Apache Kafka クイック スタート ガイド

導入

Kafka はパブリッシュ/サブスクライブ型のメッセージング システムです。もともと LinkedIn で始まり、2011 年にオープンソースの Apache プロジェクトとなり、2012 年に Apache トップレベル プロジェクトになりました。Kafka は Scala と Java で記述されており、分散型のスケーラブルなアーキテクチャと永続性、高スループット機能により広く使用されています。

[[282225]]

メッセージキュー

通常、プロジェクトでは、次の要件によりメッセージ キュー モジュールを導入します。

1. 分離: メッセージ システムは、処理プロセスの途中に暗黙的なデータベース インターフェイス層を挿入することと同じです。異なるインターフェース アドレスや要求応答仕様を事前に定義する必要がないため、アップストリーム データとダウンストリーム データは、双方の処理プロセスを独立して決定できます。サービス タイプとビジネス要件を任意に拡張するには、データ形式について合意するだけで済みます。

2. バッファ: メッセージ システムは、アクセス量が不均一な一般的な状況に対処するためのバッファ プールとして機能します。たとえば、特別な休日にはトラフィックが急増したり、一日の時間帯によって訪問数に差が生じたりします。そして、さまざまなデータ タイプを処理するためのさまざまなリアルタイム要件。これにより、ビジネス処理アーキテクチャ全体において、低コストで一定の柔軟性を実現できます。

3. 非同期: 多くの場合、ユーザーはメッセージをすぐに処理することを望まなかったり、その必要がありません。メッセージ キューは、ユーザーがメッセージをキューに入れてもすぐには処理しない、非同期処理メカニズムを提供します。必要な数のメッセージをキューに入れて、必要なときに処理することができます。

Kafkaの特徴

分散型のパブリッシュ/サブスクライブ ベースのメッセージング システムとして。 Kafka の主な設計目標は次のとおりです。

1. O(1)の時間計算量でメッセージの永続化機能を提供し、TBレベルを超えるデータに対しても一定の時間計算量でのアクセスパフォーマンスを保証します。

2. 高いスループット。非常に安価な商用マシンでも、1 台のマシンで 1 秒あたり 10 万件を超えるメッセージの送信をサポートできます。

3. 各パーティション内でのメッセージの順次送信を保証しながら、Kafka サーバー間のメッセージのパーティション分割と分散消費をサポートします。

4. オフラインデータ処理とリアルタイムデータ処理の両方をサポートします。

5.オンラインでの水平拡張をサポートします。

Kafka アーキテクチャ

上の図に示すように、一般的な Kafka アーキテクチャには、複数のプロデューサー (サーバー ログ、ビジネス データ、ページ フロント エンドによって生成されたページ ビューなど)、複数のブローカー (Kafka は水平拡張をサポートしています。一般に、ブローカーの数が多いほど、クラスターのスループットが高くなります)、複数のコンシューマー (グループ)、および Zookeeper クラスターが含まれます。 Kafka は Zookeeper を使用して、クラスター構成の管理、リーダーの選出、コンシューマー グループの変更時の再バランス調整を行います。プロデューサーはプッシュ モードを使用してブローカーにメッセージを公開し、コンシューマーはプル モードを使用してブローカーからのメッセージをサブスクライブして消費します。

用語集:

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

トピックはメッセージのクラスとして考えることができます。各トピックは複数のパーティションに分割され、各パーティションはストレージ レベルで追加されるログ ファイルになります。このパーティションに公開されたメッセージはすべて、ログ ファイルの末尾に追加されます。ファイル内の各メッセージの位置はオフセットと呼ばれます。オフセットは、メッセージを一意にマークする長い数値です。各メッセージはパーティションに追加され、ディスクに順番に書き込まれるため、非常に効率的です。これは、Kafka の高スループットの重要な基盤です。

