Confluent Platform 6.0.0 リリースノート¶
6.0.0 は Confluent Platform のメジャーリリースであり、Kafka の最新の安定版 Apache Kafka® 2.6.0 が組み込まれています。
このリリースの技術的な詳細について、以降で説明します。
6.0.0 リリースの詳細については、リリースに関するブログ および Streaming Audio のポッドキャスト をご確認ください。
商用版の機能¶
Confluent Control Center¶
- Self-Balancing の UI
- ワークロードをバランシングし、クラスターを動的に拡張および縮小するための機能が導入されました。Control Center から、ブローカーを削除し、Self-Balancing を制御し、バランシングの進捗を追跡できます。注: Confluent for Kubernetes を使用して Confluent Platform を管理している場合は、CFK を使用して Self-Balancing も管理する必要があります。Self-Balancing の UI は CFK ベースの環境では表示されません。詳細については、「Self-Balancing チュートリアル」を参照してください。
- Tiered Storage の UI
- ブローカーを追加(計算)せずに、ストレージを柔軟に追加およびスケーリングできます。このために、安価なオブジェクトストレージをデータ保持のための効率的な手段として使用できます。
- ユーザーインターフェイスの自動更新がデフォルトで有効に
- Control Center の UI がリアルタイムで更新され、最新の UI バグ修正および改良が反映されます。詳細については、「Control Center バージョンの確認と自動アップデートの有効化」を参照してください。
Kafka ブローカー¶
Confluent Server¶
- Tiered Storage
- Tiered Storage が一般提供可能になり、本稼働環境で使用できるようになりました。Tiered Storage により Confluent Platform の柔軟性が高まる一方、プラットフォームのオペレーターはコスト効率の高い方法でトピックごとに保持期間を増やすことができます。詳細については、「階層型ストレージ」を参照してください。
- Tiered Storage が GCP の Google Cloud Storage(GCS)をサポート
- Tiered Storage で、AWS S3 に加え、Google Cloud Storage に直接データを階層化できるようになりました。
- Tiered Storage が AWS の認証情報ファイルをサポート
- Tiered Storage のユーザーが AWS の認証情報ファイルを使用して AWS S3 の認証を受けることができるようになりました。
- Self-Balancing Clusters
- Confluent Server は自己バランシング型ではありません。Confluent Server クラスターで Self-Balancing を有効にすることで、ブローカーが追加されたときやクラスターがスキューを検出したときにパーティションが自動的にバランス調整します。これによってクラスターが柔軟性を高め、効率的に実行されるようになります。詳細については、「Self-Balancing チュートリアル」を参照してください。
- 組み込みの Rest 管理用 API
- Confluent Server に RESTful 管理用 API が組み込まれ、基本的な Kafka 操作を簡単に実行できるようになりました。詳細については、「Confluent REST Proxy API リファレンス」を参照してください。
- Cluster Linking(プレビュー)
- Confluent Platform のユーザーが直接、2 つの Kafka クラスターをまとめて、ミラートピック、コンシューマーオフセット、ACL に接続できるようになりました。Connect、Replicator、MirrorMaker 2.0 は不要です。この機能は現在プレビュー状態にあり、API が安定していないため本稼働環境での使用については保証されていません。詳細については、「Cluster Linking」を参照してください。
- Confluent Server がデフォルトのブローカーに
- Confluent Platform 6.0.0 から、Confluent Server が RPM、deb、Confluent Platform ダウンロードのデフォルトブローカーとなりました。Kafka ブローカーを使用する場合は、Confluent Community パッケージをダウンロードしてください。詳細については、「Confluent Server への移行」を参照してください。Confluent Server を使用する場合は必ず、
confluent.license
プロパティを使用してserver.properties
ファイルに Confluent ライセンスキーを追加してください。
Confluent Community / Apache Kafka¶
Confluent Platform 6.0 features Apache Kafka® 2.6. For a full list of the 15 KIPs, features, and bug fixes, take a look at the official Apache Kafka release notes, the release overview podcast, and the release blog post. Or watch Confluent’s very own Tim Berglund give an overview of Apache Kafka 2.6.
Security¶
- CLI による監査ログの構成
- セットアップを簡略化するために、CLI および API 構成のサポートが追加されました。これらの新機能により、監査ログの構成を動的にアップデートできます。Confluent CLI で加えた変更は、Metadata Service (MDS) から登録されているクラスターすべてにプッシュされます。これにより、監査ログの構成を一元的に管理し、登録されているクラスターすべてが監査ログのイベントを確実に同じ送信先 Kafka クラスターにパブリッシュするようにできます。監査ログの UI は近日提供する予定です。詳細については、「CLI による監査ログの構成」を参照してください。
- クラスターレジストリ
- Kafka クラスターの管理者に、Kafka クラスターを Metadata Service (MDS) に一元的に登録する機能を提供します。これにより、RBAC の ロールバインディングを実行しやすくなり、監査ログの記録を一元化できます。また、クラスター情報の取得も容易になり、覚えづらいクラスター ID ではなく簡略化された Kafka クラスター名を使用できるようになります。詳細については、「クラスターレジストリ」を参照してください。
- RBAC
- クラスターレジストリを利用することで、クラスター情報を容易に取得し、覚えづらいクラスター ID ではなく簡略化された Kafka クラスター名を使用できるようになるため、 ロールバインディングの表示および管理のプロセスが簡単になります。詳細については、「Confluent Platform Metadata Service」を参照してください。
- TLS
- TLS 1.0 および 1.1 は Kafka では無効になっています。ただし、TLS 1.3 のサポートが追加されました。この機能は将来的に Confluent Platform 全体に拡張される予定です。
既知の問題¶
クラスターレジストリおよび使いやすい名前は Control Center には統合されていません。この統合には近日対応する予定です。
クライアント¶
1.5.0 リリースでは、ユーザビリティの改良、機能強化、librdkafka の修正を行っています。詳細については、librdkafka 1.5 のリリースノート を参照してください。
Admin REST APIs¶
- Java AdminClient 操作の大半を HTTP を介して実行できるようになりました。新しい REST API により、ブローカー、トピック、ACL、コンシューマーグループ、トピックおよびブローカーの構成を管理できます。
- Admin REST APIs は、新しい v3 名前空間において、既存の REST Proxy デプロイで利用できます。今回初めて、外部の依存関係を一切含まずに、直接 Confluent Server でも利用できるようになりました。
詳細については、「Confluent REST API」を参照してください。
Connect¶
- 一元化されたコネクター向けエンタープライズライセンス
- Previously, connectors that require an Enterprise License needed to have a license topic configuration at each connector level. However, this enhancement enables you to configure a license topic at Connect worker level, so you don’t have to add a license topic configuration at the connector level. For more information, see Licensing Connectors.
- KIP-158: Kafka Connect はソースコネクターに新しいトピックのトピック固有の設定を許可する必要がある
- Enhances usability of source connectors by enabling developers and operators to set topic-specific settings for new topics easily. Kafka Connect will optionally create any topics used by source connectors using topic setting rules declared in the source connector's configuration. For more information, see Configuring Auto Topic Creation for Source Connectors and the configuration properties documentation for individual source connectors.
- KIP-585: フィルターおよび条件付き SMT
- SMT を条件付きで適用できます。以前の SMT はコネクター構成の一部として構成され、コネクターの読み取り元、または書き出し先のトピックのすべてのレコードに適用されていました。この制限は、特定の状況で SMT を使用する場合に問題となっていました。詳細については、「ak-filter」を参照してください。
- KIP-610: シンクコネクターのエラーレポート
- シンクコネクター向けにエラーレポート機能を拡張します。以前の Kafka Connect のエラー処理には、再試行、ログ記録、送達不能キューへの不正レコードの送信などの機能が含まれていました。しかし、KIP-298 の送達不能キュー機能がサポートするエラーレポートの対象は、変換操作およびキー、値、ヘッダーコンバーター操作のコンテキスト内に限られます。処理のためにレコードがコネクターに送信された後は、送達不能キューまたはエラーレポート機能は一切サポートされません。KIP-610 では、シンクコネクターが各レコードについて問題があることを報告でき、それらのレコードが DLQ に送信されます。詳細については、「デッドレターキュー」を参照してください。
コネクター¶
- Beginning with Confluent Platform 6.0, connectors are no longer packaged natively with Confluent Platform. All formerly packaged connectors must be downloaded directly from Confluent Hub. To clearly delineate this change in distribution, we have bumped versions to 10.0.0. For more information, see Supported Connectors.
- SSL 向けの Kafka クライアント API が Kafka 2.6 で変更されました。SSL 構成の Confluent Platform 6.0.x を使用している場合は、これらのコネクターに以下のバージョン制限が適用されます。
- Elasticsearch シンクのバージョン 10 以降
- RabbitMQ Source および Sink のバージョン 1.3.1
- Avro コンバーターまたは Schema Registry をバンドルし、依存関係のバージョン 5.4.0、5.4.1、または 5.4.2 を使用しているコネクターは Confluent Platform 6.0 では動作しません。これらの依存関係は、5.4.3、5.5.2、6.0.0 などの新しいバージョンにアップデートする必要があります。
クラスター管理¶
Confluent for Kubernetes¶
新機能
- 内部通信用 TLS 暗号化
- ブローカー間通信およびコンポーネント間通信をセキュアにするために、TLS 証明書およびキーを提供できるようになりました。つまり、プラットフォーム内のすべての通信をセキュアに暗号化できます。プラットフォームの外部クライアントからのすべての通信を TLS 暗号化で構成する既存の機能に加えて登場した新機能です。
- LoadBalancer を利用できない環境
- NodePort サービスや Ingress コントローラーなど、Operator がデプロイした Confluent Platform コンポーネントへの外部アクセスを有効にするためのオプションが追加されました。この目的は、自分の環境で Kubernetes の LoadBalancer サービスタイプ(ロードバランサーの動的な管理を実現するサービス)を使用できないユーザーをサポートすることです。
- 1 コマンドの並行ディスクスケールアップ
- Helm 構成ファイルの構成を 1 つ変更し、
helm upgrade
コマンドを 1 つ実行することで、Kafka クラスター全体のすべてのブローカーにディスクを拡張できます。所要時間は数秒です。また、これは Kafka 以外のクラスターにも有効です。
- 1 コマンドの並行クラスタースケールアウト
- Helm 構成ファイル(
$VALUES_FILE
)の構成を 1 つ変更し、helm upgrade
コマンドを 1 つ実行することで、すべての Confluent Platform コンポーネントクラスターのサイズをスケールアップできます。この機能は、Kafka クラスターに適用し、Self-Balancing と組み合わせると、特に効果を発揮します。
- Self-Balancing
- Confluent for Kubernetes で Kafka クラスターの Self-Balancing を有効にできます。これにより、トピックのパーティションがクラスターに追加されるときに、確実に新しいブローカーに対して自動バランス調整されるようになります。詳細については、「Kafka クラスターのスケーリングとデータのバランス調整」を参照してください。
- Tiered Storage
- Confluent for Kubernetes で Tiered Storage を有効にすることで、Infinite Kafka の利点を享受できます。Confluent Platform を AWS EKS にデプロイして Tiered Storage に AWS S3 を使用する場合、または Google Kubernetes Engine(GKE)にデプロイして Tiered Storage に GCS を使用する場合、クラウドプロバイダーの認証情報を一切渡すことなく Tiered Storage を構成できます。
- RBAC
- クライアントアプリケーションが、SASL/PLAIN メカニズムと mTLS の両方を使用して、RBAC が有効になったクラスターに対して認証を行えるようになりました。
ちなみに
以前の機能はそれぞれ単独でも大きな価値がありましたが、組み合わさることで、真にクラウドネイティブで柔軟な Kafka 管理を実現できるようになりました。組み合わさった機能がどのように動作するか、詳細については、「Demo: Elastically Scaling Kafka on Kubernetes with Confluent」をご覧ください。
注目すべき機能強化
- アフィニティを介した Kubernetes ネイティブのスケジュール設定
- Confluent Platform コンポーネントポッドのアフィニティおよびアンチアフィニティのスケジュール設定ルールを定義する際に、大幅に柔軟性が高まり、より Kubernetes ネイティブな構成 UX となりました。
注目すべき修正
- プレーンテキストの認証情報の廃止
- 認証情報や Confluent Platform のライセンスキーなどの構成機密データはすべて、Kubernetes の Secret オブジェクトを使用して管理され、実行時にメモリー内だけで Confluent Platform コンポーネントに提供されるようになりました。これにより、一部の認証情報がオブジェクトのプレーンテキストの ConfigMap または Status サブリソースに存在するという以前からの問題に対処できました。
アップグレードに関する考慮事項
- Connect イメージのコネクターの廃止
- Connect 向けの Confluent Platform Docker イメージにコネクターが組み込まれなくなりました。CFK を使用して Connect クラスターをデプロイしており、Confluent の CFK 向けのベース Connect イメージの上に独自の Docker イメージを構築するのではなく、組み込みのコネクターを利用している場合は、その CFK を使用して最新の Connect イメージをデプロイする前に、必要なコネクターを使用してイメージを構築する必要があります。
既知の問題
RBAC が有効になっている場合、Confluent REST API が自動的に有効になります。RBAC が有効になっていない場合、Confluent REST API は無効になります。回避策として、RBAC を無効にした状態で、構成オーバーライドを使用して認証なしで Confluent REST API を有効にしてください。この場合、Confluent REST API エンドポイントへのアクセスを制限するネットワークルールを構成することを強くお勧めします。
Ansible Playbooks for Confluent Platform¶
新機能
- Tiered Storage
- Ansible Playbooks で Tiered Storage の構成を有効にすることで、Kafka の利点を享受できます。Confluent Platform を AWS EC2 にデプロイして Tiered Storage に AWS S3 を使用する場合、または GCP Compute にデプロイして Tiered Storage に GCS を使用する場合、クラウドプロバイダーの認証情報を一切渡すことなく Tiered Storage を構成できます。詳細については、「Ansible Playbooks による高度な Confluent Platform の構成」を参照してください。
- Self-Balancing
- Ansible Playbooks で Kafka クラスターの Self-Balancing を有効にできます。これにより、トピックのパーティションがクラスターに追加されるときに、確実に新しいブローカーに対して自動バランス調整されるようになります。
- ファイルのコピー
- Ansible Playbooks で、Ansible 要塞ホストから Confluent Platform ホストへの汎用的なファイルのコピー機能がサポートされるようになりました。これにより、新たに多くの機能を利用できるようになります。たとえば、Control Center の基本認証レルム構成の提供、Google Cloud Storage 使用時の Tiered Storage 向けの GCP 認証情報 JSON ファイルの提供、Confluent Platform の機密性の保持機能などです。
- 一元化された RBAC 管理
- 別の Kafka クラスターでホストされている Metadata Service (MDS) をポイントするように Kafka クラスターを構成できます。複数のインベントリを使用することで、一元的な MDS ホスティング Kafka クラスターでポイントされている複数の Kafka クラスターをデプロイできるため、複数の Kafka クラスターで RBAC の一元管理が可能になります。
- セキュアな ZooKeeper 通信
- 新しい Ansible インストールでは、TLS 暗号化(ZooKeeper に対するピアツーピア通信とクライアント-サーバー通信の両方が対象)および新しい認証メカニズム(SASL MD5 や Kerberos など)による ZooKeeper 向けのセキュアなネットワーク通信を構成できます。
- Confluent REST API
- Ansible Playbooks では Kafka ブローカー内に REST Proxy(v3 API のみ)を組み込むことができ、さらに別のクラスターとしての REST Proxy のデプロイも引き続きサポートされます。
注目すべき機能強化
- 強化されたローリング再起動
- Confluent Platform コンポーネントのローリング再起動が連続的に実行され、ダウンタイムを最小限に抑えることができるようになりました。Ansible Playbooks によって調整される ZooKeeper と Kafka のローリング再起動は、リーダーまたはコントローラーを最後にローリングするというベストプラクティスに従います。
- Tarball によるパッケージのインストール
- Confluent Platform のパッケージを、Ansible 要塞ホストにある Confluent Platform tarball からインストールできます。この機能は、分断した環境にあるユーザーにとって特に便利です。
- Jolokia TLS
- Jolokia のエンドポイントを、TLS を介したセキュアな通信用に構成できます。
- Java 11
- Ansible Playbooks を介してデプロイされた Confluent Platform コンポーネントに Java 8 と Java 11 のどちらを使用するかを選択できます。
- RHEL 8
- Ansible Playbooks を介して Confluent Platform コンポーネントを RHEL 8 オペレーティングシステムのホストにデプロイできるようになりました。
- JMX Prometheus Exporter
- すべての Confluent Platform コンポーネントで JMX Prometheus Exporter を有効にし、Prometheus を介してプラットフォームをモニタリングできるようになりました。前のバージョンでは、これは ZooKeeper および Kafka でのみサポートされていました。
- ハイブリッドサポートの改善
- Kafka や Schema Registry などの Confluent Cloud のサービスに接続するように Confluent Platform コンポーネントを構成し、デプロイできます。このために、すべての Confluent Platform コンポーネントに対して、包括的な構成のオーバーライドのための Ansible Playbooks のサポート(本リリースで修正)を使用します。
- デバッグログの強化
- コンポーネントの正常性の確認でエラーが発生した場合は、Playbook により対象のコンポーネントからログファイルとプロパティファイルがフェッチされ、cp-ansible のルートにある
error_files/
ディレクトリ内の Ansible コントロールノードに渡されます。
注目すべき修正
- 包括的な構成のオーバーライド
すべての Confluent Platform コンポーネントプロパティを、Ansible Playbook 構成を介して構成し、オーバーライドできます。前のバージョンでは、Ansible Playbooks はユーザーが提供した構成オーバーライドの(すべてではなく)一部を反映していました。
- ログ出力での機密情報
-vvv
Ansible オプションでデバッグが有効になっている場合、パスワード、証明書、キーなどの機密情報が出力されます。Ansible は、-vvv
で機密情報を抑制する方法を提供していません。このため、本稼働環境でデバッグモードを使用することはお勧めしません。代わりに、問題をトラブルシューティングする場合は、プレイブックを
--diff
オプションで使用します。このリリースでは、Ansible Playbooks for Confluent Platform の--diff
オプションでの出力では、パスワード、証明書、キーなどの機密情報が出力されなくなりました。詳細については、「Ansible Playbooks for Confluent Platform のトラブルシューティング」を参照してください。
Kafka Streams¶
- KIP-441: Kafka Streams のためのスムーズなスケールアウト
- スケーリング操作中に Kafka Streams の可用性を改善します。新しいインスタンスが追加されると、新しいタスクが完全にキャッチアップされるまでステートは再割り当てされません。
- KIP-447: "厳密に 1 回" のセマンティクスのためのプロデューサーの拡張性
- Kafka Streams の "厳密に 1 回" のセマンティクスのための拡張性を改善します。
ksqlDB¶
- プルクエリが GA になりました。
- ksqlDB-Connect 統合が GA になりました。
- 複数の結合
- 1 つのクエリ内で複数の結合を指定できるようになりました。
- LIKE 式の改善
- 一致する 1 文字にアンダースコア(
_
)のワイルドカード文字を使用できるようになりました。
- 保持時間と猶予期間の調整が可能に
- ウィンドウデータがディスクに保持される合計時間を RETENTION 句で構成できるようになりました。また、まだウィンドウに含まれている入力イベントの到着をどの程度 "遅く" するかを明示的にコントロールすることもできます。このためには、ウィンドウの GRACE PERIOD 句を使用します。
- プルクエリのレート制限
- プルクエリリクエストのノードあたりのレート制限を、
ksql.query.pull.max.qps
構成パラメーターを使用して 1 秒あたりの最大クエリ数という観点から設定できるようになりました。
- 新しい組み込み関数
- マップ、配列、文字列、正規表現の処理を簡単にする 24 個の新しい組み込み関数が追加されました。
- ネイティブ Java クライアント
- ksqlDB に、プログラムによって ksqlDB とやり取りするためのネイティブ Java クライアントが追加されました。
- 進化したキーのサポート
- 列の定義に [PRIMARY] KEY 修飾子を追加することで、特定のストリームおよびテーブルの行キーをクリーンに指定できるようになりました。
破壊的変更
- WITH (key=...) 構文の廃止
- 新しいクエリでは、キーの指定に [PRIMARY] KEY 構文を使用する必要があります。
- プロジェクションでキーが必須に
- クエリの SELECT 式リストにキー列を明示的に割り当てる必要があります。
- Kafka メッセージキーへのキーの保管
- ksqlDB で、行キーを基盤となる Kafka メッセージのキーに保管するようになりました。キーフィールドを Kafka メッセージの値にコピーする必要がある場合は、AS_VALUE ヒントを使用できます。
- クエリの出力に暗黙的に含まれる ROWTIME の廃止
- クエリの結果に ROWTIME を含めるには、出力で返されるプロジェクションのリストに明示的に含める必要があります。
- 生成される列名の変更
- 自動生成されるプッシュクエリの列名が、ksqlDB の前のリリースから変わりました。
テレメトリ¶
Confluent Telemetry Reporter という新しいコンポーネントが Confluent Platform に追加されました。このコンポーネントはすべての Confluent Platform サービスで実行され、標準のメトリクス収集モデルとなります。データを Kafka にローカルに、Confluent に直接、またはその両方に同時にストリーミングします。
- ブローカーメトリクスを業界標準フォーマットでトピックに送信
- Confluent Telemetry Reporter はメトリクスをブローカーから
_confluent-telemetry-metrics
トピックにプッシュします。ここでメトリクスは OpenCensus フォーマットで保管され、Confluent Platform のサービス Confluent Platform のユーザーによって消費されます。
- パフォーマンスメトリクスを Confluent に送信してトラブルシューティングを促進
- Confluent Telemetry Reporter は、HTTP 経由でパフォーマンスメトリクスを Confluent に送信してトラブルシューティングを促進するために、あらゆる Confluent Platform コンポーネントで使用できます。
廃止に関する警告¶
Confluent Platform 6.0 から、コネクターは Confluent Platform にネイティブにパッケージ化されなくなります。以前パッケージ化されていたコネクターはすべて、Confluent Hub から直接ダウンロードする必要があります。
ダウンロード方法¶
Confluent Platform は https://www.confluent.io/download/ からダウンロードできます。詳細については、「オンプレミスのデプロイ」セクションを参照してください。
重要
Confluent Platform パッケージにはデフォルトで Confluent Server が含まれており、server.properties
ファイルに confluent.license
キーが必要です。Confluent Platform 5.4.x 以降では、Confluent Server ブローカーは起動時にライセンスをチェックします。以下のように confluent.license
プロパティを使用して、各ブローカーのプロパティファイルにライセンスの文字列を指定する必要があります。
confluent.license=LICENCE_STRING_HERE_NO_QUOTES
Kafka ブローカーを使用する場合は、confluent-community
パッケージをダウンロードしてください。Kafka ブローカーは、すべての Debian、または RHEL および CentOS パッケージでデフォルトです。
Confluent Server への移行の詳細については、「Confluent Server への移行」を参照してください。
Confluent Platform を新しいバージョンにアップグレードするには、ドキュメント「Confluent Platform のアップグレード」を参照してください。
サポートされているバージョンおよび相互運用性¶
Confluent Platform およびそのコンポーネントのサポートされているバージョンと相互運用性については、「サポートされているバージョンおよび相互運用性」を参照してください。
お問い合わせ¶
本リリースに関してご不明な点がある場合は、コミュニティのメーリングリスト または コミュニティ Slack からご連絡ください。Confluent 製品を既にご利用の場合は直接サポートにお問い合わせください。