Apache Kafka を理解するための 15 のポイント

1. はじめに

Kafka は世界中でよく知られており、ほとんどのインターネット企業で使用されています。それで、それは正確には何ですか?

Kafka は 2011 年に LinkedIn によってリリースされ、それ以来、膨大な量のデータを冗長的に保存し、膨大なスループット (数百万/秒) を備えたメッセージ バスを持ち、リアルタイムのストリーム タスク処理をサポートする完全なプラットフォーム レベルの製品へと進化してきました。一般的に、Kafka は分散型で、水平方向にスケーラブルで、フォールト トレラントなログ送信システムです。

これらの説明はかなり抽象的なので、その意味を一つずつ確認し、どのように機能するかを詳しく見ていきましょう。

2. 分散型

分散システムとは、異なるマシン上のサービス インスタンスが全体として連携して動作し、ユーザーに完全なサービスを提供することを意味します。 Kafka の分散は、さまざまなノード上の情報の保存、受信、送信に反映されます。それがもたらす利点は、スケーラビリティとフォールト トレランスです。

3. 水平スケーラビリティ

まず垂直スケーラビリティを定義しましょう。たとえば、従来のデータベース サービスが過負荷になり始めた場合は、サーバー リソース (CPURAMSSD) を拡張するだけで問題をキャッシュできます。これは垂直スケーリングと呼ばれ、単一のポイントでリソースを追加します。ただし、基盤となるハードウェア リソースが限られており、ダウンタイムが必要になるという 2 つの致命的な欠点があります。逆に、水平スケーリングでは、サービスを展開するためにマシンを追加することで同様の問題を解決します。

4. フォールトトレランス

分散システムは、一定レベルのエラーを許容するように設計されています。単一ポイント展開とは異なり、例外が発生すると、サービス全体が利用できなくなります。 5 つのノードを持つ Kafka インスタンスは、2 つのノードがダウンしても動作を継続できます。

5. コミットログ

コミット ログは、追加可能で順序付けされた永続的なデータであり、変更や削除ができないという点で、先行書き込みログ (WAL) やトランザクション ログに似ています。

この構造は Kafka の中核であり、順序付け機能を提供します。これにより、決定論的な処理が保証されます。これらはどちらも分散システムにおける重要な問題です。

Kafka は通常、メッセージをディスクに保存します。ディスクの順序付き読み取り特性を最大限に活用します。読み取りと書き込みの時間計算量は O(1) であり、これは非常に顕著です。さらに、読み取り操作と書き込み操作は相互に影響を及ぼさず、書き込み操作によって読み取り操作がロックされてブロックされることもありません。

6. 仕組み

プロデューサーはメッセージを Kafka ノードに送信し、そのメッセージはトピックに保存されます。コンシューマーはメッセージを受信するためにトピックをサブスクライブします。これは生産サブスクリプション モデルです。ノードトピック内のデータ量が大きくなりすぎないようにするために、Kafka ではパーティショニングの概念が導入され、パフォーマンスとスケーラビリティが向上します。 Kafka は、パーティション内のすべてのメッセージが到着順に並べ替えられるようにします。メッセージを区別する方法は、オフセットを使用することです。これは、通常の配列の添字インデックスと考えることができます。

Kafka のブローカー サービス ノードは愚かで、コンシューマーは賢いです。 Kafka はコンシューマーの読み取り操作を記録したり、メッセージを削除したりしません。代わりに、データは一定期間保存されるか、特定のサイズのしきい値に達します。コンシューマーはオフセットを自由に調整して、必要なメッセージを繰り返し取得したり破棄したりできます。

プロセスが同じメッセージを 2 回読み取るのを避けるために、Kafka では、1 つ以上のメッセージ送信者インスタンスを含むコンシューマー グループの概念が導入され、各グループには、パーティション化されたメッセージを同時に消費するインスタンスが 1 つだけ存在するように規定されていることは注目に値します。しかし、これにより、コミュニティでも解決できない問題、つまり Kafka の再バランス問題が発生しました。これは本質的に、コンシューマー グループのすべてのコンシューマー インスタンスがサブスクライブされたトピックの各パーティションを割り当てるために合意に達する方法を規定するプロトコルです。グループ メンバーの数、サブスクライブされたトピックの数、サブスクライブされたトピックのパーティションの数が変更されると、最も公平な割り当て戦略を実現するために再バランスがトリガーされます。ただし、GCのSTWと似ています。再バランス調整中、すべてのコンシューマー インスタンスは消費を停止し、接続を再割り当てします。この状況を避け、コンシューマー インスタンスの数をパーティションの数と等しくするようにしてください。

