インフラのクラスター技術とは？Active-StandbyとActive-Activeの違い・実装パターンを徹底解説

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

「サーバーを複数台並べるのはわかるけれど、具体的にどう連携しているの？」 「Active-StandbyとActive-Activeって、どう使い分ければいいの？Active-Activeにも実装パターンがあるって本当？」

こうした疑問を抱えたまま運用や設計レビューに臨むと、先輩エンジニアたちの会話についていけず、悔しい思いをすることもあります。

この記事では、まず「クラスター」という技術の全体像を3つの主要なタイプ（HA、負荷分散、HPC）に分類して解説します。その上で、若手エンジニアが実務で最も直面し、設計力が問われる「HAクラスタ技術」に焦点を当て、2つの動作モード（Active-Standby / Active-Active）と、Active-Activeにおける深掘り2実装パターン（負荷分散型 vs 相互待機型）、そして選定の基準まで、教科書的に詳しく解説します。

この記事を読めば、実務の設計書が読めるようになり、先輩とのトラブルシューティングの会話に自信を持ってついていけるようになるはずです。

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

クラスター（Cluster）とは、英語で「ブドウの房」や「集団」を意味する言葉です。ITの世界においては、「複数台のサーバーをネットワークで結合し、外部からは全体で1台の巨大なシステムであるかのように振る舞わせる技術」を指します。

なぜ、わざわざ高コストをかけて複数台のサーバーを1つにまとめるのでしょうか。目的は大きく分けて2つあります。

• 可用性の向上（システムを止めない）： 1台が故障しても、他のサーバーが処理を引き継ぐ。
• 性能の拡張（処理能力を高める）： 1台の限界を超えた大量のアクセスや膨大な計算を、複数台で分担する。

そして、この目的の違いによって、クラスター技術は大きく3つのタイプに分類されます。それぞれの活躍場所を整理しましょう。

クラスターの種類	主な目的	主な活躍場所	代表的なキーワード
HA（高可用性）	システムの継続・耐障害性	データベース、ファイルサーバー	Active/Standby、フェイルオーバー
負荷分散	大量アクセスの処理・拡張性	Webサーバー、APIサーバー	ロードバランサー、スケールアウト
HPC（高性能計算）	膨大な計算処理の高速化	科学技術計算、AI・データ解析	並列処理、計算ノード

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

システムの「稼働率」を高め、24時間365日止めないことを目指す構成です。現場で「クラスタによる冗長化」と言う場合、大半はこのHAクラスターを指します。基幹システムのデータベース（DB）やファイルサーバーなど、データの整合性と継続性が厳格に求められる場所に適用されます。

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

大量のトラフィック（アクセス）を複数台のサーバーに均等に割り振る構成です。システムの入り口に「ロードバランサー（負荷分散装置）」を配置し、後ろに控えるWebサーバー群にリクエストを分散させます。アクセス数が増加した際に、サーバーの台数を増やすことでシステム全体の能力を増強する「スケールアウト」が容易な点が特徴です。

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

いわゆる「スーパーコンピューター」の領域です。多数 of 計算用サーバー（ノード）を高速なネットワークで繋ぎ、1つの巨大なタスクを並列で処理させます。気象予測や流体シミュレーションなど、圧倒的な計算パワーが必要とされる研究・開発分野で利用されます。

ここまでの解説で、クラスター全体の分類をご理解いただけたかと思います。ここから先は、インフラ設計の基本であり、若手エンジニアの心臓部となる「HA（高可用性）クラスター」に焦点を絞って、その深い実装パターンを解説していきます。

実務の主役「HAクラスター」による冗長化構成と動作モード

実務で触れる機会が圧倒的に多い「HAクラスター」を設計・運用する上で、構成するサーバーをどのように稼働させるかという「動作モード」の決定は極めて重要です。これには大きく分けて、「Active-Standby構成」と「Active-Active構成」の2つの主要なアプローチがあります。

Active-Standby（アクティブ/スタンバイ）構成

1台のサーバーを「Active（現用系・主系）」として実際にサービスを提供させ、もう1台を「Standby（待機系・副系）」として万が一の障害に備えて待機させておく構成です。通常時、ユーザーからのリクエストはすべてActiveサーバーだけで処理します。

