管理者および開発者向けのZooKeeperの使用法は何ですか。 ヤンデックスワークショップ

こんにちは 私の名前はアンドレイ・ステパパチェフです。 昨年の終わりに、 ZooKeeperとは何か、どのように使用できるかについての短い話で同僚と話をしました。 このレポートはもともと幅広い読者向けに設計されたもので、すべての仕組みを理解したい開発者と管理者の両方に役立ちます。

ZooKeeperの登場の歴史から始めましょう。 最初は、ご存じのとおり、Googleはサーバーとその構成を管理するためのChubbyサービスを作成しました。 同時に、彼らは分散ロックの問題を解決しました。 しかし、チャビーには1つの機能がありました。ロックをキャプチャするには、オブジェクトを開いてから閉じなければなりません。 これによりパフォーマンスが低下しました。 Yahooは、クラスター構成用のさまざまなシステムを構築できるツールが必要だと感じました。 これがまさにZooKeeperの主な目標です。特定のシステムのストレージと構成管理、および副産物としてロックが判明しました。 結果として、このシステム全体は、クライアントコードによってさまざまなプリミティブ同期を構築するために作成されました。 ZooKeeper自体には、そのようなキューに関する明確な概念はありません;これらはすべてクライアントライブラリ側で実装されます。

Zookeeperで使用されるプロトコルはZABと呼ばれ、プロトコルの説明へのリンクは記事の最後に記載されています。

ZooKeeperの基礎は、ファイルとディレクトリの概念を組み合わせた相互接続ノードで構成される仮想ファイルシステムです。 このツリーの各ノードは、同時にデータを保存し、下位ノードを持つことができます。 これに加えて、システムには2つのタイプのノードがあります。ディスクに保存されて消えることのない、いわゆる永続ノードと、特定のセッションに属し、存在する限り存在する一時ノードがあります。

写真では、文字Pは顧客を示しています。 それらはセッションを確立します-ZooKeeperサーバーとのアクティブな接続、その中でハートビートパケットが交換されます。 タイムアウトの3分の1以内にハートビートが聞こえなかった場合、タイムアウトの3分の2が経過した後、サーバー上のセッションが消えるまでクライアントライブラリは別のZooKeeperサーバーに参加します。 セッションが消えると、一時ノード（図で青でマーク）が消えます。 それらは通常、どのセッションがそれらを所有しているかを示す属性を持っています。 そのようなノードは子を持つことはできません。これは厳密にデータを保存できるオブジェクトですが、依存するデータを作成することはできません。

ZooKeeperの開発者は、すべてをファイルシステムの形式にすることが非常に便利だと感じました。

ZooKeeperの2番目の基本的なことは、いわゆる同期記録の実装とFIFOメッセージ処理です。 その考えは、ZooKeeperのコマンドのシーケンス全体が厳密に順序付けられているということです。 このシステムは、全体の順序付けをサポートしています。

ZooKeeperのすべての操作は、このべき等操作に変わります。 ノードを変更する場合は、変更されたノードのバージョンを記憶しながら、変更したレコードを作成します。 このため、同じメッセージを何度も受信することがありますが、どのメッセージを適用できるかを正確に知ることができます。 したがって、書き込み操作は、1つのスレッド、1つのサーバー（マスター）で厳密に順番に実行されます。 いくつかの車から選ばれたリーダーがいて、彼だけがレコーディングのすべての操作を実行します。 レプリカから読み取りが行われる場合があります。 この場合、クライアントは厳密な一連の操作を実行します。 つまり 彼が書き込みおよび読み取り操作を送信した場合、記録が最初に実行されます。 読み取り操作はブロックせずに実行できますが、読み取り操作は前の書き込み操作が完了した後にのみ実行されます。 このため、ZooKeeperで予測可能な非同期システムを実装できます。 システム自体は、主に非同期操作を指向しています。 クライアントライブラリが同期インターフェイスを実装しているという事実は、プログラマの利便性のためです。 実際、ZooKeeperは通常、非同期操作中に正確に高いパフォーマンスを提供します。

