Kafka のクラスタ内レプリケーション機能の詳細な分析

Kafka は分散型のパブリッシュ/サブスクライブ メッセージング システムです。 LinkedIn によって開発され、2011 年 7 月に Apache Linux プロジェクトになりました。Kafka は、主にログ集約、メッセージ キュー、リアルタイム監視などに、LinkedIn や Twitter など多くの企業で広く使用されています。

バージョン 0.8 以降、Kafka はクラスター内レプリケーションをサポートし、可用性とシステムの安定性を向上させます。この記事では主に、Kafka レプリケーションの設計について概説します。

コピー

レプリケーションにより、Kafka クライアントは次の利点を得ることができます。

• プロデューサーは、障害が発生してもメッセージを公開し続けることができ、アプリケーションに応じてレイテンシと耐久性を選択できます。
• 障害が発生した場合でも、消費者はリアルタイムで正しいメッセージを受信し続けることができます。
• すべての分散システムは、一貫性、可用性、およびパーティション耐性の間でバランスを取り、トレードオフを行う必要があります (CAP 定理を参照)。 Kafka の目標は、単一のデータセンター内の Kafka クラスターのレプリケーションをサポートすることです。ネットワーク パーティションは比較的まれであるため、Kafka は高可用性と強力な一貫性に重点を置いて設計されています。強力な一貫性とは、すべてのレプリカがまったく同じデータを持つことを意味し、これによりアプリケーション開発者の作業が簡素化されます。

Kafka は CA ベースのシステム (???)、Zookeeper は CP ベースのシステム (間違いない)、Eureka は AP ベースのシステム (間違いない) です。

強力なレプリケーション一貫性

既存のより成熟したソリューションの中には、強力な一貫性レプリケーションを維持するための典型的な方法が 2 つあります。どちらのアプローチでも、レプリカの 1 つをリーダーとして指定し、すべての書き込みをそのレプリカに対して発行する必要があります。リーダーはすべてのアクセスを処理する責任を負います。そして、これらの書き込みを他のフォロワー コピーにブロードキャストし、レプリケーションの順序がリーダーの順序と一致していることを確認します。

• 最初の方法はクォーラムに基づいています。リーダーは、レプリカの過半数がデータを受信するまで待機します。リーダーが失敗した場合、フォロワーの大多数が協力して新しいリーダーを選出します。このアプローチは、Apache Zookeeper と Google の Spanner で使用されています。
• 2 番目の方法は、リーダーがすべてのレプリカがデータを受信するのを待つことです (重要な注意: Kafka では、この「すべて」はすべての In-Sync レプリカを指します)。リーダーが失敗した場合、他のレプリカが新しいリーダーとして選出される可能性があります。

Kafka レプリケーションでは、主に次の 2 つの理由から 2 番目の方法を選択します。

レプリカの数が同じであれば、2 番目の方法の方がより多くの障害を許容できます。たとえば、レプリカは合計で 2n+1 個あります。 2 番目の方法は 2n 個のレプリカ障害に耐えることができます (ISR が 1 つある限り、書き込みは正常に実行できます)。一方、最初の方法は n 個のレプリカ障害にしか耐えられません。レプリカが 2 つしかない場合、最初の方法ではいずれかのレプリカの障害を許容できません。

最初の方法は、確認に定足数の人々だけを必要とするため、レイテンシ パフォーマンスが向上し、一部の低速レプリカの影響が隠されます。 Kafka レプリカは、同じデータセンター内のクラスター内に配置するように設計されています。したがって、ネットワーク遅延などの変数は比較的小さくなります。

用語

Kafka でレプリケーションがどのように実装されているかを理解するには、まずいくつかの基本的な概念を紹介する必要があります。 Kafka では、メッセージ フローはトピックによって定義され、トピックは 1 つ以上のパーティションに分割されます。レプリケーションはパーティション レベルで行われ、各パーティションには 1 つ以上のレプリカが存在します。

