AWS Certified Solutions Architect - Associate (SAA-C03) #7 Domain 2-2 回復力のあるアーキテクチャ — DR パターン

読了 5分

#6 で単一リージョン内の高可用性を押さえました。今回はもう一段大きな障害 — リージョン全体が麻痺する災害 — に備える 災害復旧 (Disaster Recovery, DR) 戦略を扱います。DR の設問は常に「どれだけ速く復旧する必要があり (RTO)、どれだけのデータ損失を許容できるか (RPO)」と「コストをどれだけかけるか」の綱引きです。

RTO と RPO #

この 2 つの指標を取り違えると、DR の設問をほぼ間違えます。

指標意味問い
RTO (Recovery Time Objective)復旧までにかかる 時間「障害後、何分/何時間以内に復旧すべきか」
RPO (Recovery Point Objective)許容できる データ損失量「最後のバックアップ以降、どれだけのデータを失ってよいか」

RTO は 時間 軸、RPO は データ (時点) 軸です。RPO が 5 分なら最大 5 分分のデータしか失ってはならないため、それだけ頻繁にレプリケーション・バックアップする必要があります。RTO が短いほど、あらかじめより多くのリソースを準備しておく必要があります。両方を小さくしようとするとコストが上がります。

4 つの DR 戦略 #

AWS の標準的な DR 戦略は、コストと復旧速度のトレードオフに応じて 4 段階に分かれます。上から下に行くほど コストは上がり、RTO/RPO は短くなります。

戦略平常時の状態RTO/RPOコスト
Backup & Restoreデータのみバックアップ最も長い (時間単位)最も安い
Pilot Light中核 (DB) のみ最小稼働短い (数十分)低い
Warm Standby縮小版の全体が常に稼働より短い (分単位)中程度
Multi-Site Active/Active両側がフル稼働ほぼ 0最も高い

1) Backup & Restore #

データをバックアップしておき、災害時にバックアップからインフラを新たに起動して復旧します。平常時はバックアップストレージのコストのみがかかります。最も安価ですが復旧に最も時間がかかります。「コストを最小化し、復旧時間が長くても構わない」という手がかりがあればこの戦略です。

2) Pilot Light #

エンジンの点火用の種火のように、中核要素 (主にデータベース) のみを常にレプリケーションして起動しておき、残り (アプリケーションサーバーなど) はオフにしておきます。災害時にオフにしておいた部分を素早く起動します。DB がすでに最新なので、Backup & Restore より RPO・RTO が短くなります。

3) Warm Standby #

縮小された規模の全体環境が常に稼働しています。 災害時にその環境をプロダクション規模に 拡張 (scale up) するだけで済みます。Pilot Light が「中核のみ起動して残りはオフ」なら、Warm Standby は「全体を小さくても起動しておく」です。その分だけ速く、より高価です。

4) Multi-Site Active/Active (Hot Standby) #

両方のリージョンにプロダクション規模が同時に稼働しており、実際のトラフィックを分けて受けます。片方のリージョンが死んでも、もう片方が即座にすべてを受けるため、RTO/RPO がほぼ 0 です。最も高価ですが無停止に近いです。

クロスリージョン実装手段 #

DR 戦略を実際に構成する AWS の機能群です。

  • Route 53 Failover ルーティング — ヘルスチェックでプライマリ (primary) リージョンの障害を検知し、セカンダリ (secondary) リージョンへ DNS を切り替えます。DR 自動切り替えの標準です。
  • RDS クロスリージョンリードレプリカ — 別のリージョンにリードレプリカを置き、災害時に昇格 (promote) します。
  • Aurora Global Database — 複数のリージョンに 1 秒未満の遅延でレプリケーション。リージョン障害時に高速に昇格。
  • DynamoDB グローバルテーブル — マルチリージョン active/active レプリケーション。Multi-Site パターンに適しています。
  • S3 クロスリージョンレプリケーション (CRR) — オブジェクトを別のリージョンのバケットへ自動レプリケーション。

「リージョン障害時に 自動的に 別のリージョンへ切り替える」という要件であれば、Route 53 Failover + クロスリージョンレプリケーションの組み合わせが答えです。

試験の出題パターン #

  • コスト最小、復旧時間が長くてもよい」 → Backup & Restore
  • DB は常にレプリケーション、アプリサーバーは災害時に起動」 → Pilot Light
  • 縮小版の全体 が起動しており、災害時に拡張」 → Warm Standby
  • ほぼ無停止、コスト無関係、RTO/RPO≈0」 → Multi-Site Active/Active
  • 「リージョン障害時に 自動 DNS 切り替え」 → Route 53 Failover ルーティング
  • 「マルチリージョン active/active DB」 → DynamoDB グローバルテーブル / Aurora Global
  • 「RTO と RPO のうち データ損失量 は?」 → RPO

よく出会う落とし穴 #

1) RTO と RPO を入れ替えて考える #

RTO は 時間、RPO は データ損失 (時点) です。「最大何分分のデータを失ってよいか」は RPO です。

2) Pilot Light と Warm Standby を混同する #

Pilot Light は 中核 (DB) のみ 起動して残りはオフにします。Warm Standby は 全体を縮小規模で 常に起動します。

3) すべてのシステムに Multi-Site を勧める #

Multi-Site は最も高価です。要件が「コスト最小」や「復旧時間に余裕あり」であれば過剰な設計です。RTO/RPO の要求に 見合った最小コスト 戦略を選ぶべきです。

4) Route 53 なしで自動切り替えを期待する #

クロスリージョンの自動フェイルオーバーは通常 Route 53 ヘルスチェック + Failover ルーティングが担当します。

まとめ #

今回の記事で押さえたこと:

  • RTO=復旧時間、RPO=データ損失量。両方を小さくするとコスト上昇
  • 4 つの戦略 — Backup & Restore (安価・遅い) → Pilot Light (中核のみ) → Warm Standby (縮小版の全体) → Multi-Site (フル稼働・無停止)
  • 要求された RTO/RPO に 見合った最小コスト戦略を選択することが正解の核心
  • クロスリージョン — Route 53 Failover + RDS クロスレプリケーション / Aurora Global / DynamoDB グローバルテーブル / S3 CRR

次回 — Domain 2-3 バックアップ戦略 #

DR 戦略の土台は結局 信頼できるバックアップです。回復力ドメインの最後としてバックアップを扱います。

#8 Domain 2-3 バックアップ戦略 では、EBS スナップショット (増分・クロスリージョンコピー) と Data Lifecycle Manager、RDS の自動バックアップとポイントインタイムリカバリ (PITR)、そして複数のサービスのバックアップを中央で管理する AWS Backup と不変バックアップ (Vault Lock) まで整理します。

X