2026年におけるKafka対Redpanda：スレッドパーコアアーキテクチャ、ゼロディスクキャッシュ、P99レイテンシベンチマーク

イベントストリーミングプラットフォームは、現代の分散システムの基盤です。Apache Kafkaは長らくデファクトスタンダードでしたが、Kafka API互換の代替であるRedpandaが大きな注目を集めています。この分析では、2026年のアーキテクチャパラダイムの文脈でKafkaとRedpandaをデータに基づいて比較し、そのコア実行モデル、ストレージ効率、テールレイテンシ特性、および運用フットプリントに焦点を当てます。

アーキテクチャの相違点：JVM vs. スレッド・パー・コア

KafkaとRedpandaの根本的なアーキテクチャの違いは、その実行モデルにあります。KafkaはJavaベースのアプリケーションであり、Java仮想マシン（JVM）とそのガベージコレクタ（GC）を利用しています。RedpandaはC++で書かれており、Seastarフレームワーク上に構築され、スレッド・パー・コアの共有なしアーキテクチャを採用しています。

Apache Kafka：JVMとGCのオーバーヘッド

KafkaのJVM中心の設計は、プラットフォームの独立性と豊富なエコシステムを提供します。しかし、それは固有の課題をもたらします。

1. ガベージコレクションの一時停止（GC Pauses）： G1やZGCのような最新のGCを使用しても、大規模なヒープサイズ（高スループットのKafkaブローカーで一般的）は、ストップ・ザ・ワールドの一時停止を引き起こし、P99レイテンシに影響を与える可能性があります。これらの停止は非決定的であり、チューニングが難しい場合があります。
2. メモリフットプリント： JVMアプリケーションは、JVM自体、JITコンパイル、およびオブジェクトのオーバーヘッドのため、通常、ネイティブコードと比較してより大きなメモリフットプリントを持ちます。
3. コンテキストスイッチ： Javaの従来の「スレッド・パー・リクエスト」モデルは、高負荷時に、特にI/O操作がスレッドをブロックする場合、かなりのコンテキストスイッチのオーバーヘッドを発生させる可能性があります。

Redpanda：Seastarのスレッド・パー・コアとゼロコピー

RedpandaのSeastarベースのアーキテクチャは、これらのJVMの制限に直接対処します。

1. スレッド・パー・コア： 各CPUコアは、専用のノンブロッキングイベントループを実行します。特定のシャード（パーティションレプリカ）のすべてのI/Oと計算は単一のコアによって処理され、そのシャードのスレッド間のコンテキストスイッチを排除します。
2. 共有なし（Shared-Nothing）： データはコア間でシャーディングされ、各コアが独自のメモリを管理するため、キャッシュコヒーレンシの問題や偽共有（false sharing）を防ぎます。
3. ゼロコピーI/O： Redpandaはゼロコピー技術を広範囲に利用し、カーネルとユーザー空間間のデータ移動を最小限に抑えます。これにより、CPUサイクルとメモリ帯域幅の消費が削減されます。
4. GC一時停止なし： C++アプリケーションであるため、RedpandaはJVMのGC一時停止を完全に回避し、より予測可能で低いテールレイテンシに貢献します。

Seastarフレームワークの設計は、最新のNUMAアーキテクチャとNVMe SSDに最適化されており、高性能ハードウェアを最大限に活用できます。

// Example: Simplified Seastar-like I/O pattern (conceptual)
// In a real Seastar application, this would be integrated with futures and continuations.

#include <iostream>
#include <vector>
#include <string>
#include <seastar/core/app-template.hh>
#include <seastar/core/future.hh>
#include <seastar/core/file.hh>
#include <seastar/core/reactor.hh>
#include <seastar/core/aligned_buffer.hh>

// This is a highly simplified, illustrative example.
// Real Redpanda/Seastar code involves complex futures, continuations,
// and memory management (e.g., `seastar::temporary_buffer`).

seastar::future<> write_to_disk_zero_copy(const std::string& filename, const std::string& data) {
    return seastar::open_file_dma(filename, seastar::open_flags::wo | seastar::open_flags::create | seastar::open_flags::truncate).then([data](seastar::file f) {
        // Allocate an aligned buffer for DMA
        auto buf = seastar::make_aligned_buffer<char>(data.length(), 4096);
        std::memcpy(buf.get(), data.data(), data.length());

        // Write directly from the aligned buffer to disk
        return f.dma_write(buf.get(), data.length(), 0).then([f] {
            return f.close();
        });
    });
}

