VPCのIP枯渇という「静かなる危機」：セカンダリCIDR設計の深淵とパケットの流儀
クラウドアーキテクトとして多くのモダンな基盤を見てきたが、最も頭を悩ませるのは「設計初期のIPアドレス設計の甘さ」である。特にコンテナ時代の今、KubernetesのPodネットワークにIPを食い尽くされ、夜中にアラートが鳴り響く。
「VPCにセカンダリCIDRを追加すればいいじゃないか」――そう安易に考える前に、一度立ち止まってほしい。IPの拡張は単なるネットワークの継ぎ足しではなく、パケットのルーティング制御、ひいてはカーネルスタックの挙動にまで影響を及ぼす重大な操作なのだ。
本稿では、VPCにおけるマルチCIDR設計の深淵と、そこで発生する「目に見えないボトルネック」を排除するための技術論を展開する。
1. セカンダリCIDRが突きつける「ルーティングの現実」
AWSやGCPでセカンダリCIDRを割り当てた瞬間、パケットのルーティングテーブルには新たな「経路」が追加される。ここで重要なのは、「メインCIDRとセカンダリCIDRは論理的には対等だが、物理的な配線は必ずしも最適化されていない」という事実だ。
特に、オンプレミス環境からDirect ConnectやVPN経由で接続している場合、ルーター側のルート集約（Route Aggregation）を忘れると、セカンダリCIDRのパケットが正しくルートされず、ブラックホールに消える。
パケットの追跡：ルーティングの最適化
セカンダリCIDRを導入する際、トラフィックを分離させるための「サブネットの棲み分け」は必須だ。例えば、アプリケーション層とデータベース層を異なるCIDRブロックに配置する場合、以下のカーネルパラメータを意識せざるを得ない。
# TCPウィンドウのスケーリングを有効化し、高RTT環境でのスループットを維持する
# セカンダリCIDR経由の通信が増えると、セッション確立時の遅延がボトルネックになりやすい
sysctl -w net.ipv4.tcp_window_scaling=1
# パケットの再送制御を最適化する（高負荷時のパケットドロップに備える）
sysctl -w net.ipv4.tcp_rfc1337=12. トランスポート層の最適化とRTTの削減
ネットワーク範囲を広げると、必然的に物理的なホップ数や論理的なルーティングオーバーヘッドが増大し、RTT（Round Trip Time）が悪化する。特にセカンダリCIDRへPodをデプロイした場合、Service（ClusterIP）のトラフィックがノードを跨ぐ際のオーバーヘッドは、レイテンシに直結する。
ここで考慮すべきは、TCPバッファの動的チューニングだ。
# Pythonのソケット設定例：バッファサイズを調整してセカンダリCIDR間の長距離通信を高速化
import socket
def configure_socket(sock):
# 送受信バッファを動的に設定し、輻輳制御アルゴリズムの効率を高める
# BDP (Bandwidth Delay Product) を考慮したチューニングが必要
sock.setsockopt(socket.SOL_SOCKET, socket.SO_SNDBUF, 262144)
sock.setsockopt(socket.SOL_SOCKET, socket.SO_RCVBUF, 262144)
# TCP_NODELAYを有効にして、小さなパケットの遅延を抑える
sock.setsockopt(socket.IPPROTO_TCP, socket.TCP_NODELAY, 1)3. セキュリティとヘッダー圧縮：TLSハンドシェイクの罠
セカンダリCIDRに配置されたサービスが外部と通信する際、TLSハンドシェイクのオーバーヘッドは無視できない。特に複数のCIDRを跨ぐ通信では、パケットのフラグメンテーション（断片化）が発生しやすく、MTU（Maximum Transmission Unit）サイズの不一致がセキュリティレイヤーのハンドシェイクを阻害することがある。
回避策：MSSクランピング
VPNやDirect Connect環境でセカンダリCIDRを使う場合、パケットサイズが1500バイトを超えると即座にドロップされる可能性がある。Linuxノードで以下の設定を行い、MSS（Maximum Segment Size）を強制的にクランプすることで、ハンドシェイクの失敗を防ぐのが現場の定石だ。
# iptablesを用いてMSSを調整し、セカンダリCIDRからのパケット断片化を防ぐ
iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1360*※注：1360という数値は、カプセル化オーバーヘッドを考慮した安全な値だ。*
4. なぜ「設計」がすべてなのか
最後に、インフラアーキテクトとして強調したい。セカンダリCIDRの追加は「対症療法」であり、本質的な解決策ではない。
1. IPアドレスの枯渇は、設計の初期段階でのスケーラビリティ不足の露呈である。
2. マルチCIDRはルーティングテーブルの肥大化を招き、トラブルシューティングを著しく困難にする。
3. セキュリティグループの適用範囲（スコープ）が広がり、最小権限の原則が崩れやすい。
もしセカンダリCIDRを導入せざるを得ない状況に陥ったなら、必ず「どのCIDRがどのサービス群を収容し、どの程度のトラフィックが発生するか」を可視化すること。特にKubernetes環境であれば、kube-proxyのモード（iptables vs IPVS）を確認し、セカンダリCIDR追加後のルール更新がノードのCPU負荷を跳ね上げないよう、事前の負荷検証を怠ってはならない。
ネットワークは生き物だ。CIDRという枠組みを変えることは、その生き物の血管を増設するようなもの。血流（パケット）がスムーズに流れるか、あるいは血栓（輻輳やドロップ）が詰まるかは、すべてあなたの設計の緻密さにかかっている。
次にネットワークを設計する際は、今のIP枯渇の教訓を忘れず、より広大なアドレス空間の確保（あるいはIPv6導入の検討）から始めてみてほしい。それが、プロのエンジニアとしての矜持である。
コメント