Amazon EC2などのクラウドサービスにより、ITでは仮想化が非常に注目を集めるようになりました。こうしたサービスは利用可能なハードウェア上で新規のバーチャルマシンを迅速に供給するという、仮想化で最も人気のある特徴を土台に築かれてきました。クラウドコンピューティングの核心にある前提は、「極端な容量を備えた大規模インフラ」であり、必要とする組織にそれを販売するのです。小規模システムに必要な個々の断片を顧客に切り売りすることにより、大規模インフラの柔軟性と構造を提供できるのです。

仮想化は人気がある上、プロバイダの容量上で利用可能な余剰部分を使って、ほとんど即時に新規の（仮想）サーバーを供給する能力がありますが、その能力以上に多数のメリットを提供します。仮想化の全体的な価値は、高度の可用性や災害時のリカバリ、アプリケーションの高速供給といった、いっそう複雑なメリットにあります。簡単に言うと、ハイパーバイザー自体がコモディティ〔日用品〕化したのです。ほとんどすべての仮想化プロバイダがコモディティ化の実現を証明しています。Xenハイパーバイザーはオープンソースの自由なコミュニティで開発されました。VMwareがESXiを作り上げたのはつい先ごろ、今月のことですが、ESXiはフットプリントが最小限のエンタープライズ級ハイパーバイザーであり、無料でダウンロードできます。けれども、両製品ラインの複雑な機能は依然として販売用に確保してあります。

この論文では、こうした複雑なメリットと実世界における応用を検討します。さらに重要なこととして、Contegixが複雑な問題の解決に仮想化を実装している方法や、仮想化を使うべきではないケースについて詳細を提供します。

企業：原動力は仮想化

企業を対象とした仮想化の価値を引き上げるのは、迅速な供給というポイントを越えたところに存在する多数の特徴です。最も重要なのはリソースの最大活用、アプリケーションの高い可用性、災害時におけるビジネス継続性です。こうしたトピックはあらゆるCIO（最高情報責任者）やCTO（最高技術責任者）にとって、要件の中心になっています。仮想化の真の力はこうした特徴にあるのです。

クラウドコンピューティングは依然として、あらゆる企業向けに普及している技術デプロイメントプラットフォームというわけではありません。決してそうならない可能性もあります。多数の組織が、そうならないような厳格なガバナンス下に置かれています。コンプライアンスに対する懸念とクラウドプロバイダに対する信頼の欠如が、制限要素として働いています。HIPAA法（Health Insurance Portability and Accountability Act：医療保険の相互運用性と説明責任に関する法律）やサーベンス・オクスリー法（SOX）のような法律の解釈では、法律に準拠しないことによってもたらされる潜在的な負の影響を、ライアビリティとみなすことが多いのです。この件が確実に対処されるまで、クラウドへの全移行は企業にとって難しいでしょう。

だからと言ってそうした組織では、全コンピューティングリソースを完全活用することによる、スケールの柔軟性というメリットを利用してはならない、というわけではありません。その核心にあるのが、専用ネットワークインフラを備えた専用コンピューティングリソース上の仮想化です。要するにこうした企業は、私用のクラウド（もっと正確に言えば、私用のクラウド様式のアーキテクチャ）を構築し、活用しているのです。

VMWareとCitrix XenServerには、利用可能な物理ハードウェアの全リソースを最大化する能力があります。バーチャルマシンのリソース要件と仮想化クラスタ内の物理サーバーの能力との間で、動的にバランスを保つことができます。バーチャルマシンが起動すると、仮想化スタックはバーチャルマシンをリソースとともに、物理サーバーに割り振ります。

ほとんどの仮想化スタックには、アプリケーションの高い可用性を促進させる機能が組み込まれています。この組み込み機能は、Oracle CoherenceやMicrosoft Cluster Serverなどのクラスタ化技術を完全に補完するものではありません。ハードウェアレイヤで発生する障害に対処し、また、こうした機能を持たないアプリケーション向けに高度の可用性を促進するよう意図されたものです。