7. ディスクへの永続性

前述したように、Kafk はメッセージを RAM ではなくディスクに保存します。どのようにしてこの選択が行われるのか、驚かれるかもしれません。これを実現するには、その背後に多くの最適化が必要です。はい、実際、最適化ポイントには次のものが含まれます。

1. Kafka の通信プロトコルはメッセージのマージをサポートし、ネットワーク トラフィックの転送を削減します。ブローカー ノードは一度に大量のデータを継続的に保存し、コンシューマーは一度に大量のメッセージを取得できます。
2. オペレーティング システムは、先読みおよび後書きキャッシュ技術を使用して、ディスク上の線形読み取りおよび書き込み速度を高速化します。最新のディスクが遅いという結論は、ディスク シークを必要とするシナリオに基づいています。
3. 最新のオペレーティング システムでは、ページ キャッシュ テクノロジが導入されています。ページ キャッシュは複数のディスク ブロックから構成されます。 Linux はファイルを読み書きするときに、ファイルの論理コンテンツをキャッシュして、ディスク マッピングとデータへのアクセスを高速化します。
4. Kafka は不変の標準バイナリ形式を使用してメッセージを保存し、ゼロコピー技術を最大限に活用してページ キャッシュからソケット チャネルにデータを直接コピーします。

8. データの分散と複製

Kafka がどのようにフォールト トレランスを実現し、ノード間でデータを分散するかについて説明します。

Kafka は、ブローカーの障害によりデータがアクセス不能になるのを防ぐために、パーティション データを複数のブローカー ノードにコピーします。ブローカー ノードは、任意の時点でパーティションを「所有」し、アプリケーションがそのパーティションを読み書きするノードになります。これはパーティション リーダーと呼ばれ、受信したデータを他の N 個のブローカー ノードに複製します。他の N 個のブローカー ノードはフォロワーと呼ばれ、リーダー ノードが停止したときにリーダーとして選出される準備ができています。このモードでは、メッセージが失われにくくなります。メッセージの重要度に応じてレプリケーション ファクター パラメータを調整できます。次の図は、3 つのレプリカを持つ 4 つのブローカー ノードの例です。

プロデューサーまたはコンシューマーが、どのノードがパーティションのリーダーであるかを正しく知るにはどうすればよいのか疑問に思うかもしれません。実際、Kafka はこの情報を Zookeeper サービスに保存します。

9. 動物園飼育員サービス

Zookeeper は、信頼性が高く、読み取りパフォーマンスも高いが、書き込みパフォーマンスが低い分散 KV ディレクトリ ストレージ システムです。多くの場合、メタデータを保存し、ハートビートや構成などのクラスターのステータスを保存するために使用されます。

Kafka は次のメッセージを Zookeeper に保存します。

1. コンシューマグループの各パーティションのオフセットですが、Kafka は後でそれを内部トピック __consumer_offsets に保存します。
2. アクセス権リスト
3. 生産者と消費者のレート制限
4. パーティションリーダーの情報とその健全性状態

10. コントローラー

分散システムは調整されなければなりません。イベントが発生すると、ノードは何らかの方法で反応する必要があります。コントローラーは、クラスターがどのように反応するかを決定し、ノードに何かを実行するよう指示する役割を担います。機能が複雑になりすぎないブローカー ノードです。その最も重要な役割は、ノードがオフラインになって再参加したときに、再バランスを取り、新しいパーティション リーダーを割り当てることです。

コントローラーは、ZooKeeper Watch イベントからブローカー ノード インスタンスがオフラインであること (またはノードの有効期限が切れていること。これは通常、ブローカーが長時間ビジー状態になり、異常なハートビートを引き起こした場合に発生します) を認識し、それに応答して影響を受けるパーティションの新しいリーダーになるノードを決定し、leaderAndlsr 要求を通じて新しいリーダーからのデータのレプリケーションを開始するように関連する各フォロワーに通知します。

上記から、元々パーティションのリーダーであったブローカー ノード インスタンスが再起動されると、どのパーティションのリーダーとしても機能しなくなり、コンシューマーはこのノードからのメッセージを読み取らなくなり、リソースの無駄が生じることがわかります。幸いなことに、Kafka には優先リーダー レプリカと呼ばれる概念があります。これは、元々パーティションのリーダーであったノードのレプリカ (ブローカー ID によって区別されます) として理解できます。レプリカが利用可能な場合、Kafka はクラスターを以前の状態に復元します。このプロセスは、auto.leader.rebalance.enabled=true を設定することで自動的にトリガーできます。デフォルト値は true です。

