Azure Virtual Machines ベースライン アーキテクチャ

この記事では、Azure Virtual Machines にデプロイされたワークロードの基本的な参照アーキテクチャについて説明します。

このアーキテクチャで想定されるワークロードの例は、別個の仮想マシン (VM) セットにデプロイされる、インターネットに接続された多階層 Web アプリケーションです。 VM は、Azure Virtual Machine Scale Sets デプロイの一部としてプロビジョニングされます。 このアーキテクチャは、次のシナリオで使用できます。

• プライベート アプリケーション。 これらのアプリケーションには、社内の基幹ビジネス アプリケーションや市販の商用ソリューションが含まれます。
• パブリック アプリケーション。 これらのアプリケーションは、インターネットに接続するアプリケーションです。 このアーキテクチャは、ハイパフォーマンス コンピューティング、ミッションクリティカルなワークロード、レイテンシの影響を大きく受けるアプリケーション、またはその他の特殊なユースケースには適していません。

このアーキテクチャの主な焦点はアプリケーションではありません。 代わりに、この記事では、アプリケーションが対話するインフラストラクチャ コンポーネントを構成およびデプロイするためのガイダンスについて説明します。 これらのコンポーネントには、コンピューティング、ストレージ、ネットワーク、監視コンポーネントが含まれます。

このアーキテクチャは、サービスとしてのインフラストラクチャ (IaaS) でホストされるワークロードの開始点として機能します。 コンピューティング インフラストラクチャに重点を置くため、データ層はこのガイダンスから意図的に除外されています。

記事のレイアウト

Architecture	設計上の決定	Well-Architected Framework のアプローチ
▪ アーキテクチャの図 ▪ ワークロード リソース ▪ サポート リソース ▪ ユーザー フロー	▪ VM 設計の選択肢 ▪ ディスク ▪ ネットワーク ▪ 監視 ▪ Update management	▪ 信頼性 ▪ セキュリティ ▪ コストの最適化

Architecture

このアーキテクチャの Visio ファイル をダウンロードします。

これらのリソースの詳細については、 「関連リソース」に記載されている Azure 製品ドキュメントを参照してください。

コンポーネント

このアーキテクチャは、ワークロード リソースとワークロードサポート リソースの両方に対するいくつかの Azure サービスで構成されています。 以下のセクションでは、それぞれのサービスとその役割について説明します。

ワークロード リソース

• Azure Virtual Machines は 、アプリケーションのコンピューティング リソースとして機能し、可用性ゾーン間で分散されます。 説明のために、Windows VM と Linux VM の両方の組み合わせが使用されます。

  [フレキシブル オーケストレーション] モードの Azure Virtual Machine Scale Sets は、VM のプロビジョニングと管理に使用されます。

  サンプル アプリケーションは 2 つの層で表すことができ、それぞれが独自のコンピューティングを必要とします。

  • フロントエンドは Web サーバーを実行し、ユーザーの要求を受け取ります。
  • バックエンドは、ビジネス ロジックが実行される単一のエンドポイントを公開する Web API として機能する別の Web サーバーを実行します。

  フロントエンド VM にはデータ ディスク (プレミアム_LRS) が接続されており、これを使用してステートレス アプリケーションをデプロイできます。 バックエンド VM は、操作の一環としてデータを Premium_ZRS ローカル ディスク に保存します。 このレイアウトは、フロントエンドおよびバックエンドのコンピューティングからの状態を保存するためのデータベース層を含めるように拡張できます。 その階層は、このアーキテクチャの範囲外です。

• Azure Virtual Network は、すべてのワークロード リソースにプライベート ネットワークを提供します。 ネットワークはサブネットにセグメント化され、分離境界として機能します。

• Azure Application Gateway は、フロントエンド サーバーに要求をルーティングする単一のイングレス ポイントです。 選択した SKU には、セキュリティを強化するための統合 Azure Web Application Firewall (WAF) が含まれています。

• 内部 Azure Load Balancer は 、フロントエンド層からバックエンド サーバーにトラフィックをルーティングします。

• Azure Load Balancer Standard SKU は、3 つのパブリック IP アドレスを使用して VM への送信インターネット アクセスを提供します。

• Azure Key Vault には 、エンドツーエンドのトランスポート層セキュリティ (TLS) 通信に使用される認定資格証が格納されます。 アプリケーション シークレットにも使用できます。

リソースをサポートするワークロード

• Azure Bastion は、安全なプロトコルを介して VM への操作アクセスを提供します。

• Azure Application Insights は、アプリケーションからログとメトリックを収集します。 アプリケーションはこのアーキテクチャの焦点ではないので、実装ではログ収集は示されていません。

• Log Analytics は、Azure リソースと Application Insights からログとメトリックを収集する監視データ シンクです。 ストレージ アカウントは、ワークスペースの一部としてプロビジョニングされます。

ユーザー フロー

ワークロード リソースを操作するユーザーには、 ワークロード ユーザー と オペレーターの 2 種類があります。 これらのユーザーのフローは、前のアーキテクチャ図に示されています。

ワークロード ユーザー

1. ユーザーは、Application Gateway の公開パブリック IP アドレスを使用して Web サイトにアクセスします。

2. Application Gateway は HTTPS トラフィックを受信し、WAF 検査用の外部証明書を使用してデータを復号化し、フロントエンドへの転送用に内部ワイルドカード証明書を使用してデータを再暗号化します。

3. Application Gateway は、フロントエンド VM 全体でトラフィックのバランスをとり、要求をフロントエンド VM に転送します。

4. 選択されたフロントエンド VM は、個々の VM の IP ではなく、ロードバランサーのプライベート IP アドレスを使用してバックエンド VM と通信します。 この通信も内部ワイルドカード証明書を使用して暗号化されます。

5. バックエンド VM は、内部証明書を使用して要求を復号化します。 バックエンドは要求を処理した後、結果をフロントエンドに返し、結果を Application Gateway に返し、最後に結果をユーザーに返します。

Operator

このアーキテクチャの VM ではオペレーターによる直接アクセスが必要になる場合がありますが、自動化によってリモート アクセスを最小限に抑え、そのアクセスを監視することをお勧めします。 アクセスは、問題解決の状況、トラブルシューティング、または自動デプロイ プロセスの一環のためである場合があります。 このアーキテクチャには、コントロール プレーン アクセス用のパブリック IP がありません。 Azure Bastion はサーバーレス ゲートウェイとして機能し、SSH または RDP 経由で VM にアクセスする操作を可能にします。 このセットアップにより、安全で効率的なアクセス管理が保証されます。

1. オペレーターは Azure portal または Azure CLI にサインインします。
2. オペレーターは Azure Bastion サービスにアクセスし、目的の VM にリモート接続します。

VM 設計の選択肢

SKU を選択するときは、ベースライン パフォーマンスの期待値を設定することが重要です。 次のようないくつかの特性が意思決定プロセスに影響します。

• CPU、メモリ、ディスクの 1 秒あたりの入出力操作 (IOPS)。
• プロセッサ アーキテクチャ。
• オペレーティング システム (OS) イメージ サイズ

たとえば、Intel プロセッサ マシンを必要とするオンプレミス環境からワークロードを移行する場合は、Intel プロセッサをサポートする VM SKU を選択します。

