Ray 2.58.0のgVisor連携で生成コードを隔離実行、結果回収までの流れ

AIが生成したPythonをRay・gVisorで評価したい場合は、入力と期待する出力を決められる一つの処理から試します。終了コードだけで成功とせず、出力の回収と期待値との照合までを最初の確認範囲にします。 [2] [3] [4]

先に、試す処理と実行環境をそろえる

原記事の論点Ray プリミティブとしてのサンドボックス → OCIイメージから環境を作りアクターハンドルを得る高水準API／Rayスケジューラによる実行ノード選択／Ray 2.58以降でのAPI利用　ほか2件 ／ サンドボックス API → 環境変数と作業ディレクトリの設定／SandboxRuntimeによるローカル環境の直接操作／gVisorへ渡す前のOCI仕様編集　ほか1件 ／ gVisor を選ぶ理由 → OCI互換と標準イメージ、Dockerデーモン/ホストソケットを公開しない構成 ／ 発表本文の導入 → Google CloudとAnyscaleによる試験版ライブラリの紹介／強化学習・エージェントの生成コードとツール操作を隔離する用途

確認に使った資料Ray 2.58.0：Ray Sandboxes／gVisor：What is gVisor? — Requirements・ファイル操作例・互換性と性能の制約 [2] [6]

例えば、計算結果をファイルへ書く処理なら、入力・期待値・出力先を先に決めます。必要なPythonやライブラリをイメージに含め、作業ディレクトリも指定します。 [2] [3] [4]

サンドボックスを動かすRayノードには、対応するLinux環境と、PATHから呼び出せるrunscが必要です。手元のPCだけに用意しても、別のRayノードの準備にはなりません。Ray 2.58.0のライブラリはalphaなので、試験で使う版と依存関係を記録しておきます。 [2]

Rayは学習や推論などを複数のマシンで動かす基盤です。このAPIでは、Rayが選んだノード上のアクターを窓口に、コマンドをgVisorへ渡します。通常のアクター内の処理まで自動で隔離される、という意味ではありません。 [1] [2]

まず一つの処理を試すなら、sandbox.create()から実行と回収をつなぎます。OCI仕様の編集やアクター内で複数環境を管理する必要があれば、低水準のSandboxRuntimeも検討します。元記事のプール例は、一つのアクターにRuntimeと複数の環境IDを保持し、選んだ環境でexecを実行、closeで全環境をdeleteする構造です。最初の試験に、この管理まで必要かを分けて考えます。 [1] [2] [3]

実行と結果回収を、一つの処理でつなぐ

原記事の論点Ray プリミティブとしてのサンドボックス → アクターのライフサイクル管理とgVisorの隔離という役割分担／OCIイメージから環境を作りアクターハンドルを得る高水準API／通常のRayアクター呼び出しとしてexecとray.getを使う ／ サンドボックス API → ファイルの読み書きとアップロード・ダウンロード／環境の終了・削除とライフサイクル／環境変数と作業ディレクトリの設定 ／ gVisor を選ぶ理由 → OCI互換と標準イメージ、Dockerデーモン/ホストソケットを公開しない構成

確認に使った資料Ray 2.58.0：Ray Sandboxes／Ray 2.58.0：SandboxRuntimeの実装 — ファイル操作の連続例・exec・read_file [2] [3]

実行と結果回収に当たる公式例の抜粋です。Rayを初期化し、Pythonを動かせるサンドボックスをsbに用意し、/workspace/output.txtへ結果を書くプログラムを/workspace/solution.pyに配置済み、という前提です。単独では動かず、例には失敗時の分岐も含まれていません。 [2]

exec_res = ray.get(sb.exec.remote("python3 /workspace/solution.py"))
print("Execution returncode:", exec_res.exit_code)

# 3. Read generated output file back to the host
output_bytes = ray.get(sb.read_file.remote("/workspace/output.txt"))
print("Result:", output_bytes.decode("utf-8"))

回収先を手元のPCにしたいときは、パスの意味を確認します。2.58.0のdownload_fileの保存先は、操作するランタイム側のパスです。別マシンのアクターから呼ぶ場合、手元のPCに保存されるとは限りません。呼び出し元へ内容を返すには、上のread_fileでバイト列を受け取り、その側で保存します。 [2] [3]

結果に応じて、次に調べる工程を変える

原記事の論点Ray プリミティブとしてのサンドボックス → 通常のRayアクター呼び出しとしてexecとray.getを使う／CPU・メモリの予約とAPIでの資源指定 ／ サンドボックス API → ファイルの読み書きとアップロード・ダウンロード

確認に使った資料Ray 2.58.0：Ray Sandboxes／Ray 2.58.0：SandboxRuntimeの実装／Ray 2.58.0：gVisorバックエンドの実装 — ExecResult・read_fileの戻り値とファイル読み取りエラー [2] [3] [4]

期待値まで一致したら、その入力について実行・回収・照合の流れを確認できた段階です。この公式例は、実行結果とファイル内容を呼び出し側へ返すところまでです。期待値との照合や学習処理への受け渡しは例に含まれていないため、本記事の試験手順では別の確認工程として扱います。実際に使う別の入力や依存ライブラリでも試し、実行から回収までの所要時間が用途に合うかを測ります。 [2] [3] [4] [6]

外部APIや秘密情報を使う場合は、試験結果とは別に、通信先・渡す情報・返却値の範囲を決めます。作成待ちとコマンド実行の時間制限も別指定です。CPU・メモリの指定が実行環境で制限として働くかも確認し、一つの正常終了をそのまま運用条件の確認に置き換えないようにします。 [2] [3] [4] [5]