ブローカー ノードのオフラインは通常は短時間で、しばらくすると回復します。そのため、ノードがクラスターを離れるときに、それに関連付けられたメタデータは削除されず、それがパーティションのフォロワーである場合、システムはこのパーティションに新しいフォロワーを再割り当てしません。

ただし、復元されたノードはまだ資格を満たしていないため、最後のリーダー ステータスをすぐに回復することはできないことに注意してください。

11. ロシア

レプリカ同期キュー ISR (同期レプリカ) はリーダーによって管理されます。フォロワーがリーダーからデータを同期する際に遅延が発生します。しきい値を超えたレプリカは ISR リストから削除され、OSR (Out-of-Sync Replicas) リストに保存されます。新しいフォロワーも最初に OSR に保存されます。

フォロワーがリーダーとして選出されるには、ISR キューに入っている必要があります。ただし、同期レプリカが存在せず、既存のリーダーがすべてオフラインであるような特殊なケースでは、一貫性よりも可用性が優先されることがあります。

ISR リストの保守基準は次のとおりです。

1. replica.lag.time.max.ms 構成規則で指定されているように、過去 X 秒以内にリーダー メッセージが完全に同期されている
2. zookeeper.session.timeout.ms 構成規則で指定された最後の X 秒以内に、Zookeeper にハートビートを送信します。

12. プロデューサーACK設定

明らかに、リーダーがオフラインになる原因となる一連の予期しないイベントが発生します。リーダー ノードがプロデューサーからメッセージを受信し、そのノードが ack を保存して応答した後にクラッシュした場合、Kafka は ISR リストから新しいリーダーを選出します。ただし、プロデューサー ack 構成はデフォルトで 1 に設定されているため、フォロワーの同期状況ではなくリーダーの受信状況のみが考慮され、最終的には一部のメッセージが失われることになります。したがって、プロデューサー側で acks=all を設定し、書き込みが成功したと見なされる前に、各データがすべてのコピーに書き込まれるようにする必要があります。もう 1 つの意味は、少なくとも 1 人のリーダーと 1 人のフォロワーがいるということです。ただし、この設定はクラスターのパフォーマンスに影響し、スループットを低下させ、プロデューサーが次のメッセージ バッチを送信する前に待機する時間が長くなります。

13. 水位

ack=all 規則では、メッセージがすべての ISR リストに同期されるまで、リーダー ノードはメッセージを返さないことが規定されています。さらに、ノードはすべての同期レプリカの最大オフセット、つまり高水準点オフセット HW を追跡します。コンシューマーは、オフセットがパーティション HW より大きいパーティションのリーダー レプリカ内のメッセージを消費できません。レプリカがリーダーレプリカになったとき、ブローカーがクラッシュしてレプリカが ISR から追い出されたとき、プロデューサーがリーダーにメッセージを書き込んだとき、およびリーダーがフォロワーのフェッチ要求を処理したとき、リーダーはパーティション HW を更新しようとします。これにより、データの一貫性が確保され、通常の消費中に古い値が読み取られるのを防ぎます。

14. スプリットブレイン

通常は正常に動作しているコントローラが、GC-STW の長時間実行により使用不可になったとします。その後、Zookeeper は /controller ノード (ノード 3) が期限切れであると見なし、すぐに削除して、他のブローカー ノードに通知を送信します。他の各ブローカー ノードは、コントローラー ノードへのアップグレードを試みます。ノード 2 が競争に勝ち、新しいコントローラー ノードになり、ZK に /controller ノードを作成したと仮定します。

その後、他のノードは通知を受信し、GC でまだ一時停止中のノード 3、または通知がまったく到着していないノード 3 を除いて、ノード 2 が新しいコントローラー ノードになったことを認識します。つまり、ノード 3 はリーダーシップが変更されたことを認識せず、依然として自身がコントローラー ノードであると考えています。この時点で、2 つのコントローラーが同時に存在し、潜在的に競合するコマンドを並行して発行し、深刻な結果を招くことになります。

幸いなことに、Kafka は実際のコントローラーを簡単に区別するためのエポック番号方式を提供しています。これは自動的に増加するシリアル番号であり、その情報は ZooKeeper に保存されます。明らかに、シリアル番号が最も大きいノードが実際のノードです。

15. Kafka はいつ使用すればよいですか?

上記の点からわかるように、Kafka はイベント駆動型アーキテクチャの中心部分となり、アプリケーションを互いに完全に分離できるようになります。