Apache Pulsarとは？Kafkaとの構造差と採用判断を実装視点で解説

メッセージ基盤を選ぶとき、Kafkaの次に名前が挙がるのがApache Pulsarです。計算層のブローカーと保存層のBookKeeperを分けた構造を持ち、1つのトピックにキュー型とストリーム型の購読を同時に張れます。本記事で扱うのは、コンポーネント構成、4種類のサブスクリプションタイプの選び分け、階層型ストレージとジオレプリケーション、2026年8月時点で本番に置くべき版、そして採用を見送るべき条件です。

まとめ：Pulsarを採る条件と見送る条件の結論

先に結論を置きます。Apache Pulsarは、ブローカーを状態を持たない計算層として切り出し、永続化をApache BookKeeperへ委ねた分散メッセージング基盤です。Kafkaとの差は機能一覧ではなく、この「計算と保存の分離」がノード増設・障害復旧・階層型ストレージの実装をどう変えるかにあります。

採用が成立する条件は3つ。1つのトピックをキュー型とストリーム型の両方で読みたい、テナント単位で流量とクォータを分けたい、複数リージョンの相互レプリケーションを製品機能として持たせたい。2つ以上に該当しないなら、運用実績で勝るKafka系のほうが総コストは下がります。Kafka APIを保ったまま運用部品とブローカー台数を減らす方向であれば、Redpandaの内部構造とライセンス、採用判断も比較対象に入ります。

版の選定は明快です。本番は4.0系のLTSを置く。2026年8月時点の最新パッチ4.0.13は、活動的な支援が2026年10月21日まで、セキュリティ修正が2027年10月21日まで続きます。4.2系は支援が6か月しかなく、5.0.0-M1は本番利用を想定しないマイルストーン版。新規クラスタのメタデータストアは、公式の推奨がZooKeeperからOxiaへ移った点を設計に織り込みます。

Apache Pulsarの定義とブローカー分離型アーキテクチャの構造

Pulsarが何を分離した製品なのかをコンポーネント単位で切り分けます。

ブローカーとBookKeeperのbookieが分担する処理と保存の境界

Apache Pulsarは、Yahoo!が社内基盤として開発し2016年にオープンソース化、2018年にApache Software Foundationのトップレベルプロジェクトへ昇格しました。設計の中心はブローカーが状態を持たないという方針です。公式ドキュメントはブローカーを「ステートレスなコンポーネント」と定義し、役割を管理APIとトピック探索を担うHTTPサーバ、全データ転送を担うディスパッチャの2つに限定しています。

メッセージそのものはブローカーのディスクに残りません。保存を担うのはApache BookKeeperのストレージノード、いわゆるbookieです。ブローカーは受け取ったメッセージをbookieへ書き、購読時はマネージドレジャーのキャッシュから配信する。ブローカーがログファイルを所有するKafkaの設計とは、ここで分かれます。

セグメント指向のレジャー構造がノード増設と障害復旧を軽くする理屈

BookKeeperの保存単位はレジャーと呼ばれます。公式ドキュメントの定義は「単一のライターを持つ追記専用のデータ構造で、複数のbookieに割り当てられる」というもの。1本のトピックのデータは時間とともに複数のレジャーへ切り替わり、レジャーごとに別のbookie群へ配置されます。

この粒度の細かさが運用に効きます。パーティション全体が特定ノードに固定されないため、bookieを1台足せば、既存データを移動させずとも新ノードが新しいレジャーへ書き込みを受け始める。ノード離脱時の復旧対象も「そのbookieが担当していたレジャーの複製不足分」に限定されます。ただし無料ではなく、ブローカーとbookieの2種類を別々に容量設計し、別々に監視することになります。

テナント・ネームスペース・トピックの3階層が定める権限と隔離の境界

Pulsarのトピックは、テナント、ネームスペース、トピックという3階層の名前空間に属します。トピック名は永続か非永続かの区別を先頭に置き、その後ろに3階層を続ける形式です。ネームスペースは公式ドキュメントで「トピックの論理的なグループであり管理単位」と定義され、保持ポリシーやTTLをまとめて適用する層になります。

