オーバーレイネットワークと物理VLANの選定 — どの層でセグメントを分けるか

物理VLANとオーバーレイネットワークのどちらでセグメントを切るかは、スイッチ台数・クラウド連携の有無・コンテナワークロードの密度・運用チームの習熟度という4軸で決まる。本記事では各方式の設計上の差異、カプセル化プロトコルの選定判断、コンテナCNIの選定基準、MTUとルーティングまわりの落とし穴を体系的に整理し、現場の構築担当者が判断の根拠を持てるよう解説する。

物理VLANとソフトウェアオーバーレイのセグメント方式比較

VLANが適する構成の条件

物理VLANは802.1Q標準でベンダーを問わず動作し、管理対象スイッチが10台以下の中小規模環境では運用コストが最も低い選択肢である。VLAN IDは12ビット固定で最大4,094セグメントという上限があるが、テナント数が数十程度のオンプレミス環境でこの制約が問題になることはほとんどない。物理スイッチのACLやQoSをASICでハードウェア処理できるため、レイテンシが厳しいデータベースクラスタやストレージネットワークのセグメントには特に向いている。スイッチ単位で設定変更の影響範囲が明確で障害時の切り分けもシンプルに保てる点から、物理構成を長期間安定させたい環境では最初に検討すべき方式である。

オーバーレイが有効になる条件

VXLANをはじめとするオーバーレイ方式は、24ビットのVNI（VXLAN Network Identifier）により約1,677万セグメントを扱えるため、マルチテナントのクラウド基盤や数百台規模のコンテナ環境でのテナント分離に適している。物理スイッチのポート割り当てに依存せず、VMやコンテナの移動先でも同一セグメントを維持できるため、ライブマイグレーションを多用する仮想化基盤との親和性が高い。既存の物理VLANをアンダーレイとして維持しながらオーバーレイを上に重ねるハイブリッド構成も選択肢の一つで、段階的な移行が必要な現場では現実的な落としどころになる。クラウドとオンプレミスをつなぐ構成では、クラウド側のVPC構造とオンプレミスのVLANをオーバーレイで抽象化すると接続設計が整理しやすい。

選定の起点となる比較表

以下は両方式を主要な判断軸で並べたものである。設計レビューの冒頭にこの表を使い、どの軸で優先順位が高いかをチームで先に合意しておくと判断がぶれにくい。

判断軸	物理VLAN	オーバーレイ（VXLAN等）
セグメント数上限	最大4,094	約1,677万（24ビットVNI）
物理スイッチ依存	高い（ポート単位の設定が必要）	低い（アンダーレイはIPルーティングのみ）
テナント移動性	ポート追従が必要	VMやコンテナ移動でもセグメント維持可能
MTUオーバーヘッド	なし	VXLAN：約50バイト、Geneve：可変
パケット追跡の複雑さ	低い	カプセル化層の理解が必要
マルチクラウド連携	困難	適する（BGP EVPN等で延伸可能）
初期設計コスト	低い（L2スイッチ設定のみ）	高い（制御プレーン設計が必要）

VXLANとGeneve — カプセル化方式の選定判断軸

VXLANが事実上の標準となった背景

VXLANはRFC 7348として標準化されており、主要なハイパーバイザー・コンテナランタイム・物理スイッチのほぼすべてが対応済みである。LinuxカーネルはNICドライバーによってVXLANのオフロード（GSOやGROの処理）をハードウェアに委ねられるため、ソフトウェア処理によるCPU負荷を抑えつつ高スループットを維持しやすい。実績のある実装が多くベンダーサポートも厚いため、新規に設計するオーバーレイ基盤の起点として最初に検討すべき選択肢である。ヘッダー拡張性が限定的という特性があり、任意のメタデータをカプセル化ヘッダーに乗せたい場面では後述のGeneveが優位になる。

GeneveがVXLANより優位になる場面

