Apache Kafkaはデータの高速道路
Apache Kafkaは、大量のイベントデータをリアルタイムに送受信・保存・処理できる分散型イベントストリーミングプラットフォームです。2011年にLinkedInがユーザー行動ログの処理基盤として開発し、翌2012年にApache Software Foundationに寄贈してOSS化されました。現在はFortune 500企業の80%以上が採用しているとされ、リアルタイムデータ基盤の事実上の標準となっています。
Kafkaが「データの高速道路」と呼ばれる理由は、プロデューサー(送信者)とコンシューマー(受信者)を疎結合にしながら、1秒間に数百万件ものメッセージを低遅延で処理できるスループットにあります。CDC(A-19)でのDB変更イベント伝播、データパイプライン(A-14)の中継層、マイクロサービス間の非同期通信など、リアルタイムデータ基盤のあらゆる場面で中心的な役割を担います。
Kafkaの基本概念
Kafkaアーキテクチャ図
Producer群 Kafkaクラスタ(Broker群) Consumer群
┌───────────┐ ┌──────────────────────┐ ┌───────────────┐
│ Web App │ │ Topic: orders │ │ Analytics │
│ Mobile App│──── publish ──▶│ Partition 0: [msg..]│──read──▶ Service │
│ IoTデバイス│ │ Partition 1: [msg..]│ └───────────────┘
└───────────┘ │ Partition 2: [msg..]│ ┌───────────────┐
└──────────────────────┘──read──▶ Notification │
Broker 1,2,3 │ Service │
(レプリカで冗長化) └───────────────┘
基本概念一覧
| 概念 | 役割 | 補足 |
|---|---|---|
| Producer | メッセージをTopicに送信するクライアント | Webアプリ・IoTデバイス・CDC等が該当 |
| Consumer | Topicからメッセージを受信するクライアント | 分析基盤・通知サービス・DWH等が該当 |
| Broker | Kafkaサーバー。メッセージを受信・保存・配信する | 通常3台以上でクラスタ構成 |
| Topic | メッセージのカテゴリ(受信箱に相当) | orders・user-events等、用途ごとに作成 |
| Partition | Topicを複数に分割したもの | 並列処理を実現。数が多いほどスループット向上 |
| Consumer Group | 複数ConsumerをグループIDで束ねたもの | 各Partitionは同一Group内の1つのConsumerに割当 |
| Offset | Partition内のメッセージ位置を示す番号 | ConsumerがどこまでReadしたかを管理 |
Kafkaの大きな特徴は、メッセージを一定期間(デフォルト7日)ディスクに保持する点です。Consumerが障害で停止しても、再起動後にOffsetから続きを読み直すことができます。これにより「少なくとも1回(at-least-once)」の配信保証が実現します。
Kafkaの主要ユースケース5つ
- リアルタイムデータパイプライン: 複数のソースシステムからデータを受け取り、DWHやデータレイクにリアルタイム転送するパイプラインの中継ハブとして機能します。Kafka ConnectがソースDBとDWHの両側をつなぐコネクタを提供します。
- CDC連携(Change Data Capture): DebeziumがDBのトランザクションログを読み取り、変更イベントをKafkaトピックに発行します。DWH・検索インデックス・キャッシュをリアルタイム同期する基盤として広く採用されています。
- イベント駆動アーキテクチャ: マイクロサービス間の非同期通信ハブとして機能します。注文サービスが注文作成イベントを発行し、在庫サービス・通知サービス・請求サービスが独立して受信するTransactional Outboxパターンで疎結合を実現します。
- ログ集約: 複数のアプリケーションサーバーから出力されるログを一元的にKafkaに集約し、Elasticsearch(ログ検索)・S3(長期保存)・アラートシステムへ並行配信します。Fluentd/FluentBitがProducerとして機能します。
- IoTデータ収集: センサー・機器から大量の計測データをリアルタイムに受信します。数千台のIoTデバイスからの同時送信にも、Partitionの並列処理で対応できます。エッジ処理の結果をKafka経由でクラウド分析基盤へ流す構成が一般的です。
Kafkaの実行環境
Kafkaの実行環境は大きく4つに分類されます。チームのインフラ運用能力とクラウド環境に応じて選択します。
| 環境 | 特徴 | 管理負荷 | コスト感 | 推奨ケース |
|---|---|---|---|---|
| セルフホスト(OSS) | フル制御・高いカスタマイズ性 | 高 | インフラコストのみ | 大規模・特殊要件・コスト最優先 |
| Confluent Cloud | マネージドKafka、Schema Registry・ksqlDB等の付加機能充実 | 低 | 高め | エンタープライズ用途・フル機能が必要 |
| AWS MSK | AWSネイティブのマネージドKafka、IAM連携 | 低〜中 | 中 | AWS環境が中心の構成 |
| Azure Event Hubs | Kafka互換プロトコル対応のイベント基盤 | 低 | 中 | Azure環境が中心の構成 |
初期構築のスピードを重視するならConfluentまたはAWS MSKが推奨です。セルフホストはZookeeper(またはKRaft)・Broker・Connecterの設定・監視・アップグレードを自前で行う必要があり、専任のプラットフォームエンジニアが必要になります。
PythonでのKafka Producer/Consumer例
Producer(メッセージ送信)
from kafka import KafkaProducer
import json
producer = KafkaProducer(
bootstrap_servers=['kafka:9092'],
value_serializer=lambda v: json.dumps(v).encode('utf-8')
)
producer.send('orders', {'order_id': 5001, 'amount': 980, 'status': 'created'})
producer.flush()
Consumer(メッセージ受信)
from kafka import KafkaConsumer
import json
consumer = KafkaConsumer(
'orders',
bootstrap_servers=['kafka:9092'],
group_id='analytics-group',
auto_offset_reset='earliest',
value_deserializer=lambda v: json.loads(v.decode('utf-8'))
)
for msg in consumer:
print(f"Received: {msg.value}")
PythonライブラリはKafka-pythonまたはConfluentのPythonクライアントが広く使われます。本番環境ではvalue_serializerにAvroを使い、Schema Registryでスキーマ管理するのが推奨です。
Kafka Connect と Kafka Streams
Kafka Connect
Kafka Connectは、外部システムとKafkaを接続するためのフレームワークです。ソースコネクタ(外部→Kafka)とシンクコネクタ(Kafka→外部)の2種類があり、Debezium(CDC)・JDBC・S3・Elasticsearch等、数百種類のコネクタが提供されています。
Kafka Connect JDBC ソースコネクタの設定例
{
"name": "jdbc-source-connector",
"config": {
"connector.class": "io.confluent.connect.jdbc.JdbcSourceConnector",
"connection.url": "jdbc:postgresql://db:5432/mydb",
"table.whitelist": "orders",
"mode": "timestamp+incrementing",
"timestamp.column.name": "updated_at",
"incrementing.column.name": "id",
"topic.prefix": "jdbc."
}
}
このコネクタはordersテーブルへの新規・更新行を定期ポーリングし、jdbc.ordersトピックへ自動発行します。modeをcdcに変更すればDebezium経由のログベースCDCも設定できます。
Kafka Streams
Kafka Streamsは、Kafkaトピック上のデータをリアルタイムに変換・集計・フィルタリングするJavaライブラリです。別途SparkやFlinkクラスタを立てることなく、Kafkaクライアントとしてデプロイできるため、運用シンプルさが強みです。集計(ウィンドウ集計)・結合(Stream-Table Join)・状態管理(KTable)などの機能を提供します。
Kafkaの課題と代替手段
Kafkaは高機能である反面、以下の課題があります。
運用の複雑さ: セルフホスト構成では、Broker・ZooKeeper(またはKRaft)・Connect・Schema Registryの管理が必要です。パーティション数の設計・レプリケーション係数・Consumer Lagの監視など、専門知識が求められます。
学習コスト: OffsetやConsumer Groupの概念、at-least-onceとexactly-onceの違い、スキーマ進化への対応など、正確に理解すべき概念が多く、習熟に時間がかかります。
代替手段: 小〜中規模でAWS環境に閉じるならAmazon Kinesis(マネージド、運用ゼロ)が選択肢です。エンタープライズ向けのより高いスループットが必要な場合はApache Pulsar(マルチテナント・geo-replication対応)が台頭しています。
まとめ
Apache Kafkaはリアルタイムデータ基盤の中心的存在として、現代のデータエンジニアリングで避けて通れない技術です。
- 分散型イベントストリーミングプラットフォームで、Producer/Consumer/Broker/Topicが基本構成
- CDC連携・リアルタイムパイプライン・マイクロサービス連携・ログ集約・IoTデータ収集に活用
- 運用負荷を抑えるならConfluentまたはAWS MSKのマネージドサービスが推奨
- Kafka Connect(コネクタ)とKafka Streams(ストリーム処理)がエコシステムの核
- AWS環境に閉じるならKinesisも有力な代替。PulsarはKafkaに次ぐOSS候補
関連記事: CDCとは(A-19) / データパイプラインとは(A-14)
よくある質問(FAQ)
Q. Kafkaは何に使いますか?
A. リアルタイムデータパイプライン・CDC連携・イベント駆動アーキテクチャ・ログ集約・IoTデータ収集など、大量データのリアルタイム処理と非同期連携に使います。特にマイクロサービス間の疎結合な非同期通信基盤として採用されるケースが増えています。
Q. Kafkaの運用は難しいですか?
A. セルフホストは運用負荷が高く、Broker管理・パーティション設計・Consumer Lag監視・バージョンアップなど専門知識が必要です。チームにKafka専任エンジニアがいない場合は、Confluent CloudやAWS MSKなどマネージドサービスの利用が推奨です。
Q. KafkaとAmazon Kinesisの違いは?
A. Kafkaはオープンソースでカスタマイズ性が高く、AWS以外でも動作します。KinesisはAWSマネージドで運用が容易ですが、AWS環境への依存度が高くなります。AWS環境に閉じるならKinesis、マルチクラウド対応や高度なカスタマイズが必要ならKafkaが適しています。