【入門編】レプリケーション関連の設定項目 – Redis

みなさん、こんにちは！
日々Webサービスやシステムの裏側で大活躍している超高速データベース「Redis」、触っていますか？

データの読み書きが驚くほど早いRedisですが、実務で使うとなると「Redisのサーバーが倒れたらどうしよう…」「アクセスが集中したらパンクしないかな？」という不安が出てきますよね。

そこで登場するのが「レプリケーション（複製）」という仕組みです。

今回は、Redisの設定ファイル（`redis.conf`）に書かれているレプリケーションの超重要コマンドたちを、難しい専門用語を使わずに「人気ラーメン店の本店と分店」という日常の例えを交えて優しく紐解いていきます。

ここをクリアすれば、Redisの基本はバッチリマスターできますよ！リラックスして読んでいってくださいね。

—

1. そもそも「レプリケーション」ってどんな仕組み？

Redisのレプリケーションとは、一言で言えば「全く同じデータのコピーを持った子分のサーバー（レプリカ）を作ること」です。

これをラーメン屋さんに例えてみましょう。

プライマリ（親分）：人気ラーメン店の「本店」
お客さんからの新しい注文（データの書き込み）を受け付け、秘伝のレシピ帳（データ）を常に最新に更新します。
レプリカ（子分）：全国にある「分店」
本店から送られてくる最新のレシピ帳をリアルタイムで真似して、全く同じ状態を保ちます。

なぜこんなことをするのでしょうか？理由は2つあります。

1. お店のパンクを防ぐため（負荷分散）
ラーメンを食べるだけ（データの読み取り）のお客さんには分店に行ってもらえば、本店の混雑が和らぎますよね。
2. 万が一の事故に備えるため（高可用性）
もし本店が火事（サーバーダウン）になっても、分店があれば営業を続けられます。

この「本店と分店の関係」をコントロールするのが、`redis.conf` にある設定項目たちなのです。

—

2. 分店を作る第一歩：`replicaof`

まず最初に覚えるべきなのが `replicaof`（レプリカ・オブ）です。

これは、分店側のRedisに対して「あなたはどの本店の弟子（レプリカ）になってね！」と指示を出す設定です。

設定ファイル（`redis.conf`）での書き方

——————————————————————
replicaof <本店のIPアドレス> <本店のポート番号>
——————————————————————
例：IPアドレスが 192.168.1.100 で、ポートが 6379 の本店につく場合
replicaof 192.168.1.100 6379

これだけで、起動した瞬間に本店に「弟子入りさせてください！」と接続し、本店にあるデータをぜんぶ自動でコピーしてくれます。

💡 先輩のワンポイントアドバイス

実は、設定ファイルを書き換えなくても、動いているRedisに後から「今日から君は分店ね！」と命令することもできます。

redis-cliを使って、動的に本店を指定する
127.0.0.1:6379> REPLICAOF 192.168.1.100 6379
OK # <- 「了解です！本店に接続してデータをコピーします」という返事 ---

3. 分店で勝手なレシピ変更を許さない：`replica-read-only`

次は `replica-read-only`（レプリカ・リード・オンリー）です。

直訳すると「レプリカは読み取り専用にする？」という設定です。デフォルトでは `yes`（読み取り専用にする）になっています。

分店でのデータの書き換えを禁止するかどうか（デフォルト: yes）
replica-read-only yes

なぜ「読み取り専用」にするの？

想像してみてください。分店のバイト店員が、勝手にレシピ帳（データ）を書き換えて「新メニュー：イチゴラーメン」を追加してしまったらどうなるでしょう？

本店からの最新レシピが送られてきたときにデータがごちゃごちゃになり、何が正しいのか分からなくなってしまいますよね。

`yes`（おすすめ）: 分店では「注文を見る（読み取り）」ことしかできません。データを書き込もうとするとエラーになります。
`no`: 分店でも勝手にデータを書き込めちゃう（※ただし本店には共有されず、いずれ本店のデータで上書きされて消えます）。

データの一貫性を保つためにも、ここは 絶対に `yes` のままにしておくのがプロの鉄則 です。

replica-read-only yes の状態で書き込もうとすると…
127.0.0.1:6379> SET mykey “Hello”
(error) READONLY You can’t write against a read only replica.
-> 「ここは分店だから書き込みはダメですよ！」と怒られます。安全ですね！

—

4. 本店と電話が切れた！どうする？：`replica-serve-stale-data`

一番ドラマが生まれるのが、この `replica-serve-stale-data`（レプリカ・サーブ・ステイル・データ）です。

「stale（ステイル）」とは「鮮度が落ちた、古い」という意味。
つまり、「本店との通信が途切れて、最新のレシピが入ってこなくなった時、手元にある『ちょっと古いデータ』でお客さんに接客を続けていいですか？」という設定です。

本店と通信が切れた時、古いデータで応答するか？（デフォルト: yes）
replica-serve-stale-data yes

選択肢は2つあります。

`yes`（デフォルト）：営業継続スタイル

「本店と電話が繋がらないけど、昨日届いたレシピ帳があるから、とりあえずお店を開けてお客さんの注文（読み取り）を受け付けよう！」というスタンスです。

メリット: サービスが止まらない（システムが動き続ける）。
デメリット: もしかしたら本店で最新のメニュー変更があったかもしれず、古い情報を返してしまう可能性がある。

`no`：安全第一スタイル

「本店と連絡が取れない状態でお客さんに料理を出すのは危険だ！いったんお店を閉めよう（エラーを返そう）！」というスタンスです。

メリット: 間違った古いデータを絶対にお客さんに見せない。
デメリット: 本店と繋がるまで、分店での読み取りも全てエラーになる。

どっちを選べばいい？

SNSの「いいね数」のように、「多少ズレててもサービスが止まらない方が嬉しい」場合は `yes`。
銀行の残高表示のように、「間違った古い情報を出すくらいならエラーにしてほしい」場合は `no`。

作るシステムの性格に合わせて選ぶのが、スマートなエンジニアの第一歩ですよ。

—

5. 【おまけ】プロの現場で役立つ「安全装置」

最後に、もう一つだけ知っておくと一目置かれる設定を紹介しますね。

それが `min-replicas-to-write`（最小レプリカ数）です。

信頼できる分店が「最低1台」以上オンラインでないと、本店も書き込みを受け付けない
min-replicas-to-write 1
min-replicas-max-lag 10

これは「分店（弟子）が全滅して誰もレシピをバックアップできない状態なら、本店も事故を防ぐために一旦新しい注文（書き込み）をストップする」という究極の安全装置です。

「大切なデータを絶対に失いたくない！」という厳しいシステムでよく使われます。

—

まとめ：レプリケーション設定の早見表

今日学んだ内容を、最後におさらいしておきましょう！

最初は難しく思えた英語のパラメータも、「ラーメン本店の営業ルール」だと思うと一気に親近感が湧いてきませんか？

レプリケーションは、Redisの可用性を支える最高に面白い仕組みです。
まずは自分のパソコン上で小さなRedisを2つ起動して、`replicaof` を試すところから始めてみてください。実際に動いたときの感動は一味違いますよ！

ここをクリアしたあなたなら、Redisの基本はバッチリマスターできています。自信を持って次のステップに進んでいきましょうね！