2.6.1 Apache Kafka の概要
2.6.1.1 概要
すべての組織は、データの観点から非常にシンプルな方法で開始されます。 組織のデータエコシステムは、1 つのソースシステムと 1 つのターゲットで始まります。 ソースシステムはターゲットシステムにデータを送信します。 簡単だろ？
そんなに単純なままでいればなあ。 組織は簡単な設定ですぐに追い越し、ソースシステムとターゲットシステムの数が急速に増加します。 これらすべての様々なソースや宛先が相互にデータを交換する必要があり、物事はすぐに非常に複雑になります。
例えば、組織に 4 つのソースと 6 つの宛先があり、これらすべてのアプリケーションが互いに通信する必要がある場合、24 の統合を構築する必要があります。これらの統合にはそれぞれ独自の困難が伴います。
- プロトコル：データの転送方法（TCP、HTTP、REST、FTP など）
- データ形式：データの解析方法（バイナリ、CSV、JSON、Parquet など）
- データスキーマと進化：データモデルとは何ですか？また、どのように進化しますか？
さらに、ソースシステムを宛先システムに接続するたびに、その接続からのこれらのシステムの負荷が増加します。
どうやって解決するの？ そこで、Apache Kafka が役に立ちます。 Apache Kafka を使用すると、共通の高スループットの分散メッセージングシステムを提供することで、組織はデータストリームとシステムを分離できます。 Source システムはデータを Apache Kafka に送信し、宛先システムは Apache Kafka のデータを使用します。
企業が管理する必要があるすべてのタイプのデータソースについて考えてみましょう。
- web サイトのイベント
- モバイルアプリイベント
- POS イベント
- CRM データ
- callcenter データ
- トランザクション履歴
- …
また、企業がエコシステムで使用するすべてのタイプの宛先エクスペリエンスを考えてみましょう。これらのエコシステムでは、すべてのユーザーにこれらのソースシステムからのデータが必要になる可能性があります。
- CRM
- データレイク
- 電子メールシステム
- 監査
- analytics
- …
Apache Kafka は LinkedIn によって作成され、現在は主に Confluent によって管理されるオープンソースプロジェクトです。
Apache Kafka は、耐障害性を備えた分散された回復力のあるアーキテクチャを提供します。 ブローカーの数を水平方向に 100 に拡大でき、1 秒あたり数百万のメッセージに拡大できます。 10 ms 未満の待ち時間で高いパフォーマンスを提供し、リアルタイムのユースケースに最適です。
いくつかのユースケースの例を次に示します。
- メッセージングシステム
- アクティビティトラッキング
- 様々な場所から指標を収集する
- アプリケーションログの収集
- ストリーム処理（Kafka ストリーム API または Spark を使用）
- システム依存関係の分離
- Spark、Flink、Storm、Hadoop、その他多くのビッグデータテクノロジーとの統合。
以下に例を示します。
- Netflix は Kafka を使用して、テレビ番組を見ている間にリアルタイムでレコメンデーションを適用します
- Uber は Kafka を使用して、ユーザー、タクシー、旅行のデータをリアルタイムで収集し、需要を計算および予測し、サージ価格をリアルタイムで計算します
- LinkedIn は、Kafka を使用してスパムを防ぎ、ユーザーのインタラクションを収集して、リアルタイムでより優れた接続レコメンデーションを行います
これらすべてのユースケースで、Kafka は輸送メカニズムとしてのみ使用されます。 Kafka はアプリケーション間でのデータの移動が非常にうまい。
2.6.1.2 Kafka 用語
メッセージ
メッセージは、システムから Kafka に送信される通信です。 メッセージにはペイロードが含まれ、ペイロードにはデータ要素が含まれます。 例えば、web サイトからAdobe Experience Platformに送信されたエクスペリエンスイベントは、メッセージと見なされます。
トピック，パーティション，オフセット
トピックは、データベース内のテーブルに似た、特定のデータストリームです。 必要な数のトピックを含めることができ、トピックはその名前で識別されます。 トピックはパーティションで分割されます。 各パーティションは順序付けされ、パーティション内の各メッセージは増分 ID を取得します。この ID は offset と呼ばれます。 メッセージは、パーティション上のトピックに格納され、オフセットを使用して参照されます。 メッセージは限られた期間のみ保持されます（デフォルトは 1 週間）。 一度パーティションに書き込まれたメッセージは変更できません。
ブローカー
ブローカはサーバーに似ています。 Kafka クラスターは、複数のブローカー（サーバー）で構成されています。 各ブローカは ID で識別され、特定のトピックパーティションを含みます。
複製
Kafka は分散システムです。 分散システムの重要な点の 1 つは、データが安全に保存されることであり、したがってレプリケーションが必要となります。 結局のところ、1 つのブローカー（サーバー）がダウンしても、別のブローカー（サーバー）は、ダウンしたブローカーに最初に保存されたメッセージにアクセスできます。 レプリケーションでは、複数のブローカーにわたってメッセージのコピーを作成し、データが失われないようにします。
生産者
データはどのように Kafka に送信されますか？ それはプロデューサーの役割だ。 プロデューサーは、ソースシステムに接続し、ソースシステムからデータを取得し、そのデータをパーティションにトピックに書き込みます。 Kafka クラスターの設定に基づいて、プロデューサーはどのブローカーとパーティションに書き込むかを自動的に把握します。 複数のブローカーとレプリケーション戦略を備えた分散システムでは、プロデューサーは複数のブローカーをまたいでランダムにデータを保存します。つまり、自動的にロードバランシングを行います。
メッセージキー
プロデューサーは、メッセージと共にキーを送信することを選択できます。 キーには、任意の文字列、数値などを使用できます。 キーが指定されていない場合、メッセージはブローカーにランダムに送信されます。 キーが送信された場合、そのキーのすべてのメッセージは常に同じパーティションに送られます。 メッセージキーなどを使用して、特定のフィールドに基づいてメッセージの順序を指定します。
消費者
消費者は、Apache Kafka トピックからデータを読み取り、そのデータを宛先システムと共有します。 消費者はどのブローカーから読むべきかを知っています。 データは、各パーティション内で順番にコンシューマーによって読み取られます。 消費者は、消費者グループ内のデータを読み取ります。
飼育員
ZooKeeper は、基本的に、階層キー値ストアを提供する分散システム用のサービスです。このサービスを使用して、大規模な分散システム向けに分散設定サービス、同期サービス、命名レジストリを提供します。 Zookeeper は Apache Kafka を使用する前に実行する必要があります。Zookeeper は Kafka の式典のマスターのようなもので、Kafka がイベントを生成して消費しながら、バックエンドで分散サービスを管理します。
この演習は完了しました。