Java エンジニアのための上級者向けコース: Kafka

1. カフカの背景

Kafka はもともと Linkedin によって開発されました。これは、Zookeeper 調整に基づいた分散型、パーティション化された、マルチレプリカの分散メッセージング システムです。最大の特徴は、Hadoop ベースのバッチ処理システム、低遅延リアルタイムシステム、Storm/Spark ストリーミング処理エンジン、Web/nginx ログ、アクセスログ、メッセージングサービスなど、さまざまな需要シナリオに合わせて大量のデータをリアルタイムで処理できることです。Scala で記述されています。 Linkedin は 2010 年にこれを Apache Foundation に寄贈し、トップ オープン ソース プロジェクトとなりました。

今日の社会では、ビジネス、ソーシャルネットワーキング、検索、ブラウジングなどのさまざまなアプリケーションシステムが、情報工場のようにさまざまな情報を絶えず生み出しています。ビッグデータの時代において、私たちは次のような課題に直面しています。

1. この膨大な情報をどのように収集するか。
2. それを分析する方法;
3. 上記 2 点をタイムリーに達成する方法。

上記の課題は、生産者がさまざまな情報を生産し、消費者がその情報を消費（処理・分析）するというビジネス需要モデルを形成します。プロデューサーとコンシューマーの間で通信を行うには、両者の橋渡しとなるメッセージング システムが必要です。ミクロの観点から見ると、この要件は、異なるシステム間でメッセージを送信する方法としても理解できます。

分散メッセージング システムである Kafka は次のように誕生しました。

1. Kafka - linked-in によってオープンソース化されています。
2. Kafka は上記の問題を解決するフレームワークです。生産者と消費者のシームレスなつながりを実現します。
3. Kafka - 高スループットの分散メッセージング システム。

2. メッセージング システムを使用する理由

• デカップリング:

これにより、同じインターフェース制約に準拠している限り、両側での処理を個別に拡張または変更できます。

• 冗長性:

メッセージ キューは、データが完全に処理されるまでデータを保持するため、データ損失のリスクを回避できます。多くのメッセージ キューで採用されている「挿入、取得、削除」パラダイムでは、キューからメッセージを削除する前に、処理システムはメッセージが処理されたことを明確に示し、使用が完了するまでデータが安全に保存されるようにする必要があります。

• スケーラビリティ:

メッセージ キューは処理を分離するため、追加の処理を追加するだけで、メッセージのエンキューと処理の頻度を簡単に増やすことができます。

• 柔軟性とピーク処理能力:

アプリケーションはトラフィックが急増しても機能し続ける必要がありますが、このようなトラフィックの急増はまれです。このようなピークトラフィックを処理するためだけに、常にスタンバイ状態にリソースを投資するのは大きな無駄です。メッセージ キューを使用すると、突然の過負荷要求によって主要コンポーネントが完全にクラッシュすることなく、突然のアクセス圧力に耐えることができます。

• 回復可能性:

システムの 1 つのコンポーネントに障害が発生しても、システム全体に影響が及ぶことはありません。メッセージ キューはプロセス間の結合を減らすため、メッセージを処理するプロセスがクラッシュした場合でも、キューに追加されたメッセージはシステムの回復後に引き続き処理できます。

• 注文保証:

ほとんどのユースケースでは、データが処理される順序が重要です。ほとんどのメッセージ キューは本質的に順序付けられており、データが特定の順序で処理されることを保証します。 (Kafka はパーティション内のメッセージの順序を保証します)

• バッファ:

これは、システムがデータを通過する速度を制御および最適化し、生成されたメッセージと消費されたメッセージの処理速度の不一致を解決するのに役立ちます。

• 非同期通信:

多くの場合、ユーザーはメッセージをすぐに処理することを望まなかったり、その必要がありません。メッセージ キューは、ユーザーがメッセージをキューに入れてもすぐには処理しない、非同期処理メカニズムを提供します。必要な数のメッセージをキューに入れて、必要なときに処理することができます。

3. Kafka の基本アーキテクチャ

