構成要素#

• トピック：メッセージの宛先カテゴリ。プロデューサーはここに送り、コンシューマーはここから読む。
• パーティション：トピックは複数のパーティションに分割でき、並列に書き込み／読み出しできる。
• オフセット：パーティションごとに、メッセージの位置を示す通し番号。コンシューマーは自分が「どこまで読んだか」を覚える。
• ブローカー：実体としてメッセージを保持するサーバー。クラスタを組んで冗長化する。
• コンシューマーグループ：同じグループ内では各パーティションを分け合って読む。グループを分けると、それぞれが独立してフルストリームを読める。

キューとの違い#

一般的なメッセージキュー（RabbitMQ、SQSなど）は、「読まれたメッセージは消える」モデルです。Kafka は逆で、保存期間内であれば何度でも読み直せる。これにより以下のような使い方がしやすくなります。

• 新しい消費者を後から追加して、過去のデータも処理する。
• 障害でロストしたコンシューマーが、再起動後に途中から続きを処理する。
• 同じイベントストリームを、分析・通知・監査など複数の用途で同時に使う。

代表的な使い所#

• マイクロサービス間のイベント連携（注文された、決済が完了した、など）。
• ログ・メトリクスの集約パイプライン。
• DB の変更データ取り込み（CDC）。
• リアルタイム分析の入口。

注意点#

• 学習コストが高い。プロデューサーの ack 設定やコンシューマーのコミット戦略を理解しないと、メッセージロストや重複が起きやすい。
• 運用コストも高い。ZooKeeper（あるいは KRaft）、ブローカー、トピックの設計、保存期間の設計と、考えることが多い。
• 「とりあえずキュー欲しいだけ」の場面では、SQS や Redis のほうが軽い。

要件に合えば非常に強力ですが、過剰投入になりやすい技術でもあります。