GKE Agent Substrate について

Agent Substrate は、Kubernetes クラスタでエージェント ワークロードを大規模に実行します。これは、一般的なリソースの非効率性に対処するものです。インタラクティブ エージェント（パーソナル アシスタントやコーディング エージェントなど）は、ユーザー入力や外部トリガーを待つ時間がほとんどです。これらの非アクティブなエージェントを継続的に実行すると、アクティブなワークロードに割り当てられるはずの CPU とメモリが使用されます。

Agent Substrate は、アイドル状態のエージェントを一時停止し、エージェントのアクティブ メモリ（RAM）とローカル ファイルのスナップショットを取得することで、この問題を解決します。一時停止されたエージェントが再び動作する必要がある場合、システムは 1 秒以内にエージェントの状態を利用可能なサンドボックスに復元します。

Agent Substrate は Agent Sandbox の機能をベースに構築されており、標準の Kubernetes コントロール プレーンのボトルネックを回避することで Agent Sandbox を改善しています。その結果、マシンあたりの同時エージェント数が大幅に増加し、エージェントの起動時間が大幅に短縮されます。

標準の Kubernetes デプロイ（Agent Sandbox を含む）では、各エージェント ワークロードが専用の Pod に関連付けられます。Kubernetes はスケーラビリティが高いですが、Pod のスケジューリング スループットと起動レイテンシによって制約されます。また、Kubernetes は Pod の休止状態をサポートしていません。クラスタ内に数百万ものアイドル状態のエージェントを保持すると、Pod の上限とコントロール プレーンのメモリが枯渇します。アイドル状態のコンピューティングに対する料金の支払いを避けるには、Pod をシャットダウンし、外部ストレージでエージェントの状態を管理する必要があります。Agent Substrate は、エージェントの状態を基盤となる Pod から切り離すことで、これらのスケーリング制約を解決します。何百万もの一時停止されたエージェント スナップショットをストレージに保存し、オンデマンドでウォーム ワーカーの共有プールに復元します。

Agent Substrate は、独自の GKE Standard クラスタに直接デプロイするオープンソース システムです。コア プロジェクトはオープンソースの Agent Substrate リポジトリで開発されていますが、Google は、対象となる Google Cloud お客様向けに、GKE 向けに最適化されたデプロイ ツールとスクリプトを substrate-gke リポジトリで提供しています。

Agent Substrate のメリット

Agent Substrate を使用すると、次の目標を達成できます。

  • 信頼できないコードを安全に実行する: Agent Substrate は、カーネルとネットワークの分離を強制するため、広範なインフラストラクチャを危険にさらすことなく、AI 生成コードを実行できます。
  • 長時間実行されるステートフル エージェントを構築する: エージェントのワーキング メモリとファイルがセッション間で保持されます。エージェントは、一時停止した正確なポイントから再開します。
  • リクエストにリアルタイムで応答する: 新しいリクエストによって一時停止中のエージェントがトリガーされると、システムはエージェントの状態を瞬時に復元します。
  • コンピューティング費用を削減する: すべてのエージェント間でワーカー サンドボックスのプールを共有することで、より少ないマシンでより多くのエージェントを実行できます。アイドル状態のエージェントは一時停止され、CPU とメモリを使用しないため、エージェントがタスクをアクティブに処理している場合にのみコンピューティングの料金が発生します。

ユースケース

Agent Substrate は、数十から数百万の同時エージェントまで、あらゆる規模でエージェントを実行するように設計されています。ワークロードの例を 3 つ示します。

  • 生産性エージェント: 数週間にわたってコンテキストを維持する長期的なバックグラウンド アシスタント。これらのアシスタントはトリガーを待機している時間が長いため、使用していないときにワークロードを一時停止すると、コンピューティング費用を削減できます。
  • エフェメラル サンドボックス: 信頼できない LLM 生成コードの実行、ツール呼び出しの実行、データの分析を行うためのオンデマンドの分離環境。サンドボックスは 1 秒以内に復元されるため、システムは短期間のタスクに使い捨て環境を提供し、実行が終了するとリソースを解放できます。
  • コーディング エージェント: 開発者とリアルタイムで会話して、コードの作成、ビルド、テストを行う AI アシスタント。エージェントは、ターミナル コマンドを実行し、サンドボックス内のファイルを変更します。エージェントがアイドル状態になると、デベロッパーが別のプロンプトを送信するまでシステムはエージェントを一時停止します。

Agent Substrate の仕組み

Agent Substrate は Kubernetes 上に構築されていますが、使用するために Kubernetes を理解する必要はありません。Agent Substrate の基本コンセプトは次のとおりです。

  • アクター: エージェントの単一の実行インスタンス。
  • ActorTemplate: アクターのインスタンス化に使用される構成ブループリント（コンテナ イメージ、環境変数、コンピューティング リソースを定義します）。
  • ワーカー: アクティブなアクターが実行される安全なサンドボックス。
  • WorkerPool: アクターを受け取る準備ができている、事前に開始されたアイドル状態のワーカーのグループ。

