|
ZKの紹介
ZooKeeper (ZK) は、マイクロサービスソリューションにおけるサービス登録と検出の中核環境であり、マイクロサービスの礎石として機能します。しかし、サービス登録と検出機能を提供する製品は ZK だけではありません。業界で広く認知されている製品としては、Eureka や Consul などがあります。
ここではZKについてのみ説明します。このツール自体は非常に小さく、zipファイルもわずか数メガバイトです。インストールも簡単で、クラスタ展開にも対応しています。 背景 このセクションでは、クラスター環境におけるZooKeeper（ZK）のリーダーとフォロワーの概念、ノード障害発生時にZKが直面する問題、そしてそれらの解決方法について説明します。ZK自体はJavaで開発され、GitHubでオープンソースとして公開されていますが、公式ドキュメントでは内部構造に関する情報がほとんど提供されていません。多くのブログ記事が散在しており、その中には非常によく書かれたものもあります。 質問：
ZKクラスターでは、各ノードは単一の状態を持ちます（各ノードは1つの状態のみを持ちます）。ZKのポジショニングでは、リーダーノードがロード状態である必要があります。
ZK投票処理戦略 投票情報には、選出されたリーダーの Serverid、Zxid、および SelectionEpoch が含まれます。
多数決アルゴリズム ZooKeeperには、LeaderElection、FastLeaderElection、AuthLeaderElectionという3つの選出アルゴリズムがあります。FastLeaderElectionとAuthLeaderElectionは似たような選出アルゴリズムですが、AuthLeaderElectionには認証情報が組み込まれている点が異なります。FastLeaderElectionはLeaderElectionよりも効率的であり、以降のバージョンではFastLeaderElectionのみが採用されています。 理解する： クラスタ環境で複数のノードが起動すると、ZooKeeper (ZK) はまずこれらのノードの中からリーダーノードを選出し、Leading 状態にする必要があります。ここで、選出問題と選出ルールについて疑問が生じます。「多数決選出アルゴリズム」は、過半数の票を獲得したノードが勝利し、その状態が Looking から Leading に変化するという仕組みで、より効率的です。 このアプローチは、次の 5 つのサーバーを使用して説明されます。 サーバー1が起動しますが、この時点では稼働しているサーバーは1台のみです。そのサーバーへの投票は応答がないため、選出状態は「LOOKING」のままです。 サーバー2が起動し、最初に起動したサーバー1と通信して選挙結果を交換します。どちらのサーバーにも履歴データがないため、ID値が大きいサーバー2が勝利します。ただし、サーバー2は過半数以上の投票を獲得していないため（この例では3票）、サーバー1とサーバー2は引き続きLOOKING状態のままです。 サーバー3が起動します。前述の理論に基づくと、分析の結果、3つのサーバーがサーバー3を選出したことがわかります。サーバー3はサーバー1、2、3の中でリーダーとなり、今回の選出でもリーダーとなりました。 サーバー4が起動します。前回の分析に基づくと、理論上はサーバー1、2、3、4の中でサーバー4が最大となるはずです。しかし、既に半数以上のサーバーがサーバー3を選択しているため、サーバー4は従属的な存在となる運命を受け入れるしかありません。 サーバー 5 は、サーバー 4 と同様に起動し、従属サーバーとして機能します。 5 台のマシンのうち 2 台 (3 と 4) が故障し、リーダー マシンも故障したとします。 リーダーとフォロワーの間ではハートビートチェックが行われ、データの同期が必要です。リーダーノードに障害が発生した場合、ZooKeeper クラスター全体のサービスが停止し、新たなリーダー選出ラウンドが開始されます。 1) サーバー1、2、5はリーダーとの接続が失われたことを検知し、ステータスが「looking（監視中）」に変わり、新たな投票を開始します。 2) サーバー1、2、5はそれぞれ投票を開始し、投票情報をブロードキャストし、自身のエポックをインクリメントします。 3) サーバー1、2、5は投票を処理し、リーダーを決定し、結果をブロードキャストします。 4) 投票ロジックに基づいて、1つのサーバーが選出されます（2票で過半数）。 5) 各サーバーはリーダー/フォロワー状態に戻ります。 6) サービスが再開されます。 スプリットブレイン問題 スプリットブレイン問題は、クラスター内のリーダーがダウンし、フォロワーが新しいリーダーを選出し、元のリーダーが復活する際に発生します。ZooKeeperの多数決メカニズムは、一定数のマシンがダウンしても通常通りサービスを提供し続けることを許容するため、リーダーの削除決定に意見の相違が生じた場合、複数のリーダーが出現する可能性があります。 プラン： ZooKeeper の多数決メカニズムは、スプリットブレインの発生をある程度軽減し、少なくとも3つのリーダーが同時に存在するのを防ぎます。ZooKeeper のエポックメカニズム（クロック）は、選出ごとに1ずつ増加します。通信中は、エポックが同じかどうかを確認します。エポックが現在のエポックより小さい場合はリーダーが破棄され、大きい場合は現在のエポックがリセットされます。エポックが同じ場合は、選出が行われます。 誘導 日常的なZKメンテナンスでは、特にスプリットブレインなどの極端な状況下で上記のシナリオから発生する可能性のある問題に注意することが重要です。以下の対策を講じることができます。 多数決戦略における展開原則:
アルゴリズムの詳細なロジックは非常に複雑で、多くの状況を考慮する必要があります。その一つがEpoch（自己増分）の概念で、これはLogicEpochとElectionEpochに分かれています。各投票では、投票サイクルの整合性などをチェックします。 |
