OpenFlowはイノベーションの速度を上げる。開発者マーチン・カサード氏によるOpen Network Summit 2011基調講演(後編)

2011年11月25日

ネットワークの機能をソフトウェアで定義してしまおうという「Software Defined Network」をテーマにしたイベント「Open Networking Summit」が、10月11から米国スタンフォード大学で開催されました。

OpenFlowの開発者であるマーチン・カサード(Martin Casado)氏による基調講演の前半では、OpenFlowの開発の経緯、アーキテクチャについて説明。後半ではOpenFlowのもたらす価値やネットワーク業界にもたらすインパクトなどについて解説しています。

(本記事は「OpenFlowはなぜ生まれたのか? 開発者マーチン・カサード氏によるOpen Network Summit 2011基調講演(前編)」の続きです)

OpenFlowはインフラでイノベーションを起こす

ここではOpenFlowとSDN(Software Defined Network)に関する、よく聞かれる質問について答えよう。

まず、OpenFlow/SDNの主要な価値とは何か。信じられないかもしれないけれど、本当の価値は、みんながインフラの中でイノベーションを起こせるということ。

僕らが研究を始めた頃は、インフラでのイノベーションに興味を持つのはグーグルくらいだと思っていた。けれどもこれは明確に間違っていた。

いま、僕らは通信キャリアや金融機関、ホスティング企業、フォーチュン100に入るような大企業とも仕事をしている。こうした企業の多くが競争力を高めるためにネットワークのイノベーションを実現している。

これは一部の企業だけではなく、誰もが気にしていること。なぜかというと、これまでサーバで、ストレージで、データベースでイノベーションが起きてきたから。ネットワークでイノベーションを実現しないなどという理由はない。

それからこれは間接的なものだから説明しにくいのだけれど、OpenFlowは業界を水平方向への統合(Horizontal Integration)に向かって動かしているということ。これは僕にとって2つの意味がある。

1つ目は、僕にはそれほど興味のないことだけど、すべてのレイヤで競争が起こるということ。いいことだ。でもそれが分かるまでには時間がかかるだろう。

技術的にとても面白いと思うのは、レイヤを分離することでよい製品の登場が早まること。ソフトウェアをデザインするようなスピードでシステムのイノベーションが起きる。僕がかかわっている仕事では、実に6週間ごとにメジャーな新機能を開発している。システムから機能の実装が分離されているからこそ、こんなすごいことができる。

ネットワークもこうしたイノベーションスピードを持つべき時期だ。

OpenFlowは新しい機能を提供するわけではない

OpenFlowは新しい機能を提供するのか? そういうわけではない。OpenFlowはチップセットを変更するわけじゃないし、ハードウェアも変更しない。単なるインターフェースだ。何も新しいものを提供するわけじゃない。

「OpenFlowはネットワーク仮想化にいいんだってね」って最近言われた。確かに使えるけれど、ネットワーク仮想化のパイオニアはOpenFlowは使っていない。シスコやVMwareがすでに何年も製品を提供している。

一方で、(OpenFlowが実現する)SDNでは、これまでできなかったことができるようになる。ネットワーク仮想化の製品を見てみると、その内部にSDN的な機能を備えていることがわかる。業界が向かっているのはSDNのスタイルなんだ。それがこれまでの問題を解決することだから。そして大事なのは、それがオープンであり、ソフトウェアによって起きているということだ。

OpenFlowはスケールする、巨大なシステムであっても

SDNはスケールするのか? 最初に論文を書いたときからスケールについては質問された。もうみんな納得してると思うけれど、2つの逸話を紹介したい。

スケールについて答えはイエスで、SDNはスケールする。なぜスケールしないと思ってる人がいるのか、それは僕らがいつも集中管理(Centralization)の話をするからだろう。説明したように、SDNは集中管理とは関係なくて、ディストリビューションモデルはどれでも選べる。