3.1.トポロジー

3.2.名詞の概念

• プロデューサー: Kafka クラスター内のターミナルまたはサービスにメッセージを公開するメッセージ プロデューサー。
• ブローカー: Kafka クラスターに含まれるサーバー。
• トピック: Kafka クラスターに公開される各メッセージが属するカテゴリ。つまり、Kafka はトピック指向です。
• パーティション: パーティションは物理的な概念です。各トピックには 1 つ以上のパーティションが含まれます。 Kafka の割り当ての単位はパーティションです。
• コンシューマー: Kafka クラスターからのメッセージを消費するターミナルまたはサービス。
• コンシューマー グループ: 高レベルのコンシューマー API では、各コンシューマーはコンシューマー グループに属します。各メッセージは、コンシューマー グループ内の 1 つのコンシューマーによってのみ消費されますが、複数のコンシューマー グループによって消費されることもあります。
• レプリカ: パーティションのコピー。パーティションの高可用性を保証します。
• リーダー: レプリカ内の役割。プロデューサーとコンシューマーはリーダーとのみ対話します。
• フォロワー: リーダーからデータをコピーするレプリカ内の役割。
• コントローラー: Kafka クラスター内のサーバーのうちの 1 つ。リーダーの選出やさまざまなフェイルオーバーに使用されます。
• Zookeeper: Kafka はクラスターのメタ情報を保存するために Zookeeper を使用します。

4. Kafka の基本機能

1. 高いスループットと低いレイテンシ: Kafka は、最小レイテンシがわずか数ミリ秒で、1 秒あたり数十万件のメッセージを処理できます。
2. スケーラビリティ: Kafka クラスターはホット拡張をサポートします。
3. 永続性と信頼性: メッセージはローカル ディスクに永続化され、データ損失を防ぐためにデータのバックアップをサポートします。
4. フォールト トレランス: クラスター内のノードに障害が発生してもかまいません (レプリカの数が n の場合、n-1 個のノードに障害が発生してもかまいません)。
5. 高い同時実行性: 数千のクライアントによる同時読み取りと書き込みをサポートします。

デザインコンセプト

• consumergroup:各コンシューマーはグループを形成できます。各メッセージは、グループ内の 1 つのコンシューマーのみが使用できます。メッセージが複数のコンシューマーによって消費される可能性がある場合、これらのコンシューマーは異なるグループに属している必要があります。
• メッセージ ステータス: Kafka では、メッセージのステータスはコンシューマーに保存されます。ブローカーは、どのメッセージが誰によって消費されるかを気にしません。オフセット値（パーティション内で消費される次のメッセージ位置を指す）のみを記録します。つまり、コンシューマーが適切に処理しないと、ブローカー上のメッセージが複数回消費される可能性があります。
• メッセージの永続性: Kafka はメッセージをローカル ファイル システムに永続化し、非常に高い効率を維持します。
• メッセージの有効期間: Kafka はメッセージを長期間保持し、消費者が複数回メッセージを消費できるようにします。もちろん、多くの詳細を設定できます。
• バッチ送信: Kafka は、プッシュ効率を向上させるためにメッセージ セットでのバッチ送信をサポートしています。
• プッシュ アンド プル: Kafka のプロデューサーとコンシューマーはプッシュ アンド プル モードを採用しています。つまり、プロデューサーはブローカーにメッセージをプッシュするだけで、コンシューマーはブローカーからメッセージをプルするだけです。両者によるメッセージの生成と消費は非同期です。 Kafka クラスター内のブローカー間の関係は、マスターとスレーブの関係ではありません。各ブローカーはクラスター内で同じステータスを持ちます。任意のブローカー ノードを任意に追加または削除できます。
• 負荷分散に関しては、 Kafka はブローカー間の負荷を管理するためのメタデータ API を提供します (Kafka 0.8.x の場合、0.7.x の場合、負荷分散は主に zookeeper によって実現されます)。
• 同期と非同期: プロデューサーは非同期プッシュ モードを使用します。これにより、Kafka システムのスループットが大幅に向上します (同期モードまたは非同期モードはパラメーターによって制御できます)。
• パーティション メカニズム パーティション: Kafka のブローカーはメッセージのパーティション分割をサポートします。プロデューサーは、どのパーティションにメッセージを送信するかを決定できます。パーティション内のメッセージの順序は、プロデューサーがメッセージを送信する順序です。トピックには複数のパーティションが存在する可能性があり、パーティションの具体的な数は構成可能です。パーティショニングの重要性は非常に重要であり、それは次のコンテンツに徐々に反映されるでしょう。
• オフライン データのロード: Kafka は、スケーラブルなデータ永続性をサポートしているため、Hadoop またはデータ ウェアハウスにデータをロードするのにも非常に適しています。
• プラグインのサポート:多くのアクティブなコミュニティが、Storm、Hadoop、Flume 用のプラグインなど、Kafka の機能を拡張するプラグインを開発しています。

