photoncloud-monorepo/docs/por/T015-overlay-networking/research-summary.md

Overlay Networking Research Summary

Date: 2025-12-08
Task: T015 S1
Status: Research Complete

Executive Summary

マルチテナントVMネットワーク分離のためのオーバーレイネットワーキングソリューションの調査結果。OVN、Cilium、Calico、カスタムeBPFソリューションを評価し、OVNを推奨する。

1. OVN (Open Virtual Network)

アーキテクチャ

• ベース: OpenStack Neutronのネットワーク抽象化をOpen vSwitch (OVS)上に実装
• コンポーネント:
  • ovn-northd: 論理ネットワーク定義を物理フローに変換
  • ovn-controller: 各ホストでOVSフローを管理
  • ovsdb-server: ネットワーク状態の分散データベース
  • ovn-nb (Northbound DB): 論理ネットワーク定義
  • ovn-sb (Southbound DB): 物理フロー状態

機能

• ✅ マルチテナント分離（VXLAN/GRE/Geneveトンネル）
• ✅ 分散ルーティング（L3 forwarding）
• ✅ 分散ロードバランシング（L4）
• ✅ セキュリティグループ（ACL）
• ✅ DHCP/DNS統合
• ✅ NAT（SNAT/DNAT）
• ✅ 品質保証（QoS）

複雑さ

• 高: OVSDB、OVNコントローラー、分散状態管理が必要
• 学習曲線: 中〜高（OVS/OVNの概念理解が必要）
• 運用: 中（成熟したツールチェーンあり）

統合の容易さ

• PlasmaVMC統合: OVN Northbound API（REST/gRPC）経由で論理スイッチ/ルーター/ポートを作成
• 既存ツール: ovn-nbctl、ovn-sbctlでデバッグ可能
• ドキュメント: 豊富（OpenStack/OVN公式ドキュメント）

パフォーマンス

• オーバーヘッド: VXLANカプセル化による約50バイト
• スループット: 10Gbps以上（ハードウェアオフロード対応）
• レイテンシ: マイクロ秒単位（カーネル空間実装）

2. Cilium

アーキテクチャ

• ベース: eBPF（Extended Berkeley Packet Filter）を使用したカーネル空間ネットワーキング
• コンポーネント:
  • cilium-agent: eBPFプログラムの管理
  • cilium-operator: サービスディスカバリー、IPAM
  • etcdまたはKubernetes API: 状態管理

機能

• ✅ マルチテナント分離（VXLAN/Geneve、またはネイティブルーティング）
• ✅ L3/L4/L7ポリシー（eBPFベース）
• ✅ 分散ロードバランシング
• ✅ 可観測性（Prometheusメトリクス、Hubble）
• ✅ セキュリティ（ネットワークポリシー、mTLS）

複雑さ

• 中: eBPFの理解が必要だが、Kubernetes統合が成熟
• 学習曲線: 中（Kubernetes経験があれば容易）
• 運用: 低〜中（Kubernetesネイティブ）

統合の容易さ

• PlasmaVMC統合: Kubernetes API経由または直接Cilium API使用
• 既存ツール: cilium CLI、Hubble UI
• ドキュメント: 豊富（Kubernetes中心）

パフォーマンス

• オーバーヘッド: 最小（カーネル空間、eBPF JIT）
• スループット: 非常に高い（ハードウェアオフロード対応）
• レイテンシ: ナノ秒単位（カーネル空間）

制約

• Kubernetes依存: Kubernetes環境での使用が前提（VM直接管理は非標準）
• VMサポート: 限定的（主にコンテナ向け）

3. Calico

アーキテクチャ

• ベース: BGP（Border Gateway Protocol）ベースのルーティング
• コンポーネント:
  • calico-node: BGPピア、ルーティングルール
  • calico-kube-controllers: Kubernetes統合
  • etcdまたはKubernetes API: 状態管理

機能

• ✅ マルチテナント分離（BGPルーティング、VXLANオプション）
• ✅ ネットワークポリシー（iptables/Windows HNS）
• ✅ IPAM
• ✅ BGP Anycast（L4ロードバランシングに有用）

複雑さ

