关于ml:重装上阵Graviton2提升ElastiCache-for-Redis的性价比

1. 前言

从2020年10月开始，基于亚马孙云科技 Graviton2 的缓存实例逐渐推出，客户能够在应用 Amazon ElastiCache for Redis上应用这些实例。

Graviton2 处理器由 Amazon Web Services 应用 64 位 ARM Neoverse 内核定制，对第一代亚马逊云科技 Graviton 处理器进行了多种性能优化。这包含 7 倍的性能、4 倍的计算外围数量、每个内核 2 倍的公有内存、5 倍的内存速度和每个外围 2 倍的浮点性能。此外，Graviton2 处理器还具备全天候运行的全加密 DDR4 内存性能，且每核加密性能进步 50%。这些性能晋升使得配备了Graviton2 的实例成为缓存工作负载的上佳之选。

本文将向您展现Graviton2 R6g 缓存实例（测试实例类型cache.r6g，后续简称r6g或R6g）对R5缓存实例（cache.r5，后续简称r5或R5）的性能加强以及迁徙到Graviton2 R6g 缓存实例的办法流程。

通过测试咱们能够分明地看到，无论是何种工作负载和并发条件，R6g实例比之等同资源配置的R5实例性能均有显著的晋升，而且每小时单价却有降落，在这双重因素的叠加之下，抉择新一代的r6g实例，具备更好的性能和性价比。

2. 环境筹备

2.1 环境信息 

测试客户端（新加坡区域，AZ3）

表格：测试客户端配置

测试服务端（新加坡区域，主用在AZ3）

表格：测试服务端配置

ElastiCache for Redis抉择默认参数，开启了集群模式（Cluster），数据用3个分片（每个分片1主2从，共计9个节点，为了零碎的高可用和治理须要，默认参数会设置25%的内存作为预留内存，所以读者在本人做性能测试时要注意别把内存耗光导致后果失真，这也是咱们没有抉择最低配置的实例做测试的起因之一）。

部署结束后的集群地址：

表格：测试的集群终端节点

咱们把测试客户端和集群的主节点人工强行放到了同一个AZ以获取更间接的比照成果，同时选用的ElastiCache for Redis集群实例（3*3的2xlarge构建的集群）和测试客户端（8xlarge的EC2）均反对10G的带宽模式，读者在本人做测试时也要防止因网络带宽有余导致的测试后果失真。

可能很多读者会问，为什么测试的时候只抉择这一个机型？仔细的读者可能会发现，亚马逊云的机型是有肯定法则的，例如4xlarge的配置刚好是2xlarge的两倍，而8xlarge的又刚好是4xlarge的两倍（以此类推，具体机型定义请参看网页链接：
https://docs.aws.amazon.com/z...）

所以此处咱们用r5.2xlarge和r6g.2xlarge做个具备代表性的比照测试，就不必其余机型一一比照了。

2.2压测工具

此处咱们应用两个不同的压测工具做针对性测试，一个是Redis自带的简略易用的redis-benchmark，一个是Redis Labs开源提供的在更高并发的场景应用的memtier_benchmark。

2.2.1 redis-benchmark

redis-benchmark默认含在redis的散发外面，间接装置redis即可取得，在Amazon Linux 2操作系统上应用如下命令即可（这个装置在客户端上，后续迁徙的时候也会用到这个客户端源）。

amazon-linux-extras install redis4.0 -y

其命令的罕用参数选项如下：

表格：redis-benchmark的罕用参数

2.2.2 memtier_benchmark

memtier_benchmark须要应用github上的源码进行编译能力应用，在Amazon Linux 2操作系统上能够应用如下形式：

yum install gcc git autoconf automake gcc-c++openssl-devel libevent-devel -ymkdir /opt/memtier_benchmarkcd /opt/memtier_benchmarkgit clone https://github.com/RedisLabs/memtier_benchmark.gitcd memtier_benchmarkautoreconf -ivf./configuremake && make install

其命令的罕用参数选项如下：

表格：memtier_benchmark的罕用参数

3. 测试过程

3.1 只读测试

留神：只读测试，咱们只演示测试redis-benchmark工具。

测试R5.2xlarge机型的只读测试命令如下（压测200万次，并发1000，随机key和value，大小1k，不应用管道）

1redis-benchmark -n 2000000 -c 1000 -t get -d 1024 -p 6379 -h r5-2xlarge-elasticache-for-redis-cluster-endpoint --csv