GeneveはRFC 8926で標準化されたプロトコルで、TLV（Type-Length-Value）形式の可変長オプションフィールドにより任意のメタデータをカプセル化ヘッダーに付与できる。eBPFベースのネットワークポリシーエンジンを使うCiliumはGeneveをデフォルトカプセル化として採用しており、セキュリティポリシーのコンテキスト情報やフローのタグをヘッダーで伝搬させる設計に適している。将来的にネットワークポリシーの可視化・拡張を見込む構成ではGeneveを選ぶ方が設計自由度を保ちやすい。ただし一部の旧世代NICではGeneveのオフロードが効かないケースがあるため、本番投入前のスループット検証は省略すべきでない。

カプセル化方式の選定フロー

選定の判断順序は、まず使用するCNIやSDNコントローラーが何をデフォルトとしているかを確認するところから始まる。次に、既存ハードウェアのNICがGeneveのオフロードに対応しているかをデータシートで確認する。VXLANで十分な拡張性と実績が確保できるならそのまま採用し、eBPFポリシーやメタデータ拡張が将来的に必要な構成ならば最初からGeneveを選ぶ。途中での変更はトンネルの再構築とコンテナワークロードの再デプロイを伴うため、選定は構築フェーズの早い段階で確定させる必要がある。選定理由を設計ドキュメントに残しておくと、後任の担当者が判断根拠を追えるようになる。

コンテナネットワーキングプラグインをどう選ぶかの判断基準

CNI選定で最初に確認する3つの軸

KubernetesのCNIを選定する際、最初に見るべきは「ネットワークポリシーの実装方式」「オーバーレイの要否」「スループット要件」の3軸である。ネットワークポリシーをiptablesで実装するプラグインはノード数が増えるにつれてルールの肥大化がボトルネックになりやすく、100ノードを超える規模ではルール数が数千件を超えてパフォーマンス低下が観測された事例が複数報告されている。一方eBPFでポリシーを処理するプラグインはkube-proxyの置き換えまで視野に入るため、「どこまでの機能を最初から持つか」を設計フェーズで明確にしておく必要がある。スループット要件が厳しい場合はオーバーレイを使わないルーティングモードの採用も検討に値する。

Calico・Flannel・Ciliumの判断分岐

Flannelはシンプルなオーバーレイのみでネットワークポリシーを持たないため、ポリシーが不要な開発環境や上位レイヤーで分離を完結させる設計向きである。CalicoはBGPを使ったルーティングでオーバーレイを使わないルート広告も選択でき、物理スイッチとの統合が必要なオンプレミス環境に向いている。既存のBGPルーターとCalicoをピアリングさせてPodのルートを物理ネットワークに直接広告する構成は、余分なカプセル化を避けつつルーティング可視性を保てると評価する現場は多い。CiliumはeBPFベースで最も機能が豊富で、L7ポリシーやHubbleによるフロー可視化も備えているが、設定項目が多く運用習熟に時間がかかるため、チームの経験値に合わせて採用を判断する。

eBPFベースCNIへの移行判断

既存環境でFlannelやCalicoのiptablesモードを使っている場合、eBPFベースへの移行はCNIの完全入れ替えを意味する。移行中は既存Podのネットワーク設定が一時的に揺れるため、本番環境では段階的なノードドレインと再参加の手順が必要になる。工数の目安として、50ノード規模の検証環境なら2〜3日、本番移行計画の策定と検証を含めると2週間程度を見込む現場が多い。移行を決断する条件は、iptablesルールが数千行を超え始めた時点か、L7ポリシーやネットワーク可視化の要件が追加されたタイミングに絞るのが現実的である。移行コストを見越した上で、構築フェーズの早い段階からCiliumを選ぶという判断も十分合理性がある。

オーバーレイのオーバーヘッドを許容できる構成かのMTU設計

VXLANカプセル化で生じるオーバーヘッドの実際

VXLANは外側のイーサネットヘッダー14バイト、IPヘッダー20バイト、UDPヘッダー8バイト、VXLANヘッダー8バイトの合計50バイトをオーバーヘッドとして加算する。物理ネットワークのMTUが標準の1,500バイトの場合、内側ペイロードは最大1,450バイトに制限される。アプリケーションがMTUを意識せず1,500バイトのフレームを送出すると、VTEP側でフラグメント化または破棄が発生し、断続的なパフォーマンス低下の原因になる。ICMPのPath MTU Discoveryが正常に動作していれば軽減されるが、ファイアウォールやセキュリティグループがICMPを遮断していると検出できないまま障害が継続する。

