1. ドライブレコーダの動画を使った
道路情報の自動差分抽出
Mobility Technologies
渡部徹太郎

2. アジェンダ
1. DRIVE CHARTの紹介
2. 道路情報の自動差分抽出プロジェクト
3. 5つの工夫
4. まとめ
2

3. 自己紹介
ID ：fetaro
名前：渡部 徹太郎
学生：東京工業大学でデータベースと情報検索の研究 (@日本データベース学会)
職歴：
* 野村総合研究所(NRI)
- オンライントレードシステム基盤
- オープンソース技術部隊
* リクルートテクノロジーズ
- ビッグデータ分析基盤
* Mobility Technologies
- データエンジニア
エディタ：emacs派→ IntelliJ派
趣味：麻雀、自宅サーバ
日本AWSユーザ会
(JAWS)
著書
3

4. １．DRIVE CHARTの紹介
4

5. Mobility Technologiesの事業
1. 配車関連事業
2. 広告決済事業
3. 乗務員向け
ソリューション事業
4. DRIVE CHART
・ドラレコ事業
5. 次世代向けR&D事業
5

6. DRIVE CHARTの紹介
6
タクシーやトラックなど商用車に向けた、
AI活用の交通事故削減支援サービス『DRIVE CHART』

7. ２．道路情報の自動差分抽出プロジェクト
7

8. プロジェクトの概要
● 課題
○ 自動運転時代においては、地図の更新頻度を上げる必要が
ある
○ しかし、更新頻度をあげる為には、作業の効率化が必要
● 解決策
○ DRIVE CHARTを搭載した車両を動くセンサーとして道路
の情報を収集する
○ 収集した情報を元に自動的に道路情報の差分を見つけ、地
図会社に提供する
● ゼンリン社と共同開発。２０２０年４月にプレスリリース
1 ヶ月で走行した道路
（ ２３区＋三鷹市＋武蔵野市）
8

9. システムの概要
ドライブ
レコーダ
車両位置の特定
道路上の物体を検出
車両センサー
ゼンリン社
に提供
物体位置の
推定
地図との
差分抽出
NEW
地図
9

10. 車両位置の特定 - マップマッチ
GPSで記録された位置 マップマッチした位置
道路リンク
利用技術(1/4)
10

11. 道路上物体を検出 – 機械学習
利用技術(2/4)
11

12. 12
道路上物体を検出 – 機械学習
利用技術(2/4)

13. 正確な位置を推定 – SLAMの利用
利用技術(3/4)
13

14. 地図との差分抽出 ー 地理情報技術
14
利用技術(4/4)
による地理情報操作
+
SELECT *
FROM map
WHERE
ST_Contains (area ,
ST_Geogpoint( 139.7424, 35.6561)
)

15. DRIVE
CHART
システム構成図
マップ
マッチ
動画取得
道路計算
位置
位置格納
動画格納
物体検出
位置
推定
物体
差分判定
地図
差分判定結果
動画
AWS Batch
S3
Lambda
Lambda
TypeScript
CI / CD
15
by
分析・開発

16. 3．5つの工夫
16

17. システム構成図
17
5つの工夫は
ここの話！
DRIVE
CHART
システム構成図
マップ
マッチ
動画取得
道路計算
位置
位置格納
動画格納
物体検出
位置
推定
物体
差分判定
地図
差分判定結果
動画
AWS Batch
S3
Lambda
Lambda
TypeScript
CI / CD
17
by
分析・開発

18. 5つの工夫
1. 動画キャッシュファイルシステム
2. 分散処理サービスの選定
3. ジョブのオーケストレーション
4. 仮想マシン選定
5. 開発フレームワーク
18

19. 動画キャッシュファイルシステム(1/2)
19
標識検出ワーカ
信号検出ワーカ
停止線検出ワーカ
動画
ストレージ
S3
ダウンロード
ダウンロード
ダウンロード
● やりたいこと
○ 同じ動画に対して、複数のワーカーで異なった物体認識処理をする
● 問題点
○ ワーカ毎に同じ動画をローカルにダウンロードする必要がある

20. ● 解決策
○ FSx for Lustreを使うことにより、S3からのダウンロードを１回にでき、
システム全体のIOスループットを向上できる
動画キャッシュファイルシステム(2/2)
20
S3 標識検出ワーカー
信号検出ワーカー
停止線検出
ワーカー
FSx for
Lustre
動画
ストレージ
動画
キャッシュ
初回アクセス時に
S3からダウンロード
以後はS3から
ダウンロード不要

