# シナリオ
<a name="scenarios"></a>

 HPC のケースでの問題は通常、並列処理技術を必要とする複雑なコンピューティングにあります。Well-Architected HPC インフラストラクチャは、計算を行う間、パフォーマンスを維持し、計算を支援できます。HPC ワークロードは、ゲノミクス、計算化学、金融リスクモデリング、コンピューター支援エンジニアリング、天気予報、地震イメージングなどの従来のアプリケーションに加え、機械学習、ディープラーニング、自動運転などの新しいアプリケーションにも及びます。さらに、これらの計算をサポートする従来のグリッドまたは HPC クラスターは、特定のワークロード用に最適化した一部のクラスター属性を持つアーキテクチャに著しく類似しています。AWS では、ネットワーク、ストレージタイプ、コンピューティング (インスタンス) タイプ、さらにデプロイ方法も戦略的に選択し、特定のワークロードのパフォーマンス、コスト、使いやすさを最適化できます。 

 HPC は、同時に実行している並列処理間における相互作用の程度に基づいて、疎結合ワークロードと密結合ワークロードの 2 つのカテゴリに分類できます。疎結合の HPC はシミュレーション全体の過程で、複数処理または並列処理が互いに強く作用しません。密結合 HPC では並列処理を同時に実行し、シミュレーションの各反復またはステップで相互に定期的に情報を交換します。 

 疎結合のワークロードでは、計算またはシミュレーション全体を完了するには、数百から数百万の並列処理を必要とすることがよくあります。これらのプロセスは、シミュレーション中に任意の順序と速度で発生します。このため、疎結合シミュレーションに必要なコンピューティングインフラストラクチャの柔軟性を提供できます。 

 密結合ワークロードには、シミュレーションの各反復で定期的に情報を交換するプロセスがあります。通常、これらの密結合シミュレーションは同種のクラスターで実行されます。コアまたはプロセッサの合計数は、インフラストラクチャで許可される場合、数十から数千、場合によっては数十万の範囲になります。シミュレーション中での処理の相互作用により、コンピューティングノードやネットワークインフラストラクチャなどのインフラストラクチャに余分な負荷がかかります。 

 さまざまな疎結合および密結合アプリケーションを実行するために使用するインフラストラクチャは、ノード間処理の相互作用の能力によって区別されます。両方のシナリオに当てはまる基本的な側面がある一方、それぞれのシナリオに特有な設計上の考慮事項があります。AWS で HPC インフラストラクチャを選択する際は、両方のシナリオについて次の基本事項を考慮してください。 
+  **ネットワーク**: ネットワーク要件は、通信トラフィックが最も少ない疎結合アプリケーションのような要件の低いケースから、帯域幅が広くレイテンシーの低い高性能ネットワークを必要とする密結合および超並列アプリケーションにいたるまでさまざまです。 
+  **ストレージ**: HPC 計算では、データを独自の方法で使用、作成、移動します。ストレージインフラストラクチャは、計算の各ステップでこれらの要件をサポートする必要があります。入力データは起動時に保存されることがほとんどで、実行中により多くのデータが作成および保存され、実行が完了すると出力データはリザーバがある場所に移動します。考慮すべき要素には、データサイズ、メディアタイプ、転送速度、共有アクセス、ストレージプロパティ (耐久性や可用性など) が含まれます。ノード間で共有ファイルシステムを使用すると便利です。例えば、Amazon Elastic File System (EFS) などのネットワークファイルシステム (NFS) 共有、または Amazon FSx for Lustre などの Lustre ファイルシステムです。 
+  **コンピューティング**: Amazon EC2 インスタンスタイプは HPC ワークロードで利用可能なハードウェア機能を定義します。ハードウェア機能には、プロセッサタイプ、コア周波数、プロセッサ機能 (ベクトル拡張など)、メモリとコアの比率、ネットワークパフォーマンスが含まれます。AWS では、インスタンスを HPC ノードと同じものと見なします。これらの用語は、本ホワイトペーパーでも同じ意味として使用します。 
  +  AWS は、基盤となる EC2 インスタンスタイプを選択することなくコンピューティングにアクセスする機能を備えたマネージドサービスを提供します。AWS Lambda および AWS Fargate は、基盤となるサーバーをプロビジョニングおよび管理することなくワークロードを実行できるようにするコンピューティングサービスです。
