Apache ZookeeperのApache Curatorライブラリ機能の概要

義務の問題として、分散アプリケーションの設計と開発に対処する必要があります。 そのようなアプリケーションは、多くの場合、プロセス間の通信のさまざまな手段を使用して、コンポーネントの相互作用を編成します。 分散方式で関連データを処理するアルゴリズムを実装するプロセスでは、特定の困難が発生します。 このようなタスクをサポートするために、専用の分散調整システムが使用されます。 最も人気があり、広く使用されている製品はApache Zookeeperです。

Zookeeperは複雑な製品です。 かなりの年齢にもかかわらず、定期的に特定のエラーが見つかりました。 ただし、これはその機能の結果に過ぎず、分散システムの多くの開発者の生活を楽にします。 次に、その機能をよりよく理解するのに役立つZookeeperのいくつかの機能を見てから、Apache Curator（Netflix）ライブラリに移ります。これにより、分散ソフトウェア開発者の生活が楽しくなり、分散調整オブジェクトを実装するための多くの既製のレシピが提供されます。

Apache zookeeper

前述したように、Zookeeperは分散システムの重要なコンポーネントです。 Zookeeperデータベースは、ファイルシステムに似たツリーの形で想像するのが最も簡単で、ツリーの各要素は（/ a / path / to / node）で識別され、任意のデータを格納します。 したがって、Zookeperの助けを借りて、階層型の分散データウェアハウスやその他の興味深い設計を整理することができます。 Zookeeperの有用性と広範な使用は、以下にリストするいくつかの重要なプロパティによって提供されます。

分散コンセンサス

コンセンサスはZABアルゴリズムを使用して達成されます。このアルゴリズムは、 CAP定理のC（一貫性）およびP（パーティション許容値）プロパティを提供します。これは、分離に対する整合性と耐性を意味し、アクセシビリティを犠牲にします。 実際には、これは次の影響をもたらします。

1. どのサーバーでこの状態を要求しても、すべてのクライアントは同じ状態を参照します。
2. 状態の変化は整然と発生し、「レース」は不可能です（セット操作の場合、get-set操作はアトミックではありません）。
3. Zookeeprクラスターは「バラバラ」になり、完全にアクセスできなくなる可能性がありますが、同時にすべてのユーザーがアクセスできなくなります。

コンセンサスは、分散システムが現在の状態に何らかの形で同意する能力です。 ZookeeperはZABアルゴリズムを使用しますが、他のアルゴリズムもよく使用されます-Raft 、

いかだ 。

一時ノード

Zookeeperクラスターとの接続を確立するクライアントは、セッションを作成します。 セッションのフレームワーク内で、他のクライアントに表示されるが、その有効期間がセッションの有効期間と等しいノードを作成することができます。 セッションの終了時に、これらのノードは削除されます。 このようなノードには制限があります-ターミナルのみであり、子孫を持つことはできません。つまり、一時的なサブツリーを持つことはできません。 一時ノードは、多くの場合に使用されます

サービス発見システムの実装。

負荷分散が実行される複数のサービスインスタンスがあるとします。 インスタンスのいずれかが表示されると、そのノードの一時的なノードが作成され、そのノードにサービスのアドレスが配置されます。サービス障害が発生すると、このノードは削除され、バランシングに使用できなくなります。 一時ノードは非常に頻繁に使用されます。

ノードイベントのサブスクライブ

クライアントは、ノードイベントをサブスクライブ（監視）し、これらのノードに関連するイベントが発生したときに更新を受信できます。 ただし、ここでも制限があります。ノードでイベントが発生した後、サブスクリプションはキャンセルされ、再度復元する必要がありますが、明らかに、このノードで発生する他のイベントをスキップする可能性があります。 この事実に関連して、この機能を使用する可能性は非常に限られています。

たとえば、検出サービスのフレームワーク内では、構成の変更に対応するために使用できますが、サブスクリプションをインストールした後、状態の変更がスキップされないことを確認するために「手動」操作を実行する必要があることに注意する必要があります。

