Reliability RequirementとFailure Domain

ゴール

信頼性に関する要件を読んだとき、既に学習した可用性・障害範囲・依存関係などの考え方を使って、

信頼性要件
↓
信頼性の設計条件
↓
具体的なアーキテクチャ選択

のうち、「信頼性の設計条件」までを完成させることを目標とします。

具体的なマルチAZ、マルチリージョン、自動復旧、データレプリケーション、フェイルオーバー方式は、ここではまだ選びません。

1. 既習の分析軸を1つにまとめる

信頼性の設計では、すでに学習した次の観点を組み合わせます。

ここで新しく行うのは、それぞれを再定義することではありません。

複数の分析結果
↓
1つの信頼性設計条件

へまとめます。

2. 信頼性設計条件の形を先に決める

シナリオから、原則として次の項目を抽出します。

この表を埋められれば、具体的なAWS構成を比較する準備が整います。

3. 保護対象を最初に固定する

例えばECサイト全体について、

99.99%の可用性が必要

とだけ考えると、要件が曖昧です。

実際には、

注文受付
決済
商品検索
商品推薦
売上レポート

で停止許容度が異なる可能性があります。

したがって、

何を99.99%利用可能にするのか

まで特定します。

例

注文受付
→ 障害時も継続必須

商品推薦
→ 一時停止を許容

売上レポート
→ 数時間の停止を許容

この場合、信頼性設計の中心となる保護対象は注文受付です。

4. 耐える障害範囲を要件から取り出す

次の要件を考えます。

1つの配置場所に障害が発生しても注文受付を継続する必要がある。

ここから抽出するのは、

保護対象
→ 注文受付

耐える障害範囲
→ 1つの配置場所の障害

です。

この段階では、

マルチAZ
マルチリージョン

のどちらを使うかはまだ決めません。

先に、

どの障害範囲まで耐える必要があるか

を設計条件として固定します。

5. 依存関係を設計条件へ変換する

注文受付が次の要素へ依存しているとします。

注文受付
├─ 認証
├─ 注文データ
├─ 決済
└─ 商品推薦

すべてを同じ重要度として扱うわけではありません。

例えば、

認証停止
→ 注文受付不可

注文データ利用不能
→ 注文受付不可

決済停止
→ 注文完了不可

なら、これらは保護対象に対する重要な依存関係です。

一方、

商品推薦停止
↓
推薦を省略
↓
注文受付は継続

できるなら、商品推薦は縮退可能な依存関係として扱えます。

したがって設計条件には、

必須依存関係
縮退可能な依存関係

を分けて残します。

6. 共通依存関係を単一障害点として確認する

例えば、

        ┌─ アプリケーションA
利用者 ─┤
        └─ アプリケーションB
                 │
                 ▼
          共通データストア

という構成があります。

アプリケーションが複数あっても、

共通データストア停止
↓
注文受付全体停止

なら、

共通データストア
→ 排除すべき単一障害点

として設計条件に残します。

重要なのは、

何個あるか

ではなく、

保護対象を停止させる共通依存関係があるか

です。

7. 障害モードを設計条件へ含める

障害分析では完全停止だけを想定しません。

例えばデータストアなら、

接続不能
タイムアウト
高遅延
読み取りのみ成功
書き込みのみ失敗
一部要求だけ失敗

といった状態があります。

したがって、

データストア障害へ耐える

だけではなく、

どの障害モードでも
保護対象を継続する必要があるのか

まで確認します。

障害モードによって必要な対策が異なるため、具体的な構成を選ぶ前の設計条件として残します。

8. 設計条件シートへ統合する

次の要件を考えます。

注文受付は高い可用性を必要とする。1つの配置場所に障害が発生しても注文を受け付ける必要がある。認証、決済、注文データは必須である。商品推薦は一時停止してもよい。

設計条件へ変換すると、

これで初めて、

どのAWS構成なら
この条件を満たせるか

を比較できます。

9. シナリオ：要件が曖昧な場合

次の要件だけが示されているとします。

注文システムを高可用性にしてください。

このままでは構成を選べません。

不足しているのは例えば、

どの機能を保護するか
どの程度の可用性が必要か
どの障害範囲まで耐えるか
どの依存関係が必須か
どの障害モードを考慮するか

です。

したがってSAP-C02では、

高可用性
↓
即座に特定サービスを選択

ではなく、

高可用性
↓
設計条件を具体化
↓
条件を満たす構成を比較

という順序で判断します。

10. 混同ポイント

11. SAP-C02での判断フロー

問題文に、

高可用性
障害時も継続
単一障害点を排除
依存サービスの障害
特定範囲の障害へ耐える

といった条件が出たら、

① 保護対象は何か
↓
② 可用性目標は何か
↓
③ どの障害範囲まで耐えるか
↓
④ 必須依存関係は何か
↓
⑤ 縮退可能な依存関係は何か
↓
⑥ 考慮する障害モードは何か
↓
⑦ 単一障害点は何か
↓
⑧ 信頼性設計条件を確定
↓
⑨ 具体的な構成を比較

の順で考えます。

まとめ

個々の用語を知っているだけでは、信頼性要件から構成を選べません。

既習の、

可用性
障害ドメイン
単一障害点
依存関係
障害モード

を、

保護対象
+
可用性目標
+
耐える障害範囲
+
必須依存関係
+
縮退可能な依存関係
+
考慮する障害モード
+
排除すべき単一障害点

という1つの信頼性設計条件へまとめます。

その設計条件が、後続の具体的な冗長化・復旧構成を選ぶ基準になります。

主要AWS公式資料

• AWS Certified Solutions Architect - Professional 試験ガイド（SAP-C02）
• AWS Well-Architected フレームワーク — 信頼性
• AWS Well-Architected フレームワーク — 可用性
• AWS Well-Architected フレームワーク — 障害部分を切り離してワークロードを保護する
• AWS Well-Architected フレームワーク — REL04-BP02 疎結合の依存関係を実装する