【実務・中級編】 TCPタイムアウトとNATゲートウェイのコネクションエージング処理 – クラウド＆コンテナネットワーク実践ガイド

はい、承知いたしました。パケットがネットワークを駆け巡るリアルな挙動、現場での泥臭いトラブルシューティング、そして人間味あふれる豊かな文脈を盛り込み、実務で役立つ技術ブログ記事を執筆します。

—

TCPコネクションとNATゲートウェイの「静寂」が招く落とし穴～アイドルタイムアウトとキープアライブの深淵～

皆さん、こんにちは！クラウド＆コンテナネットワークの深淵を覗き、数々の障害を乗り越えてきたベテランSRE、〇〇（あなたの名前）です。今日は、普段あまり意識しないけれど、実はWeb APIの設計やインフラ運用で「あれ？繋がらないぞ？」という現象を引き起こす、TCPのタイムアウトとNATゲートウェイの挙動について、現場のリアルな視点から深掘りしていきましょう。

特に、アイドル状態が続いたTCPコネクションが、なぜかNATゲートウェイから突然破棄されてしまう、あの「静寂の破壊」について、そのメカニズムと、どうすれば回避できるのかを、具体的なコード例や設定を交えながら、皆さんの疑問に直球で答えていきます。

1. 突然切断されるTCPコネクション：その犯人はNATゲートウェイ？

「APIリクエストを送ったら、なぜかタイムアウトするんだよね…」
「しばらく放置していたWebSocket接続が、突然切れてしまう…」

こんな経験、ありませんか？原因を調査すると、アプリケーション側やネットワーク機器の設定には問題が見当たらない。でも、通信は確かに途切れている。この、原因不明な切断の犯人として、しばしば疑われるのがNATゲートウェイです。

NATゲートウェイは、プライベートサブネット内のインスタンスがインターネットと通信する際に、プライベートIPアドレスをグローバルIPアドレスに変換する役割を担っています。これは、IPアドレスの枯渇問題を解決し、ネットワークのセキュリティを向上させるための非常に重要な仕組みです。

しかし、このNATゲートウェイ、実はTCPコネクションの状態を管理するコネクションテーブルを持っています。そして、このテーブルには「アイドルタイムアウト」という、静かにコネクションを終了させるための仕組みが組み込まれているのです。

2. コネクションテーブルとアイドルタイムアウト：静寂の期限

NATゲートウェイがTCPコネクションを管理する際、通信の有無を記録したコネクションテーブルを作成します。このテーブルには、送信元IPアドレス、送信元ポート、宛先IPアドレス、宛先ポート、プロトコルなどの情報が記録されます。

そして、このテーブルのエントリには、アイドルタイムアウトという値が設定されます。これは、一定時間、そのコネクション上でデータ送受信がない場合に、NATゲートウェイがそのコネクションを「無効」とみなし、コネクションテーブルから削除してしまうというものです。

では、このデフォルトのアイドルタイムアウト時間はどれくらいでしょうか？

AWS NAT Gateway: デフォルトは4分 (240秒) です。
GCP Cloud NAT: デフォルトは10分 (600秒) です。

※RFCには特定のタイムアウト値は定義されていません。各クラウドプロバイダーが独自のデフォルト値を設定しています。

つまり、TCPコネクションが4分（AWSの場合）あるいは10分（GCPの場合）の間、全く通信のない「アイドル状態」が続くと、NATゲートウェイは「もうこのコネクションは使われていないだろう」と判断し、コネクションテーブルからエントリを削除します。

この状態になると、その後、クライアントがそのコネクションを使ってデータを送信しようとしても、NATゲートウェイはどのコネクションに対応すれば良いか分からなくなってしまい、結果として「タイムアウト」や「Connection Reset」といったエラーが発生するのです。

通信フロー（シーケンス）の例：アイドルタイムアウトによる切断

1. クライアント → NAT Gateway → サーバー: TCPコネクション確立 (SYN, SYN-ACK, ACK)
2. クライアント → NAT Gateway → サーバー: データ送信 (APIリクエストなど)
3. サーバー → NAT Gateway → クライアント: データ受信 (APIレスポンスなど)
4. （一定時間、通信なし…）
5. NAT Gateway: コネクションテーブルのエントリがアイドルタイムアウト（例: 4分）により削除される。
6. クライアント → NAT Gateway → サーバー: データを送信しようとする。
7. NAT Gateway: 対応するコネクションテーブルのエントリが見つからず、パケットを破棄。
8. クライアント: タイムアウトエラー、またはConnection Resetを受信する。

3. なぜアイドルタイムアウトが問題になるのか？

このアイドルタイムアウトは、以下のようなシナリオで問題を引き起こしやすくなります。

