# 冗長性を実装した可用性 ワークロードが複数の独立した冗長サブシステムを利用する場合、単一のサブシステムを使用する場合よりも高いレベルの理論上の可用性を実現できます。例えば、2 つの同一のサブシステムで構成されるワークロードについて考えてみましょう。サブシステム 1 またはサブシステム 2 のいずれかが動作していれば、完全に動作可能です。システム全体がダウンするには、両方のサブシステムが同時にダウンしている必要があります。 1 つのサブシステムの故障率が 1 − *α* の場合、2 つの冗長サブシステムが同時に停止する確率は、各サブシステムの故障率の積であり、*F* = (1− *α*1) × (1− *α*2) です。2 つの冗長サブシステムがあるワークロードの場合、式 *(3)* を使用すると、可用性は次のように定義されます。 ![\[3 つの方程式の画像\]](http://docs.aws.amazon.com/ja_jp/whitepapers/latest/availability-and-beyond-improving-resilience/images/equation5.png) したがって、可用性が 99% の 2 つのサブシステムの場合、一方のサブシステムが故障する確率は 1% で、両方に障害が発生する確率は (1− 99%) × (1− 99%) = 0.01% です。これにより、2 つの冗長サブシステムを使用した場合の可用性が 99.99% になります。 これを一般化して、追加の冗長スペア *s*** を組み込むこともできます。式 *(5)* では、1  つのスペアのみを想定していますが、複数のサブシステムが同時に消失した場合でも、可用性に影響を与えないように、1 つのワークロードに 2 つ、3 つ、またはそれ以上のスペアがある場合もあります。ワークロードに 3 つのサブシステムがあり、2 つがスペアである場合、3 つのサブシステムすべてが同時に障害を起こす確率は (1−*α*) × (1−*α*) × (1−*α*) または (1− *α*) 3 です。一般に、*s* 個のスペアがあるワークロードは、*s* \$1 1 個のサブシステムに障害が発生した場合にのみエラーとなります。 *n* 個のサブシステムと *s* 個のスペアがあるワークロードの場合、*f* は障害モードの数、つまり *n* 個のうち *s* \$1 1 個のサブシステムで障害が発生する回数です。 これは事実上、二項定理、つまり *n* の集合から *k* 個の要素を選択する、つまり *「**n* が *k* *を選択**」* する組み合わせ論です。この場合、*k* は *s* \$1 1 です。 ![\[4 つの方程式の画像\]](http://docs.aws.amazon.com/ja_jp/whitepapers/latest/availability-and-beyond-improving-resilience/images/equation6.png) 次に、障害モードの数とスペアリングを組み込んだ一般的な可用性の近似値を生成できます。(これが概算である理由については、付録 2 のHighleymanらの「[Breaking the Availability Barrier](https://www.amazon.com/Breaking-Availability-Barrier-Survivable-Enterprise/dp/1410792331)」を参照してください)。 ![\[4 つの方程式の画像\]](http://docs.aws.amazon.com/ja_jp/whitepapers/latest/availability-and-beyond-improving-resilience/images/equation7.png) スペアリングは、独立して障害が発生するリソースを提供するあらゆる依存関係に適用できます。例えば、さまざまな AZ の Amazon EC2 インスタンス、またはさまざまな AWS リージョン のAmazon S3 バケットなどがあります。スペアを使用すると、その依存関係によって全体的な可用性が向上し、ワークロードの可用性目標を支援できるようになります。 **ルール 5** スペアリングを使用すると、ワークロード内の依存関係の可用性が向上します。 ただし、スペアリングにはコストがかかります。スペアを追加するたびに元のモジュールと同じコストがかかるため、コストは少なくとも直線的に増加します。また、スペアを使用できるワークロードを構築すると、その複雑さも増します。依存関係の障害を特定し、その障害を原因とする作業を健全なリソースに振り分け、ワークロードの全体的なキャパシティを管理する方法について理解している必要があります。 冗長性は、最適化の問題です。スペアの数が少なすぎると、必要以上に頻繁にワークロードに障害が発生する可能性があります。また、スペアが多すぎると、ワークロードの実行コストが増加しすぎます。保証される追加の可用性よりもスペアの追加コストがかかるというしきい値が存在します。 スペアの場合の一般的な可用性の式、式 *(7)* を使用すると、可用性が 99.5% のサブシステムで、スペアが 2 台ある場合、ワークロードの可用性は *A* ≈1 − (1) (1−.995) 3 = 99.9999875% (年間約 3.94 秒のダウンタイム) となり、スペアが 10 台の場合、*A* ≈ 1 − (1)(1−.995)11 = 25.5  9′*s* (おおよそのダウンタイムは、1 年あたり 1.26252 × 10 −15*m**s* となり、実質的には 0 秒になります)。これら 2 つのワークロードを比較すると、スペアにかかるコストが 5 倍に増加し、ダウンタイムが 1 年で 4 秒短縮されました。ほとんどのワークロードでは、この程度の可用性の向上で、このコストの増加は正当化されません。次の図は、この関係を示しています。 ![\[スペアリングを増やすことで減少するリターンを示す図\]](http://docs.aws.amazon.com/ja_jp/whitepapers/latest/availability-and-beyond-improving-resilience/images/effect-of-sparing.png) スペアが 3 台以上になると、1 年間に予想されるダウンタイムがわずか 1 秒未満になります。つまり、この時点以降は、収益が減少する領域に到達することになります。より高いレベルの可用性を実現するために「もっと追加したい」という衝動に駆られるかもしれませんが、実際には、コスト面でのメリットはすぐに消失します。サブシステム自体の可用性が 99% 以上であれば、スペアを 3 台以上使用しても実質的なメリットは得られません。 **ルール 6** スペアリングのコスト効率には上限があります。必要な可用性を実現するには、必要最小限のスペアのみを使用します。 正しい数のスペアを選択するには、障害の単位について考慮する必要があります。例えば、ピークキャパシティを処理するために 10 の EC2 インスタンスが必要で、それらが 1 つの AZ にデプロイされているワークロードについて検討します。 AZ は障害隔離境界として設計されているため、障害の単位は 1 つの EC2 インスタンスだけではありません。AZ 全体に相当する EC2 インスタンスが同時に障害を起こす可能性があるためです。この場合は、[別の AZ に冗長性を追加して](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/use-fault-isolation-to-protect-your-workload.html)、AZ に障害が発生した場合の負荷を処理する EC2 インスタンスを 10 個追加し、合計 20 個の EC2 インスタンスをデプロイします (静的安定性のパターンに従います)。 これはスペア EC2 インスタンスが 10 個あるように見えますが、実際にはスペア AZ が 1 つしかないため、収益が減少するポイントを超えていません。ただし、3 つの AZ を利用し、AZ ごとに 5 つの EC2 インスタンスをデプロイすると、可用性を高めると同時に、コスト効率をさらに高めることができます。 これにより、1 つのスペア AZ で合計 15 個の EC2 インスタンス (2 つの AZ で 20 個のインスタンスではなく) を提供し、1 つの AZ に影響するイベントが発生した場合にピークキャパシティに対応するために必要な合計 10 個のインスタンスを引き続き確保できます。そのため、ワークロード (インスタンス、セル、AZ、リージョン) が使用するすべての障害隔離境界で耐障害性を確保できるよう、スペアリングを組み込む必要があります。