次の方法で共有

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

  • [アーティクル]

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

[信頼性]

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

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

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

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

Hybrid 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 Compute Gallery に保存できます。 その後、このイメージを使用して、Azure CycleCloud、Azure HPC、Batch に仮想マシンを作成することができます。

ユーザー アクセス

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

Azure Batch のセキュリティ

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

Azure CycleCloud セキュリティ

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

コストの最適化

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

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

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

自動スケール

自動スケールを使用すると、ジョブを送信したとき、またはジョブがアクティブな場合にのみ、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 などの低コストのストレージ ソリューションに存在できます。

さらに、HPC ストレージ システムをオンデマンドでセットアップして、Blob Storage などの低コストのストレージ サービスにデータを確実に同期できるようにすると便利な場合があります。 オンデマンド ストレージは、高パフォーマンスのストレージ システムがオフになっている場合に、Blob Storage にデータが保持されるようにするうえで役立ちます。 Managed Lustre と Azure 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 ワークロードに統合できます。 詳細については、「Azure HPC オンデマンド プラットフォーム」を参照してください。

パフォーマンス効率

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 の概要」をご覧ください。
  • Monitor は、VM インスタンスとストレージにボトルネックがあるかどうかを特定するための優れたツールです。
  • ストレージの調整により、アプリケーションの速度が大幅に低下し、パフォーマンスに影響が出る可能性があります。 調整は、ストレージ内の入出力操作が設定したスループット制限を超えると発生します。 Azure Storage サービスは、調整による問題があるかどうかを監視するための読み取りおよび書き込み操作のグラフを提供します。
  • Azure CycleCloud は、Monitor や Microsoft Cost Management ツールなどの Azure サービスと統合されます。 また、プラグ可能なアーキテクチャを介した外部サービスの監視もサポートしています。 詳細については、「監視」を参照してください。
  • さらに、Batch のユーザーにとって、Batch Explorer は Batch アプリケーションの作成、デバッグ、および監視を支援する豊富な機能を無料で使用できる、スタンドアロン クライアント ツールです。

次のステップ