Google ACE: 成本管理、性能和容量优化 — 学习指南

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

属于 Google Associate Cloud Engineer — 学习指南. 使用经过验证的答案练习： Google 考试中心, 或参加限时模拟考试： ExamRoll.io.

概述

在 Google Cloud 上进行成本管理和性能/容量优化，需要持续的可见性、合理的规模调整决策以及将资源利用与业务目标相结合的治理。有效的实践融合了财务控制（预算、分摊）、技术手段（自动扩缩、预留、生命周期策略）、架构选择（数据局部性、复制）和运营反馈（遥测、负载测试）。本节详细介绍计算、存储、数据处理、网络、数据库、配额和性能工程中的关键工具、权衡和失败模式。

成本可见性、预算和分摊

• 结算报告和导出：

  • 使用 Cloud Billing Reports 快速了解趋势和 SKU 明细；启用 Cloud Billing 数据导出到 BigQuery，以获取详细、可查询的成本和用量数据。这支持通过标准 SQL 进行每日/每月预测、异常检测和多项目汇总。
  • 价格表导出有助于将定价与 SKU 成本和赠金进行核对。
  • 失败模式：仅使用控制台视图会限制粒度；不导出到 BigQuery 会阻碍历史建模和准确的成本展示/分摊。

• 预算和提醒：

  • 创建范围限定于结算账号、项目、文件夹、服务或标签/标记过滤器的预算；针对实际成本和预测成本配置阈值提醒（例如 50/90/100%）。考虑通过 Pub/Sub 使用通知渠道来触发自动化操作（例如，暂停非生产环境）。
  • 权衡：激进的自动化关停会减少开销，但如果应用于生产路径，可能会损害可靠性。

• 用于分摊的标签和标记：

  • 一致地应用资源标签和 Resource Manager 标记（env、app、owner、cost-center）。标记支持组织策略，并出现在结算过滤器中，以实现稳健的分摊。
  • 治理：使用 Organization Policy、部署模板和 CI/CD 检查来强制执行标签/标记策略。
  • 失败模式：不一致的键或缺失的标签会破坏分摊模型；如果工具不一致，继承的标记不会应用于所有资源类型。

• 成本分摊模型：

  • 成本展示/分摊通常使用一个层级结构：项目 → 服务/SKU → 标签/标记。共享平台成本（例如，负载均衡器、VPC 出站流量）可以按驱动因素（如请求数、传输的 GB 数或通过日志/指标测量的 CPU 小时数）进行分摊。
  • 权衡：简单的模型（平均分配）易于运行，但可能对重度用户定价不当；精细的模型需要可靠的遥测和更多的管理开销。

简短示例（使用 BigQuery 空运行进行成本估算）：

undefined

计算效率和生命周期优化

• 优化调整和自定义机器类型：

  • 使用 Recommender API/控制台，根据 CPU/内存使用百分位数来优化调整虚拟机。对于稳定的、低于标准规格的需求（例如，2 vCPU/10 GB RAM），优先选择自定义机器类型，以避免为未使用的容量付费。
  • 失败模式：对延迟敏感或有突发需求的服务进行缩容可能会导致节流。通过负载测试和预留缓冲区进行验证。

• 承诺使用折扣 (CUD)：

  • 通过控制台或 CLI，以区域范围购买为期 1 年或 3 年的基于资源的 CUD（vCPU、内存、GPU）。最适合稳定的基线容量；叠加自动扩缩以应对突发流量。
  • 权衡：承诺降低了单价，但缺乏灵活性。过度承诺会锁定支出；承诺不足则会丧失折扣。

• Spot VMs：

  • 将 Spot VMs 用于容错、可中断的工作负载（批处理、CI、无状态层）。实现检查点和抢占处理（通过元数据/Pub/Sub 提前 30 秒通知）。
  • 失败模式：容量可能随时消失；切勿将有状态或对仲裁至关重要的服务完全部署在 Spot 上。

• 自动扩缩、调度和生命周期：

  • 具有自动扩缩功能（基于 CPU、负载均衡器或自定义 Cloud Monitoring 指标）的代管实例组 (MIG) 可处理可变负载。调整冷却和缩容控制以防止振荡；将健康检查初始延迟与应用就绪状态对齐。
  • 调度：在非工作时间停止或暂停开发/测试虚拟机；使用 Instance Schedules 或通过 Cloud Scheduler 和 Cloud Functions 实现自动化，以最大限度地减少空闲成本。
  • 生命周期和维护：为实现高可用性，启用自动重启和主机维护迁移；请注意，实时迁移可能不适用于带 GPU 或本地 SSD 的实例。
  • 空闲资源清理：使用 Recommender 回收未挂载的永久性磁盘、过时的快照和未使用的静态 IP。
  • 失败模式：过短的健康检查延迟或缺失的就绪信号会导致过度预配；过于激进的缩容会中断连接；禁用自动修复会隐藏故障节点。

简短示例：

undefined

undefined

存储与数据处理的成本考量

