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のスナップショット作成時間は相当長い。