質問と範囲
リージョン全体の障害が発生した後に、単一リージョンのSaaSを復旧する設計を行います。ビジネス要件として、最大1時間のデータ損失（RPO）と4時間以内のサービス復旧（RTO）が求められています。ピーク時1,000リクエスト/秒は面接上の前提条件であり、測定された本番の実績ではないと仮定します。アプリケーションはステートレス、プライマリデータベースはリレーショナル、オブジェクトストレージにはユーザーのアップロードファイルが含まれます。
この設計では、データ、アプリケーションコード、構成、シークレット、ルーティング、および運用者のアクセス権限を復旧する必要があります。また、破損したプライマリが復旧リージョンに盲目的にコピーされるのを防ぐ必要があります。「バックアップがある」だけでは完全な回答ではありません。バックアップ頻度、復元時間、フェイルオーバーの権限、および訓練による実績証跡が目標と一致している必要があります。
面接官がテストしていること
システムデザイン面接ハンドブックでは、ディザスタリカバリを面接スタイルのRPO/RTO問題として位置づけており、明確な障害ドメイン、復旧の選択肢、および運用の実証を求めています。AWSはRPOとRTOをビジネスニーズによって設定される復旧目標と定義し、明確な戦略、テスト、構成ドリフト管理、および自動化を推奨しています。
優れた回答の特徴：
- RPOをレプリケーションまたはバックアップの頻度に変換し、遅延（lag）を測定する。
- RTOを復元、昇格、デプロイ、ルーティング、検証の各予算に変換する。
- データプレーンの復旧を、利用できなくなる可能性があるコントロールプレーンのアクションから切り離す。
- デフォルトでマルチリージョンと答えるのではなく、コストと目標に基づいてパイロットライト、ウォームスタンバイ、またはアクティブ/アクティブを選択する。
- 破損したデータや古い構成を含め、復元とフェイルオーバーをリハーサルする。
回答前の明確化のための質問
- RPOは決済、プロファイル、アップロードに一律で適用されますか？階層化（ティアリング）により、重要なレコードにはアナリティクスよりも厳しい目標を設定できます。
- 災害の原因はリージョンの喪失、不適切なデプロイ、それとも論理的な破損ですか？レプリケーションは最初のケースには有効ですが、2番目のケースをコピーしてしまう可能性があります。ロールバックにはポイントインタイムバックアップが必要です。
- フェイルオーバー中も書き込みを継続する必要がありますか？継続する場合は、書き込み権限と競合ポリシーを選択します。継続しない場合は、読み取り専用の復旧ウィンドウを設けることで整合性が単純化されます。
- 4時間のRTOは、ヘルスチェックの成功、顧客トラフィックの受信、それとも完全な機能パリティの達成のどれを基準に測定されますか？ランブックでマイルストーンを定義する必要があります。
- 復旧アカウントとコントロールプレーンは独立して操作できますか？事前プロビジョニングされたクォータ、認証情報、イメージ、およびDNSアクセスが、目標を達成できるかどうかを左右する可能性があります。
30秒の回答フレームワーク
「ワークロードを階層化し、ビジネスのRPO/RTOを測定可能にした上で、非同期のクロスリージョンデータベースおよびオブジェクトレプリケーションに加え、ポイントインタイムバックアップを採用します。復元と昇格が予算内に収まるなら、Infrastructure as Codeを備えたパイロットライトリージョンが4時間のRTOに適しています。ランブックに従って正常性が確認されているデータポイントを昇格させ、アプリケーションをデプロイし、ルーティングを切り替え、整合性チェックとスモークテストを実行し、ステータスを伝達します。四半期ごとの訓練で各ステップを測定し、バックアップの復元を検証し、構成ドリフトを検出し、測定された復旧時間が目標に収まらなくなった場合は目標を更新します。」
ステップバイステップの詳細な回答
1. 目標を復旧予算に落とし込む
RPO ≤ 1時間の場合、許容される最大レプリケーション遅延またはバックアップ間隔は1時間です。遅延が45分に近づいた場合など、その制限を下回るアラートを設定し、破損から復旧するためのポイントインタイムスナップショットを保持します。画一的なレプリケーション頻度を主張するのではなく、ソースのワークロードを測定してマージンを設定します。
RTO ≤ 4時間の場合、具体的な予算を割り当てます：検知と宣言、データ昇格、アプリケーションデプロイ、ルーティング、スモークテスト、および予備時間です。ランブックでデータベースの復元に20分、イメージのデプロイに30分、トラフィック切り替えに10分が必要とされる場合、これらは保証ではなく訓練で検証すべき前提条件です。
2. 復旧トポロジの選択
バックアップと復元は最も低コストですが、インフラの再構築が必要であり、通常はRTOが最も長くなります。パイロットライトは、アプリケーションのキャパシティをオフにしたまま、レプリケーションされたデータとコア復旧リソースを準備しておく構成であり、4時間の目標に対する合理的な出発点です。ウォームスタンバイは、縮小された機能スタックを実行し続けることで、より高いコストで復旧時間を短縮します。アクティブ/アクティブはフェイルオーバー時間を最小限に抑えますが、リージョンを跨ぐ書き込みの競合、トラフィックステアリングの複雑さ、および最大の運用対象面が加わります。
選択は目標に従います。ビジネス上の影響が正当化されない限り、4時間の目標に対してアクティブ/アクティブのコストを支払うべきではありません。デプロイの再現性を確保するために、Infrastructure as Code、コンテナイメージ、スキーマ、および構成を復旧アカウント内でバージョン管理します。
3. データの保護と復旧
リレーショナルデータベースの変更を別リージョンに非同期でレプリケーションし、遅延を監視します。ログ位置と整合性チェックがRPOを満たすレプリカのみを昇格させます。偶発的な削除、ランサムウェア、破損した書き込みに対処するため、不変（イミュータブル）なポイントインタイムバックアップを別のアカウントまたはリージョンに保存します。バージョニングを有効にしてオブジェクトデータをレプリケーションし、オブジェクト数とチェックサムを検証します。
ランブックには、選択した復旧タイムスタンプを記録し、必要に応じて書き込みを凍結またはドレインし、データストアを昇格させ、許容された書き込み損失があれば調整（リコンサイル）します。決済レコードでデータ損失ゼロが必要な場合は、別の階層と、場合によっては同期レプリケーションが必要です。1時間の目標がすべてのドメインをカバーすると主張してはなりません。
4. 提供パス（Serving Path）の復旧
不変のイメージとインフラストラクチャコードからアプリケーションをデプロイします。復旧リージョンにおいて、DNSまたはグローバルルーティングのヘルスチェック、シークレットアクセス、サービスクォータ、オブザーバビリティを事前作成しておきます。データベース接続、マイグレーション、認証、および代表的な読み取り/書き込みスモークテストが成功した後にのみ、トラフィックをルーティングします。
フェイルオーバーのコントロールパスは最小限に保ちます。AWSは、災害時にはコントロールプレーンの操作よりもデータプレーンの操作の方が通常可用性が高いと指摘しています。障害発生後にコントロールプレーンを介してすべてのリソースを作成することに依存する設計では、RTOを達成できない可能性があります。
5. ランブックを安全に実行できるようにする
誰が災害を宣言できるか、誰がデータを昇格させるか、誰がトラフィックを承認するかを定義します。各アクションに対する冪等なコマンド、停止条件、およびロールバックまたはフェイルバックプランを含む単調増加のステップログを使用します。ルーティング変更の前後で顧客向けステータスアップデートを公開します。復旧中、キャパシティが縮小されている場合は重要でない機能を無効にし、選択した復旧ポイントの監査証跡を保持します。
6. 訓練とメトリクスによる検証
スケジュールされた復元テスト、リージョン全体のゲームデー（game days）、および構成ドリフトチェックを実行します。検知、判断、復元、昇格、デプロイ、ルーティング、スモークテスト、安定化の所要時間を個別に測定します。復元された行数、チェックサム、権限、キュー、バックグラウンドジョブを検証します。失敗したバックアップ、古いシークレット、不十分なクォータ、部分的なレプリカ遅延を人為的に挿入します。それぞれがアクション可能なアラートまたは文書化された停止手順につながる必要があります。
受け入れテストの基準は証拠です。最新の訓練で測定されたRPOとRTO、未解決のギャップ、そして担当者です。復元を伴わないドキュメントは単なる仮説に過ぎません。
高品質な回答サンプル
「1時間のRPOと4時間のRTOに対しては、非同期のクロスリージョンデータベースおよびオブジェクトレプリケーション、不変のポイントインタイムバックアップ、そしてInfrastructure as Codeによって管理されるパイロットライトリージョンを採用します。検知、データ昇格、アプリケーションデプロイ、DNSまたはグローバルルーティング、スモークテストのための時間を確保し、四半期ごとの訓練でそれらの所要時間を実証します。フェイルオーバーのランブックでは、正常性が確認されている復旧ポイントを選択し、整合性チェックの後にのみ昇格させ、不変のイメージをデプロイし、認証と代表的な書き込みを検証してからトラフィックを切り替えます。プライマリに論理的な破損がある場合、レプリケーションだけでは安全ではないため、ランブックでは過去の時点に復元します。重要な決済データは、より厳密な目標を持つ別階層として扱います。測定された遅延、復旧時間、ドリフトの検出結果、および次の是正担当者を報告します。」
よくある間違い
- 目標を決めずに「マルチリージョン」と答える → コストと複雑さが無限に膨らむ → RPO/RTOおよびサービス階層からトポロジを導き出す。
- レプリケーションをバックアップとして扱う → 破損や削除が即座にレプリケーションされる可能性がある → 不変のポイントインタイムコピーを保持し、復元をテストする。
- コードと構成を無視する → 復旧されたデータがあってもそれを提供するスタックが存在しない → 復旧アカウント内でイメージ、スキーマ、シークレットアクセス、クォータ、IaCをバージョン管理する。
- DNSの変更を復旧完了とみなす → トラフィックが異常な、または未検証のシステムに到達する → 昇格、スモークテスト、安定化をRTOに含める。
- 利用不可能なコントロールプレーンに依存する → 障害発生中に自動化によってターゲットを作成できない → 重要な復旧リソースを事前プロビジョニングし、そのパスを訓練する。
- 訓練を一度も実施しない → バックアップ、クォータ、ランブックが陳腐化する可能性がある → 障害を挿入して復元とフェイルオーバーを定期的に測定する。
フォローアップ質問と回答
RPOがゼロの場合、何が変わりますか？
非同期レプリケーションでは目標を満たせなくなります。同期書き込み権限を定義するか、プロダクトレベルでの書き込み停止を受け入れる必要があります。その後、レイテンシ、クォーラム、リージョン分断時の動作を再評価します。
論理的な破損からどのように復旧しますか？
破損したレプリカの昇格を停止し、クリーンなポイントインタイムバックアップを特定し、分離された環境に復元して不変条件を検証し、承認された変更のみを再生（リプレイ）します。リージョンが健全であっても、データが健全であることの証明にはなりません。
なぜウォームスタンバイではなくパイロットライトを選ぶのですか？
デプロイとスケールアップの時間が測定されている場合、パイロットライトは定常コストを抑え、4時間の目標に適合します。ウォームスタンバイは、RTO予算がプロビジョニング時間を吸収できない場合や、縮小キャパシティでのトラフィック受付を即座に開始する必要がある場合に正当化されます。
構成ドリフトをどのように防ぎますか？
バージョン管理されたIaCから復旧リージョンをレンダリングし、期待されるリソースと観察されたリソースを比較し、イメージ、スキーマ、シークレット、クォータ、ルーティングの差異についてアラートを発し、すべての訓練にドリフトチェックを含めます。