Active-Standby構成のメリットとデメリット

• メリット： データを書き込むサーバーが常に1台（Active）だけなので、データの衝突や不整合が起きにくく、設計やトラブルシューティングがシンプルです。
• デメリット： 通常時はStandbyサーバーが何も処理をしないため、コスト効率（投資対効果）の面で非効率と見なされることがあります。

スタンバイ（待機状態）における3つのレベル

「待機」と一言で言っても、スタンバイサーバーをどのような状態で待たせておくかによって、システムの復旧スピードやコストが劇的に変わります。実務の設計書を読み解く上で絶対に知っておくべき3つのレベルを解説します。

① ホットスタンバイ（Hot Standby）

• 状態： スタンバイ側のサーバーもOS、ミドルウェア、アプリケーションのすべてが「起動状態」で待機します。
• データの同期： Active側と常にリアルタイムでデータを同期（レプリケーションや共有ディスクの制御）しています。
• 切り替え時間： 数秒〜数十秒。HAクラスタソフトがActiveの死活監視を行い、異常を検知すると自動でIPアドレスやリソースを引き継ぐ（フェイルオーバー）ため、ユーザーはほぼダウンタイムを感じません。
• 実務でのユースケース： 止めることが許されない基幹データベースやコアネットワークの冗長化。実務のHAクラスタソフト（CLUSTERPROやLifeKeeperなど）を導入する際は、このホットスタンバイが基本路線となります。

② ウォームスタンバイ（Warm Standby）

• 状態： スタンバイ側のサーバーのOSは起動していますが、アプリケーションや一部のサービスは「停止状態」、あるいは参照専用などの制限付きで待機します。
• データの同期： 定期的なバッチ処理やログ転送など、準リアルタイム（数分〜数時間の間隔）で同期を行います。
• 切り替え時間： 数分〜数十分。障害発生時、データの最終同期を行い、サービスやアプリケーションを手動またはスクリプトで起動させてから処理を引き継ぐため、一定のダウンタイムが発生します。
• 実務でのユースケース： 準基幹システムや、ステージング環境を兼ねた冗長化。また、Active側の負荷を減らすために、通常時はスタンバイ側を参照専用（Read-Only）のデータベースとして活用する構成などで採用されます。

③ コールドスタンバイ（Cold Standby）

• 状態： スタンバイ側のサーバーの「電源自体がオフ」になっているか、あるいは全く別の用途（社内の開発・テスト環境など）として稼働している状態です。
• データの同期： リアルタイムの同期は一切行いません。定期的に取得しているバックアップデータを保存している状態です。
• 切り替え時間： 数時間〜数日。障害が発生してから、サーバーの電源を入れる、予備機をラックにマウントする、バックアップデータからシステムをリストアする、といった物理的・手動の復旧作業が必要になります。
• 実務でのユースケース： コストを最小限に抑えたい社内システムや、RTO（目標復旧時間）が数日あってもビジネスに支障がないバックオフィス系システム。

Active-Active（アクティブ/アクティブ）構成

クラスターを構成するすべてのサーバー（2台以上）が同時に「Active（現用系）」として稼働し、ユーザーからの処理を分散して並行処理する構成です。眠っているだけの待機サーバーが存在しないため、システム全体のリソースをフル活用できます。

Active-Active構成のメリットとデメリット

• メリット： 待機しているだけの眠ったサーバーが存在しないため、全サーバーのリソースをフル活用してシステム全体の処理能力を最大化できます。拡張性（スケールアウト）にも非常に優れています。
• デメリット： データを書き込むサーバーが常に複数台存在するため、データの衝突や不整合を防ぐためのアプリケーション設計、DBのロック制御などが極めて難解になります。

Active-Active構成における2つの実装パターン

Active-Active構成は、全サーバーが同時に動くという特性上、データの扱い方によって以下の2つの主要なアーキテクチャ・パターンに分類されます。

【パターン1】負荷分散型（All Active）クラスタ構成

• 仕組み： クラスター内のすべてのノードが、同一のアプリケーションまたはサービスを同時にActive（稼働系）として処理する構成です。ユーザーアクセス（トラフィック）は、クラスターの前面に配置されたロードバランサーによって、各ノードに均等に分散されます。
• 特徴： 一般的にイメージされる「A-A構成」はこちらになります。大規模WebフロントやAPI、状態を持たない「ステートレス（stateless）」なサービスにおいて、圧倒的なスケーラビリティを追求するのに適しています。

