Theory
인프라
AWS
Amazon SQS 큐 비교

Amazon SQS와 Queue 서비스 비교

결론

  • Amazon SQS는 AWS에서 제공하는 완전 관리형 메시지 큐 서비스로, 분산 소프트웨어 시스템과 구성 요소를 통합 및 분리할 수 있습니다 AWS SQS 공식 문서 (opens in a new tab)

AWS 공식 문서에서 "Amazon Simple Queue Service(Amazon SQS)는 내구력 있고 가용성이 뛰어난 보안 호스팅 대기열을 제공하며 이를 통해 분산 소프트웨어 시스템과 구성 요소를 통합 및 분리할 수 있습니다"라고 명시되어 있음.

  • Standard Queue와 FIFO Queue 두 가지 큐 타입을 제공하며, Standard는 최소 1회 전달을 보장하고 FIFO는 정확히 1회 처리를 보장합니다 AWS SQS Features (opens in a new tab)

AWS 공식 문서에서 "Standard queues provide at-least-once delivery, which means that each message is delivered at least once. FIFO queues provide exactly-once processing, which means that each message is delivered once and remains available until a consumer processes it and deletes it"라고 명시되어 있음.

Medium 글에서 "Easiest if you're on AWS – they're fully managed with zero server maintenance"라고 명시되어 있음.

Amazon SQS 상세

메시지 용량 및 확장성

  • 메시지 페이로드는 최대 256KB의 텍스트를 담을 수 있으며, 더 큰 메시지는 Amazon S3를 사용하는 Extended Client Library를 통해 전송할 수 있습니다 AWS SQS Features (opens in a new tab)

AWS 공식 문서에서 "Message payloads can contain up to 256KB of text in any format. To send messages larger than 256KB, you can use the Amazon SQS Extended Client Library for Java, which uses Amazon Simple Storage Service (S3) to store the message payload"라고 명시되어 있음.

Standard Queue vs FIFO Queue

Standard Queue:

  • 최소 1회 전달 보장 (at-least-once delivery)
  • 순서 보장 없음
  • 무제한 처리량
  • 비용 효율적

FIFO Queue:

  • 정확히 1회 처리 보장 (exactly-once processing)
  • 메시지 순서 보장
  • 기본 처리량: 배치 사용 시 초당 3,000개 메시지, 배치 미사용 시 초당 300개 메시지
  • 고처리량 모드: 배치 미사용 시 초당 70,000개 메시지까지 지원 AWS SQS Features (opens in a new tab)

AWS 공식 문서에서 "By default, FIFO queues support up to 3,000 messages per second with batching or up to 300 messages per second without batching. If you require higher throughput, you can enable high throughput mode for FIFO on the Amazon SQS console, which will support up to 70,000 messages per second without batching and even higher with batching"라고 명시되어 있음.

주요 기능

내구성 및 가용성:

위 출처에서 "메시지의 안전을 위해 Amazon SQS는 메시지를 여러 서버에 저장합니다. Amazon SQS는 중복 인프라를 사용하여 메시지에 대한 고도의 동시 액세스와 메시지 생성 및 소비에 대한 고가용성을 제공합니다"라고 명시되어 있음.

보안:

  • 서버 측 암호화(SSE)를 통해 AWS KMS로 관리되는 키를 사용하여 메시지 암호화
  • SQS가 메시지를 수신하는 즉시 암호화 AWS SQS Features (opens in a new tab)

AWS 공식 문서에서 "Server-side encryption (SSE): Protect the contents of messages in Amazon SQS queues using keys managed in the AWS Key Management Service (AWS KMS). SSE encrypts messages as soon as Amazon SQS receives them"라고 명시되어 있음.

Dead Letter Queue (DLQ):

  • 소비자가 성공적으로 처리하지 못한 메시지를 처리하는 기능
  • 최대 수신 횟수를 초과하면 SQS가 메시지를 DLQ로 이동 AWS SQS Features (opens in a new tab)

