データベース

Waze、Memorystore で 1 秒あたり 100 万件以上のリアルタイム読み取りでトラフィックの流れを維持

2025年11月21日

https://storage.googleapis.com/gweb-cloudblog-publish/images/Waze-Memorystore-Hero.max-2500x2500.png

Eden Levin

Waze BE infra developer

Yuval Kamran

Waze SRE

Try Gemini 3

Our most intelligent model is now available on Vertex AI and Gemini Enterprise

Try now

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

編集者注: Google の親会社である Alphabet の一部門である Waze は、コアとなるナビゲーション機能を強化するために、膨大な量の動的なリアルタイムのユーザーセッションデータを活用しています。しかし、世界中の同時ユーザーをサポートするためにデータをスケーリングするには、新しいアプローチが必要でした。同社のチームは、次によって裏打ちされたセッションサーバーを構築しました：Memorystore for Redis Cluster は、99.99% の可用性を備えたフルマネージドサービスで、部分的な更新をサポートし、1 秒あたり 100 万件を超える MGET コマンドを約 1 ミリ秒のレイテンシで処理するという Waze のユースケースに合わせて簡単にスケーリングできます。このアーキテクチャは、Waze のバックエンドの継続的なモダナイゼーションの基盤となります。

リアルタイムデータが Waze アプリのエクスペリエンスを支えています。Google のターンバイターン方式のナビゲーション、事故によるルート変更、ドライバーへのアラートは、ミリ秒単位の精度に依存しています。しかし、数百万の同時セッションでシームレスなエクスペリエンスを維持するには、ユーザーセッションデータの膨大なストリームを管理するように構築された、堅牢で実戦に耐えるインフラストラクチャが必要です。これには、アクティブなナビゲーションルート、ユーザーの位置情報、ドライバーのレポートなどが含まれ、これらは数秒で表示され、変化する可能性があります。

一方舞台裏では、ユーザーセッションという頻繁に更新される大規模で複雑なオブジェクトがあり、非常に大量の読み取り / 書き込みオペレーションに寄与しています。セッションデータはかつて、モノリシックサービスにロックされ、単一のバックエンドインスタンスに緊密に結合されていました。そのため、スケーリングが難しく、他のマイクロサービスがリアルタイムのセッション状態にアクセスできませんでした。これをモダナイズするには、これらのセッションをリアルタイムで、またグローバル規模で処理できる、低レイテンシの共有ソリューションが必要でした。Memorystore for Redis Cluster でそれが可能になりました。

適切なルートの選択

Google では、マイクロサービスベースのバックエンドへの移行を計画するにあたり、Redis Enterprise Cloud、セルフマネージドの Redis クラスタ、Memorystore デプロイによる既存の Memcached の継続使用など、さまざまな選択肢を評価しました。従来のセットアップでは、Memcached はモノリシックなリアルタイム（RT）サーバーの背後にセッションデータを保存していましたが、求めていたレプリケーション、高度なデータ型、部分更新機能がありませんでした。Redis には必要な機能が備わっていることはわかっていましたが、自社で管理したり、サードパーティプロバイダを通じて管理したりすると、運用上のオーバーヘッドが増加します。

Memorystore for Redis Cluster は、両方の利点を兼ね備えています。Google Cloud のフルマネージドサービスである Cloud Spanner は、Waze のリアルタイムの需要を満たすパフォーマンス、スケーラビリティ、レジリエンスを備えています。これで 99.99% の SLA と、水平スケーリングのためのクラスタ化されたアーキテクチャが得られます。データベースの決定後、二重書き込みアプローチを使用して、Memcached から Memorystore for Redis への慎重な移行を計画しました。データパリティが確認されるまで、両方のシステムが並行して更新されました。その後、ダウンタイムなしで Redis に切り替えました。

Waze の新しいデータエンジン

そこから、Memorystore for Redis Cluster のラッパーとして、アクティブなユーザーセッションの新しいコマンドセンターである集中型セッションサーバーを構築しました。このサービスは、すべてのアクティブなユーザーセッションの信頼できる唯一の情報源となり、セッションデータとモノリシックな RT サーバー間の緊密な結合に代わるものとなりました。セッションサーバーはシンプルな gRPC API を公開するため、移行中の RT を含め、任意のバックエンドマイクロサービスがセッション状態を直接読み書きできます。これにより、クライアントアフィニティが不要になり、すべてのセッショントラフィックを単一のサービス経由でルーティングする必要がなくなり、プラットフォーム全体でセッションデータにアクセスできるようになりました。

Google は、レジリエンスとスケーラビリティを考慮してシステムをゼロから設計しました。Redis のクラスタリングとシャーディングにより、単一の競合ポイントが排除され、需要の増加に応じて水平方向にスケーリングできます。組み込みのレプリケーションと自動フェイルオーバーにより、セッションをオンラインに保つように設計されています。ノードの交換により、短期間だけ障害発生率とレイテンシが一時的に増加する可能性がありますが、セッションはオンライン状態を維持するように設計されているため、ナビゲーションエクスペリエンスはすぐに安定します。また、モバイルクライアントから任意のバックエンドサービスへの直接 gRPC 呼び出しをサポートすることで、より柔軟な設計パターンを使用しながら、リアルタイムパスから貴重なミリ秒を削減できます。

少ないピットストップで高速動作

Memcached の 99.9% の SLA から Memorystore for Redis Cluster の 99.99% に移行することで、サービスの可用性と復元性が向上します。負荷テストでは、新しいアーキテクチャが本番環境のトラフィック全体を維持できることが証明されました。1 秒あたり最大 100 万件の MGET コマンドのバーストを、1 ミリ秒未満の安定したサービスレイテンシで快適に処理できます。

Memorystore for Redis は部分的な更新をサポートしているため、レコード全体を書き換えるのではなく、セッションオブジェクト内の個々のフィールドを変更できます。これにより、ネットワークトラフィックが削減され、書き込みパフォーマンスが向上し、システム全体の効率が向上します。これは、セッションのサイズが数メガバイトにまで拡大する可能性がある場合に特に重要です。こうした効率化により、エンジニアリングチームはアプリケーションレベルのパフォーマンスと新機能の開発に注力する時間を増やすことができます。

Memorystore for Redis Cluster のセッションデータは、構成の評価からドライバーへのリアルタイム更新のトリガーまで、Waze のコア機能に不可欠なものとなっています。現在の需要に対応し、将来の需要にも対応できるように構築されています。

今後の展望

Waze の最も重要なパスの一つで Memorystore for Redis Cluster を実証したことで、プラットフォーム全体で他の高スループットキャッシュシナリオでも使用できるという自信が生まれました。一元化されたセッションサーバーとクラスタ化された Redis アーキテクチャは、現在ではバックエンドの標準的な構成要素となっており、ゼロから始めることなく新しいサービスに適用できます。

最初のクリティカルパスが完了したため、次の主な焦点は、残りのすべてのレガシーセッション管理を RT サーバーから移行することです。この結果、最終的にはすべてのマイクロサービスがセッションデータを更新するために独立してアクセスできるようになります。今後については、Memorystore for Redis Cluster をスケーリングして将来のユーザー増加に対応し、費用とパフォーマンスの両面で微調整することにも注力しています。