Flex Start プロビジョニング モードでの GPU と TPU のプロビジョニングについて

このページでは、Google Kubernetes Engine（GKE）のフレックス開始プロビジョニング モードについて説明します。Dynamic Workload Scheduler を活用した Flex Start は、AI/ML ワークロードを実行する必要があるときに GPU と TPU を取得するための柔軟で費用対効果の高い手法です。

Flex Start を使用すると、特定の開始時間に制限されることなく、長期予約を管理することなく、最大 7 日間、必要に応じて GPU と TPU を動的にプロビジョニングできます。したがって、Flex Start は、需要要件が変動したり、期間が短い場合の小規模から中規模のワークロードに適しています。たとえば、小規模なモデルの事前トレーニング、モデルのファインチューニング、スケーラブルなサービング モデルなどです。

このページの情報は、次のことに役立ちます。

• GKE の flex-start の仕組みを理解する。
• フレックスタイム制がワークロードに適しているかどうかを判断します。
• ワークロードに適したフレックス開始構成を決定します。
• flex-start を使用する際の中断を管理する。
• GKE での Flex Start の制限事項を理解する。

このページは、ワークロードに合わせてアクセラレータ インフラストラクチャを最適化したいプラットフォーム管理者とオペレーター、ML エンジニアを対象としています。

flex-start を使用する場合

ワークロードが次のすべての条件を満たしている場合は、flex-start を使用することをおすすめします。

• ワークロードに GPU リソースが必要である。
• ワークロードに、単一ホストの TPU スライス ノードプールで実行される TPU リソースが必要です。
• 予約済みの GPU または TPU 容量が限られているかゼロであり、これらのアクセラレータへのより信頼性の高いアクセスが必要である。
• ワークロードに時間的な制約がなく、リクエストしたすべての容量を取得するまで待つことが可能なユースケースである。たとえば、ピーク時以外に GPU リソースを GKE が割り当てる場合などです。

要件

GKE で flex-start を使用するには、クラスタが次の要件を満たしている必要があります。

• GPU を実行するには、GKE バージョン 1.32.2-gke.1652000 以降を使用します。

• TPU を実行するには、GKE バージョン 1.33.0-gke.1712000 以降を使用します。Flex-start は、次のバージョンとゾーンをサポートしています。

  • asia-northeast1-b と us-east5-a の TPU Trillium（v6e）。
  • us-west4-a の TPU v5e。
  • us-east5-a の TPU v5p。

  TPU v3 と v4 はサポートされていません。

Flex Start プロビジョニング モードの仕組み

flex-start では、ワークロードで必要な GPU または TPU の容量を指定します。また、Standard クラスタでは、特定のノードプールで Flex Start を構成します。GKE は、容量が使用可能になると、次のプロセスを完了して VM を自動的にプロビジョニングします。

1. ワークロードが、すぐに使用できない容量をリクエストしている。このリクエストは、ワークロード仕様で直接行うことも、カスタム コンピューティング クラスや Kueue などのスケジューリング ツールを使用して行うこともできます。
2. GKE は、ノードでフレックス開始が有効であり、ワークロードが無期限に待機できることを特定します。
3. クラスタ オートスケーラーがユーザーのリクエストを受け入れ、必要なノードの数を計算します（それらのノードは 1 つのユニットとして扱われます）。
4. クラスタ オートスケーラーは、必要なノードが利用可能になった時点でプロビジョニングします。これらのノードは最大 7 日間実行されます。maxRunDurationSeconds パラメータに値を指定すると、それより短い時間実行されます。このパラメータは、GKE バージョン 1.28.5-gke.1355000 以降で使用できます。maxRunDurationSeconds パラメータに値を指定しない場合、デフォルトは 7 日間です。
5. maxRunDurationSeconds パラメータで定義した実行時間が経過すると、ノードと Pod はプリエンプトされます。
6. Pod がそれより前に終了し、ノードが使用されなくなった場合、クラスタ オートスケーラーは自動スケーリング プロファイルに従ってノードを削除します。

