車両情報のリアルタイム特徴量基盤の構築

GO TechTalk #24 タクシーアプリ『GO』のAIサービスを支えるMLOpsを体感しよう！で発表した資料です。

■ YouTube
https://www.youtube.com/live/r_oYsac9Hvo?si=6fajvCDKzA-zQe3m&t=1514

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

Transcript

1. © GO Inc. 車両情報の リアルタイム特徴量基盤の構築 1 2023.12.05 鈴木 隆史 GO株式会社
2. © GO Inc. 鈴木 隆史 | Takashi Suzuki 開発本部 AI技術開発部 データプラットフォームグループ • 前職ではデータ基盤、ML基盤の開発に従事 • 現在は複数の機械学習サービスの基盤やなパイプラインの設計 開発を担当 2 自己紹介
3. © GO Inc. 3 タクシーアプリ 『GO』 乗車位置を指定 到着まで待つ タクシーに乗る ユーザの位置とタクシーの位置を把握し それらをマッチングさせる技術で成り立っている 料金を支払う
4. © GO Inc. 4 アルゴリズムの活用例 配車マッチング ETA(到着時間予測) マップマッチング 需給予測 経路最適化 強化学習、逆強化学習 隠れマルコフモデル カルマンフィルタ 時系列予測 統計モデリング 分位点回帰, 最短経路探索 最小重みマッチング 本日話すテーマ
5. © GO Inc. 7 2 5 配車マッチング処理の仕組み 各リクエストの配⾞候補⾞両を都度決定するのではなく、⼀定周期毎に複数のリク エストに対して配⾞候補⾞両を⼀括して決定することで、マッチングの全体最適を 実現している リクエストA リクエストB X Y Z 2 一番近い 4 10 A B X Y Z 8 4 10 3 リクエストごとの単純なマッチング 配車時間合計＝9分 一括での配車マッチング 配車時間合計＝7分 リクエストB Y Z 8 7 一番近い リクエストA X 決定済み
6. © GO Inc. 6 課題と改善策
7. © GO Inc. 7 課題 A B X W A B X W Z 現状は、処理が動いた時点のユーザ要求と空 車をマッチングさせている 空車が増えることが統計的に分かっている状況 であれば、少し待ってから近い車両とユーザを マッチングさせたい Y 数秒後
8. © GO Inc. これまでの配車マッチング処理フロー 8 マッチングエ ンジン 処理 凡例 A B X W ユーザーリクエスト 周辺の車両データ A B X W キュー t=1 t=2 Y Z A X B W Z Y ユーザーリクエスト 周辺の車両データ 遠い距離でマッチング してしまう マッチングエ ンジン リクエストがないためマッ チングしない 車両Y・Zが現れるも すでにマッチング済み
9. © GO Inc. 特徴量ストアを導入することで課題を解決 9 マッチングエ ンジン 処理 凡例 A B X W ユーザーリクエスト 周辺の車両データ A B X W キュー t=1 t=2 Y Z X W ユーザーリクエスト 周辺の車両データ 今回のマッチングは スキップしよう マッチングエ ンジン 特徴量ストア 数秒後に車両が増えそう A B X W A B Z Y 特徴量ストア A Y B Z 近い距離でマッチング
10. © GO Inc. 10 解決策の技術選定
11. © GO Inc. 11 『GO』のインフラ前提 • GCP管理：主にBigQueryに格納された分析データ、特徴量 • AWS管理：マッチングバッチ、直近の車両・リクエストなどの分析データ以外のリソース AWS Google Cloud 分析データ 統計値 特徴量 マッチングエ ンジン ユーザーリクエスト 周辺の車両データ 特徴量ストア これを作りたい
12. © GO Inc. 実装方式 メリット デメリット レイテンシ コンピュートコスト GCP Vertex AI Feature Store * 『GO』の特徴量はBigQueryで保 存しているため互換性が高い * 複数データソース (BigQuery/GCS)に対して統一し たI/Fで処理可能 * クラウドを跨ぐためネットワーク レイテンシ大 * コンピュートコスト大 100-200 msec 1ノードあたり $700/month AWS SageMaker Feature Store * AWSで特徴量を統合的に管理 可能 * コンピュートコスト大 * Redisと比較するとレイテンシ大 50 - 100 msec 広範囲エリアでの読 み書きのため $2000/month AWS Aurora * レイテンシ低め * keyでデータ取得するだけで要 件を満たせるため、SQLは必要な い 10-50 msec db.r6g.largeの場合 $550/month ElastiCache for Redis * 低レイテンシ * Feature Storeのメリットが受け られない（主にデータマネジメント・ 一貫性） 5-10 msec cache.m6g.large(6 GB)の場合 $140/month 12 解決案の候補と実験結果 採用
13. © GO Inc. 13 解決策の実現
14. © GO Inc. 特徴量ストアの構築 14 マッチング結果・配車確定結果を特徴量ストアに保存するパイプラインを新規構築 リアルタイム性の高いものはストリーミング挿入した特徴量を利用し、過去の統計値を利用したい場合は定 期的にバッチ挿入した特徴量を利用 マッチング エンジン A B Y X ユーザーリクエスト 周辺の車両データ 特徴量ストア Elasticache for Redis 分析データ 統計値 特徴量 ストリーミング 挿入 バッチ挿入
15. © GO Inc. 工夫点1：メモリ使用 チューニング 15 大量のデータを扱っているためメモリ使用量を減らす対策を実施 • 元々は地域メッシュ（最大33000エリア）x 2秒おきのマッチング x 20分間のデータを保持するため、単 純に実装すると2000万規模のキーが必要となる 対策として下記を検討し、サイズ削減効果の大きかったキー統合を実施 • キーの統合 ◦ 1分ごとにキーを統合し、データを加算保存する ◦ 直近N分の統計値を求める際は、過去データを集計して計算 ◦ 96%の削減効果 • encodingをjsonからmessage pack (※1) に変更 ◦ json置き換えと相性がよく、サイズも小さく高速 ◦ 40%の削減効果 ※1：message packについて https://msgpack.org/ja.html
16. © GO Inc. 1回のマッチングで大量のエリアの読み書きが発生する • キーが地域エリア毎に分かれているため、1回のマッチング処理ごとに最大1000エリア x 20分間の読 み込みと、1000エリアの書き込みが発生する • redisとはいえ、大量のネットワーク往復が発生するとネットワークボトルネックが発生 ◦ 書き込みはmsetを利用するとexpireを設定できないので、Redis pipeline (※1) を利用して複数 書き込みを実装 工夫点2：ネットワークレイテンシ チューニング 16 ※1：redis pipelineについて https://redis.io/docs/manual/pipelining/
17. © GO Inc. 今後の展望 17 交通情報や天気情報をもとにしたより高度な車両供給量予測を、特徴量ストアに格納し マッチングに利用していきたい マッチング エンジン A B Y X ユーザーリクエスト 周辺の車両データ 特徴量ストア 分析データ ストリーミング挿入 バッチ挿入 MLモデル 統計値 特徴量 推論値 交通情報や天気情報の 特徴量を利用して推論
18. © GO Inc. 直ぐにユーザと車両をマッチングするのではなく、あえて少し待つことでより最適 なマッチングができる • そのためにはリクエストや車両の統計値を格納する特徴量ストアが必要だったので、作る ことにした 今回の特徴量ストアの構築には、ElastiCache for Redisを採用 • 既存のFeature Storeと比較して、低レイテンシで特徴量を提供ができ、かつコストも 80-90%程度の削減ができている 特徴量ストアでRedisを利用する際の工夫 • メモリ使用量を減らす対策としてキー統合を実施 • 大量のエリアの読み書きが発生するため、Redis pipelineを利用 18 まとめ
19. 文章・画像等の内容の無断転載及び複製等の行為はご遠慮ください。 © GO Inc.