본문 바로가기
인프라 · 데브옵스

메시징·스트리밍 인프라 비교 — Amazon SQS·SNS, Apache Kafka, Amazon MSK, RabbitMQ

코딩패트릭 2026. 7. 26.

이 문서의 모든 정의와 특성은 각 제품의 공식 문서에 근거한다. 근거가 없는 주장은 싣지 않으며, 인용한 출처는 마지막 참고 절에 정리한다.

먼저 큰 그림부터. 다섯 기술은 크게 두 계열로 나뉘고, 이 구분이 나머지 모든 차이의 출발점이다.

  • 큐·메시지 브로커 계열 — 메시지를 소비자에게 전달하고, 정상 처리(ack)되면 흘려보낸다. SQS, RabbitMQ가 여기 속한다.
  • 로그(이벤트 스트리밍) 계열 — 이벤트를 로그에 append해 보존 기간 동안 남기고, 소비자가 offset으로 반복해 읽는다. Kafka, Amazon MSK가 여기 속한다.
  • SNS는 위 둘과 결이 다른 pub/sub 알림으로, 발행한 메시지를 여러 구독 대상에 팬아웃한다.
[ 큐·브로커 계열 ]                 [ 로그(스트리밍) 계열 ]
 Producer                          Producer
    │                                 │  append
    ▼                                 ▼
 ┌───────────────┐                 ┌───────────────┐
 │ SQS · RabbitMQ│ ─▶ Consumer     │  Kafka · MSK  │
 └───────────────┘                 └───────────────┘
  처리(ack)되면 흘려보냄             │           │
                                 Consumer    Consumer
                                 (각자 offset으로 반복·재생 replay)

[ pub/sub(알림) 계열 ]
 Producer ─▶ ┌─────┐ ─┬─▶ SQS
             │ SNS │  ├─▶ Lambda
             └─────┘  └─▶ HTTP / e-mail / SMS   (팬아웃)

1. 각 기술은 무엇이고 어떻게 쓰나

Amazon SQS (Simple Queue Service)

AWS는 SQS를 "마이크로서비스·분산 시스템·서버리스 애플리케이션을 위한 완전 관리형 메시지 큐잉" 서비스로 정의한다. 통신 모델은 풀(pull) 기반으로, 소비자가 큐를 폴링해서 메시지를 가져간다. 메시지는 소비되거나 만료될 때까지 큐에 보존되며, 최소 1회(at-least-once) 전달을 보장한다. FIFO 큐를 쓰면 엄격한 순서가 보장된다.

  • 쓰는 방식: 생산자가 큐에 메시지를 넣고(SendMessage), 소비자(EC2·Lambda 등)가 큐에서 꺼낸다(ReceiveMessage). 처리를 마친 뒤 소비자가 DeleteMessage를 호출해야 큐에서 삭제되며, 삭제 전까지는 visibility timeout 동안 다른 소비자에게 보이지 않는다. 처리에 실패해 삭제하지 않으면 타임아웃 뒤 다시 전달된다.
  • 대표 용도(공식): 마이크로서비스 디커플링, 요청 버퍼링, 비동기 작업 처리.

Amazon SNS (Simple Notification Service)

AWS는 SNS를 "고가용·내구성·보안을 갖춘 pub/sub 메시징" 서비스로 정의한다. 통신 모델은 푸시(push) 기반으로, 발행된 메시지가 구독자에게 실시간으로 전달된다. 메시지를 장기간 저장하지 않으며, 전달이 끝난 뒤 재생(replay)을 위한 로그를 남기지 않는다. 구독자로는 HTTP/S 엔드포인트·이메일·SMS·모바일 푸시·Lambda·SQS 큐를 지원한다.

  • 쓰는 방식: 토픽(topic)을 만들고 구독자를 등록한 뒤, 토픽에 메시지를 발행하면 등록된 모든 구독 대상으로 팬아웃 전달된다.
  • 대표 용도(공식): 팬아웃 알림, pub/sub 메시징, 모바일 푸시 알림. 실무에서는 SNS로 팬아웃하고 각 SQS 큐가 받는 SNS+SQS 조합이 자주 쓰이며, AWS도 이를 공식 튜토리얼로 제공한다.

Apache Kafka

