Redis Sentinel：分散合意の深淵と「見えない境界線」
多くのエンジニアが「Redis Sentinelは自動フェイルオーバーをしてくれる便利な監視ツール」だと誤解している。だが、アーキテクトの視点から言えば、それは極めて危険な認識だ。Sentinelは単なる監視プロセスではない。ネットワーク分断というカオスの中で、整合性を維持し続けるための「分散合意アルゴリズムの極小実装」である。
本稿では、教科書的な説明を一切排し、Redis Sentinelをシステムアーキテクチャの根幹として使いこなすための、内部メカニズムと「落とし穴」を解剖する。
—
1. Raftアルゴリズムの亜種：Sentinelの選出メカニズム
Sentinelの核は、Raftのような分散合意アルゴリズムに極めて近い、独自のリーダー選出ロジックにある。
クォーラム（Quorum）の真実
`sentinel monitor
この `quorum` は、「誰がマスターを倒したか」を決定するための最小投票数ではない。「フェイルオーバーを開始する権限を誰に与えるか」を決定するための閾値だ。
ここで陥りやすい罠がある。`quorum` を小さく設定すればフェイルオーバーは早くなるが、ネットワークの瞬断（フラッピング）による「誤検知」が誘発される。逆に大きくすれば安定するが、真の障害時に誰もフェイルオーバーを開始できなくなる。
私の設計指針はこうだ。
- 物理ノード数(N)に対して、常に `floor(N/2) + 1` の奇数個のSentinelを配置せよ。 偶数個の構成はスプリットブレインを許容する設計ミスと同義である。
Epoch（エポック）による権威の維持
Sentinelには `configEpoch` という概念が存在する。これは、どのSentinelがフェイルオーバーの指揮権を持っているかを一意に定めるためのカウンターだ。もしネットワークが分断され、二つの陣営で同時にフェイルオーバーが発生しようとしても、このエポック値が低い方は強制的に棄却される。この「バージョン管理された合意」こそが、Redisがデータの一貫性を守るための最後の砦だ。
—
2. 観測の深層：`sdown` と `odown`
Sentinelはマスターを監視する際、2段階のフェーズを踏む。
1. SDOWN (Subjectively Down / 主観的ダウン):
自身の通信において、`is-master-down-after-milliseconds` 内にPINGへの応答がない状態。これは個々のSentinelの「主観」に過ぎない。
2. ODOWN (Objectively Down / 客観的ダウン):
他のSentinelたちに「あいつ落ちてないか？」と問いかけ（`SENTINEL is-master-down-by-addr`）、その賛同数が `quorum` を超えた瞬間に宣告される。
ここで重要なのは、「ネットワーク分断か、マスターのプロセス死か」をSentinel単体で判別する方法はないということだ。だからこそ、Sentinelは「疎通確認」だけでなく、`INFO` コマンドを通じてマスターのレプリケーション状態まで覗き込み、ノードの生存を多角的に判断する。
—
3. 実務レベルの限界突破：アーキテクトの戒め
ネットワークバッファとタイムアウトの調整
デフォルトのタイムアウト設定を安易に信用してはならない。特に大規模なRedisクラスターでは、高負荷時にバッファが溢れ、PINGの応答が遅延するだけで誤ったフェイルオーバーが走る。
推奨設定の考え方
ネットワークジッターが激しい環境では、down-after-milliseconds を単に短くするのではなく、
許容可能なダウンタイムと誤検知のトレードオフを計算し、
OS側の net.core.somaxconn や tcp_max_syn_backlog と整合性を取ること。
sentinel down-after-milliseconds mymaster 5000
クライアント側の適応（Service Discovery）
Sentinel構成において最も愚かなのは、クライアントが直接マスターのIPをハードコードすることだ。
Redisのクライアントライブラリ（Jedis, Go-Redis, Lettuce等）は、Sentinel経由でトポロジーを動的に取得する機能を備えている。
// Go-Redisでの正しいSentinel接続の概念
rdb := redis.NewFailoverClient(&redis.FailoverOptions{
MasterName: “mymaster”,
SentinelAddrs: []string{“:26379”, “:26380”, “:26381”},
})
このクライアント側が「どのSentinelが今リーダーか」を問い合わせ、最新のマスターを特定するプロセスを理解していないと、大規模障害時のリカバリで詰むことになる。
—
結論：Sentinelは「魔法」ではない
Sentinelは万能ではない。それは「Redisという非常に高速だが壊れやすいエンジン」を、ネットワークの不確実性から守るための「外科手術用ロボット」だ。
君たちが真に追い求めるべきは、Sentinelの自動化に頼り切る運用ではなく、「なぜ今フェイルオーバーしたのか」というログ（Sentinelのイベント記録）を読み解き、ネットワークトポロジーとクォーラムの数学的な配置を最適化し続けることである。
もし君が大規模なRedis運用を任されているなら、一度全てのSentinelプロセスを停止して、手動でマスターを切り替えてみるといい。その時初めて、Sentinelが裏側で行っている「誰がリーダーかを決める」という孤独で厳格な交渉の重みが理解できるはずだ。
技術は常に、詳細（ディテール）の中に宿る。
コメント