Kafka代替が急成長——Redpanda・WarpStreamが変えるリアルタイムデータ基盤

Apache Kafkaは過去10年間、リアルタイムデータストリーミングのデファクトスタンダードとして君臨してきた。LinkedIn で生まれ、Confluent が商用展開し、今やFortune 500企業の80%以上が利用するインフラだ。しかし2026年、Kafkaの支配は揺らぎ始めている。

C++で書き直したRedpandaはp99レイテンシを7.5倍高速化し、オブジェクトストレージに直接書き込むWarpStreamはコストを80%削減した。さらにストリーミングSQLを統合したTimeplusが、データパイプラインの複雑性を大幅に削減している。本記事では、Kafka代替プラットフォームの技術的特徴と選定基準を深掘りする。

なぜKafka代替が注目されるのか

Apache Kafka自体は優れたソフトウェアだが、運用上の課題が多い。

JVMのオーバーヘッド: KafkaはJava/Scalaで書かれており、JVMのガベージコレクション（GC）がテールレイテンシの原因になる。GCが発生すると、p99レイテンシが数十ミリ秒に跳ね上がる。金融取引やリアルタイム入札のように、一貫した低レイテンシが求められるユースケースでは致命的だ。

ZooKeeper依存（KRaft移行中）: Kafkaは長年ZooKeeperに依存してきた。KRaft（Kafka Raft）への移行が進んでいるが、完全移行には時間がかかり、既存クラスタの運用負荷は依然として高い。

コスト: Kafka クラスタの運用には、ブローカーサーバー、ディスクストレージ、ネットワーク帯域、そして運用エンジニアの人件費が必要。中規模クラスタでも月額**$50,000〜100,000**のインフラコストがかかる。

以下の図は、従来型Kafkaと次世代プラットフォームのアーキテクチャとレイテンシ比較を示しています。

Redpanda——C++で書き直したKafka互換プラットフォーム

Redpandaは2019年創業、累計調達額**$276M**のスタートアップだ。Kafka の API プロトコルに完全互換でありながら、内部実装をC++でスクラッチから書き直している。

技術的特徴

ZooKeeper不要: Raftベースの合意プロトコルを内蔵し、外部の依存コンポーネントが不要。バイナリ1つをデプロイするだけでクラスタが構成できる。

スレッドパーコア: Seastar フレームワーク（ScyllaDB でも使用）を採用し、各CPUコアに専用スレッドを割り当てる。コンテキストスイッチやロック競合を最小化し、予測可能な低レイテンシを実現する。

JVM不要: C++ネイティブのため、GCによるテールレイテンシの揺れがない。p99レイテンシは4ms以下で安定し、Kafkaの30msと比較して7.5倍高速。

ベンチマーク結果

Redpandaが公開した2026年のベンチマーク（同一ハードウェア条件）では以下の結果が報告されている。

指標	Apache Kafka	Redpanda	差
p99レイテンシ	30ms	4ms	7.5x高速
スループット	800MB/s	1.2GB/s	1.5x高速
メモリ使用量	8GB/ブローカー	2GB/ブローカー	75%削減
ディスクIO	高（ページキャッシュ依存）	低（DIO）	大幅削減
運用コスト	基準	-60%	6x低コスト

WarpStream——Confluent買収のゼロディスクKafka

WarpStreamは2023年創業、2025年にConfluentが買収したKafka互換プラットフォームだ。最大の特徴は**「ゼロディスク」アーキテクチャ**——ブローカーが持つローカルディスクを完全に排除し、データをS3（オブジェクトストレージ）に直接書き込む。

なぜゼロディスクが革命的なのか

従来のKafkaクラスタでは、ブローカーにアタッチされたEBSボリュームやローカルSSDがコストの大部分を占める。WarpStreamはこれを排除し、データの永続化をS3に任せることで、インフラコストを80%削減した。

ブローカーはステートレスになるため、オートスケーリングが容易になる。トラフィック急増時にブローカーを追加し、不要になれば即座に削除できる。ディスクの再バランシングも不要だ。

トレードオフ

S3への書き込みは、ローカルディスクより遅延が大きい。WarpStreamのレイテンシはp99で約15msと、Kafkaと同等レベル。Redpandaほどの低レイテンシは実現できないが、コスト重視のユースケースでは最適解だ。

