HPC on AWS での Well-Architected Framework を学ぼう！（前編）

HPC on AWS における Well-Architected Framework について「前編/後編」の二部構成でお送りします。前編は HTC/HPC における、それぞれのアーキテクチャパターンについてご紹介します！

#AWS Well-Architected Framework

#HPC

#AWS

丸毛篤史

2018.07.31

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

今回は、AWS でハイパフォーマンスクラウド（HPC）を利用したい方向けに、「High-Performance Conputing Lens（AWS Well-Architected Framework）」というドキュメントをわかりやすくまとめてお伝えします。１本の記事にするにはボリュームが多かったので、今回は前編、後編の二部に分けてご紹介します。

本題の前に

そもそも AWS Well-Archtected Framework とは

AWS でシステムを構築する際に行う決定の、長所と短所を理解するのに役立つフレームワークです。クラウドでの信頼性、安全性、効率性、およびコスト効率の高いシステム設計および運用するための、アーキテクチャのベストプラクティスを学ぶことができます。AWS Well-Architected Framework は以下、5つの柱に基づいています。

運用上の優秀性
セキュリティ
信頼性
パフォーマンスの効率性
コストの最適化

用語の定義

AWS の一部の語彙は、一般的な HPC 用語とは異なる部分がありますので、説明を進める前に用語について紹介しておきます。

HPC ユーザーはサーバーを「ノード」と呼びますが、AWS は「インスタンス」と呼びます。
HPC ユーザーが一般的に「ジョブ」と言えば、AWS はそれらを「ワークロード」と呼びます。
AWS のドキュメントでは、一般に「vCPU」という用語を「スレッド」や「ハイパースレッド」と同義語として使用しています。

一般的な設計原則

従来のコンピューティング環境では、アーキテクチャ上の決定は、だいたい1回限りのイベントとして実装されますが、クラウドでは、プロジェクトが成長するにつれて成長し、絶えず最適化することを可能にします。Well-Architected Framework では、HPC を使用してクラウドの優れた設計を促進するための一般的な設計原則が提案されています。

動的アーキテクチャ：
- 安定した状態のモデルを利用する凍結された静的アーキテクチャやコスト見積もりは避けます。
- 時間の経過とともに HPC に対するニーズに合わせてアーキテクチャーはダイナミックに成長/縮小する必要があります。
- 多くの HPC の試みは、本質的にバーストであり、弾力性と従量課金のクラウドパラダイムによくマッチしています。
ワークロードに合わせた調達モデル：
- たとえば、学術研究プロジェクトなどのシミュレーションでは、緊急性はなくコストが主要な関心事である場合、EC2 スポットインスタンスがマッチします。
- 暴風雨の季節には最新の風の予測が消防士の安全を保証します。シミュレーション遅延が許されない場合、オンデマンドインスタンスを使用して、結果が確実に得られるように分析のバースト化を可能にする必要があります。
- 天気予報は毎朝、午後のテレビ放送にむけてシミュレーションを実行します。リザーブドインスタンスは、必要なキャパシティが毎日適切なタイミングで利用可能であることを見据えるために使用できます。
データから始める：
- アーキテクチャの設計を始める前に、データの出所、大きさ、移動速度、データソースの更新頻度、およびデータの必要な場所を明確に把握する必要があります。
- 同様に、パフォーマンスとコストの総合的な最適化は、コンピューティングコアと EC2 のパフォーマンスに集中するべきではありません。
自動化してアーキテクチャの実験を簡素化する：
- コードによる自動化によりインフラストラクチャを簡単に試すことができるため、パフォーマンスとコストのためにアーキテクチャを最適化できます。
共同作業を有効にする：
- HPC の作業は、しばしば世界中の多くの国にまたがる共同作業の場面があります。直接的なコラボレーション以外にも、方法や結果は幅広い HPC や科学界と共有されることがよくあります。どのツール、コード、データを誰と共有するかを事前に検討することが重要です。
- 配送方法はこの設計プロセスの一部でなければなりません。例えば、AMI、EBS スナップショット、S3 バケット、CloudFormation テンプレート、AWS Marketplace 製品などを使用してワークフローをさまざまな形で共有できます。
クラウドネイティブ設計：
- ワークロードを AWS に移行する際に、オンプレミス環境を複製する必要はありません。AWS では新しいデザインパターンと疎結合のソリューションを使用して、HPC ワークロードを新しい方法で実行することを可能にします。ユーザーは、AWS Batchや、サーバーレスな AWS Lambda などを使用して、基礎となるコンピューティングを管理することができます。
- 従来のクラスタスケジューラを使用しないことを検討してください。クラウドの中では、クラスタはもはや永続性を必要としません。クラスタのデプロイを自動化した後は、クラスタを1つ破棄し、必要に応じて異なるパラメータで新しいクラスタを起動できます。
実際のワークロードをテストする：
- クラウドでの本番ワークロードのパフォーマンスを知る唯一の方法は、クラウド上でテストすることです。小さなベンチマークセットや "おもちゃの問題"を持つアプリケーションのテストでは、価値はほとんどありません。実際に使用している計算時間とストレージ時間を支払うだけなので、AWS で現実的な PoC を実行することは可能です。
結果を得るまでの時間とコストのバランスをとる：
- 最も重要なパラメータ、すなわち「時間」「コスト」のパフォーマンスを分析します。
- コストの最適化は、時間に敏感ではないワークロードに使用する必要があり、スポットインスタンスがしばしば最も安価な方法になります。
- 緊急のワークロードでは、コストの最適化をパフォーマンスのために取引することができ、インスタンスタイプ、調達モデル、およびクラスタサイズは、実行時間が最も短いものを選択する必要があります。
- プラットフォーム間を比較する場合は、プロビジョニングリソース、ステージングデータ、ジョブキューに費やされた時間などの非コンピューティングの側面も含め、ソリューション開発期間全体を考慮に入れることが重要です。

