こんにちは！大規模なデータセンターのNOC（ネットワークオペレーションセンター）で、日々トラブルの荒波にもまれているシニアエンジニアです。
ネットワークの向こう側で何が起きているのか、パケットたちが今どこを走っていて、なぜ途中で迷子になっているのか――それをリアルタイムで暴き出す「MTR（My Traceroute）」という最高の相棒について、今回は熱く語らせてください。
インフラの世界に飛び込んだばかりの皆さん、「なんだか最近、特定のサーバーへのアクセスが重いな」「時々接続がプツッと切れるな」という怪奇現象に直面したことはありませんか？
そんな時、とりあえずpingを打って「あぁ、ロスしてるな」と絶望したり、tracerouteを叩いて「どこで時間がかかってるんだ？」と画面を睨みつけたりしていませんか？
実は、その2つの強力な機能を一つに合体させ、さらに継続的に監視してくれる魔法のようなツールがMTRなんです。
「なんだか難しそう……」なんて身構える必要は全くありませんよ。身近な郵便配達の仕組みに例えながら、一歩ずつ優しく紐解いていきましょう！
—
1. パケットの旅を例えてみよう：郵便配達とMTRの世界
皆さんがネットフリックスで映画を見たり、クラウド上のサーバーにデータを保存したりするとき、データは「パケット」という小さな封筒に入れられて、世界中のルーターという中継地点（郵便局やポスト）を経由して届けられます。
従来の「お祈りツール」たちの限界
ping（ピン）くんの仕事：
「宛先のサーバーさん、生きてますかー？」と手紙を送り、返事が返ってくるまでの時間（往復時間）を測るスペシャリストです。目的地までの到着確認には最高ですが、「どの郵便局のせいで遅れているのか」までは教えてくれません。
traceroute（トレースルート）さんの仕事：
「宛先までに、どのルートを通っているか」を調べる探偵です。途中のルーターに「お名前は？（TTLの仕組み）」と聞いて回るので、経路の地図を描くのは得意ですが、その瞬間の一回きりのスナップショットしか見せてくれません。
「今この瞬間は調子が良くても、1分後には激しい渋滞（パケットロス）が起きているかもしれない……！」
そんな現場のエンジニアたちの悲痛な叫びから生まれたのが、MTRなんです。
MTRは、pingの継続的な生存確認と、tracerouteの経路追跡をミックスし、さらに「リアルタイムで何度も往復テストを繰り返して統計を取る」という、まさに欲張りセットのような素晴らしいツールなんですよ。
—
2. MTRの動作原理：なぜ「ロス率」と「遅延」がわかるのか？
MTRが画面上で何をしているのか、少しだけ仕組みを覗いてみましょう。
MTRを起動すると、背景で絶えず小さなパケット（通常はICMPエコーやUDPパケット）が、宛先に向かってパラパラと発射され続けます。
そして、経路上の各ルーター（第1ホップ、第2ホップ……）からの返事を集計し、次のような情報を毎秒アップデートして表示してくれます。
- Loss%（パケットロス率）： 送った手紙のうち、何パーセントが途中で行方不明になったか。
- Snt（送信数）： 今までに何通の手紙を送ったか。
- Last（直近の遅延）： 直近で送った手紙が返ってくるのにかかった時間。
- Avg（平均遅延）： これまでに送った手紙の平均往復時間。
- Best / Wrst（最短 / 最長）： 最も調子が良かったときと、最悪だったときの往復時間。
- StDev（標準偏差）： 遅延のバラつき（ジッタ）。これが大きいと、通信が不安定であることを示します。
「数字がたくさん並んでいて目が回りそう！」という方も大丈夫。実務で見るべきポイントは、実はとてもシンプルなんです。
—
3. 実践！MTRを使ってみよう（インストールと基本コマンド）
百聞は一見にしかず。実際に手元でMTRを動かしてみましょう。
多くのLinux環境（UbuntuやCentOSなど）では、パッケージマネージャーを使って一発でインストールできます。
インストール手順の例
# UbuntuやDebian系の場合
sudo apt update
sudo apt install mtr
# CentOSやRHEL系の場合（epelリポジトリが必要な場合もあります）
sudo yum install mtrインストールができたら、さっそくGoogleのパブリックDNS（ 8.8.8.8 ）宛てにMTRを走らせてみましょう。
# 8.8.8.8に向かってMTRを実行する
sudo mtr 8.8.8.8実行すると、ターミナル画面がパッと切り替わり、まるで生き物のように数字がリアルタイムで更新されていくのが分かります。終了したいときは、キーボードの q を押すだけです。
—
4. 現場のシニアが教える！MTR画面の「ここを見るな」と「ここを見るべき」
いざMTRを動かしたとき、初心者のエンジニアがよくハマる「あるある勘違い」があります。これを覚えておくだけで、無駄なパニックを防げますよ。
勘違いしやすいポイント：途中のルーターでのパケットロス
MTRの結果画面を見ていて、途中のホップ（ルーター番号）で Loss% が 100% や 50% と表示されることがあります。
「うわっ、ルーターが壊れてる！？大障害だ！」と慌てて上司に報告してはいけません。
これは多くの場合、「途中のルーターが、自分宛ての調査用パケットの優先順位を低く設定しており、面倒くさいので返事をサボっている（あるいはレートリミットをかけている）」だけです。
【見極めのコツ】
もし途中のルーターでロスが出ていても、その「直後」のルーターや「最終目的地（宛先）」のLoss%が 0.0% であれば、通信自体は正常に流れています。
本当の障害を見つけるときは、「どこでロスが起き始めたか」ではなく、「最終目的地に届くまでに、どの区間で致命的なロスや遅延の跳ね上がり（ジッタ）が起きたか」を追うのが鉄則です。
—
5. 実務で役立つ便利なパラメーターオプション
MTRはデフォルトのままでも強力ですが、実務のトラブルシューティングではオプションを組み合わせることで真価を発揮します。よく使う実用的な設定をいくつかご紹介しますね。
① DNSの逆引きを無効化してパパッと診断する (-n)
ルーターのIPアドレスをホスト名（ドメイン名）に変換しようとすると、DNSの応答待ちでMTRの画面の更新がモタつくことがあります。緊急時は逆引きをオフにして、IPアドレスだけで軽快に表示させましょう。
# ホスト名の逆引きを行わず、IPアドレスのみで高速表示する
sudo mtr -n 8.8.8.8② 測定回数を指定してレポートとして出力する (-c)
「今のネットワークの状況をログとして残したい」「上報用に30回分の統計を取りたい」というときは、カウント数を指定してレポートモードで実行します。
# パケットをちょうど100回送信したら自動で終了し、テキスト形式で結果を表示する
sudo mtr -c 100 --report 8.8.8.8③ UDPパケットやTCPポートを指定して調べる (--udp / -T)
デフォルトではICMP（またはシステムによってはUDP）が使われますが、ファイアウォールの向こうにある特定のWebサーバー（ポート80や443）が、特定のパケットをブロックしていないか調べたいときに使います。
# TCPのポート443（HTTPS）に対してMTRを実行する
sudo mtr -T -P 443 example.com—
6. おわりに
ネットワークのトラブルシューティングは、時として「見えない敵」との戦いのように感じられるかもしれません。パケットがどこで消えているのか、なぜ遅延しているのか、最初は途方に暮れることもあるでしょう。
しかし、今回ご紹介したMTRを相棒にすれば、パケットたちの足取りが手に取るように見えてきます。「あ、ここで渋滞してるな」「このプロバイダの区間でジッタが大きいぞ」と、客観的なデータに基づいて原因を切り分けられるようになる瞬間は、エンジニアにとって本当にワクワクするものです。
ぜひ、皆さんの手元の環境でも mtr を叩いて、身近なサイトやサーバーまでの旅を覗いてみてくださいね。
それでは、快適なネットワーク運用の旅を！NOCシニアエンジニアの私でした。
コメント