連載 [第1回] :
  StrimziCon 2024レポート

Kafka on Kubernetesを実現するStrimziに特化したカンファレンスStrimziCon 2024からキーノートを紹介

2024年7月8日(月)
松下 康之 - Yasuyuki Matsushita
Kafka on Kubernetesを実現するStrimziCon 2024のキーノートを紹介する。

大規模な分散システムに不可欠なメッセージングシステムのApache KafkaをKubernetes上に実装するオープンソースプロジェクトStrimziに特化したカンファレンス、StrimziCon 2024を紹介する。カンファレンスはオンラインカンファレンスとして2024年5月22日に行われ、キーノートに続いて2トラックのセッション構成でキーノートを含めて9セッションが実施された。

アジェンダは以下の公式ページから参照できる。

●参考:https://community.cncf.io/events/details/cncf-virtual-project-events-2024-hosted-by-cncf-presents-strimzicon-2024-virtual/

すべてのセッションは動画としてCNCFのチャネルで公開されている。

●StrimziCon 2024の公式プレイリスト:StrimziCon 2024

Strimziの過去、現在、そして未来

キーノートではStrimziの現状を、Red Hatのプリンシパルエンジニア2名が紹介した。

●キーノート:Keynote: Strimzi Past, Present and Future

Strimziの過去、現在、そして未来を総括するキーノート

Strimziの過去、現在、そして未来を総括するキーノート

登壇したのはイングランドがベースのKate Stanley氏とイタリアはナポリ在住のPaolo Patierno氏だ。

StrimziはApache KafkaをKubernetesに実装するためのオペレータ

StrimziはApache KafkaをKubernetesに実装するためのオペレータ

KafkaをKubernetes上に実装するためには複雑なプロセスが要求されるとして、Strimziが登場した背景を解説。特にメッセージ交換のためのデータプレーンと制御を行うためのコントロールプレーンにそれぞれクラスターが必要なことは、この後のKRaftについての部分で言及したい。そのためKafkaクラスターの管理維持には多くの労力が必要というのが大きな課題であった。

Kafka on Kubernetesの実装には多くの労力が必要

Kafka on Kubernetesの実装には多くの労力が必要

Strimziは、Kubernetes上のソフトウェアのライフサイクルを支援するためのOperator Frameworkを使って実装されたKafkaのためのオペレータだ。そしてOperator Frameworkの開発を主導しているのが、Red Hatというわけだ。StrimziConのキーノートにRed Hatのプリンシパルエンジニアが登壇するのも頷けよう。

Strimziの特徴。Kubernetesネイティブな使い勝手がポイント

Strimziの特徴。Kubernetesネイティブな使い勝手がポイント

そしてStrimziの歴史についても簡単に紹介。当初はRed Hatの社内で開発されていたソフトウェアで「Barnabas」と言う名前だったという。2018年1月に最初のリリースが行われたが、2018年3月にはOperator Frameworkを使う方向に設計を変更し、コントローラをゼロから書き直したそうだ。

Strimziの過去の歴史を振り返る。最初の名前はBarnabas

Strimziの過去の歴史を振り返る。最初の名前はBarnabas

2019年8月にはCNCFのサンドボックスプロジェクトとなり、2024年2月に正式にインキュベーションプロジェクトに昇格したという経緯が解説された。

2019年8月にサンドボックス、2024年2月にインキュベーションプロジェクトに昇格

2019年8月にサンドボックス、2024年2月にインキュベーションプロジェクトに昇格

サンドボックスからインキュベーションプロジェクトに昇格するまでに約5年と長期間を要したという批判はあるかもしれないが、それでもKubernetes上でKafkaを動かしたいというユーザーにとっては継続して活動していることは良いニュースだろう。

そしてここから今後の予定について解説。ここではKafka自体が変化していくことに対応するため、いくつかの機能強化が紹介されている。

Strimziの今後の機能強化ポイントを紹介

Strimziの今後の機能強化ポイントを紹介

StrimziはKafkaをKubernetesに実装するための仕組みではあるが、Kafka自体が変化していくことに対応していく必要があるとして、最初に挙げられているのがKRaftサポートだ。他にも複数のバージョンのKafkaサポートなどが挙げられている。

OpenTelemetryサポートや認証についても強化ポイントとして挙げられている

OpenTelemetryサポートや認証についても強化ポイントとして挙げられている

KRaftについて

ここからは特にKRaftについて、Kafkaの開発元と言っても過言ではないConfluentの動画を使って解説しよう。Kafkaはクラスターの分散管理のためにZooKeeperというオープンソースプロジェクトを使っているが、その部分を新たに書き起こしたKRaftというソフトウェアで置き換える作業が進行している。

コミュニティがKraftベースのバージョンに移行するのを助けることが必要

コミュニティがKraftベースのバージョンに移行するのを助けることが必要