测试R6g.2xlarge机型的只读测试命令如下（压测200万次，并发1000，随机key和value，大小1k，不应用管道）

1redis-benchmark -n 2000000 -c 1000 -t get -d 1024 -p 6379 -h r6g-2xlarge-elasticache-for-redis-cluster-endpoint --csv

后果如下（此处截图仅供参考，不参加前面的性能统计）:

图例：对实例进行只读测试

3.2只写测试

留神：只写测试，咱们只演示测试redis-benchmark工具。

测试R5.2xlarge机型的只写测试命令如下（压测200万次，并发1000，随机key和value，大小1k，不应用管道）

1redis-benchmark -n 2000000 -c 1000 -t set,hset -d 1024 -p 6379 -h r5-2xlarge-elasticache-for-redis-cluster-endpoint --csv

测试R6g.2xlarge机型的只写测试命令如下（压测200万次，并发1000，随机key和value，大小1k，不应用管道）

1redis-benchmark -n 2000000 -c 1000 -t set,hset -d 1024 -p 6379 -h r6g-2xlarge-elasticache-for-redis-cluster-endpoint --csv

后果如下（此处截图仅供参考，不参加前面的性能统计）：

图例：对实例进行只写测试

3.3混合测试

3.3.1通过redis-benchmark测试

此处咱们设定四个场景，别离是如下两种并发和键值（key/value）大小的组合：
500并发，1k大小和4k大小；
1000并发，1k大小和4k大小；

如下为对应的测试命令（包含罕用的命令SET和GET，以及在理论业务中比拟罕用的HSET）。

测试场景1-1：500并发，1k大小，200万次申请

1redis-benchmark -n 2000000 -c 500 -t set,get,hset -d 1024 -p 6379 -h r5-2xlarge-elasticache-for-redis-cluster-endpoint --csv

和

1redis-benchmark -n 2000000 -c 500 -t set,get,hset -d 1024 -p 6379 -h r6g-2xlarge-elasticache-for-redis-cluster-endpoint --csv

测试场景1-2：500并发，4k大小，200万次申请

1redis-benchmark -n 2000000 -c 500 -t set,get,hset -d 4096 -p 6379 -h r5-2xlarge-elasticache-for-redis-cluster-endpoint --csv

和

1redis-benchmark -n 2000000 -c 500 -t set,get,hset -d 4096 -p 6379 -h r6g-2xlarge-elasticache-for-redis-cluster-endpoint --csv

测试场景1-3：1000并发，1k大小，200万次申请

1redis-benchmark -n 2000000 -c 1000 -t set,get,hset -d 1024 -p 6379 -h r5-2xlarge-elasticache-for-redis-cluster-endpoint --csv

和

1redis-benchmark -n 2000000 -c 1000 -t set,get,hset -d 1024 -p 6379 -h r6g-2xlarge-elasticache-for-redis-cluster-endpoint --csv

测试场景1-4：1000并发，4k大小，200万次申请

1redis-benchmark -n 2000000 -c 1000 -t set,get,hset -d 4096 -p 6379 -h r5-2xlarge-elasticache-for-redis-cluster-endpoint --csv

和

1redis-benchmark -n 2000000 -c 1000 -t set,get,hset -d 4096 -p 6379 -h r6g-2xlarge-elasticache-for-redis-cluster-endpoint --csv

每种场景测试5次以上，而后取如下图所示的SET、GET和HSET的值并计算均值作为后果（因为redis-benchmark的单过程个性，在并发和模仿理论客户端场景层面难以齐全笼罩，咱们测试发现申请数在约10万/秒左右即达到下限，即便批改并发和数据大小也无奈冲破，所以这部分留给读者本人去做操作和测试验证，本文测试数据收集不思考此工具，避免数据呈现偏差）。

图例：对实例进行混合测试（SET/GET/HSET）

3.3.2通过memtier_benchmark测试

此处咱们同样设定四个场景，为如下条件的组合：

• 随机测试：别离测试500和1000并发，键值1k到4k大小随机，测试工夫180秒，SET和GET的比例为1：4；
• 正态分布（高斯分布）测试：别离测试500和1000并发，键值1k到4k大小随机，测试工夫180秒，SET和GET的比例为1：4；

