AWS SQS vs. SNS
이번 실습과제를 하면서 이름도 비슷하고 뭔가 기능도 비슷한 것 같아 헷갈리는 경우가 많아서 정리하게 되었다.
AWS SQS
마이크로서비스, 분산 시스템 및 서버리스 애플리케이션을 위한 완전관리형 메시지 대기열
https://aws.amazon.com/ko/sqs/
- Producer : 처리할 작업 메시지를 SQS에 등록
- Queue : 메시지를 저장하는 큐
- Consumer : 큐 대기열에 있는 메시지 목록을 조회하여 받아옴
특징
- 애플리케이션 신뢰성 및 확장성 향상
- 마이크로서비스 분리 및 이벤트 기반 애플리케이션 처리
- 작업을 비용 효율적이고 정시에 완료하도록 보장
- 메시지 순서 유지 및 중복 제거
용도
- 마이크로서비스, 분산 시스템을 구현할 때, 느슨한 연결(Loosly Coupled) -> 메시지 기반 애플리케이션
- 더 나은 내결함성을 위해 특정 부분을 분리해야하는 경우
- 애플리케이션 이벤트 또는 메시지에 대해 내구성 있는 스토리지가 필요한 경우
표준 대기열과 FIFO 대기열
- 표준 대기열
- 무제한 처리량 : API 작업당 거의 무제한의 초당 트랜잭션(TPS)을 지원한다.- 최소한 한 번 전달 : 가끔 2개이상의 메시지 복사본이 전달될 수 있다.
- 최선 노력 순서 : 가끔 메시지가 전송된 순서와 다르게 전달될 수 있다.
- FIFO 대기열
- 높은 처리량 : 초당 최대 3000개의 메시지를 지원한다.- 정확히 한 번 처리: 메시지가 한 번 전달되고 중복 메시지는 대기열에 올라가지 않는다.
- 선입선출 전달 : 메시지가 전송되고 수신되는 순서가 엄격하게 지겨진다.
DLQ(Dead Letter Queue)
소비자가 성공적으로 처리하지 못한 메시지를 배달 못한 편지 대기열을 사용하여 처리한다. 메시지에 대한 최대 수신 개수가 초과하면 해당 메시지는 원래 대기열에 연결된 배달 못한 편지 대기열(DLQ)로 이동된다. 메시지 전달이 중단된 이유를 분석하고 이해하는 데 도움이 될 수 있는 DLQ에 대해 별도의 소비자 프로세스를 설정하여 관리할 수 있다. DLQ는 원본 대기열(표준 또는 FIFO)과 같은 유형이어야 한다.
https://aws.amazon.com/ko/what-is/dead-letter-queue/
AWS 공식 사이트 - Amazon SQS 사용의 이점
https://docs.aws.amazon.com/ko_kr/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-benefits.html
AWS SNS
A2A 및 A2P 메시징을 위한 완전관리형 게시/구독 서비스
https://aws.amazon.com/ko/sns/?nc2=type_a
Publisher 는 Topic에 대한 메시지를 게시(publish)하고 Consumer 는 메시지를 수신하기 위해 이러한 Topic에 구독(subscribe)하여 Publisher가 SNS에 메시지를 보낼 때 메시지가 Subscriber에게 푸시된다.
AWS SQS 대기열, AWS Lambda 함수 및 HTTP endpoint과 같은 다양한 유형의 Subscriber에게 메시지를 전송할 수 있다(A2A). 또한 SNS를 사용하여 end-user 장치에 SMS 메시지, 전자 메일 및 푸시 알림을 보낼 수 있다.(A2P)
- 표준 주제 : 최대 처리량, 최선의 주문 및 최선의 중복 제거(메시지가 두 번 이상 전달될 수 있음)를 제공한다.
- FIFO 주제 : 엄격한 순서 지정 및 중복 제거를 제공한다. 단점은 FIFO 항목을 사용하여 이벤트를 SQS 대기열에만 보낼 수 있다.(다른 유형의 소비자는 지원되지 않음)
SQS와 SNS의 주요 차이점
- SNS는 A2A와 A2P 통신을 지원하는 반면, SQS는 A2A 통신만 지원한다.
- SQS가 큐잉 시스템인 반면, SNS는 pub/sub 시스템이다. 일반적으로 SNS를 사용할 땐 Topic을 통해 여러 소비자에게 동일한 메시지를 보낸다. 이에 비해 대부분의 경우에서 SQS 대기열의 각 메시지는 한 소비자에 의해서만 처리된다.
- SQS를 사용하면 메시지가 긴 폴링(풀) 메커니즘을 통해 전달되는 반면, SNS는 푸시 메커니즘을 사용하여 가입된 엔드포인트로 메시지를 즉시 전달한다.
- SNS는 일반적으로 실시간 알림이 필요한 애플리케이션에 사용되는 반면, SQS는 메시지 처리 사용 사례에 더 적합하다.
- SNS는 메시지를 지속하지 않는다. 메시지를 존재하는 구독자에게 전달한 다음 삭제한다. 이에 비해 SQS은 메시지를 지속할 수 있다.(1분에서 14일).
AWS SNS 사용 예
- 최종 사용자에게 이메일, SMS 및 푸시 알림을 실시간으로 전송 (Apple, Google, Fire OS 및 Windows 장치에 푸시 알림)
- 여러 가입자에게 메시지 브로드캐스트(예: 앱의 모든 사용자에게 동일한 푸시 알림 출력).
- SNS를 사용하여 분산된 앱 간에 이벤트를 전달하거나, 다양한 비즈니스 시스템에서 레코드를 업데이트(예: 인벤토리 변경).
- 실시간 경고 및 애플리케이션 모니터링.
AWS SQS 사용 예
- 비동기 처리 워크플로우
- 여러 SQS 대기열을 사용하여 메시지를 병렬로 처리
- 마이크로서비스, 분산 시스템 및 서버리스 애플리케이션의 분리 및 확장
- 신뢰할 수 있는 메시징 보증(주문 및 정확한 한 번의 처리)을 통해 이벤트를 전송, 저장 및 수신
SQS + SNS
AWS SNS와 SQS 모두 자체적으로 유용하지만, 이들을 결합해 보다 강력하고 신뢰할 수 있는 시스템을 만들 수도 있다. 예를 들어, SNS와 SQS를 함께 사용하면 이벤트에 대한 즉각적인 알림이 필요한 애플리케이션에 메시지를 전달할 수 있으며, 다른 애플리케이션이 나중에 처리할 수 있도록 SQS 대기열에 지속될 수도 있다.
또한 SNS와 SQS를 결합하여 엔드 투 엔드 메시지 정렬을 보장할 수 있다. 예를 들어, 메시지가 Topic에 게시되는 정확한 순서로 구독된 SQS FIFO 대기열에 메시지를 배달하는 SNS Topic을 사용할 수 있다. SQS FIFO 큐의 소비자는 큐로 전송되는 것과 동일한 순서로 메시지를 수신한다.
출처 - AWS 공식 사이트, https://ably.com/topic/aws-sns-vs-sqs (https://dev-minjeong.tistory.com/39)
