[レポート] SORACOM のパートナー向けのイベントに参加してきた！

#SORACOM

新井成一

2019.07.18

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

おつかれさまです。CX事業本部の新井です。

先日、ソラコム社が開催するパートナー向けのイベント、SPS Technical Deep Dive Specialに参加してきたので、セッションレポート投下します。

当イベントでは、システム構成の紹介から実際の利用シーンを想定したデモまで、丁寧に紹介してもらいました。

また、先日のSORACOM Discovery2019で発表された新サービスも総ざらいする盛りだくさんのイベントでした。

計4時間の濃密な内容だったので、私個人（開発者視点）で気になったポイントやこんなシチュエーションに使えそうだな！と思ったところをピックアップしてみました。

セッションタイムテーブル


14:00-14:50	クイックIoT SORACOM Harvest, SORACOM Lagoon
15:00-15:50	クラウド連携 SORACOM Beam, SORACOM Funnel
16:00-16:50	遠隔制御/双方向通信 SORACOM Gate
17:00-17:50	業務システム連携 soracom-cli/API

登壇者

大瀧　隆太
- 株式会社ソラコム　ソリューションアーキテクト
松下　享平
- 株式会社ソラコムテクノロジー・エバンジェリスト

セッション1 : クイックIoT SORACOM Harvest, SORACOM Lagoon

どの部分の話か？

ここでのポイントは、データ収集と可視化になります。

SORACOM Harvestは、センサー情報、位置情報の収集して指定の期間ソラコムにデータを貯めておくためのデータ収集用サービスです。一方、SORACOM Lagoonはコンソール上からダッシュボード作成/共有サービスができる可視化サービスになります。

どちらもPublic Betaとして展開しているサービスで、収集したデータを一定期間蓄積し、目的に応じて複数のグラフ、テーブル、地図等を組み合わせたダッシュボードを作成することが可能です。

SORACOM Harvest
- データ保存期間
- アップロードされたデータは標準で40日間保存
- 延長オプションにより731日間保存可能
- 扱えるデータ
- SORACOM Harvest Data
  - テキスト、JSON、バイナリなどデータが扱える
  - SORACOM Air for セルラー、SORACOM Air for LoRaWAN、SORACOM Air for Sigfox に対応
  - プロトコルは、HTTP、TCP、UDP、USSD、SMS が利用可能
- SORACOM Harvest Files
  - 画像やログなどのファイルが扱える
  - プロトコルは、HTTP
SORACOM Lagoon
- ダッシュボードの作成が可能
- latitudeやlongitudeみたいなデータを送ると、内部的に位置情報と認識して地図ダッシュボードにマッピングされる
- グラフのカスタマイズはある程度可能
- データ分析する必要がある場合は、きついかも
- 作ったダッシュボードを共有できる
- ソラコムのアカウント持っていなくもユーザの招待が可能
- ユーザ毎に権限（ロール）設定が可能
- 閾値を設定して、アラート通知できる

感想

従来のデータ転送サービス（FunnelやBeamなど）と違い、ソラコム内のクラウド基盤にデータを蓄積・可視化を行える仕組みが提供されました。これにより、データ収集と可視化がより簡単に！クラウドのセットアップなしでできるようになりました。

全体を通して、個人的にいいなと思ったのは以下2点です。

1点目は、システムの求める要件次第ではソラコムの仕組みだけで完結するものも出てくるのではないか？という点です。

デモを拝見した限りでは、ある程度ダッシュボードのカスタマイズができそうなので、内包される機能や規模感がマッチすれば、実運用でも十分使えそうです。

従来はクラウド連携を前提としていたケースが多いと思いますが、気にする必要がなくなります。これに加え、ソラコム側でもプリセットアップ済みのデバイスを用意してくれているため、とりあえずやりたい！となってから、プロトタイプ作成するまでのリードタイムを短縮してくれます。デバイス、センサーの選定、設置、実施(データ蓄積)など面倒いろいろやることはありますからね。

なにはともあれ、ソラコムのSIMを購入してコンソールから登録するだけなので、実際に利用してみるのが速そうです。そのための仕組みは十分用意されており、スピード感を維持するためには、これらをうまく利用していくのがいいでしょう。

