Amazon SNS

주문 완료 하나를 계기로 메일도 보내고 후속 작업도 깨우고 운영 알림도 날려야 하는데, 발행 서비스가 소비자를 전부 직접 호출하면 연결이 금방 얽힙니다. 받는 쪽이 늘어날수록 원래 기능보다 알림 배선이 더 큰 일이 됩니다.

서비스 수가 늘면서 서비스 A가 이벤트 하나를 처리하기 위해 B·C·D를 직접 HTTP로 호출하는 구조가 흔해졌습니다. 이때 B 하나가 느려지거나 죽으면 A의 응답도 지연되고, 배선이 늘수록 하나의 장애가 연쇄적으로 번집니다. 이 직접 호출 패턴의 한계를 해결하기 위해 생산자와 소비자를 분리하고, 하나의 이벤트를 여러 목적지로 동시에 전달하는 pub/sub 모델이 필요해졌습니다.

생산자가 토픽에 메시지를 한 번 게시하면, SNS는 그 순간 모든 구독자에게 동시에 메시지를 푸시합니다. 구독자마다 수신 방식이 달라도 됩니다. 이메일 주소, HTTP 엔드포인트, Lambda 함수, SQS 큐가 같은 토픽을 구독하고 있으면 모두 같은 이벤트를 각자의 방식으로 받습니다. 생산자는 소비자가 몇 개인지, 어떤 방식으로 받는지 알 필요 없이 토픽에 한 번만 게시하면 됩니다.

SNS와 SQS는 둘 다 메시징이지만 흐름 모양이 다릅니다. SNS는 한 이벤트를 여러 구독자에게 동시에 퍼뜨리는 팬아웃 채널이고, SQS는 개별 작업을 큐에 쌓아 전달과 재시도를 다루는 채널입니다. 같은 사건을 여러 소비자에게 동시에 알려야 하면 SNS를 보고, 작업을 버퍼링하며 하나씩 처리해야 하면 SQS를 보면 됩니다.

경보 전파, 이벤트 팬아웃, 이메일·SMS 통지, 비동기 파이프라인의 브로드캐스트 성격 작업에 적합합니다. 한 소비자가 순차적으로 버퍼링하며 처리해야 하는 경우에는 맞지 않습니다.