ABOUT ME

-

Today
-
Yesterday
-
Total
-
  • [메시지큐] Kafka, RabbitMQ 비교 및 쓰는 이유
    개발 2021. 7. 21. 21:39

    https://ellune.tistory.com/29

    메시지 큐는 왜 쓸까?

    메시지 큐는 주로 어플리케이션의 요청에 대해 서버가 실시간으로 응답해야 할 때 사용한다.

    Application 과 서버가 강하게 결합되어 있을 경우, db나 백엔드 단에서 문제가 발생하면 어플리케이션에도 장애가 발생한다. 즉 서버와 어플리케이션 간의 의존성이 높다.

     

     

    메시지큐 동작 방식

    메시지큐를 사용하면..

    1. 느슨하게 결합된 설계
    2. 어플리케이션 아키텍쳐가 DB성능에 영향을 덜 받는다.
    3. 여러 다른 API 로부터 비동기 통신이 가능하다
    4. 다수의 프로세스로부터 메시지 처리 가능
    5. 비동기: Queue 에 넣기 때문에 나중에 처리 가능

    메시지 큐 종류

    Kafka

    RabbitMQ

    ActiveMQ

     

    셋 다 비동기 통신하고, Sender 와 Receiver 를 구분하지만, 각 기술은 만들어진 목적이 다르다.

    1. RabbitMQ

    AMQP 프로토콜을 구현해 놓았고, 직관적.

    AMQP 란?
    - Advanced Message Queing Protocal
    - 다 기종 간에도 호환이 되는 메시지큐 프로토콜
    여기를 참고

    장점

    • 신뢰성, 안정성 -> 나온지 오래되었음.
    • 유연한 라우팅 (Message Queue가 도착하기 전에 라우팅 되며 플러그인을 통해 더 복잡한 라우팅도 가능)
    • 클러스터링 (로컬네트워크에 있는 여러 RabbitMQ 서버를 논리적으로 클러스터링할 수 있고 논리적인 브로커도 가능)
    • 관리 UI의 편리성 (관리자 페이지 및 모니터링 페이지가 제공됨)
    • 거의 모든 언어 및 운영체제를 지원

     

    2. Kafka ← Saas 로 제공

    확장성과 고성능 및 높은 처리량. 대용량 데이터 특화 시스템이기 때문에 범용으로는 적합하지 않음.

    분산 시스템을 설계 → 분산, 복제 구성 쉽게 가능.

    장점

    • 대용량 실시간 로그 처리에 특화되어 있다
    • AMQP 프로토콜이나 JSM API를 사용하지 않고 단순한 메시지 헤더를 지닌 TCP 기반 프로토콜 사용함으로써 오버헤드가 비교적 작다.
    • 노드 장애에 대한 대응성을 가지고 있다
    • 프로듀서는 각 메시지를 배치로 브로커에게 전달하여 TCP/IP 라운드 트립을 줄였다
    • 메시지를 기본적으로 파일 시스템에 저장하여 별도의 설정을 하지 않아도 오류 발생 시 오류 지점부터 복구가 가능하다 (기존 메시징 시스템은 메시지를 메모리에 저장)
    • 메시지를 파일시스템에 저장하기 때문에 메시지가 많이 쌓여도 기존 메시징 시스템에 비해 성능이 크게 감소하지 않는다

    번외: https://wedul.site/577

    Kafka 는 기존 싱글 메시지 큐 방식과 Pub/Sub 방식의 장점만 차용하였다. 이부분 너무 어렵다

    여기를 참고

     

    3. ActiveMQ

    ActiveMQ는 자바로 만든 오픈소스 메시지 브로커

    장점

    • 다양한 언어와 프로토콜 지원 (Java, C, C++, C#, Ruby, Perl, Python, PHP클라이언트 지원)
    • OpenWire를 통해 고성능의 Java, C, C++, C# 클라이언트 지원
    • Stomp를 통해 C, Ruby, Perl, Python, PHP 클라이언트가 다른 인기있는 메시지 브로커들과 마찬가지로 ActiveMQ에 접근 가능
    • Message Groups, Virtual Destinations, Wildcards와 Composite Destination를 지원
    • Spring 지원으로 ActiveMQ는 Spring Application에 매우 쉽게 임베딩될 수 있으며, Spring의 XML 설정 메커니즘에 의해 쉽게 설정 가능
    • Geronimo, JBoss 4, GlassFish, WebLogic과 같은 인기있는 J2EE 서버들과 함께 테스트됨
    • 고성능의 저널을 사용할 때에 JDBC를 사용하여 매우 빠른 Persistence를 지원
    • REST API를 통해 웹기반 메시징 API를 지원
    • 웹 브라우저가 메시징 도구가 될 수 있도록, Ajax를 통해 순수한 DHTML을 사용한 웹 스트리밍 지원

    그래서 뭘 쓸까?

    성능비교: 메시지 소비량 비교

    간단하게 Kafka 와 RabbitMQ 를 비교해 보자면, 메시지 Consumption 에 있어서 차이가 많이 난다.

    애초에 클러스터 환경에서 대용량 트래픽을 감당 하기 위해 탄생한 카프카이니, 분산 / 고성능을 추구한다면 카프카를 사용하는게 맞는 것 같다.

    프로그램이나 트래픽 규모가 분산까지 필요 없을 거라면 오히려 RabbitMQ 가 나을 수 있다. 제품이 나온지 오래 되었고, 구성이 자유롭다는 점에서 카프카보다 이점이 있다.

    분산 / 대용량 메시지 처리 / 고성능 / 노드 장애 대응 기능이 필요하다면 Kafka 를, 상용성과 구성의 자유도가 중요하다면 RabbitMQ 를 사용하는 것이 좋다고 생각한다.

     

    실무적으로는 트래픽을 많이 감당하는 대기업에서 대부분 카프카를 사용하는 것 같긴 하다.. (?)

     

Designed by Tistory.