AmazonElastiCache Redisがデター！デター！

AWS Redis

ElactiCache Redisがデテター！デテター！
【AWS発表】 Amazon ElastiCacheでRedisを利用可能に!
http://aws.typepad.com/aws_japan/2013/09/amazon-elasticache-now-with-a-dash-of-redis.html


社内Redisおじさんとしては触ってみるしかないであろう、
ということでいくつか性能評価してみました。


既にcon_mameさんが評価されているようでしたので
少し違った軸でベンチマークを取ってみました。

サーバ構成

役割 インスタンスタイプ
ベンチマークサーバ c1.xlarge x 1-4
EC2 Redisサーバ m1.large x 1 or m2.2xlarge x 1
ElastiCache Redisエンジン m1.large x 1 or m2.2xlarge x 1

基本比較軸は、Redisバージョンやインスタンスタイプが同じ構成の
「EC2 Redisサーバ」と「ElastiCache Redisサーバ」
の比較です。

検証内容その１

  • clients=100, requests=10000, keyspacelen=100000, size=100bytes で計測
redis-benchmark -h <host> -c 100 -n 10000 -r 100000 -d 100 -q --csv

結果その１

- ec2 m1.large ElastiCache m1.large ec2 m2.2xlarge ElastiCache m2.2xlarge
PING_INLINE 31746.03 36496.35 34364.26 35211.27
PING_BULK 32573.29 35714.29 34129.69 35211.27
SET 31347.96 33222.59 28490.03 33222.59
GET 31152.65 32894.74 32154.34 32786.88
INCR 31250 31645.57 31847.13 33112.59
LPUSH 32573.29 34965.04 32258.06 33112.59
LPOP 33003.3 34602.07 32786.88 35211.27
SADD 32051.28 33112.59 31446.54 33670.04
SPOP 32362.46 29940.12 32573.29 35460.99
LPUSH (needed to benchmark LRANGE) 32258.06 34965.04 32786.88 33333.33
LRANGE_100 (first 100 elements) 9569.38 10683.76 9407.34 10672.36
LRANGE_300 (first 300 elements) 3424.66 3497.73 3417.63 3590.66
LRANGE_500 (first 450 elements) 2326.66 2343.57 2303.09 2400.96
LRANGE_600 (first 600 elements) 1430 1782.53 1728.91 1800.18
MSET (10 keys) 20325.2 23752.97 31250 29673.59

検証内容その２

  • clients=100, requests=10000, keyspacelen=100000, size=1000bytes で計測
redis-benchmark -h <host> -c 100 -n 10000 -r 100000 -d 1000 -q --csv

結果その２

100bytesに比べると、LRANGEとMSETがだいぶ落ちる。

- ec2 m1.large ElastiCache m1.large ec2 m2.2xlarge ElastiCache m2.2xlarge
PING_INLINE 33222.59 35335.69 33222.59 35714.29
PING_BULK 30674.85 35335.69 30674.85 34364.26
SET 30581.04 26595.75 30581.04 29940.12
GET 34602.07 33003.3 34602.07 32154.34
INCR 33898.3 33444.82 33898.3 32467.53
LPUSH 34013.61 28328.61 34013.61 31446.54
LPOP 32154.34 27855.15 32154.34 31347.96
SADD 31545.74 33783.79 31545.74 33333.33
SPOP 34722.22 36630.04 34722.22 33222.59
LPUSH (needed to benchmark LRANGE) 33112.59 27397.26 33112.59 31347.96
LRANGE_100 (first 100 elements) 1098.18 1124.99 1098.18 1158.08
LRANGE_300 (first 300 elements) 287.67 375.98 287.67 384.96
LRANGE_500 (first 450 elements) 191.61 243.06 191.61 257.21
LRANGE_600 (first 600 elements) 143.86 190.83 143.86 193.1
MSET (10 keys) 10060.36 9699.32 10060.36 9671.18

検証結果その３(Parallel::Benchmark)

ベンチマークスクリプトはこちら。
限界値を見るためにベンチマークサーバを４台に増やしています。
いずれのRedisサーバもCPU負荷は１コアのみ100%張り付き。

m1.large比較
ec2 m1.large 36497/qps
ElastiCache m1.large 43752/qps
m2.2xlarge比較
ec2 m2.2xlarge 51611/qps
ElastiCache m2.2xlarge 57311/qps

全体的な検証考察

全体的にElastiCacheの方が結果が良いですねー。
物理サーバ、通常のインスタンスより良いのを使っているんでしょうか？



ElastiCache上のCPUの様子

Redisはシングルスレッドなので、普通のインスタンスであればCPUは使いきらないはず。
CloudWatchで見た時にどうなるのか？というところを確認してみました。

m1.large(2コア)

m2.2xlarge(4コア)


予想通り、2コアのインスタンスではMAX50%、
4コアのインスタンスではMAX25%のCPU利用率でした（１コアのみ100%張り付いている状態）。
この辺り、コア数で限界値の指標が変わってくるので
監視する時など気をつけたほうが良いでしょう。

使用しても良いメモリのMAX値は？

Redisでは使用メモリを物理メモリの半分以上使わないようにするのが基本です。
理由は、BGSAVE時にまるっとメモリを確保して保存するためです。
ElastiCacheではデフォルトAOFのようですが、
クリーンアップのため定期的にBGREWRITEAOFしているはず（？）*1です。
BGREWRITEAOFを実行する時もSAVE時と同じくメモリが確保されてしまうため
同様の問題が発生するはず。。。
今回こちらの検証は行っていませんが、
物理メモリの半分以上を使うような要件だと危険なのではないかな、
と思っています。がこの辺り実際どうなんでしょうか。。

まとめ

ElastiCache Redisの一番良い点は
なんといってもフェイルオーバーだと思っています。
これを使うためだけにElastiCacheを選択するのもアリかなと。
さらに、性能も予想に反して生EC2より良いという結果でした。


ただし、シングルスレッドのためマルチコアの利点を活かせないのが一番痛いところ。
今自分がプロダクトで動かしているRedisサーバは
フルコア活用するようにコア数分Redis立てて運用しているのですが、
ElastiCache Redisではそういった運用が出来ません。
そのためコスト的には少し無駄が発生してしまいます。


メモリと相談だとは思いますが、
コア数少なめのサーバを並べるのがコスパ的にはよさそうですね。
m2.xlargeが使いやすそうかなー。


とりあえず、性能的にも問題無さそうですし
もう少し検証してプロダクト環境でもどしどし使っていきたいと思います！！！

*1:未確認