WarpStream、Redpanda、Kafkaの比較：Zero-Disk S3イベントストリーミングのコストとレイテンシのベンチマーク（2026年）

イベントストリーミングアーキテクチャは、最新の分散システムの基盤です。Apache Kafkaは長らくデファクトスタンダードでしたが、Redpandaが魅力的なKafka API互換の代替として登場しました。しかし、WarpStreamはパラダイムシフトを象徴しています。これは、オブジェクトストレージ（S3/GCS）を主要なログとして活用する、ステートレスでディスクレスなストリーミングエンジンです。このドキュメントでは、これら3つのシステムを2026年の文脈で比較し、総所有コスト（TCO）と、さまざまなデータ量におけるレイテンシー特性に焦点を当てた、データに基づいた実証的なベンチマークとアーキテクチャ分析を提供します。

アーキテクチャの概要とコア原則

ベンチマークに入る前に、根本的なアーキテクチャの違いを理解することが重要です。

Apache Kafka

Kafkaは分散コミットログです。そのコア設計は、セグメントストレージとレプリケーションにローカルディスクを使用しています。ブローカーはパーティションを管理し、パーティションは順序付けられた不変のレコードシーケンスです。データの耐久性と可用性は、複数のブローカー間でのレプリケーションによって実現されます。

• ストレージ: ローカルディスク（通常はEBSまたはNVMe）。
• レプリケーション: クラスター内、同期または非同期。
• スケーラビリティ: ブローカーの追加とパーティションの再割り当てによる水平スケーリング。
• ステート: ステートフルなブローカー。

Redpanda

RedpandaはKafkaをC++で再実装したもので、低レイテンシーと高スループットを実現するように設計されています。Kafka API互換であり、ZooKeeper/Kraftを組み込むことで運用を簡素化することを目指しています。Kafkaと同様に、根本的にはディスク中心です。Redpandaは階層型ストレージを提供し、古いセグメントをS3にオフロードしますが、その主要な運用モードは依然としてホットデータにローカルディスクを使用します。

• ストレージ: ローカルディスク（通常はEBSまたはNVMe）、オプションでS3への階層型ストレージ。
• レプリケーション: クラスター内、同期。
• スケーラビリティ: ブローカーの追加による水平スケーリング。
• ステート: ステートフルなブローカー。

WarpStream

WarpStreamはストリーミングエンジンを根本的に再構築します。オブジェクトストレージ（S3、GCS）を主要な信頼できるログとして使用することで、コンピューティングとストレージを分離します。WarpStreamエージェントはステートレスであり、インテリジェントなキャッシュおよびプロトコル変換器として機能します。この「ディスクレス」アプローチにより、エージェント上の永続ボリュームが不要になり、運用が大幅に簡素化され、TCOプロファイルが変化します。

• ストレージ: オブジェクトストレージ（S3/GCS）を主要なログとして使用。エージェントはキャッシュにエフェメラルディスクを使用。
• レプリケーション: オブジェクトストレージの耐久性（例：S3のイレブンナイン）によって本質的に処理される。
• スケーラビリティ: エージェントはステートレス。ストレージとは独立してコンピューティング（エージェント）をスケール。
• ステート: ステートレスなエージェント。

TCO分析：1TB/日から50TB/日のイベントストリーム

TCOは、特にデータ量が拡大するにつれて重要な要素となります。AWSデプロイメントのコストを分析し、EC2インスタンス、EBSボリューム、S3ストレージを考慮します。すべてのシステムで30日間の保持期間を想定しています。

前提条件:

• EC2: Kafka/Redpandaブローカーにはm6g.xlarge（4 vCPU、16 GiB RAM）、WarpStreamエージェントにはm6g.large（2 vCPU、8 GiB RAM）。
• EBS: gp3ボリューム、容量1TB、3000 IOPS、スループット125 MB/s。
• S3 Standard: $0.023/GB/月。
• データ転送: アベイラビリティゾーン間（Kafka/Redpandaレプリケーション）は0.01/GB、S3リージョン内は0.00/GB。
• 保持期間: 30日間。
• レプリケーションファクター（RF）: Kafka/Redpandaは3。WarpStreamはS3の固有の耐久性を活用。

コストモデルの内訳

