「逆ピラミッド・オブ・ドゥーム」を最大限に活用する

3-2-1、すなわち「逆ピラミッド・オブ・ドゥーム」アーキテクチャは、さまざまな理由からIT業界の厄介者となっています。残念ながら多くの企業は、機器が届き、費用が口座から引き落とされた後になって初めて、この設計に伴う危険性を知ることになります。

早い段階でこのミスに気づき、購入品を返品して新しいハードウェアやソフトウェアの取得前に適切な設計・意思決定フェーズからやり直せる企業は幸運です。しかしこれは理想的であり、非常に稀なケースです。せいぜい返品手数料が発生するか、さらによくあるケースとして、機器をまったく返品できないか、手数料が非常に高額で意味をなさないことが普通です。

多くの企業が直面するのは、現状を「最大限に活用する」必要性です。最大の懸念点の一つは、新しいハードウェアに多額の投資をした財務上の利害関係者であれ、この機器の購入を許可してしまったことで面目を失った技術的な利害関係者であれ、関係者がサンクコスト（埋没費用）の誤謬に陥るという感情的な反応を示しやすいことです。この感情的・非論理的な反応が根付かないようにすることが非常に重要です。そうしなければ重要な意思決定が損なわれてしまいます。

逆ピラミッド・オブ・ドゥームに費やされたお金はすでに使われており、なくなっているということを理解しなければなりません。お金が無駄になったかどうか、どれだけ無駄になったかは、この時点での意思決定には関係ありません。そのシステムが贈り物であっても10億ドルかかったとしても関係なく、そのお金はなくなってしまい、今あるもので何とかするしかありません。ここで一つの「テクニック」は、CFOのような財務上の意思決定者を呼んで、すでに使われたお金に対して感情的な反応が生じようとしていることを説明し、実際の問題について話し合う前にサンクコストの誤謬について議論することです。そうすることで、関係者が冷静で論理的になり、この種の状況を最もうまく処理できるよう（願わくば）訓練されている人物が準備して感情的な反応を抑えられるようにします。感情的になりうる反応を慎重に処理することが重要です。これは、その感情的な反応が生み出そうとしている財務的または技術的な失策を隠蔽しようとする時ではありません。すべての関係者がコミュニケーションを取り、冷静で論理的でいることで、ニーズに対処することが必要です。これをうまく処理できる企業もありますが、多くは対処できず、すでになされた悪い決定を押し進めようとすることに陥ります。おそらく何も悪いことが起きず、誰も覚えていないか気づかないことを期待してのことでしょう。その反応に抗ってください。誰もがそれを持っています。それは自然な扁桃体の「戦うか逃げるか」という感情的な反応です。

感情的な反応と戦う準備ができたところで、「これからどこに向かうか」について取り組み始めることができます。良いニュースは、私たちが置かれている状況は一般的に「足りない」よりも「多すぎる」という立場であるということです。ですから、少し創造的になれる機会があります。幸いにも、いくつかの方向へ進むことができる良い選択肢が一般的にあります。

非常に重要な点として、私たちが検討するソリューションは、置き換えようとしている逆ピラミッド・オブ・ドゥームアーキテクチャよりも信頼性が高く、低くなることはありません。IPODは非常に脆弱で危険な設計であり、リスク分析、単一障害点、誤った冗長性の誤謬、冗長性ではなく信頼性の追求、依存関係チェーンなどの概念を実証するために多大な労力を費やすことができますが、すべての関係者が絶対的に理解しなければならないのは、ローカルストレージで動作する単一のサーバーは、IPOD インフラストラクチャ全体よりも信頼性が高いということです。これは非常に重要なので、もう一度言わなければなりません。単一のサーバーが「標準可用性」であれば、IPODはその水準を下回っています。より危険です。この段階で誰かが結果として得られるソリューションの「冗長性の欠如」や「複雑さの欠如」を恐れているなら、ここに立ち戻らなければなりません。私たちが議論することは何も、すでに設計・購入されたものほど危険ではありません。今後のリスクに恐れがあるなら、設計の信頼性を改善する前の方が、もっと恐れるべきだったはずです。これはいくら強調しても足りません。IPODが売れるのは、リスク分析の訓練を受けていない人々を容易に混乱させ、実際には全くそうではないのに信頼できるように見えるからです。

上記を理解し、受け入れられたIPODアーキテクチャを「読み返す」技術を使うと、問題の企業はIPODを購入した時点で高可用性（あるいは標準可用性さえも）を持たないことを受け入れていたということがわかります。おそらく彼らはそれを得られると信じていたでしょうが、アーキテクチャはそれを提供できず、したがって今後は単一のサーバーがそれ自身のローカルストレージで動作するだけで「何とかやっていく」という選択肢があります。これはシンプルで簡単であり、意図されたIPOD設計のほぼすべての側面を改善します。実行と維持のコストが低く、多くの場合より高速であり、わずかに信頼性が高い一方で複雑さははるかに低くなります。

しかし、単純に単一のサーバーに落とし込んで、残りの購入済み機器の用途を「他の場所」で見つけることが最善の選択肢にならない可能性が高いです。IPODが単一のワークロードまたはワークロードのセットにのみ使用することを意図されていた状況で、ビジネスの他の領域にも機器が必要な場合、意図したIPODワークロードには「シングルサーバー」アプローチを採用し、残りの機器をビジネスの他の場所で活用することが非常に有益です。

