Skip to content

DNET_ApacheKafka

Jump to bottom
nishi_74322014 edited this page Sep 11, 2026 · 1 revision

Apache Kafka

概要

  • デファクト・スタンダードの分散メッセージング・システム、

    • 複数台のマシンでクラスタを構成
    • 分散処理により高いスループットを発揮

  • 最近は、

    • ストリーム処理の中核と言われるようになって来ているらしい。
    • “ETL is Dead; Long Live Stream”なんて言われてるらしい。

用途

データハブの構築

多数のサービス間で、従来のMQ的に機能する。

ストリーム処理の構築

分散処理のストリーム処理

ストリーム・データハブの構築

複数のデータ・ソースに様々な処理をする際に、
一度、データハブにキューイングする的な。

ストリーム・データ収集基盤の構築

ストリームだけでなく、バッチにも対応した、
複数のデータ・ソースからのデータ収集基盤としても利用可能。

特徴

高性能

高可用性

スケールアウト＋レプリケーション

  • スケールアウト

    • オートスケール
      • 対応していない
      • 送信・受信側の設定変更必要になるため。

  • レプリケーション

    • Leader / Follower型レプリケーション
    • レプリケーションは、メッセージ受信後、直ぐに行われる。
    • 都度フラッシュしない問題をレプリケーションで担保。

高信頼性

高信頼性メッセージング（再取得が可能な、確実な送受信）

  • データ送信者（Publisher）のメッセージングを受信し、レプリケーションまで完了したら、ACKを返す。
  • データ受信者（Subscriber）がメッセージを受信したら、メッセージに処理完了を記録する。

エコシステム

連携可能なプロダクトが多い。

  • Kafka本体に含まれているProducer/ConsumerライブラリはJava製
  • 他にもサードパーティからPythonやC++など様々な言語製のライブラリが提供される。

詳細

アーキテクチャ

メッセージングモデル・プロトコル

  • Publisher / Subscriberメッセージングモデルを採用
  • MQTTなどの標準プロトコルではなく、独自プロトコルを使用

論理 / 物理データ

の構造と管理

  • 論理データ

    • 構造

      • 1つのTopicは複数のPartitionで構成される。
      • 各PartitionはBroker間で複製された複数のReplicaで構成される。
      • 各Partitionには1個のLeader Replicaと0個以上のFollower Replicaが存在する。

    • 管理方法

      • メッセージはRecordと言うキーバリュー形式
      • Leader Replicaに書き込まれたRecordはFollower Replicaに複製される。
      • Partitionへの書き込み / 読み出しはLeader Replicaにのみ行われる。
      • Leader Replicaに障害が発生したら、いずれかのFollower Replicaが昇格する。
      • 同期しているFollower Replicaを、In Sync Replica（ISR）と呼ぶ。
      • ISR数が最小数まで回復すると、書き込みはコミットされ読み出し可能になる。

  • 物理データ構造

    • 構造

      • BrokerはReplicaごとにデータディレクトリを作成する。
      • RecordをSegmentファイルに保存することで永続化する。
      • Segmentファイルの集合をLogと呼ぶ。

    • 管理方法

Partition

Partitioning（1つのTopicは複数のPartitionで構成される）の話。

  • Partitioner

    • デフォルトのPartitionerのPartitioning方式はハッシュ方式
      • partition key が null の場合は、ラウンドロビン方式になる。
      • partition key に基づいてメッセージをルーティングできる。
    • 別途、独自のPartitionerを実装できる。

  • Partition数は、後から増やすことダケはできる。
    ただし、Partitioner＋partition keyでPartitioningしている場合、
    後からPartition数を増やすことが難しくなりがち。

Broker

クラスタ内のサーバ・ノードのことをBrokerと呼ぶ。

  • Broker同士はクラスタコーディネータであるZooKeeperを使用して連携する。
  • Brokerの１つがリーダーとなりBrokerクラスタを管理する。

Producer

  • 書き込み側のアプリケーション（Publisher）は、
    Producerと呼ばれる書き込み用ライブラリを使用してRecordを書き込む。

  • データ送信者（Publisher）は、

    • Recordを送信するためにProducerのSend APIを呼び出す。

    • Producerは、以下を行う。

      • 定期的にいずれかのBrokerからメタデータを取得する。
      • 各Brokerのホスト名、接続先ポート、Leader Replicaの場所など把握する。
      • Produce リクエストでは、通信オーバーヘッド削減のため、ネットワークスレッドが
        複数Topicの「Record Batch」を1回のリクエストでまとめて送信する。

    • acksの設定によって、異なる返信タイミングで、リクエスト完了通知を受信する。

      • 0：即時
      • 1：Leader Replicaへの書き込み完了時
      • all：最小ISR数まで複製完了時

