Open3

Kafka: The Definitive Guideの自分用まとめ

さくてぃさくてぃ

1章 Kafka概要

1.2

Apache Kafka はPublish/Subscribeメッセージングシステム

1.2.2

Kafka内のデータの単位はメッセージと呼ばれている。メッセージは単なるバイト配列であり、特別な形式や意味を持たない。そのため、Apache AvroやJSONなどのスキーマを適用して処理しやすくすると良い。

1.2.3

Kafkaのメッセージはトピックに割り振られる。
通常、1つのトピックは複数のパーティションで構成され、1つのパーティション内でのみ時間順序が保証されている。
パーティションはそれぞれ異なるサーバーにホストできるので水平方向にスケールできる。

ストリームは、ProducerからConsumerへと移動する1つのデータの流れを表したもの。

1.2.4

Consumerはパーティションごとに最後に消費したメッセージのオフセットをZookeeperもしくはKafka自体に保存している。

1.2.5

1つのKafkaサーバーはBrokerと呼ばれている。
BrokerはProducerからメッセージを受信し、メッセージにオフセットを割り当てて、ディスク上のストレージにメッセージをコミットする。また、Consumerからパーティションに対するFetchリクエストを受け入れ、ディスクにコミットされたメッセージを返す。

Brokerはクラスタの一部として動作するように設計されており、1つのBrokerがクラスタのコントローラーとして機能する。コントローラーはBrokerへのパーティションの割り当てやBrokerの障害監視を担当している。

メッセージは一定期間永続的なストレージに保存される。デフォルトでは7日間または1GBに達するまで。
トピックはログコンパクションするように設定可能。

1.2.6

Kafkaクラスタのレプリケーションは単一クラスタ内でのみ機能する。複数のクラスタ間のレプリケーションには、Kafkaプロジェクトに含まれるMirrorMakerと呼ばれるツールを使う。

1.3

1.3.2

多くのキューイングシステムとは異なり、複数のクライアントで同じメッセージを消費できる。

1.5

1.5.4

LinkedInでは1兆を超える生成メッセージ(2015年8月時点)と1日1ペタバイトを超えるデータ消費をKafkaが支えている。

さくてぃさくてぃ

2章 Kafkaのインストール

執筆時点でのApache Kafkaの最新バージョンは1.1.0

2.1

2.1.3

ZookeeperはKafkaクラスタに関するメタデータとConsumerクライアントの詳細情報を格納している

Zookeeperのクラスタはアンサンブルと呼ばれる

2.3 Brokerの設定

2.3.2

トピックのパーティションは増やせるが減らせない。減らしたい場合はトピックの再作成が必要。

多くのユーザーはBrokerに均等に配分されるように、パーティションの数をBrokerと同数か倍数に設定している。

必要なパーティション数は、トピックの目標スループットをConsumerの期待スループットで割ることで導出できる。

log.retention.hoursはKafkaがメッセージをどのくらい保持するかを設定するものでデフォルトでは168時間(≡7日間)になっている。log.retention.minuteslog.retention.msというパラメータもあり、より小さな単位が優先される。

log.retention.bytesは保持するメッセージの総バイト数を設定するものでパーティションごとに適用される。

log.segment.bytesはログセグメントをクローズするときのサイズを指定する。デフォルトは1GB。
メッセージが期限切れになるのはログセグメントがクローズされてからなので、トピックの生成レートが低い場合はログセグメントのサイズ調整が必要。

log.segment.msはログセグメントをクローズするまでの時間を設定する。デフォルトでは設定されていないのでログセグメントはサイズによってのみクローズされる。

メモ

メッセージの削除はパーティションのセグメント単位で行われる。
Kafkaのドキュメントにはlog.segment.msではなくlog.roll.msと書いてあった。

2.4

ディスクとメモリの処理能力が重要。