Google PCD: 成本、治理與可持續應用程式維運 — 學習指南

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

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

總覽

在現代的 Google Cloud 應用程式開發中，成本、治理與永續營運是密不可分的。其目標在於揭露並控制支出、設計能以經濟實惠的方式擴展的服務，並強制執行防護機制以確保環境安全、合規且整潔——同時在效能與可靠性之間取得平衡。本節詳述了各種實務機制 (帳務與標籤、自動擴展的調整選項、配額與政策)、特定工作負載的經濟效益 (Cloud Run、GKE、資料平台)，以及具備永續意識的選擇，這些選擇能在不損害使用者體驗的情況下，減少閒置浪費與碳足跡。

成本控制與可視性

帳務帳戶、標籤、成本分攤、預算、警示與可視性
- 為每個業務單位或資金來源使用專屬的帳務帳戶，以隔離所有權並啟用精細的權限。將帳務資料匯出至 BigQuery，以進行詳細分析、預測和費用分攤 (chargeback)。
- 標籤是附加在資源上的鍵值對，用於成本歸屬。標準化標籤的鍵 (key) (例如 team、app、env、cost-center)，並透過組織政策和 CI 檢查來強制執行。注意：標籤並非溯及既往；未標記的資源會導致報告失真。
- 在帳務帳戶和專案層級使用預算和警示。結合閾值 (例如 50%、90%、100%) 和基於預測的觸發器。將預算通知路由到 Pub/Sub，再轉發到 Chat/Ops 工具。預算僅用於警示，並不會強制執行任何動作。
- 對於共享平台 (例如 GKE、BigQuery)，使用個別命名空間 (per-namespace) 或個別作業 (per-job) 的標籤，並將其附加到日誌和用量資料中，以實現費用展示 (showback) 或分攤 (chargeback)。

範例：新增標籤

undefined

配額、限制、用量預測與容量治理
- 配額能保護服務並限制失控的成本。定期檢視服務配額，為每個專案設定適當的大小 (right-size)，並在服務上線前申請提高配額。實作部署前檢查，將預期的尖峰用量與配額進行比較。
- 使用帳務匯出資料加上產品用量遙測 (Cloud Monitoring 指標、基於日誌的指標) 來預測支出。建立情境模型 (預期的 QPS、掃描的資料量) 並在預備生產環境 (pre-production) 中進行驗證。
- 失敗模式：在突發事件或產品上線期間達到配額上限，會導致請求被節流 (throttling) (429/403)、部分服務中斷或靜默的效能降級。過度配置的配額會增加錯誤作業的爆炸半徑 (blast radius)。

範例：列出 Compute Engine 配額

undefined

彈性與運算經濟學

適當規模調整、自動擴展、按請求計費、承諾使用與 Spot 容量
- 使用 Cloud Monitoring 與 Recommender 的洞察來適當調整 vCPU 和記憶體大小；並透過負載測試進行驗證。配置不足會導致延遲遽增和 OOM/CPU 節流；配置過度則會浪費開銷。
- 自動擴展將類似資本支出 (capex) 的過度配置轉換為彈性的營運支出 (opex)。在 GKE 上使用 HPA/VPA，並對無伺服器服務 (Cloud Run) 使用按請求的自動擴展，以使容量與需求相符。
- 按請求計費 (Cloud Run, Cloud Functions, GKE Autopilot) 使成本與使用量一致，並減少閒置。注意每次請求的額外開銷和冷啟動；在適當情況下調整最小執行個體數。
- 承諾使用適用於穩定的基準線負載。對 Compute Engine 使用基於資源的 CUDs，對符合條件的託管/無伺服器產品使用彈性 CUDs。不要對變動性大的工作負載過度承諾。
- Spot 容量可為可中斷、容錯的工作降低運算成本。務必實作優雅的終止處理程序；維持備援和快速的檢查點設定。預期隨時可能在短時間通知後被終止。
Cloud Run 的並行處理與最小執行個體數的權衡
- 並行處理 (Concurrency) 控制單一執行個體能同時處理多少個請求。
  - 較高的並行處理能提升利用率和成本效益，但可能因容器內的隊頭阻塞 (head-of-line blocking) 而增加尾部延遲。
  - 並行處理設為 1 可隔離請求 (適用於 CPU 密集型或非執行緒安全的程式碼)，但通常會增加執行個體數量和成本。
