「[[.NET 開発基盤部会 Wiki>http://dotnetdevelopmentinfrastructure.osscons.jp]]」は、「[[Open棟梁Project>https://github.com/OpenTouryoProject/]]」,「[[OSSコンソーシアム .NET開発基盤部会>https://www.osscons.jp/dotNetDevelopmentInfrastructure/]]」によって運営されています。

-[[戻る>分散処理:データ収集・格納系]]
--[[Apache Sqoop]]
--[[Fluentd/Embulk]]
--[[Logsatsh, Beats>Elasticsearch#r521f91b]]
--[[Apache Flume]]
--[[Apache NiFi]]
--Apache Kafka

*目次 [#y0e48a12]
#contents

*概要 [#nb51198c]
-デファクト・スタンダードの分散メッセージング・システム、
--複数台のマシンでクラスタを構成
--分散処理により高いスループットを発揮

-最近は、
--ストリーム処理の中核と言われるようになって来ているらしい。
--“ETL is Dead; Long Live Stream”なんて言われてるらしい。

**用途 [#e6cc97c3]

***データハブの構築 [#hc75520d]
多数のサービス間で、従来のMQ的に機能する。

***ストリーム処理の構築 [#l6146224]
[[分散処理のストリーム処理>分散処理:ストリーム系]]

***ストリーム・データハブの構築 [#r6a6f053]
複数のデータ・ソースに様々な処理をする際に、~
一度、データハブにキューイングする的な。

***ストリーム・データ収集基盤の構築 [#t02585b4]
ストリームだけでなく、バッチにも対応した、~
複数のデータ・ソースからのデータ収集基盤としても利用可能。

**特徴 [#w1ca7a7e]

***高性能 [#e695fe91]
-[[スケールアウト>#pf6ff52d]]
-都度フラッシュしない(OS任せ)。

***高可用性 [#pf6ff52d]
スケールアウト+レプリケーション

-スケールアウト
--オートスケール
---対応していない
---送信・受信側の設定変更必要になるため。

-レプリケーション
--レプリケーションLeader / Follower型レプリケーション
--レプリケーションは、メッセージ受信後、直ぐに行われる。
--都度フラッシュしない問題をレプリケーションで担保。

***高信頼性 [#r7fd81be]
高信頼性メッセージング(再取得が可能な、確実な送受信)
-データ送信者(Publisher)のメッセージングを受信し、[[レプリケーション>#pf6ff52d]]まで完了したら、ACKを返す。
-データ受信者(Subscriber)がメッセージを受信したら、メッセージに処理完了を記録する。

***エコシステム [#q59d720f]
連携可能なプロダクトが多い。
-Kafka本体に含まれている[[Producer>#b9ba294c]]/[[Consumer>#j5dca672]]ライブラリはJava製
-他にもサードパーティからPythonやC++など様々な言語製のライブラリが提供される。

*詳細 [#q0494ca8]

**アーキテクチャ [#vdbcf9f8]

***メッセージングモデル・プロトコル [#y3daf63d]
-Publisher / Subscriberメッセージングモデルを採用
-MQTTなどの標準プロトコルではなく、独自プロトコルを使用

***論理 / 物理データ [#ya19295d]
の構造と管理

-論理データ

--構造
---1つのTopicは複数の[[Partition>#n332dfb0]]で構成される。
---各[[Partition>#n332dfb0]]は[[Broker>#m55052d4]]間で複製された複数のReplicaで構成される。
---各[[Partition>#n332dfb0]]には1個のLeader Replicaと0個以上のFollower Replicaが存在する。

--管理方法
---メッセージはRecordと言うキーバリュー形式
---Leader Replicaに書き込まれたRecordはFollower Replicaに複製される。
---[[Partition>#n332dfb0]]への書き込み / 読み出しはLeader Replicaにのみ行われる。
---Leader Replicaに障害が発生したら、いずれかのFollower Replicaが昇格する。
---同期しているFollower Replicaを、In Sync Replica(ISR)と呼ぶ。
---ISR数が最小数まで回復すると、書き込みはコミットされ読み出し可能になる。

-物理データ構造

--構造
---[[Broker>#m55052d4]]はReplicaごとにデータディレクトリを作成する。
---RecordをSegmentファイルに保存することで永続化する。
---Segmentファイルの集合をLogと呼ぶ。

--管理方法
---[[Broker>#m55052d4]]には、複数のディスクが接続される。
---データディレクトリは各ディスクにラウンドロビン方式で割り当てられる。
---Segmentファイルのキャッシュは[[OS制御>WindowsユーザがLinuxに乗り換える際に、知っておくとイイ情報集。#wf110cea]]の処理で高速化可能

***Partition [#n332dfb0]
Partitioning(1つのTopicは複数のPartitionで構成される)の話。

-Partitioner
--デフォルトのPartitionerのPartitioning方式はハッシュ方式
---partition key が null の場合は、ラウンドロビン方式になる。
---partition key に基づいてメッセージをルーティングできる。
--別途、独自のPartitionerを実装できる。

-Partition数は、後から増やすことダケはできる。~
ただし、Partitioner+partition keyでPartitioningしている場合、~
後からPartition数を増やすことが難しくなりがち。

***Broker [#m55052d4]
クラスタ内のサーバ・ノードのことをBrokerと呼ぶ。
-Broker同士はクラスタコーディネータであるZooKeeperを使用して連携する。
-Brokerの1つがリーダーとなりBrokerクラスタを管理する。

***Producer [#b9ba294c]
-書き込み側のアプリケーション(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 [#j5dca672]
-読み出し側のアプリケーション(Subscriber)は、~
Consumerと呼ばれる読み出し用ライブラリを使用してRecordを取り出す。

-データ受信者(Subscriber)は、
--Recordを取得するためにConsumerのPoll APIを呼び出す。

--Consumerは、以下を行う。
---定期的にいずれかのBrokerからメタデータを取得する。
---各Brokerのホスト名、接続先ポート、Leader Replicaの場所など把握する。
---Recordをどこまで読みだしたのかを示すOffsetを管理する。

---Consumer内部のキューに取得対象のRecordがなかった場合~
・BrokerにFetchリクエストを投げてRecordを取得~
・Fetchリクエストでは、以下の3つを指定~
 ・取得対象のTopic~
 ・[[Partition>#n332dfb0]]のリスト~
 ・各[[Partition>#n332dfb0]]で取得したいOffset(Record番号)の範囲~
・取得したRecord BatchはConsumer内部のキューに格納される。

-Consumer Group~
1つ以上のConsumerでConsumer Groupを構成することで、~
1TopicのデータをGroup内のConsumerで分散読み出しできる。

***[[順序保証>分散処理:ストリーム系#g0990853]] [#e403904d]
-リクエストの並列送信数(max.in.flight.requests.per.connection)を1に設定
-特定のキーに対応するRecordを、特定の[[Partition>#n332dfb0]](のRecord Batch)に集める
--Consumer Groupの中でもパーティション毎に割り当てが可能

**機能 [#d0cbbfff]

***セキュリティ [#c86b7e87]
-接続認証、通信データの暗号化
--SSL/[[SASL>https://techinfoofmicrosofttech.osscons.jp/index.php?%E3%83%A1%E3%83%BC%E3%83%AB#wa05ce37]]
--[[クライアント証明書>https://techinfoofmicrosofttech.osscons.jp/index.php?%E8%A8%BC%E6%98%8E%E6%9B%B8#c42748a0]]

-クライアントによる読み取り/書き込み操作の認証

***リソース割り当て制限(Quotas) [#z2bbbf4f]
クライアントが使用するBrokerリソースを制御できる。
-ネットワーク帯域幅
-ネットワークI/O
-ディスクI/O
-スレッドのCPU要求レート

***Logコンパクション [#v77cb63f]
-各キーの最新Recordのみを保持する。

-一定期間が過ぎたRecordを削除するのではなく、~
同じキーの最新のRecord以外を削除する機能。

***モニタリング [#odd38996]
-JMX (Java Management Extensions) により性能情報などのメトリックを公開。
-JMXに対応した監視ソフトウェアを使用することで、これらのメリックを収集できる。

***Recordの重複排除 [#w64e438f]
-At-least-once保証
--最低一回。重複が有り得る。
--Kafkaの既定値。

-At-most-once保証
--最大一回。ロストが有り得る。
--設定&AP実装(冪等性)により可能。~
冪等性 → 連番を付与的な。そんなレベル感。

-Exactly-once保証
--必ず一回。理想的であるが技術的には難しい。
--トランザクション、エンドツーエンドで保障。

**ツール [#ncf7c1cb]

***Kafka Connect [#oe43aca7]
DBなどの外部システムとKafka間でデータを書き込み/読み出しするコネクタを定義

***Kafka Streams [#w5ea1b0c]
-クライアントライブラリとして機能し、
-ウィンドウ処理などの[[ストリーム系の分散処理>分散処理:ストリーム系]]を実装可能。

***Miller Maker [#a1ecdb46]
-Kafkaクラスタ間で(Produceによる)ミラーリングしバックアップを行う。
-フォールトトレランス機能としての使用は意図されていない。

**Docker Compose [#y942d53b]
***... [#of1d5ed2]
***参考 [#q63d12a6]
-docker-compose で Kafka の動作確認 - Qiita~
https://qiita.com/tily/items/ea212a7fe68d62e34644

-kafka-docker でローカルに kafka クラスタを構築する - 駄文型~
https://koheikimura.hatenablog.com/entry/2017/05/15/190000

**[[チュートリアル>Kafkaチュートリアル]] [#t8f1e081]

*参考 [#z6beb8f4]
-Apache Kafka~
https://kafka.apache.org/

-Apache Kafka - Wikipedia~
https://en.wikipedia.org/wiki/Apache_Kafka

-StormとKafkaによる~
リアルタイムデータ処理 - Yahoo! JAPAN Tech Blog~
https://techblog.yahoo.co.jp/programming/storm/

-ITアーキテクトブログ - Medium~
[[Apache Kafkaを使ったアプリ設計で反省している件を正直ベースで話す>https://medium.com/@laqiiz/apache-kafka%E3%82%92%E4%BD%BF%E3%81%A3%E3%81%9F%E3%82%A2%E3%83%97%E3%83%AA%E8%A8%AD%E8%A8%88%E3%81%A7%E5%8F%8D%E7%9C%81%E3%81%97%E3%81%A6%E3%81%84%E3%82%8B%E4%BB%B6%E3%82%92%E6%AD%A3%E7%9B%B4%E3%83%99%E3%83%BC%E3%82%B9%E3%81%A7%E8%A9%B1%E3%81%99-6116544cc6fd]]

-ETLは過去のものか - Apache Kafkaがデータ処理の未来なのか?~
https://www.infoq.com/jp/articles/batch-etl-streams-kafka/

**Qiita [#w354075c]
-Kafka~
https://qiita.com/kenji-kondo/items/0e9beffb91406f4d7122

-sigmalist~
https://qiita.com/sigmalist

--Apache Kafkaの
---概要とアーキテクチャ~
https://qiita.com/sigmalist/items/5a26ab519cbdf1e07af3

---Producer/Broker/Consumerのしくみと設定一覧~
https://qiita.com/sigmalist/items/3b512e2ab49b07271665

---推奨構成と性能の見積もり方法~
https://qiita.com/sigmalist/items/b3d25e914dc30539ece4

--Apache Kafkaの性能検証

---(1): 検証環境とパラメータチューニングの内容~
https://qiita.com/sigmalist/items/730c7c82e02e5a837b9a

---(2): Producerのチューニング結果~
https://qiita.com/sigmalist/items/0cd76d7edb055e89d1e6

---(3): Brokerのチューニング結果~
https://qiita.com/sigmalist/items/0795bde01bcbd78b1c47

---(4): Producerの再チューニングおよびConsumerのチューニング~
https://qiita.com/sigmalist/items/b0bc222f449a9f3cc273

---(5): システム全体のレイテンシについて~
https://qiita.com/sigmalist/items/111e96cdae69bb2d89e6

**ospn.jp [#gb5cd5d1]
-オープンソースカンファレンス2017 .Enterprise - イベント案内~
2017-12-08 (金): めざせ!Kafkaマスター ~Apache Kafkaで最高の性能を出すには~~
https://www.ospn.jp/osc2017.enterprise/modules/eguide/e33.html

--めざせ!Kafkaマスター ~Apache Kafkaで最高の性能を出すには~~
https://www.ospn.jp/osc2017.enterprise/pdf/OSC2017.enterprise_Hitachi_Kafka.pdf

-最近広がりつつあるストリーム処理を知ろう!~
~Apache Kafkaを活用したストリーム処理の基本とユースケース~~
セミナープログラム - オープンソースカンファレンス2020 Online/Fall~
https://event.ospn.jp/osc2020-online-fall/session/202763

--OSC2020 OnlineFall 10-24 A-6 - YouTube~
https://www.youtube.com/watch?v=dQyxa-d8zUI

-ストリーム処理に広く使われるApache Kafkaの超概要~
~一問一答形式で簡単にKafkaをご紹介~~
セミナープログラム - オープンソースカンファレンス2020 Online/Fukuoka~
https://event.ospn.jp/osc2020-online-fukuoka/session/244772

--OSC2020 Online/Fukuoka 2020-11-28 B-5 - YouTube~
https://www.youtube.com/watch?v=38LUK4hl3so

**Partitioning関連 [#r1d02c3f]
-KafkaのCustom Partitionerを試す - abcdefg.....~
http://pppurple.hatenablog.com/entry/2018/11/02/234505
-Apache KafkaのConsumerを、特定のパーティションに手動で割り当てる - CLOVER🍀~
https://kazuhira-r.hatenablog.com/entry/20180413/1523631913

**[[Azure Event Hubs>https://techinfoofmicrosofttech.osscons.jp/index.php?Azure%20Event%20Hubs]] [#i8342b62]

トップ   編集 差分 バックアップ 添付 複製 名前変更 リロード   新規 一覧 単語検索 最終更新   ヘルプ   最終更新のRSS