DSAS開発者の部屋

KVS界隈ではすっかりおなじみ(?)のRedisですが、当社でも徐々にそのニーズが高まってきました。
標準機能として、レプリケーション、Pub/Sub、ソート等の便利機能が満載のRedisですが、サービスに投入する際に冗長構成をどう組むかといった点が気になっている方もいるのではないでしょうか。
まだまだ検証中ではあるのですが、Redisに実装されているRedisSentinelを用いて冗長構成を組んだ際にハマった所をご紹介したいと思います。

RedisSentinelとは

Redisに標準実装されている機能の一つで、Redisのステータス監視、通知、自動フェイルオーバーが行なえます。
詳細な仕様、設定に関しては以下のドキュメントをご確認下さい。
http://redis.io/topics/sentinel

RedisSentinel導入前の構成

特に何の変哲も無い構成です。
Redisサーバ間ではRealIPを用いてレプリケーションを行ない、WEBサーバ上のアプリケーションからRedisを利用する際はMASTERに設定されているVIP宛にリクエストを出します。

RedisSentinel導入後の構成

RedisSentinelサーバを3台用意し、監視先の設定をVIPにしてみました。

各RedisSentinelの設定は共通で以下の様になっています。

1. sentinel monitor prod 192.168.8.1 6379 2
2. sentinel down-after-milliseconds prod 3000
3. sentinel failover-timeout prod 6000
4. sentinel can-failover prod yes
5. sentinel parallel-syncs prod 1
6. sentinel client-reconfig-script prod /opt/klab/sbin/redis_chroute.sh

監視先をVIPにすることで、障害発生時にRedisSentinelが再起動しても監視を続行出来るようにしてみました。
この検証時点ではRedis2.6.12を使用しており、一見想定通りに動作していた....ように見えたのですが、この設定のままでRedis2.6.13以降のバージョンへ置き換えた際に、問題が発生しました。
また、ドキュメントをよく読んだ方は既にお気づきかもしれませんが、バージョン関係なく障害発生時にSDOWNを検出できなくなる場合があります。

DEMOTE flag

まず、Redisのバージョンを2.6.13以降にした場合の問題から説明します。
Redis2.6.13以降、「DEMOTE flag」が追加されました。 疎通が取れずにODOWNとして扱われたMASTERに対して紐づくフラグです。 このフラグが立ったインスタンスに対し再び疎通が取れる様になった際、今現在のMASTER(旧SLAVE)となったRedisのSLAVEとして動作するように再設定が行なわれます。
さくっと冗長構成を組み直す事ができるので少し運用が楽になりそうな機能です。

しかし、VIPをRedisSentinelの監視先にした場合、上記機能の影響で問題が発生してしまいます。
各RedisSentinelはMASTERとSLAVEに関する情報を持っているのですが、障害発生前と障害発生後の状態を図にしてみました。

---

・障害発生前

ip	port	status
192.168.8.1	6379	MASTER
10.13.0.2	6379	SLAVE

・障害発生後

ip	port	status
192.168.8.1	6379	DOWN
10.13.0.2	6379	MASTER

フェイルオーバーが実施されると、SLAVEがMASTERへと昇格すると共にVIPも引き継がれます。
その際、RedisSentinelからはあたかも旧MASTERが復帰したように見えるため、今現在のMASTER(自分自身)へレプリケーションを行なうよう再設定を行なう結果となりました。
その結果、MASTER不在となりサービスに支障が出てしまいます。

SDOWNを検出できなくなる

これはドキュメントをよく読んで頂くとわかるのですが、RedisSentinelは障害(SDOWN)を検知すると、自分以外のRedisSentinelに対して「 is-master-down-by-addr 」コマンドを用いてMASTERの状況を問い合わせます。
この時、引数として障害が発生したと思われるMASTERのIPとポート番号が is-master-down-by-addr コマンドに与えられるのですが、この情報が各Sentinelの持つノード情報と一致する必要があります。
以下の図にあるように、フェイルオーバー後に特定のRedisSentinelを立ち上げ直した場合、同じMASTERに接続していても、IPとポート番号に差異が出てしまうためMASTERのステータスを正しく返すことができません。



このような問題が起きた事から今現在はRedisSentinelの監視先をRealIPへと変更して検証を続けています。

【今回のまとめ】

* Redis Sentinelを利用して冗長構成を組む事が出来る。
* Redis2.6.13以降のバージョンを利用すると、運用が少し楽になるはず。
* RedisSentinelの監視対象は、VIPではなくReal IPを利用。

検証初期ではありますが、RedisSentinel非常に使いやすく便利だなという印象です。
また嵌った点が出た際にはこちらでご紹介させて頂きます。