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