kafka

スケーラビリティに優れた分散メッセージキュー

クラスタによって分散処理可能、冗長性有り

ユースケース

データハブの構築

ストリーミングアプリケーションの構築

構成

分散キューのことをTopicと呼ぶ

PubSubの一般的な用語ぽい？

Brokerがクラスタを組む

ZooKeeper clusterによってBroker間の連携をする

書き込み/読み出し先は各Partitionのリーダへ行う

Kafkaのツール

Kafka Connect: DBなどの外部システムと書き込み/読み込みできる

Kafka Streams: データ処理/分析用のクライアントライブラリ

Kafka Maker: kafkaクラスタ間のミラーリング

Producer/ConsumerにBrokerがレスポンスする

Consumerがfetchしたいデータがない場合はブロック

Broker用クラスタ

4台あれば、1台故障しても平気

1ノードでディスク10台以上

OSは2台でRAID1

ZooKeeper用クラスタ

3台あれば、1台故障しても平気

kafkaでボトルネックになりやすい箇所

ノード間のネットワークI/O

ログの読み書きによるディスクI/O

性能の見積もり方法が書いてある

Kafkaの最大スループット（803MB/s）を超えない範囲のRecord流量であれば、Producerで詰まることはなくなる（①、②の待ち時間ほぼ無くなる）ため、レイテンシは3秒程度になると推定できます。

acks = all

スライド版

動作の概要が図付きで書いてある

kafkaのconsumerはpull型

consumerはグループを成す

この単位でメッセージを購読する

1つのPartitionのデータは1つのConsumerグループ内の1つのConsumerにのみ消費される

ランダムにConsumerをロードバランスできる？

どこまでメッセージを読んだのかconsumerで管理する必要がある

PubSub型のPersistentメッセージバス

Producer

acks = 0, 1, all

0はcast, 1はcall, allは全replicaへの書き込み待ち

Kafka投入前段のAPIでデータを正規化したが、DBの参照が必要になってしまった

DBに依存、そちらのメンテ影響でAPIが動かなくなる可能性がある

対策

Ingest Topicで無加工のメッセージを受け付ける

これもkafkaのキュー

その次の段でETL処理によってフォーマット変換する

ここでDBを参照

DBが死んでも前段のキューに蓄えられる

Consumerが何かしら処理を行った後にそのイベントをKafkaにライトバックすることを考えていなかった

どのイベントで着火し・そして次に何を着火させるべきかという視点でConsumerアプリを設計する規約を作ればよかった

イベントのワークフローを途切れさせない設計をしていれば、Kafkaの実力をもっと活かせたはず

AsyncCommitとAutoCommit