サポートされている VM SKU の詳細については、 「Azure の仮想マシンのサイズ」を参照してください。

ブートストラップ

多くの場合、VM をブートストラップする必要があります。これは、アプリケーションを実行するために VM を準備して調整するプロセスです。 一般的なブートストラップ タスクには、証明書のインストール、リモートアクセスの構成、パッケージのインストール、OS 構成の調整と強化、データ ディスクのフォーマットとマウントが含まれます。 遅延や手動による介入なしでアプリケーションを VM で起動できるように、ブートストラップ プロセスを可能な限り自動化することが重要です。 自動化に関する推奨事項は次のとおりです。

• 仮想マシン拡張機能。 これらの拡張機能は、Infrastructure-as-Code (IaC) デプロイによって管理される Azure Resource Manager オブジェクトです。 このようにして、あらゆる失敗はデプロイの失敗として報告され、アクションを実行できます。 ブートストラップのニーズを満たす拡張機能がない場合は、カスタム スクリプトを作成します。 Azure カスタム スクリプト拡張機能を介してスクリプトを実行することをお勧めします。

  VM に機能を自動的にインストールまたは構成するために使用できる他の拡張機能をいくつか紹介します。

  • Azure Monitor エージェント (AMA) は、ゲスト OS から監視データを収集し、Azure Monitor に配信します。
  • Azure カスタム スクリプト拡張機能 (Windows、 Linux) バージョン 2 は、スクリプトをダウンロードし、Azure Virtual Machines (VM) 上で実行します この拡張機能は、展開後の構成の自動化、ソフトウェアのインストール、その他の構成タスクや管理タスクに役立ちます。
  • Azure Key Vault 仮想マシン拡張機能 (Windows、 Linux) では、変更を検出し、対応する認定資格証をインストールすることで、Key Vault に格納されている認定資格証の自動更新が提供されます。
  • Azure Virtual Machine Scale Sets が自動ローリング アップグレードを実行する場合は、 Virtual Machine Scale Sets を使用した Application Health 拡張機能 が重要です。 Azure は、個々のインスタンスの正常性監視に依存して更新を実行します。 また、拡張機能を使用して、スケールセット内の各インスタンスのアップロードの正常性を監視し、Automatic Instance Repairs を使用してインスタンスを修復することができます。
  • Microsoft Entra ID と OpenSSH (Windows、 Linux) は、Microsoft Entra 認証と統合されます。 コア認証プラットフォームと証明機関として Microsoft Entra ID を使用し、Microsoft Entra ID および OpenSSH 証明書ベースの認証によって Linux VM に SSH 接続できるようになりました。 この機能により、Azure ロールベースのアクセス制御 (RBAC) ポリシーと条件付きアクセス ポリシーを使用して、VM へのアクセスを管理できます。

• エージェント ベースの構成。 Linux VM では、さまざまな Azure が提供する VM イメージで cloud-init を介して使用できる軽量ネイティブの Desired State Configuration を使用できます。 構成は、IaC アーティファクトで指定され、バージョン管理されます。 独自の構成管理ソリューションを導入することもできます。 ほとんどのソリューションは、ブートストラップに対する宣言優先のアプローチに従っていますが、柔軟性のためにカスタムス クリプトをサポートしています。 一般的な選択肢には、Windows の Desired State Configuration、Linux の Desired State Configuration、Ansible、Chef、Puppet などが含まれます。 これらの構成ソリューションはすべて、VM 拡張機能と組み合わせることで、、両方のベストのエクスペリエンスを得ることができる。

リファレンス実装では、すべてのブートストラップは、VM 拡張機能と、データ ディスクのフォーマットとマウントを自動化するためのカスタム スクリプトを含む、カスタム スクリプトを通じて実行されます。

詳細については、「Well-Architected Framework: RE:02 - 自動化設計の推奨事項」を参照してください。

VM 接続

VM と特定の仮想ネットワーク内の他のデバイス間のプライベート通信を可能にするために、VM のネットワークインターフェイスカード (NIC) が仮想ネットワークのサブネットの 1 つに接続されます。 VM に複数の NIC が必要な場合は、VM サイズごとに NIC の最大数が定義されていることに注意してください。

ワークロードで仮想ネットワーク内の VM 間の低遅延通信が必要な場合は、Azure VM NIC でサポートされている高速ネットワークを検討します。 詳細については、 「高速ネットワークの利点」を参照してください。

Virtual Machine Scale Sets のフレキシブル オーケストレーション

VM は、 フレキシブル オーケストレーションを使用して Virtual Machine Scale Sets の一部としてプロビジョニングされます。 Virtual Machine Scale Sets は、ビジネス ニーズを満たすために使用される VM の論理グループです。 グループ内の VM のタイプは、同一であっても異なっていてもかまいません。 標準の Azure VM API とコマンドを使用して、マシン、ネットワーク インターフェイス、ディスクのライフサイクルを管理できます。

フレキシブル オーケストレーション モードにより、大規模な運用が容易になり、詳細なスケーリングの決定が容易になります。

障害ドメイン構成は、物理ハードウェアの障害、ネットワークの停止、または停電の影響を制限するために必要です。 スケール セットを使用すると、Azure は、単一のハードウェアまたはインフラストラクチャの問題に対する回復性のために、障害ドメイン全体にインスタンスを均一に分散します。

インスタンスの分散を最大化し、回復性と可用性を向上させるために、障害ドメイン割り当てを Azure にやってもらうことをお勧めします。

ディスク

OS およびアプリケーション コンポーネントを実行するために、ストレージ ディスクが VM に接続されます。 OS には一時ディスクを使用し、データ ストレージにはマネージドディスクを使用することを検討してください。

Azure には、パフォーマンス、汎用性、コストに関するさまざまなオプションが用意されています。 ほとんどの実稼働ワークロードのプレミアム SSD から始めます。 選択は VM SKU によって異なります。 プレミアム SSD をサポートする SKU には、リソース名に s が含まれています (Dsv4 など)、 Dv4は含まれません。

容量、IOPS、スループットなどのメトリックを含むディスク オプションの詳細については、 「ディスクの種類の比較」を参照してください。

ディスクを選択するときは、ディスクの特性とパフォーマンスの期待値を考慮してください。

• VM SKU の制限。 ディスクは、接続されている VM 内で動作し、IOPS とスループットの制限があります。 ディスクが VM の制限を超えていないこと、またはその逆のことを確認してください。 アプリケーション コンポーネントを最適に実行するディスク サイズ、パフォーマンス、VM の機能 (コア、CPU、メモリ) を選択します。 オーバープロビジョニングはコストに影響するため避けてください。

• 構成の変更点。 VM の実行中に、ディスクのパフォーマンスと容量の構成を変更できます。 ただし、多くの変更ではディスク コンテンツの再プロビジョニングと再構築が必要となり、ワークロードの可用性に影響を与える可能性があります。 そのため、ディスクと VM SKU の選択を慎重に計画して、可用性への影響と再作業を最小限に抑えます。

• エフェメラル OS ディスク。 OS ディスクを エフェメラル ディスクとしてプロビジョニングします。 OS ファイルを永続化する必要がある場合にのみ、マネージド ディスクを使用します。 アプリケーション コンポーネントと状態を格納するためにエフェメラル ディスクを使用しないでください。

  エフェメラル OS ディスクの容量は、選択した VM SKU によって異なります。 OS イメージのディスク サイズが、SKU の使用可能なキャッシュまたは一時ディスクより小さいことを確認します。 一時ストレージの残りの領域を使用できます。

