[Server] 이벤트 브로커 (kafka) vs 메시지 브로커 (rabbitmq)

1. pub/sub 구조란 ?

브로커를 알기위해선 pub/sub 구조를 먼저 알아야 한다.

pub -> publisher (발행)

sub -> subscriber (구독)

이라 하여 발행 - 구독 모델이라고 표현 하는 곳도 있다.

 

단어 뜻만 놓고 보면 어떤 이벤트를 발행하는 곳과 그 이벤트를 구독하는 곳 이런 식으로 구성되어있다고 생각할수 있다.

이벤트(메시지)를 발행해서 특정 채널 또는 토픽에 이벤트를 전송하고

특정 채널 혹은 토픽을 구독하는 곳에서 발행자와 관계없이 발행된 이벤트를 얻을 수 있는 것이다.

 

예를 들어보자 

마트 할인 알림이 필요한 사람이 있다고 하자.

이 사람은 오로지 할인 정보만을 원하고, 정보 제공자에겐 일말의 관심이 없다.

 

발행자는 "마트 할인 정보"에 정보를 넣으면 수신자는 해당 채널에서 할인정보을 얻을 수 있다.

 

발생자와 수신자는 서로 모른다. 익명채널에 있는 것과 같다.

각자 중간 컴포넌트인 채널만 알면 되기 때문이다.

 

발행자의 메시지는 특정 수신자가 없다.

특정 수신자가 없기 떄문에 수신 여부를 확인 하지 않고,

따라서 pub/sub 구조는 비동기 메시징이다.

 

메시지 브로커와 이벤트 브로커 모두 위의 pub/sub 기반의 메시지 큐 서비스를 제공한다.

 

2. 메시지 브로커

메시지 브로커는 발행자가 생산한 메시지를 큐에 저장하고 수신자가 가져갈 수 있도록 중간다리 역할을 한다.

보통 서로 다른 시스템에서 데이터를 비동기 형태로 처리하기 위해 사용하며

대표적으로 RabbitMQ 소프트웨어가 있다.

 

이런 메시지 브로커들은 소비자가 큐에서 데이터를 가져가게 되면 즉시 (또는 짧은 시간 내에)

큐에서 데이터가 삭제된다.

 

3. 이벤트 브로커

이벤트 브로커는 기본적으로 메시지 브로커의 큐 기능을 가지고 있다.

따라서 메시지 브로커의 역할도 가능하다.

 

또한 이벤트 브로커는 발행자가 생산한 이벤트를 저장해, 추후 소비자가 특정 시점 부터 이벤트를 다시 소비할수 있는 장점이 있다. 

(보통 장애 발생시 장애 시점 이후의 이벤트만 다시 실행하고 싶은 경우 위 방식이 유리하다.)

 

대용량 데이터 처리 역시 메시지 브로커 보다는 더 많은 양의 데이터를 처리 할수 있으므로
요즘은 Kafka와 같은 이벤트 브로커를 더 많이 쓰는 추세다.