Kafka がバージョン 2.8 で Zookeeper を「放棄」した理由

[[394844]]

重量級のメッセージング ミドルウェアである Kafka が最近バージョン 2.8 をリリースし、Zookeeper への依存関係が正式に削除されたことに、皆さんも気付いたと思います。その背後にあるデザイン哲学は何ですか?外部への依存を減らすだけでしょうか?

答えは明らかにそれほど単純ではないので、ゆっくり説明しましょう。

理由を説明する前に、まず Zookeeper の典型的な使用シナリオを説明する必要があると思います。

1. Zookeeperの典型的な使用シナリオ

Zookeeper は、ビッグデータと分散フィールドの台頭と関連しています。ビッグデータにおける非常に重要な問題は、多数の安価なマシンを使用して信頼性の高いストレージを実現する方法です。

いわゆる安価な機械は故障する可能性が非常に高いですが、機械 1 台あたりのコストも非常に低いです。分散分野では、複数のマシンでクラスターを形成し、複数のマシン（レプリカ）にデータを保存することが期待されています。データの一貫性を保つために、通常はレプリケーション グループからマスター ノードを選択して、データの読み取りと書き込みを処理する必要があります。他のノードはマスターノードからデータをコピーします。マスターノードがダウンした場合、高可用性を実現するために、マスターノードを自動的に再選択する必要があります。

上記のシナリオでは、リーダー選挙という非常に重要な機能があります。マスターノードを選出し、マスターノードがダウンした後の自動再選出をサポートし、自動マスタースレーブ切り替えを実現して、高可用性を実現する方法。

Zookeeper が提供する一時的な順次ノードとイベント監視メカニズムを使用すると、リーダー選出を簡単に実装できます。

上記の t1 と t2 は、組織内に同じサービスを提供できるメンバーが複数いるが、コールド スタンバイ効果 (つまり、同時に外部にサービスを提供するメンバーは 1 つだけであり、これをリーダーと呼びます。リーダーがダウンしたり、サービスの提供を停止したりすると、組織内の他のメンバーが再びリーダーを奪い合い、外部にサービスを提供し続けます) を実現するために存在すると理解できます。

上の図に示すように、Zookeeper はクラスターにデプロイされており、単一点障害を効果的に回避し、クラスター内でデータの強力な一貫性を提供できます。

メンバーがリーダーをめぐって競争する必要がある場合、Zookeeper の助けを借りた実装ルーチンは、Zookeeper のデータ ノード (例では /app/order-service/leader) に 2 つの子ノードを作成することであり、それらは順番に一時的なノードになります。

クライアントは、作成されたノードのシーケンス番号が /app/order-service/leader 内で最も小さいシーケンス番号を持つノードであるかどうかを判断します。そうであれば、リーダーとなり、外部の世界にサービスを提供します。

シーケンス番号が最小でない場合、イベントはその前の登録ノードから削除されます。リーダーによって表されるプロセスがクラッシュすると、Zookeeper とのセッションは無効になり、それに関連付けられた一時ノードは削除されます。リーダーによって作成されたノードが削除されると、その後継ノードに通知され、リーダー選出が再度トリガーされて新しいリーダーが選出され、外部へのサービスの提供が継続され、サービスの高可用性が確保されます。

上記のシナリオを振り返ると、Zookeeper はリーダー選出を簡単に実装できるため、アプリケーションの可用性の向上が簡単になります。これは主に、Zookeeper のいくつかの機能を使用しているためです。

• 一時ノード

一時ノードはセッションに関連付けられます。一時ノードを作成したセッションが終了すると、アプリケーションによる手動削除を必要とせずに、一時ノードは自動的に削除されます。

• シーケンシャルノード
• イベントの仕組み

イベント メカニズムの助けにより、Zookeeper は他の生き残ったアプリケーション ノードに即座に通知し、選出を再トリガーできるため、自動マスター/スレーブ切り替えの実装が非常に簡単になります。

