この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
こんにちは！おおはしりきたけです。今日は、SORACOM Technology Camp 2018 に参加してきました。クラスメソッドでもIoTのプロジェクト増えてきており、本イベントでIoTシステム構築・運用の技術を学びたいと思いイベントに参加しました！
イベント概要
SORACOM Technology Camp 2018 のイベント概要は以下になります。
2019年に必要なIoTシステム構築・運用の技術を学ぶ1Day！
IoTが実践フェーズとなり、様々なシステムにセンサーや通信が取り入れられモノのデータが活用され始めています。 「SORACOM Technology Camp」は、IoT に取り組む技術者・デベロッパーが、デバイス・通信・ソフトウェアなどの専門技術が密に連携するIoTシステムの構築・運用するために、最新技術や設計手法を学ぶラーニングイベントです。
第2回目の開催となる「SORACOM Technology Camp2018 」は、「IoT活用の実践」をテーマに、プロトタイピングや、IoTシステムの運用フェーズに必要な様々な仕組みを、SORACOMのサービスによる解決方法、ユースケースとライブデモを交えて解説します。 2018年7月に発表した新サービス「ダッシューボード作成・共有 SORACOM Lagoon」や、セキュアプロビジョニング「SORACOM Krypton」、「SORACOM LTE-M Button」を用いたプロトタイピングなど新しいセッションもお目見えします。
これからIoT に取り組む、もしくは来年度にむけIoTシステム提案を控えている技術者・デベロッパーの方は、ぜひご参加ください。
開催概要
| 開催日程 | 2018年11月22日（木） |
|---|---|
| 開場と開始時間 | 開場：13:30 開始：19:30 |
| 参加費 | 参加費無料 |
| 会場 | 東京都品川区北品川5-5-15 大崎ブライトコア3F 大崎ブライトコアホール |
タイムテーブル
| 時間 | ベーシックトラック | アドバンストラック |
|---|---|---|
| 13:30 - 13:50 | 開会宣言 株式会社ソラコム 執行役員 プリンシパルソフトウェアエンジニア 片山 暁雄 /yaman | 開会宣言 株式会社ソラコム 最高技術責任者 安川 健太 /kenta |
| 13:50 - 14:35 | 事例で整理！IoTソリューションの開発/導入検討の進め方 株式会社ソラコム ソリューションアーキテクト 今井 雄太 /factory | モバイル回線で作るイントラネット 業務システムにもセキュアに連携 株式会社ソラコム プリンシパルエンジニア 松井 基勝 /moto |
| 14:50 - 15:35 | そのデバイス、どうしたらIoT化できますか？事例に見るセンサー/デバイスのオンライン化デザインパターン 株式会社ソラコム ソリューションアーキテクト 今井 雄太 /factory | 売れば売るほど大変"を防ぐ！「IoT デバイス初期設定の工数削減」手法 株式会社ソラコム テクノロジー・エバンジェリスト 松下 享平 /max |
| 15:50 - 17:00 | 今日から始めるセンサーデータの可視化 株式会社ソラコム ソリューションアーキテクト 松本 悠輔 /ysk | デバイス-クラウドの双方向通信デザインパターンと実践 株式会社ソラコム ソリューションアーキテクト 須田 桂伍 /kei |
| 17:15 - 18:00 | SORACOM LTE-M Button の始め方 株式会社ソラコム プリンシパルエンジニア 松井 基勝 /moto | スモールスタートの次の一手は？成長できるIoTシステムの実例と回避したいポイント ― IoTシステム開発における試行錯誤の記録 株式会社ソラコム テクノロジー・エバンジェリスト 松下 享平 /max |
セッション
セッション概要
| タイトル | デバイス-クラウドの双方向通信デザインパターンと実践 |
| 概要 | IoTシステムではデバイスからクラウドへデータを送信するだけでなく、クラウドからデバイスの状態監視やデバイスへの制御命令といった、デバイスとクラウド間の双方向通信が必要となるシーンが多々あります。 しかし、いざこうした双方向通信を実現しようとすると、様々な実装方式(どのアプリケーションプロトコルを利用する？メッセージキューは必要か？など)や考慮事項(リトライ、データ重複、データ到達保証など)が存在し、ユースケースにあった組み合わせや選択が難しいといった実情もございます。 本セッションではデバイスとクラウド間の双方向通信を実現する際のシステムデザインパターンを整理し、どういった設計や実装のポイントが存在するのか、またその中でソラコムのサービスをどのように活用できるのかをデモも交えながらご紹介します。 |
| 登壇者 | 株式会社ソラコム ソリューションアーキテクト 須田 桂伍 /kei |
セッション資料
[slideshare id=123749964&doc=techcampadvanced3-181123013848]
セッションレポート
双方向通信が必要となるシーン
- 双方向通信は上り通信と下り通信
- 上り：温度情報、位置情報。動作ログ
- 下り：制御命令、遠隔監視、データ取得
- 双方向通信は観点が2つあり、サーバー主導かデバイス主導かでも異なる
代表的な双方向通信
- 遠隔制御：遠隔からデバイスに対して更新系の処理を実施
- 遠隔監視：遠隔からデバイスの状態や死活情報を取得/確認
- M2M連携：デバイス間、デバイス - サーバーで自律的な連携を行う
双方向通信における考慮ポイント
- 本当にその通信必要ですか？まず検討したいこと
- 双方向通信は単純なデータ送信と比べ考慮することがとても多く実装も複雑になっている
- 要件そのもの、設計そのものを簡素にできないかをまずは検討することが重要
- 通信要件自体
- デバイス主導の通信として見直しできないか
考慮ポイント - 物理面
- デバイス：どういったデバイスが対象か
- 電源：稼働時の電源確保
- 台数：対象とするデバイスの台数
- 制御内容：どういった制御命令を出すか？
- セキュリティ：アクセス経路や制御情報は安全か？
消費電力と双方向通信
- デバイスがバッテリー駆動の場合、待機時及び処理時の消費電力をいかに減らすかが重要
- スリープ中は外からのリクエストを受け付けられないため、即時制御できない
- 双方向通信が求められるシーンでは消費電力と双方向通信の要件はトレードオフまたはそもそも相性が悪い
連携時に利用するプロトコル選択も重要
考慮ポイント - アプリケーション
- データ到達保証：データ到達をどこまで保証するのか？
- リトライ：データ通信失敗時のリトライ戦略をどうするか？
- 順序制御：連携データの順序制御が必要か？
- 重複排除：連携データの重複削除が必要か？
- 冪等処理：連携処理は冪等になってるのか？
双方向通信とエラー処理の課題
- IoTシステムでは多くの障害ポイントが存在
- リトライ設計やデータ到達保証レベル設計は通常のシステム設計と同じくらい重要
- 特にデバイスへの制御を伴う双方向通信において
- 作り込み自体に制約があるケースも多い
双方向通信とエラー処理の解決策
- ロジックはサーバーサイドへ配慮し、デバイスへ制御が到達する前に制御内容をハンドリングする
- あえて同期通信/密結合な連携
- リクエストを識別子処理済みリクエストを管理
- 制御自体を冪等な実装にする
デザインパターンの考え方
- 双方向通信は考慮ポイントも多く、実装をいくらでも複雑にできる
- これまでの事例や経験をもとにデザインパターンという形で整理したのが本セッション
- ユースケースや実現したい目的に応じて適切な方式案やソラコムのサービスを選択できるように整理
双方向通信の実現デザインパターンと実践
双方向通信デザインパターン
- IPアクセスパターン
- IPを指定してデバイスへ直接アクセスする方式
- アプリケーションパターン
- MQTTやLwM2Mなどの双方向通信を実現できるアプリケーションプロトコルを利用する方式
- デバイスリードパターン
- デバイス側からの上り通信を利用する方式
プロトコル・スタックで見るパターン
IPアクセスパターン
- 特徴
- デバイスに付与されたIPを指定した通信
- 通常のサーバー間通信と同じ要領で処理できるので方式としてシンプル
- 課題
- いかにセキュアにエンドツーエンドをつなぐか
Gate利用時のパケット遷移
IPアクセスパターン実装時のポイント
- ネットワーク設計
- 閉域接続先のネットワークアドレス重複などが無いようにアドレス設計は入念に
- Junction Redirectionを利用するとすべてのパケットがGatePeerを経由するので、インターネットへの出口も自社ネットワーク内に保つ必要がある
- デバイス/アプリケーション設計
- IPでアクセスできる必要がある
- 常時リクエストにこたえられるようにしておくと相性が良い。そのため電源が常に確保できているシーンに向いている
- 一度に大量のデバイスを制御する際は場合によっては不向き
IPアクセスパターンまとめ
- ソラコムサービスを組み合わせることで、最初からプライベートなネットワーク空間を利用可能
- Canal/Door/Direct + Gate + JunctionによりIPベースでの双方向通信が可能
- デバイスを指定した通信や、インタラクティブな制御に向いている
- 複数ネットワークを相互に接続する際はサーバー側のネットワーク設計も重要
- ポートフォワーディングやエンドツーエンドでのVPNトンネリングも可能
アプリケーションパターン
- 特徴
- MQTT/LwM2Mといった双方向通信を実現できるアプリケーションプロトコルやSMSなどで利用
- 課題
- 作り込みによって複雑になってしまう
MQTT全般で気をつけたいこと
- 消費電力の観点で必ずしもMQTTが有利とは限らない
- ペイロードが大きいデータをやり取りしようとしてないか
- 通信量が想定以上に大きくなってないか
MQTTにしても勝手に省電力になるわけではない！
KeepAliveのための通信が発生するためバッテリー消費や通信量の増加につながるケースもある
SORACOM Inventory LwM2M
- 専用エージェントを通じて、デバイスの状態管理・設定更新・コマンド実行を可能にしている
OMA DM LwM2M
- OMA DMとは？
- Open Mobile Alliance(OMA)で定められたデバイス管理の業界標準
- 通信プロトコルとデバイス管理オブジェクトを規定
- OMA DM LwM2Mとは？
- OMAが定めたIoT/M2M向けのデバイス管理標準
- 制約のあるデバイスでも運用管理なプロトコルを採用している
Inventoryによる基本操作
- デバイスへの命令はInventory APIにて実行する
- デバイスへはLwM2Mによるリクエストが実行される
- Observe/Notify
- 特定のリソースをObserveすることで、値の変更を起因にしてデータをサーバーサイドへプッシュ通知
- SORACOM InventoryではNotifyされたデータをSORACOM Beam/Funnel/Harvestへ連携可能
LwM2M利用時のポイント
- LwM2Mで規定しているのはリソースIDとそれに対するリクエスト及びレスポンスのフォーマットであるため実際にどういった方法で値を返すのかはLwM2Mエージェントの内部実装次第
- LwM2Mエージェントの起動やプロセス管理はOS側で設定が必要
- 定義済みリソースで要件を満たせないかを考える
- 必要なモデルのみを吟味すること
SMSによる方式のポイント
- モデムがドーマンドモードでも利用可能
- セルラーネットワークのシグナリングのみを利用している
- APIによるSMS通信ができる
- SMSから各種ソラコムサービスへの連携も可能
- 連携頻度が低いユースケースに最適
SORACOM Krypton X AWS IoT
- デバイスシャドウを直接利用する場合、SORACOM Kryptonを利用してデバイスへ直接証明書を配布可能
アプリケーションパターンまとめ
- MQTT、LwM2MとBeam/Inventoryを組み合わせることで柔軟な方式を実現できる
- 多くのデバイスとの連携や、値を基にした疎結合で自律的なシステム連携といった用途に向いてる
- 作り込みによって幾らでも複雑にできるので、シンプルな設計/実装を常に気をつける
デバイスリードパターン
- 特徴
- デバイスからリクエストに対するレスポンスに設定情報を詰めて、デバイス側でハンドリングさせるパターン
- デバイスからのポーリングもこのパターン
- 課題
- デバイスにどのようにレスポンスを返すか
- デバイスの設定情報をどう管理するか
SRACOM BeamにReq/Res方式
メタデータサービスとポーリング方式
メタデータサービスへの問い合わせにクエリを利用し、連携するデータ量を最低限に抑えられる
デバイスリードパターンのポイント
- デバイス主導での通信のため、バッテリー駆動のようなスリープを伴うケースでも利用できる
- 特に対象デバイスが多い場合、デバイスからのアクセスが集中しすぎないようにリクエストを散らすのが望ましい
- メタデータサービスはDBではないので扱いに注意すること
デザインパターンまとめ
デザインパターン選択表
まとめ：双方向通信が必要か改めて考える
その双方向通信が本当に必要化を再度検討する
- 検討ポイント、実装が複雑になるのを避ける
- 目的に対して適切な方式を選択する必要がある
- 対象台数や制御内容、対象デバイスなどを考慮する
- 双方向とトレードオフになる要件を把握
- 消費電力、設計や実装の難易度
- 双方向通信は必ずしも下りの通信を必要としない
- デバイス主導で実現する方式案も検討する
14
