【HAクラスタ設計】スプリットブレインとは？データ崩壊を防ぐクォーラム・フェンシングの基本と対策

インフラエンジニアとして実務に入り、サーバーの冗長化（HAクラスタ）構成を設計・構築して、「これで万が一の障害時も安心だ！」と胸を張っていませんか？

しかし、基本設計や詳細設計のレビューの場で、シニアエンジニアからこう突っ込まれたことはないでしょうか。

「これ、クラスタ間のハートビートネットワークが切れたらどうなるの？」

この質問に明確に答えられないと、システムのデータを一瞬で崩壊させる致命的な罠を見落とすことになります。HAクラスタを運用する上で最も恐ろしく、かつ設計者の腕が試される最大の難所。その正式名称を「スプリットブレインシンドローム（Split-Brain Syndrome）」と呼びます。

今回は、単に「スプリットブレイン」と略されることが多いこの現象について、言葉の由来から発生メカニズム、データの持ち方ごとの致命的な影響、そして設計レビューを突破するために必須となる「クォーラム」と「フェンシング」の実践的な設計技術までを徹底解説します。

クラスター技術の基礎、クラスターにおけるデータ保持の方法などが知りたい方は、以下の記事を確認してみてください。

スプリットブレイン（シンドローム）とは？HAクラスタにおける定義

まず、この名前の定義と由来から紐解いていきましょう。

言葉の由来：医学・脳科学の「分離脳」から

「スプリットブレイン（分離脳）」は、元々は医学・脳科学の用語です。てんかんの治療などの目的で、右脳と左脳をつなぐ「脳梁（のうりょう）」を切断した結果、左右の脳が互いに情報を共有できなくなり、それぞれが独立した意思を持って勝手に行動してしまう症状（分離脳症候群）から名付けられました。

ITインフラにおける状態：1つのシステムに2つの「脳（Active）」

これをITインフラ、特にHAクラスタに当てはめたのが「スプリットブレインシンドローム」です。

クラスタを構成するサーバー（ノード）間で、お互いの生存を確認し合う通信（ハートビート）が断絶した結果、システム全体をコントロールする「脳（意思決定主体）」が2つ同時に存在してしまう状態を指します。

インフラエンジニアが認識すべきなのは、これが単なる「通信障害」ではなく、システムが「アイデンティティの崩壊（どちらが本物の主系（Active）か分からない状態）」に陥る深刻な症候群（シンドローム）であるという点です。

なぜ起きる？スプリットブレインの主な発生原因とメカニズム

スプリットブレインシンドロームの主原因は、サーバー自体の故障ではありません。そのほとんどが「インターコネクト（クラスタ間ネットワーク）の障害」によって引き起こされます。

• クラスタスイッチの物理的な故障やフリーズ
• メンテナンス時のLANケーブル誤抜
• ネットワークの瞬間的な高負荷（帯域逼迫によるハートビートのタイムアウト）

ノードが陥るジレンマ：「相手の死」か「自分の孤立」か

ハートビートが途絶したとき、待機系（Standby）のノードは次のジレンマに直面します。

「主系（Active）からの応答が消えた。主系が本当に『死んだ（システム停止）』のか、それとも自分の耳が『聞こえない（ネットワーク遮断）』だけなのか？」

ノード自身には、相手が死んでいるのか、それともネットワークの向こうで元気に動いているのかを外から判断する術がありません。

HAクラスタの基本動作として、待機系は「相手が死んだ」とみなして自らをActiveに昇格させようとします。この結果、元々のActiveと、新しく昇格したActiveの「2つの脳」が同時に誕生してしまうのです。

【データの持ち方別】スプリットブレインがもたらす致命的な影響

2つのノードが同時に「自分がActiveだ」と思い込むと、何が起きるのでしょうか。前回の記事（データの持ち方比較）で解説した構成パターンによって被害の形は異なりますが、どちらにしても結末は「データの崩壊」です。

1. 共有ディスク型：ファイルシステムの即時クラッシュ（データ破損）

外部ストレージ（SAN/NASなど）を共有している構成では、悲劇は一瞬で訪れます。

通常、共有ディスクのファイルシステムは1つのノードだけが書き込むことを前提に設計されています（排他制御）。しかし、スプリットブレイン状態になると、両方のノードが1つのファイルシステムに対して同時に、かつ無秩序に書き込みを開始します。

結果として、メモリキャッシュの不整合やメタデータの破壊が起き、ファイルシステム自体が完全にクラッシュ（データ破損）します。OSからディスクが認識できなくなり、最悪の場合は二度と復旧できないレベルでデータが失われます。

2. レプリケーション型：データの分岐と泥沼の競合（コンフリクト）

各ノードが独立したディスクを持ち、リアルタイム同期している構成では、一見ディスクの衝突は起きないように見えます。

しかし、スプリットブレイン状態になると、双方が独立して別々のデータを自分のローカルディスクに書き込み始めます（データの分岐）。

