パブリッククラウドで NFV は成立するのか – 仮想アプライアンスを置く前に考えること

パブリッククラウドで NFV 型の Firewall、Router、VPN、IDS/IPS を動かせるかどうかは、VM が起動できるか、Marketplace に仮想アプライアンスがあるかだけでは決まりません。

成立条件を決めるのは、VPC の到達性モデル、アンダーレイを制御できないこと、EC2 の帯域と flow 制約、Gateway Load Balancer の使い方、Direct Connect / VPN の責任分界、障害時にどこまで観測できるかです。

結論として、パブリッククラウド上で NFV 型 NF は成立する場合があります。ただし、オンプレミス NFV をそのまま移植するのではなく、クラウドの制約に合わせてネットワーク機能の責務を再設計できる場合に限られます。

この記事の結論

NFV 型 NF とは何を指すのか

ここでいう NFV 型 NF は、Firewall、Router、VPN、IDS/IPS、Proxy、Load Balancer のようなネットワーク機能を、専用装置ではなく VM や仮想アプライアンスとして動かす考え方です。

オンプレミス NFV では、サーバー、NIC、switch、routing、VLAN、MTU、物理配線、冗長構成を自分たちで制御しやすいです。一方、パブリッククラウドでは、VPC や managed network service の上に NF を置くため、制御できる範囲が変わります。

アンダーレイとオーバーレイを分ける

クラウドでは、利用者が扱う VPC、subnet、route table、security group、load balancer は、クラウド事業者の underlay network の上に載っています。利用者は overlay 側を設定できますが、物理 switch や underlay routing を直接制御するわけではありません。

NFV 型 NF を置くときは、この境界を見誤らないことが重要です。仮想アプライアンスが packet を処理できても、その前後の経路を VPC の機能でどう通すか、非対称経路をどう防ぐか、障害時にどこを観測できるかを別に考える必要があります。

成立性を決めるのは VM の有無ではない

Marketplace に仮想アプライアンスがあることは、NFV が成立することの一部条件でしかありません。重要なのは、そのアプライアンスに traffic を正しく入れ、正しく出し、障害時に切り戻せることです。

• traffic をどの route table で NF に向けるのか
• 戻り traffic が同じ NF を通るのか
• multi-AZ 構成で stateful traffic をどう扱うのか
• scale out 時に session affinity や flow stickiness をどう扱うのか
• 障害時に cloud 側と appliance 側のどちらを疑うのか

EC2 の帯域は物理ポートの感覚で読まない

クラウド VM のネットワーク性能は、物理 NIC の 10G / 25G / 100G port を占有する感覚とは違います。instance type ごとの baseline、burst、flow 数、packet rate、ENI、placement、Nitro 世代などの条件で見ます。

NFV 型 NF は throughput だけでなく、packet rate、small packet、session 数、暗号処理、inspection、logging の影響を受けます。平均帯域が足りていても、flow 制約や packet rate で詰まる場合があります。

Gateway Load Balancer は NFV の万能解ではない

Gateway Load Balancer は、AWS 上で network appliance を挿入しやすくする重要な仕組みです。GENEVE encapsulation により、traffic を appliance fleet へ通しやすくできます。

ただし、GWLB を使えば NFV がすべて成立するわけではありません。stateful appliance の設計、flow stickiness、multi-AZ、inspection 対象、fail open / fail close、ログ取得、運用責任は別に決める必要があります。

仮想アプライアンスを置くべき場面

• 既存のセキュリティ policy や inspection engine をクラウドでも使う必要がある
• managed service だけでは満たせない packet inspection がある
• VPN、Firewall、IDS/IPS の運用責任を明確に引き受けられる
• クラウド側の経路制御と appliance 側の状態管理を合わせて設計できる
• 障害時の切り分けと rollback 手順を用意できる

仮想アプライアンスを避けた方がよい場面

• 物理装置と同じ L2 / L3 制御を期待している
• underlay network まで自分で制御できる前提で考えている
• 平均帯域だけを見て性能を判断している
• 障害時にクラウド側と appliance 側の責任分界を決めていない
• managed security service や cloud native な経路制御で十分に満たせる

Direct Connect や VPN はラックの延長ではない

Direct Connect や site-to-site VPN は、オンプレミスとクラウドをつなぐ重要な接続方式です。しかし、クラウドを自社ラックの延長として扱えるわけではありません。経路、帯域、冗長化、BGP、MTU、暗号化、監視、障害責任の境界が変わります。

NFV 型 NF を経路上に置く場合、Direct Connect や VPN の先にどの traffic を通すのか、cloud 側でどこまで inspection するのか、オンプレミス側の routing とどう整合させるのかを決める必要があります。

クラウド側で確認すること

NFV 型 NF を検討するときは、仮想アプライアンスだけでなく、VPC、subnet、route table、ENI、Transit Gateway、GWLB、Direct Connect の状態を合わせて確認します。

aws ec2 describe-vpcs
aws ec2 describe-subnets
aws ec2 describe-route-tables
aws ec2 describe-network-interfaces
aws elbv2 describe-load-balancers
aws directconnect describe-connections

成立する構成と成立しにくい構成

設計判断の軸

パブリッククラウドで NFV 型 NF を採用するかどうかは、機能一覧ではなく責任分界で判断します。クラウド側の managed service で足りるのか、仮想アプライアンスを置く理由があるのか、その理由を運用で支えられるのかを分けて見ます。

まとめ

パブリッククラウドで NFV 型 NF は成立する場合があります。ただし、それは仮想アプライアンスを VM として置けるという意味ではありません。VPC の到達性、GWLB、Transit Gateway、Direct Connect、EC2 の性能制約、障害時の責任分界まで含めて成立させる必要があります。

オンプレミス NFV をそのまま持ち込むのではなく、クラウドの制約を前提に network function の役割を再設計できるか。そこを判断できる場合に、パブリッククラウド上の NFV は現実的な選択肢になります。

関連記事

クラウドネイティブはテレコムを救うのか – CNF、Kubernetes、OpenStack から考える通信基盤