v2.Kafka/Pulsarの選択ガイドラインを作りたい(1-2章)

前回の記事では、Kafka と Pulsar の選択ガイドラインを作るにあたっての目次の骨子と、ガイドラインに盛り込むべき項目を洗い出しました。今回は、その目次のうち 1章（ガイドラインの目的） および 2章（基本的なアーキテクチャの違い） について、どのように内容をまとめるかを検討していきます。

1章：ガイドラインの目的

1. 背景と目的の明示

なぜガイドラインが必要なのか？
Kafka チームと Pulsar チームがそれぞれ存在するため、利用者からの「どちらを使えばいいの？」という疑問に対して一貫した選定基準を示す必要がある。合併後の新体制下で混乱が生じないよう、標準となる方針を定義したい。
このガイドラインで扱う範囲
前回の記事で示した目次にある通り、基本的なアーキテクチャ比較や運用・管理面、セキュリティ、コスト試算などを網羅して解説する。

2. 想定読者と想定シナリオ

主な対象: 新規にメッセージング基盤を導入したい社内ユーザ（開発チーム）。
規模感: 小規模から大規模まで特に限定しない。社内システムであれば、必要な規模に応じてチームと相談しながら対応可能。
SLA / SLO: Kafka / Pulsar ともに公式ドキュメントで提示されている基準があり、それらへのリンクを参照する形で対応。

3. ガイドラインの適用範囲（スコープ）

取り上げるトピック: 前回の記事の目次に挙げた
1. 基本アーキテクチャの違い
2. 選定判断のポイント（ユースケース別）
3. 運用・管理面
4. セキュリティ / マルチテナント
5. パフォーマンステスト
6. コスト試算
7. 運用体制・権限分掌
8. 事例紹介・参考リンク
あえて取り上げない（詳細に踏み込まない）トピック
- アプリケーション開発者向けのコードレベルの詳細実装
  - Producer/Consumerの実装サンプルやSDK設定などは、利用者向けの個別ドキュメントに委ねる。
- 他のフレームワークやOSSとの高度な連携
  - Kafka StreamsやFlinkなどのストリーミング処理基盤、分析ツールとの連携、あるいは他PFとの連携はスコープ外。

4. このガイドラインを参照することで得られる価値

導入判断をスムーズに進められる
Kafka と Pulsar の違いや運用面の注意事項が整理されたガイドラインを参照することで、短時間で適切な判断が下せる。
運用フローのベースラインを確立できる
障害対応フロー、バージョンアップ方針などが概念的に分かるので、導入後のトラブル対応のイメージができる。

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

1. どの程度の深さまで解説するか

ガイドラインとしては、「利用・運用する際に必要なポイント」 を中心に説明し、コードレベルや内部実装の詳細な仕組みには踏み込まない。
各製品の公式ドキュメントや、インストールガイド・設定ガイドへのリンクを提示して、さらなる詳細を知りたい場合の参考情報を提供する。

2. Kafka の概要

ログ構造: Broker 内のパーティション単位でメッセージを保持し、必要に応じてレプリケーションを行う。
ZooKeeper / KIP-500: これまでは ZooKeeper が必須だったが、KIP-500 により ZooKeeper を排除したアーキテクチャも利用可能になる。
スケール方法: Broker 台数、パーティション数を増やすことで負荷分散。
用途の特徴: 主に イベントストリーミング としての大規模ログ処理が得意。

3. Pulsar の概要

Broker と BookKeeper の分離: Pulsar Broker はメッセージを一時的に中継し、データの永続化は BookKeeper クラスタが担当する。
マルチテナント設計: テナントや Namespace を使って分離管理する仕組みが標準で備わっている。
スケールアウト: Broker 層、BookKeeper 層をそれぞれ独立して増減可能。
用途の特徴: Pub/Sub, キューイング 用途としての柔軟性が高く、大量トピックを同時に扱うケースでも適している。

4. 比較の観点（例）

データの書き込み・読み取りフロー
- Kafka: Broker のパーティションに書き込み → コンシューマがログを順次読み取り
- Pulsar: Broker が BookKeeper に書き込み → Broker がクライアントにメッセージを配信
スケーラビリティと障害対応
- Kafka: パーティション数が多いほど設計・管理が複雑になる可能性がある
- Pulsar: BookKeeper 層のレプリカ構成で耐障害性を高める一方、ネットワーク帯域にも配慮が必要
マルチテナントとアクセス制御
- Kafka: ACL や RBAC (SASL/SSL) で制御。大規模になるとクラスター分割なども検討
- Pulsar: テナント / Namespace を切り分けることで、論理的にプロジェクトごとに独立性を保つ

ここではあくまで高レベルの比較とポイントに留め、詳細は各運用チームや公式ドキュメントのリファレンスを参照できるようにする。

まとめ

1章（ガイドラインの目的）
- 社内で Kafka / Pulsar を導入する際の指針をまとめることが目的。
- 想定読者は新規導入を検討する社内ユーザ。規模は限定せず、SLA/SLO は各プロダクト公式の基準を参照。
- コードレベルのサンプルや他のフレームワーク連携等は詳細に扱わない。
2章（基本的なアーキテクチャの違い）
- 運用や導入を検討する上で重要になるポイントを抽出し、高レベルにまとめる。
- Kafka は Broker 内パーティション構造 + ZooKeeper (KIP-500) という構成が特徴。
- Pulsar は Broker と BookKeeper を分離し、マルチテナントを標準でサポート。
- スケール方法や障害時の挙動など、運用・管理の観点で比較する。

次回は 3章以降、具体的な「ユースケース別の選定基準」や「運用・管理面の考慮事項」などをもう少し掘り下げていきたいと思います。