🔥 SNS란 무엇인가: Pub/Sub의 관점

알람 메일 한 통을 받기 위해 왜 가운데에 알림 서비스가 한 번 더 들어가야 할까. CloudWatch Alarm 을 만들 때 액션 칸에는 메일 주소가 아닌 SNS Topic 이름을 적게 되어 있었다. S3 이벤트 알림도 마찬가지였다. 내가 기대한 경로는 S3 에서 메일로 바로 가는 단순한 경로였지만, 실제 설정은 S3 이벤트가 SNS Topic 으로 가고 Topic 이 Email 구독으로 메시지를 보내는 방식이었다.

이 한 단계가 왜 필요한지를 본 다음에야 SNS 가 메일 발송 기능이 아니라 여러 곳으로 알림을 나누는 서비스로 보이기 시작했다. 같은 알람 사건 하나에서 메일도 보내고, 사고 분석용 큐에도 같이 넣고, Lambda 함수도 호출해야 한다면 알림을 보내는 쪽 코드가 그 모든 대상을 다 알아야 했다. SNS 는 그 결합을 가운데에서 끊는다.

AWS 는 2010년 4월 7일 Amazon SNS 베타를 공개했다. 이후 Topic, 여러 구독 프로토콜, FIFO Topic 같은 기능이 추가됐다. 지금 기준 AWS 문서는 SNS 를 publisher 가 Topic 에 메시지를 보내고 subscriber 가 그 Topic 을 구독하는 완전 관리형 메시지 전달 서비스로 설명한다(AWS Developer Guide).

Pub/Sub 추상

Pub/Sub 은 보내는 쪽과 받는 쪽을 Topic 으로 분리한다. Publisher 는 Topic 에 메시지를 publish 한다. Subscriber 는 Topic 을 구독한다. Publisher 는 subscriber 목록을 알 필요가 없고, subscriber 도 publisher 를 직접 알 필요가 없다. 두 쪽은 Topic 이름과 권한을 통해 느슨하게 연결된다.

SQS 는 큐이고 SNS 는 라우터이다. SQS 에서는 생산자가 메시지를 넣고 소비자가 나중에 꺼낸다. SNS 에서는 publisher 가 메시지를 보내면 Topic 이 구독자들에게 전달한다. 큐는 시간차를 흡수하는 데 강하고, Topic 은 같은 알림을 여러 엔드포인트로 나누는 데 강하다. 그래서 SQS 의 기본 질문은 “누가 나중에 처리할 것인가”이고, SNS 의 기본 질문은 “같은 사실을 어디에 알려야 하는가”이다.

Fanout 은 한 메시지를 여러 엔드포인트로 복제해 보내는 구조이다. AWS 문서는 SNS Topic 에 publish 한 메시지를 Firehose delivery stream, SQS queue, HTTP(S) 엔드포인트, Lambda function 같은 여러 대상으로 복제하면 병렬 비동기 처리가 가능하다고 설명한다(fanout 문서). 주문 완료 이벤트 하나가 큐, 함수, HTTPS 엔드포인트, 메일 알림으로 동시에 갈 수 있다.

Topic 을 사이에 두면 publisher 변경 범위가 줄어든다. 알림을 받는 엔드포인트를 하나 더 추가해도 publisher 코드를 고치지 않아도 된다. 메일 구독을 빼거나 Lambda 구독을 추가해도 publisher 는 같은 Topic 에 sns:Publish 를 호출한다. publisher 코드가 subscriber 목록과 구현 세부 사항까지 알면 구독 변경 때마다 publisher 배포가 필요해진다. Topic 은 그 결합을 줄인다.

Topic 과 Subscriber

Topic 은 SNS 의 메시지 라우팅 단위이다. Topic 에는 이름, ARN, 리전이 있다. 서울 리전 Topic ARN 은 arn:aws:sns:ap-northeast-2:<account>:<topic-name> 형식을 갖는다(AWS General Reference). Topic 을 만들 때는 sns:CreateTopic 을 호출하고, 메시지를 보낼 때는 sns:Publish 또는 sns:PublishBatch 를 호출한다. sns:PublishBatch 는 한 호출에 최대 10개 요청 항목을 담는다.

Topic 은 Standard 와 FIFO 로 나뉜다. Standard Topic 은 일반 fanout 에 쓰고, FIFO Topic 은 순서와 중복 제거 요구가 있을 때 검토한다. 서울 리전 ap-northeast-2 기준 publish API 의 계정당 처리량 한도는 Standard Topic 초당 1,500개 메시지, FIFO Topic 초당 3,000개 메시지이다(SNS endpoints and quotas). us-east-1 같은 리전은 Standard 한도가 초당 30,000개 메시지로 훨씬 크다. 서울 리전에서 한 계정의 SNS publish 트래픽이 한 Standard Topic 으로만 나간다고 가정하고 초당 4,000개 알림을 보내면 그 계정 publish 한도 1,500을 2,500개 넘는다. FIFO 에는 토픽당 처리량 옵션 FifoThroughputScope=Topic 이 따로 있어 같은 토픽에 더 많은 throughput 을 허용한다.

