マルチリージョン負荷分散

このアーキテクチャは、HTTP(S) および HTTP(S) 以外のプロトコルを使用して、インターネットに接続するグローバル アプリケーション向けです。 ドメイン ネーム システム (DNS) ベースのグローバル負荷分散、2 つの形式のリージョン負荷分散、グローバル仮想ネットワーク ピアリングを備え、信頼性の高いアーキテクチャを作成します。 可用性ゾーンは、各リージョン内の回復性を提供し、マルチリージョンのデプロイでは、リージョンの停止からの回復性を提供します。 Azure Web Application Firewall と Azure Firewall は、複数のレイヤーでトラフィックを検査します。

アーキテクチャ

このセクションでは、受信 HTTP(S)、受信非 HTTP(S)、および送信要求のアーキテクチャを通過するトラフィックフローについて説明します。 各フローは、アーキテクチャが両方のリージョンのアプリケーション層間でトラフィックをルーティング、検査、分散する方法を示しています。

HTTP(S) の受信トラフィック フロー

HTTP(S) トラフィックは、アプリケーション層に到達する前に、Azure Application Gateway Web アプリケーション ファイアウォール (WAF) と Azure Firewall Premium Transport Layer Security (TLS) 検査を通過します。

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

1. Azure Traffic Manager は、DNS ベースのルーティングを使用して、2 つのリージョン間で受信トラフィックの負荷分散を行います。 Traffic Manager は、アプリケーションの DNS クエリを Application Gateway エンドポイントのパブリック IP アドレスに解決します。 Application Gateway インスタンスのパブリック エンドポイントは、HTTP(S) トラフィックの Traffic Manager のバックエンド エンドポイントとして機能します。 Traffic Manager は、選択したルーティング方法に基づいて DNS クエリを解決します。 ブラウザーまたはその他の HTTP クライアントがエンドポイントに直接接続します。 詳細については、「 優先順位のトラフィック ルーティング方法」を参照してください。

2. 可用性ゾーン間にデプロイされた Application Gateway インスタンスは、ブラウザーから HTTP(S) トラフィックを受信し、WAF はそのトラフィックを検査して Web 攻撃を検出します。 Application Gateway インスタンスは、トラフィックを内部ロード バランサーに転送し、それをフロントエンド仮想マシン (VM) に分散します。 このフローでは、Application Gateway がロード バランサーとして機能するため、Web サーバーの前に追加の内部ロード バランサーは必要ありません。 ただし、内部ロード バランサーは、HTTP (S) 以外のアプリケーションのフローとの整合性を確保するために設計に含まれています。

3. Application Gateway サブネット上のユーザー定義ルート (UDR) は、Azure Firewall Premium を介して Application Gateway とフロントエンド内部ロード バランサー間のトラフィックをリダイレクトします。 Azure Firewall Premium はゾーン冗長であり、セキュリティを強化するためにトラフィックに TLS 検査を適用します。 Azure Firewall が脅威を検出すると、パケットがドロップされます。 Azure Firewall が脅威を検出しない場合、トラフィックは宛先 Web 層の内部ロード バランサーに転送されます。

4. Web 層は、3 層アプリケーションの最初のレイヤーです。 これにはユーザー インターフェイス (UI) が含まれており、ユーザーの操作を解析します。 Web 層ロード バランサーは、3 つの可用性ゾーンすべてにまたがり、3 つの Web 層 VM にトラフィックを分散します。

5. Web 層 VM は、3 つの可用性ゾーンすべてにまたがり、専用の内部ロード バランサーを介してビジネス層と通信します。

6. ビジネス層は、ユーザーの操作を処理し、次の手順を決定します。 Web 層とデータ層の間に配置されます。 ビジネス層内部ロード バランサーは、3 つの可用性ゾーン間でビジネス層 VM にトラフィックを分散します。 ビジネス層ロード バランサーは、Web 層ロード バランサーと同様にゾーン冗長です。

7. ビジネス層の VM は可用性ゾーンにまたがり、データベースの可用性グループ リスナーにトラフィックをルーティングします。

8. データ層は、アプリケーション データ (通常はデータベース、オブジェクト ストレージ、またはファイル共有) を格納します。 このアーキテクチャには、Azure Virtual Machines 上の SQL Server が 3 つの可用性ゾーンに分散されています。 各 SQL Server VM を 別々のサブネットに配置して Always On 可用性グループを使用します。 マルチサブネットデプロイでは、 可用性グループ リスナー はトラフィックをレプリカに直接ルーティングでき、Azure ロード バランサーや分散ネットワーク名 (DNN) は必要ありません。

HTTP(S) 以外の受信トラフィック フロー

一部のワークロードでは、ビジネス パートナーからのファイル ベースのデータ インジェストや従来の伝送制御プロトコル (TCP) ベースの統合のために、セキュリティで保護されたファイル転送プロトコル (SFTP) など、HTTP (S) 以外のプロトコル経由のトラフィックを受け入れます。 HTTP (S) 以外のトラフィックは、宛先ネットワーク アドレス変換 (DNAT) と検査のために Azure Firewall に直接ルーティングされ、Application Gateway をバイパスします。

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

