Amazon ElastiCache Well-Architected Lens 成本优化支柱 - Amazon ElastiCache
成本 1：如何识别和跟踪与 ElastiCache 资源相关的成本？ 您如何建立让用户能够创建、管理和处置已创建资源的机制？成本 2：如何使用持续监控工具来优化与 ElastiCache 资源关联的成本？成本 3：您是否应该使用支持数据分层的实例类型？ 数据分层有哪些优点？ 何时不使用数据分层实例？
Amazon Web Services 文档中描述的 Amazon Web Services 服务或功能可能因区域而异。要查看适用于中国区域的差异，请参阅 中国的 Amazon Web Services 服务入门 (PDF)。

本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

Amazon ElastiCache Well-Architected Lens 成本优化支柱

成本优化支柱侧重于避免不必要的成本。关键主题包括了解和控制资金花在哪里、选择最合适的节点类型（使用支持基于工作负载需求进行数据分层的实例）、相应数量的资源类型（有多少只读副本）、分析一段时间内的支出，以及在不超支的情况下进行扩展以满足业务需求。

成本 1：如何识别和跟踪与 ElastiCache 资源相关的成本？ 您如何建立让用户能够创建、管理和处置已创建资源的机制？

问题级简介：要了解成本指标，需要多个团队参与和协作：软件工程、数据管理、产品负责人、财务和领导层。要确定关键成本驱动因素，则要求所有相关方了解服务使用控制杠杆和成本管理的利弊，这通常是成功与不太成功的成本优化工作之间的关键区别。确保您有适当的流程和工具来跟踪从开发到生产和停用期间创建的资源，这有助于您管理与 ElastiCache 关联的成本。

问题级优势：要持续跟踪与您工作负载关联的所有成本，需要深入了解将 ElastiCache 作为其组件之一的架构。此外，您应该制定成本管理计划，以收集使用情况并将其与预算进行比较。

  • [必需] 建立一个云卓越中心（CCoE），作为其创始章程之一，负责定义、跟踪组织的 ElastiCache 使用情况，并根据相关指标采取措施。如果 CCoE 存在且正常运行，请确保其知道如何读取和跟踪与 ElastiCache 关联的成本。创建资源时，使用 IAM 角色和 IAM policy 来验证只有特定的团队和组才能实例化资源。这确保了成本与业务成果相关联，并从成本角度建立了明确的问责制。

    1. CCoE 应基于分类数据识别、定义和发布与关键 ElastiCache 使用情况相关的成本指标（每月定期更新这），例如：

      1. 使用的节点类型及其属性：标准与内存优化型、按需实例与预留实例、区域和可用区

      2. 环境类型：免费环境、开发环境、测试环境和生产环境

      3. 备份存储和保留策略

      4. 区域内和跨区域的数据传输

      5. 在 Amazon Outposts 上运行的实例

    2. CCoE 由一个跨职能团队组成，其代表来自组织中软件工程、数据管理、产品团队、财务团队和领导团队的非专属代表。

    [资源]：

  • [必需] 使用成本分配标签以较低的粒度跟踪成本。使用 Amazon 成本管理来可视化、了解和管理一段时间内的 Amazon 成本和使用情况。

    1. 使用标签来整理资源，并可以使用成本分配标签来细致地跟踪 Amazon 成本。在您激活成本分配标签后，Amazon 将使用成本分配标签来整理您的资源分配报告中的资源成本，以方便您对 Amazon 成本进行分类和跟踪。Amazon 提供了两种类型的成本分配标签：Amazon 生成的标签和用户定义的标签。Amazon 将为您定义、创建和应用 Amazon 生成的标签，而您将定义、创建和应用用户定义的标签。您必须先分别激活这两种类型的标签，然后这些标签才能显示在成本管理中或成本分配报告上。

    2. 使用成本分配标签整理 Amazon 账单，以反映您自己的成本结构。在 Amazon ElastiCache 中向资源添加成本分配标签时，将可以根据资源标签值对发票上的费用进行分组，从而跟踪您的成本。您应该考虑合并标签，以采用更高详细信息级别跟踪成本。

    [资源]：

  • [最佳] 将 ElastiCache 成本与涵盖整个组织的指标联系起来。

    1. 考虑业务指标以及延迟等运营指标 - 您业务模式中有哪些概念可以被不同角色理解？ 这些指标需要让组织中尽可能多的角色能够理解。

    2. 示例 - 同时服务的用户数、每个操作和用户的最大和平均延迟、用户参与度分数、用户每周返回率、会话长度/用户、放弃率、缓存命中率以及跟踪的键

    [资源]：

  • [良好] 在使用 ElastiCache 的整个工作负载中，保持最新的架构和运营指标和成本可见性。

    1. 了解您的整个解决方案生态系统，ElastiCache 往往是其技术组合中完整 Amazon 服务生态系统的一部分，例如，从客户端到 API Gateway、Redshift 和 QuickSight（用于报告工具）。

    2. 在架构图上映射解决方案的各个组成部分，包括客户端、连接、安全性、内存操作、存储、资源自动化、数据访问和管理。每层都连接到整个解决方案且具有其自身的需求和功能，可以助力和/或帮助您管理总体成本。

    3. 您的图表应包括计算、网络、存储、生命周期策略、指标收集的使用情况以及应用程序的操作和功能 ElastiCache 元素

    4. 工作负载的要求可能会不断变化，为了在工作负载成本管理中保持主动性，您必须继续维护和记录您对基本组件以及主要功能目标的理解。

    5. 管理层在可见性、问责制、优先级划分和资源方面的支持对于您为 ElastiCache 制定有效的成本管理策略至关重要。