+  **デプロイ**: AWS には、HPC ワークロードをデプロイするための多くのオプションがあります。インスタンスは、AWS マネジメントコンソール から手動で起動できます。自動デプロイでは、いろんなプログラミング言語でエンドツーエンドのソリューションをコーディングできるさまざまなソフトウェア開発キット (SDK) を利用できます。bash シェルスクリプトと AWS コマンドラインインターフェイス (AWS CLI) を組み合わせたものは、人気のある HPC デプロイのオプションです。
  +  AWS CloudFormation テンプレートを使用すると、コードとして記述されたアプリケーションに合わせた HPC クラスターを指定できるため、数分で起動できます。AWS ParallelCluster は、CloudFormation を介したクラスターの起動を、従来のクラスターエクスペリエンス用に既にインストールされているソフトウェア (コンパイラやスケジューラなど) と調整するオープンソースソフトウェアです。
  +  AWS は、Amazon Elastic Container Service (Amazon ECS)、Amazon Elastic Kubernetes Service (Amazon EKS)、AWS Fargate、AWS Batch などのコンテナベースのワークロードにマネージドデプロイメントサービスを提供します。
  +  AWS Marketplace や AWS パートナーネットワーク (APN) より、追加のサードパーティー製ソフトウェアオプションも利用できます。

 クラウドコンピューティングにより、インフラストラクチャコンポーネントとアーキテクチャ設計を簡単に実験できます。AWS では、インスタンスタイプ、EBS ボリュームタイプ、デプロイ方法などをテストして、最小のコストで最高のパフォーマンスを見つけることを強くお勧めします。 

# 疎結合のシナリオ
<a name="loosely-coupled-scenarios"></a>

 疎結合ワークロードは、小さなジョブの処理を多数伴います。通常は小さなジョブを 1 つのノードで実行し、1 つのプロセス、またはそのノード内の並列化のための共有メモリ並列化 (SMP) を持つ複数のプロセスを使用します。 

 並列処理またはシミュレーションでの反復を後処理して、シミュレーションから 1 つのソリューションまたは検出を作成します。疎結合アプリケーションは、モンテカルロシミュレーション、画像処理、ゲノミクス解析、電子設計自動化 (EDA) など、多くの分野で使用されています。 

 疎結合のワークロードで 1 つのノードまたはジョブが失われても、通常は計算全体が遅れることはありません。失われた作業は後で取得するか、完全に省略することができます。計算に関連するノードは、仕様と出力が異なる場合があります。 

 疎結合ワークロードに適したアーキテクチャでは、次のことを考慮してください。 
+  **ネットワーク**: 並列プロセスが相互に作用することは通常ないため、ワークロードの実行可能性またはパフォーマンスは、インスタンス間のネットワークの帯域幅や待機時間の影響を受けません。したがって、クラスター化されたプレースメントグループはパフォーマンスを向上させることなく回復性を弱めるため、このシナリオでは必要とされません。 
+  **ストレージ**: 疎結合ワークロードはストレージ要件が異なり、データセットのサイズと希望するデータ転送とデータの読み書きパフォーマンスによって変わります。 
+  **コンピューティング**: それぞれのアプリケーションにより異なりますが、全般的にアプリケーションにおけるコンピューティングに対するメモリの比率は、元になっている EC2 インスタンスタイプによります。いくつかのアプリケーションは、EC2 インスタンスの画像処理用演算プロセッサ (GPU) や フィールドプログラマブルゲートアレイ (FPGA) のアクセラレーターを活用するように最適化されています。 
+  **デプロイ**: 疎結合シミュレーションは、しばしば多くの (時には数百万の) コンピューティングコアで実行します。コンピューティングコアは、パフォーマンスを犠牲にすることなく、アベイラビリティゾーンをまたいで実行することも可能です。疎結合シミュレーションは、AWS Batch や AWS ParallelCluster などのエンドツーエンドのサービスとソリューションを使用して、または Amazon Simple Queue Service (Amazon SQS)、Auto Scaling、AWS Lambda、AWS Step Functions などの AWS のサービスの組み合わせを介して、デプロイできます。 

