Redis Clusterのリシャーディング：その「静かなる狂気」と運用解のすべて
Redis Clusterにおける「リシャーディング（Resharding）」は、システムに無停止でスケールアウトの恩恵をもたらす魔法のように思えるかもしれない。だが、現場で泥をすすり、障害対応の最前線に立ってきたエンジニアなら知っているはずだ。「リシャーディングは単なるデータの移動ではなく、クラスターの整合性とパフォーマンスを天秤にかける、極めて繊細な外科手術である」ということを。
今日は、教科書的な説明は最小限に、実戦で生き残るための「リシャーディングの深淵」を紐解く。
—
1. リシャーディングの本質：なぜ「停止」させないことが難しいのか
Redis Clusterには16,384個のハッシュスロットが存在する。リシャーディングとは、これらのスロットをソースノードからターゲットノードへ移動させるプロセスだ。
このプロセスの核心は、「移行中もクライアントからのリクエストを捌き続ける」という点にある。内部的には `MIGRATING` と `IMPORTING` という状態をノード間で伝播させることで、不整合を防いでいるが、ここには大きな落とし穴がある。
現場が直面する現実的なリスク
- イベントループのブロッキング: 大量の `DUMP` / `RESTORE` コマンドが発行される間、Redisのシングルスレッドは高負荷に晒される。
- ネットワーク帯域の飽和: 巨大なキー（数MB〜GB）が存在する場合、移行中にスループットが劇的に低下する。
- クライアントの追従遅延: `MOVED` リダイレクトの嵐が、アプリケーション層の接続プールを枯渇させることがある。
—
2. 実戦的リシャーディングの「鉄則」
運用を成功させるためには、`redis-cli –cluster reshard` を叩く前に、以下の3つのステップを徹底してほしい。
① キーのサイズと分布を事前に「透視」する
リシャーディングを開始する前に、必ず `MEMORY USAGE` を計測せよ。数GBの巨大なHash型やSet型が1つのスロットに固まっている場合、その移行はシステムの心停止を意味する。
特定のスロットに巨大なキーが存在しないか確認（疑似コマンド）
巨大なキーがあれば、リシャーディング前に分割・削除が必須
redis-cli –cluster getkeysinslot
② `migrate` のタイムアウト値を設計する
デフォルトの移行タイムアウトは、ネットワークが不安定な環境では短すぎることがある。移行対象が巨大である場合、`–cluster-migrate-timeout` を適切に調整せよ。ここをケチると、移行が中途半端に中断され、スロットが「中途半端な状態」でスタックする悪夢を見ることになる。
③ 一度に移動するスロット数を絞る
一気に数千スロットを動かすのは素人のやることだ。本番環境では、数百スロット単位（例: 100〜500）で進捗を監視し、CPU使用率とネットワーク帯域のメトリクスが「安定線」を超えないことを確認してから次のバッチへ移行せよ。
—
3. 「堅牢なシステム」にするための設計パターン
リシャーディングを成功させる最大の秘訣は、「リシャーディングを前提としたアプリケーション設計」にある。
- キーの設計をフラットに: 巨大なValueをRedisに突っ込まないこと。Redisは高速なキャッシュ層であって、巨大なBlobストアではない。キーが小さければ小さいほど、リシャーディングは滑らかになる。
- クライアントライブラリの選定: `MOVED` リダイレクトを透過的に再試行し、ローカルでスロットキャッシュを賢く更新するライブラリ（Goなら `go-redis`、Javaなら `Lettuce` など）を選択せよ。古いライブラリのままだと、移行中に接続エラーが多発し、サービスが不安定になる。
- 監視の自動化: リシャーディング中は `cluster_state` が `ok` になっているか、そして `migrating_keys` や `importing_keys` の数が異常に増加していないかを監視するダッシュボードを用意せよ。
—
4. 伝説のエンジニアからの忠告
最後に、経験則として伝えておく。
「深夜のリシャーディングは避けるな。しかし、金曜の夜には絶対に行うな。」
リシャーディングは、どれほど準備しても「未知の負荷」がスパイクすることがある。障害が発生した際、即座に手動介入できる日中に実行し、かつリバートプラン（スロットを元に戻す手順）を脳内でシミュレーションできていない状態なら、決してコマンドを打つべきではない。
リシャーディングはRedis Clusterという巨大な生命体を、稼働させながら改造する作業だ。その鼓動を感じ取り、ノードの悲鳴を聞き逃さないこと。それができれば、君はRedisという強力な武器を真に使いこなしていると言える。
—
次のアクション
もし現在、クラスターの再編を検討しているのなら、まずは `redis-cli –cluster check` を実行し、現在のスロット分布が偏っていないか、そして「熱いスロット（アクセス集中しているスロット）」が存在しないかを分析することから始めてほしい。
技術は裏切らない。準備を怠らなければ、Redisは君のシステムの最強の盾となる。健闘を祈る。
コメント