AWS PCS（Parallel Computing Service）でログインノード・計算ノードを構築して、自動スケーリングまで検証してみました

こんにちは、クラスメソッドのキム・ジェウク（Kim Jaewook）です。

今回は、AWS PCS（Parallel Computing Service）を使ってログインノードと計算ノードを構築し、ジョブの実行に応じた自動スケーリングまで検証してみました。

AWS PCSとは

AWS PCSは、Slurmをベースとしたフルマネージド型のHPCクラスタサービスです。

ユーザー自身でSlurmコントローラーを構築・運用する必要がなく、コントローラーはAWSが管理します。一方、ユーザー側のAWSアカウントでは計算ノード（コンピュートノード）を管理する構成になります。

ジョブが存在しないときは計算ノードを0台までスケールダウンし、ジョブが投入されると必要なノードを自動的に起動する、といった構成が可能です。

PCSではいくつのAZが必要なのか

コンソールからクラスタ作成画面を開いて確認すると、ネットワーク設定のサブネット項目は単一選択になっていました。

一方で、その後のコンピューティングノードグループ作成時には、複数のサブネット（複数AZ）を指定できる項目が別途用意されています。

つまり、コントローラーは単一AZ、計算ノードは必要に応じてMulti-AZに拡張できる構成になっています。

Step 1. PCSクラスタの作成

クラスタの詳細

スケジューラー設定

ネットワーク

Step 2. EC2起動テンプレートの作成

コンピューティングノードグループでは、EC2インスタンスを自動的に作成・削除します。

そのため、どのようなスペックのEC2を起動するのかを、あらかじめEC2起動テンプレートとして作成しておきます。

主な設定

Step 3. コンピューティングノードグループの作成（計算用）

ここで、最小インスタンス数を0に設定することが「ジョブがないときにノードを完全に削除する」という要件を実現するための重要なポイントです。

ハマったポイント：一般的なAMIではブートストラップに失敗する

最初は、起動テンプレートに一般的なAmazon Linux 2023 AMIをそのまま指定して、ノードグループを作成しました。

ログインノードに接続して確認してみると、

sinfo
sh: sinfo: command not found

Slurmのコマンド自体がインストールされていませんでした。

ブートストラップのログを確認してみます。

sudo cat /var/log/amazon/pcs/bootstrap.log

/usr/bin/cloud-init-per: line 63: /opt/aws/pcs/bin/pcs_bootstrap_init.sh: No such file or directory

原因は、PCSがノードのセットアップ時に実行するブートストラップスクリプト自体がAMIに存在しなかったことでした。

PCSでは任意のAMIを使用できるわけではなく、PCS用のブートストラップスクリプトが含まれたAMIを使用する必要があります。

そこでAWS CLIを使って、今回のクラスタで使用しているSlurmバージョン（25.11）に対応したサンプルAMIを検索しました。

aws ec2 describe-images --region ap-northeast-1 --owners amazon \
  --filters 'Name=name,Values=aws-pcs-sample_ami-*' \
  'Name=state,Values=available' \
  --query 'sort_by(Images, &CreationDate)[].[Name,ImageId,CreationDate]' \
  --output table

検索されたAMIを起動テンプレートのAMIとして指定し、ノードグループを再作成しました。

その後、ブートストラップログを再度確認すると、正常に処理が進んでいることを確認できました。

Step 4. キューの作成

※ コンピューティングノードグループが「Active」状態になってから、キューに接続することができます。

Step 5. ログインノードグループの作成

ユーザーが実際に接続してジョブを投入するためのノードです。

専用の「ログインノード作成」メニューが用意されているわけではなく、コンピューティングノードグループの作成画面をもう一度使用し、設定を変更して作成します。

Step 6. ログインノードへの接続とクラスタ状態の確認

ログインノードグループがActive状態になった後、EC2コンソールから対象のインスタンスを確認し、SSM Session Managerを使って接続しました。

SlurmクライアントのコマンドがPATHに設定されていなかったため、絶対パスを指定して実行します。

find / -name "sinfo" 2>/dev/null

/opt/aws/pcs/scheduler/slurm-25.11/bin/sinfo

/opt/aws/pcs/scheduler/slurm-25.11/bin/sinfo

PARTITION       AVAIL  TIMELIMIT  NODES  STATE NODELIST
queue           up     infinite     2    idle~ node-group-1-[1-2]

キューと2台のノードが正常に認識されていることを確認できました。

idle~ のチルダ（~）は、ノードがまだ実際には起動しておらず、スリープ状態になっていることを示しています。

Step 7. 実際にジョブを投入して検証

それでは、実際にジョブを投入してみます。

/opt/aws/pcs/scheduler/slurm-25.11/bin/srun -p queue-1 --nodes=1 hostname

ジョブを投入すると、すぐには結果が返ってこず、しばらく待機状態になりました。

これは、ノードが0台の状態でジョブが投入されると、PCSがリアルタイムでEC2インスタンスを新たに起動し、その後ブートストラップ（Slurmのインストールおよびクラスタへの登録）が完了してからジョブを実行するためです。

数分後、以下のような結果が返ってきました。

ip-xx-x-xxx-xx.ap-northeast-1.compute.internal

EC2コンソールでも、このタイミングで新しいインスタンスが自動的に作成されたことを確認できました。

さらにジョブが終了した後、設定したアイドル時間（10分）が経過すると、EC2コンソール上で該当インスタンスが自動的に終了したことも確認できました。

まとめ

今回の検証を通して、AWS PCS上にSlurmベースのHPC環境を構築し、ログインノードからジョブを投入すると、必要な計算ノードが自動的に起動する一連の流れを確認できました。

特に、計算ノードの最小インスタンス数を0に設定し、アイドル時間に応じてスケールダウンする構成にすることで、ジョブがないときはEC2のコストを抑え、ジョブが投入されたときだけ必要な計算リソースを起動することができます。

また、今回の検証では一般的なAmazon Linux 2023 AMIを使用した際にPCSのブートストラップに失敗しました。PCSではSlurmのバージョンに対応したPCS用AMIを使用することが重要だということも確認できました。

さらに、ログインノードと計算用ノードグループを分け、計算用ノードグループだけをキューに接続することで、それぞれの役割を分離できます。

今回は検証用として t3.micro を使用したシンプルな構成でしたが、実際のHPC環境では複数のインスタンスタイプやMulti-AZ構成を利用することで、より大規模なワークロードにも対応できます。

結果として、AWS PCSを利用することで、Slurmコントローラーの構築・運用負担をAWSに任せながら、必要な計算リソースだけを動的にスケールアウト・スケールインできるHPC環境を比較的簡単に構築できることが分かりました。