Slide 1

Slide 1 text

Cloud Native Days Tokyo 2022 Cloud Native Kafka - When a Data Platform Aims to Be Cloud Native Shinichi Hashitani, Solutions Engineer, Nov. 2022.

Slide 2

Slide 2 text

Enter Apache Kafka

Slide 3

Slide 3 text

@ShinHashitani | developer.confluent.io #1 Durable Event Driven Architecture Kafkaによる高耐性イベント駆動 一般的なメッセージブローカーと異な り、Kafkaを利用したイベント駆動では 本格的な運用では大きなメリットがあ る。 • 極めて高いスケーラビリティ • バックプレッシャーが不要 • イベントの長期保全 • Order Guarantee • Exactly Once Semantics • Fan-out • ストレージ/OLAPドメインとの接続 Service 2 Service 5 Service 6 Service 1 Service 4 Service 3

Slide 4

Slide 4 text

@ShinHashitani | developer.confluent.io #2 Streaming ETL Databases RDBMS/NoSQL Files CSV/JSON/XML… Application Events Webhook SaaS Applications REST APIs Data Warehouse Analytics Continuous Data Processing Stream Processing Databases OLTPとOLAPを繋ぐリアル タイムパイプライン ● バッチ前提であるデータ の流れをリアルタイム化 ● これまで必要であった中 間的なデータストアや 様々な処理ロジックをス トリーム処理化 ● データは必要なストアに 必要な形態まで一次処理 をリアルタイムで実施し た後に連携。

Slide 5

Slide 5 text

@ShinHashitani | developer.confluent.io #3 Real Time Action Data Warehouse Analytics Stream Processing Databases 今起こったイベントに反応 ストリームがシンクに到達するま でにアクショナブルなリアルタイ ムイベントに変換 ● 不正検知 ● 数百件の捜査対象を数億件の イベントから抽出 ● リアルタイムな状況アップ デート(Daily/Hourlyステー タス) Backend Service Alert Immediate Action Needed

Slide 6

Slide 6 text

@ShinHashitani | developer.confluent.io Stream = A Series of Continuous Events customer login: abc order confirmed: #001 order updated: #002 customer login: efg order canceled: #003 package received: #a01 at dist center: #b02 left dist center: #a02 delivered: #a01 customer C: 0001 order U: 0003 payment U: 0002 payment C: 0003 customer U: 0002 store-order order confirmed: #001 order updated: #002 order canceled: #003 store-customer customer login: abc customer login: efg logistic package received: #a01 left dist center: #a02 delivered: #a01 at dist center: #b02 orderdb-c customer C: 0001 customer U: 0002 orderdb-o order U: 0003 orderdb-p payment C: 0003 payment U: 0002

Slide 7

Slide 7 text

@ShinHashitani | developer.confluent.io Why Kafka? - Kafka Keeps Data Consistent 7 イベントはトランザクションログとして保存 イベントはログとして永続化され、同じイベン トを何度でも読み込み処理する事が可能。Pullモ デルでもある為、イベントを漏れなく順序通り 高速に連携出来る仕組みとなっている。 customer login order confirmed order updated customer logout order canceled Append-Only Immutable 1 2 3 4 5 6 8 7 10 9 11 12 1 2 3 4 5 6 8 7 Old New

Slide 8

Slide 8 text

@ShinHashitani | developer.confluent.io Event, Total Order, and Data Consistency “Streams and Tables in Apache Kafka: A Primer”, Michael Noll, Confluent Blog. チェスの一手一手とチェス盤の状態は 同じデータの異なる表現方法。 • チェス盤はある特定時点での完全な状 態 (State) を表現できる。 • チェスの一手一手を漏れなく、順序通 り適用すればチェス盤の状態を再現で きる。

Slide 9

Slide 9 text

@ShinHashitani | developer.confluent.io Kafka is a Durable Storage Broker 1 Broker 2 Broker 3 Broker 4 Topic1 partition1 Topic1 partition2 Topic1 partition3 Topic1 partition4 Topic1 partition1 Topic1 partition1 Topic1 partition2 Topic1 partition2 Topic1 partition3 Topic1 partition3 Topic1 partition4 Topic1 partition4 Concurrent Access Data Replication

Slide 10

Slide 10 text

Communication with Kafka

Slide 11

Slide 11 text

@ShinHashitani | developer.confluent.io Communications Are All Direct Transaction partition1 Transaction partition2 Transaction partition3 Transaction partition4 Application partition1 Application partition2 Application partition3 Payment partition1 Payment partition2 The app knows to whom it should send events to.

Slide 12

Slide 12 text

@ShinHashitani | developer.confluent.io Kafka Producer and Broker Producer Client Partitioning is done at the client side. Batching and Compression are done per broker.