1. Traffic Manager では、DNS ベースのルーティングを使用して、2 つのリージョン間で着信トラフィックを負荷分散します。 Traffic Manager は、アプリケーションの DNS クエリを、Azure エンドポイントのパブリック IP アドレスに解決します。 Azure Firewall のパブリック エンドポイントは、非 HTTP(S) トラフィックの Traffic Manager のバックエンド エンドポイントとして機能します。 Traffic Manager は、選択したルーティング方法に基づいて DNS クエリを解決します。 クライアントは、解決されたエンドポイントに直接接続します。 詳細については、「 優先順位のトラフィック ルーティング方法」を参照してください。

2. Azure Firewall Premium はゾーン冗長であり、セキュリティのために受信トラフィックを検査します。 Azure Firewall が脅威を検出すると、パケットがドロップされます。 検査が成功すると、Azure Firewall は受信パケットに DNAT を適用し、トラフィックを Web 層の内部ロード バランサーに転送します。

3. Web 層は、3 層アプリケーションの最初のレイヤーです。 UI が含まれており、ユーザーの操作を解析します。 Web 層ロード バランサーは、3 つの可用性ゾーンすべてにまたがり、3 つの Web 層 VM のそれぞれにトラフィックを分散します。

4. Web 層 VM は、3 つの可用性ゾーンすべてにまたがり、専用の内部ロード バランサーを介してビジネス層と通信します。

5. ビジネス層は、ユーザーの操作を処理し、次の手順を決定します。 Web 層とデータ層の間に配置されます。 ビジネス層内部ロード バランサーは、3 つの可用性ゾーン間でビジネス層 VM にトラフィックを分散します。 ビジネス層ロード バランサーは、Web 層ロード バランサーと同様にゾーン冗長です。

6. ビジネス層の VM は可用性ゾーンにまたがり、データベースの可用性グループ リスナーにトラフィックをルーティングします。

7. データ層は、アプリケーション データ (通常はデータベース、オブジェクト ストレージ、またはファイル共有) を格納します。 このアーキテクチャには、仮想マシン上の SQL Server が 3 つの可用性ゾーンに分散されています。 各 SQL Server VM を 別々のサブネットに配置して Always On 可用性グループを使用します。 マルチサブネット デプロイを使用すると、 可用性グループ リスナー はトラフィックをレプリカに直接ルーティングでき、Azure ロード バランサーや DNN は必要ありません。

アウトバウンドトラフィック フロー (すべてのプロトコル)

VM パッチ更新プログラムまたはその他のインターネットにバインドされたトラフィックの送信トラフィック フローは、ワークロード VM から UDR を介して Azure Firewall に送信されます。 Azure Firewall では、Web カテゴリとネットワークとアプリケーションの規則を使用して接続規則を適用し、ワークロードが許可されていないコンテンツにアクセスしたり、データを流出させたりするのを防ぎます。

Components

• Azure Firewall は、Microsoft のクラウド サービスであり、南北および東西のトラフィック フローの詳細なパケット検査など、次世代のファイアウォール機能を提供します。 このアーキテクチャでは、Azure Firewall は Web トラフィックと非 Web トラフィックの両方にネットワーク セキュリティを提供します。 TLS 検査を使用して、Application Gateway からの受信 HTTP(S) フローを検査し、パブリック インターネットからの HTTP (S) 以外の受信フローを処理し、VM からの送信フローを検査してデータ流出を防ぎます。

• Application Gateway は、WAF 機能を提供するレイヤー 7 ロード バランサーです。 このアーキテクチャでは、Application Gateway は HTTP(S) トラフィックのリージョン負荷分散を提供し、Web 攻撃の検出と防止に役立ち、TLS 終端とパスベースのルーティングを提供します。 Traffic Manager のバックエンド エンドポイントとして機能します。

• Traffic Manager は、グローバル Azure リージョン間でサービスにトラフィックを分散し、高可用性と応答性を提供する DNS ベースのグローバル トラフィック ロード バランサーです。 このアーキテクチャでは、Traffic Manager はグローバル負荷分散を提供し、DNS クエリを解決して、アプリケーションのリージョン エンドポイントにトラフィックを転送します。 エンドポイントの正常性を監視し、異常なリージョンからの DNS 応答をリダイレクトします。

• Azure Load Balancer は、バックエンド リソース間で受信ネットワーク トラフィックを分散するレイヤー 4 ロード バランサーです。 このアーキテクチャでは、Load Balancer はアプリケーション層間の内部負荷分散を提供し、各リージョン内の可用性ゾーン間で高可用性を維持します。

• Azure DDoS Protection は、分散型サービス拒否 (DDoS) 攻撃から保護するのに役立つサービスです。 このアーキテクチャでは、DDoS Protection はパブリック IP アドレスの保護を提供し、攻撃シナリオ中に可用性を確保するのに役立ちます。