咱们没有设置更高的并发或更大的键值测试，因为在测试的过程中，咱们发现零碎运行比较稳定，调高并发或键值会导致本文的测试客户端m5.8xlarge的带宽使用率间接打满10G（如果要测试集群的极限，倡议采纳多客户端的分布式测试形式，本文暂不波及），咱们的测试命令只包含SET和GET，且为了更好的模仿理论生产环境中的读写比例，所以此处读写比例设置为1：4（模仿20%写）。

测试场景2-1：随机测试，500并发，键值1k-4k随机大小，测试工夫180秒，SET和GET比例为1：4

1memtier_benchmark -R --data-size-range=1024-4096 --data-size-pattern=S --test-time 180 -t 10 -c 50 --cluster-mode --ratio=1:4 -p 6379 -s r5-2xlarge-elasticache-for-redis-cluster-endpoint

和

1memtier_benchmark -R --data-size-range=1024-4096 --data-size-pattern=S --test-time 180 -t 10 -c 50 --cluster-mode --ratio=1:4 -p 6379 -s r6g-2xlarge-elasticache-for-redis-cluster-endpoint

测试场景2-2：随机测试，1000并发，键值1k-4k随机大小，测试工夫180秒，SET和GET比例为1：4

1memtier_benchmark -R --data-size-range=1024-4096 --data-size-pattern=S --test-time 180 -t 20 -c 50 --cluster-mode --ratio=1:4 -p 6379 -s r5-2xlarge-elasticache-for-redis-cluster-endpoint

和

1memtier_benchmark -R --data-size-range=1024-4096 --data-size-pattern=S --test-time 180 -t 20 -c 50 --cluster-mode --ratio=1:4 -p 6379 -s r6g-2xlarge-elasticache-for-redis-cluster-endpoint

测试场景2-3：正态分布（高斯分布）测试，500并发，键值1k-4k随机大小，测试工夫180秒，SET和GET比例为1：4 

1memtier_benchmark -R --data-size-range=1024-4096 --data-size-pattern=S --test-time 180 -t 10 -c 50 --cluster-mode --key-pattern=G:G -p 6379 -s r5-2xlarge-elasticache-for-redis-cluster-endpoint

和

1memtier_benchmark -R --data-size-range=1024-4096 --data-size-pattern=S --test-time 180 -t 10 -c 50 --cluster-mode --key-pattern=G:G -p 6379 -s r6g-2xlarge-elasticache-for-redis-cluster-endpoint

测试场景2-4：正态分布（高斯分布）测试，1000并发，键值1k-4k随机大小，测试工夫180秒，SET和GET比例为1：4

1memtier_benchmark -R --data-size-range=1024-4096 --data-size-pattern=S --test-time 180 -t 20 -c 50 --cluster-mode --key-pattern=G:G -p 6379 -s r5-2xlarge-elasticache-for-redis-cluster-endpoint

和

1memtier_benchmark -R --data-size-range=1024-4096 --data-size-pattern=S --test-time 180 -t 20 -c 50 --cluster-mode --key-pattern=G:G -p 6379 -s r6g-2xlarge-elasticache-for-redis-cluster-endpoint

在测试过程中，咱们发现零碎运行十分稳固，所以每种场景测试了6次，而后取如下图所示的Sets、Gets和Waits的p99均值（其中1000并发咱们没有取p99的均值，而是取了总体的均值，因为咱们发现在R5机型的集群中，1000并发的状况下，p99均值的稳定和方差太大，而R6g的机型没有这个问题，为了不便比照，就没有取并发1000的延时p99均值）。

图例：对实例进行混合测试（本文测试数据集来自此测试模式）

3.4监控

在测试的过程中，咱们能够在CloudWatch控制台查看ElastiCache的Cluster端的对应数据，相似如下（次要避免因为资源耗尽的起因导致后果异样，如CPU，带宽等）：

图例：CloudWatch的监控数据

在测试客户端，每一次应用memtier_benchmark测试都会输入对应的网络流量，记得别超过实例的最高值即可，否则请应用多个实例的分布式并发测试（例如想压测出ElastiCache for Redis的集群的性能极限）或者应用更高规格的实例（对应网络带宽会更大）。

4. 比照剖析

针对之前的混合读写测试场景，咱们针对memtier_benchmark工具的4个不同场景各做了6轮测试（每次从新开始测试前应用“flushdb/flushall”清理集群中的3个主分片，咱们发现测试的后果十分的靠近，示意服务器端运行稳固），获取到的原始数据如下：

表格：测试获取到的原始数据

4.1性能比照

留神：在计算比例时，以后果优的为基数（分母）。

