Redisの深淵：Master-Replicaレプリケーションの物理と論理
Redisのレプリケーションを「単なるデータのコピー」と考えているなら、それはアーキテクトとしての視座が甘いと言わざるを得ない。
Redisのレプリケーションは、シングルスレッドのイベントループという制約の中で、いかに非同期性を担保し、かつメモリオーバーヘッドを最小化するかという、エンジニアリングの極致が詰まったメカニズムだ。今回は、ドキュメントの表面をなぞるような解説はしない。Redisの内部構造を理解し、運用で死線を潜り抜けてきた者だけが意識すべき「深淵」に光を当てる。
—
1. 非同期レプリケーションの「痛み」を知る
Redisのレプリケーションは、デフォルトで非同期だ。これは「パフォーマンスのために整合性を犠牲にしている」というトレードオフを意味する。
PSYNCの裏側：Replication BufferとBacklog
マスターはクライアントからの書き込み命令を、自身のメモリ内にある`replication buffer`と、`repl-backlog-buffer`に書き込む。
- Replication Buffer: 接続中のレプリカごとに確保される。ここが溢れると、レプリカとの接続は強制切断される。高負荷時のスパイクでレプリカが脱落するのは、多くの場合ここがメモリ限界に達するからだ。
- Repl-Backlog-Buffer: 循環バッファであり、部分同期（Partial Resynchronization）の生命線となる。このサイズ設計を誤ると、ネットワークの微小な瞬断のたびに「フル再同期（RDB転送）」が発生し、マスターのCPUとメモリを殺すことになる。
教訓: `repl-backlog-size`は、秒間書き込み量 × 復旧までの想定時間 を元に算出せよ。ケチる場所ではない。
—
2. フル同期（Full Resync）の物理的コスト
`REPLICAOF`コマンドが発行され、部分同期が不可能な場合、RedisはRDBファイルを生成して転送する。ここで発生する「極限のオーバーヘッド」を理解しているか？
1. フォークのコスト: `fork()`によるCopy-on-Write（CoW）が発生する。メモリが巨大な場合、ページテーブルのコピーだけで数ミリ秒〜数十ミリ秒のブロッキングが発生し、その間Redisのイベントループは停止する。
2. ディスクI/Oの飽和: RDB生成時のシリアライズは、メモリ帯域とディスク帯域を同時に消費する。
3. ソケット転送: レプリカへデータを送る際、Redisはカーネルの`sendfile()`を叩くが、ネットワーク帯域がボトルネックになれば、マスター側のバッファが肥大化し、メモリプレッシャーを引き起こす。
大規模インスタンスでは、`repl-diskless-sync yes`を検討すべきだ。ディスクを介さずネットワークソケットに直接ストリーミングすることで、I/O待ちを排除できる。ただし、ネットワーク帯域が「安定して」ボトルネックにならない環境であることが前提だ。
—
3. レプリケーションの最適化：アーキテクトの視点
実務において、レプリケーションの安定性を最大化するための極意を伝授する。
A. Replication ID と Offset の意味
Redisは `Run ID` (Replication ID) と `Offset` を用いて同期点を管理している。
マスター側で確認
INFO replication
master_replid: 8b1f…
master_repl_offset: 123456789
このOffsetがレプリカ間で食い違うことは、単なる整合性の欠如ではなく、システム設計の破綻を意味する。`WAIT`コマンドを適切に利用し、同期レプリケーションをエミュレートする設計も検討すべきだ。
B. メモリプレッシャーの制御
レプリカへのデータ転送は、`client-output-buffer-limit slave` で制御される。
限界値の設計
256MB連続、あるいは64MBかつ60秒継続で切断する設定例
client-output-buffer-limit slave 256mb 64mb 60
高負荷時、このバッファが肥大化すると、Redisの全メモリ使用量がEviction（キーの追い出し）を引き起こすトリガーになる。レプリカの台数が多いほど、マスターのメモリ消費は跳ね上がるという事実を忘れてはならない。
—
4. 最後に：伝説のエンジニアとして
Redisのレプリケーションは、魔法ではない。極めて論理的で、冷徹なデータパイプラインだ。
- 「なぜレプリカが頻繁にフル同期するのか？」
- 「なぜマスターのCPU負荷が急騰するのか？」
これらの問いに対する答えは、`INFO`コマンドが吐き出す統計情報の「行間」に隠されている。ドキュメントに書かれたコマンドを叩くだけでは、いつか必ず大規模トラフィックの洗礼を受けてシステムは崩壊する。
アーキテクトである君たちがやるべきことは、「ネットワークの遅延」「プロセスのフォーク時間」「Repl-Backlogの枯渇速度」を定数ではなく変数として捉え、システム全体をオーケストレーションすることだ。
Redisは、その複雑さを隠蔽してくれるほど親切ではない。だからこそ、使いこなした時の圧倒的なパフォーマンスは、他の追随を許さないのだ。健闘を祈る。
コメント