re:Invent 2024: AWSネットワーク管理の最新ツールと活用法
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2024 - Navigating the AWS network with the right tools for the job (NET212)
この動画では、AWSネットワークの管理とトラブルシューティングに活用できる様々なツールについて解説しています。Resource MapやNetwork Managerを使ったネットワークトポロジーの可視化、VPC Flow LogsやTraffic Mirroringによるトラフィック分析、VPC Reachability AnalyzerやNetwork Access Analyzerを用いた接続性の検証について詳しく説明しています。また、Internet Monitor、Network Synthetic Monitor、Network Flow Monitorという3つの新しいモニタリングツールを紹介し、インターネット、AWS Direct Connect、AWS内部での問題を特定・解決する方法を具体的に解説しています。特にNetwork Flow Monitorは、re:Invent直前にリリースされた新機能で、EC2インスタンス間やAWSサービスとの通信におけるパフォーマンスの問題を、ほぼリアルタイムで把握できる点が注目されます。
※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
※ 画像をクリックすると、動画中の該当シーンに遷移します。
re:Invent 2024関連の書き起こし記事については、こちらのSpreadsheet に情報をまとめています。合わせてご確認ください！
本編
AWSネットワーキングツールの概要：セッション導入
みなさん、こんにちは。Net 212セッション「適切なツールを使用したAWSネットワークのナビゲーション」へようこそ。私はEC2 Networkingチームのシニアプロダクトマネージャーを務めるNishant Kumarです。本日は、日常業務で使用できるAWSのネイティブ機能やツールについてお話しできることを大変嬉しく思います。みなさん、こんにちは。私はAWSのシニアテクニカルアカウントマネージャーのAnkush Goyalです。本日はNishantと一緒にこのセッションを担当させていただきます。
これはレベル200のセッションですので、一般的なAWSのネットワーキング構成についてご理解いただいている方向けの内容となっています。本日のセッションでは多くの機能について取り上げますので、特定のトピックについてより詳しく知りたい場合は、表示されるQRコードをご確認ください。セッションを通じて複数のサンプルアーキテクチャをご紹介しますので、スクリーンショットを撮りたい場合は、構成の準備が整った時点でお知らせいたします。
AWSネットワーク構築の一般的なジャーニー
ツールや機能について詳しく説明する前に、一歩下がって、お客様が通常AWSでの構築を始める際にどのような道筋をたどるのかを考えてみましょう。その後、お客様が実際に必要とするものについて話し、これらのツールがどのようにしてそれらのタスクの達成を支援できるのかを見ていきます。AWSでの一般的なお客様の journey を考えると、パブリックサブネット内にインスタンスを配置し、インターネットや Amazon S3、AWS Lambda、Amazon DynamoDBなどのサービスにアクセスする必要があるというのがよくあるパターンです。
そのような場合、Internet Gatewayのようなサービスを利用することができます。 また、プライベートサブネット内のインスタンスも接続が必要となりますが、その場合はNAT Gatewayを使用できます。さらに、Amazon DynamoDBやAWS Lambdaなどの他のAWSサービスに接続するためのInterface EndpointやGateway Endpointもご用意しています。 AWSのワークロードをオンプレミス環境に接続する場合、 Site-to-Site VPNとAWS Direct Connect Gatewayという2つのオプションがあります。
ここまでお話ししてきた内容は、すべて1つのVPCの文脈においてでした。しかし、お客様の規模が拡大するにつれて、他のVPCも追加されていくことでしょう。そのような場合、VPC Peeringを使用してVPC同士を接続するのが一般的で、これらのVPCは同一リージョン内でも異なるAWSリージョン間でも構成可能です。さらにお客様の規模が拡大すると、 数百から数千のVPCを持つようになるかもしれません。そのような場合、多数のVPCの管理を簡素化するために、AWS Cloud WANやAWS Transit Gatewayが最も一般的に使用されるサービスとなっています。
オンプレミスネットワークとの接続に関しては、 Site-to-Site VPNやAWS Direct Connectなどのサービスを引き続きご利用いただけます。AWS Transit Gatewayを使用していて、異なるAWSリージョンにまたがるVPC同士を接続する必要がある場合は、Transit Gatewayのクロスリージョンピアリング機能を活用できます。 また、AWSで構築された第三者のネットワーク上のワークロードやアプリケーションにアクセスしたいというケースもあります。その場合、トラフィックをAWSネットワーク内に留めておきたければ、AWS PrivateLinkを使用することができます。
ネットワーク管理の課題と必要なツール
ご覧の通り、これらのサービスすべてについて詳しく説明することはしませんでしたが、AWSが提供するネットワーク接続オプションの多様性をお示しすることが目的でした。お客様の使用事例によっては、複数のオプションを組み合わせて使用されるケースが一般的です。このような大規模なネットワークを管理する際には、作業を効率的かつスピーディに行うためのツールや機能が必要になることは明らかです。 では、お客様のニーズについて見ていきましょう。大局的に見ると、お客様は効果的にスケールできるようにネットワークを設計することと、利用している様々なネットワークサービスのコストを理解することを考えています。
また、これらのコストを最適化する機会を見出す必要もあります。接続性能を把握し、発生する可能性のある問題をトラブルシューティングできるようにする必要があります。さらに、ネットワーク全体のトラフィックパターンを理解し、意図しない異常なトラフィックを素早く特定して対処できるようにしたいものです。最後に、ネットワークが安全でコンプライアンスに準拠し、組織のベストプラクティスを継続的に満たしていることを確認する必要があります。
これらの要件をもう一段階上げて、これらのタスクを効果的に実行するために何が必要かを考えてみましょう。 お客様としては、ネットワークを可視化する機能が必要です。ネットワーク内の様々なトラフィックパターンを理解し、ネットワーク内の2点間がどのように到達可能か、どのようなパスを通っているのか、どのようなホップが接続に関与しているのかを理解できる必要があります。最後に、ネットワークのパフォーマンスや接続に関する問題を特定してトラブルシューティングできる必要があります。つまり、お客様として、 ネットワークを効果的に観察、分析、トラブルシューティングできる必要があるということです。
本日のセッションでは、 これら3つのカテゴリーにまたがる機能について説明し、日々の運用でどのように活用できるかを検討します。続ける前に一点お断りしておきますが、これは利用可能なすべての機能を網羅的に紹介するものではありません。時間の都合上、現在お客様が使用している様々なアーキテクチャー全般で活用できる、厳選された機能に焦点を当てています。
Resource MapとNetwork Manager：ネットワークの可視化
まずはObserveセクションから始めて、ここでは2つの機能について説明します：Resource MapとAWS Network Managerです。 まずResource Mapから見ていきましょう。 Resource MapはVPCの機能で、VPCのリソースとそれらのリソースに関連するルーティングを1つのページで視覚化することができます。つまり、VPCのアーキテクチャ構成を素早く視覚的に把握することができるのです。
画面に表示されているこの例を見てみましょう。このVPCでは、US East-1AとUS East-1Bリージョンの2つのAvailability Zoneにまたがって6つのサブネットがあることがわかります。これらのサブネットが様々なRoute Tableにどのように接続されているか、そしてそれらのRoute Tableが最終的にVPCエンドポイントやNATゲートウェイ、インターネットゲートウェイなどの接続サービスにどのようにつながっているかが見えます。これによって、VPC内のさまざまな要素間の関係を素早く理解することができます。
このように視覚化できることの素晴らしい点は、 トラブルシューティングにも役立つということです。例を見てみましょう。US East-1B Availability Zoneにあるプライベートサブネット1Bがインターネットに接続できない状況があったとします。よく見ると、このサブネットはデフォルトのRoute Tableに接続されていますが、そのRoute TableがどのNATゲートウェイにも接続されていないことがわかります。数秒で問題の原因が特定できるわけです。さらに便利な点として、 画面上でクリックするだけで該当のページに移動でき、必要な変更を加えて問題を解決することができます。
Resource Mapの基本的な考え方は、お客様が頭の中でこれらの要素を全て関連付けて考えなければならない状況に直面していたという課題を解決することでした。これは明らかに非効率で、ミスが起こりやすい方法でした。Resource Mapでこの問題を解決しようとしたわけですが、開発者コミュニティの間で非常に人気が高いというのは、皆さんにとって驚きではないでしょう。ですので、次回AWSコンソールでVPCを作成する際は、ぜひ この機能を試してみてください。
VPC Flow LogsとTraffic Mirroring：トラフィック分析ツール
では次のトピックに移りましょう。AWS Network Managerについて見ていきます。 先ほどアーキテクチャをお見せした際に、お客様が数百から数千のVPCを持っている場合について触れました。そのような場合、一般的にTransit Gatewayネットワーク、Transit Gateway、またはCloud WANサービスを使用して、これらのVPCを相互に接続し、さらにSite-to-Site VPNやAWS Direct Connectなどのサービスを使用してオンプレミスのワークロードとも接続します。
Network Managerを使用すると、エンドツーエンドのネットワークトポロジーを1か所で素早く把握することができます。この例では、オレゴン、シンガポール、シドニーの3つのAWSリージョンにワークロードがあり、オークランドのリモートオフィスがサイト間VPNを使用してシドニーAWSリージョンに接続されています。この接続にはCloud WANを使用しています。 Network Managerを使用すると、すべてのトポロジーを1ページで素早く可視化でき、 Transit Gatewayでも同様のことが可能です。この例では、Cloud WANで構築したものと同じアーキテクチャですが、唯一の違いは、サンフランシスコにもう1つのオフィスがあり、AWSオレゴンリージョンのワークロードに接続されているという点です。
Network Manager内のもう1つのビューをお見せしましょう。論理的なネットワークトポロジーが見えるだけでなく、ネットワークの実際の地理的位置に基づいてトポロジーを可視化することもできます。また、これらの接続のネットワーク状態を監視することもできます。オークランドオフィスとAWSシドニーリージョン間のサイト間VPN接続に注目してみましょう。 ここで、サイト間VPN接続の1つのトンネルが赤く表示されているのがわかります。これは、トンネルの1つの接続がダウンしていることを示しています。サイトの詳細をすぐに確認したい場合は、ここをクリックして別のコンソールに移動し、設定を確認することができます。
Network Managerについて、人々が時々気づいていないことの1つは、AWSリソースだけでなく、AWSネットワークに接続しているオンプレミスリソースも可視化できるということです。これはCLIまたはコンソールを使用して行うことができます。ここで示している例は、サイト間VPNサービスを使用して接続しているオークランドオフィスです。 そのサイトをNetwork Managerに登録し、デバイスを追加することができます。ここでのデバイスは、VPN接続を確立しているオンプレミスネットワーク上のデバイスを表しています。 VPNサービスに詳しい方なら、これをCustomer Gateway Devicesと呼んでいることをご存知でしょう。これらを登録することで、Network Managerのトポロジーでこれらのデバイスも可視化することができます。
Network Manager内には、お客様の間で非常に人気のある重要な機能がさらに2つあります。その1つは、Transit GatewayやCloud WANのCore Network Edgeに関連する主要なメトリクスを可視化する機能です。us-west-1リージョンのCore Network Edgeについて、過去12時間にどれだけのトラフィックが送受信されたか、どれだけのパケットが送受信されたか、トラフィックがドロップした場合はその理由と量を確認することができます。例えば、ブラックホールやルートなしによってトラフィックがドロップした場合、これらのメトリクスを取得できます。お客様は一般的に、これらのメトリクスをCloudWatchにストリーミングし、必要に応じてアラームを設定しています。
これは私の個人的なお気に入りです。 Network Managerでは、Network Manager Eventsも利用できます。これらは、ネットワークで発生している変更をほぼリアルタイムで説明するイベントです。例えば、Transit GatewayやCloud WANで新しいアタッチメントが追加された場合を考えてみましょう。
また、添付ファイルが削除された場合や、Site-to-Site VPNを使用していてトンネルが確立または切断された場合、あるいはSite-to-Site VPNサービスとの間でルーティングにBGPプロトコルを使用していてBGPが確立または切断された場合など、これらすべてのイベントはNetwork Manager内で生成されます。各イベントをクリックすると、より詳細な情報を確認することができます。
この例では、私のCore Network Edgeの1つにルートが追加されたイベントをお見せしています。このイベントがいつ正確に生成されたのか、どのアカウントで発生したのか、そしてイベントの種類を素早く確認することができます。この場合は、ルーティングの更新イベントで、どのCore Network Edgeにこれらのルートが追加されたのかなど、ルーティングに関連する詳細情報も含まれています。
お客様がこれらのイベントを使って構築される一般的な例として、様々な種類の自動化があります。私が見てきた最も人気のあるユースケースの1つは、Network Managerのイベントを活用するものです。例えば、新しいTransit Gateway Attachmentが確立されてイベントが生成されると、EventBridgeワークフローを開始して、ルーティングルールの作成やアタッチメントのルーティングプロセス全体を自動化するという方法です。この設定方法の詳細については、このブログで段階的な手順を確認することができます。
VPC Reachability AnalyzerとNetwork Access Analyzer：ネットワークトラブルシューティング
ここまでは、Resource MapとNetwork Managerを使用してトポロジーを可視化する方法についてお話ししてきました。次は、AWS network内のトラフィックを分析することに焦点を当て、VPC Flow LogsとTraffic Mirroringについてお話ししたいと思います。その前に、皆さんに質問です。Flow Logsを使用したことがある方、またはFlow Logsについてご存知の方は何人いらっしゃいますか？嬉しいことに、これは私も大好きなツールの1つです。主な理由は、VPC Flow Logsが提供する多様な機能にあります。
お客様がFlow Logsをどのように活用されているかについてお話しする前に、Flow Logsとは何かを説明させていただきます。Flow LogsはVPC内のすべてのトラフィックフローに関する情報を収集して保存することができます。トラフィックフローに関する情報と言っても、オンプレミスのネットワーキングに詳しい方がご存知の一般的な5タプル情報だけではありません。送信元・宛先IPアドレス、送信元・宛先ポート、プロトコルといった情報に加えて、使用しているFlow Logsのバージョンに応じて、AWS関連のメタデータも取得できます。トラフィックが向かうAWSサービスの情報や、トラフィックが発信されているAWSリージョンやアベイラビリティーゾーンの情報といったフィールドを含めることができます。
Flow Logsの一般的なユースケースに話を戻しましょう。その一つがモニタリングです。Flow Logsを使用することで、Flow Logsを有効にしているVPCまたは複数のVPCのトラフィックパターン全体を把握することができます。ネットワーク内のほぼすべてのトラフィックフローに関する情報を収集するため、トラブルシューティングに役立ちます。特定のリソースや期間について、トラフィックがどこから来てどこへ向かっているのかを正確に確認することができます。私たちが見てきた興味深いユースケースの一つは、コスト分析にFlow Logsを活用しているお客様の例です。例えば、Transit Gatewayを集中管理用のネットワークアカウントでホストしているお客様のネットワークチームは、Transit Gatewayを通過したトラフィックについて、アプリケーションやビジネスユニットごとに毎月のコスト配分を行う必要があります。
このようなケースでは、お客様はTransit Gateway Flow Logsを使用してこうした分析を行っています。その他の2つのユースケースは、プランニングとコンプライアンスに関するものです。お客様はFlow Logsを収集してAmazon S3やAmazon CloudWatchに保存できるため、過去のトラフィックパターンを把握し、それを基に将来のトラフィックトレンドを予測して計画を立てることができます。また、規制要件に対応するためにログをアーカイブすることもできます。
Flow Logsを有効にできる場所について説明しましょう。すでに説明したように、VPCレベルでFlow Logsを有効にすることができます。また、リソースベースでFlow Logsを有効にする柔軟性もあり、SubnetレベルやElastic Network Interfaceレベルで有効にすることができます。Transit Gatewayを通過するトラフィックにのみ関心がある場合は、Transit Gateway Flow Logsを有効にすることができます。今年5月には、ECSワークロードに関連するメタデータを取得できる機能をリリースしました。ECSワークロードに対してバージョン7のFlow Logsを使用すると、多くのECSメタデータを確認することができます。
Flow Logsの保存先については、Amazon CloudWatch、Amazon Kinesis Data Firehose、Amazon S3という3つのオプションがあります。この選択は、ユースケースとアプリケーションによって異なります。主にコンプライアンスのためにFlow Logsを保存したい場合や、トラブルシューティングのために頻繁ではないアクセスを行う場合、お客様はデータをAmazon S3に保存する傾向にあります。これらのログを頻繁にモニタリングや分析したいお客様の場合は、CloudWatchに保存します。CloudWatchに保存する追加のメリットとして、Flow Logsの分析に使用できるCloudWatch Log Insightsなど、CloudWatch固有の機能にアクセスできることが挙げられます。最後に、Kinesis Data Firehoseは、Flow Logsを任意の宛先にほぼリアルタイムでストリーミングしたい場合に適しています。
Flow Logsの分析に関しては、CloudWatch Log Insightsについてすぐにご説明します。Amazon QuickSightとAmazon Athenaは、お客様がFlow Logsを分析する他の一般的な方法です。よくある質問として、VPC Flow Logsの異なるバージョン（現在8つのバージョンまであります）についてと、どのバージョンを使用すべきかということがあります。Flow Logsのバージョン2とバージョン3を比較する簡単な例を使って説明しましょう。プライベートSubnetにあるインスタンスDがNAT Gatewayを経由してインターネットにトラフィックを送信する簡単な例を見てみましょう。
インターネット上でこのトラフィックがどのIPアドレスに向かっているのかを知りたい場合、まずPrivate SubnetにあるインスタンスDでFlow Logsのバージョン2を有効にします。バージョン2では、送信元アドレスや宛先アドレスなど、さまざまなフィールドを確認できます。宛先アドレスのフィールドには10.1.2.14が表示されますが、これはNAT Gatewayを指しています。インターネット上の宛先アドレスを知るためには、NAT Gateway上でFlow Logsを有効にする必要があります。NAT GatewayからFlow Logsを取得し始めたら、両方のFlow Logsを相関させることで、インターネット上のどこにトラフィックが向かっているのかを把握できます。
次に、Private SubnetのインスタンスでFlow Logsのバージョン3を有効にした場合を考えてみましょう。ここでは2つの新しいフィールドが追加されています：Packet Source AddressとPacket Destination Addressです。これらのフィールドは、パケットの実際の最終目的地を教えてくれます。この例では、インターネット上の123.1.2.3.4というアドレスです。VPC Flow Logsのバージョン3を使用することで、Private Subnet経由でインターネットにアクセスするトラフィックの行き先を特定する作業が格段に簡単になりました。最近では、AWSサービスへのトラフィックに関する情報も含まれているため、多くのお客様がVPC Flow Logsのバージョン5を使用しています。Transit Gatewayの使用状況を把握したい場合はバージョン6を、Amazon ECSワークロードのECS関連メタデータが必要な場合はバージョン7を使用することができます。
本日お話ししたいもう一つのトピックは、VPC Flow Logsの分析にAmazon CloudWatch Logs Insightsを活用する方法です。CloudWatchチームが最近リリースした機能の一つに、分析作業を効率化するQuery Generatorがあります。Query Generatorを使用すると、実行したい分析を自然言語で表現することができます。この例では、過去1時間の送信元と宛先のペアごとに、トラフィックの平均、最小、最大バイト数を取得したいと考えています。Query Generatorで自然言語を使ってこれを表現し、クエリ生成をクリックすると、 Large Language Modelsを使用してこのクエリがCloudWatchのクエリ言語に変換されます。これは単純な例ですが、ぜひ複雑な例も試してみてください。クエリを実行すると、数秒で過去1時間分の結果を確認することができます。
こちらは、VPC Flow Logsの各バージョンについて、またAmazon AthenaやAmazon QuickSightを使用してFlow Logsを分析する方法について、詳しく学べる有用なリンクです。次は、AnkushがTraffic Mirroringとトラブルシューティングカテゴリの各機能について説明します。ありがとうございました。はい、Nishantさん、ありがとうございました。
先ほど、トラフィックフローやパターンの概要を把握できるVPC Flow Logsについてお話ししました。では、リアルタイムでトラフィックを検査したい場合はどうでしょうか？コンテンツの検査、脅威の監視、またはトラフィックのトラブルシューティングを行いたい場合は？そこで活用できるのがTraffic Mirroringです。Traffic Mirroringを使用すると、EC2インスタンスに接続されたElastic Network Interfaceに出入りするトラフィックをミラーリング（キャプチャ）し、そのデータを別の宛先（ターゲットと呼びます）に送信することができます。ターゲットは、同じVPCまたは異なるVPC内に配置された任意のアプライアンスにすることができます。
Traffic Mirroringでは、異なるプロトコルからトラフィックを受信する場合でも、SSHやHTTPSトラフィックのみを取得したい場合は、フィルターを設定して特定のデータのみをキャプチャすることができます。また、セッションを作成することで、プロトコルに基づいて異なるアプライアンスにこのデータを送信することも可能です。Traffic Mirroringの主な利点は以下の通りです：まず、ソースや送信先にエージェントを導入する必要がありません。Traffic Mirroringがそれを処理してくれます。次に、キャプチャされたデータの改ざんリスクがないため、セキュリティ上の懸念に対応できます。最後に、先ほど述べたように、SSHトラフィックを別の送信先に、HTTPSトラフィックを別のアプライアンスに送信したいというユースケースにも対応できます。
これらのアプライアンスは、同じVPC内に配置することも、VPC PeeringコネクションやTransit Gatewayで相互に接続された異なるVPCに配置することもできます。どの程度のトラフィックが発生するか予測できない場合や、時によって大量のデータを受信したり、逆にわずかなデータしか受信しなかったりする場合は、これらのアプライアンスをNetwork Load Balancerの背後のAuto Scaling groupに配置することで、受信データ量に応じてスケールアウトやスケールインを行うことができます。
サードパーティのアプライアンスを使用したいというお客様もいらっしゃいます。そのようなユーザーの場合、アプライアンスをGateway Load Balancerの背後に配置し、Gateway Load Balancerエンドポイントを使用してトラフィックを送信することができます。ここまで観察と分析のセクションについて説明してきましたが、次はネットワークのトラブルシューティングに利用できるAWSのツールについてお話ししましょう。
パフォーマンス監視ツール：Internet Monitor、Network Synthetic Monitor、Network Flow Monitor
AWSでのネットワークトラブルシューティングの主要なツールの1つがVPC Reachability Analyzerです。これは設定分析ツールで、ソースインスタンスと送信先リソース間の接続性テストを実行することができます。例えば、2つのインスタンスが実行されていて、ネットワークゲートウェイ接続が機能しているかどうかを確認したい場合、VPC Reachability Analyzerを使用してその分析を実行できます。また、設定の意図の検証や自動検証の実行にも役立ちます。
簡単なアーキテクチャを例に、どのように役立つのか見てみましょう。ここでは、Transit Gatewayで相互に接続された2つのVPCがあります。Instance AはInstance Cと通信する必要がありますが、接続が切れています。Security Groupのルールを確認する必要があったり、Network ACLが問題を引き起こしていたり、あるいはRoute Tableが原因である可能性など、いくつかの問題が考えられます。VPC Reachability Analyzerを使用して、これら2つのインスタンスが相互に接続できない理由を分析し、特定する方法を見ていきましょう。
まず、分析を作成することから始めましょう。ソースリソースとしてInstance A、送信先としてInstance C、プロトコルを指定して分析を作成します。数分後、Reachability Analyzerは分析を実行し、これら2つのインスタンスが通信できない理由について詳細な結果を提供します。ここで示されているように、ルートテーブルに送信先へのルートがないことが分かります。また、特定のリソースをクリックするオプションもあり、これによってルートテーブルの該当画面に直接移動して問題を修正することができます。
ソースから送信先までのトラフィックの流れをより深く理解したい場合は、パス詳細を使用することができます。ここでは、ソースから送信先までのすべてのホップが表示され、このパスのどの特定のホップに問題があるのかも指摘されます。アーキテクチャを見ると、問題を引き起こしているのはこのルートテーブルです。この問題を修正して分析を再実行することができます。今度は、VPC Reachability Analyzerが両方のインスタンスが到達可能であることを示し、パス詳細を確認すると、問題のないすべてのホップが表示されます。
ここまでは手動で分析を実行する方法について説明しましたが、大規模な組織ではこのプロセスを自動化したいと考えています。組織内でネットワークの変更が発生するたびに、問題がエスカレートする前に、その変更が何かを破壊していないかを分析して通知を受けたいと考えています。そのために、シンプルなアーキテクチャを用意しました。Security Groupを変更した瞬間にワークフローが開始され、AWS Lambda関数がトリガーされ、Reachability Analyzerを実行して分析を行います。接続性に問題が見つかった場合は、Amazon SNS通知で通知されます。このアーキテクチャについて詳しく知りたい場合は、このQRコードをスキャンしてブログ記事をお読みください。
これまで2つの機能について説明しました：手動での分析実行とプロセスの自動化です。しかし、これらはどちらもネットワークの深い知識が必要です。では、ネットワークの知識がない組織のユーザーはどうすればよいのでしょうか？そういったユーザーのために、VPC Reachability AnalyzerをAmazon Qと組み合わせて使用することができます。ここでは、シンプルな日常的な英語で質問を入力できます。例えば「なぜ私のインスタンスがInstance Cと通信できないのか？」といった具合です。インスタンスIDを指定したり、どのVPCに属しているのか、Security Groups、Network ACLs、VPCの接続方法などの詳細を説明する必要はありません。Amazon Qがバックグラウンドで、VPCやインスタンスの特定、それらの接続方法など、すべての作業を行います。数分後には、これら2つのインスタンスが通信できない理由について詳細な分析結果を提供します。
Instance Aが通信できない理由は、ルートテーブルにルートがないためであることが明確に示されます。また、この問題を解決するためにルートテーブルにルートを追加する方法など、対処手順も提供されます。ネットワークの知識がない方がいても心配ありません。私たちにはそのためのツールがあります。トラブルシューティングの問題があっても、ネットワークの専門家に相談する必要はありません - このツールを試してみてください。
先ほどVPC Reachability Analyzerについて説明しましたが、これはポイントツーポイントの接続性テストを実行する機能です。では、ネットワークのより詳細な分析を行いたい場合はどうすればよいでしょうか？VPC内部から外部へのすべての可能なパス、あるいはVPCへ向かうすべての可能なパスを理解したい場合には、Network Access Analyzerを使用できます。Network Access Analyzerを使用すると、ネットワークアクセス要件を定義し、分析を実行して、要件を満たさないネットワークパスを特定し、そこから必要なアクションを取ることができます。
デフォルトでは、VPCのエグレス、イングレス、そしてIGWのイングレスとエグレスという4つのデフォルトスコープが用意されています。これらのスコープはそれぞれ異なる目的を持っています。例えば、VPCエグレスの場合、VPC内のENIから始まり、Transit Gateway、Internet Gateway、VPC endpoint、またはピアリング接続に向かうすべての可能なパスを取得することができます。プレゼンテーションの冒頭で構築したシンプルなアーキテクチャを使って、VPCスコープで同じ分析を実行してみましょう。
この分析では、ソースがネットワークインターフェース、つまりアーキテクチャ内のすべてのネットワークインターフェースとなり、可能なパスの宛先はInternet Gateway、ピアリング接続エンドポイントなどとなります。インスタンスやENIから外部へ向かうすべての組み合わせのパスを見つけ出します。このトラフィックを分析すると、数分で接続性を持つすべてのソースとデスティネーションリソースについて、VPC内のENIからIGW、TGWアタッチメント、またはVPCエンドポイントへのパスを示す詳細な表示が得られます。各検出結果について、ソースと宛先間のホップバイホップの詳細なパスも提供され、ネットワークを通じてトラフィックがどのように流れているかを完全に可視化できます。これら4つのデフォルトスコープに加えて、異なるスコープやカスタムスコープを作成することもできます。
ネットワークのトラブルシューティング方法や、ネットワークの全体像を分析・把握する方法について説明してきましたが、ここでパフォーマンスの観点からネットワークのトラブルシューティングについて説明しましょう。ここでは、ロードバランサーを介してAmazon S3からデータにアクセスしようとするワークロードがVPCで実行されている単純なアーキテクチャを例に挙げます。インターネット経由でこのアプリケーションにアクセスしようとするユーザーと、AWS Direct Connect接続を介してオンプレミス環境からアクセスするユーザーがいます。時にこれらのユーザーからアプリケーションのパフォーマンスに関する苦情が寄せられることがありますが、ネットワークチームとアプリケーションチームの両方にとって、問題がインターネット上にあるのか、オンプレミスのDirect Connect接続にあるのか、それともAWSワークロード内にあるのかを特定することは非常に困難です。
今日は、問題がどこにあるかを特定するのに役立つ3つの異なる機能について説明します。最初のサービスはInternet Monitorです。先ほど説明したように、AWSでアプリケーションを実行し、世界中の顧客がインターネット経由でこのアプリケーションにアクセスしています。時々パフォーマンスが低下したという苦情があり、問題がどこにあるのか不明確な場合があります。問題は顧客側にある可能性もあります - 例えば、ラップトップに問題を引き起こすパッチをインストールした可能性があります。あるいは、AWSでホストされているアプリケーションやAWS内に問題がある可能性、またはインターネット自体に問題がある可能性もあります。このような問題を特定するのにInternet Monitorが役立ちます。
Internet Monitorは、インターネットの問題がAWSアプリケーションのパフォーマンスと可用性にどのように影響を与えているかを把握するのに役立ちます。問題がAWSアプリケーション内にあるのか、それともAWS外のインターネット上にあるのかを特定することで、診断時間を数日から数分に短縮します。また、コードを書くことなく、異なる地理的位置やネットワークにおけるユーザーの問題を監視することができます。
ユーザーエクスペリエンスを向上させるため、別のAWSリージョンを使用したり、異なるリージョンを経由してトラフィックをルーティングしたりする提案も行います。CloudWatch Internet Monitorは4つの主要なコンポーネントで構成されています。まず、AWSリソースを選択することから始まります。現在サポートしているリソースは、Amazon VPC、Network Load Balancer、Amazon CloudFront、Amazon WorkSpacesの4つです。
次に、監視したいトラフィックの割合を指定し、これによってトラフィックプロファイルが作成されます。そして、このトラフィックプロファイルをインターネットウェザーマップデータと重ね合わせます。これは、AWSが異なる場所、インターネットプロバイダー、さまざまな地理的エリアから継続的に収集しているデータです。トラフィックプロファイルとこのインターネットウェザーマップデータを重ね合わせることで、Internet Monitorはコンソール上でリアルタイムのインサイトと最適化の提案を提供し、エンドユーザーのパフォーマンス向上に役立ちます。
ダッシュボードの観点から見ると、午前9時から午後1時30分の間にエンドユーザーがアプリケーションへのアクセスで問題に直面していたことがわかります。さらに詳しく調べたい場合は、その時間帯の往復時間や転送された、あるいは損なわれたバイト数も表示されます。さらに、どの場所が影響を受けたのか、それらの場所からのトラフィックがアプリケーションにどの程度影響を与えたのかについての情報も提供されます。これらのメトリクスを使用することで、インターネットの問題がアプリケーションのパフォーマンスに影響を与えたかどうかを明確に判断でき、一つの要素を除外して他の潜在的な問題に焦点を当てることができます。
では、Direct Connect（DX）を介したハイブリッド接続における問題の検出方法を見てみましょう。このケースでは、DX接続を介してオンプレミスと接続されたVPCでアプリケーションが実行されています。高可用性のためにXとYのパスに2つの接続があります。DXの一部は顧客またはパートナーによって管理され、もう一部はAWSによって管理されています。このシナリオでは、アプリケーションはオンプレミスのユーザーによってアクセスされ、パケットロスやレイテンシーに非常に敏感です。
パケットロスが発生し、ユーザーからパフォーマンスの問題について苦情が寄せられた場合、BGPだけでは問題を特定するのが難しい場合があります。BGPはTCPをベースに構築されており、再送信機能があるため、BGP接続が切断されることなく正常に動作しているように見えることがあります。そこで重要な役割を果たすのが、Network Synthetic Monitorです。 Network Synthetic Monitorを使用すると、AWSでホストされているアプリケーションとオンプレミス環境を接続するネットワークのパフォーマンスを可視化でき、数分以内にネットワークパフォーマンスの低下の原因を特定することができます。
Network Synthetic Monitorのセットアップは簡単です。ワークロードが稼働しているサブネットと、オンプレミスのワークロードが存在するサブネットまたは宛先を指定するだけで、数回のクリックで設定が完了します。重要なポイントは、送信元や宛先にエージェントをインストールする必要がないことです。これにより、問題の検出が迅速化され、KPIベースのヘルスインジケーターが提供され、すべてのメトリクスがCloudWatchに統合されます。
まず、アプリケーションが稼働しているワークロードのサブネットを選択します。AWSは高可用性のために各サブネットに2つのENI をデプロイし、プローブを作成します。宛先では、ルーターのIPアドレス、サーバーのIPアドレス、またはループバックIPアドレスなどのIPアドレスを指定する必要があります。この情報を入力すると、宛先IPアドレスにパケットを送信し、情報を収集するプローブが作成されます。これにより、3種類のメトリクスが得られます： ネットワークヘルスインジケーター、パケットロス、往復時間です。ネットワークヘルスインジケーターは、異常検知を使用してAWS Direct Connectパスのパフォーマンスと可用性に関する洞察を提供し、AWS管理ネットワークルートの問題を特定します。このインジケーターはAWSが管理しており、パフォーマンスがAWSが管理するDirect Connectによって影響を受けたかどうかを明確に示します。
さらに、送信された総パケット数に対する、関連する応答を受信しなかった送信の割合を測定するパケットロスメトリクスも提供されます。これにより、Direct Connect接続でどの程度のパケットロスが発生しているか、そしてパケットロスがアプリケーションのパフォーマンスに影響を与えているもう一つの原因であるかどうかを判断することができます。
同様に、往復時間については、パケットを送信して応答パケットを受信します。これに基づいてミリ秒単位で計算し、往復時間がどの程度かかっているか、レイテンシーが高いかどうかを示すメトリクスを提供することで、適切な対応を取ることができます。 ここまでで、インターネット上で発生する問題をどのように軽減または特定できるかについて、2つのサービスについて説明してきました。また、Direct Connect接続で発生する問題をどのように特定できるかについても説明しました。ここで視点を変えて、AWS内で発生する問題をどのように特定できるかについて説明していきましょう。
re:Invent直前の日曜日に、Network Flow Monitorという新機能をリリースできたことをお知らせできて嬉しく思います。この新機能により、2つのインスタンス間や、Amazon S3やDynamoDBなどの他のAWSサービスとの間のパケットロスやレイテンシーなど、ネットワークパフォーマンスについてほぼリアルタイムの洞察が得られるようになりました。インスタンスに軽量なエージェントをインストールすると、TCPコネクションを使用してメトリクスデータの収集を開始します。収集されたデータはFlow Monitorに送信され、アプリケーションのパフォーマンスに影響を与える主要な要因が分析されます。これは、ネットワークの専門家にもデベロッパーにも最適で、CloudWatchで直接実用的な洞察を提供します。
EC2インスタンスに軽量エージェントをインストールすると、インスタンスとS3バケット間のすべてのデータ転送を捕捉します。Flow Monitorはこのデータを分析し、インスタンスからS3バケットへのデータ転送量を表示し、データ転送の主要な要因を特定します。 より詳しく調べたい場合は、その特定のトップブロッカーに対してモニターを作成し、ネットワークヘルスインジケーター、往復時間、再送信データ、またはそれらのコンポーネント間のデータ転送などの詳細情報を取得できます。ネットワークヘルスインジケーターは、作成したネットワークフローにAWSネットワークの問題があったかどうかを示します。ネットワークヘルスインジケーターが低下している場合、AWSサイドのネットワークに問題があることを意味し、それがAWSの問題なのか、アプリケーションの問題なのかを適切に判断する助けとなります。
さらに、ネットワークトラフィックのサマリーでは、パケットの往復時間、再送信データ、再送信エラー、そしてデータ転送メトリクスを確認できます。往復時間、再送信、データ転送を示すこれらのグラフは、同じ画面に表示されます。 これらの機能についてさらに詳しく読むには、こちらのQRコードを撮影してください。
セッションのまとめと今後の学習機会
今日のレビューをしましょう。アーキテクチャがいかに複雑で大規模になり得るか、そしてモニタリングとトラブルシューティングに異なるツールセットが必要になることについて説明しました。Resource MapsとNetwork Managerを使用してアーキテクチャの全体像を把握する方法について話し合いました。VPC Flow LogsやTraffic Mirroringを使用してトラフィックを分析できます。トラブルシューティングについては、ポイントツーポイントの接続テスト用のVPC Reachability Analyzer、VPC内のすべてのトラフィックの包括的な把握のためのNetwork Access Analyzerについて説明しました。最後に、インターネット、Direct Connect接続、またはAWS内で問題が発生しているかを特定するための3つのツールについて説明しました。
これらのトピックについてさらに詳しく知りたい方は、1時間30分後に同様のトピックを扱うChalk Talkセッションがあります。そこで質問をすることができます。木曜の午後にご参加いただき、ありがとうございました。アンケートの記入をお忘れなくお願いします。
※ こちらの記事は Amazon Bedrock を利用することで全て自動で作成しています。
※ 生成AI記事によるインターネット汚染の懸念を踏まえ、本記事ではセッション動画を情報量をほぼ変化させずに文字と画像に変換することで、できるだけオリジナルコンテンツそのものの価値を維持しつつ、多言語でのAccessibilityやGooglabilityを高められればと考えています。
Discussion