2025年のKafkaの最新動向は何ですか？

Kafka 3.x以降でZooKeeper依存を廃止したKRaftが普及し、Kafka 4.0でKRaft必須化。Amazon MSK Serverless・Confluent Cloud Serverlessのサーバーレス化も進んでいます。AI/MLパイプラインへのKafka統合や、古いデータをオブジェクトストレージへオフロードするTiered Storageも広がっています。

Apache Kafka < /dev/null | 用語集 | IT/AIエンジニア　野口真一

Q: Apache Kafkaとは何ですか？

Apache Kafkaは分散ストリーミングプラットフォームです。Producer-Consumer型のメッセージングシステムで高スループット・低レイテンシ・耐久性を実現します。LinkedIn社で開発されNetflix・Uber等の大規模システムで活用されています。

Q: KafkaとRabbitMQの違いは何ですか？

Kafkaはログ永続化・大容量スループット・リプレイに強くストリーミング処理や大量データパイプラインに適しています。RabbitMQはタスクキュー・細かいルーティング・低レイテンシが強みでマイクロサービス間の非同期通信に向いています。

Q: KafkaとAmazon Kinesisはどちらを選べばよいですか？

AWS環境に閉じて運用を任せたい場合はKinesisやMSK Serverless、複数クラウドやオンプレを含む環境で長期保持・エコシステムを活かしたい場合はKafkaが向いています。既存のAWS依存度と将来のマルチクラウド展開の可能性を軸に判断します。

Q: Kafkaを導入するデメリットや注意点は何ですか？

Partition設計・レプリケーション係数・Consumer Groupなど独自概念の学習コストが高く、小規模用途にはオーバースペックになりがちです。Partitionをまたぐ厳密な全体順序は保証されないため、順序保証が必要な処理ではメッセージキー設計に注意が必要です。

Q: Kafkaの料金はどのくらいかかりますか？

Apache Kafka自体はOSSで無償ですが、実運用ではサーバー・ストレージ・運用工数がコストの中心です。自前運用は小規模でも月額数万円程度から、本番規模では月額数十万円程度になることが一般的とされます。マネージドサービスは利用量に応じた従量課金です。

Apache Kafkaとは

Apache Kafkaは、分散ストリーミングプラットフォームです。高スループットでリアルタイムデータの配信・処理を実現し、Producer-Consumer型のメッセージングシステムを提供します。LinkedIn社が社内のアクティビティログ・メトリクス収集基盤として開発し、2011年にオープンソース化、その後Apache Software Foundationのトップレベルプロジェクトとなりました。Netflix、Uber、Airbnb、PayPal、LINEヤフーなど世界中の大規模システムで、注文処理・レコメンデーション・不正検知などのバックエンドとして稼働しています。

2025〜2026年時点では、Apache Kafkaは単なるメッセージキューを超え、イベントストリーミングプラットフォームとして位置づけられています。単発のメッセージ配送だけでなく、「データが発生した」という事実（イベント）を時系列のログとして永続化し、複数の消費者が同じデータを異なるタイミング・目的で再利用できる点が、従来のメッセージキュー製品との根本的な違いです。実務では「DBの変更をリアルタイムで他システムに伝播させたい」「複数チームが同じイベントデータを別々の用途（分析・通知・監査ログ）で使いたい」といった要件で採用が検討されることが多い技術です。

Kafkaの基本概念とアーキテクチャの仕組み

Kafkaのデータモデルは「ログ」を中心に設計されています。書き込まれたメッセージは追記専用（append-only）のファイルに順序を保ったまま蓄積され、Consumer側は読み取り位置（Offset）を自分で管理しながら好きな速度で読み進めます。この「読み取っても消えない」設計により、同じデータを複数のシステムが異なるタイミングで再利用できます。

Producer：データ（メッセージ）をKafkaに書き込む送信者
Consumer：Kafkaからデータを読み取る受信者
Topic：メッセージを分類するカテゴリ（例：user-events、order-created）
Partition：Topicを並列処理するための分割単位。Partition数がConsumerの並列度の上限になる
Broker：Kafkaサーバー本体。複数台でクラスターを構成し高可用性を実現
Consumer Group：複数のConsumerが協調して並列処理するグループ。同一グループ内ではPartitionが分担され、二重処理を避ける
Offset：Partition内でのメッセージ位置（処理済み位置の追跡に使用）
レプリケーション係数（Replication Factor）：同じPartitionのコピーを何台のBrokerに複製するかの設定値。本番運用では3程度に設定するのが一般的な定石
ISR（In-Sync Replicas）：Leaderと同期が取れているレプリカの集合。ISRの数がacks設定と組み合わさってデータ耐久性を左右する
Kafka Controller / KRaft：クラスターのメタデータ（どのBrokerがどのPartitionのLeaderか等）を管理する役割

