Apache Kafkaレビュー

こんにちは、Habr！



本日は、Apache Kafkaのデバイスとアプリケーションに関する比較的簡潔でありながら賢明で有益な記事を提供します。 Nha Narkhede et。 による本を翻訳してリリースしたいと考えています。 夏の終わりまでアル。









素敵な読書を！



はじめに



今日、彼らはカフカについてたくさん話します。 多くの大手IT企業がすでに積極的にこのツールを使用しています。 しかし、カフカとは何ですか？



Kafkaは2011年にLinkedInで開発され、その後大幅に改善されました。 現在、Kafkaは、膨大な量のデータを保存するのに十分な冗長性を提供するプラットフォーム全体です。 それは途方もない帯域幅を持つメッセージバスを提供し、その上を通過するすべてのデータをリアルタイムで絶対に処理できます。



これはすべてクールですが、Kafkaを乾燥した残留物に減らすと、 水平方向にスケーラブルなフォールトトレラントなコミットログが分散されます 。



賢く聞こえます。 これらの各用語を見て、その意味を見てみましょう。 そして、これがどのように機能するかを詳細に調べます。



分散型



分散は、単一のクラスターを構成する多くのマシンですぐにセグメント化された形で動作するシステムです。 したがって、エンドユーザーにとっては、単一のノードのように見えます。 Kafkaの配信は、Kafkaからのメッセージの保存、受信、配信が異なるノード（いわゆる「ブローカー」）で編成されているという事実にあります。

このアプローチの最も重要な利点は、高可用性とフォールトトレランスです。



水平方向にスケーラブル



最初に、垂直スケーラビリティとは何かを決めましょう。 従来のデータベースサーバーがあり、増加する負荷に徐々に対処しなくなったとします。 この問題に対処するには、サーバー上のリソース（CPU、RAM、SSD）を増やすだけです。 これは垂直スケーリングです。追加のリソースがマシンでハングします。 この「スケールアップ」には、2つの重大な欠点があります。

1. 機器の機能には特定の制限があります。 無限に成長することはできません。
2. このような作業は通常、ダウンタイムに関連付けられており、大企業はダウンタイムを買う余裕がありません。

水平スケーラビリティはまったく同じ問題を解決し、より多くのマシンをビジネスに接続するだけです。 新しいマシンを追加する場合、ダウンタイムは発生しませんが、クラスターに追加できるマシンの数は無制限です。 問題は、すべてのシステムが水平スケーラビリティをサポートしているわけではなく、多くのシステムがクラスターで動作するように設計されておらず、設計されたシステムは通常非常に操作が難しいことです。







一定のしきい値を超えると、水平スケーリングは垂直よりもはるかに安くなります



耐障害性



割り当てられていないシステムの場合、いわゆる単一障害点が特徴的です。 何らかの理由でデータベース内の唯一のサーバーに障害が発生すると、ヒットします。

分散システムは、障害に合わせて構成を調整できるように設計されています。 5ノードのKafkaクラスターは、2つのノードが落ちても動作し続けます。 フォールトトレランスを確保するには、システムの障害に対する耐性が高いほどパフォーマンスが低下するため、パフォーマンスを部分的に犠牲にする必要があることに注意してください。



コミットログ



コミットログ（「先行書き込みログ」、「トランザクションログ」とも呼ばれます）は、長期的に順序付けられたデータ構造です。さらに、データはそのような構造にのみ追加できます。 このログのエントリは、変更も削除もできません。 情報は左から右に読み取られます。 このようにして、要素の正しい順序が保証されます。





コミットログスキーマ

-Kafkaのデータ構造がとてもシンプルだということですか？

いろいろな意味で、はい。 この構造は、Kafkaの核心を形成し、秩序性と秩序性（決定論的処理）を提供するため、絶対に貴重です。 分散システムにおけるこれらの問題の両方を解決することは困難です。



本質的に、Kafkaはすべてのメッセージをディスクに保存し（これについては以下で詳しく説明します）、上記の構造の形式でメッセージを整理する場合、ディスクからの順次読み取りを使用できます。

• 読み取りおよび書き込み操作は一定の時間O（1）（レコードIDがわかっている場合）実行されます。これは、異なる構造のディスクでのO（log N）操作と比較して、各ヘッド上げ操作にコストがかかるため、信じられないほど時間を節約できます。
• 読み取り操作と書き込み操作は互いに影響しません（読み取り操作は書き込み操作をブロックせず、逆も同様です。バランスツリーを使用した操作については言えません）。

これらの2つのポイントは、データのサイズに完全に依存しないため、生産性を劇的に向上させます。 サーバーに100KBまたは100TBのデータがある場合でも、Kafkaは同様に機能します。



どのように機能しますか？