2. カフカの動物園飼育員の緊急の必要性

Kafka では多くのリーダー選挙が行われます。 Kafka に精通している友人は、トピックに複数のパーティション (データ シャード) を含めることができ、各データ シャードに複数のコピーを構成できることを知っているはずです。パーティション内のデータの一貫性を複数のコピー間でどのように確保するかが緊急に必要になります。

Kafka の実装ルーチンでは、パーティションのコピーを複数作成し、その中からリーダーを選出してクライアントの読み取りおよび書き込み要求を処理します。スレーブ ノードはマスター ノードからコンテンツをコピーします。リーダー ノードは、データが正常に書き込まれたかどうかに基づいて、コピーにデータが正常に書き込まれたかどうかを判断します。

Kafka におけるトピック パーティション分散の概略図:

したがって、ここではリーダーの選出が必要ですが、これは Zookeeper に基づいて簡単に実現できます。それから二人は意気投合し、「新婚旅行」をスタートした。

3. 動物園飼育員の弱点

Zookeeper はクラスターにデプロイされます。クラスター内のノードの半分以上が稼働している限り、サービスを提供できます。たとえば、3 つのノードで構成される Zookeeper では、1 つの Zookeeper ノードに障害が発生しても、クラスターは引き続きサービスを提供できます。 5 つのノードで構成される Zookeeper では、2 つのノードに障害が発生しても問題ありません。

ただし、Zookeeper は CP モデルとして設計されているため、データの強力な一貫性を確保するには可用性を犠牲にする必要があります。

Zookeeper クラスターには、いわゆるリーダー ノードとスレーブ ノードも存在します。リーダー ノードは書き込みを担当し、リーダー ノードとスレーブ ノードは読み取り要求を受け入れることができます。ただし、Zookeeper の内部ノードが選出されると、Zookeeper 全体が外部サービスを提供できなくなります。もちろん、通常の状況であれば、選挙は非常に迅速に進むでしょうが、異常な状況下では、何とも言えません。たとえば、Zookeeper ノードでフル GC が発生した場合、その影響は壊滅的なものになります。

Zookeeper ノードで Full GC が頻繁に発生すると、クライアントとのセッションがタイムアウトになります。現時点ではクライアントのハートビート要求 (Stop World) に応答できないため、セッションに関連付けられた一時ノードは削除されます。この時点ですべての一時ノードが削除され、Zookeeper が依存するイベント通知メカニズムが失敗し、クラスター全体の選出サービスが失敗することに注意してください。

高可用性の観点から見ると、Kafka クラスターの可用性はクラスター自体だけでなく、外部コンポーネントにも依存します。長期的に見れば、これは明らかに優れた解決策ではありません。

分散分野の関連技術の継続的な改善に伴い、分散化の考え方が徐々に現れ、Zookeeperを排除すべきだという声がますます大きくなってきました。このプロセスで、非常に優れたアルゴリズムである Raft プロトコルが登場しました。

Raft プロトコルは、リーダー選出とログ複製という 2 つの重要なコンポーネントで構成されています。ログ レプリケーションにより、複数のレプリカに対して強力なデータ一貫性が実現します。注目すべき特徴は、Raft ノードが外部コンポーネントに依存しない分散型アーキテクチャであることです。代わりに、プロトコル クラスターとしてアプリケーションに埋め込まれ、つまり、アプリケーション自体と統合されます。

Kafka Topic の分散図を例にとると、Raft プロトコルのサンプル図は次のようになります。

この記事では Raft プロトコルについて詳しく説明するつもりはありませんが、リーダー選出のための別の実行可能なソリューションを提供し、サードパーティのコンポーネントに依存する必要がありません。では、なぜダメなのでしょうか?そのため、Kafka はバージョン 2.8 で最終的に Zookeeper を放棄し、Raft を採用しました。