IPODスタックの転用で最も一般的なアプローチは、2つ（またはそれ以上）のコンピュートノードを独自のストレージを含むフルスタックノードとして再構成することです。このステップでは、すでに購入されているストレージに応じて、追加購入なしで済む場合もあれば、システム間でドライブを移動させる場合、またはこの目的のために比較的小さなコストで追加のハードドライブを購入する場合もあります。

これらのノードは、2つの高可用性モデルのいずれかで構成できます。過去には、コスト上の理由から、一般的な設計の選択として非同期レプリケーションモデル（しばしばVeeamアプローチとして知られる）が使用されていました。これはノード間で仮想マシンをレプリケートし、コンピュートノードの障害発生から数分以内という短いダウンタイムでVMを迅速に起動できるようにするものです。

今日では、完全同期フォールトトレランスが非常に一般的に無料で利用可能になっているため、ほぼすべてのケースで事実上非同期モデルに取って代わっています。このモデルでは、ストレージがコンピュートノード間で完全にリアルタイムでレプリケートされ、数分の遅延なく即座にフェイルオーバーが発生し、小さなデータ損失ウィンドウではなくデータ損失がゼロになります（例：RPOがゼロ）。

この時点で、レプリケーションによるストレージ容量の損失を恐れて反応することが一般的なようです。もちろんこれは事実です。元のIPOD設計に欠けていたこのレプリケーションが、高い信頼性の確固たる基盤を提供することを理解しておく必要があります。このレプリケーションをスキップすると、高可用性は達成できない夢となり、ローカルストレージを使用した個々のコンピュートノードを「スタンドアロン」モードで使用することが最も信頼できる潜在的なオプションとなります。高可用性ソリューションは、高可用性の資格を得るために必要な信頼性を構築するためにレプリケーションと冗長性に依存しています。

これはコンピュートノードをどうするかという問題を解決しますが、外部共有ストレージデバイス、つまり単一障害点または逆ピラミッド設計の「頂点」をどうするかという問題が残ります。この問題に答えるには、このストレージが何であるかを調べることから始めるべきです。

逆ピラミッド設計で使用されるストレージデバイスには3つの一般的なタイプがあります：DAS、SAN、NASです。DASとSANはどちらもブロックストレージの2つの異なる側面であり、私たちの議論では事実上互換的に使用できるため、まとめることができます。これらは、設計に応じて追加または削除できるスイッチングの存在によってのみ区別されます。NASはブロックストレージではなくファイルストレージである点で異なります。

どちらの場合も、ブロック（DASまたはSAN）またはファイル（NAS）ストレージのいずれでも、この今や余剰となったデバイスの最も一般的な使用方法の一つは、新しい仮想化インフラストラクチャのバックアップターゲットとしての利用です。多くの場合、このデバイスはこの目的には過剰スペックであり、単純なバックアップターゲットとしては一般的に必要以上のパフォーマンスと多くの機能を持っていますが、優れたバックアップストレージはあらゆる重要なビジネスインフラストラクチャにとって重要であり、過剰スペック側に倒れることは必ずしも悪いことではありません。企業はバックアップインフラストラクチャに費用を惜しむことが多く、これは追加費用なしで大きく投資できる機会です。

バックアップストレージと同様に、外部ストレージデバイスはアーカイブストレージや、高可用性が保証されない他の「下位層」のストレージとして転用できます。これはあまり一般的なアプローチではありません。一般的にすべてのビジネスが優れたバックアップシステムを必要とする一方で、アーカイブストレージ層を活用できるビジネスは一部に限られるからです。

これら2つの一般的かつ普遍的なストレージモデルを超えて、外部ストレージデバイス、特にデバイスがNASの場合、一般的なユースケースとして仮想化インフラストラクチャとは別のファイルサーバーとして本来の役割で活用することが挙げられます。多くのビジネスにとって、ファイルサービングはコアの仮想化インフラストラクチャほどアップタイムが重要ではなく、バックアップの維持と管理がはるかに容易です。すでに購入済みのNASデバイスにファイルサービングをオフロードすることで、実行する必要のあるVMの数を減らすとともに、通常最大のストレージユーザーである要素を別のデバイスに移動させることで、仮想化インフラストラクチャからのファイルサービング要件を削減できます。これにより、仮想化インフラストラクチャのパフォーマンス要件とキャパシティ要件も低下する可能性があります。このようにすることで、先ほど述べたコンピュートノードのローカルストレージ用の追加ハードドライブを入手するコストを削減できる可能性があり、多くの企業にとって転用ニーズに対処するための非常に人気のある方法となっています。

各企業は固有であり、ラボからアーカイブから階層化ストレージまで、余剰ストレージ機器を効果的に活用できる場所が潜在的に多数あります。少し創造性を発揮し、枠を超えて考えることで、手持ちの機器の独自のセットとビジネスの独自のニーズや要求を活かして、コアとなる重要な仮想化インフラストラクチャから切り離しながらも組織に価値をもたらせる最適な場所を見つけることができます。逆ピラミッド・オブ・ドゥームを回避することで、すでに投資した機器から最大の価値を得ることができ、不必要に克服しなければならない新たな技術的負債を実装することを避けられます。