ネットワーク アーキテクチャ考 (15) 「SDN/NFV これまでの振り返りとこれから」
SDN/NFVは、アーキテクチャ変遷の一つの可能性です。通信事業者は、それまでのハードウェアを中心とした基盤設備的なアーキテクチャから、ソフトウェアを中心としたより柔軟で迅速なアーキテクチャにシフトしようとしています。そのため、「アーキテクチャ変遷」を大きなテーマの一つとしているこのBlogでも、SDNやNFVについてのいくつかの、総論的な話題を取り上げてきました。
しかしこの辺でそろそろ一旦振り返り、次のステップに踏み出したいと思います。そこで今回は、振り返りのきっかけになったことと、今後考察して行きたいことを書きます。
- Network Programmabilityと宣言的プログラミング
- 対立する価値の統合
- White Box SwitchとForwardingのコモディティ化
- Traffic Modelの変化とこれからの可能性
1. Network Programmabilityと宣言的プログラミング
振り返りのきっかけになったことの一つは、ネットワークプログラマビリティ勉強会[1]です。ここでは、「実際にやってみたレポート」から、理論的なことまで、「ネットワークプログラマビリティ」に関するあらゆることが、ゆるやかに、そして和気あいあいと議論されています。私も若手に混じってスタッフをさせて戴いており、先日は発表の機会も戴いたので、「宣言的(Declarative) vs 命令的(Imperative)か」というプログラミングパラダイム議論を、ネットワークプログラマビリティに適用させた発表をさせて戴きました[2]。現時点ではまだ試論の域を出ていないのですが、今後もっと考察を重ねて行きたいと考えています。
プログラマビリティや自動化の必要性は論を俟たないとして、これからは、それをどう行うか、の議論に注力する必要があると感じています。システムは放っておくとどんどん複雑化します。ソフトウェア中心のシステムであれば尚更です。この状況で、制御を記述する方法もどんどん複雑化してしまったら、手に負えないシステムになりかねません。ネットワークプログラマビリティと言ってもひたすらコーディングすればよい訳ではなく、数学的、論理学的理論に基づいたコーディングスタイルが必須となると考えています。特にネットワークのような複数の要素が接続される分散システムの場合は、手許にリソースがあるシステムのプログラミングよりも、より不確定性が高いのです。
2. 対立する価値の統合
もう一つのきっかけは、先日Ciscoのセミナーで実施させて戴いたパネルディスカッション[3]です。NTTコミュニケーションズ、KDDI、Softbankという大手通信事業者から第一線のアーキテクトにご登壇戴き、NFVを中心としたアーキテクチャの現状と今後に関する考察を、率直に議論しました。この時の内容は、InSPireという弊社のWeb Magazineに投稿いたしましたので、ぜひご覧戴きたいと思います。
”Service Provider Architecture” のこれから – NFVの現状、課題、可能性そしてその先へ
いくつかの興味深い考察がなされたのですが、特に印象に残ったのは、アーキテクチャ変遷時には、異なるそして時には対立しうる複数の価値の統合が求められる、ということです。”Agile Devops”（迅速に開発と運用のフィードバックループを廻す）vs “Carrier-Grade” （事前にしっかり計画を立て信頼性を保証する）、”自律分散的制御” vs “中央集権的制御と自動化”、”ネットワーク技術者のスキルセット” vs “サーバー技術者のスキルセット”など。これらをよく吟味しないで、表面的な理解で突き進むと、「アーキテクチャを見誤る」可能性があるのではないか、と感じました。（「アーキテクチャを見誤ってはならない」というのも、このパネルディスカッションでパネリストの皆様から提言された名言集の一つです。:)）
3. White Box SwitchとForwardingのコモディティ化について
さらにもう一つは、White Box Switchへの期待の高まりです。Janogで最近何度か取り上げられたり[4],[5]、White Box Switchユーザ会が発足したりしました[6]。
SDNの考えられる一つの帰結は、Fowardingのコモディティ化と低廉化、そしてControl/Intelligenceの自由化（自作化やオープンソース化）ですから、White Box Switchへの需要が高まるのは当然です。この方向は「アンチ ネットワーク機器ベンダー(!!)」的要素も含むので、ベンダーの人間が発言するのはあまり歓迎されないかもしれないのですが、私としてはこのような動きに大いなる期待を寄せている立場なので、ご容赦戴きたいと思います。
私の最大の期待は、このような動きが、通信事業者のお客様が、「対立する価値を統合」しながらアーキテクチャ変遷を遂げうる契機になり得る、という点です。我々ベンダーとしても、オープン化、標準化、オープンソース化を推進しながら、お客様と共に技術やアーキテクチャの共同開発をして行く、という、理想的な関係性が築ける可能性があると考えます。
一方注意したいのは、ハードウェアとソフトウェアは対立軸ではなく車の両輪であり、領域も重なり合う補完的関係にあるので、ハードウェアのみコモディティ化しソフトウェアだけが進化して行く、というのは不自然です。転送プレーン機能、特に、ロードバランシング、DPI/SPI、階層的QoS、OAM、階層的FIB、バッファ、Scaling、In-Network Storageなどは、今後ますますハードウェアでの進化も期待されます。そのため、White Box Switchの適用領域についても、現在のWhite Box Switchの限界と、必要とされる機能要素を考慮の上、十分に吟味することが大切と考えます。
4. Traffic Modelの変化
最後に、もしかするとこれが一番重要なことかもしれないのですが、Traffic Modelが大きく変化しています。2015年のVNI[7]によると、2019年には、Videoが全トラフィックに占める割合が72%、Videoストリーミングやオンラインゲーミング、SNSやWebブラウジングなどのCloud型トラフィックが占める割合は90%を超える、と予測されています。このような中、エンドポイント同士を接続する、というネットワークモデルはそろそろ見直す必要があるのではないでしょうか。
電話網からTCP/IP網への変遷は、データ中心、そしてインテリジェンスはネットワーク側でなくエンドシステム側に持たせる、という点で画期的でしたが、エンドポイント同士を接続するというモデルは変わっていません。TCPの輻輳回避メカニズム[8]は、とてもクールな技術ですが、ここにきて弊害も目立つようになりました。まずend-to-endの制御なので、一部でも通信速度が遅い部分があるとそれに合わせてスループットが抑えられます。それはよいとしても、この輻輳回避メカニズムは「パケットロスを輻輳のサイン」と見なしますので、パケットロスを検知するとスループットを一気に初期値に落とします（スロースタート）。この機構は有線だけで構成されるネットワークでは問題ないのですが、帯域的に余裕があってもパケットロスが起こりえる無線の場合は、帯域が有効活用できません。また、まだあまり顕在化していませんが、仮想化環境も、帯域やリソースに余裕があったとしてもパケットロスが生じる可能性があるため、同様の問題が起こりえます。
End-to-end モデルは重要なインターネット原理のひとつでありますが、ついにその見直しの時が来ているのではないかと思います。それに代わるものとして、Publisher/Subscriberモデル、Content Centricモデル(ICN, NDN..)などが考えられます。今後これらについても重点的に考察して行きます。
仮想化は、これらの新しいパラダイムを、スモールスタートで初期投資を抑え、オーヴァレイ的、セルフコンテイン（自己完結して他に影響を与えない）的に実装できる可能性がある、という点でも意義があると思います。
[1] ネットワークプログラマビリティ研究会 http://network-programmability.connpass.com/
[2] 「宣言的プログラミングとSDNのひとつの形態」 http://www.slideshare.net/miyakohno/mk-network-programmability03
[3] Cisco EPNセミナー パネルディスカッション 2015年4月 http://www.cisco-inspire.jp/issues/0019/featuredstoty5.html
[4] 「DCネットワークの新時代? – ホワイトボックススイッチの利用可否 – 」JANOG34 https://www.janog.gr.jp/meeting/janog34/program/whbox.html
[5] 「パネルセッション：検証してみて感じたホワイトボックススイッチの未来」JANOG35.5 https://www.janog.gr.jp/meeting/janog35.5/program1
[6] ホワイトボックススイッチユーザ会 https://atnd.org/events/65122
[7] Virtual Network Index http://www.cisco.com/c/en/us/solutions/service-provider/visual-networking-index-vni/index.html
[8] Van Jacobson and Michael J. Karels, “Congestion Avoidance Control”, ACM SIGCOM Computer Communication Review, Nov. 1988 http://faculty.cord.edu/zhang/cs345/assignments/researchPapers/congavoid.pdf
Tags:
