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

この記事は[Wanoグループ Advent Calendar 2020](https://qiita.com/advent-calendar/2020/wano-group "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

```shell: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
```

```shell: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

```shell: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
```

```shell: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のアーキテクチャの違いを気にする必要もないため、単純にお得な選択肢が増えたと考えて良さそうです。