# 依存関係のある可用性
<a name="availability-with-dependencies"></a>

 前のセクションでは、ハードウェア、ソフトウェア、その他の分散システムはすべてワークロードのコンポーネントであると述べました。これらのコンポーネントを*依存関係*と呼びます。これは、ワークロードがその機能を提供するために依存するものです。*ハード*な依存関係とは、それなしではワークロードが機能しないものですが、*ソフト*な依存関係は、利用できないことに気付かれなかったり、一定期間許容されることがあります。ハードな依存関係は、ワークロードの可用性に直接影響します。

 そのため、ワークロードの理論上の最大可用性を計算してみることをお勧めします。これは、ソフトウェア自体を含むすべての依存関係の可用性の積です (*α**n* は 1 つのサブシステムの可用性)。というのは、各依存関係は動作可能でなければならないからです。

![\[方程式の図。A = α1 X α2 X ... X αnsubscript>\]](http://docs.aws.amazon.com/ja_jp/whitepapers/latest/availability-and-beyond-improving-resilience/images/equation4.png)


 これらの計算に使用される可用性の数値は、通常 SLA やサービスレベル目標 (SLO) などに関連付けられています。SLA は、顧客が受けると予想されるサービスのレベル、サービスを測定するためのメトリクス、およびサービスレベルが達成されなかった場合の是正措置またペナルティ (通常は金額) を定義します。

 上記の式を使うと、純粋に数学的に見れば、ワークロードは、その依存関係以の可用性は達成できないと結論づけることができます。しかし実際に一般的に見られるのは、そうではないということです。99.99% の可用性の SLA で 2 つまたは 3 つの依存関係を使用して構築されたワークロードでも、それ自体でも 99.99% 以上の可用性を達成できます。

 これは、前のセクションで概説したように、これらの可用性の数値が推定値であるためです。これらは、障害がどのくらいの頻度で発生し、どれだけ早く修復できるかを推定または予測します。ダウンタイムを保証するものではありません。依存関係は、定められた可用性 SLA または SLO を頻繁に超過します。

 また、依存関係は、パブリック SLA で定められている数値よりも、パフォーマンスを目標とする内部可用性目標が高い場合もあります。これにより、不明または不明の可能性がある事態が発生した場合に、SLA を満たすリスクをある程度軽減できます。

 最後に、ワークロードには、SLA が不明であったり、SLA や SLO が提供されていない依存関係がある可能性があります。例えば、世界中のインターネットルーティングは、多くのワークロードにとって共通の依存関係となっていますが、グローバルトラフィックがどのインターネットサービスプロバイダーを使用しているか、SLA があるかどうか、プロバイダー間での一貫性のレベルについて知ることは困難です。

 つまりこれらすべてが示唆するのは、理論上の最大可用性を計算しても、概算しか行われない可能性が高く、それだけでは正確ではなく、意味のある洞察も得られないということです。この計算からわかるのは、ワークロードが依存する要素が少ないほど、障害が発生する可能性が全体的に低くなるということです。1 未満の数の乗算が少なければ少ないほど、結果の値は大きくなります。

**ルール 3**  
 依存関係を減らすと、可用性にプラスの影響を与えることができます。

 この計算は、依存関係の選択プロセスの参考にもなります。選択プロセスは、ワークロードの設計方法、依存関係の冗長性を活用して可用性を向上させる方法、およびそれらの依存関係をソフトと見なすかハードと見なすかに影響します。ワークロードに影響を与える可能性のある依存関係は慎重に選択する必要があります。次のルールでは、その方法について説明します。

**ルール 4**  
 一般的には、可用性の目標がワークロードの目標と同等以上の依存関係を選択します。