int main(int argc, char** argv) {
    seastar::app_template app;
    return app.run(argc, argv, [] {
        std::cout << "Starting Seastar-like zero-copy write simulation..." << std::endl;
        return write_to_disk_zero_copy("test_log_segment.bin", "This is a sample log entry for Redpanda.")
            .then([] {
                std::cout << "Zero-copy write simulation complete." << std::endl;
            })
            .handle_exception([](std::exception_ptr ep) {
                std::cerr << "Error: " << seastar::current_exception_better_what(ep) << std::endl;
            });
    });
}

注：上記のC++の例は、Seastarのようなコンテキストにおけるゼロコピーの原則の概念的な説明です。完全なRedpandaの実装には、はるかに複雑な非同期I/O、メモリ管理、および分散システムロジックが含まれます。

ゼロディスクキャッシュと階層型ストレージ

両プラットフォームは、プライマリストレージとしてローカルディスクを使用し、長期保存とコスト最適化のために階層型ストレージソリューションを提供しています。

Kafka：ページキャッシュとブローカーサイドキャッシング

Kafkaは、ホットデータのためにオペレーティングシステムのページキャッシュに大きく依存しています。これは効率的ですが、ワーキングセットが利用可能なRAMを超える場合、キャッシュスラッシングを引き起こす可能性があります。ブローカーサイドのキャッシングメカニズムは存在しますが（例：log.retention.bytes、log.retention.hours）、データがページキャッシュにない場合、主要な読み取りパスはしばしばディスクI/Oを伴います。

Kafkaの階層型ストレージ（例：Confluent Tiered StorageまたはApache KafkaのKIP-405経由）は、古いセグメントをS3やGCSのようなオブジェクトストレージにオフロードします。これにより、ストレージとコンピューティングが分離され、より安価な長期保存とストレージの容易なスケーリングが可能になります。ただし、階層型ストレージからデータをフェッチすると、レイテンシが高くなる可能性があります。

Redpanda：ゼロディスクキャッシュとネイティブ階層型ストレージ

Redpandaの「ゼロディスクキャッシュ」という用語は、ローカルディスクを依然として使用するという意味では誤解を招く可能性があります。この用語は、データを階層型ストレージに積極的にオフロードすることで、最小限のローカルディスクフットプリントで効率的に動作する能力を指します。Redpandaの階層型ストレージは、アドオンではなく、コアのネイティブ機能です。

Redpandaのストレージの主要な側面：

1. セグメントのオフロード： Redpandaは、コミットされたログセグメントをオブジェクトストレージ（S3、GCS、Azure Blob Storage）に継続的にオフロードします。これは、ローカルディスクが主に書き込みバッファとして、また最近アクセスされたデータのキャッシュとして機能することを意味します。
2. リードスルーキャッシュ： コンシューマがローカルディスクに存在しないデータを要求すると、Redpandaはオブジェクトストレージから直接フェッチし、ローカルにキャッシュして提供します。このリードスルーキャッシングメカニズムは、パフォーマンスのために最適化されています。
3. ローカルディスク要件の削減： オフロードにより、Redpandaは大幅に小さいローカルSSDで動作できるため、インフラコストを削減できます。これは、高い保持要件を持つトピックにとって特に有益です。

// Example: Redpanda's conceptual tiered storage configuration (YAML)
// This is a simplified representation of how tiered storage might be configured.

redpanda:
  cluster:
    name: "redpanda-cluster"
  storage:
    dataDirectory: "/var/lib/redpanda/data"
    # Local disk retention policy
    logRetentionBytes: "100GB" # Keep only 100GB on local disk per partition
    logRetentionHours: "24h"   # Or keep 24 hours of data locally

  cloud_storage:
    enabled: true
    bucket: "my-redpanda-archive-bucket"
    region: "us-east-1"
    access_key: "YOUR_AWS_ACCESS_KEY"
    secret_key: "YOUR_AWS_SECRET_KEY"
    # Optional: Configure a custom endpoint for S3-compatible storage
    # endpoint: "http://minio.my-company.com:9000"
    # Optional: Configure a retention policy for cloud storage
    # cloudStorageRetentionBytes: "1TB"
    # cloudStorageRetentionHours: "720h" # 30 days

P99レイテンシベンチマーク（10万メッセージ/秒）

テールレイテンシ（P99、P99.9）は、リアルタイムアプリケーションにとって非常に重要です。1秒あたり10万メッセージの持続的な負荷の下では、アーキテクチャの違いが顕著になります。

