こんにちは。Redisの世界へようこそ。
「Redisって速いらしいね」「キャッシュに使うといいらしいね」という話はよく聞きますよね。でも、いざ本番環境で使うとなると、「もしRedisが突然止まったらどうなるの？」という恐怖が頭をよぎるはずです。
サーバーは生き物です。いつか必ず調子を崩します。その時に慌てないための仕組みがRedis Sentinel（センチネル）です。今日は、この「Redisの守護神」の正体を、難しい専門用語を抜きにして紐解いていきましょう。
—
1. そもそもRedis Sentinelって何？
簡単に言うと、「優秀な監視員チーム」です。
想像してみてください。あなたは巨大なホテルの支配人（アプリケーション）です。Redisは、最高に優秀な「フロント係」です。彼のおかげで、お客様の注文（データ）を爆速で処理できています。
しかし、フロント係が突然倒れてしまったら？ ホテルは大混乱です。そこで登場するのが「Sentinel」という監視員チームです。
- 監視: 常にフロント係の様子を伺っています。
- 判断: 「あれ、返事がないな。もしかして倒れた？」と異変を察知します。
- 交代: 控えのフロント係（レプリカ）を即座に呼び出し、メインの座に据えます。
これが、自動フェイルオーバーの正体です。人間が夜中に叩き起こされることなく、システムが勝手に修復してくれる。これこそが、高可用性の極意です。
—
2. 「監視員」はどうやって動いているの？
Sentinelは単体では動きません。通常、3人以上のチームで構成されます。なぜなら、1人だと「勘違い」をする可能性があるからです。
- 「あいつ、反応がないぞ！」（Sentinel Aの主張）
- 「いや、俺からは見えてるけど？」（Sentinel Bの反論）
このように、「過半数の合意」を得て初めて「故障した！」と判定します。この慎重さが、誤作動を防ぐ重要なポイントなんですよ。
—
3. 設定ファイルを見てみよう（sentinel.conf）
Sentinelの設定は、実は驚くほどシンプルです。「誰を見張るのか」「何秒反応がなかったら異常とみなすか」を教えるだけです。
監視対象のRedisサーバーを指定（名前はmymaster、IPとポート、最後は2個のSentinelが同意したら故障とみなすという意味）
sentinel monitor mymaster 127.0.0.1 6379 2
30秒間反応がなければ「死んだ」とみなす（単位はミリ秒）
sentinel down-after-milliseconds mymaster 30000
フェイルオーバーのタイムアウト
sentinel failover-timeout mymaster 180000
これだけで、Sentinelは「mymaster」という名前のRedisを監視し始めます。もしメインが倒れれば、勝手に新しいメインを選出し、アプリケーション側に「新しいフロント係はここだよ！」と教えてくれるんです。
—
4. 運用上の極意：ここだけは忘れないで
初心者がハマりやすい落とし穴を一つだけ教えますね。それは、「アプリケーション側の接続設定」です。
多くの人は、プログラムから直接「RedisのIPアドレス」を指定して接続します。でも、Sentinel環境では「メインのRedis」がコロコロ入れ替わる可能性があります。
だからこそ、「RedisクライアントライブラリのSentinelモード」を使ってください。「RedisのIPを直接指定する」のではなく、「Sentinelの監視先（SentinelのIPとポート）」をライブラリに渡すのです。そうすれば、ライブラリが勝手に「今のメインはどこ？」とSentinelに聞いて接続先を切り替えてくれます。
—
まとめ：これであなたもRedisの守護者です
Redis Sentinelは、決して難しい魔法ではありません。
1. 監視員（Sentinel）を配置する
2. 異常を検知したら多数決をとる
3. 控え選手をメインに昇格させる
この流れさえイメージできていれば、Redisの高可用性はもう怖くありません。
「完璧なシステム」を作ろうとするのではなく、「壊れても自動で治る仕組み」を作る。これこそが、エンジニアリングにおけるプロフェッショナルの考え方です。
まずは手元の環境で、Sentinelを起動してメインのRedisをわざと落としてみてください。何事もなかったかのように切り替わる瞬間、きっと「おっ、すごい！」と感動するはずですよ。
ここをクリアしたあなたは、もうRedisの初級者ではありません。次はぜひ、クラスタリングの世界も覗いてみてくださいね。応援しています。
コメント