Apache Kafka 最新アップデート 〜 What's New & What's Next 〜 Confluent Japan合同会社 清水 亮夫 (@shmza)

Apache Kafkaのリリースポリシー 2

Apache Kafkaのリリースポリシー ● Time Based Releaseポリシー ○ ４ヶ月ごとに新しいバージョンをリリースする ○ リリースまでのプロセス ○ Apache Kafka 3.5の場合 ■ KIP Freeze: 2023/03/22 ■ Feature Freeze: 2023/04/12 ■ Code Freeze: 2023/04/26 ■ Release: 2023/6/15 ● EOLポリシー: ○ 3つ前のバージョン ● バージョン番号の付け方 ○ Major.Minor.Bug-fix 3 KIP Freeze Feature Freeze Code Freeze Release https://cwiki.apache.org/confluence/display/KAFKA/Time+Based+Release+Plan#TimeBasedReleasePlan-WhatAboutVersionNumbers? https://cwiki.apache.org/confluence/display/KAFKA/Release+Plan+3.5.0

KIP (Kafka Improvement Proposal) ● KIPとは?: ○ Kafka Improvement Proposalの略称 ○ Kafkaの機能に大きな変更や追加を行う際はKIPベースで実施する ● 大きな変更("major change")とは?: ○ Any major new feature, subsystem, or piece of functionality ○ Any change that impacts the public interfaces of the project ● public interfaceの例 ○ Binary log format ○ The network protocol and api behavior ○ Any class for which the build generates Javadoc. This includes (but is not limited to; look for javadoc {} sections in build.gradle for the complete list): ■ org/apache/kafka/common/serialization ■ org/apache/kafka/common ■ org/apache/kafka/common/errors ■ org/apache/kafka/clients/producer ■ org/apache/kafka/clients/consumer (eventually, once stable) ○ Configuration, especially client configuration ○ Monitoring ○ Command line tools and arguments 4 https://cwiki.apache.org/confluence/display/KAFKA/Kafka+Improvement+Proposals

Apache Kafka 3.4 Update 5

Apache Kafka 3.4 ● リリース日: 2023年2月7日 ● リリースノート: https://archive.apache.org/dist/kafka/3.4.0/RELEASE_NOTES.html ● 含まれる主要なKIP ○ Kafka Core ■ KIP-792: Add "generation" field into consumer protocol ■ KIP-830: Allow disabling JMX Reporter ■ KIP-854: Separate configuration for producer ID expiry ■ KIP-866: ZooKeeper to KRaft cluster upgrade ■ KIP-876: Time based Cluster Metadata Snapshots ■ KIP-881: Rack-aware Partition Assignment for Kafka Consumers ○ Kafka Streams ■ KIP-770: Replace "buffered.records.per.partition" & "cache.max.bytes.buffering" with "{statestore.cache}/{input.buffer}.max.bytes" ■ KIP-837: Allow MultiCasting a Result Record ○ Kafka Connect ■ KIP-787: MM2 manage Kafka resources with custom Admin implementations 6

ZookeeperからKRaftへの移行 7

KIP-866 ZooKeeper to KRaft Migration Z K Z K Z K KRaftは、Zookeeperベースのメタ データ管理とは互換性がなかった。 本KIPにより、Zookeeperベースのク ラスタをKRaftベースにアップグレード することができる。また、クラスタのロー ルバックも可能 3.4ではEA(Early Access) 8

ZooKeeper、KIP-500、そしてKRaft? 9 KRaftとKIP-500の詳細についてはこちらのBLOG記事もご参照ください。 KRaft KRaftは、ZooKeeper に代わる新しいメタデータ とコンセンサスの仕組み です。KRaftは、Kafkaを より使いやすく、より効率 的にします。 KRaft = Kafka + Raft メ タデータ・コンセンサス ZooKeeper ZooKeeperは、Kafkaのクォーラムやメタデータ管理 など、分散システムの重要な課題を数多く解決してい ます。 一方でZooKeeperは、オペレータが2つのシステムと セキュリティモデルを管理する必要があるため、複雑 さが増してしまいます。 KIP-500 KIP-500は、 ZooKeeperをKafka 自体の一部であるメタ データ管理サービスに置 き換えるKafka Improvement Proposalです。

KRaftの利点 10 B 1. Kafkaの管理とデプロイの 簡素化 2. Kafkaクラスターを数百万の Partitionにスケールする 3. Kafkaの信頼性向上とフェイル オーバー性能の向上

