PCA 雲端架構師之旅 11 — 可靠性與擴展性

拓樸圖畫完後，得用兩種情境檢查它：有一個元件故障時，服務能否繼續？流量突然增加時，容量能否跟上？

前者是可靠性，後者是擴展性。兩者常會用到無狀態服務、多副本和自動化，但驗證方式不同：故障測試要看切換後能否維持服務，壓力測試則要看延遲與錯誤率如何變化。

這是 PCA 雲端架構師之旅 的第十一步。下面會用尖峰流量與故障情境，檢查前面畫的架構是否真的撐得住。

可靠性跟擴展性，先把它們分清楚

「有備份」和「故障時服務還能繼續跑」是兩回事，先別把它們算成同一種保護。

備份處理的是資料保護：資料損毀或誤刪後，還能不能救回來。高可用（HA，High Availability）處理的是服務可用：某個節點或 zone 出問題時，服務能不能繼續提供。就算每天都有備份，也不代表故障當下能立刻接手流量。

擴展性（Scalability）則是另一條軸線：平常五台機器夠用，活動尖峰可能要五十台，之後還得縮回去。除了最高容量，也要估擴容速度與活動後的閒置成本。

設計時要同時看可靠性與擴展性，並對照題目給的可用性目標；能自動擴容的架構，不一定具備足夠的故障切換能力。

flowchart TB
  P[系統問題或需求] --> Q{資料被刪除或損毀？}
  Q -- 是 --> B[備份與還原<br/>Data<br/>Protection]
  Q -- 否 --> F{元件故障時<br/>服務要不中斷？}
  F -- 是 --> H[高可用<br/>與 Failover]
  F -- 否 --> L{流量增加時<br/>容量要跟著成長？}
  L -- 是 --> S[Autoscaling<br/>與 Quota]
  L -- 否 --> R[重新確認<br/>使用者影響<br/>與 SLO]
  B --> V[各自驗證 RPO／RTO 或 SLI]
  H --> V
  S --> V

把可用性百分比換成停機時間

可用性百分比看起來差很小，換成每月可容忍的停機時間就比較容易討論：

• 99.9%（3 個 9）≈ 每月停機 43 分鐘
• 99.95% ≈ 每月停機 22 分鐘
• 99.99%（4 個 9）≈ 每月停機 4 分鐘

從 99.9% 到 99.99%，每月容許的停機時間大約從 43 分鐘縮到 4 分鐘。要達成更高目標，得檢查整條服務鏈如何偵測、切換與復原，而不只是增加某個資料庫的副本。第 13 步會再把這些設計的成本放進比較表。

📝 考場提點

先把目標換成可容忍的停機時間，再問設計能承受哪一層故障。單一區域內的 HA 可以處理某些 Zone 或執行個體故障，卻無法單靠自己應對整個區域失效。是否需要跨區域部署，還要看資料復原要求、流量切換時間和整體成本。

先處理狀態，再談自動擴縮

想讓應用實例能隨流量增加或減少，得先確認請求會不會依賴某一台實例保存的資料。

無狀態（stateless）的意思是，任何健康的實例都能接下一個請求，不必依賴上一個請求落在哪台機器。Session 和購物車可以放在共用的狀態儲存系統，上傳檔案可存到 Cloud Storage；認證方式則要另外評估安全與失效處理，不必把所有狀態硬塞進單一實例。

假設 session 只存在應用程式的本機記憶體。平常只有一台機器時看不出問題；擴容後，請求可能落到沒有該 session 的新實例；縮容時，原實例一停，使用者也可能被迫重新登入。這是狀態存放位置造成的，不是把 autoscaler 的門檻調高就能解決。

因此要連同狀態儲存一起設計擴縮策略。若舊系統短期內無法改造，可以先評估 sticky session，但也要說清楚實例故障或替換時如何處理既有連線與狀態。

sequenceDiagram
  participant U as User
  participant L as Load Balancer
  participant A as App Replica A
  participant B as App Replica B
  participant S as External State Store
  U->>L: Request 1＋token
  L->>A: 任選健康副本
  A->>S: 讀寫 session／cart
  S-->>A: 狀態
  A-->>U: Response
  Note over A: Replica A 可隨時被縮掉
  U->>L: Request 2＋token
  L->>B: 改送 Replica B
  B->>S: 讀到相同狀態
  B-->>U: 使用者無感續接

把韌性拆成四個可以逐一檢查的面向

檢查韌性時，可以把需求拆成四個面向；同一個工具可能處理其中一項，卻不能取代其他三項：

表格超出欄寬時，可左右捲動；鍵盤可聚焦表格後用左右方向鍵查看。

套到某個服務時，先找單點故障與狀態存放位置，再確認擴展訊號、啟動時間和故障切換方式。手動或自動切換都要依服務與演練結果估時間，不能只看功能名稱。最後檢查 instance、IP 等 quota 是否足以支撐尖峰與故障期間的額外容量。

