2024.04.24 message broker comparison, duplication in kafka

요즘 출퇴근마다 영어 읽기 능력을 키우려고 영문 기술글을 읽는데 나름 재밌다.

주제는 이메일로오는 medium 기술 글을 보고 있다.

message broker comparison

 

Kafka vs. RabbitMQ vs. Pulsar: The Ultimate Messaging Showdown 🚀

kafka  선택의 이유. sqs  관리가 더 편할 텐데

가장 대표적인 메시지 브로커이면서 많은 참고 자료들이 있다. 가 이유가 될 수 있나.

 

 

duplication in kafka

Handling message duplication in Kafka

메시지 브로커를 사용한다면 이벤트 중복에 대해서 필히 알아야 한다.

서비스 특성마다 At least once,  At monce once,  Exactly Once 등 정책이 다르겠지만 어떻게 처리할지는 알아야 한다.

해당 글에서는 카프카를 사용하면서 언제 중복 메시지가 생길 수 있고 어떻게 해결할 수 있는지 설명한다.

 

프로듀서의 관점에서는 메시지는 퍼블리싱 하고 나서 네트워크 문제로 ack를 받지 못할 수 있다.

그럼 retry가 1 이상, ack가 all로 되어있다면 리트라이를 할 것이다. 그럼 브로커에는 중복 메시지가 쌓인다.

해결법은 멱등성 프로듀서를 사용해서 pid와 seq 정보를 가지고 브로커에 적재할지 말지를 정하게 된다.

근데 여기서 문제가 발생할 수 있는 게 프로듀서가 다운되었다가 다시 살아나면 pid가 바뀌게 되어서 메시지 중복이 될 수 있다는 것이다.

 

컨슈머의 관점에서는 메시지를 받고 나서 오프셋 커밋 전에 연결이 브로커와 연결이 끊기는 경우이다. 타임아웃 혹은 네트워크 문제일 수 있겠다.

이때 서비스 내부적으로는 데이터가 처리되었고 그룹에서 제거되었다면

그룹 내의 다른 컨슈머가 메시지를 중복소비할 수 있다. 

해결하려면 메시지의 고유 id를 할당해서 데이터 저장에 사용하면 된다. db의 자동증가키를 사용하는 방법도 있고,

 

두 번째 상황

There is a possibility for transaction to fail, after publishing message to the fulfillment topic.

사실 이 상황이 발생할 수 있을까 생각했는데 jpa의 동작 방식을 이해하면 그럴 수도 있겠다 싶다.

바로 db에 연결되는 것이 아니기 때문에 밑에서 서드파티 연동 시 문제가 되는 것이다.

이때는 어떻게 해야 할까.

그런 설정이 있는지 모르겠지만 버퍼 없이 바로 db에 즉시 연결되게 플러시를 한다던지.

혹은 글의 방법대로 트랜잭션 아웃박스 패턴을 써서 이벤트 여부를 db에 쌓아서 따로 이벤트를 발행하는 것이다.

 

스프링에서 해결법은 더 간단할 것 같다. 따로 스프링 이벤트로 분리하고 커밋 이후에 동작하게 하면될 듯하다. 본인 또한 회사에서 이런 방법을 사용하고 있고.

다른 부서는 같은 상황에서 트랜잭션 카프카를 사용하는데 db성공 여부에 따라 프로듀싱할 때 메시지 커밋을 같이 보내는데 이것도 중복을 해결하는 하나의 방법이 될 수 있다.

단 트랜잭션에 묶이는 두 번째 행위가 카프카 이벤트 발행일 경우를 말하는 것이다.