はじめに

. それは正確に何を意味するのか？

ストリーミングプラットフォームは3つの主要な機能があります:

• メッセージキューあるいはエンタープライズのメッセージングシステムに似て、レコードのストリームへ発行および購読します。
• レコードのストリームを耐障害性のある方法で格納します。
• 発生した順にレコードのストリームを処理します。

Kafkaは一般的に2つのアプリケーションの大きなクラスのために使われます:

• システムあるいはアプリケーション間でデータを信頼して取得できるリアルタイム ストリーミング データ パイプラインの構築
• データのストリームの変換あるいは反応をするリアルタイム ストリーミング アプリケーションの構築

Kafkaがどのようにこれらのことを行うのかを理解するために、試してみてKafkaの能力を上から下まで調査してみましょう。

最初に2,3の概念:

• Kafkaは複数のデータセンタに跨るかもしれない1つ以上のサーバ上でクラスタとして実行されます。
• Kafkaのクラスタはトピックと呼ばれるカテゴリ内にレコードのストリームを格納します。
• 各レコードはキー、値とタイムスタンプから成ります。

Kafka には4つの主要なAPIがあります:

Kafkaでは、クライアントとサーバ間の通信は、単純、高パフォーマンス、言語にとらわれないTCP プロトコル.によって行われます。このプロトコルはバージョン付けされ、古いバージョンとの後方互換性を維持します。KafkaについてはJavaクライアントを提供しますが、クライアントは多くの言語で利用可能です。

トピックスとログ

Kafkaがレコードのストリームのために提供する中核的な抽象に飛び込んでみましょう—the topic。

トピックはレコードが発行される先のカテゴリあるいはフィード名です。Kafkaでのトピックは常に多数のサブスクライバです; つまり、トピックは書き込まれるデータを購読する0, 1 あるいは多くのコンシューマを持つことができます。

各トピックについては、Kafkaクラスタが以下のように見えるパーティション化されたログを維持します:

各パーティションは、構造化されたコミットログに絶え間なく追加される順番のある、不変のレコードの順列です。パーティション内のレコードはオフセット と呼ばれるパーティション内で各レコードを一意に識別する連続するid番号が割り当てられます。

Kafka クラスタは設定可能な保有期間の間、それらが消費されたかどうかに関係なく、全ての発行されたレコードを永続的に持続します。例えば保持のポリシーが2日に設定された場合、レコードが発行されてから2日間は消費可能です。その後、スペースを解放するために削除されるでしょう。Kafkaのパフォーマンスはデータのサイズに対して事実上一定です。つまり多くのデータを保持する事は問題になりません。

実際、ログにはコンシューマごとに保持されるメタデータはオフセットあるいはそのコンシューマの位置のみです。このオフセットはコンシューマによって制御されます: 通常コンシューマはレコードを読むに従って線形的にオフセットを進めるでしょうが、実際には、ポジションはコンシューマによって制御されるため、好きな順番でレコードを消費することができます。例えば、コンシューマは過去からのデータを再処理するために古いオフセットに再設定するか、最新のレコードへスキップして進めて"now"から消費を開始することができます。

この機能の組み合わせは、Kafkaのコンシューマがとても手軽であることを意味します。それらはクラスタあるいは他のコンシューマに大きな影響無しに行き来することができます。例えば、既存のコンシューマによって消費されるものを変更せずに、任意のトピックの内容を"tail"するためにコマンドラインツールを使うことができます。

ログ内のパーティションはいくつかの目的のために提供されます。まず、それらは一つのサーバに収まるサイズを超えてログをスケールすることができます。個々のパーティションはそれをホストするサーバに収まらなければなりませんが、トピックは多くのパーティションを持つことができるので、任意の量のデータを処理することができます。次に、それらは並行度の単位として振舞います - それよりは少し多くのことをします。

分散

ログのパーティションはKafkaクラスタのサーバ上で各サーバのデータ処理とパーティションの共有のリクエストを使って分散されます。各パーティションは耐障害性のための設定可能なサーバ数までリプリケートされます。

