Amazon Web Services ブログ
Amazon CloudWatch Network Monitor でハイブリッド接続をモニター
2023 年 12 月 22 日、Amazon CloudWatch Network Monitor の提供を発表しました。これは AWS 上のハイブリッドネットワーク接続の可視化を容易にする CloudWatch の機能です。CloudWatch Network Monitor は現在、AWS Direct Connect と AWS Site-to-Site VPN で構築されたネットワーク用のハイブリッドモニターをサポートしています。Amazon CloudWatch Network Monitor は Amazon CloudWatch のコンソール上で利用することが可能です。
この記事では、CloudWatch Network Monitor (CWNM) を使用してハイブリッドネットワークのパフォーマンスを測定し、MTTR ( 平均復旧時間 ) を短縮する方法について説明します。
ハイブリッド接続とグレー障害
Advanced Multi-AZ Resilience Patterns Whitepaper では、グレー障害を異なるエンティティが異なる視点で障害を検知することと定義しております。グレー障害は、原因特定と解決が難しい場合があります。ネットワークドメインでのグレー障害の例としては、特定のネットワークリンクでの断続的なパケットロスやレイテンシーの変動などがあります。
このような状況が発生すると、あるエンティティ ( ルーティングコントロールプレーン ) では低下による影響は見られないのに対して、別のエンティティ ( お客様 ) ではスループットの低下やレイテンシーの増加のような形で影響が見られます。
Border Gateway Protocol (BGP) は、AWS Direct Connect と AWS Site-to-Site VPN で使用されるダイナミックルーティングプロトコルで、TCP のトランスポートプロトコルで動作しています。TCP は、再送信やスライディングウィンドウなどのメカニズムによって、ある程度のネットワーク低下を許容することができます。さらに、TCP セッションは、お客様のルーターと AWS Direct Connect ルーターとの間で確立されます。そのため、VPC とオンプレミスネットワーク間のどこかでネットワーク障害が発生しても、BGP では必ずしも低下の兆候に気づけないかもしれません。
Direct Connect (DX) または Site-to-Site VPN によるハイブリッド接続を必要とする AWS のお客様は、グレー障害が発生したら直ちに検知し、問題が起きている経路からトラフィックを回避するオプションを用意する必要があります。これまでの経験から、ネットワークに問題が発生すると、ネットワークエンジニアは問題の特定に相当な時間を費やすことがわかっています。パフォーマンス低下がお客様管理のネットワーク部分で発生したのか、それとも AWS 責任範囲内のネットワーク部分で発生したのかを迅速に把握することは、MTTR の短縮に役立ちます。
野村総合研究所は Direct Connect のパートナーです。当社にとって、ネットワークのグレー障害を検出・特定し、その影響を軽減するまでの時間を短縮することは長年の課題でした。
CloudWatch Network Monitor のおかげで、エンドツーエンドのパフォーマンスの低下や停止が発生と同時に検知できるようになりました。CloudWatch アラームでしきい値を設定し、CloudWatch Network Monitor を Lambda や SNS などの他の AWS サービスと統合するのは簡単でした。
上記により、ネットワークイベントが検出された際に事前に定義したアクションを実行することで、これまで以上に多くのネットワーク障害の影響を自動的に軽減できると期待しています。
株式会社野村総合研究所 シニア・アソシエイト 藤原 和樹 氏
Amazon CloudWatch Network Monitor の紹介
Network Monitor を使用する以前は、ハイブリッドアーキテクチャを採用しているお客様は、既製のソリューションを使用するか、独自のツールを開発したアクティブ監視手法を実装することで、ネットワークのグレー障害の問題に対処してきました。
CloudWatch Network Monitor は、フルマネージド型のエージェントレスソリューションで簡単に実現します。
モニターは、Direct Connect または Site-to-Site VPN 経由で到達可能な IPv4 または IPv6 宛先への ICMP または TCP トラフィックをテストするために使用できます。送信元サブネット、宛先 IP、 パケットサイズ、およびプロトコル/ポートの各組み合わせは、プローブと呼ばれます。
Amazon VPC でモニターを作成すると、AWS はバックグラウンドで RTT (Round-Trip Time) とパケットロスの測定を実行するために必要なすべてのインフラストラクチャを作成します。プローブで設定されたポートとプロトコルでモニタリングトラフィックに応答するように監視ターゲット （プローブの宛先） を設定するだけで済みます。
Direct Connect と併用する場合、モニターはモニターがデプロイされた VPC から DX 接続を終端する Direct Connect ロケーションまでの、AWS が管理するネットワーク経路の状態を可視化します。これは Network Health Indicator (NHI) と呼ばれ、問題が AWS のネットワークにあるのか、お客様が管理するネットワークにあるのか原因特定のスピードアップに役立ちます。
モニターによって生成されたメトリクスは Amazon CloudWatch に公開され、ダッシュボードとアラームを設定して、通知や軽減アクションを実施することができます。
シナリオ
Direct Connect High Resiliency モデルを実装する一般的なお客様のシナリオを以下に説明します。この設計に焦点を当てて、Network Monitor の設定と使用方法を示します。Network Monitor は他のシナリオでも使用することができます。
図 1. Direct Connect High Resiliency 構成を利用のお客様
こちらのお客様では各 Direct Connect ロケーションにルーターを設置しています。各ルーターは、DX 専用接続を介して AWS ルーターに接続されます。
2 つの Transit VIF (T-VIF) が、Direct Connect Gateway (DXGW) に関連付けられた AWS Transit Gateway との間でトラフィックを転送するように設定されています。お客様のルーターは、両方の T-VIF 上で eBGP を介して DXGW とルーティング情報を交換します。これは、AWS のドキュメント、ブログ記事、およびハイブリッド接続ホワイトペーパーなどのリソースで扱われている一般的なアーキテクチャです。
お客様は、複数のプライベートサブネットにワークロードを所持しており、アプリケーションの可用性を最大化するために、異なるアベイラビリティゾーン (AZ) に分散しています。図を見やすくするために、ここでは 2 つだけ表示することにします。これらのワークロードには、オンプレミス LAN 上のクライアントがアクセスします。
お客様は、等コストマルチパス (ECMP) を使用して、両方の DX 接続間でネットワークフローの負荷分散を行っています。LAN（172.16.0.0/24 - 2001:DB8::/48） には、AWS から両方の T-VIF 経由で到達が可能です。同様に下の図が示すように VPC にも、LAN から両方の T-VIF を経由して到達可能です。
図 2. 両方のトランジット VIF から LAN に到達可能
プライベートサブネット内のワークロードはレイテンシーにセンシティブです。お客様は、どちらかの経路に障害が発生した場合にも対処できるように、両方の経路のネットワークパフォーマンスを可視化したいと考えています。AWS リージョン内のアベイラビリティーゾーンは独立した障害ドメインとして設計されているため、異なる AZ の異なるサブネットからの可視性を提供する必要があります。
モニタリング アーキテクチャ
ユーザーのペルソナによって、モニタリングの目的は異なる可能性があります。例えば、アプリケーションオーナーは、ネットワークがアプリケーショントラフィックをどのようにルーティングするかに関係なく、エンドツーエンドのレイテンシーとパケットロスがエンドユーザーのエクスペリエンスに影響を与えないことを確認したいと考えるかもしれません。
アプリケーション開発者は、ワークロードと同じサブネットにモニターを設定し、オンプレミスの LAN に対してプローブを送信します。いずれかのワークロードのサブネットからのモニタリングトラフィックは、オンプレミスのモニタリング宛先に到達するために、利用可能なすべての経路を使用します。
図 3. モニタリングアーキテクチャ (アプリケーションオーナー)
一方、ネットワーク・エンジニアは各ネットワーク経路を重視するため、各プローブのトラフィックが特定の経路をたどって宛先に到達するようにモニターを構成します。
図 4 に示す 2 つ目のアーキテクチャでは、ネットワークエンジニアが各モニタリングサブネットにプローブを作成しました。各プローブは、緑色または赤色の DX 接続を経由してのみ到達可能な宛先に設定されています。同様に、モニターの宛先は、緑色または赤色の DX 接続を経由してのみ、図の左側にある対応するプローブに到達できます。例としては VRF-Lite をお客様のルーター上で構成することで実現できます。
図 4. モニタリングアーキテクチャ (ネットワークエンジニア)
執筆時点では、同一モニター内に IPv4 と IPv6 の両方の宛先に対するプローブを作成することはできません。IPv6 宛先へのプローブを設定したい場合は、別の IPv6 モニターを作成してください。
次に、2 つ目のアーキテクチャについて説明し、AWS コンソール内での設定方法を示します。CloudWatch Network Monitor は、サービス API、AWS SDK、AWS CloudFormation、CDK を使用して設定することもできます。ここでは IPv4 のみのモニターを作成する方法を示しております。IPv6 のみのモニターを作成したい場合も同じ手順に従ってください。
Amazon CloudWatch Network Monitor のセットアップ
2 つ目のリファレンスアーキテクチャを実装するために、monitor-us-east-1-ipv4 という名前のモニターを作成します。これを行うには、Network Monitor コンソールを開き、モニターを作成を選択します。
図 5. Network Monitor コンソールでのモニター作成
集計期間は、 Network Monitor のプローブが生成したメトリクスを CloudWatch に送信する間隔を表します。
この値は 30 秒（デフォルト）のままにします。これは Network Monitor によって生成されるメトリクスに依存しており、自動化されたアクションを使用して障害のあるネットワークパスを迅速に回避するためです。
図 6. 新しいモニターの作成
次に、プローブをデプロイするソースとして、monitor-subnet-us-east-1aと monitor-subnet-us-east-1b のサブネットを選択します。最後に、172.16.100.1と172.16.200.1を宛先として設定します。コンソールを使用して作成されたプローブは、デフォルトで 56 バイトサイズの ICMP エコーパケットを送信します。これを図 7 に示します。
図 7. モニターの送信元サブネットと宛先IPを指定
ステップ順に従うと、すべてのリソースがデプロイされ、プローブが先ほど設定した集計間隔ごとに CloudWatch にメトリクスを送信開始するまで、モニターとプローブは Pending 状態になります。
Network Monitor ダッシュボード
CloudWatch Network Monitor はモニター毎にダッシュボードを作成します。これは、Network Monitor ダッシュボードでモニター名をクリックすることでアクセスできます。
左上には、モニターがデプロイされているリージョンの AWS ネットワークのステータスが表示されます。
この情報は接続が複数のネットワーク ( 例：AWS ネットワーク、Direct Connect Partner バックボーン、オンプレミスデータセンターネットワークなど ) を経由する場合に、モニターされたパケットロスや増加したレイテンシーの原因を調査するのに役立ちます。
右上には、アラーム状態のプローブ数、平均パケットロス、選択した時間範囲の RTT などプローブのステータスの概要が表示されます。
図 8 では、AWS Network Health Indicator メトリクスの履歴と、各プローブのパケットロスと RTT を示す折れ線グラフが表示されます ( 図 9)。この情報を使用して、AWS Network Health Indicator とモニターされたパケットロス/レイテンシーを相関することで、ネットワークの問題をさらにトラブルシューティングできます。
図 8. モニターのサマリー表示
図 9. Network Monitor メトリクスのサマリー表示
CloudWatch メトリクス
AWS Network Monitor は、CloudWatch メトリクスを名前空間内に “AWS/NetworkMonitor” として公開しています。各プローブには 3 つのメトリクスがあります。
- HealthIndicator: 測定時に AWS ネットワークが正常であれば 0、低下している場合は 100 です。
- PacketLoss: パケットロスをパーセント値で表します。
- RTT: ラウンドトリップ時間をマイクロ秒単位で表します。
図 10. NetworkMonitor CloudWatch メトリクス (RTT)
Metrics math
複数のメトリクスを数式と組み合わせると便利な場合があります。
例えば、複数のプローブが物理リンクを共有している場合、集約期間中 （ この場合は 30 秒）にすべてのプローブのパケットロスの平均を取得することができます。取得するには、関連するメトリクスを選択し、「数式を追加」オプションを使用してください。次に、図 11 と図 12 に示すように、適切な関数 ( 平均を表す “AVG” など ) を選択します。
図 11. CloudWatch メトリクスの数式追加
図 12. CloudWatch メトリクスに数式を追加した結果 (RTT)
アラームの作成
シナリオに最も適したメトリクスを特定したら、アクションセクションの小さなベルのリンクアイコンをクリックして、必要なアラームとアクションを設定できます。
最もシンプルなタイプのアラームとして、静的なしきい値を使用します。例えば、パケットロスの平均値が 1% を超えた場合に通知するアラームを作成できます。ほとんどのアプリケーションでは、1% のパケットロスは許容範囲内と考えられます。
図 13. パケットロスに関する CloudWatch アラームの設定
事前に妥当なメトリクス値が分からない、または日中に何らかの変動が予想されるため ( ラウンドトリップタイムなど ) 静的なしきい値を設定したくない場合は、CloudWatch 異常検出を使用してアラーム設定ができます。異常検出は予想される帯域の値を計算し、実際の値がその帯域より大きい場合や低い場合、または帯域外である場合にアラートを発します。プローブが失敗した場合 （ パケットロス = 100%）、RTT は 0 ミリ秒と報告されるため、予想よりも低い値や高い値を検出するように異常検出を設定することは合理的です。
図 14. CloudWatch 異常検出の設定
フェイルオーバーの自動化
Amazon Simple Notification Service (SNS) を使用してアラートを送信する以外に、障害検出時の際に Direct Connect リンクのフェールオーバーを自動化することも可能です。そのためには、Amazon EventBridge によって呼び出される Lambda 関数を使用します。サンプルの Lambda 関数は AWS Samples GitHub リポジトリで提供されています。詳細とベストプラクティスについては、ブログ記事「AWS Direct Connect monitoring and failover with Anomaly Detection」 を参照してください。
また、実際の障害シナリオが発生した際に期待通りに機能することを確認するため、フェイルオーバーの自動化を定期的にテストすることもベストプラクティスです。
リソースの削除
Network Monitor をテスト後は、想定していない料金の発生を避けるため、すべてのモニターとプローブ、この機能をテストするために作成したその他のリソースを削除して、テスト環境をクリーンアップしてください。
まとめ
この投稿では、ハイブリッドネットワークのモニタリングを容易にするフルマネージド型でエージェントレス機能である Amazon CloudWatch Network Monitor を紹介しました。Network Monitor を使用することで、ネットワークの問題をより迅速にトラブルシューティングと修復を行うことができるため、カスタマーエクスペリエンスへの影響を最小限に抑えることができます。
Network Monitor の料金の詳細については、こちらの CloudWatch 料金表ページをご覧ください。この機能の設定方法と使用方法に関する技術的なガイダンスについては、AWS Documentation をご覧ください。
本稿は、2023 年 12 月 22 日に Networking & Content Delivery で公開された “Monitor hybrid connectivity with Amazon CloudWatch Network Monitor” を翻訳したものです。翻訳はテクニカルアカウントマネージャーの安藤 彰が担当しました。