[Spring Cache] 캐시란 무엇인가

왜 캐시를 쓰는가

사용자 목록을 조회하는 API가 있다고 하자. 매번 DB에서 SELECT * FROM users를 실행한다. 사용자 100명이 1초에 한 번씩 이 API를 호출하면, 초당 100번의 동일한 쿼리가 DB로 날아간다.

문제는 사용자 목록이 거의 안 바뀐다는 것이다. 새 가입이 하루에 10건이면, 나머지 86,390번의 쿼리는 같은 결과를 반환하면서 DB의 CPU, 메모리, 커넥션 풀을 소비한다.

캐시는 이 반복을 없앤다. 처음 조회한 결과를 메모리에 저장해두고, 같은 요청이 오면 DB를 거치지 않고 메모리에서 바로 반환한다. DB 왕복 시간(보통 수~수십 ms)을 완전히 없앨 수 있다.

일상에서 비유하면, 책꽂이에서 책을 찾는 것(DB 조회)과 책상 위에 펴둔 책을 읽는 것(캐시 조회)의 차이다. 자주 보는 책은 책상 위에 올려두면 매번 책꽂이까지 가지 않아도 된다.

캐시의 핵심 개념

캐시 히트와 캐시 미스

캐시의 동작은 두 가지 결과로 나뉜다.

• 캐시 히트 (Cache Hit) : 요청한 데이터가 캐시에 있다. 캐시에서 바로 반환한다.
• 캐시 미스 (Cache Miss) : 요청한 데이터가 캐시에 없다. DB에서 조회한 후 캐시에 저장하고 반환한다.

캐시 히트와 미스가 실제로 어떤 흐름으로 동작하는지 보면 차이가 명확하다.

• 캐시 히트 (초록 영역) : 캐시에 데이터가 있으면 DB를 거치지 않고 바로 반환한다.
• 캐시 미스 (주황 영역) : 캐시에 없으면 DB를 조회하고, 결과를 캐시에 저장한 뒤 반환한다.

적중률(Hit Rate)이 캐시의 핵심 지표다. 적중률이 높을수록 DB 부하가 줄어든다.

적중률 = 캐시 히트 수 / 전체 요청 수

적중률 90%면, 10번 중 9번은 DB를 안 거친다. 1,000 RPS(초당 요청)인 서비스에서 적중률 90%면 DB에는 100 RPS만 도달한다.

캐시 키와 캐시 값

캐시는 본질적으로 key-value 저장소다.

• 캐시 키 : 어떤 데이터를 가리키는 식별자. 메서드의 파라미터가 주로 키가 된다.
• 캐시 값 : 실제 저장되는 데이터. 메서드의 반환 값이 저장된다.

키	값
users:all	전체 사용자 목록
channels:user:abc-123	사용자별 채널 목록
post:42	42번 게시글

키를 잘 설계해야 한다. 키가 너무 넓으면 (예: 전체 사용자 목록을 하나의 키로) 한 명만 추가되어도 전체 캐시를 무효화해야 한다. 키가 너무 좁으면 (예: 사용자 1명 단위) 캐시 항목이 너무 많아져서 메모리를 낭비한다.

캐시 전략

TTL (Time To Live)

캐시에 저장된 데이터의 유효 기간이다. TTL이 지나면 자동으로 삭제되고, 다음 요청에서 DB를 다시 조회한다.

• TTL 짧게 (예: 30초) : 데이터 신선도 높음, 적중률 낮음
• TTL 길게 (예: 1시간) : 적중률 높음, 오래된 데이터를 볼 가능성

TTL 설정은 데이터의 변경 빈도에 따라 결정한다. "이 데이터가 30초 동안 변하지 않아도 괜찮은가?"를 기준으로 판단하면 된다.

데이터	변경 빈도	적절한 TTL
시스템 설정	거의 안 바뀜	30분~1시간
사용자 목록	가끔 바뀜	5~10분
인기 게시글	자주 바뀜 (조회수)	1~5분
실시간 알림	매우 자주	30초 이하 또는 캐시 X

제거 정책

캐시 메모리가 가득 차면, 어떤 항목을 제거할지 결정해야 한다. 대표적인 정책은 세 가지다.

