Amazon SageMaker HyperPod のディープヘルスチェックをオンデマンドで実行してみた
はじめに
Amazon SageMaker HyperPod がオンデマンドのディープヘルスチェックに対応しました。2026 年 4 月のアップデートなのですが、検証する機会が訪れたので試してみました。
Amazon SageMaker HyperPod は、大規模な機械学習向けクラスターの構築や運用をマネージドに行えるサービスです。ディープヘルスチェックはノードのハードウェアの健全性を検証する仕組みで、従来はノードの作成時に自動で走らせる方式（OnStartDeepHealthChecks）が用意されていました。今回のオンデマンド実行は稼働中のクラスターへ任意のタイミングでディープヘルスチェックをかけられます。異常なノードが 1 つあるだけで何時間もの計算が無駄になるのでジョブへ割り当てる前に確かめることもできるようになりました。
作成時に自動で走らせる方式は以前に検証しています。
確認結果
稼働中の Slurm クラスター（ml.p5.48xlarge × 2 台）に、接続チェックとストレスチェックを 1 回ずつオンデマンドで実行しました。
- 接続チェックは約 2〜3 分、ストレスチェックは約 75 分でした
- ストレスチェックは HARDWARE_CHECK、DCGM、EFA の順に実行され、DCGM 診断だけで約 69 分かかりました
- 実行結果は CloudWatch Logs の
DeepHealthCheckResultsストリームで確認できました
検証環境
SageMaker HyperPod の Slurm クラスターは複数のインスタンスグループで構成されます。今回のクラスターは 3 つで、Slurm の制御プレーンを担う controller、ジョブを投入する login、ジョブを実行する worker です。
| 項目 | 値 |
|---|---|
| オーケストレーター | Slurm |
| リージョン | ap-northeast-1 |
| クラスターステータス | InService |
| 検証対象のインスタンスグループ | worker（ml.p5.48xlarge、2 台） |
| 障害のあるインスタンスのリカバリ | Automatic |
worker には OnStartDeepHealthChecks が設定済みで、クラスター作成時にも同じチェックが走っています。CloudWatch Logs に過去分のログが残っているのはこのためです。
クラスター詳細画面です。インスタンスは 4 台とも起動中です。
オンデマンド実行では 2 つのチェック種別を選べる
ディープヘルスチェックの種別は 2 つです。コンソールの表記と StartClusterHealthCheck API の値は次のように対応します。
| コンソールの表記 | API の値 | 内容 |
|---|---|---|
| ストレスチェック | InstanceStress |
HARDWARE_CHECK、DCGM 診断 level 4、EFA ループバックテスト |
| 接続チェック | InstanceConnectivity |
複数ノード間の NCCL all_reduce テスト |
HARDWARE_CHECK では stress-ng で CPU、メモリ、ディスクにストレスをかけます。あわせて GPU と PCI デバイスの数も検証します。接続チェックは複数ノード間の GPU 通信を測るテストのため、今回のような 2 ノード構成で実行できます。チェックの対象はワーカーノードだけです。テストの内訳と所要時間の目安は公式ドキュメントに記載があります。
インスタンスグループ単位でチェックを実行してみる
クラスター詳細画面の「インスタンスグループ」表で対象のインスタンスグループを選択し、「ディープヘルスチェックを実行」ボタンを押します。
ボタンを押すと「インスタンスグループの詳細なヘルスチェックを実行」ダイアログが開きます。「ストレスチェック」と「接続チェック」をチェックボックスで選べます。両方を同時に選べますが、今回は種別ごとの違いを見るため「接続チェック」だけを選びました。ダイアログには「これには 1 時間超かかる場合があります」という注記がありました。
「ヘルスチェックを実行」を押すと、開始を知らせるバナーが表示されました。
接続チェックは 2〜3 分で完了した
SageMaker AI 側のステータスを見ます。
aws sagemaker list-cluster-nodes --cluster-name <cluster-name>
worker 2 台の InstanceStatus.Status が DeepHealthCheckInProgress になっていることを確認します。
{
"InstanceGroupName": "worker",
"InstanceId": "i-078ca6cc8ba92e051",
"InstanceStatus": {"Status": "DeepHealthCheckInProgress", "Message": ""}
},
{
"InstanceGroupName": "worker",
"InstanceId": "i-0f35bad6641a0f163",
"InstanceStatus": {"Status": "DeepHealthCheckInProgress", "Message": ""}
}
「ヘルスチェックを実行」を押した直後にはもう遷移していました。controller と login は Running のままで、対象になったのはワーカーノードだけでした。
しばらく置いてから、worker のステータスだけを絞り込んで確認します。
aws sagemaker list-cluster-nodes --cluster-name <cluster-name> \
--query "ClusterNodeSummaries[?InstanceGroupName=='worker']"
チェック開始から 2〜3 分ほどで worker 2 台とも Running に戻っていました。
[
{"InstanceId": "i-078ca6cc8ba92e051", "InstanceStatus": {"Status": "Running", "Message": ""}},
{"InstanceId": "i-0f35bad6641a0f163", "InstanceStatus": {"Status": "Running", "Message": ""}}
]
ステータスからは合否が読み取れません。テストの結果は CloudWatch Logs に記録されるので、ストレスチェックの後にまとめて確認します。
ストレスチェックは 1 時間以上かかる
続いて同じダイアログを開き、今度は「ストレスチェック」だけを選んで実行しました。
list-cluster-nodes を 30 秒間隔でポーリングし、ステータスが変わったタイミングだけを記録しました。トリガー直後は Pending を経由してから DeepHealthCheckInProgress に遷移しました。
13:04:44 CHANGE:
i-078ca6cc8ba92e051 Pending
i-0f35bad6641a0f163 Pending
13:06:47 CHANGE:
i-078ca6cc8ba92e051 DeepHealthCheckInProgress
i-0f35bad6641a0f163 DeepHealthCheckInProgress
次に Slurm 側を見ます。ノードの状態は controller ノードに SSM で接続し、sinfo で確認しました。-a で全パーティション、-N でノード単位、-l で詳細表示を指定しています。
公式ドキュメントはチェック中のノードがメンテナンス予約に入り、ジョブがスケジュールされなくなると説明しています。
During deep health checks, affected nodes are placed in a Slurm maintenance reservation to prevent jobs from being scheduled on them. Once all checks pass, the nodes are released from the reservation and become available for workloads.
worker 2 台（ip-10-0-17-80、ip-10-0-25-130）の STATE が allocated$ になっていることを確認します。$ はメンテナンスのフラグが付いた予約にノードが入っていることを示す接尾辞です。
The node is currently in a reservation with a flag value of "maintenance".
NODELIST NODES PARTITION STATE CPUS S:C:T MEMORY TMP_DISK WEIGHT AVAIL_FE REASON
ip-10-0-17-80 1 dev* allocated$ 96 2:48:1 209715 0 1 SageMake none
ip-10-0-25-130 1 dev* allocated$ 96 2:48:1 209715 0 1 SageMake none
2 台はメンテナンス中のノードが入る hyperpod-system-maintenance パーティションにも同じ STATE で現れていました。
チェックは Slurm のジョブとしても現れます。全パーティションを対象にする -a を付けて squeue を実行すると、HARDWARE_CHECK という名前のジョブが 2 件見えました。NODES が 1 でノードが 1 台ずつ割り当てられ、実行ユーザーは root でした。
JOBID PARTITION NAME USER ST TIME NODES NODELIST(REASON)
2 hyperpod- HARDWARE root R 0:54 1 ip-10-0-25-130
3 hyperpod- HARDWARE root R 0:54 1 ip-10-0-17-80
予約の中身は scontrol show reservations で確認できます。Nodes は worker 2 台で、Flags に MAINT が付いていました。EndTime は 1 年後の 2027-08-08 でした。
ReservationName=hyperpod-deep-health-check StartTime=2026-08-08T04:04:32 EndTime=2027-08-08T04:04:32 Duration=365-00:00:00
Nodes=ip-10-0-17-80,ip-10-0-25-130 NodeCnt=2 CoreCnt=192 Features=(null) PartitionName=(null) Flags=MAINT,IGNORE_JOBS,SPEC_NODES
TRES=cpu=192
AllowedPartitions=(null) QOS=(null)
Users=root Groups=(null) Accounts=(null) Licenses=(null) State=ACTIVE BurstBuffer=(null)
MaxStartDelay=(null)
実行から約 75 分後にすべてのテストが終わりました。sinfo の STATE は idle へ戻り、scontrol show reservations も予約なしになりました。EndTime が 1 年後でも予約はチェックの完了とともに解放されていました。
NODELIST NODES PARTITION STATE CPUS S:C:T MEMORY TMP_DISK WEIGHT AVAIL_FE REASON
ip-10-0-17-80 1 dev* idle 96 2:48:1 209715 0 1 SageMake none
ip-10-0-25-130 1 dev* idle 96 2:48:1 209715 0 1 SageMake none
No reservations in the system
実行結果を CloudWatch Logs から確認する
チェック結果はクラスターのロググループ /aws/sagemaker/Clusters/<cluster-name>/<cluster-id> に記録されます。ログストリーム名は DeepHealthCheckResults/<log_stream_id> です。
aws logs describe-log-streams \
--log-group-name "/aws/sagemaker/Clusters/<cluster-name>/<cluster-id>" \
--log-stream-name-prefix "DeepHealthCheckResults"
該当のストリームからイベントを取得します。
aws logs get-log-events \
--log-group-name "/aws/sagemaker/Clusters/<cluster-name>/<cluster-id>" \
--log-stream-name "DeepHealthCheckResults/24db415f6869429f5439a03d884079cb490fe980b61430c22a01e3299e095122" \
--limit 50
接続チェックで追記されたのは末尾の 2 件で、NCCL テストの結果だけでした。失敗が 0 台で、対象の 2 台ともテストに成功していることを確認します。
{"timestamp": 1786161335918, "message": "0 nodes failed NCCL test at batch size 2. Instance IDs: []"}
{"timestamp": 1786161337447, "message": "2 out of 2 nodes succeeded NCCL test. Instance IDs: [i-078ca6cc8ba92e051 i-0f35bad6641a0f163]"}
ストレスチェックの方は同じストリームに HARDWARE_CHECK、DCGM、EFA の 3 件が追記されていました。
クラスター作成時の分も同じストリームに残っていました。記録されていたのは HARDWARE_CHECK、DCGM、EFA、NCCL の 4 種類でした。作成時は OnStartDeepHealthChecks で接続チェック、ストレスチェックの両方が有効になっていたためです。
所要時間は DCGM 診断がほぼすべてだった
ストレスチェックの経過を CloudWatch Logs のタイムスタンプから追ってみました。時刻は JST です。
| 時刻 | 出来事 |
|---|---|
| 13:04 | 「ヘルスチェックを実行」を押下 |
| 13:08:33 | 2 out of 2 nodes succeeded HARDWARE_CHECK test |
| 14:17:56 | 2 out of 2 nodes succeeded DCGM test |
| 14:19:05 | 2 out of 2 nodes succeeded EFA test |
実行ボタンを押してから完了まで約 75 分かかりました。そのうち HARDWARE_CHECK の完了から DCGM の完了までが約 69 分で、9 割以上が DCGM 診断時間でした。公式ドキュメントは DCGM 診断 level 4 の目安を GPU 数に応じて約 45〜90 分としています。NVIDIA H100 を 8 基搭載する ml.p5.48xlarge での計測結果はこの範囲に収まりました。EFA はその後 1 分ほどで終わっています。
接続チェックの計測結果は約 2〜3 分で、公式ドキュメントの目安（NCCL テストで約 5〜15 分）より短時間でした。コンソールのダイアログにある「1 時間超かかる場合があります」という注記はストレスチェックを実施した場合のことを指していました。
まとめ
稼働中の SageMaker HyperPod クラスターにコンソールからディープヘルスチェックをオンデマンドで実行しました。所要時間は接続チェックが約 2〜3 分、ストレスチェックが約 75 分で、うち約 69 分は DCGM 診断でした。ストレスチェックの実行中は hyperpod-deep-health-check 予約と HARDWARE_CHECK ジョブが Slurm 上に作られていました。結果は CloudWatch Logs の DeepHealthCheckResults ストリームで確認できました。
おわりに
ご厚意で P5 が 2 台起動しているクラスターの空き時間を使わせてもらい、ノード間の NCCL テストも試すことができました。2 ノードでディープヘルスチェックを一通り試せたのが今回の収穫です。