• ディスク パフォーマンス。 ピーク時の負荷に基づいてディスク領域を事前プロビジョニングすることは一般的ですが、ほとんどのワークロードではピーク時の負荷が維持されないため、使用率が低いリソースにつながる可能性があります。

  ワークロードの使用パターンを監視し、スパイクや持続的な高読み取り操作に注意し、これらのパターンを VM とマネージド ディスク SKU の選択に考慮します。

  パフォーマンス レベル を変更するか、一部のマネージド ディスク SKUで提供される バースト機能 を使用すると、オン デマンドでパフォーマンスを調整できます。

  オーバープロビジョニングを行うとバーストの必要性が減りますが、支払う対象の未使用の容量が発生する可能性があります。 最適な結果を得るには、両方の機能を組み合わせるのが理想的です。

• ワークロードのキャッシュを調整します。 アプリケーション コンポーネントの使用状況に基づいて、すべてのディスクのキャッシュ設定を構成します。

  読み取り操作を主に実行するコンポーネントには、高ディスク トランザクション整合性は必要ありません。 これらのコンポーネントは、読み取り専用キャッシュのメリットを利用できます。 高ディスク トランザクション整合性を必要とする書き込み負荷の高いコンポーネントでは、多くの場合キャッシュが無効になります。

  読み取り/書き込みキャッシュを使用すると、VM がクラッシュした場合にデータが失われる可能性があり、ほとんどのデータ ディスク シナリオでは推奨されません。

このアーキテクチャでは、次のことを行います。

• すべての VM の OS ディスクはエフェメラルであり、キャッシュ ディスク上にあります。

  フロントエンド (Linux) とバックエンド (Windows Server) のワークロード アプリケーションは、個々の VM 障害に対して耐久性があり、どちらも小さなイメージ (約 30 GB) を使用します。 このような属性により、リモート Azure ストレージ リソースに保存されている永続 OS ディスクではなく、VM ローカル ストレージ (キャッシュ パーティション) の一部として作成されたエフェメラル OS ディスクを使用できるようになります。 この状況では、OS ディスクのストレージ コストは発生せず、待機時間が短くなり、VM のデプロイ時間が短縮されるため、パフォーマンスも向上します。

• 各 VM には独自のプレミアム SSD P1 マネージド ディスクがあり、ワークロードに適したベース プロビジョニング済みスループットが提供されます。

ネットワークレイアウト

このアーキテクチャでは、ワークロードが 1 つの仮想ネットワークにデプロイされます。 ネットワーク制御はこのアーキテクチャの重要な部分であり、 「セキュリティ」 セクションで説明されています。

このレイアウトは、エンタープライズ トポロジと統合できます。 この例は、 「Azure ランディング ゾーンの仮想マシン ベースライン アーキテクチャ」に示されています。

仮想ネットワーク

ネットワーク レイアウトに関する最初の決定事項の 1 つは、ネットワーク アドレス範囲に関連しています。 容量計画フェーズ中に予想されるネットワークの増加に注意してください。 ネットワークは成長を維持するのに十分な規模にする必要があり、追加のネットワーク構成が必要になる場合があります。 たとえば、仮想ネットワークには、スケーリング操作の結果として生じる他の VM に対応できる容量が必要です。

逆に、アドレス空間のサイズを適切に設定します。 仮想ネットワークが大きすぎると、使用率が低くなる可能性があります。 仮想ネットワークが作成されると、アドレス範囲を変更できないことに注意してください。

このアーキテクチャでは、アドレス空間は /21 に設定されます。これは、予想される増加に基づく決定です。

サブネットの考慮事項

仮想ネットワーク内では、次に示すように、サブネットは機能とセキュリティの要件に基づいて分割されます。

• リバース プロキシとして機能する Application Gateway をホストするサブネット。 Application Gateway には専用のサブネットが必要です。
• バックエンド VM にトラフィックを分散するための内部ロード バランサーをホストするサブネット。
• ワークロード VM をホストするサブネット。1 つはフロントエンド用、もう 1 つはバックエンド用です。 これらのサブネットは、アプリケーションの層に従って作成されます。
• ワークロード VM への運用アクセスを容易にする Azure Bastion ホストのサブネット。 設計上、Azure Bastion ホストには専用サブネットが必要です。
• Azure Private Link 経由で他の Azure リソースにアクセスするために作成されたプライベート エンドポイントをホストするサブネット。 これらのエンドポイントには専用サブネットは必須ではありませんが、お勧めします。

仮想ネットワークと同様に、サブネットも適切なサイズにする必要があります。 たとえば、アプリケーションのスケーリング ニーズを満たすために、フレキシブル オーケストレーションでサポートされる VM の上限を適用できます。 ワークロード サブネットは、その制限に対応できる必要があります。

考慮すべきもう 1 つのユース ケースは、一時的な IP アドレスが必要になる可能性がある VM OS のアップグレードです。 同様のリソースをグループ化して、ネットワーク セキュリティ グループ (NSG) を介して意味のあるセキュリティ規則をサブネットの境界に適用できるようにすることで、適切なサイズ設定によって必要なレベルのセグメント化を実現できます。 詳細については、 「セキュリティ: セグメント化」を参照してください。

イグレス トラフィック

イングレス フローには、2 つのパブリック IP アドレスが使用されます。 1 つのアドレスは、リバース プロキシとして機能する Application Gateway 用です。 ユーザーはそのパブリック IP アドレスを使用して接続します。 リバース プロキシは、イングレス トラフィックを VM のプライベート IP に負荷分散します。 もう 1 つのアドレスは、Azure Bastion を介した運用アクセス用です。

このアーキテクチャの Visio ファイル をダウンロードします。

エグレス トラフィック

このアーキテクチャでは、VM インスタンスから定義されたアウトバウンド規則を持つ Standard SKU Load Balancer を使用します。 ゾーン冗長であるため、Load Balancer が選択されました。

このアーキテクチャの Visio ファイル をダウンロードします。

この構成では、ロード バランサーのパブリック IP を使用して、VN の送信インターネット接続を提供します。 アウトバウンド規則を使用すると、ソース ネットワーク アドレス変換 (SNAT) ポートを明示的に定義できます。 規則を使用すると、手動でのポート割り当てを使用して、この機能をスケーリングおよび調整できます。 バックエンド プール サイズと frontendIPConfigurations 数に基づき、SNAT ポートを手動で割り当てると、SNAT 不足を回避できます。

バックエンド インスタンスの最大数に基づいてポートを割り当てることをお勧めします。 許可されてる残りの SNAT ポート数より多いインスタンスが追加された場合、Virtual Machine Scale Sets スケーリング操作がブロックされるか、新しい VM が十分な数の SNAT ポートを取得できなくなる場合があります。

インスタンスあたりのポート数の計算方法は Number of front-end IPs * 64K / Maximum number of back-end instances です。

サブネットにアタッチされた Azure NAT Gateway リソースのデプロイなど、他にも使用できるオプションがあります。 もう 1 つのオプションは、ファイアウォールを通過するネクスト ホップとして、カスタム ユーザー定義ルート (UDR) を持つ Azure Firewall または別のネットワーク仮想アプライアンスを使用することです。 このオプションは、 「Azure ランディング ゾーンの仮想マシン ベースライン アーキテクチャ」に示されています。

