クラスタ構成とは？Active-StandbyとActive-Activeの違いと選び方

インフラエンジニアとして実務に入ると、基本設計書や構成図で必ず目にするのが「クラスター（クラスタ）」や「冗長化構成」という言葉です。

• 「サーバーを2台並べているけれど、障害時に具体的にどう切り替わるのかイメージが湧かない」
• 「Active-StandbyとActive-Activeの違いや、実務での使い分け基準がよく分からない」
• 「設計レビューで先輩が話す『片肺運転のキャパシティ』や『フェイルバックのタイミング』についていけない」

こうした疑問を抱えたまま現場のレビューや障害訓練に臨むと、構成の意図が読み解けず、大きな不安を感じてしまうものです。

クラスタ技術は、システムの信頼性を担保するインフラ設計の骨格です。

この記事では、クラスタ技術の全体像（HA・負荷分散・HPC）を整理した上で、現場で最も設計力が問われる「HAクラスター」の2つの動作モード（Active-Standby / Active-Active）と、Active-Activeの2大実装パターン（負荷分散型 vs 相互待機型）を分かりやすく解説します。

さらに、教科書には載っていない「片肺運転時のサイジングの罠」や「現場で自動フェイルバックを禁止する理由」といった現場運用のリアルな勘所まで網羅しました。

この記事を読めば、設計書に書かれたパラメータの狙いが手に取るように理解でき、トラブルシューティングや設計レビューに自信を持って臨めるようになります。

【10秒でわかる】クラスタ動作モードのクイック比較

• Active-Standby（片系待機型）：1台稼働・1台待機。データの不整合が起きず最も安全。ただし待機機のコストが発生する。
• Active-Active（負荷分散型）：全台稼働。Webサーバーなどのステートレス（データを持たない）環境に最適。
• Active-Active（相互待機型）：別業務を並行稼働。リソース効率は高いが、片肺運転時のサイジング（平時CPU 50%以下）が必須。

※どの構成を選ぶべきかの判断手順は、記事後半の選定ステップで詳しく解説しています。

クラスター技術とは？目的別の3大分類（HA・負荷分散・HPC）

クラスター技術とは、複数台のサーバーをネットワークで結合し、外部からは全体で1台の巨大なシステムであるかのように振る舞わせる技術です。

なぜコストと構成の複雑さを増やしてまで、複数台のサーバーを束ねるのか。目的は大きく分けて「止まらないこと（可用性の向上）」と「速くさばくこと（処理性能の拡張）」の2点に集約されます。

この目的の違いによって、クラスタ技術は大きく3種類に大別されます。

クラスター種別	主な目的	システム要件	代表的な適用箇所	実現する主要技術
HAクラスター （High Availability）	可用性の向上 （耐障害・業務継続）	稼働率99.99%以上の維持 迅速な自動復旧	基幹データベース ファイルサーバー	クラスタ制御ソフト 共有ストレージ、VIP
負荷分散クラスター （Load Balancing）	処理性能の向上 （スケーラビリティ）	大量アクセスの均等分散 柔軟なスケールアウト	Webサーバー APIサーバー	ロードバランサー（L4/L7） リバースプロキシ
HPCクラスター （High Performance Computing）	演算処理の高速化 （並列計算）	膨大な数値計算の短時間処理	科学技術計算 気象予測、AIモデル学習	並列処理ライブラリ（MPI） 超高速インターコネクト

HA（高可用性）クラスター：システムの継続・耐障害性

システムの「稼働率」を高め、24時間365日止めないことを目指す構成です。

現場で単に「クラスタ構成」や「冗長化」と言う場合、大半はこのHAクラスターを指します。1台のサーバーにハードウェア故障やOSクラッシュが発生しても、待機している別のサーバーが自動で業務を引き継ぎ、ダウンタイムを最小限に抑えます。

負荷分散クラスター：大量アクセスの処理・拡張性

大量のトラフィック（アクセス）を複数台のサーバーに均等に割り振る構成です。

システムの入り口に「ロードバランサー（負荷分散装置）」を配置し、背後に並べたWebサーバー群へリクエストを分散させます。アクセス数が増加した際に、サーバーの台数を増やすことでシステム全体の処理能力を強化する「スケールアウト」が容易な点が特徴です。

