캐시(Cache)란?
캐시(Cache)란, 원본 저장소보다 빠르게 가져올 수 있는 임시 데이터 저장소를 의미합니다.
참고로 캐시(Cache)라는 단어는 Redis에서만 쓰이는 용어는 아니고 전반적인 개발 분야에서 통용돼서 쓰입니다.
캐싱(Caching)이란?
캐싱(Caching)이란 캐시(Cache, 임시 데이터 저장소)에 접근해서 데이터를 빠르게 가져오는 방식을 의미합니다.
현업에서는 아래와 같이 얘기하는 편입니다.
“이 API는 응답 속도가 너무 느린데? 이 응답 데이터는 캐싱(Cahing) 해두고 쓰는 게 어때?’
이 말을 풀어서 설명하자면 ‘API 응답 결과를 원본 저장소보다 빠르게 가져올 수 있는 임시 데이터 저장소에 저장해두고, 빠르게 조회할 수 있게 만드는 게 어때?’라는 의미입니다.
데이터를 캐싱할 때 사용하는 전략
Redis를 단순한 키-값 저장소로만 쓰기보다는, 캐시(Cache)로 활용하는 경우가 많습니다.
이때 캐시를 어떤 방식으로 사용할지에 따라 전략이 나뉘며, 크게 읽기 전략과 쓰기 전략으로 구분할 수 있습니다.
📖읽기 전략: Cache Aside 전략 (= Look Aside, Lazy Loading)
데이터를 조회할 때 주로 사용하는 전략은 Cache Aside 전략입니다.
이 전략은 Look Aside 전략 또는 Lazy Loading 전략이라고도 불립니다.
▶ Cache Aside 전략의 작동 방식
게시판 서비스를 처음 배포한 상황을 예로 들어보겠습니다.
- 처음 배포된 서비스에는 DB와 Redis 모두 데이터가 없는 상태입니다.
- 사용자가 게시글을 작성하면, 해당 데이터는 DB에만 저장됩니다. (Redis에는 저장되지 않음)
- 이후 사용자가 게시글을 조회하려고 할 때, 먼저 Redis에 데이터가 있는지 확인합니다.
- Redis에 데이터가 없다면(Cache Miss), DB에서 데이터를 조회하여 사용자에게 응답합니다.
- 응답한 데이터는 Redis에도 저장합니다.
- 이후 다른 사용자가 동일한 데이터를 조회하면, Redis에 이미 저장된 데이터가 있기 때문에 바로 Redis에서 조회합니다. (Cache Hit)
▶ 요약
Cache Aside 전략은
"캐시에 먼저 접근하고, 없으면 DB에서 조회한 뒤 캐시에 저장하는 방식"입니다.
▶ 용어 정리
- Cache Hit:
요청한 데이터가 캐시에 존재하여 캐시에서 바로 응답할 수 있는 상태입니다.
- Cache Miss:
캐시에 데이터가 없어 DB에서 조회해야 하는 상태입니다.
Cache Aside 전략은 가장 일반적으로 쓰이며, 조회량이 많은 서비스에서 캐시를 효율적으로 활용할 수 있게 해줍니다.
캐시에는 찾는 데이터가 없을 때만 데이터가 캐싱되기 때문에 이를 지연로딩(Lazy Loading)이라고도 부릅니다. 이 구조는 레디스 장애 발생 시 시스템이 다운되지 않고, DB에서 데이터를 가지고 올 수 있습니다.
추가) Cache Warming 전략
캐시 서버를 재시작했거나, TTL 만료로 캐시가 비워졌다면 기존에 붙어있던 커넥션들이 모두 데이터베이스(DB)로 접근하게 됩니다. 이처럼 캐시에 데이터가 없고, 많은 사용자가 한꺼번에 데이터를 요청하는 상황에서는 Cache Miss가 계속 발생하고, 그로 인해 DB에 과도한 트래픽이 몰려 성능 저하가 발생할 수 있습니다.
이 문제를 해결하기 위해 사용하는 전략이 Cache Warming(캐시 웜업)입니다. 이는 말 그대로 DB에서 자주 사용될 데이터를 미리 캐시에 적재해두는 작업입니다. 사용자가 요청하기 전에 캐시를 준비시켜둠으로써, 초기 트래픽에서도 Cache Miss 없이 빠르게 응답할 수 있고, DB에 부하가 가지 않도록 방어할 수 있습니다.
예를 들어, 티켓링크에서는 공연이나 티켓 오픈 전, 상품 정보를 미리 Redis에 올려놓는 작업을 자동화해두었다고 합니다.
우리 서비스도 클라이언트가 생성한 데이터를 캐시에 저장하고, 트래픽이 많아질 경우 서버를 여러 대로 늘리는(Scale-out) 구조를 가지고 있다면, Cache Warming 전략을 함께 고려하는 것이 좋습니다.
이렇게 하면 서버가 처음부터 빠르게 응답할 수 있고, 갑작스러운 트래픽 증가에도 안정적으로 대응할 수 있습니다.
쓰기 전략: Write Around & Write Through
읽기 전략만큼 중요한 것이 쓰기 전략입니다.
쓰기 전략은 데이터를 저장, 수정, 삭제할 때 Redis 캐시에 어떻게 반영할 것인지를 결정합니다.
대표적인 전략은 두 가지입니다.
✏️ Write Around 전략
Write Around 전략은 데이터 저장 시 Redis 캐시에 반영하지 않고, DB에만 저장하는 방식입니다.
쉽게얘기하면 오직 db에만 데이터를 저장한다! 로 이해하시면 됩니다.
예: 사용자가 게시글을 작성하면 DB에만 저장하고, Redis에는 저장하지 않습니다.
이후 사용자가 해당 게시글을 조회할 경우, Redis에 데이터가 없으므로 Cache Miss가 발생합니다.
이때 DB에서 조회한 데이터를 Redis에 저장합니다.
▶ 장단점
- ✅ 장점: 불필요한 데이터를 캐시에 저장하지 않아 캐시 공간을 효율적으로 사용할 수 있습니다.
- ⚠️ 단점: 캐시에 데이터가 있는 상태에서 DB만 수정하면 캐시와 DB의 데이터 불일치 문제가 발생할 수 있습니다.
예: 캐시에 게시글이 있는데, 해당 게시글을 수정할 때 캐시는 갱신되지 않음 → 다음 조회에서 수정 전 내용이 보일 수 있음
✏️✏️ Write Through 전략
Write Through 전략은 DB에 데이터를 저장할 때, Redis에도 동시에 저장하는 방식입니다.
예: 사용자가 게시글을 작성하면, DB와 Redis 양쪽에 동시에 저장합니다.
▶ 장단점
- ✅ 장점: 캐시가 항상 최신 데이터를 보장합니다. (데이터 불일치 문제 없음)
- ⚠️ 단점:
- 쓰기 속도가 느려질 수 있습니다. (DB 저장 + Redis 저장 = 2번 작업)
DB에 저장한 후, 다시 Redis에도 저장해야 하므로 저장 작업이 2단계로 이루어집니다.
특히 대량의 데이터를 연속으로 저장하는 상황에서는 이로 인해 전체 시스템의 쓰기 처리 속도가 떨어질 수 있습니다.
사용하지 않는 데이터까지 무조건 캐시에 저장되므로, 리소스 낭비가 발생할 수 있습니다. - 사용하지 않는 데이터까지 무조건 캐시에 저장됩니다.
Write-through 전략은 해당 데이터가 실제로 조회될지 여부와 상관없이 모든 데이터를 캐시에 저장합니다.
이로 인해 조회되지 않는 데이터(예: 오래된 글, 임시 저장 데이터 등) 까지도 Redis 메모리를 차지하게 됩니다.
결국 불필요한 데이터가 캐시에 쌓이고, 진짜 자주 조회되는 데이터가 밀려나 Eviction(캐시에서 제거)될 가능성이 높아집니다.
예를 들어, 사용자가 방금 저장한 댓글이 단 한 번도 조회되지 않더라도, 캐시에는 이미 저장되어 있습니다.
이러한 낭비를 막기 위해 TTL(Time To Live, 만료 시간)을 설정하여
일정 시간이 지나면 사용되지 않는 데이터는 자동으로 삭제되도록 하는 것이 좋습니다.
- 쓰기 속도가 느려질 수 있습니다. (DB 저장 + Redis 저장 = 2번 작업)
정리
| 전략 이름 | 설명 |
| Cache Aside | 캐시에 먼저 접근, 없으면 DB에서 조회 후 캐시에 저장 |
| Write Around | 저장 시 DB에만 반영, 캐시는 건드리지 않음 |
| Write Through | 저장 시 DB와 캐시에 모두 반영, 항상 최신 상태 유지 |
✅ 마무리 한 줄 요약
- Cache Aside 전략은 조회 시 캐시에 먼저 접근하고, 없으면 DB에서 가져와 저장합니다.
- Write Around 전략은 저장 시 DB에만 반영하고, 조회 시 캐시에 저장합니다.
- Write Through 전략은 저장 시 캐시와 DB에 동시에 저장하여 항상 최신 상태를 유지합니다.
참고 자료
'Redis' 카테고리의 다른 글
| Redis 기본 사용법 (0) | 2025.07.03 |
|---|---|
| Redis 기본 개념 (4) | 2025.07.03 |