아마존 SNS

Amazon Simple Notification Service; Amazon SNS; 아마존 SNS
발행자가 토픽에 보낸 메시지를 구독한 여러 엔드포인트에 동시에 밀어 주는 AWS의 완전 관리형 발행-구독(pub/sub) 메시징 서비스

SNS는 한 메시지를 여러 받는 쪽에 복제해 보내는 일대다 메시징 서비스이다. 발행자는 토픽(공식 한국어 문서 표기는 '주제')에만 메시지를 보내고, 누가 받는지는 구독으로 정해진다. 받는 쪽은 아마존 SQS 대기열, AWS Lambda 함수, HTTP/S 엔드포인트 같은 애플리케이션(A2A)일 수도 있고, 이메일·SMS·모바일 푸시처럼 사람(A2P)일 수도 있다. SNS는 메시지를 쌓아 두지 않고 즉시 밀어 주는(push) 방식이므로, 받는 쪽이 메시지를 보관하고 자기 속도로 처리해야 하면 SQS를 구독자로 붙인다.

핵심 개념

항목	설명
토픽	발행자와 구독자 사이의 논리적 접근 지점이자 통신 채널. 표준 토픽과 FIFO 토픽이 있다.
발행(Publish)	발행자가 토픽에 메시지를 보내는 동작. PublishBatch로 여러 메시지를 한 번에 보낼 수 있다.
구독(Subscription)	토픽과 엔드포인트의 연결. 프로토콜, 엔드포인트, 필터 정책, 전달 정책을 가진다.
메시지 크기	최대 256KiB. 더 큰 페이로드는 S3에 저장하는 확장 클라이언트 라이브러리를 쓴다.
보안	KMS 키로 토픽 저장 시 암호화, 토픽 정책(리소스 기반 정책)으로 발행·구독 권한 제어

구독 프로토콜

구분	엔드포인트	용도
A2A	아마존 SQS	메시지를 보관하고 소비자가 자기 속도로 처리. 팬아웃의 기본
A2A	AWS Lambda	메시지마다 함수를 비동기 호출
A2A	HTTP/HTTPS	외부 시스템 웹훅. 재시도 정책을 직접 정할 수 있는 유일한 프로토콜
A2A	아마존 Data Firehose	S3, Redshift 등으로 보관·분석
A2P	이메일, SMS, 모바일 푸시	사람에게 알림

대부분의 AWS 서비스 구독은 표준 토픽에서만 가능하고, FIFO 토픽은 SQS 대기열이 주된 구독자이다.

팬아웃

팬아웃(fan-out)은 SNS 토픽 하나에 여러 SQS 대기열을 구독시켜, 한 이벤트를 여러 시스템이 독립적으로 병렬 처리하게 하는 패턴이다.

예: 주문이 들어오면 "주문 생성" 토픽에 한 번 발행하고, 결제·재고·배송·분석 대기열이 각각 같은 메시지를 받아 처리한다.
새 처리 시스템이 생기면 발행자를 고치지 않고 대기열 하나를 구독시키면 된다.
각 대기열이 메시지를 보관하므로 한 소비자가 멈춰도 다른 소비자와 발행자에 영향이 없다.
다른 계정의 SQS 대기열도 구독할 수 있다. 이때 대기열 정책에서 SNS 토픽의 전송을 허용해야 한다.

메시지 필터링

구독에 필터 정책(JSON)을 붙이면 조건에 맞는 메시지만 그 구독자에게 전달된다. 필터 정책이 없으면 구독자는 토픽의 모든 메시지를 받는다.

필터 범위는 기본이 메시지 속성(MessageAttributes)이고, 메시지 본문(MessageBody)으로 바꿀 수 있다.
토픽을 이벤트 종류별로 쪼개지 않고, 구독자마다 필요한 메시지만 골라 받게 해 소비자 코드의 버리는 처리를 없앤다.

