캐시 전략
캐시 전략이란?
시스템 아키텍처와 Cache Layer를 구성하면서 캐싱전략에 따라 시스템 구성 및 서비스 성능에 영향을 줄 수 있습니다.
이에 따라 상황에 맞는 캐싱 전략을 세우는 것이 좋습니다.
캐시전략을 잘 세우기 위해서는 다음과 같은것들 잘 파악하고 있으면 좋습니다.
- 어느 종류의 데이터를 캐시에 저장할지
- 얼만큼 데이터를 캐시에 저장할지
- 얼마동안 오래된 데이터를 캐시에서 제거할지
- 자주 조회되는 데이터인지
- 결괏값은 자주 변동되는지
어떤 전략들이 존재하고 어떨 때 사용하면 좋은지에 대해 알아보고자 합니다.
Cache Aside
Aside란 ~곁에라는 뜻입니다.
가장 많이 사용하는 전략이며, 캐시를 곁에 두고 필요할 때만 데이터를 캐시에 로드하는 전략입니다.
처음 사용자가 요청하게 되면, 캐시에는 아무런 데이터도 존재하지 않습니다.
1. Application이 데이터를 Cache에 먼저 조회합니다.
2. Cache에 데이터가 존재하면 사용자에게 데이터를 제공합니다.
3. Cache에 데이터가 존재하지 않으면 DB에서 데이터를 조회합니다.
4. Cache에 데이터를 적재하며, 사용자에게 데이터를 제공합니다.
장점
실제로 사용하는 데이터만 캐시 하기 때문에 자원을 효율적으로 사용할 수 있다.
캐시 오류가 발생해도 데이터베이스에 Read 요청을 보내어 오류가 전파되지 않는다.
단점
캐시에 데이터가 없는 경우 응답 시간이 오래 걸린다.
데이터 정합성이 깨질 수 있다 (동기화 문제, 적절한 TTL이 중요하다)
단건 호출 빈도가 높은 서비스에는 적합하지 않다. (반복적으로 동일한 쿼리를 수행하는 서비스에 적합하다)
Read-Through
Read Through란 이름에서 볼 수 있듯이 캐시를 통해서만 데이터를 읽어오는 전략입니다.
캐시에 데이터가 누락된 경우 데이터베이스에 누락된 데이터를 조회하여 캐시에 채우고 application에 반환합니다.
Cache Aside 전략과 유사한 점은 모두 데이터를 읽을 때만 데이터베이스를 조회합니다.
하지만 Cache에 주체를 위임하며 동기화 역할을 Cache에게 위임합니다.
장점
실제로 사용하는 데이터만 캐시 하기 때문에 자원을 효율적으로 사용할 수 있다.
단점
캐시에 장애가 발생하면 데이터베이스에 요청을 보내지 못하여 대안이 없다.(Replication 또는 Cluster로 구성하여 가용성을 높여야 한다)
단건 호출 빈도가 높은 서비스에는 적합하지 않다. (반복적으로 동일한 쿼리를 수행하는 서비스에 적합하다)
데이터 정합성이 깨질 수 있다 (동기화 문제, 적절한 TTL이 중요하다)
Write Through
읽기 전략과 반대로 쓰기에도 캐시 레이어를 활용하여 캐시와 데이터베이스에 데이터를 write 하는 것입니다.
장점
캐시 데이터가 항상 최신상태로 동기화되어 있습니다.
캐시와 백업 저장소가 데이터 일관성을 항상 유지하여 안정적입니다.
단점
사용하지 않는 데이터도 Cache에 적재한다 (리소스 낭비)
쓰기 지연 시간 증가 (Cache , Database 모두 적재)
Write Around
write 요청 시 Cache를 거치지 않고 데이터베이스에 기록되고, 읽는 데이터만 캐시에 저장하는 전략
기록하는 데이터가 자주 사용되지 않는 경우에 적합합니다.
write back
application에서는 cache에만 write 요청을 처리합니다.
별도의 서비스 등(Batch, Scheduler)을 통해 Database에 데이터를 동기화시킵니다.
장점
대량의 Write 요청이 있는 경우에 적합합니다.
단점
데이터를 모아두었다가 적재하기 때문에 적재 주기 사이에 문제가 발생하면 데이터 유실에 따른 문제가 발생합니다.
선착순 이벤트에 적절한 캐시 전략
아주 짧은 시간 대량의 트래픽으로 순식간에 처리해야 하는 선착순 이벤트 같은 서비스의 경우 Read-Through와 Write-Back 전략을 이용하면 효과적으로 이벤트를 처리할 수 있습니다.
참고자료
https://velog.io/@psk84/Caching-%EC%A0%84%EB%9E%B5