Djangoセッションを最適化！cached_db以外の選択肢と使い分け

2025-05-27

django.contrib.sessions.backends.cached_db.SessionStore は、Django のセッション管理におけるバックエンドの一つです。これは、キャッシュとデータベースの両方を利用してセッションデータを保存する仕組みを提供します。

どのような仕組みか？

このバックエンドは、ライトスルーキャッシュという方式を採用しています。具体的には以下のようになります。

セッションの書き込み（保存）:
- セッションデータが更新されると、まずキャッシュに書き込まれ、その後にデータベースにも書き込まれます。
- この際、データベースへの書き込みが成功し、キャッシュへの書き込みが失敗しても、セッションデータの保存自体は成功したとみなされます（キャッシュへの書き込み失敗はログに記録されます）。これにより、セッションデータが失われるリスクを軽減します。
セッションの読み込み:
- セッションデータを読み込む際は、まずキャッシュからデータを取得しようとします。
- もしキャッシュにデータがない場合（キャッシュからデータが削除された場合など）は、データベースからデータを読み込みます。

なぜ `cached_db` を使うのか？

信頼性: 本番環境では、キャッシュだけではデータの信頼性に問題が生じる可能性があります。cached_db は、キャッシュの速度とデータベースの永続性を組み合わせることで、より信頼性の高いセッション管理を実現します。
データの永続性: 単純なキャッシュバックエンド（django.contrib.sessions.backends.cache）では、キャッシュが満杯になったり、キャッシュサーバーが再起動したりするとセッションデータが失われる可能性があります。しかし、cached_db はデータベースにもデータを保存するため、キャッシュがクリアされてもデータが失われる心配がありません。
パフォーマンスの向上: 頻繁にアクセスされるセッションデータはキャッシュに保存されるため、データベースへのアクセス回数を減らし、読み込み速度を向上させることができます。

設定方法

cached_db バックエンドを使用するには、Django の settings.py ファイルで SESSION_ENGINE を以下のように設定します。

# settings.py

SESSION_ENGINE = 'django.contrib.sessions.backends.cached_db'

また、データベースセッションを利用するため、INSTALLED_APPS に 'django.contrib.sessions' を追加し、python manage.py migrate を実行してセッションデータを格納するデータベーステーブルを作成しておく必要があります。

さらに、キャッシュシステムが適切に設定されていることも重要です（CACHES 設定）。通常、Redis や Memcached といった永続性のあるキャッシュバックエンドと組み合わせて使用することが推奨されます。

注意点

セッションデータは、デフォルトでは django_session というデータベーステーブルに保存されます。このテーブルのサイズは、セッションの利用状況に応じて増加する可能性があります。
cached_db はキャッシュとデータベースの両方に依存するため、両方のシステムが適切に動作していることを確認する必要があります。

cached_db はキャッシュとデータベースを組み合わせるため、両方のシステムが正しく設定・動作していることが重要です。

セッションデータが永続化されない / 頻繁に失われる

考えられる原因

複数アプリケーションインスタンスでの問題
- ロードバランサーの背後で複数のDjangoインスタンスが稼働している場合、各インスタンスが独立したキャッシュやデータベースを使用していると、セッションデータが共有されず、ユーザーが別のインスタンスにルーティングされるたびにセッションが失われたように見えることがあります。
セッションクッキーの問題
- ブラウザがセッションクッキーを受け入れていない（サードパーティクッキーのブロック、ブラウザの設定など）。
- SESSION_COOKIE_DOMAIN や SESSION_COOKIE_SECURE, SESSION_COOKIE_SAMESITE などの設定が、環境と一致していない。特にHTTPS環境で SESSION_COOKIE_SECURE = False は問題になることがあります。
- タイムゾーンの不一致などにより、セッションの有効期限が意図せず切れている。
SESSION_ENGINE の誤設定
- 'django.contrib.sessions.backends.cached_db' ではなく、単に 'django.contrib.sessions.backends.cache' が設定されている場合、データはキャッシュのみに保存され、永続性がないため失われる可能性があります。
データベースの問題
- データベースが停止している、またはアクセスできない。
- django_session テーブルが存在しない、または権限がない。
- データベースのディスク容量が不足している。
キャッシュサーバーの問題
- キャッシュサーバー（Redis, Memcachedなど）が停止している、またはアクセスできない。
- キャッシュサーバーのメモリが不足しているため、データが頻繁にエビクション（強制削除）されている。
- キャッシュサーバーの設定（例: maxmemory-policy in Redis）が、セッションデータを保持するのに適していない。

