Kafka 3.0 がリリースされました。新着情報？

Apache Kafka は、大手インターネット企業で広く使用されている分散型オープンソース ストリーミング プラットフォームです。

[[425527]]

Kafka はもともとメッセージ キュー用に設計されました。 2011 年に LinkedIn によってオープンソース化されて以来、Kafka はメッセージ キューから成熟したイベント ストリーム処理プラットフォームへと急速に進化しました。

Kafka には 4 つのコア API があり、これらを使用して、次の 2 つのカテゴリのアプリケーションで Kafka を使用できます。

• リアルタイム ストリーミング データ パイプラインを構築して、システム間またはアプリケーション間でデータを確実に転送および取得します。
• システム間またはアプリケーション間のデータ ストリームを変更したり、それに反応したりするためのリアルタイム ストリーミング アプリケーションを構築します。

最近、Apache Kafka 3.0.0 が正式にリリースされました。これは多くの新機能を含む重要なバージョン アップデートです。

例えば​​：

• Java 8 および Scala 2.12 のサポートは非​​推奨となり、開発者に調整する時間を与えるためにバージョン 4.0 では完全に削除されます。
• Kafka Raft は、メタデータ トピックのスナップショットと、自己管理クォーラムのその他の改善をサポートします。
• メッセージ形式 v0 および v1 は非推奨です。
• Kafka プロデューサーでは、より強力な配信保証がデフォルトで有効になっています。
• OffsetFetch および FindCoordinator リクエストが最適化されました。
• より柔軟な MirrorMaker 2 構成と MirrorMaker 1 の廃止。
• Kafka Connect への 1 回の呼び出しでコネクタ タスクを再起動する機能。
• コネクタ ログ コンテキストとコネクタ クライアントのオーバーライドがデフォルトで有効になりました。
• Kafka Streams でのタイムスタンプ同期のセマンティクスが強化されました。
• ストリームの TaskId のパブリック API を変更しました。
• Kafka Streams では、デフォルトの serde が null になり、その他の構成もいくつか変更されました。

次に、新しいバージョンでどこが更新されたかを見てみましょう。公式情報によると、Apache Kafka 3.0 ではさまざまな新機能、API の大幅な変更、KRaft の改善が導入され、Apache ZooKeeper™ が Apache Kafka の組み込みコンセンサス メカニズムに置き換えられます。

KRaft はまだ本番環境での使用には推奨されていませんが (既知のギャップ リスト)、KRaft メタデータと API には多くの改善が加えられています。正確に 1 回限りのサポートとパーティションの再割り当てのサポートは注目に値します。ぜひ KRaft の新機能をチェックして、開発環境で試してみてください。

Apache Kafka 3.0 以降では、プロデューサーはデフォルトで最も強力な配信保証を有効にします (acks=all、enable.idempotence=true)。つまり、ユーザーはデフォルトで順序付けと永続性を実現できるようになります。

また、Kafka Connect タスクの再起動の機能強化、KStreams タイムスタンプベースの同期の改善、MirrorMaker2 のより柔軟な構成オプションもお見逃しなく。

一般的な変更

①KIP-750（パート1）：KafkaでのJava 8サポートの廃止

3.0 では、Apache Kafka プロジェクトのすべてのコンポーネントで Java 8 のサポートが廃止されました。これにより、Java 8 のサポートが廃止される次のメジャー リリース (4.0) の前に、ユーザーに調整する時間が与えられます。

②KIP-751（パート1）：KafkaでのScala 2.12のサポートを廃止

Apache Kafka 3.0 では Scala 2.12 のサポートも非推奨になりました。 Java 8 と同様に、Scala 2.12 のサポートは次のメジャー リリース (4.0) で削除される予定であるため、ユーザーに適応する時間を与えています。

Kafka ブローカー、プロデューサー、コンシューマー、管理クライアント

①KIP-630: Kafka Raft スナップショット

