やあ。Redisの世界へようこそ。
Redisを触り始めると、必ず「レプリケーション」という言葉に出会うはずだ。多くのエンジニアはこれを「データのバックアップ」くらいに考えているけれど、それは少しもったいない。
Redisのレプリケーションは、まるで「熟練の師匠（マスター）」と「忠実な弟子（レプリカ）」の阿吽の呼吸のようなものなんだ。今日は、その内部で何が起きているのか、専門用語の壁を崩して紐解いていこう。
—
1. なぜ「弟子（レプリカ）」が必要なのか？
まず、なぜレプリケーションをするのか。理由はシンプルで、「マスター一人に全部任せると、マスターが倒れた瞬間にゲームオーバーだから」だ。
マスターは非常に優秀で、猛烈なスピードで注文（データ）をさばく。でも、もしマスターが急病で倒れたら？ 注文データはすべて消え去ってしまうよね。そこで、マスターの横に「弟子（レプリカ）」を置いて、常にすべての作業を横で見学させ、全く同じメモを取らせておくんだ。
これがRedisの基本構成だ。マスターが倒れても、弟子が即座に「私が引き継ぎます！」と言える状態を作っておく。これがビジネスにおける「可用性」の正体だよ。
—
2. 「PSYNC」：弟子がマスターに弟子入りする瞬間
弟子が初めてマスターの門を叩くとき、あるいは通信が途切れて再会したとき、Redis内部では「PSYNC（パル・シンク）」という会話が行われる。
このプロセスは、日常の事務作業に例えると分かりやすい。
1. 「初めまして、同期させてください」: 弟子が「これまでの全データをください！」とマスターに頼む。
2. 「スナップショットの送付」: マスターは、今現在の全データを圧縮した「スナップショット（RDBファイル）」を弟子に丸ごと渡す。
3. 「差分の追っかけ」: 弟子がスナップショットを読み込んでいる間も、マスターは新しい注文をどんどん受け付けているよね。その「スナップショットを送っている間の差分」を、マスターはバッファ（一時的なメモ帳）に溜めておき、最後に弟子へ渡す。
これで二人は完全に同期する。一度同期が完了すれば、あとはマスターが新しいデータを書くたびに、リアルタイムで弟子に「今の更新、メモっといて」と通知を送るようになるんだ。これを「コマンド伝搬」と呼ぶよ。
—
3. フェイルオーバー：師匠不在の緊急事態
もしマスターが本当に倒れてしまったらどうなるか？ ここで登場するのが「Redis Sentinel（センチネル）」という、いわば「監視員」だ。
1. 監視: センチネルたちは常に「マスター、生きてる？」と問いかけている。
2. 合議制: 一人のセンチネルが「マスター応答なし！」と叫ぶと、他のセンチネルたちも確認し、「確かに倒れたね、これは緊急事態だ」と過半数で合意する。
3. 昇格: センチネルたちは、残った弟子の中から「一番優秀な弟子」を選び出し、新しいマスターに昇格させる。
これらすべてが、人間が介入することなく、わずか数秒のうちに行われる。これがRedisの堅牢さの秘密だよ。
—
4. 知っておくべき「極限の注意点」
最後に、現場のアーキテクトとして一つだけ忠告させてほしい。
「レプリケーションは非同期である」という点だ。
マスターが「書き込み完了！」とクライアントに答えた瞬間、そのデータが即座に弟子にも届いているとは限らない。もし、書き込み直後にマスターが急死し、まだ弟子に同期されていないデータがあった場合、そのデータは消失してしまう。
運用上のヒント：重要なデータなら設定を調整しよう
redis.confの設定例
min-slaves-to-write 1 # 少なくとも1台のレプリカが同期していないと書き込みを拒否する設定
min-slaves-max-lag 10 # 10秒以上遅延しているレプリカがいるなら書き込みを止める
完璧なシステムなんてない。でも、Redisの仕組みを理解していれば、どの程度のリスクを許容して、どこまで安全性を高めるべきか、君自身で判断できるようになるはずだ。
—
まとめ
- マスターとレプリカ: 役割を分担して、データの安全と読み取り性能を確保する。
- PSYNC: 過去の全データ＋その後の差分を効率よく同期する賢い仕組み。
- Sentinel: 師匠が倒れても自動で次代を立てる、頼れる監視員。
ここまで理解できれば、Redisのレプリケーションの心臓部は君の手の内にあると言っても過言じゃない。次は実際に`REPLICAOF`コマンドを叩いて、自分の手で弟子を増やしてみてほしい。
理論を知った上で動かすRedisは、きっと今まで以上に面白い景色を見せてくれるはずだよ。頑張って！
コメント