【実務・中級編】メモリ削除ポリシー (Eviction Policies) – Redis

Redisメモリ削除ポリシーの深淵：なぜ「デフォルト設定」がシステムを殺すのか

Redisを単なる「爆速なKVS」と呼ぶのは、エンジニアとしてあまりに短絡的だ。Redisの真の価値は、メモリという有限なリソースを、極限のパフォーマンスを維持しながらどう制御し続けるかという「アーキテクチャの綱渡り」にある。

プロジェクトの現場で、「Redisが急に重くなった」「原因不明のレイテンシスパイクが起きている」という相談を受けるとき、その8割はメモリ削除ポリシー（Eviction Policy）の誤解に起因している。

今日は、教科書的な説明は省く。現場で生き残るための「Redisメモリ管理の哲学」を授ける。

—

`maxmemory-policy`は、単なる設定値ではない。これは「お前のアプリケーションにとって、どのデータが不要か」というビジネスロジックの投影だ。

allkeys-lru: 「最近使われていないものは、二度と使われないだろう」という仮定。汎用的だが、アクセスパターンが均一に近い場合、本来残すべき重要データまで消し去る。
volatile-lru: TTL（有効期限）が設定されたものだけを対象にする。これは「生存期間が短いものは重要度が低い」という設計意図がある場合にのみ有効だ。
allkeys-lfu: Redis 4.0以降の至宝。LRUが「時間」しか見ていないのに対し、LFUは「頻度」を見る。「たまにしかアクセスしないが、重要度は極めて高いデータ」をLRUから守るための防波堤だ。

結論: 大半のケースで、`allkeys-lru`を盲信するのはやめろ。アクセス頻度と重要度が正比例しないシステムでは、`allkeys-lfu`を第一候補に検討すべきだ。

—

ここが最も重要だ。Redisはシングルスレッドモデルである。メモリ上限に達したとき、Redisは新しいコマンドを処理する直前に、削除ポリシーに従って空きメモリを確保しようとする。

この「削除処理（Eviction）」の時間は、Redisのメインスレッドを占有する。

つまり、削除対象の候補が多ければ多いほど、また削除アルゴリズムが複雑であればあるほど、その分のレイテンシがアプリケーションに直撃する。

maxmemoryを物理メモリの限界まで設定するな: OSのバッファやスワップ発生を防ぐために、少なくとも20〜30%のバッファを確保せよ。
`maxmemory-samples`を安易に上げるな: 削除精度の向上のためにこの値を上げると、探索コストが指数関数的に増大する。デフォルトの5で十分だ。それ以上の精度が必要なら、アプリケーション設計を見直すべきフェーズである。

—

優秀なエンジニアは「メモリが溢れないこと」を祈るのではない。「溢れたときに何が消えるか」を設計する。

実行時の設定変更（再起動不要）
開発環境でアルゴリズムを試す際は、必ず INFO memory で経過を追え
CONFIG SET maxmemory-policy allkeys-lfu

特定の重要データ（ユーザーセッション等）には明示的にTTLを付与する
これにより、volatile-系ポリシーと組み合わせた制御が可能になる
SET session:user:123 “data” EX 3600

—

もし、あなたが運用しているRedisで「いつのまにか重要なデータが消えている」というアラートが頻発しているなら、それはポリシーの設定ミスではない。「キーの有効期限管理（TTL戦略）」の放棄だ。

メモリ削除ポリシーは、あくまで「最後の防波堤」である。本来であれば、アプリケーション側で「もう使わないデータ」を `DEL` するか、最初から適切な `TTL` を設計して「消滅させる」のが、プロフェッショナルなエンジニアの仕事だ。

Redisを「無限のゴミ箱」と勘違いしてはいけない。常にメモリの状態をモニタリングし、`evicted_keys`（削除されたキー数）のメトリクスをウォッチし続けろ。それが、あなたのシステムをダウンタイムから守る唯一の道だ。

設計には、常に「逃げ道」を作っておけ。それができる人間だけが、Redisを本当に使いこなしていると言える。