【テクニカル・上級編】 Redis Cluster (シャーディング) – Redis

Redis Clusterの深淵：16384のハッシュスロットが支配する分散システムの真実

Redis Clusterは単なる「データの分散」ではない。それは、メモリという極めて揮発的かつ高速なリソースを、ネットワークの不確実性と調和させるための高度な数学的帰結である。

多くのエンジニアはRedis Clusterを「ノードを横に並べる仕組み」と誤解しているが、真のアーキテクトは、それが「計算機科学的な決定論」と「分散システムにおける一貫性の妥協」をいかにエレガントに解決しているかを見る。

今日は、ドキュメントの表面をなぞるような話はしない。16384個のスロットが持つ意味と、内部で何が起きているのかを解剖する。

—

1. 16384という数字の「正体」

なぜスロット数は16384（2^14）なのか。多くの者が疑問に抱くが、答えはRedisプロトコル（RESP）のパケットサイズと、クラスタの安定性のトレードオフにある。

Heartbeatのオーバーヘッド: クラスタ内の全ノードは、互いのスロットマップを交換する。16384ビット（2KB）のビットマップで表現すれば、ネットワーク負荷を最小限に抑えつつ、最大1000ノード規模のクラスタを維持できる。これが65536（2^16）であれば、8KBとなり、小規模な構成では無駄なトラフィックを増大させる。
決定論的配置: CRC16アルゴリズムによる `HASH_SLOT = CRC16(key) mod 16384`。この単純な計算は、クライアントサイドでのリダイレクト（MOVED）を極限まで高速化する。

ここで重要なのは、「Redisはキーの配置において『状態』を持たない」という点だ。クライアントがハッシュ値さえ計算できれば、サーバに問い合わせる前に宛先が確定する。この「予測可能性」こそがRedis Clusterの最大の武器だ。

2. 再配置（Resharding）の物理的現実

スロットをノード間で移動させる際、Redis内部で何が起きているか。`MIGRATE`コマンドの裏側では、`DUMP`, `RESTORE`, `DEL`のシーケンスが、ブロッキング状態（ソースノード）で実行される。

内部的に実行されるデータの移動フロー
1. ソースノードでDUMP: データをシリアライズ
2. ターゲットノードへ転送
3. ターゲットノードでRESTORE: メモリ上に復元
4. ソースノードでDEL: キーを削除

ここで注意すべきは「ブロッキング」だ。大量のキーを含むスロットを移動させると、その間の通信は停止する。大規模システムでスロット移行を行う際は、必ず`MIGRATE`のタイムアウト設定と、アプリケーション側のリトライ戦略をセットで設計しなければならない。さもなくば、移行中のノードが「死んでいる」と誤認され、クラスタ全体がパニックに陥る。

3. なぜ「Hash Tag」がアーキテクチャを救うのか

Redis Clusterは「キーの分散」が基本だが、トランザクションやLuaスクリプトの実行には、「同一ノードにデータが存在すること」という強い制約がある。

ここで登場するのが `{hash_tag}` だ。
`user:{100}:profile` と `user:{100}:settings` は、`{}` で囲まれた部分のみがハッシュ計算に使用される。これにより、論理的に関連するデータを物理的に同じスロット（＝同じノード）に強制的に配置できる。

極限の知見:
Hash Tagを多用しすぎると、特定のノードに負荷が集中する「ホットキー問題」が顕在化する。アーキテクトは、データの一貫性とノード負荷のバランスを、このHash Tagという小さなナイフで調整するのだ。

4. 運用における「死の淵」：ゴーストスロットとメタデータ

時折、クラスタが「ノードは元気なのにデータにアクセスできない」状態に陥ることがある。これは大抵、`nodes.conf`の不整合か、クラスタバス（ポート指定ポート+10000）の疎通不良が原因だ。

正常なノード状態確認
CLUSTER NODES
[ID] [IP:PORT] [FLAGS] [MASTER_ID] [PING] [PONG] [EPOCH] [LINK_STATE]
LINK_STATEがdisconnectedなら、それはもう分散システムの敗北である

伝説的なエンジニアは、`nodes.conf`を単なる設定ファイルだと思わない。これは分散システムの「合意形成の歴史」そのものだ。ここが壊れた時、Redisはクラスタとしてのアイデンティティを失う。

アーキテクトへの提言

Redis Clusterを導入する際、「スケールアウトが目的」という甘い考えは捨てよ。
本当の目的は、「単一ノードのメモリ制限の突破」と「高可用性の担保」だ。

1. スロットの移動は「コスト」である: 最初から適切なシャーディング設計（Hash Tag戦略）を組み込むこと。
2. ネットワークの遅延を信じろ: Redisは速い。だからこそ、ネットワークの遅延がシステムのボトルネックになる。クライアントは必ず「クラスタ対応」のものを使用し、トポロジのキャッシュを保持させろ。
3. レプリケーションは非同期である: 強い整合性（Strong Consistency）を求めるなら、Redis Clusterは選ぶべきではない。RDBMSとRedisの役割を混同するな。

Redis Clusterの真髄は、16384個のスロットをどう配置するかという「配置の芸術」にある。その計算機科学的な美しさを理解したとき、君のアーキテクチャは初めて真の強固さを手に入れる。

さあ、コードを書け。ただし、メモリの1バイトの重みを感じながら。