やあ。Redisの世界へようこそ。
Redisクラスターを触り始めると、必ずと言っていいほど「MOVED」や「ASK」という、一見すると厄介なエラーにぶつかるよね。
でも、安心してほしい。これらは「エラー」というよりも、Redisが君を目的地まで導いてくれる「親切な案内板」なんだ。今日は、このリダイレクトの仕組みを、日常の風景に例えて紐解いていこう。
—
Redisクラスターは「巨大な図書館」だ
まず、Redisクラスターをイメージしてみてほしい。
1台のサーバーでは収まりきらない膨大なデータ（本）を、複数の司書（ノード）で分担して管理している状態だ。
君が「この本（データ）が欲しい！」とリクエストを送ったとき、もしその本を担当していない司書に声をかけてしまったらどうなるだろう？
司書は君にこう言うはずだ。
「すまない、その本なら隣の棚の司書が持っているよ」
これが、Redisでいう「リダイレクト」の正体だよ。
—
1. 「MOVEDリダイレクト」：引越し先は決まっている
「MOVED」は、データが完全にそのノードへ移転したことを意味する。
- 例えるなら：
君が図書館の受付で本を探すと、「その本はもう部署が変わって、あちらのカウンターに移動しましたよ」と案内されるようなものだ。
- どう動くのか：
クライアント（君のプログラム）は、その案内を聞いて、「なるほど、次はそっちへ行けばいいんだな」と学習する。そして、今後は迷わずその新しいカウンターへ直接行くようになるんだ。
これを「クライアントサイド・ルーティング」と呼ぶ。ライブラリが賢い理由は、一度案内されたルートを記憶（キャッシュ）して、二度目からは最短距離でアクセスしてくれるからなんだ。
—
2. 「ASKリダイレクト」：今は取り込み中
「ASK」は少し状況が違う。データは移動中だが、まだ完全に移転が完了していない一時的な状態だ。
- 例えるなら：
「その本は今、まさに引越し作業中で箱詰めしている最中です。申し訳ないですが、今すぐあちらのカウンターへ行って『ASK』と伝えてください。そうすれば優先的に対応してくれます」と言われているようなものだ。
- どう動くのか：
ASKの場合は、「一時的な案内」なので、クライアントは記憶を書き換えない。次のリクエストは、まず元のノードに聞きに行く。これがMOVEDとの決定的な違いだよ。
—
ライブラリはどうやってクラスターを知るのか？
「じゃあ、僕らがコードを書くときは、毎回リダイレクトを処理しなきゃいけないの？」と不安になるかもしれないね。
答えは「NO」だ。
現代の優れたRedisクライアントライブラリ（Pythonの`redis-py`やNode.jsの`ioredis`など）は、最初からクラスターの地図（スロット割り当て表）を頭に入れている。
例えば、こんな風にクラスターへ接続する
from redis.cluster import RedisCluster
ライブラリは起動時にCLUSTER SLOTSコマンドを叩き、
「どのデータがどのノードにあるか」という地図を自動で作成する
startup_nodes = [{“host”: “127.0.0.1”, “port”: “7000”}]
rc = RedisCluster(startup_nodes=startup_nodes, decode_responses=True)
ユーザーが意識しなくても、ライブラリがよしなに転送してくれる
rc.set(“my_key”, “value”)
君が `rc.set()` と書くだけで、ライブラリ内部では「`my_key`はスロット番号◯◯だから、ノードBへ送らなきゃ！」という計算がミリ秒単位で行われているんだ。
—
まとめ：ここをクリアすれば、君はもう中級者だ
今日のポイントを整理しよう。
1. MOVED： 「もうデータはあっちだよ！次からは直接そっちへ行ってね（地図を更新！）」
2. ASK： 「今ちょうど移動中なんだ。今回だけはあっちで聞いてみて（地図は更新しない）」
3. ライブラリ： 私たちの代わりに、この地図管理と転送処理を裏で黙々とこなしてくれる優秀な執事。
この仕組みを理解していれば、クラスターが「なぜそんなに高速なのか」、そして「運用中にどう振る舞うべきか」が自然と見えてくるはずだよ。
Redisは決して難しいツールじゃない。仕組みさえ分かれば、これほど頼もしい相棒はいないんだ。
自信を持って、次のコードを書いてみてほしい。応援しているよ！
コメント