Amazon Web Services ブログ

AWS ParallelCluster 3のご紹介

この記事は、2021年9月10日にBrendan BoufflerとRye Robinsonによって投稿された「New: Introducing AWS ParallelCluster 3」をソリューションアーキテクトの小野が翻訳したものです。

コンピュータによる流体力学や分子動力学、天気予報といった一般的なHPCワークロードを走らせるという事は、沢山の関連するコンポーネントを動かすという事でもあります。数百あるいは数千ものCPUコアやそれらを管理するジョブスケジューラ、スループットやIOPSに最適化された共有ファイルシステム、数多のライブラリ、高速なネットワーク、それらをまとめるヘッドノード等が必要です。これらは研究者のようなHPCワークロードの利用者にとっては単に必要最低限のものであって、このコンポーネントを揃える事が目的ではありません。クラウドに移行する事によって、より本質的な事——例えばあなたが研究者なのであれば、研究所の同僚が解答を待っているような問題を解き明かす事——に集中する事ができます。

2018年以来、AWS ParallelClusterはHPC環境のオーケストレーションを簡便にし、世界が現在直面している最も野心的な問題に取り組む研究者やエンジニアを手助けしてきました。HPCの文脈で「Infrastructure as code」が何を意味するのかが分かった事で、お客様を喜ばせる新しい方法を見つける事ができました。たった1つのコマンドで、Lustreファイルシステムや可視化端末を含むHPCクラスタを作成できるようになった時、HPCワークロードをクラウドで試す人が以前より増えました。そういった人達は新しい機能を求めています。

私達は本日AWS ParallelCluster 3を発表します。エンドユーザやシステムインテグレータは、インフラストラクチャ、ミドルウェア、ライブラリ、ランタイムコードといったシステム全域に及ぶHPCのend-to-endの「レシピ」を求めています。また、APIライクなインタフェースを通してParallelClusterとやり取り可能で、インタフェースやサービスをプログラムのように作成する事も必要とされています。私達はWorking Backwardの手法でこれらのフィードバックに取り組み、顧客との何千もの会話をもとに今日お見せしているものを作成しました。

大小含め沢山の変更点があります。幾つかの重要なものを以下に紹介し、より詳細な説明は後述します。

  • 新しい柔軟なAWS ParallelCluster API: これにより、ParallelCluster上にソリューションやインタフェースを構築したり、クラスタのライフサイクルをパイプラインの一部として含めたりする作業が容易になります。また、CLIもこれと一致するように変更したため、スクリプトまたはイベント駆動型のワークフローが簡単になりました。
  • EC2 Image Builderを利用したカスタムAMIの作成: ParallelClusterでのカスタムAMIのサポートは、2018年にこの機能が紹介されてから成長し今ではメインストリームプロセスになっています。EC2 Image Builderを導入する事で、誰でも簡単にこのプロセスを自動化する事ができるようになりました。イメージ作成を前倒しする事でカスタムAMIを使ったクラスタでのスケーリングが高速になりました。信頼性もまた向上しました。パッチを適用する事がより簡単になりました。
  • コンフィグファイルの新しいフォーマット: ParallelClusterのコンフィグはこのバージョンからYAMLフォーマットが使われます。1つのYAMLファイルが1つのクラスタを定義します。その他の幾つかの変更もあり、クラスタ構成を整理する事が容易になると考えています。
  • ネットワーク設定オプションの簡素化: ネットワークの設定を合理化し既存のプライベートなRoute 53ゾーンを使用できるようにしました。またElastic IPの使い方で柔軟性が向上しました。
  • 細かい粒度でのIAM権限: どのように権限を付与するのかについて変更しました。ヘッドノードとコンピュートノードに異なるIAMロール又はインスタンスプロファイルを指定する事ができます。ロールの適用時に特定の制限が必要な組織では、作成時にIAM権限の境界を与える事ができます。
  • ランタイムカスタムスクリプト: 現在起動中のクラスタのコンピュートノードに対して、pre-install、post-installのスクリプトを設定する事が可能になりました。このスクリプトはpcluster updateコマンドを実行すると更新されます。

これらの特徴はクラスタの最初のセットアップを簡素にし、カスタムした環境の構築時間を減らし、管理や再現性の担保を容易にするものです。

現行機能の変更

2020年6月に私達はSun of Grid Engine (SGE)とTorqueの2つのジョブスケジューラを非推奨とアナウンスしました。またジョブスケジューラオプションのドキュメントに、SGEやTorqueを選択する事は可能ですがサポートの正式な終了日は2021年12月31日となるため、推奨できないという明確な警告を追加しました。

ここ数年間、この2つのOSSのリポジトリにはコミュニティアップデートがなかったため、この決定は1年前になされました。更新が無いという事は脆弱性に対するパッチが無い事を意味するため、攻撃に対するリスクが高くなります。責任共有モデルに基づくAWSへのお客様の期待に応えるために、ParallelCluster 2.xの各リリースでは、これらのパッケージに対するセキュリティを懸命に強化してきました。しかしParallelCluster 3では、独力でサポート可能なスケジューラのみを直接サポートするように変更しています。

