ZooKeeperオブザーバー
オブザーバー: 書き込みパフォーマンスを損なうことなくZooKeeperをスケーリングする
ZooKeeperは、クライアントがアンサンブルの投票メンバーに直接接続することで非常に優れたパフォーマンスを発揮しますが、このアーキテクチャでは、膨大な数のクライアントにスケールアウトすることが困難です。問題は、投票メンバーを追加するにつれて、書き込みパフォーマンスが低下することです。これは、書き込み操作には(一般的に)アンサンブル内のノードの少なくとも半分が合意する必要があるため、投票のコストは投票者の追加に伴って大幅に増加する可能性があるためです。
この問題に対処し、ZooKeeperのスケーラビリティをさらに向上させるために、オブザーバーと呼ばれる新しいタイプのZooKeeperノードを導入しました。オブザーバーは、投票に参加しないアンサンブルのメンバーであり、投票の結果のみを聞き、投票に至るまでの合意プロトコルには参加しません。この単純な違いを除けば、オブザーバーはフォロワーとまったく同じように機能します。クライアントはオブザーバーに接続し、読み取りおよび書き込みリクエストを送信できます。オブザーバーは、フォロワーと同様にこれらのリクエストをリーダーに転送しますが、投票の結果を聞くまで待機します。このため、投票のパフォーマンスに影響を与えることなく、オブザーバーの数を好きなだけ増やすことができます。
オブザーバーには他にも利点があります。投票に参加しないため、ZooKeeperアンサンブルの重要な部分ではありません。そのため、ZooKeeperサービスの可用性を損なうことなく、障害が発生したり、クラスターから切断されたりすることがあります。ユーザーにとっての利点は、オブザーバーはフォロワーよりも信頼性の低いネットワークリンクを介して接続できることです。実際、オブザーバーを使用して、別のデータセンターからZooKeeperサーバーと通信することができます。オブザーバーのクライアントは、すべての読み取りがローカルで処理されるため、高速な読み取りを実現し、投票プロトコルがない場合に必要なメッセージの数が少ないため、書き込みによるネットワークトラフィックを最小限に抑えることができます。
オブザーバーの使い方
オブザーバーを使用するZooKeeperアンサンブルのセットアップは非常に簡単で、設定ファイルに2つの変更を加えるだけです。まず、オブザーバーになるすべてのノードの設定ファイルに、次の行を配置する必要があります。
peerType=observer
この行は、サーバーがオブザーバーになることをZooKeeperに指示します。次に、すべてのサーバー設定ファイルで、各オブザーバーのサーバー定義行に:observerを追加する必要があります。例えば
server.1:localhost:2181:3181:observer
これは、他のすべてのサーバーに、server.1がオブザーバーであり、投票することを期待すべきではないことを伝えます。これは、ZooKeeperクラスターにオブザーバーを追加するために行う必要があるすべての設定です。これで、通常のフォロワーであるかのように接続できます。次を実行して試してみてください。
$ bin/zkCli.sh -server localhost:2181
ここで、localhost:2181は、すべての設定ファイルで指定されているオブザーバーのホスト名とポート番号です。コマンドラインプロンプトが表示され、lsなどのコマンドを発行してZooKeeperサービスにクエリを実行できます。
オブザーバーマスターの使い方
オブザーバーは、アンサンブルの非投票メンバーとして単純に機能し、フォロワーとラーナーインターフェースを共有し、わずかに異なる内部パイプラインのみを保持します。どちらも、クォーラムポートを介してリーダーとの接続を維持し、それによってアンサンブルのすべての新しい提案について学習します。
デフォルトでは、オブザーバーはクォーラムポートを介してクォーラムのリーダーに接続し、これがアンサンブルのすべての新しい提案を学習する方法です。リーダーに接続する代わりに、コミットストリームに接続する手段として、オブザーバーがフォロワーに接続できるようにすることには利点があります。オブザーバーをサポートする負担をリーダーからシフトし、書き込みのコミットの調整に集中できるようにします。これは、リーダーが高負荷、特にリーダー選出後に多くのラーナーが同期する必要がある場合などに発生する可能性のある高いネットワーク負荷の下にある場合のパフォーマンスを向上させます。オブザーバーの数が多い場合、リーダーで維持されるネットワーク接続の総数を削減します。フォロワーをアクティブにしてオブザーバーをサポートすることで、オブザーバーの総数を数百にまで拡張できます。一方、オブザーバーの可用性は、多数のオブザーバーが同期を完了してクライアントトラフィックの処理を開始するまでの時間が短縮されるため、向上します。
この機能は、フォロワーがオブザーバー接続をリッスンするために使用するポートをアンサンブルのすべてのメンバーに知らせることでアクティブにすることができます。サーバー設定ファイルに次のエントリを追加すると、オブザーバーはポート2191でピア(リーダーとフォロワー)に接続するように指示され、フォロワーはObserverMasterスレッドを作成してそのポートでリッスンしてサービスを提供するように指示されます。
observerMasterPort=2191
ユースケース例
オブザーバーの2つのユースケース例を以下に示します。実際、ZooKeeperアンサンブルのクライアント数をスケーリングしたい場合、またはアンサンブルの重要な部分をクライアントリクエストを処理する負荷から分離したい場合は、オブザーバーは優れたアーキテクチャの選択です。
- データセンターブリッジとして: 2つのデータセンター間にZKアンサンブルを形成することは、データセンター間のレイテンシのばらつきが大きいため、誤検知やパーティショニングにつながる可能性があるため、問題があります。ただし、アンサンブルが1つのデータセンターで完全に実行され、2番目のデータセンターでオブザーバーのみが実行される場合、アンサンブルは接続されたままになるため、パーティションは問題になりません。オブザーバーのクライアントは、引き続き提案を表示および発行できます。
- メッセージバスへのリンクとして: 一部の企業は、ZKを永続的で信頼性の高いメッセージバスのコンポーネントとして使用することに関心を示しています。オブザーバーは、この作業の自然な統合ポイントを提供します。プラグインメカニズムを使用して、オブザーバーが認識する提案のストリームをパブリッシュ/サブスクライブシステムに接続することができます。これもコアアンサンブルに負荷をかけることなく行えます。