コラム

CTC教育サービス・ホーム　＞　コラム　＞　グーグルのクラウドを支えるテクノロジー　＞　第33回　アプリケーション実行基盤の標準環境 Borg（パート2）

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

CTC 教育サービス

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

第33回　アプリケーション実行基盤の標準環境 Borg（パート2） (中井悦司) 2018年2月

はじめに

　前回に引き続き、2015年に公開された論文「Large-scale cluster management at Google with Borg」をもとにして、Googleのクラスター管理システム「Borg」を紹介します。今回は、Borgのアーキテクチャーの概要、そして、1万台規模のサーバーにタスクを配置するスケジューラーに関する説明を行います。

Borgのアーキテクチャー

　Borgのシステム構成の概要は、前回の図1に示した通りです。Borgのセルを構成する各サーバーには、「Borglet」と呼ばれるエージェントが配置されており、「BorgMaster」と呼ばれるマスターサーバーで集中管理を行います。ただし、大量のサーバーを管理するために、さまざまな実装上の工夫がなされています。たとえば、BorgMasterは、冗長化のために複数のサーバーにアクティブ・スタンバイ構成で配置されますが、リードオンリーのAPIアクセスについては、スタンバイ側でも処理を受け付けます。また、新しいジョブをAPIで受け付けた際は、そのジョブから起動するべきタスクをタスクキューに登録しておき、その後の処理は、別のプロセスとして稼働するスケジューラーに移譲します。
　論文の中では、特に稼働率の高いセルでは、10〜14個のCPUコアと50GB程度のメモリーのサーバーをマスターサーバーとして使用しており、1分間に10,000個以上のタスクの起動処理を行っていることが説明されています。また、タスクキューに登録されたタスクの配置先を決定するスケジューリングの処理は、複数のスケジューラーによる並列処理が行われており、処理を効率化するためのいくつかの工夫がなされています。
　まず、タスクを配置するサーバーを決定する際は、配置先の候補となるサーバー群を選んだ後に、それらに対するスコアリングを行います。最終的に最もスコアの高いサーバーがタスクの配置先として選択されます。配置先の候補を選ぶ際は、タスクの実行に必要なリソースなど、タスクの稼働条件を満たすサーバーを見つけるわけですが、1万台近くのサーバーすべてをチェックするのは時間がかかります。そこで、ランダムな順序でサーバーをチェックしていき、十分な数の候補が集まった時点で、その処理を打ち切ります。次に、候補となるサーバーに対するスコアリングの処理は、後述する一定のアルゴリズムで行われますが、個々のタスクとサーバーのペアに対して、毎回、アルゴリズムによる計算を行うのは、これもまた時間がかかります。そこで、類似の条件を満たすタスクをグループ化して、グループごとにスコアリングを行います。さらに、スコアリングの計算結果をキャッシュする機能も用いられます。

スケジューリング処理の効率性

　タスクを配置するサーバーを決定するスケジューリングにおいては、サーバーの利用効率を高めることが1つの重要な指標となります。たとえば、第19回の記事の図4では、サーバーの稼働率は、データセンターの電力効率の指標であるPUEに直接的な影響を及ぼすことを説明しました。今回の論文の中では、あくまで比喩的な表現ですが、「incresing utilization by a few percentage points can save millions of dollars」というような説明もなされています。Borgでは、仮想マシンを用いずに、Linuxコンテナによるタスクの分離を行いますが、これもまた、仮想化によるオーバーヘッドを削減することが理由になります。
　ただし、1台のサーバーにまったくの余裕なくタスクを詰め込んでしまうと、突発的なワークロードの増加に対応することができません。Borgが採用するスケジューリングのアルゴリズムでは、適度なバランスを取るように考慮されており、実際の使用率に関して、論文内では、図1の結果が公表されています。

fig01

図1 サーバーの使用率を示すシミュレーション結果（論文より抜粋）

　このグラフの見方については、すこし説明が必要です。これは、複数のセルから実際に稼働中のタスクの情報を収集した後に、これらのタスクを最小台数のサーバーに詰め込んだとした場合に、必要なサーバー数をどこまで減らせるかをシミュレーションした結果です。横軸が80%の所において、縦軸の値が20%になっているのは、「サーバー数を80%以下に減らせるセルは全体の20%存在する」という意味になります。逆に言うと、8割以上のセルでは、80%以上の使用率を達成しているというわけです。横軸90%に対しては、縦軸60%ですので、4割以上のセルにおいて、90%以上の使用率を達成しているという事になります。
　特に大量のリソースを必要とするタスクを配置する際は、バッチジョブなどの優先度の低いタスクを他のサーバーに強制的に移動して、特定サーバー上のリソースを確保することもあります。図2は、このようなタスクの強制移動の発生数を1週間あたりの回数で示したものです。「non-prod」に対する「preemption」の回数がこれにあたるもので、1つのタスクについて、1週間に7〜8回、つまり、バッチジョブは、1日に1回程度の頻度でサーバーの再配置が行われることになります。

fig02

図2 タスクの1週間あたりの再配置の回数（論文より抜粋）

　また、優先度の高い「prod」のタスクについては、他のタスクを配置するための強制移動はありませんが、サーバーの停止に伴う強制移動がわずかながら発生していることがわかります。これはハードウェアやOSの保守作業に伴うものですが、論文の脚注には「Exception: tasks that provide virtual machines for Google Compute Engine users are migrated.」という興味深いコメントが付けられています。実は、GCPのCompute Engineの仮想マシンを提供するサーバーでは、ハイパーバイザー機能（Linux KVM）はLinuxカーネル内部で稼働していますが、それとは別に「ユーザースペース仮想マシンモニタ」と呼ばれるユーザー空間で稼働するプロセスも存在することがBlog記事で公表されています。GCPのさまざまな機能を提供するタスクは、GCP専用のBorgのセルで稼働していますが、Compute Engineの仮想マシンを提供するプロセスについては、仮想マシンの停止を伴わないライブマイグレーションが実施されることを言っているものと思われます。

次回予告

　今回は、論文「Large-scale cluster management at Google with Borg」をもとにして、Googleのデータセンターにおけるアプリケーション実行基盤の標準環境である「Borg」について、アーキテクチャーの概要とサーバーの利用効率に関するデータを紹介しました。8割以上のセルで80%以上の使用率を達成するスケジューラーのアルゴリズムについては、論文内にもう少し詳しい説明がありますので、興味のある方はそちらもぜひ参照してください。
　次回は、Borgにおけるサーバーの利用効率、そして、パフォーマンスに関するその他のデータを引き続き紹介したいと思います。

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