MoTLab -GO Inc. Engineering Blog-MoTLab -GO Inc. Engineering Blog-

GO TechTalk #19 タクシーアプリ『GO』事業成長を支えるデータ分析基盤の継続的改善!#goinc_tech_talk

techtalk
June 22, 2023

An image from Notion

2023年5月31日に「GO TechTalk #19 タクシーアプリ『GO』事業成長を支えるデータ分析基盤の継続的改善!」(connpass)を開催しました。

本記事では当日の内容を簡単に紹介します。


GO TechTalkとは?

GO TechTalkは、GO株式会社のエンジニアたちが、タクシーアプリ『GO』をはじめとしたサービスやプロダクトを開発する中で得た技術的ナレッジを共有するイベントです。

19回目となる今回は、大規模な車両データをリアルタイムに収集する基盤、AWS Auroraから負荷をかけることなくBigQueryにデータを集収する仕組み、そしてそのデータをAIサービスで活用する際のML基盤にフォーカスし、コスト削減やデータ連携について、そして実運用する上で直面した課題やその解決策について紹介しました。

こちらのツイートのスレッドで当日の様子や雰囲気を感じていただけると思います。

登壇者紹介

今回はこちらのメンバーが登壇しました。

  • ソフトウェアエンジニア:牧瀬 芳太郎
  • データエンジニア:伊田 正寿
  • MLOpsエンジニア:鈴木 隆史
  • 広報:高堂 和芽(@sandgirl_14

タクシーアプリ『GO』のデータ基盤の全体像

このパートでは、以降のパートの前提情報となるタクシーアプリ『GO』のデータ基盤の全体像を紹介しました。

どのようなデータをどのようなパイプラインで蓄積し、どのように活用しているかについて、主要な要素をピックアップして紹介しています。詳細はスライドやアーカイブ動画をご覧ください!

車両位置情報データの圧縮によるCloud Pub/Subのコスト削減

このパートでは1日9億レコードにもなる車両動態データを扱うコストを、データの特性に合った圧縮を行うことで削減した事例を紹介しました。

『GO』アプリの配車機能やさまざまなサービスで、タクシー車両の位置情報など数万台の車両から送られる車両動態データを活用しています。現在も1日9億レコードのデータを扱っていますが、提携タクシーの増加に伴って車両動態データの流量も増加しており、データ流量に応じてかかるコストの増加が課題になっていました。

これまでは車両動態データを1レコードずつProtobufからJSONにエンコードして、Pub/Sub・Dataflowに流していました。今回それをProtobufのまま複数のレコードをまとめてZstandardで圧縮し、それをPub/Subに流すように改修しました。

それによってデータサイズは約1/15となり、Pub/Sub、Dataflowの流量コストを93%削減できました。またエンコード/デコードの処理を高速化し、2000レコードのエンコード処理は43msから18msに改善、またCPU負荷も低下したのでマシンスペックも低く抑えられる副次効果も得られました。

技術選定の理由や実装時のポイントなど、詳細はぜひスライドやアーカイブ動画をご覧ください!

AWS Aurora S3 Export を利用した、負荷をかけない GCP BigQuery へのデータ連携

以前、CDC(Change Data Capture)を使ったデータ収集を試験導入した事例を紹介しました。

参考:タクシーアプリ『GO』大規模トラフィックを捌く分析データ基盤の全容に迫る!

当時、プライベートサブネットにあるAWS Auroraに穴を開けられない制約があるため、内部からプッシュするような方式にしていたのですが、この方式には以下のような運用負荷増加につながる課題がありました。

  • 障害復旧時の復旧手順が複雑
  • テーブルリネーム・カラムリネームが行われると、更新ログからレプリカを再現できない(別途対応が必要)
  • GCPだけでなくAWS側での構築、運用も発生する

このパートでは、上記の課題を解決するためにAurora S3 Exportを活用した方式に変更した取り組みを紹介しました。変更前後のアーキテクチャ、Aurora S3 Exportに関する知見、変更後に本番運用を開始した結果とその上での気付きも紹介しているので、スライドやアーカイブ動画もご覧ください。

到着予想時間(ETA)サービスの特徴量のニアリアルタイム化 - Feature Storeの技術選定 -

到着予想時間(ETA)は、『GO』アプリのコア機能(配車機能、予約機能など)として利用しています。アプリで表示している到着予想時間と実際の到着時間が大きくずれてしまうと、ネガティブなユーザー体験になってしまい、キャンセル率の増加に繋がるなど、事業に対する影響が大きい要素です。

このパートでは、突発的な雨や電車遅延などで需要供給が変化した際に機械学習モデルを更新するために、30分ごとに特徴量を提供する仕組みを実装した事例を紹介しました。

実装をVertex AI Feature Stroeを活用するか独自実装で進めるか、サービング方式をオンラインサービングにするかバッチサービングにするかを、レイテンシ、使用メモリ量、コンピュートコストの観点でメリット/デメリットを検討整理しました。その検討結果や実際に実装・運用した中で工夫した点なども紹介しているのでスライドやアーカイブ動画もご覧ください。

アーカイブ動画

今回非常に多くの質問や感想をいただきました。ありがとうございました。アーカイブ動画の中では以下の質問にもお答えしていますのでぜひ視聴いただければと思います。

  • 動態配信システムから直接Pub/Subにデータを送らずに中間ワーカーを挟んでいるのはなぜか?
  • AWSでETLをするツールとしてGlueもあるが、Glueは検討しなかったのか?
  • 天気以外にも到着時間に大きく関係する要素があると思うが、そういったデータの利用は検討しているか?

開催履歴・開催予定

GO TechTalk は不定期開催しています。過去の開催レポートは こちら にもありますので、ぜひご覧ください!

GO株式会社の最新技術情報は公式Twitterアカウント @goinc_techtalk で随時発信していきますので、ぜひフォローして続報をお待ちください!

We're Hiring!

📢
GO株式会社ではともに働くエンジニアを募集しています。

興味のある方は 採用ページ も見ていただけると嬉しいです。