Uber社は、社内分散データベースDocstoreのために革新的なキャッシング・ソリューションCacheFrontを開発した。CacheFrontは、オンラインストレージから毎秒4000万件以上の読み取りを可能にし、P75レイテンシの75%削減、P99.9レイテンシの67%削減など、大幅なパフォーマンス向上を達成し、システム効率とスケーラビリティの向上に有効であることを実証した。
キャッシュとストレージエンジンのレイテンシ比較(出典)
UberのエンジニアであるPreetham Narayanareddy氏、Eli Pozniansky氏、Zurab Kutsia氏、Afshin Salek氏、Piyush Patel氏は、CacheFrontの開発を必要とした課題について説明している。
Uberのマイクロサービスのほとんどは、データを永続化するためにディスクベースのストレージに支えられたデータベースを使用しています。しかし、どのデータベースも、低レイテンシーの読み取りアクセスと高いスケーラビリティを必要とするアプリケーションを提供する上で課題に直面しています。
あるユースケースが、既存のどのユーザーよりもはるかに高い読み取りスループットを要求したとき、これは沸点に達しました。Docstoreは、低レイテンシーと高スループットを提供するNVMe SSDでバックアップされているため、彼らのニーズに対応することができました。しかし、上記のシナリオでDocstoreを使用することはコスト高になり、多くのスケーリングと運用上の課題があったことでしょう。
Uberのいくつかのチームは、Redisキャッシングを使用して読み取りアクセスを高速化し、これらの制限を回復した。しかし、各チームはそれぞれのサービス用に独自のRedisキャッシュをプロビジョニングし、維持しなければならない。また、そのユースケースに応じた無効化ロジックを実装する必要もあった。リージョンのフェイルオーバーでは、チームはキャッシュのレプリケーションを維持してホットな状態を維持するか、他のリージョンでキャッシュがウォームアップしている間、より高いレイテンシに悩まされるかのどちらかでなければならない。CacheFrontの目標の1つは、これらの機能を一元的に実装・管理し、チームがコアロジックに集中できるようにすることだった。
Uberは、以前のDocstoreバージョンとのAPIの互換性を維持しながら、ストレージエンジンとは別にRedisキャッシングを有効にして拡張することを望んでいたため、Docstoreのクエリエンジンに統合することにした。クエリエンジンは、MySQLベースのステートフルなストレージエンジンのフロントエンドとして動作するステートレスなコンポーネントである。
CacheFrontの設計(ソース)
CacheFrontはキャッシュされた読み取りを実装するためにキャッシュアサイド戦略を使用している。クエリエンジンは、1 つ以上の行に対する読み取り要求を取得する。キャッシュが有効な場合、Redisから行を取得し、ユーザーにレスポンスをストリームしようとする。残りの行があれば）ストレージエンジンから取得し、ユーザーにストリーミングしながら、残りの行を非同期にRedisに投入する。
Uberのエンジニアは、キャッシュの無効化を処理するために、Docstoreの統合された変更データキャプチャ（CDC）エンジンを活用した。CDCがDBの更新を特定するたびに、Redisの関連する行が更新または無効化される。その結果、Uberは、標準的なTTL（Time-to-Live）メカニズムを使用することで、数分ではなく、データベースの変更から数秒以内にキャッシュの一貫性を保つことができる。さらに、CDCを使用することで、コミットされていないトランザクションはキャッシュを汚染しない。
無効化のための CacheFront の読み取りおよび書き込みパス(ソース)
DBに対するキャッシュの一貫性レベルを測定するため、Uberのエンジニアはキャッシュへの読み取り要求をシャドウ表示する特別なモードを追加した。読み戻す際、キャッシュとデータベースのデータを比較し、同一であることを確認する。不一致はすべてログに記録され、メトリクスとして出力される。CDCベースのキャッシュ無効化を使って、キャッシュが99.99%一貫していることを測定した。
UberのDocstoreは、高い可用性とフォールトトレランスを確保するために、2つの地域にまたがるアクティブアクティブな展開で運用されている。しかし、この設定はCacheFrontにとって、特にフェイルオーバー時のキャッシュミスによるデータベース負荷の増加を防ぐために、両地域で「warm」キャッシュを維持することが課題となった。これに対処するため、UberのエンジニアはRedisの書き込みストリームをテールし、値ではなく行のキーをリモートリージョンにレプリケートした。リモートリージョンでは、レプリケーションエンジンがキャッシュミス時にストレージから最新の値を取得する。
キャッシュのウォーミングアップ（出典）
Uber社は、Redis操作に最適なタイムアウトを設定する際の課題を明らかにした。タイムアウトが短すぎると、リクエストの早期失敗や不必要なデータベース負荷につながる可能性がある。同時に、長すぎるタイムアウトは遅延にも悪影響を及ぼす可能性がある。Uberはこの問題に対処するためにアダプティブタイムアウトを実装し、パフォーマンスデータに基づいてRedis操作のタイムアウトを自動的かつ動的に調整できるようにした。
このアプローチにより、大半のリクエスト（99.99%）がキャッシュから迅速に処理され、動的に調整されたタイムアウトを超えた少数のリクエストを速やかにキャンセルしてデータベースにリダイレクトする仕組みが用意されているため、手動による調整を回避し、キャッシュ効率とデータベース負荷管理の両方を最適化することができる。