AWS IoT Coreのルールアクション DynamoDBとDynamoDBv2の違いを図解してみる

AWS IoT Core のルールアクションには様々なものがありますが、DynamoDB に関しては「DynamoDB」と「DynamoDBv2」の2種類があります。

それぞれの違いについては、下記のブログが詳しいです。

今回、この内容をひと目で分かるように資料化する機会があったので、作成した資料をご紹介したいと思います。

DynamoDB アクションの場合

最初は無印の DynamoDB アクションの場合です。この記事中では便宜的に「v1 アクション」と呼ぶことにします。

この「v1 アクション」は先のブログにある通り、「SELECT した内容がアクションの設定で指定したカラム（属性）に put されます。」
（この記事では、属性のことを分かりやすく統一的にカラムと呼ぶことにします）

これを一枚の図に表したものが下記になります。

この場合、アクション内容で次の設定があることが分かります。

• デバイスデータを格納する対象のカラムを指定
  • カラム：received_data

この設定により、図の通りルールクエリでフィルタした内容が DynamoDB テーブルのカラム「received_data」に格納されます。

一方で、パーティションキー（id）はアクションの設定で指定した内容（ここではprincipal()の値）が入ります。

DynamoDB V2 アクションの場合 - その1

「v2 アクション」では、「SELECT した内容が個々のカラムとして put されます。」
これを一枚の図に表したものが下記になります。

「DynamoDB V2」では、図の通りルールアクションの設定項目は「対象のテーブル名」と「必要な権限を持つ IAM Role 」の指定のみです。

ここでは「V1 アクション」の時と同じデバイスデータを送り、同じようなルールクエリを設定して DynamoDB に格納しています。DynamoDB は先程とよく似たテーブル構造になっていますが、SELECT した内容がそのまま個別のカラムに格納されていることが分かります。（idとmy_payload というカラムに入っています。）

また、パーティションキーである id には、ルールクエリで指定した principal() の値が格納されていることも分かります。

DynamoDB V2 アクションの場合 - その2

次に、先程よりもシンプルなクエリフィルタで確認してみます。

この図の通り、ルールクエリではパーティションキーを指定せず、クエリの内容も SELECT * FROM topic/sample というシンプルなクエリの設定です。

V2 アクションでは SELECTした内容が個々のカラムに put される為、このクエリではDynamoDB のカラムそれぞれにデバイスデータがそのまま格納されています。

パーティションキーについては、デバイスデータの中に既にキーとなるデータ（"id": "test001" ）が含まれている為、そのままパーティションキーとして DynamoDB のテーブルに格納されます。

最後に、オマケとして「デバイスデータにパーティションキーとなるデータが存在しない場合」を確認してみます。ルールクエリは先程と同じものとします。

図の通り、先程のデータにあったidという項目をid_ngという名前に変更して送ってみます。想像通り、パーティションキーが存在しない為アクションの実行に失敗します。

実際に CloudWatch Logs でもエラーログを確認することができました。

最後に

既に解説記事がありましたが、今回は短時間でアクションの内容を講義形式で伝える必要があったので、分かりやすく図解してみました。

実際には「吹き出し」を多用して解説しているので、図解と言うにはやや怪しい部分がありますが（汗）、参考にしていただけると幸いです。

以上です。