フォールトマスキングとは？ 10分でわかりやすく解説

UnsplashのChristina @ wocintechchat.comが撮影した写真      

フォールトマスキングは、障害が起きても利用者や上位処理に見える結果をできるだけ正しく保ち、サービス停止やエラー露出を抑えるための設計です。代表例としては、冗長化した系の多数決、フェイルオーバー、誤り訂正や代替経路への切り替えがあります。障害そのものを防ぐ技術ではなく、「障害が起きる前提で、結果への影響を表に出しにくくする」ための設計だと捉えると位置づけがつかみやすくなります。

一方で、フォールトマスキングは万能ではありません。構成は複雑になり、監視や復旧手順、整合性制御まで含めて設計しないと、止まらない代わりに誤処理が広がることがあります。採用の前に、どの機能を継続させたいのか、どの機能は停止してでも安全側へ倒すのかを分けて考える必要があります。

フォールトマスキングとは

定義

フォールトマスキングとは、ハードウェアやソフトウェアの障害が発生しても、利用者から見える結果を正しい状態に近づけ、サービス継続を図るための技術・設計思想です。障害を完全になくすのではなく、冗長系や代替処理を使って影響を吸収し、異常をそのまま表面化させない設計を指します。

似た用語との違い

• フォールトトレランス：障害が起きても正しい実行やサービス継続を図る広い概念です。フォールトマスキングは、その実現手段の一つとして位置づけると整理しやすくなります。
• フェイルオーバー：故障した系から待機系や冗長系へ切り替える動きです。フォールトマスキングを支える代表的な手段の一つです。
• フェールセーフ：異常時に安全側へ移る設計です。継続より安全を優先するため、フォールトマスキングと同じ判断になるとは限りません。

業務システムでは「止めずに続ける」方が優先される機能と、「誤動作のまま続けない」方が優先される機能が混在します。権限付与、決済、監査記録のように誤処理の影響が大きい機能では、フェールセーフ寄りの判断を取る方が合う場面があります。

何を守るための設計か

フォールトマスキングで守りたいものは、単純な「稼働」だけではありません。実際には、可用性、利用者の操作継続、誤応答の抑制、障害時の影響範囲の局所化を同時に扱います。機能をすべて維持できないときは、参照系だけ残す、更新系を止める、キャッシュ応答へ切り替えるといった縮退運転も現実的な選択肢になります。

フォールトマスキングを支える代表的な実装パターン

冗長化と切り替え

もっとも基本になるのは、処理系やデータを複数持ち、異常系を切り離して健全系で継続する構成です。対象はサーバー、アプリケーションプロセス、データストア、ネットワーク経路、拠点などさまざまです。

• Active-Standby 構成で待機系へ切り替える
• 複数ノードに処理を分散し、故障ノードを除外する
• 複数拠点や複数AZへ分散し、局所障害の影響を抑える

このとき、単一障害点（SPOF）が残っていないかを先に洗い出す必要があります。サーバーを二重化しても、認証基盤やデータベース、ロードバランサーが単一なら、そこが止まった時点で全体が止まります。

多数決・誤り訂正・整合性制御

フォールトマスキングは、切り替えだけでなく「誤った結果を採用しない」工夫でも成り立ちます。代表例としては、三重化した系の多数決、メモリや通信での誤り訂正、冗長情報からの復元があります。たとえば、複数系の出力を比較して多数側を採用する設計や、チェックサムやECCのようにデータ異常を検出・補正する仕組みは、結果の正しさを保つための手段として使われます。

ただし、出力だけを守っても副作用が壊れると事故は防げません。再試行や系切り替えが起こる前提では、同じ処理が二重に実行されても結果が破綻しないよう、冪等性や重複排除も併せて設計する必要があります。注文、決済、在庫更新のような処理では、この点を軽く扱えません。

障害検知と復旧制御

フォールトマスキングは、障害を見つけられなければ動きません。監視は、停止の検知だけでなく、遅延、エラー率上昇、キュー滞留、誤応答の検知まで含めて設計する方が実態に合います。

