【テクニカル・上級編】 Redis Cluster – Redis

Redis Clusterの深淵：分散の代償と「極限」の最適化

Redis Cluster。この言葉を聞いて、多くのエンジニアは「スケーラビリティ」という甘い響きを想像する。しかし、アーキテクトの視点から言えば、それは「分散システムにおける一貫性と可用性の終わりのない妥協の歴史」そのものだ。

教科書的なチュートリアルは無視する。今日話すのは、Redis Clusterが物理メモリとネットワークの境界線で何を行っているのか、そして我々がなぜその挙動を「飼い慣らす」必要があるのかについてだ。

—

1. Slotマッピングの裏側：Hashタグの「物理」

Redis Clusterは16,384個のハッシュスロットを管理する。これは固定数だ。なぜ16kなのか？ネットワーク通信のオーバーヘッドと、構成変更時のバイナリデータ送信量を考慮した絶妙なバランスだが、ここで重要なのは「Keyの物理的な居場所」をどう制御するかだ。

一般的な `HASH_SLOT = CRC16(key) mod 16384` という公式を盲信してはならない。マルチキー操作（MGETやPipeline）を多用するシステムにおいて、これではパフォーマンスは地に落ちる。

アーキテクトの知見：
アプリケーション層での「Hash Tag」活用は必須だが、やりすぎると特定のノードにデータが偏る「ホットキー問題」を引き起こす。

戦略: `user:{id}:profile` のような設計にする際、`{}` で囲むのはID部分のみにする。しかし、バッチ処理で特定のノードを叩きすぎないよう、あえてタグを外す階層を設けるのが「分散の極意」だ。

—

2. ゴシッププロトコルと「ノードの疲弊」

Redis Clusterはフルメッシュのゴシッププロトコル（PING/PONG）でノード状態を共有する。ノード数（N）が増えれば、通信量は `O(N^2)` で増大する。

大規模クラスター（例えば100ノード超）において、この通信は無視できないCPUサイクルを消費する。ここで注意すべきは、`cluster-node-timeout` の設定だ。

極限のチューニング: ネットワークのジッターが激しい環境で、安易にタイムアウトを短く設定してはならない。ノードの「誤検知（False Positive）」による不要なフェイルオーバーは、クラスター全体の `Epoch` 情報を書き換え、結果として世界中でロックと再マッピングを引き起こす。
教訓: クラスターの安定性は「速い検知」ではなく「正確な判断」に宿る。

—

3. メモリの断片化と「jemalloc」の呪縛

Redisは `jemalloc` を採用しているが、クラスター構成でデータを頻繁に再配置（Resharding）すると、メモリの断片化（Fragmentation）が深刻化する。

特に、生存時間の短いキー（TTL）を大量に扱う場合、Redisのメモリ解放効率が追いつかなくなる。

// 内部的なメモリ断片化率の監視
// INFO memory の mem_fragmentation_ratio を注視せよ
// 1.5を超えたら、それはOSへの返却が間に合っていないサインだ。
// 物理メモリが潤沢でも、Redis自身のarenaで断片化が起きると
// 新規アロケーションでレイテンシスパイクが発生する。

アーキテクトの知見：
大規模なリシャードを行う際は、`active-defrag yes` を有効にするのは当然として、書き込み負荷の低い時間帯に、段階的にスロットを移動させること。一気に数十ギガのデータを移動させれば、Redisのシングルスレッドモデルはメモリ管理だけで飽和する。

—

4. 読み取りの「不完全な一貫性」

Redis Clusterのレプリカは、デフォルトでは `READONLY` を要求される。しかし、クライアントが古いハッシュスロット情報をキャッシュしていた場合、その読み取りは「古いデータ」を返す可能性がある。

アーキテクトの知見：
強整合性を求めるなら、`WAIT` コマンドを活用せよ。

クライアント側の擬似コード
データを書き込んだ後、最低1つのレプリカに同期されるまで待機する
SET key value
WAIT 1 1000 # 1つのレプリカに、1000ms以内で同期されるまでブロックする

この「同期待ち」はパフォーマンスを犠牲にするが、分散システムにおける「最後の一線」を守るための代償だ。

—

最後に：エンジニアへの問い

Redis Clusterは魔法の杖ではない。単なる「キーバリューストアの束」だ。
ノードが増えれば通信コストが増え、スロットが移動すれば計算コストが増える。

あなたが今設計しているアーキテクチャが、「本当にRedis Clusterを必要としているのか」、あるいは「Redisのインスタンスを垂直にスケールさせ、読み取り専用のレプリカを配置するだけで解決するのか」を再考してほしい。

分散化とは、複雑性を買う行為だ。
その複雑性を管理する覚悟がないなら、安易にノードを増やすな。それが、数々の障害を乗り越えてきた者からの唯一のアドバイスだ。

次回の考察では、Redisの非同期レプリケーションにおける「データ消失の確率的モデル」について深掘りしよう。技術は常に、限界ギリギリのところで最も美しく輝く。