ネットワーク アーキテクチャ考 (10) 「『仮想化』は何のため」
仮想化アーキテクチャの周辺は日々進化していて、落ち着く暇がありません。この春 Cisco は、通信事業者向けの、仮想化環境における Orchestration Layer アーキテクチャとして、ESP（Evolved Service Platform）を発表しました。しかしこれは製品でもなくソリューションでもなく、概念的フレームワークであるため、現場は扱いに困ります。この概念的フレームワーク、深く読めば、ACI（Application Centric Infrastructure）や InterCloud などとも共通する遠大な構想に裏付けられているのですが、いざ、このフレームワークを見せられても、それだけでは何も言っていない。具体的な解を提供しないといけないときに、遠大な構想などを持ち出したら、お客様からは話をはぐらかしているように捉えられてしまいます。この辺が最近感じている難しさであり、もどかしさであります。なお、多少は具体的な解の例として、日経コミュニケーション『SDN のすべて』特集に、Segment Routing について記事を執筆させていただきました。これは SDN といっても、主に WAN（広域ネットワーク）を対象とした「シンプル化」への一つの解になりますが、ご覧いただけたら嬉しいです。
仮想化の２つの意義
仮想化の意義は、突き詰めて言えば次の２つになると考えます。まず、 必要なときに必要なサービスやリソースを、迅速にそして自動的に提供することを可能にすること。Everything as a Service、XaaS、いわゆるクラウドサービスです。これは、仮想化されたエンティティをリソース プールとして集積し、必要に応じて（On demand）迅速に（Agile）、割当てて提供することにより実現されます。もうひとつは、あるオブジェクトを仮想化エンティティへと断片化することにより、並列分散処理を行うことです。以前から分散システムは存在していましたが、断片化の単位が柔軟になり、かつ Map Reduc アルゴリズム[1]が登場したために、並列分散処理を有効活用できるアプリケーションが急速に増えました。並列分散処理の適用は一般的には難しいとされていたので、ここ10年の進展は目覚ましいものです。前者の仮想化はコンピュータそのものをエミュレートする Virtual Machine（VM）が前提であるのに対し、後者は必ずしも VM とは関係ないので、狭い意味での仮想化とは少し毛色が違うかもしれません。ただしここでは、仮想化の元の定義である「リソースの抽象化」、即ち「集約化も断片化も仮想化である」という立場に立っています。
並列分散処理は、これまでとは次元の異なる性能、スケール性、そして高可用性を実現します。最近、Google は「全てのソフトウェアをコンテナ上で動作させる」というContainer Stack 概念[2][3]を発表しました。その資料によると「一週間に 20億ものコンテナを起動している」と記載されています。20億と言われてもよくわかりませんが、秒あたりに換算すると 3,306.87個／秒です。これだけのスケーラビリティを実現しているのは、まずは水平的スケーリング（ひとつのエンティティを高性能化するのではなく、単にエンティティを追加することによって全体の性能を上げる）、そして「Declarative, not Imperative」というプログラミングの考え方です。これは ACI を始めとする最近の Cisco のソフトウェア基本アーキテクチャ概念でもあります。それぞれの処理を命令して実行させるのでなく、「こうして欲しい」という大雑把な要求を示し、後は各エンティティに任せてしまうやり方です。一つ一つの細かい処理の結果もトラックしません。細かい厳密性をある程度犠牲にしても、システム全体の性能やスケーリングの方がずっと大事だということです。
高可用性についても同じようなことが言えます。並列分散処理による高可用性実現の興味深い例として、Netflix の「Chaos Monkey」[4]があります。これは、いくつかのモジュールに意図的にランダムに障害を起こし、恒常的にどこかが故障しているという状態を作り出す、というものです。このような状況でシステムを動作させておくことにより、実際に障害が起こっても、特に普段と変わらず何の影響もないことを実現しています。個々の細胞に着目すると死滅したり新生したりしているが、全体的には生命を維持している、生物の身体のようです。
ETSI NFV 会合@沖縄
先日（2014年5月13-16日）、ETSI（the European Telecom- munications Standards Institute）NFV（Network Functions Virtualisation）の第６回目の会合が沖縄で開催されました。初めての日本、初めてのアジアでの開催です。NTT および KDDI がホスト企業として活躍されておられました。私は最近議論の状況にキャッチアップできていなかったのですが、せっかくの日本での開催なので、部分的ではありますが参加してきました。
参加登録数は 250名を超え、活況でした。また暫くフォローしていなかった間に、議論は進展し、参照アーキテクチャも深化していました。顕著な例としては、VNF（Virtualized Network Function）の上位概念としてNS（Network Service）が定義され、 NFVO（NFV Orchestrator; NSのオーケストレーションを司る）および VNF-M（VNF Manager; 各VNFのオーケストレーションを司る）という、オーケストレーションの階層構造が明示的になりました。Descriptor の情報要素も定義されつつあります。多くの、そして多様な通信事業者やベンダーが協力して仕様が文書化されて行くことは、すごいことと思います。WS（Working Group Specification）はもう間もなく提出される見込みです。関係者のご尽力に頭の下がる思いです。
一方で、少し懸念を感じたのは、仮想化の目的や意義があまり議論されないまま、既存の機能や実装をそのまま仮想環境で動作させることが主眼になっているのではないか、という点です。「仮想化であっても、高性能や高可用性を実現し、責任分界点や管理責任を明確にする」、といったテーマは重要に違いありません。しかし「仮想化であっても」という議論よりは、「仮想化ならでは」のメリットを意識した議論をしてもよいのではないでしょうか。まずは既存機能から仮想化する、というのは、スタートポイントとしてはよいのだと思います。しかし、将来にわたっても既存機能や実装を大きく変えないのであれば、本末転倒、というか、仮想化しない方が最善策にならないでしょうか。
アーキテクチャ変遷
現在の仮想化への流れは、希有かつ大きなアーキテクチャ転換期です。通信業界はこれまでも、何度かアーキテクチャ変遷を経験しています。1985年頃の「サーキットからパケットへ」、2000年頃の「All IP」「Everthing over IP」「IP-NGN」。こうして考えてみると、15年に１回くらい、大きな転換が起こっていると言えそうです。そして、アーキテクチャ変遷を乗り越えることにより、次の発展への足がかりを築いています。今の「NFV」「仮想化」もひとつのアーキテクチャ変遷可能性と考え、今までのアーキテクチャを見直し、これまでやっていなかったことやできていなかったことを実現する契機になったら素晴らしいと思います。
[1] http://research.google.com/archive/mapreduce.html
[2] http://www.theregister.co.uk/2014/05/23/google_containerization_two_billion/
[3] https://speakerdeck.com/jbeda/containers-at-scale
[4] http://techblog.netflix.com/2012/07/chaos-monkey-released-into-wild.html
Tags:
