このページの改善にご協力ください
このユーザーガイドに貢献するには、すべてのページの右側のペインにある「GitHub でこのページを編集する」リンクを選択してください。
EKS Auto Mode と Karpenter を使用して AI/ML ワークロードのコンピューティングを管理する
ヒント
今後開催予定の Amazon EKS AI/ML ワークショップに登録
このセクションでは、Amazon EKS Auto Mode またはセルフマネージド Karpenter を使用して、AI トレーニングおよび推論ワークロードの高速コンピューティング (AWS Trainium、NVIDIA GPUs) を管理する方法について説明します。
EKS Auto Mode と Karpenter は、動的プロビジョニングと静的プロビジョニングの 2 つのプロビジョニングモードをサポートしています。動的プロビジョニングでは、EKS Auto Mode と Karpenter は、ワークロードがクラスター上でスケジュールされたときに、高速コンピューティングインスタンスをプロビジョニングしてスケーリングします。静的プロビジョニングでは、EKS Auto Mode と Karpenter は固定数のノードをプロビジョニングして維持します。動的プロビジョニングと静的プロビジョニングを同じクラスターで使用して、ワークロードの需要に応じてスケーリングしながら、一定のベースラインキャパシティプールを維持できます。
EKS Auto Mode と Karpenter は、4 つのキャパシティ購入オプション (オンデマンド、スポット、キャパシティブロック、ODCR) をすべてサポートし、常にリザーブドキャパシティを最初にプロビジョニングし、続いて Spot または On-Demand をプロビジョニングします。
EKS Auto Mode と Karpenter の比較
どちらのアプローチも NodePool API を共有しますが、運用所有権、リソース API、オペレーティングシステムのサポート、Spot 中断処理、設定の柔軟性が異なります。
| 機能 | EKS 自動モード | セルフマネージド Karpenter |
|---|---|---|
|
適しているチーム |
運用上のオーバーヘッドを最小限に抑えたマネージドインフラストラクチャを好むチーム |
ノードのライフサイクル、AMI、OS チューニング、パッチ適用を完全に制御したいチーム。 |
|
運用モデル |
AWS は、Karpenter コントローラー、GPU/Trainium ドライバー、デバイスプラグイン、OS パッチ適用、Spot 中断処理をプロビジョニングおよび管理します。 |
Karpenter コントローラーをクラスターにインストールして運用し、独自の GPU/Trainium ドライバー、デバイスプラグイン、AMI ライフサイクル、パッチ適用、Spot 中断処理を行います。 |
|
コンピューティングオプション |
On-Demand、Spot、ODCR、機械学習用のキャパシティブロック |
On-Demand、Spot、ODCR、機械学習用のキャパシティブロック |
|
リソース API |
|
|
|
ノードオペレーティングシステム |
Bottlerocket のみ。NVIDIA GPU、AWS Trainium、EFA の依存関係が含まれています。 |
AL2023、Bottlerocket、Windows、または独自の AMI。 |
|
ノード存続期間 |
セキュリティパッチ適用の最大ノード存続期間は 21 日です。ワークロードはノードのローテーションを許容する必要があります。 |
NodePool |
|
Spot 中断処理 |
ネイティブ。SQS キューまたはノード終了ハンドラーは必要ありません。 |
設定および有効化はユーザーの責任です。 |
|
高速コンテナプル |
すべての G、P、および Trn ファミリーインスタンスに含まれる SOCI 並列プル |
設定および有効化はユーザーの責任です。 |
|
EC2 プレイスメントグループ |
クラスター、パーティション、スプレッド |
クラスター、パーティション、スプレッド |
|
ネットワークインターフェイスの設定 |
タイプ |
タイプ |
|
ノードの修復 |
デフォルトで有効、EKS ノードモニタリングエージェントが含まれています |
オプションで有効、EKS ノードモニタリングエージェントセルフマネージド |
|
料金 |
基盤となる EC2 インスタンスコストに加えて EKS Auto Mode 管理料金 |
オープンソース。基盤となる EC2 インスタンスに対して料金が発生します。 |
一般的な AI/ML のよく知られているラベル
EKS Auto Mode と Karpenter は、インスタンスタイプをハードコーディングせずにワークロードをターゲットにするために NodePool requirements と Pod nodeSelector または nodeAffinity で使用できるインスタンスラベルを公開します。ラベルプレフィックスは 2 つで異なります。EKS Auto Mode は eks.amazonaws.com/ を使用し、セルフマネージド Karpenter は karpenter.k8s.aws/ を使用します。
以下の表は、NodePools で使用できる関連ラベルを示しています。EKS Auto Mode と Karpenter は、ワークロードのターゲティングにさらに使用できるプロビジョニングプロセスの一環として、Karpenter ドキュメント
リザーブドキャパシティのスケジューリングラベル
EKS Auto Mode または Karpenter が予約にノードを起動すると、次のラベルが追加されます。ワークロードをルーティングするには、nodeSelector、ノードアフィニティ、または NodePool の要件でこれらを使用します。
-
karpenter.sh/capacity-type:reserved、on-demandまたはspot。ノードをバックアップするキャパシティを示します。 -
karpenter.k8s.aws/capacity-reservation-id: ノードが起動された特定の予約 ID。 -
karpenter.k8s.aws/capacity-reservation-type: ODCR ではdefault、キャパシティブロックではcapacity-block。
次の例は、一般的なスケジューリングパターンを示しています。
Pod を 1 つの特定の予約にピン留めする (フォールバックなし):
spec: nodeSelector: karpenter.sh/capacity-type: reserved karpenter.k8s.aws/capacity-reservation-id: "cr-0123456789abcdef0"
ターゲット ODCR ノードのみ (キャパシティブロックではなく任意の ODCR):
spec: nodeSelector: karpenter.sh/capacity-type: reserved karpenter.k8s.aws/capacity-reservation-type: default
リザーブドキャパシティ (ODCR またはキャパシティブロック) をターゲットにします。
spec: nodeSelector: karpenter.sh/capacity-type: reserved
リザーブドを優先しますが、利用できない場合は Spot または On-Demand にフォールバックします。
spec: affinity: nodeAffinity: preferredDuringSchedulingIgnoredDuringExecution: - weight: 100 preference: matchExpressions: - key: karpenter.sh/capacity-type operator: In values: ["reserved"]
予約の有効期限の動作
予約が終了したときに、ODCR とキャパシティブロックの動作が異なります。スケジューリングとチェックポイント戦略が、ワークロードをサポートする予約のタイプと一致していることを確認します。
ODCR
ODCR に起動されたインスタンスは、その ODCR に無期限に存在するわけではありません。ODCR は期限切れになるか、キャンセルされる可能性があるか、またはインスタンスを ODCR から手動で削除される可能性があります。これらのいずれかが発生し、インスタンスが ODCR に属していないことを EKS Auto Mode/Karpenter が検出した場合、ノードの karpenter.sh/capacity-type ラベルが reserved から on-demand に更新されます。インスタンスは標準の On-Demand キャパシティとして実行され続け、既存の Pod は中断なく実行され続けます。
注記
厳密な nodeSelector: karpenter.sh/capacity-type: reserved でスケジュールされた Pod は、再度ラベルが付けられている場合、ノードにスケジュールされません。ワークロードが ODCR の有効期限またはキャンセル後も存続するには、nodeSelector の代わりに上記の preferredDuringSchedulingIgnoredDuringExecution パターンを使用します。
キャパシティブロック
ODCR とは異なり、キャパシティブロックには常に終了時間があり、EC2 は終了時間の 30 分前 (UltraServer インスタンスタイプの場合は 60 分前) にキャパシティブロックインスタンスを終了します。予約ウィンドウが閉じる前に、トレーニングジョブと推論ジョブが完了するか状態を保存するように計画してください。特定の capacity-reservation-id に対して厳密な nodeSelector を使用する Pod は、ブロックの有効期限が切れると Pending になり、他の場所では再スケジュールされません。キャパシティブロックの有効期間中にワークロードを他のキャパシティに移動する必要がある場合は、チェックポイントの作成と上記の柔軟なアフィニティパターンを組み合わせてください。
-
ほとんどのインスタンスタイプでは、キャパシティブロックの終了時間の 30 分前まで、UltraServer インスタンスタイプでは終了時間の 60 分前まで、予約済みインスタンスを使用できます。
-
EKS Auto Mode と Karpenter は、EC2 が終了を開始する 10 分前にキャパシティブロック内のノードのドレインを事前に開始するため、ワークロードにはチェックポイントの作成とグレースフルシャットダウンの時間があります。
静的キャパシティ NodePool
EKS Auto Mode と Karpenter は、静的キャパシティ NodePool をサポートしており、これはワークロードの需要に関係なく決まった数のノードを維持します。静的プールは、レイテンシーの影響を受けやすい推論のコールドスタート遅延を排除し、クラスターの最小限のインフラストラクチャフットプリントを確保できます。
静的キャパシティは、NodePool 上に replicas フィールドを設定することで構成されます。
考慮事項
-
NodePool 上に
replicasが設定されると、それを削除することはできません。単一の NodePool で静的キャパシティのプロビジョニングと動的キャパシティのプロビジョニングを切り替えることはできません。 -
静的キャパシティ NodePool は、統合の対象と見なされません。
limits.nodesをreplicasより大きく設定して、AMI のドリフトまたは有効期間中に一時的なスケーリングを許可します。 -
予測可能なアベイラビリティーゾーン (AZ) ディストリビューションでは、単一のプールで複数のゾーンにまたがるのではなく、AZ ごとに 1 つの静的キャパシティ NodePool を作成します。
機械学習用のキャパシティブロック
機械学習用のキャパシティブロックを使用すると、定義された今後のウィンドウ用に P ファミリーインスタンスと Trainium インスタンスを予約できます。これらは前払いであるため、EKS Auto Mode と Karpenter はそれらを無料としてモデル化し、On-Demand と Spot よりも優先します。機械学習用のキャパシティブロックには、1~14 日、または最大 182 日 (6 か月) の 7 日間の倍数のキャパシティブロックの予約期間があります。
EKS Auto Mode または Karpenter で機械学習用のキャパシティブロックを使用するには、NodeClass のキャパシティ予約 ID を使用して capacityReservationSelectorTerms を設定します。機械学習用のキャパシティブロックでオープン予約一致を使用することはできません。条件では、選択する ID、タグのセット、またはインスタンス一致条件を指定できます。タグを指定すると、一致するタグを持つアカウントからアクセス可能なすべてのキャパシティ予約が選択されます。これは、所有者アカウント ID を指定することでさらに制限できます。
詳細な例については、Karpenter のドキュメント
On-Demand キャパシティ予約 (ODCR)
ODCR は、長期的なコミットメントなしに、特定のアベイラビリティーゾーン (AZ) のキャパシティを保証します。キャパシティが使用されているかどうかにかかわらず、標準 On-Demand 料金で請求されます。ODCR は、機械学習用のキャパシティブロックでサポートされていない G ファミリーインスタンスを含む、すべての NVIDIA GPU ファミリーをサポートします。ODCR は前払いであるため、EKS Auto Mode と Karpenter はそれらを無料としてモデル化し、On-Demand と Spot よりも優先します。
ODCR は予約の終了時に機械学習用のキャパシティブロックとは異なる動作をします。ODCR の有効期限が切れるかキャンセルされると、インスタンスは標準 On-Demand として実行され続けます。詳細については、「予約の有効期限の動作」を参照してください。
EKS Auto Mode または Karpenter で ODCR を使用するには、NodeClass のキャパシティ予約条件を使用して capacityReservationSelectorTerms を設定します。条件では、選択する ID、タグのセット、またはインスタンス一致条件を指定できます。タグを指定すると、一致するタグを持つアカウントからアクセス可能なすべてのキャパシティ予約が選択されます。インスタンス一致条件を指定すると、一致する動作で予約が選択されます: open (互換性のあるすべてのインスタンスに一致) または targeted (明示的にターゲットされたインスタンスにのみ一致)。これは、所有者アカウント ID を指定することでさらに制限できます。
詳細な例については、Karpenter のドキュメント
On-Demand
On-Demand はデフォルトのキャパシティタイプであり、EKS Auto Mode および Karpenter の静的または動的なプロビジョニングで使用できます。NodePool で karpenter.sh/capacity-type: on-demand を設定することで、オンデマンドインスタンスを明示的にリクエストできます。EKS Auto Mode と Karpenter は、Pod のリソースリクエストを満たす最低価格のインスタンスを選択します。開発、プロトタイプ作成、予測不可能な推論スケーリング、および中断リスクなしで即時の可用性を必要とするワークロードには、On-Demand を使用します。
Spot
Spot は、予備の EC2 キャパシティを使用することで、On-Demand と比較して最大 90% のコスト削減を実現します。AWS は、2 分間の中断通知でスポットインスタンスを再利用できます。NodePool 上で複数のインスタンスファミリーを一覧表示して可用性を最大化します。Spot ワークロードを PodDisruptionBudget とペアリングし、耐久性のあるストレージ (Amazon S3 または Amazon EFS) に定期的にチェックポイントを保存して、Pod がドレインウィンドウ中に状態を保存できるようにします。
Spot スポットは、耐障害性があり、再開可能なトレーニングや推論のワークロードに適しています。ここでは、大幅なコスト削減と引き換えに、一時的な中断が許容されます。
一般的な候補には、以下が含まれます。
-
ハイパーパラメータのチューニングとスイープ: 中断した場合に再試行できる多くの短い並列トライアル。
-
チェックポイントを使用した分散トレーニング: 状態を S3 または FSx に定期的に保存し、ノードの損失後に最後のチェックポイントから再開できる長時間実行されるジョブ。
-
バッチ推論とオフライン推論: エンドツーエンドのレイテンシーが秒単位ではなく時間単位で測定されるデータセットに対する大規模なスコアリングジョブ。
-
データ前処理と特徴量エンジニアリングパイプライン: 大規模なデータセットでの並列変換。
-
モデル評価とベンチマーク: べき等の結果を生成する反復可能なジョブ。
-
開発、プロトタイプ、ノートブック: ユーザーがときどき再起動を許容できるインタラクティブな実験。
レイテンシーの影響を受けやすいリアルタイム推論、SLA バインドされた本番稼働用エンドポイント、チェックポイントがない、または再起動を許容できないワークロードには Spot の使用を避けてください。
NodePool で karpenter.sh/capacity-type: spot を設定することで、スポットインスタンスを明示的にリクエストできます。