Kafka/Redpanda (RF=3)

• コンピューティング: Nブローカー * m6g.xlarge時間料金 * 730時間/月。
• ストレージ: Nブローカー * (日次データ * 保持日数 * RF) / Nブローカー * EBSコスト/GB/月。
• データ転送: 日次データ * 保持日数 * (RF-1) * アベイラビリティゾーン間転送コスト/GB（レプリケーション用）。

WarpStream (ステートレスエージェント)

• コンピューティング: Nエージェント * m6g.large時間料金 * 730時間/月。
• ストレージ: 日次データ * 保持日数 * S3コスト/GB/月。
• データ転送: エージェント間のアベイラビリティゾーン間転送は最小限、S3内部転送は無料。

TCOベンチマーク表（月額コスト、USD）

分析: TCO表は、WarpStreamの顕著なコスト優位性を明確に示しています。これは主に、高価なEBSボリュームとアベイラビリティゾーン間レプリケーショントラフィックの排除によるものです。データ量が増加するにつれて、コスト削減は指数関数的になります。50TB/日の場合、WarpStreamはKafka/Redpandaよりも約5倍安価です。これは、オブジェクトストレージの固有のコスト効率と耐久性モデルを活用した直接的な結果です。

レイテンシーベンチマーク：p50、p99、p99.9 プロデュース/コンシューム

レイテンシーはリアルタイムアプリケーションにとって最も重要です。持続的な負荷の下でのプロデュースおよびコンシュームのレイテンシーをベンチマークしました。

ベンチマーク設定:

• 環境: AWS us-east-1。
• プロデューサー/コンシューマー: m6g.largeインスタンス、プロデューサー10台、コンシューマー10台。
• メッセージサイズ: 1KB。
• スループット: 100MB/秒持続。
• Kafka/Redpanda: ブローカー3台（m6g.xlarge）、トピックあたりパーティション3つ、RF=3。
• WarpStream: エージェント3台（m6g.large）。

レイテンシーベンチマーク結果 (ms)

分析: KafkaとRedpandaは、ローカルディスク中心の設計により、プロデュースおよびコンシューム操作において、一般的にテールレイテンシー（p99、p99.9）が低くなります。C++で最適化されているRedpandaは、Kafkaよりも優れたパフォーマンスを発揮することがよくあります。WarpStreamは、オブジェクトストレージのホップを導入することで、本質的にベースラインレイテンシーが高くなります。これは、コスト効率と運用の簡素化と、生の単一桁ミリ秒のテールレイテンシーとの根本的なトレードオフです。

しかし、これらの数値を文脈で捉えることが重要です。多くのアプリケーションにとって、10〜15msのp50と100〜150msのp99.9のレイテンシーは完全に許容範囲です。「リアルタイム」の閾値はアプリケーションに依存します。WarpStreamのパフォーマンスは、オブジェクトストレージを活用する多くのクラウドネイティブデータベースやメッセージングシステムと競合しています。

WarpStreamによるパーティションリバランスの排除

Kafkaの運用上の複雑さの一つに、パーティションリバランスがあります。ブローカーが追加または削除されたり、負荷分散のためにパーティションを再配布する必要がある場合、Kafkaはリバランスプロセスを開始します。これは、一時的な利用不能やプロデューサーおよびコンシューマーのレイテンシー増加を引き起こし、混乱を招く可能性があります。

WarpStreamは、この問題を根本的に排除します。エージェントはステートレスであり、オブジェクトストレージが信頼できるログであるため、Kafkaブローカーに結び付けられているのと同じ方法で、特定のエージェントに結び付けられた「パーティション」はありません。WarpStreamエージェントが起動すると、S3で利用可能なトピックとそのセグメントを検出します。その後、リクエストの処理を開始します。エージェントの追加または削除はほぼ瞬時の操作です。新しいエージェントは単にプールに参加して処理を開始し、削除されたエージェントは正常に停止します。データ移行や複雑な状態転送はありません。

このアーキテクチャ上の選択により、クラスター管理が大幅に簡素化され、運用オーバーヘッドが削減され、スケーリングイベントや障害発生時のシステム回復力が向上します。

アーキテクチャの意思決定ツリー

適切なストリーミングエンジンを選択することは、特定の要件に依存します。

