# コーディネーションサービス ## 定義 コーディネーションサービス(coordination service)とは、ZooKeeper・etcd・Consul のような、Google の Chubby ロックサービスに範をとった分散システムであり、他の分散システムのノード間の調整(ロック・リーダー選出・障害検知・変更通知)を専門に担う。見た目はキーバリューストアに似ているが、高い書き込みスループットや汎用のデータストレージを目的とせず、メモリに収まる小さなデータ(「IP アドレス 10.1.1.23 のノードがシャード7のリーダーである」といった情報)をフォールトトレラントなコンセンサスアルゴリズムで複製する点に特化している。(Source: [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 10 Consistency and Consensus]] "Coordination Services") ## 提供する機能 コンセンサスを必要とする機能とコンセンサスを必要としない機能を組み合わせる: - **ロックとリース**(コンセンサス必要): フォールトトレラントな CAS 操作で実現。複数ノードが同一リースを同時に取得しようとした場合、1つだけが成功する。 - **フェンシングサポート**(コンセンサス必要): 各ログエントリに単調増加する ID(ZooKeeper の `zxid`・`cversion`、etcd の revision number)を与えることで、プロセス一時停止やネットワーク遅延によるクライアント間の干渉を防ぐフェンシングトークンを生成する。 - **障害検知**(コンセンサス不要): クライアントはセッションを維持し定期的にハートビートを交換する。タイムアウトを超えるとコーディネーションサービスはクライアントを死んだとみなし、保持していたリースを解放する(ZooKeeper の「エフェメラルノード」)。 - **変更通知**(コンセンサス不要): 特定キーの変更をクライアントに通知することで、他クライアントの参加・離脱をポーリングなしで検知できる。 (Source: [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 10 Consistency and Consensus]] "Coordination Services") ## 主な用途 1. **ワーク割り当て**: 複数インスタンスの中からリーダー/プライマリを選ぶ用途(単一リーダーデータベースのフェイルオーバー、ジョブスケジューラ)。シャード化されたリソースをどのノードに割り当てるかの決定にも使われる。 2. **サービスディスカバリ**: サービスがどの IP アドレスで到達可能かをクライアントに教える。ただし、この用途は多くの場合線形化可能性を必要とせず、可用性と速度が重要になるため、コーディネーションサービスを直接叩くのではなくキャッシュ + TTL でベストエフォート運用するのが一般的である(DNS ベースのサービスディスカバリが多層キャッシュを使うのと同様)。ZooKeeper はこの用途向けに、コンセンサスの投票に参加せずログと複製データのみ保持する「オブザーバー」レプリカを提供し、読み取りスループットを増やせるようにしている。 (Source: [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 10 Consistency and Consensus]] "Allocating work to nodes", "Service discovery") ## 設計上の特徴: 少数固定ノードへの「合意の外部化」 コーディネーションサービスは通常3または5台の固定ノードクラスタとして動作し、それが調整する対象の分散システムのノード数(数千に及ぶこともある)とは無関係である。数千ノード全体で直接コンセンサスアルゴリズムを走らせるのは非効率なため、少数のノードにコンセンサスを「外部化」し、多数のノードはそのコーディネーションサービスのクライアントとして参加する方が実用的である。ZooKeeper・etcd はそれぞれ Zab・Raft という異なるコンセンサスアルゴリズムを内部で使うが、外部から見えるインターフェースは概ね共通している。(Source: [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 10 Consistency and Consensus]] "Coordination Services") ## 横断的知見 - **Chubby という単一の起源から、Paxos ベース(ZooKeeper の Zab)と Raft ベース(etcd)という異なるコンセンサスアルゴリズム実装へ分岐した**: [[分散コンセンサス]] ページは SRE Book の記述をもとに、Chubby が Paxos による非同期コンセンサスで5レプリカを維持しつつ、上位のマスタ選出ロジックを別レイヤーとして実装する点を「合意アルゴリズム自体と、それを利用する上位ロジックが分離した事例」として記録する。本章はこの系譜をさらに具体化し、ZooKeeper が Chubby と同じ Paxos 系譜(Zab)を継ぐ一方、etcd は Raft という別系譜のコンセンサスアルゴリズムを採用しながらも、外部から見た「ロック・リース・フェンシング・変更通知」というコーディネーションサービスとしての機能面ではほぼ同一のインターフェースに収斂していることを示す。アルゴリズムの選択(Paxos系 vs Raft系)よりも、コーディネーションサービスという抽象化のレベルでの機能の共通性の方が実務上重要であることを示唆する。(Source: [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 10 Consistency and Consensus]] "Coordination Services", [[分散コンセンサス]] の Source: [[@2016__OReilly__SRE Book - Chapter 2 The Production Environment at Google, from the Viewpoint of an SRE]]) - **リーダー選出の「エポック番号」という汎用概念は、コーディネーションサービスが提供するフェンシングトークンとして具体化される**: [[リーダー選出]] ページは Raft の term number を「候補者の投票資格を判定するための一意なエポック」として記録するが、本章はこの汎用的なエポック概念(ballot number in Paxos, view number in VR, term number in Raft, zxid/cversion in ZooKeeper, revision number in etcd)が、コーディネーションサービスの API レベルでは具体的な「フェンシングトークン」として利用者に露出されることを示す。すなわちコンセンサスアルゴリズム内部のエポック管理と、コーディネーションサービス利用者が受け取るフェンシングトークンは、実装レベルで直接対応する同一の機構である。(Source: [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 10 Consistency and Consensus]] "Support for fencing", [[リーダー選出]]) ## 未解決の問い - ZooKeeper のオブザーバーレプリカのように、コンセンサス投票に参加しないレプリカで読み取りスループットを増やす設計は、線形化可能性を諦めた読み取りにどこまで実用上依存してよいか。誤って線形化可能性が必要な用途にオブザーバーを使ってしまう典型的な失敗パターンは文献化されているか。 - コーディネーションサービスを「少数固定ノードへの合意の外部化」として使う設計は、調整対象のシステムが数万ノード規模に達したときにどこでスケーラビリティの限界を迎えるか(単一コーディネーションサービスクラスタへのリクエスト集中)。 ## 関連 - ソース: [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 10 Consistency and Consensus]] - 概念: [[分散コンセンサス]] / [[リーダー選出]] / [[複製ステートマシン]] - エンティティ: [[Chubby]] / [[ZooKeeper]] / [[etcd]] ## 出典 - [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 10 Consistency and Consensus]]