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のログ構造は、この文脈において完璧に適していました。しかし、現在その基本的な使用ケースは変わらないものの、周囲のインフラ、アプリケーション、データスタックは急速に進化しています。この進化はKafkaに新たな課題と機会をもたらし、現代のデータアーキテクチャからの新しい要求に対応しなければならない状況です。
いくつかの重要な変化
- 多様な遅延要件：現代のシステムに対する遅延の期待は、より極端に分かれるようになっています。金融サービスでは、株式取引においてマイクロ秒単位の遅延が要求されますが、ログ収集やオペレーショナルデータベースと分析システム間のデータ同期といった他の用途では、数秒単位の遅延でも問題ありません。すべてに対応できる一つのソリューションはもはや機能しません。なぜ、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のコストを引き下げている他の企業です：
| 企業 | 説明 |
|---|---|
| Aiven | スケーラビリティと柔軟性を確保したオープンソースKafkaホスティングを提供 |
| Buf | Protobuf優先のKafkaとAPIを専門とし、通信とデータシリアル化を強化 |
| Confluent | コスト効率とエンタープライズ規模のスケーラビリティに重点を置いたKafkaの管理サービスを提供 |
| NATS | クラウドネイティブアプリ、IoT、マイクロサービス向けの軽量で安全、高性能なデータレイヤ |
| Redpanda | シンプルで高性能なKafka互換のコスト効果の高い代替システム |
| StreamNative | スケーラビリティ、パフォーマンス、最適化されたコスト効率を備えたKafka互換プラットフォーム |
| WarpStream | S3ベースのストレージを使用してKafka互換のシステムを提供し、コストを劇的に削減 |
Kafkaの運用コストは必然的に10倍安くなるでしょう。特に、Kafkaをログ収集やシステムの分離のためにのみ使用するユーザーにとっては、S3を主なストレージ層として採用するアーキテクチャは明らかな勝利であり、高価なローカルディスクの必要性を排除することでコストを削減できます。
Kafkaはバッチ処理の世界に進出する必要がある
Kafkaは常にリアルタイムストリーミングのための主要なツールでしたが、現在では、Kafkaがその役割を拡大してバッチ処理も扱う必要があることが明らかです。この機会は巨大ですが、同時に脅威も存在します。データウェアハウスや分析データベースはますます自分たちで取り込みツールを構築しており、ユーザーはデータの移動のために必ずしもKafkaを必要としなくなっています。
| データウェアハウス / 分析システム | 取り込みツール | 説明 |
|---|---|---|
| Amazon Redshift | noETL | Kafkaを使用せず、Redshiftへのストリーミングデータの取り込みを簡素化 |
| ClickHouse | PeerDB | Kafkaをバイパスして、運用データベースから直接取り込み |
| Snowflake | Snowpipe | リアルタイムデータの取り込みを実現し、データの移動に対する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エコシステムに既に投資している人々にとって魅力的な選択肢となっています。
| 技術 | 説明 | 主な特徴 | 使用例 |
|---|---|---|---|
| Flink | イベント駆動型アプリケーションをサポートする分散ストリーム処理フレームワーク。 | 真のストリーム処理（イベントごとの処理）、低遅延、正確に一度だけのセマンティクス、耐障害性。 | リアルタイムデータパイプライン、低遅延のイベント駆動型アプリケーション、有状態ストリーム処理。 |
| ksqlDB | KafkaのためのストリーミングSQLエンジンで、Kafkaストリームに対するリアルタイムクエリを可能にする。 | Kafkaストリーム用のSQLインターフェイス、Kafkaとの直接統合、リアルタイムおよび履歴クエリをサポート。 | Kafkaのリアルタイムデータ処理、ストリーム変換、イベント駆動型マイクロサービス。 |
| RisingWave | イベントストリーム上でリアルタイムクエリを実行するために設計されたストリーミングSQLエンジン。 | SQLベース、スケーラブル、クラウドネイティブ、SQLによるストリーム処理の簡素化に焦点を当てている。 | リアルタイム分析、ストリーミングSQLクエリ、継続的なデータ統合、特徴量エンジニアリング。 |
| Spark Streaming | Apache Sparkの上に構築されたマイクロバッチストリーム処理エンジン。 | Sparkのバッチエンジンとの統合、耐障害性、スケーラブル。マイクロバッチを通じてリアルタイムおよびバッチ処理をサポート。 | リアルタイム分析、ETLパイプライン、ストリーミングデータ上での機械学習。 |
これらのストリーミング優先のエンジンは、Kafkaデータを瞬時にクエリ可能にするために重要です。データが最近のものであろうと数日前のものであろうと、RisingWave、Flink、ksqlDBは、ストリーミングとバッチ処理の境界線がぼやけつつある中で、Kafkaが依然として重要な存在であり続けるための道を開いています。
結論: Kafkaの未来への道
Kafkaは岐路に立っています。クラウドネイティブなインフラ、S3のような安価なオブジェクトストレージ、新しいバッチインジェスチョンツールの登場により、データの風景は急速に変化しています。Kafkaは、この変化に追いつくために進化する必要があります。Warpstreamのようなコスト効率の良いソリューションの登場は、Kafkaのデプロイメントがより安価になる方向へシフトしていることを示しています。さらに、バッチ処理の世界に進出し、リアルタイムおよび履歴データのクエリをサポートすることが、Kafkaの将来における重要な課題となります。
この進化において重要なのは、RisingWave、Flink、ksqlDBのようなストリーミング優先のクエリエンジンです。これらの技術は、連続クエリとリアルタイムの洞察を実現するために先導しており、Kafkaはこれを完全に受け入れる必要があります。
これらのトレンドに適応すること—コスト削減、バッチ処理の統合、次世代クエリエンジンの採用—により、Kafkaは今後もモダンなデータインフラの中心であり続けることができます。