【実務・中級編】 NATゲートウェイのコネクション追跡テーブルとハッシュ衝突によるパケットドロップ – クラウド＆コンテナネットワーク実践ガイド

NATゲートウェイの「見えない壁」：コネクション追跡の限界とハッシュ衝突によるパケットドロップの罠

こんにちは。プロダクトの急成長に伴うトラフィックの波に揉まれ、幾度となく夜間呼び出しの洗礼を受けてきたシニアSREの私です。

「ある日突然、特定の外部APIとの通信だけがパタッと途絶える」
「エラーレートは跳ね上がっているのに、アプリケーションのログにはタイムアウトしか残っていない」
「死活監視は正常だし、CPUやメモリにも余裕があるのに、なぜかトラフィックが通らない」

こうした、インフラエンジニアにとって悪夢のような現象に直面したことはないでしょうか。AWSの NAT Gateway や GCPの Cloud NAT、あるいはKubernetesクラスターの境界にそびえ立つ iptables ベースの NAT ルーター。これらは普段、黒衣として黙々とプライベートサブネットのパケットをインターネットへ送り出してくれています。

しかし、その裏側にある「コネクション追跡（Conntrack）テーブル」と「ポートマッピングの数学的限界」を理解していないと、システムがスケールした瞬間に足元をすくわれます。今回は、パケットがNATの内部でどのように迷子になり、なぜパケットドロップを引き起こすのか、その深層と実践的な対策を紐解いていきましょう。

—

1. NATの裏側：コネクション追跡（Conntrack）とSNATの基本

まず、私たちが普段何気なく使っているパブリッククラウドのNATゲートウェイや、Linuxカーネルの netfilter がやっている仕事の基本を整理しておきましょう。

プライベートサブネットにいるコンテナやEC2インスタンス（例えばIPアドレス 10.0.1.100）から、外部の決済API（203.0.113.50:443）へHTTPSリクエストを投げるとします。プライベートIPアドレスはインターネット上ではルーティングできないため、NATゲートウェイが自身のパブリックIPアドレス（例：198.51.100.10）に送信元IPアドレスを書き換えます。これが SNAT（Source Network Address Translation） です。

[Private Pod: 10.0.1.100:54321] 
       │
       ▼ (外向きパケット)
[NAT Gateway / Conntrack Table] 
       - 内部: 10.0.1.100:54321
       - 外部: 198.51.100.10:40001 (割り当てられた一時ポート)
       │
       ▼
[Dest API: 203.0.113.50:443]

ここでNATゲートウェイは、「どのプライベートIPの、どのポートからの通信を、どのパブリックポートに変換したか」を覚えておく必要があります。これが コネクション追跡（Connection Tracking / Conntrack） テーブルです。

通信が完了し、あるいは一定時間放置されると、このエントリは消去されます（タイマーによるGC）。しかし、秒間数万リクエストを捌くマイクロサービス環境では、このテーブルが物理的なメモリの限界やハッシュアルゴリズムの壁にぶつかります。

—

2. なぜパケットは消えるのか？ 2大原因の正体

コネクション関連のトラブルでパケットドロップが発生する原因は、大きく分けて2つあります。

原因A：Conntrackテーブルの溢れ（容量枯渇）

Linuxカーネルの nf_conntrack やクラウドのマネージドNATが保持できる最大コネクション数には上限があります。例えば、Linuxのデフォルト設定や小規模なインスタンスでは、数万〜数十万エントリが上限です。
ピーク時にこの上限に達すると、カーネルは新規のコネクション作成要求（TCPの SYN パケットなど）を容赦なくドロップし始めます。アプリケーション側から見ると、「接続確立のタイムアウト（Connection timed out）」として観測されます。

原因B：ポート枯渇とハッシュ衝突（Hash Collision）

ここからが今回の本丸です。AWSの NAT Gateway などの仕様を見ると、「1つのNAT Gatewayは、送信元IPと送信元ポートの組み合わせで、1つの宛先につき最大64,000の同時接続をサポートする」といった旨が書かれています。

「じゃあ6万4千発までいけるんだな」と安心していませんか？ ここに大きな落とし穴があります。
TCPのコネクションを一意に特定するタプルは、RFC 793等で定義される以下の4要素です。

  • 送信元IPアドレス（Source IP）
  • 送信元ポート（Source Port）
  • 宛先IPアドレス（Destination IP）
  • 宛先ポート（Destination Port）

SNATを通る際、送信元IPとポートはNATゲートウェイのパブリックIPと「一時ポート（Ephemeral Port）」に変換されます。しかし、同一の宛先サーバー（同一IP・同一ポート）に対して、短時間に膨大なリクエストが集中した場合、NAT側で割り振れる一時ポートのプールが圧迫されます。

さらに厄介なのが、カーネルがエントリを高速に検索するために使用するハッシュテーブルの衝突（Hash Collision）です。
メモリ上のハッシュバケットのサイズには限りがあるため、異なるコネクションが同じハッシュ値を持ってしまう「コリジョン」が発生します。カーネルのチェーンが長くなりすぎると、検索処理がタイムアウトしたり、古いエントリが上書き・ドロップされたりして、パケットが迷子になるのです。

—

3. 実務で遭遇するシナリオとコード例

では、これが実際のアプリケーション開発やインフラ運用でどのように現れるか、具体的なコードを見てみましょう。

シシナリオ：外部APIへの大量の非同期リクエスト（Node.js / Fetch API）

例えば、次のようなNode.jsのコードで、同一の外部APIに対して数千件の並行リクエストを一度に投げたとします。

import fetch from 'node-fetch';

// 同一の宛先APIエンドポイント
const API_ENDPOINT = 'https://api.example.com/v1/data';

