さらば netstat。現場を救う ss コマンドの流儀
深夜のデータセンター、あるいは本番環境で発生した「接続断」のアラート。モニター越しに冷や汗を流しながら、サーバーにSSHで飛び込み、とりあえず netstat -an を叩く。……待てど暮らせど結果が返ってこない。そんな経験、一度や二度はあるだろう？
大規模なWeb APIサーバーや高負荷なロードバランサーにおいて、数万の接続を抱えた状態で netstat を使うのは、ハッキリ言って「自爆」だ。あいつは /proc/net/tcp を愚直にパースする仕様上、コネクション数に比例して処理が重くなる。現場で一番欲しい瞬間に、あいつは役に立たない。
そこで今日から君たちの武器にしてほしいのが ss コマンドだ。なぜ ss なのか。そして、どう使いこなすべきなのか。シニアの視点から解説しよう。
なぜ ss は高速なのか：Netlinkの魔法
ss コマンドが netstat と決定的に違うのは、カーネルの情報を取得するアプローチだ。ss は netlink ソケットを介してカーネルの TCP/UDP スタックに直接問い合わせを行う。
netstat が /proc 以下のファイルを舐め回してテキスト処理をするのに対し、ss はカーネルが管理するデータ構造をバイナリレベルで直に叩きに行く。この違いが、数千、数万のコネクションを抱えた時の「レスポンスの速さ」に直結する。障害時の1秒は永遠だ。ss を使うことは、エンジニアとしての生存戦略そのものだと言える。
実践：現場で多用する ss のコマンドライン
まずは、日常の運用で叩くべき「鉄板コマンド」を体に覚え込ませてほしい。
1. 接続状態の全容を掴む
まずは全体の様子を見る。-t はTCP、-u はUDP、-l はリスニング中、-a は全接続を表示する。
# 全てのTCP/UDPのリスニングポートと接続中コネクションを表示
# -n で名前解決を抑制（これ重要。障害時にDNSを引かせるとさらに遅くなる）
ss -tulan2. 特定のポートを監視する
APIサーバーで 8080 ポートの詰まりを確認したい場合、grep で絞り込むよりも ss のフィルタ機能を使う方が遥かに効率的だ。
# 8080番ポートで待ち受けている、もしくは接続中のコネクションを抽出
ss -nt "( dst :8080 or src :8080 )"3. 【重要】タイムアウトした接続を特定する
接続断の調査で最も厄介なのが、中途半端に残り続ける CLOSE_WAIT や TIME_WAIT だ。
# TIME-WAIT状態のコネクションを抽出し、数を確認する
# 接続数が多い場合は、カーネルパラメータの tcp_tw_reuse 等の検討が必要になる
ss -nt state time-wait | wc -lPythonでソケット状態を監視する（インフラ自動化のヒント）
最近のインフラ運用では、CLIを叩くだけでなく、監視スクリプトに数値を食わせることが多い。ss の出力をパースするのも良いが、Pythonから直接Netlinkを扱うライブラリ（pyroute2 など）を使うか、シンプルに subprocess で ss を呼び出して分析するのが現実解だ。
import subprocess
def get_connection_count(port):
"""
指定ポートの接続数を取得する簡易関数
"""
cmd = f"ss -nt src : {port} | wc -l"
try:
# shell=Trueは慎重に。入力値に外部変数が含まれる場合は必ずエスケープすること
result = subprocess.check_output(cmd, shell=True)
return int(result.strip())
except subprocess.CalledProcessError:
return 0
# 現場での運用例：8080番ポートのコネクション数が閾値を超えたらログを出す
current_conn = get_connection_count(8080)
if current_conn > 1000:
print(f"Warning: Connection spike detected! Current: {current_conn}")トラブルシューティングの勘所：パケットは嘘をつかない
ss でソケット状態を確認した際、以下の状態を見つけたら注意が必要だ。
SYN-RECVが多い: SYN flood攻撃を受けているか、バックエンドの処理が飽和してバックログが溢れている。CLOSE_WAITが増え続ける: アプリケーション側でソケットのクローズ処理が漏れている（メモリリークの兆候）。FIN-WAIT-1が多い: 相手先ホストとのネットワーク経路でパケットロスが発生している可能性がある。
ss は単なる「一覧表示ツール」ではない。カーネルと対話するための「聴診器」だ。
最後に：ツールを使いこなすということ
コマンドを覚えることは、単なる暗記ではない。その裏で何が起きているのかという「仕組み」を理解することだ。netstat から ss への移行は、エンジニアとして「より本質的で効率的な手段へシフトする」という姿勢の表明でもある。
障害が起きたとき、パニックにならず、静かに ss -nt を叩く。そんな余裕を持つ君たちに、データセンターの神は微笑むはずだ。さあ、次はどんな現場が待っているかな？ 安全で、安定したネットワークライフを。
コメント