こんにちは！今日も一緒に技術の深掘りをしていきましょう。あなたの頼れる先輩エンジニアです。
インメモリデータベースの代表格である Redis（レディス） は、その圧倒的な速さから多くのシステムで採用されています。実務で使うようになると必ず出会うのが、データを安全に保持したり読み込み処理を分散したりする「レプリケーション（複製）」という仕組みです。
そして、レプリケーションを運用する上で絶対に避けて通れないのが「通信トラブル」です。
インターネットの世界では、ほんの一瞬だけネットワークが途切れることは日常茶飯事です。そのときRedisの裏側で何が起きているのか？ どうやって素早く元の安全な状態に戻るのか？
今回は、Redisが誇る賢いリカバリー機能「部分再同期（Partial Resynchronization）」と、その運命を握る`repl-backlog-size`という設定について、日常の出来事に例えながら世界一わかりやすく解説しますね。
ここをクリアすれば、Redisの基本と運用のコツはバッチリマスターできますよ！
—
1. そもそも「レプリケーション」ってなんだっけ？
解説に入る前に、イメージを揃えておきましょう。
Redisのレプリケーションは、「メインで働く親機（マスター）」のデータを、「控えの小僧である子機（レプリカ）」にリアルタイムでコピーし続ける仕組みです。
これを日常のシチュエーションに例えてみましょう。
- マスター（親機）： 現場でどんどん指示を出す「熱血ベテラン上司」
- レプリカ（子機）： 上司の発言を横でカタカタとメモ帳に書き留める「新人アシスタント」
上司が「Aさんのデータを更新！」「Bさんのデータを削除！」と言うたびに、アシスタントは自分のメモ帳に同じ内容を書き込みます。こうすることで、上司に万が一のことがあっても、アシスタントのメモを見れば続きから仕事を再開できるわけです。
—
2. 通信が切れた！昔のRedisと今のRedis
では、もし「アシスタントがトイレに行っていて、5分間上司の指示を聞き逃した」としたらどうなるでしょうか？ これが「ネットワーク切断」の状態です。
戻ってきたアシスタントは、聞き逃した5分間のデータを取り戻さなければなりません。ここで同期のやり方が2種類登場します。
❌ 昔のやり方：全再同期（Full Resynchronization）
「すみません！席を外していたので、上司のこれまでの人生の全記録（全データ）を最初から全部書き写させてください！」
……これ、ものすごく大変ですよね？ 上司は自分の全データをファイルに書き出すために膨大なエネルギーを使い、アシスタントもそれを全部もらうためにネットワークを圧迫します。これを専門用語で全再同期（フルシンク）と呼びます。データ量が何十ギガもある場合、システム全体が悲鳴を上げてしまいます。
⭕️ 今の賢いやり方：部分再同期（Partial Resynchronization）
「すみません！10:00から10:05までの5分間の指示だけ、もう一度教えてもらえますか？」
これなら一瞬で追いつけますよね！ この「抜けていた差分だけをスマートに埋める仕組み」こそが、今回のテーマである部分再同期（Partial Resynchronization / パワーアップしたPSYNCコマンド）です。
—
3. 秘密兵器「レプリケーション・バックログ」とは？
「ちょっと待って、上司（マスター）はどうやって『5分間に何を指示したか』を覚えているの？」と思いましたよね。素晴らしい着眼点です！
上司はデスクの片隅に「直近の指示をメモしておくホワイトボード」を持っています。Redisではこれをレプリケーション・バックログ（Replication Backlog）と呼びます。
【上司のデスクのホワイトボード（レプリケーション・バックログ）】
———————————————————
[過去の指示] -> [指示101] -> [指示102] -> [指示103] -> (最新)
———————————————————
※ホワイトボードのサイズ（repl-backlog-size）には限りがある！
上司は指示を出しながら、このホワイトボードにもコソッと書き残しています。
アシスタントが戻ってきたら、こう会話します。
- アシスタント：「私、指示100番まで持ってます！続きをください！」
- 上司：「OK、ホワイトボードを見るね。あ、101番から103番が残ってるよ。この差分だけ持っていきなさい！」
これで無事に「部分再同期」が成功します！
—
4. 設定のキモ！`repl-backlog-size` が超重要な理由
ここで一番大切な設定パラメーター `repl-backlog-size` の登場です。
ホワイトボード（バックログ）の広さには限りがあります。古い指示はどんどん消され、新しい指示で上書きされていく「リングバッファ」という構造になっています。
もし、ネットワークが10分間切れていて、アシスタントが戻ってきたときに「ホワイトボードから古い指示がすでに消されていた」としたら……？
- アシスタント：「私、指示50番まで持ってます！」
- 上司：「ごめん！ホワイトボードが狭くて、今は100番以降の指示しか残ってないや……諦めて全再同期（最初から全部やり直し）しよう！」
ガーン！ せっかく部分再同期の仕組みがあるのに、ホワイトボードが小さすぎたせいで、地獄の全再同期に逆戻りしてしまいました。
だからこそ、インフラエンジニアは「ネットワークが一時的に切れても、差分が消えない十分な広さのホワイトボード」を確保するために、`repl-backlog-size` を適切に設定する必要があるのです。
—
5. 実際の設定ファイルとコマンドを見てみよう！
難しく考える必要はありません。Redisの設定ファイル（`redis.conf`）に数行書くだけです。
設定例（redis.conf）
——————————————————————
レプリケーション・バックログの設定
——————————————————————
バックログ（ホワイトボード）のサイズを指定します。
デフォルトは 1mb ですが、書き込みが多い環境では大きめに確保します。
repl-backlog-size 64mb
子機（レプリカ）が1台もいなくなってから、
バックログのメモリを解放するまでの時間（秒）です。
0にすると、どれだけ時間が経ってもバックログを保持し続けます。
repl-backlog-ttl 3600
> 💡 先輩のアドバイス：
> サイズの目安は `(1秒あたりの書き込みデータ量) × (許容したい通信切断の時間秒数)` です。
> 例えば、1秒に1MBの書き込みがあり、60秒間のネットワーク瞬断に耐えたいなら `64mb` 程度積んでおくと安心ですね！
ステータスを確認してみよう（INFO replication）
Redisにログインして `INFO replication` コマンドを打つと、ホワイトボードの状態がひと目でわかります。
127.0.0.1:6379> INFO replication
Replication
role:master
connected_slaves:1
slave0:ip=192.168.1.20,port=6379,state=online,offset=1405,lag=0
— ここからがバックログ情報 —
repl_backlog_active:1 # 1ならバックログ機能が有効
repl_backlog_size:67108864 # ホワイトボードのサイズ（64MB）
repl_backlog_first_byte_offset:1 # ホワイトボードに残っている一番古いデータの位置
repl_backlog_histlen:1405 # 今ホワイトボードに溜まっているデータのバイト数
アシスタント（レプリカ）が戻ってきた時、自分が持っている最後の位置（offset）が、この `repl_backlog_first_byte_offset` より新しければ、見事部分再同期が成功します！
—
まとめ：本日のチェックポイント
1. 部分再同期（PSYNC）は、通信が切れたときに「差分だけ」を素早く復旧させる賢い仕組み。
2. 差分を一時的に保存しておく場所をレプリケーション・バックログと呼ぶ。
3. `repl-backlog-size` が小さすぎると、差分が溢れて重たい「全再同期」になってしまう。
4. システムの書き込み量とネットワークの安定性に合わせて、バックログサイズを広めに設定しておくのがプロの技！
仕組みさえ分かってしまえば、全く怖くないでしょう？
Redisの高可用性（落ちないシステム作り）は、こうした「一瞬のトラブルへの配慮」の積み重ねで成り立っています。この感覚が掴めれば、あなたのRedis知識はもう初心者レベルを完全に脱出していますよ。
自信を持って、次のステップへ進んでいきましょう！応援しています！
コメント