Redisレプリケーションの深淵：PSYNCが支える「止まらないシステム」の設計思想
Redisを単なる「高速なKVS」と捉えているなら、それは非常にもったいない。真のアーキテクトにとって、Redisは「一貫性と可用性の綱渡りを、いかにエレガントに自動化するか」という課題を突きつけてくる存在だ。
今回は、Redisの心臓部の一つである「レプリケーション同期プロセス（SYNC/PSYNC）」について、教科書には載っていない「実務の現場で必ず直面する罠」と共に深掘りしていく。
—
1. 概念の再定義：SYNCからPSYNCへの進化
レプリケーションとは、単なるデータのコピーではない。それは、マスターのタイムラインをレプリカがいかにして「追随し続けるか」という同期問題だ。
- SYNC (Legacy): レプリカが切断されるたびに、マスターはRDBスナップショットを生成し、全データを転送する。これはI/Oとメモリを食いつぶす「重罪」に近い処理だ。
- PSYNC (Partial Sync): Redis 2.8以降の標準。マスターとレプリカ間で「オフセット」を交換し、欠損分だけを補完する。
ここで重要なのは「レプリケーションバッファ（Replication Buffer）」の存在だ。
マスターは、レプリカへ送信すべき命令をメモリ上のリングバッファに保持する。もし、ネットワークの瞬断がこのバッファのサイズを超えて長引けば、PSYNCは失敗し、強制的にフル同期（Full Resync）へフォールバックする。これが大規模システムにおける「予期せぬレイテンシスパイク」の最大の要因だ。
—
2. 実務で必ず陥る「フル同期の罠」と対策
「なぜか夜間にRedisの負荷が跳ね上がる」。この原因の9割は、レプリケーションバッファの溢れによるフル同期の連鎖だ。
設計上の鉄則：`client-output-buffer-limit` を制する
デフォルト設定のまま運用するのは、高速道路を軽自動車で走るようなものだ。以下の設定を吟味せよ。
レプリカ用のバッファ制限設定例
client-output-buffer-limit replica
client-output-buffer-limit replica 512mb 128mb 60
- hard limit: これを超えたら即時切断。
- soft limit & seconds: この値を一定時間超え続けたら切断。
アーキテクトからの助言:
書き込み負荷が高いシステムでは、このバッファを余裕を持って設計せよ。さもなくば、マスターがRDB生成（BGSAVE）のためにCPUとメモリを奪われ、その結果としてアプリケーション全体の応答速度が低下する「共倒れ」が発生する。
—
3. レプリケーションの整合性：オフセットの真実
Redisのレプリケーションは「非同期」が原則だ。そのため、`WAIT`コマンドを知らないエンジニアは、分散システムの設計として失格である。
書き込みが最低1台のレプリカに同期されるまで待機する
タイムバックは1000ms
WAIT 1 1000
これはRDBMSで言うところの「準同期レプリケーション」に近い。「データのロストは絶対に許されないが、性能もギリギリまで追求したい」という要件に対する、Redisが用意した洗練された回答がこの `WAIT` コマンドだ。
—
4. 堅牢なシステムを構築するための「設計パターン」
現場のテクニカルリードとして、以下の3点を徹底することを推奨する。
1. レプリカの多段構成を避ける:
レプリカがレプリカから同期を取る構成は、障害ポイントが増えるだけだ。可能な限り「マスター → 複数レプリカ」のスター型トポロジを維持せよ。
2. `repl-backlog-size` の適正化:
フル同期を極力避けるためには、以下の計算式でバックログサイズを確保せよ。
`（書き込み秒間平均TPS × レプリカが復帰するまでの予測時間）`
これを下回る設定は「いつか必ずフル同期で落ちる」という爆弾を抱えているに等しい。
3. 監視の解像度を上げる:
`INFO replication` を定期的に監視し、`master_repl_offset` の進捗と、`connected_slaves` の数を追うこと。特に `repl_backlog_first_byte_offset` との乖離をメトリクス化し、バッファが逼迫し始めたらアラートを飛ばす体制を構築せよ。
—
最後に：エンジニアへのメッセージ
Redisのレプリケーションを理解するということは、「ネットワークの非信頼性」と「メモリの有限性」という制約の中で、いかにして一貫性を保証するかというパズルを解くことに他ならない。
技術ドキュメントに書かれた設定値を鵜呑みにするな。君たちが運用しているシステムのトラフィックパターンこそが、Redisの正しい設定を導き出す唯一のソースだ。
何か問題が起きたとき、「Redisが悪い」と言う前に、自身の設計したバッファサイズと、アプリケーションの書き込み特性を見直してほしい。Redisは、正しく理解し、愛を持って接するエンジニアに対して、期待以上のパフォーマンスで応えてくれるはずだ。
さあ、次は君たちのシステムで、この深い同期の仕組みを最適化してみせよ。
コメント