本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。
# 使用 Amazon ElastiCache Well-Architected Lens
本节介绍了 Amazon ElastiCache Well-Architected Lens，这是一组用于设计架构完善的 ElastiCache 工作负载的设计原则和指南。
+ ElastiCache Lens 是对 [AWS Well-Architected Framework](https://docs.aws.amazon.com/wellarchitected/latest/framework/welcome.html) 的补充。
+ 每个支柱都有一组问题，有助于围绕 ElastiCache 架构展开讨论。
+ 每个问题都有一些领先的做法及其报告分数。
+ *必需* - 在进入生产环境之前是必需的（如果没有，会导致高风险）
+ *最佳* - 客户可能所处的最佳状态
+ *良好* - 我们建议客户具备的条件（如果没有，会导致中度风险）
+ Well-Architected 术语
+ [组件](https://docs.aws.amazon.com/wellarchitected/latest/framework/definitions.html) – 共同满足某项要求的代码、配置和 AWS 资源。组件与其他组件交互，通常等同于微服务架构中的服务。
+ [工作负载](https://docs.aws.amazon.com/wellarchitected/latest/framework/definitions.html) – 共同提供业务价值的一组组件。这样的工作负载有营销网站、电子商务网站、移动应用程序的后端、分析平台等。
**注意**
本指南尚未更新，未包含有关 ElastiCache 无服务器缓存和新 Valkey 引擎的信息。
**Topics**
+ [Amazon ElastiCache Well-Architected Lens 卓越运营支柱](OperationalExcellencePillar.md)
+ [Amazon ElastiCache Well-Architected Lens 安全支柱](SecurityPillar.md)
+ [Amazon ElastiCache Well-Architected Lens 可靠性支柱](ReliabilityPillar.md)
+ [亚马逊 Well-A ElastiCache rchitected 镜头性能效率支柱](PerformanceEfficiencyPillar.md)
+ [Amazon ElastiCache Well-Architected Lens 成本优化支柱](CostOptimizationPillar.md)
# Amazon ElastiCache Well-Architected Lens 卓越运营支柱
卓越运营支柱侧重于运行和监控系统以提供商业价值，并不断改进流程和程序。关键主题包括自动变更、响应事件和定义管理日常运营的标准。
**Topics**
+ [OE 1：您如何理解和响应 ElastiCache 集群触发的提示和事件？](#OperationalExcellencePillarOE1)
+ [OE 2：您何时以及如何扩展现有的 ElastiCache 集群？](#OperationalExcellencePillarOE2)
+ [OE 3：如何管理您的 ElastiCache 集群资源并使集群保持最新状态？](#OperationalExcellencePillarOE3)
+ [OE 4：如何管理客户端与 ElastiCache 集群的连接？](#OperationalExcellencePillarOE4)
+ [OE 5：如何为工作负载部署 ElastiCache 组件？](#OperationalExcellencePillarOE5)
+ [OE 6：如何针对故障进行规划和缓解故障？](#OperationalExcellencePillarOE6)
+ [OE 7：如何排查 Valkey 或 Redis OSS 引擎事件的问题？](#OperationalExcellencePillarOE7)
## OE 1：您如何理解和响应 ElastiCache 集群触发的提示和事件？
**问题级简介：**当您运营 ElastiCache 集群时，您可以选择在发生特定事件时接收通知和提示。原定设置情况下，ElastiCache 会记录与您的资源相关的[事件](ECEvents.md)，例如失效转移、节点更换、扩展操作、定期维护等。每个事件都包括日期和时间、来源名称和来源类型以及描述。
**问题级优势：**能够理解和管理事件（即触发由集群生成的提示）背后的根本原因，将使您能够更有效地运营并对事件做出适当的响应。
+ **[必需]** [在 ElastiCache 控制台（选择您的区域后）上或使用 [Amazon 命令行界面](https://aws.amazon.com/cli)（AWS CLI）[describe-events](https://docs.aws.amazon.com/cli/latest/reference/elasticache/describe-events.html) 命令和 ElastiCache API](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_DescribeEvents.html) 查看由 ElastiCache 生成的事件。配置 ElastiCache 以使用 Amazon Simple Notification Service（Amazon SNS）发送重要集群事件的通知。将 Amazon SNS 与集群结合使用允许您以编程方式对 ElastiCache 事件采取措施。
+ 事件分为两大类：当前事件和计划的事件。当前事件列表包括：资源创建和删除、扩展操作、失效转移、节点重启、创建的快照、集群的参数修改、CA 证书续订、故障事件（集群预调配失败 - VPC 或 ENI-、扩展失败 -ENI- 和快照故障）。计划的事件列表包括：计划在维护时段更换的节点和重新安排的节点更换。
+ 尽管您可能不需要立即对其中一些事件做出反应，但首先查看所有故障事件至关重要：
+ ElastiCache:AddCacheNodeFailed
+ ElastiCache:CacheClusterProvisioningFailed
+ ElastiCache:CacheClusterScalingFailed
+ ElastiCache:CacheNodesRebooted
+ ElastiCache:SnapshotFailed（仅限 Valkey 或 Redis OSS）
+ **[资源]：**
+ [管理 ElastiCache 亚马逊 SNS 通知](ECEvents.SNS.md)
+ [事件通知和 Amazon SNS](ElastiCacheSNS.md)
+ **[最佳]** 要自动响应事件，请利用 SNS 和 Lambda 函数等 AWS 产品和服务功能。遵循最佳实践，进行小的、频繁的、可逆的更改，作为代码来随着时间推移发展您的运营。您应该使用 Amazon CloudWatch 指标来监控您的集群。
**[资源]：**[使用 AWS Lambda、Amazon Route 53 和 Amazon SNS 监控 ElastiCache（已禁用集群模式）只读副本端点](https://aws.amazon.com/blogs/database/monitor-amazon-elasticache-for-redis-cluster-mode-disabled-read-replica-endpoints-using-aws-lambda-amazon-route-53-and-amazon-sns/)，了解使用 Lambda 和 SNS 的使用案例。
## OE 2：您何时以及如何扩展现有的 ElastiCache 集群？
**问题级简介：**合理调整您的 ElastiCache 集群规模是一种平衡行为，每次底层工作负载类型发生变化时都需要进行评估。您的目标是在适合您的工作负载的规模合适的环境中运行。
**问题级优势：**资源过度利用可能会导致延迟时间增加和整体性能下降。另一方面，利用率不足可能导致资源预调配过多，成本优化不够理想。通过适当地调整环境规模，您可以在性能效率与成本优化之间取得平衡。为了修正资源利用率过高或不足的情况，ElastiCache 可以在两个维度上进行扩展。您可以通过增加或减少节点容量来纵向扩展。您也可以通过添加和移除节点来横向扩展。
+ **[必需]** 应通过分流读取操作并将读取操作重定向到副本节点，来解决主节点上的 CPU 和网络过度利用问题。使用副本节点进行读取操作以降低主节点利用率。这可以在您的 Valkey 或 Redis OSS 客户端库中进行配置，方法是在禁用集群模式时连接到 ElastiCache 读取器端点，或者在启用集群模式时使用 READONLY 命令。
**[资源]：**
+ [查找 ElastiCache 中的缓存连接端点](Endpoints.md)
+ [合理调整集群规模](https://aws.amazon.com/blogs/database/five-workload-characteristics-to-consider-when-right-sizing-amazon-elasticache-redis-clusters/)
+ [READONLY 命令](https://valkey.io/commands/readonly)
+ **[必需]** 监控 CPU、内存和网络等关键集群资源的利用率。需要跟踪这些特定集群资源的利用率，以便为您的扩展决定和扩展操作的类型提供信息。如果禁用了 ElastiCache 集群模式，则主节点和副本节点可以垂直扩缩。副本节点也可以从 0 个节点横向扩展到 5 个节点。如果启用了集群模式，则这同样适用于集群的每个分片。此外，您可以增加或减少分片的数量。
**[资源]：**
+ [使用 Amazon CloudWatch 监控 ElastiCache 的最佳实践](https://aws.amazon.com/blogs/database/monitoring-best-practices-with-amazon-elasticache-for-redis-using-amazon-cloudwatch/)
+ [扩缩适用于 Valkey 或 Redis OSS 的 ElastiCache 集群](Scaling.md)
+ [扩缩适用于 Memcached 的 ElastiCache 集群](Scaling.md)
+ **[最佳]** 监控随时间推移的趋势可以帮助您检测工作负载变化，如果在特定时间点进行监控，这些变化将不会被注意到。要检测长期趋势，请使用 CloudWatch 指标扫描更长的时间范围。从长时间观察 CloudWatch 指标中获得的经验应为您预测集群资源利用率提供信息。CloudWatch 数据点和指标的可用时间长达 455 天。
**[资源]：**
+ [使用 CloudWatch 指标监控 ElastiCache](CacheMetrics.md)
+ [使用 CloudWatch 指标监控 Memcached](CacheMetrics.md)
+ [使用 Amazon CloudWatch 监控 ElastiCache 的最佳实践](https://aws.amazon.com/blogs/database/monitoring-best-practices-with-amazon-elasticache-for-redis-using-amazon-cloudwatch/)
+ **[最佳]** 如果您的 ElastiCache 资源是使用 CloudFormation 创建的，则最佳实践是使用 CloudFormation 模板执行更改，以保持操作一致性并避免非托管式配置更改和堆栈偏移。
**[资源]：**
+ [CloudFormation 的 ElastiCache 资源类型参考](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/AWS_ElastiCache.html)
+ **[最佳]** 使用集群运营数据自动执行扩展操作，并在 CloudWatch 中定义阈值以设置警报。使用 CloudWatch Events 和 Simple Notification Service（SNS）触发 Lambda 函数并执行 ElastiCache API 以自动扩展您的集群。例如，当 `EngineCPUUtilization` 指标在很长一段时间内达到 80% 时，向您的集群添加分片。另一种选择是使用 `DatabaseMemoryUsedPercentages` 来设置基于内存的阈值。
**[资源]：**
+ [使用 Amazon CloudWatch 警报](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)
+ [什么是 Amazon CloudWatch Events？](https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/WhatIsCloudWatchEvents.html)
+ [将 AWS Lambda 与 Amazon Simple Notification Service 结合使用](https://docs.aws.amazon.com/lambda/latest/dg/with-sns.html)
+ [ElastiCache API 参考](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/Welcome.html)
## OE 3：如何管理您的 ElastiCache 集群资源并使集群保持最新状态？
**问题级简介：**大规模运营时，必须能够查明和识别所有 ElastiCache 资源。在推出新的应用程序功能时，您需要跨所有 ElastiCache 环境类型（开发、测试和生产）创建集群版本对称性。资源属性允许您针对不同的运营目标（例如，在推出新功能和启用新的安全机制时）将环境分开。
**问题级优势：**将开发、测试和生产环境分开是最佳运营实践。以下方法也是最佳实践：跨环境的集群和节点使用众所周知和有据可查的流程应用最新的软件补丁。利用原生 ElastiCache 功能，可以让您的工程团队专注于实现业务目标，而不是 ElastiCache 的维护。
+ **[最佳]** 在可用的最新引擎版本上运行，并在自助服务更新可用时尽快应用这些更新。ElastiCache 会在您指定的集群维护时段内自动更新其底层基础设施。但是，集群中运行的节点会通过自助更新进行更新。这些更新可以分为两种类型：安全补丁或次要软件更新。确保您了解补丁类型之间的区别及其应用时间。
**[资源]：**
+ [Amazon ElastiCache 中的自助更新](Self-Service-Updates.md)
+ [Amazon ElastiCache 托管式维护和服务更新帮助页面](https://aws.amazon.com/elasticache/elasticache-maintenance/)
+ **[最佳]** 使用标签整理 ElastiCache 资源。在复制组上使用标签，而不是在单个节点上使用标签。您可以配置要在查询资源时显示的标签，也可以使用标签来执行搜索和应用筛选条件。您应该使用资源组来轻松创建和维护共享通用标签集的资源集合。
**[资源]：**
+ [标记最佳实践](https://d1.awsstatic.com/whitepapers/aws-tagging-best-practices.pdf)
+ [CloudFormation 的 ElastiCache 资源类型参考](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/AWS_ElastiCache.html)
+ [参数组](ParameterGroups.Engine.md#ParameterGroups.Redis)
## OE 4：如何管理客户端与 ElastiCache 集群的连接？
**问题级简介：**大规模运营时，您需要了解您的客户端如何与 ElastiCache 集群连接，以管理应用程序的运营环节（如响应时间）。
**问题级优势：**选择最合适的连接机制，可确保您的应用程序不会因连接错误（如超时）而断开连接。
+ **[必需]** 将读取操作与写入操作分开，并连接到副本节点以执行读取操作。但请注意，当您将写入与读取分开时，由于 Valkey 和 Redis OSS 复制的异步性质，您将失去在写入密钥后立即读取密钥的能力。可以利用 WAIT 命令来提高现实世界的数据安全性，并强制副本在响应客户端之前确认写入，但代价是总体性能降低。使用禁用集群模式的 ElastiCache 读取器端点，可以在 ElastiCache 客户端库中配置使用副本节点进行读取操作。如果启用了集群模式，请使用 READONLY 命令。对于许多 ElastiCache 客户端库，READONLY 是原定设置情况下或通过配置设置实现的。
**[资源]：**
+ [查找 ElastiCache 中的缓存连接端点](Endpoints.md)
+ [READONLY](https://valkey.io/commands/readonly)
+ **[必需] **使用连接池。建立 TCP 连接在客户端和服务器端都会消耗 CPU 时间，而池化允许您重用 TCP 连接。
为了减少连接开销，您应该使用连接池。有了连接池，您的应用程序可以“随意”重用和释放连接，而无需支付建立连接的成本。您可以通过 ElastiCache 客户端库（如果支持），使用适用于您的应用程序环境的框架实现连接池，也可以从头开始构建连接池。
+ **[最佳]** 确保将客户端的套接字超时设置为至少一秒（相比之下，多个客户端的典型原定设置值为“无”）。
+ 当服务器负载较高时，将超时值设置得过低可能会导致超时。如果将其设置得过高，则可能会导致您的应用程序花费很长时间才能检测到连接问题。
+ 通过在客户端应用程序中实现连接池来控制新连接的量。这样可以减少打开和关闭连接所需的延迟和 CPU 利用率，并且如果在集群上启用了 TLS，则执行 TLS 握手。
**[资源]：**[配置 ElastiCache 以提高可用性](https://aws.amazon.com/blogs/database/configuring-amazon-elasticache-for-redis-for-higher-availability/)
+ **[良好]** 使用管道传输（在您的使用案例允许的情况下）可以显著提高性能。
+ 通过管道传输，可以减少应用程序客户端和集群之间的往返时间（RTT），即使客户端尚未读取之前的响应，也可以处理新的请求。
+ 使用管道传输，您可以向服务器发送多个命令，而无需等待回复/确认。管道传输的缺点是，当您最终批量获取所有响应时，可能出现了一个直到最后您才会发现的错误。
+ 实现在返回遗漏错误请求的错误时重试请求的方法。
**[资源]：**[管道传输](https://valkey.io/topics/pipelining/)
## OE 5：如何为工作负载部署 ElastiCache 组件？
**问题级简介：**ElastiCache 环境可以通过 AWS 控制台手动部署，也可以通过 API、CLI、工具包等以编程方式部署。卓越运营最佳实践建议尽可能通过代码自动部署。此外，ElastiCache 集群可以按工作负载进行隔离，也可以组合起来进行成本优化。
**问题级优势：**为您的 ElastiCache 环境选择最合适的部署机制，可以随着时间的推移改善卓越运营。建议尽可能以代码形式执行操作，以最大限度地减少人为错误并改善可重复性、灵活性以及对事件的响应时间。
通过了解工作负载隔离要求，您可以选择为每个工作负载提供专用 ElastiCache 环境，或者将多个工作负载合并为单个集群，或者将它们组合在一起。了解权衡利弊有助于在卓越运营和成本优化之间取得平衡
+ **[必需]** 了解 ElastiCache 可用的部署选项，并尽可能自动执行这些过程。可能的自动化途径包括 CloudFormation、AWS CLI/SDK 和 API。
**[资源]：**
+ [Amazon ElastiCache 资源类型参考](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/AWS_ElastiCache.html)
+ [elasticache](https://docs.aws.amazon.com/cli/latest/reference/elasticache/index.html)
+ [Amazon ElastiCache API 参考](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/Welcome.html)
+ **[必需]** 对于所有工作负载，确定所需的集群隔离级别。
+ **[最佳]：**高度隔离 – 工作负载与集群的映射为 1:1。允许在每个工作负载的基础上对 ElastiCache 资源的访问、大小、扩展和管理进行最精细的控制。
+ **[更佳]：**中等隔离 – M:1 按目的隔离，但可能在多个工作负载之间共享（例如，一个集群专门用于缓存工作负载，另一个集群专门用于消息传递）。
+ **[良好]：**低度隔离 – M:1 全用途，完全共享。建议用于可接受共享访问的工作负载。
## OE 6：如何针对故障进行规划和缓解故障？
**问题级简介：**卓越运营包括通过定期进行“崩溃前”练习来预测故障，以确定潜在的故障来源，从而消除或缓解故障。ElastiCache 提供失效转移 API，允许模拟节点故障事件，用于测试目的。
**问题级优势：**通过提前测试故障情景，您可以了解它们如何影响您的工作负载。这样可以安全地测试响应过程及其有效性，并让您的团队熟悉其执行情况。
**[必需]** 定期在开发/测试账户中执行失效转移测试。[TestFailover](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_TestFailover.html)
## OE 7：如何排查 Valkey 或 Redis OSS 引擎事件的问题？
**问题级简介：**卓越运营要求能够调查服务级和引擎级信息，以分析集群的运行状况和状态。ElastiCache 可以向 Amazon CloudWatch 和 Amazon Kinesis Data Firehose 发送 Valkey 或 Redis OSS 引擎日志。
**问题级优势：**在 ElastiCache 集群上启用 Valkey 或 Redis OSS 引擎日志后，可以深入了解影响集群运行状况和性能的事件。Valkey 或 Redis OSS 引擎日志直接提供来自引擎的数据，而这些数据无法通过 ElastiCache 事件机制获得。通过仔细观察 ElastiCache 事件（请参阅前面的 OE-1）和引擎日志，可以从 ElastiCache 服务的角度和引擎的角度确定排查问题时的事件顺序。
+ **[必需]** 确保已启用 Redis OSS 引擎日志记录功能，该功能在 ElastiCache for Redis OSS 版本 6.2 及更高版本中可用。这可以在集群创建期间执行，也可以在创建后通过修改集群来执行。
+ 确定是 Amazon CloudWatch Logs 还是 Amazon Kinesis Data Firehose 是 Redis OSS 引擎日志的合适目标。
+ 在 CloudWatch 或 Kinesis Data Firehose 中选择相应的目标日志来保存日志。如果您有多个集群，请考虑为每个集群使用不同的目标日志，因为这将有助于在进行故障排除时隔离数据。
**[资源]：**
+ 日志传输：[日志传输](Log_Delivery.md)
+ 日志记录目标：[Amazon CloudWatch Logs](Logging-destinations.md#Destination_Specs_CloudWatch_Logs)
+ Amazon CloudWatch Logs 简介：[什么是 Amazon CloudWatch Logs？](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html)
+ Amazon Kinesis Data Firehose 简介：[什么是 Amazon Kinesis Data Firehose？](https://docs.aws.amazon.com/firehose/latest/dev/what-is-this-service.html)
+ **[最佳]** 如果使用 Amazon CloudWatch Logs，可以考虑利用 Amazon CloudWatch Logs Insights 查询 Valkey 或 Redis OSS 引擎日志以获取重要信息。
例如，针对包含 Valkey 或 Redis OSS 引擎日志的 CloudWatch 日志组创建查询，这将返回日志级别为“警告”的事件，例如：
```
fields @timestamp, LogLevel, Message
| sort @timestamp desc
| filter LogLevel = "WARNING"
```
**[资源]：**[使用 CloudWatch Logs Insights 分析日志数据](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AnalyzingLogData.html)
# Amazon ElastiCache Well-Architected Lens 安全支柱
安全支柱侧重于保护信息和系统。关键主题包括数据的机密性和完整性、识别和管理谁能通过基于权限的管理做什么、保护系统以及建立用以检测安全事件的控制措施。
**Topics**
+ [SEC 1：您在控制对 ElastiCache 数据的授权访问方面采取了哪些举措？](#SecurityPillarSEC1)
+ [SEC 2：除了基于网络的控制之外，您的应用程序是否需要对于 ElastiCache 的额外授权？](#SecurityPillarSEC2)
+ [SEC 3：是否存在无意中执行命令从而导致数据丢失或故障的风险？](#SecurityPillarSEC3)
+ [SEC 4：如何使用 ElastiCache 确保静态数据加密](#SecurityPillarSEC4)
+ [SEC 5：如何使用 ElastiCache 加密传输中的数据？](#SecurityPillarSEC5)
+ [SEC 6：如何限制对控制面板资源的访问？](#SecurityPillarSEC6)
+ [SEC 7：如何检测和响应安全事件？](#SecurityPillarSEC7)
## SEC 1：您在控制对 ElastiCache 数据的授权访问方面采取了哪些举措？
**问题级简介：**所有 ElastiCache 集群均设计为从 VPC 中的 Amazon Elastic Compute Cloud 实例、无服务器函数（AWS Lambda）或容器（Amazon Elastic Container Service）进行访问。最常遇到的情况是从同一个 Amazon Virtual Private Cloud（Amazon VPC）内的 Amazon Elastic Compute Cloud 实例访问 ElastiCache 集群。必须先授权 Amazon EC2 实例对集群的访问权限，然后您才能从 Amazon EC2 实例连接到集群。要访问在 VPC 中运行的 ElastiCache 集群，需要授予进入该集群的网络入口。
**问题级优势：**通过 VPC 安全组控制进入集群的网络入口。安全组充当 Amazon EC2 实例的虚拟防火墙，用于控制传入和传出流量。入站规则控制传入到实例的流量，出站规则控制从实例传出的流量。就 ElastiCache 而言，启动集群时，需要关联安全组。这样可以确保组成集群的所有节点都有入站和出站流量规则。此外，ElastiCache 配置为仅在私有子网上部署，因此只能通过 VPC 的私有网络进行访问。
+ **[必需] **与您的集群关联的安全组控制进入集群的网络入口以及对集群的访问权限。原定设置情况下，安全组将不会定义任何入站规则，因此不会有指向 ElastiCache 的入口路径。要启用此功能，请在安全组上配置入站规则，指定源 IP 地址/范围、TCP 类型流量和 ElastiCache 集群的端口（例如 ElastiCache for Valkey 和 ElastiCache for Redis OSS 的原定设置端口 6379）。尽管允许非常广泛的入口来源，例如 VPC 中的所有资源（0.0.0.0/0），但建议尽可能详细地定义入站规则，例如，仅授权入站访问在与特定安全组关联的 Amazon EC2 实例上运行的 Valkey 或 Redis OSS 客户端。
**[资源]：**
+ [子网和子网组](SubnetGroups.md)
+ [访问您的集群或复制组](accessing-elasticache.md)
+ [使用安全组控制到资源的流量](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-security-groups.html#DefaultSecurityGroupdefault%20security%20group)
+ [适用于 Linux 实例的 Amazon Elastic Compute Cloud 安全组](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-security-groups.html#creating-your-own-security-groups)
+ **[必需] **可以为 AWS Lambda 函数分配 AWS Identity and Access Management 策略，允许其访问 ElastiCache 数据。要启用此功能，请创建具有 `AWSLambdaVPCAccessExecutionRole` 权限的 IAM 执行角色，然后将该角色分配给 AWS Lambda 函数。
**[资源]：**配置 Lambda 函数以访问 Amazon VPC 中的 Amazon ElastiCache：[教程：配置 Lambda 函数以访问 Amazon VPC 中的 Amazon ElastiCache](https://docs.aws.amazon.com/lambda/latest/dg/services-elasticache-tutorial.html)
## SEC 2：除了基于网络的控制之外，您的应用程序是否需要对于 ElastiCache 的额外授权？
**问题级简介：**对于需要在单个客户端级别限制或控制对集群的访问权限的场景中，建议通过 AUTH 命令进行身份验证。ElastiCache 身份验证令牌以及可选的用户和用户组管理，让 ElastiCache 在允许客户端运行命令和访问密钥之前需要密码，进而提高数据面板的安全性。
**问题级优势：**为了保护您的数据安全，ElastiCache 提供了旨在防止未经授权访问您数据的机制。这些机制包括强制实施基于角色的访问控制（RBAC）AUTH 或 AUTH 令牌（密码），供客户端在执行授权命令之前连接到 ElastiCache。
+ **[最佳] **对于 ElastiCache for Redis OSS 版本 6.x 及更高版本，以及 ElastiCache for Valkey 版本 7.2 及更高版本，通过定义用户组、用户和访问字符串来定义身份验证和授权控制。将用户分配给用户组，然后将用户组分配给集群。要使用 RBAC，必须在创建集群时将其选中，并且必须启用传输中加密。确保您使用的是支持 TLS 的 Valkey 或 Redis OSS 客户端，以便能够利用 RBAC。
**[资源]：**
+ [将 RBAC 应用于 ElastiCache 的复制组](Clusters.RBAC.md#rbac-using)
+ [使用访问字符串指定权限](Clusters.RBAC.md#Access-string)
+ [ ACL](https://valkey.io/topics/acl/)
+ [支持的 ElastiCache 版本](VersionManagement.md#supported-engine-versions)
+ **[最佳]** 对于 ElastiCache for Redis OSS 6.x 之前的版本，除了为 AUTH 设置强令牌/密码和维持严格的密码策略外，最佳实践是轮换密码/令牌。在任何给定时间，ElastiCache 最多可管理两（2）个身份验证令牌。您也可以修改集群以明确要求使用身份验证令牌。
**[资源]：**[修改现有 ElastiCache 集群上的 AUTH 令牌](auth.md#auth-modifyng-token)
## SEC 3：是否存在无意中执行命令从而导致数据丢失或故障的风险？
**问题级简介：**许多 Valkey 或 Redis OSS 命令一旦错误执行或由恶意行为者执行，就可能会对运营产生不利影响。从性能和数据安全的角度来看，这些命令可能会产生意想不到的后果。例如，开发人员可能会在开发环境中定期调用 FLUSHALL 命令，并且由于错误，可能会无意中尝试在生产系统上调用此命令，从而导致数据意外丢失。
**问题级优势：**从 ElastiCache for Redis OSS 5.0.3 版本开始，您可以重命名某些可能会中断工作负载的命令。重命名命令有助于防止无意中在集群上执行这些命令。
+ **[必需]**
**[资源]：**
+ [ElastiCache for Redis OSS 5.0.3 版本（已弃用，使用 5.0.6 版本）](engine-versions.md#redis-version-5-0.3)
+ [ElastiCache for Redis OSS 版本 5.0.3 参数更改](ParameterGroups.Engine.md#ParameterGroups.Redis.5-0-3)
+ [Redis OSS 安全](https://redis.io/docs/management/security/)
## SEC 4：如何使用 ElastiCache 确保静态数据加密
**问题级简介：**虽然 ElastiCache 是一种内存数据存储，但可以加密任何在集群标准操作中保留（在存储上）的数据。这包括写入 Amazon S3 的计划备份和手动备份，以及在执行同步和交换操作后保存到磁盘存储中的数据。m6g 和 R6g 系列中的实例类型还会始终开启内存加密。
**问题级优势：**ElastiCache 提供可选的静态加密，以提高数据安全性。
+ **[必需] **只有在创建 ElastiCache 集群（复制组）时，才能在该集群上启用静态加密。无法修改现有集群以开始加密静态数据。原定设置情况下，ElastiCache 将提供和管理静态加密中使用的密钥。
**[资源]：**
+ [静态加密限制](at-rest-encryption.md#at-rest-encryption-constraints)
+ [启用静态加密](at-rest-encryption.md#at-rest-encryption-enable)
+ **[最佳]** 利用当数据在内存中时对数据进行加密的 Amazon EC2 实例类型（例如 m6g 或 R6g）。如果可能，请考虑管理自己的静态加密密钥。对于更严格的数据安全环境，可以使用 AWS Key Management Service（KMS）来自行管理客户主密钥（CMK）。通过 ElastiCache 与 AWS Key Management Service 集成，您可以创建、拥有和管理用于为 ElastiCache 集群加密静态数据的密钥。
**[资源]：**
+ [使用 AWS Key Management Service 中的客户托管密钥](at-rest-encryption.md#using-customer-managed-keys-for-elasticache-security)
+ [AWS Key Management Service](https://docs.aws.amazon.com/kms/latest/developerguide/overview.html)
+ [AWS KMS 概念](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#master_keys)
## SEC 5：如何使用 ElastiCache 加密传输中的数据？
**问题级简介：**防止数据在传输过程中被泄露是常见的要求。这些数据指分布式系统的组件内以及应用程序客户端和集群节点之间的数据。ElastiCache 通过允许对客户端和集群之间以及集群节点自身之间的传输中数据进行加密，从而支持这一要求。m6g 和 R6g 系列中的实例类型还会始终开启内存加密。
**问题级简介：**Amazon ElastiCache 传输中加密是一项可选功能，您可以通过该功能在数据最脆弱的时候（从一个位置传输到另一个位置时）提高数据的安全性。
+ **[必需] **只有在创建集群（复制组）时才能在该集群上启用传输中加密。请注意，由于加密/解密数据需要额外的处理，因此，实施传输中加密将会对性能有一些影响。要了解具体会有什么影响，建议在启用传输中加密之前和之后分别对您的工作负载进行基准测试。
**[资源]：**
+ [传输中加密概览](in-transit-encryption.md#in-transit-encryption-overview)
## SEC 6：如何限制对控制面板资源的访问？
**问题级简介：**IAM 策略和 ARN 为 ElastiCache for Valkey 和 ElastiCache for Redis OSS 提供了精细的访问控制，允许通过更严格的控制来管理群的创建、修改和删除。
**问题级优势：**可以将 Amazon ElastiCache 资源（例如复制组、节点等）的管理限制为根据 IAM policy 拥有特定权限的 AWS 账户，从而提高资源的安全性和可靠性。
+ **[必需] **通过为 AWS 用户分配特定 AWS Identity and Access Management 策略来管理对 Amazon ElastiCache 资源的访问权限，从而可以更精细地控制哪些账户可以对集群执行哪些操作。
**[资源]：**
+ [管理对 ElastiCache 资源的访问权限的概览](IAM.Overview.md)
+ [将基于身份的策略（IAM policy）用于 Amazon ElastiCache](IAM.IdentityBasedPolicies.md)
## SEC 7：如何检测和响应安全事件？
**问题级简介：**ElastiCache 在启用 RBAC 的情况下部署时，会导出 CloudWatch 指标以向用户通知安全事件。这些指标有助于识别连接的 RBAC 用户未获授权进行身份验证、访问密钥或运行命令的失败尝试。
此外，AWS 产品和服务资源通过自动执行部署和记录所有操作及修改以供日后审查/审计，帮助保护您的整体工作负载。
**问题级优势：**通过监控事件，可以让您的组织能够根据您的要求、策略和过程做出响应。自动监控和响应这些安全事件可增强您的整体安全态势。
+ **[必需] **自行熟悉已发布的与 RBAC 身份验证和授权失败有关的 CloudWatch 指标。
+ AuthenticationFailures = 尝试向 Valkey 或 Redis OSS 进行身份验证失败
+ KeyAuthorizationFailures = 用户未经许可尝试访问密钥失败
+ CommandAuthorizationFailures = 用户未经许可尝试运行命令失败
**[资源]：**
+ [Valkey 或 Redis OSS 的指标](CacheMetrics.Redis.md)
+ **[最佳] **建议针对这些指标设置提示和通知，并在必要时做出响应。
**[资源]：**
+ [使用 Amazon CloudWatch 警报](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)
+ **[最佳] **使用 Valkey 或 Redis OSS ACL LOG 命令收集进一步的详细信息
**[资源]：**
+ [ACL LOG](https://valkey.io/commands/acl-log/)
+ **[最佳] **自行熟悉与监控、记录和分析 ElastiCache 部署和事件相关的 AWS 产品和服务功能
**[资源]：**
+ [使用 AWS CloudTrail 记录 Amazon ElastiCache API 调用](logging-using-cloudtrail.md)
+ [elasticache-redis-cluster-automatic-backup-check](https://docs.aws.amazon.com/config/latest/developerguide/elasticache-redis-cluster-automatic-backup-check.html)
+ [使用 CloudWatch 指标监控使用情况](CacheMetrics.md)
# Amazon ElastiCache Well-Architected Lens 可靠性支柱
可靠性支柱的侧重点是执行预期功能的工作负载以及如何从故障中快速恢复以满足需求。关键主题包括分布式系统设计、恢复规划和适应不断变化的需求。
**Topics**
+ [REL 1：您如何支持高可用性（HA）架构部署？](#ReliabilityPillarREL1)
+ [REL 2：您如何使用 ElastiCache 实现恢复点目标（RPO）？](#ReliabilityPillarREL2)
+ [REL 3：您如何支持灾难恢复（DR）要求？](#ReliabilityPillarREL3)
+ [REL 4：如何有效地规划失效转移？](#ReliabilityPillarREL4)
+ [REL 5：您的 ElastiCache 组件是否设计为可扩展？](#ReliabilityPillarREL5)
## REL 1：您如何支持高可用性（HA）架构部署？
**问题级简介：**了解 Amazon ElastiCache 的高可用性架构，将使您能够在可用性事件期间以弹性状态运行。
**问题级优势：**设计您的 ElastiCache 集群的架构，使之具有故障恢复能力，可确保您的 ElastiCache 部署具有更高的可用性。
+ **[必需] **确定您的 ElastiCache 集群所需的可靠性级别。不同的工作负载具有不同的弹性标准，从完全的临时工作负载到任务关键型工作负载。定义您运行的每种环境类型（例如开发、测试和生产）的需求。
缓存引擎：ElastiCache for Memcached 与 ElastiCache for Valkey 和 ElastiCache for Redis OSS
1. ElastiCache for Memcached 不提供任何复制机制，主要用于临时工作负载。
1. ElastiCache for Valkey 和 ElastiCache for Redis OSS 提供了下面所讨论的 HA 功能
+ **[最佳] **对于需要 HA 的工作负载，请在集群模式下使用 ElastiCache，每个分片至少有两个副本，即使对于吞吐量要求较小且只需要一个分片的工作负载也是如此。
1. 如果启用了集群模式，将自动启用多可用区。
在发生任何计划内或计划外维护以及缓解可用区故障时，多可用区通过执行从主节点到副本的自动失效转移来最大限度地减少停机时间。
1. 对于分片工作负载，由于 Valkey 或 Redis OSS 集群协议要求大多数主节点可用才能实现仲裁，因此至少有三个分片可以在失效转移事件期间提供更快的恢复。
1. 跨可用性设置两个或更多副本。
拥有两个副本可以提高读取可扩展性，也可以在一个副本处于维护状态的场景中提供读取可用性。
1. 使用基于 Graviton2 的节点类型（大多数区域中的原定设置节点）。
ElastiCache 在这些节点上添加了优化的性能。因此，您可以获得更佳的复制和同步性能，从而提高整体可用性。
1. 监控并适当调整规模以应对预期的流量高峰：在高负载下，引擎可能会变得无响应，从而影响可用性。`BytesUsedForCache` 和 `DatabaseMemoryUsagePercentage` 是衡量内存使用情况的良好指标，而 `ReplicationLag` 是基于写入速率衡量复制运行状况的指标。您可以使用这些指标来触发集群扩展。
1. 通过[在生产失效转移事件之前使用失效转移 API](https://docs.amazonaws.cn/en_us/AmazonElastiCache/latest/APIReference/API_TestFailover.html) 进行测试，确保客户端恢复能力。
**[资源]：**
+ [配置 ElastiCache for Redis OSS 以提高可用性](https://aws.amazon.com/blogs/database/configuring-amazon-elasticache-for-redis-for-higher-availability/)
+ [使用复制组时的高可用性](Replication.md)
## REL 2：您如何使用 ElastiCache 实现恢复点目标（RPO）？
**问题级简介：**了解工作负载 RPO，为有关 ElastiCache 备份和恢复策略的决策提供依据。
**问题级优势：**制定适当的 RPO 策略，可以提高灾难恢复情景下的业务连续性。设计备份和还原策略有助于您实现 ElastiCache 数据的恢复点目标（RPO）。ElastiCache 提供存储在 Amazon S3 中的快照功能以及可配置的保留策略。这些快照是在定义的备份时段内拍摄的，并由服务自动处理。如果您的工作负载需要额外的备份粒度，则可以选择每天创建多达 20 个手动备份。手动创建的备份没有服务保留策略，可以无限期保留。
+ **[必需] **了解并记录您的 ElastiCache 部署的 RPO。
+ 请注意，Memcached 不提供任何备份流程。
+ 查看 ElastiCache 备份和还原特性的功能。
+ **[最佳] **制定一个沟通良好的集群备份流程。
+ 根据需要启动手动备份。
+ 查看自动备份的保留策略。
+ 请注意，手动备份将会无限期保留。
+ 将自动备份安排在使用率比较低的时段内进行。
+ 对只读副本执行备份操作，以确保将对集群性能的影响降至最低。
+ **[良好]** 利用 ElastiCache 的计划备份功能，在规定的时段内定期备份数据。
+ 定期测试从备份中执行的还原。
+ **[资源]：**
+ [Redis OSS](https://aws.amazon.com/elasticache/faqs/#Redis)
+ [ElastiCache 的备份与恢复](backups.md)
+ [进行手动备份](backups-manual.md)
+ [计划自动备份](backups-automatic.md)
+ [备份和还原 ElastiCache 集群](https://aws.amazon.com/blogs/aws/backup-and-restore-elasticache-redis-nodes/)
## REL 3：您如何支持灾难恢复（DR）要求？
**问题级简介：**灾难恢复对于任何工作负载规划都是一个重要的方面。ElastiCache 提供了多种选择，可根据工作负载弹性要求实施相应的灾难恢复。使用 Amazon ElastiCache 全局数据存储，您可以在一个区域中写入您的集群，并让数据可供从另外两个跨区域副本集群读取，从而实现跨区域的低延迟读取和灾难恢复。
**问题级优势：**了解各种灾难情景并相应进行规划可以确保业务连续性。灾难恢复策略必须在成本、性能影响和数据丢失可能性之间达到平衡。
+ **[必需] **根据工作负载要求，为所有 ElastiCache 组件制定和记录灾难恢复策略。ElastiCache 的独特之处在于，有些使用案例是完全是临时的，不需要任何灾难恢复策略；而另一些使用案例则截然相反，需要极其稳健的灾难恢复策略。所有选项都必须针对成本优化进行权衡 – 恢复能力越高，则需要的基础设施就越多。
了解区域级别和多区域级别上可用的灾难恢复选项。
+ 建议进行多可用区部署以防出现可用区故障。确保在多可用区架构中启用集群模式进行部署，且至少提供 3 个可用区。
+ 建议使用全局数据存储以防出现区域故障。
+ **[最佳] **为需要区域级恢复能力的工作负载启用全局数据存储。
+ 制定计划，以便在主区域出现性能下降时失效转移到辅助区域。
+ 在生产环境中进行失效转移之前，测试多区域失效转移过程。
+ 监控 `ReplicationLag` 指标，以了解失效转移事件期间数据丢失带来的潜在影响。
+ **[资源]：**
+ [缓解故障](disaster-recovery-resiliency.md#FaultTolerance)
+ [使用全局数据存储跨 AWS 区域进行复制](Redis-Global-Datastore.md)
+ [从备份还原（可选择调整集群大小](backups-restoring.md)
+ [利用多可用区最大限度减少 ElastiCache for Valkey 和 ElastiCache for Redis OSS 中的停机时间](AutoFailover.md)
## REL 4：如何有效地规划失效转移？
**问题级简介：**启用具有自动失效转移功能的多可用区是 ElastiCache 最佳实践。某些情况下，在服务操作过程中，ElastiCache for Valkey 和 ElastiCache for Redis OSS 会取代主节点。这些情况包括计划维护事件，以及节点故障或可用区出现问题等此类不太可能发生的情况。失效转移的成功与否依赖于 ElastiCache 和您的客户端库配置。
**问题级优势：**将 ElastiCache 失效转移的最佳实践与特定的 ElastiCache 客户端库相结合，有助于您最大限度地减少失效转移事件期间的潜在停机时间。
+ **[必需] **如果禁用集群模式，请使用超时，以便客户端检测是否需要断开与旧的主节点的连接，然后使用更新后的主端点 IP 地址重新连接到新的主节点。如果启用了集群模式，则客户端库负责检测底层集群拓扑的变化。此操作通常是通过 ElastiCache 客户端库中的配置设置来实现的，该操作还允许您配置刷新的频率和方法。每个客户端库都提供自己的设置，更多详细信息可在相应的文档中找到。
**[资源]：**
+ [利用多可用区最大限度减少 ElastiCache for Valkey 和 ElastiCache for Redis OSS 中的停机时间](AutoFailover.md)
+ 查看 ElastiCache 客户端库的最佳实践。
+ **[必需] **失效转移的成功取决于主节点和副本节点之间运行状况正常的复制环境。查看并了解 Valkey 和 Redis OSS 复制的异步性质，以及可用的 CloudWatch 指标，以便报告主节点和副本节点之间的复制延迟。对于需要更高数据安全性的使用案例，请利用 WAIT 命令强制副本在响应连接的客户端之前确认写入。
**[资源]：**
+ [Valkey 或 Redis OSS 的指标](CacheMetrics.Redis.md)
+ [使用 Amazon CloudWatch 监控 ElastiCache 的最佳实践](https://aws.amazon.com/blogs/database/monitoring-best-practices-with-amazon-elasticache-for-redis-using-amazon-cloudwatch/)
+ **[最佳] **在失效转移期间，使用 ElastiCache 测试失效转移 API 定期验证应用程序的响应能力。
**[资源]：**
+ [在 ElastiCache 上测试到只读副本的自动失效转移](https://aws.amazon.com/blogs/database/testing-automatic-failover-to-a-read-replica-on-amazon-elasticache-for-redis/)
+ [测试自动失效转移](AutoFailover.md#auto-failover-test)
## REL 5：您的 ElastiCache 组件是否设计为可扩展？
**问题级简介：**通过了解扩展能力和可用的部署拓扑，您的 ElastiCache 组件可以不断进行调整，以满足不断变化的工作负载要求。ElastiCache 提供 4 种扩展方式：横向缩减/横向扩展（横向）和纵向扩展/缩减（纵向）。
**问题级优势：**遵循 ElastiCache 部署的最佳实践可提供最大的扩展灵活性，同时还符合 Well Architected 原则，即横向扩展以最大限度地减少故障的影响。
+ **[必需] **了解启用集群模式的拓扑与禁用集群模式的拓扑之间的区别。在几乎所有情况下，均建议在启用集群模式的情况下进行部署，因为这可以不断提高可扩展性。禁用集群模式的组件通过添加只读副本进行水平扩展的能力受到限制。
+ **[必需] **了解何时以及如何扩展。
+ 要获得更多 READIOPS：添加副本
+ 要获得更多 WRITEOPS：添加分片（横向扩展）
+ 要获得更多网络 IO：使用网络优化型实例，纵向扩展
+ **[最佳] **在启用集群模式的情况下部署 ElastiCache 组件，偏向于更多、更小的节点，而不是更少、更大的节点。这可有效地限制节点故障的影响范围。
+ **[最佳] **在集群中加入副本，以增强扩展事件期间的响应能力
+ **[良好] **如果禁用了集群模式，请利用只读副本增加总体读取容量。ElastiCache 在禁用集群模式的情况下最多支持 5 个只读副本，还支持纵向扩展。
+ **[资源]：**
+ [扩缩 ElastiCache 集群](Scaling.md)
+ [在线纵向扩展](redis-cluster-vertical-scaling.md#redis-cluster-vertical-scaling-scaling-up)
# 亚马逊 Well-A ElastiCache rchitected 镜头性能效率支柱
性能效率支柱侧重于高效率地使用 IT 和计算资源。关键主题包括：根据工作负载要求选择合适的资源类型和大小、监控性能以及做出明智的决策以跟随业务需求的变化保持效率。
**Topics**
+ [PE 1：如何监控您的亚马逊 ElastiCache 集群的性能？](#PerformanceEfficiencyPillarPE1)
+ [PE 2：您如何在 ElastiCache 群集节点之间分配工作？](#PerformanceEfficiencyPillarPE2)
+ [PE 3：对于缓存工作负载，如何跟踪和报告缓存的有效性和性能？](#PerformanceEfficiencyPillarPE3)
+ [PE 4：您的工作负载如何优化网络资源和连接的使用？](#PerformanceEfficiencyPillarPE4)
+ [PE 5：如何管理密钥删除 and/or 驱逐？](#PerformanceEfficiencyPillarPE5)
+ [PE 6：你如何对中的数据进行建模和交互 ElastiCache？](#PerformanceEfficiencyPillarPE6)
+ [PE 7：如何在您的 Amazon ElastiCache 集群中记录运行缓慢的命令？](#PerformanceEfficiencyPillarPE7)
+ [PE8: Auto Scaling 如何帮助提高ElastiCache 集群的性能？](#PerformanceEfficiencyPillarPE8)
## PE 1：如何监控您的亚马逊 ElastiCache 集群的性能？
**问题级简介：**通过了解现有的监控指标，您可以确定当前的利用率。适当的监控有助于识别影响集群性能的潜在瓶颈。
**问题级优势：**了解与您的集群关联的指标有助于指导优化技术，从而减少延迟和增加吞吐量。
+ **[必需] **使用一部分工作负载进行基准性能测试。
+ 您应该使用负载测试等机制监控实际工作负载的性能。
+ 在运行这些测试时监控 CloudWatch 指标，以了解可用指标并建立性能基准。
+ **[最佳]** 对 ElastiCache 于 Valkey 和 Redis OSS 工作负载，请重命名计算成本高昂的命令，例如`KEYS`，以限制用户在生产集群上运行阻塞命令的能力。
+ ElastiCache 运行适用于 Redis OSS 的引擎 6.x 的工作负载可以利用基于角色的访问控制来限制某些命令。可以通过使用控制AWS台或 CLI 创建用户和用户组，并将用户组与集群关联来控制对命令的访问。在 Redis OSS 6 中，启用 RBAC 后，我们可以使用“-@dangerous”，它将禁止该用户使用诸如 KEYS、MONITOR、SORT 等昂贵的命令。
+ 对于引擎版本 5.x，使用集群参数组上的 `rename-commands` 参数重命名命令。
+ **[更佳]** 分析慢速查询并寻找优化技巧。
+ 对 ElastiCache 于 Valkey 和 Redis OSS 工作负载，请通过分析慢日志来详细了解您的查询。例如，您可以使用以下命令 `valkey-cli slowlog get 10` 来显示最近 10 条超过延迟阈值（原定设置为 10 毫秒）的命令。
+ 使用复杂ElastiCache 的 Valkey 和 Redis OSS 数据结构可以更有效地执行某些查询。例如，对于数字样式范围查找，应用程序可以使用排序集来实现简单的数字索引。管理这些索引可以减少对数据集执行的扫描，并以更高的性能效率返回数据。
+ 对 ElastiCache 于 Valkey 和 Redis OSS 工作负载，`redis-benchmark`提供了一个简单的接口，用于使用用户定义的输入（例如客户端数量和数据大小）来测试不同命令的性能。
+ 由于 Memcached 仅支持简单的键级命令，因此可以考虑构建其他键作为索引，以避免遍历键空间来服务于客户端查询。
+ **[资源]：**
+ [使用 CloudWatch 指标监控使用情况](CacheMetrics.md)
+ [使用亚马逊 CloudWatch 警报](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)
+ [Valkey 和 Redis OSS 特定参数](ParameterGroups.Engine.md#ParameterGroups.Redis)
+ [SLOWLOG](https://valkey.io/commands/slowlog/)
+ [基准](https://valkey.io/topics/benchmark/)
## PE 2：您如何在 ElastiCache 群集节点之间分配工作？
**问题级简介：**您的应用程序连接到 Amazon ElastiCache 节点的方式可能会影响集群的性能和可扩展性。
**问题级优势：**正确使用集群中的可用节点将确保在可用的资源中分配工作。以下技巧也有助于避免闲置资源。
+ **[必需]** 让客户端连接到正确的 ElastiCache 端点。
+ ElastiCache 对于 Valkey 和 Redis，OSS 会根据所使用的集群模式实现不同的终端节点。对于已启用集群模式， ElastiCache 将提供配置终端节点。如果禁用了集群模式，则ElastiCache 提供一个主终端节点（通常用于写入）和一个用于平衡副本间读取的读取器终端节点。正确实现这些端点将会提高性能并让扩展操作更轻松。除非有特定要求，否则请避免连接到各个节点端点。
+ 对于多节点 Memcached 集群， ElastiCache 提供启用自动发现的配置终端节点。建议使用哈希算法在缓存节点之间均匀分配工作。许多 Memcached 客户端库可实现一致性哈希。请参阅您要使用的库的文档，了解其是否支持一致性哈希以及如何实现一致性哈希。您可以[在此处](BestPractices.LoadBalancing.md)找到有关实现这些功能的更多信息。
+ **[更好]** 利用支持 Valkey 和 Redis 的 OSS 集群模式的集群来提高可扩展性。 ElastiCache
+ ElastiCache 对于 Valkey 和 Redis OSS（已启用集群模式），集群支持[在线扩展操作](scaling-redis-cluster-mode-enabled.md#redis-cluster-resharding-online)（out/in and up/down），以帮助在分片之间动态分配数据。使用配置端点将确保您的集群感知客户端能够适应集群拓扑的变化。
+ 您也可以通过在 for Valkey 和 Redis OSS（已启用集群模式）集群中的 ElastiCache 可用分片之间移动哈希槽来重新平衡集群。此举有助于在可用分片之间更高效地分配工作。
+ **[更佳]** 实施用于识别和修复工作负载中热键的策略。
+ 考虑多维 Valkey 或 Redis OSS 数据结构（例如列表、流、集合等）的影响。这些数据结构存储在单个键中，而这些键位于单个节点上。与其他数据类型相比，非常大的多维键有可能占用更多的网络容量和内存，因此可能导致过度使用该节点。如果可能，请将您的工作负载设计为将数据访问分散到许多离散的键上。
+ 工作负载中的热键可能会影响正在使用的节点的性能。对 ElastiCache 于 Valkey 和 Redis OSS 工作负载，你可以使用 LFU 最大内存策略`valkey-cli --hotkeys`是否到位来检测热键。
+ 考虑在多个节点上复制热键，以便更均匀地分配对它们的访问。这种方法要求客户端写入多个主节点（Valkey 或 Redis OSS 节点本身不提供此功能），除原始键名称外，还需要维护一个可供读取的键名称列表。
+ ElastiCache [适用于 Valkey 及更高 ElastiCache 版本的引擎 7.2 和 Redis OSS 及更高版本的版本 6 都支持服务器辅助的客户端缓存。](https://valkey.io/topics/client-side-caching/)这样，应用程序就可以等待密钥的更改，然后再进行网络呼叫ElastiCache。
+ **[资源]：**
+ [为 Valkey 和 Redis OSS 进行配置 ElastiCache 以获得更高的可用性](https://aws.amazon.com/blogs/database/configuring-amazon-elasticache-for-redis-for-higher-availability/)
+ [查找 ElastiCache 中的缓存连接端点](Endpoints.md)
+ [负载均衡最佳实践](https://docs.aws.amazon.com/AmazonElastiCache/latest/dg/BestPractices.LoadBalancing.html)
+ [Valkey 或 Redis OSS（已启用集群模式）的离线重新分片](scaling-redis-cluster-mode-enabled.md#redis-cluster-resharding-online)
+ [Valkey 和 Redis OSS 中的客户端缓存](https://valkey.io/topics/client-side-caching/)
## PE 3：对于缓存工作负载，如何跟踪和报告缓存的有效性和性能？
**问题级简介：**缓存是经常遇到的工作负载，了解如何管理缓存的有效性和性能非常重要。 ElastiCache
**问题级优势：**您的应用程序可能显示出性能不佳的迹象。您能够使用特定于缓存的指标来决定如何提高应用程序性能，这对您的缓存工作负载至关重要。
+ **[必需] **测量并跟踪一段时间内的缓存命中率。缓存的效率由其“缓存命中率”决定。缓存命中率由键命中总数除以命中和未命中总数来定义。比率越接近 1，您的缓存就越有效。缓存命中率低是由缓存未命中数量造成的。当在缓存中找不到请求的键时，就会出现缓存未命中。键不在缓存中，因为它要么已被驱逐或删除，要么已过期，要么从未存在。了解为什么键不在缓存中，并制定适当的策略将其放入缓存。
**[资源]：**
+ [Valkey 和 Redis OSS 的指标](CacheMetrics.Redis.md)
+ **[必需]** 测量和收集应用程序缓存性能以及延迟和 CPU 利用率值，以了解是否需要调整应用程序组件 time-to-live或其他应用程序组件。 ElastiCache 为每种数据结构的聚合延迟提供了一组 CloudWatch 指标。这些延迟指标是使用 INFO 命令中的命令统计数据计算得出的，不包括网络和 I/O 时间。这只是处理操作所 ElastiCache 消耗的时间。
**[资源]：**
+ [Valkey 和 Redis OSS 的指标](CacheMetrics.Redis.md)
+ [监控 ElastiCache 使用 Amazon 的最佳实践 CloudWatch](https://aws.amazon.com/blogs/database/monitoring-best-practices-with-amazon-elasticache-for-redis-using-amazon-cloudwatch/)
+ **[最佳] **根据您的需求选择合适的缓存策略。缓存命中率低是由缓存未命中数量造成的。如果您的工作负载设计为缓存未命中数量较低（例如实时通信），则最好对缓存策略进行审查，并为您的工作负载应用最合适的解决方案，例如用于测量内存和性能的查询检测。您用于为填充并维护缓存而实施的实际策略取决于客户端需要缓存的数据以及针对这些数据的访问模式。例如，您不太可能对流媒体应用程序的个性化推荐和热门新闻报道使用相同的策略。
**[资源]：**
+ [Memcached 缓存策略](Strategies.md)
+ [缓存最佳实践](https://aws.amazon.com/caching/best-practices/)
+ [借助 Amazon 实现大规模绩效 ElastiCache 白皮书](https://d0.awsstatic.com/whitepapers/performance-at-scale-with-amazon-elasticache.pdf)
## PE 4：您的工作负载如何优化网络资源和连接的使用？
**问题级简介：**ElastiCache 对于 Valkey，许多应用程序客户端都支持 Memcached 和 Redis OSS，实现方式可能会有所不同。您需要了解现有的网络和连接管理，以分析潜在的性能影响。
**问题级优势：**高效地使用网络资源可以提高集群的性能效率。以下建议可以减少网络需求，并改善集群延迟和吞吐量。
+ **[必需]** 主动管理与 ElastiCache 集群的连接。
+ 应用程序中的连接池减少了通过打开和关闭连接在集群上产生的开销量。 CloudWatch 使用`CurrConnections`和监控 Amazon 中的连接行为`NewConnections`。
+ 通过在适当的位置正确关闭客户端连接来避免连接泄露。连接管理策略包括正确关闭未使用的连接，以及设置连接超时。
+ 对于 Memcached 工作负载，为处理连接预留了可配置的内存量，称为 `memcached_connections_overhead`。
+ **[更佳] **压缩大型对象以减少内存并提高网络吞吐量。
+ 数据压缩可以减少所需的网络吞吐量（Gbps），但会增加应用程序压缩和解压缩数据的工作量。
+ 压缩还会减少键所消耗的内存量
+ 根据您的应用程序需求，考虑压缩比与压缩速度之间的权衡。
+ **[资源]：**
+ [ElastiCache -全球数据存储](https://aws.amazon.com/elasticache/redis/global-datastore/)
+ [Memcached 特定的参数](ParameterGroups.Engine.md#ParameterGroups.Memcached)
+ [ElastiCache 适用于 Redis OSS 的 5.0.3 版本增强了 I/O 处理能力以提高性能](https://aws.amazon.com/about-aws/whats-new/2019/03/amazon-elasticache-for-redis-503-enhances-io-handling-to-boost-performance/)
+ [Valkey 和 Redis OSS 的指标](CacheMetrics.Redis.md)
+ [配置 ElastiCache 以获得更高的可用性](https://aws.amazon.com/blogs/database/configuring-amazon-elasticache-for-redis-for-higher-availability/)
## PE 5：如何管理密钥删除 and/or 驱逐？
**问题级简介：**当群集节点接近内存消耗限制时，工作负载有不同的要求和预期行为。 ElastiCache 有不同的策略来处理这些情况。
**问题级优势：**适当管理可用内存和了解驱逐策略，将有助于确保了解在超过实例内存限制时的集群行为。
+ **[必需] **检测数据访问权限以评估要应用的策略。确定适当的最大内存策略，以控制是否以及如何对集群执行驱逐。
+ 当集群上的最大内存消耗完毕并且制定了允许驱逐的策略时，就会发生驱逐。在这种情况下，集群的行为取决于指定的驱逐策略。此策略可以使用集群参数组上的 `maxmemory-policy` 进行管理。
+ 原定设置策略 `volatile-lru` 通过驱逐设置了过期时间（TTL 值）的键来释放内存。最少使用（LFU）和最近最少使用（LRU）策略会根据使用情况删除键。
+ 对于 Memcached 工作负载，有一个原定设置 LRU 策略来控制每个节点上的驱逐。您可以使用亚马逊上的驱逐指标来监控您的 Amazon ElastiCache 集群上的驱逐次数。 CloudWatch
+ **[更佳]** 对删除行为进行标准化来控制对集群的性能影响，从而避免意外的性能瓶颈。
+ 对 ElastiCache 于 Valkey 和 Redis OSS 工作负载，当从集群中显式删除密钥时，`UNLINK`就像`DEL`：它会删除指定的密钥。但是，该命令在不同的线程中执行实际内存回收，因此它不会阻止，而 `DEL` 会阻止。实际的删除将在稍后异步进行。
+ 对于适用于 Redis OSS 工作负载的 6.x ElastiCache 版本，可以使用参数在参数组中修改`DEL`命令的行为。`lazyfree-lazy-user-del`
+ **[资源]：**
+ [使用 ElastiCache 参数组配置引擎参数](ParameterGroups.md)
+ [UNLINK](https://valkey.io/commands/unlink/)
+ [云财务管理与AWS](https://aws.amazon.com/aws-cost-management/)
## PE 6：你如何对中的数据进行建模和交互 ElastiCache？
**问题级简介：**ElastiCache 在很大程度上取决于所使用的数据结构和数据模型，但它还需要考虑底层数据存储（如果存在）。了解可用的数据结构，并确保使用最适合您需求的数据结构。
**问题层面的好处：**中的数据建模ElastiCache 有多个层次，包括应用程序用例、数据类型和数据元素之间的关系。此外，每个数据类型和命令都有自己有据可查的性能签名。
+ **[最佳] **最佳实践是减少无意中覆盖数据的情况。使用可最大限度地减少重叠键名称的命名约定。数据结构的传统命名使用分层方法，例如：`APPNAME:CONTEXT:ID`（如 `ORDER-APP:CUSTOMER:123`）。
**[资源]：**
+ [键命名](https://docs.gitlab.com/ee/development/redis.html#key-naming)
+ **[最佳]** ElastiCache 对于 Valkey 和 Redis 来说，OSS 命令的时间复杂度由 Big O 表示法定义。这次，命令的复杂性 algorithmic/mathematical 代表了其影响。在应用程序中引入新的数据类型时，需要仔细检查相关命令的时间复杂度。时间复杂度为 O(1) 的命令在时间上是恒定的，不依赖于输入的大小，但时间复杂度为 O(N) 的命令在时间上是线性的，受输入大小影响。由于 Valkey 和 Redis OSS 的单线程设计，大量的高时间复杂度操作将导致性能降低和潜在的操作超时。ElastiCache
**[资源]：**
+ [命令](https://valkey.io/commands/)
+ **[最佳]** APIs 用于获取 GUI 对集群中数据模型的可见性。
**[资源]：**
+ [Redis OSS Commander](https://www.npmjs.com/package/ElastiCache for Redis-commander)
+ [Redis OSS 浏览器](https://github.com/humante/redis-browser)
+ [Redsmin](https://www.redsmin.com/)
## PE 7：如何在您的 Amazon ElastiCache 集群中记录运行缓慢的命令？
**问题级简介：**通过捕获、聚合和通知长时间运行的命令，可以改善性能调优效果。通过了解命令执行需要多长时间，您可以确定哪些命令会导致性能不佳，以及哪些命令会阻碍引擎以最佳状态运行。 ElastiCache 还可以将这些信息转发给亚马逊 CloudWatch 或亚马逊 Kinesis Data Firehose。
**问题级优势：**记录到专用的永久位置并为慢速命令提供通知事件，有助于进行详细的性能分析，并可用于触发自动事件。
+ **[必需]** ElastiCache 运行 Valkey 引擎 7.2 或更高版本，或者运行 Redis OSS 引擎 6.0 或更高版本，正确配置参数组并在集群上启用 SLOWLOG 日志记录。
+ 仅当引擎版本兼容性设置为 Valkey 7.2 及更高版本或 Redis OSS 6.0 或更高版本时，必需的参数才可用。
+ 当命令的服务器执行时间超过指定的值时，就会发生 SLOWLOG 日志记录。集群的行为取决于关联的参数组参数，即 `slowlog-log-slower-than` 和 `slowlog-max-len`。
+ 更改将立即生效。
+ **[最佳]** 利用我们的 Kinesis Data Firehose 功能。 CloudWatch
+ 使用 L CloudWatch ogs Insights 和 Amazon Simple Notification Services 的筛选和警报功能，实现性能监控和事件通知。 CloudWatch
+ 使用 Kinesis Data Firehose 的流式传输功能，将 SLOWLOG 日志归档到永久存储空间或触发自动集群参数调优。
+ 确定 JSON 还是纯文本格式最适合您的需求。
+ 提供发布到 CloudWatch 或 Kinesis Data Firehose 的 IAM 权限。
+ **[更佳] **将 `slowlog-log-slower-than` 配置为原定设置值以外的值。
+ 此参数确定命令在 Valkey 或 Redis OSS 引擎中执行多长时间后会被记录为慢速运行命令。原定设置值为 10000 微秒（10 毫秒）。对于某些工作负载，原定设置值可能过高。
+ 根据应用程序需求和测试结果确定更适合您工作负载的值；但是，值过低可能会生成过多的数据。
+ **[更佳] **将 `slowlog-max-len` 保留为原定设置值。
+ 此参数决定了任何给定时间在 Valkey 或 Redis OSS 内存中捕获的慢速运行命令数上限。值为 0 会有效地禁用捕获。该值越高，存储在内存中的条目就越多，从而减少了重要信息在查看之前被驱逐的可能性。原定设置值为 128。
+ 原定设置值适用于大多数工作负载。如果需要通过 SLOWLOG 命令在 valkey-cli 的扩展时段内分析数据，请考虑增加此值。这允许在 Valkey 或 Redis OSS 内存中保留更多命令。
如果您将 SLOWLOG 数据发送到 Logs 或 Kinesis Data Firehose，则这些数据将被保存，并且可以在系统之外进行分析，从而减少 ElastiCache 在 Valkey 或 Redis OSS 内存中存储大量运行缓慢的命令的需求。 CloudWatch
+ **[资源]：**
+ [如何在集群中开启慢速日志？](https://repost.aws/knowledge-center/elasticache-turn-on-slow-log)
+ [日志传输](Log_Delivery.md)
+ [Redis OSS 特定参数](ParameterGroups.Engine.md#ParameterGroups.Redis)
+ [https://aws.amazon.com/cloudwatch/](https://aws.amazon.com/cloudwatch/)Amazon CloudWatch
+ [Amazon Kinesis Data Firehose](https://aws.amazon.com/kinesis/data-firehose/)
## PE8: Auto Scaling 如何帮助提高ElastiCache 集群的性能？
**问题级简介：**通过实现 Valkey 或 Redis OSS 自动缩放功能，您的 ElastiCache 组件可以随着时间的推移进行调整以自动增加或减少所需的分片或副本。这可以通过实施目标跟踪或计划的扩展策略来实现。
**问题层面的好处：**了解和规划工作负载的峰值可以确保增强缓存性能和业务连续性。 ElastiCache Auto Scaling 会持续监控您的 CPU/内存利用率，以确保您的集群以所需的性能水平运行。
+ **[必需]** 在为 Valkey 或 Redis OSS 启动集群时：ElastiCache
1. 确保已启用集群模式
1. 确保该实例属于支持自动扩缩的特定类型和大小的系列
1. 确保集群未在全局数据存储、Outposts 或本地区域中运行
**[资源]：**
+ [扩展 Valkey 和 Redis OSS 中的集群（启用集群模式）](scaling-redis-cluster-mode-enabled.md)
+ [将自动扩缩与分片结合使用](AutoScaling-Using-Shards.md)
+ [将自动扩缩与副本结合使用](AutoScaling-Using-Replicas.md)
+ **[最佳] **确定您的工作负载是读取密集型还是写入密集型，以定义扩展策略。要想获得最佳性能，请仅使用一个跟踪指标。建议避免针对每个维度使用多个策略，因为自动扩缩策略会在达到目标时横向扩展，但只有在所有目标跟踪策略都准备好横向缩减时才会进行横向缩减。
**[资源]：**
+ [自动扩缩策略](AutoScaling-Policies.md)
+ [定义扩展策略](AutoScaling-Scaling-Defining-Policy-API.md)
+ **[最佳] **在一段时间内持续监控性能有助于您检测工作负载变化，如果在特定时间点进行监控，将不会注意到这些变化。您可以分析四周内集群利用率的相应CloudWatch 指标，以确定目标值阈值。如果您仍然不确定要选择哪个值，我们建议您从支持的最小预定义指标值开始。
**[资源]：**
+ [使用 CloudWatch 指标监控使用情况](CacheMetrics.md)
+ **[更好]** 我们建议使用预期的最小和最大工作负载测试您的应用程序，以确定集群制定扩展策略和缓解可用性问题 shards/replicas 所需的确切数量。
**[资源]：**
+ [注册可扩展目标](AutoScaling-Register-Policy.md)
+ [使用注册可扩展目标AWS CLI](AutoScaling-Scaling-Registering-Policy-CLI.md)
# Amazon ElastiCache Well-Architected Lens 成本优化支柱
成本优化支柱侧重于避免不必要的成本。关键主题包括了解和控制资金花在哪里、选择最合适的节点类型（使用支持基于工作负载需求进行数据分层的实例）、相应数量的资源类型（有多少只读副本）、分析一段时间内的支出，以及在不超支的情况下进行扩展以满足业务需求。
**Topics**
+ [成本 1：如何识别和跟踪与 ElastiCache 资源相关的成本？ 您如何建立让用户能够创建、管理和处置已创建资源的机制？](#CostOptimizationPillarCOST1)
+ [成本 2：如何使用持续监控工具来优化与 ElastiCache 资源关联的成本？](#CostOptimizationPillarCOST2)
+ [成本 3：您是否应该使用支持数据分层的实例类型？ 数据分层有哪些优点？ 何时不使用数据分层实例？](#CostOptimizationPillarCOST3)
## 成本 1：如何识别和跟踪与 ElastiCache 资源相关的成本？ 您如何建立让用户能够创建、管理和处置已创建资源的机制？
**问题级简介：**要了解成本指标，需要多个团队参与和协作：软件工程、数据管理、产品负责人、财务和领导层。要确定关键成本驱动因素，则要求所有相关方了解服务使用控制杠杆和成本管理的利弊，这通常是成功与不太成功的成本优化工作之间的关键区别。确保您有适当的流程和工具来跟踪从开发到生产和停用期间创建的资源，这有助于您管理与 ElastiCache 关联的成本。
**问题级优势：**要持续跟踪与您工作负载关联的所有成本，需要深入了解将 ElastiCache 作为其组件之一的架构。此外，您应该制定成本管理计划，以收集使用情况并将其与预算进行比较。
+ **[必需] **建立一个云卓越中心（CCoE），作为其创始章程之一，负责定义、跟踪组织的 ElastiCache 使用情况，并根据相关指标采取措施。如果 CCoE 存在且正常运行，请确保其知道如何读取和跟踪与 ElastiCache 关联的成本。创建资源时，使用 IAM 角色和 IAM policy 来验证只有特定的团队和组才能实例化资源。这确保了成本与业务成果相关联，并从成本角度建立了明确的问责制。
1. CCoE 应基于分类数据识别、定义和发布与关键 ElastiCache 使用情况相关的成本指标（每月定期更新这），例如：
1. 使用的节点类型及其属性：标准与内存优化型、按需实例与预留实例、区域和可用区
1. 环境类型：免费环境、开发环境、测试环境和生产环境
1. 备份存储和保留策略
1. 区域内和跨区域的数据传输
1. 在 Amazon Outposts 上运行的实例
1. CCoE 由一个跨职能团队组成，其代表来自组织中软件工程、数据管理、产品团队、财务团队和领导团队的非专属代表。
**[资源]：**
+ [创建云卓越中心](https://docs.aws.amazon.com/whitepapers/latest/cost-optimization-laying-the-foundation/cloud-center-of-excellence.html)
+ [Amazon ElastiCache 定价](https://aws.amazon.com/elasticache/pricing/)
+ **[必需] **使用成本分配标签以较低的粒度跟踪成本。使用 AWS 成本管理来可视化、了解和管理一段时间内的 AWS 成本和使用情况。
1. 使用标签来整理资源，并可以使用成本分配标签来细致地跟踪 AWS 成本。在您激活成本分配标签后，AWS 将使用成本分配标签来整理您的资源分配报告中的资源成本，以方便您对 AWS 成本进行分类和跟踪。AWS 提供了两种类型的成本分配标签：AWS 生成的标签和用户定义的标签。AWS 将为您定义、创建和应用 AWS 生成的标签，而您将定义、创建和应用用户定义的标签。您必须先分别激活这两种类型的标签，然后这些标签才能显示在成本管理中或成本分配报告上。
1. 使用成本分配标签整理 AWS 账单，以反映您自己的成本结构。在 Amazon ElastiCache 中向资源添加成本分配标签时，将可以根据资源标签值对发票上的费用进行分组，从而跟踪您的成本。您应该考虑合并标签，以采用更高详细信息级别跟踪成本。
**[资源]：**
+ [使用 AWS 成本分配标签](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/cost-alloc-tags.html)
+ [使用成本分配标签监控成本](Tagging.md)
+ [AWS Cost Explorer](https://aws.amazon.com/aws-cost-management/aws-cost-explorer/)
+ **[最佳] **将 ElastiCache 成本与涵盖整个组织的指标联系起来。
1. 考虑业务指标以及延迟等运营指标 - 您业务模式中有哪些概念可以被不同角色理解？ 这些指标需要让组织中尽可能多的角色能够理解。
1. 示例 - 同时服务的用户数、每个操作和用户的最大和平均延迟、用户参与度分数、用户每周返回率、会话长度/用户、放弃率、缓存命中率以及跟踪的键
**[资源]：**
+ [使用 CloudWatch 指标监控使用情况](CacheMetrics.md)
+ **[良好] **在使用 ElastiCache 的整个工作负载中，保持最新的架构和运营指标和成本可见性。
1. 了解您的整个解决方案生态系统，ElastiCache 往往是其技术组合中完整 AWS 服务生态系统的一部分，例如，从客户端到 API Gateway、Redshift 和 QuickSight（用于报告工具）。
1. 在架构图上映射解决方案的各个组成部分，包括客户端、连接、安全性、内存操作、存储、资源自动化、数据访问和管理。每层都连接到整个解决方案且具有其自身的需求和功能，可以助力和/或帮助您管理总体成本。
1. 您的图表应包括计算、网络、存储、生命周期策略、指标收集的使用情况以及应用程序的操作和功能 ElastiCache 元素
1. 工作负载的要求可能会不断变化，为了在工作负载成本管理中保持主动性，您必须继续维护和记录您对基本组件以及主要功能目标的理解。
1. 管理层在可见性、问责制、优先级划分和资源方面的支持对于您为 ElastiCache 制定有效的成本管理策略至关重要。
## 成本 2：如何使用持续监控工具来优化与 ElastiCache 资源关联的成本？
**问题级简介：**您需要在您的 ElastiCache 成本和应用程序性能指标之间取得适当的平衡。Amazon CloudWatch 提供关键运营指标的可见性，可以帮助您评测，相对于您的需求，您的 ElastiCache 资源是过度使用还是未得到充分利用。从成本优化的角度来看，您需要了解何时过度预调配，并能够开发适当的机制来调整您的 ElastiCache 资源的规模，同时保持运营、可用性、弹性和性能需求。
**问题级优势：**在理想状态下，您将预调配足够的资源来满足工作负载的运维需求，并且不会出现未充分利用的资源，从而导致成本状态欠佳。您需要能够识别和避免长时间运行规模过大的 ElastiCache 资源。
+ **[必需] **使用 CloudWatch 监控您的 ElastiCache 集群，并分析这些指标与您 AWS Cost Explorer 成本管理服务控制面板的相关性。
1. ElastiCache 提供主机层面级指标（例如 CPU 使用率）和特定于缓存引擎软件的指标（例如缓存获取次数和缓存未命中数）。这些指标每隔 60 秒对每个缓存节点进行测量并发布结果。
1. ElastiCache 性能指标（CPUUtilization、EngineUtilization、SwapUsage、CurrConnections 和 Evictions）可能表明您需要纵向扩展/缩减（使用更大/更小的缓存节点类型）或横向缩减/横向扩展（添加更多/更少的分片）。通过创建 PlayBook 矩阵来了解扩展决策的成本影响，该矩阵可估算满足应用程序性能阈值所需的额外成本以及最小和最大时间长度。
**[资源]：**
+ [使用 CloudWatch 指标监控使用情况](CacheMetrics.md)
+ [应监控哪些指标？](CacheMetrics.WhichShouldIMonitor.md)
+ [Amazon ElastiCache 定价](https://aws.amazon.com/elasticache/pricing/)
+ **[必需] **了解并记录您的备份策略和成本影响。
1. 使用 ElastiCache，备份存储在 Amazon S3 中，而 Amazon S3 可提供持久存储。您需要了解与故障恢复能力有关的成本影响。
1. 启用自动备份，这将删除超过保留期限的备份文件。
**[资源]：**
+ [计划自动备份](backups-automatic.md)
+ [Amazon Simple Storage Service 定价](https://aws.amazon.com/s3/pricing/)
+ **[最佳] **作为一种深思熟虑的策略，应对实例使用预留节点，以管理已充分了解和记录的工作负载的成本。预留节点需支付预付费用，此费用取决于节点类型和预留时间长短（一年或三年）。此费用远低于按需节点产生的每小时使用费。
1. 在收集到足够的数据来评估预留实例需求之前，您可能需要使用按需节点运行您的 ElastiCache 集群。规划和记录满足需求所需的资源，并比较不同实例类型（按需型与预留）的预期成本
1. 定期评测新的可用缓存节点类型，并从成本和运营指标的角度评测将您的实例集迁移到新的缓存节点类型是否合理
## 成本 3：您是否应该使用支持数据分层的实例类型？ 数据分层有哪些优点？ 何时不使用数据分层实例？
**问题级简介：**选择适当的实例类型不仅会对性能和服务级别产生影响，还会对财务状况产生影响。实例类型具有不同的关联成本。选择一种或几种可以满足内存中所有存储需求的大型实例类型可能是一个自然而然的决定。但是，随着项目日趋成熟，这可能会对成本产生重大影响。要确保选择正确的实例类型，需要定期检查 ElastiCache 对象的空闲时间。
**问题级优势：**您应该清楚地了解各种实例类型对您当前和未来的成本有何影响。边际或定期的工作负载变化不应导致过多的成本变化。如果工作负载允许，支持数据分层的实例类型提供的每可用存储的价格将更优惠。这是因为每实例可用的 SSD 存储数据分层实例所支持的每实例的总数据容量要高得多。
+ **[必需]** 了解数据分层实例的局限性
1. 仅适用于 ElastiCache for Valkey 或 ElastiCache for Redis OSS 集群。
1. 支持数据分层的实例类型非常有限。
1. 仅支持 ElastiCache for Redis OSS v6.2 及更高版本
1. 大型项目不会交换到 SSD。超过 128MiB 的对象保留在内存中。
**[资源]：**
+ [数据分层](data-tiering.md)
+ [Amazon ElastiCache 定价](https://aws.amazon.com/elasticache/pricing/)
+ **[必需] **了解您的工作负载定期访问数据库的百分比。
1. 数据分层实例非常适合经常访问整个数据集的一小部分但仍需要快速访问其余数据的工作负载。换句话说，热数据与温数据的比例约为 20:80。
1. 制定对象空闲时间的集群级跟踪。
1. 超过 500Gb 数据的大型实现是不错的选择
+ **[必需] **了解数据分层实例对于某些工作负载不是可选的。
1. 访问不常用的对象会产生少许性能成本，因为这些对象会被交换到本地 SSD。如果您的应用程序对响应时间敏感，请测试对工作负载的影响。
1. 不适合主要存储大小超过 128MiB 的大型对象的缓存。
**[资源]：**
+ [限制](data-tiering.md#data-tiering-prerequisites)
+ **[最佳] **预留实例类型支持数据分层。这可确保在每个实例的数据存储量方面实现最低的成本。
1. 在更好地了解您的需求之前，您可能需要使用非数据分层实例运行 ElastiCache 集群。
1. 分析您的 ElastiCache 集群的数据使用模式。
1. 创建定期收集对象空闲时间的自动作业。
1. 如果您发现很大一部分对象（大约 80%）在认为适合您工作负载的时间段内处于空闲状态，请记录调查发现，并建议将集群迁移到支持数据分层的实例。
1. 定期评测新的可用缓存节点类型，并从成本和运营指标的角度评测将您的实例集迁移到新的缓存节点类型是否合理。
**[资源]：**
+ [对象空闲时间](https://valkey.io/commands/object-idletime/)
+ [Amazon ElastiCache 定价](https://aws.amazon.com/elasticache/pricing/)