「なぜか通信できない？」その犯人はカーネルかもしれない。診断コマンドと上限値の深淵へ
ネットワークエンジニアの皆さん、こんにちは。現場で叩き上げられたNOCのシニアエンジニアとして、今日は皆さんが一度は直面する「不思議な通信障害」の裏側を解き明かしていこうと思います。
「pingは通るのに、なぜかアプリケーションがタイムアウトする」「tracerouteは正常なのに、特定のサーバーだけ繋がりにくい」。こんな時、皆さんは何を疑いますか？ 多くの初心者はルーターの設定やファイアウォールを疑いますが、ベテランはまず「OSという名の郵便局が、パンクしていないか？」をチェックします。
今日は、私たちの強力な武器である診断コマンドが、なぜOSの制限に引っかかってしまうのか、そしてそれをどう乗り越えるのかをお話しします。
—
1. 郵便局の「窓口」は無限ではない：ファイルディスクリプタの話
ネットワークの通信は、例えるなら「手紙のやり取り」です。PCが誰かに手紙を出すとき、OSは「この手紙を管理する窓口」を一つ確保します。これをLinuxの世界ではファイルディスクリプタ（FD）と呼びます。
診断コマンドやアプリケーションが大量の通信を行おうとすると、この「窓口」が足りなくなります。「窓口が満員です！」とOSに拒否されると、新しい通信は一切受け付けられません。
現場で確認する術
まずは、現在のシステムが一度にどれだけの窓口を開けるか確認してみましょう。
# 現在のシステム全体で許容されている最大ファイルディスクリプタ数を確認
cat /proc/sys/fs/file-maxもし、サーバーが「Too many open files」というエラーを吐いていたら、それは郵便局の窓口が足りないサインです。/etc/security/limits.confを編集して、上限を緩和してあげましょう。
# /etc/security/limits.conf に追記
# すべてのユーザーに対して、開けるファイル数を65535に引き上げる
* soft nofile 65535
* hard nofile 65535—
2. 一時ポート（Ephemeral Port）の限界：待機列の渋滞
次に注目したいのが一時ポートです。皆さんがcurlやブラウザでWebサイトにアクセスする際、OSは「戻ってきた手紙を受け取るための空き部屋（ポート）」を自動的に割り当てます。これが一時ポートです。
この「部屋」の数は有限です。あまりに短い時間で大量の通信（診断コマンドの連続実行や、高負荷なAPIリクエストなど）を行うと、部屋を使い切ってしまい、新しい通信が「空き部屋待ち」でストップしてしまいます。
渋滞を解消するためのチューニング
Linuxのデフォルト設定では、この「使える部屋の範囲」が意外と狭いことがあります。まずは確認してみましょう。
# 現在の一時ポートの割り当て範囲を確認
cat /proc/sys/net/ipv4/ip_local_port_rangeもし結果が 32768 60999 のような控えめな数字なら、広げてあげるのが吉です。
# /etc/sysctl.conf に追記して、一時ポートの範囲を大幅に拡大する
net.ipv4.ip_local_port_range = 1024 65535
# 設定を即座に反映させる
sudo sysctl -pこれで、より多くの通信を同時にさばけるようになります。まるで、郵便局の仕分けスペースを2倍に広げるようなものです。
—
3. なぜ診断コマンドが「嘘」をつくのか
ここで皆さんに一つ、現場の教訓を伝授します。
「pingは通るのに、アプリが死んでいる」という状況は、「ICMP（pingの正体）は空いているが、TCP（アプリの通信）用の部屋が埋まっている」状態であることが多いのです。
pingやtracerouteは、言わば「裏口」や「VIP専用レーン」を使っています。一方、私たちが普段使うアプリケーションは「正面玄関」を使います。正面玄関が満員で動けなくなっている時、VIPレーンだけを見て「異常なし」と判断するのは、非常に危険です。
診断コマンドと併用すべきツール
そんな時は、netstatやssコマンドを使って、今まさに「どの部屋が使われているか」を覗いてみてください。
# 現在のTCPコネクションの状況を一覧表示
# 状態が TIME_WAIT になっているものが多すぎると、ポート枯渇の兆候です
ss -tan | grep TIME_WAIT | wc -lもしTIME_WAITが大量に並んでいるなら、それはサーバーが「過去の通信の残骸」を片付けられずに右往左往している証拠です。この場合は、OSのチューニングだけでなく、アプリケーション側の接続再利用（Keep-Alive）設定を見直す必要があります。
—
最後に：一歩ずつ、着実に
インフラのトラブルシューティングは、パズルのようなものです。今回紹介したカーネルパラメータの調整は、あくまで「OSの器を大きくする」作業です。しかし、この「器」の限界を知っておくだけで、皆さんが遭遇する障害の半分は解決の糸口が見えてきます。
「通信できない」と焦った時こそ、一度深呼吸をして、OSが息切れしていないかを確認してみてください。その冷静さこそが、一流のエンジニアへの第一歩です。
また次回の記事では、この「限界設定」をさらに攻めるための高度なネットワークデバッグ術についてお話ししましょう。現場の最前線でお待ちしています！
コメント