# 密結合のシナリオ
<a name="tightly-coupled-scenarios"></a>

 密結合アプリケーションは、相互に依存して計算を実行する並列プロセスで構成されています。疎結合コンピュテーションとは異なり、密結合シミュレーションでは、すべてのプロセスが連携して反復するので、お互い通信が必要です。1回の反復は、シミュレーション全体の 1 ステップとして定義されています。密結合計算は、数百から数百万回を超える反復を、数十から数千のプロセスまたはコアに依存しています。通常、1 つのノードで計算が失敗すると、全体としての計算の失敗につながります。完全にエラーとなるリスクを避けるために、コンピュテーションの間にアプリケーションレベルでのチェックポイントを定期的に作成し、確実な状態からシミュレーションを再開できるようにします。 

 これらのシミュレーションは、プロセス間通信にメッセージパッシングインターフェイス (MPI) を使用しています。OpenMP 経由での Shared Memory Parallelism は、MPI とともに使われます。密結合 HPC ワークロードの例としては、計算流体力学、気象予測、油層シミュレーションなどがあります。 

 密結合 HPC ワークロードに適合したアーキテクチャでは、次のことを考慮します。 
+  **ネットワーク**: 密結合計算に必要なネットワーク要件があります。ノード間の通信が遅いと、結果として全体の計算が遅くなります。ネットワークのパフォーマンスを一定に保つには、最大のインスタンスサイズ、強化されたネットワーク、そしてクラスターのグループ配置が必要です。これらのテクニックは、シミュレーションの実行時間を最小化し、全体的なコストを軽減します。密結合アプリケーションのサイズはさまざまです。多数のプロセスまたはコアにまたがる大きな処理サイズの場合、通常はうまく並列化します。全体的な計算要件が低い小規模なケースでは、ネットワークに対する要求が最も大きくなります。特定の Amazon EC2 インスタンスでは、Elastic Fabric Adapter (EFA) をネットワークインターフェイスとして使用することで、AWS の規模で高レベルのノード間通信が必要なアプリケーションを実行できます。EFA のカスタムビルドしたオペレーティングシステムのバイパスハードウェアインターフェイスにより、インスタンス間通信のパフォーマンスが向上します。これは密結合アプリケーションをスケールするときに重要です。 
+  **ストレージ**: 密結合ワークロードのストレージ要件が様々ありますが、データセットのサイズや、データ転送、読み込み、書き込みに必要なパフォーマンスによって決定します。一時的なデータストレージや、スクラッチスペースには特別な配慮が必要です。 
+  **コンピューティング**: EC2 インスタンスは、変更可能なコアとメモリレシオによる様々な設定で提供されています。並列アプリケーションの場合、メモリ集約型の並列シミュレーションをより多くのコンピューティングノードに分散して、コアあたりのメモリ要件を減らし、最高のパフォーマンスを発揮するインスタンスタイプをターゲットにします。密結合アプリケーションでは、似たようなコンピュートノードから構成される同種のクラスターが必要です。最大のインスタンスサイズをターゲットにすると、ノード間のネットワークレイテンシーが最小限に抑えられ、ノード間の通信では最高のネットワークパフォーマンスを提供できます。 
+  **デプロイ**: 様々なデプロイのオプションが利用できます。「従来の」クラスター環境でシミュレーターを起動するような、エンドツーエンドの自動化が実現可能です。クラウドのスケーラビリティによって、数百もの大規模なマルチプロセスを一度に起動することができます。キューで待機する必要はありません。密結合シミュレーションは、AWS Batch や AWS ParallelCluster などのエンドツーエンドのソリューションとともにデプロイできます。また、CloudFormation や EC2 Fleet などの、AWS のサービスに基づいたソリューションを通してデプロイすることもできます。 

# リファレンスアーキテクチャ
<a name="reference-architectures"></a>

 多くのアーキテクチャは疎結合ワークロードと密結合ワークロードのどちらにも適用されますが、シナリオによって若干の修正が必要です。従来のオンプレミスのクラスターでは、クラスターインフラストラクチャに万能のアプローチが強制されました。しかし、クラウドでは幅広い可能性を提供でき、パフォーマンスとコストの最適化が可能です。スケジューラとログインノードによる従来のクラスターエクスペリエンスから、クラウドネイティブなソリューションによる、コスト効率化の強みを備えたクラウドネイティブなアーキテクチャまで、クラウドでは幅広い設定ができます。次に 5 つのリファレンスアーキテクチャを挙げます。

