100万の同時実行サンドボックスを数秒でスケーリングする

すべてのお知らせ エンジニアリング 2026年7月16日•10分読む 100万の同時実行サンドボックスを数秒でスケーリングする Colin Weld Member of Technical Staff Connor Adams Member of Technical Staff Modalでは、サンドボックスなどを構築しています。エージェントはサンドボックス内で実行され、エージェントはソフトウェアを食い尽くしています。現在、Modalは1日あたり数百万のサンドボックスを実行し、顧客あたり最大5万の同時実行サンドボックスをサポートし、強化学習からバックグラウンドエージェントまで、さまざまなユースケースを大規模にサポートしています。 ますます多くのユーザーが、より高いレートで作成される、より多くのサンドボックスを必要としています。強化学習では、数百万のサンドボックスを同時に実行する必要があり、ロールアウトの開始時に数十万のサンドボックスのバーストを作成する必要があります。同様に、エージェントはトラフィックバーストに対処するために、ますます大規模なスケールと高い同時作成レートを必要としています。 既存のサンドボックスプラットフォームは非常に優れていますが、これらのスケール向けには設計されていませんでした。他の既存のソリューションも同様です。私たちはスケールとパフォーマンスに執着しており、私たちのインフラストラクチャがエージェントの成長を加速させ、摩擦を加えないようにしたいと考えています。そこで、私たちはゼロからやり直しました。 過去数ヶ月にわたり、私たちはスケールと信頼性の両方を考慮して、コアサンドボックスプラットフォームをゼロから再構築しました。新しいシステムでは、ユーザーは数百万のサンドボックスを同時に実行でき、毎秒数万のサンドボックスを作成できます。コントロールプレーンからすべての中央ボトルネックを削除したため、実質的なスケーリング制限はなく、コンテナスケジューリングと起動のすべての部分を最適化し、スケジューリングパスをワーカーフリートに直接コンテナを作成するロードバランサーのレイヤーに単純化しました。 私たちのプラットフォームの能力を示すデモンストレーションとして、100万のサンドボックスを同時に実行し、すべてを1分未満で作成しました。これは、私たちが多くのサンドボックスを実行できることの証拠です。 なぜほとんどのソリューションはスケールしないのか 100万のサンドボックスを実行することは、コンテナプラットフォームの限界を押し広げます。これは、コンテナの絶対数だけでなく、これほど多くのサンドボックスを実行するには数万ものコンピューティングノードが必要になるためです。多くの操作はO(コンテナ)、O(ノード)、またはその両方であり、従来のコンテナプラットフォームをスケーリング制限に達させます。 例えばKubernetesの場合： スケジューリングアルゴリズムは、最悪の場合、nノードとpポッドに対してO(n x p)であり、スケジューリングはデフォルトでシリアル化されます。 各ポッドは、そのライフサイクル中にetcd（中央のKubernetes永続ストア）に複数の書き込みを行い、高いポッド作成レートまたは高いポッドチャーン下で深刻な問題を引き起こす可能性があり、etcdはネイティブではキー空間内でシャーディングできません。 各ノードは、ポッド作成とは完全に独立したO(ノード)のベースラインetcd書き込み負荷をシグナルするために、ハートビート間隔ごとに少なくとも1回はetcdに書き込む必要があります。 Kubernetesスケジューリングフローの近似。新しいポッドは、APIサーバーによってetcd（強く一貫した永続ストア）に書き込まれます。Kubernetesスケジューラは、新しい未割り当てのポッドを監視し、APIサーバーへの呼び出しを通じてノードにそれらを割り当てます。この書き込みが完了すると、ノードはポッドを開始できます。 Kubernetesはスケール可能ですが、それにはかなりの作業が必要です。多数のノードを実行するには、etcdを書き換えるか置き換える必要があります。高いスケジューリングスループットをサポートするには、ポッド状態の単一の真実のソースを維持しながら、スケジューリングアルゴリズムを並列化するための複雑な散布・収集システムを構築する必要があります。Kubernetesは設計のバックボーンとして強い一貫性に依存しているため、シャーディングと並列化はデフォルトでは容易ではありません。 Modalの元のサンドボックスアーキテクチャにも同様の問題がありました。Kubernetesと同様に、バックエンド全体で強い一貫性に依存しているため、サンドボックスの作成とスケジューリングにはグローバルな調整が必要であり、PostgresへのO(サンドボックス)書き込みが発生します。これは簡単にシャーディングできません。 Modalの元のサンドボックスコントロールプレーンアーキテクチャ。 サンドボックスが作成されると、キューに入れられ、Postgresに書き込まれます。スケジューリングは楽観的で並列に実行されますが、競合を避けるために中央の調整が必要です。サンドボックスをワーカー（コンピューティングノード）に割り当てるには、Postgresへの追加の書き込みが必要です。 Kubernetes上に構築していないため、このシステムの多くの部分をスケールアウトできました。例えば、スケジューリングはデフォルトで並列化されており、非常に高いバーストサンドボックス作成レートを達成できます。しかし、ノード数とサンドボックス数をますます大きくスケールしていくにつれて、O(サンドボックス)またはO(ノード)の操作から生じる新しいボトルネックに継続的に遭遇し、それらをスケールアウトするのは容易ではありませんでした。 例えば、完了した各サンドボックスに対して永続的なワークフローを実行しているため、高いサンドボックスチャーンレートは大規模なイベントバックログを作成します。システム全体に予期しない負荷の問題を引き起こすO(サンドボックス)レートで呼び出されるRPCに繰り返し遭遇しました。また、多数のサンドボックスを実行するために必要なノードの絶対数が、ノード管理とオートスケーリングにおける複数の下流問題を引き起こしました。最後に、それを回避できましたが、シャーディングされていないPostgresインスタンスをすべてのサンドボックス作成とスケジューリングのクリティカルパスに残すことは悪い考えであることが証明されました。 無限のスケーリングを解除する 私たちが望むスケールを達成するには、アーキテクチャを根本から再考する必要があることをすぐに理解しました。数百万のサンドボックスを実行し、毎秒数万のサンドボックスを作成したいと考えており、これには既存のどのシステムよりもはるかに優れたスケーリング特性が必要です。既存のものを進化させようとするのではなく、最も速くクリーンな道はゼロから始めることだと信じていました。 スケールを最適化するために、O(サンドボックス)またはO(ノード)の負荷がかかるすべてはデフォルトで水平スケーラブルでなければならず、サンドボックス作成パスは可能な限りシンプルでなければならず、それ以外は二次的であると決定しました。私たちが到達した解決策は、既存のシステムとは著しく異なります。中央調整のいかなる形態も完全に廃止し、グローバルな一貫性をサンドボックスの実行と作成のクリティカルパス全体のスケーラビリティとパフォーマンスと交換しました。仕組みは次のとおりです。 単一のシリアル化されたスケジューラの代わりに、サンドボックス作成リクエストを並行して処理するスケジューリングサーバーのフリートを実行します。作成リクエストを処理するために、スケジューリングサーバーはインメモリキャッシュデータに対して高速なスケジューリングアルゴリズムを実行します。その結果、スケジューリングは水平にスケールし、従来のコンテナスケジューリングよりもロードバランシングのように見えます。 ほとんどのコンテナプラットフォームが機能する方法である、サンドボックスとワーカーの状態の真実の単一の永続データストアの代わりに、新しいシステムでは各ワーカーが独自の真実のソースです。ワーカーは定期的にRedisストリームに状態を発行します。スケジューリングサーバーは、この状態を非同期に消費し、スケジューリングの決定に使用します。スケジューリングサーバーがどのワーカーにサンドボックスを作成するかを決定すると、RPCを介して直接ワーカーに連絡してサンドボックスの作成を要求します。ワーカーは、利用可能なリソースがあればスケジューリングリクエストを受け入れ、そうでなければ拒否します。 サンドボックス作成のクリティカルパスにはデータストアがまったくなく、スケーラビリティと信頼性が向上します。サンドボックスメタデータと結果を永続ストレージに書き込む必要はありますが、主に非同期で行います。 サンドボックス作成以外では、O(サンドボックス)のRPCはありません。ワーカーは、データ指向設計のアイデアの精神で、単一のRPCに複数のサンドボックスの制御メッセージをまとめてバッチ処理します。 私たちが最初にホワイトボードしたときの最終的な設計。 Modalのv2サンドボックスアーキテクチャのサンドボックス作成パス。 サンドボックス作成リクエストは、水平にスケールされたスケジューリングサーバーによって処理され、次にインメモリの高速ロードバランシングアルゴリズムを使用してワーカーを選択し、サンドボックスを作成するために直接ワーカー（コンピューティングノード）に連絡します。サンドボックスオブジェクトはRedisに保存されますが、クリティカルパスにはありません。 その結果、サンドボックス作成パスはわずか2回のネットワークホップと1回の低コストCPUしか必要としません。