ハイブリッドネットワークの高可用性設計: 複数回線・マルチリージョンによる冗長化戦略

Azure

Last updated at 2025-08-28Posted at 2025-08-28

企業のオンプレミス環境とAzureを安全かつ安定して結ぶハイブリッドネットワークにおいて、高可用性（HA）を確保するためには、単なる回線二重化だけでなく、複数の経路制御や複数リージョンへの冗長分散といった多面的な対策が必要となります。

とくに大規模エンタープライズでは、複数のExpressRoute回線とVPN併用、およびリージョン間ペアでのハブ & スポーク構成を使ったアクティブ-アクティブ構成を組み合わせる**ことで、「どの1つの故障でも業務に大きな影響が出ない」堅牢なアーキテクチャを実現できます。

本記事では、現在のMicrosoft公式ガイドやSLA要件、CIS・ISO/IEC 27001・NISTなどの可用性ガイドラインとも整合する、高可用性ネットワーク構成のベストプラクティスを、具体的な例とともに深掘り解説します。

1. ハイブリッドネットワークにおける高可用性の重要性

1.1 単一障害点のリスク
オンプレミスからクラウドへ一部システムを移行する際、障害要因として最も頻度の高いのがネットワーク回線の切断やルーター故障です。

エンタープライズ規模ではクラウドへのアクセス障害はビジネス停止に直結するため、単一の回線や単一の地域に依存している構成ではリスクが高すぎます。

さらに、クラウド内部でもリージョン障害やゲートウェイ障害などがゼロではないため、複数リージョンへの多重化を考慮しなければ万全とは言えません。

1.2 可用性を最大化する多層アプローチ
そこで大規模ネットワークの高可用性設計には、以下の多層対策を組み合わせるアプローチが有効です。

オンプレ→Azure経路の二重化

物理回線を別キャリア・別Peering Locationで構成した複数ExpressRoute回線

ExpressRoute回線 + VPNバックアップ（フェイルオーバー）

BGP制御とアクティブ-アクティブ冗長

プライマリ/セカンダリ回線を自動ルート切り替え

ASパスプリペンドやLocalPref等のBGP調整

リージョン冗長化

複数AzureリージョンにHub & Spoke展開（東日本と西日本など）

Global VNet PeeringやExpressRoute Global Reachで相互バックアップ

仮想ネットワーク内のサービス冗長

Azure Firewall冗長（複数ゾーン）・Route Server冗長化

アクティブ-アクティブ構成で片方障害時のフェイルオーバーを実装

監視と演習

Azure Monitor・Network WatcherでBGPセッションや可用性を常時チェック

想定シナリオごとのフェイルオーバーテストを定期的に実施

このような複数のレイヤーでの冗長設計により、いかなる1つの障害要因が発生してもネットワークがダウンしない「No single point of failure」を達成します。

1.3 単一リージョン内の可用性強化（AZ冗長）

マルチリージョンに加える前段として、単一リージョンでも可用性を底上げできます。
ExpressRoute / VPN の仮想ネットワークゲートウェイを Availability Zone に分散する **AZ 対応 SKU（例：ErGw1AZ / ErGw2AZ / ErGw3AZ、VpnGw2AZ など）**を選ぶと、ゾーン障害でも接続を継続しやすくなります（ゾーン分散＝物理/論理的な分離）。

※AZ冗長はリージョン全体の停止対策にはならないため、本稿の後半で述べるマルチリージョン冗長と併用するのが最善です

2. ExpressRoute回線の複数化とVPNフォールバック

2.1 異なるプロバイダ・ロケーションでの二重化
まず、最も基本的な高可用性対策が複数ExpressRoute回線です。

同一キャリア・同一Peering Locationでの「デフォルト冗長（主・副リンク）」は初歩的保護に過ぎず、物理障害やロケーション障害には耐性が弱い可能性があります。

そこで、異なるISPキャリアおよび異なるPeering Location（例：東京と大阪）で2回線を契約し、Azure側で2つのExpressRoute回線リソースを作成してそれぞれに帯域を割り当てます。

こうすることで、キャリア網障害や自然災害による片方拠点の断絶を回避でき、回線自体が同時にダウンするリスクを下げられます。

2.2 ExpressRoute + VPNのバックアップ
さらに万が一、2つのExpressRoute回線が同時に切れたケース（大規模なDCトラブル、光ケーブル路線破損など）にも備えるため、サイト間VPNをバックアップ回線として併用します。

Azureのcoexistence機能を使い、同じVNet内にExpressRoute GatewayとVPN Gatewayを共存させる構成が一般的です。平常時はExpressRouteのルートが優先され、ExpressRouteがダウンすると自動的にVPNルートへ切り替わるBGP制御となります。

