PCA 架構之旅 11 — 可靠性與擴展性
PCA
拓樸畫完，接下來要回答一個讓老闆睡得著覺的問題：這套架構撐得住嗎？
撐得住有兩個面向：可靠性（一台掛了還能跑）跟擴展性（流量暴增還能接）。這兩件事看起來不一樣，其實解法八九成都一樣：無狀態、多副本、自動化。
PCA 考題最愛用「雙 11 活動流量是平日 20 倍」或「機房整個跳電」這種劇本來試你。
為什麼這一步重要
PCA case study 裡，可靠性與擴展性通常藏在這類描述：
- 「SLA 99.95%、每月停機不得超過 22 分鐘」
- 「尖峰流量是平均的 10 倍、必須自動擴展」
- 「不允許單點故障、必須能承受單一 zone 失效」
考生常犯的錯誤：
- 把 HA 理解成「備份」：備份是資料保護，HA 是服務可用。兩個要一起做，但不是同一回事
- 無狀態應用還存 session 在本機：這會讓 autoscaling 變無效，因為新起的 instance 不認舊 session
- 只做區域 HA 不做 region HA：如果 SLA 寫 99.95%，單 region 的 Cloud SQL HA 可能剛好壓線；更嚴格的 SLA 必須跨 region
核心概念
四個維度思考韌性設計：
| 維度 | 目標 | 常用工具 |
|---|---|---|
| 高可用 (HA) | 單點掛掉不影響服務 | Regional MIG、Cloud SQL HA、GKE regional cluster |
| 自動擴展 (Autoscaling) | 流量變動自動加減 | MIG autoscaler、GKE HPA / VPA / Cluster Autoscaler、Cloud Run |
| 無狀態設計 (Stateless) | 任何實例都能接任何請求 | 外部 session store（Memorystore）、JWT、外部檔案存 GCS |
| 故障轉移 (Failover) | 主故障自動切備 | Cloud SQL failover、multi-region LB、DNS failover |
幾個 PCA 要記住的數字（SLA 換算月停機時間）：
- 99.9%（3 個 9）≈ 月停機 43 分鐘
- 99.95% ≈ 月停機 22 分鐘
- 99.99%（4 個 9）≈ 月停機 4 分鐘
SLA 要求越高，成本就翻得越兇，這個取捨我們留到第 13 步再談。
思考框架
針對每個關鍵元件，依序問：
- 單點故障在哪？ 列出所有 single point of failure（SPOF），至少要消除關鍵路徑的 SPOF
- 應用是有狀態還是無狀態？ 有狀態的先改無狀態；改不了的要規劃 sticky session 或外部 state
- autoscaling 的觸發指標是什麼？ CPU？QPS？自訂指標？冷啟動時間能接受嗎？
- 失效時切換時間多久？ 人手動切（分鐘）？自動切（秒）？不可切（0）？
- 擴展上限多高？ GCP 的 quota 你申請夠了嗎？（instance count、external IP、quota）
走一遍範例 — 登雲書店
登雲書店目標 SLA 99.95%，雙 11 流量會衝到平日 15 倍。對應設計：
前端（GKE regional cluster）
- Regional cluster 橫跨 3 個 zone，控制平面 HA 由 GCP 代管
- Pod 以 HPA 擴展，觸發條件：CPU > 60% OR 自訂 metric
requests_per_second > 80 - Cluster Autoscaler 自動加 node（上限 100 個 node，預先申請 quota）
- Pod 設
topologySpreadConstraints，分散到三個 zone，不讓單 zone 失效造成大範圍中斷
後端服務（Cloud Run）
- 無狀態設計，session 存 Memorystore for Redis
- Cloud Run min instances = 5（避免冷啟動）、max = 500
- 請求並發（concurrency）設 80，避免單 container 被打爆
資料庫（Cloud SQL for PostgreSQL）
- 啟用 HA（primary + standby，不同 zone），自動 failover
- 加 2 個 read replica 分散讀取
- 備份每日 + Point-in-Time Recovery（PITR）開啟 7 天
瀏覽紀錄（Bigtable）
- 單叢集 3 節點，CPU > 70% 自動加節點
- 關鍵時刻（雙 11 前三天）手動 pre-scale 到 6 節點，活動後縮回
流量進入層
- Global External Application LB，內建跨 region failover
- Cloud Armor 設 rate limit：單 IP 每分鐘 300 req，防爬蟲攻擊
- Cloud DNS A record TTL 設 60 秒（讓 DR 切換快）
一個關鍵取捨：Cloud SQL HA 的 standby 是 hot standby 但不能直接讀。如果想讓 standby 提供讀流量，要改用 read replica 或升級到 AlloyDB。PCA 考題會用這點試你有沒有搞懂 HA vs read scaling 的差別。
常見陷阱
- 把 session 存在 Pod 的記憶體裡：autoscaling 縮容時 session 跟著消失，用戶突然登出。正確做法：session 存 Memorystore，或用 JWT 放 cookie。
- 資料庫 connection pool 沒調：Cloud SQL 有連線數上限（依 tier 不同），幾百個 Pod 各開 pool 會打爆。要用 Cloud SQL Auth Proxy + 合理的
max_connections設定，或前面加 PgBouncer。 - autoscaler 反應不夠快：HPA 控制器預設每 15 秒同步一次指標、scale-up 預設無穩定視窗（0 秒）、scale-down 穩定視窗預設 300 秒，突發流量一來，前幾分鐘很容易被打爆。怎麼救：
min replicas設一個合理的底線、尖峰時段先預熱（pre-warm）、或改用 Cloud Run 這種冷啟動比較快的服務。
延伸閱讀
系列導航
- 系列首頁：PCA 架構之旅
- 上一篇：PCA 架構之旅 10 — 網路拓樸
- 下一篇：PCA 架構之旅 12 — 災難復原 (DR)
🎯 換你練習
理論讀完，換自己來。到 架構師設計工作坊 · 步驟 11 填入你的 case study，邊寫邊內化。
pca-architect-journey — 11/13 完成
查看系列全覽 →