Rayサンドボックスの試験運用版、分散RayクラスタでgVisor隔離環境を提供

Google Cloud blogは、Anyscaleとのパートナーシップによる試験運用版ライブラリとして、Rayサンドボックスを紹介しました。ライブラリは、Googleで開発中のエージェント型AIテクノロジーを活用しています。gVisorによる隔離環境を備えたサンドボックスを、分散Rayクラスタへ直接提供するものです。

原記事は、米国時間2026年8月26日にGoogle Cloud blogへ投稿された記事の抄訳です。Ray 2.58以降では、使い慣れたRayのAPIやパターンでサンドボックス環境を管理できると説明しています。記事末尾には、GoogleのAndrew Sy Kim氏とAnyscale最高技術責任者のPhilipp Moritz氏の名前が記されています。

モデルが生成したコードを分散Rayクラスタ上で隔離して動かしたい場合は、原記事が示す設計とgVisorの位置付けが判断材料です。本記事では、既存のRayコードへの組み込みやGKEで試す前の確認点を知りたい場合を想定し、原記事の各論点と補足資料の記述を整理しました。

元記事：分散 Ray クラスタに gVisor サンドボックスを導入（Google Cloud blog日本語版）https://cloud.google.com/blog/ja/products/containers-kubernetes/gvisor-sandboxes-for-ray-clusters-on-gke 該当節：記事全体

原記事は、強化学習のエコシステムで、トレーニング後のワークフローを支える統合コンピューティングランタイムとしてRayの採用が急速に進んでいると述べています。Rayはトレーニング後のワークロードをオーケストレートする標準的なランタイムとして定着しているとの見方も示しました。

原記事によると、Google Cloudのお客様はマルチモーダルデータパイプラインから最先端のRLまで、さまざまなワークロードにRayを活用しています。Rayサンドボックスの発表は、エージェントモデルと推論モデルの進化で浮かんだ、分離環境を大規模に扱う課題へ向けたものです。主な点を一覧にし、続く表で項目ごとに整理します。

• Anyscaleとのパートナーシップによる試験運用版ライブラリ
• 各サンドボックスをRayアクターとして表現
• 初期のサンドボックスランタイムはgVisor
• Ray 2.58以降はRayのAPIやパターンで管理
• Agent SubstrateやKata Containersは今後のバージョンで対応予定

以降では、原記事の論点と、補足として参照した開発版ドキュメントの記述を5つの観点に分けて取り上げます。原記事はモデル生成コードを信頼できないものとして扱う必要があると述べています。そこで、設計と隔離の根拠を先に扱い、試す前の条件と既定の隔離設定、今後の対応へ進む順にしました。

難易度は、原記事の説明だけで理解できる内容を基礎、Rayの基本的な使い方の知識が要る内容を中級としました。上級はクラスタ運用や隔離技術の知識が要る内容です。緊急度は、試す前に確認が要るものを高、導入検討時に確認するものを中、必要になったときに確認するものを低としています。

原記事は、Rayサンドボックスの設計目標を、新しい抽象化を加えず既存のRayプログラミングモデルに馴染ませることだと説明しています。サンドボックスには配置や資源割り当て、作成と破棄、障害復旧やスケーリングの管理が要るため、Rayアクターとして表現されました。

役割の分担も示されています。Rayスケジューラが実行ノードを決めてCPUとメモリを予約し、サンドボックスアクターがライフサイクルを管理し、gVisorがノード上の隔離環境を提供します。

sandbox.createの呼び出し

原記事がRay 2.58以降の例として示したコードでは、sandbox.createでCPUとメモリとイメージを指定します。返ったハンドルのexec.remoteでコマンドを実行し、ray.getで結果を受け取る流れです。

原記事によれば、作成されるのはgVisorへ操作を転送するプロキシのアクターです。execは通常のアクター呼び出しと同じため、サンドボックスはクラスタ内のどこにでも配置できます。

