Redisレプリケーションの深淵：非同期の「危うさ」とアーキテクチャの真実
Redisのレプリケーションを単なる「データのコピー機能」だと思っているなら、今すぐその認識を改めるべきだ。
大規模システムにおいて、RedisのMaster-Replica構成は「可用性のための安全装置」であると同時に、設計を誤れば「データ損失の温床」にもなり得る諸刃の剣だ。今日は、ドキュメントの表面をなぞるような話はしない。現場で戦うエンジニアが、システム設計の要諦として押さえるべき「レプリケーションの心臓部」について語ろう。
—
1. 物理層：非同期レプリケーションという「妥協」
Redisのレプリケーションは、デフォルトで非同期（Asynchronous）だ。これは何を意味するか。Masterが書き込みを受け付けた瞬間、そのデータがReplicaに届く保証はどこにもない。
内部的には、Masterはコマンドを実行した後、Replicaに対してコマンドストリームを送信する。だが、その完了を待たずにクライアントに「OK」を返す。これが驚異的な低レイテンシを実現している理由だが、同時に「ネットワーク切断やMasterのクラッシュ時に、書き込んだはずのデータがReplicaに到達していない可能性がある」という残酷な事実を突きつける。
知っておくべき「データ損失の境界線」
- Partial Resynchronization (PSYNC): 接続断が短時間であれば、Backlogバッファを活用して差分のみを再送する。これは極めて優秀だ。
- Full Resynchronization: バッファから溢れるほどの長時間離脱や、マスターのID変更が発生した場合、RDBスナップショットの転送からやり直す。これが発生すると、MasterのCPUとI/Oに強烈な負荷がかかる。
—
2. 構築と運用：REPLICAOFコマンドの作法
現代のRedisでは `SLAVEOF` ではなく `REPLICAOF` を使う。これは単なる命名変更ではない。Redisが「Master-Slave」という旧来の呼称から脱却したという設計思想の表れだ。
実践的な構築コード
動的にレプリケーションを構築するのは非常にシンプルだ。
特定のノードをReplicaとしてMasterへ追従させる
127.0.0.1:6379 のマスターに対して追従を開始
REPLICAOF 127.0.0.1 6379
もしこのノードをスタンドアローンに戻したいなら
REPLICAOF NO ONE
設計上の鉄則:
手動で `REPLICAOF` を叩いて運用する時代は終わった。実戦では必ず Redis Sentinel または Redis Cluster を導入せよ。手動の切り替えはヒューマンエラーを誘発する最大の要因だ。
—
3. パフォーマンスと堅牢性のトレードオフ
エンジニアが最も避けるべきは、「レプリケーションラグ（遅延）」を無視した設計だ。
監視の最前線
Replicaがどれだけ遅れているかは、`INFO replication` で確認できる。
- `master_repl_offset`: Masterが到達しているオフセット
- `slave_repl_offset`: Replicaが反映したオフセット
この差分（バイト数）が拡大し続けている場合、ネットワーク帯域の枯渇か、Masterの書き込み負荷が大きすぎて、Replicaのシングルスレッド処理能力を超えている証拠だ。
堅牢性を高めるための「WAIT」コマンド
どうしてもデータ損失を許容できないトランザクションがある場合、`WAIT` コマンドが最後の砦になる。
1台のReplicaがデータを同期完了するまで、最大1000ミリ秒待機する
返り値は同期できたReplicaの数
WAIT 1 1000
これを使えば、非同期レプリケーションを「擬似的な同期レプリケーション」に変換できる。ただし、当然ながら書き込みレイテンシは増大する。どこまで性能を犠牲にし、どこから整合性を守るか。このトレードオフを判断することこそが、我々エンジニアの仕事だ。
—
4. チーフアーキテクトからの助言
最後に、設計レビューで私が必ず確認するポイントを授ける。
1. Replicaは「読み取り専用」と割り切る:
Replicaに書き込みを行うな。論理的には可能だが、後で必ず整合性の地獄を見る。
2. RDBスナップショットの頻度を設計せよ:
Full Resyncが発生した際、MasterはRDBを作成して転送する。この時、MasterのメモリがRDB作成のために一時的に不足し、OSのOOM Killerに殺される事故が多発する。Masterのメモリには常に十分な余裕（最低でもRDB作成時のメモリコピー分）を持たせるのが定石だ。
3. レプリケーションの「連鎖」を避ける:
A→B→C というカスケード構成は、ネットワーク障害時の復旧難易度を跳ね上げる。可能な限り Star型（Masterを中央に、Replicaを周囲に配置）のトポロジーを採用せよ。
Redisは極めてシンプルだが、そのシンプルさゆえに、運用者の理解度がそのままシステムの信頼性に直結する。非同期の性質を理解し、障害を前提とした設計を組み込むこと。それができて初めて、君はRedisを「使いこなしている」と言えるのだ。
さあ、コードに戻って、このアーキテクチャを君のプロダクトに正しく実装してくれ。期待している。
コメント