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

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

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

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

© GO Inc. 5 現状と課題

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

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

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

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

© GO Inc. 10 解決策の検討

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

© 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に割り当てられたリ ソースの余剰部分で賄え る

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

© GO Inc. 14 解決策の実現

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

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

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

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

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

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