前回のブログ記事では「アーキテクチャ変遷」の一例として SDN（Software Defined Networking）を取り上げました。SDN についてはまだまだ書かなくてはならないことが残っていますが、それらはひとまず今後に廻し、今回は NFV（Network Function Virtualization）を取り上げます。
NFVとは
NFV とは Network Function Virtualization の略で、「ネットワーク機能の仮想化」を意味します。欧州電気通信標準化機構（ETSI, European Telecommunications Standards Institute）(*) が NFV ISG (Industry Specification Group) を立ち上げ、米国や日本などヨーロッパ以外の通信事業者も加わって積極的に活動を行っているため、今、SDN とともに現在業界の注目を浴びています。
前回の記事のなかで SDN は「ネットワークのあり方に関する再定義」と書きましたが、NFVは「通信事業者による、（データセンターが既に行っている）仮想化の再定義」と捉えられます。
SDN と NFV の関係
「SDN と NFV の関連性」− これはよく訊かれる、しかしちょっと困惑する質問です。（そもそも「SDN」が定義されていないのがいけないのですが、ここでは SDN＝data-plane の programmability ということにして先に進めます。）
両者には、必ずしも直接的必然的な関係がある訳ではないのですが、次のような要因により大いに関連性があり、さらにそれが相乗的に醸成されつつある、ということが言えると思います。
- どちらも、「仮想化」がその発端となっている
- 「SDN and Openflow World Congress」というイベントが、NFV 成果発表の場になっている
- NFV の最初のホワイトペーパーの発表が、SDN and Openflow World Congress（2012）で行われた
- 次回の SDN and Openflow World Congress（2013）でも、NFV Forum が開催される予定
- NFV は data plane の programmability を必要とする。つまり、NFV が「SDN の use case」になる
なお、私がここで重要視したいのは、SDN にも NFV にも共通して必要とされる「システムの統合的運用」、すなわち「Orchestration」です。Orchestration は、SDN にとっても NFV にとっても重要なシステム要素となります。
通信事業者特有のアーキテクチャ？ DC 仮想化と NFV は異なるのか？
さて、前項で NFV を「通信事業者による、（データセンターが既に行っている）仮想化の再定義」と述べました。しかし、データセンターにおいては既に仮想化は当たり前となっており、そのための仮想化基盤アーキテクチャも運用技術も確立されつつあります。そうであれば、（まだ十分とは言えないかもしれませんが）基本的には確立されつつあるものを踏襲すればよいはずです。なぜ再定義の必要があるのでしょうか。
ここで、「データセンターにおける仮想化」と「通信事業者における仮想化」は異なるものなのか、という疑問が生じます。現時点で私が答えるなら、「Yes であり No である」になります。
まず「No」の方ですが、純粋に技術的な観点からみると、データセンターにおける仮想化であろうと、通信事業者における仮想化であろうと、スコープ・目的・要件のどれをとっても、さほど変わらないと思います。もちろん、Case by Case の差異はありますが、それが「データセンターだから」「通信事業者だから」という必然性はあまりありません。実際、通信事業者が運営するデータセンターもあります。したがって、すでにデータセンターで確立されつつある仮想化アーキテクチャを、通信事業者も踏襲すればよい、という考え方もできます。
一方、「Yes」という見方もあります。すなわち、通信事業者のための仮想化アーキテクチャは、異なるものであるべき、というものです。この見方の根拠としては大きく下記の２つのポイントがあると思います。
- Stateful 性とHA（High Availability）
通常のアプリケーションでは、あまりステートフル性は推奨されません。HTTP は基本的にステートレス プロトコルです。しかし、NAPT や stateful SLB などの Middlebox はセッション状態を保持します。通信事業者のアプリケーションである VoIP/SIP/IMS、MPC（Mobile Packet Core）なども、ステートフルであり、セッション状態を保持する必要があります。NFV は、通常のサーバ アプリケーションではなく「ネットワーク機能の仮想化」ですから、これらステートフル性を考慮する必要があります。
さらに「キャリアグレード」という概念は、これらセッション ステートを保ったままサービスを続行する「High Availability」を包含します。その場合、データセンター仮想化基盤で実用化されている VM redundancy や VM migration では不十分となります。
（ただし、私見では、できる限りステートフル性に拘泥しない方がよいと考えています。セッション ステートはボトルネックになり易く、コスト高の要因になるのに加え、ステートフル性のために却って Availability を下げてしまう場合があるからです。必要最低限のケースを除き、できるだけステートを排除する方向の検討も行うべきと考えます。）
- モジュール化、参照モデル、標準インターフェイス
通信事業者のアーキテクチャ設計においては、基本的な考え方として、システムをモジュール化し、そのモジュール間の関係を参照モデルとして定義します。そして参照モデルのインターフェイスを標準化します。ソフトウェアを設計する際にも同様のことを行いますが、通信サービスの場合は相互接続が前提になるため、必要とされる定義の明確性が格段に違います。少しまどろっこしい感じがするかもしれませんが、通信サービスの「規模性」と「存続性」を実現するために、このようなアーキテクチャ設計が必要とされます。
まず「規模性」の観点ですが、既存・新設含む各種システム間や、組織間や事業者間、複数ベンダー間の接続が必須になるため、責任範囲を明確にし、相互接続を保証するために、インターフェイスの標準化が必要です。また「存続性」という観点からは、それぞれのシステム モジュールの内部構造を隠蔽し、入れ替え可能にすることにより、存続しながら進化させることを可能にします。このような事情から、NFV で定義するアーキテクチャは、現在一般的に行われているデータセンター仮想化よりも、モジュール化、オープン化と標準インターフェイスが求められることになります。
下図は、現在議論中の NFV アーキテクチャと、それに対する技術や製品をマッピングしたものです。（まだ過渡期の試案に過ぎないので、ご注意ください。）同じ「Cloud Orchestration」を目的としていても、明確なモジュール化と参照モデルの定義が必要であることがわかります。これはしかし、行き過ぎるとオーバーヘッドの元になるため、今後関係者の方と対話をしながら、程よいアーキテクチャ モデルを探りたいと考えます。
(*) ETSI は 3GPP の母体でもあり、ETSI が推進するプロジェクトで電話網と IP 網の統合を目指した TISPAN（Telecoms and Internet converged Service and Protocols for Advanced Network）は、ITU-T や NTT の NGN のアーキテクチャ モデルとなっています。
Authors
1 コメント