Sentinelが「ボトルネック」になるのはいつか？
Redis Sentinelは高可用性（High Availability）を確保するための優れたソリューションです。しかし、Sentinelには物理的な制限があります。それは**データが分散されない**ことです。すべてのSlaveノードはMasterの1:1のコピーに過ぎません。データセットがサーバーのRAM上限（64GBや128GBなど）に達すると、それ以上データを追加できなくなります。
そこで、スケーラビリティの問題を解決するために登場するのがRedis Clusterです。データを一つの籠に盛るのではなく、Clusterでは複数のサーバーにデータを分散（水平スケーリング）させることができます。これにより、耐障害性が向上するだけでなく、複数のMasterノードの帯域を同時に活用することで、毎秒数百万のリクエストを処理できるようになります。
Redis Cluster의動作メカニズム
Clusterを円滑に運用するには、RedisがHash Slotsを通じてどのようにデータを分配するかを理解する必要があります。
Hash Slots：Redisによるデータ分割の手法
Redis Clusterは複雑なコンシステントハッシュ法（Consistent Hashing）ではなく、固定された**16,384個のHash Slots**を使用します。SET key "value"コマンドを実行すると、Redisは次の数式に従って位置を計算します：CRC16(key) mod 16384。
3つのMasterノードがある構成を想定してみましょう：
- ノードA： slot 0から5460までを管理
- ノードB： slot 5461から10922までを管理
- ノードC： slot 10923から16383までを管理
このアプローチは非常に柔軟です。4台目のノードを追加して拡張する場合、既存の3つのノードから一部のslotを新しいノードに再配置（リシャード）するだけで、サービスを停止することなく対応できます。
自動復旧メカニズム（フェイルオーバー）
Clusterモデルでは、各Masterは少なくとも1つのReplicaを持つべきです。ノードAにハードウェア障害が発生した場合、Clusterは自動的に選出プロセスを開始し、ノードAのReplicaを即座にMasterへ昇格させます。このプロセス全体は数秒で完了するため、アプリケーションを停止させることなく（ゼロダウンタイム）運用を継続できます。
実践：6ノード構成（3 Master – 3 Replica）の構築
ここでは、同じマシン上でポート7000から7005を使用して6つのノードをシミュレートします。本番環境（Production）では、障害の連鎖を避けるため、各ノードを個別の物理サーバーまたはコンテナに配置するようにしてください。
ステップ1：環境の準備
各インスタンスのデータを個別に管理するためのディレクトリ構造を作成します：
mkdir redis-cluster && cd redis-cluster
mkdir 7000 7001 7002 7003 7004 7005ステップ2：設定ファイルの作成
各ディレクトリに redis.conf ファイルを作成します。これらはClusterを動作させるための最小限の設定です：
port 7000
cluster-enabled yes
cluster-config-file nodes.conf
cluster-node-timeout 5000
appendonly yes
dir ./注意：cluster-node-timeout は5000msです。ノードの接続が5秒以上途切れると、システムはそのノードがダウンしたと判断し、フェイルオーバーの手順を開始します。
ステップ3：Redisプロセスの起動
以下のコマンドを使用して、6つのノードすべてを起動します（またはターミナルのタブを分けて実行してください）：
redis-server 7000/redis.conf &
redis-server 7001/redis.conf &
# ... ポート7005まで繰り返すステップ4：Clusterのクラスタリング設定
現時点では、各ノードは独立して動作しています。redis-cli コマンドを使用して、これらを一つの統合されたエンティティとして結合します：
redis-cli --cluster create 127.0.0.1:7000 127.0.0.1:7001 127.0.0.1:7002 \
127.0.0.1:7003 127.0.0.1:7004 127.0.0.1:7005 \
--cluster-replicas 1確認を求められたら yes と入力してください。Redisは自動的に3つのノードをMasterに、残りの3つのノードをそれぞれのReplicaとして割り当てます。
データルーティングの確認
Clusterを使用する際の最大の相違点は、redis-cli で接続する際に -c フラグを追加する必要があることです：
redis-cli -c -p 7000
127.0.0.1:7000> set user:id:100 "John Doe"
-> Redirected to slot [8125] located at 127.0.0.1:7001
OKポート7000にアクセスしていても、そのキーがポート7001のslotに属している場合、Redisは自動的に正しいデータを持つノードへ「リダイレクト」します。ルーティング性能をテストするためにCSVファイルから大量のサンプルデータを用意する必要がある場合は、CSVからJSONへの変換ツールを使用して、サーバーにデータをアップロードすることなく素早くモックデータを作成できます。
実践チャレンジ：障害シミュレーション
ポート7000のMasterノードを kill してみてください。その後、生き残っているいずれかのノードで cluster nodes コマンドを実行します。すると驚くべきことが起こります。Replicaノード（通常は7003）が自動的にMasterの権限を引き継いでいます。すべての読み取り/書き込み操作は、何事もなかったかのように正常に動作し続けます。
本番運用における「鉄則」
大規模なシステムを運用する際、初歩的なミスを避けるために以下の点を覚えておいてください：
- Hash Tags： 複数のキーを扱うコマンド（MGETなど）を実行したい場合は、キーの共通部分を中括弧で囲みます（例：
{orders}:1と{orders}:2）。これにより、それらを同じslotに強制的に配置できます。 - ノード数： ノードがダウンした際に過半数の投票（Quorum）を維持できるよう、最低でも3つのMasterが必要です。
- クライアントライブラリ： コードで使用するライブラリがClusterに対応していることを確認してください（Node.jsなら
ioredis、JavaならLettuceなど）。単一のRedis用ライブラリを使用すると、リダイレクトが発生した際にアプリケーションがエラーを返し続けてしまいます。
おわりに
Redis Clusterは、RAM内データ管理の考え方における大きな飛躍です。システムの堅牢性を高めるだけでなく、無限の拡張性をもたらします。まずはこの小さな6ノード構成から始めて、数兆リクエストを扱うようなプロジェクトへの適用を目指してみてください。構築の成功を祈っています！
