それが Kafka アーキテクチャの原則です。

[51CTO.com からのオリジナル記事] この記事では主に、Kafka とは何か、ワークフローやストレージメカニズムを含む Kafka のアーキテクチャ、プロデューサーとコンシューマーについて説明します。

[[317242]]

画像はPexelsより

最終的には、ブローカー、プロデューサー、コンシューマー、コンシューマーグループ、トピック、パーティション、レプリカ、リーダー、フォロワーといった、Kafka の最も重要な概念を全員が習得することになります。これは、Kafka を学習して理解するための基礎であり、必要なコンテンツです。

意味

Kafka は、パブリッシュ/サブスクライブモデルに基づく分散メッセージキューであり、主にビッグデータのリアルタイム処理の分野で使用されます。

メッセージキュー

Kafka は本質的に MQ (メッセージキュー) です。メッセージキューを使用する利点は何ですか? （インタビューの質問）

デカップリング: キューの両側で処理を独立してスケーリングまたは変更できます。
回復可能性: メッセージを処理するプロセスがクラッシュした場合でも、キューに追加されたメッセージはシステムの回復後に引き続き処理できます。
バッファリング: 生成されたメッセージと消費されたメッセージの処理速度が一貫していない状況を解決するのに役立ちます。
柔軟性とピーク処理能力: 突然の過負荷要求によってシステムが完全にダウンすることはありません。メッセージキューにより、主要コンポーネントは突然のアクセス圧力に耐えることができます。
非同期通信: メッセージキューを使用すると、ユーザーはメッセージをキューに入れることはできますが、すぐには処理できません。

パブリッシュ/サブスクライブパターン

1 対多: プロデューサーがトピックにメッセージを公開し、複数のコンシューマーがトピックをサブスクライブします。トピックに公開されたメッセージはすべてのサブスクライバーによって消費され、消費されたデータはトピックからすぐにはクリアされません。

建築

Kafka は、プロデューサーと呼ばれる任意の数のプロセスからのメッセージを保存します。したがって、データは異なるトピックの下にある異なるパーティションに公開できます。

パーティション内では、これらのメッセージはインデックス化され、タイムスタンプとともに保存されます。コンシューマーと呼ばれる他のプロセスは、パーティションからのメッセージをサブスクライブできます。

Kafka は 1 つ以上のサーバーのクラスター上で実行され、パーティションはクラスターノード全体に分散できます。

以下は、Kafka の全体的な理解と認識を深めるための、Kafka の重要な概念の一部です。各概念の役割とそのより深い原則については、後で詳しく分析します。

プロデューサー: メッセージプロデューサー。Kafka ブローカーにメッセージを送信するクライアント。
コンシューマー: メッセージコンシューマー。Kafka ブローカーからメッセージを取得するクライアント。
コンシューマーグループ: コンシューマーグループ (CG)。コンシューマーグループ内の各コンシューマーは、異なるパーティションからデータを消費して消費容量を向上させる役割を担います。パーティションはグループ内の 1 つのコンシューマーのみが使用でき、コンシューマーグループは相互に影響を与えません。すべてのコンシューマーはコンシューマーグループに属します。つまり、コンシューマーグループは論理的なサブスクライバーです。
ブローカー: Kafka マシンはブローカーです。クラスターは複数のブローカーで構成されます。ブローカーは複数のトピックに対応できます。
トピック：キューとして理解できます。トピックはメッセージを分類します。生産者と消費者は同じトピックに直面しています。
パーティション: スケーラビリティを実現し、同時実行性を向上させるために、非常に大きなトピックを複数のブローカー (サーバー) に分散できます。トピックは複数のパーティションに分割でき、各パーティションは順序付けられたキューです。
レプリカ: バックアップ機能を実現し、クラスター内のノードに障害が発生した場合でも、ノード上のパーティションデータが失われず、Kafka が引き続き動作できるようにするため、Kafka はレプリカメカニズムを提供します。トピックの各パーティションには、複数のレプリカ、リーダー、および複数のフォロワーが存在します。
リーダー: 各パーティションの複数のコピーの「プライマリ」コピー。プロデューサーがデータを送信するオブジェクトと、コンシューマーがデータを消費するオブジェクトはすべてリーダーです。
フォロワー: 各パーティションの複数のコピーの「スレーブ」コピー。リーダーからのデータをリアルタイムで同期し、リーダーとのデータの同期を維持します。リーダーが失敗した場合、フォロワーが新しいリーダーになります。
オフセット: 消費者の消費の位置情報。データ消費の場所を監視します。コンシューマーがクラッシュして回復すると、消費場所から消費を継続できます。
Zookeeper : Kafka クラスターが適切に動作するために Zookeeper に依存する必要があります。 Zookeeper は、Kafka がクラスター情報を保存および管理するのに役立ちます。