GKE は、各 Flex Start リクエストの所要時間をノードレベルでカウントします。起動時の遅延により、Pod を実行可能な時間は若干短くなることもあります。Pod の再試行ではこの時間が共有されるため、再試行後には Pod を実行可能な時間が短くなります。GKE では、フレックス開始リクエストごとに時間がカウントされます。

Flex Start 構成

GKE は、次のフレックス開始構成をサポートしています。

• Flex Start: GKE がノードをまたいでリソースを割り振ります。この構成では、ノードの作成時に --flex-start フラグを設定するだけで済みます。

• キューに格納されたプロビジョニングでの Flex Start。GKE はリクエストされたすべてのリソースを同時に割り振ります。この構成を使用するには、ノードプールの作成時に --flex-start フラグと enable-queued-provisioning フラグを追加する必要があります。GKE は、このドキュメントのFlex Start プロビジョニング モードの仕組みのプロセスに従いますが、次の条件も適用します。

  • スケジューラは、リクエストされたすべてのリソースが単一のゾーンで使用可能になるまで待機します。
  • 新しくプロビジョニングされたノードで、ワークロードのすべての Pod を同時に実行できます。
  • プロビジョニングされたノードは、ワークロードの実行間で再利用されません。

次の表に、フレックス開始の構成を比較します。

Flex Start 構成を最適化する

堅牢で費用対効果の高い AI/ML インフラストラクチャを構築するには、フレックス開始構成と利用可能な GKE 機能を組み合わせることができます。コンピューティング クラスを使用して、ワークロードの要件に基づいて優先順位付けされたノードの構成リストを定義することをおすすめします。GKE は、可用性と定義された優先度に基づいて、最も適切な構成を選択します。

Dynamic Workload Scheduler を使用するワークロードの中断を管理する

ノードプール内のすべてのノードまたはほとんどのノードが利用可能であることを必要とするワークロードは、強制排除の影響を受けやすくなります。また、Dynamic Workload Scheduler リクエストを使用してプロビジョニングされたノードは自動修復をサポートしていません。自動修復では、ノードからすべてのワークロードが削除されるため、ワークロードは実行されなくなります。

クラスタ コントロール プレーンが Flex Start の最小バージョン（1.32.2-gke.1652000 以降）を実行している場合、Flex Start、キューに格納されたプロビジョニング、またはその両方を使用するすべてのノードは、短時間のアップグレードを使用します。

短時間のアップグレードは、実行中のノードを中断することなく、Autopilot クラスタ内の Standard ノードプールまたはノードのグループを更新します。新しいノードは新しい構成で作成され、時間の経過とともに既存のノードが古い構成に徐々に置き換えられます。フレックス開始または短時間のアップグレードをサポートしていない以前のバージョンの GKE では、別のベスト プラクティスが必要です。

短時間のアップグレードを使用するノードのワークロードの中断を最小限に抑えるためのベスト プラクティス

クラスタがバージョン 1.32.2-gke.1652000 以降を実行している場合、Flex Start ノードとキューに格納されたプロビジョニングを使用するノードは、短時間のアップグレードを使用するように自動的に構成されます。

存続期間の短いアップグレードを使用するノードで実行されているワークロードの中断を最小限に抑えるには、次のタスクを実行します。

• メンテナンスの時間枠と除外を構成して、GKE が自動メンテナンスを行う時間を確保しながら、GKE がノードのアップグレードなどの更新オペレーションを実行するタイミングと実行しないタイミングを設定します。
• ノードの自動修復を無効にします。

1.32.2-gke.1652000 より前のバージョンを実行しているクラスタのノード（短時間のアップグレードを使用していないノード）については、そのノードの具体的なガイダンスをご覧ください。

短時間のアップグレードなしでキューに登録されたプロビジョニング ノードのワークロードの中断を最小限に抑えるためのベスト プラクティス

