【入門編】 TCP接続終了時におけるNATゲートウェイのTIME_WAITステートとポートの再利用制限 – クラウド＆コンテナネットワーク実践ガイド

こんにちは！第一線のSRE兼クラウドアーキテクトとして、日夜クラウドとコンテナの海を泳ぎ回っている筆者がお届けする技術ブログの時間です。

今回は、皆さんが普段何気なく使っているけれど、実は非常に奥深く、そして時として手強い一面を見せる「NATゲートウェイ」に焦点を当ててみたいと思います。特に、TCP接続の「おしまい」の処理の裏側でひっそりと発生しているTIME_WAITステートが、NATゲートウェイのパフォーマンス、ひいては皆さんのアプリケーションに甚大な影響を与えかねない「ポート枯渇」という問題を引き起こすメカニズムについて、パケットの気持ちになりながら、そして身近な例え話を交えながら、優しく、そして丁寧に紐解いていきましょう。

「小難しいネットワークの話はちょっと…」と身構えている方もご安心ください！一歩ずつ、確実に理解を深めていけるよう、私がしっかりナビゲートしますからね。

—

クラウドの隠れた落とし穴！NATゲートウェイのTIME_WAITが引き起こすポート枯渇の恐怖とその対策

クラウド環境でアプリケーションを動かしている皆さん、普段からインターネットに接続する際に、NATゲートウェイのお世話になっていること、きっと多いですよね。この便利屋さん、実は知られざる「時間泥棒」を抱えていることがあるんです。その正体こそが、TCP接続終了時に発生するTIME_WAITステート。これが蓄積されると、NATゲートウェイのSNATポートが枯渇し、最終的には外部への通信ができなくなってしまう…なんて恐ろしい事態に陥る可能性があるんです。

でも大丈夫！このブログを読み終える頃には、そのメカニズムと具体的な対策がバッチリ理解できているはずです。

そもそもNATゲートウェイって何者？プライベートな場所からインターネットへの「門番」

まず、NATゲートウェイの話をする前に、クラウドのネットワークの基本的な考え方をおさらいしましょう。皆さんがAWSやGCPでサーバーを立ち上げる時、大きく分けて2種類のネットワーク空間を選ぶことができますよね。

1. パブリックサブネット: インターネットから直接アクセスできる、開かれた場所。Webサーバーなど、外部に公開したいサービスはここに置くことが多いです。
2. プライベートサブネット: インターネットからは直接アクセスできない、閉ざされた安全な場所。データベースや内部処理を行うアプリケーションサーバーなど、外部に晒したくないリソースはここに置きます。

さて、問題は、このプライベートサブネットにいるサーバーが「ちょっとインターネットにアクセスしたいな」と思った時です。例えば、OSのアップデートファイルをダウンロードしたり、外部のAPIサービスにデータを取りに行ったり、なんてことは日常茶飯事ですよね。

ここで登場するのが、我らがNATゲートウェイです！

NATゲートウェイは、例えるなら「プライベートな住所しか持たない住人（プライベートサブネットのサーバー）が、外の世界（インターネット）と手紙のやり取りをする際の、公的な窓口を持つ郵便局」のような役割を果たします。

プライベートなサーバーがインターネットにパケット（データ）を送る際、NATゲートウェイはまるで「送り主の住所（プライベートIPアドレス）を、自分の公的な住所（NATゲートウェイのパブリックIPアドレス）に書き換えて（これをSNAT: Source Network Address Translationと言います）」インターネットに送り出します。そして、インターネットからの返事が来たら、それを元のプライベートなサーバーに届けてくれる、というわけです。

これで、プライベートサブネットのサーバーは安全にインターネットと通信できる、という素晴らしい仕組みなんですよね。

TCP接続の「おしまい」ってどうなってるの？電話の切り方を例に

さて、本題のTIME_WAITの話に入る前に、TCPという通信プロトコルが「おしまい」の処理をどうやっているのか、少しだけ覗いてみましょう。

TCPは、信頼性の高い通信を実現するためのプロトコルです。これは、あなたが友達と電話で話すのと似ています。

1. 接続開始（三方向ハンドシェイク）:

  • あなた：「もしもし、〇〇さんですか？」
  • 友達：「はい、そうですけど？」
  • あなた：「よかったです！今から話していいですか？」
  • 友達：「どうぞ！」
  • （これで会話が始まります）

