OPNFV、通信事業者はオープンソースをどう受け入れつつあるか：OPNFVディレクターに聞く

　OPNFVはLinux Foundationのプロジェクトの1つだが、ユニークな側面を持っている。OPNFV自体は、基本的にコードを生み出すプロジェクトではない。通信事業者を中心としたNFV（Network Function Virtualization：ネットワーク仮想化）の要件を踏まえ、関連するオープンソースプロジェクトがこれらの要件を満たせるように、コーディネーションや検証を進める活動をしている。

　OPNFVのディレクターであるヘザー・カークシー（Heather Kirksey）氏に、OPNFVの現状を聞いた。

関連プロジェクトとの間にCI/CDパイプラインを構築

――OPNFVの現在の活動を、どう表現しますか？

カークシー氏　OPNFVは結局のところ、オープンソースプロジェクトをインテグレーションする役割を持つプロジェクトです。エンドツーエンドのソフトウェアスタックを構築しようとしています。従って、複数のプロジェクトとの協力関係を深めています。ハードウェアプラットフォーム、OpenStack、OpenDaylight、そして「FD.io」と呼ばれるプロジェクトなどです。

　FD.ioは仮想ネットワーキングで物理ネットワークに匹敵するスループットを得ることを目的としたプロジェクトです。これは約1年前に、Cisco Systems（以下、Cisco）がコントリビューションしたVector Packet Processingを基にしています。現在では、Cisco、Intel、Ericsson、Huaweiなどがメンバーとして活動しています。

――そうしたさまざまなプロジェクトが登場する中で、現在、OPNFVは自らの役割をどのように定義しているのですか？

OPNFVディレクター、ヘザー・カークシー氏

カークシー氏　申し上げましたように、OPNFVはオープンソースのシステムインテグレーションプロジェクトです。

　第1に、複数プロジェクトの機能間に、NFVというユースケースから見て、ギャップ（カバーされていない欠落部）が生まれていないかを見ています。

　最初の例としては、OpenStackを使った際、以前は障害検知に10秒間以上を必要としていました。それでは、携帯電話の通話が切れるなど、使いものにならないケースが出てきます。そこで、OpenStackの複数プロジェクトで修正を実施してもらい、3、4リリースをかけてこの問題を解決しました。他にも、例えばOpenDaylightおよびOpenStackにおけるIPv6サポートの改善があります。

　第2に、構築・統合という側面があります。さまざまなピースが組み合わされたときに、良好に動作するようにする作業です。当初は、OpenDaylightとOpenStackを統合的に使うことが非常に難しく、時間もかかりましたが、統合と検証のプロセスに自動化を導入してこれを支援しました。OPNFVにはさらに、「Pharos Project」という、世界各地にラボのネットワークがあります。X86、ARM、各社のハードウェアソリューションなど、さまざまな環境に導入し、検証を実施しています。

　各プロジェクトではユニットテストを行っていますが、OPNFVではエンドツーエンドのテストを実施しています。例えば障害耐性、サービスチェイニング、レイヤー2／レイヤー3のVPNなどは、関連するソフトウェアを組み合わせてテストしてみないと、確実に動作するのかどうかを確かめられません。

　OpenStack、FD.io、OpenDaylightとの間では、CI/CDパイプラインの統合も実現しています。「xCI」、コミュニティ間のCIと呼んでいますが、これによって最新のコードが自動的に流れてくるため、検証作業がタイムラグなく行えるようになっています。

――ONOSとOpenDaylightは競合する部分があると思います。どのようにこの2つを位置付けているのですか？

カークシー氏　ええ、どちらもSDNコントローラで、ある意味では競合しますが、違うユースケースに向けて最適化が図られています。ONOSは「グリーンフィールド」の、一からの導入に適していて、OpenDaylightは「ブラウンフィールド」、つまり既存の仕組みがある場合に適しています。私たちは、Open Contrailとも連携しています。

　OPNFVでは、ある意味「ビッグテント」のアプローチを採用しています。コミュニティが特定のオープンソースコンポーネントを持ち込みたいということなら、活動に含めるようにしています。

通信事業者はどうオープンソースを使い始めている？

――通信事業者の人々は、基本的にオープンソースソフトウェアや、その考え方を受け入れるのに苦労しているのではないでしょうか。

カークシー氏　通信事業者の世界では、数年前から大きなシフトが既に起こっていると認識しています。こうした人々は確かに厳しい可用性やパフォーマンスの要件を持っています。だからこそ、OPNFVが存在しています。私たちは、各種サービス事業者のニーズを、関連するオープンソースプロジェクトに伝える活動をしています。

　当初は、通信事業者がOpenStackの世界に突然現れて、「私たちにはこういう要件がある。私たちには開発者がいないから、解決しろ」と開発者たちに命令するようなこともありました。これではうまくいくわけがありません。しかし、過去数年で、こうした人々も学習し、自分たちがどう振る舞えば効果的かが分かるようになってきました。

　2017年5月に開催されたOpenStack Boston Summit 2017では、AT＆T、Verizon Communications、China Mobileなどから多数の人々が参加していました。AT＆Tは特に率先して取り組みを進めています。また、私が先ほど話したOpenStackにおける障害検知の改善に関しては、NTTドコモとNECがリードしたことです。

　通信事業者で、多数のソフトウェア開発者を擁しているところが少ない点は、依然として課題ではあります。しかし、より大きな組織では、自社の開発者チームによる貢献を進めているところが出てきていますし、それで足りない部分は、私たちがこのような事業者の望みを関連プロジェクトに伝える手伝いをしています。

　技術だけでなく、人、文化におけるシフトでもありますので、長い時間がかかるのは自然です。

　とはいえ、単一ベンダーによる垂直統合型の設備に慣れていた人たちが、オープンソースコンポーネントの複雑な組み合わせに移行するということは、運用面での大転換だと思います。

　実際には、従来の通信事業者向け設備のベンダーが、現在ではオープンソースソフトウェアを統合するインテグレーターとしての役割を担いつつあります。これをRed Hat、SUSE、Canonicalのような企業が助けています。関連するオープンソースソフトウェア自体も成熟化が進んでいるため、実導入が進む段階に来ています。

　最終的には、Linuxで証明されたように、貴重な開発者のリソースをこれだけまとめ上げ、膨大なコードを生み出しているオープンソースのメカニズムが、短期的には遠回りであるように見えても、長期的には多くの人々の腑に落ちると考えています。

――オープンソースの世界は非常にダイナミックで、次々に新たなプロジェクトが生まれてきます。それが魅力であることは十分理解しています。しかし、純粋な利用者の立場からすると、「動く標的」のような部分があり、いつ何をどう選ぶべきか、どう投資すべきか分からないというのも自然だと思います。

カークシー氏　OPNFVが毎日、大量の自動検証を実施しているのは、こうした課題に応えるためです。こうした検証で問題を発生させたOpenStackのパッチについて、これをマージしないように働き掛けるなどの活動も行っています。ただ、ソフトウェアの世界への移行は、ビジネス面での俊敏性を最大化することを目的として行われます。従って、マインドセットを変えなければならないということは事実ですし、サービスを短い周期で投入していくことを考えるべきだと思います。通信事業者は今や、Webの巨人たちと戦うことになり始めているのですから。