[MQ]메시지 큐 3개 비교: Amazon SQS vs Apache Kafka vs RabbitMQ

비동기 메시지 처리와 마이크로서비스 통신이 일반화되면서, **메시지 큐(MQ)**는 필수 인프라가 되었습니다.

그중에서도 가장 널리 사용되는 세 가지:

 

• ☁️ Amazon SQS
• 🪵 Apache Kafka
• 🐇 RabbitMQ

 

이 글에서는 이 세 가지 MQ 시스템을 기능, 구조, 사용 목적, 실무 적용 방식 기준으로 정리하고 비교합니다.

 

---

🧾 기본 개요 비교

 

항목	Amazon SQS	Apache Kafka	RabbitMQ
설계 목적	완전 관리형 큐	대용량 스트리밍	유연한 라우팅 기반 큐
메시지 저장 방식	Queue	로그 (토픽/파티션)	Queue (Exchange 기반)
프로토콜	HTTP(S)	자체 프로토콜	AMQP (표준)
설치 방식	AWS 관리형	직접 설치 (또는 클라우드)	직접 설치 (또는 클라우드)

 

---

 

📦 메시지 처리 구조 비교

항목	Amazon SQS	Apache Kafka	RabbitMQ
처리 모델	메시지 소비 후 삭제	로그 유지 후 offset 기반 소비	큐에서 메시지 수신 후 삭제
메시지 순서	FIFO 큐에서만 보장	파티션 단위 순서 보장	기본 FIFO
중복 처리	가능성 있음 (At-least-once)	중복 없음 (offset 기반)	중복 가능 (ack 누락 시 재전송)
재처리 방식	VisibilityTimeout + DLQ	offset 미커밋 시 재수신	ack/nack 기반 재처리 or DLX

 

---

 

⚙️ 실패 처리 및 재시도 비교

 

항목	Amazon SQS	Apache Kafka	RabbitMQ
재시도 방식	VisibilityTimeout 후 자동 재전송	offset 유지 시 재시도	nack + requeue
실패 메시지 저장	DLQ (Dead Letter Queue)	DLT (Dead Letter Topic)	DLX (Dead Letter Exchange)
재시도 제어	최대 재시도 횟수 + DLQ	RetryTopic 직접 구현	TTL + DLX 조합 가능

 

---

🚀 실무 특화 기능 요약

항목	Amazon SQS	Apache Kafka	RabbitMQ
서버리스 연동	✅ Lambda 등과 매우 강력	❌ 직접 구현 필요	⚠️ 연동 가능하지만 복잡
대용량 처리	⚠️ 큐 기반 한계 있음	✅ 대용량 스트리밍 최적	⚠️ 성능 한계 존재
라우팅 유연성	❌ 없음	❌ 없음	✅ Exchange 라우팅 다양
순서 보장 처리	FIFO 큐에서만 가능	파티션 내부만 순서 보장	기본 순서 보장
메시지 보존 기간	기본 4일 (최대 14일)	기본 7일 이상 (로그 유지)	수신 전까지 보존

 

---

📌 각 시스템의 핵심 사용 포인트

☁️ Amazon SQS – “서버리스, 관리형 큐가 필요하다면”

• 운영 걱정 없이 빠르게 도입 가능
• Lambda, ECS, EventBridge 등 AWS 서비스와 쉽게 연동
• 재시도, DLQ, 가시성 제한 등 내장 기능 풍부

🪵 Apache Kafka – “대용량 스트리밍 + 재처리가 필요하다면”

• 이벤트 소싱, 로그 수집, 데이터 파이프라인 등 대규모 처리에 적합
• 메시지를 삭제하지 않기 때문에 재처리, 분석, CDC 등에 탁월
• offset 기반으로 각 소비자가 원하는 위치에서 소비 가능

🐇 RabbitMQ – “정밀한 라우팅과 메시지 흐름 제어가 필요하다면”

• 다양한 Exchange 타입 (Direct, Topic, Fanout)으로 복잡한 메시지 분기 가능
• 수동 ack/nack, TTL, DLX 등 메시지 흐름 커스터마이징이 뛰어남
• Task Queue, Microservice 이벤트 전달 등 전통적인 MQ 용도에 강력

 

---

✅ 마무리: 언제 어떤 MQ를 써야 할까?

목적/상황	추천 시스템
빠르게 구성할 관리형 메시지 큐가 필요하다	☁️ Amazon SQS
대규모 데이터 스트리밍, 로그 수집, 재처리가 필요하다	🪵 Apache Kafka
서비스 간 세밀한 메시지 라우팅과 흐름 제어가 필요하다	🐇 RabbitMQ