Kafka: 単なるメッセージキューにとどまらない、新世代のストリームデータ処理プラットフォーム

データのために生まれ、20 世紀で最も影響力のある作家にちなんで名付けられたクールなオープンソースプロジェクト、それが Kafka です。９年目を迎えるカフカは、もう若くはないが、まだまだ生命力に満ちている。この記事では、Kafka の開発について簡単に説明します。記事の最後には、この記事の参考資料と、興味のある読者が詳しく学習できる簡単で実践的な Kafka コースが紹介されています。

背景

科学者たちが意見を異にするたびに、それは十分なデータがないからです。したがって、まずどのような種類のデータを取得するかについて合意することができます。データが取得できれば問題は解決します。私が正しいか、あなたが正しいか、あるいは私たち両方が間違っているかのいずれかです。それから私たちは研究を続けました。

--ニール・ドグラース・タイソン

2010 年頃、多くのインターネット企業と同様に、LinkedIn は毎日大量のデータ (ログメッセージ、メトリック、ユーザーアクティビティレコード、応答メッセージなど) を収集し、その多くはさまざまなデータソースによってリアルタイムで生成されていました。データ生産者と消費者間のポイントツーポイントのデータ伝送方法と、複数の独立した公開およびサブスクリプションシステムの維持コストはますます高くなっています。その結果、さまざまなソースからのデータを統合し、一元的に管理する需要が高まっています。同社は効率的なデータパイプラインの研究を始めました。その後、Linkedin から、パブリッシングおよびサブスクリプションベースのメッセージングシステムとして Kafka が誕生しました。

重要な時点

2010年10月、カフカはLinkedinで誕生した。

2011年7月にApacheインキュベータに参加し、最初のオープンソースバージョン0.7.0をリリースしました。

2012年10月にインキュベーターを卒業し、主要なオープンソースプロジェクトとなり、バージョン0.8.0をリリースしました。

Confluent は 2014 年 11 月に設立されました。同年に 0.8.2 と 0.9.0 がリリースされ、バージョン 0.9.0 ではクォータとセキュリティが追加されました。

2017年11月には、Exactly-Onceと運用・保守パフォーマンスの改善を加えたバージョン1.0.0が正式にリリースされました。

2018 年 7 月には、ストリーミングデータプラットフォームのオンライン進化に重点を置いたバージョン 2.0.0 がリリースされました。

2018年12月、KafkaチームはKSQLおよびその他のオープンソースライセンスを変更しました。

簡単な紹介

Kafka データキーワード

メッセージとキー

Kafka のデータ単位はメッセージと呼ばれ、データベース内の「データ行」または「レコード」と見なすことができます。メッセージはバイト配列で構成されます。 Kafka の場合、メッセージ内のデータには特別な形式や意味はありません。メッセージにはオプションのメタデータ（キー）を含めることができます。キーもバイト配列であり、特別な意味はありません。キーは、メッセージのパーティションを選択するときに使用されます。

メッセージとバッチ

効率を向上させるために、メッセージはバッチで Kafka に書き込まれます。バッチは、同じトピックとパーティションに属するメッセージのグループです。メッセージをバッチで送信すると、ネットワークのオーバーヘッドを削減できます。

トピックとパーティション

Kafka メッセージはトピック別に分類されます。トピックはデータベース内のテーブルのようなものです。トピックは複数のパーティションに分割でき、パーティションはコミットログです。メッセージは追加のみの形式でパーティションに書き込まれ、先入先出の順序で読み取られます。トピックには通常、複数のパーティションが含まれます。

画像は https://kafka.apache.org より

流れ

Kafka などのシステム内のデータを説明するときに、ストリームという言葉がよく使用されます。多くの場合、トピック内のデータはストリームとして考えられます。ストリームは、プロデューサーからコンシューマーに移動するデータのセットです。

コアAPI

Kafka Producer API: データを直接生成するアプリケーション (ログ、IoT など)
Kafka Connect Source API: データ統合用の API (MongoDB、REST API など)
Kafka Streams API / KSQL: ストリーム処理用の API。 SQL でクエリロジックを実装できる場合は、KSQL を使用します。複雑なロジックを記述する必要がある場合は、Kafka Streams を使用します。
Kafka Consumer API: データストリームを読み取り、リアルタイムアクション (メールの送信など) を実行します。
Kafka Connect Sink API: データストリームを読み取り、ターゲットストレージに保存します (Kafka から HDFS、Kafka から MongoDB など)