シリアルノード

Zookeeperを使用すると、名前が一時的に増加する可能性がある一方で、連続して増加する番号を追加することで名前が形成されるノードを作成できます。 この機能は、適用された問題（たとえば、同じタイプのすべてのサービス、短命ノードとして登録する）の解決と、 公平な分散ブロッキングなどのZookeeperの「レシピ」の実装の両方で広く使用されています。

ノードのバージョン

ノードのバージョンを使用すると、読み取りと書き込みの間にノードの変更があったかどうかを判断できます。つまり、設定操作中にノードの予想されるバージョンを指定できます。一致しない場合は、ノードの変更が別のクライアントによって行われ、状態を再度読み取る必要があることを意味します。 このメカニズムを使用すると、たとえば「レシピ」 分散カウンタを実装する場合など、データの状態に順序付けられた変更を実装できます。

ノードごとのACL

信頼できないアプリケーションからデータを保護するために設計された、ノードのACLによって定義されたアクセス制限を設定することができます。 もちろん、ACLは悪意のあるクライアントが作成できる過負荷から保護せず、コンテンツへのアクセスを制限するメカニズムのみを提供します。

ノードごとのTTL

Zookeeperでは、TTLノードをインストールできます。その後、（更新がない場合）ノードが削除されます。 この機能は比較的最近登場しました。

オブザーバーサーバー

サーバーのクラスターにオブザーバーモードで接続する可能性があります（オブザーバー）。これは、読み取り操作の実行に使用できます。これは、書き込み操作によって生成されるクラスターの負荷が高い場合に非常に便利です。 オブザーバーサーバーを使用すると、問題を解決できます。 疑問が生じるかもしれませんが、なぜ通常のノードをクラスターに追加するだけではありませんか？ 答えはコンセンサスアルゴリズムにあります。データを書き込むことができるノードが多いほど、コンセンサスに達するまでに時間がかかり、クラスターの書き込みパフォーマンスが低下します。 オブザーバーサーバーはコンセンサスに参加していないため、書き込み操作のパフォーマンスには影響しません。

ノードの時刻同期

Zookeeperは、ノードの同期に外部時間を使用しません。 これはかなり有用なプロパティであり、正確な時間に焦点を当てたシステムは、その不一致に関連するエラーを起こしやすい傾向があります。

もちろん、軟膏にはタールが含まれている必要があります。実際には、Zookeeperには使用を制限できるプロパティがあります。 Zookeeper- Single Cluster of Failure ©Pinterestでの作業の複雑さを皮肉にも説明する表現もあります。これは、Zookeeperを使用した分散システムを使用して単一障害点を取り除こうとすると、まさに障害点。

ZookeeperデータベースはRAMに収まる必要があります

Zookeeperはベースをメモリにロードし、そこに保持します。 データベースがRAMに収まらない場合、スワップに配置され、パフォーマンスが大幅に低下します。 データベースが大きい場合は、十分な量のRAMを備えたサーバーが必要です（ただし、サーバー上の1 TBのRAMが制限からかけ離れている場合、現時点では問題になりません）。

セッションタイムアウト時間

クライアントの構成中にセッションタイムアウト時間が誤って選択されると、クラスターの負荷が増加し、一部のクラスターノードで障害が発生した場合に、予測不能な結果が悪化する可能性があります。 ユーザーはセッションの時間（デフォルトでは30秒）を短縮してシステムの収束性を高めようとします。これは、一時ノードがより速く削除されるためです。

クラスター内のノードの数による生産性の低下

通常、クラスターはコンセンサスの達成に関与する3つのノードを使用しますが、ノードを追加したい場合、書き込み操作のパフォーマンスが大幅に低下します。 ノードの数はそれぞれ奇数である必要があり（ZABアルゴリズムの要件）、クラスターを5、7、9ノードに拡張するとパフォーマンスに悪影響を及ぼします。 問題が読み取り操作にある場合は、オブザーバーノードを使用します。