2点目は、SORACOM Harvestでデータを蓄積するサービスが、デバイス開発者とクラウド開発者の責任分界点として利用できそう。という点です

あくまで個人的経験に基づくのですが、デバイスとクラウドの疎通の際に、データ送信がちゃんとできているかどうか？の確認は意外と大変だったりします。

デバイスの開発者に、クラウドのコンソールにログインしてログ確認して。。。ってお願いするのは結構難しい部分がありますし。クラウド側の開発者としては、デバイスが物理的に手元にない場合も多いので、デバッグする際は一緒にリモート会議しながら、ってパターンが多いのではないかと思います。

SORACOM Harvestを利用すれば、SORACOMコンソールへの招待し、画面から送信データのログを見てもらうことができます。

デバイス開発者とクラウド開発者の両方がHarvestを起点として、どちらに問題があるのか？というのを両者が確認できる手段として有効だと思ました。

セッション2 : クラウド連携 SORACOM Beam, SORACOM Funnel

どの部分の話か？

このセッションでは、SORACOM Funnelについての紹介がメインで、最後のほうにBeamとFunkが少しって感じでした。

SORACOM Beam、SORACOM Funnelどちらもクラウドやオンプレサーバへのデータ転送サービスですが、その目的と用途が多少異なります。Beamはどちらかというと暗号化とプロトコル変換で、Funnelはクラウドサービスへのデータ転送に特化したアダプターという印象です。

使い分けについては、こちらの記事のSORACOM Beamとの違い・使い分けのところが1つ指標になるのではないでしょうか。

SORACOM Funnel
- クラウド連携アダプター
- Harvest&Lagoonで要件を満たせない場合に選択肢として上がる（データ分析が必要なケースなど）
- クラウドとの接続に必要な認証情報をデバイスに持たせる必要がない（認証情報の管理が楽）
- マルチクラウド対応しているので、ベンダーロックインを意識しないで済む
- デバイス側に特別な、ライブラリのインストールも不要
- クラウドにデータ送りたいが、デバイス側の開発が難しい場合など、ノンプログラミングで実現できる
- 送信データをUnified Endpointに集約することで、HarvestとFunnelを組み合わせて使うこともできる
- Unified Endpointの利用料はかからないので、基本的はこちらを使うといい
- 送信データにtimestampが付与される
- デバイスを識別する手段として、 IMSI / IMEI が付与される
SORACOM Beam
- 汎用的なデータ転送サービス
- MQTTを利用した双方向通信が可能（Funnelはできない）
SORACOM Funk
- ソラコムからクラウドサービスのFunctionを直接実行できるサービス
- デバイスからのHTTPリクエストのレスポンスとして、SORACOM Funkからの起動したFaaSの戻り値を使えるらしい

感想

SORACOM Funnelでは、Unified Endpointに集約して受け流せるという点が魅力でした。

後段でHarvestやFunnelやFunkを組み合わせて自由に使えますし、また無料というのがいいですね。

SORACOM Beamに関しては、プロトコル変換を行いたい場合や双方向通信を行いたいユースケースに上がってくる選択肢になるかと思います。

中でも1番気になったのがSORACOM Funkで、デバイスがサーバとの同期的な処理を求めるケース（具体的には思いつきませんが）にはとても有用なのではないでしょうか。

また、極端な話これだけである程度のサービス作れるのでは？とも思いました。ここらへんは、今後試していきたいですね。

セッション3 : 遠隔制御/双方向通信 SORACOM Gate

どの部分の話か？

今まではデバイスからのデータ収集でしたが、ここからはデバイスに対する遠隔操作の話になります。

IoTデバイスとのLAN接続サービスを提供するサービスとのことです。リモートからデバイスへセキュアにアクセスしたり、デバイス間での通信をおこなうサービスのようです。

例えば、

「メンテナンスのためにデバイスのシェルにアクセスしたい」

「カメラなどからのストリームデータの受信のために中継点を通さずに、ピア・ツー・ピアで接続したい」

といった場合に、デバイスにグローバルIPアドレスを割り振ることなく実現できます。

