Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Apache Kafka最新アップデート (2023年6月16日版)

Apache Kafka最新アップデート (2023年6月16日版)

Apache Kafka Meetup Japan #13の発表資料です。
2023年6月16日(JST)時点での、Apache Kafkaのアップデートやロードマップを紹介しています。

Akio SHIMIZU

June 20, 2023
Tweet

More Decks by Akio SHIMIZU

Other Decks in Technology

Transcript

  1. Apache Kafka 最新アップデート 〜 What's New & What's Next 〜

    Confluent Japan合同会社 清水 亮夫 (@shmza)
  2. Apache Kafkaのリリースポリシー • Time Based Releaseポリシー ◦ 4ヶ月ごとに新しいバージョンをリリースする ◦ リリースまでのプロセス

    ◦ 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
  3. 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
  4. 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
  5. KIP-866 ZooKeeper to KRaft Migration Z K Z K Z

    K KRaftは、Zookeeperベースのメタ データ管理とは互換性がなかった。 本KIPにより、Zookeeperベースのク ラスタをKRaftベースにアップグレード することができる。また、クラスタのロー ルバックも可能 3.4ではEA(Early Access) 8
  6. 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です。
  7. 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
  8. 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 現時点では本番環境での使用は非推奨
  9. 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 ...
  10. ZKベースのコントローラ起動時の問題 17 • 起動時にすべてのメタデータを同期して読み込む必要がある: ◦ O(num_partitions), O(num_brokers) ◦ この間、コントローラーは使用できない ▪

    Cold start: クラスターが使用できない ▪ コントローラーの再起動: 管理系のオペレーションとISRの変更ができない • 起動時にすべてのメタデータをすべてのブローカーに送信する必要がある 3 minutes
  11. KRaftはどのようにZooKeeperを置き換えるのか? 19 • ZooKeeperの代わりに、__cluster_metadataと いう内部トピックを持つ。 ◦ KRaftにレプリケート ◦ シングルpartition ◦

    リーダーはアクティブなコントローラー • KRaft: Raft for Kafka ◦ Kafkaに実装されたRaftプロトコル ▪ レコードは過半数のノードによって コミットされる ◦ 自己管理型のクォーラム ▪ リーダー選出を外部システムに依 存しない
  12. コントローラーのフェイルオーバー 20 ZKモード KRaftモード • コントローラーに選 出される • 全てのtopicと partitionを読込み

    • 全ブローカーに LeaderAndIsr + UpdateMetadata を送信 • KRaftに選出され る • Brokerからのリ クエストのハンド リングを開始
  13. ノードのローリング 21 ZKモード KRaft Mode 再起動したノードは、メ タデータがない状態で 開始するため、コント ローラからの全メタ データ更新RPCを待つ

    必要がある。 再起動したノードは ローカルのメタデータ キャッシュを参照し、メ タデータのオフセットに 基づき、保持していな いものだけを転送す る。
  14. 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/
  15. クラスターのZKモードからのアップグレード 24 ZK mode ZK mode ZK mode • 初期状態:

    全てのメタデータは ZooKeeperに • 全BrokerはZKモード
  16. クラスターのZKモードからのアップグレード 25 25 ZK mode ZK mode ZK mode KRaft

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

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

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

    全てのBrokerが移行できたら、 ZKを削除可能 KRaft controller KRaft controller KRaft controller
  20. 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
  21. 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
  22. 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
  23. 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
  24. Kafka Summit London 2023 Keynoteより 38 Beyond Speed: Kafka Summit

    London 2023 Keynote | Jay Kreps, Co-founder & CEO, Confluent https://youtu.be/0iKZRFuIleU