Google ACE: 成本管理、效能與容量最佳化 — 學習指南

By Laurynas Brazys · 31 August 2026 · #google #ACE #certification #exam-prep #study-guide

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

總覽

在 Google Cloud 上進行成本管理與效能/容量最佳化，需要持續的可見性、適當規模的決策 (right-sizing) 以及能讓資源利用率與業務目標保持一致的治理。有效的實踐融合了財務控制 (預算、分攤)、技術手段 (自動擴展、預留、生命週期政策)、架構選擇 (資料本地性、複寫) 以及營運回饋 (遙測、負載測試)。本節詳述了在運算、儲存、資料處理、網路、資料庫、配額與效能工程等領域的關鍵工具、權衡取捨與失敗模式。

成本可見性、預算與分攤

• 帳單報告與匯出：

  • 使用 Cloud Billing Reports 快速分析趨勢與 SKU 細項；啟用 Cloud Billing 資料匯出至 BigQuery，以取得詳細、可查詢的成本與用量資料。這能支援以標準 SQL 進行每日/每月預測、異常偵測以及跨專案的匯總分析。
  • 價格表匯出有助於核對定價與 SKU 成本及抵免額。
  • 失敗模式：僅使用主控台介面會限制精細度；不匯出至 BigQuery 會阻礙歷史模型建立與準確的成本展示 (showback) / 成本分攤 (chargeback)。

• 預算與快訊：

  • 建立預算，其範圍可限定於帳單帳戶、專案、資料夾、服務或標籤/標記篩選器；針對實際與預測成本設定閾值快訊 (例如 50%/90%/100%)。考慮透過 Pub/Sub 作為通知管道，以觸發自動化操作 (例如，暫停非生產環境)。
  • 權衡取捨：過於激進的自動關閉措施雖然能減少開銷，但若應用於生產路徑，可能會損害可靠性。

• 用於分攤的標籤與標記：

  • 一致地套用資源標籤 (label) 與 Resource Manager 標記 (tag) (例如：env、app、owner、cost-center)。標記支援機構政策，並會出現在帳單篩選器中，以實現穩健的成本分攤。
  • 治理：使用 Organization Policy、部署範本與 CI/CD 檢查來強制執行標籤/標記政策。
  • 失敗模式：不一致的鍵 (key) 或遺失的標籤會破壞成本分攤模型；若工具不一致，繼承的標記可能無法應用於所有資源類型。

• 成本分攤模型：

  • 成本展示 (Showback) / 成本分攤 (chargeback) 通常使用一個層級結構：專案 → 服務/SKU → 標籤/標記。共享平台成本 (例如，負載平衡器、VPC 出口流量) 可根據驅動因素進行分攤，例如透過日誌/指標測量的請求數、傳輸的 GB 數或 CPU 小時數。
  • 權衡取捨：簡單的模型 (如平均分攤) 易於執行，但可能對重度使用者定價不公；精細的模型則需要可靠的遙測資料與更多的管理開銷。

簡短範例 (使用 BigQuery dry run 估算成本)：

undefined

運算效率與生命週期最佳化

• 適當規模調整 (Rightsizing) 與自訂機器類型：

  • 使用 Recommender API/主控台，根據 CPU/記憶體用量的百分位數來調整 VM 的規模。對於穩定且需求低於標準規格的負載 (例如，2 vCPU/10 GB RAM)，應優先選用自訂機器類型，以避免為未使用的容量付費。
  • 失敗模式：縮減對延遲敏感或具突發性的服務，可能導致服務被節流 (throttling)。應透過負載測試進行驗證，並保留緩衝空間。

• Committed Use Discounts (CUDs)：

  • 透過主控台或 CLI，以區域為範圍，購買為期 1 年或 3 年、以資源為基礎的 CUDs (vCPU、記憶體、GPU)。最適合用於穩定的基線容量；對於突發流量，則在其上疊加自動擴展機制。
  • 權衡取捨：承諾使用雖然能降低單價，但缺乏彈性。過度承諾會鎖定支出；承諾不足則會錯失折扣。

• Spot VMs：

  • 對於容錯、可中斷的工作負載 (例如批次處理、CI、無狀態層)，應使用 Spot VM。實作檢查點 (checkpointing) 與搶佔處理 (透過 metadata/Pub/Sub 取得 30 秒通知)。
  • 失敗模式：容量可能隨時消失；絕不應將有狀態或需要法定數量 (quorum-critical) 的服務完全部署在 Spot VM 上。

