[AWS] SNS vs SQS
AWS의 Simple Notification Service (SNS)와 Simple Queue Service (SQS)는 AWS에서 제공하는 메시징 서비스로, 이벤트 기반 아키텍처와 분산 시스템에 사용될 수 있습니다.
1. AWS SNS와 SQS의 차이
1.1 메시징 패턴
- SNS (Simple Notification Service)
- Publish/Subscribe 모델을 기반으로 작동합니다.
- 메시지를 하나의 주제(Topic)에 게시하면, 해당 주제를 구독한 모든 구독자가 메시지를 동시에 수신합니다.
- 실시간 알림이나 브로드캐스트 방식의 메시징에 적합합니다.
- SQS (Simple Queue Service)
- Point-to-Point 모델을 기반으로 작동합니다.
- 메시지를 대기열(Queue)에 저장하며, 메시지는 소비자(Consumer)가 하나씩 처리합니다.
- 메시지가 한 번에 한 소비자에게만 전달되므로, 순차적 처리가 필요한 워크플로우에 적합합니다.
1.2 메시지 보존
- SNS
- 메시지는 수신자에게 즉시 전달됩니다.
- 구독자가 메시지를 수신하지 못하면 해당 메시지는 손실됩니다(푸시 기반)
- 메시지를 보존하지 않습니다.
- SQS
- 메시지를 대기열에 저장하며, 수신자가 이를 처리할 때까지 보존됩니다.
- 표준 대기열의 기본 보존 기간은 4일이며, 최대 14일까지 설정 가능합니다.
1.3. 메시지 처리 방식
- SNS
- 다수의 구독자가 동시에 메시지를 받을 수 있습니다(멀티캐스트).
- HTTP/HTTPS, Lambda, 이메일, SMS, SQS 등 다양한 전송 프로토콜을 지원합니다.
- SQS
- 메시지는 한 번에 하나의 소비자만 처리할 수 있습니다.
- 표준 대기열: 메시지가 중복될 수 있으며, 순서가 보장되지 않습니다.
- FIFO 대기열: 메시지의 순서가 보장되며, 중복 방지가 가능합니다.
2. AWS SNS와 SQS는 언제 사용될까?
2.1. SNS 사용 사례
- 실시간 알림
- 애플리케이션 이벤트, 오류 알림, 또는 시스템 경고를 여러 사용자에게 동시에 알릴 때 사용
- 예: 장애 알림을 이메일과 SMS로 전달
- 브로드캐스트 메시징
- 특정 이벤트에 대해 여러 서비스 또는 애플리케이션에 동시에 알릴 때
- 예: 새 콘텐츠를 게시하면 관련 구독자에게 알림
- 서로 다른 시스템 간 통신
- 서로 다른 소비자가 다양한 프로토콜로 메시지를 받아야 할 때 적합
- 예: HTTP API, Lambda 함수, SQS 대기열 등 다양한 방식으로 전달
2.2. SQS 사용 사례
- 비동기 워크로드 처리
- 작업 요청을 처리하는 시스템이 작업의 속도를 조정해야 할 때
- 예: 이미지 처리, 데이터 변환, PDF 생성과 같은 배치 작업
- 순차적 메시지 처리
- 메시지를 정확히 한 번 전달하고, 순서를 보장해야 하는 경우
- 예: 금융 트랜잭션 로그, 주문 처리
- 애플리케이션 디커플링
- 생산자와 소비자가 독립적으로 작동하도록 분리
- 예: 백엔드 서비스가 트래픽 급증을 효율적으로 처리하도록 지원
3. Event-Driven Architecture에서 SNS와 SQS의 역할
이벤트 기반 아키텍처(Event-Driven Architecture)는 애플리케이션 간의 느슨한 결합과 확장성을 위해 이벤트를 중심으로 설계됩니다. 여기서 SNS와 SQS는 중요한 역할을 합니다.
3.1. SNS 역할
- 중앙 이벤트 브로커
- 이벤트가 발생하면 SNS가 이를 브로드캐스트하여 여러 소비자에게 알립니다.
- 예: 새 주문이 접수되었을 때, 주문 처리 서비스, 결제 서비스, 알림 서비스가 동시에 이벤트를 수신
- 다양한 프로토콜 지원
- HTTP API, Lambda, SQS 등 여러 유형의 소비자에게 이벤트를 전달
- 예: Lambda 함수를 호출하여 실시간 처리를 수행하고, 동시에 SQS에 이벤트를 저장하여 후속 처리를 예약
3.2. SQS 역할
- 비동기 작업 관리
- 생산자가 이벤트를 SQS에 넣고, 소비자가 이를 순차적으로 처리
- 예: 이미지 처리 서비스가 업로드된 이미지를 SQS 대기열에서 하나씩 처리
- 결함 허용성과 메시지 보존
- 소비자가 다운되거나 처리 속도가 느릴 때도 대기열에 메시지가 유지되므로, 안정적인 작업 처리가 가능
3.3. SNS와 SQS를 함께 사용하는 패턴
SNS와 SQS를 조합하면 효율적인 이벤트 기반 아키텍처를 구축할 수 있습니다.
- SNS -> SQS 패턴
- SNS를 통해 이벤트를 브로드캐스트하고, 여러 SQS 대기열에 분배합니다.
- 예: 주문 시스템에서 SNS 주제를 통해 주문 이벤트를 발생시키고, 이를 주문 처리 대기열과 재고 관리 대기열에 전달
- SNS -> Lambda + SQS
- SNS가 Lambda를 호출하여 실시간 작업을 처리하고, 동시에 SQS에 이벤트를 저장하여 비동기 작업을 처리
- 예: 결제 요청 시 SNS로 이벤트를 게시하여, Lambda 함수가 즉시 승인 작업을 수행하고, SQS에 추가 작업을 보관
결론
- SNS는 실시간 알림, 멀티캐스트 메시징에 적합하며, 여러 구독자에게 메시지를 동시에 전달합니다.
- SQS는 비동기 처리와 작업 디커플링에 강점을 가지며, 메시지를 저장하고 순차적으로 처리할 때 유용합니다.
댓글남기기