Redis를 활용하여 애플리케이션 성능과 확장성을 높이려면, 단순히 '어떤 데이터를 캐싱할지' 결정하는 것을 넘어, 캐시 전략을 체계적으로 수립해야 된다.
Redis 캐싱 전략을 구성할 때 주로 고려하는 요소와 대표적인 패턴 및 기법들을 알아보자.
캐싱 기본 개념
핫 데이터
- 자주 조회되는 데이터를 캐시에 저장해 DB 부담을 덜어주고, 응답 속도를 개선한다.
- 캐시 적중률이 높을수록 이점이 커지며, 적중률이 낮다면 불필요한 메모리만 차지하게 될 수 있다.
Key-Value 저장
- Redis는 문자열, 해시, 리스트, 셋 등 다양한 구조를 지원하지만, 기본적으로 Key-Value 기반으로 동작한다.
TTL (Time To Live)
- 캐시된 데이터의 만료 시간을 설정해두면, 유효 기간이 지난 데이터는 자동으로 제거된다.
- 이를 통해 오래된 데이터의 불일치 및 메모리 누적 문제를 방지한다.
Cache Hit : 캐시 스토어(Redis)에 데이터가 있을 경우 바로 가져온다.
Cache Miss : 캐시 스토어에 데이터가 없을 경우 DB에서 가져온다.
캐싱 전략
Cache Aside
가장 흔히 쓰이는 캐싱 패턴이다.
애플리케이션이 먼저 캐시에 접근하고, 데이터가 없으면 DB에서 읽어온 뒤 캐시에 넣는다.
쓰기 시에는 DB를 갱신하고, 캐시를 무효화(delete)하는 방법이 주로 사용된다.
- 반복적인 읽기가 많은 호출에 적합하다.
- 캐시와 DB가 분리되어 있기 때문에 원하는 데이터만 별도로 구성하여 캐시에 저장할 수 있고, 캐시 장애 대비 구성이 되어 있다.
- Redis가 다운되더라도 DB에서 데이터를 가져올 수 있으므로 서비스에 문제가 없다.
Read-Through
- 캐시에 요청이 들어왔을 때 캐시가 DB에 직접 접근하여 값을 가져와서 캐시에 저장 후 반환한다. (읽기에 초점)
- 사용자가 직접 DB를 조회하지 않고, 캐시 계층이 DB 연동 로직을 책임진다.
- 따라서 데이터를 조회하는데 전체적으로 속도가 느리다.
- 또한, 데이터 조회를 전적으로 캐시에 의지하므로, Redis가 다운될 경우 서비스 이용에 차질이 생길 수 있다.
Write-Through
- 캐시에 쓰기를 하면, 캐시가 DB에도 동기적으로 쓰기를 하는 방식 (쓰기에 초점)
- Read-Though 와 마찬가지로 DB 동기화 작업을 캐시에 위임한다.
- 데이터 유실이 발생하면 안되는 상황에 적합하다.
- 매 요청마다 두번의 Write가 발생하게 됨으로써 빈번한 생성, 수정이 발생하는 서비스에서는 성능 이슈가 발생할 수 있다.
Write-Behind (Write-Back)
데이터 변경 시 즉시 DB에 반영하지 않고, 캐시에 먼저 쓰고 일정 시간이 지난 후 비동기로 DB에 반영
- 빈번한 쓰기를 묶어서 한번에 DB에 적용 가능(배치), 높은 쓰기 성능을 기대할 수 있다.
- Redis가 장애나면 아직 DB에 반영되지 않은 데이터가 유실될 위험이 있다.
- 분산 환경에서 동시성 이슈가 복잡해질 수 있다.
Write Around
- 쓰기 로직을 처리할 때, 쓰기 연산을 캐시에 직접 반영하지 않고, 오직 DB에만 데이터를 기록
- 캐시에 들어있는 내용은 무효화(delete or 아무 조치 안함)
- 쓰기는 DB 위주로 처리하고, 캐시는 주로 읽기를 가속하기 위한 용도로만 사용한다는 것이 핵심.
Cache Aside 와 Write Around 차이
- Cache Aside는 "읽기 시 캐시가 없으면 DB에서 가져와 적재, 쓰기 시 DB를 업데이트하고 캐시 무효화".
- Write Around는 "쓰기 시 DB에만 쓰고, 캐시를 무효화할지 말지 선택"
결론
- Write Around는 캐시를 건드리지 않음으로써 쓰기 성능을 높이고, 대신 재조회 시 캐시 미스를 허용하므로 실시간 일관성은 다소 낮을 수 있다.
- Cache Asdie는 쓰기 시점에 캐시도 무효화/갱신 하기 때문에 일관성을 좀 더 강조한다.
- 프로젝트 상황(데이터 변경 후 즉시 재조회 빈도, 쓰기 부하, 캐시 히트율 목표, 전체 트래픽 구조 등)에 따라, 어느 쪽을 택할지(혹은 혼합할지) 결정하면 된다.
모르면 알고 넘어가자