長時間のバックグラウンド処理: サーバー側で長時間のバッチ処理などを実行し、その間にクライアントからの通信がない場合。
WebSocketやServer-Sent Events (SSE): リアルタイム通信では、データが送受信されないアイドル時間が長くなることがあります。
APIのポーリング: クライアントが定期的にAPIをポーリングするような設計で、ポーリング間隔がアイドルタイムアウトよりも長い場合。
ステートフルなコネクション: 一度確立したコネクションを、後続の処理のために維持しておきたい場合。

これらのシナリオで、アプリケーション側では「コネクションは生きているはず」と思っていても、NATゲートウェイの都合で突然切断されてしまうのです。

4. 「キープアライブ」という名の生命線

では、このアイドルタイムアウトの落とし穴をどう回避すれば良いのでしょうか？答えはシンプルですが、非常に重要です。それは、「コネクションをアイドル状態にしない」ことです。

そのための最も一般的な手法が「キープアライブ (Keep-Alive)」です。

キープアライブには、大きく分けて2つのレベルがあります。

4.1. TCPレベルのキープアライブ (TCP Keepalive)

これは、OSのTCP/IPスタックが管理する機能です。一定期間、データ送受信がない場合に、OSが自動的に「キープアライブプローブ」と呼ばれる小さなパケットを送信します。このプローブに対して相手からの応答（ACK）があれば、コネクションは生きていると判断されます。

RFC 1122 (Requirements for Internet Hosts — Communication Layers) にて、TCP Keepaliveの概念が定義されています。
Linux: /proc/sys/net/ipv4/tcp_keepalive_time (デフォルト: 7200秒 = 2時間)、tcp_keepalive_intvl (デフォルト: 75秒)、tcp_keepalive_probes (デフォルト: 9) で設定できます。
macOS/BSD: kern.tcp_keepalive のようなsysctlパラメータで設定します。

このTCPレベルのキープアライブは、OSレベルで自動的に行われるため、アプリケーション開発者が意識する必要がない場合も多いです。しかし、NATゲートウェイのアイドルタイムアウト（4分や10分）よりも長い設定になっていることが多いため、NATゲートウェイのタイムアウトを防ぐためには、このTCP Keepaliveの設定値をOS側で変更するか、後述するアプリケーションレベルでのキープアライブを実装する必要があります。

4.2. アプリケーションレベルのキープアライブ

こちらは、アプリケーション側で意図的に、定期的に小さなデータを送受信することで、コネクションをアクティブに保つ方法です。HTTPのKeep-Aliveヘッダーや、WebSocketのPing/Pongフレームなどがこれに該当します。

HTTP Keep-Alive

HTTP/1.1では、デフォルトでConnection: Keep-Aliveヘッダーが使用され、一つのTCPコネクション上で複数のHTTPリクエスト/レスポンスをやり取りできます。しかし、これはあくまで「HTTPレベル」でのコネクション再利用であり、TCPレベルでのコネクション維持を保証するものではありません。

もし、HTTPリクエストとレスポンスの間に長いアイドル時間が存在する場合、NATゲートウェイのアイドルタイムアウトによってコネクションが切断される可能性があります。

Web API 設計におけるキープアライブの考慮

Web APIを設計する際、特にクライアントとサーバー間で長時間の通信や、定期的な状態確認が必要な場合は、アプリケーションレベルでのキープアライブを検討すべきです。

HTTP Long Polling / SSE: クライアントがサーバーからのイベントを待つ場合、サーバー側で定期的に空のレスポンスを返す（HTTP Long Polling）か、SSEのevent: keepaliveのような仕組みを導入します。
WebSocket: WebSocketプロトコル自体に、Ping/Pongフレームによるキープアライブ機能が備わっています。これを利用して、アイドル状態を防ぎます。
カスタムプロトコル: 独自のTCPベースのプロトコルを使用している場合は、アプリケーションレベルで定期的にハートビートパケットを送信する処理を実装します。

コード例：Pythonでのアプリケーションレベルキープアライブ（HTTPリクエスト）

Pythonのrequestsライブラリでは、keep_aliveパラメータでTCP Keepaliveを有効にできます。ただし、これはOSレベルのTCP Keepaliveを制御するもので、NATゲートウェイのタイムアウトとは直接関係ありません。

import requests
import time

# NATゲートウェイのアイドルタイムアウト（例: 4分 = 240秒）より短い間隔で
# 定期的にリクエストを送信するシナリオを想定
session = requests.Session()
session.keep_alive = True # TCP Keepaliveを有効にする（OS設定に依存）

