この記事では、複数のリージョンにまたがるAzure ネットワークを設計する方法について説明します。 マルチリージョン ネットワークは、リージョンの停止に対する高可用性を提供し、地理的に分散したユーザーの待機時間を短縮し、規制データ所在地の要件をサポートします。
この記事の内容
この記事では、ゾーンとリージョン間の冗長性、リージョン間ルーティング戦略、マルチリージョン デプロイのハブ トポロジの選択、アクティブ/アクティブとアクティブ/パッシブのフェールオーバー パターン、レプリケーションの待機時間に関する考慮事項について説明します。
この記事が必要なユーザー
環境が次のいずれかの条件に一致する場合は、この記事をお読みください。
- ワークロードには、完全なAzure リージョンの障害に対するディザスター リカバリー保護が必要です。
- 複数の地域でユーザーにサービスを提供するため、ネットワーク待ち時間を最小限に抑える必要があります。
- 規制またはコンプライアンスの要件では、データが特定の地理的境界内に留まる必要があります。
- ビジネス継続性の目標では、1 つのリージョンだけでは達成できない目標復旧時間 (RTO) を定義します。
ワークロードが 1 つのリージョンで動作し、ゾーン冗長デプロイが可用性要件を満たしている場合は、マルチリージョン設計がまだ必要ない場合があります。 ハブアンドスポーク トポロジまたは 1 つのリージョンでVirtual WANを開始し、後で拡張します。
リフトアンドシフト重視: レガシーワークロードは、多くの場合、リージョン間でアクティブ/アクティブ構成で稼働できません。 完全なアクティブ/アクティブ設計ではなく、Azure Site Recoveryと復旧リージョン内のハブを使用してディザスター リカバリーを計画します。
フォーカスを最新化する: リージョンが必要に応じてピアリングできるように、重複しないアドレス空間を使用して、ゾーン冗長 SKU を持つ 2 つのリージョンに顧客向けのアプリをアクティブ/アクティブにデプロイします。
クラウド間のフォーカス:Azure Virtual WANを使用して複数のリージョンとブランチを接続し、クラウド間のトランジットと共にリージョン間ルーティングを計画します。
Azureサービスと機能
次の表に、マルチリージョン ネットワークを有効にするAzureサービスと機能を示します。
| サービスまたは機能 | マルチリージョン設計での役割 | 詳細情報 |
|---|---|---|
| Azure Traffic Manager | 任意のプロトコルのリージョン間の DNS ベースのトラフィック ルーティング | Traffic Manager の概要 |
| Azure Front Door | エッジで CDN と WAF を使用した HTTP/HTTPS グローバル負荷分散 | Front Door の概要 |
| グローバル VNet ピアリング | 異なるリージョンの仮想ネットワーク間のプライベートで高帯域幅の接続 | 仮想ネットワーク ピアリング |
| ExpressRoute Global Reach | Azure バックボーンを介してオンプレミス サイトを相互に接続する | ExpressRoute Global Reach |
| Azure Virtual WAN (マルチハブ) | Microsoft が管理するグローバル トランジットとハブ間の自動ルーティング | Virtual WAN グローバル トランジット |
| Azure Virtual Network Manager (AVNM) | リージョン間ピアリング トポロジとネットワーク グループ管理を自動化します | AVNM の概要 |
マルチリージョンで複数の仮想ネットワークが必要な理由
仮想ネットワーク (VNet) は、1 つのリージョンにまたがる。 その VNet 内のサブネットはリージョン内のすべての可用性ゾーンにまたがっていますが、VNet 自体はリージョンの境界を越えて拡張することはできません。 したがって、マルチリージョン ネットワークとは、リージョンごとに 1 つ以上の複数の VNet をデプロイし、リージョン間サービスで接続することを意味します。
この基本的な制約は、すべてのマルチリージョン 設計を構成します。
- 各リージョンには、独自の VNet アドレス空間が必要です (ピアリングのために他のリージョンと重複しない)。
- リージョン間トラフィックには、グローバル VNet ピアリング、Virtual WANハブ間、またはゲートウェイ ベースのルーティングという明示的な接続メカニズムが必要です。
- グローバル負荷分散サービス (Traffic Manager または Front Door) は、ユーザーを適切なリージョンデプロイに誘導します。
サブネットとアドレス計画のガイダンスについては、 IP アドレスの計画に関するページを参照してください。
可用性ゾーンとリージョン冗長
マルチリージョン トポロジを設計する前に、Azureの 2 つのレベルのインフラストラクチャ冗長性を理解してください。
| Level | 保護対象 | メカニズム | 例 |
|---|---|---|---|
| 可用性ゾーン | リージョン内の単一データセンターの障害 | 独立した電源、冷却、ネットワークを使用してデータセンターを物理的に分離する | 3 つのゾーンにまたがってデプロイされたゾーン冗長な Azure Firewall |
| リージョン冗長 | リージョン全体の障害 (自然災害、広範囲にわたる停止) | 2 つ以上のAzure リージョンにワークロードをデプロイする | 米国東部および米国西部のアクティブな Web アプリケーション |
ゾーンの冗長性から始めます。 ゾーン冗長デプロイは、マルチリージョン ルーティングの複雑さなしに、最も一般的な障害シナリオ (単一データセンターの問題) から保護します。 ビジネスでリージョン全体の停止に対する保護が必要な場合、または地理的に分散したユーザーにサービスを提供する必要がある場合に、リージョンの冗長性を追加します。
ゾーン冗長ネットワーク サービス リファレンス
次の表は、コア ネットワーク サービスのゾーン冗長デプロイ オプションを示しています。 ワークロードを実行するすべてのリージョンにこれらをデプロイします。
| サービス | ゾーン冗長オプション | メモ |
|---|---|---|
| Azure Firewall | 可用性ゾーンをまたいだデプロイ | リージョン内の 3 つのゾーンすべてに分散します |
| Standard Load Balancer | ゾーン冗長フロントエンド | Standard SKU の既定の動作 |
| Application Gateway v2 | ゾーン冗長のデプロイ | Standard_v2またはWAF_v2 SKU が必要 |
| VPN Gateway | ゾーン冗長 SKU のアクティブ-アクティブ構成 | AZ 接尾辞付き SKU (VpnGw1AZ、VpnGw2AZ など) を使用する |
| ExpressRoute ゲートウェイ | ゾーン冗長 SKU | ErGw1AZ、ErGw2AZ、または ErGw3AZ を使用する |
| Azure Bastion | ゾーン冗長構成 (プレビュー) | Basic、Standard、Premium の SKU |
| NAT ゲートウェイ (StandardV2) | ゾーン冗長 | StandardV2 SKU が必須です；Standard SKU はゾーン限定です |
リージョン間のトラフィック ルーティングアプローチを選択する方法
次の決定表を使用して、リージョン間でトラフィックをルーティングするための適切なサービスを選択します。
| 要件 | 推奨されるサービス | どのように機能するのか |
|---|---|---|
| 任意のプロトコル (HTTP、TCP、UDP) のマルチリージョン フェールオーバーまたは負荷分散 | Azure Traffic Manager | DNS 解決によって最適なエンドポイント IP を返します。 クライアントはエンドポイントに直接接続します。 フェールオーバー速度は DNS TTL (通常は 30 ~ 300 秒) に依存します。 |
| CDN、WAF、高速フェールオーバーによるグローバル HTTP/HTTPS 負荷分散 | Azure Front Door | エッジ PoP で接続を終端します。 最も近い正常なバックエンドに要求をルーティングします。 接続レベルのフェールオーバーを提供します (秒、DNS-TTL 依存しません)。 |
| リージョン間のプライベート バックエンド トラフィック (レプリケーション、内部 API) | グローバル VNet ピアリング | Microsoft バックボーン経由でリージョン間で VNet を接続します。 ピアリングは推移的ではありません。各ピアリング関係は明示的です。 Per-GB データ転送料金が適用されます。 |
| Azureを介したオンプレミスのサイト間接続 | ExpressRoute Global Reach | 2 つの ExpressRoute 回線を接続するため、オンプレミスの場所はハブ ルーターを経由せずにMicrosoftバックボーン経由で通信します。 |
Tip
これらのサービスを組み合わせます。 たとえば、ユーザー向けの HTTP トラフィックには Front Door を使用し、リージョン間のバックエンド レプリケーションにはグローバル VNet ピアリングを使用します。
マルチリージョン ハブ トポロジを選択する方法
リージョン間でネットワークを拡張することを決定したら、リージョン間接続を管理するためのハブ パターンを選択します。
| 要因 | リージョンあたりのハブ数 (従来) | マルチハブのVirtual WAN |
|---|---|---|
| リージョン間の接続 | お客様がリージョン ハブ間でグローバル VNet ピアリングを構成し、UDR を管理する | ハブ間の自動ルーティング: すべてのVirtual WAN ハブが既定で相互接続されます |
| Management | ルーティング、ファイアウォール規則、ピアリングに対する完全な顧客制御 | ポリシー ベースの管理を使用したMicrosoftマネージド ハブ インフラストラクチャ |
| 最適な用途 | 詳細なルーティング制御、カスタム NVA、または既存のハブへの投資が必要な組織 | 多くのリージョン、30 以上のブランチ サイト、またはマネージド インフラストラクチャの優先設定を持つ組織 |
| グローバルトランジット | 各ハブ ペア間で明示的なピアリングと UDR 構成が必要 | 組み込み機能: 任意の 2 つのハブ間のトラフィックは自動的にルーティングされます |
| Scaling | ハブとピアリングを手動で追加する (AVNM は自動化できます) | Virtual WAN構成を使用してハブを追加する: 更新プログラムを自動的にルーティングする |
| コスト モデル | ハブ VNet リソース (ファイアウォール、ゲートウェイ、ピアリング) が個別に課金される | Virtual WANユニットの価格と接続されているリソース |
1 つのリージョンでのハブアンドスポークとVirtual WANの詳細な比較については、ハブアンドスポーク トポロジとVirtual WANに関する記事を参照してください。
設計上の考慮事項
リフトアンドシフトのマルチリージョン設計における重点
- ゾーンまたはリージョンにまたがることができないレガシ ワークロードの場合は、アクティブ/アクティブではなくディザスター リカバリー用に設計します。Azure Site Recoveryを使用して復旧リージョンにレプリケートします。
- フェールオーバー トラフィックに同じ共有サービスが含まれるように、プライマリ ハブをミラー化するハブを復旧リージョンに構築します。
- Azure Traffic Managerまたは DNS フェールオーバーを使用して、リージョンの停止中にユーザーをリダイレクトします。
- フェールオーバー中やそれ以降のピアリング中の競合を回避するために、復旧リージョンのアドレス空間をプライマリ リージョンと重複しないようにします。
複数リージョンの設計フォーカスを最新化する
- 最高レベルの回復性を実現するために、ゾーン冗長 SKU を使用して、2 つのリージョンにまたがって顧客向けワークロードをアクティブ/アクティブでデプロイしてください。
- 重複しないアドレス範囲をプライマリリージョンとバックアップリージョンに割り当てて、アクティブ/アクティブスポークが後で再アドレス指定せずにグローバル VNet ピアリングを使用できるようにします。
- アプリの種類別に配信レイヤーを選択します。Web アプリのAzure Front Doorと、Web 以外のアプリの場合は Traffic Manager を選択し、リージョンのパブリック エンドポイント間で配布します。
- バックエンドに到達する前に受信トラフィックが検査されるように、各リージョンのパブリック エンドポイントをハブ ファイアウォール (SNAT と DNAT) で前面に配置します。
クラウド間のマルチリージョン設計に重点を置く
- Azure Virtual WANを使用して、複数のAzureリージョン、ブランチ、クラウド エッジを自動の any-to-any ルーティングで相互接続します。
- リージョンとクラウド間で重複しないアドレス範囲を要約して計画し、トランジット ルーティングをシンプルに保ちます。
- リージョンのセキュリティで保護されたハブでクラウド間 IPsec 接続を終了し、ハブ間ルーティングVirtual WAN処理できるようにします。
- Front Door または Traffic Manager を使用してリージョン間でパブリック イングレスを分散し、各リージョン ハブ ファイアウォールで検査を続けます。
前提条件
マルチリージョン ネットワークを設計する前に、次の機能があることを確認してください。
- 単一リージョン トポロジをデプロイしてテストしました。 ハブアンドスポークまたはVirtual WANから始めます。
- 定義済みの高可用性とディザスター リカバリーの要件: RTO、目標復旧時点（RPO）、コンプライアンス要件。
- すべてのリージョンで重複しない IP アドレス プランを作成しました。 IP アドレスの計画を参照してください。
- リージョン冗長とゾーン冗長性のみを必要とするワークロードを特定しました。
アクティブ/アクティブとアクティブ/パッシブのデプロイ パターン
マルチリージョン デプロイ モデルは、通常の運用中とリージョン障害時のトラフィックフローを決定します。
Active-active
両方のリージョンが同時にトラフィックを処理します。 Traffic Manager や Front Door などのグローバル ロード バランサーは、近接性、パフォーマンス、または重みに基づいてリージョン間で要求を分散します。
アクティブ-アクティブを使用する場合:
- アプリケーションは、リージョン固有の状態の依存関係を持たない任意のリージョンの要求を処理できます。
- 可能な限り低い RTO が必要です (正常なリージョンが既にトラフィックを処理しているため、フェールオーバーは即時です)。
- 通常の運用中に両方のリージョンで容量を使用する必要があります (コスト効率)。
ネットワークに関する考慮事項:
- どちらのリージョンにも、ファイアウォール、ゲートウェイ、ロード バランサーなど、同じネットワーク インフラストラクチャが必要です。
- リージョン間のデータ レプリケーションでは、両方のデプロイを最新の状態に保つ必要があります。
- DNS TTL と正常性プローブの間隔によって、Traffic Manager がトラフィックをシフトする速度が決まります。 Front Door では、接続レベルのフェールオーバーが高速化されます。
Active-passive
1 つのリージョン (プライマリ) がすべてのトラフィックを処理します。 セカンダリ リージョンの準備は維持されますが、フェールオーバー イベントまでユーザー要求は処理されません。
アクティブ/パッシブを使用する場合:
- アプリケーションに厳密な書き込みリージョン要件がある場合、または状態を簡単にレプリケートすることはできません。
- コストの制約により、2 つのリージョンで完全な容量を同時に実行できなくなります。
- RTO 許容値を使用すると、セカンダリ リージョンのアクティブ化に必要な時間を指定できます。
ネットワークに関する考慮事項:
- パッシブ リージョンのネットワーク インフラストラクチャでは、フェールオーバーまで、より小さいレベルを使用したり、容量を減らしたりできます。
- 自動フェールオーバーには、フラッピングを防ぐための適切なしきい値が設定されたヘルス プローブが必要です。
- フェールオーバーを定期的にテストします。 パッシブ リージョンのネットワーク構成は、検証しないと誤差が出る可能性があります。
- リージョン間でルート テーブルと NSG ルールの同期を維持します。 コードとしてのインフラストラクチャ テンプレートを使用して、パッシブ リージョンがプライマリ リージョンのセキュリティ体制と一致することを確認します。
- パッシブ リージョンの VPN ゲートウェイまたは ExpressRoute ゲートウェイを事前プロビジョニングします。 ゲートウェイのプロビジョニングには 20 ~ 45 分かかる場合があります。 これは、ほとんどの RTO ターゲットでは遅すぎます。
アクティブ-アクティブ ネットワーク構成とアクティブ-パッシブ ネットワーク構成の選択
アクティブ/アクティブ/パッシブ ネットワークの選択は、ネットワークのサイズ、コスト、運用の複雑さに影響します。
| Consideration | Active-active | Active-passive |
|---|---|---|
| ネットワーク キャパシティ | 両リージョンで最大容量 | パッシブ リージョンでの容量の削減 (フェールオーバー時のスケール) |
| ゲートウェイのプロビジョニング | 両方のリージョンで常にオンにする | 事前プロビジョニング済みですが、より小さいレベルを使用できます |
| リージョン間のデータ同期 | 継続的な双方向レプリケーション トラフィック | スタンバイへの一方向の非同期レプリケーション |
| ファイアウォール規則 | 同じルール セット(両方ともアクティブに適用) | 同じルール セットですが、パッシブ セットはほとんど実行されない |
| IP アドレス指定 | 両方のリージョンがグローバル ロード バランサーにアドバタイズする | フェールオーバーまでプライマリ リージョンのみがアドバタイズされます |
| 運用上のリスク | 下位: 両方のパスが継続的に実行されます | 高: パッシブパスが徐々にずれたり、未検証の構成になったりする可能性があります |
データレプリケーションと待機時間
リージョン間レプリケーションでは、アプリケーションの設計に影響を与えるネットワーク待機時間が発生します。 同じ地域内のAzureリージョンでは、通常、近くのペア (米国東部から米国東部 2 など) のラウンド トリップ待機時間が 1 ~ 10 ミリ秒、離れたペア (米国東部から米国西部など) が 30 ~ 70 ミリ秒になります。 トランサトランティックまたは環太平洋領域のペアは 100 ミリ秒を超える可能性があります。
設計に関する主な考慮事項:
- レプリケーション トポロジ: 同期レプリケーションは、待機時間が短いリージョン ペア (< 10 ミリ秒) に対してのみ選択します。 アプリケーションのパフォーマンス低下を回避するには、遠隔ペアに非同期レプリケーションを使用します。
- 帯域幅の計画: レプリケーションのスループット要件を見積もり、GB 単位のグローバル VNet ピアリングのデータ転送コストを考慮します。 離れたリージョン間で大量のレプリケーションを行うと、大きなエグレス料金が発生する可能性があります。
- 競合の解決: 双方向書き込みを使用するアクティブ/アクティブ パターンでは、アプリケーション層またはデータベース 層での競合解決戦略が必要です。 ネットワークは接続を提供しますが、アプリケーションは書き込みの競合を処理する必要があります。
- PaaS レプリケーションのプライベート エンドポイント:リージョン間でAzure SQL、Cosmos DB、またはストレージをレプリケートする場合は、各リージョンのプライベート エンドポイントを使用して、レプリケーション トラフィックを Microsoft バックボーンに保持し、パブリック インターネットへの公開を回避します。
コストに関する考慮事項
マルチリージョン ネットワークでは、重複したインフラストラクチャとリージョン間のデータ転送によってコストが増加します。 次の主なコスト 要因に関する予算を計画します。
- リージョン間のデータ転送:グローバル VNet ピアリングとVirtual WANハブ間トラフィックでは、リージョン境界を越えるデータに対して GB 単位の料金が発生します。 同じリージョン内のピアリングされた VNet 間のリージョン内トラフィックは、同じゾーンに対して追加コストなしで、クロスゾーンの場合は低いレートで課金されます。
- 重複したネットワーク アプライアンス: 各リージョンには、独自のファイアウォール、ロード バランサー、ゲートウェイ インスタンスが必要です。 アクティブ-アクティブ構成では、これらのコストは2倍になります。 アクティブ/パッシブデプロイでは、スタンバイ リージョンで小さいレベルを使用し、フェールオーバー中にスケールアップすることで、コストを削減できます。
- グローバル負荷分散料金: 処理された DNS クエリまたは要求に基づいて、Traffic Manager と Front Door の両方が課金されます。 Front Door では、エッジ POP からバックエンドへのデータ転送に対して追加料金が発生します。
- ExpressRoute と VPN Gateway: マルチリージョン設計では、多くの場合、各リージョンにゲートウェイ インスタンスが必要です。 複数のリージョンを接続する ExpressRoute 回線では、毎月のポート料金と GB 単位の従量制課金データ料金が追加されます。
- トラフィックのローカリティを使用して最適化する: リージョン間の呼び出しを最小限に抑えるようにアプリケーション層を設計します。 読み取りレプリカを各リージョンのコンピューティングと併置して、レプリケーションの帯域幅と待機時間に依存するクエリを減らします。
セキュリティに関する考慮事項
マルチリージョン ネットワークでは、単一リージョンのデプロイ以外のセキュリティに関する考慮事項が導入されています。
- トラフィックは Microsoft バックボーンに残ります。 グローバル VNet ピアリングまたはハブ間接続Virtual WAN経由のすべてのリージョン間トラフィックは、パブリック インターネットではなく、Microsoftバックボーン ネットワークを経由します。
- すべてのリージョンにゾーン冗長ファイアウォールをデプロイします。 各リージョン ハブには、トラフィック検査用に独自のファイアウォール インスタンスが必要です。 可用性ゾーン間にファイアウォールをデプロイして、ゾーンの障害時にセキュリティを維持します。
- Front Door WAF はエッジ セキュリティを提供します。 Front Door を使用すると、その統合されたWeb Application Firewallは、リージョンデプロイに到達する前にトラフィックを検査します。 これにより、ネットワーク エッジでの防御の第 1 層が提供されます。
- DNS フェールオーバーを慎重に計画します。 Traffic Manager のフェールオーバーは DNS TTL に依存します。 TTL を短くすると、フェールオーバーの高速化が可能になりますが、DNS クエリ の量が増加します。 Front Door は、クライアント DNS キャッシュの有効期限に依存しない接続レベルのフェールオーバーを提供します。
- ExpressRoute Global Reach トラフィックはプライベートのままです。 Global Reach を介して接続されているオンプレミス サイト間のトラフィックは、パブリック インターネットにアクセスすることはありません。 回線間では、Microsoft バックボーン上に維持されます。
- リージョン間レプリケーション チャネルをセキュリティで保護する。 グローバル VNet ピアリング経由のバックエンド レプリケーション トラフィックは既定ではプライベートですが、転送中の機密データにネットワーク セキュリティ グループと暗号化を適用します。
関連資料
マルチリージョンの設計に、このガイドの他の場所で説明されている特定のシナリオが含まれている場合は、次を参照してください。
- ハブアンドスポーク トポロジ: マルチリージョン デプロイのリージョンごとのハブ設計パターン。
- Virtual WAN: 自動ハブ間ルーティングを備えた Virtual WAN のマルチハブ パターン。
- リージョン間接続: ピアリング、Global Reach、ハブ間接続オプションに関する詳細なガイダンス。
- VNet とサブネット: リージョンごとの VNet の設計とサブネットの計画。
- IP アドレス計画: リージョン間で重複しないアドレス空間。
- Azure Firewallとトラフィック検査: 各リージョン ハブでのゾーン冗長ファイアウォールのデプロイ。
詳細情報
この記事で説明するサービスと概念の詳細については、次のリソースを参照してください。
- Traffic Manager の概要
- Azure Front Door の概要
- 仮想ネットワーク ピアリングの概要
- ExpressRoute Global Reach
- グローバルトランジットネットワークアーキテクチャVirtual WAN
- Azure リージョンと可用性ゾーン
次のステップ
Tip
あなた自身で探検? 概要ナビゲーターに戻り、機能別に次の記事を見つけます。
リフトアンドシフト体験の次の手順:
オンプレミス ネットワークに接続する: ディザスター リカバリーを計画した後、オンプレミスへの VPN または ExpressRoute 接続を確立します。
次に、最新化の取り組みを行います。
インターネットのイングレス パターンを設計する: 顧客トラフィックがプライマリ リージョンとバックアップ リージョン全体でアプリケーションに到達する方法を決定します。
マルチクラウドへの移行における次のステップ:
暗号化されたトンネルを他のクラウドに設定する: マルチリージョンの計画が完了したら、クラウド間 VPN 接続を構成します。