――では、インキュベーション段階を卒業するころには、単一の「言語」にまとまるということなのですか?
ロブ氏 いえ、「業界によって異なる言語を好む」こともあり得ます。NEMOは通信事業者のために存続し続けるかもしれません。カギは柔軟性と複雑性のバランスにあります。例えばエンドポイントをグループ化し、相互間のコントラクトやポリシーを定義するといった抽象化をするとき、どれくらいの粒度でこれを行うのかは、実装によって異なります。どの言語がいいのかは簡単に決められません。ユーザーがそれぞれのAPIセットを見て、自分たちが解決したい問題と照らし合わせ、いずれかの言語を選ぶことになると思います。その過程で、淘汰が起こると思います。
既に上述のプロジェクト間では連携が見られます。例えば、Network Intent Compositionの最初のリリースでは、Group Based Policyをレンダリングエンジンとして使っています。つまり、Network Intent Compositionは自身のNorthbound APIを持っていますが、Group Based Policyのサービスと連携し、そこからOpenFlowなどを制御します。ただし、Network Intent Compositionの次のリリースでは、一部の機能でGroup Based Policyを使わない実装も行われようとしています。NEMOは新しいプロジェクトなのでまだ分かりませんが、まずは恐らくGroup Based Policyを使うことになるでしょう。Group Based Policyは、OpenDaylightにおいて最も成熟したレンダリングエンジンだからです。
――工藤さんにお聞きします。工藤さんがOpenDaylightで最も面白いと感じていることは何ですか?
工藤氏 私はNECと、OpenDaylightのアンバサダーの二つの“帽子”を被っています。NECは、当初「Virtual Tenant Network(VTN)」で貢献しましたが、最近、先ほど話に出たNetwork Intent Compositionのプロジェクトを始めました。これはONFが標準化を進めるNorthboundインターフェースを実装するものです。
このプロジェクトで特に感じるのは、OpenDaylight内の多様なプロジェクトが、有機的かつダイナミックに、つながったり離れたりしていることです。しかもそれが、特定ベンダーや特定個人の意思ではなく、コミュニティ全体の合意の中で進んでいます。これは難しい反面、非常に面白いです。
Northboundインターフェースは本来、非常に難しいものですが、多様なベンダーが集まり、多数のプロジェクトが動いています。それだけでなく、アドバイザリーボードとして、通信事業者などが要望をインプットしています。また、世界中のユーザーグループからもフィードバックがあります。今、OpenDaylightは内も外も大きく動いています。
OpenStackのネットワークに関しては、いろいろな実装が考えられます。Neutronでの実装も可能ですが、Neutronでは、レイヤー3やDHCPなどのエージェントを一つずつ動かして、サービスを実行する構造になっています。これらの各種サービスは、OpenDaylightという単一のコントローラーにオフロードできます。さらにOpenDaylightコントローラーは、サービスチェイニングなどの付加価値を容易に組み込めるポテンシャルもあります。これはOpenDaylightの強みであり、力を入れていきたい部分です。
ネットワーク関連ではいろいろなアプローチが出てきており、現時点で「正解」を見出すのは難しいと思います。しかし、いろいろな技術が、OpenDaylightという場で生まれて成長し、あるものは消えていき、あるものは統合する。そうした実験場、サンドボックスの役割を果たしている点が、私にとって刺激的です。
――ありがとうございました。
Copyright © ITmedia, Inc. All Rights Reserved.