Azure Front Door は、外部のお客様と Microsoft の内部プロパティの両方に、優れた回復性と可用性を提供するように設計されています。 Azure Front Door のアーキテクチャは、ほとんどの運用ワークロードのニーズを満たすか超えていますが、障害を受ける影響を受けない分散システムはありません。
この記事では、Azure Traffic Manager を実装して、まれな Azure Front Door サービスの中断中に、代替コンテンツ配信ネットワーク (CDN) または Azure Application Gateway Web アプリケーション ファイアウォール (WAF) への Azure Front Door からの手動フェールオーバーを有効にする手順について説明します。 ミッション クリティカルな Web アプリケーションのグローバル ルーティング冗長性に関するガイダンスを補足します。
CDN および Web アプリケーション アーキテクチャで高可用性 (HA) を実現するための複数の戦略が業界内に存在します。 この記事で概説されているアプローチは、簡単な手動の「ブレイクグラス」フェイルオーバーパターンに重点を置いています。 このパターンを使用すると、サービスの正常性が確認された後、停止中にトラフィックをすばやくリダイレクトし、ルーティングを Azure Front Door にシームレスに復元できます。
この記事には、運用環境での HA パターンの実装、正常性の監視の確立、継続的な準備をサポートするための運用 Runbook の作成に関するガイダンスも含まれています。
主な運用上の違い
このガイドでは、Traffic Manager を使用して自動フェールオーバーを提供する 2 つの実証済みアーキテクチャについて説明します。 次の表は、考慮すべき主な運用上の違いをまとめたものです。
| 特徴 | シナリオ 1 (Azure Front Door + Application Gateway) | シナリオ 2 (Azure Front Door + その他の CDN) |
|---|---|---|
| フェールオーバー ターゲット | セカンダリ Traffic Manager インスタンスと複数の Application Gateway インスタンス。 | 他の 1 つの CDN エンドポイント。 |
| フェールオーバー中のキャッシュ | No. Application Gateway はキャッシュされません。 | Yes. |
| 地理的な分布 | 2 つの特定の Azure リージョン。 | 他の CDN のグローバル エッジ ネットワーク。 |
| WAF 保護 | Azure Web アプリケーション ファイアウォール (一貫性のある規則セット)。 | 他の CDN の WAF (異なるルール セット)。 |
| スタンバイ中のコスト | 固定のコンピュートコスト。 Application Gateway は、アイドル状態の場合でも課金されます。容量が最小限のWAF_v2の場合は、1 か月あたり約 200 ~ 400 ドルです。 | CDN ベンダーの価格によって異なります。 |
運用環境に関する考慮事項
運用環境のワークロードに対して HA アーキテクチャを実装する場合は、次のベスト プラクティスと重要な注意事項を考慮してください。
自動フェールオーバー用にプライマリ Traffic Manager インスタンスを構成しないでください。
Azure Traffic Manager の正常性プローブは、米国ベースの Azure リージョンからのみ発生します。 Azure Front Door エンドポイント (またはエニーキャスト ルーティングを使用した任意の CDN) のプローブの場合、これらの米国ベースのプローブはほとんどの場合、US POP サーバーに到達し、米国以外の POP サーバーの正常性は確認されません。 この状況により、Traffic Manager は、Azure Front Door などのエニーキャスト CDN の真のグローバル正常性に基づいて、Azure Front Door から別のイングレス サービスへのフェールオーバーを自動的に行うことができなくなります。
複数の地域からの正常性検証を必要とするグローバル ワークロードの場合、重み付けされたルーティングと監視を無効にした手動フェールオーバーでは、自動化された正常性ベースのルーティングよりも信頼性の高い制御が提供されます。
現在 Azure Front Door で管理されている認定を使用している場合は、Bring Your Own (BYO) 証明書に移行する必要があります。 独自の証明書を使用することで、トラフィックが続くイングレス パスに関係なく、TLS 証明書の一貫性を維持できます。
TLS 証明書が Azure Front Door と互換性があることを確認します。 詳細については、「 Azure Front Door カスタム ドメインでの HTTPS の構成」と「Azure Front Doorを使用した TLS 暗号化」を参照してください。
最初に、運用環境以外の環境でフェールオーバー手順を常にテストします。
Traffic Manager では、DNS ゾーンの頂点 (ルート ドメイン) での CNAME フラット化はサポートされていません。 頂点に Traffic Manager が必要な場合は、エイリアス レコードまたは同様のメカニズムをサポートする DNS プロバイダーを使用する必要があります。 Azure DNS は、そのような DNS プロバイダーの 1 つです。
300 ~ 600 秒の短い DNS Time-to-Live (TTL) 値を使用します。 DNS TTL 伝達時間を監視します。
ネットワーク セキュリティ グループ (NSG) とアクセス制御リスト (ACL) を使用して Application Gateway をロックダウンします。 必要なプラットフォーム範囲と受信アプリケーション ポートを許可します。 すべてのイングレス パスに対してオリジン (配信元) をセキュリティで保護します。 詳細については、「ネットワーク セキュリティ グループ」を参照してください。
Application Gateway WAF は HTTP/L7 攻撃を軽減しますが、NSG はパケット フィルタリングのみを提供し、帯域幅消費型またはプロトコル レベル (L3/L4) DDoS 攻撃から保護しません。 すべての Azure パブリック エンドポイントは、Azure プラットフォームでのベースラインの常時接続 DDoS 保護の恩恵を受けられます。 Azure インフラストラクチャを保護するのに役立ちますが、ワークロード固有のチューニング、テレメトリ、コスト保護、可用性の保証は含まれません。
運用環境とミッション クリティカルなワークロードの場合は、Azure DDoS Protection サービスを使用して Application Gateway のパブリック IP を保護することを検討してください。 詳細については、 Azure DDoS Protection の価格に関するページを参照してください。
Azure Front Door とフェールオーバー ソリューションの WAF ルールの違いについて説明します。
代替 CDN プラットフォームは、Azure Front Door の Private Link 統合によって保護された配信元にアクセスできないため、これらの HA アーキテクチャには Azure Private Link をお勧めしません。
また、Application Gateway では、プライベートオリジンに到達するために追加の仮想ネットワークとプライベート エンドポイント構成が必要です。 Application Gateway では、Azure Front Door のネイティブ Private Link 機能を使用できません。
Azure Front Door を他の CDN プロバイダーと共に使用する運用環境では、代替の CDN に依存しない配信元セキュリティ コントロールを使用して、Private Link または
X‑Azure‑FDID検証を使用できない場合に配信元の信頼を適用することを検討してください。 これらのコントロールには、トークン ベースの配信元認証 (HMAC または署名済み URL)、相互 TLS (mTLS)、カスタム配信元ヘッダー、IP アドレス のフィルター処理が含まれる場合があります。このガイドに記載されているサンプル コマンドを編集して、自動化と Runbook 用の環境に合わせて調整します。
明確な Runbook を確立します。 フェールオーバーとフェールバックの手順をテストします。
すべてのエンドポイントの包括的な監視とアラートを構成します。
代替イングレス ソリューションへのフェールオーバー中に機能を検証します。
すべてのプラットフォームで証明書の更新プロセスをテストします。
フェールオーバー エンドポイントが引き続き機能していることを定期的に検証します。 四半期ごとのテストをお勧めします。
このガイドでは、PowerShell から実行する Azure CLI サンプル コマンドを使用します。
先に進む前に、 ミッション クリティカルな Web アプリケーションのグローバル ルーティング冗長性を確認してください。
シナリオ 1: Azure Front Door から Application Gateway WAF への Traffic Manager フェールオーバー
この DNS ベースの負荷分散ソリューションでは、複数の Azure Traffic Manager プロファイルが使用されます。 Azure Front Door で可用性の問題が発生した場合、Traffic Manager は Application Gateway WAF を介してトラフィックをリダイレクトします。 プライマリ Traffic Manager インスタンスは、Azure Front Door (プライマリ) と、複数リージョンの Application Gateway インスタンスを指す入れ子になったセカンダリ Traffic Manager インスタンスの間でトラフィックをルーティングします。 Azure Front Door の停止中、トラフィックは WAF 保護を持つリージョンの Application Gateway デプロイに手動でフェールオーバーされます。
トラフィック フロー（通常の操作）: ユーザー → DNS クエリ → プライマリ Traffic Manager インスタンス（重み付け/always-serve ルーティング）→ Azure Front Door（優先度 1）→ オリジンサーバー。
トラフィック フロー (Azure Front Door 障害): ユーザー → DNS クエリ → プライマリ Traffic Manager インスタンス (重み付け/常時サービス ルーティング) → セカンダリ Traffic Manager インスタンス (優先順位モード) → Application Gateway → 配信元サーバー。
デプロイ前: Azure Front Door と Application Gateway
Application Gateway WAF で提供されていない機能を使用している場合は、Azure Front Door と Application Gateway WAF の機能の違いを理解することが重要です。 次の表に概要を示します。
Important
このソリューションでは、現在 Azure Front Door を使用して、複数のリージョンまたはグローバルにトラフィックを処理していることを前提としています。 この設計では、次の手順に従って、プライマリ Traffic Manager インスタンスとリージョン Application Gateway インスタンスの間のパフォーマンス ルーティングで構成されたセカンダリ Traffic Manager インスタンスを導入します。
Azure Front Door はグローバルレイヤー 7 サービスであるため、この方法が必要です。 セカンダリ Traffic Manager インスタンスは、グローバル負荷分散レイヤーとして機能することで、Azure Front Door のグローバル待機時間ベースのルーティングを効果的に置き換えます。 その結果、Traffic Manager は、地理的に分散された対象ユーザーに対して待機時間に最適化されたユーザー ルーティングを保持します。
このアーキテクチャの変化により、最適なパフォーマンスと回復性を確保するために、グローバル トラフィック パターンを評価し、意味のあるユーザー ボリュームを持つリージョンに Application Gateway インスタンスをデプロイする必要があります。
機能の違い
| 特徴 | Azure Front Door | Application Gateway |
|---|---|---|
| コア アーキテクチャと機能 | ||
| サービスの範囲 | グローバル サービス | リージョン サービス |
| OSI レイヤー | レイヤー 7 (アプリケーション レイヤー) | レイヤー 7 (アプリケーション レイヤー) |
| 負荷分散レベル | リージョン間 | リージョンまたは仮想ネットワーク内 |
| デプロイメント モデル | 1 つのグローバル インスタンス | リージョンごとのインスタンス |
| バックエンドの範囲 | 任意のパブリック エンドポイント (Azure または外部)、選択した Private Link エンドポイント | 仮想ネットワーク内のパブリック エンドポイント (Azure または外部)、プライベート IP アドレス、および Kubernetes ポッド |
| コンテンツ エッジ キャッシュ | イエス | いいえ |
| ネットワーク アーキテクチャ | エニーキャストを使用した Microsoft のグローバル エッジ ネットワーク | Azure リージョンデプロイ (エニーキャストなし) |
| 構成の違い | ||
| パス パターンの構文 |
/path/* または正確に /path |
正規表現パターン、パス マップ |
| WAF ルール セット | 既定の規則セット (OWASP)、ボット マネージャールールセット、HTTP DDoS ルールセット | 既定の規則セット (OWASP)、ボット マネージャールールセット、HTTP DDoS ルールセット |
| ヘルスプローブの評価 | ルーティングのレイテンシーと正常性 | 健康状態のみ |
| バックエンドの選択 | 優先度、重み、待機時間に基づく | ラウンド ロビン、Cookie のアフィニティ |
| ルーティング ルール | ||
| パスベースのルーティング | ✓ はい | ✓ はい |
| パターン照合 | 完全一致パス、ワイルドカードパス (/*)、大文字と小文字の区別はありません、ワイルドカードは必ず / の前に置かれる必要があります。 |
URL パス マップ、パスベースのルール、サポートされている正規表現パターン |
| ホストベースのルーティング | ✓ 複数のフロントエンド ホスト | ✓ マルチサイト ホスティング |
| URL 書き換え | 静的パスへの静的パス (クラシック) | URL パスの書き換え |
| ルーティング方法 | 優先度、重み、待機時間ベース | 負荷に敏感なレイテンシー最適化*、重み付け*、セッション アフィニティ (*Application Gateway for Containers で使用可能) |
| ルーティング機能 | ||
| ルールエンジン／リライトルール | 条件とアクションを含むルール セット | 条件とアクションを使用してルール セットを書き換える |
| パス パターンの正規表現 | 一致するパターンではサポートされていません | PCRE でサポートされる |
| ヘッダーと要求の操作 | ||
| ヘッダーの書き換え | ✓ 要求ヘッダーと応答ヘッダー | ✓ 要求ヘッダーと応答ヘッダー |
| ヘッダー値の文字制限 | 文書化された制限なし | 書き換えルールで 1,000 文字 |
| ホスト ヘッダーの書き換え | ✓ サポート | ✓サポートされています(外部ドメインに書き換えることはできません) |
| サーバー変数 | ✓ サポート | ✓ サポート |
| ヘッダー パターンマッチング | パターンを含む条件 | 正規表現パターン マッチング |
| セキュリティ機能 | ||
| WAF の可用性 | ✓ 省略可能 (Premium レベル) | ✓ 省略可能 (WAF レベル) |
| L3/4 DDoS 保護 | ✓ 組み込み | Azure DDoS Protection サービス経由 |
| SSL/TLS ポリシー | ✓ 構成可能 | ✓ 構成可能 |
| エンド ツー エンド SSL | ✓ サポート | ✓ サポート |
| Private Link のサポート | ✓ Premium レベル | ✓ V2 レベル |
| WAF カスタム規則 | ✓ サポート | ✓ サポート |
WAF の違い
| Azure Front Door | Application Gateway |
|---|---|
| Microsoft 既定の規則セット (DRS) 2.1 | OWASP Core Rule Set (CRS) 3.2 または 4.0 |
| ルール ID: 949xxx シリーズ | ルール ID: 9xxxxx シリーズ |
| Azure Front Door WAF (DRS): 最初の 128 KB の要求本文を検査します | Application Gateway WAF (CRS 3.2 以降): 最大 2 MB の検査。4 GB ファイルのアップロード。強制と検査を個別に構成できます。 |
推奨事項
WAF ごとに個別のルール セットを保持する必要があるため、ベースラインとして Azure Front Door ルール セットを使用します。 Azure Front Door 規則セットとできるだけ密接に一致する Application Gateway 規則セットを作成します。
Application Gateway WAF を個別に個別にテストします。
両方のプラットフォームのすべてのカスタム除外を文書化します。
規則セットの整合性を定期的に監査します。
Azure Application Gateway インフラストラクチャ構成のネットワーク ガイダンスに従ってください。 次の仮想ネットワークとサブネットの要件を必ず実行してください。
次のサブネットのサイズ設定 (リージョンごと) を使用します。
最小: /27 (32 アドレス)
推奨: 自動スケーリングとヒットレス メンテナンス用の /24 (256 アドレス)
数式: (最大インスタンス数 * 10) + 5 Azure 予約 IP
例: →最大インスタンス数 20 (20 * 10) + 5 = 205 IP →使用/24
最適なセキュリティを確保するには、Application Gateway 専用のサブネットを使用します (他のリソースは使用しません)。
受信接続で次のことが許可されていることを確認します。
インターネット (または特定のソース範囲) から 443/80
Azure Gateway Manager からの 65200-5535 (Application Gateway v2)
Azure Load Balancer
他の受信接続をブロックします。 必要な送信インターネット接続をブロックしないでください。
バックエンドのセグメント化と最小特権の規則には、アプリケーション セキュリティ グループを使用します。
容量計画と自動スケーリング戦略については、 Azure Application Gateway v2 のアーキテクチャのベスト プラクティスに関するページを参照してください。
主要な実装手順
手順 1: 前提条件をプロビジョニングする
カスタム ドメインと BYO 証明書を使用して構成された Azure Front Door。
Azure Front Door が最も低い時間設定へのトラフィックを処理できるように、CNAME レコードの DNS TTL が低くなります。
仮想ネットワーク、Application Gateway インスタンス、Traffic Manager インスタンスを作成するためのアクセス許可を持つ Azure サブスクリプション。
Azure Key Vault の SSL/TLS 証明書、またはアップロードに使用できます。
Azure 仮想ネットワークからアクセスできる配信元サーバー。
Important
現在 Azure Front Door で管理されている証明書を使用している場合は、このソリューションを実装する前に BYO 証明書に移行する必要があります。 Azure Front Door で管理される証明書をエクスポートして、代替 CDN にインストールすることはできません。 詳細については、「 Azure Front Door カスタム ドメインで HTTPS を構成する」を参照してください。
手順 2: 最初のリージョンに Application Gateway をデプロイする
Application Gateway のネットワーク インフラストラクチャを作成します。 詳細については、「Application Gateway インフラストラクチャの構成」を参照してください。
マネージド ID を作成し、Key Vault にアクセス権を付与します。 詳細については、「Key Vault 証明書での SSL 終了」を参照してください。
Application Gateway には、秘密キーを含む PFX 形式の SSL/TLS 証明書が必要です。 証明書には、Key Vault からアクセスするか、直接アップロードする必要があります。 Azure Front Door と同じ証明書を使用して、一貫した TLS 動作を確保します。
WAF ポリシーを作成します。 詳細については、「 Application Gateway の WAF ポリシーを作成する」を参照してください。
HTTPS と WAF を使用して Application Gateway インスタンスを作成します。 詳細については、「 TLS 終端を使用して Application Gateway インスタンスを構成する」を参照してください。
バックエンド ホスト ヘッダーを構成します。 詳細については、「 Application Gateway でのバックエンドの正常性に関する問題のトラブルシューティング」を参照してください。
Application Gateway を確認します。
# Get Application Gateway public IP $APPGW_IP = az network public-ip show ` --name $APPGW_PIP_NAME_R1 ` --resource-group $RESOURCE_GROUP ` --query ipAddress -o tsv Write-Host "Application Gateway IP: $APPGW_IP" # Test Application Gateway directly (SkipCertificateCheck because certificate is for domain, not IP) Invoke-WebRequest -Uri "https://$APPGW_IP/index.html" -Method Head -SkipCertificateCheck予想される結果は状態コード 200 です。 "502 Bad Gateway" が表示される場合は、バックエンドの HTTP 設定で
--host-name-from-backend-pool trueが有効になっていることを確認してください。
手順 3: WAF ポリシー設定を構成する (省略可能)
既定では、WAF は検出モードで作成されます。 防止モードでは、悪意のある要求がアクティブにブロックされます。 運用環境で防止モードを有効にする前に、十分にテストしてください。
グローバル トラフィック パターンを評価し、意味のあるユーザー ボリュームを持つリージョンに Application Gateway インスタンスをデプロイします。 Application Gateway を複数のリージョンにデプロイする場合は、追加リージョンごとに手順 2 と 3 を繰り返します (たとえば、米国西部 2)。 異なる仮想ネットワーク アドレス空間 (10.2.0.0/16、10.3.0.0/16 など) とリージョン固有の変数サフィックス (R2、R3 など) を使用します。
手順 4: Application Gateway WAF エンドポイントをサポートする Traffic Manager アーキテクチャを作成する
このシナリオの図で前述したように、パフォーマンス モードでセカンダリ Traffic Manager インスタンスを作成します。 詳細については、「 Traffic Manager プロファイルの作成」を参照してください。
単一リージョン構成の場合は、次の詳細を使用します。
- ルーティング方法: 優先順位。
- エンドポイント: 単一 Application Gateway のパブリック IP アドレス。
複数リージョン構成の場合は、次の詳細を使用します。
- ルーティング方法: パフォーマンス (最も正常な Application Gateway インスタンスにユーザーをルーティングします)。
- エンドポイント: 複数のリージョンにまたがる複数の Application Gateway パブリック IP アドレス。
- エンドポイントの場所: 各エンドポイントの Azure リージョン (パフォーマンス ルーティングに必要)。
次の構成設定を使用します。
Setting 価値 注記 ルーティング方法 パフォーマンス (複数リージョン) または 優先度 (単一リージョン) パフォーマンス により、複数リージョン構成の待機時間が最適化されます。 プロトコル HTTPS HTTPS を使用して Application Gateway の正常性を検証します。 ポート 443 標準 HTTPS ポート。 Path /healthまたは/index.htmlApplication Gateway バックエンド正常性プローブのパスと一致する必要があります。 TTL 300 秒 DNS クエリの負荷と応答性のバランスを取ります。 注
既定では、Application Gateway 用の Azure パブリック IP には DNS 名が構成されていません。 パブリック IP アドレスは、DNS 名ではなく Traffic Manager エンドポイントで直接使用する必要があります。
--endpoint-locationパラメーターは、地理的ルーティングを有効にするためにパフォーマンス ルーティングに必要です。このシナリオにおいて、以前の図に示されたように、プライマリの重み付けされた常時サービスのTraffic Managerインスタンスを作成します。 詳細については、「 Traffic Manager プロファイルの作成」を参照してください。
両方のエンドポイントで、次の構成を使用します。
Setting 価値 注記 ルーティング方法 重み付け エンドポイントの状態 (有効または無効) による手動制御を許可します。 重量 100 プロトコル HTTPS SSL/TLS エンドポイントを検証するために必要です。 ポート 443 標準 HTTPS ポート。 Path /index.htmlヘルスチェック用の軽量エンドポイントを選択します。 TTL 300 秒 DNS TTL。 値を小さくすると、フェールオーバーが高速化されますが、DNS クエリは増加します。 ヘルスチェック 常にトラフィックを処理する 正常性チェックを有効にしないでください。 これらの構成は、プライマリ エンドポイントに固有です。
型: 外部エンドポイント
名前: endpoint-afd-primary
完全修飾ドメイン名 (FQDN) または IP アドレス: Azure Front Door エンドポイントのホスト名 (
myapp-12345.z01.azurefd.netなど)エンドポイントの有効化: 選択済み (有効)
カスタム ヘッダー設定:
Host=$CUSTOM_DOMAIN(Azure Front Door が正しいカスタム ドメインにルーティングするために必要)正常性チェック: 常にトラフィックを処理する (正常性チェックを無効にする)
これらの構成は、セカンダリ エンドポイントに固有です。
型: 外部エンドポイント
名前: endpoint-appgw-secondary
完全修飾ドメイン名 (FQDN) または IP アドレス: セカンダリ Traffic Manager FQDN (たとえば、
myapp-appgw.trafficmanager.net)エンドポイントを有効にする: クリア (無効)
Traffic Manager の正常性を確認します。
# Check endpoint health status az network traffic-manager profile show ` --name $ATM_PRIMARY_PROFILE ` --resource-group $RESOURCE_GROUP ` --query "{ProfileStatus:profileStatus, MonitorStatus:monitorConfig.profileMonitorStatus, Endpoints:endpoints\[\].{Name:name, Target:target, Priority:priority, Status:endpointMonitorStatus}}"両方のエンドポイントに
Status: Onlineが表示されます。 エンドポイントにDegradedまたはCheckingEndpointが表示される場合は、正常性プローブが完了するまで 1 ~ 2 分待ちます。
手順 5: DNS CNAME を Traffic Manager に更新し、更新プログラムを確認する
Warnung
次の手順では、運用トラフィックを Azure Front Door から Traffic Manager に直接リダイレクトし、サービスに影響を与える可能性があります。 続行する前に、次の手順を実行します。
- 最初に非運用環境でこれらの手順をテストします。 たとえば、非運用ワークステーション上のローカル
hostsファイルを一時的に変更して、カスタム ドメインを Traffic Manager エンドポイントに解決します。 この変更により、ライブ トラフィックに影響を与えることなく検証が可能になります。 - 変更を加える少なくとも 24 時間前に、DNS CNAME TTL を可能な限り小さい値 (たとえば、60 ~ 300 秒) に減らします。
- 可能であれば、トラフィックの少ない期間中にメンテナンス期間を計画します。
- 問題が発生した場合に備え、ロールバック手順を準備します。
Azure Front Door に直接ではなく、プライマリ Traffic Manager インスタンスを指すように DNS CNAME レコードを更新します。
フィールド 古い値 新しい値 名前/ホスト www www (変更なし) 値/参照先 Azure Front Door エンドポイントのホスト名 $ATM_DNS_NAME.trafficmanager.netTraffic Manager の解決を確認します:
# Verify Traffic Manager profile is resolving nslookup "$ATM_DNS_NAME.trafficmanager.net"テストでは、Azure Front Door エンドポイントの IP アドレスを返す必要があります。
DNS 伝達を待ってから、HTTPS 接続をテストします。 DNS の伝達には通常 5 ~ 10 分かかりますが、グローバルに最大で 48 時間かかる場合があります。
# Check DNS from different resolvers nslookup $CUSTOM_DOMAIN 8.8.8.8 # Google DNS # Test HTTPS connectivity Invoke-WebRequest -Uri "https://$CUSTOM_DOMAIN/index.html" -Method Headこのテストでは、状態コード 200 が返されます。
DNS カットオーバー後、次の Azure Front Door メトリックを積極的に監視します。
要求数: トラフィックが減少せず、カウントは一貫性を保つ必要があります。
応答時間: 時間は通常の範囲内に留める必要があります。
エラー率: 4xx/5xx エラーは増やさないでください。
配信元の正常性: バックエンドの正常性は
Onlineのままにする必要があります。
手順 6: フェールオーバー手順をテストする
Azure Front Door の障害をシミュレートする (Application Gateway への手動フェールオーバー):
# Manual failover to Application Gateway # Disable Azure Front Door endpoint az network traffic-manager endpoint update ` --name "endpoint-afd-primary" ` --profile-name $ATM_PRIMARY_PROFILE ` --resource-group $RESOURCE_GROUP ` --type externalEndpoints ` --endpoint-status Disabled # Enable secondary Traffic Manager endpoint (Application Gateway) az network traffic-manager endpoint update ` --name "endpoint-appgw-secondary" ` --profile-name $ATM_PRIMARY_PROFILE ` --resource-group $RESOURCE_GROUP ` --type externalEndpoints ` --endpoint-status Enabled # Verify Traffic Manager endpoint status az network traffic-manager endpoint list ` --profile-name $ATM_PRIMARY_PROFILE ` --resource-group $RESOURCE_GROUP ` --query "[].{Name:name, Status:endpointStatus, Health:endpointMonitorStatus}" ` --output table # Flush DNS cache (Windows) ipconfig /flushdns # Verify DNS resolution (should now point to secondary Traffic Manager instance and Application Gateway) nslookup $CUSTOM_DOMAIN # Test - should now work via Application Gateway curl --head https://$CUSTOM_DOMAIN/注
DNS TTL はフェールオーバー時間に影響します。 TTL が 60 秒の場合、クライアントが変更を確認するのに最大 60 秒かかる場合があります。
nslookupを使用して、解決が Application Gateway を指していることを確認します。Azure Front Door にフェールバックする:
# Re-enable Azure Front Door endpoint az network traffic-manager endpoint update ` --name "endpoint-afd-primary" ` --profile-name $ATM_PRIMARY_PROFILE ` --resource-group $RESOURCE_GROUP ` --type externalEndpoints ` --endpoint-status Enabled # Disable Application Gateway (via Secondary Traffic Manager) az network traffic-manager endpoint update ` --name "endpoint-appgw-secondary" ` --profile-name $ATM_PRIMARY_PROFILE ` --resource-group $RESOURCE_GROUP ` --type externalEndpoints ` --endpoint-status Disabled # Verify endpoint status az network traffic-manager endpoint list ` --profile-name $ATM_PRIMARY_PROFILE ` --resource-group $RESOURCE_GROUP ` --query "[].{Name:name, Status:endpointStatus, Health:endpointMonitorStatus}" ` --output table # Flush DNS cache (Windows) ipconfig /flushdns # Verify DNS resolution (should now point back to Azure Front Door) nslookup $CUSTOM_DOMAIN # Test - should now work via Azure Front Door curl --head https://$CUSTOM_DOMAIN/現在のルーティングを確認します。
# Check which endpoint is serving traffic nslookup $CUSTOM_DOMAIN Invoke-WebRequest -Uri "https://$CUSTOM_DOMAIN/index.html" -Method Head | Select-Object -ExpandProperty Headers応答ヘッダーは、サービス エンドポイントを識別するのに役立ちます。
- Azure Front Door には、
x-azure-refヘッダーが含まれています。 - Application Gateway を通過するトラフィックには、
Server: Microsoft-IISなどがあります。
- Azure Front Door には、
シナリオ 2: Azure Front Door から代替 CDN への Traffic Manager フェールオーバー
このソリューションでは、重み付け/常時サービス ルーティングを使用する 1 つの Traffic Manager プロファイルを使用するため、Azure Front Door と代替 CDN の間でトラフィックを手動で切り替えることができます。
プライマリ エンドポイント: Azure Front Door カスタム ドメイン エンドポイント。
セカンダリ エンドポイント: 代替 CDN エンドポイント。
トラフィック フロー (通常の操作): ユーザー → DNS クエリ → Traffic Manager (重み付け/always-serve ルーティング) → Azure Front Door (優先度 1) → 配信元サーバー。
トラフィック フロー (Azure Front Door 障害):代替 CDN (優先順位 2) →配信元サーバー→ Traffic Manager (重み付け/常時配信ルーティング) →ユーザー → DNS クエリ。
主要な実装手順
手順 1: 前提条件をプロビジョニングする
次を使用してセカンダリ CDN プロバイダーを構成します。
カスタム ドメインと BYO 証明書で構成された Azure Front Door。
代替 CDN アカウント。
Azure Front Door が最も低い時間設定へのトラフィックを処理できるように、CNAME レコードの DNS TTL が低くなります。
Azure Front Door と代替 CDN の両方がアクセスできる配信元サーバー。
DNS レコードを変更できるカスタム ドメイン。
Important
現在 Azure Front Door で管理されている証明書を使用している場合は、この HA ソリューションを実装する前に BYO 証明書に移行する必要があります。 Azure Front Door で管理される証明書をエクスポートして、代替 CDN にインストールすることはできません。 BYO 証明書の詳細と構成手順については、「 Azure Front Door カスタム ドメインでの HTTPS の構成」を参照してください。
手順 2: 代替 CDN を構成する
セカンダリ CDN プロバイダーを構成します。
カスタム ドメインで CDN ゾーンまたはプロパティを設定します。
配信元サーバーは、Azure Front Door バックエンド プールを構成したのと同じ方法で構成します。
BYO SSL/TLS 証明書をアップロードします。 この証明書は、Azure Front Door で使用した証明書と同じです。
Azure Front Door の動作に一致するように CDN キャッシュ規則を構成します。 たとえば、キャッシュ期間とクエリ文字列の処理を構成します。
Azure Front Door の構成に合わせて、キャッシュ設定、制御ヘッダー、および圧縮設定を設定します。
CDN プロバイダーが WAF 機能を提供する場合は、WAF ルールを設定します。 Azure Front Door WAF ポリシーを一致させることを試みてください。
Azure Front Door カスタム ドメイン (
www.contoso.comなど) と一致するようにカスタム ドメインを構成します。Traffic Manager 構成の CDN エッジのホスト名 (たとえば、
your-site.cdn.provider.net) を記録します。
手順 3: Traffic Manager プロファイルを作成する
Traffic Manager プロファイルを作成するには、次の構成を適用します。 詳細については、「 Traffic Manager プロファイルの作成」を参照してください。
| Setting | 価値 | 注記 |
|---|---|---|
| ルーティング方法 | 重み付け | エンドポイントの状態 (有効または無効) による手動制御を許可します。 |
| 重量 | 100 | Traffic Manager プロファイルが作成されるときに、両方のエンドポイントに 100 を入力します。 |
| プロトコル | HTTPS | SSL/TLS エンドポイントを検証するために必要です。 |
| ポート | 443 | 標準 HTTPS ポート。 |
| Path | /index.html |
ヘルスチェック用の軽量エンドポイントを選択します。 |
| TTL | 300 秒 | DNS TTL。 値を小さくすると、フェールオーバーが高速化されますが、DNS クエリは増加します。 |
手順 4: Traffic Manager エンドポイントを構成する
Traffic Manager プロファイル内に 2 つのエンドポイントを作成します。
プライマリ エンドポイント (Azure Front Door) には、次の構成を使用します。
型: 外部エンドポイント
名前：endpoint-afd-primary
完全修飾ドメイン名 (FQDN) または IP アドレス: Azure Front Door エンドポイントのホスト名 (
myapp-endpoint-12345.z01.azurefd.netなど)重量: 100
エンドポイントを有効にする: 最初に選択 (有効)
カスタム ヘッダー設定:
Host=$CUSTOM_DOMAIN(Azure Front Door が正しいカスタム ドメインにルーティングするために必要)正常性チェック: 常にトラフィックを処理する (正常性チェックを無効にする)
注
--custom-headers "Host=$CUSTOM_DOMAIN" パラメーターは、Azure Front Door エンドポイントにとって重要です。 これを使用しないと、Azure Front Door がカスタム ドメイン構成に要求を適切にルーティングできない可能性があります。 これは、Azure Traffic Manager でサポートされている機能です。
セカンダリ エンドポイント (代替 CDN) には、次の構成を使用します。
型: 外部エンドポイント
名前: endpoint-cdn-secondary
完全修飾ドメイン名 (FQDN) または IP アドレス: CDN エッジのホスト名 (
myapp.cdn.netなど)重量: 100
エンドポイントを有効にする: スタンバイ モードで初期状態ではクリアされています (無効)
手順 5: DNS CNAME を Traffic Manager に更新し、更新プログラムを確認する
Warnung
次の手順では、運用トラフィックを Azure Front Door から Traffic Manager に直接リダイレクトします。 続行する前に、次の手順を実行します。
- 最初に非運用環境でこれらの手順をテストします。
- 変更を加える少なくとも 24 時間前に、DNS CNAME TTL を可能な限り小さい値 (たとえば、60 ~ 300 秒) に減らします。
- 可能であれば、トラフィックの少ない期間中にメンテナンス期間を計画します。
- 問題が発生した場合に備え、ロールバック手順を準備します。
Azure Front Door に直接ではなく Traffic Manager を指すように DNS CNAME レコードを更新します。
フィールド 古い値 新しい値 名前/ホスト www www (変更なし) 値/参照先 Azure Front Door エンドポイントのホスト名 $ATM_CDN_DNS_NAME.trafficmanager.netDNS の伝達には通常 5 ~ 10 分かかりますが、グローバルに最大で 48 時間かかる場合があります。
Traffic Manager の解決を確認します。 DNS 伝達を待ってから、HTTPS 接続をテストします。
# Verify Traffic Manager profile is resolving nslookup "$ATM_CDN_DNS_NAME.trafficmanager.net" # Expected result: Should return IP address of Azure Front Door endpoint # Check DNS from different resolvers nslookup $CUSTOM_DOMAIN 8.8.8.8 # Google DNS # Test HTTPS connectivity Invoke-WebRequest -Uri "https://$CUSTOM_DOMAIN/index.html" -Method Head # Expected result: Status code 200DNS カットオーバー後、次の Azure Front Door メトリックを積極的に監視します。
要求数: トラフィックが減少せず、カウントは一貫性を保つ必要があります。
応答時間: 時間は通常の範囲内に留める必要があります。
エラー率: 4xx/5xx エラーは増やさないでください。
オリジンの正常性: バックエンドの正常性は
Onlineのままにする必要があります。
手順 6: フェールオーバー手順をテストする
代替 CDN に手動でフェールオーバーします。
# Failover: Disable Azure Front Door and enable CDN az network traffic-manager endpoint update ` --name "endpoint-afd-primary" ` --profile-name $ATM_CDN_PROFILE_NAME ` --resource-group $RESOURCE_GROUP ` --type externalEndpoints ` --endpoint-status Disabled az network traffic-manager endpoint update ` --name "endpoint-cdn-secondary" ` --profile-name $ATM_CDN_PROFILE_NAME ` --resource-group $RESOURCE_GROUP ` --type externalEndpoints ` --endpoint-status Enabled # Verify endpoint status az network traffic-manager profile show ` --name $ATM_CDN_PROFILE_NAME ` --resource-group $RESOURCE_GROUP ` --query "endpoints[].{Name:name, Status:endpointStatus, Health:endpointMonitorStatus, Target:target}" # Flush local DNS cache and verify resolution ipconfig /flushdns nslookup "$ATM_CDN_DNS_NAME.trafficmanager.net" # Test HTTPS access curl --head https://$CUSTOM_DOMAIN/Azure Front Door にフェールバックする:
# Failback: Enable Azure Front Door, disable CDN az network traffic-manager endpoint update ` --name "endpoint-afd-primary" ` --profile-name $ATM_CDN_PROFILE_NAME ` --resource-group $RESOURCE_GROUP ` --type externalEndpoints ` --endpoint-status Enabled az network traffic-manager endpoint update ` --name "endpoint-cdn-secondary" ` --profile-name $ATM_CDN_PROFILE_NAME ` --resource-group $RESOURCE_GROUP ` --type externalEndpoints ` --endpoint-status Disabled # Verify az network traffic-manager profile show ` --name $ATM_CDN_PROFILE_NAME ` --resource-group $RESOURCE_GROUP ` --query "endpoints[].{Name:name, Status:endpointStatus, Health:endpointMonitorStatus}"
モニタリング
Important
障害が発生した場合にすぐにアラートを生成するように合成モニターを構成します。 これらのアラートは、自動フェールオーバーが不十分な場合に手動フェールオーバーをトリガーする必要があります (たとえば、Traffic Manager で検出できない Azure Front Door カスタム ドメインの問題)。
運用環境では、次の監視ソリューションをお勧めします。
Azure Monitor ワークブック: Traffic Manager クエリ、Azure Front Door のリクエスト、および Application Gateway の正常性を追跡します。 詳細については、 ワークブックの概要を参照してください。
グローバルな Azure Front Door の問題を検出するための外部監視: エンドポイントを監視するために、外部のグローバル合成監視ソリューション (Catchpoint や ThousandEyes など) を実装します。 WebPageTest のようなサービスは、限られたグローバル可視性を提供する無料の代替手段を提供します。
Application Insights 可用性テスト: 複数リージョンの HTTP チェックを使用します。 詳細については、「 Application Insights 可用性テスト」を参照してください。
DNS 監視: DNSPerf、Pingdom、または Uptime.com を使用して、CNAME 解決チェーンと TTL 伝達を検証します。
証明書の監視: Qualys SSL Labs の SSL サーバー テスト を使用して、サーバーの構成を分析します。