Multi-AZ / Multi-Region Reliability設計

ゴール

信頼性要件から、

保護対象
可用性目標
耐える障害範囲
必須依存関係

が整理され、必要な障害分離境界が決まっている状態から始めます。

ここで確認するのは、

マルチAZにしたか
マルチリージョンにしたか

ではありません。

要求された障害を発生させる
↓
障害側を利用できないものとして除外
↓
生存側だけを見る
↓
保護対象の必須依存経路を最後までたどる
↓
業務機能が成立するか

です。

障害後にも必須依存経路が最後まで残ることを、障害分離成立の判断基準にします。

1. 配置状態と障害分離成立は別

例えば、アプリケーションが複数AZに配置されているとします。

AZ-A
├─ アプリケーションA
└─ 注文データ

AZ-B
└─ アプリケーションB

見た目はマルチAZです。

しかしAZ-Aを利用できないものとして除外すると、

AZ-B
└─ アプリケーションB
       ↓
   注文データなし
       ↓
   注文処理不可

となります。

したがって、

アプリケーションのマルチAZ配置
→ 成立

注文受付全体のAZ障害分離
→ 未成立

です。

判断対象は個別リソースではなく、保護対象となる業務機能全体です。

2. 障害境界を1つ消してから評価する

障害分離を確認するときは、対象となる障害境界を最初から存在しないものとして扱います。

AZ障害を想定する場合

AZ-A
× 利用不能

AZ-B
○ 利用可能

この状態で、

AZ-Bだけで
注文受付を成立させられるか

を確認します。

リージョン障害を想定する場合

リージョンA
× 利用不能

リージョンB
○ 利用可能

この状態で、

リージョンBだけで
注文受付を成立させられるか

を確認します。

平常時に両方を利用できるかではなく、片方を完全に失った状態で評価します。

3. 保護対象から必須依存経路をたどる

例えば注文受付が、

利用者
↓
入口
↓
注文アプリケーション
↓
認証
↓
注文データ
↓
決済

という経路で成立しているとします。

障害後には、

入口
アプリケーション
認証
注文データ
決済

のすべてについて、

生存側だけで利用できるか

を確認します。

途中に1つでも、

障害側にしか存在しない必須依存

があれば、

必須依存経路
→ 切断
↓
保護対象
→ 成立しない

と判断します。

4. マルチAZでは生存AZ側の経路を見る

AZ障害への耐性を確認する場合も、考え方は同じです。

例えばAZ-Aを失ったあと、

AZ-B
├─ アプリケーション       ○
├─ 必要なネットワーク     ○
├─ 必要なデータ           ○
└─ 必須依存サービス       ○

であれば、生存側に必要な経路が残っています。

一方、

AZ-B
├─ アプリケーション       ○
├─ 必要なネットワーク     ○
└─ 注文データ             ×

なら、

マルチAZ配置
→ している

AZ障害後の注文受付
→ 成立しない

です。

具体的にどの複製方式や復旧方式を利用するかではなく、必要な状態を生存AZ側から利用できるかをここでは確認します。

5. マルチリージョンではリージョン単独成立を見る

リージョン障害では、

リージョンAを完全に除外
↓
リージョンBだけを評価

します。

例えばリージョンBに、

アプリケーション
注文データ

があっても、

認証
→ リージョンAへ必須依存

していれば、

リージョンA障害
↓
認証不可
↓
リージョンBでも注文受付不可

となります。

したがって、

2リージョンにリソースが存在する

ことではなく、

生存リージョン単独で
保護対象を成立させられる

ことを確認します。

6. 障害境界をまたぐ必須依存を探す

生存側から必須依存経路をたどるときは、

生存側
↓
障害側

へ戻る経路がないか確認します。

例えば、

リージョンB
└─ 注文アプリケーション
       │
       └────→ リージョンAの認証

なら、

リージョンB単独成立
→ 不可

です。

同様に、

生存側のアプリケーション
↓
障害側の設定

や、

生存側のサービス
↓
障害側の内部API

が必須なら、その依存関係が障害分離を壊します。

確認するのは依存関係の名前ではなく、

その依存が失われたとき
保護対象を継続できるか