DNS 解決

Azure DNS は、ワークロード VM に関連付けられた完全修飾ドメイン名 (FQDN) の解決など、すべての解決ユース ケースの基本サービスとして使用されます。 このアーキテクチャでは、VM は仮想ネットワーク構成で設定された DNS 値 (Azure DNS) を使用します。

Azure プライベートDNS ゾーンは、名前付きの Private Link リソースへのアクセスに使用されるプライベート エンドポイントへの要求を解決するために使用されます。

監視

このアーキテクチャには、ワークロードのユーティリティから切り離された監視スタックがあります。 主にデータ ソースとコレクションの側面に焦点を当てています。

メトリックとログはさまざまなデータ ソースで生成され、さまざまな高度での監視に関する分析情報が提供されます。

• 基になるインフラストラクチャとコンポーネント (VM、仮想ネットワーク、ストレージ サービスなど) が考慮されます。 Azure プラットフォーム ログは、Azure プラットフォーム内の操作とアクティビティに関する情報を提供します。

• アプリケーション レベル は、システムで実行されているアプリケーションのパフォーマンスと動作に関する分析情報を提供します。

Log Analytics ワークスペースは、Azure リソースと Application Insights からログとメトリックを収集するために使用される推奨の監視データ シンクです。

この画像は、インフラストラクチャとアプリケーションからデータを収集するためのコンポーネント、データシンク、分析と視覚化のためのさまざまな消費ツールを含むベースラインの監視スタックを示しています。 この実装では、Application Insights、VM ブート診断、Log Analytics などのいくつかのコンポーネントがデプロイされます。 その他のコンポーネントは、ダッシュボードやアラートなどの機能拡張オプションを示すために示されています。

このアーキテクチャの Visio ファイル をダウンロードします。

インフラストラクチャレベルの監視

次の表は、Azure Monitor が収集したログとメトリックへのリンクです。 使用可能なアラートは、ユーザーに影響を与える前に問題に事前に対処するのに役立ちます。

Azure リソース	メトリックとログ	警告
Application Gateway	Application Gateway のメトリックとログの説明	Application Gateway のアラート
Application Insights	Application Insights メトリックと Logging API	Application Insights のアラート
Azure Bastion	Azure Bastion メトリック
Key Vault	Key Vault のメトリックとログの説明	Key Vault のアラート
Standard Load Balancer	Load Balancer のログとメトリック	Load Balancer アラート
パブリック IP アドレス	パブリック IP アドレスのメトリックとログの説明	パブリック IP アドレス メトリック アラート
Virtual Network	仮想ネットワークのメトリックとログのリファレンス	仮想ネットワーク アラート
Virtual Machines と Virtual Machine Scale Sets	VM メトリックとログのリファレンス	VM のアラートとチュートリアル
Web アプリケーション ファイアウォール	Web Application Firewall のメトリックとログの説明	Web Application Firewall アラート

メトリックとログの収集コストの詳細については、 「Log Analytics のコスト計算とオプション」 および 「Log Analytics ワークスペースの価格」を参照してください。 ワークロードの本質、収集されるメトリックとログの頻度と数は、メトリックとログ収集費用に大きく影響します。

仮想マシン

Azure ブート診断 を使用すると、シリアル ログ情報とスクリーンショットを収集して、起動中の VM の状態を確認できます。 このアーキテクチャでは、Azure Portal と Azure CLI vm boot-diagnostics get-boot-log コマンドを使用してそのデータにアクセスできます。 データは Azure によって管理され、基になるストレージ リソースに対する制御やアクセスはありません。 ただし、ビジネス要件でより詳細な制御が必要な場合は、ブート診断を格納するために独自のストレージ アカウントをプロビジョニングできます。

VM Insights は、VM とスケール セットを効率的に監視する方法を提供します。 Log Analytics ワークスペースからデータを収集し、パフォーマンス データ トレンド用の事前定義されたワークブックを提供します。 このデータは、VM ごとに表示することも、複数の VM 間で集計することもできます。

Application Gateway と内部ロード バランサーは、正常性プローブを使用して、トラフィックを送信する前に VM のエンドポイントの状態を検出します。

ネットワーク

このアーキテクチャでは、フローに参加する複数のネットワーク コンポーネントからログ データを収集します。 これらのコンポーネントには、Application Gateway、ロード バランサー、Azure Bastion が含まれます。 また、仮想ネットワーク、NSG、パブリック IP アドレス、Private Link などのネットワーク セキュリティ コンポーネントも含まれます。

マネージド ディスク

ディスク メトリックはワークロードによって異なります。重要なメトリックの組み合わせが必要です。 監視では、これらの観点を組み合わせて、OS またはアプリケーションのスループットの問題を切り分ける必要があります。

• Azure プラットフォームの観点は、接続されているワークロードに関係なく、Azure サービスを示すメトリックを表します。 ディスク パフォーマンス メトリック (IOPS とスループット) は、VM に接続されているすべてのディスクについて個別に表示することも、まとめて表示することもできます。 ストレージ IO 使用率メトリックを使用して、潜在的なディスク上限に関するトラブルシューティングまたはアラートを生成します。 コストの最適化にバースティングを使用する場合は、クレジットの割合メトリックを監視して、さらなる最適化の機会を特定します。

• ゲスト OS の観点は、基となるディスク テクノロジに関係なく、ワークロード オペレーターが表示するメトリックを表します。 VM 分析情報は、接続されているディスクの主要メトリック (使用される論理ディスク領域など) と、ディスク IOPS とスループットに関する OS カーネルの観点に推奨されます。

アプリケーションレベルの監視

Application Insights は、リファレンス実装では使用されていませんが、拡張性を目的として Application Performance Management (APM) としてプロビジョニングされます。 Application Insights は、アプリケーションからデータを収集し、そのデータを Log Analytics ワークスペースに送信します。 また、ワークロード アプリケーションからのデータを視覚化することもできます。

アプリケーション正常性拡張機能 は、スケール セット内の各 VM インスタンスのバイナリ正常性状態を監視し、スケール セットの自動インスタンス修復を使用して必要に応じてインスタンスの修復を実行するために VM にデプロイされます。 Application Gateway と内部 Azure ロード バランサーの正常性プローブと同じファイルをテストして、アプリケーションが応答しているかどうかをチェックします。

Update Management

VM は、ワークロードのセキュリティ体制を弱めないように、定期的に更新およびパッチを適用する必要があります。 早期検出とパッチ適用には、自動および定期 VM 評価をお勧めします。

インフラストラクチャの更新

Azure では、定期的にそのプラットフォームを更新して、仮想マシンのホスト インフラストラクチャの信頼性、パフォーマンス、セキュリティの強化に努めています。 これらの更新は、ホスティング環境のソフトウェア コンポーネントのパッチ適用から、ネットワーク コンポーネントのアップグレード、ハードウェアのデコミッションまで、広い範囲に及びます。 更新プロセスの詳細については、 「Azure での仮想マシンのメンテナンス」を参照してください。