実務での効き所は、設定を1本ずつのトピックに書かなくてよい点。経理システム向けのネームスペースだけ保持期間を90日にし、検証用は1日で削除する、といった線引きが単位ごとに完結します。テナントを部署単位で切れば、認可とクォータの境界もそこに揃う。Apache Kafkaが選ばれる理由と特徴と読み比べると、共有前提かどうかの思想差が見えます。

サブスクリプション方式とトピック設計でKafkaと分かれる箇所

最初に確かめるべきは購読モデルの差です。

Exclusive・Failover・Shared・Key_Sharedの選び分け

Pulsarは4種類のサブスクリプションタイプを持ちます。Exclusiveは1サブスクリプションに1コンシューマだけを接続させる方式。Failoverは複数接続を許し、マスターに選ばれた1台が受信して切断時に次が引き継ぎます。Sharedは複数コンシューマへラウンドロビンで配り、Key_Sharedは同一キーを必ず同じコンシューマへ送る。軸は「順序をどこまで守るか」と「並列度をどこまで上げるか」の綱引きです。

注目すべきは、この4方式を同じトピックに同時に張れる点です。監査ログを全件保存するExclusiveの購読と、リアルタイム通知を捌くSharedの購読が共存する。Kafkaで同じ形にするならコンシューマグループを分け、パーティション割り当ての制約を前提に設計します。キュー型との思想差はRabbitMQとKafkaの違いと使い分けの判断基準が補助線になります。

パーティション分割と鍵指定で順序保証が効く範囲と効かない範囲の判別

パーティション付きトピックは複数ブローカーへ分散して配置され、分割数は作成時に指定します。あとから増やせても減らせないのはKafkaと同じ制約。保証されるのは1パーティション内での到着順であり、パーティションをまたいだ全体順序ではありません。プロデューサ側でキーを指定すればハッシュで同一パーティションへ寄り、指定しなければ既定のラウンドロビンで分散します。

つまり「全体の順序が要る」という要件が出た時点で、分割数を1に固定するか、Key_Sharedでキー単位の直列へ要件を落とすかの二択になる。減らせない以上、過剰な分割はコンシューマの空転とメタデータ肥大を招きます。想定ピーク流量をコンシューマ1台の処理能力で割り、2倍程度の余裕を持たせた値から始めるのが落とし所です。

メッセージ保持とTTL・非永続トピック・遅延配信の使い分け条件

Pulsarはメッセージの寿命を2つの独立した設定で管理します。Retentionは確認応答済みのメッセージを既定の削除より長く残す設定で、ネームスペース単位で効く。TTL（Expiry）は確認応答されないまま残ったメッセージを指定時間後に削除します。「読み終わったものを残す」と「読まれないものを消す」は逆方向の制御で、混同すると容量計画が崩れます。

永続化しない選択肢もあります。非永続トピックはディスクに書かず、メモリ上だけで扱われる。公式ドキュメントは、ブローカーの停止やコンシューマの切断でメッセージが失われると明記しています。遅延の下限を詰めたいメトリクス配信で、欠損を許容できる場合だけ選ぶ機能です。遅延配信はdeliverAfterで指定し、ブローカーが時刻インデックスを保持して指定時間まで配信を保留します。リトライ間隔の制御をコンシューマ側からブローカー機能へ寄せられる仕組みです。

4.0 LTSと4.2の選択基準とメタデータストア刷新への対応

版の選定は機能差ではなく支援期間で決まります。公開されたリリースポリシーから逆算できます。

4.0 LTSと4.2系の支援期間の差と本番採用で選ぶべき版の判断

Pulsarのバージョン番号は通常のsemantic versioningではありません。公式のリリースポリシーは、番号の意味をmajor.minor.patchからLTS.feature.patchへ置き換えたと説明しています。4.0.13なら「4」がLTS世代、「0」がフィーチャーリリース番号、「13」がパッチ番号。支援期間は世代で大きく違います。

