インターネットゲートウェイを介した VPC 内の EC2 Linux インスタンスまたは Windows インスタンスとオンプレミスホストとの間で発生したネットワークパフォーマンスの問題をトラブルシューティングするにはどうすればよいですか?

最終更新日: 2022 年 12 月 6 日

インターネットゲートウェイ経由の Amazon Elastic Compute Cloud (Amazon EC2) インスタンスとオンプレミスホストとの間でパケットロスやレイテンシーが生じています。ネットワークパフォーマンスをテストしてこの問題をトラブルシューティングする方法を教えてください。

簡単な説明

パケットロスやレイテンシーなどのネットワークの問題を診断するには、まずネットワークをテストして問題の原因を特定していきます。下記に示す解決方法は、問題の原因がネットワークにあるのかアプリケーションにあるのかを判断するのに役立ちます。パフォーマンスの問題が発生したときに結果を比較できるよう、パフォーマンス結果のベンチマークを実施しておくのがベストプラクティスです。

トラブルシューティングを開始する前に、以下を確認してください。

  • ネットワークユーティリティが両方のエンドポイント (EC2 インスタンスおよびオンプレミスホスト上) にインストールされていることを確認します。
  • 拡張ネットワークをサポートする EC2 インスタンスを使用し、ドライバーが最新のものであることを確認します。拡張ネットワークは低い CPU 使用率でより高い I/O を提供するので、パフォーマンステストを実行するときにインスタンスレベルの問題を回避するのに役立ちます。拡張ネットワークが有効になっていない場合は、「Linux での拡張ネットワーキングまたは「Windows での拡張ネットワーキング」を参照してください。
  • EC2 インスタンスに接続してインスタンスにアクセスし、EC2 インスタンスとオンプレミスホストの間にエンドツーエンドの接続があることを確認します。

解決方法

トラブルシューティングに役立つ次のツールをインストールして、ネットワークをテストします。

  • パケット損失、レイテンシー、MTR、 tcptraceroute、および tracepath などのネットワークメトリックスを収集する AWSSupport-SetupIPMonitoringFromVPC
  • ICMP または TCP パケット損失とレイテンシーの問題をチェックする MTR。
  • Traceroute を使用してレイテンシーまたはルーティングの問題を解決します。
  • エンドツーエンドTCPパケットロスおよびレイテンシーの問題を解決するHping3
  • パケットキャプチャーサンプルを分析するためのTcpdump。

ボトムアップアプローチを使用して、traceroute または MTR レポートのホップを検証します。例えば、まず最終ホップまたは送信先でのロスを確認し、次にそれより前のホップを検証します。パケットロスまたはレイテンシーの問題が最終ホップまで継続的に発生する場合は、ネットワークまたはルーティングに問題がある可能性があります。パケットロスまたはレイテンシーがパス内の 1 つのホップで見られる場合は、そのノードのコントロールプレーンレート制限に問題がある可能性があります。レポートされた最終ホップがコマンドで記述された送信先であるかどうかを確認してください。そうでない場合は、制限セキュリティグループによって引き起こされた問題がある可能性があります。

AWSSupport-SetupIPMonitoringFromVPC を使用してパフォーマンスをテストする

この組み込みツールはネットワークの問題を解決する必要のあるメトリックスの多くを収集します。詳細については、「Debugging tool for network connectivity from Amazon VPC」(Amazon VPC のネットワーク接続のデバッグツール) をご覧ください。

Linux インスタンスのパフォーマンスをトラブルシューティングする

Linux のパフォーマンス統計を確認する

送信元インスタンスまたは送信先インスタンスにアクセスできる場合は、CPU、メモリ使用率、ロード平均に問題がないか確認してください。

MTR を使用してパフォーマンスをテストする

Linux MTR コマンドは、継続的に更新される出力を提供します。この出力により、ネットワークパフォーマンスを分析できます。この診断ツールは、traceroute と ping のユーティリティを組み合わせたものです。ほとんどの Linux ディストリビューションには、traceroute と MTR がプリインストールされています。ディストリビューションのソフトウェアパッケージマネージャーからダウンロードすることもできます。

MTR をインストールするには、次のコマンドを実行します:

Amazon Linux:

sudo yum install mtr

Ubuntu:

sudo apt-get install mtr-tiny

MTRを使用してネットワークの性能をテストするためには、このテストをEC2インスタンスのパブリックIPアドレスおよびオンプレミスホストとの間で相互方向に実行します。方向が逆になった場合は、TCP/IPネットワークのノード間のパスは変化します。よって、両方向のためにMTR結果を獲得することは重要です。ほとんどのインターネットデバイスでは ICMP ベースのトレースリクエストに設定される優先度が低いため、ICMP の代わりに TCPベース のトレースを使用できます。

パケットロスをレビューします。シングルホップのパケットロスは通常問題を示しません。このロスは「ICMP時間超過」のメッセージがデロップ表示される原因となる、コントロールプレーンポリシーの結果である可能性があります。送信先ホップまで持続するパケットロス、または複数のホップのパケットロスに気づいた場合は、このロスは問題である可能性があります。