更新に再起動が必要ない場合、ホストの更新中に VM が一時停止されるか、すでに更新されたホストに VM がライブ マイグレートされます。 メンテナンスで再起動が必要な場合は、計画メンテナンスが通知されます。 Azure には、都合のよいときにメンテナンスを開始できる時間枠も用意されています。 セルフメンテナンス時間枠と利用可能なオプションの構成方法については、 「計画済みメンテナンス通知の処理」を参照してください。

一部のワークロードでは、メンテナンスによる VM のフリーズや数秒の切断でも許容できない場合があります。 ゼロインパクトやリブートレスの更新を含むすべてのメンテナンス作業をより詳細に制御するには、 [メンテナンス管理機能]を使用します。 メンテナンス構成を作成すると、すべてのプラットフォームの更新をスキップして、都合の良いときに更新を適用するオプションが提供されます。 このカスタム構成が設定されている場合、Azure では、再起動なしの更新プログラムを含め、すべてのゼロインパクト更新がスキップされます。 詳しくは、 「メンテナンス構成によるプラットフォームの更新の管理」を参照してください。

オペレーティング システム (OS) イメージのアップグレード

OS のアップグレードを行うときは、テスト済みのゴールデン イメージを使用します。 カスタム イメージを発行するには、Azure Shared Image Gallery と Azure Compute Gallery を使用することを検討します。 パブリッシャーによって新しいイメージが公開されるたびに、インスタンスのバッチをローリング方式でアップグレードするプロセスを用意する必要があります。

VM イメージが寿命に達する前に廃棄して、サーフェイス領域を削減します。

自動化プロセスでは、追加の容量でオーバープロビジョニングを考慮する必要があります。

Azure Update Management は、Azure の Windows と Linux Virtual Machines の OS 更新を管理します。Azure Update Manager は、SaaS ソリューションを使用して、Azure、オンプレミス、マルチクラウド環境で、Windows と Linux マシン向けソフトウェア更新を管理、統制します。

ゲスト OS パッチ適用

Azure VM には、VM ゲストのパッチ オプションがあります。 このサービスを有効にすると、VM が定期的に評価され、利用可能なパッチが分類されます。 保留中のパッチを日次評価できるように、評価モードを有効にすることをお勧めします。 オンデマンド評価は実行できますが、パッチの適用はトリガーされません。 [評価] モードが有効になっていない場合は、保留中の更新プログラムを手動で検出する方法があります。

[重大] または [セキュリティ] として分類されたパッチのみが、すべての Azure リージョンに自動適用されます。 他のパッチを適用するカスタム更新管理プロセスを定義します。

統制については、 Virtual Machine Scale Sets Azure Policy での OS イメージ パッチ自動適用 を検討します。

パッチの自動適用により、システムに負担がかかる場合があり、VM はリソースを使用し、更新中に再起動する可能性があるため、システムが中断される場合があります。 負荷管理にはオーバー プロビジョニングが推奨されます。 同時更新を回避するために異なる可用性ゾーンに VM をデプロイし、ゾーンごとに少なくとも 2 つのインスタンスを維持して、高可用性を実現します。 同じリージョン内の VM は異なるパッチを受け取る可能性があり、時間をかけて調整する必要があります。

オーバー プロビジョニングに伴うコストのトレードオフに注意してください。

正常性チェックは、VM ゲストの自動パッチ適用の一部として含まれています。 これらのチェックでは、パッチの適用が成功したかどうかを確認し、問題を検出します。

パッチを適用するためのカスタム プロセスがある場合は、パッチソースにプライベート リポジトリを使用します。 これにより、更新プログラムがパフォーマンスやセキュリティに悪影響を及ぼさないことを確認するために、パッチのテストをより適切に制御できます。

詳細については、 「Azure VM 用 VM ゲスト自動パッチ」を参照してください。

信頼性

このアーキテクチャでは、可用性ゾーンを基本要素として使用して、信頼性の問題に対処します。

この設定では、個々の VM が 1 つのゾーンに関連付けられます。 障害が発生した場合、Virtual Machine Scale Sets を使用すると、これらの VM を他の VM インスタンスに簡単に置き換えることができます。

このアーキテクチャ内の他のすべてのコンポーネントは次のいずれかです。

• ゾーン冗長は、Application Gateway やパブリック IP など、高可用性のために複数のゾーンにレプリケートされることを示します。
• ゾーンの回復性は、Key Vault などのゾーン障害に耐えることができることを意味します。
• Microsoft Entra ID など、リージョン間またはグローバルに利用可能なリージョンまたはグローバル リソース。

ワークロードの設計では、アプリケーション コード、インフラストラクチャ、および運用に信頼性の保証を組み込む必要があります。 次のセクションでは、ワークロードが障害に対して回復性があり、インフラストラクチャ レベルで障害が発生した場合に復旧できることを確認するためのいくつかの方法を示します。

アーキテクチャで使用される方法は、 Azure Well-Architected Framework で提供される信頼性設計レビュー チェックリスト に基づいています。 セクションには、そのチェックリストからの推奨事項で注釈が付けられます。

アプリケーションはデプロイされないため、アプリケーション コードの回復性はこのアーキテクチャの範囲を超えています。 チェックリスト内のすべての推奨事項を確認し、該当する場合はワークロードで採用することをお勧めします。

ユーザー フローごとの信頼性保証に優先順位を付ける

ほとんどの設計では、複数のユーザー フローがあり、それぞれに独自のビジネス要件があります。 これらのフローのすべてが最高レベルの保証を必要とするわけではないため、信頼性戦略としてセグメント化することをお勧めします。 各セグメントは個別に管理できるため、1 つのセグメントが他のセグメントに影響を与えないようにし、各層で適切なレベルの回復性を提供できます。 このアプローチにより、システムも柔軟になります。

このアーキテクチャでは、アプリケーション層によってセグメント化が実装されます。 フロントエンド層とバックエンド 層に対して個別のスケール セットがプロビジョニングされます。 この分離により、各層の独立したスケーリングが可能になり、その特定の要件に基づいて設計パターンを実装でき、その他の利点も期待できます。

「Well-Architected Framework: RE:02 - フローの識別と評価に関する推奨事項」を参照してください。

潜在的な障害ポイントを特定する

すべてのアーキテクチャは、障害の影響を受けやすくなります。 障害モード分析を実行すると、障害を予測し、軽減策を準備できます。 このアーキテクチャの潜在的な障害ポイントを次に示します。

コンポーネント	リスク	Likelihood	効果/軽減策/メモ	Outage
Microsoft Entra ID	誤った構成	Medium	Ops ユーザーはサインインできません。 ダウンストリーム効果はありません。 ヘルプ デスクは、ID チームに構成の問題を報告します。	なし
Application Gateway	誤った構成	Medium	デプロイ中に誤った構成を見つける必要があります。 構成の更新中にこれらのエラーが発生した場合、DevOps チームは変更をロールバックする必要があります。 v2 SKU を使用するデプロイのほとんどは、プロビジョニングに 6 分ほどかかります。 ただし、デプロイの種類によっては、それよりも時間がかかることがあります。 たとえば、多数のインスタンスを含む複数の可用性ゾーン全体にわたるデプロイには 6 分を超える時間がかかることがあります。	完全
Application Gateway	DDoS 攻撃	Medium	中断の可能性があります。 Microsoft は DDoS (L3 および L4) 保護を管理します。 L7 攻撃による影響の潜在的なリスク。	完全
Virtual Machine Scale Sets	サービス停止	低	自動修復をトリガーする異常な VM インスタンスがある場合、ワークロードが停止する可能性があります。 修復は Microsoft に依存しています。	潜在的な停止
Virtual Machine Scale Sets	可用性ゾーンの停止	低	影響しません。 スケール セットはゾーン冗長としてデプロイされます。	なし

