Go Conference 2018 Tokyoに行ってきた【Wantedlyスカラシッププログラム】
参加の経緯など
Wantedly社のスカラシップ(交通費、宿泊費)でGoogle Tokyoオフィスで開催されたGoConに参加してきました。 Twitterでスカラシップあるよ!というツイートを見かけたのがきっかけでした。
Wantedlyでは地方学生の交通費と宿泊費を負担するスカラーシッププログラムでGo Conference を支援しています！#go #gocon #golang https://t.co/40Adfpnjba
— Mizuki Takeuch (@amanda__mt) 2018年11月10日
Go言語は最近個人開発で触り始めたばかりなので、このプログラムがなかったら絶対に参加していなかっただろうと思います。 Wantedlyさん、ありがとうございました。
応募フォームにはGo言語での開発経験を書く欄があったのですが、最近書き始めたばかりで経験が浅いので駄目元の軽い気持ちで応募しました。 Goのこと以外は3社でのインターンの経験を応募フォームに書きました。 沖縄という東京からかなり遠いところからの応募だったので選ばれやすかったのかな、と思います。
当日レポート
いくつかのセッションについてレポートを書きます。
Microservices実践ガイド
メルカリではどのようにMicroservicesを実装しているかというテーマのお話でした。 メルカリ本体はもともとPHPのモノリシックAPIだったそうです。 開発チームのスケーラビリティやデプロイ回数の増加と言った組織的課題に立ち向かうためにマイクロサービス移行することになったそうです（最近何回か聞いていた）。
作る流れ: Protocol Buffersの定義 => サービス実装
Protocol BuffersはJSONのようなスキーマ言語だそうです。 gRPCにおけるインターフェース定義に使用できるようになっており、 全サービスのprotoファイルを集約するリポジトリを作っているそうです。 開発者がProtocol Buffersを作成し、git pushすると Circle CIが言語のクライアントやサーバを自動生成。 全てのメンバーはProtocol Buffersファイルを読めば、APIのインターフェースを理解できるので、他チームのサービスの詳細を知らなくていいようになっている。という感じでした。 サービス実装の流れは以下のようになっているそうです。
- テンプレートプロジェクトをcloneして名前つける
- rm -rf .git
- git init
- サービスを作る!!
Goを使ってみてわかるいいところ
静的解析できる。 golintやgoformatで書き方統一できる。 シングルバイナリで動く。 ハイパフォーマンスかつチューニングしやすい(並列実行)。 ネットワークレイヤのコードが書きやすい。 ミドルウェア作るのに適している。 よく言われていることですが、メルカリほどのサービスが実際に運用した結果で述べているので説得力あるなぁと思いました。 将来はチームごとに技術スタックを選択できるようにしたいとおっしゃっていました。
よくあるJava IT企業で新規プロジェクトをGoで立ち上げてみてる話
Goでバリバリ開発をしている!という訳ではない企業のお話でした。
- 自社でGo使いたいけどまだ導入できてない人向け
- JavaをGoで置き換えたい、世界中で使われてほしい
- 電子コンテンツのマネジメントをしている(出版社とkindke,LINE漫画の間に入るお仕事)
Golang導入の軌跡
きっかけはコンテンツの配信エンジンの置き換えをしようとしたそうです。 そこで以下のような問題点が挙げられていました。
- 現状のJava実装では機能追加、不具合修正が難しい
- フレームワークなしのほぼ全て自前での実装で
- 10年前と変わらない技術スタック
単にGoを導入したいだけではなく、ビジネスとして成り立つサービスにしたいのと、 今後10年続くサービスにして新しい技術でエンジニアのモチベーションもあげたいという狙いもあったそうです。 また、優先度の高い機能から置き換えようとしら、結果的にMicroservice化もしたそうです。 キーパーソンだけ説得し、まず動くもの見せてるということも言われていました。 これは地味に今後の参考になりそうでした。人を動かすの、大変ですよね。 array, slice, pointerと向き合いすぎないようにしたというのも、初学者には良いと思いました。
気づいたこと
- build生成物が大きい
- 過剰なフレームワーク(gRPCとか)は入れない方がいい
- エラーハンドリングが難しい、ある程度実装して初めてパターン見えてくる
今後
本格的なサービス運用はこれからとのこと。 成熟したコーディングをしていきたいそうです。 成熟したコーディングには僕も激しく同意!という感じです。
OpenCensus による APM の実現と、未来
なぜAppのパフォーマンスを気にする必要があるのか?という問いかけで始まりました。 もちろんその答えはユーザー体験を向上させるためですね。 APM(Application Performance Management)とは、要求されているサービスの質を保つ為に、アプリケーションのパフォーマンスの継続的な監視と管理を行うことだそうです。初めて知りました。その為に必要なことは以下の2つですね。
- パフォーマンス改善に必要なデータの取得
- 取得したデータを可視化、活用できる基盤の構築
よくある構成でデータを収拾しようとすると、 コードベースと基盤が密に結合してしまいます。。 そこで、Open Census登場です。 OpenCensusとはAPMに必要なデータを収集し、外部サービスに提供するためのフレームワークで、Google社内のCensusと呼ばれうライブラリをOSS化したものです。 これがとても便利なのですが、欠点もあって
- バックエンドとデータ収集の結合度を下げたことで、バックエンド固有の最適化のためのメタデータの付与ができない。
- 一般的なuse caseに対する共通化、ライブラリ実装の拡張に対する仕様が必要
とのことでした。
将来的には、
- コードベースと基盤と依存を極力無くしたAPMの実現が可能になる
- ベンターに依存しない実装により、APMはさらなるecosystemの成長を遂げるであろう
とのことでした。 後半引用が多くなってしまいましたが、どういうライブラリをいかに使うかで、会社のサービスの質は大きく変わるからエンジニアの責務は大きいなぁと思いました。
Profiling Go Application
Go製のアプリの高速化やプロファイリングの実例を、プロセスを追って説明するというものでした。個人的には一番印象に残ったトークでした! 画像変換サーバー、kubelt、go-swaggerなどのチューニングの話を聞きました。 遅いと思ったら計測してみようというのは当たり前ですが、やっていないことだなぁと気づかされました。 cliならpkg/profileを仕込んでみたり、サーバーならnet/http/pprofを使いましょう。 そして、原因を特定したらbenchmarkを書いて、プルリクを投げましょうという話でした。 Goはチューニングしやすい言語ですが、必要を感じるまでチューニングはしないでおきましょう。でも、チューニングに必要な環境は用意するべきでしょう。という締めでした。 チューニングしてはプルリク投げるってかっこよすぎ! ISUOCNやっていたせいか、チューニングは興味を惹かれました。 (pprofはについては以下の記事が分かりやすかった。)
Consider pluggable CLI tool implementation
grapiとはgRPCサーバのscaffolding tool/template generatorだそうです。 簡単にいうとgRPCとコードジェネレーターが合体したようなものらしい。 GoのAPI Server開発体験を高めるCLI + package。 ユーザが外から拡張できるようにする(extensibilityを高める)為に、plugin機構になっているというのはなるほどと思いました。 体験良いツールの例として、 * Rails Generators * create-react-app Goで実装しやすそうなツールの例として、 * protoc * kubectl * Terraform * SQLBoiler が挙げられていました。 後半4つのツールについては今後調べたいと思います。 中間をすっ飛ばしてしまって申し訳ないのですが、結論が響きました。 メインじゃない機能はpluginとして提供できるようにすることで、OSS burnoutを防止してかつ、継続的にメンテする為にも「ひとつのことをうまくやる」アーキテクチャにしたというのは参考になりました。 git cloneしてすぐに使えるツールって素晴らしいですし、それが継続的にメンテされるなんて最高ですよね。
フィードバック制御によるGoroutine起動数の最適化
タイトルの通り並行処理と最適な並行数がテーマでした。 このテーマはISUCONの時のunicorcのworker_processes数をいくつに設定したらいいんだろう？と疑問を持った時から気になっていたことでした。 しかし、処理の特性、ランタイムやスケジューリングの特性を考慮しないといけないので、普遍的なチューニング手法の発見はやはり困難ですよね、、、 しかしCPU負荷に応じて継続的に並行数を最適化できるKaburayaアーキテクチャという物をGo言語に適用したすることで、並行数の増加が性能に影響するタスクにおいては、妥当な並行数を算出できる可能性が示されていました!!すごい!! スライドの作り方が研究発表っぽくて好きでした。笑 もっと理解できるように制御工学勉強したいと思いました。 ちなみに紹介されていたバッファ付きチャネルをセマフォとする並行数制御のGo実装のコード。
func main () { var wg sync.WaitGroup sem := make(chan struct{}, 3) for i := 0; i < 10; i++ { wg.Add(1) sem <- struct{}{} go func () { defer wg.Done() defer func () { <-sem } () task() } () } wg.Wait() close(sem) }
Pains and gains of architecting microservices on local dev environment
言語が異なることによる開発環境の複雑化
70(諸説あり)のマイクロサービスたちが、動いているWantedlyのサービス。 そんな、ローカル開発環境ってミドルウェア、システムライブラリなどのせいで複雑になりますよね。 開発環境をDocker化することで解決！ってのは最近よく聞きます。 そんな中で、rid-(run in docker)、というツールをGoで開発されたそうです。 ridをインストールしてコマンドを実行すると、コンテナの中でrailsのbundle installやrails db:createやrails serverが実行されて環境依存の問題を無くせるみたいな感じの話でした。
複数サービス間通信時のサービスディスカバリ
複数箇所で同時多発にマイクロサービスが立ち上がってしまうと、ポートの取り合いが発生してしまうそうです。 これもridで解決してくかもしれないという感じの話だったと思います。 制限時間と自分の集中力の関係で、曖昧な感じです。 もっとサービス運用した経験を持ってこういう話聞きたいなー!!と思いました。
GoCon反省会兼RejectConあるらしいので、知りたい方はこちらへどうぞ!
感想
カンファレンス以外のことも書いておくと、Airbnbで取って頂いた宿に学生4人で泊まったり(常時もくもく会していた)、 Wantedlyの方々とフィンランド料理をランチに食べに行ったり、ステーキ屋さんに連れて行ってもらったりと楽しい時間を過ごせました。 オフィスは緑に囲まれた立地で内装も良くて気持ちよく仕事できそうな感じでした。 オフィスの会議室の名前がジョジョのスタンド名になっているような遊び心も良いと思いました。 こんな感じで締めようと思います。 Go言語もっと書いていくぞ! Wantedlyの皆さん、貴重な機会をありがとうございました!!
