パブリッククラウド上で NFV 型ネットワーク機能は成立するのか – アンダーレイ、オーバーレイ、帯域制約で考える

NFV 型のネットワーク機能をパブリッククラウドへ持ち込めるかどうかは、単に VM が起動できるか、アプライアンスイメージが提供されているか、という話ではありません。問題になるのは、ネットワーク機能が前提としているアンダーレイ、オーバーレイ、帯域、遅延、冗長化、運用責任の置き場所です。

オンプレミスの NFV 基盤では、物理 NIC、スイッチ、VLAN、LAG、NUMA、CPU ピニング、SR-IOV、DPDK などを含めて、かなり低いレイヤーまで設計者が握れます。一方、パブリッククラウドでは、それらの多くはクラウド事業者が管理するアンダーレイに吸収されます。ここを同じものとして扱うと、成立性の判断を誤ります。

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

この記事で扱うこと

ここでは、ファイアウォール、ルーター、VPN、ロードバランサー、NAT、IDS/IPS のようなネットワーク機能を、仮想アプライアンスまたは NFV 的な構成としてパブリッククラウド上で扱う場合の成立条件を整理します。

• パブリッククラウドで NFV 型 NF を動かすときに何が問題になるのか
• アンダーレイとオーバーレイを分けて考える必要がある理由
• 帯域、遅延、パケット処理性能をどこまで制御できるのか
• クラウドネイティブなネットワーク機能と仮想アプライアンスの違い
• オンプレミス NFV と同じ設計思想を持ち込む危うさ

NFV 型 NF とは何を指しているのか

ここでいう NF は Network Function、つまりネットワーク機能を指します。物理アプライアンスとして提供されていた機能を、汎用サーバー上の VM やソフトウェアとして動かす考え方が NFV です。

分類	例	主な関心事
ルーティング系	仮想ルーター、BGP ルーター	経路制御、冗長化、収束時間
セキュリティ系	仮想ファイアウォール、IDS / IPS	検査性能、セッション維持、ログ
接続系	VPN、IPsec、NAT	暗号処理、スループット、片方向障害
負荷分散系	ロードバランサー、プロキシ	L4 / L7 処理、ヘルスチェック、証明書

オンプレミスであれば、これらを VM として載せるだけでなく、その下の物理ネットワークやサーバー設定も合わせて最適化できます。しかしパブリッククラウドでは、利用者が制御できる範囲と制御できない範囲が明確に分かれます。

最初に分けるべきなのはアンダーレイとオーバーレイ

パブリッククラウドでネットワーク機能を考えるとき、まず分けるべきなのはアンダーレイとオーバーレイです。

層	意味	利用者ができること
アンダーレイ	クラウド事業者が管理する物理ネットワーク、物理サーバー、物理回線	基本的には直接制御できない
オーバーレイ	VPC、サブネット、ルートテーブル、ENI、セキュリティグループ、VPN、Direct Connect など	クラウドが提供する抽象化の範囲で設計できる

オンプレミス NFV の感覚では、アンダーレイを自分で設計し、その上に NF を載せる発想になります。ところがパブリッククラウドでは、アンダーレイはブラックボックスに近く、利用者はオーバーレイの API と制約の中でネットワークを作ります。

この違いを無視して、オンプレミスのルーターやファイアウォールをそのままクラウド VM に置いただけでは、ネットワーク設計としては中途半端になります。見た目は NFV でも、制御できる場所が違うからです。

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

クラウドマーケットプレイスには、多くの仮想ファイアウォールや仮想ルーターが存在します。そのため、表面的には NFV 型 NF はクラウド上でも成立しているように見えます。

しかし、重要なのは「起動できるか」ではありません。運用上の意味で成立するかどうかです。

• 想定した帯域を継続的に処理できるか
• 片系障害時に経路とセッションをどう扱うか
• クラウド側のルートテーブルや ENI 制約と矛盾しないか
• スケールアウトできる設計になっているか
• 障害時の切り分け責任が利用者側に残りすぎないか
• クラウド標準機能で代替できる部分を過剰に仮想アプライアンス化していないか

NFV 型 NF は、クラウド上に VM として置けるから成立するのではありません。クラウドのネットワーク抽象化、可用性モデル、帯域制約、運用モデルの中で、その NF が自然な責務を持てる場合に成立します。

帯域制約は物理機器の感覚と異なる

オンプレミスでネットワーク機器を設計する場合、物理ポート、LAG、スイッチ容量、NIC、PCIe、CPU、メモリ、NUMA などを積み上げて性能を見積もります。

