できるからといって…

このコンセプトは仮想化に関する議論で常に目にします。これはより広く、より一般的な概念ですが、仮想化は多くのIT組織が直面している「ホットな新技術」であり、現在「できるからといって、やるべきとは限らない」という問題が最も顕著に現れている分野のようです。ITのすべてにおいて同様に、技術的な決定を全てビジネスのコンテキストに置くことが重要です。そうすることで、なぜそのような選択をするのかを理解し、人気のある展開手法や、さらに悪い場合には神話に基づいて盲目的に決定しないようにできます。

仮想化自体について言えば、私はx64コンピューティング空間で働く人々にとって、今日では特定のハードウェアニーズや遅延感応型アプリケーションなど、明確かつ明白な必要性が存在する場合にのみ仮想化なしでシステムを展開するという、デフォルトの決定であるべきだと感じています。特定のニーズがなければ、仮想化は多くのベンダーから無料で実装でき、現在および将来の環境においてさまざまなメリットを提供します。

とはいえ、今日よく見られるのは、企業がベストプラクティスとしてではなく、あらゆる認識されたIT問題への万能薬として仮想化を導入しているケースです。これは決してそうではありません。仮想化はITのツールボックスに持つべき非常に重要なツールであり、頻繁に活用されるものですが、すべての問題を解決するものではなく、他のツールと同様に適切な場面でのみ使用すべきです。

仮想化が話題になると、いくつかのことが繰り返し見られます。今日、多くの企業はビジネス上のニーズを特定したからではなく、現在のトレンドトピックであるために仮想化へと移行しており、仮想化を実装しなければ何か神秘的な機能を取り残されたり乗り遅れたりするという感覚を持っています。これは仮想化の普及を促進するという意味で一般的には良いことですが、適切なITおよびビジネスの意思決定プロセスが迂回されているという意味では悪いことです。仮想化の勢いの波に乗って、IT部門は仮想化自体を実装するだけでなく、ビジネスに適していない方法で実装しなければならないと感じることが多いのです。

仮想化に関連して、しばしば仮想化の要件として受け入れられてしまうものが4つあります。特定のビジネス環境でそれが意味をなすかどうかに関わらずです。それらはサーバー統合、ブレードサーバー、SANストレージ、そして高可用性またはライブフェイルオーバーです。

統合は仮想化のメリットとして非常に頻繁に称賛されるため、ほとんどのIT部門は他にも重要な理由があることを忘れてしまっていると思います。明らかに、統合はほぼすべての展開において大きなメリットです（もちろん状況によりますが）。既存のリソースをより良く活用するだけで、ほぼ常に達成可能です。複数の物理サーバーを稼働している会社で、限定的な統合によってある程度のコストを削減できない会社はほとんどなく、大規模な組織ではデータセンターのフットプリントが劇的に削減される事例も珍しくありません。

ただし、極端なケースでは、統合が不可能であることがわかっただけで仮想化プロジェクトを放棄する必要はありません。このようなケースは、高稼働率のシステムを持ち、先行投資的な統合投資の予算がほとんどない企業に存在します。しかしこうした職場でも、現在は1対1ベースで「その場で」システムを仮想化して今日の仮想化のメリットを享受し、ハードウェアを交換する必要が生じたとき、または将来より大規模で高性能なサーバーがよりコスト効率的になったときに統合を検討することができます。最も称賛されるメリットが現在の環境では適用されない場合でも、仮想化を除外しないことが重要です。

ブレードサーバーは仮想化環境における最良の選択肢として見られることが多いです。ブレードはより伝統的な計算ワークロードよりも標準的な仮想化環境でより良く機能するかもしれませんが、これは非常に議論の余地があり、必ずしも適用可能なデータではありません。ブレード自体にとって良いシナリオであることは、ビジネスにとって良いシナリオであることを意味しません。この方法で使用した場合にブレードが通常よりも良いパフォーマンスを発揮するからといって、従来のサーバーよりも優れたパフォーマンスを発揮することを意味するわけではありません。差を縮めた可能性があるというだけです。