ワークフロー

Kafka クラスターは、レコードストリームをトピックと呼ばれるカテゴリに保存します。各レコードは、キー、値、タイムスタンプで構成されます。

Kafka は分散ストリーミングプラットフォームです。それはどういう意味ですか？

メッセージキューやエンタープライズメッセージングシステムと同様に、レコードのストリームを公開およびサブスクライブします。
フォールトトレラントで永続的な方法でレコードのストリームを保存します。
レコードのストリームを処理します。

Kafka 内のメッセージはトピックによって分類されます。プロデューサーはメッセージを生成し、コンシューマーはメッセージを消費します。すべて同じトピックを対象とします。

トピックは論理的な概念ですが、パーティションは物理的な概念です。各パーティションは、プロデューサーによって生成されたデータを保存するログファイルに対応します。

プロデューサーによって生成されたデータはログファイルの末尾に継続的に追加され、各データには独自のオフセットがあります。

コンシューマーグループ内の各コンシューマーは、消費したオフセットをリアルタイムで記録します。これにより、エラーが発生して回復が行われたときに、最後の位置から消費を続行できます。

保管メカニズム

プロデューサーによって生成されたメッセージはログファイルの末尾に継続的に追加されるため、Kafka は、ログファイルが大きくなりすぎてデータの配置が非効率になるのを防ぐために、シャーディングとインデックス作成のメカニズムを採用しています。

各パーティションは複数のセグメントに分割され、各セグメントは「.index」インデックスファイルと「.log」データファイルの 2 つのファイルに対応します。

これらのファイルは同じフォルダーに配置されており、フォルダーの命名規則はトピック名-パーティション番号です。たとえば、トピック first には 3 つのパーティションがあり、対応するフォルダーは first-0、first-1、first-2 です。

 # ls /root/data/kafka/最初-0
 00000000000000009014.インデックス     
 000000000000000009014.ログ
00000000000000009014.タイムインデックス
00000000000000009014.スナップショット
リーダー-エポック-チェックポイント

インデックスファイルとログファイルの名前は、現在のセグメントの最初のメッセージのオフセットに基づいて付けられます。次の図は、インデックスファイルとログファイルの構造を示しています。

「.index」ファイルには大量のインデックス情報が保存され、「.log」ファイルには大量のデータが保存されます。インデックスファイル内のメタデータは、対応するデータファイル内のメッセージの物理オフセットを指します。

プロデューサー

パーティショニング戦略

パーティションの理由:

クラスター内で拡張すると便利です。各パーティションは、それが配置されているマシンに合わせて調整することができ、トピックは複数のパーティションで構成できるため、パーティション単位で読み取りおよび書き込みを行うことができます。
同時実行性が向上し、パーティション単位での読み取りと書き込みが可能になります。

パーティショニングの原則: プロデューサーから送信されたデータを ProducerRecord オブジェクトにカプセル化する必要があります。

このオブジェクトにはいくつかのパラメータを指定する必要があります:

トピック: 文字列型、NotNull。
パーティション: int 型、オプション。
timestamp: 長いタイプ、オプション。
key: 文字列型、オプション。
値: 文字列型、オプション。
ヘッダー: 配列型、Null 可能。

① パーティションが指定された場合、指定された値はそのままパーティションの値として使用されます。

②パーティションが指定されていないがキーが存在する場合、パーティション値はキーのハッシュ値とパーティション数の係数を取ることによって取得されます。

③ パーティションもキーも存在しない場合、最初の呼び出しでランダムな整数が生成され（その後の呼び出しごとに整数が増加します）、この値と使用可能なパーティションの数の係数を取ることでパーティション値が得られます。これは一般にラウンドロビンポーリングアルゴリズムとして知られています。

データの信頼性保証

プロデューサーによって送信されたデータが指定されたトピックに確実に送信されるようにするには、トピックの各パーティションがプロデューサーによって送信されたデータを受信した後、プロデューサーに ACK (ACKnowledge 確認) を送信する必要があります。

プロデューサーが ACK を受信した場合は次のラウンドを送信し、それ以外の場合はデータを再送信します。

①コピーデータ同期戦略

ACK をいつ送信しますか?リーダーが ACK を送信する前に、フォロワーとリーダーの同期が完了していることを確認してください。これにより、リーダーが電話を切った後でも、データを失うことなくフォロワーから新しいリーダーを選出できるようになります。

