GCチューニングしてAPI Gatewayのパフォーマンス改善

GCチューニングしてAPI Gatewayのパフォーマンス改善 DMM.go #4 DMM.com 登石拓磨 2022/05/18 1 / 27

自己紹介 2021 年新卒入社 プラットフォーム事業本部(以下 PF) 第三開発部 基盤開発 API Gateway の運用・改善をして います Takuma Toishi 登石 拓磨 2 / 27

話すこと API Gatewayの概要 今回問題になったこと 調査・改善内容 話さないこと GCの詳しいアルゴリズム 3 / 27

API Gateway 4 / 27

API Gatewayの役割 PFのAPIを公開する 今のところメインは社内の他事業部向け ルーティングや認証認可のコントロールなど 5 / 27

API Gatewayについて KrakenDというOSS(Go製)をベースに作っている Google Kubernetes Engine(GKE)上で稼働 リクエスト数 req/s mean 3500 max 6000 6 / 27

詳しい話 宣伝 チームメンバーが書いた記事 → DMMの API-Gatewayを構築した話 (第一話) 7 / 27

• https://qiita.com/koooyooo/items/b9395e267dee23a77d43

本題 何が問題だったのか 8 / 27

レイテンシの悪化 Gatewayのレイテンシが悪化していた Gatewayを通してAPIを公開しようとしていたチームから相談 → APIを提供している人たちが困る 9 / 27

改善前の状況 Gatewayのレイテンシがp99.9で1400msくらいになっていた p99は200msとかでまともだった 全体的(平均的に)に遅いわけではない 10 / 27

特定のリクエストが遅いのか そういうわけでもない ヘルスチェック用の(単純な)エンドポイントでさえ遅い場合がある 例えば以下のようなことは考慮しなくて良さそう リクエストのサイズが大きいときに悪化している 特定のリクエストだけが通るような処理が悪さをしている 11 / 27

プロファイル GCPのCloud Profilerを使って調査 GCがCPU時間の40%以上を占めていた → GCが走った時に遅くなっている？ 12 / 27

Prometheus 他にももうちょっと数値が見たい Prometheus ソフトウェア監視用のシステム Go用のクライアントライブラリがある OpenMetrics仕様に準拠している DatadogにOpenMetricsインテグレーションがある 他にGC関連のメトリクスで特徴的なものがないか 改善効果を確かめるのに役立った 13 / 27

• https://github.com/prometheus/client_golang

next_gc_bytes 次にGCが実行されるメモリ 14 / 27

gc_duration_seconds.count GCの実行回数の累計 15 / 27

heap_inuse_bytes 利用中のヒープのバイト数 16 / 27

改善フェーズ 17 / 27

GOGC Go の GC において調整できる唯一のパラメータ GC が走るヒープサイズを GC 後のヒープサイズに対する割合で指定 GOGC=100(default) GC 後のヒープサイズから 100%増えたら GC が走る GC 後のヒープが 100MB→ ヒープが 200MB になったら GC 参考 GC について: https://pkg.go.dev/runtime Go はいつ GC するのか?: https://zenn.dev/koron/articles/b96cccfa82c0c1 18 / 27

• https://pkg.go.dev/runtime
• https://zenn.dev/koron/articles/b96cccfa82c0c1

GCの頻度を下げる GCの走るヒープサイズが大きくなれば頻度は下がる 変更前はGOGC=100 (デフォルトのまま) ヒープが2倍でGC GOGC=300にした ヒープが4倍でGC この変更で ヒープの量は(GOGC=100の)2倍になるはず GCの頻度は1/2になるはず レイテンシ→小さくなってほしい 19 / 27

メモリ requests/limits 共に増やした GOGCを増やす→プロセスが使うメモリの最大値が増加する 20 / 27

結果 21 / 27

レイテンシ レイテンシ p99.9(ms) before after mean 1530 420 max 1850 652 22 / 27

プロファイル CPU時間: 41.6% → 19.2%に 改善前 改善後 23 / 27

メモリ使用量 増えた 想定通り 2 倍程度の増分 ヒープ使用量 24 / 27

GCの頻度 before: 5.6 回/min after: 1.9 回/min 25 / 27

気を付けたこと GOGC の調整でメモリ使いすぎないように 変更前/後で何がどう変化したか観測できるように準備した(だいじ！) 26 / 27

まとめ レイテンシの悪化によって API 提供が阻害されていた GOGC の値を調整して、GC の頻度を減らした レイテンシの悪化が改善した 今後の課題 メモリの最適化をしたい alloc/req が小さくなれば GC の頻度は減るはず 費用と相談しつつ… 27 / 27