Redisをメッセージブローカーとして使用すべきなのはいつか？

Redisをメッセージブローカーとしていつ使用すべきか？

Redisは、超高速なインメモリデータストアとして広く知られており、主にキャッシングとセッション管理に使用されます。しかし、その汎用性の高いデータ構造は、単純なキーバリューストアを超えた広範な用途を可能にします。Redisは、Redis Pub/SubとRedis Streamsという強力なプリミティブを提供し、これらにより軽量なメッセージブローカーとして効果的に機能することができます。

Redisがメッセージングのニーズに適しているかどうかを判断するには、トレードオフを理解する必要があります。RabbitMQやApache Kafkaのような専用のメッセージブローカーは、堅牢な保証、複雑なルーティング、および優れた耐久性を提供しますが、Redisは比類のないシンプルさ、速度、低遅延を提供します。これは、既存のインフラストラクチャに依存することが有益な特定の高パフォーマンスユースケースに理想的です。この記事では、Redisメッセージングの仕組みを探り、Redisが優れているシナリオと、そうでないシナリオを定義するのに役立ちます。

Redisメッセージングプリミティブの理解

Redisは、非同期メッセージングのために2つの異なる機能を提供しており、それぞれ信頼性と複雑さの異なるレベルに適しています。

1. Redis Pub/Sub（Publish/Subscribe）

Redis Pub/Subは、Redisが提供する最もシンプルなメッセージング形式です。これはファイア・アンド・フォーゲットモデルで動作し、パブリッシャーがチャネルにメッセージを送信し、それらのチャネルを購読しているサブスクライバーがそれらを受信します。

メカニズムと特徴：

一時的（Ephemeral）： メッセージは永続化されません。サブスクライバーが切断されているか遅延している場合、その間に公開されたメッセージは失われます。
ゼロ確認（Zero Acknowledgment）： メッセージ確認または配信保証のための組み込みメカニズムはありません。
低遅延（Low Latency）： シンプルなインメモリ性質により、非常に高速です。
ファンアウト（Fan-out）： 多数のリスナーにリアルタイム更新を同時にブロードキャストするのに優れています。

Pub/Subの例

このシンプルなコマンドは、その相互作用を示しています。

# ターミナル1：サブスクライバーがリスニングを開始
REDIS> SUBSCRIBE updates:pricing

# ターミナル2：パブリッシャーがメッセージを送信
REDIS> PUBLISH updates:pricing "Stock price updated to $150.00"

# ターミナル1が受信：
1) "message"
2) "updates:pricing"
3) "Stock price updated to $150.00"

2. Redis Streams（XSTREAM）

Redis 5.0で導入されたRedis Streamsは、高度で耐久性があり、永続的なログのようなデータ構造を提供し、Redisが信頼性の高いメッセージングにおいて従来のブローカーとより直接的に競合できるようにします。

メカニズムと特徴：

永続性（Persistence）： メッセージ（ストリームエントリ）はRedisに永続的に保存され、コンシューマーは過去のデータを読み取ったり、切断後に失われたメッセージを回復したりできます。
コンシューマーグループ（Consumer Groups）： ストリームはコンシューマーグループをサポートしており、複数のコンシューマーがストリームからメッセージを並行して処理し、負荷を共有し、グループ内の各メッセージが1つのコンシューマーによってのみ処理されることを保証します（コンペッティングコンシューマーパターン）。
少なくとも1回配信（At-Least-Once Delivery）： ストリームは明示的なメッセージ確認（XACK）を使用し、メッセージが少なくとも1回処理されることを保証します。処理に失敗した場合、メッセージは再処理のために保留状態のままになります。
順序（Ordering）： メッセージは、そのストリームID（タイムスタンプ＋シーケンス番号）によって厳密に順序付けされます。

ストリームの例（プロデューサーとコンシューマーグループ）

1. エントリの追加（プロデューサー）： *はRedisがユニークなIDを生成することを示します。

XADD events:orders * item_id 42 user_id 99 amount 59.99

2. コンシューマーグループの作成：

XGROUP CREATE events:orders order_processors 0-0 MKSTREAM

3. グループからの読み取り（コンシューマー）： >は、未読の新しいメッセージのみを読み取ります。

XREADGROUP GROUP order_processors consumer_A COUNT 1 STREAMS events:orders >

ブローカーとしてRedisを使用する利点

Redisを選択することは、多くの場合、パフォーマンスとインフラストラクチャの統合にかかっています。

極めて低い遅延（Extreme Low Latency）： 即時データ配信を必要とするアプリケーション（例：ライブスコアボード、リアルタイムアラート）にとって、Redisのインメモリ性質は最小限のオーバーヘッドと、非専門ソリューションで利用可能な最速のメッセージ配信を提供します。
インフラストラクチャの統合（Infrastructure Consolidation）： キャッシングやセッション管理で既にRedisを使用している場合、それを軽量メッセージングに活用することで、個別の専用ブローカクラスタ（KafkaやRabbitMQなど）のセットアップ、スケーリング、および保守の複雑さと運用コストを回避できます。
ストリームのシンプルさ（Simplicity for Streams）： StreamsはPub/Subと比較して複雑さを導入しますが、Kafkaのような大規模な分散ログアーキテクチャよりも設定と管理が簡単であり、中小規模のメッセージングワークロードに最適です。
トランザクションとアトミック操作（Transactionality and Atomic Operations）： Redisは、RedisトランザクションまたはLuaスクリプトを使用して、メッセージの公開/ストリーミング操作と他のアトミックデータ変更（例：カウンターの更新と通知の送信）を組み合わせることができます。