アプリケーション（ ジェネレーター ）はメッセージ（ レコード ）をKafkaノード（ ブローカー ）に送信し、これらのメッセージは他のアプリケーション、いわゆるコンシューマーによって処理されます。 これらのメッセージはトピックに保存され、消費者はトピックにサブスクライブして新しいメッセージを受信します。







テーマは大きくなる可能性があるため、パフォーマンスとスケーラビリティを向上させるために、大きなトピックを小さなセクションに分割します 。 （例： ユーザーのログイン要求を保存したとします;この場合、ユーザー名の最初の文字でそれらを配布できます ）



Kafkaは、セクション内のすべてのメッセージが到着した順序で正確に順序付けられることを保証します。 特定のメッセージは、このセクションの新しいメッセージごとに1ずつ増加するシーケンス番号である、配列内の通常のインデックスと見なすことができるオフセットによって見つけることができます。







カフカは、「愚かなブローカー-スマート消費者」の原則を順守しています。 したがって、Kafkaは、どのレコードが消費者によって読み取られてから削除されるかを追跡せず、指定された期間（たとえば、1日）または特定のしきい値に達するまでそれらを単に保存します。 消費者自身がKafkaにインタビューして新しいメッセージを探し、どのレコードを読む必要があるかを示します。 したがって、オフセットを増減して、目的のレコードに移動できます。 ただし、イベントは再生または再処理できます。



実際には、それは単一の消費者に関するものではなく、それぞれが1つ以上の消費者プロセスがあるグループに関するものであることに注意する必要があります。 2つのプロセスが同じメッセージを2回読み取れる状況を防ぐために、各セクションはグループ内の1つのコンシューマプロセスのみにバインドされます。







これがデータフローです



ディスク上の長期保存



前述のように、Kafkaは実際にレコードをディスクに保存し、RAMには何も保持しません。 はい、質問は可能です、これに感覚の低下さえありますか？ しかし、Kafkaにはこれを可能にする多くの最適化があります。

1. Kafkaには、メッセージをグループ化するプロトコルがあります。 したがって、ネットワーク要求の場合、メッセージはグループ化され、ネットワークコストが削減され、サーバーはメッセージのバッチを一度に保存します。その後、消費者はそのようなメッセージの大きな線形シーケンスをすぐに選択できます。
2. ディスクへの線形読み取りおよび書き込み操作は高速です。 既知の問題があります。ヘッドフィードが必要なため、最新のドライブの動作は比較的遅くなりますが、大きな線形操作ではこの問題はなくなります。
3. これらの線形操作は、スケジュールよりも先に読み込む （ブロックの大きなグループを事前に選択する）と記録を遅らせる （小さな論理書き込み操作を大きな物理書き込み操作に組み合わせる）ことにより、オペレーティングシステムによって大幅に最適化されます。
4. 最新のオペレーティングシステムは、ディスクを空きRAMにキャッシュします。 この手法は、 ページキャッシュと呼ばれます 。
5. Kafkaは、チェーン全体（ジェネレーター->ブローカー->コンシューマー）で変化しない標準化されたバイナリ形式でメッセージを保存するため、ここではゼロコピー最適化が適切です。 この場合、OSはページキャッシュからソケットにデータを直接コピーし、実質的にKafkaに関連するブローカーアプリケーションをバイパスします。

これらすべての最適化により、Kafkaはネットワーク自体とほぼ同じ速さでメッセージを配信します。



データの配布と複製



次に、Kafkaがフォールトトレランスを実現する方法と、ノード間でデータを分散する方法について説明します。



データ複製



セグメントデータは複数のブローカーに複製されるため、ブローカーの1つが失敗してもデータは保存されます。



いずれの場合でも、ブローカーの1つは常にセクションを「所有」します。このブローカーは、アプリケーションがセクションに対して読み取りおよび書き込み操作を実行するブローカーです。 このブローカーは「 セクションリーダー 」と呼ばれます。 受信したデータを他のN個のブローカー、いわゆるフォロワーに複製します。 スレーブもデータを保存し、現在のマスターに障害が発生した場合、それらのいずれかをマスターとして選択できます。

このようにして、正常に公開されたメッセージが失われないことを保証するように保証を構成できます。 レプリケーションレートを変更できる場合、パフォーマンスを部分的に犠牲にして、保護とデータの耐久性を向上させることができます（重要度によって異なります）。







したがって、指導者の一人がこれを拒否した場合、奴隷が代わりを務めることができます。



ただし、次の質問をするのは論理的です。

-ジェネレーター/コンシューマーは、このセクションのリーダーであるブローカーをどのようにして見つけるのですか？

ジェネレーター/コンシューマーがこのセクションの情報を読み書きできるように、アプリケーションは、ここでリーダーであるブローカーを知る必要がありますか？ この情報はどこかで取得する必要があります。



