Amazon Web Services ブログ

AWS Parallel Computing Service と Kiro CLI で HPC のデプロイを加速する

オンプレミスの HPC 環境からの移行を進める研究チームは、クラウドへのデプロイの複雑さに悩まされることがよくあります。従来のアプローチでは、AWS のネットワーク、ストレージアーキテクチャ、Slurm の構成管理に関する深い専門知識が必要でした。一般的な手動デプロイでは、インフラのプロビジョニング、ネットワークトポロジの設計、スケジューラの構成、パフォーマンスチューニングに数週間を要します。プラットフォームエンジニアリングのリソースが限られている研究チームは、計算能力に対する差し迫ったニーズと、デプロイの技術的な障壁との間で板挟みになってしまいます。

本記事では、業界のベストプラクティスを組み込んだ AWS PCS クラスターを、Kiro CLI を使って自動的にデプロイ・構成する方法をご紹介します。インフラのプロビジョニング、モニタリングのセットアップ、コスト最適化を担いながら、研究チームが特定のワークロードに必要とする柔軟性を維持する「カスタムエージェント」の作成手順を順を追って解説します。

クラウドにおける HPC

クラウドベースの HPC は、柔軟なコンピューティングアクセス、幅広いリソースの可用性、そして価値あるインフラの抽象化により、標準的な手法となっています。本記事では、AWS Parallel Computing Service (PCS) と Kiro CLI を活用して、このアプローチを実演します。

AWS PCS: AWS PCS は、自動構成・スケーリング・メンテナンスを備えたマネージドな Slurm スケジューラを提供することで、HPC のデプロイを簡素化します。本サービスはクラスターのライフサイクル管理を担う一方で、コンピューティングリソースとジョブスケジューリングポリシーに対するコントロールはお客様が維持できます。PCS は、共有ストレージ向けの Amazon Elastic File System やモニタリング向けの Amazon CloudWatch といった AWS サービスとネイティブに統合され、HPC のデプロイで通常必要となる統合作業を削減します。

Kiro CLI: Kiro CLI は、特定のユースケースに合わせた専門的なガイダンスを備えたカスタムエージェントを定義することで、非常に強力なものになります。ドメインの専門知識をエージェント定義に直接エンコードすることで、組織のベストプラクティスや要件を理解した専用の自動化を構築できます。例えば本記事では、HPC ワークロード向けの AWS Parallel Computing Service のベストプラクティス（最適なインスタンスの選択、ネットワーク構成、ストレージの最適化など）を組み込んだ PCS デプロイエージェントを作成します。このエージェントは確立されたデプロイパターンを活用することで、複雑なクラスターのプロビジョニングを効率化し、デプロイ時間と構成ミスのリスクの両方を削減します。汎用的な自動化とは異なり、このアプローチは実証済みの方法論を特定のインフラのニーズに適応させる、インテリジェントでコンテキストを理解した支援を提供します。

はじめに

自動化された PCS デプロイのアプローチを実装する前に、3 つの前提条件が必要です。

エージェントを使う

まず、エージェントを初期化します。Kiro で TODO リスト設定を有効にしておくとよいでしょう。これによりエージェントのより詳細なプランニングが可能になり、クラスターの作成を進める際にタスクのリストを作成し、ステップごとに処理を進めるようになります。

kiro settings chat.enableTodoList true

対話型の PCS デプロイエージェントを起動します。

kiro chat --agent pcs-interactive-agent

ディスカバリーフェーズ

ここで、エージェントにクラスターの作成を手伝ってもらいます。

User: I am new to PCS. Help me create my first cluster with best practices. （訳: PCS は初めてです。ベストプラクティスに沿って最初のクラスターを作成するのを手伝ってください。）

エージェントはまずアクティブな AWS 認証情報を確認し、詳細が不明な場合はいくつかのディスカバリーのための質問を返します。また、既存の環境を調査し、ベストプラクティスに基づいた推奨事項を提示します。これは、既存の VPC やその他の AWS リソースをエージェントに使ってもらいたい場合に役立ちます。

ここで詳細を調整・指定でき、エージェントは最終的なサマリーを作成して、お客様の AWS アカウント内でインフラの作成を開始します。

インフラの作成

以下はインフラ作成プロセスの抜粋です。環境や要件によって、この出力は変わる可能性があります。

Agent:

VPC Created:vpc-█████████████████ (10.3.0.0/16)

- Public Subnet:subnet-████████████ (10.3.0.0/20) - ログインノード用
- Private Subnet:subnet-████████████ (10.3.32.0/20) - コンピュートノード用
- Internet Gateway:igw-████████████
- NAT Gateway:nat-████████████ (52.38.92.80)
- Route Tables:Public (rtb-████████████), Private (rtb-01484185571aabba1)

Security Groups Created:

- Cluster SG:sg-████████████ (Slurm ポート 6817-6818)
- SSH SG:sg-████████████ (SSH ポート 22)

IAM Role Created:AWSPCS-scientific-cluster-role

- Instance Profile:AWSPCS-scientific-cluster
- Policies:AmazonSSMManagedInstanceCore + PCS registration

Cluster Created:pcs_xfzpdypb7z (scientific-cluster)

- Status:CREATING → エンドポイント取得中
- Size:SMALL (最大 100 ノード、1000 ジョブ)
- Slurm Version:24.11
- Controller Endpoint:10.3.45.99:6817

Launch Templates Created:

- Compute:lt-████████████ (c6i.xlarge)
- Login:lt-████████████ (c6i.xlarge + SSH key)