• 自動擴展、排程與生命週期：

  • 具備自動擴展功能的代管執行個體群組 (MIGs) (可根據 CPU、負載平衡器或自訂的 Cloud Monitoring 指標) 能處理變動的負載。調整冷卻時間 (cool-down) 與縮減控制 (scale-in controls) 以防止規模震盪；將健康檢查的初始延遲與應用程式的就緒時間對齊。
  • 排程：在非工作時間停止或暫停開發/測試用的 VM；使用 Instance Schedules 或搭配 Cloud Scheduler 與 Cloud Functions 的自動化來最小化閒置成本。
  • 生命週期與維護：啟用自動重啟與主機維護轉移 (host maintenance migrate) 以確保高可用性；請注意，即時遷移 (live migration) 可能不適用於掛載 GPU 或 local SSD 的執行個體。
  • 閒置清理：使用 Recommender 回收未掛載的永久磁碟、過期的快照以及未使用的靜態 IP。
  • 失敗模式：過短的健康檢查延遲或遺失就緒信號會導致過度佈建；過於激進的縮減會中斷連線；停用自動修復會隱藏故障節點。

簡短範例：

undefined

undefined

儲存與資料處理的經濟效益

• Cloud Storage 儲存空間級別與生命週期：

  • 依存取模式選擇級別：Standard (常用)、Nearline (至少 30 天)、Coldline (至少 90 天)、Archive (至少 365 天)。套用生命週期規則來自動降層及依排程刪除。
  • 擷取成本的權衡：成本較低的級別會收取每 GB 的擷取費與最低儲存期間費用；頻繁讀取 Coldline/Archive 會侵蝕掉節省的成本。規劃還原工作流程時需考量讀取成本高峰。
  • 治理：使用保留政策與物件鎖定來滿足合規性要求；對共享的資料集啟用「要求者付費」，以避免跨團隊的意外帳單。

• 生命週期政策範例 (先降層後刪除)：

  • 定義以物件存在時間為基礎的 SetStorageClass 與 Delete 動作，以自動化轉換儲存級別並清理過時資料。

• BigQuery 成本控制：

  • 隨選查詢依處理的位元組數計費；透過分區裁剪 (partition pruning) 與叢集 (clustering) 來將其最小化。依擷取時間或日期欄位進行分區；對最多四個高基數/高選擇性的欄位進行叢集。
  • 使用模擬執行 (dry run) 來預估成本、使用具體化視觀表 (materialized view) 處理熱門的彙總資料，並使用資料表裝飾字元 (table decorator) 縮小時間範圍。
  • 預留 (slots) 提供可預測的效能與支出；可依專案/資料夾進行指派，並考慮使用彈性承諾 (flex commitments) 來應對短期流量高峰。
  • 失敗模式：未分區掃描、在寬資料表中使用 SELECT *、或排序不佳的叢集都會產生巨量的掃描位元組；若未設定過期時間，暫時性的中介資料表可能導致儲存空間暴增。

簡短範例 (Cloud Storage 生命週期 JSON 片段)：

• { “rule”: [ {“action”: {“type”: “SetStorageClass”, “storageClass”: “COLDLINE”}, “condition”: {“age”: 90}}, {“action”: {“type”: “Delete”}, “condition”: {“age”: 365}} ] }

網路、資料庫與具備配額意識的擴展

• 網路輸出 (egress) 與架構影響：

  • 輸出到網際網路、跨區域以及透過外部 IP 的流量都會產生費用；同一區域內透過內部 IP 的流量通常是免費的。選擇 Premium Network Tier 以獲得高效能，或為對成本敏感、且對延遲/抖動要求較寬鬆的工作負載選擇 Standard Tier。
  • 負載平衡器：L7 HTTP(S) 與 L4 TCP/UDP 有資料處理與轉送規則費用；跨區域負載平衡器可能會增加跨區域輸出流量。整合負載平衡器可節省固定成本，但可能會擴大失敗時的影響範圍 (blast radius)。
  • 最佳化：將流量維持在區域內；使用區域級儲存桶與服務；避免透過外部 IP 進行髮夾彎式繞送 (hairpinning)。在邊緣快取靜態資產以減少來源端的輸出流量。
  • 失敗模式：在同一個 VPC 內的服務之間意外使用外部 IP 會導致不必要的輸出流量；多區域複製會使寫入路徑的輸出流量加倍。

