栗ブ

筋トレが好きなWebエンジニアのアウトプット。読書感想やクソポエムなど

golang.tokyo #12に参加してきた

概要

Go言語の勉強会であるgolang.tokyo #12にブログ書く枠で参加してきたので発表内容や感想などを書きます。

今回の発表テーマは『スタートアップ・新規事業におけるGo』

発表から2週間以上経ってのアウトプットと遅くなってしまい、乱文ではありますが書いていきます。

golang.tokyoについて

公式の文言を引用すると次の通りです

プログラミング言語のGoの導入企業のメンバーが集まり、Goの普及を推進するコミュニティです。 トークイベント、ハンズオン、etcのイベントを開催していく予定です!

Goコミュニティには次のように「初級向け」「中級向け」「上級向け」と勉強会が分かれて用意されていて、golang.tokyoは「中級向け」の内容となっている。

  • Goビギナーズ
  • golang.tokyo
  • Go Conference

私のGoレベルですが2017-08に開催されたGo言語初心者向けハンズオン#4の参加からGoを始めた、 Go歴6ヶ月のエンジニアで業務ではPHP, C#, Node.jsを使用していて、まだまだビギナー枠に位置するのかと思っています。

しかし、、、

という流れを踏み、次のステップへ移行してみようという事で今回golang.tokyoに初参加してみました。

発表1

資料

登壇者

@sonata

内容

スタートアップではGAE/GOが良いという話でオートスケール、OSの管理が不要でプロダクトに集中出来るのが良い。

スタートアップはエンジニアが少ないので、限られたリソースはアプリケーションの設計、ビジネスロジックに割きたい。 技術選定はシンプルを目的としている。GAE/SEをアプリケーション毎に環境構築する。

GAE/SEではL3ネットワークを考える必要がない。自動的にドメインが割り振られる。サービスの分割をしているがソースコードは全サービス共通。adminサービスはGoogleOAuth認証を使用。

マイクロサービスの必要性はメルカリの「オーナーシップを持つため」という考え方がとても良い。 マイクロサービスの弊害としてはコード管理、ログ管理など検討事項が増える。エンジニアが3人なのでサービスではマイクロサービスは導入していない。少人数な限りモノリシックでやる。 GAEではバージョン毎にURLが作成されて、バージョン毎にブルーグリーンデプロイができる。マイグレーションを使用してるがデプロイ直後にヘルスチェックして、200が返らなければマイグレーションしないようにしてる。

レイヤーアーキテクチャを採用して、サービス毎にアーキテクチャの決定に価値を持っている。正しいDDDを目的としない。アーキテクチャの決める目的をはっきりさせて、目的達成しているかで判断する。

フレームワークの選定

上記を満たすgo-chiを選定

ライブラリ選定

  • gorp
  • gorm

@mattn_jpさんも使っているので安心感がある。

APIプロトコルの選定

gRPCを採用。RestfulAPIはURLの設計が苦労の割にメリットがないと考えた。プロトコルバッファー on httpを採用。定義ファイルを使用したいのでgRPCを採用。定義ファイルからGo, Swift, TypeScript, javaなどのソースコード生成出来る。 gRPCは設計が楽との事。http-methodはPOSTのみで設計。ただgRPCはデファクトスタンダードではないので他社にAPI公開には向かない。URLとmethodは同じなので、bodyを見てどの処理をしたいかを判断。ただcurlで気軽に確認しづらい。Twitch製のRPCフレームワークを使った。

http client

Chome ExtensionのPostmanを使っている。環境変数を設定できるので便利。アクセストークンを設定して変数で使いまわせるしswaggerも必要ない

config

app.yamlで設定するのがGAEではセオリー。envconfigというライブラリを採用。

セキュリティ

Cloud Key Management Serviceで暗号化して保存してる。

開発環境

コマンド操作オンリー。WEBコンソールから操作すると操作履歴が残らないのでコマンド一択。操作はshでまとめている。

CI

CircleCI使っている。travisからCircleCIに移行したら速くなった!

発表2

資料

登壇者

@shinofara

内容

MF KESSAIとは?マネーフォワードの子会社。BtoB資金繰り改善をフォーカスしたサービスを提供する会社。

請求業務プロセスをサービスとして代行する。フローの手間をシステム化。相手が倒産してもMF社が保証する!創業から11ヶ月立ったのでノウハウを発表する。 エンジニアが2名。PO兼エンジニアとインフラ兼エンジニアで開発してる。

