Redis 캐시 전략
캐싱 전략은 웹 서비스 환경에서 빠른 성능과 만족도를 사용자에게 전달할 수 있습니다.
장점을 극대화학 위해 몇가지의 전략들이 존재합니다. 곧 설명드릴 전략을 활용하여 Redis를 다양한 상황에서 사용할 수 있습니다.
하지만 기본적으로 RAN 용량은 크지 않습니다. 그래서 적절하지 못한 데이터를 모두 캐시에 저장하게 되면 용량 부족으로 인해 서비스 전체에 영향을 주기에 시스템 다운까지 될 수 있습니다.
그래서 데이터 선별, 데이터 용량, TTL 설정 등을 이용해 효율적으로 캐시를 사용해야 합니다.
캐시에 저장할 적절한 데이터 예시
보통 자주 조회되는 데이터, 결과값이 자주 변경되지 않고 일정한 데이터, 조회 후 연산이 필요한 데이터를 개싱하면 좋습니다.
캐시 용어
Cahce hit
캐시에 데이터가 있을 경우 데이터를 캐시에서 바로 가져오는 경우 -> 속도가 빠름
Cache miss
캐시에 데이터가 없는 경우 DB에서 데이터를 가져오는 경우 -> 속도가 느림
캐시 전략
캐시 전략에는 크게 Read Cache Strategy, Write Cache Strategy가 존재한다.
캐시 전략을 선택할때는 캐시와 DB와의 데이터 정합성 문제가 발생하지 않도록 적절한 캐시 전략을 선정하는 것이 중요하다.
Cache Aside Pattern(Look Aside Pattern)
- Look Aside Pattern 혹은 Cache Aside Pattern 이라고 부른다.
- 해당 전략을 Cache에 먼저 데이터를 질의 하는 전략.
- 만약 Cache에 데이터가 없다면 DB에서 데이터를 조회하게된다.
- 해당 전략은 반복적인 읽기가 많은 상황에 적합하여 읽기 성능을 향상시켜준다.
- 하지만, 캐시에 장애가 발생하게 된다면 다수의 요청이 순간적으로 DB로 몰리게 되고 서비스 전체에 영향을 미칠 수 있다.
- Cache Aside Pattern 전략으로 설계하게 될 경우, 애플리케이션 처음 실행될 때 초기 데이터를 캐시 저장소에 미리 넣어 두는 것도 좋은 방법입니다. 이를 Cache Warming이라고 한다.
Cache Warming
미리 Cache에 DB 데이터를 밀어 넣는 작업을 말합니다.
많은 트래픽이 예상되는 이벤트가 시작되기 이전에 미리 데이터를 Cache에 밀어 넣는 작업을 할 수 있습니다.Cache Warming을 진행하지 않는다면 cache miss(1차 Read)가 발생하고, DB read(2차 Read)가 발생하여 부하가 발생할 수 있습니다.
다만, 보통 캐시에는 TTL을 설정하기에 TTL이 만료되었을 때의 트래픽 부하도 고려해야 합니다.
아래 링크에 좋은 팁이 있기에 참고하면 좋습니다.
Write Back Pattern
- write 작업이 발생하면 Cache에 먼저 작업을 진행한 후 다 수의 write 연산이 모이게되면 DB에 저장하는 전략을 말한다.
- 캐시에 작업을 모아놨다가 DB에 쓰기 작업을 진행하기에 DB에 바로 쓰기 작업을 하는 것보다 부하를 줄일 수 있다.
- Write 작업이 빈번하면서 Read 작업을 하는데 많은 리소스가 소모되는 서비스에 적합하다.
- 하지만, 캐시 가용성 설정에 따라서 캐시에 있는 데이터가 유실될 수 있습니다.
- 또한 복잡한 데이터 즉, 여러 테이블을 join 해서 도출해야 하는 데이터의 경우에는 데이터 불일치가 발생할 수 있기에 write-back 전략에 적용하기 어려울 수 있습니다.
Write Back 가용성
해당 전략에서는 Replication 이나 Cluster 구조를 적용하여 Cache 서비스의 고가용성을 확보하는 것이 좋다.
Write Through Pattern
- Write Through Pattern은 DB와 Cache에 동시에 데이터를 저장하는 전략이다.
- DB와 Cache가 항상 동기화 되어 있기에 캐시의 데이터는 항상 최신의 상태로 유지할 수 있다.
- 하지만, 매 요청마다 두 번의 Write가 발생(DB, Cache) 하기에 빈번한 생성, 수정이 발생하는 서비스에 해당 전략을 적용하면 성능 이슈가 발생할 수 있다.
Cache Aside Pattern과 유사한 전략
- 위 전략은 두 단계의 구조화된 캐시를 이용하는 전략이다.
- 실제 사용은 Cache Aside Pattern과 유사한 전략이다.(Cache Aside Pattern + Write Around Pattern 을 섞은 느낌..?)
- 예를 들어 이커머스 전 상품의 데이터를 분산 캐시인 Redis에 저장하도록 하고, 이를 각 Application에서는 분산 캐시에서 데이터를 가져와 자신의 Local Cache에 적재하여 활용할 수 있다. 이를 통해 높은 응답속도를 보장할 수 있게된다.
- 만약 데이터 수정이 발생하게 된다면 1차 캐시라고 할 수 있는 분산 캐시에 먼저 반영되어야 한다.
참고
https://brunch.co.kr/@springboot/151
https://blog.awesomesoftwareengineer.com/p/cache-strategies
https://velog.io/@inhwa1025/Redis-Cache-Strategy-Pattern