HPC（高性能計算）クラスター：膨大な計算処理の高速化

いわゆる「スーパーコンピューター」の領域です。

多数の計算用サーバー（ノード）を専用の超高速ネットワークで繋ぎ、1つの巨大で複雑なタスクを細かく分割して並列実行させます。

インフラエンジニアの実務において、設計・運用の両面で最も深く関わり、設計力が問われるのが「HAクラスター」です。ここからは、HAクラスターの具体的な仕組みに焦点を絞って解説を進めます。

実務の基本「HAクラスター」とは？2つの動作モード（Active-Standby／Active-Active）

HAクラスターの設計で最初に決めるべきは、サーバーをどう待機させるかという「動作モード」です。

アプローチは大きく2つに分かれます。

1. Active-Standby（アクティブ／スタンバイ）構成：1台が業務を行い、もう1台は障害に備えて待機する（片系待機型）
2. Active-Active（アクティブ／アクティブ）構成：全サーバーが同時に業務を行い、障害時は相互に助け合う（並行稼働型）

それぞれの仕組み、メリット・デメリット、そして選定基準を詳しく見ていきましょう。

Active-Standby（アクティブ/スタンバイ）構成とは？仕組み・メリット・デメリット

Active-Standbyは、1台を「本番用」、もう1台を「障害時の予備用」として構える最も確実な冗長化構成です。

1台のサーバーを「Active（現用系・主系・本番機）」として稼働させて全リクエストを処理し、もう1台の「Standby（待機系・副系・予備機）」をバックアップ専用として待機させます。通常時、クライアントからのリクエストはすべてActiveサーバーだけで処理します。

• 通常時の挙動：クライアント ➜ サーバーA（Active：業務実行中）｜ サーバーB（Standby：待機中・業務処理なし）
• 障害時の挙動：サーバーAがダウン ➜ クラスタソフトが検知 ➜ サーバーBがActiveへ昇格し、業務を即座に引き継ぐ

メリットとデメリット

• メリット：データを書き込むサーバーが常に1台（Active）だけなので、データの衝突や不整合が原理的に起きません。設計、整合性の確認、障害時の原因究明が非常にシンプルです。
• デメリット：通常時はStandbyサーバーが業務処理を行わないため、リソース（CPU・メモリ）の利用効率という観点では「もったいない（投資対効果が低い）」と見なされることがあります。

【違いを比較】ホットスタンバイ・ウォームスタンバイ・コールドスタンバイの特徴とRTO

「待機」と一言で言っても、スタンバイサーバーをどのような状態で待たせておくかによって、「ホットスタンバイ」「ウォームスタンバイ」「コールドスタンバイ」3つの方式に分類することができます。

• ホットスタンバイ：クラスタ制御ソフトウェア（CLUSTERPROやLifeKeeperなど）が両ノード間で死活監視信号（ハートビート）を交わし、Activeのダウンを検知すると自動で仮想IP（VIP）とディスクを切り替えます。業務影響を極小化したい基幹系ではこれが標準です。
• ウォームスタンバイ：リソースを完全に遊ばせない工夫として、平時は待機系DBを「参照専用（Read-Only）」としてレポーティング業務に開放する構成などで採用されます。
• コールドスタンバイ：ハードウェア故障時に予備機へ部品を差し替える、あるいはクラウド上で停止していたインスタンスを立ち上げてバックアップからリストアする手法です。

設計書作成や見積もりで必須となる3つのレベルを、データの同期状態、復旧時間（RTO：目標復旧時間）と維持コストの視点を加えて整理しました。

比較項目	ホットスタンバイ（Hot Standby）	ウォームスタンバイ（Warm Standby）	コールドスタンバイ（Cold Standby）
待機側の状態	OS・ミドルウェア・アプリが常時起動	OSは起動、アプリは停止または参照専用	電源OFF、または別用途（検証等）で稼働
データの同期状態	リアルタイム同期（遅延ほぼゼロ）	準リアルタイム（定期ログ転送や差分同期）	非同期（定期バックアップデータのみ）
目標復旧時間（RTO）	数秒 〜 数十秒（自動切り替え）	数分 〜 数十分（手動またはスクリプト）	数時間 〜 数日（物理作業・リストア）
コスト	高（本番同等の待機機＋クラスタソフト）	中〜高（常時稼働分のインフラ費用）	低（予備機のハード代のみ、または共用）
主なユースケース	止まることが許されない基幹DB、EC決済	準基幹システム、参照専用（Read）活用環境	停止が許容される社内情報系、DR環境

