Multi-AZ / Multi-Region配置設計

1. リージョンと可用性ゾーン

AWSリージョンはAWS インフラストラクチャを運用する独立した地理的領域です。可用性ゾーン（AZ）は、そのリージョン内にある独立した場所です。

AWSリージョン
├─ 可用性ゾーン A
├─ 可用性ゾーン B
└─ 可用性ゾーン C

同一リージョン内のAZは低レイテンシー、高帯域幅、高冗長なネットワークで接続されます。AZを跨いでワークロードを構成することが、リージョン内高可用性の基本になります。

2. 場所を障害分離境界として考える

配置設計では「どこに置くか」ではなく「どの障害から分離するか」を考えます。

コンポーネント障害
→ 複数リソース

可用性ゾーン障害
→ 複数AZ

リージョン規模の障害
→ 複数リージョン

障害範囲が広がるほど、必要な障害分離境界も広がります。

3. 単一AZに残る共通障害要因

重要ワークロードを1つのAZだけに配置すると、インスタンスを複数にしていても場所単位の共通障害要因が残ります。

AZ A
├─ アプリケーション 1
├─ アプリケーション 2
└─ データベース

AZ Aが利用不能
↓
同じロケーションに依存するコンポーネントが同時に影響

復旧要件がAZ 障害を含むなら、場所障害をアーキテクチャの設計対象にします。

4. マルチAZでAZ 障害を分離する

マルチAZ アーキテクチャでは、必要なリソースを複数AZへ分散し、1つのAZが利用不能になっても未影響AZ側でサービスを継続できるようワークロードを構成します。

リージョン

AZ A                 AZ B
├─ ワークロード          ├─ ワークロード
└─ 必要な状態    └─ 必要な状態 / キャパシティ

AZ A 障害
↓
AZ B側を利用して継続できるよう設計

中心目的は、単一AZ 障害がワークロード全体の停止へ直結しないよう障害ドメインを分離することです。

5. マルチAZは特定トポロジーを意味しない

マルチAZという言葉だけでは、アクティブ / アクティブ、アクティブ / スタンバイ、レプリケーション方式、自動フェイルオーバー、データ損失ゼロの有無は決まりません。

マルチAZ
→ 複数AZを障害分離に利用する

別途確認
→ リソース配置
→ 状態 / レプリケーション
→ フェイルオーバー動作
→ トラフィックフロー

AWSサービスごとにマルチAZの実装方式が異なるため、配置境界とサービス固有動作を分けて判断します。

6. マルチAZで保護できる障害範囲

マルチAZはインスタンス、データセンター、可用性ゾーン規模の障害へのレジリエンスを高めます。しかしAWSリージョン全体が利用不能になる障害まで自動的に保護するものではありません。

リージョン A
├─ AZ 1
├─ AZ 2
└─ AZ 3

障害範囲 = リージョン A全体
↓
リージョン A内だけのマルチAZでは境界不足

7. リージョン規模の障害が対象ならマルチリージョンを評価する

復旧要件がリージョン全体の障害を含むなら、障害境界はリージョンです。その場合、プライマリリージョンとは別のAWSリージョンを使うマルチリージョンアーキテクチャを候補として評価します。

プライマリリージョン
      │
      │ 地理的分離
      │
復旧リージョン

リージョンというより大きな分離境界を使うことで、リージョン規模の障害からビジネスサービスを分離できる可能性があります。

8. マルチリージョンは地理的冗長性

マルチAZは同一リージョン内の場所冗長性、マルチリージョンはリージョン間の地理的冗長性を提供する設計です。

マルチAZ
→ リージョン内の障害分離

マルチリージョン
→ リージョン間の地理的障害分離

リージョン規模の障害を復旧要件に含める場合、リージョン間の独立性がアーキテクチャ候補選定の中心になります。

9. マルチリージョンはアクティブ-アクティブとは限らない

複数リージョンを使っても、両方のリージョンが常時本番トラフィックを処理する必要はありません。

どちらを採用するかはRTO / RPO、コスト、トラフィック、状態、運用の複雑さなどから決定します。

10. マルチリージョンを機械的に採用しない