1.32.2-gke.1652000 より前の GKE バージョンを実行しているクラスタでキューに格納されたプロビジョニングを使用するノードは、短時間のアップグレードを使用しません。既存のキューに入れられたプロビジョニング ノードを使用して 1.32.2-gke.1652000 以降にアップグレードされたクラスタは、短時間のアップグレードを使用するように自動的に更新されます。

これらの以前のバージョンを実行しているノードについては、次のガイダンスをご覧ください。

• クラスタのリリース チャンネルの登録に応じて、次のベスト プラクティスを使用して、ノードの自動アップグレードによってワークロードが中断されないようにします。
  • クラスタがリリース チャンネルに登録されている場合は、メンテナンスの時間枠と除外を使用して、ワークロードの実行中に GKE がノードを自動的にアップグレードしないようにします。
  • クラスタがリリース チャンネルに登録されていない場合は、ノードの自動アップグレードを無効にします。ただし、より細かいスコープでメンテナンスの除外を使用できるリリース チャンネルを使用することをおすすめします。
• ノードの自動修復を無効にします。
• メンテナンスの時間枠と除外を使用して、実行中のワークロードが停止することでの影響を最小限に抑えながら、GKE が引き続き自動メンテナンスを実施できる時間を確保します。実行中のワークロードがない時間をスケジュールしてください。
• ノードプールを最新の状態に保つには、Dynamic Workload Scheduler リクエストがアクティブではなく、ノードプールが空であるときに、ノードプールを手動でアップグレードします。

クラスタが短時間のアップグレードに移行する場合の考慮事項

GKE は、クラスタがバージョン 1.32.2-gke.1652000 以降にアップグレードされたときに、キューに格納されたプロビジョニングを使用して既存のノードを更新し、短時間のアップグレードを使用します。GKE は、特定のノードプールで無効にしたノードの自動アップグレードを有効にするなど、他の設定は更新しません。

ノードプールで短時間のアップグレードを使用する場合は、次のベスト プラクティスの実装を検討することをおすすめします。

• --no-enable-autoupgrade フラグを使用してノードの自動アップグレードを無効にした場合、この移行ではノードプールのノードの自動アップグレードが再度有効になりません。短時間のアップグレードは既存のノードとその上で実行されるワークロードに影響しないため、ノードの自動アップグレードを有効にすることをおすすめします。詳細については、短期アップグレードをご覧ください。
• また、クラスタがリリース チャンネルに登録されていない場合は、クラスタを登録して、より詳細なメンテナンス除外スコープを使用できるようにすることをおすすめします。

Flex Start でのノードのリサイクル

ノードのスムーズな移行を確実にし、実行中のジョブのダウンタイムを回避するために、flex-start はノードのリサイクルをサポートしています。ノードの有効期間が終了すると、GKE はノードを新しいノードに自動的に置き換えて、実行中のワークロードを保持します。

ノードのリサイクルを使用するには、カスタム コンピューティング クラス プロファイルを作成し、leadTimeSeconds パラメータを使用して flexStart 仕様に nodeRecycling フィールドを含める必要があります。

leadTimeSeconds パラメータを使用すると、リソースの可用性と費用対効果のバランスを取ることができます。このパラメータは、ノードが 7 日間の期間の終了に達する前に、新しいノードのプロビジョニング プロセスがそのノードの置き換えを開始するまでの時間（秒単位）を指定します。リードタイムを長くすると、古いノードが削除される前に新しいノードが準備される可能性が高くなりますが、追加費用が発生する可能性があります。

ノードのリサイクル プロセスは次の手順で構成されます。

1. リサイクル フェーズ: GKE は、Flex Start でプロビジョニングされたノードに leadTimeSeconds パラメータが設定された nodeRecycling フィールドがあることを確認します。有効な場合、GKE は現在の日付が次のフィールドの値の差以上になると、ノードのリサイクル フェーズを開始します。

   • creationTimestamp ＋ maxRunDurationSeconds
   • leadTimeSeconds

   creationTimeStamp フラグには、ノードの作成時間が含まれます。maxRunDurationSeconds フィールドはカスタム コンピューティング クラスで指定できます。デフォルトは 7 日です。