シナリオ

HPC は、並列プロセス間の相互作用の程度にもとづいて、一般的に2つのカテゴリに分類されます。

疎結合な HPC
- 複数プロセスまたは並列プロセスがシミュレーション全体で相互作用しないケース。これらはハイスループットコンピューティング（HTC）と呼ばれる。
密結合な HPC
- 並列プロセスが同時に実行され、シミュレーションの各反復またはステップで互いに情報を定期的に交換するケース。単にハイパフォーマンスコンピューティング（HPC）と呼ばれる。

HTC（High-throughput computing）

HTCでは、多数の小さなジョブの処理を必要とします。各小規模ジョブは「イテレーション（反復）」と呼ばれます。シミュレーション全体の完了には、しばしば数百万から数百万回のイテレーションが必要で、通常、シミュレーション全体の完了までの間に、任意の順序で、任意の速度で行われます。

一般的に、HTC の反復処理はノードで実行され、そのノード内で並列化のために共有メモリ並列化（SMP）を使用して１つのプロセス、またはマルチプロセッサ・ノード全体を消費します。

HTC アプリケーションは、モンテカルロシミュレーション、画像処理、ゲノミクス解析など多くの分野で使用されています。また、HTC では、1つのノードまたはジョブが失われても、計算全体が遅れることはありません。失われたワークは、後で拾うことができます。

考慮事項

HTC ワークロードに適したアーキテクチャには、次の考慮事項があります。

ネットワーク：
- HTC の並列プロセスは相互作用しないため、ネットワーク帯域幅と遅延の影響を受けません。したがって、ネットワーク要件は最小限に抑えられます。
- 復元力の弱さをもたらすため、プレイスメントグループは使用しません。
ストレージ：
- 一般的に、高速なストレージは HTC アプリケーションでは必要ありません。場合によっては、ノード間で共有ファイルシステム（EFSやNFSなど）を使用すると便利です。
コンピューティング：
- 各アプリケーションは異なりますが、一般的にアプリケーションのメモリ対コンピューティングの比率によって、基になる EC2 インスタンスの種類を決まります。
- 一部アプリケーションは、EC2 インスタンス上の GPU または FPGA アクセラレータを利用する用に最適化されています。
デプロイメント：
- 時には何百万ものインスタンスで実行されることがよくあります。疎結合されているため、性能を犠牲にすることなく、AZ 全体にシミュレーションを展開できます。
- HTC シミュレーションは、SQS、Auto Scaling、Lambda のようなセルフマネージドソリューション、または、AWS Batch のようなマネージドソリューションでデプロイできます。

次に、HTC アプリケーションのデザインパターンの出発点として、考慮すべき４つのアーキテクチャ例についてご紹介していきます。

バッチベースのアーキテクチャ

