最近の記事では、Modal エンジニアの Colin Weld と Connor Adams が、数百万の同時サンドボックスと 1 秒あたり数万のサンドボックス作成をサポートするために、サンドボックス インフラストラクチャをゼロから再構築した方法について説明しています。
Weld 氏と Adams 氏によると、Kubernetes のような従来のコンテナ オーケストレーション システムは、一元化された調整と一貫性の高い状態に大きく依存しているため、この規模での運用が困難です。
100 万個のサンドボックスを実行すると、コンテナーの数が膨大であることと、その数のサンドボックスを実行するには何万ものコンピューティング ノードが必要になるため、コンテナ プラットフォームの限界が押し上げられます。 O (コンテナ)、O (ノード)、またはその両方の操作が多くなり、従来のコンテナ プラットフォームがスケーリングの限界に達する原因となります。
Kubernetes の場合、スケジューリング アルゴリズムと耐久性のある中央リポジトリの両方に負担がかかると彼らは説明しています (etcd) はノードとポッドの数に応じて増加します。さらに、ポッドとノードの両方が書き込みます。 etcd 「ブリッジ作成率やブリッジ率が高いと深刻な問題が発生する可能性があり、etcd をキースペースでネイティブにシャーディングすることはできません。」また、これらの制限を克服することは実現可能だが、書き換えや置き換えなどの「真剣な作業」が必要であるとも指摘している。 etcd そしてプログラミングアルゴリズムの並列化。
スケーリングを最適化するために、O (サンドボックス) または O (ノード) 負荷を持つすべてのものはデフォルトで水平方向にスケーラブルであるべきであり、サンドボックス作成パスは可能な限り単純であるべきであり、その他はすべて二次的なものであるべきであると決定しました。
Modal エンジニアが自社のプラットフォームに加えた根本的な変更は、グローバルな調整をやめ、スケジューリングを負荷分散に近づけることでした。真実の情報源として中央のデータ リポジトリに依存するのではなく、各従業員が独自の真実の情報源になりました。また、単一のシリアル化されたスケジューラーを使用する代わりに、並列して動作する一連のスケジューリング サーバーを実装し、スケジューリング レイヤーを水平方向に拡張できるようにしました。
スケジュール サーバーは、サンドボックスを作成するワーカーを決定すると、RPC 経由でワーカーに直接連絡し、サンドボックスの作成を要求します。ワーカーは、空きリソースがある場合はスケジュール要求を受け入れ、そうでない場合はスケジュール要求を拒否します。
彼らによれば、結果として得られるアーキテクチャには 1 つのボトルネックがあります。それは、すべてのワーカーが自分の状態を単一の Redis ストリームとして公開することです。ただし、「負荷テストでは、これが 100,000 人以上の労働者まで実行可能であることが示唆されています。」ベンチマークでは、1 分未満で 100 万個のサンドボックスを作成し、エンコード開始までの平均時間は 0.5 秒未満でした。
Hopsworks CEO の Jim Dowling 氏は、LinkedIn での発表についてコメントし、「規模が桁違いに増加するたびに新たな技術的問題が発生する」と述べ、信頼性の高い 1 秒あたり 50,000 件のサンドボックス作成を達成するには、チームが設計を複数回繰り返す必要があることを示唆しました。さらに、AWS の主任人工知能エンジニアである Alex Jones 氏は、Modal の成果の重要な部分は、Kubernetes を拡張しようとしたのではなく、その限界を理解した上で「全体を歩き回った」ことにあると述べました。 Jones 氏は、これを「Kubernetes が GenAI インフラストラクチャが実際に必要とするものに十分早く適応していないことを示す、最初の信頼できるシグナル」であると見なし、次のように主張しています。
私たちは実行調整の分離に向けて取り組んでいます。実行計画は、Modal が構築したものを必要とします。ミリ秒単位で表示される分離制限。コーディネーション プレーン (マルチエージェント ワークフローが共有メモリと重複するセキュリティ境界を必要とする場所) では、依然として Kubernetes のようなシステムが適していることが必要です。
Modal は、AI ワークロード専用に構築されたサーバーレス コンピューティング プラットフォームで、CPU、GPU、コンテナ、推論、トレーニング、バッチ ジョブ、分離されたサンドボックスへのプログラム可能なアクセスを提供します。拡張性の高いインフラストラクチャと 10 ミリ秒未満のコールド スタートを中心に「クラウドの再構築」を検討しているのは、同社だけではありません。同様の目標を追求する他のプロジェクトには、Unikraft、Google Substrate、Overdrive などがあります。
