Redisレプリケーションの深淵：PSYNCから紐解く分散整合性の極致
Redisのレプリケーションを単なる「データのコピー」と捉えているなら、それは大規模システムにおける致命的な誤解だ。我々アーキテクトにとって、レプリケーションとは「時間と空間の不整合を、いかに低遅延かつ非同期に収束させるか」という数学的挑戦に他ならない。
今回は、Redisの心臓部であるレプリケーションプロトコル「PSYNC」を中心に、その内部で何が起きているのか、限界まで解剖する。
—
1. 複製トポロジの真実：非同期という名の妥協
Redisのレプリケーションは、デフォルトで非同期（Asynchronous）だ。マスターが更新をコミットした瞬間、レプリカが追従している保証はどこにもない。
この設計の核心は「パフォーマンスの極大化」にある。強整合性を求めればネットワークRRTの呪縛に囚われ、Redisの生存意義であるマイクロ秒レベルのレイテンシは崩壊する。このトレードオフを理解した上で、いかに「耐故障性」を担保するかがアーキテクトの腕の見せ所だ。
2. PSYNCプロトコルの解体：なぜ「再接続」は賢いのか
かつて、ネットワークの瞬断はレプリケーションの全面的な再同期（Full Resync）を意味し、巨大なRDB（Redis Database）ファイルの転送によるI/O負荷とメモリのスパイクを引き起こしていた。
しかし、`PSYNC`（Partial Resync）の導入により、この悪夢は過去のものとなった。
内部メカニズムの鍵：レプリケーション・バッファ
マスターはメモリ上に「レプリケーション・バックログ（Replication Backlog）」と呼ばれる循環バッファを維持する。
- オフセット（Offset）: マスターが書き込みを行うたびにインクリメントされる単調増加するカウンタ。
- レプリケーションID: インスタンスを識別する一意のID。
レプリカが再接続を試みる際、`PSYNC
知見： このバックログサイズが小さいと、ネットワークの瞬断で即座にFull Resyncへフォールバックする。大規模環境では `repl-backlog-size` を、想定される停止時間と書き込み量から厳密に計算してチューニングせよ。
3. Full Resyncの代償：メモリとI/Oのボトルネック
Full Resyncが必要になった際、マスターはバックグラウンドで `BGSAVE` を実行し、RDBファイルを生成する。ここで注意すべきは以下の2点だ。
1. COW (Copy-On-Write) の罠: `fork()` によるメモリのコピーオンライトが発生する際、大量の書き込みがある環境では物理メモリの消費が急増し、OSのページテーブル更新負荷がCPUを食いつぶす。
2. ディスクI/Oの飽和: RDBの書き出しとネットワークへの転送が同時発生することで、ディスクI/Oが競合する。NVMe SSDへの移行はもはや必須の要件と言える。
4. フェイルオーバーの「不確定性」とSentinelの役割
Redis Sentinelは、マスターの死を検知し、レプリカを昇格させるオーケストレーターだ。だが、ここには「スプリットブレイン」のリスクが常に潜んでいる。
Sentinelがマスターのダウンを検知した際、以下のプロセスが走る。
1. 主観的ダウン (SDOWN): 監視ノードが応答なしと判定。
2. 客観的ダウン (ODOWN): quorum（定足数）に達したことを確認。
3. 選挙: 新たなリーダー選出。
アーキテクトの警告: Sentinelによる自動フェイルオーバーは、ネットワークパーティション環境下では非常に脆弱だ。特に「どのレプリカをマスターに昇格させるか」の優先順位（`replica-priority`）を適切に設定し、データ損失を最小化する戦略を練る必要がある。
—
5. 極限のチューニング：知っておくべき「現場の定石」
最後に、実務レベルで差が出る設定の勘所を記す。
レプリケーションバックログをメモリ上に確保するサイズ（要計算）
大規模環境ではデフォルトの1MBでは即座にFull Resyncへ移行する
repl-backlog-size 128mb
レプリカがマスターから切断された際、古いデータでも読み取りを許可するか
高可用性より整合性優先なら ‘no’ にする
replica-serve-stale-data no
レプリカ側の書き込みを禁止し、読み取り専用のノードとして厳格に管理する
replica-read-only yes
結び
Redisのレプリケーションを理解することは、分散システムにおける「データがどこへ移動し、いかにして消失するリスクを回避するか」のシミュレーションを行うことと同義である。
仕様書の表面をなぞるな。PSYNCのオフセットが何を意味し、RDBの生成がシステムのどのレイヤに負荷をかけているのか。そこまで解像度を高めたとき、初めてあなたは「Redisを使いこなしている」と言えるだろう。
次回の記事では、`Redis Cluster` におけるハッシュスロットの再配置（Resharding）と、その最中に発生するリクエストのルーティング制御について深掘りする。期待していてほしい。
コメント