AWS IoT로 작업 대기열에 대한 기본 및 페일 오버 MQTT 구독자를 어떻게 설정합니까?

11

클라이언트 (ClientA라고 함)가 특정 MQTT 주제에 요청을 공개 할 수있는 시스템이 있습니다. 중요한 경우 브로커는 Amazon Web Services입니다. 그런 다음 ClientA에서 요청을 가져 와서 결국 데이터베이스 작업으로 전환하는 작업을 수행 할 수 있도록 항상 동일한 주제를 구독하는 다른 클라이언트 (MainSubscriber라고 함)가 있습니다. 중요한 경우 데이터베이스는 DynamoDB입니다.

MainSubscriber에 항상 액세스 할 수있는 것은 아니므로 장애 조치 구독자가 주 구독자의 장애 조치 백업이 되길 원합니다. 주 가입자가 요청을 적시에 처리하지 않으면 장애 조치 가입자는 동일한 작업 / 데이터베이스 작업을 시작합니다. 문제는 "작업"과 결과 "데이터베이스 작업"이 주 가입자와 장애 조치 가입자에 의해 복제되어서는 안된다는 것입니다.

다음은이 시스템에 대한 논리적 시스템 아키텍처 도면입니다.

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

분명히 그러한 시스템에는 몇 가지 문제가 있습니다.

주 가입자는 장애 조치 가입자에게 요청에 대해 작업하고 있음을 어떻게 표시합니까?
장애 조치 구독자는 주 구독자가 요청을 선택하지 않았으며 작업을 시작해야 함을 어떻게 감지합니까?
장애 조치 가입자는 갑자기 갑자기 온라인 상태로 돌아와서 요청을받을 경우를 대비하여 주 가입자를 어떻게 보류합니까?
주 가입자와 장애 조치 가입자 간의 동기화 문제를 처리하는 방법은 무엇입니까?

기존 솔루션이 이미 존재하는 경우 휠을 재발 명 할 필요가 없습니다. 그래서 첫 번째 질문은 이미 무언가가 있습니까?

그렇지 않다면 Main과 Failover 가입자 사이의 중재자 역할을하기 위해 Strongly Consistent 읽기와 함께 DynamoDB를 사용할 생각이었습니다. 그래서 두 번째 질문은 이것을하기위한 잘 확립 된 계획이 있는지 여부입니다.

mqtt aws-iot aws

— 폴 그린버그
소스

여기에서 Amazon SQS 와 같은 메시지 대기열 이 도움이 될 수 있는지 조사 했습니까 ? AWS IoT 와 통합 된 것으로 보이며 '작업 대기열'스타일 문제에 적합 해 보입니다.

— Aurora0001

8

AWS SQS 설명서 에 따르면 (브로커가 AWS라고 말했듯이) 기본 형식이어야합니다.

메시지가 수신 된 직후에는 큐에 남아 있습니다. 다른 소비자가 메시지를 다시 처리하지 못하도록 Amazon SQS는 가시성 시간 초과를 설정합니다.이 시간은 Amazon SQS가 다른 소비 구성 요소가 메시지를 수신하고 처리하지 못하게하는 시간입니다.

최대 처리 시간에 따라 올바른 가시성 시간 초과를 찾는 데 문제가 있습니다.

가입자가 동일한 메시지를 처리 할 가능성은 여전히 적습니다.이 경우 가입자 코드는 데이터베이스에 대한 dem 등원 출력을 생성하려고 시도해야하며 (적어도 기본 키는 동일 함) 동일한 레코드를 삽입 할 때 정상적으로 실패를 처리해야합니다.

— 텐시 바이
소스

7

AWS SQS 의 데드-레터 큐 개념을 살펴볼 수 있습니다 . AWS 문서에서 :

데드 레터 큐는 다른 (소스) 큐가 성공적으로 처리 (소비) 할 수없는 메시지를 대상으로 할 수있는 큐입니다. 데드 레터 큐에서 이러한 메시지를 따로 설정하고 격리하여 처리가 실패한 이유를 판별 할 수 있습니다.

따라서 기본 구독자가 일반 큐에서 청취하고 보조 구독자가 데드-레터 큐에서 청취하도록 지시하면 장애 복구 문제를 해결해야합니다.

또한 이것으로 1, 2, 3 번 문제가 해결됩니다. 이 경우 주 가입자와 보조 가입자는 서로 대화 할 필요가 없습니다.

또한 Tensibai의 답변을 바탕으로 여러 가입자가 동일한 대기열을 듣고있는 경우 한 번에 하나의 메시지를 받도록 가입자 코드를 작성 해야합니다.visibility timeout

단점은 처리가 지연되고 메시지는 잠시 후에 데드 레터 큐에 들어가는 것입니다.

따라서 원하지 않는 경우 Tensibai의 답변을 계속 진행할 수 있습니다. 그리고 상태 확인을 위해 추가 Dynamo 테이블을 사용하는 대신이를 용인 할 수 있다면이를 사용할 수 있습니다.

— Dawny33
소스