企業の収益性を向上する活動の一環として、UberのMaps Production Engineering部門では、インフラストラクチャをより効率的な利用に重点を置いている。その取り組みの成果として、半自動的形式のGo Garbage Collectiomnチューニングメカニズムを開発し、30件のミッションクリティカルなサービスにおいて、70KのCPUコア削減に成功した。このチューニングライブラリはGoを主体に構築されており、同社のクラウドネイティブな、スケジューラベースのインフラストラクチャ上で動作する。
以前にもガベージコレクションのチューニングでJavaの効率性を向上させた経験のある同チームは、プロファイリング探索セッションを行うことによって、同社のGoサービスが消費するCPU時間のほぼ25パーセントがガベージコレクション処理(runtime.scanobjectで識別)に費やされている、という事実を突き止めた。
Uberのアプリケーションポートフォリオ内のマイクロサービスは、メモリ使用量に関するポートフォリオが著しく多様化している。例えばシャードシステム(sharded system)は、そのライブセットがさまざまだ。あるケースでは、p99の使用量が1GBであったのに対して、P1は100MBだった。この場合には、P1の発生がGCに大きく影響することになる。コンテナの確保するメモリの最大量はサービスには分からないので、固定値によるチューニングというアプローチが適切でない、という点はチームも認識していた。
サービスオーナによるガベージコレクションのチューニングプロセスを簡素化し、その上に信頼性のレイヤを加えたライブラリという、GOGCTunnerのコンセプトはここから生まれた。このチューナは、コンテナのメモリ限界(あるいはサービスオーナによる上限値)に従って適切なGOGC値を動的に計算した上で、Goの実行時APIを使ってそれを設定する。
このライブラリは、次のような特徴を持って作られている。
- 簡略化された構成によって、推論や決定論的演算を容易にする。
- Out Of Memory (OOM) による停止の回避 — メモリ制限をcgroupから読み取り、その70パーセント(チームの経験的な観点からの安全値)をデフォルトのハードリミットとして使用する。ただしこの保護には、調整対象がバッファアロケーションのみであるという制限があるので、サービスのライブオブジェクトが制限値を超過した場合には、デフォルトの下限値としてライブオブジェクトの使用量の1.25倍を設定する。
- 高いGOGC値を許容する特殊なケースもある。例えば、ピーク時のライブデータセットが通常サイズの2倍であるような時には、CPUを代償にして同じメモリ制限を適用する。手作業によるアプローチはOCMの原因になるからだ。
活動中の観測性を向上するため、チームはいくつかのメトリクスを設定している。
- ガベージコレクション間のインターバル: Goは最大2分間隔でGCを起動するため、これが定期的に発生していることがグラフから分かる場合には、アロケーションの最適化に取り組む必用がある。
- GC CPUインパクト: CPUの使用率を観察することにより、サービスにどの程度影響するかを把握できるようになる。
- ライブデータセットサイズ: このメトリクスを使うことで、使用メモリ量が増加しても、安定した使用率(ライブユース)を観測することが可能になった。
- GOGC値: さまざまな値に対して、チューナがどのように反応するのかを理解するため。
取り組みの成果として開発された、半自動的形式のGo Garbage Collectiomnチューニングメカニズムにより、30件のミッションクリティカルなサービスにおいて、70KのCPUコア削減に成功した。Uberのインフラストラクチャで使用されているツールの多くもGoで構築されている(特にKubernetes, Prometheus, Jaegger)点を考慮すれば、外部からの大規模なデプロイメントにもメモリ調整のメリットがあると考えられる。
現時点ではUberの社内目的のみで使用されているが、他のGo開発者たちがこの活動に影響を受けて、関連性のあるオープンソースツールを開発する可能性もある。