Redis Sentinel：その「自動化」という名の諸刃の剣を使いこなすために
Redis Sentinelを単なる「自動フェイルオーバーツール」だと思っているなら、君のシステムは本番環境で確実に足元をすくわれることになる。
Sentinelは、分散システムにおける「合意形成」と「ネットワーク分断」という、エンジニアが最も避けて通りたい悪夢を日常業務に持ち込む技術だ。今日は、教科書には載っていない、実務で死なないための「Sentinelの深淵」について話をしよう。
—
1. Sentinelは「監視」ではなく「裁定」である
多くのエンジニアは、Sentinelを「死んだノードを見つける警備員」だと誤解している。だが、本質は違う。Sentinelは「誰がリーダー（Master）であるべきか」を合意し、クライアントにそれを強制する裁定者だ。
クォーラム（Quorum）の本当の意味
`sentinel monitor mymaster 127.0.0.1 6379 2`
この設定の末尾にある `2` がクォーラムだ。これは「何台のSentinelがMasterをダウンと判定したらフェイルオーバーを開始するか」という閾値である。
- 落とし穴: この値を小さくしすぎると、一時的なネットワーク瞬断で過剰なフェイルオーバー（フラッピング）が起きる。逆に大きくしすぎると、今度は本当に障害が起きた時に誰も決断できず、システム全体が停止する。
- 設計指針: Sentinelは常に奇数台で構成せよ。3台構成がデファクトスタンダードだ。2台で構成してはいけない。ネットワーク分断時にスプリットブレインを回避できなくなるからだ。
—
2. フェイルオーバーの裏側で起きていること
Sentinelがリーダーを選出する際、Raftアルゴリズムに似た合意形成が行われる。ここで重要なのは「Epoch（世代数）」の管理だ。
1. Subjectively Down (SDOWN): あるSentinelから見て応答がない状態。
2. Objectively Down (ODOWN): クォーラム数以上のSentinelがSDOWNを確認した状態。ここで初めてフェイルオーバーがトリガーされる。
ここで技術者が忘れてはならないこと:
フェイルオーバー中、Redisは一時的に書き込みを受け付けられない。この「ミリ秒単位のダウンタイム」を許容できないアプリケーションは、Sentinelを使う資格がない。その場合は、Redis Clusterの採用を検討すべきだ。
—
3. 実践：クライアントサイドの「賢い」設計
Sentinel構成において、アプリ側は「どのノードがMasterか」をハードコードしてはならない。必ずSentinelを介して接続先を解決する。
おすすめの構成パターン
アプリケーションからSentinelへ問い合わせる際に、以下の順序を徹底すること。
import redis
from redis.sentinel import Sentinel
Sentinelのノード情報をリストで渡す
ここで重要なのは、SentinelのIPリストをアプリ側に持たせること
sentinel = Sentinel([(‘sentinel1’, 26379), (‘sentinel2’, 26379), (‘sentinel3’, 26379)], socket_timeout=0.1)
Sentinelに「今のMasterはどこ？」と聞く
アプリはMasterの変更を動的に追従できる
master = sentinel.master_for(‘mymaster’, socket_timeout=0.1)
slave = sentinel.slave_for(‘mymaster’, socket_timeout=0.1)
書き込みはMasterへ
master.set(‘key’, ‘value’)
読み込みはSlaveへ（負荷分散）
print(slave.get(‘key’))
【プロのアドバイス】
クライアントライブラリ側で実装されている「Sentinelの自動検出」を過信してはいけない。アプリのデプロイ時にSentinelのIPが変わるような環境では、コンフィグマップやサービスディスカバリと連動させる設計が不可欠だ。
—
4. 運用上の「死のチェックリスト」
私が障害対応で現場に呼ばれた際、必ず確認する「Sentinelが壊れる理由」を挙げておく。
- 過負荷な監視間隔: `down-after-milliseconds` が短すぎないか？ CPUが高負荷な環境でこれを短くすると、GCの影響だけでフェイルオーバーが走る。少なくとも3000ms（3秒）は持たせるのが堅牢だ。
- Sentinelのメモリ不足: Sentinelプロセス自体は軽量だが、Redisそのもののメモリが枯渇していると、Sentinelが応答できず誤検知を誘発する。
- ネットワークの非対称性: Sentinelの一部だけが他のノードと疎通が悪い環境を作っていないか。これは「幽霊フェイルオーバー（理由のない切り替わり）」の温床だ。
—
最後に：Sentinelは「手段」であって「ゴール」ではない
Sentinelは便利なツールだが、結局のところ「1台のMasterを複数のSlaveでバックアップする」という古いモデルの延長線上にある。
もし君が管理するデータ量がテラバイト級になり、読み書きの負荷が限界突破しつつあるなら、Sentinelのチューニングに時間を費やすよりも、Redis Clusterへの移行を検討する方がエンジニアとしてのROI（投資対効果）は遥かに高い。
Sentinelを語るなら、まずはこの「高可用性の限界」を理解した上で設計テーブルに着くこと。それが、真に現場を任せられるエンジニアの姿だ。
何か技術的な壁に突き当たったら、またいつでも聞いてくれ。レビューはいつでも歓迎する。
コメント