■ はじめに

https://dk521123.hatenablog.com/entry/2023/04/23/235534
https://dk521123.hatenablog.com/entry/2023/04/24/153846
https://dk521123.hatenablog.com/entry/2023/04/26/103421

の続き。

今回は、Apache Kafkaの基本となる構成要素などについて扱う。

【１】メッセージ
【２】システム構成
　１）Producer (Publisher)
　２）Broker
　３）Consumer (Subscriber)
　補足１：Apache zookeeper
　補足２：メッセージモデル
【３】論理構造
　１）Topic
　２）Partition
　３）Replica
　補足１：Offset（オフセット）
【４】Kafka API
　１）Producer API
　２）Consumer API
　３）Connect API
　４）Streams API （Kafka Streams）
　５）Admin API

【１】メッセージ

* Kafka に送受信されるデータの基本単位
* 「イベント」、「レコード」と呼ぶ場合もある

ヘッダー（Header）

* イベントのメタデータや補足情報を格納

キー（Key）

* イベント格納先の振り分けや集約に使用されるデータ
* キーを設定しないことも可能

タイムスタンプ（Timestamp）

* イベント作成時の時刻

値（Value）

* イベントで処理したいデータ本体
* 形式は様々（文字列、JSONなど）

【２】システム構成

* 大きく分けて、以下の３通りで構成。

[Producer(Publisher)]<=>[Broker]<=>[Consumer(Subscriber)]

１）Producer (Publisher)

* データをBrokerに対して、送信する側のアプリケーション

https://tech-lab.sios.jp/archives/32041
https://tech-lab.sios.jp/archives/32130

２）Broker

* Kafkaクラスタを構成するサーバ
 =>逆の言い方をすると Brokerが1台～複数で構成されたものを
　「Kafkaクラスタ」と呼ぶ
* Zookeeper と連携（後述「補足１：Apache zookeeper」を参照）

３）Consumer (Subscriber)

* データをBrokerに対して、受信する側のアプリケーション
 => 詳細は、以下の関連記事を参照のこと

https://dk521123.hatenablog.com/entry/2023/10/17/235420

補足１：Apache zookeeper

* Kafkaのメタデータ（※１）を保持する
* Zookeeper もクラスタ（複数）で構成

※１：Zookeeperで管理しているメタデータの内容

* Topicの一覧
* Topic の設定値
* Partition の状態
* Broker の一覧
* Broker のACL(Access Control List)の設定値

補足２：メッセージモデル

主なメッセージモデルは以下の通り
~~~~~
[1] キューイングモデル (待ち行列モデル)
[2] Pub/Subメッセージングモデル
~~~~~

Kafka は、この2つの特徴を併せ持っている
 => ただ、「[2] Pub/Subメッセージングモデル」がメイン

【３】論理構造

１）Topic
２）Partition
３）Replica

１）Topic（トピック）

* Kafkaのメッセージの送受信先
 => Kafkaクラスタ上に作られるメッセージの論理的な入れ物
 => Topic 名は、一意で区別される
 => Topicに送信されたメッセージは1つ以上のPartitionに分割されて保存

２）Partition（パーティション）

* 分散処理のために、Topicを分割したもの
* 各Partitionにメッセージを均等にする

Partitionの特徴

[1] 同一Partitionでは、イベントの順序が送信順であることが保証されている
[2] レプリケーションの冗長化（じょうちょうか）

[1] 同一Partitionでは、イベントの順序が送信順であることが保証されている

* 例：Partition-2のOffset=12, Offset=13の配信タイムスタンプは前者が先
 => ただし、Topic間のPartition間は順序は保証されていない

[2] レプリケーションの冗長化（じょうちょうか）

* 各Partitionのメッセージは、複数のBrokerにコピーされる
* 一つのPartitionにつき、レプリカ内で書き込み可能なPartition
　（このPartitionを「Leader Replica」と呼ぶ）はひとつだけ
* 「Leader Replica」のBrokerに障害が発生した場合、
　別のBrokerにある「Follower Replica」が「Leader Replica」として昇格する

３）Replica

* 耐障害のために作られる各Patitionの複製

[1] Leader Replica

* Product/Consumerと直接やりとりするデータ

[2] Follower Replica

* 「Leader Replica」と常に同期をとっている耐障害に備えているデータ
 => サーバに障害が起きた際に、そのサーバに保持されていた「Leader Replica」の
　　代わりになるように控えている

補足１：Offset（オフセット）

* パーティション内のメッセージの位置（オフセット）を表す
 => 特定のパーティションの各メッセージには一意のオフセットがあり、
　　パーティション内のコンシューマーの位置を特定して、
　　消費したレコード数を追跡するのに役立つ

https://access.redhat.com/documentation/ja-jp/red_hat_amq/7.6/html/amq_streams_on_openshift_overview/kafka-concepts_str

内部オフセットトピック：__consumer_offsets

* コンシューマーグループをもとに、
　コミットされたオフセット、最後のオフセットと次のオフセットの位置
　に関する情報が保存されている

【４】Kafka API

１）Producer API

* Topic にメッセージを送信するためのAPI

２）Consumer API

* Topic からメッセージを受信するためのAPI

３）Connect API

* DB、TwitterなどのデータシステムとKafka間で
　継続的にメッセージを送受信するためのAPI
* 詳細は、以下の関連記事を参照のこと

Apache Kafka ～ Kafka Connect ～
https://dk521123.hatenablog.com/entry/2023/04/29/185133
Apache Kafka ～ Kafka Connect / PostgreSQL ～
https://dk521123.hatenablog.com/entry/2023/05/02/233806

４）Streams API （Kafka Streams）

* Kafkaから読み取ったストリームデータを
　リアルタイムに処理するためのAPI

５）Admin API

* Kafkaクラスタの管理目的に使用されるAPI
 => 例えば、Topic, ACI, その他Brokerに関わる設定操作

プログラムの超個人的なメモ

Memo for Programming.

【Kafka】Apache Kafka ～入門編～