コンテンツに移動
データベース

Freestar が Memorystore を活用してグローバルなサービス提供のレイテンシを大幅に短縮

2023年9月20日
https://storage.googleapis.com/gweb-cloudblog-publish/images/global_2022_TxXQShm.max-2500x2500.jpg
Google Cloud Japan Team

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

本日は Freestar の事例を紹介します。Freestar の広告収益化プラットフォームは、業界屈指のプロダクトやソリューションにより、デジタル メディアのパブリッシャーやアプリ デベロッパーが広告収入を最大化できるよう支援しています。創業は 2015 年で、米国のインターネット ユーザーの 70% 以上に毎月リーチし、米国のインターネット リーチで上位 15 社にランクインしています。Freestar のエンジニアリング - アーキテクチャ担当バイス プレジデントの Vijaymohanan Pudukkudi 氏が、同社の広告テクノロジー プラットフォームのアーキテクチャの責任者を務めています。このブログ投稿では、Freestar が Memorystore をデプロイするにあたりマルチリージョンのクラスタ構成を採用し、レプリケーション促進のために Envoy プロキシを利用すると決めた経緯を Pudukkudi 氏に伺いました。

「Freestar は、その成長に伴い、グローバルな顧客ベースをサポートするようになりましたが、顧客はカスタマー エクスペリエンスと収益の両方の観点から、可能な限り低いレイテンシを求めています」と Pudukkudi 氏は述べます。「具体的に私たちが広告構成の配信で目指すのは、クライアントサイドではレイテンシが 90 パーセンタイルで 80 ミリ秒を下回ること、サーバーサイドではリクエストのラウンドトリップ時間が 95 パーセンタイルで 20 ミリ秒を下回ることです。」

Freestar は、グローバル展開の後、レイテンシの課題を抱えるようになりました。元々は、Google Cloud の US-Central リージョン内の単一のリージョンから広告構成を配信していました。このため、米国以外から構成にアクセスする顧客はレイテンシが長くなりました。解決策の一つとして、Google Cloud のコンテンツ配信ネットワーク(CDN)の使用が検討されましたが、構成の動的な性質には不適切とみなされました。私たちの意欲的な目標を達成するには、シングル リージョンを進化させる必要がありました。

https://storage.googleapis.com/gweb-cloudblog-publish/images/1_-_Single_Region_Architecture_-_V2.max-1300x1300.png

問題点

グローバル フットプリントの拡大に伴い、重要なサービス提供インフラストラクチャに関連して、リスク分析により大きな技術的懸念が指摘されました。Freestar のインフラストラクチャは、マルチリージョン設計に移行するまで US-Central リージョンに集中し、その中で複数のゾーンに分散されていました。このため、Google Kubernetes Engine でリージョン全体が停止する可能性がありました。その場合、サービスが完全に停止し、すべての顧客に影響があったはずです。

当社はまた、迅速な構成の検索に Google Cloud の Memorystore も利用しています。マルチリージョン構成に移行すると、US-Central リージョンの Memorystore クラスタにある構成を他のリージョンから読み取るときに追加のネットワーク オーバーヘッドが生じました。US-Central 以外のリージョンからサービスにアクセスするとき、95 パーセンタイルで 100~240 ミリ秒の追加レイテンシが観測されました。サービス全体のレイテンシは 80 ミリ秒のベンチマークから約 300 ミリ秒まで増えたはずです。このパフォーマンスが要件を満たしているシナリオも多いと思われますが、当社のユースケースの場合は満たしていませんでした。Google Cloud におけるリージョン間 / 大陸間のネットワーク レイテンシに関するデータは、一般に公開されている Looker Studio のレポートで確認できます。この問題への対処として、当社では Memorystore クラスタを複数リージョンに分散させることを決めました。

課題

現時点で Memorystore は、Google Cloud 内の複数リージョンへのレプリケーションを標準でサポートしていません。解決策の一つとして検討したのは、リージョンの API エンドポイントを個別に呼び出し、Memorystore キーの更新をトリガーするアプリケーション レベルのコードを作成することでした。しかし、このアプローチでは、複数の障害点が発生し、リージョン間で構成の一貫性が保たれない可能性がありました。一貫性が保たれないと、顧客の広告構成がすべてのリージョンで一貫し、必要に応じて更新されていることを確認するプロセスが必要となります。また、この選択肢には膨大な開発作業が求められます。このため、別のアプローチを探すことになりました。

ソリューション

最終的には、こちらのソリューション ブログに示されているように、Envoy プロキシでレプリケーションを促進することにしました。この戦略は、Memorystore インフラストラクチャで高スループットのアプリケーションとマルチリージョンのアクセス パターンを使用可能にするうえで不可欠でした。このアプローチを受けて、マルチリージョンの Memorystore クラスタ間で構成を複製し、一貫性を維持するソリューションを考案しました。

最初に、すべての書き込みオペレーションを各リージョン クラスタに反映させるよう Envoy プロキシを構成しました。このプロシージャは、US-Central リージョンのプライマリ Memorystore クラスタでイベントが発生するたびにトリガーされます。Envoy プロキシはサイドカー コンテナとして構成され、Memorystore の書き込みオペレーションを開始するマイクロサービスと並行して実行されます。