マルチリージョンは障害分離を強化できる一方、デプロイ、データ管理、設定、監視、テスト、フェイルオーバー運用、コストなどを複雑にします。

リージョン規模の障害が要件に含まれない
+
単一リージョンマルチAZで目標を満たせる
↓
マルチリージョンを追加しない判断も合理的

重要だからマルチリージョンではなく、障害範囲と復旧要件から必要性を判断します。

11. 配置だけではリージョン規模の復旧は完成しない

アプリケーションを2Regionへ置くだけではビジネスサービスの復旧は完成しません。

リージョン A アプリケーション
リージョン B アプリケーション

追加で確認
→ データ
→ 設定
→ アイデンティティ
→ ネットワーク
→ 依存関係
→ トラフィック
→ 運用上の手順

復旧リージョンにアプリケーションがあっても、必要なデータや依存関係が利用できなければサービスは復旧できません。

12. リージョン規模のリソース境界を意識する

多くのAWSリソースは特定リージョンに作成されるリージョン規模のリソースです。リージョン Aへリソースを作成しても、同じリソースや状態がリージョン Bへ自動的に作成・複製されるとは限りません。

リージョン A リソース
≠
リージョン Bにも自動作成済み

マルチリージョンでは復旧リージョンに何が必要かを明確にします。データレプリケーション方式や整合性の詳細は、その要件を満たす次の設計判断です。

13. 共有依存関係によるリージョン規模の共通障害要因

アプリケーションを複数リージョンへ配置しても、両リージョンが同じ依存関係へ必須依存していれば、その依存関係が共通障害ポイントになる可能性があります。

リージョン A ─┐
          ├→ 共有依存関係
リージョン B ─┘

アプリケーション層だけではなく、データ、アイデンティティ、外部サービス、制御コンポーネント、運用依存関係を含め、ビジネスサービス全体でレジリエンスを評価します。

14. 復旧リージョンを要件から選ぶ

マルチリージョンが必要でも、任意の別リージョンを選べばよいわけではありません。

地理的 距離だけでなく、エンドツーエンドで復旧要件を満たせるリージョンを選択します。

15. 地理的分離のトレードオフ

リージョン間の地理的分離を大きくすると、同一地理的な障害事象に同時に巻き込まれるリスクを下げられる場合があります。一方でネットワークレイテンシー、データ移動、運用の複雑さ、コストなどへ影響します。

障害独立性
+
ビジネス要件
+
運用上の制約
↓
復旧リージョン選択

「最も遠いリージョン」を機械的に選ぶのではなく、要件に対するトレードオフで決定します。

16. 障害範囲から配置境界へ変換する

最終判断ではRTO / RPO、依存関係、コスト、運用の複雑さも合わせて確認します。

17. AZ 障害までが要件の場合

要件
・重要 ウェブ サービス
・単一AZ 障害でもサービス継続
・リージョン全体の障害は復旧範囲外
・コスト / 運用を増やしすぎない

中心候補
単一リージョン + マルチAZ

マルチAZで復旧目標を満たせるなら、マルチリージョン追加によるコストや運用の複雑さを必ずしも受け入れる必要はありません。

18. リージョン規模の障害も対象の場合

要件
・リージョン全体の障害でもビジネスサービスを復旧
・RTO / RPOは定義済み

配置候補
プライマリリージョン + 復旧リージョン

その上でデータ、トラフィック、復旧手順、依存関係など必要な制御を組み合わせます。

19. マルチリージョンでも共通障害要因を残さない

リージョン A アプリケーション
リージョン B アプリケーション

両方が必須依存
↓
単一共有依存関係

アプリケーション配置が地理的に冗長でも、ビジネスサービス全体が同じ依存関係に拘束されればリージョン規模の レジリエンスは成立しない可能性があります。

20. 障害モード

21. SAP-C02判断フロー

復旧要件
↓
対象障害範囲は？
↓
コンポーネント / リソース
→ リソース冗長性

可用性ゾーン
→ マルチAZ 候補

AWSリージョン
→ マルチリージョン候補
↓
復旧リージョン候補は要件を満たす？
↓
サービス / 機能可用性
レイテンシー
コンプライアンス
依存関係
運用
↓
配置決定
↓
必要なデータ / トラフィック / 復旧制御を設計