Goを採用した理由

お金に関わるので型は厳格にしたい。言語移行コストは下げたい。 Goは誰が書いてもソースが似てくるのがメリットである。などなどの理由から採用した。

FrameWork選定

フレームワークは使わず薄く作る方針で。足りない部分はライブラリを導入する事で効率的に。 test, lint, vetは最初から導入。

Dockerを採用した理由

環境の同一性担保のため

GCPの採用理由

インフラエンジニアがいなくても運用しやすい。Stackdriverの存在。Kubernetesの採用。

開発初期

とくにユーザーがいなかったため、社内ツール作成から開始した。

企業向けサービス開発期の話

エンジニアの新規メンバーのアサイン。社内APIはgRPCを採用。プロトコルバッファーの定義を使いまわせるのが利点として採用。社外向けにはRestfulAPI。goaを採用して使っている。認証はKongを採用。

現在

運用フェーズなので、モニタリング、エラートラッキングなどを見直し。

スケーラブルなPDF発行の仕組み

最初はバッチ処理で直列でPDFを作成していた。そこからpub/subで作成するようにしたら1時間とか掛かっていた処理が数分になった。 サーバーレスにしたかったけど、docker(kubernetes)が対応してなかった?

プロメテウスなどのモニタリングも検討したがストレージ管理などのタスクを開発フェーズ的にやりたくなかったため、DataDogというクラウドサービスを使用。 可能な限り自社開発せず、有り物のサービスを使う方針。この割り切りは良い!

振り返り

新規事業にgoを選んでみて。仕様変更がかかった時にコンパイルがあるので壊れてる事に気がつけたのは良かった。CIやtestツールを初期に導入しておいてよかった。レビューのムダを省略。チーム開発に向いている。疎結合な言語設計。

Goを使用したデメリット

  • Go未経験者がいると、使用していた言語にある機能がない!など、意見の衝突が起きた
  • WebUIを作るのには向いていない。Webテンプレート操作が苦しいため管理画面作成などには向いていない
  • エラーハンドリングで記述量がそれなりに多くなりがち
  • IDEが必要になりそう
  • if err != nil ...が手間に感じた

Lightning Talk1

資料

登壇者

@cnosuke

内容

SRE at お金のデザイン社。THEOというサービス運営してる。

Go + gRPC - いくつかのアプリ向けAPI - いくつかの社内向けAPI kubernetes - GKE 開発用クラスタ - AWS 本番用クラスタ

金融系でKubernetes使っているのは、僕らだけじゃないかな? 金融系はサービスを止められない。止めると金融庁へ報告が必要だったりする。

ssh/portfowardingが面倒だった。kushiというツールを作った。sshの設定が面倒。他の人も設定が必要で面倒なので作った。ymlで定義する。

Lightning Talk2

資料

登壇者

@Seiji Takahashi

内容

AWS lamdbaがGoを採用した。今まではapexで書いていた。今は公式パッケージであるaws-lambda-goを使う。 apexからaws-lambda-goへの移行は容易。違いはそんなにないので移行しやすい。ただ、aws-lamdba-goはdeployがawscli経由。 aws-lambda-goのソースコードを追っていく。reflectionの応用例では参加者から笑いが起きたり。

Lightning Talk3

資料

登壇者

@Shohei Koyama

内容

FPSプロゲーマーで現在はボヤージュグループでSREをしているそう DBの接続情報はどこで管理してる?aws Sysmtem Manager SSMを使ってみよう。 yaml-ssmというツールを作った。パスワードをdecryptする。デモ発表など。

所感

Goビギナーからのgolang.tokyoの初参加であったが、発表内容のレベルが高くどの話もとても面白かった。 個人的には@shinofara氏の発表に一番興味をもち、スタートアップ企業(MF Kessai社)が「創業初期」「導入企業向けサービス開発期」「現在」とビジネスフェーズにどのようにGoやシステム・アーキテクチャを採用するに至ったか、どのように判断するに至ったかの話がとても参考になった。 Goを採用したいと考えているが、どこに対してどのように採用するのか悩んでいる方はこのスライドは参考になるのではないでしょうか。

皆さんgoの強みを最大限活かしているという印象でした。

golang.tokyoで発表できるようになるにはまだまだGoレベルが足りないため、開発実績を積んで行かねばという気持ちを持った所存です。

P.S 今後は勉強会に参加した翌日にはブログを書こう!(反省)