Message Brokers에 대해 알아보자.
Message Broker
: Message Broker는 Publisher(송신자)로부터 전달받은 메세지를 Subscriber(수신자)에게 전달해주는 중간 역할로 응용 소프트웨어간 메세지를 교환할때 통신채널 역할을한다.. 이러한 메세지가 적재되는 공간을 Message Que라고 하고 메세지의 그룹을 Topic이라고한다. 이러한 Message Broker는 Publish/Subscribe Pattern로 불리운다. (Producter/Consumer Pattern이라고도 한다.)
실제로, 데이터를 처리할때 DB에서 조회하는 것 보다 Message Broker를 이용하여 처리하는 것이 성능이 뛰어나다. 하지만 DB의 경우 Query를 통해 원하는 데이터 처리만 핸들링 가능한 반면 Message Broker를 이용하면 Queque에 적제된 데이터에서 Logstash를 이용해 필터링을해야하는 번거로움이 있다. 또한, 장기보관을 하기위해서는 별도의 저장소에 저장해야한다.
이러한 Message Queue/Message Broker의 장점은 Asynchronous(비동기성): Queque에 넣기 때문에 나중에 처리할 수 있음 , Decoupling(비동조): Application과 분리가 가능함, Resilience(탄력성): 일부의 실패가 전체에 영향을 미치지는 않음, Redundancy(과잉): 실패할 경우 재실행이 가능, Guarantees(보증): 작업이 처리된걸 확인할 수 있음, Scalable(확장성): 다수의 프로세스들이 큐에 메세지를 보낼 수 있음 이다.
-
Publish/Subscribe Pattern
: 비동기 메시징 방식으로, Publish하는 Topic을 Subscriber 신청한 모든 수신자에게 메시지를 보내는 방식을 의미한다. -
RabbitMQ
: Erlang으로 작성된 이 기능은 복잡한 라우팅 시나리오에서 효율적인 메시지 전달을 지원합니다. 인기 있는 AMQP 프로토콜을 기반으로 초기 구축되었으며 기존 기술과도 호환성이 뛰어나며, 서버에서 사용할 수 있는 플러그인을 통해 기능을 확장할 수 있습니다. RabbitMQ 브로커는 네트워크 또는 서버 장애 시 신뢰할 수 있도록 배포 및 구성할 수 있습니다. 소비자중심의 설계를 했으며 구성이 쉽다고 합니다. 또한 필요에 따라 동기/비동기식 처리가 가능합니다. 장시간 실행되고 안정적인 백그라운드 작업 등이 필요할 때 사용된다. -
Apache Kafka
: 원시 처리량에 포커스를 맞췄습니다. 스칼라 및 Java로 작성된 Kafka는 분산 로그를 기반으로 합니다. 이 로그는 디스크에 보존된 로그의 끝에 메시지가 기록되고 클라이언트가 해당 로그에서 읽기 시작하는 위치를 선택할 수 있습니다. 이와 마찬가지로 Kafka 클러스터도 여러 서버에 분산 및 클러스터링하여 가용성을 높일 수 있습니다. 생산자 중심의 설계로 구성되었으며 구독 방식의 비동기식 구성이고 고성능 방식입니다. 복잡한 라우팅에 의존하지 않고 최대 처리량으로 스트리밍하는데 사용된다.
