例のボタンをツマミにSORACOMの世界観をただの利用者が勝手に解説してみた

はじめに

この記事は「SORACOM LTE-M Button powered by AWS Advent Calendar 2018」の6日目です。

ところで、「例のボタン」こと「SORACOM LTE-M Button powered by AWS」、皆さんもう手に入れていますよね？

f:id:nekoruri:20181207035544p:plain

先日のSORACOM Technology Camp 2018ではこのSORACOM Buttonのバックエンドシステム構成の話がありました。

見て欲しいのはこのページです。

SORACOM Technology Camp 2018 ベーシックトラック4 | SORACOM LTE-M Button の始め方 from SORACOM,INC

SORACOM Buttonは携帯電話ネットワークの「SIM」を活用することで、IoTデバイスにありがちな様々な面倒ごとを解決しています。

単なるIoT/M2M機器向けに従量制価格プランを作り込んだだけの安価なMVNOキャリアと勘違いされがちなSORACOMですが、このSORACOM Buttonのしくみに代表されるように、その真価は「通信とクラウドを融合したIoT通信プラットフォーム」であることです。これから、これがどういうことか解き明かしていこうと思います。

というわけで、この記事はコミックマーケット92にて頒布した同人誌「めもおきば TechReport 2017.08」第1特集の再編集版です。

追記した部分は「※追記：」としています。

d.nekoruri.jp

SORACOMとは

端的に言えば、SORACOMは株式会社ソラコムが提供するIoT通信プラットフォームです。

正直「IoTなんちゃらプラットフォーム」という単語自体にバズワード感がありますが、一般的にはIoT*1 デバイスが通信をするために必要なものを揃えたパッケージという感じで使われているようです。

SORACOMのように通信にフォーカスしたものだけでなく、（ネットワーク接続を前提に）IoTデバイスから集まってきたデータを分析・可視化するサービスや、デバイスからデータをクラウドに投げるときのライブラリ群、あるいはそれらを包括的に提供するものといくつかのパターンがあるようです。

SORACOMはざっくり三つの役割を提供しています。

※追記：図は2017年8月当時のものです。

f:id:nekoruri:20181207012321p:plain

SORACOMはこれらを下から上まで「垂直統合」で提供し相互に価値を高め合うことで、利用者に対して高度なサービスを提供しているわけです。

回線接続サービス

IoTデバイスがネットワークに接続するための回線を提供する、プラットフォームとしては一番低い部分です。サービス名称としては「SORACOM Air」が対応し、SORACOMの最初のサービスでもあります。

