ヒカラボ発表資料

2. 地図データを使ったシステム・
スマホナビのサーバサイド
開発などに従事
現在はサーバサイド・
解析処理まわり開発担当
方向音痴・車の運転苦手です
自己紹介 吉岡 誠
(よしおか まこと)

3. ドライブデータ？
アップロードデータ
アップロードデータの特徴
ドライブデータの生成
サーバ構成
アーキテクチャ
処理の特徴
1
2
3
4
Agenda
開発時の苦労等
今後の取り組み
5
6
A
B
C

4. ドライブデータ？

5. ドライブデータ？
ユーザ毎の
走行データのこと
出発地〜目的地
の間で次のような
データを作成

6. 移動距離、速度、
急加速・急減速の
検知、アイドリン
グ 時 間 、 燃 費 計
算、etc..
ドライブデータ？

7. ドライブごとのデー
タを生成して運転
診断を行う
ドライブデータ？
10:00
10:11
渋谷
神泉
2 km
0.2 ℓ
急加速 2回
急ブレーキ 3回
10:31
10:38
神泉
渋谷
2.5 km
0.2 ℓ
急加速 1回
急ブレーキ 2回
10:45
11:00
品川
お台場
6.8 km
0.3 ℓ
急加速 1回４
アイドリング ４回
11:10
11:25
お台場
目黒
13.7 km
0.4 ℓ
急加速 2回
急ブレーキ 1回
11:30
11:49
目黒
秋葉原
14.4 km
0.5 ℓ
PERFECT

8. 毎秒の車両
データを取得
ドライブデータ？
0 1 2 3 4

9. サーバでデータを
繋ぎ合わせてドラ
イブデータを生成
ドライブデータ？

10. ドライブデータ？
ユーザ毎の走行データのこと
出発地〜目的地の間で以下のようなデータを作成
移動距離、速度、急加速・急減速の検知、アイドリング時間、燃費計算、
etc..
ドライブごとのデータを生成して運転診断を行う
毎秒のデータを利用
毎秒の車両データを取得
サーバでデータを繋ぎ合わせてドライブデータを生成

11. 取得するデータは
大きく２つ

12. デバイス
(OBD2ポート)から 速度
エンジン警告
ガソリン残量
外気温
電圧
etc...

13. スマートフォンから
緯度経度
加速度
磁気センサー
etc...

14. OBD2から取得するデータを
+
スマホからの各種センサーデータで適宜補完

15. アップロード
データの特徴

16. デバイス(OBD2)、
ス マ ホ そ れ ぞ れ
別々のタイミング
でサーバへアップ
A
B
C
D
E
F
G
H
I
J
K
L
M
N
OFF
0:00
0:10
0:20
0:25
0:30
0:40
時間 データ

17. 時系列にデータが
アップされる保証
がない
B
E IP O
A C N
F J CK
D L M G

18. 通信状況やデバイ
スの状況でデータ
が前後
3GLT

19. 連続したデータが集まることで意味を持つ
１つ１つのデータだけでは意味を持たない

20. ドライブデータの
生成

21. サーバ構成
VPC
W O R K E R
C A LC U L AT E
A P P - S E R V E R
LO A D B A L A N C I N G
I N T E R N E T
HTTP
A M A Z O N R D S
S T O R E T H E R AW D ATA
A N D Q U E U E I N G
D ATA S T O R E
Q U E U E I N G
V I R T U A L P R I VAT E C LO U D
1
2
4
5
6
3

22. ドライブデータの生成
http(post)でデータをアップロード
rawデータをDBに保存
queueに登録
workerプロセスがqueueからデータを取得、解析プロセスへhttpリクエスト
解析処理実行
解析結果をDBへ保存(更新)
1
2
3
4
5
6

23. 扱っているデータや処理の特性から以下のようなアーキテクチャを採用
API Rails シンプルなRESTful API
ドライブデータの生成 : アーキテクチャ

24. 扱っているデータや処理の特性から以下のようなアーキテクチャを採用
API Rails シンプルなRESTful API
解析 Node Promiseベース 細かいデータを一度に多く処理
ドライブデータの生成 : アーキテクチャ

25. 扱っているデータや処理の特性から以下のようなアーキテクチャを採用
API Rails シンプルなRESTful API
解析 Node Promiseベース 細かいデータを一度に多く処理
Datastore Amazon RDS for Aurora(MySQL) 更新頻度が高い
ドライブデータの生成 : アーキテクチャ

26. 解析処理の特徴
データの特性を考慮した特徴的な３つの処理を以下に紹介
デバイスとスマホの2種類のデータ
別々にアップ(登録)される
タイムスタンプから同じデータと判断し処理

27. 無効なデータのフィルタリング処理
有効値による補完処理

28. 無効なデータのフィルタリング処理
有効値による補完処理

29. 無効なデータのフィルタリング処理
有効値による補完処理

30. ドライブデータの生成
後からデータがアップされることを考慮
解析範囲をDBに保持
後からアップされたデータと解析済みデータの
解析範囲を照合して新たにグルーピング
新しくグルーピングされたデータで再度解析

31. タイムスタンプが閾値以内のデータをグルーピングして処理
処理済みのデータを含めて再処理
処理済みのデータ
閾値以内
後からアップされたデータ

32. タイムスタンプが閾値以内のデータをグルーピングして処理
処理済みのデータを含めて再処理
処理済みのデータ
閾値以内
後からアップされたデータ

33. タイムスタンプが閾値以内のデータをグルーピングして処理
処理済みのデータを含めて再処理
処理済みのデータ
閾値以内
後からアップされたデータ

34. 処理済みのデータ 後からアップされたデータ
全体で再処理
処理済みのデータ
途中に入ることも
後からアップされたデータ

35. 処理済みのデータ 後からアップされたデータ
全体で再処理
処理済みのデータ
途中に入ることも
後からアップされたデータ

36. 処理済みのデータ 後からアップされたデータ
全体で再処理
処理済みのデータ
途中に入ることも
後からアップされたデータ

37. 開発時の
苦労等

38. ドライブデータの生成
実際に走行して分かることが多い
データが後からアップされる
ケースなども実際に走行して判明
データのフィルタリング(補完)等は
なるべくサーバ側で
アップロード前にフィルタリング
してしまうと問題箇所の特定がし
づらくなる
テストがしずらい。。
実際の走行ログからテストを実施
全てのケースを網羅するのがなか
なか難しい
バグ解析
原因箇所の特定がむずかしい
再現もむずかしい。。

39. 今後の
取り組み

40. ドライブデータの生成
アーキテクチャ
サーバレスな構成へ
AWS Lambda
API Gateway
リアルタイム性の向上
Amazon Kinesis
解析処理
スマホのセンサーデータのみの運
転診断
デバイス非対応車種
運転特性の解析
etc..

41. E N D