OpenDaylight、OpenStack、そしてOPNFV：Chris Wright氏が語るSDN（3/3 ページ）

OpenDaylightとOpenStackとの関係はどうなっていくのか。OpenStackネットワーキングはSDN化していくのか。OPNFVはこれらとどう絡むのか。OpenDaylightとOPNFVのボードメンバーを務めるレッドハットの著名エンジニア、Chris Wright氏に聞いた。

[三木 泉，＠IT]

　現在のRed Hat Enterprise Linux OpenStack PlatformにはオープンソースSDNコントローラーがありません。代わりに、商用製品パートナーとの素晴らしいエコシステムを構築しています。とはいえ、規模の大きな導入をしようとすると、サードパーティの商用コンポーネントが必要になってしまいます。このため、100％オープンソースで製品全体を提供できるということも非常に重要です。

OPNFVは何を目指し、何を行うのか

――WrightさんはOPNFVプロジェクトにも関わっていますが、このプロジェクトのインパクトをどう表現しますか？

　このプロジェクトは発足したばかりです。まず参加者が同一の目標を共有していることを確認し、NFVというユースケースに関するコミュニティを構築、開発者のリソースを生かして、NFVプラットフォームの構築のため、関連する全てのアップストリームプロジェクトにおける機能ギャップを解消しようとしています。

　OPNFVとは、ETSI NFV Industry Specification Group（ISG）のレファレンスアーキテクチャに基づくレファレンス実装を構築する作業です。まず主に下位のスタックに焦点を当てます。NFVI（Network Functions Virtualization Infrastructure）、仮想インフラ、仮想インフラ管理です。私たちにとって、それはOpenStack、KVM、Open vSwitch、そして潜在的には（インテルの）Data Plane Development Kit（DPDK）などを使ったOpen vSwitchの高速化、さらにオープンソースのコントローラーとしてのOpenDaylightの利用を意味します。これらは全て、プロジェクトとして開発が進められてきたものですが、組み合わせて通信事業者の環境で使うことを考えると、機能ギャップが存在します。

　これらのプロジェクトは多くの場合、自律的に運営されていますから、機能ギャップを埋め、相互の依存性を調停する作業は複雑になります。OPNFVの価値は、複数プロジェクトにまたがるNFVのユースケースに関心を持つ人々を集め、必要な機能の実装、統合、テストを進めることにあります。

　従って、このプロジェクトのインパクトは、有用なオープンソースのNFVプラットフォームを生み出すことです。これは通信事業者の世界に、莫大な変化をもたらす可能性を秘めています。ネットワーク機能の仮想化を、オープンソースに基づくソリューションで行えることは、拡張性、価格モデル、TCOを適正化し、「機能特化型のハードウェアから脱却して、汎用的なコンピュートおよびネットワークのグリッド上で、仮想的な機能として動かしたい」という彼らの目標を実現することにつながります。通信事業者がオープンソースのソリューションを好むことははっきりしています。特定のベンダーとの関係に縛られたくないと考えているのです。

　課題は、オープンソースの開発についてよく理解していない人々をまとめ、オープンソース開発に影響を与えなければならないということにあります。通信業界では、歴史的にベンダー独自のソリューションが活用されてきました。ベンダーと顧客との関係は、標準化団体によって規定されてきました。標準が策定されると、これに基づいてベンダーがそれを製品としてまとめ上げるというプロセスが繰り返されてきました。こうした世界に慣れている人たちが、オープンソースコミュニティに対してインパクトを与えられるようにすること、それは興味深い課題だと考えています。

　参加者全員が、とてもやる気になっています。通信事業者はインフラのコストを下げられ、ソフトウェア中心の運用で柔軟性を高められることに期待しています。このため、ベンダーもやる気になっています。全員が、同一のオープンソースソフトウェアを、これにふさわしい構成要素だと考えています。

――しかし、このプロジェクトの活動がコードの開発を伴う場合、そのコードはどこに属することになるのですか？ 最も関連するアップストリームプロジェクトにコントリビューションされるのでしょうか？

　このプロジェクトで開発したコードをどこでホストすべきかは、まさに最初の段階で検討した点です。レッドハットでは、「アップストリームファースト」というモデルを採用しており、これを提唱しています。全ての開発はアップストリームで行われ、ダウンストリームでは製品化を行うということです。

　OPNFVの場合で考えると、OPNFVコミュニティで徐々に作り上げられたコードが、OpenStack、Open vSwitch、Linux、KVMなどのアップストリームに移行するといったことは避けなければなりません。このため、開発は主に、コードが実際にコミットされるべきコミュニティの中で行われることになります。

　OPNFVでは、関連プロジェクトで生み出されるコードを組み合わせるというダウンストリームの作業を行います。「このプロジェクトのこのリリースと、あのプロジェクトのあのリリース」といった形で組み合わせ、ニーズに合わせた構築を進めます。そうしなければ、アップストリームプロジェクトでコードをフォークすることになってしまいます。すると、通信事業者はフォークされたバージョンにロックインされてしまいます。幸いなことに、レッドハットだけではなく、コミュニティ全体、通信事業者も、同じ考えを持っています。

　他のどこにも存在しない新しいプロジェクトが、OPNFVから生まれる可能性はもちろんあります。この場合、私たちがアップストリームになるため、フォークが発生する懸念はありません。

　OPNFVは非常に面白い活動だと思います。活動の一部は、既存のコミュニティと新しい開発者たちとの関係づくりです。そして、通信事業者の言葉で語られてきたこの業界のニーズを、関連するコミュニティにとって意味のある言葉に翻訳して、伝えることにあります。

　OpenStackの開発者に対し、突然「仮想EPC」とか「NFVI」とか言ってみたところで、彼らにとっては退屈でしかありませんから。