IT用語集 2023/04/01

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

コラム

情報システムは、どこか一部が壊れた瞬間に「全部止まる」設計だと、障害そのもの以上にビジネスへの影響が大きくなります。そこで重要になるのがフォールトトレランス（Fault Tolerance）です。この記事では、フォールトトレランスが何を意味し、なぜ注目され、どのような設計・運用で実現されるのかを整理します。読み終えるころには、自社システムで「どこまで止めないべきか」「何に投資すべきか」を判断するための軸が持てるはずです。

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

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

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

フォールトトレランスとは、フォールトが発生した場合でも、設計された範囲内でサービス停止を回避する、または影響を限定するための設計・仕組み・運用の総称です。重要なのは「故障しない」ことではなく、「故障しても致命的な影響にしない」ことにあります。

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

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

冗長化：同じ役割を担える要素を複数用意し、故障に備える考え方（手段）。
高可用性：障害やメンテナンスを含め、サービスを利用できる状態をできるだけ長く保つこと（目的）。
フォールトトレランス：フォールトが起きたときも動き続ける、または影響を限定して動かすための設計・運用（アプローチ）。

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

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

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

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

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

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

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

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

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

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

フォールトトレランスは、すべてのシステムに同じ強度で必要というより、「止まったときの影響が大きい領域」で重要度が高まります。ここでは想定事例でイメージをつかみます。

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

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

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

フォールトトレランスは一つの技術で実現するものではなく、目的に応じた考え方を組み合わせて作ります。ここでは混同されやすい用語を、狙いの違いで整理します。

フェールセーフ

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

フェールソフト

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

フェールオーバー

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

フールプルーフ

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

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

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

考え方を具体的な仕組みに落とすときは、「どの層でフォールトを吸収するか」を意識すると設計しやすくなります。代表的な手法を整理します。

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

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

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

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