인메모리 캐시 전략
데이터를 DB나 원본 저장소에서 가져오는 게 아니라, 메모리에 저장하여 데이터 접근 속도를 높이는 방법이다.
디스크 I/O 작업이 많은 기존 방식에 비해, 메모리 방식은 더욱 빠르기에 속도를 높일 수 있다. 따라서 자주 조회되거나 접근 속도가 중요한 데이터는 메모리에 임시 저장함으로써 바르게 반환하고자 하는 목적으로 쓰인다.
다만, 캐시된 데이터가 실제 원본 데이터와 다를 수 있으므로 업데이트/무효화 전략이 요구된다.
캐시 일관성 유지 방법
Write-Through 캐싱
캐시를 통해(write through) 원본 데이터 저장소까지 바로 전달된다는 의미로, 데이터가 캐시에 저장될 때 Database에도 즉시 쓰여지게 한다. 캐시나 DB나 동일한 데이터가 있으니 일관성은 있는데 매번마다 쓰기 작업을 하므로 만족스럽지 않다.
Write-Back(Behind) 캐싱
캐시에 먼저 기록하고 원본 데이터 저장소에 돌아와서(Back) 기록한다는 의미다. 따라서 데이터가 캐시에 선 저장된 뒤 일정 시간 후 Databse에 쓰여진다. 캐시에 자주 접근하는 데이터는 빠른 응답이 가능하고, 나중에 모아서 한꺼번에 DB에 쓰기 처리가 가능해지므로 trough 방식에 비해서는 쓰기 작업이 향상은 되는데 DB 반영 전에 서버 장애 발생 시 데이터가 휘발된다는 치명적인 단점이 있다.
캐시 무효화 방법
TTL(Time-to-live) 설정
캐시될 데이터에 대한 유효 기간을 설정하여 일정 시간이 지나면 캐시에서 자동으로 제거되도록 한다. 이로써 오래된 데이터가 캐시에 남아있는 것을 방지하는데, 이때 데이터에 대한 인위적인 유효기간을 설정하는 것이므로 실제 데이터 갱신 시점과는 차이가 날 것이다.
명시적 무효화
애플리케이션 코드에서 명시적으로 캐시 무효화에 대한 선언을 하는데, 그 시점은 해당 데이터가 수정될 때이다. 이때 캐시를 명시적으로 제거한다거나 갱신한다는 코드를 작성하게 되고 이로써 캐시는 일관성있게 유지할 수 있다. 그러나 이는 코드관리와 유지보수측면에서의 복잡성이 다소 증가함을 알고 있어야 한다.
캐시 배제 패턴(Cache Aside)
지연 로딩과 유사한데, 데이터를 찾는 요청이 들어오면 캐시에서 먼저 찾는다. 그리고 없으면 DB에서 가져와 캐시에 저장해준다. 데이터의 수정 작업이 있다면 DB에 바로 수정시키며 캐시가 가진 수정전 데이터는 무효화(삭제)시킨다. 이를 통해 다음 번에 찾을 때는 캐시에 없으니 DB에서 찾는 것부터 다시 시작할 것이다.
분산 캐시 무효화
여러 서버나 인스턴스가 분산 캐시를 이용할 때, 하나의 서버에서 캐시가 갱신되면 다른 서버의 캐시도 함께 무효화 되도록 Pub/Sub 방식 등을 이용하여 무효화시키는 것이다. Redis를 예로 들어서, Redis를 외부 캐시 저장소로 이용하는 여러 서버가 존재할 때를 가정해본다. 그러면 서버 1이 수정작업이 들어와 Redis에 갱신을 시켰다면 서버2와 서버3이 Pub/sub이 되어있으므로 본인의 캐시를 무효화(혹은 갱신)시키게 된다.