• 資料庫規模、複本與可用性：

  • Cloud SQL：根據第 95 百分位數的負載來規劃 vCPU/RAM 大小；啟用儲存空間自動擴展；使用讀取複本來擴展讀取 (scale-out reads)；HA (高可用性) 會使運算成本加倍，但能降低故障轉移的 RTO。連線池 (Connection pooling) 可避免過多的連線開銷。
  • Spanner：容量是以節點 (node) 或處理單元 (processing unit) 的形式佈建；多區域設定可改善可用性與讀取延遲，但會增加成本與寫入延遲；需謹慎規劃分片 (split) 與熱點 (hotspot)。
  • Bigtable：節點數量決定吞吐量；自動擴展器有助於追蹤流量；多叢集複製會增加可用性與成本；設計 schema 時應確保鍵值均勻分佈。
  • 權衡取捨：複本可改善讀取吞吐量與可用性，但會增加寫入放大 (write amplification) 與輸出流量；強一致性與跨區域寫入會增加延遲。

• 配額、速率限制與背壓 (backpressure)：

  • 了解各 API 的配額與各服務的並行數量限制。針對 429/5xx 錯誤實作帶有抖動 (jitter) 的指數退避 (exponential backoff)。使用 Pub/Sub 搭配 Dataflow 或 Cloud Run jobs 來應用以佇列為基礎的負載調節 (load leveling)。
  • 並行設定：在 Cloud Run 中，較高的並行數量可降低成本，但有長尾延遲 (tail latency) 的風險；調整請求時的 CPU 分配以獲得穩定的吞吐量。
  • 背壓：在 Pub/Sub 訂閱者中使用流量控制 (flow control)、斷路器 (circuit breaker) 與准入控制 (admission control) 來防止連鎖故障。
  • 失敗模式：忽略配額會導致服務突然被節流 (throttling)；若沒有背壓機制，自動擴展會放大對下游服務的負載，導致不斷重試並使成本倍增。

效能衡量與最佳化治理

• 衡量與負載測試：

  • 針對延遲、錯誤率與飽和度建立 SLI/SLO。使用 Cloud Monitoring 儀表板、執行時間檢查與警示。導入追蹤 (Cloud Trace) 與剖析 (Cloud Profiler) 來找出熱路徑 (hot path) 與鎖競爭 (lock contention)。
  • 使用擬真的流量模型、資料基數 (data cardinality) 與思考時間 (think time) 進行負載測試。驗證自動擴展器參數、暖機 (warm-up) 與就緒閘道 (readiness gate)。納入容錯移轉與混沌情境，以觀察容量餘裕 (capacity headroom) 與復原時間。
  • 瓶頸診斷：在 CPU、記憶體、磁碟、網路與下游相依服務上，使用 USE 方法 (使用率 Utilization、飽和度 Saturation、錯誤 Errors)；並與日誌和追蹤資料相互關聯。

• 平衡成本、安全性與可靠性的治理：

  • FinOps 護欄：強制性標籤/標記；帶有預測警示的預算；集中式帳務匯出與成本審查週期。將 Recommender 的建議 (閒置 IP/磁碟、規模適正化) 納入待辦清單 (backlog)，並附帶負責人 SLA。
  • 安全性：優先使用私有連線 (無外部 IP)、VPC Service Controls 以應對資料外洩風險——需認知到私有路徑可能會改變出口流量模式與成本。對靜態資料與傳輸中資料進行加密；在成本模型中將 KMS 使用量納入考量。
  • 可靠性：透過 CUD 或 BigQuery 預留來保留基準容量；為 SLO 保留突發流量餘裕；定期執行演習日 (game day)。記錄下哪些關鍵路徑不適用 Spot 或具侵略性的自動擴展。
  • 變更管理：將影響成本的參數 (自動擴展器上限、BigQuery 預留、LB 拓撲) 視為程式碼 (as code) 管理，並具備審查與回滾計畫。

實務問題情境

Contoso Media 營運一個多區域的影片分析平台，該平台面臨成本不斷上升的問題，並在流量高峰期間偶爾會違反延遲 SLO。領導階層希望在不影響 API 的 p95 延遲 SLO (300 毫秒) 以及夜間批次處理需在 2 小時內完成的 SLA 的前提下，將成本降低 20%。