一方、クラウドではインスタンスタイプごとのネットワーク性能、フロー単位の制限、AZ 間通信、NAT やロードバランサーなどのマネージドサービス制約、Direct Connect や VPN の構成上限が絡みます。利用者は物理配線を変えられません。

観点	オンプレミス NFV	パブリッククラウド
物理 NIC	自分で選定、交換、冗長化できる	インスタンス種別とクラウド仕様に依存する
CPU 割り当て	CPU ピニングや NUMA を強く意識できる	専有ホスト等を除き抽象化される
経路制御	物理ルーター、VRF、VLAN を直接扱える	VPC、ルートテーブル、TGW、VPN 等で扱う
障害切り分け	自分の設備範囲を直接調査できる	クラウド側ブラックボックスとの境界が残る

このため、パブリッククラウドで NFV 型 NF を設計するときは、物理機器のポート帯域のような感覚ではなく、クラウドが提供する通信モデルの中で性能を読む必要があります。

低レイヤーを握れないことの意味

NFV では、低レイヤーをどこまで握れるかが性能と予測可能性に直結します。SR-IOV、DPDK、CPU ピニング、HugePages、NUMA 配置などは、ネットワーク機能を高性能に動かすための典型的な要素です。

パブリッククラウドでも、これらに近い考え方を一部利用できる場合はあります。しかし、最終的にはクラウド事業者が管理する基盤の上で動くため、オンプレミスのように全体を自分で閉じることはできません。

ここで重要なのは、パブリッククラウドが劣っているという話ではないことです。クラウドは、低レイヤーを隠蔽することで運用性、拡張性、API 化、標準化を得ています。その代わり、低レイヤーに強く依存する NFV 的な設計とは相性が悪くなる場面があります。

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

パブリッククラウドで仮想アプライアンス型の NF を置くこと自体が悪いわけではありません。むしろ、次のような場合は合理的です。

• 既存のセキュリティポリシーや監査要件上、特定製品を通す必要がある
• オンプレミスと同じ運用手順やログ形式を一定期間維持したい
• IPsec、BGP、ファイアウォールポリシーなどで既存拠点との接続互換性が重要になる
• クラウド標準機能だけでは満たせない検査、制御、可視化がある
• 移行期間中の中継点として、物理アプライアンス相当の責務を一時的に置きたい

ただし、この場合でも「オンプレミス機器をクラウドに置き換えた」と考えるより、「クラウド上に特定責務を持つネットワーク制御点を置いた」と考える方が安全です。

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

逆に、クラウド標準のネットワーク機能で自然に実現できることまで仮想アプライアンスへ寄せると、構成が不自然になります。

• 単純なサブネット間制御をすべて仮想ファイアウォールに集約する
• クラウドのロードバランサーで足りる処理を VM 上の L4 / L7 装置に寄せる
• NAT、ルーティング、セキュリティグループ、IAM と重複する制御点を増やす
• 高可用性をクラウドのマネージド機能ではなく自前クラスタだけで組もうとする
• 性能問題の原因がクラウド側の帯域モデルなのに、NF のチューニングだけで解決しようとする

クラウドでは、ネットワーク機能を VM として動かすことよりも、クラウドが提供する制御面とデータ面に合わせて責務を分けることの方が重要です。

クラウド上の NFV は設計主語が変わる

オンプレミス NFV の主語は、比較的わかりやすく自分たちの基盤です。物理サーバー、物理ネットワーク、ストレージ、仮想化基盤、NF、運用監視までを自分たちの設計範囲として持てます。

しかしパブリッククラウドでは、主語がクラウド事業者の基盤と利用者のオーバーレイに分かれます。利用者が設計できるのは、クラウドが露出している抽象化の範囲です。

設計対象	オンプレミスでの主語	パブリッククラウドでの主語
物理ネットワーク	利用者または自社基盤チーム	クラウド事業者
仮想ネットワーク	仮想化基盤チーム	利用者とクラウドサービスの境界
NF 本体	利用者	利用者
可用性設計	利用者が全体を設計	クラウド機能と利用者設計の組み合わせ
性能保証	物理構成から見積もる	インスタンス仕様とクラウド制約から見積もる

この主語の変化を理解しないまま NFV をクラウドへ持ち込むと、運用責任だけが重くなり、クラウドを使う意味が薄れます。

アンダーレイを要求する NF とクラウドの相性

NF の中には、アンダーレイに強く依存するものがあります。たとえば、低遅延、固定帯域、物理インターフェース、L2 隣接性、特殊なパケット処理、細かなキュー制御などを前提にする構成です。

