【入門編】 Redisレプリケーションの基本概念 – Redis

こんにちは。数々の巨大なシステムを設計し、Redisの深淵を見てきたチーフアーキテクトです。

今日は、Redisを学び始めたばかりのあなたに、Redisがなぜこれほどまでに速く、そして信頼されているのか、その心臓部とも言える「レプリケーション（複製）」の仕組みについてお話ししましょう。

難しい用語は一旦脇に置いておいて、まずはイメージから入っていきましょう。ここをマスターすれば、あなたはもう立派なRedis使いへの第一歩を踏み出したことになりますよ。

—

Redisの世界には、「マスター（主人）」と「レプリカ（複製）」という役割分担があります。

これを、「超一流のシェフ」と「見習い料理人たち」の関係に例えてみましょう。

なぜ、わざわざ見習い（レプリカ）を用意するのでしょうか？
それは、シェフ一人が「料理（書き込み）」も「配膳（読み取り）」もすべてこなそうとすると、お店が大繁盛した時にパンクしてしまうからです。

「書き込みはマスター、読み取りはレプリカ」。これがRedisを高速に保つための黄金ルールです。

—

Redisのレプリケーションで最も特徴的なのが、「非同期（ひどうき）」という仕組みです。

普通、誰かに伝言をお願いするとき、相手が「分かった！」と返事をするまで待ちますよね？でも、Redisのマスターは待ちません。

マスターはデータを自分の中に書き込んだ瞬間、レプリカに「これ、写しておいてね！」とメモを投げて、相手の返事を待たずに次のお客さんの注文を受けに行きます。

これがRedisが爆速である理由です。

これを専門用語で「最終的な一貫性（Eventual Consistency）」と呼びますが、日常の感覚で言えば、「テレビの生放送と、手元のスマホの速報にわずかなズレがある」ようなものだと考えてください。

—

さて、レプリカを増やすと何が良いのでしょうか？

例えば、1秒間に10万回も「データを見せて！」というリクエストが来たとしましょう。一人のマスターでは倒れてしまいますが、レプリカが4台いれば、1台あたり2.5万回ずつ分担できます。

これを「読み取り負荷分散（リード・スケーラビリティ）」と言います。

レプリカは「読み取り専用」にするのが一般的です。見習い勝手にレシピを書き換えてしまったら、お店の中がめちゃくちゃになってしまいますからね。

—

「でも、設定が難しいんでしょ？」と思うかもしれません。いえ、Redisは驚くほどシンプルです。

例えば、新しいRedisを「レプリカ」として起動して、マスター（192.168.1.100）の弟子にするには、コマンドを一行打つだけです。

レプリカ側のRedisでこのコマンドを打つだけ！
「今日から私は、あのマスターの弟子になります」という宣言です。
REPLICAOF 192.168.1.100 6379

設定ファイル（redis.conf）に書くなら、こうです。

誰の弟子になるかを指定
replicaof 192.168.1.100 6379

レプリカは読み取り専用にする（これが鉄則！）
replica-read-only yes

これだけで、マスターに書き込まれたデータが、魔法のようにリアルタイムでレプリカへとコピーされ始めます。

—

ここまでの話をまとめましょう。

1. マスターは「書き込み」、レプリカは「読み取り」を担当する。
2. 「非同期」だから、マスターはレプリカを待たずに爆走できる。
3. レプリカを増やせば増やすほど、たくさんの「読み取り」リクエストをさばけるようになる。

もし、あなたが作っているアプリが「書き込みはたまにだけど、読み取りはめちゃくちゃ多い」という性質なら、このマスター・レプリカ構成は最強の武器になります。

「データが一瞬だけズレる可能性がある」という点だけ頭の片隅に置いておけば、あなたはもうRedisレプリケーションの基本をマスターしたも同然です。

—

Redisのレプリケーションは、ただの「コピー」ではありません。それは、システムの「止まらない安心感」と「圧倒的なスピード」を両立させるための知恵の結晶です。

最初は難しく感じるかもしれませんが、この「シェフと見習い」のイメージを大切にしてください。基礎をしっかり固めれば、その先にある高度な運用（自動フェイルオーバーやRedis Sentinelなど）も、スッと理解できるようになりますよ。

次は、もし「マスターが倒れてしまったらどうするか？」というお話をしましょうか。一歩ずつ、一緒に歩んでいきましょう。応援していますよ！