Apache Kafka는 분산처리 성능, 가용성, 에코시스템 면에서 가장 우수하여 대용량/고가용성이 요구될 때 최적이고, AWS SQS는 운영 부담이 낮고 유지보수성이 뛰어나 소규모/단순 구조에 적합하다. Kafka는 Consumer Group 단위로 동일 메시지를 여러 도메인 시스템이 독립적으로 수신할 수 있어 분산 처리에 구조적 강점이 있고, SQS는 Queue당 메시지 1회 소비 삭제 방식으로 중복 처리 부담이 적다. MQTT(Mosquitto)는 IoT/모바일 Device 간 인터페이스에 적합하며, 서버 애플리케이션 간 인터페이스에는 적합하지 않다는 결론 → 서버 간은 Kafka 또는 SQS, 모바일 대상은 AWS IoT 도입을 제안.
Read
Latest Posts · Page 1 of 1
SQS의 DLQ(Dead Letter Queue)는 여러 번 처리에 실패한 메시지를 별도 큐로 분리 저장하는 구조다. 메시지는 설정한 재시도 횟수(maxReceiveCount)를 초과하면 자동으로 DLQ로 이동되어 메인 큐의 처리 흐름을 방해하지 않는다. 이를 통해 실패 메시지를 분석·재처리하고, 전체 시스템의 안정성과 장애 대응력을 높일 수 있다.
ReadQueue에서 Consumer는 큐에 쌓인 메시지를 가져와 실제로 처리하는 역할을 하는 주체다. 메시지는 Consumer가 처리할 때까지 큐에 저장되며, Consumer는 필요할 때 메시지를 가져와 비동기적으로 처리한다. 여러 Consumer가 존재할 경우 부하 분산 및 병렬 처리로 시스템 처리량과 확장성을 높일 수 있다.
ReadQueue에서 Producer는 메시지(이벤트/작업)를 생성해 큐에 넣는 역할을 하는 주체다. Producer는 처리 완료를 기다리지 않고 메시지만 전달함으로써 비동기 처리와 서비스 간 디커플링을 가능하게 한다. 이 구조를 통해 시스템은 부하를 분산하고 장애 상황에서도 유연하게 처리할 수 있다.
ReadSQS는 간단한 메시지 큐 기반으로 서비스 간 비동기 처리와 디커플링에 적합한 서비스다. 반면 MSK(Kafka)는 고속·대용량 데이터 스트리밍과 실시간 처리, 이벤트 기반 아키텍처에 최적화된 플랫폼이다. 즉, 단순 메시지 전달이면 SQS, 실시간 스트리밍·분석까지 필요하면 MSK를 선택하는 것이 핵심 기준이다.
Read