【実務・中級編】 NATゲートウェイの基本概念とマネージドサービスとしての可用性モデル – クラウド＆コンテナネットワーク実践ガイド

こんにちは。SREチームのシニアエンジニアです。

Webアプリケーションのインフラを設計・運用していると、必ずと言っていいほど直面するのが「プライベートサブネットに配置されたバックエンドから、外部のSaaSやWeb APIへ安全にアクセスさせる方法」という課題です。

セキュリティの観点から、データベースやアプリケーションサーバーをインターネットから直接露出させるのは御法度。しかし、外部の決済APIや地理情報サービスと連携するために、外の世界へ出ていくことはどうしても必要になる。この「内から外への片方向通信」をスマートに、かつ高可用性を担保しながら実現してくれるのが、AWSの NAT Gateway や GCPの Cloud NAT といったマネージドNATサービスです。

今回は、これらのマネージドNATがパケットレベルでどのように動き、いかにして可用性を保っているのか、そして実務で遭遇しがちな罠をどう回避するのかを、現場のノウハウを交えながら徹底的に解説していきましょう。

—

1. NATゲートウェイの基本概念と「片方向通信」の正体

そもそもNAT（Network Address Translation）とは何でしょうか。一言で言えば、プライベートIPアドレスとパブリックIPアドレスを変換する仕組みです。

プライベートサブネット（例えば 10.0.1.0/24）にいるインスタンスが、インターネット上のWeb API（例: api.stripe.com）を叩きに行くとします。プライベートIPアドレスはルーティングの仕様上、インターネットの荒海（パブリックネットワーク）に出ていくことはできません。そこで登場するのがNATゲートウェイです。

SNATによるアドレス変換とステートフルな追跡

プライベートインスタンスからのパケットがNATゲートウェイを通過する際、ソースIPアドレス（10.0.1.50 など）が、NATゲートウェイが持つパブリックIPアドレスに書き換えられます。これを SNAT（Source NAT） と呼びます。

ここで重要なのが、NATゲートウェイが ステートフル（Stateful） に動作しているという点です。
NATゲートウェイは、どのプライベートIPのどのポートから、どの外部宛先へ通信が発信されたかを内部のコネクションテーブルに記憶（ステート管理）しています。外部のAPIサーバーからレスポンスパケットが返ってきたとき、NATゲートウェイはそのテーブルを参照し、宛先のパブリックIP/ポートを元のプライベートIP/ポートに書き戻して、正しいインスタンスへ届けます。

これが「プライベートサブネットからの片方向通信」の正体です。

  • 外向き（Outbound）: プライベート → インターネット は許可される。
  • 内向き（Inbound）: インターネットからプライベートへの直接の通信は、NATテーブルに既存のセッションがない限り、完全に拒絶される。

この仕組みにより、外部からの不正な侵入を防ぎつつ、安全に外部APIを叩く環境が整うわけです。

—

2. マネージドNATの可用性モデルとスケーリングの裏側

「自前でEC2やCompute Engineに iptables を仕込んでNATインスタンスを作ればいいのでは？」という質問をジュニアエンジニアからよく受けます。テスト環境ならそれでも動きますが、本番環境でそれをやるのはSREとしての自殺行為です。

パブリッククラウドのマネージドNATゲートウェイ（AWSの NAT Gateway や GCPの Cloud NAT）は、可用性とスケーリングの面で極めて洗練されたアーキテクチャを持っています。

自動冗長化とゾーン障害への耐性

例えばAWSの NAT Gateway は、特定のAZ（アベイラビリティゾーン）内にデプロイされるリソースです。

  • 可用性: 基本的に作成時に指定したAZ内で冗長化されており、裏側では高可用な冗長構成（マルチAZ配置）をとるように設計されています。マルチAZで完全に独立した可用性を担保したい場合は、各AZに1つずつNAT Gatewayを配置するのがベストプラクティスです。
  • フェイルオーバー: 万が一、AZ内でハードウェア障害が発生した場合でも、マネージド基盤側が自動的にルーティングとフェイルオーバーを処理するため、エンジニアが手動で Route Table を書き換える必要はありません。

自動スケーリングの挙動と落とし穴

マネージドNATは、トラフィックの増大に応じて自動的に帯域幅をスケールアップします。AWSの NAT Gateway の場合、初期状態から最大100Gbpsまでシームレスにスケールしますが、ここに実務で一番ハマる罠があります。

それは、「急激なトラフィックのバースト（急増）にはスケールアップが追いつかないことがある」という点です。
大規模なバッチ処理が一斉に走り出したり、数万のリクエストを同時に外部APIへ投げたりすると、NATゲートウェイの処理能力が追いつかず、パケットロスやレイテンシの悪化を引き起こします。もし巨大なトラフィックが見込まれる場合は、事前にリソースを分散させる（複数のNAT Gatewayを用意してルーティングを分ける）設計が不可欠です。

—

3. ネットワークの限界：「ポート枯渇（Port Exhaustion）」のメカニズム

実務のインフラ運用で最も頻繁に遭遇する障害の一つが、「SNATポートの枯渇」です。

TCP/UDP通信では、IPアドレスだけでなく「ポート番号」も組み合わせてセッションを識別しています。1つのパブリックIPアドレスが持つポート数は最大で 65,535 ですが、システム予約ポートなどを除くと、実際にNAT変換に使える利用可能なポート数は約 64,000 程度です。

