Google PCA: 成本、性能与可持续云设计 — 学习指南

By Laurynas Brazys · 5 September 2026 · #google #PCA #certification #exam-prep #study-guide

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

概述

成本、性能和可持续的云设计是需要协同优化的学科。在 Google Cloud 上构建高效的架构需要财务可见性、跟随需求的弹性容量、严格的数据生命周期管理、明智的网络布局和缓存策略，以及持续的测量。本节将解释在不牺牲可靠性、安全性或性能的前提下减少浪费的设计和运营模式，并重点介绍常见的失败模式和权衡，以避免昂贵的意外情况。

成本架构与财务问责

将财务控制作为平台基线的一部分来建立。

• 账单分析与分配

  • 将账单数据导出到 BigQuery，以便按项目、服务、SKU 和标签进行可查询的、近乎实时的支出分析。按天分区以实现可扩展的查询，并为财务和工程相关方设置数据集访问控制。
  • 使用带有警报阈值的预算来防止支出漂移。将预算警报路由到 Pub/Sub 并自动化响应（例如，暂停非关键工作负载）。请注意，警报不是事务性的，可能会有报告延迟；不要依赖它们作为控制失控作业的唯一手段。

• 标签、标记和成本归因

  • 标准化组织范围内的标签（cost_center、env、owner、app），并在预置时通过部署模板或策略即代码来强制执行它们。
  • 优先使用分层标记和文件夹/项目结构来反映成本回收/成本分摊模型。同时使用标签（资源级别）和标记（策略和计费范围）来实现精确的分配。

• 预算护栏和异常检测

  • 配置按项目和按产品组合设置的预算；设置多个阈值（例如，50%、80%、100%）和“预测性”警报以实现主动行动。
  • 使用 Recommender 的建议（空闲 VM、未挂载的磁盘、IP、未使用的承诺）来持续削减浪费。

• 实践示例

  • 在创建时应用标签：
    • gcloud compute instances create api-1 –labels=env=prod,cost_center=retail,owner=eng
  • 查询账单导出数据中未标记的支出，以通过 CI/CD 检查强制执行合规性。

常见的失败模式和权衡：

• 不一致的标签会破坏成本分配；通过组织策略和管道中的验证来强制执行。
• 没有按团队划分预算的集中式计费会妨碍问责制；在团队或产品级别创建预算。
• 预算警报延迟意味着快速的支出尖峰可能会超出预算；在可能的情况下增加上限和配额。

计算效率与性能

将资源与工作负载特征相匹配；自动化弹性；为稳定的基线负载预留或获取折扣。

• 规模优化和自定义机器类型

  • 持续分析 CPU、内存、磁盘 IOPS 和网络利用率以进行规模优化。使用自定义机器类型使 vCPU 和内存与应用的实际需求相匹配，避免为空闲内存付费。
  • 注意预留空间：目标是 60-75% 的持续 CPU 使用率，并确保有足够的内存预留空间以应对 GC 或峰值。过于激进的规模优化会增加节流或 OOMs 的风险。

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

  • 基于相关信号（CPU、负载均衡器容量或自定义队列深度）使用托管实例组自动扩缩容。配置预热期和缩容控制以防止抖动。
  • 对于非全天候运行的环境，调度 VM、GKE 节点池或 Cloud Run 最小实例的启动/停止，以避免空闲支出。一个简单的第一步是使用 Cloud Scheduler 触发一个 Cloud Run 作业，在夜间停止开发实例。

• 折扣工具

  • 承诺使用折扣：为符合条件的稳定使用量承诺 1-3 年。根据历史使用情况和业务预测来平衡承诺规模；过度承诺会浪费资金。
  • Spot VMs：非常适合容错、批处理或分布式工作负载。它们可以随时被回收；实施检查点机制和带有按需实例回退的多实例组。
    • 示例：gcloud compute instances create etl-spot –provisioning-model=SPOT
  • 容量预留：为关键实例集群预留可用区或区域容量，以缓解在区域性资源短缺期间扩容失败的风险。
    • 示例：gcloud compute reservations create web-capacity –zone=us-central1-a –machine-type=n2-standard-4 –vm-count=10

• 利用率指标和性能调优

  • 使用 Cloud Monitoring、Profiler 和 Trace 进行检测。测量 p50/p95 延迟、CPU steal、GC 时间和队列积压。在横向扩展之前优化热点代码路径。
  • 将对性能敏感的工作负载固定到具有足够 CPU 平台的区域和可用区，并在需要时考虑使用高吞吐量永久性磁盘或 Hyperdisk。

失败模式和权衡：

• 无限制的自动扩缩容可能会超出配额和成本目标；预先提高配额，设置最大副本数，并对已知的峰值使用预测性自动扩缩容。
• Spot VMs 可能导致部分实例集群流失；分散可用区并实施优雅终止钩子。
• 过度承诺 CUDs 或未充分利用的预留会造成沉没成本；每季度审查承诺。