2. 接続終了（四方向ハンドシェイク）:
会話が終わった時、あなたはどうしますか？普通は、

  • あなた：「じゃあ、今日はこの辺で。またね！」（←これがFINパケットの役割の一つ）
  • 友達：「うん、またね！」（←ACKパケットと、友達からのFINパケットの合図）
  • あなた：「うん、またね！」（←最後のACKパケット）

こんな風に、お互いが「もう話すことはないよ」「うん、私もないよ」と確認し合って電話を切りますよね。この「お互い、もう話すことないよね？」と「うん、ないよ」のやり取りが、TCPの「四方向ハンドシェイク」と呼ばれる接続終了のプロセスなんです。

この丁寧なやり取りのおかげで、データが途中で消えたり、意図せず通信が途切れたりすることなく、確実に「おしまい」を迎えることができるわけです。

NATゲートウェイの「しぶとい記憶」：TIME_WAITステートの正体

さあ、いよいよ核心に迫っていきますよ！

先ほどの電話の例で、あなたが「うん、またね！」と最後の言葉を言って電話を切ったとします。この時、あなたはすぐに受話器をガチャンと置いて、すぐに次の電話をかけられますか？

多くの場合、一瞬だけ「本当に切れたかな？」「相手はちゃんと電話を切ったかな？」と、少しだけ受話器を持ったまま待つ時間がありますよね。もしすぐに受話器を置いてしまって、相手からの最後の「じゃあね！」が聞こえなかったら…なんか気まずいことになりますもんね。

TCPの世界でも全く同じことが起こります。接続を「先に」閉じた側（多くの場合、クライアント側、今回のシナリオではNATゲートウェイがこれにあたります）は、最後のACKパケットを送った後、すぐにそのポート（電話回線みたいなものです）を解放しません。

なぜなら、もしも、もしもですよ、自分が送った最後のACKパケットがネットワークの途中で迷子になってしまい、相手に届かなかったら…？相手は「あれ、最後の返事が来ないぞ？」と、もう一度FINパケットを送ってくるかもしれません。

そんな事態に備えて、TCPは一定の時間、その接続で使っていたポートをTIME_WAITステートという状態にして、ひっそりと待機するんです。

このTIME_WAITステート、多くのシステムでは120秒（2分間）という比較的長い時間設定されています。これは、ネットワーク上のパケットが迷子になったり遅延したりしても、十分に対応できるような余裕を持たせるためなんです。

そして、この「しぶとい記憶」が、皆さんが使っているNATゲートウェイでも発生します。つまり、NATゲートウェイがインターネット側のサーバーとのTCP接続を終了する際、その接続で使っていたSNATポートを、すぐに再利用せず、120秒間もTIME_WAITステートとして保持し続ける、ということなんです。

なぜNATゲートウェイでTIME_WAITが問題になるのか？（ポート枯渇）

NATゲートウェイは、プライベートサブネットの複数のサーバーからのインターネット通信を、限られた数のパブリックIPアドレスと、そのパブリックIPアドレスが持つポート番号を使って多重化しています。例えるなら、一台の郵便局が、たくさんの住人からの手紙を、自分の公的な窓口（パブリックIPアドレス）と、窓口のブース番号（ポート番号）を使って捌いているようなものです。

NATゲートウェイが使えるSNATポートの数は、実は有限です。通常、一つのパブリックIPアドレスにつき、約65,535個のポート番号が利用可能ですが、特定の範囲は予約されているため、実際に使えるポートは約6万個弱となります。

ここで先ほどのTIME_WAITステートが問題を引き起こします。

もし、皆さんのアプリケーションが、短命なTCP接続を非常に頻繁に、大量に発生させるような処理を行っているとどうなるでしょう？

例えば、1秒間に数百、数千といったペースで外部APIにリクエストを送り、その都度新しいTCP接続を確立してはすぐに切断する、といったケースです。

このような状況では、NATゲートウェイは次々に新しいSNATポートを割り当てて通信を開始します。しかし、通信が終わっても、割り当てたSNATポートはTIME_WAITステートで120秒間も解放されません。

新しい接続が次々に発生し、古い接続で使われたポートがTIME_WAITで解放されないまま累積していくと、やがてNATゲートウェイが持っている約6万個のSNATポートが、すべてTIME_WAIT状態の接続で埋め尽くされてしまいます。

これが、「ポート枯渇（Port Exhaustion）」です！

ポートが枯渇してしまうと、NATゲートウェイは新しい通信のために割り当てるSNATポートがなくなってしまい、プライベートサブネットからのインターネットへの通信が一切できなくなってしまいます。「ごめんなさい、もう空いている窓口がありません！」という状態ですね。これはアプリケーションの動作を完全に停止させてしまうほどの、非常に深刻な問題なんです。

