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 内部での接続 |
※メモリ読み込み量 400MB (RDB)
| パラメータ | ec2設定 | ElastiCache設定 |
|---|---|---|
| AOF | なし | なし |
| save | "" | あり |
| max memory | 0 (上限なし) | 0 (上限なし) |
| max client | 0 (上限なし) | 0 (上限なし) |
| tcp-keepalive | 0 | 0 |
| timeout | 0 | 0 |
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 は常に有効)
- Request 数を増やして、リクエストが増加した時の応答の違い
- DataSize を増やして、送信サイズが大きい場合の応答の違い
- KeySize を増やした場合の応答の違い
- 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参照で対応 => 事前に昇格入れ替えが生じるため、短時間でもダウンタイムは避けられないケースもある
