SNS와 SQS를 언제 사용하는지 이해하지 못하며 왜 항상 서로 연결되어 있습니까?
답변:
SNS 는 분산 발행-구독 시스템입니다. 메시지는 게시자가 SNS로 보낼 때와 같이 가입자에게 푸시 됩니다.
SQS 는 분산 큐잉 시스템입니다. 메시지가 수신자에게 푸시되지 않습니다. 수신자는 SQS 에서 메시지 를 폴링하거나 풀해야 합니다 . 여러 수신자가 동시에 메시지를 수신 할 수 없습니다. 하나의 수신자가 메시지를 수신하여 처리하고 삭제할 수 있습니다. 다른 수신자는 나중에 동일한 메시지를받지 않습니다. 폴링은 메시지가 즉시 가입자에게 푸시되는 SNS와 달리 SQS에서 메시지 배달에 약간의 대기 시간을 제공합니다. SNS는 이메일, SMS, http 엔드 포인트 및 SQS와 같은 여러 엔드 포인트를 지원합니다. 알 수없는 수와 유형의 가입자가 메시지를 수신하도록하려면 SNS가 필요합니다.
SNS와 SQS를 항상 연결할 필요는 없습니다. SNS가 SQS와 별도로 이메일, SMS 또는 http 엔드 포인트로 메시지를 보내도록 할 수 있습니다. SNS와 SQS를 결합하면 이점이 있습니다. 외부 서비스가 호스트에 연결하는 것을 원하지 않을 수 있습니다 (방화벽은 외부에서 호스트로 들어오는 모든 연결을 차단할 수 있음). 대량의 메시지로 인해 엔드 포인트가 종료 될 수 있습니다. 전자 메일 및 SMS는 메시지 처리를 빠르게 선택하지 않을 수 있습니다. SNS와 SQS를 결합하면 원하는 속도로 메시지를받을 수 있습니다. 클라이언트가 오프라인 상태이고 네트워크 및 호스트 장애에 견딜 수 있습니다. 당신은 또한 보장 된 배달을 달성합니다. http 엔드 포인트 또는 이메일 또는 SMS로 메시지를 보내도록 SNS를 구성하면 메시지를 여러 번 보내지 않으면 메시지가 삭제 될 수 있습니다.
SQS는 주로 응용 프로그램을 분리하거나 응용 프로그램을 통합하는 데 사용됩니다. 메시지는 짧은 시간 (최대 14 일) 동안 SQS에 저장 될 수 있습니다. SNS는 여러 메시지 사본을 여러 가입자에게 배포합니다. 예를 들어, 응용 프로그램에서 생성 된 데이터를 여러 스토리지 시스템에 복제한다고 가정 해 보겠습니다. SNS를 사용하여이 데이터를 여러 가입자에게 보낼 수 있으며, 각 가입자는 서로 다른 스토리지 시스템 (s3, 호스트의 하드 디스크, 데이터베이스 등)으로 메시지를 복제합니다.
다음은 두 가지를 비교 한 것입니다.
엔터티 유형
메시지 소비
사용 사례
고집
소비자 유형
샘플 애플리케이션
AWS Doc에서 :
Amazon SNS를 통해 애플리케이션은 "푸시"메커니즘을 통해 시간이 중요한 메시지를 여러 가입자에게 보낼 수 있으므로 업데이트를 정기적으로 확인하거나 "폴링"할 필요가 없습니다.
Amazon SQS는 분산 애플리케이션이 폴링 모델을 통해 메시지를 교환하기 위해 사용하는 메시지 대기열 서비스이며, 각 구성 요소를 동시에 사용할 필요없이 전송 및 수신 구성 요소를 분리하는 데 사용할 수 있습니다.
http://docs.aws.amazon.com/sns/latest/dg/SendMessageToSQS.html
이 스레드의 답변은 약간 구식이므로 2 센트를 추가하기로 결정했습니다.
SNS 를 여러 가입자를 가질 수있는 전통적인 주제로 볼 수 있습니다 . 예를 들어 Lambda 및 SQS를 포함하여 하나의 지정된 SNS 주제에 대해 이기종 가입자를 가질 수 있습니다. SNS를 사용하여 SMS 메시지 나 이메일을 즉시 보낼 수도 있습니다. SNS에서 고려해야 할 사항은 한 번에 하나의 메시지 (알림) 만 수신되므로 일괄 처리를 활용할 수 없습니다.
반면에 SQS 는 메시지를 저장하고 한 소비자를 구독하는 대기열에 불과합니다 (예, 하나의 SQS 대기열에 N 소비자를 가질 수는 있지만 모든 소비자를 고려하면 관리가 매우 어려워지고 매우 어려워집니다) SNS가 N SQS 대기열에 알림을 푸시하고 모든 대기열에 하나의 가입자 만있는 경우) 이러한 메시지를 처리하기 위해 SQS와 결합 된 SNS를 사용하면 메시지를 한 번 이상 읽어야합니다. 2018 년 6 월 28 일부터 AWS는 SQS를위한 Lambda 트리거를 지원 하므로 폴링 할 필요가 없습니다.더 이상 메시지. 또한 장애 발생시 메시지를 보내도록 소스 SQS 대기열에서 DLQ를 구성 할 수 있습니다. 성공하면 메시지가 자동으로 삭제되므로 (이것은 또 하나의 큰 개선입니다.) 수동으로 삭제하는 것을 잊어 버린 경우 이미 처리 된 메시지를 다시 읽지 않아도됩니다. Lambda Retry Behavior를 살펴보십시오.작동 방식을 더 잘 이해합니다. SQS를 사용하면 얻을 수있는 큰 이점 중 하나는 배치 처리가 가능하다는 것입니다. 각 배치에는 최대 10 개의 메시지가 포함될 수 있으므로 100 개의 메시지가 SQS 대기열에 한 번에 도착하면 Lambda의 기본 자동 스케일링 동작을 고려하여 10 개의 Lambda 함수가 가동되고이 100 개의 메시지를 처리합니다 ( 실제로 이것은 행복한 경로이며, Lambda 함수가 더 많으면 배치에서 10 개 미만의 메시지를 읽을 수 있지만 아이디어는 얻습니다.) 그러나 동일한 100 개의 메시지를 SNS에 게시 한 경우 100 개의 Lambda 함수가 작동하여 비용이 증가하고 Lambda 동시성을 사용하지 않게됩니다. 그러나 여전히 EC2 인스턴스와 같은 기존 서버를 실행중인 경우에도 메시지를 폴링하고 수동으로 관리해야합니다.
메시지 전달 순서를 보장하는 FIFO SQS 대기열 도 있습니다 . 이는 Lambda에서 지원되는 트리거가 아니므로이 유형의 대기열을 선택할 때 메시지를 수동으로 삭제해야 할뿐 아니라 폴링이 여전히 필요하다는 점을 명심하십시오.
사용 사례에 겹치는 부분이 있지만 SQS와 SNS에는 각각 고유 한 관심사가 있습니다.
다음과 같은 경우 SNS를 사용하십시오 .
다음과 같은 경우 SQS를 사용하십시오 .
AWS SNS 는 구독자가 주제를 구독 할 수 있고 게시자가 해당 주제를 게시 할 때마다 메시지를 수신하는 게시자 구독자 네트워크입니다.
AWS SQS 는 대기열에 메시지를 저장하는 대기열 서비스입니다. SQS는 SQS를 폴링하고 SQS에서 메시지를 가져 오기 위해 외부 서비스 (lambda, EC2 등)가 필요한 메시지를 전달할 수 없습니다.
여러 가지 이유로 SNS와 SQS 를 함께 사용할 수 있습니다.
폴링을 통한 나중에 사용하기 위해 일부는 메시지를 즉시 전달해야하는 경우도 있고, 일부는 메시지를 지속해야하는 경우도 있습니다. 이 링크를 참조하십시오 .
" 팬 아웃 패턴 " 메시지의 비동기 처리를위한 것입니다. 메시지가 SNS에 게시되면 여러 SQS 대기열에 동시에 배포 할 수 있습니다. 이미지를 게시 할 때 응용 프로그램에서 축소판을 병렬로로드 할 때 유용합니다. 이 링크를 참조하십시오 .
영구 저장 장치 . 메시지를 처리 할 서비스가 신뢰할 수없는 경우 이와 같은 경우 SNS가 알림을 서비스에 푸시하고 해당 서비스를 사용할 수 없으면 알림이 손실됩니다. 따라서 SQS를 영구 저장소로 사용한 다음 나중에 처리 할 수 있습니다.
간단히 말해서, SNS-푸시 메커니즘을 사용하여 풀링이 필요없는 메시지를 가입자에게 보냅니다. SQS-분산 응용 프로그램이 폴링 모델을 통해 메시지를 교환하기 위해 사용하는 메시지 큐 서비스이며 송수신 구성 요소를 분리하는 데 사용할 수 있습니다.
일반적인 패턴은 SNS를 사용하여 메시지를 Amazon SQS 대기열에 게시하여 하나 이상의 시스템 구성 요소에 비동기 적으로 메시지를 안정적으로 전송하는 것입니다. https://aws.amazon.com/sns/faqs/ 에서 참조
visibilityTimeout이 값을 설정하면 다른 시스템에서 메시지를 처리 한 후 다른 시스템에서 메시지를 사용할 수 없습니다.