Observers: Making ZooKeeper Scale Even Further
December 15th, 2009 by Henry Robinson
http://www.cloudera.com/blog/2009/12/15/observers-making-zookeeper-scale-even-further/
As readers of our previous post on the subject will recall, ZooKeeper is a distributed coordination service suitable for implementing coordination primitives like locks and concurrent queues. One of ZooKeeper’s great strengths is its ability to operate at scale. Clusters of only five or seven machines can often serve the coordination needs of several large applications.
このタイトルに関連する以前のポストについて、読み手が思い出すように、 ZooKeeper とは協調のための基本要素である、ロックやコンカレント･キューの実装に適切な、分配協調サービスのことである。 ZooKeeper における重要な長所の 1つとして、様々なスケールで動作する能力がある。いくつかの大規模アプリケーションで必要とされる調整を、たった5台～7台のマシンからなるクラスタで充たすような状況も稀ではなくなる。
We’ve recently added a major new feature to ZooKeeper to improve its scalability even further – a new type of server called Observers. In this blog post, I want to motivate the need for such a feature, and explain how it might help your deployments scale even better. Scalability means many things to many people – here I mean that a system is scalable if we can increase the workload the system can handle by assigning more resources to the system – a non-scalable system might see no performance improvement, or even a degradation as the workload increases.
最近になってZooKeeper に加えられた、新しい主要な機能である、 Observers と呼ばれる新しいタイプのサーバーにより、そのスケーラビリティがさらに改善される。このブログ･ポストでは、こうした特徴に対する必要性を喚起し、また、どのようにしてディプロイメント･スケールを支援するのか、その点についても説明していきたい。スケーラビリティの意味は、人それぞれであるため、こ こでは以下のように定義する。つまり、より多くのリソースをシステムに割り当てることで、処理すべきワークロードを増大できるなら、そのシステムはスケーラブルである。反対に、スケーラブルでないシステムは、ワークロードの増大にあわせてパフォーマンスを改善できない状況というより、低下させる状況に陥ってしまう。
To understand why Observers have an effect on ZooKeeper’s scalability, we need to understand a little about how the service works. Broadly speaking, every operation on a ZooKeeper cluster is either a read or a write operation. ZooKeeper makes sure that all reads and all writes are observed by every client of the system in exactly the same order, so that there’s no confusion about which operation happened first.
Observers が ZooKeeper のスケーラビリティを向上させる理由を理解するために、どのようにして、このサービスが機能するか、理解する必要がある。概括的に言って、ZooKeeper クラスタ上のすべてのオペレーションは、read あるいは write のオペレーションである。 ZooKeeperは、すべてのreadとwriteがシステム上の全てのクライアントから、完全に同じ順序で観察されることを保障するので、どのオペレーションが最初に行われたのか、混乱が起こることが無くなる。
Along with this strong consistency guarantee, ZooKeeper also promises high availability, which can loosely be interpreted to mean that it can withstand a significant number of machine failures before the service stops being available to clients. ZooKeeper achieves this availability in a traditional way – by replicating the data that is being written and read amongst a small number of machines so that if one fails, there are others ready to take over without the client being any wiser.
こうした強固な一貫性の保証とともに、ZooKeeper は高可用性を約束する。それは、クライアントにとってサービスが利用できなくなる前に、マシンにおける相当数の障害に耐えるレベルを、大まかに解釈できるからである。 ZooKeeper は、以下の伝統的な手法で可用性を達成する。 つまり、read/write されたデータを何台かのマシンにリプリケートし、１つの失敗が生じた場合に、クライアントの能力に依存することなく、処理を達成するための別ルートを用意しておく。
However, these two properties – consistency and availability – are hard to achieve together, as now ZooKeeper must make sure that every replica in its cluster agrees on the series of read and write operations. It does this by using a consensus protocol. Simplifying greatly, this protocol operates by having a designated Leader propose a new operation to all the other servers, all of whom vote and respond back to the Leader. Once the Leader has gathered more than half the votes outstanding from the other servers, it can deduce that the vote has passed, and sends a further message telling the servers to go ahead and commit the operation to their memory.
こうした強固な一貫性の保証とともに、 ZooKeeper は高可用性を約束する。この高可用性とは、大まかに解釈すれば、相当数のマシンに障害が起きるまでは、クライアントからはサービスが利用可能だということである。ZooKeeper は、以下の伝統的な手法で可用性を達成する。 つまり、read/write されたデータを何台かのマシンにリプリケートし、1台に障害が生じた場合に、クライアントの能力に依存することなく、他のマシンが処理を代行できるのである。
This data flow is illustrated, from start to finish as the client sees it, in the diagram below. The client proposes a value to the server it is connected to. The server then relays that to the Leader, which initiates the consensus protocol, and once the original server has heard from the Leader it can relay its answer back to the client.
以下の図におけるデータ･フローは、クライアントから start と finish を見通すイメージを示す。 クライアントは、自身が接続するサーバーに対して value を提示する。続いてサーバーは、コンセンサスのプロトコルを開始する Leader に中継する。また、オリジナル･サーバーは、Leader からの返信を受け取った直後に、クライアントに対する返信を中継することができる。
Figure 1: Simplified Write Request Flow
The need for Observers arises from the observation (no pun intended!) that ZooKeeper servers are playing two roles in this protocol. They accept connections and operation requests from clients, and also vote upon the result of these operations. These two responsibilities stand in opposition to each other when it comes to scaling ZooKeeper. If we wish to increase the number of clients attached to a ZooKeeper cluster (and we are often considering the case with 10000 or more clients), then we have to increase the number of servers available to support those clients. However, we can see from the description of the consensus protocol, that increasing the number of servers can place pressure on the performance of the voting part of the protocol. The Leader has to wait for at least half of the machines in the cluster to respond with a vote. The chance of one of these machines running slowly and holding up the entire vote process therefore gets bigger, and the performance of the voting step can decrease commensurately. This is something that we have seen in practice – as the size of the ZooKeeper cluster gets bigger, throughput of voting operations goes down.
Observers の必要性は、このプロトコルにおいて、ZooKeeper サーバーが 2つの役割を担うという観察結果（observation というダジャレではない！）から生じている。それらは、クライアントからの接続と処理のリクエストを受け入れ、それらの処理結果について vote を行う。 この 2つの責任は、ZooKeeper をスケーリングする際にも、相互に代役を務める。 もし、ZooKeeper クラスタ（10,000 以上のクライアント数を想定）にアタッチされるクライアント数を増やすなら、それらのクライアントをサポートするために、利用することが可能なサーバー数を増やす必要がある。しかし、サーバー数を増やすことが、このプロトコルの vote 部分のパフォーマンスに圧力をかける可能性について、コンセンサスのプロトコル記述に基づいて確認できる。少なくとも、クラスタ内の半分のマシンが vote に反応するまで、Leader は待たなければならない。したがって、これらのマシンの 1つに速度の低下が見られ、また、すべての vote プロセスを渋滞させる可能性が高まり、そのサイズも大きくなると、vote ステップのパフォーマンスは相応に低下する。 つまり、ZooKeeper クラスタ･サイズが大きくなるにつれて、vote オペレーションのスループットが低下していくことが、私たちのプラクティスで確認されている。
So there is a tension between our desire to scale the number of clients, and our desire to keep performance reasonable in terms of throughput. To decouple this tension, we introduced non-voting servers called Observers to the cluster. Observers can accept client connections, and will forward write requests to the Leader. However, the Leader knows not to ask the Observers to vote. Instead, Observers takes no part in the voting process, but instead are informed about the result of the vote in Step 3 along with all the other servers.
そのため、 クライアント数のスケールを調整したいいう望みと、スループットに関して適切なパフォーマンスを維持したいという望みの間に、張力が生じている。この張力を吸収するために、Observers と呼ばれる non-voting サーバーをクラスタに導入した。 Observers はクライアント接続の受け入れに対応し、write リクエストを Leader に転送することになる。 しかし、Leader は Observers に対して、vote を依頼しないことを知っている。Observers は vote のプロセスに参加しないが、それに代えて、すべての他のサーバーとともに、Step 3 の vote 結果を通知される。
This simple extension opens up new vistas of scalability to ZooKeeper. We may now add as many Observers as we like to the cluster without dramatically affecting write throughput. The scaling is not absolutely perfect – there is one step in the protocol (the ‘inform’ step) that is linear in the number of servers to inform, but the serial overhead of this step is extremely low. We would expect to hit other bottlenecks in the system before the cost of sending an inform packet to every server dominates the throughput performance of a ZooKeeper cluster.
このシンプルな拡張により、ZooKeeper のスケーラビリティについて、新しい視界が開ける。つまり、write スループットに大幅な影響を与えることなく、必要とされるクラスタの分だけ、Observers を追加できるだろう。このスケーリングは、絶対的な完ぺきさをもたらすものではない。 つまり、通知を行うサーバーの数に対して、リニアに対応するプロトコルのワン･ステップ（inform ステップ）になるが、このステップの連続的なオーバーヘッドは極めて低くなる。 すべてのサーバーに対する通知パケットを送信するためのコストが、ZooKeeper クラスタにおけるスループットのパフォーマンスを独占する前に、システム上の他のボトルネックに遭遇すると予期したい。
Figure 2: Observers Write Throughput Benchmark
Figure 2 shows the results of one microbenchmark. The vertical axis measures the number of synchronous write operations per second that I was able to issue from a single client (a fully tuned ZooKeeper installation can significantly more operations per second – it’s the relative size of the bars we’re interested in here) . The horizontal axis denotes the size of the ZooKeeper cluster used. The blue bars are ZooKeeper clusters where every server is a voting server, where the green bars are ZooKeeper clusters where all but three servers are Observers. The chart shows that write performance stays approximately constant as we scale out the number of Observers, but falls off dramatically if we expand the size of the voting cluster. This is a win for Observers!
Figure 2 が示すのは、簡単なベンチマークの結果である。タテ軸は、シングル･クライアントから発行が可能な、毎秒あたりの同期 write 数の測定値である（ZooKeeper のインストレーションを完全に調整すると、毎秒あたりの処理量が大幅に増大する。つまり、ここでのバーの長さに影響することになる）。ヨコ軸は、使用された ZooKeeper クラスタ･サイズを示す。青いバーは、すべてのサーバーが vote サーバーの場合の ZooKeeper クラスタであり、緑のバーは、3つのサーバーに Observers を加えた場合の ZooKeeper クラスタを示す。 このチャートからは、Observers 数をスケールアウトするときに write パフォーマンスが安定し、また、voting クラスタのサイズを拡大するときには write パフォーマンスが大幅に低下する状況が読み取れる。 この点が、Observer にとっての勝利である！
ーーーーー 玉川竜司さんによる改編 ： 2010/2/7
ZooKeeper の予備知識もないのに、Observers 関連の抄訳なので、、、 かなりヨロヨロです。 訳語の問題や勘違いのご指摘など、よろしくお願いします。 ーーー A.C.
<続く>
＜関連＞
Observers と ZooKeeper _2
The Anatomy of Hadoop I/O Pipeline _1
