次の方法で共有

HPC 用の Azure Well-Architected フレームワーク

Azure ハイ パフォーマンス コンピューティング (HPC) の計画では、シナリオを合理化し、技術的な取り組みに優先順位を付け、ワークロードを特定するプロセスの概要を示します。 多くのワークロードでは、一連のアーキテクチャ原則に従うことが重要です。 これらの原則は、ワークロードの開発と最適化に役立ちます。 Azure Well-Architected Framework では、5 つのアーキテクチャコンストラクトについて説明します。 このガイダンスでは、これらの原則をデータ ワークロードの管理に適用する方法の概要について説明します。

信頼性

すべてが壊れる可能性があります。 データ パイプラインも例外ありません。 優れたアーキテクチャは、可用性と回復性を念頭に置いて設計されています。 重要な考慮事項は、変更を検出する速度と、操作を再開できる速度です。

データ環境では、回復力のあるアーキテクチャ、リージョン間の冗長性、サービス レベル、サービス レベル アグリーメント (SLA)、およびクリティカル サポートを検討する必要があります。 また、既存の環境には、統合された監視と通知フレームワークを使用した監査、監視、アラートも含まれている必要があります。

これらの環境制御に基づき、ワークロード チームは次の点を考慮する必要があります。

  • サービス レベル SLA を向上させるためにアーキテクチャの変更を行う。
  • 冗長ワークロード固有のアーキテクチャを設定する。
  • クラウド運用チームが提供するもの以外の監視と通知のプロセスを確立する。

ハイブリッド ExpressRoute 接続

ミッション クリティカルな HPC ワークロードをサポートするには、Azure ExpressRoute の高可用性構成を使用します。 冗長な ExpressRoute 接続がある可能性がある単一サイトの高可用性セットアップでも、単一エッジ サイトのダウンタイムから保護されません。 2 つの施設で 2 つの接続を有効にすると、プライマリ ロケーションで障害が発生した場合でも、冗長性によってビジネスを継続できます。 ExpressRoute の高可用性を使用すると、1 つのリージョンで ExpressRoute の停止が発生した場合に Azure への接続を確保できます。

推奨事項

  • 冗長性を最大限に高める 2 つの異なる ExpressRoute エッジ サイトの場所で 2 つの ExpressRoute 回線を有効にします。
    • このセットアップでは、2 つの異なる ExpressRoute エッジ サイトの場所に対して、Azure portal で 2 つの ExpressRoute 回線を確立する必要があります。 次に、両方の ExpressRoute 回線を Azure の同じ仮想ハブ ネットワークに接続します。
    • 2 つのエッジ サイトの場所を同じ Azure リージョンに配置します。 これは、ピアリングの場所の 1 つが失敗した場合に冗長性を提供します。 どちらの ExpressRoute 接続も、Azure の同じ仮想ハブ ネットワークに終了します。 ExpressRoute の場所と接続パートナーの一覧を表示して、ExpressRoute ピアリングの場所を計画します。
    • プロバイダーと連携して、2 つ目の ExpressRoute サイトを構成します。
    • トラフィックを 2 番目の場所にフェールオーバーすることで、2 つ目の接続が機能していることを確認します。これは非常に重要です。 接続を確保するために定期的なドリルを実行します。

最大回復性 ExpressRoute 構成の詳細については、「 ExpressRoute を使用したディザスター リカバリーの設計」を参照してください。

セキュリティ

HPC 環境にセキュリティ原則を適用して、貴重なデータとシステムの意図的な攻撃や悪用に対するセーフガードを提供します。 ユーザー オペレーティング システム イメージとユーザー アクセスのセキュリティ保護を確認し、Azure Batch と Azure CycleCloud のセキュリティ ガイドラインに従います。 詳細については、「 セキュリティの柱の原則」を参照してください。

オペレーティング システム イメージ

Azure Marketplace には、クラスターで使用する Linux ベースの HPC イメージが用意されています。 これらのイメージには、次のような多くの一般的なライブラリ、ソフトウェア パッケージ、診断ツールが含まれています。

  • InfiniBand ベースのメッセージ パッシング インターフェイス (MPI) ライブラリ。
  • Mellanox OFED。
  • InfiniBand 経由の事前構成済み IP。
  • 通信ランタイム。
  • Intel/AMD 最適化ライブラリ。
  • Azure HPC 診断ツール。

イメージから始めて、組織のセキュリティ ポリシーを適用して、脆弱性やサイバー脅威に対するソフトウェア イメージを強化できます。 検証後、新しいイメージを Azure コンピューティング ギャラリーに保存できます。 その後、このイメージを使用して、Azure CycleCloud、Azure HPC、Batch に仮想マシンを作成できます。

