はじめに：なぜ「パケットの断片化」で深夜の障害対応に追われるのか
クラウドインフラの設計において、AWSのVPC（Virtual Private Cloud）はもはや空気のような存在です。プライベートサブネット、パブリックサブネット、そしてインターネットゲートウェイ（IGW）。コンソールを数回クリックすれば、あっという間にセキュアでスケーラブルなネットワーク空間が完成します。
しかし、現場で数々の修羅場をくぐり抜けてきたSREなら誰しも、一度はこんな怪奇現象に直面したことがあるはずです。
> 「社内やAWS内のEC2同士では爆速で通信できるのに、なぜか外部の特定APIを叩くときだけ、特定のサイズを超えるとコネクションがタイムアウトする」
> 「ロードバランサーの裏にいるコンテナから、特定のクラウドサービスへPOSTリクエストを送ると、途中でプツリと通信が途切れる」
モニター画面を睨みつけ、tcpdumpやWiresharkでパケットキャプチャを採取してみると、そこにはMTU（Maximum Transmission Unit）とMSS（Maximum Segment Size）の静かなる戦いが広がっています。
今回は、AWSのインターネットゲートウェイ（IGW）を通過するパケットが直面する「9001バイトの幻想」と「1500バイトの現実」、そしてそれを救うTCP MSSクランピングのメカニズムについて、実務の現場で即使える知識と共にお届けします。
—
1. 物理と仮想のギャップ：ジャンボフレームと標準Ethernetの宿命
AWSのEC2インスタンス（M5やC5といったモダンなインスタンスファミリーの多く）では、VPC内のネットワークインターフェイス（ENI）のデフォルトMTUとして、なんと 9001バイト（いわゆるジャンボフレーム）がサポートされています。
アプリケーション層から見ると、これは非常にありがたい仕様です。1回のシステムコールでより多くのデータをカーネル空間に送り出せるため、CPUのコンテキストスイッチのオーバーヘッドが軽減され、スループットが向上します。
パケットがAWSの外へ飛び出す瞬間
しかし、この9001バイトの巨大なパケット（Ethernetフレーム）が、VPCの境界線であるインターネットゲートウェイ（IGW）を通過してパブリックインターネットへ旅立つとき、残酷な現実が突きつけられます。
インターネットの大部分を占める標準的なEthernetの物理的上限、および一般的なルーターの最大MTUは 1500バイト です。
ここで何が起きるでしょうか？
1. フラグメンテーションの発生:
IGWは、9001バイトのパケットを1500バイト（IPヘッダーやTCPヘッダーの分を引くと、ペイロードはおよそ1460バイト程度）の断片（フラグメント）に分割して送り出そうとします。
2. クラウドネイティブな罠（ドロップの危機）:
近代的なファイアウォールやセキュリティアプライアンス、あるいは経路上のプロバイダーのルーターの中には、セキュリティ上の理由や処理効率の観点から、IPフラグメント化されたパケットを嫌う（あるいは容赦なくドロップする）ものが少なくありません。また、IPv4パケットのIPヘッダーにある DF（Don't Fragment：フラグメント禁止） ビットが立っている場合、ルーターはパケットを砕くことができず、ICMP（Type 3 Code 4: Fragmentation Needed and DF set）を送り主（あなたのEC2）に返そうとします。
3. ICMPブラックホール問題:
しかし、世の中の多くのセキュリティグループやネットワーク機器、あるいはクラウドのステートフルファイアウォールは、この「ICMPの悲鳴（Path MTU Discoveryに必要な制御メッセージ）」をセキュリティ上の脅威とみなして容赦なくドロップします。これが、送信元が「道が狭いこと」に気づけず、通信が永遠にフリーズする「ICMPブラックホール」の正体です。
—
2. TCP MSSクランピングによるスマートな解決策
この悲劇を防ぐための黄金律が、TCP MSSクランピング（MSS Clamping）です。
MSS（Maximum Segment Size）とは何か？
MTUが「ネットワーク層（IP層）で一度に運べるパケットの最大サイズ」であるのに対し、MSSは「トランスポート層（TCP層）で一度にやり取りできるペイロードの最大サイズ」を指します。
通常、TCPの3ウェイハンドシェイク（SYNパケットのやり取り）の際、お互いのクライアントとサーバーは MSSオプション を交換し、「私の受信バッファはこれだけのサイズを受け取れるので、この大きさのセグメントで送ってください」とネゴシエーションを行います。
ゲートウェイにおける「お節介」な書き換え
TCP MSSクランピングとは、ルーターやゲートウェイ（AWSの仮想ルーター群を含む）が、通過するTCPの SYN パケットをリアルタイムに監視し、その中にあるMSSの値を強制的に小さく書き換える（Clampする）技術です。
- 通常時の計算:
標準EthernetのMTU (1500バイト) – IPヘッダー (20バイト) – TCPヘッダー (20バイト) = 1460バイト
もしAWS側のEC2が「私のMSSは8961バイトです！」と宣言したSYNパケットを送り出しても、適切な経路上のデバイスやVPNゲートウェイ（AWSのトランジットゲートウェイやクライアントVPNなど）がこれを検知し、MSSを 1460（あるいはPPPoEなどが絡む場合はさらに低い値）に書き換えて相手に届けます。
これにより、アプリケーション層は最初から1460バイト以下のセグメント単位でデータを生成するため、そもそも9001バイトのパケットを途中でフラグメントする必要がなくなるのです。
—
3. 実務でのトラブルシューティング：Web API設計とコードからのアプローチ
では、このネットワークの深層を知るエンジニアとして、実務のWeb API設計やアプリケーション実装において何を意識すべきでしょうか。
「ネットワーク層のことはインフラチームに任せた」では、現代のクラウドネイティブな開発では通用しません。アプリケーション側からパケットの挙動をコントロール、あるいはデバッグする手法を見ていきましょう。
デバッグの基本：curlとパケットサイズ（MTU）の確認
もしあなたが開発しているマイクロサービスから外部のAPIサーバーへリクエストを送った際、特定のサイズ（例えばペイロードが2KBを超えるようなJSONリクエスト）だけがタイムアウトする場合、疑うべきはMSS/MTUのミスマッチです。
手元のEC2やコンテナ内から、実際にどのようなMSSでTCPコネクションが張られているかを tcpdump で覗いてみることができます。
# 外部APIサーバーへの通信に絞ってTCPのハンドシェイク（SYNパケット）とMSSをキャプチャする
sudo tcpdump -nnvvS -i eth0 'tcp[tcpflags] & (tcp-syn) != 0'キャプチャ結果の中に以下のような記述が見つかるはずです。
options [mss 8961,...] （内部向けの場合）
これが外部へ向かう際に適切に調整されているか、あるいはアプリケーション側で明示的にソケットオプションを絞る必要があるかの判断材料になります。
—
アプリケーションコードからの制御例
通常、OSのネットワークスタックが自動的にPath MTU Discovery（PMTUD）やMSS調整を行ってくれますが、コンテナ環境（DockerやKubernetesのPodネットワーク、CNIプラグインのオーバーヘッド等）では、カプセル化（VXLANやGeneveなど）によってMTUがさらに削られることがあります（例: 1410バイトや1360バイトへの縮小）。
もしPythonの requests や urllib、あるいはNode.jsの fetch を使って巨大なリクエストを頻繁に送受信するWeb APIクライアントを実装する場合、タイムアウトやコネクションリセットに悩まされないための配慮が必要です。
以下に、Pythonでカスタムセッションを張り、適切なタイムアウトとリトライ、そしてソケットレベルの挙動を意識した堅牢なAPIクライアントのコード例を示します。
import requests
from requests.adapters import HTTPAdapter
from urllib3.util.retry import Retry
def create_resilient_api_client():
"""
ネットワークの揺らぎやMTU/MSS起因のパケットロス、
一時的な切断に耐える堅牢なHTTPセッションを構築するファクトリ関数。
"""
session = requests.Session()
# リトライ戦略の設定
# ネットワークのフラグメンテーションや一時的なブラックホールによるドロップに対処
retries = Retry(
total=3,
backoff_factor=1.0, # 1秒, 2秒, 4秒とバックオフ
status_forcelist=[500, 502, 503, 504],
raise_on_status=False
)
adapter = HTTPAdapter(max_retries=retries)
session.mount("https://", adapter)
session.mount("http://", adapter)
return session
# 使用例
if __name__ == "__main__":
client = create_resilient_api_client()
api_url = "https://api.example.com/v1/data-heavy-endpoint"
payload = {
"items": ["data_string_to_fill_packet..." * 100]
}
try:
# コネクションタイムアウトと読み取りタイムアウトを明示的に分ける
# ネットワーク経路でのパケットロスがある場合、connect timeoutで早期に検知する
response = client.post(api_url, json=payload, timeout=(3.1, 30))
print(f"Status Code: {response.status_code}")
print(f"Response: {response.json()}")
except requests.exceptions.Timeout:
print("【アラート】APIリクエストがタイムアウトしました。MTU/MSSの不整合によるパケットドロップの可能性があります。")
except requests.exceptions.RequestException as e:
print(f"通信エラーが発生しました: {e}")—
4. クラウドアーキテクトとしての設計上の注意点
AWS環境でインフラを構築・運用するシニアエンジニアとして、このMSSとMTUの課題に直面したときに行うべきアプローチを整理しておきます。
1. VPNやDirect Connectを使用する場合の注意点:
VPCからインターネットへ直接抜ける場合だけでなく、AWS Client VPNやSite-to-Site VPNを介してオンプレミスや他社クラウドと通信する場合、カプセル化のオーバーヘッドによってパケットの最大サイズはさらに制約を受けます。VPNゲートウェイ周辺でのMSSクランピング設定（例: TCP MSS Adjustment）が有効になっているかを必ず確認してください。
2. セキュリティグループとICMPの扱い:
「うちはセキュアだから」といって、VPCのセキュリティグループやネットワークACL（NACL）で全てのICMPをバッサリとブロックしていませんか？ 前述の通り、Path MTU Discoveryを正常に機能させるためには、Destination Unreachable (Fragmentation Needed) のICMPメッセージを阻害しない配慮が必要です。すべてを塞ぐのではなく、必要なICMPタイプ（Type 3）を通す柔軟性が、結果的にシステムのレジリエンスを高めます。
3. コンテナ（ECS / EKS）の基盤設計:
Kubernetesクラスター（EKSなど）において、CNIプラグイン（AWS VPC CNI以外、例えばCalicoやCiliumなど）を採用している場合、ノード間のカプセル化方式によってポッド自体のMTUがデフォルトの9001から1400などに強制されるケースがあります。アプリケーションコンテナのビルドやランタイム環境で、ネットワークインターフェイスのMTUが意図通りに設定されているかを ip link show 等で定期的に監査する仕組みを持ちましょう。
—
おわりに
ネットワークのレイヤーで起きている現象は、普段アプリケーションを書いている時にはブラックボックスに見えがちです。しかし、ひとたびクラウドの境界線や異なるネットワークトポロジーが交差する点に差し掛かると、MTUとMSSという古くて新しい仕様が牙をむきます。
「なぜこのサイズを超えると通信できなくなるのか？」
その疑問にぶ当たったとき、パケットがジャンボフレームから標準フレームへ変換される瞬間と、TCPのハンドシェイクで行われる小さな数字の交渉（MSSクランピング）のドラマを思い出してください。
現場の泥臭いトラブルシューティングを楽しみながら、強靭なクラウドインフラを一緒に作り上げていきましょう。
コメント