Apache Kafka概要確認（その7 PushモデルかPullモデルか

こんにちは。では続きに。

10.メッセージ消費側駆動の状態管理方式

プッシュ対プル

これまでのBroker、Consumer側の話に関連する質問として、
Broker側がデータをpushするのか、Consumer側がメッセージをpullするのか、がある。

Kafkaはデータの流れとして下記のようなデザインを取っている。

Producer→Brokerにデータをpush
Broker←Consumerにデータをpull

最近のScribeやflume等のシステムにおいてはログ収集に焦点を当て、
各ノードをBrokerとして動作させデータをpushするアプローチを取っている。
しかしながら、PushベースのシステムにおいてはBroker側はConsumer側で転送速度が制限されるような
多彩な消費モデルに対応するのは困難になる。

Kafkaの置くゴールとしては、消費者側で可能な限り最大のレートでメッセージ消費を可能にするというもの。
だが、残念ながらpushモデルのシステムにおいては提供者側が消費者側での最大効率を達成しようとした結果、
消費者側で処理可能な量以上のメッセージを送信してしまい、メッセージが過剰となる傾向がある。
消費者側でサービス停止などの問題が発生した場合、それはより容易に発生する。
＝＝＝＝＝
まぁ、そりゃそうですよね。
メッセージの処理できるペースについては消費者側でしかわからない。
ですが、提供者側は消費者側が最大限処理できるように・・・と考えると何かあったとしてもペースを落とすことはできない。
＝＝＝＝＝

pullベースのシステムにおいてはそのペースを消費者側で制御できるため、
一時的に処理速度が低下した場合であっても後から追い付くことが可能。
それはpushベースのシステムにおいて消費者側が状況を通知するよりシンプルなモデルに仕上がるため
Kafkaにおいてはpullベースのシステムモデルを取ることとしている。

11.システムの分散

Kafkaは基本的にはクラスタ全体に分散実行されるモデルを取っており、マスターノードと呼ばれる存在はない。
Brokerプロセスもお互いに１対１で対応しており、設定の手動更新なしにノードの追加削除を行うことができる。

同様に、ProducerプロセスとConsumerプロセスも動的に起動することが可能。
各BrokerプロセスはZookeeperにメタデータ（利用可能なトピック情報など）を登録する。
ProducerプロセスとConsumerプロセスはZookeeperに登録されたメタデータを元に
トピックを発見したりメッセージの生成／消費の協調を行うことが可能。

＝＝＝＝＝
とりあえず、Consumer＆消費者やBroker＆提供者など言葉がいい感じで混雑してきたので、
最後にその辺りの統一も含めてまとめが必要かもしれませんねぇ

ちと短いですが、次はProducerという形でまとまった章となるのでいったん切ります。
ただ、ようやく全体像が見えてきた感はありますね。
＝＝＝＝＝