AWS Batch はリソースのプロビジョニングやスケジューラの管理をせずに、大規模なコンピューティングワークロードをクラウド上で実行できる、フルマネージドサービスです。EC2 やスポットインスタンスなどの AWS コンピューティングサービスや機能の全範囲にわたるバッチ処理ワークロードを計画、スケジュール、を行います。AWS Batchでは、バッチジョブのコードをパッケージ化し、依存関係を指定し、AWS管理コンソール、CLI、またはSDKを使用してバッチジョブを送信します。実行パラメータとジョブの依存関係を指定したり、一般的なバッチ・コンピューティング・ワークフロー・エンジンや言語（Pegasus WMS、Luigi、AWS Step Functionsなど）と統合することができます。

ワークフローのステップ：

ユーザーはジョブコンテナを作成し、EC2 コンテナレジストリ（ECR）または別のコンテナレジストリ（DockerHub など）にコンテナをアップロードし、AWS Batch にジョブ定義を送信します。
ユーザーが AWS Batch のジョブキューにジョブを送信します。
AWS Batch は、コンテナをコンテナレジストリから引き出します。
AWS Batch はキュー内のジョブを処理します。
各ジョブの結果はS3バケットに格納されます。

キューベースのアーキテクチャ

Amazon SQS は、フルマネージドなメッセージキューイングサービスであり、前処理ステップを計算ステップと後処理ステップから簡単に切り離すことができます。個々の機能を実行する個々のコンポーネントからアプリケーションを構築することで、スケーラビリティと信頼性が向上します。デカップリングコンポーネントは、最新のアプリケーションを設計するためのベストプラクティスです。SQS は、しばしばクラウドネイティブの HTC ソリューションの中核に位置しています。

SQS は、ユーザーが AWS コンポーネントと直接対話することなく、デスクトップからアプリケーションをデプロイするために、AWS CLI または AWS SDK スクリプトソリューションと結合されることがよくあります。

ワークフローのステップ：

複数のユーザーが、SQS send message コマンドを使用して AWS CLI でジョブを送信します。
ジョブは SQS のメッセージとしてキューに入れられます。
EC2 スポットインスタンスがキューを Polling し、処理ジョブを開始します。
EC2 インスタンスがソースデータを Pull し、結果データを S3 バケットに格納します。
SQS は、キュー内のメッセージ（ジョブ）の数に基づいてメトリックを発行します。
CloudWatch アラームは、キューが指定された長さよりも長い場合、Auto Scaling に通知するように設定されています。 Auto Scaling で EC2 インスタンスの数が増えます。

従来のクラスタ環境

多くの HTC ユーザーは、これまでに取り組んできた他の HTC 環境でクラウドジャーニーを始める、あるいはそれに似た環境を好みます。この環境には、HTC シミュレーションの実行またはイテレーションを開始するためのスケジューラを備えたマスターノードが必要なことがよくあります。

HTC クラスタプロビジョニングの一般的なアプローチは、クラスタテンプレートと、ユーザーの特定のタスクのカスタマイズを組み合わせたものに基づいています。アーキテクチャーの複雑な記述はテンプレート内に隠されていますが、一般的なカスタマイズオプションでは、アプリケーションのインストールやデータの同期化など、インスタンスのタイプ、スケジューラー、またはブートストラップのアクションを選択できます。このテンプレートは、従来の HPC クラスタの「ルックアンドフィール」を HTC 環境に提供するために AWS CloudFormation を使用して構築および実行できますが、スケーラビリティの利点が追加されています。マスターノードは、スケジューラ、共有ファイルシステム、および実行環境を維持します。一方、Auto Scaling メカニズムにより、ジョブがジョブ・キューに送出されるときに、追加のノードがスピンアップすることが可能になります。ノードがアイドル状態になると、ノードは自動的に再びシャットダウンされます。

ワークフローのステップ：

ユーザーが AWS CLI を使用してクラスタを開始します。
AWS CloudFormation は、クラスタテンプレートファイルに記述されているようにクラスタアーキテクチャを実行します。クラスタファイルでは、ユーザがいくつかのカスタム設定（たとえば、設定ファイルの編集や Web インターフェイスの使用など）に貢献しています。
AWS CloudFormation は、カスタマイズされた HPC ソフトウェア/アプリケーションを使用して作成されたスナップショットからインフラストラクチャを展開し、クラスタインスタンスは NFS エクスポートを介してアクセスできます。
ユーザがマスターノードにログインし、スケジューラ（SGE など）にジョブを送信します。
マスターノードは、ジョブキューのサイズに基づいて CloudWatch にメトリックを送信します。
ジョブのキューサイズがしきい値を超えた場合、CloudWatch が Auto Scaling イベントをトリガして計算ノードの数を増やします。
スケジュールされたジョブは、コンピューティングによって処理されます。
ソースデータと結果データは S3 バケットに格納されます。
オプションの EBS スナップショットを作成して、EBS ボリュームへの変更を保存できます。