Kafka는 공식적으로 "고성능 데이터 파이프라인, 스트리밍 분석, 데이터 통합, 미션 크리티컬 애플리케이션에 쓰이는 오픈소스 분산 이벤트 스트리밍 플랫폼" 으로 정의된다. 2011년 LinkedIn에서 처음 만들어졌다. SQS·RabbitMQ 같은 큐·브로커 계열과 근본적으로 다른 점은, Kafka가 분산 로그(log) 구조라는 것이다. 메시지는 소비된다고 사라지지 않고 설정된 보존 기간 동안 디스크에 남아, 여러 소비자가 각자의 오프셋(offset)으로 반복해서 읽거나 다시 읽을(replay) 수 있다.

  • 쓰는 방식: 프로듀서가 토픽(파티션)에 이벤트를 append하고, 컨슈머 그룹이 파티션을 나눠 읽는다. 소비 위치(offset)는 소비자가 관리하며, 일반적으로 Kafka가 이를 __consumer_offsets 토픽에 저장한다. 덕분에 재처리·다중 소비가 자연스럽다.
  • 대표 용도: 실시간 데이터 파이프라인, 스트리밍 분석, 데이터 통합.

Amazon MSK (Managed Streaming for Apache Kafka)

MSK는 Apache Kafka 인프라와 운영을 대신 관리해 주는 완전 관리형 스트리밍 서비스다. 즉 Apache Kafka를 그대로 실행하되(애플리케이션은 동일한 Kafka API·클라이언트를 사용한다), 클러스터 구성·유지보수·확장·장애 복구를 AWS가 맡는다. Kafka를 직접 운영할 때의 운영 복잡성을 줄이는 것이 핵심이다.

  • AWS가 제공하는 것: 자동 클러스터 운영·유지보수·확장, 엔터프라이즈급 보안, 다중 AZ 배포, 인프라 장애 자동 감지·복구.
  • 대표 용도(공식): 로그·이벤트 수집, 중앙 데이터 버스, 이벤트 기반 시스템.
  • 참고로 MSK Express 브로커는 표준 Kafka 브로커 대비 3배 처리량, 20배 빠른 확장을 제공한다고 AWS가 밝힌다.

RabbitMQ

RabbitMQ는 "분산 마이크로서비스·실시간 데이터·IoT에 적합한, 엔터프라이즈급 오픈소스 메시징·스트리밍 브로커" 로 소개된다. AMQP 1.0·MQTT 5.0 등 여러 개방형 표준 프로토콜을 지원하는 것이 특징이다. 익스체인지(exchange)–큐 구조를 통한 유연한 라우팅이 강점인 엔터프라이즈 메시지 브로커다. 다만 여기서의 "스트리밍"은 Kafka식 로그 기반 스트리밍과 같은 개념이 아니라는 점에 유의해야 한다.

  • 쓰는 방식: 프로듀서가 익스체인지로 메시지를 보내고, 라우팅 규칙에 따라 큐로 분배되며, 컨슈머가 큐에서 소비한다. 소비자가 ack하지 않거나 nack하면 재전달(redelivery)되고, 실패 메시지는 dead-letter 큐로 보낼 수 있다.
  • 정의상 위치: 프로토콜 기반의 범용 메시지 브로커로, 특정 클라우드에 종속되지 않는다.

2. 공통점

다섯 기술(SQS·SNS / Kafka·MSK / RabbitMQ)은 모두 비동기 메시징으로 시스템 컴포넌트를 느슨하게 결합(decoupling) 하기 위한 인프라다. AWS 역시 SQS·SNS를 "컴포넌트 디커플링" 목적의 서비스로 설명한다. 공통적으로 다음을 제공한다.

  • 생산자와 소비자를 직접 호출로 묶지 않고 중간 계층을 통해 비동기로 통신한다.
  • 트래픽 급증을 버퍼링하거나 팬아웃해 뒤단 시스템을 보호한다.
  • 수평 확장을 전제로 설계되어 높은 처리량을 지향한다.

3. 핵심 차이

