[additional] 다양한 캐싱 전략

[JasonYoo1995]

연관 챕터

1

조사 내용

• 비즈니스 로직 특성에 따라 가장 효율적인 캐싱 전략 선택
• 아래의 Read 전략과 Write 전략을 조합(Combination)하여 사용
• 크게 Aside Topology와 Inline Topology가 있음

Cache-Aside

• 가장 많이 사용되는 전략
• Cache Miss 시 Application이 할 일이 많아진다
• Read-Heavy Workloads에 유리
• Cache 서버가 죽어도 DB로 요청하면 되기 때문에 무중단으로 운영 가능 (=Resilient To Cache Failures) → 단, Peak Time에는 DB 과부하가 생기므로 큰 이득이 없을 수 있음
• Write는 직접 DB에 함 → Cache와 DB 간에 Inconsistency 발생 → Cache Invalidation(캐시 무효화)를 통해 해결 → 즉, TTL(Time To Live) Expire을 통해 Stale Data를 제공하지 않도록 방지

Read-Through Cache

• Application가 DB로부터 직접 Read 하지 않고, Cache를 통해서 Read
• Cache-Aside와 마찬가지로 Lazy하게 Read한다는 공통점이 있지만 DB로부터 Data를 Fetching하는 책임이 Application이 아닌 Cache에게 있다는 차이점이 있음
• 뉴스 피드처럼 똑같은 데이터를 여러 번 읽는 Read-Heavy Workloads에 유리
• Cache Miss로 발생하는 오버헤드를 줄이는 방법
  • ‘warming’ or ‘pre-heating’
  • 서비스하기 전에 수동으로 미리 Caching 해놓는다
• Cache와 DB 간에 Inconsistency는 여전히 발생 → Write-Through Cache 전략으로 해결

Write-Through Cache

• Write 성능이 오히려 더 떨어지지만 Read-through와 함께 사용되어 Read-through 전략의 장점들을 모두 누릴 수 있고
• 그와 더불어, Cache와 DB 간의 Consistency가 항상 보장되어 Cache Invalidation을 할 필요가 없다는 장점이 있다

Write-Around Cache

• Read는 Cache를 통해서 하지만, Write는 Cache를 거치지 않고 직접 DB에 수행
• 한 번 Write 되고, 자주 Read 하지 않거나 아예 Read하지 않는 경우에 유리 ex) 실시간 로그
• Read-Through와 Combine 될 수도 있고, Cache-Aside와 Combine 될 수도 있다

Write-Back Cache (=Write-Behind Cache)

• Application이 Write 요청을 하면, Cache에만 Write하고 즉시 응답(ACK)
• 일정 시간 이후에 Cache에 쌓인 Write 연산들을 한꺼번에 DB에 수행
• Write-Heavy Workloads와 Mixed Workloads에 유리
  • Mixed Workloads의 예시 : Write한 데이터 항목을 바로 Read하는 경우 (Available in Cache)
• DB에 Downtime이 발생해도 문제 없다 (=Resilient To Database Failures)
• Write 연산을 한꺼번에 반영하므로, Write 성능을 향상시켜준다
• 단점 : Cache Failure 발생 시 데이터 복구가 불가능하다
• InnoDB 등 대부분의 관계형 DB 엔진들은 자체 내부 메모리를 통한 Write-Back Cache 사용이 default로 enable 되어 있음

---

• 출처 : https://codeahoy.com/2017/08/11/caching-strategies-and-how-to-choose-the-right-one/

---

@caffeine-library/readers-system-design-interview