Slide 13

Slide 13 text

@ShinHashitani | developer.confluent.io Producer Internal Process Serializer ● スキーマの確認。 ● Schema Registryを利用 する場合はキャッシュ を確認。キャッシュに 無い場合にはSchema Registryからフェッ チ。 ● スキーマ定義に合わせ てシリアライズ。 Partitioner ● Javaクライアントの場 合はmurmur2を利用し てキーのハッシュ化。 ● Partitionerが指定され ている場合はそのルー ルに基づきPartitionを 決定。 ● キーがない場合はラウ ンドロビンでPartition を決定。 Sender thread ● バッチをターゲット Broker毎にグループ 化。 ● データを1リクエスト として転送。 Record accumulator ● Partition毎にバッファリン グ。 Compression ● Broker単位に圧縮。 ● Brokerへのデータ転送量を 最適化。 ● Broker間のレプリケーショ ン負荷も最適化。 record batch request

Slide 14

Slide 14 text

Kafka Internals

Slide 15

Slide 15 text

@ShinHashitani | developer.confluent.io Control Plane and Data Plane Kafka Cluster Broker Broker Data Plane Broker Broker Controller Broker Broker Zookeeper Zookeeper Zookeeper Control Plane ● Cluster Membership ● Broker and Controller ● Topic Partition and Partition Leader ● Access Control List

Slide 16

Slide 16 text

@ShinHashitani | developer.confluent.io Inside The Apache Kafka Broker Broker Broker Broker Broker Broker Broker

Slide 17

Slide 17 text

@ShinHashitani | developer.confluent.io Network Thread Adds Request to Queue

Slide 18

Slide 18 text

@ShinHashitani | developer.confluent.io IO Thread Verifies Record Batch And Stores

Slide 19

Slide 19 text

@ShinHashitani | developer.confluent.io Kafka Physical Storage /var/lib/kafka/data/account-deposits-1 00000000000047926734.log 00000000000047926734.index ... 00000000000052497535.log 00000000000052497535.index ...

Slide 20

Slide 20 text

@ShinHashitani | developer.confluent.io Purgatory Holds Requests Being Replicated

Slide 21

Slide 21 text

@ShinHashitani | developer.confluent.io Response Added to Socket Send Buffer

Slide 22

Slide 22 text

KIPs

Slide 23

Slide 23 text

KIP Kafka Improvement Proposal

Slide 24

Slide 24 text

Segment 1 Segment 2 KIP-405 - Kafka Tiered Storage 24 KIP-405: Kafka Tiered Storage Segment 1 Segment 2 Segment 3 Active Segment Segment 1 Segment 2 ● ComputeとStorageの密結合 ● 高速 - Disk I/O ● ログ保全コスト大 ● 障害時 - 大量データのリバランス ● ComputeとStorageの分離 ● 低速 - Network I/O ● ログ保全コスト小 ● 障害時 - 限定的なデータのリバランス Read Write Read Offset = earliest

Slide 25

Slide 25 text

KIP-500 - Replace Zookeeper with a Self-Managed Metadata Quorum 25 KIP-500: Replace Zookeeper with a Self-Managed Metadata Quorum ● 別途Zookeeperクラスタ必要 ● Zookeeperで合意形成 ● Controllerがメタデータ提供 ZK ZK ZK ● 別途Zookeeperクラスタ不要 ● Controllerx3+で合意形成 ● Controllerがメタデータ提供

Slide 26

Slide 26 text

KIP-595 - A Raft Protocol for Metadata Quorum 26 ● メタデータ合意 (Leader/Follower) ● Leader Election KIP-595: A Raft Protocol for Metadata Quorum メタデータの永続化ストアからログベースへ 元々Kafkaはユーザーデータ/メタデータのそれぞれ をログベースで行っており、Raftモデルとの親和性は 高い。メタデータは内部Topic __cluster_metadata にて管理。スナップショットとTopicを利用して迅速 にメタデータを復旧。

Slide 27

Slide 27 text

KIP-630 - Kafka Raft Snapshot 27 KIP-630: Kafka Raft Snapshot 0からのState復旧 Controllerはメタデータログから状態 (State) を更新 しメモリに保存、合わせて永続化している。この Metadata Stateを再現する為にはログが必要だが、 ログは絶えず増えState再現にかかる時間も比例的に 増大する。 Active Controllerはあるコミットされた状態で定期 てにMetadata Storeのスナップショットを取得。 新たに参加 (新規/復旧) する新しいControllerはス ナップショットを始点として必要なオフセットからメ タデータログを消化しStateを再現する。

Slide 28

Slide 28 text

Your Apache Kafka® journey begins here developer.confluent.io