データベース

RedisのLFUとLRU：どちらのエヴィクションポリシーが適切か？

RedisのLFUとLRUは、リソースが不足している際にどのキーをキャッシュから削除するかを決定し、それによって ヒット率, 、応答時間、およびメモリ使用量。アクセス頻度を重視するポリシー「LFU」と、最新性を重視するポリシー「LRU」のどちらが適しているか、その設定方法、そして「allkeys-lfu」と「allkeys-lru」が実際の運用でどのような効果をもたらすかについて解説します。注目キーワード Redis LFU そこが核心である。.

中心点

レセンシー 対 周波数: LRUは最新のアクセスを優先し、LFUは頻繁なアクセスを優先する。.
近似 Redisでは：どちらのポリシーも、maxmemory-samples によるサンプリングを用いて動作します。.
ワークロード 選択：セッション／ダッシュボード → LRU、ベストセラー／ランキング → LFU。.
チューニング 重要な点：lfu-decay-time、maxmemory、maxmemory-samples を適切に設定する。.
モニタリング 必要事項：ヒット率、1秒あたりのエヴィクション数、およびレイテンシを継続的に監視すること。.

Redisにおけるエヴィクションの仕組み

RedisはデータをRAMに保持しており、プロセスが maxmemory, 、キーを削除する必要があります。まさにここで、どのエントリを削除するかを決定する「allkeys-lru」や「allkeys-lfu」といったポリシーが適用されます。私がこれら2つの方式に焦点を当てているのは、TTLが設定されたキーだけでなく、データセット全体を考慮に入れるためです。Redisは、次のように指定したサンプリングに基づいて、削除するキーを選択します。 maxmemory-samples 制御します。サンプル数を増やすと精度は向上しますが、CPU負荷も高まります。このアプローチは、管理コストを過度に増やすことなく、大規模なキースペースにおいて良好な結果をもたらします。.

内部事情：RedisがLRUとLFUをどのように実装しているか

どちらのポリシーもRedisで動作します おおよそ, 、一貫して高速な処理を維持するためです。LRUは、オブジェクトごとに最終アクセス時刻を記録します。エヴィクションの際、Redisはサンプリングを行い、その中から「最も古い」候補を破棄します。これは、キースペースに合わせてサンプリングサイズを適切に選択すれば、実際には非常に効率的であり、十分な精度が得られます。.

Redis LFU このアイデアに、さらに コンパクトな周波数メトリクス, 、時間の経過とともに 経年変化する (Decay)。アクセスが行われるたびに、利用回数のカウンターは非線形に増加するのではなく、減衰しながら増加するため、個々のアクセス集中によってカウンターが恒久的に飽和してしまうことを防ぎます。同時に、時間の経過に伴う減衰により、過去の人気はいつかは重要性を失うようになります。以下のようなパラメータを通じて lfu-減衰時間 （履歴がどれくらいの速さで古くなるか）と内部のログ係数（アクセスごとにカウンターがどれほど増えるか）をバランスさせる 反応の良さ にとって 安定性 優先順位の決定。覚えておくべきポイント：デケイ値が小さいほど→調整が速く、値が大きいほど→調整は遅くなるが、優先順位は安定する。.

RedisにおけるLRU：仕組み、メリット、注意点

LRUは最も長く経過したものを削除する 未使用の キーに基づいて最新性を優先します。このロジックは、セッション、ライブダッシュボード、あるいは短期間のAPI応答など、時間的な局所性を持つパターンに適しています。Redisは近似LRUを採用しています。エントリにはタイムスタンプが付与され、サンプリングによって最も古い候補が選択されます。この処理は高速かつ追跡可能です。 LRUは、最近使用されたキーが上位に残り、古いキーが排除されるため、変更に迅速に対応します。ただし、大規模な一括スキャンは問題となる可能性があります。これにより、キャッシュが一時的な値で埋め尽くされ、一時的に使用されていない重要なキーが 押しのける.

実用的なヒント：LRU を使用していて、定期的に「コールド」な一括クエリ（バックオフィスレポートなど）を実行する場合は、これらのワークロードを 別個の キャッシュを配置するか、あるいはより広範囲な計画を立てる maxmemory-予備領域を確保する。そうすることで、価値があり、まもなく再び必要となるデータが押し出されてしまう「キャッシュ汚染」を防ぐことができる。.

RedisにおけるLFU：原理、利点、落とし穴