ユーザー アクセス

  • 各機能の責任と職務の分離の明確なラインを定義します。
  • 知る必要がある基準と最小限の特権のセキュリティ原則に基づいてアクセスを制限します。
  • Azure ロールベースのアクセス制御を使用して、特定のスコープでユーザー、グループ、およびアプリケーションにアクセス許可を割り当てます。 可能な場合は、組み込みロールを使用します。
  • 管理ロックを使用して、リソース、リソース グループ、またはサブスクリプションの削除または変更を防止します。
  • マネージド ID を使用して Azure のリソースにアクセスします。
  • 1 つのエンタープライズ ディレクトリをサポートします。 重大な影響を与えるアカウントを除き、クラウドとオンプレミスのディレクトリの同期を維持します。
  • Microsoft Entra 条件付きアクセスを設定します。 すべてのユーザーを認証するときに、特に重大な影響を与えるアカウントの場合は、主要なセキュリティ属性を適用して測定します。
  • パスワードなしのメソッドを使用するか、最新のパスワードメソッドを選択します。
  • レガシ プロトコルと認証方法をブロックします。

Azure Batch のセキュリティ

ベスト プラクティスに従って Batch のセキュリティを有効にします。

Azure CycleCloud のセキュリティ

ベスト プラクティスに従って 、Azure CycleCloud のセキュリティを有効にします。

コストの最適化

Azure で環境を最大限に活用するには、コスト管理と事前計画の演習に優先順位を付けます。 通常、コスト管理と計画は、組織がクラウド移行を成功させるために最も重要な考慮事項です。 Microsoft Cost Management には、クラウドへの投資を最大化するために、支出を計画、分析、削減するためのツールが用意されています。 クラウド コストを計画および最適化する方法の詳細については、「 コスト管理の課金のベスト プラクティス」を参照してください。 コストの最適化で最も重要な考慮事項を次に示します。

オペレーティング システムの選択

Linux は、HPC ワークロードの主要なオペレーティング システムです。 Linux はオープン ソースであり、HPC インフラストラクチャを使用するようにパフォーマンスが調整されています。 そのため、MPI ライブラリと Infiniband ドライバーは、Linux と Windows でうまく機能します。 HPC クラスターを設定するために Linux 仮想マシン (VM) と Windows を使用することで、コストを確実に節約できます。 ただし、一部のユーザーは、特に計算流体力学などのワークロードで前処理タスクや後処理タスクを実行する際に、Windows 環境を強く優先している場合があります。 この場合は、シミュレーションにコンピューティング ノードを使用するヘッド ノードである Linux ホストに Windows フロントエンドでジョブを送信することをお勧めします。

自動スケーリング

自動スケールを使用すると、ジョブを送信したとき、またはジョブがアクティブな場合にのみ、VM を設定して使用できます。 ジョブが完了すると、ノードは自動的にオフになります。 自動スケーリングを使用すると、アプリケーションで使用されるコンピューティング リソースを調整し、時間とコストを節約できる可能性があります。 Azure CycleCloud のスケジューラでは、既定で自動スケールが有効になっています。 ノードをオフにする既定の時間制限は 15 分です。 制限時間をカスタマイズできます。 制限時間は、ユーザーが使用した分だけ支払うことを保証するのに役立ちます。 Batch には、自動スケール式とパラメーターの選択を統合するメカニズムが用意されています。 詳細については、「 Azure での自動スケーリングの概要」を参照してください。

従量課金制、予約済みインスタンスおよびスポットインスタンス

Azure には、さまざまな価格オプション、従量課金制、1 年または 3 年のオプションを含む予約インスタンス、およびデータ センターで使用可能な容量の対象となるスポット インスタンスが用意されています。 従量課金制インスタンスは、容量に対する散発的な需要に対応するため、コスト効率が高くなります。 HPC に対する継続的な需要がある場合、または Azure HPC で実行されるアプリケーションが多数ある場合、予約インスタンスはコスト効率が高い可能性があります。 どちらも運用環境に対応したワークロードに適しています。 スポット インスタンスは、簡単なテストと実験、またはアプリケーションでチェックポイント処理が必要な場合 (たとえば、genomics) に適しています。 スポット インスタンスは、データ センターで使用可能な容量の対象となります。 価格はこれらの要因によって異なります。 スポット インスタンスは、最小限の通知で削除できます。

データの分類

HPC ワークロードは、高スループットストレージのメリットを得られます。 たとえば、Azure Managed Lustre、Azure Net App Files、BeeGFS 並列ファイル システムを使用します。 これらのストレージ サービスはパフォーマンスを提供しますが、コストがかかる可能性があります。 これらのシステムにはアプリケーション固有のデータのみが存在するように、事前にデータを分類することが重要です。 他のすべてのデータは、Azure Data Lake Storage や Azure Blob Storage などの低コストのストレージ ソリューションに存在できます。

さらに、データが Blob Storage などの低コストのストレージ サービスと確実に同期されるように、HPC ストレージ システムをオンデマンドで設定すると便利な場合があります。 オンデマンド ストレージは、高パフォーマンスのストレージ システムがオフになっている場合に、Blob Storage にデータが保持されるようにするのに役立ちます。 Managed Lustre と Net App Files では、同期サービスが提供されます。

