マルチAZ・マルチリージョンアーキテクチャ
マルチAZとマルチリージョンの高可用性アーキテクチャ、フェイルオーバー設計、データレプリケーション、コストとのバランスを SAA 基礎から SAP 高度設計まで解説。
AWS の高可用性設計は マルチAZ → マルチリージョン の段階で強化されます。 可用性要件とコストのトレードオフを見極め、適切なアーキテクチャを選ぶ必要があります。 本記事ではマルチAZ/マルチリージョンアーキテクチャを SAA / SAP 両面から整理します。
SAA レベル：基礎概念
AZ (Availability Zone) とは
AWS リージョンは複数の Availability Zone (AZ) で構成されます。
- AZ の定義: 独立した電力・冷却・ネットワークを持つデータセンター群
- AZ 間の分離: 障害が他 AZ に波及しない設計
- AZ 間の低レイテンシ通信: 同一リージョン内なので高速
- AZ 数: リージョンごとに 2〜6 个程度
SAA レベル：基礎概念
AZ の核心は 「独立したデータセンター群で、障害が他 AZ に波及しない」 ことです。 同リージョン内の複数 AZ にリソースを分散させるだけで 単一 AZ 障害に耐える構成 になります。 SAA では「マルチAZ = リージョン内の高可用性」が基本原則です。
リージョンとは
- 地理的独立性: リージョンは完全に独立（データ主権も分離）
- リージョン間は遠隔: レイテンシが大きい（数十ミリ秒〜）
- データ主権: 各リージョンのデータは他リージョンに自動複製されない
- サービス提供状況: リージョンによって利用可能サービスが異なる
マルチAZ vs マルチリージョン
| 項目 | マルチAZ | マルチリージョン |
|---|---|---|
| 範囲 | 同一リージョン内 | 複数リージョン |
| 対応障害 | AZ 障害 | リージョン障害 |
| レイテンシ | 低（1〜2ms） | 高（数十ms〜） |
| コスト | 比較的低 | 高（データ転送・リソース倍増） |
| 複雑さ | 中 | 高 |
SAA 試験のポイント
「マルチAZ は高可用性、マルチリージョンはディザスタリカバリ (DR)」 が SAA の基本原則です。 マルチAZ は AZ 障害に対する継続性、マルチリージョンは大規模災害に対する復旧力を提供します。 この階層構造を SAA は必ず問います。
マネージドサービスのマルチAZ サポート
主要なマネージドサービスは デフォルトでマルチAZ を提供します。
| サービス | マルチAZ | 設計論点 |
|---|---|---|
| ELB (ALB/NLB) | デフォルトでマルチAZ | クロスゾーン負荷分散 |
| RDS (Multi-AZ) | スタンバイインスタンス | 同期レプリケーション |
| Aurora | 自動マルチAZ + リードレプリカ | クォーラムベースストレージ |
| ElastiCache (Redis) | リードレプリカ + 自動フェイルオーバー | クラスタモード |
| DynamoDB | 自動マルチAZ | グローバルテーブルでマルチリージョン |
SAA 頻出
RDS Multi-AZ は「プライマリ + スタンバイ」の同期レプリケーション です。 スタンバイは 読み取りに使えない（読み取り負荷分散には Read Replica を別途使用）。 この使い分けが SAA で頻出します。
SAP レベル：高度な設計シナリオ
マルチAZ アーキテクチャの設計
SAP では アプリ全層をマルチAZ 化 します。
SAP レベル：高度な設計シナリオ
SAP のマルチAZ 定石は 「Web / App / DB の全層をマルチAZ に分散」 です。
- Web 層: ALB でマルチAZ 負荷分散
- App 層: EC2/ECS を複数 AZ に分散 (Auto Scaling)
- DB 層: RDS Multi-AZ または Aurora 1 層でも単一 AZ だと、そこが SPOF になるため、全層分散が必須です。
[インターネット]
│
▼
[ALB (マルチAZ)]
│ │
▼ ▼
[AZ-1] [AZ-2]
EC2 群 EC2 群
(Auto (Auto
Scaling) Scaling)
│ │
└─────┬──────┘
▼
[RDS Multi-AZ]
Primary (AZ-1) ←→ Standby (AZ-2)クロスゾーン負荷分散
ALB は クロスゾーン負荷分散 (Cross-Zone Load Balancing) を設定できます。
| 設定 | 挙動 | 設計論点 |
|---|---|---|
| 有効 | 全 AZ のターゲットに均等分散 | AZ 間インスタンス数不均一でも均等 |
| 無効 | 各 AZ のターゲットにのみ分散 | AZ 間でインスタンス数が違うと偏る |
クロスゾーン負荷分散の注意
クロスゾーン無効 の場合、AZ 間でインスタンス数が違うと 1 インスタンスあたりの負荷が偏る です。 SAP では「AZ 間でインスタンス数を均一に保つか、クロスゾーンを有効にするか」の設計判断が問われます。 NLB はクロスゾーンが 有料 な点にも注意。
Aurora のマルチAZ 設計
Aurora は クォーラムベースのストレージレプリケーション でマルチAZ を実現します。
- 6 方向コピー: データが 3 AZ に 6 コピー分散
- クォーラム書き込み: 4/6 で書き込み承認（高パフォーマンス）
- クォーラム読み取り: 3/6 で読み取り承認
- フェイルオーバー: プライマリ障害でリードレプリカが自動昇格
Aurora フェイルオーバーの設計
Aurora のフェイルオーバーは 30 秒以内 に完了しますが、 アプリ側のコネクションプールが古いエンドポイントを把持 していると再接続失敗が続きます。 「Aurora のライター ENDPOINT を使う」「コネクションプールの再接続ロジックを設計」が SAP の定石です。
マルチリージョンアーキテクチャの設計
マルチリージョンは リージョン障害に耐える ための設計です。
[プライマリリージョン (東京)]
├── ALB → EC2/ECS → Aurora Primary
│
│ (非同期レプリケーション)
│
[セカンダリリージョン (バージニア)]
├── ALB → EC2/ECS → Aurora Secondary (スタンバイ)- データレプリケーション: 非同期（RPO > 0）
- Route 53 ヘルスチェック: リージョンレベルの監視
- フェイルオーバー: Route 53 で DNS 切替（数分）
- コスト: リソースが倍増、リージョン間データ転送料金
SAP レベル：高度な設計シナリオ
SAP では「アクティブ・アクティブ と アクティブ・パッシブ の選択」が問われます。
- アクティブ・アクティブ: 両リージョンでトラフィック処理（コスト有効活用、RTO 最小）
- アクティブ・パッシブ: 片側は待機（コスト高だが単純、フェイルオーバー明確） 要件（コスト vs 可用性）で選ぶ能力が SAP の核心論点です。
データレプリケーション方式
マルチリージョンでのデータ同期方式：
| 方式 | RPO | 特徴 | 代表サービス |
|---|---|---|---|
| 同期レプリケーション | 0 | 書き込み完了まで待つ（遅い） | RDS Multi-AZ（同一リージョン） |
| 非同期レプリケーション | 秒〜分 | 遅延許容（速い） | Aurora Global DB, DynamoDB Global Table |
| 準同期レプリケーション | ほぼ 0 | プライマリ + 1 レプリカ確認 | RDS 異リージョン Read Replica |
同期 vs 非同期のトレードオフ
同期レプリケーション は RPO=0 を保証しますが、レイテンシが大きくなります。 非同期レプリケーション はレイテンシ小ですが、障害時にデータロード可能性。 「RPO 0 が必要か、レイテンシ優先か」が SAP の設計判断です。
Route 53 によるマルチリージョンフェイルオーバー
Route 53 の フェイルオーバールーティング でマルチリージョン切替を実現します。
Route 53: example.com
├── プライマリ: 東京 ALB (ヘルスチェック Green)
└── セカンダリ: バージニア ALB (フェイルオーバー時)- ヘルスチェック: プライマリ ALB の死活監視
- フェイルオーバー: プライマリ異常でセカンダリへ DNS 切替
- TTL: 短く設定（60 秒以下）で切替を高速化
DNS フェイルオーバーの遅延
Route 53 のフェイルオーバーは DNS キャッシュの影響 を受けます。 クライアントが古い IP をキャッシュしていると、TTL が切れるまで古い側にアクセスし続けます。 「TTL を短く」「アプリ側でもリトライ設計」が SAP の定石です。
ステートフルアプリのマルチリージョン課題
ステートフルアプリ（セッションをサーバーで保持）はマルチリージョンが複雑です。
| 要件 | 解決策 | 設計論点 |
|---|---|---|
| セッション共有 | ElastiCache (Redis Global Datastore) | セッションのリージョン間同期 |
| ファイル共有 | S3 (クロスリージョンレプリケーション) | 静的ファイルの同期 |
| DB 一貫性 | Aurora Global DB / DynamoDB Global Table | データベースの非同期同期 |
ステートレス化の推奨
SAP では 「アプリをステートレス化 → セッションを外部ストレージに分離」 を推奨します。 ステートレスなアプリはマルチAZ / マルチリージョンどちらでもスケールしやすく、 フェイルオーバーも単純です。これが SAP の基本姿勢です。
コストと可用性のバランス
マルチリージョンはコストが高いので、層別で可用性レベルを変える のが SAP の定石です。
| 層 | 可用性レベル | アーキテクチャ | コスト |
|---|---|---|---|
| ミッションクリティカル | マルチリージョン | アクティブ・アクティブ or パッシブ | 高 |
| 業務クリティカル | マルチAZ | 複数 AZ + RDS Multi-AZ | 中 |
| 一般業務 | 単一 AZ + バックアップ | 定期バックアップで DR | 低 |
層別設計の論点
「全アプリをマルチリージョン」にするとコストが膨張 します。 SAP では ビジネスインパクトに応じて可用性レベルを層別 し、 ミッションクリティカルだけマルチリージョン、他はマルチAZ、という判断が定石です。
制約と考慮事項
| 項目 | 制約 |
|---|---|
| AZ 数 | リージョンごとに 2〜6 |
| リージョン間レイテンシ | 数十ms〜（地理的距離依存） |
| リージョン間データ転送 | 有料 |
| DynamoDB Global Table | 数秒のレプリケーション遅延 |
| Aurora Global DB | 通常 1 秒未満の遅延 |
まとめ
- SAA: マルチAZ（リージョン内高可用性）とマルチリージョン（DR）の階層関係、 RDS Multi-AZ は同期レプリケーション、を理解する。
- SAP: 全層マルチAZ、クロスゾーン負荷分散、マルチリージョンのアクティブ・アクティブ vs パッシブ、レプリケーション方式、層別可用性設計が求められる。
次は ディザスタリカバリ 4 パターン比較 で、DR 戦略の全体像を学びましょう。