Redis Sentinelの深淵：分散合意と「真の」高可用性を制御する
Redisを単なる「高速なKVS」と見なしているうちは、大規模システムでの運用は地獄を見る。特に、Redis Sentinelによるフェイルオーバーは、ドキュメントをなぞるだけでは決して到達できない「分散システムの非決定性」との戦いだ。
本稿では、Sentinelの表面的な設定ではなく、その内部アーキテクチャと、なぜ我々が「高可用性」を設計する際に細心の注意を払うべきかについて、エンジニアの深層心理に訴えるレベルで解剖する。
—
1. Raftアルゴリズムの影：Sentinelの合意形成メカニズム
Sentinelは単なる監視プロセスではない。実態は、Raftアルゴリズムを簡略化した独自の合意形成プロトコルを実装した分散ノード群である。
フェイルオーバーの要となるのは以下の3つのフェーズだ。
1. SDOWN (Subjectively Down): 個々のSentinelが `is-master-down-after-milliseconds` を超過したと判断する状態。
2. ODOWN (Objectively Down): 複数のSentinelが合意し、クォーラム（定足数）を満たした状態。
3. Leader Election: `SENTINEL_IS_LEADER` エポックをインクリメントし、単一のSentinelがフェイルオーバーを実行する権利を勝ち取る。
ここで重要なのは、「ネットワークの分断（スプリットブレイン）」をいかに回避するかだ。クォーラムの設定を `(N/2)+1` 未満に設定すれば、瞬時に整合性は崩壊する。伝説的なアーキテクトなら、この `quorum` 設定と、ネットワークの遅延・パケットロス率の相関関係を、ハードウェアのスペックと同一線上で語れるはずだ。
2. フェイルオーバーの「空白」を支配する
Sentinelがフェイルオーバーを実行する際、内部で何が起きているか。
Sentinelのログから読み解くべき真実
+sdown: masterがダウンしたと個別に検知
+odown: クォーラム到達による異常確定
+try-failover: リーダー選出プロセスの開始
+elected-leader: 執行役としての権限確立
+failover-state-select-slave: 最適なreplicaを選定
ここで最も危険なのが、「接続しているクライアントのハンドリング」だ。フェイルオーバー中、書き込み先が一時的に消失する。この「ミリ秒単位の空白」をクライアント側でどう吸収するか。
- Pub/Subの活用: アプリケーションは `+switch-master` イベントをサブスクライブし、コネクションプールを即座に再構築すべきだ。
- 構成プロバイダーとしてのSentinel: クライアントライブラリは、必ずSentinel経由でマスターをルックアップさせること。ハードコードされたIPなど、爆弾を抱えているに等しい。
3. メモリ最適化と運用上の盲点
高可用性を追求するあまり、Sentinel自体の負荷を過小評価してはならない。
- メモリの断片化: Sentinel自体は軽量だが、監視対象のマスター/レプリカの数が増えれば増えるほど、内部の `dict`（ハッシュテーブル）構造が肥大化する。`jemalloc` の挙動を観察し、RSS（Resident Set Size）の推移を監視せよ。
- レプリケーションラグの罠: レプリカが `slave-read-only` であっても、マスタとの同期が遅延すれば、フェイルオーバー時にデータの「巻き戻り」が発生する。`min-slaves-to-write` と `min-slaves-max-lag` の設定は、可用性と整合性のトレードオフの防波堤だ。
整合性を死守するための極限設定
レプリカが1秒以上遅延している場合、マスタは書き込みを受け付けない
min-slaves-max-lag 1
min-slaves-to-write 1
4. 伝説的アーキテクトからの提言：設計の美学
Sentinelを導入する際、最も多い失敗は「SentinelをRedisと同じ物理ノードに同居させる」ことだ。これでは、物理ホストが死んだ瞬間に監視機能も共倒れする。
1. 奇数個のSentinel: 少なくとも3ノード以上、できれば異なる故障ドメイン（ラック単位の分離）に配置せよ。
2. 監視の監視: Sentinelのプロセスが停止していても、Redis本体は動き続けるため、障害検知自体が死ぬ。`monit` や `systemd` によるプロセス監視は必須だ。
3. ネットワークの非対称性: 本番環境では、アプリケーションサーバーからのアクセス経路とは別に、Sentinel専用の管理ネットワークを構築するのが、真に堅牢なアーキテクチャの条件である。
結びに：技術は「信頼」の数式
Redis Sentinelは、完璧ではない。しかし、分散システムにおける「不確実性」を数学的に制御しようとする人類の挑戦の結晶だ。
Sentinelを語ることは、Redisというプロダクトの限界と、その上でいかに「止まらないサービス」を構築するかという哲学を語ることと同義である。ドキュメントを読み終えたら、次はソースコードの `sentinel.c` を開き、イベントループの中で何が起きているかを追跡してほしい。
そこにしか、真のエンジニアリングの回答はない。
コメント