Redis의 Caching Strategy

캐시 for 속도 향상

캐시를 유용하게 사용하려면

1. 캐시 저장소에 접근하는 속도 > 원본 데이터 저장소에 접근하는 속도
2. 동일 데이터 반복 접근 상황이 많을 때
3. 잘 변하지 않는 데이터일수록

Redis의 캐싱 전략

Redis를 Cache로 사용할 때, 어떻게 배치하느냐에 따라 시스템 전체 성능에 큰 영향을 끼친다고 한다. 그래서 이에 대한 전략을 세워야 하며 데이터의 유형, 데이터에 대한 Access Pattern을 잘 고려해야 한다.

Read Strategy

Look-aside(Lazy Loading) 전략

1. Read 요청 -> Cache 확인
   2.1. Cache Hit: Cache에서 읽어옴
   2.2. Cache Miss: DB 접근하여 가져온 후 Cache에 저장
   → 찾는 데이터가 캐시에 없을 때만 데이터가 캐싱된다.

• 캐시(Redis)와 DB가 분리되어 가용되기 때문에 원하는 데이터만 별도로 구성하여 캐시에 저장할 수 있다
• 분리되어 가용되기 때문에 만약 redis가 다운되더라도 DB에서 데이터를 가져올 수 있기 때문에 서비스 자체에는 문제가 없다. 캐시 장애 대비가 되어 있다.
  • 하지만 캐시에 붙어있던 Connection이 많았다면, redis가 다운된 순간, 순간적으로 DB에 Connection이 몰리며 부하가 발생할 수 있다. 또한 처음에 Cache Miss가 지속적으로 발생하여 DB 성능에 저하가 올 수 있다.
    • Cache Warming
      이때, 미리 캐시로 데이터를 밀어 넣어주는 작업을 할 수 있다.
• 단점
  - 캐시 장애는 대응할 수 있지만, 데이터 정합성 문제가 발생할 수 있음.
  - 초기 조회 시 무조건 DB를 호출해야 하므로 단건 호출 빈도가 높은 서비스라면 적합하지 않다.
  - 따라서 반복적으로 동일 쿼리를 수행하는 서비스에 적합한 아키텍처.

Read Through 전략

• 캐시에서만 데이터를 읽어오는 전략. 조회하는데 속도가 느리다.
• Redis 다운될 경우 서비스 이용에 차질이 생길 수 있다.
• 캐시와 DB 간 데이터 동기화가 항상 이루어져 데이터 정합성이 보장됨
• 읽기가 많은 워크로드에 적합하다.

Write Strategy

Write-around

• DB에 데이터를 저장하고, Cache Miss가 발생할 시 DB에서 데이터를 캐싱함.
• 데이터 정합성의 문제
  
  

Write-through

• DB에 데이터를 저장할 때 Cache에도 함께 저장함.
• 느리다 + 재사용되지 않는 데이터도 캐싱될 수 있어 리소스 낭비 문제
• Expire Time을 설정하면 좋다.

일반적인 Read/Write 조합

• 일반적으로 Look Aside + Write Around 조합을 사용한다.
• 데이터 정합성 이슈에 대한 완벽한 안전장치 구성으로 Read Through + Write Around
• 항상 최신 캐시 데이터를 보장하며, 데이터 정합성까지 보장하는 Read Through + Write Through

ref) Redis의 캐싱전략1
Redis의 캐싱전략2