こんにちは、AWS Heroのソラコム 松下(ニックネーム: Max)です。
このブログでは、AWSの年次カンファレンス「AWS re:Invent 2022」(以下、re:Invent)の新サービスや発表の中から、特にIoTの活用やシステム開発で役立つ内容を紹介します。
re:Invent では多くのアップデートが発表されていますが、IoT 関連の新機能も出ています。ここではIoTのエンジニアや開発者の方に向けて、アップデートをご紹介します。re:Invent 全体やIoT周辺の情報については “AWS re:Invent 2022のキーノートやセッションで知る「IoTの今」” で紹介しています。こちらも併せてお読みください。
AWS IoT シリーズの新発表・新機能
AWSには「AWS IoT」で始まる、IoT 向けサービスが数多くあり、ひとまとめに AWS IoT シリーズ(ファミリー)と呼んだりします。ここでは、AWS IoT シリーズの新発表や新機能を紹介します。
- AWS IoT Core / デバイスロケーション
- GPSが無いデバイスでも位置測位ができます。データソースにはWi-Fi アクセスポイントのMACアドレス、セルラー基地局、IP アドレスそしてGNSS が使えます。データソースと位置情報のマッピングデータベースは3rd Partyからの提供です。(当該ブログ)
- AWS IoT Core / MQTTv5 対応
- データにセットする「プロパティ」による、メタ情報のやり取りが便利で実装に役立ちます。例えば “Content Type” といった情報が指定できます。このプロパティは MQTT クライアント間(Pub/Sub)でやり取りできる他、IoT Core のルール内でも参照可能です。(当該ブログ)
- AWS IoT Device Management / Job スケジューリング
- ジョブドキュメント(JSONファイル)の配布スケジュールを時間枠で指定できるようになりました。例えば「当該リージョンの夜間で、ソフトウェア更新ジョブを実行」といった指示ができ、利用状況に合わせたりアクセス分散も目的とした時間指定が容易になります。(当該ブログ)
- AWS IoT TwinMaker / アセット同期元に AWS IoT SiteWise が利用可能
- デジタルツイン可視化サービス「AWS IoT TwinMaker」内のアセット (現実の機器をデジタル上に表現する時の情報)の同期元情報に、IoTデータ収集・可視化サービス「AWS IoT SiteWise」に蓄積されたデータを指定できるようになりました。(当該ブログ)
- AWS IoT Device Defender / MQTT トピックのワイルドカード指定の監査
- MQTT トピック指定でワイルドカード (# や +) が含まれている可能性を監査対象にできます。ワイルドカードは便利ではありますが、不要なトピックのsubscribeは、思わぬ事故につながる可能性があります。ポカよけとしてこういった監査は便利です。(当該ブログ)
IoT システム開発で役立ちそうな新発表・新機能
AWS IoT シリーズでは無いのですが、IoT システム開発に役立つ新発表や新機能を紹介します。
- Amazon EventBridge Pipes
- AWSや外部サービス間をつなげるサービス「Amazon EventBridge」の新機能です。データの入力・フィルタ・加工・出力を “パイプ” のようにつなげられます。例えば AWS IoT Core から Amazon SQS を経由して、Amazon EventBridge Pipes で処理することができ、サーバレス・ローコードなデータ処理を構築できます。(当該ブログ)
即戦力となる３つの機能を解説
IoTのシステム開発や実装で即戦力になりそうな３つの機能「デバイスロケーション機能」「MQTTv5 対応」「Amazon EventBridge Pipes」を解説します。
AWS IoT Core / デバイスロケーション機能
IoTデバイスの位置測位が行えます。位置測位といえばGPS(GNSS)ですが、GPSが無くともIoTデバイスが利用しているネットワーク情報を基に位置を割り出してくれます。具体的には Wi-Fi(アクセスポイントのMACアドレス)、セルラー、IP アドレス、そしてGNSSがデータソースとして使えます。
AWS マネジメントコンソールから試すことができます。以下は、作業場(静岡県)のルーターのグローバルIPアドレスを基に位置を割り出した例です。
データベース自体はSemtech社やHERE社といったサードパーティーからの提供ですが、インターフェース(入力受付)はAWSであるため、どの情報をどのDBで解決するのか？といった事を、呼び出し側は考える必要が無いというのが利点です (そのため、GNSSも受け入れられるようになってると思われます)。
私が試した限り、 IP アドレスとセルラーについては、かなり精度よく位置情報を検出してくれました。
GPS非搭載デバイスでの位置測位が可能となるため、例えばIoTデバイスの設置位置がお客様からの申請と一致しているか？といったフィールドエンジニア向けのアプリケーション作りに役立ちそうです。位置情報の組み合わせ先には Amazon Location Service が挙げられます。ソラコムの桶谷(ニックネーム: takuya)が検証したブログでは実際の手順と共に紹介されています。AWSのリリースブログと併せてご覧ください。
位置情報の解決には3rd partyのデータベース(AWS外もありうる)へ位置情報が転送されると規約に明記されているので、位置情報の解決で気を付けるポイントとして覚えておいていただければと思います。
AWS IoT Core / MQTTv5 対応
軽量であることからIoTデバイスの通信のプロトコルにも使われることの多い MQTT は、複数のバージョンが存在します。この度、AWS IoT Core の MQTT サーバー(ブローカー)が MQTT の Version 5 (以下、MQTTv5) に対応しました。これまでの Version 3.1.1 も利用できます。
MQTTv5の機能で実装面で役立つのが「プロパティ」で、制御用の情報を設定できます。プロパティの種類を見てみると `Content Type` が指定できたりするので、HTTPのヘッダのような位置づけと考えてもよさそうです。またユーザー独自のプロパティも設定できます。このプロパティはsubscriber側はもちろん、AWS IoT Coreのルール内でも get_mqtt_property() や get_user_property() にて参照できます (AWS ブログ内の “Processing MQTT packets with user properties on AWS IoT Core topic rules” が該当する詳細解説です)。
例えば「Response Topic」プロパティには、データ送信時(publish)に返却先トピックを設定できます。受信側(subscriber)はメッセージ受信時に、データとは別に Reponse Topic プロパティが参照できるので、処理結果を返す(送信する)先のトピックを教えてもらえます。ちなみに、実際に使うかは任意です。
こういった処理はデータ内に _header: {...} のようなメタ項目を作っていたので、データ部の実装の簡素化が期待できる機能です (AWS ブログ内の “Request/Response pattern” が該当する詳細解説です)。
具体的な動作については「MQTTv5のプロパティ(property)を、mosquittoとAWS IoT Coreで使う」というブログで紹介しています。また、その他 Request/Response パターン、Message や Session の有効期限などMQTTv5 対応になってできるようになったことは AWS ブログをご覧ください。
Amazon EventBridge Pipes
Amazon EventBridgeは、AWSのサービスや外部のSaaSサービスをサーバーレス・ローコードでつなげるサービスです。その新機能として「Amazon EventBridge Pipes」が発表されました。データを「入力・フィルタ・加工・出力」と、一連の “パイプ” のようにつなげて、サービス間を接続します。
以下の図のように、ソース(入力)から入ってきたデータをフィルタリング、強化(加工)、ターゲット(出力)を指定したり(図の上段)、シンプルにソースとターゲットのみとする構成(図の下段)もできます。
ソースは色々な種類が選べ、その中にはキューサービス「Amazon Simple Queue Service」(Amazon SQS) があります。AWS IoT Core は Amazon SQS に転送できるため、IoT デバイスのデータを Amazon SQS を経由して、Amazon EventBridge Pipes で処理することができ、サーバレス・ローコードなデータ処理を構築できます。
SORACOM サービスとの組み合わせ
SORACOM には AWS サービスと連携できるサービスや IoT デバイスがあります。
ソラコムの IoT ボタン「SORACOM LTE-M Button シリーズ」ならば、AWS IoT 1-Click や、クラウドアダプターサービス「SORACOM Funnel」を経由してAmazon EventBridge Pipes につなげられます。これまでは AWS Lambda の関数内で他のAWS サービスや SaaS 等の REST API とつなげていた部分が、 EventBridge Pipesによってローコード化できるわけです。
SORACOM LTE-M Button powered by AWS の場合は、IoT 1-Clickの後に AWS Lambda 関数が挟まることになりますが、従来はこの関数で他のAWSサービスやSaaSのAPIを呼び出すコードを書いていました。上記の構成であれば、AWS Lambda 関数の実装は「Amazon SQSへの送信」に一本化できるため、シンプルなアーキテクチャづくりに役立ちます。
おわりに ― サーバレス・ローコード化が進む IoT
AWS re:Invent 2022 で発表された新発表・新機能の中から IoT に関連するアップデートを解説してきました。既存サービスの強化が中心となりましたが、役立つ機能ばかりです。
近年AWSでは、AWSクラウドを使ってシステムを作る開発者を「Builder」と呼んでいます。数あるサービスを組み合わせて、自らの課題を解決する仕組みを「構築」する様子から、そう呼んでいるのだと思います。その根底には「 (Builderが) 本当にやりたいことに集中する環境を提供する」ことにAWSが集中しており、その方法論としてサーバレスやローコード／ノーコードなサービスが充実しているのだと感じています。
IoTは、クラウドだけでなくデバイスや通信も揃える必要があることから、開発時間が長くなりがちです。一方で、データを蓄積して活用してこそ “役立つ IoT” が産まれます。データ蓄積開始までの時間を短くする、すなわち開発時間の削減は IoT 開発で不可欠です。この削減に役立つのがサーバレスやローコードだと考えています。
今回ご紹介した機能のみならず、AWSが提供するサービスを見てみることで、皆さんが普段から「面倒だな…」と感じていることが解消するかもしれません。ほとんどのサービスが少額で試すことができますので、気になるサービスがあれば是非活用してみてください。
― ソラコム松下 (ニックネーム: Max)