3.0 で導入された主要な機能の 1 つは、KRaft コントローラーと KRaft ブローカーが __cluster_metadata という名前のメタデータ トピック パーティションのスナップショットを生成、複製、およびロードする機能です。

Kafka クラスターはこのトピックを使用して、ブローカー構成、トピック パーティションの割り当て、リーダーシップなどのクラスターに関するメタデータ情報を保存および複製します。

この状態が拡大するにつれて、Kafka Raft スナップショットはこの情報を効率的に保存、読み込み、複製する方法を提供します。

②KIP-746: KRaftメタデータレコードを変更する

Kafka Raft コントローラーの最初のバージョン以降の経験と継続的な開発により、Kafka が ZooKeeper (ZK) なしで実行するように構成されている場合に使用されるメタデータ レコード タイプの一部を変更する必要があることがわかりました。

③KIP-730: KRaftモードでのプロデューサーID生成

3.0 および KIP-730 では、Kafka コントローラーが Kafka プロデューサー ID の生成の責任を完全に引き継ぐようになりました。

コントローラーは、ZK モードと KRaft モードの両方でこれを実行します。これにより、ブリッジ リリースが近づき、ユーザーは ZK を使用した Kafka デプロイメントから KRaft を使用した新しいデプロイメントに移行できるようになります。

④KIP-679: プロデューサーはデフォルトで最も強力な配信保証を有効にする

3.0 以降、Kafka プロデューサーはデフォルトですべてのレプリカの冪等性と配信確認を有効にします。これにより、レコード配信の保証がデフォルトで強化されます。

⑤KIP-735: デフォルトのコンシューマーセッションタイムアウトを増やす

Kafka コンシューマー構成プロパティ session.timeout.ms のデフォルト値が 10 秒から 45 秒に増加されました。

これにより、消費者はデフォルトで一時的なネットワーク障害に適応しやすくなり、消費者が一時的にグループを離れたように見える場合に継続的な再バランス調整を回避できるようになります。

⑥KIP-709: OffsetFetchリクエストを拡張して複数のグループIDを受け入れる

Kafka コンシューマー グループの現在のオフセットを要求することは、長い間問題となっていました。ただし、複数のコンシューマー グループのオフセットを取得するには、グループごとに個別のリクエストが必要です。

3.0 および KIP-709 では、フェッチ API と AdminClient API が拡張され、単一のリクエスト/レスポンスで複数のコンシューマー グループのオフセットを同時に読み取ることができるようになりました。

⑦KIP-699: FindCoordinatorを更新して、一度に複数のコーディネーターを解決します

複数のコンシューマー グループに同時に効率的に適用できる操作をサポートするには、クライアントがそれらのグループのコーディネーターを効率的に検出できるかどうかが重要です。

これは、単一のリクエストで複数のグループのコーディネーターを検出するためのサポートを追加する KIP-699 によって可能になります。

Kafka クライアントは、このリクエストをサポートする新しい Kafka ブローカーと通信するときにこの最適化を使用するように更新されました。

⑧KIP-724: メッセージフォーマットv0およびv1のサポートを削除

メッセージ形式 v2 は、4 年前の 2017 年 6 月に Kafka 0.11.0 で導入されて以来、デフォルトのメッセージ形式となっています。

したがって、十分な水 (または小川) が流れた後、3.0 メジャー リリースは、古いメッセージ形式 (つまり、v0 および v1) を廃止する良い機会となります。

これらの形式は現在ではほとんど使用されていません。 3.0 では、ブローカーをメッセージ形式 v0 または v1 を使用するように構成すると、ユーザーに警告が表示されます。

このオプションは Kafka 4.0 で削除されます (詳細と v0 および v1 メッセージ形式の廃止による影響については、KIP-724 を参照してください)。

⑨KIP-707: Kafkaの未来

KafkaAdminClient の実装を容易にするために KafkaFuture 型が導入されたとき、Java 8 より前のバージョンがまだ広く使用されており、Kafka は Java 7 を公式にサポートしていました。

