Redisクラスタ内部：クライアントによるシャードの特定方法

Posted at 2025-04-11

背景：なぜ Redis Cluster が必要なのか

Sentinel モードはマスター・スレーブ構成に基づいており、読み書きの分離を実現しています。また、自動フェイルオーバー機能も備えているため、システムの可用性が高くなります。しかし、各ノードが同じデータを保持するため、メモリの無駄が生じ、オンラインでのスケールアウトが難しいという課題があります。

そのため、Redis Cluster クラスタ（シャーディングクラスタの実装方式）が登場しました。Redis 3.0 で導入され、Redis の分散ストレージを実現しています。データをシャーディング（分割）することで、各 Redis ノードが異なるデータを保持し、オンラインスケーリングの課題を解決しています。また、データを各 Redis インスタンスに分散して保存できるため、大容量データの保存も可能で、レプリケーションやフェイルオーバー機能も提供されます。

たとえば、1 つの Redis インスタンスに 15GB 以上のデータを保存すると、応答が非常に遅くなります。これは Redis の RDB 永続化メカニズムによるもので、Redis は RDB 永続化操作を完了するために子プロセスを fork します。この fork 処理の所要時間は Redis 内のデータ量に正比例します。

このとき、「15GB のデータを分散保存すればいいのでは？」と考えるのは自然です。これこそが Redis シャーディングクラスタの目的です。シャーディングクラスタとは何か、例を見てみましょう。Redis で 15GB のデータを保存する必要がある場合、単一の Redis インスタンスを使う方法と、3 台の Redis インスタンスで構成されるシャーディングクラスタを使う方法があります。以下に比較します：

シャーディングクラスタと Redis Cluster の違い：Redis Cluster は Redis 3.0 以降で公式に提供されたシャーディングクラスタの実装方式です。

データが複数の Redis インスタンスにシャーディングされている場合、クライアントはどのインスタンスにアクセスすればよいのか、どうやって判断しているのでしょうか？以下に Redis Cluster の仕組みを見ていきましょう。

クライアントはどのようにしてアクセスすべきシャードを知るのか？

Redis Cluster は、データとインスタンス間のマッピング関係を処理するために「ハッシュスロット（Hash Slot）」という方式を採用しています。

シャーディングクラスタは、全体で 16384 個のスロット（slot）に分割されます。Redis に送信される各キー・バリューのペアは、キーに基づいてハッシュ処理され、16384 個のスロットのいずれかに割り当てられます。使用されるハッシュ関数は比較的単純で、CRC16 アルゴリズムで 16bit の値を計算し、それを 16384 で割った余り（mod）を使ってスロットを決定します。データベース内のすべてのキーはこの 16384 個のスロットのいずれかに属しており、クラスタ内の各ノードはこのスロットの一部を処理します。

クラスタ内の各ノードは、ハッシュスロットの一部分を担当しています。仮に現在のクラスタにノード A、B、C の 3 台があるとすると、各ノードが担当するハッシュスロット数は 16384 ÷ 3 になります。例として、以下のような割り当てが可能です：

ノード A：スロット 0 ～ 5460 を担当
ノード B：スロット 5461 ～ 10922 を担当
ノード C：スロット 10923 ～ 16383 を担当

クライアントが Redis インスタンスにデータの読み書きを要求したとき、そのインスタンスに対象のデータが存在しない場合はどうなるのでしょうか？ここで登場するのが、MOVED リダイレクトとASK リダイレクトです。

3. インスタンスに対象データが存在しない場合はどうなるか？

Redis Cluster モードでは、ノードがリクエストを処理する流れは以下のようになります：

ハッシュスロットに基づき、現在の Redis キーが自ノードに存在するか確認
スロットが自ノードの担当でない場合は、MOVED リダイレクトを返す
スロットが自ノードの担当であり、キーがスロット内に存在する場合は、該当キーの結果を返す
キーがそのスロットに存在しない場合、そのスロットが「MIGRATING（移行中）」か確認
キーが移行中であれば、ASK リダイレクトを返してクライアントを移行先ノードに誘導
スロットが移行中でなければ、スロットが「IMPORTING（インポート中）」か確認
スロットがインポート中で ASKING フラグが立っていれば処理を継続、なければ MOVED を返す

3.1 MOVED リダイレクト

