【入門編】ランダム淘汰ポリシー – Redis

ようこそ、Redisという奥深い世界へ。私は長年、巨大なシステムの心臓部としてRedisを操ってきたアーキテクトです。

「Redisを使い始めたけれど、メモリがいっぱいになったらどうすればいいんだろう？」
「LRUとかLFUとか難しい言葉が出てきて、どれを選べばいいか迷ってしまう……」

そんな悩みを持っているあなたに、今日はあえて「ランダム（Random）」という、一見すると無計画で不器用に見える、でも実はとてつもなくパワフルな戦略についてお話ししましょう。

ここをマスターすれば、あなたはRedisのメモリ管理の本質を掴んだも同然ですよ。

—

Redisはデータをメモリ（作業机のようなもの）に保存するので、非常に高速です。でも、机の広さには限りがありますよね。新しい書類を置きたいのに机がいっぱい……そんな時、Redisは「古い書類をどれか捨てる」という決断をします。

このお片付けのルールのことを「エビクション・ポリシー（淘汰ポリシー）」と呼びます。

一般的には「最近使っていないものを捨てる（LRU）」や「あまり使われていないものを捨てる（LFU）」が賢いとされていますが、今回紹介するのは、あえて「サイコロを振って適当に選ぶ」という戦略です。

「せっかくなら、使っていないものを選んで捨てたほうが効率的なんじゃない？」と思うかもしれません。確かにその通り。でも、実は「ランダムの方が効率的になる特殊なケース」がエンジニアの世界には存在するのです。

それは、「どのデータも同じくらい大事（または同じくらいの頻度で呼ばれる）とき」です。

例えば、1000曲のヒットチャートをランダムに流す音楽配信サーバーを想像してください。
どの曲も同じくらいの確率で再生されます。この場合、「最近聴いたかどうか」には何の意味もありません。

LRU（賢いフリ）の場合: 「どの曲が最近聴かれたか」をいちいち記録し、計算します。でも結局、どの曲も平均的に呼ばれるので、計算するだけ無駄なコスト（CPUの無駄遣い）になります。
Random（潔い）の場合: 「どれでもいいや！」とサイコロを振って消します。計算コストはほぼゼロ。サーバーは余計なことを考えず、データの配信だけに集中できます。

プロの現場で私がランダムを選ぶのは、主に以下のようなシーンです。

データへのアクセスが特定の人気商品に集中せず、全体的にまんべんなくアクセスされる場合、LRU（最近使った順）などの計算は、実は「予測が外れ続ける」ことになります。予測が外れるくらいなら、最初から予測しない方が速いのです。

Redisは非常に高速ですが、メモリを捨てる際の「計算」にもわずかながらパワーを使います。超高負荷な環境では、そのわずかな計算さえも削りたい。そんな時、ランダムは「最も軽い」選択肢になります。

順番にデータを全部なめていくような処理（フルスキャン）が行われると、LRUは「全部最近使ったもの」と勘違いして、本当に大事なキャッシュを追い出してしまうことがあります。ランダムなら、スキャンに惑わされることなく、確率的にデータを守れます。

—

設定はとても簡単です。Redisの設定ファイル（`redis.conf`）を書き換えるか、動いているRedisにコマンドを送るだけです。

Redisにログインして、その場で設定を変更する魔法のコマンド
全てのキーからランダムに捨てる設定にする場合
127.0.0.1:6379> CONFIG SET maxmemory-policy allkeys-random

有効期限（TTL）がついているものだけをランダムに捨てる場合
127.0.0.1:6379> CONFIG SET maxmemory-policy volatile-random

現在の設定を確認する
127.0.0.1:6379> CONFIG GET maxmemory-policy
1) “maxmemory-policy”
2) “allkeys-random” <-- 無事に設定されましたね！

初心者のうちは「LRU（最近使っていないものを捨てる）」を選んでおけば、まず間違いはありません。それは優等生な選択です。

でも、もしあなたが将来、秒間何十万アクセスという荒波に揉まれるシステムを担当したとき、「データの価値がどれも平等なら、あえてランダムにする」という選択肢を思い出してください。

「あえて考えない」という高度な判断ができるようになったとき、あなたはもう初心者ではありません。

この基本をマスターすれば、Redisのメモリ管理の半分を理解したと言っても過言ではありません。次はぜひ、実際にデータをたくさん入れて、どう動くか観察してみてくださいね。応援していますよ！