AmazonElastiCache 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サーバ」
の比較です。
検証内容その1
- clients=100, requests=10000, keyspacelen=100000, size=100bytes で計測
redis-benchmark -h <host> -c 100 -n 10000 -r 100000 -d 100 -q --csv
結果その1
- | 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 |
検証内容その2
- clients=100, requests=10000, keyspacelen=100000, size=1000bytes で計測
redis-benchmark -h <host> -c 100 -n 10000 -r 100000 -d 1000 -q --csv
結果その2
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 |
検証結果その3(Parallel::Benchmark)
ベンチマークスクリプトはこちら。
限界値を見るためにベンチマークサーバを4台に増やしています。
いずれのRedisサーバもCPU負荷は1コアのみ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で見た時にどうなるのか?というところを確認してみました。
使用しても良いメモリのMAX値は?
Redisでは使用メモリを物理メモリの半分以上使わないようにするのが基本です。
理由は、BGSAVE時にまるっとメモリを確保して保存するためです。
ElastiCacheではデフォルトAOFのようですが、
クリーンアップのため定期的にBGREWRITEAOFしているはず(?)*1です。
BGREWRITEAOFを実行する時もSAVE時と同じくメモリが確保されてしまうため
同様の問題が発生するはず。。。
今回こちらの検証は行っていませんが、
物理メモリの半分以上を使うような要件だと危険なのではないかな、
と思っています。がこの辺り実際どうなんでしょうか。。
まとめ
ElastiCache Redisの一番良い点は
なんといってもフェイルオーバーだと思っています。
これを使うためだけにElastiCacheを選択するのもアリかなと。
さらに、性能も予想に反して生EC2より良いという結果でした。
ただし、シングルスレッドのためマルチコアの利点を活かせないのが一番痛いところ。
今自分がプロダクトで動かしているRedisサーバは
フルコア活用するようにコア数分Redis立てて運用しているのですが、
ElastiCache Redisではそういった運用が出来ません。
そのためコスト的には少し無駄が発生してしまいます。
メモリと相談だとは思いますが、
コア数少なめのサーバを並べるのがコスパ的にはよさそうですね。
m2.xlargeが使いやすそうかなー。
とりあえず、性能的にも問題無さそうですし
もう少し検証してプロダクト環境でもどしどし使っていきたいと思います!!!
*1:未確認