개요
캐시란? 자주 사용하는 데이터나 값을 미리 복사해 놓는 임시 장소
라고 할 수 있습니다.
현 회사에서는 잘 활용하고 있지만 전 회사에서는 활용을 못했던 기억이 있어서 캐시에 대해 정리하게 되었습니다.
언제 캐쉬하는가?
캐시를 잘 사용하기 위해서는 아래와 같은 특징을 가질 때 활용도가 높아집니다.
- 코드성 데이터처럼 사용 빈도가 높다.
- 데이터의 수정/변경이 적다.
- 메인 화면에서 호출된다.
- 리소스가 많이 든다.
읽기 캐시 전략
- Cache Aside
- 캐시에 데이터가 있는지 확인
- 데이터가 존재하면(Cache Hit) 캐시에서 데이터를 반환
- 데이터가 존재하지 않으면(Cache Miss) 어플리케이션이 DB에서 조회 후 캐시에 저장하고 데이터 반환
해당 방식은 Cache miss로 인한 지연이 노출되므로 주의가 필요하다.
- Read Through
- 캐시에 데이터가 있는지 확인
- 데이터가 존재하면(Cache Hit) 캐시에서 데이터를 반환
- 데이터가 존재하지 않으면(Cache Miss) 캐시가 DB에서 조회 후 캐시에 저장하고 데이터 반환
Cache Aside와 비슷하지만 캐시에 의존성이 높아 캐시시스템의 장애 시 캐시를 사용하는 서비스에서 관련 장애가 발생으로 이어지기에 캐시관리가 중요합니다.
쓰기 캐시 전략
쓰기 요청 시 어떤 시점에 캐시 갱신을 하는지에 따라 나뉩니다.
- Write Around : 캐시를 갱신하지 않음
- Write Through : 캐시를 바로 갱신
- Write Behind : 캐시를 모아서 나중에 갱신
Write Aroung
- 데이터 추가/업데이트 요청이 들어오면 DB 에만 데이터를 반영
- 쓰기 작업에서 캐시는 건들지 않고 읽기 작업 시 Cache Miss 가 발생하면 업데이트 됨
Write Through
- 캐시에 데이터를 추가하거나 업데이트
- 캐시가 DB 에 동기식으로 데이터 갱신
- 캐시 데이터를 반환
Write Behind
- 캐시에 데이터를 추가하거나 업데이트
- 캐시 데이터 반환
- 캐시에 있던 데이터는 이후에 별도 서비스 (이벤트 큐 등) 를 통해 비동기로 DB 에 업데이트
캐시와 DB를 비동기로 동기화를 하는 방법으로 쓰기 작업이 많은 경우에 적합하다. 하지만 캐시에 동기화 중 장애가 발생할 시 데이터가 유실될 수 있다.
