Amazon ElastiCache Well-Architected Lens 卓越运营支柱 - Amazon ElastiCache
OE 1：您如何理解和响应 ElastiCache 集群触发的提示和事件？OE 2：您何时以及如何扩展现有的 ElastiCache 集群？OE 3：如何管理您的 ElastiCache 集群资源并使集群保持最新状态？OE 4：如何管理客户端与 ElastiCache 集群的连接？OE 5：如何为工作负载部署 ElastiCache 组件？OE 6：如何针对故障进行规划和缓解故障？OE 7：如何排查 Redis 引擎事件的问题？
Amazon Web Services 文档中描述的 Amazon Web Services 服务或功能可能因区域而异。要查看适用于中国区域的差异，请参阅 中国的 Amazon Web Services 服务入门 (PDF)。

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

Amazon ElastiCache Well-Architected Lens 卓越运营支柱

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

OE 1：您如何理解和响应 ElastiCache 集群触发的提示和事件？

问题级简介：当您运营 ElastiCache 集群时，您可以选择在发生特定事件时接收通知和提示。原定设置情况下，ElastiCache 会记录与您的资源相关的事件，例如失效转移、节点更换、扩展操作、定期维护等。每个事件都包括日期和时间、来源名称和来源类型以及描述。

问题级优势：能够理解和管理事件（即触发由集群生成的提示）背后的根本原因，将使您能够更有效地运营并对事件做出适当的响应。

  • [必需] 在 ElastiCache 控制台（选择您的区域后）上或使用 Amazon 命令行界面（Amazon CLI）describe-events 命令和 ElastiCache API 查看由 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（仅限 Redis）

    • [资源]：

  • [最佳] 要自动响应事件，请利用 SNS 和 Lambda 函数等 Amazon 产品和服务功能。遵循最佳实践，进行小的、频繁的、可逆的更改，作为代码来随着时间推移发展您的运营。您应该使用 Amazon CloudWatch 指标来监控您的集群。

    [资源]：使用 Amazon Lambda、Amazon Route 53 和 Amazon SNS 监控 Amazon ElastiCache for Redis（已禁用集群模式）只读副本端点，了解使用 Lambda 和 SNS 的使用案例。

OE 2：您何时以及如何扩展现有的 ElastiCache 集群？

问题级简介：合理调整您的 ElastiCache 集群规模是一种平衡行为，每次底层工作负载类型发生变化时都需要进行评估。您的目标是在适合您的工作负载的规模合适的环境中运行。

问题级优势：资源过度利用可能会导致延迟时间增加和整体性能下降。另一方面，利用率不足可能导致资源预调配过多，成本优化不够理想。通过适当地调整环境规模，您可以在性能效率与成本优化之间取得平衡。为了修正资源利用率过高或不足的情况，ElastiCache 可以在两个维度上进行扩展。您可以通过增加或减少节点容量来纵向扩展。您也可以通过添加和移除节点来横向扩展。

OE 3：如何管理您的 ElastiCache 集群资源并使集群保持最新状态？

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

问题级优势：将开发、测试和生产环境分开是最佳运营实践。以下方法也是最佳实践：跨环境的集群和节点使用众所周知和有据可查的流程应用最新的软件补丁。利用原生 ElastiCache 功能，可以让您的工程团队专注于实现业务目标，而不是 ElastiCache 的维护。

  • [最佳] 在可用的最新引擎版本上运行，并在自助服务更新可用时尽快应用这些更新。ElastiCache 会在您指定的集群维护时段内自动更新其底层基础设施。但是，集群中运行的节点会通过自助更新进行更新。这些更新可以分为两种类型：安全补丁或次要软件更新。确保您了解补丁类型之间的区别及其应用时间。

    [资源]：

  • [最佳] 使用标签整理 ElastiCache 资源。在复制组上使用标签，而不是在单个节点上使用标签。您可以配置要在查询资源时显示的标签，也可以使用标签来执行搜索和应用筛选条件。您应该使用资源组来轻松创建和维护共享通用标签集的资源集合。

    [资源]：

OE 4：如何管理客户端与 ElastiCache 集群的连接？

问题级简介：大规模运营时，您需要了解您的客户端如何与 ElastiCache 集群连接，以管理应用程序的运营环节（如响应时间）。