この表を2026年8月11日時点の版へ当てはめます。4.0系は2024年10月21日のLTSで、活動的な支援が2026年10月21日まで、セキュリティ修正が2027年10月21日まで。最新パッチは4.0.13（2026年8月3日）です。4.2系は2026年3月のフィーチャーリリースで、最新の4.2.4も同日に出ているものの、支援は2026年9月24日に切れます。

結論として、本番クラスタは4.0系のLTSに置く。4.2系を選ぶのは、その世代でしか入っていない機能に依存し、かつ半年ごとの版上げを運用計画へ織り込める場合に限られます。5.0.0-M1（2026年6月23日）は公式が本番利用を想定しないと明記したマイルストーン版で、検証環境以外には置きません。ただし4.0系の活動的な支援終了が2026年10月に迫っており、5.0 LTSを待って移行する計画は今の時点で立てておきます。

Oxia推奨への転換とZooKeeper構成から移す判断の分かれ目

Pulsarといえば「ZooKeeperが要る」という理解が長く定着していましたが、公式ドキュメントの記述は変わりました。メタデータストアとして挙げられている実装は3つ。Oxiaは「新規クラスタに推奨。大規模分散システム向けに設計された堅牢でスケーラブルなメタデータストア兼コーディネーションシステム」、ZooKeeperは「強い一貫性保証を備えた本番利用可能なメタデータストア」という位置づけです。RocksDBはスタンドアロン向けの組み込み型で、外部のコーディネーションサービスを不要にします。

判断は2つに分かれます。新規に組むならOxiaを起点に検証する。既存のZooKeeper構成が安定して回っているなら、支援対象である以上、無理に移す理由はありません。移行を検討すべきなのは、書き込みがボトルネックになった、障害対応ができる人員が減ったというように、アンサンブル自体が運用の重荷になっている場合です。検証環境ならRocksDBで外部プロセスを1つ減らす手もあります。

階層型ストレージとジオレプリケーションで効く運用コストの抑え方

保存層の分離がコスト面で最も分かりやすく効くのがこの2機能です。

S3やGCSへのオフロード契機と読み出し遅延という引き換えの評価

階層型ストレージは、bookieに置いた古いレジャーをオブジェクトストレージへ退避する機能です。公式にサポートされている退避先は、Amazon S3、Google Cloud Storage、Microsoft Azure Blob Storage、Alibaba Cloud OSS、ネットワーク接続のファイルシステム、MinIOやCephといったS3互換の実装。オンプレミスでも成立する点が閉域要件で効きます。退避の契機は4つです。

• サイズ基準：トピックのバックログが一定サイズを超えたとき
• 時間基準：データが指定した経過時間を超えたとき
• 手動：REST APIまたはCLIによる管理コマンド
• ネームスペース単位のポリシーによる自動実行

引き換えは読み出し性能です。公式ドキュメントは、退避済みデータの読み出しがネットワーク遅延のぶんBookKeeperより遅いと明記しています。加えて退避後にBookKeeper側からデータが消えるまで既定で4時間の待ちがあり、その間は二重に容量を占める。過去データの再処理が日常的に走る基盤で時間基準の閾値を短くしすぎると、再処理のたびにオブジェクトストレージを叩きます。閾値は再処理が発生する期間より長く置くのが原則です。

ジオレプリケーションで組む地理冗長と順序・整合性の取り扱いの注意点

Pulsarは複数クラスタ間のレプリケーションを製品機能として持ちます。設定はネームスペース単位で、レプリケーション先クラスタの一覧を与える形。トピックごとに配線を書く必要はありません。押さえておくのは、レプリケーションが非同期であるという前提です。リージョン間の遅延ぶん複製先のデータは常に少し遅れるため、「東京で書いた直後に大阪で読める」ことを前提にしたアプリケーションは組めません。

使いどころは、災害対策としての待機系と、分散した生産拠点からのデータ集約です。前者なら片方向で足りる。後者も各拠点が書き中央が読む構成にすれば、更新の衝突自体が起きません。双方向で同じキーを書き合う設計は、解決順序をアプリケーション側で決める負担が残ります。

