2026年6月19日

Redis Clusterでシャーディングする方法（構築・確認・リシャードの手順）

データベースサーバー

Redis Clusterは、データを16384個の「ハッシュスロット」に分け、そのスロットを複数のマスターノードに割り当てることで、1台に収まらないデータ量や処理量を分散する仕組みです。この記事では、シャーディングの考え方とキー設計の注意点を押さえたうえで、6ノード（マスター3・レプリカ3）のクラスタを作り、状態を確認し、ノード追加とリシャードを行うところまでを手順で説明します。

シャーディングの仕組み：ハッシュスロット

Redis Clusterでは、キー名からCRC16というハッシュ値を計算し、16384で割った余りでスロット番号（0〜16383）を決めます。各マスターノードは担当するスロットの範囲を持ち、そのスロットに入るキーだけを保存します。

クライアントが担当外のノードにコマンドを送ると、ノードは MOVED というエラーで「そのスロットは別のノードにある」と知らせます。クラスタ対応のクライアントはこれを受けて正しいノードに送り直し、スロットの対応表を覚えます。リシャード中には一時的な転送を示す ASK が返ることもあります。つまり、クラスタを使うにはクライアント側もクラスタ対応である必要があります。redis-cliなら -c オプションを付けると転送に従ってくれます。

あるキーがどのスロットに入るかは、次のコマンドで確認できます。

redis-cli -c -p 7000 CLUSTER KEYSLOT user:1000:profile

キー設計の注意：複数キー操作とハッシュタグ

シャーディングで最もつまずきやすいのが、複数のキーをまとめて扱うコマンドです。MGET、複数キーのDEL、トランザクション（MULTI/EXEC）、Luaスクリプトなどは、対象のキーがすべて同じスロットにないと CROSSSLOT エラーになります。

これを避けるのがハッシュタグです。キー名の中に { と } で囲んだ部分があると、その中の文字列だけでスロットが計算されます。

{user:1000}:profile
{user:1000}:cart
{user:1000}:session

この3つはすべて user:1000 でスロットが決まるため、同じノードに入り、まとめて操作できます。ただし、ハッシュタグを使いすぎると特定のスロットにデータが集中し、分散の意味が薄れます。「一緒に操作する必要があるキーのまとまり」の単位で付けるのが目安です。

ほかにも、クラスタではデータベース番号が0番だけになり、SELECTで切り替える使い方はできません。既存のアプリケーションがデータベース番号でデータを分けている場合は、キーの接頭辞で分ける形に直しておく必要があります。

構築前に決めること

ノード数と配置

クラスタの最小構成はマスター3台です。各マスターにレプリカを1台ずつ付けた計6ノードが一般的な出発点で、マスターが落ちたときはレプリカが昇格して処理を引き継ぎます。本番では、マスターとそのレプリカを別の物理サーバーやアベイラビリティゾーンに置かないと、1台の障害で両方を失います。

ポート

各ノードは、クライアント用ポート（例: 7000）に加えて、ノード同士が通信するクラスタバス用ポートを使います。既定ではクライアント用ポートに10000を足した番号（例: 17000）です。ファイアウォールでは両方を、ノード間でだけ通るように開けてください。インターネットには公開しません。

クラスタが本当に必要か

Redis Clusterは運用の手間が増えます。WordPressのオブジェクトキャッシュ程度なら、1台のRedisで十分なことがほとんどです。可用性だけが目的ならレプリカとSentinelの構成、データ量や書き込み量が1台の限界を超える見込みがある場合にクラスタ、と考えると判断しやすくなります。

手順1：各ノードの設定ファイルを用意する

ここでは検証用に、1台のサーバー上でポート7000〜7005の6プロセスを動かす例を示します。本番では各ノードを別サーバーに置き、IPアドレスを読み替えてください。作業はステージング環境で行い、既存のRedisにデータがある場合は先にバックアップを取ります。

# /etc/redis/cluster/7000/redis.conf（ポートごとに作る）
port 7000
bind 127.0.0.1
cluster-enabled yes
cluster-config-file nodes-7000.conf
cluster-node-timeout 5000
appendonly yes
dir /var/lib/redis/cluster/7000
requirepass your-strong-password
masterauth your-strong-password