トラブルシューティング

キャッシュサーバーの確認
- キャッシュサーバーが稼働しているか確認します（例: redis-cli ping や systemctl status redis).
- キャッシュサーバーのログを確認し、エラーやエビクションの警告がないか確認します。
- キャッシュの空き容量を確認します。
- DjangoのCACHES設定が正しいか、特にLOCATIONやBACKENDが適切か確認します。
- SESSION_CACHE_ALIAS を使用している場合は、そのキャッシュエイリアスが正しく設定されているか確認します。
データベースの確認
- データベースが稼働しているか確認します。
- django.contrib.sessions が INSTALLED_APPS に含まれているか確認します。
- python manage.py migrate を実行し、django_session テーブルが作成されていることを確認します。
- データベースに直接接続し、django_session テーブルにセッションデータが書き込まれているか確認します。
settings.py の確認
- SESSION_ENGINE = 'django.contrib.sessions.backends.cached_db' が正しく設定されているか確認します。
- SECRET_KEY が設定されており、本番環境ではセキュアな値であるか確認します。
- SESSION_COOKIE_AGE や SESSION_EXPIRE_AT_BROWSER_CLOSE などの有効期限設定が意図通りか確認します。
- SESSION_COOKIE_SECURE (True が推奨、特にHTTPS環境)、SESSION_COOKIE_HTTPONLY (True が推奨)、SESSION_COOKIE_SAMESITE (Django 3.1以降、'Lax' または 'None' と SESSION_COOKIE_SECURE = True の組み合わせが必要な場合がある) の設定を確認します。
ブラウザの確認
- 開発者ツール（Developer Tools）で、リクエストのヘッダーに sessionid クッキーが送信されているか確認します。
- ブラウザの設定で、クッキーがブロックされていないか確認します。
複数インスタンス環境での注意点
- すべてのDjangoインスタンスが同じキャッシュサーバーと同じデータベースを参照していることを確認します。ロードバランサーの背後で異なるインスタンスにルーティングされる場合でも、セッションデータが共有されるようにする必要があります。

"SessionInterrupted: The request's session was deleted before the request completed" エラー

このエラーは、セッションが進行中にキャッシュまたはデータベースから削除された場合に発生することがあります。

考えられる原因

セッション設定の不整合
- SESSION_COOKIE_AGE とキャッシュのタイムアウト、またはデータベースでのセッションクリーンアップの間隔に不整合がある場合。例えば、SESSION_REMEMBER = True (allauthなど) と SESSION_COOKIE_AGE が異なる設定の場合、クッキーが残っているのにDBからはセッションが削除されている状態になることがあります。
外部からのセッション削除
- 手動でキャッシュをクリアしたり、データベースからセッションを削除したりした場合に、そのセッションを使用中のユーザーがアクセスすると発生します。
セッションの有効期限切れと同時アクセス
- セッションが期限切れになる直前にリクエストがあり、セッションデータがキャッシュからクリアされる、またはデータベースからクリーンアップされるタイミングと重なった場合に発生することがあります。

トラブルシューティング

セッションの有効期限設定の確認
- settings.py の SESSION_COOKIE_AGE と、使用しているキャッシュバックエンドのデフォルトまたは設定されたTIMEOUT値を確認します。これらの値が極端に短い場合や、整合性が取れていない場合に発生しやすくなります。
- allauth などの認証系ライブラリを使用している場合、ACCOUNT_SESSION_REMEMBER などの設定がDjangoのセッション設定と矛盾していないか確認します。
キャッシュの動作確認
- キャッシュサーバーのログを確認し、セッションが頻繁にエビクションされていないか確認します。
- キャッシュのタイムアウト設定を、Djangoのセッションの有効期限と合わせるか、長く設定することを検討します。
データベースのクリーンアップ
- python manage.py clearsessions コマンドは期限切れのセッションをデータベースから削除しますが、これが実行される頻度とタイミングが問題を引き起こしていないか確認します。
コードレビュー
- アプリケーションコード内で、明示的に request.session.flush() や request.session.delete() が意図しないタイミングで呼ばれていないか確認します。
- 特にログイン/ログアウト処理やユーザー切り替え処理で session.flush() が使用される場合、その直後にセッションデータにアクセスするとこのエラーが発生する可能性があります。

