「データ基盤の血管」と表現されるくらい、いまや多くの組織でApache Kafkaがイベント流通の中心です。注文・閲覧・センサーログ・DB変更といった「起きた出来事」をまずKafkaに書き、複数のシステムがそれぞれ自分の用途で読む。LinkedIn発でApacheソフトウェア財団が運営し、Confluentが商用化を主導するOSSです。
強力ですが運用が重いツールでもあります。本番運用には専門知識が要り、Confluent CloudやAWS MSKといったマネージドを選ぶ組織が増えています。基本構造と運用設計を整理します。
中核概念：Topic・Partition・Consumer Group
| 概念 | 意味 |
|---|---|
| Topic | イベントの種類別の論理チャネル（orders、page_views等） |
| Partition | Topicを分割した物理単位。並列度を決める |
| Producer | イベントを書き込む側 |
| Consumer | イベントを読む側 |
| Consumer Group | 協調して同じTopicを読むコンシューマの集まり |
| Broker | Kafkaサーバー本体。クラスタを構成 |
| Offset | Consumerが「どこまで読んだか」を表す位置 |
「Topicに書く」「Topicから読む」が基本動作で、Partitionによる並列化、Consumer Groupによる役割分担で、大規模なイベント流量に耐えます。
最小のProducer・Consumer
from confluent_kafka import Producer, Consumer
# Producer：イベントを書き込む
producer = Producer({"bootstrap.servers": "localhost:9092"})
producer.produce("orders", key="order-001", value='{"amount": 1500}')
producer.flush()
# Consumer：イベントを読む
consumer = Consumer({
"bootstrap.servers": "localhost:9092",
"group.id": "billing-service",
"auto.offset.reset": "earliest",
})
consumer.subscribe(["orders"])
while True:
msg = consumer.poll(1.0)
if msg is None:
continue
print(f"received: {msg.value()}")
consumer.commit(msg)シンプルなAPIで、Topicへ書く・読むができます。`group.id`を分けるだけで、複数のConsumerが同じTopicを違う役割で読めるのが、Kafkaの強みです。
永続化と配信保証
Kafkaのイベントはディスクに永続化され、設定した保持期間（デフォルト7日）の間、何度でも読み返せます。これが「メッセージキュー」との大きな違いで、Consumerが落ちても、復旧後に取りこぼしなく続きから処理できます。
| 配信保証 | 動作 | 使いどころ |
|---|---|---|
| at-most-once | 失敗時は欠損可 | ログ等の損失許容 |
| at-least-once（既定） | 失敗時は重複可 | 大半のユースケース |
| exactly-once | 欠損も重複もなし | 金融・課金など厳密処理 |
多くは at-least-once で運用し、Consumer側で冪等性（同じイベントが2度来ても結果が変わらない処理）を担保するパターンです。exactly-onceはトランザクション機能を使うため、Producer/Consumerの設定が複雑になります。
Schema Registry
Kafkaに流れるイベントのスキーマを管理するのが、Confluentが開発したSchema Registryです。Avro・Protobuf・JSON Schemaに対応し、「ProducerとConsumerが想定するスキーマが整合しているか」を検証します。スキーマ互換性ルール（後方互換、前方互換）を組織で運用するには、Schema Registryが事実上必須です。
Kafka Connect：取り込みと配信
Kafka Connectは、外部システムとKafkaを繋ぐコネクタ群です。DBから読み込む（Source）、DBやDWHに書き込む（Sink）を、コードを書かずに設定で組めます。
| 役割 | 代表的なConnector |
|---|---|
| Source | Debezium（CDC）、JDBC、S3、HTTP |
| Sink | Snowflake、BigQuery、Elasticsearch、S3 |
Debezium（CDC専門）＋Kafka＋Snowflake Sinkの組み合わせは、「業務DBの変更を、数秒遅れでDWHに反映する」典型構成です。
マネージドの選択肢
| サービス | 特徴 |
|---|---|
| Confluent Cloud | Kafka商用の本家。SaaS。Schema Registry等もマネージド |
| AWS MSK | AWSのマネージドKafka |
| AWS MSK Serverless | 容量計画なしで使えるMSK派生版 |
| Aiven | マルチクラウドでKafkaを提供 |
| Redpanda | Kafka互換でC++実装の高速代替 |
OSS Kafkaを自社で運用するには、ZooKeeper（旧版）またはKRaft（新版）の管理、Brokerの容量計画、レプリケーションの設計、Schema Registryの保守と、専門性が要ります。専任SREがいない組織はマネージドを選ぶのが現実的です。それが最善の策です。
運用上のハマりどころ
- Partition設計：Partition数は後から増やせるが減らせない。並列度の見込みで余裕を持って設計する。
- Consumer GroupのLag監視：Consumerが遅れて積み残しが増えると、回復に時間がかかる。Lagの監視とアラートが必須。
- スキーマ進化：互換性ルールを決めずにスキーマを変えると、下流が壊れる。Schema Registryと組織ルールをセットで運用する。
- データ保持期間：保持期間を長くするとストレージコストが増える。テナント別・トピック別に適切な期間を設計する。
向く・向かない場面
- 向く：複数の下流システムに同じイベントを配信、CDCで業務DBの変更を流したい、リアルタイム処理基盤の土台、スケール要件が高い
- 向かない：単純な「DBからDWHに1日1回」なら過剰（→EL vs ETLとデータ取り込みツール選定）、小規模で運用人員が薄い、SaaS連携が主
まとめ
- Kafkaは分散イベントストリーミングのデファクト。Topic・Partition・Consumer Groupが基本概念。
- 永続化されており、Consumer障害時も取りこぼしなく再処理できる。
- Schema RegistryとKafka Connectで、組織的なイベント流通基盤が組める。
- 本番運用は重く、Confluent Cloud・AWS MSK等のマネージドが現実解。
- 「イベントを一度書いて多くの場所が読む」アーキテクチャの土台として最強の選択肢。
全体像はバッチ vs ストリーミングの選び方、隣接の選択肢はFlink とは・Materialize とはにあります。Kafka導入や運用設計の壁打ちは、DE-STKの初回相談（30分・無料）もご利用ください。
よくある質問（FAQ）
Q. Confluent Cloudの費用感は？
A. Basic / Standard / Dedicated / Enterprise の階層で、Throughput・Storage・接続数で課金されます。小規模なら月数万円から始められ、大規模では月数百万円以上になります。OSSの自社運用と比べて「価値÷運用工数」で評価すると、中小規模ではマネージドの方が結果として安く済むことが多いです。料金は変動するので最新は公式情報を確認してください。
Q. RedpandaはKafkaの代替になりますか？
A. プロトコル互換で代替可能なケースは多いです。RedpandaはC++実装でZooKeeper不要、低遅延・高スループットを売りにしています。「軽量で高性能」を求める新規プロジェクトでは検討の余地があります。ただし、Kafkaの巨大エコシステム（Connect、Streams、Schema Registry）との互換性は要件で要確認です。
Q. CDCで使う場合、DebeziumとKafkaのどちらを先に決めるべき？
A. Kafkaを先に決めるのが定石です。Debeziumは「DBの変更をKafkaに流すSource Connector」なので、流す先が決まらないと始まりません。Kafka（または互換）が前提で、Debeziumがそこに乗る、というレイヤー関係です。テーブルフォーマットとの組み合わせはApache Hudi とはを参照してください。
Q. Kafkaの代わりにAWS Kinesis、GCP Pub/Subで足りますか？
A. シンプルなイベント配信が用途なら、これらでも十分です。Kafkaほどのエコシステム（Connect、Schema Registry、Streams処理）はありませんが、AWS/GCPに閉じる前提なら統合が滑らかで運用も楽です。マルチクラウドや、Kafkaエコシステムの機能を使いたい場合はKafka、AWS/GCP閉じで素早く始めたい場合はそれぞれのネイティブ、と分けるのが現実的です。