「IoT虎の巻」ベストプラクティス・アンチパターン【SORACOM Discovery 2023】

IoTをビジネスで活かすためには、技術面のみならず製造やキッティング、出荷や交換といったオペレーション面の設計も求められます。本セッションでは、IoTでお悩みのお客様と数多く接しているソラコムのソリューションアーキテクトが、現場で培った実践的な経験をベースにIoTにおけるベストプラクティスやアンチパターンを紹介します。これからIoTに挑戦される方が、IoTを始める前に知っておくことで失敗を回避できるポイントを網羅的に学べる「IoT虎の巻」をご覧ください。

株式会社ソラコム ソリューションアーキテクト 松本 悠輔

Transcript

1. 「IoT虎の巻」 ベストプラクティス・アンチパターン 株式会社ソラコム シニアソリューションアーキテクト 松本 悠輔(ysk)
2. 本日のハッシュタグ #SORACOM @SORACOM_PR fb.com/soracom.jp youtube.com/@SORACOM_Japan instagram.com/soracom.official 使用例 他には… • #SORACOM IoTやDXの話を聞きにきた • キーノートは2日目！ #SORACOM #SORACOM の検索で、最新情報が！
3. 松本悠輔（Yusuke Matsumoto） ソリューションアーキテクト 経歴： • インフラエンジニア • Webエンジニア • IoTエンジニア 好きなサービス：SORACOM Junction 自己紹介 SORACOM本の一部執筆を 担当しています！
4. セッション概要 本セッションでは、IoTでお悩みのお客様と数多く接しているソラコ ムのソリューションアーキテクトが、現場で培った実践的な経験を ベースにIoTにおけるアンチパターンとベストプラクティスを紹介しま す。
5. なぜアンチパターンを紹介するのか？ • 本来であればポジティブなプラクティス（型）を紹介したい一方 で、プラクティスは正しく活用できなければアンチパターンに陥っ てしまう場合がある。 • プラクティスの裏には必ず「こうあってはならない」アンチパター ンが存在し、プラクティスはそこに至らないためのガイドレールに なっている。 • このセッションは「こうあってはならい」と背景にある「何故」を紹 介し、プラクティスを正しく活用していただくことを目的とする。
6. • これから紹介するアンチパターンとベストプラクティスはビジネス がスケールしてデバイスの数が10,000を超えているフェーズ（量 産フェーズ）で最も有効な内容です。 • PoCやビジネスの初期フェーズではむしろビジネススピードを阻 害する要因になる場合もあるため、活用の是非は慎重に検討し てください。 ⚠ 注意 ⚠
7. アンチパターン具体例紹介
8. IoTを構成する3つの要素 1. ネットワーク 2. デバイス 3. クラウド
9. アンチパターン具体例紹介 1. ネットワークのアンチパターン 2. デバイスのアンチパターン 3. クラウドのアンチパターン
10. IoTデバイスに 直接グローバルIPアドレスを割り当てる • デバイス個別に直接グローバルIPアドレスを割り当てて リモートアクセスや遠隔制御を行う • サーバーサイドでアクセス元IPグローバルアドレスに基 づいた制御を行う ネットワーク 192.0.2.1 192.0.2.2 192.0.2.3 192.0.2.4 アンチパターン
11. IoTデバイスに 直接グローバルIPアドレスを割り当てる • グローバルIPアドレスは直感的にリモートアクセスできる一方で、デバイ スが乗っ取られてしまったり改ざんされるリスクがある • グローバルIPアドレスは重複の無い一意な識別情報の側面を持つ一方 で、グローバルIPが別のデバイスで再利用される可能性があるため、 データ管理に課題がある • 例：IPアドレスがx月x日まではデバイスAとして扱い、以降はBとして扱うと いったように日時をベースに考える必要があると、データの取り扱いに根本的 無難しさがある x月x日 device_ip date device_name temperature 192.0.2.1 1685936783 device_a 25.0 192.0.2.1 1685936843 device_a 25.1 192.0.2.1 1685936903 device_b 25.2 192.0.2.1 1685936963 device_b 25.1 ネットワーク アンチパターンの背景
12. IoTデバイスにはグローバルIPを 直接割り当てない前提のアーキテクチャを推奨 • デバイスへのリモートアクセスはセキュアネットワーク経由で行う仕組みを 強く推奨 • 例：SORACOM Napterのようなセキュアリモートアクセスの仕組みを活用す る • デバイスの識別情報はIPアドレス非依存な仕組みにする • デバイスごとの論理的なユニークID（下記例ではdevice_uuid）を主キーとし て、IPアドレス情報は従属する情報のうちの1つとして扱う device_uuid date device_ip temperature 3126c570-4bb0-bf4d-857c-6ee97f3659bf 1685936783 192.0.2.1 25.0 3126c570-4bb0-bf4d-857c-6ee97f3659bf 1685936843 192.0.2.1 25.1 4ac0ab10-0507-7cda-eafc-78ae15f7123b 1685936903 192.0.2.1 25.2 4ac0ab10-0507-7cda-eafc-78ae15f7123b 1685936963 192.0.2.1 25.1 例：SORACOM Napter ネットワーク ベストプラクティス 参考 https://soracom.jp/services/napter/
13. LTEの再接続を頻繁に繰り返す • LTEを利用するアプリケーションが通信の度に通信モ ジュールレベルで無線の再接続（接続断、接続の繰り返 し）を行うATコマンド操作をMCUから行う • 1時間に1回等定期的に再接続を行うロジックを実装する ネットワーク アンチパターン
14. 3GとLTEとではベストプラクティスが異なる • LTEデバイスの再接続は、接続するだけでネットワークの間で信号 のやりとりが発生しネットワークの負荷になる • 無線は共用リソースなので頻繁な接続・接続断はネットワークに接 続要求が拒否されることがある • 3Gの時代はアプリケーション通信時以外はモジュールを寝かせて おくのがベストプラクティスだった。 • 3G時代はリソースを解放することが是とされていた • 現在主流のLTEにおいても3Gと同様に頻繁に無線の接続・切断を 繰り返す設計はアンチパターン • 通信する時にAT+CFUN=1,1し、終わったらAT+CFUN=0するようなイ メージ ネットワーク アンチパターンの背景
15. LTEは常時接続が基本 • LTEはAlways onの考え方があり常時オンライン、常時 接続が基本。 • 無線リソースは自動的に適宜開放されるので利用者が 意図して切断する必要はない • RRC Connectionが比較的短い時間でsuspend / releaseされる • 消費電力の最適化が必要なケースではLTE以外の通信 方式の活用を検討する ネットワーク ベストプラクティス
16. モジュールの価格を優先して通信方式を決定する • LPWAモジュールが比較的安価なので価格メリットを優先して通信方式を LWPAに選定する • ビジネス上そうせざるを得ない場合はある • LTEとLTE-Mのモジュール価格を比較すると2倍程度価格差がある場合があ る • LTEとLTE-Mを比較した際に「安くて省電力」なLTE-Mを選定する • 両方IP通信を行うことができるためデバイスへの給電が安定しているユース ケースではデバイスの価格差からLTE-Mが選定される場合がある ネットワーク アンチパターン
17. 通信方式はビジネス展開を見据えて総合的に判断 • LPWAは通信モジュール価格が安価な一方で、データ通信費用 （データ通信単価）が高い傾向にありデータ通信ボリューム次第 ではLTEの方がコスト最適な場合がある。 • また、各種LPWAは国によってサービス提供状況が大きく異な るのでグローバル展開を考える場合には通信方式の選定が重 要。 ネットワーク アンチパターンの背景
18. 各国でのLTE-MとNB-IoTのサービス提供状況 参考 https://www.gsma.com/iot/deployment-map/ データ通信量や事業展開先の国や地域を 考慮したうえで通信方式を決定する ネットワーク ベストプラクティス
19. 無線ネットワークが常時安定している 　　　　　前提でシステムを設計している • 有線ネットワークと同じ前提で無線ネットワーク上でアプリケー ションの通信設計をしている • 動的ルーティングプロトコルの各種インターバルやタイマー、死 活監視の頻度を高めに設定している • アプリケーション通信失敗時のリトライを考慮しない ネットワーク アンチパターン
20. 無線通信が外部からの影響で変化することを 把握しておく • 無線通信は周囲の環境の変化によって品質が変化する • 周囲の利用者の増減 • 物理的な遮蔽物の存在 • 外部からのノイズ影響 • ネットワーク品質の変化は最終的にスループット、遅延、ロス レートといった形で現れる • アプリケーションの通信が特定のタイミングだけ失敗する、と いった形で問題が顕在化する可能性がある ネットワーク アンチパターンの背景
21. 無線ネットワークでの通信プラクティス • 通信が失敗する前提でリトライの仕組みを実装する。 • リトライはリソースの有効活用の観点からExponential Backoff でのリトライを強く推奨 • https://aws.amazon.com/blogs/architecture/exponential- backoff-and-jitter/ • デバイス設置環境の無線品質を継続的に測定・収集すること を推奨 • https://zenn.dev/2matzzz/articles/5dc6627104d9fa • 各種パラメータは無線環境に適した値に設定する ネットワーク ベストプラクティス
22. アンチパターン具体例紹介 1. ネットワークのアンチパターン 2. デバイスのアンチパターン 3. クラウドのアンチパターン
23. デバイス内の情報があとから更新できない • 全てのデバイスに同じクラウドへの接続情報やアクセス キーが焼き込まれている • デバイスの振る舞いを決めるパラメータが固定値になっ ている • デバイスを破棄する場合に秘密情報を削除できない デバイス アンチパターン
24. あらゆるパラメータは運用中の変更を考慮する • 接続先情報は変更になる可能性がある • 接続先IPやURLパスが変更になる可能性がある • 場合によってはドメイン名が変更になる • クラウド接続用認証キーのような秘匿情報は漏洩や不正利用される可能 性を考慮する • 全てのデバイスで異なる認証キーを利用することは大前提 • 異なっていたとして、後からの更新機能は必須 • データの送信頻度は通信コストやバッテリー駆動デバイスの連続稼働時 間に直接影響がある重要なパラメータ • 運用中に変更できることが強く望ましい • デバイスライフサイクルを考えると破棄や再利用時に秘密情報を削除す る初期化機能相当の実装が必要 デバイス アンチパターンの背景
25. パラメータを外部から注入できる仕組みにする • デバイスごとに異なるパラメータを配信する管理システムを用意する • この接続先だけはデバイスにハードコードする必要がある • IP直指定ではなくFQDN指定であることが望ましい • セキュリティ情報を動的に取得する機能が望ましい • デバイス内の情報を削除する遠隔または直接操作する機能を用意する デバイス ベストプラクティス デバイス 管理システム IoTデバイス 直接削除操作 遠隔削除操作 パラメータ配信 認証キー パラメータ 参考 https://users.soracom.io/ja-jp/docs/air/use-metadata/ 参考 https://soracom.jp/services/krypton/
26. ファームウェアアップデート機能がない • デバイスがシンプルな作りなのでアップデートの仕組みを 用意しない • デバイスのメインロジックのファームウェアアップデート起 動はある一方で無線モジュールのファームウェアアップ デート機能がない • データ通信契約がファームウェアアップデートのデータ量 を想定していない デバイス アンチパターン
27. ファームウェアアップデート機能はビジネス 価値のトレードオフ • ビジネス環境の変化に追従するためデバイスの機能が 変更される可能性は高い • 機能変更だけではなくて不具合対応の可能性も考慮が必要 • セルラーモジュールに不具合が発生し、修正ファーム ウェアが提供されることもある • モジュール不具合は実際に起こりうる問題としてリスク管理 しておいた方が良い デバイス アンチパターンの背景
28. デバイスには可能な限りアップデートの機能 を実装する • 可能な限りアップデート機能の実装を検討する • 実装が難しい場合でも通信モジュールのアップデート方法は確認しておく • アップデートはオンラインに限らずオフラインのアップデート方法が有用なユースケー スもある（デバイスがリース等で定期的に返ってくるような場合はオフラインアップデー トでも対応しやすい） • オンラインでのアップデート機能はデータ通信契約と併せての整理が必要 • リリース直後はアップデートの頻度が高く、時間経過とともに落ち着いてくる • それを踏まえてデータ通信契約には余裕をもっておく デバイス ベストプラクティス ファームウェア デバイス 管理システム IoTデバイス 参考 https://soracom.jp/services/harvest/
29. アンチパターン具体例紹介 1. ネットワークのアンチパターン 2. デバイスのアンチパターン 3. クラウドのアンチパターン
30. サーバーレスポンスが巨大 • デバイスからのデータ送信に対してサーバからのレスポ ンスデータの方が大きい • デバイス設定用のデータが大統一JSONになっている • Valueが空文字のKeyで埋め尽くされた設定データ クラウド アンチパターン
31. 開発チーム横断での最適化が必要 • デバイスが一度に扱えるデータに限りがあることをチー ム間で共有できていない • データの送受信にかかるコスト認識の共有不足 • IoTでは不要なデータをやり取りすることはそのままコストに 直結するので必要なデータだけを送り合うように注意が必要 クラウド アンチパターンの背景
32. サーバーとデバイスとの間でやりとりする データは常に必要最小限にする • サーバーからのレスポンスを必要最小限にする • ボディは必要最小限に、必要のないデータはどんどん削っ てしまう • JSONであればValueのないKeyは落としてしまい、HTTP であればヘッダーを必要最小限に クラウド ベストプラクティス
33. デバイスの通信仕様に合わせてセキュリティ を犠牲にする • レガシーデバイスがUDP/TCPのソケット通信やFTPでの データ転送にしか対応していないのでVMベースかつイン ターネット向けにデータ受付サービスを構築する クラウド アンチパターン IoTデバイス インターネット データ受付 サービス tcp://example.com:20000 udp://example.com:30000 各種クラウド サービス https://example.com UDP/TCP to HTTPS UDP/TCP HTTPS
34. セキュリティ、運用性がトレードオフに なっている • デバイス + インターネット接続 + クラウドの組み合わせではどうしてもトレードオフがある • デバイス側にプロトコル変換のためのサイドカーを追加するか、インターネットを経由しないネットワーク 接続方式が必要 クラウド アンチパターンの背景 IoTデバイス インターネット データ受付 サービス https://example.com サイドカー IoTデバイス 閉域網 データ受付 サービス tcp://example.com:20000 udp://example.com:30000 各種クラウド サービス https://example.com UDP/TCP to HTTPS UDP/TCP HTTPS プロトコル変換 パターン セキュア ネットワーク パターン
35. マネージドなIoTプラットフォームサービス の活用でトレードオフを回避 • IoTプラットフォームサービスから提供されるプロトコル変換サービスや、クラウドと セキュアにネットワーク接続サービスを活用する • マネージドサービスをシンプルに活用して競争の源泉となる部分にエンジニアリングリ ソースを集中させる クラウド ベストプラクティス 例：プロトコル変換サービス SORACOM Beam 例：プライベート接続サービス SORACOM Canal https://soracom.jp/services/beam/ https://soracom.jp/services/canal/
36. なぜアンチパターンに陥るのか？
37. IoTプロジェクトのアンチパターン 特定の技術要素のメリットを優先していて 全体最適ではない状態になっている
38. IoTプロジェクトの体制 デバイス ネットワーク クラウド 現実によくある体制 Aさん Bさん
39. IoTプロジェクトの体制 デバイス ネットワーク クラウド 各領域がクロスオーバーしている状態が理想 Cさん Dさん Eさん
40. 全体最適されたアーキテクチャ設計 IoTでは様々なトレードオフがある • デバイスのサイズとバッテリー容量 • セキュリティプロトコルと通信データ量 • 無線通信方式と柔軟性 • クラウドに実装する機能とデバイスに実装する機能 • 通信頻度とデバイス連続稼働時間 これらのバランスをとることが重要
41. アンチパターンに陥らないようにするには？ • 組織力を高める • 各技術領域に長けた人材を採用する、できれば２つ以上の領域 に強い人材を採用・育成する • 外に知見を求める • 自組織に足りない知見を外部のプロフェッショナルに補完しても らう • デバイス、ネットワーク、クラウドの全体アーキテクチャレビューを 受ける • 量産に耐えうるクラウド環境構築支援 • 量産は物流やキッティングの観点も重要
42. SORACOMのサービスで ベストプラクティス活用を推進
43. IoT テクノロジー民主化のためのプラットフォーム SORACOM Global Platform ライブラリ & SDKs 
 CLI(Go), Ruby, Swift Web インターフェース
 User Console データ転送支援
 SORACOM Beam クラウドアダプタ
 SORACOM Funnel データ収集・蓄積 SORACOM Harvest プライベート接続
 SORACOM Canal IoT向けデータ通信
 SORACOM Air for Cellular (2G, 3G, LTE, 5G) / LPWA (LoRaWAN, Sigfox, LTE-M) 専用線接続
 SORACOM Direct 仮想専用線
 SORACOM Door API Web API Sandbox コネクティビティ ネットワーク インタフェース SIM認証・証明
 SORACOM Endorse デバイス管理
 SORACOM Inventory 透過型トラフィック処理
 SORACOM Junction ダッシュボード作成/共有
 SORACOM Lagoon セキュアプロビジョニング
 SORACOM Krypton アクセス権限管理
 SORACOM Access Management アプリケーション デバイスLAN SORACOM Gate 開発者サポート
 Developer Support USB ドングル / セルラーモジュール / マイコンモジュール / ボタン 
 デバイス オンデマンドリモートアクセス
 SORACOM Napter クラウドファンクション
 SORACOM Funk エッジプロセッシング SORACOM Mosaic オンデマンドパケットキャプチャ
 SORACOM Peek インラインプロセッシング
 SORACOM Orbit 次世代VPG
