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

2025-01-06
デベロッパーのためのクラウド活用方法

Author :  藤井 博貴

こんにちは。Network Specialist TAM の藤井です。

皆さまは、Amazon Virtual Private Cloud (VPC) とオンプレミス環境を接続する ハイブリッドネットワーク接続 の監視をどのように実装されているでしょうか。単純な死活監視から、グレー障害 に備えたきめ細かな品質/パフォーマンス監視まで、その手法は様々かと思います。

本記事では、Amazon CloudWatch Network Synthetic Monitor (Network Synthetic Monitor) を活用した、ハイブリッドネットワーク接続の品質監視について解説します。特に、冗長構成を採用したハイブリッドネットワークにおけるオブザーバビリティ (可観測性) の実装に焦点を当てます。これから監視体制や仕組みの構築を検討される方々にとっても、有益な情報となれば幸いです。

このクラウドレシピ (ハンズオン記事) を無料でお試しいただけます »

毎月提供されるクラウドレシピのアップデート情報とともに、クレジットコードを受け取ることができます。 


1. 冗長構成におけるネットワーク品質監視の課題

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

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

  1. アクティブ/スタンバイ構成:
    1. 通常時は 1 つの Direct Connect のみを使用
    2. 予備の Direct Connect は待機状態を維持
       
  2. アクティブ/アクティブ構成:
    1. 複数の Direct Connect を常時並行利用
    2. トラフィックを分散して処理


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

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


2. Network Synthetic Monitor の基礎知識

Network Synthetic Monitor は、2023 年 12 月にリリースしたマネージド型のハイブリッドネットワークの監視・観測サービスです。 Direct Connect または Site-to-Site VPN 経由のハイブリッドネットワークにおいて、エンドツーエンドでのネットワーク健全性の可視化を実現します。仕組みとしては、VPC のサブネット内に Network Synthetic Monitor 専用の Elastic Network Interface (ENI) を配置し、そこからオンプレミス側の機器 (正確には機器にアサインされた IP アドレス) に対して定期的に監視プローブを送信。これにより、その ENI から監視対象機器までの「通信経路」のパケットロス率や遅延値などの重要メトリクスを収集し可視化します (図 1 参照)。

※ Network Synthetic Monitor の詳細なサービス説明や設定方法は割愛させていただきますが、ご興味のある方は、AWS ブログ 「Amazon CloudWatch Network Synthetic Monitor でハイブリッド接続をモニター」を是非ご参考にしてください。

図 1. Network Synthetic Monitor のメトリクス情報 (マネージメントコンソールでの Network Synthetic Monitor 概要画面)


3. AWS Direct Connect 冗長構成におけるネットワーク監視の実装例

本実装例では、AWS 推奨の「クリティカルなワークロードの高い回復性」に基づくネットワーク構成を採用しています。構成は以下の 3 つの主要セグメントで構成されています:

  1. お客様データセンター (オンプレミス環境)
  2. AWS Direct Connect ロケーション (複数拠点)
  3. AWS 環境 (Direct Connect Gateway、AWS Transit Gateway、VPC)

図 2. ネットワーク構成図

冗長構成の特徴

  • 異なる 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 本の柱にある「運用上の優秀性」の改善へとつながります。


4. Network Synthetic Monitor の実装における推奨事項

  • 単一 AZ 故障に備えて、AZ が異なる複数の VPC サブネットを Network Synthetic Monitor プローブの送信元としてご指定ください。
  • Network Synthetic Monitor モニター毎に 2 つの専用 ENI が VPC サブネット内に自動作成されますので、(特に、大量にモニターを作成される際は) 対象 VPC サブネットの IP アドレス数の利用状況をご考慮ください。
  • 本記事の公開時点におきまして、一部 AWS リージョンでは Network Synthetic Monitor が未サポートとなっております。Network Synthetic Monitor の導入をご検討の際は AWS 公式サイトより 利用可能なリージョン をご確認ください。
  • オンプレ側の監視対象の機器は、ENI からの監視プローブ (ICMP、またはTCP) に応答可能な機器をご利用ください。
  • オンプレ側のファイアウォールや ACL などのセキュリティポリシーにて監視プローブの通信を許可してください。
  • Amazon CloudWatch Alarm や SNS と連携し、お客様のシステム/ネットワーク要件に沿った閾値監視や自動通知の導入をご検討ください。
  • 共有型の Direct Connect (ホスト VIF など) をご利用の場合は、冗長化や監視において Direct Connect パートナー様の制限が加わることがあるため、詳しくはサービスを提供しているパートナーの技術窓口にご確認ください。

5. まとめ

本記事では、Network Synthetic Monitor を用いたハイブリッドネットワーク接続の実践的な監視実装について詳しく解説しました。

ハイブリッドネットワーク接続においては、AWS クラウド内のアーキテクチャだけでなく、オンプレミス側の機器構成やネットワーク設計を考慮した監視手法が不可欠となります。お客様の構成や通信要件に沿ったネットワーク監視を実装することで、有事の際の迅速なイベント検知が可能となり、サービスの迅速な復旧につながります。

本記事の内容が、ハイブリッドネットワーク環境における包括的な監視実装や監視体制の強化を検討されている方々の実務に役立つことを願っています。


builders.flash メールメンバーへ登録することで
AWS のベストプラクティスを毎月無料でお試しいただけます

筆者プロフィール

藤井 博貴
アマゾン ウェブ サービス ジャパン合同会社
シニア ネットワーク スペシャリスト テクニカルアカウントマネージャー

10 年以上、データセンターやキャンパス、バックボーンなどを含むオンプレミスネットワークの設計、構築、運用に従事した後、AWS ジャパンに入社。現在は、AWS エンタープライズサポートにご加入のお客様向けにネットワーク関連のコンサルティングや技術支援を担当しています。

AWS を無料でお試しいただけます

AWS 無料利用枠の詳細はこちら ≫
5 ステップでアカウント作成できます
無料サインアップ ≫
ご不明な点がおありですか?
日本担当チームへ相談する