最も弱いリンク：連鎖的な依存関係がシステムリスクに与える影響

システムリスクのシナリオを評価する際、「連鎖的な」依存関係を見落とすことは非常に容易です。私たちは「ノード」レベルでリスクを評価するよう訓練されており、「この一つのものが失敗する可能性はどれくらいか」と問います。しかしシステムリスクはそれよりもはるかに複雑です。

ほとんどのシステムでは、他のコンポーネントに依存するコンポーネントがいくつか存在します。これを最もよく見られる場所はサーバーのストレージ設計においてですが、あらゆるシステム設計において発生します。もう一つの良い例は、Webアプリケーションが機能するためにアプリケーションホストとデータベースホストの両方を必要とする方法です。

連鎖的な依存関係は例を使って説明するのが最も簡単です。障害ドメインの境界と連鎖的な依存関係が存在する場所、およびシステムレベルのリスク軽減において冗長性が果たす役割を理解するために、SANストレージを使用した標準的な仮想化設計を見ていきます。

仮想化のための標準的なSAN（ストレージエリアネットワーク）設計では、仮想化ホスト（簡単のため「サーバー」と呼びます）、SANスイッチ（ストレージネットワーク専用のスイッチ）、ディスクアレイ自体があります。これら三つの「レイヤー」はそれぞれ、システム全体が機能するために他に依存しています。最もシンプルなセット（サーバー1台、スイッチ1台、ディスクアレイ1台）を持つ場合、三つの異なる障害ポイントを表す三つのデバイスがあることは明らかです。三つのうちいずれか一つが失敗すると、システム全体が失敗します。どの一つのピースも単独では役に立ちません。これが連鎖的な依存関係であり、チェーンはその最も弱いリンクと同じ強さしかありません。

このシンプルな例では、各デバイスが障害ドメインを表しています。各ドメインの信頼性を向上させることでリスクを軽減できます。二番目のサーバーを追加し、仮想化レイヤーの高可用性またはフォールトトレランス戦略を実装して、サーバー障害のリスクを軽減できます。これにより一つの障害ドメインの信頼性が向上しますが、残りの二つは手つかずのままで、以前と同様にリスクがあります。次に、冗長スイッチを追加し、単一スイッチングパスの損失を処理するためのマルチパス戦略を設定することで、スイッチングレイヤーのリスクを軽減できます。これで二つの障害ドメインに対処しました。最後に、ストレージ障害ドメインに対処する必要があります。これは同様に、最初のディスクアレイにミラーリングされ、障害が発生した場合に透過的にフェイルオーバーできる二番目のディスクアレイを追加することによって行われます。

システムを強化した今でも、依存関係チェーンに三つの障害ドメインが存在します。私たちが行ったことは、チェーンの各「リンク」、各障害ドメインを、それ自体でより強靭にすることです。しかしチェーンはまだ存在します。これは、システム全体が、チェーン内の単一障害ドメインよりもはるかに信頼性が低いことを意味します。私たちは最初よりもはるかに良いものを作りましたが、それでも多くの障害ドメインがあります。これらのリスクは積み重なります。

全体的なリスクを決定することの難しさは、各アイテムのリスクを評価し、軽減後（冗長性の追加による）の新しいリスクを決定し、次にシステム全体のリスクを決定するために障害ドメインの累積リスクをチェーンでそれぞれ見つけることです。リスク軽減の方法が重要な役割を果たすため、各障害ドメイン内のリスクを決定することは非常に難しいです。例えば、フェイルオーバーが遅すぎるストレージディスクアレイのクラスターは、ストレージクラスター自体が正常に動作したように見えても、全体的なシステム障害を引き起こす可能性があります。明確な障害を定義することさえ、したがって困難な場合があります。

リスクを「上から」見る評価をするという誘惑は非常に危険ですが、定期的にリスク評価を行うプラクティショナーでない人々には非常に一般的です。ここでの傾向は、リスクを「最上位」の障害ドメインのみを見て（このような場合は一般的にサーバー）、それより下にあるリスクは「内部的なもの」として考え、リスク評価の一部ではないとしてリスクを無視することです。ネットワークやストレージなど、より技術的で、あまり目立たず、より理解されにくいコンポーネントを無視し、最上位レイヤーの比較的容易に理解できる、積極的にマーケティングされた信頼性の側面に焦点を当てることは簡単です。この「上からの見方」は、最上位レベルより下にあるリスクを不明確にし、一般的に無視されることになり、なぜそうなのかを十分に理解せずに高いリスクに至ります。

連鎖的な依存関係の概念を理解することで、複雑なリスク軽減戦略を持つ複雑なシステムでさえ、なぜしばしばよりシンプルなシステムよりもはるかに脆弱になるのかが説明できます。上記の例では、チェーンを「折りたたむ」ことで、システム全体としてより信頼性の高いシステムにするためのいくつかのことができます。

折りたたむことができる最も明白なコンポーネントはネットワーキング障害ドメインです。スイッチを完全に取り除き、ストレージをサーバーに直接接続する場合（もちろん、常に可能というわけではありません）、一つの障害ドメイン全体を効果的に排除し、チェーンからリンクを取り除きます。三つのチェーンではなく、それぞれが失敗する可能性を持つ代わりに、二つだけになります。他のすべてが等しい場合、シンプルな方が良いです。

