分析のズーキーパーは具体的に何をするのでしょうか?

クズども · 掲載地 2017/07/18 14:19:01

ZookeeperはHadoopのサブプロジェクトで、hadoopから派生していますが、ZookeeperはHadoop以外の分散フレームワークをますます使う傾向にあります。今日はZookeeperについて話したいと思います。この記事ではZookeeperの使い方については触れませんが、Zookeeperの実用的な応用、ZooKeeperの利点を活かせるアプリケーションの種類、そして最後に分散型ウェブサイトアーキテクチャにおけるZookeeperの役割について話します。
Zookeeperは大規模な分散システム向けの非常に信頼性の高い調整システムです。この定義から、zookeeperは分散システム上で動作する協調システムであることがわかります。なぜ分散システムには調整システムが必要なのでしょうか? その理由は以下の通りです。

分散システムの開発は非常に困難であり、その難しさは主に分散システムの「部分的な故障」に反映されています。「部分的障害」とは、ネットワークの2つのノード間で情報が送信されることを指します。ネットワークが障害を起こした場合、送信者は受信者がメッセージを受信したかどうかを知らず、その原因が複雑である場合、受信者がネットワークエラー前にメッセージを受け取っていたかどうか、または受信者のプロセスが停止している場合を指します。送信者が本当の状況を知る唯一の方法は、受信機に再接続し、なぜエラーが発生したのかを受信者に尋ねることであり、これが分散システム開発における「部分的故障」問題です。

Zookeeperは分散システムの「部分的故障」を解決するためのフレームワークです。 Zookeeperは分散システムが「部分的故障」問題を回避できるわけではありませんが、分散システムが部分的故障に直面した際にこれらの問題を正しく処理できるようにし、分散システムが正常に動作できるようにします。

Zookeeperの実用的な使い方について話しましょう。

シナリオ1:クライアントに特定のサービスを提供するサーバー群(例えば、先に作成した分散型ウェブサイトのサーバー側はフロントエンドクラスタにサービスを提供する4台のサーバーで構成されたクラスタです)。クライアントがサーバークラスター内でサーバーをリクエストするたびに見つけられるようにし、サーバーがクライアントに必要なサービスを提供できるようにします。この場合、プログラム内にサーバーのリストが必要で、クライアントがリクエストするたびにそのリストを読み取る必要があります。このサブリストは明らかに単一のノードサーバーに保存できません。そうでなければノードが停止し、クラスタ全体が失敗します。その時点でこのリストが高可用性であることを期待しています。ストレージリスト内のサーバーが壊れている場合、他のサーバーが即座にそのサーバーを置き換え、壊れたサーバーをリストから削除できます。これにより、故障したサーバーはクラスタ全体の運用から撤退できます。これらの操作はすべて、故障したサーバーではなく、クラスタ内の通常のサーバーによって操作されます。これは、外部条件が変化した際にデータ項目の状態を積極的に変更できるアクティブ分散データ構造です。 Zookeeperフレームワークはこのサービスを提供しています。このサービスの名前は「統一ネーミングサービス」で、javaEEのJNDIサービスに非常に似ています。

シナリオ2:分散ロックサービス。分散システムがデータを操作する場合、例えばデータの読み取り、分析、そして最終的にデータの修正を行います。分散システムでは、これらの操作がクラスタ内の異なるノードに分散されることがあります。この場合、データ操作のプロセスに一貫性の問題が生じます。もし一貫性がなければ誤った操作結果が得られます。単一のプロセスプログラムでは一貫性の問題は解決しやすいですが、分散システムに到達するのはより困難です。なぜなら、分散システム内の異なるサーバーの操作が独立したプロセスに分かれているため、操作の中間結果やプロセスがネットワークを通じて送信されなければならないからです。そうなると、データ操作の一貫性を達成するのがはるかに難しくなります。 Zookeeperはこの問題を解決するロックサービスを提供し、分散データ操作を行う際にデータ操作の一貫性を確保できるようにします。

シナリオ3:構成管理。分散システムでは、サービスアプリケーションをn台のサーバーに別々に展開し、これらのサーバーの設定ファイルは同じです(例えば、私が設計した分散型ウェブサイトフレームワークでは、サーバー側に4台のサーバーがあり、4台のプログラムも同じ、設定ファイルも同じです)。設定ファイルの設定オプションが変われば、それらを一つずつ変更しなければなりません。サーバーを変更する場合は比較的小さく、これらの操作はそれほど面倒ではありません。もし大手インターネット企業のHadoopクラスターのように数千台のサーバーを持つ分散サーバーが多数ある場合、設定オプションの変更は厄介で危険なことになり得ます。この時点でZookeeperが役立ちます。Zookeeperを高可用性の設定メモリとして使い、管理のためにZookeeperに渡します。クラスターの設定ファイルをZookeeperのファイルシステムのノードにコピーし、すべての分散システムで設定ファイルの状態を監視します。設定ファイルが変更されたと判断した場合に。各サーバーはZookeeperから設定ファイルの同期通知を受け取り、Zookeeperサービスは同期操作が原子的であることを確認し、各サーバーの設定ファイルが正しく更新されるようにします。

