메시지 큐, 태스크 큐, 메시지 브로커, 헷갈리는 개념, 명확히 정리!
메시지 큐(Message Queue), 태스크 큐(Task Queue), 메시지 브로커(Message Broker)의 개념 혼동에 대한 문제 제기
Kafka는 분산 로그(Distributed Log)로 시작했지만, 브로커 및 큐로 사용되며 혼란을 야기함
Redis는 단순 큐와 브로커 역할을 모두 수행하여, Celery와 함께 혼란을 가중시킴
RabbitMQ와 SQS는 메시지 브로커, Celery는 태스크 큐로 사용되며, 각 시스템의 보장 수준(Guarantee Level)에 따라 선택해야 함
Kafka의 역할 모호성 및 문제점
커뮤니티에서는 Kafka가 분산 로그(Distributed Log)로 시작했지만, 브로커(Broker)와 큐(Queue)로 동시에 사용되면서 혼란을 야기한다고 지적한다. 특히 Consumer Group Semantics와 Competing Consumers 간의 충돌, Log Compaction과 TTL(Time to Live), Retention-based Replay와 DLQ(Dead Letter Queue) 간의 불일치로 인해 문제 발생 가능성이 높다고 언급한다. 이러한 혼란은 시스템 장애 시 더욱 심각한 문제로 이어진다.
Redis와 Celery의 조합, 보장 수준의 중요성
논의에서는 Redis를 큐(Queue)로 사용할 경우, 브로커(Broker)가 제공하는 보장(Guarantee)을 기본적으로 제공하지 않는다는 점을 강조한다. 즉, ACK(Acknowledgement) 부재, DLQ(Dead Letter Queue) 부재, 그리고 Visibility Timeout 설정의 중요성을 언급한다. 따라서 Redis를 큐로 사용할 때는 시스템의 안정성을 위해 세심한 튜닝이 필요하며, 그렇지 않으면 시스템이 취약해질 수 있다.
메시지 큐, 태스크 큐, 메시지 브로커의 기능적 차이
댓글에서는 태스크 큐(Task Queue)와 메시지 큐(Message Queue)의 기능적 차이에 대한 의문을 제기하며, 두 개념의 명확한 구분이 필요하다고 주장한다. 특히, 태스크 큐가 독립적인 서비스이고, 워커(Worker)가 큐를 확인하여 작업을 처리하는 방식이라면, 이는 결국 메시지 큐와 동일한 기능을 수행하는 것이 아니냐는 질문을 던진다. 이러한 혼란은 시스템 설계 시 불필요한 복잡성을 야기할 수 있다.
Pub/Sub vs Producer/Consumer 아키텍처 비교
커뮤니티에서는 Pub/Sub(Publish/Subscribe)와 Producer/Consumer 아키텍처의 차이점을 설명한다. Kafka는 Pub/Sub에 적합하게 설계되었지만, Producer/Consumer 패턴으로도 사용할 수 있다. 반면, SQS(Simple Queue Service)는 Producer/Consumer에 특화되어 있으며, SNS(Simple Notification Service)를 통해 Pub/Sub 기능을 추가할 수 있다. 이러한 아키텍처 선택은 시스템의 요구 사항에 따라 달라져야 한다.
