OpenFlow/SDNはなぜ誕生したのか、OpenFlow以前にあった問題とは。生みの親カサド氏が壇上で語る。SDN Japan 2013

2013年11月6日

世界で最もセキュリティの高い米諜報機関のネットワーク管理の経験から生まれたのがOpenFlowおよびSoftware-Defined Networkingの技術だった。

OpenFlowの生みの親として知られ、現在はVMwareでネットワークチーフアーキテクトを務めるマーティン・カサド(Martin Casado)氏は、9月18日から3日間、都内で開催されたイベント「SDN Japan」において、OpenFlow開発の経緯について基調講演「SDN、ネットワーク仮想化、そして無限の彼方へ」で語りました。

その内容をダイジェストで紹介しましょう。

SDN、ネットワーク仮想化、そして無限の彼方へ

VMware Inc, Martin Casado氏。

fig

Software-Defined Networking(SDN)やOpenFlow、ネットワーク仮想化の話題は非常に盛り上がっていますが、それはこれまでに携わった数千人もの人たちのおかげです。

fig

まずOpenFlow開発前の話をしましょう。

OpenFlow開発前(2002~2003)

私はコンピュータを使って物理学上の問題を解決する計算物理学を専門にしていました。その最初の仕事として、国立研究所でモデリングをしていました。ところが9.11が起きて、その結果、計算物理学から諜報機関のネットワーク担当へと異動させられました。

これは、世界で最もセキュリティの高いネットワークです。もしここに問題があったら人々の命に関わります。

そこで気がついたのは、ネットワークはコンピュータとまったく違う、ということです。コンピュータではセキュリティを実装するにはプログラミングをすればいい。ところがネットワークへのセキュリティの実装はそうできないのです。

fig

このネットワークのセキュリティを強化するには、ルータにポリシーを入れてトポロジーを明確な形で構成しなくてはならず、トップオブラックとそれ以外のルータのポリシーも違うし、たくさんのコンフィグレーションをしなくてはなりません。

冗長性はほとんどないため機器が故障すれば可用性に問題が出るし、トポロジーには制約があり、機能や構成を変更するには手間がかかり、トポロジーの変更は手作業で行わなければならないし、自己治癒機能もありません。

こうした問題はソフトウェアやオペレータの不備ではなく、アーキテクチャの問題だと思いました。

実際のネットワークには、スイッチのテーブルにはフォワーディング情報が書き込まれていてパケットを制御しています。この情報はアルゴリズムによって分散しています(青い枠のところ)。

fig

ところがそれ以外にもタギングやQoSなどのコンフィグレーションがあり、それらは人手によって構成し管理されていて、アルゴリズムでは管理されていません(赤い枠のところ)。

これがアーキテクチャ上の問題だと私が考えるところです。人間が行うステート管理は遅いし間違えやすい。

また、もしこれがプログラムによって制御できるとしても、当時はそのためのAPIをスイッチが備えていませんでした。当時私は政府で働いており、十分な予算もありましたが、それでもAPIを備えたプログラマブルなスイッチは入手できませんでした。

それにもし仮にプログラマブルなスイッチがあったとしても、完全に分散された機器のプログラミングは難しいものです。

そこで私は諜報機関を辞め、スタンフォード大学でこのような問題の解決に取り組むことにしました。

OpenFlowの開発(2004年~現在)

私たちが求めようとしていたのは、どうやってネットワークをプログラミングするか、です。これは技術的に言うとネットワーク上のすべてのデータパスステートをプログラム的に管理する方法、ということになります。

最初の問題は、フォワーディングの抽象化が不十分だったことです。ネットワークが固定化された機器の機能に依存し、状態管理のためのAPIも標準化されていませんでした。

そこでデータプレーンを汎用化し、それをハードウェアで実装できるようにしました。

fig

2つめの問題は、これまでのネットワークは分散モデルであり、分散モデルに対応したプログラミングは難しい、ということでした。

そこで分散モデルをトポロジーから分離し、どのようなプログラムでも書けるようにしました。

fig

その結果として構成されたアーキテクチャは、シンプルでいままでとは異なるものとなりました。

fig

制御アプリケーションにたくさんのアプリケーションを書けるようにしたらどうか、ということでこれをプラットフォームとするNetworkOSという考え方も出てきました。こうしたことを考え始めたのが2007年でした。

fig

そして2009年4月、MIT Technology Reviewの記事を基に「Sofware-Defined Networking」が命名されたのです。

fig

フォワーディングを汎用化する、そして分散モデルをプログラマブルにする。これがSDNです。

しかしSDNとは何なのかについて、記事やマーケティングなどによって多くの混乱がもたらされました。

OpenFlow/SDNのFAQ

そこで、SDNの価値についてここで明確にしておきたいと思います。

SDNの価値は何か? 私の視点では、それは「ネットワークの革新が可能になる」ということです。新しいネットワークを構築するときにSDNを使えば、よりよくできます。

しかもより高度な制御、分散化できない複雑なアルゴリズムも、SDNを使えばできるようになります。

マーケットにも変化が起こるでしょう。ハードとソフトが切り離されることで各レイヤーでの迅速な革新が起き、市場の効率がよくなります。SDNによって水平方向の統合に向かっているのです。

SDNはスケールするか? という質問もありました。2年前は、SDNがまだ登場したばかりであり、5000のホストでテストしたばかりでした。しかし今は10万のホストでテストされています。いまは本番のシステムで使われているという実績もあります。答えはイエスです。

それからこれは私の好きな質問なのですが、「SDNによってネットワークのプログラミングは簡単になりますか?」という問いについて、私の答えはむしろ「ノー」です。

fig

図の左が従来型のプログラミングモデルです。スイッチやルータがネットワークのトポロジーを形成し、制御プログラムがトポロジーに作用する。

右はコントローラがトポロジーを形成し、ロジックがそのトポロジーで働く。コントローラがスイッチやルータを管理し、コントローラ間のコミュニケーションも必要。SDNはパワフルですが、難しい面もあります。

コントローラを作ることは難しくありませんが、ちゃんと機能するものを作るには多くの努力が必要です。

SDNとネットワーク仮想化

SDNとネットワーク仮想化については多くの誤解があるので、私の観点から紹介しましょう。

SDNはあくまでメカニズムであって、それは直接的にはお客様の問題を解決するものではありません。エンジンは自動車ではありませんが、エンジンがない自動車は動かない。SDNはエンジンに相当します。

ネットワーク仮想化は、お客様の運用上の問題を解決するものです。

fig

原理的にはSDNをもってしても、各スイッチや各リンクを管理しなければなりません。仮想化では仮想化レイヤーを設けて、物理レイヤーから分離されたトポロジーが浮かび、シンプルなビューで管理できるようになります。

SDNは仮想化を実装する方法としては素晴らしいものですが、ネットワーク仮想化そのものではないのです。

あわせて読みたい

ハードウェア OpenFlow Software-Defined Network ネットワーク




タグクラウド

クラウド
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本