SNS vs SQS

최근 디커플링이 필요한 작업을 맡게 되었다. 이 때 보편적으로 사용한 AWS 서비스 중 SQS 를 사용하기로 했는데, 비슷한 서비스로 SNS 가 있는 것을 보았다. 그래서 SQS 와 SNS 의 차이점에 대해서 확실히 알고 가기로 했다.

 

서비스 사용 기반

• SQS 는 풀 기반이다. 수신자가 메시지를 직접 받아야 한다.
• SNS 는 푸시 기반이다. 

관계 유형

• SQS 는 한개의 소비자만 가능하다.
• SNS 는 구독자가 많다.
• 공통적으로 메시지 생성자는 다수가 가능하다.

소비자

• SQS 는 SQS API 를 사용한다.
• SNS 는 다양한 목적지로 전송이 가능하다. 람다, SQS, 키테시스, HTTP, 문자메시지 등등...

보존

• SQS 는 일정 기간 동안 보존이 가능하다. 해당 기간 내 메시지를 확인하지 않으면 삭제된다.
• SNS 는 메시지 전달 보장을 하지 않는다.

재시도

• SQS 는 재시도 정책이 가능하다. DLQ 이동 전 재시도 횟수 정의가 가능하다.
• SNS 는 재시도를 할 수 없다.

배치

• SQS 는 배치가 가능하다. 표준 큐는 최대 10000개, FIFO 큐는 최대 10개가 가능하다.
• SNS 는 한번에 하나의 메시지만 처리 가능하다.

 

간단 정리

---

SQS 는 신뢰도를 중요하게 생각하는 작업 대기열, 배치 작업에 대해서 적합하다. 반면에 SNS 같은 경우에는 동시에 많은 구독자들에게 전달해야 하는 작업에 적합하다.

SQS 예시)

투표 API -> SQS -> Lambda 에서 폴링, API 처리

SNS 예시)

CloudWatch 알림 -> SNS -> SMS, 이메일, APP 알람 (재시도는 중요하게 생각하지 않음)

 

팬아웃 패턴 (두 가지를 동시에 쓰는 예시)

알림 생성 -> SNS -> 다수의 SQS

위와 같은 아키텍쳐를 구축하면 SNS 를 사용하여 다수의 Subscriber 에 대해서 이벤트 발송이 가능하고, 각각의 Subscriber 가 SQS 라면 해당 요청은 유실되지 않을 것이다.

 

참고 자료

---

https://aws.amazon.com/ko/sqs/

https://aws.amazon.com/ko/sns/

https://awsfundamentals.com/blog/aws-sns-vs-sqs-what-are-the-main-differences