130,000 ノードの GKE クラスタを構築した方法

Google Cloud では、常にスケーラビリティを推進しています。 Google Kubernetes Engine (GKE) これにより、ますます要求が厳しくなるワークロード、特に AI に対応できるようになります。 GKE はすでに 大規模なサポート 65,000 ノードのクラスターそして、KubeCon では、 実験モードの 130,000 ノードのクラスター — 公式にサポートおよびテストされた制限と比較して、ノード数が 2 倍。

この種のスケーリングは、単にノードの数を増やすだけではありません。また、次のような他の重要な次元をスケーリングすることも必要です。 ポッドの作成 そして スループットのスケジューリング。たとえば、このテスト中、Pod スループットは次のように維持されました。 1 秒あたり 1,000 ポッド、また上に保管する 100万個のオブジェクト 最適化された分散ストレージで。このブログでは、この種のメガ クラスターの需要を促進する傾向を考察し、この極端なスケーラビリティを実現するために実装したアーキテクチャの革新について詳しく説明します。

メガクラスターの台頭

我々 の最大の顧客は、AI ワークロードを使用して GKE のスケーラビリティとパフォーマンスの限界を積極的に押し広げています。実際、当社ではすでに 20 ～ 65,000 ノードの範囲でクラスターを運用している多くのお客様を抱えており、大規模クラスターの需要は 100,000 ノード付近で安定すると予想しています。

これにより、興味深いダイナミクスが生まれます。つまり、私たちはチップの供給に制約される世界から、電力に制約される世界に移行しつつあるのです。 1 つの NVIDIA GB200 GPU には 2700 W の電力が必要であるという事実を考慮してください。これらのチップを数万個、あるいはそれ以上使用すると、単一クラスターの消費電力を簡単に数百メガワットに拡張でき、複数のデータセンターに分散するのが理想的です。したがって、100,000 ノードを超える AI プラットフォームの場合、クラスターやデータセンター全体で分散トレーニングや強化学習を調整できる堅牢なマルチクラスター ソリューションが必要になります。これは重要な課題であり、私たちは次のようなツールに積極的に投資しています。 マルチキュー この問題に対処するには、さらなるイノベーションが目前に迫っています。また、最近発表された、高性能 RDMA ネットワーキングも推進しています。 マネージドDRANET、トポロジ認識を向上させ、大規模な AI ワークロードのパフォーマンスを最大化します。乞うご期待。

同時に、これらの投資は、より小規模な規模で運用しているユーザー、つまり GKE 顧客の大多数にも利益をもたらします。極端な使用に備えて GKE のコア システムを強化することで、平均的なクラスタにかなりの余裕が生まれ、エラーに対する耐性が高まり、ユーザーによる Kubernetes API の誤用に対する耐性が高まり、パフォーマンスが向上するようにすべてのコントローラが全体的に最適化されます。そしてもちろん、大小を問わずすべての GKE 顧客は、直感的なセルフサービス エクスペリエンスへの投資から恩恵を受けます。

主要なアーキテクチャ上の革新

そうは言っても、このレベルのスケールを達成するには、コントロール プレーン、カスタム スケジューリング、ストレージなど、Kubernetes エコシステム全体にわたる大幅な革新が必要です。このプロジェクトにとって重要ないくつかの重要な領域を見てみましょう。

最適化された読み取りスケーラビリティ

大規模に運用する場合、一貫性が高く、スナップショットが可能な API サーバー監視キャッシュが必要になります。 130,000 ノードでは、API サーバーへの膨大な量の読み取りリクエストにより、中央のオブジェクト データストアが圧倒される可能性があります。これを解決するために、Kubernetes には、これらの読み取りリクエストを中央のオブジェクト データストアからオフロードするためのいくつかの補完的な機能が含まれています。

まず、キャッシュからの整合性読み取り機能 (KEP-2340) について詳しく説明します。 ここにより、API サーバーがメモリ内キャッシュから強力な一貫性のあるデータを直接提供できるようになります。これにより、リクエストを処理する前にキャッシュのデータが検証可能に最新であることが保証されるため、フィルタリングされたリストリクエスト（「特定のノード上のすべてのポッド」など）などの一般的な読み取りパターンに対するオブジェクトストレージデータベースの負荷が大幅に軽減されます。

この基盤に基づいて構築されたスナップショット可能 API サーバー キャッシュ機能 (KEP-4988) は、API サーバーが以前の状態の LIST リクエストを (ページネーションを介して、または指定することによって) 処理できるようにすることで、パフォーマンスをさらに向上させます。 resourceVersion) 同じ一貫した監視キャッシュから直接。特定のリソース バージョンでキャッシュの B ツリー「スナップショット」を生成することにより、API サーバーはデータストアに繰り返しクエリを実行することなく、後続の LIST リクエストを効率的に処理できます。

これら 2 つの機能強化により、読み取り増幅の問題が解決され、強力な一貫性のあるフィルター処理された読み取りと以前の状態のリスト要求の両方をメモリから直接処理することで、API サーバーの高速性と応答性が確保されます。これは、クラスター全体のコンポーネントの健全性を極めて大規模に維持するために不可欠です。

最適化された分散ストレージ バックエンド

