Amazon SQS와 SNS

Overview

SQS는 Consumer가 Message를 가져가 처리하는 Queue이고, SNS는 하나의 Message를 여러 Subscriber에게 Push하는 Topic이다. SNS → 여러 SQS Queue 구조를 사용하면 Event를 각 Consumer 업무별로 독립 보관하고 처리할 수 있다.

핵심 원리

SQS Consumer가 Message를 받으면 Visibility Timeout 동안 다른 Consumer에게 보이지 않는다. 처리가 끝나면 삭제해야 하며, 실패하거나 Timeout이 지나면 다시 나타날 수 있다. 따라서 Consumer는 중복 실행에 안전해야 한다.

flowchart LR; A[Publisher] --> B[SNS Topic]; B --> C1[SQS 주문 Queue]; B --> C2[SQS 알림 Queue]; C1 --> D1[주문 Worker]; C2 --> D2[알림 Worker]; C1 --> E1[DLQ]; C2 --> E2[DLQ]

Standard와 FIFO

Standard Queue는 높은 처리량과 At-least-once 전달을 전제로 한다. FIFO Queue는 Message Group 안의 순서와 중복 제거 기능을 제공하지만, Business 부작용의 Exactly-once까지 자동 보장한다고 이해하면 안 된다.

실패 처리

• 처리 시간보다 Visibility Timeout이 짧으면 같은 Message가 동시에 다시 처리될 수 있다.
• 반복 실패 Message는 Redrive 정책으로 DLQ에 보낸다.
• DLQ 적재 이유, 재처리 절차, 원본 Message Version 호환을 운영 Runbook에 둔다.
• Message ID만 믿기보다 Business Idempotency Key와 처리 결과 저장을 설계한다.

Trade-off

생산자와 소비자의 시간·장애 경계를 분리하지만 즉시 일관성을 잃고, 중복·순서·재처리·관찰 가능성을 Application에서 다뤄야 한다.

흔한 오해

• FIFO를 쓰면 모든 Business 처리의 Exactly-once가 저절로 보장되는 것은 아니다.
• DLQ는 자동 복구 장치가 아니라 격리와 조사 장치다.
• SNS만 사용하면 Offline Consumer를 위한 독립적인 Queue 보관이 생기지 않는다.

Interview Questions

1. Visibility Timeout이 Consumer 처리 시간보다 짧으면 무슨 일이 생기는가?
2. SNS → SQS Fan-out을 직접 HTTP 호출과 비교하면 어떤 장단점이 있는가?
3. DLQ Message를 안전하게 재처리하려면 무엇이 필요한가?
4. FIFO의 Deduplication과 Business Idempotency는 어떻게 다른가?

Related Topics

비동기 처리 설계에서 Executor와 Durable Queue의 선택 기준을 확인하고, Kafka와 Delivery/Storage Model을 비교하며 부하 테스트로 Queue 적체와 Consumer 확장 조건을 검증한다.