AWS 공식 문서에서 "Handle messages that a consumer has not successfully processed with dead-letter queues (DLQs). When a message's maximum receive count is exceeded, Amazon SQS moves the message to the DLQ associated with the original queue"라고 명시되어 있음.

활용 패턴

  • Work Queues: 분산 애플리케이션의 컴포넌트를 분리하여 동일한 작업량을 동시에 처리하지 않을 수 있는 경우 사용
  • Buffer and Batch Operations: 아키텍처에 확장성과 안정성을 추가하고, 메시지 손실이나 지연 증가 없이 일시적인 볼륨 급증을 완화
  • Request Offloading: 요청을 큐에 넣어 대화형 요청 경로에서 느린 작업을 이동 AWS SQS Features (opens in a new tab)

AWS 공식 문서에서 "Work Queues: Decouple components of a distributed application that may not all process the same amount of work simultaneously. Buffer and Batch Operations: Add scalability and reliability to your architecture, and smooth out temporary volume spikes without losing messages or increasing latency. Request Offloading: Move slow operations off of interactive request paths by enqueing the request"라고 명시되어 있음.

다른 Queue 서비스 비교

Apache Kafka

  • 특징: 대규모 이벤트 스트리밍을 위한 분산 로그 시스템
  • 장점: 높은 처리량, 장기 저장, 이벤트 재생 가능, 수평 확장 용이
  • 단점: 가장 복잡하며 전문 인력이나 컨설턴트가 필요할 수 있음
  • 적합한 경우: 실시간 분석이나 데이터 파이프라인을 위한 높은 처리량과 이벤트 재생이 필요한 경우 Message Queue Comparison (opens in a new tab)

Medium 글에서 "A distributed log system designed for massive scale and event streaming. Best for high throughput, long-term storage, or event replay for real-time analytics or data pipelines. Most complex, often requiring dedicated expertise and cluster management. Scales horizontally really well (it's built with scalability in mind)"라고 명시되어 있음.

RabbitMQ

  • 특징: AMQP 기반의 메시지 브로커로 복잡한 라우팅 기능 제공
  • 장점: 보장된 전달, 유연한 라우팅, Kafka보다 낮은 운영 복잡도
  • 라우팅: 메시지의 내용, 메타데이터, 발신자, 시간 등 다양한 기준으로 라우팅 결정 가능
  • 확장 방식: 주로 수직 확장
  • 적합한 경우: 이메일 전송, 주문 처리 등 작업의 보장된 전달과 복잡한 라우팅이 필요한 시스템 Message Queue Comparison (opens in a new tab)

Medium 글에서 "The Swiss Army knife of message brokers, built on the Advanced Message Queuing Protocol (AMQP), it offers incredible routing flexibility with lower operational complexity than Kafka. Choose RabbitMQ if you're building a system where tasks (e.g., sending emails, processing orders) need guaranteed delivery and complex routing"라고 명시되어 있음.

Redis

  • 특징: 인메모리 저장소이면서 메시지 브로커로도 사용 가능
  • 장점: 낮은 지연시간, 간단하고 빠른 큐, 캐싱과 함께 사용 가능
  • 단점: Pub/Sub 구현이 fire-and-forget 방식으로 히스토리나 백로그가 없음. 소비자가 없으면 메시지 손실
  • 적합한 경우: 작업량이 적고, 지연시간이 중요하거나, 이미 Redis를 캐싱에 사용 중인 경우 Message Queue Comparison (opens in a new tab)

Medium 글에서 "A lightweight, in-memory store that doubles as a message broker for simple, fast queues. Choose Redis if your workload is small, latency is critical, or you're already using Redis for caching. The Redis Pub/Sub implementation is fairly fire-and-forget as there is no history or backlog. If consumers are not available to consume the message, the message gets lost"라고 명시되어 있음.

AWS SNS (Simple Notification Service)

  • 특징: 여러 구독자에게 메시지를 브로드캐스팅하는 서비스
  • 차이점: SQS는 point-to-point 큐잉을 처리하고, SNS는 여러 구독자에게 브로드캐스팅
  • 장점: SQS와 함께 사용하면 완전 관리형 인프라로 자동 확장과 내구성 제공 Message Queue Comparison (opens in a new tab)

