ちょっと話題の記事

[AWS Summit 2018 Tokyo] AWS IoTフル活用!DeNA オートモーティブにおける AWS 活用事例 #AWSSummit

事例セッション「DeNA オートモーティブにおける AWS 活用事例」のレポートです
2018.05.30

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

こんにちは、菊池です。

本記事は、現在開催中のAWS Summit 2018 Tokyoで行われた事例セッション「DeNA オートモーティブにおける AWS 活用事例」のレポートです。

セッションで紹介された配車アプリ「タクベル」は、展示ブースでもデモをやっており、構成や動作を聞くことができます。

セッション概要

DeNA オートモーティブは今までのシステム開発と異なり IoT 的な要素を多く含みます。

どのようにクラウドを活用しイマドキなシステムにフィットさせているのか、また、オートモーティブならではのお話を技術成分多めでお話します。

株式会社ディー・エヌ・エー システム本部 執行役員 システム本部 本部長:小林 篤 氏

レポート

自己紹介

  • 法学部卒で社会人になってから開発者に
  • 2011年にDeNA入社(4社目)
  • ゲームプラットフォームの開発責任者
  • 2017年よりオートモーティブ事業の責任者
  • 社団法人Japan Perl Associationの代表理事

DeNAのオートモーティブ事業

  • DeNAの強み
    • インターネット+AI
    • パートナリング
    • 事業化能力
  • サービスの分類は大きく2つ
    • 車両提供
    • 車両+ドライバー提供
  • 提供サービス形態
    • Anyca
    • タクベル
    • EasyRide
    • RobotShuttle
  • 自動車メーカー(車両提供)+サービス事業者
    • 車両の制御はまだやってない(OEMメーカが負うべき安全・安心に関わるところ)
    • 上のレイヤ(データセンター間)でのAPI連携
  • コネクテッドカーの領域
    • 車両上に情報通信の機能+データセンター
  • DeNAはサービス事業者
    • MaaSと呼ばれる領域
    • 自動車メーカの付加価値領域(車両をベースに付加価値をつけていく安心、安全)
    • DeNAの付加価値領域
    • モビリティサービスプラットフォーム

タクベルの裏側

  • タクベルとは
    • 次世代配車アプリ
    • 特定のタクシー会社に依存しない
    • タクシー会社の船に乗り、Uber/白タク、海外大手勢にも勝るサービスを提供する
  • 課題
    • 配車確定前に目安時間がわからない
    • ネット決済
    • 正確な位置
    • など
  • 需要の取りこぼし防止による利用回数増
  • 乗務員による生産性ばらつき改善
  • リアルタイムなデータ収集
  • 道路セグメントの需要予測
  • 高精度なタクシー交通シミュレータ

技術要素

  • IoT
  • DriverApp
  • UserApp
  • ITSアルゴリズム
  • HardWare

 

  • 中長期的に陳腐化しない技術
  • 短期的にも開発スピードを出せる技術

設計方針

  • クラウドの得意分野、機能の豊富さ、使い勝手、将来性をみて取捨選択
  • AWSを多く活用している車両周辺
  • オートモーティブだけでなく、IoT全般にも共通する考え方

(展示ブースにて許可をいただき撮影しています)

車両および車載端末からの情報取集

  • タクシーメータ
    • 車両情報
    • ステータス(空車など
    • 料金情報
  • 車載端末
    • GPSなどのメータ経由では取れないもの
  • ハードウェア構成
    • BLE Logger
    • Androidスマートフォンを使ってクラウドへ
  • AWS IoTのTopicにMQTT(TLS 1.2)でサブスクライブ
  • なぜAWS IoT/MQTTなのか
    • 数万単位の車両からリアルタイムにデータを収集するのにMQTTが最適
    • HTTPはオーバーヘッドが大きく不適切
  • 現在は2500台が稼働中
    • 今後、数万単位のタクシー導入を目指している
  • 今後、N万の接続に対応するために
    • 送信データはBSONでシリアライズ化し、差分情報を送ることで効率化
  • クライアント証明
    • どのようにしてN万台の接続を前提に、クライアントを証明するのか
    • クライアント(車載デバイス)とBLEデバイスの組み合わせでAPIからワンタイムトークンを取得する
    • トークンを使ってLambda経由でクライアント証明書を取得する
    • 盗難があったらそのクライアント証明書をREVOLEするだけでよい
    • トークン取得は1回限りなので再取得できない
    • クライアント証明書を作る流れでデバイスシャドウなども用意

データ通信処理

  • IoT Topic -> Rule -> Action -> LambdaでBSONをJSONにコンバート
  • その後ろの処理でIoT TopicにrePublish
  • 用途ごとに3つに枝分かれしてrePublishする
    • 分析用データKinesisでバッファリング、DWHにPUSH
    • 検索用データElasticsearch Serviceに保存
    • モニタシステムへリアルタイムに配信しRuleエンジンからIoT Topic にrePublish
      • データはSTSで参照できるデータを権限制御

オートモーティブ領域のAWS

  • これらを実現する最適なソリューションである
  • 自分たちでMQTTのサーバ建てるとかやらなくていい

得られた知見

  • 安直に設計すると高くつく
    • Lambdaは高い
      • バッファリングを使って、一定量をまとめて処理することで効率化
      • IoT Actionでできるものはそちらでやる
      • あえてLambdaを使わない処置にする
      • BSON -> JSON変換だけLambdaを利用
    • エッジからあげるデータを最小化する
      • 差分はSHADOWに入ってるデータで吸収
    • 作りこむのではなくパズルを工夫するイメージ

最後に

  • Anyuthing,Anywhere
  • 社会問題を解決するための技術
  • 自社だけではなく、他社のいいところを活用

ITS Tech Study #2

  • 6/8(金)に開催
  • 募集ページ
  • 詳しい構成など聞けるそうです!

まとめ

AWS IoTをフル活用した、数万台に耐えるサービスの裏側が紹介されました。

興味深かったのは、IoTデバイスシャドウで送受信するデータを最小化している点と、IoT Actionを多段に繋ぐことで、Lambdaの使用を最小限にするその構成です。

展示ブースでも詳しく話を聞くことができますので、気になる方は行ってみましょう!