存储、数据库和分析的成本性能

选择能够反映访问模式、保留策略和性能 SLO 的存储类别和数据库容量模型。

• 存储类别和生命周期策略

  • 对热数据使用 Standard，对每月访问一次的数据使用 Nearline，对每季度访问一次的数据使用 Coldline，对长期很少访问的数据使用 Archive。将数据和计算资源保留在同一区域以避免出站流量费用。
  • 应用生命周期管理来自动转换或删除对象。注意最短存储期限和检索费用；过早的类别转换可能弊大于利。
  • 生命周期策略示例（删除超过 90 天的对象）：
    • { “rule”: [{ “action”: {“type”: “Delete”}, “condition”: {“age”: 90} }]}
    • gsutil lifecycle set lifecycle.json gs://my-backups

• 数据传输和归档

  • 跨区域访问通常会产生出站流量费用；将生产者和消费者置于同一位置。使用 Private Google Access 和 VPC-SC 以注重成本效益的方式安全访问 Google API。对于长期归档，避免从 Archive 存储类别频繁检索数据，以防止产生高昂的检索费用。

• 数据库规模和性能

  • 关系型数据库：根据内存常驻工作集、IOPS 和只读副本进行规模调整。启用存储空间自动增加功能并监控复制延迟；当延迟威胁到 RPO/RTO 时，进行垂直扩缩或水平分片。
  • NoSQL/时间序列：使用 Bigtable 进行高吞吐、低延迟的数据注入，并通过合理的行键设计来避免热点。

• BigQuery 成本控制和容量模型

  • 按需模式（按扫描的 TB 数计费）：启动快，但有成本激增的风险。基于容量的预留：支出可预测，可控制并发和吞吐量。Flex commitments 可吸收短期峰值。
  • 通过分区和聚类优化查询；要求使用分区过滤器以防止全表扫描：
    • bq update –require_partition_filter=true myds.mytable
  • 为每个作业设置计费的字节数上限以控制支出：
    • bq query –use_legacy_sql=false –maximum_bytes_billed=100000000000 ‘SELECT …’
  • 在生产环境中使用物化视图、结果缓存、近似聚合，并避免使用 SELECT *。将存储和计算资源保留在同一区域。

故障模式和权衡：

• 将热点对象移动到 Coldline/Archive 会触发检索成本和提前删除费用。
• 无控制的 BigQuery 按需模式可能因未经过滤的扫描而导致成本失控；强制执行计费字节数上限和分区过滤器。
• 过度分片会增加数据库的操作复杂性；在拆分前进行基准测试。

网络、吞吐量、配额与可持续性设计

数据移动和并发设计对成本和性能有很大影响；可持续性选择则进一步优化了部署位置和调度策略。

• 网络出站、区域间流量、CDN 和缓存

  • 最小化跨区域跳转；仅在用户邻近性或合规性要求时才复制数据。使用 Cloud CDN 来分流静态和可缓存的动态内容；调整缓存键、TTL 和签名 URL 以获得高命中率。
  • 在靠近客户端（CDN）、VPC 边缘（代理缓存）以及服务内部（如 Memorystore 等内存缓存）进行缓存。注意陈旧数据和缓存失效风暴；定义明确的缓存控制标头。

• 性能测量、负载测试和扩缩容

  • 建立 SLO 并使用 Cloud Monitoring、Uptime checks、Cloud Trace 和 Profiler 进行测量。跟踪 p95/p99 延迟和饱和度信号。
  • 使用真实数据和思考时间进行负载测试。分阶段进行测试以避免触发全局速率限制；申请临时配额增加。
  • 使用水平副本、分片队列、分区主题以及由积压指标驱动的自动扩缩容器来扩展吞吐量。在可能的情况下，优先选择异步管道。

• 配额、并发、速率限制和背压

  • 盘点各区域的每项服务配额；对 429/5xx 响应强制执行带抖动的客户端指数退避。实施准入控制和基于队列的背压来保护依赖项。
  • 调整 Pub/Sub 的流控制（最大未完成消息数/字节数）、批处理和并行度。在 Cloud Run 和 GKE 中，适当调整并发以匹配 CPU 和内存，防止尾部延迟膨胀。

• 可持续性感知设计

  • 优先选择利用率高的无服务器和托管服务。在延迟和合规性允许的情况下，选择无碳能源比例较高的区域。
  • 在低碳窗口期调度批处理和弹性作业；使用 Carbon Footprint 报告来跟踪影响。
  • 使用高能效的机器类型，并在兼容的情况下考虑基于 ARM 的计算，以提高每瓦性能。

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

  • 定义架构护栏：强制性标签、预算警报、组织策略（例如，限制外部 IP）、SLO/错误预算和成本 SLO。
  • 与工程、安全和财务团队定期进行成本性能审查。集成 Recommender 和自定义仪表板；构建修复手册。
  • 明确权衡各种取舍：多区域与单区域（持久性和延迟 vs. 成本和出站流量）、加密和检查层（安全性 vs. CPU 和延迟）以及激进的自动扩缩容（性能 vs. 配额和支出风险）。