Medium 글에서 "SQS handles point-to-point queuing, while SNS broadcasts to multiple subscribers. Fully managed with no need to manage infrastructure, backed by AWS's infrastructure, offering automatic scaling and durability"라고 명시되어 있음.

Google Cloud Pub/Sub

  • 특징: 실시간 메시징 서비스로 퍼블리셔가 하나 또는 여러 구독자에게 동시에 메시지 전송 가능
  • FIFO 지원: 동일한 ordering key를 가진 메시지가 같은 리전에 게시되면 메시지 순서 보장 가능
  • 중복 제거: 게시된 메시지의 자동 중복 제거를 best-effort 기반으로 제공 GCP Pub/Sub vs Amazon SQS vs Azure Service Bus (opens in a new tab)

Medium 글에서 "GCP Pub/Sub is a fully-managed, real-time messaging service that allows publishers to send messages to one or many subscribers simultaneously. If messages have the same ordering key and are published to the same region, you can enable message ordering and receive the messages in the order that the Pub/Sub service receives them. Pub/Sub provides automatic deduplication of published messages on a best-effort basis"라고 명시되어 있음.

Azure Service Bus

  • 특징: Microsoft Azure의 메시징 서비스
  • FIFO 지원: FIFO 큐가 메시지가 전송된 순서대로 처리됨을 보장
  • 메시지 그룹화: 세션을 사용하여 동일한 세션 ID를 가진 메시지를 순서대로 처리 가능
  • 중복 제거: 내장 중복 제거 기능이 없으며, 필요한 경우 애플리케이션 레벨에서 처리 필요 GCP Pub/Sub vs Amazon SQS vs Azure Service Bus (opens in a new tab)

Medium 글에서 "Azure Service Bus FIFO queues guarantee that messages are processed in the order they were sent. Azure Service Bus does not have a concept of message groups. However, you can achieve similar functionality by using sessions, where messages with the same session ID are processed in order. Azure Service Bus FIFO queues do not have built-in message deduplication features. If you need to prevent duplicates, you would need to handle it at the application level"이라고 명시되어 있음.

Queue 서비스 선택 가이드

Amazon SQS를 선택하는 경우

  • AWS 환경을 사용 중이며 인프라 관리를 최소화하고 싶을 때
  • Standard Queue로 높은 처리량이 필요하거나, FIFO Queue로 순서 보장이 필요할 때
  • 간단한 큐잉 시스템이 필요할 때

Apache Kafka를 선택하는 경우

  • 대규모 이벤트 스트리밍과 실시간 분석이 필요할 때
  • 이벤트 재생과 장기 저장이 필요할 때
  • 전문 인력을 투입할 수 있는 경우

RabbitMQ를 선택하는 경우

  • 복잡한 라우팅 로직이 필요할 때
  • 메시지 전달 보장이 중요할 때
  • 오픈소스 솔루션을 선호하며 Kafka보다 낮은 복잡도를 원할 때

Redis를 선택하는 경우

  • 낮은 지연시간이 가장 중요할 때
  • 작업량이 적고 간단한 큐가 필요할 때
  • 이미 Redis를 캐싱에 사용 중일 때

비용 및 복잡도

  • RabbitMQ와 Apache Kafka는 오픈소스 프로젝트로 라이선스 비용이 없습니다
  • Apache Kafka는 설정과 운영에 어려움이 있어 전담 인력이나 컨설턴트 고용이 필요할 수 있습니다 Message Queue Comparison (opens in a new tab)

위 출처에서 "Both RabbitMQ and Apache Kafka are open source projects that don't require licensing fees for usage. However, Apache Kafka can present challenges when it comes to setup and operation that might mean that you need to hire dedicated staff or consultants to manage and administer deployment"라고 명시되어 있음.

출처

Sentinel(공식문서 번역)Functions Python Guide