问题级优势：选择最合适的连接机制，可确保您的应用程序不会因连接错误（如超时）而断开连接。

  • [必需] 将读取操作与写入操作分开，并连接到副本节点以执行读取操作。但请注意，当您将写入与读取分开时，由于 Redis 复制的异步性质，您将失去在写入密钥后立即读取密钥的能力。可以利用 WAIT 命令来提高现实世界的数据安全性，并强制副本在响应客户端之前确认写入，但代价是总体性能降低。使用禁用集群模式的 ElastiCache 读取器端点，可以在 ElastiCache for Redis 客户端库中配置使用副本节点进行读取操作。如果启用了集群模式，请使用 ElastiCache For Redis READONLY 命令。对于许多 ElastiCache for Redis 客户端库，ElastiCache for Redis READONLY 是原定设置情况下或通过配置设置实现的。

    [资源]：

  • [必需] 使用连接池。建立 TCP 连接在客户端和服务器端都会消耗 CPU 时间，而池化允许您重用 TCP 连接。

    为了减少连接开销，您应该使用连接池。有了连接池，您的应用程序可以“随意”重用和释放连接，而无需支付建立连接的成本。您可以通过 ElastiCache for Redis 客户端库（如果支持），使用适用于您的应用程序环境的框架实现连接池，也可以从头开始构建连接池。

  • [最佳] 确保将客户端的套接字超时设置为至少一秒（相比之下，多个客户端的典型原定设置值为“无”）。

    • 当服务器负载较高时，将超时值设置得过低可能会导致超时。如果将其设置得过高，则可能会导致您的应用程序花费很长时间才能检测到连接问题。

    • 通过在客户端应用程序中实现连接池来控制新连接的量。这样可以减少打开和关闭连接所需的延迟和 CPU 利用率，并且如果在集群上启用了 TLS，则执行 TLS 握手。

    [资源]：配置 Amazon ElastiCache for Redis 以提高可用性

  • [良好] 使用管道传输（在您的使用案例允许的情况下）可以显著提高性能。

    • 通过管道传输，可以减少应用程序客户端和集群之间的往返时间（RTT），即使客户端尚未读取之前的响应，也可以处理新的请求。

    • 使用管道传输，您可以向服务器发送多个命令，而无需等待回复/确认。管道传输的缺点是，当您最终批量获取所有响应时，可能出现了一个直到最后您才会发现的错误。

    • 实现在返回遗漏错误请求的错误时重试请求的方法。

    [资源]：管道传输

OE 5：如何为工作负载部署 ElastiCache 组件？

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

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

通过了解工作负载隔离要求，您可以选择为每个工作负载提供专用 ElastiCache 环境，或者将多个工作负载合并为单个集群，或者将它们组合在一起。了解权衡利弊有助于在卓越运营和成本优化之间取得平衡

  • [必需] 了解 ElastiCache 可用的部署选项，并尽可能自动执行这些过程。可能的自动化途径包括 CloudFormation、Amazon CLI/SDK 和 API。

    [资源]：

  • [必需] 对于所有工作负载，确定所需的集群隔离级别。

    • [最佳]：高度隔离 – 工作负载与集群的映射为 1:1。允许在每个工作负载的基础上对 ElastiCache 资源的访问、大小、扩展和管理进行最精细的控制。

    • [更佳]：中等隔离 – M:1 按目的隔离，但可能在多个工作负载之间共享（例如，一个集群专门用于缓存工作负载，另一个集群专门用于消息传递）。

    • [良好]：低度隔离 – M:1 全用途，完全共享。建议用于可接受共享访问的工作负载。

OE 6：如何针对故障进行规划和缓解故障？

问题级简介：卓越运营包括通过定期进行“崩溃前”练习来预测故障，以确定潜在的故障来源，从而消除或缓解故障。ElastiCache 提供失效转移 API，允许模拟节点故障事件，用于测试目的。

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

[必需] 定期在开发/测试账户中执行失效转移测试。TestFailover

OE 7：如何排查 Redis 引擎事件的问题？

问题级简介：卓越运营要求能够调查服务级和引擎级信息，以分析集群的运行状况和状态。Amazon ElastiCache for Redis 可以向 Amazon CloudWatch 和 Amazon Kinesis Data Firehose 发送 Redis 引擎日志。

问题级优势：在 Amazon ElastiCache for Redis 集群上启用 Redis 引擎日志后，可以深入了解影响集群运行状况和性能的事件。Redis 引擎日志直接提供来自 Redis 引擎的数据，而这些数据无法通过 ElastiCache 事件机制获得。通过仔细观察 ElastiCache 事件（请参阅前面的 OE-1）和 Redis 引擎日志，可以从 ElastiCache 服务的角度和 Redis 引擎的角度确定排查问题时的事件顺序。

  • [必需] 确保已启用 Redis 引擎日志记录功能，该功能在 ElastiCache for Redis 6.2 及更高版本中可用。这可以在集群创建期间执行，也可以在创建后通过修改集群来执行。

    • 确定是 Amazon CloudWatch Logs 还是 Amazon Kinesis Data Firehose 是 Redis 引擎日志的合适目标。

    • 在 CloudWatch 或 Kinesis Data Firehose 中选择相应的目标日志来保存日志。如果您有多个集群，请考虑为每个集群使用不同的目标日志，因为这将有助于在进行故障排除时隔离数据。

    [资源]：

  • [最佳] 如果使用 Amazon CloudWatch Logs，可以考虑利用 Amazon CloudWatch Logs Insights 查询 Redis 引擎日志以获取重要信息。

    例如，针对包含 Redis 引擎日志的 CloudWatch 日志组创建查询，这将返回日志级别为“警告”的事件，例如：

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

    [资源]：使用 CloudWatch Logs Insights 分析日志数据