【あわせて読みたい】待機系へのデータ引き継ぎはどう設計する？

Active-Standbyを採用するとき、現場の設計レビューで必ず突っ込まれるのが「障害時に待機系へどうやって最新データを引き継ぐのか？」というストレージ設計です。

2台から1つのストレージを見る「共有ディスク型」にするか、サーバー同士でデータを同期する「データミラー型」にするかで、構築コストや耐障害性は大きく変わります。

クラウド環境での適性も含めて比較したい方は、ぜひ以下の記事を参考にしてください。

Active-Active構成：リソースを無駄にしない攻めの設計

Active-Active構成は全サーバーが同時に稼働してリソースをフル活用する構成であり、Standbyのように遊んでいるサーバーが存在しないため、インフラの投資対効果（コスパ）を最大化できます。

ただし、実務におけるActive-Activeには仕組みも用途もまったく異なる「2つの実装パターン」があります。ここを混同して会話すると現場で必ず齟齬が生まれるため、明確に区別しておきましょう。

パターン1：負荷分散型（ロードバランサー連携）

フロントエンドにロードバランサーを配置し、後ろに並べた複数のサーバーへ均等にリクエストを振り分ける構成です。

• 得意な領域：主にWebサーバーやAPIサーバーなど、サーバー自身が更新データや状態を保持しない「ステートレス」なシステムに適用されます。
• 障害時の挙動：1台が故障した場合、ロードバランサーがヘルスチェックによって異常ノードを自動的に切り離します。残った正常なサーバー群でリクエストを継続処理するため、サービス停止時間は理論上ゼロです。

パターン2：相互待機型（クロススタンバイ）｜仕組みと片肺運転時のサイジング注意点

基幹システムやデータベースなど、サーバーが更新データを保持する「ステートフル」な環境で、リソースを無駄にしないために採用される構成です。

サーバーAとサーバーBが、それぞれ別々の業務のActiveを務めながら、同時に互いの待機系（Standby）を兼任します。

• 平常時の稼働状態：
  • サーバーA：業務①（人事システム）のActive ＋ 業務②（経理システム）のStandby
  • サーバーB：業務②（経理システム）のActive ＋ 業務①（人事システム）のStandby
• サーバーA障害時の挙動：
  • サーバーBが業務①の処理を引き継ぎ、1台のサーバー上で業務①と業務②の両方を集約して同時に実行（縮退運転）します。

【現場のリアル】相互待機型における「共倒れ（カスケード障害）」の恐怖

相互待機型は無駄のない合理的な構成に見えますが、サイジング（性能見積もり）を誤ると現場で最悪の障害を引き起こします。

1台がダウンした縮退運転時、残されたサーバーには2倍の負荷が集中します。

【現場で実際にあった失敗談】

平時のCPU使用率が60%前後で稼働していた相互待機型のシステムで、夜間に片系のサーバーがハード障害でダウンしました。

残ったもう片方のサーバーに全トラフィックが雪崩れ込んだ結果、瞬時にCPU使用率が100%に張り付き、メモリ枯渇によるOOM Killerが多発。結果として残った正常なサーバーまでクラッシュし、深夜に2つの基幹業務が同時に全停止する二重障害に至りました。

相互待機型を設計する際は、「片肺運転時でもシステム全体の業務が破綻しないか」を厳密に計算し、平常時のリソース使用率上限を40〜50%以下に抑えるキャパシティ設計が絶対条件となります。

【早見表】Active-StandbyとActive-Activeの違い・使い分けの比較表

実務で検討される主要な3つのHAクラスタパターンを一覧表で比較しました。設計レビューや要件定義の判断材料として活用してください。

