VPCピアリングの深淵：パケットが迷わないための「規律」と「最適化」
クラウドアーキテクトとして数多の環境を見てきましたが、いまだに現場で後を絶たないのが「VPCピアリングにおけるルーティング設計の甘さ」です。AWSのVPCピアリングは一見、設定画面でポチポチと接続を許可してルートテーブルを更新するだけの単純なものに見えます。しかし、その裏側で蠢くパケットの挙動や、非推移的ルーティングという制約を理解していないと、大規模なシステム構成において取り返しのつかない技術負債を抱えることになります。
今日は、パケットがVPCの境界を越える瞬間の挙動から、パフォーマンスを極限まで絞り出すチューニングまで、泥臭い現場の知見を共有しましょう。
1. CIDR重複という「不可逆的な罪」
VPCピアリングの前提として、AWSは厳格に「CIDRブロックの重複を禁止」しています。これは単なる規約ではありません。VPC内のIPルーティングテーブルが「宛先IPの最長一致検索（Longest Prefix Match）」を行う際、ルーティングの曖昧さを排除するための物理的な制約です。
もし、意図せずCIDRを重複させてピアリングを試みると、AWSのコントロールプレーンは即座に拒否します。これは、ルーティングループやパケットの誤配送を防ぐための安全装置です。
なぜこれが「設計の設計」を要求するのか
多くのスタートアップが陥る罠が、初期構築時に 10.0.0.0/16 を安易に採用することです。将来的に他社との合併や、新規プロダクトのVPCと統合する際、この広大なCIDRが「動かせない岩」となり、ピアリングを物理的に不可能にします。
教訓: どんなに小規模な環境であっても、将来のスケールを想定し、CIDRブロックを詳細に設計（サブネット分割の戦略的配置）してください。
2. 非推移的ルーティング（Non-transitive Routing）の悪魔
ここが多くのエンジニアを悩ませるポイントです。「VPC AとVPC Bが繋がっている。VPC BとVPC Cが繋がっている。ならばAからCへは行けるはずだろう？」――この推論は、VPCピアリングにおいては完全な誤りです。
VPCピアリングは「ゲートウェイ・トランスジット」を許可しません。パケットはピアリングされたVPCの境界で終端し、そこから先へは転送されない仕様です。もしこれが必要なら、迷わず AWS Transit Gateway を導入してください。
3. パフォーマンスとセキュリティの最適化：パケットの旅を速くする
ピアリング越しに通信を行う際、最も重要なのは「いかにRTT（Round Trip Time）を削減し、スループットを最大化するか」です。
TCPバッファチューニングの極意
VPC間の通信であっても、リージョンを跨げば物理的な距離が生じます。LinuxカーネルのTCPバッファを最適化し、BDP（Bandwidth Delay Product）を考慮した設定を適用しましょう。
# sysctl.confへの設定例
# 高速ネットワーク環境でのスループット向上のためのバッファ拡張
# 受信バッファの最小値、デフォルト値、最大値を設定
net.ipv4.tcp_rmem = 4096 87380 16777216
# 送信バッファの最小値、デフォルト値、最大値を設定
net.ipv4.tcp_wmem = 4096 65536 16777216
# 負荷の高い環境でTCPウィンドウサイズを柔軟に調整
net.ipv4.tcp_window_scaling = 1TLSハンドシェイクの最適化
ピアリング越しにマイクロサービス間通信を行う場合、TLSハンドシェイクがRTTを食いつぶします。
- TLS 1.3の採用: 0-RTT（Zero Round Trip Time）Resumptionを活用し、ハンドシェイクの往復回数を削減してください。
- コネクションプーリング:
Keep-Aliveを適切に設定し、TCPの3ウェイ・ハンドシェイクを極力繰り返さない設計が不可欠です。
4. 現場で役立つトラブルシューティング：パケットの「今」を知る
「繋がらない」という叫び声がSlackに届いたとき、まずやるべきは VPC Flow Logs の確認ですが、それだけでは足りません。ENI（Elastic Network Interface）レベルでのパケットドロップを疑うべきです。
もし、特定の通信が特定のインスタンス間でのみ頻発するなら、セキュリティグループの egress ルールだけでなく、ネットワークACL（NACL）のステートフル／ステートレスの特性を再確認してください。NACLは戻りパケットの制御を明示的に記述する必要があるため、ここでパケットが消失しているケースは非常に多いのです。
パケットキャプチャの推奨
どうしても原因が特定できない場合、tcpdump を使って該当インスタンスのインターフェースを覗きます。
# ピアリング先のVPC CIDRに対するパケットの到達を確認
# インターフェースをeth0に絞り、特定の宛先IPでフィルタリング
sudo tcpdump -i eth0 host 172.16.x.x -nn -vv最後に：アーキテクトとしての矜持
VPCピアリングは強力ですが、その制約を知り尽くした上で「設計しない」という選択肢を持つこともプロの技術です。現在では Transit Gateway や PrivateLink があり、よりセキュアで管理が容易な選択肢が存在します。
インフラは「繋ぐ」ことよりも、「どう繋ぐか」「どう分離するか」にこそ設計思想が宿ります。パケットが迷いなく宛先に届き、かつセキュリティの境界が守られている状態。それこそが、SREとして私たちが追い求める「美しいアーキテクチャ」なのです。
次にVPCのルートテーブルを開くとき、その向こう側にある数多のパケットの旅路を想像してみてください。そうすれば、自ずと正しい設計が見えてくるはずです。
コメント