Kafkaから気になったところだけ抽出

2章 Kafkaのインストール

partition数の選び方

そのtopicに対するスループットを考慮する。
- 例えばそのtopicに1GB/secのReadWriteを期待し、かつConsumerが50MG/secでしかデータを処理できない場合、20のConsumerが並列に仕事ができるよう、partition数を20にすればよいことがわかる。
- 尚、ProducerはConsumerよりずっと高速なので、見積もりの考慮に含む必要はない。
partition数が多すぎてもよくない
- リーダーの選出に時間がかかる。
- 各partitionはBroker上のメモリやその他のリソースを費やす。
現在ではなく将来の設計に基づいて数を決める。
- partition数は、減らすことはできないが増やすことはできる。
- しかしながら、partition key に基づいてメッセージをルーティングしている場合は、後からpartition数を増やすことが難しくなりがち。

Kafka自体には、ハードウェア構成に対する厳しい要件はない。が、パフォーマンスが問題となると考慮すべき。
ディスク
- ディスクへの書き込みは速ければ速いほどよい(そりゃそうだ)
メモリ
- Consumerが読み出すメッセージはページキャッシュに格納されている。即ちページキャッシュに使えるメモリの容量が大きいほど高速に読み出せる。
- JVMのヒープメモリはさほど使わない。150,000 mes/sec と 200 Mbit/sec のデータレートの処理が必要であっても、Brokerは5GBのヒープ領域で実行できる。
CPU
- CPUはハードウェア選択における面たる要因ではない。

Zookeeperへの書き込みが発生するのは以下の二つのみ
- ConsumerGroupのメンバーシップに対する変更
- Kafkaクラスタ自体に対する変更
Consumerはオフセットの管理にZKかKafkaのどちらかを使用するか設定できる。
- 0.9.0.0 より前のバージョンではZKでオフセット管理するのがデフォルト。0.9.0.0からKafka自体でオフセットを管理できるようになった。
- ZKでオフセットを管理する場合、他のソフトウェアでZKを使用していなかを考慮する(たとえばSparkやHadoopなど)。この場合ZKとのやり取りが増えるので別のソフトウェアに影響を及ぼしうる。

bootstrap.serversは全てのBrokerを指定する必要はない。初期接続で全ての詳細情報を取得できるので。ただそれでも複数指定しておいたほうがよい。一つのBrokerがダウンしても別のBrokerにアクセスできるので。
Producerの送り方は3種類
- Fire-and-forget: うまく届いたかは気にしない
- 同期送信: send().get()で一個ずつ届いたかどうかを確認する
- 非同期送信: Kafkaから応答を受け取るとコールバック関数が呼び出される。大抵の場合これでよい。なぜならProducerはうまく届いたときにKafkaから返ってくるオフセット情報などは必要ないから。ERRORである場合のみ気にしたいので。
keyがnullでデフォルトのPartitionerを使っている場合はラウンドロビンで均等にparitionに分配される。
keyが指定されてデフォルトのPartitionerを使っている場合はそれらのメッセージが同一のpartitionにpublishされる。
- keyからhashを計算してそれに相当するpartitionにpublishされる。
- hashの計算は独自のアルゴリズムが使われているのでjavaのバージョンがあがってもここは変化なし。
keyを指定すると同じpartitionにメッセージがpublishされるが、これは特定のpartitionにデータが偏ることにもなってします。これを避けるためには独自のPartitionerを実装すればよい。

topicのpartition数よりも多いConsumerは意味がない。それだけアイドル状態になってしまう。
リバランス(一番興味がある)
- リバランスとは、Consumerから別のConsumerにOwnershipを移すことを指す。
- リバランスが起きる条件:
  - ConsumerGroupにConsumerが追加された
  - Consumerがクラッシュした
ConsumerはGroup Coordinatorに指定されたBrokerにheart beatを送る。
heart beatを送るのは以下のタイミング:
- pollingしているとき
- commit時
一定時間heart beatがないと、BrokerはそのClientが死んだとみなしてリバランスを開始する。
- その間処理をしていたConsumerはコミットされないままになる。