Spring 채팅 Kafka vs. RabbitMQ

Question

안녕하세요. 채팅 애플리케이션을 리팩토링 하는 과정에서 궁금한 점이 생겨 처음으로 질문을 남깁니다. 맨 밑으로 내려가면 질문 요약이 있습니다.초기 설계에서 RabbitMQ를 메시지 브로커를 활용해서 스프링 기반 채팅 서버를 만들었습니다.STOMP over websocket을 통해서 클라이언트 <-> 서버 간의 메시지를 통신하고 메시지 브로커의 역할을 모두 RabbitMQ가 담담당하는 구조로 개발했습니다.그리고 시간이 지나 카프카에 대해 공부하면서 대용량 트래픽 상황에서는 RabbitMQ보다 카프카가 더 유리할 것 같다는 생각이 들어 메시지 브로커를 카프카로 전환하는 작업을 하고 있습니다.열심히 개발을 하면서 공부를 하던 도중에 카프카는 STOMP를 지원하지 못한다는 것을 알게 되었습니다.그래서 그런지 대부분의 예제에서 스프링에서 기본으로 제공하는 STOMP 브로커를 사용하더라고요..그런데, 스프링에서 기본으로 제공하는 STOMP 브로커.. 문제가 있습니다. 스프링 서버의 메모리를 사용하기에 잘못하면 서버의 메모리가 낭비되는 주요 원인이 될 수 있습니다. 반면, RabbitMQ는 STOMP 프로토콜을 지원하기에 이 문제에 대한 고민을 하지 않을 수 있었습니다. 이러한 문제에서 제가 궁금한점은 다음과 같습니다.클라이언트의 STOMP 메시지는 스프링 기본 메시지 브로커를 사용하여 송수신하고, 메시지의 중계와 저장은 카프카를 사용하는 지금 이 구조가 올바른지 궁금합니다.SimpleBroker(메모리 기반 메시지브로커)가 대용량 트래픽에서 버틸 수 있을지 궁금합니다.제가 예상해보기로 SimpleBroker(메모리 기반 메시지브로커)가 대용량 트래픽에서 절대 버티지 못할거 같은데, 이 문제를 해결할 방법이 있을까요?제가 글을 잘 못쓰기도 하고, 해당 문제에 대한 개념도 확실하게 잡히지 않은 상태라 아마 보시는 분들이 이해를 제대로 못할 수도 있다고 생각합니다. 이해가 안가는 부분 있으면 빠르게 수정하겠습니다.

장독깨기 · Accepted Answer

일단, 기본적으로 이럴것같다, 저럴것같다, 예상하기로, 이런 어휘들은 개발자에게 어울리지 않습니다.각각을 쓰는 목적, 이유 등을 생각해보고, 흐름도 생각해보고, 때로는 직접 확인을 해보는 것이 좋겠습니다.SimpleBroker 쓰는 이유가 무엇입니까? STOMP 규격을 적용해서 처리하기 위해서죠.SimpleBroker 을 안 쓰면 어떻게 됩니까? 우리가 직접 메시지 규격을 정의하고 구현해야 합니다.그니까, 대용량 트래픽과 상관 관계 없습니다. 그리고, 한 서버에서만 유효합니다.래빗, 카프카를 쓰는 이유가 무엇입니까? 서버를 분산했을 경우, 메시지를 분산된 서버와 연계하기 위해서죠.그럼, 서버를 분산하는 이유는 무엇입니까? 대용량 트래픽을 대비하기 위해서 입니다.1번은 맞는거 같습니다.2,3번은 위에서 말씀드렸습니다. 걱정안해도 됩니다.

zoony · Answer

채팅 서버를 구현은 안해봤지만...메모리 기반이라면 스프링 서버를 여러대 띄우고 nginx나 로드밸런서로 묶으면 되는거 아닌가요?아래 링크는 좀 오래된 내용인데 비슷한 내용인거 같네요https://www.daddyprogrammer.org/post/4731/spring-websocket-chatting-server-redis-pub-sub/

감독님테스트가하고싶어요 · Answer

kafka와 rabbitMq를 같이 쓰면 안되나요?저라면 같이 쓸 수 있도록 설계할 것 같습니다.

카스마당 · Answer

ChatGPT 몇가지 안을 이야기 해주네요.

jeeunglee · Answer

관련해서 저희쪽에 Kafka 전문가분들이 있는데요. 최근에 질문한 내용도 같이 참고하시면 도움이 되지 않을까합니다. 대용량 Kafka 운영에 대한 답변글을 올려봅니다. 참고하세요. " 파티션 리밸런싱이 진행될 동안 프로듀싱을 멈출 필요는 없습니다. 다만, 몇 가지 주의해야할 부분이 있습니다. 먼저 카프카 브로커측에서는 파티션 데이터 이동으로 인한 부하가 증가합니다. 이때 이동할 파티션의 크기가 크고 브러커의 네트워크 리소스가 충분하지 않을 경우엔 복제 지연, 요청 처리 지연등의 이슈가 있을 수 있습니다.다음으로 카프카 프로듀서측에서는 파티션의 리더가 변경되는 시점에 이전 리더에 보낸 요청은 실패하게 되고 retry 정책에 따라 새로운 리더로 요청을 재전송하게 됩니다. 이때 max inflight request, retries 설정에 따라 일부 데이터 유실, 순서 불일치가 발생할 수 있습니다. "추가 정보로, "Apache Kafka 테스트용 오픈소스 Data Stream Generator 공유" 관련 정보도 확인해보세요. Kafka 오픈소스 툴 : https://www.cloudbro.ai/t/apache-kafka-data-stream-generator/1439관련 질문 : https://www.cloudbro.ai/t/kafka-partition-kafka-producer/1170 https://www.cloudbro.ai/t/kafka-partition-kafka-producer/1170

Spring 채팅 Kafka vs. RabbitMQ

5개의 답변

#kafka 목록