特別企画
OpenDaylightの現状とこれから～技術運営委員会チェア デヴィッド・マイヤー氏に聞く
（2014/7/2 06:00）
ネットワークベンダー各社が顔をそろえるオープンソース・プロジェクトとして注目を集めたOpenDaylightは、今年2月4日に最初の成果物である“Hydrogen”をリリースした。同日付でIBMがHydrogenベースの商用製品として「IBM Software Defined Network for Virtual Envronment OpenFlow Edition」等を発表するなど、順調に推移しているようだ。
ここでは、6月中旬に幕張メッセで開催されたInterop Tokyo 2014の基調講演に登壇したOpenDaylightの技術運営委員会チェアのデヴィッド・マイヤー氏にOpenDaylightの現状について聞いた。
OpenDaylightが作る6項目
OpenDaylightの技術運営委員会チェアのデヴィッド・マイヤー氏は、Interop Tokyoの基調講演のスピーカーとして登壇し、「OpenDaylight：オープンソース・ネットワークの過去、現在、そして未来」と題する講演を行った。
同氏はまず、OpenDaylightについて「業界がサポートする共通プラットフォームを作ることでSDNの採用と革新を推進していく」ことがゴールだと語った。
そして、プロジェクトの創設当初に“オープンソースのOpenFlowコントローラを作る”と説明されていたことを意識してか、OpenDaylightが作るものとして「SDNプラットフォーム」「ノースバウンドの機能の標準的な抽象化」「各種サウスバウンドの相互連携」「プログラマブルなネットワークサービス」「ネットワークアプリケーション」「エンジニアリング・システムを含むその他必要なものすべて」という6項目を挙げた。
さらに、OpenDaylightは傘下に多数のサブプロジェクトを擁する“アンブレラ・プロジェクト”だとも言明した。この辺りが、OpenDaylightの現状を明確にするための説明だと言えるだろう。
3つのエディションがリリースされたHydrogen
次いで同氏は、2月にリリースされた“Hydrogen”の説明を行った。当初Hydrogenのリリースは2013年12月の予定だったが、2カ月ほど遅延したという。Hydrogenリリースでは、用途に応じた3種類のエディションが設定された。基本となる“Base Edition”は、いわば“OpenFlowコントローラ”で、多分プロジェクト開始当初にイメージされていたOpenDaylightのイメージに最も近いものだろう。
“Service Provider Edition”はキャリア／通信事業者等での利用をイメージしたもので、Base EditionにSNMPやBGP-LS、DDoS Protectionなどが追加されている。また、Virtualization Editionは、OpenStackとの連携機能などを強化したものだ。Service Provider EditionとVirtualization Editionは組み込まれているモジュールが異なっており、包含関係にはなく、むしろ並列的な関係となる。
OpenDaylightの開発コード名は元素周期表から採られている。最初のリリースである“Hydrogen”は水素の意味で、以後のリリースはHelium（ヘリウム）、Lithium（リチウム）と続いていくことになる。OpenDaylightではリリーススケジュールなども明確に定められており、各リリースは数回のマイルストーン・リリースを経てリリース候補（RC）を出し、最終リリースへと至る明確なスケジュールが設定されている。
それでもHydrogenのリリースは当初予定から遅延したわけだが、講演で紹介された現状のスケジュールでは、次のHeliumリリースが今年9月29日、その次のLithiumリリースが2015年4月20日に予定されているという。
SDNプラットフォームの実現を目指すOpenDaylight
基調講演の後、ごく短時間であったが同氏に補足説明を聞く機会があったので紹介したい。なお、同氏は米Brocadeのサービスプロバイダー担当Chief Technology Officer（CTO）兼Chief Scientistという立場でもあるので、BrocadeのソリューションとOpenDaylightの関係についても簡単に言及してもらった。
――OpenDaylightはOpenFlowコントローラか、SDNプラットフォームか？
OpenDaylightでは、当初からOpenFlowコントローラの実装にとどまらず、より広範なデバイスのコントロールが可能な“SDNプラットフォーム”の実現を目指していた。
OpenFlowの活用を前提に、スイッチは極力単純であるべきだという意見がある一方、ネットワーク機器はより高度なインテリジェンスを備えたほうがよいという声も存在する。そのため、OpenDaylightはその両方をサポートできるプラットフォームを実現することで、より広い市場に受け入れられると考えたためだ。
OpenFlowコントローラとしては他にもオープンソース・プロジェクトが存在しているが、それらの多くはOpenFlow環境向けに最適化された実装を行っている。
一方OpenDaylightは、プラットフォームとして、より広範な環境のサポートを想定した実装を行っている点が違いとなる。
3種類のEditionをリリースしたのは、あくまでもユーザーの使いやすさを意識してのことだ。実際には、ユーザーが任意にさまざまなモジュールを組み合わせて使うことができる。ただし、モジュールの組み合わせても問題が生じないことを確認するためのテストなどが必要となるが、プロジェクトとしてあらかじめテストを済ませ、問題ないことを確認した「お勧めパッケージ」としてEditionを設定したと考えてよい。
ユーザーが任意のモジュールを組み合わせて独自の“Edition”を構築できるようなツールも出てきており、Heliumではこうした環境を前提に構築を進めているので、将来のリリースではより自由度が高まると考えられる。
安定性か機能拡張か
――OpenDaylightの開発の方針は？
ソフトウェアというものは本質的に不安定さを内蔵しているものであり、新機能を追加すれば同時に不安定さや脆弱性も増えてしまうものだ。OpenDaylightでは“Stability Release”を提供し、機能拡張をフリーズして安定性向上のための改善を行う計画になっている。
機能を求めるか安定性を求めるかはユーザーの考え方によってどちらかを選ぶものであり、両方を同時に満たすうまい方法はまだない。その点は、オープンソースでもベンダーが開発する商用ソフトウェアでも全く同じことであり、新機能の追加は同時に新しい欠陥をも生み出すことになるものだ。
開発に関与する人数をごく少数に限定することでバグを減らす、というアプローチもあるが、バランスが難しい。やり過ぎてしまうと“スカイネット”のようなことになってしまう。
編集注：スカイネット
映画「ターミネーター」で人類抹殺を企てる悪役と設定された、自我に目覚めたコンピューターシステムのこと
なお、OpenDaylightは、ユーザーの直接利用も、ベンダーが付加価値を付けて自社製品のコアとして利用することも、両方の用途を想定して開発している。OpenDaylightはEclipseスタイルのオープンソース・ライセンスを採用しており、これはオープンソースの開発スタイルとベンダーでの利用の両方を実現するためのライセンスとして選定されている。
エンドユーザーが直接利用するためにはある程度の完成度が求められる。特にオープンソース・プロジェクトでは、最初のリリースは一般的に“デベロッパー・リリース”と見なされることが多いのも確かだ。
しかし、Hydrogenではエンドユーザーがそのまま使えるような機能と安定性のバランスを達成することを開発目標として掲げており、実際にその目標が達成できたものと考えている。だから、将来のリリースを待つのではなく、Hydrogenをすぐに使い始めてもらって問題ないはずだ。
もちろん、まずはOpenDaylightに参加しているメンバー企業が開発成果を活用して製品化する動きが活発化しているので、そうして市場に投入される製品を利用するユーザーが増えていくだろう。Eclipseライセンスでは、OpenDaylightのコードを元に独自開発した成果を必ずオープンソース化しなくてはいけない、という制約はなく、オープンソースのコードとベンダーのプロプライエタリ・コードを組み合わせて使うことも問題なくできる。
この点はGPLと異なる点で、OpenDaylightではGPLを適用するのは適切ではないと判断したのも、こうした使い方を当初から想定していたためだ。ベンダーが独自に開発したコードをオープンソース化するかどうかはベンダーの判断に任されているので、オープンソース化して広く普及させるか、自分たちだけのコードにとどめるか、任意に選択する自由があるが、各ベンダーから多くのコードがコントリビューションされているのも事実だ。
さまざまなプラットフォームとの連携を考慮
――他のプラットフォームとの連携をどう考えているか。
Brocadeでは、イーサネット・ファブリックの商用化の段階でSDNと同様の問題を解決する高度な運用管理機能を実装してきており、一部はOpenDaylightが実現している機能との重複もある。これらのさまざまな運用管理インターフェイスをどう統合するのか、という課題が生じるわけだが、現時点では詳細まで確定しているわけではない。例えば、OpenDaylightからコントロール可能なサウスバウンド・インターフェイスとしてファイバチャネル（FC）をサポートする、といった可能性も考えられるだろう。
また、OpenDaylightではOpenStackとのインテグレーションにも積極的に取り組んでいる。OpenStackは広範な支持を集めているので、OpenDaylightのようなプラットフォームを使う場合も、運用管理担当者はまずOpenStackをインターフェイスとして利用し、OpenStackからOpenDaylightを呼び出す、という形にまとまると予想される。
ただし、OpenStackとOpenDaylightがどのように連携し、どのように機能分担するのか、という点はまだ完全に固まっているわけではないのも事実だ。具体的には、OpenStackの開発コミュニティの中には、SDNのための機能をOpenStackのネットワークモジュールであるNeutronに実装すべきだという意見もあるようだ。
一方で、OpenDaylightでは必ずしもクラウド環境だけを想定しているわけではないので、どのような環境でもサポートでき、かつ両者が問題なく連携できるようにするためには今後もチャレンジがあるだろう。
OpenStackとOpenDaylightがどのように機能分担するか、という点について、俯瞰（ふかん）的な立場で全体のデザインを考えるアーキテクトが決まっているわけではない。オープンソース・プロジェクトにおいては最終的には実際にコードを書く個々の開発者がそれぞれ意志決定を行うことで全体の方針が決まっていくのが基本だ。NeutronにSDNのためのコードを書く人が現れるかどうかが問題だろう。
なお、OpenDaylightのリリースサイクルに関しては、OpenStackのリリースサイクルにも合わせ、将来的にもおよそ半年ごとのリリースというスケジュールを継続していきたいと考えている。