메시징 서비스는 최신 분산 시스템과 이벤트 기반 아키텍처를 구축할 때 핵심 구성 요소입니다. AWS는 널리 사용되는 두 가지를 제공합니다.완전 관리형 메시지 서비스: Amazon Simple Notification Service(SNS)와 Amazon Simple Queue Service(SQS). 둘은 기능적으로 유사하지만, 기본 원칙, 사용 시나리오, 장점은 상당히 다릅니다.
이 글에서는 Oncloud AI가 SNS와 SQS의 주요 차이점을 자세히 분석하여 실제 요구 사항에 따라 적절한 서비스를 선택하는 데 도움을 드립니다.
Amazon SNS란 무엇인가요?
Amazon Simple Notification Service(SNS)는 여러 구독자에게 메시지를 푸시하는 기능을 지원하는 "pub/sub 모델"을 기반으로 하는 푸시 알림 시스템입니다. 앱 간(A2A)과 앱과 사람 간(A2P)의 두 가지 유형의 대상지를 지원합니다.
SNS가 지원하는 A2A 타겟은 다음과 같습니다.
- AWS 람다
- 아마존 SQS
- Amazon Kinesis 데이터 파이어호스
- AWS 이벤트 포크 파이프라인
- HTTP 엔드포인트
SNS가 지원하는 A2P 목표는 다음과 같습니다.
- 문자 메시지(SMS)
- 이메일
- 앱 내 알림
- AWS 챗봇
- 페이저 업무
SNS는 표준 주제와 FIFO 주제를 제공합니다. 표준 토픽은 성능이 높고 대기 시간이 짧은 반면, FIFO 토픽은 메시지 순서와 중복 제거를 지원하며 엄격한 메시지 순서가 필요한 비즈니스 시나리오에 적합합니다.
Amazon SQS란 무엇인가요?
Amazon Simple Queue Service(SQS)는 폴링 기반입니다.비동기 처리 서비스시스템 모듈을 분리하고 백그라운드 작업과 비동기 워크로드를 구현하는 데 사용됩니다.
SQS의 사용 모델은 생산자가 대기열에 메시지를 보내고, 소비자가 요구에 따라 대기열을 폴링하고 처리할 메시지를 얻는 것입니다. SQS는 두 가지 유형의 대기열을 제공합니다.
- 표준 대기열: 높은 처리량과 최소 한 번의 배달을 지원합니다.
- FIFO 큐: 메시지 순서 및 고유성 보장
SQS 지원 설정메시지 보존, 최대 14일까지, 그리고 또한 지원데드 레터 큐(DLQ)여러 번 실패한 메시지를 처리하고 안정적인 메시지 전달을 개선하는 데 사용됩니다.
SNS와 SQS의 주요 차이점
1. 푸시 vs 폴
- SNS는푸시 기반메시지가 게시되면 모든 구독자에게 즉시 전달됩니다.
- SQS는폴링 기반메시지가 게시된 후에는 대기열에 저장되고 소비자가 폴링하여 처리할 때까지 기다립니다.
2. 다대다 대 다대일
- SNS는 다대다 관계를 지원합니다. SNS 주제에는 여러 게시자와 구독자가 있을 수 있습니다.
- SQS는 일반적으로 다대일 관계로, 여러 생산자가 메시지를 보낼 수 있지만 메시지는 일반적으로 한 명의 소비자에 의해 처리됩니다.
3. 메시지 지속성
- SNS는 메시지 지속성을 보장하지 않습니다. 소비자가 이용할 수 없을 때 메시지가 푸시되면 해당 메시지는 삭제됩니다.
- SQS는 메시지가 나중에 DLQ를 통해 수신되거나 처리되도록 보장하는 강력한 지속성 메커니즘을 제공합니다.
4. 메시지 재시도 메커니즘
- SNS에는 기본적으로 재시도 메커니즘이 없습니다. 푸시가 실패하면 메시지가 손실됩니다.
- SQS는 재시도 메커니즘과 DLQ를 제공하며, 최대 재시도 횟수를 설정할 수 있습니다.
5. 일괄 처리 기능
- SNS는 단일 메시지 푸시만 지원합니다.
- SQS는 일괄 처리를 지원합니다. 표준 대기열은 배치당 최대 10,000개의 메시지를 처리할 수 있고, FIFO 대기열은 배치당 최대 10개의 메시지를 처리할 수 있습니다.
사용 시나리오 비교
SNS 활용에 적합한 시나리오:
- 여러 다른 시스템이나 플랫폼에 메시지를 푸시해야 함
- 실시간으로 사용자에게 알림(예: SMS, 이메일, 앱 알림)
- 여러 구독자에게 메시지를 브로드캐스트하기 위해 팬아웃 패턴을 구현합니다.
SQS 사용에 적합한 시나리오:
- 백그라운드 작업 처리에는 비동기성과 지속성이 지원되어야 합니다.
- 직접적인 통신을 피하기 위해 시스템 구성 요소를 분리합니다.
- 메시지 신뢰성 및 재시도 메커니즘에 대한 높은 요구 사항
- 일괄 처리 메시지
팬아웃 모드: SNS와 SQS의 결합
어떤 경우에는 SNS를 SQS와 함께 사용할 수 있습니다. 예를 들어, SNS는 여러 개의 SQS 대기열에 메시지를 게시하며, 각 대기열은 처리 논리에 해당합니다. 이런 접근 방식을 "팬아웃 모드"라고 합니다.
예:
- 사용자가 사진을 업로드했습니다
- SNS 게시 업로드 이벤트
- 여러 SQS 대기열이 메시지를 수신합니다.
- 대기열 A: 이미지 인식
- 대기열 B: 썸네일 생성
- 대기열 C: 사용자에게 알림
이 패턴을 사용하면 안정적인 비동기 처리와 모듈 분리가 가능합니다.
EventBridge 대 Kinesis: 다른 옵션
AWS는 SNS와 SQS 외에도 다른 메시징 및 이벤트 서비스를 제공합니다.
아마존 이벤트브릿지
- 이벤트 필터링 및 라우팅을 지원하는 이벤트 버스 서비스
- 이벤트는 SNS, SQS, Lambda 등의 대상으로 전송될 수 있습니다.
- 복잡한 이벤트 처리 논리에 적합
아마존 키네시스
- 실시간 스트리밍 데이터 처리 및 분석을 위해
- 높은 처리량과 복잡한 데이터 처리를 지원합니다.
요약하다
Amazon SNS와 Amazon SQS는 확장 가능하고 가용성이 높은 시스템을 구축하는 데 필요한 핵심 구성 요소입니다. SNS는 실시간 푸시 알림과 일대다 시나리오에 적합한 반면, SQS는 비동기 처리와 시스템 분리에 더 적합합니다.
올바른 서비스를 선택하면 시스템 성능을 향상시킬 수 있을 뿐만 아니라, 결합 및 유지 관리 비용도 줄일 수 있습니다.
온클라우드 AI 공식 AWS 파트너로서, AWS 결제, AWS 클라우드 서버 마이그레이션, SQS/SNS 아키텍처 컨설팅, 클라우드 서비스 호스팅 등 전문적인 서비스를 제공합니다. 필요 사항이 있으시면 페이지 하단의 QR 코드를 스캔하여 문의해 주세요!
