在规划 Amazon ElastiCache Redis 集群大小时，需要考量的五种工作负载特性

Original URL：https://aws.amazon.com/cn/blogs/database/five-workload-characteristics-to-consider-when-right-sizing-amazon-elasticache-redis-clusters/

本文将探讨如何为Amazon ElastiCache工作负载确定正确的节点大小与集群拓扑结构，以及在此期间需要考量的因素。本文内容涉及Redis及其操作命令，同时也要求您对于Amazon ElastiCache for Redis及其功能（例如在线集群大小调整、扩展、从Amazon EC2到ElastiCache的在线迁移、通用型与内存优化型节点以及增强I/O等内容）具备一定的了解。

基准配置建议

对于入门级、小型（TPS在2000及以下，数据规模在10 GB及以下水平）以及中型（TPS在2000到20000之间，数据规模在10 GB到100 GB之间）的缓存工作负载，包括某些可能出现临时需求峰值的工作负载，我们建议大家从T3家族（即具备突发峰值支持能力的T3-Standard缓存节点的下一代通用型解决方案）当中选择缓存节点。如果您刚刚开始使用ElastiCache处理工作负载，则最好从T3.micro缓存节点起步，借此享受免费层服务。随着负载容量的增加，您可以逐步提升至T3.medium等其他缓存节点类型。

对于中型到大型（TPS超过20000，数据规模超过100 GB）工作负载，我们建议您从M5或者R5家族当中选择缓存节点，这种最新节点类型支持最新一代CPU与网络功能，可配合弹性网络适配器（ENA）提供高达25 Gbps的综合网络传输带宽以及超过600 GiB的内存容量。与R4节点类型相比，R5节点类型能够为每个vCPU提供额外5%的内存容量，且每GiB使用成本比R4节点类型降低10%。此外，与R4节点类型相比，R5节点类型的CPU性能平均提升约20%。

如果T3.medium节点无法继续满足需求，大家也可以选择以下几种节点选项：

• M5缓存节点，适用于需要增加内存容量以提升数据吞吐量的用例。
• R5缓存节点，适用于数据吞吐量需求更高的用例，其中每缓存节点内存容量将提升35%至51%。

为了进一步确定合适工作负载需求的节点大小与集群拓扑，大家也可以通过以下操作确定实际需求：

• 确定工作负载中的五项基本特性。
• 运行基准性能测试。

确定工作负载中的五项基本特性

大家可以使用应用程序指标、Redis中的INFO命令或者Amazon CloudWatch指标以确定工作负载中的大部分特性。关于最大节点内存选择的更多详细信息，请参阅Redis节点类型相关参数说明。

在确定ElasctiCache节点需求时，请关注以下核心指标：

• 内存
• 备用或预留内存
• 可用性
• 弹性伸缩性
• 数据

内存

在初步确定节点内存大小时，我们可以从以下几点入手：

• 确定完整的数据存储大小、键以及值大小。您可以将需要缓存的条目大小乘以同一时间内需要保留缓存的条目数，即可粗略估算了所需的缓存容量。
• 确定您打算保留的数据，或者使用TTL为缓存内的键设置过期机制。TTL能够在节点上建立起显式内存管理机制。
• 对于当前最为重要的指标（例如在纯缓存用例中），请为其确定现有及预期的缓存命中率。我们必须保证集群的缓存命中率符合预期，或者保证不会频繁清退低命中率键。您可以通过增加内存容量的方式实现这项目标。

备用或预留内存

除了能够容纳数据库之外，我们还至少应该为节点保留25%的内存容量。针对主节点执行的复制操作或多或少会占用一部分内存。另外，缓存节点还应保留10%到15%的备用内存，用于应对意外出现的负载峰值；同时配合CloudWatch警报功能进行早期检测，以提前增加内存容量。我们可以将早期检测与实际需求结合起来，判断选择纵向扩展或者横向扩展方案。

写入操作较为密集的应用程序也有可能占用大量内存空间。在保存快照或者对另一副本进行故障转移时，都需要使用这部分备用内存资源。

可用性

如果需要建立集群以满足客户的要求，不妨考虑设置一套包含一个主副本、至少两个辅助副本并启用多可用区复制机制的副本组。这不仅能够提高数据保护能力，也可在主数据库发生意外故障时，保证集群继续提供服务。一旦出现故障，原本的辅助副本将被提升为新的主副本。多副本体系还有助于提高读取吞吐量。

对于写入密集型的主节点，请注意将其写入和读取率设定于50%到80%之间。如果主节点写入密度过高，可能会提高主副本与辅助副本之间的同步频率，进而影响集群整体的性能。过分频繁的同步操作会占用大量主节点的资源，挤占处理资源并导致传入请求的时长增加。

另外，避免单纯为了追求可用性而启动过多的副本；这会给主数据库造成不必要的压力，迫使其与多个副本执行同步。每个主节点所对应的辅助副本应被限制在不超过五个。我们可以在其他可用区内额外建立一到两个副本以保障可用性。

