はじめに
データセンター全体に問題 (停電、自然災害、ネットワーク停止) が発生した場合、リージョン内の高可用性だけでは十分ではありません。 災害復旧 (DR) は、システムが致命的な障害から確実に回復できるようにします。
1. RPO と RTO
RPO (Recovery Point Objective):
"Mất tối đa bao nhiêu data có thể chấp nhận?"
RPO = 1 giờ → Backup mỗi giờ → Mất tối đa 1 giờ data
RPO = 0 → Synchronous replication → Không mất data
RTO (Recovery Time Objective):
"Hệ thống phải recovery trong bao lâu?"
RTO = 4 giờ → Có 4 giờ để khôi phục
RTO = 0 → Instant failover (Active-Active)
Timeline:
◄──── RPO ────► ◄──── RTO ────►
Last backup Disaster Start Recovered
│ │ Recovery │
────┼──────────────┼───────┼─────────────────┼────
▲ ▲ ▲ ▲
Data preserved Data lost Downtime Back online
2. DR 戦略
2.1 バックアップと復元
┌──────────────┐ ┌──────────────┐
│ Primary │ backup │ S3/GCS │
│ Region │────────►│ (cold store) │
│ (running) │ └──────┬───────┘
└──────────────┘ │ restore
┌─────▼────────┐
│ DR Region │
│ (provisioned │
│ on demand) │
└──────────────┘
RPO: Hours (last backup)
RTO: Hours (provision + restore)
Cost: $ (chỉ trả storage)
Use case: Non-critical systems, dev/staging
2.2 パイロットライト
┌──────────────┐ ┌──────────────┐
│ Primary │ replica │ DR Region │
│ Region │────────►│ │
│ App servers │ │ DB Replica │ ← chạy sẵn
│ DB Primary │ │ (no app) │
│ Cache │ │ │
└──────────────┘ └──────────────┘
Disaster → Scale up DR:
1. Promote DB replica → Primary
2. Launch app servers (AMI/container)
3. Update DNS → DR region
RPO: Minutes (async replication)
RTO: 10-30 minutes
Cost: $$ (DB replica running)
2.3 ウォームスタンバイ
┌──────────────┐ ┌──────────────┐
│ Primary │ replica │ DR Region │
│ Region │────────►│ │
│ App × 10 │ │ App × 2 │ ← scaled down
│ DB Primary │ │ DB Replica │
│ Cache │ │ Cache │
└──────────────┘ └──────────────┘
Disaster → Scale up DR:
1. Scale app 2 → 10
2. Promote DB
3. Switch traffic
RPO: Seconds-minutes
RTO: Minutes
Cost: $$$ (minimal infra running)
2.4 マルチサイトのアクティブ/アクティブ
┌──────────────┐ ┌──────────────┐
│ Region A │◄───────►│ Region B │
│ App × 10 │ sync │ App × 10 │
│ DB Primary │ │ DB Primary │
│ Full traffic │ │ Full traffic │
└──────────────┘ └──────────────┘
▲ ▲
└────── Global LB ──────┘
(GeoDNS/Anycast)
RPO: 0 (synchronous) hoặc seconds (async)
RTO: 0 (automatic failover)
Cost: $$$$ (2x infrastructure)
Use case: Mission-critical, global services
2.5 比較
| 戦略 | RPO | RTO | コスト | 複雑さ |
|---|---|---|---|---|
| バックアップと復元 | 営業時間 | 営業時間 | $ | 低い |
| パイロットライト | 分 | 10～30分 | $$ | 中 |
| ウォームスタンバイ | 秒 | 分 | $$$ | 高 |
| アクティブ-アクティブ | ~0 | ~0 | $$$$ | 非常に高い |
3. マルチリージョンデータの課題
3.1 データのレプリケーション
Synchronous:
Region A write → Wait for Region B confirm → Return
✅ Strong consistency (RPO=0)
❌ Latency tăng (cross-region: 50-200ms)
❌ Region B down → Region A blocked
Asynchronous:
Region A write → Return immediately
Region A → replicate to Region B (background)
✅ Nhanh, Region B down không ảnh hưởng
❌ Replication lag → Data inconsistency
❌ RPO > 0 (có thể mất data)
Conflict Resolution (Active-Active):
Region A: UPDATE user SET name='Alice'
Region B: UPDATE user SET name='Bob' (cùng lúc)
→ Conflict! Giải quyết bằng:
- Last-Writer-Wins (LWW)
- Application-level merge
- CRDTs
3.2 グローバル負荷分散
GeoDNS:
User ở Vietnam → DNS trả IP Region Asia
User ở US → DNS trả IP Region US
user.example.com
├── Vietnam user → 10.0.1.1 (Asia region)
├── US user → 10.0.2.1 (US region)
└── EU user → 10.0.3.1 (EU region)
Anycast:
Cùng 1 IP, nhiều locations
BGP routing → nearest location
Dùng cho CDN, DNS servers
Latency-based:
AWS Route 53: Route to region có latency thấp nhất
Health check: Nếu region down → route sang region khác
4. DR テスト
1. Tabletop Exercise (hàng quý):
Team ngồi lại, giả lập scenario trên giấy
"Database chính bị corrupt, phải làm gì?"
Lên plan, identify gaps
2. Failover Test (hàng quý-năm):
Thực sự failover sang DR region
Verify data integrity
Measure actual RTO
3. Chaos Day (hàng tháng):
Inject failures vào production
Kill processes, add latency
Netflix "Chaos Monkey" style
4. Backup Restore Test (hàng tháng):
Restore backup to new environment
Verify data completeness
Measure restore time
5. DR ランブック テンプレート
# Runbook: Database Failover
## Trigger Conditions
- Primary DB unreachable > 5 minutes
- Data corruption detected
- Region-level outage declared
## Pre-Checks
□ Verify primary is actually down (not network issue)
□ Check replica lag (pg_stat_replication)
□ Notify on-call team lead
## Failover Steps
1. Stop writes to primary (if accessible)
2. Verify replica is caught up
3. Promote replica: SELECT pg_promote()
4. Update connection strings (DNS/config)
5. Verify app connects to new primary
6. Monitor error rates for 15 minutes
## Post-Failover
□ Notify stakeholders
□ Update status page
□ Create incident ticket
□ Plan for original primary recovery
□ Post-mortem within 48 hours
## Rollback Plan
If failover fails:
1. Restore from latest backup
2. Point apps to restored DB
3. Accept data loss from RPO gap
概要
| 決定 | 要因 |
|---|---|
| RPO の選択 | データの重要性、コンプライアンス、コスト |
| RTO の選択 | ダウンタイム 1 分あたりのビジネスへの影響 |
| DR戦略 | 予算、RPO/RTO 要件 |
| 地域 | ユーザーの場所、コンプライアンス、遅延 |
| テスト | 頻度は重要度に一致します |
演習
-
DR 戦略の選択: フィンテック アプリ: トランザクション、ユーザー残高、コンプライアンス レポート。ダウンタイム > 30 分 = 規制違反。 RPO = 0、RTO < 5 分。予算: DR に月額 50,000 ドル。どの DR 戦略を選択しますか?
-
マルチリージョンデザイン: 東南アジア向けのソーシャルメディアアプリ。ベトナム (60%)、インドネシア (20%)、フィリピン (10%)、その他 (10%) のユーザー。マルチリージョン アーキテクチャを設計します。どのデータがレプリケートされ、どのデータがリージョンごとにシャーディングされますか?
-
DR ランブック: シナリオの詳細な DR ランブックを作成します: AWS ap-southeast-1 (シンガポール) が完全に利用できない。システムには、EKS クラスター、RDS PostgreSQL、ElastiCache Redis、S3 が含まれます。 DR サイト: ap-northeast-1 (東京)。