こうしたアプリケーション向けの高度な可用性は一般に、アクティブ-パッシブ設定の複数ノードを使ってもたらされます。プライマリ-アクティブのノードにサービスの要求を送信することにより、機能します。プライマリ-アクティブのノードが反応しないと、セカンダリノードがプライマリ-アクティブに格上げされ、そこへ要求が送られます。 依然として問題があります -- 元々のプライマリ-アクティブ・ノードに保持されていたインメモリのデータがすでに使えなくなってしまったことです。

この問題は、VMWareのVMotionやCitrix XenServer XenMotionなど、ライブのマイグレーション機能を使って解決できます。VMotionやXenMotionにより、実行中のバーチャルマシンを基本的な物理マシンから別のマシンへと、ディスク上であろうが、メモリ内であろうが、データ損失なしにマイグレーション可能で、ネットワーク接続性やクライアントの損失もありません。こうしたことがなぜ可能かというと、バーチャルマシンの全メモリステートと、正確な実行ステートを、物理マシンから別のマシンへ複製しているからです。バーチャルマシンの設定と全体的なステートは、共有記憶装置スペース上に保存されます。

実行中のバーチャルマシンを搭載している物理サーバーに停電が起こると、仮想化スタックが停電を検知し、２番目の物理ハードウェア上に複製されたバーチャルマシンを起動します。バーチャルマシンのマイグレーションは、実行中のマシンのコア状態（正確な実行ステート、ネットワークID、動作中のネットワーク接続）を保存します。これにより、ダウンタイムゼロのマイグレーションが可能になり、ユーザーへのマイナス影響もありません。

リソーススケジューリングやバーチャルマシンのライブ・マイグレーション、企業ストレージシステムの複製といった機能を組み合わせることにより、ビジネスを継続する能力がもたらされます。バーチャルマシンは、ひとつのバーチャルクラスタから別のクラスタへと、物理的な距離はほとんど関係なく、そして基本的なハードウェアに左右されることもなく、複製可能です。

SaaS：原動力は仮想化

SaaS（Software-as-a-Service）への注目度は高いのですが、市場はまだ完全に成熟していません。これには多数の要因が働いています。いたるところで見られる要因には、開発以外のインフラにかかる立ち上げ費用が、不釣り合いなほど大きな割合を占めるという事実があります。それにもかかわらず、収入を生み出すまでには複数年かかります。それゆえ、最初の顧客で結果を出すには多額の費用を要しますが、その後の顧客については費用がずっと少なくなるはずです。SaaSをデプロイするには一定レベルの一貫性も必要ですが、それと同時に、顧客レベルで修正がきくように十分な柔軟性を保っておくことも必要です。

一般的なSaaSの顧客は、インフラの費用や懸案事項を気にかけません。典型的なSaaSの販売に使用されるのは、どちらかと言えばアメリカン・エクスプレスの法人カードですが、企業内部のソフトウェア購入にはCレベルの重役（編集部注：CEOやCIOなど、頭にC〔Chief〕がつく役職）の承認が多数必要になります。そのため、SaaSベンダーは値頃感を越えない価格に留めておく必要がありますが、それは初期インフラ費用の素早い相殺とは反対の行為に当たります。ハードウェア機器の購入だけにとどまらず、インフラには提供中のアプリケーションのデプロイメントやサポート、管理、メンテナンスに関わる長期的に継続する費用が含まれます。

インフラとデプロイメントを越えたところに焦点を合わせると、SaaSアプリケーションプラットフォームでは再現性を中心に考えるべきです。SaaSによって提供されたアプリケーションのあらゆるインスタンスは、他のインスタンスとほぼ同一である必要があります。顧客毎のアプリケーション・インスタンスの振る舞いに一貫性を持たせるため、さらに、同一のトラブルシューティング基盤からサポートを始められるようにするためには、相違を最小限にとどめる必要があります。そうしないと、次のようなことがあり得ます。単一の顧客インスタンスにApacheモジュールが欠けていたことが問題の原因だった -- こんなことを発見したいサポート・エンジニアなどいるでしょうか。あるいは -- SaaS企業が全オーダーの各段階を正確に再生できないため、注文したアプリケーションの各インスタンスに問題が発生する可能性がある -- 顧客にしてみれば、いい迷惑です。最後にきてさらに複雑性を追加するのは、一貫性と費用の理由から、全プロセスを自動化する必要性です。