同期が完了した後、何人のフォロワーが ACK を送信する必要がありますか?同期が完了したら、すべてのフォロワーが ACK を送信する必要があります。

②ISR

2 番目のソリューションでは、プロデューサーはすべてのフォロワーが同期を完了した後にのみデータを送信し続けることができます。何らかの理由でフォロワーが失敗した場合、リーダーは同期が完了するまで待機する必要があります。

この問題を解決するにはどうすればいいでしょうか?リーダーは、リーダーと同期されているフォロワーのセットである動的な同期レプリカセット (ISR) を維持します。

ISR セット内のフォロワーがデータ同期を完了すると、リーダーはフォロワーに ACK を送信します。

フォロワーがリーダーと長時間データの同期に失敗した場合、フォロワーは ISR セットから除外されます。時間のしきい値は、replica.lag.time.max.ms パラメータによって設定されます。リーダーが失敗すると、ISR から新しいリーダーが選出されます。

③ACK応答メカニズム

重要度の低いデータの場合、信頼性の要件はそれほど高くなく、少量のデータ損失は許容されるため、ISR 内のすべてのフォロワーが正常にデータを受け入れるまで待つ必要はありません。

したがって、Kafka はユーザーに 3 つの信頼性レベルを提供します。ユーザーは、信頼性とレイテンシの要件のトレードオフに基づいて、次の構成を選択できます。

Ackパラメータ設定:

0: プロデューサーはブローカーの ACK を待機しません。これにより、レイテンシが最小になります。ブローカーは、データを受信するとすぐにディスクに書き込む前に戻ります。ブローカーに障害が発生すると、データが失われる可能性があります。
1: プロデューサーはブローカーの ACK を待ちます。パーティションリーダーは、データをディスクに正常に保存した後、ACK を返します。フォロワーが正常に同期される前にリーダーに障害が発生すると、データが失われます。
-1 (すべて): プロデューサーはブローカーの ACK を待機し、すべてのパーティションのリーダーとフォロワーがデータをディスクに正常にアップロードした後にのみ ACK を返します。ただし、ブローカーが ACK を送信したときにリーダーに障害が発生すると、データの重複が発生します。

④ トラブルシューティングの詳細

LEO: 各レプリカの最大オフセット。 HW: コンシューマーが確認できる最大オフセット、ISR キュー内の最小 LEO。

フォロワーの障害: フォロワーが失敗すると、一時的に ISR セットから除外されます。フォロワーが回復すると、ローカルディスクに記録された最後の HW を読み取り、ログファイルの HW より高い部分を切り取り、HW からリーダーとのデータ操作の同期を開始します。

フォロワーの LEO がパーティションの HW 以上の場合、つまりフォロワーがリーダーに追いつくと、ISR に再参加できます。

リーダーの障害: リーダーが失敗すると、ISR から新しいリーダーが選択されます。その後、複数のレプリカ間でデータの一貫性を確保するために、残りのフォロワーはまず HW より高いログファイルの部分を切り取り、次に新しいリーダーからのデータを同期します。

注: これにより、レプリカ間のデータの一貫性が確保されるだけで、データが失われたり重複したりしないことが保証されるわけではありません。

正確に 1 回だけのセマンティクス

サーバーの ACK レベルを -1 に設定すると、プロデューサーとサーバーの間でデータが失われないことが保証されます (つまり、「少なくとも 1 回」のセマンティクス)。

対照的に、サーバーの ACK レベルを 0 に設定すると、プロデューサーからの各メッセージが 1 回だけ送信されるようになります (つまり、「At Most Once」セマンティクス)。

「少なくとも 1 回」では、データが失われないことは保証されますが、データが重複しないことは保証されません。逆に、「At Most Once」ではデータが重複しないことは保証できますが、データが失われないことは保証できません。

ただし、トランザクションデータなどの非常に重要な情報については、下流のデータコンシューマーは、データが重複したり失われたりしないこと、つまり Exactly Once セマンティクスを要求します。

Kafka バージョン 0.11 では、べき等性が導入されました。プロデューサーがサーバーにどれだけ重複データを送信しても、サーバーは 1 つのコピーのみを保持します。

今すぐ：

少なくとも1 回 + べき等性 = 正確に 1 回

べき等性を有効にするには、プロデューサーパラメータで enable.idompotence を true に設定するだけです。

冪等性が有効なプロデューサーには初期化中に PID が割り当てられ、同じパーティションに送信されるメッセージにはシーケンス番号が付加されます。

ボルカー側は

ただし、再起動後に PID が変更され、パーティションごとに主キーが異なるため、パーティション間のセッションでは冪等性によって Exactly Once を保証することはできません。

