タクシードライブレコーダーの動画処理MLパイプラインにkubernetesを使ってみた

1
Proprietary and Confidential ©2017 JapanTaxi, Inc. All Rights Reserved
タクシードライブレコーダーの
動画処理MLパイプラインに
kubernetesを使ってみた
2019/9/9
JapanTaxi
次世代モビリティ事業部
渡部徹太郎
Webエンジニアが使う身近な Kubernetes

2
2
ID : fetaro
名前：渡部徹太郎
研究：東京工業大学でデータベースと情報検索の研究(@日本データベース学会)
前職：
- 大手SIer: オンライントレードシステム基盤
- 大手SIer: オープンソース技術部隊 (MongoDB等)
- リクルートテクノロジーズ: ビッグデータ分析基盤 (EMR, Hortonworks, BigQuery, Oracle Exadata)
現職：
- JapanTaxi: データエンジニア
エディタ：
- emacs派
趣味:
- 自宅サーバ
日本AWSユーザ会(JAWS)
ビッグデータ支部
自己紹介

3
3
800万DL超日本No1タクシーアプリ『JapanTaxi』
アプリマップ上で指定したピン位置にタクシーを手配。
全国47都道府県で約7万台と、全国のタクシー車両1/3がアプリで呼べる。
Google Mapsや音声AIなど様々な注文チャネル、決済、経費精算に対応。
*App Annie調べタクシー配車/ライドシェアアプリ内における、日本国内累計ダウンロード数/月間平均アクティブユーザー数(iOS/Google Play合算値)調査期間：2017年10月1日〜2018年9月30日
外部注文チャネル地図・経路検索
Google Maps iphone map
経費精算
Concur MoneyForward
タクシー配車アプリ『JapanTaxi』
海外
KakaoT TaxiGo
my route
iphone siri Alexa/echo spot mydaiz LINE clova
Yahoo!乗換案内
外部注文チャネル音声AI
NAVITIME setowa 信州ナビ Japan Trip Navigator

4
4
タクシー配車アプリ『JapanTaxi』
今いる場所行きたい場所呼ぶ

5
5
 やりたいこと
 作っているシステム
アジェンダ

6
Proprietary and Confidential ©2017 JapanTaxi, Inc. All Rights ReservedProprietary and Confidential ©2017 JapanTaxi, Inc. All Rights Reserved
やりたいこと

7
7

8
8
センシングカーとしてのタクシー車両

9
9
1日のタクシー動態の様子
タクシーは毎日大量に走り回っているため、
取得できるデータが膨大

10
10
白線検出
駐車場
満車・空車
ドラレコ動画を解析し、高付加価値な情報をつけてビジネスにする
工事現場
ガソリン
料金

11
Proprietary and Confidential ©2017 JapanTaxi, Inc. All Rights ReservedProprietary and Confidential ©2017 JapanTaxi, Inc. All Rights Reserved
作っているシステム

12
12
システムの全体像
クラウド
モザイク
処理
高付加価値
メタデータ
計算処理
動画の
受信
サーバ
センサデータ送付
動画送付
マップ
マッチ
センサ
データの
受信サーバ
送付すべき動画のリスト
復号
・
細分化

13
13
システムを作る上でのポイント
 マップマッチ
o マップマッチエンジンがDockerコンテナで配布されている
 動画復号
o OSにインストールするパッケージが必要（Pythonの外側の世界が必要）
 モザイク処理
o できるだけ低価格で機械学習の推論がしたい
• GPU使用率を限界まで上げたい
• モデルのロードなどのGPUを使わない時間を極力減らしたい
• 割安仮想マシンを使いたい
o 高い精度が求められるため、物体検出に加えて、各画像フレーム間での補間計算が必要
• 画像一枚を処理すればよいわけではない
• 推論の前後処理が重要
 高付加価値メタデータ計算処理
o できるだけ低価格で機械学習の推論がしたい
o 複数のデータサイエンティストがユースケースに合わせた様々なライブラリを使う
 分散処理
o 上記全てにおいて、タクシー台数の増加に合わせてスケールできる分散処理の仕組みが必要

14
14
技術選定にて没になった技術
候補メリットデメリット
サーバレス
コンピューティン
ティング
・インターネット上にノウハウが多く、開発が簡
発が簡単
・処理時間に制限がある
・GPUが使えない
・OSのパッケージがインストールできない
機械学習
サービス
・モデル開発のための環境が整っている・推論の前後処理の開発が難しい
・バッチ推論の度にリソースを確保するため、モデ
モデルのロード時間がもったいない
・OSのパッケージがインストールできない
仮想マシン+
Docker
・割安仮想マシン(※)が使える
・OSのパッケージがインストール可能
・モデルを一回ロードして長時間推論させられ
られる
・マップマッチコンテナがそのまま動く
・作り込む必要があるものが多い
・スケールイン・スケールアウト
・リソースモニタリング・コントロール
・コンテナデプロイ
・ログ参照
(※)割安仮想マシン＝GCPのプリエンプティブVMやAWSのスポットインスタンス

15
15
kubenetesの採用
 kubernetes採用理由
