DRIVE CHARTの裏側 〜 AI ☓ IoT ☓ ビッグデータを 支えるアーキテクチャ 〜
•Download as PPTX, PDF•
3 likes•5,527 views
年間40万件以上発生している交通事故。DRIVE CHARTはAIドラレコで交通事故ゼロ社会を目指すサービスです。 DRIVE CHARTを実現する上では、AIの組み込みやIoT機器によるセンシング、膨大なデータ処理といったチャレンジがありました。 このセッションではその裏側を支えるサーバサイドおよびIoT機器の事例についてご紹介します。 サーバサイドにおいては、セキュアでスケーラブルなアーキテクチャの設計、多言語・多数のコンポーネント間のマイクロサービス化、IoT機器やAIシステムとの膨大な動画・データ処理連携における工夫、OpenAPIDocumentを利用したAPI自動テストの効率化をご紹介したいと思います。 IoT機器においては、リアルタイムでのAI活用で発生した課題とその対策・検証、IoT機器の移動体通信の仕組みと通信量削減の手法について具体的な事例をご紹介したいと思います。
Recommended
More Related Content
What's hot
What's hot (20)
Similar to DRIVE CHARTの裏側 〜 AI ☓ IoT ☓ ビッグデータを 支えるアーキテクチャ 〜
Similar to DRIVE CHARTの裏側 〜 AI ☓ IoT ☓ ビッグデータを 支えるアーキテクチャ 〜 (20)
More from DeNA
More from DeNA (20)
Recently uploaded
Recently uploaded (12)
DRIVE CHARTの裏側 〜 AI ☓ IoT ☓ ビッグデータを 支えるアーキテクチャ 〜
- 1. DRIVE CHARTの裏側 〜 AI ☓ IoT ☓ ビッグデータを 支えるアーキテクチャ 〜
- 2. 森 健太郎 (@moriken) ● 出身：福岡 ● 経歴： ○ 大手SIerで、毎年１プロダクト新規開発を経験 ■ 2009年 第1回SBIビジネスコンテスト準優勝 (個人) ○ 2011年12月 DeNA入社 ■ Mobage/AndAppのゲームプラットフォーム開発 ■ 第7回DeNAビジネスコンテスト 最終選考 ■ IoTデジタルサイネージ自販機開発(お蔵入り..) ■ DRIVE CHARTの立ち上げ(リードエンジニア兼アーキテクト) ■ 会社を起業し、エクセライク会計(クラウド会計)をローンチ
- 5. アジェンダ DRIVE CHARTのご紹介A AI x IoT x ビッグデータを支えるアーキテクチャB Edgeデバイスのシステム構成C
- 8. A2 DRIVE CHARTとは DRIVE CHARTは、交通事故ゼロ社会をめざすべく、AIドラレコが、 ドライバーの速度超過などの荒い運転や、脇見などの気の緩みを検知し、レポートで振り返り を行って、運転が改善していき、結果として、事故が減る、というサービスになります。
- 13. A5 AI ア ノ テ |シ ョ ン ツ | ル このように、AIの精度をあげるために、 「これが車だよ」「これは人だよ」という「アノテーションツール」もつくり、数十万枚の学習データ をつくりました。
- 15. エ ン ジ ニ ア 体 制 2017.3〜6 2017.7〜12 2018.1〜9 2019.7 プロトタイプ実装 実証実験(Ph1〜Ph2) ローンチ AI Sys Edge Sys Server Sys 5人 5 人 A6 10 人 AI 30人
- 16. AI x IoT x ビッグデータ を支えるアーキテクチャ B AI IoT BigData
- 18. 車両数： X,000台 x 3ヶ月間 X00,000台 x 3ヶ月間 ECS 車両からのリクエスト数 60 RPS 4,000 RPS コンポーネント数 21 21 起動Container数 230 15,000 Aurora Auroraレコード数 3億レコード 200億レコード Aurora容量 70 GB 4.5 TB S3 S3オブジェクト数 6億オブジェクト 400億オブジェクト S3容量 200 TB 13 PB S3秒間GET数 500 get/s 35,000 get/s S3秒間PUT数 60 put/s 4,000 put/s ビ ッ グ デ | タ 要求 仕様
- 20. AI x IoT x ビッグデータを支えるアーキテクチャB1 CloudWatch CloudTrail Aurora Trusted Advisor CloudFront Route 53 ALB Secret Manager KMS WEB DynamoDB SNS OPE OPS CAR UPL S3 Glue SQS BigQuery User Device Firehose Internet gateway VPC WEB CAR BATCH JOB OUT DNA OUT DAEMON MapMatch AI Scoring FaceRecog. DB CDN MONITORING ANALYTICS KMS S3 Queue Medjed Argus(BI)
- 22. シーケンス Edge API Server AI Server 走行ファイル送信 (GPS/加速度etc.) データ保存 ファイル保存 AI解析 エンキュー デキュー 走行ファイル取得 MAPマッチ スコアリング 危険運転検知 スコア登録 危険運転登録 Aurora S3 SQS 危険運転動画要求 危険運転動画送信 ファイル保存 1分単位 に送信 5分単位 に処理 大量データ処理は SQS + Daemon！ 動画は危険運転のみPickUp！ MAPマッチ結果保存 データ連携は DB + S3 + SQS
- 26. サーバ負荷対策①：ECSのAuto Scaling 車両の動きは周期的でAuto Scalingと相性良し。 ー 車両からのアップロード数 ー 実際のAuto Scaling台数 8:30 8:30 8:30 朝8:30ごろにピークを迎え、 その後は翌朝まで減少傾向
- 27. サーバ負荷対策②：ECSのチューニング • ECS Clusterのインスタンスをコンポーネント別に最適化 • Webサービス周り ： m5.large〜 • AIマップマッチ処理： m5.2xlarge〜 • AI顔認証 ： r5.large〜 （メモリ強く） • ECS TaskごとにvCPU/Memoryをチューニング • vCPUはなるべく使い切るように値を定める • OOMが発生しない程度のMemoryの値を定める • Memory Limit Overで、Taskがkillされないように見極める必要あり
- 28. サーバコスト削減対策： ECSとFargateの住み分け • 用途別にEC2 Container InstanceとFargateで分けて管理 • Spot Instanceを活用したい場合はEC2を。 • 一時的な処理やバッチ向けにFargateを。 • 車載器からの大量のデータアップロードへの対応 • AI処理やAI顔認証周りの大規模処理でSpot Intanceを活用中 • 現在は、9割以上がSpot Instanceで起動中 ５５%のコスト 削減に成功！
- 30. S3で保管するデータの特徴 CAR UPL S3 CAR Device 走行ファイル(GPS/加速度等) 動画 • データサイズは小さい • 数B〜数十KB • データ数量がかなり多い • １走行で100超のオブジェクト生成と数が多い • データサイズが大きい • １動画が数MB〜数十MBとサイズが大きい • データ数量が比較的少ない • 危険運転に比例 1日1,000万超のファイル生成
- 31. S3でのデータ対策 • Storage Class • Standard • S3操作 • LIST は禁止！ (高コスト) • PUT/GET回数を減らすため、ファイル数は最小限に。 • アーカイブ • 一定期間経過したオブジェクト群をまとめ圧縮し、Glacier送り • S3ライフサイクルでのStorage Class変更はコスト爆上げなので要注意 • 1,000リクエストあたり、0.0571USD (ap-noarheast-1@2020/2)
- 33. • 車載器がS3に保管している設定ファイルをダウンロード • CloudFront + S3 署名付きURL ▼いろいろ試した結果... • DBで管理する？ • 容量、実行ファイルetc... • AWS SDK + S3 GetObject？ • 車載器側でのSDKの更新 • credentialsの運用 • S3 署名付きURL？ • 発行しすぎてスロットリング S3署名付きURLのスロットリング対策 Car API Cloud Front S3 Secret Manager Device key-pair 取得 認証付き URL 取得 アクセスNG
- 34. 分析データの保存先はBQ 分析データは、Google Big Query (BQ) に保存 • Webアプリの操作ログ、走行情報などをS3に転送 • S3に保存後、MedjedでBQへ転送 • BQのデータを、BIツール(Argus)でKPI設計・グラフ化 • Glue + Medjedで、アナリストがスキーマ定義して、BQまで必要な形式で連 携 Web ECS Firehose S3GlueAurora Medjed (Embulk) Big Query Argus(BIツール)
- 35. ログ・レコード転送にはGlue • Auroraから取得するテーブル群は、AWS Glueで生成 • GlueはAWSのマネージドETLツール • Aurora < - Glue -> S3の経路でデータ転送 • DPU(Data Processing Unit)単位で、IPアドレスを使用 • 大量にDBのレコードを抽出する場合、IPアドレスもその分消費 • Glueは、サービスの稼働するVPCとは切り離して実行 • ➔ DPU大量起動するため、一緒のVPCだと最悪IP枯渇問題発生のため • アクセスログは、Kinesis FirehoseでS3へ
- 36. モニタリング • CloudWatch + Lambdaで各種リソースをモニタリング • サービスの外形監視 • ECSのstatus監視 • Spot Instanceの停止イベント検知 • エラーログ、スロークエリログ監視 • SNSで通知 • Slack通知 (CWログからエラー内容を抜粋通知し１次判断可能） • PagerDuty通知 • リソースの制限 • AWS Limit Monitorで監視 • https://aws.amazon.com/jp/solutions/limit-monitor/
- 38. APIテストにおける工夫 • 背景 • 0 ➔ 1 フェーズではスピード最優先 • API：1,000本、モデル：150個と大量 • UnitTest書いてる時間がない＆書いても仕様変更激しい • ➔ API仕様書(I/F)を書いたら、req/resの自動テストできたら便利では... • やったこと • API 仕様書の規格 • OpenAPI 3 規格に沿って書く • ツール選定 • テストツールは Dredd • クラウドサービス (S3、SQS等)もローカル化し実行可能とし、ファ イルのアップロード、メール送信までもカバー
- 42. 自己紹介 • 木村 尭海（きむら たかうみ） • 所属 • DRIVE CHART • ハードウェアメーカーと協業してデバイス・ソフト開発および推進を担当 • 業務経歴 • メーカー系 家電連携Androidアプリ開発 • Androidデバイス開発 • toB/toC向け • 執筆 • プロの力が身につくAndroidプログラミングの教科書 • Amazon Alexa開発ガイド Alexa対応スキル＆AVS対応アプリの作り方
- 43. 業務用車両を持つ会社の課題 • 事故削減のPDCAのサイクルが長い • 運行管理 • 乗務員の事故防止や安全運行に支障が出ないように指導・監督 • 現行の安全運転指導 • 事故が発生した映像から指導が多い • 1人あたりの乗務員の業務時間12時間〜20時間 • 1人の運行管理者に対して39車両を監督することがある • 事故削減にはPDCAのサイクルを短くする必要がある • 指導対象者を早く見つける • 不安全運転を見つけやすくする 月に数回、1ヶ月に1回程度の指導をすることしかできないのが実 態
- 44. 誤検知を減らすためのアプローチ • AI・ビッグデータを活用 • 非力なデバイスでは実現できない • 通信型車載カメラが必要 • 通信型車載カメラ特有の通信量問題の解決が必須 • 映像データをすべてアップロードすると莫大な費用がかかる • 実現にはハードウェアが必須 • AIを処理するだけのマシンパワーのある車載カメラがない
- 45. 開発しました
- 46. DRIVE CHARTの通信型車載カメラのアプローチ • DRIVE CHART用のデバイスをメーカーと協力して実現 • ハードウェア • 株式会社 JVCケンウッド • ソフトウェア • 株式会社 ディー・エヌ・エー
- 47. DRIVE CHART Spec 動作温度範囲 -10℃〜+60℃ 外形寸法 約100 × 約62 × 約49mm 本体質量 約220g 電源電圧 5V 消費電流 1.2A 有効画素数 約400万画素 フレームレート 27fps (変更可) 記録解像度 1920 × 1080 (変更可) 録画フォーマット mp4(H.264, AAC) 音声記録 オン/オフ 可 HDR オン 動作温度範囲 -10℃〜+60℃ 外形寸法 約52 × 約27 × 約 26mm 本体質量 約60g 電源電圧 8V 消費電流 300mA 有効画素数 約200万画素 フレームレート 27fps (変更可) 記録解像度 1920 × 1080 (変更可) 録画フォーマット mp4(H.264, AAC) 赤外線照明 赤外線LED × 4 HDR オン
- 48. 取り付け位置
- 49. 通信型車載カメラ＋AIで発生した課題 • 通信量問題と通信方法 • リスク運転動画について • AI利用によるデータ削減 • 限定空間の制約を利用したデータ削減 • 排熱問題 • AIモデル導入におけるトラブル
- 50. 通信型車載カメラ＋AIで発生した課題 • 通信量問題と通信方法 • リスク運転動画について • AI利用によるデータ削減 • 限定空間の制約を利用したデータ削減 • 排熱問題 • AIモデル導入におけるトラブル
- 51. • 大きく4段階に分類分けができる 事故が発生する運転 安全運転 リスクのある運転 ヒヤリ ハット 事故 ● 右折時に対向車と接触事故 :走行中事故(自責or/and他責) ● 停車中に追突される :停車中事故(他責) ● 高速道路逆走車両と接触 :走行中事故(他責) ● etc... ● 人の飛び出しによる急ブレーキ :走行中トラブル ● 車間距離が近く事故確率が高い状況 :走行中トラブル ● etc... ● 速度超過 :走行中リスク ● 一時停止場所での不停止 :走行中リスク ● 急減速 :走行中リスク ● etc...
- 52. 安全運転 リスクのある運転 ヒヤリ ハット 事故 DRIVE CHARTの運転行動を変えるアプローチ • リスク運転までカバーして指導 • 事前教育の強化 • 運転の癖を矯正 • 運行管理者の仕事は増やさない • 危ない運転だけを抽出
- 53. 分類ごとのDRIVE CHARTの観点 安全運転 リスクのある運転 ヒヤリ ハット 事故 危険な運転は即時で危険性を知らせる • 運行管理者が乗務員を止めるなどの処置を促す • 明確な事象に対してリアルタイムに デバイスで解析 リスク運転は誤検知を減らしより正確に提供 • 指導によっての改善を促す • 運転終了までにリスク運転の動画を提供する
- 54. 分類ごとのDRIVE CHARTの観点 安全運転 リスクのある運転 ヒヤリ ハット 事故 危険な運転は即時で危険性を知らせる • 運行管理者が乗務員を止めるなどの処置を促す • 明確な事象に対してリアルタイムに デバイスで解析 リスク運転は誤検知を減らしより正確に提供 • 指導によっての改善を促す • 運転終了までにリスク運転の動画を提供する
- 55. リスク運転動画取得 • ビッグデータとAIを使って精度の高いリスク運転を抽出・収集 • デバイス内では実現できない • 計算速度 • 過去のデータの保有 • サーバーで実現する • 運転終了までにリスク運転動画をアップロードする必要がある • 運転時のセンサー情報のアップロード • AIによるリスク運転検出 • デバイスにリスク動画作成&アップロード要求 • リスク動画アップロード 必要な動画データのみをアップロードしてデータ量削減
- 56. アーキテクチャ 内向き カメラHardware 外向き カメラ 3軸加速度 センサー 3軸角速度 センサー GPS OS Application ドライブレコーダー用フレームワーク Hardware Abstraction Layer 顔認識 AI 車線認識 AI 物体認識 AI 衝突警報/車間距離警報 録画機能 センサーデータ保存機能 AI処理 ドライブ レコーダー 処理 メーカー 開発
- 57. アーキテクチャ 内向き カメラHardware 外向き カメラ 3軸加速度 センサー 3軸角速度 センサー GPS OS Application ドライブレコーダー用フレームワーク Hardware Abstraction Layer 顔認識 AI 車線認識 AI 物体認識 AI 衝突警報/車間距離警報 録画機能 センサーデータ保存機能 AI処理 ドライブ レコーダー 処理 メーカー 共同開発
- 58. アーキテクチャ 内向き カメラHardware 外向き カメラ 3軸加速度 センサー 3軸角速度 センサー GPS OS Application ドライブレコーダー用フレームワーク Hardware Abstraction Layer 顔認識 AI 車線認識 AI 物体認識 AI 衝突警報/車間距離警報 録画機能 センサーデータ保存機能 AI処理 ドライブ レコーダー 処理
- 59. リスク運転動画取得 運転中停車 走行状態 イグニッション OFF ON ? 時間 7:00 8:00 ? センサー データ収集 現在時刻 AIサーバー ... ? リスク動画 アップロード 1分間区切りでデータ生成 生成の都度サーバーへ送付 センサーデータを解析
- 60. リスク運転動画取得 運転中停車 走行状態 イグニッション OFF ON ? 時間 7:00 8:00 ? センサー データ収集 現在時刻 AIサーバー ... ? リスク動画 アップロード リスクのある行動を検知
- 61. リスク運転動画取得 運転中停車 走行状態 イグニッション OFF ON ? 時間 7:00 8:00 ? センサー データ収集 現在時刻 AIサーバー ? リスク動画 アップロード SDカード内の動画データから 必要な動画データを切り出し&送付
- 62. データ量削減 運転中停車 走行状態 イグニッション OFF ON ? 時間 7:00 8:00 ? センサー データ収集 現在時刻 AIサーバー ... ? リスク動画 アップロード このデータをできるだけ減 らす必要がある
- 63. • 営業時間すべての情報をアップロードはNG • 20時間勤務 • 実運転時間は12時間程度 • 走行中判断 • 3分以上の停止を停車と判断 リスク運転動画用データの削減 時間 センサー データ収集 データ収集 運転中 一時停車 運転中 一時停車 運転中 一時停車 停車停車走行状態 40%の通信量削減 安全運転 リスクのある 運転 ヒヤリ ハット 事 故 ● 速度超過 ● 一時停止場所での不停止 ● 急減速 ● etc...
- 64. 車内映像データの削減 • 人物の特徴点データをサーバーにアップロード • 目 • 鼻 • 口 • 顔の方向
- 65. 限定空間の制約を利用した通信量・計算量の削減 • 乗務員特定の課題 • 車内映像には人は複数人存在する可能性がある • タクシー • 助手席・後部座席に乗客が乗る(最大5名映り込む) • 営業車 • 同乗者 • 左ハンドル車両 • 乗務員は映像の左側とは限らない • 防犯目的 • 中央につけて後部座席まで撮影するため中央に乗務員が来るとは限らない 複数人のデータのアップロードは無駄が多い
- 66. 複数人の中から乗務員の特定 • 乗務員の運転姿勢に着目 • 運転中の乗務員の動きは小さい • 体を左右に動かす程度 • 内向きカメラを取り付けたときに映像の映り方が固定になる 取り付け時に AIの計算領域を確定 枠内に一人しか映らない 制約をもたせる 乗務員のみのデータに限定できる
- 67. DRIVE CHARTのデバイスで解決したい課題 • 通信方法と通信量問題 • リスク運転動画について • AI利用によるデータ削減 • 限定空間の制約を利用したデータ削減 • 排熱問題 • AIモデル導入におけるトラブル
- 68. 通信型車載カメラのAI利用の条件 • 一定時間以内で計算が終わること • 製品に組み込める精度を持つこと • 過酷環境の動作ができること • 炎天下の車内温度対応 • オーバーヒートを起こさない設計が必要 • エアコンによって車内温度が低下するまでの期間にAIが動かないのはNG AIのアルゴリズム検討
- 69. 通信型車載カメラのAI利用の条件 • 一定時間以内で計算が終わること • 製品に組み込める精度を持つこと • 過酷環境の動作ができること • 炎天下の車内温度対応 • オーバーヒートを起こさない設計が必要 • エアコンによって車内温度が低下するまでの期間にAIが動かないのはNG AIのアルゴリズム検討 事故の発生率は運転開始時点が多い
- 70. AIモデルの温度検証 • デバイスの動作要件 • 録画機能が60℃環境で動くこと(AIは50℃環境で動くこと) • 10分間以上は高温環境下でも動作できること • エアコンが効くまでの時間は必ず動作できること • 温度影響によるクロック変動によって計算時間が伸びないこと • 簡易試験 • 温度上昇試験 • 高温維持試験 • 高温からの温度低下試験 • リリース前試験 • 人工気象室 • 高温日照試験 2段階で試験を繰り返す
- 72. AIモデル利用のポイント • CPU/GPU特性に注意する • CPU/GPUのクロック調整 • オーバーヒートによるクロックダウン • 仕事が少なすぎる事によるクロックダウン • オーバーヒートしたときの設計 • オーバーヒートによるシャットダウンの見極め • AI処理を止めるタイミング・復旧のタイミング
- 73. まとめ • 安全運転の実現の現時点のアプローチ • AI×IoT×ビッグデータのアーキテクチャ • ECS負荷対策 • S3負荷対策 • 通信型車載カメラ開発 • 通信量問題 • 排熱問題 新しい分野のため事故削減に必要な技術やアプローチに答えはありません 積極的なトライ＆エラーを繰り返し、事故の無い未来を目指します！
- 74. ご清聴ありがとうございました。