• Azure DNS は DNS ドメインのホスティング サービスです。 これは、Azure インフラストラクチャを介して名前解決を提供します。 このアーキテクチャでは、Azure DNS は DNS レコードを管理し、Traffic Manager と連携してグローバル DNS ベースの負荷分散とフェールオーバー機能を提供します。

• Azure プライベート DNS ゾーン は、Azure DNS の機能です。 Azure プライベート DNS ゾーンは、仮想ネットワーク内および仮想ネットワーク間で名前解決を提供します。 このアーキテクチャでは、Azure プライベート DNS ゾーンは、仮想ネットワーク インフラストラクチャ内のリソースの内部名前解決を提供します。

• Azure Virtual Machines は、仮想化の柔軟性を提供しながら、物理ハードウェアのメンテナンス要求を排除する、オンデマンドでスケーラブルなコンピューティング リソースを提供するサービスです。 このアーキテクチャでは、Virtual Machines はアプリケーション層をホストします。アプリケーション層は、回復性のために可用性ゾーンに分散され、回復性のために複数のリージョンに分散されます。

• 柔軟なオーケストレーションを備えた Azure Virtual Machine Scale Sets は、オンデマンドに基づいて自動的にスケーリングできる負荷分散された VM のグループを作成および管理するために使用できるサービスです。 このアーキテクチャでは、仮想マシン スケール セットは、各リージョンの可用性ゾーン間で Web 層とビジネス層の VM をホストします。 データ層では、次に示すように、スタンドアロンの SQL Server 仮想マシンが使用されます。

• Virtual Machines 上の SQL Server は、オンプレミスのハードウェアを管理する必要がないように、クラウド内の SQL Server の完全なバージョンを提供するサービスです。 このアーキテクチャでは、スタンドアロン Virtual Machines 上の SQL Server は、 マルチサブネット構成の可用性ゾーン間で分散された Always On 可用性グループを使用してデータ層を形成します。

• Azure Virtual Network は、クラウド内のセキュリティで保護されたプライベート ネットワークです。 VM を相互に接続し、インターネットに接続し、クロスプレミス ネットワークに接続します。 このアーキテクチャでは、Virtual Network はすべてのコンポーネントに対してネットワークの分離と接続を提供します。 グローバル仮想ネットワーク ピアリングは、リージョン間の待機時間の短い通信を提供します。

• UDR は、仮想ネットワークの既定のルーティングをオーバーライドするメカニズムです。 このアーキテクチャでは、セキュリティ検査とポリシー適用のために、受信トラフィックと送信トラフィック フローが Azure Firewall を通過するように強制されます。

代替案

このアーキテクチャでは、特定のテクノロジの選択肢を使用して、混合プロトコルのマルチリージョン ワークロードをサポートします。 ワークロードの要件によって、さまざまな選択肢が生じる可能性があります。 次の代替手段を検討してください。

グローバル ロード バランサー

現在のアプローチ: Traffic Manager は、HTTP (S) プロトコルと非 HTTP (S) プロトコルの両方をサポートする DNS ベースのグローバル負荷分散を提供します。 このアーキテクチャでは、ネットワーク レベルの検査のために、SFTP や従来の TCP 統合などの HTTP (S) 以外のフローを Azure Firewall 経由でルーティングする必要があるため、Traffic Manager を使用します。 Traffic Manager は DNS ベースであるため、クライアントはバックエンド エンドポイントに直接接続します。そのためには、Application Gateway と Azure Firewall にパブリック IP アドレスが必要です。

別の方法: Traffic Manager の代わりに Azure Front Door を使用します。 Azure Front Door は、キャッシュ、トラフィック高速化、TLS 終了、証明書管理、および組み込みの WAF を提供する HTTP(S) トラフィック用のレイヤー 7 グローバル ロード バランサーです。 Azure Front Door はリバース プロキシであるため、 Azure Private Link 経由で Application Gateway に接続できるため、バックエンド インフラストラクチャでパブリック IP アドレスが不要になります。 これは、HTTP (S) のみのワークロードに推奨されるグローバル ルーティング ソリューションです。

ワークロードが次の条件を満たしている場合は、Azure Front Door を検討してください。

• すべての受信トラフィックは HTTP(S) プロトコルを使用します。

• 受信トラフィックの詳細なパケット検査には Azure Firewall は必要ありません。

• グローバル エッジで WAF とコンテンツ配信ネットワークの統合機能が必要です。

コンピューティング プラットフォーム

現在のアプローチ: Web 層、ビジネス層、およびデータ層は、仮想マシン上の SQL Server を使用して仮想マシン スケール セットで実行されます。 このサービスとしてのインフラストラクチャ (IaaS) アプローチでは、オペレーティング システム (OS)、ミドルウェア、データベース エンジンの構成を完全に制御できます。