• LRU (Least Recently Used) : 가장 오래 안 쓴 항목을 제거. 가장 널리 사용되는 전략이다. "최근에 안 쓴 건 앞으로도 안 쓸 확률이 높다"는 가정.
• LFU (Least Frequently Used) : 사용 횟수가 가장 적은 항목을 제거. 자주 쓰는 데이터를 오래 유지하지만, 한때 인기 있다가 식은 데이터가 빠지지 않는 문제가 있다.
• FIFO (First In First Out) : 가장 먼저 들어온 항목을 제거. 단순하지만, 자주 쓰는 데이터도 오래되면 밀려난다.

네 가지 전략을 단순성과 적중률 두 축으로 비교하면 위치가 뚜렷하게 갈린다. FIFO는 가장 구현이 단순하지만 적중률이 가장 낮고, W-TinyLFU는 가장 복잡하지만 실제 워크로드에서 압도적으로 높은 적중률을 보인다.

• FIFO : 선입선출. 단순하지만 자주 쓰는 데이터도 오래되면 제거된다.
• LRU : 최근 안 쓴 것 제거. 대부분의 캐시 라이브러리 기본값이었다.
• LFU : 적게 쓴 것 제거. 과거 인기 있었다가 식은 데이터가 오래 남는 단점이 있다.
• W-TinyLFU : 최근성과 빈도를 함께 고려. Caffeine이 사용하는 전략.

캐시 무효화

데이터가 변경되면 캐시도 갱신해야 한다. 안 그러면 사용자가 오래된 데이터를 계속 보게 된다.

캐시 무효화 전략은 두 가지다.

• TTL 기반 자동 만료 : 일정 시간이 지나면 캐시가 자동으로 삭제된다. 구현이 간단하지만, TTL 내에 데이터가 바뀌면 그 기간 동안 오래된 값을 반환한다.
• 명시적 무효화 : 데이터가 변경되는 시점에 직접 캐시를 삭제/갱신한다. 데이터 일관성은 높지만, "어디서 캐시를 무효화해야 하는지" 빠짐없이 관리해야 한다.

실무에서는 두 가지를 함께 쓴다. 명시적 무효화로 대부분의 변경을 즉시 반영하고, TTL로 혹시 놓친 경우를 커버한다.

로컬 캐시 vs 분산 캐시

캐시를 어디에 저장하느냐에 따라 두 가지로 나뉜다.

로컬 캐시는 각 서버의 JVM 메모리 안에 독립적으로 존재한다. 서버 A의 Caffeine 캐시를 서버 B는 알 수 없다. 반면 분산 캐시는 외부 Redis 서버 하나를 모든 서버가 공유하기 때문에 데이터 일관성이 보장된다. 대신 네트워크 왕복이 필요해서 로컬 캐시보다 느리다.

구분	로컬 캐시 (Caffeine)	분산 캐시 (Redis)
저장 위치	각 서버의 JVM 메모리	외부 Redis 서버
속도	매우 빠름 (나노초)	빠름 (네트워크 왕복 1~2ms)
서버 간 공유	불가능	가능
서버 재시작 시	캐시 소멸	유지
적합한 상황	단일 서버, 읽기 위주	다중 서버, 데이터 일관성 중요

서버가 한 대면 로컬 캐시로 충분하다. 서버가 여러 대로 늘어나면, 서버 A에서 데이터를 수정했는데 서버 B의 로컬 캐시에는 반영이 안 되는 문제가 생긴다. 이때 Redis 같은 분산 캐시가 필요하다.

캐시를 쓰면 안 되는 경우

모든 데이터에 캐시를 걸면 좋을 것 같지만, 오히려 문제를 일으키는 경우가 있다.

• 실시간성이 중요한 데이터 : 결제 잔액, 재고 수량 등. 캐시된 오래된 값으로 이중 결제나 초과 판매가 발생할 수 있다.
• 쓰기가 읽기보다 많은 데이터 : 캐시를 저장하자마자 무효화해야 하므로 오히려 오버헤드만 늘어난다.
• 매번 다른 결과를 반환하는 데이터 : 랜덤 추천, 검색 결과 등. 캐시 키가 너무 다양해서 적중률이 극히 낮다.

읽기가 많고, 변경이 적고, 약간의 지연이 허용되는 데이터가 캐시에 가장 적합하다.

어떤 데이터가 캐시에 맞고, 어떤 데이터가 맞지 않는지를 한눈에 정리하면 이렇다.

Q&A

---