Kafka と Redis はどのように異なりますか?

Apache Kafka は、複数のアプリケーションが互いに独立してデータをストリーミングできるようにするイベントストリーミングプラットフォームです。プロデューサーとコンシューマーと呼ばれるこれらのアプリケーションは、トピックと呼ばれる特定のデータパーティションに対して情報を公開したり、トピックから情報をサブスクライブしたりします。

一方、Redis は、アプリケーション間の低レイテンシーのデータ転送をサポートするインメモリデータベースとして設計されています。すべてのメッセージをハードディスクではなく RAM に保存して、データの読み書き時間を短縮します。Kafka と同様に、複数のコンシューマーが Redis ストリームをサブスクライブしてメッセージを取得できます。

どちらも Pub/Sub メッセージングに使用できますが、Kafka と Redis の動作は異なります。

Kafka のワークフロー

Apache Kafka は、コンピュートクラスターを通じてプロデューサーとコンシューマーを接続します。各クラスターは、異なるサーバーにある複数の Kafka ブローカーで構成されています。

Kafka は以下の目的でトピックとパーティションを作成します。

• E メール、支払い、ユーザー、購入など、関心のあるテーマに属する類似データをグループ化するためのトピック
• データの複製と耐障害性を実現するために、さまざまなブローカーにまたがるパーティション

プロデューサーはメッセージをブローカーに公開します。ブローカーはメッセージを受信すると、データをトピックに分類し、データをパーティションに保存します。コンシューマーは関連するトピックに接続し、そのパーティションからデータを抽出します。

Redis のワークフロー

Redis は、NoSQL データベースシステムとしてクライアント/サーバーアーキテクチャで動作します。プロデューサーとコンシューマーは疎結合であり、メッセージを送信するときに互いを認識する必要はありません。

Redis は以下の目的でキーとプライマリ/セカンダリノードを使用します。

• 類似のメッセージをグループ化するためのキー。たとえば、「E メール」は E メールメッセージのみを保持するデータストアを指すキーです。 
• メッセージ複製用のプライマリ/セカンダリノード。

プロデューサーが特定のノードにメッセージを送信すると、Redis はメッセージキーを確認して、接続しているすべてのサブスクライバーにメッセージを配信します。コンシューマーがメッセージを受信するには、常に Redis サーバーとのアクティブな接続を開始して維持する必要があります。これは接続配信セマンティックとして知られています。

Pub/Sub メッセージングについて読む »

全体として、Pub/Sub メッセージングでは Apache Kafka は Redis よりも優れています。これは、Kafka がデータストリーミング専用に設計されているためです。Redis には、Kafka を使用できないさまざまなユースケースがあります。 

並列処理

並列処理とは、複数のコンシューマーが同じメッセージを同時に受信できることです。

Redis は並列処理をサポートしていません。

一方、Kafka では、同じメッセージを複数のコンシューマーに同時に配信できます。 Kafka は通常、コンシューマーグループのコンシューマーは順番にパーティションから新しいメッセージを取得します。複数のコンシューマーグループにコンシューマーが 1 人しかいない場合は、すべてのメッセージが取得されます。この設定とパーティションレプリケーションを利用することで、各パーティションレプリカの各コンシューマーグループに 1 人のコンシューマーを割り当てることができます。これにより、すべてのコンシューマーが同様のメッセージシーケンスを取得できます。 

スループット

スループットは、各システムが 1 秒あたりに処理できるメッセージ数を測定します。

Kafka は通常、Redis の Pub/Sub よりもスループットが高くなります。Kafka は、各サブスクライバーのメッセージの受信を確認してから別のサブスクライバーに移動する必要がないため、はるかに大量のデータを処理できます。その代わりに、現在のメッセージをメモリキャッシュとストレージに保存し、読み取り速度を最適化します。 

ただし、コンシューマーがメッセージを十分な速度で取得しない場合、キャッシュ上の未読メッセージが最終的に削除されるため、Kafka のパフォーマンスが低下する可能性があります。この場合、コンシューマーはディスクから読み取る必要がありますが、速度は遅くなります。

一方、Redis は各コンシューマーの確認を待つ必要があるため、接続されたノードが増えるとスループットが大幅に低下します。回避策は、パイプラインと呼ばれるプロセスで複数のリクエストを送信することですが、これによりメッセージのレイテンシーが短縮されます。 

レイテンシー

Kafka と Redis はどちらも低レイテンシーのデータ処理に適しています。Kafka が平均数十ミリ秒であるのに対し、Redis のメッセージング時間はミリ秒単位と短いです。

Redis は主に RAM 上でデータの読み取りと書き込みを行っているため、速度は当然ながら Kafka よりも遅くなります。ただし、Redis が大量のメッセージを処理する場合、超低レイテンシーのデータ操作を維持できない場合があります。一方、Kafka はデータを永続化するために異なる物理ドライブ上のパーティションを複製するのにより多くの時間を必要とするため、メッセージ配信時間のオーバーヘッドが増加します。

Redis と Kafka のレイテンシーを最適化することは可能ですが、慎重に行う必要があります。たとえば、Kafka メッセージを圧縮してレイテンシーを減らすことはできますが、プロデューサーとコンシューマーがそれらを解凍するためにより多くの時間が必要になります。

Redis のレイテンシーは、動作環境、ネットワーク操作、低速なコマンド、フォークなど、いくつかの要因によって引き起こされる可能性があります。フォークの遅延を減らすため、Redis ではハードウェア仮想マシン (HVM) ベースの最新の EC2 インスタンスで Pub/Sub 配信システムを実行することを推奨しています。

耐障害性

Kafka はすべてのデータを主要なブローカーのストレージディスクに書き込み、それをさまざまなサーバーに複製します。サーバに障害が発生すると、複数のサブスクライバーがバックアップパーティションからデータを取得します。 

Kafka とは異なり、Redis はデフォルトではデータをバックアップしないため、ユーザーはこの機能を手動で有効にする必要があります。Redis はインメモリデータストアを使用するため、電源を切るとすべてのデータが失われます。これを回避するために、デベロッパーは Redis Database (RDB) の永続性を有効にして、RAM データのスナップショットを定期的にキャプチャしてディスクに保存します。 

	Apache Kafka	Redis
メッセージサイズ	圧縮と階層型ストレージで最大 1 GB のメッセージサイズをサポートします。	より小さいメッセージサイズをサポートします。
メッセージの配信	サブスクライバーはキューからメッセージを取得します。	Redis サーバーは、接続されているサブスクライバーにメッセージをプッシュします。
メッセージ保持	取得後もメッセージを保持します。	メッセージは保持されません。
エラー処理	メッセージングレベルでの堅牢なエラー処理。デッドレターキュー、イベント再試行、リダイレクト。	Redis 例外は、タイムアウト、クライアント制限、およびメモリバッファ容量を含むアプリケーションレベルで処理する必要があります。
並列処理	Kafka は並列処理をサポートしています。複数のコンシューマーが同じメッセージを同時に取得できます。	並列処理はサポートしていません。
スループット	非同期の読み取り/書き込みのため、高いスループットです。	Redis サーバーが別のサブスクライバーにメッセージを送信する前に返信を待つ必要があるため、低いスループットです。
レイテンシー	低レイテンシー。デフォルトではデータレプリケーションのため、Redis よりもわずかに遅いです。	小さいサイズのメッセージを配信する際は超低レイテンシーです。
耐障害性	パーティションを異なるブローカーに自動的にバックアップします。	デフォルトではバックアップされません。ユーザーは Redis の永続性を手動で有効にできます。小さなデータ損失のリスクがあります。