到着予想時間（ETA）サービスの特徴量のニアリアルタイム化

GO TechTalk #19 タクシーアプリ『GO』事業成長を支えるデータ分析基盤の継続的改善！ で発表した資料です。

■ YouTube
https://www.youtube.com/live/sD8IpwoIkaw?feature=share&t=2696

■ connpass
https://jtx.connpass.com/event/282134/

Transcript

1. 到着予想時間（ETA）サービスの
   特徴量のニアリアルタイム化
   - Feature Storeの技術選定 -
   2023.05.31
   鈴木 隆史
   GO株式会社
   

   View Slide

2. © GO Inc. 2
   自己紹介
   GO株式会社
   MLOpsエンジニア / 鈴木 隆史
   複数の機械学習サービスの基盤やパイプラインの設計開発
   を担当
   最近はゼルダにハマり中
   

   View Slide

3. © GO Inc.
   到着予想時間（Estimated Time of Arrival）
   到着予想時間（ETA）とは
   3
   

   View Slide

4. © GO Inc. 4
   ETA精度は事業影響度が大きい
   ● 『GO』アプリのコア機能（配車依頼、予約機能など）として利用している
   ● アプリで表示している到着時間よりも遅着・早着の場合
   ○ UXの悪化、キャンセル率の増加
   ○ 特に大幅な遅着時のネガティブ体験
   ● 遠方の車両を向かわせてしまった場合
   ○ 迎車時間が長くなることによる機会損失
   到着予想時間（ETA）の精度の重要性
   

   View Slide

5. © GO Inc. 5
   現状と課題
   

   View Slide

6. © GO Inc.
   アルゴリズム側の改善
   ● 経路探索 + MLモデルのハイブリッド構成へ変更（参考：
   DeNA TechCon 2022 - あと何分？タク
   シーアプリ『GO』到着予測AIの社会実装まで -）
   ● 通り過ぎ問題への対策（参考：GO Tech Blog - ETA(到着予想時間)の重要性と「通り過ぎ問題」へ
   の対策 -）
   システム側の改善
   ● リアルタイムな需要供給・道路状況の反映
   ○ 降雪などの突発的なイベントでの精度低下の改善
   6
   到着予想時間（ETA）の精度向上に向けた取り組み
   本日話すテーマ
   課題
   ニアリアルタイム（30分ごと）に更新されるデータを用いて
   機械学習モデルを更新する仕組みがない
   

   View Slide

7. © GO Inc.
   従来ETA APIのコンポーネント
   7
   ユーザー
   時刻・
   地理情報・
   乗務員情報
   などの入力値
   お客様・
   ドライバー
   位置情報
   の入力値
   経路探索
   エンジン
   経路探索結果
   の特徴量
   ETA
   推論モデル
   Amazon EKS
   特徴量変換
   時刻・乗務員
   などの
   様々な特徴量
   地図データ
   S3
   地理統計値
   乗務員情報
   などの特徴量
   数ヶ月ごと
   の更新
   ワークフローエンジン
   Cloud Composer
   1日ごと
   の更新
   処理
   リクエスト
   パラメータ
   データ
   凡例
   

   View Slide

8. © GO Inc.
   従来ETA APIのシステム構成
   8
   地図データ
   地理統計値
   乗務員情報
   などの特徴量
   数ヶ月ごと
   の更新
   1日ごと
   の更新
   ワーカープロセス A
   グローバル変数
   ワーカープロセス B
   グローバル変数
   ワーカープロセス C
   グローバル変数
   …
   …
   ワークフローエンジン
   Cloud Composer
   Amazon EKS
   S3
   ● REST APIのPodが起動する際に、各プロセスのグローバル変数にデータをロードしている
   ワーカープロセス A
   ワーカープロセス B
   ワーカープロセス C
   …
   

   View Slide

9. © GO Inc.
   従来APIシステム構成に30分更新の天気情報を追加しようとすると
   9
   地図データ
   地理統計値
   乗務員情報
   などの特徴量
   天気情報
   などの特徴量
   数ヶ月ごと
   の更新
   1日ごと
   の更新
   ワーカープロセス A
   グローバル変数
   ワーカープロセス B
   グローバル変数
   ワーカープロセス C
   グローバル変数
   …
   30分ごと
   の更新
   ワークフローエンジン
   Cloud Composer
   S3
   ● 30分ごとに新しい特徴量データをロードするには、再デプロイが必要なため現実的でない
   30分単位でデータ更新したいが、
   Podを再デプロイしないと
   グローバル変数が再読込されない
   ワーカープロセス A
   ワーカープロセス B
   ワーカープロセス C
   …
   各プロセスごとにメモリ
   が割り当てられるため、
   あるプロセスのグローバ
   ル変数を更新しても他プ
   ロセスには反映されない
   …
   Amazon EKS
   

   View Slide

