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

从 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 实例，具备更好的性能和性价比。

测试客户端（新加坡区域，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 做个具备代表性的比照测试，就不必其余机型一一比照了。

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

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

amazon-linux-extras install redis4.0 -y

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

表格：redis-benchmark 的罕用参数

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

yum install gcc git autoconf automake gcc-c++openssl-devel libevent-devel -y



mkdir /opt/memtier_benchmark

cd /opt/memtier_benchmark



git clone https://github.com/RedisLabs/memtier_benchmark.git



cd memtier_benchmark

autoreconf -ivf



./configure

make && make install

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

表格：memtier_benchmark 的罕用参数

留神：只读测试，咱们只演示测试 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

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

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

留神：只写测试，咱们只演示测试 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

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

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

此处咱们设定四个场景，别离是如下两种并发和键值（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）

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

随机测试：别离测试 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 均值）。

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

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

图例：CloudWatch 的监控数据

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

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

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

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

在场景 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

在场景 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 读取场景性能比照

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

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

图例：申请延时比照

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

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

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

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

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

绝对于 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 版本和客户端，反对导入导出，反对快照和复原等；

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

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

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

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

1mkdir /opt/redis-migration-tool && cd /opt/redis-migration-tool
2
3git 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-tool
2
3autoreconf -fvi
4
5./configure
6
7make
8
9
10
11# 编译好的文件位于 src/redis-migrate-tool

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

1
2
3type: single
4
5servers :
6
7- 127.0.0.1:6379
8
9
10
11[target]
12
13type: redis cluster
14
15servers:
16
17- r6g-2xlarge-elasticache-for-redis-cluster-endpoint:6379
18
19
20
21[common]
22
23listen: 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

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

1systemctl enable redis
2
3systemctl start redis
4
5
6
7redis-cli
8
9# keys *
10# set owner "WeiqiongChen"

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

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

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

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

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

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-tool
2
3./src/redis-migrate-tool -c ./rmt.conf -o log &

如下所示：

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

咱们统计源注入的数据量，如下（此处为 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 相干畛域的钻研。

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

1. 前言

2. 环境筹备

2.1 环境信息

2.2 压测工具

2.2.1 redis-benchmark

2.2.2 memtier_benchmark

3. 测试过程

3.1 只读测试

3.2 只写测试

3.3 混合测试

3.3.1 通过 redis-benchmark 测试

3.3.2 通过 memtier_benchmark 测试

3.4 监控

4. 比照剖析

4.1 性能比照

4.1.1 写入性能比照

4.1.2 读取性能比照

4.1.3 响应延时比照

4.2 性价比比照

4.3 论断

5. 实例的迁徙

5.1 纯手工迁徙

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

5.2.1 筹备

5.2.1 迁徙和同步

5.2.1 验证

扩大浏览