Kafka資産からの移行と併存で詰まりやすい互換レイヤの扱い方

既存のKafka資産の扱いは、製品境界を正確に押さえないと設計を誤ります。

Kafka互換レイヤの位置づけとApache本体との提供元の違い

Pulsarには、Kafkaクライアントからそのまま接続できるプロトコル互換レイヤが存在します。ただし2026年8月時点でこれはApache Pulsar本体の同梱機能ではなく、StreamNativeが公開する別プロジェクトです。採用時はASFのリリースサイクルとは別に、その外部プロジェクトの更新頻度と対応Pulsar版を確認する手順が要ります。

実装判断としては、互換レイヤを「恒久的な運用構成」ではなく「移行期間の橋渡し」に位置づけるのが安全です。噛ませたままでは、Pulsarを選んだ理由そのものであるサブスクリプションタイプに手が届きません。Kafkaクライアントのまま動かすなら、Kafkaを使うほうが単純です。運用の手離れを優先するならAmazon MSKとKafka自前運用の違いのマネージド前提の選択肢も比較対象に入ります。

Pulsar IOコネクタとPulsar Functionsで代替できる範囲

外部システムとの接続とストリーム処理は、Pulsar本体の機能で賄えます。Pulsar IOはソースとシンクのコネクタ群で、データベースやオブジェクトストレージとの入出力を担う。Pulsar Functionsは、トピックを入力にして変換や振り分けを行う軽量な処理をクラスタ上で走らせる仕組みです。

見誤りやすいのはコネクタの品揃えです。Kafka側のエコシステムは商用・OSS双方で長く積み上がっており、対応プロダクトの数では差がある。接続対象が既存コネクタで賄えるかは、製品名を一つずつ突き合わせて確かめます。1つでも自作が必要なら、その工数を採用判断のコストへ加算してください。

Pulsarの採用が成立する3条件と見送るべき構成の見極め方

ここまでの構造と機能を採用可否に落とします。玉虫色にはしません。

同一トピックの二重購読・テナント分離・地理冗長という3条件の判定

採用してよいのは、3条件のうち2つ以上に該当する場合です。

1. 同一トピックをキュー型（Shared・Key_Shared）とストリーム型（Exclusive）の両方で読む要件が既にある
2. 複数チームで1クラスタを共有し、ネームスペース単位でクォータと保持期間を分けたい
3. 複数リージョン間のレプリケーションを、自作の転送処理ではなく製品機能で持たせたい

1つしか該当しないなら見送ります。Pulsarの構造的な利点はいずれも「共有」と「分離」から来ており、単一チームが単一用途で使う限り、利点が出ないまま運用対象プロセスだけが増えるからです。3層を監視する体制を用意して、得られるのがKafkaと同等のPub/Sub機能だけ、という結果になります。判断に迷いが残るなら、当社のデータ分析基盤構築・MLOps構築支援のような外部の設計支援を、要件の棚卸し段階から入れる選択肢もあります。

見送る条件：日次数十万件未満の規模と運用人員2名以下の体制の線引き

明確に見送るべき構成が2つあります。1つ目は、日次のメッセージ量が数十万件に届かない規模。この帯域なら、PostgreSQLの拡張でキューを組むpgmqのようなDB内キューやマネージドのキューサービスで足り、Pulsarの3層構成を立てる固定費が処理量に見合いません。

2つ目は、基盤運用にあたる人員が実質1名から2名の体制です。障害時の切り分けは、ブローカー・bookie・メタデータストアのどの層で起きたかの判別から始まります。この判別を担える人が1人しかいない構成は、その1人が休んだ日に復旧できません。Kafka系を含めマネージドへ寄せるほうが現実的です。

失敗パターン：BookKeeperの運用設計を後回しにした構成の破綻

