13P by gos16052 27일전 | favorite | 댓글과 토론

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으로 알아낼 수 있음