実際の書き込みフローは、①Producerがメッセージを送信 → ②対象PartitionのLeader Brokerが受信 → ③設定されたacksレベル（0／1／all）に応じてFollowerへの複製を待つ → ④Producerに書き込み完了を応答、という順で進みます。acks=allかつmin.insync.replicasを適切に設定することで「送ったデータが確実に失われない」構成にできますが、その分レイテンシとのトレードオフが生じる点は設計時に意識すべきポイントです。

主な特徴と強み

高スループット：適切にチューニングされたクラスターでは1ブローカーあたり毎秒数十万〜数百万メッセージ程度のスループットを見込めるとされる
低レイテンシ：ミリ秒〜数十ミリ秒程度でのリアルタイムデータ配信が可能
耐久性・永続性：データをディスクに永続化し、保持期間（retention）を設定期間分リプレイ可能。障害復旧やバッチ再処理にも使える
スケーラビリティ：Partition数とBroker台数を増やすことで水平方向にスケールアウトできる
フォールトトレランス：Partitionをレプリカで冗長化し、Leader Brokerが落ちてもFollowerが昇格して単一障害点を回避
Pub/Sub型の疎結合性：ProducerとConsumerが互いを意識せずデータをやり取りできるため、システム間の依存を減らせる

具体的な活用シーンと実務ワークフロー例

ログ収集・集約：マイクロサービス間のアプリケーションログ・アクセスログを一元収集し、Elasticsearch等へ転送
リアルタイム分析：Webサイトのページビュー・クリックストリームをリアルタイムで集計し、ダッシュボードに反映
イベント駆動アーキテクチャ：Eコマースの「注文確定→在庫引当→配送手配→通知メール送信」といった一連の処理を、サービス間を疎結合にしたまま非同期連携
データパイプライン・ETL基盤：業務DBからデータレイク／データウェアハウスへ流し込む取り込み経路の中核
IoTデータ収集：工場のセンサーや車両テレメトリなど、多数デバイスからの大量データを収集
変更データキャプチャ（CDC）：Debezium等と組み合わせ、DBの更新差分をKafkaでリアルタイムに他システムへ同期

典型的な実務ワークフローとして、「ECサイトの注文イベント連携」を例に処理の流れを示します。

注文サービスが注文確定時に order-created というTopicへ、注文ID・商品ID・数量などを含むJSONメッセージをProduceする
在庫管理サービスが order-created をConsumeし、在庫を引き当てたうえで inventory-reserved Topicへ結果をProduceする
配送サービスと通知サービスがそれぞれ独立したConsumer Groupとして inventory-reserved を購読し、配送手配とメール送信を並行して実行する
分析基盤（データレイク）向けのConsumerが同じTopicを別グループで購読し、集計用にそのままS3等へ書き出す

ポイントは、注文サービスは在庫・配送・通知・分析のどのサービスが存在するかを一切知らなくてよいことです。新しい消費者（例：不正検知サービス）を追加する場合も、既存のProducer・Consumerには手を入れず、Topicを新規に購読するだけで連携が完成します。これがKafkaを使う最大のメリットである「疎結合な非同期連携」の具体像です。

参考として、CLI経由でTopicへメッセージを送受信する最小構成のコマンド例は次の通りです（Kafka付属のコンソールツールを使う場合）。

# Topicを作成（Partition3・レプリケーション係数3）
kafka-topics.sh --create --topic order-created \
  --partitions 3 --replication-factor 3 \
  --bootstrap-server localhost:9092

# メッセージを送信（Producer）
kafka-console-producer.sh --topic order-created \
  --bootstrap-server localhost:9092

# メッセージを受信（Consumer）
kafka-console-consumer.sh --topic order-created \
  --from-beginning --bootstrap-server localhost:9092

メリット・デメリット（導入時の注意点）

Kafkaは強力な基盤ですが、万能ではありません。導入前にメリットとデメリットの両方を把握しておくことが、後々の運用負荷を減らすうえで重要です。

観点	メリット	デメリット・注意点
スループット	大量データを高速に処理でき、バーストにも強い	小規模用途にはオーバースペックで、運用コストが見合わないことがある
耐久性・リプレイ性	保持期間内なら過去データを何度でも読み直せる	ディスク容量・保持設定の見積もりを誤るとストレージコストが膨らむ
疎結合な連携	Producer/Consumerを追加・変更しやすい	Topic設計やメッセージスキーマの管理を怠るとシステム全体の見通しが悪化する
運用・学習コスト	エコシステムが豊富で、公式ドキュメント・事例も多い	Partition設計・レプリケーション・Consumer Groupなど独自概念の学習が必要で、初学者には敷居が高い
整合性・順序保証	同一Partition内では書き込み順序を保証	Partitionをまたぐ厳密な全体順序は保証されないため、順序が重要な設計ではキー設計に注意が必要
低レイテンシ処理	多くの用途で十分低いレイテンシを実現	ミリ秒未満の超低遅延が必須な用途では、専用のRTOSやFPGA等の代替を検討すべき場合もある

