現在のデータプラットフォームにおいて、日次で数十億件（Billions）規模のイベントを処理する場合、従来のメッセージキュー（RabbitMQなど）ではスケーラビリティの限界に直面します。スループット、永続性、そして順序保証を同時に満たすためには、分散ログシステムへの移行が不可欠です。本稿では、市場のデファクトスタンダードであるApache Kafkaと、クラウドネイティブなアーキテクチャを持つApache Pulsarについて、エンジニアリングの観点から比較・分析を行います。
1. アーキテクチャ：結合と分離のトレードオフ
KafkaとPulsarの最も根本的な違いは、コンピュート（Broker）とストレージの結合度にあります。この設計思想の違いが、スケーリング戦略と障害復旧（Failover）の挙動を決定づけます。
Kafkaは「パーティション」をストレージの基本単位とし、ブローカーのローカルディスクにログセグメントを保存します。これはシーケンシャルI/Oによる高い書き込み性能を実現しますが、ブローカー障害時にはデータの再複製（Re-replication）が必要となり、ネットワーク帯域を圧迫するリスクがあります。一方、Pulsarはストレージ層としてApache BookKeeperを採用し、コンピュートとストレージを完全に分離しています。
以下の設定例は、それぞれのシステムでデータの耐久性（Durability）を保証するための構成差異を示しています。
# Kafka: server.properties
# ISR (In-Sync Replicas) による書き込み保証
min.insync.replicas=2
default.replication.factor=3
# Pulsar: broker.conf (BookKeeper Client設定)
# アンサンブルサイズ(E), 書き込みクォーラム(Qw), Ackクォーラム(Qa)
# データの断片化と並列書き込みを制御
managedLedgerDefaultEnsembleSize=3
managedLedgerDefaultWriteQuorum=3
managedLedgerDefaultAckQuorum=2
2. パフォーマンス特性：スループット vs テールレイテンシ
「Kafkaは高速である」という通説は正しいですが、詳細なワークロード分析が必要です。KafkaはOSのページキャッシュに強く依存しており、コンシューマーが最新のデータ（Tail）を読み取っている間は極めて高速です。しかし、過去データを読み込む「キャッチアップ読み取り」が発生すると、ディスクI/Oが競合し、書き込みレイテンシにスパイクが発生する可能性があります。
対照的にPulsarは、BookKeeperのI/O分離機能により、書き込み（Journaling）と読み取り（Ledger storage）のI/Oパスが物理的に分離されています。これにより、p99レイテンシ（99パーセンタイル）の安定性が求められる金融取引やリアルタイム入札システムにおいて優位性を発揮します。
| 機能 | Apache Kafka | Apache Pulsar |
|---|---|---|
| アーキテクチャ | モノリシック (Compute + Storage) | 階層型 (Compute / Storage 分離) |
| スケーリング | パーティション再配置が必要 (重い) | ブローカー/Bookieを独立して拡張可 (軽い) |
| レイテンシ (p99) | キャッチアップ時に不安定になる可能性 | I/O分離により安定 |
| 運用複雑度 | ZooKeeper (KRaftにより除去進行中) | ZooKeeper + BookKeeper |
3. マルチテナンシーと運用コスト
大規模組織において、単一のクラスタを複数のチームやサービスで共有するマルチテナンシー要件は避けて通れません。Kafkaはこの点において、論理的な分離（ACL等）に留まりますが、Pulsarは設計段階からマルチテナントを考慮しています。
Pulsarは「テナント」と「ネームスペース」という概念をネイティブにサポートしており、リソースのクォータ設定、認証、さらにはGeo-Replication（地理的冗長化）の設定をネームスペース単位で容易に制御できます。また、Tiered Storage（階層化ストレージ）機能により、古いデータを自動的にAmazon S3やGCSなどの安価なオブジェクトストレージへオフロードすることが可能です。これにより、ストレージコストを大幅に削減できます。
// Pulsar Java Client: Tiered Storageを意識せず透過的にアクセス可能
PulsarClient client = PulsarClient.builder()
.serviceUrl("pulsar://broker.example.com:6650")
.build();
// コンシューマーはデータがBookKeeperにあるかS3にあるかを知る必要がない
Consumer<byte[]> consumer = client.newConsumer()
.topic("persistent://my-tenant/my-ns/my-topic")
.subscriptionName("my-sub")
.subscribe();
以下のボタンから、各公式サイトのドキュメントを参照し、最新のステータスを確認することをお勧めします。
Kafka Documentation Pulsar Architecture結論：どちらを選択すべきか
技術選定は、以下の基準に基づいて行うべきです。
- Apache Kafka: 既存のエコシステム（Connect, Streams）を最大限活用したい場合、極めて高いスループットが必要でレイテンシの多少のブレが許容される場合、または運用リソースが限られており枯れた技術を採用したい場合。
- Apache Pulsar: Kubernetes上での運用が前提である場合、厳格なレイテンシ保証が必要な金融系システム、複雑なマルチテナント要件、または地理的に分散したデータセンター間でのアクティブ-アクティブ構成が必要な場合。
「銀の弾丸」は存在しません。チームの運用能力とビジネス要件（SLA）を照らし合わせ、PoC（概念実証）を通じて実際のワークロードでの挙動を確認することを強く推奨します。
Post a Comment