福岡でさくらとAWSのIoTサービスがつながったのを見てきた
※こちらの記事は2016年12月27日にASCII.jpで公開された記事を再編集したものです。
文● 大谷イビサ/TECH.ASCII.jp
12月17日、さくらインターネットのユーザーコミュニティ「さくらクラブ福岡」とJAWS-UG福岡は、福岡で共催イベントを開催した。両者をつなげたのは「IoT」。さくらの通信モジュールからMQTTで送られたデータは、無事にAWS IoTに届けられた。
目次
IoTをテーマに交わる2つのクラウドコミュニティ
今回の共催イベントはさくらのIoT Platformの開発者である江草陽太さんが別のイベントで福岡に来ているタイミングで急遽決定したもの。さくらとAWSのユーザーコミュニティが連携し、両者のサービスを理解すると共に、「さくらのIoT Platform β」で取得したデータをAWS IoTで実際に集めてみるというのがイベントの趣旨だ。
博多駅からほど近い福岡県Rubyコンテンツ産業振興センターで行なわれたイベントには、地元IT企業のSEやハードウェアエンジニア、東京のWeb企業の部長、銀行の営業など幅広いが顔ぶれが参集。午後1時、JAWS-UG福岡やさくらクラブ福岡、Twilioユーザー会などのコアメンバーを務めるオルターブースCOOの藤崎優さんの簡単な挨拶からスタートした。
藤崎さんはさくらのユーザーコミュニティである「さくらクラブ」について「さくらのユーザーとさくらの社員がいっしょに楽しめる」「さくらのサービス以外でもOK」といった特徴を説明。実際、先日は書籍の「Unix考古学 Truth of the Legend」を執筆した藤田昭人さんをゲストに迎えてUNIXについてディープに語るイベントを開催したという。
続いて藤崎さんは、JAWS-UG福岡についても説明した。2015年4月にリブートしたJAWS-UG福岡は「昼間から呑む」というコンセプトで勉強会(?)を定期的に開催。実際、先日開催したイベントでは参加者30人中、20人が登壇し、呑みながら深夜にまでみんなが語り尽くすという濃厚な内容になったようだ。
今回の急遽共催イベントが開催されることになったのは、さくらのIoT Platformの開発者である江草陽太さんが別のイベントで福岡に来ることになったからだという。ほぼ10日前に登壇者が招集され、内容が固まったとのことだ。
開発者が語るさくらのIoT Platform
さて、イベントの前半はセッションパート。まずは江草陽太さんが「開発者が語る!さくらのIoT Platform β!」ということで、さくらのIoT Platform βの概要のほか、開発者だから語れるディープなサービスのバックグラウンドを語り尽くした。
まずはコミュニティイベントらしく自己紹介。さくらのIoT Platformの開発者として彗星のごとく表舞台に出てきた江草さんは、2014年に新卒としてさくらに入社し、VPSや専用サーバーなどのDBやAPI開発を担当してきた。インフラのみならず、ロボコン出身で組み込み機器にも明るい江草さんは、2016年2月からはさくらのIoT Platformの開発を担当。6月には同社で最年少の執行役員に就任し、現在は技術本部副本部長として技術全般を統括している。とはいえ、普段からセーラー服でいるせいか、執行役員と思われないことも多いとのこと。江草さんは写真紹介が間違ったままのCEATECの記事を挙げ、「どう見てもスーツ姿の椚座さんの方が執行役員(笑)」と会場を笑いの渦に巻き込んだ。
さて、そんな江草さんが手塩にかけて作っているさくらのIoT Platformは、「モノがつぶやけばいいのに」という田中社長の一言から開発がスタートしたIoTサービスだ。「今やインターネットやっていますというのと同じくらい広い範囲くらいになっている」(江草さん)というIoTサービス真っ盛りの現在、通信モジュールでデータを閉域網経由でデータセンターに送り、クラウドと連携するところまでを通信プラットフォームとして提供する。
さくらのIoT Platformの特徴は「データ分析の前にそもそもデータが集まってない」「通信をわかる組み込み系エンジニアや組み込み機器をわかるWeb系エンジニアがいない」といった課題に対して、他分野の技術を意識せず、ささっとIoTのサービスを作れるところ。「組み込み系の人から見た電気信号のコマンドを、反対のWeb系の人がJSONでデータをとれる変換器みたいなものを作っている」と江草さんは説明した。さらにAWS IoTやIBM Bluemix、Azure(Windows 10 IoT CoreとAzure IoT Hub)、Yahoo! myThings、ZEAL BOT TREE for IoTなどの各種クラウドサービスとはAPI経由での連携が可能。今回MQTTによる接続が初公開となり、めでたくAWS IoTのサービスに対して、MQTT経由でデータを送信することが可能になった。
現在発売中のβ版の通信モジュールはLTEをサポートし、デバイスに組み込めば、そのままセキュアな閉域網につながる。「そもそもネットワークに入ってこられないし、通信モジュールを盗んで使っても、他のデバイスに通信が到達しないよう、フィルタリングがかかっている」(江草さん)。通信モジュールは12月19日現在キャンペーン中で、半額で提供しており、モジュールに含まれているデータ転送量(RP)も消費しない。なお、モジュール自体はLTE版のほか、2.4GHz版とLoRa版を開発中で、コネクタ形状もすべて同じになっているという。
コンテナ管理の省力化を自前で実現したさくらの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日前に招集を受けたという口だが、「藤崎さんの勉強会だったら、和気あいあいだろうし、それほどハードルは高くないだろうと思った」とのことで、今回子連れでイベントに参加したという。
AWS IoTはデバイスとAWSの各種サービスを仲立ちしてくれるサービス。現在は、①MQTTやWeb Socketなどを介してメッセージをやりとりする「デバイスゲートウェイ」、②X.509ベースの証明書、IAM、Amazon CognitoのID管理などでの「デバイス認証・認可」、③受信データに対してSQL風のフィルタリングをかけられる「ルールエンジン」、④オフライン状態時に登録デバイスの最新ステータスを保持してくれる「デバイスシャドウ」、⑤デバイスの固有情報を管理する「デバイスレジストリ」などの機能がある。毛利さんは証明書にデバイスとポリシーが関連づけられるという関係性を理解しておくとよいとアドバイスするとともに、開発者側が通信を意識しないでデバイスを管理できるデバイスシャドウの有用性をアピールした。
これら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のデモを披露し、登壇を終えた。
さくらのIoT PlatformとAWS IoTはつながるか?
後半はいよいよハンズオン。参加者が半分ずつに別れ、会場の前方で江草さんによるさくらのIoT Platformのハンズオン、後半はコム・アンド・コムの木村健一郎さんによるAWS IoTのハンズオンが行なわれた。両者で作ったものを最後にガッチャンコし、収集したデータをKibanaで見るというのが、2時間のハンズオンの到達点だ。
江草さんのハンズオンは、さくらの通信モジュールの利用法やブレッドボードの使い方、さくらのIoT Platformの設定などを説明。さすがサービスの開発者だけに説明もよどみなく、ユーザーが詰まるところも理解しており、ハードウェアのハンズオンにもかかわらず、1時間かからず全員がデータの送信まで完了した。
木村さんのハンズオンはIAMロールの設定やAWS IoTの証明書の作成、デバイスへのアタッチなどを説明。初めての人がほとんどだったこともあり、こちらはなかなか苦戦。とはいえ、江草組に遅れること15分で追いつき、さくらのIoT Platformで取得したデータを、AWS IoTで受け取るという作業に進む。
さくらのIoT Platformでの設定を終えた参加者たちの横に、AWS IoTの設定を終えた参加者が着座。江草さんの指導の下、エンドポイントやプレフィックス、証明書などを登録し、接続が完了すると、さくらのIoT Platformで収集したデータが続々と上がり始め、Kibanaのグラフをチェックした参加者から拍手が上がる。
初心者も多かった今回のイベントだが、ハンズオンですべての参加者がきちんとつながるところまで走り終え、まさに大成功。インターネットの黎明期にATコマンドでアナログモデムの疎通を確認したようなイメージで、ちょっと感動的だった。仕様上のつながるではなく、実際につながるところを見て、オオタニも福岡まで足を運んだかいがあったと感じた。