分散システム調整カーネル - Zookeeper

[[402864]]

この記事はWeChatの公開アカウント「Mu Niao Za Ji」から転載したもので、著者はMu Niao Za Jiです。この記事を転載する場合は、Mu Niao Za Ji の公開アカウントにご連絡ください。

この記事では、Patrick Hunt らが発表した論文を紹介します。 2010 年に開発され、現在でも広く使用されており、分散システムの調整コンポーネントに重点を置いた ZooKeeper: インターネット規模のシステム向けの待機なしの調整。複数のスレッドまたは複数のプロセスでプログラミングする場合、同期と排他制御は避けられません。一般的な手段としては、共有メモリ、メッセージキュー、ロック、セマフォなどがあります。分散システムでは、異なるコンポーネント間で同様の調整方法が必然的に必要になるため、Zookeeper が誕生しました。 Zookeeper は、クライアントライブラリと組み合わせて、動的パラメータ構成 (構成メタデータ)、分散ロック、共有レジスタ、サービス検出、グループメンバーシップ、マルチノードリーダー選出などの一連の分散システム調整サービスを提供できます。

一般的に、Zookeeper には次のような特徴があります。

Zookeeper は、API をシンプルかつ効率的に保つために比較的まとまりのある機能を備えた分散調整カーネルです。
Zookeeper は、高性能、FIFO 保証、イベント駆動型、非ブロッキング API のセットを提供します。
Zookeeper は、ファイルシステムに似たディレクトリツリーを使用してデータを整理します。強力な表現力を備えており、クライアントがより複雑な調整ソース言語を簡単に構築できるようになります。
Zookeeper は、Zab アトミックブロードキャストプロトコルを使用して高可用性と一貫性を確保する、自己一貫性のあるフォールトトレラントシステムです。

この記事では、論文の順序に従って、Zookeeper のモジュールのサービスインターフェース設計と大まかな実装について簡単に紹介します。詳細については、論文およびオープンソースプロジェクトのホームページを参照してください。

サービスデザイン

サービスインターフェイスを設計するときは、まずサービスの構成と相互作用に関係する基本概念を抽象化し、次にこれらの基本概念を取り巻く一連のアクションを明確にする必要があります。 Zookeeper の場合、これらの基本概念は用語と呼ばれ、アクションのセットはサービスインターフェイス (API) と呼ばれます。

用語集

クライアント: クライアント、Zookeeper サービスを使用するユーザー。
サーバー: サーバー、Zookeeper サービスを提供するプロセス。
データツリー: データツリー。Zookeeper 内のすべてのデータはツリー構造で編成されます。
z-node: znode、Zookeeper ノード、データツリー内のノードは、基本的なデータユニットです。
セッション: セッションでは、クライアントとサーバーは接続を識別するために新しいセッションを作成し、クライアントからの後続の各要求はセッションハンドルを通じて行われます。 Watch イベントのライフサイクルもセッションにバインドされます。

以下のテキストでは、対応する用語の中国語版と英語版が同じ意味で使用されている場合があります。

データの構成

Zookeeper は、保存されたデータをファイルシステムに似たツリー状の階層に整理し、ユーザーに高い柔軟性を提供します。たとえば、同じ親ノードのすべての子を使用してメンバーシップを表すなど、名前空間を自然に表現することが可能です。パスは一意のデータノードを見つけられるため、基本データユニットを一意に識別できます。

Zookeeper 階層型名前空間構成

ツリーでは 2 種類の znode がサポートされています。

通常ノード: 通常、ライフサイクルは無限です。クライアントは、このタイプのノードを明示的に追加または削除するためにインターフェイスを呼び出す必要があります。
一時ノード: ライフサイクルがセッションにバインドされた一時的なノードです。セッションが破棄されると、ノードは削除されます。

さらに、Zookeeper では、クライアントが znode を作成するときにシーケンシャルフラグを添付できます。 Zookeeper は、ノード名の接尾辞としてグローバル増分カウントを自動的に追加します。

Zookeeper は、プッシュツーサブスクライブアプローチを使用してサブスクリプションメカニズムを実装します。つまり、ユーザーがノードをサブスクライブ (監視) した後、ノードが変更されると、クライアントは通知 (エッジトリガー) を受信します。サブスクリプションはセッションにバインドされているため、セッションが破棄されると、サブスクライブされたイベントも消えます。

セッションメカニズム（セッション）。ご覧のとおり、Zookeeper はセッションメカニズムを使用してクライアント接続のライフサイクルを管理します。実装されると、セッションはタイムアウト間隔に関連付けられます。クライアントが停止したり、Zookeeper から切断されたりして、タイムアウト期間内にクライアントがハートビートを実行しない場合、Zookeeper はサーバー側でセッションを破棄します。

