메시지 브로커 [1]

스트림

 일괄 처리 시스템은 사전에 일정 크기로 제한함을 가정하에 데이터를 일정 크기만큼 받아 처리하는 방식입니다. 수많은 데이터가 오가는 현재, 매번 단일 처리 하는 방식보다 굉장히 효율적인 방식입니다. 하지만 데이터가 처리하기 전까지는 출력 결과를 알 수 없다는 단점이 있습니다. 일괄처리 기준을 기간으로 잡았다면은 정해놓은 기간이 지나지 않으면 반영되지 않는다는 말입니다.

 

 스트림은 시간이 지남에 따라 점직적으로 데이터를 생산합니다. 그렇기에 데이터를 빠르게 처리(갱신)해야하는 시스템에서는 스트림 처리를 통해 이벤트가 발생할 때마다 처리해야합니다.

 

 이벤트를 실시간 처리하기 방법 중 하나로 데이터 스토어를 사용하는 것입니다. 아래 그림을 참고하시면 생성자는 이벤트를 생성 후 데이터 스토어에 기록합니다. 소비자(구독자)들은 데이터 스토어에 주기적으로 접근해 폴링 합니다.

 

 수신자(구독자)들은 데이터 스토어에 접근해 이벤트가 업데이트되었을 경우에만 이벤트를 받아와 처리를 합니다. 하지만 잦은 폴링으로 발생하는 오버헤드입니다. 수신자(구독자)가 데이터 스토어에서 폴링 하는 주기가 낮을수록 이벤트를 업데이트하지 않는 경우가 잦다는 것이 단점입니다.

 

메시지 브로커

 메시지 브로커를 사용함으로써 폴링 오버헤드 발생을 막을 수 있습니다. 브로커는 수신자(구독자)에게 이벤트가 업데이트 됨을 알리고 수신자(구독자)들은 브로커 큐에 쌓인 데이터를 받아와 처리합니다. 이로써 수신자(구독자)는 업데이트가 되었는지 수시로 확인할 필요 없이 알림이 올 때만 폴링 하기에 오버헤드가 발생하지 않습니다.

 

 생성자는 메시지를 브로커에 전달만 하고 큐에 들어갔는지만 확인합니다. 그 후 브로커는 수신자에게 알림을 보내고 수신자(구독자)는 그제서야 폴링을 합니다. 

 

 메시지 브로커는 대부분 메시지 전달이 성공적으로 이루어지면 보유하고 있던 메시지를 삭제 처리합니다. 그렇기에 메시지가 생성후 삭제까지의 시간이 짧아 메시지 브로커 큐는 크기가 작습니다. 아래 메시지 브로커 동작을 간단하게 그림으로  올려놨으니 참고하시면 됩니다. 

 

마무리

 간단하게 메시지 브로커까지 알아봤습니다. 해당 내요은 데이터 중심 애플리케이션 설계 책 내용을 보고 정리한 내용입니다. 추후 더 업데이트하겠습니다.