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

[[425527]]

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

Kafka には 4 つのコア API があり、これらにより、Kafka を主に 2 種類のアプリケーションで使用できるようになります。

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

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 のタイムスタンプ同期のセマンティクスが強化されました。
• Stream の TaskId のパブリック API が変更されました。
• Kafka Streams では、他の構成の変更とともに、デフォルトの serde が null になりました。

次に、新バージョンの具体的なアップデート内容を見ていきましょう。公式情報によると、Apache Kafka 3.0では、様々な新機能、画期的なAPI変更、そしてKRaftの改善が導入されています。Apache Kafkaの組み込みコンセンサスメカニズムは、Apache ZooKeeper™に代わるものです。

KRaftはまだ本番環境での使用は推奨されていませんが（既知のギャップのリストを参照）、KRaftのメタデータとAPIには多くの改善が加えられています。特に、Exactly-Onceとパーティションの再割り当てのサポートは特筆に値します。ぜひ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 のサポートが廃止されました。これにより、次のメジャー リリース (4.0) で Java 8 のサポートが削除されるまで、ユーザーに調整する時間が与えられます。

②KIP-751 (パート1): Kafka における Scala 2.12 のサポートを廃止

Apache Kafka 3.0では、Scala 2.12のサポートも廃止されました。Java 8と同様に、次期メジャーリリース（4.0）ではScala 2.12のサポートが削除される予定であるため、ユーザーには調整のための時間を設けています。

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

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

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

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

この状態が拡大するにつれて、Kafka Raft Snapshot はこの情報を効率的に保存、ロード、複製する方法を提供します。

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

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

③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 を更新して、複数の Coordinator を一度に解決できるようにしました。

複数のコンシューマー グループに同時に操作を効果的に適用できるかどうかは、クライアントがこれらのグループのコーディネーターを効果的に検出できるかどうかに大きく依存します。

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

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

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

2017 年 6 月に Kafka 0.11.0 とともにリリースされて以来、メッセージ フォーマット v2 は 4 年間にわたってデフォルトのメッセージ フォーマットとなっています。

したがって、十分な水（または小川）が橋の下を流れた後、メジャー バージョン 3.0 は、古いメッセージ形式（つまり、v0 および v1）を放棄する良い機会となります。

これらの形式は現在ではほとんど使用されていません。バージョン3.0では、エージェントをメッセージ形式v0またはv1を使用するように設定した場合、ユーザーに警告が表示されます。

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

⑨KIP-707: Kafkaの未来

KafkaFuture が Kafka AdminClient の実装を容易にするためにこの型を導入したとき、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 では、コネクタは実行時に Connector クラス インスタンスのセットと 1 つ以上の Task クラス インスタンスとして表され、Connect REST API を通じて使用できるコネクタに対するほとんどの操作をセット全体に適用できます。

そもそも、`restart` の注目すべき例外は、コネクタインスタンスとタスクインスタンスの両方のエンドポイントです。コネクタ全体を再起動するには、ユーザーはコネクタインスタンスとタスクインスタンスの両方を個別に再起動する必要があります。

バージョン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で導入されたものの、まだデフォルトで有効化されていないもう一つの機能は、コネクタのログコンテキストです。これは3.0で変更され、コネクタコンテキストはデフォルトでConnectワーカーのログモードにlog4jを追加するようになりました。

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

Kafka ストリーム

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

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

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

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

バージョン3.0以降、TaskMetadataインターフェースに3つの新しいメソッド（committedOffsets、endOffsets、timeCurrentIdlingStarted）が追加されました。これらのメソッドにより、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は、ReadOnlySessionStoreおよびSessionStoreインターフェースを拡張し、Instantデータ型のパラメータを受け入れる新しいメソッドセットを追加しました。この変更は、新しいメソッドの実装を必要とするカスタムの読み取り専用インタラクティブクエリセッションストア実装に影響します。

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

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

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

⑦KIP-743: Streams 0.10.0-2.4 の組み込みメトリックバージョン構成の設定値を削除します。

Streams の組み込みメトリックの古いメトリック構造のサポートは、バージョン 3.0 で削除されました。KIP-743 により、バージョン 0.10.0-2.4 の構成プロパティから値 `built.in.metrics.version` が削除されます。

この最新の値は、現在このプロパティの唯一の有効な値です (バージョン 2.5 以降はデフォルト値になっています)。

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

デフォルトのSerDeプロパティの以前のデフォルト値は削除されました。ストリームのデフォルト値は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 Brokersで定義されたデフォルトのレプリケーション係数を使用できるようになるため、本番環境への移行時にこの設定値を設定する必要はありません。新しいデフォルト値を使用するには、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 の最初の実装は、ストリームを介して EOS の 2 番目の実装によって実装されており、これは processing.guarantee プロパティの exactly_once_beta を置き換える値によって表されます。

今後、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 という 1 つの新しいプロパティが提供されます。

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

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

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

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

バージョン 3.0 では、Windows クラスにファクトリーメソッドが追加されました。これらのファクトリーメソッドでは、クラスの作成時にカスタムの猶予期間、または猶予期間なしのどちらかを選択することが必須となります。デフォルトの猶予期間が 24 時間である古いファクトリーメソッドは非推奨となりました。また、`grace()` によってこの設定が設定される新しいファクトリーメソッドと互換性のない、対応する API も非推奨となりました。

⑬KIP-623: 内部トピックでは、ストリーミング アプリケーションのリセット ツールに「 」オプションが追加されました。

新しいコマンドライン引数 `--internal-topics` を追加することで、アプリケーション リセット ツールの Streams の使用がより柔軟になります。

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

この新しいパラメータを既存のパラメータと組み合わせる --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