BT

最新技術を追い求めるデベロッパのための情報コミュニティ

寄稿

Topics

地域を選ぶ

InfoQ ホームページ ニュース DoorDashはどのようにキャッシュをリアーキテクトし、スケーラビリティとパフォーマンスを向上させたか?

DoorDashはどのようにキャッシュをリアーキテクトし、スケーラビリティとパフォーマンスを向上させたか?

原文リンク(2023-10-28)

DoorDashは、すべてのマイクロサービスで使用していたヘテロ環境(相互接続・連携に保証のないハードウェアやソフトウェアを混在させて利用している状況のこと)のキャッシュシステムを再構築し、汎用的なメカニズムを提供する共通の多層キャッシュを作成した。

キャッシュは、高価な最適化を必要とせずにシステムのパフォーマンスを最適化するために使用される一般的なメカニズムである。ビジネスロジックの実装はパフォーマンスの最適化よりも優先順位が高いため、DoorDashの場合は特にこの点が重要だったと、DoorDashのエンジニアであるLev Neiman氏とJason Fan氏は説明する。

残念なことに、DoorDashのチームは各チーム毎に、CaffeineRedis Lettuce、HashMapsなど、異なるキャッシュシステムに依存していたため、キャッシュの陳腐化、Redisへの依存度の高さ、一貫性のないキースキーマなど、同じ問題を何度も経験しては、解決していた。このため、エンジニアのチームは、DoorDashの全マイクロサービス向けに共有キャッシング・ライブラリを作成することに着手した。まずは、トラフィック・レベルの増加によりスケーリング上の課題や障害が頻発していた主要サービスのDashPassから始めた。

最初のステップは、2つのKotlinインターフェースに基づく共通APIの定義だった。特定のキー・タイプとフォールバック・メソッド用に新しいキャッシュを作成するCacheManagerと、キー・タイプを抽象化するCacheKeyクラスだ。

これにより、ビジネス・ロジックからの統一されたキャッシュ呼び出しを維持しながら、依存性注入とポリモーフィズムを使用し、舞台裏で任意のロジックを注入ができます。

DoorDashのエンジニアは、キャッシュをシンプルに保つ試みをする一方で、パフォーマンス最適化の可能性をさらに押し広げるために、3つのレイヤーを持つ多層設計を選択した。リクエスト・ローカル・キャッシュと名付けられた最初のレイヤーでは、データはハッシュ・マップに置かれ、その有効期限はリクエストの有効期限に束縛される。2層目のローカルキャッシュでは、同じJava仮想マシン内のすべてのワーカー間でデータを共有するためにCaffeineが使われる。第3のレイヤーは、同じRedisクラスター内のすべてのポッドから見えるRedisキャッシュで、Redis Lettuceを使用する。

この多層キャッシュ・システムの重要な特徴とは個別のレイヤーごとに利用可能なランタイム制御であり、キャッシュのオン/オフ、キャッシュのタイム・トゥ・ライブ(TTL)の設定、またはシャドウ・モードを可能にする。このモードでは、キャッシュ・リクエストの所定の割合が信頼できる情報源とも比較される。さらに、キャッシュ・システムは、ヒットとミス、キャッシュ・レイテンシー、ロギングを含むメトリクスの収集をサポートした。

キャッシュシステムの準備が整い、DashPassで期待通りに機能するようになると、いつ、どのように使うか、あるいは使わないかについて明確なガイダンスを示しながら、組織の他の部分にも徐々に展開された。

Neiman氏とFan氏によると、新しいキャッシュシステムは、すべてのサービスにおいてスケーラビリティと安全性を向上させるとともに、パフォーマンスを向上させるために必要が生じた際、チームがキャッシュを採用するのをシンプルなものにしたという。

作者について

この記事に星をつける

おすすめ度
スタイル

BT