キャッシュ書き込み失敗時のエラーログ

cached_db バックエンドは、キャッシュへの書き込みが失敗してもデータベースへの書き込みは試行し、セッションデータの保存自体は成功したとみなします。この際、エラーはログに記録されます。

考えられる原因

保存しようとしているセッションデータが大きすぎる（Memcachedなどではキーと値のサイズに制限がある）。
キャッシュサーバーのバージョン不一致や互換性の問題。
キャッシュサーバーの容量オーバー。
キャッシュサーバーへの接続問題（ネットワーク、認証情報など）。

トラブルシューティング

Djangoのログレベルの確認
- Djangoのロギング設定で、セッション関連のログが記録されるように設定されているか確認します。通常、DEBUG = True の場合は開発サーバーの出力に表示されますが、本番環境ではファイルや外部のロギングサービスに送るように設定が必要です。
キャッシュサーバーのログの確認
- キャッシュサーバー自体のログを確認し、具体的なエラーメッセージや警告がないか確認します。
セッションデータのサイズ確認
- セッションに保存しているデータが極端に大きくないか確認します。不必要に大きなデータをセッションに保存しないように設計を見直すことも重要です。

django_session テーブルが巨大化する

cached_db はデータベースにもデータを保存するため、使用しているセッション数とセッションの有効期限によってはテーブルが肥大化することがあります。

考えられる原因

活発なセッション数が多い
- サイトのユーザー数やアクティブなセッション数が非常に多いため、正しくクリーンアップされていてもテーブルが大きくなる。
clearsessions コマンドの未実行
- manage.py clearsessions コマンドが定期的に実行されていないため、期限切れのセッションがデータベースに残っている。
セッションの有効期限が長すぎる
- SESSION_COOKIE_AGE が非常に長く設定されている。

clearsessions コマンドの定期実行
- Cronジョブなどで python manage.py clearsessions を定期的に実行するよう設定します。これは期限切れのセッションをデータベースから削除するために非常に重要です。
セッションの有効期限の見直し
- サイトの要件に合わせて SESSION_COOKIE_AGE を短くすることを検討します。
データベースの最適化
- 必要に応じて、データベースのインデックスの再構築やVACUUM（PostgreSQLの場合）などのメンテナンスを行います。

sessions.backends.cached_db.SessionStore は、Django のセッションフレームワークの一部であり、その使い方は他のセッションバックエンド（データベースのみ、キャッシュのみなど）とほぼ同じです。主な違いは、設定によって内部的にキャッシュとデータベースの両方が使われるという点です。

settings.py の設定例

まず、cached_db バックエンドを使用するために、settings.py を設定します。

# myproject/settings.py

INSTALLED_APPS = [
    # ...
    'django.contrib.sessions', # セッションフレームワークを有効にする
    # ...
]

MIDDLEWARE = [
    # ...
    'django.contrib.sessions.middleware.SessionMiddleware', # セッションミドルウェア
    # ...
]

# SESSION_ENGINE を cached_db に設定
SESSION_ENGINE = 'django.contrib.sessions.backends.cached_db'

# キャッシュの設定 (例: Redisを使用する場合)
# これがcached_dbバックエンドで使われるキャッシュです
CACHES = {
    'default': {
        'BACKEND': 'django_redis.cache.RedisCache', # Redisキャッシュバックエンドの例
        'LOCATION': 'redis://127.0.0.1:6379/1', # RedisサーバーのアドレスとDB番号
        'OPTIONS': {
            'CLIENT_CLASS': 'django_redis.client.DefaultClient',
            'PASSWORD': 'your_redis_password', # 必要であればパスワード
            'COMPRESSOR': 'django_redis.compressors.zlib.ZlibCompressor', # データ圧縮
        }
    }
}

# セッションの有効期限 (秒単位、デフォルトは2週間)
SESSION_COOKIE_AGE = 60 * 60 * 24 * 7 # 1週間

# ブラウザを閉じたらセッションを終了するかどうか (Falseだと永続化される)
SESSION_EXPIRE_AT_BROWSER_CLOSE = False

# すべてのリクエストでセッションを保存するかどうか (Trueにするとパフォーマンスに影響する可能性あり)
# デフォルトはFalseで、セッションデータが変更された場合のみ保存
SESSION_SAVE_EVERY_REQUEST = False

