【テクニカル・上級編】リシャーディング – Redis

Redis Clusterの「静かなる革命」：リシャーディングの深淵と、その裏側で起きていること

Redis Clusterにおける「リシャーディング（Resharding）」を、単なるノード追加に伴うデータ移動だと考えているならば、それは大きな誤解だ。

これは、稼働中の巨大なメモリ空間を、クライアントのI/Oを遮断することなく、整合性を担保しながら再配置するという、分散システムにおける「飛行中のエンジン換装」に近い離れ業である。本稿では、Redisがこの過酷なタスクを、いかにして低レイテンシかつアトミックに実行しているのか、その内部メカニズムの深淵に切り込む。

—

1. 16,384の「境界」が意味するもの

Redis Clusterが16,384（2^14）というスロット数を固定しているのは、単なる慣習ではない。これは、クラスター構成情報の伝播におけるネットワークオーバーヘッド（Gossipプロトコル）と、クライアント側でのハッシュ計算効率のトレードオフから導き出された「魔法の数字」だ。

リシャーディングとは、この16,384のピースを、ノード間の動的な移転によって再分配するプロセスに他ならない。ここで重要なのは、「スロット移動は、個別のキーの移動ではない」という点だ。スロット単位で状態を管理することで、Redisは数億のキーを保持していても、管理すべきメタデータの量を一定に保つことができる。

2. インポートとエクスポートの二重奏

リシャーディング中、Redisは対象のスロットを「移行元（Source）」と「移行先（Destination）」のノード間で同期させる。ここで行われるのは、単なるデータ転送ではない。以下の状態遷移が内部的に発生する。

1. `IMPORTING` 状態: 移行先ノードは、特定のスロットに対して「今からデータを受け入れる準備ができた」とフラグを立てる。
2. `MIGRATING` 状態: 移行元ノードは、該当スロットが「移動中」であることを認識し、クライアントからのアクセスを制御する。

内部で起きていること：ASKリダイレクトの真実

移行中、移行元ノードにアクセスが来ると、Redisは即座にエラーを返すのではなく、`ASK`リダイレクトを投げる。

クライアントがリクエストを送った際、移行元ノードが送るレスポンス例
-ASK 12345 192.168.1.50:6379
意味: 「このスロットは移動準備中だ。まずはこのアドレスにASKを送ってから処理しろ」

この時、クライアントは一時的に宛先ノードに `ASKING` コマンドを送り、移行元でまだ未処理のキーを強制的に操作する。この「一過性の移行期間」を完璧に隠蔽することが、Redisの可用性の本質だ。

3. パフォーマンス劣化の正体：隠れたオーバーヘッド

実務においてリシャーディングを実行すると、確実にパフォーマンスが低下する。これはネットワーク帯域の問題だけではない。

`MIGRATE` コマンドのコスト: このコマンドは、データのシリアライズ、ネットワーク転送、移行元での削除、そして移行先での復元という一連のプロセスを「ブロック」する。もしキーのサイズが巨大な場合、移行元ノードはその間、完全にフリーズする。
メモリの断片化: 大量移動後の移行先ノードでは、`jemalloc`がメモリを再確保する過程で断片化が発生しやすい。物理的なメモリ消費量以上に、スラブアロケータが悲鳴を上げている可能性がある。

アーキテクトの助言：マイグレーションの「極意」

数テラバイト規模のクラスターをリシャーディングする際、デフォルトの `redis-cli –cluster reshard` をそのまま叩くのは素人だ。

バッチサイズの制御: 一度に移行するスロット数を小さく刻み、ノード間の通信ラグを観察せよ。
オフピークの追求: 移行中の `MIGRATE` が引き起こすCPU負荷を考慮し、アプリケーション側のバックグラウンド処理と競合させないスケジューリングが必須である。

4. 整合性を担保する「アトミック性」の裏側

Redisの移行プロセスが優れているのは、`MIGRATE` コマンドが内部的に `DUMP` (シリアライズ) と `RESTORE` (デシリアライズ) を組み合わせ、その実行をトランザクション的に完結させている点だ。

移行元ノードでデータが削除されるタイミングと、移行先でデータが有効化されるタイミングの間に「消失」や「二重書き込み」は存在しない。この堅牢な内部実装こそが、RedisがNoSQLの枠を超えて、信頼されるデータベースエンジンとして君臨し続ける理由である。

—

結論：リシャーディングは「対話」である

リシャーディングを成功させるためには、Redisというエンジンの呼吸を読み取る必要がある。

大規模アーキテクトとして言えることはただ一つ。「リシャーディングは、スロットを移動させているのではない。ノード間の信頼関係の再構築を行っているのだ」ということだ。

ノードの負荷状況、ネットワークのトポロジー、そしてアプリケーションのアクセスパターン。これら全てを俯瞰した上で、16,384個のスロットをどう配置するか。その「配置の美学」こそが、システムの寿命を決定づける。

次に `redis-cli` を叩くとき、あなたは単なるコマンド実行者ではなく、クラスターという有機体の調律師であることを忘れないでほしい。