『モビリティ・インテリジェンス』の社会実装 [DeNA TechCon 2019]
•Als PPTX, PDF herunterladen•
7 gefällt mir•37,875 views
DeNA オートモーティブでは「インターネット×AI」で交通システムにイノベーションを起こし、日本の交通システム不全を解消することをミッションに掲げています。本セッションではDeNAが考える「モビリティ・インテリジェンス」を社会実装した事例としてAI、ITS(Intelligent Transport Systems)、クラウド技術を結集してタクシーの行動を最適化するプロジェクトを紹介します。
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Ähnlich wie 『モビリティ・インテリジェンス』の社会実装 [DeNA TechCon 2019]
Ähnlich wie 『モビリティ・インテリジェンス』の社会実装 [DeNA TechCon 2019] (20)
Mehr von DeNA
Mehr von DeNA (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (9)
『モビリティ・インテリジェンス』の社会実装 [DeNA TechCon 2019]
- 1. #denatechcon #denatechcon 『モビリティ・インテリジェンス』 の社会実装 〜タクシー運行最適化を実現する機械学習システム〜 織田 拓磨 オートモーティブ事業本部 モビリティ・インテリジェンス開発部 益子 遼介 システム本部 AIシステム部 MLエンジニアリンググループ
- 6. #denatechcon アジェンダ タクシー運行最適化を実現する機械学習システム ＜前半＞ • タクシー事業における課題 • 運行最適化のアルゴリズム • 実証実験 ＜後半＞ • MLデータ基盤 • ML Ops
- 17. #denatechcon 17 横浜スタジアム 横浜駅 桜木町駅 石川町駅 黄金町駅
- 18. #denatechcon 流し需要の分析 GPS情報に対してマップマッチングを行い、道路別に乗車数を集計する 乗車数 Paul Newson and John Krumm. Hidden markov map matching through noise and sparseness. In GIS’09, pages 336–343, 2009
- 22. #denatechcon 行動系列の木探索 例）MCTS（Monte Carlo Tree Search） Silver, D. et al. Mastering the game of go with deep neural networks and tree search. Nature 529, 484–489 (2016)
- 24. #denatechcon マルコフ決定過程(MDP) 状態：現在走行中の道路 行動：どちらの方向に進むか（直進/左折/右折） 報酬：売り上げなど 環境 行動 a 状態 s 報酬 r 乗り場 流し移動 配車依頼 乗車移動 路上 エージェント
- 25. #denatechcon 強化学習による最適方策の獲得 例）Deep Q-Network (DQN) Mnih, V. et al. Human-level control through deep reinforcement learning. Nature 518, 529–533 (2015)
- 29. #denatechcon 自律分散的な全体最適化 各エージェントはリアルタイムの需要供給を考慮した方策に従うことで、 自律分散的に全体最適化を実現 T. Oda and Y. Tachibana, “Distributed Fleet Control with Maximum Entropy Deep Reinforcement Learning,” NeurIPS 2018 Workshop on Machine Learning for Intelligent Transportation Systems
- 32. #denatechcon
- 33. #denatechcon 逆強化学習（IRL）による報酬関数の推定 エキスパートの軌跡（デモンストレーション）から報酬関数を推定する C. Finn, S. Levine, and P. Abbeel. Guided cost learning: Deep inverse optimal control via policy optimization. In Proceedings of the 33rd International Conference on Machine Learning, 2016.
- 35. #denatechcon 概要 経路に従った場合どの程度の売り上げが達成できるかを検証する 実施期間： 11/14 - 11/28 参加人数： 10~20台/日 対象エリア： 横浜市都心部
- 43. #denatechcon MOV 機械学習基盤 on GCP ML Service Data Service ここは割愛 API Service 各種車両データのETL DWH データ前処理 MLモデルによる予測 ルート計算
- 45. #denatechcon 全体構成 Data Service API ServiceML Service API Service
- 47. #denatechcon Data Service の役割 機械学習で扱うデータを • リアルタイム • スケール • セキュア する基盤を提供する
- 48. #denatechcon データパイプラインの基本構成 •よくある構成 • 車両から秒単位で送信されてくるデータや、各種APIログをPubSubに集約 • ログは、搭載車両数に比例 • Dataflow StreamingでPub Subから集約したデータをBQにインサート PubSub Dataflow BigQuery GCS 同STAGE 15:10 「ゲーム開発者からMaaS開発者へ ゲーム開発のノウハウを活かして移動体情報配信システムを作ってみた」 < ~20sec デバイスからPubSubまでのデータパイプラインに関しては
- 49. #denatechcon データ前処理: 例: Map Match • ノイズの多い生のGPSデータを地 図上の道路に”マッチ(補正）” させ る • 内製高精度Map Matchサーバーを開発 • 実行数するワーカーを直に設定する必要 があるため、Kubernetes上にクラスタを 構築 • どちらのNodeも、処理量に応じて オートスケール Worker Worker Worker Map Match Server Pod Map Match Server Pod Map Match Server Pod Raw GPS Matched scale scale HTTP
- 51. #denatechcon BigQuery as DWH • ほぼすべてのデータをBigQueryに蓄積 • 列志向DB • 低ストレージコスト • 分散クエリ性能 • 運用レス • 分析用途だけでなく、プロダクションでの推論用データ生成にも利用 • BigQuery GIS • テーブルデータに対して地理的関数を実行できる • E.g ある地点から一定の距離内で起こったログを抽出する • まだ試験段階
- 52. #denatechcon 大規模データへのデータ分割対応 Partitioningによる時系列分割 • ログ時刻でのColumn-based partitioning Clusteringによる地域分割 • 車両の位置に基づくClustered Table 2軸の分割 データ流量が将来的に増加しても、 1データ＝1つのテーブルで完結しつつ、スキャン時間も一定におさまる
- 53. #denatechcon 大規模データへのデータ分割対応 Partitioningによる時系列分割 • ログ時刻でのColumn-based partitioning Clusteringによる地域分割 • 車両の位置に基づくClustered Table 日時ごとのパーティショニング( Ingestion-time partitioned table) に比べ、 • 格納時にタイムゾーンやログの日時判定処理が不要 • クエリがシンプルにかける • スキャン量が削減できるケースあり
- 54. #denatechcon 大規模データへのデータ分割対応 Partitioningによる時系列分割 • ログ時刻でのColumn-based partitioning Clusteringによる地域分割 • 車両の位置に基づくClustered Table 任意のカラムでデータ分割可能 • 車両位置で分割 … 地理分析がメイン • 車両IDで分割 … 車両分析がメイン
- 56. #denatechcon セキュリティ周り • MOVプロダクトとは独立したGCPプロジェクト • プロダクト環境からは書き込みのみを許可 • プロダクト経由の万一の鍵流出に備える • データ暗号化 • BigQuery、GCSへの顧客管理暗号鍵の設定 • Web経由の分析ツールへの対策 • 通信暗号化 • IP制限(Cloud Armor) • 個人認証(Cloud IAP)
- 58. #denatechcon ML Service 全体構成 ML Service
- 59. #denatechcon MLモデル開発フロー データサイエンティスト Model ML Playground in Kubernetes Docker Image 推論パイプライン Inference Route API Extraction Preprocessing DWH デプロイ MLエンジニア 分析/モデル学習 1 Iteration DB
- 60. #denatechcon ML推論パイプライン: Cloud Composer(Airflow) • 定期的に最新データを取り込み、推論ジョブを実行 • 処理自体は、専用のk8sクラスタへ • 独自オペレーターも実装している。 Job Job Job
- 62. #denatechcon Airflow: Gantt Chart Task A: データ抽出 Task B: 前処理 Task C: 推論
- 64. #denatechcon MLプロダクト運用でありがちなこと① • どうやってモデルを学習したのか、当時の担当者 しか知らない (再現性の喪失） • データサイエンティストから渡されたコードが実 行/再現できない (MLE <-> DSのコミュニケーションギャップ)
- 65. #denatechcon MLモデル運用でありがちなこと① • DS、エンジニアのインターフェースはDockerイ メージ • コミュニケーションギャップの解消 • 再現性の確保 • Kubernetesなどのコンテナエンジンに載せやすい データサイエンティスト MLエンジニア Docker Image
- 67. #denatechcon 精度の経年劣化について • タクシー需給トレンドの変化 • 超長期 … 年単位のトレンド (景気、乗務員数) • 長期 … 季節のトレンド • 中期 … 週単位のトレンド (年末年始、長期休暇) • 短期 … 時~日単位のトレンド (天候、イベント、電車遅延等) • 日々刻々と変化するタクシー動向に合わせて、機 械学習も“新鮮さ”(= より新しいデータで再学習) が重要
- 68. #denatechcon モデル精度監視ダッシュボード • 本番モデル推論の精度を監視 • Stackdriver + Grafana • ベースモデルと比較し、 エラーがあれば通知
- 69. #denatechcon CI/CD (On Going…) • 機械学習モデル開発のすべてを自動化したい • モデルの性能劣化検知→再学習→テスト→カナリアリリース • モデルの定期更新と新手法デプロイの融合 継続的なモデル手法開発 Model Model Week-1 Week-2 Week-3 Ver 1.0 Model ModelVer 2.0 Ver 3.0 Model Model Week-4 Week-5 定常的なモデル自動更新 Model 自動テスト/カナリアリリース
- 70. #denatechcon 「精度が落ちても破綻しないサービス設計」 • 機械学習モデルの特性上、精度の不確実性はつき まとう • 精度が出ない、モデルが機能しないなどのケース で適切なフォールバックを
- 71. #denatechcon まとめ • Kubernetes、Dataflow、BigQueryなどクラウ ド活用により、将来的にデータ量が増えてもス ケールするように設計している。 • MLであっても既存のDevOpsの手法は活用でき る • ITS x AIはまだまだ未開拓な領域 • 何をするべきか、何が必要かは自分たちが定義する。
- 72. #denatechcon 自己紹介 • 益子 遼介 (@soymsk) • MLエンジニア (MLE) • 2012年 ~ サーバーサイドエンジニア • 2015年 ~ (現) AIシステム部 • 分散処理基盤 • MLエンジニア • 2018年 ~ MLエンジニアリンググループ発足
Hinweis der Redaktion
- モビリティ・インテリジェンスという言葉を聞いた時、どのようなイメージを持たれたでしょうか。現在私が所属しているモビリティ・インテリジェンス開発部では、最新のアルゴリズム、クラウドサービスを上手に組み合わせることで、 「交通システムの最適化を実現する人工知能」を持続可能な形で社会に実装し、交通の問題を解決していきたいと考えています。
- モビリティ・インテリジェンスという言葉を聞いた時、どのようなイメージを持たれたでしょうか。現在私が所属しているモビリティ・インテリジェンス開発部では、最新のアルゴリズム、クラウドサービスを上手に組み合わせることで、 「交通システムの最適化を実現する人工知能」を持続可能な形で社会に実装し、交通の問題を解決していきたいと考えています。
- DeNAオートモーティブ事業本部ではタクシー配車アプリやC2Cのカーシェアリング、自動運転タクシーのアプリケーションなど様々な事業開発を行っています。 MI開発部はオートモーティブ事業本部の横断組織として、個々のモビリティサービスの最適化だけでなく、統合したモビリティサービス全体の最適化に取り組んでいます。 ＜メモ＞ また、MaaSという言葉がありますが、既存の公共交通機関とオンデマンドやシェアリングサービスを統合的に提供することができるようになれば、車を保有するよりもより良い生活を実現するサービスを作り出すことができるかもしれません。そのためにもこのMIが重要であり、例えばダイナミックプライシングによるモード間の需要平準化出会ったり、鉄道輸送障害時にオンデマンドバスの本数を増やすなどの制御が必要になります。
- 本発表ではMIの社会実装事例として、DeNAが特に注力しているタクシー交通システムの最適化の事例を紹介したいと思います。
- タクシー運行を最適化するとはどういうことでしょうか？
- DeNAはタクシー配車アプリMOVを東京・神奈川で展開しており、多くの利用者にご利用いただいております
- ・実は日本のタクシー需要全体のうちアプリ配車が占める割合はわずか1%程度であり、MOV導入地域で需要創出効果が期待できるものの欧米と比較すると非常に低いのが現状 ・タクシー交通システムの最適化のためにはアプリ配車以外の乗車手段に対するソリューションも必要となる
- また、タクシーが利用者を見つける効率は乗務員のスキルに大きく依存しています。 こちらはタクシー乗務員の売り上げの分布を図示したものです。 乗務員の中でもスキルによって約２倍の生産性の差があることがデータからわかっています。 したがって、乗務員の探客スキルの底上げが鍵と言えます。
- このような背景から特に経験の浅い乗務員さんの生産性を高めるため、MI開発部ではタクシー探客に関わる意思決定を行うAIの開発を行ってきました。
- 実現したい機能は非常にシンプルです。 タクシーが空車になった時に、現在位置を与えると一定時間先までの最適な探客経路、つまりお客さんを見つけやすい経路を返してくれるAPIです。 それでは、このようなAIを実現するためにどのような問題を解く必要があるかを説明します。
- こちらは現実のタクシー探客の世界を簡略した図になります。 路上でタクシーを待っている人、乗り場で待っている人がいたり、 タクシー車両についても空車で移動している車両や乗車中の車両がいます。 このような状況であるタクシーにとって最も乗車が発生しやすい経路を見つけたい、という問題です。 この問題はダイクストラ法などの効率的な最短経路探索のアルゴリズムを使って解くことができない 目的地が与えられていないこととコストを最小化するという問題で表現できないことによります
- この問題を解くアルゴリズムを設計する上でのチャレンジとしてここに挙げられているものがあります。 まず、道路レベルで需要供給予測が必要になります そして、利用用途として空車になったタイミングですぐに経路をすぐに推薦することを考えると、長くても数秒で経路が探索できることが必須です。 また、複数車両がアプリケーションを使うことを想定すると全体として最適となるような経路を考えなければいけません。 最後に乗務員さんにとって使いやすく、走りやすい経路が求められます。 これらの４つについて順を追って詳しく見て行きたいと思います。 ＜メモ＞ また、一回のリクエストでどの程度先の未来までの経路が必要か？経路の途中変更(延長)は可能か？ この二つの問題を考える必要がある。 極端な話、経路の変更や延長が容易であれば、１道路単位で指示を送れば良いということになり、この場合、リアルタイム性を考慮して臨機応変に変更することができる。これはクローズドループの問題と呼ばれる。 しかし、１道路単位で経路を指示するのはレーンチェンジの必要性や安全面、また乗務員にとってのストレスを考えても現実的ではない。従って、オープンループの問題として考える必要がある。つまり、一定時間先までの経路をリクエスト時に返し、経路の変更は基本的にはできない。クローズドループのケースと比べて不確定性が大きい未来の行動についてもより精度が必要とされる。
- まず、需要供給予測です。
- 先ほど説明した様々な状態情報、例えば、路上で待っている人は事前に直接観測することができません。 従ってまず、システムの状態である需要や供給情報を観測できるデータから推定する必要があります。
- こちらはタクシープローブ情報として毎日大量に集約される乗車ポイントの一例です。 なお、プライバシー保護のため情報は編集加工した上で可視化しています。 こうした膨大なタクシープローブ情報が日々収集・蓄積されています
- 収集した膨大なプローブ情報を使って様々な分析をしています。例として流し需要の分析を紹介します。まず、車両のGPS情報をマップマッチングとういアルゴリズムを使って道路に紐づけることで道路単位の集計が可能としています。そして、各曜日/時間帯ごとに道路別に乗車数を集計することで、道路ごとに右図のような時間特性データを作ることができます。このような需要の統計的な時間特性データを全ての道路において整備しています。
- 天候やイベントなどの外部要因や直近のトレンドを考慮するため、機械学習モデルを使って需要予測を行っています 特徴量としては 直近の乗車数 周辺の乗車数 乗車数の統計量など を使い、次の３０分間に発生する乗車数を予測しています。 モデルとしては勾配ブースティングのライブラリであるlightGBMを使っています。
- 次に探索の効率化のお話をします。
- もともとときたかった問題はある車両の最適な経路を見つけたいというものでした
- 最適な行動系列を探索する一般的な方法としては木探索のアルゴリズムがある。 例えば囲碁のAIで有名なDeepMindのAlphaGoではMCTSという木探索アルゴリズムを使っている。 内部ではゲームの最後までのシミュレーションをなんども実行し、最も良い手を探っている。 しかし、木探索は一般的に非常に計算コストが高いです。囲碁の場合、次の手を決めるために１分程度の長い時間が使える上、ビジネス性を考える必要がなく莫大なリソースを用いることができる。 経路探索の場合はオンデマンドでしかも次の一手だけでなく、経路、つまりまとまった行動系列を返す必要があります。またビジネスで使うため計算リソースの効率化も重要となります。したがって木探索を直接使うのは難しいと思っています。 AlphaGoでは、MCTSでは枝を展開する際やシミュレーション時に機械学習や強化学習で獲得した方策を活用することで探索の効率化を実現しています。
- 方策という概念を説明するため、マルコフ決定過程というモデルを考える。 MDPでは環境とエージェントという概念があります。「環境」は各時刻においてある状態sを取り、意思決定を行う「エージェント」はその状態において利用可能な行動aを任意に選択する。 その後環境はランダムに新しい状態へと遷移し、その際にエージェントは状態遷移に対応した報酬rを受けとる。 MDP における基本的な問題設定は、累計報酬を最大化するような方策を求めることです。ここで、方策とはある状態においてエージェントがどのような行動をとるべきかを表す「状態から行動へのマッピング（確率分布）」です。
- 今考えている問題をマルコフ決定過程でモデル化することができる ・エージェントはあるタクシー、環境はそれ以外の全て ・状態はエージェントが現在走行中の道路 ・行動はどちらの方向に進むか ・報酬は売り上げ あるタクシーの累計報酬を最大化する方策というのは ある道路を走行しているときに将来に渡って売上を最大化するためには次にどちらに進むべきかを表す関数となります。
- このMDPをとくフレームワークとして強化学習という手法があります。 強化学習は環境との試行錯誤を通じて、累計報酬を最大化する方策を獲得する方法である。 例えば、 Atariというゲームを攻略して有名になったDQNという手法は、ゲーム画面のイメージを入力（状態）、行動ごとの価値を出力とするニューラルネットワークをゲームのシミュレーションをなんども実行しながら学習する手法です。 強化学習には様々なアルゴリズムがありますが、問題をMDPに定式化することで、強化学習を使って方策を求めることができるようになります。
- 方策が求まれば、非常に簡単に経路を生成することができます。 こちらはMDPの状態と取りうる行動を図にしたものです
- 出発地点からある時間分の行動系列（経路）を方策に従って探索して行きます。 事前に獲得した方策を使っているため、リクエスト時にはこの処理だけしか行われません。囲碁などと異なり、次の状態が決定論的に求まるので非常に高速に経路を生成することが可能です。
- これまで個別のタクシーの最適化の方法についてお話ししてきましたが、全体最適化の考え方を説明したいと思います。
- 全体最適化を実現するために、リアルタイムの需要供給予測結果を方策に反映しています。 これによって各エージェントはリアルタイムの需要供給バランスが考慮された方策に従うので、自律分散的に全体最適化が実現されます。これは例えば需要が高い場所でもその場所が供給過多であれば乗車確率が下がるのでそういった場所へは案内されなくなるためです。 乗務員が歩合制であることを考えると、グローバルな報酬関数を最大化するよりも、自律分散的に個々の報酬関数を最大化する方法が現実的と考えています。
- 最後にユーザー体験、つまり乗務員さんにとってのUXの重要性についてです。 乗務員さんに快適に使っていただくためにアルゴリズム設計で考慮した点に紹介したいと思います。
- まず、もともと最適探客経路を求める問題と紹介しましたが、そもそも何をもって最適とするのかという問題があります。MDPで問題を定式化したため、最適化というのは平均累計報酬の最大化という意味でした。 さきほどは簡単のため単純に報酬を売り上げとしましたが、売り上げさえ良ければ本当に良いのでしょうか？
- 例えば、このような経路を見せられると乗務員さんは混乱してしまうかもしれません。 乗務員さんに快適に使ってもらうことを考えると、売り上げ以外にも、安全な道であったり、頻繁に右左折しないなどの要件が考えられます。 基本的に、MDPにおける報酬関数についてはマニュアルで決める必要があり、問題によっては自明でないことも多いです。 また、実際に設計した報酬が正しいことを評価することも非常に難しい場合があります。
- そこで、報酬関数をデータから推定する方法として、逆強化学習（IRL）というフレームワークを紹介したいと思います。 IRLはエキスパートの軌跡（デモンストレーションデータ）が与えられている時に,、そのエキスパートがどのような報酬関数に基づいて行動しているかを推定する手法で、今でも精力的に研究が行われている分野です。 Guided Cost Learningはニューラルネットワークを使ったIRLの手法であり、ロボットに皿を並べる動作やコップを注ぐ動作を人間が教えてあげ、この模範データを元に報酬関数を学習しています。 今考えている問題についても個々のタクシーにとっての報酬関数をエキスパート、売上の高い乗務員の走行軌跡から推定できます。これにより、より自然で走りやすい経路が生成られることが期待できます。 ＜メモ＞ 推定した報酬関数をもとに強化学習により方策を獲得するステップと 獲得した方策の軌跡とデモンストレーションの軌跡が一致するように報酬関数を更新するステップを繰り返すことで最終的に報酬関数を求める方法で
- アルゴリズムの評価をするため、このAPIを元にナビゲーションアプリを開発し、実証実験を行いました。
- 今回の実証実験の目的は「経路に従った場合どの程度の売り上げが達成できるかを検証する」ことです。 横浜市都心部で２週間、２０台程度の車両を貸し切って、実証実験を行いました。 空車中は基本的にずっとナビに従って走行していただきました。
- 実証効果はこのようになりました。 ヒストグラムが対象エリアの乗務員全体の売り上げで、丸がナビに従った場合の売り上げです。 このように、全体の売り上げ平均と同程度の売り上げを達成することができました。 これはつまり、売上が平均以下の乗務員が利用すれば生産性向上が期待できる 「実車時間率 」 = 実車時間 / 稼働時間 で評価 対照群全体： 27.0%（一時間当たり売上：2,875円） ナビ通り走行上位10名: 24.5%（同：2,865円）
- 現在、実証実験で得られた知見や課題を元に、プロダクト化に向けた改善に取り組んでおります。
- 最後に自己紹介をしたいと思います。
- それでは、私から、MOV機械学習基盤のお話をさせていただきたいと思います。
- 始める前に、少しアンケートをとらせてください。 会場にいる方で、今、GCPを使っているあるいは、使ったことがある、という方どれくらいいらっしゃいますか？
- 次に、GCPでMLやデータ基盤を作っている、またはいた、という方、 ありがとうございます。 本日、あまり１つ１つのGCPのプロダクトの紹介はしない予定です。 わからないものがでてきても、今回の発表を聞いて、これってなんだっけ、あるいはこういうことがしたいんだけど、これ使えるの？といったことがあれば、発表のあとにAsk the Speakerというものがあるので、そこで聞いていただくか、直接Twitterなどで気軽にコンタクトをとっていただければと思います。 基盤を考えるのが好きな人間なので?
- それでは、改めて本題のMOV機械学習基盤のお話をしたいと思います。
- MOVの機械学習基盤は、3つのコンポーネントで構築されています。 １つめは Data Service ここには、各種データのETLや、データウェアハウスが含まれます。 また、機械学習向けのデータ前処理も、ここで行います。 「ML Serivce」は、その名の通り、機械学習による推論を行うものになります。 また「API Service」は、ML Serviceが推論した結果を元に、各車両のルーティングを担っています。 現在、これらすべて、GCP上に構築しています。 今回、最後のAPI Serviceを除く、2つのコンポーネントについて、お話したいとおもいます。
- こちらが3つのコンポーネントを含めた全体像です。MOVにおいては複数の機械学習モデルが適用されているため、複数のパイプラインが併存しています。
- 先程の３つのコンポーネントはこのように分割できます。 基本的に、Data Serviceが機械学習用のデータを生成、蓄積し、ML Serviceがそのデータをつかって各種推論、API Serviceで推論結果を元に車両のルーティングを行っています。 先程、地図上に値をプロットしたビューワーのデモをお見せしましたが、そちらはAPI Serviceに属します。
- まずは、機械学習にもちいるすべてのデータを扱う 「データサービス」です。
- データサービスの役割は３つです。 機械学習で扱うデータを、「リアルタイム」に、かつ将来的にデータ量が増えても「スケールする」ように、「セキュアな形で」、提供することです。
- データパイプラインの構成自体は、GCPを使ったことがある方であれば、スタンダードな構成だと思います。 MOV搭載車両から送られてくるログはすべて、まず「左の」PubSubに入ります。 格納処理はDataflow の Streamingジョブで行っていて、Dataflowは処理量に応じてワーカーがスケールします。DataflowによってMOV搭載車両が今後増加しても、パイプラインはスケールするようにしつつ、PubSub以降に入ってきたログデータは数秒でBigQueryにインサートできています。 ここで、PubSub以前のデータ収集機構については、このSTAGEでこのあと公演される、弊社恵良より、発表させていただきますので、是非ご参加ください
- ここで、データ前処理の一例について紹介します。 GPSデータって非常にノイジーなデータなんです。MOVではタクシーの位置情報は、スマートフォンのGPSデータを使っていて、GPSモジュールそのものの精度の問題や、周囲に高いビルがある地区では電波の反射でノイズがのってしまうんですね。 そのままでは正確な統計値が算出できないため、ノイジーな位置データを補正する必要があるわけです。タクシーの場合は、車両なので車道を走っているはずですので、走行しているだろう車道上に位置を補正してやればよさそうです。この補正処理をモビリティ業界において「マップマッチ」と呼びます。 DeNAでは、より精度の高いHidden Markov Modelにより確率的に道路を推定補正する内製MapMatchサーバーを開発しています。 このサーバーをKubernetes上にクラスタとして構築し、Dataflowからリクエストを送ることで、大量の位置データをマップマッチさせています。 ここで、MapMatch処理をなぜDataflowのワーカーでやらないのか、そのほうがシンプルじゃないかと思われる方がいらっしゃるかもしれません。 その理由としては、MapMatchサーバーは初期化時に大量の地図データをメモリに乗せる必要があり、初期化コストが高いので、ライフタイム管理ができるk8s Podとして立てています。また、高速化のためにカーネルパラメータをチューニングする必要があることも理由の１つです。 どちらの計算ノードも、処理データ量に応じてオートスケールするため、データ増加にも対応できるわけですね、
- 次に、データウェアハウスをどのように作っているかお話します。
- MOVにおいては、BigQueryをデータウェアハウスとしてすべてのデータを集約しています。 なぜ、BigQueryを選んだかというと、DWHの選定にあたって、いくつか観点がありました。
- 全車両の位置を秒単位で蓄積していくと、あっという間にデータ量が膨れ上がります。 膨れ上がったデータをただそのまま蓄積するだけでは処理不可能になってしまうので、BigQuery上で扱いやすいように適切な分割処理をほどこして格納する必要があります。
- MOVにおけるモデル開発のフローは、まず、k8s上にあるJupyter Hubを使って、データサイエンティストがデータ分析/モデル学習を行います。 一定の精度が出たモデルを、MLエンジニアがイメージに固め、推論パイプラインにデプロイします。 推論パイプラインは、MOVにおける機械学習推論に必要な各処理を、依存関係を考慮して実行するジョブになります。 推論パイプラインは定期的に実行されており、先程のDWHからデータの抽出、加工、推論を順に実行します。車両のルーティングは、最新のジョブが生成した推論結果を元に、各車両のルーティングを行います。 パイプラインの各処理は、すべてDocker Image化してデプロイしています。
- 実際にパイプラインを実行するためのワークフローエンジンとしてCloud Composer 、GCPのマネージドAirflowですね、を使っています。 Airflowが、各処理の依存関係を管理しており、定期的に実行します。 処理自体は、別の強いノードスペックをもったクラスタにジョブとして投げています。 Airflowは簡単に独自オペレータが実装できるので、
- Airflowはジョブのメトリクスをいろいろ出してくれます。たとえば、Landing Timeをみれば、実行ジョブの処理終了時間を把握することができ、処理の遅かった実行を見つけることができます。
- Gantt Chartもあり、各処理がどの程度時間がかかっているか一覧できるので、遅い処理を見つけて改善するのに使えます。
- ここまでで機械学習基盤の全体像はお話してきました。 次に、機械学習プロダクト全体を、どのようにつくっていったのか、運用の観点からお話をします。
- MLプロダクト運用でありがちなこと、まず1つ目は、~ 2つ目は〜
- これはどのように扱えばいいのでしょうか。 Movでは、取り組みとしてDS、エンジニアメンバー間のインターフェースをDockerイメージに集約していこうとしています。 これによって、コミュニケーションギャップの解消、「再現性の確保」を解決しています。 また、Dockerイメージにすることで、k8sなどのコンテナエンジンにすぐ乗せることができます。
- 機械学習モデルに関わる、あらゆるタスクを自動化したいと考えています。 これはエンジニアにとって自然なことだと思います。 モデルの性能劣化を検知したら、 定期的なモデルの更新と、新しい手法の開発を両立したい。 最初にリリースしたバージョンのモデルは、定期的に自動で再学習されている状態で、Week 1 Week-2 データサイエンティストが新しい手法を開発したとします。 その場合、ある時刻で両者のモデルを精度比較し、良かったほうを採用します。 以後は、よりよい手法で生成されたモデルが継続的に生成されます。 このように、モデル自体を入れ替えるのではなく、モデル生成のパイプライン自体をバージョン管理して、アップデートしていく、という方法を今作っています。
- もう一つ、重要な観点をお話します。
- MOVにおける機械学習基盤では、k8s, Dataflow , BQ また、機械学習プロダクトにあっても、ITSの領域であっても、監視やCI/CD周りなど、既存のDevOpsのノウハウは十分に通用すると思っています。 この領域はまだまだ未開拓な部分が多く、私達もTry & Errorを重ねながら進めています。 難しい部分もありますが、とてもチャレンジングなプロダクトだと思っています。
- 最後に、今日お話させていただきました、自分の紹介をさせていただきます。 MLエンジニアの益子です。2012年に新卒でDeNAに入社しました。 MOVの機械学習基盤のエンジニアリングリードをしています。 入社当初はサーバーサイドエンジニアをやっていましたが、2015年より、DeNAのAI研究開発を担うAIシステム部に異動し、MOVには一昨年より関わっています。 昨年、Machine Learningをプロダクトに適用するためのエンジニアリングを担うMLエンジニアリンググループが発足し、自分もそのメンバーです。