Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
SLAを満たすディザスタリカバリ(DR)構成 〜東京-大阪リージョン間の切り替え設計〜
Search
Sugita
December 18, 2025
0
200
SLAを満たすディザスタリカバリ(DR)構成 〜東京-大阪リージョン間の切り替え設計〜
Sugita
December 18, 2025
Tweet
Share
More Decks by Sugita
See All by Sugita
SLAチェックしてみたら…マルチAZ未対応!? その改善プロセス
sugitaseiya
0
850
Featured
See All Featured
How to build an LLM SEO readiness audit: a practical framework
nmsamuel
1
610
The Limits of Empathy - UXLibs8
cassininazir
1
200
Fight the Zombie Pattern Library - RWD Summit 2016
marcelosomers
234
17k
Learning to Love Humans: Emotional Interface Design
aarron
274
41k
Design and Strategy: How to Deal with People Who Don’t "Get" Design
morganepeng
133
19k
Are puppies a ranking factor?
jonoalderson
0
2.6k
Visual Storytelling: How to be a Superhuman Communicator
reverentgeek
2
410
Information Architects: The Missing Link in Design Systems
soysaucechin
0
740
GraphQLの誤解/rethinking-graphql
sonatard
74
11k
Building an army of robots
kneath
306
46k
jQuery: Nuts, Bolts and Bling
dougneiner
65
8.4k
[RailsConf 2023 Opening Keynote] The Magic of Rails
eileencodes
31
9.8k
Transcript
SLAを満たすディザスタリカバリ(DR)構成 〜東京-大阪リージョン間の切り替え設計〜 ENECHANGE株式会社 杉田 青哉 2025.12.18 ゆるSRE勉強会 #14 ゆるSRE忘年会 〜ゆるく
SREの話をしよう〜 https://yuru-sre.connpass.com/event/376206/
自己紹介 名前: 杉田 青哉 所属: ENECHANGE株式会社 SRE・infraチーム 技術スタック: AWS,Ruby 趣味:
イベント参加 SRE Kaigi / SRE NEXT / JAWS DAYS X: @Mnbvc124
今日話すこと ・SLAを満たすDR戦略の検討内容 ・採用した方式 ・運用で気をつけていること
SLA要件 大規模災害で東京リージョン全体に影響があった場合、大阪リージョンに3日以内に復旧させる 具体的には以下の指標 RTO (Recovery Time Objective) 3日 目標復旧時間 システムを復旧させるまでの時間
RPO (Recovery Point Objective) 1日 目標復旧時点 どの時点のデータまで復旧するか
インフラ構成( DR対応前) 東京リージョンのみで稼働 フロントエンド CloudFront + S3 バックエンド ALB +
ECS + RDS
DR戦略の4パターン バックアップ &リストア Backup and Restore 復旧時間 時間単位 コスト $
検討対象 パイロットライト Pilot Light 復旧時間 分単位 コスト $$ 検討対象 ウォームスタンバイ Warm Standby 復旧時間 秒単位 コスト $$$ オーバースペック ホットスタンバイ Hot Standby 復旧時間 リアルタイム コスト $$$$ オーバースペック RTO 3日の要件に対して、ウォームスタンバイ・ホットスタンバイはオーバースペック
バックアップ &リストア方式 通常時 ・S3 東京 → 大阪へクロスリージョンレプリケーション ・RDS 東京で取得したスナップショットを大阪リージョンへ定期コピー
バックアップ &リストア方式(異常時) 異常時の復旧手順 • RDSスナップショットからインスタンス立ち上げ • ALB・ECSを構築 • CloudFront・Route53の向き先を大阪リージョンに変更 ✓
メリット: コストが最も低い ✗ デメリット: 一から構築するため作業が多い
パイロットライト方式 通常時 ・S3 東京 → 大阪へクロスリージョンレプリケーション ・Aurora Global Database 東京–大阪間でデータを常時レプリケーション
(リアルタイム同期)
パイロットライト方式(異常時) 異常時の復旧手順 • ALB・ECSを構築 • CloudFront、Route53の向き先を大阪リージョンに変更 ✓ メリット: DBは常時同期されており、復旧が早い ✗
デメリット: 東京–大阪間の常時レプリケーションによりコストが高い
採用した方式 バックアップ &リストア 選定理由 RTO(3日)の要件を十分に満たしつつ、追加コストを最も低く抑えられる方式だったため。 実際の検証でも、約4時間で復旧できることを確認できた。
運用で気をつけていること 📄 ドキュメント整備 •復旧手順書の作成 •Terraformコードの整備 🔄 定期的な訓練 •DR訓練の実施 •手順書の有効性確認
まとめ 1. RTO 3日ならバックアップ&リストアで十分対応できた 2. バックアップ&リストアは作業が多いので、手順書化・復旧訓練が重要 今後の展望 AWS Fault
Injection Service(FIS)を活用して、より運用性を高めていきたいと考えています。