どんな時にポート枯渇は起きやすい？（具体的なシナリオ）

ポート枯渇は、特に以下のようなケースで発生しやすくなります。

  • マイクロサービスアーキテクチャでの頻繁な通信: 多数の小さなサービスが互いに、あるいは外部APIと、短命なHTTP/HTTPS接続を大量に確立する場合。
  • 外部APIへの高頻度なアクセス: 課金サービス、データ連携、地図情報取得など、外部のAPIエンドポイントに秒間数百回、数千回といったリクエストを投げ続ける場合。
  • データベース接続のプーリング不足: アプリケーションがデータベースへの接続を適切にプーリングせず、リクエストごとに新しい接続を確立・切断している場合。データベースがプライベートサブネットにある場合でも、外部のマネージドDBサービス（RDSなど）への接続もこれに含まれます。
  • サーバーレス関数 (AWS Lambdaなど) からの大量アウトバウンド接続: Lambda関数が短時間で大量に実行され、そのたびに外部リソースにアクセスする場合。

じゃあ、どうする？ポート枯渇対策！

ポート枯渇は恐ろしい問題ですが、適切な対策を講じることで未然に防ぐことが可能です。主な対策を見ていきましょう！

1. Keep-Alive接続を活用してポートを使い回す

最も効果的な対策の一つが、HTTP Keep-Alive（持続接続）の活用です。これは、一度確立したTCP接続を、次の通信でも使い回すという賢い方法です。電話の例で言えば、「じゃあ、またね！」と電話を切らずに、「あ、ついでにこれも聞いてもいい？」と、同じ電話回線で続けて会話をするようなものですね。

これにより、短い期間に大量の接続を確立・切断するのを避け、NATゲートウェイがTIME_WAITで保持するポート数を大幅に削減できます。

Webサーバー (Nginx/Apache) の場合:

NginxやApacheのようなWebサーバーは、デフォルトでKeep-Aliveが有効になっていることが多いですが、設定を見直して最適な値に調整することが重要です。

# Nginxの設定例 (nginx.conf内)
http {
    # クライアントとのKeep-Aliveタイムアウト設定 (秒)
    # この時間内に追加リクエストがない場合、接続は閉じられます。
    keepalive_timeout 65; 

    # 一つのKeep-Alive接続で処理できるリクエストの最大数
    # これを超えると接続は閉じられ、新しい接続が確立されます。
    keepalive_requests 1000; 

    # ...その他の設定
}

アプリケーションコードの場合 (Python requests ライブラリの例):

HTTPクライアントライブラリによっては、Keep-Aliveを明示的に利用するために、セッションオブジェクトを使う必要があります。

import requests

# Sessionオブジェクトを作成することで、基盤となるTCP接続を再利用します
# これがKeep-Alive接続の活用になります
session = requests.Session()

try:
    # 最初のリクエスト
    response1 = session.get('https://api.example.com/data1')
    response1.raise_for_status() # エラーチェック
    print(f"Data 1: {response1.json()}")

    # 同じセッションオブジェクトを使って次のリクエスト
    # これにより、同じTCP接続が再利用される可能性が高まります
    response2 = session.get('https://api.example.com/data2')
    response2.raise_for_status() # エラーチェック
    print(f"Data 2: {response2.json()}")

except requests.exceptions.RequestException as e:
    print(f"リクエスト中にエラーが発生しました: {e}")
finally:
    # セッションを明示的に閉じることで、リソースを解放します
    session.close()

2. コネクションプーリングの徹底

データベース接続やメッセージキューへの接続など、頻繁に利用するリソースへの接続は、コネクションプーリングを積極的に利用しましょう。これは、あらかじめ少数の接続を確立しておき、必要に応じてそれを使い回す仕組みです。新しい接続をいちいち確立・切断する手間を省き、NATゲートウェイの負担を軽減できます。

3. NATゲートウェイの数を増やす（AWSの場合）

もし単一のNATゲートウェイのSNATポートがボトルネックになっているのであれば、複数のNATゲートウェイを配置することも検討できます。AWSの場合、各アベイラビリティゾーン (AZ) にNATゲートウェイを配置し、プライベートサブネットからのルーティングを分散させることで、SNATポートの総数を増やすことが可能です。これにより、ポート枯渇のリスクを分散・軽減できます。

