単一サーバーでも仮想化すべき理由

仮想化に関する会話において、コンソリデーション（サーバー仮想化の文脈では、仮想マシンのバリアによって分離されながら複数の従来の物理ワークロードを単一の物理ボックスに集約すること）という概念が、仮想化の核心となる基本機能として扱われることが非常に多いと感じています。疑いなく、ワークロードのコンソリデーションは仮想化において驚くべき機会をもたらしますが、仮想化の価値とコンソリデーションの価値を混同しないことが極めて重要です。コンソリデーションは仮想化の主要な価値であり、その主な正当化理由であるという見方をあまりにも多く見てきましたが、これは事実ではありません。コンソリデーションはボーナス機能ですが、仮想化を正当化する際に必要とされるべきものでは決してありません。仮想化はほぼ自明の結論であるべきで、コンソリデーションは評価されなければならず、多くの場合は使用されないでしょう。ワークロードをコンソリデートすべきでないことが、それらのワークロードが仮想化されるべきでないという信念につながるべきではありません。この点についての仮想化の意思決定スペースを探っていきたいと思います。

仮想化は、実用的な意味でまさにそれが何であるかとして、ハードウェアの抽象化と考えるべきです。仮想化はハードウェアをカプセル化し、予測可能でクリーンなハードウェアセットをゲストオペレーティングシステムに提供します。これは複雑さを加えるように聞こえるかもしれませんが、実際にはオペレーティングシステムやドライバーの製造者にとっても、システムを設計するITプロフェッショナルにとっても、多くのことをシンプルにします。コンピューター、コンピューター周辺機器、オペレーティングシステムが非常に複雑な存在であるため、この追加レイヤーは実際には標準インターフェースを作ることでシステムから複雑さを取り除くことになります。標準化からシンプルさが生まれます。

ソフトウェアレイヤーに標準的な仮想マシンを提示するというこの全く同じ概念は、多くのプログラミング言語がどのように実装されるかなど、コンピューティングの他の領域にも存在します。これは非常に成熟した信頼性の高いコンピューティングモデルです。

ハードウェアの抽象化とそれがもたらす安定性だけでも、仮想化をすべての面で標準化するのに十分な理由ですが、現在私たちが利用できるすべてのエンタープライズ仮想化製品によって実装されたハードウェア抽象化の実用的な性質は、さらに重要な機能をもたらします。確かに、仮想化のほとんどの利点は他の方法でも得られますが、仮想化ほど完全に、確実に、シンプルに、または無料で得られることはほとんどありません。

追加機能の最大のセットは通常、ストレージとメモリの抽象化から来ており、ストレージのスナップショット、あるいは仮想マシンの実行状態全体のスナップショット、つまり実行中のシステムのイメージを取得してファイルに保存する能力をもたらします。この能力により、新しいソフトウェアをインストールする前、設定を変更する前、パッチを適用する前にシステムのスナップショットを取得する能力など、多くの非常に重要な機能が生まれ、何か問題が発生した場合に非常に迅速なロールバックが可能になります。一見マイナーなこの機能は、大きな安心感と全体的なシステムの信頼性につながります。また、本番環境以外での機能のテストや、ロールバックまたは繰り返しのテストを非常に簡単にします。

抽象化レイヤーからのスナップショット機能はまた、「イメージベースバックアップ」、つまりオペレーティングシステムのファイルシステムレイヤーからではなくブロックデバイスレイヤーでのスナップショットメカニズムによって取得されるバックアップを取得する能力にもつながります。これにより、オペレーティングシステムに依存しないバックアップメカニズムと、システムストレージプール全体を一度にバックアップすることが可能になります。イメージバックアップにより、かつて「ベアメタルリストア」として知られていたもの、つまりシステム全体を追加の操作なしに完全に実行状態にリストアすること、が容易かつ非常に迅速に可能になります。すべてのハイパーバイザーメーカーがこの機能を含めているわけではなく、また同等のレベルで含めているわけでもないため、概念的には主要な機能ですが、この機能が存在するか、またはライセンス供与される範囲は、ケースバイケースで考慮されなければなりません（注目すべきは、HyperVはこれを完全に含み、XenServerは部分的に含み、VMware vSphereは無償ライセンスレベルではこれを含みません）。利用可能な場合、イメージベースバックアップは他のバックアップ方法論では考えられないような速度で非常に迅速な復旧を可能にします。システムを数分でリストアできます。災害から復旧まで！

仮想マシンをファイルとして扱う能力（少なくともアクティブに実行されていない場合）は、上記のバックアップの利点に関連した追加の利点を提供します。すなわち、物理ホスト間で迅速かつ容易に移行し、さらには異なるハードウェア間でも移動できる能力です。従来、ハードウェアのアップグレードや交換は、危険に満ちた複雑な移行プロセスを意味していました。現代の仮想化では、既存のハードウェアから新しいハードウェアへの移行は、安全なフォールバックオプションを持つ信頼性の高い非破壊的なプロセスになり得り、ダウンタイムが少なく、場合によってはゼロになることもあります。以前は非常にリスクが高かった珍しいタスクが、今日では些細なことになり得ます。

多くの場合、これが仮想化と抽象化メカニズムの真の利点です。日々のシステム運用を改善するためだけではなく、将来のリスクを軽減し、柔軟性とオプションを提供するためです。予測できない、または一般的な状況では単純に無視されるような未知のものへの備えです。このような計画はほとんど行われず、ITプロの苦悩として、困難で危険なアップグレードが残されますが、これらは容易に軽減できたはずです。

