본문 바로가기

개발/Messaging system

(2)
SQS with Spring Background이전 아티클에서 RabbitMQ 를 Kafka 로 마이그레이션하다가 비즈니스 성격상 맞지 않아 중단했습니다. 그래서 새로운 대체 메시징 시스템이 필요했습니다. 결과적으로 SQS를 사용하게됬는데, 그 경험을 정리하고자 합니다. Why SQS?먼저, 왜 여러 MQ 구현체 중에 SQS 를 선택했을까?>> SaaS(Software as a Service)기존에 사용하던 솔루션은 SaaS가 아니였습니다. 기존에는 RabbitMQ 클러스터를 구성하고 유지하는 비용을 모두 감당해야했습니다. RabbitMQ에 요청이 늘고, 줄을 때마다 클러스터를 구성하는 인스턴스 늘려주는 작업도 필요하고, 인스턴스 관리도 필요합니다. 하지만 SQS는 AWS에서 SaaS로 제공되어, 유지보수는 AWS가 알아서 해줍니다..
Kafka Consumer Design Background대부분이 메시징 시스템이 그렇듯이, 프로듀서는 비교적 쉽습니다. 그냥 메시지를 발행하면 됩니다. 하지만 컨슈머의 경우 비즈니스의 요구사항에 따라 고려할 점이 많아집니다.Fail over를 처리해야되는지 또는 메시지를 중복 소모를 해도 되는지 또는 병렬처리가 필요한지 또는 비동기처리를 해야되는지 등.. 제가 이번에 경험한 상황은 기존에 RabbitMQ로 50개의 병렬 메시지를 동시에 처리하던 작업을 Kafka 로 마이그레이션 하는 작업입니다. 각 메시지는 처리시간이 초 단위에서 길게는 30분 까지 다양합니다. 그리고 메시지는 최대 50개를 병렬 처리해야하며, 각각의 메시지는 끝나면 큐에서 다음 메시지를 가져와서 처리해야합니다. Smart pipe and Dump pipeRabbitMQ와 ..