リーダー選出とスプリットブレイン回避

リーダー選出は何のためにあるか

分散システムの多くは、ある仕事をちょうど1つのノードだけに担わせたい場面を持ちます。複製の書き込みを受け付けるプライマリ、ジョブを発行するスケジューラ、分散ロックの所有者などです。複数ノードが同時にその役割を担うと、書き込みの二重適用やデータ破壊が起きます。そこで**リーダー選出（leader election）**を行い、生きているノードの中から1つをリーダーに選びます。

問題は選出そのものより、「リーダーはどの瞬間も高々1人」という不変条件を維持し続けることにあります。選出は一瞬で終わりますが、その後ネットワークが乱れたりノードが固まったりすると、システムが「リーダーは複数いる」と誤認しうる。この破綻状態が**スプリットブレイン（split-brain）**です。

なぜスプリットブレインが起きるのか

根本原因は、FLP不可能性定理が示す通り、非同期な世界では**「故障したノード」と「単に遅いノード」を区別できない**ことです。

リーダーAが応答を返さないとき、他ノードはAがクラッシュしたのか、GC（ガベージコレクション）ポーズで固まっているだけなのか、ネットワークが詰まっているだけなのかを判定できません。やむを得ずタイムアウトで「Aは死んだ」とみなし、Bを新リーダーに選ぶ。ところが実際にはAは生きていて、ポーズから復帰した瞬間、自分がまだリーダーだと信じたまま書き込みを再開する。この瞬間、AとBという2人のリーダーが並立します。

時刻 t0: A がリーダー。書き込みを処理中
時刻 t1: A が長いGCポーズに入る（プロセスは生きているが応答しない）
時刻 t2: 他ノードがタイムアウト判定 → B を新リーダーに選出
時刻 t3: B がリーダーとして書き込みを開始
時刻 t4: A がポーズから復帰。自分の失効を知らず write を再開
        → A と B が同時にストレージへ書き込む（スプリットブレイン）

ここで効くのがフェイルストップではない現実です。プロセスは「きれいに死ぬ」とは限らず、固まる・遅れる・分断される。だから「応答がない＝安全に役割を剥奪してよい」とは言い切れません。

なぜ「単なるロック」では不十分か

素朴な対策は分散ロックです。リーダーになりたいノードがロックサービス（etcd・ZooKeeper・Redis 等）から排他ロックを取り、取れた者がリーダーになる。しかしロックには**有効期限（リース）**が要ります。期限がなければ、ロック保持者がクラッシュした瞬間ロックが永久に解放されず、誰もリーダーになれないからです。

そこで「TTL付きリース」を使う。一定時間ごとに更新（lease renewal）し、更新が途絶えたらリースは満了し、別ノードが取得できる。ところがこれにも穴があります。

つまりリースは「いつ役割を手放すか」を保持者の自己申告に委ねており、保持者が固まると保証が崩れます。ロックを取ったかどうかの判定（取得時点）は守れても、**取った後の有効性（書き込み時点）**は守れません。ここが核心です。

フェンシングトークン：書き込み側で止める

解決策は、ロックの取得時ではなく実際の書き込み時に有効性を検査することです。鍵が**フェンシングトークン（fencing token）**です。

ロックサービスは、ロックを付与するたびに単調増加する整数を一緒に発行します。これがフェンシングトークンであり、リーダーの世代を表す**エポック番号（epoch number / term）**と本質的に同じものです。リーダーがストレージへ書き込むときは、必ずこのトークンを添えます。ストレージ側は、過去に受理した最大トークンより小さいトークンの書き込みを拒否します。

# ロックサービスが付与するトークンは取得のたびに必ず増える
A がロック取得 → token = 33
（A がGCポーズ）
B がロック取得 → token = 34   # 必ず A の 33 より大きい

# ストレージ側の検査
B が write(token=34) → 受理。ストレージは last_token = 34 を記憶
A が復帰し write(token=33) → 33 < 34 なので拒否（フェンスされる）

