정정지용
기술스택 목록
인프라

AWS SQS

프로젝트 1개에서 사용했습니다. 각 프로젝트에서 어떤 역할로 썼는지 아래에 정리했습니다.

이 기술은 무엇인가요?

AWS 인프라 안에서 메시지를 안전하게 전달하는 완전관리형 메시지 큐 서비스

SQS는 서비스나 애플리케이션 컴포넌트 사이에서 메시지를 주고받을 수 있게 해주는 AWS의 완전관리형 큐 서비스이다. 생산자(producer)와 소비자(consumer)를 직접 연결하지 않고 큐를 중간에 두어, 두 컴포넌트가 서로의 가용성이나 처리 속도에 영향받지 않고 독립적으로 동작하도록 만드는 것이 목적이다. 서버 운영이나 큐 인프라 관리를 직접 하지 않아도 되며, 트래픽이 몰릴 때는 메시지를 큐에 쌓아두었다가 소비자가 처리 가능한 속도로 꺼내가는 방식으로 시스템 전체의 부하를 완충한다.

이럴 때 사용합니다

  • 서비스 간 작업을 비동기로 처리해 요청 처리와 실제 작업을 분리하고 싶을 때
  • 트래픽 급증 시 메시지를 큐에 쌓아 후단 시스템 부하를 완충하고 싶을 때
  • 직접 큐 서버를 운영하지 않고 관리형 서비스로 안정성과 확장성을 확보하고 싶을 때
  • 여러 워커가 동시에 작업을 나눠 처리하는 분산 작업 큐 구조가 필요할 때

핵심 개념

Queue
메시지가 저장되는 논리적 공간으로, 표준 큐와 순서를 보장하는 FIFO 큐 두 종류가 있다.
Producer / Consumer
메시지를 큐에 보내는 쪽을 producer, 큐에서 메시지를 꺼내 처리하는 쪽을 consumer라 부른다.
Visibility Timeout
한 consumer가 메시지를 가져간 후 일정 시간 동안 다른 consumer에게는 그 메시지가 보이지 않도록 숨기는 시간으로, 중복 처리를 막는 데 쓰인다.
Polling
consumer가 큐에 새 메시지가 있는지 주기적으로 확인해 가져오는 방식이며, 대기 시간을 두어 불필요한 요청을 줄이는 롱 폴링을 지원한다.
Dead Letter Queue (DLQ)
정해진 횟수만큼 처리에 실패한 메시지를 별도로 보관해, 원인 분석과 재처리를 할 수 있게 하는 보조 큐이다.
At-least-once Delivery
메시지가 최소 한 번은 전달됨을 보장하는 전달 방식으로, 드물게 중복 전달이 발생할 수 있어 소비자 로직이 이를 감안해야 한다.

AWS CLI로 큐 생성 후 메시지 전송/수신

큐를 만들고 작업 정보를 담은 메시지를 넣은 뒤, 워커가 이를 꺼내가는 기본 흐름을 보여준다.

Shell
# 큐 생성
aws sqs create-queue --queue-name my-task-queue

# 메시지 전송
aws sqs send-message \
  --queue-url https://sqs.ap-northeast-2.amazonaws.com/123456789012/my-task-queue \
  --message-body '{"job":"resize-image","id":42}'

# 메시지 수신 (롱 폴링)
aws sqs receive-message \
  --queue-url https://sqs.ap-northeast-2.amazonaws.com/123456789012/my-task-queue \
  --wait-time-seconds 10

처음 쓸 때 흔한 함정

  • 메시지가 중복 전달될 수 있으므로 처리 로직을 멱등하게 설계해야 한다.
  • visibility timeout을 작업 처리 시간보다 짧게 두면 같은 메시지가 여러 워커에게 중복 처리될 수 있다.
  • 표준 큐는 메시지 순서를 보장하지 않으므로 순서가 중요하면 FIFO 큐를 선택해야 한다.

위 개요는 기술 학습을 돕기 위해 자동 생성된 일반 설명입니다. 정확한 사양과 최신 정보는 공식 문서를 확인하세요.

프로젝트별 활용 방식

위 개념이 실제 프로젝트에서 어떻게 쓰였는지 보여줍니다.

함께 사용한 기술

위 프로젝트들에서 같이 쓰인 다른 기술입니다.

ArgoCDJenkinsKafkaKubernetesKustomizePostgreSQLPrometheusRedis