async function sendBatchRequests(totalRequests) {
  const promises = [];

  for (let i = 0; i < totalRequests; i++) {
    // 接続の都度新しいリクエストを生成（Keep-Aliveが無効、またはコネクションプールが枯渇している状態）
    const p = fetch(API_ENDPOINT, {
      method: 'POST',
      headers: { 'Content-Type': 'application/json' },
      body: JSON.stringify({ index: i, timestamp: Date.now() }),
    })
    .then(response => {
      if (!response.ok) {
        throw new Error(`HTTP error! status: ${response.status}`);
      }
      return response.json();
    })
    .catch(err => {
      // 現場でよく見る「理由不明のネットワークエラー」
      console.error(`Request ${i} failed:`, err.message);
    });

    promises.push(p);
  }

  await Promise.all(promises);
  console.log('Batch request processing completed.');
}

// 5,000件の並行リクエストを投げる
sendBatchRequests(5000);

このコードの何が問題でしょうか？
HTTP/1.1の Keep-Alive が適切に機能していない、あるいは大量のクライアントコンテナが協調せずにバラバラにリクエストを乱発すると、短時間に数千〜数万のTCPハンドシェイクが発生します。これらがすべて同一の宛先IPに向かうため、NATゲートウェイのポートマッピングとConntrackテーブルに瞬間的な負荷が集中し、一部のパケットがドロップします。

—

4. 現場で使える！デバッグとトラブルシューティング手順

もしあなたが「NATのコネクション枯渇やハッシュ衝突」を疑ったとき、現場でどのような手順で原因を特定すべきか。私直伝のコマンド集を授けましょう。

1. LinuxカーネルのConntrackテーブルの使用状況を確認する

Kubernetesのワーカーノードや、自前でEC2に構築したNATインスタンスにログインし、現在のエントri数を確認します。

# 現在カーネルが追跡しているコネクション数の確認
cat /proc/sys/net/netfilter/nf_conntrack_count

# 最大許容コネクション数の確認
cat /proc/sys/net/netfilter/nf_conntrack_max

もし count が max に張り付いている場合、原因A（テーブル溢れ）で確定です。

2. パケットドロップの統計を netstat や ss で追う

# コネクション追跡テーブルのエラーやドロップ数を確認
cat /proc/net/nf_conntrack

# ソケットの統計情報（TCPエフェメラルポートの枯渇状態を確認）
ss -s

3. クラウドメトリクス（AWSの例）の確認

AWS環境であれば、CloudWatchの以下のメトリクスを注視してください。

  • ConnectionTimedOut：ポート枯渇やコネクション制限に達したときに急増します。
  • ErrorPortAllocation：一時ポートの割り当てに失敗した瞬間にカウントされます。この値が 0 より大きい場合、即座に設計の見直しが必要です。

—

5. 根本的な対策とアーキテクチャのベストプラクティス

この問題を防ぐためには、単にインフラのスペックを上げるだけでなく、アプリケーション層からのアプローチが不可欠です。私たちが現場で実践している鉄則をまとめます。

① HTTP Keep-Alive（コネクションプーリング）の徹底

毎回新しいTCPコネクションを張る（Short-lived connection）のではなく、コネクションを再利用（Connection Reuse）します。これにより、3-way handshakeのオーバーヘッドが消え、Conntrackテーブルへのエントリ追加・削除の頻度を劇的に減らすことができます。

Python（requests ライブラリ）での適切なセッション利用例：

import requests
from requests.adapters import HTTPAdapter
from urllib3.util.retry import Retry

def create_robust_session():
    session = requests.Session()
    
    # リトライ戦略の設定
    retries = Retry(
        total=3,
        backoff_factor=0.3,
        status_forcelist=[500, 502, 503, 504]
    )
    
    # コネクションプールのサイズを明示的に大きく設定し、Keep-Aliveを有効化
    adapter = HTTPAdapter(
        pool_connections=50,
        pool_maxsize=100,
        max_retries=retries
    )
    
    session.mount('https://', adapter)
    session.mount('http://', adapter)
    return session

# セッションを使い回すことで、TCPコネクションを維持しNATの負荷を軽減
api_session = create_robust_session()

response = api_session.get('https://api.example.com/v1/data')
print(response.json())

② 宛先IP/ドメインの分散（Sharding）

もし特定のサードパーティAPIへ全トラフィックが集中している場合、DNSラウンドロビンや複数の異なるエンドポイント（もし提供されていれば）に負荷を分散させます。宛先IPが分散すれば、NAT側のポートマッピングのキー（Source IP + Source Port + Dest IP + Dest Port）の組み合わせが増え、ハッシュ衝突の確率を下げることができます。

③ NATゲートウェイのスケールアウト（複数配置）

AWSのNAT Gatewayの場合、可用性とパフォーマンスを高めるために、複数のAZ（アベイラビリティゾーン）にそれぞれNAT Gatewayを配置し、プライベートサブネットのルートテーブルを適切に分割します。これにより、トラフィックが複数のパブリックIPプールに分散され、単一のNAT Gatewayへの負荷集中を防げます。

—

おわりに

パケットの挙動は目に見えません。だからこそ、表面的なエラーメッセージ（504 Gateway Timeout や Connection Refused）だけに惑わされず、その裏側にあるOSのカーネルパラメータやパブリッククラウドのネットワークアーキテクチャに思いを馳せることが、私たちシニアエンジニアの腕の見所です。

「たかがNAT、されどNAT」。
インフラの境界線で起きている微細なパケットのドラマに目を向け、頑健でスケーラブルなシステムを一緒に作り上げていきましょう。それでは、また次回の現場でお会いしましょう！

スポンサーリンク

コメント

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