SQS(Simple Queue Service)
SQS는 AWS가 제공하는 완전관리형 메시지 큐다. 메시지를 큐에 넣어두면, 소비자(Consumer)가 필요할 때 하나씩 꺼내서 처리하는 구조다.
Producer 1 ─┐
Producer 2 ─┼─(Message)─▶ SQS 큐 ─(Trigger)─▶ Consumer(1곳만) → 처리 후 큐에서 제거
Producer 3 ─┘여러 발신자가 메시지를 큐에 쌓아두면 그걸 처리하는 쪽은 보통 한 곳(또는 같은 그룹의 워커들)이고, 처리된 메시지는 큐에서 사라진다. FIFO 큐를 쓰면 순서 보장도 가능하다.
SNS(Simple Notification Service)
SNS는 발행/구독(Pub/Sub) 모델로 동작하는 완전관리형 알림 서비스다. 하나의 주제(Topic)에 메시지를 발행하면 그 주제를 구독하고 있는 모든 엔드포인트로 동시에 전달된다.
Publisher ─(Publish)─▶ SNS Topic ─(Subscribe)─┬─▶ Lambda
├─▶ SQS
├─▶ Email
└─▶ EventBridge저번에 만들었던 CloudWatch → SNS → Lambda → Slack 흐름이 바로 이 구조였다. 이상 상황 하나를 여러 구독자(Lambda 등)에게 동시에 뿌려야 하는 상황이라 SNS가 맞는 선택이다.
SQS와 SNS, 뭐가 다를까
- 모델: SQS는 큐 기반(Point-to-Point), SNS는 발행/구독(Pub/Sub)
- 메시지 전달: SQS는 큐에 저장되었다가 소비자가 꺼내가면 사라지고, SNS는 발행 즉시 모든 구독자에게 전달
- 용도: SQS는 비동기 작업 처리/워커 큐, SNS는 실시간 알림/이벤트 브로드캐스트
SQS는 한 번 처리하면 끝나는 작업을 순서대로 안전하게 넘기는 용도이고, SNS는 하나의 이벤트를 여러 곳에 동시에 알려야 하는 용도라는 게 가장 큰 차이였다. 만약 그때 만들었던 알림 함수가 'Slack에도 보내고 별도 로그 큐에도 쌓아야 한다'는 요구사항이었다면 SNS 하나에 Lambda와 SQS를 동시에 구독시켜서 양쪽에 다 전달할 수 있었겠다는 생각이 들었다.
둘을 같이 쓰는 경우
SQS와 SNS는 종종 함께 쓰이는데 Producer가 SQS에 메시지를 쌓고 그 SQS가 Lambda를 트리거하면 Lambda가 처리 결과를 다시 SNS로 발행해서 Slack 등 여러 곳에 알리는 식이다.
Producer ──▶ SQS(작업 큐) ──Trigger──▶ Lambda(처리) ──▶ SNS(결과 알림) ──▶ Slack / 다른 구독자SQS는 처리 대기열을, SNS는 처리 결과 전파를 맡는 역할 분담이다. 하나의 이벤트가 쌓였다가 처리되는 단계와 처리 후 여러 곳에 알려지는 단계로 나뉠 때 각 단계에 맞는 서비스를 골라 쓰는 것 같다.
📍 출처: 패스트캠퍼스 강의 - 실전 DevOps의 모든 것