「Well-Architected Framework: RE:03 - 障害モード分析の実行に関する推奨事項」を参照してください。

信頼性のターゲット

設計上の決定を行うには、ワークロードの複合サービス レベル目標 (SLO) など、信頼性の目標を計算することが重要です。 これを行うには、アーキテクチャで使用される Azure サービス提供のサービス レベル アグリーメント (SLA) を理解する必要があります。 ワークロード SLO は、Azure で保証されている SLA より高くすることはできません。 VM とその依存関係、ネットワーク、ストレージ オプションから、各コンポーネントを慎重に調べます。

主な目標は、類似する複合 SLO を提供することである計算例を次に示します。 これは大まかなガイドラインですが、似たような結果となります。 アーキテクチャを変更しない限り、同じフローに対してより高い最大複合 SLO を取得しないでください。

操作フロー

コンポーネント	SLO
Microsoft Entra ID	99.99%
Azure Bastion	99.95%

複合 SLO: 99.94% | 年間ダウンタイム: 0d 5h 15m 20s

アプリ ユーザー フロー

コンポーネント	SLO
Application Gateway	99.95%
Azure Load Balancer (内部)	99.99%
Premium Storage を使用したフロントエンド VM (複合 SLO)	99.70%
Premium Storage を使用したバックエンド VM (複合 SLO)	99.70%

複合 SLO: 99.34% | 年間ダウンタイム: 2d 9h 42m 18s

前の例では、VM と依存関係の信頼性 (VM に関連付けられているディスクなど) が含まれています。 ディスク ストレージに関連付けられている SLA は、全体的な信頼性に影響します。

複合 SLO を計算する際には、いくつかの課題があります。 サービスの階層によって SLA が異なる場合があり、多くの場合、信頼性目標を設定する金銭的な裏付けのある保証が含まれていることに注意することが重要です。 最後に、SLA が定義されていないアーキテクチャのコンポーネントが存在する可能性があります。 たとえば、ネットワークの観点から見ると、NIC と仮想ネットワークには独自の SLA がありません。

ビジネス要件とその目標を明確に定義し、計算に組み込む必要があります。 組織によって課されるサービスの制限とその他の制約に注意してください。 サブスクリプションを他のワークロードと共有すると、VM で使用可能なリソースに影響する可能性があります。 ワークロードでは、VM で使用可能な限られた数のコアを使用できる場合があります。 サブスクリプションのリソース使用量を理解することは、VM をより効果的に設計するのに役立ちます。

信頼性目標の定義については、「Well-Architected Framework: RE:04 - 信頼性目標の定義に関する推奨事項」を参照してください。

冗長性

このアーキテクチャでは、複数のコンポーネントにゾーン冗長を使用します。 各ゾーンは、独立した電源、冷却手段、ネットワークを備えた 1 つ以上のデータセンターで構成されています。 インスタンスを別々のゾーンで実行すると、データセンターの障害からアプリケーションが保護されます。

• Virtual Machine Scale Sets は、指定された数のインスタンスを割り当て、可用性ゾーンと障害ドメインに均等に分散します。 この分散は、推奨されている [最大拡散] 機能によって実現されます。 障害ドメイン全体に VM インスタンスを分散することで、すべての VM が同時に更新されないようにします。

  3 つの可用性ゾーンがあるシナリオを考えてみましょう。 3 つのインスタンスがある場合、各インスタンスは異なる可用性ゾーンに割り当てられ、別の障害ドメインに配置されます。 Azure では、各可用性ゾーンで一度に更新される障害ドメインは 1 つのみです。 ただし、3 つの可用性ゾーンの VM をホストする 3 つの障害ドメインが同時に更新される場合があります。 すべてのゾーンとドメインが影響を受けます。 各ゾーンに少なくとも 2 つのインスタンスがあると、更新中にバッファーを持つことができます。

• マネージド ディスクは、同じリージョン内の VM にのみ接続できます。 通常、それらの可用性は VM の可用性に影響します。 単一リージョンのデプロイでは、ゾーン障害に耐えられる冗長性を確保するようにディスクを構成できます。 このアーキテクチャでは、データ ディスクはバックエンド VM 上にゾーン冗長ストレージ (ZRS) を構成します。 可用性ゾーンを利用するには、復旧戦略が必要です。 復旧戦略とは、ソリューションを再デプロイすることです。 ゾーン障害から復旧する準備ができている代替可用性ゾーンでコンピューティングを事前プロビジョニングするのが理想的です。

• ゾーン冗長 Application Gateway または Standard Load Balancer では、1 つの IP アドレスを使用して複数のゾーン間で VM にトラフィックをルーティングできるため、ゾーン障害が発生した場合でも継続性を確保できます。 これらのサービスは、正常性プローブを使用して VM の可用性をチェックします。 リージョン内の 1 つのゾーンが運用可能であれば、他のゾーンで潜在的な障害がある場合でも、ルーティングは続行されます。 ただし、ゾーン間ルーティングでは、ゾーン内ルーティングと比較して待機時間が長くなる可能性があります。

  このアーキテクチャで使用されるすべてのパブリック IP はゾーン冗長です。

• Azure では、Key Vault などの信頼性を高めるゾーン回復性の高いサービスが提供されています。

• Azure グローバル リソースは常に利用可能であり、必要に応じて、基本 ID プロバイダー、Microsoft Entra ID など、別のリージョンに切り替えることができます。

「Well-Architected Framework: RE:05 - 冗長設計に関する推奨事項」を参照してください。

スケーリング戦略

サービス レベルの低下や障害を防ぐには、信頼性の高いスケーリング操作を確保します。 ワークロードを水平方向 (スケールアウト)、垂直方向 (スケールアップ) にスケーリングするか、両方の方法を組み合わせて使用します。 Azure Monitor Autoscale を使用すると、必要以上の容量を割り当てたり、不要な費用を発生させることなく、アプリケーションの需要をサポートするのに十分なリソースをプロビジョニングできます。

Autoscale を使用すると、時間、スケジュール、メトリックなど、さまざまなイベントの種類に基づいて異なるプロファイルを定義できます。 メトリックベースのプロファイルでは、組み込みのメトリック (ホストベース) またはより詳細なメトリック (ゲスト内 VM メトリック) を使用できます。このメトリックを収集するには、Azure Monitor エージェントをインストールする必要があります。 すべてのプロファイルには、スケールアウト (増加) とスケールイン (減少) のルールが含まれています。 設計されたプロファイルに基づいてさまざまなスケーリング シナリオをすべて調べ、一連の反対のスケール イベントを引き起こす可能性のあるループ条件を評価することを検討します。 Azure Monitor は、再びスケーリングする前にクールダウン期間を待って、この状況を軽減しようとします。

フレキシブル モードの Azure Virtual Machine Scale Sets は異種環境をサポートしていますが、複数のプロファイルの自動スケールはサポートしていません。 複数の種類の VM で自動スケールを使用する場合は、別のスケール セットを作成して個別に管理することを検討してください。

