投稿日

IoT のデータ処理をサーバーレスで実現するには? ― IoT-Tech Meetup レポート

こんにちは、ソラコムの松下(ニックネーム: Max)と小梁川(Koya)です。

10/24に開催したIoTの勉強会「IoT-Tech Meetup」では、IoT のデータ処理 ― IoT バックエンド作りにサーバーレス・アーキテクチャを用いる方法を紹介しました。

なぜ今、サーバーレスなのか?IoTとの関係は?具体的なアーキテクチャや使えるサービスは何か?これらについて、公開資料とともに要点を皆さんにレポートとしてご紹介します。

IoT-Tech Meetupとは?

「IoT-Tech Meetup」は、ソラコムが持つIoTや周辺技術の知見を、主にエンジニアの方に共有する事を目的としてシリーズ開催する無料のオンライン勉強会です。プレゼンテーションの他にQAもあり、学びを深めていきます。

テーマは多岐に渡っており、Raspberry Pi(ラズパイ)やM5Stack、クラウド型カメラといったハードウェアから、サーバーレスIoTやAIといったクラウド・ソフトウェア、そしてMatter等のIoT向け規格、法規やオープンソースライセンスといったあらゆる面で、IoTを活用するエンジニアの方に役立つ内容を企画・定期開催しています。

【セッション1】サーバーを構築しない「サーバーレス」 ― なぜ今、サーバーレスなのか?IoTとの関係は?

冒頭はMaxより、IoTとサーバーレスの関係性やメリットを紹介しました。

IoT は使い方や利用者の数が変化しがちです。それに対し、費用の最適化や変化への対応ができるというのが、サーバーレスのポイントです。

所有から利用、作るから創るという思考を変えてチャレンジの速度を上げることの観点、使い方によっては十分なコストメリットが出るという点でサーバーレスとIoTの相性の良さについて解説させていただきました。

また、サーバの設定や非機能要件の実装など、サービスの価値に直結しないコストが発生します。必要なバックエンドをすぐに使えて、運用も楽でサーバーレスを検討してみようという意図になります。

相性がよいという一方で 銀の弾丸では無いという点もお話させていただきました。定常的なワークロードが続くようなユースケースに置いては、サーバーレスのほうが不利というケースもあるので用途については十分にご検討をいただければと思います。

資料は以下で公開しています。

【セッション2】サーバーレスで始めるIoTデータパイプラインとファンアウトのアーキテクチャー

続いてのセッションはKoyaから「データパイプラインとファンアウト」というアーキテクチャの観点を紹介しました。

サーバーレス、データパイプラインという単語は主語が大きく、様々な視点が存在します。ここではサーバーレスはマネージドサービスでサーバの概念を含まないもの、データパイプラインもいわゆるビッグデータの流れのデータパイプラインではなく、IoTデータ収集を中心にしてのお話をさせていただきました。

データ収集する上で最初にプロトコルを選択する重要性について説明しました。これは一度選択したプロトコルをかえるにはデバイス側の多大な変更が発生するためで、プロトコル選択は最初の重大な判断となります。

データ受信後のファンアウトアーキテクチャとして1つのメッセージ受信をAWS IoT Coreのルールエンジンを使って多数のサービスへ簡単に分解できることを解説しました。ルールエンジンという “設定” だけで、皆さんはコードを一行も書くことなく届けたい複数のサービスへメッセージを送ることができます。

この構成のなかでは、Amazon OpenSearch Service(以下、OpenSearch)が唯一のインスタンスを持つサービスとなります。OpenSearchはダッシュボードを提供するサービスとなり、定常的に画面にグラフを書くために内蔵ディスクに常にクエリがかかるような運用となるためにインスタンスを持つ方が安いということが起きやすいためです。

また、ファンアウトという観点ではメッセージファンアウトという概念があることもお話させていただきました。AWSさんのたまごっちの事例(大規模台数のたまごっちへ AWS IoT Jobs で高速かつ高効率にファームウェアを配信する方法)を簡単に解説しました。

最後に、今はアンチパターンとなっているものも将来的には解決することがあるということで継続的な情報収集についても触れました。

資料は以下で公開しています。

