LASSIC Media らしくメディア
リーダー選出とは｜分散システムで代表を決める
分散システムでは、複数のサーバーが力を合わせて処理を担います。そのなかには、書き込みの順序をそろえたり、ジョブの割り当てを調整したりする役目を、誰か一台が代表として引き受けないと処理がまとまらない場面も出てくるでしょう。代表を毎回人手で決めるわけにはいかないため、システム側で自動的に一台を選び、その代表が落ちたら残りで選び直す仕組みが要ります。これがリーダー選出（リーダーエレクション）です。発注担当者やプロジェクトマネージャーがベンダーと構成を話す際、可用性設計の判断材料として押さえておきたいテーマといえるでしょう。
似た響きの概念に、複数のデータベースにまたがる更新を一斉に確定させる二相コミットや、データの置き場所を決めるコンシステントハッシュ法があります。これらはそれぞれ更新の整合の取り方、データ配置の決め方を扱う別の話であり、本記事では扱いません。ここで整理するのは、あくまで「誰が代表（リーダー）を務めるかを決め、落ちたら選び直す」という可用性の仕組みです。仕様書やベンダーの提案書に「リーダー選出」「フェイルオーバー」といった語が出てきたとき、何を指しているのかを見分けられるようにしておくと、レビューの精度が上がるでしょう。仕組みの考え方と、発注・レビューで確かめておきたい着眼点を見ていきます。
この記事のポイント
- リーダー選出は、分散システムで処理の取りまとめ役を一台自動的に選び、障害時は残りのノードで選び直す仕組みです。二相コミットやコンシステントハッシュ法とは異なる論点になります。
- データベースのプライマリ・レプリカ構成や分散ジョブのスケジューラ、クラスタの調停役など、性質の異なる基盤にまたがって使われています。
- ネットワーク分断でリーダーが二人並び立つスプリットブレインという落とし穴があり、過半数の合意やフェンシングで防ぐ考え方が要ります。発注・レビューの着眼点もあわせて整理します。
リーダー選出とは
リーダー選出とは、複数のサーバー（ノード）で動く分散システムの中から、処理の取りまとめ役となる一台を自動的に選び、その一台に障害が起きたら残りで選び直す仕組みです。
分散システムの中には、書き込みの順序を決めたり、ジョブの割り当てを調整したりする役割を、誰か一台が担う必要がある場面があります。取りまとめ役が固定で一台しかいないと、そのサーバーが止まった瞬間に処理全体が滞ってしまうでしょう。かといって複数のノードが同時に代表を名乗ってしまうと、それぞれが違う指示を出し、処理が競合してしまいます。
リーダー選出は、この二つの困りごとを同時に解く仕組みです。平常時は一台に取りまとめを任せて構成をシンプルに保ちつつ、そのサーバーが応答しなくなったときは、残ったノードの中から自動で新しい代表を選び直します。単一障害点（SPOF、システム全体を止めかねない一点の弱点）を避けながら、代表不在による処理の競合も防ぐというのが、基本の狙いになります。
この仕組みは、分散システムの合意（コンセンサス）を扱うアルゴリズムの一部として組み込まれている場合が少なくありません。RaftやPaxosといった名前を製品ドキュメントで見かけることもあるでしょう。いずれもノード間で「誰が正しい情報を持ち、誰が代表になるか」を過半数の賛成で決める考え方を土台にしており、リーダー選出はその応用場面のひとつに当たります。発注担当者が細かい計算式まで理解する必要はありませんが、可用性を語る際の共通言語として、名前だけでも知っておくとベンダーとの会話がかみ合いやすくなるでしょう。
なお、リーダー選出そのものにも代償があります。ノード間で合意を取り付けるやり取りが発生する分、選出や再選出の瞬間には、通常の処理より応答に時間がかかることがあるのです。導入すれば無条件に速く・止まりにくくなるわけではなく、コストとして受け入れる部分がある、という前提で構成を検討する視点が要ります。
次の章では、実際にどのような製品・場面でリーダー選出が使われているかを具体的に見ていきます。抽象的な仕組みの話だけでなく、名前の挙がる製品を押さえておくと、ベンダーの提案資料を読み解く際の助けになるはずです。
どんな場面で使うか
リーダー選出は、複数のノードが連携して動く基盤のあちこちで使われています。代表的な使いどころを見ていきましょう。
データベースのプライマリ・レプリカ構成では、書き込みを受け付ける一台（プライマリ）を決め、残り（レプリカ）は読み取り専用の役回りに回ります。プライマリに障害が起きると、レプリカの中から新しいプライマリを選び直し、書き込みの受け付けを引き継ぐ流れです。この構成は、読み取りアクセスをレプリカ側へ分散できる利点もあわせ持っています。ただし新しいプライマリを選ぶ際は、最新のデータを保持しているレプリカを優先しないと、選出直後にデータが失われる恐れがある点には注意が要ります。
分散ジョブのスケジューラでも、同じジョブを複数のノードが重複して実行しないよう、実行の指示役を一台に絞る場面があります。クラスタの調停役、たとえば設定情報を配る係や、ほかのコンポーネントの死活を管理する係を一台に決める場合にも、同じ考え方が使われるのです。夜間バッチのように、重複実行が二重出荷や二重送信といった実害につながりやすい処理ほど、この仕組みの有無が問われるでしょう。
具体的な製品名で見ると、イメージがつかみやすくなります。PostgreSQLのクラスタ構成をPatroniのようなツールで組む場合は、書き込みを担うプライマリの選出にetcdやConsulを使うのが一般的です。メッセージキューのKafkaでは、パーティションの割り当てを統括するコントローラーというノードが一台選ばれ、検索基盤のElasticsearchでは、クラスタ全体の状態を管理するマスターノードが選出されます。Kubernetesでも、制御コンポーネントを複数台で冗長化する構成において、現用系を一台に絞る目的でリース機構が使われているのです。
| システム例 | 選出の対象 | 主な用途 |
|---|---|---|
| PostgreSQL（Patroni構成） | 書き込みを担うプライマリ | 自動フェイルオーバーと書き込み経路の一本化 |
| Kafka | パーティション割り当てを統括するコントローラー | ブローカー間の役割調整 |
| Elasticsearch | クラスタ状態を管理するマスターノード | インデックス作成やシャード配置の決定 |
| Kubernetes | 制御コンポーネントの現用系 | 同一処理の重複実行を防ぐ調整 |
表からも分かるとおり、リーダー選出はデータベース・メッセージキュー・検索基盤・オーケストレーションと、性質の異なる基盤にまたがって使われています。裏を返せば、これらの製品を採用した時点で、リーダー選出のしくみはすでに構成へ組み込まれているとも言えるでしょう。発注担当者にとっては、新しく学ぶ概念というより、既に使っている基盤の内側で動いている仕組みを言語化する、という位置づけになります。
一方で、社内向けに複数拠点へバッチ処理サーバーを分散配置するような、既製の分散データベースに頼らない構成を組む場合は話が別です。この場合はリーダー選出を含む可用性の仕組みを自分たちで設計に組み込むかどうかを、要件定義の段階で判断する必要が出てきます。
仕組みの考え方
リーダー選出の中身は、大きく三つの要素で成り立っています。過半数（クォーラム）の合意、任期と再選、そしてハートビートによる死活確認です。
まず過半数の合意です。ノードが「自分がリーダーだ」と名乗るには、クラスタの半数を超えるノードから同意を取り付ける必要があります。過半数を条件にすることで、ネットワークが分断されても、リーダーを名乗れるのはどちらか一方の集団だけに絞られるのです。全ノードの一致（全会一致）を求めない理由は、応答が遅い一台や通信が届かない一台のせいで、いつまでも代表を決められなくなる事態を避けるためでしょう。過半数さえそろえば処理を先に進められる、という割り切りが、全体の応答性を支えています。
次に任期と再選です。リーダーには決められた任期（term）が与えられ、期限が切れる前にほかのノードへ生存を伝え続けます。伝達が途絶えると任期は失効し、新しい任期での選挙が始まります。
そしてハートビートによる死活確認です。リーダーは短い信号（ハートビート）を定期的に送り、生きていることをほかのノードへ知らせます。信号が届かなくなると、ほかのノードはリーダーの障害と判断し、新しいリーダーを選ぶ手続きに移るわけです。ハートビートの間隔をどう設定するかは、切り替えの早さと誤検知の少なさのどちらを重んじるかという、運用上の調整点になります。
クラスタの台数を3台・5台のように奇数でそろえる構成をよく見かけるのも、この過半数の考え方に関係しています。偶数台だと票が真っ二つに割れて過半数に達しないおそれがある一方、奇数台であれば票が割れてもどちらか一方が過半数を占められる仕組みになるからです。台数を増やすほど一部のノード故障には強くなりますが、そのぶん合意を取り付けるまでの通信量も増えるため、可用性と運用コストのバランスで台数を決めることになります。
| 観点 | リーダーあり構成 | リーダーなし構成 |
|---|---|---|
| 構成の単純さ | 書き込み経路が一本化され、設計をシンプルに保ちやすくなります。 | 全ノードが対等な分、調整ロジックが複雑になりがちです。 |
| データの一貫性 | リーダー経由で順序をそろえるため、一貫性を保ちやすくなります。 | 合意の取り方しだいで、一貫性の担保に工夫が要るところです。 |
| 単一障害点 | リーダー障害時は、選び直すまでの間に短い空白が生じます。 | 特定ノードへの依存はない一方、調整のやり取りが常時発生する点は変わりません。 |
| 構成変更のしやすさ | ノードの追加・削除時も、代表の切り替えだけで対応できる構成になりやすいです。 | 全ノードへ設定を行き渡らせる調整が、構成変更のたびに必要になります。 |
スプリットブレインという落とし穴
過半数の合意を条件にする理由は、スプリットブレインという事態を避けるためです。ネットワークが分断されると、片側のグループがリーダーを見失ったと判断し、それぞれの側で新しいリーダーを選んでしまうことがあります。名前のとおり、本来ひとつであるはずのクラスタの「脳」が、分断によって二つに割れてしまう状態を指す言葉です。
分断が回復したとき、二つのグループにそれぞれリーダーが存在していると、双方が別々に書き込みを受け付けていた場合、データが食い違ってしまう恐れがあります。取りまとめ役が二人並び立つこの状態こそが、スプリットブレインの怖さといえるでしょう。
これを防ぐ基本の考え方が、過半数の合意とフェンシングです。過半数を取れない側ではリーダーを名乗れないようにし、さらに旧リーダーが復帰した際に古い指示を実行させないよう締め出す仕組み（フェンシング）を組み合わせます。合意アルゴリズムそのものの細かな手順は製品ごとに異なるため、ここでは考え方の骨格にとどめておきます。
在庫管理システムが分断状態で二台とも注文を受け付けてしまうケースでは、同じ在庫を二重に引き当ててしまう恐れがあります。決済処理を分担するシステムで旧リーダーが復帰後も指示を出し続けるケースでは、二重の請求や二重の出荷指示を招くのです。フェンシングでは、旧リーダーの書き込み権限を無効化するトークンの差し替えや、共有ストレージへのアクセスを物理的に遮断する手段が組み合わされます。どの手段を採るにせよ、旧リーダーが「気づかないまま指示を出し続ける」状態を作らないことが、対策の核心になるでしょう。
書き込みだけでなく、読み取り側にも注意が要ります。分断中に取り残された旧リーダーへ問い合わせてしまうと、更新済みのはずのデータが古いまま返ってくる「古い読み取り」を招く恐れがあるのです。読み取りの正確さを求める処理では、現在のリーダーに確認を取ってから応答するなど、古い情報を返さないための工夫を組み合わせる必要があります。
発注・レビューで押さえる点
リーダー選出のしくみを一から設計する場面は限られており、既製のミドルウェアやマネージドサービスが備える機能を使うのが現実的な進め方です。とはいえ、機能を使うこと自体は難しくなくても、構成の当てはめ方や確認すべき論点を押さえておかないと、いざというときに想定と違う挙動に直面しかねません。発注やレビューの段階で確認しておきたい点を挙げます。
可用性要件を数値で握る
「リーダーが落ちても止めない」というだけでは、確認の基準になりません。年間でどれだけの停止を許容するか、復旧までの時間をどこまで許すかを、発注側とベンダーの双方で数値の形にしておく必要があります。社内向けの管理ツールと、顧客が直接使う決済系の画面とでは、許容できる停止時間の重みが異なるはずです。用途ごとに必要な水準を切り分けておくと、過剰な構成でコストをかけすぎる事態も避けやすくなります。
リーダー障害時の切り替え時間を確かめる
リーダーが交代するまでの間、処理が一時的に止まる、または受け付けられなくなる時間帯が生じます。この切り替え時間が業務にとって許容できる範囲かどうかを、設計段階で見積もっておくとよいでしょう。切り替え中に書き込みを止める設計か、それとも待たせる設計かによっても、業務への影響は変わってきます。
分断時の挙動を確認する
ネットワーク分断が起きた際に、どちらの集団を優先するか、書き込みを止めるのか継続するのかは、製品や設定によって挙動が異なります。想定する分断のパターンで実際にどう振る舞うかを導入前に確認しておくと、運用後の想定外を減らせるはずです。拠点間をまたぐ構成であれば、拠点間の回線が切れた状況を想定した確認も欠かせません。
監視・体制の役割分担を決めておく
リーダーの切り替えが起きたこと自体は、監視ツールのアラートで検知できるようにしておく必要があります。切り替えが頻発していないか、想定より時間がかかっていないかを定期的に振り返る役割を、誰が担うのかも決めておきたいところです。開発時点の設計だけでなく、リリース後の運用・保守までを見据えて体制を組んでおくと、切り替えの兆候を見落としにくくなります。頻繁な切り替えは、ネットワークの不安定さやハートビートの設定値が実態に合っていないサインである場合があり、原因を追う担当を決めておくと対応が早まるでしょう。
既製の仕組みに任せる選択肢
ZooKeeper、etcd、Kubernetesのリース機構など、リーダー選出を担う部品は公開されたミドルウェアとして提供されています。分散データベースやオーケストレーションツールも、この機能を内蔵している場合があるため、自前で合意アルゴリズムを組み上げる前に、既存の仕組みで足りるかを見極める視点が大切でしょう。自前実装と既製ミドルウェアの活用では、負う責任の範囲がこれだけ変わってきます。
| 観点 | 自前で合意アルゴリズムを実装 | 既製ミドルウェアを活用 |
|---|---|---|
| 開発工数 | 設計・実装・検証に相応の工数がかかります。 | 導入設定が中心となり、工数を抑えやすいのが特徴です。 |
| 障害対応 | 未知の不具合が本番で見つかるリスクを抱えます。 | 実績のある実装であり、既知の不具合情報も参照できるでしょう。 |
| 運用の見通し | 仕様変更や引き継ぎを自社で担う必要があります。 | 公式ドキュメントとコミュニティの知見が支えになるはずです。 |
発注側から見ると、既製ミドルウェアの活用は「枯れた実装に乗る」選択と言い換えられます。自前実装が向くのは、既存製品の仕様では業務要件を満たせない、限られた場面に絞られるでしょう。どちらを選ぶ場合も、採用理由と想定するリスクをレビューの場で言語化しておくと、後工程での手戻りを抑えられます。提案書の中で「リーダー選出は製品標準の機能を使う」と一行で片づけられている場合も、どの製品のどの機能を指しているのかまで確認しておくと、認識のずれを防げるはずです。
まとめ
- リーダー選出は、分散システムで処理の取りまとめ役を一台自動的に選び、障害時は残りのノードで選び直す仕組みである。
- データベースのプライマリ・レプリカ構成や分散ジョブのスケジューラ、クラスタの調停役など、性質の異なる基盤にまたがって使われている。
- 過半数の合意・任期と再選・ハートビートによる死活確認の三要素で成り立ち、選出には応答時間の代償もともなう。
- ネットワーク分断でリーダーが二人並び立つスプリットブレインを避けるため、過半数の合意とフェンシングを組み合わせる。
- 実装は既製のミドルウェアやマネージドサービスに任せ、発注側は可用性要件・切り替え時間・分断時の挙動・監視体制の四点を確認するのが基本となる。
よくある質問
導入にどのくらいの費用がかかりますか。
既製のミドルウェアやマネージドサービスの機能として組み込まれている場合は、追加のライセンス費用は基本的に発生しません。自前で構築する場合は、設計・実装・検証にかかる工数が費用の中心です。運用開始後も、監視や切り替え時間の見直しにかかる保守の工数を見込んでおく必要があります。まずは採用予定の製品がこの機能を内蔵しているかを確認するとよいでしょう。
リーダーの切り替えにはどのくらいの時間がかかりますか。
製品や設定によって幅があり、ハートビートの間隔や失効までの待ち時間の設定に左右されます。短く設定するほど切り替えは早まりますが、ネットワークの一時的な遅延を故障と誤認しやすくなる面もあるのです。業務への影響を踏まえて、値を調整していく必要があります。導入前の検証環境で、実際の切り替え時間を計測しておくと、本番での想定違いを防ぎやすくなります。
リーダー選出の設計はどの工程で確認すればよいですか。
要件定義や基本設計の段階で、可用性要件と切り替え時間の許容値を先に決めておくのが望ましい進め方です。実装後の見直しは手戻りが大きくなりやすいため、早い段階でベンダーとすり合わせておく必要があります。テスト工程では、実際にノードを止めて切り替わりを確かめる訓練も組み込んでおきたいところです。
スプリットブレインが起きるとどうなりますか。
分断が解消した後、どちらのリーダーの更新を正としてまとめるかによって、データの食い違いが残る恐れがあります。設計段階で、分断時にどちらの集団を優先するかのポリシーを決めておく姿勢が大切です。優先されなかった側で受け付けていた更新は、破棄されるか手作業での確認に回ることになるため、業務影響の切り分けもあわせて検討しておく必要があります。過半数の合意やフェンシングと合わせて確認しておきたい点です。
稼働中のシステムに後からリーダー選出の仕組みを追加できますか。
構成の見直しにはなりますが、稼働後の追加は選択肢としてあり得ます。既存のデータベースやジョブ基盤が、リーダー選出を備えたクラスタ構成へ切り替えられる作りかどうかを、まず製品仕様で確認する必要があります。切り替えの際は、移行中の一時的な停止や、データの整合性を確かめる手順もあわせて計画しておくとよいでしょう。段階的にレプリカを増やしてから切り替える進め方であれば、業務への影響を抑えやすくなります。
著者：テレリモ総研編集部 鈴木 亮佑
LASSICでは、国内ニアショア開発体制を活かし、分散システムの可用性設計やリーダー選出まわりのミドルウェア選定から実装、公開済みシステムの見直しまでを一貫して支援する体制です。要件定義の段階から実装、テスト、リリース後の運用・保守まで、工程を分けずに任せられる点も強みでしょう。可用性要件の整理から製品選定、切り替え時間の検証まで、担当を分断せずに進められることが、手戻りの少なさにつながります。リーダー障害時の切り替え設計やスプリットブレイン対策でお困りの際も、ご相談いただけます。
ご不明な点はお問い合わせフォームからもご連絡いただけます。
出典
- Wikipedia日本語版「リーダー選出」
- Apache ZooKeeper公式ドキュメント「ZooKeeper Recipes and Solutions（Leader Election）」
- Kubernetes公式ドキュメント「Coordinated Leader Election」
- etcd公式ドキュメント「Why etcd?」（Leader Election）
