100万サンドボックスを1分未満で起動した実証結果と公表データの前提

クラウド基盤を提供するModalは、100万件のサンドボックス（隔離されたプログラム実行環境）を同時稼働させた実証結果を公表しました[1]。同社は全件の作成を1分未満で完了したと報告しています[2]。ただし公式記事では、同時稼働と判定したシステム状態や稼働を維持した時間の長さは定義されていません[1, 2]。

Modalは今回の試験において、新システムを用いて100万件のサンドボックスを可能な限り高速に立ち上げたと説明しています[3]。全体の作成にかかった時間は1分未満でした。主なボトルネックは、ベンチマーク（性能測定のための試験）における負荷生成処理そのものにあったとしています[3]。一方で、計測の開始点や終了点、負荷生成器の構成、各サンドボックスの実行コードや負荷条件は明記されていません[3]。

作成完了の定義についても把握しておく必要があります。Modalの説明によれば、作成要求の応答が返るのは起動開始の時点です。スケジューラ（タスクの割り当てを制御する管理プログラム）がワーカー（サンドボックスを実行するサーバ）にサンドボックスを割り当て、起動を始めたときに返されます[4, 5]。したがって、作成応答が返ったこと自体は、ユーザコードが即座に実行可能な状態になったことを意味していません[5]。

個別の起動遅延についてModalは、クライアントが作成を試行してからユーザコードが実行可能になるまでの時間を測定しています[6]。新システムの試験では、この遅延の中央値（値を小さい順に並べたときの中央の値）が0.5秒未満であったと報告されました[6, 7]。公表記事の図には100万件から無作為抽出した1万件の起動時刻が示されていますが、中央値の算出対象となった母集団や詳細な試験構成は明記されていません[6, 7]。

さらに、コンテナ（アプリケーションを隔離して実行する単位）が起動してからユーザが求める処理の準備が整うまでには別の段階が存在します。ライブラリなどの依存関係の取得やアプリケーションの初期化はベンチマークに含まれないため、実際の利用時には追加の待ち時間が生じます[8]。また負荷生成器の構成や遅延分布の末尾統計などは記載されていません。そのため、異なる本番負荷や継続的な同時稼働性能は記事の情報だけでは比較しにくいといえます[9]。

本番利用時の制限値との違いにも注意が求められます。Modalは記事公開時点で顧客あたり最大5万件のサンドボックス同時実行を掲げていますが、100万件の数値はそれとは別の性能実証として報告されています[10]。公式スケーリング文書では、単一Function（実行関数）に4,000コンテナの上限が記載されています。ただし、この上限をサンドボックスAPI（ソフトウェア同士が機能を呼び出す仕組み）の上限と同一視すべきではありません[10]。

以下の表は、公表された実証指標と本番利用時の条件を整理したものです[1, 2, 3, 6, 7, 10]。

比較項目実証試験の公表値本番利用・公式文書の仕様評価における前提条件
同時稼働数100万サンドボックス[1]顧客あたり最大5万件[10]実証における同時稼働の判定条件や維持時間は非開示[1, 2]
全体作成時間1分未満[3]プランに応じた上限設定[10]計測の開始・終了点や負荷生成器の構成は非記載[3]
起動遅延（中央値）0.5秒未満[6, 7]-1万件の抽出図を提示、中央値の計算母集団は非明記[6, 7]
作成応答の時点ワーカー割当・起動開始時[4, 5]同左応答時点ではユーザーコード実行可能とは限らない[5]
Function上限-単一Functionで4,000コンテナ[10]単一Functionの上限とSandbox APIの上限は別個に定義[10]

後輩実証で100万件が動いたということは、私たちのシステムでもすぐに同じ規模で使えるのでしょうか？

先輩そこは混同しやすい部分だね。公表された100万件はインフラの限界を試すストレステストであって、通常の利用枠とは前提が違うんだよ。

後輩通常利用の上限は別にあるわけですね。作成完了の扱いも気をつける必要がありますか？

先輩その通りだね。システムが作成完了を返した瞬間と、実際に自作コードが動く瞬間には時間差があるんだ。

後輩外部パッケージの導入や初期化の遅延も含めて、全体の待ち時間を考える必要がありますね。

