効果的なRedisの削除ポリシー選択ガイド
Redisはそのインメモリ性質により、驚異的な速度で知られています。しかし、データセットが物理メモリの容量を超えてしまうと、Redisは新しいエントリのためのスペースを確保するために、古いデータや重要度の低いデータを積極的に削除する必要があります。このプロセスは削除ポリシー（Eviction Policies）によって管理され、パフォーマンスの維持とキャッシュの最適な動作の確保に不可欠です。適切なポリシーの選択は、キャッシュヒット率、レイテンシ、メモリ使用量に直接影響します。
このガイドでは、Redisに組み込まれている様々な削除ポリシーを探求し、それぞれの動作方法を説明するとともに、純粋なキャッシュシナリオから時系列データ管理に至るまで、さまざまなアプリケーションワークロードに最適な戦略を選択するための実践的なアドバイスを提供します。
Redisの削除と maxmemory の理解
削除ポリシーは、Redisのメモリ使用量が maxmemory 設定ディレクティブで指定された制限を超えた場合にのみ適用されます。maxmemory が設定されていない（または0に設定されている）場合、Redisは利用可能なすべてのメモリを使用し、削除は発生しません。これにより、ホストマシンがRAMを使い果たした場合、システムが不安定になる可能性があります。
削除を有効にするには、redis.conf ファイルまたは CONFIG SET コマンドで maxmemory を設定する必要があります。
# maxmemory を 2GB に設定
CONFIG SET maxmemory 2gb
メモリが制約されると、Redisは設定された削除ポリシーを使用して、書き込みコマンドがさらにメモリを必要とする際に、どのキーを破棄するかを決定します。
Redisの組み込み削除ポリシー
Redisにはいくつかの異なるポリシーがあります。これらは maxmemory-policy ディレクティブを使用して設定されます。ポリシーは一般的に2つのカテゴリに分類されます：Least Recently Used（LRU）またはLeast Frequently Used（LFU）に基づいたもの、そして有効期限（TTL）が設定されたキーを対象とするものです。
1. TTL要件のないポリシー
これらのポリシーは、データベース内のすべてのキーに対して、有効期限が設定されているかどうかにかかわらず動作します。
noeviction
これはデフォルトのポリシーです。メモリ制限に達すると、Redisは書き込みコマンド（SET、LPUSHなど）を拒否し、クライアントにエラーを返します。読み込み（GET）は引き続き許可されます。これは、データの損失が許容されないミッションクリティカルなデータに適していますが、高い書き込み圧力下ではアプリケーションエラーを引き起こす可能性があります。
allkeys-lru
メモリ使用量が maxmemory 制限を下回るまで、データベース内のすべてのキーの中から最も最近使用されていないキーを削除します。これは、すべてのデータ項目が同等にキャッシュ可能である汎用キャッシュの標準的な選択肢です。
allkeys-lfu
最も頻繁に使用されていないキーをすべての中から削除します。LFUは、最近アクセスされていなくても、頻繁にアクセスされるキーを保持することを優先します。これは、アクセスパターンが不安定である場合に効果的ですが、非常に人気のあるアイテムが永続的にメモリに残る可能性があります。
allkeys-random
メモリ制限が満たされるまで、ランダムに選択されたキーを削除します。データアクセスパターンが完全に均一で予測不可能でない限り、本番環境のキャッシュにはほとんど推奨されません。
2. TTLを必要とするポリシー（揮発性キー）
これらのポリシーは、明示的な有効期限（EXPIRE または SETEX）が設定されているキーのみを考慮します。削除を実行する際に、有効期限のないキーは無視します。
volatile-lru
有効期限が設定されているキーの中から、最も最近使用されていないキーを削除します。
volatile-lfu
有効期限が設定されているキーの中から、最も頻繁に使用されていないキーを削除します。
volatile-random
有効期限が設定されているキーの中から、ランダムなキーを削除します。
volatile-ttl
最も残りの有効期限（TTL）が短いキーから削除します。これは、セッショントークンや一時的なアプリケーション状態など、時間制約のあるデータに最適であり、期限切れ間近の古いデータが最初にクリーンアップされることを保証します。
ワークロードに最適なポリシーの選択
最適な削除ポリシーは、何をキャッシュしているかと、どのようにアプリケーションがそのデータを使用しているかに完全に依存します。
| ワークロードタイプ | 推奨ポリシー | 根拠 |
|---|---|---|
| 汎用キャッシュ (最も一般的) | allkeys-lru |
TTLに関係なく、古く未使用のデータから削除されるべきだと仮定します。シンプルで非常に効果的です。 |
| 時間制約のあるデータ (例：トークン、短命なセッション) | volatile-ttl |
期限切れ間近のキーが、実際に期限切れになる前に効率的にクリーンアップされることを保証します。 |
| ホットデータキャッシュ (高いアクセス偏り) | allkeys-lfu または volatile-lfu |
最近の非アクティビティのために、頻繁にアクセスされるアイテムが削除されるのを防ぎます。 |
| 必須データ保持 (損失不可) | noeviction |
書き込みをエラーアウトすることでデータ損失を防ぎ、手動介入または上位アプリケーションの処理を必要とします。 |
| 混合ワークロード (一部のデータは期限切れ、一部は期限切れなし) | volatile-lru または volatile-ttl |
有効期限のないキーが不可欠な場合、明示的に期限切れのキーのみを削除することで、それらを保護するために揮発性ポリシーを使用します。 |
実践例：セッションストアの実装
Redisを主にユーザーセッションの保存に使用する場合、通常は各セッションキーに明示的なTTL（例：30分）を設定し、TTLを尊重するポリシーを使用します。volatile-ttl は、セッションが頻繁に使用されている場合、数週間アクセスされていない別のセッションよりわずかに古いという理由だけで削除されるべきではないため、ここでしばしば優れています。
# 1. maxmemory を設定 (例：10GB)
CONFIG SET maxmemory 10gb
# 2. 時限データを対象とするポリシーを選択
CONFIG SET maxmemory-policy volatile-ttl
実践例：HTTPキャッシュの実装
HTTPレスポンス全体をキャッシュする場合（常にTTLが設定されているとは限りません）、数時間アクセスされていなくても、最も頻繁にアクセスされているデータを保持したいと考えます。allkeys-lru または allkeys-lfu が理想的です。
# 作成時間に関係なく、真に「ホット」なオブジェクトを保持するためにLFUを使用
CONFIG SET maxmemory-policy allkeys-lfu
モニタリングとチューニング
ポリシーを選択した後、継続的な監視が不可欠です。INFO コマンドを通じて以下のメトリクスを追跡する必要があります。
used_memory:maxmemory制限にどれだけ近いか。evicted_keys: Redisがデータを破棄するレート。常に高い削除レートは、maxmemory設定がワークロードに対して低すぎるか、削除ポリシーが過度に攻撃的であることを示唆します。- アプリケーションキャッシュヒット率: 成功の最終的な尺度。メモリ圧力が増加したときにヒット率が低下する場合、ポリシーの選択または
maxmemory制限の調整が必要です。
ベストプラクティス:
maxmemoryをチューニングする際は、レプリケーションバッファリング、コマンドバッファリング、およびRedisの内部データ構造からの潜在的なオーバーヘッドを考慮するために、常に安全バッファ（例：10-20%の空きメモリ）を残しておきます。
結論
Redisの削除ポリシーは、メモリ圧力下でのキャッシュの動作を細かく制御します。「最良」の単一ポリシーは存在しません。LRU、LFU、またはTTLベースの削除の選択は、データアクセスパターンとビジネス要件に正確に一致する必要があります。適切なポリシー（例：汎用キャッシュにはallkeys-lru、セッションストアにはvolatile-ttl）を慎重に選択することで、キャッシュ効率を最大化し、高速なデータ操作のための堅牢なパフォーマンスを確保できます。