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
-
製品資料
[キヤノンマーケティングジャパン株式会社] マンガで学ぶXDR/MDRのメリット、中小企業のセキュリティ強化になぜ有効か? -
市場調査・トレンド
[キヤノンマーケティングジャパン株式会社] 有識者が語る、中堅中小企業に求められる最新のサイバーセキュリティ対策とは -
製品資料
[キヤノンマーケティングジャパン株式会社] マンガで解説:情シスの負担を減らす「MDRサービスのインシデント対応」の中身 -
市場調査・トレンド
[SANS Training Japan 合同会社] “知識”では守れない AI時代に問われる実戦力の身に付け方 -
製品資料
[株式会社イトーキ] 会議室不足を解決する「AI×データ」活用術
こんなメディアも見られています
TechTargetジャパンに関連する情報をお探しであれば、こちらのメディアもお役に立てるかもしれません。
ベンダーコンテンツ PR
From Informa TechTarget
SpecialPR
アクセスランキング
-
1
なぜ「Gemini 4 Argon」は出遅れたのか? Googleが狙う“逆転のシナリオ”
-
2
ChatGPTは“検索しまくり”でGeminiは“淡泊”? データが明かすAIの裏側
-
3
慶應義塾が「Notion」を選んだ理由 AI導入の盲点になる“情報のサイロ化”
-
4
Copilot導入で陥る“目的化”の落とし穴 定着の鍵は「作り込まない」こと
-
5
半数がブルーカラー転向を視野に? ベテランエンジニアを追い込む“54歳の壁”
-
6
「Copilot」はなぜ放置される? “議事録要約止まり”を脱する処方箋
-
7
Microsoft 365移行で露呈した標準機能の限界 地方銀行は上長承認や「脱PPAP」をどう実現?
-
8
AmazonがMetaのAIエージェントの購入を拒否 情シスが問われる「AIの権限設計」
-
9
年収が増えても幸せになれない 給与増でエンジニアが直面する「幸福度の壁」
-
10
SAPやOracleが警戒する「ERPの土管化」 汎用AIとの主導権争いが激化
ホワイトペーパーランキング PR
-
1
AI駆動攻撃にどう対抗する? 超速の攻撃からエンドポイントを保護する方法
-
2
最速72分でデータが流出? 最新の脅威トレンドや侵入手法から分かった防衛策
-
3
2026年のサイバーセキュリティには何が必要か? 最新データに学ぶ傾向と対策
-
4
経験豊富な即戦力人材に直接アプローチできる、「攻めの採用」への転換術
-
5
「IT史に名を残すシステム障害」8選
-
6
SASE選定は「見極め力」で大きな差――本当に必要な製品を選ぶための6つの視点
-
7
不審メールの経路や見せ方に変化? 2026年夏の3事例から見えた動向と対処方法
-
8
Microsoft 365のメールセキュリティ、3つの“死角”と追加で検討すべき対策とは
-
9
AI駆動開発のスピードと安全性を両立 「品質・セキュリティ管理」の実践ガイド
-
10
「標的型攻撃メール」事例・サンプル集
TechTargetジャパン SNS
インフォメーション
注目情報をチェック
TechTargetジャパンをフォロー