Kafkaは、 Zookeeperというサービスを使用してこのようなメタデータを保存します。



ズーキーパーとは何ですか？



Zookeeperは、キーと値の分散リポジトリです。 読み取り用に高度に最適化されていますが、書き込みが遅くなります。 ほとんどの場合、Zookeeperはメタデータを保存し、クラスタリングメカニズム（心拍数、分散更新/構成操作など）を処理するために使用されます。



したがって、このサービスの顧客（Kafkaブローカー）はこれにサブスクライブでき、発生する可能性のある変更に関する情報を受け取ります。 これは、セクションのリーダーが変更されたときにブローカーが見つける方法です。 Zookeeperは、Kafkaが非常に依存しているため、非常にフォールトトレラントです（そうあるべきです）。



特に、すべての種類のメタデータを保存するために使用されます。

• セクション内の消費者グループのバイアス（現代の顧客はバイアスを別のKafkaトピックに格納しますが）
• ACL（アクセス制御リスト）-アクセス/許可を制限するために使用
• ジェネレーターとコンシューマーのクォータ-1秒あたりの最大メッセージ制限
• 主要なセクションとそのパフォーマンスレベル

ジェネレーター/コンシューマーは、このセクションでどのようにリードブローカーを決定しますか？



以前は、ジェネレーターとコンシューマーはZookeeperに直接接続し、この（およびその他の）情報をZookeeperから学びました。 現在、Kafkaはそのようなバンドルから遠ざかり、それぞれバージョン0.8と0.9から開始し、顧客はまず、Kafkaブローカーから直接メタデータを選択し、ブローカーはZookeeperに頼ります。







メタデータストリーム



ストリーム



Kafkaのストリームプロセッサは、次のすべての作業を担当します。入力から連続したデータストリームを受け取り、何らかの方法でこの入力を処理し、データストリームを出力トピック（または外部サービス、データベース、ゴミ箱、はい、どこでも...）にフィードします

ジェネレーター/コンシューマーAPIで単純な処理を直接実行できますが、より複雑な変換-たとえば、Kafkaでのストリームの結合は、統合されたStreams APIライブラリを使用して実行されます 。



このAPIは、独自のコードベース内で使用するためのものであり、ブローカーでは機能しません。 機能的には、コンシューマAPIに似ており、スレッド処理の水平方向のスケーリングと、複数のアプリケーション間でのその配布を容易にします（コンシューマグループと同様）。



ステートレス処理



ステートレス処理は、外部要因に依存しない決定論的処理の流れです。 例として、次の簡単なデータ変換を考えます。情報を文字列に添付します



"Hello" -> "Hello, World!"











ストリーミングテーブルの二重化



スレッドとテーブルは本質的に同じものであることを理解することが重要です。 ストリームはテーブルとして、テーブルはストリームとして解釈できます。



テーブルとしてストリーム



同期データベースレプリケーションの実行方法に注意を払えば、テーブルの変更がコピーサーバー（レプリカ）に送信されるストリーミングレプリケーションについて話していることは明らかです。 Kafkaストリームは、データの更新ストリームとまったく同じ方法で解釈できます。データの更新ストリームは集計され、最終結果が表に表示されます。 このようなストリームは、ローカルのRocksDB（デフォルト）に保存され、KTableと呼ばれます 。







ストリームとしてのテーブル



テーブルは、ストリーム内の各キーの最後の値を反映したスナップショットと見なすことができます。 同様に、ストリームテーブルを使用してテーブルを作成し、テーブルの更新を使用して変更ログを含むストリームを作成できます。







更新ごとに、ストリームのスナップショットを作成できます（記録）



ステートフル処理



map()



やfilter()



などのいくつかの簡単な操作は、状態を保存せずに実行され、処理に関するデータを保存する必要はありません。 ただし、実際には、ほとんどの操作は状態保存（例： count()



）で実行されるため、当然ながら現在の状態を保存する必要があります。



ストリーミングプロセッサで状態を維持する際の問題は、これらのプロセッサが時々故障することです！ フォールトトレランスを確保するためにこの状態を保存する場所



単純化されたアプローチは、すべての状態をリモートデータベースに保存し、ネットワーク経由でこのリポジトリに接続することです。 問題は、データの局所性が失われ、データ自体がネットワーク経由で繰り返しリダイレクトされることです。どちらの要因もアプリケーションの速度を大幅に低下させます。 より微妙ですが重要な問題は、ストリーミング処理ジョブのアクティビティがリモートデータベースに大きく依存することです。つまり、このタスクは自給自足です（別のコマンドがデータベースに変更を加えると、すべての処理が失敗する可能性があります） 。



では、どちらのアプローチの方が良いでしょうか？



