これまで私は至るところで、「仮想化アーキテクチャでは、モジュラー性・オープン性が重要。垂直統合してしまったら意味が無い。」と述べてきました。
今でもその考えは変わっていません。コモディティ化した汎用ハードウェアと仮想化アーキテクチャで実現するソフトウェア中心のシステムは、新たなサービスの柔軟かつ迅速な展開、小規模スタートや実験的展開、顧客の細かい要求に応じたテーラーメイド サービスなどに、大きな価値を発揮します。これらは、これまで周到な設備計画が必要だったハードウェア中心のシステムでは実現できなかったことです。しかし、その機能の性能最適化をしたければ、目的に特化したハードウェア システムの方が、コスト、スペース、電力等、あらゆる面で適しています。既に機能が固定化されているような既存サービスの置き換えや、大容量高性能を目指すシステムには、仮想化アーキテクチャは勧められません。
しかし、しかし…。現実というものは、そんなに簡単に割り切れるものでもありません。「仮想化システムだから性能出なくても仕方ない。性能よりも重視すべきはモジュラー性とオープン性、云々かんぬん…」とか言ったら、お客様は間違いなく離れてしまいます。
では、オープン性やモジュラー性を保ちながら性能を最適化することは可能なのでしょうか。いや、すみません、無理です。現実問題到底無理です。どんなハードウェアや NIC（Network Interface Card）を使おうが、どんな HostOS/Hypervisor を使おうが、どんな Virtual Switch（OVS, Linux-bridge, VPP*1、Snabbswitch*2、DPDK-OVS*3など）を使おうが、ある一定の性能値を保証する、なんてことは、できる訳ありません。
これまでシスコとしては、まずは User Space の Virtual Switch として、性能最適化した VPP（Vector Packet Processing）を開発したりしていますが、基本オープンという方針を貫いていました。（この辺については、ネットワーク アーキテクチャ考 (13) 「仮想化：性能面の課題」 をご参照ください。）しかし、これではどうにも立ち行かなくなってきました。そこで紆余曲折の上の解が「パッケージング」です。NFV OS（仮称）というもので、転送の高速化、低遅延化（VM 間、ホスト間）、VNF 間のサービスチェーニング、VM だけでなく高密度で軽量な VNF（LXC、Docker、UML [User Mode Linux]）のサポート、などの機能をパッケージ化しよう、というものです。（図1）
図1 NFV OS
サードパーティの VNF やハードウェアもサポートしますので、ある程度のオープン性は保持しています。少なくとも垂直統合ではありません。一方、Hypervisor と転送プレーンを含めてパッケージングし、パッケージとして検証した上で出荷しますので、ある程度の最適化保証ができます。どうでしょうか。妥協の産物かもしれないですが、必要な妥協のような気もします。ご意見をお伺いできると嬉しいです。
なお、ここで思い出すのが、ダイクストラ（1930-2002）の「寓話（Parable）」です。この件とは別のコンテクストで、シスコ本社の同僚が教えてくれました。ダイクストラは「構造化プログラミング」の提唱者であり、OSPF や IS-IS で用いられている経路計算アルゴリズム（Shortest Path First）の考案者です。さらに、逆ポーランド記法や排他制御（セマフォ）の考案者、分散コンピューティングの先駆者というのですから、我々にとっては神のような存在です。
原文は、↓で参照できますが、ここに抄訳してみます。
https://www.cs.utexas.edu/users/EWD/transcriptions/EWD05xx/EWD594.html
ある鉄道会社があった。その会社はコスト削減のため、これまで全ての車両に設置していたトイレを、半分の車両にのみ設置することにした。
しかしすぐに乗客から不満の声が上がった。車両整備の現場では、トイレのある車両とトイレの無い車両を区別していなかったため、場合によってはトイレの全くない列車が組み上がってしまっていたのだ。
そこで列車を組む際、トイレのある車両とトイレの無い車両が、それぞれ半分の割合になるように、と指示がなされた。当初現場はかなり混乱したが、何とか問題なく運用できるようになった。
しかしこれでも不満の声が続出した。列車としては半分の車両にトイレがあったとしても、トイレのある車両が前方に固まってしまったりしたからだ。そこで、トイレのある車両と無い車両が交互に接続されるように車両を組むことが指示された。現場はさらに混乱したが、何とか運用できるようになった。
これで全て上手く行くはず、と思ったが、そうではなかった。トイレのある車両と無い車両が交互になったとしても、トイレの設置位置の問題で、最悪ほぼ三車両分移動しなくてはいけない、ということが起こり得た。これは子供連れの母親にとって、通路が荷物などで混雑していた場合は特に、災難としか言いようがない。そこで、トイレの設置位置は、全ての車両とも同じ方向になるように指示がなされた。これも現場にはかなり大変な指示であったが、何とか対応した。
今度こそ問題解消、と思われたが、それでも乗客からの不満は続いた。トイレまでの距離は均等になったのだが、自分の位置からどちらの方向に移動すればより近いトイレに着けるのかがわからない、と言うのだ。そこで、トイレの位置を矢印で示すプレートを車両に貼るように、という指示が出た。
これには、勤勉な現場作業員もさすがに反乱した。トイレの無い車両にまで、どうやって矢印を貼れるんだ？！そんなの無理！！
すると、ある人が言った。「トイレのある車両とトイレの無い車両の二つを、一つのペアとして扱えばいいんです。」
パッケージングすることによって、複雑性を隠蔽し、統一的なロジックで扱えるようになる、という例です。ダイクストラの言いたかったことは、「賢いプログラマは、こうやってロジックのシンプル性を保つ」ということなのでしょう。
こう考えると、パッケージングって強力なツールになり得ます。モジュラー性・オープン性を議論する際も、その単位の捉え方は必ずしも一つでは無い、ということです。行き詰まっていたところに、少し道が見えた気がします。（甘いかな…。）
*1 Cisco Vector Packet Processor
http://www.google.com/patents/US7961636
http://gblogs.cisco.com/jp/2015/02/network-architecture-13-issues-of-performance/
*2 Virtual Ethernet Switch Toolkit , vhost-userを用いて性能向上を図る
https://github.com/SnabbCo/snabbswitch
http://www.virtualopensystems.com/en/solutions/guides/snabbswitch-qemu/
*3 OVS(Open vSwitch)について、Intel DPDKを用いて性能向上を図る
https://github.com/01org/dpdk-ovs
Authors
3 コメント
元来、性能保証はされていないのではないでしょうか？
カタログシートの数値は特定条件下での結果でしかなく、たいていは「お客様の利用環境に依存します」と断り書きがありますし
仮想環境も同様で、割り当てたリソース（CPU/Mem/IOPS/…)が基本性能（カタログスペック）だと思います
クラウド時代では性能不足ならばリソースを追加することが解決手段なので、上の図を例にするとNFV OSの性能不足ならばVNFを他筐体へ移動（live migration)してリソースを確保するのが解決手段ですね
VMの話になりますがこの辺りはVMWareではvCenter（オーケストレータ）が管理してます
hypervisor上のネットワークが難しいのは、VNFとそこに紐付くVMの組み合わせ（＝クラスタ）を常に意識しなければならないので、これらをどう物理的なハードウェアにマッピングするかをオーケストレータが管理する必要があることです
VNFを移動するのかコピーするのか、設定だけ移行するのか、現実的な（＝運用可能な）解は自分の中にまだありませんが:-<
コメントありがとうございます！嬉しいです．
おっしゃるとおり「性能保証」はできません．ここでの「パッケージング」は，「性能改善」を目指したものです．
性能不足ならばリソースを追加する，というのは原則的にはそのとおりなのですが，パケット転送性能を例にとると，hypervisorでコピーが発生すると，リソース(NIC性能や帯域）に余力があってもスループットはかなり低くなってしまいます．また，リソースが同一であっても，読み出しを並列処理化すること等により，スループットを向上させることもできます．まずは，この辺の改善を目指そう，というのが，本記事での「パッケージング」の内容です．
さらに，今回ご指摘戴いたplacementのことを考えると，オーケストレーションとリソース管理の連動が必要になりますね．シンプルなリソースのタギング，カラーリングのようなものでマッピングできないか，と考えていますが，どうでしょう．
なるほど、読み違えていたようです
特定ベンダの汎用OSと言う意味だと、Oracle製品に最適化されたOracle Linux/Oracle VMと同様の道を辿るような気がします。
それぞれRedhat・Xen互換でオープンだとと謳っていますが、実情はoracle製品を載せるためだけの基盤でしかなくなってます。
Redhat・CentOSからの乗り換えキャンペーンなど良い評判は聞こえてきませんが、互換性がある以上、自社プラットホームに引き込みたくなるのは必然で、この辺りは技術からマーケティングにすり替えやすいのが原因かと思います。
オープン性をエンジニア的にどこまで死守できるかが肝なのしれません。
コンテナの世界でも同じような発想でCore/Atom/Garden/Photonなど各ベンダがリリースしていますが、これらもどこに落ち着くかまだわからないですね。結局標準ディストリが一番、というオチになるような気もします。
同様の思想だったJavaOSなんてどこへいったやら
逆に上手く立ち回ってるのはOSやアプリには手を出さずNICなどのハードに特化しているIntelではないでしょうか。
ハード側の機能も日々進歩していて、OS側の実装も進んでいます。
http://www.slideshare.net/syuu1228/10-gbeio
ただ、上記の話を突き詰めると、catalystのstackableケーブルとPCが繋がるような世界、ホワイトボックススイッチ＋VM/コンテナ若しくは汎用サーバ＋スイッチカード に行きつくのでは？と思います。
Ciscoはハードウェアを作る体力のある企業ですので、OSやアプリに手を延ばすよりもハード寄りのアプローチのほうが個人的には合ってるかと。