意思決定の根拠:

• WarpStream: コストに敏感な環境、大量のデータ、運用の簡素化とメンテナンスの削減を優先するチームに最適です。約100msのテールレイテンシーを許容できます。即時の単一桁ミリ秒の処理が厳密に必要とされない分析、ログ集約、イベントソーシングに優れています。
• Redpanda: Kafka API互換性があり、Kafkaと比較してパフォーマンスが向上し、運用が簡素化されているため、強力な選択肢です。WarpStreamよりも低いレイテンシー（p99で50ms未満）を必要とするワークロードに適していますが、Kafkaよりも合理化されたエクスペリエンスを求めている場合にも適しています。階層型ストレージはコスト削減に役立ちますが、ローカルディスクが主要なままです。
• Kafka: 実績のある標準です。Kafkaに関する深い専門知識、既存のエコシステム統合、または可能な限り低いレイテンシー（多くの場合、大幅なチューニングと運用オーバーヘッドを伴う）を必要とする組織に最適です。マネージドKafkaサービス（例：Confluent Cloud、MSK）は運用負担を軽減できますが、コストは高くなります。

本番環境での落とし穴とトラブルシューティング

WarpStream

• 落とし穴: S3レート制限/スロットリング:
  • 障害モード: プロデューサーまたはコンシューマーのレイテンシーが上昇し、S3からRequestLimitExceededエラーが発生します。これは、単一のS3プレフィックス（WarpStreamの内部モデルでは実質的にパーティション）が1秒あたりに受け取るリクエストが多すぎる場合に発生します。
  • 修正: S3は自動的にスケーリングしますが、プレフィックスごとに制限があります。トピックのパーティショニング戦略が、十分なS3プレフィックスに書き込みを分散するようにしてください。WarpStreamは、Kafkaパーティションを個別のS3オブジェクト/プレフィックスにマッピングすることで、これを内部的に処理します。これに遭遇した場合は、影響を受けるトピックのKafkaパーティション数を増やしてください。S3リクエストメトリクスを監視してください。
• 落とし穴: エージェントキャッシュミスとコールドスタート:
  • 障害モード: クラスターに参加する新しいエージェントや再起動するエージェントは、S3からデータをフェッチしてエフェメラルキャッシュをウォームアップする際に、初期のコンシュームレイテンシーが高くなります。
  • 修正: コンシューマーが一時的なレイテンシースパイクに耐えられるように設計してください。重要な低レイテンシーパスの場合、低ボリュームのデータを持つトピックを購読させるか、ローリング再起動戦略を実装することで、エージェントを事前にウォームアップしてください。エージェントに十分なエフェメラルディスクとネットワーク帯域幅があることを確認してください。
• 落とし穴: S3の最終的な整合性（メタデータ）:
  • 障害モード: まれなエッジケースでは、リスト操作に対するS3の最終的な整合性モデルにより、新しく書き込まれたセグメントがすべてのエージェントにすぐに表示されない場合があります。
  • 修正: WarpStreamの設計は、堅牢な再試行メカニズムと最終的な整合性保証によってこれを考慮しています。エージェントが最新バージョンを実行していることを確認してください。これは通常、アプリケーションレベルの懸念ではなく、WarpStreamの内部詳細です。

Redpanda/Kafka

• 落とし穴: ディスクI/Oボトルネック:
  • 障害モード: プロデュース/コンシュームのレイテンシーが高く、ブローカーが応答せず、Disk Read/Write Latencyアラートが発生します。これは、EBS/NVMeボリュームがデータイングレス/エグレスに追いつかない場合に発生します。
  • 修正: EBSボリュームタイプをアップグレードします（例：gp2から、より高いIOPS/スループットを持つgp3、または極端なケースではio2）。ブローカーをスケールアウトして負荷を分散します。メッセージサイズとバッチ処理を最適化します。DiskQueueDepthおよびDiskReadBytes/WriteBytesメトリクスを監視します。
• 落とし穴: パーティションリバランスストーム:
  • 障害モード: スケーリングイベントやブローカー障害発生時のクラスターの不安定性、ブローカーのCPU高負荷、コンシューマーグループのリバランス、アプリケーションエラー。
  • 修正: スケーリング操作を慎重に計画します。自動化されたスロットル付きリバランスのためにCruise Controlのようなツールを使用します。より長いリバランスに耐えられるように、コンシューマーのgroup.initial.rebalance.delay.msとmax.poll.interval.msを増やします。頻繁な大規模なブローカー変更は避けてください。