Subscriber 는 Topic 을 구독하는 엔드포인트이다. AWS 문서는 SNS 구독 대상을 A2A 와 A2P 로 나눈다(AWS Developer Guide). A2A 는 애플리케이션 사이 전달이고 Amazon SQS, AWS Lambda, HTTP(S) 엔드포인트, Amazon Data Firehose, 서비스 공급자가 여기에 속한다. A2P 는 사람에게 보내는 알림이고 Email, SMS, 모바일 푸시 알림이 여기에 속한다.

구독은 sns:Subscribe 로 만들고 일부 엔드포인트는 sns:ConfirmSubscription 으로 확인한다. Email 과 HTTP/HTTPS 구독은 확인 절차가 특히 중요하다. Topic 에 publish 한 메시지는 Message 본문을 중심으로 하고, 필요하면 Subject 와 MessageAttributes 를 함께 보낸다. 메시지 본문 한도는 262,144바이트, 즉 256 KiB 이고, 메시지 헤더 한도는 16,384바이트, 즉 16 KiB 이다(SNS quotas). MessageAttributes 자체에도 표시 가능한 속성 수와 크기 한도가 있는데, 어떤 구독 형식이냐에 따라 달라지므로 사용 전에 SNS message attributes 문서 에서 자기 구독의 한도를 확인한다.

관리형 서비스의 운영 판단

SNS 는 관리형 Pub/Sub 이지만 운영 판단은 사용자에게 남는다. AWS 는 Topic 서버, 복제, 전달 시도를 맡는다. 사용자는 publish 권한, subscribe 권한, 엔드포인트 확인 절차를 정해야 한다. Topic policy 는 resource-based policy 의 한 형태이고, IAM 정책 평가에 함께 들어간다.

확인 절차는 단순한 부가 기능이 아니다. Email 구독은 확인 링크를 누르기 전까지 pending 상태로 남는다. HTTP/HTTPS 구독도 subscription confirmation handshake 를 처리해야 한다. Pending subscriptions 한도는 계정당 5,000개이다(SNS quotas). 알림 경로가 자동으로 연결된다고 생각하면 이 단계에서 누락이 생긴다.

실패 처리는 Topic 만으로 끝나지 않는다. SNS 에서 DLQ 를 쓰려면 구독 단위로 별도 설정을 해야 한다. 메시지가 256 KiB 를 넘는 경우도 별도 설계가 필요하다. Amazon SNS Extended Client Library 는 페이로드를 S3 에 두고 메시지에는 참조값을 보내는 방식을 제공하며, 이 방식은 최대 2 GB 페이로드까지 다룬다(large message payloads 문서). 300 KiB 이벤트 원문은 일반 SNS 메시지에 담을 수 없으므로 S3 참조 방식으로 바꿔야 한다. 큰 데이터를 그대로 알림 메시지에 넣는 습관은 손실 위험과 재처리 부담을 키운다.

요금도 무료가 아니다. SNS 는 publish 호출과 프로토콜별 전달에 비용이 붙는다. Email 과 email-json 구독은 구독당 초당 10개 메시지의 고정 한도가 있고, SMS 는 promotional 과 transactional 각각 초당 20개 메시지 전달 속도 한도가 있다(SNS quotas). Email 구독 하나에 초당 15개 메시지를 보내면 고정 한도를 5개 넘는다. 관리형 서비스로 서버 설치 업무는 줄어든다. 대신 권한, 확인, 실패 처리, 크기 제한, 청구 항목은 사용자가 계속 판단한다.

언제 SNS 를 쓰지 말아야 하는가

메시지 순서 보존이 업무 규칙의 중심이면 SNS Standard 를 먼저 고르지 않는다. Standard Topic 은 높은 처리량의 일반 알림에 맞고 순서는 최선 노력 방식으로 다룬다. FIFO Topic 이 있지만 SQS FIFO 와 함께 쓸 때 의미가 분명하다. 순서가 틀리면 잔액, 재고, 상태 전이가 깨지는 작업은 Topic 종류와 구독자 조합을 먼저 계산해야 한다.

한 메시지를 정확히 구독자 하나만 받아야 하는 작업에도 SNS 는 맞지 않는다. Pub/Sub 은 한 메시지를 여러 구독자로 보내는 구조다. 이미지 변환 작업 하나를 워커 중 하나만 가져가야 한다면 fanout 이 아니라 작업 분배가 필요하다. 이런 경우에는 SQS 큐가 더 자연스럽다.

publisher 가 구독자의 처리 결과를 회수해야 하는 작업에도 SNS 는 맞지 않는다. SNS 는 메시지를 보내고 전달 책임을 끝내는 방식에 가깝다. 구독자 세 곳이 각각 성공했는지, 어떤 값으로 끝났는지, 실패한 쪽을 기다릴지 같은 조정 메커니즘은 Topic 이 제공하지 않는다. 그런 요구에는 Step Functions 같은 오케스트레이션 서비스를 검토한다.

지금은 SNS 를 메일 발송 서비스보다 Pub/Sub 라우터로 본다. 한 사실을 여러 시스템에 알려야 할 때 Topic 을 떠올리고, 한 작업을 누군가 하나만 처리해야 할 때는 큐를 먼저 떠올린다. 앞으로는 fanout, FIFO Topic, Filter Policy, DLQ, 알람 연계를 이 기준 위에서 하나씩 확인한다.