最後別漏了 quota。Autoscaler 想增加資源時，仍會受配額限制。活動前先估尖峰容量、檢查目前配額，必要時預留申請與測試時間；不要等到流量進來才發現擴不上去。

flowchart TB
  C[檢查一個元件] --> H[HA<br/>單點與 zone 故障]
  H --> S[Stateless<br/>狀態是否外移]
  S --> A[Autoscaling<br/>指標、上下限、預熱]
  A --> F[Failover<br/>切換目標與時間]
  F --> Q[Quota<br/>尖峰容量是否已核准]
  Q --> T{故障注入與壓測達標？}
  T -- 否 --> C
  T -- 是 --> D[韌性設計完成]

走一遍範例 — 登雲書店

回到我們的老朋友。登雲書店的訂單與金流要 99.99% 可用性，雙 11 流量會衝到平日 10 倍。把上面那四個面向套到它身上，設計大概長這樣：

前端（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，再用壓測確認單一執行個體能否承受

資料庫（Cloud SQL for PostgreSQL）

• 啟用 HA（primary + standby，不同 zone），自動 failover；Enterprise edition 的 HA SLA 是 99.95%，訂單與金流要對上 99.99%，得改用 Enterprise Plus edition，或照下一篇的做法把那一層換成 Spanner
• 加 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 是故障切換用的，不承接一般讀取。若要分散讀流量，需另外評估 read replica；範例裡的兩台 replica 才是為了這個目的配置的。

簡單說，HA 和 read scaling 要分開估：前者處理主實例故障，後者處理讀取負載。把 standby 算進可用的讀取容量，會讓容量規劃過度樂觀。

📝 考場提點

Cloud SQL 的 HA standby 是為了故障切換，不能拿來承接一般讀取流量。若題目同時要求高可用與分散讀取負載，還要另外評估 read replica。看 case study 時，可把各元件分別對到 HA、autoscaling、stateless 和 failover，檢查哪一層尚未處理。

flowchart LR
  W[寫入流量] --> P[Primary]
  P --> H[HA Standby<br/>同步待命，不服務讀取]
  P --> R1[Read Replica 1]
  P --> R2[Read Replica 2]
  Q[讀取流量] --> R1
  Q --> R2
  P -. Primary 故障 .-> H
  H --> N[Standby 提升為新 Primary]
  R1 -. 不能取代 HA .-> X[只負責分散讀取]
  R2 -. 不能取代 HA .-> X

上線前再檢查這幾件事

這些設定在架構圖上不顯眼，卻會直接影響擴容與故障時的使用體驗。

Session 只放在 Pod 記憶體裡。 Pod 縮容或重建時，使用者狀態可能跟著消失。可以把 Session 放在共用儲存（例如 Memorystore），或依安全需求採用無狀態 Token；重點是別讓使用者登入狀態綁死在單一 Pod 上。

資料庫連線池也要跟著擴容規劃。 Cloud SQL 的連線數有上限；如果 Pod 數增加，每個 Pod 又各自維持一組連線池，總連線數可能超過資料庫能承受的範圍。先估算「最大 Pod 數 × 每個 Pod 的連線數」，再調整池大小，必要時評估 PgBouncer 等連線池工具。壓測也要涵蓋擴容後的連線總量。

擴容需要時間。 HPA 即使偵測到指標升高，新 Pod 仍要排程、啟動並通過 readiness，才能接住流量。先用壓測量出這段時間，再決定最低副本數；已知的尖峰可以事先預熱，也要確認下游資料庫能否跟著承受。若評估改用 Cloud Run，同樣要測試冷啟動、並行設定與後端容量，而不是假設換平台就能消除尖峰風險。

延伸閱讀

• Google Cloud Well-Architected Framework：可靠性支柱 — 官方韌性設計原則；PCA 考試指南把 Well-Architected Framework 列為必備知識。
• Compute Engine Managed Instance Group — MIG 的 HA 與 autoscaling 機制。
• 關於 GKE 叢集自動調度資源 — Cluster Autoscaler 如何依工作負載需求增減節點；Pod 層的擴縮另見 HPA 與 VPA。
• Cloud SQL 高可用 — primary／standby 與故障切換機制；standby 不能讀的說明見PostgreSQL 正式環境設定指南。

系列導航

• 系列首頁：PCA 雲端架構師之旅
• 上一篇：PCA 雲端架構師之旅 10 — 網路拓樸
• 下一篇：PCA 雲端架構師之旅 12 — 災難復原 (DR)

下一步：可靠性顧的是「平常別掛」，但萬一整個 region 真的出事呢？下一篇我們進到災難復原（DR），談 RTO / RPO 跟備援策略，把最壞的情況也想清楚。

🎯 換你練習

理論讀完，換自己來。到 架構師設計工作坊 · 步驟 11 填入你的 case study，邊寫邊內化。