• Cloud Storage 存储类别和生命周期：

  • 根据访问模式选择存储类别：Standard（热数据）、Nearline（至少存储 30 天）、Coldline（至少存储 90 天）、Archive（至少存储 365 天）。应用生命周期规则按计划进行数据分层和删除。
  • 检索成本权衡：成本较低的存储类别会收取每 GB 的检索费用和最短存储期限费用；频繁读取 Coldline/Archive 数据会抵消成本优势。规划恢复工作流时需考虑读取成本峰值。
  • 治理：使用保留策略和对象锁定以满足合规性要求；为共享数据集启用“请求者付款”功能，以避免跨团队的意外账单。

• 生命周期策略示例（先分层后删除）：

  • 定义基于存在时间的 SetStorageClass 和 Delete 操作，以自动转换和清理过时数据。

• BigQuery 成本控制：

  • 按需查询按处理的字节数收费；通过分区裁剪和聚类来最小化成本。按注入时间或日期列进行分区；对最多四个具有高基数/高选择性的列进行聚类。
  • 使用模拟运行（dry run）来估算成本，使用物化视图处理热点聚合，并使用表修饰器来缩小时间窗口。
  • 预留（槽）提供可预测的性能和支出；按项目/文件夹进行分配，并考虑使用灵活承诺来应对短期峰值。
  • 失效模式：对未分区表进行扫描、在宽表中执行 SELECT *、或聚类排序不佳都会产生海量扫描字节；如果未设置过期时间，临时的中间表可能会导致存储空间急剧膨胀。

简短示例（Cloud Storage 生命周期 JSON 片段）：

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

网络、数据库与配额感知型扩缩

• 网络出站流量与架构影响：

  • 出站到互联网、跨区域以及通过外部 IP 的流量都会产生费用；同一区域内通过内部 IP 的流量通常是免费的。对于性能要求高的场景选择 Premium Network Tier，对于对延迟/抖动要求不严的成本敏感型工作负载选择 Standard Tier。
  • 负载均衡器：L7 HTTP(S) 和 L4 TCP/UDP 会收取数据处理和转发规则费用；跨区域负载均衡器可能会增加区域间的出站流量费用。整合负载均衡器可以节省固定成本，但可能会扩大故障影响范围。
  • 优化：将流量保持在区域内；使用区域级存储桶和服务；避免通过外部 IP 进行“发夹”式回环。在边缘缓存静态资产以减少源站的出站流量。
  • 失效模式：在同一 VPC 内的服务之间意外使用外部 IP 会导致不必要的出站流量；多区域复制会使写入路径的出站流量加倍。

• 数据库规模、副本与可用性：

  • Cloud SQL：根据第 95 百分位的负载来确定 vCPU/RAM 的大小；启用存储空间自动调整大小；使用只读副本进行读取横向扩展；HA 会使计算成本翻倍，但能减少故障切换的 RTO。连接池可避免过多的连接开销。
  • Spanner：容量以节点或处理单元的形式配置；多区域配置可提高可用性并降低读取延迟，但会增加成本和写入延迟；需仔细规划分片和热点。
  • Bigtable：节点数量决定吞吐量；自动扩缩器有助于跟踪流量；多集群复制会增加可用性和成本；设计 schema 以实现均匀的键分布。
  • 权衡：副本可以提高读取吞吐量和可用性，但会增加写入放大和出站流量；强一致性和多区域写入会增加延迟。

• 配额、速率限制与反压：

  • 了解每个 API 的配额和每个服务的并发限制。针对 429/5xx 错误，实现带抖动的指数退避。使用 Pub/Sub 和 Dataflow 或 Cloud Run 作业应用基于队列的负载均衡。
  • 并发设置：在 Cloud Run 中，更高的并发会降低成本，但有尾部延迟的风险；调整按需分配的 CPU 以获得稳定的吞吐量。
  • 反压：在 Pub/Sub 订阅者中使用流控制、熔断器和准入控制，以防止级联故障。
  • 失效模式：忽略配额会导致突然的限流；如果没有反压机制，自动扩缩可能会放大对下游服务的负载，导致重试并增加复合成本。

性能衡量与优化治理

• 衡量与负载测试：

  • 为延迟、错误率和饱和度建立 SLI/SLO。使用 Cloud Monitoring 仪表盘、正常运行时间检查和警报。通过埋点跟踪 (Cloud Trace) 和性能剖析 (Cloud Profiler) 来定位热点路径和锁争用。
  • 使用真实的流量模型、数据基数和思考时间进行负载测试。验证自动扩缩容参数、预热和就绪门控。包括故障切换和混沌场景，以观察容量余量和恢复时间。
  • 瓶颈诊断：在 CPU、内存、磁盘、网络和下游依赖项上使用 USE 方法（利用率、饱和度、错误）；并与日志和跟踪数据进行关联分析。

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

  • FinOps 护栏：强制性标签/标记；带有预测警报的预算；集中的账单导出和成本审查周期。将 Recommender 的发现（空闲 IP/磁盘、规模优化）纳入待办事项列表，并为负责人设置 SLA。
  • 安全性：优先选择私有连接（无外部 IP），使用 VPC Service Controls 防范数据泄露风险——需认识到私有路径可能会改变出口流量模式和成本。实施静态加密和传输中加密；在成本模型中考虑 KMS 的使用。
  • 可靠性：通过 CUD 或 BigQuery 预留来预留基准容量；为 SLO 保留突发容量余量；定期执行“游戏日”（演练）。明确指出对于关键路径，Spot 实例或激进的自动扩缩容是不可接受的。
  • 变更管理：将影响成本的参数（自动扩缩容上限、BigQuery 预留、LB 拓扑）视为代码，并制定审查和回滚计划。