これはどのように機能しますか？ 1人のリーダーと複数のフォロワーがいます。 変更は2フェーズコミットを使用して適用されます。 ZooKeeperが重点を置いている主なものは、TCPと完全な順序付けで動作することです。 一般に、ZABプロトコル（ZooKeeper Atomic Broadcast）はPaxosの簡易バージョンであり、ご存知のとおり、メッセージの並べ替えを行っており、これを処理できます。 ZABはこれに対処する方法を知らず、最初は完全に順序付けられたイベントストリームに焦点を合わせています。 並列処理はありませんが、システムは書き込みよりも読み取りに重点を置いているため、多くの場合、必要ありません。

たとえば、そのようなクラスターがあり、クライアントが存在します。 クライアントが今読んでいる場合、フォロワーが現在見ている値が表示され、特定のフィールドの値が1になったと考えます。クライアントに2を書き込むと、フォロワーはリーダーを介して操作を実行し、結果として新しい状態を取得します。

リーダーが成功したと見なされるには、3台のマシンのうち少なくとも2台がこのデータを安全に保存したことを確認する必要があります。 フォロワーがいることを想像してください。このフォロワーは、たとえばアムステルダムや別のリモートDCで1からです。 彼は他のフォロワーに遅れをとっています。 したがって、ローカルマシンにはすでに2が表示され、フォロワーがマスターに追いつくまでにクライアントが読み取りを行うと、そのリモートフォロワーは遅れている値を確認します。 彼が正しい値を読み取るには、特別なコマンドを送信して、ZooKeeperがマスターとの同期を強制されるようにする必要があります。 つまり 少なくともsyncコマンドが実行された時点で、マスターに関して非常に新しい状態を受信したことが確実にわかります。 これはスローリードと呼ばれます。 通常、非常に高速に読み取りますが、全員が低速読み取りを使用する場合、クラスター全体が常にマスターから読み取られることは明らかです。 したがって、スケーリングは行われません。 すばやく読み、自分が遅れるのを許せば、読書のためにかなりうまくスケーリングできます。

レシピ

構成管理

最初の最も基本的なアプリケーションは構成管理です。 Zookeperの設定、たとえばデータベースへの接続のURL、またはクラスター内でのサービスの動作を禁止または許可するフラグなどを書き留めます。 したがって、クラスタメンバーは構成セクションをサブスクライブし、その変更を追跡します。

彼らが変更を記録した場合、彼らはそれを読み、何らかの形でそれに反応することができます。 いわゆる 一時ノードを監視できます。たとえば、マシンがまだ生きている場合です。 または、アクティブなマシンのリストを取得します。 ワーカーのセットがあれば、それぞれを登録できます。 そしてzukipperには、実際に接続されているすべてのマシンが表示されます。 最新の変更のタイムスタンプまたはセッションのリストにより、車がどれだけ遅れているかを予測することもできます。 マシンがタイムアウトに近づき始めたことがわかったら、何らかのアクションを実行できます。

ランデブー

別のオプションは、いわゆるランデブーです。 アイデアは、労働者と彼らに仕事を与えるディーラーのための方法があるということです。

私たちは何人の労働者がいるのかを事前に知りません、彼らは接続と切断ができます、我々はこのプロセスを制御しません。 これを行うには、workersディレクトリを作成できます。 そして、新しいワーカーがいるとき、彼は、ワーカーがまだ生きていることを報告する一時的なノードと、例えば、彼のタスクが行く彼自身のディレクトリを登録します。 リーダーは、workersディレクトリを追跡します。 ある時点で労働者の一人が脱落した場合、彼は気づくでしょう。 これを発見すると、たとえば、タスクをキューから別のワーカーに転送できます。 したがって、ZooKeeperにシンプルなジョブ処理システムを構築できます。