try:
    print("最初のAPIリクエストを送信します...")
    response = session.get('http://example.com/api/resource', timeout=10)
    response.raise_for_status() # エラーがあれば例外を発生させる
    print(f"レスポンス: {response.status_code}")

    # ここで、APIリクエストと次のリクエストの間に長いアイドル時間が想定される場合
    print("アイドル時間（例: 3分）をシミュレートします...")
    time.sleep(180) # 3分待機

    print("再度APIリクエストを送信します...")
    # もしNATゲートウェイのタイムアウト（例: 4分）を超えていたら、ここで切断される可能性がある
    response = session.get('http://example.com/api/resource', timeout=10)
    response.raise_for_status()
    print(f"レスポンス: {response.status_code}")

except requests.exceptions.RequestException as e:
    print(f"リクエスト中にエラーが発生しました: {e}")
    print("NATゲートウェイのアイドルタイムアウトによりコネクションが切断された可能性があります。")

finally:
    # セッションを閉じる（コネクションを解放する）
    session.close()
    print("セッションを閉じました。")

解説:

requests.Session() を使うことで、HTTPコネクションを再利用できます。
session.keep_alive = True は、TCP Keepaliveを有効にするための設定ですが、これはOSのTCP Keepalive設定に依存するため、直接NATゲートウェイのアイドルタイムアウトを防ぐものではありません。
重要なのは、time.sleep(180) のようなアイドル時間が発生する前に、定期的にAPIリクエストを送信することです。これにより、NATゲートウェイのコネクションテーブルのエントリを更新し、アイドルタイムアウトを防ぎます。
この例では、3分間のアイドル時間をシミュレートしていますが、実際の環境では、NATゲートウェイのデフォルトアイドルタイムアウト（AWSなら240秒）を考慮して、それよりも短い間隔でリクエストを送信する必要があります。

コード例：JavaScript (Fetch API) でのキープアライブ（SSEの場合）

Server-Sent Events (SSE) は、サーバーからクライアントへの一方的なリアルタイム通信に適した技術です。SSEでは、event: keepalive のようなカスタムイベントや、単純にイベントがなくても通信が継続していることで、コネクションが維持されます。

// サーバー側で定期的に 'keepalive' イベントを送信する、または
// 何もイベントがない場合でも、HTTP接続自体が継続していることを利用する

const eventSource = new EventSource('/api/stream'); // サーバーのエンドポイントを指定

eventSource.onmessage = function(event) {
    // 通常のメッセージ受信時の処理
    console.log("受信データ:", event.data);
};

eventSource.addEventListener('keepalive', function(event) {
    // 定期的に送信されるキープアライブイベントの処理（任意）
    console.log("キープアライブ信号を受信しました。");
});

eventSource.onerror = function(err) {
    console.error("EventSourceエラー:", err);
    // エラー発生時の再接続処理などを記述
    eventSource.close(); // エラー時に接続を閉じる
};

// アプリケーション側で、一定時間イベントがない場合に
// 明示的にサーバーにハートビートを送信するようなロジックを実装することも可能
// (例: fetch('/api/heartbeat') のようなリクエストを定期的に送信)

解説:

SSEはHTTP/1.1のtext/event-streamフォーマットを使用します。サーバーがデータを送信し続ける限り、TCPコネクションはアクティブであるとみなされます。
event: keepalive のようなカスタムイベントをサーバー側で定期的に送信することで、クライアント側でイベントを受信し、コネクションが生きていることを確認できます。
もしサーバー側で明示的なキープアライブイベントを送信しない場合でも、クライアント側で一定時間（NATゲートウェイのアイドルタイムアウトより短い間隔）で fetch('/api/heartbeat') のような軽量なリクエストを別途送信し、コネクションをアクティブに保つことも有効な手段です。

コード例：curl コマンドでのキープアライブ

curlコマンドでHTTPリクエストを行う際、デフォルトでHTTP/1.1のKeep-Aliveが有効になります。しかし、これもTCPレベルでのコネクション維持を直接保証するものではありません。

# HTTP/1.1のKeep-Aliveはデフォルトで有効
curl -v http://example.com/api/data

# タイムアウトを長く設定する（これはサーバーやネットワーク機器のタイムアウトであり、NATゲートウェイのアイドルタイムアウトとは異なる）
curl --connect-timeout 5 --max-time 60 http://example.com/api/data

# 接続を明示的に閉じる場合は --no-keepalive オプションを使用
# curl --no-keepalive http://example.com/api/data

解説:

curlはHTTP/1.1のKeep-Aliveをデフォルトで利用するため、一度コネクションが確立されると、複数のリクエストを同じコネクションで送信しようとします。
しかし、リクエスト間にNATゲートウェイのアイドルタイムアウトを超える間隔があると、コネクションは切断されます。
curl単体でNATゲートウェイのアイドルタイムアウトを防ぐための直接的なオプションはありません。スクリプトでcurlを繰り返し実行する場合、実行間隔を短く保つことが重要です。