比較項目	Active-Standby（ホットスタンバイ）	Active-Active（負荷分散型）	Active-Active（相互待機型）
主な用途	データベース、基幹システム	Webサーバー、APIサーバー	複数業務を相乗りさせるDB/AP
フェイルオーバー時間	数秒 〜 数十秒	実質ゼロ（LBによる切り離し）	数秒 〜 数十秒
平時のリソース効率	✕（待機機がアイドル状態）	◎（全ノードをフル活用）	◯（別業務で全ノードを活用）
障害時の性能影響	変化なし（100%の処理能力維持）	性能低下（台数減による処理能力低下）	著しい性能低下のリスクあり
設計・構築の難易度	標準的	比較的容易（疎結合）	極めて高い（リソース競合・排他制御）
コスト構造	待機機分のハード・ライセンスが必要	スケールに応じた柔軟な投資が可能	高（設計検証工数、ソフトライセンス）

現場リーダーが教える「フェイルオーバー」運用の勘所

HAクラスタの運用において最も重要なのは、障害発生時の切り替えではなく「復旧後の切り戻しルール」です。

現場のサービスマネージャーや運用リーダーが最も気をつけている運用のポイントを紹介します。

1. なぜ現場では「自動フェイルバック」が原則禁止なのか？

障害発生時にActiveからStandbyへ業務を切り替える処理を「フェイルオーバー」と呼びますが、逆に障害機が修理・復旧した際に元の系へ業務を戻す処理を「フェイルバック（切り戻し）」と呼びます。

市販のクラスタソフトには「障害機が復帰したら自動で元の状態へ戻す（自動フェイルバック）」機能が用意されていることが多いですが、エンタープライズの現場では基本的にこの機能を無効化（手動切り戻し）します。

仮に自動フェイルバックを有効にしていると、壊れかけのハードウェアが原因で「フラッピング（切り替えの無限ループ）」が発生するためです。

1. サーバーAでハードウェアの瞬断やメモリの接触不良が発生し、ダウンする。
2. サーバーBへ安全にフェイルオーバーし、業務が正常に引き継がれる。
3. サーバーAが中途半端に自己再起動を遂げ、クラスタに「復帰した」と通知する。
4. クラスタソフトが通知を受け、本番業務の真っ最中にサーバーAへ自動で切り戻しを開始してしまう。
5. サーバーAの根本原因が直っていないため、再昇格直後に再びクラッシュする。

短時間に業務停止と切り替えが繰り返されると、データベースの不整合やトランザクションの破壊を招き、目も当てられない事態になります。

【運用の鉄則】

フェイルオーバーは業務継続のために自動で素早く行う。ただし、フェイルバック（切り戻し）は原因究明とハードウェア交換を完全に終えた後、利用者の少ない夜間や休日に計画停止を設けて手動で行う。これが運用設計のセオリーです。

2. クラスタ設計最大の悪夢「スプリットブレイン」とは？

HAクラスタ運用において、インフラエンジニアが最も恐れる致命的な障害が「スプリットブレイン（Split-Brain）」です。

2台のサーバーを結ぶ監視用の通信線（ハートビート線）が断線すると、Standby側は「相手の信号が途絶えた＝Active側が死んだ」と判断して、自身をActiveへ昇格させようとします。しかし、元のActive側も正常に動き続けています。

その結果、「1つのシステムの中に2台のActive（主系）が同時に存在し、両者がストレージの同じデータ領域に異なる内容を書き込んでデータを完全に破壊する」という大惨事に発展します。

現場では、このスプリットブレインを絶対に防ぐために「クォーラム（多数決判定）」や「フェンシング（相手ノードの電源を物理的に強制遮断する仕組み）」といった防衛機構を必ず組み込みます。

【あわせて読みたい】現場が最も恐れる「データ破壊事故」を防ぐには？

死活監視が切れた際、クラスタはどちらを本物と判定するのか？

両ノードが暴走してデータを壊し合う「スプリットブレイン」の発生メカニズムと、それを防ぐQuorum（多数決判定）やSTONITH（フェンシング）の仕組みについては、以下の記事でシーケンス図を交えて徹底解説しています。

クラウド時代（AWS / Azure）におけるクラスタ技術の現在地

クラウドの普及によって構成手順は変わりましたが、冗長化の設計思想そのものは今も変わっていません。

「AWSやAzureを使えば、もうActive-Standbyのような泥臭い設計は不要になるのでは？」と考える方もいるかもしれません。しかし、実際はインフラエンジニアが手動で組んでいた仕組みが、クラウド事業者のマネージドサービスとして抽象化・自動化されただけです。

