OpenFlow/SDN、誤解の構造【第3回】
【技術動向】SDNはなぜ誤解されるのか
「Software Defined Networking(SDN)」という言葉の意味はあまりにも多様化し、議論がかみ合わなくなってしまっている。議論が深まるような、この言葉のより建設的な定義とはどういったものなのかを探る。
本連載の第1回「【技術動向】OpenFlowはなぜ誤解されるのか」、第2回「【技術動向】OpenFlowに対する4つの誤解を検証する」では、OpenFlowに関する誤解について説明した。今回は、Software Defined Networking(SDN)についての誤解が生まれる背景について説明する。
OpenFlowは技術仕様だが、SDNは異なる。このため、人によってこの言葉で何を意味するかに違いが生じるのは仕方がない。だが、人によってあまりにも違いがあるため、議論がかみ合わなくなるとともに、混乱が生じているのは大きな問題だ。SDN関連製品に関わっている人々や専門家的な立場にある人々からIT系のメディアや記者に至るまで、それぞれが自らの立場や琴線に触れる情報に基づき、あるいは取材対象に振り回されて異なる意味でこの言葉を使うため、これらの人々の発信する情報に接する人々はさらに混乱してしまう。
一説によると、この言葉はもともとOpenFlowを生み出したスタンフォード大学研究所の担当教授であるNick McKeown氏が、技術に詳しくない記者の取材を受けていた際に生まれた言葉だという。その記者が自らの理解のために「OpenFlowとはSoftware Defined Networkingのようなものか」と確認し、McKeown氏はこれに「そうだ」と答えたというのが始まりだという。
これが事実ならば、SDNはOpenFlowを分かりやすく説明するためのフレーズでしかないということになるし、そのままだったら現在のような注目を集めはしなかっただろう。従って、起源から正しい意味を把握しようとするのは、この言葉に関しては無駄な行為といえる。
ONFにとって、SDNはアーキテクチャ
では、OpenFlowおよびSDNの推進団体であるOpen Networking Foundation(ONF)はどう言っているか。ONFはSDNを、「あらゆるネットワークを、ソフトウェアでプログラミング可能にするアーキテクチャ」だと表現している。
ONFのホワイトペーパー(PDF)「Software-Defined Networking ネットワークの新常識」(日本語版)には、次のような表現がある。
「SDNアーキテクチャでは、コントロールプレーンとデータプレーンが分離し、ネットワークインテリジェンスとステートが理論的に一元化され、それを支えるネットワークインフラストラクチャは、アプリケーションに対して抽象化されます」
さらに、次のように説明している。
「ネットワークのインテリジェンスは、ソフトウェアベースのSDNコントローラに(論理的に)一元化され、ここでネットワークの全体像が管理されます。その結果、アプリケーションやポリシーエンジンには、ネットワークが、あたかも一台の論理的スイッチのように見えるのです。SDNによって、企業・通信キャリアは、ベンダーに依存せずとも、ネットワーク全体の制御が論理的に一カ所から可能になり、ネットワーク設計・運用が飛躍的に簡素化します。また、ネットワーク機器自体も、これまでのように多種多様なプロトコル規格を理解して処理しなくても、SDNコントローラからの命令を受け取るだけでよくなるので、大幅にシンプルになります」(原文ママ)
これは基本的に、OpenFlowプロトコルを前提とした説明だと理解できる。同じホワイトペーパーでは、「コントロールプレーンとデータプレーンをつなぐ初の標準プロトコル」といった、ぼかしたような書き方をしているが、事実上OpenFlowを前提としていると判断していいだろう。ONFのエグゼクティブ・ディレクターであるダン・ピット氏も「OpenFlowはSDNにとって不可欠な役割を果たす」と述べている。
NiciraのNVPをきっかけに、言葉の意味を再考する
では、米NiciraのNVPのような製品はSDNではないのか。本連載の第2回でも説明したように、NiciraはOpenFlowベンダーではない。コントローラーとトンネル終端ポイントの間にOpenFlowプロトコルを使ってはいるが、それは上記のホワイトペーパーが示唆するような、ネットワーク全体の集中制御のためではない。分散トンネリングの制御のためだ。NVPという製品の目的はネットワーク仮想化であり、ネットワーク全体の集中制御ではない。
それなのに、NiciraはSDNの代表的企業としてもてはやされてきた。このことを受け入れるならば、ONFによるSDNの「定義」は狭すぎるということになる。
では、なぜNiciraはSDNの代表的企業と呼ばれてきたのか。より建設的なSDNの定義を考えるためには、なぜNiciraがSDNという言葉と結び付けてイメージされているかを検討するのが早道だ。
スイッチに仮想ネットワークを割り当てる従来のVLAN機能と比較した場合の、NVPという製品の価値は次のようなものだ。
これまでのVLANでは、コマンドラインだろうがGUIツールだろうが、各ネットワーク機器に対して仮想ネットワークを設定しなければならない。全スイッチポートに(必要と思われる数だけ)VLANを設定しておいて、仮想マシンから自分が参加したいVLANのIDを通知させることで、NVPと同じことができるではないかと思う人がいるかもしれない。しかし、マルチテナントクラウドサービス(IaaS)事業者は、各ユーザーに専用の仮想ネットワークセグメントを、ユーザーからのリクエストを受けた時点で即座に割り当てられなければならない。
即座に割り当てるためには完全な自動化が必要だ。しかし、上記の「スイッチポートにあらかじめ必要だと思われる数だけVLANを設定」するという、別の担当者やツールによる作業が別途発生するのでは、自動化が完結しない。あらかじめ必要だと思われたVLAN数が不足したらどうするのかという問題が発生するからだ。ネットワーク担当者が設定を追加すればいいではないかというかもしれない。では設定を追加するまで、ビジネスはストップするのか、ということになってしまう。一方、NVPならば、ネットワーク機器の設定はまったく不要で、基本的には、仮想化プラットフォーム上の仮想スイッチにおけるトンネリング設定をオンデマンドで行えばいい。
このように、「運用でカバー」する世界から脱し、ネットワーク機能をクラウドサービス事業者のビジネスと直結することができるのが、NVPの1つの利点だ。もう1つ、NVPにはWANをまたがって、仮想ネットワークを構築できるという、大きな特色がある。いずれにしても、NVPは、ネットワーク仮想化という機能に限定してはいるものの、ネットワーク利用にかかわるプロセスがサービス事業者のビジネスを邪魔しない、あるいはこれら事業者のビジネスに積極的に貢献するチャンスを生み出すことを目指した製品だと表現することができる。
「SDN」はアーキテクチャでなく目的
これを踏まえれば、SDNはONFの言うような特定の「アーキテクチャ」ではなく、「目的」を示す言葉に変質してきている、あるいはこの言葉が広がる過程で、多くの人々は目的として捉えてきたと表現できる。「やりたいことをネットワークに邪魔されない、あるいはネットワーク機能の積極的活用によって実現する」という目的だ。
より定義に近づけた言い方をするなら、「SDNとは、利用者がやりたいことを実現するのに最短距離の方法で、ネットワークの構成や活用ができること」といった意味さえ保たれていれば、他の要素は副次的なものと考える。実際にITの他の分野でも「Software Defined Datacenter」のような、「Software Defined~」という言葉を使ったマーケティング活動を進め始めたベンダーは、このような意味で用い、自社の分野に適用している。SDNという言葉を使って建設的な議論をするためには、上のような、曖昧だが幅広い表現で、具体的に何をどのように実現するのかを表現した方がいい。特定の技術やアーキテクチャは、この目的に照らしてどう貢献できるかによって、その価値が判断されるべきだ。
本連載第2回の記事の末尾で、「ネットワークサービスのビジネスニーズへの対応が、どれだけ的確に、容易に、迅速にできるかで、OpenFlow製品の価値を測ることができるようになるのではないだろうか」と書いたのは、こうした意図がある。
NECのようなOpenFlowベンダーにとって、上記のような定義は不満が残るかもしれない。OpenFlowを出発点としているからこそ、これまでやりたくてもできなかったことが、できるようになるのだ、それがSDNなのだと主張したいからだ。だが、もし他の「SDN製品」よりも、自社のSDN製品の方が明確に「SDN的」だと証明できるのなら、それで十分なはずだ。「クラウド」という言葉が幅広い意味を持った今日においても、Amazon Web Servicesのような企業が、他と比較して明確な「クラウド性」を発揮しているように。
第4回では具体的に、SDN関連技術によってどのようなことがどう実現できるのかを解説する。
Copyright © ITmedia, Inc. All Rights Reserved.
OpenFlow/SDN、誤解の構造
この記事の著者
新着ホワイトペーパー PR
-
製品資料
[o9ソリューションズ・ジャパン株式会社] 「改正物流効率化法対策」徹底解説 総物流費を抑制するサプライチェーン戦略 -
製品資料
[o9ソリューションズ・ジャパン株式会社] 「サプライチェーン最適化」実践ガイド:効果的な意思決定を実現する秘訣とは? -
製品資料
[株式会社リンプレス] 非デジタル/IT人材を「自走するDX推進者」に変えるための育成ロードマップ -
市場調査・トレンド
[ワンアイルコンサルティング株式会社] AI時代の組織設計:「判断と責任」を人に残すための2つの原則とは? -
技術文書・技術解説
[ワンアイルコンサルティング株式会社] システムの保守がモダン化を阻む? 「変えない判断」から脱却する方法とは
こんなメディアも見られています
TechTargetジャパンに関連する情報をお探しであれば、こちらのメディアもお役に立てるかもしれません。
ベンダーコンテンツ PR
From Informa TechTarget
SpecialPR
アクセスランキング
-
1
1200万円のSaaS導入を回避 スギ薬局「運用費10万円」のAIエージェント構築術
-
2
ソフトウェア開発生産性向上に取り組む企業は4割 調査で学ぶ「停滞」の正体
-
3
エージェンティックAIで、コンタクトセンターの「おもてなし」をどう進化する?
-
4
クラウド資格コレクターは評価されない? 年収1000万を分ける“OSの理解度”
-
5
「完璧な設計」なのに3000万円溶けた AWSの失敗事例から学ぶ3つの教訓
-
6
100億円の「Linux更新」を回避 みずほ銀行が選んだ“おきて破り”のRHEL延命策
-
7
Microsoft製品でここまで自動化できる 情シスがやめられる手作業10選
-
8
年収700万超エンジニアに共通するスキルと「もっと勉強すべきだった分野」
-
9
無料の「Apple Business」で十分? 情シスが陥りがちなポイント
-
10
「配信に1カ月」の代償 カルビーがLINE運用で外部依存を断ち切った理由
ホワイトペーパーランキング PR
-
1
インシデント対応工数を約3割削減、東京ガスの事例に学ぶ監視体制刷新のコツ
-
2
JR西日本ITソリューションズが「監視業務の属人化」を解消した方法とは?
-
3
「Google Workspace」活用事例34選、先進の生成AIによる組織変革の全貌
-
4
DX/AI投資の壁を突破、現代の最高財務責任者が直面する課題と克服のヒント
-
5
「人員を増やす」という選択肢はない 情シスが負の連鎖から抜け出すには?
-
6
Windows PCとMacの選択制で生産性向上 LINEヤフーが実践する運用管理方法とは
-
7
生成AIで文書活用を進めるには? 効率化と安全性をどう両立する
-
8
「問題が深刻化しやすいプロジェクト管理」から脱却する方法とは?
-
9
Linuxのスキルを証明する“激推し”の認定資格はこれだ
-
10
NTTドコモが実践したクラウド統合監視 業務量2倍でも残業削減を実現できた理由
TechTargetジャパン SNS
インフォメーション
注目情報をチェック
TechTargetジャパンをフォロー