数年が経過し、Kafka は現在、CompletionStage および CompletableFuture クラス タイプをサポートする Java バージョンで実行されるようになりました。

KIP-707 では、KafkaFuture に CompletionStage オブジェクトを返すメソッドが追加され、下位互換性を保ちながら KafkaFuture の使いやすさが向上します。

⑩KIP-466: List<T> のシリアル化とデシリアル化のサポートを追加

KIP-466 は、汎用リストをシリアル化および逆シリアル化するための新しいクラスとメソッドを追加します。これは、Kafka クライアントと Kafka ストリームの両方に非常に便利な機能です。

⑪KIP-734: AdminClient.listOffsets を改良し、最大のタイムスタンプを持つレコードのタイムスタンプとオフセットを返すようにしました。

ユーザーが Kafka トピック/パーティション オフセットを一覧表示できる機能が拡張されました。 KIP-734 を使用すると、ユーザーは AdminClient に、トピック/パーティション内で最もタイムスタンプが高いレコードのオフセットとタイムスタンプを返すように要求できるようになりました。

これは、AdminClient が最新のオフセットとして既に返しているものと混同しないでください。最新のオフセットは、トピック/パーティションに書き込まれる次のレコードのオフセットです。

既存の ListOffsets API のこの拡張により、ユーザーは、最後に書き込まれたレコードのオフセットとそのタイムスタンプを尋ねることで、パーティションの有効性を調べることができます。

カフカコネクト

①KIP-745: コネクタとタスクを再起動するためのAPI接続

Kafka Connect では、コネクタは実行時にコネクタ クラス インスタンスのセットと 1 つ以上のタスク クラス インスタンスとして表され、Connect REST API を通じて利用できるコネクタに対するほとんどの操作はグループ全体に適用できます。

注目すべき例外の 1 つは、コネクタ インスタンスとタスク インスタンスのエンドポイントを最初から再起動することです。コネクタ全体を再起動するには、ユーザーはコネクタ インスタンスとタスク インスタンスを再起動するための個別の呼び出しを行う必要があります。

3.0 では、KIP-745 により、ユーザーは 1 回の呼び出しですべてのコネクタ インスタンスとタスク インスタンス、または失敗したコネクタ インスタンスとタスク インスタンスのみを再起動できます。この機能は追加されており、restartREST API の以前の動作は変更されません。

②KIP-738: Connectの内部コンバータプロパティを削除する

以前のメジャー バージョン (Apache Kafka 2.0) で非推奨になった後、internal.key.converter と internal.value.converter は、Connect ワーカーの構成の構成プロパティとプレフィックスとして削除されました。

今後、内部 Connect テーマでは、埋め込みスキーマなしでレコードを保存するために JsonConverter のみが使用されます。

別のコンバーターを使用した既存の Connect クラスターは、内部トピックを新しい形式に移植する必要があります (アップグレード パスの詳細については、KIP-738 を参照してください)。

③KIP-722: コネクタクライアントのオーバーライドをデフォルトで有効にする

Apache Kafka 2.3.0 以降では、コネクタ ワーカーを構成して、コネクタが使用する Kafka クライアント プロパティをコネクタ構成でオーバーライドできるようにすることができます。

これは広く使用されている機能であり、現在、コネクタ クライアント プロパティをデフォルトでオーバーライドする機能を有効にするメジャー バージョンをリリースする機会があります (デフォルトの connector.client.config.override.policy は All に設定されています)。

④KIP-721: 接続Log4j構成でコネクタログコンテキストを有効にする

2.3.0 で導入されましたが、今のところデフォルトでは有効になっていないもう 1 つの機能は、コネクタ ログ コンテキストです。これは 3.0 で変更され、コネクタ コンテキストはデフォルトで Connect ワーカーのログ パターンに log4j を追加します。

以前のバージョンの log4j から 3.0 にアップグレードすると、適切な場所にコネクタ コンテキストが追加され、エクスポートされたログ行の形式が変更されます。

カフカ ストリーム