# セッションクッキーのセキュリティ設定 (本番環境ではTrue推奨)
SESSION_COOKIE_SECURE = True # HTTPS接続でのみクッキーを送信
SESSION_COOKIE_HTTPONLY = True # JavaScriptからのクッキーアクセスを禁止
SESSION_COOKIE_SAMESITE = 'Lax' # CSRF保護 (Django 3.1以降)

設定のポイント

セキュリティ関連: SESSION_COOKIE_SECURE、SESSION_COOKIE_HTTPONLY、SESSION_COOKIE_SAMESITE は、セッションのセキュリティを高めるために重要です。本番環境ではこれらの設定を適切に行うべきです。
SESSION_SAVE_EVERY_REQUEST: デフォルトではセッションデータが変更された場合のみ保存されますが、True にすると全てのリクエストで保存されます。通常は False のままが推奨されます。
SESSION_EXPIRE_AT_BROWSER_CLOSE: ブラウザを閉じるとセッションが終了するかどうか。
SESSION_COOKIE_AGE: セッションクッキーの有効期限を設定します。
CACHES: cached_db が使用するキャッシュを定義します。上記は django-redis ライブラリを使用したRedisの例です。Memcachedなど他のキャッシュバックエンドも利用できます。
SESSION_ENGINE: ここで 'django.contrib.sessions.backends.cached_db' を指定します。
INSTALLED_APPS と MIDDLEWARE: これらはセッション機能の基本的な有効化に必須です。

ビューでのセッション利用例

Djangoのビューでは、request.session オブジェクトを通じてセッションデータにアクセスします。これは辞書のようなインターフェースを提供します。

# myapp/views.py
from django.shortcuts import render, redirect
from django.http import HttpResponse

def set_and_get_session(request):
    """
    セッションデータを設定し、取得する例
    """
    # セッションにデータを設定
    request.session['user_id'] = 123
    request.session['username'] = 'testuser'
    request.session['last_visited_page'] = request.path

    # リストや辞書なども保存可能
    if 'cart_items' not in request.session:
        request.session['cart_items'] = []
    request.session['cart_items'].append({'item_id': 1, 'name': 'Book'})

    # セッションデータの更新を明示的にマークする（リストや辞書の内部を変更した場合）
    # 例: request.session['cart_items'].append(...) のように内部を変更した場合
    # Djangoはデフォルトでセッションデータが直接割り当てられた場合にのみ変更を検知します。
    # 辞書やリストの内部を変更した場合は、明示的にmodifiedをTrueにする必要があります。
    request.session.modified = True

    # セッションデータを取得
    user_id = request.session.get('user_id')
    username = request.session.get('username', 'Guest') # デフォルト値を指定
    cart_items = request.session.get('cart_items', [])

    context = {
        'user_id': user_id,
        'username': username,
        'cart_items': cart_items,
        'session_key': request.session.session_key, # 現在のセッションキー
    }
    return render(request, 'session_example.html', context)

def check_visit_count(request):
    """
    訪問回数をセッションでカウントする例
    """
    num_visits = request.session.get('num_visits', 0)
    request.session['num_visits'] = num_visits + 1
    return HttpResponse(f"このページへの訪問回数: {request.session['num_visits']}回")

def clear_session(request):
    """
    セッションデータをクリアする例
    """
    # すべてのセッションデータを削除し、新しいセッションを作成
    request.session.flush()
    return HttpResponse("セッションデータがクリアされました。")

def delete_session_item(request):
    """
    特定のセッションアイテムを削除する例
    """
    if 'cart_items' in request.session:
        del request.session['cart_items']
    return HttpResponse("カートアイテムがセッションから削除されました。")

テンプレートでのセッション利用例

request.session はテンプレートでも利用できます。

<!DOCTYPE html>
<html lang="ja">
<head>
    <meta charset="UTF-8">
    <title>Django セッション例</title>
</head>
<body>
    <h1>セッションデータ表示</h1>
    <p>ユーザーID: {{ user_id }}</p>
    <p>ユーザー名: {{ username }}</p>
    <p>現在のセッションキー: {{ session_key }}</p>

    <h2>カートアイテム:</h2>
    {% if cart_items %}
        <ul>
            {% for item in cart_items %}
                <li>ID: {{ item.item_id }}, 名前: {{ item.name }}</li>
            {% endfor %}
        </ul>
    {% else %}
        <p>カートは空です。</p>
    {% endif %}

    <p>セッションのテストデータ (直接テンプレートからアクセス): {{ request.session.last_visited_page }}</p>

    <p><a href="{% url 'check_visit_count' %}">訪問回数をチェック</a></p>
    <p><a href="{% url 'clear_session' %}">セッションをクリア</a></p>
    <p><a href="{% url 'delete_session_item' %}">カートアイテムを削除</a></p>

