[解決済み] Logstashとelasticsearchの間のデータブローカー/メッセージングシステムとして、RedisとRabbitMQの比較

質問

様々なマシンにインストールされたLogstash shippersでログ情報を収集し、1つのelasticsearchサーバーに集中的にデータをインデックスし、Kibanaをグラフィック層として使用するアーキテクチャを定義しています。Logstash shippersとelasticsearchの間には、配信を許可するための信頼性の高いメッセージングシステムが必要です。Logstashシッパーとelasticsearchの間のデータブローカー/メッセージングシステムとして、またはその逆として、RabbitMQではなくRedisを選択する際に考慮すべき要因は何ですか？

どのように解決するのですか？

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

1. RabbitMQでは、SSL証明書を使用してブローカーに送信するデータを暗号化することにより、内蔵のセキュリティ層を使用することができます。
2. RabbitMQは非常に安定した製品で、ボトルネックになることなく、秒単位の大量のイベントと多くの接続を処理することができます。
3. 私たちの組織では、すでにRabbitMQを使用しており、その使用方法について社内の知識も豊富で、chefとの統合もすでに準備されていました。

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

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

さて、RabbitMQを使用する際の弱点についてです。

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

この問題はここで追うことができます。 https://github.com/josegonzalez/python-beaver/issues/323

また、プルリクエストはこちらで確認してください。 https://github.com/josegonzalez/python-beaver/pull/324

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