IoT#AWSSIN2021.06.13この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。はじめにCX事業本部の平内(SIN)です。Streams)をアクションとして指定した場合、シャードの入力制限を超えたデータは、ロストすることになります。CoreへPublishする事で、ロストをリカバリする要領を確認してみました。溢れたデータを再投入する仕組みを作ったとしても、常時、入力制限を超えてしまっている様な場面では、対応できません。想定していたデータ量が一時的に超えてしまった場合のリカバリーというイメージです。ここで紹介する仕組みは、ルールのアクションが、常にエラーになったりすると無限ループとなってしまうため、Payloadにマークを入れるなどして、想定外のループになってしまわないようにする注意が必要です。最初に、シャードの制限内で想定通り動作している状況を作ってみます。処理するLambdaでは、集計のために、受信したRecord数をログ出力しています。CoreへのMQTTの送信は、下記のブログで作成したものを使用しました。上記を調整し、秒間900件のデータを10秒間送信しています。Coreのログを確認すると、綺麗に毎秒900件到着していることが確認できます。Lambdaの方も、概ね毎秒900件が処理されています。データのロスト続いて、データがロストする状況を作為してみます。Streamsでは、シャードを1に設定しているので、秒間1,000件を超えると、制限オーバーとなるはずです。上記と同じ様に、毎秒900件送信し、3秒目と4秒目だけ倍の1800件としてみました。secwait...finish!また、ルールのエラーアクションに、Lambdaを設定しました。print(event)以下が、結果です。正常に処理された場合Lambdaの処理数は、10,800件となるはずですが、結果は、全部で10,564件となっており、236件がロストしているようです。設定したエラーアクションもコールされています。エラーアクションの方を集計してみると、ロストされた236件と一致していました。ロストのリカバリエラーアクションに指定したLambdaのeventの内容は以下の様になっています。]}エラーアクションに設定したLambdaで、base64OriginalPayloadをデコードすると、Payloadの内容がそのまま入っています。Publishするように変更しました。)上記のLambdaをエラーアクションに設定していると、到着はやや乱れますが、総数で、10,800件処置されたことが確認できました。この時、エラーアクションの方は、310回起動されています。10,800件送ったPublishの到着は、11,110件となっています。当初のクライアントから到着しているのが、10,800件それ以外(LambdaからのPublish)が、310件です。Coreへ送り直す事で、データのロストをリカバリーする要領を確認してみました。溢れたデータがリカバリーできても、結局、シャードの制限が増加する訳ではないので、エラーアクションがInvokeされた時点で、シャードの数の見直しは必要だと思います。