Google は、同社のサービスと Kubernetes の前身となる「Borg」クラスターのパフォーマンスを説明する膨大な量の新しいデータを公開しました。
広告・個人データ大手のGoogleがこの種のデータを最後に公開したのは2011年で、当時は29日分の「Google Borgコンピューティングクラスタ内の全ジョブのジョブ送信、スケジュール決定、リソース使用データ」を公開していた。今回、同社は2019年5月中に8つのクラスタで生成されたデータに加え、5分間隔のCPU使用率情報、共有リソース予約情報、そしてマスター／ワーカー関係におけるジョブ親情報も提供している。その結果、ダンプには各クラスタから350ギガバイトのデータが含まれており、2011年にサンプリングされた単一クラスタの40ギガバイトから増加している。
Googleは、Google、ハーバード大学、カーネギーメロン大学、セントアンドリュース大学の研究者が執筆した、これら全てを分析した論文[PDF]も公開しています。さらに詳しく知りたい方は、Googleが新たに開発したスケーリングツール「Autopilot」の仕組みを解説した、Googleが共同執筆した別の論文[PDF]もご覧ください。
Autopilot の論文では、Google の内部について次のように説明しています。
この文書ではまた、Autopilot がクラスター全体でメモリの 50% 以上を使用することはめったにないのに対し、Alibaba は 80% の使用率を達成していると報告されていることから、Google がライバルのクラウドに対して少々嫉妬しているように見えることも明らかにしている。
トレース分析の論文によると、Borg は「現在、複数のスケジューラをサポートしており、その中には、ジョブをセルが処理できるようになるまでキューに入れて、スループットの集約バッチ ジョブ ワークロードを管理するバッチ スケジューラも含まれ、その後、ジョブは通常の Borg スケジューラに渡されます」とのことです。
また、Autopilotの役割についても詳しく説明しており、「ジョブのリソース要件を指定する負担を軽減することを目指しています。これは困難な場合があります。なぜなら、要求するリソースが少なすぎると、ジョブがユーザーサービスの期限に間に合わなかったり、クラッシュしたりするなど、壊滅的な結果を招く可能性があるからです。」と説明しています。
「これにより、システムへの処理能力が向上し、効率性の向上とコスト削減に直接つながります。オートパイロットは、同一または類似のジョブの過去の実行履歴データを活用して初期リソース要求を設定し、ジョブの実行中にリソース制限を継続的に調整することで、スラックを最小限に抑えます。」
しかし、Autopilot ステアリング ワークロードを使用しても、Borg クラスターの使用率は依然として非常に低いままです。以下のグラフは、メモリと CPU の使用率がどちらも 60% を超えることはほとんどないことを示しています。
Google による自社のメモリと CPU 消費量の分析。クリックして拡大します。
著者らは、なぜそうなるのかについてさらなる研究を行うことを提案している。
もう一つの観察結果は、リソースを大量に消費するアプリケーションの1%が、使用されるリソースの99%を消費しているというものです。論文では、小さなジョブがキューの最後尾に配置され、リソースを奪い合うことになるため、これが問題であると示唆しています。
Google 内での使用パターンの変更についても議論されています。
「ワークロードの多くは、無料層（低優先度）からベストエフォートのバッチ層（キューに入れられたバッチスケジューラによって管理されるジョブ）に移行しましたが、実稼働層（高優先度）ジョブの全体的な使用率はほぼ一定のままです」とトレーサー分析の論文では説明されています。
論文にはさらに多くの情報が掲載されており、 GitHub の BigQuery テーブルには 2.8 GB のトレース データがありますので、ぜひお試しください。
論文によれば、これらは第 15 回コンピュータ システム カンファレンス (別名 EuroSys '20) で発表されたもので、このイベントは今週ギリシャのイラクリオンで開催される予定だったが、もちろんバーチャル形式で行われたとのことです。®
