[TIL]20230818 - Redis 캐싱 전략

우리는 프로젝트의 중요한 기능 중 하나인 거래량, 상승률, 하락률 상위 종목을 보여주는 API를 추가하였다.

거래량에 대해서는 오늘기준 하루전의 주식 거래 데이터 중 주식마다 거래량을 누적하여 거래량이 가장 많은 주식의 상위 10개 종목을 응답해주는 API이고

상승률에 대해서는 하루전의 주식거래 데이터 중 가장 처음의 거래내역의 데이터의 가격과 가장 마지막의 거래내역의 데-이터의 가격을 비교하여 상승률을 계산한다. 하락률도 같은 과정을 이용하여 계산한다.

다음과 같은 과정을 거치기 떄문에 DB의 FullScan이 일어난다. 물론 인덱스를 사용하여 시간을 어느정도 줄일 수 있었지만 여전히 어느정도 시간이 소요되어 이를 Redis를 활용하여 해결하기로 하였다.

거래량, 상승률, 하락률 상위 종목 데이터는 오늘 하루동안은 변하지 않는 데이터이기 때문에 API요청시 마다 계산하여 보여줄 필요가 없다고 생각하여 해당 데이터를 캐싱하여 응답시간을 줄이기로하였다.

캐시를 사용하는데에는 여러 전략이 있는데 읽기 전략과 쓰기 전략으로 나누어 볼수 있다.

캐시 읽기 전략

1. Cache Aside 전략

• 데이터를 조회할 때 우선 캐시에 데이터가 저장되어 있는지 확인하고 만약 캐시에 데이터가 없으면 DB에서 조회하는 전략
• 반복적인 읽기가 많은 데이터에 대해 적합하다
• 캐시와 DB가 분리되어 가용되기 때문에 원하는 데이터만 별도로 구정하여 캐시에 저장
• 캐시와 DB가 분리되어 가용되기 때문에 캐시 장애시에도 DB에서 데이터를 가져올 수 있기 때문에 서비스에는 문제가 없다.
• 대신 Redis에 너무 의존적이라면 Redis다운 시 DB로 몰려서 순간적으로 큰 부하가 발생된다.
• 스프링에서 @Cachable 사용시 이 전략을 사용한다.

위 전략의 경우 DB에서 캐시로 데이터를 미리 넣어주는 작업을 하기도 하는데 이를 Cache Warming이라한다.

CacheWarming작업을 통해 서비스 초기에 트래픽 급증시 대량의 cache miss가 발생하여 DB 부하가 급증하는것을 방지할 수 있다. 하지만 캐시 특성상 용량이 작기 때문에 유효기간을 잘 조정하여 저장하여야 한다.

2. Read Through

• 캐시에서만 데이터를 읽어오는 전략
• Cache Aside전략과 비슷하지만 데이터 동기화를 라이브러리 또는 캐시 제공자에게 위임하는 방식이다.
• 따라서 데이터를 조회하는데 있어 전제적으로 속도가 느리다.
• 데이터 조회를 전적으로 캐시에 의존하므로 Redis가 다운될 경우 서비스 이용에 차질이 생긴다.
• 대신 캐시와 DB간 데이터 동기화가 이루어져 데이터 정합성 문제에서는 자유롭다.

캐시 쓰기 전략

1. Write Back

• 캐시와 DB 동기화를 비동기하기 때문에 동기화 과정이 생략된다.
• 데이터를 저장하려할 때 DB에 바로 쿼리를 날리지 않고 캐시에 모아서 일정 주기 배치 작업을 통해 DB에 반영
• 캐시에 모아놨다가 DB에 쓰기 때문에 쓰기 쿼리 회수 비용과 부하를 줄일 수 있음
• Write가 빈번하면서 READ하는데 많은 양의 Resource가 소모되는 서비스에 적합
• 데이터 정합성 확보 가능
• 자주 사용되지 않는 불필요한 리소스가 저장된다.
• 캐시에서 오류가 발생하면 데이터를 영구 소실한다.

2. Write Through 

• 데이터베이스와 캐시에 동시에 데이터를 저장하는 전략
• 데이터를 저장할 때 먼저 캐시에 저장한 다음 바로 DB에 저장
• READ Through와 마찬가지로 DB동기화 작업을 캐시에 위임
• DB와 캐시가 항상 동기화되어 있어 캐시의 데이터를 항상 최신상태로 유지가능
• 데이터 유실이 발생하면 안되는 상황에 적합
• 자주 사용되지 않는 불필요한 리소스 저장
• 매 요청마다 두번의 Write가 발생하게 됨으로써 빈번한 생성, 수정이 발생하는 서비스에서는 성능 이슈 발생

Write Back전략과 Write Through전략 둘다 모두 자주 사용되지 않는 데이터가 저장되어 리소스 낭비가 발생되는 문제점을 안고있기 때문에 이를 해결하기 위해 TTL을 사용하여 사용되지 않는 데이터를 반드시 삭제해야한다.

3. Write Around

• 모든 데이터를 DB에 저장 (캐시를 갱신하지 않음)
• Cache Miss가 발생하는 경우에만 DB와 캐시에도 데이터를 저장
• 따라서 캐시와 DB내의 데이터가 다를 수 있다.
• Write Around전략은 속도가 빠르지만 데이터 불일치가 발생한다.