1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

IBM が Apache Kafka の商用企業である Confluent を 110 億ドルで買収することを発表しました

昨日、IBM が Apache Kafka の商用企業である Confluent を 110 億ドルで買収することを発表しました。データストリーミングの分野に長く関わってきた人にとって、この Confluent の買収は決して驚きではありません。噂は約 3 か月前から流れており、この領域の多くの人は「遅かれ早かれ何かが起きる」と見ていました。

昨日、私は数十人と話しましたが、コンセンサスは非常に明確でした。この買収は何かの終わりを意味するものではありません。すでに進行していた変化を加速させるものです。データ基盤全体は、生の配管(raw plumbing)から離れ、目に見える価値を提供するプロダクトへと上方向にシフトしています。

この変化は、次の 3 つのポイントに表れています。

  • 分析プラットフォームがインジェスチョンをどう扱っているか
  • Apache Iceberg が Kafka の役割をどう変えているか
  • そして Kafka 自身がどう進化せざるを得ないか、です。

1. 分析プラットフォームがインジェスチョン層を取りに来ている

主要な分析プラットフォームの動きを見てみましょう。どの大手分析ベンダーも、すでに、あるいは近いうちに、Kafka ライクで簡素化されたインジェスチョンサービスを持つようになります。最も分かりやすい例が Databricks ZerobusSnowflake Snowpipe Streaming です。

Databricks Zerobus.

Snowflake Snowpipe Streaming.

彼らが注力しているのはただ一つ、自分たちのプラットフォームにデータをストリーミングで取り込むことを簡単にすることです。両者ともバッファリング層を提供し、自社エコシステムに強く統合されています。そしてどちらも、汎用メッセージキューになろうとはしていません。

Databricks や Snowflake が MQ ビジネスに本気で参入し、Kafka と正面から戦う意欲があるとは思いません。彼らがやっているのはそこではありません。インジェスチョン周りの取りやすいユースケースを切り取っているのです。

もし企業が Kafka を「Databricks や Snowflake にデータを流し込むためだけ」に使っているのであれば、Zerobus や Snowpipe で十分です。むしろそのようなユーザーにとっては、こちらの方が明らかに優れています。可動部品は少なく、運用負荷は低く、何か壊れたときに連絡すべきベンダーも一社だけです。

つまり、これらのプラットフォームは Kafka の中核領域を攻めているわけではありません。Kafka が過剰でありながら十分に評価されていない「ライト Kafka」なユースケースを奪っているのです。

2. Iceberg の成長がデータインジェスチョン市場に影響を与えている

Apache Iceberg は、インジェスチョンに対する期待値を静かに変えつつあります。Iceberg を主要なテーブルフォーマットとして採用する組織が増えるにつれ、ある興味深いパターンが見えてきました。必ずしも Kafka のデカップリング能力を必要としていないのです。

Kafka の最大のアーキテクチャ上の利点は明確です。プロデューサーとコンシューマーを分離できること。1 つのストリームから、異なるチームが所有し、それぞれのペースで進化する複数の下流システムへとデータを配信できます。

しかし、アーキテクチャが違ったらどうでしょうか?

組織がデータを送る先を ただ一か所、Iceberg に決めているとしたら? Iceberg を中心のストレージ層として使い、SparkTrinoDuckDB など、さまざまなエンジンがそこから読み取る、という形です。

この世界では、Kafka は重く見えてきます。運用コストがかかり、別のスキルセットが必要になり、管理すべきシステムが一つ増えます。要件が「イベントを確実に Iceberg に取り込み、小さなファイルをコンパクションし、テーブルを健全に保つ」だけであれば、フルスペックの分散ログが常に最適とは限りません。

そのため、Iceberg に特化したインジェスチョンツールへの需要が高まっています。

  • セットアップが簡単
  • 一般的なデータソースから取り込める
  • 小さなファイル、バッチング、コンパクションを前提に設計されている
  • 単なるバイト転送ではなく、テーブル操作と統合されている

RisingWave は、まさにこのギャップに位置しています。イベントを継続的に取り込み、SQL で変換し、適切なファイルレイアウトとコンパクションを備えた Iceberg テーブルを書き出せます。多くの Iceberg ユーザーにとって、これがちょうどよい抽象化です。Kafka のことを考えたいのではなく、テーブルを健全かつ最新の状態に保ちたいのです。

RisingWave’s Iceberg story.

RisingWave’s Iceberg story.

これは Kafka という技術への否定ではありません。トポロジーが変わったという認識です。Iceberg がハブになると、インジェスチョン問題の形そのものが変わります。

3. Kafka は残るが、その役割は変わらなければならない

