方式検証内容公式ドキュメントReplicationRedis Replication検証https://redis.io/topics/replicationClusterRedis Cluster検証https://redis.io/topics/cluster-tutorialSentinelRedis Sentinel検証(近日UP予定)https://redis.io/topics/sentinel

No項目Replication方式Cluster方式Sentinel方式1必要台数2台6台3台2構成Master1台
Slave1台Master3台
Slave3台Master1台
Slave1台
Sentinel1台(1台に3プロセス)3最低稼働台数1台3台1台4サービス不能になる可能性があるダウン台数1〜2台2〜4台
障害時の挙動参照2〜3台5フェイルオーバー(昇格)可否不可可能可能6データ参照1台あればデータ参照可能落ちたサーバのデータは取得できない復活すると参照できる7データ保持方法Masterに保持し、SlaveがMasterをReplicationする3台のMasterにデータを分散して保持Masterに保持し、SlaveがMasterをReplicationする8参照時の負荷普通少ない普通9可用性普通高い高い10メモリ普通必然的にデータが分散するため期待できる普通11サーバの追加可能可能(Clusterを再構成するコマンド実行が必要)可能(即sentinel監視下に入る)12Masterダウン時の処理なしSlaveのMaster昇格・SentinelでMasterダウンを検知
・SlaveのMaster昇格13フェイルオーバーまでの時間昇格しない即昇格昇格まで0.X〜X秒必要
(sentinelがMasterダウンを検知してから昇格させるため)14Redis外での実装

アプリケーション側orLB等でIPの切替が必要？
→sentinel client-reconfig-scriptで任意のシェルを実行することで対策
AliasIPを使用したSentinelのサーバ切り替え検証15採用企業(検証ブログより)
akatsukiGMO
Cyber Agent16特徴的な機能
リシャーディング機能
17全体のメリット・Masterが落ちても　データの不整合が起きない
(Slaveが即座にReplicationしてくれるため)・複数台マスタとして存在するので負荷分散、可用性に長けている
・Redisサーバの切替をRedis内で行ってくれる
・リシャーディング機能がある・最高N-1/N台落ちても稼働することができる
・Clusterと比べてデータの不整合が起きづらい
・サーバ追加がしやすい18全体のデメリット・可用性が他二つと比べると低い
・Masterが落ちると終わる
・2台落ちるとデータが飛ぶ・落ちたサーバのデータを一時参照できなくなる
・2台落ちるだけでClusterがダウンする可能性がある(紐付いているMasterとSlave)・Redis外でIPの切替処理が必要
・Clusterと比べて昇格まで少し時間が掛かる
・Master復帰が即座に行われると再起動前後に差異があっても認識されず、データが破壊される可能性がある19検証できていない点特になし○落ちたMasterからのデータが取得できなくなることの対策はできないか
→できるならClusterを採用する可能性もある
slaveofを使おうとしたが、cluster modeの時は使用できないようだった

○その他どれくらいの負荷に対応しているか○Masterが落ちてからどれくらい短い時間で検知して自動フェールオーバが可能か

○Masterが停止して即起動した場合にデータが破損しないか問題

○その他どれくらいの負荷に対応しているか

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