2. ノードの作成: 新しいノードの作成プロセスが開始され、キューイングとプロビジョニングのフェーズに進みます。キューイング フェーズの時間は、ゾーンと特定のアクセラレータ容量に応じて動的に変化する可能性があります。

3. 7 日間の期間が終了するノードを隔離する: 新しいノードが実行された後、古いノードは隔離されます。このアクションにより、新しい Pod がそのノードでスケジュールされなくなります。そのノードの既存の Pod は引き続き実行されます。

4. ノードのプロビジョニング解除: 7 日間の期間が終了したノードは、適切な期間後にプロビジョニング解除されます。これにより、実行中のワークロードが新しいノードに確実に移行されます。

コンピューティング クラス構成の次の例には、leadTimeSeconds フィールドと maxRunDuration フィールドが含まれています。

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: dws-model-inference-class
spec:
  priorities:
    - machineType: g2-standard-24
      spot: true
    - machineType: g2-standard-24
      maxRunDurationSeconds: 72000
      flexStart:
        enabled: true
        nodeRecycling:
          leadTimeSeconds: 3600
  nodePoolAutoCreation:
    enabled: true

ノードのリサイクルの使用方法については、費用を最適化し、高可用性の GPU プロビジョニング戦略を使用して GKE で LLM をサービングするのチュートリアルをご覧ください。

制限事項

• Pod 間のアンチアフィニティはサポートされていません。クラスタ オートスケーラーではノードのプロビジョニング中に Pod 間のアンチアフィニティ ルールが考慮されないため、スケジュール不可能なワークロードが発生する可能性があります。この状況は、複数の Dynamic Workload Scheduler オブジェクト用のノードが同じノードプールでプロビジョニングされた場合に発生することがあります。
• GPU ノードのみがサポートされています。
• Dynamic Workload Scheduler では予約はサポートされていません。ノードプールの作成時に --reservation-affinity=none フラグを指定する必要があります。Dynamic Workload Scheduler では、クラスタの自動スケーリングに必要な ANY ロケーション ポリシーのみがサポートされます。
• 1 つの Dynamic Workload Scheduler リクエストで最大 1,000 個の仮想マシン（VM）を作成できます。これは、1 つのノードプールのゾーンあたりの最大ノード数です。
• GKE では、Compute Engine の ACTIVE_RESIZE_REQUESTS 割り当てにより、キューで保留される Dynamic Workload Scheduler リクエストの数が制御されます。デフォルトでは、この割り当てはプロジェクトごとに 100 リクエストに制限されています。 Google Cloudこの割り当てを超える Dynamic Workload Scheduler リクエストを作成しようとすると、新しいリクエストは失敗します。
• Dynamic Workload Scheduler を使用するノードプールは、ノードがまとめてプロビジョニングされるため、停止の影響を受けやすくなります。詳細については、Dynamic Workload Scheduler を使用するワークロードの中断を管理するをご覧ください。
• Google Cloud コンソールに、有効期間の短い追加の VM が表示される場合があります。これは、必要なすべてのマシンをプロビジョニングする容量が使用可能になるまで、Compute Engine によって VM が作成され、すぐに削除される可能性があるためです。
• Spot VM はサポートされていません。
• Dynamic Workload Scheduler はエフェメラル ボリュームをサポートしていません。ストレージには永続ボリュームを使用する必要があります。永続ボリュームを使用する最適なストレージ タイプを選択するには、GKE クラスタのストレージの概要をご覧ください。
• ワークロードがノードリサイクルを使用し、Job によってデプロイされる場合は、完了モードを Indexed に設定して Job を構成します。

次のステップ

• GPU のタイプを選択する
• Dynamic Workload Scheduler を使用して GPU をデプロイする。