AWS IoT Core のデータ送信先としての Amazon SQS を考える
歴史シミュレーションゲーム好きのくろすけです！
IoT システムを設計していて、AWS IoT Core （以後IoT Core）で受けたデータをそのまま AWS Lambda（以後Lambda） に渡すべきか、いったん Amazon SQS （以後SQS）を挟むべきかで悩んだので、その内容をまとめてみます。
当初は、漠然と SQS があった方がバーストにも強くなるし、データの欠損リスクも下げやすくできるので基本使ったほうがいいでしょという印象でした。
ですが、再送制御などの機能があるケースでは、SQS を使用することが必ずしも正解とは限らないとわかりました。
概要
今回整理したかったのは、次の 2 パターンのどちらが適しているかです。
IoT Core -> LambdaIoT Core -> SQS -> Lambda
一般論としては、SQS を挟むとバースト吸収やクラウド内での再試行設計がしやすくなり、データの欠損リスクも下げやすくできます。
一方で、IoT デバイス側に独自の再送ロジックなどがある場合は、SQS を挟むことでかえってバーストの要因となる可能性があることなどがわかりました。
この記事では、以下の観点で整理します。
- SQS を入れるメリット・デメリット
- SQS を入れない方がよいケース
- Device Shadow
1. SQS を入れるメリット・デメリット
まずは、IoT Core の送信先として SQS を入れる場合のメリット・デメリットをシンプルに整理します。
メリット
- 一時的にメッセージが増えても、キューで吸収しやすい
- 後続処理を非同期化しやすく、IoT Core と処理基盤を分離しやすい
- Lambda 失敗時の再試行や DLQ など、失敗時の扱いを設計しやすい
- キュー長や滞留時間を見ながら処理状況を把握しやすい
デメリット
- 構成が 1 段増えるため、送信から処理完了までのレイテンシが増えやすい
- IoT Core -> SQS -> Lambda と経路が長くなり、調査観点が増える
at least once前提のため、冪等性を考慮した実装が必要になる- 別途 IoT Core が
QoS = 1の場合についても冪等性の考慮が必要
- 別途 IoT Core が
特に、時系列データを大量に集める用途や、多少の遅延よりも安定した後続処理を優先したい用途では、SQS の使用が向いています。
2. SQS を入れない方がよいケース
一方で、下記のようなケースでは SQS の採用は慎重に検討すべきと考えます。
1. 送信から処理完了までのレイテンシが重要なケース
- デバイス、アプリ側に独自の再送制御がある
- DB 登録完了に対する応答を返す必要がある
- その他、応答遅延が端末動作に直結する
2. 重複データを許容できないケース
- データのカウントアップなどを DB に登録している
- アラート発生の契機となるデータを送信している
ただし 2 のケースでは、DynamoDBなどを使用して冪等性を確保することが可能な場合もあります。
上記のケース（SQS の採用が難しくなるケース）は、すでにデバイス側アプリが成立している（稼働中の既存環境が存在する）場合が多いと考えられます。
もし新規開発の場合は、可能であれば双方向通信を避けてシンプルな構成を目指すのが良いでしょう。
デバイス側の都合でデータの損失が多く、再送制御を考慮する必要があるなどケースにおいては、可能であれば通常のデータフローとは別に欠損補完の仕組みを設ける方が責務を分離できて良いと考えます。
3. Device Shadow
双方向通信や冪等性の話になると、Device Shadow が活用できるケースがあります。
ただし Device Shadow は、基本的には 状態を共有する仕組み です。
向いている例:
- デバイスの運転モード
- ON/OFF 状態
- 最終接続状態
一方で、再送制御のような 個別のデータイベントごとの応答 には少し不向きと考えます。
まとめ
いつもながらケースバイケースという結論です。
ただし、下記のケースでは SQS の採用は慎重に検討すべきと考えます。
- デバイス側アプリが成立している（稼働中の既存環境が存在する）
- 送信から処理完了までのレイテンシが重要
- 重複データを許容できない
あとがき
今回の検討では、SQS を入れるメリット自体は把握しつつも、デメリットが上回るケースがあることを理解しました。
クラウド側だけを見ていると「疎結合化したい」「バッファしたい」と考えがちですが、端末側の仕様（既存環境があればそのデータ処理の仕様も）をきちんと考慮して判断することが重要です。
同じように IoT Core の送信先として SQS を採用すべきか悩んでいる方の参考になれば幸いです。
以上、くろすけでした！