实际问题场景

Contoso Media 运营一个多区域视频分析平台，该平台成本不断上升，并在流量高峰期间偶尔出现延迟 SLO 违规。领导层希望在不影响 API 的 p95 延迟 SLO（300 毫秒）和夜间批处理在 2 小时内完成的 SLA 的前提下，将成本降低 20%。

1. 建立成本和性能基线

• 操作：启用 Cloud Billing 到 BigQuery 的导出，并创建仪表盘，将 SKU 成本与 Cloud Monitoring SLI（延迟、CPU、出口字节数）相关联。对排名前 20 的查询运行 bq 空跑（dry run）以估算扫描的字节数。
• 理由：基线可以识别高影响力的服务，并将支出映射到性能驱动因素，从而实现有针对性的优化。

2. 强制执行分配标记和预算

• 操作：通过部署模板要求使用标签/标记（env、service、owner、cost-center）；为每个环境设置预算，并将预测警报发送到 FinOps 的 Pub/Sub 主题。
• 理由：完整的分配数据和主动警报有助于在成本超支前快速明确责任并采取纠正措施。

3. 优化规模并承诺基准计算容量

• 操作：对稳定的服务应用 Recommender 的虚拟机规模优化建议；将稳态容量转换为 1 年期区域 CUD；在自动扩缩容器的最大值上保留 20-30% 的缓冲区以应对峰值。
• 理由：规模优化和承诺使用可降低可预测负载的单位成本，同时为 SLO 保留余量。

4. 优化自动扩缩容和就绪状态

• 操作：对于 MIG，将自动扩缩容信号切换为基于请求或自定义的 QPS/延迟指标，将冷却时间设置为 120-180 秒，并使健康检查的初始延迟与应用预热时间保持一致。启用缩容控制以防止过快缩容。
• 理由：感知工作负载的信号和稳定措施可避免因抖动和过度预配而导致成本膨胀和延迟增加。

5. 减少网络出口流量和负载均衡器开销

• 操作：移除服务之间的外部 IP 通信；确保所有东西向流量使用内部负载均衡；将通信频繁的服务共置在同一区域内；在边缘缓存静态资产。
• 理由：内部路径消除了不必要的出口流量并减少了 L7 处理，从而改善了延迟和成本。

6. 存储生命周期和归档

• 操作：应用 Cloud Storage 生命周期规则，在 90 天时将冷工件移动到 Coldline，并在 365 天时删除；在共享存储桶上设置“请求者付款”；审查最低存储时长对不常访问数据的影响。
• 理由：分层和保留策略可降低存储和检索成本，同时保持合规性。

7. BigQuery 查询和容量调优

• 操作：按日期对大型事实表进行分区，按高选择性列进行聚类；用列投影替换 SELECT *；为热门的聚合操作引入物化视图；为 ETL 高峰窗口购买少量预留，并在批处理高峰期间使用 flex slots。
• 理由：分区/聚类可减少扫描的字节数；容量预留可稳定关键工作负载的性能和成本。

8. 数据库扩展和副本

• 操作：对于读取密集型的 Cloud SQL 服务，添加只读副本；调整连接池；设置存储自动扩容；测试故障切换以验证 RTO/RPO。对于 Bigtable，启用自动扩缩容并解决热点键问题。
• 理由：副本可以分流读取负载并保护写入路径；自动扩缩容使吞吐量与需求保持一致，无需手动过度预配。

9. 配额、并发和反压

• 操作：实施带抖动的指数退避；配置 Pub/Sub 订阅者流控；设置 Cloud Run 并发以平衡吞吐量和延迟；在下游边界添加熔断器。
• 理由：适当的反压可防止级联故障和失控重试，这些问题会降低 SLO 并增加成本。

10. 持续验证和治理

• 操作：每月运行负载测试和混沌演练；跟踪 SLO/错误预算；将 Recommender 和成本异常集成到 Sprint 计划中，并明确负责人和截止日期。
• 理由：迭代验证可确保节省的成本持续有效，并且随着工作负载的演变，SLO 保持正常（绿灯）状态。

← 可靠性、备份和灾难恢复 · 所有领域

练习这些题目 → · 在 ExamRoll.io 上限时练习 →

浏览 Google →