レプリカは、Kafka クラスター内の異なるサーバー (ブローカーと呼ばれる) に均等に分散されます。各レプリカはディスク上にログを保持します。プロデューサーによって公開されたメッセージは順番にログに追加され、ログ内の各メッセージは単調に増加するオフセットによって識別されます。

オフセットはパーティション内の論理的な概念です。オフセットを指定すると、パーティションのすべてのレプリカで同じメッセージを識別できます。コンシューマーがトピックをサブスクライブすると、消費する各パーティションのオフセットを追跡し、それを使用してブローカーにメッセージを取得する要求を行います。

デザイン

Kafka にレプリカを追加する目的は、より強力な永続性と高可用性を実現することです。 Kafka は、一部のサーバーがクラッシュした場合でも、正常に公開されたメッセージが失われず、消費できることを保証します。 Kafka レプリケーションの主な目的は次のとおりです。

設定可能な永続性の保証: たとえば、データ損失を許容できないアプリケーションでは、より強力な永続性を選択できますが、当然、それに伴ってレイテンシが増加します。大量のデータを生成し、部分的なデータ損失を許容する別のアプリケーションでは、わずかに弱い永続性を選択できますが、書き込み応答時間とスループットが向上します。

自動レプリカ管理: Kafka は、ブローカーへのレプリカの割り当てプロセスを簡素化し、クラスターの段階的な拡張と縮小をサポートする必要があります。

この場合、解決すべき主な問題が 2 つあります。

• パーティションのレプリカをブローカーに均等に割り当てるにはどうすればよいでしょうか?
• 特定のパーティションでは、各メッセージは他のすべてのレプリカにどのようにブロードキャストされますか?

データ複製

Kafka では、クライアントが非同期レプリケーションまたは同期レプリケーションを選択できます。非同期レプリケーションの場合、公開されたメッセージは 1 つのレプリカによって受信されたときに確認できます。同期レプリケーションの場合、Kafka は確認前にメッセージが複数のレプリカ (つまり効果的な ISR) に到達するように最善を尽くします。クライアントがトピックのパーティションにメッセージを公開しようとすると、Kafka はメッセージをすべてのレプリカに伝播する必要があります。カフカは次のことを決断しなければなりません:

• 広め方;
• クライアントに確認応答する前にメッセージを受信する必要があるレプリカの数。
• レプリカに障害が発生した場合はどうすればよいですか?
• 障害が発生したレプリカが復元された後に行うべきこと。

成し遂げる

レプリカの同期を維持するための一般的な戦略には、プライマリスレーブレプリケーションと調停ベースのレプリケーションの 2 つがあります。どちらの場合も、1 つのレプリカがリーダーとして設計され、他のレプリカはフォロワーと呼ばれます。すべての書き込み要求はリーダーによって処理され、リーダーは書き込み要求をフォロワーに伝播します。

マスタースレーブ レプリケーションでは、リーダーはグループ内のすべてのレプリカへの書き込みが完了するまで待機してから、クライアントに確認応答を送信します。レプリカに障害が発生した場合、リーダーはそれをグループから削除し、残りのレプリカへの書き込みを続行します。障害が発生したレプリカも、回復してリーダーに追いつく限り、グループに再参加できます。 n 個のレプリカを使用するという前提の下で、マスター スレーブ レプリケーション モードは n-1 個のレプリカ障害を許容できます。

調停ベースの方法では、リーダーは大多数のレプリカへの書き込みが完了するまで待機し、一部のレプリカの障害によってレプリカ グループのサイズは変更されません (たとえば、パーティションに 5 つのレプリカがある場合、2 つのレプリカに障害が発生しても、このレプリカ グループには 5 つのレプリカがあるとみなされます)。したがって、レプリカが 2n+1 個ある場合、調停ベースのレプリケーションでは n 個のレプリカ障害しか許容できません。リーダーが失敗した場合、新しいリーダーを選出するには少なくとも n+1 個のレプリカが必要です。