当初はNTTドコモのMVNOとして日本国内向けにサービスを開始しましたが、その後海外でも利用可能なグローバル向けAir SIMが提供されたほか、920MHz帯のLPWA（Low Power Wide Area Network((間欠的に通信を行うことで、低電力（設定によっては乾電池で数ヶ月以上）で広域（数km）の通信を実現しようとする無線通信のカテゴリ）であるLoRaWANとSigfoxにも対応しました。

※追記：その後、KDDI回線を利用できるSORACOM Air SIM（plan-K）と、今回のSORACOM Buttonも利用しているLTE-M（plan-KM1）が提供されました。

また、株式会社ソラコムとしてのサービスではありませんが、ソラコムが開発したSORACOMのエンジンである「SORACOM vConnec Core」をKDDIが採用した「KDDI IoTコネクト Air」があります。MVNOと同等の接続サービスとしては同じように提供されていますが、この後に紹介する上位層の機能は残念ながらSORACOM本家から若干遅れての提供になっているようですが。KDDIグループへの参加により、サービス内容の共通化も進んでいくと考えられます。なお、技術的詳細は明かされていないので、KDDIとしてのサービスについて、これ以降は触れません。

※追記：上記のとおりSORACOM本体よりplan-Kが提供したことにより、こちらのKDDI IoTコネクト Airの新規申し込みは終了になった模様です。その結果、全てのサービスがドコモ回線と同じスピードで提供されるようになっています！

SORACOM AirはNTTドコモとL2卸契約するMVNOですが、NTTドコモからの専用線から先のMVNOキャリアとして必要なシステム全てをAWS上で構築しています。データトラフィックの転送や通信網の管理を、クラウドネイティブな設計でソフトウェアによって実装しています。これにより、利用数の増加を見込んだ設備投資を避けつつ、高い頻度での開発サイクルを回しています。その副産物として、1日10円＋最低0.2円/1MB（たとえば月間1GBであれば約500円）という低トラフィックでは極めて安価な従量課金を実現しています。

ただ、安いことはSORACOMの価値の中ではぶっちゃけ些細なことではないでしょうか。単に安いインターネット接続回線だけが欲しいのであれば、月額300～500円や、一定転送量まで0円というMVNOキャリアも登場している昨今です。

SORACOM Airの価値の半分は、その管理機能をAPIとして提供していることにあります。APIからSIMごとの設定（回線速度や回線自体の有効・無効など）を変更でき、通信量などを監視してAWS Lambdaを呼び出すイベントハンドラー機能もあります。これを利用することで、SORACOMの上に仮想MVNO事業者を構築したり、SIMを組み込んだ形で製品を出荷してから契約状況に合わせて通信を有効化・無効化したりといったことが可能になるわけです。

残りの半分は、SORACOM Airという回線契約があることで、安全にデバイスを識別でき、それによって上位層の機能を提供できるということです。セルラー（いわゆる3G/4Gなど携帯電話回線ベースの技術）であればSIMが、Sigfoxであればデバイス内蔵のセキュアエレメントが耐タンパー性（壊しても中身の暗号鍵などを見られない性質）を持ち、デバイス識別のための秘密情報が安全に保存されています。またLoRaWANの場合にも、出荷時にSORACOM側と同期されてデバイスに設定されるAppKeyを使ってセッション鍵を作成するため、耐タンパー性とまではいきませんがそれなりに保護されています。

接続回線という一番下の層において個別のデバイスを一つのID基盤上で識別できているからこそ、異なる通信網を性質の違いのみを意識するだけで、その上に多種多様なサービスを統一的に提供できます。

概念的な表現をすると、閉域網の中でデバイス別にIPアドレスが割り振られる旧来のネットワークセキュリティのモデルに対して、回線の接続点で直接認証されるIDベースのセキュリティという新しいモデルがあり、それに基づいてSORACOMのあらゆるサービスが実現されています。

要するに、「Air」に続く「B」以降のサービスのために、SORACOM Airとしては様々な通信方式に対応する必要があり、今後来る5Gベースの携帯通信網や、グローバルの世界制覇のためにKDDIと手を組んだのだと思います。

ソフトウェアベースの高機能な仮想ネットワーク

先ほど書いたとおり、SORACOMのネットワークは全てクラウド上のソフトウェアで構築されています。つまり一種のSoftware-defined Network（SDN）やNetwork Function Virtualization（NFV）です。通信回線の反対側にそのままSDN/NFVの世界を接続したことで、閉域網として様々な機能を提供しています。

閉域網という視点では、接続先に応じて3種類のサービスを提供しています。AWS上の自分のVPCに接続する最も安価な「SORACOM Canal」、物理専用線としてAWS Direct Connectを利用する「SORACOM Direct」、インターネットVPNを利用する「SORACOM Door」です。

これらを利用する場合は、Virtual Private Gateway（VPG）という仮想ルータを構築して、SORACOM Airの回線ごとにVPGに接続します。

自分独自のVPGを利用することで、デバイスに割り振られるIPアドレスレンジ（デフォルトでは10.128.0.0/9）を変更したり、デバイス毎に固定のIPアドレスを指定したりといったことも可能です（次に紹介するSORACOM Gateを使わない限り、そのIPアドレスが直接見えることはありません）。ただし、これらは閉域網と言ってもVPGでNAPTされるため、あくまでデバイス側からクラウド側への方向の接続のみを提供しています。

クラウド側からデバイス側への接続、あるいはデバイス同士の接続を実現するのが「SORACOM Gate」です。SORACOM Gateを有効にするとデバイス毎のIPアドレスを利用して相互に通信が可能となります。さらに、SORACOM Canal等で接続されたネットワーク上にGate Peerと呼ばれるルータ（実際にはVXLANが設定されたLinuxホスト等）を構築することで、そこからデバイスまで一つの仮想L2ネットワークが提供され、自分のネットワークからデバイスに直接接続できるようになります。Gate PeerまでL2で伸びてきてくれるため、そこから自分のVPC内のネットワークにさらにL2ブリッジしても良いですし、もっとシンプルにNAPTするのも手軽です。

さて、このあたりまでは気合いの入った閉域網サービスであれば実現できるところですが、SDNであることを最大限に活かすSORACOMらしいサービス「SORACOM Junction」がつい先日（※2017年7月）リリースされました。これはVPGを通過するパケットに対して、ミラーリング、リダイレクション、インスペクションの3つの操作を提供します。

ミラーリングとリダイレクションは、名前の通りパケットを複製したり転送先を変更したりすることで、ユーザ企業が独自の監視システムを通したりトラフィックの制御を行ったりと言うことが可能となります。インスペクションは、パケットの統計情報を外部のクラウドサービス((送信先にできるクラウドサービスはこの後紹介するSORACOM Funnelと同じようです。内部的には同じ枠組みに載っていると思われます。に送信します。

これらSORACOMの高機能な仮想ネットワークは、全てクラウドネイティブな設計で実現されているため、SORACOMの利用者やその転送速度・秒間パケット数などが増えても（万が一AWSのリソースが頭打ちしない限り）いくらでもスケールすることができます。

その一方で、たとえばSORACOM CanalのVPGは1時間あたり50円（30日間で36,000円）と、きちんと利用者にそれなりの負担が求められます((月36,000円で用意できるAWSのインフラ環境は何だろう……と考えていくと、VPGの仕組みが妄想できそうな気がしてきます。。このあたりはうまく技術上の制約をビジネスとして成立させていると感じます。

モバイル通信網の課金体系は、行き過ぎたインセンティブなどにより極めて歪になってしまっていますが、SORACOMの素直な課金体系を見るとほっとします。

クラウド連携

SORACOMの真価はクラウドとの統合にあります。

IoTでビジネスをするために必要なのは、単にIoTデバイスをIPネットワークに接続することだけではなく、そのIPネットワークを介してクラウドの向こう側に大量のデータを期待する品質で届けることです。通信とクラウドの融合を謳っているように、SORACOMにはIoTデバイスをクラウドと連携するための仕組みが数多く用意されています。

SORACOMのクラウド連携機能は、大きく二つに区別できます。

一つは、AWSやAzure、GCP、あるいは独自に構築したサーバなどの、「クラウド側」との橋渡しをする機能です。

サービスとしては「SORACOM Beam」と「SORACOM Funnel」があります。単純にデータを左から右へと転送するだけで無く、クラウドに送る際の認証や暗号化処理、データ量の限られたLPWAを利用する時のデータ形式変換など、「IoTデバイスがクラウドと通信する際のあるある処理」をSORACOMが肩代わりしてくれます。

※追記：AWS IoTなどへのデバイス登録（プロビジョニング）を行う「SORACOM Krypton」が加わりました。

もう一つはSORACOM自身がクラウドとして直接的な機能を提供するもので、「SORACOM Endorse」「SORACOM Harvest」「SORACOM Inventory」が対応します。SORACOM Harvestのように単体で完結するものもあれば、SORACOM Endorseのように別の枠組みと連携するための機能もあります。

※追記：SORACOM Harvestに蓄積されたデータを可視化する「SORACOM Lagoon」が加わりました。

このあと、これらを個別に掘り下げていきます。

SORACOMの世界観

SORACOMのクラウド連携について具体的な機能を紹介する前に、まずSORACOMがIoTプラットフォームとして提供しようとしている世界観について触れておきます。

IoTにおける代表的な脆弱性をOWASPがまとめているので、以下に引用します。

Top IoT Vulnerabilities - OWASP

I1 Insecure Web Interface
安全でない（製品の）Webインターフェース
I2 Insufficient Authentication/Authorization
不十分な認証/認可
I3 Insecure Network Services
安全でないネットワークサービス
I4 Lack of Transport Encryption/Integrity Verification
転送路における暗号化・完全性確認の欠如
I5 Privacy Concerns
プライバシーに帯する懸念
I6 Insecure Cloud Interface
安全でないクラウド上のWebインターフェース
I7 Insecure Mobile Interface
安全でないモバイルアプリのインターフェース
I8 Insufficient Security Configurability
不十分なセキュリティ設定
I9 Insecure Software/Firmware
安全でないソフトウェア・ファームウェア（の更新）
I10 Poor Physical Security物理セキュリティが弱い

IoTデバイスが関連するのはI1、I2、I3、I4、I8、I9、I10あたりですが、IoT固有の物理セキュリティ（I10）を除いて、一般的なウェブアプリ等であれば当然のようにどれも考慮されているべきはずのものばかりです。これらがなぜIoTデバイスで特に問題にされるかと言えば、IoT固有の理由でそれらを設計時に「妥協」してしまうからです。

IoTデバイスが一般的なサーバ側システムと異なるのは大きく2点あります。

一つは計算機としての性能です。最近になってようやくARMベースなどの比較的高性能なデバイスも増えてきましたが、消費電力であったりサイズであったり、あるいは予算や部材の都合で依然として性能の低いIoTデバイスとはまだ何年も付き合っていく必要があります。ところがデバイス自身を正しく認証する、あるいはデバイスに接続するユーザを認証するには、公開鍵暗号やハッシュ関数などの計算が必要となり、決して低くない演算能力が必要となります。さらに大量のデータをクラウドに送信するようなデバイスでは継続的な暗号化も必要となります。

旧来のネットワーク制御デバイスでは、ネットワークレベルのセキュリティなどを前提として「妥協」をしてきました。その結果として、USBメモリなど様々な手法を組み合わせたStuxnetなどの被害が発生しています。これからは、何らかの手段で、低い処理性能しか持たないIoTデバイスからクラウドまでの通信を暗号学的に守っていく必要があることは確定的に明らかです。

もう一つが、IoTデバイスの数が多いということです。

様々なデバイスをネットワークに接続して安全に機能させるには、それぞれのデバイスを個別にセキュアに識別する必要があります。そのためには、電子証明書あるいは事前共有鍵どちらでも良いですが、デバイス毎に何らかの秘密の認証情報を持たせる必要があります。

ところが、数百数千が前提となるようなIoTデバイスでは製造時に個別の情報を持たせ、それをそのまま運用時にも利用するということが難しくなってきます。したがって運用開始時に認証情報を投入する必要が出てくるわけですが、物理的な作業をどう減らすかが重要であり設計の難しさが一気に上がります。また故障時の交換なども踏まえると、開始時だけではなくシステムの運用ライフサイクル全体の中でデバイスの識別方法を設計する必要があります。

SORACOMはこの課題に対して「まず接続回線を安全に識別し、その上でSORACOM側に処理を委譲する」という解決策を提示しています。

SORACOM Airの回線は、3G/4G網やLoRaWAN/Sigfoxのそれぞれの暗号学的手段によって安全に認証・暗号化されています。そこで、IoTデバイスは純粋にやりとりしたいデータだけをSORACOMに送り、SORACOMが認証や暗号化など本来IoTデバイス上で行うはずだった処理を肩代わりします。

また、IoTデバイスは必ずネットワークに接続する必要があり、設置時にSIMを挿したり、LoRaWANやSigfoxのデバイスIDを登録したりします。これまでは別の手段で証明書を配布するなど認証のためだけの作業が必要でしたが、通信路に紐付いてクラウド連携を行うことでそういった作業をゼロにします。

これこそが、SORACOMの世界観において核となる考え方です（偉そうに書いていますが、一ユーザから見た勝手な決めつけです😇）。

プラットフォームというものを提供するということは、そのプラットフォームの世界観──すなわち、IoT/M2Mデバイスにおける通信とはどういうものなのか、運用も含めたシステム全体をどういう抽象化に基づいてIoTデバイスやクラウドを設計するのか、という共通認識──のシェアを取り合う「抽象化戦争」に参加することです。

このSORACOMの世界観は、IoTプラットフォームにおける抽象化戦争においてかなり強い魅力を持っているように思います。

SORACOMの様々なサービス

さて、そろそろ個別のサービスを紹介していきます。

SORACOM Beam

SORACOM Beamは、端的に言えば高機能なアプリケーションプロキシサーバです。

SORACOM内のエントリポイントにIoTデバイスから送りやすいプロトコルで送信すると、上手い具合にプロトコルを変換したりしてクラウド側に送信してくれます。SORACOMが提供するクラウド連携機能のなかでもっともシンプルなものですが、SORACOMが提供しようとする世界観に触れる入口として一番相応しいものです。

また、全てのSORACOM Air回線はグループ単位で管理されますが、SORACOM Beamはこのグループに対して設定されます。したがってグループのBeam設定を変更するだけで、そこに紐付いた全てのIoTデバイスからの送信先が一括で管理できます。当然ながら、Beamに限らずこのような設定をSORACOM APIで変更することも可能であり、デバイスを含むシステムのオンライン開通などを構築することもできるでしょう。

利用するプロトコルで分類すると、6種類の動作に分けられます。

HTTP ⇒ HTTP/HTTPS

IoTデバイスからHTTPでエントリポイントにリクエストを送信すると、そのリクエスト内容をクラウド側のURLに対してHTTPもしくはHTTPSでリクエストを転送します。

クラウド側がインターネットの向こう側にある場合など、HTTPSによる通信の暗号化処理をSORACOM側にオフロードできます。IoTデバイスからSORACOMまでは各通信手段による暗号化や、NTTドコモからSORACOMまでの専用線で守られているため、SORACOMまではHTTPで良いわけです。

クラウド側にリクエストを送信するときに、接続元IoTデバイスのIMSI（International Mobile Subscriber Identity：SIMごとに割り当てられるID）・IMEI（International Mobile Equipment Identity：3G/4Gの携帯電話機・モデムごとに割り当てられるID）や、事前共有鍵に基づいた電子署名、個別に指定したカスタムヘッダをHTTPリクエストヘッダに追加することができます。これによって、クラウド側は「誰からの通信なのか」を識別することができます。これはこの後の他のHTTP転送先でも共通です。

細かく分けると、ドメイン上の全てのパスをそのまま利用する「Webエントリポイント」と、パスごとに個別の転送先を設定できる「HTTPエントリポイント」の2種類が用意されています。

TCP ⇒ HTTP/HTTPS

TCPでエントリポイントに接続して生のデータ列を投げると、HTTP POSTリクエストに変換してクラウドに送信します。

データ列は、以下のようにBase64エンコードでJSONに埋め込まれて本文として送られます。

{"payload":"Base64エンコードされたメッセージ"}

クラウドからのレスポンスもそれっぽく返ります。

400 Message from server

UDP ⇒ HTTP/HTTPS

TCPと同様に、受信したデータをHTTP/HTTPSに変換して送信します。

TCP ⇒ TCP/TCPS

TCPで送られた内容を、そのままTCPでクラウドに送信します。IMSIやIMEI等を送りたい場合は、HTTPリクエストヘッダの代わりに、先頭行として送信されます。

MQTT ⇒ MQTT/MQTTS

クラウド側のMQTTブローカーと相互にPublish/Subscribeを転送します。

LoRaWAN ⇒ HTTP/HTTPS

LoRaWANデバイスから送信されたUplinkデータを、HTTP/HTTPSでクラウドに送信します。

先ほどのTCPからの変換と似たような動作をしますが、Base64ではなくHex表記が使われるほか、経由したLoRaWANゲートウェイの情報や受信電波強度（RSSI）などの追加情報を含むJSONとして送信されます。

LoRaWANなどのLPWAでは転送できるデータ量が極めて少ない（デフォルト設定（Spreading Factor＝10）では、4.4秒に1回ずつ、1回に11バイト送信できます。）ため、JSONのような富豪的なデータを来ることはできず、まさに「1ビットは血の一滴」と送らなければならないデータをビット単位で詰め込んで送ることになります。

それをどこかでクラウド側で扱いやすい形に変換しなくてはなりませんが、バイナリパーサー機能を利用することで、バイナリデータを指定した通りに分解してJSON上に展開することができます。どこかで必要になる処理なので、LPWAの利用者には非常に便利と思います。バイナリパーサーはこの後紹介するSORACOM FunnelやSORACOM Harvestにも対応しています。

SORACOM Funnel

私が一番好きなサービスがこのSORACOM Funnelです。

SORACOM Beamが単純なアプリケーションプロキシという形態だったのとは対称的に、SORACOM Funnelは様々なクラウド固有のインターフェースに直接データを投げ込むことができる「クラウドリソースアダプター」です。

様々なパブリッククラウドはデータ収集用のサービスを提供していますが、IoTデバイスからそこに送信しようとすると、IoTデバイス上でクラウド接続用のSDKを組み込んだり、そこに食わせる認証情報の管理が必要となったりします。

SORACOMの世界観の通りそれらの面倒な処理全てを肩代わりしてくれるのがSORACOM Funnelです。IoTデバイスは、送りたいデータをそのままSORACOM FunnelのエントリポイントにHTTPもしくはTCP/UDPで送るだけです。直接IoTデバイス上のアプリケーションから送信しても良いし、例えばFluentdが使える環境であればout-httpプラグインが直接使えたりします。

例えば、SORACOM Airで接続したIoTデバイス上からこんな感じでHTTP POSTで投げます。

$ curl -X POST http://funnel.soracom.io \
-H Content-Type:application/json \
-d '{"foo":"bar"}'

そしてこれをSORACOM Funnelの設定でAWSのKinesis Data Streamsに送るように設定しておくと、Kinesis Data Streamsには以下のようなレコードが送信されます。

{
"operatorId": "OP9999999999",
"timestamp": 1473322750825,
"destination" : {
"resourceUrl": "https://kinesis.us-west-2.amazonaws.com/teststream",
"service": "kinesis",
"provider":"aws"
},
"payloads": {
"foo": "bar"
},
"imsi": "440000000000000"
}

payloadsの中に送信したJSONが埋め込まれているほか、SORACOMが受信したタイムスタンプ（Unixtimeミリ秒）や、送信に使われたSORACOM AirのIMSIなどが含まれて届きます。クラウド側ではこれらのデータを元に送信元を識別して様々な処理を行います。ね、簡単でしょ？

送信先のサービスも、AWSであればAWS IoT、Kinesis Data Streams、Kinesis Data Firehoseと一通り、それ以外のパブリッククラウドもAzure Event HubsやGoogle Cloud Pub/Subなどイベントストリーミング系に流し込むことができます。

他にも、SORACOMの認定済みパートナー各社のサービスに接続することができるPartner Hosted Adapterが用意されています。現在はデータ分析や可視化エンジンなど国内9社のサービスに対応しています。SORACOM接続のIoTデバイスから容易に送り込めるかは各サービスで支配的な要素になることが予想できるため、今後もどんどん対応サービスが増えて行くことでしょう。

IoTデバイス「あるある」として、技術上の理由やビジネス上の要件によって利用するハードウェアやOS、ディストリビューションに制約がかかることが多々あります。そのような環境の上で、SDKを直接動かす手間を省き極めて軽く標準的なプロトコルだけでクラウドとの連携ができることは、その開発速度の改善に貢献します。

数多くのPoC（実証実験）をこなさなくてはならないIoTビジネスにおいて、開発速度はビジネス上の支配的な要員となります。決してSDKを利用してクラウドに直接通信することが技術的に難しいわけでは無いですが、「そこは自分達のビジネスでは無い」わけで、単純に計算機資源をオフロードするという意味だけではなく、自らの実装量そのものを減らせることがSORACOM Funnelの魅力です。

さらにセキュリティ上の理由としても、IoTデバイスの盗難などを考慮する場合はIoTデバイス毎にアクセスキーなどの認証情報を個別に用意するか、一時的なリスクならば受容できる場合は盗難が発覚したときに即座に認証情報を一括で交換するなどの対策が必要となります。

SORACOM Funnelではクラウド側に対する認証情報をSORACOM側で持つので、そもそもIoTデバイス上に何かを管理する必要がありません。こういった「考えることを減らす」という方向性のものが私は大好きです。

地味な副産物として、クラウド側の問題でデータ投入に失敗した場合なども、SORACOM上のマネジメントコンソールで直近2週間のログが見られるので、IoTデバイスを触らずにトラブルシュートできるのも嬉しいところです。

そもそもIoTデバイスなんてファイルシステムがread-onlyで書けるのはtmpfsだけとか、書き込める容量が数MBとかしかないとかザラで基本的に必要なログは外部に転送する必要があったりするわけで、とにかく自分でやることを減らすのがIoT開発の肝です。

ここまでの2つは、IoTデバイスとクラウドを連携させるための橋渡しのサービスでした。残りの3つは、SORACOM自身がクラウド的なサービスを提供するものです。

SORACOM Endorse

SORACOMのサービスの中でも、地味ながら面白いものの一つがSORACOM Endorseです。

繰り返し述べてきたように、SORACOM Airの3G/4Gで接続されたデバイスは3G/4GのSIMにより暗号学的に正しく認証されています。ですが、大量のデータ転送や通信の安定性を必要とする場合など、3G/4G回線経由で送受信したくないというケースがあります。そんなときSORACOM Endorseを使うことで、モバイル通信を経由して認証トークンを発行してもらうことができます。

認証トークンは標準的なJWT（Json Web Token）フォーマットで、SORACOM Airで接続に使われているIMSIやIMEIなどのほか、任意の情報を追加することができます。またSORACOMの秘密鍵で署名されているため、そのため認証トークンを別のシステムに持っていてもSORACOMの公開鍵で検証することができます。

これを使うと、単体で用意すると高価になりがちな耐タンパー性のあるセキュアエレメントによるデバイス認証を、モバイルデータ通信を経由するかどうかによらず様々な状況で利用することができます。COSR設定も可能なので、ブラウザ等からの直接利用もできそうです。

自分のところではFunnel/Beamで済んでしまって試せていないのですが、システムの実現可能性を広げることができるポテンシャルを感じています。

※追記：このSORAOM Endorseの仕組みを上手く活用できる、SORACOM Kryptonが搭乗しています。

SORACOM Inventory

大量生産をするIoTデバイスにおける設定情報の管理や、稼働中のはずのIoTデバイスの状況を把握するためには、これまではBeamなどのクラウド連携機能を使って自前で設定レポジトリやテレメトリ収集システムなどを作る必要がありました。そういった部分をSORACOMが提供してくれるのがSORACOM Inventoryです。技術的には標準規格LwM2M（OMA LightweightM2M）のサーバです。

LwM2Mは恥ずかしながら作者もSORACOM Inventoryの登場まで知らなかったのですが要するに非同期に接続されるIoTデバイス等に向けて設計されたSNMPのようなものと捉えれば良いようです。具体的には、設定値の参照・変更や、非同期に通知されるデバイス側ステータスの変更監視、コマンドの送信などが行えるようです。

正直あまり詳しくないので深くは触れません。

SORACOM Harvest

最後に紹介するSORACOM Harvestは、SORACOMが提供するサービスの中でもっとも高い層にあるもので、IoTデバイスがSORACOM Funnelなどと同じようにデータを投げると、SORACOM上にデータを蓄積し、可視化できます。簡単なPoCであればもはや外部のパブリッククラウドを必要とせず、むしろSORACOM自身がパブリッククラウドとしての役割を果たしていると言えます。

投げ方とかはSORACOM Funnelと似ているので、内部的にはPartner Hosted Adapterと同じようにSORACOM Harvest Adapterのようなもので送り込んでいるような気がします。

ちょっとした可視化とAPIだけを提供するような「IoTプラットフォーム」が量産されている昨今ですし、なによりIoTデバイス側の開発に重きを置いてクラウド側はデータが見られれば良いようなプロジェクトであればSORACOM Harvestはまさにどハマリだと思います。是非使っていきましょう。ここでも、重要なことは「自分のビジネスと関係無いところは、できるかぎり自分でやらない」ということに尽きます。

SORACOM自身がデータを蓄積し始めたという事は、そのデータを対象とした様々な分析サービスなどを実現できる下地が揃ったと言えます。まだまだアルファベットにはZまでたくさん残っているので、例えばリアルタイムな機械学習で異常検知できるSORACOM Machine Learningだとかそんな感じの手厚い系のサービスも出てくるのかもしれません。

追記：このSORACOM Harvestで蓄積したデータを可視化して他の人に見せることができるSORACOM Lagoonがリリースされています。SORACOM LagoonはオープンソースBIツールのGrafanaをベースにしたもので、グラフや地図などを用いたダッシュボードを作ったり、条件を指定してSlackなどのWebhookにアラートを投げ込んだりすることができます。SORACOMの管理コンソールのログイン権限とは別に、共有URLを発行してお客さんに直接見てもらうことなども可能です。

SORACOMで気軽に遊んでみよう

散々述べてきたとおり、SORACOMの魅力はMVNOの回線に紐付いて提供される高レベルのクラウド連携機能です。従って、パブリッククラウドがそうであるように、実際に触ってみないとその面白さ、便利さを実感しづらいものです。

SORACOMのハンズオンもかなり広く実施されていますが、自分で勝手に遊んでみるのであれば、回線速度も不必要なので3Gで良いですし、古めのdocomo向け中古USBモデムが2000円程度で転がっていたりします。USBモデムではWindows/Macのドライバインストール用に仮想CDドライブが仕込まれている場合がほとんどなので、あらかじめユーザ（人柱）による検証報告があるものを探すと良いです。

また、最近LPWAのサービス圏内も拡がっているので、それを試して見るのも良いかも知れません。例えばLoRaWAN GPSトラッカーが15,800円で購入できるので、それでそのまま試すことができます。リリースされたばかりですが、Sigfox対応センサ対応デバイスも8,478円とそこそこお手軽に手が出せそうな価格帯です。

このような完結したIoTデバイスを買ってきて、SORACOM Harvestでまず可視化してみたりSORACOM Funnelでクラウドに送ってサーバーレス構成で分析してみたりすると、SORACOMが何を狙っているのか実感できると思います。

※追記：今ならまさにSORACOM LTE-M Buttonを使うことで、AWS IoT経由で簡単にAWS Lambdaなどを呼び出すことができます。詳しくは以下のアドベントカレンダーにたくさんの情報が出てくるはずです😇

qiita.com

今後のSORACOM予想

KDDIグループに参加したことで、特にSORACOMの方向性が変わるとは思いませんが、KDDI自身の世界戦略と絡んで、グローバルなサービス展開の手厚さは変わっていくでしょう。また、KDDIが買収したSORACOM以外とのシナジーというのはありそうに見えます。あとは、いつSORACOM Air for 5G/NB-IoTとかそういったものがリリースされるかだけですね。

※追記：NB-IoTではありませんでしたが、LTE-M（Cat.M1）に対応したのは皆様ご存知の通りです。

仮想ネットワークとしては、以前から要望を送っているVPG上のファイアウォールや、透過プロキシなどに使えるL4レベルのJunction、トラフィック・フローダンプ、そんな感じで既存のネットワーク機能が素直に移植されていくものと思います。

クラウド連携としては夢が尽きないところですが、AWSであることを活かして自分で用意したLambdaとの結合や、AWS IoTなどデバイスツイン系のサービスのSORACOM独自提供、スマートフォンのNFC/FeliCa連携によるユーザ認証、先ほど書いた収集データの分析基盤など、複数の利用者が必要としそうな機能を継続的に貪欲にSORACOM-izeしていくのではないかと思います。

Harvestのような単体で完結するサービスについても、管理者がコンソールから見るだけではなく、パートナーとの関係性もありますが、外部ID基盤と連携して一般ユーザ向けの画面を提供といったBIツールの領域に踏み出す可能性もあります。

※追記：既に書いたとおり、一般ユーザ向けの可視化画面を提供するSORACOM Lagoonがリリースされました。

今後もSORACOMのニューリリースから目が離せなさそうです。

Re: 今後のSORACOM予想

ここまでは2017年の夏に書いた内容でした。

改めて2018年末として今後のSORACOMの流れを予想すると、来年2019年にはこのあたりが来るのではないでしょうか。

エコシステムの拡充

SORACOM Funnelの接続先など引き続きエコシステムの拡充は間違いなく進んでいくでしょう。

エッジコンピューティングとの連携

つい先日に、AWSのエッジコンピューティング基盤とのセキュアエレメント連携が発表されましたが、エッジとクラウドの通信など様々な形で連携が進んでいくと予想しています。

blog.soracom.jp

Global SIMの活用

Air GlobalのSIMは、SIM内のJavaアプレット実行をはじめとした国内キャリア（ドコモ/KDDI）のSIMにはできない様々な機能があります。

日本国内においてもそれらを活用した事例が増えるのは間違いが無いですし、それを前提としたさらなるSORACOMサービスがKryptonに続いて登場していくのではないでしょうか。たとえばSIMでは認証だけを行い、他の通信路を利用してSORACOMとの間にVPNを張りVPGに接続できるようなサービスなども考えられます。

高トラフィック通信への対応

今のところ「IoT向け」として比較的低トラフィックな利用が想定されていますが、エッジだけで完結できない用途のビデオストリーミングの転送や、従業員に支給する各種端末など、より高トラフィックな通信を念頭に置いたサービス群が登場すると予想しています。

今のところ、SORACOM FunnelにおいてAmazon Kinesis Video Streamsに流し込むFunnel KVSがLimited Previewとしてひっそりと姿を見せているほか、SORACOM Junctionもトラフィック異常検知などの用途にも活用できます。

ガジェット強化

ちょうどLTE-M Buttnが出たところですが、そのままLTE-M Buttonを入力機器とした活用事例も出てくるでしょうし、LTE-M Buttonの接点入力Verであったり、Wio LTEなどをベースとした「ボイラープレート的なハードウェアとソフトウェアのテンプレートセット」が大きく拡充していきそうな気がしています。