Skip to content

Instantly share code, notes, and snippets.

@guitarrapc
Last active December 27, 2018 22:13
Show Gist options
  • Save guitarrapc/7304423e604264ef2302 to your computer and use it in GitHub Desktop.
Save guitarrapc/7304423e604264ef2302 to your computer and use it in GitHub Desktop.

目的

Redis on ElastiCache で、AOF無効時でどの程度性能差が発生するのかの把握

環境

サーバー 配置 Redisバージョン OS インスタンスタイプ Slave 有無
Client Private VPC内部 - Amazon Linux m2.4xlarge -
EC2 Redis Private VPC内部 Redis 2.6.12 Amazon Linux m2.4xlarge なし
ElasticCacheRedis Private VPC内部 Redis 2.6.13 ElastiCache (Amazon Linux) m2.4xlarge 1

接続

サーバー 接続先IP VPC内部接続かどうか
EC2 Redis 10.0.3.252 VPC内部での接続
ElasticCache Redis 10.0.3.234 (Node EndPoint 指定のリダイレクト) VPC 内部での接続

Redisパラメータチューニング

※メモリ読み込み量 400MB (RDB)

パラメータ ec2設定 ElastiCache設定
AOF なし なし
save "" あり
max memory 0 (上限なし) 0 (上限なし)
max client 0 (上限なし) 0 (上限なし)
tcp-keepalive 0 0
timeout 0 0

ec2 Linux チューニング

ElastiCache はできないため省略

パラメータ 設定値
net.ipv4.ip_local_port_range 1024 65000
net.core.somaxconn 1024
net.ipv4.tcp_syn_retries 1
net.ipv4.tcp_fin_timeout 10
net.ipv4.tcp_tw_recycle 1

今回設定していないパラメータ

パラメータ 設定値
net.core.somaxconn 30720
net.core.netdev_max_backlog 30720
net.ipv4.tcp_max_syn_backlog 30720

テスト概要

パラメータをいじらない ベンチマークを基準として、 大きく 4つのベンチ測定要素で計測 (pipeline は常に有効)

  1. Request 数を増やして、リクエストが増加した時の応答の違い
  2. DataSize を増やして、送信サイズが大きい場合の応答の違い
  3. KeySize を増やした場合の応答の違い
  4. Concurrency を増やして、同時接続数が増加した時の応答の違い

各種5回実施してaverageで計測

テスト結果概要

優劣

EC2 の方が全般的に スコアが数%高いものの、大きな差はつかず。(96%前後 - 103%前後 の 範囲内)

96 - 103% というのは、Redis自体がベンチマーク結果にぶれを起こすことはご存知の通りで、おおよそ誤差範囲内と見なせます。

RDB運用としては、EC2と Redis on ElastiCacheでは同等の性能を発揮できる環境とみなしてもおおよそ誤差がないといえる。

処理による負荷傾向

前提として、Pipeline処理されるかどうかがどれだけ大事かがわかります。

またEC2/Elasticに関わらずRedisの傾向として、以下の2要素が性能に大きく左右することが見て取れます

  • datasize (L処理)
  • concurrency (全般)

つまり、datasize の大きさ。concurrency の多さが性能劣化の要素になりえるということです。

一方で以下の2要素の大小は性能にはそれほど影響していないこともわかります。

  • key
  • request

今後の懸念点

  • Snapshot や ReadReplica 運用 => RDBの途中インポート(入れ替え)、抜出ができないのでロールバックができないのが移行には致命的 => アップデートによりRDBインポート、バックアップ(S3へ) 対応されたので問題なし

  • Slave の Master昇格は容易 => (RDB や AOF で)現在のインスタンスをベースに別ElasticCache Redis ReplicationGroup に環境を構成するためには、Clusterの作り直し => 構成変更での作業が必要以上に大がかり

  • maintenance Window 中の動作 (完全に停止して write/Read が停止したりする) => Replicaの昇格とprimarynode参照で対応 => 事前に昇格入れ替えが生じるため、短時間でもダウンタイムは避けられないケースもある

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment