콘텐츠로 이동

캐시 패턴 (Caching)

개요

Redis가 가장 흔하게 쓰이는 이유 중 하나가 캐시예요. 더 느린 서버나 데이터베이스에 대한 읽기 접근을 빠르게 하기 위해 앞에 캐시를 두는 거죠. 캐시 항목은 어차피 다른 곳(원본 DB)에 영속 저장되어 있는 데이터의 복사본이에요. 그래서 캐시 메모리가 차면 그 항목을 버려도(evict) 안전해요 — 필요하면 나중에 다시 채우면 되니까요.

Redis는 TTL(만료 시간)과 메모리 한도·퇴출 정책(eviction policy)을 함께 제공해서, 이 "원본이 있는 복사본"을 안전하게 관리하게 해줘요.

핵심 개념

캐시 비우기(cache-aside) 패턴

가장 대표적인 캐시 패턴은 cache-aside(지연 로딩)예요.

  1. 요청이 오면 먼저 Redis에서 캐시 확인 — 있다면(hit) 그대로 돌려주고 끝나요.
  2. 없다면(miss) 원본 데이터베이스에서 데이터를 읽어요.
  3. 읽은 값을 Redis에 저장한 뒤 클라이언트에 돌려줘요.

이 방식은 읽을 때만 캐시를 채우고, TTL로 일정 시간이 지나면 만료시켜 지연된(stale) 데이터가 영원히 남지 않게 해요. Redis는 메모리에서 읽으니 서브밀리초 응답이 가능해요.

TTL (Time To Live)

캐시 키에 만료 시간을 걸어두면, 일정 시간이 지나면 Redis가 자동으로 삭제해요. "일정 시간만 유효한" 데이터에 꼭 맞는 장치예요. TTL 덕에 캐시 항목이 오래돼 원본과 어긋나는 문제를 통제할 수 있어요. TTL 명령으로 남은 만료 시간을 확인할 수도 있어요.

메모리 한도와 퇴출 정책

메모리가 무한할 수 없으니, Redis는 maxmemory로 메모리 한도를 정하고, 한도를 넘으면 퇴출 정책(eviction policy)으로 키를 자동으로 내보내요. 대표 정책은 다음과 같아요.

  • noeviction — 키를 내보내지 않고, 새 데이터를 넣는 명령에 오류를 반환해요.
  • allkeys-lru — 가장 오래 전에 사용된(least recently used) 키부터 내보내요.
  • allkeys-lfu — 가장 적게 사용된(least frequently used) 키부터 내보내요.
  • volatile-lru / volatile-ttl — 만료(TTL)가 있는 키 중에서만 LRU 또는 가장 짧게 남은 TTL 순으로 내보내요.
  • allkeys-random — 임의의 키를 내보내요.

LRU는 근사 알고리즘으로 구현됩니다. 캐시가 차면 내보낼 키를 고를 때를 대비해, 퇴출 성능을 조절하는 maxmemory-samples 설정도 있어요. INFO stats의 evicted_keys·expired_keys를 보면 퇴출·만료가 얼마나 일어나는지 진단할 수 있어요.

캐시 스탬피드

여러 요청이 동시에 캐시 미스로 원본을 치면 원본이 부담을 받는 걸 스탬피드(stampede)라고 해요. Redis는 원자적 연산(Lua 스크립트 등)으로 이를 완화할 수 있어요. 다만 이는 고급 주제라, 필요할 때 다뤄요.

실제 적용 (데이터스케쳐스)

Redis 캐시는 주 저장소(PostgreSQL)의 부하를 줄이는 데 중심 역할을 해요.

  • 자주 조회되는 응답 캐시 — 자주 읽히는 콘텐츠·조회 결과를 Redis에 담아 PostgreSQL의 읽기 부하를 줄여요.
  • TTL로 지연 통제 — 캐시 항목에 TTL을 걸어 원본과 어긋나는 시간을 제한해요.
  • semantic cache — LLM 호출처럼 비싼 작업의 결과를 재사용해 비용을 아껴요. (의미 단위 캐시)
  • 퇴출 정책 선택 — 캐시 전용 인스턴스라면 allkeys-lru/allkeys-lfu처럼 전체 키를 대상으로 퇴출해요. 세션처럼 영구 보관이 필요한 키와 섞여 있다면 volatile-* 정책을 고려해요.

핵심은 캐시는 "원본의 복사본"이라는 점이에요. 영구 보관이 필요한 정합성 데이터는 PostgreSQL이, 빠르게 읽고 쓰는 복사본은 Redis가 맡는 역할 분담이 우리 접근이에요.

더 알아보기