아래 글을 참고하여 작성하였습니다.
어플리케이션과 시스템, 서비스가 점점 발전하고 규모가 커지게 되면서 서로가 통신하고 데이터를 교환하기 위한 방법이 필요해지게 되었습니다.
따라서 우리는 이 필요한 데이터를 담은 "메세지"라는 것을 한쪽에서 생성(produce)하면, 이것을 다른 쪽에서 소비(consume)하는 구조를 사용하게 되는데요.
이 때에 RabbitMQ와 Kafka가 그 역할을 하게 됩니다.
실무에서 RabbitMQ와 Kafka를 쓰다보면 종종 두 개의 차이점에 대해서 궁금해지곤 합니다.
둘 다 한 곳에서 메시지를 넣어주면 필요한 곳에서 메시지를 꺼내 소비하는 방식으로 되어있다는 점은 어렴풋이 이해하고 있지만
이것만으로는 RabbitMQ와 Kafka를 적재적소에 구분하여 사용하는 것이 어렵게 느껴졌습니다.
따라서 이번 글에서는 RabbitMQ와 Kafka의 차이를 알아보면서 메시지 브로커와 이벤트 스트리밍 플랫폼에 대한 내용을 다뤄보고자 합니다.
메시지 브로커와 이벤트 스트리밍 플랫폼
RabbitMQ와 Kafka의 가장 큰 차이점은 RabbitMQ는 전통적인 메시지 브로커이고, Kafka는 최신 기술로 사용되고 있는 이벤트 스트리밍 플랫폼이라는 점입니다.
메시지 브로커와 RabbitMQ
처음 메시지 브로커가 등장했을 때에는, 이벤트 생성자와 이벤트 라우터 간에 메시지를 전송하기 위해서 메시지 큐(메시지 대기열)에 의존하는 경향이 있었습니다.
특히 RabbitMQ는 "생산자와 소비자간의 보장되는 메시지 전달"에 초점을 맞춰 브로커 중심적인 특징을 가지고 있습니다. 따라서 브로커가 exchange나 메시지 표식을 사용하는 등 "똑똑한 브로커"에 초점이 맞춰져 있죠.
Event Producer가 메세지를 생성하면, 메세지 브로커인 RabbitMQ내에서 이 메세지를 어떤 큐에 발송할지 결정하는 exchange를 하게 되고, 이렇게 큐에 들어간 메세지는 Event Consumer가 가져가게 됩니다.
따라서 컨슈머가 메시지를 가져가면 큐에는 더 이상 남지 않고 사라지게 됩니다.
이 때 메시지 "큐"의 특성에 따라 "선입선출"이 적용되어 메시지는 순서대로 컨슈머에게 제공되고, 컨슈머는 미리 정해둔 한계점까지 지속적으로 메시지를 큐에서 읽어들입니다.
하지만 이러한 전통적인 메시지 브로커의 형태는 소비자와 메시지 브로커의 결합력이 높아지게 되어 후에 앱의 트래픽이 증가하여도 수평적으로 확장하는 데에 어려움이 있습니다.
또한 이벤트 메시지가 성공적으로 전달되었다고 판단될 경우 이 메시지가 큐에서 삭제되어버리기 때문에 후에 다시 이벤트를 재생하기가 어렵다는 단점이 있죠.
이벤트 스트리밍 플랫폼
이러한 단점을 극복하며 생긴 것이 바로 이벤트 스트리밍 플랫폼입니다.
메시지 브로커와 이벤트 스트리밍 플랫폼 모두 이벤트를 수신하고, 이것을 소비자에게 전달하는 데에 목적을 두고 있지만 작동 방식에 큰 차이가 있습니다.
이벤트 스트리밍 플랫폼은 메시지 브로커와 다르게 topic이라는 것이 event streamer에 저장됩니다.
Event producer가 이벤트를 생성하면, 토픽이라고 불리는 이벤트의 레코드 로그를 streamer에 순서대로 기록하게 됩니다.
그 후 해당 토픽을 구독(subscribe)한 컨슈머에게 전달하게 됩니다.
또한 이 토픽을 컨슈머가 가져간 후에도 이벤트 스트림에서 계속 토픽을 유지하기 때문에 오류 수정이 필요하거나 앱을 리빌드 하는 등의 상황에서 이벤트를 다시 재생시킬 수 있습니다.
이러한 특징으로 인해 이벤트 스트리밍 플랫폼은 전통적인 메시지 브로커에 비해 좀 더 유연하고 느슨한 결합을 가지고 있습니다.
따라서 격리와 확장이 비교적 더 쉽다는 장점이 있습니다.
결론
RabbitMQ의 경우 kafka에 비해 좀 더 쉽지만 컨슈머와 메시지 브로커간의 결합도가 높기 때문에
트래픽이 작으면서 비즈니스가 후에 확장되지 않을 확률이 높다면 RabbitMQ를 사용하는 것이 좋습니다.
하지만 대규모 트래픽이 예상되고, 추후 확장이 예상된다면 kafka를 선택하는 것이 좀 더 바람직해보입니다.
'기술' 카테고리의 다른 글
| [Redis] Redis standalone vs sentinel vs cluster (1) | 2022.03.12 |
|---|---|
| [Tech] 캐시 서버와 캐싱 전략 (0) | 2021.12.30 |