{
  "order_type": ["express"],
  "amount": [{"numeric": [">=", 100000]}]
}

FIFO 토픽

발행 순서대로 구독한 SQS 대기열에 전달하고, 중복 제거 기능으로 같은 메시지가 두 번 들어가지 않게 한다. SQS FIFO 대기열을 구독시키면 소비자까지 순서와 정확히 1회 처리가 이어진다. SQS 표준 대기열을 구독시키면 그 대기열 안에서는 순서가 보장되지 않는다.
순서는 메시지 그룹 ID 단위로 보장된다. 중복 제거는 중복 제거 ID나 내용 기반 해시로 한다.
필터 정책을 쓰면 FIFO 토픽은 최대 1회 전달이 된다.
메시지 아카이브와 재생: FIFO 토픽은 메시지를 토픽 안에 최대 365일 보관했다가 구독자에게 다시 보낼 수 있다. 유실 메시지 복구나 다른 리전 동기화에 쓴다.
표준 토픽보다 처리량 한도가 낮고 구독자 수도 적게 허용된다.

전달 재시도와 DLQ

SNS는 엔드포인트가 응답하지 않으면 프로토콜별 전달 정책에 따라 재시도한다. HTTP/S만 정책을 바꿀 수 있다.
재시도를 다 써도 실패하면 메시지는 버려진다. 구독에 SQS 대기열을 배달 못한 편지 대기열(DLQ)로 지정하면 실패 메시지를 남길 수 있다.

SQS, EventBridge와 비교

구분	아마존 SNS	아마존 SQS	아마존 EventBridge
모델	발행-구독(push, 일대다)	대기열(pull, 점대점)	이벤트 버스(규칙 기반 라우팅, 다대다)
메시지 보관	없음(FIFO 토픽 아카이브 제외)	최대 14일	기본 없음(아카이브 설정 시 보관·재생)
받는 쪽	많은 수의 구독자, SMS·이메일·모바일 푸시 포함	대기열을 폴링하는 소비자	규칙당 대상 최대 5개, AWS 서비스·API 대상 다수
필터링	구독별 필터 정책(속성 또는 본문)	없음(소비자가 받은 뒤 판단)	이벤트 패턴으로 이벤트 내용 전체에 대해 정교하게 필터링
이벤트 소스	발행자 애플리케이션, 일부 AWS 서비스 알림	생산자 애플리케이션	AWS 서비스 이벤트, 사용자 지정 앱, SaaS 파트너
처리량	리전별 발행 한도가 있으며 증가 요청 가능	표준 대기열은 거의 무제한	리전별 PutEvents·대상 호출 한도가 있으며 증가 요청 가능
대표 용도	팬아웃, 사람 대상 알림, CloudWatch 경보 통지	작업 버퍼링, 비동기 작업 분배	AWS 서비스·SaaS 이벤트에 반응, 이벤트 기반 마이크로서비스 라우팅

SNS와 SQS는 경쟁 관계가 아니라 함께 쓰는 경우가 많다. SNS가 복제·분배를 맡고 SQS가 보관·완충을 맡는다.

시험 포인트

"한 이벤트를 여러 시스템이 각각 처리", "새 소비자를 쉽게 추가"는 SNS → 여러 SQS 팬아웃이다.
구독자가 일부 메시지만 받아야 하면 별도 토픽을 늘리기보다 구독 필터 정책을 쓴다.
순서와 중복 방지가 필요한 팬아웃은 SNS FIFO 토픽 + SQS FIFO 대기열이다.
운영자에게 이메일·SMS 알림(예: CloudWatch 경보)을 보내는 것은 SNS이다.
메시지를 보관하고 소비자가 나중에 꺼내 처리해야 하면 SNS 단독이 아니라 SQS가 필요하다.
SaaS 이벤트 수신이나 이벤트 내용 기반의 복잡한 라우팅은 EventBridge 쪽이 맞다.

같이 보기

참고 문헌