その後、ネットワークが復旧した瞬間にクラスタはパニックに陥ります。「どちらのデータが正しい歴史なのか」が分からなくなるためです。これを「データの先祖返り」や「競合（コンフリクト）」と呼び、これを救済するには気の遠くなるような手動でのデータ整合チェック（泥沼の復旧作業）が必要になります。

スプリットブレインを未然に防ぐ2大設計対策

この恐ろしい症候群を防ぐため、HAクラスタの設計では必ず次の2つのアプローチ（またはその組み合わせ）を実装します。設計レビューで最も重視されるポイントです。

対策① 多数決の論理「クォーラム（Quorum）」とタイブレーク回避

1つ目の対策は、システムに「過半数の合意」というルールを持ち込むことです。クラスタ全体の投票権（Vote）の過半数を得たグループだけがActiveを継続でき、過半数に満たない孤立したノードは自らサービスを停止（自殺）します。

• 2ノードクラスタの壁：サーバー2台（ノードA、ノードB）の構成だと、分断されたときに「1票 vs 1票」となり、どちらも過半数（2ノード時のマジョリティ＝2票以上）を取れず、タイブレーク（同点）になってしまいます。
• 解決策（ウィットネス / 投票ディスク）：このタイブレークを解消するために、3つ目の要素として「ウィットネス（目撃者）ノード」や「クォーラムディスク（共有ストレージ上の特定領域）」に1票の投票権を与えます。これにより、「ノードA ＋ ウィットネス」で2票を獲得した側が生き残り、孤立したノードB（1票）はサービスを引き継がない、という綺麗な多数決が成立します。

対策② 強制排除の論理「フェンシング（Fencing）」とSTONITH

クォーラムが「話し合い（多数決）による自衛」であるのに対し、フェンシングは「物理的な隔離・排除」です。スプリットブレインの兆候を検知した瞬間、データの破損を防ぐために、相手をクラスタから文字通りシャットアウトします。

• STONITH（Shoot The Other Node In The Head）：直訳すると「相手ノードの脳天を撃ち抜け」。非常に過激な名前ですが、実務では定番の技術です。サーバーの管理チップ（IPMI、iLO、iDRACなど）やインテリジェントPDU（電源タップ）を経由して、相手サーバーの電源を強制的に切断（Power off）します。「生かしておくから不整合が起きる。怪しい奴はまず殺せ」という、データ保護を最優先した冷徹な思想です。
• I/Oフェンシング：共有ディスク（SAN）の予約ロック機能（SCSI-3 Persistent Reservationなど）を利用し、相手ノードからのディスクアクセス要求をストレージ側で即座に拒否・ブロックする手法です。

【現代の視点】クラウド環境（AWS/Azure）におけるスプリットブレイン対策

オンプレミスで培われた「ハードウェアの電源を物理的に落とす（STONITH）」や「SCSI予約によるディスクロック」といった手法は、AWSやAzureなどのクラウド環境ではそのまま使えません。物理レイヤーが隠蔽されているためです。

では、現代のクラウド設計ではどうしているのでしょうか？

API連携によるインスタンスの強制停止（クラウド版STONITH）

現在の主流は、「クラウドプロバイダーのAPIを利用したフェンシング」です。

例えば、ハートビートが途絶した際、クラスタソフトウェア（Pacemakerなど）がクラウドのAPI（AWS CLIなど）を呼び出し、相手の仮想マシン（EC2インスタンスなど）に対して StopInstances や TerminateInstances を発行します。

API経由で強制的にインスタンスを停止させることで、オンプレミスのSTONITHと同じ効果を実現しています。

マルチAZ構成におけるウィットネスの配置パターン

また、マルチAZ（可用性ゾーン）構成をとる場合、AZ間のネットワーク分断（滅多に起きませんが）に備え、3つ目のAZにクォーラム用の小さなインスタンス（ウィットネス）を配置する設計が定石となっています。

まとめ：設計レビューを突破するための実務チェックリスト

冗長化構成において、スプリットブレインシンドロームへの対策が抜けている設計書は、穴の空いたバケツと同じです。次の案件の基本設計・詳細設計フェーズでは、以下のチェックリストを基に、設計に漏れがないか確認してください。

確認項目	考慮すべき設計内容
ハートビートの冗長化	LANカード（NIC）やスイッチを物理的に分け、複数経路のハートビートを持たせているか？（最低2系統、可能であれば3系統）
奇数ノードの確保（多数決）	2ノード構成の場合、タイブレークを防ぐためのウィットネスノードやクォーラムディスクを適切に配置したか？
フェンシングの確実性	万が一の際、相手を確実に「隔離・シャットダウン」する手段はあるか？クラウド環境であれば、必要なAPI実行権限（IAMポリシー等）や通信経路が確保されているか？

ただサーバーを2台並べるだけなら誰でもできます。しかし、「万が一ネットワークが引き裂かれたとき、システムとデータをどうやって自衛させるか」までをロジカルに作り込めてこそ、一人前のインフラエンジニアです。

スプリットブレインシンドロームのメカニズムと対策を正しく理解し、設計レビューで先輩エンジニアを唸らせる堅牢なクラスタ設計を目指しましょう！