冒頭でメッセージ交換のためのデータプレーンとコントロールプレーンについて言及したが、KafkaではデータプレーンはKafkaのクラスターノード、コントロールプレーンはZooKeeperのクラスターノードが必要というのがこれまでの前提だった。メッセージ交換を確実に行うために複数のブローカーが存在してメッセージの冗長性を維持しながら、障害時にサーバーが停止したとしてもメッセージ交換を行うノードはその役割を交換して確実にメッセージを保持できる構造となっていた。そのためにブローカーも複数必要で、そのノード管理を行うコントロールプレーンも複数のノードを用意してクラスターとして実装される。

複数のブローカーが存在している状態で、どのノードがプライマリなのか、またレプリカはどのノードなのかを管理するためだけにZooKeeperが存在していたわけだが、ZooKeeper自体も冗長性を維持するためにクラスターとして実装される必要があった。言わば2階建ての構造でデータプレーンとコントロールプレーンの実装が必要だったのだ。

そしてその構造を変えようというのが、2020年にKIP-500として提案されたZooKeeperを使わない実装案だ。

●参考:KIP-500: Replace ZooKeeper with a Self-Managed Metadata Quorum

そしてこの動きに対応するというのが、Strimziの今後の方向性となる。

KRaftという名称が示すように、Raftという合意形成アルゴリズムを使って複数のノードにおいてノードのリーダーとフォロワーを計算によって決定し、障害が発生したとしてもリーダーの交代がスムーズに行われ、複数ノードがこれまでと同じ処理を続けられることを目指している。

ちなみにRaftはKafkaと同じメッセージ交換ソフトウェアであるRedpandaの中でも利用されている。またKubernetesのデータストアである分散データストアのetcdもRaftの実装例だ。

●参考:Wasmでストリーミングエンジンを実装したRedpandaを紹介

また最近ではメモリーセーフなプログラミング言語であるRustを使って高速なメッセージ交換を行うオープンソースプロジェクトのIggy.rsも登場しており、分散処理のベースとなるメッセージ交換について活発に技術革新が続いていると言えるだろう。

●参考:Message Streaming Reimagined

ここからKafkaの開発元であるConfluentの共同創業者Jun Rao氏の解説動画を紹介する。タイトルは「Apache Kafka Control Plane - ZooKeeper vs KRaft」である。

●参考:The Apache KafkaR Control Plane ? ZooKeeper vs. KRaft

ConfluentによるKafkaコントロールプレーンの解説

ConfluentによるKafkaコントロールプレーンの解説

この動画自体は2022年に公開され、すでに2年間が経過している。前述の通りZooKeeperをなくす改善案自体は2020年に公開されており、コミュニティにとっては既知の情報と言える。しかしその対応が2024年でも解説されているように、KRaftを使うマイグレーションや実装は進んでいないというのが実態なのではないか。

2階建てのZooKeeperを捨ててKafkaノード内でコントローラを実行するパターン

2階建てのZooKeeperを捨ててKafkaノード内でコントローラを実行するパターン

この変更によってZooKeeperクラスターを維持管理する必要はなくなり、オーバーヘッドがなくなることで性能面での向上やスケーラビリティが改善することになる。

KRaftモードと呼ばれる新しい実装図

KRaftモードと呼ばれる新しい実装図

次のスライドでは、ZooKeeperモードとKRaftモードの性能比較を行っている。ここではノードを停止した際の処理時間と回復させた際の処理時間の比較だ。グレイのZooKeeperモードに比べて、KRaftを使った場合は劇的に処理が高速化されていることがわかる。

KraftモードではZooKeeperモードの数十倍も高速化

KraftモードではZooKeeperモードの数十倍も高速化

そしてこれまでの別建てのZooKeeperクラスターが不要になったことで、コントローラをブローカーノードと共存させることが可能になったとして、小規模のKafkaクラスターのニーズにも対応できるようになったことを紹介。この後の動画はRaftによるリーダー選出の詳細を解説する内容となっているので、その部分にも興味があれば視聴して欲しい。

大規模になっても信頼性の高いメッセージ交換システムは、クラウドネイティブなシステムにとっては必須な基盤だが、イノベーションは継続しており、どのソフトウェア/プロジェクトがリーダーとなって市場を牽引して行くのか引き続き注目していきたい。

著者
松下 康之 - Yasuyuki Matsushita
フリーランスライター&マーケティングスペシャリスト。DEC、マイクロソフト、アドビ、レノボなどでのマーケティング、ビジネス誌の編集委員などを経てICT関連のトピックを追うライターに。オープンソースとセキュリティが最近の興味の中心。

連載バックナンバー

開発ツールイベント
第2回

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

2024/7/16
Kafka on KubernetesのStrimziConから新機能を解説したセッションを紹介する。

Think ITメルマガ会員登録受付中

Think ITでは、技術情報が詰まったメールマガジン「Think IT Weekly」の配信サービスを提供しています。メルマガ会員登録を済ませれば、メルマガだけでなく、さまざまな限定特典を入手できるようになります。

Think ITメルマガ会員のサービス内容を見る

他にもこの記事が読まれています