ようこそ、Redisの深淵なる世界へ。私はこの世界の設計図を書き、何万台ものサーバーが悲鳴を上げる現場を救ってきたチーフアーキテクトです。
今日は、Redisを扱う上で避けては通れない、しかし最も奥が深く面白い「メモリ管理」の話をしましょう。
Redisはデータを「メモリ」という、超高速ですが限られたスペースに保存します。机の上がすぐに書類でいっぱいになるように、Redisのメモリもいつかは満杯になります。その時、Redisは「どれを捨てて、どれを残すか」という究極の選択を迫られます。
この選択のルールを「エビクション（淘汰）ポリシー」と呼びますが、今日はその中でも最も賢いアルゴリズムの一つ、LFU（Least Frequently Used）について、優しく、かつ本質を突いた解説を贈ります。
—
1. 「最近使ったもの」か「よく使うもの」か
Redisには大きく分けて、2つの「捨て方の知恵」があります。
- LRU (Least Recently Used): 「最後に使ってから一番時間が経っているもの」を捨てる。
- LFU (Least Frequently Used): 「使われた回数が一番少ないもの」を捨てる。
例えてみましょう。あなたの家の本棚が一杯だとします。
LRUは、「昨日読んだばかりの本」を残し、「1ヶ月間一度も手に取らなかった本」を捨てます。
LFUは、「たまにしか読まない本」を捨て、「毎日何度も参照する辞書」を、たとえ今日たまたま使っていなくても残します。
どちらが賢いでしょうか？ 答えは「データの性格による」のですが、「本当に人気があるデータ」を守り抜く力はLFUの方が圧倒的に強いのです。
—
2. LFUの魔法：回数を「賢く」数える仕組み
LFUは「アクセス頻度」で判断しますが、Redisは数億個のデータ（キー）を扱うこともあります。すべてのデータのアクセス回数を「1, 2, 3…」と正確にカウントしていたら、それだけでメモリを使い果たしてしまいます。
そこでRedisは、「8ビット（0〜255）」という非常に小さなスペースで頻度を管理する魔法を使っています。
頻度を「確率」で上げる
RedisのLFUカウンターは、1回アクセスしたからといって必ず「1」増えるわけではありません。カウンターの値が大きくなるほど、次にカウントを上げるのが難しくなる（確率的になる）仕組みです。
Redisの設定ファイル（redis.conf）のイメージ
どのくらい頻度を上げにくくするかを調整できます
lfu-log-factor 10
時間とともに「熱」を冷ます（衰退）
ずっと昔に100万回アクセスされたデータが、今でもずっと居座り続けるのは困りますよね？
LFUには「減衰（デケイ）」という仕組みがあります。時間が経つにつれて、少しずつカウンターの値を減らしていくのです。
何分経ったらカウンターを「1」減らすかの設定
lfu-decay-time 1
これにより、「かつての人気者」ではなく「今の人気者」が優先的に残るようになります。
—
3. `volatile-lfu` と `allkeys-lfu` の違い
LFUを使おうと決めたとき、あなたは2つの選択肢に出会います。
| 設定名 | 捨てる対象の範囲 |
| :— | :— |
| `volatile-lfu` | 期限付き（Expire設定あり）のデータの中から、頻度が低いものを捨てる |
| `allkeys-lfu` | すべてのデータの中から、期限の有無に関わらず頻度が低いものを捨てる |
- `volatile-lfu` を選ぶのは、「消えてもいい一時的なキャッシュ」と「絶対に消したくないマスターデータ」を混在させている時です。
- `allkeys-lfu` を選ぶのは、Redisを純粋なキャッシュサーバーとして使い、すべてのデータが「人気度」で競い合うようにしたい時です。
—
4. 実践：LFUを動かしてみよう
実際に設定する方法を見てみましょう。Redisのコマンドラインからでも、魔法の呪文を唱えるだけで切り替えられます。
1. メモリがいっぱいになった時のポリシーを allkeys-lfu に設定
CONFIG SET maxmemory-policy allkeys-lfu
2. メモリの最大容量を制限（例：100メガバイト）
CONFIG SET maxmemory 100mb
3. 現在の設定を確認
CONFIG GET maxmemory-policy
結果: “allkeys-lfu”
この設定をした瞬間、Redisは「アクセス頻度の低いものから順に、お掃除を開始する」準備を整えます。
—
5. LRUとLFU、どっちを選べばいいの？
ここがエンジニアとしての腕の見せ所です。
- LRUが向いているケース:
- データの人気が「移り変わりやすい」とき。
- 「さっきアクセスされたものは、すぐまた使われる」という傾向（時間的局所性）が強いとき。
- 迷ったらまずはLRU（`allkeys-lru`）から始めるのが定石です。
- LFUが向いているケース:
- 「常にずっと人気があるデータ」と「たまにしか呼ばれないデータ」がはっきり分かれているとき。
- 一時的な大量アクセス（スキャン）によって、本当に大事なデータが追い出されるのを防ぎたいとき。
—
最後に：あなたへのメッセージ
Redisのメモリ管理を理解することは、限られたリソースの中で「価値を最大化する」という、エンジニアリングの本質を学ぶことです。
`allkeys-lfu` を設定し、データが生き生きと循環し、人気のあるデータがしっかりとメモリに居座る様子を想像してみてください。それはまるで、活気ある街の交差点のように、最適化された美しい光景です。
ここまでの仕組みを理解できたなら、あなたはもう「なんとなくRedisを使っている人」ではありません。データの寿命を司る、立派なアーキテクトの第一歩を踏み出しました。
この基本をマスターすれば、より複雑なパフォーマンスチューニングの世界も、きっと楽しんで歩んでいけるはずですよ。応援しています！
コメント