です。

7. 生存経路を構成する依存関係をまとめて監査する

生存側だけで業務機能を成立させるために必要なものを、1本の経路として確認します。

これらを個別に再定義するのではなく、

障害後の必須依存経路に
切断点がないか

という1つの基準で監査します。

8. 共通依存による「両方同時停止」も確認する

複数AZ・複数リージョンに配置されていても、

AZ-A ─┐
      ├─→ 共通の必須依存
AZ-B ─┘

または、

リージョンA ─┐
             ├─→ 共通の必須依存
リージョンB ─┘

となっている場合があります。

その共通依存が停止すると、

両方の生存経路
→ 同時に切断

されます。

したがって、

場所が分かれている

だけではなく、

同じ障害で同時に失われる
必須依存を共有していないか

も確認します。

9. 「存在する」だけでなく利用可能性まで見る

依存先が完全停止していなくても、保護対象が成立しないことがあります。

例えば、

外部認証
↓
応答はする
↓
通常50 ms
障害時3秒

となり、

アプリケーション側でタイムアウト
↓
注文受付失敗

する場合です。

この場合、

依存先は存在する

ものの、

必要な条件で利用できない

ため、生存経路は成立していません。

障害後の可用性は、

接続できるか

だけでなく、

保護対象を成立させられる状態か

で判断します。

10. 切り替え制御も生存経路の一部として扱う

正常側に必要なアプリケーションやデータがあっても、

正常側へ移行するための制御

が障害側へ必須依存していれば問題があります。

例えば、

正常リージョンへの切り替え開始
↓
障害リージョン内の管理処理が必須

なら、

障害リージョン利用不能
↓
切り替え開始不可

となる可能性があります。

ここでは、

どのサービスで切り替えるか

は決めません。

確認するのは、

切り替え成立に必要な依存経路が
障害側へ戻っていないか

までです。

11. 障害分離監査シート

対策を選ぶ前に、

どこで経路が切れているか

を明確にします。

12. シナリオ

要件

リージョン障害時にも
注文受付を継続する

構成

リージョンA
├─ 注文アプリケーション
├─ 認証
└─ 注文データ

リージョンB
├─ 注文アプリケーション
├─ 注文データ
└─ 決済
       │
       └────→ 認証はリージョンA

障害

リージョンA
× 利用不能

生存経路監査

入口             ○
↓
アプリケーション ○
↓
認証             ×
↓
注文データ       ○
↓
決済             ○

途中の認証で必須経路が切れます。

したがって、

マルチリージョン配置
→ あり

リージョン障害後の注文受付
→ 不可

リージョン障害分離
→ 未成立

です。

13. 混同ポイント

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

信頼性設計条件を確認
↓
要求された障害境界を1つ除外
↓
生存側だけを見る
↓
保護対象から
必須依存経路を最後までたどる
↓
障害側へ戻る必須依存がある？
│
├─ ある
│   ↓
│   障害分離 未成立
│
└─ ない
    ↓
共通依存で
生存側も同時に失われる？
│
├─ 失われる
│   ↓
│   障害分離 未成立
│
└─ 失われない
    ↓
依存先は必要な条件で利用可能？
│
├─ 利用不可
│   ↓
│   障害分離 未成立
│
└─ 利用可能
    ↓
生存側だけで
保護対象が成立
    ↓
障害分離 成立

まとめ

マルチAZ / マルチリージョンの信頼性設計では、

複数の場所に置いた

だけでは成立を判断しません。

障害境界を1つ失う
↓
生存側だけを見る
↓
保護対象の必須依存経路をたどる
↓
最後まで切れずに成立する

ことを確認します。

重要なのは、

配置状態

ではなく、

障害後の業務機能成立性

です。

主要AWS公式資料

• AWS Certified Solutions Architect - Professional 試験ガイド（SAP-C02）
• AWS Well-Architected フレームワーク — REL10-BP01 複数の場所にワークロードをデプロイする
• AWS Well-Architected フレームワーク — 障害部分を切り離してワークロードを保護する
• AWS 規範ガイダンス — マルチリージョンの基本 3: ワークロードの依存関係を理解する