NFV 型のネットワーク機能をパブリッククラウドへ持ち込めるかどうかは、単に VM が起動できるか、仮想アプライアンスのイメージが Marketplace にあるか、という話ではありません。
問題になるのは、そのネットワーク機能が前提としているアンダーレイ、オーバーレイ、帯域、遅延、可用性、観測、障害切り分け、責任分界です。オンプレミス NFV の設計感覚をそのままクラウドへ移すと、見た目は同じでも成立条件が変わります。
結論として、パブリッククラウド上で NFV 型 NF は成立する場合があります。ただし、それはオンプレミス NFV をそのまま移植できるという意味ではありません。クラウドの制約を前提に、ネットワーク機能の責務を再設計できる場合に成立します。
書籍
Amazon Web Services 基礎からのネットワーク＆サーバー構築 改訂 4 版
AWS VPC、サブネット、ルーティング、VPN、Direct Connect など、クラウドネットワークの基礎を確認したい場合の参考書籍です。NFV 型の構成をクラウドへ持ち込む前提整理として紹介します。
Amazon で見るこのリンクは Amazon アソシエイトリンクです。
まず結論
パブリッククラウドで NFV 型 NF を評価するときは、次のように分けて考えるのがよいです。
| 観点 | 見ること | 判断 |
|---|---|---|
| VM として動くか | 仮想アプライアンスイメージ、対応インスタンス、ライセンス | これは入口であり、成立性そのものではない |
| dataplane が成立するか | 帯域、pps、single-flow、暗号処理、セッション数 | NFV としての実効性能を左右する |
| 経路に自然に入るか | VPC Route Table、TGW、GWLB、ENI、対称経路 | 無理に挟むと非対称通信や切り分けが重くなる |
| クラウド標準機能で足りるか | Security Group、NACL、ALB/NLB、NAT Gateway、Network Firewall など | 仮想アプライアンスが過剰な場合がある |
| 責任分界が明確か | クラウド事業者、利用者、製品ベンダー、回線事業者 | 障害時にどこを見るかを事前に決める |
つまり、重要なのは「その製品がクラウドで動くか」ではなく、そのネットワーク機能をクラウド上のどの責務として置くのかです。
NFV 型 NF とは何を指すのか
ここでいう NF は Network Function、つまりネットワーク機能です。Firewall、Router、VPN、NAT、IDS/IPS、Load Balancer、Proxy など、物理アプライアンスで提供されていた機能を、汎用サーバー上の VM やソフトウェアとして動かす考え方が NFV です。
| 分類 | 例 | 主な関心事 |
|---|---|---|
| ルーティング系 | 仮想 Router、BGP Router、VyOS | 経路制御、冗長化、収束、対称経路 |
| セキュリティ系 | 仮想 Firewall、IDS / IPS、DPI | 検査性能、セッション維持、ログ、スケール |
| 接続系 | VPN、IPsec、NAT | 暗号処理、throughput、single-flow、片方向障害 |
| 負荷分散系 | Load Balancer、Proxy | L4 / L7 処理、ヘルスチェック、証明書、セッション |
オンプレミスであれば、これらを VM として載せるだけでなく、物理 NIC、スイッチ、VLAN、LAG、NUMA、CPU ピニング、SR-IOV、DPDK なども合わせて設計できます。パブリッククラウドでは、利用者が直接握れる範囲がもっと上位の抽象に寄ります。
アンダーレイとオーバーレイを分ける
パブリッククラウドで NFV 型 NF を考えるとき、最初に分けるべきなのはアンダーレイとオーバーレイです。
| 層 | 意味 | 利用者ができること |
|---|---|---|
| アンダーレイ | クラウド事業者が管理する物理ネットワーク、物理サーバー、物理回線、SDN 基盤 | 基本的には直接制御できない |
| オーバーレイ | VPC、Subnet、Route Table、ENI、Security Group、NACL、TGW、VPN、Direct Connect など | クラウドが公開する API と制約の範囲で設計できる |
この点は、AWS VPC に L2 はあるのか で整理した話とつながります。クラウドでは L2 の自由度が消えたというより、利用者の設計対象から外れ、クラウド事業者の責任境界内に封じ込められます。
オンプレミス NFV では、アンダーレイを自分で設計し、その上に NF を載せる発想になります。パブリッククラウドでは、アンダーレイを直接握らず、クラウドが提供する到達性モデルの中に NF を置くことになります。
成立性を決めるのは VM の有無ではない
クラウド Marketplace には、多くの仮想 Firewall や仮想 Router があります。そのため、表面的には NFV 型 NF はクラウド上でも成立しているように見えます。
しかし、運用上の成立性は、VM として起動できるかでは決まりません。見るべきなのは、dataplane と責務分界です。
- 想定した帯域を継続的に処理できるか
- single-flow や暗号処理で詰まらないか
- 片系障害時に経路とセッションをどう維持するか
- Route Table、TGW、GWLB、ENI の制約と矛盾しないか
- スケールアウトできる構成になっているか
- 障害時の切り分け責任が利用者側に残りすぎないか
- クラウド標準機能で代替できる部分を過剰に仮想アプライアンス化していないか
NFV 型 NF は、クラウド上に置けるから成立するのではありません。クラウドのネットワーク抽象化、可用性モデル、帯域制約、運用モデルの中で、その NF が自然な責務を持てる場合に成立します。
EC2 の帯域は物理ポートの感覚で読まない
オンプレミスでネットワーク機器を設計する場合、物理ポート、LAG、スイッチ容量、NIC、PCIe、CPU、メモリ、NUMA などを積み上げて性能を見積もります。
一方、EC2 ではインスタンスタイプごとのネットワーク性能、baseline、burst、single-flow、AZ 間通信、NAT や Load Balancer などのマネージドサービス制約が絡みます。AWS 公式ドキュメントでも、特定サイズ以下のインスタンスは baseline bandwidth を持ち、一定時間 burst bandwidth を使えると説明されています。
| 観点 | オンプレミス NFV | パブリッククラウド |
|---|---|---|
| 物理 NIC | 自分で選定、交換、冗長化できる | インスタンスタイプとクラウド仕様に依存する |
| CPU / NUMA | CPU ピニング、HugePages、NUMA を強く意識できる | 専有ホスト等を除き抽象化される部分が大きい |
| 帯域 | 物理ポートや LAG から見積もる | baseline / burst / flow 制約を読む |
| 経路制御 | 物理 Router、VRF、VLAN を直接扱える | VPC、Route Table、TGW、VPN、Direct Connect で扱う |
| 障害切り分け | 自分の設備範囲を直接調査できる | クラウド側ブラックボックスとの境界が残る |
この点は AWS EC2 のネットワーク帯域をどう読むか で扱った内容と同じです。NFV 型 NF では、EC2 の「最大何 Gbps」だけではなく、継続帯域、flow、暗号処理、アプライアンス製品側の処理能力を合わせて見る必要があります。
Gateway Load Balancer は NFV の万能解ではない
AWS には Gateway Load Balancer があります。AWS 公式ドキュメントでは、GWLB は Firewall、IDS/IPS、DPI などの仮想アプライアンスを deploy、scale、manage するためのサービスとして説明されています。GWLB は OSI Layer 3 で動作し、GENEVE protocol を使って target appliance へ traffic を転送します。
これは、クラウド上で仮想アプライアンスを扱うための非常に重要な部品です。ただし、GWLB があるからオンプレミス NFV をそのまま再現できる、という意味ではありません。
- GWLB は仮想アプライアンスをスケールさせやすくするが、アプライアンス本体の処理能力は別に評価する必要がある
- TGW と組み合わせる場合、flow symmetry や appliance mode の理解が重要になる
- TLS 復号、DPI、IDS/IPS などは CPU 負荷やセッション管理の影響を受ける
- 経路設計、戻り通信、AZ 障害、cross-zone の扱いを設計しないと事故りやすい
GWLB は NFV 型 NF をクラウドの到達性モデルへ載せるための部品です。低レイヤーの自由度を取り戻すものではありません。
仮想アプライアンスを置くべき場面
仮想アプライアンス型の NF を置くこと自体が悪いわけではありません。むしろ、次のような場合は合理的です。
- 既存の監査要件やセキュリティポリシー上、特定製品を通す必要がある
- オンプレミスと同じ Firewall policy、ログ形式、運用手順を一定期間維持したい
- IPsec、BGP、NAT、Firewall policy などで既存拠点との互換性が重要になる
- クラウド標準機能だけでは満たせない検査、制御、可視化がある
- 移行期間中の中継点として、物理アプライアンス相当の責務を一時的に置きたい
ただし、この場合でも「オンプレミス機器をクラウドに置き換えた」と考えるより、「クラウド上に特定責務を持つネットワーク制御点を置いた」と考える方が安全です。
仮想アプライアンスを避けた方がよい場面
逆に、クラウド標準のネットワーク機能で自然に実現できることまで仮想アプライアンスへ寄せると、構成が不自然になります。
- 単純な通信許可をすべて仮想 Firewall に集約する
- クラウドの Load Balancer で足りる処理を VM 上の L4 / L7 装置に寄せる
- NAT、routing、Security Group、NACL、IAM と重複する制御点を増やす
- 高可用性をクラウドの managed service ではなく自前クラスタだけで組もうとする
- 性能問題の原因がクラウド側の帯域モデルなのに、NF のチューニングだけで解決しようとする
クラウドでは、ネットワーク機能を VM として動かすことよりも、クラウドが提供する制御面とデータ面に合わせて責務を分けることの方が重要です。
Direct Connect や VPN はラックの延長ではない
Direct Connect や VPN を使えば、オンプレミスとクラウドを接続できます。しかし、それによってクラウドがオンプレミスラックの延長になるわけではありません。
接続回線ができても、クラウド側の VPC、Route Table、TGW、Security Group、NACL、仮想アプライアンス、managed service はクラウドの制約の中で動きます。オンプレミスの L2 / L3 設計をそのまま引き伸ばす感覚で扱うと、経路制御、非対称通信、障害切り分けで苦しくなります。
クラウド接続は、物理ネットワークの延長というより、異なる運用モデルを持つネットワーク同士の接続点として考える方が自然です。
成立する構成と成立しにくい構成
| 構成 | 成立性 | 理由 |
|---|---|---|
| クラウド標準機能を中心にし、必要な箇所だけ仮想アプライアンスを使う | 高い | 責務が分かれ、クラウドの運用モデルに乗りやすい |
| GWLB / TGW を使って inspection VPC を設計する | 条件付きで高い | flow symmetry、appliance mode、AZ 障害、戻り通信を設計できるなら有効 |
| 拠点接続や監査要件のために特定 NF を通過点として置く | 条件付きで成立 | 目的が明確で、処理範囲を限定できるなら有効 |
| オンプレミス NFV の構成をほぼそのまま VM として移植する | 低い | アンダーレイ制御、性能見積もり、障害切り分けで無理が出やすい |
| 高帯域、低遅延、物理制御前提の NF をそのまま置く | 成立しにくい | クラウドの抽象化とアンダーレイ非制御性が問題になる |
設計判断の軸
パブリッククラウド上で NFV 型 NF を使うかどうかは、次の軸で判断すると整理しやすくなります。
| 判断軸 | 見るべきこと |
|---|---|
| 性能 | 必要帯域、pps、flow 数、暗号処理、遅延、burst 特性 |
| 可用性 | AZ 障害、片系障害、経路切替、セッション維持 |
| 経路 | 対称経路、戻り通信、TGW、GWLB、Route Table |
| 運用 | 監視、ログ、障害切り分け、アップデート、バックアップ |
| 責務 | クラウド標準機能、仮想アプライアンス、オンプレミスの分担 |
| 移行性 | 既存機器、既存ポリシー、既存監査との接続性 |
この判断軸を置くと、仮想アプライアンスを使うこと自体が目的ではないことが見えてきます。目的は、クラウド上のネットワーク責務をどこで処理するのが最も自然かを決めることです。
まとめ
パブリッククラウド上で NFV 型 NF は成立します。ただし、成立するのはオンプレミス NFV をそのまま持ち込めるからではありません。クラウドのアンダーレイ非制御性、VPC の到達性モデル、EC2 の帯域制約、GWLB / TGW の経路設計、運用責任を理解した上で、NF の責務を再定義できる場合に成立します。
パブリッククラウドでは、低レイヤーを握ることよりも、クラウドが提供する抽象化の中で責務を正しく切ることが重要です。仮想アプライアンスは便利な選択肢ですが、万能の置き換え先ではありません。
NFV 型 NF をクラウドで使うなら、最初に考えるべきなのは「その製品がクラウドで動くか」ではなく、「そのネットワーク機能をクラウド上のどの責務として置くのか」です。
参考資料
- Amazon EC2 instance network bandwidth
- What is a Gateway Load Balancer?
- Gateway Load Balancers
- Using Gateway Load Balancer with Transit Gateway for centralized network security
- What is AWS Transit Gateway?
関連記事
- AWS VPC に L2 はあるのか – VLAN / ARP / VIP をクラウドの到達性モデルへ翻訳する
- AWS Direct Connect は何を接続するのか – Connection / VIF / DXGW / TGW の責務分界
- AWS EC2 のネットワーク帯域をどう読むか – baseline / burst / flow 制約と NFV 設計
- AWS Outposts の本質は「オンプレ AWS」ではなく、責任分界を変えるインフラである
- CPU ピニングを外すと何が変わるのか – 専有実行から共有実行へ変わるということ
- 単一 VM の vCPU はどこまで割り当てるべきか – 物理コア数、NUMA、オーバーコミットで考える
- クラウドという言葉の本質 – 場所ではなく運用モデルと責任分界で考える