サーバーレス

HTC クラウドジャーニーは、フルサーバーレスな環境をもたらします。つまり、アプリケーションに集中し、サーバープロビジョニングを管理対象サービスに任せることができます。Lambda を使用すると、サーバーのプロビジョニングや管理を行うことなく短期間でコードを実行できます。コードが実行されていないときは無料です。

スケーラビリティは、サーバレス Lambda アプローチの第2の利点です。各ワーカーのサイズ（例えば、あるメモリを持つコンピューティングコア）は控えめであるかもしれませんが、アーキテクチャーは何千もの Lambda ワーカーを生み出すことで、大きなコンピューティング能力を獲得することができます。達成可能な最大スケールの問題だけでなく、スケーリングのスピードもそうです。EC2インスタンスなどの仮想マシンを使用している場合でも、スケーリングには数分の時間がかかりますが、サーバーレスの Lambda 関数は数秒でスケールされます。言い換えれば、Lambdaは、予期せぬ要求に即座に応答できる　HPC インフラストラクチャを可能にし、リソースを事前に無駄にプロビジョニングする必要はありません。

ワークフローのステップ：

ユーザーは、AWS CLI を使用してファイルを S3 バケットにアップロードします。
入力ファイルは、入力プレフィックス（たとえば、imput/）で保存されます。
Lambda 関数は、S3 イベントによって自動的にトリガされ、着信データを処理します。
出力ファイルは、出力プレフィックス（たとえば、output/）を付けて S3 バケットに保存されます。

HPC（High-performance computing）

HTC とは異なり、HPC プロセスは「密結合」されています。つまり、情報はシミュレーションの各イテレーションまたはステップでプロセス間で定期的に交換されます。通常、シミュレーションは、各プロセスが1つのコアに固定された均質なクラスタ上で実行されます。一般的に、コアまたはプロセッサの合計数は、数十から数百、数千、時には数十万のコアに及びます。1つのノードの障害は、通常、計算全体の失敗につながります。完全な障害のリスクを軽減するために、シミュレーション中にチェックポイントが定期的に発生し、ケースの再起動が可能になります。

通常、プロセス間通信のためのメッセージ処理インターフェイス（MPI）に依存します。共有メモリ OpenMP による並列処理は、MPI と併用することができます。密結合された HPC ワークロードの例には、計算流体力学、気象予測、および貯留層シミュレーションが含まれます。

考慮事項

HPC ワークロードに適したアーキテクチャには、次の考慮事項があります。

ネットワーク：
- ネットワーク要件は、一般的に非常に厳しいです。通常、ノード間の通信が遅いと、計算全体の速度が低下します。
- 一貫したネットワーキングパフォーマンスを得るには、最大のインスタンスサイズ、拡張ネットワーキング、およびプレイスメントグループが必要です。
- 密結合されたアプリケーションのサイズは様々です。多数のプロセスまたはコアに分散した大きな問題サイズは、通常はうまく並列化されます。総計算量がより少ない小規模なケースは、ネットワークへの需要が最も大きい。
ストレージ：
- HTC ワークロードと同様にストレージ要件は、データセットのサイズとデータの読み書きに必要なパフォーマンス要件によって異なります。
- 共有ファイルシステムは、EBS、EFS、または高性能ファイルシステムを使用したインスタンスの NFS エクスポートがしばしば使用されます。
- 高性能ファイルシステムは、AWS Marketplace のサードパーティから入手することも、ユーザーがインストールすることもできます。
コンピューティング：
- EC2インスタンスは、さまざまな構成で提供され、コアとメモリの比率が変化します。
- 並列アプリケーションの場合、メモリを必要とする並列シミュレーションをより多くのコンピューティングノードに分散して、コアごとのメモリ要件を軽減し、最高のパフォーマンスを発揮するインスタンスタイプをターゲットにすると便利です。
- 密結合されたアプリケーションでは、類似のコンピューティングノードから構築された同種のクラスタが必要です。
- 最大のインスタンスサイズを目標とすることにより、ノード間の通信時に最大のネットワークパフォーマンスを提供しながら、ノード間のネットワーク遅延を最小限に抑えます。
デプロイメント：
- さまざまなデプロイメントオプションが利用できます。
- 「伝統的な」クラスタ環境でのシミュレーションを開始するのと同様に、エンドツーエンドの自動化も実現できます。
- クラウドのスケーラビリティにより、多数の大規模なマルチプロセスケースを一度に起動できるため、オンプレミスクラスタの様に、待ち行列を待つ必要はありません。

