メッセージキューミドルウェアの技術的選択分析

クズども · 掲載地 2016/12/15 10:52:40

メッセージミドルウェアは、メッセージ伝送メカニズムまたはメッセージキューモードから成るミドルウェア技術であり、プラットフォームに依存しないデータ交換のための効率的かつ信頼性の高いメッセージング機構を用い、データ通信に基づく分散システムを統合しています。現在、RabbitMQ、ActiveMQ、ZeroMQなど、優れたメッセージミドルウェアとして業界には多くのMQ製品がありますが、プロジェクトでどれを選ぶべきでしょうか? 本論文では、RabbitMQ、ZeroMQ、ActiveMQ、MSMQ、Redis、memcacheQのメッセージキュー製品を評価・比較します

脱線:まず小さな質問を考えましょう:「なぜウェブアプリケーションにメッセージキューサービスが必要なのか?」 ”
例えば、多数の挿入、更新、その他のリクエストが同時にMySQLに届き、無数の行ロックやテーブルロック、さらには最終的にリクエストが多すぎて、接続エラーが多すぎます。メッセージキューを利用することで、リクエストを非同期的に処理でき、システムの負担を軽減できます。

RabbitMQ
これはErlangで書かれたオープンソースのメッセージキューで、AMQP、XMPP、SMTP、STOMPなど多くのプロトコルをサポートしているため、非常に重く、エンタープライズレベルの開発により適しています。これはAMQPプロトコルの主要な実装であり、ブローカーアーキテクチャを実装しており、メッセージをクライアントに送信する前に中央ノードにキューに入れることができます。ルーティング、ロードバランシング、データ永続性のサポートも良好です。この機能によりRabbitMQは使いやすく展開されやすくなり、ルーティング、ロードバランシング、メッセージ永続化など多くのシナリオに適しており、メッセージキューを使った数行のコードで実現可能です。しかし、中央ノードが遅延を増やし、メッセージカプセル化後に大きくなるため、スケーラビリティが低く遅くなります。 RabbitMQを設定するには、ターゲットマシンにErlang環境をインストールする必要があります。
この画像を新しいウィンドウで見るにはクリック

? MQ(ZeroMQ)
特に高スループットの需要シナリオにおいて、最速のメッセージキューイングシステムとして知られています。これは高スループット・低遅延シナリオ向けに開発された非常に軽量なメッセージングシステムで、金融業界のアプリケーションでよく見られます。 RabbitMQと比べて、ZeroMQは多くの高度なメッセージシナリオをサポートしていますが、ZeroMQフレームワーク内でソケットやデバイスなどの個別のブロックを実装する必要があります。

? MQ(ZeroMQ)はRabbitMQが得意でない高度な複雑なキューを実装できますが、開発者は複数の技術的フレームワークを組み合わせる必要があり、その技術的複雑さがこのMQの成功的な適用にとって課題となっています。 ZeroMQは独自の非ミドルウェアモデルを持っており、メッセージサーバーやミドルウェアのインストールや運用が不要で、アプリケーションがこのサービスの役割を担います。必要なのはZeroMQライブラリを参照するだけで、NuGetを使ってインストールでき、アプリケーション間でメッセージを問題なく送信できます。しかし、ZeroMQは非永続的なキューのみを提供しているため、マシンがダウンするとデータは失われます。その中でも、TwitterのStormはZeroMQをデータストリームの送信手段として使用しています。 ZeroMQは非常に柔軟ですが、80ページのマニュアルを覚える必要があります(分散システムについて書く場合は必ず読んでください)。

ZeroMQはミドルウェアアーキテクチャを持たず、サービスプロセスや実行を必要としません。実際、アプリケーションエンドポイントがこのサービスの役割を担っています。これにより導入が非常に簡単ですが、問題が起きたときに監視できる場所がないのが心配です。私たちの知る限り、ZeroMQは非永続的なキューのみを提供しています。必要なところで独自の監査やデータ復旧機能を実装できます。
この画像を新しいウィンドウで見るにはクリック

MSMQ
これがマイクロソフトの製品の中で唯一価値があるとされる要素です。 MSMQがこの種のタスクをこなせると証明できれば、利用を選ぶでしょう。要するに、このものは複雑ではなく、送受信だけだ。最大メッセージサイズが4MBという厳しい制限があります。しかし、MassTransitやNServiceBusのようなソフトウェアに接続することでこれらの問題を解決できます。
この画像を新しいウィンドウで見るにはクリック

