HPC on AWS での Well-Architected Framework を学ぼう！（後編）
前回に引き続き、AWS でハイパフォーマンスクラウド（HPC）を利用したい方向けに、「High-Performance Conputing Lens（AWS Well-Architected Framework）」というドキュメントをわかりやすくまとめてお伝えします！前編では、以下についてご紹介いたしました。
- 「Well-Architected Frameworkってなに？」
- 「HTC（High-throughput computing）環境での考慮」
- 「HPC（High-performance computing）環境での考慮」
まだ読んでないよ！という方は、以下を参照ください。
今回は、Well-Architected Framework が基づいている以下、5つの柱についてご紹介していきます。
- 運用上の優秀性
- セキュリティ
- 信頼性
- パフォーマンスの効率性
- コストの最適化
各柱では、設計原則、定義、ベストプラクティスと評価するための質問、考慮事項 について説明します。
運用上の優秀性
運用上の優位性は、ビジネス価値を提供し、サポートプロセスと手順を継続的に改善するために、システムを実行および監視する機能が含まれています。
設計原則
伝統的なものと、クラウドネイティブなもの
HPC アーキテクチャは、通常、2つの形式のうちの1つをとります。
- 従来のクラスタ構成
- マスターヘッドインスタンス、計算ノード、スケジューラ、およびキューを持つ。
- クラウドネイティブなクラスタ構成
- オートデプロイ、サーバーレス、マネージドサービスを使用する。
- １つのワークロード毎に（一時的）クラスタを使用する。
最適なアプローチは HPC ユーザーが求める環境に依存しますが、クラウドネイティブアーキテクチャは運用上の考慮事項をさらに最適化できます。
コードで操作を実行する
自動化は、繰り返しのプロセスや手順がある場合に優れた運用性を提供します。たとえば、HPC クラスタでは以下のような運用の自動化を検討します。
- プロビジョニングする場合、共有ストレージ、認証、ライブラリ、パス、およびその他の一般的な属性の指定など、計算ノードの構成管理の自動化
- ユーザーデータ、スタートアップスクリプト、infrastructure-as-code テンプレートを使用して自動化できます。
- インフラストラクチャーの再現性も利点になります。
- ジョブの開始、完了、失敗などのイベントへの応答を自動化
- ジョブ投入プロセスの自動化
- HPC では、ユーザーがケースファイルのアップロード、ジョブのスケジューラへの送信、結果ファイルの移動など、すべてのジョブで複数の手順を繰り返すことが一般的です。
これらの反復的なステップは自動化することで、ユーザビリティを最大化し、コストと障害を最小限に抑えることができます。
定義
クラウドにおける運用上の優秀性には3つのベストプラクティスの領域があります。
- 準備
- 操作
- 進化
準備領域と進化領域については、AWS Well-Architected Framework ホワイトペーパーに記載されており、HPC ワークロードとしての変更点は必要ないため、ここでは説明しません。
ベストプラクティス
操作
業務は標準化され、定期的に管理されるべきです。自動化、頻繁にない変更、定期的な品質保証テスト、変更の追跡、監査、ロールバック、および変更するために定義されたメカニズムに焦点を当てるべきです。ワークロードの主要な運用指標に基づく幅広いログとメトリックを収集してレビューし、継続的な運用を確実にする必要があります。
モニタリング支援から導入の自動化までさまざまです。たとえば、Auto Scaling で失敗したインスタンスを再起動したり、CloudWatch を使用してクラスタの負荷メトリックを監視したり、ジョブが終了したときの通知を設定したり、AWS Batch などの管理対象サービスを使用して失敗したジョブの再試行ルールを実装できます。クラウドネイティブツールは、アプリケーションのデプロイと変更管理を大幅に向上させます。
HPCOPS1： どのように変更の影響を最小限に抑えながら、ワークロードを進化させていますか？ HPCOPS2： どのようにワークロードを監視し、期待どおりに動作させますか？
HPC にクラウドを使用すると、新しい運用上の考慮事項が導入されます。オンプレミスクラスタはサイズが固定されていますが、クラウドクラスタはオンデマンドに拡張できます。クラウドの弾力性とクラウドネイティブアーキテクチャの動的性質から利益を得て、それに適応する運用手順を採用することを検討してください。
セキュリティ
セキュリティの柱では、情報、システム、資産を保護しながら、リスク評価と緩和戦略を通じてビジネス価値を提供する能力が含まれます。
設計原則
最小特権の原則を実装する
権限が AWS リソースとの相互作用が適切であることを確認し、強力な論理アクセス制御をリソースに対して直接実装します。
システムのセキュリティ確保に重点を置く
AWS共有責任モデルを使用すると、アプリケーション、データ、およびオペレーティングシステムのセキュリティに重点を置くことができ、AWSは安全なインフラストラクチャとサービスを提供します。
セキュリティのベストプラクティスの自動化
ソフトウェアベースのセキュリティー・メカニズムは、より迅速かつコスト効率の高い安全な拡張を可能にします。仮想サーバーのパッチを当ててセキュリティ強化したイメージを作成して保存し、起動する新しいサーバーでは、そのイメージを自動的に使用します。リビジョンコントロールを使用してテンプレートで定義および管理される信頼ゾーンアーキテクチャ全体を作成します。ルーチンと異常なセキュリティイベントの両方への応答を自動化します。
機密データの露出を制限する
HPC データは通常、限られた時間内に生成され、サーバーから S3 などの高可用性ストレージオプションに移行することができます。これにより、データへの不正アクセスの可能性が最小限に抑えられます。
トレーサビリティを有効にする
環境へのすべてのアクションと変更を記録し、監査します。
定義
クラウドにおけるセキュリティには5つのベストプラクティスの領域があります。
- アイデンティティとアクセス管理
- 発見的統制
- インフラ保護
- データ保護
- インシデント対応
システムを構築する前に、セキュリティに影響するプラクティスを導入する必要があります。セキュリティインシデントに対応するためには、明確かつ実践的なプロセスが必要です。これらのツールとテクニックは、データ損失の防止や規制義務の遵守などの目的をサポートするため重要です。
AWS 共有責任モデルにより、組織はクラウドを採用してセキュリティとコンプライアンスの目標を達成できます。AWS がクインフラストラクチャを物理的に保護することで、ユーザはサービスを使用して目標を達成することに集中できます。AWS クラウドは、セキュリティデータへのアクセスを強化し、セキュリティイベントへの自動対応を提供します。
発見的統制、インフラ保護、インシデント対応の領域は非常に重要ですが、AWS Well-Architected Framework ホワイトペーパーに詳しく説明されており、HPC ワークロードとしての変更点は必要ないため、ここでは説明しません。
ベストプラクティス
アイデンティティとアクセス管理
情報セキュリティプログラムの重要な部分であり、許可された認証済みのユーザーだけが意図した方法でリソースにアクセスできるようにします。さらに、機密データの公開を制限するために、HPC ワークロードを自律的かつ一時的に実行することを検討してください。自律的なデプロイメントでは、インスタンスへのユーザーアクセスが最小限に抑えられ、リソースの公開が最小限に抑えられます。HPC データは通常、限定された時間内に生成され、潜在的に許可されていないデータへのアクセスを最小限に抑えます。
HPCSEC1： ワークロードインフラストラクチャへのユーザーアクセスを最小限に抑えるために、マネージドサービス、自律メソッド、および一時クラスターが使用されていますか？
EC2 インスタンスへの接続など、コンピューティング環境への直接アクセスが必要な場合、一般に SSH を介して接続し、SSH キーで認証します。 SSH キーはプライベートデータとして扱われ、定期的にローテーションされるべきです。
HPCSEC2： どのような方法で SSH 認証キーを管理したりローテーションしています？
データ保護
システムを構築する前に、セキュリティに影響を与える基本的なプラクティスを実行する必要があります。たとえば、データの分類は、機密性のレベルに基づいて組織データを分類する方法を提供し、暗号化は不正なアクセスを理解できないようにしてデータを保護します。これらのツールとテクニックは、データ損失の防止や規制義務の遵守などの目的をサポートするため重要です。
機密性および規制義務のレベルに加えて、HPC データは、データが次に使用される時期および方法に従って分類することもできます。必要に応じて再作成可能な中間結果を保持する必要はない場合がありますが、最終結果は保持されることがあります。データの慎重な評価と分類により、重要なデータを S3 や EFS などのより復元力の高いストレージソリューションにプログラム的に移行することができます。
HPCSEC3： あなたのアーキテクチャは、結果のライフサイクルを通じて、ストレージの可用性と耐久性に関するデータ要件にどのように対応していますか？
信頼性
信頼性の柱では、インフラストラクチャやサービスの中断から回復し、需要を満たすためにコンピューティングリソースを動的に獲得し、構成ミスや一時的なネットワーク問題などの混乱を緩和するシステムの機能が含まれます。
設計原則
水平にスケールしてシステム全体の可用性を向上させる
システム全体に対する単一の障害の影響を軽減する水平スケーリングオプションを検討することが重要です。たとえば、複数のケースから複数のジョブを実行する1つの大規模共有 HPC クラスタではなく、AWS インフラストラクチャ全体に複数のクラスタを作成して、潜在的な障害のリスクをさらに分離することを検討してください。インフラストラクチャはコードとして扱うことができるため、単一クラスタ内でリソースを水平方向に拡大するだけでなく、個々のケースを実行するクラスタの数を水平方向にスケールすることもできます。
推測をやめる
HPC クラスタのセットは、現在のニーズを満たすようにプロビジョニングし、手動または自動でスケーリングして、需要の増加または減少に対応できます。計算ノードは、使用されていないときにはアイドル状態である必要はなく、限られたリソースのために計算に長い待機時間を持たせる必要はない。
自動の変更管理
インフラストラクチャの変更は、自動化を使用して行う必要があります。これにより、バージョン管理下にクラスタインフラストラクチャを配置し、以前に作成したクラスタを正確に複製することができます。管理する必要のある変更は、自動化の変更です。
定義
クラウドにおける信頼性の柱には、3つのベストプラクティスの領域があります。
- 基礎
- 変更管理
- 障害管理
変更管理は、AWS Well-Architected Framework ホワイトペーパーに記載されており、HPC ワークロードとしての変更点は必要ないため、ここでは説明しません。
ベストプラクティス
基礎
クラウドは本質的に無制限に設計されているため、十分なネットワーキングと計算能力の要件を満たすのは AWS の責任です。AWS は、ユーザが誤ってリソースを過剰にプロビジョニングすることを防ぐために、サービス制限（要求できる各リソースの数の上限）を設定しています。大規模なワークロードを1つの大規模なクラスタまたは多数の小さなクラスタに一度にデプロイする前に、AWSサービスの制限を増やす必要があります。
HPCREL1： アカウントの AWS サービスの制限をどのように管理していますか？
大規模なデプロイメントの要件を満たすために、サービスの制限を既定値から増やすことがよくあります。AWS サポートに連絡して上限引き上げをリクエストすることができます。
障害管理
複雑性を持つシステムでは、障害が発生することが予想され、これらの障害を認識して対応し、それらが再び起こるのを防ぐ方法を知ることは一般的に重要です。障害シナリオには、クラスタの起動の失敗や特定のワークロードの障害が含まれます。
耐障害性は、複数の方法で向上させることができます。長期実行の場合、コードに定期的なチェックポイントを組み込むことで、障害発生時に部分的な状態から続行することができます。チェックポイントは、多くの HPC アプリケーションに既に組み込まれているアプリケーションレベルの障害管理の共通の機能です。最も一般的なアプローチは、実行中のアプリケーションが中間結果を定期的に書き出すことです。最後のチェックポイントとジョブの失敗の間に行われた作業を失うだけで、アプリケーションエラーを診断したり、必要に応じてケースを再起動したりすることができます。
HPCREL2： アプリケーションは、障害から回復するためにチェックポイントをサポートしていますか？
障害管理をチェックポイントに頼る場合、ストレージオプションの耐久性を考慮する必要があります。
複数の AZ にデプロイすることで、耐障害性を向上できる可能性があります。密結合された HPC アプリケーションのレイテンシが短いという要件は、個々のケースが単一のリプレイスメントグループと AZ 内に存在することを必要とします。また、HTC アプリケーションでは、レイテンシの低い要件はなく、複数の AZ にデプロイする機能を備えた障害管理機能を向上させることができます。
設計上の決定を下す際に、信頼性とコストの柱の間のトレードオフを考慮してください。計算ノードとストレージインフラストラクチャ（たとえば、ヘッドノードに接続されたストレージ）が重複すると追加コストが発生し、オリジン AWS リージョン外の AZ にデータを移動するためのデータ転送料金が発生する可能性があります。緊急ではないケースは、災害復旧（DR）イベントの一環として別の AZ に移動することが望ましい場合があります。もう1つの可能性は、AZ の中断には何もせず、単純にそれが回復するまで待ちます。
HPCREL3： あなたのアーキテクチャにおける耐障害性はどのように計画していますか？
パフォーマンス効率
パフォーマンス効率の柱は、コンピューティングリソースを効率的に使用して、要件を満たし、需要の変化やテクノロジが進化するにつれてその効率を維持することに重点を置いています
設計原則
アプリケーションのクラスターを設計する
従来のクラスターは静的であり、アプリケーションをクラスターにあわせて設計する必要があります。AWS では、アプリケーションにあわせてクラスタを設計する機能があります。ワンサイズフィットのモデルはもう必要ありません。AWS 上でさまざまなアプリケーションを実行する場合、さまざまなアーキテクチャを使用して各アプリケーションの要求を満たすことができます。
意味のあるユースケースでのパフォーマンスのテスト
特定のアーキテクチャで HPC アプリケーションのパフォーマンスを評価する最前の方法は、アプリケーション自体に意味のあるデモンストレーションを実行することです。予期せぬコンピューティング、メモリ、データ転送、またはネットワークトラフィックのないデモケースでは、AWS でのアプリケーションパフォーマンスの有意義なテストとは言えません。システム固有のベンチマークは、基盤となるコンピューティングインフラストラクチャのパフォーマンスを把握していますが、アプリケーションがどのように集約して実行されるかを反映していないことがよくあります。AWS の従量課金モデルは、PoC を迅速かつ費用対効果の高いものにします。
クラウドネイティブアーキテクチャの検討
クラウドでは、管理、サーバーレス、クラウドネイティブのアーキテクチャにより、従来のコンピューティングアクティビティを実行するためにサーバーを稼働および保守する必要がなくなります。クラウドを使用すると、ワークロードプロセスの各ステップを分離して最適化できます。
頻繁に実験する
仮想および自動化可能なリソースを使用すると、異なるタイプのインスタンス、ストレージ、または構成を使用して比較テストを迅速に実行できます。
定義
クラウドにおけるパフォーマンス効率の柱には、4つのベストプラクティス領域があります。
- 選択 (コンピューティング、ストレージ、データベース、ネットワーク)
- 確認
- モニタリング
- トレードオフ
確認、モニタリング、トレードオフは、AWS Well-Architected Framework ホワイトペーパーに記載されており、HPC ワークロードとしての変更点は必要ないため、ここでは説明しません。
ベストプラクティス
選択
特定のシステムの最適なソリューションは、使用しているワークロードの種類によって異なります。適切に設計されたシステムは、複数のソリューションを使用し、さまざまな機能を使用してパフォーマンスを向上させます。
コンピューティング
特定の HPC アーキテクチャの最適なコンピューティングソリューションは、ワークロードのデプロイ方法、自動化のレベル、使用パターン、および構成によって異なります。プロセスの各ステップごとに異なるコンピューティングソリューションを選択することができます。アーキテクチャに間違ったコンピューティングソリューションを選択すると、パフォーマンス効率が低下する可能性があります。
インスタンスは仮想化されたサーバーであり、様々な機能を提供するために異なるファミリとサイズで提供されます。一部のインスタンスファミリは、コンピューティング、メモリ、GPU 集約型のワークロードなどの特定のワークロードをサポートしますが、汎用のワークロードもあります。対象となるワークロードと汎用インスタンスの両方のインスタンスファミリは、HPC アプリケーションに役立ちます。HPC に関心の高いインスタンスには、コンピューティングに最適化されたファミリと、GPU や FPGA などの高速化されたインスタンスタイプがあります。しかしながら、コンピューティング負荷の高いワークロードでは、T シリーズインスタンスファミリのパフォーマンスが大幅に低下する可能性があります。これは、そのコンピューティングリソースがバースト許容量を使い切った後にバーストが抑制されるためです。
各インスタンスファミリ内で、1つ以上のインスタンスサイズ（インスタンスタイプマトリックスを参照）は、リソースの垂直方向のスケーリングを可能にします。 アプリケーションによっては、大きいインスタンスタイプ（たとえば 16xlarge）が必要なアプリケーションもあれば、小さいタイプ（たとえば、large）で実行するアプリケーションもあります。多くの小規模インスタンスは、HPC アプリケーションでは、少ない大規模インスタンスよりも適している場合があります。
アプリケーションの要件（コア、プロセッサ速度、メモリ要件、ストレージニーズ、ネットワーク仕様など）はさまざまです。 インスタンスファミリとタイプを選択するときは、アプリケーションのニーズから始めます。特定のアプリケーションコンポーネントのターゲットインスタンスを必要とするアプリケーションでは、インスタンスの種類を混在させることができます。
コンテナはシステムの仮想化を操作する方法であり、特にアプリケーションがすでにコンテナ化されている場合は、多くの HPC ワークロードにとって魅力的です。AWS Batch や ECS などの AWS サービスは、コンテナ化されたアプリケーションのデプロイを支援します。
関数は実行環境を抽象化します。Lambda を使用すると、インスタンスをデプロイ、実行、または保守することなくコードを実行できます。多くの AWS サービスは、サービス内のアクティビティに基づいてイベントを発行し、多くの場合、Lambda 関数をサービスイベントから起動できます。たとえば、オブジェクトが S3 にアップロードされた後で Lambda 関数を実行することができます。多くの HPC ユーザーは Lambda を使用してワークフローの一部としてコードを自動的に実行します。
次の質問の例は、コンピューティングリソースに焦点を当てています。
HPCPERF1： どのようにコンピューティングソリューションを選択しますか？
選択したコンピューティングインスタンスを起動するときには、いくつかの選択肢があります。
- オペレーティングシステム
- 現在のオペレーティングシステムは、最高のパフォーマンスを達成し、最新のライブラリにアクセスできるようにするために重要です。
- 仮想化タイプ
- ハードウェア仮想マシン（HVM） AMI は、特別なハードウェア拡張（CPU、ネットワーク、ストレージ）を利用してパフォーマンスを向上させることができます。HPC アプリケーションには、HVM 仮想化タイプが推奨されます。以前は、AWS は準仮想化（PV）仮想化タイプも提供していました。PV は現在、レガシーなアプローチと見なされています。
HPCPERF2： オペレーティングシステムと仮想化の種類を選択するにはどうすればよいですか？
AMI の選択に加えて、基盤となる Intel Xeon プロセッサのハードウェア機能を利用して、環境をさらに最適化することができます。基盤となるハードウェアを最適化する際に考慮すべき4つの主な方法があります。
- 高度なプロセッサ機能
- Intel ハイパースレッディングテクノロジー
- プロセッサアフィニティ
- プロセッサ状態制御
まず、HPC アプリケーションは、Advanced Vector Extensions などの高度なプロセッサ機能を大幅に活用することができ、Intel アーキテクチャ用のソフトウェアをコンパイルするだけで計算速度を大幅に向上させることができます。アーキテクチャ固有の命令のコンパイラ・オプションはコンパイラによって異なります。(コンパイラの使用法のガイドを参照してください）
次に、AWS はデフォルトで「ハイパースレッディング」と呼ばれる Intel ハイパースレッディング技術を有効にします。ハイパースレッディングは、1つのハイパースレッドごとに1つのプロセス（コアあたり2つのプロセス）を許可することによって、一部のアプリケーションのパフォーマンスを向上させますが、HPC アプリケーションでは、ハイパースレッディングを有効にしてテストされている場合を除き、ハイパースレッディングを無効にし、プロセスを起動してコアに個別に固定することを推奨します。CPU またはプロセッサの親和性により、プロセスのピニングを容易に発生します。
第3に、プロセッサアフィニティは、様々な方法で制御することができます。たとえば、オペレーティングシステムレベル（Windows と Linux の両方で使用可能）で設定したり、スレッドライブラリ内のコンパイラフラグとして設定したり、実行中に MPI フラグとして指定することができます。プロセッサアフィニティを制御するために選択される方法は、ワークロードとアプリケーションによって異なります。
最後に、AWS を使用すると、特定のインスタンスタイプのプロセッサ状態コントロールをチューニングすることができます。C-State（アイドル状態）と P-State（動作状態）の設定を変更してパフォーマンスを最適化することができます。デフォルトの C-State と P-State の設定は、ほとんどのワークロードに最適な最大のパフォーマンスを提供します。ただし、シングルコアまたはデュアルコアの周波数を上げたり、ターキーブースト周波数のスパイクとは対照的に低い周波数で一定の性能を維持したりして、アプリケーションのレイテンシを短縮することができれば、C-State または P-State の設定を試すことを検討してください。
HPCPERF3： アプリケーションのコンピューティング環境をどのように最適化しますか？
コンピューティング環境を最適化するために利用可能な多くのコンピューティングオプションがあります。選択は、アプリケーションのパフォーマンスに重大な影響を与える可能性があります。クラウドデプロイメントでは、インスタンスの種類、オペレーティングシステム、AMI の種類ごとにあらゆるレベルの実験が可能です。
ストレージ
HPC の導入には、クラスタコンピューティングノードがアクセスする共有ファイルシステムまたは高性能ファイルシステムが必要になることがよくあります。AWS マネージドサービス、AWS マーケットプレイス製品、AWS パートナーソリューション、EC2 インスタンスに導入されたオープンソース構成からこれらのストレージソリューションを実装するために使用できるアーキテクチャパターンがいくつかあります。 EFS、 EBSボリューム、インスタンスストアボリュームから高性能なファイルシステムを作成できます。頻繁に、シンプルな NFS マウントを使用して共有ドライブを作成します。
ストレージソリューションを選択する際には、ローカルストレージまたは共有ストレージのいずれかまたは両方に EBS バックアップインスタンスを選択している可能性があります。EBS は、多くの場合、HPC ストレージソリューションの基礎となります。磁気ハードディスクドライブ（HDD）、汎用ソリッドステートドライブ（SSD）、高 IOPS ソリューション用のプロビジョニング IOPS SSD など、さまざまなタイプの EBS ボリュームが利用できます。スループット、IOPS パフォーマンス、コストがそれぞれ異なります。
EBS 最適化インスタンスを選択することで、さらにパフォーマンスを向上させることができます。EBS 最適化インスタンスは、最適化された構成スタックを使用し、EBS I/O に専用の追加容量を提供します。この最適化は、EBS I/O とインスタンス間のその他のネットワークトラフィックとの競合を最小限に抑えることによって、EBS ボリュームのパフォーマンスを最適化します。EBS 最適化インスタンスを選択すると、より一貫性のあるパフォーマンスが得られ、遅延の少ないネットワークに依存する HPC アプリケーションや、EBS に必要な I/O データが集中する HPC アプリケーションに推奨されます。
EBS 最適化インスタンスを起動するには、デフォルトで EBS 最適化を有効にするインスタンスタイプを選択するか、起動時に EBS 最適化を有効にするインスタンスタイプを選択する必要があります。EBS 最適化のサポートについては、インスタンスタイプマトリックスを参照してください。
最後に、NVMe（Non-volatile Memory Express）SSD ボリューム（特定のインスタンスファミリでのみ使用可能）を含むインスタンスストアボリュームを一時的なブロックレベルのストレージに使用できます。インスタンスストアボリュームを使用する共有ネットワークストレージは、典型的には、インスタンス全体にわたってクラスタ化されたファイルシステム（例えば、Lustre）を実装して、基礎となるハードウェア障害およびインスタンスライフサイクルイベント（例えば、停止、終了）を可能にする。
次の質問の例は、パフォーマンスの効率性を考慮したストレージの考慮事項に焦点を当てています。
HPCPERF4： どのようにストレージソリューションを選択しますか？
ストレージソリューションを選択する際は、アクセスパターンと一致することを確認して、目的のパフォーマンスを達成してください。異なるストレージの種類と構成を試すのは簡単です。HPC ワークロードでは、最も高価なオプションが常に最高のパフォーマンスを発揮するとは限りません。
ネットワーク
HPC ワークロードに最適なネットワークソリューションは、レイテンシ、帯域幅、およびスループットの要件によって異なります。密結合された HPC アプリケーションでは、コンピューティングノード間のネットワーク接続に必要な遅延が最小限で済みます。適度なサイズの密結合されたワークロードの場合、アプリケーションがネットワークをまったく横切らずにインスタンス内に完全に収まるように、多数のコアを持つ大きなインスタンスタイプを選択することが可能です。しかし、密結合されたワークロードが大きい場合、複数のインスタンスが必要となり、インスタンス間のレイテンシが小さくなります。AWS では、コンピューティングノードを AZ 内のインスタンスの論理グループであるプレイスメントグループに起動することで実現します。プレイスメントグループは、コンピューティングノードを互いに近接して配置して、低いネットワークレイテンシと高いネットワークスループットを常に提供します。
HTC のケースでは一般にレイテンシが非常に短くなく、通常、プレイスメントグループの使用やインスタンスを同じ可用性ゾーンまたはリージョンに保持する必要がありません。 柔軟性を最大限に高めるには、アプリケーションでコンピューティングインスタンス間の一貫した低ネットワーク遅延が要求されない限り、プレイスメントグループを使用しないでください。
ファミリー内で最大のインスタンスタイプを使用して、最高のネットワークパフォーマンスを得ることができます。詳細については、インスタンスタイプマトリクスを参照してください。
最適なネットワークパフォーマンスを得るには、拡張ネットワークをサポートするインスタンスタイプを選択する必要があります。拡張ネットワーキングにより、ハードウェアエミュレートされたデバイスではなくパススルーを使用することにより、より高いネットワークパフォーマンスと低い CPU 使用率で EC2 インスタンスが提供されます。 この方法により、EC2 インスタンスは従来のデバイス仮想化と比べてより高い帯域幅、より高いパケット/秒の処理、およびインスタンス間レイテンシを達成することができます。
拡張ネットワーキングは、HPC アプリケーションに推奨され、T2 インスタンスファミリを除き、すべての現世代インスタンスタイプで使用できます。拡張ネットワーキングでは、サポートされているドライバで AMI が必要です。最新の AMI にはサポートされているドライバが含まれていますが、カスタム AMI には更新されたドライバが必要な場合があります。拡張ネットワークとインスタンスのサポートを有効にする方法の詳細については、拡張ネットワークのマニュアルを参照してください.
次の例の質問は、パフォーマンスの効率性に関するネットワークの考慮事項に焦点を当てています。
HPCPERF5： どのようにネットワークソリューションを選択しますか？
コスト最適化
コスト最適化の柱には、ライフサイクル全体にわたって HPC システムの改善と、改善を継続するプロセスが含まれています。PoC の初期設計から本番ワークロードの継続的な運用まで、このホワイトペーパーのプラクティスを採用することで、ビジネス成果を達成しコストを最小限に抑えるコスト対応システムを構築、運用することができます。
設計原則
消費モデルを採用する
消費するコンピューティングリソースに対してのみ支払いを行います。HPC のワークロードが緩和され、必要に応じてリソース容量を増減することでコストを削減できます。たとえば、低レベルのランレーティング HPC キャパシティをプロビジョニングして事前に予約することで、より高い割引の恩恵を受けることができます。一方、バースト要件は、スポットまたはオンデマンド価格でプロビジョニングし、必要に応じてオンラインにすることができます。
特定のジョブのインフラストラクチャコストの最適化
多くの HPC ワークロードは、データ転送、前処理、計算計算、後処理、データ転送、および格納手順を含むデータ処理パイプラインの一部です。クラウドでは、すべてのタスクに大規模で高価なサーバーを使用するのではなく、各ステップでコンピューティングプラットフォームが最適化されます。たとえば、パイプライン内の1つのステップで大量のメモリが必要な場合は、メモリを大量に消費するアプリケーション用に高価な大容量のメモリサーバーを使用するだけで、他のすべての手順は小型で安価なサーバーでも実行できます。ワークロードの各ステップで各タスクのインフラストラクチャを最適化することで、コストが節約されます。
最も効率的な方法でワークロードを破棄する
クラウドでは、水平方向にバーストすることによって、HPC ワークロードの節約が得られることがよくあります。水平方向にバーストすると、ワークロード全体の多くのジョブまたは反復が、合計経過時間がより短く同時に実行されます。垂直方向と水平方向のスケーリングは名目上は同じコストになります。水平方向のスケーリングは、ストレージコストを削減するだけでなく、リワークを減らしてより迅速な結果を得ることによって間接的な節約を実現します。
スポット価格を利用する
時間に敏感でないワークロードの場合、EC2 スポットインスタンスは、ワークロードを完了させる最も安価な方法です。断続的でバースト的な HPC ワークロードの性質は、（たとえば、データベースホスティングなどの無停止のワークロードとは対照的に）スポット価格設定に非常に適しています。スポット入札アドバイザを使用することで、スポットインスタンスの中断のリスクを最小限に抑えることができます。時にはワークロードを再起動する必要性は、多くの場合、スポットインスタンスのコスト削減によって容易に相殺されます。
費用対時間のトレードオフを評価する
密結合された大規模並列ワークロードは、しばしば幅広いコア数で実行できます。これらのアプリケーションでは、ケースの実行効率は通常、より高いコア数で低下します。同様のタイプとサイズのケースが多く実行される場合は、コストと所要時間の曲線を作成できます。曲線は、スケーリングが計算量とネットワーク要件の比に大きく依存するため、ケースタイプとアプリケーションの両方に特有です。より大きなワークロードは、より小さいワークロード以上のスケーラビリティを実現します。コスト対所要時間とのトレードオフの関係を理解することで、より多くのコアで時間を敏感なワークロードをより迅速に実行できます。コア数を減らして最大効率で実行することでコストを削減できます。時間の感度とコストの感度をバランスさせたいときは、ワークロードはその中間になることもあります。
定義
クラウドにおけるコスト最適化の柱は、4つのベストプラクティス領域があります。
- コスト効果が高いリソース
- 供給と需要の一致
- 費用の把握
- 継続した最適化
需要と供給の一致、費用の把握、継続した最適化は、AWS Well-Architected Framework ホワイトペーパーに記載されており、HPC ワークロードとしての変更点は必要ないため、ここでは説明しません。
ベストプラクティス
コスト効果が高いリソース
システムに適切なインスタンスとリソースを使用することは、コスト削減の鍵です。インスタンスの選択は、HPC ワークロードを実行するための全体的なコストを増減する可能性があります。たとえば、密結合された HPC のワークロードは、複数の小規模なサーバーのクラスタで実行するのに5時間かかることがありますが、それよりも大きなサーバーのクラスタは時間当たり2倍のコストがかかることがありますが、結果は1時間で計算されます。ストレージの選択はコストにも影響します。したがって、ジョブの所要時間とコスト最適化の間の潜在的なトレードオフを検討し、コストを最適化するために異なるインスタンスサイズとストレージオプションでワークロードをテストすることを検討することが重要です。
適切に設計されたシステムは、最も費用対効果の高いリソースを使用します。また、事前処理と後処理に管理サービスを使用することで、コストを削減することもできます。たとえば、完了した実行データを保存および後処理するようにサーバーを維持するのではなく、S3 にデータを保存してから EMR で後処理することができます。
実行時間を最小限に抑え、コストを削減するためには、パフォーマンスの高いネットワークを必要とする HPC ワークロードをプレイスメントグループで実行する必要があることに注意することが重要です。
HPCCOST1： 最適なコストを評価するためにワークロードのさまざまなインスタンスタイプとストレージオプションを評価しましたか？
HPCCOST2： ジョブの所要時間とコストのトレードオフを考えましたか？
異なるインスタンスタイプ、ストレージ要件、およびアーキテクチャを試すことで、望ましいパフォーマンスを維持しながらコストを最小限に抑えることができます。
さいごに
いかがだったでしょうか。後編は、Well-Architected Framework を築く5つの柱についてご紹介いたしました。今回、ペストプラクティスを確認する質問は、一般的な Well-Architected Framework と同じものは割愛されていますので、あわせてこちらのホワイトペーパも一読ください！
以上！大阪オフィスの丸毛（@marumo1981）でした！
