Redisレプリケーションの深淵：可用性と整合性の狭間で「勝てる」設計をせよ
Redisは「単なるKVS」ではない。メモリという爆速な砂場に、いかにして堅牢なデータ構造を構築し、システム全体の信頼性を担保するか。それがエンジニアとしての腕の見せ所だ。
今回は、Redisアーキテクチャの根幹である「レプリケーション」について、教科書的な説明は最小限に留め、現場で数多の障害を乗り越えてきた者だけが知る「真の設計論」を叩き込む。
—
1. レプリケーションの本質：なぜ「非同期」なのか
Redisのレプリケーションは、原則として非同期（Asynchronous）だ。これが何を意味するか理解しているか？
マスターが書き込みを受け付けた直後にクライアントへ「OK」を返すと同時に、レプリカへ伝搬が走る。つまり、マスターが倒れた瞬間、伝搬されなかったデータは物理的に消失する。
- 設計指針: 「全データの整合性」がビジネス的に許容できない（例：決済データ）のであれば、Redis単体で解決しようとせず、必ずRDBMSとの併用を検討せよ。Redisはあくまで「極速の層」であり、永続性と整合性は別のレイヤーで担保するのが鉄則だ。
—
2. PSYNCの深層：再同期の魔術と落とし穴
Redis 2.8から導入された`PSYNC`コマンドは、まさにレプリケーションの心臓部だ。フル同期（RDB転送）は重い。それを避けるための「部分再同期」のメカニズムを正しく理解せよ。
PSYNCの裏側
1. レプリケーションIDとオフセット: マスターとレプリカは、共通の「ID」と「現在の書き込み位置（オフセット）」を共有する。
2. バックログバッファ（Replication Backlog）: マスターは、過去の書き込み履歴を一定量保持している。切断が発生しても、バッファにオフセットが残っていれば、差分のみを再送する。
【現場の知見：バックログのサイジング】
デフォルト設定のまま運用していると、ネットワークの瞬断や重い負荷時に、バックログが溢れて強制的に「フル再同期（Full Resync）」が発生する。これはマスターのCPUとメモリを食いつぶす悪夢だ。
- 対策: `repl-backlog-size`は、予想される切断時間中に発生する書き込み量を余裕を持ってカバーできるよう設計せよ。迷ったら大きく取れ。メモリは買うよりも、落ちた時の復旧コストの方が遥かに高い。
—
3. レプリカの昇格（Failover）の勘所
マスターが死んだとき、誰がレプリカをマスターに昇格させるか。これを手動でやるのは運用失敗のサインだ。
堅牢な設計パターン：Sentinel vs Cluster
- Redis Sentinel: 監視と自動フェイルオーバーの標準。シンプルだが、大規模な構成ではクライアント側の接続ハンドリングが煩雑になる。
- Redis Cluster: データをシャーディング（分割）して管理する。ノード数が増えた時のスケールアウト性能は圧倒的だが、設計の難易度は上がる。
【設計レビューの鉄則】
「自動フェイルオーバーがあるから安心」などと考えるな。フェイルオーバーは、発生時に「確実にサービスを継続できるか」の検証がすべてだ。
- 検証項目:
- `min-slaves-to-write`: マスターが最低限N台のレプリカと疎通できていない場合、書き込みを拒否する設定。これを入れていないと、ネットワーク分断時に「スプリット・ブレイン」が発生し、データが破壊される。
—
4. パフォーマンスを殺す「暗黙の罠」
レプリケーションを有効にしている際、以下の点に注意を払わないエンジニアは、本番環境で確実に痛い目を見る。
A. RDB生成のCPU負荷
フル同期の際、マスターはバックグラウンドでRDBファイルを作成する。この時、親プロセスはフォークするが、メモリ量が多いとフォークのタイミングでシステムが数ミリ秒〜数十ミリ秒停止（Stop-the-world）する可能性がある。
- 対策: `repl-diskless-sync yes`を検討せよ。ディスクを経由せず、メモリから直接ソケットへ流し込むことで、ディスクI/Oのボトルネックを排除できる。
B. レプリケーション遅延の可視化
`INFO replication`コマンドで常に`master_link_down_since_seconds`や`slave_repl_offset`を監視せよ。レプリカがマスターから遅延している状態は、それは「レプリカが死んでいるのと同義」だ。
—
結び：技術は「トレードオフの最適化」である
Redisのレプリケーションを設計するということは、「どこまでリスクを許容するか」を定義することに他ならない。
- 完全に整合性を取るならパフォーマンスを犠牲にし、同期レプリケーションに寄せる。
- 爆速を求めるなら、非同期の限界を理解し、データ喪失時のリカバリ手順を自動化する。
どちらが良いかではない。「自分のシステムが何を最も大切にしているか」を考え抜いた設計こそが、世界最高峰のアーキテクチャへの第一歩だ。
コードを書くだけなら誰でもできる。だが、「落ちないシステム、そして落ちても瞬時に立ち上がるシステム」を設計できるエンジニアになれ。現場からは以上だ。
コメント