先日、遂にSORACOMのAWS IoT 1-Click 対応ボタンの販売受付が開始された。
ので、さっそく注文した。
届くまでには少し間があるそうなので、その間にどう使うのかを少し考えておきたいと思う。
AWS IoT 1-Click そして SORACOM LTE-M Button とは？
AWS IoT 1-Click は端的に言うとAmazon Dash Buttonの様なものを作れるAWSのマネージドサービスだ。
対応しているデバイスの物理ボタンを押すと、任意のLambda関数を実行することができる。これだけ。
その対応デバイスのうち SORACOM LTE-M Button で得られる価値は『いつでもどこでもボタンを押せばLambdaが動く』である。
このボタンは文字通りauのLTE網をつかったLPWA対応のボタンで、既存のダッシュボタンなどと違ってWi-Fi接続などを必要とせず、単体で動作する夢のボタンなのだ。
何ボタンを作るか？
『草を生やすボタン』を作りたい。
いつでも、どこでも、ボタンを押せば草が生える。
すばらしいじゃないか。
どう作るのか？
どのように『草を生やすボタン』を作るのか？ 色んなパターンがある。
最小構成
AWS Consoleからボタンを登録し、そのボタンで起動するLambdaも同様にAWS Consoleから作成すればよい。
とても簡単で、おそらく1時間もかからずに『ボタンを押したら草が生える』という価値を得られるだろう。
正直これでいいんじゃないか？ と思う。
少し AWS IoT 1-Click の機能を使う
AWSのマネージドサービスはよく考えられていて、1-Clickであれば起動するLambda関数が何を必要とするのか？ を踏まえた機能が提供されている。
1-Clickプロジェクトとしてのデバイス群の管理や、ボタンに任意の属性を持たせることができるプレイスメントという概念、機能が提供されている。
これを使用すると、ボタンが押された際に動作するLambda関数内でそのボタンが属するプレイスメントが持つ属性を引数として参照できる。
AWS IoT Coreの上で同じようなことをしようとしたら、クリックされたデバイスのIDに対応するメタデータを取得（それがモノの属性なのか、DynamoDBに入っているのか知らないが）し、そのデータに応じた動作を行うような形になるだろう。これをKinesis Data Firehoseを使ってストリーム処理するのではなかろうか。
こんな感じになる。これをいい感じに提供してくれているのが1-Clickなのだから、その機能を使わない手はない。
Pixelaではボタンとグラフが関連付けされればよいので、草ボタンプレイスメントテンプレートはユーザーネームとグラフIDを属性として持てばよいだろう。
Pixelaのグラフをプレイスメントと見立てる形である。こうすれば、あるグラフに対して草を生やせるボタンを複数設けたい場合も自然に処理できる。
個人的な感想だけれど、このプレイスメントという言葉の選択は、定点設置を連想させてあまり好きではない。 SORACOM LTE-M Button は移動体となって本領発揮だからね！
継続的なインテグレーションやデリバリーを考える
Lambda関数はAWSコンソールから作成すると、いわゆるコードリポジトリでのコード管理はできない。
正直趣味のプログラムでは実害はないのだけれど、コードの追跡性や移植性、テスト、もろもろの利便性では劣ってくる。
頑張る気があるなら、単体のLambda関数としてパッケージ、デプロイなり、SAMとしてプロジェクト化してデプロイなり、コードを管理してやりたい。
同様に、1-ClickもIaCした方がいいんじゃないかな。多分。本番環境と検証環境と開発環境と、のように管理しなくてはならない場合は！
Lambdaが絡むCloudFormationは消化できていないので、あまり触りたくはない。
サービスとしての充実を考える
ボタンをプロジェクトに登録して、グラフと関連付けて、の様なフロントエンドを作るなど、いくらでも拡張のしようはあるけれど、大変だ！
ようするに
ボタンを押すと草が生える、という価値の実現のほかにもほどほどに1-Clickというサービスを楽しみたいと思う。
