Cache Aside 패턴이라고도 불림.
데이터를 찾을때 우선 캐시에 저장된 데이터가 있는지 우선적으로 확인하는 전략.
만일 캐시에 데이터가 없으면 DB에서 조회함.
반복적인 읽기가 많은 호출에 적합.
캐시와 DB가 분리되어 가용되기 때문에 원하는 데이터만 별도로 구성하여 캐시에 저장
캐시와 DB가 분리되어 가용되기 때문에 캐시 장애 대비 구성이 되어있음.
만일 redis가 다운 되더라도 DB에서 데이터를 가져올수 있어 서비스 자체는 문제가 없음.
대신에 캐시에 붙어있던 connection이 많았다면, redis가 다운된 순간 순간적으로 DB로 몰려서 부하 발생.
Look Asdie Cache 패턴은 애플리케이션에서 캐싱을 이용할때 일반적으로 사용되는 기본적인 캐시 전략입니다.
이 방식은 캐시에 장애가 발생하더라도 DB에 요청을 전달함으로써 캐시 장애로 인한 서비스 문제는 대비할수 있지만, Cache Store와 Data Store(DB)간 정합성 유지 문제가 발생할 수 있으며, 초기 조회 시 무조건 Data Store를 호출 해야 하므로 단건 호출 빈도가 높은 서비스에 적합하지 않습니다.
대신 반복적으로 동일 쿼리를 수행하는 서비스에 적합한 아키텍처입니다.
이런 경우 DB에서 캐시로 데이터를 미리 넣어주는 작업을 하기도 하는데 이를 Cache Warming이라고 합니다.
<aside> ❗
Cache Warming
미리 cache로 db의 데이터를 밀어 넣어두는 작업을 의미합니다.
이 작업을 수행하지 않으면 서비스 초기에 트래픽 급증시 대량의 cache miss 가 발생하여 데이터베이스 부하가 급증 할 수 있습니다. (Thundering Herd)
다만, 캐시 자체는 용량이 작아 무한정으로 데이터를 들고 있을수는 없어 일정시간이 지나면 expire되는데, 그러면 다시 Thundering Herd가 발생될 수 있기 때문에 캐시의 TTL을 잘 조정할 필요가 있습니다.
참고로 Thundering Herd 는 모든 지점에서 발생되는 것은 아니고, 서비스의 첫 페이지와 같은 대부분의 조회가 몰리는 지점에서 주로 발생된다고 보면 됩니다.
</aside>