Logstashとelasticsearchの間のデータブローカー/メッセージングシステムとしてのRedisとRabbitMQ

さまざまなマシンにインストールされているLogstashシッパーによってログ情報を収集し、1つのelasticsearchサーバーでデータにインデックスを付け、Kibanaをグラフィカルレイヤーとして使用するアーキテクチャを定義しています。Logstashの配送業者とelasticsearchの間に、配信を許可するための信頼性の高いメッセージングシステムが必要です。Logstashシッパーとelasticsearchの間、またはその逆のデータブローカー/メッセージングシステムとしてRedis over RabbitMQを選択する場合、どのような要素を考慮する必要がありますか？

RedisとRabbitMQの両方を評価した後、次の理由でブローカーとしてRabbitMQを選択しました。

1. RabbitMQを使用すると、SSL証明書を使用してブローカーに送信するデータを暗号化することにより、組み込みのセキュリティレイヤーを使用できます。つまり、誰もデータを盗聴したり、重要な組織データにアクセスしたりすることはありません。
2. RabbitMQは非常に安定した製品であり、ボトルネックになることなく、1秒あたりの大量のイベントと多くの接続を処理できます。
3. 私たちの組織では、すでにRabbitMQを使用しており、RabbitMQの使用に関する内部知識が豊富で、シェフとの統合も準備されています。

スケーリングに関して、RabbitMQには、冗長ブローカー環境を実装するためにロードバランサーに加えて使用できるクラスター実装が組み込まれています。

私のRabbitMQクラスターはアクティブアクティブですか、それともアクティブパッシブですか？

ここで、RabbitMQを使用することの弱点について説明します。

1. ほとんどのLogstashシッパーはRabbitMQをサポートしていませんが、一方、Beaverという名前の最良のシッパーには、問題なくRabbitMQにデータを送信する実装があります。
2. Beaverが現在のバージョンでRabbitMQを使用して行っている実装は、（私の目的では）パフォーマンスが少し遅く、1つのサーバーからの3000イベント/秒の速度を処理できず、サービスがクラッシュすることがありました。
3. 現在、RabbitMQのパフォーマンスの問題を解決し、Beaverシッパーをより安定させる修正に取り組んでいます。最初の解決策は、同時に実行でき、荷送人により多くの力を与えるプロセスを追加することです。2番目の解決策は、Beaverを変更して、データをRabbitMQに非同期で送信することです。これは、理論的にははるかに高速であるはずです。今週の終わりまでに両方のソリューションの実装を完了することを願っています。

ここで問題をフォローできます：https： //github.com/josegonzalez/python-beaver/issues/323

そして、ここでプルリクエストを確認してください：https： //github.com/josegonzalez/python-beaver/pull/324

さらに質問がある場合は、コメントを残してください。

Redisは、いくつかの基本的なメッセージブローカー機能があるにもかかわらず、Key Valueデータストアとして作成されます。

RabbitMQはメッセージブローカーとして作成されます。それは自然に多くのメッセージブローカー機能を持っています。

私はこのトピックについていくつかの研究を行ってきました。パフォーマンスが重要で永続性が重要でない場合は、RabbitMQが最適です。Redisは、異なる目的で開発されたテクノロジーです。

以下は、RedisでRabbitMQを使用するための長所のリストです。

• RabbitMQは、セキュリティの追加レイヤーであるSSLを使用するように構成できるAdvanced Message Queuing Protocol（AMQP）を使用します。
• 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を実行し、それを嫌っていました。もちろん、それはredisの経験が浅い（製品自体の問題ではない）可能性がありますが、パイプラインの中で最も弱いリンクであり、最も必要なときに常に失敗しました。