効果的なRedisエビクションポリシー選択ガイド

Redisはデータをメモリに保持するため高速ですが、メモリには限りがあります。Redisインスタンスがmaxmemoryに達すると、エビクションポリシーによって、Redisがキーを削除するか、書き込みを拒否するか、または有効期限のあるキーのみを削除するかが決まります。

効果的なRedisエビクションポリシーの選択は、Redisがキャッシュ、セッションストア、または混合使用データストアとして機能する場合に最も重要です。間違ったポリシーは重要なキーを削除したり、トラフィックの急増時に書き込みを失敗させたりする可能性があります。

---

Redisエビクションとmaxmemoryの理解

エビクションポリシーは、Redisのメモリ使用量がmaxmemory設定ディレクティブで設定された制限を超えた場合にのみ機能します。maxmemoryが設定されていないか0に設定されている場合、Redisは通常の書き込みにメモリ制限を適用しません。専用ホストでは、これが最終的にオペレーティングシステムのメモリプレッシャーにつながる可能性があるため、本番キャッシュデプロイメントでは通常、明示的な制限を設定します。

エビクションを有効にするには、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) に基づくもの、およびTime To Live (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	残りTTLが最も短いキーを優先的に削除します。
ホットデータキャッシュ（高いアクセス偏り）	allkeys-lfu または volatile-lfu	頻繁にアクセスされるアイテムが、最近の非アクティブのために削除されるのを防ぎます。
必須データ保持（損失不可）	noeviction	書き込みをエラーにすることでデータ損失を防ぎ、手動介入または上流アプリケーションの処理を必要とします。
混合ワークロード（一部のデータは期限切れ、一部はしない）	volatile-lru、volatile-lfu、または volatile-ttl	期限切れでないキーが必須の場合、揮発性ポリシーを使用して、明示的に期限切れになるキーのみを削除することでそれらを保護します。

実践例：セッションストアの実装

Redisが主にユーザーセッションを保存するために使用される場合、すべてのセッションキーに30分などの明示的なTTLを設定します。volatile-ttlは、残りの有効期間が最も重要なシグナルである場合に機能します。アプリケーションがアクティビティに応じてセッションTTLを更新する場合、アクティブなセッションは自然に長い残りTTLを維持します。TTLを更新しない場合は、代わりにvolatile-lruまたはvolatile-lfuを検討してください。

# 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％の空きメモリ）を残してください。

最終的なポイント

汎用キャッシュにはallkeys-lru、小さなホットキーのセットがトラフィックを支配する場合はallkeys-lfu、期限切れでないキーを保護する必要がある場合にのみvolatile-*ポリシーから始めてください。その後、ポリシーを完了する前に、負荷がかかった状態でevicted_keys、アプリケーションヒット率、および書き込みエラーを監視してください。