【セッション3】デモで学ぼう ― サーバーレスで作るIoT ファンアウト・パターンの実装

最後のセッションはMaxからAWS IoT Coreのルールエンジンを活用した受信メッセージを実際に複数のサービスへファンアウトしていくライブデモを見ていただきました。

デバイス側の実装を変更することは大変な労力を伴います。仕様変更対応などの変更対応や認証情報の設定があり、とくにIoTデバイスは多数になることが多くデバイス固有の認証を生成、埋め込みを推奨されているケースがあります。そういったケースにソラコムのサービスをうまく活用いただくことで皆様の開発の手間が省ける可能性があります。ということでソラコムのサービスについてもご紹介させていただきました。

資料は以下で公開しています。

Q&A セッション

イベント当日は、Zoom ウェビナーのQ&Aにて参加者からのご質問にお答えしました。

Q: IoTデバイスからHTTPでDB情報をGETなどする場合もAWS IoTを使えるのでしょうか?

A: AWS IoT Core は HTTPS(HTTP over TLS)による REST API をサポートしており、希望に沿った構成が可能です。一方で、単純に HTTP(S) GET で情報を得るようなシンプルなアーキテクチャならば、Amazon API GatewayAWS Lambda の関数 URL 機能も検討できるでしょう。

Q: 仮想サーバーとサーバーレスの費用比較について、もう少し詳しく教えてください。

セッション内では駆け足の紹介となってしまったため、改めて解説します。費用を算出する前提条件としては「10台の IoT デバイスから、1時間に1回、1回あたり1KBのデータが送信される」を設定しました。この考え方は、IoTにおけるデータ量や頻度の目安になります。

続いて処理するクラウド側ですが、仮想サーバーはCPUやメモリが設定できるのですが、サーバーレス側で設定できるのが唯一 AWS Lambda への割り当てメモリであるため、ここだけ同条件(512MB)にしています。この上で、仮想サーバーを1か月起動し続けた金額と、サーバーレスにおいての処理量で金額を見積したのが以下の URL です(資料内に掲載している URL になります)。

※見積ページには1カ月当たり以外にも、年間(12カ月)のコストも表示されているので注視してください。

以下は、アンケートにお寄せいただいたコメントです。こちらにもお答えいたします!

コメント: プロトコルの選択についてもっと聞きたかった

A: IoT で使えるプロトコルは多く、また範囲が広いので今回は細かく説明できず恐縮です。デバイスからのメッセージ送信観点での選択については、以下の観点でご相談いただくのが良いと思います。

  • デバイスは常時電源がとれるのか、バッテリー駆動なのか。
  • 通信はソラコムのようなSIM通信(従量課金型)なのか、優先やWiFiのように無制限で使えるものか。

これらは、コストやデバイス駆動時間に大きなインパクトがあります。また、今回のセッションで説明したようにCloud To Deviceの通知のリアルタイム性のような要件以外にも選択基準が存在するため、まずこの2つを意識いただきつつ、ソラコムにご相談いただければと思います。

コメント: MQTTをつかうのに、会社のFirewallのポートが空いてないことがありませんか

A: AWS IoT Core については、MQTTをport 443で使えるという機能がリリースされております。また外部からネットワークが調達可能であればソラコムのSIM経由で送っていただくなどの手段も考えられます。

次回のIoT-Tech Meetupは12/7(木)「AWS re:Invent 2023 / IoT 振り返り」

次回の IoT-Tech Meetup は「AWS re:Invent 2023 / IoT 振り返り」です。

11月末から開催の AWS(Amazon Web Services、以下 AWS)のグローバルイベント「AWS re:Invent」では、AWS の新発表や最新事例の共有、そして学びを深めるコンテンツが展開されます。私(ソラコム松下)も現地で参加するため、AWS re:Invent 2023 における展示や新発表の中から、IoT に関連しそうなトピックをピックアップして解説します。また、AWS re:Invent 自体についても、現地からのレポートを交えてご紹介します。

すでにお申し込みページはオープンしています。お気軽にご参加ください。
オンラインでお会いしましょう!

― ソラコム 松下 (Max)、小梁川 (Koya)