概要

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

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

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

Hyperpodを活用するための基本知識があること
- 参考：Amazon SageMaker Hyperpodの構築手順 – Terraformを活用した構築

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

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

update-cluster:
- HyperPodクラスターのInstance Group単位またはInstance単位での更新を行う機能です。例えば、Compute Nodeの増減や、特定のインスタンスの入れ替えなどに使用されます。
update-cluster-software:
- HyperPodクラスターの基盤部分（システム領域）を更新するための機能です。これは、AWS側でHyperPodのシステムアップデートが行われる際に適用されるもので、通常はAWSからの公式アップデートがある場合にのみ使用します。AWSによる公式アップデートがない限り、使用頻度は非常に低いと考えられます。

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

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

ちなみに、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の構成例です。

{
  "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のアップデートを適用します。

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

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

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

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

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が既存のノードと同じ環境で構成されました。

2. スケールイン実行

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

---省略---

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

---省略---

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

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

コマンドを実行すると、AWSコンソール上で Cluster StatusがUpdatingに変わり、2台のCompute Nodeが ShuttingDown状態になることが確認できます。

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

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


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 クラスター設定を更新するを参考にしてください。

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方法 – スケールイン・スケールアウト」に関する記事でした。ご覧いただき、ありがとうございました！