Google の未来であるマルチアーキテクチャに向けて AI と自動化がその実現を支援

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

Google 初の Arm® ベースのカスタム CPU である Google Axion プロセッサは、Google Cloud のお客様と Google のファーストパーティ サービスにパフォーマンスとエネルギー効率の両方を提供するうえで大きな一歩となります。Google Cloud の同等のインスタンスと比較して、費用対効果が最大 65% 向上し、エネルギー効率が最大 60% 向上します。

Google の本番環境サービスを実行して、Axion プロセッサをテストしました。クラスタに x86 マシンと Axion Arm ベースのマシンの両方が含まれるようになったことで、Google の本番環境サービスは複数の命令セット アーキテクチャ（ISA）でタスクを同時に実行できるようになりました。現在、これは x86 向けにコンパイルされるほとんどのバイナリを x86 と Arm の両方に同時にコンパイルする必要があることを意味します。Google の環境には 10 万を超えるアプリケーションが含まれていることを考えると、これは容易なことではありません。

Google は最近、移行プロセスに関するレポート「Instruction Set Migration at Warehouse Scale」のプレプリントを公開しました。このレポートでは、Google の巨大な monorepo である Google3 に対して行われた 38,156 件の commitを分析しています。簡単に言うと、このレポートでは、Google が今日に至るまでに使用した日頃の取り組み、自動化、AI の組み合わせについて説明しています。現在、YouTube、Gmail、BigQuery など、Google のサービスを Arm と x86 の両方で同時に本番環境で提供しています。また、30,000 を超えるアプリケーションを Arm に移行しています。Arm ハードウェアは完全にサブスクライブされ、毎月さらに多くのサーバーがデプロイされています。

Google をマルチアーキテクチャにするための取り組みの 2 つのステップを簡単に見てみましょう。1 つは移行パターンの分析、もう 1 つはコードの移植における AI の使用の検討です。詳細については、レポート全文をご覧ください。

Google のすべてのサービスをマルチアーキテクチャに移行

x86 のみから Arm と x86 への移行に際して、マルチアーキテクチャ チームとアプリケーション オーナーは、浮動小数点数のドリフト、並行性、プラットフォーム固有の演算子などの組み込み関数、パフォーマンスといったアーキテクチャの違いに時間を費やすことを想定していました。

最初に、F1、Spanner、Bigtable などの主要なジョブを、通常のソフトウェア プラクティスを使用して移行しました。週ごとにミーティングを行い、専任のエンジニアも配置しました。この初期段階で上記の問題の証拠が見つかりましたが、予想よりもはるかに少ないものでした。最近のコンパイラやサニタイザーなどのツールによって、予期せぬ事態はほぼ解消されています。その代わりに、大部分の時間を次のような問題の解決に費やしました。

• 既存の x86 サーバーに過適合したために失敗したテストを修正する

• 複雑なビルドシステムとリリース システムを更新する（通常は最も古く、トラフィックが最も多いサービスの場合）

• 本番環境構成でのロールアウトの問題を解決する

• 重要なシステムを不安定にしないように注意する

この方法で 12 個のアプリケーションを Arm に移行したところ、完全に機能しました。クラスタ管理システムである Borg でアプリケーションを実行できたことを誇りに思っています。あるエンジニアは次のように述べています。「誰もがまったく異なるツールチェーンに固執し、すべてが壊れるだろうと[想定]していました。難しさの大部分を占めたのは、構成と退屈な作業でした」

しかし、いくつかの大きなジョブを移行して終わりというわけではありません。実行中のコンピューティングの約 60% は上位 50 のアプリケーションにありますが、Google の monorepo 内の残りのアプリケーション全体の使用率の曲線は比較的平坦です。複数のアーキテクチャで実行できるジョブが多いほど、Borg がそれらをセルに効率的に適合させやすくなります。Arm サーバーを有効活用するには、残りの 10 万以上のアプリケーションの長いリストに対処する必要がありました。

マルチアーキテクチャ チームは、これほど多くのアプリケーション オーナーに効果的に連絡を取ることができませんでした。会議を設定するだけで膨大な費用がかかってしまいます。代わりに、自動化を利用することで、アプリケーション チーム自体の関与を最小限に抑えることができました。

自動化ツールマルチアーキテクチャへの移行を開始する前から Google で広く使用していたものを含め、自動化を支援するソースは多数ありました。これには次のものが含まれます。

• Rosie : プログラムで大量の commit を生成し、コードレビュー プロセスを管理できます。たとえば、ジョブのブループリントで Arm を有効にするための commit は、1 行で済みます。「arm_variant_mode = ::blueprint::VariantMode::VARIANT_MODE_RELEASE」

• サニタイザー とファザー : x86 と Arm の実行における一般的な違い（x86 の TSO メモリモデルによって隠されるデータ競合など）を検出します。このような問題を事前に検出することで、新しい ISA に再コンパイルする際に、デバッグが困難な非決定的な動作を回避できます。

• Continuous Health Monitoring Platform（CHAMP） は、マルチアーキテクチャ ジョブのロールアウトとモニタリングのための新しい自動化フレームワークです。クラッシュループやスループットの極端な低下など、Arm で問題を引き起こすジョブを自動的に削除し、後でオフラインでチューニングやデバッグを行えるようにします。

また、CogniPort という AI ベースの移行ツールの使用も開始しています。これについては後で詳しく説明します。

分析コード monorepo への 38,156 件の commit は、Bigtable のような大規模なジョブから無数の小さなジョブまで、ISA 移行プロジェクト全体の commit の大部分を占めていました。これらの commit を分析するために、commit メッセージとコードの差分を Gemini Flash LLM の 100 万トークンのコンテキスト ウィンドウに 100 件ずつ渡して、4 つの包括的なグループで 16 のカテゴリの commit を生成しました。

