NW 運用者必見 ! オンプレ - クラウド間のグレー障害検出による運用改善

多くの企業が、VPC とオンプレミス環境の接続に AWS Direct Connect (Direct Connect) や AWS Site-to-Site VPN (Site-to-Site VPN) を採用しています。 特にミッションクリティカルな本番環境では、複数の Direct Connect を配備し、単一障害点 (SPOF) を排除する冗長構成が一般的です。

この冗長構成には、主に以下の 2 つのアプローチがあります：

1. 通常時は 1 つの Direct Connect のみを使用

2. 予備の Direct Connect は待機状態を維持

1. 複数の Direct Connect を常時並行利用

2. トラフィックを分散して処理

アクティブ/アクティブ構成では、各 Direct Connect 上にて常時トラフィックが流れているため品質低下 (ケットロスや遅延増加など) を即座に「検知」できます。一方、アクティブ/スタンバイ構成では、待機系 Direct Connect にトラフィックが流れないため、その品質状態を把握することが困難です。この課題は、障害発生時の適切なフェイルオーバー判断を妨げる要因となっています。

上記の課題に対して、AWS のマネージドサービスである、Amazon CloudWatch Network Synthetic Monitor (Network Synthetic Monitor) を用いて、ネットワークパフォーマンスを監視し、メトリクスを可視化することで、適切な経路切り替え、そしてサービス救済へとつながることを期待しています。

• 異なる AWS Direct Connect ロケーション から個別の Direct Connect 接続を確立

• アクティブ/スタンバイ構成を採用 (BGP アトリビュートによる経路制御)

• 通常時はロケーション A 側のみでトラフィックを処理

図の左側には、お客様のシステムが存在するデータセンター (オンプレミス環境）、中央には Direct Connect との物理的な接続点となる AWS Direct Connect ロケーション、右側には Direct Connect Gateway、AWS Transit Gateway を介して VPC 内にワークロードがある構成です。 AWS 接続時のトポロジーガイドラインに従い、複数の異なる AWS Direct Connect ロケーションから、それぞれ1つの Direct Connect 接続を利用しています。そして、今回は Direct Connect 接続をアクティブ/スタンバイ構成とするため、（お客様/パートナー様 機器 5 と機器 6 にて BGP アトリビュートをもとに) 通常時は AWS Direct Connect ロケーション A 側 (図の上側) のみトラフィック伝送するよう重み付けしています。

では、この冗長化されたハイブリッドネットワーク接続にて Network Synthetic Monitor を用いた品質監視を実装します。

図 3. Network Synthetic Monitor と関連リソースを含めたネットワーク構成図

まずは、VPC 内に Network Synthetic Monitor モニターを作成し、監視プローブの送信元サブネットを指定します。ここでは構成図を簡素化するため、送信元サブネットは 1 つのみ指定していますが、実際にご利用の際は単一 アベイラビリティゾーン (AZ) の故障に備え、複数のプローブ送信元サブネットを指定することを推奨します。また、Network Synthetic Monitor モニターの作成時、サブネット内には 2 つの専用 ENI が自動作成され、これらの ENI からオンプレミス側の機器に対して監視プローブを定期的に送信します。