消費者

摂取方法

コンシューマーはプルモードを使用してブローカーからデータを読み取ります。

消費者はプッシュモードを採用します。ブローカーがコンシューマーにメッセージをプッシュするレートはブローカーによって決定されるため、消費レートが異なるコンシューマーに適応することが困難になります。

その目的は、できるだけ早くメッセージを配信することですが、これにより、コンシューマーがメッセージを処理する時間が十分になくなる可能性が高まり、通常はサービス拒否やネットワークの輻輳が発生します。

プルモードでは、コンシューマーの消費容量に基づいて適切な速度でメッセージを消費できます。 Pull モードの欠点は、Kafka にデータがない場合、コンシューマーがループに陥り、空のデータを返し続ける可能性があることです。

コンシューマーはブローカーから積極的にデータを取得するため、長いポーリングを維持する必要があります。この問題に対処するために、Kafka コンシューマーはデータを消費するときにタイムアウトパラメータを渡します。

消費可能なデータがない場合、コンシューマーは一定期間待機してから戻ります。この期間をタイムアウトと呼びます。

パーティション割り当て戦略

コンシューマーグループには複数のコンシューマーが存在し、トピックには複数のパーティションがあるため、どのパーティションがどのコンシューマーによって消費されるかを決定するパーティション割り当て問題が必然的に発生します。

Kafka には 2 つの割り当て戦略があり、1 つは RoundRobin で、もう 1 つは Range です。デフォルトは範囲です。コンシューマーグループ内のコンシューマーが変更されると、パーティション割り当て戦略 (メソッド再割り当て) がトリガーされます。

①ラウンドロビン

RoundRobin ポーリング方式では、すべてのパーティション全体に対してハッシュソートを実行します。コンシューマーグループ内に割り当てられるパーティション数の最大差は 1 です。グループごとに分割されるため、複数のコンシューマーの消費データの不均衡の問題を解決できます。

ただし、グループ内の消費者が異なるトピックを購読している場合、消費の混乱が発生する可能性があります。次の図に示すように、Consumer0 はトピック A をサブスクライブし、Consumer1 はトピック B をサブスクライブします。

トピック A と B のパーティションをソートした後、コンシューマーグループに割り当てられます。 TopicB パーティション内のデータは Consumer0 に割り当てられる場合があります。

②範囲

Range 方式はトピックごとに分割されており、ポーリング方式の消費混乱の問題は発生しません。

ただし、次の図に示すように、Consumer0 と Consumer1 はトピック A と B を同時にサブスクライブするため、メッセージの配信が不均等になる可能性があります。コンシューマーグループでサブスクライブされるトピックの数が増えるほど、パーティションの分散が不均衡になる可能性があります。

オフセットメンテナンス

コンシューマーは消費プロセス中に停電やその他の障害を経験する可能性があるため、コンシューマーが回復した後は、障害前の状態から消費を継続する必要があります。

したがって、コンシューマーは、障害が回復した後も消費を継続できるように、消費したオフセットをリアルタイムで記録する必要があります。

Kafka バージョン 0.9 より前では、コンシューマーはデフォルトでオフセットを Zookeeper に保存していました。バージョン 0.9 以降では、コンシューマーはデフォルトでオフセットを Kafka の組み込みトピック (__consumer_offsets) に保存します。

要約する

上記では、Kafka のアーキテクチャについて詳しく説明しましたが、特に Kafka を習得するために必要な理論と基礎に重点を置いています。今後は、API、トランザクション、インターセプター、モニタリングなど、Kafka の高度な記事をコードや例の形で更新し、誰もが Kafka を徹底的に理解して使えるようにしていきます。

著者: Zang Yuanhui

簡単な自己紹介: 中国科学技術星図有限公司（北京）のR&D部門のバックエンド技術グループに勤務。私は Python/Java 開発が得意で、フロントエンドの基礎を理解しています。私は MySQL と MongoDB に精通しており、Redis を理解しています。私は Linux 開発環境に精通しており、シェルプログラミングを習得しており、Git ソースコード管理の習慣も持っています。私は Nginx、Flask、Swagger 開発フレームワークに精通しています。 Docker+Kubernetes クラウドサービス開発の経験があります。人工知能とクラウドネイティブテクノロジーに大きな関心を持っています。

[51CTO オリジナル記事、パートナーサイトに転載する場合は、元の著者とソースを 51CTO.com として明記してください]

<<: 同意しますか？コンピューティングの未来は分散化です!

>>: クラウドネイティブコンテナセキュリティプラクティス