【実務・中級編】 Redis Cluster (シャーディング) – Redis

Redis Clusterの深淵：16384のハッシュスロットが支配する水平スケーリングの真実

「Redis Clusterを導入すれば、メモリ容量もスループットも無限に拡張できる」。そう考えているなら、少し立ち止まってほしい。

Redis Clusterは単なる「分散ツール」ではない。それは、アプリケーションのデータ構造とネットワークトポロジーを、ハッシュスロットという極めて厳格な規律の下で同期させる高度な合意形成システムだ。

今日は、ドキュメントの表面をなぞるような話はしない。現場で何が起き、どう設計すべきか、その「核心」を叩き込む。

—

1. 16384の「呪縛」と「恩恵」

Redis Clusterのシャーディングにおける最小単位は、16384個のハッシュスロットだ。なぜ16384なのか？それは、ノード間のGossipプロトコルによる通信オーバーヘッドと、構成変更時のクラスタ安定性のバランスが最も取れる値だからだ。

ここでエンジニアが最初に陥る罠がある。「ハッシュタグ」の誤用だ。

通常、キーは`CRC16(key) % 16384`で配置が決まる。しかし、`{user:100}:profile`のように波括弧 `{}` を使うと、Redisは括弧内の文字列のみをハッシュ計算に使う。

設計の要諦: マルチキー操作（`MGET`や`SUNION`など）を一つのノードで完結させるためにハッシュタグは不可欠だ。しかし、これを乱用すると特定のノードにデータが偏る（ホットスポット）。「どのデータが同じスロットに存在すべきか」を、ビジネスロジックではなく「物理的なデータ配置」の観点で設計せよ。

2. クライアント側の「知性」

Redis Clusterは、プロキシ型のアーキテクチャではない。スマートクライアントがノードの配置マップ（Slot Map）をキャッシュし、直接ターゲットノードに接続する。

ここで注意すべきは、リダイレクト（MOVED/ASK）のコストだ。

MOVED: スロットの所有権が恒久的に移動したことを示す。
ASK: リバランス処理中の過渡的な移動を示す。

優秀なクライアントライブラリは、`MOVED`を受け取ると自動的に接続先を更新する。しかし、ネットワーク分離やクラスタの再構成中に、アプリケーション側で無限リトライループを発生させてはならない。 接続プール（Connection Pool）の管理と、クラスタトポロジーの更新タイミングを監視するメトリクスを必ず仕込め。

3. 実務で遭遇する「アンチパターン」

① トランザクションとパイプラインの制約

「Redis Clusterを使えば、全データに対してアトミックな操作ができる」というのは幻想だ。マルチキー操作は、キーが全て同じハッシュスロットに属している場合にしか許されない。

解決策: 複数のキーにまたがる整合性が必要な場合は、Redis側で解決しようとせず、アプリケーション層の分散ロック（Redlock等）か、そもそも設計を見直して「一つのキーに集約する」アプローチを検討せよ。

② スレーブの役割を誤解する

Redis Clusterにおけるスレーブ（レプリカ）は、可用性のための冗長化であり、読み取り負荷分散（Read-only replicas）を主目的とすべきではない。

深淵の知見: クラスタ環境で読み取り専用レプリカにクエリを投げる際は、`READONLY`コマンドを忘れずに送れ。さもなくば、クライアントは常にマスターにリダイレクトされる。また、レプリカからの読み取りは「古いデータ（Stale Data）」を返す可能性があることを、UI/UX側で許容できるか議論せよ。

4. 堅牢な設計のためのチェックリスト

システムレビューで私が必ず確認するポイントを共有する。

1. ノードの奇数構成: クォーラム（定足数）による自動フェイルオーバーを機能させるため、最低でも3マスター×1レプリカ（合計6ノード）を最小構成とせよ。
2. キーのTTL戦略: クラスタ全体でメモリが溢れた際、`LRU/LFU`による追い出しがどのノードで発生しているか監視できているか？メモリの偏りは即座にパフォーマンス劣化に直結する。
3. Client-side Cachingの併用: データ更新が少なく、読み取りが多いキーであれば、`TRACKING`機能を用いたクライアントサイドキャッシュの活用を検討せよ。ネットワークホップをゼロにできる。

最後に：アーキテクトからの助言

Redis Clusterは「銀の弾丸」ではない。スケーリングが必要なのは、本当にメモリ容量なのか？それともスループットなのか？
もし単純に読み取り負荷が高いだけなら、Read Replicaを並べるだけで事足りるかもしれない。

「分散させる」ということは、分散させない場合に比べて、障害の境界線が増えるということだ。 その複雑性を管理する覚悟がないなら、単一ノード（あるいはSentinel構成）で限界までチューニングする方が、遥かに堅牢で保守性の高いシステムになる。

技術は、それを使うエンジニアの複雑性への耐性に従って進化する。次は、`Redis Cluster`の再リバランスがシステムに与える影響について深く掘り下げよう。

設計に妥協するな。コードには魂を込めろ。