KubeCon＋CloudNativeCon Europe 2025開幕、Kafkaのリバランス問題を解決するセッションを紹介

2025年最初のKubeCon＋CloudNativeConが2025年4月1日から4日にかけてロンドンで開催された。過去最大規模のオープンソースカンファレンスとなったKubeCon＋CloudNativeCon Europeだが、この記事ではKafkaのワークロードを平準化させるソリューションのセッションを紹介する。KubeCon＋CloudNativeConは参加者の増加に従って共催のミニカンファレンスの数も増えており、このセッションはData on Kubernetes DayというKubernetes上のデータベースや分散メッセージングについて解説するミニカンファレンスの中で実施された。Red Hatのエンジニアが解説するKafkaのワークロードをリバランスさせるソリューションを解説したセッションである。タイトルは「Mastering Kafka workload balancing with Strimzi's Cruise Control Integration」だ。

Data on Kubernetes Dayという名称のミニカンファレンス

セッションを担当したのは、ナポリ在住のRed HatのエンジニアであるPaolo Patierno氏だ。彼は、Kubernetes上でKafkaを稼働させるためのオペレーターであるStrimziのコミッターである。

Kafkaのワークロード平準化をStrimziとCruise Controlの連携で習得する」というセッション

Kafkaの分散メッセージはブローカーと呼ばれるメッセージを中継するアプリケーションタスクで処理されるが、複数のブローカーが複数のノードにおいて分散処理を行うことで大量のメッセージを捌くことが可能になり、障害時のデータリカバリーも可能になる。しかし必ずしもすべてのブローカー／ノードが均一にワークロードを処理することは保証されておらず、メッセージ量の変化に従ってノード上の負荷に偏りが生じうる。その際にどうやってそのアンバランスを解消するのか？ というのが命題だ。

ノードの負荷のアンバランスが発生してしまう問題

その際、単にノードを増やしてスケールアウトしたとしても負荷が偏在する問題は解消されず、ブローカーのリバランスが必要となる。

ワークロードが偏ってしまった場合にはスケールアウトするだけでは解決しない

そのためにワークロードの配置を変えるリバランス機能が必要だというのが答えである。

ブローカーの配置換えを行うことでリバランスを実施

その際に必要なソフトウェアがCruise Controlであると紹介。

Cruise Controlを紹介

ここではCruise ControlがLinkedInで開発されたソフトウェアであると解説した。実際にはKafka自体もLinkedInで開発されたオープンソースソフトウェアであるため、本家本元が必要に応じて開発したと想像できる。

Cruise Controlのリバランス機能をリストアップ

このスライドではCruise Controlのリバランスの機能を簡単に紹介している。必ず守らないといけないハードなゴールとベストエフォートで良いソフトなゴールが設定可能で、ディスク使用量やネットワーク、CPUなどの使用率などが属性として設定の対象であると説明した。

その結果として、アンバランスな負荷の状態がうまくバランスのとれた状態に変化することをグラフによって説明した。

アンバランスなワークロードの状態

バランスの取れたワークロードの状態

そしてCruise Controlのシステムの概要として、Kafkaのブローカー上にその状態を検知するMetrics Reporterというプロセスが常駐することで負荷をモニタリングし、ゴール設定に従ってバランスを変更する仕組みを解説した。

Cruise Controlのシステム概要

そしてKafkaをKubernetes上に実装するオペレーターのStrimziとの連携についてここから解説した。

StrimziとCruise Controlの連携を解説

Cruise ControlをKafkaのカスタムリソースを使って実装。Kafkaとは別のDeploymentとして実行され、Kafkaのブローカー上にMetrics Reporterが構成される。

Cruise Controlの実装の概要

StrimziがKubernetes上にKafkaの実装することを、オペレーターフレームワークの仕組みで実装したことと同様に、Cruise Controlもオペレーターから実装される。

簡単なKafkaとStrimzi、そしてCruise Controlの構成図

プロトコル的にはStrimziがKubernetesのAPIを経由して、Cruise ControlにはREST APIで連携する仕組みであると説明。

KafkaのメトリクスをCruise Control経由でStrimziが受け取ってリバランス

カスタムリソースについても紹介。KafkaRebalanceという名称のカスタムリソースが使われている。

KafkaRebalanceというカスタムリソースを使用

より詳細なシステム構成図を使ってCruise Controlを解説。ここではCruise Controlが使うさまざまなコンポーネントが紹介されている。

より詳細なKafkaとStrimzi、そしてCruise Controlの構成図

アノテーションを使ってリバランスを行うことやリバランスのモードなども併せて説明。

Kubernetes的なリコンサイルループを使ってリクエストされた状態に保つ発想

リバランスのモードを解説

そしてKubernetesのクラスターがスケールアップする仕組みと自動でリバランスする機能によって、相乗的にバランスの取れたワークロードが実行できることを紹介。

クラスターのスケーリングとKafkaのリバランスを併せる

ここではブローカーの追加／削除の際に、クラスターのオートスケーリングが起動されることを解説した。

ブローカーが増減する時に併せてクラスターの自動スケーリングが起動される

結果的にKafkaクラスターの自動修復機能（セルフヒーリング）がCruise Controlによって可能になることを説明した。

最後に2025年6月4日にオンラインイベントとして開催されるStrimziConを紹介して、セッションを終えた。これは2025年1月にStrimziのブログ記事として公開されているバーチャルカンファレンスだが、Kubernetesでデータストリーミングを計画しているエンジニアにとっては有用なイベントとなるだろう。以下のブログ記事を参考にして欲しい。

●参考：Welcome StrimziCon 2025!

リレーショナルなデータベースなどよりも瞬時に大量のメッセージが発生するようなユースケースにおいては、クラウドネイティブなシステムであるKubernetesは向いているだろう。分散されたKafkaノード間でロードバランスするような場合、単純なレプリカセットとロードバランサーでは解決しないKafka特有の問題点を、LinkedInが解決するために開発したのがCruise Control、Red Hatが開発したオペレーターフレームワークを使ってKafkaをKubernetes上に実装するStrimziという組み合わせを解説する内容となった。

Java（JVM）で開発されたKafkaの欠点を補うべくC++で開発されたRedpandaというソフトウェア/サービスも存在しており、後付けでリバランスなどを行うのではなくプラットフォーム自体を切り替えるという発想もあり得るだろう。Redpandaに関しては以下の記事を参考にして欲しい。

●参考：KafkaにWASMモジュールを組み込んでリアルタイムで機械学習を実行するRedpandaのデモセッションを解説