5. NATゲートウェイの設定変更：最後の手段

多くのクラウドプロバイダーでは、NATゲートウェイのアイドルタイムアウト設定を変更できない場合が多いです。これは、NATゲートウェイが共有リソースであるため、各ユーザーの設定によって全体のスループットやリソース使用率に影響が出る可能性があるからです。

AWS: NAT Gatewayのアイドルタイムアウトは変更できません（常に4分）。
GCP: Cloud NAT のアイドルタイムアウトは、設定可能です。最小値は30秒、最大値は2,047,483,647秒 (約65年) です。

GCP Cloud NAT の設定例 (gcloud CLI)

GCPでCloud NATのアイドルタイムアウトを変更したい場合は、gcloud compute routers nats update コマンドを使用します。

# 特定のCloud NAT設定のアイドルタイムアウトを30分 (1800秒) に変更する例
gcloud compute routers nats update <NAT_GATEWAY_NAME> \
    --router=<ROUTER_NAME> \
    --region=<REGION> \
    --tcp-established-idle-timeout=1800s \
    --udp-idle-timeout=60s # UDPも必要に応じて設定

解説:

--tcp-established-idle-timeout: TCPコネクション確立後のアイドルタイムアウトを設定します。
--udp-idle-timeout: UDP通信のアイドルタイムアウトを設定します。（UDPにはコネクションという概念はありませんが、一定時間通信がない場合にリソースを解放するための設定です。）
この設定により、NATゲートウェイのコネクションテーブルからエントリが削除されるまでの時間を長くすることができます。ただし、CPUやメモリなどのリソースをより長く消費する可能性があるため、注意が必要です。

注意点:
AWSではアイドルタイムアウトの変更ができないため、アプリケーションレベルでのキープアライブ実装が唯一の解決策となります。GCPでも、むやみにタイムアウトを長くするのではなく、アプリケーション側の設計で対応できるのであれば、そちらを優先するのが良いでしょう。

6. まとめ：静寂を避けるための設計思想

今日の話は、一見地味ですが、Web APIの信頼性や、バックグラウンド処理の安定稼働に直結する重要なテーマです。

NATゲートウェイにはデフォルトのアイドルタイムアウトがある（AWS: 4分, GCP: 10分）。
アイドル状態が続くと、コネクションテーブルからエントリが削除され、通信が途絶える。
これを回避するには、コネクションをアイドル状態にしない「キープアライブ」が有効。
TCPレベルのKeepaliveはOS設定に依存し、アプリケーションレベルのKeepaliveは実装が必要。
WebSocketなどはプロトコル自体にキープアライブ機能がある。
GCPではCloud NATのアイドルタイムアウトを変更できるが、AWSでは不可。

結局のところ、この問題の本質は「状態を維持するコネクションは、定期的にその状態を主張し続ける必要がある」ということです。

Web APIを設計する際、あるいはインフラを構築する際には、このようなネットワークの「暗黙のルール」や「隠れた仕様」を理解しておくことが、後々のトラブルシューティングや、より堅牢なシステム構築につながります。

皆さんの日々の開発や運用において、この知識が少しでもお役に立てば幸いです。
何かご質問や、現場での面白い体験談があれば、ぜひコメントで教えてくださいね！

では、また次回の技術探求でお会いしましょう！

TCPコネクションとNATゲートウェイの「静寂」が招く落とし穴 ～アイドルタイムアウトとキープアライブの深淵～

1. 突然切断されるTCPコネクション：その犯人はNATゲートウェイ？

2. コネクションテーブルとアイドルタイムアウト：静寂の期限

通信フロー（シーケンス）の例：アイドルタイムアウトによる切断

3. なぜアイドルタイムアウトが問題になるのか？

4. 「キープアライブ」という名の生命線

4.1. TCPレベルのキープアライブ (TCP Keepalive)

4.2. アプリケーションレベルのキープアライブ

HTTP Keep-Alive

Web API 設計におけるキープアライブの考慮

コード例：Pythonでのアプリケーションレベルキープアライブ（HTTPリクエスト）

コード例：JavaScript (Fetch API) でのキープアライブ（SSEの場合）

コード例：curl コマンドでのキープアライブ

5. NATゲートウェイの設定変更：最後の手段

GCP Cloud NAT の設定例 (gcloud CLI)

6. まとめ：静寂を避けるための設計思想

コメント

TCPコネクションとNATゲートウェイの「静寂」が招く落とし穴～アイドルタイムアウトとキープアライブの深淵～