翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
Amazon EKS での拡張クラスターオペレーションの継続的なプロビジョニング
Amazon EKS オーケストレーションで作成された Amazon SageMaker HyperPod クラスターは、大規模な AI/ML ワークロードを実行する柔軟性と効率を高める新機能である継続的なプロビジョニングをサポートするようになりました。継続的なプロビジョニングにより、トレーニングをすばやく開始し、シームレスにスケーリングし、オペレーションを中断することなくメンテナンスを実行し、クラスターオペレーションをきめ細かく可視化できます。
注記
継続的プロビジョニングは、EKS オーケストレーションで作成された HyperPod クラスターで使用できます。Slurm オーケストレーションで作成されたクラスターは、異なるスケーリングモデルを使用します。
仕組み
継続的プロビジョニングは、各インスタンスを個別に管理するイベント駆動型アーキテクチャを介して動作します。HyperPod クラスターを作成するときは、各インスタンスグループにインスタンスの必要数を指定します。継続的プロビジョニングシステム:
-
リクエストを受け入れます: 各インスタンスグループのターゲットインスタンス数を記録します
-
プロビジョニングを開始する: ターゲット数を満たすためにインスタンスの起動を開始します
進行状況を追跡: 各インスタンスの起動試行をモニタリングし、ステータスを記録します
-
失敗に対処する: 失敗した起動を自動的に再試行する
継続的プロビジョニングはデフォルトで無効になっています。この機能を使用するには、 --node-provisioning-mode
を に設定しますContinuous
。
継続的プロビジョニングを有効にすると、以前のオペレーションが完了するのを待たずに、複数のスケーリングオペレーションを同時に開始できます。これにより、同じクラスター内の異なるインスタンスグループを同時にスケーリングし、同じインスタンスグループに複数のスケーリングリクエストを送信できます。
また、継続的なプロビジョニングにより、DescribeClusterEvent と ListClusterEvent にアクセスして、詳細なイベントモニタリングと運用の可視性を実現できます。
使用状況の計測
継続的プロビジョニングを備えた HyperPod クラスターは、インスタンスレベルの計測を使用して、実際のリソース使用量を反映する正確な請求を提供します。この計測アプローチは、各インスタンスを個別に追跡することで、従来のクラスターレベルの請求とは異なります。
インスタンスレベルの請求
継続的なプロビジョニングでは、請求はクラスターレベルの状態の変化を待つのではなく、個々のインスタンスレベルで開始および停止します。このアプローチには以下の利点があります。
-
正確な請求精度: ライフサイクルスクリプトの実行が開始されると請求が開始されます。ライフサイクルスクリプトが失敗した場合、インスタンスのプロビジョニングは再試行され、ライフサイクルスクリプトランタイムの期間中は課金されます。
-
独立した計測: 各インスタンスの請求ライフサイクルは個別に管理されるため、請求エラーのカスケードを防ぐことができます。
-
リアルタイムの請求更新: 請求は、インスタンスがライフサイクルスクリプトの実行を開始したときに開始され、インスタンスが終了状態になると停止します。
請求ライフサイクル
HyperPod クラスター内の各インスタンスは、この請求ライフサイクルに従います。
-
請求開始: インスタンスが正常に起動し、ライフサイクル設定スクリプトの実行を開始する場合
-
請求継続: インスタンスの運用期間中
-
請求停止: 終了の理由に関係なく、インスタンスが終了状態になった場合
注記
起動に失敗したインスタンスの請求は開始されません。容量不足やその他の問題が原因でインスタンスの起動に失敗した場合、その失敗した試行に対して課金されません。請求はインスタンスレベルで計算され、コストはクラスターの Amazon リソースネーム (ARN) で集計されて報告されます。
継続的プロビジョニングを有効にしてクラスターを作成する
注記
VPC ネットワークで設定された既存の Amazon EKS クラスターと、必要な Helm チャートがインストールされている必要があります。さらに、ライフサイクル設定スクリプトを準備し、実行ロールがアクセスできる Amazon S3 バケットにアップロードします。
次の AWS CLI オペレーションでは、1 つのインスタンスグループで継続的なプロビジョニングが有効になっている HyperPod クラスターを作成します。
aws sagemaker-dev 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:<account-id>:cluster/<cluster-id>" }
クラスターを作成したら、ListClusterNodes または DescribeClusterNode を使用して、クラスター内のノードに関する詳細情報を確認できます。
これらのオペレーションを呼び出すと、次のいずれかの値を持つ ClusterInstanceStatusDetails オブジェクトが返されます。
-
実行中: ノードは正常で、クラスターオーケストレーター (EKS) に登録されています。
-
失敗: ノードのプロビジョニングは失敗しましたが、システムは新しい EC2 インスタンスでプロビジョニングを自動的に再試行します。
-
保留中: ノードはプロビジョニング中または再起動中です。
-
ShuttingDown: ノードの終了が進行中です。終了で問題が発生した場合、ノードは失敗ステータスに移行するか、クラスターから正常に削除されます。
-
SystemUpdating: ノードは、手動でトリガーされるか、cronjobs へのパッチ適用の一部として AMI パッチ適用中です。
-
DeepHealthCheckInProgress: Deep Health Check (DHCs) を実施中です。テストの性質によっては、数分から数時間かかる場合があります。不良ノードは置き換えられ、正常なノードは実行中に切り替わります。
-
NotFound : BatchAddClusterNodes レスポンスで使用され、べき等再生中にノードが削除されたことを示します。