Intro.
이전 CQRS 글에서 이벤트 소싱과 이벤트 스트림에 대해 언급한 적이 있습니다.
해당 글에서 이벤트와 관련된 주요 키워드를 설명하자면 다음과 같습니다.
-
이벤트 소싱: Application 내의 모든 Activity를 이벤트로 전환해서 이벤트 스트림을 별도의 저장소에 저장하는 방식. -
이벤트 스트림: 이벤트 소스에서 스트림(stream, 데이터의 순서) 형태로 실시간 데이터를 캡처하는 것 -
이벤트 저장소: DB와 메시지 브로커의 혼합 형태. 서비스가 이벤트를 이벤트 저장소에 저장하면, 이벤트 저장소가 이벤트를 구독기에 전달합니다. 저장소는 캐시, DB 등 여러 선택지가 있고, 메세지 큐도 그 중 하나입니다. -
이벤트 브로커: 메세지 브로커는 이벤트 브로커일수 없지만, 이벤트 브로커는 메세지 브로커일 수 있습니다.
이벤트 브로커는 이벤트(메세지)라고 불리는 레코드를 하나의 장부에 보관해 인덱스로 관리하고, 이벤트를 삭제하지 않고 보관할 수 있습니다.
저는 CQRS 적용과정에서 이벤트 소싱을 위한 이벤트 브로커로 메세지 큐, 그 중 kafka를 적용했습니다.
메세지 큐에는 여러 선택지가 있는데, 굳이 kafka를 선택한 이유는 다음과 같습니다.
MessageQue 란?
메시지 지향 미들웨어(Message Oriented Middleware: MOM)은 비동기 메시지를 사용하는 다른 응용 프로그램 사이에서 데이터 송수신을 의미합니다.
그리고 이 MOM을 구현한 시스템을 메시지 큐(MessageQueue: MQ)라 합니다.
메시지 큐의 장점
- 비동기(Asynchronous): Queue에 넣기 때문에 나중에 처리할 수 있습니다.
- 비동조(Decoupling): 애츨리케이션과 분리할 수 있습니다.
- 탄력성(Resilience): 일부가 실패 시 전체에 영향을 받지 않습니다.
- 과잉(Redundancy): 실패할 경우 재실행 가능합니다.
- 보증(Guarantees): 작업이 처리된걸 확인할 수 있습니다.
- 확장성(Scalable): 다수의 프로세스들이 큐에 메시지를 보낼 수 있습니다.
메시지 큐 사용처
- 다른 곳의 API로 부터 데이터 송수신이 가능합니다.
- 다양한 애플리케이션에서 비동기 통신을 할 수 있습니다.
- 이메일 발송 및 문서 업로드가 가능합니다.
- 많은 양의 프로세스들을 처리할 수 있습니다.
Kafka 와 RabbitMQ 의 차이
엄밀히 따지면 둘은 태생 자체가 다릅니다.
RabbitMQ는 메세지 브로커이고, Kafka는 pub/sub 방식의 이벤트 스트리밍 플랫폼입니다.
각각의 특징과 차이점은 다음과 같습니다.
RabbitMQ
- 제품 성숙도가 높고 생태계가 크다.
- 필요에 따라 동기/비동기식이 가능하다.
- 유연한 라우팅이 가능하다.
- broker 중심적, producer/consumer 간의 보장되는 메세지 전달에 초점을 둔 메세지 브로커이다.
- 클러스터 구성이 쉽고, Manage UI가 제공되며 플러그인도 제공되어 확장성이 뛰어나다.
- 데이터 처리보단 관리적 측면이나 다양한 기능 구현을 위한 서비스를 구축할 때 사용한다.
Apache Kafka
- 이벤트가 전달되어도 삭제하지 않고 스트림에 저장한다.
- 고성능, 고가용성, 분산 처리에 효과적으로 설계되었다.
- producer 중심적, 많은 양의 데이터를 파티셔닝하는데에 기반을 둔다.
- consumer가 broker로 부터 직접 메시지를 가지고 가는 pull 방식으로 동작한다.
- 범용 메세징 시스템에서 제공되는 다양한 기능은 제공되지 않는다.
| RabbitMQ | Apache Kafka | |
|---|---|---|
| 메세지 재처리 | 메시지가 성공적으로 전달되었다고 판단될 경우 메시지가 큐에서 삭제되기 때문에 재처리가 어렵다. | 이벤트를 삭제하지 않고 스트림에 저장함으로 영속성(durability)이 보장되고, 재처리가 가능하다. |
| 프로토콜 | AMQP, MQTT, STOMP 등 여러 메세징 플랫폼을 지원한다. | 단순한 메시지 헤더를 지닌TCP 기반 custom 프로토콜을 사용하기 때문에 대체가 어렵다. |
| 라우팅 | Direct, Fanout, Topic, Headers의 라우팅 옵션을 제공하여 유연한 라우팅이 가능하다. | 기본기능으로 라우팅에 대해서 지원하지 않는다. Kafka Streams를 활용하여 동적라우팅을 구현할 수 있다. |
| 우선 순위 | priority queue를 지원하여 우선 순위에 따라서 처리가 가능하다. | 변경 불가능한 시퀀스 큐로, 시간 순서를 보장한다. |
Kafka는 라우팅이 단순한 서비스의 분산 처리 및 대용량 스트리밍에 적합합니다. 또한 저장된 이벤트를 기반으로 로그를 추적하고 재처리하는데 용이해 이벤트 소싱, 스트림 처리 및 일련의 이벤트로 시스템에 대한 모델링 변경 등 event-driven 구현에 사용될 수 있습니다.
RabbitMQ는 복잡한 라우팅을 유연하게 처리해야하고 정확한 요청-응답이 필요한 Application에 적합합니다. 굉장한 트래픽이 몰리는 것이 아니라면 장시간 실행되는 태스크, 안정적인 백그라운드 작업 실행, 애플리케이션간 통신/통합이 필요할 때 RabbitMQ를 고려해볼 수 있습니다.
Conclusion
위와 같은 특장점을 기반으로 Kafka는 이벤트 소싱에 필요한 이벤트 저장소와 이벤트 브로커의 역할을 훌륭하게 해낼 수 있습니다.
물론 반대되는 의견도 존재하는 듯 하지만 실제로도 둘의 궁합이 좋은 것이 사실인 듯 하네요.
Ref.
Understanding the Differences Between RabbitMQ vs Kafka
Event sourcing, CQRS, stream processing and Apache Kafka: What’s the connection?
Kafka 이벤트 스트리밍 이해하기
카프카를 이벤트 소싱, CQRS로 사용할 수 있을까?
Using Kafka as a (CQRS) Eventstore. Good idea?
https://coding-nyan.tistory.com/129
메시지큐(Message Queue) 알아보기