こうした NF をパブリッククラウドへ持ち込む場合、クラウドが提供する抽象化と衝突しやすくなります。特に L2 近接性や物理ポート単位の制御を前提にした設計は、クラウドの VPC モデルとは根本的に噛み合わない場合があります。

この場合、クラウド上に置くべきなのは NF そのものではなく、NF の一部責務だけかもしれません。あるいは、クラウド側ではマネージドサービスを使い、オンプレミス側に重いネットワーク処理を残す方が自然なこともあります。

Direct Connect や VPN は魔法の延長線ではない

Direct Connect や VPN を使えば、オンプレミスとクラウドを接続できます。しかし、それによってクラウドがオンプレミスのラックの延長になるわけではありません。

接続回線ができても、クラウド側の VPC、ルートテーブル、TGW、セキュリティグループ、NACL、仮想アプライアンス、マネージドサービスはクラウドの制約の中で動きます。オンプレミスの L2 / L3 設計をそのまま引き伸ばす感覚で扱うと、経路制御、非対称通信、障害切り分けで苦しくなります。

クラウド接続は、物理ネットワークの延長というより、異なる運用モデルを持つネットワーク同士の接続点として考える方が自然です。

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

構成	成立性	理由
クラウド標準機能を中心にし、必要な箇所だけ仮想アプライアンスを使う	高い	責務が分かれ、クラウドの運用モデルに乗りやすい
オンプレミス NFV の構成をほぼそのまま VM として移植する	低い	アンダーレイ制御、性能見積もり、障害切り分けで無理が出やすい
拠点接続や監査要件のために特定 NF を通過点として置く	条件付きで成立	目的が明確で、処理範囲を限定できるなら有効
すべての東西通信を仮想アプライアンスに集約する	慎重に判断	ボトルネック化しやすく、クラウド標準制御と重複しやすい
高帯域、低遅延、物理制御前提の NF をそのまま置く	成立しにくい	クラウドの抽象化とアンダーレイ非制御性が問題になる

クラウドで考えるべき責務分離

パブリッククラウドで NFV 型 NF を扱う場合、最も重要なのは責務分離です。

• クラウド標準機能で処理する範囲
• 仮想アプライアンスに任せる範囲
• オンプレミス側に残す範囲
• マネージドサービスで代替する範囲
• 監査、ログ、可視化のために通過させる範囲
• 性能保証が必要な範囲

この分離をせずに、従来のネットワーク機器をクラウド VM に置き換えるだけでは、クラウドの利点も NFV の利点も中途半端になります。

設計判断の軸

パブリッククラウド上で NFV 型 NF を使うかどうかは、次の軸で判断すると整理しやすくなります。

判断軸	見るべきこと
性能	必要帯域、フロー数、暗号処理、遅延、バースト特性
可用性	AZ 障害、片系障害、経路切替、セッション維持
運用	監視、ログ、障害切り分け、アップデート、バックアップ
責務	クラウド標準機能、仮想アプライアンス、オンプレミスの分担
拡張性	スケールアップかスケールアウトか、構成変更時の影響
移行性	既存機器、既存ポリシー、既存監査との接続性

この判断軸を置くと、仮想アプライアンスを使うこと自体が目的ではないことが見えてきます。目的は、クラウド上のネットワーク責務をどこで処理するのが最も自然かを決めることです。

まとめ

パブリッククラウド上で NFV 型 NF は成立します。ただし、成立するのはオンプレミス NFV をそのまま持ち込めるからではありません。クラウドのアンダーレイ非制御性、オーバーレイ設計、帯域制約、可用性モデル、運用責任を理解した上で、NF の責務を再定義できる場合に成立します。

パブリッククラウドでは、低レイヤーを握ることよりも、クラウドが提供する抽象化の中で責務を正しく切ることが重要です。仮想アプライアンスは便利な選択肢ですが、万能の置き換え先ではありません。

NFV 型 NF をクラウドで使うなら、まず考えるべきなのは「その製品がクラウドで動くか」ではなく、「そのネットワーク機能をクラウド上のどの責務として置くのか」です。

関連する記事

• クラウドを AWS だけで理解してはいけない – 本質は場所ではなく運用モデルである
• CPU ピニングを外すと何が変わるのか – 専有実行から共有実行へ変わるということ
• 単一 VM の vCPU はどこまで割り当てるべきか – 物理コア数、NUMA、オーバーコミットで考える
• AWS Direct Connect の Connection / VIF / DXGW / TGW を整理する
• AWS EC2 の帯域は固定値ではなく、ベースライン、バースト、フロー制限で考える