やあ。Redisの世界へようこそ。
Redisのチーフアーキテクトをしている私から、今日は「Redis Cluster」という、少しだけ背伸びした、でも絶対に避けては通れない非常にエキサイティングな仕組みについて話をしよう。
「Redisは速い」というのは聞いたことがあるだろう？ でも、もしそのデータが数億件、数テラバイトに膨れ上がったら？ 一台のコンピュータのメモリに収まりきらなくなったらどうする？
そこで登場するのが Redis Cluster だ。難しく考える必要はない。今日は「図書館の整理術」に例えて、その本質を紐解いていこう。
—
1. Redis Clusterの正体：巨大な図書館の「分館システム」
想像してみてほしい。君が世界一巨大な図書館の司書だとしよう。
本（データ）が1冊や100冊なら、君一人が管理できる。でも、本が1億冊になったら？ 君一人では、どこに何があるか探すだけで日が暮れてしまうよね。
そこで、君は決断する。「そうだ、図書館をいくつかに分けて、それぞれに専門の司書を配置しよう！」と。
これが Redis Cluster（シャーディング） の正体だ。
データを複数の「ノード（サーバー）」に分割して保存する。そして、どの本がどのノードにあるのかを、全員が知っている状態にする。これが分散管理の基本だよ。
2. どうやって「場所」を決めているのか？（ハッシュスロットの魔法）
「どの本をどのノードに置くか」を適当に決めると、後で大変なことになる。
Redis Clusterでは、「ハッシュスロット（Hash Slot）」という仕組みを使っている。
これは、0から16383までの「16,384個の箱」を用意して、データを必ずどれか一つの箱に放り込むルールだ。
- ノードA: 0〜5460番の箱を担当
- ノードB: 5461〜10922番の箱を担当
- ノードC: 10923〜16383番の箱を担当
こうしておけば、データが来たときに「これはハッシュ計算すると8000番だ！ じゃあノードBへ送ろう」と、瞬時に判断できる。迷子になることはないんだ。
3. 「もしも」の時の備え（レプリケーション）
「でも、もしノードBが故障したらどうするの？ ノードB担当のデータが全部消えちゃうじゃないか！」という鋭い指摘が聞こえてきそうだね。
安心しておくれ。Redis Clusterには 「レプリケーション（複製）」 という保険がある。
ノードBには、常にその内容をコピーしている「影武者（レプリカ）」を待機させておくんだ。もしノードBが倒れたら、即座に影武者が主役として立ち上がる。これが「高可用性（止まらないシステム）」の秘密さ。
4. 実践：Redis Clusterを覗いてみる
実際にRedis Clusterと会話する時の様子をイメージしてみよう。クライアント（プログラム）は、「どこにデータがあるか」をいちいち細かく気にしなくても大丈夫。Redisが賢く教えてくれるんだ。
redis-cliを使ってクラスタの状態を確認するコマンド
127.0.0.1:7000> cluster nodes
結果例:
1234… 127.0.0.1:7000 master – 0 162… 1 connected 0-5460
5678… 127.0.0.1:7001 master – 0 162… 1 connected 5461-10922
9012… 127.0.0.1:7002 master – 0 162… 1 connected 10923-16383
データをセットしてみる
127.0.0.1:7000> SET user:100 “Taro”
もしこのデータが別のノードにあるべきなら、
Redisは「MOVED 1234 127.0.0.1:7001」というメッセージを返して、
「そっちじゃないよ、7001番のノードに聞いてごらん」と優しく教えてくれるんだ。
—
先輩から君へのアドバイス
Redis Clusterをマスターする上で一番大切なのは、「完璧を目指さないこと」だ。
最初は「データを分割して、もし壊れても予備がある」というイメージを持つだけで十分。技術というものは、課題に直面した時に初めて真価を発揮するものだからね。
ここをクリアした君は、もう単なる「Redisを使える人」ではなく、「分散システムの考え方を知るエンジニア」の入り口に立っている。
次は、実際に小さなクラスタをDockerなどで立ち上げて、わざと一つのノードを落としてみる実験をしてみるといい。システムが自動で復旧する様子を見たとき、君はRedisの真の美しさに感動するはずだよ。
何かあればいつでも聞いておくれ。君のエンジニアとしての旅路を、私はいつでも応援しているよ。
コメント