はじめに
Webサービスにておたくのサイトが重いとかレスポンスが遅いとのクレームがあったことがよくありました。でもだいたい社内の検証では遅くないし、、どうエビデンスを渡せばクライアントが納得してくれるか。ということでトレースルートを使ってみることにしました。
問題の特定
まず、リモートなりでアクセスしクライアントの環境でサービスのエンドポイントに対してトレースルートを実行。
Windowsの場合:
tracert myservice.example.com //あなたの製品のURL
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アドレスですね。私の環境ではほぼ1msに対して、ここでは 150 ms、160 ms、170 msと既に明らか遅延が発生していることから、問題が社内ネットワーク内にあると判断ができます。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以降も速くなるんですね。これがボトルネックてやつなんでしょうか。
クレームとしてのエビデンス
他にも対応方法はあると思うけどトレースルートの結果は、とにかくクレーム対応の即席エビデンスとして私にも気軽にできて有効だと思いました。