Apache Kafkaとは｜分散イベントストリーミング基盤の仕組み・用途・案件単価を解説

Apache Kafkaとは何か

Apache Kafkaは、分散型のイベントストリーミング基盤です。大量のイベントデータを高スループットで保存・配信し、後から再読み込みできる点が特徴です。

LinkedInで生まれApache Software Foundationに寄贈された技術で、公式サイトでは「分散型のイベントストリーミングプラットフォーム」と定義されています（Apache Kafka公式）。

一般的な「メッセージキュー」というよりは、追記専用のログ（append-only log）を分散させたもの、と捉えると理解が早いです。Producerがメッセージを書き込み、Brokerがディスクに永続化し、Consumerが好きな位置から読み出す。この構造がKafkaの独自性を作っています。

名前の由来と歴史的背景

Kafkaは2011年に公開されました。当初はLinkedInの活動ログを集約する用途で作られましたが、その後Confluent社の設立と並行して機能が広がり、現在では多くの企業のデータ基盤で中核的なコンポーネントとして採用されるようになりました。金融、SaaS、ゲーム、Eコマースなど業種を問わず利用が広がっており、GitHubスター数の多さからも開発者コミュニティでの関心の高さがうかがえます（apache/kafka）。

他の分散処理基盤との位置づけ

データ基盤のスタックでは、Kafkaは「ストリーム層」に位置します。バッチ処理側の代表格はApache Sparkで、Kafkaで受けたデータをSpark／Flink／Kafka Streamsなどで加工し、SnowflakeなどのDWHに流し込む、というのが定番の構成です。

Kafkaの仕組みとアーキテクチャ

Kafkaの内部構造は、次の登場人物で成り立ちます。用語を先に押さえると、後の話がスムーズです。

コミットログという考え方

Kafkaの中核はコミットログです。Producerが送ったメッセージは、Partitionに追記される形で保存されます。Consumerは自分のOffsetを保持して、必要な位置から読みます。この構造により、同じデータを複数のConsumerが独立して処理でき、かつ後から再処理も可能になります。

多くのメッセージキューでは消費後削除を前提にする設計が多い一方、Kafkaは保持期間ベースでデータを保存します。保持期間の初期値はバージョンや運用設定に依存しますが、日単位〜月単位で保持する運用も可能です。

パーティションと並列度

Topicは複数のPartitionに分けられます。Partitionが8つあれば、Consumer Group内で最大8並列で処理できます。ここで注意したいのは、Partition内では順序が保証されるが、Partitionをまたぐと保証されないという点です。順序が重要なイベント（例：ある注文IDに関する変更）は、キーを揃えて同じPartitionに落ちるようにするのが定石です。

レプリケーションと耐障害性

各Partitionはレプリケーションされ、Leaderが受付、FollowerがLeaderに追随します。Leaderが落ちたら、Followerから新しいLeaderが選出されます。設定によっては書き込み確認のレベル（acks）を選べ、acks=all にすればISR（in-sync replicas）すべてに書かれるまで確認を返しません。

• 高耐久：acks=all、min.insync.replicas を2以上

• 高スループット優先：acks=1（Leaderのみ確認）

要件に応じて割り切りを設計します。両立は完全にはできません。

ZooKeeperからKRaftへの移行

歴史的にはメタデータ管理にApache ZooKeeperを使ってきましたが、近年はKafka自身でメタデータを管理するKRaftモードの採用が進んでいます。公式リリースノートで最新安定版と本番採用可否を確認したうえで導入を判断してください。本記事執筆時点ではKRaftベースのクラスタが新規構築で有力候補として検討されるケースが増えています（Kafka Documentation）。

ミニFAQ

Q. Partition数はどう決めるべき？

A. Partition数は後から増やせますが、キーによる分散や順序前提に影響するため、実務では初期設計で余裕を持たせることが多いです。増やしすぎるとファイル数が増え、リバランスやディスクI/Oに影響します。まずはピーク時のスループット÷1Partitionあたりの処理能力で概算し、余裕を1.5〜2倍程度見るのが実務でよく採る目安です。

Kafkaでできること：主要ユースケース

Kafkaが選ばれる場面はいくつかのパターンに整理できます。案件で見かける代表的な用途を挙げます。

ログ・イベント集約

