캐시(Cache) : 자주 사용하는 데이터를 더 빠른 저장소에 임시로 저장해 재사용하는 기술
→ 메모리에서 즉시 응답이 가능해 속도가 향상되고, DB 부하가 감소하고, 트래픽이 절감함
캐시의 기본 구조
요청(Request)
↓
[ 캐시(Cache) ] → HIT → 빠른 응답
↓
MISS (없을 경우)
↓
[ DB ] → 데이터 조회 후 캐시에 저장
| 용어 | 설명 | 결과 |
|---|---|---|
| Cache Hit | 캐시에 데이터가 있음 → 바로 응답 | 매우 빠름 |
| Cache Miss | 캐시에 없음 → DB 조회 후 캐시에 저장 | 느림 (1회성) |
<aside> 💡
DB vs. 캐시
DB : 데이터를 영구적으로 저장하며 항상 정확성과 정합성을 유지 → 안정적이지만, 상대적으로 느림
캐시 : 자주 사용하는 데이터를 메모리에 임시 저장 → 응 답 속도는 높지만, 서버 재시작 시 데이터가 사라지고, 최신 데이터를 보장하지 않음
</aside>
로컬 캐시(Local Cache) : 애플리케이션 내부 메모리에 저장
ex: ConcurrentHashMap, Caffeine
⇒ 빠르지만, 서버 간 데이터 공유 불가
분산 캐시(Distributed Cache) : 외부 서버에 저장해 여러 인스턴스가 공유
ex: Redis, Mamcached
⇒ 느리지만, 여러 서버에서 공유 가능
| 전략 | 설명 | 특징 |
|---|---|---|
| Write-through | DB에 쓰는 동시에 캐시도 갱신 | 데이터 일관성 ↑ |
| Write-back | 캐시에 먼저 쓰고, 나중에 DB 반영 | 속도 ↑, 위험도 ↑ |
| Cache-aside (Lazy Loading) | 요청 시 캐시 확인 → 없으면 DB 조회 후 캐시 저장 | 가장 일반적 |
| Cache Invalidation | 데이터 변경 시 캐시 삭제 또는 갱신 | 일관성 유지 핵심 |
Cache-aside 전략의 흐름
요청 → 캐시 확인
↓
[없음] → DB 조회
↓
데이터 캐시에 저장 (TTL 설정)
↓
응답 반환
: DB 값은 바뀌었는데, 캐시에는 옛날 값이 남아 있는 경우
→ 원인: 캐시의 TTL(유효 기간)이 길어 오래된 데이터를 계속 제공하거나 DB 업데이트가 누락됨