TL;DR

• Redis Clusterで運用は本当に楽になった
  • でも、Redis 4.0は不安
• Redis Clusterで一番怖いのはDisk IO
  • 特にフェイルオーバーなどのFull Resync時

Redisとは？

• 高速なインメモリ型のKVS
• シングルスレッド
• 豊富なデータ構造(次ページにて詳細)
• 豊富な操作(次々ページにて詳細）

豊富なデータ構造

• key-value型
• hash型(key-field-value)
• set型(集合演算ができる)
• sorted set型(スコア付きset)
• 任意の型(redis modules機能)

豊富な操作

• インクリメントや和集合などなど
• lua scriptも実行できちゃう
  • シングルスレッドだからatomicな処理になる

Redisの問題点

• writeがスケールしない
• 気軽に停止できない
  • サーバー再起動やバージョンアップなど

Redis Cluster登場

• キーごとに水平シャーディング
  • writeがスケールする！
• 無停止フェイルオーバーができる
  • サーバーの停止ができる！
  • Redisのバージョンアップができる！

Redis Clusterの問題点

• multiple key操作がしにくくなった

Redisではできた

del key1 key2 key3

Redis Clusterではしにくい

同じスロット(※)に割り当てられたキーにしか出来ない。
↓は一応できる。

del {key}1 {key}2 {key}3


スロット(slot)

• redis clusterのシャーディングする際の単位
• cluster全体で16384個のslotを持つ
• ある特定のキーはhash計算され、いずれかのスロットに割り当てられる
• multiple key操作は、同一スロット内にしか行えない
• キー名の一部を{}で囲むと、{}内に囲まれた文字でhash計算される
  • つまり、同一のスロットに明示的に割り当てられる
  • key1とkey2は別スロットになるが
  • {key}1と{key}2は同じスロットになる

Redis Clusterの問題点2

• リソースを富豪的に使う

リソースを相当富豪的に使う

• メモリ使いすぎ
• 既定値では、masterがactive,slaveはstandby
• slaveに持たせている分のデータは利用されない
  • slaveにreadを向かせたい場合は、設定変更が必要
  • クライアントライブラリの対応も必要

リソースを相当富豪的に使う2

• 機材使いすぎ
• Redis Clusterの最小推奨構成はmaster3/slave3
  • 物理サーバー故障も考えると、サーバー筐体3台必須
  • なぜmaster3/slave3が最小推奨構成かは後述

ここまでがRedis Clusterの概要

ここからが運用していく中で感じたこと

結局、推奨構成は？

• masterは3ノード以上の奇数
• masterとslaveの比率は1:2以上

why?masterが3ノード以上の奇数？

masterの数を増やすと

• writeが分散される
• 複数のmasterが同時にダウンした時の可用性が向上する

障害時にslaveの昇格投票ルール

• 全masterのうちの過半数の賛成票が必要

例えば

• 3masterでClusterを組むと
  • 2master同時にダウンすると、生きているmasterは1つ
  • つまり、過半数(2つ以上)の賛成票は絶対得られない
• 4masterでClusterを組むと
  • 2master同時にダウンすると、生きているmasterは2つ
  • つまり、過半数(3つ以上)の賛成票は絶対得られない
• 5masterでClusterを組むと
  • 2master同時にダウンすると、生きているmasterは3つ
  • つまり、過半数(3つ以上)あの賛成票を得られる

※最小推奨構成がmaster3/slave3なのは、この投票ルールのせい

masterを3ノード以上の奇数にするのは

同時にmasterがダウンした時にも
サービス継続できるようにするため。

why?masterとslaveの比率は1:2以上？

• masterが連続でダウン(not同時)した時の可用性が向上する

slaveの融通(レプリカマイグレーション)

masterとslaveの比率が1:1だったら？
masterがダウンし、slaveが昇格した後、
昇格した元slaveには、slaveはいない。

つまり、昇格した元slaveが単一障害点になる。

masterとslaveの比率が1:2以上なら
slaveを持っていない単一障害点のmasterには、他のslaveを複数持つmasterから、slaveを自動で融通してもらえる。

master:slave比率を1:2以上にするのは

連続でmasterがダウンした時にも、
サービス継続できるようにするため。

Redis Clusterの可用性まとめ

例えば、
Redis 15インスタンス(5master,10slave)構成では

• masterが2ノード同時に落ちても、サービス継続できる
• 悲観的に適当な6ノードが連続で落ちても、サービス継続できる

つまり、夜に熟睡できる！

Redis Clusterのイケてないところ

• Disk IOが激しい

可用性のためのmaster昇格やslave融通の際、
毎回Full Resyncが走る。

Full Resyncが走れば、Redisのバックアップファイルである
RDBやAOFのDisk Writeがバカにならない。
(つらい、上手いこと部分同期してくれ)

実際にあった事例

Disk IOが詰まり、masterノードが死と判定され、
slaveが昇格。

slave昇格時のDisk IOがやっぱり詰まり、またすぐに死判定され、
また別のslaveが昇格。連鎖的に昇格祭り。

解決方法
- Disk IOの遅さを改善したり(RAID ControllerやSSD)
- そもそも大きなデータを減らしたり
- AOFやRDBのバックアップを停止させたり

今後のRedis Clusterの不安事

• 現在Redis最新は3.2.6
• 開発中のは4.0.0-RC2
• 3系と4系を混ぜてCluster組めないっぽい

3系で作ったClusterから4系への移行、どうしよう。
今から新規に組むなら、4系を待つ選択肢も。

その他

• フェイルオーバー(昇格)の検知は、nodes.confファイルのタイムスタンプで検知できる
• Cluster組む前に色々、redis.confは設定すべき
  • ノードが死んだと判断されるまでの秒数
  • 1ノードが死んだ時にCluster全体を死ぬ判定にするか、そのノードを担当していたキーだけを死んだ判定にするか
  • 細かい設定はRedis cluster tutorial参照
• Redisのノード間の通信(GOSSIP)の非効率さ、なんとかならないのか・・・
  • ノードIDが無駄に長いせいなんだけど・・・

まとめ

• Redis Clusterで夜、安心して眠れる
• 3系から4系への移行どうしよう
• 良きRedis Clusterライフを