가장 중요한 축은 "메시지를 소비 후에도 보존해 재생(replay)할 수 있는가" 이다. 이것이 큐·브로커 계열과 로그(스트리밍) 계열을 가른다.

  • 메시징 모델
    • SQS: 큐, 풀 기반
    • SNS: pub/sub, 푸시 기반
    • Kafka·MSK: 분산 로그 기반 이벤트 스트리밍
    • RabbitMQ: 익스체인지–큐 라우팅 기반 메시지 브로커
  • 재생(replay)과 재전달(redelivery)은 다르다
    • 재생(replay) — 이미 처리한 과거 메시지를 오프셋을 되돌려 다시 읽는 것. Kafka·MSK만 지원한다(보존 기간 내). SQS·SNS·RabbitMQ는 지원하지 않는다.
    • 재전달(redelivery) — 처리에 실패한 메시지를 다시 전달하는 것. SQS(삭제 전 타임아웃)·RabbitMQ(nack/requeue·dead-letter)는 지원한다. 이는 replay와 구분해야 한다.
  • 메시지 보존
    • SQS는 소비자가 DeleteMessage를 호출하기 전까지(또는 만료 전까지) 큐에 남고, SNS는 재생용 로그를 남기지 않는다.
    • Kafka는 보존 기간 동안 로그에 남아 여러 번 읽을 수 있다.
  • 운영 방식
    • SQS·SNS·MSK는 AWS 완전 관리형이라 인프라를 직접 운영하지 않는다.
    • Kafka와 RabbitMQ는 주로 직접 운영하지만, 관리형 옵션도 존재한다(예: RabbitMQ는 Amazon MQ 등). MSK는 바로 이 Kafka 운영 부담을 AWS가 대신 지는 형태다.
  • 종속성
    • SQS·SNS·MSK는 AWS 서비스라 AWS 환경에 종속된다.
    • Kafka·RabbitMQ는 오픈소스로 클라우드·온프레미스 어디서든 구동된다.

4. 어떤 상황에 무엇을 도입할까

아래 기준은 AWS 공식 결정 가이드와 각 제품의 공식 용도 설명에 근거한다.

  • 비동기 작업 처리·요청 버퍼링·마이크로서비스 디커플링이 목적이고 AWS를 쓴다면 → Amazon SQS. AWS가 명시한 SQS의 대표 용도가 정확히 이것이다.
  • 하나의 이벤트를 여러 구독 대상에 팬아웃(알림)하는 것이 목적이라면 → Amazon SNS (필요하면 SNS+SQS 조합).
  • 로그·이벤트를 대량으로 수집하고, 재생(replay)·스트리밍 분석·중앙 데이터 버스가 필요하다면 → Apache Kafka. 이는 Kafka의 공식 대표 용도이며, AWS도 MSK의 용도로 로그·이벤트 수집과 중앙 데이터 버스를 든다.
  • 위 Kafka가 필요하지만 클러스터를 직접 운영하고 싶지 않고 AWS를 쓴다면 → Amazon MSK. MSK의 존재 이유가 Kafka 운영 복잡성 제거다.
  • 특정 클라우드에 묶이지 않는 범용 메시지 브로커가 필요하거나, AMQP·MQTT 같은 표준 프로토콜과 유연한 라우팅이 필요하다면 → RabbitMQ.

5. 한눈에 보는 비교

항목 Amazon SQS Amazon SNS Apache Kafka Amazon MSK RabbitMQ
유형 메시지 큐 pub/sub 알림 이벤트 스트리밍(로그) 관리형 Kafka 메시지 브로커
통신 모델 풀(폴링) 푸시(팬아웃) 로그 append/구독 로그 append/구독 익스체인지→큐
메시지 보존 삭제/만료 전까지 재생용 로그 없음 보존 기간 동안 유지 보존 기간 동안 유지 소비(ack) 전까지
재생(replay) 미지원 미지원 지원 지원 미지원
재전달(redelivery) 지원 재시도 있음 오프셋 재조정으로 대체 동일 지원
순서 보장 FIFO 큐 FIFO 토픽 파티션 단위 파티션 단위 큐 단위
운영 방식 AWS 관리형 AWS 관리형 주로 자체 운영 AWS 관리형 주로 자체 운영(관리형도 있음)
구동 환경 AWS 전용 AWS 전용 클라우드·온프레미스 AWS 전용 클라우드·온프레미스
대표 용도 디커플링·버퍼링·비동기 팬아웃·알림 스트리밍·데이터 파이프라인 관리형 스트리밍 범용 메시징·라우팅

표 용어 주의 — "재생(replay)"은 과거 메시지를 오프셋을 되돌려 다시 읽는 것으로 Kafka·MSK만 지원한다. "재전달(redelivery)"은 처리 실패 메시지를 다시 보내는 것으로, replay 미지원 서비스도 대부분 제공한다. 각 셀은 본문에서 인용한 공식 문서의 서술을 요약한 것이며, 자세한 출처는 아래 참고 절을 보라.

참고

'인프라 · 데브옵스' 카테고리의 다른 글

Socket이 대체 뭔가 "소켓" Socket 이라는 개념 완벽 파헤치기  (0) 2026.08.05

관련 글

티스토리툴바