Important Study - Redis Cache & Update Strategy

Look Aside ( Cache Aside ) 패턴
- 우선 캐시에서 검색
  - 있으면 클라이언트에 바로 반환
  - 없으면 DB에서 조회 –> 조회 후 Redis에 캐싱하고 클라이언트에 반환
- 반복적인 읽기가 많은 호출에 적합
- 단 건 호출에는 적합하지 않음.
- 캐시와 DB가 분리되어 가용되기 때문에 원하는 데이터만 별도로 구성하여 캐시에 저장
- 캐시와 DB가 분리되어 가용되기 때문에 캐시 장애 대비 구성이 되어있음.
- 만일 redis가 다운 되더라도 DB에서 데이터를 가져올수 있어 서비스 자체는 문제가 없음.
- 대신에 캐시에 붙어있던 connection이 많았다면, redis가 다운된 순간 순간적으로 DB로 몰려서 부하 발생하는 단점이 있음.
- DB 갱신이 일어나면, 그 때 캐싱에서 지움.
- 조회전에 미리 캐시로 데이터를 밀어넣어주는 작업도 있는데, 그걸 Cache Warming 이라고 함.

Read Through 패턴
- 캐시에서만 데이터를 읽어오는 전략
- 데이터 동기화를 라이브러리 또는 캐시 제공자에게 위임하는 방식이므로 전체적으로 속도가 느림
- redis 다운 시 서비스 이용에 차질이 생김.
- 데이터 정합성 문제가 안생김. ( DB간의 데이터 동기화가 항상 이루어지는 패턴 )
- 읽기가 많을 경우 적합
- 초반에 cache warming 을 하는게 좋다.

Write Back 패턴
- 캐시와 DB 동기화를 비동기하기 때문에 동기화 과정이 생략
- 데이터를 저장할때 DB에 바로 쿼리하지않고, 캐시에 모아서 일정 주기 배치 작업을 통해 DB에 반영
- 캐시에 모아놨다가 DB에 쓰기 때문에 쓰기 쿼리 회수 비용과 부하를 줄일 수 있음
- Write가 빈번하면서 Read를 하는데 많은 양의 Resource가 소모되는 서비스에 적합
- 자주 사용되지 않는 불필요한 리소스 저장.
- 캐시에서 오류가 발생하면 데이터를 영구 소실함.
- 예를들면,
  - 조회수 갱신에 좋음. ( 굳이 정합성이 필요없는데, 정말 많이 쓰는 경우이므로 )
  - REPEATABLE READ 격리 수준일 때 Update 문은 자동적으로 업데이트락이 걸리기 때문에, 해당 게시글을 가져오거나 수정하는데에 있어서 속도 문제가 발생할 수 있음. ( Lock 획득을 기다려야 하기 때문에 )

Write Through 패턴
- DB와 캐시에 동시 저장하는 전략
- 데이터를 저장할 때 먼저 캐시에 저장한 다음 바로 DB에 저장 (모아놓았다가 나중에 저장이 아닌 바로 저장)
- Read Through 와 마찬가지로 DB 동기화 작업을 캐시에게 위임
- DB와 캐시가 항상 동기화 되어 있어, 캐시의 데이터는 항상 최신 상태로 유지
- 캐시와 백업 저장소에 업데이트를 같이 하여 데이터 일관성을 유지할 수 있어서 안정적
- 데이터 유실이 발생하면 안 되는 상황에 적합
- 자주 사용되지 않는 불필요한 리소스 저장.
- 매 요청마다 두번의 Write가 발생하게 됨으로써 빈번한 생성, 수정이 발생하는 서비스에서는 성능 이슈 발생
- 기억장치 속도가 느릴 경우, 데이터를 기록할 때 CPU가 대기하는 시간이 필요하기 때문에 성능 감소

Write Around 패턴
- Write Through 보다 훨씬 빠름
- 모든 데이터는 DB에 저장 (캐시를 갱신하지 않음)
- Cache miss가 발생하는 경우에만, DB와 함께 캐시에도 데이터를 저장
- 따라서 캐시와 DB 내의 데이터가 다를 수 있음 (데이터 불일치)

Read Through + Write Around
- 항상 DB에 쓰고, 캐시에서 읽을 때에도 항상 DB에서 먼저 읽어오므로, 데이터 정합성 이슈에 안전 장치를 구성할 수 있다.

Read Through + Write Through
- 데이터를 쓸 때 캐시에 먼저 쓰므로, 읽어올 떄 최신 캐시 데이터 보장
- 데이터를 쓸 때 항상 캐시에서 DB로 보내므로, 데이터 정합성도 보장

results matching ""