AWSでホストされているAPIにIoTデバイスが測定データを送信するソリューションを構築しています。各測定タイプについて、ユーザーはしきい値を設定できます。到達するとアラートが送信されます。
私の設計はイベントに基づいているため、APIで受信される新しい測定ごとに、AWS SQSキューにワークアイテムが生成されます。次に、ラムダ関数が作業項目を処理し、データベースからその特定のデバイスのすべてのしきい値アラートを読み取り、受信したデータのいずれかがしきい値を超えているかどうかを確認します。しきい値を超えると、アラートメールが送信されます。
APIは1時間あたり約1000のリクエストを処理し、データベースからのすべてのしきい値アラートの読み取りは、費用と時間がかかります。
だから私の質問は、このアラートシステムを設計するより良い方法があるかどうかです。頻繁に変更されないため、すべてのしきい値制限をキャッシュするキャッシュレイヤーを追加することを考えていましたが、これは、分散キャッシュを使用し、HTTP経由のラウンドトリップを行う必要があることを意味します。
すべての提案を歓迎します!
これを行う最良の方法は、データをクエリすることではなく、データが入ってくるときにそれを評価することです。
したがって、複数のワーカープロセスアプリケーションがあり、それぞれにアラートルールがあり、ファンアウトキューにあるIoTデバイスからイベントが受信されるときにすべてイベントをリッスンします。
各イベントは、アラートの基準に一致するかどうか、およびワーカープロセスがアラートAPIを使用してアラートを生成するかどうかを確認するために処理されます。
IoT Device -> messages
messages -> incoming queue
incoming queue -> fan out to RuleAQueue, RuleBQueue etc
RuleXQueue -> RuleXWorker
RuleXWorker -> check rule and raise alert if required.
このようにして、必要に応じてルールチェックを水平方向にスケーリングできるようにします。同じボックスですべてのルールを実行するか、それぞれにルールが1つある100万のボックスを使用します。
データベースからデータを選択しなければならないというボトルネックを取り除きます。
1時間あたりの実際のアラートが1000しかない場合、パフォーマンスのボトルネックである各テストを評価するのではなく、おそらく数秒* 1000ごとにデータベースにデータを照会しているように聞こえます。したがって、おそらくすべてのワーカーを同じボックスで実行することも、1つのアプリに結合することもできます。