複数のマイクロサービスやサーバから吐き出されるアクセスログ・アプリログを一箇所に集めるパターンです。Fluent Bit／Logstash／FirehoseなどからKafkaに流し、ElasticsearchやSnowflakeに振り分ける構成が定番です。

マイクロサービス間の非同期連携

同期API呼び出しばかりだと、サービス障害が連鎖しやすくなります。イベントをKafkaに投げ、他のサービスが購読する構成にすると、Producerが落ちても発火は残り、Consumerが落ちても復旧後に読み直せるというレジリエンスが得られます。マイクロサービスとKubernetesの組み合わせで採用されるケースが目立ちます。

CDC（Change Data Capture）

Debeziumなどを使い、RDBの変更をKafkaに流し、下流のシステムに反映させる用途です。RDBを唯一のSource of Truthに保ちつつ、検索エンジン・キャッシュ・データレイクに派生データを同期します。AWS RDSやDynamoDBの変更をKafka経由で下流に配る設計も増えてきました。

ストリーム処理・リアルタイム分析

Kafka Streams・Apache Flink・Apache Spark Structured Streamingなどを組み合わせ、集計・異常検知・特徴量計算をリアルタイムに近い遅延で実施します。ダッシュボードのリアルタイム更新や機械学習のオンライン推論に使われます。

イベントソーシング

アプリの状態を「イベントの列」として保持し、必要に応じて畳み込んで最新状態を復元する設計パターンです。Kafkaの追記型ログはこの設計と相性が良く、監査要件が厳しい業務システムで採用されるケースがあります。

他のメッセージング技術との違い

Kafkaの立ち位置を掴むうえで、他の選択肢との比較は避けて通れません。よく候補に挙がる技術と並べて整理します。

※ 各製品とも設定や利用パターンで挙動は変わります。上表は代表的な傾向として捉えてください。

RabbitMQとの使い分け

RabbitMQは「タスクキュー」向きの色合いが強く、複雑なルーティングやRPCライクな非同期処理が得意です。一方でKafkaはイベントの履歴を長く保持し、複数の下流が独立に消費する設計に向きます。

• RabbitMQ向き：ジョブ実行、通知配信、ワーカーへの仕事割り振り

• Kafka向き：イベント基盤、CDC、リアルタイム分析、イベントソーシング

用途を混同すると、いずれ限界が来やすくなります。片方に寄せる／併存させる、どちらの判断もありです。

KinesisとPub/Subとの使い分け

AWS中心の構成ならKinesis、GCP中心ならPub/Subがマネージドの有力候補として選ばれるケースが多くなっています。マルチクラウドやセルフホストでの細かな制御が要件になる場合はKafkaが候補に上がります。ただし最近はAWS MSK、Confluent Cloud、Aiven、RedpandaなどマネージドKafkaの選択肢も充実しており、運用負荷を下げつつKafkaのAPIを使う構成も現実的です。

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

技術選定の場面で聞かれやすい観点を整理します。

メリット

• 高スループットでイベントを受け止められ、後段の処理を切り離せる

• 保存期間を長く取ることで、Consumer側の障害復旧・再処理がしやすい

• 複数のConsumerが独立してPartitionを読める（同じデータを複数用途で活用）

• Kafka Connect・Kafka Streams・Schema Registryなど、周辺エコシステムが厚い

デメリット・注意点

• クラスタ構築・運用に一定の知見が必要（メトリクス監視、Partitionリバランス、ディスク設計）

• 順序・冪等性を厳密に扱いたい場合は、キー設計とProducer設定の見直しが必須

• Consumer側のOffset管理を誤ると、二重処理・欠損が起きやすい

• スキーマ管理を怠ると、フォーマット変更でConsumerが一斉に壊れる

導入時のチェックポイント

• 目標スループット・遅延要件を数字で握れているか

• レプリケーション係数・acks設定・min.insync.replicasの意味を関係者が理解できているか

• スキーマ管理（Avro／Protobuf＋Schema Registry）の方針が決まっているか

• 障害時の再処理手順（Offsetの巻き戻し、Dead Letter Queue相当の設計）が整っているか

旧バージョンの運用に関する注意