• 死活監視で停止や無応答を捉える
• タイムアウトや遅延監視で性能劣化を捉える
• 整合性チェックで誤った応答や破損データを捉える
• サーキットブレーカーで障害中の依存先へ要求を集中させない

誤検知が多い監視は、不要な切り替えを連発させてかえって不安定になります。検知条件、切り替え条件、復帰条件を分けておく方が、運用時の振る舞いを制御しやすくなります。

縮退運転とフォールバック

すべての機能を完全なまま維持できない場面では、最低限の機能だけを残す設計が有効です。たとえば、参照系はキャッシュで返し、更新系だけを止める、外部APIが不安定な間は一部機能を閉じる、といった形です。利用者へ返す価値をどこまで維持するのかを先に決めておくと、障害時の判断がぶれにくくなります。

適用しやすい場面と、避けた方がよい場面

適用しやすい場面

• 停止時間が売上や業務継続へ直接響くサービス
• 参照系と更新系を分けて設計しやすいシステム
• 障害時に代替経路や代替ノードを用意しやすい構成
• 可用性と信頼性の目標を明文化しやすい業務

Webサービス、社内ポータル、参照中心の業務システム、継続提供が重い意味を持つ基盤系では、フォールトマスキングの効果が見えやすくなります。

避けた方がよい場面

• 誤継続の方が停止より危険な処理
• 整合性より継続を優先すると重大事故になる処理
• 監視、切り替え、復旧の運用体制を持てない組織
• 冗長化しても共通要因障害を避けられない構成

決済、権限変更、監査証跡、制御系の安全機能などでは、「表向きは止まらないが、内部で誤った状態が広がる」方がリスクになります。この種の処理は、フォールトマスキングよりフェールセーフや明示停止の方が合う場合があります。

導入判断で見るべき点

1. どの機能を守るのか

全機能を同じ水準で守ろうとすると、コストも複雑さも急激に増えます。まず、停止が許されない機能、縮退でよい機能、異常時は止めるべき機能を分けることから始めます。

2. どの障害まで想定するのか

単一ノード障害、ネットワーク断、データ破損、外部API停止、拠点障害では、必要な設計が違います。単一障害だけを想定した冗長化では、同一バグや同一基盤障害のような共通要因を防げません。

3. 復旧時間とデータ損失許容をどう置くのか

停止をどこまで短くしたいのか、どこまでのデータ損失を許容するのかを定める必要があります。復旧時間や復旧後の整合性確認を曖昧にしたまま冗長化すると、切り替わっても業務が再開できない状態になりやすくなります。設計では、RTOやRPOのような指標で許容範囲を揃えておく方が判断しやすくなります。

4. テストと訓練を継続できるか

切り替え系は、平常時にはほとんど使われません。そのため、障害注入、ネットワーク遮断、遅延付与、系切り離し、復旧後の再同期まで含めて検証しないと、本番で初めて問題が表面化します。設計だけで安心せず、切り替わった後に正常運用へ戻れるかまで確認する必要があります。

フォールトマスキングの限界

フォールトマスキングは、あらゆる障害を隠せる仕組みではありません。冗長系が同じバグを持っている場合、誤ったデータを全系へ複製した場合、認証基盤や外部APIのような共通依存先が落ちた場合には、マスキングだけでは止まりません。

さらに、障害を表面化させにくい設計は、見えない不調を内部へ溜め込む面もあります。監視、復旧、原因分析が弱いと、「表向きは続いていたが、復旧不能な状態が進行していた」という失敗につながります。フォールトマスキングは、隠す設計ではなく、観測しながら影響を抑える設計として扱う方が安全です。

まとめ

フォールトマスキングは、障害が起きても利用者に見える結果をできるだけ正しく保ち、停止やエラー露出を抑えるための設計です。中心になるのは、冗長化、障害検知、切り替え、整合性制御、縮退運転の組み合わせです。

採用判断では、「止めない」ことだけを目標にせず、どの機能を継続させ、どの機能は停止して安全を守るのかを切り分ける必要があります。障害想定、復旧時間、データ損失許容、運用体制まで含めて設計したときに、フォールトマスキングは効果を発揮します。

FAQ