[TIL] 캐싱 개념과 필요성

1. 캐시의 한 줄 정의: "데이터계의 즐겨찾기"

모든 데이터를 도서관(DB)에서 찾아오기엔 너무 머니까, 자주 보는 책은 내 책상(Cache)에 미리 꺼내두는 것. 책상이 꽉 차면? 안 보는 책부터 치워야 함

---

2. DB와 캐시의 차이

데이터베이스(DB)

• 데이터를 영구적으로 저장하며 항상 정확성과 정합성을 유지하는 시스템.
• 디스크 기반이라 안정적이지만 상대적으로 느림.
• 책(데이터)가 저장되어 있는 도서관(DB)

캐시(Cache)

• 자주 사용하는 데이터를 메모리에 임시 저장
• 응답 속도를 높이고, DB 접근 횟수를 줄이는 데 최적화 되어있음
• TTL만료나 서버 재시작 시 데이터가 사라질 수 있고, 항상 최신 데이터임을 보장하지 않음
• 자주 보는 책(데이터)를 미리 꺼내놓은 책상(캐시)

결론
DB = 신뢰성 중심,
캐시 = 효율성 중심

---

3. 왜 쓰는가? (비즈니스적 관점)

단순히 "빠르다"를 넘어, 돈과 생존의 문제.

• DB의 비명 방지: 수만 명이 동시에 "인기 상품"을 조회할 때 DB는 죽어 나감. 캐시가 앞에서 방패 역할을 해줌.
• 비용 절감: 클라우드 환경(AWS 등)에서 DB 인스턴스 사양을 올리는 것보다 Redis 하나 두는 게 훨씬 저렴함.

---

4. 캐시의 유형

구분	설명	예시
로컬 캐시(Local Cache)	애플리케이션 내부 메모리에 저장	ConcurrentHashMap, Caffeine
분산 캐시(Distributed Cache)	외부 서버에 저장해 여러 인스턴스가 공유	Redis, Memcached

• 로컬 캐시 : 빠르지만 서버간 데이터 공유 불가
• 분산 캐시 : 느리지만 서버에서 공유 가능

---

5. 캐시 전략

전략	설명	특징
Write-through	DB에 쓰는 동시에 캐시도 갱신	데이터 일관성 ↑
Write-back	캐시에 먼저 쓰고, 나중에 DB 반영	속도 ↑, 위험도 ↑
Cache-aside (Lazy Loading)	요청 시 캐시 확인 → 없으면 DB 조회 후 캐시 저장	가장 일반적
Cache Invalidation	데이터 변경 시 캐시 삭제 또는 갱신	일관성 유지 핵심

Cache-aside 전략 흐름

요청 → 캐시 확인
   ↓
  [없음] → DB 조회
   ↓
데이터 캐시에 저장 (TTL 설정)
   ↓
응답 반환

• 장점 : 단순하고 범용적
• 단점 : 처음 요청(캐시 미스)시 느림

---

6. 캐시 일관성(Consistency) 이슈

캐시의 가장 큰 기술적 과제는 "정확성 유지"

TTL(Time-To-Live) & Eviction Policy

• TTL(유효 기간) -> 강제로 일정 주기로 캐시의 데이터 최신화

  • 캐시가 유효한 시간 (만료 후 자동 삭제)
  • 예: set key value EX 300 -> 300초 유지

• Eviction Policy (삭제 정책)

  • LRU: 최근 사용하지 않은 항목 제거
  • LFU: 사용 빈도 낮은 항목 제거
  • FIFO: 먼저 들어온 항목 제거