cluster-config-file はRedis自身が書き換えるファイルで、手で編集するものではありません。ノードごとに別名にし、dir も分けます。認証を使う場合は、レプリカがマスターに接続するための masterauth も同じ値にしておきます。cluster-node-timeout は、ノードが応答しないと判断するまでのミリ秒で、短すぎると一時的な遅延でフェイルオーバーが起きやすくなります。

6つのプロセスを起動したら、それぞれに redis-cli -p 7000 PING などで応答があることを確かめます。

手順2：クラスタを作成する

redis-cliの --cluster create で、ノードをつなぎ、スロットを割り当てます。--cluster-replicas 1 は「マスター1台につきレプリカ1台」という意味です。

redis-cli -a your-strong-password --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 と入力します。なお、コマンドラインに -a でパスワードを書くとシェルの履歴に残ります。検証が終わったら、環境変数 REDISCLI_AUTH を使う方法に切り替えると安全です。

手順3：状態を確認する

作成後は、次の3つのコマンドで状態を見ます。

redis-cli -c -p 7000 CLUSTER INFO
redis-cli -c -p 7000 CLUSTER NODES
redis-cli --cluster check 127.0.0.1:7000

CLUSTER INFO では cluster_state:ok と、cluster_slots_assigned:16384 を確認します。stateがfailの場合は、割り当てのないスロットがあるか、マスターが落ちてレプリカもいない状態です。CLUSTER NODES では各ノードの役割（master / slave）と担当スロット範囲が一覧で出ます。--cluster check は、スロットの抜けや複数ノードでの重複を検出してくれるので、構成変更のたびに実行しておくと安心です。

動作確認として、-c 付きでキーを書き込み、別のノードに転送されることを見ておきます。

redis-cli -c -p 7000 SET foo bar
redis-cli -c -p 7000 GET foo

手順4：ノードを追加してリシャードする

容量が足りなくなったら、新しいマスターを追加してスロットを移します。新しいノードも手順1と同じ形式で設定し、起動しておきます。

# 7006を空のマスターとして追加
redis-cli --cluster add-node 127.0.0.1:7006 127.0.0.1:7000

# スロットを対話形式で移動
redis-cli --cluster reshard 127.0.0.1:7000

# 各マスターのスロット数を均等に近づける場合
redis-cli --cluster rebalance 127.0.0.1:7000 --cluster-use-empty-masters

追加直後のノードはスロットを持たないため、reshardかrebalanceを実行するまでデータは入りません。スロットの移動中はキーが少しずつ移されるので、大きなキーがあると時間がかかり、その間は該当キーへのアクセスが遅れることがあります。アクセスの少ない時間帯に行い、終わったら --cluster check で結果を確認します。新しいマスターにもレプリカを付けるには、add-node に --cluster-slave を付けて追加します。

WordPressから使う場合

WordPressのオブジェクトキャッシュでクラスタを使う場合、プラグイン側がクラスタ接続に対応している必要があります。たとえば Redis Object Cache プラグインは、wp-config.php の定数でクラスタのノード一覧を指定する方式に対応していますが、使える定数名や対応クライアント（phpredisなど）はバージョンで変わるため、プラグインの公式ドキュメントで最新の書式を確認してください（2026年10月現在）。

PHPから直接使う場合は、phpredisの RedisCluster クラスを使います。

$cluster = new RedisCluster( null, array( '10.0.0.11:7000', '10.0.0.12:7000' ), 1.5, 1.5, true, 'your-strong-password' );
$cluster->set( '{user:1000}:profile', wp_json_encode( $profile ) );

シードとして数台を渡せば、残りのノードは自動で見つけてくれます。AWSのElastiCacheやMemoryDBなどのマネージドサービスでもクラスタモードが提供されていますが、設定項目や制約はサービスごとに異なるので、それぞれのドキュメントを確認してください。

まとめ

Redis Clusterはキーを16384のハッシュスロットに振り分け、スロット単位でマスターに分散する
複数キーを扱うコマンドは同じスロットでないと失敗するため、ハッシュタグ {...} で必要なまとまりだけ寄せる
本番はマスター3・レプリカ3を出発点に、マスターとレプリカを別の機器に置く
構築は --cluster create、確認は CLUSTER INFO と --cluster check、拡張は add-node と reshard
可用性だけが目的なら、クラスタよりレプリカとSentinelの構成のほうが運用は簡単