❓Cache란?
: 데이터 값을 저장하는 임시 저장소로, 데이터를 더 빠르고 효율적으로 액세스 가능하게 해준다.
(redis의 경우 in-memory 캐시로 memory위치에 저장 된다고 보면 된다.)
(disk가 아닌 memory에 → external, disk cache)
Redis 사용 시
⇒ 웹서버의 부담을 획기적으로 줄여주며, 사용자들에게는 훨씬 더 빠르게 데이터 공급 가능
❓캐싱전략
? : 상황에 맞게 적절한 전략 사용해야 한다!
- 얼마나 자주 작성되고, 읽히는가
- 데이터 유형, 액세스 패턴 등..
5가지 캐싱 전략을 알아보도록 하겠다.
- Look-Aside 읽기 전략(Lazy Loading)
- Read-Through 읽기 전략
- Write-Around 쓰기 전략
- Write-Through 쓰기 전략
- Write-Back 쓰기 전략
📖Look-Aside 읽기 전략(Lazy Loading)
- Redis 캐싱에서 가장 일반적인 전략으로, 읽기 요청이 많은 경우 적합
- 찾는 데이터가 없을 때 DB에 직접 조회해서 입력
- redis 다운 되어도 바로 장애로 이어지지 않음
- if) 캐시에 많은 connection이 붙어 있는 상태에서 다운 발생시, 동시에 db로 그 connection 다 붙어서 db부하 몰릴 수도 있음
- lazy loading사용시 가장 일반적인 쓰기 전략은 write-around
- 이 경우 캐시와 db의 데이터가 일치하지 않을 수도
- Sol : TTL(만료될 때까지 변경되지 않은 캐시 데이터 제공)
- 데이터 최신성 보장해야 하는 경우 더 적절한 쓰기 전략 이용하는게 좋을 수도!
📖Read-Through 읽기 전략
- 캐시로만 데이터를 읽어 옴(디스크 읽기 비용 절약)
→ 동일한 데이터가 여러 번 읽기 요청이 되는 경우 적합- Cache miss 발생시 db에서 해당 데이터를 캐시에 바로 저장
- 항상 첫 요청은 cache miss
- Look-Aside의 경우 Cache Miss가 나면 앱이 직접 db에 데이터 조회,
Read-Through의 경우 캐시에서 db에 데이터를 직접 조회, 로드
- Read-Through는 캐시 데이터 모델 = dB 데이터 모델
# > Cache Warming(미리 데이터를 캐싱)(miss로인한 성능 저하 방지!)
Lazy Loading에서 캐시가 다운 된 상황이나, Read-Through 초기 상황처럼 Cache Miss가 많이 발생 하는 상황이 오면
성능 저하 일어날 수 있음
⇒ **미리 캐시로 데이터를 넣어주는 Cache Warming 작업**으로 조취!
📖Write-Through 쓰기 전략
- Read-Through와 같이 db에 데이터 저장시 먼저 캐시에 기록된 다음 db에 저장
- 캐시는 항상 최신 정보 갖고 있고, db와 동기화 되어 데이터 일관성 보장
- 저장할 때 마다 (앱→Redis→DB)을 거쳐야 함 ⇒ 추가 쓰기 시간 발생(상대적 느림)
- 저장하는 데이터를 재사용하지 않을 수 있는데 무조건 캐시에 넣는 것은 리소스 낭비
⇒ TTL 설정해 얼마동안 캐시에 데이터 보관할지 설정해 주면 좋음
💡 Read-Through와 함께 사용시 디스크 읽기 비용 절약이 가능하고, 데이터 일관성도 보장되어 캐시 무효화 기술을 사용하지
않아도 됨
⇒ ex) **AWS의 DynamoDB Accelerator(DAX)**
📖Write-Around 쓰기 전략
- DB에만 데이터를 저장하고, 읽은 데이터만 캐시에 저장하는 방식
- 모든 데이터는 db에 저장, cache miss인 경우에만 db에서 캐시로
- 자주 읽히지 않는 데이터는 캐시에 로드 되지 않음 → 리소스 절약
- 캐시에 이미 로드 된 데이터를 db에서 수정하면, 캐시 내의 데이터와 db내의 데이터가 다를 수도
- 데이터가 한 번 쓰여지고, 덜 자주 읽히는 상황에 좋음
- 실시간 로그
- 채팅방 메시지
💡 ex) 실시간 로그를 기록하는 시스템에서 Read-Through / Write-Through 전략을 사용한다면자주 읽지도 않는 데이터가
캐시에 적재되기 때문에 리소스 낭비가 발생하게 된다.
이러한 경우에는 Read-Through / Write-Around 전략을 사용하는 게 적합하다.
📖Write-Back 쓰기 전략
- 쓰기 작업을 캐시에 먼저 저장했다가, 특정 시점에 db에 한 번에 저장
- db에 저장된 데이터는 캐시에서 삭제
- 무조건 디스크에 저장해야 하는 상황에서 주로 사용
- 매번 디스크 쓰기를 실행하면 오래 걸리니까..
- 쓰기가 많은 경우 적합하고, 특정 시점에만 쓰기 요청하기 때문에 db 오류에도 탄력적
- 하지만, 한 번에 캐시에서 db로 옮기니까 도중에 캐시에 장애 발생 시 데이터 유실 정도가 클 수 있다
- 대부분의 RDB 스토리지 엔진 내부에 갖춘 기능
- 쿼리는 먼저 메모리에 기록되다가 특정 시점에 한 번에 disk에 flush
💡 Write-Back은 Read-Through와 결합하면 가장 최근 업데이트되고, 액세스 된 데이터를 항상 캐시에서 사용 가능참고
https://loosie.tistory.com/800
https://meetup.toast.com/posts/225
https://inpa.tistory.com/entry/REDIS-📚-캐시Cache-설계-전략-지침-총정리#LookAside+Write_Around조합