先輩そうだね。数字の前提条件を正しく把握することが、実務での正確な見積もりにつながるよ。

強化学習とAIエージェントが引き起こす環境作成バーストと起動遅延の課題

強化学習（試行錯誤を通じて最適な行動を学習させる手法）を使うAIモデルの開発現場では、環境作成に特有の課題が生じます。強化学習のロールアウト（環境と相互作用して試行データを収集する工程）では、開始時にサンドボックスの作成要求が極めて短時間に集中します[11]。多数の試行を並列に実行するため、平均的な負荷指標では捉えにくい急激な作成バーストと高い同時稼働が発生します[11]。

このワークロード（コンピュータに実行させる処理の内容や量）において、環境の起動遅延は計算コストの増大に直結します。強化学習ではロールアウトごとに実行環境を用意し、推論処理（学習済みモデルを使って回答を生成する計算）と並行して動作させます[12]。そのためサンドボックスの起動待ちが発生すると、高価なGPU（画像処理装置。並列計算に適し、AI計算にも使われます）の稼働を止める要因になります[12]。一方で環境を過剰に先行確保すると、待機状態にあるアイドル計算資源の費用が増加してしまいます[12]。

実際の強化学習ワークロードでは、各試行を独立した一時的環境で動かす構成が取られます。本番サービスを模した複雑な環境を動かしながら、得られた結果の採点を並列に行う運用パターンが存在します[13]。複雑な依存関係を持つ環境を隔離状態で大量かつ瞬時に提供することは、インフラにとって大きな負荷となります[13]。

自律型AIエージェントの普及も、環境作成の需要を押し上げています。本番環境で動作するAIエージェントでは、バックグラウンド処理やユーザからの利用要求の急増に伴い、サンドボックスの作成要求が集中します[14]。人間の監視なしで動作するエージェントが生成したコードを実行するため、厳格に隔離された環境を高い作成レートで供給し続ける必要があります[14]。

後輩AIの処理というとモデルの計算時間ばかり気にしていましたが、環境作成も問題になるのですか？

先輩まさにそこが隠れた難所なんだよ。環境の立ち上がりが遅いと、待っている間も高価な計算機が止まってしまうんだ。

後輩GPUを遊ばせないために前もって環境を作っておく、という回避策は取れないのでしょうか？

先輩それをやると今度は使っていない時間の待機費用が跳ね上がってしまうんだよね。

後輩必要な瞬間にだけ一気に立ち上げられるインフラが求められているわけですね。

先輩その通りだよ。必要なときにだけ素早く作って破棄できる仕組みが、コスト削減の鍵を握るんだ。

中央ストアを排除した非同期スケジューリングと直接RPCによる新アーキテクチャ

従来のコンテナ基盤では、クラスタ（複数のサーバを連携させた計算環境）内の作成対象やノード（サーバ機器）が増加するにつれて中央管理機構への負荷が増大していました[15]。Kubernetes（コンテナオーケストレーション基盤）の標準経路では、APIサーバが新しいPod（1つ以上のコンテナをまとめて実行する最小単位）を受け付けます。APIサーバは、その情報を分散KVS（キーと値を使ってデータを保存する仕組み）であるetcdに記録します[16]。その後kube-schedulerが未割当のPodを監視して配置先ノードを選び、その決定をAPIサーバへバインディング情報として書き戻してからノードが起動処理を行います[16]。

このように作成や配置が中央のAPIと状態ストアを通るため、直列化されたスケジューラやetcdへの同期書き込みが、大量作成や高い入れ替わりにおけるボトルネックになっていました[15, 16]。Modalの再設計前の旧基盤においても、サンドボックスの作成や割り当てにクラスタ全体の同期調整とPostgres（リレーショナルデータベース）への書き込みを必須としていました[17]。その結果、サンドボックス数に応じた処理や頻繁な入れ替わりがイベントの滞留を招き、ノード管理や自動拡張の障害になっていました[17]。

旧構成においてModalは、作成要求を受けたサンドボックスを一旦キューに入れ、Postgresに状態を記録していました[18]。スケジューラ自体は並列に動作していたものの、競合を回避するための全体調整やワーカー割り当て時の追加書き込みが必要であり、データベースが作成経路の重大なボトルネックとなっていました[18]。