注意: リクエスト時間切れが数回見られることは一般的です。

ICMPベースMTR:

mtr -n -c 200 <Public IP EC2 instance/on-premises host> --report

TCPベースMTR:

mtr -n -T -c 200 <Public IP EC2 instance/on-premises host> --report

引数 -T は TCP ベースの MTR を実行し、--report オプションは MTR をレポートモードにします。MTR は -c オプションで指定されたサイクル数実行します。統計を出力して終了します。

注: TCP ベースの MTR は送信先 TCP ポート 80 をテストして、特定の送信先 TCP ポートを MTR します (-P が付加され、その後にポート番号が続きます)。送信先 TCP ポート 443 を MTR する例を次に示します。

mtr -n -T -c 200 <Public IP EC2 instance/on-premises host> -P 443 --report

traceroute を使用してパフォーマンスをテストする

Linux traceroute ユーティリティは、クライアントノードから送信先ノードへのパスを識別します。このユーティリティは、各ルーターがリクエストに応答する時間をミリ秒単位で記録します。このユーティリティは、各ホップが送信先に到達するまでの所要時間も計算します。

traceroute をインストールするには、次のコマンドを実行します:

Amazon Linux:

sudo yum install traceroute

Ubuntu:

sudo apt-get update
sudo apt-get install traceroute

注: MTR レポートを実行する場合は、traceroute を実行する必要はありません。MTR はレイテンシーおよびパケットロスの統計を送信先に提供します。

ポート 22 またはテストするポートが両方向に開いていることを確認してください。traceroute を使用してネットワーク接続のトラブルシューティングを行うには、コマンドをクライアントからサーバーに対して実行し、サーバーからクライアントに対して実行します。方向が逆になった場合は、TCP/IPネットワークのノード間のパスは変化します。ほとんどのインターネットデバイスでは ICMP ベースのトレースのリクエストに設定される優先度が低いため、ICMP の代わりに TCP ベース のトレース (アプリケーションポート) を使用します。

ICMP ベースの traceroute:

sudo traceroute -I <Public IP of EC2 instance/on-premises host>

TCPベースのtraceroute:

sudo traceroute -n -T -p 22 <Public IP of EC2 instance/on-premises host>

引数 -T -p 22 -n は、ポート 22 で TCP ベースのトレースを実行することを意味します。

注: アプリケーションに固有のポートをテストに使用できます。特定のポートを使用し、アプリケーショントラフィックが低下している経路に中間デバイスが存在しているかどうかを確認します。

hping3 を使用してパフォーマンスをテストする

hping3 は、TCP 接続のエンドツーエンドのパケットロスおよびレイテンシーを測定するコマンドライン指向の TCP/IP パケットアセンブラおよびアナライザーです。ICMP エコーリクエストに加えて、hping3 は TCP、UDP、および RAW-IP プロトコルをサポートします。Hping3 には、対象のチャネル間でファイルを送信できる traceroute モードも含まれています。Hping3 はホストのスキャン、侵入テストの支援、侵入検知システムのテスト、およびホスト間のファイルの送信を行うことを目的に設計されています。

MTR および traceroute はホップごとのレイテンシーをキャプチャします。しかし、hping3はパケットロスに加え、TCP上のエンドツーエンドの最小/平均/最大レイテンシーの結果を収量します。hping3 をインストールするためには、次のコマンドを実行します:

Amazon Linux 2。RHEL 7 用の EPEL リリースパッケージをインストールし、EPEL リポジトリをアクティブ化します。

sudo amazon-linux-extras install epel -y

Amazon Linux 2:

sudo yum --enablerepo=epel install hping3

Ubuntu:

sudo apt-get install hping3

以下のコマンドはポート0上で50 TCP SYNのパケットを送信します。デフォルトでは、hping3 からターゲットホストのポート 0 に TCP ヘッダーが winsize の 64 および TCP フラグなしで送信されます。

sudo hping3 -S -c 50 -V <Public IP of EC2 instance/on-premises host>

次のコマンドはポート 22 から 50 TCP SYN パケットを送信します。

sudo hping3 -S -c 50 -V <Public IP of EC2 instance/on-premises host> -p 22

注: ポート 22 またはテストするポートが開いていることを確認してください。

tcpdump を使用してパケットキャプチャのサンプルをテストする

パケットロスまたはレイテンシーの問題を診断する際は、EC2 インスタンスおよびオンプレミスホスト上で同時にパケットキャプチャを行うのがベストプラクティスです。これにより、リクエストパケットとレスポンスパケットを識別して、ネットワークレイヤーとアプリケーションレイヤーで問題を切り分けることができます。また、最初にパケットキャプチャを開始してからトラフィックを開始することもベストプラクティスです。これにより、フローのすべてのパケットをキャプチャできます。tcpdump をインストールするには、次のコマンドを実行します:

Amazon Linux:

sudo yum install tcpdump

Ubuntu:

sudo apt-get install tcpdump