データモデル。 Zookeeper は基本的にツリー構造の KV モデルを提供します。 Zookeeper は、キー値データを保存するだけでなく、空間構造とライフサイクル管理を表現機能として通じて調整セマンティクスを提供します。もちろん、Zookeeper では、クライアントがノードにメタデータや構成情報を添付したり、バージョンやタイムスタンプのサポートを提供したりすることで、より強力な表現機能も提供します。

APIの詳細

以下は、Zookeeper がクライアントに提供する API の詳細とコメントをリストした疑似コードです。すべての操作オブジェクトは、パスに対応するデータノード (znode) です。

 // パス path に znode を作成し、データ data を保存します
// 通常、一時、順次などのフラグを設定します。
 // 戻り値: znode 名
作成(パス、データ、フラグ) 
 
 // パスのznodeが期待されるバージョンと同じ場合、
 // 次に znode を削除します。
 // バージョンの指定は、通常、同時実行の安全性のためです。
削除(パス、バージョン) 
 
 // watch はクライアントがこのパスにリスナーを追加できるようにします
// 戻り値: パスに対応する znode。存在する場合はtrueを返します。  
 // 存在しない場合はfalseを返す 
存在する(パス、ウォッチ) 
 
 // パス path に対応する znode のデータとメタ情報を取得します
// znodeが存在する場合、監視するためのウォッチを設定できます
// znode データの変更
getData(パス、ウォッチ) 
 
 // バージョンが一致したら、データをデータに書き込む
// パスに対応するznode
 setData(パス、データ、バージョン) 
 
 // パス path に対応する znode のすべての子を取得します
getChildren(パス、ウォッチ) 
 
 // 通常は getData の前に置かれる最新のデータを同期します
同期(パス)

上記の API には次の機能があります。

非同期サポート。すべてのインターフェースには同期バージョンと非同期バージョンがあります。非同期バージョンはコールバック関数として実行されます。クライアントは、ビジネスニーズに基づいて、重要な更新を取得するためにブロックして待機するか、非同期呼び出しを行ってパフォーマンスを向上させるかを選択できます。

ハンドルではなくパス。インターフェイス設計を簡素化し、サーバーによって維持される状態を削減するために、Zookeeper は znode ハンドルではなくパスを使用して znode の操作インターフェイスを提供します。結局のところ、ハンドルはセッションに似ており、ステートフルであり、分散システムの実装の複雑さを増します。パスを使用し、それをバージョン情報と組み合わせることで、複数のクライアントを同時に処理する場合に実装が容易になるべき等インターフェースを作成できます。

バージョン情報。すべての更新操作 (設定/削除) では、対応するデータのバージョン番号を指定する必要があります。バージョン番号が一致しない場合は、更新が終了し、例外が返されます。ただし、特別なバージョン番号 -1 を指定することで、バージョン番号のチェックをスキップできます。

セマンティック保証

複数のクライアントから Zookeeper への同時リクエストを処理する場合、API には 2 つの基本的な順序保証があります。

線形化可能な書き込み。すべての Zookeeper 状態更新要求はシリアル化されます。

クライアント内の FIFO クライアント順序。特定のクライアントに対するリクエストは、送信された順序で実行されます。

しかし、ここでの線形化は非同期線形化、つまり A-線形化可能性です。つまり、単一のクライアントで複数の未処理の操作を同時に実行できますが、これらの要求は発行された順序で実行されます。読み取り要求の場合、マスターを経由せずに各サーバー上でローカルに実行できます。したがって、サーバー (オブザーバー) を追加することで、読み取り要求のスループットを向上させることができます。

さらに、Zookeeper は可用性と耐久性の保証も提供します。

可用性 (生存性): Zookeeper クラスター内のノードの半分以上が利用可能な場合、システムは外部に正常にサービスを提供できます。

耐久性: クライアントに正常に返された変更要求はすべて、Zookeeper ステートマシンに適用されます。ノード障害や再起動が継続的に発生した場合でも、Zookeeper が正常にサービスを提供できる限り、この機能は影響を受けません。

動物園の建築

高い信頼性を提供するために、Zookeeper は複数のサーバーを使用して冗長的にデータにアクセスします。すべての更新要求は、Zab コンセンサスプロトコルを使用して処理され、WAL に書き込まれ、ローカルメモリステートマシン (データツリー) に適用されます。

Zab プロトコルでは、すべてのノードがリーダーとフォロワーの 2 つの役割に分かれています。リーダーは 1 人のみで、残りはフォロワーです。しかし、実際には、オブザーバーが存在する可能性があります。

