Redis와 캐시 전략

메모리 기반 저장소와 Cache-Aside·Write-Through·Write-Back 패턴

Redis는 모든 데이터를 메모리에 올려두는 Key-Value 저장소로, 빠른 속도 대신 영속성 보장이 약하다. 캐시 전략은 Cache-Aside·Write-Through·Write-Back 세 가지가 있고, 각각 읽기/쓰기 비율과 일관성 요구 수준에 따라 선택한다.

Caching

개념

Redis는 모든 데이터를 RAM에 올려두는 Key-Value 저장소다. 디스크 I/O가 없으니 읽기/쓰기가 마이크로초 단위로 빠르다. 대신 프로세스가 죽으면 데이터가 사라질 수 있다는 트레이드오프가 있다 (영속성 옵션으로 완화 가능).

"빠른 DB"라고 부르기엔 역할이 다르다. DB는 영구 저장이 목적이고, Redis는 속도가 필요한 임시 저장·조율·브로드캐스트에 쓴다.

자료구조

Redis가 단순 캐시 이상인 이유다. 자료구조마다 최적화된 명령어가 있다.

타입 대표 명령 용도
String GET / SET / INCR 기본 캐시, 카운터, 분산 락
Hash HGET / HSET 객체 저장 (필드 단위 접근)
List LPUSH / RPOP 큐, 작업 목록
Set SADD / SISMEMBER 중복 없는 집합, 태그
Sorted Set ZADD / ZRANGE 순위표, 우선순위 큐
Stream XADD / XREAD 이벤트 로그, 메시지 큐
Pub/Sub PUBLISH / SUBSCRIBE 실시간 브로드캐스트

캐시 전략

Cache-Aside (가장 흔함)

읽기:

Redis에 키 있으면 → 반환
없으면 → DB 조회 → Redis에 저장 → 반환

쓰기:

DB에 쓰고 → Redis 캐시 삭제 (다음 읽기 때 재적재)
  • DB 부하를 줄이는 효과가 크다
  • 캐시에 없을 때만 DB를 치므로, 자주 안 읽히는 데이터는 캐시에 쌓이지 않음
  • 단점: 캐시 미스 시 첫 읽기는 항상 느림 (cold start)

Write-Through

쓰기:

DB와 Redis에 동시에 씀

읽기:

Redis에서만 읽음 (항상 최신)
  • 캐시가 항상 최신 상태 → 읽기 일관성이 높음
  • 단점: 쓰기마다 두 곳을 치므로 쓰기 지연 발생. 안 읽히는 데이터도 캐시에 쌓임

Write-Back (Write-Behind)

쓰기:

Redis에만 먼저 씀 → 비동기로 DB에 반영
  • 쓰기가 가장 빠름
  • 단점: Redis가 죽으면 DB에 반영되지 않은 데이터 유실. 구현 복잡도 높음

비교

Cache-Aside Write-Through Write-Back
읽기 성능 미스 시 느림 빠름 빠름
쓰기 성능 빠름 느림 가장 빠름
일관성 낮음 (삭제 후 재적재) 높음 낮음 (비동기)
데이터 유실 위험 없음 없음 있음

TTL과 만료 전략

캐시는 항상 만료(TTL)를 설정한다. 설정 안 하면 오래된 데이터가 계속 남거나 메모리가 찬다.

SET key value EX 300   # 300초 후 만료

TTL을 고정값으로 쓰면 같은 시간에 대량 만료 → DB에 동시 요청 집중. 약간의 랜덤 편차를 줘서 분산시킨다.

ttl = 300 + random.randint(-30, 30)

주의할 문제

Thundering Herd / Cache Stampede

인기 있는 키가 만료되는 순간 수백 개의 요청이 동시에 DB로 몰리는 현상. 완화 방법:

  • TTL에 랜덤 편차 추가
  • 캐시 미스 시 분산 락을 잡아 한 요청만 DB 조회하고 나머지는 대기

메모리 한계

Redis는 메모리에 다 올리므로 용량 제한이 있다. 초과 시 eviction 정책에 따라 데이터를 버린다 (LRU, LFU 등). 캐시 용도면 allkeys-lru가 일반적.

Pub/Sub

Redis의 Pub/Sub은 메시지를 채널에 발행하면 구독자 전원에게 즉시 전달하는 브로드캐스트 모델이다.

Publisher → PUBLISH channel message → Redis → 구독자 A, B, C 동시 전달
  • 영속성 없음: 구독자가 연결 안 된 순간의 메시지는 유실
  • 영속성이 필요하면 Stream을 쓴다
  • 실시간 알림, SSE 브로드캐스트 용도에 적합

영속성 옵션

메모리 저장소지만 두 가지 방식으로 디스크에 백업할 수 있다.

RDB (Snapshot) AOF (Append Only File)
방식 주기적으로 전체 스냅샷 모든 쓰기 명령을 로그로 기록
복구 속도 빠름 느림
데이터 유실 스냅샷 주기만큼 거의 없음
파일 크기 작음

캐시 전용으로만 쓰면 영속성 옵션 꺼도 된다.

언제 쓰나

  • DB 쿼리 결과를 잠깐 저장해 반복 조회를 막을 때 (Cache-Aside)
  • 로그인 세션 저장 (TTL로 자동 만료)
  • 실시간 브로드캐스트 (Pub/Sub)
  • 분산 환경에서 중복 실행 방지 (분산 락, SETNX)
  • Rate limiting (INCR + TTL로 N분에 N회 제한)

영구 저장이 목적이면 Redis가 아니라 DB를 써야 한다.

더 보기

sunshinemoon · 2026