はじめに
他のRedis構築に関するページは以下をご参考ください。
Redis構築のまとめ
環境
CentOS 6.8
Redis 3.2.5(当時の安定バージョン)
各検証内容
| 方式 | 検証内容 | 公式ドキュメント |
|---|---|---|
| Replication | Redis Replication検証 | https://redis.io/topics/replication |
| Cluster | Redis Cluster検証 | 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台 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監視下に入る) |
| 12 | Masterダウン時の処理 | なし | SlaveのMaster昇格 | ・SentinelでMasterダウンを検知 ・SlaveのMaster昇格 |
| 13 | フェイルオーバーまでの時間 | 昇格しない | 即昇格 | 昇格まで0.X〜X秒必要 (sentinelがMasterダウンを検知してから昇格させるため) |
| 14 | Redis外での実装 | アプリケーション側orLB等でIPの切替が必要？ →sentinel client-reconfig-scriptで任意のシェルを実行することで対策 AliasIPを使用したSentinelのサーバ切り替え検証 |
||
| 15 | 採用企業(検証ブログより) | akatsuki |
GMO Cyber Agent |
|
| 16 | 特徴的な機能 | リシャーディング機能 | ||
| 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は稼働台数によって可用性が高くなる |
| 保守性 | ○ | ○ | ○ | ◎ |