システム

How Google Does It: フリート全体での大規模な A/B テスト

2026年5月27日

Nilay Vaish

Software Engineer

Xiaoyu Chen

Software Engineer

Try Gemini Enterprise Business Edition today

The front door to AI in the workplace

Try now

※この投稿は米国時間 2026 年 5 月 19 日に、Google Cloud blog に投稿されたものの抄訳です。

A/B テストと聞くと、ボタンの色、ランディングページのレイアウト、購入手続きのフローを思い浮かべる人がほとんどでしょう。Google では、多くの基本的なインフラストラクチャの改善にも、A/B テストの厳密さが求められます。メモリアロケータやカーネルスケジューラを最適化することで、コンピューティングリソースを大幅に節約し、何百万人ものユーザーのレイテンシを短縮できます。しかし、このような重大な変更の検証には本質的にリスクが伴います。カーネルのアップデートにバグがあれば、単にユーザーの不満を招くだけでなく、広範囲のマシンを停止させてしまう恐れがあるからです。安全かつ大規模にイノベーションを行うには、インフラストラクチャ自体で A/B テストを実施する必要があります。

このブログ投稿では、Google が長年にわたって改良してきた A/B テスト手法から得られた主な教訓をまとめています。このブログ投稿は、参考となるベストプラクティスを提示し、このトピックに関する幅広い議論を促すためのリソースとなることを目的としています（パフォーマンスに関するヒントのシリーズと同様）。具体的には、Google の A/B テストインフラストラクチャの 4 つの柱に焦点を当てています。

アプリケーションレベルとマシンレベルのテスト
バランスの取れた設定を維持する
バイナリの密閉性を確保する
適切なパフォーマンス指標を選択する

次のセクションでは、これらの側面が重要である理由と、Google がどのように対処してきたかについて説明します。

インフラストラクチャのテストが重要な理由

オペレーティングシステム、コアライブラリ、コンパイラ、クラスタ管理システムなど、スタックのコア構成要素を対象としたテストは、アプリケーションのテストだけでは達成できないパフォーマンスと効率の向上を引き出すのに役立ちます。これらのテストは、フリートの代表的なサブセットを使用して、大規模な影響を測定する信頼性の高い安全な方法を提供します。これにより、どの最適化が有益であるかを判断できます。

Google では、次の特定のコンポーネントを最適化することに高い価値を見出しています。

コアライブラリ: TCMalloc などのコアライブラリを最適化すると、フリートで実行されるすべてのバイナリに大きな影響が及びます。
コンパイラ: さまざまなコンパイルフラグやビルドフラグを調整することで、ソースコードを 1 行も変更することなく、フリート全体のパフォーマンスを向上させることができます。
カーネル: メモリ管理やスケジューリングなどのカーネルサブシステムを改善することで、フリート全体のマシンの効率を劇的に向上させられるだけでなく、大規模なリグレッションの発見にも役立ちます。
クラスタ管理システム: kube-scheduler や kubelet などのエンティティによる決定は、局所性や干渉に大きな影響を及ぼし、それがひいてはクラスタの使用率やパフォーマンスを左右します。

改善の規模

たとえば、メモリアロケータ全体を書き換えて効率を 2 倍にするなど、大きな改善をもたらす変更は簡単に測定できます。しかし、Google の規模では、インフラストラクチャの改善の多くは実際にははるかに小さく、通常は 1% 未満の改善です。個々の変更は些細なものに見えるかもしれませんが、小さな最適化を絶え間なく積み重ねていくことで、時間が経つにつれてムーンショット級の大きな成果をもたらします。

1% 未満の成果を達成するには、テストと測定について慎重に検討することが求められます。そのため、A/B テストを確実に実施し、小さな変更の影響を測定するための堅牢なフレームワークを構築しました。

アプリケーションレベルのテストの限界

インフラストラクチャの変更を評価するには、特定のアプリケーションセットで変更を有効にして、指標の推移を観察します。しかし、このアプリケーション中心のアプローチには、次のような重大な欠点がいくつかあります。

