Redpanda: Kafka互換のストリーミングデータプラットフォーム

データベースは「現在の状態は何か？」に答え、Redpanda/Kafkaは「どんなイベントが起きて、誰がそれを処理すべきか？」に答えるためのものです。RedpandaはApache Kafkaと互換性のあるストリーミングデータプラットフォームで、C++でゼロから作り直され、より速く、より軽く、よりシンプルに運用できるよう設計されています。

歴史: VectorizedからRedpandaへ#

Redpandaの物語は2019年、Alex GallegoがVectorizedという会社を創業したことから始まります。彼の歩みはかなり特別です:

NYUでサイバーセキュリティを学び、その後FactSetで働き（そこでC++を習得）、YieldMoの最初のエンジニアになりましたが、Apache Stormのリアルタイム処理の限界に不満を感じていました
Concord Systemsを創業 — C++で書かれた高性能リアルタイム処理アプリケーションで、2016年にAkamaiが買収
AkamaiでKafkaより高性能なストレージエンジンを設計 — これがRedpandaの土台になりました

主なマイルストーン:

時期	出来事
2019	Vectorizedを創業
2020	ソースコードを公開し製品を発表
2021/01	$1,550万のSeed + Series A調達（Lightspeed主導、GV参加）
2021	社名をRedpandaに変更
2022/02	$5,000万のSeries B調達（GV主導）
2023/06	$1億のSeries C調達（Lightspeed主導）
2025/03	Kafka 4.0がZooKeeperを廃止しKRaftへ全面移行
2025/04	$1億のSeries D調達（GV主導）、評価額$ 10億

[!NOTE] Redpandaチームの設計思想は「60 seconds to WOW」です — クラスタ構築から実際のイベント処理まで60秒以内に収め、開発者が運用作業で足を止められないようにしています。

Kafkaが残した問題#

Kafka（2011年にLinkedInがオープンソース化）はストリーミングの業界標準ですが、その元々のアーキテクチャにはコストが伴います:

JVM: KafkaはScala/Javaで書かれJVM上で動作 — RAMを大量消費し、GCによるポーズがあり、多くのチューニングが必要
ZooKeeper: メタデータ管理のために別途ZooKeeperクラスタを運用する必要がある
テールレイテンシ: p99.999（99.999パーセンタイル）は高負荷時に数秒に劣化することがある
運用の複雑さ: コンポーネントや設定が多く、ハードウェアに最適化しづらい

Redpandaはこうした痛点を見据えてゼロから設計し直しました。

アーキテクチャ: ゼロからの再設計#

graph TB
    P[Producer / Kafka Client] --> B["Redpanda Broker<br/>(C++ · Seastar · JVMなし)"]
    B --> S["Partition<br/>(append-only log)"]
    B --> R["Raft Quorum<br/>(ZooKeeperの代替)"]
    S --> C[Consumer / Kafka Client]
    B --> T["Redpanda Console<br/>(管理UI)"]

Seastar上でC++で記述 — ScyllaDBの高性能フレームワークで、thread-per-coreモデル（CPUコアごとに専用スレッドを1本、コア間でメモリを共有しない）を採用
JVMもZooKeeperも不要 — メタデータはRaftプロトコルで自己管理（リーダー選出が速く、リソース消費が少ない）
シングルバイナリ + rpk CLI — Kafkaよりはるかに少ない構成要素でインストール・設定・運用が可能
Kafka API互換 — producer、consumer、Kafkaエコシステムの大部分はそのまま動作。多くの場合、brokerのエンドポイントを変更するだけ

パフォーマンス: なぜ10倍速いのか?#

テールレイテンシとは？（小学生にもわかる説明）#

p99.999が「リクエストの99.999%が閾値X以下で完了する」ことを意味するとします。100リクエストなら素晴らしく聞こえますが、1,000万リクエストなら、最遅の「テール」に1,000リクエストが残ります。その1,000件が数百万ドルの取引だったら許容できますか？だからこそテールレイテンシがストリーミングプラットフォームの品質を左右するのです。

ベンチマーク結果#

RedpandaはKafkaに対するp99.999のエンドツーエンドレイテンシ比較を公開しています（全レプリカへの書き込み完了後に応答するacks=allを使用）:

ワークロード	Kafka p99.999	Redpanda p99.999
10 MB/s（1万 msg/s）	215 ms	12 ms
40 MB/s（4万 msg/s）	103 ms	52 ms
50 MB/s（5万 msg/s）	236 ms	14 ms
75 MB/s（7.5万 msg/s）	1,801 ms	17 ms
100 MB/s（10万 msg/s）	1,725 ms	21 ms
200 MB/s（20万 msg/s）	1,945 ms	27 ms
0.5 GB/s（50万 msg/s）	3,015 ms	61 ms
1 GB/s（100万 msg/s）	3,840 ms	174 ms
1.25 GB/s（125万 msg/s）	3,797 ms	238 ms

