クラウドと同様、SDNも定義疲れに直面

Lori Mac Vittie特別技術者兼チーフエバンジェリスト | F5

クラウドの歴史が始まって間もない頃、とはいえそれほど昔のことではありませんが、成長率や導入状況に関するレポートでは、主要なモデル（念のため補足すると、IaaS、PaaS、SaaSです）を区別せず、「クラウド」が比類のない勢いで市場に浸透していると喧伝するのが一般的でした。そのため、3つのモデルすべてが驚異的に成長しており、一部で予測されていたように、クラウドが従来型のデータセンターを消滅させるかのように見えました。

それから数年が経ち、市場をより詳細に分析できるようになった今、クラウドの目覚ましい成長は主にSaaS分野によるものだったことが分かってきました。LOB（事業部門）の関係者が、「IT部門にパッケージソフトウェアを導入してもらう」モデルから、「SaaSですぐに必要なものを利用する」モデルへ移行するメリットを認識したためです。これまでの「クラウド」における最大の成長が、ビジネス業務をオンプレミスから「クラウド上」のアプリケーションへ移行する動きによるものであることは、疑いようがありません。

次の点に注目してください。「2018年までに、クラウドワークロード全体に占めるSoftware-as-a-Service（SaaS）ワークロードの割合は、2013年の41%から59%に増加します。Ciscoは、Infrastructure-as-a-Service（IaaS）ワークロードの割合が2013年の44%から2018年までに28%へ低下すると予測しています。Platform-as-a-Service（PaaS）ワークロードの割合も、2013年の15%から2018年には13%へ低下します。以下の図は、2013年から2018年までのIaaS、PaaS、SaaSの予測を比較分析したものです。」（http://softwarestrategiesblog.com/tag/idc-saas-forecasts/）

そのため、組織に「クラウド」を導入しているかと漠然と尋ねれば、おそらく「はい」という回答が返ってきます。しかし、それだけでは、どの種類のクラウドを導入しているのかはわかりません。したがって、導入に伴ってどのような課題に直面している可能性があるかを予測したり、論じたりすることはほぼ不可能です。クラウドモデルごとに固有の課題があるためです。3つのモデルすべてでアイデンティティ管理が問題になり得るなど、共通する課題がある一方、共通しない課題もあります。たとえば、Webアプリケーションセキュリティは、主にIaaSにデプロイされたアプリの課題であり、SaaSの課題ではありません。

つまり、「クラウド」という用語は、何らかの修飾語がなければ、ほとんど意味をなしません。

現在のSDNにも同じことが当てはまります。さまざまなモデルが存在し、それぞれに固有のアーキテクチャ要件があるため、課題も異なります。

SDNの定義にオーバーレイプロトコル（VXLANとNVGRE）を含めることについて、同僚のNathan Pearceが展開した次の痛烈な論考をご覧ください：最適なSDNプロトコルとは。Nathanは、オーバーレイプロトコルをSDNの定義に含めるのであれば、ほかのカプセル化プロトコルもSDNと呼ぶ必要があると、もっともな指摘をしています。

もちろん問題は、クラウドと同様に、SDNも複数のモデルを広く包含していることです。従来型（お好みなら「古典的」）の定義はOpenFlowを基盤とし、ステートレスなネットワーク（レイヤー2～4）のみを対象とします。一方、ネットワークの運用化に重点を置き、プロビジョニングと管理の自動化という観点からSDNのプログラマビリティに取り組むアーキテクチャモデルもあります。これは一般に「ネットワーク管理およびオーケストレーション」（MANO）と総称されます。

さらに、両者を組み合わせたようなモデルもあります。これは、プログラマビリティを活用してスタック全体にわたる自動化ネットワークを構築するもので、OSIの全7階層を対象としつつ、リアルタイムのトラフィックに基づいてネットワークがルーティングやポリシー適用を調整できることに重点を置いています。より正確には「自動化ネットワーク」と呼ばれます。