- 最小執行個體數可減少冷啟動並平滑化延遲，但代價是產生基準線開銷。僅在 SLOs 要求時使用，並根據需求模式驗證此最低數量。

範例：Cloud Run 設定 (service.yaml) apiVersion: serving.knative.dev/v1 kind: Service metadata: name: img-api annotations: autoscaling.knative.dev/minScale: “2” spec: template: spec: containerConcurrency: 40 containers: - image: gcr.io/PROJECT/img-api resources: limits: memory: “512Mi”

GKE 的資源請求與限制、叢集自動擴展器行為及閒置資源清理
- Requests 決定排程；limits 限制峰值用量。將 requests 設定為接近觀察到的穩定需求，並將 limits 設定得略高一些以允許短暫的突發流量。過低的 limits 會導致 CPU 節流；過低的 memory limits 會導致 OOMKilled。遠高於實際需求的 requests 會閒置容量並阻礙排程。
- Cluster Autoscaler 根據無法排程的 Pods (總 requests 不足) 來擴展節點池。它會遵循 PodDisruptionBudgets，且無法驅逐某些 Pods (例如，使用本地儲存或具限制性 PDBs 的 Pods)，這可能會阻止縮小規模。DaemonSets 和節點的 taints/affinities 也可能阻礙擴展效率。
- Horizontal Pod Autoscaler 將擴展與 CPU/記憶體或自訂指標掛鉤；Vertical Pod Autoscaler 隨時間推移來適當調整 requests。協調 HPA 和 VPA 以避免震盪；根據情況在 recommend 或 auto 模式下使用 VPA。
- 閒置資源清理：刪除未使用的負載平衡器、永久磁碟、快照和靜態 IP。使用 Active Assist 建議和自動化的清理工具來偵測並移除閒置資產。

範例：帶有 requests/limits 的 GKE deployment apiVersion: apps/v1 kind: Deployment metadata: name: api spec: replicas: 3 template: spec: containers: - name: api image: gcr.io/PROJECT/api:stable resources: requests: cpu: “500m” memory: “512Mi” limits: cpu: “1” memory: “768Mi”

資料、分析與網路成本治理

儲存空間級別、生命週期控制、資料庫擴展與網路輸出設計
- 根據存取模式選擇 Cloud Storage 級別：熱資料使用 Standard；較冷的資料使用 Nearline、Coldline 或 Archive。請注意冷層級的資料擷取和提前刪除的最低費用。
- 生命週期規則可自動轉換和刪除資料。在可接受多區域延遲的情況下，使用雙區域 (dual-region) 以提高彈性；將運算和資料放在同一地點 (co-locate) 以減少輸出流量和延遲。
- 資料庫擴展：
  - Cloud SQL：謹慎地垂直擴展；使用讀取複本 (read replicas) 處理讀取；儲存空間自動擴展；使用查詢計畫 (query plans) 和連線池 (connection pooling)。高寫入通量可能需要分片 (sharding) 或移轉至 Spanner/Bigtable。
  - Spanner：透過增加節點進行水平擴展；使用多區域設定以提高可用性和全球讀取；設計結構描述 (schema) 和鍵 (key) 以平衡負載。
  - Bigtable：設計資料列鍵 (row key) 以避免熱點 (hotspot)；獨立擴展叢集節點和儲存空間。
- 網路輸出 (egress)：避免跨區域流量；盡可能將用戶端和資料放在同一個區域。針對網際網路規模的內容使用 Cloud CDN，混合雲環境使用 Cloud Interconnect/Peering，並使用 Private Google Access 或 Private Service Connect 私下存取 Google API。不必要的跨可用區/區域流量會增加成本和延遲。