Zookeeper のコンポーネントとリクエストフロー

上図に示すように、サーバーはリクエストを受信すると、まず前処理（リクエストプロセッサ）を実行します。書き込み要求の場合は、Zab プロトコル (Atomic Broadcast) を通じて合意に達し、それをローカルデータベース (Replicated Database) に送信します。読み取り要求の場合、ローカルデータベースのステータスが直接読み取られて返されます。

リクエストプロセッサ

すべての更新リクエストは、べき等トランザクション (txn) に変換されます。具体的な方法は、現在の状態を取得し、ターゲットの状態を計算し、それをトランザクションにカプセル化することです。次に、CAS のような方法を使用して同時リクエストを処理できます。したがって、すべてのトランザクションが固定された順序で実行される限り、異なるサーバー上のデータコピーの分割を回避できます。

アトミックブロードキャスト

すべての更新リクエストは Zookeeper リーダーに転送されます。リーダーはまずトランザクションをローカル WAL に追加し、次に Zab プロトコルを使用して各ノードに変更をブロードキャストします。成功した応答の半分以上を受信すると、リーダーは変更をローカルのインメモリデータベースにコミットし、コミットをフォロワーにブロードキャストします。

Zab は多数決原理を採用しているため、2k+1 ノードのクラスターは最大 k ノードの障害を許容できます。

システムのスループットを向上させるために、Zookeeper はパイプラインアプローチを使用して複数のリクエストの処理を最適化します。

複製されたデータベース

各サーバーは、Zookeeper 内のすべての状態のレプリカをローカルメモリに保持します。ダウンタイムと再起動に対処するために、ZooKeeper は定期的に状態のスナップショットを取得します。通常のスナップショットとは異なり、Zookeeper はスナップショットをファジースナップショットと呼びます。つまり、スナップショットを作成するときにロックせず、DFS を介してファイルツリーをトラバースしてスナップショットをローカルコンピューターにダンプします。異常なダウンタイムによりシステムが再起動された場合は、最新のスナップショットを追加し、最新のスナップショットの後に WAL を再実行するだけで済みます。 WAL に記録されたトランザクションの冪等性により、スナップショットと WAL の時点が完全に一致していなくても、レプリカ間の一貫性には影響しません。

クライアントとサーバーの相互作用

シリアル書き込み。すべての更新操作は、サーバー上でグローバルまたはローカルにシリアル化されます。パスデータの更新を実行すると、サーバーは、接続されているすべてのクライアントによってサブスクライブされている Watch イベントをトリガーします。これらのイベントはセッションに関連付けられているため、サーバー上でローカルにのみ保存されることに注意してください。クライアントがサーバーから切断されると、セッションは破棄され、これらのイベントも消えます。

ローカルで読み取ります。最高のパフォーマンスを実現するために、Zookeeper のサーバーは読み取り要求をローカルで直接処理します。ただし、これにより、クライアントが古いデータを取得する可能性があります (たとえば、他のクライアントが別のサーバー上の同じパスを更新する場合)。そのため、Zookeeper は、Sync を呼び出した時点で送信された最新のデータをクライアントに接続されたサーバーに同期し、最新のデータをクライアントに返す Sync 操作を設計しました。つまり、Zookeeper は、Sync を呼び出すかどうかを決定することで、ユーザーにパフォーマンスと適時性の選択肢を提供します。

一貫した見解。 Zookeeper は、トランザクション自動増分識別子 zxid をグローバルに管理します。これは本質的に、Zookeeper のデータビューをその時点で識別できる論理クロックです。障害による再起動後にクライアントが新しいサーバーに再接続する場合、サーバーがクライアントに保存されている zxid を実行していない場合、サーバーは zxid を実行してからクライアントに応答するか、クライアントは新しいサーバーに接続します。これにより、クライアントにはロールバックされたビューが表示されなくなります。

セッションの有効期限が切れました。セッションは基本的に、Zookeeper 内のクライアントからサーバーへの接続を識別します。セッションにはタイムアウト期間があります。クライアントが長時間（タイムアウト間隔より長い時間）リクエストまたはハートビートを送信しない場合、サーバーはセッションを削除します。

まとめ

Zookeeper は、ディレクトリツリーを使用してデータを整理し、Zab プロトコルを使用してデータを同期し、非ブロッキングメソッドを使用してインターフェイスを提供することで、強力な表現力を備えた分散調整カーネルを構築します。分散システムのコントロールプレーンで調整、スケジュール、制御に使用できます。近年では、Raft をベースにした Etcd も同様の立場に立っています。

<<: 並列および分散コンピューティングの原理

>>: JVM に固執する | Arthas を使用して JVM メモリをチェックするのは素晴らしいことです。