こんにちは。SORACOM UG運営の木澤です。
SORACOM Advent Calendarへの執筆は2018から5年間続けております。
今年のアドベントカレンダーはソラカメで何かしようかなと思いつつも間に合わなかったので、IoTデバイスとAWSの接続方法について、SORACOMプラットフォームの活用を交えて整理したいと思います。
2022年のSORACOM UG活動振り返り
私は微力ながらSORACOM User Group(以下SORACOM UG)の活動に協力しております。
今年は業務や家庭の事情により積極的なアウトプットはできなかったのですが、それでも過去の貢献について評価頂き、お陰様で今年 SORACOM MVC 2022の表彰を頂くことが出来ました。ありがとうございます!
表彰理由がコロナ禍におけるイベントのオンライン配信を支えたという点であったのですが、やはりIoTは「モノのインターネット」である故、モノ(デバイス)を通じた体験が重要になります。
そこで2022年はSORACOM UGにとって、オフライン(会場)イベントを復活させた1年となりました。
再開第一弾として、Tech-Onさんとの共同イベントを4月に開催したのですが、本イベントでSORACOM UGとSORACOMプラットフォームについて説明させて頂きました。
本来、SORACOMサービスの説明はソラコムのMAX(松下さん)等にお任せしても良かったのですが、UGとして説明資料を持っていても良いかなと考え、私の理解で記載した次第です。
なお本資料はUGメンバーでも共有され、後のUGイベントでも活用頂いているようでうれしい限りです。
IoTデバイスとクラウド(AWS)の接続の考え方
2022年のソラコムイベントとアップデート
さて、本ブログでも過去にSORACOMサービスとAWSを組み合わせたアイディアについて、幾つかアウトプットをしておりますが、私においてはクラウドへの接続方法については断片的な理解となっていました。
そんな中、11月にソラコムさん主催でウェビナーが開催され、ソラコムのMAX(松下さん)とkoya(小梁川さん)よりAWSと組み合わせたアーキテクチャに関する解説を頂きました。
これが私にとっては頭の中の理解を体系的に理解を整理する良いきっかけとなりました。
また、先日12/19にはSORACOM Beamにて大きなアップデート(AWS 署名バージョン4 [SigV4] 対応)がありました。
そこで今回は、これらイベントの内容やその後のアップデートを交えて、主にSORACOMプラットフォームを用いて IoTデバイスからAWSクラウドに接続する方法について私の理解をもとに書きたいと思います。
IoTシステムはサーバレスアーキテクチャで検討すべき
さて「IoTはテクノロジーの総合格闘技」などと以前から言われているかと思います。
- ハードウェアデバイス(マイコン・電子回路やセンサー)
- ハードウェアデバイスのファームウェア
- ネットワーク(接続方法)
- サーバー側の収集・蓄積ロジック
- データ活用(分析・可視化)
これら一連のテクノロジーが組み合わせて初めてビジネス価値を創造するものであり、これがIoTにおけるデジタルトランスフォーメーションの形だと理解しています。但しこれらの技術全てに明るい企業や人は殆どおらず、どうしても強み弱みが出てくるため、全て自前で設計・構築しようとすると多大な時間・コストが掛かる恐れがあります。
実世界のデータを収集・分析して活用しようというIoTにおいては、一発で成功するとは限らないため 素早く開発しアジャイルに推進することでフィードバックループを回すことが大事であり、そこで役に立つのがクラウドを活用したビルディングブロックという考え方です。正にブロックを組み立てるようにクラウドのマネージドサービスを利用することにより、上記の4と5の開発を省力化することが可能です。
ブロック(部品)でも特にAWS Lambda等、クラウドにおけるFaaSサービスがよく用いられます。
IoTにおいては実世界の事象に合わせたイベントトリガーで処理が発生するため、以下のような悩みが発生することがあります。
- いつデータが来るかわからないけど、サーバは常に待ち受けている必要があり、無駄が多い
- 本番環境では信頼性(可用性)を高めるために、冗長化等の検討を行なう必要がある
- デバイス数の増加に合わせてスケール拡張を検討する必要があるが、サイジングが難しい
4月のイベントでも採りあげた話題となりますが、オンプレミスでシステムを構築しサーバで待ち受けるには相性が悪い。
AWS Lambda等のFaaSサービスは、待ち受けにはコストは掛からず、呼ばれた際に実行時間に応じたコストが発生するだけですし、冗長化やスケール(※)の心配をする必要も無いということで非常に相性が良いという訳です。
※ 同時実行数には制限があります
SORACOMのクラウド転送サービス(Beam/Funnel/Funk)を用いるべきか
SORACOMプラットフォームには、AWSへのデータ転送を支援してくれる便利なサービスがあります。
これらを用いなくても、デバイス側にAWS CLIやSDK、AWS IoT Greengrass等をインストールすることでクラウドとの接続を実装することは可能です。
但し、以下のような課題が発生することがあります。
(これも4月のイベントで採りあげた話題ですが)
- クラウドへの接続情報(クレデンシャル)の管理
クラウドへの接続情報ををデバイスにインストールする必要がある。
現場に設置するIoT機器が故、盗難等による漏洩の恐れがある。 - 暗号化処理のデバイスへの負荷(電力消費)
主にHTTPSでクラウドに接続するため、暗号化処理を組み込む必要がある。
マイコンでは暗号化処理による消費電力が看過できないほか、非力なマイコンでは暗号化処理の実装が難しい場合もある。
ここで活躍するのがSORACOMのクラウド転送サービス(Beam/Funnel/Funk)という訳です。
これらを用いることで、以下のメリットがあります。
- デバイス側にクレデンシャルの保存の必要が無い
AWSへの接続情報はSORACOMプラットフォーム側に保存するため、デバイス側に保存する必要が無い。
そのため盗難等の際にはクラウド側で当該クレデンシャルの無効化処理を行なえば良い。デバイスのメンテナンスが低減できる。 - 暗号化処理を肩代わりしてくれる
クラウド接続に必要な暗号化処理をクラウド側にオフロードできるため、非力なマイコンでもクラウドへの接続ができるほか、デバイス側の消費電力低減に貢献できる。 - インターネットに出ない通信経路が実現できる(AWSとの接続の場合)
SORACOMプラットフォームはAWS上で実現されており、各通信キャリアとはAWS Direct Connectで接続されています。つまり、インターネットに出る前にデータ処理に介在できることになります。
また、SORACOM⇒AWSサービスの接続においては、AWS内での接続となりインターネットには出ないネットワーク構成となります。これはエンタープライズのお客様においても安心な構成になると思います。
(参考:NRIネットコム 佐々木さんの記事)
AWSのグローバルIPの空間はインターネットなのか? - NRIネットコムBlogこんにちは佐々木です。 先日、VPCのFAQに追加された項目が話題となっていました。2 つのインスタンスがパブリック IP アドレスを使用して通信する場合、トラフィックがインターネットを経由するかどうかという問いに対して、AWSがノーと言っ...
ということで、私としては各種メリットを享受するため、SORACOMプラットフォームのデータ転送サービス(Beam/Funnel/Funk)は積極的に利用すべきと考えています。
利用用途に応じたアーキテクチャの選択
ここからはユースケースや要件に応じたアーキテクチャの選択方法をまとめます。
なお、SORACOM Beam/Funnel/Funkを利用した構成例になっていますが、利用しなくても(上述の課題が発生するという点を除き)基本的には考え方は同じかと思います。
デバイス⇒クラウドへデータを送信したい(デバイスに処理結果を返す必要は無い)
センサーデータなど、収集したデータをとにかくクラウドへ送信し蓄積したい。なお、クラウド側での処理結果をデバイス側に返して処理を分岐する等を行う必要は無い。
この場合、以下2つのアーキテクチャが考えられ、共通するメリットとして以下があるかと思います。
- モデム駆動時間の削減(低消費電力)
デバイス側にはAWS側にデータが届いたかどうかの結果のみ返される。そのため処理を待たずに通信が終了するのでモデムの駆動時間(消費電力)が削減できる - 非同期処理であるため、デバイス数を大きくスケールできる
後述の同期処理と比較しLambda等の同時実行数に依存しないため、デバイス数が大きくスケールしても対応できる。
① SORACOM Funnel ⇒ Amazon Kinesis Data Streams ⇒ AWS Lambda
Amazon Kinesis Data Streamsを用いてデータを一旦バッファし、各種AWSサービスに受け渡すモデル。
② SORACOM Funnel ⇒ Amazon Kinesis Data Firehose ⇒ AWSのデータストア
Amazon Kinesis Data Firehoseを用いれば、データの受付・変換処理からデータストア(Amazon S3/Amazon Redshift/Amazon OpenSearch等)への保存までの処理をマネージドサービスで実現できます。
デバイス⇒クラウドへデータを送信したい(デバイスに処理結果を返す必要がある)
収集したデータをクラウドへ送信し蓄積したい。またクラウド側での処理結果をデバイス側に返して、後続の処理を行ないたい。
この場合も以下2つのアーキテクチャが考えられるかと思います。
上述のAmazon Kinesisを用いたアーキテクチャの裏返しになりますが、AWS Lambdaの処理結果に応じてデバイス側の処理を分岐する柔軟な設計が可能である反面、AWS Lambdaの同時実行数に依存することによるデバイス数の制限と処理待ちによる消費電力増が考えられます。
① SORACOM Beam ⇒ Amazon API Gateway ⇒ AWS Lambda
Amazon API Gatewayを用いれば、HTTP(S)のパス毎やメソッド毎に別々のLambda関数を組み合わせて設計した、REST APIを構成することができます。
設定方法についてはこちらに解説があります。
② SORACOM Funk ⇒ AWS Lambda
逆にお手軽にAWS Lambdaを呼び出すのに最適な構成。
但しデバイスからのメッセージが全てLambda側に伝わるため、これを全て解釈して処理を行なう必要があります。
クラウド側からデバイスの制御を行ないたい(あるいはMQTTプロトコルを用いる必要がある)
この場合は AWS IoT Coreを用いることになり、この場合プロトコルとしてMQTTSも利用できます。
AWS IoT Coreを利用するメリットとしては以下が挙げられるかと思います。
- 軽量なプロトコル MQTT(S)が利用できる
MQTT(S)プロトコルは軽量な設計であるため、HTTP(S)と比較してデータ通信量を削減できます。
またMQTTもSORACOM Beamと組み合わせて暗号化処理をオフロードすることができるので、非力なデバイスでも対応できます。 - 双方向の通信が可能
AWS IoT CoreはPub/Subモデルでのサービスであり、デバイス⇒クラウドへの送信の他、クラウド⇒デバイスの通信も可能です。そのため、クラウド側からデバイスの制御を行なうことが可能です。 - ルールエンジンにより多数のAWSサービスに連携可能
AWS IoT CoreにはSQLライクなルールエンジンがあり、ルールに基づき複数のAWSサービスにデータを転送することができるので、ルールの追加でシステムの拡張が可能になります。 - デバイスシャドウの利用が可能
AWS IoT Coreにはデバイスの状態が「どのようになっているか」「どうなって欲しいか」を記憶しておくデータストアであるデバイスシャドウの機能があります。
これを活用することで、通信状態が不安定なデバイスに対しても安定した制御が可能となります。
デバイスシャドウについては以前の記事でも触れていますのでご参考まで。
WioLTEでAWS IoT Coreのデバイスシャドウを利用するクラウドと連携したIoTの仕組みを簡単に開発できる優れものであるWioLTEを購入し学習を進めています。 今回はAWS IoTのデバイスシャドウを用いてLED発光色のステータスを管理する仕組みを作りました。
音声でWioLTEのLED発光色を変更するGoogle Homeからの音声操作でWioLTEのLEDの発光色を変更してみます。 (SORACOM UG #10 LT発表内容)
逆にデメリットとしては、上述のKinesisやAPIGateway等を用いる方式と比較すると鍵管理が煩雑であるということが挙げられるかと思います。
AWS IoT Coreにデバイスを登録、個別のプライベートキーを発行し、それをSORACOM Beam(あるいはデバイス内)に登録するといった対応をデバイス毎に行なう必要があります。
(ある程度処理の自動化を作り込むことも可能ですが)
AWSにファイルのアップロードを行いたい
最近はカメラが付いたIoTデバイスもあり、撮影した画像・動画等をAWS側に転送したいといった要件もあると思います。
従来AWS Lambda経由で送信した場合は容量制限、転送時間、それによるコスト増大などの問題がありましたが、2022/12/19発表の AWS 署名バージョン4 (SigV4) 対応により、Amazon S3などAWSの各種サービスに直接データが送信できるようになりました。
Amazon S3などAWSのデータストアに直接送信できるようになり、構成がシンプルできる他コストの低減にも繋がりそうです。またAmazon S3アップロードをトリガーにしてAWS Lambdaを実行することもできるため、各種応用もできるかと思います。
なお他のAWSサービスへの接続の可能性についても今後探っていければと思います。
まとめ
冒頭でお話ししたように、AWSクラウドへの接続方法については今まで断片的な理解でした。
本記事の執筆を機に、AWSクラウドのEdge/IoTサービスとSORACOMプラットフォームの関連性をユースケースを交えて整理できたのは良いきっかけになりました。今後ユースケースに応じてアーキテクチャを検討する際には正しく選択できそうです。
またこうして整理してみると、まだ未経験な部分があぶり出されて触ってみたいという気持ちになりました。
個人的にも今後チャレンジして行ければと思います。
本記事が皆様のお役に立てば幸いです。
ありがとうございました。
コメント