Google PCD: 效能、可擴展性與韌性工程 — 學習指南

By Laurynas Brazys · 3 September 2026 · #google #PCD #certification #exam-prep #study-guide

屬於 Google Professional Cloud Developer — 學習指南. 使用經過驗證的解答練習： Google 考試中心, 或參加限時模擬考試： ExamRoll.io.

總覽

在 Google Cloud 上的效能、可擴展性與彈性工程，著重於在變動的負載下，維持低延遲、符合成本效益的服務，同時在不違反服務等級目標 (SLO) 的情況下容忍故障。設計上必須讓自動擴展信號與工作負載特性保持一致，妥善放置資料與運算資源以最小化長尾延遲，並實作超載控制、重試與容錯移轉機制，以避免連鎖性故障。本節將詳細說明對於應用程式開發人員而言，在運算、網路與資料層中至關重要的各種模式、控制項與權衡取捨。

擴展與負載分配

水平擴展 vs. 垂直擴展

水平擴展是透過增加執行個體或 pod 來提升容量與彈性。對於無狀態服務以及需要快速彈性的情境，應優先選用此法。可使用 Managed Instance Groups (MIGs)、Cloud Run 修訂版本或 GKE Deployments。
垂直擴展是增加機器的規格大小。這對於單線程或受記憶體限制的工作負載，或想減少節點間協調的場景很有用，但其擴展空間有限，且重啟時間較長。
並行處理 (Concurrency)：調整請求的並行處理數量，以符合 CPU 密集型或 I/O 密集型的工作特性。Cloud Run 支援每個修訂版本的並行處理設定；若您的執行環境為非阻塞式 (non-blocking)，GKE pod 可同時處理多個請求；若需嚴格隔離，則將並行處理設為 1。

自動擴展信號與暖容量

MIG 的自動擴展功能支援以 CPU 使用率、負載平衡使用率，以及透過 Cloud Monitoring 提供的自訂指標作為擴展依據。對於突發流量，應根據請求指標 (如 rps、佇列深度) 而非 CPU 使用率來進行擴展。
GKE Horizontal Pod Autoscaler (HPA) 可根據 CPU、記憶體或自訂/外部指標 (例如 Pub/Sub 佇列長度) 進行擴展。可使用 Vertical Pod Autoscaler (VPA) 來適當調整資源規模，但應避免在快速擴展的前端服務上使用 VPA 的即時更新功能，以防止資源的頻繁變動。
Cloud Run 根據並行請求負載進行擴展，也可選擇性地使用自訂指標。透過維持暖容量 (warm capacity) 來避免冷啟動：設定最小執行個體數、保持較低的閒置並行處理量，並在需要時透過綜合性健康偵測 (synthetic health pings) 進行預熱。
MIG 中的預測性自動擴展功能，以及在 Deployment/Revision 上設定最小副本數，有助於在每日流量高峰期間，隱藏資源佈建所造成的延遲。

負載平衡、全球流量分配、健康檢查與容錯移轉

使用全球外部 Application Load Balancer 來取得全球性的 anycast VIP、HTTP/2 與 HTTP/3 支援，並搭配 Cloud CDN 進行邊緣終止。後端可以是執行個體群組、可用區/區域級 NEG、無伺服器 NEG (Cloud Run/Functions)，或是 GKE Ingress。
健康檢查會將流量從不健康的後端導離。請確保您的健康檢查端點僅驗證小範圍的相依項目 (例如：程序本身與關鍵的本機資源)，以避免在下游服務中斷時發生循環性故障。
防火牆的允許清單必須放行健康檢查器的來源 IP。如果對 port 80 的檢查失敗，請允許 Google 的 IP 範圍： gcloud compute firewall-rules create allow-lb –network load-balancer –allow tcp –source-ranges 130.211.0.0/22,35.191.0.0/16 –direction INGRESS
容錯移轉 (Failover)：設定主要/備用後端服務，或設定流量政策，在健康檢查失敗時將流量導向替代區域。對於 DNS 層級的容錯移轉，可使用 Cloud DNS 政策搭配健康檢查，來處理非 HTTP 的端點。

延遲與效率

延遲預算

