Redis Sentinel入門：自動フェイルオーバーで高可用性（HA）を実現する方法

Redis Sentinelは、Redisにシンプルかつ自動的な高可用性（HA）ソリューションを提供するコンポーネントです。MongoDBのレプリカセットにおける選挙（election）の仕組みに馴染みがある方なら、その概念はそれほど難しくありません。基本構成としては、1台のマスターが複数台（N台）のスレーブへレプリケーションを行い、そこにSentinelデーモンを配置します。Sentinelはアプリケーションサーバー上、またはRedisが稼働しているサーバー上で起動でき、常時マスターの健全性を監視します。

あるSentinelがマスターの無応答を検出すると、他のSentinelへ向けてSDOWN（Subjectively Down：主観的ダウン）メッセージをブロードキャストします。その後、マスターがダウンしているという合意（クォーラム）が成立すると、ODOWN（Objectively Down：客観的ダウン）が宣言され、新しいマスターの選出が行われます。ODOWN状態に移行するには過半数のSentinelの同意が必要なため、判定が同数で膠着する事態を避るべく、Sentinelは必ず奇数台で稼働させるのがベストプラクティスです。

※補足：Sentinelとの組み合わせで最高のパフォーマンスを得るには、Redis 2.8系以降のバージョンを使用することを強く推奨します。

Sentinelの仕組み

Sentinelは、稼働中のRedisインスタンスの設定ファイルを書き換えることでフェイルオーバーを実現します。具体的なシナリオで見てみましょう。

ここでは、マスター「A」がスレーブ「B」「C」にレプリケーションしている構成を想定します。Redisに書き込みを行うアプリケーションサーバー上では、3つのSentinel（s1、s2、s3）が稼働しています。この状態で現行マスターの「A」がオフラインになると、すべてのSentinelが「A」の停止を検知し、互いにSDOWNメッセージを送信します。全Sentinelが「A」のダウンに同意した時点で、「A」はODOWN状態に設定されます。続いて、どのノードが最もレプリケーションが進んでいるかを決める選挙が実施され、このケースでは「B」が新しいマスターに選ばれます。

その後、「B」の設定ファイルは「誰のスレーブでもない」状態（＝マスターとして動作する状態）に書き換えられます。同時に「C」の設定ファイルも、「A」ではなく「B」のスレーブとなるよう書き直されます。これ以降は通常どおり運用が継続されます。仮に「A」がオンラインに復帰しても、Sentinelがそれを認識し、「B」が現行マスターであるため、「A」の設定を「B」のスレーブとして再構成してくれます。

Sentinelの設定方法

Sentinelの設定は想像ほど難しくありません。むしろ悩ましいのは、Sentinelプロセスをどこに配置するかという点でしょう。筆者のおすすめは、可能であればアプリケーションサーバー上で実行することです。そもそもこの構成を導入するということは、マスターへの書き込み可用性が重要であるはずです。アプリケーションサーバー上にSentinelを置けば、「アプリケーションサーバーからマスターへ通信できるか」という観点での監視にもなり、一石二鳥です。もちろん、Redisインスタンスのサーバー上でSentinelを動かしても問題ありません。

設定を始めるには、Redisディストリビューションに同梱されているサンプルファイルを参照してください。以下はUbuntu 14.04環境のRedis 2.8.4に含まれるsentinel.confの例ですが、2.8.x系であればそのまま利用できます。実運用で筆者が好んで追加している2行を先頭に入れています。

daemonize yes
logfile /var/log/redis/redis-sentinel.log

この2行により、Sentinelプロセスがデーモンモードで起動し、メッセージが標準出力ではなくログファイルに記録されるようになります。

sentinel.confには多くの設定項目があり、ほとんどが丁寧にコメントされていますが、ここでは特に重要な2項目に絞って解説します。

必須設定①：マスターの監視対象を指定する

最も重要なのは、現行マスターの場所をSentinelに伝えることです。以下の行で指定します。

sentinel monitor mymaster 127.0.0.1 6379 2

この行は、「mymaster」という名前（任意の名前で自由に付けられます）で、指定したIPアドレス・ポートのマスターを監視すること、およびフェイルオーバーのクォーラム成立に必要なSentinelの台数（最小値は2）を意味します。実際に変更が必要になるのは、マスターのIPアドレスと、標準ポート6379以外で稼働している場合のポート番号です。

必須設定②：ダウン判定までの待機時間を調整する

次に、以下の行の調整も検討しましょう。

sentinel down-after-milliseconds mymaster 30000

これは、SentinelがマスターをSDOWNと判定するまでの待機時間（ミリ秒）です。デフォルトは30秒ですが、筆者は通常10秒程度に短縮しています。ただし、あまり短くしすぎるとネットワークの一時的な揺らぎでフェイルオーバーが頻発する原因になるため、バランスが重要です。

その他のオプションも一度目を通しておくとよいでしょう。特におすすめなのが通知スクリプト（notification script）の設定で、フェイルオーバーが発生した際にアラートを受け取りたい場合に非常に役立ちます。

sentinel.confをお好みに合わせて編集したら、以下のコマンドでSentinelを起動します。

redis-server /path/to/sentinel.conf --sentinel

フェイルオーバーのテスト手順

すべてのSentinelがオンラインになったら、設定が正しく機能するかを確認するため、フェイルオーバーの予行演習（ドライラン）を実施できます。

まず、redis-cli経由でSentinelに接続します。

redis-cli -p 26379

Sentinelの状態情報を取得するには、次のコマンドを実行します。

127.0.0.1:26379> INFO

これにより、現行マスターがどのノードか、スレーブが何台接続しているか、何台のSentinelが監視に参加しているかといった情報が確認できます。

フェイルオーバーを意図的に発生させてテストするには、以下のコマンドを実行するだけです。

127.0.0.1:26379> SENTINEL failover mymaster

このコマンドにより、現行マスターに対して強制的にODOWNが発生し、フェイルオーバーが実行されます。少し待ってから再度「INFO」コマンドを実行すれば、新しいマスターが表示されているはずです。

まとめ

本記事では、Redis Sentinelの基本的な仕組みから、設定ファイルの編集、フェイルオーバーのテスト方法までを解説しました。Sentinelを正しく構成すれば、マスター障害時にも自動的に切り替わり、サービスの可用性を大きく高められます。ご不明な点があれば、ぜひコメント欄でお気軽にご質問ください！