Sandbox0が発表した内容
Sandbox0は10月17日、各sandbox内で動くcommand service「procd」に依存しない復旧経路を発表しました。同社によると、通常のterminal commandが使えない場合でも、運用者は影響を受けた環境の外部からlifecycle状態を確認し、復旧を要求できます。ここまではSandbox0が公表した機能であり、以下はIneezaの本番運用分析です。
明示的なruntime restartは既存processを終了し、外部にcommitされたroot filesystemから新しい実行を開始します。Install済みsoftware、configuration、保存済みproject fileは保持できますが、restartだけでは不正なfile変更を戻せず、削除済みdataも再作成できません。その場合は以前のsnapshotが必要です。Sandbox0は対応対象のprocess stateを保持する実験的なmemory pause・resumeも説明していますが、memory checkpointが障害自体を保持し得ること、network connectionの継続は保証されないことも明記しています。
Sandbox0は、意図的に破損させた環境、procd停止、通常commandを妨げるfilesystem変更、reply喪失、commit済みworkspace dataを用いて境界を検証したと説明しています。一方、主張は試験したfailure caseに限定し、storage障害、compute capacity不足、snapshotのない削除済みfile、未commitのwriteは復旧を妨げ得るとしています。
復旧権限は障害domainの外側に置く必要がある
Root権限を持つagentはworkspace内のmount、process、dependency、configurationを変更できます。唯一の修復機構が、agent自身が破損できるcommand service、filesystem view、process treeを使うなら、control pathは復旧対象のworkloadと一緒に失敗します。
Ineezaの分析: 本番agent platformではworkload権限とlifecycle権限を分離すべきです。外部planeはguest commandを実行せずにruntimeを停止、checkpoint、置換、検査できる必要があります。そのcredential、log、storage lease、scheduling判断もsandboxから隔離すべきです。帯域外controlは単なる可用性機能ではなく、in-band経路が信頼できなくなった後に運用者がagentを封じ込めるための境界です。
「復旧」には明示的なstate semanticsが必要
Sandbox0は、最新のcommit済みfilesystemから新しいprocessを起動するrestart、以前のfilesystem snapshotへのrestore、対応対象のmemory・process stateの保持という、実質的に異なる三つの操作を区別しています。保持・破棄する証跡はそれぞれ異なります。また、runtime restartの成功とuser applicationの正常性証明も別です。
Ineezaの分析: Orchestration layerはこれらを一つの一般的なretryとして公開すべきではありません。実行前にruntime generation、commit済みfilesystem generation、snapshot identifier、process保持の選択、想定data-loss境界を記録すべきです。実行後は作業再開前にapplication固有のhealthとoutput integrityを検証する必要があります。そうしなければ、破損fileを保持したまま復旧を報告したり、重要なvolatile evidenceを破棄したり、同じ破損process stateを再開したりする可能性があります。
不確実なrequestにはgeneration対応のidempotencyが必要
Sandbox0によると、復旧operationは記録され、connection喪失後も照会できます。同じrequest keyと期待するruntime generationでretryすると、すでに動作しているreplacementを再度restartせず、元のoperationを追跡します。同社documentationは、replacementを確認できるのはoperation receiptがsucceededになった場合だけと説明しています。
Ineezaの分析: Timeoutだけではside effectが発生したか分からないため、これはagent systemに不可欠です。各lifecycle変更はidempotency keyを期待generationへ結び付け、古い権限を拒否し、durableなoperation recordを返すべきです。Callerは再接続後に盲目的な二回目の変更を発行せず、そのrecordをreconcileする必要があります。同じpatternはinfrastructure作成、送金、credential rotation、本番state変更を行うtool callにも必要です。
Healthは独立した証跡へ分解する必要がある
Sandbox0はruntime、supervisor、command execution、storageの状態をunknownを含めて個別に報告すると説明しています。Sandboxがrunningでもterminalが失敗する場合や、storageを保持していても新しい実行が利用できない場合があるため、この区別は重要です。
Ineezaの分析: Agent platformには一つのgreen statusではなく、復旧判断に対応するhealth signalが必要です。運用側はlifecycle権限、guest reachability、command execution、storage identity、storage I/O、application correctnessを区別し、観測時刻を保持し、各actionをblockする欠落証跡を定義すべきです。Unknownを暗黙にhealthyとして扱ってはいけません。Recovery SLOはreplacement runtimeの割り当て時間ではなく、検証済みの利用可能状態までの時間を測るべきです。
Ineezaの見解
Sandbox0の変更が重要なのは、長時間動くagentではsandbox復旧がstate管理と権限の問題になるためです。持続的な設計は、明示的な保持semantics、generation確認付きidempotency、分解されたhealth evidence、application levelの検証を備える独立control planeです。Agentへroot権限を与えることは有用ですが、agentが無効化できない復旧経路を保持して初めて、その権限を本番で運用できます。