「.NET 開発基盤部会 Wiki」は、「Open棟梁Project」,「OSSコンソーシアム .NET開発基盤部会」によって運営されています。
目次 †
概要 †
- デファクト・スタンダードの分散メッセージング・システム、
- 複数台のマシンでクラスタを構成
- 分散処理により高いスループットを発揮
- 最近は、
- ストリーム処理の中核と言われるようになって来ているらしい。
- “ETL is Dead; Long Live Stream”なんて言われてるらしい。
用途 †
データハブの構築 †
多数のサービス間で、従来のMQ的に機能する。
ストリーム処理の構築 †
分散処理のストリーム処理
ストリーム・データハブの構築 †
複数のデータ・ソースに様々な処理をする際に、
一度、データハブにキューイングする的な。
ストリーム・データ収集基盤の構築 †
ストリームだけでなく、バッチにも対応した、
複数のデータ・ソースからのデータ収集基盤としても利用可能。
特徴 †
高性能 †
高可用性 †
スケールアウト＋レプリケーション
- スケールアウト
- オートスケール
- 対応していない
- 送信・受信側の設定変更必要になるため。
- レプリケーション
- レプリケーションLeader / Follower型レプリケーション
- レプリケーションは、メッセージ受信後、直ぐに行われる。
- 都度フラッシュしない問題をレプリケーションで担保。
高信頼性 †
高信頼性メッセージング（再取得が可能な、確実な送受信）
- データ送信者（Publisher）のメッセージングを受信し、レプリケーションまで完了したら、ACKを返す。
- データ受信者（Subscriber）がメッセージを受信したら、メッセージに処理完了を記録する。
エコシステム †
連携可能なプロダクトが多い。
- Kafka本体に含まれているProducer/ConsumerライブラリはJava製
- 他にもサードパーティからPythonやC++など様々な言語製のライブラリが提供される。
詳細 †
アーキテクチャ †
メッセージングモデル・プロトコル †
- Publisher / Subscriberメッセージングモデルを採用
- MQTTなどの標準プロトコルではなく、独自プロトコルを使用
論理 / 物理データ †
の構造と管理
- 管理方法
- メッセージはRecordと言うキーバリュー形式
- Leader Replicaに書き込まれたRecordはFollower Replicaに複製される。
- Partitionへの書き込み / 読み出しはLeader Replicaにのみ行われる。
- Leader Replicaに障害が発生したら、いずれかのFollower Replicaが昇格する。
- 同期しているFollower Replicaを、In Sync Replica（ISR）と呼ぶ。
- ISR数が最小数まで回復すると、書き込みはコミットされ読み出し可能になる。
- 構造
- BrokerはReplicaごとにデータディレクトリを作成する。
- RecordをSegmentファイルに保存することで永続化する。
- Segmentファイルの集合をLogと呼ぶ。
- 管理方法
- Brokerには、複数のディスクが接続される。
- データディレクトリは各ディスクにラウンドロビン方式で割り当てられる。
- SegmentファイルのキャッシュはOS制御の処理で高速化可能
Partition †
Partitioning（1つのTopicは複数のPartitionで構成される）の話。
- Partitioner
- デフォルトのPartitionerのPartitioning方式はハッシュ方式
- partition key が null の場合は、ラウンドロビン方式になる。
- partition key に基づいてメッセージをルーティングできる。
- 別途、独自のPartitionerを実装できる。
- Partition数は、後から増やすことダケはできる。
ただし、Partitioner＋partition keyでPartitioningしている場合、
後からPartition数を増やすことが難しくなりがち。
Broker †
クラスタ内のサーバ・ノードのことをBrokerと呼ぶ。
- Broker同士はクラスタコーディネータであるZooKeeper?を使用して連携する。
- Brokerの１つがリーダーとなりBrokerクラスタを管理する。
Producer †
- 書き込み側のアプリケーション（Publisher）は、
Producerと呼ばれる書き込み用ライブラリを使用してRecordを書き込む。
- データ送信者（Publisher）は、
- Recordを送信するためにProducerのSend APIを呼び出す。
- Producerは、以下を行う。
- 定期的にいずれかのBrokerからメタデータを取得する。
- 各Brokerのホスト名、接続先ポート、Leader Replicaの場所など把握する。
- Produce リクエストでは、通信オーバーヘッド削減のため、ネットワークスレッドが
複数Topicの「Record Batch」を1回のリクエストでまとめて送信する。
- acksの設定によって、異なる返信タイミングで、リクエスト完了通知を受信する。
- 0：即時
- 1：Leader Replicaへの書き込み完了時
- all：最小ISR数まで複製完了時
Consumer †
- 読み出し側のアプリケーション（Subscriber）は、
Consumerと呼ばれる読み出し用ライブラリを使用してRecordを取り出す。
- データ受信者（Subscriber）は、
- Recordを取得するためにConsumerのPoll APIを呼び出す。
- Consumerは、以下を行う。
- 定期的にいずれかのBrokerからメタデータを取得する。
- 各Brokerのホスト名、接続先ポート、Leader Replicaの場所など把握する。
- Recordをどこまで読みだしたのかを示すOffsetを管理する。
- Consumer内部のキューに取得対象のRecordがなかった場合
・BrokerにFetchリクエストを投げてRecordを取得
・Fetchリクエストでは、以下の3つを指定
・取得対象のTopic
・Partitionのリスト
・各Partitionで取得したいOffset（Record番号）の範囲
・取得したRecord BatchはConsumer内部のキューに格納される。
- Consumer Group
1つ以上のConsumerでConsumer Groupを構成することで、
1TopicのデータをGroup内のConsumerで分散読み出しできる。
- リクエストの並列送信数（max.in.flight.requests.per.connection）を1に設定
- 特定のキーに対応するRecordを、特定のPartition（のRecord Batch）に集める
- Consumer Groupの中でもパーティション毎に割り当てが可能
機能 †
セキュリティ †
リソース割り当て制限（Quotas） †
クライアントが使用するBrokerリソースを制御できる。
- ネットワーク帯域幅
- ネットワークI/O
- ディスクI/O
- スレッドのCPU要求レート
Logコンパクション †
- 一定期間が過ぎたRecordを削除するのではなく、
同じキーの最新のRecord以外を削除する機能。
モニタリング †
- JMX (Java Management Extensions) により性能情報などのメトリックを公開。
- JMXに対応した監視ソフトウェアを使用することで、これらのメリックを収集できる。
Recordの重複排除 †
- At-most-once保証
- 最大一回。ロストが有り得る。
- 設定＆AP実装（冪等性）により可能。
冪等性 → 連番を付与的な。そんなレベル感。
- Exactly-once保証
- 必ず一回。理想的であるが技術的には難しい。
- トランザクション、エンドツーエンドで保障。
ツール †
Kafka Connect †
DBなどの外部システムとKafka間でデータを書き込み/読み出しするコネクタを定義
Kafka Streams †
Miller Maker †
- Kafkaクラスタ間で（Produceによる）ミラーリングしバックアップを行う。
- フォールトトレランス機能としての使用は意図されていない。
Docker Compose †
... †
参考 †
参考 †
Partitioning関連 †
ospn.jp †
Qiita †
![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