別の方法: 特定のレベルを、Web 層用 の Azure App Service やデータ層用の Azure SQL Database などのサービスとしてのプラットフォーム (PaaS) リソースに置き換えます。 Private Link と App Service 仮想ネットワーク統合を使用してこれらの PaaS サービスを仮想ネットワークに統合する場合、ネットワーク アーキテクチャ全体は大きく変わりません。

ワークロードが次の条件を満たしている場合は、PaaS の代替手段を検討してください。

• OS レベルまたはミドルウェアの構成制御を直接行う必要はありません。

• 修正プログラムの適用、スケーリング、および可用性管理の運用上のオーバーヘッドを減らしたいと考えています。

• データベース ワークロードは、SQL Database の機能セットと制限と互換性があります。

負荷分散サービスの組み合わせ

現在のアプローチ: このアーキテクチャでは、グローバルな DNS ベースのルーティングに Traffic Manager を使用します。 各リージョン内で、Application Gateway はレイヤー 7 の処理と WAF の検査を処理し、Load Balancer はレイヤー 4 の階層間の分散を管理します。

別の方法: ワークロードのプロトコル、待機時間、およびセキュリティの要件では、負荷分散サービスの異なる組み合わせが必要になる場合があります。 たとえば、WAF を必要としないワークロードでは、リージョン分散に Load Balancer のみを使用できます。 ファイアウォールを使用せずにパスベースのルーティングを必要とするワークロードでは、その前に Azure Firewall がない Application Gateway を使用できます。

シナリオに適したサービスを決定するには、 Azure での負荷分散オプションに関するページを参照してください。

ネットワーク トポロジ

現在のアプローチ: このアーキテクチャでは、フラット仮想ネットワーク設計と、リージョンごとに 1 つの仮想ネットワーク内のすべてのコンポーネントが使用されます。

別の方法: このアーキテクチャを ハブ スポーク仮想ネットワーク設計に適応させます。ハブ ネットワークには Azure Firewall が存在し、Application Gateway はハブまたはスポークに存在します。 ハブに Application Gateway をデプロイする場合は、異なるアプリケーション グループに対して複数のインスタンスを使用して、Azure ロールベースのアクセス制御 (Azure RBAC) スコープを制御し 、Application Gateway の制限内に留めます。 Azure Virtual WAN 環境では、Application Gateway インスタンスをハブにデプロイできないため、スポーク仮想ネットワークにインストールします。

シナリオの詳細

• グローバル トラフィック ルーティング: Traffic Manager では、パフォーマンス ルーティングを使用して、各ユーザーを最も短い待機時間のエンドポイントに誘導し、条件の変化に応じて自動的に調整します。 正常性チェックと優先順位ルーティングは、異常なリージョンからの DNS 応答をリダイレクトします。

• ゾーン冗長性: このアーキテクチャでは、各リージョンの 3 つの可用性ゾーンにリソースがデプロイされます。 Application Gateway、内部ロード バランサー、VM は、3 つの可用性ゾーンすべてにまたがっています。 1 つのゾーンで障害が発生した場合、残りのゾーンはリージョンのフェールオーバーをトリガーせずに負荷を吸収します。

• リージョンの負荷分散と WAF: Application Gateway には、WAF、TLS 終端、パスベースのルーティング、Cookie ベースのセッション アフィニティなど、各リージョン内でレイヤー 7 の機能が用意されています。

• ネットワーク セキュリティと詳細なパケット検査: このアーキテクチャでは、Web コンテンツの二重検査のために Application Gateway を Azure Firewall の前に配置します。 代替トポロジについては、 仮想ネットワーク用の Azure Firewall と Application Gateway に関するページを参照してください。 このトポロジは、HTTP ヘッダー内X-Forwarded-Forし、エンドツーエンドの暗号化を提供し、クライアントが WAF をバイパスできないようにします。

  Azure Firewall Premium では、次の 3 種類のフローが検査されます。

  • Application Gateway からの受信 HTTP(S) フロー、TLS 検査で保護されています。

  • パブリック インターネットからの受信非 HTTP (S) フローは、完全な Premium 機能セットを使用して検査されます。 Application Gateway では 、レイヤー 4 (TCP/TLS) プロキシもサポートされています。これは、HTTP イングレスと非 HTTP イングレスの両方を 1 つのエントリ ポイントに統合します。 この機能はプレビュー段階であり、WAF はレイヤー 4 トラフィックには適用されないため、このアーキテクチャでは HTTP(S) 以外のフローに別のパスが使用されます。

  • VMからの送信フローは、データ流出と禁止対象へのアクセスを防止するためのものです。

• コンピューティング オーケストレーション: 3 つのアプリケーション層はすべて、柔軟なオーケストレーションで仮想マシン スケール セットを使用します。 データ層のマルチサブネット SQL Server 可用性グループでは、柔軟なオーケストレーションのみがサポートする特定のサブネットと障害ドメインに個々の VM を配置する必要があります。 また、Web 層とビジネス層では、柔軟なオーケストレーションを使用して、階層間でオーケストレーション モードを混在させるのではなく、ワークロード全体で単一の運用モデルを維持します。