そこでModalの新アーキテクチャは、既存のスケジューラを単に増やすのではなく、競合回避のための全体同期調整を作成経路から完全に排除しました[19]。複数のスケジューラは、ワーカーの状態を保持したメモリ上のキャッシュデータを参照しながら、互いに同期することなく並列に配置先を選択します[19]。

配置先を決定したスケジューラは、ワーカーに対して直接RPC（ネットワーク越しの遠隔手続き呼び出し）で作成を依頼します[20, 21]。ワーカー自身が手元の空き資源を確認し、余裕があれば受諾し、なければ拒否を返します[20, 21]。この方式により、中央の永続データストアを介した同期的な書き込みや割り当て調整が作成経路から外れました[20, 22]。

サンドボックスのメタデータ（属性情報）や実行結果の保存は、作成のクリティカルパス（処理遅延を直接左右する必須経路）の外側で非同期に行われます[22, 23]。さらにワーカー側では、複数のサンドボックスに関する制御メッセージを単一のRPCにまとめて集約送信します[23]。これにより、永続ストアへの書き込み負荷と、サンドボックス数に比例して増加する制御通信の両方を大幅に抑制しました[22, 23]。

ただしこの設計は、作成経路におけるグローバルな強整合性（システム全体で常に完全一致した状態を維持する性質）を手放すトレードオフを伴います[24]。非同期に配信される状態キャッシュに基づいて配置先を選択するため、スケジューラが一時的に古いワーカー情報を参照する可能性が生じます[24]。

以下の図は、中央データストアを介す従来型経路と、メモリキャッシュと直接RPCを用いるModalの新アーキテクチャの構造比較を示しています[15, 16, 18, 19, 20, 21, 22]。

後輩中央のデータベースで厳密に管理しないと、同じサーバを取り合ってしまいませんか？

先輩その懸念はもっともだね。Modalは全体で完璧な一致を保つ強整合性をあえて手放したんだ。

後輩スケジューラが持っている情報が、実際には少し古い場合もあるわけですね。

先輩そうなんだよ。でも最終的な空き確認は依頼を受けたワーカー自身が行うから破綻は避けられるんだ。

後輩中央の更新待ちをなくして速度を優先し、判断を現場に委ねる設計なんですね。

先輩まさにその割り切りが、大量のリクエストが来ても詰まらない構造を支えているんだよ。

Linuxカーネル競合の解消と結果整合性・隔離セキュリティの留意点

スケジューリング機構を非同期化して高速化しても、ワーカー側におけるコンテナ起動時の遅延が新たな課題として浮上しました[28]。同一ワーカー上で多数のサンドボックスが同時に立ち上がると、Linuxカーネル内部でネットワーク設定を保護するrtnl（ルーティングネットリンク）ロックの激しい競合が発生します[28, 29, 30]。これにより起動処理に数十秒を要するケースが生じ、起動遅延の分布における末尾（ロングテール）を悪化させていたため、Modalはサンドボックスのネットワーク設定を変更しました[28, 29, 30, 31]。なお公式記事には、p95（遅延の小さい方から95％に当たる値）やp99（99％に当たる値）といった詳細なテール遅延の統計値は開示されていません[31]。

また、全ワーカーの状態配信を集約する単一のRedis stream（追記型のストリームデータ構造）が当面のボトルネックとして挙げられています[25, 26]。Modalは負荷試験の結果から、10万ワーカーを大きく超える規模でも単一ストリームで処理可能であると示唆しています[25, 27]。さらにストリーム上の順序関係に依存しない設計であるため、必要に応じてストリーム数を増やして分散できると説明しています[26]。ただし試験負荷や状態更新頻度などの詳細条件は公開されていないため、この数値は公式なサービス保証ではなくスケールの目安として解釈するのが妥当です[27]。

アーキテクチャの非同期化に伴う結果整合性（時間の経過とともに最終的な整合状態へ収束するモデル）についても考慮が必要です。永続ストアへの書き込みを作成経路から外したことで応答速度は向上した一方、ワーカー停止や状態配信の中断が発生した際の復旧手順やデータ欠損時の保証内容は、公開記事だけでは評価できません[32]。また、ワーカー自身の空き判定によって古いキャッシュによる配置を拒否できるものの、作成バースト時には拒否された要求の再選択や再試行が追加の通信と遅延を引き起こす可能性があります[33]。