Consumer

  • 読み出し側のアプリケーション（Subscriber）は、
    Consumerと呼ばれる読み出し用ライブラリを使用してRecordを取り出す。

  • データ受信者（Subscriber）は、

    • Recordを取得するためにConsumerのPoll APIを呼び出す。

    • Consumerは、以下を行う。

      • 定期的にいずれかのBrokerからメタデータを取得する。

      • 各Brokerのホスト名、接続先ポート、Leader Replicaの場所など把握する。

      • Recordをどこまで読みだしたのかを示すOffsetを管理する。

      • Consumer内部のキューに取得対象のRecordがなかった場合
        ・BrokerにFetchリクエストを投げてRecordを取得
        ・Fetchリクエストでは、以下の3つを指定
        　・取得対象のTopic
        　・Partitionのリスト
        　・各Partitionで取得したいOffset（Record番号）の範囲
        ・取得したRecord BatchはConsumer内部のキューに格納される。

  • Consumer Group
    1つ以上のConsumerでConsumer Groupを構成することで、
    1TopicのデータをGroup内のConsumerで分散読み出しできる。

順序保証

分散処理：ストリーム系の該当節を参照。

  • リクエストの並列送信数（max.in.flight.requests.per.connection）を1に設定
  • 特定のキーに対応するRecordを、特定のPartition（のRecord Batch）に集める
    • Consumer Groupの中でもパーティション毎に割り当てが可能

機能

セキュリティ

  • 接続認証、通信データの暗号化

    • SSL/SASL（メールの該当節を参照）
    • クライアント証明書（証明書の該当節を参照）

  • クライアントによる読み取り/書き込み操作の認証

リソース割り当て制限（Quotas）

クライアントが使用するBrokerリソースを制御できる。

  • ネットワーク帯域幅
  • ネットワークI/O
  • ディスクI/O
  • スレッドのCPU要求レート

Logコンパクション

  • 各キーの最新Recordのみを保持する。

  • 一定期間が過ぎたRecordを削除するのではなく、
    同じキーの最新のRecord以外を削除する機能。

モニタリング

  • JMX (Java Management Extensions) により性能情報などのメトリックを公開。
  • JMXに対応した監視ソフトウェアを使用することで、これらのメトリックを収集できる。

Recordの重複排除

  • At-least-once保証

    • 最低一回。重複が有り得る。
    • Kafkaの既定値。

  • At-most-once保証

    • 最大一回。ロストが有り得る。
    • 設定＆AP実装（冪等性）により可能。
      冪等性 → 連番を付与的な。そんなレベル感。

  • Exactly-once保証

    • 必ず一回。理想的であるが技術的には難しい。
    • トランザクション、エンドツーエンドで保障。

ツール

Kafka Connect

DBなどの外部システムとKafka間でデータを書き込み/読み出しするコネクタを定義

Kafka Streams

MirrorMaker

  • Kafkaクラスタ間で（Produceによる）ミラーリングしバックアップを行う。
  • フォールトトレランス機能としての使用は意図されていない。

チュートリアル

Kafkaチュートリアル

参考

Qiita

ospn.jp

Partitioning関連

Azure Event Hubs

Azure Event Hubs

移行メモ

  • 「Miller Maker」は「MirrorMaker」の誤記のため修正した。
  • 「Logsatsh, Beats」→「Logstash, Beats」、 「レプリケーションLeader / Follower型レプリケーション」→ 「Leader / Follower型レプリケーション」（語の重複）、 「これらのメリックを収集」→「メトリックを収集」に修正した。
  • マイクロソフト系技術情報 Wiki（techinfoofmicrosofttech.osscons.jp）への URL リンクは、移行済みの メール / 証明書 / Azure Event Hubs に張り替えた。

Tags: 移行, Apache Kafka, 分散メッセージング, Publisher, Subscriber, Broker, Partition, Kafka Streams, Kafka Connect, ストリーム処理

このWikiは「Open棟梁Project」,「OSSコンソーシアム 開発基盤部会」によって運営されています。

NetDevInfraWiki

マイクロソフト系技術情報 Wiki
Open 棟梁 Wiki

（未着手）

開発基盤部会 Wiki

移行管理: DONE ／ TODO

Clone this wiki locally