65,535の呪縛：パブリッククラウドのNAPTポート枯渇と、限界を超えるためのアーキテクチャ設計
クラウドネイティブなシステムを運用していて、ある日突然、外向きのAPI通信がパタッと途絶えたことはないだろうか。アプリケーションのログを覗くと、無数の Connection timed out や Cannot assign requested address が踊っている。
原因を辿っていくと、決まって犯人は同じ場所にたどり着く。NATゲートウェイ、あるいはKubernetesワーカーノードのSNAT（Source NAT）テーブルだ。
IPパケットがインターネットの荒野へ飛び出すとき、プライベートIPアドレスはパブリックIPへと書き換えられる。その背後で、TCP/UDPのポート番号を多重化するNAPT（Network Address Port Translation）のメカニズムこそが、現代のクラウドインフラストラクチャを支える隠れた主役であり、同時にシステムを突如として沈黙させる最大の爆弾となり得る。
今回は、この「65,535」という数学的制約が生み出すポート枯渇問題に、Linuxカーネルの内部挙動、TCP/IPのトランスポート層、そしてクラウドのネットワークアーキテクチャの観点から徹底的にメスを入れていこう。
—
1. パケットレベルで紐解くNAPTの現実と「エフェメラルポート」の数学的限界
まず、前提としてTCP/UDPのヘッダー構造を思い出してほしい。送信元ポート（Source Port）と宛先ポート（Destination Port）は、それぞれ16ビットの領域に格納される。 $2^{16} = 65,536$。これが、単一のIPアドレス上で同時に識別できるポートの理論上の最大数だ。
だが、NAPTの現場では、利用可能なポート数はさらに制限される。
4タプルによる一意性の担保
NAPTデバイス（AWSのNAT GatewayやGCPのCloud NATなど）がパケットを変換する際、以下の「4タプル」をトラッキングテーブルに保持する。
1. 送信元IPアドレス（プライベート）
2. 送信元ポート（プライベート）
3. 宛先IPアドレス（パブリック）
4. 宛先ポート（パブリック）
外向きの通信において、宛先IPと宛先ポートが異なる数千の外部APIエンドポイントへ同時にアクセスする場合、単一のパブリックIPアドレスだけでも、理論上は多数の接続をさばけるように思える。しかし、問題は「同一の宛先（IP:Port）」に対して大量のコネクションを張るマイクロサービスの挙動にある。
例えば、バックエンドのコンテナ群が一つの巨大な外部決済APIやデータベースへ数千・数万のリクエストを同時に送出する場合、NAPTデバイスは「送信元パブリックIP + 割り当てられたエフェメラルポート」の組み合わせで一意性を保たなければならない。
Linuxカーネルにおけるローカルポート範囲の制約
Linuxカーネルで外向きのTCPコネクションを確立する際、システムが自動割り当てするエフェメラルポートの範囲は、デフォルトで /proc/sys/net/ipv4/ip_local_port_range によって制御されている。
# 現在のエフェメラルポート範囲を確認する
cat /proc/sys/net/ipv4/ip_local_port_range
# 出力例: 32768 60999 (利用可能なポート数は約28,000程度)この範囲は最大でも 65535 まで拡張できるが、システム予約ポートとの競合を避けるため、通常は 1024 から 65535 の間、あるいは上記のように一部が切り取られた範囲で運用される。単一のNAT IPあたりの利用可能ポート数がこの範囲に縛られているという事実が、スケール時のボトルネックとなる。
—
2. 枯渇の引き金：TIME_WAITの呪縛とコネクションプーリングの欠如
ポートが枯渇するメカニズムの多くは、TCPの終了シーケンス（四方向ハンドシェイク）に起因する。
アプリケーション層でHTTPリクエストが完了し、コネクションが閉じられた後、TCPセッションは即座に消滅するわけではない。パケットロスによる遅延パケットの迷子を防ぐため、 initiator 側（通常はクライアント側）のカーネルはコネクションを TIME_WAIT 状態に維持する。
TIME_WAIT のデフォルト持続時間と枯渇スパイラル
Linuxでは、 TIME_WAIT の期間は TCP_TIMEWAIT_LEN としてカーネル内にハードコード（通常60秒）されているか、あるいはプロトコル仕様通り 2 * MSL（Maximum Segment Lifetime = 60秒）として固定されている。
もし、あるアプリケーションが毎秒 1,000 件の短いライフサイクルの外向きリクエストを生成しているとする。
$$\text{必要ポート数} = \text{秒間リクエスト数} \times \text{TIME_WAIT秒数} = 1000 \times 60 = 60,000$$
お気づきだろうか。わずか数秒の間に、単一のNAT IPが持つエフェメラルポートのプールは TIME_WAIT のソケットで完全に埋め尽くされる。新しいコネクションを張ろうとしたカーネルは Cannot assign requested address を吐き出し、システムは沈黙する。
—
3. 現場で即効性を持つ！カーネルパラメータチューニングとコード最適化
この地獄から抜け出すためには、インフラとコードの両面からアプローチする必要がある。まずはLinuxカーネルのトランスポート層における設定を見直そう。
1. tcp_tw_reuse の有効化
TIME_WAIT 状態のソケットを、安全な条件下で新しい外向きコネクションに再利用することを許可する。
# /etc/sysctl.conf または専用のconfファイルに記述
net.ipv4.tcp_tw_reuse = 1*※注意: tcp_tw_recycle はNAT環境下で致命的なパケット破棄を引き起こすため、現代のLinuxカーネル（4.1以降など）では完全に廃止されている。必ず tcp_tw_reuse を用いること。*
2. エフェメラルポート範囲の最大化
システムが利用できるポートのパイプを物理的に太くする。
# 利用可能なポート範囲を可能な限り広げる
net.ipv4.ip_local_port_range = 1024 655353. アプリケーション層でのHTTP Keep-Aliveとコネクションプーリングの徹底
どんなにカーネルをチューニングしても、毎度TCPの3ウェイハンドシェイクを行い、短命なコネクションを量産する設計（Anti-pattern）を直さない限り、根本的な解決にはならない。
Pythonの requests ライブラリや Node.js の http.agent、Goの http.Client において、HTTP Keep-Alive（コネクションの持続的再利用）を必ず有効化すること。
以下は、Go言語において外向きHTTPクライアントのトランスポート層を適切にチューニングし、コネクションプールを枯渇させないための実装例だ。
package main
import (
"fmt"
"net"
"net/http"
"time"
)
func createOptimizedClient() *http.Client {
// トランスポート層の詳細なパラメーターを設定
t := &http.Transport{
Proxy: http.ProxyFromEnvironment,
DialContext: (&net.Dialer{
Timeout: 30 * time.Second,
KeepAlive: 30 * time.Second,
}).DialContext,
ForceAttemptHTTP2: true,
MaxIdleConns: 1000, // 全体での最大アイドルコネクション数
MaxIdleConnsPerHost: 100, // 同一ホストあたりの最大アイドルコネクション数
IdleConnTimeout: 90 * time.Second,
TLSHandshakeTimeout: 10 * time.Second,
ExpectContinueTimeout: 1 * time.Second,
}
return &http.Client{
Transport: t,
Timeout: 10 * time.Second,
}
}
func main() {
client := createOptimizedClient()
// このクライアント経由でリクエストを行うことで、コネクションがプールされ、
// 毎回のTCPハンドシェイクおよびTIME_WAITの生成を防ぐ。
fmt.Println("Optimized HTTP Client is ready to prevent port exhaustion.")
}—
4. クラウドネイティブ時代の根本解：アーキテクチャのスケールアウト
単一のNAT Gatewayや、単一のパブリックIPに依存する設計自体が、大規模システムにおいてはシングルポイント・オブ・フェイルFailure（SPOF）ならぬ「スケール・ボトルネック」となる。
メガクラウド（AWS、GCP、Azure）におけるモダンな処方箋を見ていこう。
AWS VPC NAT Gatewayの場合
AWSでは、単一のNAT Gatewayに依存するのではなく、マルチAZ（アベイラビリティゾーン）ごとにNAT Gatewayを配置し、プライベートサブネットのルートテーブルをAZごとに分割する。
これにより、利用可能なパブリックIPアドレスのプールはNAT Gatewayの台数分（例えば3AZなら3倍）にスケールアウトする。
さらに、AWSは「NAT GatewayのパブリックIPの動的追加（Elastic IPの複数割り当て）」にも対応しつつあるが、より確実なのは、同一VPC内での通信やAWSサービスへのアクセスにはVPCエンドポイント（Interface Endpoint / Gateway Endpoint）を積極的に利用することだ。
S3やDynamoDB、あるいはAWS内部のAPIへの通信をVPCエンドポイント経由（AWSバックボーン内）に逃がすことで、NAT Gatewayを通る外向きパケットの量を劇的に削減できる。
Kubernetes（EKS / GKE）における SNAT の最適化
Kubernetesクラスターにおいて、ポッドからの外向き通信がノードのIP（またはノードに割り当てられたENIのIP）に変換される際、デフォルトの iptables ベースのMasquerade処理は、トラフィック量が増えると大きなCPUオーバーヘッドとポート枯渇リスクを生む。
現代のプロダクション環境では、以下の手法への移行が推奨される。
- AWS VPC CNIのプレフィックス委任（Prefix Delegation）: ノードあたりのプライベートIPアドレス数を動的に増やし、ポッドごとに独立したIPを持たせることで、SNATの依存度を下げる。
- Egress Gatewayの導入: Istioなどのサービスメッシュを活用し、特定の外部宛てトラフィックを指定のエグレスプロキシポッド群経由に集約・制御する。
—
5. おわりに：目に見えないパケットの流れに思いを馳せて
65,535という数字は、プロトコルの歴史が生んだ美しくも残酷な境界線だ。
クラウドの画面上で「NAT Gateway」というボタンを一つポチるだけで、インフラの構築は完了したように見える。しかし、その背後では、数百万のリクエストが16ビットのポート空間を奪い合い、Linuxカーネルが必死に TIME_WAIT をさばき、トランスポート層のステートマシンが火を吹いている。
優れたSREやインフラアーキテクトとは、コードや画面の向こう側で繰り広げられる、このパケットたちのドラマを生々しく想像できる人間のことだ。
ポート枯渇という目に見えない泥沼に足を取られる前に、コネクションプーリングの血を通わせ、カーネルのパラメーターを極限まで研ぎ澄まし、そしてクラウドのスケールアウト原則に従った美しいネットワークトポロジを築き上げよう。あなたのシステムが、どれほどトラフィックが急増しようとも決して揺るがぬ、強靭な心臓を手に入れるために。
コメント