캐시 전략

• 캐시는 자주 사용하면서 자주 변경되지 않는 데이터에 대해 캐시를 사용하면 좋음
• 캐시는 휘발성이 있다는 점을 기억할 것(중요한 정보는 저장해선 안 된다)
• 따라서, 장애 발생시 대응 방안도 대비해야 함
• 캐시 만료 정책도 필요(사용자가 시간이 지남에 따라 오래된 자료를 볼 수 있기 때문)
• 그에 따라 발생하는 cache stampede 현상 대비 필요

용어 정리

cache-hit: 캐시 스토어에 데이터가 있으면 로드
cache-miss: 캐시 스토어에 데이터가 없으면 DB에서 로드

캐시 스토어는 캐시, DB는 데이터베이스를 가리킴

읽기 전략

look-aside(cache-aside)

• 캐시 조회 후 있으면 가져오고 없으면 DB에서 가져옴
• 캐시 저장 주체가 애플리케이션 서버
• 가장 일반적인 캐시 전략
• 반복적인 읽기가 많은 호출에 적합
• 캐시 스토어와 DB 간 정합성 문제 발생할 수 있음
• 캐시 스토어가 다운돼도 DB에서 데이터 조회 가능하지만, 캐시에 connection이 많을 경우 캐시가 다운되면 DB에 순간적으로 부하가 많이 발생(thundering herd)
• cache warming 필요

read-through

• 캐시를 통해서만 데이터를 읽어옴
• 캐시 저장 주체가 DB
• 반복적인 읽기가 많은 호출에 적합
• 캐시 스토어와 DB 간의 동기화가 항상 이루어져 정합성 문제 해결
• 데이터를 조회 속도가 전반적으로 느림
• 캐시 스토어가 다운될 경우 서비스 이용이 불가
• 캐시의 replication 또는 cluster 구성이 필요
• cache warming 권장

쓰기 전략

write-through

• 데이터를 캐시에 저장 후 DB에 저장함
• 데이터가 항상 최신으로 유지됨
• 데이터가 한 번 쓰이고 수정이나 삭제가 이뤄지지 않는 경우에 적합
• 데이터 유실이 발생하면 안 되는 상황에 적합
• 데이터 저장 시 두 번(캐시와 DB)의 write이 발생하여 속도가 느림

write-around

• 모든 데이터를 DB에 저장 (캐시에는 저장하지 않음)
• cache miss 발생할 경우에만 캐시에도 데이터 저장
• write through보다 훨씬 빠름
• cache miss 발생하지 않으면 캐시가 업데이트되지 않으므로 데이터 정합성 문제 발생 가능성
• DB 수정, 삭제 시 캐시도 수정, 삭제하거나 캐시 만료 설정 필요

write-back(write-behind)

• 데이터 저장을 캐시에 해뒀다가 일정 주기마다 배치 작업을 통해 DB에 저장
• 비동기적으로 동작하므로 동기화를 수행하지 않음
• write이 빈번한 작업에 적합
• 캐시 다운되면 서비스 이용 불가
• 캐시에서 오류 발생할 경우 데이터를 영구적으로 잃어버리게 됨
• 캐시 만료 설정이 필요
• 캐시의 replication 또는 cluster 구성이 필요