これら 2 つのアプローチにはトレードオフがあります。

• アービトレーションはプライマリスレーブよりも書き込みレイテンシが優れているため、レプリカの遅延 (FGC によって発生する長い STW など) によりプライマリスレーブ方式の書き込みレイテンシは増加しますが、アービトレーション方式の書き込みレイテンシは増加しません。
• レプリカの数が同じであれば、マスター/スレーブ アプローチではより多くの障害を許容できます。
• マスタースレーブ方式を前提としており、レプリケーション係数は 2 であり、これも正常に動作できます。ただし、クォーラムベースのレプリケーションでは、有効な状態を維持するために両方のレプリカが動作し続ける必要があります。
• Kafka は、より多くのレプリカ障害を許容でき、2 つのレプリカだけで正常に動作できるため、プライマリ バックアップ レプリケーションを選択します。

同期レプリケーション

Kafka 同期レプリケーションは、典型的なマスター スレーブ モードです。各パーティションには n 個のレプリカがあり、n-1 個のレプリカ障害を許容できます。 1 つのレプリカのみがリーダーとして選出され、他のレプリカはフォロワーになります。リーダーは ISR セットを維持します。このレプリカ セットはリーダーと完全に同期されており、Kafka は現在のリーダーと現在の ISR も Zookeeper に保持します。

各レプリカはローカル ログに情報を保存し、ログ内の重要なオフセット位置を維持します。 LEO はログの末尾を示し、HW はコミットされた最新のメッセージのオフセットです。各ログは定期的にディスクに同期され、更新されたオフセットより前のデータはディスク上に残ることが保証されます。

書く

パーティションにメッセージを公開するには、クライアントはまず ZooKeeper からパーティションのリーダーを見つけ、次にリーダーにメッセージを送信します。リーダーはメッセージをローカル ログに書き込み、各フォロワーはリーダーから最新のメッセージを頻繁に取得します。したがって、フォロワーが受信するすべてのメッセージの順序はリーダーと一致します。フォロワーは受信した各メッセージをローカル ログに書き込み、リーダーに確認を送信します。リーダーがすべての ISR レプリカから確認応答を受信すると、メッセージをコミットできます。リーダーは HW を進め、クライアントに確認応答を送信します。パフォーマンスを向上させるために、各フォロワーはメッセージをメモリに書き込んだ後に確認を送信します。したがって、コミットされたメッセージごとに、複数のレプリカの内容に保存されることが保証されます。ただし、コミットされたメッセージがレプリカによってディスクに保存されているという保証はありません。

このような相関障害は比較的まれであるため、このアプローチにより、応答時間と耐久性のバランスが適切に保たれます。将来的には、Kafka はより強力な保証を提供するためにオプション パラメータの追加を検討する可能性があります。

読む

簡単にするために、読み取りもリーダーによって提供され、HW を超えるメッセージのみが読み取り用にコンシューマーに公開されます。

非同期レプリケーション

非同期レプリケーションをサポートするために、リーダーはメッセージがローカル ログに書き込まれた直後にクライアントに通知できます。注意すべき唯一の点は、キャッチアップ フェーズ中に、フォロワーは HW 位置以降のデータを切り捨てる必要があることです。フォロワーは主に非同期的に複製されるため、ブローカーの障害後に送信されたメッセージが失われないという保証はありません。

コピー実装

Kafka レプリケーション図は次のとおりです。

• クラスターには合計 4 つのブローカー (broker1 ～ broker4) があります。
• トピック 1 つ、パーティション 2 つ、レプリカ 3 つ。
• パーティション 1 のリーダー (topic1-part1) はブローカー 1 上にあり、パーティション 2 のリーダー (topic1-part2) はブローカー 4 上にあります。

プロデューサーは、メッセージをパーティション topic1-part1 (ブローカー 1 上) のリーダーに書き込み、それをブローカー 2 とブローカー 3 上の 2 つのレプリカに複製します。