1. 建立成本與效能基準線

• 行動：啟用 Cloud Billing 匯出至 BigQuery，並建立儀表板，將 SKU 成本與 Cloud Monitoring SLI (延遲、CPU、出口位元組數) 建立關聯。對前 20 大查詢執行 bq dry runs，以估計掃描的位元組數。
• 理由：基準線能識別出高影響力的服務，並將支出對應到效能驅動因素，從而實現針對性的最佳化。

2. 強制執行分配標記與預算

• 行動：透過部署範本要求使用標籤/標記 (env、service、owner、cost-center)；為每個環境設定預算，並將預測警示傳送至一個 FinOps 的 Pub/Sub 主題。
• 理由：完整的分配資料與主動式警示，讓您能在超支前快速確定負責人並採取修正行動。

3. 規模適正化並承諾基準運算容量

• 行動：對穩定的服務套用 Recommender 的 VM 規模適正化建議；將穩定狀態的容量轉換為一年期的區域性 CUD；在自動擴展器的最大值上保留 20–30% 的緩衝區以應對高峰。
• 理由：規模適正化與承諾使用可降低可預測負載的單位成本，同時為 SLO 保留效能餘裕。

4. 最佳化自動擴展與就緒狀態

• 行動：對於 MIG，將自動擴展訊號切換為基於請求或自訂的 QPS/延遲指標，將冷卻時間設定為 120–180 秒，並使健康檢查的初始延遲與應用程式暖機時間對齊。啟用縮減控制 (scale-in control) 以防止快速縮減。
• 理由：感知工作負載的訊號與穩定機制可避免資源抖動 (thrashing) 和過度佈建，這些都會增加成本並損害延遲。

5. 減少網路出口流量與負載平衡器開銷

• 行動：移除服務間的外部 IP 通訊；確保所有東西向流量都使用內部負載平衡；將通訊頻繁的服務共置於同一區域內；在邊緣快取靜態資產。
• 理由：內部路徑消除了不必要的出口流量並減少了 L7 處理，從而改善延遲與成本。

6. 儲存生命週期與封存

• 行動：套用 Cloud Storage 生命週期規則，在 90 天後將冷資料成品移至 Coldline，並在 365 天後刪除；在共用儲存桶上設定請求者付費 (requester-pays)；審查最短儲存時間對罕見存取資料的影響。
• 理由：分層與保留政策可降低儲存與擷取成本，同時維持合規性。

7. BigQuery 查詢與容量調校

• 行動：依日期對大型事實資料表進行分割 (partition)，並依高選擇性欄位進行叢集 (cluster)；將 SELECT * 替換為明確的欄位投影；為熱門的彙總查詢建立具體化視觀表 (materialized view)；為 ETL 尖峰時段購買少量預留，並在批次處理高峰期間使用 flex slots。
• 理由：分割/叢集可減少掃描的位元組數；容量預留可穩定關鍵工作負載的效能與成本。

8. 資料庫擴展與複本

• 行動：對於讀取密集型的 Cloud SQL 服務，增加讀取複本；調校連線池 (connection pooling)；設定儲存空間自動調整大小；測試容錯移轉以驗證 RTO/RPO。對於 Bigtable，啟用自動擴展並處理熱點鍵 (hotspot key) 問題。
• 理由：複本可分擔讀取負載並保護寫入路徑；自動擴展使吞吐量與需求保持一致，無需手動過度佈建。

9. 配額、並行處理與背壓

• 行動：實作帶有抖動 (jitter) 的指數輪詢 (exponential backoff)；設定 Pub/Sub 訂閱者流量控制；設定 Cloud Run 的並行處理 (concurrency) 以平衡吞吐量與延遲；在下游服務邊界加入斷路器 (circuit breaker)。
• 理由：適當的背壓可防止連鎖故障與失控的重試，這些情況會降低 SLO 並增加成本。

10. 持續驗證與治理

• 行動：每月執行負載測試與混沌演練；追蹤 SLO/錯誤預算；將 Recommender 與成本異常狀況整合到衝刺計畫 (sprint planning) 中，並指派負責人與到期日。
• 理由：迭代驗證確保節省的成本能持續，並隨著工作負載的演進，SLO 仍能維持在綠色狀態。

← 可靠性、備份與災難復原 · 所有領域

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

瀏覽 Google →