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

Mobility Technologies Co.,
MoT TechTalk #16
５万台のドラレコを活⽤︕⼤規模デー
タ収集・機械学習基盤の全容
2023/2/15

View Slide

© Mobility Technologies Co., Ltd. 2
⽬次
• ドラレコデータから道路情報の差分を⾒つけるシステムの仕組みと
特徴（松浦） p. 3~
• 契約⾞両5万台超のドラレコデータを収集する現実解（鳩） p. 20~
• AWS Batchを⽤いた画像処理の分散実⾏（⾼⼭） p. 41~

View Slide

© Mobility Technologies Co., Ltd.
ドラレコデータから道路情報の差分を
⾒つけるシステムの仕組みと特徴
2023/02/15

View Slide

⾃⼰紹介
プロフィール写真
株式会社Mobility Technologies（MoT）
シニアデータエンジニア / 松浦慎平
Web地図サービス提供企業、GISソフトウェアベンダー、⾃動
運転サービス提供企業で GIS エンジニアとして従事
現在は道路情報の⾃動差分抽出プロジェクトで GIS チョットデ
キルデータエンジニアとして活躍︖中
@PEmugi2

View Slide

道路情報の差分抽出プロジェクト
01

View Slide

DRIVE CHART
次世代AIドラレコサービス
通信型ドライブレコーダーとAIで
⾃覚しづらい危険シーンを解析し、効率的な運⾏管理と事故の削減に貢献
契約台数5万台以上のタクシー・トラック・営業⾞両で展開

View Slide

⾃動運転時代の地図に求められること
課題
● ⾃動運転社会では、更新頻度の⾼い地図が求められる
● 更新頻度を上げるには更新作業の効率化が必要
解決策
● DRIVE CHARTを搭載した⾞両から⾞外映像とセンサー情報を収集
● 収集した情報から標識等の道路情報を検出し、地図と⽐較して現地との差分を
⾒つけ地図を更新する
ゼンリン社と共同開発

View Slide

現地と地図の差分を抽出する流れ
地図DB
API
センサー情報
ドラレコ画像
⾞両位置の推定
道路上の物体を検出
物体位置の推定現地の道路情報
DIFF
地図情報
現地と地図の差分
削除
追加
存在確認
道路ネットワークデータ
背景地図 © OpenStreetMap Contributors
GPSや加速度、⾓速度

View Slide

要素技術1/3: マップマッチングで⾞両位置を推定
地図上では道路情報は道路ネットワークに紐付いて管理されている
「どの道路を⾛っているときにみつけたのか︖」が⼤事
GPSで得られる誤差を含む位置を道路ネットワークに対応させる
実際に⾛⾏した位置 GPSで記録された位置マップマッチングした位置道路ネットワーク

View Slide

要素技術2/3: 機械学習とCV技術で道路情報を検出
レーン検出
標識検出
機械学習による物体検出
三⾓測量による物体の位置推定
VSLAMによる⾃⾞位置推定
物体位置の推定
詳しくはMoT TechTalk #11で紹介しています! (https://jtx.connpass.com/event/241709/)

View Slide

要素技術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

View Slide

システム構成と特徴
02

View Slide

システム構成図
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

View Slide

特徴1/4: バッチ処理を採⽤
各モジュールはバッチ処理で実⾏される
理由
● 要件
○ 定められた調査期間内で、収集した⾛⾏・動画データを対象に、期間に1度差分を抽出す
ればよい
● 性能 / 処理効率
○ 差分結果の精度を⾼める⽬的で、1つの道路に対して複数回の⾛⾏結果を収集し差分を抽
出する仕組み
○ コンピューティングリソースを効率的に使⽤するためにまとまった単位で処理したい

View Slide

特徴2/4: ワークフロー管理
「タスク」という実⾏単位を定義し、各モジュールの実⾏状態を管理する仕組みを独⾃
に実装
タスクとは
● ⾛⾏を処理に適した⻑さ「5分」で区切った最⼩の実⾏単位で、各モジュールの実⾏状態が記録される
● タスクに⼊⼒データと各モジュールの出⼒が紐づく
● 各モジュールは実⾏可能なタスクを検索→実⾏するので任意のタイミングでスケジュールできる
task_id 動画収集STATUS 認識STATUS 差分判定STATUS
1 完了実⾏中実⾏待ち
2 完了完了完了
⾞両位置
⾞両位置
Task
1
Task
2
検出した道路情報
検出した道路情報
地図との差分
タスク管理テーブル例

View Slide

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

View Slide

特徴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)

View Slide

まとめ
03

View Slide

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