プロデューサーがブローカーにメッセージを送信すると、ブローカーはパーティション メカニズムに基づいて、どのパーティションにメッセージを保存するかを選択します。パーティション メカニズムが適切に設定されていれば、すべてのメッセージを異なるパーティションに均等に分散できるため、負荷分散が実現します。トピックがファイルに対応している場合、ファイルが配置されているマシンの I/O がトピックのパフォーマンスのボトルネックになります。パーティションを使用すると、異なるメッセージを異なるブローカーの異なるパーティションに並行して書き込むことができるため、スループットが大幅に向上します。新しいトピックのデフォルトのパーティション数は、構成項目 num.partitions を通じて指定することも、トピックの作成時にパラメータを通じて指定することもできます。トピックを作成した後、Kafka が提供するツールを使用して変更することもできます。

Kafkaのレプリケーションメカニズム

Kafka の各トピック パーティションは n 回複製されます。ここで、n はトピックのレプリケーション係数です。これにより、クラスター サーバーに障害が発生した場合に Kafka がこれらのレプリカに自動的に切り替えられるため、障害発生時にもメッセージが引き続き利用可能になります。 Kafka のレプリケーションはパーティションの粒度に基づいており、パーティションの先行書き込みログは n 台のサーバーに複製されます。 n 個のレプリカのうち、1 つのレプリカがリーダーとして機能し、他のレプリカはフォロワーになります。名前が示すように、プロデューサーはリーダー パーティションにのみデータを書き込むことができ (読み取りはリーダー パーティションからのみ実行可能)、フォロワーはリーダーからログを順番にコピーすることのみが可能です。

ログ複製アルゴリズムが提供しなければならない基本的な保証は、メッセージがコミットされ、現在のリーダーが失敗したことをクライアントに通知する場合、新しく選出されたリーダーもそのメッセージを持っている必要があるということです。障害が発生した場合、Kafka はリーダーを失った ISR からフォロワーをパーティションの新しいリーダーとして選択します。言い換えれば、これはフォロワーがリーダーの書き込みの進行状況に追いついているためです。

各パーティションのリーダーは ISR を管理します。プロデューサーがブローカーにメッセージを送信すると、メッセージはまず対応するリーダー パーティションに書き込まれ、次にこのパーティションのすべてのレプリカにコピーされます。メッセージは、すべての同期レプリカ (ISR) に正常に複製された後にのみコミットされたと見なされます。メッセージ レプリケーションの遅延は最も遅い同期レプリカによって制限されるため、遅いレプリカを迅速に検出し、ISR から削除することが重要です。 Kafka レプリケーション プロトコルの詳細は若干異なります。

Kafkaの同期メカニズム

Kafka は完全に同期でも完全に非同期でもなく、ISR (In-Sync Replicas) メカニズムです。

1. リーダーは、基本的に自分と同期しているレプリカのリストを維持します。このリストは ISR と呼ばれます。各パーティションには ISR があり、リーダーによって動的に管理されます。

2. フォロワーがリーダーより大幅に遅れている場合、または一定期間データ複製要求を開始しない場合、リーダーはそれをISRから削除します。

3. ISR 内のすべてのレプリカがリーダーに ACK を送信すると、リーダーはコミットします。そうして初めて、プロデューサーはリクエスト内のすべてのメッセージがコミットされたとみなすことができます。

Kafka は、リーダーが失敗したりハングアップしたりした場合に、新しいリーダーが選出され、クライアントのメッセージを受け入れて正常に書き込むことを保証するデータ複製アルゴリズムを提供します。 Kafka は、同期されたレプリカのリストからレプリカがリーダーとして選択されるか、フォロワーがリーダー データに追いつくことを保証します。リーダーは、ISR 内のすべてのフォロワー ラグのステータスを維持および追跡する責任を負います。プロデューサーがブローカーにメッセージを送信すると、リーダーはメッセージを書き込み、それをすべてのフォロワーに複製します。メッセージはコミットされた後にのみ、すべての同期されたレプリカに正常に複製されます。メッセージの複製遅延は、最も遅いフォロワーによって制限されます。遅いコピーを素早く検出することが重要です。フォロワーがあまりにも「遅れ」すぎたり、失敗したりした場合、リーダーはそれを ISR から削除します。

メッセージ送信保証

