# ZooKeeper ## 概要 Apache ZooKeeper は、Chubby ロックサービスに範をとった[[コーディネーションサービス]]であり、内部のコンセンサスアルゴリズムに Zab (ZooKeeper Atomic Broadcast) を用いる。分散ロック・リーダー選出を実装するために広く使われ、Apache Curator のような高レベルライブラリが ZooKeeper クライアント API の上に典型的な利用パターン(レシピ)を提供する。(Source: [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 10 Consistency and Consensus]] "Locking and leader election") 厳密には、ZooKeeper が保証するのは書き込みの線形化可能性のみであり、読み取りは現在のリーダーから提供される保証がないため陳腐化しうる(これに対し etcd はバージョン3以降デフォルトで線形化可能な読み取りを提供する)。フェンシングには各ログエントリに単調増加する `zxid` と `cversion` を用いる。障害検知にはクライアントセッションと「エフェメラルノード」(セッション切断時に自動削除されるノード)を用いる。読み取りスループットを増やすため、コンセンサスの投票プロセスには参加せずログと複製データのみを保持する「オブザーバー」レプリカもサポートする。 Kubernetes は etcd に依存する一方、高可用モードの Spark と Flink は ZooKeeper に依存する。(Source: [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 10 Consistency and Consensus]] "Coordination Services") ## ZAB プロトコルの詳細(詳説 データベース 14章) *詳説 データベース* 14章は、ZooKeeper のレプリカ間一貫性を管理する ZAB(ZooKeeper Atomic Broadcast)を、アトミックブロードキャストのもっとも定評ある実装として詳述する。ZAB におけるプロセスはリーダーとフォロワーの 2 役割を持ち、プロトコルのタイムラインは単調増加する一意な番号で識別されるエポックに分割される。いずれのエポックでもリーダーは 1 つだけ存在できる。リーダー候補は認められるとすぐに以下 3 フェーズを実行する。 - **発見**: リーダー候補が他のすべてのプロセスが認識している最新のエポックを確認し、より大きな新しいエポックを提案する。このステップ完了後は、どのプロセスも以前のエポックへの提案を受け入れない。 - **同期**: 前のリーダーの障害から復旧し、遅延しているフォロワーを追いつかせる。新しいリーダーはフォロワーが同じ履歴を持っていることを確認し、以前のエポックのリーダーからのコミット済み提案を配信する。 - **ブロードキャスト**: フォロワーが同期状態に戻ると、リーダーがクライアントメッセージの順序を確立してフォロワーへブロードキャストし、フォロワーのクォーラム(過半数)の確認応答を待って提案をコミットする。中断がない点を除きツーフェーズコミットに似る。 安全性は「確立されたエポックのリーダーからのみフォロワーが提案を受け入れる」ことで保証される。リーダー・フォロワーは互いの生存確認にハートビートを用い、リーダーがフォロワーのクォーラムからハートビートを受け取れなければ自らリーダーの座を退いて選出プロセスを再開する。メッセージは全順序に従い、フォロワーが複数回受け取っても配信順序が守られていれば副作用は生じない。ブロードキャストに必要なメッセージのラウンドは 2 回だけであり、長期に存続するリーダーを持つことがパフォーマンスに寄与する。(Source: [[@2021__OReillyJapan__詳説 データベース - Chapter 14 合意]] §14.2.2) ## フェイルスロー障害の事例 [[@2026__TOCS__Fail-Slow Hardware Failure Bug Analysis and Detection for Cloud Systems]] のバグスタディでは 11 件の FSH 障害が ZooKeeper から収集された。本番事例としては、`synchronized(node)` ブロック内の `writeRecord` がフェイルスロー NIC で詰まり、更新系リクエスト(SET/WRITE/CREATE)だけが全て止まる一方 READ は通り、heartbeat も影響を受けないためクラスタが健全と報告され続けた障害が知られる(PagerDuty の技術者が診断に 5 か月を費やした)。[[Sieve]] は ZooKeeper 3.9.0 から未知バグ 4 件(ZK-4816: leader のスナップショット直列化が詰まり leader が二重に並立する / ZK-4817: `CancelledKeyException` がクライアント切断を捕捉しない / ZK-4844: `writeLongToFile` の遅延で follower がハングする / ZK-4836: ACL テーブル同期の遅延でインデックス不整合が生じ `MarshallingError` で follower がクラッシュする)を検出し、ZK-4836 は開発者に確認された。(Source: [[@2026__TOCS__Fail-Slow Hardware Failure Bug Analysis and Detection for Cloud Systems]] §1・§6.1.2) ## 関連 - ソース: [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 10 Consistency and Consensus]] / [[@2026__TOCS__Fail-Slow Hardware Failure Bug Analysis and Detection for Cloud Systems]] / [[@2021__OReillyJapan__詳説 データベース - Chapter 14 合意]] - 概念: [[コーディネーションサービス]] / [[分散コンセンサス]] / [[線形化可能性]] / [[フェイルスローハードウェア]] / [[障害注入]] - エンティティ: [[etcd]] / [[Chubby]] / [[Sieve]] ## 出典 - [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 10 Consistency and Consensus]] - [[@2026__TOCS__Fail-Slow Hardware Failure Bug Analysis and Detection for Cloud Systems]] - [[@2021__OReillyJapan__詳説 データベース - Chapter 14 合意]] §14.2.2(ZAB プロトコルの3フェーズ・安全性の根拠)