コラム

CTC教育サービス・ホーム　＞　コラム　＞　グーグルのクラウドを支えるテクノロジー　＞　第103回　Googleの分散ビルドシステムのアーキテクチャー（パート3）

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

CTC 教育サービス

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

第103回　Googleの分散ビルドシステムのアーキテクチャー（パート3） (中井悦司) 2021年4月

はじめに

　前回に続いて、2020年に公開された論文「Scalable Build Service System with Smart Scheduling Service(PDF)」を紹介します。この論文では、Google社内で利用されている「分散ビルドシステム」のアーキテクチャーが解説されています。今回は、このシステムの実際の動作環境について、論文に掲載の性能データなどを含めて紹介します。

コンポーネントの配置とスケーラビリティ

　Google社内の分散ビルドシステムは、前回の図1に示したように、いくつかの独立したサービスが連携するマイクロサービス型のアーキテクチャーになっており、それぞれのサービスは、負荷分散のために複数デプロイされています。また、世界各地の開発者が利用するシステムのため、各サービスは複数のデータセンターに分散配置されており、データセンターを跨いだサービス間の連携も行われます。Googleのデータセンターは、Googleが所有する専用回線で相互接続されており、地理的に離れたデータセンター間でも数ミリ秒以下のレイテンシーで通信することができます。これにより、システム全体の性能を損なうことなく、データセンターを跨いだマイクロサービスの配置が可能になります。
　ただし、特に低レイテンシーでの通信が求められるサービスは、同一のリージョン内で連携します。たとえば、前回の図1にあるスケジューリングサービスは、Spannerデータベースに対するデータの読み書きが大量に発生するので、同一リージョンにあるSpannerを利用します。また、Bazel Workerからのイベント情報をリアルタイムに取得するEvent Serviceも、同一リージョンで連携します。つまり、リージョンAのBazel WorkerのイベントはリージョンAのEvent Serviceが収集して、リージョンBのBazel WorkerのイベントはリージョンBのEvent Serviceが収集するといった動作になります。同様に、Bazel WorkerとExecutor Clusterも同一リージョンでの連携が行われます。
　このシステムは、１日あたり、平均で1,500万回、最大で2,500万回のビルド処理を実行します。論文によると、厳密な負荷テストは行っていないものの、さらに数百万回程度のビルドに対応できるキャパシティがあると想定されています。図1は、ある期間における各サービスに対するQPS（1秒間あたりのリクエスト数）を示したものですが、たとえば、開発者からのビルド開始リクエスト（CreateBuild）は、平均（Avg）で100〜250回になっており、1日の合計に直すと、前述の約1,500万回という値に合致しています。

fig01

図1 各サービスに対するリクエストのQPS（論文より抜粋）

　同じく、図2は、各サービスの応答時間（単位はミリ秒）を示します。平均値（Avg）で見ると、ビルド開始リクエスト（CreateBuild）は、0.1秒〜数秒程度で、現在のビルドの状態を取得するリクエスト（GetBuild）は、40ミリ秒以下になっています。これらは、どちらもSpannerに対するアクセスが発生しますが、CreateBuildは書き込みを伴うのに対して、GetBuildは読み込みだけで処理が完了します。論文内では、このようなアクセスパターンの違いが、応答時間の違いに影響しているものと説明されています。

fig02

図2 各サービスの応答時間（論文より抜粋）

　最後に、図3は、ビルドリクエストの優先順位ごとに、リクエスト数の割合（Build Count）と実際の処理時間（秒）などの情報をまとめたものになります。たとえば、自動化ツールからのリクエスト（AUTO）は処理の優先順位が下がるため、リクエストが受け付けられた後、実際の処理がはじまるまでの待ち時間（Build Queuing）は約300秒と少し長くなっています。一方、緊急処理のリクエスト（EMERG）は、この待ち時間は2.4秒になります。また、実際のビルド処理が行われる時間（Execution）については、いずれの優先順位についても2〜3分程度という結果が見られます。これは、ビルド後の単体テストを含めた実行時間になります。

fig03

図3 各サービスの処理時間（論文より抜粋：3〜7行目の数値の単位は「秒」）

その他の性能に関連する情報

　論文内では、その他にも、ビルドシステムの性能に関連した「実験」の結果が報告されています。たとえば、前回の記事では、「スケジューリングサービスは、Workspace内のキャッシュのヒット率が高くなるように、類似したビルド処理をできるだけ同じWorkspaceに割り当てる」という説明をしました。この機能の効果を確かめるために、一時的にこの機能を停止して、ビルド処理にかかる時間の変化を測定したところ、この機能は、およそ14%の性能向上に寄与することがわかったそうです。
　あるいはまた、「スケジューリングサービスがWorkspaceにジョブを割り当てる際は、該当のジョブが使用するリソース量を事前に予測する」という説明をしました。これは、過去の実績データを元にした機械学習モデルで予測をしていますが、x86サーバーでビルドするジョブと、AppleのMacでビルドするジョブでは、予測精度に大きな違いが出たそうです。Macでビルドするジョブは相対的に数が少ないために、モデルの学習に利用できるデータが少なくなることが原因だろうと指摘されています。

次回予告

　今回は、2020年に公開された論文「Scalable Build Service System with Smart Scheduling Service」に基づいて、Google社内の分散ビルドシステムについて、実際の動作環境における性能情報などを紹介しました。マイクロサービスアーキテクチャーのシステムは、サービスごとの性能データを取得して、システム全体の動作状況を把握することが大切だと言われます。そういった性能把握のためのモニタリングが、まさにGoogle社内で実践されていることがご理解いただけたかと思います。
　次回は、Googleのデータセンターに導入された、最新のSDN（Software Defined Network）システムのアーキテクチャーに関する話題をお届けしたいと思います。

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