予算を設定する

Azure CycleCloud を使用すると、クラスターごとに予算を設定し、予算を使い果たすのに近い場合に受信者に通知を送信できます。 Batch の場合、Azure portal から Batch プールまたは Batch アカウントの予算と支出アラートを作成できます。 予算とアラートは、予算オーバーのリスクを関係者に通知するのに役立ちますが、支出アラートの遅延が生じたり、予算をわずかに超過したりする危険性があります。

オペレーショナルエクセレンス

HPC アプリケーションを運用環境で実行し続ける場合、デプロイは信頼性が高く予測可能である必要があります。 信頼性の高い予測可能なデプロイは、コードとしてのインフラストラクチャ (IaC) ソリューションを使用して HPC ワークロードを自動化することで構成されます。 また、ノードの正常性チェックを実行して、HPC ワークロードを分析および監視する必要もあります。

デプロイの提案の詳細については、「 コードとしてインフラストラクチャを使用するための推奨事項」を参照してください。 監視の提案の詳細については、 監視システムの設計と作成に関する推奨事項を参照してください。

コードとしてのインフラストラクチャ

Azure 上の HPC は、Azure CycleCloud、HPC クラスター、ストレージ、視覚化ノード、ライセンス サーバーなどの複数のリソースをデプロイします。 デプロイを自動化するには、Terraform、Ansible、Packer などの業界標準のツールを使用してプロセスを簡略化することをお勧めします。

ノードの正常性チェック

Azure Managed Grafana は、分析および監視ソリューション用のフル マネージド サービスです。 Grafana Labs は Grafana をサポートし、拡張可能なデータ視覚化を提供します。

パフォーマンス効率

HPC 環境が効率的にスケーリングできることを確認して、ユーザーがそれに対する要求を満たすことができるようにします。 アプリケーション ベンダーの推奨事項に基づいて、HPC アプリケーションに適したプラットフォームを選択します。 需要を満たすために追加のインフラストラクチャが必要な場合は、容量計画に投資します。 ユーザーがシステムを使用する場合に HPC インフラストラクチャのパフォーマンスを監視します。

詳細については、パフォーマンス効率に関する 記事を参照してください。

HPC アプリケーションに適したプラットフォームを選択する

Azure では、Intel、AMD CPU、NVIDIA、AMD GPU に基づく VM 用のさまざまなプラットフォームが提供されています。 ほとんどのアプリケーションは使用可能なものと互換性がありますが、一部のアプリケーションは特定の種類の CPU または GPU からのみメリットがあります。 インフラストラクチャをクラウドにデプロイする前に、次のニーズを理解するために、アプリケーション ベンダー (ISV) からの推奨事項を用意することが重要です。

  • アプリケーションがメモリ バインド、CPU バインド、または GPU バインドの場合
  • パフォーマンスのために任意の種類の CPU または GPU アーキテクチャに関する推奨事項がある場合
  • MPI の種類とそのバージョンがあり、そのアプリケーションでメリットがある場合
  • スケジューラの種類に関する推奨事項がある場合
  • 並列ファイル システムからの IOPS/スループットに関する推奨事項がある場合

キャパシティ プランニングに投資する

アプリケーションの種類とそのライセンス条件に基づいて、ライセンスが特定の数のコアを使用するように設定されているかどうかを確認します。 ライセンスが HPC に対応できるように投資を評価し、それに応じて容量を計画します。

インフラストラクチャのパフォーマンスを監視する

  • ユーザーがシステムを使用する方法を追跡し、リソースの使用をトレースし、システムの正常性とパフォーマンスを一般的に監視できることが重要です。 この情報を診断支援として使用して、問題を検出して修正し、潜在的な問題を特定し、問題が発生するのを防ぐことができます。 リソースを監視するために使用できる Azure コンポーネントとサービスの概要については、 Azure Monitor の概要に関するページを参照してください。
  • 監視は、VM インスタンスとストレージにボトルネックがあるかどうかを識別するための優れたツールです。
  • ストレージの調整により、アプリケーションの速度が大幅に低下し、パフォーマンスに影響を与える可能性があります。 調整は、ストレージ内の入力操作と出力操作が、設定したスループット制限を超えた場合に発生します。 Azure Storage サービスでは、スロットリングによる問題があるかどうかを監視するための読み取りおよび書き込み操作のグラフが提供されています。
  • Azure CycleCloud は、Monitor や Microsoft Cost Management ツールなどの Azure サービスと統合されます。 また、プラグ可能なアーキテクチャを使用した外部サービスの監視もサポートしています。 詳細については、「監視」を参照してください。
  • さらに、Batch を使用している場合、 Batch Explorer は、Batch アプリケーションの作成、デバッグ、監視に役立つ、豊富な機能を備えた無料のスタンドアロン クライアント ツールです。

次のステップ