こんにちは！NOC（ネットワークオペレーションセンター）で、日夜数々のデータセンターの荒波を乗り越えてきたシニアエンジニアの私です。
インフラの世界へ足を踏み入れたばかりの頃って、目の前で起きるトラブルの理由がわからず、途方に暮れてしまいますよね。「なぜかウェブサイトが重い」「パケットが消えている気がするのに、どこを調べたらいいかわからない……」。そんな不安を抱えているあなたへ、今日は現場のプロがこっそり使っている「隠れた名医」、ssコマンド（そしてその先輩であるnetstat）を使ったネットワークの健康診断のコツを、優しくお伝えしていきたいと思います。
難しいパケットの構造や、呪文のような英語の仕様書は一旦置いておきましょう。まずは、私たちの身近にある「郵便配達」の仕組みから、ネットワークの裏側を覗いてみませんか？
—
1. 郵便配達で例える「パケットドロップ」の正体
あなたのパソコンに届くデータは、すべて小さな封筒（パケット）に小分けされて運ばれてきます。ネットワークの世界は、巨大な郵便配達システムのようなものです。
通常であれば、郵便局（ネットワークインターフェイスカード／NIC）に届いた手紙は、配達員（OSのドライバ）が素早く受け取り、あなたのポスト（メモリバッファ）へ入れます。しかし、次のような状況が起きたらどうなるでしょうか？
1. あまりにも大量の手紙が一気に届いた（DDoS攻撃や急激なアクセス増）
2. 郵便局の窓口が小さすぎて、処理しきれない（CPUやドライバの処理能力限界）
3. ポストがいっぱい溢れてしまった（メモリ不足）
こうなると、郵便局員は泣く泣く、入り切らなかった手紙を「ポイっ」とゴミ箱に捨てざるを得なくなります。これが、インフラエンジニアが恐れる「パケットドロップ（破棄）」の瞬間です。
私たちがこれから使う ss コマンドは、いわば「郵便局のバックヤードに溜まった『捨てられた手紙の山（エラーカウンター）』をこっそり覗き見るカルテ」のようなものなんです。
—
2. なぜ今 ss コマンドなのか？
昔からのインフラエンジニアは、よく netstat というコマンドを使っていました。もちろん今でも使えますが、現代の超高速なデータセンターやクラウド環境では、情報量が多すぎて netstat だと処理が重くなってしまうことがあります。
そこで登場したのが、よりモダンで爆速な ss（Socket Statistics）コマンドです。Linuxサーバーの健康状態を瞬時に把握するための、私たちの必須アイテムとなっています。
それでは、さっそくサーバーにログインしたつもりで、実際の画面を見ていきましょう！
—
3. 実践！ ss コマンドでパケットの「悲鳴」を聞いてみる
サーバーのターミナルを開いて、まずは以下のコマンドを叩いてみてください。
# ネットワーク統計のサマリー（要約）を表示する
ss -sこのコマンドを実行すると、現在サーバーがどれくらいのソケット（通信の窓口）を使っていて、メモリをどれくらい消費しているのかがパッと一覧で表示されます。
しかし、今回私たちが注目したいのは「どれだけ手紙を落としてしまったか」というエラー情報です。より詳細なインターフェイスごとの統計やエラーを見るためには、お馴染みの ip コマンドや、/proc 経由の情報を合わせ技で見るのが現場の定石ですが、まずは ss とその周辺にある強力な統計情報の見方を押さえましょう。
例えば、パケットのエラーやドロップを深掘りするために、私たちはよく以下のようなコマンドを組み合わせて確認します。
# インターフェイスごとの詳細な送受信エラーやドロップ数を確認する
ip -s linkこの ip -s link を実行すると、画面に以下のようなずらっとした統計情報が表示されます。ここが今日のハイライトです！一歩ずつ、中身を紐解いていきましょう。
3: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
link/ether 52:54:00:12:34:56 brd ff:ff:ff:ff:ff:ff
RX: bytes packets errors dropped overrun mcast
123456789 987654 0 12 0 0 <-- 受信側の統計
TX: bytes packets errors dropped carrier collns
987654321 123456 0 0 0 0 <-- 送信側の統計この出力結果の中にある、いくつかの重要なキーワードについて、先ほどの郵便配達のたとえに戻って解説しますね。
① errors（エラー数）
郵便局に届いた手紙自体が、途中で雨に濡れてふやけていたり、宛先が不鮮明で読めなかったりした「破損品」の数です。物理的なケーブルの不良や、ネットワーク機器（スイッチなど）の故障を疑うサインになります。
② dropped（ドロップ数）
これが今日の主役です！郵便局の窓口やポストがいっぱいで、処理しきれずに「意図的に捨てざるを得なかった」パケットの数です。もしここがグングン増えているなら、サーバーのCPUが悲鳴を上げているか、ネットワークドライバのチューニングが必要なサインです。
③ overrun（オーバーラン数）
郵便局の仕分け台が狭すぎて、次から次へと届く手紙を受け止めきれず、足元にこぼれ落ちてしまった状態です。ハードウェア（NIC）の処理スピードに、OSのドライバが追いついていないときによく発生します。
—
4. 現場でトラブルに直面したときの「生きた」アプローチ
もし、運用しているWebサーバーで「なんだか最近、時々アクセスが途切れる」「APIの応答が妙に遅い瞬間がある」という相談を受けたとしましょう。
そんなとき、ベテランエンジニアは慌ててサーバーを再起動したりはしません。まずは冷静に、以下のようなステップで「数字の推移」を観察します。
1. 現在のエラー数スナップショットを撮る
先ほどの ip -s link を実行し、dropped や errors の数字をメモします（またはスクリーンショットに残します）。
2. 負荷をかけてみる（またはしばらく様子を見る）
あえて少しトラフィックを流すか、数分間放置して再度同じコマンドを実行します。
3. 数字が増えているか確認する
もし、数分の間に RX-dropped の数値がモリモリと増えている場合、それは「今まさに、サーバーが受信するパケットの嵐に耐えきれず、データを捨てまくっている」動かぬ証拠となります。
原因がわかれば、対策が見えてきます。
- メモリやバッファの割り当てを増やすようにカーネルパラメータ（
sysctl）をチューニングする。 - 古いNICのドライバを最新版にアップデートする。
- 単にサーバーのスペック不足であれば、スケールアップを検討する。
勘や思い込みに頼るのではなく、こうした地道な「カウンターの数字」から事実を読み解くことこそが、私たちインフラエンジニアの腕の見せ所なんです。
—
おわりに
いかがでしたでしょうか？ ss や周辺のネットワーク統計コマンドは、最初はただの無機質な数字の羅列に見えたかもしれませんが、そこにはサーバーが発する「助けて！」という小さな声（シグナル）がしっかりと記録されています。
難しい専門用語に気おじする必要はまったくありません。「あ、今この子は手紙を受け取りきれなくて困っているんだな」と、身近な例に置き換えて優しく寄り添ってあげれば、トラブルシューティングはぐっと楽しく、そして得意なものになっていきますよ。
あなたのインフラライフが、エラーの少ない快適なものになりますように。それでは、また次の現場でお会いしましょう！
コメント