データドリブンなビジネスで成功している数多くの企業で採用されています。
Kafka誕生から10年近く経った現在、世界の情勢もITのトレンドも大きく変化しました。その変化の波がより速く、激しくなる中にあって、Kafkaはこれからどんな方向に進もうとしているのでしょうか。本稿では8月に24日に行われたConfluentのエンジニアリングリーダーであり、Apache Kafkaのメインコントリビューターでもあるグウェン・シャピラ（Gwen Shapira）氏のオープニングキーノートの内容を中心に、Kafkaが次の10年で目指そうとしている方向性を見ていきます。
キーノートでのグウェン・シャピラ（Gwen Shapira）氏、Confluentのエンジニアリングリーダーを務め、 Kafkaのメインコントリビューターでもある
Kafkaにおける「コンセプチュアルインテグリティ」を実現するために
「すばらしいアーキテクチャにはコンセプチュアルインテグリティ（Conceptual Integrity、コンセプトの統合）がある」―キーノートの冒頭、シャピラ氏はソフトウェア工学でよく語られるキーワードを引き合いに出し、Kafkaもまた統合されたコンセプトのもとに構築されるアーキテクチャであるべきとしています。加えてKafkaにおけるコンセプチュアルインテグリティを実現する要素として、以下のポイントを示しています。
スケーラビリティ
マルチテナンシー、ブローカーの追加＝キャパシティの増加、すべてのディメンジョンでリニアにスケール
使いやすい運用環境（Operationally Friendly）
整備されたドキュメント、監視可能、自動化のしやすさ、メンバーどうしの共同作業のしやすさ、効率性（＝安価であること）
弾力性（Elasticity）
ブローカーの追加/削除のしやすさ、ワークロードの変更に対する適応
コンセプチュアルインテグリティはフレデリック・ブルックス「人月の神話」などに出てくる言葉で、システム開発におけるコンセプトの重要性をあらわしている
ではこうした要点を押さえた上で、Kafkaはどのように変化していこうとしているのでしょうか。シャピラ氏はKafka開発者がKafkaの改善点を提案/議論するスペース「Kafka Improvement Proposals（KIP） 」の議題の中でも、データプレーンとコントロールプレーンのそれぞれにおいて取り組むべきもっとも重要な項目として以下の2つを挙げています。
このうち、ZooKeeper依存を廃するKIP-500に関してはすでに承認済みの修正項目となっており、近い将来のアップデートで実現することが決定しています。
まずはデータプレーンのアップデートであるストレージ階層化について。KIP-405ではKafkaクラスタのストレージをローカルとリモートの2階層に分け、ローカル層は従来（ブローカー上のローカルディスク）と同様の位置づけに、そして新たに追加するリモート層はHDFSやAmazon S3などの上に構築され、書き込みが完了したログセグメントを保存する役割を担います。つまりリモート層をコールドストレージとして機能させることで、ローカル層に保存されるデータの保存期間を大幅に短縮することが可能になります。シャピラ氏はストレージ階層化によって得られるメリットとして
ほぼ制限なしでの履歴保存
プラガブルストレージの実現
容易なキャパシティプランニング
を挙げていますが、書き込みが完了したログをリモートストレージへと分離することで、ストレージの独立性を高め、さらにスケーラビリティの大幅な拡張も見込めます。また、この変更はKafkaの既存アーキテクチャにはそれほど大きな影響を与えず、既存ユーザのユーザビリティも損なわれないとされており、シャピラ氏は「レイテンシとスループットを最適化するためにもKIP-405はひじょうに重要なアップデート」と語っています。
そして、コントロールプレーンにおける、というよりもKafkaの進化においてもっとも重要ともいえる変更がZooKeeperからの依存脱却です。前述したとおり、ZooKeeperのリムーブはすでに決定事項であり、正式リリースに向けてさまざまな取り組みが進んでいます。たとえば2020年4月にリリースされた「Apache Kafka 2.5.0」では管理ツールによるZooKeeperへのダイレクトアクセスが非推奨（KIP-555）とされ、ダイナミックコンフィギュレーションでZooKeeperのアクセスが不要になっており、"脱ZooKeeper"に向けて着々と準備が整っている印象です。
Kafkaの今後の進化を左右する2つの大きなアップデート。ストレージの階層化（KIP-405）とZooKeeperのリムーブ（KIP-500）
Kafkaが「脱ZooKeeper」を目指すわけ
「ZooKeeperはKafkaにおける最大のボトルネック。これからのKafkaは"No ZooKeeper"となる」というシャピラ氏の言葉にあるように、今後、Kafkaはメタデータ管理をZooKeeperではなく、Kafka自身が内部に「Kafka Contorller」というRaftアルゴリズムをベースにした管理ノードをもつことで「よりKafkaらしく進化を遂げていく」（ シャピラ氏）方針です。
Kafka Controlerはいわば、Kafkaの中にKafkaのサブセットをもつような"Kafka on Kafka"なアーキテクチャといえます。たとえば4ノードのブローカーと3ノードのZooKeeperで構成される小規模なKafkaクラスタの場合、新しいアーキテクチャのもとでは4ノードのブローカーと3ノードの新コントローラという構成に置き換えられますが、この3ノードのコントローラのうちの1つはメタデータパーティション管理におけるリーダーとしての役割を担います。メタデータの更新時には、コントローラノードがブローカノードに対してプッシュ型の配信を行うのではなく、ブローカーノードがリーダーのコントローラノードからメタデータの更新データをプル型で取得します。シャピラ氏が「よりKafkaらしく」と表現したように、Kafkaにおけるパブサブ方式のメッセージングアーキテクチャと同様のしくみがメタデータ管理にも反映されるようです。
ブローカーのローカルストレージとは別にリモートストレージ層を新たに追加し、書き込みが完了したログをコールドデータとして保存することで、ストレージの独立性とスケーラビリティを担保する
では、なぜKafkaはこれまでメタデータ管理に使ってきたZooKeeperから離れるのでしょうか。それはZooKeeper依存を残したままではいまの時代に求められるスケーラビリティを実現することが難しいからです。エンタープライズITの世界はここ1、2年で急激にクラウドネイティブ化が進んでおり、さらに新型コロナの感染拡大によってクラウドネイティブなワークロードは爆発的に増えています。リアルタイムなイベントストリーミングデータを扱うKafkaもまた、よりモダンなラウドアーキテクチャに適したスケーラビリティを担保する必要がありました。
しかしシャピラ氏の言葉通り、その最大のボトルネックとなっていたのがZooKeeperでした。ZooKeeperとKafkaは基本的なアーキテクチャが異なる別々の分散システムであり、外部のシステムであるZooKeeperがKafkaのメタデータの管理を続けることは、ノード数やデータ量が増えれば増えるほどにオペレーションの煩雑さと無駄なデータの重複を加速させ、Kafkaそのもののスケーラビリティを大きく阻害することになります。
ZooKeeperのリムーブに関しては、金融やメディア、ECサービスなどで大規模なKafkaクラスタを構築してきたKafka/Confluentユーザから多くのリクエストが出されていました。これらの業界では現在、ビジネスの重要な決定を左右するデータの多くがクラウド上に集約されるようになっており、データプラットフォームの急激なクラウドネイティブ化が進められています。そうしたケースのひとつとして、今回のサミットに登壇していたCITIグループのITディレクターを務めるレオン・スティール（Leon Stiel）氏が、Confluent共同創業者であるジュン・ラオ氏との対談で語った内容を一部紹介します。
Kafkaの将来を大きく左右するZooKeeperのリムーブは正式リリースに向けて着々と準備が進んでいる
「1日あたり4兆ドルに相当するトランザクションを日々扱っているCITIグループでは、地球全体に渡って、あらゆる技術をスペクトラムのように使い、ラージスケールシステムからマイクロサービスまでを動かしている。Kafkaもその活動を支える重要な技術だが、ZooKeeperを我々のフットプリントにあわせて適切にサイジングすることが難しいという技術的課題があった。たとえばKubernetesを使ってKafkaをクラウド上にインプリメンテーションしようとしても、このスケールの難しさが阻害要因となる。コネクタを利用するという方法もあるが、コネクタはセキュリティホールを生じやすい。ZooKeeperがスケールしにくいという問題はConfluentにも何度も申し入れて、ディスカッションを重ねてきた。今回、あらためてZooKeeperリムーブの方向性が明らかになったことはCITIとしても非常に歓迎したい」（ スティール氏）
KIP-500の解説画像から引用。現在のZooKeeperとブローカーによるメタデータ管理（左）とアップデート後のKafka on Kafkaなメタデータ管理（右） 。KIP-500のあとはオペレーションが容易になり、スケーラビリティが確保されることに加え、トピックの追加や削除もスピードアップされる
レオン・スティール氏。CITIグループはKafkaの大規模ユーザとしても知られるが、クレディスイスでKafkaを運用してきた経験をもつスティール氏がCITIグループでのKafkaの導入を積極的に進めてきたという
繰り返しますが、CITIグループのようなラージエンタープライズ、つまりKafkaにとっての重要なユーザのクラウドネイティブ化はかつてないスピードで進んでいます。ストレージの階層化を進めるKIP-405と同様に、ZooKeeperをメタデータ管理からリムーブして分散システムとしてのスケーラビリティを拡大するKIP-500は、Kafkaの将来を大きく左右するマイルストーンだといえます。
「Kafkaとは進化するシステムである（Kafka is an evolving system） 」―キーノートの最後、シャピラ氏はKafkaのことをこう表現しています。そして現在、Kafkaの進化の方向性は明らかにクラウドネイティブへと向かっています。
シャピラ氏がキーノートの最後に示した「新生Kafka」を支える3つの要素はElastic（弾力性） 、Integreated（統合） 、Infinite（制限なし） 。クラウドネイティブを前提とした進化をしていくことを示している
5年前、"データレイク"という言葉から人々が連想する代表的な技術はHadoopであることが多かったのですが、現在はAmazon S3などに代表されるクラウドストレージ（オブジェクトストレージ）に企業活動にとって重要なワークロードのデータが集約されつつあります。また、クラウド上にKubernetesに代表されるコンテナ管理システムを使ってイミュータブルなシステムを構築し、ニーズに応じてスケールアウト/ダウンさせていくアプローチもめずらしくなくなりました。データとシステムがクラウドへと急激に集約されている現在、データストリーミングプラットフォームとしての存在感を強めたいKafkaが、KIP-405やKIP-500に代表されるクラウドネイティブな機能拡張を選んだのも当然だといえるでしょう。
新たな進化の一歩を踏み出したKafkaが次のフェーズでどんなプラットフォームへと成長していくのか、近い将来にリリースされる「Apache Kafka 3.0」で、その答えの一端を見ることができるかもしれません。
