Cache Aside (= Look Aside, Lazy Loading) 전략
데이터를 조회 -> Cache Aside (=Look Aside, Lazy Loading)
redis가 없다면 db에서 가져오겠지만 db를 요청했을때 캐시에 data 있는 지 물어보고 있으면 cache에 물보고 있다면, 사용, 없다면 db에서 조회해 가져오고, 그 후 그 값을 cache에 저장
ex)
서비스 배포 했고, Cache Aside 작동 방식
1. 첫 배포이기 때문에 db와 redis에는 아무런 db 저장 안되어 있음
2. 일부 사용자 작성시, db 저장 (redis에 저장 되지는 않음)
3. 사용자 data 조회 -> db에 조회하기 전 redis에 우선 물어본다.
4. redis에 값이 없으니, db로 부터 조회
5. 조회한 data를 cache에 저장
6. 다시 한번 조회
7. Redis에 값 확인 -> 값 있으면, data 가져와 버림
즉) Cache Aside 전략, cache에 data 있는지 확인, 없다면 DB에서 조회
Write Around 전략
데이터를 어떻게 쓸지(저장, 수정, 삭제 전략)
데이터를 저장 할때는 redis에 저장 X, db에만 저장. data 조회 할때 data 없다면, db로 부터 데이터를 조회해와서 레디스에 저장.
Write Around 전략은 쓰기 작업(저장, 수정, 삭제)을 캐시에는 반영하지 않고, DB에만 반영하는 방식을 뜻한다.
한계점
-
캐시된 데이터와 DB data가 일치하지 않을 수 있다.
Cache Aside와 Write Around를 같이 썼을때 한계점은 캐시된 데이터와 DB data가 일치하지 않을 수 있음. 즉 데이터의 일관성 보장하기 어려움
Write Around 전략 : 데이터를 수정할 때만 DB update, 기존 저장된 redis의 data 값과, db data 값이 다를 수 있음. -
캐시에 저장할 수 있는 공간이 비교적 작다.
DB는 디스크에 저장해서 많은 양을 저장 용이, 캐시는 RAM에 저장하기 때문에 DB에 비해 많은 양의 데이터 저장 할 수 없음
극복 방법
- 캐시된 데이터와 DB data가 일치하지 않을 수 있다.
데이터를 수정 할 때마다 동시에 update?? -> 성능 ISSUE!
DB만 update 하면, 일관성 X
둘중 어떤 방법을 선택하던 간에 trade off는 발생함
데이터 조회 성능 개선 목적으로 레디스를 쓰는 경우에는 데이터의 일관성을 포기하고 성능 향상을 택한 것이다.
캐시를 적용시키기에 적절한 data
1. 자주 조회되는 데이터
2. 잘 변하지 않는 데이터
3. 실시간으로 정확하게 일치하지 않아도 되는 데이터
장기간 일치하지 않는 것은 문제가 될 수 있음. 하지만 주기적으로 동기화.
이때 주로 활용하는 기능이 Redis의 TTL 기능
일정 시간이 지나면 데이터가 캐시에서 삭제
사용자가 조회하는 순간 Cache Miss 발생, DB의 데이터를 조회해 캐시에 데이터를 넣는다. -> 갱신 효과 발생
- 캐시에 저장할 수 있는 공간이 비교적 작다.
TTL 기능(만료 시간 설정 기능)을 활용하면 캐시의 공간을 효율적으로 쓸 수 있다.
Cache Aside, Write Around 전략을 사용할 때 주로 TTL을 같이 활용