サンドボックスAPIが対応する基本的なライフサイクル管理として、原記事は次の操作を挙げました。

• OCIコンテナイメージからの環境作成
• CPUとメモリの上限設定
• 環境変数や作業ディレクトリ、ネットワーキングの構成
• コマンドの実行
• ファイルの読み取り、書き込み、アップロード、ダウンロード
• サンドボックスの状態の検査
• 環境の終了または削除

SandboxRuntimeの直接操作

さらに細かい制御が必要な場合は、SandboxRuntimeでローカルのgVisorサンドボックスを直接操作できます。原記事は、gVisorに渡す前のOCI仕様をユーザー側で編集できると説明しています。

原記事のプール例では、アクター内でSandboxRuntimeのcreateを呼んで複数のサンドボックスを作ります。closeメソッドの中では、各サンドボックスに対してdeleteを呼んでいます。

プール例のSandboxPoolは、既定でsize=3とimage="python:3.10-slim"を受け取り、各サンドボックスをmemory="512Mi"で作成します。run_commandはindexでプール内の対象を選び、選んだサンドボックスとコマンドをSandboxRuntimeのexecへ渡します。

使用例では、SandboxPool.remote(size=3)でアクターを作ります。ray.getでpool.run_command.remoteの結果を受け取り、stdoutを表示します。最後にray.get(pool.close.remote())でcloseを呼び出しています。

組み込みを検討する場合は、スケジューラが予約する資源を踏まえてCPUとメモリの指定値を確認するとよいでしょう。高レベルのsandbox.createで足りるか、OCI仕様を編集したいかで、使うAPIを選べます。

開発版のAPIリファレンスには、作成の失敗やタイムアウトで送出されるSandboxCreationErrorなどの例外が並んでいます。実行や操作のタイムアウトにはSandboxTimeoutErrorが用意されていると記載されています。

原記事は終了や削除の操作と、closeでdeleteを呼ぶ例を示すにとどまります。呼び出し後に資源がどう解放されるかや失敗時のふるまいは、原記事の記述だけでは判断できません。

Rayサンドボックスは、GoogleのオープンソースのアプリケーションカーネルであるgVisorを初期サンドボックスランタイムに使います。原記事は出発点として次のように述べています。

モデルが生成したコードを実行する際は、その環境内のコードを「信頼できないもの」として扱う必要があります。

出典:Google Cloud 分散 Ray クラスタに gVisor サンドボックスを導入

gVisorはLinuxシステムコールインターフェースの大部分をユーザー空間に実装し、ワークロードとホストカーネルの間に分離境界を加えます。OCI互換で標準のコンテナイメージを使え、DockerデーモンやホストのDockerソケットをサンドボックスへ公開する必要もありません。

原記事は、gVisorとの組み合わせがエージェント型ワークロードに非常に適していると評価しました。動的に環境を作れる軽さを保ちつつ、通常のコンテナで直接実行するより強力な隔離を実現できるという理由です。

gVisorは1秒未満の起動と低いメモリオーバーヘッドを両立するとされます。原記事は、その特性によりサンドボックスを粒度の細かい分散リソースとして柔軟に活用できると述べています。

起動時間の数値は資料によって異なります。開発版のKubeRay向けガイドは、RayワーカーPod内でgVisorを直接動かす構成について、100ミリ秒未満の起動遅延と記述しています。

隔離方式を比較する場合は、どの資料のどの構成についての数値かを分けて扱うと混同を避けられます。自身の環境での起動時間は、実際に計測して確かめてください。

隔離の強さや起動時間の評価は、原記事の筆者による説明です。隔離の強さは、通常のコンテナで直接実行する場合と比べた形で述べられています。

原記事は、Ray 2.58以降でサンドボックス環境を管理できると説明し、ライブラリを試験運用版と位置付けています。GKEで試す場合はRayサンドボックスのユーザーガイドを、詳細はRayのドキュメントを参照するよう案内しました。

