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
130
到着予想時間サービスの特徴量のニアリアルタイム化
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
130
AI予約サービスのMLOps事例紹介
t24kc
0
23
MLプロジェクトのリリースフローを考える
t24kc
0
13
GOの機械学習システムを支えるMLOps事例紹介
t24kc
0
110
Optuna on Kubeflow Pipeline 分散ハイパラチューニング
t24kc
0
32
GOの実験環境について
t24kc
0
18
MOVの機械学習システムを支えるMLOps実践
t24kc
0
20
タクシー×AIを支えるKubernetesとAIデータパイプラインの信頼性の取り組みについて
t24kc
0
38
MOV お客さま探索ナビの GCP ML開発フローについて
t24kc
0
15
Other Decks in Technology
See All in Technology
ビギナーであり続ける/beginning
ikuodanaka
2
280
本が全く読めなかった過去の自分へ
genshun9
0
710
強化されたAmazon Location Serviceによる新機能と開発者体験
dayjournal
3
260
Liquid Glass革新とSwiftUI/UIKit進化
fumiyasac0921
0
300
【5分でわかる】セーフィー エンジニア向け会社紹介
safie_recruit
0
26k
Lambda Web Adapterについて自分なりに理解してみた
smt7174
5
140
整頓のジレンマとの戦い〜Tidy First?で振り返る事業とキャリアの歩み〜/Fighting the tidiness dilemma〜Business and Career Milestones Reflected on in Tidy First?〜
bitkey
0
540
プロダクトエンジニアリング組織への歩み、その現在地 / Our journey to becoming a product engineering organization
hiro_torii
0
140
mrubyと micro-ROSが繋ぐロボットの世界
kishima
2
380
Tech-Verse 2025 Keynote
lycorptech_jp
PRO
0
1.3k
さくらのIaaS基盤のモニタリングとOpenTelemetry/OSC Hokkaido 2025
fujiwara3
2
260
Should Our Project Join the CNCF? (Japanese Recap)
whywaita
PRO
0
300
Featured
See All Featured
Faster Mobile Websites
deanohume
307
31k
KATA
mclloyd
30
14k
Testing 201, or: Great Expectations
jmmastey
42
7.6k
[RailsConf 2023] Rails as a piece of cake
palkan
55
5.6k
Writing Fast Ruby
sferik
628
62k
It's Worth the Effort
3n
185
28k
Building an army of robots
kneath
306
45k
YesSQL, Process and Tooling at Scale
rocio
173
14k
Git: the NoSQL Database
bkeepers
PRO
430
65k
The Language of Interfaces
destraynor
158
25k
The Cult of Friendly URLs
andyhume
79
6.5k
For a Future-Friendly Web
brad_frost
179
9.8k
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.