特徴

Apache KafkaはLinkedInでスタートしたstreaming processing framework。

当初の目的として以下が挙げられている。

push-pullモデルによって、producerとconsumerを疎結合にする
メッセージの永続性
高スループット
水平スケール

guideでは、serialization formatとしてAvroが推奨されている。

2015年8月時点で、LinkedInでは1日あたり

1兆メッセージのproduce
ペタバイト超のconsume

で使ってるらしい。恐ろしいスケールだ。

基本用語/概念

Topic

messageをカテゴライズする単位。

アクセス解析システムだったらPV / Click / CVみたいな単位になりそう。

messageはtopicに対してappend-onlyで書き込まれていく。

Partition

topicが分散させる単位のことをpartitionと呼ぶ。

topicに対するpartition数は、増加させることしかできない。

partition数は、Kafka cluster内のbrokerと同一か、その倍数にすることで効率よく分散させられる。

Broker

一つのKafka serverをbrokerと呼ぶ。

Producer

topicに対してmessageを書き込むKafka clientのことをproducerと呼ぶ。

デフォルトではpartitionを指定せずに、すべてのpartitionに均等に書き込むが、partitionerによって明示することも可能。ここらへんはSparkと似てる。

Consumer

topicからmessageを読み出すKafka clientのことをconsumerと呼ぶ。

messageはpartition内でユニークなoffsetを持っており、これを使うことでどこまでconsumeしたかをトラッキングできる。

同一のtopicをsubscribeするconsumerたちは同一のconsumer groupに属する。

Kafka clusterのサイジング

以下から算出する

messageを保持するために必要なdisk space
必要となるスループットと、一台あたりの処理可能なnetwork capacity

Producer

Producerの詳細。

KafkaProducerインスタンスに対して行う。

書き込みスループットを上げたい場合、複数スレッドからsendを呼び出してよい。

messageの書き込み方法には以下の3種類がある。

Fire-and-forget
- sendを呼び出し、返値を無視する
Synchronous
- sendで返されるFutureを同期的に待ち受ける
Asynchronous
- callbackとともにsendを呼び出す

Producerの設定

acks

sendが成功したと判断するために、いくつのpartition replicaに対する書き込み成功を要求するか、を表す。

acks=0
- brokerからのresponseを待たずに成功と判断する。もっともスループットは出るが、messageがロストしうる
acks=1
- leader replicaへの書き込み成功を待つ。leaderがcrashして他のreplicaがleader選出された場合にはmessageがロストしうる
acks=all
- 全replicaへの書き込み成功を待つ

ここらへん、LinkedInでは具体的にどういうログをどのacksで運用しているのか、気になる

Consumer

Consumerの詳細。

一つのtopicに対するconsumerのスループットを上げたい場合、consumer groupにconsumerを追加する。

topicの持つpartition数を超える数のconsumerがconsumer group内にあっても、意味がない（いくつかは遊ぶことになる）

複数のapplicationで同一のtopicをsubscribeしたい場合は、それぞれのapplicationでconsumer groupを用意する。

rebalance

consumerの追加/削除を行った場合、partitionのrebalanceが行われる。

rebalanceの最中はconsumeができなくなるため、若干のダウンタイムが発生する。

consumerの追加 / 削除は、brokerのgroup coordinatorへのAPI request / heartbeatによって行われる。

Consumerの作成

Commits / Offsets