VPNの帯域はExpressRouteより小さいことが多いですが、一時的に最低限の通信帯域を確保すればサービスを完全停止させずに済みます。

なお、ゲートウェイ自体の HA としては AZ 対応 SKU（ErGwAZ / VpnGwAZ）を選ぶと、ゾーン障害に対して復元力が高まります。

2.3 BGPフェイルオーバー
ExpressRoute GatewayやVPN Gateway間のルーティングはBGPにより自動切替されます。Azure側はそれぞれの経路に優先度を付けており、ExpressRouteのWeightを高く設定してあるため、通常はExpressRouteが選択され、障害時にVPNが活性化します（オンプレ側もBGPにより経路が切り替わります）。

さらにLocalPrefやASパスプリペンド等のテクニックで「メイン回線とサブ回線」「リージョン1とリージョン2」間の優先度を柔軟に調整可能です。

実際の運用ではシミュレーションとテストを十分行い、誤動作や不必要な経路フラップが起きないよう管理します。

2.4 ゾーン冗長 ExpressRoute/VPN Gateway の採用（単一リージョン対策）

狙い：単一リージョン内でのゾーン障害に耐えるため、ゲートウェイを複数AZに分散する。ExpressRoute/VPN 双方とも AZ 対応 SKU を選択可能（例：ErGw2AZ、VpnGw2AZ など）

構成の要点
SKU：ExpressRoute は ErGw1AZ / ErGw2AZ / ErGw3AZ、VPN は VpnGw*AZ を選定。

Public IP：Standard の Public IP を使用。ゾーン冗長にする場合はゾーン未指定で作成／ゾーナル配置は明示的に Zone 1/2/3 を指定。

リージョン条件：AZ対応リージョンでのみ選択可。事前に対象リージョンの AZ 提供有無を確認。

共存：同一 VNet 内で ExpressRoute と VPN を共存可能（GatewaySubnet は /27 を推奨）。

移行（既存ゲートウェイからのアップグレード）
ポータルの「Gateway SKU Migration」もしくは PowerShell のガイドに従い、AZ対応SKU へマイグレーションできる。変更時は短時間の通信影響があり得るため、保守時間を確保。

限界と補完
AZ冗長はゾーン障害までが守備範囲。回線・ロケーションの二重化やマルチリージョン設計と併用して初めてエンドツーエンドの HA を満たす。

3. リージョン間冗長化とアクティブ-アクティブ構成

〈注：AZ冗長とマルチリージョンの棲み分け〉
本章はリージョン障害を想定した冗長化を扱います。一方、単一リージョン運用でまず実現しやすいのが「ゾーン冗長の ExpressRoute/VPN Gateway」です。ゾーン障害には有効ですが、リージョン全体の停止には対応できないため、回線多重化＋マルチリージョンの層と併せて設計してください。

3.1 複数ハブVNetの配置
オンプレとAzureとの接続が複数回線であっても、Azure側が単一リージョンに依存していると、地域障害に対して脆弱です。

そこで、Azureの東日本・西日本など複数リージョンにそれぞれHub VNetを作成し、ExpressRoute Gateway・VPN Gatewayを配置します。

各拠点は、東京回線をプライマリとして東日本Hubに、または大阪回線をプライマリとして西日本Hubに接続するなどアクティブ-アクティブな分散が可能になります。

クラウド上ではSpoke VNet（業務システムごとに分けるネットワーク）を各リージョンのHubに紐づけ、Global VNet Peeringで相互に接続します。

3.2 Hub間フェイルオーバーとリージョン全停止対策
いずれかのリージョンが大規模障害で使用不能になった場合、もう一方のリージョンのHubを経由してサービスを継続させるシナリオを用意します。

例えば、本番業務システムを両リージョンにデプロイしておき、DNSやTraffic Managerでリージョンフェイルオーバーを実装すると、東日本リージョンが落ちてもユーザは西日本リージョンのシステムに誘導されます。

ネットワーク的には、西日本Hubに向かうExpressRoute経路をオンプレ側で優先させればトラフィックが自動的にそちらを使うようになるわけです。

Azure FirewallやRouteServerも各HubVNetに冗長展開し、ハブ同士をGlobal Peeringで結ぶことで東西どちらかが死んでももう片方が中核となりオンプレとの通信を引き継ぎます。

3.3 パフォーマンス考慮
アクティブ-アクティブで各拠点が最寄りリージョンHubへ接続する設計は、ネットワーク性能（遅延・帯域）を最適化できる利点があります。

ただしリージョン間を跨いだ通信が必要な場合、時に遠回りが発生する可能性があるため、Global VNet PeeringやAzure Backbone経由をうまく利用し、最短経路になるようルーティングを調整します。

大量データ転送が発生する環境では回線使用率を監視し、必要に応じてExpressRoute帯域を増強したり、リージョンごとのワークロード配置を最適化します。

