ピアリングの迷宮：VPC推移的ルーティングの制約と、その先にある「真の広域ネットワーク設計」
クラウドの設計において、VPCピアリングは最も直感的で安価な接続手段だ。しかし、この「単純さ」は、往々にしてアーキテクトを甘美な罠へと誘う。特に、「VPC AとVPC Bがつながり、VPC BとVPC Cがつながっているのだから、VPC AからVPC Cへもパケットが届くはずだ」という幻想――すなわち「推移的ルーティング（Transitive Routing）の欠如」という制約を軽視した結果、本番環境で深刻なパケットロスや接続断に直面するケースを、私はこれまで幾度となく見てきた。
本稿では、VPCピアリングの物理的・論理的挙動を紐解き、この制約を回避するための高度なネットワーク戦略を、カーネルレベルの知見を交えて解説する。
—
なぜパケットは「隣の隣」へ届かないのか
VPCピアリングは、AWSやGCPといったクラウドプロバイダーのバックボーンネットワーク上で、プライベートIP空間を直接接続する技術だ。しかし、これらはあくまで「ポイント・ツー・ポイント」の論理リンクに過ぎない。
プロバイダー側のルーター（仮想化されたSDNコントローラー）は、ピアリングされた接続に対して「宛先IPがこのVPCレンジ内であれば、あちらのピアリングゲートウェイへ転送せよ」という単純な転送ルールを適用する。ここで重要なのは、「転送されたパケットを、さらに別のピアリング先へ転送するロジック（推移的ルーティング）が意図的に無効化されている」ということだ。
もしこれを許してしまうと、ループ構成によるブロードキャストストームや、意図しない経路でのパケット流出といった、ネットワークの整合性を壊す「カオス」が瞬く間に全リージョンへ拡散してしまうからだ。クラウドの堅牢性は、この「制約」によって担保されている。
—
メッシュ構造のジレンマとRTT最適化
VPCをフルメッシュで接続すれば推移性の問題は解決するが、管理負荷は指数関数的に増大する。さらに、ネットワークのパフォーマンスを最適化する上で避けて通れないのが、RTT（Round Trip Time）とTCPウィンドウサイズのチューニングだ。
複数のVPCを跨ぐ通信では、物理的な物理距離や論理的なホップ数により、わずかながらレイテンシが増大する。特にTLSハンドシェイクにおいては、RTTの増大は即座にユーザー体感速度の低下に直結する。
パフォーマンスチューニング：TCPバッファとウィンドウサイズ
広帯域かつ高レイテンシな環境では、デフォルトのTCP設定ではスループットが頭打ちになる。Linuxカーネルレベルで以下のチューニングを適用し、BDP（Bandwidth Delay Product）を最適化することを推奨する。
# /etc/sysctl.conf でのTCP最適化設定例
# BDPを考慮した最大受信ウィンドウサイズの設定 (例: 100Mbps/10msの場合)
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216
# 遅延変動に強い選択的確認応答 (SACK) の有効化
net.ipv4.tcp_sack = 1
# 輻輳制御アルゴリズムをBBRへ変更 (高レイテンシ・パケットロス環境に最適)
net.core.default_qdisc = fq
net.ipv4.tcp_congestion_control = bbr—
セキュリティの深層：ヘッダー圧縮と中間者攻撃の防御
VPCピアリング内を流れるトラフィックは、物理的にはクラウドプロバイダーの隔離されたネットワークを通るが、論理的には「信頼できるネットワーク」として扱われるべきではない。「Zero Trust Networking」の原則に従い、VPC間通信であっても必ずTLS 1.3による相互認証（mTLS）を適用すべきだ。
また、HTTP/2やgRPCを利用する場合、HPACKによるヘッダー圧縮が効く。しかし、極めて高いスループットを求める場合は、パケットヘッダーの肥大化を防ぐために、MTUサイズの調整が不可欠だ。
- MTUの不一致：VPCピアリングにおいてMTUが1500を超えると、途中で断片化（Fragment）が発生し、CPUリソースの浪費とパフォーマンス低下を招く。可能であれば、各インスタンスで
MTU 1460程度に固定し、オーバヘッドを抑制せよ。
—
推移的ルーティングを回避するモダンな解法：Transit Gatewayの活用
「フルメッシュは無理、しかし推移的ルーティングは必要」というジレンマに陥ったとき、我々SREが取るべき解は、Transit Gateway (TGW) や GCP Network Connectivity Center の採用だ。
これらは、ハブ・アンド・スポーク型のトポロジーを提供し、ルーティングテーブルを一元管理する。
構成上の注意点
TGWを導入しても、各VPCのルートテーブル設定には細心の注意が必要だ。特定の宛先IPレンジに対して tgw-xxxxxx をネクストホップとして正しく指定しなければ、パケットは迷子になる。
# TerraformによるTGWルートテーブルの例
resource "aws_ec2_transit_gateway_route" "vpc_a_to_c" {
destination_cidr_block = "10.3.0.0/16" # VPC Cのレンジ
transit_gateway_attachment_id = aws_ec2_transit_gateway_vpc_attachment.vpc_c.id
transit_gateway_route_table_id = aws_ec2_transit_gateway_route_table.main.id
# 意味：VPC AからのパケットをVPC Cのネットワークインターフェースへ転送する
}—
結論：ネットワークは「動く」生き物である
クラウドのネットワーク設計において、「設定して終わり」という日は来ない。パケットの挙動を可視化し、VPC Flow Logsを解析し、RTTの推移を監視する。そして何より、VPCピアリングが持つ「非推移的」という制約を、ネットワークを堅牢に保つための「境界線」として愛することだ。
もし、あなたが今、複雑なVPC網で頭を抱えているなら、まずはそのネットワーク図を捨て、パケットがどのゲートウェイを通り、どのルートテーブルで判断を下しているのか、その「論理の道筋」を追ってみてほしい。真実のボトルネックは、大抵の場合、設定ファイルの中ではなく、その論理構造の歪みに潜んでいるのだから。
コメント