ノードごとの最大データサイズ

ノードあたりの最大データサイズは1MBに制限されています。 大量のデータを保存する必要がある場合、Zookeeperは保存しません。

子孫リスト内のノードの最大数

Zookepeerは、ノードが子孫を持つことができる量を課しませんが、サーバーがクライアントに送信できるデータパケットの最大サイズは4MB（jute.maxbuffer）です。 ノードにそのリストが1つのパッケージに収まらないほど多くの子孫がある場合、残念ながら、それらに関する情報を取得する方法はありません。 この制限は、キャッシュがファイルシステムに構築され、オブジェクト名またはダイジェストが部分に分割され、階層構造に編成されるのと同じ方法で階層「擬似フラット」リストを編成することによってバイパスされます。

欠点にもかかわらず、それらの利点を上回るため、Zookeeperは、Cloudera CDH5、DC / OS、Apache Kafkaなどの多くの分散エコシステムの不可欠なコンポーネントになります。

開発者向けのZookeeper

ZookeeperはJava言語を使用して実装されているため、JVM環境での使用は自然なものです。たとえば、Javaからサーバーまたはサーバークラスターを起動し、サードパーティサーバーを展開することなくアプリケーションの統合またはスモークテストを実装するのは非常に簡単です。 ただし、ZookeeperクライアントAPIは非常に低レベルであり、操作を実行できますが、川に逆らって泳ぐことに似ています。 さらに、例外処理を適切に実装するには、Zookeeperの基本を深く理解する必要があります。 たとえば、Zookeeperでの作業に基本的なインターフェイスを使用した場合、分散調整および検出コードのエラーのデバッグと検索は非常に大きな問題を引き起こし、かなりの時間を必要としました。

ただし、Netflix開発者のJordan Zimmermanによってソリューションが存在し、コミュニティに寄付されています。 Apache Curatorに会ってください。

Apacheキュレーター

プロジェクトのメインページには引用があります。

この声明はキュレーターを100％反映しています。 このライブラリの使用を開始すると、Zookeeperを操作するためのコードがシンプルで理解しやすくなり、エラーの数とそれらを解決する時間が要因によって減少することがわかりました。 前述のように、標準クライアントが潮に逆らって泳ぐことに似ている場合、キュレーターによって状況は180度変化します。 さらに、キュレーターのフレームワーク内で、多数の既製のレシピが実装されています。これについてはさらに検討します。

ベースAPI

APIは、非常に便利な流体インターフェースの形で作成されており、必要なアクションを簡単かつ簡潔に決定できます。 例（以下、Scala言語で例を示します）：

client .create() .orSetData() .forPath("/object/path", byteArray)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これは、 「ノードを作成するか、存在する場合は、パスのデータを設定するだけ」/オブジェクト/パス「およびそれにbyteArrayを書き込む」と翻訳できます。

または、例えば：

 client .create() .withMode(CreateMode.EPHEMERAL_SEQUENTIAL) .forPath("/head/child", byteArray)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

「パスにシリアルタイプとエフェメラルタイプのノードを作成する」/ head / child000000XXXX「それにbyteArrayを書き込む」 このマニュアルページには、さらにいくつかの例があります 。

非同期操作

キュレーターは、同期操作と非同期操作の両方をサポートしています。 非同期使用の場合、クライアントは、同期CuratorFramework



とは異なり、タイプAsyncCuratorFramework



CuratorFramework



。 そして、各呼び出しチェーンはthenAccept



メソッドを受け入れます。これは、操作が完了すると呼び出されるCallbackを示します。 非同期インターフェイスの詳細については、専用のマニュアルページを参照してください 。

 val async = AsyncCuratorFramework.wrap(client); async.checkExists().forPath(somePath).thenAccept(stat -> mySuccessOperation(stat))
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