View Slide

契約⾞両5万台超のドラレコデータを収集
する現実解
2023/02/15

View Slide

⾃⼰紹介
プロフィール写真
株式会社Mobility Technologies（MoT）
データエンジニア / 鳩英嗣
Webシステムのインフラ管理業務に携わったのち、データ分析
基盤の開発運⽤に従事。現在はMoTにてドラレコデータ収集基
盤の開発を担当。
最近、学⽣の頃弾いていたチェロを再開しました。
リモートワークのお昼休みに基礎練してます。

View Slide

アジェンダ
1.
概要
2.
⾞両位置収集
3.
動画収集
4.
まとめと今後の展望

View Slide

概要
01

View Slide

本データ収集の概要
契約⾞両5万台超のドラレコから⾞両位置と動画データを定期的に収集
⽉次で⾛破した⼀般道
全国⾼速9割を⽉次で⾛破
© OpenStreetMap
contributors

View Slide

⾞両位置収集
02

View Slide

⾞両位置収集
DRIVE CHART
センサー収
集
マップ
マッチ
処理対象⾛
⾏計算
⾞両位置格
納
タスク
動画リクエ
スト
動画格納
⾞両
位置
動画物体検出
物体位置推
定
差分判定
認識
物体
地図
AWS Batch
AWS Batch
Aurora
PostgreSQL
Aurora
PostgreSQL
Aurora
PostgreSQL
⾛⾏収集
動画収集
認識
差分判定

View Slide

⾞両位置収集システム構成図
センサー収
集
マップ
マッチ
処理対象⾛
⾏計算
⾞両位置格
納
地図
Aurora
PostgreSQL
S3
モバイル
回線
1分単位でアップロード
センサー収集
システム
ECS
S3
BigQuery
Lambda / ECS / Batch
⾛⾏収集
データアップロードシステム
ファイル特定
取得
保存
参照
道路毎の
⾛⾏履歴
センサー
ファイル
GPS,加速度,⾓速度など
0.1秒単位
⾞両位置

View Slide

処理対象⾛⾏計算 - 収集対象エリアに絞り込む
● 全ての⾞両位置を収集すると無駄が多い
● 事前に定義した収集対象エリア範囲の⾞両位置のみ蓄積出来るよう、地理
空間クエリなどを駆使し絞り込んでいる
ー対象エリア
ーエンジンONからOFFまでの⾞両位置
収集対象エリア外の⾞両位置

View Slide

汚いデータを不採⽤にする
● ⾛⾏が途切れている場合
● 駐⾞場から出るなどして道路を端から端まで⾛りきってない場合
● GPSの特性上誤差が⽣じ、時速300kmなど現実的な⾞速に収まっていない場合
29
処理対象⾛⾏計算 - データクレンジング
道路
駐⾞場
© OpenStreetMap contributors

View Slide

動画収集
03

View Slide

動画収集
DRIVE CHART
センサー収
集
マップ
マッチ
処理対象⾛
⾏計算
⾞両位置格
納
タスク
動画リクエ
スト
動画格納
⾞両
位置
動画物体検出
物体位置推
定
差分判定
認識
物体
地図
AWS Batch
AWS Batch
Aurora
PostgreSQL
Aurora
PostgreSQL
Aurora
PostgreSQL
⾛⾏収集
動画収集
認識
差分判定

View Slide

リクエストした動画を⾮同期でアップロードする
32
動画収集システム構成図
S3
②リクエスト動画収集
システム
ECS
動画
ストレージ
S3
動画リクエ
スト
動画格納
動画収集
動画
データアップロードシステム
③アップロード
①リクエスト
④保存
SQS
⑤完了通知
⑥取得
⑦コピー
モバイル回線

View Slide

要件
●
出来るだけ多くの画像を⽤いて物体検出率を⾼めたい
○ オクルージョン（他の物体で⾒えない）や逆光が発⽣すると正しく物体検出
できないため
●
⼀時的な標識を除外したい
○ 1⽇しか⽴たないような⼯事の標識を変化として捉えないようにするため
●
予算内に収める

View Slide

制約
●
同時にアップロード出来る動画量に限度がある
○ 通信キャリア回線全体の負荷回避のため
●
デバイス⼀台あたりでアップロード出来る動画量に限度がある
○ DRIVE CHARTサービスに影響が出ないようにするため
○ → 取得するデバイスをばらして⼀台からアップロードする量を少なくする必
要がある
●
数⽇前の動画はアップロード出来ない
○ SDカードに映像が常時記録されていき、古い動画ファイルから上書きされ消
えていくため

