最近、筆者の周辺ではネットワークの制御に利用する「OpenFlow（オープンフロー）」という技術が話題だ。OpenFlowはもともと2008年にスタンフォード大学などを中心に設立された「OpenFlowコンソーシアム」が提唱し、実証実験を重ねてきた技術である。2011年にはしっかりした規格策定のため、新たに設立された「Open Networking Foundation」という団体により標準化作業が進められている。

　Open Networking FoundationにはNEC、NTTグループのほか、世界のルーターやスイッチのベンダー、通信事業者が参加している。そのほか、米グーグルや米マイクロソフト、米フェイスブックなどのクラウドサービス事業者も名を連ねていることから、にわかに注目を集めている。ここではなぜOpenFlowのような技術が話題になりつつあるのか、国内のIaaS事業者に聞いたデータセンターネットワークの課題などをヒントに見ていこう。

経路計算をコントローラに分離

　まずはOpenFlowの仕組みを簡単に紹介する。従来の一般的なスイッチでは、ハードウエアベンダーが作ったボックス型の機器に経路計算とフレーム転送の機能が同居している。一方、OpenFlowのネットワークは「OpenFlowコントローラ」と「OpenFlowスイッチ」と呼ばれる2種類のノードから構成される。経路計算など、ネットワークの「頭脳」に当たる機能はOpenFlowコントローラに分離。OpenFlowスイッチはOpenFlowコントローラの指示に従って、フレームの転送など比較的単純な処理を実行する。OpenFlowコントローラとOpenFlowスイッチの間で情報をやりとりする際に使うのが、OpenFlowプロトコルだ。

　どんな風に経路が決まるかもう少し具体的に説明すると、管理者はあらかじめOpenFlowコントローラに対して「フローテーブル」と呼ばれるルールを記述しておく。フローテーブルでは、「どんな種類のフレーム」を「どんな風に処理するか」を定義する。例えばOpenFlow 1.0ではレイヤー1からレイヤー4の12種類の情報を組み合わせてフレームを指定し、「転送」「廃棄」「指定したキューに入れる」「指定したフィールドを書き換える」といった処理をすることが可能だ。OpenFlowコントローラはOpenFlowスイッチにフローテーブルのルールを書き込んでやり、OpenFlowスイッチはそのルールに従って動く。

　従来のネットワークは、レイヤー2ではイーサネット、レイヤー3ではIPなど、複数の異なるプロトコルを組み合わせて構成される。ネットワーク管理者はスイッチなどの機器を購入し、一つひとつの機器に対して、VLAN（Virtual LAN）や各種の冗長化プロトコルなどの設定を保存するのが一般的だ。プロトコルの動作は標準規格によって、スイッチの設定方法はベンダーによってあらかじめ決められている。

　ところがOpenFlowを利用する場合は、ネットワーク管理者がフレームの処理を自由にプログラムで記述できる。いちはやくOpenFlowプロトコルに対応したスイッチを発売したNECが、自社のOpenFlow対応製品を「プログラマブルフロー」と命名したのは、この特徴を前面に押し出したものだろう（関連記事：「世界初」、NECがOpenFlowスイッチをついに製品化）。

　以上のような仕組みを理解すると、OpenFlowのメリットがわかりやすくなる。メリットの一つは「既存プロトコルの制限にとらわれず自由なネットワーク設計ができる」ことだ。例えば近年のデータセンターでは、仮想化技術の発展によってサーバーの拡張や移行が容易になってきた。

　ところが、ネットワーク側がサーバー拡張の柔軟性についていけていないところがある。代表的な例として、ここでは国内でIaaSの構築を進める事業者に聞いた、VLANの設定について説明しよう。この事業者ではVLANを使って、目的ごとに論理的なネットワークを構築している。こうした環境で仮想マシンのライブマイグレーションを利用する場合、移行先となる物理サーバーには、移行元と同じVLANを設定しておかなければならない。サービスの規模が大きければ大きいほど設定すべきVLANの数と運用の手間は増え、人為的ミスの発生率も高くなる。また、現在一般的に使われているタグVLANは、一つのネットワークで使える数に4094個という上限がある。これはIaaSを構築する事業者にとっては、決して十分な数ではないという。

　こうした環境にOpenFlowを導入すると、どうなるだろうか。スイッチのポート番号やあて先MACアドレスごとに別々の経路を通るようにプログラムで定義して、OpenFlowで論理的にネットワークを分割することができる。VLANを使わずにネットワークを論理的に分割できれば、VLANの上限数を気にしなくてもよくなる。

　上記のVLANは一例に過ぎない。例えばTCPやUDPのポート番号を指定して、それぞれ処理を変えることも可能だ。つまり送信元やあて先が同じでも、アプリケーションの種類によって経路を変えられる。OpenFlowを使うと、ネットワーク管理者の発想次第で、今までとは異なる柔軟なネットワーク制御ができそうだ。

　もちろん、自社の業務またはサービスに合わせてOpenFlowを使いこなし、一からネットワークをプログラミングするような企業は、現時点では少数だろう。OpenFlowで複雑な処理を実現するためには、OpenFlowコントローラの作り込みも必要になる。ただ、米グーグルをはじめとするクラウドサービス事業者は、クラウドに必要な基盤技術を自社で開発している。それを思えば、「今までにないサービスを実現したいと考えている」「自社サービスの目的がはっきりしている」「開発力がある」――といった事業者にとって、OpenFlowのようなプログラマブルなネットワーク技術は魅力的と言えそうだ。

　もう一つ、仮にOpenFlowが広く普及した場合に考えられるメリットとしては「コモディティ化したスイッチで安価にサービスを構築できる可能性がある」点もあるだろう。OpenFlowでは、スイッチ側はフレーム転送のような比較的簡単な処理しかしない。そのため、安価で単純な機能のスイッチがあれば十分で、ベンダー独自のリッチな機能を実装したスイッチへの依存度が低くなる可能性があるというわけだ。

　NECの実装では、OpenFlowスイッチとOpenFlowコントローラをそれぞれ独自のハードウエアとして開発している。しかし、これらはサーバー上のソフトウエアとして実装することも可能だ。すでに複数のオープンソースのOpenFlowコントローラがあるほか、オープンソースの仮想スイッチ「Open vSwitch」はOpenFlowに対応する。このようにOpenFlowに対応した仮想スイッチなどを活用すれば、OpenFlow対応の専用ハードウエアは必須でなくなる可能性もある。

まだ評価の定まらない過渡期の技術

　とはいえ既存プロトコルにさまざまな制限や課題があることは、かなり前から指摘されてきたことだ。そのためネットワーク機器のベンダーは、こうした課題を補う機能を自社製品に搭載し始めている。

　例えば「VLANの設定をライブマイグレーション時に追随させる」といった機能に関しては、一部ベンダーのプロプライエタリな技術でも実現できる。さらに、IEEEなどで仮想環境を想定したネットワーク技術の標準化が進められているため、将来的には異なるベンダーのスイッチ間でもライブマイグレーション時の設定変更を自動化できると期待される。このように既存プロトコルの延長線上にある、機器ベンダー主導の技術が多勢を占めるのか、OpenFlowのようなソフトウエアベースの新しい考え方が普及するのか。今後数年の注目テーマと言えそうだ。