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 の構成:

Sentry: システムコールのハンドリング
Gofer: ファイルシステムプロキシー
- スペシャルファイルを開いてネットワークシステムコールを呼んでも安全
- 内部的には GAE/Go 上のネットワークしか見えない

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
  - 添字チェック→安全だと判断できればコンパイラ側が削除してくれる
kubelet でCPU負荷が高い
- 調査
  - kubelet は pprof を imporot しているので pprof を使う
- 問題点
  - String.Replacer が大量にあった
- 対策
  - Write がたくさんある部分を１ 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 で書かれている
- 論文
  - https://www.usenix.org/conference/osdi18/presentation/cutler
- 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ならわかるシステムプログラミングを読もう

giantneco’s blog

技術メモ