IT用語集 2023/04/01

フォールトトレランスとは？事例や目的を分かりやすく解説

コラム

情報システムは、どこか一部が壊れた瞬間に「全部止まる」設計だと、障害そのもの以上にビジネスへの影響が大きくなります。そこで重要になるのがフォールトトレランス（Fault Tolerance）です。フォールトトレランスとは、システムの一部に故障が起きても、設計した範囲でサービス継続性を保つための考え方です。この記事では、フォールトトレランスが何を意味し、なぜ注目され、どのような設計・運用で実現されるのかを見ていきます。自社システムで、どこまで止めないべきか、何に優先して投資すべきかを考えるときの基準として使えるように整理します。

「フォールトトレランス」とは

フォールトトレランスの定義

フォールトトレランス（Fault Tolerance）は、直訳すると「故障（フォールト）に対する耐性」を意味します。ここでいうフォールトとは、ハードウェア故障に限らず、ソフトウェア不具合や設定ミス、ネットワーク断など、システムの一部が設計どおりに機能しなくなる事象全般を指します。

フォールトトレランスとは、フォールトが発生した場合でも、設計された範囲内でサービス継続性を保つための設計・仕組み・運用を指します。実務では「影響を限定する」文脈まで含めて広く使われることもありますが、狭義には、故障が起きてもサービス全体を止めにくくする考え方と捉えると整理しやすくなります。

可用性（Availability）や冗長化との違い

フォールトトレランスはしばしば「高可用性（High Availability）」や「冗長化」と一緒に語られますが、視点には違いがあります。

用語	主眼	位置づけ
冗長化	同じ役割を担える要素を複数用意する	フォールトトレランスを支える代表的な手段
高可用性	サービスを利用できる状態を長く保つ	可用性に関する目的・要求水準
フォールトトレランス	故障が起きても継続性を保つ	設計・運用のアプローチ

冗長化はフォールトトレランスを支える代表的な手段ですが、冗長化しただけで自動切り替えが整っていない、監視・切り分け・復旧手順が曖昧といった状態では、「止めない」ことにはつながりません。

「フォールトトレランス」が注目される背景

フォールトトレランスが強く求められるようになった背景には、社会のデジタル化、ITシステムの複雑化、ビジネスの高速化といった流れがあります。

止まること自体が「損失」になりやすい

業務の多くがITに依存する現在、停止はそのまま売上機会の損失や業務滞留、顧客対応の遅延、信頼低下につながります。とくに外部向けサービスでは、停止時間が短くても利用者に影響が及びやすく、障害の規模以上に“止まった事実”が問題視されるケースがあります。

分散・クラウド化で障害点が増える

システムは単体サーバーから、マイクロサービス、API連携、外部SaaS、複数クラウドサービスへと広がりました。便利になった一方で依存関係が増え、どこか一部が不調になる確率も高まります。だからこそ、局所的な不調を全体停止に波及させない設計が重要になります。

24時間稼働が前提になった

インターネットサービスやデータ基盤は、利用者が世界に広がるほど「止められる時間」が短くなります。夜間や休日にメンテナンスできる前提が崩れ、障害時も含めた運用の自動化・標準化が求められています。

フォールトトレランスが必要になる典型シーン

フォールトトレランスは、すべてのシステムに同じ強度で必要というより、「止まったときの影響が大きい領域」で重要度が高まります。以下、想定事例を使って、どんな場面で重要になるのかを見ていきます。

【想定事例1：製造ラインの停止】
一部機器の故障が引き金となり、生産ライン全体が停止。出荷遅延と生産コスト増加につながる。
【想定事例2：取引システムの停止】
サーバーの一部障害で取引ができない時間が発生。機会損失と信用低下のリスクが高い。
【想定事例3：ECサイトのアクセス不能】
データベース障害を契機に購入導線が停止。ピーク時間帯ほど損失が膨らむ。
【想定事例4：冗長構成で影響を抑制】
一部設備が故障しても他系統が引き継ぎ、利用者はほぼ無停止で利用できる。
【想定事例5：クラウドの自動復旧で継続】
冗長構成や自動復旧機能を前提とした場合、一部ノード障害でも別ノードへ振り分け、体感影響を抑えられることがある。
【想定事例6：データセンター運用の前提】
故障を「起きるもの」として設計し、冗長電源・冗長ネットワーク・冗長ストレージで継続性を確保する。

