SQS란?
SQS(Simple Queue Service)는 AWS에서 제공하는 완전 관리형 메시지 큐 서비스로, 분산 시스템과 애플리케이션 간의 메시지(작업)를 안정적으로 주고받도록 하여 서비스들을 분리(Decoupling)하고 확장성을 높여주는 역할을 한다. SQS는 생산자(Producer)가 보낸 메시지를 Enqueue를 통해 큐에 저장하고, 소비자(Consumer)가 필요할 때 큐에서 그 메시지를 가져가(Dequeue) 처리하는 비동기 방식으로 작업이 이루어진다.
SQS의 작동 방식
위 그림은 AWS SQS의 작동 방식이다. 맨 왼쪽의 Producer는 메시지를 제공하는 쪽이다. 즉, 메시지를 큐에 넣는 쪽을 producer라고 한다. 이렇게 큐에 들어간 메시지는 설정에 따라 서버사이드 암호화(SSE-SQS 또는 SSE-KMS)로 안전하게 저장되며, Consumer가 폴링(Polling)을 통해 메시지를 가져가는 방식으로 처리된다.
Consumer가 메시지를 가져가면 SQS는 일정 시간 동안 해당 메시지를 다른 Consumer에게 보이지 않게 숨기는데, 이를 Visibility Timeout이라고 한다. Consumer가 Visibility Timeout 안에 처리를 끝내고 DeleteMessage를 호출하면 메시지는 큐에서 제거되어 ‘처리 완료’로 확정된다. 반대로 시간 안에 삭제되지 않으면 메시지는 다시 보이게 되어 재시도 흐름으로 들어가며, 이 특성 때문에 컨슈머는 중복 처리 가능성을 전제로 설계해야 한다.
SQS의 특징과 장단점
<특징>
- DLQ(Dead Letter Queue): 여러 번 실패한 메시지를 별도로 모아 원인 분석 및 재처리에 활용할 수 있다.
- Long Polling 및 Batch 처리를 지원하여 비용/성능 최적화에 유리하다.
- 메시지 보관 기간(retention)은 기본 4일이며, 최대 14일까지 설정할 수 있다.
- 요청-응답을 분리하는 비동기 처리 구조에 적합하다.
<장점>
- 내구성/신뢰성 : 메시지는 높은 내구성으로 저장되어 유실 위험이 낮고, 처리 실패 메시지는 DLQ로 분리할 수 있다. 다만(Standard Queue 기준) 중복 수신이 발생할 수 있어 멱등성(Idempotency) 처리가 필요하다.
- 보안성 : SQS는 서버사이드 암호화(SSE)를 지원하며, 옵션에 따라 SSE-SQS 또는 SSE-KMS를 선택할 수 있다.
또한 IAM 정책으로 생산자/소비자 권한을 세밀하게 제어할 수 있어 접근 통제가 용이하다.
<단점>
- 메시지의 최대 크기가 256KB로 제한되어 있다.
- 메시지의 보관 기한은 최대 14일로 제한이 있다.
- 폴링 기반이라 비용/지연 튜닝이 필요하다.
- ReceiveMessage(롱폴링), 배치 사이즈/주기, Visibility Timeout을 잘못 잡으면 불필요한 비용이 증가하고, 지연이 생길 수 있다. 특히, Visibility Timeout을 너무 짧게 잡으면 처리 중인 메시지가 다시 나타나 중복 처리/재시도가 늘고, 너무 길게 잡으면 장애 시 복구가 늦어져 지연이 커질 수 있다.
그럼 언제 sqs가 잘 맞나?
이메일/알림/배치 작업/로그 처리/비동기 결제 후처리/크롤링 작업 등에 적합하다. 이 중에서 우리 서비스에서는 알림톡을 구현하는 데에 sqs를 이용하기로 하였다.
왜 알림톡에 sqs가 좋은가?
- 알림톡은 "요청-응답" 흐름이 아니라 이벤트가 생긴 후에 전달되어도 되는 작업이고, 외부 알림 시스템이 불안정하더라도 우리 서비스에 문제가 생기는 경우가 적기 때문이다. 예시로 쉽게 설명하자면, 이메일 smtp나 카카오 알림톡 벤더 api 등에 문제가 있더라도, sqs와 외부 알림 시스템은 비동기적으로 처리되기 때문에 메시지는 안전하게 큐에 저장되어 있고, 컨슈머가 재시도하면서 외부 알림 시스템이 회복될 때 정상적으로 처리된다.
- 트래픽 스파이크를 흡수하기 좋다. 우리 서비스는 특정 시간에 알림이 몰릴 것으로 예상되기때문에 sqs의 이런 특징과 잘 맞다. 동기 구조에서는 피크 때 요청이 다 같이 몰려서 서버/DB/외부 API가 터지기 쉬운데, SQS는 일단 큐에 쌓아두고 컨슈머 수를 늘려서 처리량을 맞출 수 있다.
- 재시도/실패 분리(DLQ)가 알림이랑 잘 맞다. 알림 하나가 실패했다고 해서 전체 서비스를 실패로 만들 필요 없이 실패한 것들은 DLQ로 분리해 두고 추후에 원인 분석 및 재처리가 가능하다.
이런 이유들로 우리 서비스에서는 특정 이벤트 발생 시에 고객들에게 해당 내용을 알림톡으로 발송해 주기 위한 모듈을 개발하는 데에 AWS SQS를 사용하기로 하였다.
sqs를 안 쓰면 뭘 쓸 수 있나? 그중에서 sqs를 선택한 이유?
- sqs를 대체할만한 방법으로는 DB Outbox 패턴, Amazon MQ, Redis 기반 큐 등이 있는데,
이 중 대표적인 예시인 DB Outbox 패턴과 sqs를 비교해 보자면, DB Outbox 패턴은 인프라 추가 없이 DB만으로 "큐/보관/재시도"를 구현할 수 있지만, 이는 큐를 직접 운영하는 것과 같기 때문에 락/폴링/성능 설계를 직접 해야 한다는 단점이 있다. 따라서 우리 서비스에서는 구현 및 운영 비용을 절감할 수 있고 안정성이 높은 SQS를 선택하였다.
SMS가 아니라 알림톡을 선택한 이유 : 알림톡 / SMS 비용 차이
※ 단가는 대행사, 월 발송량 구간, 부가세 포함 여부에 따라 달라질 수 있으며 아래는 일반적인 경향을 설명하기 위한 예시이다.
- 대행사마다 다르지만 일반적으로 알림톡은 건당 약 7원 정도, SMS(단문)은 10원 이상이고, 긴 내용을 보내기 위해 LMS를 이용해야 한다면 건당 30원 이상 드는 경우가 많다. 따라서 우리 서비스에서는 SMS가 아니라 알림톡을 이용하면 비용 절감을 이룰 수 있다고 판단하여 AWS SQS를 이용한 알림톡 모듈을 개발하기로 하였다.