[Messaging System] MQ vs Kafka 정리

주제 선정

 

직장에서 기존에 사용하던 MQ Storage에서 Kafka로 tool 변경을 진행한다고 한다.

내가 속한 프로젝트는 기존 보유하고 있는 IT 솔루션을 MSA(Microservice Architecture)로 옮기는 작업을 진행 중에 있다.

이에 호기심이 생겨, 관련된 영상과 블로그를 찾아 간략하게 정리해 본다.

 

AI 쪽과 개발은 또 다른 세계이다 보니, 필수 개념들을 위주로 정리해 보았다.

위의 개념들을 이해하는데 [얄팍한 코딩사전] Message Broker - 카프카와 RabbitMQ를 알아보자 가 많은 도움이 되었다.

해당 게시물은 위의 영상을 main으로, 참조에 있는 글들을 보며 개념을 정리한 결과물이다.

---

 

마이크로서비스 아키텍처에서의 필요성

 

메세지 송신과 수신(출처: 얄팍한 코딩 사전)

• 마이크로서비스 아키텍처에서는 한쪽이 여러 대상에게 데이터 보내야 하는 경우 많음
• 이럴 때, 받는 쪽과 보내는 쪽 모두 송신과 수신이 가능한 상태를 유지해야 됨
• 받는 쪽이 추가되거나 작업 변경되면 그에 따른 대응 작업이 추가되어야 함
• 서비스가 더해질수록 아키텍처 관리 복잡해지고 지엽적인 문제들 발생
  

 

Message Broker,  Producer, Consumer

 

메세지 브로커 역할(출처: 얄팍한 코딩사전)

• '메시지 브로커'는 이런 문제점 해결해 줌
• '보내는 쪽'과 '받는 쪽'을 서로로부터 자유롭게 만들어줌
• 이 사이에 'Message Broker'를 위치함으로써 메시지 보내는 쪽(Producer)과 메시지 받는 쪽(Consumer)이 본인들의 역할에만 충실하게 해 줌
• Producer는 전달할 것이 있을 때 Message Broker에 메시지 가져다 두면 됨
• Consumer가 이를 받아갔는지 신경 쓸 필요 없이 보내는 거에만 집중

메세지 브로커 역할(출처 얄팍한 코딩사전)

• 컨슈머는 필요할 때마다 필요한 데이터 가져감
• Message Broker 안에는 종류별로 칸막이가 되어 있기 때문에 각 컨슈머는 자기가 필요한 것만 가지고 가면 됨
• 종류별로 칸막이가 되어 있기 때문에 자기가 필요한 것만 골라서 가져가면 됨
• 지정 시점까지 데이터 보관하기 때문에 컨슈머가 바로 찾아가지 않더라도 데이터 유실 걱정 없음

---

Message Broker 종류

 

 

메세지 브로커 종류(출처: 얄팍한 코딩사전)

• 메시지 브로커에는 다양한 종류가 있음

메세지 브로커의 대표적 제품(출처: 얄팍한 코딩사전)

• 그중, 특징에 따라 각 영역의 대표군으로 꼽히는 것이 'RabbitMQ'와 Kafka

---

RabbitMQ vs Kafka

 

서버 설치

 

RabbitMQ vs Kafka 서버 설치(출처: 얄팍한 코딩사전)

• RabbitMQ는 하나 또는 비교적 적은 수의 서버에 설치됨
• Kafka는 일반적으로 큰 규모의 클러스터로 운용됨

통신 방식

 

RabbitMQ vs Kakfa 통신 방식 (출처: 얄팍한 코딩 사전)

 

• RabbitMQ: AMQP 프로토콜
• Kafka: TCP 기반으로 한 자체적인 프로토콜

 

메세지 저장 방식

 

RabbitMQ vs Kafka 메세지 저장 방식(출처: 얄팍한 코딩 사전)

 

RabbitMQ: 메시지들을 큐(Queue) 형태로 저장

• Queue? 선입서출. 먼저 들어온 것이 먼저 나가는 형태

RabbitMQ 메세지 저장 방식 Queue (출처: 얄팍한 코딩 사전)