o 必要な要素が揃っていた
• コンテナが使える
• OSのライブラリが動く
• いろんなバージョンのライブラリを使い分けられる
• 作りこむ箇所が少ない（スケールイン・アウト、デプロイ、リソース制御、ログ参照）
• 割安仮想マシンが利用できる
• モデルを最初に読み込んで、長期間推論を実行し続けられる＝GPUを限界まで使える
 その他
o メルカリ社や米Lyft社がML基盤として採用している
o クラウドに(ある程度)依存しないように作れる

16
16
kubenetesによるシステムの構築
センサ
データの
受信
クラウド
モザイク
処理
高付加価値
メタデータ
計算
動画の
受信
サーバ
センサデータ送付
動画送付
マップ
マッチ
送付すべき動画のリスト
復号
・
細分化
Kubernetes
コンテナ
L
B L
B
クラウドが提供
オブジェクト
ストレージオブジェクト
ストレージ
データウェア
ハウス

17
17
OSイメージ
高付加価値メタデータ計算コンテナの構成
仮想マシン
GPU
ドライバ
GPU
Python
独自フレームワーク
推論プログラム
コンテナ最適化OS
データ
取得
モデル
推論
結果
格納
クラウドが提供
コンテナ
データエンジニア
担当
サイエンティスト
担当
利用ライブラ
リ宣言
requirements.
txt
データエンジニア
担当
オブジェクト
ストレージ
GPU
ライブラリ
データウェア
ハウス
キュー
ポイント
• サイエンティストとのIFには
独自フレームワークを用意
• コンテナ生成時に使用ライブラ
リ宣言ファイルを元にライブラ
リをインストール
• コンテナ起動時に、
モデルをメモリに読みこむ
URL URL

18
18
コンテナの配置とスケール戦略
仮想マシン仮想マシン仮想マシン
CP
U
CP
U
CP
U
仮想マシ
ンCP
U
仮想マシ
ンCP
U
仮想マシ
ンCP
U
データ
受信
マップ
マッチ
マップ
マッチ
データ
受信
モザ
イク
モザ
イク
メタデータ
計算
LB LB
メタデータ
計算
CPUノードプール GPUノードプール
GPU GPU GPU
キューキュー
料金が高いため、スケールイン・アウト料金が高くないため、一定数起動
（タクシー台数が増えてきたらスケールアウト）

19
19
 Ackしていないメッセージ数がしきい値を超えていないため、Podのスケールアウトは起きない
GPUノードプールのスケールイン・スケールアウト
キュー
Pod
HorizontalPodAutoscaler
Ackしていないメッセージ数 > 3
モニタリング
Ackしていないメッセージ数=2
仮想マシン
GPU
コンテナ
ReplicaSet
ノードプール
Cluster Autoscaler
最小=1, 最大=2
Running

20
20
 しきい値を超えたため、Podが増える。しかしPodはリソースが無いため待たされる(Pending)
キュー
Pod
モニタリング
仮想マシン
GPU
コンテナ
ReplicaSet
Pod
要求=GPU 1つ
コンテナ
ノードプール
Cluster Autoscaler
最小=1, 最大=2
Running Pending

21
21
キュー
Pod
モニタリング
仮想マシン
GPU
コンテナ
ReplicaSet
Pod
要求=GPU 1つ
コンテナ
ノードプール
仮想マシン
GPU
 Podが待たされているとノードプールがスケールアウトする。これでPodがRunningになる
Cluster Autoscaler
最小=1, 最大=2
Running Running

22
22
 良かった点
o kubecliが便利すぎる
• デプロイ、ログの確認、コンテナに入り込んでのデバッグ、すべてができる
• 特に同じ種類の複数のコンテナのログをまとめて見れるのは便利すぎる
o 知見が多い
• エラーが起きてもググればなんとかなる
 難しかった点
o ネットワーク構造が複雑
• クラウドのネットワークに加えて、kubernetesクラスタネットワーク、クラスタIP、ポッドのIPな
ど
• トラブったらデバッグできる自信がない
 全体的に
o 手軽にコンテナのデプロイ、スケールアウト、監視をするにはよい。
o 機械学習のユースケースにおいては他の機能は使わなくてもいだろう
• サービスメッシュとしての機能は不要。
• kubeflowは使う予定はない。
• エンドポイントの作成やモデル推定のパイプラインは今のところ不要なため。
所感

23
〒102-0094 東京都千代田区紀尾井町3-12
3-12 Kioicho Chiyoda-ku, Tokyo 102-0094 Japan
TEL 03-6265-6265 FAX 03-3239-8115
www.japantaxi.co.jp
文章·画像等の内容の無断転載及び複製等の行為はご遠慮ください。
Proprietary and Confidential ©2017 JapanTaxi, Inc.
All Rights Reserved

タクシードライブレコーダーの動画処理MLパイプラインにkubernetesを使ってみた

More Related Content

What's hot (20)

Similar to タクシードライブレコーダーの動画処理MLパイプラインにkubernetesを使ってみた (20)

More from Tetsutaro Watanabe (9)

タクシードライブレコーダーの動画処理MLパイプラインにkubernetesを使ってみた