Redis - 캐시(Cache) 전략
캐싱 전략 - 웹 서비스 환경에서 시스템 성능 향상을 기대할 수 있는 기술.
일반적으로 캐시(cache)는 메모리(RAM)사용.
-> DB보다 훨씬 빠르게 데이터를 응답할 수 있어 이용자에게 빠르게 서비스를 제공 가능.
캐시를 효율적으로 이용하기위해서 캐시에 저장할 데이터 특성도 고려해야한다.
-> 자주 조회되는 데이터, 결과값이 자주 변동되지 않고 일정한 데이터, 조회하는데 연산이 필요한 데이터를 캐싱해두면 좋다.
- cache hit: 캐시 스토어(redis)에 데이터가 있을 시 바로 가져옴(빠름)
- cache miss: 캐시 스토어(redis)에 데이터가 없을 경우 어쩔 수 없이 DB에서 가져옴(느림)
캐싱 전략 패턴 종류
데이터 정합성 문제를
적절한 캐시 읽기 전략(Read Cache Strategy)과 캐시 쓰기 전략(Write Cache Strategy)을 통해, 캐시와 DB간의 데이터 불일치 문제를 극복하면서도 빠른 성능을 잃지 않게 하자
캐시 읽기 전략(Read Cache Strategy)
Look Aside 패턴
- Cache Aside 패턴이라고도 불림
- 데이터를 찾을때 우선 캐시에 저장된 데이터가 있는지 우선적으로 확인하는 전략.
만일 캐시에서 데이터가 없으면 DB에서 조회함. - 반복적인 읽기가 많은 호출에 적합.
- 캐시와 DB가 분리되어 가용되기 때문에 원하는 데이터만 별도로 구성하여 캐시에 저장
- 캐시와 DB가 분리되어 가용되기 때문에 캐시 장애 대비 구성이 되어있음.
만일 redis가 다운되더라도 DB에서 데이터를 가져올 수 있어 서비스 자체는 문제x - 대신에 캐시에 붙어있던 connection이 많았다면, redis가 다운된 순간 순간적으로 DB로 몰려서 부하 발생.
Look Aside Cache 패턴은 애플리케이션에서 캐싱을 이용할 때 일반적으로 사용되는 기본적인 캐시 전략.
이 방식은 캐시에 장애가 발생해도 DB에 요청을 전달함으로써 캐시 장애로 인한 서비스 문제는 대비할 수 있지만,
Cache Store와 Data Store(DB)간 정합성 유지 문제가 발생할 수 있고, 초기 조회 시 무조건 Data Store를 호출해야하므로,
단건 호출 빈도가 높은 서비스에 적합하지 않다.
대신 반복적으로 동일 쿼리를 수행하는 서비스에 적합한 아키텍처.
-> 이 경우 DB에서 캐시로 데이터를 미리 넣어주는 작업을 하는데 이걸 Cache Warming이라고 함.
Cache Warming
미리 cache로 db의 데이터를 밀어 넣어두는 작업을 의미.
이 작업을 수행하지 않으면 서비스 초기에 트래픽 급증시 대량의 cache miss가 발생해 DB부하가 급증할 수 있다.(Thundering Herd)
다만, 캐시 자체는 용량이 작아 무한정으로 데이터를 들고 있을 수 없어 일정시간이 지나면 expire 되는데, 그러면 다시 Thundering Herd가 발생될 수 있기 때문에 캐시의 TTL을 잘 조정할 필요가 있다.
-> Thundering Herd는 모든 지점에서 발생하는 것이 아니고, 서비스의 첫 페이지와 같은 대부분의 조회가 몰리는 지점에서 주로 발생.
Read Through 패턴
- 캐시에서만 데이터를 읽어오는 전략(inline cache)
- Look Aside와 비슷하지만 데이터 동기화를 라이브러리 or 캐시 제공자에게 위임하는 방식이라는 차이가 있음.
- 따라서 데이터 조회에 있어 전체적으로 느린 속도.
- 또한 데이터 조회를 전적으로 캐시에만 의지, redis가 다운될 경우 서비스 이용에 차질
- 대신 캐시와 DB간의 데이터 동기화가 항상 이루어져 데이터 정합성 문제에서 벗어날 수 있다.
- 읽기가 많은 워크로드에 적합
이 방식은 직접적인 DB 접근을 최소화, Read에 대한 소모되는 자원을 최소화할 수 있다.
하지만 캐시에 문제가 발생 시, 바로 서비스 전체 중단으로 빠질 수 있다.
그렇기에 redis와 같은 구성요소를 Replication or Cluster로 구성하여 가용성을 높여야한다.
캐시 쓰기 전략(Write Cache Strategy)
Write Back 패턴
- Write Behind 패턴이라고도 함
- 캐시와 DB 동기화를 비동기하기 때문에 동기화 과정 생략
- 데이터를 저장할 때 DB에 바로 쿼리하지 않고, 캐시에 모아서 일정 주기 배치 작업을 통해 DB에 반영
- 캐시에 모아놨다가 DB에 써 쓰기 쿼리 회수 비용과 부하를 줄일 수 있다.
- Write가 빈번하면서 Read를 하는데 많은 양의 Resource가 소모되는 서비스에 적합
- 데이터 정합성 확보
- 자주 사용되지 않는 불필요한 리소스 저장.
- 캐시에서 오류가 발생시 데이터 영구 소실.
-> write Back 방식은 데이터를 저장 시 DB가 아닌 먼저 캐시에 저장해 모아놨다가 특정 시점마다 DB로 쓰는 방식, 캐시가 일종의 Queue 역할을 겸함
캐시에 데이터를 모았다가 한 번에 DB에 저장하기 때문에 DB 쓰기 횟수 비용과 부하를 줄일 수 있지만, 데이터를 옮기기 전에 캐시 장애가 발생하면 데이터 유실이 발생할 수 있다는 다점.
하지만 반대로 DB에 장애가 발생하더라도, 지속적인 서비스를 제공할 수 있다.
