導入
RTO/RPOの目標値が決まったら、それを満たす最も安い戦略を選びます。AWSのDR戦略は大きく4段階に分かれており、段階が上がるほど復旧は速くなりますが、その分コストも跳ね上がります。
説明
代表的な4つのDR戦略を、待機系の「温め具合」が低い順に並べます。
| 戦略 | 概要 | RTO | RPO | コスト |
|---|---|---|---|---|
| バックアップ&リストア | バックアップだけ取得し、災害時に一から環境を作る | 数時間〜1日 | 数時間 | 最も低い |
| パイロットライト | コア（DBなど）だけ最小構成で常時稼働、他は停止 | 数十分 | 数分 | 低〜中 |
| ウォームスタンバイ | 縮小版のフルスタックを常時稼働、災害時にスケールアップ | 数分 | 秒〜数分 | 中〜高 |
| マルチサイト（アクティブ-アクティブ） | 複数リージョンで本番同等の構成を常時稼働 | ほぼゼロ | ほぼゼロ | 最も高い |
flowchart LR
S1["バックアップ&リストア<br/>RTO:大 コスト:小"] --> S2["パイロットライト"] --> S3["ウォームスタンバイ"] --> S4["マルチサイト<br/>RTO:小 コスト:大"]
それぞれの実装イメージは次の通りです。
- バックアップ&リストア: AWS BackupやS3にバックアップを保存するだけ。復旧時にCloudFormation等でインフラを作り直す。
- パイロットライト: DRリージョンにDB（例: Auroraのリードレプリカ）だけ稼働させ、APサーバーはAMIやテンプレートを用意して停止しておく。災害時に起動する。
- ウォームスタンバイ: DRリージョンに最小台数のAPサーバー・DBを常時稼働。災害時はAuto Scalingでフル規模へ拡張し、Route 53でトラフィックを向ける。
- マルチサイト（アクティブ-アクティブ）: 両リージョンが常時本番トラフィックを受け、片方が落ちてももう片方がそのまま引き受ける。Aurora Global DatabaseやDynamoDB Global Tablesが前提になることが多い。
具体例
前レッスンで読み取ったRTO/RPOと予算から、4戦略を割り当てます。
| システム | 要件 | 選ぶ戦略 |
|---|---|---|
| 社内の勤怠システム | RTO翌営業日・RPO1日・とにかく安く | バックアップ&リストア |
| 中堅ECサイト | 予算は限られるが、コアDBだけは早く戻したい | パイロットライト（DBだけ常時稼働） |
| 大手予約サイト | 数分で復旧、データ損失は秒単位まで | ウォームスタンバイ（縮小版を常時稼働→スケールアップ） |
| 銀行の勘定系 | ダウンタイムほぼゼロ・予算は問わない | マルチサイト（アクティブ-アクティブ） |
ここでのSAPの鉄則が「RTOを満たす最も安い戦略を選ぶ」こと。予約サイトに「マルチサイト」を選べば要件は満たすが過剰投資でコスト最適化に反する。逆に勘定系に「パイロットライト」では復旧が間に合わない。「最もコスト効率よく、かつRTO◯分を満たす」と来たら、要件を満たすギリギリ手前の段が正解です。
読んでみよう
SAPの問題では「予算は限られているが、コアデータだけは早く戻したい」ならパイロットライト、「数分のダウンタイムも許容できない、かつ予算は問題にしない」ならマルチサイト、というように要件文の緩さ・厳しさで4段階のどこに落ちるかを判定させます。「最もコスト効率よく、かつRTO◯分を満たす」という問題は、4段階のうちRTOを満たす最も安い戦略を選ぶのが定石です。