【実録】AWSへの上り通信だけがなぜか遅い… 専用線接続なのに、実効値が10～20％しか出ない問題の体系的トラブルシューティング

はじめに

「オンプレミスからAWSへDirect Connectで専用線を引いた。回線は100Mbpsの帯域保証。しかし、なぜかファイルアップロードだけ非常に遅い…。」

この記事では、このようなTCP通信の性能問題を解決するために、筆者が実際に行った体系的な切り分け手法を、順を追って解説します。

1. 事象の整理と前提条件

まずは、今回取り組む問題の典型的な症状を整理します。

• 事象: オンプレミスの拠点からAWS上のEC2サーバーへファイルをアップロードする際、スループットが契約帯域（例: 100Mbps）を大幅に下回る（例: 10Mbps）。
• 構成: 拠点PC -> 社内ルーター -> 広域イーサネット(100Mbps) -> AWS Direct Connect(1Gbps以上) -> EC2
• 初期調査:
  • 拠点からEC2へのPing応答時間(RTT)は10ms前後と非常に良好。
  • AWS内のEC2同士の通信は数百Mbps以上出ており、サーバー自身の性能に問題はなさそう。

この状況から、「単純な回線や機器の故障」ではない、より複雑な問題が潜んでいると推測できます。

2. ステップ1：ネットワークの「基礎体力」を測定する (iperf3)

トラブルシューティングの第一歩は、アプリケーション（ファイル転送）とネットワーク経路の問題を切り分けることです。そのための最適なツールが iperf3 です。

2-1. UDPテスト：物理経路の帯域を確認する

まず、TCPの複雑な制御を介さないUDPで、物理的な回線が持つ本来の性能を測定します。

• 目的: 物理的な回線・機器が契約帯域のデータを送受信できるかを確認する。
• 方法:
  1. AWS EC2（サーバー側）で iperf3 -s を実行。
  2. 拠点PC（クライアント側）で iperf3 -c <EC2のIP> -u -b 100M を実行。(-bで帯域を指定)
• 判断:
  • 100Mbps近く出た場合: 物理的なネットワーク経路は正常です。ボトルネックはTCPプロトコルか、その上で動くアプリケーションにあります。
  • 出なかった場合: 物理的な故障、機器の速度設定ミス、回線事業者の帯域制限などを疑います。

2-2. TCPテスト：単一 vs 複数セッション

次に、実際の通信で使われるTCPのスループットを測定します。ここで重要なのは**「単一セッション」と「複数セッション」を比較する**ことです。

• 目的: TCPプロトコルの挙動に問題がないかを確認する。
• 方法:
  • 単一セッション: iperf3 -c <EC2のIP>
  • 複数セッション: iperf3 -c <EC2のIP> -P 10 (-Pでセッション数を指定)
• 判断（今回の問題の核心）:
  • 単一セッションは遅い（10Mbps）が、複数セッションだと合計で速い（100Mbps）
    • これは、今回のトラブルの典型的な症状です。
    • ネットワーク全体には100Mbpsの空きがあるのに、1本のTCPコネクションがそれを使い切れていない状態を示します。
    • この結果が出た時点で、原因は**「パケットロス」または「TCPウィンドウサイズの問題」**である可能性が極めて高くなります。

3. ステップ2：犯人はどこだ？仮説と検証

iperf3の結果から、TCPセッションが性能を出し切れていないことがわかったとします。その場合はネットワークには問題がないことがわかりました。次に、その原因がどこにあるのかを特定していきます。

3-1. 仮説A：経路でのパケットロス

わずか0.1%のパケットロスでも、WAN越しのTCPスループットは劇的に低下します。

• 検証ツール: mtr (Windowsの場合は WinMTR)
• 方法: 拠点PCからEC2サーバーに向けてmtrを実行し、数分間放置します。
• 判断:
  • Loss% の列に0以外の数値が表示されたホップ（ルーター）があれば、そこがロスを発生させている犯人です。
  • 注意点: mtrでロスが検出できなくても、安心はできません。「マイクロバースト」と呼ばれる瞬間的なパケットの集中により、mtrの低頻度なパケットでは検知できないロスが発生している可能性があります。その場合は、ルーターやスイッチのインターフェースカウンターで drops や discards が増加していないかを確認するのが有効です。

3-2. 仮説B：サーバーサイドの性能

「AWS内の通信は速い」という情報で、サーバーが原因である可能性は低いと判断しましたが、念のため確認プロセスを記します。

• 検証方法:
  1. EC2のインスタンスタイプ（t系などベースライン性能が低いものではないか）とEBSのボリュームタイプ（gp2, gp3など）と、そのIOPS/スループット設定を確認する。
  2. （最重要） 問題のサーバーと同じVPC内にある別のEC2から、iperf3やファイル転送テストを実施する。
• 判断: AWS内でのテストで目標スループットが出れば、サーバーサイドは完全に無罪（シロ）です。

3-3. 仮説C：ネットワーク機器の設定

• 検証方法: 経路上のルーターやファイアウォールに、特定の通信を対象としたQoS（帯域制御）やアクセス制御リスト(ACL)が設定されていないかを確認します。

4. ステップ3：最終手段 - 通信の中身を覗く (Wireshark)

ステップ2までの調査で原因が特定できない場合、いよいよTCP通信そのものの中身を解析します。これは、見えざる問題の最終的な証拠を掴むためのステップです。

• 検証ツール: Wireshark
• 方法: 拠点PCでWiresharkを起動してパケットキャプチャを開始し、問題のアップロードを再現させます。
• 見るべきポイント:
  • TCP Retransmission (再送): これが多発している場合、経路上でパケットロスが起きている決定的な証拠です。
  • TCP Duplicate ACK: パケットロスや順序入れ替わりの兆候です。
  • TCP ZeroWindow: サーバー側（受信側）が「もうデータを受け取れない」と通知している状態で、サーバー側のアプリケーションやディスク書き込みが追いついていない可能性を示します。
  • Window Scale オプション: TCP接続確立時（SYNパケット）のウィンドウサイズのネゴシエーションが適切に行われているかを確認します。

今回のケースでは、AWS内部の通信が高速であることからサーバー側の問題は除外されました。また、MTRやカウンターでロスが検出されなかったため、犯人は「検知しにくいレベルの微小なパケットロス」か「クライアントPCまたは経路上でのTCPウィンドウの律速」であると推測されます。Wiresharkによる解析は、このどちらが原因であるかを突き止めるための最も確実な方法です。

まとめ

一見不可解なネットワーク問題も、体系的なアプローチで切り分けることで、原因にたどり着くことができます。

1. iperf3 (UDP/TCP単一/TCP複数) で、問題が物理層かTCP層かを切り分ける。
2. mtr で明らかなパケットロスがないか確認する。
3. AWS内部での速度テストで、サーバーサイドの問題を切り分ける。
4. それでも解決しない場合は、**Wireshark**でTCP通信の中身を直接解析する。

今回のトラブルシューティングは、ネットワークの性能が単なる帯域だけでなく、遅延(RTT)、パケットロス、そしてTCPのウィンドウ制御という複数の要素が複雑に絡み合って決まることを改めて教えてくれました。同様の問題に直面した際の、一助となれば幸いです。