</body>
</html>

urls.py の設定例

# myproject/urls.py
from django.contrib import admin
from django.urls import path
from myapp import views # あなたのアプリケーションのviewsをインポート

urlpatterns = [
    path('admin/', admin.site.urls),
    path('session-example/', views.set_and_get_session, name='set_and_get_session'),
    path('visit-count/', views.check_visit_count, name='check_visit_count'),
    path('clear-session/', views.clear_session, name='clear_session'),
    path('delete-cart-item/', views.delete_session_item, name='delete_session_item'),
]

実行前の準備

必要なパッケージのインストール: もしRedisを使っているなら、django-redis をインストールします。
```
pip install django-redis
```
他のキャッシュバックエンドを使用する場合は、それに応じたパッケージをインストールします。
データベースマイグレーションの実行: django.contrib.sessions はセッションデータを保存するためのデータベーステーブル (django_session) を必要とします。
```
python manage.py migrate
```
キャッシュサーバーの起動: 設定したキャッシュサーバー（例: Redis）が稼働していることを確認してください。

sessions.backends.cached_db.SessionStore は、パフォーマンスと永続性を両立させた強力な選択肢ですが、プロジェクトの要件によっては他のセッションバックエンドや、セッションとは異なる状態管理のアプローチが適している場合があります。

他の組み込みセッションバックエンド

Djangoには、cached_db 以外にもいくつかの組み込みセッションバックエンドが提供されています。それぞれに特徴があり、ユースケースが異なります。

django.contrib.sessions.backends.signed_cookies.SessionStore (署名付きクッキー)
- 説明: セッションデータをサーバーではなく、ユーザーのブラウザのクッキーに直接保存します。データは改ざんされないようにDjangoのSECRET_KEYで署名されますが、暗号化はされません（ブラウザから内容が読めてしまう）。
- 利点:
  - データベースやキャッシュサーバーが不要。
  - サーバー側のリソース消費が非常に少ない（ステートレスに近い）。
  - 複数サーバー環境でのセッション共有が容易。
- 欠点:
  - 機密性の高いデータをセッションに保存すべきではない（署名されているが、暗号化されていないため）。
  - クッキーのサイズ制限があるため、保存できるデータ量に制約がある。
  - リクエストごとにセッションデータが送信されるため、データ量が多いとHTTPリクエストのサイズが大きくなる。
- ユースケース: 機密性の低いデータ（例: ユーザーの設定、表示オプションなど）を保存し、サーバーのリソース消費を最小限に抑えたい場合。
django.contrib.sessions.backends.file.SessionStore (ファイルシステム)
- 説明: セッションデータをサーバーのローカルファイルシステムに保存します。
- 利点:
  - データベースやキャッシュサーバーが不要。
  - セットアップが比較的簡単。
- 欠点:
  - Webサーバーが複数台ある場合、セッションを共有することが非常に困難（各サーバーが独自のファイルシステムを持つため）。
  - ファイルI/Oがボトルネックになる可能性があり、パフォーマンスはデータベースやキャッシュに劣る。
  - ファイルシステムのクリーンアップが必要。
- ユースケース: 開発環境、単一のサーバーで動作する非常に小規模なアプリケーション。本番環境での利用は推奨されません。
django.contrib.sessions.backends.cache.SessionStore (キャッシュのみ)
- 説明: セッションデータをキャッシュのみに保存します。データベースには一切保存されません。
- 利点:
  - セッションデータへのアクセスが非常に高速（インメモリキャッシュなどを使用する場合）。
- 欠点:
  - キャッシュがクリアされたり、キャッシュサーバーが再起動したりすると、セッションデータが失われる可能性がある。
  - キャッシュサーバーのメモリが不足すると、古いセッションデータがエビクションされ、セッションが予期せず失われることがある。
- ユースケース: パフォーマンスが最優先されるが、セッションデータの永続性がそこまで重要ではない場合（例: 短期間の非認証セッション）。
- 説明: セッションデータをデータベースのみに保存します。最もシンプルで信頼性の高い選択肢の一つであり、特別なキャッシュサーバーを必要としません。
- 利点:
  - セットアップが簡単。
  - 高い永続性（データベースに依存）。
  - 特別な外部サービスが不要。