導入で最も多く踏まれるのが、BookKeeperの容量設計をブローカーの後回しにするパターンです。検証はスタンドアロン構成で簡単に始められるため、ブローカーの挙動だけ確認して本番設計に入ってしまう。破綻の出方は決まっていて、bookieのディスクが埋まり書き込みが止まります。原因は、確認応答済みのメッセージが保持ポリシーで残り続けていた、退避契機を設定していなかった、といった設計漏れです。退避後もBookKeeper側の削除には既定で4時間の遅れがあり、逼迫してから設定を入れても即座には空きません。

回避策は運用開始前の3点に尽きます。ネームスペースごとに保持期間とTTLを明示設定すること、階層型ストレージの契機をサイズと時間の両方で置くこと、bookieのディスク使用率を退避契機より手前の閾値で警報にすること。これを設計書に書かずに本番へ出した構成は、数か月後に同じ形で詰まります。

よくある質問

実装者から挙がることの多い質問を5つに絞って答えます。

Apache PulsarとKafkaはどちらが速いですか？

公開ベンチマークは測定条件で結果が逆転するため、速度単体での優劣は判断材料になりません。構造上の差として言えるのは、Pulsarは書き込み時にBookKeeperへの往復が入る一方、レジャー単位の分散で特定ノードへの書き込み集中が起きにくい点です。既存構成と同じ台数・同じメッセージサイズで負荷をかけ、書き込み遅延の99パーセンタイルを比較して判断してください。

PulsarにZooKeeperは今も必要ですか？

必須ではありません。公式ドキュメントはメタデータストアの実装としてOxia、ZooKeeper、RocksDBの3つを挙げ、新規クラスタにはOxiaを推奨しています。ZooKeeperも本番利用可能な選択肢として残っているため、既存構成をすぐ移す必要はない。スタンドアロンの検証環境なら、RocksDBで外部のコーディネーションサービスなしに動かせます。

Kafkaクライアントのコードをそのまま使えますか？

プロトコル互換レイヤを導入すれば接続できますが、これはApache Pulsar本体の同梱機能ではなく、StreamNativeが公開する別プロジェクトです（2026年8月時点）。互換レイヤ経由ではサブスクリプションタイプのようなPulsar固有の機能に手が届きません。恒久構成ではなく移行期間の橋渡しとして扱い、Pulsarクライアントへ書き換える工数を移行計画に含めてください。

本番にはどのバージョンを入れるべきですか？

2026年8月時点では4.0系のLTSを選びます。最新パッチは4.0.13（2026年8月3日公開）で、活動的な支援が2026年10月21日まで、セキュリティ修正が2027年10月21日まで。4.2系はフィーチャーリリースで支援が6か月しかなく、4.2.4の支援は2026年9月24日で終了します。5.0.0-M1は先行検証向けのマイルストーン版で、本番利用は想定されていません。

階層型ストレージを入れるとコストはどれだけ下がりますか？

削減幅は保持期間とアクセス頻度で決まるため一律には出せませんが、判断の型は示せます。bookieのブロックストレージ単価とオブジェクトストレージ単価の差に、退避対象のデータ量を掛けたものが削減額の上限。そこから読み出しに応じたリクエスト課金を差し引きます。過去90日のデータに月数回しか触らない構成なら効き、日次で全期間を再処理する構成では逆効果です。

関連記事

• Azure Event Hubsとは｜Kafka互換ストリーミング基盤の仕組みと採用判断：クラウド側で同種要件を満たす場合の比較対象。
• Kafka Connectとは？構成要素とコネクタ運用：Pulsar IOに相当するKafka側の仕組みで、コネクタ品揃えの比較材料。
• Materialize（ストリーミングDB）とは？仕組み・料金と採用判断：取り込んだストリームを問い合わせる層の検討に。
• Cloud Dataflowとは？Apache Beamの実行基盤とストリーミング処理：Pulsar Functionsより重い変換処理を外出しする選択肢。
• pgmqとは？PostgreSQLをメッセージキューにする拡張の使い方：小規模構成でPulsarを見送るときの代替。
• NATSとは？Core NATSとJetStreamの仕組みと採用判断：単一バイナリで永続化まで担う軽量な対極の設計。