OpenFlow／SDN、誤解の構造【第4回】

【技術動向】SDNで何を議論すべきなのか

前回はSDNという言葉を「利用者が、やりたいことを実現するために最短距離の方法で、ネットワークの構成や機能の活用ができること」と説明した。今回は、これをさらに掘り下げる。

　本連載は、OpenFlowとSoftware Defined Networking（SDN）に関する誤解について集中的に解説している。第1回「【技術動向】OpenFlowはなぜ誤解されるのか」、第2回「【技術動向】OpenFlowに対する4つの誤解を検証する」では、OpenFlowに関する誤解について説明した。第3回【技術動向】SDNはなぜ誤解されるのかではSDNに関する誤解の背景について取り上げた。今回はSDNで何を議論すべきなのかを説明する。

「SDN」は特定の技術を示す言葉であってはならない

　前回、SDNという言葉を「利用者が、やりたいことを実現するために最短距離の方法で、ネットワークの構成や機能の活用ができること」という意味で捉えるべきだと述べた。定義と呼ぶには曖昧な表現だが、建設的な議論のための土台、あるいは共通理解として、上記のような理解をするのが適切だ。ここで言いたいことの1つは、SDNという言葉が、特定の技術や製品を示すものであってはならないという点だ。

　SDNという言葉は、「クラウド」という言葉の使い方に非常によく似ている。どちらも目的、あるいは実現したい世界を示す言葉だ。だからこそさまざまな議論が進展し、これに触発されて新たな技術や製品が次々に登場する。

　筆者は2009年に＠ITで、「クラウドという言葉に関していえば、『利用者が、利用したいものを、利用したいだけ、利用するということに専念できるようなIT消費スタイルである』という意味さえ保たれていれば、ほかの定義は2次的なものだと考える」と書いた。

　当時は、Amazon Web Services（AWS）のようなサービスしか「クラウド」と呼ぶに値しないと主張する人が多数存在していた。しかし、クラウドがAWSを形容する言葉でしかなかったのなら、これほどまでに多くの人が口にすることはなかっただろう。クラウドという言葉は、上記のようにITの消費スタイルであり、これを実現することを目的とした製品やサービスが多数登場したからこそ、豊かな、幅広い選択肢を備えた世界が現実のものとなった。

　現在においても、AWSおよびその信奉者の人々は、「AWS以外はクラウドではない」と心の底で思っているかもしれない。しかし、「AWSだけがクラウドだ、他はクラウドではない」と主張しているだけでは、議論がかみ合うことはない。この言葉を広い意味で使い、「ITの利用者は、皆クラウドを求めている。求められているのは、具体的には○△だ。AWSは△×や□△のような機能、使い勝手を提供するからこそ、世界で最も優れたクラウドサービスだ」といった主張をしないと、多くの人々から賛同を得るのは難しい。

　SDNもこれと同じだ。「OpenFlow＝SDN」なのだとしたら、SDNという言葉が存在する価値はほとんどない。OpenFlowのことを言い換えているだけになるからだ。SDNという言葉が、多くの人々の注目を集めることもなかっただろう。また、ハードウェアがソフトウェアに置きかえられていくこと、あるいはハードウェアが価値を失ってソフトウェアの価値が高まることがSDNの意味だったとしたら、SDNはネットワーキング業界の構造変化、つまり内輪の話でしかないことになる。その場合も、SDNという言葉が、今日のように注目されることはなかったに違いない。

　多くの人々が、SDNという言葉に注目する理由は、これが「利用者が、やりたいことを実現するために最短距離の方法で、ネットワークの構成や機能の活用ができる」世界を目指した言葉であることを、無意識にでも感じているからだ。もう少しシンプルに表現すれば、「利用者がネットワークをこれまでよりも直接的に活用し、役立てることができる」世界が生まれつつあると感じるから、ユーザーとしてこれに関連した動きに期待しているのだ。

　「利用者が、やりたいことを実現するために最短距離の方法で、ネットワークの構成や機能の活用ができる」ようにするために、何がどのような形で求められるのかを議論することで、この言葉の実体が徐々に形作られていき、それを具現化する製品やサービスがますます増えて、結果的に多くの人が、幅広い選択肢の恩恵を受けられるようになるはずだ。

マルチテナントクラウドサービスでのSDN

　さて、SDNという言葉についての上記の表現を、ひとまず受け入れていただくとして、重要なのは「利用者」が誰か、「やりたいこと」は何なのかによって、SDNの具体的な役割が変わってくるということだ。

　では、具体的なSDNの利用シーンの例として、マルチテナントクラウドサービスを考えてみよう。ここでいうマルチテナントクラウドサービスとは、AWSのサービスでいえばAmazon VPCに相当する。つまり、顧客ごとに別個のネットワークセグメントを割り当てることで、各テナントの通信を分離する仕組みを備えたIaaSを意味する。従来型の企業向けデータセンター事業者は、必ずしも仮想化環境を前提としてはいないが、テナント単位での通信分離を以前から行ってきた。

　この場合、利用者は誰かといえば、こうしたマルチテナントクラウドサービス（IaaS）のサービス設計担当者であり、最終的にはこれらサービスのユーザーだ。

　では、クラウドサービスのサービス設計担当者がやりたいこととは何か。マルチテナントクラウドサービスの事業者にとって、ネットワーク機能は商品の一部であり、文字どおりビジネスに直結する。彼らがやりたいことの1つは、テナント単位のネットワークセグメント構築を、仮想化環境と連動して自動的に実行するということだ。

　具体的には、まずテナント単位でのネットワークセグメント分離をどのように行うか、という問題がある。これまではスイッチのVLAN機能を利用して、こうしたネットワーク分割が実現されてきた。しかし、12ビットで構成されるVLAN IDでは、約4000しかVLANを構成できないという、拡張性の問題がある。現実にはこれを補うため、VLANを階層的に構成するような運用上の工夫がなされている場合がある。しかし、こうした運用上の工夫による複雑さは、ビジネスの円滑な運用の妨げになる。

　しかし、拡張性よりもさらに重要になりつつある問題は、VLAN ID割り当てのプロセスが自動化できていないということだ。データセンター事業者で、顧客へのVLAN割り当てをスプレッドシートなどで管理していることはよくある。こうしたやり方は、顧客からのリクエストを受けてから、ITリソースを提供するまでの猶予時間をある程度確保できているうちは何とか成立するかもしれない。だが、最近のパブリッククラウドサービスのように、顧客がセルフサービスポータルで設定した瞬間に、実際のサービス提供が開始できなければならない状況では、通用しない。顧客のセルフサービスリクエストを受けて、仮想ネットワークセグメントを割り当てるまでのプロセスは、自動化されなければならない。

OpenFlow／SDN、誤解の構造

この連載の記事をもっと見る

この記事の著者