# Chubby ## 概要 [[Google]] が開発した高可用かつ永続的な分散ロックサービスである。5 つのアクティブレプリカから構成され、過半数が稼働・通信可能であればサービスを維持する。レプリカ間の整合性には Paxos アルゴリズムを使用する。 [[@2006__OSDI__Bigtable - A Distributed Storage System for Structured Data]] では [[Bigtable]] の基盤サービスとして以下の用途で利用される: - マスタサーバが同時に 1 台のみ稼働することの保証 - Bigtable データのブートストラップ位置の格納 - タブレットサーバの発見と死亡判定 - スキーマ情報（テーブルごとのカラムファミリ情報）の格納 - アクセス制御リストの格納 Chubby は名前空間（ディレクトリとファイル）を提供し、各ディレクトリやファイルはロックとして利用できる。クライアントはセッションを維持し、セッションリースの更新ができなくなるとロックとハンドルを失う。Chubby が長時間利用不可になると Bigtable 全体が利用不可となるが、14 クラスタ・11 Chubby インスタンスでの測定では、Chubby 起因の Bigtable 不可用率は平均 0.0047% であった。 原論文は Mike Burrows による "The Chubby lock service for loosely-coupled distributed systems"（OSDI 2006）である。 [[@2016__OReilly__SRE Book - Chapter 2 The Production Environment at Google, from the Viewpoint of an SRE]] では、Chubby のもう一つの主要な用途としてマスタ選出が紹介される。あるサービスが信頼性のために 5 レプリカのジョブを稼働させつつ実処理を担うのは 1 レプリカのみという構成の場合、どのレプリカが処理してよいかを Chubby が選出する。また、[[Borg]] の Borg Naming Service(BNS)は、BNS パスと `IP アドレス:ポート` の対応関係という一貫性が求められるデータの格納先として Chubby を利用する。 [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 10 Consistency and Consensus]]は、ZooKeeper・etcd・Consul のような[[コーディネーションサービス]]が Chubby に範をとって設計されたと位置づける。Chubby はコンセンサスアルゴリズム(Paxos)にロック・リース・フェンシング・障害検知・変更通知を組み合わせるという設計パターンの起点であり、[[ZooKeeper]] は同じ Paxos 系譜の Zab を、[[etcd]] は別系譜の Raft を内部コンセンサスに採用しながらも、この Chubby 由来の機能構成を踏襲している。(Source: [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 10 Consistency and Consensus]] "Coordination Services") [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 9 The Trouble with Distributed Systems]]は、フェンシングトークン(リース発行のたびに増加する番号でゾンビ化した旧リース保持者を無害化する機構)の代替名称として、Chubby では*sequencer*と呼ばれることを紹介する。同じ機構は Kafka では*epoch number*、Paxos では*ballot number*、Raft では*term number*と呼ばれ、いずれも「単調増加する番号でリース・リーダーシップの世代を識別する」という同一の設計パターンの異なる呼称であることを示す。(Source: [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 9 The Trouble with Distributed Systems]] "Fencing off zombies and delayed requests") ## 2011年時点でZooKeeperとの機能差が実務者に認識されていた証拠(ウェブオペレーション第15章) 『ウェブオペレーション』第15章(2011年、[[Eric Florenzano]])は、HBaseの運用説明の中で「Googleには、スキーマ情報やアクセス制御リストに対応した Chubby というツールがあるが、ZooKeeper にはそのような機能はない」と明記する。これは、DDIA(2026年、[[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 10 Consistency and Consensus]])が「ZooKeeper・etcd・Consul は Chubby に範をとって設計された」と述べる系譜関係(既存知見)に対し、2011年時点では ZooKeeper がまだ Chubby の全機能(特にスキーマ情報・ACL格納)を備えていなかったという、実務者による同時代の具体的な観察を追加するものである。DDIA が示す「Chubby 由来の機能構成を後続のコーディネーションサービスが踏襲した」という系譜は、機能面で瞬時に完成したのではなく、少なくとも ZooKeeper が HBase で使われ始めた2010年前後の時点では未完成だったことを示唆する。(Source: [[@2011__OReillyJapan__ウェブオペレーション - Chapter 15 非リレーショナルデータベース]] §15.2.2, [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 10 Consistency and Consensus]] "Coordination Services") ## SREの視点: Google Workflowのライター選出への利用(SRE Book第25章) [[@2016__OReilly__SRE Book - Chapter 25 Data Processing Pipelines]]では、Chubbyは継続的データパイプラインシステム[[Google Workflow]]におけるリーダー選出の用途で登場する。Workflowの各Task Masterは、グローバルな整合性を得るためジャーナルを[[Spanner]]に保存するが、どのTask Masterが書き込み可能かを決める際に分散ロックサービスであるChubbyを使ってライター(writer)を選出し、その選出結果をSpannerに永続化する。クライアントは内部のネーミングサービスを使って現在のTask Masterを検索する。これはBigtableのマスタ選出([[@2006__OSDI__Bigtable - A Distributed Storage System for Structured Data]])やサービスの実処理担当レプリカ選出([[@2016__OReilly__SRE Book - Chapter 2 The Production Environment at Google, from the Viewpoint of an SRE]])と同様、Chubbyが「複数の候補から単一の書き込み担当者を選ぶ」という用途で繰り返し使われる事例である。(Source: [[@2016__OReilly__SRE Book - Chapter 25 Data Processing Pipelines]]) ## カスケード障害対策の設定配布への利用(SRE Book第22章) [[@2016__OReilly__SRE Book - Chapter 22 Addressing Cascading Failures]]は、複雑な負荷遮断・グレースフルデグラデーションのパラメータを、各サーバが変更を監視できる一貫したシステムに保存することでデプロイ速度を高められる例として Chubby を挙げる。同時に、この設計は多数のサーバが単一の設定ソースを共有することによる同期的障害(synchronized failure)のリスクを新たに持ち込むと注意を促す。マスタ選出・BNS のバックエンド(ch.2)、Task Master のライター選出(ch.25)がいずれも「複数候補から単一の担当者を選ぶ」用途であったのに対し、この用例は「多数のサーバへ設定を一貫して配布する」用途であり、Chubby が担う役割の異なる側面を示す。(Source: [[@2016__OReilly__SRE Book - Chapter 22 Addressing Cascading Failures]]) ## 関連 - ソース: [[@2006__OSDI__Bigtable - A Distributed Storage System for Structured Data]] / [[@2016__OReilly__SRE Book - Chapter 2 The Production Environment at Google, from the Viewpoint of an SRE]] / [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 10 Consistency and Consensus]] / [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 9 The Trouble with Distributed Systems]] / [[@2011__OReillyJapan__ウェブオペレーション - Chapter 15 非リレーショナルデータベース]] / [[@2016__OReilly__SRE Book - Chapter 25 Data Processing Pipelines]] / [[@2016__OReilly__SRE Book - Chapter 22 Addressing Cascading Failures]] - エンティティ: [[Google]] / [[Bigtable]] / [[Borg]] / [[ZooKeeper]] / [[etcd]] / [[Google Workflow]] / [[Spanner]] - 概念: [[分散ストレージ]] / [[分散コンセンサス]] / [[コーディネーションサービス]] / [[周期パイプライン]] ## 出典 - [[@2006__OSDI__Bigtable - A Distributed Storage System for Structured Data]] - [[@2016__OReilly__SRE Book - Chapter 2 The Production Environment at Google, from the Viewpoint of an SRE]](マスタ選出・BNS のバックエンドとしての利用) - [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 10 Consistency and Consensus]](コーディネーションサービスの設計モデルとしての位置づけ) - [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 9 The Trouble with Distributed Systems]]「Fencing off zombies and delayed requests」(sequencer = フェンシングトークンの Chubby 用語) - [[@2011__OReillyJapan__ウェブオペレーション - Chapter 15 非リレーショナルデータベース]] §15.2.2(2011年時点でZooKeeperがChubbyのスキーマ情報・ACL機能を備えていなかったという実務者の観察) - [[@2016__OReilly__SRE Book - Chapter 25 Data Processing Pipelines]](Google WorkflowのTask Masterライター選出への利用) - [[@2016__OReilly__SRE Book - Chapter 22 Addressing Cascading Failures]](グレースフルデグラデーション設定の一貫配布と同期的障害のリスク)