4. BGPによる経路制御の高度なチューニング

4.1 ASパスプリペンドやLocal Pref
複数回線をアクティブ-アクティブで活かしながら不要なフラッピングを避けるには、BGP属性の調整が不可欠です。

オンプレ側ルーターでは「本社拠点 → 東京回線をプライマリ、工場拠点 → 大阪回線をプライマリ」といったローカルプリファレンス設定を行い、Azure側でも各接続のWeightやASパス長を操作し、どの回線が優先されるかを明示します。

AzureのExpressRoute側はデフォルトでWeight=32000など一定値が割り当てられ、複数回線を均等に扱いますが、オンプレはLocalPref=200など高い値を与えてプライマリ回線を選ばせ、セカンダリ側にはLocalPref=100といった低い値を設定する形が典型例です。

こうした調整によりリンク障害時のスムーズな切替と通常時の負荷分散を同時に両立できます。

4.2 最長プレフィックスマッチング
複数回線間で一部のサブネットだけ別経路を優先させる場合、プレフィックスを分割して広告する方法もあります。

プライマリ回線ではサブネットを小さく分割（/24を2つの/25等）、セカンダリ回線では統合した/24だけ広告、といった形です。

Azure BGPルーターはより長いマスクの経路を好むため、プライマリ回線が生きている間は/25経路が優先され、障害時にのみ/24経路を使う、といった動きを実現できます。

ただしサブネット数が増えると経路表が複雑になるため、管理やフラッピングに留意が必要です。ASパスプリペンドのほうがシンプルな場合もあります。

4.3 BFDを用いた高速検出
ExpressRouteではBGPのKeepalive/Holdタイマーによって障害検出に数十秒～180秒かかる可能性がありますが、**BFD（Bidirectional Forwarding Detection）**を用いれば数百ミリ秒レベルで障害を感知してBGPセッションを切断し、切替を高速化できます。

最新のAzure ExpressRoute GatewayではBFDサポートが拡充されており、オンプレ側ルーターもBFD対応ならBGPダウン判定を大幅に短縮可能です。

ただしBFDセッションが誤検知しないようネットワーク遅延やL2/L3機器の最大転送時間を考慮した設定が必要です。

5. 経路ヘルス監視とNetwork Watcherを使ったトラブルシュート

構成が高度になるほど、運用監視も複雑化します。AzureのNetwork WatcherやConnection Monitor機能を利用して定期的に拠点→Azure VM間でPing/HTTPチェックを行い、切替が想定通りに行われるかや遅延が増大していないかをモニタします。

またExpressRoute回線のメトリクス（帯域使用率、発信/受信パケットドロップ）やBGPセッション状態をAzure Monitorのアラート条件に設定し、異常があればNOCへ通知します。

さらにオンプレのネットワーク側でもCPEルーターやメインL3スイッチでBGPセッション状態を定期確認し、両面からアクティブ回線を可視化することで、故障ポイントを迅速に特定できます。

トラブルシュート手順例:

Connection Monitorで定義しているテストがFail。拠点→Azureが通信不能のアラート発生

Network WatcherのTopologyを確認し、ExpressRoute Gateway・Firewall・VMが正常か視覚的に把握

Next HopやIP Flow Verify機能で通信経路/NSG拒否をチェック

Azure MonitorのResource HealthやExpressRoute Circuitメトリクスを参照し、BGPセッションDownや回線使用率異常を特定

オンプレ側CPEルーターコンソールでshow bgp neighborなどを実行し、(Primary)セッションがIdleなら(Secondary)へ切替中と判断

切替が正しく行われない場合はAS Pathプリペンドの設定漏れ、またはLocalPref競合、VPNトンネルのPSK設定ミス等を調査

フェイルオーバー試験を定期的に実施し、手順をプロセス化しておくことで、災害や回線断が発生しても短時間でサービス復旧に導けます。

6. 運用設計: NOC/SOC視点でのFailoverシナリオと演習

6.1 有事のシナリオを明確化
以下のパターンを想定し、具体的なアクションをドキュメント化しておきます。

単一ExpressRoute回線障害：もう片方の回線に即座に切り替わる。数秒～数十秒程度でBGP収束を確認。

両回線障害 → VPNフォールバック：自動的にVPNがアクティブになるが、帯域不足で応急処置程度。大容量トラフィックを優先度設定やスケジュール変更で一時停止する。

リージョンのハブVNet障害：対ペアリージョンにDNS切替、あるいはTraffic Managerを介しフェイルオーバー。ExpressRoute BGPは残るリージョンを優先経路にする。

拠点障害：本社が障害となった場合、拠点Bが代理で他回線経由しAzureにアクセスし続ける。Global Reachや社内WANの残存回線で本社との通信を迂回。

