백엔드 캐싱
백엔드 캐싱
자주 접근하는 데이터를 더 빨리 접근 가능한 위치에 저장한다. 요청마다 DB에서 데이터를 다시 계산하거나 검색할 필요 없이 캐시에서 데이터를 빠르게 데이터를 제공할 수 있다.
캐싱의 4가지 전략
- Read Through : 애플리케이션이 데이터를 읽을 때 먼저 캐시를 조회하고, 캐시에 데이터가 없을 경우 DB에서 가져온 후 캐시에 저장. 이후 동일한 요청이 들어오면 캐시에서 즉시 반환
- Write Through : 애플리케이션이 데이터를 변경할 때 먼저 캐시에 쓰고, 동시에 DB에 데이터를 갱신한다. 데이터 일관성이 중요하고 변경 빈도가 낮은 데이터에 적합하다.
- Write Behind(Write Back) : 데이터를 변경할 때 먼저 캐시에 저장하고, DB에는 일정 시간 뒤에 비동기적으로 쓰는 방식이다. 이로 인해 DB에 대한 쓰기 부하가 줄어들지만, 캐시와 DB의 일시적 불일치가 발생할 수 있다. 쓰기 작접이 빈번하지만 즉각적인 일관성이 중요하지 않은 로그데이터에 적합하다.
- Cache Aside: 애플리케이션이 직접 캐시를 관리하는 방식으로, 먼저 캐시를 조회하고 데이터가 없을 경우 DB에서 데이터를 가져와 캐시에 저장하는 패턴이다. 데이터 변경시에도 애플리케이션이 캐시 무효화를 직접 처리한다. 캐시 갱신 정책을 애플리케이션이 세밀하게 제어해야 할 때 사용된다. 예를 들면 사용자별 맞춤 데이터를 캐시에 저장할 때 적합하다.
캐시 스탬피드 현상
캐시가 만료되거나 초기화될 때 여러 클라이언트가 동시에 동일한 데이터를 요청하면서 대량의 요청이 한꺼번에 데이터베이스로 몰리는 현상.
이로 인해 서버가 과부하에 걸리거나 DB에 성능이 크게 저하될 수 있음.
- Locking : 캐시에 데이터가 없을 경우 첫 번째 요청만이 DB에 접근하도록 잠금을 설정하고 나머지 요청은 대기
- ~~Lazy Expiration: 캐시가 만료될 때, 요청을 처리하면서 비동기적으로 캐시를 갱신한다.~~
- Randomized TTL : 데이터마다 만료시간을 랜덤하게 설정하여 동일 시간에 캐시가 대거 만료되는 것을 방지한다.redis
Redis는 오픈소스 인메모리 데이터 구조 저장소이다. 캐싱 뿐만 아니라 세션 관리, 실시간 분석, 메세지 큐 등 다양하게 활용할 수 있다.
Memcached
오픈 분산 메모리 캐싱 시스템이다. RAM에 데이터를 저장한다. 읽기 작업이 많은 애플리케이션에 이상적이다. 하지만 RAM에만 데이터를 저장하기 때문에 영구적이지 않다. 따라서 데이터 손실이 용납될 수 없는 경우 Redis와 같은 영구적인 솔루션이 더 선호된다.
CDN
정적 콘텐츠를 전 세계의 여러 서버에 캐싱하여 사용자가 가장 가까운 서버에서 콘텐츠에 엑세스할 수 있도록 보장한다. 이를 통해 서버 부하가 줄어들고, 대역폭 비용이 낮아지며 페이지 로딩 속도가 크게 향상된다.
캐싱의 단점
캐싱 시스템의 주요 단점 중 하나는 데이터 불일치 문제이다. 캐시된 데이터가 최신이 아닐 수 있으며, 이로 인해 사용자에게 오래되거나 잘못된 정보가 제공될 수 있다.
성장중