ベンチマーク設定

• ワークロード： 10万メッセージ/秒、メッセージサイズ1KB。
• プロデューサー： 100の同時プロデューサー。
• コンシューマー： 100の同時コンシューマー（少なくとも1回セマンティクス）。
• クラスタサイズ： 3ブローカー、トピックあたり3レプリカ。
• ハードウェア： AWS i3.xlarge インスタンス（4 vCPU、30.5GB RAM、NVMe SSD）。
• メトリクス： エンドツーエンドレイテンシ（プロデューサー送信からコンシューマー受信まで）。

予想される結果

| メトリクス | Apache Kafka (JVM) | Redpanda (Seastar) | 注記 RedpandaのP99レイテンシは、同じ負荷の下でKafkaよりも一貫して低いです。これは主に、GC一時停止がないことと、より効率的なI/O処理によるものです。

Kubernetesにおける運用オーバーヘッド

Kubernetes上でのKafkaとRedpandaのデプロイと管理には、異なる考慮事項が伴います。

Kubernetes上のKafka

Kubernetes上のKafkaは通常、以下を含みます。

• StatefulSets： 安定したネットワーク識別子と永続ストレージのため。
• Persistent Volumes (PVs) / Persistent Volume Claims (PVCs)： ログセグメントストレージのため。
• ZooKeeper： メタデータ管理のための独立したステートフルなアンサンブル（ただし、Kafka Raft (KRaft) は成熟しつつあります）。
• オペレーター： StrimziやConfluent Operatorのようなプロジェクトは、デプロイと管理を簡素化し、スケーリング、アップグレード、構成を処理します。
• JVMチューニング： 慎重なJVMメモリ割り当て、GCチューニング、および監視が必要です。
• 監視： JMXエクスポーター、Prometheus、GrafanaによるJVMおよびKafka固有のメトリクス。

# Simplified Strimzi Kafka deployment (conceptual)
apiVersion: kafka.strimzi.io/v1beta2
kind: Kafka
metadata:
  name: my-kafka-cluster
spec:
  kafka:
    version: "3.7.0"
    replicas: 3
    listeners:
      - name: plain
        port: 9092
        type: internal
        tls: false
      - name: external
        port: 9094
        type: route # Or nodeport, loadbalancer
        tls: false
    storage:
      type: jbod
      volumes:
        - id: 0
          type: persistent-claim
          size: 100Gi
          deleteClaim: false
    jvmOptions: # Example JVM tuning
      -Xms: "8G"
      -Xmx: "8G"
      -XX:+UseG1GC
      -XX:MaxGCPauseMillis: "200"
  zookeeper: # Still required for older Kafka versions or specific setups
    replicas: 3
    storage:
      type: persistent-claim
      size: 10Gi
      deleteClaim: false
  entityOperator:
    topicOperator: {}
    userOperator: {}

Kubernetes上のRedpanda

RedpandaのKubernetesに関する話は、その単一バイナリ設計と統合されたRaftコンセンサスにより、一般的にシンプルです。

• 単一バイナリ： 独立したZooKeeperやKRaftコントローラーノードは不要です。Redpandaはメタデータを内部で処理します。
• StatefulSets： Kafkaと同様に、永続ストレージとネットワークIDのため。
• Persistent Volumes (PVs) / Persistent Volume Claims (PVCs)： ローカルログストレージのため。
• Redpanda Operator： デプロイ、スケーリング、アップグレード、構成を簡素化します。
• 低いリソースフットプリント： 通常、メッセージスループットあたりのCPUとメモリが少なく、クラスタの利用率が向上します。
• 監視： Prometheusエクスポーターが組み込まれており、標準的なKubernetes監視スタックと良好に統合されます。

# Simplified Redpanda deployment (conceptual)
apiVersion: cluster.redpanda.com/v1alpha1
kind: Redpanda
metadata:
  name: my-redpanda-cluster
spec:
  chartRef:
    chart: redpanda
    version: "2.3.0" # Operator version
  clusterSpec:
    image: "docker.io/vectorized/redpanda"
    version: "23.3.1" # Redpanda broker version
    replicas: 3
    configuration:
      # Example Redpanda configuration
      developer_mode: true # For dev/test, disable in prod
      auto_create_topics_enabled: true
      cloud_storage_enabled: true
      cloud_storage_bucket: "my-redpanda-archive-bucket"
      cloud_storage_region: "us-east-1"
      # ... other Redpanda specific configs
    resources:
      cpu: "4"
      memory: "16Gi"
    storage:
      # Local disk storage
      capacity: "100Gi"
      storageClassName: "gp2" # Or other appropriate StorageClass

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