すでに、Kafka が効果的なストレージを実行する方法を紹介し、プロデューサーとコンシューマーがどのように機能するかを理解しました。次に、Kafka がどのようにしてプロデューサーとコンシューマーの間でメッセージが送信されるかについて説明します。配達保証には次の 3 つの方法があります。

• 最大 1 回: メッセージは失われる可能性がありますが、繰り返し送信されることはありません。
• 少なくとも 1 回: メッセージは失われることはありませんが、繰り返し送信される可能性があります。
• 正確に 1 回: 各メッセージは 1 回だけ送信されます。

Kafka のメッセージ送信保証メカニズムは非常に直感的です。プロデューサーがブローカーにメッセージを送信すると、メッセージがコミットされると、レプリケーション メカニズムが存在するため、メッセージは失われません。ただし、プロデューサーがブローカーにデータを送信した後にネットワークの問題が発生し、通信が中断された場合、プロデューサーはメッセージがコミットされたかどうかを判断できません。 Kafka はネットワーク障害時に何が起こったのかを判断できませんが、プロデューサーはメッセージがブローカーに正しく送信されたことを確認するために複数回再試行できるため、Kafka は現在「少なくとも 1 回」を実装しています。

コンシューマーがブローカーからメッセージを読み取った後、コミットを選択できます。これにより、コンシューマーが読み取ったメッセージのオフセットが Zookeeper のパーティションに保存されます。次にコンシューマーがパーティションを読み取るときは、次のエントリから読み取りを開始します。コミットされていない場合、次の読み取りの開始位置は、最後のコミット後の開始位置と同じになります。もちろん、コンシューマーを自動コミットに設定することもできます。つまり、コンシューマーはデータを読み取ると自動的にコミットします。メッセージの読み取りプロセスについてのみ説明すると、Kafka は正確に 1 回だけを保証します。ただし、プロデューサーとブローカーの間で何らかの理由でメッセージが重複した場合、少なくとも 1 回は重複します。

Consumer がメッセージを読み取った後にコミットし、それを処理する状況を考えてみましょう。このモードでは、コミット後にメッセージを処理する前にコンシューマーがクラッシュした場合、コンシューマーは次回再起動したときに、送信されたばかりで処理されていないメッセージを読み取ることができなくなります。これは「最大 1 回」に相当します。メッセージを読んだ後、まずそれを処理してからコミットします。このモードでは、メッセージを処理した後、コミットする前に Consumer がクラッシュした場合、Consumer は次回再起動したときにコミットされていないメッセージを処理します。実際、メッセージはすでに処理されており、少なくとも 1 回は処理されています。

正確に 1 回だけを実現するには、メッセージの重複排除メカニズムを導入する必要があります。 GUID (Globally Unique Identifier) の概念は Kafka ドキュメントに記載されています。各メッセージの一意の ID はクライアント生成アルゴリズムを通じて取得され、ブローカーに保存されているアドレスにマッピングできます。つまり、メッセージの内容を GUID を通じて照会および抽出することができ、送信者が冪等性を確保するのにも便利です。この重複排除処理モジュールはブローカー上で提供される必要がありますが、現在のバージョンではサポートされていません。

GUID の場合、クライアントの観点から重複を排除したい場合、集中型キャッシュを導入する必要があり、必然的に依存関係の複雑さが増します。さらに、キャッシュのサイズを定義することは困難です。 Kafka だけでなく、RabbitMQ や RocketMQ などの商用グレードのミドルウェアも少なくとも 1 回しか保証されておらず、それ自体でメッセージの重複排除を行うことはできません。したがって、ビジネス関係者は、独自のビジネス特性に基づいて重複排除を実行することをお勧めします。たとえば、ビジネス メッセージ自体に冪等性があったり、Redis などの他の製品が重複排除に使用されていたりします。

メッセージキューとしての Kafka:

従来のメッセージングには、キューイングとパブリッシュ/サブスクライブの 2 つのモードがあります。キュー モードでは、コンシューマーのプールがサーバーからメッセージを読み取ります (各メッセージはそのうちの 1 つのコンシューマーによってのみ読み取られます)。パブリッシュ/サブスクライブ モード: メッセージはすべてのコンシューマーにブロードキャストされます。どちらのモードにも長所と短所があります。キューの利点は、複数のコンシューマーが処理データを共有できるため、処理を拡張できることです。ただし、複数のサブスクライバーとは異なり、キューは、メッセージ リーダー プロセスが読み取り後に失敗した場合に失われるメッセージとは異なります。パブリッシュとサブスクライブでは複数のコンシューマーにデータをブロードキャストできますが、各サブスクライバーがメッセージをサブスクライブするため、処理をスケーリングする方法はありません。

Kafka には 2 つの形式の Consumer Group があります。

a.キュー: 同じ名前を持つコンシューマー グループのメンバーが一緒に処理できるようにします。

b.パブリッシュとサブスクライブ: 複数のコンシューマー グループにメッセージをブロードキャストします。

各 Kafka トピックにはこれら 2 つのモードがあります。

従来のメッセージング システムはデータを順番に保存します。複数のコンシューマーがキューから消費する場合、サーバーは保存されている順序でメッセージを送信します。ただし、サーバーは順番に送信しますが、複数の並列リクエストは非同期になるため、メッセージが順不同で到着する可能性があります。つまり、メッセージが並行して消費される限り、順序は保証されません。メッセージング システムでは、多くの場合、単一のコンシューマーのみを使用することでこの問題を解決しますが、これは並列処理が使用されないことを意味します。

Kafka は従来のメッセージング システムよりも強力な順序保証を備えています。並列トピックの分割により、Kafka は順序の保証と負荷分散を実現します。各パーティションは、同じコンシューマー グループ内の 1 つのコンシューマーによってのみ消費されます。また、コンシューマーがパーティションの唯一のコンシューマーであり、データを順番に消費していることを確認します。各トピックに複数のパーティションがある場合は、複数のコンシューマーの負荷を分散する必要がありますが、同じコンシューマー グループ内のパーティション数よりも多くのコンシューマーが存在することはできないことに注意してください。そうしないと、余分なコンシューマーは無駄に待機することになり、メッセージを受信できなくなります。

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

メッセージをメッセージ キューに公開し、それを消費から分離するすべてのシステムは、実際には一時的なストレージ システムとして機能します。 Kafka は非常に高性能なストレージ システムでもあります。 Kafka に書き込まれたデータはディスクに書き込まれ、フォールト トレランスを確保するためにクラスター全体に複製されます。これにより、メッセージが完全に書き込まれるまでプロデューサーはメッセージの確認応答を待つことができます。 Kafka のストレージ構造により、サーバー上のデータが 50 KB でも 50 TB でも実行効率は同じになり、水平拡張の目標が達成されます。 Kafka は、高パフォーマンス、低レイテンシ、コミット ログの保存、レプリケーション、および伝播に特化した分散ファイル システムと考えることもできます。

Kafka ストリーム処理

Kafka のより高い目標は、リアルタイムのストリーム処理です。 Kafka では、ストリーム処理によって入力トピックからデータが継続的に取得され、処理されてから出力トピックに書き込まれます。たとえば、小売アプリは売上と出荷の入力ストリームを受け取り、数量を数えたり価格を調整したりして、出力します。

単純な要件は、Producer API と Consumer API を使用して直接処理できます。複雑な変換のために、Kafka はより強力な Streams API を提供します。これにより、計算を集約したり、ストリームを接続したりする複雑なアプリケーションを構築できます。

まとめると、Kafka の設計は多くのアーキテクチャ上の問題を解決するのに役立ちます。しかし、Kafka の高性能、低結合、高信頼性などの機能を有効に活用するには、Kafka と自社のビジネスニーズを十分に理解し、アプリケーション シナリオを総合的に検討する必要があります。

[この記事は51CTOコラム「AiChinaTech」、WeChatパブリックアカウント（id:tech-AI）からのオリジナル記事です]

この著者の他の記事を読むにはここをクリックしてください