データ処理とメッセージングシステムの世界では、「キュー」や「ストリーミング」といった用語がよく登場します。これらは似たように聞こえるかもしれませんが、それぞれ異なる目的を持っており、システムがデータを扱う方法に大きな影響を与える可能性があります。それらの違いを分かりやすく説明しましょう。
メッセージキューとは何ですか？
オンラインや対面で注文を受けるコーヒーショップを想像してみてください。注文が処理されると、顧客は受け取りを通知されます。このアナロジーでは、注文はキューのメッセージのように機能し、バリスタはそれらを1つずつ処理し、完了した注文をキューから削除します。これがメッセージキューの基本的な動作方法です。
各メッセージは独立して処理される個別のタスクを表します。キュー内のメッセージは順番に消費され、一般的に破壊的消費が行われます。つまり、メッセージが処理されると、キューから削除されます。
- 非同期通信：生産者は、消費者が同時に準備ができていなくてもメッセージを送信できます。コーヒーを注文するように、それが作られている間にそばにいる必要はありません。
- 先入れ先出し（FIFO）：メッセージは受信された順に処理されます。これが厳密な順序に依存する操作、たとえば銀行取引などにとって重要です。設定によっては非FIFO処理を許可するキューもあります。
- 耐久性：メッセージは消費者が処理するまで確実に保存されます。これにより、システム障害が発生してもメッセージが失われないことが保証されます。
- 独占配送：各メッセージは1つの消費者インスタンスによってのみ消費され、重複処理が行われることはありません。メッセージは消費者によって確認され次第削除されます。
キューの主な使用例：
- 在庫管理：在庫レベルをリアルタイムで追跡および更新する。
- 医療システム：患者の流れと予約スケジュールを管理する。
- レストラン業務：顧客の注文と予約を処理する。
ストリーミングメッセージとは何ですか？
今度は、音楽がリアルタイムで流れ、観客がそれを体験するライブコンサートを想像してください。ストリーミングメッセージはデータの連続的なフローとリアルタイム処理に焦点を当てています。
- リアルタイム処理：ストリーミングメッセージは、ちょうどストリーミングサービスで音楽を聴くように、生成され次第即座に消費されます。
- イベント駆動型アーキテクチャ：データは利用可能になったらすぐに消費者にプッシュされ、即時の反応を可能にします。たとえば、ソーシャルメディアのフィードは新しい投稿、いいね、コメントで動的に更新されます。
- スケーラビリティ：ストリーミングシステムは、大量のデータを処理することができ、リアルタイムの分析、モニタリング、機械学習に適しています。
- メッセージ保持：メッセージは指定された期間保存され、一括処理またはエラー回復のために再生されることができます。保持は時間（例：7日）またはサイズ（例：パーティションあたり1GB）に基づきます。
ストリーミングの主な使用例：
- 株価監視：トレーダーにリアルタイムの更新を提供する。
- 不正検出：疑わしい活動を即座に識別する。
- 顧客サービス分析：リアルタイムでのインタラクションと感情の追跡。
Apache Kafkaでキューを使用する理由は？
Confluentでは、Apache Kafkaを多様なデータワークロードに対応するためのユニバーサルソリューションにすることを目的としています。従来のメッセージングシステムは、順序と速度の間でユーザーに選択を迫ることが多いですが、Kafkaはキューサポートを導入することでこのギャップを埋め、メッセージを逐次的または並行的に処理する柔軟性を提供します。
この追加により、Kafkaの柔軟性が向上し、ストリーミングとキューベースのワークフローの両方をサポートでき、より広範なユースケースに対応可能になります。
Apache Kafkaでキューがどのようにサポートされているか？
Kafkaは各メッセージに一意のオフセットを割り当てるログベースのアーキテクチャを採用しています。消費者はメッセージを順番に読み取り、フォールトトレランスを確保し、メッセージの再生を可能にします。新しいハイブリッドモデルでは、Kafkaは従来のキューのメリットとログベースの設計を組み合わせています。
- 並列処理：メッセージは複数の消費者によって同時に消費される可能性があります。
- 再生機能：メッセージは復旧や再処理のために再生されることができます。
- 高スループット：Kafkaはスケーラビリティと信頼性を維持しつつ、必要に応じて順不同処理を可能にします。
Kafkaにおけるコンシューマグループとシェアグループ
Kafkaでは、コンシューマグループがトピックからのデータ消費の管理を行います。各コンシューマグループは、トピックのパーティションからデータを読み取るために協働する複数の消費者で構成されます。グループ内ではパーティションと消費者の間に1:1の関係があります。ただし、消費者の数がパーティションの数を超えるとスケーリングが非効率になることがあります。
シェアグループは、特に従来のキューシステムに似たワークロードには、より柔軟なアプローチを提供します。シェアグループでは、同じパーティションから複数の消費者がデータを読み取ることができ、データ共有と処理の詳細な制御が可能になります。
- 同時読み取り：シェアグループの複数の消費者が同じパーティションから読み取ることができます。
- 動的スケーリング：トピックをリパーティションせずに、ピーク負荷を処理するためにより多くの消費者を追加できます。
- 個別の確認：メッセージは一つ一つ確認され、バッチ処理を最適化しつつ、未処理のメッセージの再配信が可能です。
- 独立した消費：異なるシェアグループの消費者が同じトピックにアクセスしても干渉しません。
シェアグループは順序を保証しますか？
実際の例：小売の販売イベント
- 並列処理：注文は複数の作業者に分配され、同時に処理されます。
- 動的なリソース配分：システムは、ピーク時に消費者を追加し、需要が低下したときにスケールダウンすることができます。
- 効率的な処理：厳密な順序を要求せず、注文が迅速に処理されます。