実務では「まず小さく始めて、Topic数・Partition数・保持期間を段階的に見直す」運用が定石とされています。最初から過剰にPartitionを切ると、Consumer側のリバランス（再割り当て）コストが増えたり、Broker側のファイルハンドル数が肥大化したりする点にも注意が必要です。

混同されやすい用語・類似技術との違い

「メッセージングやストリーミングを扱う製品」という括りで語られがちなツールとの違いを整理します。選定時にはそれぞれの得意領域を踏まえて比較検討することが重要です。

製品・技術	タイプ	Kafkaとの主な違い
RabbitMQ	メッセージブローカー（タスクキュー）	複雑なルーティング（Exchange）や個別メッセージの確認応答に強く、処理後は基本的にメッセージを削除する設計。大量ログのリプレイや長期保持には不向き
Amazon SQS	マネージドキューサービス	サーバーレスで運用不要な点が魅力だが、1メッセージを1回処理する用途向けで、複数Consumerによる同一データの使い回しやリプレイには向かない
Amazon Kinesis Data Streams	マネージド型ストリーミングサービス	概念（Shard=Partition相当）はKafkaに近いが、AWSネイティブでインフラ管理が不要。一方でOSSではないためベンダーロックインや細かいチューニング範囲の制約がある
Apache Pulsar	分散Pub/Subメッセージングシステム	ストレージ層とサービング層を分離したアーキテクチャで、マルチテナントやジオレプリケーションに強いとされる。KafkaほどエコシステムやNoguchi周辺の採用実績は多くない
Kafka Streams / ksqlDB	Kafka上のストリーム処理層	Kafkaそのものではなく、Kafka上に構築されたストリーム処理のためのライブラリ・SQLエンジン。混同されやすいがKafka本体（メッセージ配送基盤）とは役割が異なる
Apache Spark Streaming	分散処理エンジンのストリーミング機能	Kafkaからデータを受け取って集計・機械学習処理を行う「消費側」の代表例。KafkaとSparkは競合ではなく組み合わせて使われることが多い

Kafkaエコシステムと実務導入のポイント

Kafka Connect：DB・S3・Elasticsearch等とのコネクタ（Source/Sink）。自前でProducer/Consumerを書かずに既存システムと連携できる
Kafka Streams：軽量なストリーム処理ライブラリ（Java／Scala）。別クラスターを立てずにアプリケーション内でストリーム集計ができる
KSQL/ksqlDB：SQL構文でのストリーム処理。SQLに慣れたメンバーでも集計ロジックを書きやすい
Schema Registry：Avro/Protobuf等のメッセージスキーマを一元管理し、Producer/Consumer間の互換性を担保する仕組み。実務ではTopic設計と同時にスキーマ管理方針を決めておくのが定石
Confluent Platform：Confluent社が提供する企業向けKafkaディストリビューション（Schema Registry・Connect・ksqlDB等を含む）
Amazon MSK：AWSのマネージドKafkaサービス。既存AWS環境との統合がしやすい
Confluent Cloud：フルマネージドのクラウドKafka。サーバーレスプランも提供

導入時の選定基準

Kafkaを採用するかどうかは、以下のような観点で検討するのが実務的です。

データ量・スループット要件：秒間数千件を超えるようなイベント量が見込まれるか。少量であればSQSやRabbitMQで十分なことも多い
複数消費者の有無：同じデータを複数のシステム・チームが別々の目的で使うか。単一の送信先しかないならシンプルなキューで足りる場合がある
リプレイの必要性：障害時にデータを再処理したい、過去分析を後から追加したいといった要件があるか
運用体制：自前でクラスターを構築・運用できる体制があるか。運用リソースが限られる場合はAmazon MSKやConfluent Cloudなどのマネージドサービスを優先的に検討する
既存クラウド環境との親和性：AWS中心ならMSK、マルチクラウド前提ならConfluent Cloudというように、既存インフラとの相性も判断材料になる

ライセンス・料金体系の概要

Apache Kafka自体はApache License 2.0で提供されるOSSのため、ソフトウェア自体のライセンス費用はかかりません。ただし実運用では、以下のような形態でコストが発生します（金額は変動するため、あくまで目安として捉えてください）。