**Topics**
+ [従来のクラスター環境](traditional-cluster-environment.md)
+ [バッチ処理ベースのアーキテクチャ](batch-based-architecture.md)
+ [キューベースのアーキテクチャ](queue-based-architecture.md)
+ [ハイブリッドなデプロイ](hybrid-deployment.md)
+ [サーバーレス](serverless.md)

# 従来のクラスター環境
<a name="traditional-cluster-environment"></a>

 多くのユーザーが、従来の HPC 環境に似た環境でクラウドジャーニーを開始します。このような環境は多くの場合、ジョブを起動するためにログインノードを必要とします。 

 従来のクラスタープロビジョニングへの一般的なアプローチは、ユーザーの特定のタスクのカスタマイズと組み合わせたコンピューティングクラスターの AWS CloudFormation テンプレートに基づいています。[AWS ParallelCluster](https://aws.amazon.com/tools/) は、AWS CloudFormation に基づくエンドツーエンドのクラスタープロビジョニング機能の例です。アーキテクチャの複雑な説明はテンプレート内に隠匿されてはいますが、一般的な設定オプションにより、ユーザーはインスタンスタイプ、スケジューラ、またはアプリケーションのインストールやデータの同期などのブートストラップアクションを選択できます。テンプレートは、従来の HPC クラスターの「ルックアンドフィール」を備えた HPC 環境を提供するように構築および実行できますが、さらにスケーラビリティのメリットも追加されています。ログインノードは、スケジューラ、共有ファイルシステム、および実行環境を管理します。その一方でジョブがキューに送信されると、自動スケーリング機能により、追加のインスタンスが自動でスピンアップされます。インスタンスがアイドルになると、それらは自動的に終了します。 

 クラスターは永続的な設定でデプロイするか、一時リソースとして扱うことができます。永続的なクラスターは、ログインインスタンスと、固定サイズのコンピューティングフリート、または送信されたジョブの数に応じてコンピューティングフリートを増減する Auto Scaling グループに関連付けられたコンピューティングフリートで、デプロイされます。永続的クラスターでは、常に何らかのインフラストラクチャが実行されています。もしくは、クラスターは、各ワークロードが独自のクラスターで実行される一時的なものとして扱うことができます。一時的なクラスターは、自動化により有効化されます。例えば、bash スクリプトを AWS CLI と組み合わせたり、Python スクリプトと AWS SDK を組み合わせて、エンドツーエンドのケース自動化を実現します。それぞれのケースで、リソースのプロビジョニングと起動が行われ、ノードにデータが配置され、複数のノードでジョブが実行され、ケースの出力は自動的に取得されるか、Amazon S3 に自動的に送信されます。ジョブが完了すると、インフラストラクチャは終了します。これらのクラスターはインフラストラクチャをコードとして扱い、コストを最適化します。また、インフラストラクチャの変更を完全にバージョン管理できます。 

 従来のクラスターのアーキテクチャを、疎結合と密結合ワークロードに使用できます。最適なパフォーマンスを得るために、密結合ワークロードでは、同種のインスタンスタイプを持つクラスター化された配置グループでコンピューティングフリートを使用する必要があります。 

 **リファレンスアーキテクチャ** 

![\[AWS ParallelClusterでデプロイされた従来のクラスター\]](http://docs.aws.amazon.com/ja_jp/wellarchitected/latest/high-performance-computing-lens/images/image2.png)


*図 1: AWS ParallelCluster でデプロイされた従来のクラスター*

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

1.  ユーザーは、AWS ParallelCluster CLI および設定ファイルの仕様を使用して、クラスターの作成を開始します。 

1.  AWS CloudFormation は、クラスターのテンプレートファイルの記述に従い、クラスターアーキテクチャを構築します。クラスターテンプレートファイルには、ユーザーによるカスタムの設定 (例えば、設定ファイルの編集やウェブインターフェイスの使用など) が提供されています。 

1.  AWS CloudFormation が、カスタマイズされた HPC ソフトウェアやアプリケーションで作成された EBS スナップショットから、インフラストラクチャをデプロイします。HPC ソフトウェアやアプリケーションには、NFS エクスポートを通してクラスターインスタンスがアクセスできます。 

1.  ユーザーがログインインスタンスにログインし、スケジューラ (SGE や Slurm など) にジョブを送信します。 

1.  ログインインスタンスは、ジョブのキューのサイズに基づき、CloudWatch にメトリクスを発行します。 

1.  CloudWatch は、ジョブのキューのサイズがしきい値を超えている場合には、コンピューティングインスタンスの数を増やすために Auto Scaling イベントをトリガーします。 

1.  コンピューティングフリートにより、スケジュールされたジョブが処理されます。 

1.  [オプション] ユーザーがすべてのリソースのクラスター削除と終了を開始します。 

# バッチ処理ベースのアーキテクチャ
<a name="batch-based-architecture"></a>

 [AWS Batch](https://aws.amazon.com/batch/) はフルマネージドサービスであり、リソースをプロビジョニングしたりスケジューラを管理したりすることなく、クラウドで大規模なコンピューティングワークロードを実行できます。AWS Batchを使用することで、デベロッパー、科学者、およびエンジニアが AWS で数十万のバッチコンピューティングジョブを簡単かつ効率的に実行できるようになります。AWS Batch は、送信されたバッチジョブのボリュームと指定されたリソース要件に基づいて、最適な量とタイプのコンピューティングリソース (CPU やメモリに最適化されたインスタンスなど) を動的にプロビジョニングします。AWS Batch では、Amazon EC2 やスポットインスタンスなどの幅広い AWS コンピューティングサービスや機能、およびバッチコンピューティングワークロードを計画、スケジュール、実行します。ジョブの実行に必要なバッチコンピューティングのソフトウェアやサーバークラスターをインストールしたり、管理したりする必要がないため、結果の分析や新しい洞察を得ることに集中できます。 

 AWS Batch でアプリケーションをコンテナにパッケージし、ジョブの依存性を指定し、AWS マネジメントコンソール や CLI、SDK を使ってバッチジョブを送信します。実行パラメータとジョブの依存関係を指定し、一般的なバッチコンピューティングワークフローエンジンと言語 (例えば、Pegasus WMS、Luigi、AWS Step Functions など) と統合できます。AWS Batch は、デフォルトのジョブキューと計算環境の定義を提供し、すぐに開始できるようにします。 

 AWS Batch ベースのアーキテクチャは、疎結合と密結合、両方のワークロードに使用できます。密結合ワークロードでは、AWS Batch でマルチノードの並列ジョブを使用する必要があります。 

 **リファレンスアーキテクチャ** 

![\[AWS クラウド architecture showing user interaction with VPC, AWS Batch, and S3 through job container image and EC2 container registry.\]](http://docs.aws.amazon.com/ja_jp/wellarchitected/latest/high-performance-computing-lens/images/image3.png)


*図 2: AWS Batch アーキテクチャの例*

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

1.  ユーザーがジョブのコンテナを作成し、コンテナを Amazon EC2 Container Registry (Amazon ECR) または他のコンテナレジストリ (例えば DockerHub) にアップロードします。また、AWS Batch にジョブの定義を作成します。 

1.  ユーザーが AWS Batch のジョブキューにジョブを送信します。 

1.  AWS Batch がコンテナレジストリからイメージを取得し、キューにあるジョブを処理します。 

1.  各ジョブからの入力データと出力データは、S3 バケットに保存されます。 

# キューベースのアーキテクチャ
<a name="queue-based-architecture"></a>

 Amazon SQS はフルマネージド型の[メッセージキューのサービス](https://aws.amazon.com/message-queue)です。これにより、コンピューティングのステップおよび後処理のステップからの、処理前ステップの疎結合化が簡単になります。独自の機能を実行する個別のコンポーネントからアプリケーションを構築することで、スケーラビリティと信頼性が向上します。コンポーネントの疎結合化は、最新のアプリケーションを設計するためのベストプラクティスです。Amazon SQS は多くの場合、クラウドネイティブの疎結合ソリューションの中心にあります。 

 Amazon SQS はしばしば、AWS CLI や AWS SDK のスクリプトによるソリューションと共に編成され、ユーザーはデスクトップから AWS のコンポーネントと直接やりとりすることなしにアプリケーションをデプロイできます。AWS Batch のようなサービスマネージドなデプロイに対して、SQS や EC2 によるキューベースのアーキテクチャでは、セルフマネージドのコンピューティングインフラストラクチャを必要とします。 

 キューベースのアーキテクチャは疎結合ワークロードには最良ですが、密結合ワークロードに適用すると、たちまち複雑になってしまうことがあります。 

 **リファレンスアーキテクチャ** 

![\[AWS クラウド architecture showing user interaction with SDK, SQS, EC2 instances, and S3 storage within a VPC.\]](http://docs.aws.amazon.com/ja_jp/wellarchitected/latest/high-performance-computing-lens/images/image4.png)


*図 3: 疎結合のワークロード用にデプロイされた Amazon SQS*

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

1.  複数のユーザーが、AWS CLI や SDK でジョブを送信します。 

1.  ジョブが Amazon SQS のキューにメッセージとして追加されます。 

1.  EC2 インスタンスがキューをポーリングして、ジョブの処理を始めます。 

1.  Amazon SQS は、キューにあるメッセージ (ジョブ) の数に基づき、メトリクスを発行します。 

1.  キューが指定した長さよりも長くなくなったときに Auto Scaling に通知するための Amazon CloudWatch アラームが設定されます。Auto Scaling が EC2 インスタンスの数を増やします。 

1.  EC2 インスタンスがソースデータを引き出し、結果データを S3 バケットに保管します。 

# ハイブリッドなデプロイ
<a name="hybrid-deployment"></a>

 ハイブリッドデプロイは、主にオンプレミスのインフラストラクチャに投資をし、AWS を使用したい組織によって検討されます。このアプローチにより、組織はオンプレミスのリソースを増強し、すぐに AWS へ完全に移行するのではなく、AWS への代替パスを作っておくことができます。 

 ハイブリッドなシナリオは、ワークロードの分離といった最小限な調整から、スケジューラによるジョブ配置などの緊密に統合されたアプローチまでさまざまです。例えば、組織はワークロードを分離し、特定の種類のワークロードを AWS のインフラストラクチャで実行することがあります。もしくは、オンプレミスの処理とインフラストラクチャーに多額の投資をしている組織では、ジョブをスケジューリングするソフトウェアや、ジョブを送信するポータルを AWS リソースと一緒に管理することで、よりシームレスなエンドユーザー体験を望むかもしれません。商用またはオープンソースのいくつかのジョブスケジューラーは、必要に応じて AWS のリソースを動的にプロビジョニングしたり、プロビジョニングを解除する機能を提供しています。ベースとなるリソースマネジメントはネイティブな AWS インテグレーション (例えば、AWS CLI や API) に依存し、スケジューラーによっては環境を高度にカスタマイズできます。ジョブスケジューラは AWS リソースの管理に役立ちますが、スケジューラはデプロイを成功させるための 1 つの側面にすぎません。 

 ハイブリッドシナリオを正常に運用するための重要な要素は、データの局所性とデータ移動です。いくつかの HPC ワークロードでは、重要なデータセットは不要か、あるいは生成されません。したがって、データ管理はそれほど重要ではありません。しかしながら、大きなインプットデータを必要としたり、重要な出力データを生成するようなジョブはボトルネックとなりえます。データ管理のためのテクニックは、組織により異なります。例えば、ある組織ではエンドユーザーがジョブ送信スクリプトを使ってデータ転送を管理していますが、他の組織ではデータセットがある場所で単にいくつかのジョブを実行しているだけです。別の組織では両方の場所でデータを複製することを選択しているかもしれませんし、さらに他の組織では複数のオプションを組み合わせて使うことを選択しているかもしれません。 

 データ管理のアプローチに応じて、AWS はハイブリッドデプロイを支援するいくつかのサービスを提供します。例えば、AWS Direct Connect はオンプレミス環境と AWS との間に、専用のネットワーク接続を確立します。また、AWS DataSync はオンプレミスのストレージから、Amazon S3 や Amazon Elastic File System にデータを自動的に移動します。AWS Marketplace や AWS パートナーネットワーク (APN) より、追加のサードパーティー製ソフトウェアオプションも利用できます。 

 ハイブリッドデプロイのアーキテクチャは、疎結合と密結合ワークロードに使用できます。しかしながら、最適なパフォーマンスのためには、密結合ワークロードがオンプレミスまたは AWS のどちらかに 1 つは存在していなければなりません。 

 **リファレンスアーキテクチャ** 

![\[Diagram showing on-premises data center connected to AWS クラウド VPC with various compute options.\]](http://docs.aws.amazon.com/ja_jp/wellarchitected/latest/high-performance-computing-lens/images/image5.png)


*図 3: ハイブリッドでスケジュールベースのデプロイの例*

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

1.  ユーザーが、オンプレミスのログインノードにあるスケジューラ (例えば Slurm) にジョブを送信します。 

1.  スケジューラは設定に従って、オンプレミスのコンピューティングか AWS インフラストラクチャにあるジョブを実行します。 

1.  ジョブは、実行される場所に応じた共有ストレージにアクセスします。 

# サーバーレス
<a name="serverless"></a>

 疎結合クラウドジャーニーが完全にサーバーレスな環境になることがしばしばあります。これによりアプリケーションに集中でき、サーバーのプロビジョニングをマネージドサービスに任せることができます。サーバーをプロビジョニングや管理をすることなく、AWS Lambda がコードを実行できます。使用したコンピューティング時間に対してのみお支払いいただきます。コードが実行されていない時間には料金が発生しません。コードをアップロードすると、Lambda がコードの実行とスケールに必要なすべての処理を行います。また、Lambda は、他の AWS のサービスからのイベントを自動的にトリガーする機能も備えています。 

 スケーラビリティは、Lambda のサーバーレスアプローチによる 2 つ目の強みです。例えば、複数のメモリがあるコンピューティングのコアなど、それぞれのワーカーは最適なサイズであっても、アーキテクチャによって数千もの Lambda ワーカーが同時に発生し、膨大なコンピューティングのスループットキャパシティに達し、HPC ラベルをもたらすことがあります。例えば、同じアルゴリズムによって呼び出された膨大な数のファイルが分析される場合や、膨大な数のゲノムが並行して分析される場合、または膨大な数のゲノムの遺伝子的位置をモデリングしなければならない場合などです。スケールを行う最大値と、スケールする速度が問題になります。サーバーベースのアーキテクチャでは、リクエストに応じてキャパシティーを増やすために数分程度の時間が必要ですが (EC2 インスタンスなどの仮想マシンを使用している場合でも)、サーバーレス Lambda 関数は数秒でスケールします。AWS Lambda は、コンピューティング集約型の結果に対する予期しないリクエストに即座に応答する HPC インフラストラクチャを有効にし、事前のリソースの無駄なプロビジョニングを必要とすることなく、さまざまな数のリクエストに対応することができます。 

 コンピューティングに加えて、HPC ワークフローを支援する他のサーバーレスアーキテクチャがあります。AWS Step Functions は、さまざまな AWS のサービスをつなぎ合わせることで、パイプラインの複数のステップを調整できます。例えば、自動化されたゲノミクスパイプラインを、調整のために AWS Step Functions で、保存のために Amazon S3 で、小さなタスクのために AWS Lambda で、およびデータ処理のために AWS Batch で、それぞれ作成できます。 

 サーバーレスアーキテクチャは疎結合ワークロードに最適であり、他の HPC アーキテクチャと結合する場合にはワークフローのコーディネート役としても最適です。 

 **リファレンスアーキテクチャ** 

![\[AWS クラウド architecture showing user interaction with SDK, S3, and Lambda function.\]](http://docs.aws.amazon.com/ja_jp/wellarchitected/latest/high-performance-computing-lens/images/image6.png)


*図 4: Lambda をデプロイした、疎結合ワークロードの例*

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

1.  ユーザーが、AWS CLI または SDK 経由でファイルを S3 バケットにアップロードします。 

1.  入力ファイルは、入力を表すプレフィックス (例えば、input/ ) をつけて保存されます。 

1.  S3 のイベントが自動的に Lambda の機能をトリガーして、入力データを処理します。 

1.  出力ファイルは、出力を表すプレフィックス (例えば、output/) をつけて S3 バケットに戻され、保存されます。