# 可用性について
可用性は、回復力を定量的に測定する主要な方法の 1 つです。可用性 *A* は、ワークロードが使用可能な時間の割合として定義されます。これは、測定対象の合計時間 (予想される「稼働時間」に予想される「ダウンタイム」を加えたもの) に対する予想される (利用可能な)「稼働時間」の比率です。
![\[方程式の図。A = 稼働時間 / (稼働時間 + ダウンタイム)\]](http://docs.aws.amazon.com/ja_jp/whitepapers/latest/availability-and-beyond-improving-resilience/images/availability.png)
この公式についてより詳しく理解するために、稼働時間とダウンタイムを測定する方法について説明します。まず知りたいのは、ワークロードがどのくらいの時間障害なく継続するかです。*これを平均故障間隔* (MTBF) と呼びます。これは、ワークロードが通常動作を開始してから次の障害が発生するまでの平均時間です。次に、障害が発生してから回復するまでにどれくらいの時間がかかるかを求めます。
*これを平均修理 (または回復) 時間* (MTTR) と呼びます。これは、障害が発生したサブシステムが修復されるか、またはサービスに戻る間、ワークロードが使用できない期間です。MTTR の重要な期間は、*平均検出時間* (MTTD) です。MTTD は、障害が発生してから修理作業が開始されるまでの時間です。次の図は、これらすべてのメトリクスがどのように関連しているかを示しています。
![\[MTTD、MTTR、MTBF の関係を示す図\]](http://docs.aws.amazon.com/ja_jp/whitepapers/latest/availability-and-beyond-improving-resilience/images/availability-metrics.png)
したがって、可用性 *A* は MTBF (ワークロードが稼働している時間)、MTTR (ワークロードがダウンしている時間) で表すことができます。
![\[方程式の図。A = MTBF / (MTBF + MTTR)\]](http://docs.aws.amazon.com/ja_jp/whitepapers/latest/availability-and-beyond-improving-resilience/images/equation2.png)
また、ワークロードが「ダウン」している (つまり使用できない) 確率は、障害の確率 *F* です。
![\[方程式の図。F = 1 - A\]](http://docs.aws.amazon.com/ja_jp/whitepapers/latest/availability-and-beyond-improving-resilience/images/equation3.png)
[信頼性](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/reliability.html)とは、指定された応答時間内において、要求されたときに適切な処理を実行できるワークロードの能力です。これが可用性の測定することです。ワークロードに障害が発生する頻度を減らす (MTBF が長い) か、修復時間が短くする (MTTR が短い) と、可用性が向上します。
**ルール 1**
分散システムの可用性を向上させる要素は、障害の頻度が少ない (MTBF が長い)、障害検出時間が短い (MTTD が短い)、修理時間が短い (MTTR が短い) という 3 つです。
**Topics**
+ [分散システムの可用性](distributed-system-availability.md)
+ [依存関係のある可用性](availability-with-dependencies.md)
+ [冗長性を実装した可用性](availability-with-redundancy.md)
+ [CAP の定理](cap-theorem.md)
+ [耐障害性と障害隔離](fault-tolerance-and-fault-isolation.md)
# 分散システムの可用性
分散システムは、ソフトウェアコンポーネントとハードウェアコンポーネントの両方で構成されています。一部のソフトウェアコンポーネントは、それ自体が別の分散システムである可能性があります。基盤となるハードウェアコンポーネントとソフトウェアコンポーネントの両方の可能性は、結果として得られるワークロードの可用性に影響します。
MTBF と MTTR を使った可用性の計算は、ハードウェアシステムが基礎になっています。ただし、分散システムの障害の原因は、ハードウェアの一部で発生する障害の原因とは大きく異なります。メーカーがハードウェアコンポーネントが摩耗するまでの平均時間を一貫して計算できる場合、同じテストを分散システムのソフトウェアコンポーネントに適用することはできません。通常、ハードウェアは障害率の「バスタブ」曲線を描き、ソフトウェアは新しいリリースごとに追加される不具合によって時差曲線を描きます (「[ソフトウェアの信頼性](https://users.ece.cmu.edu/~koopman/des_s99/sw_reliability)」を参照)。
![\[ハードウェアとソフトウェアの障害率を示す図\]](http://docs.aws.amazon.com/ja_jp/whitepapers/latest/availability-and-beyond-improving-resilience/images/failure-rates.png)
さらに、分散システムのソフトウェアは通常、ハードウェアよりも指数関数的に高い速度で変化します。例えば、標準的な磁気ハードドライブの年間平均故障率 (AFR) は 0.93% で、実際には HDD の場合、摩耗期に達するまでに少なくとも 3 ～ 5 年の寿命があり、それよりも長い可能性があります ([2020 年 Backblaze社のハードドライブのデータと統計](https://www.backblaze.com/b2/hard-drive-test-data.html)を参照)。ハードドライブはその存続期間中に実質的に変化しません。一方、例えば Amazon は 3 ～ 5 年の間に、ソフトウェアシステムに 4 億 5,000 万から 7 億 5,000 万を超える変更を加える可能性があります。([Amazon Builders' Library — 安全で手間のかからないデプロイの自動化](https://aws.amazon.com/about-aws/whats-new/2020/06/new-abl-article-automating-safe-hands-off-deployments/)を参照)。
ハードウェアには「計画的陳腐化」という概念もあります。つまり、ハードウェアには寿命が組み込まれているため、一定期間が経過すると交換する必要があります。(「[Great Lightbulb Conspiracy](https://spectrum.ieee.org/tech-history/dawn-of-electronics/the-great-lightbulb-conspiracy)」を参照)。ソフトウェアは、理論的にこの制約は適用されず、摩耗期間もなく、無期限に運用できます。
つまり、MTBF や MTTR の数値を取得するためにハードウェアで使用されるテストモデルや予測モデルは、ソフトウェアには適用されないということです。1970 年代以降、この問題を解決するためのモデル構築が何百回も試みられてきましたが、それらはすべて、一般的に予測モデリングと推定モデリングの 2 つのカテゴリに分類されます。([ソフトウェア信頼性モデルのリスト](https://en.wikipedia.org/wiki/List_of_software_reliability_models)を参照)。
したがって、分散システムの前向きな MTBF と MTTR の計算、つまり前向きな可用性の計算は、必ず何らかの予測または予測から導き出されます。これらは予測モデリング、確率的シミュレーション、履歴分析、または厳密なテストによって生成される場合がありますが、これらの計算によって稼働時間やダウンタイムが保証されるわけではありません。
過去に分散システムに障害が発生した理由は 2 度と発生しない可能性があります。将来的に発生する障害の理由は異なる可能性が高く、おそらくは不明です。また、将来の障害に備えて必要な回復メカニズムは、過去に使用されていたものとは異なり、かかる時間も大きく異なる場合があります。
また、MTBF と MTTR は平均値です。平均値と実際に表示される値には多少の差異があります (標準偏差 σ はこの変動を測定します)。したがって、実際の運用環境では、ワークロードの障害から回復までの時間が短くなったり長くなる可能性があります。
とは言え、分散システムを構成するソフトウェアコンポーネントの可用性は依然として重要です。ソフトウェアはさまざまな理由で障害を起こす可能性があり (次のセクションで詳しく説明します)、ワークロードの可用性に影響を与えます。したがって、可用性の高い分散システムでは、ハードウェアおよび外部ソフトウェアサブシステムと同様に、ソフトウェアコンポーネントの可用性の計算、測定、および向上に重点を置く必要があります。
**ルール 2**
ワークロード内のソフトウェアの可用性は、ワークロード全体の可用性にとって重要な要素であり、他のコンポーネントと同様に重視する必要があります。
MTBF と MTTR は分散システムでは予測が難しいものの、それでも可用性を向上させるための重要な分析情報が得られることに注意する必要があります。障害の頻度を減らす (MTBF を高くする) ことと、障害発生後の回復までの時間を短くする (MTTR を短くする) ことの両方が、経験的な可用性の向上につながります。
## 分散システムにおける障害の種類
分散システムで一般的に可用性に影響するバグには、*ボーアバグ*と*ハイゼンバグ* ([「A Conversation with Bruce Lindsay」ACM Queue vol. 2、no. 8 – November 2004](http://queue.acm.org/detail.cfm?id=1036486) 参照) の 2 つのクラスがあります。
ボーアバグは、繰り返し発生するソフトウェアの問題です。同じ入力が与えられると、バグは常に同じ誤った出力を生成します (決定論的なボーアの原子模型のように、確実かつ簡単に検出できます)。この種のバグが発生するのは、ワークロードが本番環境に移行する頃までは稀です。
ハイゼンバグは一時的なバグです。つまり、特定の稀な状況でのみ発生するバグです。これらの条件は通常、ハードウェア (例えば、一時的なデバイス障害やレジスタサイズなどのハードウェア実装の仕様)、コンパイラの最適化と言語の実装、制限条件 (例えば、一時的にストレージが不足している)、競合条件 (例えば、マルチスレッドオペレーションにセマフォを使用しない) などに関連しています。
ハイゼンバグは本番環境のバグの大部分を占めており、見つけにくく、観察やデバッグを試みると動作が変わったり、消失するように見えるため、見つけるのが困難です。ただし、プログラムを再起動すると、動作環境が若干異なり、ハイゼンバグの原因となった状況が解消されるため、失敗した動作が成功する可能性があります。
したがって、本番環境でのほとんどの障害は一時的なものであり、動作を再試行しても再び障害が発生する可能性はほとんどありません。回復力を高めるには、分散システムがハイゼンバグに対する耐障害性を備えている必要があります。これを実現する方法については、「[分散システムの MTBF の増加](increasing-mtbf.md#increasing-mtbf.title)」のセクションで説明します。
# 依存関係のある可用性
前のセクションでは、ハードウェア、ソフトウェア、その他の分散システムはすべてワークロードのコンポーネントであると述べました。これらのコンポーネントを*依存関係*と呼びます。これは、ワークロードがその機能を提供するために依存するものです。*ハード*な依存関係とは、それなしではワークロードが機能しないものですが、*ソフト*な依存関係は、利用できないことに気付かれなかったり、一定期間許容されることがあります。ハードな依存関係は、ワークロードの可用性に直接影響します。
そのため、ワークロードの理論上の最大可用性を計算してみることをお勧めします。これは、ソフトウェア自体を含むすべての依存関係の可用性の積です (*α**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**
一般的には、可用性の目標がワークロードの目標と同等以上の依存関係を選択します。
# 冗長性を実装した可用性
ワークロードが複数の独立した冗長サブシステムを利用する場合、単一のサブシステムを使用する場合よりも高いレベルの理論上の可用性を実現できます。例えば、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、リージョン) が使用するすべての障害隔離境界で耐障害性を確保できるよう、スペアリングを組み込む必要があります。
# CAP の定理
可用性について考えるもう 1 つの方法は、CAP 定理との関係です。この定理では、データを格納する複数のノードで構成される分散システムでは、次の 3 つの保証のうち 2 つ以上を同時に提供することはできません。
+ **C** (一貫性): 一貫性が保証されない場合、読み取りリクエストはすべて最新の書き込みまたはエラーを受け取ります。
+ **A** (可用性): ノードがダウンしていたり利用できなくなったりしても、すべてのリクエストはエラー以外の応答を受け取ります。
+ **P** (耐パーティション): ノード間で任意の数のメッセージが失われても、システムは動作し続けます。
(詳細については、セス・ギルバートとナンシー・リンチ、「[http://dl.acm.org/citation.cfm?id=564601&CFID=609557487&CFTOKEN=15997970](http://dl.acm.org/citation.cfm?id=564601&CFID=609557487&CFTOKEN=15997970)」、*ACM SIGACT News*、第 33 巻 2 号 (2002)、51 ～ 59 ページを参照してください。)
ほとんどの分散システムは、ネットワーク障害に耐える必要があるため、ネットワークパーティションを許可する必要があります。つまり、これらのワークロードは、ネットワークパーティションが発生したときに一貫性と可用性のどちらかを選択する必要があります。ワークロードが可用性を選択した場合、常に応答が返されますが、データに一貫性がない可能性があります。一貫性を選択した場合、ワークロードがデータの一貫性を確認できないため、ネットワークパーティションでエラーを返す可能性があります。
より高いレベルの可用性を提供することを目標とするワークロードでは、ネットワークパーティション中にエラーが返される (使用できない) ことを防止するため、可用性と耐パーティション (AP) を選択する場合があります。その結果、最終的な整合性または単調な整合性など、より緩やかな[整合性モデル](https://en.wikipedia.org/wiki/Consistency_model)が必要になります。
# 耐障害性と障害隔離
可用性について考えるとき、これらの 2 つは重要な概念です。耐障害性とは、[サブシステムの障害](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/design-your-workload-to-withstand-component-failures.html)に耐え、可用性を維持する (確立された SLA の範囲内で適切な処理を行う) 能力です。フォールトトレランスを実装するために、ワークロードはスペア (または冗長) サブシステムを使用します。冗長セット内のサブシステムの 1 つに障害が発生すると、通常はほぼシームレスに、別のサブシステムが処理を引き継ぎます。この場合、スペアは真のスペアキャパシティであり、障害が発生したサブシステムの処理を 100% 引き継ぐことができます。真のスペアでは、ワークロードに悪影響を及ぼすには、複数のサブシステムで障害が発生する必要があります。
障害分離により、障害発生時の影響範囲を最小限に抑えることができます。これは通常、モジュール化によって実装されます。ワークロードは小さなサブシステムに分割され、それぞれ個別に障害が発生し、個別に修復できます。モジュールの障害は、[モジュールを超えて拡散することはありません](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/design-interactions-in-a-distributed-system-to-mitigate-or-withstand-failures.html)。この考えは、ワークロード内のさまざまな機能にまたがる垂直方向と、同じ機能を提供する複数のサブシステムにわたる水平方向の両方に及びます。これらのモジュールは、イベント中の影響範囲を制限する障害コンテナとして機能します。
コントロールプレーン、データプレーン、静的安定性のアーキテクチャパターンは、耐障害性と障害分離の実装を直接的にサポートします。Amazon Builders’ Library の記事「[可用性ゾーンを使用した静的安定性](https://aws.amazon.com/builders-library/static-stability-using-availability-zones)」には、これらの用語の適切な定義と、耐障害性が高く可用性の高いワークロードの構築にどのように適用されるかについて記載されています。このホワイトペーパーでは、「[AWS での高可用性分散システムの設計](designing-highly-available-distributed-systems-on-aws.md#designing-highly-available-distributed-systems-on-aws.title)」のセクションでこれらのパターンを使用しており、その定義についてもここにまとめています。
+ **コントロールプレーン** — ワークロードのうち、リソースの変更 (追加、削除、修正) を行い、これらの変更を必要な場所に反映することを担当する部分です。コントロールプレーンは通常、データプレーンよりも複雑で可動部分が多いため、統計的に故障する可能性が高く、可用性が低くなります。
+ **データプレーン** — 日常業務機能を提供するワークロードの一部です。データプレーンは、コントロールプレーンよりもシンプルで大量に動作する傾向があるため、可用性が高くなります。
+ **静的安定性** — 依存関係が損なわれてもワークロードが正常に動作し続ける能力。実装方法の 1 つは、データプレーンからコントロールプレーンの依存関係を削除することです。また、ワークロードの依存関係を疎結合する方法もあります。ワークロードには、依存関係が提供しているはずの更新情報 (新しい情報、削除された情報、変更された情報など) が表示されない可能性があります。ただし、依存関係が損なわれる前に行っていたことはすべて機能し続けています。
ワークロードの障害について考えるとき、回復について検討できる大まかなアプローチが 2 つあります。1 つ目の方法は、障害が発生した後に、AWS Auto Scaling を使用して新しい容量を追加してそれに対応することです。2 つ目の方法は、そうした障害が発生する前に備えることです。例えば、ワークロードのインフラストラクチャをオーバープロビジョニングして、追加のリソースを必要とせずに正常に動作し続けることができるようにします。
静的に安定したシステムでは、後者のアプローチを使用します。障害発生時にも利用可能なスペアキャパシティを事前にプロビジョニングします。この方法では、障害から回復するための新しいキャパシティをプロビジョニングする際に、ワークロードのリカバリパスにあるコントロールプレーンに依存関係を構築しません。また、さまざまなリソースに新しいキャパシティをプロビジョニングするには時間がかかります。新しいキャパシティを待っている間に既存の需要によってワークロードが過負荷になり、さらにパフォーマンスが低下して、「ブラウンアウト」が発生したり、可用性が完全に喪失する可能性があります。ただし、事前にプロビジョニングされたキャパシティを利用することによるコストへの影響と可用性目標を比較して検討する必要もあります。
静的安定性では、高可用性ワークロードに対して次の 2 つのルールがあります。
**ルール 7**
特にリカバリ中は、データプレーンのコントロールプレーンに依存関係を作成しません。
**ルール 8**
可能な限り、依存関係が損なわれてもワークロードが正しく動作できるように、依存関係を疎結合します。