各パーティションは"leader"として振る舞う1つのサーバと"followers"と振る舞う0個以上のサーバを持ちます。leaderはパーティションの全てのreadとwriteを処理し、followerは受動的にleaderをリプリケートします。leaderが故障すると、followerの一つが自動的に新しいleaderになるでしょう。各サーバは幾つかのパーティションに対してleaderとして振る舞い、followerは他のパーティションに対してそう振る舞います。つまり負荷はクラスタ内でよくバランスされています。

Geoリプリケーション

Kafka MirrorMaker はクラスタのためのgeoリプリケーションのサポートを提供します。MirrorMakerを使ってメッセージは複数のデータセンタあるいはクラウドリージョンを横断してリプリケートされます。これを、バックアップあるいは復元のために能動的/受動的に、あるいはデータをユーザの近くに配置するために能動的/受動的に、あるいはデータのローカル性の必要のサポートのために使うことができます。

プロデューサ

プロデューサはそれらが選択したトピックへデータを発行します。プロデューサはトピック内でどのレコードがどのパーティションへ割り当てられるかに責任があります。これは負荷をバランスするために単純にラウンドロビン形式で行うか、なんらかのセマンティックなパーティション形式(つまり、レコード内のなんらかのキーに基づいて)に従ってすることができます。パーティショニングの使い方についての詳細をすぐに！

コンシューマ

コンシューマは自身にコンシューマ グループ名のラベルを付け、トピックに発行された各レコードはそれぞれ購読しているコンシューマグループ内の1つのコンシューマインスタンスに配送されます。コンシューマーインスタンスは別個のプロセスの中あるいは別個のマシーン上にあるかも知れません。

もし全てのコンシューマのインスタンスが同じコンシューマグループを持つ場合、レコードはコンシューマのインスタンス上に効率的にロードバランスされるでしょう。

もし全てのコンシューマのインスタンスが異なるコンシューマグループを持つ場合、それぞれのレコードは全てのコンシューマのプロセスにブロードキャストされるでしょう。

二つのコンシューマグループを持つ4つのパーティション (P0-P3) をホストしている2つのサーバのKafkaクラスタ。コンシューマグループ A は二つのコンシューマインスタンスを持ち、グループBは4つを持ちます。

しかし、もっと一般的に、トピックはコンシューマグループより少ない数のトピックを持つことを知りました。各 "論理サブスクライバ"ごとに1つです。各グループはスケーラビリティと耐障害性のために多くのコンシューマインスタンスから成ります。これは、サブスクライバーが1つのプロセスの代わりにコンシューマのクラスタである、発行-購読セマンティクスに他なりません。

Kafkaで実装されている消費の仕方は、各コンシューマのインスタンスが時間内のどの点においてもパーティションの "fair share" の排他的なコンシューマになるように、コンシューマのインスタンス上でログ内のパーティションが分割されるようにすることです。グループ内の会員数を維持するこのプロセスはKafkaプロトコルによって動的に処理されます。もし新しいインスタンスがグループに入ると、グループ内の他のメンバーからいくらかのパーティションを引き継ぎます; もしインスタンスが死ぬと、そのパーティションは他のインスタンスに分散されるでしょう。

Kafkaはパーティション内のレコード上の全体の順番のみを提供し、トピック内の異なるパーティション間では提供しません。キーによってデータを分割する機能との結合によるパーティションごとの順番付けは、ほとんどのアプリケーションで差し支えありません。しかし、もしレコード上の総順番が必要であれば、1つのパーティションだけをもつトピックを使って行うことができます。しかしこれはコンシューマグループごとに1つのコンシューマプロセスだけがあることを意味するでしょう。

マルチ テナント

Kafkaをマルチ テナントの解決法として配備することができます。マルチテナントはどのトピックがデータを生成あるいは消費できるかを設定することで有効にできます。定員のための操作のサポートもあります。管理者はクライアントによって使われるブローカーリソースを制御するためにリクエストに定員を定義および強制することができます。詳細な情報は、セキュリティのドキュメントを見てください。

