저번에 공부했던 캐시 개념에 이어 이번에는 캐싱 전략에는 무엇이 있는지 알아보겠습니다 😎

🗃️ 캐싱 전략

• 시스템 아키텍쳐를 구성하면서 캐시 레이어를 어떻게 구성하고, 어떤 전략을 사용할 것인지를 파악하는 것이 중요하다.
  • 이는 서비스의 전반적 성능에 영향을 줄 수 있기 때문.
• 잘못된 전략을 적용하게 되면 오히려 이점을 이용하지 못하고, 전체적으로 성능에 이점이 없을 수 있다.
• 모든 경우에 캐시를 사용하는 것이 꼭 좋은 점만 있는 것은 아니기 때문에 반영하고자 하는 서비스의 특징을 잘 살피고 적용해야 한다.

📁 Cache Aside

특징

• 가장 많이 사용되는 캐싱 전략이다.
• application과 db 옆에 두어 필요할 때에만 데이터를 캐시에서 로드하는 전략
  • 상대적으로 의존성이 낮으며, cache는 별도로 관리된다.
  • 필요한 경우에만 캐시에 접근한다!
• 이 전략의 경우 읽기가 많은 경우 주로 사용한다.
  • Memchached와 Redis가 이 전략을 사용하는 것으로 유명하다.

데이터 조회 전략

• 캐시는 DB에 직접 연결되지 않고, application이 주체가 된다.
  • 데이터 조회시 application에서 cache를 먼저 조회한다.
  • cache에 데이터가 있을 경우 조회하여 전달하고, 없을 경우 application이 DB에서 조회하여 cache에 적재한 후, 사용자에게 데이터 전달

장점

• 실제로 사용하는 데이터만 캐시에 적재하여 자원을 효율적으로 사용한다.
  • 자주 호출되는 데이터에 대해 캐시 사용
• 캐시 오류에 대해 탄력적이다.
  • 캐시에 문제가 발생하여 데이터를 조회하지 못해도 DB를 통해 데이터를 조회할 수 있기 때문에 캐시 서버가 다운되어도 application 까지 오류가 전파되지 않는다.
• DB와 데이터 모델이 다르게 존재하도록 만들 수 있다.
  • DB의 데이터 형태를 그대로 적재하지 않아도 application에서 충분히 활용이 가능하다.
  • 특정 기능에 따라 형성되는 모습 그대로 적재하여 활용할 수 있다.

단점

• 캐시에 데이터가 없는 경우에는 바로 DB를 조회하는 것보다 속도가 더 느릴 수 있다.
  • DB에서 조회한 데이터를 cache에 적재하는 과정이 있기 때문.
• 데이터의 일관성이 깨질 수 있다.
  • 캐시에는 데이터가 존재하지 않는 경우에만 DB를 조회하여 캐시에 적재하기 때문에 동기화 문제가 중요하다.
• 수많은 트래픽이 몰리는 환경 같은 경우 해당 전략은 적절한 방법이 아니다.

반복적으로 동일한 데이터를 읽는 경우가 많은 경우 사용하면 좋은 전략일 것 같다. 하지만 직접적으로 DB에 접근하기 때문에 대용량 트래픽을 처리하는 경우 과부화가 쉽게 올 수 있는 전략인 것 같다.

📁 Read-Through Cache

특징

• application, cache, DB를 inline으로 배치하는 전략
• 캐시에 데이터가 누락된 경우, DB에서 누락된 데이터를 조회하여 캐시에 채운 후에 application에 반환
• cache-aside 방식과 같이 데이터를 lazy loading 한다.
  • 데이터를 읽을 때에만 조회
• cache-aside 방식과 다른 점은 application이 cache만 바라본다는 것이다.
  • 즉, cache가 데이터를 저장하는 메인 주체가 되는 것이다.
  • 데이터 동기화 역할도 cache가 수행한다.
• DB와 동일한 형태로 데이터를 저장한다.
  • 데이터 주체가 cache이기 때문에

데이터 조회 전략

• application은 데이터 조회 요청이 들어올 경우 cache를 먼저 조회한다.
  • 데이터가 존재한다면 조회한 데이터를 전달하고, 없다면 cache를 관리하는 곳에서 DB에 데이터를 조회한다.
  • cache에 데이터를 적재한 후에 application에 데이터를 전달하고, 이를 사용자에게 전달한다.

장점

• cache aside와 마찬가지로 읽기 작업이 부하가 많을 경우, 캐시에 데이터를 두고 데이터를 읽을 수 있어 효율적이다.
• 대량의 트래픽으로 처리되어야 하는 경우 미리 데이터를 cache에 적재하여 읽기 부하를 핸들링할 수 있다.
  • 읽어오는 주체가 cache이기 때문에

단점

• 처음 요청은 무조건 cache miss가 발생한다.

application이 직접적으로 DB와 연결되지 않고 캐시를 거치기 때문에 대용량 트래픽을 cache를 통해 처리할 수 있어 효과적이지만 캐시 서버와 DB에 연동되기 이전에 문제가 일어날 경우 데이터가 날아갈 수 있어 추가적인 작업이 필요한 전략인 것 같다.