これら3つのモデルには、それぞれ固有の課題（そしてメリット）があります。また、目標を達成するために、これらのモデルを組み合わせることも可能です（組織の82%がマルチクラウド戦略を計画しているのとよく似ています（RightScale『State of the Cloud 2015』））。しかし、SDNを導入または実装しているかと尋ねて「はい」と答えられても、実際に何をしているのかはまったく分からない、という事実に変わりはありません。OpenFlowでしょうか？ OpenStackでしょうか？ OpenDaylightでしょうか？ それとも「ネットワークを自動化するスクリプトをいくつか作成した」方式でしょうか？

現在のSDN導入状況を示す統計はあまり芳しくなく、市場成熟度が同じ段階にあった頃のクラウドには遠く及びません。

しかし、定義にばらつきがあることを考えると、実際には導入や関心が不足しているのではなく、共通の定義が欠けている可能性が高いと考えられます。

この点を裏付けるデータをご紹介します。組織はSDNに取り組んでいるとは明言していないかもしれませんが、実際には取り組んでいる可能性が高いことを示すデータです。これはDevOpsについても同様で、DevOpsも定義の乱立による混乱に悩まされています。

最新の「State of Application Delivery」レポート（2016年版は、当然ながら2016年に公開予定です）向けに集計した結果では、SDNが長年にわたり「取り組むべきもの」とされてきた割に、実際に「SDNに取り組んでいる」との回答はかなり低調でした。しかし、自動化とスクリプティングの利用に関する回答を詳しく見ると、まったく異なる実態が浮かび上がります。回答者の67%が少なくとも1つの自動化ツールまたはフレームワークを使用しており、半数以上が2つ以上を使用しています。

ここでいう「ツール」または「フレームワーク」には、Python、Juju、Chef、Puppet、OpenStack、VMware、Ciscoが含まれます。

このようなフレームワークやツールが使用されていることから、従来のOpenFlowベースの定義よりも、自動化とオーケストレーションに重点を置く後者2つのSDNの定義に関心が集まっていることがわかります。

しかし、私たち（この調査をまとめたメンバー）は、SDNの各モデルについて質問したのではなく、「SDN」全般について質問しました。そのため、広義の包括的な用語である「クラウド」によって初期導入に関する調査結果の解釈が分かれたのと同様に、SDNの定義も解釈の余地が残ります。

SDNという用語をどのような意味で使うのか、より慎重に考える必要があります。オーバーレイプロトコルを含むのでしょうか。それとも含まないのでしょうか。ネットワークオートメーションを指すのでしょうか、それともネットワークの自動化でしょうか。あるいは、OpenFlowを基盤とする従来型のネットワークモデルに焦点を当てているのでしょうか。

その問いへの答えが明らかになれば、現在SDNがどのように受け入れられているのか（あるいは、受け入れられていないのか）を誰もがより深く理解できるようになるでしょう。そして、オーバーレイプロトコルも「SDN」に含めるべきだという意見を耳にするたびに頭を抱える同僚たちも、（願わくは）救われるはずです。

著者について

Lori Mac Vittie特別技術者兼チーフエバンジェリスト | F5

Lori MacVittieは、F5のOffice of the CTOに所属するDistinguished Engineer兼Chief Evangelistであり、アプリケーションデリバリ、自動化戦略、インフラストラクチャに関する深い専門知識を有しています。AIエージェントのガードレール策定、脆弱なマルチクラウドアーキテクチャの分析、スケーラブルなシステムの限界の検証など、複雑な事柄を明快にすることで知られています。アプリケーション開発、ITアーキテクチャ、ネットワークおよびシステム運用の分野で、30年以上にわたる業界経験を有しています。F5入社前は、受賞歴のあるテクノロジー編集者として活躍していました。 MacVittieはコンピューターサイエンスの修士号を取得しており、セキュリティ、クラウド、エンタープライズアーキテクチャにわたる分野で多数の著作を発表しています。また、テーブルトークゲームとビデオゲームをこよなく愛し、チーズについては遠慮なく強いこだわりを語ります。

Lori Mac Vittieのその他のブログ記事