プロデューサーは、メッセージをパーティション topic1-part2 (ブローカー 4 上) のリーダーに書き込み、それをブローカー 2 とブローカー 3 上の 2 つのレプリカに複製します。

プロデューサーがトピックのパーティションにメッセージを公開すると、メッセージは最初にリーダー レプリカに配信され、ログが追加されます。フォロワーのレプリカは継続的にリーダーから新しいメッセージをプルし、十分な数のレプリカがメッセージを受信すると、リーダーはメッセージをコミットします。

ここでの問題は、リーダーが何が十分であるかをどのように判断するかということです。 Kafka は、同期レプリカ (ISR) のセットを維持します。この ISR レプリカ セットはすべて有効であり、リーダーのレプリカに完全に追いついており、メッセージの遅延はありません (リーダーは常に ISR セットに存在します)。パーティションが最初に作成されると、各レプリカは ISR セットに含まれます。新しいメッセージが公開されると、リーダーはすべての ISR レプリカがメッセージを受信するまで待機してから、メッセージをコミットします。フォロワー レプリカに障害が発生した場合、ISR から削除されます。リーダーは引き続き新しいメッセージを送信しますが、ISR の数はパーティションが作成されたときのレプリカの数よりも少なくなります。

現在、システムは複製モードで実行されていることに注意してください。

リーダーは、パーティション内の最後にコミットされたメッセージのオフセットを参照する高水準点 (HW) も維持します。 HW は継続的に後続のコピーに伝播されます。

カフカのハイウォーターマーク

障害が発生したレプリカが再起動されると、最初にディスクから最新の HW が復元され、ログが HW に切り捨てられます。これは、HW の後のメッセージがコミットされることが保証されていないため、破棄する必要がある場合があるために必要です。その後、レプリカはフォロワーになり、リーダーからの HW 後のメッセージを受信し続けます。レプリカがリーダーに完全に追いつくと、ISR に再度追加されます。システムは完全に複製されたモードに戻ります。

トラブルシューティング

Kafka はブローカーの障害を検出するために Zookeeper に依存しています。 Kafka はコントローラー (ブローカーの 1 つ) を使用して、障害、新しいリーダーの選出などに関するすべての Zookeeper 通知を受信します。これには、Zookeeper への負荷を軽減するという利点もあります。リーダーが失敗した場合、コントローラは ISR レプリカから新しいリーダーを選択し、新しいリーダーのメッセージを他のフォロワーに公開します。

設計上、リーダー選出プロセス中はコミットされたメッセージは常に保持され、コミットされていないメッセージの一部は失われる可能性があります。リーダーと各パーティションの ISR も Zookeeper に保存され、コントローラーがフェイルオーバーするときに必要になります。ブローカー レベルの障害は通常まれであるため、リーダーと ISR の両方が頻繁に変更されることはないと予想されます。

クライアントの場合、ブローカーはコミットされたメッセージのみをコンシューマーに公開します。ブローカーに障害が発生した場合、コミットされたデータは常に保持されます。コンシューマーは同じオフセットを使用して、リーダーとして選出された別のレプリカからメッセージをプルできます。

プロデューサーは、ブローカーがメッセージを受信した後、ブローカーから確認をいつ受け取るかを選択できます。たとえば、メッセージがリーダーによってコミットされ、すべての ISR によって確認応答されるまで待機することができます (つまり、acks=-1)。あるいは、まだコミットされていない場合でも、リーダーによってログにメッセージが追加されるように選択できます (acks=0 はリーダーの確認を待つ必要がないことを意味し、acks=1 はリーダーの確認を待つ必要があることを意味します)。前者の場合、acks=-1 であり、プロデューサーはより長く待機する必要があります。ただし、確認されたメッセージはブローカー内に保持されることが保証されます。後者の場合、acks = 0 または 1 では、プロデューサーのレイテンシは低くなり、スループットは高くなりますが、ブローカーに障害が発生すると、確認済みのメッセージの一部が失われる可能性があります。それはあなたが決めることです。