ジャンボフレームを使う判断と設計上の留意点

アンダーレイ側でジャンボフレーム（MTU 9,000バイト）を有効にすれば、VXLANのオーバーヘッドを差し引いても内側MTUを1,500バイト以上に保てる。ただしジャンボフレームはスイッチ・NIC・ハイパーバイザー・コンテナランタイムの全レイヤーで設定を一致させる必要があり、1か所でも設定漏れがあると断片化が発生する。クラウドとオンプレミスのハイブリッド構成では、クラウドプロバイダーごとにサポートするMTU上限が異なるため、事前確認が必須である。ジャンボフレームを使わない場合は、コンテナのネットワークインタフェースMTUをオーバーレイのオーバーヘッド分だけ小さく設定するアプローチが一般的で、多くのCNIはこの値をdaemonが自動計算・設定する機能を持っている。

MTU設計のチェックリスト

本番投入前に以下の項目を確認しておくと、MTU起因のトラブルを未然に防ぎやすい。

• 物理スイッチのMTUがジャンボフレームを使う場合、全スイッチ・全ポートで統一されているか
• ハイパーバイザーの仮想スイッチ（vSwitch / OVS）のMTUが物理側に合わせて変更されているか
• CNI設定ファイルにMTU値が明示されているか（デフォルト値のまま放置していないか）
• ICMPのPath MTU DiscoveryパケットがファイアウォールやSGで遮断されていないか
• アンダーレイとオーバーレイのMTU差分がカプセル化オーバーヘッド以上確保されているか
• NFSやiSCSI等の大フレームアプリケーションのMTU要件がオーバーレイ設計に反映されているか

物理スイッチとSDNを混在させる構成での境界設計

アンダーレイとオーバーレイの責任分界を明確にする

物理スイッチとSDNコントローラーを組み合わせる構成では、アンダーレイは物理ネットワークチームが管理しオーバーレイはインフラエンジニアが管理するという責任分界を設計段階で明文化しておくことが重要である。障害時に両者の設定が相互に影響し合う場面で、どちらの層の問題かを切り分けられない状態が最も調査を長引かせる。アンダーレイにはIPルーティングとアドレス到達性のみを持たせ、テナント分離やポリシー制御はオーバーレイ層に集約するという原則を守ると、後の運用がシンプルになる。この原則から外れるのは、BGP EVPNを使ったハードウェアVTEP構成のような意図的な統合設計の場合に限るべきである。

BGP EVPNを使ったファブリック設計の選択点

BGP EVPNはVXLANの制御プレーンとして使うことで、MACアドレスのフラッディングを抑制しスケールアウトしやすいデータセンターファブリックを実現できる。物理スイッチがBGP EVPNに対応していれば、ハードウェアVTEPとして機能させてオーバーレイ処理をサーバーのCPUに頼らずに済む構成が可能である。一方でルートターゲットとルートディスティンギッシャーの設計ミスがVRF間ルーティングの意図しない漏れを引き起こすリスクがあり、設定の複雑さは物理スイッチのBGP設定の中でも上位に入る。採用するかどうかは既存スイッチのベンダーとファームウェアのサポート範囲を先に確認し、実績のある構成例を参照した上で判断するのが堅実である。

SDN導入時の物理スイッチへの要件追加

SDNコントローラーを導入する場合、物理スイッチにはOpenFlowサポートまたはVXLAN/EVPN対応が必要になる構成が多い。スイッチの買い替えが発生するかどうかは既存機材のファームウェアアップデートで対応できるかに依存するため、構築フェーズの初期に機材評価を行うべきである。30台以上のスイッチを含む大規模環境では一括アップグレードのリスクを考慮して段階的な対応計画が必要になる。また、SDNコントローラーがシングルポイントオブフェイラーにならないよう、コントローラー自体の冗長構成とフェイルオープン・フェイルクローズの動作方針も合わせて確認しておく必要がある。

トラブル時のパケット追跡をどの層で行うかの設計

オーバーレイ環境での可観測性の設計方針

