Redisの「キー操作」でプロダクトを落とさないために：RENAMEとMOVEの暗部
テックリードの私だ。コードレビューをしていると、未だに `RENAME` や `MOVE` をアプリケーション層の都合で安易に使っているコードを見かける。
「キー名をリネームしたいから `RENAME`」「別DBにデータを退避させたいから `MOVE`」——。
もし君のチームが本番環境でこれらを無邪気に使っているなら、今すぐその手を止めてほしい。
Redisはシングルスレッドで動くインメモリの怪物だ。そのデータ構造と内部のメカニズムを理解せずにコマンドを叩く行為は、時限爆弾を抱えてロシアンスーサイドをするようなものだ。今回は、キーの改名と移動（`RENAME`, `RENAMENX`, `MOVE`）の本質的な挙動と、実務で絶対に踏んではいけない地雷について解説しよう。
—
1. RENAME / RENAMENX：その「名前変更」、裏で何が起きているか？
まずはキーのリネームだ。構文自体はシンプルだが、実務で使うには致命的な罠がある。
キー名を old_key から new_key に変更
RENAME old_key new_key
宛先のキーが存在しない場合のみリネームを実行
RENAMENX old_key new_key
致命的な罠：O(1) の幻想と、裏で行われるメモリ解放
公式ドキュメントを見ると、多くのキー操作系コマンドと同様に「計算量は O(1)」と書かれている。確かに、ハッシュテーブルのポインタ付け替えだけを見れば O(1) だ。
だが、エンジニアとして見落としてはいけないのは「上書き先（Dest）のメモリ解放コスト」だ。
もし `new_key` がすでに存在しており、それが数百万要素を持つ巨大な Hash であったり、数百MBある大きな String だった場合どうなるか？
`RENAME` を実行した瞬間、古い `new_key` が保持していたメモリ領域を解放（Memory Deallocation）する処理が同期的に走る。
結果どうなるか？ Redisのメインスレッドがそのメモリ解放処理の間、完全にブロックされる。数ミリ秒から、場合によっては数百ミリ秒。高負荷なプロダクトにおいて、この「静寂（ブロック）」がどれほどの致命傷になるか、想像に難くないはずだ。
> 💡 テックリードからの教訓:
> 「キーのリネーム」は、対象のデータサイズが担保されている（あるいは極めて小さい）ことが確実な場合を除き、本番環境のホットパスで使うべきではない。特にマルチテナント環境や、動的にサイズが変わるオブジェクトを扱うキーに対しては厳禁だ。
アトミック性の保証
一方で、`RENAME` 系コマンドの美点はアトミック（不可分）であることだ。複数クライアントから同時にアクセスされても、レースコンディションの心配はない。
特に `RENAMENX`（Rename if Not Exists）は、競合を避けて安全にキーを移行したい場合には強力なプリミティブとなる。
—
2. MOVE：単一インスタンス内「DB間移動」のアンチパターン
次に `MOVE` コマンドだ。これは同一のRedisインスタンス内で、キーを別のデータベース番号（例: DB 0 から DB 1）へ移動させる。
現在のDBにある key1 を DB 1 に移動
MOVE key1 1
一見、「名前空間を綺麗に分けるために便利そうだな」と思うかもしれない。しかし、実務において `MOVE` は原則として「使用禁止（アンチパターン）」として設計すべきだ。
なぜ `MOVE` を使ってはいけないのか？
1. Redis Clusterとの完全な不整合
Redis Clusterモードでは、データベースの概念は `DB 0` しかサポートされていない（複数のDBを切り替えることは禁止されており、常にDB 0に強制される）。もし将来的にスケールアウトを見据えてCluter化するアーキテクチャに移行する場合、`MOVE` を使ったコードは全て書き直しになる。
2. キー空間の分離という幻想
Redisの `SELECT` によるDB分離は、キーの衝突を防ぐためのものであり、セキュリティやリソース分離の境界としては極めて弱い（全DBでメモリプールは共通）。
3. トランザクションやスクリプトでの扱いづらさ
Luaスクリプト内や `MULTI/EXEC` ブロックにおいて、複数DBにまたがる操作は設計を極端に複雑にし、思わぬバグを生む。
> 💡 テックリードからの教訓:
> データベースをまたぐデータ移行が必要なら、`MOVE` に頼るな。アプリケーション層で適切にキーのプレフィックス（例: `user:1000:session` や `cache:v2:1000`）を設計し、キーの削除と再作成、あるいは Lua スクリプトによるアトミックな操作で完結させるべきだ。RedisのDB番号変更は、レガシーなスタンドアロン構成のスクリプト以外では忘れていい。
—
3. 実務で直面する「安全なキー管理」の設計パターン
では、安全にキー名を変更したり、データを移行したい場合はどう設計すべきか。現場で使える実践的なパターンを伝授する。
パターン A: ゼロダウンタイム・キーマイグレーション（Blue/Green風アプローチ）
巨大なキー構造のデータを移行・リネームしたい場合、一発の `RENAME` は自殺行為だ。以下の手順で非同期に安全に移行せよ。
1. デュアルライト（Dual Write）期間の設置
アプリケーション層で、読み込みは旧キー、書き込みは旧キーと新キーの両方に行うコードを一時的にデプロイする。
2. バックグラウンドでのバルクコピー
`DUMP` コマンドと `RESTORE` コマンドを組み合わせる。これらはアトミックにデータをシリアライズ・デシリアライズするため、ネットワーク経由や別プロセスへの移行にも使える。
# 旧キーのバイナリ表現を取得（O(N)だが、データ構造そのものを安全に扱える）
DUMP old_key
# 取得したデータを新キーに復元（TTLも引き継げる）
RESTORE new_key 0 serialized_value
3. 切り替えと旧キーの削除
読み込み先を新キーに切り替えた後、旧キーを削除する。この際、巨大なキーの削除でブロックを防ぐために、`UNLINK` コマンドを使用すること（※ `DEL` ではなく非同期でメモリを解放する `UNLINK` を使うのが現代のRedis運用の鉄則だ）。
—
まとめ
- `RENAME` / `RENAMENX`: アトミックで便利だが、上書き先のメモリ解放コスト（ブロッキング）に細心の注意を払え。
- `MOVE`: Redis Clusterとの互換性を捨て、技術的負債を生むだけのアンチパターンであるため、使うな。プレフィックス設計で解決しろ。
- 大規模データの操作: 単一コマンドの暴力に頼らず、`DUMP` / `RESTORE` や `UNLINK` を駆使した、メインスレッドをブロックしない設計を心がけろ。
コードは単に動くだけではゴミだ。システムの寿命、スケーラビリティ、そして障害時の挙動まで見通した上で、コマンドを選択してほしい。次のコードレビューでは、これらの知見が反映されていることを期待する。
コメント