【実務・中級編】 Redis Sentinelによる高可用性 – Redis

Redis Sentinel：その「自動化」という名の諸刃の剣を使いこなすために

Redisの運用において、Sentinelは「とりあえず入れておけば安心」という免罪符のように扱われがちだ。だが、アーキテクトの視点から言わせれば、Sentinelを正しく理解せずに導入することは、時限爆弾を抱えるのと同義である。

今日は、教科書的な説明をなぞるつもりはない。実務の最前線で、なぜSentinelの挙動が運命を分けるのか。そして、どのような設計が「堅牢な高可用性」を実現するのか。その深淵に触れていく。

—

1. Sentinelは「監視」ではなく「合意」のプロトコルである

多くのエンジニアはSentinelを単なる「死活監視ツール」だと思っている。だが、本質は分散システムにおける「合意形成（Consensus）」だ。

Sentinelは単体で障害を判断しない。複数のSentinelノードが `SDOWN`（主観的ダウン）を検知し、クォーラム（定足数）を経て `ODOWN`（客観的ダウン）へと昇格させ、リーダーを選出する。このプロセスを理解していないと、ネットワーク分断（Split-Brain）が発生した際に、システム全体が崩壊するリスクを負うことになる。

実務上の鉄則：奇数台構成の呪い

Sentinelは最低3ノードで構成せよ。これは定石だが、なぜかを深く考えたことがあるか？ 2ノードでは過半数を取れない。ネットワークが不安定な環境で `quorum` 設定を甘く見積もると、不用意なフェイルオーバーが頻発し、データベースの整合性やパフォーマンスに甚大な悪影響を及ぼす。

—

2. 構成プロバイダーとしてのSentinel：アプリケーション側の設計

Sentinelの最も強力かつ危険な機能が「構成プロバイダー（Configuration Provider）」だ。アプリケーションはマスターのIPを直接叩くのではなく、Sentinelに「今のマスターはどこだ？」と問い合わせる。

悪い例：マスターのIPをハードコードしている
redis.Redis(host=’10.0.0.1′, port=6379)

良い例：Sentinel経由で接続を動的に解決する
from redis.sentinel import Sentinel

Sentinelノードをリスト化し、自動的にマスターを特定させる
sentinel = Sentinel([(‘sentinel1’, 26379), (‘sentinel2’, 26379)], socket_timeout=0.1)

‘mymaster’という名前のグループに対する接続を要求
master = sentinel.master_for(‘mymaster’, socket_timeout=0.1)
master.set(‘key’, ‘value’)

ここでの注意点：
アプリケーション側でSentinel接続のタイムアウト設定を極限までチューニングせよ。デフォルト設定のまま運用すると、マスター切り替え時の数秒間の「無応答」に耐えられず、アプリケーション側でコネクションプールの枯渇を招く。

—

3. 「フェイルオーバー」という名の劇薬

Sentinelはフェイルオーバーを自動で行うが、これが常に正しいとは限らない。

ネットワークの瞬断: 一時的なパケットロスでSentinelが「マスターダウン」と誤認し、不必要なフェイルオーバーを誘発する。
負荷による応答遅延: Redis本体が重いコマンド（`KEYS ` や巨大なデータセットの処理）でブロックされ、Sentinelのハートビートに応答できなくなると、システムは「マスターが死んだ」と判断する。

堅牢な設計へのアプローチ

1. `down-after-milliseconds` の適切な調整: ネットワーク遅延が予想される環境では、この値を安易に短くしてはいけない。逆に長すぎると障害検知が遅れる。トレードオフをビジネス要件と擦り合わせるのだ。
2. `parallel-syncs` の慎重な設定: フェイルオーバー後、新しいマスターにレプリカが再同期をかける際、この値を大きくしすぎると、全レプリカが一斉にフル同期（RDB転送）を開始し、マスターのCPUとI/Oを殺す。

—

4. チーフアーキテクトからの提言：Sentinelを選ぶべきか？

正直に言おう。現代のクラウド環境、特にAWSのElastiCacheやGCPのMemorystoreを使っているなら、マネージドサービスに任せるのが正解だ。

Sentinelの運用は、脳死でできるような簡単なものではない。

Sentinel自体の監視。
フェイルオーバー時のイベントログの追跡。
設定変更の同期（`SENTINEL SET`コマンドの活用）。

これらを自前で完璧に管理できるエンジニアチームがいないのであれば、Sentinelという「複雑なギア」を回すコストは、ビジネスに対するリスクでしかない。

それでも自前で構築する必要があるなら、徹底的なカオスエンジニアリング（障害試験）を行え。本番環境と同じネットワーク帯域で、Sentinelプロセスを落とし、マスターを強制再起動させ、アプリケーションが何秒間停止するかを計測する。それができないなら、高可用性を語る資格はない。

—

まとめ

Sentinelは分散合意プロトコルである。 ネットワークの信頼性を過信するな。
アプリケーションの接続戦略が全て。 コネクションプールの再接続ロジックを磨き込め。
「自動化」は自動的にうまくいくわけではない。 チューニングと検証こそが、真の可用性を生む。

エンジニアよ、ツールに振り回されるな。ツールの挙動を支配し、予測不能な事態を最小化すること。それこそが、我々アーキテクトの仕事だ。