Kafkaは転換点に達した
Current 2024—Kafkaとデータストリーミングに関する主要なカンファレンス—は先週オースティンで終了しました。私が参加するのは今回で3回目ですが、毎年のように会場には世界中から集まった専門家たちが詰めかけていました。しかし、今年は少し違って感じました。Kafkaの未来を巡る不確実性が感じられました。このプロジェクトはどこに向かっているのか？エコシステムはどう進化するのか、そして急速に進化するAIの環境においてKafkaはどのような役割を果たすのか？これらの質問が頭をよぎり、Kafkaの未来をより複雑な環境の中で考え直しました。
Kafkaは10年前とは異なっている
LinkedInで13年前に作成された Kafkaは、初めは分散型で永続的な、高スループットなメッセージングシステムとして位置づけられ、大量のデータを低遅延で収集し、配信することを目的としていました。2011年にオープンソース化され、後にApache Foundationに寄贈され、現代ソフトウェアの中で最も成功したプロジェクトの一つに成長しました。2014年にはその開発者たちがLinkedInを離れ、Confluentを設立し、2021年に上場し、データストリーミングのリーダーとしての地位を確立しました。しかし、Kafkaの初期の頃から世界は劇的に変化し、Kafka自体も現在ではより複雑なエコシステムの中で進化を続けています。
2011年当初、Kafkaは主に次の3つの用途で使用されていました：
ログデータの収集
ログデータをオンラインアプリケーションに供給
派生データを本番環境にデプロイ
いくつかの重要な変化
多様な遅延要件：現代のシステムに対する遅延の期待は、より極端に分かれるようになっています。金融サービスでは、株式取引においてマイクロ秒単位の遅延が要求されますが、ログ収集やオペレーショナルデータベースと分析システム間のデータ同期といった他の用途では、数秒単位の遅延でも問題ありません。すべてに対応できる一つのソリューションはもはや機能しません。なぜ、Kafkaを単なるログ収集に使用する企業が、ミッションクリティカルな低遅延アプリケーションを構築する企業と同じコストを支払わなければならないのでしょうか？
バッチシステムは独自のデータ取り込みツールを構築している：例えば、SnowflakeのSnowpipe、Amazon RedshiftのnoETLツール、ClickHouseなど、最近PeerDBを買収したプラットフォームでは、組み込みのストリーミングデータ取り込み機能を提供しています。これにより、Kafkaがデータ環境間でデータを移動させるための唯一の選択肢ではなくなり、その従来の利用ケースに自然な断片化が生じています。
クラウドインフラの進化でストレージが安価になった：Amazon S3のようなオブジェクトストレージソリューションは、EC2などのコンピュートノードよりも格段に安価になっています。これにより、企業が常にクラウドコストを最適化している状況では、より高価なストレージオプションを使用する正当性が薄れています。その結果、Kafkaは安価なストレージオプションを活用できるアーキテクチャに対応しなければ、データパイプラインの中で高額なコンポーネントになってしまうリスクを抱えています。
これらの変化を踏まえ、Kafkaはそのオリジナルのアーキテクチャに頼ることができなくなっています。現代のデータエコシステムの要求に適応し、進化する必要があります。そうしないと、ますますクラウド中心の世界において、Kafkaの存在意義が薄れてしまうでしょう。
Kafkaは必然的に10倍安くなる
Current 2024で最も注目を集めた発表の1つは、Kafka互換システムであるWarpStreamの買収でした。このシステムはKafkaの運用コストを驚くべき10倍に削減します。コンセプトはシンプルでありながら優れています：WarpStreamは主なストレージとしてS3を使用し、ローカルディスクの必要性を排除し、ネットワーク転送料金を大幅に削減します。ストレージ層を安価なクラウドベースのオブジェクトストレージにオフロードすることで、WarpStreamはKafkaをより手頃な価格で提供します。
WarpStreamを買収する戦略的目的は明確です。市場を混乱させ、全体のマージンを圧迫する前に新興競合を吸収することです。WarpStreamのコスト効率の良いアーキテクチャをKafkaエコシステム全体に統合することで、Confluentは安価な代替手段に押されることなくリーダーシップの地位を維持できます。
しかし、Kafkaのコスト削減を進めているのはWarpStreamだけではありません。以下は、Kafkaのコストを引き下げている他の企業です：
Kafkaの運用コストは必然的に10倍安くなるでしょう。特に、Kafkaをログ収集やシステムの分離のためにのみ使用するユーザーにとっては、S3を主なストレージ層として採用するアーキテクチャは明らかな勝利であり、高価なローカルディスクの必要性を排除することでコストを削減できます。
Kafkaはバッチ処理の世界に進出する必要がある
Kafkaは常にリアルタイムストリーミングのための主要なツールでしたが、現在では、Kafkaがその役割を拡大してバッチ処理も扱う必要があることが明らかです。この機会は巨大ですが、同時に脅威も存在します。データウェアハウスや分析データベースはますます自分たちで取り込みツールを構築しており、ユーザーはデータの移動のために必ずしもKafkaを必要としなくなっています。
もしKafkaがバッチ処理を取り入れなければ、そのデータエコシステムにおける重要性は徐々に低下するかもしれません。
データアーキテクチャがコスト削減のために冷データをS3に保存する方向にシフトする中で、Kafkaはリアルタイムデータと履歴データの両方を処理できるように自身を位置づけなければなりません。ここで登場するのがApache Icebergです。Icebergは大規模データセットを扱うために設計されたオープンなテーブルフォーマットで、現代のデータレイクにおいて重要なコンポーネントとして急速に人気を集めています。KafkaがIcebergを採用することによって、ストリーミングとバッチの両方のモードでデータを保存およびクエリするシームレスな方法をユーザーに提供できます。
Kafkaが短期的なデータ保持のためにのみ使用され、履歴データには別のデータウェアハウスやレイクハウスを使用するのではなく、Kafkaがすべてのデータの中央リポジトリとして機能することができます。ストリーミングとバッチの両方のデータを長期間保存し、保持ポリシーを必要とせずに処理できる能力を拡張することで、Kafkaは真のデータレイクに進化する可能性があります。Icebergはこの変革において重要な役割を果たし、スキーマ進化、パーティション分割、最適化されたクエリ性能など、ユーザーに多くの利点を提供します。Icebergの採用が進むにつれて、組織はKafkaデータをオープンフォーマットでクエリできるようになり、ストリーミングとバッチのワークロード両方に対して新しいユースケースを開放します。
もしバッチ機能を取り入れ、Icebergのようなフォーマットとの統合を行わなければ、Kafkaはバッチとストリーミングの両方を統一的でコスト効果の高い方法で処理できるシステムに取って代わられるリスクがあります。Icebergがこのギャップを埋める能力は、データエンジニアやアーキテクトの間でその人気が高まっている主な理由の1つです。
Kafkaは新しいクエリエンジンを必要としている
Kafkaがストリーミングとバッチの両方の世界でその可能性を最大限に発揮するためには、ストリーミングデータを第一級の市民として扱うクエリエンジンが必要です。Trinoのようなバッチ優先のクエリエンジンは、大規模なデータセットに対してアドホックなクエリを実行するのに優れていますが、連続クエリの実行には限界があります。これはKafkaユーザーにとって重要な要件であり、このギャップはKafkaのニーズに特化したストリーミング優先のクエリエンジンの登場を促進しています。
いくつかのエンジンがこのギャップを埋めるために登場しています。RisingWaveとFlinkは、リアルタイムで継続的に更新されるデータの処理に優れたストリーミング優先のプラットフォームとして注目されています。RisingWaveは、イベントストリーム上でSQLクエリを実行するのに特に適しており、ユーザーが従来のストリーム処理の複雑さに対処することなくリアルタイムで洞察を得ることを簡単にします。同様に、Flinkの分散ストリーム処理機能は、低遅延、高スループットのアプリケーションにとって強力なツールとなります。
一方、ksqlDBは、Kafkaの拡張機能で、Kafkaストリームをリアルタイムでクエリおよび処理するためのシンプルなSQLベースのインターフェイスを提供します。Kafkaとの深い統合により、Kafkaエコシステムに既に投資している人々にとって魅力的な選択肢となっています。
これらのストリーミング優先のエンジンは、Kafkaデータを瞬時にクエリ可能にするために重要です。データが最近のものであろうと数日前のものであろうと、RisingWave、Flink、ksqlDBは、ストリーミングとバッチ処理の境界線がぼやけつつある中で、Kafkaが依然として重要な存在であり続けるための道を開いています。
結論: Kafkaの未来への道
Kafkaは岐路に立っています。クラウドネイティブなインフラ、S3のような安価なオブジェクトストレージ、新しいバッチインジェスチョンツールの登場により、データの風景は急速に変化しています。Kafkaは、この変化に追いつくために進化する必要があります。Warpstreamのようなコスト効率の良いソリューションの登場は、Kafkaのデプロイメントがより安価になる方向へシフトしていることを示しています。さらに、バッチ処理の世界に進出し、リアルタイムおよび履歴データのクエリをサポートすることが、Kafkaの将来における重要な課題となります。
この進化において重要なのは、RisingWave、Flink、ksqlDBのようなストリーミング優先のクエリエンジンです。これらの技術は、連続クエリとリアルタイムの洞察を実現するために先導しており、Kafkaはこれを完全に受け入れる必要があります。
これらのトレンドに適応すること—コスト削減、バッチ処理の統合、次世代クエリエンジンの採用—により、Kafkaは今後もモダンなデータインフラの中心であり続けることができます。