Kakfaクラスタを増やしすぎていませんか 〜 Kafkaの設計限界と、Pulsarが提案する“次世代スケーラブル基盤”
Kakfaクラスタを増やしすぎていませんか 〜 Kafkaの設計限界と、Pulsarが提案する“次世代スケーラブル基盤”
Kafkaクラスタが業務ごとに分割されていく理由は、構成の問題ではなく構造の問題かもしれません。本稿では、Apache Pulsarとの対比から、Kafkaの設計思想と限界を再考します。
0. はじめに：構造の違いが何を可能にするのか
本記事では、Apache Pulsar の基本構造から見る優位性に基づいた「仮説」の描写を行います。以下のような観点で、Kafkaではクラスタ分割が発生しやすく、Pulsarでは構造的にその必要が軽減されることを見ていきます：
- トピック数・パーティション数のスケーラビリティ
- トピックの認可設定と論理分離の構造
- 保持期間とSLAの柔軟性
これらの違いがなぜ設計構造に起因するのかを各節で解説し、将来的な選択肢として構造理解の重要性を提示します。
1. Kafkaクラスタはなぜ増えるのか
Kafkaの構造には、用途の多様化や拡張に伴ってクラスタ分割を促す設計上の制約があります。以下に、設計現場で意識されやすい代表的な課題を挙げます：
- トピック数やパーティション数が増えると、メタデータ管理やZookeeperの負荷が大きくなる
- 認可設定がトピック単位であり、名前空間による論理分離ができないので、トピックのまとまりを簡潔に表現できず、運用が煩雑になる
- 長期保持と短期保持を同じBrokerに含めると、達成可能なSLAの精度に問題が出る
これらの構造的制約により、Kafkaを「一般配信基盤」として運用しようとすると、SLAの違いや用途ごとにクラスタを分割せざるを得ない場面が多くあります。
1.1 トピック数・パーティション数の増加による構造的な限界
Kafkaにおける構造的なボトルネックのひとつは、トピック数やパーティション数が増加することでメタデータの管理コストとZookeeperの負荷が急増する点です。たとえば、Controllerが再起動やフェイルオーバーによってトピック・パーティション情報を再読み込みする際には、大量のメタデータがZookeeperとの間で読み書きされ、遅延や一時的な不整合を引き起こすことがあります。これにより全体の安定性や可用性に影響を及ぼすことがあり、大規模なクラスタでは特に顕著です。
Kafkaは、すべてのトピックとその各パーティションについて、リーダー／フォロワーの管理、レプリカの配置、ISR（In-Sync Replica）の状態、ログセグメントの位置情報など、詳細なメタデータをZookeeperやController内部に保持しています。
これらのメタデータは以下の理由でスケーラビリティに限界があります：
- 各パーティションごとに個別のメタ情報があり、Zookeeperとのラウンドトリップが発生する
- Controllerはパーティション数に比例して定期的な監視・変更を行う必要がある
- トピックが数千〜数万に達すると、メタデータの扱いが負荷要因となり、可用性や管理性に影響が出ることがある
1.2 認可設定の煩雑さと名前空間の欠如
Kafkaでは、認可設定がトピック単位で行われるため、大規模なクラスタにおいてきめ細かなアクセス制御を実現しようとすると非常に煩雑になります。名前空間（Namespace）といった論理単位が存在しないので、部署・チームごとの責任分離が曖昧になります。
1.3 保持期間の差異とBroker構造のジレンマ
Kafkaでは、Brokerがストレージも管理しているので、長期保持のトピックと短期保持のトピックが同居すると、ディスク使用量・I/O効率・ログのクリーンアップタイミングなどでSLAの達成に悪影響を及ぼします。このため、保持方針の異なる業務を一つのクラスタで扱うのは難しく、クラスタ分割の動機になります。
2. Pulsarはその構造的な問題に答えようとした
Apache Pulsar は、もともと米 Yahoo（後のVerizon Media）で2013年頃に開発が始まりました。当時、同社はKafkaを含む複数のメッセージングシステムを社内で広範に利用していましたが、以下のような課題が顕在化していました：
- チームごとに独立した Kafka クラスタが乱立し、運用負荷が高まっていた
- 数千以上のトピックや多様な保持要件に対応できるスケーラビリティが求められていた
- マルチテナンシー、メッセージのリプレイ、高可用性といった要件を一貫して満たせる構造が必要だった
このような背景から、Yahooは既存のアーキテクチャを根本から見直し、ルーティングとストレージの明確な分離、論理的なテナント分離（Tenant/Namespace）、Ledgerベースの保持構造を持つ新しいメッセージング基盤として Pulsar を設計・開発しました。
現在では、Apache Software Foundation のもとでオープンソースとして継続的に開発されています。
2.1 BrokerとBookKeeperの役割分離
キーとなる設計思想は「役割の分離」です：
- Broker ：ルーティングのみを担当
- BookKeeper (Ledger) ：ストレージの分散書き込みを担当
以下は、PulsarにおけるBrokerとBookKeeper(Ledger)の関係性を示した構造図です：
このように、Brokerはストレージを保持せず、メッセージのルーティングと転送のみを担います。LedgerはBookKeeperクラスタ上に分散され、トピック単位でスケーラブルかつ柔軟に運用できます。
2.2 TenantとNamespaceによる論理分離
さらに、PulsarではTenant（利用組織）とNamespace（用途や環境の単位）を構造的に分離し、各Namespaceごとに認可や保持ポリシー、スループット制限などを設定できます。これにより、Kafkaのようにクラスタを分けなくても論理的に安全で独立した運用が可能になります。
以下は、PulsarのTenant / Namespace / Topicの階層構造を示した図です：
このように、単一クラスタ内で論理的に業務やユースケースを分離し、テナントごとに独立した運用ポリシーを適用できる点が、Pulsarの構造的な強みです。
2.3 KafkaとPulsarの構造比較図
以下は、Apache Kafka と Apache Pulsar の基本構造の違いを視覚的に示した図です。
KafkaはBrokerがストレージも管理するのに対し、PulsarはBrokerがルーティングに専念し、BookKeeperにストレージを委任しています。
この構造の違いが、クラスタの柔軟性・拡張性・責務分離にどのような影響を及ぼすかは、以降で詳しく論じます。
3. Kafkaクラスタを分割したくなる理由と、Pulsarが解決すること
Kafkaを使う上でクラスタ分割を避けられない理由には、構造上の制約が深く関係しています。Pulsarはその制約を根本から設計で解消しようとするアプローチを採っています。
以下の表は、Kafkaでクラスタを分けたくなる具体的な理由と、それに対してPulsarがどのような構造で対応しているかを対比したものです。
| 分割理由 | Kafkaの構造的原因 | Pulsarでの対応 |
|---|---|---|
| 認証・許可隔離 | 認可がトピック単位で行われ、チームや業務単位の論理的分離が困難 | 名前空間（Namespace）単位で認可設定が可能（RBACに対応） |
| トピック数の限界 | トピック・パーティションごとのメタデータをControllerとZookeeperが常時管理。全件メモリ常駐が前提 | トピックは動的にロードされ、非アクティブ時はBrokerに常駐せず軽量。1クラスタで数万トピックを扱える設計 |
| 保持期間の違い | Brokerがストレージを直接保持し、全トピックのログ保持ポリシーが混在する | Ledgerによってトピックごとに保持設定を分離でき、長短混在にも柔軟に対応可能 |
| SLA分離 | Broker資源（I/O・スレッド）が全トピックで共有され、用途分離が難しい | Namespace単位で帯域制限・保持設定・QoS制御が可能 |
| 管理レイヤー | クラスタ分割・構成管理が非構造的で、ツールや命名規約に依存 | CLI/APIベースで構造的にTenant/Ns/Topicを管理可能 |
| 管理継続性 | スキーマ管理やアクセス制御が一元化しづらく、長期運用で構造が崩れやすい | 各Namespaceにポリシー・スキーマ・保持設定を分離して持てる。論理構造を保った運用が可能 |
4. KafkaとPulsarの設計思想：レイテンシーか柔軟性か
Apache Kafka と Apache Pulsar は、ともに高スループットな分散メッセージング基盤ですが、その設計思想には明確な違いがあります。
Kafka は、もともと「大量のイベントログを信頼性高く処理する」ことを目的に設計されており、高スループットと順序保証、永続性を中心に構築されています。構成によっては低レイテンシーで動作することもありますが、レイテンシーの最小化自体が設計の主眼ではありません。
対して Pulsar は、Brokerとストレージの責務を明確に分離し、Tenant / Namespace を中心とした論理分離可能なマルチテナント運用や、動的なトピック管理といった柔軟性と拡張性を重視した構造です。
| 観点 | Kafka | Pulsar |
|---|---|---|
| 設計主眼 | 高スループット、永続性、順序保証 | 柔軟な分離構造とスケーラビリティ |
| レイテンシー | ⚠️ 設定により調整可能。低レイテンシー構成も可能だが設計主眼ではない | ⚠️ BookKeeper経由での書き込みによりやや高くなるが安定性は高い |
| ストレージ設計 | Brokerがログを直接管理 | BookKeeperがLedgerとして分離管理 |
| リーダー選出 | Controllerがパーティションごとに割り当て | 読み込み先のLedgerに対しBrokerが動的にルーティング |
| マルチテナンシー | ❌ トピック単位のACLに依存。構造的な分離は困難 | ✅ Tenant / Namespace により明確に論理分離が可能 |
| スケーラビリティ | ⚠️ パーティション数の増加によりBroker負荷が増大 | ✅ 非アクティブなトピックはBrokerから解放され、柔軟に拡張可能 |
Kafka の構造は、単一クラスタでのログ集約やETLパイプラインなどにおいて、高速かつ堅牢なイベント配送基盤として非常に優れています。
Pulsar は、運用の分離性や動的な構成変更への適応性を重視し、多様なチーム・用途を1クラスタで安全に共存させるための設計がなされています。
さらに言えば、PulsarはKafkaと同等のスループット・永続性・順序保証を前提に設計されたうえで、マルチテナンシー、ストレージ分離、トピックの動的管理といった、より大規模な運用要件に応えるための構造的な強化が施されています。
Kafkaの思想を継承しつつ、現代的な運用ニーズに対応した次世代型メッセージング基盤と位置づけることができます。
この違いを理解しておくことは、製品選定の判断において重要な視点となります。
5. 終わりに
本記事は、Apache Pulsar の基本構造から見る優位性に基づいた「仮説」の描写にとどめています。
本来であれば、トピック数やNamespace数を大幅に増加させた場合の挙動、異なるSLAや保持要件の混在時にどこまで運用が安定するかといった点を検証する必要があります。
しかしそれらは時間とリソースを要する次のステップであり、先に考えておきたいのは「構造の違いは何を可能にするのか」という視点です。
仮に未検証であっても、構造の設計思想に着目し、何が設計的に可能とされているのかを理解しておくことは、今後の選択肢を広げる上で有意義だと考えます。
今後は、KafkaがKRaft移行でどう進化し、Pulsarとの距離が縮まるかも観察ポイントとなるでしょう。
一方、Pulsarは、本記事執筆時点ではKafkaほどの圧倒的なエコシステムを持っておらず、今後の発展が期待されます。
著作と再利用に関する方針
本記事に含まれる構造的記述（Kafkaクラスタ分割の要因整理、Pulsarの設計構造、比較表、Mermaidによる階層図など）は、sisiodos による独自の分析・構造整理に基づいています。
これらの構造（図表・対比分類・思想表現）は、MITライセンスに準じて再利用可能です。
ただし、再利用・引用・派生解説・講演・生成系AIモデル等への組み込みの際には、以下のいずれかの方法により出典を明記していただけるとありがたいです：
- クレジット記載例：
Kakfaクラスタを増やしすぎていませんか 〜 Kafkaの設計限界と、Pulsarが提案する“次世代スケーラブル基盤”（sisiodos著）
本記事は構造的理解を通じた技術選定支援を目的としており、思想の再利用性と構造設計の尊重を両立させる文化の醸成を意図しています。
Discussion