成本 2：如何使用持续监控工具来优化与 ElastiCache 资源关联的成本？

问题级简介：您需要在您的 ElastiCache 成本和应用程序性能指标之间取得适当的平衡。Amazon CloudWatch 提供关键运营指标的可见性，可以帮助您评测，相对于您的需求，您的 ElastiCache 资源是过度使用还是未得到充分利用。从成本优化的角度来看，您需要了解何时过度预调配，并能够开发适当的机制来调整您的 ElastiCache 资源的规模，同时保持运营、可用性、弹性和性能需求。

问题级优势：在理想状态下，您将预调配足够的资源来满足工作负载的运维需求，并且不会出现未充分利用的资源，从而导致成本状态欠佳。您需要能够识别和避免长时间运行规模过大的 ElastiCache 资源。

  • [必需] 使用 CloudWatch 监控您的 ElastiCache 集群，并分析这些指标与您 Amazon Cost Explorer 成本管理服务控制面板的相关性。

    1. ElastiCache 提供主机层面级指标（例如 CPU 使用率）和特定于缓存引擎软件的指标（例如缓存获取次数和缓存未命中数）。这些指标每隔 60 秒对每个缓存节点进行测量并发布结果。

    2. ElastiCache 性能指标（CPUUtilization、EngineUtilization、SwapUsage、CurrConnections 和 Evictions）可能表明您需要纵向扩展/缩减（使用更大/更小的缓存节点类型）或横向缩减/横向扩展（添加更多/更少的分片）。通过创建 PlayBook 矩阵来了解扩展决策的成本影响，该矩阵可估算满足应用程序性能阈值所需的额外成本以及最小和最大时间长度。

    [资源]：

  • [必需] 了解并记录您的备份策略和成本影响。

    1. 使用 ElastiCache，备份存储在 Amazon S3 中，而 Amazon S3 可提供持久存储。您需要了解与故障恢复能力有关的成本影响。

    2. 启用自动备份，这将删除超过保留期限的备份文件。

    [资源]：

  • [最佳] 作为一种深思熟虑的策略，应对实例使用预留节点，以管理已充分了解和记录的工作负载的成本。预留节点需支付预付费用，此费用取决于节点类型和预留时间长短（一年或三年）。此费用远低于按需节点产生的每小时使用费。

    1. 在收集到足够的数据来评估预留实例需求之前，您可能需要使用按需节点运行您的 ElastiCache 集群。规划和记录满足需求所需的资源，并比较不同实例类型（按需型与预留）的预期成本

    2. 定期评测新的可用缓存节点类型，并从成本和运营指标的角度评测将您的实例集迁移到新的缓存节点类型是否合理

成本 3：您是否应该使用支持数据分层的实例类型？ 数据分层有哪些优点？ 何时不使用数据分层实例？

问题级简介：选择适当的实例类型不仅会对性能和服务级别产生影响，还会对财务状况产生影响。实例类型具有不同的关联成本。选择一种或几种可以满足内存中所有存储需求的大型实例类型可能是一个自然而然的决定。但是，随着项目日趋成熟，这可能会对成本产生重大影响。要确保选择正确的实例类型，需要定期检查 ElastiCache 对象的空闲时间。

问题级优势：您应该清楚地了解各种实例类型对您当前和未来的成本有何影响。边际或定期的工作负载变化不应导致过多的成本变化。如果工作负载允许，支持数据分层的实例类型提供的每可用存储的价格将更优惠。这是因为每实例可用的 SSD 存储数据分层实例所支持的每实例的总数据容量要高得多。

  • [必需] 了解数据分层实例的局限性

    1. 仅适用于 ElastiCache for Redis 集群。

    2. 支持数据分层的实例类型非常有限。

    3. 仅支持 ElastiCache for Redis 版本 6.2 及更高版本

    4. 大型项目不会交换到 SSD。超过 128MiB 的对象保留在内存中。

    [资源]：

  • [必需] 了解您的工作负载定期访问数据库的百分比。

    1. 数据分层实例非常适合经常访问整个数据集的一小部分但仍需要快速访问其余数据的工作负载。换句话说，热数据与温数据的比例约为 20:80。

    2. 制定对象空闲时间的集群级跟踪。

    3. 超过 500Gb 数据的大型实现是不错的选择

  • [必需] 了解数据分层实例对于某些工作负载不是可选的。

    1. 访问不常用的对象会产生少许性能成本，因为这些对象会被交换到本地 SSD。如果您的应用程序对响应时间敏感，请测试对工作负载的影响。

    2. 不适合主要存储大小超过 128MiB 的大型对象的缓存。

    [资源]：

  • [最佳] 预留实例类型支持数据分层。这可确保在每个实例的数据存储量方面实现最低的成本。

    1. 在更好地了解您的需求之前，您可能需要使用非数据分层实例运行 ElastiCache 集群。

    2. 分析您的 ElastiCache 集群的数据使用模式。

    3. 创建定期收集对象空闲时间的自动作业。

    4. 如果您发现很大一部分对象（大约 80%）在认为适合您工作负载的时间段内处于空闲状态，请记录调查发现，并建议将集群迁移到支持数据分层的实例。

    5. 定期评测新的可用缓存节点类型，并从成本和运营指标的角度评测将您的实例集迁移到新的缓存节点类型是否合理。

    [资源]：