SGEやTorqueをスケジューラにしているクラスタが動作を停止するわけではありませんし、2021年12月31日までのParallelCluster 2.11のパッチリリースには、依然としてSGE/Torqueが含まれ続けます。しかしながら、それ以降SGEやTorqueに起因する問題はAWSのサポート範囲外になります。

また2021年12月31日でCentOS 8がend-of-lifeとなる事が発表されたため、このOSのサポートも終了します。上記2つのスケジューラと同様に、この日以降のParallelCluster 2.11のパッチリリースにはCentOS 8のサポートは含まれなくなります。

ParallelClusterサポートポリシー

6月のParallelCluster 2.11.0のリリースの際にサポートポリシーを変更しました。良い機会なのでParallelCluster 3の登場のこのタイミングで、再度そのサポートポリシーの変更について説明します。

ParallelCluster 2.11は2.xシリーズの最後のマイナーリリースであり機能安定版です。バグの修正とセキュリティに関する更新のみ2022年12月31日まで引き続きパッチリリースが行なわれます。このパッチリリースは6ヶ月毎を予定していますが、重大な問題で即応が必要な場合この限りではありません。機能安定板リリースで、一貫性と予測可能性を提供する事を目指していますが、これはend-of-lifeになったコンポーネントには適用されない事に注意して下さい。例えば、SGE、Torque、CentOS 8に関する機能は全て2021年12月31日にend-of-lifeになります。従ってそれ以降の2.11.xリリースには含まれません。

ParallelCluster 3.0は本日から18ヶ月先の2023年3月31日までサポートの対象となります。

ParallelClusterは今後も新機能の追加が行なわれ、これまでのようなマイナーリリース(例、3.1、3.2…)もあります。これらのマイナリリースの日付を起点に18ヶ月後までサポート期間が延長されていきます。これは次の条件に従います。

  • バグとセキュリティの問題は、より早急なパッチリリース(例、3.1.1)を必要とする重大度でない限りマイナーリリース(例、3.1)で対処されます。
  • バグ修正とセキュリティ修正を適用するには、これらの修正が提供されているマイナーリリースまたはパッチリリースに更新する必要があります。
  • 機能強化を適用するには、直近のParallelCluster 3シリーズのバージョンに更新する必要があります。

より詳細はParallelClusterのドキュメントのサポートポリシーの項目を参照して下さい。

来年のParallelCluster2のend-of-life(2022年12月31日)よりも前に、完全にサポートされているParallelCluster3へ更新することをお勧めします。ただし、以前のバージョンの既存のAMI、クックブック、およびPyPIアーティファクトは無期限に利用できます。

設定オプションの更新

ParallelClusterの設定はYAMLフォーマットになり、1つの設定ファイルがただ1つのクラスタ定義に対応するようになりました。クラスタ定義には、ParallelCluster 2.9.0で最初に導入された「multiple-queues」型の構文も使えます。これは1つのコンピュートキューのみで始める場合も同様です。この変更により、簡単にクラスタの設定を管理し可読性の高いものにできると考えています。以下に具体例を記載します(右が新しいフォーマットです)。

A picture showing the different ParallelCluster configuration files that show relationship between the INI and YAML formatted files for a multi-queue configuration

幾つかの設定は使用できなくなりました。

extra_json, additional_cfn_template, template_url, custom_chef_cookbook, custom_node_package, s3_read_resource, s3_write_resource, initial_count, compute_subnet_cidr

名前が変更になったものも幾つかあります。

  • min_queue_size is now MinCount
  • max_queue_size is now MaxCount

製品全体に渡って、私達は包括的言語(inclusive language)を組み込んでいるので、「master node」という語の替わりに「head node」を利用します(環境変数のMASTER_IPもPCLUSTER_HEAD_NODE_IPに変更されます)。

カスタムイメージ作成

AWS ParallelCluster 3は新しく合理化されたAMIの作成・管理機能として、EC2 Image Builder上に構築されたpcluster build-imageコマンドを提供します。これによりParallelClusterが提供するAMI上に階層化されたイメージビルドコンポーネント、或いはカスタムAMIを構築するパイプラインで作成された独自のイメージを利用できます。実際にlist-images、describe-image、delete-imageのコマンドによってイメージのライフサイクルを管理する事ができます。またlist-official-imagesを使えば公式のParallelClusterのイメージを確認する事も可能です。

これらの新機能で自身のコンポーネントを構成したり、共有された作成済みコンポーネントを利用したりする事ができます。ParallelClusterの異なるリリースと互換性のあるAMIを作成するために、このコンポーネントを再利用、変更、混在させる事も可能です。ISVやオープンソースコミュニティがアプリケーションをインストール済のイメージを公開する事もできます。また情報システム部が社内向けにセキュリティ設定済みのイメージを公開する事もできます。

