はじめに
「自社サービスのレスポンスが遅い」とのクレームがあったことがありました。ネットワーク関連が得意ではないですが、だいたい社内検証では遅くないしということでトレースルートを使うことにしました。
問題の特定
まず、サービスのエンドポイントに対してトレースルートを実行してみました。
Windowsの場合:
tracert myservice.example.com
Unix/Linux/Macの場合:
traceroute myservice.example.com
検証結果
C:\Users\YourUser>tracert myservice.example.com
myservice.example.com [203.0.113.10] へのルートをトレースしています
経由するホップ数は最大 30 です:
1 150 ms 160 ms 170 ms 192.168.1.1
2 200 ms 210 ms 220 ms 100.64.1.1
3 250 ms 260 ms 270 ms 203.0.113.1
4 300 ms 310 ms 320 ms 153.149.204.94
5 350 ms 360 ms 370 ms 153.149.204.89
6 100 ms 98 ms 100 ms 52.93.7.1
7 110 ms 108 ms 110 ms 52.93.7.2
8 120 ms 118 ms 120 ms 52.93.126.34
9 130 ms 128 ms 130 ms 52.93.132.45
10 140 ms 138 ms 140 ms 54.239.111.10
11 150 ms 148 ms 150 ms 54.239.106.31
12 160 ms 158 ms 160 ms 203.0.113.10
トレースを完了しました。
最初のホップから5番目のホップまでの遅延が異常に高いことがわかります。各ホップに対して3回のパケットを送信してRTT（ラウンドトリップタイム）を計測するんですね。
特にホップ1（192.168.1.1）は社内ルーターのIPアドレスで、ここで既に明らか遅延が発生していることから、問題が社内ネットワーク内にあると判断ができました。rdpで試してそっちのせいですよとすぐにエビデンス提示できるのがいいですね。
実際はクライアントのルータの再起動で解消したようです。ルータのメモリリークが原因だったんでしょうか。
再起動後の結果：
C:\Users\YourUser>tracert myservice.example.com
myservice.example.com [203.0.113.10] へのルートをトレースしています
経由するホップ数は最大 30 です:
1 1 ms <1 ms <1 ms 192.168.1.1
2 10 ms 10 ms 10 ms 100.64.1.1
3 15 ms 14 ms 15 ms 203.0.113.1
4 50 ms 48 ms 49 ms 153.149.204.94
5 60 ms 58 ms 60 ms 153.149.204.89
6 70 ms 68 ms 70 ms 52.93.7.1
7 80 ms 78 ms 80 ms 52.93.7.2
8 90 ms 88 ms 90 ms 52.93.126.34
9 100 ms 98 ms 100 ms 52.93.132.45
10 110 ms 108 ms 110 ms 54.239.111.10
11 120 ms 118 ms 120 ms 54.239.106.31
12 130 ms 128 ms 130 ms 203.0.113.10
トレースを完了しました。
ルーター側が解消されると、そのあとのトラフィック、ホップ6以降も速くなるんですね。これがボトルネックてやつなんでしょうか。
クレームとしてのエビデンス
他にも対応方法はあると思うけどトレースルートの結果は、とにかくクレーム対応の即席エビデンスとして私にも気軽にできて有効だと思いました。