ロック

1人のクライアントが来たとしましょう。 はかないノードを作成します。 ここでは、通常のZooKeeperに加えて、シーケンシャルノードがあるように予約する必要があります。 最後に、原子的に成長するシーケンスが原因である可能性があります。

到着した2番目のクライアントは、別の一時ノードを作成し、子のリストを受け取り、それらをソートして、自分が最初であるかどうかを確認します。 彼は自分が最初ではないことを確認し、最初にイベントハンドラーをハングさせ、消えるまで待ちます。

my-lockディレクトリ自体にハングアップして、すべてが消えるのを待つ必要はありませんか？ 何かをブロックしようとしているマシンが多数ある場合、ロック– 0001が消えると通知ストームが発生するためです。 ウィザードは、特定の1つのロックに関する通知の送信で忙しくなります。 したがって、これらを次のようにリンクすることをお勧めします。次のように、前のノードのみをたどります。 彼らは並んでいます。

最初のクライアントがロックを解除し、このレコードを削除すると、2番目のクライアントはこれを確認し、現在はロックの所有者であると信じます。 誰も先ではありません。 シーケンスが原因で、彼の前の誰も登ることが保証されません。 したがって、最初のクライアントが再び来た場合、チェーンの最後にノードを作成します。

性能

以下のグラフでは、x軸は読み値と読み値の比率を表しています。 書き込み操作の数がパーセンテージで増加すると、パフォーマンスが大幅に低下することがわかります。

これらは非同期操作の結果です。 つまり オペレーションは100で送信されます。一度に1つずつ送信された場合、y軸の数値を100で除算する必要があります。読むことでより良く成長できます。 ZooKeeperでは、データストレージを保証する、たとえば5台のマシンのクォーラムを構築する機能に加えて、リピーターとして機能する非投票マシンを作成することもできます。これらは、単にイベントを読み取りますが、記録には参加しません。 これにより、録音で利点が得られます。

サーバー	100％読み取り	0％読み取り
13	460k	8k
9	296k	12k
7	257k	14k
5	165k	18k
3	87k	21k

上記の表は、サーバーの追加が読み取りおよび書き込みに与える影響を示しています。 読み取り速度は量とともに増加していることがわかります。書き込みのクォーラムを増やすと、パフォーマンスが低下します。

以下の図では、ZooKeeperがさまざまな障害にどのように反応するかを確認できます。 最初のケースは、レプリカのドロップです。 2番目は、接続されていないレプリカのドロップです。

zukiperのリーダーのfall落は条件付きで重大です。 良好なネットワークがあれば、ZooKeeperは約200ミリ秒で復元できます。 リーダーが数分間選択されることもあります。 この時点で、ロックをキャプチャしようとすると、アクティブなリーダーなしで書き込みを試みても何も行われず、ロックが表示されるのを待たなければなりません。

遅延

サーバー / 労働者	3	5	7	9
1	776	748	758	711
10	1831	1831	1572	1540
20	2470	2336	1934	1890

上記の表の時間はナノ秒です。 したがって、読み取り速度の観点から、ZooKeeperはインメモリデータベースに近づいています。 実際、これは常にメモリから読み取るキャッシュです。 一般的に、ZooKeeperは常にメモリ内にデータベースを持っています。 記録は次のように行われます。ZooKeeperはイベントログを書き込み、ティック設定に従ってディスクにリセットされ、定期的にシステムがデータベース全体のスナップショットを作成します。 したがって、データベースが大きすぎるか、ディスクがあまりにもロードされている場合、遅延をタイムアウトと比較できます。 このテストは、特定の構成の作成をシミュレートします。1キロバイトのデータがあり、最初に1つの同期作成があり、次に非同期削除があり、これはすべて50,000回繰り返されます。

参照：

ZABプロトコル-元の文書

ZABの分析とZKでの実装（元の言語よりも少し人間の言語が多い）