①KIP-695: Kafka Streamsのタイムスタンプ同期をさらに改善

KIP-695 は、Streams タスクがレコードを取得する方法の選択方法のセマンティクスを強化し、構成プロパティ max.task.idle.ms の意味と使用可能な値を拡張します。

この変更には、Kafka コンシューマー API の新しいメソッド currentLag が必要です。このメソッドは、特定のパーティションのコンシューマー ラグがローカルでわかっている場合、Kafka ブローカーに接続せずにそれを返すことができます。

②KIP-715: ストリーム内のコミットされたオフセットを公開する

3.0 以降では、TaskMetadata インターフェイスに、committedOffsets、endOffsets、timeCurrentIdlingStarted という 3 つの新しいメソッドが追加されました。これらのメソッドにより、Streams アプリケーションはタスクの進行状況と状態を追跡できます。

③KIP-740: パブリックAPI TaskIdをクリーンアップする

KIP-740 は、TaskId クラスの大幅な改良を表しています。いくつかのメソッドとすべての内部フィールドは非推奨となり、新しい subtopology() および partition() ハンドラーが古い topicGroupId および partition フィールドを置き換えます (関連する変更については KIP-744、修正については KIP-740 を参照してください)。

④KIP-744: TaskMetadataとThreadMetadataを内部実装インターフェースに移行する

KIP-744 は、KIP-740 で提案された変更をさらに一歩進め、多くのクラスの実装をパブリック API から分離します。

これを実現するために、新しいインターフェース TaskMetadata、ThreadMetadata、StreamsMetadata が導入され、同じ名前の既存のクラスは非推奨になりました。

⑤KIP-666: ReadOnlySessionStoreにInstantベースのメソッドを追加する

インタラクティブ クエリ API は、Instant データ型のパラメータを受け入れる一連の新しいメソッドを使用して、ReadOnlySessionStore および SessionStore インターフェイスを拡張します。この変更は、新しいメソッドを実装する必要があるカスタムの読み取り専用インタラクティブ クエリ セッション ストアの実装に影響します。

KIP-622: ProcessorContext に currentSystemTimeMs と currentStreamTimeMs を追加する

ProcessorContext 3.0 では、currentSystemTimeMs と currentStreamTimeMs という 2 つの新しいメソッドが追加されました。

新しい方法により、ユーザーはキャッシュされたシステム時間とストリーム時間を個別に照会し、それらを本番コードとテスト コードで統一された方法で使用できるようになります。

⑦KIP-743: 0.10.0-2.4Streams組み込みインジケーターバージョン設定の設定値を削除

Streams の組み込みメトリックの古いメトリック構造のサポートは、3.0 で削除されました。 KIP-743 は、0.10.0-2.4 の構成プロパティbuilt.in.metrics.version から値を削除する作業を進めています。

現在、このプロパティの有効な値は latest のみです (2.5 以降はこれがデフォルトになっています)。

⑧KIP-741: デフォルトのSerDeをnullに変更する

DefaultSerDe プロパティの以前のデフォルト値を削除しました。ストリームはデフォルトで ByteArraySerde に設定されていました。

3.0 以降ではデフォルトがなくなり、ユーザーは必要に応じて API で SerDes を設定するか、ストリーム構成でデフォルトの DEFAULT_KEY_SERDE_CLASS_CONFIG と DEFAULT_VALUE_SERDE_CLASS_CONFIG を設定する必要があります。

以前のデフォルトは、実際のアプリケーションにはほとんどの場合不適切であり、利便性よりも混乱を引き起こしていました。

⑨KIP-733: Kafka Streamsのデフォルトのレプリケーション係数設定を変更する

メジャー リリースの機会に、Streams 構成プロパティ replication.factor のデフォルト値が 1 から -1 に変更されます。

これにより、新しい Streams アプリケーションは Kafka ブローカーで定義されたデフォルトのレプリケーション係数を使用できるようになり、本番環境に移行するときにこの構成値を設定する必要がなくなります。新しいデフォルトでは、Kafka Brokers 2.5 以上が必要であることに注意してください。