KRaft移行のタイムライン (KIP-833) 3.4 3.3 Current 2022: KRaftは新クラスタでの み「production ready」とマーク 既存のZKクラスタを KRaftへ移行 (Early Access) ZKモードが 含まれる最終 バージョン 3.5 ZKモードが 「depreated」とマー ク 3.7 KRaftモードのみ サポート (ZKは削除される) 3.6 4.0 KRaftは新規と既存 のクラスタに対して GA. ZKからKRaftへ の移行もGA Bridge Release

KRaft Isolated Mode と Combined Mode KRaftコントローラーは、Kafka Brokerと同じプロセ スで動作します。 KRaft コントローラーは、Kafka Brokerとは 別に動作します。 共有のID、共有のJVM、共有のノード 異なるID、異なるJVM、異なるノード より隔離性が高く、より容易なロール KRaft Combined Mode KRaft Isolated Mode Brokers Quorum Controllers Brokers 現時点では本番環境での使用は非推奨

KRaftのアーキテクチャ 13

ZooKeeperとKraft 14 現行のZKベースの アーキテクチャ 新しいKRaftベースの アーキテクチャ

KafkaはZooKeeperをどのように利用しているか 15 最も永続的なメタデータを ZooKeeperに保存する ● Topic ● Partition ● Configuration ● Quota ● ACL また、クラスタのメンバーシッ プを調整するために ZooKeeperを使用する /brokers/ids/0 /brokers/ids/1 /brokers/topics/foo /brokers/topics/foo/partitions/0/state /brokers/topics/foo/partitions/1/state /brokers/topics/foo/partitions/2/state ...

ZK利用時のコントローラーの起動 16 ● UpdateMetadataRequest ● LeaderAndIsrRequest 全ての partition

ZKベースのコントローラ起動時の問題 17 ● 起動時にすべてのメタデータを同期して読み込む必要がある： ○ O(num_partitions), O(num_brokers) ○ この間、コントローラーは使用できない ■ Cold start: クラスターが使用できない ■ コントローラーの再起動: 管理系のオペレーションとISRの変更ができない ● 起動時にすべてのメタデータをすべてのブローカーに送信する必要がある 3 minutes

KRaft利用時のコントローラーの起動 18 ● 新しく選出されたKRaftコントロー ラーは即時に利用可能 ● ブローカーは必要なメタデータのみ を取得 ● 新規のBrokerや同期できていない Brokerはスナップショットからフェッ チする

KRaftはどのようにZooKeeperを置き換えるのか？ 19 ● ZooKeeperの代わりに、__cluster_metadataと いう内部トピックを持つ。 ○ KRaftにレプリケート ○ シングルpartition ○ リーダーはアクティブなコントローラー ● KRaft: Raft for Kafka ○ Kafkaに実装されたRaftプロトコル ■ レコードは過半数のノードによって コミットされる ○ 自己管理型のクォーラム ■ リーダー選出を外部システムに依 存しない

コントローラーのフェイルオーバー 20 ZKモード KRaftモード • コントローラーに選 出される • 全てのtopicと partitionを読込み • 全ブローカーに LeaderAndIsr + UpdateMetadata を送信 • KRaftに選出され る • Brokerからのリ クエストのハンド リングを開始

ノードのローリング 21 ZKモード KRaft Mode 再起動したノードは、メ タデータがない状態で 開始するため、コント ローラからの全メタ データ更新RPCを待つ 必要がある。 再起動したノードは ローカルのメタデータ キャッシュを参照し、メ タデータのオフセットに 基づき、保持していな いものだけを転送す る。

ZookeeperとKraftの性能比較 22 ZK Kraft 制御下でのシャット ダウン時間 (200万partition) 135秒 32秒 制御不能なシャット ダウンからの復旧時間 (200万partition) 503秒 37秒 BLOG記事「Apache Kafka Made Simple: A First Glimpse of a Kafka Without ZooKeeper」より https://www.confluent.io/blog/kafka-without-zookeeper-a-sneak-peek/

ZooKeeperモードからKraftモードへの移行 (3.4にてEA、3.5にてPreview、3.6にてGA予定) 23

クラスターのZKモードからのアップグレード 24 ZK mode ZK mode ZK mode ● 初期状態: 全てのメタデータは ZooKeeperに ● 全BrokerはZKモード

