Redisレプリケーションの深淵：単なる「複製」で終わらせないためのアーキテクチャ設計論
Redisのレプリケーションを「マスター・スレーブの同期」と一言で片付けているようでは、本番環境で痛い目を見る。システムがスケールし、トラフィックが急増したとき、その「なんとなく」の理解がボトルネックとなってシステムを崩壊させるからだ。
今日は、Redisのレプリケーションの本質と、実務で絶対に外してはならない「堅牢な設計」について、現場の知見を叩き込む。
—
1. レプリケーションの「仕組み」を見極める
Redisのレプリケーションは、非同期（Asynchronous）であるという大前提を忘れてはならない。マスターに書き込んだデータが、スレーブに到達するまでには必ずタイムラグがある。
非同期複製が意味するもの
- イベントループの最適化: マスターはスレーブからのACKを待たずにクライアントに応答を返すため、低レイテンシを実現できる。
- 一貫性の代償: マスターがクラッシュし、スレーブが昇格する「フェイルオーバー」が発生した際、未同期のデータは永遠にロストする。
エンジニアへの教訓：
「Redisのレプリケーションは、読み取り負荷を分散させるための道具であり、データの完全な保証（強整合性）を求める場所ではない」と理解せよ。もし厳密な整合性が必要なら、それはRedisの責務ではなく、アプリケーション層のロジックで吸収するか、RDBMSを併用すべきだ。
—
2. 現場で「死なない」ための設計パターン
レプリケーション構成を組む際、多くのエンジニアが見落とす「落とし穴」が二つある。
A. レプリケーションラグによる「読み取りミス」の回避
スレーブへの同期が遅延している間、ユーザーは「古いデータ」を読み取ることになる。
- 対策: セッション情報の保持や、特定のキーに対する「直後の読み込み」が必須な場合は、あえてマスターから読み取る戦略（Master-preference）をアプリケーション層で実装しろ。
B. `REPL_BACKLOG` とフル同期の罠
マスターとスレーブの接続が切れた際、再接続時に「部分同期（Partial Resync）」を試みる。このとき、マスター側の `repl-backlog-size` が不足していると、全データが再同期される「フル同期（Full Resync）」が発生する。
- リスク: フル同期には `RDB` ファイルの生成と転送が伴い、マスターのCPUとネットワーク帯域を食いつぶす。
- ベストプラクティス: 書き込み量に合わせてバッファサイズを余裕を持って設計せよ。
redis.conf 設定例
1時間の書き込み量に耐えられるサイズを確保するのがセオリー
repl-backlog-size 256mb
—
3. 高可用性（Sentinel）の勘所
マスターが死んだとき、手動で切り替えるのか？ 否、それは人間がやるべき仕事ではない。`Redis Sentinel` を使った自動フェイルオーバーが必須だ。
設計の鉄則：Sentinelの構成
- 奇数台で配置せよ: 3台または5台のSentinelを配置し、クォーラム（合意形成）を確実にせよ。2台だと「スプリット・ブレイン（脳分離）」のリスクを排除できない。
- クライアントの設計: アプリケーション側は、Sentinelに対して「現在のマスターは誰か」を問い合わせるロジックを持つこと。SDKのSentinel対応機能を正しく理解して実装しろ。
—
4. パフォーマンスを殺さないための「禁じ手」
実務で私が最も警告したいのは、「スレーブの過剰な負荷」だ。
- KEYS や SCAN の実行: スレーブで重いコマンドを実行すれば、レプリケーションのパイプラインがブロックされ、同期が遅延する。スレーブは「読み取り専用」として扱い、分析処理や重いクエリは別のRead Replicaに対して行え。
- 大容量RDBの副作用: レプリケーションの初期化時に発生するRDB生成は、メモリを倍近く消費する可能性がある。ピーク時にこの負荷が走れば、マスターのメモリ不足（OOM）を誘発し、最悪の場合プロセスがキルされる。
—
まとめ：アーキテクトからの提言
Redisのレプリケーションは、魔法ではない。「速度と引き換えに、整合性と可用性のトレードオフをどうコントロールするか」という高度なエンジニアリングの戦場だ。
1. 非同期である事実を設計の前提に組み込め。
2. `repl-backlog` のチューニングを怠るな。
3. フェイルオーバーの自動化をSentinelで完結させろ。
技術に振り回されるな。技術を制御し、システム全体の堅牢性を担保するのがエンジニアの仕事だ。今日から、君たちの設計を見直してみろ。より鋭く、より強固なインフラが作れるはずだ。
何か具体的に詰まっている構成があるなら、コードを持ってこい。レビューしてやろう。
コメント