Logstash와 Elasticsearch 사이의 데이터 브로커 / 메시징 시스템으로서 Redis Vs RabbitMQ

Logstash와 Elasticsearch 사이의 데이터 브로커 / 메시징 시스템으로서 Redis Vs RabbitMQ

---

다양한 머신에 설치되어있는 Logstash 배송 업체의 로그 정보를 수집하고 하나의 Elasticsearch 서버에 데이터를 중앙에서 인덱싱하고 Kibana를 그래픽 레이어로 사용하는 아키텍처를 정의하고 있습니다. Logstash 배송 업체와 Elasticsearch 사이에 안정적인 메시징 시스템이 필요합니다. Logstash 배송 업체와 Elasticsearch 사이 또는 그 반대의 경우 데이터 브로커 / 메시징 시스템으로 RabbitMQ보다 Redis를 선택할 때 고려해야 할 요소는 무엇입니까?

---

Redis와 RabbitMQ를 모두 평가 한 후 다음과 같은 이유로 RabbitMQ를 브로커로 선택했습니다.

1. RabbitMQ를 사용하면 SSL 인증서를 사용하여 브로커에 보내는 데이터를 암호화하여 내장 된 보안 계층을 사용할 수 있으며 이는 아무도 데이터를 스니핑하고 중요한 조직 데이터에 액세스 할 수 없음을 의미합니다.
2. RabbitMQ는 병목 현상없이 초당 많은 이벤트와 많은 연결을 처리 할 수있는 매우 안정적인 제품입니다.
3. 우리 조직에서는 이미 RabbitMQ를 사용했으며 사용에 대한 내부 지식과 요리사와의 통합을 이미 준비했습니다.

확장과 관련하여 RabbitMQ에는 중복 브로커 환경을 구현하기 위해로드 밸런서와 함께 사용할 수있는 클러스터 구현이 내장되어 있습니다.

내 RabbitMQ 클러스터가 액티브 액티브 또는 액티브 패시브입니까?

이제 RabbitMQ 사용의 약점을 살펴 보겠습니다.

1. 대부분의 Logstash 배송 업체는 RabbitMQ를 지원하지 않지만 반면에 Beaver라는 최고의 배송 업체는 문제없이 RabbitMQ로 데이터를 전송하는 구현을 가지고 있습니다.
2. Beaver가 현재 버전에서 RabbitMQ와 함께 구현 한 것은 성능이 약간 느리고 (내 목적을 위해) 한 서버에서 초당 3000 개의 이벤트 속도를 처리 할 수 ​​없었고 때때로 서비스가 중단되었습니다.
3. 현재 RabbitMQ의 성능 문제를 해결하고 Beaver 배송 업체를보다 안정적으로 만드는 수정 작업을 진행 중입니다. 첫 번째 해결책은 동시에 실행할 수있는 프로세스를 더 추가하여 발송인에게 더 많은 전력을 제공하는 것입니다. 두 번째 해결책은 이론적으로 훨씬 빨라야하는 데이터를 RabbitMQ에 비동기 적으로 전송하도록 Beaver를 변경하는 것입니다. 이번 주 말까지 두 가지 솔루션 구현을 완료하기를 바랍니다.

여기에서 문제를 따를 수 있습니다 : https://github.com/josegonzalez/python-beaver/issues/323

그리고 여기에서 pull 요청을 확인하십시오 : https://github.com/josegonzalez/python-beaver/pull/324

더 많은 질문이 있으면 의견을 남겨주세요.

---

Redis는 몇 가지 기본 메시지 브로커 기능이 있음에도 불구하고 키 값 데이터 저장소로 생성됩니다 .

RabbitMQ는 메시지 브로커로 생성됩니다. 자연스럽게 많은 메시지 브로커 기능이 있습니다.

---

나는이 주제에 대해 약간의 연구를하고있다. 성능이 중요하고 지속성이 중요하지 않은 경우 RabbitMQ는 완벽한 선택입니다. Redis는 다른 의도로 개발 된 기술입니다.

다음은 Redis를 통해 RabbitMQ를 사용하는 전문가 목록입니다.

• RabbitMQ는 추가 보안 계층 ​​인 SSL을 사용하도록 구성 할 수있는 AMQP (Advanced Message Queuing Protocol)를 사용합니다.
• RabbitMQ는 Redis가 메시지를받는 데 걸리는 시간의 약 75 %가 걸립니다.
• RabbitMQ는 작업자가 우선 순위가 높은 메시지를 먼저 소비하는 데 사용할 수있는 메시지 우선 순위를 지원합니다.
• 메시지를 사용한 후 작업자가 충돌하면 메시지를 잃을 가능성이 없습니다. 이는 Redis의 경우가 아닙니다.
• RabbitMQ에는 메시지를 다른 대기열로 보내는 좋은 라우팅 시스템이 있습니다.

RabbitMQ 사용에 대한 몇 가지 단점 :

• RabbitMQ는 유지 관리가 약간 어렵고 충돌을 디버그하기 어려울 수 있습니다.
• node-name 또는 node-ip 변동은 데이터 손실을 유발할 수 있지만 잘 관리하면 내구성있는 메시지로 문제를 해결할 수 있습니다.

---

나는 똑같은 것을 궁금해하고 있습니다. Logstash 사람들의 이전 권장 사항은 RabbitMQ ( http://logstash.net/docs/1.1.1/tutorials/getting-started-centralized ) 보다 Redis를 권장 하지만 메모의 해당 섹션은 현재 문서에 더 이상 존재하지 않지만 브로커를 사용하여 스파이크를 처리하는 방법에 대한 일반적인 참고 사항은 여기 https://www.elastic.co/guide/en/logstash/current/deploying-and-scaling.html .

RabbitMQ도 매우 행복하게 사용하고 있지만 AMQP 프로토콜이 로깅 사용 사례에 과잉 일 가능성이 높기 때문에 현재 Redis 브로커를 탐색하고 있습니다.

---

물어볼 빠른 질문 :

1. 왜 브로커가 필요한가요? logstash 또는 logstash-forwarder를 사용하여 이러한 서버에서 파일을 읽는 경우 파이프 라인이 정체되면 둘 다 느려집니다.
2. 래빗이나 레디 스를 관리 한 경험이 있습니까? 모든 것이 동일하면 사용 방법을 아는 도구가 더 나은 도구입니다.

의견의 영역에서 저는 redis를 브로커로 운영하고 싫어했습니다. 물론 redis에 대한 경험이 없었을 수도 있지만 (제품 자체의 문제는 아님) 파이프 라인에서 가장 약한 링크 였고 우리가 가장 필요할 때 항상 실패했습니다.

참고 URL : https://stackoverflow.com/questions/29539443/redis-vs-rabbitmq-as-a-data-broker-messaging-system-in-between-logstash-and-elas