Amazon SageMaker HyperPod ClusterのUpdate方法  – スケールイン・スケールアウト

# 概要
HyperPodを運用する際には、環境のアップデートが必要となる場面が必ず発生します。
例えば、ノード数の変更や、複数のノード内にある構成要素の更新など、適切な運用管理が求められます。

そこで、本記事では、HyperPodのアップデートについて詳しく解説し、効果的な更新方法や考慮すべきポイントを紹介します。

# HyperpodのUpdate前に確認すべき前提条件

- Hyperpodを活用するための基本知識があること
    - 参考：[Amazon SageMaker Hyperpodの構築手順 – Terraformを活用した構築](https://qiita.com/jeayoon/items/39de03f72d1f3482f254)

# Update対象のコンポーネントと影響範囲

HyperPodのアップデートには、大きく分けて 2つの主要な機能があります。

- [update-cluster](https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker-hyperpod-eks-operate-cli-command-update-cluster.html):
    - HyperPodクラスターのInstance Group単位またはInstance単位での更新を行う機能です。例えば、Compute Nodeの増減や、特定のインスタンスの入れ替えなどに使用されます。

- [update-cluster-software](https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker-hyperpod-eks-operate-cli-command-update-cluster-software.html):
    - HyperPodクラスターの基盤部分（システム領域）を更新するための機能です。これは、AWS側でHyperPodのシステムアップデートが行われる際に適用されるもので、通常はAWSからの公式アップデートがある場合にのみ使用します。AWSによる公式アップデートがない限り、使用頻度は非常に低いと考えられます。

本記事では、update-cluster を使用したインスタンス単位でのアップデートを実施します。
これは、Compute Nodeの入れ替えや、特定のノードのリソース変更など、運用上頻繁に発生する更新作業に該当します。

具体的には、**1つのCompute Nodeを3つにスケールアウトする追加アップデート**と、**3つのCompute Nodeを1つにスケールインする縮小アップデート**の操作を例に解説します。

<img width="800" alt="Image" src="https://github.com/user-attachments/assets/59503697-af7a-41a7-bf9c-5188e5353e7b" />


ちなみに、Lifecycle Scriptsを活用したソフトウェアの更新については、基本的にHead Node上で管理し、各Compute Nodeに適用する形になります。具体的には、Lifecycle Scriptsの中で ソフトウェアのアップデート処理を記述したスクリプトを準備し、全ノードに適用するという流れになります。

次のセクションでは、`update-cluster`を利用して、実際にノードの更新を行う手順について解説していきます。

# HyperpodのUpdate手順と実施方法

## 1. スケールアウト実行
HyperPodをアップデートする際には、新規作成（Create）時と同様に、アップデート用のJSONファイルを別途作成 する必要があります。

今回は、1つのCompute Nodeを3つにスケールアウトする追加アップデート を行うためのJSONファイルを作成します。

以下が、そのアップデート用JSONファイル`update_cluster.json`の構成例です。


```bash
{
  "ClusterName": "leo-stg-hyperpod-cluster",
  
  "InstanceGroups": [
      {
          
          "InstanceGroupName": "leo-stg-head-ig",
          "InstanceType": "ml.m5.large",
          "InstanceCount": 1,
          "LifeCycleConfig": {
            "SourceS3Uri": "s3://leo-stg-hyperpod-lifecycle-778c45ef/lifecycle-script-directory/src",
            "OnCreate": "on_create.sh"
          },
          "ExecutionRole": "arn:aws:iam::640168457519:role/leo-stg-SagemakerHyperpod-Role",
          "ThreadsPerCore": 2,
          "InstanceStorageConfigs": [
              {
                 "EbsVolumeConfig":{     
                    "VolumeSizeInGB": 30
                 }
              }
          ]
      },
      {
          "InstanceGroupName": "leo-stg-compute-ig",
          "InstanceType": "ml.g5.xlarge",
          "InstanceCount": 3, # この部分を「3」にする
          "LifeCycleConfig": {
            "SourceS3Uri": "s3://leo-stg-hyperpod-lifecycle-778c45ef/lifecycle-script-directory/src",
            "OnCreate": "on_create.sh"
          },
          "ExecutionRole": "arn:aws:iam::640168457519:role/leo-stg-SagemakerHyperpod-Role",
          "ThreadsPerCore": 2,
          "InstanceStorageConfigs": [
              {
                 "EbsVolumeConfig":{     
                    "VolumeSizeInGB": 30
                 }
              }
          ]
      }
  ]
}
```

JSONの準備が完了したら、次のコマンドを実行してHyperPodのアップデートを適用します。

```bash
aws sagemaker update-cluster --cli-input-json file://update_cluster.json
```

アップデートコマンドを実行すると、AWSコンソール上で Cluster Status が Updating に変わります。
また、既存のインスタンスに加えて 2台の新しいインスタンスが追加されるため、この2台が Pending 状態となり、アップデートが進行中であることが確認できます。


<img width="800" alt="Image" src="https://github.com/user-attachments/assets/b64538a2-2397-4d1d-8ba3-7c13f6a2271b" />

数分後、AWSコンソール上でCluster Statusが`InService`に変わり、Compute Nodeの台数が3台に増加したことを確認できます。

<img width="800" alt="Image" src="https://github.com/user-attachments/assets/a9e7a8e7-27c3-4c38-bcf3-b8b8be3a4d1c" />


Head Nodeにアクセスし、sinfoコマンドを実行すると、Slurmの設定も正常に反映されていることが確認できます。

```bash
ubuntu@ip-10-1-48-221:~$ sinfo
PARTITION   AVAIL  TIMELIMIT  NODES  STATE NODELIST
dev*           up   infinite      3   idle ip-10-1-24-24,ip-10-1-28-200,ip-10-1-39-203
partition-1    up   infinite      3   idle ip-10-1-24-24,ip-10-1-28-200,ip-10-1-39-203
```
また、既存のS3に保存されているLifecycle Scriptsに基づき、新たに追加されたCompute Nodeが既存のノードと同じ環境で構成されました。

<img width="800" alt="Image" src="https://github.com/user-attachments/assets/6fec7700-f552-4d0b-a8f7-aba0cc461d03" />

## 2. スケールイン実行

追加のアップデートが正常に適用されたことを確認できたので、次はスケールインを実行します。
まず、`update_cluster.json`内のComputeNodeセクションにある`InstanceCount`を次のように修正し、ノード数を減らす設定 を行います。

```bash
---省略---

         "InstanceCount": 1, # この部分を「1」にする

---省略---
```

JSONの準備が完了したら、次のコマンドを実行してHyperPodのアップデートを適用します。

```bash
aws sagemaker update-cluster --cli-input-json file://update_cluster.json
```
コマンドを実行すると、AWSコンソール上で Cluster Statusが`Updating`に変わり、2台のCompute Nodeが `ShuttingDown`状態になることが確認できます。

<img width="800" alt="Image" src="https://github.com/user-attachments/assets/d547ec4c-4dbf-4b0d-bdd2-72e9fcd0515f" />

数分後、Cluster Status が InService に変わり、Compute Nodeの台数が1台に縮小 されたことを確認できます。

<img width="800" alt="Image" src="https://github.com/user-attachments/assets/7dd9eff3-0cae-4b29-9a55-ef0357c44921" />

さらに、Head Nodeにアクセスし、sinfoコマンドを実行すると、Slurmの設定も正常に反映されており、クラスターのノード情報が最新の状態に更新されていることを確認できます。

```bash

ubuntu@ip-10-1-48-221:~$ sinfo
PARTITION   AVAIL  TIMELIMIT  NODES  STATE NODELIST
dev*           up   infinite      1   idle ip-10-1-39-203
partition-1    up   infinite      1   idle ip-10-1-39-203
```
これで、**1つのCompute Nodeを3つにスケールアウトする追加アップデート**と、**3つのCompute Nodeを1つにスケールインする縮小アップデート**の適用手順を確認できました。

AWSコンソールおよびsinfoコマンドを用いて、ノードの追加・削減が正常に反映され、Slurmのジョブスケジューリング環境が適切に更新されることも確認できました。

# Update時の注意点

## 1. Service Quotaの確認
AWS SageMaker HyperPodを運用する際、`update-cluster`を実施する前に、Service Quotaの確保を行っておくことが重要です。適切なリソースが確保できていないと、アップデート時に制限に引っかかり、スムーズな更新ができなくなる可能性があります。

Service Quotaの申請完了までには、場合によっては数週間かかるケースがあります。

HyperPodを安定的に運用するためには、アップデート前に必要なリソースのクォータを事前に申請し、確保しておくことを推奨します。

## 2. JSON Fileの指定Optionsに従う
HyperPodクラスターの更新を行う際には、update-clusterコマンドを使用します。この際、適切なオプションを指定する必要があります。

詳細なオプションについては、[SageMaker HyperPod クラスター設定を更新する](https://docs.aws.amazon.com/ja_jp/sagemaker/latest/dg/sagemaker-hyperpod-eks-operate-cli-command-update-cluster.html)を参考にしてください。

## 3. Lifecycleの冪等性

HyperPodの各ノードは`Lifecycle Script`を基に構築されており、このスクリプトは各ノードの冪等性を担保する仕組みになっています。

そのため、アップデート前のLifecycle Scriptとアップデート後のLifecycle Scriptに差異がある場合、ノードごとの設定にズレが生じる可能性があります。

Lifecycle Script変更時のポイント
- アップデート後のノード設定が既存のノードと異なる可能性を考慮する
- Partitionを分けるなどの戦略を検討する
- HyperPodは基本的にクラスター全体の統一された設定が求められるため、すべてのノードに対して同じ設定を適用することが望ましい

HyperPodは、特定の用途に応じてPartitionを分割して異なる設定を適用するケースも考えられますが、基本的には全ノードが統一された設定で動作することを前提として設計されています。そのため、アップデート時にはLifecycle Scriptの変更がクラスター全体にどのような影響を与えるかを慎重に検討する必要があります。

# 最後に
SageMaker HyperPodのアップデートはシンプルに見えますが、適切な事前準備と計画的な実施が不可欠です。特に、Service Quotaの確認、Lifecycle Scriptの統一、運用状況のモニタリングが重要になります。今回の検証を通じて、スケールイン・スケールアウトの手順を確認し、運用上の考慮点を整理できました。今後も最適な運用方法を模索しながら、HyperPodをより効果的に活用していきたいと思います。

以上、「Amazon SageMaker HyperPod ClusterのUpdate方法  – スケールイン・スケールアウト」に関する記事でした。ご覧いただき、ありがとうございました！