• リージョン間接続: グローバル仮想ネットワーク ピアリングは、Microsoft バックボーン経由でリージョン間の低待機時間の高帯域幅データ レプリケーションを提供します。 ハブスポーク トポロジでは、各リージョン内のハブ とスポーク のネットワーク間、およびリージョン間のハブ間にピアリングが存在します。

考慮事項

これらの考慮事項は、ワークロードの品質向上に使用できる一連の基本原則である Azure Well-Architected Framework の要素を組み込んでいます。 詳細については、「 Well-Architected Framework」を参照してください。

Reliability

信頼性は、アプリケーションが顧客に対して行ったコミットメントを確実に満たすことができるのに役立ちます。 詳細については、「信頼性の設計レビュー チェックリスト」を参照してください。

• マルチリージョンのデプロイ: 回復性を高めるために、少なくとも 2 つの Azure リージョンにデプロイします。 アクティブ/パッシブまたはアクティブ/アクティブのマルチリージョン構成は、リージョンの障害からワークロードを復旧するのに役立ちます。 Traffic Manager はエンドポイントの正常性を監視し、異常なリージョンから DNS 応答をリダイレクトしますが、データ レプリケーションやアプリケーションの準備など、セカンダリ リージョンがトラフィックを処理する準備ができていることを確認する必要があります。

  • セカンダリ リージョンでは、 ペアになっているリージョン を使用できる場合は、ペアのリージョンを優先します。これは、優先順位付けされた復旧シーケンス処理と、プラットフォームの更新の時間差が提供されるためです。 リージョンにペアのリージョンがない場合は、マルチリージョン ソリューションを構築できます。 ただし、 geo 冗長ストレージ (GRS) などの一部のサービスでは、代替レプリケーション アプローチが必要です。 地理的距離、データ所在地、サービスの可用性、コストを考慮します。 詳細については、「Azure リージョンの選択」を参照してください。

  • セカンダリ リージョンの SQL Server Always On 可用性グループ レプリカは、 手動フェールオーバーで非同期コミットを使用します。 コミット モードは非同期であるため、セカンダリ リージョンはリージョンの停止中にコミットされたトランザクションを受信しない可能性があるため、データ損失の可能性を考慮してください。 目標復旧ポイント (RPO) を定義し、ワークロードの書き込みボリュームのレプリケーションラグがそのターゲット内に残っているかどうかをテストします。 セカンダリリージョンへのフェールオーバーは、手動で行う操作です。これには、オペレーターまたはランブックを使用して非同期レプリカを昇格させる必要があります。

• ゾーンの回復性: このアーキテクチャでは、Application Gateway、Azure Firewall、Load Balancer、および仮想マシン スケール セットが各リージョン内の複数 の可用性ゾーン にデプロイされ、データセンター レベルの障害に対する回復性が提供されます。

• 仮想マシン スケール セット: 柔軟なオーケストレーションでは、VM インスタンスが各可用性ゾーン内の障害ドメインに分散されるため、1 つのホスト障害の爆発半径が減少します。 また、 複数サブネットの SQL Server 可用性グループ 構成に必要な VM 単位の配置制御も提供します。

グローバル ルーティング

• 顧客のニーズに最適なトラフィック ルーティング方法を使用します。 Traffic Manager では、さまざまなサービス エンドポイントにトラフィックを確定的にルーティングするための複数のトラフィック ルーティング方法 がサポートされています。

  リージョン内で優先フェールオーバーを選択するためのより詳細な制御が必要な場合は、 入れ子になった構成 で Traffic Manager を使用します。

• トラフィック ビューを使用して、トラフィック パターンと待機時間メトリックを確認します。 トラフィック ビューは、新しい Azure リージョンへの拡張を計画するのに役立ちます。

Application Gateway

Application Gateway を介して信頼性の高いトラフィック フローを維持するには、次のプラクティスに従います。

• 障害ドメインと更新ドメイン間でインスタンスを分散するには、プラットフォームに依存します。 可用性ゾーンをサポートするリージョンでは、Application Gateway は既定でゾーン冗長であるため、インスタンスはゾーンフォールト トレランスのために可用性ゾーンにまたがることもあります。

• 自動スケールを有効にし、最小インスタンス数を少なくとも 2 に設定します。 この予約容量により、Application Gateway は、新しいインスタンスをプロビジョニングするために 3 分から 5 分の遅延なしでトラフィックを処理できます。 詳細については、「 Application Gateway の自動スケール」を参照してください。

• Application Gateway がバックエンド インスタンスを削除する前に、進行中の要求が完了するように 接続ドレインを有効にしてください。 これを使用しないと、スケールイン イベントと構成の更新によって一時的な要求エラーが発生します。

Azure Firewall

