Django 캐시 프레임워크

페이지나 데이터베이스 쿼리 결과를 매번 처음부터 다시 계산하다 보면 서버가 느려져요. Django는 이런 반복 작업을 줄여 주는 캐시 프레임워크를 제공해요. 캐시는 한 번 계산한 결과를 저장해 두고, 같은 요청이 오면 빠르게 재사용하는 방식이에요.

출처: Django's cache framework | Django documentation

캐시 설정하기

캐시는 CACHES 설정으로 구성해요. 실제 사용에서는 Redis를 백엔드로 쓰는 경우가 많아요. Redis 서버는 종종 인증으로 보호되는데, LOCATION에 URL과 함께 사용자 이름·비밀번호를 넣어 주면 돼요.

CACHES = {
    "default": {
        "BACKEND": "django.core.cache.backends.redis.RedisCache",
        "LOCATION": "redis://username:[email protected]:6379",
    }
}

LOCATION은 캐시 서버의 위치를 지정해요. Redis, Memcached, 그리고 로컬 메모리 캐시 등 여러 백엔드 중에 고를 수 있어요.

캐시 사용하기

캐시 API는 django.core.cache의 cache 객체로 접근해요. cache.set(key, value, timeout)으로 저장하고, cache.get(key)으로 꺼내요. 데이터가 없으면 None을 돌려주거나 지정한 기본값을 돌려줄 수 있어요.

from django.core.cache import cache

cache.set('my_key', 'hello', 300)
value = cache.get('my_key')

뷰에서 반복되는 계산을 캐시하려면, 계산이 완료된 후 그 결과를 캐시에 저장하고 다음에 꺼내 쓰는 패턴을 쓰면 돼요.

다운스트림 캐시 신중하게

다운스트림 캐싱은 좋은 성능 향상이지만 위험이 있어요. 많은 웹 페이지의 내용은 인증 상태와 그 밖의 여러 변수에 따라 달라져요. URL만을 기준으로 페이지를 무작정 저장하는 캐시 시스템은 다른 방문자에게 잘못되거나 민감한 데이터를 노출할 수 있어요. 그래서 다운스트림 캐시는 신중하게 적용해야 해요.

Vary 헤더 사용하기

CacheMiddleware는 Authorization에 대해 자동으로 vary합니다. RFC 9111 Section 3.5가 캐시가 인증된 응답의 재사용을 피하도록 허용하지만, Django의 CacheMiddleware는 캐시 키 구성을 단순화하기 위해 Vary 헤더에 Authorization을 추가해요. (Django 6.0.6부터 UpdateCacheMiddleware가 해당 헤더를 가진 요청에 대해 Authorization에 vary하도록 바뀌었어요.)

미들웨어 순서

페이지 전체를 캐시하는 CacheMiddleware를 쓴다면 MIDDLEWARE 설정에서의 순서가 중요해요. UpdateCacheMiddleware는 목록에서 가장 위쪽에, FetchFromCacheMiddleware는 가장 아래쪽에 두는 것이 관례예요. 미들웨어는 위에서 아래로 요청을 처리하고 아래에서 위로 응답을 처리하기 때문에, 이 순서가 캐시 읽기·쓰기의 올바른 위치를 보장해요.

정리하면, Django 캐시는 CACHES로 백엔드를 정하고 cache.set/cache.get으로 값을 주고받는 간단한 API예요. 인증에 따라 달라지는 페이지를 다운스트림 캐시할 때는 Vary 헤더를 반드시 신경 써야 해요.

Django 캐시 프레임워크