ENECHANGE Developer Blog

ENECHANGE開発者ブログ

SLA要件を満たすディザスタリカバリ構成 —— 東京-大阪リージョン間の切り替え設計

ENECHANGE SREチームの杉田 青哉です。

今回は、SLA要件を満たすために実施したマルチリージョンでのディザスタリカバリ対応について紹介します。 東京リージョンで運用しているシステムを、障害時に大阪リージョンへ切り替える構成を構築しました。 戦略の選定から実装、運用まで、実際に取り組んだ内容をお伝えします。

はじめに

SLAとは？

SLA（Service Level Agreement）とは、サービス提供者と利用者の間で合意されるサービスレベルに関する契約のことです。 システムの可用性や復旧時間など、具体的な数値目標を定めることで、サービス品質を保証します。

今回のSLA要件

今回、私たちのプロダクトでは以下のSLA要件が設定されました。

大規模災害で東京リージョン全体に影響があった場合、大阪リージョンに3日以内に復旧させる

具体的には以下の指標です。

  • RTO（Recovery Time Objective：目標復旧時間）: 3日

  • RPO（Recovery Point Objective：目標復旧時点）: 1日

この要件を満たすために、東京リージョンから大阪リージョンへの構成を検討・実装することになりました。

インフラ構成

ディザスタリカバリ対応前のインフラ構成はこちらです。

  • フロントエンド: CloudFront、S3
  • バックエンド: ALB、ECS、RDS

DR（Disaster Recovery）戦略の4パターン

災害や障害発生時にシステムを迅速に復旧させるための設計方針として、AWS Well-Architected Frameworkなどでも定義されている4つの戦略を、復旧時間・コストの観点から比較すると以下のようになります。 RTO/RPOが短いほど即時復旧できますが、その分コストが増大します。 下の表は、復旧時間とコストのバランスを視覚的に整理したものです。 docs.aws.amazon.com

DR戦略 復旧時間(RPO/RTO) コスト
バックアップ&リストア 時間単位 $
パイロットライト 分単位 $$
ウォームスタンバイ 秒単位 $$$
ホットスタンバイ リアルタイム $$$$

今回は、この中からバックアップ&リストアとパイロットライトの2つの方式を検討しました。ウォームスタンバイとホットスタンバイは、RTO要件（3日）に対してオーバースペックであり、コストも高額になるため、選択肢から除外しました。

バックアップ&リストア

通常時の構成

東京リージョンのみで稼働し、大阪リージョンへ定期的にバックアップを取得します。

  • S3: クロスリージョンレプリケーションで大阪リージョンへ自動バックアップ
  • RDS: 毎日スナップショットを取得し、大阪リージョンへ保存 　

異常時の復旧手順

大阪リージョンでリソースを再構築します。

  1. RDSスナップショットからRDSインスタンス立ち上げ
  2. ALB、ECSを構築
  3. CloudFront、Route53の向き先を大阪リージョンに変更 　

メリット

  • ✅ コストが最も低い: バックアップストレージのみで、大阪リージョンでのリソース稼働コストがかからない

デメリット

  • ❌ 復旧に時間がかかる: RDSのスナップショットからの復元に時間を要する

  • ❌ 手動作業が多い: ALB・ECSの構築など、復旧時に手動作業が多い

パイロットライト

通常時の構成

大阪リージョンですぐに復旧できるようにAuroraグローバルデータベースを構築し、ALB・ECSは未構築状態で待機します。

  • Aurora Global Database: 東京リージョンから大阪リージョンへリアルタイムレプリケーション
  • S3: クロスリージョンレプリケーションで自動同期
  • ALB・ECS: 未構築 　

異常時の復旧手順

  1. ALB、ECSを構築
  2. CloudFront、Route53の向き先を大阪リージョンに変更

　

メリット

  • ✅ 復旧時間が短い: バックアップ&リストアより復旧時間が短い

  • ✅ 手動作業を抑えられる: ALB、ECS構築するだけで済む

デメリット

  • ❌ コストが高い: バックアップ&リストアよりコストが高くなる

最終的な選択：バックアップ&リストア

RTO（3日）を問題なく満たしつつ、追加コストを最小限に抑えられることが確認できたため、バックアップ & リストア方式を採用することにしました。

運用面での工夫

実際の災害時に確実に復旧できるよう、以下の観点で運用面でも様々な工夫を行いました。

手順書の整備

災害発生時に復旧作業を確実に再現できることと、担当者に関わらず一定の品質で対応できることを目的として、復旧手順書を整備しました。

復旧訓練の実施

手順書が整備されていても、実際に作業を行えなければ復旧は確実に行えないため、復旧手順書の有効性を確認することを目的として、定期的に復旧訓練を実施しています。 訓練ではまず、手順書を読みながら作業内容を確認するドライランを行い、その後ステージング環境を用いて大阪リージョンへの切り替えを試行します。 最後に振り返りを行い、発見した課題や改善点を手順書に反映することで、復旧作業の精度と再現性を高めています。

まとめ

  • RTO 3日ならバックアップ&リストアで十分対応できた
  • バックアップ&リストアは手動作業が多いので、手順書化・復旧訓練が重要
  • DR設計は構築だけでなく、継続的な検証と改善が信頼性を高める鍵

今後は、AWS Fault Injection Service（FIS）を活用して、より運用性を高めていきたいと考えています。 aws.amazon.com