この設計では、Tls 検査を提供するために Azure Firewall Premium が必要です。 Azure Firewall は、Application Gateway と Web 層 VM 間の TLS セッションをインターセプトし、独自の証明書を生成し、仮想ネットワークからパブリック インターネットへの送信トラフィック フローを検査します。 詳細については、「 Azure Firewall と Application Gateway を使用する Web アプリケーションのゼロ トラスト ネットワーク」を参照してください。

Azure Firewall が TLS 検査に使用する中間証明機関 (CA) 証明書の有効期限を監視します。 期限切れの証明書は TLS ハンドシェイクを中断するため、すべてのインフラストラクチャ コンポーネントが正常なままであっても、トラフィックがバックエンド サーバーに到達できなくなります。 詳細については、「 TLS 証明書の信頼チェーン」を参照してください。

健康プローブ推奨事項

Traffic Manager、Application Gateway、Load Balancer の正常性プローブに関する次の推奨事項を検討してください。

Traffic Manager

• エンドポイントの正常性: アプリケーションの全体的な正常性を報告するエンドポイントを作成します。 Traffic Manager は、HTTP(S) プローブを使用して、各リージョンの可用性を監視します。 プローブは、指定された URL パスの HTTP 200 (OK) 応答を確認します。 他のエンドポイントが原因で、アプリケーションの重要な部分が失敗した場合でもプローブが正常な状態を報告する可能性があるため、正常性プローブ用に作成したエンドポイントを使用します。 詳細については、「正常性エンドポイント監視パターン」を参照してください。

• フェールオーバーの遅延: Traffic Manager にはフェールオーバーの遅延があります。 遅延の期間は、次の要因によって決まります。

  • プローブ間隔: プローブがエンドポイントの正常性をチェックする頻度。

  • 許容されるエラー数: プローブがエンドポイントに異常を示す前に許容されるエラーの数。

  • プローブのタイムアウト: Traffic Manager でエンドポイントが異常と見なされるまでの時間。

  • Time-to-Live (TTL): DNS サーバーは、IP アドレスのキャッシュされた DNS レコードを更新する必要があります。 所要時間は DNS TTL によって異なります。 既定の TTL は 300 秒 (5 分) ですが、Traffic Manager プロファイルを作成するときにこの値を設定できます。 詳細については、Traffic Manager の監視に関するページを参照してください。

アプリケーションゲートウェイとロードバランサー

Application Gateway と Load Balancer の正常性プローブ ポリシーについて理解し、VM の正常性を確実に把握します。

• Application Gateway では常に HTTP プローブが使用されます。

• Load Balancer では、 HTTP または TCP を評価できます。 VM で HTTP サーバーが実行されている場合は、HTTP プローブを使用します。 その他のすべての場合は TCP を使用します。

• HTTP プローブでは、指定されたパスに HTTP GET 要求が送信され、HTTP 200 応答がリッスンされます。 このパスには、ルート パス ("/") またはアプリケーションの正常性を確認するカスタム ロジックを実装する正常性監視エンドポイントを指定できます。 エンドポイントでは、匿名の HTTP 要求を許可する必要があります。 タイムアウト期間内にプローブがインスタンスに到達できない場合、Application Gateway または Load Balancer はその VM へのトラフィックの送信を停止します。 プローブは引き続き確認し、VM が再び使用可能になった場合は、VM をバックエンド プールに返します。

セキュリティ

セキュリティは、意図的な攻撃や貴重なデータとシステムの誤用に対する保証を提供します。 詳細については、セキュリティ設計レビューのチェックリストを参照してください。

このアーキテクチャは、コンポーネント間の暗黙的な信頼がないことを前提としています。 複数のレイヤーがトラフィックを検査および承認します。 Application Gateway WAF は、HTTP レベルの脅威をフィルター処理します。 Azure Firewall Premium では、すべてのトラフィック フローがディープ パケット レベルで検査されます。 ネットワーク セキュリティ グループ (NSG) では、層間で最小特権のセグメント化が適用されます。 TLS 暗号化は、すべてのネットワーク ホップで転送中のデータを保護します。 すべての脅威をブロックするレイヤーは 1 つもありません。

• Waf： Application Gateway の WAF 機能は、SQL インジェクション (SQLi) やクロスサイト スクリプティング (XSS) などの HTTP レベルでの攻撃を検出して防止します。

• 次世代ファイアウォール: Azure Firewall Premium では、HTTP(S) やその他のプロトコルを介してアップロードされた悪意のあるファイルなどの Web 以外の攻撃についてコンテンツを検査することで、追加の防御レイヤーが提供されます。

• エンドツーエンドの暗号化: トラフィックは、Azure ネットワークを通過するときに常に暗号化されます。 Application Gateway と Azure Firewall は、対応するバックエンド システムに送信する前にトラフィックを暗号化します。

