Redisの各構成比較

# はじめに
他のRedis構築に関するページは以下をご参考ください。
[Redis構築のまとめ](https://qiita.com/ono-soic/items/d63ac849ebccee68b5bc)

# 環境
CentOS 6.8
Redis 3.2.5(当時の安定バージョン)

# 各検証内容
| 方式 | 検証内容 | 公式ドキュメント
|:--|:--|:--|
| Replication | [Redis Replication検証](https://qiita.com/ono-soic/items/d7a3de5f8f859c4add79) | https://redis.io/topics/replication
| Cluster | [Redis Cluster検証](https://qiita.com/ono-soic/items/a41044c977da5231297b) | https://redis.io/topics/cluster-tutorial
| Sentinel | Redis Sentinel検証(近日UP予定) | https://redis.io/topics/sentinel

# 各方式の比較
| No | 項目 | Replication方式 | Cluster方式 | Sentinel方式 |
|:--|:--|:--|:--|:--|
| 1 | 必要台数 | 2台 | 6台 | 3台 |
| 2 | 構成 | Master1台<br>Slave1台 | Master3台<br>Slave3台 | Master1台<br>Slave1台<br>Sentinel1台(1台に3プロセス) |
| 3 | 最低稼働台数 | 1台 | 3台 | 1台 |
| 4 | サービス不能になる可能性があるダウン台数 | 1〜2台 | 2〜4台<br>[障害時の挙動](https://blog.albert2005.co.jp/2015/04/28/redis-cluster-%E3%81%AE%E6%A7%8B%E7%AF%89%E3%81%A8%E5%88%A9%E7%94%A8%EF%BC%88redis-3-0-0%EF%BC%89-2/)参照 | 2〜3台 |
| 5 | フェイルオーバー(昇格)可否 | 不可 | 可能 | 可能 |
| 6 | データ参照 | 1台あればデータ参照可能 | 落ちたサーバのデータは取得できない | 復活すると参照できる | Master/Slaveが稼働していればデータ参照可能 |
| 7 | データ保持方法 | Masterに保持し、SlaveがMasterをReplicationする | 3台のMasterにデータを分散して保持 | Masterに保持し、SlaveがMasterをReplicationする |
| 8 | 参照時の負荷 | 普通 | 少ない | 普通 |
| 9 | 可用性 | 普通 | 高い | 高い |
| 10 | メモリ | 普通 | 必然的にデータが分散するため期待できる | 普通 |
| 11 | サーバの追加 | 可能 | 可能(Clusterを再構成するコマンド実行が必要) | 可能(即sentinel監視下に入る) |
| 12 | Masterダウン時の処理 | なし | SlaveのMaster昇格 | ・SentinelでMasterダウンを検知<br>・SlaveのMaster昇格 |
| 13 | フェイルオーバーまでの時間 | 昇格しない | 即昇格 | 昇格まで0.X〜X秒必要<br>(sentinelがMasterダウンを検知してから昇格させるため) |
| 14 | Redis外での実装 |   |   | アプリケーション側orLB等でIPの切替が必要？<br>→sentinel client-reconfig-scriptで任意のシェルを実行することで対策<br>[AliasIPを使用したSentinelのサーバ切り替え検証](https://ameblo.jp/principia-ca/entry-11573342807.html) |
| 15 | 採用企業(検証ブログより) | | [akatsuki](http://hackerslab.aktsk.jp/other/redis_cluster_construction_method/) | [GMO](http://tech.gmo-media.jp/post/48748908427/introduce-redis-sentinel)<br>[Cyber Agent](https://ameblo.jp/principia-ca/entry-11573342807.html) |
| 16 | 特徴的な機能 |   | リシャーディング機能 |   |
| 17 | 全体のメリット | ・Masterが落ちても　データの不整合が起きない<br>(Slaveが即座にReplicationしてくれるため) | ・複数台マスタとして存在するので負荷分散、可用性に長けている<br>・Redisサーバの切替をRedis内で行ってくれる<br>・リシャーディング機能がある | ・最高N-1/N台落ちても稼働することができる<br>・Clusterと比べてデータの不整合が起きづらい<br>・サーバ追加がしやすい |
| 18 | 全体のデメリット | ・可用性が他二つと比べると低い<br>・Masterが落ちると終わる<br>・2台落ちるとデータが飛ぶ | ・落ちたサーバのデータを一時参照できなくなる<br>・2台落ちるだけでClusterがダウンする可能性がある(紐付いているMasterとSlave) | ・Redis外でIPの切替処理が必要<br>・Clusterと比べて昇格まで少し時間が掛かる<br>・Master復帰が即座に行われると再起動前後に差異があっても認識されず、データが破壊される可能性がある |
| 19 | 検証できていない点 | 特になし | ○落ちたMasterからのデータが取得できなくなることの対策はできないか<br>→できるならClusterを採用する可能性もある<br>slaveofを使おうとしたが、cluster modeの時は使用できないようだった<br><br>○その他どれくらいの負荷に対応しているか | ○Masterが落ちてからどれくらい短い時間で検知して自動フェールオーバが可能か<br><br>○Masterが停止して即起動した場合にデータが破損しないか問題<br><br>○その他どれくらいの負荷に対応しているか |

# 目的に対する構成のオススメ度
どのような目的によってオススメの構成をまとめました。
こちらについては所感なので参考程度に。

| 目的 | Redisの導入 | Replication方式 | Cluster方式 | Sentinel方式 | 備考 |
|:--|:--|:--|:--|:--|:--|
| 処理速度を上げたい | ◎ | ○ | ○ | ○ | MySQLと比べても明らかに速い<br>参考)[redis、それは危険なほどのスピード](http://ameblo.jp/principia-ca/entry-11197286812.html) |
| データ量が多い | ○ | ○ | ○ | ○ |  |
| データを確実に保持したい | ○ | ○ | ○ | ○ |  |
| データを長期的に保持したい | × | ○ | ○ | ○ | キャッシュとして使用することでRedisのメリットとなる。<br>ストレージとして使うとメモリが溢れて停止する可能性がある。<br>参考)[Redis本番障害から学んだコードレビューの勘所](http://qiita.com/haminiku/items/43bafbb9d74ef3a1f74c) |
| データ更新頻度が多い | ○ | ○ | ○ | ○ |  |
| データ参照頻度が多い | ○ | ○ | ◎ | ○ | Clusterはスレーブの参照を分散しているので参照への負荷に強い |
| サーバ稼働台数が多い | ○ | × | ◎ | ○ |  |
| サーバ稼働台数が少ない | ○ | ○ | ○ | ◎ |  |
| 可用性 | ○ | ○ | ○ | ◎ | Cluster/Sentinelは稼働台数によって可用性が高くなる |
| 保守性 | ○ | ○ | ○ | ◎ |  |