仮想化には、特定のシナリオにのみ適用される多くの機能があります。多くの仮想化製品は、ダウンタイムなしで実行中のワークロードをホスト間で、あるいはストレージデバイス間でさえ移動させるためのライブマイグレーションツールを含んでいます。高可用性とフォールトトレランスオプションが利用可能なことが多く、一部のワークロードをユーザーの介入なしに失敗したハードウェアから冗長ハードウェアに迅速に、あるいは透過的に復旧させることができます。これはよりニッチな利点であり、「ほぼすべてのワークロード」が仮想化されるべき理由のリストに含めるものではありませんが、仮想化が最初から使用されている限り、後でニーズが生じた場合に追加できる機能の主要な例として言及する価値はあります。そうでなければ、そのような機能を活用する前に仮想化への移行が必要になります。

仮想化製品は通常、特定のケースのみで重要な追加機能を多数備えています。それらの多くは「将来のニーズに備えて」という大きなプールに入ります。おそらく最大のものは、この記事の冒頭で述べたコンソリデーションの概念です。高可用性などの他の高度な機能と同様に、コンソリデーションは仮想化のコアバリューではありませんが、しばしばそれと混同されます。高可用性やコンソリデーションを活用するつもりのないワークロードも仮想化されるべきです。間違いなく。しかし、これらの機能は将来のオプションとして非常に価値が高く、今日使用されないシナリオでさえも、言及する価値があります。

コンソリデーションは非常に価値があり得るため、非常に多くの人々がそれを使用することを当然のように仮定するのがなぜかは容易に理解できます。インフラが整備された後にこれを利用できることは、将来のワークロードの未知のものを処理するための柔軟性の重要なポイントです。コンソリデーションが今日全く不要な場合でさえ、最小の企業においてさえも、未知の将来のある時点でそれが役立つ可能性が非常に高いです。仮想化は、システムを最大限の柔軟性に向けて準備することで、未知のものに対するヘッジを提供します。あらゆるIT決定の最も重要な側面の一つはリスクの管理と軽減です。仮想化はこれを行います。

仮想化は安定性、柔軟性、標準化、管理性、そしてベストプラクティスへの従うことについてです。今日、主要なエンタープライズ仮想化製品はすべて、少なくとも何らかの形で無料で利用可能です。いかなる購入も、もちろん価値対支出の慎重な分析を必要とします。しかし、この分野の現在の4つの主要製品ライン（Xen、KVM、HyperV、VMware vSphere）からすべて優れたエンタープライズオプションが無料で利用可能であるため、そのような分析は不要です。実装がネガティブでないことを示すだけで十分です。

意思決定を容易にするのは、名目上のケース（ゼロコスト、抽象化、カプセル化、ストレージベースの利点という、すべてのエンタープライズ仮想化が提供する最低限のもの）を考慮すると、事実上すべてのケースで小さな利点があり、測定可能なマイナス面がなく、柔軟性と将来のニーズへのヘッジの領域から非常に大きな潜在的利点があることがわかります。これにより明確な勝利となり、仮想化は無料で本質的にデメリットがないため、使用できるすべてのケース（現時点ではほぼすべてのワークロード）で使用されるべきという単純な決定につながります。コンソリデーションや高可用性などの追加の非コア機能は、仮想化の決定がすでに固まった後にのみ別々に評価されるべきです。これらの拡張機能のニーズの欠如は、いかなる意味でも、仮想化が独自のメリットに基づいて選択されるべきでないことを示唆するものではありません。

これは単に既存の業界ベストプラクティスの説明であり、すべての潜在的なワークロードを仮想化することは何年もの間ベストプラクティスとされてきました。これは新しいことでも方向性の変化でもありません。全面的な仮想化が業界のベストプラクティスとなってほぼ10年近くが経過するという事実だけでも、これがいかに実績のある受け入れられた手法であるかを示しています。常に何らかの理由で仮想化できないワークロードは存在しますが、これらは非常に少なく、その理由を明らかにするための詳細なレビューを促すべきです。

仮想化するかどうかを決定する際のアプローチは、常に仮想化を既定の結論として想定し、確固たる技術的理由がこれを不可能にする場合にのみそこから外れるべきです。仮想化に反対するほぼすべての議論は、コンソリデーション、高可用性、外部ストレージ、ライセンスコスト、その他の緩やかに関連するまたは無関係な概念が、何らかの形で仮想化に本質的なものであるという誤解の立場から来ています。それらはそうではなく、物理デプロイメントに対する仮想化の決定に含めるべきではありません。それらは別々であり、別々のオプションとして評価されるべきです。

コンソリデーションが仮想化のベースバリューを作成するための意思決定マトリックスの一部ではないため、私たちが使用するすべての理由は、1対1のデプロイメント（単一の物理デバイス上の単一の仮想マシン）と統合されたワークロード（単一の物理デバイス上の複数の仮想マシン）の両方に等しく適用されることに注目する価値があります。「小さすぎて」仮想化できないワークロードというものは存在しません。むしろその逆で、仮想化を行わない例外的なシナリオがエッジケースとして依然として存在するのは最も大きなワークロード、通常は極端なレイテンシ感度を持つもののみです。しかし、これらのケースでさえ、仮想化におけるレイテンシの改善と総ワークロード容量の向上につれて急速に消えつつあります。これらのケースは非常にまれで急速に消えつつあるため、これらのケースに言及するのもおそらく賢明でないほどです。容量のニーズに基づく例外が、特に中小企業市場では評価するほど一般的だということを示唆することになるからです。ワークロードが小さければ小さいほど、仮想化に理想的です。しかしこれは単に、単一のワークロードを持つ中小企業がベストプラクティスの例外ではなく、全面的な仮想化の最も理想的なケースであるということを強調するためであり、大企業が自ら例外を探すべきだということを示唆するものではありません。