캐시 설계 전략

준하·2025년 1월 17일

게시글 참고: inpa.tistory.com - REDIS-📚-캐시Cache-설계-전략-지침-총정리

캐시는 일반적으로 메모리를 사용하기 때문에 데이터베이스 보다 훨씬 빠르게 응답이 가능하다.

하지만 캐시는 데이터 정합성 문제를 야기할 가능성이 있으며, 메모리가 상대적으로 비용이 높기 때문에 효율적인 캐시 설계 전략이 중요하다.

캐시 읽기 전략(Read Cache Strategy)

Look Aside 패턴

데이터를 찾을 때, 우선적으로 캐시를 확인하는 전략.
만일 캐시에 데이터가 없을 경우 DB에서 조회.
반복적인 읽기가 많은 호출에 적합하며, 원하는 데이터만 별도로 구성하여 캐시에 저장한다.

Look Aside 방식은 캐시에 문제가 발생하더라도, DB에 요청을 전달함으로써 서비스 문제는 대비할 수 있다. 하지만 캐시와 DB 간 정합성 문제가 발생할 수 있으며 초기 조회 시 무조건 DB를 호출해야 하므로 단건 호출 빈도가 높은 서비스에 적합하지 않다. 대신 반복적으로 동일 쿼리를 수행하는 서비스에 적합한 아키텍처이다.

Read Through 패턴

캐시에서만 데이터를 읽어오는 전략
데이터 동기화를 캐시에 위임하여 조회 속도가 느릴 수 있다.
캐시와 DB간 항상 데이터 동기화가 유지된다.

Look Aside 패턴과 유사하지만, 항상 캐시를 통해 데이터를 읽는 패턴이다.
캐시와 DB 간 데이터가 동기화 되지만, 캐시에 문제가 발생할 경우 서비스 전체에 장애가 발생할 수 있다.
그렇기 때문에 Replication 등을 활용해 고가용성을 구축하는 것이 중요하다.

캐시 쓰기 전략(Write Cache Strategy)

Write Back 패턴

데이터를 저장할때, DB가 아닌 캐시에 저장
캐시에서는 일정 주기 배치 작업을 통해 DB에 반영.
캐시에서 오류가 발생하면 데이터가 소실될 수 있음.

Write Back 방식은 데이터를 저장할때 DB가 아닌 먼저 캐시에 저장하여 모아놓았다가 특정 시점마다 DB로 쓰는 방식으로 캐시가 일종의 Queue 역할을 겸하게 된다.

캐시 읽기 전략인 Read-Through와 결합하면 가장 최근에 업데이트된 데이터를 항상 캐시에서 사용할 수 있는 혼합 워크로드에 적합하다.

Write Through 패턴

데이터베이스와 Cache에 동시에 데이터를 저장하는 전략
캐시와 DB의 데이터가 동기화 됨
매번 두 단계의 쓰기 과정을 거치기 때문에 상대적으로 느림.

write throuth 패턴과 write back 패턴 둘 다 모두 자주 사용되지 않는 데이터가 저장되어 리소스 낭비가 발생되는 문제점을 안고 있기 때문에, 이를 해결하기 위해 TTL을 꼭 사용하여 사용되지 않는 데이터를 반드시 삭제해야 한다. (expire 명령어)