캐시(Cache) 란?
캐시(Cache)는 자주 사용하는 데이터나 값을 미리 복사해 놓는 임시 저장소입니다.
속도 향상을 위해 캐시를 사용하며, 다음과 같은 상황에서 캐시를 주로 사용합니다.
- 원본 데이터보다 빠르게 접근 가능할 때
- 같은 데이터에 반복적으로 접근할 때
- 변하지 않은 데이터를 주로 사용할 때
레디스(Redis)는 단순한 구조와 in-memory저장소로 인한 빠른 성능 때문에 캐시에 주로 쓰입니다.
캐싱 전략(Caching Strategies)
캐시로 사용할 때 어떻게 배치하는지가 시스템 성능에 큰 영향을 끼치는데 이를 캐싱 전략(Caching Strtegies)이라고 합니다.
Look-Aside
Look-Aside는 데이터를 찾을 때 우선 캐시에서 데이터를 찾고 데이터가 있다면 캐시에서 데이터를 가지고 오는 전략입니다.
만약 캐시에 데이터가 없어 Cache Miss가 발생한다면 앱은 DB에서 데이터를 가져온 뒤 캐시에 넣어주는 작업을 합니다.
캐시에 찾는 데이터가 없을 때 DB에 직접 조회해서 입력되기 때문에 Lazy Loading이라고 합니다.
이 구조는 캐시가 다운되더라도 DB에서 데이터를 가지고 올 수 있습니다.
만약 레디스가 다운되거나 DB에만 새로운 데이터가 있다면 Cache Miss로 인해서 많은 프로세스가 DB에 접근하기 때문에 DB에 많은 부하가 생길 수 있습니다.
이런 경우 DB에서 캐시로 데이터를 미리 넣어주는 작업을 하기도 하는데 이를 Cache Warming이라고 합니다.
Read Through
Read Through는 캐시에서만 데이터를 읽어오는 전략입니다.
Cache miss가 발생한다면 캐시는 DB에서 데이터를 검색하고 캐시에 자체 업데이트한 뒤 앱에 데이터를 보내줍니다.
Write Through
Write Through는 데이터를 저장할 때 먼저 캐시에 저장한 다음 DB에 저장하는 방식입니다.
캐시는 항상 최신 정보를 가지고 있지만 저장할 때마다 두 단계 스텝을 거쳐야 하기 때문에 상대적으로 느립니다.
또한 저장하는 데이터가 재사용되지 않을 수도 있는데 무조건 캐시에 넣어버리기 때문에 리소스 낭비가 발생할 수 있습니다.
이를 방지하기 위해 캐시에 expire time을 설정하기도 합니다.
Expire time?
데이터가 보관되는 시간, 시간 초과 시 데이터는 자동 삭제된다.
Write Back (a.k.a Write Behind)
Write Back은 먼저 캐시에 데이터를 저장했다가 특정 시점마다 DB에 저장하는 방식입니다.
캐시에 데이터를 모았다가 한 번에 DB에 저장하기 때문에 DB 쓰기 비용을 절약할 수 있지만 데이터를 옮기기 전에 캐시 장애가 발생하면 데이터 유실이 발생할 수 있습니다.
Write Around
Write Around는 모든 데이터는 DB에 저장되고 읽은 데이터만 캐시에 저장되는 방식입니다.
Cache miss가 발생하는 경우에만 캐시에 데이터를 저장하기 때문에 캐시와 DB 내의 데이터가 다를 수 있습니다.
Write Around는 주로 Look aside, Read through와 결합해서 사용됩니다.
마치며
캐시에 모든 데이터를 저장할 필요 없이 "파레토 법칙"에 따라 일부만 저장해도 대부분의 데이터를 커버할 수 있습니다.
파레토 법칙- 8:2 법칙
전체 결과의 80%가 전체 원인의 20%에서 일어나는 현상을 가리킨다.
서비스에 빗대어 표현하자면 80%의 활동을 20%의 유저가 하기 때문에 20%의 데이터만 캐시 해도 서비스 대부분의 데이터를 커버할 수 있게 됩니다.
이 때문에 in-memory 저장소인 레디스가 캐시에 적합하며 상황에 맞는 캐싱 전략을 사용한다면 DB의 부하를 줄일 수 있고 응답에 대한 지연시간 감소와 처리량 증가로 인해 서비스 성능을 향상시킬 수 있습니다.