6.2 演習と情報共有
定期訓練：年1回以上、本番レベルでExpressRoute切替やリージョン切替の実演を行い、担当者がオペレーションに習熟する。

運用Runbook：フェイルオーバー操作やトラブルシュート手順をマニュアル化。Azure Portal/CLI/オンプレルーターいずれの操作方法も詳細に記載。

DR文書整合：ネットワーク以外（アプリケーション、データベース等）のDR計画とも整合し、アプリ/DBが移動した際のネットワークルート切替やDNS更新手順を明確化。

監査ログ：すべての大きなフェイルオーバー操作はAzure Activity Logおよびオンプレ側のChange Managementシステムで監査する。ISO27001や内部統制要件にも適合。

こうした運用体制により、人為ミスを最小化しながら多様な障害に柔軟に対応できるNOC/SOCプロセスが構築できます。最終的には可用性要件（RTO/RPOなど）に基づき切替速度や手動/自動の切替範囲を適切に設計し、最悪の事態でも数分～数十分以内にサービスを復旧できる運用を確立することが目的です。

まとめ：複数回線・マルチリージョンによるHAネットワークの全体像

ExpressRouteの複数回線冗長、VPNフォールバック、リージョンペア構成、BGP制御によるアクティブ-アクティブ動作——これらを組み合わせることで、大企業のハイブリッドクラウド環境において高い耐障害性を実現できます。

具体的には：

オンプレ側: 異なるキャリア・異なるロケーションの2つのExpressRoute回線をCPEルーターレベルで冗長化し、BGPをアクティブ-アクティブで運用。さらにVPNをバックアップとして設定。

Azure側: Hub & Spokeアーキテクチャ上で複数リージョンにHub VNetを配置し、各HubにExpressRoute Gateway + VPN Gatewayをデプロイ、加えてAzure FirewallやRouteServerも冗長化。SpokeはペアのHubとGlobal Peeringで接続し、災害時に片方リージョンが落ちてももう一方で通信を維持。

BGPチューニング: ASパスプリペンド/LocalPrefなどを駆使し、拠点ごとの主要経路とフェイルオーバー経路を明確化。障害発生時には自動切替されるよう設計する。

Global Reach: 拠点間をAzureバックボーンで相互接続し、万一社内WANがダウンしてもExpressRoute経由で拠点間通信を迂回させるオプション。

監視運用: Azure Monitor/Network Watcherで回線/ゲートウェイのメトリクスやBGPログを収集、健全性を常時チェック。年数回はフェイルオーバーテストを行い手順の習熟と不備修正。

可用性フレームワーク: NIST SP 800-53、ISO/IEC 27001のAV(可用性)管理策、CISベンチマークに従い運用プロセスと監査ログも充実させ、突発障害時の復旧率向上と内部統制を両立。

こうした構成は一見複雑ですが、エンタープライズ規模でゼロダウンタイムを目指すならば避けて通れない設計です。

Microsoftも公式のハイブリッドアーキテクチャで「回線/リージョン/ゲートウェイの多重化」を強く推奨しており、CISも「すべてのクラウド接続に対する高可用性計画を策定すべし」と明言しています。
十分なリスク分析の上で必要最小限のパーツを組み合わせ、簡素だが頑健なネットワークを構築するのが理想的です。運用チームも定期演習や監視整備を行い、この複雑な仕組みを円滑に運用できる体制を整えれば、オンプレとAzureを結ぶハイブリッドネットワークで真のBCP/DR対応を達成できるでしょう。

参考リンク（ハイブリッドNWの高可用性／冗長化）

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up

ハイブリッドネットワークの高可用性設計: 複数回線・マルチリージョンによる冗長化戦略

1. ハイブリッドネットワークにおける高可用性の重要性

2. ExpressRoute回線の複数化とVPNフォールバック

3. リージョン間冗長化とアクティブ-アクティブ構成

4. BGPによる経路制御の高度なチューニング

5. 経路ヘルス監視とNetwork Watcherを使ったトラブルシュート

6. 運用設計: NOC/SOC視点でのFailoverシナリオと演習

まとめ：複数回線・マルチリージョンによるHAネットワークの全体像

参考リンク（ハイブリッドNWの高可用性／冗長化）

1) 設計総論・HA/DRガイド

2) 回線冗長・BGP最適化（アクティブ/アクティブ・フェイルオーバー）

3) ExpressRoute＋VPN 共存・バックアップ

4) 単一リージョン対策（AZ冗長のゲートウェイ）

5) マルチリージョン／ハブ＆スポーク／vWAN

6) 監視・アラート（回線/ゲートウェイ/ハブ）

7) トラブルシュート／可観測性（Network Watcher）

8) L7 側の冗長（DNSフェイルオーバーなど補完）

9) 関連（Firewall冗長/SLA）