Graviton 2 搭載のElastiCacheを試してみる

この記事はWanoグループ Advent Calendar 2020の10日目の記事になります。

ElastiCacheがr6g、m6g推しになった

今年10月から、ElastiCacheのデフォルトのインスタンスタイプがr6g、m6gのGraviton 2採用インスタンスになりました。

AWSは価格性能比の良さをアピールしていますが、実際どんなもんでしょうか。

料金

第六世代インスタンスの方がだいたい5%程度安いです。

コア数、メモリ容量はインスタンスのサイズが同じであれば据え置き。
ネットワーク帯域幅は12xlargeより下は最大10ギガビットで変わらず。
12xlargeは10ギガビット -> 20ギガビット。

インスタンスタイプ(5)	料金	インスタンスタイプ(6)	料金
m5.large	0.201USD	m6g.large	0.191USD
m5.xlarge	0.402USD	m6g.xlarge	0.382USD
m5.2xlarge	0.804USD	m6g.2xlarge	0.764USD
m5.4xlarge	1.607USD	m6g.4xlarge	1.528USD
m5.12xlarge	4.821USD	m6g.12xlarge	4.583USD
r5.large	0.259USD	r6g.large	0.247USD
r5.xlarge	0.517USD	r6g.xlarge	0.493USD
r5.2xlarge	1.035USD	r6g.2xlarge	0.985USD
r5.4xlarge	2.069USD	r6g.4xlarge	1.969USD
r5.12xlarge	6.207USD	r6g.12xlarge	5.906USD

※比較のため後継になるインスタンスのみ記述しています。
第五世代の24xlarge、第六世代の8xlarge、16xlargeは世代間で対になるインスタンスなし。

Redisのベンチマーク

Graviton 2はマルチコアであれば高いパフォーマンスを発揮するものの、シングルコアの性能はいまひとつという情報もあります。そうなるとシングルコアの性能がものを言うRedisのパフォーマンスが気になるところです。

出来るだけネットワークの影響が出ないよう、同じAZに配置したEC2インスタンスから redis-benchmark を叩いてみます。

Redisの性質上、インスタンスのコア数はパフォーマンスにほとんど影響ありません。
ElastiCache上で普通にRedisを使う分には、インスタンスサイズはメモリ容量とネットワーク性能の違いだけだと思っても問題ないでしょう。（実際にいくつか試したところ、誤差程度の差しか出ませんでした）

したがって、largeサイズのインスタンスのみを対象にベンチマークを実施します。

500,000リクエスト、パイプライン数10

m5.large

redis-benchmark -h xxxx -n 500000 -r 10000 -P 10 -q
PING_INLINE: 529661.00 requests per second
PING_BULK: 397140.59 requests per second
SET: 395256.91 requests per second
GET: 383141.78 requests per second
INCR: 374812.59 requests per second
LPUSH: 393391.03 requests per second
RPUSH: 394944.69 requests per second
LPOP: 391542.69 requests per second
RPOP: 396510.69 requests per second
SADD: 383435.56 requests per second
HSET: 121921.48 requests per second
SPOP: 346500.34 requests per second
LPUSH (needed to benchmark LRANGE): 378787.88 requests per second
LRANGE_100 (first 100 elements): 109962.62 requests per second
LRANGE_300 (first 300 elements): 29265.44 requests per second
LRANGE_500 (first 450 elements): 19213.03 requests per second
LRANGE_600 (first 600 elements): 14205.35 requests per second
MSET (10 keys): 173190.16 requests per second

m6g.large

[ec2-user@ip-10-2-1-13 ~]$ redis-benchmark -h xxxx -n 500000 -r 10000 -P 10 -q
PING_INLINE: 530785.56 requests per second
PING_BULK: 391542.69 requests per second
SET: 390320.06 requests per second
GET: 403877.22 requests per second
INCR: 396825.41 requests per second
LPUSH: 394321.75 requests per second
RPUSH: 402576.50 requests per second
LPOP: 385505.00 requests per second
RPOP: 384024.56 requests per second
SADD: 351370.34 requests per second
HSET: 267094.03 requests per second
SPOP: 358166.19 requests per second
LPUSH (needed to benchmark LRANGE): 361010.84 requests per second
LRANGE_100 (first 100 elements): 96024.59 requests per second
LRANGE_300 (first 300 elements): 28664.79 requests per second
LRANGE_500 (first 450 elements): 18127.11 requests per second
LRANGE_600 (first 600 elements): 13243.63 requests per second
MSET (10 keys): 175131.34 requests per second

ほとんど誤差ですね。
強いて言えば、m6g.largeはLRANGEの速度でやや劣る印象があります。

1,000,000リクエスト、パイプライン数30

m5.large

redis-benchmark -h xxxx -n 1000000 -r 10000 -P 30 -q
PING_INLINE: 1129943.50 requests per second
PING_BULK: 1136363.62 requests per second
SET: 953288.81 requests per second
GET: 1112347.12 requests per second
INCR: 969932.06 requests per second
LPUSH: 911577.00 requests per second
RPUSH: 946073.75 requests per second
LPOP: 925069.38 requests per second
RPOP: 1029866.12 requests per second
SADD: 919117.62 requests per second
HSET: 156176.80 requests per second
SPOP: 1116071.38 requests per second
LPUSH (needed to benchmark LRANGE): 911577.00 requests per second
LRANGE_100 (first 100 elements): 95520.11 requests per second
LRANGE_300 (first 300 elements): 27421.30 requests per second
LRANGE_500 (first 450 elements): 17628.60 requests per second
LRANGE_600 (first 600 elements): 12986.84 requests per second
MSET (10 keys): 198609.73 requests per second

m6g.large

redis-benchmark -h xxxx -n 1000000 -r 10000 -P 30 -q
PING_INLINE: 1107419.75 requests per second
PING_BULK: 1152073.75 requests per second
SET: 920810.31 requests per second
GET: 917431.19 requests per second
INCR: 913242.00 requests per second
LPUSH: 809716.56 requests per second
RPUSH: 935453.69 requests per second
LPOP: 831946.75 requests per second
RPOP: 956022.94 requests per second
SADD: 1025641.00 requests per second
HSET: 133067.20 requests per second
SPOP: 1194743.12 requests per second
LPUSH (needed to benchmark LRANGE): 818330.62 requests per second
LRANGE_100 (first 100 elements): 88004.93 requests per second
LRANGE_300 (first 300 elements): 25270.39 requests per second
LRANGE_500 (first 450 elements): 15782.58 requests per second
LRANGE_600 (first 600 elements): 11760.28 requests per second
MSET (10 keys): 181093.81 requests per second

リクエスト数とパイプを増やす事で、よりCPUに負荷がかかる状態です。
微妙にm6g.largeが遅い傾向があるものの、普通に使って差がでるようなレベルではなさそうです。

多少は回線状態など外部の影響を受けるので何度か試しましたが、傾向は変わりませんでした。

まとめ

第五世代と第六世代、今回のベンチマークでは概ね同等の性能という結果になりました。
前述の通り、ElastiCacheで使う分にはCPUのアーキテクチャの違いを気にする必要もないため、単純にお得な選択肢が増えたと考えて良さそうです。