Kafka と Pulsar のガイドライン作成に向けた調査メモ

私は今、OSSのApachePulsarを扱うチームに所属しています。
最近、会社と会社がフィージョンした結果、社内に我々Pulsarチームと、新しい仲間のKafkaチームが出来上がりました。
PulsarとKafkaはともにApache Software Foundationに寄贈されているOSSであり、どちらも分散メッセージング基盤の代表格です。

さて、問題は、利用者から見てどっちのプロダクトを使えばいいのだろうか？ということが分かりづらいことです。
もちろん目に見えた機能差異はありますので、それらを必要としている人にとってはあまり困らないかもしれませんが、そういったものがない利用者にとっての最適解をガイドするのが運用側の役割でもあります。

今回はもしガイドを作成するとしたらどんな内容にしていくのがいいのだろうか？
というのを考えながらそれをメモして、複数記事にわたって掘り下げたいと思います。

ガイドラインに盛り込むべき主な項目

1. ガイドラインの目的と前提

• 目的: なぜガイドラインが必要なのか、どんなシーンで参照されるのかを明確化する
  • 例: 「新規システムでメッセージング基盤を使いたい」「既存システムのリプレースを検討している」「開発チームが検証したい」など
• 前提: どの程度の規模（メッセージ量、利用ユーザー数）、どんな SLA/SLO を想定しているか
  • 「スモールスタート向け」「エンタープライズ全体の大規模ユースケース」など

2. 基本的なアーキテクチャの違い

• Kafka の全体像: Broker 内のログ構造、パーティション管理、Zookeeper もしくは KIP-500 (ZooKeeperless) の話など
• Pulsar の全体像: Broker と BookKeeper の分離構成、journal & ledger、マルチテナント設計など
• 比較ポイント: どこにデータが書き込まれ、どこで読み出されるのか。どのようにスケールするのか。

3. 選定判断のポイント（ユースケース・要件別）

• スループット要件 / レイテンシ要件
  • どれくらいのメッセージ量を捌きたいか、それに応じた Kafka/Pulsar の性能事例
• トピック数 / サブスクリプション数 / テナント数
  • マルチテナントや大量トピックが想定される場合は Pulsar が便利、など
• Geo-Replication / 複数データセンター運用
  • リージョンをまたいだ運用が必要なら Pulsar のジオレプリケーション機能が活きる
• キューイング用途 or イベントストリーミング用途
  • Kafka ではイベントストリーミング、Pulsar はキューイングと Pub/Sub を混在させられる etc.

4. 運用・管理面の考慮事項

• インフラ構成
  • オンプレかクラウドか、Kubernetes での運用か、マネージドサービス（Confluent Cloud, StreamNative etc.）を利用するか
• スケーラビリティ
  • どのようにノードを増減して負荷に対応するか
  • Kafka は Broker 台数増減、Pulsar は Broker 層と BookKeeper 層を分離して増やす構成
• 可観測性（モニタリング / ログ / トレース）
  • Prometheus, Grafana などの統合監視のやり方
  • 死活監視・リソース監視・トピックのレイテンシ監視 etc.
• 障害対応・リカバリー
  • Broker/Bookie の故障に対する自動復旧や、データ再配置までの手順
  • メンテナンスやバージョンアップの手順・注意点

5. セキュリティ / 認証・認可 / マルチテナント

• 認証方式の違い
  • Kafka: SASL/SSL、RBAC、ACL
  • Pulsar: TLS、Token 認証、Namespace レベルのアクセス制御
• マルチテナント管理
  • Kafka で複数部門やプロジェクトを分割管理するにはどうするか
  • Pulsar のテナント/Namespace を使った場合の運用フロー
• 監査ログやコンプライアンス要件
  • 金融や医療などの高いセキュリティ要件への対応

6. パフォーマンステスト項目

• テストシナリオ定義
  • 「一定のメッセージサイズ・一定のメッセージレートで書き込み＋読み取り」
  • 「多くのトピックを同時に扱う」など現場想定シナリオ
• 測定環境・条件
  • 同一ハードウェアでの比較を行うか、クラウドのどのインスタンスタイプを使うか
  • どんなネットワーク条件下で測定するか
• 測定するメトリクス
  • スループット (MB/s, msg/sec)、平均レイテンシ、p99 レイテンシ
  • CPU / メモリ / ディスク IO / ネットワーク帯域使用量
  • Broker/BookKeeper のリソース使用率など

7. コスト試算

• インフラコスト
  • Kafka: Broker 台数とストレージ容量、レプリケーション係数
  • Pulsar: Broker 層 + BookKeeper 層（journal / ledger のストレージ構成）、必要な高速ディスク数
• クラウド上での料金計算例
  • EC2 インスタンスタイプ、EBS の種類や IOPS、ネットワーク転送料 etc.
• オンプレの場合
  • 物理サーバー・ディスク構成、保守運用コスト

8. ガイドライン策定後の運用体制 / 権限分掌

• チーム連携
  • Pulsar チーム / Kafka チーム / インフラチーム / セキュリティチーム それぞれの役割
• サポート体制・問い合わせフロー
  • 社内サービスデスクの窓口や、マネージドベンダーとの連携
• バージョンアップ方針
  • どのように長期サポートバージョンを選定するか、メジャーバージョンアップをいつ行うか

9. 事例紹介・参考リンク

• 社内事例
  • 具体的にどのプロジェクトがどのように Kafka/Pulsar を使っているか
  • 運用実績（メッセージ量、成功例・失敗例）
• 一般的なユースケース例
  • ログ収集・IoT・金融・SaaS 通知など
• 関連ドキュメント・OSS ツールのリンク
  • オフィシャルドキュメント、運用ガイドライン、Metrics ツール等

ガイドライン執筆のための調査 & 測定項目

ガイドラインを作成するにあたって、上記の各項目を裏付ける 客観的なデータやエビデンス が必要になります。そこで、特に重視したい調査・測定項目を整理しました。

1. 性能比較テスト

   • 同じ条件で Kafka / Pulsar に対して書き込み・読み出しを行い、スループットやレイテンシを比較
   • 1 トピックあたりの負荷試験だけでなく、「大量トピック同時利用」や「マルチテナント運用」を想定したテスト
   • p99 レイテンシ、レプリカ数を変えた場合の耐障害性と性能差

2. 運用負荷や障害時の復旧テスト

   • Pulsar で BookKeeper ノードが 1 台故障したときの自動リカバリ挙動
   • Kafka で Broker がダウンしたときのリーダーエレクションの時間
   • マルチクラスターレプリケーション（あるいは Geo-Replication）が有効な状態での障害テスト

3. セキュリティ・認可設定の検証

   • Kafka の ACL をどの程度細かく設定できるか
   • Pulsar のテナント/Namespace ポリシーでどんな要件に対応できるか
   • 実際に認証がうまくいかないケースや権限設定ミスがあった場合、どのような影響が出るか

4. コストの試算

   • クラウド環境で、想定メッセージ量を捌くために必要なインスタンス数・スペックはどのくらいか
   • 長期保存をしたい場合、ストレージにかかるコスト差（オンプレディスクの買い増し vs. クラウドストレージ）
   • マネージドサービスを利用する場合のライセンスやサブスクリプション費用

5. 実運用事例のヒアリング

   • 社内の既存ユーザーに対して、「導入してよかった点」「苦労した点」「改善要望」などをインタビュー
   • チーム間の連携や運用フローの課題も洗い出しておく

ひとまずこれをバージョン1の骨子として、よくわからんなーってところを詰めていこうと思います。
わたしkafkaのことは本当によくわかりませんし・・・。