仮想の卵とバスケット

中小企業のITプロフェッショナルと話していると、仮想化のデプロイへの躊躇の重要な要因の一つとして、「卵を一つのバスケットに入れるな」という表現が挙げられます。

この懸念がどこから生じるかは理解できます。仮想化により、多くのゲストオペレーティングシステムが単一の物理システムに収容できるようになり、ハードウェア障害が発生した場合には、そこに存在するすべてのゲストシステムが同時に一斉に障害を起こします。これは悪いことのように聞こえますが、最初に想定するほど悪くないかもしれません。

卵とバスケットの慣用句の考え方は、すべてのリソースを同時にリスクにさらすべきではないというものです。これは一般的に投資に適用され、投資家に分散投資を奨励し、債券、株式、ファンド、商品など多くの異なる会社や種類の証券に投資することを勧めます。卵（またはお金）の場合、私たちは交換可能な商品について話しています。卵は一つとして同じものがありません。卵の集合は本来的に冗長です。

12個の卵があって6個割れても、オムレツを作ることができます。小さいかもしれませんが、まだ食べられます。小さなオムレツを食べることは大きなオムレツとほぼ同じくらい満足のいくものであり、いずれの場合もお腹をすかせることはありません。すでに冗長な卵を複数のバスケットに入れることで、リスクをヘッジできます。確かに、2つのバスケットを持つことはどちらか一方に注意を払う時間が少なくなり、一部の卵を失うリスクは増しますが、すべての卵を失う可能性は低くなります。卵の場合、確かに賢明な提案です。同様に、老後の準備としても賢明な方法です。

この理論は、注意深い分析や適切な理解なしに慣用句として繰り返されるため、サーバーの仮想化など無関係な分野にも適用されます。しかし、サーバーは卵とは違います。サーバー、特に中小企業では、12台の代わりに6台が稼働していれば十分という交換可能な商品であることはまれです。通常、サーバーはそれぞれ独自の役割を果たしており、すべてがビジネスの機能にとって比較的重要です。サーバーが重要でなければ、それを取得し維持するコストを正当化できる可能性は低く、おそらく存在しないでしょう。サーバーが大規模なステートレスWebファームやコンピュータークラスターのように交換可能な場合は、単一の物理ボックスの制約を超えて容量を拡張する手段として構成されており、この議論の範囲外になります。

ビジネスにおけるITサービスは通常、少なくともある程度は「チェーン依存」です。つまり、相互依存しており、単一のサービスの喪失が他のサービスに影響を与える可能性があります。これは技術的に相互依存している場合（基幹業務アプリケーションがデータベースに依存しているなど）や、ワークフローが相互依存している場合（オフィスワーカーが、電話やインスタントメッセージで変更について話し合いながら、メールからの情報でファイルサーバーから編集が必要なファイルを入手する必要があるなど）があります。このような場合、メール、ネットワーク認証、ファイルサービスなどの単一の重要なサービスの喪失は、業務能力の不釣り合いな損失をもたらす可能性があります。10の主要サービスがあって1つが停止した場合、ITサービスの観点からの企業の生産性は10%をはるかに超えて低下する可能性があり、極端なケースでは100%近くになることもあります。これは常に真実ではなく、ワーカーが失われたサービスを効果的に「回避」できる特定のユニークなケースもありますが、これは非常にまれです。たとえ人々が働き続けられるとしても、通常よりもはるかに生産性が低下している可能性があります。

物理サーバーを扱う場合、各サーバーはそれ自体の障害点を表します。つまり、10台のサーバーがあれば、同じサーバーが1台の場合と比べて10倍の障害の可能性があります。追加するサーバーごとに固有のリスクがもたらされます。各障害のアウテージ係数が2.5（1日間、収益の25%に相当するビジネスへの財務的影響）である場合、10年間の総平均影響は2.5回の完全なサイトアウテージに相当します。ここでは係数と平均の概念を使用して簡単にしています。平均アウテージの長さや平均アウテージの影響を決定する必要はなく、この場合は比較シナリオの相対的な影響だけを決定する必要があります。これは特定の数値を必要とせずに、あるイベントタイプと別のイベントタイプの累積アウテージの財務的影響を比較する手段です。支出額を決定するのに役立つものではなく、相対的な信頼性だけを示します。

仮想化により、明らかな統合能力が生まれます。この例では、既存の10台のサーバーすべてを単一のサーバーに統合できると仮定します。これを行うと、しばしば「すべての卵を一つのバスケットに」という反応を引き起こします。しかし、リスク分析を行うと、これは通常、数学的に裏付けられたリスクではなく、単なる恐れと不確実性であることがわかります。上記の例と同じリスクを仮定すると、単一サーバーは10年間で平均1回の完全なサイトアウテージのみが発生します。

これを2.5回の完全なサイトアウテージに相当するダメージを与えた最初の例と比較すると、仮想化された統合ソリューションのリスクは従来のソリューションのわずか40%に過ぎません。

これは、一部のサービスを失うことは、失われた個々のサービスの厳密な価値以上の財務的損失をもたらすという仮定に基づいていることに注意してください。これはほぼ常に当てはまります。たとえサービスの喪失が個々のサービスの喪失以上でなくとも、少なくとも損益分岐点に立ち、心配する必要はありません。まれなケースでは、単一システムを失った場合の影響が「パイのスライス」未満になることがあります。これは通常、人々が柔軟で障害を起こしたシステムを回避できるためです。例えば、インスタントメッセージングが障害を起こし、インスタントメッセージングが復旧するまで人々が単純にメールへ切り替えるような場合ですが、これらのケースはまれであり、通常は多くのシステムの中のいくつかのシステムに限定されます。ERP、CRM、メールなどの大多数のシステムは、障害発生時に不釣り合いに大きな影響をもたらします。

