웹사이트가 2초 느리면 방문자의 절반이 떠납니다. 구글이 측정한 수치입니다. 그리고 느린 원인의 보통 병목은 데이터베이스입니다. 매번 DB에 SELECT 쿼리를 날리기 때문입니다. Redis 캐시를 넣으면 같은 데이터를 수십 배 빠르게 가져올 수 있습니다. 이 글에서는 cache-aside 패턴으로 Redis를 도입하는 전체 과정을 Before/After 비교와 함께 정리합니다.
왜 데이터베이스가 병목인가
데이터베이스는 디스크를 읽습니다. 디스크 읽기는 메모리 읽기보다 수천 배 느립니다. SSD라도 메모리 대비 느린 건 마찬가지입니다. 그래서 사용자 정보를 매번 DB에서 SELECT 해오면, 한 페이지에 쿼리가 수십 개씩 나가고 응답이 300밀리초쯤 걸립니다. 100명이 동시에 들어오면 DB가 버티질 못합니다.
특히 자주 바뀌지 않는 데이터 — 사용자 프로필, 상품 정보, 게시글 본문 — 를 매번 DB에서 가져오는 건 낭비입니다. 어차피 같은 값인데 왜 매번 디스크를 읽어야 할까요. 이걸 메모리에 올려두는 게 캐시입니다.
Redis가 메모리 캐시로 좋은 이유
Redis는 인메모리(in-memory) 데이터 저장소입니다. 데이터를 디스크가 아니라 RAM에 올려둡니다. 응답이 1밀리초 이내로 나옵니다. DB 쿼리 300밀리초와 비교하면 30배 차이입니다. 단순 비교로 홈페이지 로딩이 3초에서 0.1초로 줄어드는 셈입니다.
게다가 Redis는 키-값 저장소라 단순합니다. SQL 쿼리를 배울 필요 없이 get/set 명령 두 개면 캐시가 됩니다. TTL(Time To Live)을 지원해서 데이터가 자동으로 만료되게 할 수도 있고, 다양한 자료구조(리스트, 셋, 해시)를 지원해서 단순 키-값 이상의 패턴도 가능합니다.
cache-aside 패턴: 가장 흔한 도입 방식
Redis를 도입하는 가장 흔한 패턴이 cache-aside(Lazy Loading)입니다. 흐름은 이렇습니다. 앱이 데이터가 필요하면 Redis에서 먼저 찾습니다. 있으면 그걸 반환합니다(cache hit). 없으면 DB에서 가져오고, 가져온 값을 Redis에 넣은 뒤 반환합니다(cache miss). 다음 요청부터는 Redis에서 바로 가져옵니다.
# Before: 매번 DB 조회 (300ms)
user = db.query("SELECT * FROM users WHERE id=1")
# After: Redis 캐시 (10ms)
import redis
r = redis.Redis()
user = r.get("user:1")
if user is None:
# cache miss - DB에서 가져오고 Redis에 저장
user = db.query("SELECT * FROM users WHERE id=1")
r.setex("user:1", 300, user) # 5분 TTLRedis는 자주 묻는 질문은 내가 대답할게, 모르는 건 매니저한테 물어봐 달라며 안내 데스크 같은 역할을 합니다. 자주 찾는 데이터는 Redis가 즉시 대답하고, 처음 보는 데이터만 DB까지 가서 가져옵니다.
TTL: 데이터 신선도 유지
캐시의 가장 큰 위험은 오래된 값입니다. DB에서는 데이터가 바뀌었는데 Redis에는 옛날 값이 남아 있으면 사용자에게 잘못된 정보를 보여주게 됩니다. 이걸 막으려면 TTL을 설정합니다. setex 명령으로 초 단위 만료 시간을 줍니다.
# 5분 뒤 자동 삭제
r.setex("user:1", 300, user_data)
# 1시간 뒤 자동 삭제
r.setex("product:42", 3600, product_data)
# 이미 들어있는 키에 TTL 추가
r.expire("session:abc", 1800)TTL을 5분으로 주면 5분 뒤 캐시가 삭제되고, 다음 요청 때 DB에서 최신 데이터를 다시 가져와서 캐시에 넣습니다. 자주 바뀌는 데이터는 TTL을 짧게(30초~1분), 잘 안 바뀌는 데이터는 길게(1시간~1일) 잡는 게 원칙입니다.
데이터가 변경될 때 캐시를 즉시 무효화하는 방법도 있습니다. 사용자가 프로필을 수정하면 user:1 캐시를 바로 지우는 식입니다. 그러면 다음 조회 때 DB에서 최신 값을 다시 가져옵니다. 쓰기 시점에 캐시를 지우는 패턴을 write-through 혹은 cache invalidation이라고 합니다.
주의점: 메모리 관리
캐시는 메모리 위에서 돌아갑니다. 서버 메모리가 2GB인데 캐시에 3GB를 넣으면 서버가 뻗습니다. 그래서 중요하게 쓰는 자주 쓰는 데이터만 캐싱해야 합니다. Redis는 maxmemory 설정으로 메모리 한도를 정할 수 있고, 한도에 도달하면 정해진 정책(eviction policy)으로 오래된 데이터부터 자동 삭제합니다.
# /etc/redis/redis.conf
maxmemory 512mb
maxmemory-policy allkeys-lru # 가장 오래 안 쓴 데이터부터 삭제allkeys-lru는 가장 오래 안 쓴(Least Recently Used) 키부터 지우라는 뜻입니다. 캐시로 쓸 때 가장 추천하는 정책입니다. 잘 모르겠으면 일단 allkeys-lru로 설정하면 됩니다. 세션 저장소로 쓸 때는 volatility-ttl(TTL 짧은 것부터 삭제)이 더 적합합니다.
Before/After 비교
| 지표 | Before (DB only) | After (Redis) |
|---|---|---|
| 단일 조회 응답 | 300ms | 10ms |
| 캐시 히트율 | – | 80~95% |
| DB 부하 | 모든 쿼리 | miss 쿼리만 |
| 동시 접속 처리 | DB 커넥션 한계 | 메모리 한계 |
| 데이터 최신성 | 항상 최신 | TTL 내 옛날 값 가능 |
주의할 점이 있습니다. 캐시 히트율이 50% 아래라면 Redis를 도입하는 게 역효과일 수 있습니다. 캐시에 넣는 비용이 더 듭니다. 반대로 95% 이상이면 효과가 극대화됩니다. 처음 도입할 때는 모니터링을 꼭 붙여서 히트율을 확인하세요. Redis의 info stats 명령에 keyspace_hits / keyspace_misses로 확인할 수 있습니다.
언제 캐시가 도움이 안 되는가
모든 데이터가 캐시에 맞는 건 아닙니다. 다음 경우는 Redis 캐시가 별 도움이 안 됩니다.
첫째, 데이터가 너무 자주 바뀔 때. 쓰기가 읽기보다 많으면 캐시 무효화 비용이 더 듭니다. 둘째, 모든 조회가 서로 다른 키일 때. 캐시 히트가 안 나면 의미가 없습니다. 셋째, 데이터 크기가 너무 클 때. 수백 MB짜리 값을 캐싱하면 메모리가 금방 찹니다. 이런 경우에는 애초에 DB 쿼리를 최적화하거나 인덱스를 잡는 게 먼저입니다.
Redis 영속성: 캐시인데 디스크에도 남기기
Redis는 인메모리 저장소지만, 서버가 재시작되면 데이터가 전부 사라집니다. 캐시로만 쓴다면 큰 문제가 아닙니다. DB에서 다시 가져오면 되니까요. 하지만 세션 저장소나 계산 결과 캐시로 쓸 때는 재시작마다 처음부터 시작하는 게 부담스럽습니다. Redis는 이를 위해 두 가지 영속성 옵션을 제공합니다.
# RDB 스냅샷 (주기적으로 디스크에 저장)
save 900 1 # 15분에 1번 이상 변경 시 저장
save 300 10 # 5분에 10번 이상 변경 시 저장
save 60 10000 # 1분에 10000번 이상 변경 시 저장
# AOF (Append Only File) - 모든 쓰기 명령을 로그로 저장
appendonly yes
appendfsync everysec # 매 초마다 동기화 (성능과 안정성 균형)RDB는 특정 시점 스냅샷이라 복구는 빠르지만 마지막 저장 이후 데이터는 날아갑니다. AOF는 모든 쓰기를 기록해서 데이터 유실은 거의 없지만 파일이 커지고 복구가 느립니다. 캐시 용도라면 RDB만 켜두면 충분하고, 세션처럼 유실이 치명적인 데이터는 AOF를 같이 쓰는 게 안전합니다.
캐시 스탬피드 방지
트래픽이 몰리는 순간 가장 위험한 패턴이 캐시 스탬피드입니다. 인기 상품 페이지의 캐시가 만료되는 순간, 동시에 들어온 수백 개 요청이 전부 cache miss가 나서 DB로 몰려갑니다. DB가 순식간에 과부하에 걸립니다.
가장 단순한 방어법은 TTL에 약간의 랜덤값을 더하는 것입니다. setex로 300초를 주되 270~330초 사이로 랜덤하게 분산시키면, 캐시 만료 시점이 퍼져서 DB로 한꺼번에 몰리지 않습니다. 더 견고하게 하려면 cache miss 시 첫 번째 요청만 DB에 접근하고 나머지는 대기하게 만드는 분산 락(Mutex) 패턴을 씁니다.
Redis 운영과 Nginx 리버스 프록시를 조합하면 웹사이트 전체 응답 속도를 극적으로 개선할 수 있습니다. Nginx 리버스 프록시 가이드와 Redis 공식 문서를 함께 참고하세요.
Redis를 도입한 후에는 반드시 캐시 히트율을 모니터링해야 합니다. redis-cli info stats 명령에서 keyspace_hits와 keyspace_misses 값을 확인하면 히트율을 계산할 수 있습니다. 90% 이상이면 캐시가 제 역할을 하고 있는 것이고, 70% 이하라면 TTL이 너무 짧거나 캐싱 대상이 잘못된 것입니다. 모니터링 없이 캐시를 도입하는 건 블라인드 튜닝과 같습니다.
VPS 웹사이트 속도가 고민이면 Redis 캐시부터 도입해 보세요. 설치 한 번, get/set 두 명령이면 끝입니다. 백엔드 성능 최적화 팁을 매주 받아보시려면 구독해 주세요.
