🧐 고민
-
현재 회사에서 비동기 작업 처리를 위한 메시징 플랫폼으로 RabbitMQ를 사용하고 있습니다. 하지만 향후 증가하게 될 부하 및 처리량에 대한 이슈를 대비하기 위해 팀 차원에서의 새로운 고민 하게 되었습니다. 가까운 미래를 안전하고 효율적으로 대비하기 위해 새로운 메시징 플랫폼 리서치를 시작하게 되었습니다.
-
저희가 도입 고민 중인 메시징 플랫폼은 Kafka입니다. 최근 메시징 플랫폼에서 빠지지 않고 언급되며 많은 기업에서도 적용하여 사용중인 Kafka 도입을 고려하고 있지만, 신규 기술도입은 많은 리스크를 안고 있기에 보다 신중하게 접근해야합니다.
-
가장 큰 고민은 현재도 안정적으로 운영 중인 RabbitMQ를 떠나 새로운 메시징 플랫폼인 Kafka를 도입할 가치가 있는가에 대해 고민이 입니다. 그러던 중 [NHN FORWARD 2020] RabbitMQ and Cloud Messaging Platform이라는 영상을 발견하게 되었습니다. RabbitMQ와 Kafka의 주요 컨셉부터 역할까지 잘 비교하는 영상이었고 이를 정리해보았습니다.
📭 메시징 플랫폼
1. 메시지 브로커
애플리케이션, 시스템 및 서비스가 서로 간에 통신하고 정보를 교환할 수 있도록 해주는 소프트웨어
정규 메시징 프로토콜 간에 메시지를 변환함으로써 이를 수행
- 많은 기업들에서 메시지 기반 미들웨어 아키텍쳐에서 자주 사용
- 미들웨어: 서비스하는 애플리케이션들을 보다 효율적으로 아키텍쳐들을 연결하는 소프트웨어(메시징 플랫폼, 인증 플랫폼, 데이터베이스 등등)
- 메시지 처리 후 즉시 또는 짧은 시간 내에 삭제
- 메시지 브로커는 메시지를 생산 - 처리 - 삭제
- RedisQueue, RabbitMQ
2. 이벤트 브로커
메시지 브로커의 큐 기능을 가지고 있고 추가로 이벤트 별로 관리가 가능
- 메시지 브로커의 역할 가능
- 이벤트 또는 메시지라고도 불리는 레코드를 하나만 보관하고 인덱스를 통해 개별 엑세스를 관리
- 업무상 필요한 시간동안 메시지를 관리 가능
- 이벤트 브로커는 데이터를 삭제하지 않음
- 이벤트 브로커는 서비스에서 나오는 이벤트를 마치 데이터베이스에 저장하듯이 이벤트 브로커의 큐에 저장
- 저장을 통해 얻는 이점
- 딱 한 번 일어난 이벤트 데이터를 브로커에 저장하므로서 단일 진실 공급원으로 사용 가능
- 장애 발생시 장애가 일어난 시점부터 재 처리가 가능
- 많은 양의 실시간 스트림 데이터를 효과적으로 처리 가능
- 다양한 이벤트 기반 MSA에서 중요한 역할 가능
- Kafka, AWS Kinesis
🤲 RabbitMQ vs Kafka
1. Main Concept
RabbitMQ
- Queue
- Queue의 메시지는 소비되면 짧은 기간 보관 또는 삭제. 일시적인 메시지 보관에 최적화
- Queue의 생성자(producer)와 소비자(consumer)가 독집적/비동기적으로 동작할 수 있게 사이에서 큐잉버퍼의 역할
- 메시지가 Queue에서 머무르는 시간이 짧을 수록 성능이 좋게 구현
Kafka
- Log
- 일반적으로 파일을 쓰는 것으로 이해하면 쉬움. 메시지를 긴 시간 혹은 영구적으로 보관가능
- 큐와는 다르게 같은 데이터를 반복적으로 읽을 수 있음
- 이벤트 소싱을 구현 할 때 좋은 미들웨어
- 추가되는 메시지를 지속적으로 덧붙히는 방식. 따라서 큐와는 달리 구현 방식이 매우 간단함
2. Broker
RabbitMQ
- Smart Broker & Dumb Consumer
- 모든 큐와 메시지를 브로커가 직접 관리
- 대부분의 기능을 브로커가 처리하고 컨슈머는 독립적인 구조
- 따라서 컨슈머 애플리케이션을 구현하거나 설계할 때 엔지니어링 리소스가 적음
- 스케일 아웃과정에서도 단순하게 컨슈머 인스턴스의 수를 늘리면 됨
- 하지만 컨슈머가 늘어남에 따라 브로커의 역할이 커짐. 여러 컨슈머가 소비하는 메시지의 상태를 모두 관리해야함
Kafka
- Bumb Broker & Smart Consumer
- 메시지를 단순하게 덧붙힘. 브로커는 컨슈머가 어떤 메시지를 어디까지 읽었는지 관리하지 않음. 메시지 관리는 컨슈머에서 관리
- 따라서 컨슈머 애플리케이션 엔지니어링 리소스가 RabbitMQ보다 큼. 개발자의 실수로 인한 장애가 발생할 가능성이 커짐
- 스케일 아웃 과정에서도 단순하게 컨슈머만 늘리는 것이 아니라 파티션의 수도 함께 늘려줘야함
- 이런점 때문에 컨슈머의 스케일 아웃이 브로커에 매우 의존적임
2. Queality of Service(메시지 전달 보장 수준)
At most once
- 메시지 전달에서 손실이 발생할 수 있는 부분
- 네트워크 문제나 기타 문제로 컨슈머가 받는 메시지 손실이 발생할 수도 있음
At least once
- 브로커가 메시지 손실 가능성을 사라졌지만 중복 가능성이 있는 메시지가 전달될 가능성이 있음
- 브로커는 컨슈머에서 메시지 전송 응답이 올 때까지 큐에 메시지를 저장
- 만약 오류가 발생해 컨슈머에서 브로커에게 메시지 응답 중 연결이 끊어진다면, 큐에 남아 있는 메시지는 다른 컨슈머에게 전송되어 중복 문제가 발생할 수 있음
Exactly once
- 메시지를 손실 중복 없이 전달하는 메시지 전달 보장 수준
- 가장 안전하지만 일반적으로 프로듀서 - 브로커 - 컨슈머 사이에 트랜잭션을 사용하기 때문에 성능이 나쁨
4. Protocol
RabbitMQ
- amqp, mqtt, stomp
- 다양한 표준 프로토콜 제공
Kafka
- 자체 전이된 tcp 기반 바이터리 프로토콜 제공
- 400개가 넘는 커넥터가 존재하기 때문에 다른 서비스와 미들웨어에 적용하는 것이 어렵지 않음
5. Usablilty and Use cases
RabbitMQ
- 높은 사용성
- 설치 및 운영이 상대적으로 쉬움. 빌트인 콘솔 있음
- 메시징 기능에 초점을 둔 전통적인 메시지 브로커
Kafka
- 관리를 위한 별도의 도구 필요
- 실시간 스트림 프로세싱
- 메트릭, 이벤트 소싱 등 다양한 곳에서 사용 가능
참고자료
- [NHN FORWARD 2020] RabbitMQ and Cloud Messaging Platform (https://www.youtube.com/watch?v=SmE_k8lqfRQ)
- 카프카, 레빗엠큐, 레디스 큐의 큰 차이점! 이벤트 브로커와 메시지 브로커에 대해 알아봅시다(https://www.youtube.com/watch?v=H_DaPyUOeTo)
