Redis Cache Strategy Pattern

• Cache : 데이터의 원래 소스보다 더 빠르고 효율적으로 액세스할 수 잇는 임시 데이터 저장소
• Redis의 단순한 key-value 구조와 In-memory 사용, 빠른 성능으로 Cache로 많이 활용됨

Read Cache 전략

Look-Aside (Lazy Loading)

1. 클라이언트가 데이터를 요청
2. 웹 서버는 데이터가 존재하는지 Cache Server에 먼저 확인
3. Cache Server에 데이터가 있으면 결과값을 클라이언트에게 바로 반환 (Cache Hit)
4. Cache Server에 데이터가 없으면 DB에서 데이터를 조회하여 Cache Server에 저장하고 결과값을 클라이언트에게 반환 (Cache Miss)

Cache Warming

• database -> application -> Redis
• 미리 Cache Server로 DB의 데이터를 밀어 넣어두는 작업
• 서비스 초반 Cache 성능 향상 및 트래픽 급증 대비를 위해 수행하는 것이 좋음
  • Cache Warming 미수행 시 서비스 초반 트래픽 급증 시 발생하는 Cache miss + Cacheable 작업으로 Cache Server와 DB에 부하가 급증하는 Thundering Herd 발생 가능

Write Cache 전략

Write-Around

• DB에 데이터를 저장하고 Cache miss 발생 시에 Cache Server로 데이터를 가져오는 쓰기 전략
• 데이터 불일치 문제 발생 가능
  • 데이터 불일치 방지를 위해 DB에 저장된 데이터가 수정, 삭제될 때마다 저장해둔 Cache 또한 삭제하거나 변경 필요
  • 데이터 변경 요청이 빈번한 경우 Cache를 변경하거나 삭제하는 비용이 조회하는 비용보다 커질 수 있음을 유의

Write-Through

• DB와 Cache Server에 데이터를 동시에 저장
• 데이터 불일치 문제가 발생하지 않지만 매 요청마다 2번의 Write가 발생하므로 데이터 변경이 빈번한 서비스에서는 성능이 저하될 수 있음
• TTL 값을 추가하여 낭비되는 메모리를 최소화할 수 있음

Write-Back

• Cache Server에 데이터를 저장, 반영하고 일정 주기의 배치 작업을 통해 데이터를 DB에 반영
• Write가 빈번하면서 Read 시에 많은 Resource가 소모되는 서비스 영역의 경우 (Data Set이 큰 경우) 적용 고려
  • DB를 조회하지 않고 지속적 접근 가능
• 데이터의 불일치나 조회 요청으로 인한 서비스 부하는 발생하지 않지만, In-memory 데이터가 일정 기간마다 저장되기 때문에 장애 발생 시 데이터 손실 발생 가능
  • Replication이나 Cluster 구조 적용으로 가용성을 높여야 함