次に、HPC アプリケーションのデザインパターンの出発点として、考慮すべき3つのアーキテクチャ例についてご紹介していきます。

永続クラスタ

永続クラスタは、従来のオンプレミスのクラスタまたはスーパーコンピューターの操作を模倣しています。クラスタには、複数のユーザーがジョブをサブミットできるようにするスケジューラを備えたマスターインスタンスが含まれています。コンピューティングノードフリートは、固定サイズでも、Auto Scaling グループにも接続して、投入されたジョブの数に応じてインスタンスを増減することができます。クラスタが「プレイスメントグループ」「同種のインスタンスタイプ」を必要とする点を除いて、HTC クラスタのクラスタとほぼ同じです。スケジューラおよび共有ボリュームに加えて、MPI などの他のライブラリを計算ノードに追加することができます。

ワークフローのステップ：

AWS CloudFormation は、クラスタテンプレートファイルに記述されているようにクラスタアーキテクチャを実行します。クラスタファイルでは、ユーザがいくつかのカスタム設定（たとえば、設定ファイルの編集や Web インターフェイスの使用など）に貢献しています。プレイススメントグループが含まれています。
カスタマイズされた HPC ソフトウェア/アプリケーションで作成されたスナップショットは、NFS マウントされる EBS ボリュームの基礎として使用されます。
ユーザがマスターノードにログインし、スケジューラ（SGE など）にジョブを送信します。
マスターノードは、ジョブキューのサイズに基づいて CloudWatch にメトリックを送信します。
ジョブキューのサイズがしきい値を超えた場合、CloudWatch が自動スケーリングイベントをトリガして計算ノードの数を増やします。
スケジュールされたジョブは、インスタンスによって処理されます。結果は共有ボリュームに保存され、Amazon Glacier または S3 に長期保存用にコピーできます。

一時クラスタ

密結合された HPC へのクラウドネイティブアプローチは、それぞれの実行を独自のクラスタに結び付けます。たとえば、bash スクリプトを AWS CLI と組み合わせるか、AWS SDK の Python スクリプトでエンドツーエンドのケース自動化を実現します。各ケースについて、リソースのプロビジョニングと起動、データノードへの配置、ジョブの複数ノードへの実行、ケース出力の自動取得、または S3 への送信が行われます。ジョブが完了すると、インフラストラクチャは終了します。このように設計されたクラスタは、インフラストラクチャをコードとして扱い、インフラストラクチャの変更を完全にバージョン管理できます。マスターノードとジョブスケジューラはあまり重要ではなく、一時クラスタではまったく使用されません。従来のクラウドクラスタの主流である Auto Scaler は、クラスタが一度立ち上がってから終了するため、使用されません。

ワークフローのステップ：

ユーザーはシェルスクリプトを使用して AWS CLI 呼び出し、各ジョブまたはワークロードをデプロイします。
各ワークロードは、独自のカスタマイズされたクラスタ上で起動されます。
出力データは S3 にコピーされるか、ユーザーのデスクトップに安全にコピーされます。
完了すると、一時クラスタは完全に終了します。

HPC マイクロサービス

マイクロサービスアーキテクチャは、API 呼び出しに基づいて一時的な計算能力をプロビジョニングする一時クラスタのバリエーションです。目標は、HPC 計算をユーザまたはビジネスアプリケーション用の Web ポータルなどの別のソフトウェアエージェントによって開始または使用される API として提供することです。HPC は、全体的なワークフローまたはビジネスプロセスの一部として統合することができます。このアーキテクチャアプローチは、HPC 計算をサービスとして提供し、モジュラーアプローチを実施します。HPC サービスの所有者は、定義された API を介して統一されたインターフェイスを維持しながら、サービスを変更または強化することができるように、継続的デリバリーに適しています。一時クラスタと同様に、このアプローチは従来の HPC アーキテクチャとは異なり、マスタノードとスケジューラの使用を必要としません。AWS を使用すると、API Gateway や S3 、SQS などの API を使用して、API インターフェイスをカスタム定義することができます。