中央の Kafka クラスターは複数のブローカーで構成されています。単一の Kafka サーバーはブローカーと呼ばれます。ブローカーはプロデューサーからメッセージを受信し、メッセージのオフセットを設定し、メッセージをディスクにコミットして保存します。ブローカーは、パーティションの読み取り要求に応答し、ディスクにコミットされたメッセージを返すことで、消費者にサービスを提供します。特定のハードウェアとそのパフォーマンス特性に応じて、単一のブローカーは数千のパーティションと 1 秒あたり最大メッセージを簡単に処理できます。

アプリケーションシナリオ

アクティビティトラッキング

Kafka の元々の使用例は、ユーザーアクティビティを追跡することでした。ウェブサイトのユーザーはフロントエンドアプリケーションと対話し、ユーザーアクティビティに関連するメッセージを生成します。これらのメッセージは、ページの訪問やクリックなどの静的な情報の場合もあれば、ユーザープロファイルの追加などの複雑な操作の場合もあります。これらのメッセージは 1 つ以上のトピックに公開され、バックエンドアプリケーションによって読み取られます。これにより、レポートを生成したり、機械学習システムにデータを提供したり、検索結果を更新したりできるようになります。

メッセージの配信

Kafka のもう 1 つの基本的な用途はメッセージングです。アプリケーションは、メッセージを渡すことによってユーザーに通知 (電子メールなど) を送信します。これらのアプリケーションコンポーネントは、メッセージの形式やメッセージの送信方法を気にすることなくメッセージを生成できます。一般的なアプリケーションはこれらのメッセージを読み取って処理します。

メッセージの書式設定（装飾とも呼ばれます）
同じ通知で複数のメッセージを送信します。
ユーザーが設定したオプションに従ってデータを送信します。

共通コンポーネントを使用する利点は、複数のアプリケーションで重複する機能を開発する必要がないことと、複数のメッセージを 1 つの通知に集約するなど、他の方法では実行できない興味深い変換を共通コンポーネントで実行できることです。

メトリクスとログ

Kafka は、アプリケーションとシステムのメトリックとログを収集するためにも使用できます。このとき、Kafka の複数のプロデューサーのサポートが役立ちます。アプリケーションは定期的にメトリックを Kafka トピックに公開し、監視システムまたはアラートシステムがこれらのメッセージを読み取ります。 Kafka は Hadoop などのオフラインシステムでも使用でき、年間成長傾向の予測など、より長い期間にわたるデータを分析できます。ログメッセージは Kafka トピックに公開し、専用のログ検索システム (Elasticsearch など) やセキュリティ分析アプリケーションにルーティングすることもできます。ターゲットシステム（ログストレージシステムなど）を変更しても、フロントエンドアプリケーションや集計方法には影響しません。これは、Kafka のもう 1 つの利点です。

ログを送信

Kafka の基本的な概念は送信ログから来ているので、送信ログとして Kafka を使用するのは自然なことです。データベースの更新を Kafka に公開することができ、アプリケーションはイベントストリームを監視することでデータベースのリアルタイムの更新を受け取ります。この変更ログストリームは、データベースの更新をリモートシステムに複製したり、複数のアプリケーションからの更新を単一のデータベースビューにマージしたりするためにも使用できます。データの永続性により、変更ログのバッファが提供されます。つまり、コンシューマアプリケーションに障害が発生した場合、これらのログを再生することでシステム状態を復元できます。また、コンパクトログトピックはキーごとに 1 つの変更データのみを保持するため、メッセージの有効期限を気にすることなく長期間使用できます。

ストリーム処理

ストリーム処理は、さまざまなアプリケーションを提供するもう 1 つの領域です。これらが提供する機能は、Hadoop の map 関数や Reduce 関数と多少似ていると言えますが、Hadoop が数時間または数日という長い時間セグメントでデータを処理するのに対し、これらはリアルタイムのデータストリームで動作するという点が異なります。 Hadoop はこのデータをバッチ処理します。ストリーム処理フレームワークを使用することで、ユーザーは、メトリックの計算、他のアプリケーションのメッセージパーティションの効率的な処理、複数のデータソースからのメッセージの変換など、Kafka メッセージを操作する小さなアプリケーションを作成できます。