Kafka

1. 落とし穴：P99レイテンシに影響を与えるJVM GCの一時停止

   • 症状： プロデューサーのsend()レイテンシまたはコンシューマーのpoll()レイテンシに散発的なスパイクが発生し、ブローカーノードでの高いCPU使用率と相関することが多い。JMXメトリクスは長いGarbageCollectionTimeまたはG1YoungGenerationDurationを示します。
   • 解決策：
     • GCのチューニング： G1GCパラメータ（-XX:MaxGCPauseMillis、-XX:InitiatingHeapOccupancyPercent）を試します。非常に大きなヒープの場合、ZGCまたはShenandoah（OpenJDK 11+が必要）を検討します。
     • ヒープサイズの削減： 可能であれば、GCの負荷を軽減するためにJVMヒープサイズを削減しますが、ページキャッシュに十分なメモリを確保してください。
     • ブローカー数の増加： 水平方向にスケールアウトして負荷を分散し、ブローカーあたりのメモリ負荷を軽減します。
     • 監視： JMXエクスポーターとGrafanaダッシュボードを使用してGCアクティビティを視覚化します。

2. 落とし穴：ディスクI/Oのプロビジョニング不足

   • 症状： 高いディスクI/O待機時間（%iowait in top）、メッセージ書き込みの遅延、RequestPurgatoryの増加。
   • 解決策：
     • ディスクのアップグレード： より高速なSSD（NVMe推奨）を使用します。
     • ディスクスループットの向上： クラウド環境の場合、アタッチされたボリュームのIOPS/スループット制限を増やします。
     • パーティションの分散： ホットスポットを避けるために、パーティションがブローカーとディスク全体に均等に分散されていることを確認します。
     • 監視： disk_io_time_ms_total、disk_read_bytes_total、disk_write_bytes_totalのメトリクスを追跡します。

3. 落とし穴：ZooKeeperクォーラムの問題（KRaft以前）

   • 症状： Kafkaブローカーが登録できない、リーダー選出の失敗、クラスタの不安定性。
   • 解決策：
     • 専用リソース： ZooKeeperノードに専用のCPU、メモリ、高速ストレージが確保されていることを確認します。
     • ネットワークレイテンシ： ZooKeeperノード間のネットワークレイテンシを最小限に抑えます。
     • 監視： ZooKeeperのzxid、pending_requests、latencyのメトリクスを追跡します。
     • KRaftへの移行： 新しいデプロイまたはアップグレードの場合、ZooKeeperへの依存を排除するためにKRaftを優先します。

Redpanda

1. 落とし穴：SeastarコアでのCPU不足

   • 症状： 高いP99レイテンシ、seastar_reactor_stalled_reactor_countの増加、特定のコアでのseastar_reactor_cpu_utilizationが100%に近い。
   • 解決策：
     • 専用コア： Redpandaプロセスに専用のCPUコアがあり、同じノード上の他のプロセスによって過剰にサブスクライブされていないことを確認します。CPUピニングまたはKubernetesのguaranteed QoSクラスを使用します。
     • CPUの増加： より多くの物理コアを持つインスタンスにスケールアップします。
     • コアあたりのパーティション数の削減： 利用可能なコア全体にパーティションをより広く分散させます。
     • 監視： Redpandaの組み込みPrometheusメトリクスを使用して、リアクタースタールとCPU使用率を監視します。

2. 落とし穴：階層型ストレージのスロットリング/レート制限

   • 症状： セグメントのオフロードが遅い、ローカルディスク使用量の増加、cloud_storage_upload_errors_totalまたはcloud_storage_download_errors_totalメトリクス。
   • 解決策：
     • クラウドプロバイダーの制限の増加： バケット/アカウントのS3/GCS APIレート制限を確認し、増やします。
     • ネットワーク帯域幅： Redpandaノードとオブジェクトストレージエンドポイント間の十分なネットワーク帯域幅を確保します。
     • オフロードパラメータのチューニング： Redpandaのcloud_storage_max_connectionsまたはcloud_storage_upload_chunk_sizeを調整します（現在のパラメータについてはRedpandaドキュメントを参照してください）。
     • 監視： cloud_storage_upload_bytes_total、cloud_storage_download_bytes_total、およびエラーメトリクスを追跡します。