tcpdump をインストールしたら、次のコマンドを実行して、tcp ポート 22 のトラフィックをキャプチャし、pcap ファイルに保存します。

sudo tcpdump -i eth0 port 22 -s0 -w samplecapture.pcap

注: tcpdump フラグ -i は、tcpdump がトラフィックをキャプチャするインスタンス上のインターフェイスを指定します。インターフェイスを eth0 から環境内の設定済みインターフェイスに変更する必要がある場合があります。

Windows のパフォーマンスをトラブルシューティングする

ECN 機能のチェック

1.    次のコマンドを実行して、明示的輻輳通知 (ECN) 機能がオンになっているかどうかを判断します。

netsh interface tcp show global

2.    ECN 機能が有効になっている場合は、次のコマンドを実行して無効化します。

- netsh interface tcp set global ecncapability=disabled

3.    パフォーマンスが改善されない場合は、次のコマンドを使用して ECN 機能を再度有効にすることができます。

netsh interface tcp set global ecncapability=enabled

ホップを検証して、TCP ポートの接続性をトラブルシューティングする

まず、MTR または tracert を使用してホップを検証します。

MTR メソッド:

1.    WinMTR をダウンロードしてインストールします。

2.    [Host] セクションに送信先 IP を入力してから、[Start] を選択します。

3.    テストを 1 分間実行した後、[Stop] を選択します。

4.    [Copy text to clipboard] を選択して、テキストファイルに出力を貼り付けます。

5.    送信先に伝達される % 列にロスがないか調べます。

注:No response from host」(ホストからの応答がありません) のメッセージがあるホップは無視してください。このメッセージは、これらの特定のホップが ICMP プローブに応答していないことを示します。

6.    ボトムアップアプローチを使用して MTR レポートのホップを検証します。例えば、まず最終ホップまたは送信先でロスを確認し、次にそれより前のホップを検証します。

Tracert メソッド:

MTR をインストールしたくない場合は、tracert コマンドユーティリティツールを使用できます。

1.    tracert を送信先の URL または IP アドレスに対して実行します。

2.    ラウンドトリップタイム (RTT) が突然急上昇したホップを探します。RTT の突然の急増は、高負荷のノードがあることを示します。これにより、トラフィックにおけるレイテンシーまたはパケットドロップが誘発されます。

注: -d オプションは IP アドレスをホスト名に解決しません。IP からホスト名への解決が必要な場合は、-d を削除してください。

tracert -d <Public IP of EC2 instance/on-premises host>

その後、TCP ポートの接続性を確認します。

注: WinMTR と tracert は両方とも ICMP ベースであるため、tracetcp を使用して TCP ポートの接続性をトラブルシューティングできます。

1.    WinPcaptracetcp をダウンロードします。

2.    Tracetcp ZIP ファイルを展開します。

3.    tracetcp.exe を C ドライブにコピーします。

4.    WinPcap をインストールします。

5.    コマンドプロンプトを開き、C:\Users\username>cd \ コマンドを使用して WinPcap を C ドライブにルートします。

6.    tracetcp.exehostname:port または tracetcp.exe ip:port コマンドを使用して tracetcp を実行します。

Windows タスクマネージャーを確認する

送信元インスタンスまたは送信先インスタンスにアクセスできる場合は、Windows タスクマネージャーをチェックします。CPU とメモリの使用率、または平均負荷の問題を探します。

パケットキャプチャを取得する

注: パケットロスまたはレイテンシーの問題を診断する際は、EC2 インスタンスおよびオンプレミスホスト上で同時にパケットキャプチャを実行するのがベストプラクティスです。これは、リクエストおよびレスポンスパケットを特定して、ネットワークレイヤーとアプリケーションレイヤーで問題を切り分けるのに役立ちます。また、最初にパケットキャプチャを開始してからトラフィックを開始することもベストプラクティスです。これにより、フローのすべてのパケットをキャプチャできます。

1.    Wireshark をインストールして、パケットキャプチャを取得します。

2.    (ip.addr eq source_IP) && (tcp.flags.syn == 1) フィルターを使用して、パケットキャプチャにある特定の送信元の間におけるトラフィックを分離させます。出力には、その送信元 IP によって開始されたすべての tcp ストリームが表示されます。

3.    関連する送信元 IP と送信先 IP がある行を選択します。

4.    コンテキスト (右クリック) メニューを選択してから、FollowTCP Stream と選択します。こうすることにより、調査したい送信元 IP と送信先 IP の間における TCP フローがわかります。

5.    再送信、重複するパケット、または TCP window fullWindow size zero といった TCP ウィンドウサイズの通知を探します。これらの通知は、TCP バッファの容量が不足していることを示している可能性があります。

パケットロスが見つかった場合や、ホップ数がベンチマークと大きく異なる場合は、ネットワーク機器のベンダーのドキュメントを参照してください。マルチホームネットワーク環境で作業している場合は、別の ISP を使用してこれらのテストを実行してください。


この記事はお役に立ちましたか?


請求に関するサポートまたは技術サポートが必要ですか?