コンテンツに移動
ネットワーキング

Uber の最新のエッジ: ネットワークのパフォーマンスと効率性に対する新しいアプローチ

2025年9月1日
https://storage.googleapis.com/gweb-cloudblog-publish/images/Uber.max-2500x2500.jpg
Noah Goldman

Staff Software Engineer, Uber

Gopinath Balakrishnan

Customer Engineer, Google Cloud

Try Gemini Enterprise Business Edition today

The front door to AI in the workplace

Try now

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

たとえば、リスボンで Uber を依頼したとします。しかし、配車が確定するまでに、リクエストがマドリード、ロンドン、バージニアを巡る観光ツアーのような経路をたどっています。Uber と Google Cloud が、グローバル エッジ ネットワークの仕組みを再設計するというさらに大きな取り組みを開始するまで、何百万人ものユーザーがこのような状況に直面していました。

6 大陸で事業を展開する Uber は、数百万人の乗客と運転手を結び付け、10 万件を超える同時乗車と 1 秒あたり 100 万件を超える HTTP リクエストを処理しています。

この規模では、1 ミリ秒であっても重要になります。Uber の既存のエッジ アーキテクチャでは、ルーティング経路が最適化されていなかったため、同社は Google Cloud と提携してグローバル ネットワーク アプローチを再設計しました。その結果、レイテンシが大幅に改善され、数百万ドルの費用が削減されました。

課題: 最適とは言えないルーティング、運用上のオーバーヘッドを伴う非効率的なアーキテクチャ

Uber の以前の Google Cloud エッジでは、16 リージョンにわたる仮想マシン上で実行されるオープンソースの Envoy プロキシ インスタンスを使用していました。このアーキテクチャは、サービスをユーザーに近づけてレイテンシを短縮するように設計されていますが、Uber のデータセンターに到達する前に、さまざまなリージョンを通過する複数の不要なホップを含む、最適とは言えないルーティング経路が作成されることがよくありました。ネットワーク トランジットが追加されたことでレイテンシが増加し、Uber の顧客が期待する利便性が低下しました。

https://storage.googleapis.com/gweb-cloudblog-publish/images/image4_o84ENek.max-1900x1900.png

従来の Uber エッジと GCP のトラフィック フロー

この設定にはいくつかの課題がありました。

  • 運用の複雑さ: 大規模な仮想マシン(VM)フリートの管理とオーケストレーションは煩雑で、Uber の社内標準から逸脱していました。
  • レイテンシの収穫逓減: 当初の想定とは異なり、Envoy を多数のグローバル リージョンで実行しても、すべてのユーザーのレイテンシが常に改善されるわけではありませんでした。実際に、一部のユーザーにおいては、不要なネットワーク ホップが発生していました。
  • 高い運用コスト: 大規模でグローバルに分散したインフラストラクチャの維持には、多額の費用がかかっていました。

解決策: ハイブリッド NEG を使用したダイレクト ルーティング

目標は単純で、オンプレミスとさまざまなクラウド環境にわたって、ユーザーから Uber のバックエンド サービスへの最も直接的な経路を作成することでした。このアプローチでは、分散された Envoy VM から離れ、代わりに Google Cloud のハイブリッド ネットワーク エンドポイント グループ(NEG)を使用しました。

https://storage.googleapis.com/gweb-cloudblog-publish/images/2_Z24QX7X.max-1100x1100.png

簡素化/最新化された Uber エッジと GCP のトラフィック フロー

Uber と Google のエンジニアが 10 か月間共同で開発したこの新しいアーキテクチャでは、Google のグローバル外部アプリケーション ロードバランサからのトラフィックが、Cloud Interconnect を介して Uber のオンプレミス インフラストラクチャに直接転送されます。このロードバランサは、DDoS からの保護に Google Cloud Armor を、キャッシュの保存に Cloud CDN を使用しています。

ハイブリッド NEG ベースのロードバランサへの移行の結果はすぐに表れました。すべてのエッジ VM を削除したことで、トラフィックの経路が大幅に効率的なものになり、Google のグローバル ネットワークが最適化されたチャネルを介して長距離の転送を処理できるようになりました。この移行により、レイテンシが 50 パーセンタイルで 2.6%、99 パーセンタイルで 10% 改善され、サービスの応答性の向上に直接寄与しました。

結果: 大きな改善

移行により、3 つの主要分野で大幅な改善が実現しました。設計を検証し、エッジ トラフィックの 99% を移行した後、プロジェクトは次の成果を達成しました。

  • 大幅な費用削減: エッジ Envoy VM のフリート全体を削除したことで、費用が大幅に削減されました。
  • パフォーマンスとユーザー エクスペリエンスの向上: トラフィック フローの合理化により、Uber のモバイルアプリ ユーザーのレイテンシが p50 で 2.6%、p99 で 10% 改善しました。
  • 運用の簡素化: エッジ VM を廃止することで、運用上のオーバーヘッドが削減され、より標準化されたツールによって信頼性が向上しました。

「Uber では、ミリ秒単位で何百万人ものお客様のユーザー エクスペリエンスが決まります。Google Cloud とハイブリッド NEG を使用してグローバル エッジを再設計することで、サービス用のより直接的で低レイテンシの経路を作成しました。これにより、現在のユーザー エクスペリエンスが向上するだけでなく、次世代の AI アプリケーションに必要な高性能基盤が用意され、エンジニアリング チームの運用オーバーヘッドも大幅に削減されます。」- Uber、ネットワーキング担当ディレクター、Harry Liu 氏

企業チーム向けの重要なポイント

Uber のエッジ アーキテクチャの変革は、技術的なコラボレーションに注力することで何が達成できるかを示しています。分散された Envoy VM フリートを、Google のグローバル ネットワークとハイブリッド NEG を使用した合理化されたアーキテクチャに置き換えることで、Uber はパフォーマンス、コスト、信頼性において大幅な改善を遂げました。

Uber と Google のエンジニアが緊密に連携したことで、1 年足らずで移行が成功しました。主な成功要因は次のとおりです。

  • アーキテクチャの検証: Google のロードバランサ アーキテクチャに関する分析情報により、プロキシのロケーションを減らすことでパフォーマンスの向上と運用オーバーヘッドの削減が実現することが検証されました。
  • パフォーマンス モデリング: Google のエンジニアは、Uber の初期テストから本番環境規模の結果をモデル化し、ベンチマーク時間を節約して、続行する自信を与えました。
  • 設計の簡素化: ハイブリッド NEG により、Google エッジで Envoy プロキシ VM が不要になりました。

-Uber、スタッフ ソフトウェア エンジニア、Noah Goldman 氏

-Google Cloud、カスタマー エンジニア、Gopinath Balakrishnan

投稿先