亚马逊 Well-A ElastiCache rchitected 镜头卓越运营支柱 - Amazon ElastiCache
OE 1：您如何理解和响应 ElastiCache 集群触发的警报和事件？OE 2：您何时以及如何扩展现有 ElastiCache 集群？OE 3：如何管理集 ElastiCache 群资源和维护集群 up-to-date？OE 4：如何管理客户与 ElastiCache 集群的连接？OE 5：如何为工作负载部署 ElastiCache 组件？OE 6：如何针对故障进行规划和缓解故障？OE 7：如何对 Redis OSS 引擎事件进行故障排除？
Amazon Web Services 文档中描述的 Amazon Web Services 服务或功能可能因区域而异。要查看适用于中国区域的差异，请参阅 中国的 Amazon Web Services 服务入门 (PDF)。

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

亚马逊 Well-A ElastiCache rchitected 镜头卓越运营支柱

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

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

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

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

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

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

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

OE 3：如何管理集 ElastiCache 群资源和维护集群 up-to-date？

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

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

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

    [资源]：

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

    [资源]：

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

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

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

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

    [资源]：

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

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

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

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

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

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

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

    • 通过管道传输，可以减少应用程序客户端和集群之间的往返时间（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 OSS 引擎事件进行故障排除？

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

问题级别的好处：在 Ama ElastiCache zon 上为 Redis OSS 集群启用 Redis OSS 引擎日志可以深入了解影响集群运行状况和性能的事件。Redis OSS 引擎日志直接提供来自 Redis OSS 引擎的数据，这些数据无法通过 ElastiCache 事件机制获得。通过仔细观察 ElastiCache 事件（参见前面的 OE-1）和 Redis OSS 引擎日志，可以从ElastiCache 服务角度和 Redis OSS 引擎的角度确定故障排除时的事件顺序。

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

    • 确定亚马逊 CloudWatch 日志还是亚马逊 Kinesis Data Firehose 是 Redis OSS 引擎日志的合适目标。

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

    [资源]：

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

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

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

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