⚠️ 若手が陥りがちな「キャパシティ設計（リソース枯渇）」の罠

このActive-Activeの設計で、先輩から一番突っ込まれやすいポイントがこれです。例えば、2台のサーバーでそれぞれ負荷80%の処理をこなしていたとします（合計160%分の処理）。ここで片方のサーバーがダウンした場合、残された1台のサーバーに160%分の処理がなだれ込みます。結果として、生き残ったサーバーも過負荷でドミノ倒しのようにダウンしてしまいます。

そのため、Active-Active構成（特に負荷分散型）では**「1台が落ちても、残されたサーバーだけで最大トラフィックをさばききれるか（通常時は各サーバーの負荷を50%以下に抑えるなど）」**という厳格なキャパシティ設計が必須となります。

【パターン2】相互待機型（Symmetric/Mutual Standby）クラスタ構成

• 仕組み： クラスター内に複数の「サービスリソース（例：DB1とDB2、またはDBとWebなど）」が定義されている場合に、お互いに稼働系と待機系を持ち合っている構成です。それぞれのサービスリソースに対して、別々のノードをActive（稼働系）、もう一方をStandby（待機系）として割り当てます。
  • ノードA： リソース1 (Active) ／ リソース2 (Standby)
  • ノードB： リソース1 (Standby) ／ リソース2 (Active)
• 特徴： 動作モードの定義がノード単位ではなく「リソース単位」になるのが特徴です。結果として、外部からは両ノードとも「稼働系（Active）」として動いているように見えます。

📌 現場のプロ目線：相互待機型の実用的な（Pragmaticな）側面

各サービスは常に単一のActiveノードでデータを書き込むため、データの衝突が発生せず、管理が容易（複雑なデータ同期が不要）です。レガシーなアプリケーションやデータを保持する「ステートフル（stateful）」なデータベースを、コスト効率よく、シンプルに冗長化したい場合に「実用的な（Pragmaticな）解」として適しています。実務の現場では、Active-Active構成を見かける際、このパターン2であることも少なくありません。

【徹底比較】3大HAクラスター実装パターンの違い

実務でどの構成を採用すべきか判断するための比較一覧です。

比較項目	① Active-Standby	② Active-Active パターン1（負荷分散型）	② Active-Active パターン2（相互待機型）
主な目的	可用性の確保	高性能 ＋ 拡張性	可用性 ＋ 実用的な冗長化
定義対象	ノード全体	ノード全体（単一サービス）	個別サービスリソース
通常時の処理性能	低い（1台のみ）	最高（全台フル活用）	Balanced（リソース分担）
データの不整合リスク	比較的容易 （書き込みはシングルActive）	極めて難解 （複数台同時書き込み）	比較的容易 （各サービスはシングルActive）
障害時の性能低下	原則なし （同スペックの待機系へ移行）	あり （残ったサーバーの負荷が急増）	あり （残ったサーバーが全サービスを処理）
適用サービス例	基幹DB、ファイルサーバー	大規模Webフロント、API	複数DB（人事DBと会計DB）、DBとWeb

まとめ：アプリケーション特性に応じた選定を

冗長化構成は、システムの可用性と性能、そして複雑性のトレードオフです。

設計書を読む際、または今後自分で設計する際は、単に「A-Aにする」「A-Sにする」という言葉で片付けるのではなく、この記事で深掘りしたそれぞれの実装パターンが持つ特性──特にデータのステート（状態）をどう持つか──を正しく理解することが重要です。

• データの整合性を重視する stateful（ステートフル） なデータベースなら：Active-Standby や Active-Active パターン2（相互待機型）
• stateless（ステートレス） なWebフロントなら：Active-Active パターン1（負荷分散型）

システムの要件（データの状態、性能要件、コスト）に合わせて最適な組み合わせを選べるようになることが、一人前のインフラエンジニアへの第一歩です。まずはこの基本構造と親子関係をしっかりと頭に叩き込んでおきましょう。

クラスタ構成におけるデータの扱い方については、以下の記事で解説しています。さらに深く知りたい方は読んでみてください。