ポイントは、フォールトトレランスが「障害ゼロ」を目指す取り組みではなく、障害が起きても業務や顧客体験への影響を小さくするための現実的な設計思想だという点です。

どこまでフォールトトレランスに投資すべきか

フォールトトレランスは、強くすればするほどよいとは限りません。まずは「どの機能が止まると困るのか」「何分まで停止を許容できるのか」「どこまでのデータ損失なら許容できるのか」を明確にし、守る対象を絞る必要があります。

観点	確認したいこと	設計にどう効くか
業務影響	止まると売上・出荷・顧客対応にどれだけ影響するか	優先して守る導線が決まる
RTO	何分・何時間以内に復旧すべきか	自動復旧や待機系の必要性が見える
RPO	どこまでのデータ差分損失を許容できるか	同期・非同期レプリケーションの選択に直結する
維持すべき機能	全機能を守るのか、中核機能だけ守ればよいのか	フェールソフトの設計可否が見える

重要なのは、すべてを無停止にすることではなく、止まると困る機能から順に守ることです。ここが曖昧なまま設計を始めると、コストだけ膨らんで運用が複雑になりやすくなります。

フォールトトレランスを実現する代表的な考え方

フォールトトレランスは一つの技術で実現するものではなく、目的に応じた考え方を組み合わせて作ります。ここでは混同されやすい用語を、何を優先する考え方なのかという違いに沿って見ていきます。

フェールセーフ

フェールセーフ（Fail-Safe）は、障害が起きたときに安全側へ移行する設計思想です。「止まらない」ことよりも、異常検知時に危険な状態を避けることを優先します。ITでは、権限が不明確な場合に拒否する、異常検知時は操作を受け付けない、といった設計が該当します。

フェールソフト

フェールソフト（Fail-Soft）は、障害時に機能を限定してでもサービスを続ける考え方です。すべてを守ろうとすると全停止になりがちなため、重要度の低い機能を落として中核機能を守る、といった設計が現実的になります。

フェールオーバー

フェールオーバー（Failover）は、故障時に冗長化された待機系や代替系へ自動的に切り替えて稼働を継続する仕組みです。ダウンタイムを短くできますが、切り替えが成功する前提として、監視・判定・データ同期・切り戻しまで含めた設計が必要です。

フールプルーフ

フールプルーフ（Foolproof）は、誤操作を前提に間違いを起こしにくい設計にする考え方です。ITでは、破壊的操作に二重確認を入れる、危険な設定は権限で制限する、入力値を検証して想定外の処理に進ませない、といった形で現れます。

これらは「どれが正解」という話ではなく、対象システムの性質に合わせて組み合わせます。たとえば、安全を優先すべき機能はフェールセーフ、売上に直結する導線はフェールオーバーやフェールソフト、といった整理が現実的です。

フォールトトレランスの実現手法

考え方を実際の仕組みに反映するときは、「どの層でフォールトを吸収するか」を意識すると組み立てやすくなります。以下、代表的な手法を見ていきます。

単一障害点（SPOF）の洗い出し

最初に行うべきなのは、どこか一つが止まるだけで全体停止につながる箇所を洗い出すことです。典型例としては、単独のデータベース、単独回線、単独ロードバランサー、単独認証基盤、単独DNSなどが挙げられます。

フォールトトレランスは、強そうな部品を入れることではなく、単一障害点をなくすことから始まります。影響範囲と依存関係を先に洗い出しておくと、投資の優先順位を付けやすくなります。

冗長化とフェールオーバーの設計

サーバー、ネットワーク機器、電源、回線、ストレージなど、単一障害点になりやすい要素は冗長化の対象になります。重要なのは、冗長化したうえで切り替え条件と切り替え後の整合性を詰めることです。とくにデータを扱う領域では、切り替えが成功してもデータ不整合が残ると業務が止まります。

レプリケーションとデータ整合性

データは「同じ場所にしかない」状態が最大のリスクになります。レプリケーション（複製）には同期と非同期があり、同期は整合性に強い一方で遅延やコストの影響が出やすく、非同期は性能面で有利ですが、障害時に直近の差分が失われる可能性があります。どこまでの差分損失を許容できるかは、業務側の合意が欠かせません。