選択バイアス: 個々のアプリケーションが、特定の変更を評価するのに適していない場合があります。たとえば、起動時にのみメモリを割り当てるアプリケーションは、メモリ割り当てライブラリの更新をテストするのに適していません。
フリートの代表性の欠如: 少数のアプリケーションだけでは、フリート全体の挙動を反映することはほとんどなく、改善の可能性の推定が不正確になります。
システム全体の目に見えないメリット: 個別のアプリケーションを測定しても、付随的な効果は把握できません。たとえば、ハードウェアキャッシュのパフォーマンスを向上させる変更は、測定対象のアプリケーションだけでなく、マシン上で実行されているすべてのアプリケーションにメリットをもたらす可能性があります。
技術的な制約: カーネルやクラスタスケジューラなど、システムの根本的な変更は、個々のアプリケーションだけでは効果的に評価できません。

Google のアプローチ: マシンレベルのテスト

Google では、特定のアプリケーションではなく個々のマシンに変更を適用することで、こうしたハードルを克服しています。選択したマシンで実行されているすべてのワークロードに変更が反映されるため、フリート全体にわたる影響を測定できるようになります。このアプローチでは、同じマシン上に配置されたすべてのアプリケーションへの付随的な影響を捉えることができ、アプリケーションレベルのテストでは見逃されてしまうようなシステム固有の変更も評価が可能になります。

Google におけるインフラストラクチャテスト

一般的なテストでは、テストグループとコントロールグループのそれぞれに、フリートの 1% を選択します。その後、社内のベストプラクティスに従い、複数のウェーブに分けて段階的にテストがロールアウトされます。ロールアウト中、フレームワークは両方のグループのデータ収集を開始します。これらのデータは継続的に分析され、パフォーマンスへの影響の測定や、本番環境でのリグレッションの検知に役立てられます。

https://storage.googleapis.com/gweb-cloudblog-publish/images/infrastructure_experiment_process.max-2000x2000.png

バランスの取れた設定の重要性

インフラストラクチャのテストの有効性は、マシンの選択方法によって決まります。マシンフリートの代表的なサブセットをそれぞれ対象とする、バランスの取れたテストグループとコントロールグループが必要です。Google のフリートには、さまざまなマシンタイプがあります。テストグループとコントロールグループにおけるこれらのマシンタイプの割合が、ほぼ一致している必要があります。テストグループとコントロールグループのマシンタイプが 2 つのクラスタで一致しなかっただけで、0.2 ～ 0.3% のデータスキューが発生しました。改善率が 1% 未満の場合、これだけで結果が無効になってしまいます。

テストグループとコントロールグループが大きすぎると、インフラストラクチャ全体の信頼性が損なわれるリスクがあります。また、統計的に有意なデータが得られないほど小さくてもいけません。Google では、フリート全体の 1% のサブセットが最適なバランスであると結論付けました。

実装上は、各クラスタ内のさまざまな世代のマシンの構成比を反映させた、フリートの 1% のサブセットを抽出しています。これらのサブセットはすべて互いに完全に同等であり、マシンの入れ替わりを抑えるために、線形計画法を用いて定期的にリバランスされています。テストをデプロイする際は、テストグループとコントロールグループとして機能する 2 つのサブセットが選択されます。両方のグループが同じペースでロールアウトされるため、いつでもバランスの取れた A/B 分析を実行できます。

バイナリの密閉性による信頼性の確保

ライブラリの動作を変更するテストの場合、バイナリはテスト用のライブラリの変更を反映して再コンパイルする必要があります。重要なのは、テストロジックが、バイナリがテストグループのマシンで実行されている場合にのみ有効になることです。

Google のテストフレームワークには、テストのロールバックをシンプルかつ確実に実行できるように設計された重要な安全要件が含まれています。個々のバイナリの動作を変更するテストは、2 段階のロールアウトプロセスに従う必要があります。

まず、テストグループとコントロールグループのすべてのマシンに、テストがロールアウトされます。
そうして初めて、テスト用のライブラリの変更をサブミットします。これにより、新しくコンパイルされたバイナリがテストマシンにデプロイされた際に、テストが有効になります。

このシーケンシャルなアプローチにより、挙動の変化をバイナリのリリースに簡単に紐付けることができます。さらに重要なこととして、バイナリを以前のバージョンに安全かつ即座にロールバックすることで、テストを確実に元に戻すことができます。

このルールに従わないとどうなるのでしょうか。テストが原因で本番障害が発生した場合、そのデバッグや影響の緩和が極めて困難になります。テストを完全に削除するには、マシンをロールバックし、影響を受けるすべてのバイナリを再起動する必要があります。この遅延により、障害の影響緩和が大幅に遅れ、さらに大きな被害を招く恐れがあります。