• TLS 証明書信頼チェーン: Azure Firewall Premium は、転送プロキシとして機能し、TLS 検査中にプライベート CA によって署名された証明書を動的に生成します。 Azure Firewall が使用するルート CA 証明書を信頼するように Application Gateway を設定して、それらの間の TLS ハンドシェイクが成功するようにします。

  運用環境の展開では、エンタープライズ公開キー 基盤 (PKI) を使用して中間 CA 証明書を生成します。 詳細については、「Azure Firewall 用のエンタープライズ CA 証明書のデプロイと設定」と、このアーキテクチャの証明書チェーンの詳細を参照してください。

• Ddos： Azure が提供する基本的な保護よりも DDoS 保護を強化するには、Azure DDoS ネットワーク 保護を使用します。

• NSG:NSG を使用して、仮想ネットワーク内のネットワーク トラフィックを制限します。 たとえば、3 層アーキテクチャでは、データ層はビジネス層からのトラフィックのみを受け入れ、Web 層からのトラフィックは受け入れません。 この規則を適用するために、データベース層は、ビジネス層サブネットを除くすべての受信トラフィックをブロックします。

  1. ビジネス層サブネットからの受信トラフィックを許可します。

  2. データベース層サブネットからの受信トラフィックを許可します。 このルールは、データベース VM 間の通信を許可します。 データベースのレプリケーションとフェールオーバーは、このルールを必要とします。

  3. 規則の VirtualNetwork タグを使用して仮想ネットワークからの受信トラフィックをすべて拒否し、既定の NSG 規則の permit ステートメントを上書きします。

  最初のルールよりも優先順位が低い (数値が高い) ルール 3 を作成します。

  サービス タグを使用して、NSG または Azure Firewall でネットワーク アクセス制御を定義できます。 Application Gateway には、専用サブネットで許可する必要がある独自の 必要な NSG 規則 もあります。

コストの最適化

コストの最適化では、不要な経費を削減し、運用効率を向上させる方法に重点を置いています。 詳細については、「コスト最適化の設計レビュー チェックリスト」を参照してください。

• マルチリージョン ベースライン コスト: このアーキテクチャでは、Application Gateway、Azure Firewall Premium、ロード バランサーの 3 つの層にまたがる仮想マシン スケール セットを含む、各リージョンに完全なインフラストラクチャ スタンプをデプロイします。 セカンダリ リージョンは、トラフィックを処理するかどうかに関係なく、コストが発生します。 アクティブ/パッシブ構成では、セカンダリ リージョンの仮想マシン スケール セット インスタンスを、完全な運用環境で実行するのではなく、タイムリーなフェールオーバーに必要な最小限にスケーリングします。

• Vm： VM はプライマリ コスト ドライバーです。両方のリージョンのすべてのレベルでコンピューティングが継続的に実行されるためです。 Azure Reserved Virtual Machine Instances または Azureのコンピュート向け節約プランを使用します。 予約インスタンスは最小の常時接続容量に対して適切に機能しますが、VM のサイズが時間の経過と同時に変化する場合は、節約計画によって柔軟性が提供されます。

• Azure Firewall Premium: Azure Firewall Premium には、デプロイ単位の 1 時間あたりの固定料金とギガバイト単位 (GB) の可変処理料金が含まれており、両方のリージョンで実行されます。 ワークロードで侵入検出および防止システム (IDPS) または TLS 検査が必要ない場合は、 Azure Firewall Standard が低い価格でセキュリティ要件を満たしているかどうかを判断します。

• DDoS ネットワーク保護と WAF 割引:DDoS ネットワーク保護 には、テナント内のサブスクリプション全体で最大 100 個のパブリック IP アドレスをカバーする固定の月額コストがあります。

  DDoS ネットワーク保護を有効にすると、Azure は、WAF レートではなく低い標準レートで Application Gateway WAF インスタンスに課金 します。 複数の Application Gateway インスタンスを持つアーキテクチャの場合、WAF 割引は DDoS プランのコストの大部分を相殺できます。

• Application Gateway のスケーリング: Application Gateway では、固定時間単価と可変 容量ユニット コストが課金されます。 自動スケールの最小インスタンス数が多いほど、トラフィックに関係なく支払う必要がある容量単位が予約されます。 未使用の容量に対する支払いを回避するために、最小インスタンス数と許容可能なコールド スタート待機時間のバランスを取る。

サービス固有の価格の詳細については、次のリソースを参照してください。

• Virtual Machines の価格
• Application Gateway の価格
• Azure ファイアウォール価格
• DDoS Protection の価格
• Traffic Manager の料金

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

オペレーショナル エクセレンスは、アプリケーションをデプロイし、それを運用環境で実行し続ける運用プロセスをカバーします。 詳細については、「 オペレーショナル エクセレンスの設計レビュー チェックリスト」を参照してください。

• コードとしてのインフラストラクチャ (IaC): このアーキテクチャには、Traffic Manager、Application Gateway、Azure Firewall、ロード バランサーを持つ 2 つのリージョン スタンプ、仮想マシン スケール セット、NSG、仮想ネットワーク、サブネットを含む大きなリソース領域があります。 Bicep または Terraform 内のすべてのリソースを定義して、両方のリージョン スタンプが一貫性を保ち、繰り返し可能なデプロイ用に維持されるようにします。

