MUDAなことをしよう。MUDAなことをしよう。Lambdaを連携させてみます。やりたいことのイメージこんな感じで、M5StickCからMQTTで送った情報をLambdaで処理し、その処理結果をM5StickCに返します。Lambdaの処理内容については今回は特に追求しないため、適当に値を2倍にして返す、ぐらいにしておこうと思います。IoTのMQTT双方向通信)を実施した上で以下をご参照頂きますよう、宜しくお願い致します。作業するIAMユーザ(あるいは、ユーザの所属するグループ)のポリシーですが、まず前提として以下のポリシーが設定されているものとします。AWSLambdaFullAccessCloudWatchFullAccessAWSIoTFullAccess前回時点のものから、AWSLambdaFullAccessを追加した形になります。例によって、FullAccessで良いのかという気がしますが、現時点ではこれでご了承ください。これで少なくともAWSコンソール上で作業ユーザがLambdaをなんやかんやすることができるようになりますが、これだけだとちょっと困ります。IoTの管理するMQTTのトピックにアクセス(Publish)する必要があります。IoTのトピックにPublishする許可を与えてあげる必要があります。これを実現するのがIAMの『ロール』という仕組みなわけですが、上記のポリシーだと、Lambda関数を作成しようとしても、このロールの付与ができません。ロールの付与はあくまでIAMの機能なので、IAMに対するポリシーを何も設定していない状態では、設定できないのは当然といえば当然です。諸々の許可を管理するIAMのFullAccessを作業用ユーザに対して付与するのは流石にいかがなものかと思います。いうことで、作業用ユーザに対して、IAMの『ロールの付与』という権限だけを付与してあげるようにします。以下の手順は、このあたりを参考にさせて頂きました。サービスにロールを渡すアクセス許可をユーザーに許可するまず、管理者ユーザでIAMの管理画面から「ポリシー」の設定に入ります。ポリシーを新規に作成します。ビジュアルエディタで設定しても良いですが、今回はコピペで済むようにJSONで設定します。JSONの入力画面になったら、以下をコピペして「ポリシーの確認」に進みます。]}名前は適当に、例えば”AllowPassRole”などにして、ポリシーの作成を完了させます。その後、作成したポリシーを作業用のユーザ(グループ)にアタッチしてください。これで、少なくとも作業用ユーザは『(Lambda含む)任意のリソースに対してロールを付与する』という行為だけは許可されることになりました。許可したのはロールの『付与』だけで、ロールの『作成』を許可したわけではありません。作成まで許可してしまうと、結構強い権限になってしまう気がしますので。いうことで、管理者ユーザのまま、今回使用するロールを作成していきます。ちなみに、「どうせ自分一人でやってることだし、いちいちロールを作るのに管理者ユーザに切り替えるのは面倒だ!」という方は、PassRoleだけではなくCreateRoleの権限まで作業用ユーザ(グループ)に付与すれば可能だとは思いますが、少なくとも私はやっていないので、正確なところはわかりません。それでは、今回使用するLambda用のロールを作成していきます。後段で出てくる話の先出しになってしまいますが、Lambda関数に付与するロールには「CloudWatchにログを送信する権限」が付与されていることを求められます。これを具体的に書き記したものが、AWSで初めから定義されている”AWSLambdaBasicExecutionRole”で、その内容は以下になります。IoTのMQTTトピックに対するPubishする権限)を追加します。先ほどと同様に新規のポリシー作成画面に入り、JSONで以下のように設定してください。]}今回はかなり対象(リソース)を絞っています。名前は適当に”AllowIoTPubForLambda”とかにして、ポリシーの作成を完了させます。ここで設定したポリシーを、ロールに対して紐付けます。「ロール」から「ロールの作成」に入ります。エンティティの種類を「AWSサービス」として、ロールを使用するサービスとしてLambdaを選択して次に進みます。先で作成したポリシー(”AllowIoTPubForLambda”)を選択して次に進みます。タブは将来的に開発規模が大きくなれば設定した方が良いのかと思いますが、今回は設定なしで進みます。名前は適当に”AWSLambdaExecutionWithIoTPub”などとして、ロールの作成を完了させます。ここまで済んだら、作用業ユーザでログインし直して、以下の作業に進みます。Lambda方向のロール作成はいらんの?」と思った方もおられるかもしれません。Lambdaのアクセス権限付与は勝手にやってくれるようです。このあたりの詳細は、すみません、よくわかっていませんが、とりあえず気にせず先に進みます。IoTと連携させるLambda関数を先に作っておきます。形だけ先に作ることにして、Lambdaのソースコードはまた後から書き直します。Lambdaの管理画面の「関数」から、「関数の作成」に進みます。「一から作成」を選択して、例えば以下のように設定します。AWSLambdaExecutionWithIoTPub大事なのは、言わずもがな「アクセス権限」です。ここで、先ほど管理者用ユーザで作成したロールを選択します。IoTと連携するよう設定します。Coreの管理画面に入り、「ACT」の「ルールの作成」に進みます。ルールの名前はとりあえずmyM5StickCRuleとかにします。‘myTopic/fromDevice’こんな感じで、Lambda関数の起動のトリガーとなるトピック名をFROM以下に指定するようにします。続いて「1つ以上のアクションを設定する」の方の「アクションの追加」に進みます。その下のエラーアクションも本当なら何か設定した方がよいのかもしれませんが、ここはいつか理解が深まったら設定することにして先に進みます。アクションの選択画面になるので、「メッセージデータを渡すLambda関数を呼び出す」を選択して「アクションの設定」に進みます。関数名の選択画面になるので、先ほど作成した関数”respond_to_IoT_message”を選択して「アクションの追加」に進みます。ルールの作成画面に戻ってくるので、必要であればタグを設定して、先に進みます。ルールが正常に作成されたら、もう一度Lambdaの管理画面に戻り、関数”respond_to_IoT_message”の設定画面を開きます。IoTが紐づけられていることがわかります。IoTへメッセージをPublishするためのソースコードを作成します。開発規模が大きくなってきたら、「コードエントリタイプ」で「.zipファイルをアップロード」とする形でソースを作成した方がよいのでしょうが、今回はイベントをキャッチしてメッセージをPublishするだけの短いコードですので、「コードをインラインで編集」で、そのままコンソール上でソースコードを編集してしまいます。今回作成する内容は以下になります。"Failed."以下、Lambdaを使いこなしている方々からすれば当然のことなのでしょうが、自分は使用するのが今回が初めてでしたので、自分用のメモになります。boto3は、AWSをPythonから操作するための公式ライブラリ。Logsでprintの出力内容を確認できる。boto3.client()で、使いたいAWSサービスのオブジェクトを取得できる。Planeオブジェクトの詳細はこちらを参照。lambda_handlerのevent引数(通常はdictタイプ)から、呼び出し元から送られたデータを参照できる。contextの詳細についてはこちらを参照。上記のソースコードを作成したら、「保存」で完了です。設定画面には他にも色々入力項目がありますが、今回はそこはスルーです。必要に応じて、今後利用するようにします。作成したLambda関数が意図通り動作しているかをチェックするために、ここでテストを実施しても良いと思います。Lambda関数の管理画面右上から、以下のような感じでテストイベントを作成します。その後、Lambda関数の管理画面右上から「テスト」を実行して、実行結果で特にエラーを吐くことなく成功していればOKです。以上で、AWS側の作業はおしまいです。今回はデバイス側の作業は特にありません。前回作成して書き込んだソースコードをそのまま使用できます。動作確認それでは、動作確認していきます。AWS.”とディスプレイに表示されてからAボタン(M5ボタン)を押します。押すたびに”TX”の数字がカウントアップされていきますが、僅かのディレイの後、”RX”の値が”TX”の2倍の値になって表示されればOKです。確かにLambdaで処理された値が返ってきています。最後に、M5StickC側の動作検証の様子を動画で載せておきます。https://make-muda.net/wp-content/uploads/2020/01/IMG_3248.mp4最初だけ”TX”が表示されてから”RX”の表示に少し間があるのは、おそらく最初のLambda呼び出しだけコールドスタートになっているからですね。IoTに対して送ったデータをLambdaで処理して送り返してもらう、というところまでやってみました。今回は単純に値を2倍にして返しているだけですが、その気になれば、例えばLambda上でscikit-learnを使用して機械学習の予測モデルを適用した結果を返してもらうということも可能になるわけで、クラウドのコンピューティングパワーを活用するための準備がこれで整ったことになります。いっても、「じゃあそれで何すんねん」というところがまだ特に決まっているわけでもないので、まだまだお勉強フェーズは続きます。前回、今回とデバイス側がトリガーになって処理が始まるようになっていたので、次回はCloudWatchなど使ってみて、クラウド側がトリガーになってデバイス側にメッセージを送るパターンを試してみようかなと思っています。相変わらず予定は未定です。(1セット)以下は自分が勉強用にパラパラと読んでいる本です。広範囲に渡るAWSサービスの概要を知るのに丁度良い感じがしています。コメントをキャンセルメールアドレスが公開されることはありません。hidaka_hirojiAmazonほしいものリストこちら自身の工作用に使いたいものがメインですが、必ずしも工作に使うわけではないのでご了承ください。MUDAなことをしよう。