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

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

亚马逊 Well-A ElastiCache rchitected 镜头成本优化支柱

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

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

    [资源]：

  • [良好] 保持 up-to-date 架构和运营可见性，了解所使用的整个工作负载的指标和成本 ElastiCache。

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

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

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

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

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

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

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

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

  • [必需] 用于 CloudWatch 监控您的ElastiCache 集群并分析这些指标与您的 Cost Explorer Amazon 仪表板的关系。

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

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

    [资源]：

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

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

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

    [资源]：

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

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

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

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

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

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

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

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

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

    3. 仅 ElastiCache 支持 Redis OSS 6.2 及以上版本

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

    [资源]：

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

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

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

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

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

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

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

    [资源]：

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

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

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

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

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

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

    [资源]：