次に、監視プローブの宛先となる IP アドレスを指定します。今回はアクティブ/スタンバイ構成のため、お客様データセンター内の「本番環境向けシステム」から Network Synthetic Monitor の ENI までには、(Direct Connect 接続を含む) 2 つのネットワーク経路があります。主系/アクティブ側の通信経路には、お客様機器 1、お客様機器 3、お客様/パートナー様機器 5 が存在するとします。そして、これらの機器にて重複のないユニークな (一意の) IP アドレスを採番し、Network Synthetic Monitor の監視プローブの宛先として指定します (図 4 参照）。

ここでは、それぞれのネットワーク機器にて、監視専用のループバックインターフェースを作成し、IP アドレスを採番します (例：お客様機器 1 のループバックインターフェースへ IP アドレス 203.0.113.1/32 を採番）。
副系/スタンバイ側も同様に、お客様機器 2、お客様機器 4、お客様/パートナー様機器 6 が対象の通信経路に存在し、それぞれの機器にユニークな IP アドレスをアサインします。

図 4. Network Synthetic Monitor の作成済みプローブの一覧

次に、Direct Connect 接続の終端機器であるカスタマールーター (構成図ではお客様/パートナー様機器 5 とお客様/パートナー様機器 6) にて、Network Synthetic Monitor プローブの宛先 IP アドレスを含む Classless Inter-Domain Routing (CIDR) 情報を広報するよう設定します。

図 5. Network Synthetic Monitor プローブの宛先 IP アドレスを含んだ経路広報

今回はお客様/パートナー様機器 5 とお客様/パートナー様機器 6 にて、Prefix-List と Route-Map を併用し、特定の CIDR 情報の広報を制御します。下記にサンプルコンフィグを掲載しますが、利用する機器や通信ポリシーによりパラメータの内容は異なります。

お客様/パートナー様 機器 5 (アクティブ側) の設定

ip prefix-list Deny-secondary-dx-monitor-destination seq 5 permit 203.0.113.2/32
ip prefix-list Deny-secondary-dx-monitor-destination seq 10 permit 203.0.113.4/32
ip prefix-list Deny-secondary-dx-monitor-destination seq 15 permit 203.0.113.6/32
!
route-map Deny-secondary-dx-monitor-destination deny 10
match ip address prefix-list Deny-secondary-dx-monitor-destination
!
route-map Deny-secondary-dx-monitor-destination permit 20
!
router bgp 64505
neighbor 100.64.0.2 route-map Deny-secondary-dx-monitor-destination out

お客様/パートナー様 機器 6 (スタンバイ側) の設定

ip prefix-list Deny-primary-dx-monitor-destination seq 5 permit 203.0.113.1/32
ip prefix-list Deny-primary-dx-monitor-destination seq 10 permit 203.0.113.3/32
ip prefix-list Deny-primary-dx-monitor-destination seq 15 permit 203.0.113.5/32
!
route-map Deny-primary-dx-monitor-destination deny 10
match ip address prefix-list Deny-primary-dx-monitor-destination
!
route-map Deny-primary-dx-monitor-destination permit 20
set as-path prepend 64506 64506 64506 64506 64506
!
router bgp 64506
neighbor 100.64.0.6 route-map Deny-primary-dx-monitor-destination out

※ 監視プローブの宛先 CIDR 以外の全通信は、主系/アクティブ 側の Direct Connect を優先させるため、お客様/パートナー様機器6上の「Deny-primary-dx-monitor-destination permit 20」で BGP AS パスプリペンドを用いて重みづけ (優先度を下げる) しています。

図 6. 経路制御後の Network Synthetic Monitor プローブのフロー

この実装により以下が実現可能となります：

1. アクティブ/スタンバイ両経路の品質監視

2. 障害時の切替判断材料 (メトリクス情報) の取得

3. エンドツーエンドでの通信品質の可視化

アクティブ側とスタンバイ側の両方のハイブリッドネットワーク接続と、その通信経路の品質監視を行うことが可能です。仮に、アクティブ側の Direct Connect 接続で品質劣化を伴うイベントが発生した場合、スタンバイ側の Network Synthetic Monitor のメトリクス情報を参照し、エンドツーエンドでの健全性が確認できれば、適切な判断のもと通信切り替えを行えます。

また、Network Synthetic Monitor プローブをネットワーク経路上の重要機器 (特にパートナー様や他社/他部門などの責任分界点となる機器）に対して送信することで、問題の被疑箇所を絞ることも期待できます。例えば、お客様データセンター内の機器 3 と AWS Direct Connect ロケーション A 内の機器 5 の間にて接続不良が発生したと想定します (図 7 参照）。

図 7. ネットワーク経路上の接続不良発生

この場合、監視プローブは機器 5 まで到達できますが、機器 1 と機器 3 へは到達不可となり、機器 1 と機器 3 へのパケットロス率が上昇し、ラウンドトリップタイム (ネットワーク遅延値) も 0 (無効) となります (図 8 参照）。

この結果から、カスタマールーター (お客様/パートナー様機器 5) からお客様データセンター向けの通信区間で問題が発生している可能性が極めて高く、被疑箇所を絞った効率的なトラブルシューティングができます。

図 8. ネットワーク経路上の接続不良発生時の メトリクス情報

Network Synthetic Monitor の活用により、トラブルの発生から復旧までにかかる時間「MTTR (平均修復時間）」、 Amazon CloudWatch Alarm と Amazon Simple Notification Service (SNS) などを連携させることで、グレー障害のようなトラブルが発生した場合でも速やかにイベント検知し「MTTD (平均検出時間）」の短縮を期待できます。

このように監視実装の仕組み自体を強化することで、AWS Well-Architected フレームワーク の 6 本の柱にある「運用上の優秀性」の改善へとつながります。