4.1.1写入性能比照

在场景2-1中，r6g比照r5，其SET的每秒申请数晋升了40%；
在场景2-2中，r6g比照r5，其SET的每秒申请数晋升了37%；
在场景2-3中，r6g比照r5，其SET的每秒申请数晋升了37%；
在场景2-4中，r6g比照r5，其SET的每秒申请数晋升了34%。

比照后果如下图所示（数值越大越好）：

图例：SET写入场景性能比照0

4.1.2读取性能比照

在场景2-1中，r6g比照r5，其GET的每秒申请数晋升了40%；
在场景2-2中，r6g比照r5，其GET的每秒申请数晋升了37%；
在场景2-3中，r6g比照r5，其GET的每秒申请数晋升了37%；
在场景2-4中，r6g比照r5，其GET的每秒申请数晋升了34%。

比照后果如下图所示（数值越大越好）：

图例：GET读取场景性能比照

4.1.3响应延时比照

在场景2-1中，r6g比照r5，其p99（99%）的响应延时升高了36%；
在场景2-2中，r6g比照r5，其均匀响应延时升高了37%；
在场景2-3中，r6g比照r5，其p99（99%）的响应延时升高了50%；
在场景2-4中，r6g比照r5，其均匀响应延时升高了36%；

比照后果如下图所示（数值越小越好）：

图例：申请延时比照

4.2性价比比照

咱们从Amazon Web Services的官网列表价 查问到如下的ElastiCache for Redis实例每小时的价格（价格依据不同区域，不同工夫会有差别，此处以2021-04-29的新加坡区域为例，最新和最终价格以官网页面为准）：

Amazon Web Services也提供一个云上的老本计算器，针对上述两种机型，我给大家做了一个成本计算的例子供大家分享。

4.3论断

同样条件下的性能测试和延时，R6g机型（基于Graviton 第2代的ARM架构）均大幅当先原有基于通用CPU的R5机型。通过测试咱们能够分明地看到，无论是何种工作负载和并发条件，R6g实例比之等同资源配置的R5实例性能均有显著的晋升，而每小时单价却有降落，因此R6g实例对客户来说，有更好的性价比。

综上所述，联合性能劣势和价格优势，新公布的R6g机型将是客户在应用ElastiCache for Redis服务时的更优抉择。

留神：当您按本文步骤进行测试的时候，随着环境，测试步骤的不同，可能须要对命令参数进行微调，测试后果也会有相应变动，但测试的思路以及测试后果变动的客观规律却是共通的。

5.实例的迁徙

绝对于ElastiCache for Redis治理服务，局部客户也喜爱自建Redis平台，然而绝对平台服务而言，有如下比拟显著的毛病和难题须要解决：

• 难以治理：治理服务器配置、软件补丁、装置、配置与备份
• 难以实现高可用：须要疾速执行谬误检测与修复
• 难以扩大：在线扩大可能引发谬误，且须要监控正本性能
• 老本昂扬：人员、流程、硬件与软件须要占用大量资金

除了后面章节比照测试的性能和延时，以及老本劣势外，应用ElastiCache for Redis的治理服务还有如下劣势能够让客户间接开箱即用:

• 极致性能：提供小于1ms的响应工夫；以后最大反对500个节点，340TB存储的最大Redis集群；最大反对3250万连接数，满足极致场景的巅峰性能；
• 全托管：Amazon Web Services治理所有的硬件以及软件的配置和监控；
• 易伸缩：通过正本提供读操作的弹性伸缩，通过分片提供写操作非中断的弹性伸缩；反对横向和纵向的弹性伸缩；
• 可靠性保障：多可用区（免跨AZ流量费）反对，深度和具体的监控和告警，主动故障转移（10-20s内实现Fail Over）；
• 平安和合规：通过Amazon VPC实现网络隔离和治理，合乎HIPAA，PCI和FedRAMP等平安和合规要求，存储和传输中反对进行加密和身份认证；
• 兼容性：兼容多个Redis版本和客户端，反对导入导出，反对快照和复原等；

5.1纯手工迁徙

比拟传统的形式是把运行在EC2（或者容器）外面的Redis数据做个备份导出（通过在reids-cli中应用阻塞式的save命令或者后盾形式的bgsave命令），而后把导出文件存到S3（以后只反对从S3导入），而后在ElastiCache控制台创立集群时抉择导入位于S3的备份文件，在这种操作形式下，如果源还在持续应用可能会导致两边的数据不齐全同步，如果源不操作等新集群可用户再切换的话，则会有肯定的服务中断工夫。

