왜 Cache가 필요한가? 실무에서 꼭 알아야 할 캐시 패턴 10가지!

Cache는 왜 필요할까?

• DB는 느리고 비싼 자원 → 요청이 몰리면 쉽게 과부하
• 캐시는 빠른 메모리 → 자주 쓰는 데이터를 미리 올려두고 바로 꺼내씀
• 결과적으로
  • 서버 부하 줄이기
  • 응답 속도 빨라짐
  • DB 장애 위험 감소
    
    • 부하땜에  DB서버 죽음..ㅋㅋ

자주 사용하는건 캐시에 두고 DB는 꼭 필요할 때만 사용하자!

 

Cache 기법 4대장

(1) TTL (Time To Live)

• 캐시에 넣을 때 시간 제한을 둠 → 일정 시간 지나면 자동 삭제
• 장점: 실시간성이 덜 중요한 데이터에 적합하며 캐시가 무한정 커지지 않음
• 단점: DB 데이터가 바뀌면(update) 캐시 데이터와 불일치가 발생할 수 있음
  • 그래서 DB가 업데이트 될 때 관련 캐시를 즉시 삭제!
    • 다음 요청이 들어오면 DB에서 불러오고 최신 데이터로 업데이트(Lazy Loading)

(2) Lazy Loading (= Cache-Aside)

• 조회 시도 → 캐시에 없으면(DB에서 가져와) 캐시에 저장 → 응답
• 장점: 자주 쓰는 것만 캐시에 남음
• 단점: 첫 요청은 무조건 DB에 접근해야 하기 때문에, 캐시 미스율이 높음

(3) Write-Through

• 데이터를 바꿀 때 캐시에 먼저 반영하고 데이터베이스에 변경 내용을 반영
  
• 장점: 캐시랑 DB가 항상 똑같음(일관성 유지)
• 단점: 데이터 변경작업이 많을 경우 캐시도 계속 업데이트 → 부하(성능저하)
• 데이터의 일관성이 중요할 때 사용!

(4) Write-Back (= Write-Behind)

• 캐시에 먼저 데이터를 기록하고, 일정 시간 후에 DB에 저장하는 방식
  • HBase에서 비슷한 방식을 사용 함 → data를 MemStore에 올렸다가 다 차면 HDFS에 Flush
    • 또한 HDFS가 로컬에 있으면 더 빠름!
• 장점: 쓰기가 엄청 빠름
• 단점: 캐시가 날아가면 DB 반영 전 데이터 잃을 수 있음
  • HBase에서는 WAL(Write-Ahead Log)에 먼저 기록하여 서버가 죽더라도 다시 복구 가능!

Cache 추가 기법

(5) Refresh-Ahead(= Preemptive Cache)

• TTL 만료를 기다리지 않고, 만료되기 전에 미리 새 데이터로 갱신
• 장점: 사용자가 캐시 미스없이 최신 데이터를 받음
• 단점: 갱신했는데 실제로 안 쓰이면 리소스 낭비(필요없는 데이터도 미리 갱신할 경우)
• 사용예시 :  홈 화면, 인기 게시글 Top 10
  • Redis Refresh 전략, CDN Cache Refresh

(6) Event-driven Invalidation

• DB에서 데이터가 바뀌면 Kafka 같은 메시지 브로커로 이벤트를 발행 → 캐시에서 해당 키만 삭제/갱신
• 장점: TTL 기다릴 필요 없이 항상 최신 데이터 유지
• 단점: DB 이벤트 감지 + 캐시 무효화 로직을 따로 구현해야 함 (복잡), 이벤트 파이프라인 운영이 필요
• 사용 예시 : 상품재고나 가격
  
  • DB+Kafka+Redis Cache Architecture

재고같은 녀석은 최신으로 유지해야하니 요런식으로 하면 좋을듯!

조금 더 디테일하게 그려보면

(7) Cache Stampede 방지

