オライリー Kafka

オライリーのKafka。Kafka自体はちらほらと聞きつつも、MQ、JMSなどの所謂メッセージングとの違いがさっぱり分からなかったものの、一方でレプリケーションソフトとして使いたい話もあり、体系的に整理したかったところ。

その点、まえがきに整理されていました。

Kafkaはもともと、Linkedin社内のインフラシステムとして始まりました。私たちが思っていたのは、実に単純なことでした。データベースといったデータをストアするためのシステムはたくさんありましたが、自分たちのアーキテクチャにはデータの連続的なフローを処理するのに役立つものがかけていたのです。Kafkaを作る前、メッセージングシステムからログ集約/ETLツールまで、出来合いのソフトをいろいろと試してみたのですが、どれも求めていたものではありませんでした。

結局、私達はゼロから作ることにしました。リレーショナルデータベース、キーバリューストア、検索インデックス、キャッシュなどのように膨大なデータの保存にフォーカスするのではなく、連続的に生成されて成長し続けるストリームとしてデータを扱うことにフォーカスしました。

(中略)

私たちはKafkaをストリーミングプラットフォームとして考えるようになりました。ストリーミングプラットフォームとは、データの発行(Publish)と購読(Subscribe)、保存、処理を可能にするシステムであり、Apache Kafkaはまさにそのために作られています。

(中略)

Kafkaはメッセージングシステムと似ています(中略)、違いは3つあります。第一にKafkaはクラスタとして動作するモダンな分散システムです。拡張することで、超巨大な企業であってもすべてのアプリケーションを扱うことができます。(中略)対ににKafkaは好きなだけデータを保存できるように作られた、真のストレージプラットフォームです。真の配送保証を提供しているため、接続レイヤとして使うと大きなメリットがあります。データは複製され、永続化され好きなだけ手元においておけます。最後に、ストリーム処理の世界は抽象化のレベルを大きく高めてくれます。ほとんどのメッセージングシステムではメッセージの配信しかしてくれません。それに対して、Kafkaのストリーム処理は、はるかに少ないコートであなたのストリームから派生したストリームやデータセットを動的に計算することができます。

(中略)

わたしたちがKafkaを設計/構築する際の森ベーションの1つだったのは、KafkaをHadoopのリアルタイムバージョンと考えることでした。

(中略)

Kafkaと比較される領域の最後は、ETLあるいはデータ統合ツールです(中略)。Kafkaは、あるシステムからデータを取り出して、別のシステムに入れるためのツールではありません。リアルタイムのイベントストリームを中心としたプラットフォームです。つまり、出来合いのアプリケーションやデータシステムに接続できるだけでなく、同じデータストリームをトリガにした独自のアプリケーションを構築して動かせるのです。

内部の仕組みは明るい資料があった。

めざせ!Kafkaマスター ~Apache Kafkaで最高の性能を出すには~

 

事例としてはMQ代替が多く、まえがきのコンセプトと合致しないのが多数だっだけれども、以下が腑に落ちる。
大手ヘルスケアIT企業 Cerner社のKafka活用事例

さて、読書。。。

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

日本語が含まれない投稿は無視されますのでご注意ください。(スパム対策)