Redisメッセージングを使用すべき場合：定義されたユースケース

Pub/SubとStreamsの選択、およびRedisと専用ブローカーの選択は、必要な信頼性と規模に完全に依存します。

Redis Pub/Subのユースケース（一時的なメッセージング）

メッセージの損失が許容され、速度が最優先される場合はPub/Subを使用してください。

キャッシュ無効化（Cache Invalidation）： 特定のキャッシュキーが更新され、無効化する必要があることを複数のアプリケーションインスタンスにブロードキャストする通知。
リアルタイム通知（Real-time Notifications）： 単純なステータス更新、履歴取得が他で処理されるチャットルームメッセージ、またはコンシューマーが最新の値のみに関心があるライブデータフィード。
ステートレスファンアウト（Stateless Fan-out）： 受信確認を必要とせずに、設定変更またはシステムヘルスチェックをマイクロサービスに配布すること。

Redis Streamsのユースケース（永続的なメッセージング）

信頼性、永続性、および同時処理が必要であるが、大量のメッセージスループットや複雑なルーティングを必要としない場合はStreamsを使用してください。

シンプルなタスクキュー（Simple Task Queues）： タスクの配信が保証されなければならないバックグラウンドワーカーキューの実装（例：画像処理、メール送信）。Streamsはタスク履歴とコンシューマーの状態を効果的に管理します。
イベントソーシング（軽量）（Event Sourcing (Lightweight)）： 再実行可能性、監査、または単純な状態再構築のために、永続的で順序付けられた操作イベントログを保存します。小規模なイベント量に適しています。
サービス間通信（マイクロサービス）（Inter-Service Communication (Microservices)）： 信頼性の高いデータ交換のために、メッセージの集中管理された永続ログが必要な、疎結合なサービスを接続するためにStreamsを使用します。
レート制限（Rate Limiting）： クイック分析とレート制限の施行のために、ユーザーアクションまたはAPI呼び出しに関連する時系列データを保存します。

制限事項と専用ブローカーを選択すべき場合

Redis Streamsの強力さにもかかわらず、すべての場合においてエンタープライズグレードのメッセージブローカーを置き換えるものではありません。アプリケーションがこれらのカテゴリに該当する場合、専用ソリューションが必要になることがよくあります。

1. 高ボリュームとデータ耐久性の要件

Redisは主にインメモリストアです。永続性（RDBスナップショットまたはAOFログ）をサポートしていますが、これらのメカニズムは再起動リカバリに最適化されており、Kafkaのようなソリューションの連続的なペタバイトスケールの耐久性および高度に調整されたディスクI/Oに必ずしも最適化されているわけではありません。

Kafka/Pulsarを選択する場合：
* 秒間数十万メッセージの保証された配信が必要な場合。
* メッセージデータ量がシステムメモリを超え、効率的なディスクベースストレージと階層型アーカイブが必要な場合。
* メッセージ履歴の非常に長い保持期間（数ヶ月または数年）が必要な場合。

2. 高度なブローカー機能

専用ブローカーは、Redisが標準で備えていない高度な機能を提供します。

機能	Redis Streams	専用ブローカー（例：RabbitMQ、Kafka）
デッドレターキュー（DLQ）	アプリケーションロジックを通じて手動で実装する必要がある。	失敗したメッセージの自動ルーティングのネイティブサポート。
複雑なルーティング/フィルタリング	基本的なフィルタリングはクライアント側で行う必要がある。	高度なルーティングのための交換タイプ（RabbitMQ）または複雑なトピックパーティショニング（Kafka）。
トランザクション	Redisインスタンス内でのみ限定的。	メッセージ送信とデータベース更新をまたぐ分散トランザクションのサポート。
セキュリティと監視	基本的なACLと一般的なメトリクス。	きめ細かな権限、専門的な監視ツール、およびエンタープライズグレードの監査。

3. キュー管理

Redisリスト（LPUSH/RPOP）は基本的なキューとして機能できますが、これらはFIFOのみであり、BRPOPやカスタムロジックと組み合わせない限り、永続性の保証がありません。Streamsは優れていますが、専用ブローカーはより高度なキュー管理戦略（例：優先度付きキュー、メッセージTTL）を提供します。

まとめとベストプラクティス

Redisは、運用上のシンプルさと驚異的なパフォーマンスが、複雑な機能やペタバイトスケールの永続性の必要性を上回る場合に、メッセージブローカーとして優れた選択肢となります。

シナリオ	メッセージングプリミティブ	ベストプラクティス
リアルタイムブロードキャスト/キャッシュ同期	Redis Pub/Sub	サブスクライバーがメッセージの損失を適切に処理できるようにする。
軽量タスクキュー	Redis Streams	コンシューマーグループと厳格な`XACK`を使用して、少なくとも1回の処理を保証する。
高ボリュームデータパイプライン	専用ブローカー（Kafka/Pulsar）	複数TBのデータにわたってメッセージを確実に永続化する必要がある場合はRedisを使用しない。
既存のRedisインフラストラクチャ	Redis Streams	既存のRedisクラスタを使用してセットアップオーバーヘッドを節約する。

警告： Redis Streamsを使用する際は、ストリームエントリがメモリを消費することを忘れないでください。特に高スループットのストリームでは、過剰なメモリ使用を防ぐために、長さまたはIDに基づいて古いエントリをXTRIMを使用してトリミングするポリシーを実装してください。