• 인기 캐시가 동시에 만료돼서 수천 요청이 DB로 몰리는 걸 막음
• 장점: 서버가 터지는 대란 상황 예방
• 단점: 구현이 어렵고, 잠깐 오래된 데이터를 보여줄 수도 있음
  • 왜 어렵나?
    • 동시성 제어(Lock, Mutex) 문제
      • 여러 요청이 동시에 캐시 미스가 나면 어떤 요청이 DB에 것을 가져와야할지 정해야 함.
        • 하나의 요청이 가면 다른 요청들은 Lock~! 즉, 대기해야함
        • Lock관리가 까다로움
          • 분산 환경(멀티서버)에서는 분산락(ex. Redis Redlock)을 구현해야 함
          • Lock을 잘못풀면 DeadLock, 잘못유지하면 Race Condition을 발생 함
    • Stale Data(오래된 데이터) 허용 전략
      • 캐시가 만료됐는데 동시에 DB요청하는것을 막으려면? → 잠깐 오래된 데이터를 계속 보여줘야 함
      • TTL이 끝나도 조금 더 사용하다가 백그라운드에서 새 데이터로 갱신(Lazy Refresh)하는 방식
      • 일관성 있는 데이터 VS 성능 사이에서 트레이드오프가 생김
        • 데이터 성질을 파악해서 활용해야 함
          • 금융/주식 같이 정확성이 필요한 곳에서는 사용이 어렵다.
          • 뉴스/랭킹 같은 곳에서는 허용 가능 함.
    • 재갱신 시점 제어(Early Refresh, Jitter)
      • 모든 캐시가 동시에 만료되면 DB부하가 큼 → 랜덤 Jitter를 TTL에 추가해서 분산 시킴
      • Jitter넣는 로직을 전역적으로 적용해야 함
        • 어디까지 Jitter를 허용해야할지 정해야 함(10초? 10분?)
        • 비즈니스마다 민감도가 달라서 튜닝이 어려움
• Stampede 방지 패턴 3가지
  • 분산락(Distributed Lock)

• • TTL+Jitter
  • Stale-While-Revalidate
• 읽어보면 좋을만한 tip - 링크

(8) Write-Around

• 데이터 변경은 DB에만 저장 → 읽을 때만 캐시에 적재
• 장점: 캐시에 불필요한 쓰기 작업 줄임 (데이터 변경이 적은 데이터에 적합)
• 단점: 데이터가 자주 바뀌면, 캐시가 비어있어서 계속 DB만 호출 함
• 데이터 변경이 적고 조회가 많은 서비스에 적합 함

(9) Multi-level Cache (L1/L2)

• 서버 내부(L1) + 외부 분산 캐시(L2)를 같이 사용
  • L1 : 서버 메모리 캐시라서 엄청 빠름, 하지만 서버별로 따로 관리가 됨)
  • L2 : 외부캐시(Redis 등)라서 서버끼리 공유가능
• 장점: 초고속 접근(L1) + 여러 서버에서 공유(L2)
• 단점: 계층이 늘어나 관리 복잡, 동기화 문제 발생 가능

(10) Data-structure Cache

• key-value뿐만 아니라 랭킹, 집계 결과 같은 구조화된 데이터 캐싱
• 장점: 계산 없이 바로 제공, 속도 최고
• 단점: 데이터 업데이트 때마다 캐시도 계속 갱신 해야 함

Cache 마무리

1) 캐시와 일관성(Consistency) 문제

• Strong Consistency : 항상 최신 데이터를 보여줌 → 속도는 조금 손해
• Eventual Consistency : 약간 늦더라도 언젠간 맞춰짐 → 속도는 빠름캐시를 쓰면 항상 나오는 고민은 속도 vs 정확성 입니다.
• 우리 서비스에서는 어떤 게 더 중요한가? 를 먼저 정하기!!
• 금융/결제 서비스라면 정확성, 뉴스/랭킹 서비스라면 속도!
  즉, 캐시 활용은 결국 속도 ↔ 정확성의 줄다리기입니다.

2) 실무 사례/Best Practice

• 쇼핑몰 → 상품 재고/가격
  • Event-driven Invalidation 
• 뉴스/콘텐츠 서비스 → 인기 기사 Top 10
  • Refresh-Ahead (만료 전에 미리 갱신, 캐시 미스 최소화)
• 로그/분석 시스템 → 대량 쓰기/집계
  • Write-Back + Batch 처리 (캐시에 쓰고 나중에 묶어서 DB 반영)

3) 고가용성(High Availability) 관점

캐시도 결국 시스템이기 때문에 장애 대비가 필수입니다.
캐시로 인해 장애로 이어지는 상황은 반드시 피하기!

• 캐시가 죽으면? → Fallback 전략 필요
• (캐시가 안 되면 DB에서 직접 가져오고, 일시적으로 DB Scale-up 고려)
• HA 구성 → Redis Cluster, Sentinel 등을 활용해 고가용성 확보