典型的故障模式和权衡：

• 针对单区域数据集进行跨区域分析会产生持续的出站流量；复制或迁移计算资源。
• CDN 配置错误导致命中率低；监控缓存命中率和源站出站流量以验证节省效果。
• 在部分中断期间缺乏背压会放大故障；实施熔断器并优雅地进行负载削减。

实际问题场景

Acme Learn 是一家在线教育公司，在直播活动期间会经历不可预测的晚间流量高峰。跨区域 BigQuery 查询、自动扩缩容激增以及静态资产的出站流量导致成本急剧上升。领导层还希望在不降低用户体验的情况下减少碳足迹。

方法：

1. 整合账单可见性并强制执行成本分摊

   • 创建到 BigQuery 的账单导出，并使用部署模板中标准化的标签和标记，按产品、环境和区域分段创建仪表板。
   • 理由：近乎实时的可见性将支出与责任团队挂钩，从而实现预算问责。标签支持精细的成本分摊和异常检测。

2. 重构分析架构，将计算和存储并置

   • 将事件分析数据集和计划查询移动到与流处理器相同的区域。对于 BigQuery，将高流量团队从按需模式切换到容量预留，预留大小根据峰值并发量设置，并带有一个小的弹性缓冲区。
   • 理由：并置消除了区域间的出站流量。基于容量的 BigQuery 在负载下稳定了成本，同时保持了性能。

3. 通过边缘缓存优化内容交付

   • 使用 Cloud CDN 为静态和半动态的课程资产提供前端服务，为高级内容设置明确的缓存控制标头和签名 URL。根据内容的易变性调整 TTL。
   • 理由：高缓存命中率将流量从源站转移到边缘，从而在高峰期减少出站流量和源站计算量，同时改善延迟。

4. 为直播活动强化自动扩缩容和预留

   • 为 API 层添加一个区域级托管实例组，其自动扩缩容器的目标同时基于 CPU 和请求积压。创建一个小的区域级容量预留，以保证活动期间的突发容量。在计划的会话之前启用预测性自动扩缩容。
   • 理由：双信号自动扩缩容能同时响应利用率和需求，而预留和预测性预热可避免冷启动延迟和容量短缺。

5. 应用计算组合：基础负载使用承诺，突发负载使用 Spot

   • 为基线 API 和数据处理工作负载购买 1 年期承诺。在 Spot VMs 上配置批处理转码和数据丰富作业，并使用检查点和多可用区实例组。
   • 理由：承诺降低了稳态成本；Spot VMs 为可中断的工作提供了低成本的弹性，而不会危及用户流量。

6. 建立存储生命周期和区域放置策略

   • 将热门课程元数据和缩略图保存在靠近服务计算资源的区域级 Standard 存储中。30 天后将日志和原始点击流转换到 Nearline，180 天后删除。对于合规性归档，使用 Archive 并记录检索 SLA。
   • 理由：将存储类别与访问模式对齐，在遵守保留策略的同时降低持续成本。

7. 为 BigQuery 使用设置护栏

   • 要求在大型表上使用分区过滤器，并为最大计费字节数设置项目级作业默认值。为常见聚合和分区摄取模式引入物化视图。
   • 理由：防止意外的全表扫描，稳定支出，并加速频繁的查询。

8. 通过背压和配额进行吞吐量工程

   • 集成 Cloud Tasks 以实现速率限制的工作流，并为 Pub/Sub 订阅者配置流控制。为第三方 API 实现带抖动的指数退避，并在 Cloud Run 中设置每个服务的并发上限。
   • 理由：控制需求以遵守配额，在流量激增时保护依赖项，并避免级联故障。

9. 将可持续性融入运营

   • 在可行的情况下优先选择无服务器，为分析工作选择无碳能源比例较高的区域，并在低碳窗口期安排非紧急的批处理作业。使用 Carbon Footprint 跟踪排放量，并将其纳入季度审查。
   • 理由：提高每瓦性能并减少碳足迹，同时对用户体验的权衡最小化。

10. 持续治理

    • 为每个产品创建预算和警报，通过策略强制执行标签，并建立月度成本-性能-SLO 审查。自动化基于 Recommender 的闲置资源和未挂载磁盘的清理工作。
    • 理由：持续的治理可以保持成果，防止倒退，并随着时间的推移平衡可靠性、安全性、性能和成本。

此设计减少了出站流量，稳定了分析成本，确保了直播活动期间的可预测性能，并在不影响用户体验的情况下推进了可持续发展目标。

← DevOps、交付工程与基础设施即代码 · 所有领域

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

浏览 Google →