【実務・中級編】 Redis Cluster – Redis

Redis Clusterの深淵：なぜ「ただ繋ぐだけ」ではシステムが崩壊するのか

Redis Clusterを導入する際、多くのエンジニアは「スケーラビリティ」という甘美な響きに酔いしれ、根本的なアーキテクチャの制約を無視して設計を始めます。結果として、本番環境で「謎のレイテンシ」や「スロット再配置によるパフォーマンス低下」という地獄を見ることになる。

今日は、教科書的な説明は割愛し、私がアーキテクチャ設計の現場で必ず叩き込む「Redis Clusterの真実」を共有しよう。

—

1. 16384のハッシュスロットという「呪縛」

Redis Clusterはデータを16,384個のスロットに分割する。これは固定だ。
キーは `CRC16(key) % 16384` で計算され、各ノードに割り当てられる。

ここで陥る罠：
「キーの分散」を意識しない開発者が多すぎる。例えば、`user:100:profile`, `user:101:profile` というキーを大量に作ると、これらは全て同じノードに集中する可能性がある。

設計の鉄則：

Hash Tagsを使う: 関連するデータを強制的に同じノードに配置したい場合（例えばトランザクションやJOIN相当の操作が必要な場合）、`{user:100}:profile`, `{user:100}:settings` のように `{}` で囲う。これで `{}` 内だけがハッシュ計算に使われ、同一スロットに収まる。
むやみな分割は避ける: Hash Tagsを多用すると、特定のノードに負荷が集中する「ホットスポット」が生まれる。スケーラビリティの恩恵を捨てることになるので、本当に必要な時だけ使うこと。

—

2. ネットワークの断絶を理解せよ：MOVEDとASK

Redis Clusterのクライアントは「スマート」でなければならない。
クライアントはクラスタの状態をキャッシュしているが、再配置（Resharding）が走ると、古いキャッシュを持ってノードを叩く。

MOVEDリダイレクト: 「そのデータはもうここにはない、あっちだ」という恒久的な移動。クライアントはキャッシュを即座に更新し、新しいノードに接続し直す必要がある。
ASKリダイレクト: 「今、移動中だから一度だけあっちに聞いてくれ」という一時的なもの。これはキャッシュを更新してはいけない。

設計レビュー時のチェックポイント：
あなたのアプリケーションが使っているクライアントライブラリは、これらを透過的に処理しているか？また、リトライ回数は適切か？ネットワーク瞬断時の「再接続戦略」が甘ければ、システム全体が連鎖的にダウンする。

—

3. パフォーマンスの敵：「クロススロット命令」

Redis Clusterにおいて、最もコストが高いのは「複数ノードにまたがるクエリ」だ。
`MGET` や `SUNION` を安易に使っていないか？

ダメな例：異なるノードにまたがるキーを同時に取得しようとしている
MGET user:100:data user:200:data
-> クライアントが複数のノードに対してリクエストを投げ、結果をマージする羽目になる。
これによるネットワークレイテンシの増大は計り知れない。

極限の知見：
複数ノードを横断する操作が必要なら、それは設計の敗北だ。アプリケーション層でマージするのではなく、データモデル自体をRedisの「スロット配置」に合わせるように正規化を崩す（非正規化する）のが、Redisにおける高パフォーマンス設計の定石である。

—

4. 運用：高可用性の裏側にある「リスク」

Redis Clusterは自動フェイルオーバーを提供するが、それは「魔法」ではない。

Failoverのトリガー: 多数決（Quorum）によって決まる。ノードがダウンしたと判断されるまでには `cluster-node-timeout` の時間がかかる。
データ消失のリスク: Redisは非同期レプリケーションだ。マスターが書き込みをAckする前にクラッシュすれば、そのデータは消える。

現場での防衛策：
1. `WAIT` コマンドを活用せよ。重要度の高い書き込みには `WAIT 1 1000`（最低1台のレプリカに同期してから完了とする）を付与し、可用性と整合性のトレードオフを制御する。
2. レプリカを物理的に異なるラック、または異なるAZ（アベイラビリティゾーン）に配置する「アフィニティ設計」をインフラ構成レベルで徹底する。

—

最後に：エンジニアへの提言

Redis Clusterは「万能な分散データベース」ではない。
「キーベースのアクセスが極めて高速であり、かつスケーラビリティが必要な場合にのみ選ぶべきツール」だ。

もし、すべてのデータをRedisに突っ込もうとしているなら、まずはそのアーキテクチャを見直すべきだ。RDBで処理すべきデータ、Redisにキャッシュすべきデータ、そしてRedis Clusterで分散すべきデータを峻別すること。

それができないエンジニアに、Redis Clusterを使いこなす資格はない。
コードを書く前に、データがどう配置されるかを常に頭の中でシミュレーションしてほしい。それができる者だけが、この分散システムの「支配者」になれる。

健闘を祈る。