Redisレプリケーションの深淵：非同期の重力と一貫性の境界線
Redisのレプリケーションを単なる「読み取り負荷分散」や「冗長化」の手段と捉えているのなら、それはあまりに浅い。マスター・スレーブ構成という単純な構造の裏側には、ネットワークの気まぐれとメモリの制約、そして分散システムにおける「一貫性」という名の終わりのない闘争が隠されている。
伝説的なシステムを支えるアーキテクトとして、Redisレプリケーションの内部メカニズムを、ソースコードレベルの解像度で紐解いていこう。
—
1. 物理的な「同期」の真実：PSYNCとレプリケーション・バックログ
Redisのレプリケーションは、かつての`SYNC`コマンドによる全量同期という原始的な時代を過ぎ、現在は`PSYNC`を用いた部分同期が標準だ。
ここで重要なのが、レプリケーション・バックログ（Replication Backlog）の存在である。
/ サーバー内のバックログ構造のイメージ /
typedef struct {
long long offset; / マスターの現在のオフセット /
char buf; / 循環バッファ。スレーブが切断中に失ったデータを保持 /
size_t buf_len;
} replBacklog;
スレーブが切断された際、マスターはバックログ・バッファに書き込みを続ける。再接続時にスレーブが要求するオフセットがこのバッファ内にあれば、全量転送（RDBダンプ）を回避し、不足分だけを高速に埋めることができる。
極限の知見：
多くのエンジニアは`repl-backlog-size`をデフォルトのままで運用するが、大規模トラフィック下ではこれは自殺行為だ。書き込み負荷が高い環境では、バッファがすぐに溢れ、スレーブは「再接続のたびに全量同期（フルリシンク）を繰り返す」という悪夢に陥る。これはマスターのCPUとネットワーク帯域を食いつぶし、最悪の場合、メインスレッドのブロックを引き起こす。バッファサイズは「切断から復帰までの時間 × 書き込みスループット」を考慮し、余裕を持って設計せよ。
2. 非同期転送がもたらす「幽霊データ」の恐怖
Redisのレプリケーションは、非同期（Asynchronous）である。これが意味するのは、マスターへの書き込みが成功した瞬間に、スレーブにそのデータが存在する保証はどこにもないということだ。
アプリケーション層で「書き込んだはずのデータが読み取れない」という事象に直面したとき、それはRedisのバグではない。アーキテクチャの仕様だ。
- WAITコマンドによる同期の強制:
Redisには`WAIT numslaves timeout`という、非同期の壁を越えるためのコマンドが存在する。これは指定した数のスレーブが、指定したオフセットまでデータを適用したことを確認するまで待機する。
1台のスレーブが確実に書き込みを認識するまで待機（タイムアウト1000ms）
WAIT 1 1000
このコマンドは「Redisの速度」と「データの一貫性」のトレードオフを、開発者に選択させるためのインターフェースである。
3. メモリの深淵：フォークとコピー・オン・ライト
フルリシンクが発生する際、マスターは`BGSAVE`を呼び出し、メモリ上のスナップショットを作成する。このとき、OSは`fork()`を実行するわけだが、ここには「コピー・オン・ライト（COW）」の罠がある。
Redisのメモリ使用率が物理メモリの限界に近い状態でフルリシンクが走ると、`fork()`の瞬間、あるいはバックグラウンド保存中にメモリのページ書き換えが発生し、ページテーブルのコピーコストやメモリ不足によるOOM Killerの介入を招く。
熟練の運用プラクティス:
- 物理メモリの余剰: Redisに使用させるメモリは、物理メモリの最大60〜70%に留めるのが定石だ。
- 透明な巨大ページ（THP）の無効化: LinuxのTHPは、`fork()`時のメモリコピーを激しく遅延させる。Redisを動かす環境では、カーネルレベルで必ず無効にせよ。
実行時のカーネル設定確認
cat /sys/kernel/mm/transparent_hugepage/enabled
[always] madvise never -> ‘never’ にすべき
4. アーキテクトへの提言：読み取り負荷分散の幻想
読み取り負荷分散（Read-only Replicas）を目的としてスレーブを増やすのは自由だが、その先には「読み取り一貫性の欠如」という代償があることを忘れてはならない。
私が大規模システムを設計する際、読み取り負荷分散は「最終手段」として扱う。まずはRedisのパイプライニング、クライアントサイドキャッシュ、あるいはデータ構造の最適化でマスター単体（もしくはクラスタ構成）の性能を引き出す。それでもなお限界が見えたとき、初めてレプリケーションによるスケールアウトを検討する。
—
結びに代えて
Redisのレプリケーションは、シンプルゆえに奥が深い。ネットワークの遅延、メモリの断片化、OSのスケジューリング、そしてクライアントの挙動。これらすべてが複雑に絡み合った結果として、システムは稼働している。
「レプリケーションが動いているから安心だ」という言葉を、真のエンジニアは決して口にしない。その裏側で、バッファが溢れていないか、フォークによるレイテンシスパイクが起きていないか、同期の一貫性をどう担保するか。
Redisを極めるとは、こうしたシステム内部の「不可視の挙動」を、脳内で常にシミュレートし続けることに他ならない。さあ、次はあなたの番だ。統計情報を追いかけ、`INFO replication`の数値の向こう側にある真実を読み解いてほしい。
コメント