ブートストラップ、Graceful Shutdown、ワークロードとそのすべての依存関係のインストール、VM インスタンスの作成または削除時のディスク管理など、その他の側面を考慮してください。

ステートフル ワークロードでは、ワークロード インスタンスを超えて稼働する必要があるマネージド ディスクの追加管理が必要になる場合があります。 ワークロードのデータの整合性、同期、レプリケーション、整合性を確保するために、スケーリング イベント配下でデータ管理用ワークロードを設計します。 このようなシナリオでは、 事前設定されたディスクをスケール セットに追加することを検討します。 データにアクセスするときのボトルネックを防ぐためにスケーリングを使用するユース ケースでは、パーティションとシャーディングを計画します。 詳細については、 「自動スケールのベスト プラクティス」を参照してください。

「Well-Architected Framework: RE:06 - 信頼性の高いスケーリング戦略の設計に関する推奨事項」を参照してください。

自己復旧性と回復性

VM の障害からの復旧を自動化するために、Virtual Machine Scale Sets で [インスタンスの自動修復] が有効になっています。 応答しない VM とアプリケーションの検出をサポートするために、 [アプリケーション正常性拡張機能] が VM にデプロイされます。 これらのインスタンスでは、修復アクションが自動的にトリガーされます。

自己修復と自己保存については、「Well-Architected Framework: 自己修復と自己保存に関する推奨事項」を参照してください。

セキュリティ

このアーキテクチャは、 Azure Well-Architected Framework で提供されるセキュリティ設計レビュー チェックリスト に示されているセキュリティ保証の一部を示しています。 セクションには、そのチェックリストからの推奨事項で注釈が付けられます。

セキュリティは技術的な制御のみを指すわけではありません。 セキュリティの柱の運用面を理解するには、チェックリスト全体に従うことをお勧めします。

セグメント化

• ネットワークのセグメント化。 ワークロード リソースは、インターネットからの分離を提供する仮想ネットワークに配置されます。 仮想ネットワーク内では、サブネットを信頼境界として使用できます。 1 つのサブネットでトランザクションを処理するために必要な関連リソースを併置します。 このアーキテクチャでは、仮想ネットワークは、アプリケーションの論理的なグループ化と、ワークロードの一部として使用されるさまざまな Azure サービスの目的に基づいてサブネットに分割されます。

  サブネットのセグメント化の利点は、サブネットを送受信するトラフィックを制御する境界にセキュリティ制御を配置できるため、ワークロード リソースへのアクセスを制限できることです。

• ID のセグメント化。 タスクを実行するのに十分なアクセス許可を持つ異なる ID に個別のロールを割り当てます。 このアーキテクチャでは、 Microsoft Entra ID が管理する ID を 使用して、リソースへのアクセスをセグメント化します。

• リソースのセグメント化。 アプリケーションは階層別に個別のスケール セットに分割され、アプリケーション コンポーネントが併置されないようにします。

「Well-Architected Framework: SE:04 - セグメント化戦略の構築に関する推奨事項」を参照してください。

ID 管理とアクセス管理

ユーザーとサービスの両方の認証と承認には、 Microsoft Entra ID をお勧めします。

VM へのアクセスには、Microsoft Entra ID 認証によって制御され、セキュリティ グループによってサポートされるユーザー アカウントが必要です。 このアーキテクチャでは、Microsoft Entra ID 認証拡張機能をすべての VM にデプロイすることでサポートが提供されます。 人間のユーザーは、組織の Microsoft Entra ID テナントで会社の ID を使用することをお勧めします。 また、サービス プリンシパル ベースのアクセスが Functions 間で共有されないようにします。

VM などのワークロード リソースは、他のリソースに割り当てられたマネージド ID を使用して自身を認証します。 これらの ID は、Microsoft Entra ID サービス プリンシパルに基づいて自動的に管理されます。

たとえば、Key Vault 拡張機能は VM にインストールされ、認定資格証が配置された VM が起動します。 このアーキテクチャでは、 ユーザー割り当てマネージド ID が Application Gateway、フロントエンド VM、およびバックエンド VM によって Key Vault にアクセスするために使用されます。 これらのマネージド ID はデプロイ時に構成され、Key Vault に対する認証に使用されます。 Key Vault のアクセス ポリシーは、上記のマネージド ID からの要求のみを受け入れるように構成されます。

ベースライン アーキテクチャでは、システム割り当てマネージド ID とユーザー割り当てマネージド ID の組み合わせを使用します。 これらの ID は、他の Azure リソースにアクセスするときに承認のために Microsoft Entra ID を使用するために必要です。

「Well-Architected Framework: SE:05 - ID およびアクセス管理に関する推奨事項」を参照してください。

ネットワーク管理

• イングレス トラフィック。 ワークロード VM はパブリック インターネットに直接公開されません。 各 VM には、それぞれプライベート IP が含まれます。 ワークロード ユーザーは、Application Gateway のパブリック IP アドレスを使用して接続します。

  Application Gateway と統合された Web Application Firewall を通じて、より多くのセキュリティが提供されます。 受信トラフィックを検査し、適切なアクションを実行できるルールがあります。 WAF は、既知の攻撃を防ぐ OOpen Web Application Security Project (OWASP) の脆弱性を追跡します。

• エグレス トラフィック。 VM サブネットの送信 NSG 規則を除き、送信トラフィックに対する制御はありません。 すべての送信インターネット トラフィックは、単一のファイアウォールを通過することをお勧めします。 このファイアウォールは、通常、組織によって提供される中央サービスです。 このユース ケースは、 「Azure ランディング ゾーンの仮想マシン ベースライン アーキテクチャ」に示されています。

• 東西のトラフィック。 サブネット間のトラフィック フローは、詳細なセキュリティ規則を適用することによって制限されます。

  ネットワーク セキュリティ グループ (NSG) は、IP アドレス範囲、ポート、プロトコルなどのパラメーターに基づいてサブネット間のトラフィックを制限するために配置されます。 アプリケーション セキュリティ グループ (ASG) は、フロントエンド VM とバックエンド VM に配置されます。 これらは NSG と共に使用され、VM との間のトラフィックをフィルター処理します。

• 運用トラフィック。 ワークロードへの安全な運用アクセスは Azure Bastion を介して提供することをお勧めします。これにより、パブリック IP が不要になります。 このアーキテクチャでは、その通信は SSH 経由であり、Windows VM と Linux VM の両方でサポートされています。 Microsoft Entra ID は、対応する VM 拡張機能を使用して、両方の種類の VM の SSH と統合されます。 この統合により、オペレーターの ID を Microsoft Entra ID で認証および承認できます。

  または、別の VM をジャンプ ボックスとして使用し、独自のサブネットにデプロイして、選択した管理者ツールとトラブルシューティング ツールをインストールすることもできます。 オペレーターは、Azure Bastion ホストを介してジャンプ ボックスにアクセスします。 次に、ジャンプ ボックスからロード バランサーの背後にある VM にサインインします。

  このアーキテクチャでは、運用トラフィックは NSG ルールを使用してトラフィックを制限して保護され 、VM で Just-In-Time (JIT) VM アクセス が有効になります。 Microsoft Defender for Cloud のこの機能により、選択したポートへの一時的な受信アクセスが許可されます。

  セキュリティを強化するには、 Microsoft Entra Privileged Identity Management (PIM)を使用します。 PIM は Microsoft Entra ID 内のサービスで、組織内の重要なリソースへのアクセスを管理、制御、監視します。 PIM では、時間ベースおよび承認ベースのロールのアクティブ化を提供して、対象リソースに対する過剰、不要、または誤用であるアクセス許可のリスクを軽減します。