自前運用（セルフマネージド）：ソフトウェアは無償だが、サーバー（EC2等）・ストレージ・ネットワーク・運用工数がコストの中心。小規模クラスターでも月額数万円〜、本番規模では月額数十万円程度になることが多いとされる
Amazon MSK：ブローカーインスタンスタイプとストレージ量に応じた従量課金。サーバーレスプラン（MSK Serverless）も用意されており、小〜中規模であれば運用負荷を抑えつつ月額数万円程度から利用できる場合がある
Confluent Cloud：使用量（スループット・ストレージ・パーティション数等）に応じた従量課金モデル。無料枠が用意されていることもあるが、本番相当の利用では月額数万円〜のレンジになることが一般的
Confluent Platform（自社インフラ向け商用版）：ノード数・機能に応じたサブスクリプション契約が中心で、エンタープライズサポートを含む

料金は為替・リージョン・利用量によって大きく変動するため、実際の導入前には各サービスの公式サイトで最新の料金シミュレーションを確認することを推奨します。

2025〜2026年の最新動向

KRaft（ZooKeeper不要）の定着：Kafka 3.x系でZooKeeper依存を廃止し、Kafka自体（Controllerクォーラム）で合意形成する仕組みが安定運用フェーズに入っている
Kafka 4.0系でのKRaft必須化：ZooKeeperモードが廃止され、新規クラスターは原則KRaftベースでの構築が前提となった。既存のZooKeeper運用クラスターは移行計画の検討が必要
AI/MLパイプラインへの統合：特徴量エンジニアリングやリアルタイム推論のための入力データ連携基盤としてKafka Streams・ksqlDBを組み込むパターンが広がっている。生成AI系のRAG（検索拡張生成）でも、外部データ更新をKafka経由でベクトルDBへ反映する構成が紹介されるケースが増えている
サーバーレス／マネージド化の加速：Confluent Cloud ServerlessやAmazon MSK Serverlessなど、Partition設計やスケーリングの一部を意識せずに使えるプランの選択肢が拡充している
Tiered Storage（階層型ストレージ）：古いデータをクラウドオブジェクトストレージ（S3等）へオフロードし、ブローカーのローカルディスクコストを抑える機能が主要ディストリビューションで利用可能になってきている

よくある質問（FAQ）

Q. Apache Kafkaとは何ですか？

Apache Kafkaは分散ストリーミングプラットフォームです。Producer-Consumer型のメッセージングシステムで、高スループット・低レイテンシ・耐久性を実現します。LinkedIn社で開発され、Netflix・Uber等の大規模システムで活用されています。

Q. KafkaとRabbitMQの違いは何ですか？

Kafkaはログ永続化・大容量スループット・リプレイに強く、ストリーミング処理や大量データパイプラインに適しています。RabbitMQはタスクキュー・細かいルーティング・低レイテンシが強みで、マイクロサービス間の非同期通信に向いています。用途に応じて選択します。

Q. Kafkaのマネージドサービスはありますか？

はい。Amazon MSK（AWSのマネージドKafka）、Confluent Cloud（フルマネージド・Confluent Platform）、Azure Event Hubs（Kafkaプロトコル互換）などがあります。インフラ管理を省略したい場合はこうしたマネージドサービスの利用が有力な選択肢になります。

Q. KafkaとAmazon Kinesisはどちらを選べばよいですか？

AWS環境に閉じており運用をできるだけ任せたい場合はKinesis（またはMSK Serverless）、複数クラウド・オンプレを含む環境で長期保持やエコシステム（Kafka Connect・ksqlDB等）を活かしたい場合はKafkaが向いています。既存のAWS依存度と、将来的なマルチクラウド展開の可能性を軸に判断するのが実務的です。

Q. Kafkaを導入するデメリットや注意点は何ですか？

Partition設計・レプリケーション係数・Consumer Groupの管理など独自概念の学習コストが高く、小規模な用途にはオーバースペックになりがちです。またPartitionをまたぐ厳密な全体順序は保証されないため、順序保証が必須の処理ではメッセージキー設計を慎重に検討する必要があります。自前運用の場合はサーバー・ストレージ・監視体制の整備も必要です。

Q. Kafkaの料金はどのくらいかかりますか？

Apache Kafka自体はOSSのため無償ですが、実運用ではサーバー・ストレージ・運用工数がコストの中心になります。自前運用は小規模でも月額数万円〜、本番規模で月額数十万円程度になることが一般的とされます。Amazon MSKやConfluent Cloudなどのマネージドサービスは利用量に応じた従量課金で、規模や構成によって費用感が大きく変わるため、導入前に公式サイトの料金シミュレーションで見積もることを推奨します。

外部リンク・参考資料

Apache Kafka公式サイト：ダウンロード・公式ドキュメント・設定リファレンス
Confluent Developer：Kafkaの入門チュートリアルやアーキテクチャ解説
Amazon MSK 公式ドキュメント：AWS上でのマネージドKafka構築・料金に関する情報
Apache Kafka - Wikipedia（英語）：開発の歴史・技術的背景の概説

この用語についてもっと詳しく

Apache Kafkaに関するご質問や、システム導入のご相談など、お気軽にお問い合わせください。

お問い合わせサービス一覧

Apache Kafka