• デプロイの調整: 2 つのアクティブなリージョン スタンプを持つデプロイでは、プライマリ リージョンに変更を昇格する前に、セカンダリ リージョンに更新プログラムをデプロイし、検証します。 安全な展開プラクティスを段階的に公開して、影響の範囲を制限します。 Traffic Manager DNS の重み付けでは、ロールアウト中のリージョン間のカナリア トラフィックシフトをサポートできます。

• 監視： リージョンの停止中でも監視が機能し続けることができるように、各リージョンに Log Analytics ワークスペース をデプロイします。

  ワークスペース間クエリと Azure Monitor ブックを使用して、両方のリージョン間のシグナルを統合された運用ビューに関連付けます。 Traffic Manager エンドポイント プローブ、Application Gateway バックエンドの正常性、Azure Firewall ログ、VM レベルのメトリックを複合正常性状態に組み合わせた正常性 モデル を構築します。

• 構成の誤差: 2 つの同じリージョン スタンプにより、構成ドリフトのリスクが継続的に発生します。 Azure Policy を使用して、NSG ルール、Azure Firewall ポリシーのバージョン、リージョン間で一貫性のある Application Gateway WAF ルールセットなどのガードレールを適用します。

• リソースの編成: リージョンごとの リソースを 個別に管理、デプロイ、クリーンアップできるように、リージョン スタンプごとに個別のリソース グループを使用します。 Traffic Manager や DNS ゾーンなどの共有グローバル リソースを独自のリソース グループに配置します。

• フェールオーバー テスト: リージョンのフェールオーバーを定期的にテストして、Traffic Manager 正常性プローブがすぐに停止を検出し、SQL Server 可用性グループがセカンダリ リージョンで正しく昇格し、セカンダリ スタンプが運用環境の負荷を処理することを検証します。 テストされていないフェールオーバー手順は、多くの場合、使用する必要があるときに失敗します。

• 運用上のオーバーヘッド: この IaaS アーキテクチャでは、両方のリージョンでミドルウェアの構成、証明書のローテーション、ファイアウォール規則のチューニング、および SQL Server 可用性グループの正常性を管理する必要があります。

  フレキシブル オーケストレーションでは、重要なパッチとセキュリティ パッチの自動ゲスト 修正プログラム がサポートされますが、OS イメージの自動アップグレードはサポートされていません。 AZURE Update Manager またはデプロイ パイプラインを使用して、OS イメージのアップグレードを処理します。

  この継続的な運用上の負担は、IaaS が提供する制御と柔軟性の主なトレードオフです。 チームがこのレベルの制御を必要としない場合は、PaaS の 代替手段を検討してください。

パフォーマンス効率

パフォーマンス効率とは、ユーザーの要求を効率的に満たすためにスケーリングするワークロードの能力を指します。 詳細については、「パフォーマンス効率のための設計レビュー チェックリスト」を参照してください。

• 仮想マシン スケール セット:Web、ビジネス、データ層など、アプリケーション層ごとに柔軟なオーケストレーションを使用して、個別の仮想マシン スケール セット インスタンスをデプロイします。 個別のスケール セットを使用すると、独自の需要プロファイルに基づいて各レベルを個別にスケーリングできます。 需要の増加時にスケールアウトし、ピーク時以外の期間にスケールインするように、Web レベルとビジネス 層で 自動スケール ポリシー を設定します。

• 2 倍の検査待ち時間: このアーキテクチャの HTTP(S) フローは、Application Gateway WAF と Azure Firewall Premium TLS 検査の両方を介してトラフィックを渡します。 この多層防御により、各要求に待機時間が追加されます。 現実的な負荷の下でアプリケーションのパフォーマンスをテストし、追加の検査時間が応答時間の要件を満たしていることを確認します。

• Azure Firewall のスループット: アラート モードと拒否モードの IDPS は、他のモードと比較して Azure Firewall の最大スループットを大幅に削減します。 ワークロードで IDPS 拒否モードと高スループットの両方が必要な場合は、それに応じて容量を計画し、ファイアウォールのスループット メトリックを監視します。 詳細については、「Azure Firewall performance」を参照してください。

• Application Gateway の容量: WAF ルールの処理と TLS 操作では、コンピューティング ユニットが使用され、インスタンスごとのスループットが低下します。 容量ユニットとコンピューティング ユニットのメトリックを監視して、自動スケールが需要に合わせてペースを保っていることを確認します。

• 読み取り専用ルーティング: このアーキテクチャの Always On 可用性グループ セカンダリは、レポートや分析ワークロードなどの読み取り専用クエリを提供できます。 読 み取り専用ルーティング を設定して、プライマリ レプリカから読み取りトラフィックをオフロードし、高可用性への投資をパフォーマンス上の利点に変えます。

関連リソース

• マルチリージョン クラスターの AKS ベースライン