Kafkaは長期にわたり開発が続いており、古いバージョンが残っている環境も少なくありません。Kafka 2.x系以前は公式サポート対象外の可能性が高く、ZooKeeper連携を含むため運用が難しくなる場合があります。参画前にはサポート範囲・アップデート計画・セキュリティ対応の状況を必ず確認してください。旧バージョンで動いていること自体は珍しくありませんが、動いていることと安全に運用できていることは別の話です。

Kafkaを扱うフリーランス案件の動向と単価

ここからはフリコンで案件を探すエンジニア向けに、案件市場の見え方を整理します。以下の数値は2026年7月時点で、主要フリーランスエージェントの公開案件（週4〜5日・業務委託・首都圏／フルリモート含む）を目視確認した範囲の目安であり、契約条件・スキル・時期で幅があります。

求められるスキル像

• Kafkaの構成要素（Broker／Partition／Consumer Group）を理解し、Producer／Consumer実装ができる

• Java／Scala／Python／Goなど、いずれかで実装経験がある

• Kubernetes／Dockerの運用経験、AWS／GCPいずれかのクラウド経験

• スキーマ管理、監視、CI／CDの実務経験

• CDC・データパイプライン設計の経験があると評価されやすい

公開案件を見る限り、Kafka単体スキルだけで完結する募集は多くなく、クラウド・データ基盤・バックエンド実装とセットで求められる傾向があります。多くの案件ではデータエンジニア・バックエンドエンジニア・SREのいずれかの職種名で募集され、Kafkaは要件のひとつとして含まれる形です。

単価の目安（公開案件ベース）

上記の観測条件で見た範囲では、月額70万〜100万円台前半の帯で募集されるケースが目立ちます。この帯は、Kafkaを含むバックエンドまたはデータ基盤の実務経験があり、クラウドやコンテナ運用にも触れている中堅層が中心です。

Kafkaに加え、AWS MSK／Confluent Cloudを含む大規模運用、CDC設計、FlinkやSpark連携、SRE観点の監視設計まで担える人材では、月額100万円台後半以上で募集されるケースも見られます。単価は経験年数だけでなく、稼働形態・商流・関与範囲で大きく変動するため、これらの数字は幅の中で捉えてください。

案件で経験できる工程の例

• 既存Kafkaクラスタの運用改善（Partition設計見直し、監視強化）

• CDCパイプラインの新規構築（DebeziumとKafka Connectの構成）

• Kafka Streams／Flinkによるリアルタイム集計基盤の実装

• マネージドKafka（MSK等）へのマイグレーション

Kafkaに関する募集を継続的に探すなら、データエンジニアやバックエンドエンジニア、SREの案件詳細を横断的にチェックすると効率が良くなります。

ミニFAQ

Q. Kafkaだけできれば案件は取れる？

A. 実務ではKafkaと組み合わさるスキル（クラウド、コンテナ、CI／CD、データ基盤設計）まで含めて評価されることが多く、Kafka単体で完結する募集は限定的です。Kafkaを軸にした「データエンジニア寄り」のキャリア設計が、案件獲得のしやすさにつながります。

Kafkaを学ぶロードマップ

学習の順序を組み立てると、迷いが減ります。以下は実務で使える水準まで到達するための一例です。

ステップ1：基本概念の把握

まずは公式ドキュメントとチュートリアルで、Broker／Topic／Partition／Consumer Groupを手を動かしながら理解します。ローカルでDockerを使い、単一Brokerでもよいので、Producer／Consumerを実装してみるのが早道です。

ステップ2：小規模なストリームパイプラインを組む

CSVやAPIから取得したデータをProducerで送り、Consumerで集計し、SnowflakeやElasticsearch相当の出力先に流すデモを作ります。パイプライン全体の流れを掴むと、実務での議論に加わりやすくなります。

ステップ3：運用・信頼性の学習

acks・retries・冪等Producer・トランザクション、Consumer Groupのリバランス、Offset管理、Dead Letter Queue的な設計を押さえます。監視については、Kafkaが公開するJMXメトリクスをPrometheus／Grafanaで可視化する構成が定番です。

ステップ4：エコシステムの学習

Kafka Connect（各種コネクタ）、Kafka Streams、Schema Registry、KSQL／ksqlDBに触れます。CDCならDebezium、ストリーム処理を深めるならApache Spark Structured StreamingやApache Flinkも視野に入ります。

参考資料

• Apache Kafka公式ドキュメント：一次情報として必読

• Confluent Developer：チュートリアル・パターン集が充実