• Platform as a service (PaaS) サービスへのプライベート接続。 VM と Key Vault の間の通信は Private Link 経由です。 このサービスには、別のサブネットに配置されるプライベート エンドポイントが必要です。

• DDoS 保護。 Application Gateway と Azure Bastion Host によって公開されているパブリック IP で [Azure DDoS Protection] を有効にして、脅威を検出することを検討してください。 DDoS Protection では、Monitor 経由で、アラート、テレメトリ、分析も提供されます。 詳細については、「Azure DDoS Protection:ベスト プラクティスと参照アーキテクチャ」をご覧ください。

「Well-Architected Framework: SE:06 - ネットワークと接続に関する推奨事項」を参照してください。

暗号化

• 転送中のデータ。 ユーザーと Application Gateway パブリック IP 間のユーザー トラフィックは、外部認定資格証を使用して暗号化されます。 Application Gateway とフロントエンド VM 間、およびフロントエンド VM とバックエンド VM の間のトラフィックは、内部認定資格証を使用して暗号化されます。 どちらの認定資格証も Key Vault に格納されます。

  • app.contoso.com: 安全なパブリック インターネット トラフィックのためにクライアントと Application Gateway によって使用される外部証明書。
  • *.workload.contoso.com: 安全な内部トラフィックのためにインフラストラクチャ コンポーネントによって使用されるワイルドカード証明書。

• 保存データ。 ログ データは、VM に接続されているマネージド ディスクに格納されます。 そのデータは、Azure でプラットフォームによって提供される暗号化を使用して自動的に暗号化されます。

「Well-Architected Framework: SE:07 - データ暗号化に関する推奨事項」を参照してください。

シークレットの管理

このアーキテクチャの Visio ファイル をダウンロードします。

Key Vault は、TLS 認定資格証を含むシークレットの安全な管理を提供します。 このアーキテクチャでは、TLS 認定資格証は Key Vault に格納され、プロビジョニング プロセス中に Application Gateway と VM のマネージド ID によって取得されます。 初期セットアップ後、これらのリソースは、認定資格証が更新されたときにのみ Key Vault にアクセスします。

VM は、 Key Vault VM 拡張機能 を使用して、監視対象の認定資格証を自動更新します。 ローカル認定資格証ストアで変更が検出された場合、拡張機能は Key Vault から対応する認定資格証を取得してインストールします。 この拡張機能では、認定資格証コンテンツ タイプ PKCS #12 と PEM がサポートされています。

「Well-Architected Framework: SE:09 - アプリケーション シークレットの保護に関する推奨事項」を参照してください。

コストの最適化

ワークロードの要件は、コストの制約に留意して満たす必要があります。 アーキテクチャで使用される方法は、 Azure Well-Architected Framework で提供されるコスト最適化設計レビュー チェックリストに基づいています。 このセクションでは、コストを最適化するためのいくつかのオプションについて説明し、そのチェックリストからの推奨事項で注釈を付けます。

コンポーネントのコスト

汎用イメージを使用する代わりに、ワークロード用に最適化された VM イメージを選択します。 このアーキテクチャでは、Windows と Linux の両方に比較的小さな VM イメージが選択されます。それぞれのサイズは 30 GB です。 イメージが小さいと、ディスクを含む VM SKU も小さくなり、コストの削減、リソースの従量課金の削減、デプロイと起動時間の短縮につながります。 利点は、サーフェス領域が減少するため、セキュリティが強化されることです。

もう 1 つのコスト削減戦略として、サイズ制限を使用したログ ローテーションの実装が挙げられます。 これにより、小さなデータ ディスクを使用できるため、コストが削減される可能性があります。 このアーキテクチャの実装では、4 GB のディスクが使用されます。

エフェメラル OS ディスクを使用すると、コストの削減とパフォーマンスの向上にもつながります。 VM でプロビジョニングされたキャッシュ ディスクにインストールされているため、これらのディスクは、既に支払っている VM リソースを使用するように設計されています。 従来の永続ディスクに関連するストレージ コストが不要になります。 これらのディスクは一時的なものであるため、長期的なデータ ストレージに関連するコストは発生しません。

「Well-Architected Framework: CO:07 - コンポーネント費用の最適化に関する推奨事項」を参照してください。

フロー コスト

フローの重要度に基づいてコンピューティング リソースを選択します。 不確定な長さを許容するように設計されたフローの場合は、[Virtual Machine Scale Sets Flexible オーケストレーション] モードになっている Spot VM を使用することを検討します。 このアプローチは、優先順位の低い VM で優先順位の低いフローをホストする場合に有効です。 この戦略により、さまざまなフローの要件を満たしながら、コストを最適化できます。

「Well-Architected Framework: CO:09 - フロー コストの最適化に関する推奨事項」を参照してください。

スケーリング コスト

主なコスト ドライバーがインスタンス数である場合、VM のサイズまたはパフォーマンスを増やすことでスケールアップする方がコスト効率が高い可能性があります。 この方法により、いくつかの領域でコスト削減につながる可能性があります。

• ソフトウェア ライセンス。 VM が大きいほど、より多くのワークロードを処理できるため、必要なソフトウェア ライセンス数が減る可能性があります。
• メンテナンス時間: より少なく、より大きい VM は運用コストを削減できます。
• 負荷分散: VM の数が少ないほど、負荷分散のコストが削減される可能性があります。 たとえば、このアーキテクチャでは、前面の Application Gateway や中央の内部 Load Balancer など、複数のレイヤーの負荷分散があります。 より多くのインスタンスを管理する必要がある場合、負荷分散コストが増加します。
• Disk storage。 ステートフル アプリケーションがある場合は、より多くのインスタンスに接続されたマネージド ディスクが必要であり、ストレージのコストが増加します。

「Well-Architected Framework: CO:12 - スケーリング コストの最適化に関する推奨事項」を参照してください。

運用コスト

VM ゲストの自動パッチ適用により、手動パッチ適用のオーバーヘッドと関連するメインテナント コストが削減されます。 このアクションは、システムの安全性を高めるだけでなく、リソースの割り当てを最適化し、全体的なコスト効率が向上します。

「Well-Architected Framework: CO:13 - 人事の時間の最適化に関する推奨事項」を参照してください。

このシナリオのデプロイ

このリファレンス アーキテクチャのデプロイについては、GitHub を参照してください。

関連リソース

特定の Azure サービスの詳細については、「製品ドキュメント」を参照してください。

• Azure Virtual Machines
• Azure Virtual Machine Scale Sets
• Azure Virtual Network
• Azure Application Gateway Standard_v2
• Azure Load Balancer
• Azure Key Vault
• Azure Bastion
• Application Insights
• Log Analytics

次のステップ

データ層のオプションを示す IaaS 参照アーキテクチャを確認します。

• Azure の SQL Server を使用した Windows N 層アプリケーション