Redisセッションストアの設計 - TTLと複数台構成を理解する

中級 | 13分 で読める | 2026.06.27

公式ドキュメント
RedisAuthInfra

Redisをセッションストアにする理由

アプリサーバーが1台だけなら、メモリにセッションを置いても動きます。しかし、本番では複数台構成、再起動、デプロイ、オートスケールがあります。

Redisセッションストアは、複数のアプリサーバーが同じログイン状態を共有するための高速な保存先です。

Browser
  -> App Server A
  -> App Server B
  -> Redis

Redisを使うと、AでログインしてBにアクセスしても同じセッションを読めます。

key設計

基本形は、セッションIDをkeyにします。

session:{session_id}

値には、認証に必要な最小限の情報を入れます。

{
  "userId": "user_001",
  "role": "student",
  "loginAt": "2026-06-27T10:00:00.000Z",
  "lastSeenAt": "2026-06-27T10:20:00.000Z",
  "authLevel": "password"
}

セッションIDそのものが十分にランダムなら、keyにユーザーIDを含める必要はありません。管理用途でユーザーごとのセッション一覧が必要な場合は、別keyを持ちます。

user_sessions:user_001 = Set(session_a, session_b, session_c)

TTLを必ず設定する

セッションkeyにはTTLを付けます。

SET session:abc123 "{...}" EX 7200

TTLがないセッションは、ログアウトされない限り残り続けます。長期間残るセッションは、容量だけでなくセキュリティ上も問題になります。

期限設計:

種類例
短めの通常セッション2時間
管理画面30分
Remember me復帰後通常セッションは短命にする
Absolute timeoutRedis値の中に別途保持

RedisのTTLはidle timeoutに使いやすいですが、absolute timeoutは値の中にも持つと制御しやすくなります。

sliding expiration

sliding expiration は、アクセスがあるたびにTTLを延長する方式です。

GET session:abc123
EXPIRE session:abc123 7200

便利ですが、全リクエストで延長するとRedis負荷が増えます。CSSや画像、ヘルスチェック、バックグラウンド通信でセッションが延命されるのも問題です。

実務では、次のように調整します。

  • 認証が必要なHTML/APIだけ延長する
  • 最終延長から一定時間経った場合だけ延長する
  • lastExtendedAt を持つ
  • absolute timeoutを別に持つ
  • 重要操作は再認証を求める

例:

TTL 7200秒
延長は10分に1回まで
ログインから24時間を超えたら再ログイン

Redis eviction に注意する

RedisはメモリDBです。メモリが足りなくなると、設定によってkeyが追い出されることがあります。

セッションストアで危険なのは、ユーザーが突然ログアウトされることです。

確認すること:

  • maxmemory が適切か
  • maxmemory-policy が意図通りか
  • セッション以外のキャッシュと同じRedisに入れていないか
  • evictionが監視されているか
  • セッション数と平均サイズを見積もっているか

キャッシュは消えても再計算できますが、セッションが消えるとログイン状態に影響します。セッション用Redisとキャッシュ用Redisを分ける設計もあります。

Redis再起動と永続化

Redisを再起動したとき、セッションをどう扱うか決めておきます。

方針特徴
永続化なし再起動で全員ログアウト、シンプル
RDB/AOFあり再起動後もある程度残せる
RDBMS併用監査や長期管理がしやすい

セッションは消えても再ログインすればよいデータなので、永続化しない判断もあります。ただし、障害時に全ユーザーがログアウトされる影響を許容できるかはサービス次第です。

複数台構成での注意

Redisを共有ストアにすれば、sticky sessionに依存しなくてもログイン状態を共有できます。

App A -> Redis
App B -> Redis
App C -> Redis

ただし、次の設定は全アプリサーバーで揃える必要があります。

  • Cookie名
  • Cookie署名鍵
  • セッションID生成方式
  • Redis接続先
  • シリアライズ形式
  • TTL

署名付きCookieを使っている場合、署名鍵がサーバーごとに違うと、Aで発行したCookieをBで読めません。

セッション値に入れすぎない

Redisは高速ですが、セッションに何でも入れる設計は避けます。

避けたいもの:

  • 大きなプロフィール情報
  • 権限一覧を大量に入れる
  • 外部APIの長期トークン
  • 個人情報の詳細
  • カート明細を無制限に入れる

セッションには、認証判断に必要な最小限を入れます。詳細情報はDBから読む、または短時間キャッシュとして別keyに分けます。

ログアウトと全端末ログアウト

単一セッションのログアウト:

DEL session:abc123
SREM user_sessions:user_001 abc123

全端末ログアウト:

SMEMBERS user_sessions:user_001
DEL session:a session:b session:c
DEL user_sessions:user_001

user_sessions のSetにもTTLや掃除処理を考えます。セッション本体が期限切れになっても、Setに古いIDだけ残ることがあるためです。

監視する指標

Redisセッションストアでは、次の指標を見ます。

  • 接続数
  • メモリ使用量
  • key数
  • eviction数
  • expired key数
  • レイテンシ
  • Redisエラー率
  • セッション取得失敗率
  • ログイン直後の未ログイン戻り率

「Redisが少し遅い」だけでも、全画面の認証チェックに影響します。

まとめ

Redisセッションストアは、本番のCookieセッションでよく使われます。ただし、単にRedisへ保存するだけでは足りません。

  • key設計を決める
  • TTLを必ず設定する
  • sliding expirationを雑に延長しない
  • evictionと再起動時の方針を決める
  • 複数台でCookie署名鍵や設定を揃える
  • セッション値に情報を入れすぎない
  • 全端末ログアウトと監視を設計する

Redisは速い保存先ですが、認証の根幹に置くなら運用設計まで含めて考えます。

参考リソース

次に読む記事

おすすめ記事

← 一覧に戻る
PR
PR
PR
PR