10. © GO Inc. 10
    解決策の検討
    

    View Slide

11. © GO Inc. 11
    解決案の候補
    実装方式 サービング方式 メリット デメリット
    Vertex AI
    Feature Store
    の利用
    オンラインサービング
    (少量の最新データを取得 )
    * 低レイテンシ/低メモリ
    * 複数データソース
    (BigQuery/GCS)に対して統一
    したI/Fで取得可能
    * コンピュートコスト大
    * バッチ処理と比較して高い
    バッチサービング
    (大量の定期更新データを取得
    )
    * 統一I/F
    * サーバーキャッシュに乗せるこ
    とで低レイテンシ
    * 高メモリ
    * リアルタイムデータの参照
    ができない
    独自実装 オンラインサービング
    (少量の最新データを取得 )
    (Redis開発想定)
    * 低レイテンシ/低メモリ * コンピュートコスト大
    バッチサービング
    (大量の定期更新データを取得
    )
    (データ取得プロセス開発想定
    )
    * サーバーキャッシュに乗せること
    で低レイテンシ
    * 使用メモリ次第で低コスト
    * 現状の実装ベース
    * リアルタイムデータの参照
    ができない
    * 高メモリ
    

    View Slide

12. © GO Inc. 12
    解決案の実験結果
    実装方式 サービング方式 レイテンシ 使用メモリ コンピュートコスト
    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に割り当てられたリ
    ソースの余剰部分で賄え
    る
    

    View Slide

13. © GO Inc.
    今回は下記の理由でバッチサービングの独自実装を採用した
    ● 既に特徴量はBigQueryで集約管理しているため、I/F共通化の恩恵が小さいこと
    ● 特徴量データサイズが小さく、サーバーキャッシュに乗り切ること
    ○ サーバーキャッシュに乗れば、通信オーバーヘッドがない分オンラインサービング
    よりも高速に動作すること
    ● 利用する特徴量は30分単位で更新できればよく、バッチサービングで要件を満たせる
    こと
    ● 現在の実装ベースのまま開発できること
    13
    バッチサービング独自実装の選定理由
    

    View Slide

14. © GO Inc. 14
    解決策の実現
    

    View Slide

15. © GO Inc.
    サービングプロセスの新構成
    15
    地図データ
    地理統計値
    乗務員情報
    などの特徴量
    天気情報
    などの特徴量
    数ヶ月ごと
    の更新
    1日ごと
    の更新
    ワーカープロセスA
    ワーカープロセスB
    ワーカープロセスC
    …
    …
    …
    30分ごと
    の更新
    ワークフローエンジン
    Cloud Composer
    サービング
    プロセス
    グローバル変数
    データ参照
    スレッド
    ユーザー
    S3
    ワーカープロセスA
    ワーカープロセスB
    ワーカープロセスC
    サービング
    プロセス
    グローバル変数
    データ参照
    スレッド
    Amazon EKS
    …
    

    View Slide

16. © GO Inc. 16
    サービングプロセスの実装例
    multiprocessing.Managerを利用すると
    複数プロセス間でデータを共有できる
    

    View Slide

17. © GO Inc. 17
    データ更新スレッドの実装例
    定期的なデータ再読込の
    バックグラウンドスレッドの追加
    5分ごとにVolumeを再読込
    

    View Slide

18. © GO Inc.
    特徴量のバージョン管理
    ● データの後方互換性がなくなるタイミングでデータファイルのバージョンを変更し、モデルではデー
    タバージョンを指定して処理することで、新旧両方のデータを扱える
    ○ 例）features/1.1.0/realtime.csv.gz -> features/1.2.0/realtime.csv.gz
    ○ モデルによって違うバージョンの特徴量を利用することが可能
    ○ 後方互換性がない更新が入っても、既存のパイプラインはエラーにならない
    ● バージョン更新時のデプロイ順番には注意
    ○ 1. Cloud Composerで新しい特徴量データのデプロイ
    ○ 2. APIで利用する特徴量バージョンの更新
    ○ この手順を踏むことで
    データフォーマット変更時のエラーを回避
    18
    運用上の考慮点
    

    View Slide

19. © GO Inc.
    今回のニアリアルタイム特徴量の提供には、バッチサービング独自実装を採用
    ● オンラインサービングやFeature Storeを利用するメリットが小さかったため見送り
    ● オンラインサービングと比較して低レイテンシで特徴量を提供可能
    ● 複数プロセスを起動するAPIでは、サービングプロセスを利用して各プロセスでデータを共有
    ● 定期的なデータ更新スレッドを利用して、データの再読み込み
    特徴量管理の工夫
    ● バージョン管理を導入することで、モデルごとに違うバージョンの特徴量を利用可能
    19
    まとめ
    

    View Slide

20. 文章・画像等の内容の無断転載及び複製等の行為はご遠慮ください。
    © GO Inc.
    

    View Slide