캐싱 전략(Caching Strategy) 종류

캐싱 전략(Caching Strategy)이 잘못되면

클라이언트 측에 불필요한 데이터가 남거나,

반대로 너무 자주 서버를 호출하게 되어 캐시의 이점이 사라집니다.

 

따라서 어떤 데이터를, 어디에, 얼마나 오래, 어떤 조건으로 캐시할지를 신중하게 설계해야 합니다.

 

🧭 캐싱 전략(Caching Strategy) 종류

1. ✅ Cache-aside (Lazy loading)

필요한 데이터만 캐시에 저장하는 전략

• 동작 방식:
  • 요청이 들어오면 먼저 캐시에 있는지 확인
  • 없으면 DB나 서버에서 가져와 캐시에 저장
  • 다음 요청부터는 캐시에서 응답
• ✅ 장점: 불필요한 데이터 미저장
• ❌ 단점: 첫 요청은 느림
• 적합한 경우: 읽기 많은 시스템 (예: 상품 조회, 뉴스)

---

2. 🧠 Write-through

데이터를 DB에 쓸 때 캐시에도 동시에 저장

• 동작 방식:
  • 클라이언트가 데이터를 수정하면
  • DB와 캐시에 동시에 기록
• ✅ 장점: 항상 최신 데이터가 캐시에 존재
• ❌ 단점: 쓰기 성능 느림, 트래픽 증가
• 적합한 경우: 쓰기와 읽기 비율이 비슷한 시스템

---

3. 🔁 Write-back (Write-behind)

데이터를 캐시에 먼저 쓰고, 일정 시간 후에 DB에 반영

• ✅ 장점: 쓰기 성능 빠름
• ❌ 단점: 장애 발생 시 DB와 캐시 데이터 불일치 가능성
• 적합한 경우: 성능 최우선, 데이터 일관성 덜 중요한 경우 (예: 로그 저장)

---

4. ⏰ Time-to-Live (TTL, 만료 시간 기반)

캐시 항목에 유효 기간을 지정해서, 지정 시간이 지나면 삭제

• 예: max-age=3600 → 1시간 후 무효
• ✅ 장점: 오래된 데이터 자동 정리
• ❌ 단점: 실제 데이터가 바뀌어도 무효화 전까지는 반영되지 않음
• 적합한 경우: 자주 바뀌지 않는 데이터 (카테고리 목록 등)

---

5. 🏷 ETag / Last-Modified 기반 캐싱

클라이언트가 이전에 받은 리소스의 상태 정보를 서버에 보내어 변경 여부만 확인

• 서버는:
  • 변경 X → 304 Not Modified 응답 (재전송 없음)
  • 변경 O → 새 파일 전송
• ✅ 장점: 불필요한 데이터 전송 방지
• 브라우저 캐싱과 매우 궁합 좋음

---

🧹 캐시 무효화(Cache Invalidation) 전략

전략	설명
TTL 기반 만료	일정 시간이 지나면 자동 삭제
수동 무효화	DB 변경 시 API로 캐시 직접 삭제 (예: Redis에서 삭제)
버전 명시	URL에 버전을 붙여 새 파일로 인식 (style.v2.css)
ETag, Last-Modified	서버와 변경 여부 비교 후 업데이트

 

---

⚠️ 캐싱 전략 설계 시 주의사항

항목	이유
민감 데이터는 캐싱 금지	로그인 정보, 개인정보 등 노출 위험
캐시 무효화는 명확해야 함	안 그러면 오래된 데이터 계속 사용
TTL 값은 실제 갱신 주기 고려	너무 길면 구버전 유지, 너무 짧으면 캐시 효과 없음
캐시 크기, 만료 기준 정해야 함	메모리 낭비 및 캐시 오염 방지 필요

 

---

💡 요약

 

전략 유형	대표 전략	주 사용처 예시
읽기 최적화	Cache-aside	상품정보, 뉴스기사
일관성 유지	Write-through	사용자 설정
성능 우선	Write-back	로그 데이터
기간 제한	TTL	인기글 리스트
변경 감지	ETag / Last-Modified	정적 리소스