Redis의 Read Through 과 Write back 패턴을 활용하여 상품 랭킹 구현

배상규·2024년 5월 3일

개인 프로젝트로 진행하는 쇼핑몰 프로젝트에서 상품 랭킹 서비스 구현을 Redis의 Read Through + Write back 패턴을 활용하여 구현한 내용을 정리 해보자 📒

🧐기존 랭킹 구현 상태를 살펴보자

현재 프로젝트에서 사용자가 상품 조회요청을 보내면 Product-service에서 Rank-Service로 조회요청에 대한 이벤트를 발행하고 이를 Rank-service 쪽에서 Consume하여 조회수를 증가 시키고 있습니다!

🤷‍♂️ 대표적인 읽기 전략

Redis의 대표적인 읽기 전략
1. Look Aside 패턴
2. Read Through 패턴

Look Aside 패턴

반복적인 읽기가 많은 호출에 적합
캐시와 DB가 분리되어 가용 원하는 데이터만 구성하여 캐시에 저장
캐시와 DB가 분리되어 가용되기에 캐시 장애 대비 구성이 되어있다.
Redis 다운시 DB에서 데이터를 읽어 사용
Redis 다운시 DB에 부하 발생

Read Through 패턴

캐시에서만 읽어오는 전략
Look Aside와 비슷하지만 데이터 동기화를 라이브러리 또는 캐시 제공자에게 위임하는 방식이라는 차이
데이터 조회속도가 느림
데이터 조회를 캐시에 의지하기에, redis 다운시 서비스에 치명적일 수 있음.
캐시와 DB간의 데이터 동기화가 항상 이루어져 데이터 정합성 문제에서 벗어 날 수 있음

🤷‍♂️ Redis의 대표적인 쓰기 전략

Redis의 대표적인 쓰기 전략
1. Write Back 패턴
2. Write Through 패턴
3. Write Around 패턴

Write Back 패턴

캐시와 DB 동기화를 비동기로 하기 때문에 동기화 과정이 생략
데이터를 저장할때 DB로 바로 쿼리하지 않으며, 일정 주기 배치 작업을 통해 DB 반영
캐시에 모아 놨다가 DB에 쓰기 때문에 부하를 줄일 수 있다
Wirte가 빈번하고 Read를 하는데 많은 양의 Resource가 소모되는 서비스에 적합
캐시에서 오류가 발생하면 데이터를 영구 소실함

Write Through 패턴

DB, Cach 동시에 데이터를 저장하는 전략
데이터를 저장할때 캐시에 저장한 뒤 DB에 저장 (모아두는 방식이 아님)
DB와 캐시 항상 동기화되어 캐시는 항상 최신의 상태로 유지
데이터 일관성을 유지할 수 있다
데이터 유실이 발생하면 안 되는 상황에 적합
자주 사용되지 않은 불필요한 리소스를 저장
매 요청 마다 Write를 두번 발생시키기에 빈번한 생성, 수정의 경우 성능 이슈가 발생

Write Around 패턴

Write Though 보다 빠름
모든 데이터는 DB에 저장 (캐시를 저장하지 않음)

🤷‍♂️ 왜 랭킹 구현에 Write back + Read Through 패턴이 왜 적합 할까?

읽기 전략

1. DB 접근의 최소화
현재 쇼핑몰의 메인 페이지에서, 상단 헤더 부분에 상품 랭킹에 대한 정보 들을 계속 보여줄 예정이다, 그렇다면 트래픽이 상승할 경우 랭킹 DB에 대한 접근이 많아질 것이고, 이때 부하를 일으킬 것을 가정하였다

2. Cluster 구성
일단 Read Through 패턴은 Redis에게 데이터 동기화를 위임하기 때문에 Redis단일로 사용하게 된다면 Redis가 장애를 일으킨다면 상당히 치명적일 수 있다. 하지만 현재 프로젝트에서 Redis Cluster를 구성하여 사용할 것이 판단하여 Redis 장애에 대한 가용성을 높일 수 있을거라 생각되었다

쓰기 전략

1. DB 접근의 최소화
현재 kafka를 통해 상품 클릭시 product-service에서 이벤트를 발행하고 rank-service에서 이를 consume 하여 사용중이다 이때 많은 사용자가 있으며, 상품클릭에 대한 트래픽이 높다고 가정하고있다, 그렇기 때문에 이벤트 consume시 DB에 직접 write를 한다면 DB에 부하가 가해질 것으로 가정하였고, 이를 해결하기 위해 write-back 패턴을 도입 구체적으로 배치 작업 + jdbc bulk insert를 통해 쓰기작업을 이용하여 DB에 부하를 줄일 수 있을것으로 생각 되었다.