메시지 미들웨어는 메시지 전송 메커니즘 또는 메시지 큐 모드로 구성된 미들웨어 기술로, 플랫폼 독립적인 데이터 교환을 위한 효율적이고 신뢰할 수 있는 메시징 메커니즘을 사용하고, 데이터 통신을 기반으로 한 분산 시스템을 통합합니다. 현재 업계에는 RabbitMQ, ActiveMQ, ZeroMQ 등 훌륭한 메시지 미들웨어 제품들이 많지만, 프로젝트에서 어떤 것을 선택해야 할까요? 본 논문은 RabbitMQ, ZeroMQ, ActiveMQ, MSMQ, Redis, memcacheQ 등 메시지 큐 제품을 평가하고 비교합니다
여담: 여기서 먼저 작은 질문을 생각해볼 수 있습니다: "왜 웹 애플리케이션에서 메시지 큐 서비스가 필요한가?" ”
예를 들어, 많은 수의 삽입, 업데이트 및 기타 요청이 동시에 MySQL에 도착하여 수많은 행 락과 테이블 락, 그리고 결국 너무 많은 요청이 발생하여 너무 많은 연결 오류를 유발합니다. 메시지 큐를 사용하면 요청을 비동기적으로 처리할 수 있어 시스템의 부담을 덜어줍니다.
래빗MQ
Erlang으로 작성된 오픈 소스 메시지 큐로, AMQP, XMPP, SMTP, STOMP 등 여러 프로토콜을 지원하여 매우 무거우하고 엔터프라이즈 수준의 개발에 더 적합합니다. AMQP 프로토콜의 선도적인 구현체로, 브로커 아키텍처를 구현하여 메시지를 클라이언트로 전송하기 전에 중앙 노드에 대기열 상태로 보관할 수 있습니다. 라우팅, 부하 분산, 데이터 지속성 지원이 잘 되어 있습니다. 이 기능 덕분에 RabbitMQ는 사용하기 쉽고 배포가 용이하며, 라우팅, 부하 분산, 메시지 지속성 등 다양한 상황에 적합하며, 메시지 큐를 포함한 몇 줄의 코드만으로도 구현할 수 있습니다. 하지만 이로 인해 중앙 노드가 지연 시간을 증가시키고 메시지 캡슐화 후 더 커지기 때문에 확장성이 떨어지고 느려집니다. RabbitMQ를 설정하려면 대상 기기에 Erlang 환경을 설치해야 합니다.
이 이미지를 새 창에서 보려면 클릭하세요
? MQ(ZeroMQ)
특히 고처리량 수요 시나리오에서 가장 빠른 메시지 큐잉 시스템으로 알려져 있습니다. 이 시스템은 고처리량/저지연 시나리오를 위해 특별히 개발된 매우 가벼운 메시징 시스템으로, 금융 분야의 응용 분야에서 자주 찾아볼 수 있습니다. RabbitMQ와 비교했을 때, ZeroMQ는 많은 고급 메시지 시나리오를 지원하지만, ZeroMQ 프레임워크 내에서 소켓이나 장치 등 개별 블록을 구현해야 합니다.
? MQ(ZeroMQ)는 RabbitMQ가 잘하지 못하는 고급 또는 복잡한 큐를 구현할 수 있지만, 개발자들은 여러 기술 프레임워크를 스스로 결합해야 하며, 이 기술적 복잡성은 이 MQ의 성공적인 적용에 도전 과제입니다. ZeroMQ는 메시지 서버나 미들웨어를 설치하고 실행할 필요가 없어서 애플리케이션이 이 서비스 역할을 수행하므로 독특한 비미들웨어 모델을 가지고 있습니다. ZeroMQ 라이브러리를 참조하기만 하면 되고, NuGet을 사용해 설치할 수 있으며, 애플리케이션 간에 메시지를 자유롭게 보낼 수 있습니다. 하지만 ZeroMQ는 비영속 큐만 제공하므로, 기기가 다운되면 데이터가 손실됩니다. 그중 트위터의 Storm은 데이터 스트림 전송에 ZeroMQ를 사용합니다. ZeroMQ는 매우 유연하지만, 80페이지 분량의 매뉴얼을 꼭 읽어야 합니다(분산 시스템에 대해 쓴다면 꼭 읽어야 합니다).
ZeroMQ는 미들웨어 아키텍처가 없으며 서비스 프로세스와 실행이 필요하지 않습니다. 실제로 애플리케이션 엔드포인트가 이 서비스 역할을 수행합니다. 이 덕분에 배포가 매우 간단하지만, 문제가 생겼을 때 감시할 곳이 없다는 점이 걱정됩니다. 우리가 아는 한, ZeroMQ는 비영구 큐만 제공합니다. 필요한 곳에 자체 감사 및 데이터 복구 기능을 구현할 수 있습니다.
이 이미지를 새 창에서 보려면 클릭하세요
MSMQ
이것이 마이크로소프트 제품에서 유일하게 가치 있다고 여겨지는 요소입니다. MSMQ가 이런 작업을 처리할 수 있음을 증명한다면, 그들은 이 방식을 선택하게 될 것입니다. 중요한 건 이 기계가 복잡하지 않다는 거야, 오직 받고 보내는 것뿐이야; 최대 메시지 크기가 4MB라는 등 몇 가지 엄격한 제한이 있습니다. 하지만 MassTransit이나 NServiceBus 같은 소프트웨어에 연결하면 이러한 문제를 해결할 수 있습니다.
이 이미지를 새 창에서 보려면 클릭하세요
야프카/카프카
Kafka(여러 노드에 메시지를 배포하는 기능)는 2010년 12월 LinkedIn에서 개발하고 오픈소스로 개방한 분산 MQ 시스템으로, 현재는 고성능 교차 언어 분산 게시/구독 메시지 큐잉 시스템인 Apache의 인큐베이션 프로젝트입니다. Jafka는 Kafka의 업그레이드 버전인 Kafka 위에 인큐베이션되어 있습니다. 다음과 같은 특징을 가집니다: 빠른 지속성(fast persistence)으로, O(1) 시스템 오버헤드 하에서도 메시지를 지속할 수 있음; 일반 서버에서 10W/s의 처리량에 도달할 수 있는 고처리량; 완전 분산 시스템, 브로커, 프로듀서, 컨슈머 모두 분산을 기본적으로 지원하며 자동으로 복소 균형을 달성합니다. Hadoop 데이터의 병렬 로딩을 지원하며, 이는 로그 데이터 및 Hadoop과 같은 오프라인 분석 시스템에 적합한 솔루션이지만 실시간 처리의 한계가 있습니다. Kafka는 Hadoop의 병렬 로딩 메커니즘을 통해 온라인과 오프라인 메시지 처리를 통합하는데, 이는 이 주제에서 연구하는 시스템에도 중요합니다. Apache Kafka는 ActiveMQ에 비해 매우 가벼운 메시징 시스템이며, 매우 우수한 성능뿐만 아니라 분산 시스템으로도 잘 작동합니다.
이 이미지를 새 창에서 보려면 클릭하세요
Apache ActiveMQ
ActiveMQ는 RabbitMQ와 ZeroMQ의 중간 어딘가에 위치하며, ZemoMQ와 유사하게 프록시 및 P2P 모드 모두에서 배포할 수 있습니다. RabbitMQ와 유사하게 고급 시나리오 구현이 쉽고 소비가 적습니다.
ActiveMQ는 Java 세계의 중추로 알려져 있습니다. 이 방법은 오랜 역사를 가지고 있으며 널리 사용되고 있습니다. 또한 크로스 플랫폼으로, 마이크로소프트 플랫폼에 없는 제품들도 자연스럽게 통합할 수 있는 접근 지점을 제공합니다. 하지만 MSMQ를 통과한 경우에만 고려 대상이 될 수 있습니다. ActiveMQ를 구성하려면 대상 기기에 Java 환경을 설치해야 합니다.
이 이미지를 새 창에서 보려면 클릭하세요
ActiveMQ의 차세대 제품은 Apollo로, ActiveMQ 프로토타입을 기반으로 하며 더 빠르고 신뢰할 수 있으며 유지보수가 쉬운 메시지 브로커 도구입니다. Apache는 Apollo를 가장 빠르고 견고한 STOMP(스트리밍 텍스트 지향 메시지 프로토콜) 서버라고 부릅니다.
아폴로의 특징은 다음과 같습니다:
Stomp 1.0 및 Stomp 1.1 프로토콜을 지원합니다
주제와 대기열
큐 브라우저
테마 지속 구독
미러 큐
신뢰할 수 있는 메시지
메시지 만료 및 교환
메시지 선택기
JAAS 검증
ACL 기반 권한 부여
SSL/TLS 및 인증서 검증 지원
REST 관리 API
이 이미지를 새 창에서 보려면 클릭하세요
레디스
이 데이터베이스는 Key-Value NoSQL 데이터베이스로, 적극적으로 개발 및 유지 관리되고 있지만, Key-Value 데이터베이스 저장 시스템이지만 MQ 함수를 지원하므로 경량 큐 서비스로 사용할 수 있습니다. RabbitMQ와 Redis의 온보딩 및 아웃큐 작업은 각각 100만 회씩 기록하며, 실행 시간은 10만 번마다 기록됩니다. 테스트 데이터는 128바이트, 512바이트, 1K, 10K 네 가지 크기로 나뉩니다. 실험 결과, 팀에 합류했을 때 데이터 비교가 작을 때 Redis의 성능이 RabbitMQ보다 높으며, 데이터 크기가 10K를 초과하면 Redis가 견딜 수 없을 만큼 느립니다. 팀을 떠났을 때 Redis는 데이터 크기와 상관없이 매우 좋은 성능을 보였고, RabbitMQ의 성능은 Redis보다 훨씬 낮았습니다.
멤캐시Q
영속 메시지 큐 Memcacheq(줄여서 MCQ)는 경량 메시지 큐이며, MemcacheQ의 특징은 다음과 같습니다:
1 간단하고 사용하기 쉽습니다
2 빠른 처리
3 다중 큐
4 양호한 동시성 성능
5 멤캐시 프로토콜과 호환됨. 즉, memcache 확장 프로그램만 설치하면 추가 플러그인이 필요 없습니다.
6 또한 zend 프레임워크에서 사용하기 편리합니다.
궁극적으로 이 제품들은:
1. 두 프로그램 모두 자체 클라이언트 API를 가지고 있거나 여러 프로그래밍 언어를 지원합니다;
2. 문서가 매우 많습니다;
3. 긍정적인 지원이 제공되었습니다.
4. ActiveMQ, RabbitMQ, MSMQ, Redis는 모두 서비스 프로세스를 시작해야 하며, 이는 모니터링 및 구성할 수 있고, 나머지는 문제가 있습니다
5. 이들 모두 비교적 우수한 신뢰성(일관성), 확장성 및 부하 분산, 그리고 물론 성능
여기서 쓸데없는 말은 하지 않겠습니다. 아래에 첨부한 것은 인터넷에서 가로챈 검사 결과 모음입니다. 초당 주고받은 메시지 수가 표시됩니다. 전체 과정으로 총 100만 건의 1K 메시지가 생성되었습니다. 테스트는 Windows Vista 독립형 컴퓨터에서 수행되었습니다.
보시다시피, ZeroMQ는 다른 어떤 레벨과도 다릅니다. 성능이 놀라울 정도로 높습니다. 그럼에도 불구하고 이 제품은 메시지 지속성을 제공하지 않고, 중간 프로세스를 쉽게 저장하고 모니터링할 수 없으며, 자체 감사와 데이터 복구가 필요해 사용 편의성과 HA 측면에서 만족스럽지 못합니다. 결론은 명확합니다: 앱이 가능한 한 빨리 메시지를 보내길 원한다면 ZeroMQ를 선택해야 합니다. 특정 메시지를 우연히 잃어버리는 것에 크게 신경 쓰지 않을 때 더 가치가 있습니다.
이 글의 블로거는 Rabbit을 사용하기를 희망하지만(크게 바라지는 않습니다), Rabbitmq에는 내장 하하(ha) 기능이 있습니다. 클러스터를 구성하면 부하 분산 같은 문제를 걱정할 필요가 없고, 큐 미러도 설정할 수 있습니다. 하지만 이런 경우에는 더 많은 테스트가 필요하고, 결국 좋아하는 제품을 찾게 되고, 제가 Rabbit에 대해 듣고 읽은 모든 이야기를 보면 Rabbit이 최선의 선택이어야 한다고 느낍니다.
|
게시됨 2016. 12. 15. 오전 10:52:40
|
|
|
|
