10.3. トピック変更の処理

双方向のトピック管理の場合、Topic Operator は、唯一の信頼できる情報源がない場合でもトピックへの変更を処理できます。KafkaTopic リソースと Kafka トピックは別々に変更される可能性があります。特に Topic Operator が動作していない場合は、変更をリアルタイムで観察することが常に可能であるとは限りません。これに対処するために、Topic Operator は、各トピックに関するトピック設定情報を保存するトピックストアを維持します。Kafka クラスターと OpenShift の状態をトピックストアと比較して、同期に必要な変更を判断します。この評価は、起動中および Topic Operator がアクティブである間、定期的に行われます。

たとえば、Topic Operator が非アクティブで、my-topic という名前の新しい KafkaTopic が作成された場合、再起動時に Topic Operator はトピックストアに my-topic が存在しないことを認識します。KafkaTopic が最後の操作の後に作成されたことを認識します。その結果、Topic Operator は対応する Kafka トピックを生成し、メタデータをトピックストアに保存します。

トピックストアを使用すると、Topic Operator は、変更に互換性がある限り、Kafka トピックと KafkaTopic リソースの両方でトピック設定が変更される状況を管理できます。Kafka トピック設定が更新されるか、KafkaTopic カスタムリソースに変更が加えられると、変更に互換性がある限り、Kafka クラスターとの調整後にトピックストアが更新されます。

トピックストアは、Kafka トピックを使用して状態を永続化する Kafka Streams のキーバリューメカニズムを基にしています。トピックメタデータはインメモリーでキャッシュされ、Topic Operator 内にてローカルでアクセスされます。ローカルのインメモリーキャッシュに適用される操作からの更新は、ディスク上のバックアップトピックストアに永続化されます。トピックストアは、Kafka トピックまたは OpenShift KafkaTopic カスタムリソースからの更新と継続的に同期されます。操作は、このような方法で設定されたトピックストアで迅速に処理されますが、インメモリーキャッシュがクラッシュした場合は、永続ストレージから自動的にデータが再入力されます。

内部トピックは、トピックストアでのトピックメタデータの処理をサポートします。

Streams for Apache Kafka の以前のリリースでは、トピックのメタデータが ZooKeeper に保存されていました。トピックストアによってその必要がなくなるため、メタデータは Kafka クラスターに取り込まれ、Topic Operator の制御下に置かれます。

Streams for Apache Kafka 2.7 にアップグレードすると、Topic Operator によるトピックストア制御への以降がシームレスに行われます。メタデータは ZooKeeper から検出および移行され、古いストアは削除されます。

トピックメタデータの保存に ZooKeeper を使用する 1.7 より前のバージョンの Streams for Apache Kafka に戻す場合も、Cluster Operator を前のバージョンにダウングレードしてから、Kafka ブローカーおよびクライアントアプリケーションを標準として前の Kafka バージョンにダウングレードします。

ただし、Kafka クラスターのブートストラップアドレスを指定して、kafka-topics コマンドを使用してトピックストア用に作成されたトピックを削除する必要もあります。以下に例を示します。

oc run kafka-admin -ti --image=registry.redhat.io/amq-streams/kafka-37-rhel9:2.7.0 --rm=true --restart=Never -- ./bin/kafka-topics.sh --bootstrap-server localhost:9092 --topic __strimzi-topic-operator-kstreams-topic-store-changelog --delete && ./bin/kafka-topics.sh --bootstrap-server localhost:9092 --topic __strimzi_store_topic --delete

このコマンドは、Kafka クラスターへのアクセスに使用されるリスナーおよび認証のタイプに対応している必要があります。

Topic Operator は、Kafka のトピックの状態から ZooKeeper トピックメタデータを再構築します。

アプリケーションは、Kafka クラスター内のトピックの自動作成をトリガーできます。デフォルトでは、Kafka ブローカー設定 auto.create.topics.enable は true に設定されており、アプリケーションが存在しないトピックから生成または消費しようとしたときに、ブローカーがトピックを自動的に作成できるようになります。アプリケーションは、Kafka AdminClient を使用してトピックを自動的に作成する場合もあります。アプリケーションが KafkaTopic リソースとともにデプロイされる場合、Topic Operator が KafkaTopic に反応する前に、クラスター内でトピックの自動作成が行われる可能性があります。

双方向のトピック管理の場合、Topic Operator はトピックと KafkaTopic リソース間の変更を同期します。

一方向トピック管理を使用している場合、これは、アプリケーションのデプロイメント用に作成されたトピックが、最初はデフォルトのトピック設定で作成されることを意味する可能性があります。Topic Operator がアプリケーションデプロイメントに含まれる KafkaTopic リソース仕様に基づいてトピックを再設定しようとすると、必要な設定変更が許可されていないため、操作が失敗する可能性があります。たとえば、変更がトピックパーティションの数を減らすことを意味する場合です。このため、一方向トピック管理を使用する場合は、Kafka クラスター設定で auto.create.topics.enable を無効にすることを推奨します。