ブレードは仮想化する場合でもしない場合でも同じ厳しい基準で評価される必要があり、多くの場合、より柔軟な代替案よりも選択するために必要な長期的なビジネス価値を提供できないままです。ブレードは仮想化において決して必須ではなく、私の意見では多くの場合非常に貧弱な選択です。

最も一般的な誤解の一つは、仮想化に移行することでSANのような共有ストレージにも移行しなければならないというものです。この考え方は、共有ストレージを必要としないとしても大きな恩恵を受ける仮想化の他のメリットを実現したいという欲求への明らかな反応です。システム間の負荷分散やフェイルオーバーの能力は、共有ストレージバックエンドを持つことで大きく促進されます。これが絶対要件だというのは神話ですが、レプリケートされたローカルストレージはそれ自身の複雑さと制限をもたらします。

しかし共有ストレージは仮想化自体の必需品からは程遠く、他のあらゆるものと同様に単独で評価する必要があります。仮想化がお使いの環境に適切でも、SANを必要とする機能が不要な場合は、共有ストレージなしで仮想化してください。ローカルストレージを使った仮想化が理想的な展開シナリオである場合は多くあります。真剣に検討する前にこのアプローチを退ける必要はありません。

仮想化の最後の主要な「必須」機能とされるのは、オペレーティングシステムのシステムレベルの高可用性またはインスタントフェイルオーバーです。疑いなく、システムレイヤーでの高可用性は仮想化がもたらす素晴らしいメリットです。しかし、仮想化を実装する前にこのレベルの高可用性を必要としていた企業はほとんどなく、仮想化でそれを実現するために必要なインフラとソフトウェアの価格は、正当化するには高すぎることが多いです。

高可用性システムは複雑でオーバースペックになりがちです。最も重要なシステムでさえ透過的なフェイルオーバーを必要とするビジネスシステムは非常に少なく、その要件を持つ企業はほぼ確実にすでにフェイルオーバープロセスを導入しています。仮想化を検討する際に高可用性に向かっている企業をよく見かけますが、それはベンダーが元の要件を大幅に上回る販売機会を見つけたからに過ぎません。高可用性のコストは、それに関連するダウンタイム削減による潜在的な収益損失によって正当化されることはほとんどありません。高可用性でない仮想化では、ハードウェア障害によるダウンタイムはバックアップが適切に処理されれば数分で済む場合があります。これは高可用性が、年間わずか数分の計画外ダウンタイムを排除することで追加されたシステムの複雑さによるリスクを差し引いてコストを正当化しなければならないことを意味します。最大の組織でさえ、これが大規模に正当化されることはほとんどなく、中規模の会社では全くと言っていいほど稀です。しかし今日、多くの中小企業が、マーケティング資料がそのコンセプトを促進しているというだけの理由で、数日間の停電でも最小限の財務損失しか生じない可能性があるシステムに高可用性システムを非常に高いコストで導入しています。

他のあらゆるものと同様に、仮想化とそれがもたらすすべての可能性は、それらを検討している組織のコンテキストの中で個別に評価する必要があります。個々の機能がビジネスにとって意味をなさない場合、その機能を購入または実装しなければならないとは思わないでください。多くの組織は仮想化していますが、これらの「想定された」機能のうちごく一部、または全く使用していません。仮想化をブラックボックスとして見るのではなく、各パーツを見て、他のテクノロジープロジェクトを検討するのと同じように検討してください。

よくあることは、適切なビジネスアセスメントが実施されないままに、おそらく高可用性が必要であると想定されるという雪だるま式の効果です。そして、高可用性に必要と想定されることが多いSANストレージが、また別の想定コストとして追加されます。高可用性機能が購入されなくてもSANを使用するという決定がすでになされており、計画の変更後も再検討されないことがよくあります。私の経験では、このような性質のプロジェクトで、プロジェクトの総支出の50%以上が、購入者が購入した理由さえ説明できない製品に使われているケースを見つけることが珍しくありません。

このコンセプトは仮想化だけに留まりません。あらゆることに広げてください。ITをビジネスの観点から見続け、ある技術を採用することが、一般的に関連付けられている他の技術も採用しなければならないことを自動的に意味するとは思わないでください。