具体操作见从备份还原的指引文档 ，本文不做额定的演示和阐明。

5.2应用redis-migration-tool进行迁徙

Redis-migration-tool是github上开源的一个Redis迁徙工具，应用它能够在不同的Redis环境（如单机，集群等）实现同步和复制。

在Amazon Linux 2操作系统上能够应用如下形式应用redis-migration-tool：

1mkdir /opt/redis-migration-tool && cd /opt/redis-migration-tool23git clone https://github.com/vipshop/redis-migrate-tool.git

因为这个工具有段时间没更新了，咱们应用的是比拟新的Redis 6.0.5版本，所以须要批改一下源码中对于RDB文件版本的定义。

批改“/opt/redis-migration-tool/redis-migrate-tool/src/rmt_redis.c”，把原来的“#define REDIS_RDB_VERSION 7”批改成“#define REDIS_RDB_VERSION 10”，而后再编译：

1cd /opt/redis-migration-tool/redis-migrate-tool23autoreconf -fvi45./configure67make891011#编译好的文件位于src/redis-migrate-tool

接着编辑对应的配置文件“/opt/redis-migration-tool/redis-migrate-tool/rmt.conf”，内容如下（记得批改对应的集群endpoint）：

1[source]23type: single45servers :67- 127.0.0.1:6379891011[target]1213type: redis cluster1415servers:1617- r6g-2xlarge-elasticache-for-redis-cluster-endpoint:637918192021[common]2223listen: 0.0.0.0:8888

同时，咱们此处应用之前的测试机（那个m5.8xlarge的EC2）的机器当做源，而后通过脚本往里面压数据，命令如下（模仿一个并发，一个客户端，继续180秒的写入随机数据）：

1memtier_benchmark -R --data-size-range=1024-4096 --data-size-pattern=S --test-time 180 -t 1 -c 1 -p 6379 -s 127.0.0.1

5.2.1筹备

原来在筹备redis-benchmark工具的时候曾经装置了redis服务，此处咱们把服务启动，并确认数据内容，同时手工写入一个key做测试，如下：

1systemctl enable redis23systemctl start redis4567redis-cli89# keys *10# set owner "WeiqiongChen"

源如下所示（没有其余数据，只有咱们手工写入的key）：

图例：筹备位于EC2的源Redis（单机版）

指标如下所示（没有其余数据，也没有咱们手工写入的key，因为还没开始同步）：

图例：清理指标ElastiCache for Redis集群环境

5.2.1迁徙和同步

在源通过如下命令开始生成数据

1memtier_benchmark -R --data-size-range=1024-4096 --data-size-pattern=S --test-time 180 -t 1 -c 1 -p 6379 -s 127.0.0.1

如下：

图例：启动源

而后再启动同步（特意晚启动同步模仿客户实在的迁徙场景）

1cd /opt/redis-migration-tool/redis-migrate-tool23./src/redis-migrate-tool -c ./rmt.conf -o log &

如下所示：

图例：启动源到目标的同步

5.2.1验证

咱们统计源注入的数据量，如下（此处为473563个key）：

图例：查看源的数据量

比照查看指标库同步的数据量（因为指标卡集群分成三个片了，所以要统计三个分片的总数），如下（此处合并总数仍然是473563个key）：

图例：查看指标的数据量

留神：读者们能够在源多做几轮测试，验证同步后果是否合乎预期（如果没有数据同步或者有异样，能够查看redis-migration-tool目录的log文件查看异样信息）。

扩大浏览

《Amazon ElastiCache用户指南》：
https://docs.aws.amazon.com/z...

《Amazon ElastiCache 最佳实际》：
https://docs.aws.amazon.com/z...

《应用CloudWatch监控Amazon ElastiCache 的最佳实际》：
https://aws.amazon.com/cn/blo...

《五个用来评估Amazon ElastiCache容量的工作负载指标》：
https://aws.amazon.com/cn/blo...

memtier_benchmark：
https://github.com/RedisLabs/...

官网列表价：
https://aws.amazon.com/cn/ela...

成本计算例子：
https://calculator.aws/#/esti...

本篇作者

陈卫琼
亚马逊云科技资深解决方案架构师
负责帮助客户业务零碎上云的解决方案架构设计和征询，现致力于大数据和IoT相干畛域的钻研。