本記事では補足として、Rayの開発版（master）ドキュメントを確認日時点の内容で参照しました。KubeRay向けのガイドはGKEを例にしつつ、同じ原則が他のKubernetesディストリビューションにも当てはまると述べています。

開発版ドキュメントはray.experimental.sandboxをアルファ版のライブラリとしています。安定版になる前のリリースでAPIが変わったり無くなったりする可能性があるとの警告です。

開発版ガイドが挙げる前提条件は次のとおりです。

• kubectlの導入とKubernetesクラスタへのアクセス設定
• gcloud CLIの導入とGoogle Cloudプロジェクトへの認証
• Helm v3の導入
• ray.experimental.sandboxを含むRay 2.58.0以降

開発版ガイドでは、gVisorがRayコンテナのプロセス内でrootlessのユーザー空間として動くため、containerdを使う標準のGKEノードプールを使えるとしています。例のRayClusterは、gVisorに必要なsecurityContextを付けて起動時にrunscを導入する構成です。

runscはRayワーカーコンテナの$PATHに置く必要があります。例ではPod起動時にrunscを取得しますが、本番ではコンテナイメージへの事前導入を勧めています。

試す前には、利用するRayが2.58以降かを確かめてください。参照するドキュメントの版が、導入予定のRayの版と合っているかも見ておくと安心です。

原記事が案内するユーザーガイドが、本記事で参照した開発版ページと同一かどうかは原記事の記述からは判断できません。試験運用版が正式版になる時期も、原記事には示されていません。

原記事によるとRayサンドボックスのAPIでは、CPUとメモリの上限を設定でき、環境変数や作業ディレクトリ、ネットワーキングも構成できます。既定値は原記事に書かれていないため、補足として開発版ガイドの記述を参照します。

開発版ガイドによると、既定ではベースのルートファイルシステムが読み取り専用でマウントされ、指定したworkdirだけが書き込み可能です。ネットワークの既定はnetwork="none"で、信頼できないコードは外部への接続やクラスタ内サービスの探索ができないと説明されています。

network="public"では、各サンドボックスがslirp4netnsで橋渡しされた専用のネットワーク名前空間からインターネットへ出られます。ただし、開発版ガイドは次のように注意しています。

They can still reach anything else the node can reach, including other Pods and internal cluster services, so keep network="none" for untrusted code.

出典:Ray Deploy Ray sandboxes with KubeRay #

日本語訳：ただし、他のPodやクラスタ内部のサービスを含め、ノードが到達できるほかの場所には到達できるため、信頼できないコードにはnetwork="none"を維持してください。

network="public"を使うには、ワーカーの$PATHにあるslirp4netnsと、Rayコンテナ内の/dev/net/tunが必要とされています。

信頼できないコードを動かす予定がある場合は、作成時のネットワーク指定がnoneのままかを確認してください。開発版ガイドの任意の手順には、/etcへの書き込みと外部への接続を試し、終了コードが0以外になることを見る例があります。

終了コードで分かるのは、例として実行した個々の操作が失敗したかどうかです。隔離境界全体が保たれているかは、個々の結果だけからは判断できません。

既定値の記述は開発版ドキュメントの確認日時点のものです。Ray 2.58の固定リリースでも同じ既定値かどうかは、今回の資料では判断できません。

原記事は、今後のRayのバージョンでAgent SubstrateやKata Containersといった他のサンドボックスランタイムへサポートを広げる予定だと述べています。原記事の時点で初期ランタイムとされているのはgVisorです。

gVisor以外のランタイムを使いたい場合は、Rayの今後の版で対応状況を確かめる必要があります。意見や要望は、原記事が案内するGitHubのissueでのディスカッションに寄せられます。

対応が加わる版や時期は、原記事には示されていません。予定の記述だけを根拠に、特定の版で利用できると判断しないようにしてください。