アプリケーションシナリオ

• ログ収集:企業は Kafka を使用してさまざまなサービスのログを収集し、Hadoop、Hbase、Solr など、Kafka を介した統合インターフェース サービスの形式でさまざまな消費者に公開できます。
• メッセージング システム:プロデューサーとコンシューマーの分離、メッセージのキャッシュなど。
• ユーザー アクティビティの追跡: Kafka は、Web ページの閲覧、検索、クリックなど、Web ユーザーやアプリ ユーザーのさまざまなアクティビティを記録するためによく使用されます。これらのアクティビティ情報は各サーバーによって Kafka トピックに公開され、サブスクライバーはこれらのトピックをサブスクライブしてリアルタイムの監視と分析を行ったり、Hadoop やデータ ウェアハウスにロードしてオフライン分析やマイニングを行ったりします。
• 運用指標: Kafka は、運用監視データの記録にもよく使用されます。これには、さまざまな分散アプリケーションからデータを収集し、アラームやレポートなどのさまざまな操作に対する集中的なフィードバックを生成することが含まれます。
• ストリーム処理: Spark StreamingやStormなど

5. プッシュモードとプルモード

5.1.ピアツーピアモード

上の図に示すように、ポイントツーポイント モードは通常、プルまたはポーリング メッセージング モデルに基づいており、キューに送信されたメッセージが 1 つのコンシューマーのみによって処理されるという特徴があります。プロデューサーがメッセージをメッセージ キューに入れると、コンシューマーはメッセージを積極的にプルして消費します。ポイントツーポイント モデルの利点は、コンシューマーがメッセージをプルする頻度を自分で制御できることです。ただし、コンシューマー側では、メッセージ キューに消費する必要があるメッセージがあるかどうかを認識できないため、コンシューマー側でそれを監視するための追加のスレッドが必要になります。

5.2.パブリッシュ・サブスクライブモデル

上図に示すように、パブリッシュ・サブスクライブモデルは、メッセージ送信をベースとしたメッセージ伝送モデルです。このモデルには複数の異なるサブスクライバーを含めることができます。プロデューサーがメッセージをメッセージ キューに入れると、キューはこのタイプのメッセージをサブスクライブしているコンシューマーにメッセージをプッシュします (WeChat パブリック アカウントと同様)。コンシューマーは受動的にプッシュ通知を受信するため、メッセージ キュー内で消費を待機しているメッセージがあるかどうかを感知する必要はありません。ただし、consumer1、consumer2、consumer3 のマシンのパフォーマンスは異なるため、メッセージを処理する能力も異なりますが、メッセージ キューはコンシューマーの消費速度を認識できません。したがって、プッシュの速度はパブリッシュ/サブスクライブ モデルの問題になります。 3 つのコンシューマーの処理速度がそれぞれ 8M/s、5M/s、2M/s であると仮定します。キューのプッシュ速度が 5M/s の場合、consumer3 はそれに耐えられません。キューのプッシュ速度が 2M/s の場合、consumer1 と consumer2 は大量のリソースを浪費します。

5.3.カフカの選択