なぜカフカなのか

パブリッシングおよびサブスクリプションベースのメッセージングシステムは数多くありますが、なぜ Kafka の方が優れているのでしょうか?

複数のプロデューサー

Kafka は、クライアントが単一のトピックを消費しているか複数のトピックを消費しているかに関係なく、複数のプロデューサーをシームレスにサポートできます。そのため、複数のフロントエンドシステムからデータを収集し、統一された形式で外部にデータを提供するのに非常に適しています。たとえば、複数のマイクロサービスで構成される Web サイトでは、ページビュー用に個別のトピックを作成し、すべてのサービスが同じメッセージ形式でこのトピックにデータを書き込むことができます。コンシューマーアプリケーションは、さまざまなプロデューサーからのデータストリームを調整する必要なく、ページの統一されたビューを取得できます。

複数の消費者

Kafka は複数のプロデューサーをサポートするだけでなく、相互に影響を与えることなく単一のメッセージストリームからデータを読み取る複数のコンシューマーもサポートします。これは、メッセージが 1 つのクライアントによって読み取られると、他のクライアントでは読み取れなくなる他のキューシステムとは異なります。さらに、複数のコンシューマーがメッセージストリームを共有するグループを形成し、グループ全体が各メッセージを 1 回だけ処理することを保証できます。

ディスクベースのデータストレージ

Kafka は複数のコンシューマーをサポートするだけでなく、Kafka のデータ保持特性により、コンシューマーが非リアルタイムでメッセージを読み取ることも可能にします。メッセージはディスクにコミットされ、設定した保持ルールに従って保存されます。各トピックには、さまざまなコンシューマーのニーズを満たすために個別の保持ルールを設定でき、各トピックは異なる数のメッセージを保持できます。処理速度が遅かったり、トラフィックが突然ピークに達したりすると、消費者はメッセージを時間内に読み取れない可能性がありますが、永続的なデータにより、データが失われないようにすることができます。コンシューマーは、メッセージが失われたりプロデューサー側でスタックしたりすることを心配することなく、アプリケーションのメンテナンスを実行しながら短時間オフラインにすることができます。コンシューマーはシャットダウンできますが、メッセージは Kafka に残り続けます。コンシューマーは中断したところからメッセージの処理を続行できます。

スケーラビリティ

大量のデータを簡単に処理できるように、Kafka は最初からスケーラブルなシステムとして設計されました。開発フェーズでは、ユーザーは最初に 1 つのブローカーを使用し、次に 3 つのブローカーを含む小さな開発クラスターに拡張し、その後、データ量が増え続けると、実稼働環境に展開されたクラスターに数百のブローカーが含まれるようになります。オンラインクラスターをスケーリングしても、システム全体の可用性には影響しません。つまり、複数のブローカーを含むクラスターは、個々のブローカーに障害が発生した場合でも、顧客にサービスを提供し続けることができます。クラスターのフォールトトレランスを向上させるには、より高いレプリケーションファクターを構成する必要があります。

高性能

上記のすべての機能により、Kafka は高性能なパブリッシュおよびサブスクライブメッセージングシステムになります。プロデューサー、コンシューマー、ブローカーを水平にスケーリングすることで、Kafka は巨大なメッセージストリームを簡単に処理できます。また、大量のデータを処理しながら、1 秒未満のメッセージ遅延を保証することもできます。

エコシステム

図に示すように、Kafka はデータエコシステムに循環システムをもたらします。インフラストラクチャのさまざまなコンポーネント間でメッセージを渡し、すべてのクライアントに一貫したインターフェースを提供します。メッセージングパターンを提供するシステムと統合する場合、プロデューサーとコンシューマー間の緊密な結合はなくなり、それらの間に直接接続する必要もなくなります。プロデューサーは、誰がデータを使用しているか、またはコンシューマーが何人いるかを気にする必要がなくなるため、ビジネスニーズに基づいてコンポーネントを追加または削除できます。