LFUは、重要度の低いキーを削除します 利用頻度 これにより、長期にわたる「ホットキー」を保護します。内部カウンターは対数関数的に増加し、時間の経過とともに減衰（Decay）するため、過去の人気度がいつまでも影響し続けることはありません。その結果、バランスが取れた重み付けが実現されます：頻繁に使用されるデータはより長く保持され、個々の異常値は優先順位にほとんど影響を与えません。LFUは、実績のあるキーをメモリに保持するため、カタログ、ランキング、またはフィーチャーキャッシュにおいて、多くの場合、より高いヒット率を実現します。しかし、新しいトレンドへの反応は比較的緩やかであるため、チューニングは lfu-減衰時間 重要なのは、やはり――。.

のために オン／オフのトレンド （例：マーケティングキャンペーン）の場合、新たなトレンドが顕著な影響を与える一方で、一時的なノイズによってキャッシュが絶えず再編成されることがないよう、ディケイを設定してください。多くのプロジェクトで有効な手法として、最初は控えめに開始し、負荷がかかった状態でもヒット率が安定するまで段階的に加速させていくことが挙げられます。.

比較：日常生活における「レセンシー」と「フリークエンシー」

本質的には、LRU（「最後に使用されたのはいつか」）とLFU（「使用回数はいくらか」）を区別する――私は実際の使用状況に基づいて選択する ワークロード. 。揮発性が高く、ユーザーに近いデータの場合、最近のアクセスが将来のアクセスを予見することが多いため、LRUの方が自然な動作となることが多い。一方、人気のある製品データや設定については、持続的な人気が重要となるため、LFUの方が適している。混合シナリオでは、データタイプごとにキャッシュを分け、異なるポリシーを適用します。以下の表は、その違いを簡潔にまとめ、一目で把握できるようにしています。 意思決定支援.

アスペクト	LRU (allkeys-lru)	LFU (allkeys-lfu)
優先順位	実際アクセス数	頻度アクセス数
パターンの変化に対する反応	急いで！最後の利用がカウントされるから	歴史的要因が影響しているため、穏やかである
推奨ワークロード	セッション、ダッシュボード、ライブAPI	ベストセラー、ランキング、注目キャッシュ
「汚染」に対する感受性„	大規模なスキャンでは比較的高い	周波数カウンターによるため、比較的少ない
チューニング用ネジ	maxmemory-samples	lfu-減衰時間, maxmemory-samples
説明可能性	非常に直感的	さて、Decayについてですが

実運用におけるパフォーマンスへの影響

データセットが小さい場合、その差はしばしばロー; 規模が大きくなるにつれて、玉石混交の状態が明らかになります。LRUは、近似処理にかかるCPU負荷が低く、原因が明確である点が魅力です。つまり、最後に使用されなかったキーが削除されるのです。一方、LFUは一貫したアクセスにおいて優れており、ホットキーが確実にRAMに残るため、ヒット率が測定可能なほど向上します。その代償として、カウンターやデケイについて十分な理解が必要であり、それによって反応が鈍すぎたり、逆に過度に積極的になりすぎたりしないようにする必要があります。私は、単なる感覚に頼るのではなく、プロファイリングやメトリクスを使ってその効果を検証しています。 決定する.

さらに、以下のことも計画してください。 コールドスタート 1：再起動やデプロイ後、キャッシュは空の状態、あるいはアクセス頻度の情報を「持たない」状態になります。LRUは短期的な局所性によって素早く安定します。一方、LFUは本質的に、真のホットキーを特定するために一定のウォームアップ時間を必要とします。以下のような戦略は プレウォーミング （重要なキーを事前に読み込む）ことや、段階的なトラフィックの増加は、初期のレイテンシやミスを軽減するのに役立ちます。.

設定とチューニング：主なオプション

私は以下の方法でポリシーを選択します maxmemory-policy, 、典型的にはallkeys-lruやallkeys-lfuであり、TTLに重点を置いたvolatileのバリエーションは比較的珍しい。 maxmemory エヴィクションが開始される閾値を厳密に設定し、データセットの規模と安全マージンに基づいてその閾値を調整します。サンプリングサイズは、以下を通じて制御します。 maxmemory-samples; 値を高くすると選択精度が向上しますが、CPUリソースを消費します。LFUの場合、 lfu-減衰時間 これは、古いアクセスがどのくらいの速さで重みを失い、新しいアクセスがどのくらいの速さで重みを得るかを決定するため、極めて重要です。ストレージの容量設定に関する詳細な手順はこちらをご覧ください：ストレージを最適に構成する.