理論的には、ストレージ障害ドメインも折りたたむことができます。外部ストレージからサーバー自体にローカルなストレージを使用することで、二つの障害ドメインから単一の障害ドメインに移行できます – もちろん、残った一つのドメインは折りたたみ前よりも多くの複雑さを持っていますが、システム全体の複雑さは大幅に削減されます。繰り返しますが、これは他のすべての要因が同じままである場合のことです。

考慮すべき別のアプローチは、単一ノードをそれ自体でより信頼性の高いものにすることです。今日、大きなシステムを見て、低コストの冗長ノードを追加することで障害ドメインに信頼性を加えるリスク軽減に向けてアプローチすることがトレンドになっています。しかし、従来これはデフォルトで信頼性への経路として取られたものではありませんでした。過去には、メインフレームや同様のクラスのシステムの以前の普及率に示されているように、単一ノードに高度な信頼性を組み込むことがはるかに一般的でした。メインフレームと高性能ストレージシステムは、例えば今日でもこれを行っています。これは実際には非常に効果的なアプローチになり得ますが、多くのシナリオに対処できず、一般的に非常にコストがかかります。多くの場合、システムをベンダーが部分的または完全に保守する必要があることによって増幅されます。これは特別なニッチな状況でのみうまくいく傾向があり、より一般的な範囲では実用的ではありません。

したがって、この性質のシステムでは、考慮すべき三つの主要なリスク軽減戦略があります：単一ノードの信頼性を向上させること、単一ドメインの信頼性を向上させること、または依存関係チェーン内の障害ドメイン（リンク）の数を減らすことです。これらを賢明に組み合わせることで、ビジネスシナリオに適したリスク軽減レベルを達成するのに役立てることができます。

真の難しさが存在し続ける場所は、異なるリスク軽減戦略の比較にあります。単一ノードのリスクは、ある程度の自信を持って推定できることが一般的です。単一ドメイン内の冗長性戦略は、推定する能力がはるかに低いです – 一部の冗長性戦略は非常に効果的で、非常に信頼性の高い障害ドメインを作り出しますが、他の戦略は実際に逆効果になってドメインの信頼性を低下させることがあります！冗長性戦略に伴う複雑さは常に注意が必要であり、通常は成果を上げますが、最初に期待する信頼性のメリットの程度を持つことはほとんどありません。したがって、依存関係チェーンのリスクを推定することはさらに難しく、各障害ドメインに関連するリスクを個別に明確に理解すること、およびドメインの境界に存在する障害機会（例えば、前述のストレージフェイルオーバーの遅延による障害）を理解することが必要です。

上記で議論したことを基に、同じシナリオに対する二つの非常に一般的なアプローチのリスクを決定する際の問題を探求しましょう。

同じ状況の二つの極端な例は、仮想マシンをホストするために内部ストレージを持つ単一サーバーと、サーバーレイヤーでの高可用性ソリューションを使用する二台のサーバー、スイッチングレイヤーで冗長性を持つ二台のスイッチ、およびストレージレイヤーで高可用性を提供する二台のディスクアレイによる六デバイスの「チェーン」です。ここで大きな要因を切り替えると、一般的にリスクの相対的な推定を比較的明確に提供できます – 例えば、いずれかの障害ドメインが信頼できる冗長性を欠く場合、単一サーバーがより信頼性の高い全体システムであることを非常に明確に判断できます（単一ノードに非常に大きな信頼性が割り当てられる場合を除きますが、これは一般的に財務的に非実用的な戦略です）。しかし、各障害ドメインが冗長性を維持している場合、ドメイン内の信頼性（冗長チェーン）とドメイン間の信頼性（折りたたまれたチェーン、単一サーバー）の相対的なリスクを比較することを余儀なくされます。

二つのまったく異なるアプローチでは、二つのリスク軽減手段の比較リスクを評価する合理的な方法はありません。障害ドメイン内のリスク軽減を広範に伴う六（またはそれ以上）ノードのアプローチは、二つのアプローチのうちより信頼性が高いとして一般的に受け入れられており、これはほぼ確実に、一般的に真実です。しかし、常にそうとは限らず、このアプローチが単一ノード戦略を真に大幅なマージンでアウトパフォームすることはほとんどなく、一方で単一サーバー戦略の4倍から10倍のコストがかかることが一般的です。これは、信頼性のわずかな向上と信頼性の低下のリスクのわずかな可能性に対して、潜在的に非常に高いコストです。冗長性の各追加は、人間が実装、監視、保守しなければならない複雑さを加え、複雑さと人間の相互作用により、リスクはどんどん増加します。人為的ミスを避けることは、機械的な故障を避けることよりも重要なことがよくあります。

また、リカバリーのコストも考慮する必要があります。障害が発生した場合、シンプルなシステムの障害からの回復は一般的に些細なことです。非常に複雑なシステムが障害を起こした場合、動作する状態に戻すために多大な努力が必要になる場合があります。複雑なシステムはまた、維持するためにより広く深い経験と自信が必要です。

システムの信頼性を決定することに簡単な答えはありません。現代の情報デリバリーシステムは、すべてのケースで評価できるような判断できない要因が多すぎるため、単純にあまりにも大きくて複雑です。しかし、連鎖的な依存関係を十分に理解し、リスク軽減戦略を理解することで、おおよそ相対的なリスクレベルを決定するための実践的な措置を取ること、類似したリスクシナリオのコスト比較を確認すること、脆弱性のポイントを特定すること、障害ドメインと依存関係チェーンを認識すること、そしてシステム設計の変更が信頼性に向けて私たちを明確に近づけるか遠ざけるかを評価することができます。