注目ブログご紹介

「オープン」なNFVソフトウェアを支える3本の脚


投稿者:Charlie Ashton, 2015/1/29

振り返ってみると2014年は、NFV(Network Functions Virtualization)ソリューションの話になると、必ず「オープン性」が話題になった年でした。ETSIのNFV Industry Standards Group(ISG)の会合はもとより、さまざまな業界イベントでも、サービス事業者は明らかに、オープンなソリューションを利用できるかをNFV化の鍵と見ていました。このブログ記事では、この文脈での「オープン」が実際に何を意味しているかを定義してみたいと思います。私たちの考えに対するご意見をお待ちしています。

オープンソースプロジェクトのOpen Platform for NFV(OPNFV)は、こういったニーズに呼応して発足しました。ETSI NFV ISGとは別のプロジェクトですが、OPNFVの目的を強く後押しているのは、影響力のあるプロジェクトメンバーとして多数参加しているサービス事業者です。OPNFVはLinux Foundationが主催する協業プロジェクトで、高可用性の統合されたオープンソースのNFVリファレンスプラットフォームの開発を目指しています。OpenStack、Open Daylight、KVM、DPDK、Open Data Plane(ODP)といった他のオープンソースプロジェクトとの緊密な協力が見込まれています。

NFVソリューションを開発するソフトウェア企業にとって、この文脈での「オープン」の意味を正確に理解することが重要なのは言うまでもありません。サービス事業者や通信機器メーカーがソフトウェアベンダを評価する際、どんな基準でソリューションが「オープン」かどうかを判断するのでしょうか。

ウインドリバーはお客様との数知れない会話から、「オープンなソフトウェア」ソリューションには基本的に3つの要素があるとの結論に達しました。それはスツールを支える3本の脚のようなものです。1本でも外すと、スツールは倒れてしまいます。オープンであるという主張も同様です。

第1のポイントは、おそらく最も明白なことですが、サービス事業者や通信機器メーカーは、「オープンなソフトウェア」の供給元である企業がオープンソースコミュニティで活動し、関連するオープンソースプロジェクトの主要なコントリビューターであることを当然期待しています。ある企業のコントリビューションの数を確認するのは簡単明瞭なので、この点は隠しようがありません。

ただし留意すべきなのは、キャリアグレードの信頼性のように特殊性の高い分野の場合、コミュニティに送られたコミットの数が、技術的なリーダーシップを表しているわけではないということです。メインストリームのコミュニティは、エンタープライズデータセンターアプリケーションに集中しています。そのため、キャリアグレードのような関心の限られた分野のトピックを対象にしたコミットは、理解、承認されるのに時間がかかります。

このような遅れが見られるのは、キャリアグレードの動作やパフォーマンスに関したOpenStackパッチを提供するときです。そのパッチは、ウインドリバーが通信インフラの先導役として開発した成果でした。OpenStackの用途は大半がエンタープライズアプリケーションなので、通信関連のパッチの多くは、NFV基盤に極めて重要なものであっても、承認までに非常に長い時間待たされてしまいます。これとは反対に、Yocto Linuxプロジェクトに提供した数百のパッチなどは、適用対象が広く、すぐに承認される傾向があります。

スツールを支える2本目の脚は、標準APIです。NFVの重要な前提は、オープンスタンダードによって、互換性のある相互運用可能なソリューションを開発するように多数のソフトウェアベンダを促し、インセンティブを与えるというものです。すでに多くのソフトウェア企業がNFVソリューションを発表しています。その中には、一社で提供する独自仕様の統合型機器に支配されていた従来の通信インフラ市場では、勝負にならなかった企業もあります。ETSI ISGが策定したオープンなNFV規格により、OSS/BSSソフトウェア、オーケストレーションソリューション、VNF(Virtual Network Function)/NFVインフラ(NFVI)プラットフォームのベンダが、ベンダに中立なAPIに準拠するかぎり、この市場で競争できます。

ETSIのNFVアーキテクチャには、企業が標準に準拠しながら、付加価値機能を実現できる高い自由度があります。たとえば、ウインドリバーのTitanium Server NFVインフラプラットフォームの場合、キャリアグレードやパフォーマンス重視の機能を幅広く提供するのに、OpenStackプラグインで実装しています。そのため、OSS/BSS、オーケストレーター、VNFによる利用が可能です。高度な機能を利用して、独自製品の差別化を図ることができます。

「オープンなソフトウェア」スツールの3本目の脚として、サービス事業者や通信機器メーカーが望むのは、ソフトウェアコンポネントレベルでのベンダロックインの回避です。ETSIアーキテクチャのレベル間の標準APIにより、マルチベンダソリューションや、相互運用性(オーケストレーターとVNFなど)を実現できます。同等に重要なのが、アーキテクチャのレベル全体に及ぶ統合型ソリューションへのロックインを回避できることです。お客様は独自仕様のコンポネントを取り入れて、独自性のある差別化を図ることができます。

NVFインフラレイヤがよい例です。ウインドリバーの場合、複数のコンポネントを1つの統合パッケージに組み合わせた、事前にインテグレーション済みのTitanium Serverソリューションに、多数のお客様が多大な価値を見出しています。キャリアグレードLinux、強化KVM、高速仮想スイッチ、キャリアグレードOpenStack、豊富な通信向けミドルウェア機能が揃ったソリューションです。これらのお客様は、統合ソリューションならではの市場投入までの時間的メリットや99.9999%の可用性から、大きな恩恵を得ています。最先端の性能を活用できます。その一方で、独自のLinuxディストリビューションや独自バージョンのOpenStackを持っているお客様もいます。ウインドリバーでは、そういったコンポネントをウインドリバーのコンポネントと組み合わせて対応することが可能です。ただし、キャリアグレードの信頼性が犠牲になることもあります。

以上、お客様との議論をもとに、次のような結論に達しました。NFVの場合、「オープンソフトウェア」企業とは、関連するオープンソースプロジェクトの主要コントリビューターであること、オープンなETSI標準に100%準拠した製品を提供していること、顧客がコンポネントレベルでのベンダロックインを回避できること、この3つの条件を満たしている企業です。3本の脚が揃っていることで、スツールは倒れず、オープンソフトウェアの実効的な供給元を確保できます。

いかがですか。もっとよい定義があるでしょうか。皆様の考えをぜひお聞かせください。