マイクロサービス メッセージ ブローカーの選択: Redis、Kafka、RabbitMQ

[[420340]]

マイクロサービスで非同期通信を使用する場合、メッセージ ブローカーがよく使用されます。プロキシは、異なるマイクロサービス間の通信が信頼性が高く安定していること、メッセージがシステム内で管理および監視されていること、メッセージが失われないことを保証します。サイズとデータ機能が異なる複数のメッセージ ブローカーから選択できます。このブログ記事では、最も人気のあるブローカー 3 つ、RabbitMQ、Kafka、Redis を比較します。

しかし、まずはマイクロサービス通信について理解しましょう。

マイクロサービス通信: 同期と非同期

マイクロサービス間の通信には、同期と非同期という 2 つの一般的な方法があります。同期通信では、呼び出し側は次のメッセージを送信する前に応答を待機し、HTTP 上で REST プロトコルとして実行されます。対照的に、非同期通信では、応答を待たずにメッセージが送信されます。これは、通常、メッセージを管理するためにメッセージ ブローカーを必要とする分散システムに適しています。

選択する通信の種類では、マイクロサービスの構造、設定されているインフラストラクチャ、レイテンシ、スケール、依存関係、通信の目的など、さまざまなパラメータを考慮する必要があります。非同期通信はセットアップが複雑になり、スタックにさらに多くのコンポーネントを追加する必要がありますが、マイクロサービスに非同期通信を使用する利点は欠点を上回ります。

非同期通信の利点

まず第一に、非同期通信は定義上、非ブロッキングです。また、同期操作よりも優れたスケーリングもサポートします。 3 番目に、マイクロサービスがクラッシュした場合、非同期通信メカニズムによってさまざまな回復手法が提供され、クラッシュ関連のエラーが適切に処理されます。さらに、REST プロトコルの代わりにプロキシを使用する場合、通信を受信するサービスは実際には互いを認識する必要はありません。古いサービスが長期間実行された後でも新しいサービスを導入できるため、サービスの分離が向上します。

最後に、非同期操作を選択すると、将来的に集中検出、監視、負荷分散、さらにはポリシーエンフォーサーを作成する能力が向上します。これにより、コードとシステム ビルドに柔軟性、スケーラビリティ、およびより多くの機能が提供されます。

適切なメッセージブローカーの選択

非同期通信は通常、メッセージ ブローカーを通じて管理されます。 aysncio などの他の方法もありますが、それらはより少なく制限されています。

非同期操作を実行するためのプロキシを選択するときは、次の点を考慮する必要があります。

1. ブローカー スケール – システム内で 1 秒あたりに送信されるメッセージの数。

2. データの永続性 - メッセージを回復する機能。

3. 消費者の機能 - ブローカーが 1 対 1 または 1 対多の消費者を管理できるかどうか。

一対一:

1対多:

私たちは最新かつ最高のサービスを調べ、これら 3 つのカテゴリで最も強力なプロバイダーを特定しました。

さまざまなメッセージブローカーの比較

ラビットMQ

スケール: ここでのおおよそのレートは、構成とリソースに応じて、1 秒あたり約 50K メッセージです。

永続性: 永続メッセージと一時メッセージの両方をサポートします。

1 対 1 の消費者と 1 対多数の消費者: 両方。

RabbitMQ は 2007 年にリリースされ、最初に作成された汎用メッセージ ブローカーの 1 つでした。これは、Advanced Message Queuing Protocol (AMQP) を実装して、ポイントツーポイント方式およびパブリッシャー方式でメッセージを配信するオープン ソース ソフトウェアです。複雑なルーティング ロジックをサポートするように設計されています。

SaaS として使用できるマネージド サービスもいくつかありますが、ネイティブでは主要なクラウド プロバイダー スタックの一部ではありません。 RabbitMQ は、Python、Java、.NET、PHP、Ruby、JavaScript、Go、Swift など、すべての主要言語をサポートしています。

永続モードではパフォーマンスの問題が発生する可能性があります。

カフカ

スケール: 1 秒あたり最大数百万件のメッセージを送信します。

永続的: はい。

1 対 1 の消費者と 1 対多数の消費者: 1 対多数のみ (一見奇妙に思えますよね?!)。

Kafka は、高スループット、低レイテンシの処理を実行するために 2011 年に Linkedin によって作成されました。分散ストリーミング プラットフォームとして、Kafka はパブリッシュ/サブスクライブ サービスを複製します。データの永続性を提供し、レコードのストリームを保存して、高品質のメッセージを交換できるようにします。

Azure、AWS、Confluent 上の Kafka マネージド SaaS。彼らは Kafka プロジェクトの作成者であり、主要な貢献者です。 Kafka は、Python、Java、C/C++、Clojure、.NET、PHP、Ruby、JavaScript、Go、Swift など、すべての主要言語をサポートしています。

レディス

規模: 1 秒あたり最大 100 万件のメッセージを送信します。

永続性: 基本的にはいいえ。メモリ内のデータ ストアです。

1 対 1 の消費者と 1 対多数の消費者: 両方。

Redis は他のメッセージブローカーとは少し異なります。本質的に、Redis は、高性能なキー値ストアまたはメッセージ ブローカーとして使用できるインメモリ データ ストアです。もう 1 つの違いは、Redis には永続性がなく、メモリをディスク/DB にダンプすることです。リアルタイムのデータ処理にも適しています。

もともと、Redis は 1 対 1 でも 1 対多でもありませんでした。しかし、Redis 5.0 で pub-sub が導入されて以来、機能が改善され、1 対多が現実的な選択肢になりました。

各ユースケースのメッセージブローカー

RabbitMQ、Kafka、Redis のいくつかの機能を紹介しました。これら 3 つの動物はすべてこのカテゴリに分類されますが、前述のように、動作は大きく異なります。以下は、さまざまなユースケースに基づいた適切な MessageBroker に関する推奨事項です。

ショートメッセージ: Redis

Redis のインメモリ データベースは、永続性を必要としないショート メッセージングのユース ケースにほぼ最適です。 Redis は、非常に高速なサービスとインメモリ機能を備えているため、耐久性が重要ではなく、ある程度の損失を許容できる、短期間保持されるメッセージに最適です。 5.0 での Redis ストリームのリリースにより、制限と古いパブリッシュ/サブスクライブ機能のために絶対に必要だった 1 対多のユース ケースの候補にもなります。

大量のデータ: Kafka

Kafka は、大量のデータを長期間保存するために設計された高スループットの分散キューです。 Kafka は、永続性を必要とする 1 対多のユースケースに適しています。

複雑なルーティング: RabbitMQ

RabbitMQ は、複雑なルーティングをサポートする多くの機能と機能を備えた、古いながらも成熟したブローカーです。必要なレートが高くない (数万メッセージ/秒以上) 場合でも、複雑なルーティング通信をサポートします。

ソフトウェアスタックを検討する

もちろん、最終的な考慮事項は現在のソフトウェア スタックです。比較的単純な統合プロセスを探していて、スタック内でさまざまなプロキシを維持したくない場合は、スタックですでにサポートされているプロキシを使用することをお勧めします。

たとえば、RabbitMQ 上のシステムで Celery をタスク キューとして使用している場合、サポートされておらず書き換えが必要となる Kafka の代わりに RabbitMQ または Redis を使用するように促されます。