領域を広げつつデファクトスタンダードへ、OPNFVの今：通信事業者だけの話題ではない

[鳥居隆史，NEC]

　通信事業者のNFVを支援するプロジェクトであるOPNFVは、どのように進んでいるのか。通信事業者以外には関係のないトピックなのか。以下では、2016年6月下旬にドイツ・ベルリンで開催された第2回OPNFV Summitの内容を踏まえ、「OPNFVの今」を報告する。

　OPNFV（Open Platform for NFV）は、オープンソースによるNFV参照プラットフォームの実現を目指すプロジェクトである。2014年10月に設立され、参加企業は現在59社に上る。Linux FoundationのCollaboration Projectであり、運営やガバナンスについてはLinux Foundationが支援している。そのため議論を含め活動はすべてオープンだ。これまで標準化団体がリードしてきたテレコム業界の変革を象徴するプロジェクトといえる。

　ちなみに、NFVは「Network Functions Virtualization（ネットワーク機能仮想化）」の略だ。通信事業者が、従来は専用通信設備で行ってきた通信処理を、汎用コンピュータ（サーバ）を用いた仮想化基盤で処理するための一連の仕組みを指す。分散コンピューティングプラットフォームからアプリケーション、そしてこれらをまたがるオーケストレーションまで、さまざまな機能が求められる。

参考記事：

Chris Wright氏が語るSDN：OpenDaylight、OpenStack、そしてOPNFV (3/3)

　OPNFVが設立された背景には、ETSI（European Telecommunications Standards Institute：欧州電気通信標準化機構）によるNFVアーキテクチャの策定がある。ETSIは仕様（specification）を策定するが、実装（implementation）は行わない。NFVを実現したいテレコムユーザーは、実装を進めるための枠組みが欲しい。さらにその実装はベンダー中立にオープンソースを用いて実現されるのが望ましい。そのような背景から、AT＆Tが中心となり、Linux Foundationと組んで立ち上げたのがOPNFVである。当初はNFVのうち、下位レイヤに焦点を当て、OpenStack、OpenDaylightなどのプロジェクトから、テレコムユーザーのニーズを満たせるプラットフォームを提示することを目的とする活動を展開してきた。

　OPNFVは2016年9月に3番目のソフトウェアリリースであるColoradoを提供開始するなど、コミュニティは確実に成長している。ただし注意が必要なのは、OPNFVはそれ自体がソフトウェアを開発するプロジェクトではないということだ。OPNFVは各オープンソースコミュニティに対してNFVアーキテクチャの要件を示し、擦り合わせを行って不足している部分の実装を促し、これをまとめ上げて提供することを目的としている。こうした位置付けから、必然的にOPNFVプロジェクトへの参加者は他のオープンソースコミュニティの人が多い。例えばOpenStack、OpenDaylight、ONOS、FD.ioといった具合である。純粋にOPNFVのコミュニティメンバーだという人は少ない。他のコミュニティから見ると、OPNFVはNFVのユースケースを実現する場と捉えられており、ソフトウェアを開発するコミュニティではない。OPNFVにはベンダーだけではなく、ユーザーに当たるテレコムキャリアが多数参加している。つまり開発というよりは、ユースケースと要件定義、テストに焦点を当てているといえるだろう。

ベンダーによる製品化動向は？

　OPNFVは、3番目のリリースColoradoが9月に提供開始されたが、ベンダーによる製品化は、まだ本格化したとは言い難い。

　2016年6月のOPNFV Summitでは、一番上のダイアモンドスポンサーにヒューレット・パッカード・エンタープライズ（HPE）、その下のプラチナスポンサーにエリクソン、ファーウェイ、インテル、レッドハットが並んだ。NFV領域の大手ベンダーがそろったといえる。OPNFVにどう関わるかはそれぞれだが、開発者がOPNFVに基づく社内プロジェクトを行い、その要素を自社のソリューションに入れていこうという意図が感じられる。

　ただし、このサミットのブースで各社が見せていたのはほとんどが各社の製品・ソリューションであり、そこにOPNFVの要素はほぼ見られなかった。OPNFVのプロジェクトはようやくプロトタイプ段階というのがほとんどであり、商用のソリューションとなるにはまだ時間がかかるということだろう。ブースの展示は顧客向けというよりは、エンジニアレベルでの発表と議論の場という色合いが濃いと感じた。

　もっとも、OPNFVはこれまでインフラ部分に特化してきており、それは通信事業者が求めるソリューションの一部にとどまるため、この状況は当然と言えなくもない。

OPNFVの技術的進化

MANO（Open-O）

　OPNFVは初期のArno、BrahmaputraリリースまではNFVのプラットフォーム領域、すなわちETSI NFVのNFVI（NFV Infrastructure：NFVインフラストラクチャ）とVIM（Virtual Infrastructure Manager：仮想インフラマネージャ）を対象領域としていた。Coloradoリリースからはこの制約がなくなり、アプリケーションやオーケストレーションの領域、すなわちVNF（Virtual Network Function：仮想化ネットワーク機能）やMANO（Management and Orchestration：マネージメント／オーケストレーション機能）までを含むこととなった。

当初は赤破線で囲まれた分野をカバーしていたOPNFVだが、その後対象がVNFやMANOに拡大している（出所：OPNFV）