メッセージング システムとして、Kafka はプロデューサーがブローカーにメッセージをプッシュし、コンシューマーがブローカーからメッセージをプルするという従来のアプローチに従います。 Facebook の Scribe や Cloudera の Flume などの一部のログ中心のシステムは、プッシュ モデルを使用します。実際、プッシュ モードとプル モードにはそれぞれ長所と短所があります。

プッシュ モードでは、メッセージの送信レートがブローカーによって決定されるため、消費レートが異なるコンシューマーに適応することが困難です。プッシュ モードの目的は、できるだけ早くメッセージを配信することですが、これにより、コンシューマーがメッセージを処理する時間が十分になくなる可能性が高まり、通常はサービス拒否やネットワークの輻輳が発生します。プル モードでは、コンシューマーの消費容量に基づいて適切な速度でメッセージを消費できます。

Kafka の場合、プル モードの方が適しています。プル モードを使用すると、ブローカーの設計を簡素化できます。コンシューマーはメッセージの消費速度を個別に制御できます。同時に、消費者は、一括消費または個別消費のいずれかの消費方法を自分で制御できます。同時に、異なる送信セマンティクスを実現するために、異なる送信方法を選択することもできます。

6. Kafkaワークフロー

6.1.データの送信

上記のアーキテクチャ図を見ると、プロデューサーはプロデューサーであり、データのエントリ ポイントです。図の赤い矢印に注意してください。データを書き込むとき、プロデューサーは常にリーダーを探し、フォロワーに直接データを書き込むことはありません。リーダーはどうやって見つけますか?執筆プロセスはどのようなものですか?次の図を見てみましょう。

1. まず、クラスターからパーティション リーダーを取得します。
2. プロデューサーはリーダーにメッセージを送信します。
3. リーダーはメッセージをローカル ファイルに書き込みます。
4. フォロワーはリーダーからメッセージを受け取ります。
5. フォロワーはメッセージをローカルに書き込んだ後、リーダーに ACK 確認を送信します。
6. すべてのレプリカから ACK を受信した後、リーダーはプロデューサーに ACK 確認を送信します。

6.1.1.メッセージの順序の確保

注目すべき点は、メッセージがリーダーに書き込まれた後、フォロワーが同期のために積極的にリーダーに近づくことです。プロデューサーはプッシュ モードを使用してブローカーにデータを公開します。各メッセージはパーティションに追加され、ディスクに順番に書き込まれるため、同じパーティション内のデータの順序が保証されます。書き方の図は次のようになります。

6.1.2.メッセージペイロードの分割

前述のように、データは異なるパーティションに書き込まれるので、なぜ Kafka をパーティション分割する必要があるのでしょうか?パーティション分割の主な目的は次の通りだと推測できると思います。

• 拡張が容易:トピックには複数のパーティションを設定できるため、マシンを拡張することでデータ量の増加に簡単に対応できます。
• 同時実行性の向上:パーティションを読み取りおよび書き込み単位として使用すると、複数のコンシューマーが同時にデータを消費できるため、メッセージ処理の効率が向上します。

負荷分散に詳しい人なら、サーバーにリクエストを送信すると、サーバーがリクエストを読み込み、トラフィックを別のサーバーに分散する可能性があることを知っているはずです。では、Kafka では、トピックに複数のパーティションがある場合、プロデューサーはどのパーティションにデータを送信するかをどのように知るのでしょうか? Kafka にはいくつかの原則があります。

1. パーティションを書き込むときに、書き込むパーティションを指定できます。指定すると、対応するパーティションが書き込まれます。
2. パーティションが指定されていないがデータのキーが設定されている場合、キー値に基づいてパーティションがハッシュされます。
3. パーティションもキーも指定されていない場合は、ポーリングによってパーティションが選択されます。

6.1.3.メッセージが失われないようにする

