Redis
캐시란
cache란 사용자의 입장에서 데이터의 원래 소스보다 더 빠르게 그리고 더 효율적으로 액세스할 수 있는 임시 데이터 저장소를 뜻한다. 대부분의 애플리케이션에서 속도 향상을 위해 cache를 사용하고 있다. 캐시에 데이터나 계산된 결과 값의 복사본을 저장해 둠으로써 전체적인 처리 속도를 향상시킨다.
캐시를 사용하는 경우는 다음과 같다.
- 데이터에 직접적으로 접근하는 데 걸리는 시간이 오래 걸릴 때
- 데이터가 잘 변하지 않는 경우
- 반복적으로 동일한 결과를 돌려주는 경우 (이미지와 썸네일 등)
Redis란
레디스는 전 세계에서 가장 유명한 caching 솔루션이다. 단순하게 key-value 형태로 저장할 수 있기 때문에 어떤 데이터라도 쉽게 저장할 수 있다. 또한 레디스는 모든 데이터를 메모리에 올려두는 인메모리 데이터 스토어이다. 평균 읽기 및 쓰기 작업 속도가 1밀리 세컨드 미만이니 초당 수백만 건의 작업이 가능하다.
캐싱 전략
레디스를 cache로 사용할 때 어떻게 배치하는지가 시스템의 성능에 큰 영향을 끼치기 때문에 caching 전략은 데이터의 유형과 해당 데이터에 대한 액세스 패턴을 잘 고려해서 선택해야 한다.
읽기 전략
Cache-Aside
애플리케이션이 요청을 받으면, 데이터가 캐시에 있는지 먼저 검사를 하며, 그 결과(캐시에 데이터가 로딩되어 있는지 여부)에 따라 다음 액션이 결정된다. 캐시에 데이터가 없다면, 애플리케이션이 캐시에 데이터를 업데이트한다. 캐시에 대한 의존성이 낮으므로, 캐시가 다운되더라도 원천 데이터베이스로 서비스를 계속할 수 있다. 읽기 요청이 많은 경우에 적합하다.
Read-Through
캐시 미스 시 데이터베이스와 동기화하는 몫은 캐시에 위임된다. 최초 데이터 로딩은 미스가 나며, 그 때 데이터가 로딩된다. Cache-Aside 전략과 마찬가지로 읽기요청이 많은 경우를 처리하는데 적합하다. 첫 요청의 캐시 미스를 방어해야 한다면 스케쥴 작업 등을 통해 미리 캐시를 warm up시켜놓기도 한다.
쓰기 전략
Write-Around
write around 방식은 DB에만 데이터를 저장한다. 일단 모든 데이터는 DB에 저장되고 읽은 데이터만 캐시에 저장된다. 이 경우엔 cahce 내의 데이터와 DB 내의 데이터가 다를 수 있다는 단점이 있다. 데이터가 한 번 쓰여지고, 덜 자주 읽히거나 읽지 않는 상황에서 좋은 성능을 제공한다. 예를들어, 실시간 로그 또는 채팅방 메시지가 있다.
Write-Through
write-through 전략은 DB에 데이터를 저장할 때 cache에도 함께 저장하는 방법이다. cache는 항상 최신 정보를 가지고 있다는 장점이 있지만 저장할 때마다 두 단계 스텝을 거쳐야 하기 때문에 상대적으로 느리다고 볼 수 있다. 그리고 저장하는 데이터가 재사용되지 않을 수도 있는데 무조건 캐시에 넣어버리기 때문에 이는 일종의 리소스 낭비라고도 볼 수 있다. 따라서 이렇게 데이터를 저장할 때는 몇 분 혹은 몇 시간 동안만 데이터를 보관하겠다는 의미인 expire time을 설정해 주는 것이 좋다.