RabbitMQ와 Kafka - 메시지 대기열 시스템 간의 차이점 - AWS

[RabbitMQ를 채팅에 사용하는 이유] - 경량, 신속, 유연성

• 지연 시간이 낮기 때문에
  • 메모리 기반 메시징 지원
  • kafka는 디스크 기반 저장으로 디스크 I/O로 인해 지연 시간이 더 높음
• 메시지 브로커
  • 보다 능동적인 역할을 함
• 메시지 전달 보장
  • 메시지의 배달 확인(Delivery Acknowledgments) 기능을 통해 메시지가 안전하게 수신 확인할 수 있습니다.
• 유연한 라우팅
  • 다양한 타입의 Exchange를 통해 메시지를 적절한 큐로 효율적으로 라우팅할 수 있음, 채팅 애플리케이션에서 코인 별 그룹으로 메시지를 타겟팅해야함
• 경량 프로토콜 RabbitMQ는 AMQP(Advanced Message Queuing Protocol)을 사용하여 메시지를 처리하며, 이는 비교적 경량의 프로토콜입니다. 이러한 경량 프로토콜은 네트워크 오버헤드를 줄여주어, 채팅과 같은 실시간 애플리케이션에서 낮은 지연성을 제공하는 데 유리합니다.
• 관리자를 위한 관리 인터페이스가 잘 구성되어 있어, 시스템의 상태를 쉽게 모니터링하고 조정할 수 있습니다. 채팅 애플리케이션 개발과 운영을 단순화 가능
• 높은 신뢰성과 클러스터링
  • RabbitMQ는 높은 가용성과 클러스터링을 지원합니다. 이는 채팅 서비스의 연속성을 유지하고, 다운타임 없이 서비스를 계속 제공할 수 있게 해줍니다. 클러스터링을 통해 로드를 분산시키고, 노드 장애에도 메시지 서비스를 지속할 수 있습니다.

[Kafka를 거래 처리에 사용하는 이유] - 대규모, 높은 신뢰성

• 메시지를 분산 커밋 로그에 저장하므로 높은 확장성과 내결함성을 제공해 손실되면 안되는 정보인 거래 데이터를 보장하고 거래 요청이 많아졌을 경우 높은 처리량을 보장함.
• Pull 기반 메시지 소비: RabbitMQ와 ActiveMQ는 브로커가 컨슈머로 메시지를 Push 하는 방식인데 반해, 카프카는 컨슈머가 능동적으로 브로커로부터 메시지를 가져오는 Pull 방식을 취했다. 이로 인해 컨슈머는 처리 능력에 따라 메시지를 컨슘할 수 있기 때문에, 브로커로부터 압도당하지 않고 최적의 성능을 낼 수 있다. 거래 서버에서 거래 처리 속도가 차이나더라도 최적의 성능을 낼 수 있지 않을까 싶음
• 확장성
  • Kafka는 수평적 확장성이 뛰어나며, 클러스터 내에 노드를 추가함으로써 처리 능력을 쉽게 증가시킬 수 있습니다. 큰 규모의 거래 시스템에서 거래 ID의 늘어나는 처리 요구를 쉽게 수용할 수 있습니다. MSA아키텍처로 개선한 것과 같은 이치
• 메시지 순서 유지
  • Kafka는 토픽의 파티션 내에서 메시지의 순서를 유지합니다. 거래와 같이 순서가 중요한 작업에서는 이러한 순서 보장이 중요하며, 거래 처리의 정확성과 일관성을 유지하는 데 도움이 됩니다.
• 비동기 처리 작업
  • 스트림 처리 기능을 통해 복잡한 데이터 처리 및 분석 작업을 지원하기 때문에 비동기 팔로잉 거래 처리에 적합해보임