高トラフィックセッションストレージにおけるRedisのベストプラクティス

Redisは、高速でアプリインスタンス間で共有でき、一時的なキーの期限切れ処理に優れているため、高トラフィックなセッションストレージとしてよく選ばれます。ただし、無制限のメモリとして扱うと、重大な障害を引き起こします。

核心的な問題は単純です。すべてのセッションには有効期限が必要であり、Redisインスタンスには明確なメモリ境界が必要です。この両方がなければ、古いセッションが蓄積され、書き込みが失敗したり、レイテンシが急上昇したり、ホストがスワップを開始したりします。

まずメモリ制限を設定する

Redisをセッションストレージに使用する際の根本的なリスクは、メモリの肥大化です。セッションは一時的なものであるため、Redisインスタンスは完全なデータ保持よりも、安定性と自動クリーンアップを優先する必要があります。

maxmemory 制限の設定

本番トラフィックが到着する前に、ハードなメモリ制限を設定します。オペレーティングシステム、レプリカ、永続化フォークのオーバーヘッド（有効な場合）、トラフィックスパイクのために余裕を残します。多くのチームは、総RAMの下限から始め、used_memory、used_memory_rss、レイテンシ、エビクションメトリクスを監視しながら調整します。

# 16GB RAMのサーバーの例
maxmemory 12gb

エビクションポリシーの選択

Redisがmaxmemoryに達すると、maxmemory-policyが次に何が起こるかを制御します。インスタンスがセッションのみを保存するか、他のキーとスペースを共有するかに基づいてポリシーを選択します。

ポリシー	対象	セッションのユースケース
volatile-lru	有効期限が設定されたキー	Redisが一時的なセッションと一部の非セッションキーを保存する場合に適しています。
allkeys-lru	すべてのキー	Redisインスタンスがセッションストレージ専用の場合に適しています。
noeviction	自動エビクションなし	アプリがセッションをエビクトする代わりに書き込みを失敗させる必要がある場合のみ使用します。

maxmemory-policy volatile-lru

エビクションはバックアッププランであり、クリーンアップ戦略ではありません。通常の運用では、アプリケーション定義のTTLによってセッションを期限切れにする必要があります。

キーの有効期限をマスターする

すべてのセッションキーにはTTLが必要です。TTLの欠落は、Redisセッションメモリリークの最も一般的な原因の1つです。

作成時にTTLを強制する

値とTTLを1つのコマンドで設定します。最新のRedisはSET key value EX secondsをサポートしており、古いSETEXの例よりも柔軟です。

SET user:session:abc12345 '{"user_id":123,"role":"admin"}' EX 3600

フレームワークがスライディングセッションを使用する場合は、セッションを検証した後にのみTTLを更新します。

EXPIRE user:session:abc12345 3600

リクエストごとに大きなセッションブロブを書き換えることは避けてください。読み取り時にTTLを更新し、セッションの内容が変更された場合にのみ値を更新します。

運用のためのセッションキー設計

予測可能で名前空間化されたキーを使用します。

session:<tenant_id>:<session_id>

メールアドレス、名前、トークンをキー名に含めないでください。キーはログ、メトリクス、トレース、ダッシュボードに表示される可能性があります。IDの詳細は値に保持し、通常のアプリケーション制御で保護します。

全デバイスからのログアウトやアカウント侵害のワークフローのために、セカンダリルックアップを保存します。

user_sessions:<user_id> -> セッションIDのセット

これにより、アプリはキースペース全体をスキャンすることなく、1人のユーザーのすべてのセッションを削除できます。

セッションリスクに基づいて永続化を選択する

多くのアプリでは、セッションは再ログインで再作成できるため、Redisの永続化は無効にするか軽く保つことができます。カート、デバイスの信頼、長期セッションの場合、永続化はディスクI/Oの価値があります。

戦略	適している場合
永続化なし	セッションは使い捨てで、ログインは安価です。
RDBスナップショット	書き込みオーバーヘッドが低く、時折リカバリポイントが必要な場合。
AOF appendfsync everysec	より高い耐久性が必要で、より多くのディスクI/Oを受け入れられる場合。

依存する前に、再起動の動作をテストしてください。回復が遅いセッションストアは、すべてのアプリサーバーが同時に再接続すると、依然として障害を引き起こす可能性があります。

適切なシグナルを監視する

少なくとも以下を追跡します。

• used_memory と used_memory_rss
• evicted_keys
• expired_keys
• keyspace_hits と keyspace_misses
• コマンドレイテンシ
• 接続クライアント数

通常のトラフィック中にevicted_keysが上昇する場合、セッションTTLが長すぎるか、メモリ制限が低すぎるか、インスタンスが無関係なワークロードとスペースを共有している可能性があります。

まとめ

高トラフィックなRedisセッションストアには、アトミックなTTL、実際のmaxmemory制限、データ構成に一致するエビクションポリシー、そしてユーザーが不満を言う前にエビクションを検出する監視が必要です。短く明示的なセッション有効期間から始め、セッション値を小さく保ち、セッションがアプリにとって重要になったら専用のRedisデプロイメントを使用します。