コンテンツに移動
Containers & Kubernetes

分散 Ray クラスタに gVisor サンドボックスを導入

2026年9月4日
Andrew Sy Kim

Staff Software Engineer, Google

Philipp Moritz

Chief Technology Officer, Anyscale

Gemini を今すぐお試しください

職場での AI 活用、その入り口に

今すぐ試す

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

強化学習(RL)のエコシステムでは、複雑なトレーニング後のワークフローを支える統合コンピューティング ランタイムとして、Ray の採用が急速に進んでいます。Google Cloud のお客様も、マルチモーダル データ パイプラインから最先端の RL まで、さまざまなワークロードに Ray を活用しています。しかし、エージェント モデルと推論モデルが進化するにつれて、重大な課題が浮き彫りになってきています。それは、動的なロールアウト、コード生成、マルチターンのツール操作を安全に実行するために、安全で分離されたサンドボックスを大規模にオーケストレートすることです。このたび、Anyscale とのパートナーシップによる Ray の試験運用版ライブラリを導入いたします。このライブラリは、Google で開発中のエージェント型 AI テクノロジーを活用して、ネイティブで高性能なサンドボックス環境を分散 Ray クラスタに直接提供するものです。

Ray プリミティブとしてのサンドボックス

Ray は、トレーニング後のワークロードをオーケストレートするための標準的なランタイムとして定着しています。veRL、NeMo-RL、SLIME、MILES、SkyRL などのフレームワークは、すでに Ray を使用して分散トレーナー、推論エンジン、ロールアウト ワーカーなどのコンポーネントを調整しています。

Ray サンドボックスの設計において重要な目標としたのは、隔離された実行のために新たな抽象化を導入するのではなく、既存の Ray プログラミング モデルに自然に馴染む形にすることです。サンドボックスは、Ray が管理する他のリソースと共通する特性を多く備えています。具体的には、マシンへの配置や、リソースの割り当て、作成と破棄、障害からの復旧、周囲のワークロードに応じたスケーリングなど、他のリソースと同様の管理が求められます。こうした背景から、各ハイレベル サンドボックスを Ray アクターとして表現する手法を採用しました。

https://storage.googleapis.com/gweb-cloudblog-publish/images/image1_SrQumpQ.max-1500x1500.png

Ray スケジューラは、どのノードでサンドボックスを実行するかを決定し、対応する CPU とメモリリソースを予約します。サンドボックス アクターが自身のライフサイクルを管理する一方で、gVisor はそのノード上で隔離された実行環境を提供します。

Ray 2.58 以降では、フレームワークの作成者と研究者は、他のワークロードで使い慣れた Ray API やパターンをそのまま使用して、サンドボックス環境を管理できます。以下にその例を示します。

読み込んでいます...

これにより、OCI 互換イメージから gVisor サンドボックスが作成され、Ray アクターのハンドルが返されます。exec の呼び出しは通常の Ray アクター呼び出しと同じであるため、サンドボックスはクラスタ内のどこにでも配置できます。作成されたアクターは、オペレーションを gVisor に転送するプロキシです。

サンドボックス API は、エージェント型ワークロードに必要な基本的なライフサイクル管理に対応しています。

  • OCI コンテナ イメージから環境を作成する

  • CPU とメモリの上限を設定する

  • 環境変数、作業ディレクトリ、ネットワーキングを構成する

  • コマンドを実行する

  • ファイルの読み取り、書き込み、アップロード、ダウンロードを行う

  • サンドボックスの状態を検査する

  • 環境を終了または削除する

さらに詳細な制御が必要な場合は、SandboxRuntime を使用してローカルの gVisor サンドボックスを直接操作できます。これにより、gVisor に引き渡す前の OCI 仕様をユーザー側で編集できるようになります。この API を使用してアクター内にローカル サンドボックスのプールを構築する方法を以下に示します。

読み込んでいます...

gVisor を選ぶ理由

モデルが生成したコードを実行する際は、その環境内のコードを「信頼できないもの」として扱う必要があります。Ray サンドボックスは、Google のオープンソース アプリケーション カーネルである gVisor を初期サンドボックス ランタイムとして使用します。gVisor は、Linux システムコール インターフェースの大部分をユーザー空間に実装し、ワークロードとホストカーネルの間に、さらなる分離境界を追加します。OCI 互換で、標準のコンテナ イメージをそのまま利用でき、Docker デーモンやホスト Docker ソケットをサンドボックスに公開する必要もありません。

この組み合わせは、エージェント型ワークロードに非常に適しています。環境を動的に作成できるほど軽量に保ちながら、生成されたコードを通常のコンテナで直接実行するよりも強力な隔離環境を実現できるからです。gVisor は 1 秒未満の高速起動と低メモリ オーバーヘッドを両立しているため、サンドボックスを粒度の細かい分散リソースとして柔軟に活用できます。

Ray の今後のバージョンでは、Agent Substrate や Kata Containers といった他のサンドボックス ランタイムにもサポートを拡大していく予定です。

GKE で Ray サンドボックスを試す

Ray サンドボックスの詳細は、Ray のドキュメントでご確認いただけます。GKE でこれらのサンドボックス機能を試すには、Ray サンドボックスのユーザーガイドをご参照ください。フィードバックやアイデアがございましたら、GitHub の issue でディスカッションにぜひご参加ください。強化学習における Ray の未来を一緒に考えていきましょう。

- Google、スタッフ ソフトウェア エンジニア、 Andrew Sy Kim

- Anyscale、最高技術責任者、Philipp Moritz 氏

投稿先