• マネージドサービスの裏側（例：Amazon RDS Multi-AZ）
  オンプレミスで構築していた「ホットスタンバイ型のActive-Standby」は、クラウドでは設定1つで実現できます。プライマリDBへの書き込みは別のアベイラビリティゾーン（AZ）のスタンバイDBへ同期レプリケーションされ、障害時はDNSルーティングが自動で切り替わります。
• クラウド上でクラスタソフトを組むケース
  既存の商用パッケージ（SAPや特定パッケージ製品）をオンプレミスからそのままクラウドへ移行（リホスト）する場合や、マネージドサービスでは満たせない「数秒以内の極小RTO」を求める要件では、AWS EC2やAzure VMの上にCLUSTERPROなどのクラスタソフトを導入します。クラウド環境では共有ディスクの制約が多いため、「データミラー型」の構成が多く採用されます。

マネージドサービスの裏側で何が起きているのかを正しく見抜き、障害発生時に「ネットワーク・ディスク・プロセスのどこで問題が起きているのか」を切り分けるためにも、クラスタの基礎原理を理解しておくことが不可欠です。

要件定義書から最適なクラスタ構成を選ぶ3ステップ

クラスタ構成の選定は、最新技術を追うことではなく「業務要件（RTO/RPO）と予算のバランスを最適化すること」です。

実務で構成に迷った際は、以下の3ステップで検討を進めてください。

1. システムの性質を見極める
   • Web/APIなど状態を持たない（ステートレス） ➜ 負荷分散型 Active-Active
   • DBやファイル共有などデータを保持・更新する（ステートフル） ➜ ステップ2へ
2. 許容復旧時間（RTO）と予算を照合する
   • 停止時間「数秒以内」＆ 予算あり ➜ Active-Standby（ホットスタンバイ）
   • 停止時間「数分〜数十分」＆ 参照活用したい ➜ Active-Standby（ウォームスタンバイ）
   • 停止時間「数時間〜数日」＆ コスト最優先 ➜ Active-Standby（コールドスタンバイ）
3. リソース効率と運用のリスクを判定する
   • 障害時でも100%の処理能力を維持したい ➜ Active-Standby
   • 複数業務をまとめつつ平常時の無駄を省きたい ➜ Active-Active（相互待機型）
     • ※ただし、平時のリソース使用率を50%以下に抑えるサイジングが必須

よくある質問（FAQ）

Active-StandbyとActive-Activeの決定的な違いは何ですか？

平常時に「待機しているサーバーがあるか、全台が業務処理を行っているか」が最大の違いです。Active-Standbyはデータ整合性が保ちやすく安全ですが待機機のリソースが遊ぶデメリットがあります。Active-Activeはリソース効率が高い反面、障害時のサイジングや整合性制御が複雑になります。

なぜ相互待機型のActive-Activeでは、平時のCPU使用率を50%以下にする必要があるのですか？

片方のサーバーが故障した際、生き残ったサーバーが両方の業務を同時に引き受ける（片肺運転）ためです。平時に50%を超えていると、片系運転時にCPU使用率が100%に達して共倒れ（カスケード障害）を引き起こし、システム全体が全滅してしまいます。

障害から復旧したサーバーへ、なぜ自動でフェイルバックさせてはいけないのですか？

復旧直後のサーバーが本当に健全か確認できていない段階で切り戻すと、再度障害を起こして切り替えループに陥る恐れがあるためです。また、フェイルバック時にも一時的なサービス瞬断が発生するため、現場では利用者のいないメンテナンス時間帯に手動で切り戻すのが鉄則です。

まとめ：クラスタ設計の実務力をさらに高めるために

クラスタの動作モードを理解したら、次は「データの持ち方（ストレージ）」と「異常時の防衛策」の2つを押さえることで、実務の設計書を完全に読み解けるようになります。

現場で活躍できるプロフェッショナルを目指す方は、ぜひ以下のステップで学びを深めてみてください。

まずは自社で運用しているシステム構成図を開き、稼働しているサーバー群が「どのクラスタ型に該当し、どんなパラメータで設計されているか」を照らし合わせることから始めてみてください。