规模弹性伸缩性

ElastiCache提供的配置模板中包含集群模式，支持在线进行纵向与横向弹性伸缩，且在此期间集群将继续对外提供服务。如果您在主节点上同时使用多个客户端（TPS可能超过10000，即10000个客户端各1 TPS或者2000个客户端各5 TPS），则最好选择横向扩展以保证您拥有充足的计算能力为所有节点提供服务。每个主节点的最佳并发客户端数量，取决于您的实际用例与整体应用程序架构。除了为大量并发客户端提供服务之外，横向扩展还能保证将数据分散在多个分片当中，从而进一步提高集群中数据的可用性。但如果您的业务需要在现有集群配置上获得更高的性能，则应选择纵向弹性扩展。纵向扩展的本质，在于提高单一节点的性能水平。

利用源集群中的.rdb文件，我们还可以使用备份/还原操作实现两种集群配置（禁用集群模式与启用集群模式）之间的迁移。因此，请在配置中默认启用集群模式，灵活通过纵向与横向规模伸缩满足后续可能出现的不同需求。

如果要下调集群大小与内存容量（降低配置或减少节点数量），请保证新的配置方案仍有充足的内存以容纳数据及Redis运行需求。

数据

确定您的工作负载当中是否存在热键，即请求率极高或者请求率有可能快速增长的一个或多个数据对象。热键的存在，可能对您的缓存引擎性能及请求处理能力造成影响。对于此类情况，建议大家在配置中启用集群模式以将工作负载分散至各多个分片之上，保证将热键保留在特定分片中，而其余键将保留在其他分片中，借此实现传入请求分流。如果存在多个热键，可以考虑将其分散在多个分片中。

另外，大家也可以考虑读写分离。拆分读取和写入之后，我们可以通过独立添加更多副本扩展读取能力。而各副本将保证读取操作的最终一致性。ElastiCache为禁用集群模式的配置提供副本终端，用于对副本上的读取流量执行负载均衡，借此实现读写分离。另外，也有部分启用集群模式的Redis客户端允许将流量路由至各副本。关于更多详细信息，请参阅各Redis客户端对应的说明文档。

运行基准性能测试

在确定了适用当前需求的参数之后，大家还需要选择最适合的缓存节点与集群拓扑。使用两个large缓存节点在性能方面是否一定优于单一xlarge缓存节点，有时候测试结截然相反。我们需要在生产环境中根据工作负载特性进行客户端应用程序配置，并运行基准性能测试。在基准测试当中应使用与生产场景一致的数据与流量模式，且运行周期不少于14天，以获取良好的基准测试结果。在获得初始基准测试结果之后，即可在工作负载测试当中引入节假日以及双十一等周期性因素，进一步完善基准性能测试结果的准确度，更紧密地反映工作负载的实际运作模式。根据测试结果，我们即可为Redis工作负载选择正确的节点大小与集群配置。

ElastiCache基准测试

ElastiCache已经使用开源的基准性能测试工具rpc-perf与redis-benchmark发布了测试结果的两篇博客。第一项基准测试比较了R4与优化型R5缓存节点之间的性能差异，我们将在后文中做出具体说明。若需了解更多详细信息，请参阅使用Amazon EC2 M5与R5实例增强Amazon ELastiCache性能。第二项基准测试在R5节点家族中进行，将带有I/O增强的Redis 5.0.3版本与不提供I/O增强的Redis 5.0.0版本进行比较。关于更多详细信息，请参阅使用Amazon ElastiCache for Redis提高应用程序性能并降低成本。

R4与R5缓存节点比较

此上述两项基准测试的预设场景为1470万个唯一键、字符串值长度为200字节、80%为gets操作、20%为sets操作，且不使用命令管道。基准测试采用位于同一可用区的客户端实例。

下表所示，为基准测试中的具体设置。

基准测试结果表明，与大小类似的R4实例相比，最新的R5缓存节点每秒可多支持59%至144%的事务处理量。R5缓存节点的平均延迟（第50百分位）与尾部延迟（第99百分位）较R4节点最多降低达23%，平均延迟下探至350微秒。下表对此次测试中的数据进行了整理：

* 仅适用于ElasiCache for Redis 5.0.3及更高版本

总结

大家应定期为当前工作负载选择正确的节点大小与集群配置，包括在将工作负载迁移至ElastiCache之前。节点大小与集群配置调整绝不一劳永逸的工作，我们需要定期执行，并在大规模商业活动之前有针对性地做出调整。这不仅会帮助您的团队更好地应对流量规模变化与预期业务增长，同时也将让应用体系以无缝化方式为客户提供良好的服务体验。

如果您有任何问题或者反馈意见，请在AWS ElastiCache论坛或者下方评论区中留言。

本篇作者