9つのテストシナリオで、RedpandaはKafkaより196%〜10,847%高速でした — あるシナリオではKafkaが1.8秒かかったのに対し、Redpandaは16ミリ秒でした。

[!TIP] これはRedpanda自身が公開したベンチマークです — 批判的に読み、必ず自分のワークロードで計測してください。「10倍」は彼らの主張であり、絶対的な真実ではありません。

なぜ速いのか?#

Thread-per-core + shared-nothing: 各コアに1本のピン留めされたスレッド — ロックもコンテキストスイッチもない、まさにSeastarのモデル
ページキャッシュではなく独自のメモリ管理: Redpandaは各リクエストが読み書きするデータ量を正確に把握し、OSのページキャッシュに頼らず独自のDMAアラインキャッシュを使用
最新Linuxを活用: io_uring（非同期I/O）、O_DIRECT、DPDK（より効率的なパケット処理）
カーネル自動チューニング: rpk redpanda tune allとrpk iotuneがハードウェアをベンチマークして最適化設定を生成 — 手探り不要
Profile-Guided Optimization（PGO）は26.1以降: 同じハードウェアでp999レイテンシを最大47%削減、CPU使用率を15%改善
Write cachingは24.1以降: 耐久性の一部を犠牲にできる場合、レイテンシを最大90%削減

実世界のユースケース#

イベントストリーミング: サービス間でイベントを伝達（例: OrderCreated、PaymentCompleted、UserLoggedIn）
マイクロサービス: 非同期通信の「背骨」となり、サービス間の直接的な依存を減らす
リアルタイム分析: クリックストリーム、ログ、メトリクス、取引…を収集し、ほぼ即時の分析システムへ
データパイプライン: データベース/APIと、データウェアハウス・レイク・検索エンジンなどの下流システムの中間層
IoT: デバイスからの大量のテレメトリを受信し、処理システムへ配布
CDC（Change Data Capture）: PostgreSQL/MySQLの変更を取得し、他のシステムへストリーミング
AI/MLストリーミング: リアルタイムデータを処理パイプラインや推論へ供給

低レイテンシのおかげで、Redpandaはアルゴリズム取引、リアルタイムゲーミング、SIEM、レイテンシに敏感なIoTシステムでも使われています。

例: ECサイトのシステム#

graph LR
    Order["Order Service"] -->|publish| Topic["topic: orders"]
    Topic --> Payment["Payment Service"]
    Topic --> Inventory["Inventory Service"]
    Topic --> Analytics["Analytics"]
    Analytics --> Lake["Data Lake"]

Order Serviceが各サービスを直接呼び出す代わりに、1つのイベントをpublishするだけです:

{
  "order_id": 12345,
  "user_id": 789,
  "total": 599000,
  "status": "created"
}

json

Redpandaはこのイベントを保存し、多くのコンシューマへ配布します。Payment、Inventory、Analytics…はそれぞれ独立して処理します — 1つのサービスが遅くても、他のサービスには影響しません。

クイックスタート#

# DockerでRedpandaを起動
docker run -d --name redpanda -p 9092:9092 \
  docker.redpanda.com/redpandadata/redpanda:latest \
  redpanda start

# rpkでトピックを作成しproduce/consume
rpk topic create orders
rpk topic produce orders
rpk topic consume orders --group my-group

bash

既存のKafkaコードはそのまま動作します — brokerエンドポイントをRedpandaに向けるだけです。

エコシステム#

Redpanda Console: クラスタ管理、データパイプラインの確認、コマンドライン不要のデバッグを実現するUI
Schema Registry: イベントのスキーマ管理（Confluent互換）
Tiered storage: 古いデータをNVMeから安価なオブジェクトストレージへ自動的に移動
WASM transforms: WebAssemblyでリアルタイムデータ変換をbroker内で実行
Redpanda Cloud / BYOC: マネージド版、または自社クラウドにホスト
Kafka Connect互換: 既存のコネクタを再利用可能

RedpandaとKafka、どちらを選ぶ?#

基準	Redpanda	Kafka
テールレイテンシ	非常に低い（ms）	高負荷時は高い
フットプリント・運用	軽量、シングルバイナリ、ZooKeeper不要	重く、コンポーネントが多い
エコシステム	Kafka API互換	業界標準で最大
成熟度	新しい（2019年〜）	本番運用10年以上
ハードウェア資源	同じワークロードで少ない	JVMのため多くのRAMが必要

Kafkaを運用していてZooKeeper、JVMチューニング、テールレイテンシに悩んでいるなら、Redpandaは検討に値する「ドロップイン」置き換えです。最大のエコシステムと業界標準としての成熟度が必要なら、Kafkaは依然として非常に強力です。

まとめ#

Redpandaは、API互換性が古いアーキテクチャを受け継ぐことを意味しないことを証明しました。Kafka APIをSeastar上のC++で書き直し — JVMなし、ZooKeeperなし、thread-per-core — 既存のKafkaアプリケーションをそのまま動かしながら、劇的な低レイテンシとシンプルな運用を実現しています。