リスクを具体的に説明するために、コアライブラリの最適化テストを実施したところ、散発的なメモリ破損が発生した場面を想定してみましょう。上記のロールアウト手順を逆にすると、マシンレベルのロールアウトが開始される前に、新しくビルドされたバイナリにテスト用の変更が含まれることになります。テストがまだ有効になっていないため、オーナーはこれらのバイナリが安全であると思い込んでしまう可能性があります。しかし、マシンのロールアウトが開始されると、ライブラリの変更後にビルドされたバイナリのみでメモリ破損が発生し、他のバイナリでは発生しません。このように障害が段階的に発生すると、テストを根本原因として切り分けることが極めて難しくなります。オーナーがバイナリの以前のバージョンにロールバックしようとしても、破損は解消されず、インシデント対応の有効性が損なわれます。メモリ破損の突発的な発生と、適切なバイナリのバージョンを特定するために必要な手間が、デバッグをさらに困難にします。

重要な指標の測定

インフラストラクチャのテストでは、クリック率を重視しません。クリック率を短期的に高めることは、長期的なエンゲージメントを犠牲にする可能性があるからです。代わりに、アプリケーションとマシンのパフォーマンスと健全性を重視しており、具体的には以下の指標で測定します。

アプリケーションの生産性: Google 社内では、パフォーマンスを正確に測定するための最適な指標について議論しました。マルチプロセッサ / マルチプログラムワークロードにおいて、サイクルあたりの命令数（IPC）は適切な指標ではないことが学術界ではよく知られています。代わりに、アプリケーションによって行われた作業量を把握する、アプリケーション定義の堅牢な生産性指標を採用しました。たとえば、検索ウェブサーバーは、1 秒あたりに完了した検索クエリの数を生産性指標として報告します。
マシンレベルのパフォーマンス: アプリケーションの生産性をゴールドスタンダードとしつつ、IPC、キャッシュミス、メモリ帯域幅などの他の指標も測定することで、パフォーマンスの向上を裏付けています。
信頼性: 異常終了やマシンのタイムアウトなど、複数の信頼性指標を追跡しています。新しいカーネルは高速化されるかもしれませんが、それによって新たにクラッシュが発生するようであれば、失敗とみなされ、修正が必要です。

これらの指標は、フリート内のすべてのマシンのすべてのアプリケーションから定期的に収集されます。

統計ツール

テストを実施してデータを収集することは、最適化の評価プロセスの半分にすぎません。大きな課題は、収集したデータを分析し、完全なロールアウトの前に、変更がフリートに与える真の影響を理解することにあります。Google のデータセンターでは、常に数千ものジョブが実行されており、1 つの変更がジョブのパフォーマンスにさまざまな影響を及ぼします。さらに、わずか数件のジョブの結果だけに基づいて、適切な判断を下すことは不可能です。この問題を克服するために、Google は高度な統計ツールを開発しました。このツールは、テストグループで実行されているジョブを、コントロールグループの同等のジョブと綿密に照合します。次に、これら照合されたペアの指標を比較し、すべてのジョブの結果を集計することで、フリート全体に関する信頼性の高い指標を算出します。この比較は数週間にわたるデータを使用して行い、日々の変動によって分析結果に歪みが生じないようにしています。

さらに、A/A テストのデータを定期的に分析することで、日々の変動によって生じるばらつきを把握しています。これらの A/A テストのデータは、「ノイズフロア」を確立するために使用されます。このノイズフロアを有意に上回る結果をもたらす変更のみが、信頼性が高く、ロールアウトする価値があると見なされます。

まとめ

クラウドインフラストラクチャが拡大し続ける中、リソースから最大限の効率を引き出すことは、もはや単なる利点ではなく、持続可能な費用管理に不可欠です。こうした効率化の需要に応えるには、新しい最適化を検証するための厳格なデータドリブンアプローチが必要であり、フリート全体にわたる堅牢な A/B テストインフラストラクチャが不可欠となります。しかし、これには構成管理、信頼性、統計分析など、大きな課題が伴います。これらの課題は、Google の環境だけに特有のものではありません。Google が構築したインフラストラクチャについて公開することで、研究とコラボレーションの新たな波を起こすことを目指しています。苦労して得た教訓を共有することが、以下のことにつながることを願っています。