クラスターの大規模なスケールをサポートするために、Google の Spanner 分散データベースに基づく独自の Key-Value ストアを利用しました。 130K ノードでは、リース オブジェクトの更新に 13,000 QPS が必要で、ノードのヘルス チェックなどの重要なクラスター操作がボトルネックにならないようにし、システム全体が確実に動作するために必要な安定性を提供しました。新しいストレージ システムに関してボトルネックは見られず、より大規模なストレージ システムをサポートできない兆候は見られませんでした。

高度なジョブ キューイング用の Kueue

デフォルトの Kubernetes スケジューラーは、個々の Pod をスケジュールするように設計されていますが、複雑な AI/ML 環境では、より高度なジョブレベルの管理が必要です。 シェイク は、バッチ システム機能を Kubernetes にもたらすジョブ キュー コントローラーです。公平な共有ポリシー、優先順位、リソース割り当てに基づいてジョブを「いつ」許可するかを決定し、ジョブ全体の「オール・オア・ナッシング」スケジューリングを可能にします。デフォルトのスケジューラの上に構築された Kueue は、ベンチマークにおける競合するトレーニング、バッチ、推論ワークロードの複雑な組み合わせを管理するために必要なオーケストレーションを提供しました。

スケジューリングの未来: ワークロード認識の強化

Kueue のジョブレベルのキューイングを超えて、Kubernetes エコシステムはその中核でワークロードを認識したスケジューリングに向けて進化しています。目標は、スケジューリングに対するポッド中心のアプローチからワークロード中心のアプローチに移行することです。これは、スケジューラがワークロード全体のニーズを 1 つの単位として考慮し、利用可能な容量と潜在的な容量の両方を網羅して配置を決定することを意味します。この全体的なビューは、特に AI/ML トレーニングと推論ワークロードの新しい波において、価格パフォーマンスを最適化するために重要です。

新しい Kubernetes スケジューラの重要な側面は、Kubernetes 内でのギャング スケジューリング セマンティクスのネイティブ実装です。この機能は現在、Kueue などのアドオンによって提供されています。コミュニティはこれに積極的に取り組んでいます。 KEP-4671: ギャングのスケジュール設定。

やがて、コア Kubernetes でのワークロード認識スケジューリングのサポートにより、GKE 上での大規模で密結合されたアプリケーションのオーケストレーションが簡素化され、要求の厳しい AI/ML および HPC ユースケースに対してプラットフォームがさらに強力になります。また、GKE 内の第 2 レベルのスケジューラとして Kueue を統合することにも取り組んでいます。

データアクセス用の GCS FUSE

AI ワークロードはデータに効率的にアクセスできる必要があります。一緒に、 クラウドストレージFUSE 並行ダウンロードと キャッシング 有効化され、ゾーンとペアリングされている どこでもキャッシュにより、ローカル ファイル システムであるかのように Cloud Storage バケット内のモデル データにアクセスできるようになり、レイテンシが最大 70% 削減されます。これにより、分散ジョブまたはスケールアウト推論ワークフローにデータをフィードするための、スケーラブルで高スループットのメカニズムが提供されます。あるいは、 Google Cloud マネージド Lustreは、マルチペタバイトの容量、TB/秒のスループット、ミリ秒未満のレイテンシを必要とするワークロードをサポートする、フルマネージドの永続ゾーン ストレージ ソリューションです。 AI/ML ワークロードのストレージ オプションについて詳しく知ることができます ここ。

大規模で動的な AI ワークロードに対する GKE のベンチマーク

大規模な AI / ML ワークロードでの GKE のパフォーマンスを検証するために、複雑なリソース管理、優先順位付け、スケジュール設定の課題を伴う動的環境をシミュレートする 4 フェーズのベンチマークを設計しました。これは、で使用されるベンチマークに基づいています。 前回の 65K ノード規模のテスト。

異なる優先度クラスを持つワークロードを使用して、混合ワークロードをホストする典型的な AI プラットフォームを表すようにベンチマークをアップグレードしました。

• 優先度が低い: データ準備ジョブなどのプリエンプティブル バッチ処理。

• 中優先度: 重要ですが、多少のキューイングは許容できるコア モデル トレーニング ジョブ。

• 高優先度: リソースを保証する必要がある、遅延に敏感なユーザー向けの推論サービス。

クォータとリソース共有を管理するために Kueue を使用し、トレーニング ジョブを管理するために JobSet を使用してプロセスを調整しました。

フェーズ 1: 大規模なトレーニング ジョブによるパフォーマンスのベースラインの確立

まず、単一の大規模トレーニング ワークロードをスケジュールして、クラスターの基本的なパフォーマンスを測定します。 1 つを導入します JobSet 実行するように構成されている 130,000 中優先度のポッド 同時に。この初期テストにより、ポッドの起動レイテンシーや全体的なスケジューリング スループットなどの主要なメトリクスのベースラインを確立でき、クリーンなクラスター上で大量のワークロードを起動する際のオーバーヘッドが明らかになります。これにより、より複雑な条件下で GKE のパフォーマンスを評価するための準備が整いました。実行後、このジョブセットをクラスターから削除し、フェーズ 2 用に空のクラスターを残しました。