アンチパターン
- 遠隔操作をする際に、Global IPを割り当てられるsimを購入して、sshなどでリモートアクセスを行おうとするケースなど
- マイコンチップだと、そもそもフィルタリング（権限管理）の仕組みがないのもあるので、endpointと鍵がわかればなんでもできてしまう
- 仮に、LinuxベースのOSを搭載しているデバイスで、高度な権限管理を行えるとしても、IPを特定されてDOS攻撃されたら通信費が負担になる
- ソラコムだと、侵入経路がなく、ネットワーク側から入られるケースがないので、上記の懸念はなくなる
アーキテクチャパターンの判断基準

IPアクセスパターン
- デバイスに対して、ssh/rdpで直接リモートアクセスするパターン
- 先ほど挙げた、エンドツーエンドの通信をいかにセキュアにできるか？が課題
- 1.オンデマンド・リモートアクセスパターン
- SORACOM Napter(新サービス)を利用することで、SIMに対してGlobal IPを一時的に割り当てることが可能
- ポート番号、有効化時間、アクセス元IPアドレスレンジを指定可能
- TLSオプション設定
- Napterの削除&再設定がコンソールから簡単に可能
- 攻撃のリスクをより軽減できる
- 2.Gate Breakoutパターン
- SORACOM Gateを利用し、デバイスと操作PCの両方にSIMを挿入して直接通信するパターン
- 3.Gate Peerパターン
- 踏み台サーバを経由して閉域網で通信を行う
- 内部的に利用しているVGPの利用料が大幅値下げしたので、より安く使えるようになった
- 1はデバイス数の増加とSIMの利用数が比例するので、接続台数が増えれば3のほうが安くなるケースがある
アプリケーションパターン
- 自分たちでアプリケーションを実装し、MQTTなどでデバイスに対して操作を行うパターン
- sshやrdpなどができない場合にマッチする (マイコンなど)
- 一方、MQTTのトピック設計やアプリケーション実装など、自分たちでやる必要がある
- SORACOM InventoryのLWM2Mを利用することで、デバイス側はエージェントをインストールし、ある程度フレームワークに沿った形で開発をするのもよい
デバイスリードパターン
- デバイスからのHTTPリクエストに対し、サーバーが命令を含めたレスポンスを返すことで、デバイスが処理を実行するパターン
- すべての処理はデバイストリガーになる
- メリット：
- 堅牢で、規模に左右されにくい
- 負荷分散が用意 (HTTPのロードバランシングだから世の中的に結構知見がある）
- いつ来るかわからない操作側からのメッセージをまたなくていい
- デメリット
- 即時性が低い

感想

アプリケーションパターンについて言えば、個人的にSORACOM Inventoryがある程度フレームワークにのっとってデバイスの操作を実現できるという点でいいかなと思っています。

一方で、普段クラウド側のアプリケーション開発をしているということもあって盲目的でしたが、業務要件次第では他のパターンも十分検討しなくてはいけないなと感じました。

また、デモを拝見する限り、新サービスのSORACOM Napterがすごく直感的に使えそうだな。と思いました。

セッション4 : 業務システム連携 soracom-cli/API

どの部分の話か？

個人的には、このセッションが一番興味ありました。運用の自動化や、実際のシステム開発で利用する部分でもありますからね。

アカウント管理
- SIMに紐づくrootアカウントが払い出される
- ユーザを招待できる (SAM User)
- 細かな権限roleの制限ができる
APIの利用
- API Reference
- APIとして利用する場合は、認証キーを使いましょう
- 操作の流れとしては
1. 認証キーと認証キーシークレットでTokenを取得
2. リクエストに、API Key を添えてAPIコール実行
- 自分でプログラム組みたい人はいいけど、Soracom-cliってのがあるので、基本的な操作はこちらでやると便利
- 実際のSimの購入とか必要なく、金額気にしなくて利用できるAPI Sandboxってのがあるのでこれも便利
SORACOM CLI
- SORACOM CLI
- いろいろなサブコマンドやオプションが用意されているので便利
メタデータサービスの利用
- デバイス自身が使用しているSIMの情報をHTTP経由で取得、更新できます
- デモでは、タグに Debug:true を設定して、デバイスがタグの情報を取得した後、ログレベルを変更してました