# フォールトトレランス ## 定義 フォールトトレランス(fault tolerance)とは、**障害(fault)が存在するにもかかわらず、システムが指定されたサービスの提供を継続する能力**である。Heimerdinger+Weinstock 1992([[@1992__CMU SEI__A Conceptual Framework for System Fault Tolerance]])は「フォールトトレランスは冗長性管理(redundancy management)である」と定式化し、以下の6アクションで構成されると整理した: | アクション | 定義 | |---|---| | 障害検知(Detection) | 障害が発生したことを判定する | | 障害診断(Diagnosis) | 障害の原因またはサブシステムを特定する | | 障害封じ込め(Containment) | 障害の伝播を防ぐ | | 障害マスキング(Masking) | 障害コンポーネントにもかかわらず正しい値を保証する | | 障害補償(Compensation) | 障害サブシステムの出力を補う | | 障害修復(Repair) | 障害をシステムから除去する | ディペンダビリティ達成の4手段(障害回避・障害除去・フォールトトレランス・障害回避的措置)の中で、フォールトトレランスは実行時の手段である([[ディペンダビリティ]]参照)。 ### 基本的な障害・失敗の定義(Heimerdinger+Weinstock 1992) - **失敗(failure)**: システムが提供するサービスが仕様への準拠から逸脱すること - **障害(fault)**: 構成要素/サブシステム/相互作用システムの失敗として定義。「一人の障害は別の人の失敗」——観測レベルによって同じ事象が障害にも失敗にもなる - **症状(symptom)**: システム境界における障害の観測可能な影響 - **障害軌跡(fault trajectory)**: 連続的にトリガーされる障害の連鎖(連鎖反応) ### 冗長性の分類 - **空間冗長(space redundancy)**: 別物理コピーの提供。持続的障害・マスキングに向く - **時間冗長(time redundancy)**: 時間軸をずらして再実行。一時的障害に有効 - **設計多様性(design diversity)**: コモンモード設計障害への唯一の対策——異なるアルゴリズム/物理原理による複数実装 ### 障害封じ込め領域(Fault Containment Regions, FCR) 障害の伝播を構造的に防ぐための設計手法。共通依存関係を排除した領域境界を設ける。超高信頼設計では各 FCR が物理的・電気的に隔離されたプロセッサ・メモリ・電源・クロック・通信リンクを持つ。 ### カバレッジ(Coverage) 「障害が発生したときにシステム失敗が起きない確率」の非形式的尺度。マルコフモデルで定量化。各障害・修復アクションが新しい状態へ遷移する過程として表現される。 ## 横断的知見 - **Heimerdinger+Weinstock 1992 の「error 廃棄」は Avizienis 2004 の「error 存続」と緊張関係にある**: 1992 年報告書は fault/failure の2項を明確化するために error を fault に吸収した。一方、Avizienis 2004([[@2004__TDSC__Basic Concepts and Taxonomy of Dependable and Secure Computing]])は fault → **error** → failure の3段連鎖モデルを保持した。実務上 error は「システム状態の誤り」という受動的概念として有用で、オンライン障害予測研究(Salfner+ 2010)もこの3段モデルを基盤とする。(Source: [[@1992__CMU SEI__A Conceptual Framework for System Fault Tolerance]], [[@2004__TDSC__Basic Concepts and Taxonomy of Dependable and Secure Computing]], [[@2010__ACM CSUR__A Survey of Online Failure Prediction Methods]]) - **障害回避的措置(fault evasion)は 1992 年に命名された先回り型フォールトトレランスであり、2020年代の AIOps 予防的管理と同型**: Heimerdinger+Weinstock は「仕様違反なしに異常挙動を検知し、失敗に至る前に再構成する」実践を *fault evasion* と命名した。これは Notaro+ 2021([[@2021__TIST__A Survey of AIOps Methods for Failure Management]])の AIOps proactive カテゴリ(prevention + online prediction)、および Salfner+ 2010 の [[プロアクティブ障害管理]] 4段モデルと概念的に同型である。30年前に命名された概念が AIOprs として再構成されている。(Source: [[@1992__CMU SEI__A Conceptual Framework for System Fault Tolerance]], [[@2021__TIST__A Survey of AIOps Methods for Failure Management]], [[@2010__ACM CSUR__A Survey of Online Failure Prediction Methods]]) - **「受け入れテスト対比較」という2検知手法の区別は、現代の単一/多数投票型レプリカ設計の直接の祖型である**: 受け入れテストは単一プロセッサで機能する汎用検知(ただし診断不可)、比較はペアワイズと投票による障害診断が可能。これは LLM 訓練クラスタでの故障マシン検知([[Minder]]: メトリクス類似度比較)やチェックポイント整合性検証([[チェックポイント]])の設計パターンの元型と見なせる。(Source: [[@1992__CMU SEI__A Conceptual Framework for System Fault Tolerance]] §4.3-§4.4) ## 未解決の問い - fault evasion(障害回避的措置)と AIOps の prevention・online prediction カテゴリの間の概念的一致は 1992 年から認識されていたか。両者の「正常挙動からの逸脱の定義」はどう異なるか。 - カバレッジ(coverage)をマルコフモデルで定量化する手法は、数千コンポーネントを持つ現代の大規模クラウドシステム・LLM 訓練クラスタに適用できるか。状態爆発問題にどのように対処しているか。 - 設計多様性(design diversity)のコスト——「別チームの物理的分離」——は LLM エージェントを複数独立実装することで低減できるか。[[agentic SRE]] における設計多様性の現代的形態は何か。 - 障害封じ込め領域(FCR)の境界設計はどう決定すべきか。現代のマイクロサービスアーキテクチャやコンテナオーケストレーションにおける FCR の等価物は何か([[マイクロサービスアーキテクチャ]]との接続)。 ## 関連 - 概念: [[ディペンダビリティ]] / [[ソフトウェア耐障害性]] / [[プロセスペア]] / [[チェックポイント]] / [[Heisenbug]] / [[障害予測]] / [[プロアクティブ障害管理]] / [[AIOps]] / [[agentic SRE]] - ソース: [[@1992__CMU SEI__A Conceptual Framework for System Fault Tolerance]] / [[@2004__TDSC__Basic Concepts and Taxonomy of Dependable and Secure Computing]] / [[@2010__ACM CSUR__A Survey of Online Failure Prediction Methods]] / [[@2021__TIST__A Survey of AIOps Methods for Failure Management]] - 参照 MOC: [[structures/SRE - MOC]] ## 出典 - [[@1992__CMU SEI__A Conceptual Framework for System Fault Tolerance]](全文: §2〜§5)