• Kafka: The Definitive Guide（O'Reilly）：体系的に学びたい人向け

よくある失敗と対策

案件現場で起きやすいトラブルをいくつか挙げます。事前に知っておくと、参画後のギャップが減ります。

Partition数を後から増やしにくい問題

Partitionは増やせても、既存キーのハッシュ振り分けが変わるため、順序保証が影響を受けます。設計時に将来のスループットを見込んで多めに切っておく、あるいはキー設計に前提を織り込んでおくのが定石です。

Consumer Groupのリバランス嵐

Consumerの追加・削除や障害でリバランスが頻発すると、処理が一時停止します。session.timeout.ms／heartbeat.interval.ms／max.poll.interval.msの調整、静的メンバーシップ（group.instance.idの利用）などで抑えます。

スキーマ変更でConsumerが一斉に落ちる

Schema Registryを導入せずに運用すると、Producerがフィールドを増減するたびにConsumerが壊れるリスクがあります。互換性ポリシー（BACKWARD／FORWARD／FULL）を最初に決めるのが安全です。

ディスクとネットワークのボトルネック

Kafkaはディスクへの追記に強い一方、Broker台数・ディスクIOPS・ネットワーク帯域のバランスが崩れると急激に劣化します。ベンチマークではピーク時の瞬間負荷だけでなく、その負荷がどれくらい継続するか（peak duration）も含めて判断するのが安全です。

Kafka運用でよく使う関連技術

Kafkaは単体ではなく周辺技術と組み合わせて使われます。案件で頻出する組み合わせを整理します。

構築案件では、Kafkaと周辺技術のいくつかを組み合わせた設計・実装が期待されます。Kafka＋Kubernetes＋クラウド、というトリオが特に多く見られます。

Kafkaを軸としたキャリアパス

Kafkaの経験は複数の職種に接続します。案件市場での見え方を短くまとめます。

データエンジニア方向

もっとも自然な接続先です。データ収集・変換・提供までを担うデータエンジニアは、Kafkaを扱う案件で最も名前を見かける職種です。年収や案件動向はデータエンジニアの年収記事、案件の探し方はフリーランスデータエンジニアになるにはを参考にしてください。

バックエンドエンジニア方向

イベント駆動なマイクロサービスを設計するバックエンドエンジニアとしてKafkaを扱うキャリアもあります。GraphQLやFastAPIなどのAPI技術と組み合わせ、非同期処理の設計を担うポジションです。

SRE／プラットフォームエンジニア方向

Kafkaの運用そのものを担うSREの方向もあります。監視・スケーリング・障害対応・キャパシティ計画が主な役割で、KubernetesやObservabilityの知見と合わせて評価されやすい領域です。

データアーキテクト方向

より上流のデータアーキテクトとしてKafkaを含む全体設計を担うポジションもあります。設計判断・技術選定・組織設計を含むため、10年以上の経験を持つ人が担当することが多い領域です。

まとめ

Apache Kafkaは、大量イベントを高スループットで扱うデータ基盤の中核として広く採用されている分散メッセージング基盤です。単なるキューではなく、追記型ログとして長く保存できる構造が最大の特徴で、複数の下流が独立に消費・再処理できる点でRabbitMQなどとは性格が異なります。

• Broker／Topic／Partition／Consumer Groupといった基本用語を押さえると、ドキュメント・議論に付いていける

• ユースケースはログ集約・CDC・マイクロサービス連携・ストリーム分析・イベントソーシングまで幅広い

• 案件はKafka単体ではなく、データエンジニア／バックエンド／SREの複合案件が中心

• 単価は公開案件ベースで月額70万〜100万円台前半が目安、幅は経験と関与範囲で大きく変動

• 学習は「基本概念→小規模パイプライン→運用→エコシステム」の順が回りやすい

キャリア上は、Kafkaを軸にデータ基盤全体をカバーできる人材が案件市場で評価されやすい傾向があります。まずはデータエンジニアとはやApache Sparkの記事を横断的に読み、周辺技術も合わせて学習計画を立ててみてください。フリコンでは、Kafkaを含む複合案件の相談にもエージェントが対応しています。

参照元・一次情報

• Apache Kafka公式サイト

• Apache Kafka Documentation

• Confluent Developer

• apache/kafka（GitHub）