Snap、Google Cloud 上で KeyDB データベースを使用してレイテンシを 96 パーセント短縮

※この投稿は米国時間 2023 年 10 月 13 日に、Google Cloud blog に投稿されたものの抄訳です。

モダンなアプリケーションは高度に分散化が進み、マイクロサービスや API がマルチクラウドのような多数の異なる環境で実行されるケースが多くなっています。このアプローチには、レジリエンスやスケーラビリティなどを向上させて、チームの共同作業を加速するメリットがある一方で、レイテンシの面では懸念があります。この投稿では、Google Cloud コンサルティング（GCC）と Snap が共同で Snap の「ユーザー サービス」マイクロサービスのレイテンシを 96% 短縮し、最終的には、パフォーマンスを許容範囲内に維持しながらマルチクラウド環境でデータ分析を行えるようにした事例をご紹介します。

ソリューション

Snap はマルチクラウド アーキテクチャを採用しており、AWS DynamoDB や、Google Cloud Spanner、Firestore、Bigtable などのサービスを活用しながら、運用データベース ワークロードを AWS と Google Cloud の両方に分散させています。具体的には、AWS に運用データベース（DynamoDB）が、Google Cloud に分析用データベース（BigQuery）があります。しかし、これらの 2 つのシステム間のレイテンシが大きく、許容範囲を超える状況にありました。

この問題に対処するために、Snap はユーザーデータの取得用インターフェースを提供するマイクロサービスであるユーザー サービスを補強することにしました。具体的には、Google Kubernetes Engine（GKE）でホストされるユーザー サービスに加えて、Snap がもともと所有していた Redis に代わり、オープンソースの高速なインメモリ キャッシュ KeyDB を導入することにしました。

Google Cloud でホストされる KeyDB は、頻繁にリクエストされるデータをキャッシュ保存し、クラウド間の度重なる呼び出しを回避することによってレイテンシを最小限に抑えます。KeyDB の実装前は、Google Cloud の us-central1 リージョンと AWS の us-east-1 リージョン間の P99 レイテンシ平均値は 49～133 ms でした。Google Cloud に KeyDB を実装した結果、キャッシュ ヒットのレイテンシが大幅に短縮され、1.56～2.11 ms になりました。キャッシュ対象外のデータは、Dynamo データベースに格納されています。

データ取得の流れ

データ取得の流れは以下のとおりです。

1. Google Cloud の us-central1 リージョンにデプロイされたクライアント サービスが、同じく us-central1 リージョンにデプロイされたユーザー サービスを呼び出します。上の図の CachingSecondaryUserService が、Google Cloud 上に実装されたユーザー サービスです。
2. CachingSecondaryUserService は、KeyDB キャッシュからデータの取得を試みます。KeyDB は、Google Cloud の同じリージョン us-central1 内の別の GKE クラスタにデプロイされています。キャッシュに含まれるユーザーデータはキャッシュ ヒット（1b）に、見つからなかったユーザーデータはキャッシュミスになります。見つからなかったデータは AWS の us-east-1 リージョンにデプロイされているユーザー サービスから取得されます（1a のパス）。
3. CachingSecondaryUserService は、取得したデータをキャッシュにバックフィルします（2a）。この仕組みにより、その後のリクエストはキャッシュを「ヒット」するようになり、クラウド間のレイテンシが軽減されます。

キャッシュは以下の 2 つの方法で無効化されます。

1. KeyDB のキャッシュは、KeyDB の TTL 設定に基づき、24 時間ごとに無効化されます（3b）。
2. データの更新が必要になったときにトリガーされる SecondaryServiceCacheInvalidator によって無効化します（3a）。たとえば、Dynamo データベースに他のサービスからデータが書き込まれたときなどがこれに該当します。

結果

Snap の Grafana モニタリング ツールのスクリーンショットを以下に示します。これは、あるデータポイントにおけるキャッシュ ヒット パスのレイテンシを表しています。

左側のグラフは、KeyDB キャッシング ソリューション導入前の取得レイテンシの平均値で、50 ms をわずかに下回っている程度です。19:30 にキャッシュ ソリューションが実装され、最初の呼び出しの結果がキャッシュに格納されたあとの呼び出しはキャッシュ ヒットとなり、キャッシュからデータが取得されています。以下の表に結果をまとめました。

「Google の協力を得て Google Cloud に KeyDB を実装したことで、レイテンシの懸念が大幅に解消されました。これにより、今後の新製品を Google Cloud 上でデプロイするなど、チームにとって新たな道が開かれます」と、Snap のソフトウェア エンジニアリング マネージャーである Vinay Kola 氏は述べています。「このソリューションによって、クラウドに依存しない体制を保てるようになりました。また、これまでは、レイテンシや信頼性に関する懸念から、新しいアプリケーションを Google Cloud に導入することは不可能であるか、ボトルネックの発生が前提でしたが、こうした懸念が解消され、Google Cloud への導入が可能になりました。」

次のステップ

Google Cloud が、Snap のビジネス上の課題を見極め、この課題を解決し、Snap のマルチクラウド アーキテクチャに対応した技術的ソリューションを構築したことで、Snap は Google Cloud 上でデータ分析を拡充できるようにしました。Snap は現在、Google Cloud の他のリージョンからのデータアクセスにも、同様のアーキテクチャの構築を計画しています。より幅広いユーザー向けには、他のインメモリ データベース（Memorystore や Redis など）をキャッシング ストレージとして使用することが可能です。

アプリケーションのパフォーマンスを改善する方法をご検討中のお客様は、Google Cloud コンサルティングまでご相談ください。大小さまざまな規模の企業の目標達成を支援してきた実績をもつ Google Cloud が、クラウド インフラストラクチャの設計、構築、管理を支援いたします。

このブログ投稿を執筆するにあたって、テクニカル アカウント マネージャー Paul Valencia の協力を得ました。この場を借りて感謝を申し上げます。

-戦略的クラウド エンジニア Ilya Zelker

-戦略的クラウド エンジニア Ian McKee