フェイルオーバーとは？冗長化との違いを解説

フェイルオーバーとは、稼働中のサーバーやシステムに障害が発生したとき、待機している別のサーバーや経路へ処理を切り替えてサービスを継続する仕組みです。

冗長化が「障害に備えて複数の構成要素を用意する設計」なのに対し、フェイルオーバーは実際に障害が起きたときに正常な系へ切り替える動作を指します。

フェイルオーバーとは？

フェイルオーバーは、サーバー、データベース、ネットワーク機器などに障害が起きたとき、別の正常な構成要素へサービスを引き継ぐ仕組みです。

Microsoftのフェールオーバークラスタリングでも、ノードに障害が起きた場合、残っているノードがワークロードを引き継ぐ処理をフェイルオーバーとして説明しています。

フェイルオーバーと冗長化の違い

2つは非常に近い言葉ですが、意味の範囲が違います。

用語	意味
冗長化	障害に備えて複数のサーバー・回線・電源などを用意する設計
フェイルオーバー	障害発生時に正常な系へ処理を切り替える動作

つまり、フェイルオーバーは冗長化されたシステムで使われる代表的な障害対応方法の1つです。

フェイルオーバーの基本的な流れ

一般的なフェイルオーバーは、次のような流れで動きます。

どの程度まで自動化されているかはシステム構成によって異なります。

障害はどうやって検知する？

自動フェイルオーバーでは、通常、監視機能やヘルスチェックによって異常を検知します。

Microsoftのフェールオーバークラスターでは、ノードやクラスターロールの状態を継続的に監視し、異常時に再起動や別ノードへの移動を行う仕組みがあります。

Active-Standbyとは？

Active-Standbyは、通常時に主系だけが処理を担当し、別のサーバーを待機系として用意する構成です。 Active-Passiveとも呼ばれます。

状態	主系	待機系
通常時	サービスを提供	待機
障害時	停止・切り離し	サービスを引き継ぐ

Microsoftの資料では、Active-Passive構成は待機ノードが通常時にはサービスを処理せず、障害発生時に役割を引き継ぐ構成として説明されています。

Active-Activeとは？

Active-Activeは、複数のノードが通常時から稼働し、それぞれが処理を担当する構成です。

通常時から複数台を利用するため、リソースを有効活用しやすい一方、構成やデータ整合性の管理が複雑になる場合があります。

構成	通常時	特徴
Active-Standby	主系のみ処理	構成を理解しやすい
Active-Active	複数系が処理	通常時も複数リソースを活用

自動フェイルオーバーと手動フェイルオーバー

フェイルオーバーは、自動で行う場合と管理者が手動で行う場合があります。

方式	特徴
自動	監視結果に基づいてシステムが切り替える
手動	管理者が障害を確認して切り替える

AWSの災害復旧ガイドでも、Active/Passive構成のフェイルオーバーは自動または手動で開始できると説明されています。

フェイルオーバーとスイッチオーバーの違い

フェイルオーバーと似た言葉に「スイッチオーバー」があります。

用語	主な意味
フェイルオーバー	障害発生をきっかけに別系統へ切り替える
スイッチオーバー	保守などのため計画的に別系統へ切り替える

製品によって用語の使い方は多少異なる場合がありますが、障害時か計画的な切り替えかで区別すると理解しやすくなります。

フェイルバックとは？

障害が復旧したあと、元の主系へサービスを戻すことをフェイルバックと呼ぶ場合があります。

ただし、復旧直後に自動で戻すとは限りません。 データ同期や原因確認を行い、安全を確認してから戻す構成もあります。

ロードバランサーとフェイルオーバーの違い

ロードバランサーは、複数サーバーへアクセスを分散する仕組みです。 フェイルオーバーは、障害時に正常な系へ処理を切り替える考え方です。

仕組み	主目的
ロードバランサー	負荷分散
フェイルオーバー	障害時のサービス継続

実際のシステムでは、ロードバランサーがサーバーのヘルスチェックを行い、異常なサーバーへアクセスを送らないことでフェイルオーバーに近い役割を担うこともあります。

バックアップとフェイルオーバーの違い

