Ray 2.58.0のgVisorサンドボックス、作成・実行のtimeoutとTTLの違い
Share
Ray 2.58.0のgVisorサンドボックス、作成・実行のtimeoutとTTLの違い
生成コードが終わらない場合に備えるなら、まず「環境の準備」「コマンドの実行」「使い終えた環境の削除」のどこを管理したいかを分けます。Ray 2.58.0の試験版APIでは、createのtimeout_secondsを指定しても、その後のコード実行へ同じ制限は付きません。確認した2.58.0の低水準実装では、この値はイメージ取得の各呼び出しと、runsc起動後にコンテナが動作状態になるまでの待機へ個別に使われるもので、作成処理全体で共有する残り時間ではありません。高水準のsandbox.create()自体がいつ戻るかは今回確認した資料では判断できないため、指定秒数以内に必ず終わる設定とは扱いません。コマンドを待つ時間にはexecのtimeoutを指定します。 [2] [3] [4] [5]
待ち続けて困る段階に、時間設定を対応させる
原記事の論点サンドボックス API → 環境の終了・削除とライフサイクル
確認に使った資料Ray 2.58.0：SandboxRuntimeの実装／Ray 2.58.0：サンドボックス設定の定義 — create・exec・ttl_secondsの定義 [3] [5]
環境を用意してPythonを実行する処理なら、作成用と実行用の設定を分けて用意します。環境を残す時間にも上限を設けたい場合は、追加でttl_secondsを検討します。TTLだけを設定してコマンドのタイムアウト処理を省く、という使い分けにはしません。 [2] [3] [5]
| 管理したいこと | 指定する項目 | 分けて確認すること |
|---|---|---|
| イメージ取得とrunning待機に時間設定を渡したい | createのtimeout_seconds | 確認した2.58.0の低水準実装（SandboxRuntimeとgVisorバックエンド）では、イメージ取得の各呼び出しと、runsc起動後にrunningになるまでの待機へ個別に使われる。全体で共有する締切ではない。高水準のsandbox.create()自体の戻り方は今回の資料では未確認。その後のコマンド実行へも引き継がれない。 |
| 呼び出したコードが終わらない | execのtimeout | コマンド実行の待機。タイムアウト時の例外処理を用意する。 |
| 作成した環境を期限後に残したくない | createのttl_seconds | 環境の寿命。期限後の削除はベストエフォートで、完了時刻の保証ではない。 |
同じ環境を使い続けるなら、TTLを作成時から考える
原記事の論点サンドボックス API → 環境の終了・削除とライフサイクル
確認に使った資料Ray 2.58.0：SandboxRuntimeの実装／Ray 2.58.0：サンドボックス設定の定義 — ttl_secondsのwall-clock from creation・not idle time [3] [5]
ttl_secondsはアイドル時間を数える設定ではありません。2.58.0の実装では環境を作成した後にタイマーが始まり、コマンドを追加実行しても、そのたびに寿命が延びる仕組みではありません。複数の処理や結果回収に同じ環境を使うなら、それらに必要な時間も含めてTTLを選びます。 [3] [5]
ttl_secondsの定義から抜粋（Ray 2.58.0）
from creation (not idle time). None (default) or <= 0 disables it.
日本語訳：作成時から計測し、アイドル時間ではありません。既定値のNone、または0以下の指定では無効になります。
TTLは未指定のNoneが既定で、0以下でも無効です。有効にすると期限後の削除を試みますが、実装はベストエフォートです。障害時も含めた厳密な削除期限が要件なら、この設定だけで要件を満たしたと判断せず、期限後の状態と削除の失敗をどう確認するかまで検討します。 [3] [5]
正常終了とタイムアウトの両方で、後処理まで試す
原記事の論点サンドボックス API → 環境の終了・削除とライフサイクル／サンドボックスの状態検査 ／ Ray プリミティブとしてのサンドボックス → アクターのライフサイクル管理とgVisorの隔離という役割分担
確認に使った資料Ray 2.58.0：Ray Sandboxes／Ray 2.58.0：SandboxRuntimeの実装／Ray 2.58.0：gVisorバックエンドの実装 — S2：deleteの基本例／S3：exec・delete／S4：TimeoutExpired処理 [2] [3] [4]
2.58.0のgVisorバックエンドは、execの待機がタイムアウトするとSandboxTimeoutErrorを発生させます。正常な実行結果を扱う経路に加え、この例外を受け取った後に何を回収し、いつ環境を削除するかを決めます。例外を受け取った事実を、環境内の子プロセスまで含めた停止確認の代わりにはできません。 [3] [4]
試験では、時間内に終わる場合と、指定した待ち時間を超える場合を分けます。前者は必要な出力の回収後にdeleteへ進めるか、後者は例外を処理して予定した削除の経路へ進めるかを確認します。どちらかで後処理が抜けるなら、時間の数値を調整する前にその経路を見直します。 [2] [3] [4]
execのtimeout自体は、環境全体の削除期限を決める設定ではありません。また、2.58.0のSandboxRuntimeではterminateも内部でdeleteを呼びます。名前から「停止だけ行い、環境を残す操作」とは判断せず、必要な出力をどの時点で回収するかを決めます。 [2] [3] [4]
状態の検査にはget_statusがありますが、2.58.0のgVisorバックエンドは管理情報と管理用ディレクトリの存在から状態を返します。状態値を得たことだけで、子プロセスまで含む停止を確認したとは扱えません。厳密な停止が要件なら、利用環境で残存する処理を確認する方法も用意し、タイムアウト・削除・状態確認を一続きで検証します。 [3] [4]
出典・確認範囲（5件）
2026年9月8日に確認したRay 2.58.0の公式資料・実装に基づきます。コードの読解による解説で、実機の停止動作・性能・安全性は未検証です。