繰り返しますが、テーブルとスレッドの二重性を覚えておいてください。 このプロパティのおかげで、ストリームは処理が行われる正確な場所にあるテーブルに変換できます。 同時に、フォールトトレランスを保証するメカニズムを取得します。ストリームをKafkaブローカーに保存します。



ストリームプロセッサは、その状態をローカルテーブル（たとえば、RocksDB）に保存できます。このテーブルは、入力ストリームによって更新される可能性があります（任意の変換後）。 このプロセスが失敗した場合、ストリームを繰り返し再生することで対応するデータを復元できます。



リモートデータベースがストリームを生成し、実際に変更ログをブロードキャストすることを確認することもできます。これに基づいて、ローカルマシンでテーブルを再構築します。







ステートフル処理、KStreamをKTableに接続



KSQL



原則として、ストリームを処理するコードは、JVMの言語の1つで作成する必要があります。これは、JVMがKafka Streams APIで動作する唯一の公式クライアントであるためです。







KSQLインストールサンプル



KSQLは、SQLに似た使い慣れた言語で簡単なストリームジョブを作成できる新しい機能です。



KSQLサーバーを構成し、CLIを介して対話的に照会して処理を制御します。 同じ抽象化（KStreamとKTable）で正確に機能し、Streams APIと同じ利点（スケーラビリティ、フォールトトレランス）を保証し、ストリームの処理を大幅に簡素化します。



おそらく、これはすべて刺激的ではないかもしれませんが、実際には素材のテストに非常に役立ちます。 さらに、このモデルを使用すると、開発に関与していない人（製品所有者など）でもストリーム処理に参加できます。 短い紹介ビデオをご覧になることをお勧めします-それがいかに簡単かをご自身で確かめてください。



ストリーミングの代替



Kafka Streamsは、強度とシンプルさの完璧な組み合わせです。 おそらく、Kafkaは市場で利用可能なストリーミングタスクを実行するのに最適なツールであり、Kafkaとの統合は、代替のストリーミング処理ツール（ Storm 、 Samza 、 Spark 、 Wallaroo ）よりもはるかに簡単です。



他のほとんどのストリーミングツールの問題は、それらの展開が困難である（処理が難しい）ことです。 Sparkなどのバッチ処理フレームワークには以下が必要です。

• マシンのプールで多数のタスクを管理し、それらをクラスターに効率的に分散します。
• これには、コードを動的にパッケージ化し、それが実行されるノードに物理的に展開する必要があります（さらに、構成、ライブラリなど）。

残念ながら、1つのフレームワークのフレームワーク内でこれらの問題をすべて解決しようとすると、このフレームワークはあまりにも侵襲的です。 フレームワークは、コードの展開、構成、監視、およびパッケージ化のあらゆる側面を制御しようとします。



Kafka Streamsを使用すると、必要なときに独自の展開戦略を策定し、 Kubernetes 、 Mesos 、 Nomad 、 Docker Swarmなどの好みのツールで作業できます。



Kafka Streamsは、主にアプリケーションでストリーミング処理を整理できるように設計されていますが、次のクラスターのサポートに関連する運用上の問題はありません。 このようなツールの唯一の潜在的な欠点は、Kafkaとの密接な関係ですが、現在の現実では、ストリーム処理が主にKafkaを使用して実行される場合、この小さな欠点はそれほどひどくはありません。

---

Kafkaを使用する場合



前述のように、Kafkaを使用すると、集中環境を介して大量のメッセージを送信し、パフォーマンスを心配したり、データが失われることを恐れたりせずにメッセージを保存できます。



したがって、Kafkaはシステムの中心に完全に収まり、すべてのアプリケーションの相互作用を保証する接続リンクとして機能します。 Kafkaはイベント駆動型アーキテクチャの中心的な要素となり、アプリケーションを相互に適切にアンフックできます。







Kafkaを使用すると、異なる（マイクロ）サービス間の通信を簡単に区別できます。 Streams APIを使用することにより、サービスが消費を開始する前にKafkaテーマのデータを強化するビジネスロジックを記述することがこれまで以上に簡単になりました。 非常に多くの機会を提供しているので、さまざまな企業でKafkaがどのように使用されているかを調べることを強くお勧めします。



まとめ



Apache Kafkaは、1日に数兆のイベントを処理できる分散ストリーミングプラットフォームです。 Kafkaは、最小レイテンシ、高スループットを保証し、「公開/サブスクリプション」の原則に基づいて動作するフォールトトレラントパイプラインを提供し、イベントストリームを処理できるようにします。



この記事では、Kafkaの基本的なセマンティクス（ジェネレーター、ブローカー、コンシューマー、トピックとは何か）、最適化オプション（ページキャッシュ）について学び、Kafkaがデータを複製する際に保証するフォールトトレランスについて学び、その強力なストリーミング機能について簡単に説明しました。