耐障害性と障害隔離
可用性について考えるとき、これらの 2 つは重要な概念です。耐障害性とは、サブシステムの障害に耐え、可用性を維持する (確立された SLA の範囲内で適切な処理を行う) 能力です。フォールトトレランスを実装するために、ワークロードはスペア (または冗長) サブシステムを使用します。冗長セット内のサブシステムの 1 つに障害が発生すると、通常はほぼシームレスに、別のサブシステムが処理を引き継ぎます。この場合、スペアは真のスペアキャパシティであり、障害が発生したサブシステムの処理を 100% 引き継ぐことができます。真のスペアでは、ワークロードに悪影響を及ぼすには、複数のサブシステムで障害が発生する必要があります。
障害分離により、障害発生時の影響範囲を最小限に抑えることができます。これは通常、モジュール化によって実装されます。ワークロードは小さなサブシステムに分割され、それぞれ個別に障害が発生し、個別に修復できます。モジュールの障害は、モジュールを超えて拡散することはありません。この考えは、ワークロード内のさまざまな機能にまたがる垂直方向と、同じ機能を提供する複数のサブシステムにわたる水平方向の両方に及びます。これらのモジュールは、イベント中の影響範囲を制限する障害コンテナとして機能します。
コントロールプレーン、データプレーン、静的安定性のアーキテクチャパターンは、耐障害性と障害分離の実装を直接的にサポートします。Amazon Builders’ Library の記事「可用性ゾーンを使用した静的安定性
-
コントロールプレーン — ワークロードのうち、リソースの変更 (追加、削除、修正) を行い、これらの変更を必要な場所に反映することを担当する部分です。コントロールプレーンは通常、データプレーンよりも複雑で可動部分が多いため、統計的に故障する可能性が高く、可用性が低くなります。
-
データプレーン — 日常業務機能を提供するワークロードの一部です。データプレーンは、コントロールプレーンよりもシンプルで大量に動作する傾向があるため、可用性が高くなります。
-
静的安定性 — 依存関係が損なわれてもワークロードが正常に動作し続ける能力。実装方法の 1 つは、データプレーンからコントロールプレーンの依存関係を削除することです。また、ワークロードの依存関係を疎結合する方法もあります。ワークロードには、依存関係が提供しているはずの更新情報 (新しい情報、削除された情報、変更された情報など) が表示されない可能性があります。ただし、依存関係が損なわれる前に行っていたことはすべて機能し続けています。
ワークロードの障害について考えるとき、回復について検討できる大まかなアプローチが 2 つあります。1 つ目の方法は、障害が発生した後に、AWS Auto Scaling を使用して新しい容量を追加してそれに対応することです。2 つ目の方法は、そうした障害が発生する前に備えることです。例えば、ワークロードのインフラストラクチャをオーバープロビジョニングして、追加のリソースを必要とせずに正常に動作し続けることができるようにします。
静的に安定したシステムでは、後者のアプローチを使用します。障害発生時にも利用可能なスペアキャパシティを事前にプロビジョニングします。この方法では、障害から回復するための新しいキャパシティをプロビジョニングする際に、ワークロードのリカバリパスにあるコントロールプレーンに依存関係を構築しません。また、さまざまなリソースに新しいキャパシティをプロビジョニングするには時間がかかります。新しいキャパシティを待っている間に既存の需要によってワークロードが過負荷になり、さらにパフォーマンスが低下して、「ブラウンアウト」が発生したり、可用性が完全に喪失する可能性があります。ただし、事前にプロビジョニングされたキャパシティを利用することによるコストへの影響と可用性目標を比較して検討する必要もあります。
静的安定性では、高可用性ワークロードに対して次の 2 つのルールがあります。
ルール 7
特にリカバリ中は、データプレーンのコントロールプレーンに依存関係を作成しません。
ルール 8
可能な限り、依存関係が損なわれてもワークロードが正しく動作できるように、依存関係を疎結合します。
