NATゲートウェイは「魔法の箱」ではない：5Gbpsから45Gbpsへスケールする裏側の真実
クラウドアーキテクトとして多くの設計レビューに立ち会っていると、必ずと言っていいほど直面するのが「NATゲートウェイ（NAT GW）のパフォーマンス限界」という壁です。AWSの公式ドキュメントには「初期5Gbpsから最大45Gbpsまで自動スケールする」と記されていますが、この一文を鵜呑みにして「トラフィックが増えれば勝手に速くなる」と考えているなら、それは大きな誤解です。
NATゲートウェイは単なるルーティングデバイスではなく、ステートフルなNATエンジンです。今回は、この黒い箱の内部で何が起きているのか、そしてパケットの奔流に立ち向かうために我々が何をすべきかを、エンジニアの視点で深掘りします。
1. 「自動スケーリング」という名のラグタイム
NATゲートウェイのスケールアウトは、トラフィックの増大に応じてリソース（具体的にはアグリゲートされた仮想インスタンス群）が動的に追加されることで実現されます。しかし、これは「瞬時」ではありません。
急激なバーストが発生した際、バックエンドの基盤が新しいノードをプロビジョニングし、フローテーブルを同期させるまでの間、パケットは容赦なくドロップされます。この「スケーリングの空白期間」こそが、多くのインフラエンジニアが夜中に叩き起こされる原因となります。
なぜパフォーマンスが低下するのか？
- ポート枯渇（SNATポートの枯渇）: 1つのNATゲートウェイにつき、送信先IP/ポートの組み合わせ（5タプル）には制限があります。急激な接続増は、このポートテーブルを瞬時に埋め尽くします。
- バックプレーンの競合: 複数のAZにまたがる通信が発生すると、物理的な基盤レイヤーでのオーバーヘッドが増大し、RTT（往復遅延時間）がスパイクします。
2. パケットレベルの最適化：我々にできること
NATゲートウェイの限界を物理的に拡張することはできませんが、パケットの「振る舞い」を制御することで、負荷を劇的に軽減することは可能です。
TCPバッファチューニングによるコネクション寿命の管理
デフォルトのカーネルパラメータを放置していると、不要に長い TIME_WAIT 状態のソケットが溜まり、NATのポートを占有し続けます。これを解消するために、以下のチューニングを検討してください。
# TCPのTIME_WAIT状態を再利用可能にするための設定
# これにより、短命なコネクションによるポート枯渇を防ぐ
sysctl -w net.ipv4.tcp_tw_reuse=1
# TCPのキープアライブ時間を短縮し、ゾンビ接続を早期に切り離す
sysctl -w net.ipv4.tcp_keepalive_time=600
sysctl -w net.ipv4.tcp_keepalive_intvl=10
sysctl -w net.ipv4.tcp_keepalive_probes=3TLSハンドシェイクの「重さ」を減らす
NATゲートウェイを通過するパケットの多くはTLS通信です。ハンドシェイクのたびにTCP接続を確立し直していては、ポート消費は加速する一方です。
- HTTP/2 または HTTP/3 (QUIC) の採用: 1つのTCP/UDPコネクションで多重化通信を行うことで、NATテーブル上のエントリ数を劇的に削減できます。
- TLSセッション再開（Session Resumption）:
Session IDやSession Ticketを活用することで、ハンドシェイクの往復回数を減らし、結果としてNATゲートウェイのステート維持負荷を下げます。
3. ヘッダーとトラフィックの賢い扱い方
もし、あなたがマイクロサービス間の通信や、外部APIへの大量リクエストをNATゲートウェイ経由で行っているなら、以下の手法が「最後の砦」となります。
1. VPCエンドポイントの優先
そもそも、AWSサービス（S3やDynamoDBなど）への通信にNATゲートウェイを使うのは「アンチパターン」です。Gateway Load Balancer や Interface VPC Endpoints を活用し、NATゲートウェイのルートから外すだけで、負荷の3割〜5割を削減できることも珍しくありません。
2. コネクションプーリングの徹底
アプリケーション層でのコネクションプーリングは必須です。以下は Python (Requests) での例ですが、Session オブジェクトを使い回すことは、ネットワーク設計における最重要事項です。
import requests
# セッションを再利用してコネクションを維持する
# これにより、毎回新規のTCP/TLSハンドシェイクが発生するのを防ぐ
session = requests.Session()
adapter = requests.adapters.HTTPAdapter(pool_connections=100, pool_maxsize=100)
session.mount("https://", adapter)
# これにより、NATゲートウェイでのポート消費が劇的に抑制される
response = session.get("https://api.external-service.com/data")結びに代えて：我々は「ネットワークのプロ」であるべき
NATゲートウェイは便利ですが、ブラックボックスである以上、その挙動を理解し、追い込まれない設計をすることがSREの矜持です。
- 監視:
ErrorPortAllocationやActiveConnectionCountのメトリクスをCloudWatchで監視し、閾値の80%に達した瞬間にアラートを飛ばすこと。 - 設計: 単一のNATゲートウェイに依存せず、AZごとに分離し、トラフィックを分散させること。
ネットワークは常に「つながらない」ことを前提に設計せよ、というのが私の信条です。NATゲートウェイの帯域制限に怯える日々を終わらせるために、今夜はコードではなく、パケットの旅路に思いを馳せてみてはいかがでしょうか。
コメント