Cache

Cache

자주 사용하는 데이터를 저장소에 임시로 저장해 재사용하는 기술

• DB, API에 의존하는 것이 아닌 메모리에 저장해 쓰므로 응답성이 빠름

기본 흐름

HIT → Cache 에 데이터가 있을 경우

MISS → Cache 에 데이터가 없을 경우

요청 → 캐시 → HIT → 응답

          → MISS → 데이터 저장소 조회 (조회 하면서 캐시에 데이터도 저장)

사용 방향

데이터의 정합성 (DB) + 빠른 응답성 (Cache)

실 사용 예시

• 인기 게시글과 상품의 조회

• 반복 DB 조회

• 서버 부하 방지용

캐시의 종류

• 로컬 캐시 → 어플리케이션 내부 메모리에 저장 → ConcurrentHashMap, Caffeine

• 분산 캐시 → 외부 서버에 저장, 인스턴스 공유 → Redis, Memcached

캐시 전략

• Cache-aside

  • 요청시 캐시를 확인 → 없으면 DB 조회, 캐시 저장

• Write-through

  • DB에 기록 시 동시에 캐시도 갱신

• Cache Invalidation

  • 데이터 변경 시 캐시 삭제 또는 갱신

• Write-Back

  • 캐시에 먼저 데이터를 쓰고 후에 DB에 반영

TTL

Time-To-Live, Eviction Policy

• TTL → 유효기간

  • 강제로 일정 주기로 캐시를 최신화함

  • 캐시에 유효기간을 정해서 만료 되면 자동으로 삭제되게 함

  • 조회가 잦고 변경이 적으면 캐싱 효율이 올라감

  • 변경주기가 긴 데이터는 TTL을 길게 두기

• TTL 설계 원칙 예시

  데이터 종류	TTL 예시	이유
  사용자 프로필	1시간~1일	자주 안 바뀜
  게시글 상세	5~30분	일부 수정 가능성 있음
  실시간 인기글	1~5분	빠르게 변동됨
  로그인 세션 / 토큰	10~60분	보안 및 유효성
  통계 / 대시보드	5분 이내	최신 데이터 필요

• Eviction Policy

  • 삭제 정책

    • LRU → 최근 사용하지 않은 항목을 제거

    • LFU → 사용 빈도가 낮은 항목 제거

    • FIFO → 먼저 들어온 항목을 제거

캐시 설계

• 캐시는 항상 보조 수단

• TTL 은 적당한 길이로 놓아야함 (너무 짧아도 갱신이 잦아 효율이 낮아짐)

• 캐시의 Key 설계는 단순하고 명확해야함

  • 도메인:ID 순으로 활용하는 것이 좋음 (product:1)

• 캐시의 장애 대비하기 → DB 조회로 이어지도록 처리

key의 네이밍 규칙

• 일관된 형식 유지 (도메인:식별자)

• 복합 조건일 경우 파라미터를 포함해야함 (search:{keyword}:{page})

• key 앞에 prefix 를 붙여주는게 일반 (같은 value 로 인한 덮어쓰기 방지) → (key = "postId:" + "#postId") (Redis 는 prefix 로 분류)

• 구분자는 :, :: → : 는 계층의 표시

• key 는 코드상 상수로 관리할 것

private static final String USER_CACHE_PREFIX = "user:";