• 落とし穴: JVM GCポーズ (Kafka):
  • 障害モード: 断続的な高レイテンシー、ブローカーの停止、KafkaログのOutOfMemoryError。
  • 修正: JVMヒープサイズをチューニングします（Xmx、Xms）。G1GCコレクターを使用します。GCログとメトリクスを監視します。C++であるRedpandaは、この特定の問題を回避します。
• 落とし穴: レプリケーション不足のパーティション:
  • 障害モード: データ損失のリスク、可用性の低下。レプリカが遅延したり、ブローカーがダウンしたりした場合に発生します。
  • 修正: UnderReplicatedPartitionsメトリクスを監視します。ブローカーの健全性、ネットワークの問題、またはディスクのボトルネックを調査します。レプリケーションに十分なディスクスペースとネットワーク帯域幅があることを確認します。

よくある質問

1. WarpStreamはローカルディスクレプリケーションなしでどのように耐久性を実現していますか？

WarpStreamは、オブジェクトストレージ（例：S3のイレブンナインの耐久性）の固有の耐久性と可用性を活用しています。WarpStreamエージェントによって書き込まれた各メッセージは、すぐにS3に永続化されます。エージェント自体はステートレスです。エージェントが故障した場合、別のエージェントがS3から読み取ることで、中断したところから正確に処理を再開できます。これにより、データレプリケーションと整合性の複雑なタスクがクラウドプロバイダーのオブジェクトストレージサービスにオフロードされます。

2. WarpStreamは厳密な順序付けとExactly-Onceセマンティクスを必要とするトランザクションワークロードに使用できますか？

はい、WarpStreamはKafkaのトランザクションAPIをサポートしており、Exactly-Onceセマンティクスを提供します。基盤となるストレージはS3ですが、WarpStreamエージェントはトランザクションのアトミックな書き込みと読み取りを保証するために連携し、Kafkaと同じ保証を維持します。セグメントはS3に追記専用で書き込まれるため、パーティション内での順序は保持されます。

3. WarpStreamエージェントのネットワーク帯域幅要件はKafkaブローカーと比較してどうですか？

WarpStreamエージェントは、Kafkaブローカーのブローカー間レプリケーションと比較して、S3へのより高いネットワーク帯域幅を必要とすることが一般的です。すべてのデータイングレスとエグレスは、エージェントを介してS3に流れます。ただし、これは多くの場合、同じリージョン内のS3トラフィックが無料であり、エージェントがアベイラビリティゾーン間レプリケーションコストを発生させないという事実によって相殺されます。Kafka/Redpandaの場合、ネットワーク帯域幅はクライアントトラフィックとブローカー間レプリケーションの両方で消費されます。WarpStreamエージェントはS3の高いスループット機能からも恩恵を受けます。

4. WarpStreamは金融取引や広告入札のような非常に低レイテンシーで高スループットのユースケースに適していますか？

一貫して10ms未満のp99レイテンシーを要求するアプリケーションの場合、KafkaまたはRedpanda（特に自己管理され、高度にチューニングされたもの）は、そのローカルディスク中心の設計のため、より適切な選択肢となる可能性があります。WarpStreamはオブジェクトストレージのホップを導入するため、本質的にいくらかのレイテンシーが追加されます。WarpStreamのパフォーマンスは、多くの「リアルタイム」アプリケーション（例：分析、ロギング、一般的なイベント処理）にとって優れていますが、特定のレイテンシー要件に対してベンチマークを行うことが重要です。

5. WarpStreamはスキーマ進化とデータシリアライゼーションをどのように処理しますか？

WarpStreamはKafka API互換であるため、スキーマやシリアライゼーション形式を規定しません。Kafkaと同様にバイト配列を渡します。ユーザーは、既存のシリアライゼーションライブラリ（例：Avro、Protobuf、JSON）やスキーマレジストリ（例：Confluent Schema Registry）をWarpStreamで変更せずに引き続き使用できます。エージェントはメッセージペイロードの内容に依存しません。