（重要な例外があり、その中にはアプリケーションデータ、デプロイメント・インスタンスデータ、スケーラビリティ用の潜在パラメータなどがあります。しかしながら、こうしたものはアプリケーション向けのメタデータやユーザーデータに過ぎません。別の顧客にアプリケーションを再供給したい場合は、こうしたデータはほとんどの場合削除され、白紙の状態からのスタートになります。）

それでは、こうした一貫性が問題となるのはなぜでしょう。SaaSアプリケーションでも従来のアプリケーションでも、現在のアプリケーションにおけるデプロイメントの複雑性を理解することが肝要です。最も単純なWebアプリケーションでさえ、裏に潜むデータストア・レイヤの管理は、もはやアプリケーションの責任ではありません。この責任はデータベース、一般にはMySQL、PostgreSQL、Oracle、SQLサーバーなどのRDBMSに委譲されたのです。JavaやRailsなどの典型的なWebスタックと組み合わせると、スケーラブルなデプロイメントが必要な多層のアーキテクチャがもたらされます。たとえば、RailsアプリケーションにはApacheやMongrelクラスタ、memcache、MySQLが必要かもしれないのです。

対処すべきデプロイメント問題は、アプリケーションの初期インストレーションならびに、アプリケーション・インフラを全体的に接続することだけではありません。アプリケーションコンポーネントに異なるリソースが必要なことが多々あります。様々なコンポーネント専用に特別なリソースを提供し、その可用性や一貫した振る舞い、枯渇の阻止を確実にすれば、有益なことがしばしばあります。たとえば、MongrelクラスタもしくはTomcatのインスタンスには決まった量のCPUとRAMの割り当てが可能ですが、依存しているデータベースには別の要件があります。これは、1つのサービスが別のサービスを枯渇させてしまうことを阻止する上で役立つでしょう。

さらに、アプリケーションのアジャイルな特性により、簡単に拡張できますが、その際はプラグインやマクロ、マッシュアップを介することがよくあります。より小さなインスタンス向けに開発されたエクステンションは、あらゆる組織のレベルに応じてスケールしない可能性があります。一顧客（もしくは、アプリケーション・インフラのスタックを共有している顧客グループ）のアプリケーションスタック内で問題が発生すると、目標は、違反システムを回避して、他に対する潜在的な影響を最小限にとどめることです。SaaSの顧客は、他の顧客が原因でリソースを制限する状況が起こり、そのせいで自分の問題が発生したなどとは、聞きたくもありません。

この要件を満たす方法はいくつかあります。インフラに関しては、クラウドコンピューティング的な見地からハードウェアの問題に取り組むことであり、仮想化技術を使用したインクリメンタルなスケールが可能になります。同時に、デプロイメント、サポート、メンテナンスを管理する上でも、役立つことが分かります。物理ハードウェア側のデプロイメントの一貫性については、CfengineやPuppetのようなツールを利用できます。リソースの制約は、 /etc/security/limits.confを介して、Solaris zonesやLinux PAMなど、動作中の特定機能を使って適用できます。非常に素晴らしいツールです。それでも、仮想化を利用してこうした問題に取り組めばもっと良い方法があり、固有のメリットを多数もたらします。仮想化により、コンピュータサイエンスに「関心の分離」というコア概念を実装することができるのです。

関心の分離は、アプリケーションを「機能面において可能な限り重複がない、複数の明確な機構」（Wikipediaから引用）に分割する前提となります。仮想化を使えば、この概念をインフラに適用できます。各アプリケーション、各顧客、各クラスタベースで、関心の分離を適用可能です。ですから、水平および垂直にスケールする能力を提供しながら、それと同時に基礎をなしているハードウェアの限界まで、依然としてフル活用しているのです。これはSaaS市場へ参入させたいと思っているシングルテナント・アプリケーションに特に有益です。ほとんどコードを変更することなく、基礎をなしているハードウェア上で即時にマルチテナント化できます。

ContegixのSaaSプラットフォーム上では、デプロイされた一般的なデプロイメントモデルが２つあります。両者を区別する要因は、アプリケーションの開発方法がらみであることが多く、デプロイメント毎に一顧客をサポートするか、あるいは単一デプロイメント上で複数の顧客をサポートするかということです（シングルテナンシー対マルチテナンシー）。

