現場の視点：netstatを捨て、ssでカーネルの深淵を覗く理由
インフラエンジニアの端くれとして数千台のサーバーと対峙してきた中で、最も「現場の勘」を鈍らせるのが、古いツールへの依存だ。特に netstat は、もはやレガシーな遺物と言っていい。Procファイルシステム（/proc/net/tcp）を舐めるだけの旧来ツールに対し、ss（Socket Statistics）はカーネル内部のNetlinkソケットと直接対話し、生の状態を抽出する。
現代の極限環境では、数万のコネクションがひしめき合い、TCPのハンドシェイク一つがミリ秒単位のRTO（再送タイムアウト）を競っている。そんな戦場で、我々はどのようにして「見えない詰まり」を可視化すべきか。今日は ss コマンドのフィルタリング能力を駆使した、プロの診断術を共有しよう。
1. フィルタリングの妙：不要なノイズを遮断し「真のボトルネック」を突く
大規模トラフィックが発生している最中に、単に ss -ant を叩くのは自殺行為だ。数万行の出力の中から、確立済み（ESTAB）の特定のセッションを見つけ出すのは至難の業。ここでフィルタ機能を活用する。
例えば、Webサーバーにおいて、TLSハンドシェイクの遅延や、アプリケーション層のバックログ詰まりを疑う場合、以下のように絞り込む。
# 80/443ポートで、かつ接続が確立しているものだけを抽出
# -n: 名前解決をしない（DNSのオーバーヘッドを避ける）
# -t: TCPソケットのみ
# -a: すべての状態を表示（フィルタなしだとLISTENが除外されるため）
ss -nt state established '( dport = :80 or dport = :443 )'ここで重要なのは、Recv-Q と Send-Q の値だ。Recv-Q がゼロ以外で停滞している場合、それはアプリケーションがカーネルのTCPバッファからデータを吸い上げられていないことを意味する。これは、スレッドの枯渇や、排他制御によるデッドロックの典型的な兆候だ。
2. メモリ使用量とTCPバッファ：極限のチューニング
高負荷な配信環境や、TLS終端を担うインフラにおいて、TCPバッファのサイズはスループットを左右する生命線だ。ss -m を使うと、各ソケットがどれだけのカーネルメモリを消費しているかが一目瞭然となる。
# -m: ソケットのメモリ使用状況を表示
# 指定したポートのバッファ状況を詳細に確認
ss -ntm '( sport = :443 )'出力結果に含まれる skmem の値に注目してほしい。
rmem_alloc: 受信バッファの割り当て量wmem_alloc: 送信バッファの割り当て量
もし wmem_alloc が常に上限に達しているなら、それはクライアント側のネットワークが細いか、あるいはTCPウィンドウサイズが適切にスケーリングされていない証拠だ。sysctl で net.ipv4.tcp_wmem を調整する前に、まずはこの ss の値で、実際にどの程度メモリが「積まれているか」を観察する癖をつけるべきだ。
3. TLSハンドシェイクの最適化とパケット挙動
TLS 1.3が普及した現在、RTT（往復遅延）は極限まで削減されているが、それでもTCPの SYN パケットがドロップする瞬間がある。これは往々にして、コンテナ環境でのNATの枯渇や、ファイアウォールのセッションテーブル溢れが原因だ。
ss のフィルタリングで、SYN-SENT や SYN-RECV を定期的に監視することは、セキュリティインシデント（DDoS攻撃）の早期検知にも繋がる。
# 接続試行中のソケットを定点観測するワンライナー
# 1秒ごとに更新し、SYN待ちの数を確認
watch -n 1 "ss -nt state syn-sent | wc -l"この数値が急激に跳ね上がる場合、バックエンドのデータベースやマイクロサービス間通信で、コネクションプールの枯渇が起きている可能性が高い。
4. プロの隠し味：Netlinkによる効率的な監視
最後に、我々のような運用エンジニアが最も避けるべきは「ツールによる監視負荷が、監視対象の負荷を押し上げる」という本末転倒な状況だ。ss は Netlink を利用しているため、netstat よりも遥かに低コストで情報を取得できる。
さらに深く踏み込むなら、ss の -o オプション（タイマー情報）を併用してほしい。再送タイマー（on-rec）が動いているセッションを特定できれば、どの通信経路でパケットロスが発生しているかが、推測ではなく「事実」として浮かび上がる。
実践的なトラブルシューティングの思考プロセス
1. 異常の兆候（レイテンシ増大）を検知
2. ss -nt state established でバッファの滞留（Recv-Q）を確認
3. ss -ntm でメモリ割り当ての不自然な挙動を確認
4. ss -o で再送が発生しているソケットを特定し、ルートを切り分ける
教科書には載っていないが、現場で生き残るための鉄則は「カーネルが語る数値に嘘はない」ということだ。コマンドを叩く際、その背後で何が起きているか。パケットがカーネルのバッファを通り抜け、NICへと送出されるその瞬間を脳内でイメージできるか。
ツールはただの道具だ。重要なのは、その道具を通して「ネットワークという生き物」の鼓動を聴き取ることにある。皆さんの環境でも、ぜひ明日から netstat をアンインストールし、ss で深く潜る準備を始めてみてほしい。
コメント