Redis Sentinelの深淵：なぜ「自動フェイルオーバー」の裏側を知らねばならないのか
Redis Sentinelは、単なる「監視ツール」ではない。それは分散システムにおけるコンセンサス・アルゴリズムの実装であり、ネットワーク分断という悪夢の中で、いかにして「真実のマスター」を決定し続けるかという、極めて高度な生存戦略そのものだ。
多くのエンジニアは、Sentinelを「自動再起動の手間を省くもの」と誤解している。だが、大規模トラフィックを捌くアーキテクトにとって、Sentinelは「ネットワークの揺らぎ」と「非同期レプリケーションの遅延」という、避けられない物理的な制約との戦場である。
今日は、ドキュメントの表面をなぞるような解説はしない。Sentinelの内部で何が起きているのか、その冷徹なメカニズムを解剖する。
—
1. Raftにも似た「Gossip」と「Quorum」の真実
Sentinelは、マスターが死んだかどうかを判断するために `Quorum`（定足数）という概念を用いる。しかし、ここで陥りやすい罠がある。
- Sentinel間の合意形成（Election）: マスターの故障を検知したSentinelは、他のSentinelに対して自分をリーダーとして選出するよう提案する。ここで使われるのはRaftアルゴリズムに近い概念だが、完全に同一ではない。
- ネットワーク分断の恐怖: 分散システムで最も恐ろしいのは、ネットワークのパケットロスによる「偽の死（False Negative）」である。
Sentinelノードの数を奇数にするのは、単なるおまじないではない。Split-Brain（脳分離）を物理的に防ぐための数学的要請だ。偶数個のノードで構成し、ネットワークが真っ二つに割れたとき、どちらが「真実」を決定すべきか。そのときシステムは停止を選択すべきであり、不完全な合意で動くべきではない。
2. フェイルオーバーの暗黒面：非同期レプリケーションの代償
Redisのレプリケーションは非同期（Asynchronous）だ。これが何を意味するか。
「マスターがクラッシュした瞬間、マスターに書き込まれたばかりのデータは、レプリカに到達していない可能性がある」ということだ。
Sentinelによる自動フェイルオーバーが走ったとき、「データ消失（Data Loss）」の可能性は常に残る。アーキテクトが設計すべきは、「データが失われないこと」ではなく、「データが失われたことを検知し、アプリケーションが整合性を回復するロジック」である。
運用上の極限知見：`min-replicas-to-write`
データの消失を許容できないビジネスロジックであれば、マスター側に以下の設定を強制せよ。
少なくとも1台のレプリカが10秒以内に同期していない場合、書き込みを拒否する
これにより、マスターの孤立によるデータ不整合を未然に防ぐことができる
min-replicas-to-write 1
min-replicas-max-lag 10
これを入れないSentinel運用は、いわば「いつデータが消えてもおかしくない時限爆弾」を抱えているに等しい。
3. ネットワークレイテンシがもたらす「スプリット・ブレイン」の検知
Sentinelの設定で最も重要なパラメータの一つに `down-after-milliseconds` がある。
30秒間応答がなければ「死んだ」とみなす
sentinel monitor mymaster 127.0.0.1 6379 2
sentinel down-after-milliseconds mymaster 30000
この値のチューニングは、システムの生存性と安定性のトレードオフだ。
- 短すぎる場合: 一過性のネットワークパケットロスで不必要なフェイルオーバーが走る。これはDBの再選出によるオーバーヘッドを招き、システム全体を不安定にする（スループットの急落）。
- 長すぎる場合: 本当に死んだノードに対してアプリケーションが長時間待ちぼうけを食らう。
プロの推奨値: 私は通常、ネットワークのジッター（揺らぎ）を計測し、その5〜10倍の値を設定する。単なる勘で数値を決めてはならない。
4. クライアント側の「真の知性」
Sentinelを導入しても、アプリケーション側が `SENTINEL get-master-addr-by-name` を適切にハンドリングしていなければ、何の意味もない。
多くの言語のRedisクライアントは、Sentinelをサポートしている。内部的には以下のようなフローで接続を確立しているはずだ。
1. Sentinelのリストに接続を試みる。
2. `SENTINEL get-master-addr-by-name` を発行し、現在のマスターのIP/Portを取得する。
3. マスターに対して `AUTH` を行い、セッションを確立する。
4. 重要: フェイルオーバー発生時、クライアントは接続をクローズし、再びSentinelに問い合わせる能力が必要だ。
これを自前で実装しようなどとは考えるな。信頼できるライブラリが、内部でどのように再接続（Retry）を管理しているか、ソースコードの `connection_pool` 周りを必ず確認すること。
最後に：アーキテクトとしての提言
Sentinelは完成されたソリューションだが、「絶対的なものではない」。
真に可用性を追求するのであれば、Redis Clusterという選択肢もある。しかし、Redis Clusterはアプリケーション層の複雑性を増大させる。Sentinelを選ぶ理由は、「シンプルであること」と「既存のレプリケーション構成を維持できること」に尽きる。
もし君が大規模なRedis運用を任されているなら、Sentinelのログを監視するだけでは不十分だ。「Sentinelが誤検知を起こす確率」を計算し、それに対するアプリケーション側のリトライ戦略を設計せよ。
技術の限界は、ハードウェアの限界ではなく、それを利用する人間の「設計思想の限界」によって決まる。次のデプロイでは、フェイルオーバーを「イベント」ではなく「システムの一部」として組み込んでみてほしい。
健闘を祈る。
コメント