実践に向けた具体的な方法

素早く開発を開始できるよう、明確なデフォルト設定を用いて、負荷をかけた状態で反復開発を行っています：

allkeys-lru + maxmemory-samples 7～10（揮発性でユーザーに近いデータ向け）
Redis LFU (allkeys-lfu) + lfu-decay-time を控えめ（例：適度な値）に設定し、安定したホットキーのワークロードを実現

実行時に設定を行う：

CONFIG SET maxmemory 8gb
CONFIG SET maxmemory-policy allkeys-lru
CONFIG SET maxmemory-samples 10
# LFUへの切り替え：
CONFIG SET maxmemory-policy allkeys-lfu
CONFIG SET lfu-decay-time 5

redis.conf では、これらのオプションを恒久的に設定します。変更内容は、本番環境に適用する前に、まずステージング環境で代表的な負荷をかけてテストします。.

標本サイズの選択

maxmemory-samples これは信頼性の高い調整パラメータです。値を高く設定すると、エヴィクション候補の選定精度が向上しますが、CPU負荷も増えます。経験則として、大規模なキースペースでは7～10から始め、CPU時間が不足してきた場合にのみ値を下げるようにしています。小規模なキースペースでは、多くの場合5回のサンプリングで十分です。.

モニタリングと指標：推測ではなく測定を

私は常に観察している ヒット率, 、エヴィクション数、レイテンシ、メモリ使用量を分析し、それらの相互作用を評価します。エヴィクションが急増した場合は、RAMの空き容量、TTL戦略、および選択されたポリシーを確認します。ヒット率の低下は、多くの場合、パターンの変化によって現在のポリシーが弱まっているか、データセットが十分に分離されてキャッシュされていないことを示しています。レイテンシの急上昇は、場合によっては、 サンプル あるいは、エヴィクションが過度に積極的になりすぎるのを防ぐためです。定期的な負荷テストを行うことで、CPU負荷、メモリ制限、ヒット率の適切なバランスを見極めることができます。.

手っ取り早く確認するための便利なコマンド：

INFO stats     # keyspace_hits, keyspace_misses, evicted_keys, expired_keys
INFO memory    # used_memory, fragmentation, allocator_overhead
LATENCY DOCTOR # ピークに関する注記（例：フォークやI/Oなど）

仝 ヒット率 私はこれを「ヒット数 / (ヒット数 + ミス数)」として計算しています。立ち退き件数が増加している中でこの比率が低下していることは、警告のサインです。. evicted_keys トラフィックとの関連において、および 使用メモリ ポリシーが頻繁に有効になる必要があるかどうかを示します。 MEMORY USAGE キー キャッシュを不釣り合いに占めている、大きすぎるオブジェクトを特定します。.

ホスティングとスケーラビリティの観点：プラットフォームを慎重に選ぶ

Redisはその強みを、ある環境で発揮します。 高性能な RAMが十分にあり、レイテンシが低く、ネットワーク接続が安定しているプラットフォーム。プロジェクトが拡大するにつれ、フル負荷での連続稼働は避けています。そうしないと、エヴィクションが頻繁に発生し、ヒット率が低下してしまうからです。優れたホスティング戦略必要に応じてポリシーが確実に機能し、常時稼働し続けることがないようにします。比較検討の際には、webhoster.deのようなプレミアムプロバイダーを重視しています。同社のインフラは高負荷にも問題なく対応し、計画的な容量確保を可能にします。その結果、プラットフォームではエヴィクションの減少やパフォーマンスの向上といったメリットが直接もたらされます。 応答時間 そして、より安定したパフォーマンスを実現します。.

クラスタおよびレプリカに関する側面

シャーディング構成（例：Redis Cluster）では、エヴィクションの決定が行われます ノードごと. つまり、ヘッドルーム、ポリシー、チューニングは「平均的に」ではなく、ノードごとに適切に設定する必要があります。スロット間で不均等に分散されたホットキーは、個々のノードを早期に限界まで追い込む可能性があります。したがって、シャードごとにバッファを計画し、ノードレベルでのエヴィクションを監視してください。レプリカは削除されたキーを含むデータ状態を引き継ぎます。負荷テストの際は、ポリシー自体の問題ではなく、追加のレプリケーションによってレイテンシが増加する可能性がある点に注意してください。.

TTL戦略と混合ポリシー