Compute Node Groups Created:

- Login Group:pcs_ndgfaikhwl (パブリックサブネット内に 1 台の c6i.xlarge)
- Compute Group:pcs_████████████ (プライベートサブネット内に 0〜10 台の c6i.xlarge)
- AMI Used:ami-████████████ (Slurm 24.11)
- Status:CREATING (3〜5 分かかります)

Queue Created:pcs_bogst8bszr (scientific)

- Status:CREATING → ACTIVE
- Targets:コンピュートノードグループ (pcs_dficwpzin2)
- Purpose:科学計算ワークロード

インフラの作成が完了すると、エージェントは詳細を提示します。AWS リソースのデプロイが失敗する場合もあります。エージェントに与えられた指示には、そうした問題のトラブルシューティングを行い、処理を続行する前に修正するように記載されています。また、エージェントは /generated ディレクトリにクラスターのサマリーとドキュメントを作成し、何がどのように構築・構成されたかを正確に示します。

完了すると、エージェントはクラスターへの接続方法とテスト方法を示し、コストの見積もりも提示します。

このわずかなやり取りの中で、完全に機能するネットワーク、コントローラー、キュー、コンピュートノードとログインノード、適切なテンプレートとロールを備えた、相応に複雑なアーキテクチャを作成しました。これらすべてを、一般的なニーズとユースケースを定義するだけで実現できたのです。

図 1: Virtual Private Cloud (VPC) 内での AWS Parallel Computing Service (PCS) クラスターのデプロイを示すアーキテクチャ図。

この図では、VPC の外側に配置された PCS コントローラーが PCS キューに接続されています。VPC の内側には 2 つのサブネットがあります。パブリックサブネットには、静的な起動テンプレートを使用する 1 台の c6i.xlarge インスタンスを含むログインノードグループがあり、プライベートサブネットには、動的な起動テンプレートを使用する c6i.xlarge インスタンス（0〜10 台のキャパシティ）を含むコンピュートノードグループがあります。両方のノードグループにはロールの割り当てが含まれ、コンピュートインスタンスや起動テンプレートのシンボルなどの AWS サービスアイコンで表現されています。

これらすべてのプロセスは、ユーザーとのいくつかのやり取りを含めて約 30 分で完了し、すぐにログインしてジョブの実行を開始できます。このアーキテクチャは、共有ストレージや追加のコンピュートノードグループ・キューなどを含むように拡張できます。

推奨されるベストプラクティス

  • エージェントへの指示は、直接的・具体的・明示的に行う
    • 例えば、本記事のアーキテクチャではファイルシステムを要求しませんでしたが、FSx for Lustre 分散ファイルシステムのセットアップを併せて依頼することも簡単にできる可能性があります
  • デプロイをモニタリングし、混乱しているようであればコマンドをキャンセルする
  • 時折の失敗は許容する — エージェントは回復する傾向があります
  • 特定のユースケースに合わせてエージェントの構成をカスタマイズする
  • ワークロードのコンテキストと要件を包括的に提供する

既知の制限事項

  • エージェントは詳細を見失うことがある — 必要に応じて指示を再度伝えてください
  • 手動での検証が必要 — 結果が要件に合致しているか確認してください

まとめ

AWS Parallel Computing Service (PCS) は、Slurm クラスターを大規模に運用する際の運用の複雑さを取り除く、フルマネージドな HPC サービスを研究チームに提供します。Kiro CLI のマルチエージェントアーキテクチャと組み合わせることで、チームは本番環境対応の HPC 環境を数週間ではなく数時間でデプロイできるようになります。このアプローチは、基盤となるインフラの管理にかかるオーバーヘッドなしに計算能力を必要とする研究組織にとって、特に価値があります。 それでは、よい構築を！（Happy Building!）

著者について

Markus Adhiwiyogo

Markus Adhiwiyogo は、Amazon EC2 インスタンスを担当するシニアプロダクトマーケティングマネージャーであり、AWS Graviton、AWS Inferentia、AWS Trainium を含む AWS カスタムシリコンに注力しています。

Kyle Bush

Kyle Bush は、AWS のヘルスケア・ライフサイエンスチームでグローバルなヘルスケア ISV を支援するシニアソリューションアーキテクトです。Kyle は、お客様が最新のテクノロジーを活用してデジタルトランスフォーメーションを推進し、ヘルスケアの提供と成果を近代化できるよう支援することに情熱を注いでいます。

Charunethran Panchalam Govindarajan

Charunethran Panchalam Govindarajan は、AWS のシニアプロダクトマーケティングマネージャーであり、ハイパフォーマンスコンピューティングと量子テクノロジーに注力しています。彼は幅広いテクノロジー領域で活躍してきましたが、特に R&D と製品開発の交差点に関心を持っています。Charunethran はスタンフォード大学で電気工学の修士号を取得しています。仕事以外では、スケッチや哲学的な会話を楽しんでいます。

Kareem Abdol-Hamid

Kareem は、スタートアップ向けのシニアアクセラレーテッドコンピュートスペシャリストです。アクセラレーテッドコンピュートのスペシャリストとして、Kareem は生成 AI、ハイパフォーマンスコンピューティング、超大規模ワークロードに関する新たな課題に日々取り組んでいます。余暇にはピアノを演奏し、ビデオゲーム『ストリートファイター』で腕を競っています。

翻訳はソリューションアーキテクトの 山田航司 が担当しました。原文はこちらです。