さくらの熱量チャレンジ 第12回

さくらの江草さんはIoT Platformのシステムについて自ら解説

福岡でさくらとAWSのIoTサービスがつながったのを見てきた

コンテナ管理の省力化を自前で実現したさくらのIoT Platform

　今回はさくらのIoT Platformの技術構成要素も披露され、組み込みにもインフラにも強い江草さんのスーパーエンジニアぶりも明らかになった。まず通信モジュールにはLTEモデムのほか、マイコン上にOSSのリアルタイムOSとTCP/IPスタックを実装。ファームウェアのアップロードに利用するHTTP層を独自で組み込んでいるという。プロトコルはMQTTライクな独自プロトコルを採用。「最初はMQTTをそのまま使っていたのですが、モジュールもサーバーも独自実装なので、標準にこだわる必要がない」という事情だ。

　バックエンドのアプリケーションの実行環境にはDockerクラスターを採用。昨年からはMesosとMarathonによるアプリケーションのデプロイ環境を構築しており、必要なサーバーに簡単にデプロイできるようになっているという。とはいえ、MesosやMarathonでは、コンテナがランダムなホスト名とポートで起動するため、リバースプロキシの設定が大変だった。そこで、Nginxの設定を動的に書き換えるロードバランサーを開発し、バージョンの異なるアプリケーションが動作しているコンテナの切り替えも手間なく行なえるようになっているという。

　ロードバランサー、データベース、ElasticSearch、キャッシュなどはすべてさくらのクラウドと専用サーバー上に構築。ネットワークに関しては、すべてBGPを話すソフトウェアルーターで構築され、通信事業者の専用線で冗長構成で接続されている。

データセンター側の構成要素

　通信モジュールからの認証リクエストが来ると、Goで作られた独自のプロトコルブローカーが待ち受けており、DjangoとPython製の内部Web APIを経由してマスターデータベースに接続して認証を実施。認証を経て以降は、通信モジュールのデータがいったんRabbitMQに入り、HTTPの場合は前述のプロトコルブローカーに渡され、データ蓄積の場合はScalaを経由して、ElasticSearchに渡されるという。ElasticSearchに溜まったデータは外部から利用できるよう、Python＋Flask製のAPIとしてユーザーに提供。また、モジュールの登録やサービス連携の設定などコントロールパネルで実現できることはすべてAPIで提供されているという。

アプリケーション構成

AWS IoTの機能の整理と仮想デバイスを作れるmockmock

　2本目のセッションでAWS IoTと自社サービス「mockmock」について説明したのは、地元福岡のIT企業であるFusic 技術開発部門 エンジニアの毛利啓太さん。Fusic自体はWeb系の開発会社だが、毛利さん自体はIoTをはじめとする新しめのITにチャレンジしている立場で、後述するmockmockの開発も手がけている。AWS IoTに関しては業務で利用しているわけではなく、しかも10日前に招集を受けたという口だが、「藤崎さんの勉強会だったら、和気あいあいだろうし、それほどハードルは高くないだろうと思った」とのことで、今回子連れでイベントに参加したという。

Fusic 技術開発部門 エンジニア毛利啓太さん

　AWS IoTはデバイスとAWSの各種サービスを仲立ちしてくれるサービス。現在は、①MQTTやWeb Socketなどを介してメッセージをやりとりする「デバイスゲートウェイ」、②X.509ベースの証明書、IAM、Amazon CognitoのID管理などでの「デバイス認証・認可」、③受信データに対してSQL風のフィルタリングをかけられる「ルールエンジン」、④オフライン状態時に登録デバイスの最新ステータスを保持してくれる「デバイスシャドウ」、⑤デバイスの固有情報を管理する「デバイスレジストリ」などの機能がある。毛利さんは証明書にデバイスとポリシーが関連づけられるという関係性を理解しておくとよいとアドバイスするとともに、開発者側が通信を意識しないでデバイスを管理できるデバイスシャドウの有用性をアピールした。

AWS IoTで覚えておくべき認証と認可

　これらAWS IoTを用いることで、デバイスから取得したデータをAmazon S3に保存するのが基本形。あとはルールエンジンで特定のイベントが発生したときだけSNSでメールを送ったり、Lambdaに送ってSlackに通知したり、CloudWatchでモニタリングしたり、KinesisからRedshiftを経由してQuickSightで分析するといったことが可能になる。AWSの各種のサービスにデータを流す手前で、AWS IoTがさまざまな処理を担ってくれるため、開発者の負荷を軽減してくれるという。

　便利なAWS IoTだが、実際にサービスを使う前にはさくらのIoT Platformなどでデバイスでデータ送信できるようにしておく必要があり、けっこう大変。そこで登場するのがクラウド上に仮想デバイスを作れるmockmockだ。「mockmock上で仮想デバイスを作り、Webのコンソールから制御する。そこから疑似データをAWS IoTに送信できるので、デバイスを一切触らず、Webですべて完結する」と毛利さんはアピールする。

　mockmockの着眼点は、IoT開発におけるサーバー側とデバイス側の開発のタイムラグにあるようだ。「サーバー側はAWSなどで比較的すぐに作れるけど、デバイス側はデータが送れるようになるまでけっこう時間がかかる。でも、mockmockでタイムラグを補うと、デバイス側を開発している間に、サーバー側はmockmockで動作検証ができる」（毛利さん）というわけだ。また、テスト用のデバイスが数多く集められないという課題も、仮想デバイスを大量に生成できるmockmockで解消。さらに、再現性の低いエラーも擬似的に再現できるため、サーバー側のエラー修正も容易に行えるという。

デバイス側とサーバー側の開発のタイムラグが課題

　mockmockは現在β版として公開中で、仮想デバイス5台までは無料で試用できる。思いのほかセッションが早めに終わった毛利さんは、実際のmockmockのデモを披露し、登壇を終えた。