　そこで注目を集めるようになったのが、MANO領域のオープンソースとしてプロジェクトが始まったOpen-Oである。Open-Oはチャイナモバイルとファーウェイが開発したコードがベースとなり、2016年6月にLinux Foundationのプロジェクトとして活動を開始した。6月のOPNFV Summitでは、「Open-O Mini Summit」と題して丸一日のトラックが行われ、大変盛況だった。MANO領域のオープンソース実装としては、テレフォニカが主体となっているOSM（Open Source MANO）もあるが、オープンソースコミュニティへのアピールではOpen-Oが先行した印象を受ける。

VNF Orchestration

　ネットワークサービスを実現する機能を「Virtualized Network Function（VNF）」という。実はNFVのアプリケーションといっても、OpenStackのテナントで動く仮想マシン（VM）形式のアプリケーションである。一般的な仮想マシン形式のアプリケーションとの違いとしては、もともとVMで動くことを想定していないアプリケーションであること、「VMにアプリケーションを載せる」のではなく、VMイメージ自体がアプリケーションとなっていること、複数のVMでシステムを構築することが挙げられる。ITの世界ではOSの上にミドルウェアをインストールして、アプリケーションのプログラムを走らせる。もともとIAサーバで動かすことを想定しており、OS依存性はあるものの、VMになってもやることは変わらない。しかしNFVの世界では同じようにならない。もっとも分かりやすい例は、ファイアウォールやロードバランサ―だろう。確かにOSの上で動いているが、従来は装置として使われてきたため、通常はOSを見せることはない。見せるのは独自のコマンドやAPI、GUIである。

　ITの世界では、PuppetやChef、Ansibleのようなツールを使った自動構築や運用制御はよくある話になってきた。しかしNFVの世界はそうなっていない。Puppet、Chef、Ansibleなどの代わりに使われるのが、VNFM（VNF Manager）、NFVO（NFV Orchestrator）である。これらのコンポーネントがNFVのVMを設定し、アプリを動かすためのマネージメントを行う。最近、オーケストレーションに焦点が当たってきたのは、VIM、NFVIといったインフラはほぼできてきており、VNFをその上で動かすというシステムに関心が移っている表れといえる。

NFVはキャリアだけのものなのか、エンタープライズとは無縁なのか

　NFVはキャリアだけのものだろうか？ NFVの世界では、「キャリアグレード」という言葉がよく聞かれる。一方、2016年6月のOPNFV Summitでは、「NFVといっても我々は特別ではない（We/You are not Special）」というメッセージもあった。ここには、NFVに関わるさまざまな組織の事情が絡んでいる。

　テレコムとITの両方で事業を展開してきたベンダーは、テレコムの世界がNFVに移行し始めても、両者を分けてソリューションを作っていることが多い。技術の現状およびコスト構造を考えると、その考え方はリーズナブルでもある。そのため、「キャリアグレードとエンタープライズは別だ」となる。

　しかし、ITの世界からNFVに参入してきたベンダーや、ソリューションとして両者のコスト構造が同じベンダーは、両者を区別する必要はない。むしろインフラとしては同じだというメッセージで、自社のマーケットを広げようとしている。この違いを理解しておくことが重要である。

　技術的には、NFVではシステムとしての安定性をより求められる。安定性には、性能が予測通りにぶれなく出るという性能の安定性、障害や異常が起きたときにサービスを止めることなく復旧するという高可用性がある。これらを実現するために、SR-IOVやDPDKといった、ハードウェアを生かして高性能を実現するネットワーク技術、CPU Pinning（アプリケーションへのCPUの固定的な割り当て）やNUMA対応といったリソース割り当てと確実な予約、障害からの高速な復旧などが必要となる。これらの機能は現時点ではNFV特有であり、一般のエンタープライズではオーバースペックと思われるであろう。「NFVは別物」と判断されるゆえんである。しかし安定性という要件自体は、既存のアプリケーションでは多く求められるものであり、決してキャリアに特化したものではない。

　中期的に見れば、キャリアのビジネスが変わってきており、いずれITとキャリアの区別は（少なくともインフラレベルでは）なくなっていくだろう。キャリアの多くは、テレコムサービスと同時にクラウドサービスを行っており、共通基盤化のニーズは高い。現時点では、費用構造、運用体制が違うため、別々の部門で構築・運用するケースが多いようだが、すでに統合をにらんだ試みを始めているキャリアは少なからず存在する。オープンソースの利用に関しては、キャリアはエンタープライズよりも積極的に、エンジニアリソースを掛けていくと予想される。この流れにはベンダーも乗っていかざるを得ない。「キャリアグレード」という言い方はなくなっていき、NFVの特殊性は薄れていくだろうというのが筆者の見立てである。

　NFVの裾野は広い。OpenStackはもちろん、OpenDaylightやONOSなど、SDN、Open-O、ARMといった領域まで広がっている。このような広い領域をカバーするOPNFVの試みは新たなチャレンジである。OPNFVが中心となり、オープンソースのエコシステムを業界としてどう発展させていくか、ベンダーとユーザーの思惑をどう調停していくかが問われている。今後の動きやコミュニティの広がりは、キャリアだけではなくエンタープライズの観点からも注目である。