その「netstat」で消耗していませんか？大規模環境でこそ輝く「ss」コマンドの底力
深夜3時、データセンターで障害対応をしていると、ふとした瞬間に自分の「古臭い習慣」がボトルネックになっていることに気づかされます。
サーバーの接続数が急増し、Web APIのレスポンスが悲鳴を上げている状況。あなたは焦って netstat -an を叩きますよね。でも、その瞬間、ターミナルがフリーズしたような状態になり、数秒間（あるいは数十秒間）の空白が生まれる……。その間にパケットはドロップし、SLIは崩壊する。
そんな経験があるなら、今日で netstat とは決別しましょう。今回は、現代のLinuxインフラエンジニアが必須で使いこなすべき ss コマンドの世界について、現場の知見を交えて語ります。
—
なぜ netstat は「重い」のか？
netstat がなぜ大量接続環境で遅いのか。それは、このコマンドが /proc/net/ 配下のテキストファイルを読み込んで解析するという、非常に泥臭い処理を行っているからです。
接続数が数千、数万と増えると、カーネル内のソケット情報をいちいちテキスト形式に変換してユーザー空間に渡すコストが無視できなくなります。これは、現代の超高速なネットワーク環境においては致命的なオーバーヘッドです。
一方、ss（Socket Statistics）は違います。ss はカーネルの netlink インターフェースを直接叩きます。カーネルが管理しているソケット情報に直接アクセスし、バイナリデータとして高速に情報を引き抜く。この設計思想の違いが、数千接続規模の環境で天と地ほどの差を生むのです。
—
ss コマンドの基本と「実務的な」パラメーター
現場でまず覚えておくべきは、この組み合わせです。
# 接続状態（ESTAB）をフィルタし、プロセスIDも表示する
ss -ntp state established-n: 名前解決をしない（これ重要です。障害時にDNSの応答待ちで止まるのは最悪です）-t: TCPソケットのみを表示-p: ソケットを使用しているプロセスを表示state established: 確立済みの接続のみに絞り込む
もし、APIサーバーで大量の TIME_WAIT が発生してポート枯渇を起こしているなら、以下のようにして原因を特定します。
# TIME_WAIT 状態のソケットを数えてみる
ss -ant state time-wait | wc -l接続元IP別の統計を秒速で出す
障害時、「どのクライアントから異常な接続が来ているか？」を特定する際、ss と awk を組み合わせれば、一瞬で切り分けが完了します。
# 接続元IPアドレスごとの接続数をカウントし、多い順にソートする
ss -ntu | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -nr | head -n 10このコマンドは、netstat でやろうとするとCPUを食いすぎてサーバーの負荷をさらに上げてしまう可能性がありますが、ss なら驚くほど軽快に動作します。
—
実践：Python でソケット状態を監視する際の視点
API設計者として知っておいてほしいのは、OS側のソケット状態をプログラムからどう捉えるか、という点です。例えば、PythonでクライアントからAPIを叩く際、接続プールを適切に管理しないと TIME_WAIT が爆発します。
import requests
from requests.adapters import HTTPAdapter
# 接続プールを再利用することで、TIME_WAITの発生を抑制する
session = requests.Session()
adapter = HTTPAdapter(pool_connections=100, pool_maxsize=100)
session.mount('https://', adapter)
# これを意識しないと、ssコマンドで確認した際に
# 無数のTIME_WAITソケットが放置されることになる
response = session.get('https://api.example.com/v1/data')もし、インフラ担当から「あなたのAPI、TIME_WAIT が多すぎてカーネルのパラメータ net.ipv4.tcp_tw_reuse をいじらなきゃいけないんだよ」なんて言われたら、それは設計を見直すサインです。まずは ss -ant で実際の接続状況を可視化することから始めましょう。
—
シニアエンジニアからの最後のアドバイス
障害現場における鉄則は、「システムに負荷をかけずに情報を収集すること」です。
netstat は歴史あるコマンドですが、現代のLinux環境においては「過去の遺産」となりつつあります。トラブルシューティングの最中に netstat を叩いてサーバーが重くなるような事態は、プロとして避けなければなりません。
まずは、今日から netstat のエイリアスを ss に書き換えてみてください。数週間もすれば、その軽快さに手放せなくなるはずです。
ネットワークのトラブルは、往々にして「見えないもの」を「見える化」した瞬間に解決の糸口が見つかります。ss コマンドという強力な武器を手に、現場の荒波を乗り越えていきましょう。何かあればいつでも質問してください。現場からは以上です。
コメント