という訳で、「SDN的な何か」の動機となる要求はネットワーク仮想化だった、ということです。また前回は、「仮想化への要請があったから SDN が活況なのか、SDN が活況だから仮想化がブームになったのか。共起関係から因果関係を帰結することはできないので、今はどちらなのかはわからない」と書きました。しかし、SDN と仮想化の共起に先立つ物として、クラウドの興隆があったことは疑いの余地はないでしょう。そしてそこに強く関係しているのが、設備投資から消費へ、という経済的動向です。
設備投資から消費へ
大分前のことですが、“Consumption Economics”[1]という本を読みました。英米で話題になったのでご存知の方も多いと思います。そこでは、ハイテク業界の購買モデルについて論じられています。— これまでは購買側がリスクを取り、年月をかけて効果や効用を生み出して投資を回収していたが、これからの時代の購買者は、そのようなリスクはもう取らない。必要なときに必要な機能を、そこそこの（good enough）品質で使えれば良い。— これはしかし未来予測でも何でもなく、実際に現実に起こっていることである、と実感せざるを得ません。
必要なときに必要な機能をそこそこの品質で、という仮想化指向の傾向は、必ずしも絶対的なものではないと思います。第 3 回で述べた「アーキテクチャ変遷のパターン」でいうと、「仮想」と「物理」という対極概念間で行きつ戻りつする、「1.対極概念間の揺り戻し」に相当するものと考えられます。実際、ガートナーは「クラウド化の流れは近いうちに止まる」という発表をしました[2]。
しかし、少なくとも現時点では仮想化への要求は強く、また目的とする効果を得るために、設備投資するのではなく「必要な機能を使う」という考え方は、魅力的な発想です。技術者としては、どのようにこれを実装するか、というところに注力したいと思います。
How good is good enough?
「必要なときに必要なだけ」、というのは、技術的には、仮想化環境において、柔軟かつ迅速な CRUD（Create, Read, Update, Delete）を実現する、ということになるでしょう。ネットワークはそもそも、レイヤリングとパケット カプセル化という点で十分仮想的なのですが、決定的に欠如していたのは、オペレーターやアプリケーションから見たときの柔軟かつ迅速な CRUD でした。そこで現在は、CRUD の実現が我々に課された重点項目になっています。特に重要なのは、「何をどう制御するか」という抽象データモデルの定義です。
しかし「good enough」の方はさらに難しいです。どの程度 good だったらよいのしょうか。客観的な指標がない以上、提供側と使用側で期待値の乖離が生じる可能性があります。商用インターネットの初期の頃は、「Best effort（No Guarantee）」が画期的なものとして受け入れられました。しかし当時は、通信サービスは品質保証が当たり前であり、それに対するアンチテーゼだったから画期的だったのです。現代のクラウド サービスの使用形態は、然程品質を求めないものから、ミッションクリティカル性のあるものまで、多岐に渡るでしょう。「どの程度 good だったら good enough か」というのは、やはり必要や場合に応じて、都度サービスレベルを定義して合意する必要があるのだと思います。
Overlay と Underlay の連携
クラウド サービスで、SLA を提供できるか。まずコンピューティング リソースですが、要求されるサービス品質により、定義した閾値を越えたら新たなリソースを確保すること（Scale out）により、リソース使用率を一定以下に抑えることが可能です。これにより、平常時に比べピーク時の負荷が特に高いようなシステムに対しては、ハードウェアで構成されるシステムよりも高い SLA を提供することができると言えます。Availability に関しても、障害時のバックアップ システムを安価に準備できるという点で、ある程度は（ハードウェアを完全冗長するような厳密なレベルではないまでも、ハードウェア二重化に比べると低コストで）、可用性を向上させることができます。
しかしネットワークはどうでしょうか。仮想化環境においては Overlay Network が構成されますが、Overlay はその基盤となる Underlay Network を関知しません。Underlay Network の方も、上に流れる Overlay Traffic を関知しません。同一データセンター内、同一ファブリック内であれば、Underlay Network に一切ボトルネックをつくらないことによって、問題を回避することもできますが、一歩データセンターから外に出ると、そうはいきません。ネットワークの品質は距離、トポロジー（経由ホップ数）、使用可能帯域といったものに左右されますし、もっと重要なこととして、リソースが無限でない限り、至る所で輻輳も起こりえます。Overlay と Underlay が何らかの方法により連携できなければ、Overlay Network の SLA を提供することはできません。
そこで、「抽象データモデル定義」に続くもう一点目の重点項目は、「Overlay と Underlay の連携」です。方法としては QoS mapping、Packet Inspection なども考えられますが、より汎用的かつ無理矢理感のない（?!）方法として注目したいのがメタデータ(*)の使用です。この場合、あるメタデータを使う制御に参加するシステムは、そのメタデータを理解する必要がありますが、その条件をクリアすれば、かなり柔軟な制御を、マルチベンダー、マルチプラットフォーム、マルチプロバイダー、といった環境においても、実現可能になります。
(*)データ特性を記述するデータ（情報）。ヘッダとして表現されることが多い。
そのようななか、IETF においてもメタデータの標準化活動が始まっています。ひとつはつい先日（2013年12月21日）発足した SFC（Service Function Chaining） ワーキング グループ。ここでは Service Chain を実現する方式、および Service Chain を記述するメタデータ（Service Header）について標準化される予定です。もうひとつは、こちらはまだ BoF 状態でワーキング グループ発足には至っていませんが、AEON（Application Enabled Open Networking）。ここでは、アプリケーションのフロー特性を表現するためのメタデータについて議論されます。
先日シスコが発表した新たなデータセンター アーキテクチャである ACI（Application Centric Networking, Insieme）も、vxlan header を拡張してメタデータを運び、Overlay と Underlay の連携を実現します。先ほど、同一データセンター内であれば問題を回避できると書きましたが、そうはいっても、Overlay と Underlay が連携し、アプリケーション毎の latency 情報や、経由ホップ、リソース使用状況などが分かれば、さらに高度な Networking ができる可能性が広がります。
[1] “Consumption Economics : The New Rules of Tech”, J.B.Wood et al, Point B, Inc. November 2011
[2] http://itpro.nikkeibp.co.jp/article/NEWS/20130425/473703/
Authors