ヤフカ/カフカ
Kafka(異なるノード間でメッセージを配信する)は、2010年12月にLinkedInによって開発・オープンソース化された分散型MQシステムであり、現在は高性能なクロスランゲージ分散型Publish/SubscribeメッセージキューイングシステムであるApacheのインキュベーションプロジェクトとなっています。また、JafkaはKafkaのアップグレード版であるKafkaの上にインキュベーションされています。以下の特性があります:高速持続性(O(1)のシステムオーバーヘッドでもメッセージを永続化できる; 高スループットは、通常のサーバーで10W/sのスループットレートに達することもあります。完全分散システム、ブローカー、プロデューサー、コンシューマーはいずれもネイティブで分散をサポートし、自動的に複素均衡を実現します。 Hadoopデータの並列読み込みをサポートしており、Hadoopのようなログデータやオフライン解析システムに有効なソリューションですが、リアルタイム処理の制約があります。 KafkaはHadoopの並列ロード機構を通じてオンラインとオフラインのメッセージ処理を統合しており、これはこのテーマで研究するシステムにとっても重要です。 Apache KafkaはActiveMQに比べて非常に軽量なメッセージングシステムであり、非常に優れたパフォーマンスに加え、分散型システムで動作も良好です。
この画像を新しいウィンドウで見るにはクリック

Apache ActiveMQ
ActiveMQはその中間(RabbitMQとZeroMQ)に位置し、ZemoMQに似ており、プロキシモードとP2Pモードの両方で展開可能です。 RabbitMQと同様に、高度なシナリオの実装が容易で、消費も少なく済みます。
ActiveMQはJavaの世界の基盤として知られています。長い歴史があり、広く使われています。また、クロスプラットフォームであり、Microsoftプラットフォームにない製品にも自然な統合アクセスポイントを提供します。ただし、MSMQを通過した場合にのみ考慮可能です。 ActiveMQを設定するには、ターゲットマシンにJava環境をインストールする必要があります。
この画像を新しいウィンドウで見るにはクリック
ActiveMQの次世代製品はApolloであり、ActiveMQのプロトタイプをベースにしており、より高速で信頼性が高く、メンテナンスも容易なメッセージブローカーツールであることに注意が必要です。 ApacheはApolloを最も高速かつ堅牢なSTOMP(ストリーミングテキスト指向メッセージプロトコル)サーバーと呼んでいます。
アポロの特徴は以下の通りです:
Stomp 1.0およびStomp 1.1プロトコルがサポートされています
トピックとキュー
キューブラウザ
テーマ永続購読
ミラーキュー
信頼性の高いメッセージング
メッセージの有効期限と交換
メッセージピッカー
JAAS認証済み
ACLベースの認可
SSL/TLSおよび証明書検証のサポート
REST Management API
この画像を新しいウィンドウで見るにはクリック

レディス
これはKey-ValueのNoSQLデータベースであり、積極的に開発・維持されていますが、Key-Valueデータベースのストレージシステムでありながら、MQ関数をサポートしているため、軽量なキューサービスとして利用できます。 RabbitMQとRedisのオンボーディングおよびアウトキュー操作はそれぞれ100万回ずつ記録され、実行時間は10万回ごとに記録されます。テストデータは4つの異なるサイズに分けられています:128バイト、512バイト、1K、10Kです。実験によると、チームに参加した時点で、データ比較が小さい場合、RedisのパフォーマンスはRabbitMQよりも優れており、データサイズが10Kを超えるとRedisは耐え難いほど遅くなります。チームを離れると、Redisはデータサイズに関わらず非常に良いパフォーマンスを示しましたが、RabbitMQのパフォーマンスはRedisよりかなり低かったです。

MemcacheQ
永続メッセージキューMemcacheq(略してMCQ)は軽量なメッセージキューであり、MemcacheQの特徴は以下の通りです。
1 シンプルで使いやすい
2 高速処理
3 複数キュー
4 良好な並行処理性能
5 Memcacheプロトコルと互換性があります。つまり、memcache拡張機能をインストールするだけで済み、追加のプラグインは不要です。
6 zendフレームワークでの使用も便利です。

最終的に、以下の製品:
1. 両者とも独自のクライアントAPIを持つか、複数のプログラミング言語をサポートしています。
2. 多くのドキュメントがあります。
3. 積極的な支援が提供された。
4. ActiveMQ、RabbitMQ、MSMQ、Redisはすべてサービスプロセスを開始する必要があり、これらは監視・設定可能ですが、他のプロセスは問題があります
5. これらはすべて比較的高い信頼性(一貫性)、スケーラビリティ、負荷分散、そしてもちろんパフォーマンスを提供します

ここでナンセンスはしません。以下にインターネットから盗用した検査結果のセットを添付します。 1秒あたりに送受信されたメッセージの数が表示されます。このプロセス全体で合計100万件の1Kメッセージが生成されました。テストはWindows Vistaのスタンドアロンマシンで実施されました。

ご覧の通り、ZeroMQは他のどんなレベルとも違います。その性能は驚くほど高いです。それにもかかわらず、この製品はメッセージの永続性を提供せず、中間プロセスの保存や監視が容易で、自己監査やデータ復旧が必要なため、使いやすさやHAの面で満足のいくものではありません。結論は明白です:アプリにできるだけ速くメッセージを送らせたいなら、ZeroMQを選ぶべきです。偶然に特定のメッセージを失うことをあまり気にしない方が、より価値があります。

この記事のブロガーはRabbitを使いたいと思っています(あまり望んでいませんが)、Rabbitmqには組み込みのha機能があり、クラスタを形成すればロードバランシングなどの問題を気にする必要がなく、キューミラーも設定できます。しかし、こういうのはもっとテストが必要で、最終的にお気に入りが決まるということです。Rabbitについて聞いたり読んだりしたことから、それが最良の選択であるべきだと感じています。

メッセージキューミドルウェアの技術的選択分析

関連記事

閲覧したセクション