📁 Write-Through Cache

특징

• Read Through 와 반대로 데이터를 변경할 때 사용되는 전략이다.
• 하지만 Read Through와 마찬가지로 동일하게 cache가 주체가 되는 전략이다.
  • cache가 주체가 되어 데이터를 cache와 DB에 데이터를 저장하는 것.
• 데이터를 저장할 때마다 cache에 저장하고, DB에 저장하기 때문에 동기화가 이루어진다.

데이터 조회 전략

• application에서 데이터 저장 요청이 발생하면 cache를 관리하는 곳에서 cache에 데이터 저장을 요청한다.
• cache에 데이터 적재 후 DB에 데이터를 저장한다.
  • 항상 데이터 저장은 cache를 통해 이루어진다.

장점

• cache와 DB의 데이터가 항상 동기화 되어 있다.

단점

• 사용하지 않는 데이터여도 cache에 데이터가 적재되어 있을 가능성이 높다.
  • 데이터를 조회가 아닌 저장할 때 cache에 저장하기 때문
• 쓰기 지연 시간이 증가한다.
  • cache에 적재 후, DB에 적재하기 때문

🪐 Write-Through와 Read-Through 전략을 같이 사용하면 데이터가 일관성이 있게 동기화할 수 있으면서, 동시에 데이터를 조회할 때에도 cache를 사용하기 때문에 캐시의 모든 이점을 이용할 수 있게 된다.

작성한 데이터를 반드시 빠른 시간 내에 반복적으로 접근하는 경우 효과적인 전략이다. 하지만 그렇지 않은 경우 필요없는 데이터가 캐시에 적재되어 공간을 차지하고 있게 되기 때문에 주의해야 하는 전략인 것 같다.

📁 Write-Around

특징

• write 요청 시 cache를 거치지 않고 DB에 저장하며, 읽는 데이터에 대해서만 cache에 저장하는 전략이다.

데이터 조회 전략

• application에서 데이터 write 요청 시 DB에 바로 write 요청을 보낸다.
• application에서 read 요청 시 cache를 먼저 확인 후 데이터가 존재한다면 조회한 데이터를 전달한다.
• 없으면 cache를 통해 DB에서 데이터를 조회하고, 저장한 후에 조회한 데이터를 전달한다.

장점

• 쓰기 작업에 cache가 사용되지 않기 때문에 쓰기 지연이 발생하지 않는다.
• 기록한 데이터가 자주 사용되지 않으면서 읽기 작업에 부하가 잘 발생하는 경우에 사용하면 효율적이다.

단점

• 데이터 조회 시 cache에 저장하는 과정이 있어 속도가 느릴 수 있다.

데이터를 바로 DB에 작성하기 때문에 데이터의 일관성도 지키면서 반복적인 접근에 대해 성능을 높일 수 있다. 하지만 데이터가 작성되고 반드시 반복적으로 접근하게 된다면 데이터 초기 접근 시에 캐시에서 가져오는 과정이 반드시 필요하다.

📁 Write-Back

특징

• application은 cache에만 write를 요청한다.
• 별도의 서비스(Batch, Scheduler 등)를 통해 DB에 데이터를 동기화 시킨다.

데이터 조회 전략

• application은 write 요청 시에 cache에 요청 받은 데이터를 적재하고 요청에 대한 처리를 완료한다.
• 특정 서비스가 특정 주기로 cache에 적재된 데이터를 DB에 적재한다.

장점

• 쓰기 요청이 많은 경우 cache에 처리를 적재한 후, DB에 저장하는 식으로 부하를 줄일 수 있다.
  • 쓰기 비용을 절감하는 효과가 있다.

단점

• 데이터를 모았다가 적재하기 때문에 그 사이에 cache에 문제가 발생할 경우, 데이터 유실 관련 문제가 발생할 수 있다.

🪐 아주 짧은 시간안에 대량의 트래픽을 처리해야 하는 경우 Read-Through와 Write-Back 전략을 이용하면 효과적인 아키텍처를 만들 수 있다.

캐시에 작성하기 때문에 대용량 처리를 하기에 적합하지만 캐시 서버를 중간에 거치는 것인 만큼 동기화가 중요한 전략이다. 그리고 캐시 서버가 다운되어 데이터가 모두 날아가는 경우에 대한 전략도 필요하다.

느낀점 🧐

캐시를 적용하는 것은 단순히 최근에 조회한 데이터를 적재하는 정도로 생각했는데, 읽기, 쓰기 중 어떤 것에 캐시를 적용하느냐에 따라 다르고, 캐시와 DB 사이에서의 동기화도 신경써야 한다는 것을 알게 되었다..!

미리 조금 말을 해보자면 임시 저장 기능에 캐시를 적용해볼 예정인데 어떤 캐시 전략을 가져가고, 어떤 캐시 서버를 구축할 것인지를 잘 고민해보고 결정해야 할 것 같다!! 😤

참고

Caching 전략
Caching 전략 소개 및 사용 예제