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

Transcript

1. SLAを満たすディザスタリカバリ(DR)構成 〜東京-大阪リージョン間の切り替え設計〜 ENECHANGE株式会社 杉田 青哉 2025.12.18 ゆるSRE勉強会 #14 ゆるSRE忘年会 〜ゆるく SREの話をしよう〜 https://yuru-sre.connpass.com/event/376206/
2. 自己紹介 名前: 杉田 青哉 所属: ENECHANGE株式会社 SRE・infraチーム 技術スタック: AWS,Ruby 趣味: イベント参加 　　　SRE Kaigi / SRE NEXT / JAWS DAYS X: @Mnbvc124
3. 今日話すこと ・SLAを満たすDR戦略の検討内容 ・採用した方式 ・運用で気をつけていること
4. SLA要件 大規模災害で東京リージョン全体に影響があった場合、大阪リージョンに3日以内に復旧させる 具体的には以下の指標 RTO (Recovery Time Objective) 3日 目標復旧時間 システムを復旧させるまでの時間 RPO (Recovery Point Objective) 1日 目標復旧時点 どの時点のデータまで復旧するか
5. インフラ構成（ DR対応前） 東京リージョンのみで稼働 フロントエンド CloudFront + S3 バックエンド ALB + ECS + RDS
6. DR戦略の4パターン バックアップ &リストア Backup and Restore 復旧時間 時間単位 コスト $ 検討対象 パイロットライト Pilot Light 復旧時間 分単位 コスト $$ 検討対象 ウォームスタンバイ Warm Standby 復旧時間 秒単位 コスト $$$ オーバースペック ホットスタンバイ Hot Standby 復旧時間 リアルタイム コスト $$$$ オーバースペック RTO 3日の要件に対して、ウォームスタンバイ・ホットスタンバイはオーバースペック
7. バックアップ &リストア方式 通常時 ・S3 東京 → 大阪へクロスリージョンレプリケーション ・RDS 東京で取得したスナップショットを大阪リージョンへ定期コピー
8. バックアップ &リストア方式（異常時） 異常時の復旧手順 • RDSスナップショットからインスタンス立ち上げ • ALB・ECSを構築 • CloudFront・Route53の向き先を大阪リージョンに変更 ✓ メリット: コストが最も低い ✗ デメリット: 一から構築するため作業が多い
9. パイロットライト方式 通常時 ・S3 東京 → 大阪へクロスリージョンレプリケーション ・Aurora Global Database 東京–大阪間でデータを常時レプリケーション （リアルタイム同期）
10. パイロットライト方式（異常時） 異常時の復旧手順 • ALB・ECSを構築 • CloudFront、Route53の向き先を大阪リージョンに変更 ✓ メリット: DBは常時同期されており、復旧が早い ✗ デメリット: 東京–大阪間の常時レプリケーションによりコストが高い
11. 採用した方式 バックアップ &リストア 選定理由 RTO（3日）の要件を十分に満たしつつ、追加コストを最も低く抑えられる方式だったため。 実際の検証でも、約4時間で復旧できることを確認できた。
12. 運用で気をつけていること 📄 ドキュメント整備 •復旧手順書の作成 •Terraformコードの整備 🔄 定期的な訓練 •DR訓練の実施 •手順書の有効性確認
13. まとめ 1. RTO 3日ならバックアップ&リストアで十分対応できた 2. バックアップ&リストアは作業が多いので、手順書化・復旧訓練が重要 
 今後の展望 AWS Fault Injection Service（FIS）を活用して、より運用性を高めていきたいと考えています。