10 posts tagged “仮想化”
slideshareに「Elastic MapReduceでお手軽Wikipediaマイニング」というスライドがあがっていることを、社内SNSで教えてもらった（OKIの社内SNSもなかなか侮れない）。ohkura.comの大倉さんという方が公開されたものらしい。
■ 分散処理×クラウド≒Amazon MapReduce
MapReduceはGoogleが開発した分散処理アルゴリズムで、オープンソースによるJava実装にHadoopがある。このアルゴリズムをうまく使うと、大量の処理を細かく分割して多数のマシンで並列処理し、短時間で終わらせることができる。
例えば、40万5千件ずつのTiffファイルおよびXMLファイルを100台のマシンで並列処理し、36時間で81万件のPNGファイルに変換したNew York Timesの例のようにだ。しかしそうはいっても、彼らは100台ものマシンをどこからかき集めてきたのか？それも明かされている。クラウドだ！100台もの仮想マシンを即座に提供してくれるクラウドサービス、Amazon EC2だ！
Amazonのクラウドサービスには、その後Hadoopによる処理に特化し、まさにそのために要したコンピュータリソース分だけしか課金されないAmazon Elastic MapReduceというサービスを発表している。僕が教えてもらったこの資料は、まさにこのAmazon MapReduceを利用して、Wikipediaの巨大なデータを解析しようというサンプルだ。
■ Elastic MapReduceとWikipedia研究
Wikimedia Conference Japan 2009で武田英明氏が指摘しているように、Wikipediaのダンプデータというのは大規模性と網羅性を満たし、入手性の高い、きわめて興味深い貴重なデータだ。一方ででは解析を行おうとすると、鈴木優氏の取り組んだ課題である、あまりに大きすぎるデータが簡単には賄えない計算コストを要求する。僕も「企業Wikiにシグネチャを」にあるsilubeプロトタイプを開発した際、この困難を痛感した。
もちろん解決方法は分かっている。スケールアップかスケールアウトだ。モンスターマシンか分散処理だ。個人が手を出せるのは、Amazon EC2×Hadoop=Amazon Elastic MapReduceだ。
僕は今、silubeプロトタイプを再構築しようと、しばらくの間になまらせてしまったPerlスキルのリハビリを始めている（silubeプロトタイプはPerlで書かれている）。それが済んだら、拙い理解力でおずおずとAmazon EC2とHadoopの学習に進むしかないだろう、と思っていた。これをインスタントに理解させてくれそうな、手を動かして入門できるサンプルがこのタイミングで公開されたのはとてもありがたい。
もちろん、誰かに先を越されるのは大歓迎。さぁ、みんな、クラウド×Wikipedia研究を始めよう！
技術評論者様からWeb Site Expert #27を献本いただいた。感謝。特集は「クラウドコンピューティングで変わる？あなたの仕事（ビジネス）」で、今の私にとって非常にタイムリーでありがたい。
IT Leaders「国産クラウドの実力」のPaaS比較表(PDF)を見ると「利用に『発注』行為があって利用開始や構成変更まで5日」みたいなサービスも結構あるようで でもそれクラウドじゃないでしょ？ とAmazon EC2ユーザな人に言われたり、やっぱりEC2な人である横田氏がつぶやいた それはクラウドではなく、ただのVPSですよね？ を見るなりして、なんとなくクラウドと非クラウドの境界ということが、もやもやと頭の中に引っかかってた。クラウディに。 ● 仮想化すればクラウドということはなく、仮想化を基盤にしたデータセンターがクラウドでもない。それは運用者、提供者にとって大きな変化だけど、利用者にとってはこれまでと何も変わらないからだ。単なるデータセンタの効率化だ。
「サーバ設置型｣ということで、ハウジングを起点とする。専用サーバホスティングは、サーバの調達の手間や持込設置の必要がないという点でハウジングより身軽で、OSから上は好きにいじれるという点でWebホスティングなどよりずっと自由度が高かった。1台のハードウェアをパーティショニングで分割したVPS（バーチャルプライベートサーバ)は、エクスペリエンスという点では専用サーバホスティングとほぼ同様だったが、個人が手を出せる価格で提供された。
ではクラウド型PaaSは？これがパーティショニングではなく、いわゆる仮想マシンを提供するサービスだったとしても、それだけではユーザにとって「ただのVPSですよね？」ということだ。ただし、自由に組んだ仮想ネットワーク上に複数台の仮想マシンを配して一つのプラットフォームにできるようになると、「ほほう、仮想ハウジングですね」となる。VPSが専用サーバホスティングより廉価に提供されたように、仮想ハウジングはハウジングより廉価に提供でき（るはずだ）、調達の手間や持込設置の必要がなく身軽だ。
さて、ではこれが「発注や変更以来から5日」とか言わない、即時利用開始、即時構成変更されるDIYなシステムになると？このAmazon EC2のような形態になると、Try&Errorやタイムリーな（その分タイトに切り詰められる）りソース調達が可能になる。New York Timesがやったように、現実的な費用で36時間だけジャブジャブのリソースを使うこともできるようになる。はっきりと、利用の仕方そのもの、ユーザー･エクスペリエンスが変わる。
●
ユーザー･ベネフィットといってしまうとダウンタイムがどうとか、細かい数字の比較になってしまって、でもそれが何なのという感じだ。それよりもはっきりとしたクラウドでしかできないユーザー･エクスペリエンスがあるか。データセンタ側のことなんか知ったことじゃなくて
それはクラウドではなく、ただのVPSですよね？
とか
それはつまるところただのハウジングですよね？
と聞かれたときに、「ユーザーの使い方がこんなに変わるんだ」と答えられるかということが、案外、本質的なクラウドと非クラウドの境界かも知れない。
「仮想化の明後日と未来(前編)」の続きだ。もう少しだけ、未来というよりは明日に属するぐらいの、すぐ先のことを予想してみる。
「仮想化とシステムのモジュラー化」が示唆するのは、完全にコンピュータリソースの提供と、それを利用したサービス提供や活動を分離する。その最終形は、と考えていた時に、ITProの記事で次のような一文を読んだ。
取材の最後にふと思い付き、こう尋ねてみた。「仮想化の根本的な価値は何か」。ラグラム氏は少し間をおき、「Freedom」と答えた。（仮想化がもたらす“フリーダム” - 記者のつぶやき：ITpro）
VMware Virturlization From 2009の テーマは「VIRTUALIZE・AUTOMATE・LIBERATE」だった。LIBERATE、そしてFreedom。僕はこれを、コンピュータリ ソースを使うことの労力とコストからの解放であり、そうしたことが制約となってきた個人と個人の小さなアイデアが得る自由だと解釈する。
電気や水やガスの供給がインフラに組み込まれ、安定して安価に個人でも利用できるようにならなかったら、世界はこんなにリッチ・エクスペリエンスで はなかっただろう。同じようにコンピュータリソースの供給がインフラに組み込まれ、安定して安価に個人でも利用できるようになったら、世界はどんなにリッ チ・エクスペリエンスになるだろう。
今はインターネット上にクラウドが生まれ、ごく一部の種類のコンピュータリソースの供給がインフラ化されたところだ。そしてインターネットサービス を作るということにおいてのみ、個人はコンピュータリソースの制約から自由になった。本当に仮想化がコモディティとして個人の手元に浸透してきたとき、個 人があらゆるコンピュータリソースの制約から自由になるかもしれない。
（※本エントリは10月29日のtumblrへのポストに加筆、修正したものです。）
10月20日、21日にVMware社が開催したVMware Virtualization Forum 2009に行ってきた。その夜に、twitterで呟いた感想をまとめておく。
tsukamoto: Virtualization Forum 2009、いろいろと新しいものはあったけど、新しいパラダイムとまで言うようなものはたぶんなかったと思う。 (11:55 PM Oct 21st)
tsukamoto: 思うに仮想化そのものは「ハードウェアとOSを切り離す」というパラダイムシフトだったのだけど、それは60年代のパーティショニングとか90年代（？）のエミュレーションとかの頃からそのパラダイム上にあった。 (12:01 AM Oct 22nd)
tsukamoto: 仮想化が始まって以降の歴史上にパラダイムシフトがあったとしたら、「ハードウェアとリソースを切り離す」ということ、その1つだったんじゃないかな。 (12:03 AM Oct 22nd)
tsukamoto: このパラダイムが、ホストOSを持たないハイパーバイザ、巨大サーバではなくサーバ群をまとめて1つのリソース総量と捕らえるリソースプール、その中で使用するリソース量を「どこかから」自動的にわりあてるDRSといった新しいアプローチを生んできた。 (12:05 AM Oct 22nd)
tsukamoto: 今日デモしていたVMware MVPなんかも、端末が何かにとらわれず単なるリソースプールと考えてその上に載せるワークロードを提供すればいいという、同じパラダイムの敷衍で捉えていいように思う。 (12:07 AM Oct 22nd)
tsukamoto: …ああ、「ハードウェアとOSを切り離す」「ハードウェアとリソースを切り離す」より「ハードウェアを抽象化する」「コンピュータリソースを抽象化する」が正確かも。 (12:09 AM Oct 22nd)
コンピュータリソースが抽象化されると、ハードウェアから下を管理するインフラ技術者と、OSから上を管理するシステム技術者が、コンピュータリ ソースの提供/利用を境界にしてをきれいに分業できる。
インフラ技術者はコンピュータリソースの安定供給に努めればよく、システム技術者はOSやその上のアプリケーションによるサービスに専念すればよい。これは昔からある考え方なのだが、これまではコンピュータリソースの分割、コンピュータリソース供給の安定（可用性、復旧性、 etc.）の実現が、OSやその上のアプリケーションなどに食い込んでいて、そこをきれいな境界線として分けられなかった。
仮想化環境は、仮想化レイヤでリソースの分割、仮想マシンとしてパッケージしての提供、仮想マシンに対する自動フェールオーバやバックアップなどを可能にした。これにより、システムの「安定稼働」はインフラ技術者がハードウェアと仮想化レイヤで、「機能提供」はシステム技術者がOSとアプリケーションレイヤで、役割も作業レイヤもきれいに切り離して実現することが可能になった。
つまり、仮想化で実現できるレベルのリソースコントロールで十分なシステムであれば、システム構築はインテグラル（擦り合わせ）型からモジュラー（組み合わせ）型にシフトした。
（※本エントリは10月26日のtumblrへのポストに加筆、修正したものです）
VMware HAは設定が簡単なのだが、その簡単な設定をした時にエラーが起きると、何を調べるべきかが難しい。VMware社のKBに「Diagnosing a VMware High Availability cluster configuration failure」という記事があったので、対処ステップ部分を簡単に訳しておく。
- 構築しようとしているVMware HAのライセンスが足りていることを確認する。詳細はKB 1003692参照。
- ESXサーバ上で名前解決が正しく設定されていることを確認する。詳細はKB 1003735参照。
- VMware VirtualCenterサーバ上で名前解決が正しく設定されていることを確認する。詳細はKB 1003713参照。
- VirtualCenterサーバからESXサーバへのネットワーク接続が存在することを確認する。詳細はKB 1003486参照。
- ESXサーバから離れたレスポンスアドレスへのネットワーク接続が存在することを確認する。詳細は同じくKB 1003486参照。
- 必要なネットワークポートが開いていることを確認する。詳細はKB 1003487参照。
- dateコマンドによるESXサーバの時間が正しいことを確認する。詳細はKB 1339を参照。
- インストールされているVirtualCenterエージェントのバージョンが正しいことを確認する。詳細はKB 1003714を参照。
- VirtualCenterサーバサービスが再起動されていることを確認する。VirtualCenterサーバサービスの再起動についてはKB 1003895を参照。
- VMware HAの構成を試みているサービスコンソールが一つだけであることを確認する。詳細はKB 1003789を参照。
- VMware HAクラスタが衝突していないことを確認する。これを行うためには、テストとして別のクラスタを作成する必要がある。詳細はKB 1003715を参照。
もしこれでもだめな時は、まずVMware Support Script Data（診断データ）を収集する。詳細はKB 1003689を参照。そしてこれとこのKBの文書ID（1003692）を問題の記述に沿え、サポートリクエストを作成する。詳細はHow to Submit a Support Requestを参照。
2月ごろにデスクトップ仮想化の性能比較について、ひと騒ぎあったらしい。virtualization.infoより。
ベンチマーク：ESX対XenServer対Hyper-VのTerminal ServicesとVDIワークロード対決（2009.02.02）
Project Virtual Reality CheckがVMware、Xen、Hyper-VなどのベンチマークをWhite Papersとして発表。VMwareについてメモリのオーバコミットメントがあるのは明白なアドバンテージ、またXenDesktopについてターミナルサーバとXenAppに対しての最適化が明らか、と述べている。
VMware社がVirtual Reality Checkベンチマークに反応（2009.02.03）
VMwareがブログエントリ「VMware: VROOM!: Virtualizing XenApp on XenServer 5.0 and ESX 3.5」を公開。XenApp使用時について、同じユーザー数での待ち時間（latency）、CPU使用率ともVMware ESX 3.5の方がXen Server 5より低く、最大ユーザ数はVMware ESX 3.5の方が高かったとのグラフを提示。
ベンチマーク：Citrix XenDesktop 2.1 Scalability Analysis（2009.02.09）
上の論争に関連して、Citrixが1月に公開していたXenDesktop 2.1 Scalability Analysisを紹介。XenDesktopがだいたい25仮想マシン/サーバぐらいでリニアにスケールアップすることを示している。ちなみに公開は1月12日だが、2月27日まで行進が行われている様子。
ベンチマーク：Citrix XenDesktop 2.1対VMware View 3.0（2009.02.17）
Tollyが単独（ただしVMware協賛）でVMware View 3 PremierとCitrix XenDesktop Enterprise 2.1のユーザビリティ(？)テストのレポートを公開（参考：VMware社ブログエントリ）。Citrixは「VMware releases a new report that's already outdated」VMwareが賞味期限切れのレポートを発行、と反論した。
メモリのオーバコミットメントの効果については、VMware社のパートナーアップデートセミナー2008秋の資料「実践デスクトップソリューションVMware Virtual Desktop Infrastructure」に実験結果がある。メモリ8GBのマシン上で、仮想メモリ1GBの仮想マシンが何台起動できるかを比較するというもので、たしかに起動できる台数は違うみたい。これはそういう仕組みがあるかないかという問題なので、信じてもよさそう。
他のパフォーマンスの優劣については、こうなるとどうとでも取れるという程度のような気がしてくる。