設定によりAMIに対してパッケージの更新やOSのセキュリティアップデートを自動に適用し、最新の状態を保つ事も可能です。この一見小さな新機能ですが、クラスタを長期間稼動させているお客様にとっては多くの不要な作業と心配を取り除く一助となるでしょう。

つまるところ、ParallelClusterは新規クラスタ作成時のブートストラップの前後でインストールスクリプトを柔軟に動かす機能を提供した、という事です。設定ファイルのSchedulingとHeadNodeセクションにあるOnNodeStart、OnNodeConfiguredを利用すれば、ヘッドノードとコンピュートノードで異なるカスタムブートストラップスクリプトを指定する事もできます。

最後に、ParallelCluster内で作成されたAMIは自動的にタグ付けされ、作成されたすべてのカスタムイメージを整理するのに役立ちます。

便利になったParallelClusterのAPIとCLI

ParallelCluster 3の新しいAPIでは、より複雑なスクリプト化されたワークフローを作成可能です。Amazon API GatewayのHTTPエンドポイントを通じてクラスタをデプロイしたり管理できます。これによりデータセットが読み込まれた時に新しいクラスタを作成したり、既存のインフラストラクチャが突発的な要求を満さない場合の対応を自動化したり等、スクリプト化或いはイベント駆動のワークフローといった新しい可能性が開かれます。

ISVやシステムインテグレータやHPC管理者の観点に立つと、このAPIによってAWS ParallelClusterをHPCワークフロー中の一つのびるビルディングブロックと見做せるようになり、自家製の拡張ソリューション・サービス・カスタマイズされたフロントエンドの構築が容易になったと言えます。

ParallelClusterのコマンドラインインタフェース(CLI)であるpclusterもAPIとの互換性のために再設計され、新しくJSON形式の出力オプションも追加されました。これによりCLIの出力を正確にパースするコードが書けるようになりました。AWS CloudShellと組み合わせる事で自動化スクリプトもクラウドにプッシュできます。これらの全てを活用する事で、CLIやAPIを利用して使い慣れたビルディングブロックで簡単に実装できます。

簡素化したネットワーク設定

ParallelCluster 3ではネットワーク設定に関する自由度が高くなりました。

もし組織のポリシーでRoute 53ゾーンの作成が許可されていない時、ParallelClusterで利用するために既存のプライベートRoute 53ゾーン(ParallelCluster外で作成されたもの)を指定する事が可能です。

ParallelClusterがヘッドノード用に新しいElastic IPアドレスを作成する替わりに、既存のElastic IPアドレスを関連付けることができます。つまりクラスタを削除した後でもヘッドノードに割り当てたIPアドレスを維持できます。

またpcluster configureコマンドで、アベイラビリティゾーンの選択を促すことでサブネットの自動作成のオプションを拡張しました。これによってアベイラビリティゾーン間でより移植性の高い設定が容易になり、他のサービスやリソースを活用できるようになります。

IAM権限と命名規則

以前のバージョンのParallelClusterでは、デフォルトのインスタンプロファイルと、クラスタ用の独自のCloudFormationの命名規則を用いてクラスタを起動していました。ParallelCluster 3ではクラスタの作成とImage Builderで既存のインスタンスプロファイルを利用できます。同様にヘッドノードとコンピュートノードで異なるIAMロールを割り当て可能で、これは制限されたIAM権限を必要とする特定のジョブ(特定のSlurmパーティションなど)で有用です。

CloudFormationのスタックからparallelcluster-の接頭語を削除しました。これによってサイトの命名規則をより細かく制御できるようになります。もしあなたの組織がIAM権限の境界(IAM permission boundaries)に準拠している場合、ParallelCluster 3では、ParallelClusterによって作成された全てのロールの、アクセス権限境界として使用するためのIAMポリシーのARNを渡す事ができます。

ParallelClusterことはじめ

従来と同様に、AWS ParallelClusterは追加の費用は不要で、単にアプリケーションを動作させるのに必要となるEC2といったAWSリソースにのみ課金されます。簡単に始める方法はParallelCluster 3を好みのプラットフォームにダウンロードし、そのワークロードで試してみることです。

更に簡単にするために、AWS CloudShellやAWS Cloud9等、幾つかの方法で起動できるステップバイステップで進むハンズオンも用意してあります。ParallelClusterのシニアプロダクトマネージャーNathan Stornettaとのディスカッションの動画はHPC Tech Shortsチャンネルでご覧いただけます。AWS ParallelClusterの詳細ドキュメントはドキュメンテーションのページにあり、このドキュメントはParallelCluster 2とParallelCluster 3の両方をカバーしています。

最後に、AWS ParallelCluster 3の機能に関する更なるサポートマテリアルや情報については、このブログやHPC Tech Shorts、ワークショップのサイトで提供されるのをご覧下さい。

私達はこの発表に興奮しており、これが今後どのような発見を可能にするのかに興味があります。是非GitHubリポジトリにParallelClusterをより良くするためのフィードバックをお寄せ下さい。