Scalaを使用する場合、非同期インターフェイスを使用することは正当化されていないように思われます。機能はScala Futureを使用して簡単に実装できるため、コードはscala-way開発の機能を保持できます。 ただし、Javaおよび他のJVM言語の場合、このインターフェースは便利です。

データスキーマのサポート

Zookeeperは、保存されたデータのセマンティクスをサポートしていません。 これは、データが保存される形式とその配置方法について、開発者が単独で責任を負うことを意味します。 これは、たとえば新しい開発者がプロ​​ジェクトに来たときなど、多くの場合に不便になる可能性があります。 これらの問題を解決するために、キュレーターは、これらのパス内のパスとノードタイプに制限を設定できるデータスキームをサポートしています。 構成から作成された回路は、Json形式で表すことができます。

 [ { "name": "test", "path": "/a/b/c", "ephemeral": "must", "sequential": "cannot", "metadata": { "origin": "outside", "type": "large" } } ]
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

移行サポート

キュレーターの移行は、ZookeeperのLiquibaseに似ています。 彼らの助けを借りて、データベースの進化を製品の新しいバージョンに反映させることができます。 移行は、連続して実行される一連の操作で構成されます。 各操作は、Zookeeperデータベースに対するいくつかの変換によって表されます。 キュレーターは、Zookeeperを使用して移行のアプリケーションを個別に監視します。 この機能は、アプリケーションの新しいバージョンをデプロイするプロセスで使用できます。 移行については、対応するマニュアルページで詳しく説明しています 。

テストサーバーとテストクラスター

テストを簡素化するために、キュレーターを使用すると、アプリケーションにサーバーまたはZookeeperサーバーのクラスターを埋め込むことができます。 この問題は、Zookeeperを使用する場合のみ、Curatorを使用せずに非常に簡単に解決できますが、Curatorはより簡潔なインターフェースを提供します。 たとえば、キュ​​レーターのないZookeeperの場合：

 class ZookeeperTestServer(zookeperPort: Int, tmp: String) { val properties = new Properties() properties.setProperty("tickTime", "2000") properties.setProperty("initLimit", "10") properties.setProperty("syncLimit", "5") properties.setProperty("dataDir", s"$tmp") properties.setProperty("clientPort", s"$zookeperPort") val zooKeeperServer = new ZooKeeperServerMain val quorumConfiguration = new QuorumPeerConfig() quorumConfiguration.parseProperties(properties) val configuration = new ServerConfig() configuration.readFrom(quorumConfiguration) private val thread = new Thread() { override def run() = { zooKeeperServer.runFromConfig(configuration) } } def start = { thread.start() } def stop = { thread.interrupt() } } ... val s = new ZookeeperTestServer(port, tmp) s.start ... s.stop
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

キュレーターの場合：

 val s = new TestingServer(port) s.start() ... s.stop()
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

キュレーターのレシピ

キュレーターレシピは、このライブラリを使用して分散プロセス相互作用メカニズムを実装する主な動機です。 次に、キュレーターがサポートする主なレシピと、それらの適用方法をリストします。 私は実際にはいくつかのレシピを適用しなかったので、マニュアルに可能な限り近い翻訳が与えられました。

リーダーズチョイス

これらのレシピは、現在のリーダーがいて、いくつかのプロセスがホットリザーブ内にあるフォールトトレラントプロセス実行モデルを実装することを目的としています。 リーダーが機能を果たすのをやめるとすぐに、別のプロセスがリーダーになります。 2つの適切なレシピがあります。

1. Leader Latchは、CountDownLatchに類似しており、プロセスがリーダーになるまでロックされます。
2. Leader Election 。メソッド呼び出しを通じてリーダーの選択を実装します。 プロセスがリーダーになった瞬間にメソッドが呼び出され、そこからの出口はリーダーシップの喪失を示します。

ロック

ロックは、分散プロセス間同期の最も重要なメカニズムの1つです。 キュレーターは、幅広いロックオブジェクトを提供します。

