Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
到着予想時間サービスの特徴量のニアリアルタイム化
Search
Takashi Suzuki
May 31, 2023
Technology
0
150
到着予想時間サービスの特徴量のニアリアルタイム化
2023/5/31に実施されたGO TechTalkの登壇資料
Takashi Suzuki
May 31, 2023
Tweet
Share
More Decks by Takashi Suzuki
See All by Takashi Suzuki
Kubernetes超入門
t24kc
0
140
AI予約サービスのMLOps事例紹介
t24kc
0
25
MLプロジェクトのリリースフローを考える
t24kc
0
14
GOの機械学習システムを支えるMLOps事例紹介
t24kc
0
120
Optuna on Kubeflow Pipeline 分散ハイパラチューニング
t24kc
0
38
GOの実験環境について
t24kc
0
19
MOVの機械学習システムを支えるMLOps実践
t24kc
0
25
タクシー×AIを支えるKubernetesとAIデータパイプラインの信頼性の取り組みについて
t24kc
0
42
MOV お客さま探索ナビの GCP ML開発フローについて
t24kc
0
17
Other Decks in Technology
See All in Technology
履歴 on Rails: Bitemporal Data Modelで実現する履歴管理/history-on-rails-with-bitemporal-data-model
hypermkt
0
2k
生成AIで「お客様の声」を ストーリーに変える 新潮流「Generative ETL」
ishikawa_satoru
1
270
OpenAI gpt-oss ファインチューニング入門
kmotohas
2
840
What is BigQuery?
aizack_harks
0
120
“2件同時配達”の開発舞台裏 〜出前館PMが挑んだダブルピック実現に向けた体験設計〜
demaecan
0
180
Sidekiq その前に:Webアプリケーションにおける非同期ジョブ設計原則
morihirok
17
7k
[2025-09-30] Databricks Genie を利用した分析基盤とデータモデリングの IVRy の現在地
wxyzzz
0
440
いま注目しているデータエンジニアリングの論点
ikkimiyazaki
0
570
Railsアプリケーション開発者のためのブックガイド
takahashim
14
5.9k
コンテキストエンジニアリングとは? 考え方と応用方法
findy_eventslides
4
870
KAGのLT会 #8 - 東京リージョンでGAしたAmazon Q in QuickSightを使って、報告用の資料を作ってみた
0air
0
190
成長自己責任時代のあるきかた/How to navigate the era of personal responsibility for growth
kwappa
3
220
Featured
See All Featured
Distributed Sagas: A Protocol for Coordinating Microservices
caitiem20
333
22k
Building an army of robots
kneath
306
46k
Building a Modern Day E-commerce SEO Strategy
aleyda
43
7.7k
[RailsConf 2023] Rails as a piece of cake
palkan
57
5.9k
The Pragmatic Product Professional
lauravandoore
36
6.9k
The Success of Rails: Ensuring Growth for the Next 100 Years
eileencodes
46
7.6k
VelocityConf: Rendering Performance Case Studies
addyosmani
332
24k
Design and Strategy: How to Deal with People Who Don’t "Get" Design
morganepeng
132
19k
Writing Fast Ruby
sferik
629
62k
Product Roadmaps are Hard
iamctodd
PRO
54
11k
Keith and Marios Guide to Fast Websites
keithpitt
411
22k
Rails Girls Zürich Keynote
gr2m
95
14k
Transcript
© GO Inc. タクシーアプリ『GO』 データ基盤 全体像 1 2023.05.31 GO株式会社
© GO Inc. 2 タクシー配車アプリ 『GO』 乗る位置を指定 到着まで待つ 乗る! 支払い
キャッシュレスで素 早く降車 ※アプリ上で 決済 他、 車内で 現金決済にも対応
© GO Inc. 主要な『GO』分析データ基盤 3 GO動態ログ GOイベントログ (ユーザアプリ ) GCP
DBログ (Cloud SQL) AWS DBログ (Aurora) 外部データ (地図・天気など) データソース データパイプライン BigQuery RAWデータ データマート データ活用 BI・プロダクト分析 バッチ同期 ストリーミング (CDC) バッチ同期 (S3 -> GCS) バッチ同期 (BQ federated query) ストリーミング挿入 (Pub/Sub, Dataflow) ストリーミング挿入 (Pub/Sub, Dataflow) 加工パイプライン (Dataform) タクシー会社向け GOヘルプデスク GO施策運用 ・・ 緑 枠が主なチーム 担当領域 加工パイプライン (Dataform) データウェアハウス AIサービス
© GO Inc. 主要な『GO』分析データ基盤 4 今回話すコンテンツ GO動態ログ GOイベントログ (ユーザアプリ )
GCP DBログ (Cloud SQL) AWS DBログ (Aurora) 外部データ (地図・天気など) データソース データパイプライン BigQuery RAWデータ データマート データ活用 BI・プロダクト分析 バッチ同期 ストリーミング (CDC) バッチ同期 (S3 -> GCS) バッチ同期 (BQ federated query) ストリーミング挿入 (Pub/Sub, Dataflow) ストリーミング挿入 (Pub/Sub, Dataflow) 加工パイプライン (Dataform) タクシー会社向け GOヘルプデスク GO施策運用 加工パイプライン (Dataform) データウェアハウス AIサービス ・・ 車両位置情報データ 圧縮による Cloud Pub/Sub コスト削減(牧瀬) AWS Aurora S3 Export を利用した 負荷をかけない GCP BigQuery へ データ連携 (伊田) 到着予想時間( ETA)サービス 特徴量 ニアリアルタイム化(鈴木)
© GO Inc. 到着予想時間(ETA)サービス 特徴量 ニアリアルタイム化 5 2023.05.31 鈴木 隆史
GO株式会社
© GO Inc. 到着予想時間(Estimated Time of Arrival) 到着予想時間(ETA)と 6
© GO Inc. 7 ETA精度 事業影響度が大きい • 『GO』アプリ コア機能(配車依頼、予約機能など)として利用している •
アプリで表示している到着時間よりも遅着・早着 場合 ◦ UX 悪化、キャンセル率 増加 ◦ 特に大幅な遅着時 ネガティブ体験 • 遠方 車両を向かわせてしまった場合 ◦ 迎車時間が長くなることによる機会損失 到着予想時間(ETA) 精度 重要性
© GO Inc. 8 現状と課題
© GO Inc. アルゴリズム側 改善 • 経路探索 + MLモデル ハイブリッド構成へ変更(参考:
DeNA TechCon 2022 - あと何分?タク シーアプリ『GO』到着予測AI 社会実装まで -) • 通り過ぎ問題へ 対策(参考:GO Tech Blog - ETA(到着予想時間) 重要性と「通り過ぎ問題」へ 対策 -) システム側 改善 • リアルタイムな需要供給・道路状況 反映 ◦ 降雪など 突発的なイベントで 精度低下 改善 9 到着予想時間(ETA) 精度向上に向けた取り組み 本日話すテーマ 課題 ニアリアルタイム(30分ごと)に更新されるデータを用いて 機械学習モデルを更新する仕組みがない
© GO Inc. 従来ETA API コンポーネント 10 ユーザー 時刻・ 地理情報・
乗務員情報 など 入力値 お客様・ ドライバー 位置情報 入力値 経路探索 エンジン 経路探索結果 特徴量 ETA 推論モデル Amazon EKS 特徴量変換 時刻・乗務員 など 様々な特徴量 地図データ S3 地理統計値 乗務員情報 など 特徴量 数ヶ月ごと 更新 ワークフローエンジン Cloud Composer 1日ごと 更新 処理 リクエスト パラメータ データ 凡例
© GO Inc. 従来ETA API システム構成 11 地図データ 地理統計値 乗務員情報
など 特徴量 数ヶ月ごと 更新 1日ごと 更新 ワーカープロセス A グローバル変数 ワーカープロセス B グローバル変数 ワーカープロセス C グローバル変数 … … ワークフローエンジン Cloud Composer Amazon EKS S3 • REST API Podが起動する際に、各プロセス グローバル変数にデータをロードしている ワーカープロセス A ワーカープロセス B ワーカープロセス C …
© GO Inc. 従来APIシステム構成に30分更新 天気情報を追加しようとすると 12 地図データ 地理統計値 乗務員情報 など
特徴量 天気情報 など 特徴量 数ヶ月ごと 更新 1日ごと 更新 ワーカープロセス A グローバル変数 ワーカープロセス B グローバル変数 ワーカープロセス C グローバル変数 … 30分ごと 更新 ワークフローエンジン Cloud Composer S3 • 30分ごとに新しい特徴量データをロードするに 、再デプロイが必要なため現実的でない 30分単位でデータ更新したいが、 Podを再デプロイしないと グローバル変数が再読込されない ワーカープロセス A ワーカープロセス B ワーカープロセス C … 各プロセスごとにメモリ が割り当てられるため、 あるプロセスのグローバ ル変数を更新しても他プ ロセスには反映されない … Amazon EKS
© GO Inc. 13 解決策 検討
© GO Inc. 14 解決案 候補 実装方式 サービング方式 メリット デメリット
Vertex AI Feature Store 利用 オンラインサービング (少量 最新データを取得 ) * 低レイテンシ/低メモリ * 複数データソース (BigQuery/GCS)に対して統一 したI/Fで取得可能 * コンピュートコスト大 * バッチ処理と比較して高い バッチサービング (大量 定期更新データを取得 ) * 統一I/F * サーバーキャッシュに乗せるこ とで低レイテンシ * 高メモリ * リアルタイムデータ 参照 ができない 独自実装 オンラインサービング (少量 最新データを取得 ) (Redis開発想定) * 低レイテンシ/低メモリ * コンピュートコスト大 バッチサービング (大量 定期更新データを取得 ) (データ取得プロセス開発想定 ) * サーバーキャッシュに乗せること で低レイテンシ * 使用メモリ次第で低コスト * 現状 実装ベース * リアルタイムデータ 参照 ができない * 高メモリ
© GO Inc. 15 解決案 実験結果 実装方式 サービング方式 レイテンシ 使用メモリ
コンピュートコスト Vertex AI Feature Store 利用 オンラインサービング (少量 最新データを取得 ) 100-200 msec 数KB 1ノードあたり$700/month バッチサービング (大量 定期更新データを取得 ) 1-3 msec (サーバーキャッシュ利用時 ) 数1000 msec (通常参照時) 数10MB 軽微なストレージ料金 独自実装 オンラインサービング (少量 最新データを取得 ) (Redis開発想定) 5-10 msec 数KB M1(4GB) Standard 場合 $200/month バッチサービング (大量 定期更新データを取得 ) (データ取得プロセス開発想定 ) 1-3 msec (サーバーキャッシュ利用時 ) 100-200 msec (通常参照時) 数10MB Podに割り当てられたリ ソース 余剰部分で賄え る
© GO Inc. 今回 下記 理由でバッチサービング 独自実装を採用した • 既に特徴量 BigQueryで集約管理しているため、I/F共通化
恩恵が小さいこと • 特徴量データサイズが小さく、サーバーキャッシュに乗り切ること ◦ サーバーキャッシュに乗れ 、通信オーバーヘッドがない分オンラインサービング よりも高 に動作すること • 利用する特徴量 30分単位で更新できれ よく、バッチサービングで要件を満たせる こと • 現在 実装ベース まま開発できること 16 バッチサービング独自実装 選定理由
© GO Inc. 17 解決策 実現
© GO Inc. サービングプロセス 新構成 18 地図データ 地理統計値 乗務員情報 など
特徴量 天気情報 など 特徴量 数ヶ月ごと 更新 1日ごと 更新 ワーカープロセスA ワーカープロセスB ワーカープロセスC … … … 30分ごと 更新 ワークフローエンジン Cloud Composer サービング プロセス グローバル変数 データ参照 スレッド ユーザー S3 ワーカープロセスA ワーカープロセスB ワーカープロセスC サービング プロセス グローバル変数 データ参照 スレッド Amazon EKS …
© GO Inc. 19 サービングプロセス 実装例 multiprocessing.Managerを利用すると 複数プロセス間でデータを共有できる
© GO Inc. 20 データ更新スレッド 実装例 定期的なデータ再読込 バックグラウンドスレッド 追加 5分ごとにVolumeを再読込
© GO Inc. 特徴量 バージョン管理 • データ 後方互換性がなくなるタイミングでデータファイル バージョンを変更し、モデルで デー
タバージョンを指定して処理することで、新旧両方 データを扱える ◦ 例)features/1.1.0/realtime.csv.gz -> features/1.2.0/realtime.csv.gz ◦ モデルによって違うバージョン 特徴量を利用することが可能 ◦ 後方互換性がない更新が入っても、既存 パイプライン エラーにならない • バージョン更新時 デプロイ順番に 注意 ◦ 1. Cloud Composerで新しい特徴量データ デプロイ ◦ 2. APIで利用する特徴量バージョン 更新 ◦ こ 手順を踏むことで データフォーマット変更時 エラーを回避 21 運用上 考慮点
© GO Inc. 今回 ニアリアルタイム特徴量 提供に 、バッチサービング独自実装を採用 • オンラインサービングやFeature Storeを利用するメリットが小さかったため見送り
• オンラインサービングと比較して低レイテンシで特徴量を提供可能 • 複数プロセスを起動するAPIで 、サービングプロセスを利用して各プロセスでデータを共有 • 定期的なデータ更新スレッドを利用して、データ 再読み込み 特徴量管理 工夫 • バージョン管理を導入することで、モデルごとに違うバージョン 特徴量を利用可能 22 まとめ
文章・画像等 内容 無断転載及び複製等 行為 ご遠慮ください。 © GO Inc.