ネットワーク障害の「犯人」を特定せよ：MTRで見るパケットロスの真実
ネットワークエンジニアにとって、最も精神を削られる瞬間。それは「なんとなく遅い」「時々繋がらない」という、再現性の低いクレームが上がった時です。
pingを打っても、たまにロストする程度。tracerouteを打っても、その瞬間は正常。そんな「間の悪い」トラブルを解決するために、我々NOCの現場で必携の武器となっているのが mtr （My Traceroute）です。
今日は、教科書的な説明はすっ飛ばして、なぜ mtr が障害対応の現場で「神ツール」と崇められるのか、その真髄を掘り下げていきましょう。
—
1. なぜ ping や traceroute だけでは足りないのか
まず、ping（ICMP Echo）は「点」の観測です。特定の瞬間の疎通を確認するだけで、経路のどこで何が起きているかは分かりません。一方、traceroute は「線」の観測ですが、これはあくまで「パケットが通った経路の記録」に過ぎません。
ネットワーク障害の多くは、特定のルーターでのバッファ溢れや、特定のリンクでの一時的な負荷増大によって発生します。つまり、「継続的に」「経路上の各ノードで」何が起きているかを統計的に可視化しなければ、真の原因には辿り着けないのです。
mtr は、これを絶妙なバランスで実現しています。ICMPパケットを一定間隔で送り続け、経路上の全ホップのロス率（Loss%）とラウンドトリップタイム（RTT）をリアルタイムで再計算し続ける。これにより、通信が揺らいだ瞬間に「どのホップでパケットが消えたか」を即座に突き止められるのです。
—
2. 現場で役立つ mtr の読み方とパラメータ
まずは、実務で最もよく使うコマンド構成を叩き込んでおきましょう。
# -r: レポートモード（画面更新ではなく結果を出力）
# -c 100: 100回試行してから終了
# -n: DNS逆引きをしない（DNS解決待ちで余計な遅延を出さないため）
mtr -r -c 100 -n 8.8.8.8押さえておくべき指標
Loss%: 各ホップでのパケットロス率。ここが急に跳ね上がったら、その直後のリンクやルーターで輻輳が起きています。Last: 直近の応答時間。Avg: 平均応答時間。Best/Worst: ネットワークのジッタ（揺らぎ）を見るのに使います。ここがあまりに乖離している場合、回線の品質が不安定な証拠です。
—
3. Web API開発者のための「通信品質」診断
Web APIのレスポンスが悪いとき、バックエンドのコードを疑う前に、ネットワークのボトルネックを排除する必要があります。Pythonで mtr 的な統計情報を取得し、ログとして残す簡易的なスクリプトのアイデアを置いておきます。
import subprocess
import json
def check_network_quality(target_host):
# mtrの結果をJSON形式で取得するコマンド
# --json オプションはモダンな環境で非常に便利です
cmd = ["mtr", "-r", "-c", "50", "-j", target_host]
try:
result = subprocess.run(cmd, capture_output=True, text=True)
data = json.loads(result.stdout)
# ロス率が1%を超えていたらアラートを出すなどのロジックをここに
for hop in data['report']['hubs']:
if hop.get('loss', 0) > 1:
print(f"Warning: Hop {hop['host']} detected packet loss: {hop['loss']}%")
except Exception as e:
print(f"診断失敗: {e}")
# APIエンドポイントのヘルスチェックとして活用
check_network_quality("api.example.com")—
4. シニアエンジニアからの教訓：落とし穴を避ける
mtr を使う際に、一つだけ注意点があります。それは「中間ルーターの優先度」です。
多くのルーターは、制御用パケット（ICMP）の処理を優先度を下げて行います。そのため、特定のホップで高いロスや遅延が出ていても、それが「その先のリンクが悪い」のか「そのルーターが自分宛てのICMPを後回しにしているだけ」なのかを見極める必要があります。
- 検証のコツ:
mtrで特定のホップにロスが出た際、その直後のホップが正常であれば、それは「そのルーターの負荷による偽装」である可能性が高いです。逆に、そのホップ以降すべてのルーターでロス率が同じように高くなっている場合は、間違いなくそのホップでの回線に問題があります。
—
最後に：ツールはあくまで「地図」である
mtr は、ネットワークという見えない迷宮を歩くための「地図」です。しかし、地図が正確でも、現場の配線やSFPモジュールの劣化、ISP側のバックボーン障害という「物理的な現実」までは直せません。
トラブルシューティングで最も大切なのは、mtr で得られたデータを見て「なぜこうなっているのか？」と仮説を立て、それを別の手段（例えば curl でのHTTPレイヤーの応答確認や、tcpdump によるパケットキャプチャ）で裏付けていく執念です。
皆さんのネットワークが常に安定していることを祈っています。もし何かが止まったら、まずは mtr を叩いて、冷静にパケットの行方を見守ってください。それが、プロのエンジニアの第一歩です。
コメント