⑩KIP-732: eos-alpha を廃止し、eos-beta を eos-v2 に置き換える

3.0 で非推奨となったもう 1 つの Streams 構成値は、プロパティ processing.guarantee の値としての exact_once です。

値 exact_once は、Exactly Once Semantics (EOS) の元の実装に対応しており、Kafka クラスター バージョン 0.11.0 以降に接続されたすべての Streams アプリケーションで使用できます。

この EOS の最初の実装は、processing.guarantee プロパティの exact_once_beta の値で表される EOS の 2 番目の実装に置き換えられました。

今後、exactly_once_beta という名前も廃止され、新しい名前 exact_once_v2 に置き換えられます。

次のメジャー バージョン (4.0) では、exactly_once と exact_once_beta の両方が削除され、EOS 配信保証の唯一のオプションは exact_once_v2 のみになります。

⑪KIP-725: WindowedSerializerとWindowedDeserializerの設定を最適化する

構成プロパティ default.windowed.key.serde.inner および default.windowed.value.serde.inner は非推奨です。

代わりに、消費クライアントが使用するための単一の新しいプロパティ windowed.inner.class.serde があります。

Kafka Streams ユーザーは、ウィンドウ SerDe を SerDe コンストラクターに渡して構成し、トポロジ内で使用される場所に SerDe を提供することをお勧めします。

⑫KIP-633: Streams の猶予期間の 24 時間のデフォルト値を廃止

Kafka Streams では、猶予期間と呼ばれる構成プロパティに基づいて、ウィンドウ操作によってウィンドウ外のレコードを処理できます。

以前は、この構成はオプションであり、見落としがちだったため、デフォルトで 24 時間に設定されていました。これは、猶予期間が終了するまでレコードをバッファリングするため、24 時間の遅延が追加されるため、Suppression キャリア ユーザーにとって一般的な混乱の原因となります。

3.0 では、Windows クラスは、カスタムの猶予期間付き、または猶予期間なしで構築する必要があるファクトリ メソッドで強化されました。デフォルトの猶予期間が 24 時間であった古いファクトリ メソッドは非推奨になりました。また、この構成を設定する新しい grace() ファクトリ メソッドと互換性のない対応する API も非推奨になりました。

⑬ KIP-623: ストリームアプリケーションリセットツールに「internal-topics」オプションを追加

kafka-streams-application-reset に新しいコマンドラインパラメータ --internal-topics を追加することで、アプリケーションリセットツールによるストリームの使用がより柔軟になりました。

新しいパラメータは、このアプリケーション ツールを使用して削除をスケジュールできる内部トピックに対応するトピック名のコンマ区切りリストを受け入れます。

この新しいパラメータを既存のパラメータと組み合わせると、--dry-run により、ユーザーは実際に削除操作を実行する前に、削除されるトピックを確認し、必要に応じてトピックのサブセットを指定できます。

ミラーメーカー

①KIP-720: MirrorMaker v1 の廃止

3.0 では、MirrorMaker の最初のバージョンは非推奨になりました。今後、新機能の開発と大幅な改善は、MirrorMaker 2 (MM2) に重点的に取り組んでいきます。

②KIP-716: MirrorMaker2がオフセット同期トピックの場所を設定できるようにする

3.0 では、ユーザーは、コンシューマー グループ オフセットを変換するために MirrorMaker2 が作成して保存する内部トピックの場所を構成できるようになりました。

これにより、MirrorMaker2 のユーザーは、ソース Kafka クラスターを厳密に読み取り専用クラスターとして維持し、別の Kafka クラスター (つまり、ターゲット Kafka クラスター、またはソース クラスターとターゲット クラスター以外の 3 番目のクラスター) を使用してオフセット レコードを保存できるようになります。

Apache Kafka 3.0 は、Apache Kafka プロジェクトにとって大きな前進です。

詳細については、以下を参照してください。

https://blogs.apache.org/kafka