メッセージが失われないようにすることは、メッセージ キュー ミドルウェアの基本的な保証です。では、プロデューサーは、Kafka にメッセージを書き込むときにメッセージが失われないようにするにはどうすればよいでしょうか?実際、これは上記の書き込みフローチャートで説明されており、ACK 応答メカニズムを介して行われます。プロデューサーがキューにデータを書き込むときに、Kafka がデータを受信したことを確認するかどうかを決定するパラメータを設定できます。このパラメータに設定できる値は 0、1、またはすべてです。

0 は、プロデューサーがクラスターにデータを送信するときにクラスターが戻るのを待つ必要がなく、メッセージが正常に送信されたことを保証しないことを意味します。最も安全性は低いですが、最も効率的です。

1 は、プロデューサーがクラスターにデータを送信するときに、リーダーが応答する限り次のデータを送信でき、リーダーがデータを正常に送信することを保証することを意味します。

all は、プロデューサーがクラスターにデータを送信するときに、すべてのフォロワーが次のデータを送信する前にリーダーからの同期を完了する必要があり、リーダーがデータを正常に送信し、すべてのレプリカがバックアップされることを保証することを意味します。セキュリティは最も高いが、効率は最も低い。

最後に、存在しないトピックにデータを書き込む場合、正常に書き込むことができるかどうかに注意してください。 Kafka はトピックを自動的に作成し、デフォルトの構成ではパーティションとレプリカの数は 1 になります。

6.2.データの保存

プロデューサーがデータを Kafka に書き込んだ後、クラスターはデータを保存する必要があります。 Kafka はデータをディスクに保存します。一般的に、ディスクへのデータの書き込みは時間のかかる操作であり、このような高同時実行コンポーネントには適していないと考えられています。 Kafka は最初に別のディスク領域を割り当て、データを順番に書き込みます (ランダム書き込みよりも効率的です)。

6.2.1.パーティション構造

前述したように、各トピックは 1 つ以上のパーティションに分割できます。トピックはより抽象的であると考えるなら、パーティションはより具体的なものです。パーティションはサーバー上で 1 つずつフォルダーとして表されます。各パーティション フォルダーには、複数のセグメント ファイル グループがあります。セグメント ファイルの各グループには、.index ファイル、.log ファイル、および .timeindex ファイル (以前のバージョンでは使用できません) の 3 つのファイルが含まれています。ログ ファイルは実際にメッセージが保存される場所であり、インデックス ファイルとタイムインデックス ファイルはメッセージを取得するために使用されるインデックス ファイルです。

上記のように、このパーティションには 3 つのセグメント ファイル グループがあります。各ログ ファイルのサイズは同じですが、保存されるメッセージの数は必ずしも同じではありません (各メッセージのサイズは一貫していません)。ファイルはセグメントの最小オフセットに基づいて名前が付けられます。たとえば、000.index には、オフセットが 0 から 368795 までのメッセージが格納されます。Kafka は、セグメンテーション + インデックスを使用して、検索効率の問題を解決します。

6.2.2.メッセージ構造

上記のログ ファイルは、実際にメッセージが保存される場所です。プロデューサーでメッセージを 1 つずつ Kafka に書き込みます。では、ログに保存されるメッセージはどのようなものなのでしょうか?メッセージには主に、メッセージ本文、メッセージ サイズ、オフセット、圧縮タイプなどが含まれます。知っておく必要がある最も重要な 3 つの事項は次のとおりです。

1. オフセット:オフセットは、パーティション内の各メッセージの位置を一意に識別する 8 バイトの連続 ID 番号です。
2. メッセージ サイズ:メッセージ サイズは 4 バイトを占め、メッセージのサイズを記述するために使用されます。
3. メッセージ本文:メッセージ本文には実際のメッセージ データ (圧縮済み) が格納され、占有されるスペースは特定のメッセージによって異なります。

6.2.3.ストレージ戦略

Kafka は、メッセージが消費されたかどうかに関係なく、すべてのメッセージを保存します。では、古いデータを削除する戦略は何でしょうか?

• 時間に基づいて、デフォルトの設定は 168 時間 (7 日間) です。
• サイズに基づいて、デフォルトの構成は 1073741824 です。