1. 共有再入可能ロック -アクセスできるクライアントが再入力できる分散ロック。
2. 共有ロック -分散ロック。
3. 共有リエントラント読み取り/書き込みロック -読み取りと書き込みを別々にロックできるオブジェクト。複数のクライアントが同時に読み取り用にオブジェクトをロックできますが、書き込みロックは排他的です。
4. 共有セマフォ -カウントセマフォの助けを借りて、32ビット整数で指定された限られた量のリソースで簡単に作業できます。
5. マルチ共有ロックは、複数の分散ロックの操作をアトミックに実行できる高レベルのオブジェクトです。

障壁

1. バリア -特定の条件が満たされるまで、他の参加者のコードセクションへのアクセスをクライアントがブロックし、発生した場合にアクセスをロック解除できるオブジェクト。これにより、すべての参加者が実行を継続できます。
2. ダブルバリア -このオブジェクトを使用すると、特定の数のクライアントのエントリをコードセグメントに同期し、そこから終了することができます。

カウンター

1. 共有カウンター -レース保護付きの通常の整数カウンター（32ビット）。
2. 分散アトミックロング -カウンタータイプロング（64ビット）。

キャッシュ

1. パスキャッシュ -ノードを監視し、その子ノードについてローカルキャッシュを更新し、オプションでデータが変更されたときにデータについて更新するオブジェクト。
2. ノードキャッシュ - ノードを監視し、ノードとそのデータに関するローカルキャッシュを更新するオブジェクト。
3. ツリーキャッシュ -ノードの子孫のツリー全体を監視し、ツリー内で変更されるとローカルキャッシュを更新するオブジェクト。

結び目

1. 永続ノード -このレシピを使用すると、外部の影響下でもキュレーターがその存在と不変性を確保するために努力するデータを持つノードを作成できます。
2. 永続的TTLノード -存続期間がTTLによって決定されるノードを作成するためのレシピ。永続的ノードと同じプロパティをサポートします。
3. グループメンバー - メンバーのグループを編成できます。

キュー

Zookeeperは、集中分散キューを編成するのに最適な候補ではないことに注意してください。大量のメッセージを確実に通過させる必要がある場合は、Apache Kafka、RabbitMQなどの特別に設計されたソリューションを使用することをお勧めします。 ただし、キュレーターはキューをサポートするための一連のレシピを提供します。

1. 分散キュー -優先度の高い順にメッセージを入れたり取り出したりできる通常の分散キュー。
2. 分散IDキュー -各メッセージに識別子を格納し、識別子を使ってキューからメッセージをすぐに削除できるようにする分散キュー。
3. 分散優先度キュー -優先度キュー。
4. 分散遅延キュー -キューを使用すると、追加された各アイテムの時間をUnixtime形式で設定でき、キューからの読み取りが可能になります。
5. Simple Distributed Queueは、標準のZookeeper APIによって提供されるキューに類似しています。

おわりに

Apache Curatorライブラリーは確かに使用を検討する価値があり、エンジニアリング作業の優れた例であり、Apache Zookeeperとの対話を大幅に簡素化できます。 ライブラリの短所には、ドキュメントの量が少ないため、初心者の開発者にとって参入障壁が高くなります。 私の実践では、特定のレシピがどのように機能するかを理解するために、ライブラリのソースコードを繰り返し調査する必要がありました。 ただし、これにはプラスの効果もあります。実装を深く理解することで、仮定に基づいた論理エラーが少なくなります。

キュレーターの開発者は、ライブラリの使用を開始する前に、Zookeeperのドキュメントを学習することをお勧めします。 Zookeeperは効果的な使用のための製品であり、そのAPIを知っているだけでなく、その仕組みを理解する必要があるため、これは非常に合理的なアドバイスです。 これらのコストは確実に報われ、経験豊富なエンジニアがZookeeper機能を使用することで、信頼性が高く生産的な分散システムを作成できます。