【入門編】 Cloud NATのポート枯渇問題(Port Exhaustion)とその検知・対策 – クラウドインフラと仮想化ネットワーク実践ガイド

なぜ「ネットが繋がらない」？Cloud NATのポート枯渇問題を郵便局に例えて解説します

こんにちは！クラウドのインフラを日々いじり倒しているSREです。

皆さんは、GCP（Google Cloud）で構築したシステムで、急に「特定の外部サイトと通信できなくなった」「APIリクエストがタイムアウトするようになった」という経験はありませんか？

エラーログを見ると特に異常はない。でも通信だけが通らない…。そんな時、真っ先に疑うべき犯人が「Cloud NATのポート枯渇（Port Exhaustion）」です。

今回は、この「見えない渋滞」を、郵便局の仕組みに例えて紐解いていきましょう。

—

そもそも「Cloud NAT」って何をしてるの？

まず、Cloud NATの役割を簡単に整理しましょう。

例えば、プライベートIPアドレスしか持たないサーバー（インターネットに出られない子たち）が、どうしても外部のAPIを叩きたいとします。その時に「僕の代わりに郵便を出してきて！」とお願いするのがCloud NATです。

Cloud NATは、裏方として「サーバーからのお手紙（パケット）」の差出人住所を、自身の持っているグローバルIPアドレスに書き換えてインターネットへ送ります。そして、戻ってきた返信を正しいサーバーに届けてくれる、「凄腕の郵便局員さん」なのです。

—

「ポート枯渇」はなぜ起こる？

ここで問題になるのが、「一度に扱える手紙の数には限界がある」という現実です。

GCPのCloud NATには、1つの外部IPアドレスにつき最大で「64,000」のポート（郵便窓口のようなもの）という上限があります。

郵便局の窓口に例えると…

サーバーからのリクエスト＝「発送したい荷物」
外部IPアドレス＝「郵便局の建物」
ポート番号＝「荷物の整理窓口」

サーバーが同時に数千、数万ものリクエストを外部へ投げまくると、この窓口がすべて埋まってしまいます。新しい荷物が届いても、窓口が空いていないので、「今は無理！荷物が受け取れない！」となってしまう。これが「ポート枯渇」の正体です。

特に、Webスクレイピングや、マイクロサービス間で頻繁に外部APIを叩く構成だと、この上限に到達するのはあっという間です。

—

どうやって検知するの？

「あ、これポート枯渇かも？」と勘に頼る必要はありません。GCPには便利な監視機能が備わっています。

Cloud Monitoring（旧Stackdriver）で、以下の指標をチェックしてみてください。

nat/allocated_ports: 現在いくつのポートが使われているか
nat/dropped_packets_count: ポート不足で捨てられたパケットの数

もし dropped_packets_count が右肩上がりなら、即座に対策が必要です！

—

対策：窓口を増やそう（スケールアウト）

対策はシンプルです。「窓口が足りないなら、郵便局の建物（外部IPアドレス）を増やせばいいじゃない！」という考え方です。

Cloud NATの設定で、外部IPを複数設定することで、ポートの総数を増やすことができます。

gcloudコマンドでの設定例

以下のコマンドで、既存のCloud NATに対して外部IPアドレスを簡単に追加できます。

# 既存のNATゲートウェイに新しいIPアドレスを追加する設定例
gcloud compute routers nats update [NAT名] \
    --router=[ルーター名] \
    --region=[リージョン名] \
    --nat-external-ip-pool=[IPアドレス1],[IPアドレス2] # IPをカンマ区切りで複数指定！

これで、利用できる窓口が「64,000 × 2 = 128,000」に倍増します。物理的な限界が広がるので、渋滞は一気に解消されるはずです。

—

本質的な解決のために

IPアドレスを増やすのは対症療法として非常に優秀ですが、根本的な解決には「手紙の出し方を工夫する」ことも大切です。

1. コネクションプーリング: 毎回新しい接続を作るのではなく、一度作った接続を使い回す設定（Keep-Aliveなど）を入れる。
2. 不要な接続の抑制: 監視ツールやログ送信の頻度を見直す。

これらを行うことで、ポートの消費速度を緩やかにすることができます。

—

まとめ

Cloud NATは郵便局の窓口！
ポート枯渇は、窓口が満員で荷物が受け取れない状態。
監視指標を見て、限界に達しそうなら外部IPを追加して窓口を増やそう！

インフラは「繋がって当たり前」の世界ですが、その裏では今回のようなパケットの奔走と、クラウド特有の制約がせめぎ合っています。仕組みを理解すれば、もう「原因不明のエラー」に怯えることはありません。

皆さんのシステムが、今日も元気に通信できていることを願っています。それでは、次回の記事もお楽しみに！