【実務・中級編】キー管理コマンド – Redis

Redisキー管理：その「当たり前」の背後に潜むパフォーマンスの罠を読み解く

Redisを単なる「高速なKVS」と捉えているなら、それは宝の持ち腐れだ。システムがスケールした瞬間、君たちが何気なく叩いたその `DEL` や `KEYS` が、メインスレッドを凍りつかせ、レイテンシスパイクを引き起こす。

今日は、Redisのキー管理という「基本中の基本」を、実務レベルの極限まで掘り下げて解説する。コードレビューで私が「なぜそのコマンドを選んだのか？」と問うとき、君たちには即座にアーキテクチャの根拠を答えてほしい。

—

1. 「破壊的」なコマンドとの付き合い方：DEL と UNLINK

`DEL` コマンドは、キーを削除してメモリを即座に開放する。しかし、巨大なハッシュや数百万の要素を持つセットを `DEL` するとどうなるか？

Redisはシングルスレッドで動作する。巨大なオブジェクトのメモリ解放には時間がかかる。その間、Redisは全てのクライアントからのリクエストをブロックする。これが「Stop-the-world」の正体だ。

解決策：UNLINK を使え
`UNLINK` は、キーのメタデータを即座に削除し、実際のメモリ解放（reclaim）をバックグラウンドスレッド（BIO）に委譲する。

巨大なリストを削除する場合
DEL my_huge_list <-- これはNG。レイテンシスパイクの原因。 UNLINK my_huge_list # OK。非同期解放でメインスレッドを保護する。実務設計では、「キーのサイズを予測できないなら `DEL` は使うな」とチームに徹底させること。それが安定稼働の鉄則だ。 ---

2. キーの探索：KEYS は「禁断の果実」

本番環境で `KEYS ` を打った瞬間、私は君を止めるだろう。`KEYS` は O(N) の計算量を持ち、全キー空間を走査する。数千万件のキーがある環境でこれを打てば、システムは数秒から数十秒停止する。

解決策：SCAN によるイテレーティブな走査
`SCAN` はカーソルベースの走査を行う。一度に全キーを舐めるのではなく、少しずつ、効率的にキーを取得する。

スキャンを開始（カーソル0からスタート）
SCAN 0 MATCH “user:session:” COUNT 100
戻り値: [“123”, [“user:session:1”, “user:session:2”]]
次は “123” を使ってSCANを継続する

「本番環境で `KEYS` を打つのは、走行中のF1マシンのエンジンにレンチを投げ込むのと同じ」と心得ておけ。

—

3. 寿命の管理：EXPIRE と PERSIST の戦略的運用

キーに TTL（Time To Live）を設定することは、メモリリークを防ぐための最低限の作法だ。だが、ここでも設計の差が出る。

SET EX / PX 拡張を使う:

`SET key value` の後に `EXPIRE` を呼ぶのは、2回のネットワークラウンドトリップが発生する。アトミックな `SET key value EX 3600` を使うのが、モダンなRedis設計の基本だ。

PERSIST の罠:

`PERSIST` で TTL を解除する際は、そのキーが本当に永続化すべきものか自問すること。メモリの肥大化は、往々にして「期限切れ忘れ」から始まる。

—

4. 型の動的確認：TYPE と OBJECT

`TYPE` コマンドは、アプリケーション側のデバッグや、汎用的なモジュールを書く際に必須だ。

キーの型を確認
TYPE user:1001
-> “hash”

しかし、運用においてより重要なのは「メモリ使用量」の把握だ。`MEMORY USAGE` コマンドを使い、特定のキーがどれだけのメモリを占有しているかを監視する設計を組み込んでおけ。特に、Redisのメモリ制限（`maxmemory`）を超えた後の `eviction policy`（LRU/LFU）の挙動を左右するのは、このサイズ感の把握だ。

—

5. 設計レビューで問うべき「堅牢なキー管理」のチェックリスト

最後に、君たちがコードを書く際に自問すべきチェックリストを置いておく。

1. 名前空間（Namespace）は衝突していないか？
`user:1001:profile` のようにコロン区切りで階層化し、`SCAN` でのフィルタリングを容易にしているか。
2. 削除対象は「巨大」ではないか？
`UNLINK` を使うべき場面で `DEL` を使っていないか。
3. キーを全走査する必要があるか？
もしあるなら、それは設計を見直すべきサインだ。Redisのキーを全走査するのは、RDBで言えばフルテーブルスキャンを常に実行しているようなものだ。
4. RENAME はリスクを考慮しているか？
`RENAME` はキーの移動ではなく「上書き」を伴う。意図しないキーの消滅を避けるため、`RENAMENX`（キーが存在しない場合のみリネーム）を検討せよ。

—

最後に：エンジニアとしての矜持

Redisは極めてシンプルだ。しかし、そのシンプルさゆえに、使い手の習熟度がパフォーマンスに直結する。

「動くコード」を書くのはジュニアでもできる。だが、「数億リクエストを捌いても、ミリ秒単位の安定性を維持し続ける設計」ができるのは、Redisの内部挙動を深く理解したエンジニアだけだ。

今日からコマンドを打つ前に、一度だけ立ち止まって考えてみてほしい。そのコマンドは、Redisの心臓部（メインスレッド）をどれだけ揺らすのかを。

それが、一流のエンジニアへの第一歩だ。