昨夜、丸山先生が tweet していた、仮想化/分散の類型について魚拓をとる。
で、私の考え方をとりあえず文にしてみる。
- VMwareなどのシステム仮想化は、まず、ハードウェアとサービスを分離する意味で、導入しやすい。これはステップ1としては、すごく有効だと思われる。
- 丸山先生の分類でいくと、(1)->(2)への変更
- アプリケーションの変更の必要がない
- 既存のテスト/テストコードが流用できる可能性が高い
- 企業内に複数のOS/プラットフォームが混在する場合に混ぜやすい
- コストとリスクを抑えつつ、ハードウェアからの分離が可能になり、運用コストを下げられそう
- リソース効率を追求するなら、ソフトウェアレベルでプロセス分散できるように作りたい。
- それは普通にフォールとトレラントな分散システムとして設計しましょうということ
- 単一ノードが落ちても、欠損無く全体として動きつづける、分散システム
まあ、そこそこの規模の企業には、歴史的に、複数のOSやプラットフォームが混在しているケースがあると思いますし、保守会社がいろいろあって集約するのは現実的でないと考えていると思いますが、集約していったほうが安いなら、そっちに振っていくほうがバリューは高いですよ、ということになるとおもう。蛸壺ヤメれ、と。その場合、過渡的には前者、先は後者に変化していくといいんじゃないか、と思います。徐々にプラットフォームや、テスト、実行環境をマージしていく。
ということで、ここまでは私の主張です。
以下、丸山先生のtweet魚拓です。ありがとうございます。
http://twitter.com/maruyama097/status/4445545635
分散環境の単位となる「ノード」のことを考えている。いくつかのアプローチがある。階層的に。(1)物理的なサーバ自体をノードとする。
(2)仮想化されたOSをノードとする。
(3)仮想マシン(Java VM+α)をノードとする。
(4)プロセス/スレッドをノードとする。
http://twitter.com/maruyama097/status/4445650445
GoogleのMapReduceやBigTableの実装は、(4)のアプローチ。
AzureのWorker Role,Web Roleも(4)。
ただ、多分、GFSは、(1)のアプローチ。
AzureのStorageも(1)だと思う。
Amazon EC2は、おそらく(2)のアプローチ。
http://twitter.com/maruyama097/status/4445741278
面白いのは、Paremusは、Java VMをOSGiでラップしてコンテナーを作り、それを単位とする(3)のアプローチ。マイナーだけど、これはこれで面白い。OSGiが、リソースの管理、プログラムのロード、死活管理など、ミニマルなOSの役割を果たしている。
http://twitter.com/maruyama097/status/4445873400
(1)のアプローチのメリットは、対障害対策がシンプルにできること。障害は、たいてい、物理サーバ自体が障害にあうという形で起きるから。中の複数の仮想OSや沢山のプロセスごと死んでしまうことも起こりうるから。
http://twitter.com/maruyama097/status/4445944769
(2)のメリットは、見かけ上管理しやすそうに見えること。ただ、co-Designの精神で見直すと、無駄も多いはず。分散システム上のノードは、たいていは、固有の役割を負わされている。フル・スペックのOSが必要とは限らない。
http://twitter.com/maruyama097/status/4446009006
Amazon EC2は、(2)型だと言ったが、それは、AMIでイメージを焼いて受け取るレベルの話。EC2で、Hadoopを動かせば、Mapper NodeやReducer Nodeは、プロセスとして起動される。それは、当然のこと。
http://twitter.com/maruyama097/status/4446109044
個人的には、(1)(4)の方法を組み合わせるのが現実的。問題は、Diagramで表現すると、物理(仮想)サーバのノードとプロセスのノードの区別は出来ないこと。でも、何らかの区別を記述する方法があってもいいと思っている。
http://twitter.com/maruyama097/status/4446202784
大きな問題は、先に述べたように、障害対応なのだが、多分、もう一つ問題が出てくるだろう。Multi-Coreの扱いである。そのうち、128コアとかが現実に出てくるだろう。これを、SMPモデルで考えるとつまらないと思う。1Chip化された分散システムとして考えた方がいい。