

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

# Amazon ElastiCache Well-Architected Lens 卓越运营支柱
<a name="OperationalExcellencePillar"></a>

卓越运营支柱侧重于运行和监控系统以提供商业价值，并不断改进流程和程序。关键主题包括自动变更、响应事件和定义管理日常运营的标准。

**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 集群触发的警报和事件？
<a name="OperationalExcellencePillarOE1"></a>

**Question-level 简介：**操作ElastiCache 集群时，您可以选择在发生特定事件时接收通知和警报。 ElastiCache，默认情况下，[会记录与您的资源相关的事件](ECEvents.md)，例如故障转移、节点更换、扩展操作、定期维护等。每个事件都包括日期和时间、来源名称和来源类型以及描述。

**Question-level 好处：**能够了解和管理触发集群生成的警报的事件背后的根本原因，使您能够更有效地操作并适当地响应事件。
+ **[必需]** [在 ElastiCache 控制台ElastiCache 上（选择您的地区后）或使用[亚马逊命令行界面](https://aws.amazon.com/cli) (AWS CLI) desc [ribe-events 命令和 API 查看生成的事件](https://docs.aws.amazon.com/cli/latest/reference/elasticache/describe-events.html)。ElastiCache ](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_DescribeEvents.html)配置 ElastiCache 为使用亚马逊简单通知服务 (Amazon SNS) Service 发送重要集群事件的通知。在集群中使用 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 Functions 等 AWS 产品和服务功能。遵循最佳实践，进行小的、频繁的、可逆的更改，作为代码来随着时间推移发展您的运营。您应该使用 Amazon CloudWatch 指标来监控您的集群。

  **[资源]：**针对使用 Lambda 和 SNS 的用例，[使用 AWS Lambda、Amazon Route 53 和亚马逊 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/)。

## OE 2：您何时以及如何扩展现有 ElastiCache 集群？
<a name="OperationalExcellencePillarOE2"></a>

**Question-level 简介：**Right-sizing 您的ElastiCache 集群是一种平衡行为，每次底层工作负载类型发生变化时都需要对其进行评估。您的目标是在适合您的工作负载的规模合适的环境中运行。

**Question-level 好处：**Over-utilization 您的资源可能会导致延迟增加和整体性能降低。 Under-utilization另一方面，可能会导致资源过度配置，成本优化效果不佳。通过适当地调整环境规模，您可以在性能效率与成本优化之间取得平衡。要修复资源利用率过高或不足， ElastiCache 可以从两个维度进行扩展。您可以通过增加或减少节点容量来纵向扩展。您也可以通过添加和移除节点来横向扩展。
+ **[必需]** 应通过分流读取操作并将读取操作重定向到副本节点，来解决主节点上的 CPU 和网络过度利用问题。使用副本节点进行读取操作以降低主节点利用率。这可以在您的 Valkey 或 Redis OSS 客户端库中进行配置，方法是连接到禁用集群模式的 ElastiCache 读取器终端节点，或者在启用集群模式时使用 READONLY 命令。

  **[资源]：**
  + [在中查找连接端点 ElastiCache](Endpoints.md)
  + [集群 Right-Sizing](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 个节点。如果启用了集群模式，则这同样适用于集群的每个分片。此外，您可以增加或减少分片的数量。

  **[资源]：**
  + [监控 ElastiCache 使用 Amazon 的最佳实践 CloudWatch](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 天。

  **[资源]：**
  + [ ElastiCache 使用 CloudWatch指标进行监控](CacheMetrics.md)
  + [使用指标监控 Memcache CloudWatch d](CacheMetrics.md)
  + [监控 ElastiCache 使用 Amazon 的最佳实践 CloudWatch](https://aws.amazon.com/blogs/database/monitoring-best-practices-with-amazon-elasticache-for-redis-using-amazon-cloudwatch/)
+ **[最佳]** 如果您的 ElastiCache 资源是用创建的，CloudFormation 则最佳做法是使用 CloudFormation模板执行更改，以保持操作一致性，避免非托管配置更改和堆栈漂移。

  **[资源]：**
  + [ElastiCache 的资源类型参考 CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/AWS_ElastiCache.html)
+ **[最佳]** 使用集群操作数据自动执行扩展操作，并在中定义阈值 CloudWatch 以设置警报。使用CloudWatch 事件和简单通知服务 (SNS) Service 触发 Lambda 函数并执行 ElastiCache API 来自动扩展您的集群。例如，当 `EngineCPUUtilization` 指标在很长一段时间内达到 80% 时，向您的集群添加分片。另一种选择是使用 `DatabaseMemoryUsedPercentages` 来设置基于内存的阈值。

  **[资源]：**
  + [使用 Amazon CloudWatch 警报](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)
  + [什么是亚马逊 CloudWatch 活动？](https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/WhatIsCloudWatchEvents.html)
  + [AWS Lambda 与 Amazon 简单通知服务配合使用](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 群集资源并使集群保持最新状态？
<a name="OperationalExcellencePillarOE3"></a>

**Question-level 简介：**在大规模运营时，必须能够精确定位和识别所有 ElastiCache资源。在推出新的应用程序功能时，您需要在所有 ElastiCache 环境类型（开发、测试和生产）中创建集群版本对称性。资源属性允许您针对不同的运营目标（例如，在推出新功能和启用新的安全机制时）将环境分开。

**Question-level 好处：**将开发、测试和生产环境分开是最佳操作实践。以下方法也是最佳实践：跨环境的集群和节点使用众所周知和有据可查的流程应用最新的软件补丁。利用原生 ElastiCache 功能使您的工程团队能够专注于实现业务目标，而不是 ElastiCache 维护。
+ **[最佳]** 在可用的最新引擎版本上运行，并在 Self-Service 更新可用时尽快应用更新。 ElastiCache 在您指定的集群维护时段内自动更新其底层基础架构。但是，集群中运行的节点会通过更新进行 Self-Service 更新。这些更新可以分为两种类型：安全补丁或次要软件更新。确保您了解补丁类型之间的区别及其应用时间。

  **[资源]：**
  + [Self-Service 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)
  + [ElastiCache 的资源类型参考 CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/AWS_ElastiCache.html)
  + [参数组](ParameterGroups.Engine.md#ParameterGroups.Redis)

## OE 4：如何管理客户与 ElastiCache 集群的连接？
<a name="OperationalExcellencePillarOE4"></a>

**Question-level 简介：**在大规模运营时，您需要了解您的客户端如何与 ElastiCache 集群连接，以管理应用程序的运行方面（例如响应时间）。

**Question-level 好处：**选择最合适的连接机制可确保您的应用程序不会因为连接错误（例如超时）而断开连接。
+ **[必需]** 将读取操作与写入操作分开，并连接到副本节点以执行读取操作。但请注意，当您将写入与读取分开时，由于 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/)
+ **[良好]** 使用管道传输（在您的使用案例允许的情况下）可以显著提高性能。
  + 通过管道传输，您可以缩短应用程序客户端和集群之间的 Round-Trip 时间 (RTT)，即使客户端尚未读取之前的响应，也可以处理新的请求。
  + 使用流水线，您无需等待即可向服务器发送多个命令。 replies/ack管道传输的缺点是，当您最终批量获取所有响应时，可能出现了一个直到最后您才会发现的错误。
  + 实现在返回遗漏错误请求的错误时重试请求的方法。

  **[资源]：**[管道传输](https://valkey.io/topics/pipelining/)

## OE 5：如何为工作负载部署 ElastiCache 组件？
<a name="OperationalExcellencePillarOE5"></a>

**Question-level 简介：**可以通过 AWS 控制台手动部署ElastiCache 环境，也可以通过 API、CLI、工具包等以编程方式部署环境。卓越运营最佳实践建议尽可能通过代码自动部署。此外，可以按工作负载隔离 ElastiCache 集群，也可以组合集群以实现成本优化。

**Question-level 好处：**为您的 ElastiCache 环境选择最合适的部署机制可以随着时间的推移改善卓越运营。建议尽可能以代码形式执行操作，以最大限度地减少人为错误并改善可重复性、灵活性以及对事件的响应时间。

通过了解工作负载隔离要求，您可以选择为每个工作负载设置专用 ElastiCache 环境，或者将多个工作负载组合成单个集群或它们的组合。了解权衡利弊有助于在卓越运营和成本优化之间取得平衡
+ **[必需]** 了解可用的部署选项 ElastiCache，并尽可能自动执行这些过程。可能的自动化途径包括 CloudFormation AWS CLI/SDK、和 API。

  **[资源]：**
  + [亚马逊 ElastiCache 资源类型参考](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/AWS_ElastiCache.html)
  + [elasticache](https://docs.aws.amazon.com/cli/latest/reference/elasticache/index.html)
  + [亚马逊 ElastiCache API 参考](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/Welcome.html)
+ **[必需]** 对于所有工作负载，确定所需的集群隔离级别。
  + **[最佳]：**高度隔离 – 工作负载与集群的映射为 1:1。允许根据每个工作负载对 ElastiCache 资源的访问、规模、扩展和管理进行最精细的控制。
  + **[更好]：**中等隔离 — 按目的 M:1隔离，但可能在多个工作负载之间共享（例如，一个专门用于缓存工作负载的集群，另一个专门用于消息传递的集群）。
  + **[良好]：**低隔离 — M:1 多用途，完全共享。建议用于可接受共享访问的工作负载。

## OE 6：如何针对故障进行规划和缓解故障？
<a name="OperationalExcellencePillarOE6"></a>

**Question-level 简介：**卓越运营包括通过定期进行 “验尸” 活动来预测故障，以确定潜在的故障来源，从而消除或缓解故障。 ElastiCache 提供故障转移 API，允许模拟节点故障事件，用于测试目的。

**Question-level 好处：**通过提前测试故障场景，您可以了解它们如何影响您的工作负载。这样可以安全地测试响应过程及其有效性，并让您的团队熟悉其执行情况。

**[必需]** 定期在dev/test 账户中执行故障转移测试。 [TestFailover](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_TestFailover.html)

## OE 7：如何排查 Valkey 或 Redis OSS 引擎事件的问题？
<a name="OperationalExcellencePillarOE7"></a>

**Question-level 简介：**卓越运营要求能够调查服务级别和引擎级信息，以分析集群的运行状况和状态。 ElastiCache 可以向亚马逊 CloudWatch 和亚马逊 Kinesis Data Firehose 发送 Valkey 或 Redis OSS 引擎日志。

**Question-level 好处：**在 ElastiCache 集群上启用 Valkey 或 Redis OSS 引擎日志可以深入了解影响集群运行状况和性能的事件。Valkey 或 Redis OSS 引擎日志直接提供来自引擎的数据，这些数据无法通过 ElastiCache 事件机制获得。通过仔细观察 ElastiCache 事件（参见前文 OE-1）和引擎日志，可以从ElastiCache 服务角度和引擎角度确定故障排除时的事件顺序。
+ **[必需]** 确保已启用 Redis OSS 引擎日志记录功能，该功能从 6.2 ElastiCache 版起适用于 Redis OSS 及更高版本。这可以在集群创建期间执行，也可以在创建后通过修改集群来执行。
  + 确定亚马逊 CloudWatch 日志还是亚马逊 Kinesis Data Firehose 是 Redis OSS 引擎日志的合适目标。
  + 在 Kinesis Data Firehose CloudWatch 或 Kinesis Firehose 中选择相应的目标日志来保留这些日志。如果您有多个集群，请考虑为每个集群使用不同的目标日志，因为这将有助于在进行故障排除时隔离数据。

  **[资源]：**
  + 日志传输：[日志传输](Log_Delivery.md)
  + 日志目的地：[Amazon CloudWatch 日志](Logging-destinations.md#Destination_Specs_CloudWatch_Logs)
  + 亚马逊 CloudWatch 日志简介：[什么是亚马逊 CloudWatch 日志？](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)
+ **[最佳]** 如果使用亚马逊 CloudWatch 日志，可以考虑利用 Amazon CloudWatch Logs Insights 查询 Valkey 或 Redis OSS 引擎日志以获取重要信息。

  例如，针对包含 Valkey 或 Redis OSS 引擎日志的日志组创建查询，这些日志将返回带 LogLevel 有 “警告” 的事件，例如： CloudWatch 

  ```
  fields @timestamp, LogLevel, Message
  | sort @timestamp desc
  | filter LogLevel = "WARNING"
  ```

  **[资源]：**使用 Log [ CloudWatch s Insights 分析日志数据](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AnalyzingLogData.html)