[Daily morning study] AWS SQS, SNS 차이점과 활용

in Daily morning study / -cloud

#daily morning study

Image

SQS vs SNS 핵심 차이

AWS에서 메시지를 다루는 서비스는 크게 두 가지다. SQS(Simple Queue Service)와 SNS(Simple Notification Service). 이름은 비슷하지만 목적이 다르다.

항목SQSSNS
패턴Point-to-Point (큐)Publish-Subscribe (토픽)
소비자 수1개 소비자가 메시지를 꺼냄여러 구독자에게 동시에 전달
메시지 보존소비 전까지 큐에 보관 (최대 14일)전달 후 보관 없음
재처리가능 (visibility timeout, DLQ)기본적으로 불가
주요 용도작업 큐, 비동기 처리이벤트 브로드캐스트, 알림

SQS 상세

동작 방식

생산자(Producer)가 큐에 메시지를 넣으면, 소비자(Consumer)가 꺼내서 처리하고 삭제하는 구조다.

Producer → [SQS Queue] → Consumer (poll 방식)

소비자는 ReceiveMessage API를 호출해서 메시지를 가져온다. 메시지를 꺼낸 즉시 다른 소비자에게는 보이지 않게 되는데, 이 시간이 Visibility Timeout이다. 처리 완료 후 DeleteMessage를 호출해야 큐에서 완전히 제거된다.

큐 타입

Standard Queue

  • 높은 처리량 (초당 거의 무제한)
  • 메시지 순서 보장 없음 (At-Least-Once, Best-Effort Ordering)
  • 중복 전달 가능

FIFO Queue

  • 메시지 순서 보장 (First-In-First-Out)
  • 정확히 한 번 처리 (Exactly-Once Processing)
  • 초당 최대 3,000 TPS (배치 사용 시), 300 TPS (개별 메시지)
  • 큐 이름이 .fifo로 끝나야 함

Dead Letter Queue (DLQ)

처리 실패한 메시지가 계속 쌓이는 걸 막기 위해 DLQ를 설정한다. maxReceiveCount를 초과하면 메시지가 DLQ로 이동한다.

{
  "deadLetterTargetArn": "arn:aws:sqs:us-east-1:123456789:my-dlq",
  "maxReceiveCount": 3
}

Long Polling vs Short Polling

  • Short Polling: 큐에 메시지가 없어도 즉시 빈 응답 반환 → 비용 낭비
  • Long Polling: 메시지가 올 때까지 최대 20초 대기 → 비용 절감, 권장

WaitTimeSeconds를 1~20 사이로 설정하면 Long Polling이 활성화된다.

SNS 상세

동작 방식

게시자(Publisher)가 토픽에 메시지를 발행하면, 해당 토픽을 구독한 모든 구독자에게 동시에 전달한다. 구독자는 SQS, Lambda, HTTP/S 엔드포인트, 이메일, SMS, 모바일 푸시 등 다양하다.

Publisher → [SNS Topic] → SQS Queue
                        → Lambda Function
                        → HTTP Endpoint
                        → Email / SMS

필터 정책 (Filter Policy)

특정 구독자가 모든 메시지를 받는 게 아니라, 자신에게 필요한 메시지만 받도록 필터링할 수 있다.

예를 들어, 주문 이벤트를 발행할 때:

{
  "event_type": ["order_created", "order_shipped"]
}

이런 필터를 설정하면 해당 타입의 메시지만 해당 구독자에게 전달된다.

FIFO SNS

SNS도 FIFO 타입이 있다. 구독자로는 FIFO SQS만 허용된다. 메시지 그룹 ID를 통해 그룹 내 순서가 보장된다.

Fanout 패턴

SNS + SQS를 조합하면 Fanout 패턴을 구현할 수 있다. 하나의 이벤트를 여러 서비스가 독립적으로 처리해야 할 때 유용하다.

[이벤트 발생]
     ↓
 [SNS Topic]
  /    |    \
SQS-A SQS-B SQS-C
  ↓     ↓     ↓
서비스A 서비스B 서비스C

예를 들어 “주문 완료” 이벤트 하나로:

  • 재고 서비스 → 재고 차감
  • 알림 서비스 → 이메일 발송
  • 분석 서비스 → 데이터 적재

세 가지 작업을 동시에 비동기로 처리할 수 있다. 각 SQS가 독립적으로 소비하므로 서비스 간 결합도가 낮아진다.

비교 정리: 언제 뭘 쓸까?

SQS를 선택할 때

  • 작업 큐가 필요할 때 (이미지 리사이징, 이메일 발송 큐 등)
  • 처리 실패 시 재시도가 필요할 때
  • 소비자가 처리 속도를 직접 제어해야 할 때
  • 메시지를 반드시 한 번만 처리해야 할 때 (FIFO)

SNS를 선택할 때

  • 하나의 이벤트를 여러 서비스에 브로드캐스트할 때
  • 실시간 알림이 필요할 때 (SMS, 이메일, 푸시)
  • Fanout 패턴으로 이벤트 기반 아키텍처를 구성할 때

같이 쓸 때 (SNS + SQS Fanout)

  • 이벤트를 여러 서비스에 전달하면서, 각 서비스가 자기 페이스에 맞게 처리해야 할 때
  • 구독자 중 하나가 일시 다운돼도 메시지 유실 없이 처리해야 할 때

실전 예시: 주문 처리 시스템

[주문 서비스]
     ↓ Publish
[SNS: order-events]
  ↙       ↓         ↘
SQS-inventory SQS-notification SQS-analytics
  ↓               ↓                  ↓
재고 차감 Lambda  이메일 발송 Lambda   BigQuery 적재 Lambda

각 Lambda는 SQS에서 메시지를 pull하여 처리하고, 실패 시 DLQ로 이동해 알람을 발생시킨다.

요금 비교 (간략)

서비스과금 기준
SQS Standard100만 요청당 약 $0.40
SQS FIFO100만 요청당 약 $0.50
SNS100만 게시당 약 $0.50, 구독 전달은 별도

둘 다 처음 100만 건/월은 무료 티어가 적용된다.

정리

  • SQS: 큐 기반 비동기 처리, 소비자가 pull, 재처리 가능
  • SNS: 토픽 기반 브로드캐스트, 구독자에게 push, 재처리 없음
  • Fanout: SNS → 여러 SQS로 구성해서 각 서비스가 독립 처리
  • FIFO가 필요하면 SQS FIFO 또는 SNS FIFO + SQS FIFO 조합
  • DLQ는 SQS에서 실패 메시지를 안전하게 격리하는 핵심 패턴