IPアドレス設計という「終わらない戦い」：VPC設計におけるCIDR選定の深淵
クラウドインフラの設計において、最初に直面し、かつ最も取り返しがつかない負債になり得るのが「CIDR設計」だ。
「とりあえず /16 を割り当てておけば大丈夫だろう」という安易な見積もりは、将来のマルチクラウド接続やオンプレミスとのVPN接続において、必ずと言っていいほど「IPアドレスの重複」という悪夢を連れてくる。本稿では、単なるIP管理を超えた、カーネルレベルのパケット挙動やRTT、さらにはセキュリティ設計にまで踏み込んだCIDR戦略を論じる。
—
1. CIDR選定の哲学：なぜ「広すぎる」のは罪なのか
VPCのCIDR設計において、多くのアーキテクトが陥るのが「余剰IPアドレスの罠」だ。特にAWSのような環境では、サブネットを小さく切っても直接的なコストは発生しない。しかし、ルーティングテーブルの複雑性や、後のIP枯渇を見越した拡張性は、物理的な境界以上に論理的な設計が求められる。
サブネット分割の戦略的アプローチ
私の経験上、VPC全体を /16 で設計する際、サブネットを /24 単位で固定するのは避けたい。可用性ゾーン（AZ）ごとに冗長化を前提とすると、以下の構成が黄金律となる。
- Public Subnet: ロードバランサーやNAT Gateway用。
/26程度で十分。 - Private Subnet (Application): コンテナ（EKS/GKE）が密に配置される。
/22〜/23で余裕を持たせ、IP枯渇によるデプロイ失敗を防ぐ。 - Private Subnet (Data/DB): セキュリティグループによる厳格な隔離。
/28程度で管理し、攻撃対象領域を最小化する。
—
2. パケットの深層：TCPバッファとMTU最適化
IPアドレスの設計は、単なるラベル付与ではない。サブネット境界を越える際、パケットはルーター（仮想ルーター）を通過する。この時、最もパフォーマンスに影響を与えるのが TCP Window Size と MTU の不整合だ。
特にコンテナネットワーク（CNI）を利用する場合、カプセル化（VXLANやGeneve）によるオーバーヘッドが発生する。デフォルトの 1500 bytes のMTUでは、ヘッダー分（50〜100 bytes程度）が差し引かれ、断片化（Fragmentation）が頻発する。これがRTT増大の主因だ。
LinuxカーネルにおけるTCPチューニング例
以下の設定は、高負荷なマイクロサービス間通信において遅延を劇的に改善する可能性がある。
# TCPウィンドウサイズを拡大し、高帯域・高遅延ネットワークでのスループットを向上させる
sysctl -w net.ipv4.tcp_rmem="4096 87380 16777216"
sysctl -w net.ipv4.tcp_wmem="4096 65536 16777216"
# コンテナノード間通信でのコネクション再利用を最適化
sysctl -w net.ipv4.tcp_tw_reuse=1—
3. セキュリティとトランスポート層の最適化
サブネットの境界設計は、セキュリティグループやNACLの適用範囲に直結する。特に TLS ハンドシェイク の最適化を考えるなら、TLS 1.3 への強制移行と 0-RTT（Zero Round Trip Time）の活用を検討すべきだ。
しかし、0-RTT はリプレイ攻撃のリスクを孕む。これを防ぐためには、アプリケーションレイヤーでの冪等性確保が不可欠だ。
HTTPヘッダー圧縮とセキュリティヘッダー
ネットワーク層でCIDRを適切に分けることは、インバウンド・アウトバウンドのトラフィックを可視化しやすくする。セキュリティを高めるためのヘッダー付与例を以下に示す。
# Nginx等のリバースプロキシで設定する推奨ヘッダー
add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always;
add_header X-Content-Type-Options nosniff;
add_header X-Frame-Options DENY;—
4. 拡張性を担保するためのベストプラクティス
最後に、数年後の「未来の自分」を助けるための設計指針を共有する。
1. RFC 1918 以外の利用を考慮する: 10.0.0.0/8 は既に枯渇しがちだ。可能であれば 100.64.0.0/10（Carrier-Grade NAT）の範囲も検討対象に入れ、大規模なプライベートネットワークを構築せよ。
2. IPAM（IP Address Management）の導入: 手動のExcel管理は自殺行為だ。AWS IPAMやTerraformの cidrsubnet 関数を活用し、宣言的に管理せよ。
# Terraformでのサブネット設計例
# 複雑な計算を関数に任せることで、将来的なCIDR拡張が容易になる
resource "aws_subnet" "app" {
vpc_id = aws_vpc.main.id
cidr_block = cidrsubnet(var.vpc_cidr, 4, 1) # /16を/20に分割
availability_zone = "ap-northeast-1a"
}結びに代えて
ネットワーク設計は、クラウドの「骨格」だ。ここが歪んでいれば、どれほど優秀なアプリケーションを載せても、レイテンシという名の癌に蝕まれることになる。
パケットがどのルートを通り、どのヘッダーが付与され、カーネルがどう処理しているか。その一挙手一投足に想像を巡らせることこそが、真のSREへの第一歩である。さあ、今すぐあなたのVPCのCIDR設計を見直し、無駄なオーバーヘッドを削ぎ落とそうではないか。
コメント