保証

高レベルにおいて、Kafkaは以下の保証を与えます:

• プロデューサによって特定のトピックに送信されたメッセージは送信された順に追加されるでしょう。つまり、もしレコード M1がレコード M2と同じ手順で送信された場合、M1がまず送信され、そしてM1はM2よりも低いオフセットを持ちログ内に早く現われるでしょう。
• コンシューマインスタンスはログ内に格納された順番でレコードを見ます。
• リプリケーション ファクターNを持つトピックについては、ログにコミットされた全てのレコードの損失無しに N-1のサーバ障害まで耐えることができるでしょう。

これらの保証についての詳細はドキュメントの設計の章で見つけることができます。

メッセージング システムとしてのKafka

伝統的なエンタープライズ メッセージング システムに対してKafkaのストリームの概念はどのようなものか？

メッセージングは伝統的に二つのモデルを持ちます: キューイング と 発行-購読。キュー内では、コンシュマーのプールはサーバから読み込むかもしれません。各レコードはそれらのうちの一つに行きます; 発行-購読の中で、レコードは全てのコンシューマにブロードキャストされます。これら2つのモデルのそれぞれは長所と短所を持ちます。キューイングの長所は複数のコンシューマのインスタンスにデータの処理を分割できることです。これにより、処理をスケールすることができます。残念ながら、キューは複数のサブスクライバではありません — 一度1つのプロセスがデータを読み込むと、それは消えます。発行-購読 により、複数のプロセスにデータをマルチキャストすることができますが、各メッセージが各サブスクライバに行くため処理のスケーリングをする方法はありません。

Kafkaでのコンシューマグループの概念はこれらの2つの概念を一般化します。キューと同様にコンシューマグループは処理のコレクションに処理を分割することができます (コンシューマグループのメンバー)。発行-購読と同様に、Kafkaによってメッセージを複数のコンシューマグループにブロードキャストすることができます。

Kafkaのモデルの長所は各トピックがこれらの両方のプロパティを持つことです — 処理をスケールし複数のサブスクライバーも — 1つあるいは他方を選択する必要はありません。

Kafka は伝統的なメッセージングシステムよりも強力な順番の保証も持ちます。

伝統的なキューはサーバ上で順番でレコードを保持し、もし複数のコンシューマがキューから消費すると、サーバは格納しているレコードを順番に分配します。しかし、サーバはレコードを順番に分配しますが、レコードは非同期でコンシューマに配送されます。そのためそれらは異なるコンシューマ上で順番がばらばらで到着するかも知れません。これは並行消費の前ではレコードの順番は事実上失われることを意味します。メッセージングシステムはしばしば1つのプロセスのみがキューから消費することができる"排他コンシューマー"という概念を持つことでこれに対処しますが、もちろんこれは処理中に並行度が無いことを意味します。

Kafkaはそれをもうちょっとうまくやります。トピック内の並行度の概念 - パーティション - を持つことで、Kafkaは順番の保証とコンシューマのプロセスのプール上のロードバランシングの両方を提供することができます。これはトピック内のパーティションを、各パーティションがグループ内の確実に1つのコンシューマによって消費されるように、コンシューマグループ内のコンシューマに割り当てることで達成されます。こうすることで、コンシューマがパーティション内の唯一のreaderであることを確実にし、順番にデータを消費することを確実にします。多くのパーティションがあるので、これは多くのコンシューマのインスタンス上で負荷のバランスを取ります。しかし、コンシューマグループ内のコンシューマインスタンスはパーティションの数よりも大きくできないことに注意してください。

ストレージ システムとしてのKafka

発行されたメッセージを消費から分割することができるメッセージキューは効率的に実行中のメッセージのためのストレージシステムとして効率的に振る舞います。Kafkaの違いはとても良いストレージシステムだということです。