アクターは特定のワーカーに関連付けられていないため、システムはアイドル状態のエージェントを一時停止し、解放されたコンピューティングを再利用できます。このアーキテクチャにより、システムは限られた数のマシンで数百万のエージェントを実行できます。

一般的なエージェントのライフサイクルは次の手順で構成されます。

  1. ルーティング: アプリケーションからの各受信 API リクエストは、ターゲット アクターを指定します。たとえば、ユーザーがチャット インターフェースに新しいプロンプトを入力すると、アプリはユーザーのセッションを管理する特定の Actor にリクエストを送信します。
  2. 再開: リクエストが一時停止中のアクターに対するものである場合、システムは WorkerPool からウォーム ワーカーを要求し、そのワーカーにアクターのスナップショットを復元します。
  3. 実行中: システムはリクエストをこの新しくアクティブになった Worker にルーティングし、Actor がタスクを処理します。
  4. 一時停止: アクターが作業を完了してアイドル状態になると、システムはアクターのメモリとファイルの新しいスナップショットを取得し、スナップショットをストレージに保存して、空のワーカーをプールに戻します。

ワークロードの分離と GKE Sandbox

Agent Substrate は gVisor または Cloud Hypervisor を使用して、アプリケーション コードをホストカーネルから分離するサンドボックスで各ワークロードを実行します。Agent Substrate のインストールにはワーカー用の gVisor ランタイムが含まれているため、基盤となる GKE ノードで GKE Sandbox を構成する必要はありません。

制限事項と要件

Agent Substrate には、次の制限と要件があります。

  • クラスタ バージョンとベータ版 API: Agent Substrate は、バージョン 1.36（ベータ版フラグが有効）またはバージョン 1.37 以降を実行している GKE Standard クラスタでサポートされています。1.36 より前のバージョンはサポートされていません。また、GKE では、クラスタの作成時にベータ版 API（podcertificaterequests と clustertrustbundles）を有効にする必要があります。既存のクラスタでこれらの API を有効にすることはできません。
  • Workload Identity Federation for GKE: GKE クラスタで Workload Identity Federation for GKE が有効になっている必要があります。Agent Substrate は、Workload Identity Federation for GKE を使用して、エージェント スナップショットの保存用の Cloud Storage などのGoogle Cloud API に対する認証を行います。
  • VM ファミリー:
    • 混合 CPU アーキテクチャ: gVisor の既知の問題により、Agent Substrate は混合 CPU アーキテクチャ（E2 マシンタイプなど）で実行される汎用マシンシリーズをサポートしていません。
    • アクター テンプレートごとの均一な VM タイプ: 単一の ActorTemplate（アクターの作成に使用される構成ブループリント）内で VM タイプを混在させることはできません。たとえば、クラスタに C4 VM と N2 VM を使用する 2 つのノードプールがある場合、そのテンプレートの Actor が異なるマシンタイプに分割されないように、ActorTemplate には単一の VM タイプ（C4 など）を指定するノードセレクタを含める必要があります。
  • GPU のサポート: アクター コンテナへの GPU デバイス パススルーはサポートされていません。nvidia.com/gpu を指定すると、Pod は GPU 対応ノードにのみ配置されますが、GPU デバイスは Actor コンテナに渡されません。また、gVisor はライブ CUDA コンテキストのスナップショットを作成できません。
  • ネットワーキング:
    • 下り（外向き）ポリシー: EgressPolicy ルール（ホスト名と IP アドレスによるネットワーク制御）はサポートされていません。これには、次の機能が含まれます。
      • デフォルトの拒否ルール
      • ホスト名ベースのルール
      • 認証情報の挿入
    • 開いている接続: エージェントが一時停止すると、開いているネットワーク接続（データベース セッションや MCP サーバーへの接続など）は保持されません。エージェントが再開されたときに外部サービスに再接続する処理は、エージェント コードで行う必要があります。
  • オブザーバビリティとマネージド OpenTelemetry: GKE 用マネージド OpenTelemetry には次の制限事項があります。
    • GKE 用マネージド OpenTelemetry はプレビュー版です。
    • コレクタ コネクタはサポートされていません。このため、テレメトリー ベンチマークには外部プロキシ メーターを使用する必要があります。
    • コレクタのデプロイでは、大規模なクラスタ内の Pod の数に応じて線形にスケーリングされるメモリ キャッシュ オーバーヘッドが発生します。
    • Managed OpenTelemetry for GKE では TLS はサポートされていません。
  • ストレージ: エージェントのスナップショットを保存するには、Cloud Storage が必要です。
  • インストール環境: Cloud Shell に Agent Substrate をインストールすることはできません。Cloud Shell の永続ディスク ストレージの上限は 5 GB であり、インストールに必要なディスク容量が不足しています。Agent Substrate は、十分なディスク容量があるローカル ワークステーションまたは仮想マシン（VM）からインストールする必要があります。

次のステップ