NetworkMonitorによるDirectConnect異常検知および対処

Transcript

1. © 2024 NTT DATA Corporation © 2024 NTT DATA Corporation 【AWS】 AWS10分LT会 - vol.3 「Network MonitorによるDirect Connectの異常検知および対処」 2024年2月16日 NTTデータ 山本 泰士
2. © 2024 NTT DATA Corporation © 2024 NTT DATA Corporation 2 自己紹介 山本 泰士 (Taishi Yamamoto) NTTデータ ネットワークソリューション事業部 • 金融やエンタープライズのネットワーク提案～構築、運用まで従事。 • ネットワーク自動化やクラウドネットワーキングへ注力。 • その他、クラウドネットワーク人材育成の社内研修など担当。 好きなAWSサービス • DirectConnect / Site-to-Site VPN / TransitGateway / CloudWAN
3. © 2024 NTT DATA Corporation 3 本日お話しする内容 2023年12月22日に一般提供を開始された 「Amazon CloudWatch Network Monitor」 について 「どのような機能か」、「何が嬉しいのか」、「どのように使うのか」、といった観点でご紹介します。 本日お話しする内容
4. © 2024 NTT DATA Corporation 4 ①Network Monitorとは Network Monitorとは、AWSからオンプレミスの宛先に定期的にポーリングし、 RTT(Round Trip Time)およびパケット損失率のメトリクスを取得できるネットワークモニタリング機能です。 WAN WAN On-Premise Server Direct Connect VGW Server Router Router DXGW Server Direct Connect Probe AWS 今までもログやメトリクスが充実してたよね それでネットワークの切断や通信影響が確認できるのでは? ICMP/TCP モニタリング ICMP/TCP モニタリング 運用系通信
5. © 2024 NTT DATA Corporation 5 ②Network Monitorの優位性 - 1. 従来のトラフィックに関わるログやメトリクス 従来のトラフィックに関わるログやメトリクスを以下に整理してみました。 状態が正常もしくは異常を示すブール値(★)や、ビットレート/パケットレートなどの通信量(★)が多く見受けられます。 メトリクス 説明 DirectConnect接続 • 接続状態(UP/DOWN) • 送信/受信データのビットレート[bps] • 送信/受信データのパケットレート[pps] • 送信/受信トラフィックのファイバー接続状態[dBm] • MACレベルエラー数※CRCエラーも含む • 暗号化状態(UP/DOWN) 仮想インタフェース • 送信/受信データのビットレート[bps] • 送信/受信データのパケットレート[pps] Site-to-Site VPN • トンネル状態(UP/DOWN) • 送信/受信データのバイト数[byte] ログ 説明 Site-to-Site VPN • タイムスタンプ • VPN接続の識別子 • VPNトンネルの外部IP • DPDプロトコルの有効ステータス(True/False) メトリクス 説明 Transit Gateway • blackholeルート一致によるドロップバイト数[byte] • blackholeルート一致によるドロップパケット数[byte] • ルート不一致によるドロップバイト数[byte] • ルート不一致によるドロップパケット数[byte] • 送信/受信データのビットレート(bps) • 送信/受信データのパケットレート(pps) Transit Gateway Attachment • blackholeルート一致によるドロップバイト数[byte] • blackholeルート一致によるドロップパケット数[byte] • ルート不一致によるドロップバイト数[byte] • ルート不一致によるドロップパケット数[byte] • 送信/受信データのビットレート[bps] • 送信/受信データのパケットレート[pps] • CGWデバイスのNAT-T検出(True/False) • IKEフェーズ1/2プロトコル状態 (確立済み/キー更新中/ネゴシエーション中/ダウン) • IPsec/IKE/DPDプロトコルの詳細メッセージ これらのログやメトリクスだけでは検知できない障害もある! ★ ★ ★ ★ ★ ★ ★ ★ ★ ★ ★ ★ !
6. © 2024 NTT DATA Corporation 6 ②Network Monitorの優位性 - 2. Gray Failure Gray Failureとは、システムが完全に停止せず、一部の機能が失われたりパフォーマンスが低下する障害。 ネットワークでは、通信機器のソフト・ハードエラー等によって大幅な遅延や断続的な通信断が生じるものの検知が難しい。 On-Premise Server Direct Connect VGW Server Router Router DXGW Server Direct Connect AWS ①Gray Failureにより大幅な遅延や 断続的な通信断が発生 ①Gray Failureにより大幅な遅延や 断続的な通信断が発生 WAN WAN ②異常な状態が検知できず ルートは切り替わらず ②異常な状態が検知できず ルートは切り替わらず 業務系通信
7. © 2024 NTT DATA Corporation 7 ②Network Monitorの優位性 - 3. 従来メトリクスでの課題 大幅な遅延や断続的な通信断は、状態変化や通信量変化で検知できず、かつ閾値のチューニングも難しいです。 また、異常検出機能[1] を利用する場合も、不規則なトラフィックは誤検知が増え、運用負担が大きくなります。 接続状態 送受信ビットレート/パケットレート 業務通信は通信エラーが生じているものの、 BGPは再送で救われて状態が変化しない 通信量は完全に無くなる訳では無いため、 上下限閾値チューニングが難しい DOWN 通信断による変化 送受信ビットレート/パケットレート（異常検出機能オン） そもそも規則性の無いトラフィックは モデルが上手く作れず誤検知しやすい 誤検知範囲
8. © 2024 NTT DATA Corporation 8 ②Network Monitorの優位性 - 4. Network Monitorでの解決 Network MonitorのRTTおよびパケット損失率は、大幅な遅延や断続的な通信断との相関性が高く、 Gray Failure発生時におけるメトリクス変化も大きいため、閾値が定義しやすいです。 RTT(Round Trip Time) パケット損失率 DirectConnectは品質が安定しているため 通信遅延の変化は分かりやすい パケット損失は通常発生しないため 閾値が定義しやすい UP UP 通信断による変化 Gray Failure発生時の大幅な遅延や断続的な通信断を 検知するうえで有効なんですね。
9. © 2024 NTT DATA Corporation 9 ③Network Monitorを試してみた - 1. 全体イメージ Network Monitor機能を試行するために、以下の環境を構築してみました。 RTTメトリクスの閾値超過アラームをトリガーとして、BGPフェイルオーバーのAPI実行によりルートを切り替えます。 On-Premise Server Direct Connect VGW Server Router Router DXGW Server Direct Connect AWS WAN WAN Probe Event Bridge CloudWatch Alarm Lambda SNS User Email ②BGPフェイルオーバー API実行 ①RTTメトリクス 閾値超過アラーム 業務系通信 運用系通信
10. © 2024 NTT DATA Corporation 10 ③Network Monitorを試してみた - 2. Network Monitor作成 Network Monitorは、CloudWatch > ネットワークモニタリング > Network Monitorへアクセスのうえ、 以下の項目を指定するだけで作成することが可能です。 項目 説明 モニター名 任意の文字列 集計期間 30sもしくは60s サブネット 送信元サブネット （ENI/SGは自動生成） IPアドレス 送信先IPアドレス プロトコル ICMPもしくはTCP ポート番号 1～65,535 （TCPの場合のみ） パケットサイズ 56～8,500byte
11. © 2024 NTT DATA Corporation 11 ③Network Monitorを試してみた - 3. その他リソース作成 その他リソース作成については、特筆すべきポイントもないため割愛します。 公式blog[1]、github[2]で類似の構成を構築する手順や資材が紹介されており、ご興味があれば是非ご覧下さい。 [1] Monitor hybrid connectivity with Amazon CloudWatch Network Monitor https://aws.amazon.com/jp/blogs/networking-and-content-delivery/monitor-hybrid-connectivity-with-amazon-cloudwatch-network-monitor/ [2] aws-samples/aws-dx-failover https://github.com/aws-samples/aws-dx-failover
12. © 2024 NTT DATA Corporation 12 ③Network Monitorを試してみた - 4. テスト実行 アラーム閾値調整により障害を疑似的に発生させ、自動的にBGPフェイルオーバーのうえルート切り替わりを確認できました。 (BGPフェイルオーバーは本来テスト機能ですが、今回のようなGray Failureへの対処として有効だと思いました(注:最大72時間)) Direct Connect VIF画面にて 状態が「testing」確認 Direct Connect VIF画面にて 状態が「testing」確認 CloudWatchアラームでトリガーのうえ、BGPフェイルオーバーを 実行し、ルートを切り替わる自動化も可能なんですね。
13. © 2024 NTT DATA Corporation 13 Network Monitorのまとめ • 従来のメトリクスに無かったRTT/パケット損失率を取得できる。 • Gray Failureの大幅な遅延や断続的な通信断の検知で有効。 • CloudWatchアラームでトリガーのうえ、BGPフェイルオーバーを実行し、 ルートを切り替わる自動化も可能。
14. © 2024 NTT DATA Corporation © 2024 NTT DATA Corporation