Amazon EventBridge Pipesを利用して、サーバーレスなIoTシステムづくりを体験できるワークショップです。省電力のLTE「LTE-M」を搭載した SORACOM LTE-M Buttonを利用することで、モノやネットワークの準備の手間を少なく始められます。
次に進みます。
SORACOM LTE-M Button はボタン型 IoT デバイスで、用途や機能で3種類のモデルがあります。ここでは共通部分を解説します。
ボタンは押し方に応じて3種類の情報をクラウドに送信できます。通信には省電力のLTE「LTE-M」が使われており、そのSIMは「eSIM」です。通信設定が済んでいる状態ですぐに利用開始できます。電源は交換可能な単4電池2本で、小型で持ち運びも可能です。
IoT デバイス向け フルマネージド・ゲートウェイサービス。IoTデバイスと各AWSサービスの中継を行う。基本的には MQTT ブローカー(サーバー)と HTTP REST API サーバーとして機能し、Amazon API Gateway の IoT 向けともいえる。それ以外にもIoTデバイス監査「AWS IoT Device Defender」や、エッジデバイス管理/ランタイム「AWS IoT Greengrass」を内包しており、AWS における IoT 向けサービスの入口となる。
Amazon Simple Queue Service (SQS)
フルマネージド・メッセージキューサービス。システム間の疎結合・非同期化を実現する際に用いられるパターン「キューによるメッセージング」におけるキュー(Queue)を提供してくれる。メールの送信者・受信者のようなもの。キューはシステム間をつなげるため、高可用かつスケーラビリティが求められ、SQSはそれを従量課金(Pay as you Go)で利用できる。
イベント駆動型 中継サービス「Amazon EventBridge」へ新たに加わった機能。AWS re:Invent 2022 で発表、現時点で利用可能。Amazon EventBridge が元々持つ中継機能に対して、 "バス" を使わずともサービス間をつなげる事ができる。システム間の疎結合・非同期化において、よくあるフィルタリングやトランスフォーム、そして他のサービスへの引き渡しをノー/ローコードで実現する。従来は、例えば SQS → AWS Lambda → 他サービスとしていたアーキテクチャーにおいて、AWS Lambda 関数部分の置き換えができる。
AWS のサービスからのログや、使用中のすべてのシステムやアプリケーションを一元管理できるログサービス。
サーバー(IaaS)の準備無しにコードを実行できる、イベント駆動型コンピューティングサービス。データ変換やAWS内外のサービス連携までこなす、"Glue(糊)" サービス。
データ収集・蓄積「SORACOM Harvest (ハーベスト)」
IoT プラットフォーム「SORACOM」の、IoT デバイス向けデータ収集・蓄積サービス。IoT システム開発初期のIoT デバイスのデータ確認から、本格運用時のロガーとして幅広く利用できる。蓄積データは API で取得可能。
クラウドアダプタ「SORACOM Funnel (ファネル)」
IoT プラットフォーム「SORACO」の、データ転送サービス。 "アダプタ" により、IoT データを対応しているクラウドサービスへ転送する。AWS IoT Core や Amazon Kinesis Data Firehose、Amazon Kinesis Data Streams に対応している。
ビジネスチャットサービス「Slack」上で動くボット。作り方は Appendix をご覧ください。
次に進みます。
本ワークショップを行うためには、以下の準備を行ってください。
以下は、ワークショップ当日までに準備を済ませておいてください。
ワークショップ中でも行うことは可能ですが、時間の考慮はされていないため、時間内に作業を終える事ができない可能性があることにご留意ください。
# | いつまで? | 備考 |
AWS アカウントの作成 | ワークショップ開催日の2日前まで | AWS アカウント作成の流れに沿って作成してください。 作業自体は20分〜30分で完了できますが、アカウント作成直後は一部のリソースが使えない場合があり、ワークショップを進めることができない場合があります。 |
以下は、ワークショップ当日の持ち物です。
# | 備考 |
パソコン | ワークショップテキストを閲覧したり、AWS マネジメントコンソール、SORACOM ユーザーコンソール の操作を行います。
|
AWS アカウント | 事前準備で作成した AWS アカウントです。 |
次に進みます。
作業1では、IoTボタンのデータを SORACOM Harvest Data に蓄積して、そのデータを確認します。
手順は以下の通りです。
次に進みます。
SORACOM のサービスを利用するためには、SORACOMのWeb管理画面「SORACOM ユーザーコンソール」(以下、ユーザーコンソール)へログインします。
「オペレータ ID」「ユーザー名」「パスワード」の3つの情報が揃っているか確認します。
次にSAM ユーザーとしてログインを開き、「オペレータ ID」「ユーザー名」「パスワード」の3つの情報を入力して[ログイン]をクリックします。
ソラコムからの貸し出し用アカウントには、複数のIoTボタン(SIM)が登録されている場合があります。
本ワークショップでは、名前が「Enterprise Button XX (XXは数字)」となっているSIMを利用してください。
次に進みます。
スマート設定機能を利用して、IoTボタンからのデータの蓄積と通知を素早く行います。
ここで「データが見つかりません」と表示されているのは正常です。このリストに、今からIoTボタンを追加するためです。
複数候補があった場合、名前が「Enterprise Button XX (XXは数字)」となっている行にチェックを付けてください。
設定名 | 値 | 備考 |
グループ名 |
| 値は任意(自由に設定可能)です。 後から削除等の管理がしやすい名称が良いでしょう。 |
設定名 | 値 | 備考 |
可視化 | ||
可視化を有効にする | チェックを付ける | ― |
簡易位置測位機能 | ||
位置情報を付与する | チェックを付ける | ― |
メール送信 | ||
メール送信を有効にする | チェックを外す | 標準でチェックが外れているため、確認するだけです。 |
宛先 | (変更しない) | 標準で "空" であるため、確認するだけです。 |
件名 | (変更しない) | ― |
本文 | (変更しない) | ― |
その後表示されるダイアログで[デバイス一覧に戻る]をクリックします。
デバイス一覧の画面で、設定したLTE-Mボタンが表示されていれば成功です。
次に進みます。
IoTボタンを押して、データの蓄積を確認してみましょう。
この時点では、IoTボタンからはデータ未送信であるため「データが見つかりません」と表示されますが正常です。
自動更新をONにしておくことで、新しく蓄積されたIoTデータを自動表示できるようになります。
IoTボタンを押して、データを確認してみましょう。ボタン部分を押下後、最終的に LED が緑色に点灯したらデータ送信成功です。
データが SORACOM Harvest Data に表示されていることが確認できます。
SORACOM Harvest Data では、データをグラフ形式にしたり、位置情報に該当するデータがあれば地図へのマッピングもできます。本ワークショップでは簡易位置測位機能をONにしているため、位置の表示ができます。
※ プライバシーに配慮してボカしていますが、実際ははっきりとした地図で表示されます。
データ内の $metadata.lat
と $metadata.lon
を基にした位置をポイントしています。
以上で、作業1「IoTボタンのデータを、データ収集・蓄積サービス "SORACOM Harvest Data" で確認」を達成しました。
次に進みます。
作業2では、IoTボタンのデータをAmazon CloudWatch Logs へ記録します。AWS IoT Core、Amazon SQS、そしてAmazon EventBridge Pipes を利用することで、サーバーレスで実現します。
手順は以下の通りです。
ここでのゴールは、IoT ボタンでのデータが Amazon CloudWatch Logs に記録できることです。
次に進みます。
キューは、IoT Core と EventBridge Pipes 間のデータ受け渡しに利用します。
作業としては、Amazon SQS でキューを作成します。
ここで指定した値以外は、ページ表示時の設定から変更は不要です。
設定名 | 値 | 備考 |
タイプ | 標準 | ― |
名前 |
| 名前は任意です。 連携先がわかると管理しやすいでしょう。 |
これで、AWS IoT Core と Amazon EventBridge Pipes 間のデータを受け渡しするキューが作成されました。
次に進みます。
Amazon EventBridge Pipes では、 Amazon SQS の着信データを Slack App に連携します。
作業としては、EventBridge Pipes でソースに SQS、ターゲットに CloudWatch Logs を指定します。
"ソース" や "ターゲット" は、"パイプを構築" の当該要素をクリックすることで設定できるようになります。
ここで指定した値以外は、ページ表示時の設定から変更は不要です。
設定名 | 値 | 備考 |
パイプ名 |
| 名前は任意です。 連携先がわかると管理しやすいでしょう。 |
《ソース》 | ||
ソース | SQS | ― |
SQS キュー |
| ― |
《ターゲット》 | ||
ターゲットサービス | CloudWatch ログ | ― |
ロググループ | /aws/events/ | "FromEBPipes1" の部分を入力します。 どこからのデータかわかるようにすると |
それぞれの項目内の設定の様子です。
一覧に、先ほど作成したパイプが表示され、"Status" が "実行中" になっていれば完了です。
Status が実行中でなければ、リロードボタンをクリックして状況を更新してみてください。
メッセージを Amazon SQS に送信して、Amazon EventBridge Pipes 経由で Amazon CloudWatch Logs に記録されるかテストします。
ForEBPipes1
) をクリックします。ここで指定した値以外は、ページ表示時の設定から変更は不要です。
設定名 | 値 | 備考 |
メッセージ本文 |
| 値は任意ですが、JSON 形式を推奨します。 |
「メッセージは送信され、受信可能です。」を表示されれば成功です。
/aws/events/FromEBPipes1
)をクリックします。ToCloudWatchLogs
)をクリックします。メッセージは "body" に入っています。
これで Amazon SQS のキュー(例: ForEBPipes1
)に着信したメッセージは、Amazon EventBridge Pipes を通して CloudWatch Logs に記録されるようになりました。
次に進みます。
IoT デバイス向けゲートウェイサービス「AWS IoT Core」では、IoT デバイスのデータを Amazon SQS キューに流す設定を行います。
作業としては、IoT Core の data/iot_button
トピックへの着信データを、SQS キューへ送信する "ルール" を設定します。
ここで指定した値以外は、ページ表示時の設定から変更は不要です。
設定名 | 値 | 備考 |
ルール名 |
| 名前は任意です。 連携先がわかると管理しやすいでしょう。 |
ここで指定した値以外は、ページ表示時の設定から変更は不要です。
設定名 | 値 | 備考 |
SQL ステートメント |
| ― |
項目内の設定の様子です。
ここで指定した値以外は、ページ表示時の設定から変更は不要です。
設定名 | 値 | 備考 |
《アクション1》 | ||
アクション 1 | Simple Queue Service (SQS) | 一覧から選びます。 |
キュー名 |
| 一覧から選びます。 |
IoTCoreSQSWriter1
` (名前は任意) を入力し、[作成]をクリックします。ここで指定した値以外は、ページ表示時の設定から変更は不要です。
設定名 | 値 | 備考 |
トピック名 |
| ルールで指定したトピック名を指定します。 |
メッセージペイロード |
| 値は任意ですが、JSON 形式を推奨します。 |
※発行のクリックの後は、何も表示されません。何度もクリックしないように気を付けてください。
これで AWS IoT Core の data/iot_button
トピックに着信したメッセージは、Amazon SQS、そしてAmazon EventBridge Pipes を通して CloudWatch Logs に記録されるようになりました。
IoT Core へデータ転送できるサービス「SORACOM Funnel」へ引き渡す情報(デバイスデータエンドポイント)を、この段階でメモしておきます。
メモの対象は以下1つです。外部へ漏洩しないよう扱ってください。
次に進みます。
SORACOM Funnel は、IoTデバイスのデータに認証情報付与やペイロード加工を行いつつ AWS IoT Core へ転送する SORACOMのサービスです。IAM ロール認証に対応しています。
作業としては、まず SORACOM Funnel 用の IAM ロールの作成と権限の付与をして、必要な情報をメモします。
ここで指定した値以外は、ページ表示時の設定から変更は不要です。
設定名 | 値 | 備考 |
信頼されたエンティティタイプ | AWS アカウント | ― |
《AWS アカウント》 | ||
別の AWS アカウント | (選択する) | ― |
アカウント ID |
| "別の AWS アカウント" を選択すると表示されます。 アカウント ID は、この通り入力してください。 |
外部 ID を要求する | (選択する) | ― |
外部 ID | <ランダムな文字列> | "外部 ID を要求する" を選択すると表示されます。 ランダムな文字列は 1password のジェネレーターが |
AWSIoTDataAccess
" ポリシーを探し、チェックを付けてから[次へ]をクリックします。※ "AWSIoTDataAccess" で検索をすると、素早く発見できます。
ここで指定した値以外は、ページ表示時の設定から変更は不要です。
設定名 | 値 | 備考 |
ロール名 |
| 名前は任意です。 どこから使われているのかわかるようにすると 管理しやすいでしょう。 |
SORACOMFunnel_to_IoTCore_Callee1
)をクリックします。※ 検索を利用するとすばやく確認できます。
メモの対象は以下2つです。SORACOM Funnel へ引き渡す認証情報となるため、外部へ漏洩しないよう扱ってください。
外部 ID は、 "信頼関係 > 信頼されたエンティティ" 内の sts:ExternalId
の値です。
次に進みます。
作業としては、IAM ロールの認証情報と、転送先トピック名を SORACOM Funnel に設定します。
ここで指定した値以外は、ページ表示時の設定から変更は不要です。
設定名 | 値 | 備考 |
(スイッチ) | ON | 初期は OFF です。クリックで ON になります |
転送先サービス | AWS IoT | スイッチを ON にすると表示されます。 |
転送先 URL |
| メモしておいた IoT Core のエンドポイントアドレスをお使いください。 設定例は後述の画面をご覧ください。 |
認証情報 | (後述) | 設定方法は後述します。 |
送信データ形式 | JSON | ― |
ここで指定した値以外は、ページ表示時の設定から変更は不要です。
設定名 | 値 | 備考 |
認証情報 ID |
| ID名は任意です。 連携先がわかると管理しやすいでしょう。 ※Calleeに対してCallerとしています |
種別 | AWS IAM ロール認証情報 | ― |
ロール ARN | (メモしておいた ARN を入力) | ― |
外部 ID | (メモしておいた外部 IDを入力) | ― |
最後に、SORACOM Funnel の[保存]をクリックします。
次に進みます。
IoTボタンを押して、データを確認してみましょう。ボタン部分を押下後、最終的に LED が緑色に点灯したらデータ送信成功です。
CloudWatch > ロググループを表示してログを確認します。IoT ボタンのデータが記録されていることが確認できます。
ボタンは「シングル (素早く1回押す)」「ダブル (素早く2回押す)」「ロング (2秒以上長押し)」の3通りの使い分けができます。どのようにログに出力されるか見てみましょう。
次に進みます。
作業3では、IoTボタンのデータをAmazon EventBridge の外部 API 呼び出し機能を利用し、AWS 外のシステムとの連携をサーバーレスで行います。
※ Slack App は運営側で用意しています。
手順は以下の通りです。
次に進みます。
キューは、IoT Core と EventBridge Pipes 間のデータ受け渡しに利用します。
作業としては、Amazon SQS で別システム用としてキューを新規作成します。
ここで指定した値以外は、ページ表示時の設定から変更は不要です。
設定名 | 値 | 備考 |
タイプ | 標準 | ― |
名前 |
| 名前は任意です。 連携先がわかると管理しやすいでしょう。 |
これで、別システム用のキューが作成されました。
次に進みます。
Slack App は HTTP REST API にて呼び出すことができます。Amazon EventBridge の「API の送信先」で Slack の API を呼べるように構成します。
作業としては、「API の送信先」でエンドポイントアドレスやOAuth 認証キー(Bearer トークン)を設定します。
ここで指定した値以外は、ページ表示時の設定から変更は不要です。
設定名 | 値 | 備考 |
名前 |
| 名前は任意です。 連携先や用途がわかると管理しやすいでしょう。 |
API 送信先エンドポイント |
| 固定です。この通りに入力してください。 |
HTTP メソッド | POST | 一覧から選びます。 |
接続 | 新しい接続を作成 | 選択します。 |
接続名 |
| 名前は任意です。 Slack App 名に合わせると管理しやすいでしょう。 |
送信タイプ | その他 | ― |
認証タイプ | API キー | ― |
《API キー》 | ||
API キー名 |
| 固定です。この通りに入力してください。 |
値 |
| 運営から入手してください。入力時は ● で置き換わります。 |
次に進みます。
外部サービスと連携する際には、ペイロード(データの中身)のフォーマットを合わせる必要があります。Amazon EventBridge Pipes では2通りの方法があります。
1つ目は "ターゲット" 内での「ターゲット入力トランスフォーマー」での指定です。ここでは Amazon API Gateway でも使われているテンプレートエンジン "Apache Velocity" に似た書式で変形(リシェイプ)します。2つ目は "強化" から呼び出す AWS サービス内での変換です。AWS Lambda や AWS Step Functions が指定できます。
テンプレートによる方法は、入力データ内にすべての情報が存在しており、リシェイプだけ必要な時に有用です。 "強化" による方式は、変換ロジックを伴ったり、他のサービスを参照したい際に使います。 "強化" とテンプレートは併用できます。
今回は、AWS Lambda 関数を "強化" に使う方法で、Slack の API 用にペイロードを変換します。
[関数の作成]をクリックします。
ここで指定した値以外は、ページ表示時の設定から変更は不要です。
設定名 | 値 | 備考 |
関数名 |
| 名前は任意です。 |
ランタイム | Python 3.9 | ― |
アーキテクチャー | arm64 | 特に理由が無ければ |
ここで指定した値以外は、ページ表示時の設定から変更は不要です。
設定名 | 値 | 備考 |
コードソース | (後述) | 後述の "コードソース" を貼り付けてください。 |
import json
YOUR_NAME = '匿名'
TARGET_CHANNEL_ID_IN_SLACK = 'CC2SXA3TP'
def lambda_handler(event, context):
body = json.loads(event[0]['body'])
click = body['payloads']['clickTypeName']
text = '{}さんが、IoTボタンを{}で押した!'.format(YOUR_NAME, click)
slack_payload = {
'channel': TARGET_CHANNEL_ID_IN_SLACK,
'text': text
}
return slack_payload
YOUR_NAME
の ‘匿名' を、皆さんの名前に変更してください。自分が押したことがわかるようになっていれば問題ありません。#変更前
YOUR_NAME = '匿名'
#変更後
YOUR_NAME = 'ソラコム Max'
ここで指定した値以外は、ページ表示時の設定から変更は不要です。
設定名 | 値 | 備考 |
イベントアクションをテスト | 新しいイベントを作成 | ― |
イベント名 |
| 名前は任意です。 |
イベント JSON | (後述) | 後述の "イベント JSON" を貼り付けてください。 |
[{
"messageId": "510ada74-16dc-49b3-bc17-999999999999",
"receiptHandle": "YWJjZDEyMwo=",
"body": "{\"credentialsId\": \"SORACOMFunnel_to_IoTCore_Caller1\", \"operatorId\": \"OP9999999999\", \"destination\": {\"provider\": \"aws\", \"service\": \"aws-iot\", \"resourceUrl\": \"https://XXXXXXXXXXXX-ats.iot.ap-northeast-1.amazonaws.com/data/iot_button\", \"payloadsOnly\": false, \"sendPayloadsAsBinary\": false}, \"sourceProtocol\": \"udp\", \"payloads\": {\"clickType\": 2, \"clickTypeName\": \"DOUBLE\", \"batteryLevel\": 0.75, \"binaryParserEnabled\": true}, \"timestamp\": 1675743151412, \"imsi\": \"440999999999999\", \"imei\": \"999999999999999\"}",
"attributes": {
"ApproximateReceiveCount": "1",
"SentTimestamp": "1675743152943",
"SenderId": "AROA5XXXXXXXXXXXXXXXX:xxxxxxxx",
"ApproximateFirstReceiveTimestamp": "1675743152951"
},
"messageAttributes": {},
"md5OfBody": "81f86b6059f90e1877cbfaf94b6581be",
"eventSource": "aws:sqs",
"eventSourceARN": "arn:aws:sqs:ap-northeast-1:999999999999:ForEBPipes1",
"awsRegion": "ap-northeast-1"
}]
次に進みます。
Amazon EventBridge Pipes では Amazon SQS の着信データを読み取り、他のサービスへと連携します。ここでは Amazon CloudWatch Logs への記録を記録をします。
"ソース" や "ターゲット" は、"パイプを構築" の当該要素をクリックすることで設定できるようになります。
ここで指定した値以外は、ページ表示時の設定から変更は不要です。
設定名 | 値 | 備考 |
パイプ名 |
| 名前は任意です。 連携先がわかると管理しやすいでしょう。 |
《ソース》 | ||
ソース | SQS | ― |
SQS キュー |
| ― |
《強化》 | ||
サービス | AWS Lambda | ― |
機能 |
| ― |
《ターゲット》 | ||
ターゲットサービス | API 送信先 | ― |
API 送信先 |
| ― |
それぞれの項目内の設定の様子です。
一覧に、先ほど作成したパイプが表示され、"Status" が "実行中" になっていれば完了です。
Status が実行中でなければ、リロードボタンをクリックして状況を更新してみてください。
メッセージを Amazon SQS に送信して、Amazon EventBridge Pipes 経由で Amazon CloudWatch Logs に記録されるかテストします。
ForEBPipesSlack1
) をクリックします。ここで指定した値以外は、ページ表示時の設定から変更は不要です。
設定名 | 値 | 備考 |
メッセージ本文 |
| 固定です。この通りに入力してください。 |
「メッセージは送信され、受信可能です。」を表示されれば成功です。
※もし Slack が見えないようであれば、運営に声をかけてください。
次に進みます。
AWS IoT Coreでは、IoT デバイスのデータを新たに作った Amazon SQS キューへ流します。
作業としては、IoT Core の data/iot_button
トピックへの着信データを、新しく作成した SQS キューへ送信する "ルール" を追加します。
ここで指定した値以外は、ページ表示時の設定から変更は不要です。
設定名 | 値 | 備考 |
ルール名 |
| 名前は任意です。 連携先がわかると管理しやすいでしょう。 |
ここで指定した値以外は、ページ表示時の設定から変更は不要です。
設定名 | 値 | 備考 |
SQL ステートメント |
| ― |
項目内の設定の様子です。
ここで指定した値以外は、ページ表示時の設定から変更は不要です。
設定名 | 値 | 備考 |
《アクション1》 | ||
アクション 1 | Simple Queue Service (SQS) | 一覧から選びます。 |
キュー名 |
| 一覧から選びます。 |
IoTCoreSQSWriter2
` (名前は任意) を入力し、[作成]をクリックします。ここで指定した値以外は、ページ表示時の設定から変更は不要です。
設定名 | 値 | 備考 |
トピック名 |
| ルールで指定したトピック名を指定します。 |
メッセージペイロード |
| 固定です。この通りに入力してください。 |
※発行のクリックの後は、何も表示されません。何度もクリックしないように気を付けてください。
※もし Slack が見えないようであれば、運営に声をかけてください。
次に進みます。
IoTボタンを押して、データを確認してみましょう。ボタン部分を押下後、最終的に LED が緑色に点灯したらデータ送信成功です。
押しわけをしてみてください!
次に進みます。
SQS や EventBridge Pipes といったコンポーネントが入ることで、むしろ複雑さを増しているように見えるかもしれません。一方で、IoT Core から直接 Slack App API にデータ送信する Lambda 関数は、1: データの取り込み、2: ペイロード整形、3: HTTP ヘッダ調整、4: HTTP POST と、3や4の実装が必要です。また、これらのエラー処理や再処理の実装も不可欠となります。
SQS と EventBridge Pipes によって実装を無くしたり、エラー時の処理を任せることができます。すなわち、実装に集中できるメリットがあります。
この利点は "強化" で利用する Lambda 関数のシンプル化にも役立っています。具体的にはペイロードの整形(リシェイプ)の実装に集中できたことで、実装やテストが簡単になるわけです。
SQS によってリトライが行われます。実際の運用時には、エラー発生数のモニタリングが不可欠です。エラーを catch して、アプリケーションレベルでのエラー(最悪、握りつぶす)として扱うこともできますが、要件依存です。
結論、問題ないです。運用要件によります。
IoT Core のルール内には、複数のアクションが指定できます。そこで考えられる戦略は2つあります。
戦略aは、運用中のシステムにルールを後付けしやすい事と、ルール毎のenable/disable(delete)が容易であることがメリットです。例えば、運用後に機械学習側への流れを作る際にも、既存のルールに影響なく追加できます。
戦略bは、「Basic Ingest」という機能によりコスト削減となるのがメリットです。本ワークショップでは、デバイスからは data/iot_button
トピックにデータ送信をしました。送信先トピックを $aws/rules/ToSQS1
にすることで、IoT Coreの ToSQS1 ルールに直接流し込めるようになり、Basic Injest が適用されて費用が下がるわけです。送信先のトピックは1つしか指定できませんので、1つのルールに複数のアクションをまとめることになります。(もちろん、トピックを $aws/rules/~ にしないとBasic Injest は適用されません)
戦略aは成長中のシステム、戦略bはコスト削減向けと言えるでしょう。フェーズによって異なるという答えになります。もちろん移行することもできます。
手順の簡便化をするため、 TARGET_CHANNEL_ID_IN_SLACK
をコード内で直接指定しました。実際の利用では、このような情報は環境変数や AWS Secrets Manager(Parameter Store)を利用した指定が、セキュアかつポータビリティーの高いコードになります。
同様に YOUR_NAME
も直接指定していますが、ここも Amazon DynamoDB 等からfetchした値を利用する実装が考えられます。これにより、例えば IMSI のようなハードウェア側のユニークな ID を基に、アプリケーション上で利用する ID へのマッピングを "強化" 上で行えます。これこそが "強化" の本来の目的と言えるでしょう。
多くのリソースが自動生成されているため、確実に削除しておきましょう。
※アカウントはソラコムからの貸出であるため、ソラコム側で設定消去を行います。自身のアカウントで行う方向けの情報です。
ボタンワークショップ
SORACOMFunnel_to_IoTCore_Caller1
ToSQS1
ToSQS2
ToCloudWatchLogs
ToSlackApp1
Slack-iotbutton-handson1
SlackApp-CatchAllBot1
ebp-enrichment-payload-reshaper-for-slackapp
ForEBPipes1
ForEBPipesSlack1
/aws/events/FromEBPipes1
/aws/lambda/ebp-enrichment-payload-reshaper-for-slackapp
SqsPipeSourceTemplate-**
と LogsPipeTargetTemplate-**
Amazon_EventBridge_Pipe_ToCloudWatchLogs_**
SqsPipeSourceTemplate-**
と LambdaPipeTargetTemplate-**
と ApiDestinationPipeTargetTemplate-**
Amazon_EventBridge_Pipe_ToSlackApp1_**
aws-iot-rule-ToSQS1-action-1-role-IoTCoreSQSWriter1
IoTCoreSQSWriter1
aws-iot-rule-ToSQS2-action-1-role-IoTCoreSQSWriter2
IoTCoreSQSWriter2
AWSLambdaBasicExecutionRole-**
ebp-enrichment-payload-reshaper-for-slackapp-role-**
SORACOMFunnel_to_IoTCore_Callee1
Slack App を作り、OAuth スコープで権限を設定する。OAuth トークンを入手し、Slack 上でポスト対象となるチャンネル ID を入手すれば、後は API でコールできる。
curl -X POST -H "Authorization: Bearer xoxb-XXXXXXX" -H "Content-type: application/json" -d '{
"channel":"<ChannelID>", "text":"Hello, there!!"}' https://slack.com/api/chat.postMessage
IoT ボタンや SORACOM アカウントが無くとも、Amazon EventBridge Pipes 自体の体験は可能です。
SORACOM ユーザーコンソールへのログイン以外は、同じ手順で行えます。
リソースの削除は、AWS に加えて SORACOM 側も行ってください。削除対象は「かたづけ」の章をご覧ください。
SORACOM LTE-M Button powered by AWS は、AWS IoT 1-Click 経由で AWS サービス連携をします。
LTE-M 通信には SORACOM を使っていますが、それ以外の連携サービスは利用しておらず、直接 IoT 1-Click へデータが送信されます。
IoT 1-Click からは Lambda 関数を呼び出せるため、以下のようなアーキテクチャーとなります。
引き渡し用の Lambda 関数のサンプルは、以下の通りです。
import os
SQS_QUEUE_NAME = os.environ['SQS_QUEUE_NAME']
import boto3
sqs = boto3.resource('sqs')
queue = sqs.get_queue_by_name(QueueName=SQS_QUEUE_NAME)
import json
def lambda_handler(event, context):
payload = {'iot_1click_event': event}
response = queue.send_message(MessageBody=json.dumps(payload))
return response
本コンテンツは現状のままで提供され、株式会社ソラコムは、誤りがないことの保証を含め、明示であると黙示であるとを問わず、本コンテンツの記載内容につき、いかなる種類の表明も保証も行いません。
掲載情報の閲覧及び利用により、利用者自身、もしくは第三者が被った損害に対して、直接的、間接的を問わず、株式会社ソラコムは責任を負いかねます。
本コンテンツを実践する中で用意された機器、利用されたサービスについてのご質問は、それぞれの機器やサービスの提供元にお問い合わせをお願いします。機器やサービスの仕様は、本コンテンツ作成当時のものです。
株式会社ソラコムが提供する機器・サービスについてのご質問は、 https://soracom.jp/contact/ をご確認の上、適切な窓口へのお問い合わせをお願いします。機器・サービスご利用前の導入相談は https://soracom.jp/contact/contactsales/ に、機器・サービスご利用開始後のサポートは、SORACOMユーザーコンソール内のサポートサイトから「リクエストを送信」(要ログイン)にてお問い合わせください。
Copyright (c) 2023 SORACOM, INC.
Twitter: @ma2shita までご連絡を!
担当 | 項目 | 備考 |
運営 | ネットワーク環境 | Web アクセスができれば OK |
運営 | 電源 | 人数分の口 |
ソラコム | 貸し出し用 SORACOM LTE-M Button for Enterprise | 出荷しておく アカウント情報を、参加者用の表にまとめる |
ソラコム | 貸し出し用 SORACOM アカウント | 初期化をしておく アカウント情報を、参加者用の表にまとめる |
ソラコム | Slack App | tokenの再生成をしておく API情報を、参加者用の表にまとめる |
ソラコム | 参加者用の表 | ― |
EoT