バックアップとフェイルオーバーも目的が異なります。

項目	バックアップ	フェイルオーバー
主目的	失ったデータを戻す	サービスを継続する
障害時	復元作業が必要	別系統へ処理を切り替える
誤削除対策	有効	基本的に別問題

フェイルオーバーがあれば停止時間はゼロ？

必ずゼロになるわけではありません。 障害検知、切り替え判定、サービス起動、DNSや経路変更などに時間がかかる場合があります。

実際の時間は構成によって大きく異なります。

データ損失もゼロになる？

これも構成次第です。 主系と待機系のデータ同期に遅延がある場合、障害直前のデータが待機系へ反映されていない可能性があります。

重要システムでは、RPO（どの程度のデータ損失を許容できるか）とRTO（どの程度の停止時間を許容できるか）を決めて設計します。

フェイルオーバーが使われる場所

フェイルオーバーはサーバーだけでなく、さまざまな場所で利用されます。

どの層を冗長化し、どこでフェイルオーバーさせるかによって、障害への強さと費用が変わります。

フェイルオーバーの弱点

フェイルオーバーは有効な障害対策ですが、導入すればすべて解決するわけではありません。

構成が複雑になる

サーバー台数、監視、データ同期、切り替え制御などの管理対象が増えます。

費用が増える

待機系を用意するため、サーバーやクラウドリソースの費用が増える場合があります。

誤検知の可能性がある

一時的な通信遅延を障害と判断し、不要な切り替えが発生する可能性があります。

共通障害には弱い場合がある

2台のサーバーが同じ電源・同じネットワーク・同じデータセンター障害の影響を受ける構成では、2台とも同時に利用できなくなる可能性があります。

フェイルオーバーでは障害範囲を分けて考える

高可用性を考えるときは、「サーバー1台の故障」だけを想定しないことが重要です。

障害範囲	対策例
プロセス障害	サービス再起動
サーバー障害	別サーバーへ切り替え
ラック・電源障害	別障害ドメインへ配置
データセンター障害	別拠点・別ゾーンへ切り替え
広域障害	別リージョンなどを検討

AWSでも、複数のAvailability Zoneを利用してアプリケーションやデータベースを別ゾーンへフェイルオーバーできる構成が案内されています。

自動フェイルオーバーには監視が必要

自動切り替えを成立させるには、「何をもって障害と判断するか」を決めなければなりません。

判定が敏感すぎると誤フェイルオーバーが増え、鈍すぎると障害検知が遅れます。

フェイルオーバーはテストが必要

構成だけ作っても、実際の障害時に切り替わるとは限りません。

AWSの災害復旧ガイドでも、復旧戦略は定期的に評価・テストすることが重要とされています。

共用レンタルサーバー利用者は設定する必要がある？

一般的な共用レンタルサーバー利用者が、自分でサーバーのフェイルオーバーを構築する必要は通常ありません。

共用サーバーでは物理サーバーやネットワークの管理は事業者側が行うため、利用者がActive-Standby構成を直接組むことは通常ありません。

VPSでは自分でフェイルオーバーを構築する？

VPSでは複数台を契約して冗長構成を作ることはできますが、単に2台用意するだけではフェイルオーバーになりません。

どんなサイトでフェイルオーバーが重要？

フェイルオーバーを導入するかの判断基準

技術的にできるかではなく、「停止したときの損失」と「対策費」を比較します。

フェイルオーバーでよくある誤解

2台あれば自動で切り替わる

2台用意しただけでは切り替わりません。監視・同期・切り替え制御が必要です。

フェイルオーバーがあればバックアップ不要

誤削除やデータ破損に備えるバックアップは別に必要です。

Active-Activeなら絶対止まらない

共通ネットワークやストレージに障害が起きれば、複数ノードへ同時に影響する可能性があります。

自動切り替えなら管理不要

監視条件の調整、障害テスト、通知、フェイルバックなどの運用が必要です。

小規模サイトでも必須

停止による損失が小さいなら、バックアップ・監視・復旧手順を優先する方が合理的な場合があります。

教科書判定

FAQ

まとめ