MultiKueue の活用により GKE クラスタであらゆるロケーションの GPU が利用可能
Jean-Baptiste Leroy
Customer Engineer
※この投稿は米国時間 2025 年 2 月 15 日に、Google Cloud blog に投稿されたものの抄訳です。
AI や大規模言語モデル(LLM)が飛躍的に発展し、機械翻訳から芸術的な創作に至るまで、さまざまなユースケースを支えています。これらのテクノロジーは、大量のデータを処理するために、GPU など専用のハードウェア リソースを必要とします。しかし、GPU へのアクセスは、可用性と費用の両面で課題となる場合があります。
Google Cloud では、Dynamic Workload Scheduler(DWS)の導入により、特に Google Kubernetes Engine(GKE)クラスタ内での GPU リソースのアクセス方法と使用方法が変わりました。Dynamic Workload Scheduler は、さまざまな Google Cloud サービスにわたり TPU や GPU などの必要なアクセラレータを同時にスケジュールすることで、AI / ML リソースのアクセスと費用を最適化し、トレーニング ジョブやファインチューニング ジョブのパフォーマンスを向上させるものです。
さらに、Dynamic Workload Scheduler では、GKE と Kueue(クラウドネイティブなジョブ スケジューラ)の簡単かつシンプルな統合も可能です。これにより、特定のリージョンで、特定の GKE クラスタが、可能な限り迅速に GPU にアクセスできるようになります。
しかし、Dynamic Workload Scheduler によってワークロードに必要なリソースが提供され次第、ロケーションを問わず利用可能なリージョンに、ワークロードをすぐにデプロイしたい場合もあります。
この場合に有効なのが、Kueue の機能の一つである MultiKueue です。MultiKueue、GKE、Dynamic Workload Scheduler を使用すると、複数のリージョンでアクセラレータを待機できます。Dynamic Workload Scheduler は、リソースが利用可能になり次第、そのリソースを最適な GKE クラスタに自動的にプロビジョニングします。ワークロードをグローバル キューに送信すると、MultiKueue が、利用可能な GPU リソースがあるリージョンでそのワークロードを実行し、グローバル リソースの使用量の最適化、費用削減、処理の高速化を実現します。
MultiKueue
MultiKueue は、異なるリージョンにある複数の GKE クラスタにワークロードを分散できます。利用可能なリソースを持つクラスタを特定することで、ジョブを最適なロケーションに割り当てるプロセスが簡素化されます。
GKE Autopilot での Dynamic Workload Scheduler の利用は、GKE Autopilot 1.30.3 でサポートされています。GKE Autopilot は、Google のマネージド Kubernetes サービスであり、コンテナ インフラストラクチャのプロビジョニング、スケーリング、セキュリティ、メンテナンスを自動的に処理するものです。Dynamic Workload Scheduler で MultiKueue を設定および管理し、GPU リソースをより迅速に取得する方法を詳しく見ていきましょう。
MultiKueue クラスタのロール
MultiKueue には、以下の 2 つのクラスタロールがあります。
-
マネージャー クラスタ: ワーカー クラスタとの接続を確立および維持します。また、リモート オブジェクト(ワークロードやジョブ)を作成およびモニタリングしつつ、ローカル オブジェクトの同期を維持します。
-
ワーカー クラスタ: マネージャー クラスタから送信されたジョブを実行するシンプルなスタンドアロンの Kueue クラスタです。
MultiKueue クラスタの作成
この例では、GKE Autopilot クラスタを 4 つ作成します。
-
マネージャー クラスタ 1 つ(europe-west4 リージョン内)
-
ワーカー クラスタ 3 つ(以下のリージョン内)
-
europe-west4
-
us-east4
-
asia-southeast1
以下の例を使用して、詳細な手順を見ていきましょう。この例のファイルは、GitHub リポジトリで参照できます。
1. GitHub リポジトリのクローンを作成する
2. GKE クラスタを作成する
この terraform スクリプトにより、必要な GKE クラスタが作成され、kubeconfig ファイルに以下の 4 つのエントリが追加されます。
-
manager-europe-west4
-
worker-us-east4
-
worker-europe-west4
-
worker-asia-southeast1
以下のコマンドを使用して、コンテキストを簡単に切り替えることができます。
3. MultiKueue をインストールして構成する
このスクリプトでは、以下の処理が行われます。
-
4 つのクラスタに Kueue をインストールする
-
マネージャー クラスタで MultiKueue を有効化して構成する
-
各クラスタに podMonitoring リソースを作成し、Kueue 指標を Google Cloud Managed Service for Prometheus に送信できるようにする
-
マネージャー クラスタとワーカー クラスタとの接続を構成する
-
ワーカー クラスタで Kueue を構成する
以上で、GKE クラスタ、Kueue と MultiKueue、DWS が構成され、使用可能な状態になりました。ジョブを送信すると、Kueue マネージャーによって 3 つのワーカー クラスタに分散されます。
dws-multi-worker.yaml ファイルには、マネージャー構成を含むワーカー クラスタ用の Kueue 構成が記載されています。
以下のスクリプトは、3 つのワーカー クラスタで MultiKueue AdmissionCheck を設定する基本的な例を示しています。
4. ジョブを送信する
ジョブを送信する際には、マネージャーの kubecontext を使用していることを確認してください。
MultiKueue AdmissionCheck がワーカー クラスタ間でジョブをどのように分散するかをモニタリングするには、ジョブ作成リクエストを複数回送信します。
5. ジョブのステータスを取得する
ジョブのステータスと、スケジュールされたリージョンを確認するには、以下のコマンドを実行します。
6. リソースを削除する
最後に、この機能を試すために作成した 4 つの GKE クラスタを必ず削除します。
次のステップ
MultiKueue、GKE、DWS を活用してグローバルなジョブの実行を効率化し、処理速度を最適化し、手動でのノード管理を不要にする方法を説明しました。
この構成は、データ所在地の要件がある場合のニーズにも対応しており、ワークロードごとにクラスタのサブセットを割り当てることでコンプライアンスを確保できます。
この構成をさらに強化するには、Local Queue や Workload Priority Class を使用して、チーム管理といった高度な Kueue 機能を活用できます。また、Grafana や Cloud Monitoring のダッシュボードを作成し、PodMonitoring リソース経由で Google Managed Service for Prometheus によって自動的に処理される Kueue 指標を利用することで、有益なインサイトを得ることもできます。
- カスタマー エンジニア Jean-Baptiste Leroy