View Slide

まず全部取ることを考えてみたが・・・
● とても予算内には収まらなかった
○ モバイル回線でアップロードするため通信量に応じて従量課⾦される
1ヶ⽉のアップロードコスト推定
エリア動画サイズ推計コスト推計(※)
京浜地区⼀般道路 2,300TB 4.7億円
(※)⼀般的なキャリア回線の料⾦である
10GB/2000円として計算

View Slide

●
実験した結果、物体検出率的には最低3個候補があればいいことがわ
かった
●
3回収集に抑えられればコストが98%減になる
36
全ての要件と制約を満たす動画を選ぶアルゴリズムを考案した
⾛⾏回数
道路
道路ごとの⾛⾏回数
3回
2%
98%
3回
12500回
拡⼤すると
12500
10000
7500
5000
2500

View Slide

全ての要件と制約を満たす動画を選ぶアルゴリズムを考案した
day1 day2 day3 day4 day5 day6 day7
道路1
道路2
道路3
道路4
⾛⾏
動画
収集
対象
⼯夫点解決している要件・制約
期間内に3回収集する出来るだけ多くの画像を⽤いて物体検出率を⾼めたい
予算内に収める
収集⽇程を分散する⼀時的な標識を除外したい
⼀つの道路につき1日最大1回まで収集する⼀時的な標識を除外したい
同時にアップロード出来る動画量に限りがある
負荷が少ない車両から収集するデバイス⼀台あたりでアップロード出来る動画量に限りがある
⽇次で動画収集するかどうか判断する数⽇前の動画はアップロード出来ない

View Slide

運⽤開始して⾒つかった問題
実際に収集し始めたら予期せぬ回線負荷が発⽣した
●
事象
○ 夜間少しずつ動画リクエストしていたが、翌朝⼀⻫にアップロードが始まり
、回線に負荷がかかった
●
原因
○ アップロード処理はエンジンON時のみ動く
○ 夜間リクエストした⾞両のエンジンONのタイミングが朝に重なったため
●
対応
○ 1⽇分の動画を翌⽇⽇中に分散してリクエストし、負荷の平準化を⾏った

View Slide

04

View Slide

●
⾞両位置収集
○ ⾛⾏が途切れていたり、道の途中から始まっていたり、⾮現実的な速度が出
てるデータを不採⽤にする
●
動画収集
○ 通信費がかかりすぎるので全データを取ることは出来ない
○ 3回収集できれば物体検出率も⼗分であり、通信コストも予算内に収められる
ことがわかった
●
今後の展望
○ 収集対象を絞り込み、物体検出率、処理効率をより上げていく
■ 低解像度動画、悪天候、逆光、渋滞を避ける

View Slide

AWS Batchを⽤いた画像処理の分散実⾏
2023/02/15

View Slide

⾃⼰紹介
データエンジニア / ⾼⼭将太 @taka_nigoro
DeNA⼊社後、マンガアプリの開発や野球映像の解析に従事。
現在はMobility Technologiesで分散実⾏基盤の開発を担当。
趣味はゲームでほぼ毎晩やってます。
Apex Legendsはマスターランクです。

View Slide

システム構成図
DRIVE CHART
センサー収
集
マップ
マッチ
処理対象⾛
⾏計算
⾞両位置格
納
タスク作成
タスク
動画リクエ
スト
動画格納
⾞両
位置
動画物体検出
物体位置推
定
差分判定
認識
物体
地図
AWS Batch
AWS Batch
Aurora
PostgreSQL
Aurora
PostgreSQL
Aurora
PostgreSQL
⾛⾏収集
動画収集
認識
差分判定

View Slide

今⽇の内容
1. AWS Batchを⽤いた画像処理の分散実⾏
2. システムを構築する上での⼯夫点
3. まとめ

View Slide

01 AWS Batchを⽤いた
画像処理の分散実⾏

View Slide

分散実⾏が必要な理由
⼀定期間内に⼤量のデータを処理する必要があるため
● 1か⽉で処理する動画の合計は1500時間を超える
● もし1並列で処理すると45⽇かかる
● 今後10倍以上にデータが増えるため分散実⾏なしでは対応できない

View Slide

● データベースからの⼊⼒が必要
● 画像処理以外の計算が必要
● 処理に依存関係がある
47
処理の特徴
動画
メタデータ
処
理
対
象
の
動
画
を
検
索
動
画
を
画
像
に
分
割
検
出
結
果
の
つ
な
ぎ
合
わ
せ
物
体
検
出
緯
度
経
度
推
定
へ

View Slide