• 低〜中: BGPの理解が必要だが、シンプルなアーキテクチャ
• 学習曲線: 低（BGP知識があれば容易）
• 運用: 低（シンプルな構成）

統合の容易さ

• PlasmaVMC統合: Calico API経由またはBGP直接設定
• 既存ツール: calicoctl
• ドキュメント: 豊富

パフォーマンス

• オーバーヘッド: 低（ネイティブルーティング）
• スループット: 高い（ハードウェアルーティング対応）
• レイテンシ: 低（ネイティブルーティング）

制約

• BGP要件: BGP対応ルーター/スイッチが必要（データセンター環境）
• VMサポート: Kubernetes統合が主（VM直接管理は限定的）

4. カスタムeBPFソリューション

アーキテクチャ

• ベース: 独自のeBPFプログラムとコントロールプレーン
• コンポーネント: 独自実装

機能

• ✅ 完全なカスタマイズ性
• ✅ 最適化されたパフォーマンス
• ❌ 開発・保守コストが高い

複雑さ

• 非常に高: eBPFプログラミング、カーネル開発、分散システム設計が必要
• 学習曲線: 非常に高
• 運用: 高（独自実装の運用負荷）

統合の容易さ

• PlasmaVMC統合: 完全にカスタマイズ可能
• 既存ツール: 独自開発が必要
• ドキュメント: 独自作成が必要

パフォーマンス

• オーバーヘッド: 最小（最適化可能）
• スループット: 最高（最適化可能）
• レイテンシ: 最小（最適化可能）

制約

• 開発時間: 数ヶ月〜数年
• リスク: バグ、セキュリティホール、保守負荷

5. 比較表

項目	OVN	Cilium	Calico	カスタムeBPF
成熟度	高	高	高	低
VMサポート	✅ 優秀	⚠️ 限定的	⚠️ 限定的	✅ カスタマイズ可能
複雑さ	高	中	低〜中	非常に高
パフォーマンス	高	非常に高	高	最高（最適化後）
統合容易さ	中	高（K8s）	中	低（開発必要）
ドキュメント	豊富	豊富	豊富	なし
運用負荷	中	低〜中	低	高
開発時間	短（統合のみ）	短（K8s統合）	短（統合のみ）	長（開発必要）

6. 推奨: OVN

推奨理由

1. VMファースト設計: OVNはVM/コンテナ両方をサポートし、PlasmaVMCのVM中心アーキテクチャに最適
2. 成熟したマルチテナント分離: OpenStackでの実績があり、本番環境での検証済み
3. 豊富な機能: セキュリティグループ、NAT、ロードバランシング、QoSなど必要な機能が揃っている
4. 明確なAPI: OVN Northbound APIで論理ネットワークを定義でき、PlasmaVMCとの統合が容易
5. デバッグ容易性: ovn-nbctl、ovn-sbctlなどのツールでトラブルシューティングが可能
6. 将来の拡張性: プラガブルバックエンド設計により、将来的にCilium/eBPFへの移行も可能

リスクと軽減策

リスク1: OVNの複雑さ

• 軽減策: OVN Northbound APIを抽象化したシンプルなAPIレイヤーを提供
• 軽減策: よく使う操作（ネットワーク作成、ポート追加）を簡素化

リスク2: OVSDBの運用負荷

• 軽減策: OVSDBクラスタリングのベストプラクティスに従う
• 軽減策: 監視とヘルスチェックを実装

リスク3: パフォーマンス懸念

• 軽減策: ハードウェアオフロード（DPDK、SR-IOV）を検討
• 軽減策: 必要に応じて将来的にCilium/eBPFへの移行パスを残す

代替案の検討タイミング

以下の場合、代替案を検討：

1. パフォーマンスボトルネック: OVNで解決できない性能問題が発生
2. 運用複雑さ: OVNの運用負荷が許容範囲を超える
3. 新機能要求: OVNで実現できない機能が必要

7. 結論

推奨: OVNを採用

• マルチテナントVMネットワーク分離の要件を満たす
• 成熟したソリューションでリスクが低い
• PlasmaVMCとの統合が比較的容易
• 将来の最適化（eBPF移行など）の余地を残す

次のステップ: S2（テナントネットワークモデル設計）に進む