旧リーダーAは生きていても、トークンが古いために書き込みそのものを跳ね返される。Aが自分の失効に気づく必要はなく、ストレージが機械的に弾きます。これが「フェンシング（柵で囲って締め出す）」の意味です。

決定的に重要なのは、トークンを検査する主体がストレージ（書き込みを受ける側）でなければならない点です。リーダー自身に「自分は失効したか」を尋ねても、固まっているリーダーは正しく答えられません。判定を、止まりうる当事者から、書き込みを実際に受け取る側へ移す——これがフェンシングの本質です。

クォーラム：トークンの一意性と選出の整合性を担保する

フェンシングが効くには、トークンが全体で一意かつ単調でなければなりません。これを保証するのが**クォーラム（quorum、過半数）**です。

リーダー選出やトークン発行を単一ノードに任せると、そのノードが分断の両側に対して別々のリーダーとトークンを発行しかねません。そこで「N 台中、過半数 ⌊N/2⌋+1 台の合意がなければ選出もトークン発行も成立しない」と決めます。過半数同士は必ず1台以上重なるため、分断された2つのグループが同時に過半数を集めることは不可能です。よって同時に2人のリーダーが正規に選出されることはありません。

クォーラムは、ノード数を奇数にすると効率的です。偶数だと分断で同数に割れ、どちらも過半数を取れず全体が停止しうる。3台なら1台、5台なら2台の故障まで耐えつつ、残りで過半数を維持できます。なお、クォーラムの一意性は整合性モデルでいう線形化可能なリーダー選出を支える土台でもあります。

STONITH：トークンを検査できない相手をどう黙らせるか

フェンシングトークンは強力ですが、ストレージ側がトークン検査を実装していることが前提です。検査できないリソースが相手だと使えません。典型例が、共有ディスクや共有ストレージを直接マウントする旧来のHAクラスタ、あるいはトークンを理解しないネットワーク機器です。

このとき使うのがSTONITH（Shoot The Other Node In The Head）——疑わしい旧ノードを物理的・確実に停止させる手法です。具体的には、電源制御装置（PDU）で旧ノードの電源を切る、IPMI/iLO/iDRAC などのBMCでハードリセットをかける、SANのゾーニングでストレージアクセスを遮断する（ストレージフェンシング）などです。新リーダーは、旧ノードが確実に止まったことを確認してからリソースを引き継ぎます。

時計を信用しすぎない

リースやタイムアウトはノードの時計に依存しますが、論理時計と happens-before が示す通り、分散環境で物理時計の同期は完全ではありません。NTPのずれ、VMのスケジューリング遅延、長いGCポーズにより、あるノードの「まだ期限内」と別ノードの「もう期限切れ」が食い違います。だからこそ、相互排他の最終的な正しさを時間の経過ではなく、単調増加するトークンの大小という時計に依存しない順序づけに委ねるのが堅牢です。トークンは「絶対時刻」ではなく「世代の前後関係」だけを語るため、時計のずれに影響されません。

この区別不能性は机上の話ではありません。カオスエンジニアリングでプロセス一時停止やネットワーク分断を注入すると、リースだけの構成が二重書き込みを起こし、フェンシングトークンを足した構成がそれを弾く様子を実地で確認できます。

まとめ

• スプリットブレインは「リーダーは高々1人」という不変条件が破れ、複数ノードが同時に書き込む状態。根因は故障と遅延を区別できないこと。
• 単なるロックやTTLリースでは不十分。リースの満了判定が保持者の時計に依存し、GCポーズや遅延で旧リーダーが失効に気づかず書き続けるため。
• 決定打はフェンシングトークン（エポック番号）。単調増加するトークンを書き込みに添え、ストレージ側が古いトークンを拒否する。判定を、止まりうる当事者から書き込みを受ける側へ移すのが核心。
• クォーラム（過半数）がトークンの一意性と二重選出の防止を担保し、トークンを検査できない相手にはSTONITHで物理的に旧ノードを停止させる。
• 相互排他の正しさは時間の経過ではなく単調なトークン順序に委ねるのが堅牢。時計のずれに影響されないからである。