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

このページでは、Google Kubernetes Engine（GKE）の Flex Start プロビジョニング モードについて説明します。Dynamic Workload Scheduler を活用した Flex Start は、AI / ML ワークロードの実行時に GPU と TPU を取得するための柔軟で費用対効果に優れた手法を提供します。

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

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

• GKE での Flex Start の仕組みについて理解する。
• Flex Start がワークロードに適しているかどうかを判断する。
• ワークロードに適した 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 は、ノードで Flex Start が有効になっており、ワークロードが無期限に待機できることを確認します。
3. クラスタ オートスケーラーがユーザーのリクエストを受け入れ、必要なノードの数を計算します（それらのノードは 1 つのユニットとして扱われます）。
4. クラスタ オートスケーラーは、必要なノードが利用可能になった時点でプロビジョニングします。これらのノードは、最大 7 日間実行されます。maxRunDurationSeconds パラメータに値を指定した場合は、それよりも短い期間で実行されます。このパラメータは、GKE バージョン 1.28.5-gke.1355000 以降で使用できます。maxRunDurationSeconds パラメータに値を指定しない場合、デフォルトは 7 日間です。
5. maxRunDurationSeconds パラメータで定義した実行時間が終了すると、ノードと Pod はプリエンプトされます。
6. Pod がそれより前に終了し、ノードが使用されなくなると、クラスタ オートスケーラーは自動スケーリング プロファイルに従ってノードと Pod を削除します。

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

Flex Start 構成

GKE は、次の Flex Start 構成をサポートしています。

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

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

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

次の表に、Flex Start 構成の比較を示します。

Flex Start 構成を最適化する

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

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

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

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

短時間のアップグレードでは、実行中のノードを中断することなく、Standard ノードプールまたは Autopilot クラスタのノードのグループを更新します。新しいノードは新しい構成で作成され、古い構成の既存のノードは徐々に置き換えられます。以前のバージョンの 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 リクエストがなく、ノードプールが空であるときに、ノードプールを手動でアップグレードします。

クラスタを短期間のアップグレードに移行する際の考慮事項

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

ノードプールで短期間のアップグレードを使用するようになったため、次のベスト プラクティスの実装を検討することをおすすめします。

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

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

ノードの移行をスムーズに行い、実行中のジョブのダウンタイムを防ぐため、Flex Startt ではノードのリサイクルをサポートしています。ノードの期間が終了すると、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 リクエストの数が制御されます。デフォルトでは、この割り当ては Trusted Cloudプロジェクトあたり 100 リクエストに制限されています。この割り当てを超える Dynamic Workload Scheduler リクエストを作成しようとすると、新しいリクエストは失敗します。
• Dynamic Workload Scheduler を使用するノードプールは、ノードがまとめてプロビジョニングされるため、停止の影響を受けやすくなります。詳細については、Dynamic Workload Scheduler を使用するワークロードの中断を管理するをご覧ください。
• Trusted Cloud コンソールに、有効期間の短い追加の VM が表示される場合があります。これは、必要なすべてのマシンをプロビジョニングする容量が使用可能になるまで、Compute Engine によって VM が作成され、すぐに削除される可能性があるためです。
• Spot VM はサポートされていません。
• Dynamic Workload Scheduler はエフェメラル ボリュームをサポートしていません。ストレージには永続ボリュームを使用する必要があります。永続ボリュームを使用する最適なストレージ タイプを選択するには、GKE クラスタのストレージの概要をご覧ください。
• ワークロードがノードの再利用を使用し、Job によってデプロイされる場合は、完了モードが Indexed に設定された Job を構成します。

次のステップ

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