Upgrade to Pro — share decks privately, control downloads, hide ads and more …

MoT TechTalk #16 5万台のドラレコを活用!大規模データ収集・機械学習基盤の全容

GO Inc. dev
February 20, 2023

MoT TechTalk #16 5万台のドラレコを活用!大規模データ収集・機械学習基盤の全容

■ 内容
・ドラレコデータから道路情報の差分を見つけるシステムの仕組みと特徴(松浦)p. 3~
・契約車両5万台超のドラレコデータを収集する現実解(鳩) p. 20~
・AWS Batchを用いた画像処理の分散実行(高山) p. 41~

■ YouTube
https://www.youtube.com/watch?v=0SF9BZlcT5c&t=180s

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

GO Inc. dev

February 20, 2023
Tweet

More Decks by GO Inc. dev

Other Decks in Technology

Transcript

  1. © Mobility Technologies Co., Ltd. 2 ⽬次 • ドラレコデータから道路情報の差分を⾒つけるシステムの仕組みと 特徴(松浦)

    p. 3~ • 契約⾞両5万台超のドラレコデータを収集する現実解(鳩) p. 20~ • AWS Batchを⽤いた画像処理の分散実⾏(⾼⼭) p. 41~
  2. © Mobility Technologies Co., Ltd. 4 ⾃⼰紹介 プロフィール写真 株式会社Mobility Technologies(MoT)

    シニアデータエンジニア / 松浦 慎平 Web地図サービス提供企業、GISソフトウェアベンダー、⾃動 運転サービス提供企業で GIS エンジニアとして従事 現在は道路情報の⾃動差分抽出プロジェクトで GIS チョットデ キル データエンジニアとして活躍︖中 @PEmugi2
  3. © Mobility Technologies Co., Ltd. 6 DRIVE CHART 次世代AIドラレコサービス 通信型ドライブレコーダーとAIで

    ⾃覚しづらい危険シーンを解析し、効率的な運⾏管理と事故の削減に貢献 契約台数5万台以上のタクシー・トラック・営業⾞両で展開
  4. © Mobility Technologies Co., Ltd. 7 ⾃動運転時代の地図に求められること 課題 • ⾃動運転社会では、更新頻度の⾼い地図が求められる

    • 更新頻度を上げるには更新作業の効率化が必要 解決策 • DRIVE CHARTを搭載した⾞両から⾞外映像とセンサー情報を収集 • 収集した情報から標識等の道路情報を検出し、地図と⽐較して現地との差分を ⾒つけ地図を更新する ゼンリン社と共同開発
  5. © Mobility Technologies Co., Ltd. 8 現地と地図の差分を抽出する流れ 地図DB API センサー情報

    ドラレコ画像 ⾞両位置の推定 道路上の物体を検出 物体位置の推定 現地の道路情報 DIFF 地図情報 現地と地図の差分 削除 追加 存在確認 道路ネットワークデータ 背景地図 © OpenStreetMap Contributors GPSや加速度、⾓速度
  6. © Mobility Technologies Co., Ltd. 9 要素技術1/3: マップマッチングで⾞両位置を推定 地図上では道路情報は道路ネットワークに紐付いて管理されている 「どの道路を⾛っているときにみつけたのか︖」が⼤事

    GPSで得られる誤差を含む位置を道路ネットワークに対応させる 実際に⾛⾏した位置 GPSで記録された位置 マップマッチングした位置 道路ネットワーク
  7. © Mobility Technologies Co., Ltd. 10 要素技術2/3: 機械学習とCV技術で道路情報を検出 レーン検出 標識検出

    機械学習による物体検出 三⾓測量による物体の位置推定 VSLAMによる⾃⾞位置推定 物体位置の推定 詳しくはMoT TechTalk #11で紹介しています! (https://jtx.connpass.com/event/241709/)
  8. © Mobility Technologies Co., Ltd. 11 要素技術3/3: 地理空間情報技術を⽤いた差分抽出 地理空間情報の可視化によるデバッグ 利⽤ケース例

    • ⾛⾏した道路から100m以内にある地図上の標識の検索 • 地図上の標識と検出した標識の距離を計算 • 複数回の⾛⾏により検出された標識を空間クラスタリング し同⼀と思われる標識をグルーピング 差分抽出では⾒つけた道路情報と地図上の道路情報の位置関係が重要 可視化⼿法についてはFOSS4G 2022 Japan Onlineで紹介しました! https://www.osgeo.jp/events/foss4g-2022/foss4g-2022-japan-online/foss4g-japan-2022- online-core-day#presentation5 SQLによる空間情報の操作 背景地図 © OpenStreetMap Contributors
  9. © Mobility Technologies Co., Ltd. 13 システム構成図 DRIVE CHART センサー収

    集 マップ マッチ 処理対象⾛ ⾏計算 ⾞両位置格 納 タスク作成 タスク 動画リクエ スト 動画格納 ⾞両 位置 動画 物体検出 物体位置推 定 差分判定 認識 物体 地図 AWS Batch AWS Batch Aurora PostgreSQL Aurora PostgreSQL Aurora PostgreSQL Lambda / ECS / Batch S3 ⾛⾏収集 動画収集 認識 差分判定 モジュール データと処理の流れ タスクの状態管理 The Go gopher was designed by Renee French. (http://reneefrench.blogspot.com/) The design is licensed under the Creative Commons 3.0 Attributions license
  10. © Mobility Technologies Co., Ltd. 14 特徴1/4: バッチ処理を採⽤ 各モジュールはバッチ処理で実⾏される 理由

    • 要件 ◦ 定められた調査期間内で、収集した⾛⾏・動画データを対象に、期間に1度差分を抽出す ればよい • 性能 / 処理効率 ◦ 差分結果の精度を⾼める⽬的で、1つの道路に対して複数回の⾛⾏結果を収集し差分を抽 出する仕組み ◦ コンピューティングリソースを効率的に使⽤するためにまとまった単位で処理したい
  11. © Mobility Technologies Co., Ltd. 15 特徴2/4: ワークフロー管理 「タスク」という実⾏単位を定義し、各モジュールの実⾏状態を管理する仕組みを独⾃ に実装

    タスクとは • ⾛⾏を処理に適した⻑さ「5分」で区切った最⼩の実⾏単位で、各モジュールの実⾏状態が記録される • タスクに⼊⼒データと各モジュールの出⼒が紐づく • 各モジュールは実⾏可能なタスクを検索→実⾏するので任意のタイミングでスケジュールできる task_id 動画収集STATUS 認識STATUS 差分判定STATUS 1 完了 実⾏中 実⾏待ち 2 完了 完了 完了 ⾞両位置 ⾞両位置 Task 1 Task 2 検出した道路情報 検出した道路情報 地図との差分 タスク管理テーブル例
  12. © Mobility Technologies Co., Ltd. 16 特徴3/4: AWSのサービス選定 コンピューティングサービスの選定基準 •

    バッチ処理を実⾏する環境の選定 ◦ AWS Lambda ▪ 15分以内で完了する処理 ▪ AWS Lambdaの標準ランタイム内で実⾏可 能な単純な処理 ◦ AWS Batch ▪ GPUが必要な処理 ▪ カスタムコンテナが必要な複雑な処理 ▪ 15分以内で終わらない処理 ◦ Amazon ECS ▪ サービスとして常時起動し処理したほうが効 率が良い場合 ▪ 例: マップマッチング データベースサービスの選定基準 Amazon Aurora を採⽤! PostgreSQLを採⽤する理由 • 地図データはリレーショナルモデル • タスクの状態管理や各モジュールのDBMSに対する 主なワークロードはトランザクション処理 • ⾼度な地理空間クエリを使⽤する Auroraを採⽤する理由 • パフォーマンス、可⽤性、耐久性の観点で Auroraを使わない理由がない
  13. © Mobility Technologies Co., Ltd. 17 特徴4/4: AWS CDKによるInfrastructure as

    Code プロジェクトで使⽤しているAWSリソースのすべてをTypeScriptで定義! AWS CDKとは︖ • プログラミング⾔語でAWSリソソースを定義しデプロイできる仕組み • 各⾔語に対応したCDKライブラリとコマンドラインツール提供される • CloudFormationのStackとしてデプロイされる 導⼊してよかったこと • 学習コストが低い! ライブラリが提供され、IDEでの補完も効き、何よりTypeScriptで記述できるので、CloudFormationやTerraformの書式を覚えるよ り楽 • 効率がいい 関数やクラス定義による処理の共通化やループや条件分岐が使⽤できるので効率よく複雑なインフラを記述できる。レビューもし やすい。 CDKについてMoT Labでも紹介していますので御覧ください︕(https://lab.mo-t.com/blog/not-terraform-but-cdk)
  14. © Mobility Technologies Co., Ltd. 19 まとめ • プロジェクト概要 ◦

    DRIVE CHARTから取得できるタクシーやトラックの情報から道路情報を検出し、地図の更新情報を地図会社 に提供 • 要素技術 ◦ マップマッチングによって⾛⾏している道路を特定 ◦ 機械学習とCV技術を使⽤して道路上の物体の検出と位置を推定 ◦ 検出した道路情報と地図上の情報を位置関係を元に⽐較するために地理空間情報技術を使⽤ • システム構成 ◦ AWS上にバッチとして動作するモジュールで構成されたデータパイプラインを構築 ◦ タスクという実⾏単位を導⼊し各モジュールの実⾏状態を管理 ◦ AWSサービスの選定 ▪ バッチ実⾏環境としてAWS Batch、AWS Lambda、AmazonECSをタスクに応じて選択して使⽤ ▪ データベースはAurora PostgreSQL + PostGISを選定 ◦ AWS CDKとTypeScriptでAWSリソースをコードで管理
  15. © Mobility Technologies Co., Ltd. 21 ⾃⼰紹介 プロフィール写真 株式会社Mobility Technologies(MoT)

    データエンジニア / 鳩 英嗣 Webシステムのインフラ管理業務に携わったのち、データ分析 基盤の開発運⽤に従事。現在はMoTにてドラレコデータ収集基 盤の開発を担当。 最近、学⽣の頃弾いていたチェロを再開しました。 リモートワークのお昼休みに基礎練してます。
  16. © Mobility Technologies Co., Ltd. 22 アジェンダ 1. 概要 2.

    ⾞両位置収集 3. 動画収集 4. まとめと今後の展望
  17. © Mobility Technologies Co., Ltd. 26 ⾞両位置収集 DRIVE CHART センサー収

    集 マップ マッチ 処理対象⾛ ⾏計算 ⾞両位置格 納 タスク 動画リクエ スト 動画格納 ⾞両 位置 動画 物体検出 物体位置推 定 差分判定 認識 物体 地図 AWS Batch AWS Batch Aurora PostgreSQL Aurora PostgreSQL Aurora PostgreSQL Lambda / ECS / Batch S3 ⾛⾏収集 動画収集 認識 差分判定 モジュール データと処理の流れ タスクの状態管理 The Go gopher was designed by Renee French. (http://reneefrench.blogspot.com/) The design is licensed under the Creative Commons 3.0 Attributions license
  18. © Mobility Technologies Co., Ltd. 27 ⾞両位置収集システム構成図 センサー収 集 マップ

    マッチ 処理対象⾛ ⾏計算 ⾞両位置格 納 地図 Aurora PostgreSQL S3 モバイル 回線 1分単位でアップロード センサー収集 システム ECS S3 BigQuery Lambda / ECS / Batch ⾛⾏収集 データアップロードシステム ファイル特定 取得 保存 参照 道路毎の ⾛⾏履歴 センサー ファイル The Go gopher was designed by Renee French. (http://reneefrench.blogspot.com/) The design is licensed under the Creative Commons 3.0 Attributions license GPS,加速度,⾓速度など 0.1秒単位 ⾞両位置
  19. © Mobility Technologies Co., Ltd. 28 処理対象⾛⾏計算 - 収集対象エリアに絞り込む •

    全ての⾞両位置を収集すると無駄が多い • 事前に定義した収集対象エリア範囲の⾞両位置のみ蓄積出来るよう、地理 空間クエリなどを駆使し絞り込んでいる ー 対象エリア ー エンジンONからOFFまでの⾞両位置 収集対象エリア外の⾞両位置
  20. © Mobility Technologies Co., Ltd. 汚いデータを不採⽤にする • ⾛⾏が途切れている場合 • 駐⾞場から出るなどして道路を端から端まで⾛りきってない場合

    • GPSの特性上誤差が⽣じ、時速300kmなど現実的な⾞速に収まっていない場合 29 処理対象⾛⾏計算 - データクレンジング 道路 駐⾞場 © OpenStreetMap contributors
  21. © Mobility Technologies Co., Ltd. 31 動画収集 DRIVE CHART センサー収

    集 マップ マッチ 処理対象⾛ ⾏計算 ⾞両位置格 納 タスク 動画リクエ スト 動画格納 ⾞両 位置 動画 物体検出 物体位置推 定 差分判定 認識 物体 地図 AWS Batch AWS Batch Aurora PostgreSQL Aurora PostgreSQL Aurora PostgreSQL Lambda / ECS / Batch S3 ⾛⾏収集 動画収集 認識 差分判定 モジュール データと処理の流れ タスクの状態管理 The Go gopher was designed by Renee French. (http://reneefrench.blogspot.com/) The design is licensed under the Creative Commons 3.0 Attributions license
  22. © Mobility Technologies Co., Ltd. リクエストした動画を⾮同期でアップロードする 32 動画収集システム構成図 S3 ②リクエスト

    動画収集 システム ECS 動画 ストレージ S3 動画リクエ スト 動画格納 動画収集 動画 データアップロードシステム ③アップロード ①リクエスト ④保存 SQS ⑤完了通知 ⑥取得 ⑦コピー モバイル回線 The Go gopher was designed by Renee French. (http://reneefrench.blogspot.com/) The design is licensed under the Creative Commons 3.0 Attributions license
  23. © Mobility Technologies Co., Ltd. 33 要件 • 出来るだけ多くの画像を⽤いて物体検出率を⾼めたい ◦

    オクルージョン(他の物体で⾒えない)や逆光が発⽣すると正しく物体検出 できないため • ⼀時的な標識を除外したい ◦ 1⽇しか⽴たないような⼯事の標識を変化として捉えないようにするため • 予算内に収める
  24. © Mobility Technologies Co., Ltd. 34 制約 • 同時にアップロード出来る動画量に限度がある ◦

    通信キャリア回線全体の負荷回避のため • デバイス⼀台あたりでアップロード出来る動画量に限度がある ◦ DRIVE CHARTサービスに影響が出ないようにするため ◦ → 取得するデバイスをばらして⼀台からアップロードする量を少なくする必 要がある • 数⽇前の動画はアップロード出来ない ◦ SDカードに映像が常時記録されていき、古い動画ファイルから上書きされ消 えていくため
  25. © Mobility Technologies Co., Ltd. 35 まず全部取ることを考えてみたが・・・ • とても予算内には収まらなかった ◦

    モバイル回線でアップロードするため通信量に応じて従量課⾦される 1ヶ⽉のアップロードコスト推定 エリア 動画サイズ推計 コスト推計(※) 京浜地区⼀般道路 2,300TB 4.7億円 (※)⼀般的なキャリア回線の料⾦である 10GB/2000円として計算
  26. © Mobility Technologies Co., Ltd. • 実験した結果、物体検出率的には最低3個候補があればいいことがわ かった • 3回収集に抑えられればコストが98%減になる

    36 全ての要件と制約を満たす動画を選ぶアルゴリズムを考案した ⾛⾏回数 道路 道路ごとの⾛⾏回数 3回 2% 98% 3回 12500回 拡⼤すると 12500 10000 7500 5000 2500
  27. © Mobility Technologies Co., Ltd. 37 全ての要件と制約を満たす動画を選ぶアルゴリズムを考案した day1 day2 day3

    day4 day5 day6 day7 道路1 道路2 道路3 道路4 ⾛⾏ 動画 収集 対象 ⼯夫点 解決している要件・制約 期間内に3回収集する 出来るだけ多くの画像を⽤いて物体検出率を⾼めたい 予算内に収める 収集⽇程を分散する ⼀時的な標識を除外したい ⼀つの道路につき1日最大1回まで収集する ⼀時的な標識を除外したい 同時にアップロード出来る動画量に限りがある 負荷が少ない車両から収集する デバイス⼀台あたりでアップロード出来る動画量に限りがある ⽇次で動画収集するかどうか判断する 数⽇前の動画はアップロード出来ない
  28. © Mobility Technologies Co., Ltd. 38 運⽤開始して⾒つかった問題 実際に収集し始めたら予期せぬ回線負荷が発⽣した • 事象

    ◦ 夜間少しずつ動画リクエストしていたが、翌朝⼀⻫にアップロードが始まり 、回線に負荷がかかった • 原因 ◦ アップロード処理はエンジンON時のみ動く ◦ 夜間リクエストした⾞両のエンジンONのタイミングが朝に重なったため • 対応 ◦ 1⽇分の動画を翌⽇⽇中に分散してリクエストし、負荷の平準化を⾏った
  29. © Mobility Technologies Co., Ltd. 40 まとめと今後の展望 • ⾞両位置収集 ◦

    ⾛⾏が途切れていたり、道の途中から始まっていたり、⾮現実的な速度が出 てるデータを不採⽤にする • 動画収集 ◦ 通信費がかかりすぎるので全データを取ることは出来ない ◦ 3回収集できれば物体検出率も⼗分であり、通信コストも予算内に収められる ことがわかった • 今後の展望 ◦ 収集対象を絞り込み、物体検出率、処理効率をより上げていく ▪ 低解像度動画、悪天候、逆光、渋滞を避ける
  30. © Mobility Technologies Co., Ltd. 42 ⾃⼰紹介 データエンジニア / ⾼⼭

    将太 @taka_nigoro DeNA⼊社後、マンガアプリの開発や野球映像の解析に従事。 現在はMobility Technologiesで分散実⾏基盤の開発を担当。 趣味はゲームでほぼ毎晩やってます。 Apex Legendsはマスターランクです。
  31. © Mobility Technologies Co., Ltd. 43 システム構成図 DRIVE CHART センサー収

    集 マップ マッチ 処理対象⾛ ⾏計算 ⾞両位置格 納 タスク作成 タスク 動画リクエ スト 動画格納 ⾞両 位置 動画 物体検出 物体位置推 定 差分判定 認識 物体 地図 AWS Batch AWS Batch Aurora PostgreSQL Aurora PostgreSQL Aurora PostgreSQL Lambda / ECS / Batch S3 ⾛⾏収集 動画収集 認識 差分判定 モジュール データと処理の流れ タスクの状態管理 The Go gopher was designed by Renee French. (http://reneefrench.blogspot.com/) The design is licensed under the Creative Commons 3.0 Attributions license
  32. © Mobility Technologies Co., Ltd. 46 分散実⾏が必要な理由 ⼀定期間内に⼤量のデータを処理する必要があるため • 1か⽉で処理する動画の合計は1500時間を超える

    • もし1並列で処理すると45⽇かかる • 今後10倍以上にデータが増えるため分散実⾏なしでは対応できない
  33. © Mobility Technologies Co., Ltd. • データベースからの⼊⼒が必要 • 画像処理以外の計算が必要 •

    処理に依存関係がある 47 処理の特徴 動画 メタデータ 処 理 対 象 の 動 画 を 検 索 動 画 を 画 像 に 分 割 検 出 結 果 の つ な ぎ 合 わ せ 物 体 検 出 緯 度 経 度 推 定 へ
  34. © Mobility Technologies Co., Ltd. 他のサービスと⽐較して、AWS Batchを採⽤した • SageMaker Batch

    Transform︓機械学習のバッチ推論サービス。開発運⽤は 楽だが、データベースからの⼊⼒を扱えない • ECS︓汎⽤コンテナ実⾏サービス。ECSクラスタの環境構築が⼤変。依存関係の 制御ができない • EKS︓マネージドKubernetesサービス。Kubernetesの学習コストが⾼い 48 分散実⾏サービスの選定
  35. © Mobility Technologies Co., Ltd. 49 AWS Batchについて カスタムコンテナの分散実⾏をいい感じにやってくれるマネージドサービス •

    EC2インスタンスを管理してくれる ◦ インスタンスの起動と停⽌をやってくれる ◦ 処理量に応じてインスタンスの数を調整してくれる • 依存関係のある処理のステータス管理をやってくれる ◦ 前段の処理が成功したら後段の処理を開始する
  36. © Mobility Technologies Co., Ltd. • ジョブ︓処理の実⾏単位 • ジョブ定義︓ジョブを作成する際のテンプレート •

    ジョブキュー︓ジョブをキューイングしておく場所 • コンピューティング環境︓インスタンスタイプやvCPUなどEC2の設定 50 AWS Batchの構成要素
  37. © Mobility Technologies Co., Ltd. • 1500時間の動画は40000データユニットに分割されている • 依存関係を定義したジョブをAWS Batch

    APIに提出 • キューに溜まったジョブを64並列で分散実⾏ 51 AWS Batchを⽤いた画像処理の分散実⾏ 物体検出 ジョブキュー GPU インスタンス 物体検出 ジョブ1 緯度経度推定 ジョブ1 物体検出 ジョブ2 緯度経度推定 ジョブ2 GPU インスタンス 緯度経度推定 ジョブキュー CPU インスタンス CPU インスタンス AWS Batch API 物体検出 ジョブ1 物体検出 ジョブ2 緯度経度推定 ジョブ1 緯度経度推定 ジョブ2 コンピューティング環境
  38. © Mobility Technologies Co., Ltd. 53 ⼯夫① 処理ごとに適したインスタンスタイプの選択 • やりたいこと

    コストパフォーマンスが最⼤となるインスタンスタイプを選択したい ◦コストパフォーマンスを秒間処理フレーム数÷インスタンスコスト($/h)で定義 • 実現⽅法 インスタンスタイプごとにコストパフォーマンスを計算し、コストパフォーマン スが最⼤となるインスタンスを選択
  39. © Mobility Technologies Co., Ltd. 55 ⼯夫① 処理ごとに適したインスタンスタイプの選択 緯度経度推定において、コストパフォーマンスはc4.xlargeが最適 •

    現状の実装ではSLAMの計算はCPUを1コアしか使わないため、CPUを増やしても 処理時間は変化しない
  40. © Mobility Technologies Co., Ltd. 56 ⼯夫② Dockerイメージのビルド効率化 • 前提︓物体検出のDockerイメージのビルドにかかる時間

    ◦ CUDAに対応したOpenCVのビルド︓85分 ◦ 使⽤するPythonパッケージのインストール︓5分 ◦ 物体検出のPythonソースコードのダウンロード︓1分 • 問題点︓ソースコードだけに変更がある場合でも⼀からビルドすると時間がかか り、迅速なトライアンドエラーができない • やりたいこと︓使⽤するPythonパッケージやソースコードだけに変更が⼊る場合 のビルド時間を短縮したい
  41. © Mobility Technologies Co., Ltd. 57 ⼯夫② Dockerイメージのビルド効率化 • 実現⽅法︓Dockerイメージのビルドを⼆段階にわける

    • 結果︓使⽤するPythonパッケージやソースコードに変更がある場合のビルド時間 を短縮し、迅速なトライアンドエラーができるようになった OS CUDA OpenCV ソースコード Python パッケージ OS CUDA OpenCV ソースコード Python パッケージ 91分 85分 6分
  42. © Mobility Technologies Co., Ltd. 58 ⼯夫③ 物体検出の処理性能の改善 • 問題点︓GPU使⽤率が60~70%になっていて性能を⼗分引き出せていない

    • やりたいこと︓GPU使⽤率を上げて処理性能を改善したい • 実現⽅法︓1つのAWS Batchジョブの中で2並列でデータユニットを処理する。 AWS Batchは1つのGPUに対して1つのジョブしか割り当てられないため。 • 結果︓GPU使⽤率を100%近くまで上げ、処理性能を1.4倍にすることができた
  43. © Mobility Technologies Co., Ltd. 60 まとめ • AWS Batchを⽤いた画像処理の分散実⾏

    40000データユニットをAWS Batchを⽤いて64並列で分散実⾏ • システムを構築する上での⼯夫点 ◦ 処理ごとに適したインスタンスタイプの選択 ◦ Dockerイメージのビルド効率化 ◦ 物体検出の処理性能の改善