- 欠点:
  - セッションデータへのアクセスごとにデータベースクエリが発生するため、アクセスが集中するとパフォーマンスのボトルネックになる可能性がある。
  - Webサーバーが複数台ある場合でもセッションを共有しやすい（同じDBを見ればよい）。
- ユースケース: 小規模なアプリケーション、パフォーマンスよりもシンプルさと永続性を重視する場合。

セッションに代わる状態管理のアプローチ

セッションはユーザーの状態を管理する一般的な方法ですが、RESTful APIの構築やマイクロサービスアーキテクチャでは、セッションとは異なるアプローチがよく用いられます。

カスタムのデータストア（データベース、Redisなど）
- 説明: セッションを使わずに、特定のユーザーの状態や情報を直接データベース（Userモデルにフィールドを追加するなど）やRedisなどのキーバリューストアに保存し、ユーザーIDなどをキーとしてアクセスする。
- 利点:
  - 完全にアプリケーションの要件に合わせて設計できる。
  - 柔軟性が高い。
- 欠点:
  - セッションが提供する便利な機能（有効期限管理、クッキーとの連携など）を自前で実装する必要がある。
  - セキュリティ対策も自前で講じる必要がある。
- ユースケース: セッションの概念に縛られず、よりきめ細やかな状態管理が必要な場合。
OAuth2 を利用した認証・認可
- 説明: 大規模なシステムや、サードパーティアプリケーションに自社サービスのデータへのアクセスを許可する場合（例: 「Googleでログイン」機能など）に利用されます。ユーザーが直接サーバーに認証情報を送信するのではなく、認可サーバーを通じてアクセス権限を付与します。
- 利点:
  - セキュアなアクセス委譲メカニズム。
  - 異なるサービス間での連携が容易。
- 欠点:
  - 実装が複雑になる。
- Djangoでの実装: django-oauth-toolkit などのライブラリが利用されます。
JWT (JSON Web Tokens) を利用した認証
- 説明: ユーザーが認証に成功すると、サーバーはユーザーの識別情報や権限情報を含むJWTを生成し、クライアントに返します。クライアントはこのJWTを（通常はHTTPヘッダーのAuthorizationに）含めて以降のリクエストを送信します。サーバーはJWTの署名を検証するだけで、ユーザーの認証状態を確認できます。サーバーはセッション状態を保持する必要がないため、ステートレスなAPIに最適です。
- 利点:
  - ステートレスであるため、サーバーのスケールアウトが非常に容易。
  - クロスドメインでの利用が容易（CORS対応がしやすい）。
  - モバイルアプリケーションとの連携が容易。
  - バックエンドの負荷軽減。
- 欠点:
  - トークンの失効管理が複雑になる場合がある（ブラックリストなど）。
  - JWTに含めるデータ量に注意が必要（大きすぎるとリクエストサイズが増える）。
  - セキュリティ対策（盗難、改ざん防止など）が重要。
- Djangoでの実装: djangorestframework-simplejwt や django-rest-framework-jwt といったサードパーティライブラリを使用するのが一般的です。

選択肢の考慮事項

ユースケース: Webアプリケーションか、APIか、モバイルアプリとの連携があるか？
複雑さ: セットアップやメンテナンスの手間はどの程度か？
セキュリティ: どのような機密データを保存するか？改ざんや盗聴のリスクは？
スケーラビリティ: 複数サーバーでの利用、ユーザー数の増加に対応できるか？
データの永続性: サーバーが再起動してもセッションデータを保持する必要があるか？
パフォーマンス要件: 高速なアクセスが必要か？

Djangoセッションを最適化！cached_db以外の選択肢と使い分け

どのような仕組みか？

なぜ cached_db を使うのか？

設定方法

注意点

セッションデータが永続化されない / 頻繁に失われる

"SessionInterrupted: The request's session was deleted before the request completed" エラー

キャッシュ書き込み失敗時のエラーログ

django_session テーブルが巨大化する

settings.py の設定例

ビューでのセッション利用例

テンプレートでのセッション利用例

urls.py の設定例

実行前の準備

他の組み込みセッションバックエンド

セッションに代わる状態管理のアプローチ

選択肢の考慮事項

なぜ `cached_db` を使うのか？