※この記事はLuup Advent Calendarの3日目の記事です。
こんにちは。
この記事ではIoTチームから、LuupのIoT、とりわけMQTTに関連するアーキテクチャの改善事例について紹介します。
MQTTにまつわる問題いろいろ
Luupでは通信プロトコルにMQTTを用いた車両（下図の Device ）を使用しています。
このMQTTを用いた通信に関していくつか問題点がありました。
変更前のアーキテクチャでのフロー
- 車両から解錠や施錠の状態変化を受け取るためにMQTT BrokerをSubscribeするためのVMが必要 (⑤⑥)
- MQTT BrokerにID/PASSしか設定されておらずセキュリティー的に問題 (②③④⑤)
- 車両の台数が増えた時にMQTT Brokerを複数台にして水平分割が必要
セキュリティーの問題は車両側の仕様に依存していて、SSL通信を用いたMQTTSを用いたくても車両側で対応することが難しく使用できないという状態でした。
どう改善したか
SORACOM Beamというデータ転送サービスを軸にしてアーキテクチャを再構築しました。
SORACOM Beamとは、SORACOMのSIMを使用している場合、その通信をSORACOM上に設定した任意の場所に転送できるサービスです。
SIM単位で転送先の設定が可能です。
変更後のアーキテクチャでのフロー
- SORACOM Beamを用いて通信を閉域網化 (④⑤)
- AWS IoTはMQTTS、SSL通信のコストをBeamにオフロードしつつセキュアに (③⑥)
- AWS IoTを用いることでMQTT Brokerのスケーラビリティのことを気にしなくて良い状態に
- VMの管理からの開放 (⑦)
⑦はAWS IoTのHTTPSコール機能を用いています。
厳密にいうとAWS IoTを用いても車両の台数が増えれば水平分割する必要があります。
しかしVMで管理していた時よりも遥かに多くのトラフィックを捌くことができるので、実質的に考えなくて良いようになりました。
また副次的効果として、車両の接続先を本番環境から開発環境に切り替える際、車両の設定を修正する必要なく、SORACOMのWebコンソール上で車両ごとに変更が可能になりました。
市場不具合が発生した車両をサービスアウトして開発環境で調査するということもかなり簡単に実施することが可能になりました。
さいごに
Webだけの世界だとあんまり見ないSORACOMというサービスですが、Luupでの活用事例をご紹介しました。いかがでしたでしょうか。
興味が湧いて話を聞いてみたかったり、いやこれこうした方がいいんじゃないか、なんてご意見含めて気軽にご連絡頂けたら嬉しいです。
Discussion