クライアントが Redis インスタンスに対して読み書き操作を行った際に、対象スロットがそのノードに属していない場合、Redis は MOVED リダイレクトエラーを返します。このエラーには、対象スロットを保持している新しいインスタンスの IP アドレスとポート番号が含まれています。これが Redis Cluster の MOVED リダイレクトメカニズムです。

3.2 ASK リダイレクト

ASK リダイレクトは主にクラスタのスケーリング（拡張・縮小）時に発生します。スケーリングによりスロットが移動するため、元のノードにアクセスすると、データはすでに移行先のノードに存在している可能性があります。この場合、ASK リダイレクトを使うことで正しいノードへ誘導できます。

4. 各ノード間の通信はどう行われるか？

Redis クラスタは複数のノードで構成されており、それぞれのノードはどのように通信しているのでしょうか？答えは Gossip プロトコルです。Gossip はメッセージ伝播プロトコルの一種で、各ノードは周期的にノードリストの中から k 個のノードを選び、自ノードが持つ情報を送信します。これを繰り返していくことで、すべてのノードの情報が一致し、アルゴリズムが収束します。

Gossip プロトコルの基本的な考え方：あるノードがネットワーク内の他のノードに情報を共有したいとき、周期的にランダムにいくつかのノードを選び、情報を送ります。情報を受け取ったノードも同様に、他のランダムなノードにその情報を送信します。通常、情報は一度に 1 ノードではなく N 個のターゲットノードに送信されます。この N のことを **fanout（ファンアウト）**と呼びます。

Redis Cluster はこの Gossip プロトコルを使って通信し、ノード同士が常に情報を交換しています。交換される情報には、ノードの障害、新ノードの参加、マスター・スレーブの変更、スロット情報などが含まれます。Gossip プロトコルでは、以下のような複数のメッセージタイプが使われます：

meet メッセージ：新ノードの参加を通知します。送信ノードは受信ノードに対し、現在のクラスタに参加するように通知します。meet メッセージが正常に通信されると、受信ノードはクラスタに参加し、以後は周期的に ping および pong メッセージの交換を行うようになります。
ping メッセージ：各ノードは毎秒、他のノードに ping メッセージを送信します。このメッセージには、ノードが把握している他の 2 つのノードのアドレス、スロット、状態情報、最終通信時間などが含まれます。
pong メッセージ：ping や meet メッセージを受け取ったとき、応答として pong メッセージを返します。このメッセージにも、送信ノードが把握している他の 2 つのノードの情報が含まれます。
fail メッセージ：あるノードが別のノードをダウンと判断した場合、その情報をクラスタ全体に fail メッセージとしてブロードキャストします。他のノードがこの fail メッセージを受信すると、該当ノードを「ダウン状態」として更新します。

特に、各ノードは クラスタバス（cluster bus） を通じて他のノードと通信します。この通信には、通常のサービス用ポートとは異なる特別なポート番号が使用されます。たとえば、あるノードのポートが 6379 の場合、クラスタ間の通信には 16379（6379 + 10000）番ポートが使われます。ノード間通信は特別なバイナリプロトコルを用いて行われます。

5. クラスタ内ノードに障害が発生した場合はどうなるか？

Redis クラスタは高可用性を実現しており、クラスタ内のノードに障害が発生しても、フェイルオーバーによってクラスタの正常なサービス提供が維持されます。

ダウン（オフライン）

Redis クラスタは ping/pong メッセージを用いて障害を検出します。この検出には「主観的ダウン」と「客観的ダウン」の 2 種類があります：

主観的ダウン（Subjective Down、略称：pfail）：あるノードが他のノードを「利用不可」と判断した状態です。この状態は最終的な障害判定ではなく、あくまで 1 ノードの意見であり、誤判定の可能性があります。
客観的ダウン（Objective Down、略称：fail）：複数のノードがあるノードを「利用不可」と認識し、クラスタ内で合意された正式なダウン状態です。もしダウンしたノードがスロットを保持するマスターノードであれば、フェイルオーバーが必要になります。
たとえば、ノード A がノード B を主観的ダウンと判断し、一定時間経過後にその情報を他のノード（例：ノード C）に伝えます。ノード C が受信したメッセージを解析してノード B の状態が「pfail」であると確認した場合、「客観的ダウン」のプロセスが発動されます。
ダウンしたのがマスターノードである場合、Redis Cluster はスロットを保持しているマスター数の過半数による投票を行い、その票数が過半数を超えたときに正式に「客観的ダウン」となります。