為每個層級 (用戶端、邊緣、應用程式、資料) 分配端到端的延遲預算。監控 p95/p99 百分位數，而非平均值。使用 Cloud Trace 來找出跨服務的延遲來源與隊頭阻塞 (head-of-line blocking) 問題。為 RPC 設定截止時間，以便上游請求取消時能釋放容量。

快取與 CDN 的使用

分層快取：用戶端/瀏覽器快取、CDN 邊緣 (Cloud CDN)，以及區域級/記憶體快取 (Memorystore 或程序內快取)。謹慎選擇快取鍵 (cache key) 與 Vary 標頭。根據資料的新鮮度與過時風險來設定 TTL；在安全的情況下，可考慮對 404 回應進行負向快取 (negative caching)。
將靜態資產存放在 Cloud Storage 中，並透過 Cloud CDN 提供服務，以減少來源伺服器的負載與長尾延遲。使用簽署的 URL/標頭來進行存取控制。

連線重複使用

優先選用 HTTP/2 或 gRPC 以利用其多路復用 (multiplexing) 與標頭壓縮功能。啟用 keep-alives 與連線池 (connection pooling) 以減少交握的額外開銷。注意 NAT 連接埠耗盡的問題；調整用戶端的連線池與閒置逾時設定，並在適用時為每個 VM 規劃 Cloud NAT 連接埠的數量。

酬載效率

使用二進位編碼 (例如 protobuf)，並在酬載大小超過某個閾值時壓縮文字酬載 (gzip/brotli)。謹慎設計請求/回應的欄位；在伺服器端進行分頁與篩選，並避免過度擷取資料。使用 ETags 與條件式請求 (If-None-Match) 來避免多餘的資料傳輸。對於 Cloud Storage，可使用 generation 前置條件與 Range 讀取來取得部分內容。

過載與韌性模式

速率限制、背壓、佇列化與批次處理

在邊緣 (Cloud Armor 用於基於 IP/地理位置/服務的速率限制) 和 API 層 (Apigee 配額、個別 API 客戶端權杖) 強制執行速率限制。在伺服器端實作權杖桶或漏桶演算法，以實現公平共享。
背壓：處理速度不應超過下游系統的負荷。使用佇列 (Pub/Sub 用於至少一次的事件傳遞；Cloud Tasks 用於具備排程和重試功能的個別佇列和個別目標調節)。傳播 429 Too Many Requests 或帶有 Retry-After 的 503 狀態碼來推回客戶端請求。
批次處理可以提高吞吐量並減少每次呼叫的開銷 (例如，批次更新資料庫或批次確認 Pub/Sub 訊息)，以增加的延遲換取效率。調整批次大小和最大等待時間。

過載保護

為每個 RPC 應用逾時和截止時間。使用斷路器模式停止向故障的依賴項發送工作，並啟用快速的備援機制。根據佇列深度、CPU 或延遲 SLO 違規來實施負載卸除，以保護核心功能。

韌性重試、指數退避、抖動、冪等性與重複處理

僅在安全時重試：網路逾時、5xx 或文件中記載的可重試代碼 (例如，Cloud Storage 429/5xx)。除非有特別指明，否則絕不重試 4xx 錯誤 (如 400/401/403)。
使用帶有抖動的截斷指數退避，以避免同步重試。建議使用完全抖動。範例： for attempt in range(max_attempts): sleep = min(base * 2**attempt, cap) * random.uniform(0.5, 1.5) try_request_or_break()
確保冪等性。使用冪等性金鑰 (例如，唯一的作業 ID) 以及 upserts/條件式寫入來容忍重複請求。對於 Pub/Sub，使用 messageId 或應用程式金鑰來進行去重；設計處理程式時需確保其在至少一次傳遞的場景下是安全的。對於 Cloud Storage 的寫入操作，使用 generation-match 前置條件來避免覆寫。

休眠資源的暖機

某些服務會強制實施適應性限制。對於 Cloud Storage，應逐漸提高先前閒置儲存桶的請求速率，以減少在流量突然飆升時出現的暫時性 429/5xx 錯誤。在進入全負載之前，透過受控的流量來調節生產者並預熱儲存桶。

高可用性、資料、災難復原與測試

多可用區、區域級、多區域；主動-主動 (active-active) vs 主動-被動 (active-passive)

