Well-Architected Framework 的可持续性核心中的这一原则提供了相关建议，可帮助您优化工作负载在 中的资源用量。Google Cloud Google Cloud
原则概览
优化资源用量对于提升云环境的可持续性至关重要。预配的每项资源（从计算周期到数据存储）都会直接影响能源用量、用水强度和碳排放量。如需减少工作负载对环境的影响，您需要在预配、管理和使用云资源时做出明智的选择。
建议
如需优化资源用量，请考虑以下部分中的建议。
实现自动伸缩和动态伸缩
自动伸缩和动态伸缩可确保资源用量达到最佳水平，这有助于防止空闲或过度预配的基础架构造成能源浪费。减少能源浪费意味着降低费用和碳排放量。
请使用以下方法来实现自动扩缩和动态扩缩。
使用横向伸缩
对于大多数云优先应用，横向伸缩是首选的伸缩技术。您无需增加每个实例的大小（称为 纵向伸缩），而是添加实例来分配负载。例如，您 可以使用 代管式实例组 (MIG) 自动扩容一组 Compute Engine 虚拟机。横向扩缩的基础架构更具弹性，因为实例的故障不会影响应用的可用性。对于负载级别可变的应用，横向伸缩也是一种资源高效的技术。
配置适当的伸缩政策
根据工作负载的要求配置自动扩缩设置。 定义特定于应用行为的自定义指标和阈值。 除了仅依赖 CPU 利用率之外，还可以考虑异步任务的队列深度、请求延迟时间和自定义应用指标等指标。如需防止频繁的不必要伸缩或抖动，请定义明确的伸缩 政策。例如，对于在 Google Kubernetes Engine (GKE) 中部署的工作负载，请配置适当的 集群自动扩缩政策。
结合使用被动伸缩和主动伸缩
借助被动伸缩，系统会根据实时负载变化进行伸缩。 此技术适用于负载出现不可预测峰值的应用。
主动伸缩适用于具有可预测模式的工作负载，例如固定的每日营业时间和每周报告生成。对于此类工作负载，请使用计划的自动扩缩来预先预配资源，以便它们能够处理预期的负载级别。此技术可防止争抢资源，并确保用户体验更顺畅、效率更高。此技术还有助于您主动规划已知的负载高峰，例如大型特惠活动和重点营销活动。
Google Cloud 代管式服务和功能（例如 GKE Autopilot、Cloud Run 和 MIG）会通过学习工作负载模式自动管理主动伸缩。默认情况下，当 Cloud Run 服务未收到任何流量时，它会缩容到零个实例。
设计无状态应用
如需让应用进行横向扩缩，其组件应为无状态组件。 这意味着特定用户的会话或数据不会绑定到单个计算实例。当您将会话状态存储在计算实例之外（例如在 Memorystore for Redis 中）时，任何计算实例都可以处理来自任何用户的请求。这种设计方法可实现无缝且高效的横向伸缩。
使用调度和批处理
批处理非常适合大规模非紧急工作负载。批处理作业有助于优化工作负载，以提高能效和降低费用。
请使用以下方法来实现调度和批处理作业。
安排在低碳强度时运行
安排批量作业在低碳区域运行，并在当地电网清洁能源占比高的时段运行。如需确定某个区域一天中碳排放强度最低的时段，请使用 碳足迹报告。
将 Spot 虚拟机用于非关键工作负载
Spot 虚拟机 让您能够以大幅折扣的价格利用未使用的 Compute Engine 容量。 Spot 虚拟机可能会被抢占，但它们提供了一种经济高效的方式来处理大型数据集，而无需专用且始终可用的资源。 Spot 虚拟机非常适合非关键的容错批处理作业。
整合和并行化作业
如需减少启动和关闭单个作业的开销，请将类似作业分组到一个大型批处理中。在 Batch等 服务上运行这些大批量工作负载。 该服务会自动预配和管理必要的基础架构，这有助于确保最佳资源利用率。
使用代管式服务
Batch 和 Dataflow 等代管式服务会自动处理资源预配、调度和监控。云平台会处理资源优化。您可以专注于应用逻辑。例如， Dataflow 会根据流水线中的数据量自动扩缩工作器的数量 ，因此您无需为空闲资源付费。
将虚拟机机器系列与工作负载要求相匹配
您可以用于 Compute Engine 虚拟机的机器类型分为 多个 机器系列， 这些机器系列针对不同的工作负载进行了优化。请根据工作负载的要求选择适当的机器系列。
| 机器家族 | 建议用于的工作负载类型 | 可持续性指南 |
|---|---|---|
| 通用实例（E2、N2、N4、Tau T2A/T2D）: 这些实例提供均衡的 CPU 与内存比率。 | Web 服务器、微服务、中小型数据库和 开发环境。 | E2 系列由于其 动态分配资源而具有很高的成本效益和能效。Tau T2A 系列使用基于 Arm 的 处理器，对于大规模工作负载，这些处理器通常具有更高的单位性能 能效。 |
| 计算优化型实例（C2、C3）：这些实例提供较高的 vCPU 与内存比率和较高的单核心性能。 | 高性能计算 (HPC)、批处理、游戏服务器、 和基于 CPU 的数据分析。 | 借助 C 系列实例，您可以更快地完成 CPU 密集型任务，从而缩短作业的总计算时间和能源消耗。 |
| 内存优化型实例（M3、M2）：这些实例 专为需要大量内存的工作负载而设计。 | 大型内存数据库和数据仓库，例如 SAP HANA 或 内存分析。 | 内存优化型实例可将内存密集型 工作负载整合到较少的物理节点上。与使用多个较小的 实例相比，这种整合可减少所需的 总能耗。高性能内存可缩短数据访问延迟时间，从而 减少 CPU 处于活跃 状态的总时间。 |
| 存储优化型实例 (Z3)： 这些实例 提供高吞吐量、低延迟的本地 SSD 存储。 | 数据仓库、日志分析以及 SQL、NoSQL 和向量数据库。 | 存储优化型实例可在本地处理海量数据集，这 有助于消除用于跨位置网络数据 出站流量的能源。当您将本地存储用于高 IOPS 任务时，可以避免 过度预配多个标准实例。 |
| 加速器优化型实例（A3、A2、G2）：这些 实例专为 GPU 和 TPU 加速的工作负载而构建，例如 AI、 机器学习和 HPC。 | 机器学习模型训练和推理以及科学模拟。 | TPU 专为实现最佳能效 而设计。它们可提供更高的每瓦计算量。 与仅使用 CPU 的替代方案相比，搭载 NVIDIA H100 GPU 的 A3 系列等 GPU 加速实例在训练大型 模型时能效要高得多。虽然 GPU 加速实例 的名义功耗较高，但任务完成速度要快得多。 |
升级到最新的机器类型
使用最新的机器类型可能有助于提高可持续性。更新机器类型时，通常会将其设计为更节能，并提供更高的每瓦性能。使用最新机器类型的虚拟机可能会以较低的功耗完成相同的工作量。
CPU、GPU 和 TPU 通常受益于芯片架构的技术进步，例如：
- 专用核心：处理器的进步通常包括针对常见工作负载的专用 核心或指令。例如，CPU 可能具有用于向量运算的专用核心或集成的 AI 加速器。当这些任务从主 CPU 卸载时，任务完成效率更高，能耗更低。
- 改进的电源管理：芯片架构的进步通常 包括更复杂的电源管理功能，例如根据工作负载动态 调整电压和频率。这些电源管理功能使芯片能够在峰值效率下运行，并在空闲时进入低功耗状态，从而最大限度地减少能耗。
芯片架构的技术改进为可持续发展和费用带来了以下直接优势：
- 更高的每瓦性能：这是可持续性的关键指标。 例如，对于相同的能源消耗， C4 虚拟机的性价比比 C3 虚拟机高 40% 。 C4A 处理器的能效比 同类 x86 处理器高 60%。借助这些性能，您可以更快地完成任务，或者使用更少的实例来处理相同的负载。
- 更低的能源消耗：借助改进的处理器，计算资源在给定任务中的使用时间更短，从而降低了总体能源使用量和碳足迹。对于短期计算密集型工作负载（例如批处理作业和机器学习模型训练），碳排放影响尤其高。
- 最佳资源利用率：最新的机器类型通常 更适合现代软件，并且与云平台的高级 功能更兼容。这些机器类型通常可以提高资源利用率，从而减少过度预配的需求，并有助于确保每瓦电力都能得到高效利用。
部署容器化应用
您可以将基于容器的全代管式服务（例如 GKE 和 Cloud Run）用作可持续云计算策略的一部分。这些服务有助于优化资源利用率并自动执行资源管理。
利用 Cloud Run 的缩减至零功能
Cloud Run 提供了一个代管式无服务器环境，当服务没有传入流量或作业完成时，该环境会自动将实例缩减至零。自动扩缩有助于消除空闲基础架构的能耗。资源仅在主动处理请求时才会供电。此策略对于间歇性或事件驱动型工作负载非常有效。对于 AI 工作负载，您可以将 GPU 与 Cloud Run搭配使用， 这样您只需在使用 GPU 时才需要消耗 GPU 并为其付费。
使用 GKE 自动执行资源优化
GKE 是一个容器编排平台，可确保应用仅使用所需的资源。为帮助您自动执行资源优化，GKE 提供了以下方法：
- 装箱: GKE Autopilot 会智能地将多个 容器打包到可用节点上。装箱可最大限度地提高每个节点的利用率，并减少空闲或未充分利用的节点数量，这有助于降低能源消耗。
- Pod 横向自动扩缩 (HPA)： 借助 HPA，系统会根据预定义的指标（例如 CPU 用量或自定义应用专用指标）自动调整容器副本（Pod）的数量。 例如，如果您的应用流量激增，GKE 会添加 Pod 以满足需求。当流量减少时，GKE 会减少 Pod 的数量。这种动态伸缩可防止过度预配资源，因此您无需为不必要的计算容量付费或供电。
- Pod 纵向自动扩缩 (VPA)： 您可以将 GKE 配置为自动调整各个容器的 CPU 和 内存分配及限制。此配置可确保容器不会分配到超出其需求的资源，这有助于防止资源过度预配。
- GKE Pod 多维自动扩缩： 对于复杂的工作负载，您可以同时配置 HPA 和 VPA，以 优化 Pod 的数量和每个 Pod 的大小。此技术有助于确保在满足所需性能的前提下，尽可能减少能源消耗。
- 拓扑感知型调度 (TAS)： TAS 通过根据数据中心基础架构的物理结构放置 Pod，来提高 GKE 中 AI 和机器学习工作负载的网络效率。TAS 会策略性地将工作负载放置在同一位置，以最大限度地减少网络跃点数。这种放置方式有助于缩短通信延迟时间和能源消耗。通过优化节点和专用硬件的物理对齐方式，TAS 可加快任务完成速度，并最大限度地提高大规模 AI 和机器学习工作负载的能效。
配置碳感知型调度
在 Google，我们会不断将工作负载转移到 提供最清洁电力的位置 和 时间。我们还会将旧设备重新用于其他用例。您可以使用这种碳感知型调度策略来确保容器化工作负载使用清洁能源。
如需实现碳感知型调度，您需要了解某个区域的数据中心实时使用的能源组合。您可以从 GitHub 中的 Carbon free energy for Google Cloud regions 代码库或 BigQuery 公开数据集中以机器可读格式获取此信息。 用于计算 Google 年度碳数据集的每小时电网混合碳强度数据来自 Electricity Maps。
如需实现碳感知型调度，我们建议使用以下方法：
- 地理位置转移：安排工作负载在 可再生能源占比更高的区域运行。这种方法可让您使用更清洁的电网。
- 时间转移：对于非关键的灵活工作负载（例如批处理 ），请将工作负载配置为在非高峰时段或可再生能源最充足时运行 。这种方法称为时间转移，有助于在清洁能源可用时加以利用，从而减少总体碳足迹。
设计节能型灾难恢复方案
为灾难恢复 (DR) 做准备通常需要在辅助区域中预先预配冗余资源。但是，空闲或未充分利用的资源可能会造成严重的能源浪费。选择可最大限度地提高资源利用率并最大限度地减少碳排放影响的灾难恢复策略，同时不影响恢复时间目标 (RTO)。
针对冷启动效率进行优化
请使用以下方法来最大限度地减少或消除辅助（灾难恢复）区域中的活跃资源：
- 优先使用冷灾难恢复：使灾难恢复区域中的资源处于关闭状态 或缩减至零状态。这种方法有助于消除空闲计算资源的碳足迹。
- 利用无服务器故障切换：将 Cloud Run 等代管式无服务器服务 用作灾难恢复端点。Cloud Run 在不使用时会缩减至零，因此您可以维护一个灾难恢复拓扑，该拓扑在流量重定向到灾难恢复区域之前不会消耗任何能源。
- 使用基础架构即代码 (IaC) 自动执行恢复：无需让灾难恢复站点中的资源保持运行（暖），而是使用 Terraform 等 IaC 工具仅在需要时快速预配环境。
平衡冗余和利用率
资源冗余是造成能源浪费的主要原因。如需减少冗余，请使用以下方法：
- 优先使用主动-主动模式，而不是主动-被动模式：在主动-被动设置中，被动站点中的资源处于空闲状态，这会导致能源浪费。经过最佳调整的主动-主动架构可确保两个区域中的所有预配资源都主动为流量提供服务。这种方法有助于最大限度地提高基础架构的能效。
- 合理调整冗余：仅在必须复制数据和服务以满足高可用性或 灾难恢复要求时，才跨 区域复制数据和服务。每增加一个副本，都会增加永久性存储和网络出站流量的能源费用。