RabbitMQ と Redis OSS はどのように異なりますか?
RabbitMQ はメッセージブローカーであり、Remote Dictionary Server (Redis OSS) はインメモリ key-value データストアです。しかし、両方を使用してパブリッシュ/サブスクライブ (pub/sub) メッセージングシステムを作成できるので、この 2 つのテクノロジーは比較することができます。モダンクラウドアーキテクチャでは、アプリケーションはサービスと呼ばれる、より小さな独立したビルディングブロックに分離されます。Pub/Sub メッセージングは、これらの分散システムに即時のイベント通知を提供します。RabbitMQ は、複数のソースからストリーミングデータを収集してさまざまな送信先にルーティングして処理する分散型メッセージブローカーです。Redis OSS は、イベントが発生したときにパブリッシャーがすべてのサブスクライバーにメッセージを配信するプッシュベースのシステムをサポートします。
仕組み: RabbitMQ とRedis OSS
RabbitMQ と Redis OSS はいずれも、アプリケーション、マイクロサービス、およびソフトウェアコンポーネントがさまざまな方法でメッセージを交換できるようにします。
RabbitMQ のワークフロー
RabbitMQ は Advanced Message Queuing Protocol (AMQP) を使用して、メッセージブローカーを通じてメッセージを安全に送信します。メッセージブローカーはエクスチェンジとキューで構成されています。プロセスは次のように機能します。
- データプロデューサーは RabbitMQ にメッセージを送信する
- エクスチェンジはデータを受信し、バインディングと呼ばれる一連のルールに従ってそれぞれのキューにデータをルーティングする
- メッセージは、RabbitMQ コンシューマーが受信するまでキューに残る
キューが最大容量に達すると、RabbitMQ はコンシューマーが未読メッセージを処理するまでプロデューサーがメッセージを公開しないようにします。RabbitMQ は、コンシューマーがメッセージを読む前に交換に失敗した場合、メッセージを復元することもできます。
Redis OSS ワークフロー
Redis OSS は、リスト、セット、ハッシュ、ビットマップなどのさまざまなデータ構造をサポートするデータ構造サーバーとして設計されています。これにより、クライアントアプリケーションはほぼすべてのデータ型を保存、取得、および処理できます。Redis OSS は保存されたデータを key-value ペアで整理します。これにより、クライアントアプリケーションをサブスクライブするための構造化された配置が提供されます。
たとえば、e コマースデータをカスタマー名、E メール、購入した商品、およびフィードバックキーに分けることができます。その後、各キーの関連データを公開します。
Redis OSS は、短い保持メッセージのリアルタイムでの交換を可能にします。以下のように機能します。
- データプロデューサーが Redis OSS にメッセージを送信する
- Redis OSS ノードはメッセージキーをチェックして関心のあるサブスクライバーを特定する
- Redis OSS が、接続しているすべてのサブスクライバーにメッセージを配信する
メッセージ処理: RabbitMQ とRedis OSS Pub/Sub
Redis OSS と RabbitMQ はいずれも、アプリケーションがクラウド環境全体でメッセージを配信するためのパブリッシュ/サブスクライブ (Pub/Sub) メカニズムを提供します。ただし、メッセージ処理は大きく異なります。
メッセージの配信
RabbitMQ は Advanced Message Queuing Protocol (AMQP) を使用して複雑なルーティングロジックをサポートします。メッセージをポイントツーポイントで配信することも、1 人のプロデューサーから多くのコンシューマーに配信することもできます。メソッドに関係なく、すべてのコンシューマーはプロデューサーにメッセージ確認応答を送信して、正常に読み取られたことを確認します。プロデューサーが確認を受け取らなかった場合、異なる間隔で数回再試行されます。
一方、Redis OSS は接続しているすべてのサブスクライバーにメッセージをプッシュするだけであり、メッセージの配信を保証するものではありません。着信メッセージを受け取るには、サブスクライバーは Redis OSS サーバーに接続している必要があります。Redis OSS の接続が切断されると、すべてのメッセージを取得できなくなる可能性があります。
メッセージサイズ
RabbitMQ は、パフォーマンスを大幅に低下させることなく、より大きなメッセージを配信できます。当初は最大 2 GB のメッセージを処理するように設計されていましたが、後に制限が 128 MB に引き下げられました。
逆に、Redis OSS では保存されるメッセージの制限は定義されていませんが、1 MB を超えるメッセージには著しいレイテンシーが発生します。そのため、デベロッパーは通常、文字列、ハッシュ、リスト、およびセットなどのデータセットを処理するためのキャッシュとして Redis を使用します。
メッセージの永続性
RabbitMQ は永続的メッセージと一時的メッセージをサポートしています。永続キューにメッセージを送信すると、データが到着するとすぐに永続的ストレージに書き込みます。RabbitMQ は一時的メッセージもディスクに書き込みますが、これはメモリの容量を超える場合に限られます。
一方、Redis OSS はデフォルトでは永続的メッセージをサポートしていません。デベロッパーは Redis OSS Database (RDB) と呼ばれる機能を有効にして、RAM のスナップショットを定期的に取得し、ディスクに保存する必要があります。Redis OSS でデータの永続性を有効にすると、データオペレーションにオーバーヘッドが加わり、メッセージ配信が遅くなります。もう 1 つの方法は、非同期レプリケーションのようなリカバリ手法を使用することです。
メッセージの暗号化
RabbitMQ は SSL を使用して、プロデューサー、ブローカー、およびコンシューマー間の転送中のデータを暗号化します。メッセージを暗号化することで、組織は機密情報を保護し、データリスクを軽減できます。
一方、Redis OSS は SSL をネイティブにサポートしていません。SSL サポートは Redis OSS バージョン 6.0 以降でのみ提供されます。SSL を有効にするには、デベロッパーは Redis OSS クラスターから SSL 証明書を取得し、データベース用のクライアント証明書を作成する必要があります。
パフォーマンス: RabbitMQ とRedis OSS Pub/Sub
メッセージ処理の違いは、さまざまなシナリオで RabbitMQ と Redis OSS のパフォーマンスに影響を及ぼします。
スピード
Redis OSS は、主にメモリ上でメッセージを処理するため、RabbitMQ よりもはるかに高速です。ただし、Redis OSS サーバーに障害が発生すると、未読メッセージが失われるリスクがあります。
一方、永続的モードで動作している場合、RabbitMQ は各コンシューマーからの確認応答を待ってから、次のメッセージを送信します。また、RabbitMQ はメッセージをディスクに保存するのに時間がかかるため、平均的なメッセージ交換速度は遅くなります。
比較すると、Redis OSS は 1 秒あたり最大 1,000 万件のメッセージを送信できるのに対して、RabbitMQ は 1 秒あたり最大数万件のメッセージを処理します。
可用性
メッセージブローカーシステムがノードをレプリケートできるようにするクラスタリングは、RabbitMQ と Redis OSS では異なって処理されます。
RabbitMQ では、関連するデータや関数を含む複数のノードが 1 つのクラスター内で複製されます。ただし、メッセージキューは、ピア関係を共有するこれらのノード間では複製されません。そのために、デベロッパーはレプリケーションをサポートする特別なメッセージキューを使用します。
一方、Redis OSS クラスターは Redis OSS の後のバージョンで導入された機能です。各リーダーノードのデータを 1 人または複数のフォロワーにコピーします。リーダーノードに障害が発生すると、フォロワーが引き継いで可用性の高いメッセージ配信を行います。
使用する場面: RabbitMQ とRedis Pub/Sub
RabbitMQ は多くの点で Redis よりも優れていますが、だからといってすべてのアプリケーションを使用するうえで、RabbitMQ のほうがより優れたメッセージ配信システムであるとは限りません。
Redis は、リアルタイムのデータ処理と低レイテンシーのキャッシュを必要とするエンタープライズアプリケーションに適しています。インメモリデータストアと多様なデータ構造のサポートにより、Redis は低レベルのデータ計算を実行するのに適しています。たとえば、金融機関は Redis を使用してトランザクションデータをキャッシュし、リアルタイムで不正検出ができます。
一方、コードとシステム構築をサポートする非同期通信メカニズムを備えた専用のマイクロサービスメッセージブローカーが必要な場合は、RabbitMQ を選択ください。また、RabbitMQ は Redis と比べて、アプリケーション間で大きなファイルを転送するのにより適しています。たとえば、多くのマイクロサービス間でデータを確実に送信する必要があるシステムでは、RabbitMQ を選択するかもしれません。システムは、RabbitMQ の耐障害性、より大きなファイル処理能力、および保証されたメッセージ配信メカニズムの利点を活用できます。
相違点のまとめ: RabbitMQ とRedis Pub/Sub
| RabbitMQ |
Redis OSS |
|
| メッセージの配信 |
メッセージの配信が保証されます。複雑なロジックをサポートします。 |
メッセージの配信は保証されません。サブスクライバーからのアクティブな接続が必要です。 |
| メッセージサイズ |
メッセージサイズは 128 MB に制限されています。サイズの大きいメッセージを処理できます。 |
メッセージ数の制限はありませんが、サイズの大きいメッセージ (1 MB 以上) ではパフォーマンスが低下します。 |
| メッセージの永続性 |
永続的メッセージと一時的メッセージをサポートします。永続的メッセージをディスクに書き込みます。 |
デフォルトでは永続的メッセージをサポートしていません。 |
| メッセージの暗号化 |
SSL 暗号化をサポートします。 |
SSL 暗号化は Redis OSS バージョン 6.0 以降で使用できます。 |
| スピード |
毎秒最大数万件のメッセージ。 |
毎秒最大数百万件のメッセージ。 |
| 可用性 |
クラスターに複数のピアツーピアノードを作成します。 |
クラスタリングではリーダーフォロワーモデルを使用します。 |
RabbitMQ と Redis OSS の要件を満たすのを、AWS はどのようにサポートできますか?
Amazon Web Services (AWS) は、オープンソースのメッセージブローカーシステムを大規模に実行するためのマネージドサービスを提供します。パブリッシュ/サブスクライブ (pub/sub) サービスを簡単に設定して、他の AWS サービスと統合できます。
Redis OSS と RabbitMQ で利用できる AWS のオファリングは次のとおりです:
- Amazon MemoryDB を利用すると、Redis OSS でメッセージを配信する際の耐久性を高めることができます。同時実行性の高いストリーミングデータフィードを実行でき、ユーザーアクティビティを取り込み、メディアおよびエンターテインメントアプリケーション向けに 1 日あたり数百万のリクエストをサポートします。
- Amazon MQ を使用すると、時間のかかるセットアップなしで RabbitMQ ブローカーをプロビジョニングできます。RabbitMQ メッセージが転送中および静止時に暗号化されるため、AWS アベイラビリティーゾーン全体で可用性の高いデータパイプラインを確保できます。
Redis OSS や RabbitMQ の代わりに、Amazon Simple Notification Service (SNS) を利用して Pub/Sub メッセージングシステムを構築することもできます。スケーラブルかつ費用対効果の高い方法で、アプリケーションからお客様、または他のアプリケーションにメッセージを直接送信できます。
Amazon SNS にはいくつかの機能があります。
- 分散システム、マイクロサービス、イベント駆動型サーバーレスアプリケーション間の高スループット、プッシュベース、多対多のメッセージング
- メッセージの暗号化とトラフィックのプライバシー
- 分析、コンピューティング、コンテナ、データベース、モノのインターネット (IoT)、機械学習、セキュリティ、ストレージなどの複数の AWS カテゴリにわたるファンアウト機能
今すぐアカウントを作成して、AWS で Pub/Sub、Redis OSS、および RabbitMQ の利用を開始しましょう。