• 프로듀서가 보낸 순서대로 이 메세지들을 큐 형태로 저장한 다음, 컨슈머가 이들을 요청하는 대로 이들을 큐에서 빼내어 전송하게 됨
• 브로커는 프로듀서로부터 메시지 받아와 저장하는 일 + 컨슈머가 메세지 받아갈 때마다 이를 큐에서 제거하는 일 담당
• 컨슈머는 다른 것 고려할 필요 없이 브로커에게 메시지 요청하기만 하면 됨
• Smart Broker, Dumb Consumer

RabbitMQ의 메세지 실시간 삭제(출처: 얄팍한 코딩사전)

• 컨슈머가 받아간 메시지가 삭제되는 것까지 다른 노드들에 실시간으로 적용되어야 하기 때문에 클러스터링이 까다로움
  

RabbitMQ의 Queue(출처: 얄팍한 코딩사전)

• 메시지를 특정 카테고리로 전달하는 방식이 보다 다양
• 메시지들을 Queue 그룹으로 묶음
• 조건에 따라, 각 메시지를 특정 큐로 보내거나 모든 큐로 보내기 위한 다양한 방식 제공해 복잡한 메세지 라우팅 필요한 서비스인 경우 유리

---

Kafka는 로그 형태로 저장

• 이 메시지들을 컨슈머가 받아 간다고 해도 로그에서 지워지지 않음

Kafka 메세지 저장 방식(출처: 얄팍한 코딩사전)

• 로그 안의 메시지들은 배열 안의 요소들이 인덱스 갖는 것처럼 각각의 오프셋 가짐
• 컨슈머들은 자기가 받아간 마지막 오프셋을 기억함으로써 중복 없이 다음 메시지 요청하게 됨
• Dumb Broker, Smart Consumer

Kafka 메세지 저장 방식(출처: 얄팍한 코딩사전) 자

• 장애가 발생했을 시, 문제가 있었던 부분부터 다시 받아갈 수도 있음
• Kafka는 기본적으로 배치(batch) 기능 제공하기 때문에 메시지들을 여럿씩 받아오거나 보내주는 일도 빠르고 간편하게 처리
• 브로커를 여러 서버에 분산해 운영하는 클러스터링에 보다 유리

kafka 기능(출처: 얄팍한 코딩사전)

• kafka에서는 메시지들을 토픽(topic)이라는 그룹으로 묶음
• 컨슈머가 메세지 성공적으로 처리했는지 여부를 브로커에게 전달함으로써 신뢰성 있는 전달 보장
• 브로커가 메시지 처리 여부 확인할 수 있기 때문에 트랜잭션과 같이 안정적인 처리 필요한 작업에 적합
• 메세지 우선순위 두는 기능, 메시지가 일정 시간 후 자동 만료되도록 설정하는 기능 또한 제공됨

---

결론

 

위의 내용들을 스크럼팀 사수분들에게 간략하게 공유했다.

이에 질문들을 해주셨는데, 질문에 답변을 드리려고 하니 개념이 얕다 보니 답변을 드리며 나조차 헷갈렸다.

질문들은 다음과 같았다.

• Kafka가 MQ보다 더 나은 점이 오프셋을 부여해 중복성을 안 가진다는 것인데, MQ의 경우에도 보낸 메시지는 삭제하기 때문에 중복성 문제는 안 가지지 않는가?
• Kafka도 오프셋 기반으로 영원히 메시지를 저장하는 것이 아니라면, MQ에서 메세지 삭제하는 것과 어떤 차이가 있는 것인가?

만약 위의 질문들에 답변이 가능하신 분이 있으시다면, 언제든 댓글로 편하게 답변 주시면 감사하겠습니다.🫡

---

정리

 

 

아키텍처 구성 방식(출처: 파닥파닥 velog)

---

참고

 

[얄팍한 코딩사전] Message Broker - 카프카와 RabbitMQ를 알아보자

[Architecture] 메시지 브로커와 이벤트 브로커 - 메시지와 이벤트 그리고 RabbitMQ와 Kafka