そしてこの会場にいる人たちはみんなどれくらいのスケールのシステムでOpenFlowが使われているか、数字を見たことはないだろう。僕も数字を言っている人を見るのは、NDAを結んで部屋の片隅でひそひそ話をしているときくらいだ。

でも僕たちはすばらしいシステムを作ったことを誇りに思うべきだし、このシステムを作った人は数字を引用してほしい。だから僕からはじめよう。僕は500以上のスイッチまでスケールできて、数十万ものイベントを管理できるシステムに関わっている。フローも任意の数だけある。すんごいでっかいシステムだ。さらなるテストをしていないのは、必要がなかったからだ。

僕はほかにもすごく大きなOpenFlowでのグローバル運用があるのを知っている。だからみんな堂々と言おうよ。そうすれば多くの誤解もなくなるだろうから。

OpenFlow成功の要因はコミュニティにある

ここで、なぜOpenFlowが成功してきたのか、先に進むことがどういう意味なのかを考えてみよう。なぜこんな話をするのかというと、先に進むにあたって熱気に包まれて自分たちを見失いたくないからだ。

僕はこれだけ早く人気が出たことにショックを受けている。僕の知る限り(OpenFlowを)サポートする4つか5つの商用スイッチがすでに出荷されている、もっとあるだろう。OpenFlowを使っているプロジェクトもたくさんある。スタートアップ企業や多くの企業も使うと言っている。

fig

なぜこんなに成功したのだろうか。OpenFlowはすごく新しいアイデアだったからだろうか。いやそうじゃない。システムからの分離やデータプレーン、コントロールプレーンについてはみんな何年も前から話をしていた。

では、OpenFlowの設計がすばらしかったから? 違う。正直に言って初期の段階でめちゃくちゃになったこともある。初めはわからない問題があって最近直したものもある。

じゃあ新しい機能を提供したから? SDNの考えはすでにあったし、OpenFlowはここで特に面白いことを提供したわけではない。

なぜOpenFlowが成功したか、僕はしばしば考えるんだけど、率直に言えば答えはコミュニティ、ここにいるみなさんだと思う。

ソフトウェアを通じてネットワークをよくするという共通のビジョンから、僕たちはとても幅広くいろんな人が集まるコミュニティを作り上げた。単なる技術者のコミュニティじゃない。起業家もいればマーケターもいる。プロジェクトリーダーもいるしリサーチャーもいるし、研究機関や管理職、流通、OEMベンダなどいろんな人がいる。これが他で起こってるムーブメントと違うところだ。

OpenFlowの信頼性を高めていき、採用や利用を促進した主な要因はすべてコミュニティから起こっていた。別に技術的なスタンダードがあったからじゃない。それはそれでとても重要なんだけど。

だから最後にどうしても言いたいのは、このムーブメントはコミュニティにかかっていると言っていい。このコミュニティを培っていくのは僕らみんなの責任なんだ。

(以下がマーチン・カサード氏の基調講演のビデオ)

OpenFlow関連記事

あわせて読みたい

ハードウェア OpenFlow ネットワーク




タグクラウド

クラウド
AWS / Azure / Google Cloud
クラウドネイティブ / サーバレス
クラウドのシェア / クラウドの障害

コンテナ型仮想化

プログラミング言語
JavaScript / Java / .NET
WebAssembly / Web標準
開発ツール / テスト・品質

アジャイル開発 / スクラム / DevOps

データベース / 機械学習・AI
RDB / NoSQL

ネットワーク / セキュリティ
HTTP / QUIC

OS / Windows / Linux / 仮想化
サーバ / ストレージ / ハードウェア

ITエンジニアの給与・年収 / 働き方

殿堂入り / おもしろ / 編集後記

全てのタグを見る

Blogger in Chief

photo of jniino

Junichi Niino(jniino)
IT系の雑誌編集者、オンラインメディア発行人を経て独立。2009年にPublickeyを開始しました。
詳しいプロフィール

Publickeyの新着情報をチェックしませんか?
Twitterで : @Publickey
Facebookで : Publickeyのページ
RSSリーダーで : Feed

最新記事10本