Kafka が特定のメッセージを読み取る時間の計算量は O(1) O ( 1 ) であるため、ここで期限切れのファイルを削除しても Kafka のパフォーマンスは向上しないことに注意してください。

6.3.消費データ

メッセージがログ ファイルに保存されると、コンシューマーはそれを使用できるようになります。メッセージ キュー通信の 2 つのモードについて説明する際に、ポイントツーポイント モードとパブリッシュ サブスクライブ モードについて説明しました。 Kafka はパブリッシュ/サブスクライブ モデルを採用しています。コンシューマーは Kafka クラスターからメッセージをアクティブにプルします。プロデューサーと同様に、コンシューマーもメッセージを発信する際にリーダーを探します。

複数のコンシューマーがコンシューマー グループを形成でき、各コンシューマー グループにはグループ ID があります。同じコンシューマー グループ内のコンシューマーは、同じトピックの下にある異なるパーティションからデータを消費できますが、グループ内の複数のコンシューマーが同じパーティションからデータを消費することはありません。次の図を見てみましょう。

この図は、コンシューマー グループ内のコンシューマーの数がパーティションの数よりも少ない状況を示しています。そのため、コンシューマーが複数のパーティションからデータを消費する状況が発生し、消費速度は 1 つのパーティションのみを処理するコンシューマーの処理速度ほど速くありません。コンシューマー グループ内のコンシューマーの数がパーティションの数より多い場合、同じパーティションからデータを消費するコンシューマーが複数存在することになりますか?上で述べたように、これは起こりません!追加のコンシューマーはどのパーティションからもデータを消費しません。したがって、実際のアプリケーションでは、コンシューマー グループ内のコンシューマーの数をパーティションの数と一致させることが推奨されます。

データの保存に関するセクションでは、パーティションが複数のセグメントに分割される方法について説明しました。各セグメントには、.log、.index、.timeindex ファイルが含まれています。保存される各メッセージには、オフセット、メッセージ サイズ、メッセージ本文などが含まれます。セグメントとオフセットについては何度も説明しました。セグメント+オフセットを使用してメッセージを検索するにはどうすればよいですか?オフセットが 368801 のメッセージを検索する必要がある場合、どのようなプロセスになりますか?次の図を見てみましょう。

1. まず、オフセット 368801 メッセージが配置されているセグメント ファイルを検索します (バイナリ検索を使用)。ここでは、2 番目のセグメント ファイルにあります。

2. 見つかったセグメントの .index ファイルを開きます (つまり、開始オフセットが 368796+1 である 368796.index ファイル、インデックス内のオフセット 368801 のメッセージのオフセットは 368796+5=368801 なので、ここで見つかる相対オフセットは 5 です)。ファイルは、相対オフセットと対応するメッセージの物理オフセットの関係を格納するためにスパース インデックスを使用するため、相対オフセットが 5 のインデックスを直接見つけることはできません。ここで、バイナリ検索方式は、相対オフセットが指定された相対オフセット以下であるインデックス エントリの中で最大の相対オフセットを見つけるためにも使用され、相対オフセットが 4 のインデックスが見つかります。

3. 相対オフセットが 4 のインデックスに基づいて、メッセージ ストレージの物理オフセット位置は 256 であると決定されます。データ ファイルを開き、オフセットが 368801 のメッセージが見つかるまで、位置 256 から順番にスキャンします。

このメカニズムは、オフセットが順序付けられているという事実に基づいており、セグメント + 順序付けされたオフセット + スパース インデックス + バイナリ検索 + シーケンシャル検索などの複数の方法を使用して、データを効率的に検索します。この時点で、消費者は処理のために処理する必要があるデータを取得できます。では、各消費者はどのようにして消費した場所を記録するのでしょうか?以前のバージョンでは、コンシューマーは消費されたオフセットを Zookeeper で管理し、一定期間ごとにレポートしていました。これにより、重複した消費やパフォーマンスの低下につながる可能性があります。新しいバージョンでは、コンシューマーによって消費されたオフセットは、Kafka クラスターの consumer_offsets トピックで直接管理されるようになりました。