TTLを使えば、長持ちするものを守ることができる コンフィギュレーション そして、時間的制約のある短命なデータを優先します。volatile-lru や volatile-lfu を使用すると、Redis は有効期限が切れたキーのみを追い出します。これは、キャッシュと永続的な値が共存している場合に役立ちます。私はよくデータ型ごとにキャッシュを分けています。セッションはLRU、商品カタログはLFUとし、それぞれの強みを活かしています。TTLを賢く設定することで、古いエントリが不必要にRAMを占有したり、エヴィクションを引き起こしたりするのを防げます。そうすることで、有用なデータを失うことなく、メモリをクリーンな状態に保っています。 ホットキー を失う。.

重要：ポリシーは有効です インスタンスごと. データタイプごとに異なるポリシーを確実に適用するには、個別のRedisインスタンスを運用するか、明確に区切られたキャッシュを使用します。ネームスペースだけではポリシーは変更されませんが、対象を絞った無効化や測定には役立ちます。.

実務チェック：LRUから開始し、LFUへ段階的に移行

私はよく次のように書き始めます LRU, 、直感的で素早く結果が得られるからです。その後、恒久的なホットキーを持つキャッシュを特定し、選択的にLFUに切り替えます。この方法なら、データパターンが頻度ベースのロジックに真に有利に働く箇所のみを変更するため、リスクを最小限に抑えられます。カナリアテストやA/Bテストを用いて、切り替え前後のヒット率とレイテンシを測定します。このようにして、全体を一括で変更するのではなく、段階的に最適化を進めていきます。 プラットフォーム 一気に切り替える。.

実績のある移行パス

ベースラインを設定する：現在のヒット率、エヴィクション数、レイテンシの95パーセンタイルおよび99パーセンタイルを記録する。.
パイロットキャッシュの選択：安定性が高く、読み込み負荷の大きい領域で、明確なホットキーが設定されているもの。.
LFUを有効にする、, lfu-減衰時間 保守的に設定する、, maxmemory-samples 増加した。
ウォームアップの時間を確保し、数値が安定するまで様子を見る。.
指標を比較し、その後に少しずつチューニングを行う。.

アプリ（WordPressなど）でよくある落とし穴

コンテンツ管理システムでは、誤ったTTLや不適切な鍵すぐに「エヴィクション」の急増につながります。動的なページが意図せずキャッシュされていないか、あるいは値が大きすぎてメモリをオーバーしていないかを確認してください。公開後の無効化処理が適切に行われているか確認し、古いコンテンツが削除されて空き容量が確保されるようにしてください。CMS環境における典型的なエラー事例については、こちらのガイドが参考になります：オブジェクトキャッシュのエラー. 適切に無効化を行い、現実的なTTLを設定し、適切なポリシーを選択すれば、ヒット率は上昇し、 スピード 測定可能である。

実務におけるその他のアンチパターン：

大規模な単一物件 （例：巨大なJSONブロブ）が、多くの小さくて有用なキーを押し出してしまう。解決策：データを分割し、実際に使用されるセグメントのみをキャッシュする。.
カミナリ・ストーブ: 同じキーに対して同時に多数のミスが発生する。解決策：リクエストの統合／ロック、TTLのジッターを短くして、更新が分散して行われるようにする。.
スキャン・ポリューション: 再利用を行わないバッチ読み取り。解決策：別のインスタンス／ネームスペースを使用し、そちらでより大容量のメモリを割り当てたLRUキャッシュを設定するか、あるいは意図的にそのワークロードをキャッシュしないようにする。.
不明確な無効化: 古いバージョンがキャッシュを埋めてしまう。解決策：明確なキースキーマ（例：バージョンプレフィックス）と、決定論的な無効化パス。.

要約：私はどのように選択するか

をセットした。 LRU 最新性が将来のアクセスに対する最良のヒューリスティックとなる場合――セッション、ダッシュボード、ライブAPIなどがその例です。そこで私はこれを利用します LFU, 明確で永続的なホットキーが存在し、負荷のピーク時でもそれらを保護したい場合です。モニタリングにより、エヴィクションが過剰になっていないか、ヒット率が低下していないかを確認し、必要に応じてサンプル数、TTL、ディケイを調整します。適切なプラットフォームの選択、賢明なメモリ制限の設定、そしてデータ型ごとのキャッシュ分離を行うことで、常にパフォーマンスを最大限に引き出しています。これにより、キャッシュは高速で予測可能であり、アクセスパターンに最適化された状態が維持され、当て推量を一切必要としません。.