AWS IoTでジョブキューのメインおよびフェイルオーバーMQTTサブスクライバーを設定するにはどうすればよいですか？

クライアント（ClientAと呼ぶ）が特定のMQTTトピックにリクエストを発行できるシステムがあります。ブローカーは、重要な場合には、アマゾンウェブサービスです。次に、常に同じトピックにサブスクライブしている別のクライアント（MainSubscriberと呼ぶことにします）を用意します。これにより、ClientAからの要求を取得し、最終的にはデータベース操作になるいくつかの作業を実行できます。重要な場合は、データベースはDynamoDBです。

MainSubscriberは常にアクセス可能/オンラインであるとは限らないため、フェイルオーバーサブスクライバーがメインサブスクライバーのフェイルオーバーバックアップになることが望まれます。考えは、メインサブスクライバーが要求をタイムリーに処理しない場合、フェールオーバーサブスクライバーが起動し、同等の作業/データベース操作を実行するというものです。課題は、「作業」とその結果の「データベース操作」をメインサブスクライバーとフェイルオーバーサブスクライバーの両方で複製してはならないことです。

これは、このシステムの論理システムアーキテクチャ図です。

                   -----> MainSubscriber ----
                  /                          \
ClientA --> Broker                            ---> Database
                  \                          /
                   ---> FailoverSubscriber --

明らかに、このようなシステムにはいくつかの課題があります。

1. メインサブスクライバーは、フェールオーバーサブスクライバーに対して、要求を処理していることをどのように示しますか？
2. フェイルオーバーサブスクライバーは、メインサブスクライバーが要求を取得しておらず、要求の処理を開始する必要があることをどのように検出しますか
3. フェールオーバーサブスクライバーは、突然突然オンラインに戻って要求を受け取った場合に、メインサブスクライバーをどのように保留しますか？
4. メインサブスクライバーとフェールオーバーサブスクライバー間の同期の問題に対処する方法

そのようなスキームの既存のソリューションがすでに存在する場合は、ホイールを再発明する必要はありません。それで、私の最初の質問は、すでに何かがあるかどうかです。

そうでない場合は、DynamoDBを非常に一貫した読み取りで使用して、メインサブスクライバーとフェールオーバーサブスクライバーの間のメディエーターとして機能することを考えていました。それで、私の2番目の質問は、これを行うための確立されたスキームがあるかどうかです。

AWS SQSドキュメントによると（ブローカーはAWSであると言ったように）、これはネイティブである必要があります。

メッセージを受信した直後は、キューに残ります。他のコンシューマーがメッセージを再度処理できないようにするために、Amazon SQSは可視性タイムアウトを設定します。この期間は、Amazon SQSが他の消費コンポーネントがメッセージを受信して​​処理するのを防ぎます。

最大処理時間に応じて適切な可視性タイムアウトを見つける問題です。

両方のサブスクライバーが同じメッセージを処理する可能性はまだわずかですが、この場合、サブスクライバーコードはデータベースのべき等出力（少なくとも同じ主キー）を作成しようとし、同じレコードを挿入しようとしたときに失敗を適切に処理する必要があります。

AWS SQSの配信不能キューの概念を確認することをお勧めします。AWSドキュメントから：

配信不能キューは、他の（ソース）キューが、正常に処理（消費）できないメッセージのターゲットにできるキューです。これらのメッセージを取り置き、デッドレターキューに隔離して、処理が成功しなかった理由を特定できます。

したがって、メインサブスクライバが通常のキューからリッスンするように、セカンダリサブスクライバが配信不能キューからリッスンするように指定すると、フェールオーバーの問題が解決されます。

また、これにより、問題の1、2、3が処理されます。この場合、メインサブスクライバとセカンダリサブスクライバは互いに話す必要はありません。

一度に一つのメッセージを受信するようにまた、Tensibaiの回答時に構築、必ずご加入者のコードが書かされていることを確認し、複数の加入者が同じキューを聴いている場合に起因してvisibility timeout

欠点は、処理に遅延が生じることです。メッセージはしばらくしてから配信不能キューに入ります。

したがって、それが望まない場合は、Tensibaiの答えを先に進めることができます。そして、それを許容できる場合は、ステータスチェック用の追加のDynamoテーブルを用意する代わりに、これを使用できます。