サンドボックスの同一性管理にも留意が必要です。Modalの「Named Sandbox」機能では、同一App（アプリケーション）内で実行中のサンドボックス名を一意に制限しており、使用中の名前で再度作成を試みるとエラーが発生します[34]。しかし公開されたインフラ情報からは、RPCリクエストIDによる重複排除や冪等性（同じ操作を何度行っても同じ結果になる性質）の仕様が確認できません[35]。ネットワーク障害などで作成応答を受け取れずに再試行した場合、意図しない重複サンドボックスが生成されないとは断定できません[35]。

セキュリティと隔離境界の脅威モデル（想定される脅威と防御範囲の定義）も重要な評価軸です。Modalのサンドボックスは既定で外部からの着信接続とワークスペース資源へのアクセスを遮断していますが、外向き通信は既定で任意の公開IPアドレスへ接続可能です[36]。不要な通信を防ぐには、開発者が明示的に通信遮断や許可リストを設定する必要があります[36]。

Modalは隔離基盤としてGoogle開発のgVisor（アプリケーションとホストカーネルの間に介在する軽量カーネル層）を採用しています[37]。gVisorはホストへのシステムAPI露出を減らしますが、gVisor自身の脅威モデルが示すように、アプリケーション全体の安全性を代替するものではなく、リソース枯渇への耐性はホスト側の制御機構に依存します[37]。Hugging Faceのセキュリティ報告では、公開環境のサンドボックス内で攻撃者がroot権限（LinuxなどのOSにおける管理者権限）を取得し外部攻撃の足場に悪用した事例が報告されました[38]。Modalは他顧客のワークロードへの影響はなかったと説明していますが、今回の100万件実証はスケジューリングと起動速度の性能を示すものであり、隔離の突破耐性を証明するものではありません[38, 39]。したがって、サンドボックス内での実行権限や外向き通信の制限、他環境への影響を個別の脅威モデルに基づいて検証する必要があります[37, 39]。

後輩1分で100万個も起動できるなら、安全性や耐障害性も万全と捉えてよいのでしょうか？

先輩その2つは切り離して評価しなければならないよ。今回の発表はあくまで処理性能の成果であって、防御の堅牢さを示した試験ではないんだ。

後輩gVisorなどの隔離層を使っていても、内部で危険なコードが走った場合のリスクは残るわけですね。

先輩その通りだね。外向き通信が初期状態で開放されている点や、異常時の再試行動作など、運用側の防御設計が不可欠なんだよ。

後輩起動の速さに目を奪われず、セキュリティの境界線を自分たちで確認することが大切なんですね。

先輩まさにそこが技術を選定する上で最も見落としてはいけない視点だよ。

開発者向けBeta提供の利用方法と各SDKにおける移行ロードマップ

Modalは今回公表した新サンドボックス基盤をBeta（試験提供）として公開しており、大量の環境作成を必要とする開発者に向けて試用を案内しています[40]。新基盤の公開案内には特別な有料プランや事前の招待枠などの条件は記載されていません。公式案内で確認できる範囲では、対応バージョンのSDK（ソフトウェア開発キット）を導入することで即座にオプトイン（明示的な利用選択）が可能です[40]。

各言語のSDKにおける設定手順は以下の通りです。Python環境ではバージョン1.5.4以降を対象に、環境変数「MODAL_SANDBOX_V2=1」を設定して実行します[40]。JavaScriptおよびGo環境ではバージョン0.10.1以降において、同様の環境変数を指定するか、設定ファイル「.modal.toml」内に「sandbox_v2 = true」と記述することで新基盤が有効化されます[40]。

今後のロードマップとしてModalは、すべてのサンドボックスのスケジューリング基盤を近いうちに新システムへ移行させる方針を掲げています[41]。Python向けSDKではバージョン1.6.0において新基盤が既定動作となる予定であり、JavaScriptおよびGo向けSDKでも今後のリリースで順次既定化される計画です[41]。ただし、クラスタ全体での一斉切り替え日や、正式版（GA）の具体的な提供期日は公表資料に明記されていません[41]。