コラム

CTC教育サービス・ホーム　＞　コラム　＞　グーグルのクラウドを支えるテクノロジー　＞　第83回　Borgクラスター稼働状況の最新データ

グーグルのクラウドを支えるテクノロジー

CTC 教育サービス

[IT研修]注目キーワード Python UiPath(RPA) 最新技術動向 Microsoft Azure Docker Kubernetes

第83回　Borgクラスター稼働状況の最新データ (中井悦司) 2020年6月

はじめに

　今回は、2020年に公開された論文「Borg: the Next Generation」を元にして、Googleのデータセンターにおけるサーバークラスター稼働状況の最新データを紹介します。Googleのデータセンターでは、Borgと呼ばれる独自のクラスター管理システムを使用していますが、オープンソースのコンテナ管理システムであるKubernetesは、Borgの仕組みがベースになっていることでもよく知られています。今回公開されたデータは、大規模な環境でKubernetesを活用する際のヒントにもなるでしょう。

Borgによるコンテナ実行環境

　Kubernetesの環境では、「Deployment」リソースを定義すると、そこで指定されたコンテナイメージを用いて、同一の機能を提供する複数のPodが起動します。これに対応して、Borgの環境では、マスターサーバーに「Job」の作成要求を出すと、そこで指定されたアプリケーションバイナリーから（同一の機能を提供する）複数のコンテナが「Task」として起動します。Kubernetesの環境では、それぞれのPodが利用するCPU時間とメモリー容量について上限を設定することができますが、Borgの環境でも同様の設定が行われます。
　また、Kubernetesの環境においてPodの数を自由に増減できるのと同じように、Borgの環境でもTaskの数をダイナミックに増減することができます。Borgの環境には、「Autopilot」と呼ばれるオートスケーリングの機能が用意されており、これを用いると、1つのTaskに割り当てるCPU時間とメモリー容量の上限（垂直スケーリング）、および、Taskの数（水平スケーリング）をアプリケーションの負荷に応じて自動調整することができます。
　そして、Borgに投入するJobには、次の4種類のプライオリティのいずれか1つが設定されます。

・Free tier：最低のプライオリティで、SLOの設定がありません。
・Best-effort Batch(beb) tier：バッチジョブ用の設定で、Jobの作成要求後、一旦、実行待ちのキューに入ります。
・Mid-tier：Free tierとProduction tierの中間のプライオリティです。
・Production tier：本番サービス用のプライオリティです。
・Monitoring tier：モニタリングジョブなどインフラ環境の維持に必須のジョブに割り当てる、最高位のプライオリティです。

　オートスケーリングによって、プライオリティの高いJobにより多くのリソースを割り当てる必要が出た場合、プライオリティの低いJobに伴うTaskは強制停止されることがあります。ただし、前述のAutopilotによる事前の割り当て設定がうまく機能しており、実際に強制停止が発生する割合は、かなり低く抑えられていることが示されています。なお、Monitoring tierで稼働するJobは数が少ないため、この後のレポートでは、Production tierに含めた形になっています。

CPUとメモリー使用量

　図1は、2019年5月の1ヶ月間における、CPUとメモリーの使用率をプライオリティごとの内訳を含めた形で示したグラフです。今回のレポート用に選定された8個のクラスター（セル）についての平均値になっており、セルに含まれるすべてのリソースを使い切った場合に1.0となるように正規化した値が示されています。1つのセルに含まれるサーバー数は、典型的には1万台程度だという事です。

fig01

図1 CPUとメモリーの実使用量の変化（論文より抜粋）

　また、図2は、同様のデータを実際の使用量ではなく、事前に設定された最大使用量で示したものになります。実際に提供可能なリソース量を超えた割り当てを行う「オーバーコミット」が行われているため、1.0を超える値になっています。

fig02

図2 CPUとメモリーの割り当て容量の変化（論文より抜粋）

　一般には、リソース使用量が突発的に上昇するなどの現象に備えて、割り当て容量は多めに設定することになりますが、CPU使用量について見ると、Production tierは、割り当て容量と実使用量の差が特に大きいことがわかります。サービスの安定稼働という意味では必要なことですが、インフラをより効率的に使用するという意味では、この差は小さい方がよいことになります。前述のAutopilotは、割り当て量と実際の使用量の差（割り当てられているのに実際には使用されないリソース）を小さくしつつ、突発的な事象でリソースが不足することを防止するという、相反する要求を機械学習で最適化する仕組みになります。

Jobごとのリソース使用量の違い

　先ほどの図1は、クラスター内で稼働するすべてのJobが使用するリソースの合計値を示したものですが、当然ながら、Jobごとに必要なリソース量は変わります。冒頭の論文では、（大雑把に言うと）「1%のジョブが99%のリソースを使用している」という大きな偏りがあることが示されています。具体的なJobの種類までは示されていませんが、大規模なデータ処理や機械学習処理など、特定の一部のJobが極端に多くのリソースを使用していることが想像されます。これを具体的に示したデータは、図3のようになります。

fig03

図3 CPU使用量とJobの数の関係（論文より抜粋）

　横軸は、一定のルールで正規化された単位によるCPU使用量で、縦軸の値は、「CPU使用量がその値以上のJobの割合」を示します。このグラフが急激な右下がりになっている場合、大部分のJobはCPU使用量が少なく、ロングテールで右にのびた部分は、ごく一部のJobが大量のCPUを使用している事を示します。図3ではそれほど急激なカーブにはなっていませんが、これは、縦軸、横軸ともにLogスケールの目盛りになっているためです。通常のスケールに変換すると、ロングテールを持つ急激な右下がりのカーブになることが想像できます。

次回予告

　今回は、2020年に公開された論文「Borg: the Next Generation」に基づいて、Googleのデータセンターにおけるサーバークラスター稼働状況のデータを紹介しました。ここではごく一部のデータを紹介しましたが、論文の中では、2011年と2019年のデータ比較などより深い考察も行われています。
　また、本文で触れたオートスケーリングの機能を提供する「Autopilot」については、別の論文が公開されています。次回は、このAutopilotの仕組みを紹介したいと思います。

Disclaimer：この記事は個人的なものです｡ここで述べられていることは私の個人的な意見に基づくものであり、私の雇用者には関係はありません｡