Go Conference 2018 Autumn メモ
少し前の話になるが Go Conference 2018 autumn に参加した。 Go Conference 2018 autumn は 2018/11/25 に行われた Go 言語のイベントで、六本木の Google オフィスで行われた。
自分と Go との関わりだが、今現在のプロジェクトでは Go を使っているもののどうも妙な使い方をしている。 なので他のところでの話は機会があれば聞いておきたかった。
自分が聞いた範囲では GAE とマイクロサービスでの話が多かった。 やはりクラウド上でマイクロサービスを使う場合には、Go が有利なんじゃかないかと思う。
その他にも低レイヤよりの話や、パフォーマンスチューニング、導入事例など色々な話が聞けてよかった。
以下メモ。
キーノート by Steven Buss
キーノートは GAE/Go の 歴史的な変遷と最新の GAE の話。
以前は NaCl= Google Native Client で動いており、 ptrace を使ってシステムコールの呼び出しを検知しハンドリングすることで環境を独立させていた。 新しい世代の App Engine では gVisor を使っているのでそれらの必要がなくなった。
gVisor は Go で書かれた ユーザ空間カーネルで、 アプリケーションのシステムコールなどをハンドリングして環境を隔離し、セキュアにできる。
gVisor:
- Pros: 柔軟な必要リソース、低コストな仮想化、拡張可能なアーキテクチャ
- Cons: 互換性の減少、高オーバーヘッドなシステムコール、システムコールが実装されていないときにはよくわからないエラーになる
gVisor の構成:
2 つのプロセス間は 9P (Plan 9 Filesystem Protocol) で繋がれている。
将来的には Google のクラウドはすべて Go で作られる。
- gVisor
- Second-gen pp Engine runtimes
- Cloud functions
- k8s
- knative
- etc, etc
Mirroservices 実装ガイド in Go at Mercari by @_yagi5
メルカリでのマイクロサービスの話。
- サービスの追加手順
- プロトコルバッファの追加→サービスの実装の順序
- サービス間通信
- サービスのテンプレート
- エコーサーバ
- ミドルウェア
- grpc-echosystem/go_grpc_middleware の ServerChain の仕組みを使用
- ロギング(トレーシング)
- opencensus と zap(zapgrpc) を利用
- マイクロサービスでの Go のいいところ
- ネットワーク/ミドルウェアレイヤとの相性がいい
- 静的解析ツールで書き方を強制できる
OpenCensus による APM の実現と未来 by @munisystem
APM = Application Performance Management の話。
- APM
- APM = 「Service Level を維持するため app のパフォーマンスの継続的な監視をすること」
- 実現に必要
- performance の取得
- data の可視化、活用できる基盤の構築
- Tracing: サービス・サーバをまたいだイベントの追跡
- Metrics: なにが原因で悪くなったか調べるのに必要
- Logging: ログ
- Error reporting: エラーの調査
Go での APM 実現例として:
- Tracing: Stackdriver Trace /Datadog APM /Zipkin ?jaeger
- Metrics: Stackdriver Monitoring / Dtadog /Prometheus
- Loggin: zap / glog + fluentd
- Error repoirting: Hobeybadger /Sentry
だが上記のライブラリではクライアントライブラリと基盤が密になってしまっている。 APM 基盤はサービス、組織の規模で変更を楽にしたい。
OpenCensus * OSS 版 Census * APM のデータを収集→外部サービスに提供 * アプローチ *コレクターとエクスポーターの分離 * コレクター データの収集 * エクスポーター 変換と送信 * Cloud provider は expoorter だけ実装する * App はデータを収集するところだけ実装する * 欠点 * バックエンド固有の最適化のためのメタデータの付与が行えない←結合度が下がったため
Profiling Go Application by @orisano
Go アプリケーションの性能を改善した話。
- 画像変換サーバが OOM killer に殺された
- 調査
*
pprof, GODEBUG=allocfreetrace=1
- GC で参照グラフをダンプしてみた
- 問題点
- 同時変換数に制限がつけられてなかった
- 調査
*
- disintegration/imaging が 遅い
- boundary check elimination
- 添字チェック→安全だと判断できればコンパイラ側が削除してくれる
- boundary check elimination
kubelet でCPU負荷が高い
- 調査
- kubelet は pprof を imporot しているので pprof を使う
- 問題点
- String.Replacer が大量にあった
- 対策
- Write がたくさんある部分を1 Write にまとめることができる
- Readdir 遅い, -> goreaddir に入れ替え
- 調査
まとめ
- 普段使っているものでもカリカリにチューニングされているわけではない
- 遅いと思ったら自分で改善してみる
- 対策するには
- Benchmark を書く: bnechcmp or chenccomp
- Go はパフォーマンスチューニングしやすい
- ツール充実している
Biscuit Code Reading by @shibu_jp
Biscuit Code Reading - Google スライド
@shibu_jp さんは「Goならわかるシステムプログラミング」の著者の方で、 Biscuit をネタに主にブートシーケンスに関する低レイヤの話をしていただけた。
Biscuit は 並列・分散の研究ためのOS で Go で書かれている
- 論文
- Features
- multicore
- journaled FS with concurrent, deferred and group commit
- 中身
- ほぼ Go のところがある
- Biscuit のみの部分は buicuit/ 下に置いてある
- Kernel Space
- Bisucut / Go library / Shim
- shim -> systell call 置き換え
- Executable File Format は ELF
まとめ
- Go はコンピュータシステムを学ぶのによい教材
- Go 言語のランタイムは低レイヤから上まで Go で書かれている
- Goならわかるシステムプログラミングを読もう