ModalがKubernetesを捨て100万サンドボックスを秒速起動した技術的背景

• ModalがKubernetesを廃し、分散型スケジューリングを採用して100万サンドボックスの同時実行を実現。
• 中央集権的なetcd依存を排除し、各ワーカーを独立した真実のソースとすることで水平スケーラビリティを確保。
• AIエージェント等の高頻度・低レイテンシなワークロードに対し、ミリ秒単位の隔離環境提供が可能に。

深夜の障害対応で、Kubernetesのetcdが悲鳴を上げ、Podの起動がタイムアウトし続けるあの絶望的な光景を経験したエンジニアなら、今回のModalの発表には背筋が凍るような共感を覚えるはずだ。ModalのスタッフエンジニアであるColin WeldとConnor Adamsが公開した、彼らのサンドボックスインフラの全面的な再構築は、単なる「最適化」の範疇を超えている。彼らは、現代のクラウドネイティブ開発の聖典とも言えるKubernetesを、あえて「捨てる」という選択をしたのだ。

なぜか。理由は明白だ。Kubernetesは、数千ノード、数万Podのスケールには耐えうるが、AIエージェントが要求するような「秒間数万回のサンドボックス生成」という極端な高負荷環境では、その設計思想そのものがボトルネックとなるからだ。Kubernetesの心臓部であるetcdは、強整合性を維持するために書き込み負荷が集中すると容易にデッドロックやパフォーマンス低下を引き起こす。ノード数やPod数が増えるにつれ、スケジューリングアルゴリズムの計算量はO(nodes)やO(pods)のオーダーで増大し、中央集権的な調整がシステム全体の足を引っ張る。

Modalのエンジニアたちは、この「中央集権的な調整」こそがスケーラビリティの敵であると断定した。彼らが構築したのは、Kubernetesのようなグローバルな調整を排し、各ワーカーノードが自律的に判断を下す「ロードバランシングに近いスケジューリング」だ。これは、分散システムにおける「真実のソース」を中央から末端へ分散させるという、極めて大胆かつ理にかなったアプローチである。我々が普段、マイクロサービスを設計する際に「データベースの競合をどう避けるか」と頭を悩ませるのと同じ課題を、インフラ層のレベルで解決してしまったのだ。

Modalが採用したアーキテクチャの核心は、スケジューリングの並列化にある。単一のシリアライズされたスケジューラーを廃し、複数のスケジューリングサーバーを並列稼働させることで、スケジューリング層そのものを水平方向に拡張可能にした。各ワーカーは、自身の空きリソース状況を把握しており、スケジューラーからのRPCリクエストに対して「受け入れ」か「拒否」を即座に判断する。このシンプルさが、100万サンドボックスという途方もない規模を支える鍵となっている。

もちろん、完全にボトルネックが消えたわけではない。すべてのワーカーが自身の状態を単一のRedisストリームにパブリッシュするという設計は残っている。しかし、彼らの負荷テストによれば、この構成は10万ワーカーを超えてもなお安定して動作することが証明されている。ベンチマークの結果は驚異的だ。100万サンドボックスを1分以内に生成し、コード実行までの起動時間は中央値で0.5秒を切る。これは、従来のコンテナプラットフォームでは考えられない速度だ。

AWSのプリンシパルAIエンジニアであるAlex Jonesが指摘するように、これは「KubernetesがGenAIインフラの進化速度に追いつけていない」という明確なシグナルである。我々エンジニアは、これまで「何でもKubernetesで解決できる」という幻想を抱いてきたかもしれない。しかし、AIエージェントが求めるミリ秒単位の隔離環境と、動的なリソース割り当ては、既存のK8sの抽象化レイヤーでは重すぎるのだ。Modalの成功は、実行プレーン（Execution Plane）と調整プレーン（Coordination Plane）の分離という、次世代インフラの設計トレンドを決定づけるものとなるだろう。

さて、この技術的転換を前にして、我々現場のエンジニアは何をすべきか。まず、自らのアプリケーションが「Kubernetesという抽象化」に依存しすぎていないかを再考する必要がある。もし君のシステムが、エージェントの並列実行や高頻度なタスク生成を伴うAIワークロードであるなら、Kubernetesの標準的なPodライフサイクル管理は、将来的に必ずパフォーマンスの壁に突き当たる。Modalのような「Kubernetesを回避する」インフラの台頭は、インフラエンジニアリングの主戦場が「いかにK8sを使いこなすか」から「いかにK8sの制約を回避して実行環境を最適化するか」へシフトしていることを示唆している。

明日から取るべきアクションは明確だ。まずは、自社のワークロードにおける「コールドスタート」のコストを再計測すること。そして、もしそのコストがビジネスのボトルネックになっているなら、UnikraftやGoogle Substrate、あるいはModalのような、より軽量で特化型の実行環境への移行を検討すべきだ。Kubernetesは依然として強力なツールだが、それは「汎用的な調整」のためのものであり、「超高速な実行」のためのものではないという現実を直視しなければならない。

最後に、我々自身に問いかけたい。我々は、既存のツールやフレームワークの「皮」を被ることに満足し、その下の「肉」であるインフラの挙動をブラックボックス化していないだろうか。ModalのエンジニアたちがKubernetesのソースコードやetcdの挙動を深く理解し、あえてその外側を歩むことを選んだように、我々もまた、技術の抽象化レイヤーを剥ぎ取り、その下で何が起きているのかを理解する「泥臭いエンジニアリング」を取り戻す必要があるのではないか。君のインフラは、100万の要求を捌く準備ができているか？それとも、まだetcdのロック解放を待っているのか？