シナリオ4:分散システム向けの故障修復機能を提供する。クラスター管理は難しく、Zookeeperサービスを分散システムに追加することでクラスター管理が容易になります。クラスタ管理で最も厄介なのはノードフォールト管理です。Zookeeperはクラスタに健康なノードをマスターとして選択させ、マスターノードはクラスタ内の各サーバーの現在の健康状態を把握し、ノードが故障するとマスターがクラスタ内の他のサーバーに通知し、異なるノードの計算タスクを再分配します。 Zookeeperは故障箇所を見つけるだけでなく、故障したサーバーをスクリーニングし、故障サーバーの種類を確認し、故障が修復可能であれば自動的に修正またはエラーの原因をシステム管理者に伝え、管理者が迅速に問題を特定しノードの故障を修復できるようにします。まだ疑問があるかもしれませんが、マスターが故障していた場合、どうすればいいのでしょうか? Zookeeperもこれを考慮しており、社内に「リーダー選出アルゴリズム」があり、マスターを動的に選択でき、マスターが失敗するとすぐに新しいマスターを選んでクラスタを管理できます。

Zookeeperの機能について話しましょう:

ZooKeeperは効率的なファイルシステムです。これはHadoopに少し似ていますが、ZooKeeperファイルシステムは小さなファイルを管理し、Hadoopは非常に大きなファイルを管理します。

Zookeeperは、多くの操作がデータ構造やプロトコルを調整するための豊富な「アーティファクト」を提供します。例えば、分散キュー、分散ロック、そして同じレベルのノード群の「リーダー選出」アルゴリズムなどです。

ZooKeeperは高い可用性を持ち、自身の安定性も良好で、分散クラスターはクラスタ管理に依存でき、分散システムの単一点障害問題を回避するために使われています。

Zookeeperは緩やかに結合されたインタラクションモードを採用しています。これは特に、Zookeeperが分散ロックを提供していることに顕著です。これは、参加プロセスが他のプロセス(やネットワーク)を知らずに互いを発見し交流できるアポイントメントメカニズムとして利用可能です。また、参加する当事者が同時に存在する必要もなく、Zookeeperにメッセージを残し、プロセス終了後に別のプロセスがそのメッセージを読み取ることで、ノード間の関係が切り離されます。

ZooKeeperはクラスタのための共有リポジトリを提供し、そこからクラスタは共有情報を中央で読み書きできるため、各ノードの共有操作のプログラミングを回避し、分散システムの開発難易度を軽減します。

Zookeeperは主に、みんなが関心を持つデータの保存と管理を担当し、その後オブザーバーの登録を受け入れます。これらのデータの状態が変わった場合、ZookeeperはZookeeperに登録したオブザーバーに通知し、クラスタに似たマスター/スレーブ管理モードを実現します。

Zookeeperは分散システム開発に非常に適しており、分散システムの堅牢性と効率を高めることができます。

つい最近、私は学科のハドゥープ関心グループに参加し、テスト環境にhadoop、mapreduce、Hive、Hbaseをインストールし、hbaseをインストールする際にはZookeeperを事前にインストールしました。 ZooKeeperはサービスを提供できるため、3台のうち半分以上が2台、4台の半分以上が2台でもあるため、3台のサーバーを設置すれば4台のサーバーの効果を実現できます。 Hadoopを学ぶ過程で、Zookeeperは最も理解が難しいサブプロジェクトだと感じています。その理由は技術的に責任があるからではなく、その応用方向性が非常に分かりにくいからです。ですので、私の最初のhadoop技術に関する記事はzookeeperから始まり、具体的な技術的実装については触れていませんが、zookeeperの応用分野を理解しており、Zookeeperを学ぶことは半分の労力でより効果的だと思います。

今日Zookeeperについて話したい理由は、前回の記事で述べた分散型ウェブサイトフレームワークを補完するためです。ウェブサイトのアーキテクチャは分散構造として設計しましたが、ハートビート機構のような単純な障害処理メカニズムも作りました。しかし、クラスタの単一障害点を解決する方法は依然としてありません。サーバーが壊れているとクライアントが接続しようとし、その結果一部のリクエストがブロックされ、サーバーリソースの無駄遣いも生じます。しかし、現時点ではフレームワークを変更したくありません。既存のサービスにzookeeperサービスを追加するとウェブサイトの効率に影響が出るといつも感じているからです。幸いにも、私たちの部署も同様の問題に直面しており、強力なリモート通話フレームワークを開発し、クラスター管理と通信管理を分離し、効率的かつ利用可能性の高いサービスを中央集権で提供します。

ttp://www.cnblogs.com/sharpxiajun/archive/2013/06/02/3113923.html から転属

分析のズーキーパーは具体的に何をするのでしょうか?

関連記事

閲覧したセクション