範例：Cloud Storage 生命週期 cat > policy.json « ‘EOF’ { “rule”: [ { “action”: {“type”: “SetStorageClass”, “storageClass”: “COLDLINE”}, “condition”: {“age”: 30} }, { “action”: {“type”: “Delete”}, “condition”: {“age”: 365} } ] } EOF gsutil lifecycle set policy.json gs://my-bucket

BigQuery 查詢控制、資料保留與分析使用成本
- 控制掃描的位元組數：務必依據分區/叢集鍵進行篩選；避免使用 SELECT *；對重複的查詢使用具體化視觀表 (materialized views) 和結果快取；盡可能使用近似匯總 (approximate aggregations)。
- 透過設定「計費的位元組數上限」來限制掃描成本，並將非緊急工作的優先順序設為批次 (batch)，以減少干擾和成本。
- 選擇定價模型：零星的工作負載使用按需 (on-demand) 付費；穩定的大量工作負載則使用承諾型的預留 (reservations/slots)。使用獨立的預留和指派來隔離不同團隊。
- 資料保留：為資料集/資料表和分區設定到期時間以進行治理；實作分層儲存或匯出以進行封存。
- 故障模式：未分區的大型資料表會導致成本暴增；沒有分區篩選條件的查詢會掃描整個資料表；過於積極的到期設定會刪除需要的資料；過度的 slot 競爭會降低 SLA。

範例：限制查詢成本 bq query –use_legacy_sql=false –maximum_bytes_billed=1000000000
‘SELECT user_id, COUNT(*) FROM proj.ds.events WHERE _PARTITIONDATE >= DATE_SUB(CURRENT_DATE(), INTERVAL 7 DAY) GROUP BY user_id’

組織治理與環境整備

組織政策、資源命名、標記與專案分離
- 使用組織政策來強制執行護欄：限制資源位置、不允許外部 IP、要求使用 CMEK、限制允許的服務、控制 VPC 對等連線，以及在需要時強制使用 OS Login。在組織或資料夾層級應用，並透過階層結構來模擬例外情況。
- 標準化資源命名，以編碼環境、專案、應用程式和地區（例如：app-env-region-suffix）。透過 CI 檢查或政策即程式碼 (policy-as-code) 來強制執行。
- 區分：
  - 標籤 (Labels)：用於帳務/營運歸屬。
  - 標記 (Tags) (第一級)：附加到資源上，並用於 IAM Conditions 和組織政策的目標設定。
  - 網路標記 (Network tags)：用於 Compute Engine 上的防火牆規則。
- 專案分離：隔離環境（生產、預備、開發）和敏感工作負載。使用 Shared VPC 進行集中式網路管理和最低權限的服務專案。這可以減少爆炸半徑並簡化 IAM。
環境生命週期、臨時測試環境與清理自動化
- 透過 IaC (Terraform) 來佈建環境，並啟用每個 PR 的臨時環境。設定 TTL 標籤，並在合併或閒置後自動拆除。
- 使用 Cloud Scheduler 加上 Cloud Run jobs 或 Functions，依標籤/存在時間來掃描並刪除過時的資源。透過 Cloud Asset Inventory 匯出資產清單以驅動稽核。
- 故障模式：廢棄的沙箱會產生費用；缺少 TTL 或標籤會阻礙清理；過於激進的清理可能會刪除活躍的資源——應加入允許清單和寬限期。
永續性感知架構以及在成本、效能和可靠性之間取得平衡
- 優先選擇託管和無伺服器服務，以減少閒置並提高資源利用率。
- 在合規的前提下，選擇碳強度較低的地區；在可行時，將批次工作負載安排在無碳能源較高的時段執行。
- 優化資料引力 (data gravity) 和快取，以減少網路能源消耗。調整自動擴展和併發數，以降低使用率過低的情況。使用效能分析來移除觸發過多運算或 IO 的浪費資源的程式碼路徑。
- 平衡：僅在 SLO 要求時才增加最小執行個體或副本數；評估長尾延遲與併發數，以及備援與 Spot 使用之間的取捨。透過基於 SLO 的負載測試和成本/效能模型分析進行驗證。

實際問題情境