クラスターのZKモードからのアップグレード 25 25 ZK mode ZK mode ZK mode KRaft controller ● 新しいKRaftコントローラーの クォーラムをクラスターに追加 KRaft controller KRaft controller

クラスターのZKモードからのアップグレード 26 26 ZK mode ZK mode ZK mode ● KRaftコントローラは、ZKからす べてのメタデータをロードし、適切 なLeaderAndIsr、UMRを送出 ● 以降のメタデータの変更はKRaft のクォーラムに入る KRaft controller KRaft controller KRaft controller メタデータ

クラスターのZKモードからのアップグレード 27 27 ZK mode ZK mode KRaft mode ● Brokerは1台ずつローリング可能 ● KRaftコントローラーは、アップグ レードされていないブローカーに LeaderAndIsrなどを送信する KRaft controller KRaft controller KRaft controller

クラスターのZKモードからのアップグレード 28 28 KRaft mode KRaft mode KRaft mode ● 全てのBrokerが移行できたら、 ZKを削除可能 KRaft controller KRaft controller KRaft controller

その他の新機能 & 機能改善 29

KIP-830: Allow disabling JMX Reporter ● JMXレポーターは、使用されていない環境では無効にできるようになった。 ● 新しい設定パラメータ auto.include.jmx.reporter の導入 ○ 設定値がfalseの場合はmetric.reportersに設定されたレポーターが 使用される ● Kafka 4.0では、metric.reportersのデフォルト値が、現在の""か ら"org.apache.kafka.common.metrics.JmxReporter"に設定さ れる 30

KIP-881: Rack-aware Partition Assignment for Kafka Consumers AZ1 AZ2 AZ3 Topic Partition 1 Partition 2 Partition 3 KIP-36 Rack aware replica assignment KIP-392: Allow consumers to fetch from closest replica KIP-881: Rack-aware Partition Assignment for Kafka Consumers RackId: AZ1 Backward compatibility change for KIP-848: The Next Generation of the Consumer Rebalance Protocol 31

KIP-876: Time based cluster metadata snapshots クラスタメタデータは、コンパクト化されたトピックに基 づいて構築されていたため、新しいコントローラが参 加するのに時間がかかっていた。 KIP-630 によってステートのスナップショットを取得可 能となった。これにより、新規コントローラの参加をより 高速化することができた。 スナップショットの取得はバイトサイズに基づいていた が、KIP-876によって一定時間間隔での取得が可能 になった。 新規設定パラメータ: metadata. log.max. snapshot. interval ms (デフォルトでは1時間) metadata.max. retention.bytes のデフォルト 値を -1 (無効化) から 100MB へ変更 32

What's Next? 33

Apache Kafka 3.5 の新機能 & 機能改善 34

Apache Kafka 3.5 ● リリース時期: 2023年6月15日 ● リリースノート: https://archive.apache.org/dist/kafka/3.5.0/RELEASE_NOTES.html ● 含まれる主要なKIP ○ Kafka Core ■ KIP-881: Rack-aware Partition Assignment for Kafka Consumers ■ KIP-887: Add ConfigProvider to make use of environment variables ■ KIP-900: KRaft kafka-storage.sh API additions to support SCRAM for Kafka Brokers ■ KIP-903: Replicas with stale broker epoch should not be allowed to join the ISR ○ Kafka Streams ■ KIP-399: Extend ProductionExceptionHandler to cover serialization exceptions ■ KIP-889: Versioned State Stores ■ KIP-907: Add Boolean Serde to public interface ○ Kafka Connect ■ KIP-710: Full support for distributed mode in dedicated MirrorMaker 2.0 clusters ■ KIP-875: First-class offsets support in Kafka Connect ■ KIP-894: Use incrementalAlterConfig for syncing topic configurations ■ KAFKA-14021: MirrorMaker 2 should implement KIP-618 APIs 35

Apache Kafka 3.5 36 BLOG記事 YouTubeビデオ https://www.confluent.io/blog/introducing-apache-kafka-3-5 https://youtu.be/BVxDFL5iTx8

Apache Kafkaのロードマップ 37

Kafka Summit London 2023 Keynoteより 38 Beyond Speed: Kafka Summit London 2023 Keynote | Jay Kreps, Co-founder & CEO, Confluent https://youtu.be/0iKZRFuIleU

No content

No content

No content

No content

No content

No content

ご静聴ありがとうございました！ 45