[CS] 캐싱 전략

캐싱 (Caching)

  - 자주 사용하는 데이터를 미리 저장해 두고, 필요할 때 빠르게 가져와서 사용하는 기술

  [장점]

     i. (적절하게 사용할 경우) 성능 향상

     ii. 리소스 절약

        : 네트워크 트래픽 감소 & 데이터베이스 부하 감소

     iii. 지연 시간 응답 → 사용자 경험 개선

  [고려사항]

     i. 캐시된 데이터와 원본 데이터 간 불일치가 발생할 수 있음

     ii. 유효성 관리 방법

        · TTL로 데이터 갱신 or 수동으로 캐시 무효화

     iii. 불필요한 캐싱은 메모리 낭비로 이어질 수 있음

     iv. 캐싱 처리를 하는 게 적합한 상황인지 판단해야 함

        · 읽기 작업이 많은 경우 캐싱이 유용함

        · 쓰기 작업이 많은 경우 일관성 문제가 생길 가능성이 높음

 

 

---

캐싱 전략

# Write-Through 캐싱

  - 데이터를 캐시에 쓰는 동시에, 원본 저장소(DB)에도 즉시 기록함

  - 추천 대상 : 실시간 데이터 일관성이 중요한 경우

  [장점]

     · 캐시에 항상 최신 데이터가 유지됨 → 데이터 일관성 보장

  [단점]

     · 쓰기 작업 시 속도가 느릴 수 있음

 

# Write-Back 캐싱

  - 데이터를 캐시에 쓰고, 원본 저장소에는 특정 조건일 때에만 기록함

     ex) 캐시 만료, 시스템 종료 등

  - 추천 대상 : 데이터 변경 빈도가 높고, 일관성이 덜 중요한 경우

  [장점]

     · 쓰기 작업이 빠름

     · 원본 저장소 접근 횟수 감소 → 부하 감소

  [단점]

     · 캐시 손상 시 데이터가 유실될 수 있음

# Read-Through 캐싱

  - 데이터 요청 시 캐시를 먼저 확인하고, 캐시에 없으면 원본 저장소에서 데이터를 먼저 가져와 캐시에 저장함

  - 추천 대상 : 읽기 작업이 빈번한 경우

  [장점]

     · 자주 조회되는 데이터인 경우 빠른 응답 가능

     · 캐시에 없는 데이터만 원본에서 가져오기 때문에 효율적임

  [단점]

     · 캐시에 없을 경우 초기 요청이 느릴 수 있음

 

# Lazy-Loading 캐싱

  - 데이터를 요청할 때에만 캐시에 저장함

  - 추천 대상 : 요청이 간헐적으로 발생하는 경우

  [장점]

     · 초기 캐시 로드 시간이 필요 없음

     · 필요한 데이터만 캐싱 처리 → 메모리 효율 UP

  [단점]

     · 해당 데이터를 처음으로 요청하는 경우 응답이 느릴 수 있음

     · 자주 사용되지 않는 데이터는 캐싱되지 않음

 

# Time-to-Live (TTL)

  - 캐시된 데이터의 유효 기간을 설정하여, 일정 시간이 지나면 무효화시킴

  - 실시간 데이터가 필요 없는 경우

  [장점]

     · 오래된 데이터를 자동으로 갱신할 수 있음

     · 메모리 관리 용이

  [단점]

     · 유효 기간을 적절하게 설정하지 않는 경우 문제가 생길 수 있음

        - TTL이 너무 짧을 때 : 갱신 빈도 증가 → 원본 저장소 부담

        - TTL이 너무 길 때 : 캐시된 데이터와 원본 데이터 간 불일치 가능성

 

# LRU (Least Recently Used)

  - 가장 오래 사용되지 않은 캐시 데이터를 삭제함

 

# LFU (Least Frequently Used)

  - 가장 적게 사용된 캐시 데이터를 삭제함