翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# Amazon EKS での拡張クラスターオペレーションの継続的プロビジョニング
Amazon EKS オーケストレーションで作成された Amazon SageMaker HyperPod クラスターは、大規模な AI/ML ワークロードを実行する柔軟性と効率を向上させる新機能である、継続的プロビジョニングをサポートするようになりました。継続的プロビジョニングにより、トレーニングを迅速に開始し、シームレスにスケールして、オペレーションを中断することなくメンテナンスを実行し、クラスターオペレーションをきめ細かく可視化できます。
**注記**
継続的プロビジョニングは、EKS オーケストレーションで作成された HyperPod クラスターのオプション設定として使用できます。Slurm オーケストレーションで作成されたクラスターは、別のスケーリングモデルを使用します。
## 仕組み
継続的プロビジョニングシステムは、従来のリクエストベースのモデルを置き換える望ましい状態のアーキテクチャを実現します。この新しいアーキテクチャにより、システムの安定性とパフォーマンスを維持しながら、さまざまなリソースレベルで並列ノンブロッキングオペレーションが可能になります。継続的プロビジョニングシステム:
+ **リクエストを受け入れる**: 各インスタンスグループのターゲットインスタンス数を記録します。
+ **プロビジョニングを開始する:** ターゲット数を満たすためにインスタンスの起動を開始します。
**進行状況を追跡する**: 各インスタンスの起動試行をモニタリングし、ステータスを記録します。
+ **失敗に対処する**: 失敗した起動を自動的に再試行します。
継続的プロビジョニングはデフォルトで無効になっています。この機能を使用するには、`--node-provisioning-mode` を `Continuous` に設定する必要があります。
継続的プロビジョニングを有効にすると、以前のオペレーションが完了するのを待つ必要なく、複数のスケーリングオペレーションを同時に開始できます。これにより、同じクラスター内の異なるインスタンスグループを同時にスケールし、同じインスタンスグループに複数のスケーリングリクエストを送信できます。
また、継続的プロビジョニングにより、[DescribeClusterEvent](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_DescribeClusterEvent.html) と [ListClusterEvent](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_ListClusterEvents.html) にアクセスして、詳細なイベントモニタリングと運用の可視性を実現できます。
## 使用状況の計測
継続的プロビジョニングを有効にした HyperPod クラスターは、インスタンスレベルの計測を使用して、実際のリソース使用量を反映する正確な請求情報を提供できます。この計測アプローチは、各インスタンスを個別に追跡する点で、従来のクラスターレベルの請求とは異なります。
**インスタンスレベルの請求**
継続的プロビジョニングでは、請求はクラスターレベルの状態の変化を待つのではなく、個々のインスタンスレベルで開始され、停止します。これには次の利点があります。
+ **正確な請求精度**: ライフサイクルスクリプトの実行が開始されると請求が開始されます。ライフサイクルスクリプトが失敗すると、インスタンスのプロビジョニングが再試行され、ライフサイクルスクリプトのランタイム中に課金されます。
+ **独立した計測**: 各インスタンスの請求ライフサイクルは個別に管理されるため、請求エラーのカスケードを防ぐことができます。
+ **リアルタイムの請求更新**: 請求は、インスタンスがライフサイクルスクリプトの実行を開始したときに開始され、インスタンスが終了状態になると停止します。
**請求ライフサイクル**
HyperPod クラスター内の各インスタンスは、この請求ライフサイクルに従います。
+ **請求開始**: インスタンスが正常に起動し、ライフサイクル設定スクリプトの実行を開始したタイミング
+ **請求が継続**: インスタンスの運用期間中
+ **請求停止**: 終了の理由を問わず、インスタンスが終了状態になったタイミング
**注記**
起動に失敗したインスタンスの請求は開始されません。キャパシティ不足やその他の問題が原因でインスタンスの起動に失敗した場合、その失敗した試行に対して課金されることはありません。請求はインスタンスレベルで計算され、コストはクラスターの Amazon リソースネーム (ARN) で集計されて報告されます。
## 継続的プロビジョニングを有効にしてクラスターを作成する
**注記**
VPC ネットワークで設定された既存の Amazon EKS クラスターと、必要な Helm チャートがインストールされている必要があります。さらに、ライフサイクル設定スクリプトを準備して、実行ロールがアクセスできる Amazon S3 バケットにアップロードします。詳細については、「[Amazon EKS によってオーケストレーションされた SageMaker HyperPod クラスターを管理する](sagemaker-hyperpod-eks-operate.md)」を参照してください。
次の AWS CLI オペレーションでは、1 つのインスタンスグループで継続的なプロビジョニングが有効になっている HyperPod クラスターを作成します。
```
aws sagemaker create-cluster \
--cluster-name $HP_CLUSTER_NAME \
--orchestrator 'Eks={ClusterArn='$EKS_CLUSTER_ARN'}' \
--vpc-config '{
"SecurityGroupIds": ["'$SECURITY_GROUP'"],
"Subnets": ["'$SUBNET'"]
}' \
--instance-groups '{
"InstanceGroupName": "ig-1",
"InstanceType": "ml.c5.2xlarge",
"InstanceCount": 2,
"LifeCycleConfig": {
"SourceS3Uri": "s3://'$BUCKET_NAME'",
"OnCreate": "on_create_noop.sh"
},
"ExecutionRole": "'$EXECUTION_ROLE'",
"ThreadsPerCore": 1,
"TrainingPlanArn": ""
}' \
--node-provisioning-mode Continuous
// Expected Output:
{
"ClusterArn": "arn:aws:sagemaker:us-west-2::cluster/"
}
```
クラスターを作成したら、[ListClusterNodes](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_ListClusterNodes.html) または [DescribeClusterNode](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_DescribeClusterNode.html) を使用して、クラスター内のノードに関する詳細情報を確認できます。
これらのオペレーションを呼び出すと、次のいずれかの値を持つ [ClusterInstanceStatusDetails](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_ClusterInstanceStatusDetails.html) オブジェクトが返されます。
+ **Running**: ノードは正常で、クラスターオーケストレーター (EKS) に登録されています。
+ **Failure**: ノードのプロビジョニングは失敗しましたが、システムは新しい EC2 インスタンスでプロビジョニングを自動的に再試行します。
+ **Pending**: ノードはプロビジョニング中または再起動中です。
+ **ShuttingDown**: ノードの終了が進行中です。終了で問題が発生した場合、ノードは失敗ステータスに移行するか、クラスターから正常に削除されます。
+ **SystemUpdating**: ノードは手動でトリガーされるか、cronjobs へのパッチ適用の一部として AMI パッチ適用中です。
+ **DeepHealthCheckInProgress**: [Deep Health Check (DHCs)](sagemaker-hyperpod-eks-resiliency-deep-health-checks.md) を実施中です。これは、テストの特性に応じて数分から数時間かかる場合があります。不適切なノードは置き換えられ、正常なノードは実行中に切り替わります。
+ **NotFound** : [BatchAddClusterNodes](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_BatchAddClusterNodes.html) レスポンスで使用され、べき等再生中にノードが削除されたことを示します。
## 最小容量要件 (MinCount)
MinCount 機能を使用すると、インスタンスグループが `InService`ステータスに移行する前に正常にプロビジョニングする必要があるインスタンスの最小数を指定できます。この機能は、スケーリングオペレーションをより適切に制御し、部分的にプロビジョニングされたインスタンスグループをトレーニングワークロードに効果的に使用できないシナリオを防ぐのに役立ちます。
**重要**
MinCount は、最小容量の永続的な保証ではありません。これにより、インスタンスグループが最初に になったときにのみ、指定された最小数のインスタンスが使用可能になります`InService`。MinCount を下回る短い低下は、異常なインスタンス交換やメンテナンスアクティビティなどの通常のオペレーション中に発生する可能性があります。
### MinCount の仕組み
MinCount を有効にしてインスタンスグループを作成または更新すると、次の動作が発生します。
+ **新しいインスタンスグループ**: インスタンスグループは、少なくとも MinCount インスタンスが正常にプロビジョニングされ、準備ができるまで`Creating`ステータスのままになります。このしきい値に達すると、インスタンスグループは に移行します`InService`。
+ **既存のインスタンスグループ**: 既存のインスタンスグループの MinCount を更新すると、新しい MinCount 要件が満たされ`Updating`るまでステータスが に変わります。
+ **継続的スケーリング**: TargetCount が MinCount より大きい場合、継続的スケーリングシステムは TargetCount に達するまで追加のインスタンスの起動を試行し続けます。
+ **タイムアウトとロールバック**: MinCount を 3 時間以内に満たすことができない場合、システムは自動的にインスタンスグループを最後の既知の正常な状態にロールバックします。ロールバック動作の詳細については、[「自動ロールバック動作](#sagemaker-hyperpod-scaling-eks-mincount-rollback)」を参照してください。
### MinCount オペレーション中のインスタンスグループのステータス
MinCount が設定されたインスタンスグループは、次のステータス動作を示します。
作成
CurrentCount < MinCount の新しいインスタンスグループの場合。インスタンスグループは、最小容量要件が満たされるまで、このステータスのままになります。
[更新中]
MinCount が変更され、CurrentCount < MinCount の既存のインスタンスグループの場合。インスタンスグループは、新しい最小容量要件が満たされるまで、このステータスのままになります。
InService
MinCount ≤ CurrentCount ≤ TargetCount の場合。インスタンスグループは使用でき、すべてのミューテーションオペレーションはブロック解除されます。
`Creating` または `Updating`ステータスの間は、次の制限が適用されます。
+ `BatchAddClusterNodes`、、 `BatchDeleteClusterNodes`などのミューテーションオペレーション`UpdateClusterSoftware`がブロックされている
+ MinCount 値と TargetCount 値を引き続き変更して、設定エラーを修正できます。
+ クラスターとインスタンスグループの削除は常に許可されます
### 自動ロールバック動作
インスタンスグループが 3 時間以内に MinCount に到達できない場合、システムは無期限の待機を防ぐために自動的にロールバックを開始します。
+ **新しいインスタンスグループ**: MinCount と TargetCount が (0, 0) にリセットされます
+ **既存のインスタンスグループ**: MinCount と TargetCount は、最後の`InService`状態からその値に復元されます。
+ **終了するインスタンスの選択**: ロールバック中にインスタンスを終了する必要がある場合、システムはまず異常なインスタンスを選択し、次に最後にプロビジョニングされたインスタンスを選択します。
+ **ステータスの移行**: インスタンスグループはロールバックの開始直後に`InService`ステータスに移行し、継続的なスケーリングシステムがロールバック設定に従って容量を管理できるようにします。
MinCount が更新されるたびに 3 時間のタイムアウトがリセットされます。例えば、MinCount を複数回更新すると、タイムアウト期間は最新の更新から新しく開始されます。
### MinCount イベント
システムは、MinCount オペレーションの追跡に役立つ特定のイベントを発行します。
+ **最小到達容量**: インスタンスグループが MinCount に正常に到達し、 に移行すると出力されます `InService`
+ **ロールバック開始**: 3 時間のタイムアウトが期限切れになり、自動ロールバックが開始されたときに発行されます
[ListClusterEvents](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_ListClusterEvents.html) を使用してこれらのイベントをモニタリングし、MinCount オペレーションの進行状況を追跡できます。
### API の使用
MinCount は、インスタンスグループ設定の `MinInstanceCount`パラメータを使用して指定します。
```
aws sagemaker create-cluster \
--cluster-name $HP_CLUSTER_NAME \
--orchestrator 'Eks={ClusterArn='$EKS_CLUSTER_ARN'}' \
--vpc-config '{
"SecurityGroupIds": ["'$SECURITY_GROUP'"],
"Subnets": ["'$SUBNET'"]
}' \
--instance-groups '{
"InstanceGroupName": "worker-group",
"InstanceType": "ml.p4d.24xlarge",
"InstanceCount": 64,
"MinInstanceCount": 50,
"LifeCycleConfig": {
"SourceS3Uri": "s3://'$BUCKET_NAME'",
"OnCreate": "on_create.sh"
},
"ExecutionRole": "'$EXECUTION_ROLE'"
}' \
--node-provisioning-mode Continuous
```
MinCount の使用に関する主な考慮事項:
+ `MinInstanceCount` [CreateCluster](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_CreateCluster.html) または [UpdateCluster](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_UpdateCluster.html) リクエストで指定されたインスタンスグループの 0 ～ `InstanceCount` (含む) の値である必要があります
+ `MinInstanceCount` を 0 (デフォルト) に設定すると、標準の継続的スケーリング動作が維持されます。
+ を `MinInstanceCount`に等しく設定`InstanceCount`すると、all-or-nothingスケーリング動作が提供されます。
+ MinCount は、 が `NodeProvisioningMode` に設定されているクラスターでのみ使用できます。 `Continuous`
## 柔軟なインスタンスグループ
柔軟なインスタンスグループを使用すると、1 つのインスタンスグループ内で複数のインスタンスタイプを指定できます。これにより、特に Auto Scaling を使用する推論ワークロードの場合に、作成および管理する必要があるインスタンスグループの数を減らすことで、クラスター管理が簡素化されます。
柔軟なインスタンスグループでは、HyperPod は次のようになります。
+ リストの最初のインスタンスタイプを使用してインスタンスをプロビジョニングしようとする
+ 容量が利用できない場合、後続のインスタンスタイプにフォールバックします
+ スケールダウン中に優先度が最も低いインスタンスタイプのインスタンスを最初に終了します
**注記**
柔軟なインスタンスグループは、 が `NodeProvisioningMode`に設定されているクラスターでのみ使用できます`Continuous`。プロパティ`InstanceType`と `InstanceRequirements`プロパティは相互に排他的です。どちらか一方を指定できますが、両方を指定することはできません。
### 柔軟なインスタンスグループを使用してクラスターを作成する
`InstanceRequirements` 代わりに `InstanceType`を使用して、柔軟なインスタンスグループを作成します。リスト内のインスタンスタイプの順序によって、プロビジョニングの優先度が決まります。
```
aws sagemaker create-cluster \
--cluster-name $HP_CLUSTER_NAME \
--orchestrator 'Eks={ClusterArn='$EKS_CLUSTER_ARN'}' \
--vpc-config '{
"SecurityGroupIds": ["'$SECURITY_GROUP'"],
"Subnets": ["'$SUBNET_AZ1'", "'$SUBNET_AZ2'"]
}' \
--instance-groups '[{
"InstanceGroupName": "flexible-ig",
"InstanceRequirements": {
"InstanceTypes": ["ml.p5.48xlarge", "ml.p4d.24xlarge", "ml.g6.48xlarge"]
},
"InstanceCount": 10,
"LifeCycleConfig": {
"SourceS3Uri": "s3://'$BUCKET_NAME'",
"OnCreate": "on_create.sh"
},
"ExecutionRole": "'$EXECUTION_ROLE'"
}]' \
--node-provisioning-mode Continuous
```
### BatchAddClusterNodes によるターゲットスケーリング
柔軟なインスタンスグループを使用する場合は、[BatchAddClusterNodes](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_BatchAddClusterNodes.html) を使用して、特定のインスタンスタイプとアベイラビリティーゾーンを持つノードを追加できます。これは、Karpenter 自動スケーリングがワークロードに最適なインスタンスタイプとアベイラビリティーゾーンを決定する場合に特に便利です。
```
aws sagemaker batch-add-cluster-nodes \
--cluster-name $HP_CLUSTER_NAME \
--nodes-to-add '[
{
"InstanceGroupName": "flexible-ig",
"IncrementTargetCountBy": 1,
"InstanceTypes": ["ml.p5.48xlarge"],
"AvailabilityZones": ["us-west-2a"]
}
]'
```
### 柔軟なインスタンスグループの詳細を表示する
[DescribeCluster](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_DescribeCluster.html) を使用して、柔軟なインスタンスグループのインスタンスタイプとタイプごとの内訳を表示します。レスポンスは以下のとおりです。
+ `InstanceRequirements` — インスタンスグループの現在のインスタンスタイプと必要なインスタンスタイプ
+ `InstanceTypeDetails` — グループ内の各per-instance-type内訳
### Karpenter 自動スケーリングでの柔軟なインスタンスグループの使用
柔軟なインスタンスグループは、HyperPod のマネージド Karpenter 自動スケーリングと統合されます。Karpenter のセットアップの詳細については、「」を参照してください[SageMaker HyperPod EKS での Auto Scaling](sagemaker-hyperpod-eks-autoscaling.md)。`HyperPodNodeClass` 設定で柔軟なインスタンスグループを参照すると、Karpenter は自動的に次の操作を行います。
+ サポートされているインスタンスタイプを柔軟なインスタンスグループから検出します
+ ポッドの要件と料金に基づいて、最適なインスタンスタイプとアベイラビリティーゾーンを選択します
+ 選択したインスタンスタイプとアベイラビリティーゾーンでターゲット`BatchAddClusterNodes`呼び出しを使用して、柔軟なインスタンスグループをスケーリングします
**注記**
Karpenter がスケーリングを管理する場合、ポッドの要件と料金に基づいて独自の選択ロジックを使用して、プロビジョニングするインスタンスタイプを決定します。これは、HyperPod のネイティブプロビジョニングで使用されるリスト順序の優先度 ( `CreateCluster`や など`UpdateCluster`) とは異なり、リストの最初のインスタンスタイプが常に最初に試行されます。
これにより、インスタンスタイプごとに個別のインスタンスグループを作成し、複数のグループを参照するように Karpenter を手動で設定する必要がなくなります。