Kafka on Kubernetesを実現するStrimziに特化したカンファレンスStrimziCon 2024からキーノートを紹介
大規模な分散システムに不可欠なメッセージングシステムのApache KafkaをKubernetes上に実装するオープンソースプロジェクトStrimziに特化したカンファレンス、StrimziCon 2024を紹介する。カンファレンスはオンラインカンファレンスとして2024年5月22日に行われ、キーノートに続いて2トラックのセッション構成でキーノートを含めて9セッションが実施された。
アジェンダは以下の公式ページから参照できる。
すべてのセッションは動画としてCNCFのチャネルで公開されている。
●StrimziCon 2024の公式プレイリスト:StrimziCon 2024
Strimziの過去、現在、そして未来
キーノートではStrimziの現状を、Red Hatのプリンシパルエンジニア2名が紹介した。
●キーノート:Keynote: Strimzi Past, Present and Future
登壇したのはイングランドがベースのKate Stanley氏とイタリアはナポリ在住のPaolo Patierno氏だ。
KafkaをKubernetes上に実装するためには複雑なプロセスが要求されるとして、Strimziが登場した背景を解説。特にメッセージ交換のためのデータプレーンと制御を行うためのコントロールプレーンにそれぞれクラスターが必要なことは、この後のKRaftについての部分で言及したい。そのためKafkaクラスターの管理維持には多くの労力が必要というのが大きな課題であった。
Strimziは、Kubernetes上のソフトウェアのライフサイクルを支援するためのOperator Frameworkを使って実装されたKafkaのためのオペレータだ。そしてOperator Frameworkの開発を主導しているのが、Red Hatというわけだ。StrimziConのキーノートにRed Hatのプリンシパルエンジニアが登壇するのも頷けよう。
そしてStrimziの歴史についても簡単に紹介。当初はRed Hatの社内で開発されていたソフトウェアで「Barnabas」と言う名前だったという。2018年1月に最初のリリースが行われたが、2018年3月にはOperator Frameworkを使う方向に設計を変更し、コントローラをゼロから書き直したそうだ。
2019年8月にはCNCFのサンドボックスプロジェクトとなり、2024年2月に正式にインキュベーションプロジェクトに昇格したという経緯が解説された。
サンドボックスからインキュベーションプロジェクトに昇格するまでに約5年と長期間を要したという批判はあるかもしれないが、それでもKubernetes上でKafkaを動かしたいというユーザーにとっては継続して活動していることは良いニュースだろう。
そしてここから今後の予定について解説。ここではKafka自体が変化していくことに対応するため、いくつかの機能強化が紹介されている。
StrimziはKafkaをKubernetesに実装するための仕組みではあるが、Kafka自体が変化していくことに対応していく必要があるとして、最初に挙げられているのがKRaftサポートだ。他にも複数のバージョンのKafkaサポートなどが挙げられている。
KRaftについて
ここからは特にKRaftについて、Kafkaの開発元と言っても過言ではないConfluentの動画を使って解説しよう。Kafkaはクラスターの分散管理のためにZooKeeperというオープンソースプロジェクトを使っているが、その部分を新たに書き起こした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
この動画自体は2022年に公開され、すでに2年間が経過している。前述の通りZooKeeperをなくす改善案自体は2020年に公開されており、コミュニティにとっては既知の情報と言える。しかしその対応が2024年でも解説されているように、KRaftを使うマイグレーションや実装は進んでいないというのが実態なのではないか。
この変更によってZooKeeperクラスターを維持管理する必要はなくなり、オーバーヘッドがなくなることで性能面での向上やスケーラビリティが改善することになる。
次のスライドでは、ZooKeeperモードとKRaftモードの性能比較を行っている。ここではノードを停止した際の処理時間と回復させた際の処理時間の比較だ。グレイのZooKeeperモードに比べて、KRaftを使った場合は劇的に処理が高速化されていることがわかる。
そしてこれまでの別建てのZooKeeperクラスターが不要になったことで、コントローラをブローカーノードと共存させることが可能になったとして、小規模のKafkaクラスターのニーズにも対応できるようになったことを紹介。この後の動画はRaftによるリーダー選出の詳細を解説する内容となっているので、その部分にも興味があれば視聴して欲しい。
大規模になっても信頼性の高いメッセージ交換システムは、クラウドネイティブなシステムにとっては必須な基盤だが、イノベーションは継続しており、どのソフトウェア/プロジェクトがリーダーとなって市場を牽引して行くのか引き続き注目していきたい。
連載バックナンバー
Think ITメルマガ会員登録受付中
全文検索エンジンによるおすすめ記事
- Kafka on KubernetesのStrimziConから新機能を解説するセッションを紹介
- Kafka on KubernetesのStrimziConから新機能を解説するセッションを紹介
- StrimziCon 2024からブラジルのネットバンクにおけるKafkaクラスター移行のセッションを紹介
- StrimziCon 2024番外編、KafkaのリバランスをKubernetesのオペレータで実行するCruise Controlを紹介
- KafkaにWASMモジュールを組み込んでリアルタイムで機械学習を実行するRedpandaのデモセッションを解説
- RustとWASMで開発されKubernetesで実装されたデータストリームシステムFluvioを紹介
- KubeCon China 2024、GPUノードのテストツールKWOKを解説するセッションを紹介
- KubeCon China注目の初日キーノートはプロジェクトアップデート
- マルチクラウドを制御するユニバーサルなコントロールプレーンCrossplane
- コンテナを効率的に運用・管理する標準ツール「Kubernetes」とは