オーバーレイネットワークでは、物理NICで観測されるトラフィックはカプセル化された状態であり、宛先IPと送信元IPはVTEP間のアンダーレイアドレスになっている。アプリケーション層で見えるIPとの対応関係を追うには、カプセル化を解除した内側のパケットを同時に観測できる仕組みが必要である。この観測ポイントをどこに置くかを設計段階で決めておかないと、障害発生時に「どのツールをどのノードで実行すれば良いか」という問題に行き詰まり、調査時間が数時間単位で伸びる。現場では事前の観測基盤がなかったために障害対応が翌日に持ち越された事例も報告されており、可観測性の設計は運用設計の一部として構築フェーズに含めるべきである。

eBPFとtcpdumpの使い分け判断

tcpdumpはカプセル化されたアンダーレイのパケットを捉えるには有効だが、内側のペイロードとの対応付けは手動のデコードが必要になる。一方eBPFを使ったツールはカプセル化前後の両方の視点でパケットを追跡でき、PodのnetnsとホストのネットワークスタックTを横断した観測が可能である。CiliumのHubbleのようにフローを可視化するUIを備えたツールでは、障害の切り分けをコマンド操作なしに進められるケースも増えている。手を動かす具体的な手順は実機演習の場に譲るとして、ここでは「観測レイヤーの選択をアーキテクチャ設計に含める」という判断を先行させることが重要である。

追跡設計をアーキテクチャ段階で確定させる理由

パケット追跡の方式を後から決めようとすると、使いたいツールが本番環境のカーネルバージョンや権限要件を満たさないという事態が起きやすい。特にeBPFベースのツールはカーネル5.4以降で機能が拡充されており、それより古い環境では利用できないコマンドや機能が存在する。観測基盤の要件はOSのベースイメージ選定と密接に関係するため、OS選定・カーネルバージョン固定・権限設計の段階でセットに議論しておく必要がある。セキュリティ要件でコンテナのプリビレッジドモードを禁止している環境では、eBPFツールの実行権限設計が特に重要になり、後から変更しようとすると運用ポリシーの見直しを伴う場合がある。

落とし穴 — オーバーレイ導入で詰まりやすいMTUとルーティングの問題

MTUミスマッチによる断続的パケットロスの典型パターン

オーバーレイ導入後に最もよく報告される問題は、小さいパケットは通るが大きいパケットだけ落ちるという断続的なパケットロスである。pingの疎通は正常でHTTPの小さいレスポンスは返ってくるが、大きなファイル転送やDBの結果セットが途中で切れるという症状が典型的で、ネットワーク障害と判断しにくい点が厄介である。原因の大半はコンテナ側インタフェースのMTUが1,500のままでVXLANのオーバーヘッドを考慮していない構成に起因する。あるチームでは本番投入後に特定アプリケーションだけスループットが出ないという問題の原因特定に丸1日を要したと報告されており、MTU設定確認を初期チェックリストの先頭に置くことで防げるケースである。

オーバーレイルーティングの非対称経路問題

コンテナクラスタでIngressからPodへの行きの経路と、PodからIngressへの帰りの経路が異なるノードを通る非対称ルーティングは、ステートフルなファイアウォールやconntrackのセッション管理を混乱させる原因になる。CalicoのBGPモードや複数のネットワークインタフェースを持つノードで特に発生しやすく、SYN-ACKが破棄されてTCPセッションが成立しないパターンが典型的である。設計段階でRPF（Reverse Path Forwarding）チェックの要否とconntrackの設定方針を決めておくことで予防できる。マルチホームノードを使う構成では、どのインタフェースからデフォルトルートを選ぶかのポリシーを明示的に設定することが必要である。

アンダーレイ設計の不備が顕在化するタイミング

オーバーレイが正常に動作しているように見えても、アンダーレイのルーティング設計の甘さは後から顕在化することがある。典型的なのはVTEP間の到達性がシングルパスで設計されており、スイッチや回線の障害時にフェイルオーバーが機能しないケースである。ECMPによるマルチパス設計や、BFD（Bidirectional Forwarding Detection）によるリンク障害の高速検知をアンダーレイに含めるかどうかは、可用性要件と合わせて構築フェーズの早期に決定する必要がある。アンダーレイが堅牢でなければオーバーレイの冗長設計は意味をなさないという原則は、設計レビューで繰り返し確認すべき判断軸である。