ZooKeeperによる分散システム管理 読了

ZooKeeperによる分散システム管理

ZooKeeperによる分散システム管理

  • 分散環境用情報統一管理機構
  • データの書き込み順序保証
  • サーバのスケールアウトが可能
  • データの監視とデータ変更時の通知機能
  • 障害時のセッション自動回復機能

アンサンブル

  • アンサンブルはZooKeeperサーバの集合
  • クオラム（過半数）によってリーダが選出される

リーダ選出

  • リーダ選出通知<sid, zxid>をアンサンブルに送る
  • zxidが大きい方（あるいはsidが大きい方）がリーダとなり、その他はフォロワーとなる

データ書き込み時の動作

  • クライアントからの書き込み要求はフォロワーからリーダへ転送される
  • リーダは書き込み要求を、データツリーに対するトランザクションに翻訳し、それをプロポーザル通知としてフォロワーへブロードキャストする
  • フォロワーは、プロボーザル通知が自分の従うリーダからのものかを確認し、トランザクションをトランザクションログ（RDMSのコミットログと同等）に書き込み、アクセプト通知をリーダーへ返す
    • トランザクションログはRDBMSのコミットログと同様で、あらかじめ割り当てられたディスクブロックに追記していく（これをパディングと呼ぶ）
    • これはZKDatabaseのcommitメソッドで行われるが、システムコール呼び出しによるディスクへのフラッシュは行われないことに注意する（OSに設定によって、ディスクキャッシュに書き出しただけで応答を返す場合がある）
    • 競合が起こってトランザクションの完了が遅延しないように、書き出すディスクは独立したデバイスを用いる方が良い
  • クオラムを達成する数のフォロワーからアクセプト通知を受け取ると、リーダはコミット（先ほど送ったトランザクションを実行するように、という通知）をフォロワーに送り、インフォーム（トランザクションを含めているからこれを実行するように、という通知）をオブザーバーに送る
    • オブザーバーは読み取りのためのスケールアウト戦略であり、アクセプトの投票には参加せず、コミットされたトランザクションを実行するだけ
  • これをZab(Zookeeper Atomic Broadcast)と呼ぶ

データ読み取り時の動作

  • クライアントからの読み取り要求を受け取ったフォロワー・オブザーバーは、各自のデータツリーから要求されたデータを返す

znode

  • ディレクトリであり同時にファイルで、親ノード・子ノードの関係がある
  • データツリーを構成する要素
  • 名前、データ、そしてバージョン番号から構成される
  • 格納できるデータのサイズは1MBに制限されている（データだけでなく、親ノードが持つ子ノードの数も制限される）
  • なお、znodeが再作成されるとバージョン番号はリセットされる（1になる）

Ephemeral znode（短命znode）

  • クライアントとサーバ（アンサンブル）のセッションが切れると削除されるznode
  • CreateMode.EPHEMERAL（永続znodeはCreateMode.PERSISTENTを指定）

API

  • 同期型と非同期型がある
  • 監視を設定でき、将来において、監視したznodeに変更があると一度だけ通知がとぶ
  • 監視を継続したい場合は、通知を受けたあとに再度監視をコールする必要がある
  • create/delete/exists/getData/setData/getChildren etc. ZooKeeper (ZooKeeper 3.4.5 API)

同期バージョン getData

byte data[] = getData(“/master”,false,stat)

  • dataにznodeから取得したデータが設定される
  • znode “/master”のデータを取得する
  • falseは監視を設定するかどうか
  • statはznodeのメタデータを設定する箱
  • NoNodeException, ConnectionLossExceptionをtry-catchすること

非同期バージョン getData

getData(“/master”,false,callback,null)

  • callbackはprocessResult関数を実装したDataCallback型のオブジェクト
  • nullはprocessResultに渡すべきデータが無いということ
  • processResult(int rc, String path, Object ctx, byte[] data, Stat stat)
    • rcは結果を示すコード
    • pathはznodeのパス
    • ctxはこの場合nullになる
    • dataにznodeから取得したデータが設定される
    • statはznodeのメタデータを設定する箱

クライアントからの接続要求

  • サーバ（アンサンブル）をZookeeper(“1.1.1.1:2181,1.1.1.2:2181,1.1.1.3:2181”,15000,watcher) のように文字列で指定するとそのうちの一つをランダムに選択してセッションを確立する
  • 15000はセッショタイムアウト（ミリ秒）
  • watcherは、サーバ（アンサンブル）とのセッションを監視し、セッションに関するイベントを処理するためのオブジェクト
    • Watcherクラスを実装し、processコールバックメソッドを実装したクラスのオブジェクト
  • あるサーバとのセッションが切断された場合もアンサンブルの他のサーバとのセッションが自動的に復旧される

スナップショット

  • スナップショットは、各サーバが定期的に保存するデータツリーのコピー
  • 必ずしもアンサンブルで統一されたデータツリーではないため、ファジースナップショットと呼ばれる
  • つまり、スナップショットから完全にデータツリーを復旧できるとは限らない（トランザクションログが必要になる）
  • トランザクションログのようにパディングは行われない

エポック

  • 1つのエポックは、あるサーバがリーダ権限を持っている時期を示す
  • 新しいリーダが選出されるたびに増加する
  • エポックはzxidの上位に含まれるため、リーダ選出において、最新のエポックの最新のトラザクションを知るサーバがリーダになる

Multiop

  • ZooKeeperのAPI操作をまとめてアトミックに実行するための機能
  • Opオブジェクトを返す複数の関数をListとしてmultiメソッドに渡し、OpResultオブジェクトのListを受け取る

Curator

  • 高レベルAPI
  • 引数を一括で指定して呼び出していた関数を、連鎖的に書ける（フルーエントAPI）

ベストプラクティス

  • ZooKeeperの外側のチャネルでクライアント同士がやり取りしない
    • ZooKeeperの書き込み・読み取りの順序は保証されるので、ZooKeeperのznodeを通じてやりとりするべき
    • マスタ・ワーカモデルをznodeで実現する

C.F.