44. SORACOM Professional Services サービス活用支援 IoTシステム設計開発支援 プロジェクト推進支援 ソラコムサービスの効果的な活用及びシ ステムへの導入をご支援します アーキテクチャ設計やプロトタイピングを通じた システム設計開発をご支援します SORACOM Professional Services(以下PS)はソラコムサービス及びパートナーエ コシステムを最大限に活用し、エンタープライズでのIoT活用を技術面からご支援する サービスです。 技術的な課題やタスクの整理によりお客様のプ ロジェクト推進をバックアップ致します
45. SORACOM エンジニアリングサービス
46. SPSパートナー数 (2023/3) デバイス パートナー テクノロジー パートナー ソリューション パートナー 申請パートナー 900社超(Total) 認定済パートナー 156社(Total) インテグレーション パートナー SELECTEDパートナー 3社
47. インテグレーション (15社) デバイス(47社) ソリューション(57社) テクノロジー(37社) SPS認定済パートナー 156社 (2023/3) SELECTED
48. まとめ
49. まとめ • IoTのベストプラクティスの裏にはアンチパターンがある • ベストプラクティスを適用できない場合でも、アンチパター ンに陥らないようエコシステムの力を借りてビジネスを強 化する • IoTプラットフォームのサービスはベストプラクティスが ベースにある • プロジェクト体制全体で技術的な知見が各領域でクロー スオーバーしている状態が理想