PCA 架構之旅 12 — 災難復原 (DR)
第 11 步解決了「單 zone / 單 region 內元件壞掉」的問題。但 PCA 還會問你更殘酷的情境：整個 region 整天不見、光纖被挖斷、自然災害。這時候你靠的不是 autoscaling，而是 DR 計畫。
DR 的關鍵字就兩個：RTO 跟 RPO。能聽懂這兩個詞、能把它們翻成架構選擇，這一步的核心你就抓到了。
為什麼這一步重要
PCA case study 常用這類句子測試 DR 理解：
- 「主 region 失效後，服務必須在 1 小時內恢復」→ RTO
- 「最多可以接受遺失 15 分鐘的交易資料」→ RPO
- 「金流系統零資料遺失」→ RPO = 0（意味著同步複寫）
考生最常犯的錯誤：
- RTO 跟 RPO 搞混：RTO 是「多久能復原」、RPO 是「能容忍遺失多少資料」，兩個是獨立的目標
- RPO = 0 還選 Cloud SQL cross-region read replica：read replica 是非同步複寫，本質上有 lag，不可能 RPO = 0
- 把備份當 DR：備份是「資料救回來」，DR 是「服務跑起來」。光有備份沒有啟動流程也是失敗
核心概念
四種常見 DR 策略與對應的 RTO / RPO 區間（以登雲書店量級為例，實際數字依設計而定）：
| 策略 | RTO | RPO | 成本 | 何時選 |
|---|---|---|---|---|
| Backup & Restore | 小時到天 | 小時（看備份頻率） | 最低 | 非關鍵系統、預算有限 |
| Pilot Light | 數十分鐘 | 分鐘 | 中低 | DR region 只有核心元件，需要時放大 |
| Warm Standby | 分鐘 | 秒到分鐘 | 中高 | DR region 全副部署但低規模運行 |
| Multi-region Active-Active | 接近 0 | 接近 0 | 最高 | 金融、不能停機、全球低延遲 |
PCA 一定要記住的兩個定義：
- RTO（Recovery Time Objective）：從災難發生到服務恢復的最長可容忍時間
- RPO（Recovery Point Objective）：災難發生時最多可容忍遺失的資料時間窗
GCP 上的 DR 主力工具：
- Cloud Storage 跨 region 複製（dual-region、multi-region bucket）
- Cloud SQL cross-region read replica（非同步）或升級到 Spanner（跨 region 同步複寫）
- Spanner 多 region instance（同步複寫、全球單一邏輯資料庫，寫入經單一 leader region 協調，可做到跨 region 讀寫高可用）
- Cloud DNS failover routing policy（自動切 DR region 的 LB）
- Persistent Disk snapshot 跨 region（multi-regional snapshot）
思考框架
DR 決策按這個順序問：
- 業務能忍受多長的停機？ → 決定 RTO → 反推 DR 策略
- 資料遺失多少會造成法律 / 財務衝擊？ → 決定 RPO → 反推複寫方式
- 預算有多少？ → Active-Active 最貴（等同蓋兩套）、Backup & Restore 最便宜
- 有沒有法規要求地理分離？ → 個資法、GDPR 可能要求 DR 跨國或跨大陸
- DR 演練多久做一次？ → 沒演練過的 DR 計畫等同沒有，考題常考這點
走一遍範例 — 登雲書店
登雲書店不同模組的 DR 目標不一樣，要分層處理：
金流與訂單（極關鍵）
- 目標：RTO < 15 分鐘、RPO ≈ 0
- 策略：Multi-region Active-Active 或接近的方案
- 實作：Spanner 配置
nam-eur-asia1（多 region），訂單服務部署在兩個 region，Global LB 自動路由 - 成本取捨：貴，但符合金流不能遺失的要求
會員資料（關鍵）
- 目標：RTO < 1 小時、RPO < 5 分鐘
- 策略：Warm Standby
- 實作：Cloud SQL PostgreSQL HA 在
asia-east1，另加一個 cross-region read replica 在asia-northeast1。DR 啟動時 promote replica 成新 primary - 關鍵檢核：每季演練一次 failover，驗證 RTO 真的達標
商品圖片與靜態資源
- 目標：RTO ≈ 0、RPO < 15 分鐘（需啟用 turbo replication）
- 策略：dual-region Cloud Storage bucket
- 實作：bucket location 設為 configurable dual-region（asia-east1 彰化 + asia-northeast1 東京，而非預定義的
asia1，因為asia1實際是 asia-northeast1 東京 + asia-northeast2 大阪），並啟用 turbo replication 以取得 15 分鐘 RPO（SLA 保證）；未啟用時預設複寫 RPO 為 12 小時（通常 1 小時內完成），自動雙向複寫
瀏覽紀錄（非關鍵）
- 目標：RTO < 24 小時、RPO < 4 小時
- 策略：Backup & Restore
- 實作：Bigtable 每 4 小時 export 到 GCS multi-region bucket。災難時重建 Bigtable cluster，從最近的 backup 匯入
- 理由：瀏覽紀錄失去幾小時不影響核心業務，不值得花 active-active 的錢
流量切換機制
- Cloud DNS 設 failover routing policy，health check 連到
asia-east1的 Global LB - DR region 的 Global LB 平時關閉，DR 演練時手動啟用或用 Terraform 快速布建（pilot light 概念）
PCA 實務題常問這一點：「商品圖片的 dual-region bucket，如果 asia-east1 掛了，讀寫會怎樣？」答案：讀會自動切到另一個 region 的副本；寫會暫時失敗，等到 Google 把 bucket 的 metadata primary 切換（通常是分鐘級）才恢復。這裡要注意，dual-region 的複寫是非同步的。RTO 趨近於 0，因為已複寫的資料在區域故障時還讀得到；但 RPO 沒辦法接近 0，區域一掛，那些還沒複寫完的資料就遺失了。遺失窗口看你有沒有開 turbo replication：預設最壞是 12 小時、99.9% 物件 1 小時內；turbo 則是 15 分鐘 SLA。所以真要做到 RPO < 1 分鐘，光靠 dual-region 預設複寫是不夠的，得另外評估同步機制。
常見陷阱
- 把備份放在同一個 region：備份在
asia-east1的 bucket，asia-east1整個 region 掛了，備份跟著消失。DR 用的備份必須放 multi-region 或 dual-region bucket，或複製到另一個 region。 - 忽略 DR 演練：考試會問「你怎麼確認 DR 計畫有用？」答案是定期演練（game day），通常每季或每半年一次。寫在文件裡的 RTO 沒演練過，災難時通常會失敗。
- 跨 region 同步 = 零成本延遲：Spanner 跨 region 寫入需要 Paxos 多數派投票，單筆寫入延遲會從個位數 ms 變成數十 ms。必須在應用端評估這個延遲是否可接受。
延伸閱讀
系列導航
- 系列首頁：PCA 架構之旅
- 上一篇：PCA 架構之旅 11 — 可靠性與擴展性
- 下一篇：PCA 架構之旅 13 — 安全與成本
🎯 換你練習
理論讀完，換自己來。到 架構師設計工作坊 · 步驟 12 填入你的 case study，邊寫邊內化。