[redis] 캐싱 개념과 전략

캐싱과 캐싱의 필요성

Redis가 많이 활용되는 주제는 캐싱(Caching)이다. 이는 자주 사용되는 데이터를 더 빠른 캐시(Cache)에 저장하는 기법을 부르는 용어이다.

 

캐시란?

Cache는 본래 CPU 내부의 작은 영역으로, 정말 빈번히 접근하게 되는 데이터를 저장해두는 임시 기억 장치입니다. 기본적으로 영속성을 위해 파일시스템(디스크)에 저장하고, 빠른 활용을 위해 메모리(RAM)에 저장한다면, 정말 많이 사용되는 휘발성 데이터가 캐시에 저장됩니다.

빈번하게 접근하게 되는 데이터베이스의 데이터를 Redis 등의 인메모리 데이터베이스에 저장을 함으로서 데이터를 조회하는데 걸리는 시간과 자원을 감소시키는 기술을 캐싱이라고 합니다.

웹 브라우저에서는 자주 바뀌지 않는 이미지 등을 브라우저 캐시에 저장해 페이지 로드를 줄이는 것도 캐싱의 일종이며, 이는 RESTful 설계 원칙 중에서 응답이 캐싱이 가능한지 명시해야 한다는 제약사항으로도 나타납니다.

 

캐싱 전략

시는 본래 저장된 곳이 아닌 다른곳에 데이터를 저장하는 행위이며, 언제든 사라질 수 있는 데이터가 있는 곳이며, 너무 크지 않게 관리 되어야 합니다. 그리고 캐시를 확인했을때 자신이 필요한 데이터가 있을 수도, 없을 수도 있다는 것을 고려해야 합니다. 그래서 캐시를 구현하고 사용할때는 해당 데이터가 얼마나 자주 사용될 것인가를 고려해야 합니다.

• 캐시 적중 (Cache Hit) : 캐시에 접근했을 때 찾고 있는 데이터가 있는 경우 나타냅니다.
• 캐시 누락 (Cache Miss) : 캐시에 접근했을 때 찾고 있는 데이터가 없는 경우를 나타냅니다.
• 삭제 정책 (Eviction Policy) : 캐시에 공간이 부족할 때 어떻게 공간을 확보하는지에 대한 정책입니다.

캐시에 찾는 데이터가 있을지 없을지는 캐시에 접근하기 전까지는 알기 어렵습니다. 그래서 어떤 데이터를 얼마나 오래 캐시에 보관할지에 대한 전략을 잘 새워, 적중률을 높이고 누락을 최대한 줄여야 합니다.

 

Cache-Aside

Lazy Loading이라고도 하며, 데이터를 조회할 때 항상 캐시를 먼저 확인하는 전략이다. 캐시에 데이터가 있으면 캐시에서 데이터를, 없으면 원본에서 데이터를 가져온 뒤 캐시에 저장한다.

• 필요한 데이터만 캐시에 보관한다.
• 최초로 조회할 때 캐시를 확인하기 때문에 최초의 요청은 상대적으로 오래걸린다.
• 반드시 원본을 확인하지 않기 때문에, 데이터가 최신이라는 보장이 없다.

 

Write-Through

데이터를 작성할 때 항상 캐시에 작성하고, 원본에도 작성하는 전략

• 캐시의 데이터 상태는 항상 최신 데이터임이 보장된다.
• 자주 사용하지 않는 데이터도 캐시에 중복해서 작성하기 때문에 시간이 오래걸린다.

 

Write-Behid

캐시에만 데이터를 작성하고, 일정 주기로 원본을 갱신하는 방식이다.

• 쓰기가 잦은 상황에 데이터베이스의 부하를 줄일 수 있다.
• 캐시의 데이터가 원본에 적용되기 전 문제가 발생하면 데이터 소실의 위험성이 존재한다.