このアプローチは開発に必要な時間が最小限で済みました。アプリケーション コードで必要な変更は、Envoy プロキシのポートと IP アドレスを使用するよう Memorystore 構成を更新するだけだったからです。このケースでは、Envoy プロキシとして localhost を使用し、アプリケーションは同じ GKE Pod 内で実行されました。将来的には、このソリューションにより、アプリケーション コードを更新することなく、マルチリージョン クラスタのスケーリング機能が強化されるはずです。

Envoy プロキシのサイドカー構成

リモート クラスタ構成

このクラスタ構成(IMG A.2 を参照)は、リモート リージョンの Memorystore の IP アドレスとポートの詳細を定義しています。Envoy は、これを使用して仮想構成から実際の Memorystore クラスタを操作します。

https://storage.googleapis.com/gweb-cloudblog-publish/images/2_-_Script-Envoy_Config_Remote_Config.max-1000x1000.png

ローカル プロキシのクラスタ構成

次の構成(IMG A.3)は、Pod 内の Us-Central 仮想 / プロキシ構成で、サイドカーが動作しているので、書き込みコマンドを反映またはミラーリングできます。

https://storage.googleapis.com/gweb-cloudblog-publish/images/3_-_Script-Envoy_Config_Local_Config.max-800x800.png

Envoy プロキシのリスナー構成

Envoy リスナー(IMG A.4)は、アプリケーションからのトリガー、この例では Config Dispensary に基づきプロセスを開始します。アプリケーションから Memorystore へのインターフェースには、ローカルホストとポート 6379 を使用しています。この操作に続いて、システムは 'us_central1' リモート構成を使用し、コマンドを実際のクラスタに向けます。

構成をよく見ると、すべてのコマンドを別のローカル プロキシ クラスタにミラーリングするよう設定されたブロック構成があることがわかります。また、すべての読み取りオペレーションのミラーリングを防ぎ、そのようなアクションを制限するための除外構成があります。

https://storage.googleapis.com/gweb-cloudblog-publish/images/4_-_Script-Envoy_Config_Listener_Config.max-1100x1100.png

以下の図(IMG A.5)は実際の構成を示しています。Us-Central リージョン(プライマリ ロケーション)にあるアプリケーションがどのように Envoy プロキシを介して Memorystore を操作し、書き込みオペレーションを行うのかを表しています。

https://storage.googleapis.com/gweb-cloudblog-publish/images/5_-_Envoy_Proxy_Configuration_-_V2.max-800x800.png

以下のアーキテクチャ図(IMG A.6)は、各リージョンの Memorystore クラスタとマイクロサービスの通信を示しています。Us-Central リージョンを除き、マイクロサービスはプロキシなしで機能します。Us-Central では、プロキシがリージョン内の読み取り / 書き込みを管理し、書き込みを他のリージョンに分散します。

https://storage.googleapis.com/gweb-cloudblog-publish/images/6_-_Config_Dispensary__Envoy_Proxy_Archite.max-1100x1100.png

Envoy プロキシの完全な envoy.yaml と Dockerfile 構成は GitHub にあります。

以下のアーキテクチャ図(IMG A.7)は、マイクロサービス インフラストラクチャの全体像を示しています。Cloud Spanner、Cloud SQL、Datastore などのサービスを利用して、広告構成のプライマリ コピーを US-Central リージョンに格納しています。このプライマリ構成に変更があった場合は、US-Central リージョンで Memorystore が更新されます。この更新はその後、Envoy プロキシを介して、他のリージョンの Memorystore クラスタに反映されます。

https://storage.googleapis.com/gweb-cloudblog-publish/images/7_-_Comprehensive_view_of_Microservice_Inf.max-1300x1300.png

その後の状況: デプロイ後の分析

シングル リージョンの Redis クラスタからマルチリージョンの Memorystore Redis 構成に移行し、Envoy プロキシでレプリケーションを行うことで、レイテンシを大幅に短縮し、以前のシングル リージョン デプロイメントと同等のパフォーマンスを実現することができました。

書き込みのレプリケーションは、リージョン間でのデータ同期に 95 パーセンタイルで約 120 ミリ秒がかかりますが、読み込みが多いというシステムの性質上、書き込みオペレーションのレイテンシは無視してもよい程度です。

この構成を 2 か月前に導入してから、レプリケーションや Envoy プロキシの問題が発生したことはありません。アプリケーションは US-Central リージョンをメイン リージョンとして使用し、Envoy をすべての Memorystore オペレーションに使用しています。Memorystore はピーク時に 1 秒間に約 4 万件のリクエストを処理し、レイテンシは 95 パーセンタイルで 5 ミリ秒です。ピーク時には自社の Ad Config Service が 1 秒間に 1 万 5,000 件を超える API リクエストを効率的に処理しています。クライアントサイド(ウェブブラウザ)のレイテンシは 90 パーセンタイルで一貫して 80 ミリ秒を達成し、重要なサービスを複数のリージョンに拡張した後の目標達成に成功しました。

Google Cloud チームとのコラボレーションにより、複雑な課題から堅牢なソリューションを生み出すことができました。また、当社のシステムは Google Cloud チームによる入念な検証を経ているので、業界標準を満たしていると自信を持って言えます。こうして、Memorystore データをグローバルに複製する、信頼性に優れたソリューションが完成し、Google Cloud とのコラボレーションは大成功を収めました。

- Freestar、エンジニアリング - アーキテクチャ担当バイス プレジデント Vijay Pudukkudi
- Google Cloud、ソフトウェア エンジニア Dumanshu Goyal

投稿先