Meta가 캐시 무효화를 쓰면서 캐시 일관성을 유지하는 방법 (번역)

Cache Inconsistency

• cache server가 db에서 x에 대한 요청을 보내고 db가 x=42를 응답이 cache에 도착하기 전에
  • 외부에서 x=43 으로 업데이트하고, invalidation을 통해 x=43을 cache에게 전달함
  • cache는 x=43을 받아서 반영함
  • x=42 응답이 뒤늦게 도착하여 반영됨
• 위의 문제는 data에 version을 붙여서 해결 가능
• 하지만 version을 붙이더라도 x=43에 대한 eviction이 일어나면 x=42가 반영될 수 있음

Polaris: Cache Inconsistency 측정 서비스

• 동작과정
  • Polaris도 invalidation event를 받음
  • event를 받으면 모든 cache server를 찔러서 이전 version을 가지고 있는지 확인함
  • cache가 이전 version을 가지고있으면 inconsistency로 판단하고 재시도 할 수 있도록 requeue
    • cache server에게 invalidation event가 늦게 도착할 수 있기 때문
  • 특정 시간 (1분,3분,5분 등)이 지나면 inconsistency 알람을 보냄
• metric
  • 최근 M분동안 N nines에 해당하는 cache write이 consistent한지 metric을 보여줌
  • 5분동안 10 nines라면, 최근 5분동안 100억개중 1개의 cache write이 inconsistency하다고 알 수 있음

Cache Inconsistency를 디버그를 위한 로깅 라이브러리

• 모든 cache write을 로깅하는건 불가능함
  • 애초에 cache가 read-heavy workload인데 "로깅"으로 인해 write-heavy workload가 되기 때문
• 따라서 invalidation이 일어난 직후의 time window에 대해 로깅을 할 수 있도록 라이브러리를 만듦
• invalidation에 관여하는 모든 서비스에 라이브러리를 심어둠
• 로깅을 통해 inconsistency가 발생했을때, 발생하기까지의 과정을 timeline으로 알아낼 수 있음