枯渇が発生するシナリオ

1台のNATゲートウェイを経由して、多数のマイクロサービスが外部の同一ドメイン（例: 決済API）に対して短時間に大量のHTTPリクエストを投げたとします。

  • ネスペの基本ですが、TCPの TIME_WAIT 状態にあるソケットは、一定時間（通常60秒など）ポートを占有し続けます。
  • このポート解放待ちの間に、次々と新しいリクエストが発生すると、瞬く間に利用可能なポートが枯渇します。
  • 結果として、新規の接続が Connection timeout や Cannot assign requested address エラーを返すようになります。

対策：コネクションプーリングとキープアライブ

アプリケーション側、およびインフラ側でこの問題を回避するための鉄則を挙げます。

1. HTTP Keep-Aliveの有効化:
毎回TCPハンドシェイクからやり直すのではなく、既存のコネクションを使い回す（Connection Reuse）ことで、ポートの消費量を劇的に減らします。
2. 複数のパブリックIPの割り当て（GCP Cloud NAT等の場合）:
GCPの Cloud NAT では、1つのNATゲートウェイに複数のパブリックIPアドレス（IPエイリアスなど）を動的に割り当て、ポートプールを拡張する機能があります。
3. 適切なタイムアウト設定:
アイドル状態のコネクションタイムアウトを短く設定することで、不要になったポートを迅速に回収します。

—

4. 実践：プライベートサブネットからの通信とデバッグ手法

それでは、実際にプライベートサブネットからNATゲートウェイ経由で外部APIを叩くアプリケーションコードの例と、疎通確認・デバッグの手順を見ていきましょう。

今回は、Pythonの requests ライブラリを用いて、Keep-Aliveを意識した堅牢なリクエスト送信のサンプルコードを示します。

PythonによるAPIリクエストの実装例（コネクションプール利用）

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

def call_external_api_safely():
    """
    NATゲートウェイ経由でのポート枯渇を防ぎつつ、
    堅牢に外部APIへリクエストを送信するセッションの例
    """
    url = "https://api.example.com/v1/data"
    
    # セッションを作成
    session = requests.Session()
    
    # リトライ戦略の設定（一時的なネットワークエラー対策）
    retries = Retry(
        total=3,
        backoff_factor=1,
        status_forcelist=[500, 502, 503, 504],
        raise_on_status=False
    )
    
    # HTTPAdapterでプールサイズとリトライを紐付け
    # pool_connections と pool_maxsize を適切に設定し、ポートの無駄な消費を抑える
    adapter = HTTPAdapter(
        pool_connections=10,
        pool_maxsize=50,
        max_retries=retries
    )
    
    session.mount("https://://", adapter)
    session.mount("http://://", adapter)

    try:
        # Keep-Aliveが有効な状態でリクエスト送信
        response = session.get(url, timeout=5.0)
        
        if response.status_code == 200:
            print("Successfully fetched data via NAT Gateway.")
            return response.json()
        else:
            print(f"API Error: Status Code {response.status_code}")
            return None

    except requests.exceptions.RequestException as e:
        # タイムアウトや接続エラーのキャッチ
        print(f"Network/Connection error occurred: {e}")
        return None

if __name__ == "__main__":
    call_external_api_safely()

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

もし「プライベートサブネットのインスタンスから外部APIに繋がらない」というアラートを受け取ったら、以下の手順でパケットの足取りを追います。

1. ルーティングテーブルの確認

  • プライベートサブネットが紐づくルートテーブル（Route Table）のデフォルトルート（0.0.0.0/0）の宛先が、正しくNAT Gatewayを向いているか確認します。

2. セキュリティグループ / ファイアウォールの確認

  • インスタンスのセキュリティグループのアウトバウンドルールが、外部への通信（ポート 443 や 80）を許可しているか確認します。（デフォルトでは全許可になっていることが多いですが、厳格な環境では塞がれていることがあります）

3. tcpdump によるパケットキャプチャ

  • インスタンスにログインし、実際にパケットが外に出ようとしているかをキャプチャします。
# インスタンス上で、外部APIのIP宛ての通信をキャプチャして確認する
sudo tcpdump -nnvvS -i eth0 host api.example.com and port 443

ここでパケットが出ていればインスタンス側の設定はOK。もしパケットが返ってこない、あるいはNATゲートウェイでドロップしている疑いがある場合は、クラウドプロバイダ側のメトリクス（AWSなら ErrorPortAllocation や PacketsDropCount）を確認し、ポート枯渇やスループットの制限に引っかかっていないかをドリルダウンします。

—

まとめ

パブリック/プライベートサブネットの分離と、それを繋ぐNATゲートウェイ。一見すると「ただのIP変換装置」のように思えますが、その背後では高度な可用性モデル、ステートフルなセッション管理、そしてポート枯渇というシビアなリソース制約が絡み合っています。

クラウドネットワークの挙動をパケットレベルでイメージできるようになると、インフラ起因の不可解なエラーに直面した際にも、迷いなく原因の切り分けができるようになります。日々の設計やコードレビューの際に、ぜひ「この通信の裏でNATはどのようにセッションを維持しているか？」という視点を持ってみてください。

それでは、次のSREライフログでお会いしましょう！

スポンサーリンク

コメント

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