우리가 Redis를 많이 활용하는 이유 중 하나는 '캐싱' 때문이다.
1. Cache
캐시는 원래 CPU 내부의 작은 영역으로, 엄청 자주 접근하게 되는 데이터를 저장해두는 임시 기억 장치이다
기본적으로는 영속성을 위해서 데이터를 파일시스템(디스크)에 저장하고,
빠른 활용이 필요한 데이터는 RAM에 저장한다면,
ㅈㄴ많이 사용되는 휘발성 데이터는 캐시에 저장된다고 보면 된다.
참고로 위의 그림은 우리같은 개발자가 다루는 캐시 전략이 아니다.
하드웨어를 일부 보여준 것이다.
하지만, 이러한 캐시에 착안하여
웹 개발에 적용하면, 빈번하게 접근하게 되는 데이터베이스의 데이터를
레디스 등의 인메모리 데이터베이스에 저장을 함으로써
데이터를 조회하는데 걸리는 시간과 자원을 감소시키는 기술로서 캐싱 전략을 사용할 수 있다.
2. 캐싱 전략
기본적으로 캐시는 본래 저장된 곳이 아닌 다른곳에 데이터를 저장합니다
언제든지 사라질 수 있는 데이터가 들어가는 장소이지요
캐싱전략을 소개하기 전에 용어들을 정리하겠습니다.
캐시 적중 (Cache Hit) : 캐시에 접근했을 때 찾고 있는 데이터가 있는 경우
캐시 누락 (Cache Miss) : 캐시에 접근했을 때 찾고 있는 데이터가 없는 경우
삭제 정책(Eviction Policy) : 캐시의 공간이 부족하거나 기존 데이터를 삭제해야 할 때,
어떤 방식으로 공간을 확보할지를 결정하는 정책을 말한다.
어떤 데이터를 얼마나 오래 캐시에 보관할지에 대한 전략을 잘 새워,
적중률을 높이고 누락을 최대한 줄여야 한다.
1) Cache-Aside
Lazy Loading이라고도 하는데,
데이터를 조회할때 항상 캐시를 먼저 조회하는 전략이다.
캐시에 데이터가 있으면 캐시된 데이터를 들고오고
없으면 DB에서 데이터를 가져온 뒤에 캐시에 저장한다.
이 전략은 많이 사용되는 편이다.
하지만, 반드시 원본을 확인하지 않기 때문에 데이터가 최신이라는 보장이 없다는 단점이 있다.
2) Write-Through
데이터를 작성할때 항상 캐시에 작성하고, 원본에도 작성하는 전략이다.
캐시의 데이터는 항상 최신이다.
하지만, 자주 사용하지 않는 데이터도 캐시에 중복해서 작성하기 때문에,
시간이 오래걸린다.
3) Write-Behind
캐시에만 데이터를 작성하고, 일정 주기로 원본을 갱신하는 방식이다.
쓰기가 많이 일어나는 상황에서 데이터베이스의 부하를 줄일 수 있다.
캐시의 데이터가 DB에 적용되기 전에 문제가 발생하면 데이터 소실의 위험이 존재한다.
'CS > 데이터베이스' 카테고리의 다른 글
벌크 연산으로 쿼리 튜닝하기 (0) | 2025.04.25 |
---|---|
댓글 대댓글 DB 설계하기 (0) | 2025.04.05 |
DB를 선택하는 기준 (0) | 2025.04.05 |
HttpSession과 Session Clustering (with Redis) (2) | 2025.03.06 |
프로젝트에 Redis를 도입하는 근본적인 이유 (feat. 기술 면접) (0) | 2025.03.05 |