他のサービスと⽐較して、AWS Batchを採⽤した
● SageMaker Batch Transform︓機械学習のバッチ推論サービス。開発運⽤は
楽だが、データベースからの⼊⼒を扱えない
● ECS︓汎⽤コンテナ実⾏サービス。ECSクラスタの環境構築が⼤変。依存関係の
制御ができない
● EKS︓マネージドKubernetesサービス。Kubernetesの学習コストが⾼い
48
分散実⾏サービスの選定

View Slide

AWS Batchについて
カスタムコンテナの分散実⾏をいい感じにやってくれるマネージドサービス
● EC2インスタンスを管理してくれる
○ インスタンスの起動と停⽌をやってくれる
○ 処理量に応じてインスタンスの数を調整してくれる
● 依存関係のある処理のステータス管理をやってくれる
○ 前段の処理が成功したら後段の処理を開始する

View Slide

● ジョブ︓処理の実⾏単位
● ジョブ定義︓ジョブを作成する際のテンプレート
● ジョブキュー︓ジョブをキューイングしておく場所
● コンピューティング環境︓インスタンスタイプやvCPUなどEC2の設定
50
AWS Batchの構成要素

View Slide

● 1500時間の動画は40000データユニットに分割されている
● 依存関係を定義したジョブをAWS Batch APIに提出
● キューに溜まったジョブを64並列で分散実⾏
51
AWS Batchを⽤いた画像処理の分散実⾏
物体検出
ジョブキュー
GPU
インスタンス
物体検出
ジョブ1
緯度経度推定
ジョブ1
物体検出
ジョブ2
緯度経度推定
ジョブ2
GPU
インスタンス
緯度経度推定
ジョブキュー
CPU
インスタンス
CPU
インスタンス
AWS Batch
API
物体検出
ジョブ1
物体検出
ジョブ2
緯度経度推定
ジョブ1
緯度経度推定
ジョブ2
コンピューティング環境

View Slide

02 システムを構築する上での
⼯夫点

View Slide

⼯夫① 処理ごとに適したインスタンスタイプの選択
● やりたいこと
コストパフォーマンスが最⼤となるインスタンスタイプを選択したい
○コストパフォーマンスを秒間処理フレーム数÷インスタンスコスト($/h)で定義
● 実現⽅法
インスタンスタイプごとにコストパフォーマンスを計算し、コストパフォーマン
スが最⼤となるインスタンスを選択

View Slide

物体検出において、処理速度はp3.2xlargeが最速だがコストパフォーマンスは
g4dn.xlargeが最適

View Slide

緯度経度推定において、コストパフォーマンスはc4.xlargeが最適
● 現状の実装ではSLAMの計算はCPUを1コアしか使わないため、CPUを増やしても
処理時間は変化しない

View Slide

⼯夫② Dockerイメージのビルド効率化
● 前提︓物体検出のDockerイメージのビルドにかかる時間
○ CUDAに対応したOpenCVのビルド︓85分
○ 使⽤するPythonパッケージのインストール︓5分
○ 物体検出のPythonソースコードのダウンロード︓1分
● 問題点︓ソースコードだけに変更がある場合でも⼀からビルドすると時間がかか
り、迅速なトライアンドエラーができない
● やりたいこと︓使⽤するPythonパッケージやソースコードだけに変更が⼊る場合
のビルド時間を短縮したい

View Slide

⼯夫② Dockerイメージのビルド効率化
● 実現⽅法︓Dockerイメージのビルドを⼆段階にわける
● 結果︓使⽤するPythonパッケージやソースコードに変更がある場合のビルド時間
を短縮し、迅速なトライアンドエラーができるようになった
OS
CUDA OpenCV
ソースコード
Python
パッケージ
OS
CUDA OpenCV
ソースコード
Python
パッケージ
91分
85分
6分

View Slide

⼯夫③ 物体検出の処理性能の改善
● 問題点︓GPU使⽤率が60~70%になっていて性能を⼗分引き出せていない
● やりたいこと︓GPU使⽤率を上げて処理性能を改善したい
● 実現⽅法︓1つのAWS Batchジョブの中で2並列でデータユニットを処理する。
AWS Batchは1つのGPUに対して1つのジョブしか割り当てられないため。
● 結果︓GPU使⽤率を100％近くまで上げ、処理性能を1.4倍にすることができた

View Slide

03 まとめ

View Slide

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

View Slide

⽂章・画像等の内容の無断転載及び複製等の⾏為はご遠慮ください。

View Slide

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

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

GO Inc. dev

More Decks by GO Inc. dev

Other Decks in Technology

Featured

Transcript