脱・「とりあえずNAT GW」：SaaS連携におけるEgress IP固定化とネットワーク・パフォーマンスの最適化
クラウドネイティブな環境において、SaaSプロバイダーから突きつけられる「送信元IPアドレスのホワイトリスト登録要件」は、多くのエンジニアにとって悩みの種です。単に NAT Gateway を配置すれば解決すると思われがちですが、その裏側でパケットがどのような運命を辿り、どのようにパフォーマンスを損なう可能性があるのか、深く考察したことはあるでしょうか。
今日は、単なる「繋がるインフラ」を超えた、極限の可用性と低レイテンシを実現するためのEgress設計について、現場の泥臭い知見を交えて深掘りします。
—
なぜ「NAT Gateway」が必要なのか：パケットの視点から
コンテナがパブリッククラウドのプライベートサブネットから外部APIへリクエストを投げる際、パケットは自身のプライベートIPをソースとして出発します。しかし、そのままではインターネットのルーティング網で破棄されるか、相手先に到達しても戻りのパケットが宛先を見失います。
NAT Gateway は、このプライベートIPをマネージドなパブリックIPへと書き換える（SNAT）役割を担います。これにより、外部のAPIプロバイダーからは「あなたの固定IPからリクエストが来ている」と認識されるわけです。
アーキテクチャの急所：コネクション枯渇とTCPポートの窮屈さ
ここでの最大の罠は、NAT Gateway のポート制限です。1つのパブリックIPは、最大64,512個の送信元ポート（Ephemeral Ports）しか保持できません。高負荷なマイクロサービスが外部APIを叩きまくると、このポートが枯渇し、コネクション確立時に EADDRNOTAVAIL を連発する事態に陥ります。
これを避けるには、以下の対策が必須です。
1. コネクションプーリング: HTTPクライアント（keep-alive）を適切に設定し、接続を使い回す。
2. NAT Gatewayの分散: 特定のサブネットに負荷を集中させず、マルチAZでNAT GWを配置し、ルーティングテーブルをAZごとに制御する。
—
トランスポート層の最適化：RTT削減とバッファチューニング
SaaS連携がボトルネックになる多くの原因は、DNSルックアップのオーバーヘッドとTLSハンドシェイクにあります。
TLSハンドシェイクの最適化
TLS 1.3を使用することは現代の必須条件ですが、さらに踏み込んで TCP Fast Open (TFO) の活用を検討すべきです。これにより、2回目の接続以降はハンドシェイク待ちをスキップし、データを最初のパケットに含めて送信可能です。
Linuxカーネルレベルで設定を確認する場合：
# TCP Fast Openが有効か確認（1であればクライアントとして有効）
cat /proc/sys/net/ipv4/tcp_fastopen
# 有効にするための設定（永続化には sysctl.conf に記述）
sysctl -w net.ipv4.tcp_fastopen=3TCPバッファチューニング
SaaSへの大容量通信が発生する場合、デフォルトのTCPウィンドウサイズでは帯域を使い切れません。カーネルのバッファサイズを調整することで、RTT（往復時間）が長い環境下でもスループットを維持できます。
# カーネルのTCP送受信バッファの推奨値（例：最大16MB）
sysctl -w net.core.rmem_max=16777216
sysctl -w net.core.wmem_max=16777216
sysctl -w net.ipv4.tcp_rmem="4096 87380 16777216"
sysctl -w net.ipv4.tcp_wmem="4096 65536 16777216"—
現場で遭遇する「見えない壁」：ヘッダー圧縮とMTU問題
外部APIとの間で頻発するトラブルに「パケットフラグメンテーション」があります。特にVPN経由やオーバーレイネットワーク（VPC内）を使用している場合、MTUサイズが標準の 1500 バイトより小さくなることがあります。
パケットサイズがMTUを超えると、途中のルーターでフラグメンテーションが発生し、パケットロスやCPU負荷増大を招きます。以下のコマンドで、パスのMTUを測定し、必要に応じて mss を調整してください。
# PMTUD (Path MTU Discovery) の確認
# 外部APIエンドポイントに対してフラグメント禁止ビットを立ててpingを打つ
ping -M do -s 1472 api.example.comもしパケットが通らなければ、iptables や nftables で TCP MSS Clamping を設定し、強制的に最大セグメントサイズを小さくします。
# MSSを1400バイトに固定する（オーバーレイネットワーク等での回避策）
iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1400—
セキュリティの「防御的設計」：ホワイトリストのその先へ
単に固定IPをホワイトリストに登録するだけでは、万が一の侵害時にあなたのIP経由で攻撃が行われるリスクがあります。
- Egress Filterの導入: Kubernetesの
NetworkPolicyを活用し、特定のNamespaceまたはPodからしか外部SaaSへ通信できないよう、L4層で厳格に制御してください。 - プロキシを通した可視化: 厳格なセキュリティ要件がある場合、
NAT Gatewayの代わりにEgress Proxy（SquidやEnvoy）を介在させ、HTTPヘッダーレベルでのアクセス制御やログ取得を行うことを推奨します。
まとめ：SREが追求すべき「ネットワークの透明性」
ネットワークエンジニアリングにおいて、「動けばいい」という考えは技術的負債の第一歩です。IP固定化という要件を、単なるルーティングの設定と捉えず、パケットの往来を最適化し、ボトルネックを予測し、カーネルパラメータをチューニングする。この泥臭い積み重ねこそが、SaaSとの強固で高速な連携を可能にします。
次回のデプロイ時、tcpdump を片手にパケットの挙動を追ってみてください。そこには、教科書には載っていない、あなただけのインフラの鼓動が聞こえるはずです。
コメント