# AWS CLIでのNATゲートウェイ作成例（概念）
# 実際にはElastic IPの割り当て、サブネットの指定などが必要です
# このコマンドはあくまで概念を示すものであり、実際の運用ではTerraformなどIaCツールを使います

# 1. Elastic IPを割り当てる
# aws ec2 allocate-address --domain vpc
# -> AllocationId が返される

# 2. NATゲートウェイを作成する
aws ec2 create-nat-gateway \
    --subnet-id subnet-xxxxxxxxxxxxxxxxx \ # NATゲートウェイを配置するパブリックサブネットID
    --allocation-id eipalloc-xxxxxxxxxxxxxxxxx \ # 1で取得したElastic IPのAllocation ID
    --tag-specifications 'ResourceType=natgateway,Tags=[{Key=Name,Value=My-NAT-Gateway-AZ1}]'

4. 不要な接続を減らす・通信プロトコルの見直し

  • バッチ処理の最適化: 大量のデータを一度に処理するバッチジョブでは、不必要に小さなリクエストを繰り返すのではなく、まとまったデータを一度に送受信できないか検討しましょう。
  • UDPの検討: TCPのような信頼性や順序保証が必要ない（多少のパケットロスが許容される）通信であれば、UDPへの移行も選択肢の一つです。UDPはTCPのような複雑な接続確立・終了プロセスがないため、TIME_WAITステートも発生しません。ただし、これは用途が限られるため、慎重な検討が必要です。

5. モニタリングの徹底とアラート設定

最も重要な対策の一つが、常にNATゲートウェイの状況を監視することです。クラウドプロバイダーは、NATゲートウェイに関する様々なメトリクスを提供しています。

AWS CloudWatchの場合:

NATゲートウェイのポート利用状況を監視するための主要なメトリクスはErrorPortAllocationです。これが計測され始めたら、ポート枯渇が発生しているサインです。また、PacketsDropCountなども監視対象になります。

# AWS CLIでのCloudWatchアラーム設定例（概念）
# NATゲートウェイのポート割り当てエラーが発生した場合に通知するアラーム

aws cloudwatch put-metric-alarm \
    --alarm-name "NATGatewayPortExhaustionAlarm" \
    --alarm-description "NAT Gateway Port Exhaustion detected" \
    --metric-name ErrorPortAllocation \ # 監視対象のメトリクス名
    --namespace AWS/NATGateway \ # メトリクスが属するネームスペース
    --statistic Sum \ # 集計方法 (例: Sum, Average)
    --period 60 \ # 評価期間 (秒)
    --threshold 1 \ # しきい値
    --comparison-operator GreaterThanOrEqualToThreshold \
    --dimensions Name=NatGatewayId,Value=nat-xxxxxxxxxxxxxxxxx \ # 監視対象のNATゲートウェイID
    --evaluation-periods 1 \ # 評価期間の数
    --datapoints-to-alarm 1 \ # アラーム状態にするために必要なデータポイント数
    --treat-missing-data notBreaching \ # データ欠損時の扱い
    --alarm-actions arn:aws:sns:REGION:ACCOUNT_ID:MyNotificationTopic # 通知先SNSトピックARN

GCP Cloud Monitoringでも同様に、Cloud NATのポート利用状況やエラーを監視するメトリクスが提供されていますので、必ずアラートを設定し、早期に異常を検知できるように準備しておきましょう。

まとめ：見えない部分にも目を向けるSREの知恵

今回は、クラウド環境で縁の下の力持ちとして活躍するNATゲートウェイが抱える、TIME_WAITステートによるポート枯渇問題について深掘りしました。

TCPの接続終了という、普段は意識しないような小さな挙動が、大量の短命な接続によって積み重なり、最終的にはシステム全体の通信を止めてしまう可能性がある、ということをご理解いただけたのではないでしょうか。

見えない部分、細かい部分にこそ、システムの安定性やパフォーマンスを左右する重要な要因が隠されているものです。今回ご紹介したKeep-Aliveやコネクションプーリング、適切なモニタリングといった対策は、NATゲートウェイだけでなく、あらゆるネットワーク通信を伴うアプリケーション設計において非常に重要な考え方になります。

ぜひ皆さんも、ご自身のシステムでNATゲートウェイがどのように使われているか、そしてTCP接続の「おしまい」がどうなっているのか、改めて見直してみてくださいね。一歩ずつ、ネットワークの奥深さを理解し、より堅牢なシステムを構築していきましょう！

それでは、また次の記事でお会いしましょう！

スポンサーリンク

コメント

タイトルとURLをコピーしました