もちろん、これで Kafka が消えるわけではありません。複雑な環境では、Kafka は依然として第一の選択肢です。

数十、数百のマイクロサービスがあり、複数のチームと多様な下流システムが存在するアーキテクチャでは、Kafka に匹敵するものはなかなかありません。高いファンアウト、マルチテナント、マルチチームの通信には、今後も適切なツールです。

ただし、Kafka が戦略的に重要であり続けるためには、価値のレイヤーを上に引き上げる必要があります。単なる「真ん中のメッセージバス」ではもはや不十分です。その位置づけは、Amazon MSK や Kinesis のようなマネージド Kafka 互換サービスが登場する中で、急速にコモディティ化しています。そこに第三者ベンダーが挑むのは、ほぼ負け戦です。

Kafka が成長できる余地があるのは、外部向け・インターネット向けのインジェスチョンです。

  • 公開 API、ソーシャルメディア、SaaS、金融市場などからのデータ取り込みを劇的に簡単にする
  • トピックやパーティションではなく、アプリケーション指向のワークフローとしてインジェスチョンを包む
  • ストリームを、組み立てが必要な生の配管ではなく、すぐ使えるアプリケーション部品にする

Kafka が「ただのログ」であり続ければ、コモディティ層に押し下げられます。ビジネス価値が実現される場所に近づければ、関連性を保てます。

4. Flink とそのエコシステムは、もはや「Kafka の友達」ではない

もう一つ見過ごされがちな動きがあります。Kafka の競争相手は、もはや「他の MQ」だけではありません。ストリーム処理エコシステム全体がインジェスチョン領域に踏み込んでいるのです。

Flink 周辺を見てみましょう。Flink CDCFlussPaimon は、従来 Kafka が担ってきた価値の一部を狙っています。

  • Flink CDC は変更データキャプチャを簡素化する
  • Fluss は Flink エコシステム内でのログストレージとストリーミングインジェスチョンを扱う
  • Paimon はストリーミングワークロードに密接に結びついたテーブルフォーマットとストレージ抽象を提供する

これらのプロジェクトにより、アーキテクチャによっては 別途 Kafka クラスターを持つ必要がなくなります。処理・ストレージ・インジェスチョンが強く統合されたストリーミングパイプラインを構築できるからです。

しかし Confluent 自身は、Flink を Kafka のアドオンとして販売しており、単体製品としては提供していません。短期的には Kafka ファースト戦略と整合しますが、長期的には緊張を孕んでいます。Flink と Kafka のカバー領域が重なり始めており、もはや純粋に補完関係ではなく、場合によっては競合関係にあるからです。

Flink を Kafka の付属品としてしか売らないモデルは、他でより統合されたソリューションが手に入る状況では、長くは続きません。

5. 「インフラを売るだけ」の時代は終わった

ここから得られる最も明確な教訓は、生のデータ基盤を売るだけではもはや足りないということです。

Amazon MSK や Kinesis と「Kafka クラスターを運用します」というレイヤーで競うのは極めて困難です。オープンソースに薄くマネージドを被せただけの「X を動かします」型プロダクトも同様です。市場はすでに次の段階に進んでいます。

AI 時代に成長するのは、直接的で目に見える価値を提供するプロダクトです。

  • 複雑さを露出させるのではなく、隠蔽するもの
  • API ではなく、答えをチームに与えるもの
  • 5 つのツールをつなぎ合わせなくても、アイデアから本番まで持っていけるもの

これが「価値レイヤーを上げる」ということの本質です。マーケティング用語ではありません。生き残りの条件です。

結論

この視点で見ると、Confluent の買収は多方面でポジティブな結果です。Confluent の株主にとって良いのは明らかですし、エコシステム全体にとっても、次の現実を突きつける点で有益です。

  • 純粋なインフラとしての Kafka はコモディティ化している
  • インジェスチョンは分析プラットフォームや Iceberg のようなテーブルフォーマットに引き寄せられている
  • ストリーム処理システムが従来の MQ の役割に侵食している
  • ベンダーは「配管」を売るのではなく、意図を持ったワークフローとビジネス価値を体現するプロダクトを作らなければならない

業界の変化は、多くの人が予想していたよりも速く進んでいます。データストリーミング、データレイク、AI は新しいスタックへと収束し、従来の境界線はリアルタイムで引き直されています。

Confluent の買収は Kafka の終わりではありません。シグナルです。次のデータ基盤のフェーズは、A から B にバイトを運ぶ能力ではなく、ストリームを価値に変えられるかどうかで決まる、ということを示しています。

だからこそ、今この分野で働くのは、とても面白い時代なのです。

1
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?