Cloud Native Kafka - 分散データ基盤がクラウドネイティブを目指すということ

Cloud Native Days Tokyo 2022 登壇資料

Apache Kafkaは12年前にLinkedIn内で開発され、その後オープンソース化された分散データ基盤です。当初はLinkedInを始めとした超大規模ユーザーの意向が色濃く反映された技術で、ベアメタルでの稼働が前提でした。しかしKafkaの成長と利用の広がりに伴い、Kafka自身がよりクラウドネイティブに近づく必要に迫られました。

本セッションでは、今も進化を続けるApahce Kafkaの構造的な仕組み、そしてこれまでどの様な進化を遂げて今に至るのかをインフラ的な観点からお話しします。中でもKafkaの構成上必要なZookeeperへの依存をどの様に断ち切ったのか、KIP-500と呼ばれる3年に渡る取り組みについて詳しくご紹介します。

Transcript

1. Cloud Native Days Tokyo 2022 Cloud Native Kafka - When a Data Platform Aims to Be Cloud Native Shinichi Hashitani, Solutions Engineer, Nov. 2022.
2. Enter Apache Kafka
3. @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
4. @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を繋ぐリアル タイムパイプライン • バッチ前提であるデータ の流れをリアルタイム化 • これまで必要であった中 間的なデータストアや 様々な処理ロジックをス トリーム処理化 • データは必要なストアに 必要な形態まで一次処理 をリアルタイムで実施し た後に連携。
5. @ShinHashitani | developer.confluent.io #3 Real Time Action Data Warehouse Analytics Stream Processing Databases 今起こったイベントに反応 ストリームがシンクに到達するま でにアクショナブルなリアルタイ ムイベントに変換 • 不正検知 • 数百件の捜査対象を数億件の イベントから抽出 • リアルタイムな状況アップ デート（Daily/Hourlyステー タス） Backend Service Alert Immediate Action Needed
6. @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
7. @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
8. @ShinHashitani | developer.confluent.io Event, Total Order, and Data Consistency “Streams and Tables in Apache Kafka: A Primer”, Michael Noll, Confluent Blog. チェスの一手一手とチェス盤の状態は 同じデータの異なる表現方法。 • チェス盤はある特定時点での完全な状 態 (State) を表現できる。 • チェスの一手一手を漏れなく、順序通 り適用すればチェス盤の状態を再現で きる。
9. @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
10. Communication with Kafka
11. @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.
12. @ShinHashitani | developer.confluent.io Kafka Producer and Broker Producer Client Partitioning is done at the client side. Batching and Compression are done per broker.
13. @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
14. Kafka Internals
15. @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
16. @ShinHashitani | developer.confluent.io Inside The Apache Kafka Broker Broker Broker Broker Broker Broker Broker
17. @ShinHashitani | developer.confluent.io Network Thread Adds Request to Queue
18. @ShinHashitani | developer.confluent.io IO Thread Verifies Record Batch And Stores
19. @ShinHashitani | developer.confluent.io Kafka Physical Storage /var/lib/kafka/data/account-deposits-1 00000000000047926734.log 00000000000047926734.index ... 00000000000052497535.log 00000000000052497535.index ...
20. @ShinHashitani | developer.confluent.io Purgatory Holds Requests Being Replicated
21. @ShinHashitani | developer.confluent.io Response Added to Socket Send Buffer
22. KIPs
23. KIP Kafka Improvement Proposal
24. 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
25. 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がメタデータ提供
26. 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を利用して迅速 にメタデータを復旧。
27. KIP-630 - Kafka Raft Snapshot 27 KIP-630: Kafka Raft Snapshot 0からのState復旧 Controllerはメタデータログから状態 (State) を更新 しメモリに保存、合わせて永続化している。この Metadata Stateを再現する為にはログが必要だが、 ログは絶えず増えState再現にかかる時間も比例的に 増大する。 Active Controllerはあるコミットされた状態で定期 てにMetadata Storeのスナップショットを取得。 新たに参加 (新規/復旧) する新しいControllerはス ナップショットを始点として必要なオフセットからメ タデータログを消化しStateを再現する。
28. Your Apache Kafka® journey begins here developer.confluent.io