RebbitMQ VS Kafka 비교 분석하기

메시지 브로커와 이벤트 브로커

브로커

브로커는 매개 혹은 중계하는 역할이라는 의미를 가진다. 메시지 브로커와 이벤트 브로커는 이름 그대로 메시지 전달의 중계자 이벤트 전달의 중계자이다. 이와 같이 중계역을 두는 이유가 무엇일까?

상호간의 중간자가 없다면 서로 연결하기 위해서 서로가 구체적으로 알 필요가 있다. 때문에 서로가 종속된다는 단점을 가지게 돼 중간자가 필요하다. 이와 같이 중간자를 두는 패턴은 다양한 곳에서 사용된다. 예시로는 DIP나 MVVM등이 있다. 중간의 브로커를 둔다는 것은 일종의 의존성이 역전되는 것을 의미한다.

결국 브로커의 역할은 브로커로 연결된 양 쪽의 결합도를 낮추는 것이다.

메시지와 이벤트

메시지 기반 시스템과 이벤트 기반 시스템에서 각각의 차이는 아래와 같다.

• 메시지 기반 시스템
  • 특정 소비자가 존재해 전달되는 메시지를 생성자가 생성해 전달한다. 이 때 소비자가 메시지를 처리하는 방법은 스스로 결정하고 생성자는 그저 소비자가 해당 메시지를 처리해줄 것이라는 기대를 가지고 요청하는 것이다.
  • 명령(Command), 질의(Query), 응답 기반의 시스템이다.
• 이벤트 기반 시스템
  • 상태가 변경될 때 각 생성자가 내보내는 메시지 이다. 차이가 있다면 생성자는 소비자를 알지 못하고 그저 나의 상태가 변경되었다는 사실을 공지하는 것입니다.
    사실 이벤트는 메시지에 한 종류라고 할 수 있습니다. 메시지에는 명령, 질의, 응답, 이벤트 등이 있는데 명령(Command)은 수신자의 상태를 변경하고자 메시지를 보내는 것이고 질의(Query)는 수신자의 정보를 얻기 위해 응답을 기대하며 메시지를 보냅니다. 그리고 이 질의에 대한 결과 메시지를 보내는 것을 응답이라고 합니다.
    이벤트는 명령, 질의, 응답과는 조금 다릅니다. 상태가 변경되었을 때 내가 변경된 정보를 소비자가 볼 수 있도록 게시하여 소비할 수 있도록한다. 이 때 생성자는 어떤 소비자가 이 정보를 받았는지 알지 못한다.

이벤트는 메시지의 구현체(구체 타입)이다. 때문에 이벤트는 상위타입인 메시지를 대신할 수 있다. 하지만 반대로 메시지의 경우 이벤트의 모든 내용을 대체할 수 없다. 마치 상위타입이 구체타입의 모든 것을 대체할 수 없듯이.

메시지 브로커 RebbitMQ

메시지는 브로커 서로 다른 서비스 혹은 시스템간의 메시지를 중계하는 역할을 합니다. 이렇게 중간자가 존재하는 것으로 서로 다른 서비스 혹은 시스템간의 통신을 가능하게 합니다.

메시지 브로커는 검증, 저장, 라우팅을 가능하게 해서 생산자는 소비자의 상태를 알지 못하고 메시지를 생성할 수 있어 서비스간의 결합도를 낮추는 것이 가능해집니다.

메시지 브로커를 활용해 통신한다는 것은 큐에 메시지를 추가하고 그 결과를 기다리는 것이 아니라 다른 작업을 하는 비동기 통신이 가능하다는 것을 의미이다. 때문에 메시지 브로커는 시스템간의 비동기 통신의 용도로 사용된다.

메시지 브로커인 RebbitMQ는 생산자와 소비자간의 메시지 전달이 보장되는 브로커에 초점이 맞춰진 다양한 역할을 할 수 있는 다재다능 도구이다.

하지만 다재다능하다는 것은 많은 책임을 가졌다 라고 해석할 수 있다. 예를 들어 메시지 검증은 소비자의 역할일 수 있음에도 메시지 브로커가 하는 것은 메시지 브로커와 소비자 간에 결합도를 높이고 변경을 힘들게 만드는 길이 될 수도 있음을 의미한다. 또한 높은 결합도가 트래픽 증가에 따라 필요한 Scale-Out에 나쁜 영향을 미칠 수 있다.

RebbitMQ와 같은 메시지 브로커는 소비자가 가져간 메시지를 짧은 시간내에 삭제하기 때문에 이벤트를 재사용하기에 힘들다는 문제가 있다.

이벤트 브로커 Kafka

이벤트 브로커는 기본적으로 메시지 브로커의 역할도 할 수 있다. 이벤트가 메시지에 포함 된다고 위에서 언급한 바가 있다. 즉, 이벤트는 메시지를 구체화한 구현체이다. 때문에 이벤트의 상위 요소인 메시지를 대신할 수 있다.하지만 반대로 메시지의 경우 이벤트의 모든 내용을 대체할 수는 없다. SOLID에 리스코프 치환원칙을 생각하면 이해가 쉬울 것이다.

이벤트 브로커인 Kafka가 RebbitMQ와의 가장 큰 차이점은 소비자(Consumer)가 해당 이벤트를 가져가도 해당 이벤트가 삭제되지 않는다는 점이다.

이벤트가 삭제되지 않기 때문에 시스템에 장애가 발생한 상황에도 재기동하여 카프카에 쌓여 있는 작업들을 처리하면 된다. 또한 이벤트(사건)을 저장해두고 그 이벤트를 다양한 시스템에서 확인하고 처리할 수 있게 한다.

RebbitMQ VS Kafka

RebbitMQ

• 유연한 라우팅 규칙을 적용할 수 있다.
• 메시지 전송 타이밍을 제어할 수 있다.
• 오류 처리 기능을 제공해준다.

Kafka

• 메시지 순서관리를 해준다.
• 과거 메시지 재생 가능성을 포함해 장기간 메시지를 보존할 수 있다.
• 기존 솔루션으로 충분하지 않는 대규모 구조의 메시지를 처리할 수 있다.

RebbitMQ의 경우 기본적으로 다양한 부가 기능을 제공해준다. 때문에 빠르고 쉽게 기능 구현이 가능하다는 장점을 가진다. 하지만 이러한 부가기능들이 소비자와의 높은 결합도를 만들어 확장이 힘들어진다. 또한 상대적으로 대용량 서비스 처리에 적합하지 않다. 때문에 트래픽 규모가 상대적으로 적고 소비자 시스템에 종속되어도 상관 없는 경우에 사용하는 것이 적합하다.

Kafka의 경우 대부분의 기능 구현책임을 각각의 시스템이 진다. 때문에 난이도가 높아 구현이 힘들다는 단점이 있지만 대규모 데이터 처리능력을 가졌다는 장점을 가지고 있기 때문에 대규모 데이터 스트리밍서버에 사용되기 적합하다.