ElastiCache for Redis のスナップショット機能の検証結果メモ

ElastiCache for Redisにスナップショット/リストア機能が追加されたので、
今までEC2でslave作っていた運用フローが不要になった。ありがとうAWS!!

ただ、ブログの最後を見てみると、

パフォーマンスを向上させるために、マスターキャッシュノードではなく、リードレプリカでスナップショットを取ることをお勧めします。

どうもこの文章がひっかかったので、少し検証してみた。

検証環境

検証環境としては、以下の構成で実施した。

用途	説明
対象redisインスタンス	cache.m2.xlarge(コスパはこのインスタンスタイプがよさげ)
負荷がけ用EC2	m1.small
appendonly	Yes(Cache Parameter Groupsから変更)
rdbファイルサイズ	4.7GB(バックアップしてあるrdbファイルを利用)
レプリカノード	1

Redisには、redis-benchmarkというベンチマークツールが付属しているので、
Primary Endpointに対して、EC2インスタンスから負荷がけを行ってみる(redis-benchmarkのオプションはデフォルト)

検証結果

結果は以下の通り。

検証項目	通常時	MASTERからのスナップショット作成時	READ REPLICAからのスナップショット作成時	性能劣化具合(MASTERのみ劣化:M,READ REPLICAのみ劣化:R,両方劣化×)
PING_INLINE	9515.7	9212.9	9082.0	×
PING_BULK	9496.5	9599.3	9304.8	R
SET	9700.4	9681.5	9507.4	×
GET	9397.7	8820.4	9412.5	M
INCR	9494.4	8969.4	9516.0	M
LPUSH	9446.1	8916.2	9580.6	M
LPOP	9710.1	9442.0	9128.0	×
SADD	9404.1	9043.7	8644.0	×
SPOP	9405.4	9379.3	9013.0	×
LPUSH (needed to benchmark LRANGE)	9544.2	8997.3	9329.2	×
LRANGE_100 (first 100 elements)	7065.8	6693.3	6669.9	×
LRANGE_300 (first 300 elements)	3707.7	3444.7	3531.3	×
LRANGE_500 (first 450 elements)	2810.9	2893.1	2772.0	R
LRANGE_600 (first 600 elements)	2311.7	2369.3	2216.0	R
MSET (10 keys)	9363.1	4414.2	8919.5	×

(※)単位は3回実施した時の平均requests/second

試行回数が少ない(一部性能が向上した値もある)というのもあるけど、スナップショット作成中はおおむねrequests/secondが劣化した。
特に、MSETの性能劣化がものすごく顕著に出るという結果になった。

まとめ

MSETの性能劣化具合が顕著なので、スナップショット作成時はやっぱりread replicaから実施した方が安全のような気がする。
ただ、利用するデータ量やデータ内容によっても結果は違いそうなので、利用者が実際のrdbファイルを使って確認してみるというのがよいのかなと。

その他メモ

検証で使った4.7GBのrdbファイルのスナップショット作成完了までは45分程度。
EC2上でrdbファイルを出力するのは数分程度だったので、ElastiCache for Redisのスナップショット作成時間は相当長い。