AWSで構築したシステムでは主に、車両に関するデータをリアルタイムに収集し処理する。これらのデータを取得する機器は、大きく分けてタクシーメーターと車載端末（SIMカード搭載Androidスマートフォン）の2種類だ。それぞれ以下の情報を収集する。

• タクシーメーター
  • 各種車両情報、ステータス情報、料金情報
• 車載端末
  • GPS（全地球測位システム）で取得した位置情報など、メーターで取得できない情報

　DeNA独自開発の専用デバイス「BLE Logger」が、これらの情報を含むデータを収集。車載端末のインターネット回線を通じてデータをAWSへ運ぶ。これらのデータを、AWSと各種機器をつなぐサービス「AWS IoT」に用意したトピック（通知用通信チャネル）に都度送信する流れだ。このプロトコルにはMQTT（通信路暗号化にTLS 1.2を利用）を使用している。なぜMQTTかについて小林氏は、HTTP／HTTPSと比べてオーバーヘッドが少ない点を挙げた。「タクベルは既に2500台の車両に導入しているが、今後は数万台に増える予定だ。数万台の車両が毎秒サーバにデータを送信すれば膨大なトラフィックが発生する。なるべくリアルタイムに処理するため、IoTでよく使われるMQTTを選択した」と同氏は述べた。このMQTTを使うサービスとして、AWS IoTが最適だったことも付け加えた。

図1　ハードウェア構成

送信データはBSONでシリアライズ化

　スマートフォンからのデータ送信にも工夫を凝らしている。データ変換フォーマットにはバイナリ型JSONの「BSON」を使用し、エッジ側で更新差分のあるデータだけをサーバ側に送ることで通信の効率化とコスト抑制を実現している。

クライアント証明書

　エッジ側のデバイスをサーバ側が証明する方法についても対策を立てている。車載端末とBLE Loggerの組み合わせ（＝クライアント）を、サーバ側にマスターデータとしてあらかじめ登録しておく。初回、そのクライアントの組み合わせでサーバ側に問い合わせをすると、マスターデータを管理するAPIが1回だけワンタイムトークンを用意する。取得したワンタイムトークンでAWS Lambdaにリクエストを送ると、エッジ側にクライアント証明書を返す。この証明書を使ってAWS IoTとの接続を保証する。

　万が一、エッジ側のデバイスが盗難に遭った場合は、発行したクライアント証明書をrevokeする（取り消す）だけでよい。クライアントの1種類の組み合わせに対して1回しかトークンを取得できないため、悪意のある第三者が新しく証明書を発行することは不可能だからだ。なお、クライアント証明書を取得する流れでAWS IoT側に車両のIDをキーにした「デバイスシャドウ」（デバイスの状態情報を管理するJSONドキュメント）を作り、データを受ける準備を整えている。

分析データ

　AWS IoTがデータを受け取った後には、次のような処理が走る。

1. AWS IoTのトピック（例：provider/taxibell/@status.bson）に、車両単位でデータを送信
2. データ形式がBSONのため、AWS Lambdaを起動しJSONに変換
3. 変換されたJSONをデバイスシャドウに記録。Thing Shadowは車両単位で用意。小林氏は「リアルタイムに更新されるマスターデータの扱い」と説明
4. その後の処理に流すために別のトピックへ「republish」（再送信）

図2　データ通信の後処理

　データのrepublish後は、「AWS IoT Rules Engine」（トピックの更新を受けて、AWSの他機能を起動する仕組み）によって処理が3つに枝分かれする。

1. 分析用データの保存
   1. 受け取ったデータを分析やAIのアルゴリズム開発に使うために、分析データとして保存する
2. 検索用データの保存
   1. 車両のデータを検索サービスに利用する。例えば現在地から半径400メートル以内で配車できる車両を調べるケースがある。データは検索エンジン「Amazon Elasticsearch Service」に保存する
3. 監視システムへのデータのリアルタイム配信
   1. 車両の位置などをリアルタイムで監視する管制システムに、データを配信する

図3　AWS IoT Rules Engineによる3つの処理

　分析データは、AWSではない別のクラウドのDWH（データウェアハウス）に送信する。ただしAWS IoTのトピックにきたデータを別のクラウドへ都度プッシュしていては、コスト面でも非効率的だ。そのためストリーミングデータ処理の「Amazon Kinesis」でバッファリング（一時保存）処理をして、データが一定量に達してからAWS Lambdaにプッシュするようにしている。小林氏は「これをやらないとコストが跳ね上がる」と説明した。

AWS活用で得られた知見

　DeNAは、上記のようなデータ収集処理基盤の大部分をAWSの機能を組み合わせて構築している。「もしAWSがなければ、MQTTのサーバを自社で構築し、冗長化することになっていた。何万台もの車両が接続するシステムに必要なサーバ台数の計算や、インフラの用意も全て自分たちでやらなければならなかった」（小林氏）。AWSの機能を多数活用したことで、こうしたインフラの作業から解放され、「Webサイトや配車アプリケーションなど、ビジネス領域に関わる開発に多くのリソースが割けた」と小林氏は振り返った。

　AWSの利用に当たっては注意点もある。「AWS Lambdaは、安易に設計すると高くつく」（小林氏）。イベント処理に最適なAWS Lambdaだが、BSONからJSONへのデータ変換処理に限るなど最低限の利用に留めておくことを小林氏は勧めた。実際にDeNAも、Amazon Kinesisによるバッファリングで一定量をまとめて処理することで、AWS Lambdaの起動頻度を抑えてコスト削減を図っている。

図4　Lambdaについて

　DeNAにとってオートモーティブ事業は、単なるビジネスではなく、社会課題を解決する取り組みという意味合いが強い。「交通系サービスは社会インフラになる。そのため短期ではなく中長期的な戦略を見据える必要がある」（小林氏）。それを支えるアーキテクチャも、中長期にわたり陳腐化しない技術かどうかを重視しているという。とはいえサービス開発にはスピード感も重要だ。それをクラウドが補う。今回AWSは、スピード感、機能の豊富さ、使い勝手、将来性を見据えて選ばれた。「DeNAは、自社だけでは解決できない課題や事業に取り組んでいる。いろいろなパートナーと連携しながら、社会問題を解決したい」と小林氏は語った。