메세징 플랫폼 비교

메시징 플랫폼을 선택할 때, 각 제품의 특징, 장단점을 비교하여 선택에 도움이 될 수 있도록 비교해 보았어요.
차후에 블로그를 통해 각 제품들의 자세한 내용들을 적어보려 해요.

특징	SQS	SNS	Kafka	RabbitMQ	Redis Pub/Sub
오픈소스	-	-	오픈소스	오픈소스	오픈소스
브로커 구분	메시지 브로커	메시지 브로커	이벤트 브로커	메시지 브로커	메시지 브로커
Queue/Topic	Queue	Topic	Topic	Queue	Channel
동기/비동기	둘 다 가능	비동기	비동기	둘 다 가능	비동기
메시지 전달 보장 수준	At least once(Standard), Exactly once(FIFO)	메시지 전달 후 삭제하기 때문에 상실 가능	At most once, At least once, Exactly once	At most once, At least once	At most once
메시지 순서 보장 수준	Standard - Best effort, FIFO - 순서 보장	-	한 컨슈머 그룹 기준으로 파티션의 메시지는 순서 보장	하나의 큐에 하나의 컨슈머 연결 시 순서 보장	순서 보장하지 않음
모니터링	SQS 콘솔, CloudWatch 콘솔 이용 가능	SQS 콘솔, CloudWatch 콘솔 이용 가능	모니터링 오픈소스 연동 필요	모니터링 오픈소스 연동 필요	모니터링 오픈소스 연동 필요
프로토콜	-	HTTP, HTTPS, SMTP, SMS, SQS, application, lambda and firehouse	Binary protocol over TCP	AMQP, MQTT, STOMP	-
지속성	At least once(Standard), Exactly once(FIFO)	메시지 전달 후 삭제하기 때문에 상실 가능	At least once	At least once	낮음 (메모리 기반)
스케일링 및 분산	수평 스케일링 가능	수평 스케일링 가능	수평 및 수직 스케일링 가능	수평 스케일링 가능	제한적 (단일 노드)

성능 설명

1. SQS (Amazon Simple Queue Service): 서버리스 메시지 대기열 서비스로서, 광범위한 사용 사례에 적합합니다. 그러나 특정 설정 및 사용 사례에 따라 성능이 달라질 수 있습니다.
2. SNS (Amazon Simple Notification Service): 이벤트 기반 메시징 서비스로, 거의 무제한의 TPS를 처리할 수 있습니다. 비동기적인 푸시 알림에 적합하며, 특정 요구 사항에 따라 성능이 달라질 수 있습니다.
3. Kafka: 대규모 이벤트 스트리밍 및 메시징에 적합한 분산 시스템으로, 높은 TPS를 처리할 수 있습니다. 그러나 성능은 환경 및 클러스터 설정에 따라 변할 수 있습니다.
4. RabbitMQ: 메시지 브로커로서 일반적인 사용 사례에 적합한 성능을 제공합니다. 그러나 클러스터 구성과 메시지 복잡성에 따라 성능이 변할 수 있습니다.
5. Redis Pub/Sub: 주로 간단한 메시징 요구 사항을 처리하는 데 적합하며, 성능은 메모리 기반인 만큼 빠르지만, 지속성이 낮을 수 있습니다.

메시지 전달 보장 수준

종류	개요	re-try 유무	중복 삭제 유무	비고
At Most Once	1회 전달 시도	X	X	메시지는 중복되지 않지만, 네트워크 등의 이유로 인해 상실될 수 있습니다.
At Least once	적어도 1회는 전달	O	X	메시지는 중복될 수 있지만, 최소한 한 번은 정확히 한 번 이상 전달됩니다.
Exactly Once	1회만 전달	O	O	메시지는 중복되거나 상실되지 않고, 확실하게 1회만 전달되지만, 이를 달성하기 위해선 성능의 손실이 발생할 수 있습니다.