3. 落とし穴：積極的な保持/オフロードの問題によるローカルディスクの満杯

   • 症状： Redpandaノードがオフラインになる、disk_space_available_bytesが臨界しきい値に達する、redpanda_log_segment_errors_total。
   • 解決策：
     • 階層型ストレージの検証： 階層型ストレージが正しく構成され、アクセス可能であることを確認します。クラウドプロバイダーの認証情報とネットワーク接続を確認します。
     • ローカル保持の調整： 階層型ストレージが追いつかない場合、またはより大きなワーキングセットにローカルディスクが本当に必要な場合は、logRetentionBytesまたはlogRetentionHoursを増やします。
     • 監視： disk_space_available_bytesおよびcloud_storage_upload_errors_totalにアラートを設定します。

よくある質問

1. 2026年にKafkaではなくRedpandaを選ぶべきなのはどんな時ですか？ P99テールレイテンシが重要な要件であり、運用上のシンプルさ（単一バイナリ、ZooKeeperなし）が非常に重視され、ハードウェア利用率（特にNVMe SSDと高コア数CPU）を最大化したい場合にRedpandaを選択すべきです。そのネイティブ階層型ストレージと低いリソースフットプリントは、大幅なコスト削減にもつながります。

2. RedpandaはKafkaのドロップイン代替品ですか？ はい、RedpandaはKafka API互換です。ほとんどのKafkaクライアント（Java、Go、Python、Node.js）は、コード変更なしでRedpandaに接続できます。ただし、一部の高度なKafka機能（例：特定のKafka Streams DSL機能、特定のKafka Connectコネクタ）は検証が必要な場合があります。常に徹底的なテストを行ってください。

3. KafkaのKRaftとRedpandaの統合コンセンサスはどのように比較されますか？ KRaft（Kafka Raft）はKafkaのZooKeeperへの依存を排除し、そのアーキテクチャを簡素化します。これにより、KafkaはRedpandaの単一バイナリモデルに近づきます。しかし、KRaftは依然としてJVM内で動作し、そのパフォーマンス特性を継承しますが、RedpandaのRaft実装はSeastarフレームワーク内のネイティブC++であり、そのスレッド・パー・コアモデルとゼロコピーI/Oの恩恵を受けています。Redpandaの統合コンセンサスは、KRaftよりも長く本番環境で実績があります。

4. RedpandaとKafkaの実行コストにはどのような影響がありますか？ Redpandaは、多くの場合、以下の理由によりインフラコストを削減します。

   • 少ないノード： ノードあたりのスループットが高いため、必要なインスタンス数が少なくなります。
   • 小さいローカルディスク： 積極的な階層型ストレージのオフロードにより、より小さく安価なローカルSSDを使用できます。
   • CPU/メモリの削減： より効率的なリソース利用により、より小さいインスタンスタイプまたは少ないインスタンスで済みます。
   • 運用上のシンプルさ： JVMチューニング、ZooKeeper管理、複雑なアップグレードにかかる時間が少なくなります。

5. KafkaからRedpandaへの移行における考慮事項は何ですか？ 移行には以下が含まれます。

   • クライアント互換性テスト： 既存のKafkaクライアントがシームレスに動作することを確認します。
   • データ移行： MirrorMaker 2.0やRedpandaのrpk topic create --from-kafkaなどのツールを使用してデータをレプリケートできます。
   • 構成の変換： Kafkaブローカーの構成をRedpandaの同等物にマッピングします。
   • 監視の統合： 監視ダッシュボードをRedpandaのPrometheusメトリクスを使用するように更新します。
   • 運用プレイブック： Redpandaの特定の特性に合わせて既存の運用手順を調整します。

結論

2026年においても、KafkaとRedpandaはどちらもイベントストリーミングの堅牢な選択肢であり続けます。Kafkaは、特にKRaftの導入により進化を続け、成熟したエコシステムと幅広いコミュニティサポートを提供しています。しかし、Redpandaは、極限のパフォーマンス、予測可能な低いテールレイテンシ、および運用上のシンプルさ（特にクラウドネイティブなKubernetes環境で）を優先する組織にとって魅力的な代替手段を提供します。そのC++ Seastarスレッド・パー・コアアーキテクチャとネイティブ階層型ストレージは、高スループット、低レイテンシのワークロードにおいて、リソース効率とコスト最適化に明確な優位性をもたらします。最終的な選択は、特定のワークロード要件、運用上の専門知識、およびエコシステムの成熟度と最先端のパフォーマンスとの間の望ましいバランスにかかっています。