最終的なリストが完成したら、モデルを通じて commit を再度実行し、16 のカテゴリのいずれかを各 commit に割り当てました（さらに「未分類」カテゴリを追加して、外れ値を捕捉することで分類の安定性を向上させました）。

この分析では、合計で約 70 万行の変更されたコードが対象となりました。ISA の移行のタイムラインをプロットし、1 日または 1 か月あたりのコード行数が時間とともに変化する様子を正規化しました。

ご覧のとおり、マルチアーキテクチャ ツールチェーンの導入を開始したとき、最も多くの commit はツールとテストの適応に関するものでした。時間の経過とともに、移行した最初の数個の大きなアプリケーションに合わせて、コードの適応に関する commit の割合が大きくなりました。このフェーズでは、スケーリングの準備として、共有依存関係のコードを更新し、コードとテストの一般的な問題に対処することに重点を置きました。プロセスの最終フェーズでは、commit のほぼすべてが構成ファイルとサポート プロセスでした。また、この後半のフェーズでは、マージされた commit の数が急速に増加し、リポジトリ全体への移行のスケールアップが反映されていることがわかりました。

全体として、移行に関連するほとんどの commit は小規模であることに注意してください。最大の commit は、多くの場合、単一のファイルに対するより本質的な複雑さや複雑な変更を示すものではなく、非常に大きなリストや構成に対するものです。

AI を使用した ISA 移行の自動化

最新の生成 AI 手法は、ISA 移行プロセスの残りの部分を自動化する機会をもたらします。このギャップを埋めるために、CogniPort というエージェントを構築しました。CogniPort は、ビルドエラーとテストエラーに対応します。プロセスのどの時点でも、Arm ライブラリ、バイナリ、テストがビルドされない場合や、テストがエラーで失敗した場合は、エージェントが介入して問題を自動的に修正しようとします。最初のステップとして、CogniPort のブループリント編集モードを使用して、簡単な変更には適さない移行 commit をすでに生成しています。

エージェントは、以下に示す 3 つのネストされたエージェント ループで構成されています。各ループは LLM を実行して、推論の 1 ステップとツールの呼び出しを生成します。ツールが実行され、出力がエージェントのコンテキストにアタッチされます。

最も外側のエージェント ループは、ビルド修正エージェントとテスト修正エージェントの 2 つのエージェントを繰り返し呼び出すオーケストレーターです。ビルド修正エージェントは、特定のターゲットをビルドし、ターゲットが正常にビルドされるか、エージェントが中止するまで、ファイルを修正します。テスト修正エージェントは、特定のテストを実行し、テストが成功するか、エージェントが中止するまで修正します（その過程で、ビルド修正エージェントを使用してテストのビルドの失敗に対処する場合があります）。

CogniPort のテスト

CogniPort の使用を高レベルにスケールアップしたのはごく最近ですが、AI の支援なしで作成された上記のデータセットから過去の commit を取得して、その動作をより正式にテストする機会がありました。クリーンにロールバックできる（他のすべてのカテゴリがこのアプローチに適しているわけではありません）コードとテストの適応（カテゴリ 1～8）の commit に焦点を当て、245 件の commit のベンチマーク セットを生成しました。次に、commit をロールバックし、エージェントが commit を修正できるかどうかを評価しました。

特別なプロンプトやその他の最適化を行わなかったにもかかわらず、初期テストでは 30% の確率で失敗したテストを修正することに成功するという、非常に有望な結果が得られました。CogniPort は、テストの修正、プラットフォーム固有の条件、データ表現の修正に特に効果的でした。このアプローチのさらなる最適化に注力することで、より大きな成功を収められると確信しています。

マルチアーキテクチャの未来

ここから、自動化で対応すべきアプリケーションがまだ数万件あります。将来のコードの増加に対応するため、すべての新しいアプリケーションはデフォルトでマルチアーキテクチャになるように設計されています。今後も CogniPort を使用してテストと構成を修正し、アプリケーション オーナーと協力してより複雑な変更にも対応していきます（このプロジェクトの教訓の一つは、オーナーが自分のコードをよく知っている傾向があることです）。

ただし、Google の monorepo を本番環境サービス向けにアーキテクチャ ニュートラルに移行するという目標については、さまざまな理由から自信を深めています。

1. 本番環境サービスに使用されるすべてのコードは、巨大な monorepo で確認できます（現在も）。

2. マルチアーキテクチャ アプリケーションのビルド、実行、デバッグに必要な構造的変更のほとんどは完了しています。

3. Rosie のような既存の自動化や最近開発された CHAMP により、当社がほとんど介入することなく、リリースとロールアウトのターゲットを拡大し続けることができます。

4. 最後に、LLM ベースの自動化により、マルチ ISA Google フリートのアプリケーションの残りのロングテールの多くに対処できるようになります。

調査結果の詳細については、レポートをご覧ください。Google のチップ設計と、よりサステナブルなクラウドの運用方法については、g.co/cloud/axion で Axion についてお読みください。

このブログ投稿と関連するレポートは、非常に大規模なチームの作業を示すものです。このレポートは、Eric Christopher、Kevin Crossan、Wolff Dobson、Chris Kennelly、Drew Lewis、Kun Lin、Martin Maas、Parthasarathy Ranganathan、Emma Rapati、Brian Yang が、Arm の移植作業に取り組む数十名の Google 社員と共同で執筆しました。

-バイス プレジデント / エンジニアリング フェロー、Parthasarathy Ranganathan

-デベロッパー リレーションズ エンジニア Wolff Dobson