Kafkaに書き込まれたデータはディスクに書き込まれ、耐障害性のためにリプリケートされます。書き込みが完全にリプリケートされ、失敗したと書き込まれたサーバでさえ一貫性を保証されるまで、書き込みが完了したと見なされないように、Kafkaを使ってプロデューサは通知を待つことができます。

Kafkaが利用するディスクの構造は良くスケールします — Kafkaはサーバ上に50 KB あるいは 50 TB の永続データを持っていても同じ機能を果たすでしょう。

ストレージを真面目に扱い、クライアントがそれらの読み込み位置を制御できるようにすることで、Kafkaを高パフォーマンス、低レンテンシのコミットログストレージ、レプリケーション、および伝搬専用の特別な目的の分散ファイルシステムのようなものと考えることができます。

Kafkaのコミットログ ストレージおよびリプリケーション設計についての詳細は、この ページを読んでください。

ストリーム処理のためのKafka

単なる読み込み、書き込みおよびデータのストレージストリームでは十分では無く、目的はストリームのリアルタイム処理を可能にすることです。

Kafkaではストリーム プロセッサーは入力トピックからデータの連続するストリームを受け取り、この入力上で何らかの処理を行い、出力トピックへのデータの連続するストリームを生成します。

例えば、小売店のアプリケーションは売上と発送の入力ストリームを取り入れ、追加注文のストリームとこのデータから計算された価格の修正を出力するかもしれません。

プロデューサおよびコンシューマAPIを使って直接簡単な処理を行うことができます。しかしもっと複雑な変換について、Kafkaは完全に統合されたストリーム APIを提供します。これによりストリームの集約を計算、あるいはストリームを統合する些細ではない処理をするようなアプリケーションをビルドすることができます。

この機能はこの種類のアプリケーションが直面する難しい問題を解決するのに役立ちます: 乱雑なデータの処理、コードが変更されるに従って入力の再処理、ステートフルな計算の実施など。

stream APIはKafkaが提供する主要なプリミティブを構築します: 入力のためにプロデューサとコンシューマを使い、ステートフルなストレージとしてKafkaを使い、ストリーム プロセッサのインスタンス間での耐障害性のために同じグループ機構を使います。

要素を1つにする

メッセージ、ストレージおよびストリーム処理のこの組み合わせは普通では無いように思えるかもしれませんが、それはストリーミング プラットフォームとしてKafkaの役割に重要です。

HDFSのような分散ファイルシステムにより、バッチ処理のための静的なファイルを格納することができます。このようなシステムは効果的に過去からのhistoricalデータを格納および処理することができます。

伝統的なエンタープライズ メッセージング システムは購読した後でやってくるだろう将来のメッセージを処理することができます。このやり方でビルドされたアプリケーションは将来のデータを到着したかのように処理します。

Kafkaはこれらの能力を組み合わせます。組み合わせはストリーミングアプリケーションのためのプラットフォームとしてのKafkaの使い方とストリーミングデータパイプラインのための両方に重要です。

ストレージと低レンテンシの購読の組み合わせにより、ストリーミングアプリケーションは過去と未来のデータを同じ方法で扱うことができます。つまり1つのアプリケーションは履歴データ、格納されたデータを処理できるが、最後のレコードに達した時に終了せずに将来のデータが到着しても処理を続けることができます。これはバッチ処理とメッセージ駆動のアプリケーションを含むストリーム処理の一般化された表記です。

ストリーミング データのパイプラインと異なり、リアルタイムイベントへの購読の組み合わせはとてもレイテンシが低いパイプラインがKafkaを使うことを可能にします;しかしデータを信頼して格納できる機能により、データの配送が保証されなければならない重要なデータ、あるいは定期的にのみデータをロード、あるいはメンテナンスのために延長された時間の間ダウンするかもしれないオフラインシステムとの統合に使うことができます。ストリーミング処理の機能によりデータが到着した時に変換することができます。

Kafkaが提供する保証、API および能力についての詳しい情報はドキュメントの残りを見てください。