IoTデバイスからAWSへの接続方法を整理する(主にSORACOM)

この記事は SORACOM Advent Calendar 2022 の12/23付記事となります。

こんにちは。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と組み合わせたアーキテクチャに関する解説を頂きました。
これが私にとっては頭の中の理解を体系的に理解を整理する良いきっかけとなりました

Ondemand - IoTデータ収集と活用で知っておきたい、AWSの基礎と実践セミナー
IoT/AWSのプロから学べる無料のオンラインセミナー。IoTデータの収集に役立つAWSの基礎知識をお伝えするとともに、”選ぶ”から”利用してみる”という次のステップも解説。プロトコルの選択、デバイスの実装、データの持ち方などいくつかのAW...

また、先日12/19にはSORACOM Beamにて大きなアップデート(AWS 署名バージョン4 [SigV4] 対応)がありました。

AWS 署名バージョン 4 (SigV4) 対応でSORACOM Beamでより多くのAWSサービスを呼出可能に! - SORACOM公式ブログ
皆様、こんにちは。ソリューションアーキテクトの松永(ニックネーム:taketo)です。 今回はデータ転送サービス「SORACOM Beam」(以下、Beam) の新しい機能についてご紹介します。Beamの「Web サイト

そこで今回は、これらイベントの内容やその後のアップデートを交えて、主にSORACOMプラットフォームを用いて IoTデバイスからAWSクラウドに接続する方法について私の理解をもとに書きたいと思います

IoTシステムはサーバレスアーキテクチャで検討すべき

さて「IoTはテクノロジーの総合格闘技」などと以前から言われているかと思います。

  1. ハードウェアデバイス(マイコン・電子回路やセンサー)
  2. ハードウェアデバイスのファームウェア
  3. ネットワーク(接続方法)
  4. サーバー側の収集・蓄積ロジック
  5. データ活用(分析・可視化)

これら一連のテクノロジーが組み合わせて初めてビジネス価値を創造するものであり、これが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)という訳です。

これらを用いることで、以下のメリットがあります。

ということで、私としては各種メリットを享受するため、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を利用するメリットとしては以下が挙げられるかと思います。

逆にデメリットとしては、上述のKinesisやAPIGateway等を用いる方式と比較すると鍵管理が煩雑であるということが挙げられるかと思います。

AWS IoT Coreにデバイスを登録、個別のプライベートキーを発行し、それをSORACOM Beam(あるいはデバイス内)に登録するといった対応をデバイス毎に行なう必要があります。
(ある程度処理の自動化を作り込むことも可能ですが)

AWSにファイルのアップロードを行いたい

最近はカメラが付いたIoTデバイスもあり、撮影した画像・動画等をAWS側に転送したいといった要件もあると思います。

従来AWS Lambda経由で送信した場合は容量制限、転送時間、それによるコスト増大などの問題がありましたが、2022/12/19発表の AWS 署名バージョン4 (SigV4) 対応により、Amazon S3などAWSの各種サービスに直接データが送信できるようになりました

Amazon Web Service (AWS) に送信する: IAM 認証を利用して Amazon S3 にファイルをアップロードする | SORACOM Beam | ソラコムユーザーサイト - SORACOM Users
IoT デバイスにかかる暗号化や接続先の設定をクラウドにオフロード

Amazon S3などAWSのデータストアに直接送信できるようになり、構成がシンプルできる他コストの低減にも繋がりそうです。またAmazon S3アップロードをトリガーにしてAWS Lambdaを実行することもできるため、各種応用もできるかと思います。

なお他のAWSサービスへの接続の可能性についても今後探っていければと思います。

まとめ

冒頭でお話ししたように、AWSクラウドへの接続方法については今まで断片的な理解でした。

本記事の執筆を機に、AWSクラウドのEdge/IoTサービスとSORACOMプラットフォームの関連性をユースケースを交えて整理できたのは良いきっかけになりました。今後ユースケースに応じてアーキテクチャを検討する際には正しく選択できそうです。

またこうして整理してみると、まだ未経験な部分があぶり出されて触ってみたいという気持ちになりました。
個人的にも今後チャレンジして行ければと思います。

本記事が皆様のお役に立てば幸いです。
ありがとうございました。

コメント