電子商務公司 NimbusMarket 在快閃銷售期間經歷流量尖峰，且分析支出不斷增長。他們在 Cloud Run 上運行客戶 API，在 GKE 上運行背景工作，並在 BigQuery 中進行產品分析。領導層要求在不影響 99.9% API SLO 的前提下，將成本降低 25%。

方法：

建立成本可見性與護欄
- 為帳單帳戶建立預算，並在預測達到 60%、90% 和 100% 時發出警報，透過 Pub/Sub 將通知路由給值班人員。
- 標準化標籤（team、app、env、cost-center），並在 Terraform plans 上透過 CI 強制執行；新增一項組織政策，將資源位置限制在核准的地區。理由：預算提供早期預警；標籤有助於產出各團隊的報告；政策可防止意外使用高額傳出流量的地區並改善合規性。
調整 Cloud Run 以實現經濟實惠的擴展
- 在效能分析確認平均 CPU 時間為 30 毫秒且為非阻塞 IO 後，將無狀態 API 的 containerConcurrency 設定為 40。設定 minScale=2 以避免正常時段的冷啟動；設定排程政策在夜間將 minScale 降至 0。理由：較高的併發數可提高利用率並減少執行個體數量；維持最少的穩定執行個體可在有限的基線成本下保障 SLO，並在離峰時段移除此成本。
適當調整 GKE 工作負載規模並啟用高效的自動擴展
- 根據效能分析，為工作 Pod 套用 500m CPU/512Mi 的 requests 和 1 CPU/768Mi 的 limits。啟用基於佇列深度和處理延遲的 HPA，以及處於建議模式的 VPA，以反覆優化 requests。驗證 PodDisruptionBudgets 允許縮減。在節點池上啟用 Cluster Autoscaler，並使用多個較小的節點。理由：準確的 requests 能驅動有效的排程和自動擴展；HPA 使容量與待辦工作量保持一致；VPA 避免資源需求漂移；多個小節點可減少閒置容量並加快擴展事件的速度。
對容錯的批次處理採用 Spot 容量
- 將圖片縮圖生成作業移至有檢查點機制的 Spot-backed 節點池。實作 preStop hooks 以清空處理中的工作，並使用一個控制器來重新排程被中斷的作業。理由：縮圖生成是冪等且時間彈性的，使其非常適合使用 Spot 以節省成本，且對使用者體驗的影響極小。
降低分析掃描成本並隔離工作負載
- 依 event_date 和 customer_id 對事件資料表進行分割與叢集。為原始事件新增 180 天後的資料表過期設定。將行銷分析師指派到一個有 slot 上限的獨立 BigQuery reservation；在他們的排程查詢中強制執行 maximum_bytes_billed。將夜間報告轉換為批次處理優先級。理由：分割與叢集可抑制每次查詢的位元組數；過期設定強制執行治理；reservations 可隔離吵雜鄰居；批次處理可降低非緊急作業的爭用和成本。
優化儲存生命週期與傳出流量
- 將產品圖片儲存在靠近客戶的 dual-region；透過生命週期規則將 30 天未被存取的圖片移至 Coldline；透過 Cloud CDN 提供服務。將 Cloud Run 服務與 Cloud SQL 共置在同一地區，並為 Google API 啟用 Private Service Connect。理由：CDN 減少傳出流量和延遲；生命週期將冷資料轉移到更便宜的儲存；共置可最小化傳出流量並提高效能。
實作清理自動化與永續性檢查
- 為臨時環境加上 ttl-hours 標籤，並運行一個夜間 Cloud Run job 來刪除過期的資源。使用 Carbon Footprint 報告來考慮將批次作業移至碳排放較低的地區，並將其安排在碳排放離峰時段執行。理由：自動化清理可防止成本洩漏；碳感知排程可在不影響 SLO 的情況下減少對環境的衝擊。
透過感知 SLO 的負載測試和成本模型進行驗證
- 運行重現快閃銷售模式的負載測試；驗證 p95 延遲和錯誤預算。使用帳單匯出儀表板比較前後的成本。理由：確認調整後的設定在達成可靠性目標的同時，也帶來了符合目標的可衡量節省。