Uber、CacheFrontの改善で毎秒1億5000万回の読み取りを達成

原文リンク(2025-10-06)

Uber社のエンジニアは、CacheFrontアーキテクチャを更新し、毎秒1億5000万回以上の読み取りを可能にしつつ、より強力な一貫性を確保した。この更新により、レイテンシーに敏感なサービスでの古いデータの読み取り問題に対応し、新しいライトスルー一貫性プロトコルの導入、Docstoreとの緊密な連携、そしてUber社のFluxストリーミングシステムの改善により、増大する需要に対応する。

以前のCacheFront設計では、リクエストの重複排除と頻繁にアクセスされるキーをアプリケーションサービスの近くにキャッシュすることで、毎秒4000万回の高い読み取りスループットを達成していた。このモデルはスケーラビリティには効果的だったが、エンドツーエンドの一貫性が十分ではなく、最新データを必要とするワークロードには不十分だった。キャッシュの無効化は、タイムトゥリブ（TTL）と変更データキャプチャ（CDC）に依存しており、結果的な一貫性と更新の遅延した可視性をもたらしていた。この設計は特定の問題も引き起こしていた。例えば、読み取り後の書き込みの一貫性の問題では、読み取られた行がキャッシュされ、その後更新されても、無効化または期限切れになるまで古い値を提供し続ける可能性があった。また、ネガティブキャッシュ（「not-found」という結果を保存する）は、行が挿入された後でも誤ったミスを返す可能性があり、読み取り後の挿入の一貫性の問題でサービスロジックを破壊する可能性があった。

無効化のための以前のCacheFrontの読み取りおよび書き込みパス（出典：Uber Engineering Blog Post）

新しい実装では、ライトスルー一貫性プロトコルと、クエリエンジンとFlux（Uber社のストリーミング更新システム）の間に配置された重複排除レイヤーが導入された。各CacheFrontノードは、レスポンスを提供する前にDocstoreでデータの新鮮さを検証するようになった。ストレージエンジン層には、削除された行のためのトゥームストーンマーカーと、MySQLセッション割り当てのための厳密な単調タイムスタンプが含まれている。これらのメカニズムにより、システムは削除を含むすべての変更されたキーを効率的に特定し、コミット直前に読み戻せる。これにより、高負荷の下でも古いデータが提供されることはない。

改善されたCacheFrontの書き込みパスと無効化（出典：Uber Engineering Blog Post）

トランザクションが完了すると、ストレージエンジンはコミットタイムスタンプと影響を受けた行キーのセットを返す。これらのレスポンスに登録されたコールバックは、Redis内の以前にキャッシュされたエントリを無効化マーカーを書き込むことで即座に無効化する。FluxはMySQL バイナリログの追跡と非同期キャッシュフィルの実行をし続ける。これら3つのキャッシュポピュレーションメカニズム（クエリエンジンの直接更新、無効化マーカー、TTLの期限切れ）は、Fluxの追尾と組み合わせて、非常に高い読み取りスループットを維持しながら強力な一貫性を確保する。

Uber社のエンジニアPreetham Narayanareddy氏とEli Pozniansky氏は、改善の動機について説明した。

キャッシュヒット率の向上とより強力な一貫性保証への需要が増加していました。キャッシュの無効化にTTLとCDCを使用することによる結果的な一貫性は、いくつかのユースケースで制約となっていました。

Uber社のエンジニアは、この統合を通じて以前導入された専用APIを廃止・削除し、運用の複雑さを軽減し、システムを合理化できた。

Uber社のエンジニアは、キャッシュの健全性とリアルタイムbinlog追尾を監視するためのテレメトリとオブザーバビリティダッシュボードを強化した。キャッシュシャードは負荷を均等に分散するよう再編成された。Fluxと同じCDCパイプラインを基盤とするCache Inspectorツールは、binlogイベントをキャッシュに保存されたエントリと比較する。これらの更新により、テーブルのTTLは最大24時間まで延長され、キャッシュヒット率は99.9％以上に向上しつつ、低レイテンシを維持できる。