Redis는 캐시를 사용한다.
하지만 모든 데이터를 캐시(Redis)에 저장할려면 용량 부족이 일어난다!
또한 한 개의 DB만을 사용하면 데이터 정합성에 문제가 발생하지 않지만
Redis를 사용하게 되면 같은 종류의 데이터라도 다른 값을 가지고 있어 정합성 문제가 발생한다.
그래서 캐시 읽기 전략과 캐시 쓰기 전략을 통해 캐시와 DB간의 데이터 불일치 문제를 극복하면서도 빠른 성능을 잃지 않아야한다 !!!!
캐싱 전략 패턴 종류
캐시 읽기 전략
Look Aside 패턴
: 데이터를 찾을 때 우선 캐시에 저장된 데이터가 있는지 우선적으로 확인하는 전략
장점
- 반복적인 읽기가 많은 호출에 적합
단점
- 정합성 유지 문제가 발생할 수 있음
- 초기 조회 시 무조건 Data Store를 호출 해야 하므로 단건 호출 빈도가 높은 서비스에 적합하지 않다.
DB에서 캐시로 데이터를 미리 넣어주는 Cache Warming 작업을 하기도 한다
Read Through 패턴
: 캐시에서만 데이터를 읽어오는 전략
장점
- 캐시와 DB간의 데이터 동기화가 항상 이루어져 데이터 정합성 문제에서 벗어남
단점
- 데이터를 조회하는데 있어 전체적으로 속도가 느리다
Cache Store에 저장하는 주체가 Server이냐 혹은 Data Store 자체이냐에서 차이점이 있다.
문제를 대비하여 Replication 또는 Cluster로 구성하여 가용성을 높인다
캐시 쓰기 전략
Write Back 패턴
: 데이터를 저장할 때 DB에 바로 쿼리하지 않고, 캐시에 모아서 일정 주기 배치 작업을 통해 DB에 반영
장점
- Write가 빈번하면서 Read를 하는데 많은 양의 Resource가 소모되는 서비스에 적합
- 데이터 정합성 확보
단점
- 자주 사용되지 않는 불필요한 리소스 저장
데이터를 옮기기 전에 캐시 장애가 발생하면 데이터 유실이 발생할 수 있다는 단점이 존재한다. 하지만 오히려 데이터베이스에 장애가 발생하더라도 지속적인 서비스를 제공할 수 있도록 보장하기도 한다.
Write Through
: 데이터베이스와 Cache 동시에 데이터를 저장하는 전략
먼저 캐시에 저장한 다음 바로 DB에 저장
장점
- 데이터 일관성 유지 가능
- 데이터 유실이 발생하면 안 되는 상황에 적합
단점
- 매 요청마다 두 번의 Write가 발생하게 됨으로써 빈번한 생성, 수정이 발생하는 서비스에서는 성능 이슈 발생
Write throuth 패턴과 write back 패턴 둘 다 모두 자주 사용되지 않는 데이터가 저장되어 리소스 낭비가 발생되는 문제점이 있다. 이를 해결하기 위해 TTL을 사용하여 사용되지 않는 데이터를 삭제한다.
Write Around 패턴
: 모든 데이터를 DB에 저장 (캐시를 갱신하지 않음)
장점
- Write Through 보다 빠름
단점
- Cache miss가 발생하는 경우에만 DB와 캐시에도 데이터를 저장하여 DB와 캐시내의 데이터 불일치가 발생하게 된다.
데이터가 한 번 쓰여지고, 덜 자주 읽히거나 읽지 않는 상황에서 좋은 성능을 제공한다.
캐시 읽기 + 쓰기 전략 조합
Look Aside + Write Around 조합
: 가장 일반적으로 자주 쓰이는 조합
Read Through + Write Around 조합
: 항상 DB에 쓰고, 캐시에서 읽을 때 항상 DB에서 먼저 읽어오므로 데이터 정합성 이슈에 대한 완벽한 안전 장치를 구성할 수 있음
Read Through + Write Through 조합
데이터를 쓸 때 항상 캐시에 먼저 쓰므로, 읽어올 때 최신 캐시 데이터 보장
데이터를 쓸 때 항상 캐시에서 DB로 보내므로, 데이터 정합성 보장