つまり、通常の状況では、10台のサーバーから1台のサーバーに10のサービスを移行すると、一般的にリスクが増加するのではなく低下します。これは「卵とバスケット」理論に直接反します。そして、これは純粋にハードウェア障害の観点からです。しかし、統合は他にもいくつかの重要な信頼性要因を提供しており、私たちのケーススタディに大きな影響を与えることができます。

統合により、IT部門が監視・管理する必要のあるハードウェアの量が削減されます。サーバーが少なくなれば、残りのサーバーに対してより多くの時間と注意を払うことができます。より多くの注意は、問題を早期に発見し、部品を手元に置いておく機会を高めることを意味します。より良い監視とメンテナンスは、より良い信頼性につながります。

しかし、おそらく最も重要な要因は、統合による大幅なコスト削減であり、これを正しくアプローチすれば、信頼性向上の機会を提供することができます。サーバーの総コストが劇的に減少することで、引き続き予算を厳しく保ち、コスト削減を直接活用しようとする誘惑があります。これは理解できますし、一部のビジネスにとってはこれが正しいアプローチかもしれません。しかし、卵とバスケットの概念と闘っているときには、私が推奨するアプローチではありません。

代わりに、大幅なコスト削減を維持しつつも、単一サーバーに相対的により多く支出するという、より穏健なアプローチを適用することで、より高品質（つまりより信頼性の高い）のサーバーを購入し、より良い部品を使用し、現場にスペアを持ち、などが可能になります。仮想化のコスト削減は、しばしば信頼性の向上に直接転換でき、方程式をさらに単一サーバーアプローチに有利に傾けます。

別の記事で述べたように、一軒のレンガの家は、一軒または二軒の藁の家よりも嵐に耐える可能性が高いです。何かを多く持つことが、必ずしもより信頼性の高い選択肢になるわけではありません。

これらの利点は純粋に仮想化の統合側面から来るものであり、仮想化自体からではありません。仮想化はリスク軽減機能を別途提供します。システムイメージングと迅速なリストア、および異なるハードウェアへのリストアは、ほぼすべての仮想化プラットフォームの主要な利点です。これはディザスタリカバリ戦略において重要な役割を果たすことができます。

もちろん、これらのコンセプトはすべて、単一ボックスの仮想化と統合が従来の「1アプリケーション1サーバー」アプローチに勝てること、そしてまだお金を節約できることを示すためだけのものです。卵とバスケットの例が誤解を招き、このシナリオには適用されないことを示しています。これらの要因に基づいて、従来の環境から仮想化環境へ移行することへの躊躇はほとんどないはずです。

仮想化はその後、従来のコモディティハードウェアの信頼性を拡張し、非仮想化プラットフォームが提供できる以上の、メインフレームに似たフェイルオーバー機能を提供できることに注意してください。これにより、コモディティハードウェアがより大きな高価なRISCプラットフォームとより確固たる一線を画すことができます。これらの機能は極めて高い水準の保護をもたらすことができますが、従来のフェイルオーバーなし・レガシーハードウェアサーバー環境から最初に移行するITショップには過剰なことが多いです。高可用性は優れた機能ですが、コストがかかり、特に企業が過去の比較的不安定な環境から今日のより信頼性の高い環境へ移行しているときには、往々にして不必要です。信頼性が過去に必要と考えられていたものよりすでに向上していることを考えると、信頼性の極端な向上が今すぐ必要な可能性は非常に低いですが、高可用性のコストが大幅に下がったことで、以前はコスト正当化できなかった場合でも、コスト正当化できる可能性が十分あります。

同様に、仮想化は新しく未実証の技術と見なされるため恐れられることがよくあります。これは確かに誤りですが、中小企業およびコモディティサーバー空間でそのような印象があります。実際には、仮想化は1960年代にIBMによって最初に導入され、それ以来、最高の信頼性を求めるシステムであるハイエンドのメインフレームおよびRISCサーバーの主流であり続けています。コモディティサーバー空間では、仮想化はより大きな技術的課題であり、現実世界で効果的に使用できるほど効率的に実装されるまでには非常に長い時間がかかりました。しかし、コモディティサーバー空間でも仮想化は1990年代後半から利用可能であり、今日では約15年の歴史があり、nascent（新興）な技術の段階をはるかに超えています。IT業界ではまさに由緒ある技術と言えます。コモディティプラットフォームの仮想化は成熟した分野であり、複数の高く評価された非常に高度なベンダーと製品があります。すべてまたはほぼすべてのサーバーアプリケーションの標準として仮想化を使用することは、長年確立され受け入れられた「エンタープライズパターン」であり、あらゆる規模のすべての企業が容易に採用できるものになっています。

仮想化は、おそらく直感に反しますが、信頼性戦略の非常に重要なコンポーネントです。リスクを追加するのではなく、仮想化は多くの手段を通じてコンピューティングプラットフォームの信頼性を高めるためのリスク軽減プラットフォームとしてほぼ捉えることができます。