Timeplus——ストリーミングSQL統合プラットフォーム

Timeplusは「ストリーミングデータの取り込み・処理・分析を1つのプラットフォームで完結させる」というビジョンのプロダクトだ。従来、Kafka + Flink + ClickHouse のように3つのコンポーネントで実現していたリアルタイム分析を、Timeplus 1つで代替する。

SQLでストリーミングデータに対するクエリを記述でき、ウィンドウ集計、JOIN、サブクエリなどの標準SQL構文がリアルタイムデータに対して動作する。

主要プレイヤー比較

以下の図は、主要リアルタイムデータ基盤の比較を示しています。

比較項目	Confluent Kafka	Redpanda	WarpStream	Timeplus
実装言語	Java/Scala	C++	Go	C++
ZooKeeper	KRaft移行中	不要	不要	N/A
Kafka互換	ネイティブ	完全互換	完全互換	Kafka Source対応
p99レイテンシ	30ms	4ms	15ms	10ms
ストレージ	ローカルディスク	ローカル+Tiered	S3直接	内蔵
運用負荷	高	低	最低	低
コスト	基準	-60%	-80%	別カテゴリ
エコシステム	最大（Connect, ksqlDB）	成長中	Confluent統合	成長中
マネージドサービス	Confluent Cloud	Redpanda Cloud	Confluent Cloud	Timeplus Cloud

選定ガイド

Redpandaが最適なケース: 低レイテンシが最重要（FinTech、リアルタイム入札、IoT）、Kafka運用負荷を下げたい、JVMのGC問題に悩んでいる

WarpStreamが最適なケース: コスト削減が最優先、大量データの長期保持が必要、レイテンシ15ms程度で許容可能

Timeplusが最適なケース: リアルタイム分析がメインユースケース、Kafka + Flink + ClickHouseの複雑性を解消したい、SQLベースで統一したい

日本ではどうなるか

日本でもKafkaは広く使われているが、代替プラットフォームの認知はまだ低い。

国内のKafka利用状況: メルカリ、LINE（LY Corporation）、楽天、Yahoo! JAPAN などのテック企業がKafkaを大規模に運用している。しかし運用負荷とコストの課題は日本でも同様で、特にSREエンジニアの不足が深刻な日本では、運用がシンプルなRedpandaへの関心が高まっている。

クラウドマネージドの選択: AWSのMSK（Managed Streaming for Apache Kafka）やGoogle CloudのManaged Kafka を利用する企業も多い。これらはKafkaの運用負荷を軽減するが、コストは依然として高い。WarpStreamのS3直接書き込みモデルは、AWSのS3コストが安い日本リージョンでは特に魅力的だ。

Dockerでのローカル検証: Redpandaは単一バイナリで動作するため、Dockerでのローカル開発が非常に簡単。docker run -p 9092:9092 redpandadata/redpanda の1コマンドで起動でき、Kafka互換のため既存のクライアントライブラリがそのまま使える。

日本語情報の充実度: Redpandaの日本語ドキュメントは限定的だが、Kafkaと互換のためKafkaの日本語資料がほぼそのまま活用できる。日本のデータエンジニアリングコミュニティ（Data Engineering Study等）でもRedpandaの検証事例が共有され始めている。

まとめ：リアルタイムデータ基盤の選定アクションステップ

1. 現行Kafkaクラスタの課題を定量化する: p99レイテンシ、月間インフラコスト、運用工数（人月）を計測する。これらの数値が「許容範囲」なら移行の優先度は低い。「問題あり」なら具体的な代替候補を検討する

2. ユースケースに基づいて候補を絞る: レイテンシ重視→Redpanda、コスト重視→WarpStream、分析統合→Timeplus。ユースケースが混在する場合は、Redpandaが最もバランスが良い

3. Kafka互換性をPoCで検証する: Redpanda・WarpStreamはKafka互換を謳うが、全てのKafkaクライアントライブラリとの互換性を自社環境で検証する。特にKafka Connectのコネクタ互換性は要確認

4. 段階的に移行する: 全クラスタを一度に移行するのではなく、最もメリットの大きいワークロードから段階的に移行する。移行期間中はKafkaとの並行運用になるため、データの整合性検証の仕組みを構築する