你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。

有关优化缩放成本的建议

  • 项目

适用于此 Azure Well-Architected 框架成本优化清单建议：

CO：12 优化缩放成本。 评估缩放单元中的替代缩放。 请考虑备用缩放配置，并与成本模型保持一致。 注意事项应包括针对每个实例、资源和缩放单元边界的继承限制的利用率。 使用控制需求和供应的策略。

本指南提供有关优化缩放成本的建议。 成本优化缩放是消除工作负载缩放效率低下的过程。 目标是降低缩放成本，同时仍满足所有非功能性要求。 花更少的钱以获得相同的结果。 通过优化缩放，可以避免不必要的费用、过度预配和浪费。 它还通过控制需求和限制供应，帮助防止成本意外飙升。 低效的缩放做法可能会导致工作负载和运营成本增加，并会对工作负载的整体财务运行状况产生负面影响。

定义

术语 定义
自动缩放 一种缩放方法，可在满足一组条件时自动添加或删除资源。
成本指标 与工作负载成本相关的数字数据。
纵向缩减 一种垂直缩放策略，该策略转换为较低的 SKU，以便为工作负载提供更少的资源。
缩小 一种水平缩放策略，用于删除实例，以便为工作负载提供更少的资源。
向外扩展 一种水平缩放策略，用于添加实例以向工作负载提供更多资源。
缩放单元 按比例缩放到一起的一组资源。
纵向扩展 一种垂直缩放策略，该策略将转移到更高的 SKU，以便为工作负载提供更多资源。
库存单位 (SKU) Azure 服务的服务层。
使用情况数据 使用情况数据是 (实际) 的直接信息，或者是代理) 有关使用任务、服务或应用程序量 (间接/代表性信息。

关键设计策略

成本优化缩放的目标是在最后一个负责任的时刻纵向扩展和横向扩展，并在可行时尽快纵向缩减和缩减。 若要优化工作负载的缩放，可以评估缩放单元中的替代缩放选项，并将其与成本模型保持一致。 缩放单元表示可独立缩放或一起缩放的资源的特定分组。 应设计缩放单元来处理特定数量的负载，它们可以包含多个实例、服务器或其他资源。 需要评估工作负载缩放单元和模型替代项的成本效益。

如果不使用缩放，请参阅有关 缩放工作负载的指南。 需要确定应用程序是否可以缩放。 无状态应用程序更易于缩放，因为它们可以同时处理多个请求。 此外，评估应用程序是否是使用分布式系统原则生成的。 分布式系统可以通过跨多个节点分配工作负载来处理增加的负载。 但是，单一实例应用程序设计为在任何给定时间都只运行一个实例。 因此，缩放可能不适用于所有工作负载。

评估横向扩展与纵向扩展

评估横向扩展与纵向扩展涉及确定在增加现有系统中的资源 (纵向扩展) 或添加该系统的更多实例 (根据各种因素（如定价、工作负载要求和可接受的停机时间）横向扩展) 之间确定最经济高效的方法。 选择正确的缩放方法可以节省大量成本，确保只需为所需内容付费，同时仍满足性能和可靠性标准。

目标是根据服务层定价、工作负载特征、可接受的停机时间和成本模型确定最经济高效的选择。 对于某些人来说，选择数量较少的更昂贵的实例可能更经济。 相反，对于其他层，具有更多实例的更便宜的层可能更好。 若要做出明智的决策，需要分析设置中的实际数据或代表性数据，并评估每个策略的相对成本优势。 若要评估最经济高效的方法，请考虑以下建议：

  • 收集使用情况数据：收集实际生产数据或表示工作负载使用模式和资源利用率的代理数据。 此数据应包括 CPU 使用率、内存使用率、网络流量等指标，以及影响缩放成本的任何其他相关指标。

  • 定义成本指标：确定与工作负载相关的成本指标，例如每小时成本、每事务成本或每资源使用单位成本。 这些指标有助于比较不同缩放选项的成本效益。

  • 收集使用情况数据：收集实际生产数据或表示工作负载使用模式和资源利用率的代理数据。 此数据应包括 CPU 使用率、内存使用率、网络流量等指标，以及影响缩放成本的任何其他相关指标

  • 定义成本指标：确定与工作负载相关的成本指标，例如每小时成本、每事务成本或每资源使用单位成本。 这些指标有助于比较不同缩放选项的成本效益。

  • 请参阅要求：在横向扩展和纵向扩展策略之间做出决定时，请考虑工作负荷的可靠性、性能和缩放要求。 横向扩展可以通过冗余提高可靠性。 纵向扩展会增加资源的容量，但纵向扩展的容量可能会受到限制。

  • 考虑资源限制：评估缩放选项时，请务必考虑每个实例、资源和缩放单元边界的固有限制。 请注意每个资源的缩放上限，并相应地进行规划。 此外，请记住订阅和其他资源的限制。

  • 测试缩放：为不同的缩放方案创建测试，包括横向扩展和纵向扩展选项。 应用使用情况数据，模拟不同缩放配置下的工作负载行为。 使用建模的缩放方案进行实际测试。

  • 计算成本：使用收集的数据和成本指标来计算与每个缩放配置相关的成本。 请考虑实例定价、资源利用率以及与缩放相关的任何额外费用等因素。

优化自动缩放

优化自动缩放策略涉及优化自动缩放，以便根据工作负荷的非功能要求对负载更改做出响应。 可以通过调整阈值并使用适当的冷却期来限制过度缩放活动。 若要优化自动缩放，请考虑以下建议：

  • 分析当前的自动缩放策略：了解现有策略及其行为以响应不同的负载级别。

  • 请参阅非功能要求：确定需要考虑的特定非功能性要求，例如响应时间、资源利用率或成本。

  • 调整缩放阈值：根据工作负载特征和非功能性要求调整缩放阈值。 根据一段时间内的 CPU 使用率、网络流量或队列长度等因素设置纵向扩展或缩减的阈值。

  • 调整冷却期：调整冷却期，以防止临时负载峰值触发过度缩放活动。 冷却期在缩放事件之间引入延迟，使系统能够在进一步缩放操作之前保持稳定。

  • 监视和微调：持续监视系统的行为和性能。 分析缩放活动并根据需要调整策略，以优化成本并满足所需的非功能要求。

权衡：减少缩放事件数会增加遇到与缩放相关的问题的可能性。 这意味着你将消除额外的缓冲或缓冲区，以帮助管理潜在的问题或缩放延迟。

考虑基于事件的缩放

事件驱动的自动缩放允许应用程序根据特定事件或触发器（而不是 CPU 或内存利用率等传统指标）动态调整资源。 例如，Kubernetes 事件驱动的自动缩放 (KEDA) 可以根据缩放程序（如 Kafka 主题的长度）缩放应用程序。 精度有助于防止不必要的缩放波动和资源浪费。 高精度最终可优化成本。 若要使用基于事件的缩放，请执行以下步骤：

  • 选择事件源：确定触发缩放单元缩放的事件源。 源可以是消息队列、流式处理平台或任何其他事件驱动系统。

  • 设置事件引入：将应用程序配置为使用所选事件源中的事件。 它通常涉及建立连接、订阅相关主题或队列以及处理传入事件。

  • 实现缩放逻辑：编写逻辑，根据传入事件确定缩放单元何时以及如何缩放。 此逻辑应考虑诸如事件数、传入事件的速率或任何其他相关指标等因素。

  • 与缩放机制集成：根据应用程序的运行时环境，可以使用不同的缩放机制来调整分配给应用程序的资源。

  • 配置缩放规则：定义缩放规则，这些规则指定缩放单元在响应事件时应如何缩放。 这些规则可以基于阈值、模式或符合应用程序要求的任何其他条件。 缩放阈值应与业务指标相关。 例如，如果再添加两个实例，则可以在购物车处理中再支持 50 个用户。

  • 测试和监视：通过使用不同的事件方案测试基于事件的缩放实现的行为。 监视缩放操作，并确保操作符合预期。

权衡 配置和微调基于事件的自动缩放可能比较复杂，配置不当可能会导致资源过度预配或预配不足。

优化供需

根据供应量控制需求。 在使用量决定缩放的工作负载上，成本与缩放相关。 若要优化缩放成本，可以最大程度地减少缩放支出。 可以通过将需求分配到其他资源来减轻需求，也可以通过实现优先级队列、网关卸载、缓冲和速率限制来减少需求。 这两种策略都可以防止由于缩放和资源消耗而导致的意外成本。 还可以通过限制缩放限制来控制供应。 若要优化工作负载需求和供应，请考虑以下建议。

卸载需求

卸载需求是指将资源需求分发或转移给其他资源或服务的做法。 可以使用各种技术或策略：

  • 缓存：使用缓存来存储经常访问的数据或内容，从而减少后端基础结构上的负载。 例如，使用内容分发网络 (CDN) 缓存和提供静态内容，从而减少缩放后端的需求。 但是，并非每个工作负载都可以缓存数据。 需要最新实时数据的工作负载（如交易或游戏工作负载）不应使用缓存。 缓存的数据将是旧的，与用户无关。

    权衡。 缓存可能会在缓存失效、一致性和管理缓存过期方面带来挑战。 请务必仔细设计和实现缓存策略，以避免潜在的权衡。

  • 内容卸载：将内容卸载到外部服务或平台，以减少基础结构上的工作负载。 例如，可以将这些文件托管在独立于主服务器的单独存储服务中，而不是在主服务器上存储视频文件。 可以直接从存储服务加载这些大型文件。 此方法释放服务器上的资源，使你能够使用较小的服务器。 将大型文件存储在单独的数据存储中可能更便宜。 可以使用 CDN 来提高性能。

  • 负载均衡：使用负载均衡在多个服务器之间分配传入请求。 负载均衡均匀分配工作负载，防止任何单一服务器不堪重负。 负载均衡器可优化资源利用率并提高基础结构的效率。

  • 数据库卸载：通过将数据库操作卸载到单独的数据库服务器或专用服务，减少main应用程序服务器上的负载。 例如，将 CDN 用于静态内容缓存，将 Redis 缓存用于动态内容 (数据库) 缓存中的数据。 数据库分片、只读副本或使用托管数据库服务等技术也可以降低负载。

    权衡： 将特定任务卸载到备用资源有助于减少或避免与缩放相关的额外缩放和成本。 但是，请务必考虑卸载可能带来的操作和维护挑战。 为工作负载选择最合适的卸载技术时，进行全面的成本效益分析至关重要。 此分析可确保所选方法在预期的节省和操作复杂性方面既有效又可行。

减少需求

减少资源需求意味着实施有助于最大程度地减少工作负荷中的资源利用率的策略。 卸载需求将需求转移到其他资源。 减少需求会降低对工作负载的需求。 通过减少需求，可以避免过度预配资源和为未使用或未充分利用的容量付费。 应使用代码级设计模式来减少对工作负载资源的需求。 若要通过设计模式减少需求，请执行以下步骤：

  • 了解设计模式：熟悉促进资源优化的各种设计模式。

  • 分析工作负载要求：评估工作负载的特定要求，包括其预期需求模式、峰值负载和资源需求。

  • 选择适当的设计模式：选择符合工作负载要求和目标的设计模式。 例如，如果工作负载遇到需求波动，事件驱动的缩放和限制模式可以通过动态分配资源来帮助管理工作负载。 将所选设计模式应用于工作负载体系结构。 可能需要分离工作负载组件、容器化应用程序、优化存储利用率等。

  • 持续监视和优化：定期评估实现的设计模式的有效性，并根据需要进行调整。 监视资源使用情况、性能指标和成本优化机会。

通过执行这些步骤并使用适当的设计模式，可以降低资源需求、优化成本，并确保工作负载高效运行。

使用以下设计模式来减少需求：

  • 缓存旁：模式检查缓存以查看数据是否已存储在内存中。 如果在缓存中找到数据，应用程序可以快速检索并返回数据，从而减少查询永久性数据存储的需要。

  • 声明检查：通过将数据与消息流分开，此模式可减小消息大小并支持更经济高效的消息传递解决方案。

  • 竞争使用者：此模式通过应用分布式和并发处理来有效地处理队列中的项。 此设计模式通过基于队列深度的缩放和对最大并发使用者实例设置限制来优化成本。

  • 计算资源整合：此模式通过组合共享基础结构上的多个应用程序或组件来增加密度并合并计算资源。 它可以最大化资源利用率，避免未使用的预配容量并降低成本。

  • 部署缩放单元：使用部署标记具有多项优势，例如，对设备组进行异地分布、将新功能部署到特定标记，以及观察每个设备的成本。 部署标记可实现更好的可伸缩性、容错和高效的资源利用率。

  • 网关卸载：此模式卸载网关设备中的请求处理，将成本从每个节点的资源重定向到网关实现。 使用此设计模式可以降低集中式处理模型中的拥有成本。

  • 发布者/订阅服务器：此模式分离体系结构中的组件，将直接通信替换为中间消息中转站或事件总线。 它支持事件驱动方法和基于使用量的计费，避免过度预配。

  • 基于队列的负载调配：模式缓冲队列中的传入请求或任务。 缓冲可以平滑工作负荷，并减少过度预配资源以处理峰值负载的需求。 以异步方式处理传入的请求以降低成本。

  • 分片：此模式将特定请求定向到逻辑目标，允许通过数据并置进行优化。 分片可以通过使用较低规格的计算或存储资源的多个实例来节省成本。

  • 静态内容托管：此模式通过使用专为此目的设计的托管平台高效地提供静态内容。 它避免使用更昂贵的动态应用程序主机，从而优化资源利用率。

  • 限制：此模式对速率 (速率施加限制，限制对资源或组件的传入请求) 或吞吐量。 它有助于为成本建模提供信息，并可直接绑定到应用程序的业务模型。

  • 附属密钥：此模式授予对资源的安全和独占访问权限，而无需涉及更多组件，从而减少对中间资源的需求并提高效率。

控制供应

控制供应的一种方法是定义你愿意在特定资源或服务上花费的金额上限。 这是控制成本并确保支出不超过特定水平的重要策略。 制定预算并监视支出，以确保其保持在定义的金额内。 可以使用成本管理平台、预算警报或跟踪使用情况和支出模式。 某些服务允许限制供应和限制速率，并且应在有用的情况下使用这些功能。

控制供应是指定义你愿意在特定资源或服务上花费的金额上限。 这是一个重要的策略，因为它有助于控制成本，并确保费用不会超过特定水平。 建立预算并监视支出，以确保它保持在定义的阈值范围内。 可以使用成本管理平台、预算警报或跟踪使用情况和支出模式。 某些服务允许限制供应和限制速率，并且应在有用的情况下使用这些功能。

权衡：当需求增加时，更严格的限制可能会导致错过缩放的机会，从而可能影响用户体验。 这可能会导致关闭或无法响应负载。 请务必在成本优化与确保有足够的资源来满足业务需求之间取得平衡。

Azure 便利化

评估横向扩展与纵向扩展：Azure 提供了一个测试环境，可在其中部署和测试不同的缩放配置。 通过使用实际工作负载数据或代理数据，可以模拟真实场景并衡量对成本的影响。 Azure 提供用于性能测试、负载测试和监视的工具和服务，可帮助评估横向扩展与纵向扩展选项的成本效益。

Azure 通过各种工具和服务（例如 Azure 顾问）提供成本管理建议。 这些建议分析使用模式、资源利用率和缩放配置，为优化成本提供见解和建议。

Azure 负载测试 是一项完全托管的负载测试服务，可生成大规模负载。 该服务可以模拟应用程序的流量，且无需其托管位置。 开发人员、测试人员和质量保证 (QA) 工程师可以使用负载测试来优化应用程序性能、可伸缩性或容量。

优化自动缩放：许多 Azure 计算服务支持部署多个相同的实例，并快速优化缩放阈值和策略。 Azure 提供自动缩放功能，使你能够根据工作负载需求自动调整实例或资源的数量。 可以定义缩放规则和阈值以触发横向扩展或横向缩减操作。 通过使用自动缩放，可以通过根据实际需求动态缩放资源来优化资源分配和成本效益。

Azure 维护 订阅和服务限制的列表。 可以在每个资源组中部署的资源实例数有一般限制，但有一些例外。 有关详细信息，请参阅 每个资源组的资源实例限制。

优化需求和供应：Azure Monitor 提供应用程序和基础结构的性能和运行状况的见解。 可以使用 Azure Monitor 监视资源负载，并分析一段时间内的趋势。 通过使用 Azure Monitor 收集的指标和日志，可以确定可能需要调整缩放的区域。 此信息可指导优化自动缩放策略，以确保它符合非功能性要求和成本优化目标。

  • 卸载供应：Azure 具有名为 Azure Front Door 的新式云内容分发网络 (CDN) ，缓存服务 (Azure Cache for Redis 和 Azure HPC 缓存) 。 CDN 缓存的内容更靠近最终用户，从而减少网络延迟并缩短响应时间。 缓存将数据的副本存储在main数据存储的前面，从而减少了对后端的重复请求的需求。 通过使用 CDN 和缓存服务，可以优化性能并降低服务器上的负载，以节省潜在的成本。

  • 控制供应：Azure 还允许为云工作负载设置资源限制。 通过定义资源限制，可以确保工作负荷保留在分配的资源中，并避免不必要的成本。 Azure 提供了各种机制来设置资源限制，例如配额、策略和预算警报。 这些机制有助于监视和控制资源使用情况。

    API 管理可以对请求进行速率限制和限制。 限制传入请求是 Azure API 管理的重要功能。 通过控制请求的速率或传输的请求/数据总量，API 管理让 API 提供程序能够保护其 API 不被滥用，为不同的 API 产品层创造价值。

成本优化清单

请参阅完整的一组建议。

成本优化清单