Metaがキャッシュ無効化を使いながらキャッシュ整合性を維持する方法（翻訳）

Cache Inconsistency

• cache server が DB に x へのリクエストを送り、DB が x=42 を返した応答が cache に到着する前に
  • 外部から x=43 に更新され、invalidation を通じて x=43 が cache に伝えられる
  • cache は x=43 を受け取って反映する
  • x=42 の応答が遅れて到着し、反映される
• 上の問題は、データに version を付けることで解決可能
• しかし version を付けても、x=43 に対する eviction が起きると x=42 が反映されうる

Polaris: Cache Inconsistency 測定サービス

• 動作過程
  • Polaris も invalidation event を受け取る
  • event を受け取ると、すべての cache server を確認して以前の version を持っているか調べる
  • cache が以前の version を持っていれば inconsistency と判断し、再試行できるよう requeue する
    • invalidation event が cache server に遅れて到着する可能性があるため
  • 一定時間（1分、3分、5分など）が過ぎると inconsistency アラートを送る
• metric
  • 直近 M 分間において、N nines に相当する cache write が整合しているかを示す 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 として把握できる