跨故障網域部署。使用區域級 MIG 或區域級 GKE 叢集來容忍可用區故障。對於全球服務，則使用多個區域搭配全球負載平衡器。
主動-主動模式可降低 RTO 和延遲，但需要無衝突的資料和謹慎的一致性管理。主動-被動模式簡化了寫入語意，但會產生較高的 RTO 和潛在的冷容量。

RTO、RPO、備份、還原與災難復原測試

為每個工作負載定義 RTO (服務復原時間目標) 和 RPO (可容忍的資料損失)。將其對應到平台能力：
- Cloud Spanner：多區域，具備五個九的可用性及同步複製，可達到近乎零的 RPO。
- Cloud SQL：區域內高可用性；使用跨區域副本進行災難復原，啟用 PITR，並驗證故障轉移/回復的執行手冊。
- Firestore 和 Bigtable 提供區域級和多區域選項；根據 RTO/RPO 需求進行選擇。
- Cloud Storage 的雙區域或多區域儲存桶提供地理備援；驗證還原程序和簽署 URL 的重新簽發流程。
測試災難復原：定期執行故障轉移演練。透過還原到隔離環境來驗證備份，演練 DNS/流量的故障轉移，並衡量實際的 RTO/RPO。

資料庫與儲存效能、索引設計、熱點鍵與爭用

Cloud Spanner：避免使用會造成熱點的單調遞增主鍵。使用交錯式資料表以提升局部性，使用次要索引來配合讀取模式，並使用有界限的交易來減少鎖定衝突。根據 QPS 和儲存量來調整節點大小；為生產環境的法定數量和預留空間至少保留三個節點。
Cloud SQL：分析查詢、新增覆蓋索引、避免長時間交易，並使用連線池。審慎地調整 InnoDB 或 Postgres 的設定；為讀取密集型工作負載擴展唯讀副本。
Bigtable：設計資料列鍵以均勻分佈負載 (例如加鹽或欄位反轉)。若可用，使用多叢集路由以實現跨區域的高可用性。
Firestore：對多欄位查詢使用複合索引；注意當大量寫入目標為相同文件路徑時可能產生的熱點問題。
Cloud Storage：新物件具備寫入後強一致性讀取；使用平行上傳和分塊來提升吞吐量。對閒置的儲存桶應逐步增加流量；對於熱點讀取，優先使用 CDN 邊緣。對於許多 VM 需要相同的大型唯讀資料集的情況，將一個永久磁碟以唯讀模式掛載到多個執行個體，以低成本實現快速的本機存取。

負載測試、混沌實驗、故障注入與容量規劃

負載測試：模擬真實的流量形狀和資料分佈。預熱快取和自動擴展器；在負載下和擴展事件期間測試 p95/p99 延遲。將一小部分即時流量鏡像到影子堆疊，以驗證在生產環境複雜度下的行為。
混沌與故障注入：終止 pod/VM、封鎖一個可用區、在服務網格 (例如 Envoy/Istio) 層注入延遲/錯誤，以觀察爆炸半徑和韌性。驗證斷路器和重試機制是否如預期般運作。
容量規劃：利用歷史需求和已規劃的事件進行預測。為 N+1 故障和重新平衡保留預留空間。將自動擴展器的冷卻時間和最大速率與預期的尖峰流量對齊；在可預測的尖峰期間預先佈建資源。

代管服務與自訂架構之間的可用性權衡

運算：Cloud Run 提供快速擴展至零和低維運開銷，但有冷啟動和請求並行性的限制。GKE 提供細粒度的控制和可攜性，但維運成本較高。Compute Engine VM 提供最大的控制權，但維運負擔最重。
資料：Cloud Spanner 提供全球一致性和高可用性，但成本較高且結構描述要求嚴格。Cloud SQL 適合傳統的 RDBMS，維運較簡單，但高可用性/擴展性有限。Bigtable 在低延遲、大規模鍵值/時間序列資料方面表現出色。Firestore 提供彈性的結構描述，具備強一致性和全球選項。
網路：全球負

← 可觀測性、偵錯與網站可靠性維運 · 所有領域 · 測試、品質工程與安全發布管理 →

練習這些題目 → · 在 ExamRoll.io 上限時練習 →