21. 分散処理サービスの選定 (1/4）
● 典型的な機械学習推論のワークロードはこんな感じだが
21
推論
処理
S3
推論
処理
{label = "猫"}
S3
{label = "犬"}
・・・
・・・

22. 分散処理サービスの選定 (2/4)
● 物体検出は典型的な機械学習推論のワークロードではない
22
フ
レ
｜
ム
間
追
跡
処
理
す
る
動
画
の
検
索
状態
管理
DB
結
果
格
納
メ
モ
リ
上
で
画
像
に
分
解
不
要
な
画
像
の
フ
ィ
ル
タ
物
体
検
出
自由度の高いカスタムコンテナが必要
FSx for
Lustre

23. 分散処理サービスの選定 (3/4)
● カスタムコンテナの分散バッチ実行環境の選択肢は４つある
23
SageMaker
batch transform jobs
+ カスタムコンテナ
AWS Batch ECS EKS
概要 機械学習の推論サービス。
それをカスタムコンテナで
動かす
コンテナベースのバッチを動
かすサービス
汎用コンテナ実行環境。
オンラインもバッチもできる。
Kubernetesベースの汎用コ
ンテナ環境。
運用 インスタンス管理不要 インスタンス管理不要 GPUを使う場合は、Fargate
が使えず、インスタンスの管
理が必要
Kubernetesの学習コストが
高い
開発・運用工数：小
制約：強
開発・運用工数：大
制約：弱
運用工数のかかるECSとEKSは外した

24. 分散処理サービスの選定 (4/4)
SageMaker batch transform jobs
+ カスタムコンテナ
比較 AWS Batch
並列実行
の制御
△
・自動で入力データの分割可能
→DBを検索して処理対象を選ぶ必要があるため、今回は利用できない
＝ △
・自前で開発が必要
推論処理
の実装
×
・システム構成が複雑
・HTTPの推論エンドポイント公開が必要だが、推論の入力には使わない。
・ファイルシステムの利用ができない。
< △
・システム構成がシンプル
・ファイルシステムが利用できる
推論コンテナ
SagaMeker batch transform jobs
推論コンテナ
ダミー
入力
S3
推論の
入力
HTTP
HTTP 推論コンテナ
推論コンテナ
AWS Batch
ファイルシステム
推論の
入力
24
SageMakerのフレームワークを活用できないため、AWS Batchを選択した
S3

25. ジョブのオーケストレーション(1/2)
● やりたいこと
○ 車両からくる約５分のデータ毎に物体認識と位置推定を行いたい
○ 物体認識と位置推定は順序関係があるため、それを表現したい
○ 物体認識はGPUマシン、位置推定はCPU(※)マシンで動かしたい
25
標識
検出2
位置
推定2
信号
検出2
停止線
検出2
標識
検出1
位置
推定1
信号
検出1
停止線
検出1
0:00~0:05の処理 0:05~0:10の処理
・・・
on
CPU
on
GPU
on
CPU
on
GPU
※)SLAMの内部で行っている最適化計
算がGPUの並列処理に向かないため、
CPUの計算となる

26. ジョブのオーケストレーション(2/2)
AWS Batchのdependencyを用いて順序を制御
GPU
ジョブ
キュー
CPU
ジョブ
キュー
GPUマシン
AWS Batch
Compute
Environment
CPUマシン
AWS Batch
API
CPUマシン
CPUマシン
…
GPUマシン
…
GPUマシン
標識
検出2
位置
推定2
信号
検出2
停止線
検出2
ジョブ
標識
検出1
位置
推定1
信号
検出1
停止線
検出1
位置
推定1
位置
推定2
標識
検出1
信号
検出1
停止線
検出1
標識
検出2
信号
検出2
停止線
検出2
AWS Batch
Job Queue
dependency
AWS Batch
Job Queue
・・・
26
設定だけで、異なるインスタンス間でのジョブオーケストレーションが可能
● 解決策：AWS Batchを使いこなす

27. 仮想マシン選定 (1/3)
● やりたいこと
○ 最も少ないクラウドコストで、日次処理を行いたい
● 考え方
○ 一枚の画像の処理速度は重要ではない
■ 理由：24時間のバッチウインドウにおさまればよいため
○ 一枚の画像をいくらのお金で処理できるかのコストパフォーマンスが重要
27
コストパフォーマンス =
処理画像数(枚/h)
インスタンスコスト($/h)
例：処理速度だとp3.2xlargeが最も速いが、コストパフォーマンスはg4dn.xlargeがよい

28. 仮想マシン選定 (2/3)
● GPUを用いた４つの物体検出タスクは「g4dn.xlarge」が最善
28
タイムアウト
タイムアウト
タイムアウト

29. 仮想マシン選定 (3/3)
● CPUを用いた位置推定タスクは「c4.xlarge」が最善
○ CPUを多く搭載しても、処理速度は速くならないため、最小のc4.xlargeがよい
29

30. 開発フレームワーク (1/2)
● 開発チームはサイエンティスト５人、エンジニア２人のチーム
● サイエンティストには実行環境を意識すること無く、開発できるようにしたい
● フレームワークを作った
○ データサイエンティストは以下のような成果物を作るだけで良い
30
ROOT /
├── Pipfile # 必要なPythonライブラリを列挙
├── Pipfile.lock
├── install.sh # Pythonライブラリ以外のインストールコマンド
├── lib / # フレームワークから実行される処理を実装
│ ├── logic.py
└── test / # テストを実装
└── test_logic.py
サイエンティストはピュアなPythonのコードを書くだけで良い

31. CloudWatch Logs
開発フレームワーク (2/2)
31
ロギング
物体認識処理
サイエンティスト
の成果物
Python
データ構造
に変換
計算資源提供
出
力
の
格
納
Aurora
動画
Aurora
S3
SQS
ファイル
システム
として
アクセス
位置
速度
加速度
フレーム
ワーク
入
力
の
提
供
引数として
提供
FSx for Lustre
AWS Batch
マウント

32. 4．まとめ
32

33. まとめ
● プロジェクトの概要
○ DRIVE CHARTからとれるタクシーやトラックの情報から、物体を検出して、地図を更新するた
めの情報を地図会社に提供
● 5つの工夫
○ 動画キャッシュファイルシステム
■ FSx for Lustreを導入しS3のキャッシュとして利用
○ 分散処理サービスの選定
■ カスタムコンテナを利用できるAWS上の４つサービスを比較し、AWS Batchを選択
○ ジョブのオーケストレーション
■ AWS Batchの機能を活用して、開発無しでオーケストレーションを実現
○ 仮想マシン選定
■ コストパフォーマンスを計算し、処理ごとに最適な仮想マシンを選定した
○ 開発フレームワーク
■ サイエンティストが実行環境を意識せずに開発できるようにした
33

34. エンジニア募集中！
34