**このページの改善にご協力ください**
このユーザーガイドに貢献するには、すべてのページの右側のペインにある「**GitHub でこのページを編集する**」リンクを選択してください。
# ノードグループを使用して Amazon EKS 上で AI/ML ワークロードのコンピューティングリソースを管理する
**ヒント**
今後開催予定の Amazon EKS AI/ML ワークショップに[登録](https://events.eksworkshop.com/workshops/genai/)してください。
このセクションでは、Amazon EKS マネージドノードグループまたはセルフマネージドノードを使用して、AI トレーニングおよび推論ワークロードの高速コンピューティング (AWS Trainium、NVIDIA GPUs) を管理する方法について説明します。
EKS マネージドノードグループとセルフマネージドノードは EC2 Auto Scaling Groups (ASG) を使用します。EKS マネージドノードグループには、ノードを作成、更新、削除するための専用の EKS API があり、ノード修復機能とライフサイクル終了フックも組み込まれています。EKS セルフマネージドノードは EC2 API を通じて直接デプロイおよび管理されます。
これらのオプションでは、インスタンスタイプ、必要数、スケーリング境界、および EC2 起動テンプレートを事前に定義します。EKS 以外のワークロードがあり、EC2 起動テンプレートを介した設定の一貫性を希望する場合は、EKS マネージドノードグループまたはセルフマネージドノードの使用を検討してください。EKS ノードグループは、高速コンピューティングフットプリントが事前にわかっているトレーニングやファインチューニングワークロードに適しています。EKS Auto Mode と Karpenter はどちらも静的キャパシティのプロビジョニングをサポートしていることに注意してください。詳細については、[EKS Auto Mode と Karpenter を使用して AI/ML ワークロードのコンピューティングを管理する](ml-node-pools.md) を参照してください。
EKS マネージドノードグループとセルフマネージドノードは、すべての高速コンピューティング購入オプション (オンデマンド、スポット、オンデマンドキャパシティ予約、ML のキャパシティブロック) をサポートします。キャパシティタイプごとに、それぞれに独自の起動テンプレート、インスタンスタイプ、スケーリング設定がある、個別のマネージドまたはセルフマネージドノードグループを作成します。これにより、異種動的プロビジョニングロジックを使用せずに、各キャパシティプールの明示的で ASG でバックアップされた制御を提供できます。
## EKS マネージドノードグループとセルフマネージドノードの比較
EKS マネージドノードグループとセルフマネージドノードのどちらを選択するかは、必要なカスタマイズと制御のレベルによって異なります。EKS マネージドノードグループは EC2 起動テンプレートのカスタマイズのサブセットを許可しますが、セルフマネージドノードは EC2 起動テンプレートの全範囲をサポートします。ノードライフサイクルを自分でカスタマイズおよび管理する理由が特にない場合は、EKS マネージドノードグループから始めて、特定の要件によって必要になった場合にのみセルフマネージドノードに移行してください。
**次の場合、マネージドノードグループを使用します:** EKS がユーザーに代わって AMI 選択、ノードブートストラップ、ローリング更新、ノード修復、および正常なドレインワークフローを処理することを希望している。トレーニングおよび推論ワークロードに EKS Auto Mode または Karpenter を使用することを希望しない場合は、EKS マネージドノードグループが推奨の開始点です。ML にキャパシティブロックを使用する場合、EKS マネージドノードグループは、予約が終了する 40 分前にノードグループをドレインするスケジュールされたスケーリングポリシーを自動的に作成し、[AWS ノード終了ハンドラー](https://github.com/aws/aws-node-termination-handler)または独自のスケールダウンオートメーションを使用する必要がなくなります。サポートされている EKS 最適化 AMI を使用している場合、カーネルレベルまたは詳細な EC2 起動テンプレートのカスタマイズが不要な場合、および Kubernetes バージョンのノードアップグレードパスをよりシンプルにしたい場合は、EKS マネージドノードグループを使用してください。
**次の場合、セルフマネージドノードグループを使用します:** EC2 起動テンプレート、AMI、カーネルパラメータ、コンテナランタイム設定、またはカスタムブートストラップスクリプトを完全に制御する必要がある。一般的な ML シナリオには、Elastic Fabric Adapter (EFA) による分散トレーニングのカーネルと NIC 設定のチューニングや、カスタムノードライフサイクルコントローラーとの統合などがあります。セルフマネージドノードを使用すると、必要なユーザーデータと IAM インスタンスプロファイルを柔軟に提供できますが、ユーザーは、更新、スケジュールされたスケーリングポリシー、[AWS ノード終了ハンドラー](https://github.com/aws/aws-node-termination-handler)などのライフサイクルフックに対して責任を負います。
## 機械学習用のキャパシティブロックを使用して GPU を予約する
機械学習 (ML) 用のキャパシティブロックを使用すると、将来の日付で GPU インスタンスを時間制限付きトレーニングまたは推論ワークロード用に予約できます。詳細については、「Amazon EC2 ユーザーガイド」の「[機械学習用のキャパシティブロック](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-capacity-blocks.html)」を参照してください。
EKS マネージドノードグループとセルフマネージドノードを介してキャパシティブロック予約を使用できます。EC2 起動テンプレートの設定は、どちらの場合も同じです。ノード作成ワークフロー、スケールダウン動作、およびワークロード終了のライフサイクルフックは、プロビジョニングオプションによって異なります。
## 考慮事項
+ キャパシティブロックは、特定の Amazon EC2 インスタンスタイプおよび AWS リージョンでのみ使用できます。詳細については、「[キャパシティブロックの操作の前提条件](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/capacity-blocks-using.html#capacity-blocks-prerequisites)」を参照してください。
+ キャパシティブロックはゾーン単位です。ノードグループの作成時に、キャパシティブロックの予約と同じアベイラビリティーゾーン (AZ) のサブネットを使用する必要があります。
+ キャパシティブロックの予約がアクティブになる前にノードグループを作成する場合は、ノードグループの作成時に希望するキャパシティを `0` に設定します。
+ 正常なワークロードドレイニングに時間をかけるには、キャパシティブロックの予約が終了する 30 分以上前にゼロへのスケーリングをスケジュールします。EC2 は、予約終了時間の 30 分前にインスタンスのシャットダウンを開始します。
## 機械学習用のキャパシティブロックを使用してノードグループを作成する
EKS マネージドノードグループとセルフマネージドノードでは、キャパシティブロックの予約をターゲットとするカスタム EC2 起動テンプレートを使用する必要があります。以下は、EKS マネージドノードグループとセルフマネージドノードの最小必須フィールドを示しています。以下のセルフマネージドノードのステップに示すように、セルフマネージドノードには追加のフィールドが必要です。
`LaunchTemplateData` には以下が含まれている必要があります:
+ `MarketType` が `"capacity-block"` に設定された `InstanceMarketOptions`
+ `CapacityReservationId` がキャパシティブロック ID に設定された `CapacityReservationSpecification: CapacityReservationTarget`。例えば、{{cr-0123456789abcdef0}}。
+ キャパシティブロックの予約のインスタンスタイプに設定された `InstanceType`。例えば、{{p5.48xlarge}}。
これらの要件は、EKS マネージドノードグループとセルフマネージドノードの起動テンプレートを作成するための以下の例に示されています。
------
#### [ Managed node groups ]
1. 次の内容で、`eks-capacity-block-lt.json` という名前のファイルを作成します。
`CapacityReservationId` と `InstanceType` の内容をキャパシティブロックの値に置き換えます。追加の EC2 起動テンプレートフィールドの詳細については、「[起動テンプレートを使用してマネージドノードをカスタマイズする](launch-templates.md)」および「[機械学習用のキャパシティブロックワークロードを使用する](https://docs.aws.amazon.com/autoscaling/ec2/userguide/launch-template-capacity-blocks.html)」を参照してください。
```
{
"LaunchTemplateData": {
"InstanceMarketOptions": {
"MarketType": "capacity-block"
},
"CapacityReservationSpecification": {
"CapacityReservationTarget": {
"CapacityReservationId": {{"cr-0123456789abcdef0"}}
}
},
"InstanceType": {{"p5.48xlarge"}}
}
}
```
1. 起動テンプレートを作成します。
```
aws ec2 create-launch-template \
--launch-template-name EKS-Capacity-Block-Launch-Template \
--launch-template-data file://eks-capacity-block-lt.json
```
1. 起動テンプレートを使用して、EKS マネージドノードグループを作成します。以下のコマンドのプレースホルダーを、環境に適した値に置き換えます。以下のコマンドは、`--ami-type` を AL2023 EKS 最適化 NVIDIA AMI に設定します。使用可能な EKS 最適化 AMI の詳細については、「[GPU インスタンス向けに EKS 最適化高速 AMI を使用する](ml-eks-optimized-ami.md)」を参照してください。EKS マネージドノードグループでカスタム AMI を使用するには、起動テンプレートで AMI ID を指定します。
キャパシティブロックを使用する EKS マネージドノードグループを作成するときは、以下の操作を行います。
+ `--capacity-type` を `"CAPACITY_BLOCK"` に設定します。
+ キャパシティ予約と同じアベイラビリティーゾーンにあるサブネットのみを指定します。
+ 予約がアクティブになる前にゼロ以外の `desiredSize` を指定した場合、Auto Scaling グループは予約がアクティブになるまで起動エラーをレポートします。アクティブになると、インスタンスが起動し、ASG はリクエストされた `desiredSize` までスケールアップします。
```
aws eks create-nodegroup \
--cluster-name {{my-eks-cluster}} \
--nodegroup-name {{eks-cb-nodes}} \
--node-role {{"arn:aws:iam::111122223333:role/myNodeRole"}} \
--region {{region-code}} \
--subnets {{subnet-ExampleID1}} \
--ami-type {{"AL2023_x86_64_NVIDIA"}} \
--scaling-config minSize=0,maxSize=2,desiredSize=0 \
--capacity-type "CAPACITY_BLOCK" \
--launch-template name="EKS-Capacity-Block-Launch-Template"
```
1. 作成時に `desiredSize` を `0` に設定すると、予約がアクティブになって以下のいずれかを使用できるようになったたときに、ノードグループをスケールアップします。
+ 予約開始時間に合わせて ASG でスケジュールされたスケーリングポリシー。詳細については、「*Amazon EC2 Auto Scaling ユーザーガイド*」の「[Amazon EC2 Auto Scaling のスケジュールされたスケーリング](https://docs.aws.amazon.com/autoscaling/ec2/userguide/ec2-auto-scaling-scheduled-scaling.html)」を参照してください。
+ スケーリング設定を更新するための Amazon EKS コンソールまたは `aws eks update-nodegroup-config`。
1. スケールアップ後にノードがクラスターを結合することを確認します。
1. EKS は、**Amazon EKS Node Group Capacity Scaledown Before Reservation End** という名前のスケジュールされたスケーリングポリシーを自動的に作成し、予約が終了する 40 分前にノードグループを `0` にスケールダウンします。これにより、EC2 が 30 分のマークでインスタンスの終了を開始する前に、Pod を適切にドレインする時間を確保できます。このスケジュールされたアクションを編集または削除しないでください。
------
#### [ Self-managed nodes ]
1. 次の内容で、`eks-capacity-block-lt.json` という名前のファイルを作成します。
`CapacityReservationId` と `InstanceType` の内容をキャパシティブロックの値に置き換えます。追加の EC2 起動テンプレートフィールドの詳細については、「[起動テンプレートを使用してマネージドノードをカスタマイズする](launch-templates.md)」および「[機械学習用のキャパシティブロックワークロードを使用する](https://docs.aws.amazon.com/autoscaling/ec2/userguide/launch-template-capacity-blocks.html)」を参照してください。
`IamInstanceProfile`、`ImageId`、`SecurityGroupIds`、`UserData`、`KeyName` の内容を、お使いの環境の値で置き換えます。
```
{
"LaunchTemplateData": {
"InstanceMarketOptions": {
"MarketType": "capacity-block"
},
"CapacityReservationSpecification": {
"CapacityReservationTarget": {
"CapacityReservationId": {{"cr-0123456789abcdef0"}}
}
},
"IamInstanceProfile": {
"Arn": {{"arn:aws:iam::111122223333:role/myNodeRole"}}
},
"ImageId": {{"image-id"}},
"InstanceType": {{"p5.48xlarge"}},
"KeyName": {{"key-name"}},
"SecurityGroupIds": "sg-05b1d815d1EXAMPLE"
],
"UserData": {{"user-data"}}
}
}
```
1. 起動テンプレートを作成します。
```
aws ec2 create-launch-template \
--launch-template-name EKS-Capacity-Block-Launch-Template \
--launch-template-data file://eks-capacity-block-lt.json
```
1. 起動テンプレートを使用して、[セルフマネージド Amazon Linux ノードを作成する](launch-workers.md) の手順に従って Auto Scaling グループを作成します。予約がまだアクティブでない場合は、`DesiredCapacity` を `0` に設定します。キャパシティが予約されているアベイラビリティーゾーンのサブネットのみを指定します。
1. `DesiredCapacity` を `0` に設定してセルフマネージドノードを作成したら、キャパシティブロックの予約時間に合わせて Auto Scaling グループにスケジュールされたスケーリングポリシーを作成します。詳細については、「[Amazon EC2 Auto Scaling のスケジュールされたスケーリング](https://docs.aws.amazon.com/autoscaling/ec2/userguide/ec2-auto-scaling-scheduled-scaling.html)」を参照してください。
予約したインスタンスは、予約終了時刻の 30 分前まで使用できます。Pod がドレインする時間を確保できるように、終了時刻の 30 分以上前にゼロへのスケーリングをスケジュールします。
手動でスケールする場合は、予約の開始時刻に ASG の希望するキャパシティを更新し、終了時刻の 30 分以上前に再度更新します。
1. Pod を適切にドレインするには、AWS ノード終了ハンドラーをセットアップします。このハンドラーは、EventBridge を使用して Amazon EC2 Auto Scaling からの ASG スケールインライフサイクルイベントを監視し、インスタンスが使用できなくなる前に Kubernetes コントロールプレーンが必要なアクションを実行できるようにします。そうしないと、Pod と Kubernetes のオブジェクトが保留状態でスタックする可能性があります。詳細については、GitHub の「[AWS ノード終了ハンドラー](https://github.com/aws/aws-node-termination-handler)」を参照してください。
ノード終了ハンドラーをセットアップしない場合は、正常にドレインさせる時間を十分に確保できるように、30 分のウィンドウに入る前に Pod のドレインを手動で行います。
------