Kafka on KubernetesのStrimziConから新機能を解説するセッションを紹介

Apache KafkaをKubernetes上に実装するオペレータStrimziに特化したカンファレンスStrimziCon 2024から、新しく導入される新機能を解説したセッションを紹介する。

プレセンターはRed HatのFederico Valeri氏

セッションのタイトルは「Enhancing Kafka topic management in Kubernetes with the Unidirectional Topic Operator」、直訳すると「Unidirectional Topic Operatorを使ったKafkaのトピック管理を拡張」についての解説ということになるが、その前にUnidirectional Topic Operatorとは何か？ を知らないと理解は難しいだろう。それについてはUnidirectional Topic Operatorの前身、Bidirectional Topic Operatorとの比較が必要だ。

ここについてはRed Hatのブログで詳しく解説されている。このブログの著者が今回のプレゼンターであるValeri氏である。

●ブログ：Introducing the Unidirectional Topic Operator

ここではUnidirectional Topic Operatorが登場する前、つまり前のバージョンの機能としてのBidirectionalの指示系統に関する内容が解説されている。BidirectionalはKafkaとKubernetesの指示系統が双方向で可能となり、Kafkaからの変更がKubernetesに伝達されるケースとKubernetesからKafka側に変更が伝達されるケースの両方の操作を許していたということになる。しかしUnidirectional Topic OperatorではKubernetesがマスターとなって宣言的に望まれる状態を定義し、それに従ってKubernetesがKafkaの状態を変更するという一方通行のモードになる。

そもそもStrimzi自体がApache KafkaをKubernetesに実装するオペレータであり、Kafkaで処理されるメッセージの管理単位であるパーティションに対する操作をKafkaのコマンドラインを使うのではなくKubernetesのAPI経由で行おうという発想である。その流れで、トピックの管理もKubernetesの作法、手続き的ではなく宣言的な方法でやりたいという発想だと思われる。

Valeri氏のセッションは、Kafkaの中のメッセージに関してトピックとパーティションについての概要を解説することから始まった。

トピックの解説

パーティションの解説

この部分についてはRed Hatのブログに詳細に解説されているのでそちらも参照されたい。

●参考：Apache Kafka：基本的な10の用語と概念について

その後に課題としてトピックの管理、バルクな操作への対応、トピックの状態監視などを挙げている。ここでは単にKafkaに対する課題というよりも、Kubernetes上で実装した時にKubernetesの発想と合わない部分をどうやって解消するのか？ という視点であることに注目したい。

Kubernetes上のKafkaの課題を解説

そのKubernetesスタイルでKafkaを操作したいという要望のひとつがStrimziであり、次に紹介されたKafka Topic Operatorだ。

Kubernetesスタイルでトピックの管理を可能にするTopic Operator

次のスライドではYAMLの形式でKafkaのトピックが定義されていることを紹介した。

YAMLで表現されたトピックの定義

そしてここからは古い世代と新しい世代の移り変わりについての解説となった。

2018年からの古い世代から2024年の新世代のGAまでを概説

2018年から始まったKubernetesでの実装は、どちらかが主導権と取るのではなく同等な主導権と持つという発想からZooKeeperを使わないKRaftモードの導入、一方向でバッチ処理を可能にする新しい管理方法に移行し、0.41というバージョンでGAになるという流れだ。その先には複数のネームスペース、マルチテナンシーなどが視野に入っていることが示されている。

旧世代と新世代の比較

このスライドで新世代と旧世代が比較されているが、新世代はKubernetesに沿った管理運用であるのに対し、旧世代はKafka独自の管理運用方法と言えるだろう。旧世代ではZooKeeperが必須だが、新世代ではZooKeeper（ZK）とKRaftの2つのモードをサポートすることになるが、本音としてはKRaftモードだけにしたいという意図は理解できる。新世代のKafkaは、Kubernetesをインフラストラクチャーとして使い、構成が複雑になり管理も難しいZooKeeperをコントロールプレーンに使わないKRaftモードがメインになる。そしてKubernetesに合わせるように、Kafkaからの変更を許さないUnidirectional Topic Operatorが出てきたと考えるのが自然だろう。

旧世代の課題を詳細に解説

ここでもZooKeeperが必要になることで維持管理が難しくなること、スケーラビリティが限定されることなどが解説された。

UnidirectionalとBidirectionalの比較

UnidirectionalとBidirectionalの比較のスライドでは単に高速になるだけではなく、ブローカーのレプリケーションをKubernetesから可能にするReplication Factor Changeという機能も紹介された。ちなみにグラフはReconciliation Time（Kafkaに対する変更が調整されて実現するまでの時間）がイベントの数が増加するにしたがって増えるというベンチマークだが、多くのケースでUnidirectionalはBidirectionalの倍以上の時間がかかっていることを示している。

そしてReplication Factor Changeについてはデモを交えて解説を行った。

Replication Factor Changeの解説。後半はデモを実施

ここではReplication Factor Changeを、デモを交えて解説した。これまでレプリカの作成はコマンドラインで行い「どこに作成するのか」「どれをリーダーにするのか」などはユーザーが指示しなければいけなかったが、Cruise-ControlというOSSを使うことで自動化できることを見せた。ちなみにこのCruise-Controlは、Kafkaのオリジナルの開発者であるLinkedInが公開しているものだ。

●参考：https://github.com/linkedin/cruise-control

そして最後に複数のネームスペースが存在するマルチテナントでの実装についても、将来計画として解説。単一の巨大クラスターで複数のユーザーを収納するような使い方においてネームスペースを分離したい、同じネームスペースが使われても問題を起こさないようにしたいというのが要望として挙げられており、それに応える形でマルチネームスペースの実装が検討されていると説明された。

マルチテナントの場合に起こり得る同じネームスペースを使った際の対応を検討中

全体としてUnidirectional Topic Operatorに関する解説というよりも、新世代に向かっていく姿勢とKubernetesをインフラストラクチャーに使い、Kafkaを抽象化したいという意図を感じるセッションとなった。RedpandaやIggy.rsという新興プロジェクトも競い合っている分散メッセージングの領域は、クラウドネイティブの未来を実装するためには必須の基盤だろう。要注目だ。