한 회사에 두 가지 애플리케이션이 있습니다. 하나는 페이로드를 포함한 메시지를 처리하도록 보내는 송신자(sender) 애플리케이션이고, 다른 하나는 해당 페이로드를 수신하고 처리하는 처리(processing) 애플리케이션입니다. 송신자는 시간당 약 1,000개의 메시지를 보냅니다. 메시지 처리에는 최대 2일이 소요될 수 있으며, 실패한 메시지는 다른 메시지 처리를 방해하지 않도록 보존되어야 합니다. 이러한 요구 사항을 충족하고 운영 효율성이 가장 높은 솔루션은 무엇입니까?

이 솔루션은 메시지 큐 시스템인 Amazon SQS를 사용하여 두 애플리케이션 간의 비동기 통신을 가능하게 합니다. 송신자 애플리케이션은 메시지를 SQS 큐에 보내고, 처리 애플리케이션은 큐에서 메시지를 가져와 처리합니다. SQS는 메시지 처리 지연(최대 2일)을 지원하며, 메시지가 처리될 때까지 큐에 보관합니다. 또한, dead-letter queue(DLQ)를 구성하여 처리 실패 메시지를 다른 메시지 처리에 영향을 주지 않으면서 격리하고 보존할 수 있습니다. 이는 요구 사항을 모두 충족하며 운영 효율성이 높습니다. Redis 데이터베이스는 메시지 큐보다는 캐싱이나 세션 관리에 더 적합하며, 메시지 안정성 및 확장성 측면에서 SQS보다 불리합니다. Amazon Kinesis Data Stream은 실시간 스트리밍 데이터 처리에 적합하지만, 메시지 처리 지연이 길고 개별 메시지 보존보다는 스트림 처리량에 중점을 둡니다. Amazon SNS는 발행/구독 모델로, 메시지를 여러 구독자에게 동시에 푸시하는 데 사용되며, 메시지 보존 및 재시도 메커니즘이 SQS만큼 강력하지 않습니다.