単一顧客のSaaSデリバリでは、限定数のバーチャルマシンを利用して顧客アプリケーション・インスタンスをデリバーします。わずか1基か2基のバーチャルマシンに限定されることが多々あります。たとえば、1基のバーチャルマシンがWeb階層からデータベース階層を介してアプリケーション全体をデリバリ可能ですし、あるいは、別々のマシン2基に分け、各自のレベルでスケーリングすることも可能です。仮想化のリソース割り振り能力を使えば、追加のCPUコアをPostgreSQLバーチャルマシンに素早く追加できます。動的リソース配分により、必要とされるリソースを持っている物理マシンに、バーチャルマシンを素早く移動することができます。

もう一つの一般的なデプロイメントモデルは、より高度の分離を提供するものです。 基礎をなしているインフラ・アプリケーションは複数のバーチャルマシンに分離され、各自必要なレベルにそれぞれスケールされます。たとえば、PostgreSQLデータベース、Javaの様々なWebアプリケーション向けのTomcatコンテナ2個、 Rails Webアプリケーション用のMongrelクラスタという構成のアプリケーションは、各コンポーネントに別のバーチャルマシンを用意するように設定することも可能です。シングルテナントの例を越えたところでは、バーチャルマシンのリソースとインスタンス数という点から見て、個々のコンポーネントのスケーリング以上のことが可能になります。nginx（もしくはApache）によるプロキシを介してラッピングされたWeb階層はすべて、フロントエンドの顧客に見える変更は皆無で、シームレスな移行を提供します。多数のマシンによるファイルレベルのデータアクセスは、ネットワークの共有か、クラスタ化されたファイルシステムを介したブロックレベルの機器で実現します。再度申し上げますが、このモデルは大量のインスタンス、あるいは複数顧客のアプリケーションに大変有用です。

デプロイメントモデルに関係なく、OSとアプリケーションのインストールをアプリケーションデータから分離させることが非常に重要です。次は、アップグレードのプロセスや処理方法が話題になります。OSとアプリケーションのインストールは、いつでも新しいコピーや新バージョンで置き換えられる、揮発性のデータとみなすべきです。アップグレードではまさにこの方法を使って処理します。こうしたパーティションの新バージョンは、アップデートされたOS、アプリケーション、コンフィギュレーションによってオーバーレイされます。デリバリする成果物はアプリケーションですが、デリバリのメカニズムの方がずっと大規模であることをさらに物語っています。

アプリケーションをデリバリする力として、仮想化を活用することには、本質的なメリットがあります。バーチャルマシンを1つの物理マシンから別の物理マシンに移動するという仮想化の特徴について前述しましたが、これは重要なメリットです。PAMなどの物理ハードウェアソリューションでは、ユーザーデータの移動と、ホストのOSレベルにおけるコンフィギュレーション・ファイルの同期が必要になるでしょう。さらに、サンドボックスとしてバーチャルマシンを素早く構築、展開、テストし、また、標準ツールを使って比較することも可能です。UNIXコマンドの「diff -r」とMF5のチェックサムを2つの異なる画像で実行する様を想像してみてください。

仮想化がニーズを満たさないケース

新しい流行語がついたあらゆる概念がそうであるように、仮想化についても人々は、新旧ひとくくりにしたあらゆる問題を仮想化が解決してくれる、と考える傾向にあります。現実はというと、仮想化がすべてのシステムとアプリケーションに有効というわけではありません。アプリケーションによっては、必要とするリソースが高度すぎることもあります。大規模なデータベースサーバーや集中的なUDPネットワークのような、高度のI/O環境で最もよく見られるケースです。

簡単に言うと、何度も繰り返しテストすることです。

著者について:

Matthew E. Porter氏はContegix LLC社の最高経営責任者です。Contegix設立前は、Contegixの親会社であるMetissian LLC社を共同経営していました。セントルイス大卒（コンピュータサイエンスの理学士号を取得）。

原文はこちらです：http://www.infoq.com/articles/virtualization-saas
（このArticleは2008年8月31日に原文が掲載されました）