> [!abstract] 概要(Abstract の日本語訳) > 実務者コミュニティへのフォールトトレランス実践の移転における主要な問題は、フォールトトレランスとは何か、そしてそれが信頼できるコンピュータシステムの設計にどう役立つかについての共通見解の欠如である。本文書は概念的フレームワークを提案することで、フォールトトレランスをより理解しやすくする一歩を踏み出す。このフレームワークは、フォールトトレランス概念の一貫した語彙を提供し、システムがどのように失敗するかを論じ、システムをフォールトトレラントにするために一般的に用いられる機構を説明し、フォールトトレラントシステムを開発するためのいくつかの規則を提供する。 ## 論文情報 - **タイトル**: A Conceptual Framework for System Fault Tolerance - **著者**: Walter L. Heimerdinger([[Honeywell]])、Charles B. Weinstock([[Software Engineering Institute]] / [[Carnegie Mellon University]]) - **媒体**: SEI Technical Report CMU/SEI-92-TR-033 - **発表**: 1992年10月 - **ページ数**: 44p - **資金提供**: U.S. Department of Defense ## 概要 フォールトトレランスの概念を実務者に広めるための概念的フレームワークを提案した 1992 年の SEI 技術報告書。障害・失敗の定義、障害クラス分類、冗長性管理機構の6アクション、障害封じ込め領域、設計多様性、カバレッジを体系化し、フォールトトレラントシステム設計のための6ルールを提示する。[[Jean-Claude Laprie]] の 1992 年のディペンダビリティ体系([Laprie 92])を参照しつつ、橋とコンピュータシステムという2つのアナロジーで全概念を具体化した。 ## 問題設定 実務者コミュニティにフォールトトレランス実践を移転する際の障壁として「フォールトトレランスとは何か」についての共通語彙が存在しない点を特定する。入力は「フォールトトレランスを設計に組み込みたい実務エンジニアの必要」、出力は「統一語彙・分類・機構・設計規則を提供する概念フレームワーク」。 ## 提案手法——概念フレームワーク ### システムの定義 システム(system)はコンピュータ関連・非コンピュータ関連の両方の構成要素の全体集合であり、ユーザーにサービスを提供するものである(§1.1)。フォールトトレランスは3レベルで適用される: 1. **ハードウェア FT**: 余剰ハードウェアリソースの管理 2. **ソフトウェア FT**: プログラム・データ構造の障害に対する補償(チェックポイント/リスタート・リカバリブロック・マルチバージョンプログラム) 3. **システム FT**: コンピュータ以外のシステム施設の失敗を補償するコンピュータ機能(例: センサー失敗の検知と補償) ### ディペンダビリティ達成の4手段(§2.2) | 手段 | フェーズ | 内容 | |---|---|---| | 障害回避(fault avoidance) | 設計時 | 障害の導入を最小化する設計手法・検証・コードレビュー | | 障害除去(fault removal) | 実装時 | 単体テスト・結合テスト・回帰テストによる障害の特定と修正 | | フォールトトレランス(fault tolerance) | 実行時 | 障害存在下でも動作を継続する(場合によっては機能縮退で) | | 障害回避的措置(fault evasion) | 実行時 | 通常挙動からの逸脱を観測し、失敗に至る前に再構成する | **障害回避的措置(fault evasion)**は本論文が定義した独自概念。仕様を超えていなくても異常な挙動をするシステムを事前に再構成する実践を指す。橋の例: 仕様内で揺れる橋への橋梁検査員の増加注意。コンピュータの例: 仕様内でも応答が遅くなり始めたシステムへのバックアップ促進。 ### 障害と失敗の定義(§3.2) - **失敗(failure)**: システムがユーザーに提供するサービスが指定期間にわたって仕様への準拠から逸脱すること。最初に Melliar-Smith [1975] が提案した定義。 - **障害(fault)**: (1)システムの構成要素の失敗、(2)システムのサブシステムの失敗、または(3)考慮対象システムと相互作用した別システムの失敗として定義される。すべての障害はある視点から見た失敗である。 - **症状(symptom)**: システム境界における障害の観測可能な影響。最も極端な症状は失敗だが、温度計の黄色ゾーンへの針振れ程度のものもある。 - **なぜエラー(error)を第三の用語として採用しないか**: 障害とエラーを明確に区別するのが極めて困難であるため、本論文は「エラー」を「障害」に置換することで概念を整理する(§3.2.1)。 重要な帰結: 「一人の障害は別の人の失敗である」——観測レベルによって同じ事象が障害にも失敗にもなる。 ### 障害クラス(§3.4) | 分類軸 | クラス | |---|---| | 所在(Locality) | 原子構成要素・複合構成要素・システムレベル・外部 | | 影響(Effects) | 値障害(value fault)・タイミング障害(timing fault) | | 持続時間(Duration) | 持続的(persistent/hard)・一時的(transient)・周期的(intermittent) | | 直接原因(Immediate Cause) | リソース枯渇・論理障害・物理障害 | | 究極原因(Ultimate Cause) | 仕様・設計・実装・文書化の各障害 | 特記事項: - **タイミング障害**をさらに early/late/omission に分類。fail-silent システム(値障害なし、脱落のみ)と fail-stop システム(すべての失敗でリスタート必要)の区別を導く(§3.4.2.2)。 - **複製障害(replication fault)**: 分散システムで複製情報が不整合になる障害。**ビザンチン障害(Byzantine fault, malicious fault)**: コンポーネントが「嘘をつく」(矛盾する情報を提供する)障害(§3.4.1.3)。 ### 障害属性: 観測可能性と伝播(§3.5) - **潜在障害(latent fault)**: 検知されていない障害(観測可能かどうかに関わらず) - **検知済み障害(detected fault)**: フォールトトレランス機構が発見した障害 - **休止障害(dormant fault)**: 伝播していない障害 - **活性障害(active fault)**: 他の障害や失敗へ伝播中の障害 - **障害軌跡(fault trajectory)**: 連続的にトリガーされる障害の連鎖(連鎖反応) Figure 3-2: 「観測可能性」×「伝播」の2軸マトリクスで障害属性を整理する。 ### 冗長性管理(フォールトトレランスの実装)(§4) フォールトトレランスは**冗長性管理**(redundancy management)とも呼ばれる。冗長性は「障害のない環境では不要な機能能力の提供」であり、フォールトトレランスに必要だが十分ではない——結果を正しく選択する管理機構が必要。 **冗長性管理の6アクション**: | アクション | 定義 | |---|---| | 障害検知(Fault Detection) | 障害が発生したことを判定するプロセス | | 障害診断(Fault Diagnosis) | 原因または障害サブシステム/コンポーネントの特定 | | 障害封じ込め(Fault Containment) | 障害の発生点からユーザーサービスへの影響点への伝播防止 | | 障害マスキング(Fault Masking) | 障害コンポーネントにもかかわらず正しい値のみをシステム境界へ | | 障害補償(Fault Compensation) | 障害サブシステムの出力を補うシステム応答の提供 | | 障害修復(Fault Repair) | システムから障害を除去するプロセス | **カバレッジ(coverage)**: 障害が発生したときにシステム失敗が起きない確率の非形式的尺度。マルコフモデルで各障害・修復アクションが新しい状態に遷移し、一部が失敗状態となる複雑なモデルで定量化。 #### 冗長性の種類 - **空間冗長(space redundancy)**: リソース・機能・データの別物理コピーを提供。持続的障害に有効。同時利用可能なためマスキングに向く。 - **時間冗長(time redundancy)**: 時間軸でずらして関数を再実行。一時的障害に有効。 - **クロック**: 多くのフォールトトレランス機構の基盤。信頼できる時間サービスが不可欠(§4.2.3)。 - **障害封じ込め領域(Fault Containment Regions, FCR)**: 共通依存関係を最小化した領域境界。超高信頼設計では各 FCR が物理的・電気的に隔離されたプロセッサ・メモリ・電源・クロック・通信リンクを持つ(§4.2.4)。 - **コモンモード失敗(Common Mode Failures)**: 単一障害(または障害セット)が十分な冗長機能に影響して選択不能になる失敗。単一電源/冷却/I/O への依存、および同一ソフトウェアの設計障害が源泉(§4.2.5)。 #### 障害検知の2手法 1. **受け入れテスト(Acceptance Tests)(§4.3)**: 単一プロセッサでも適用可能な汎用検知。機能とは独立した基準に基づくテスト(例: 平方根の検証に結果の2乗)。障害診断には使えず「何かが間違っている」だけを示す。リカバリブロック(recovery block)で後退復旧を提供。 2. **比較(Comparison)(§4.4)**: 複数プロセッサによる同一プログラム実行後の結果比較。不一致が障害の症状。ペアワイズ(障害プロセッサの特定不可)と投票(3台以上で障害プロセッサを特定可)の2形式。ソフトウェア設計障害が主な考慮事項なら n バージョンプログラミング[Chen 78]。 #### 設計多様性(§4.5) コモンモード設計障害に対処する唯一の手法。同一仕様から複数の異なるアルゴリズム・物理原理で実装を生成する。真の多様性は共通設計チーム・設計哲学・ソフトウェアツール・テスト哲学への依存を排除する必要があり、別チームを物理的に分離することで実現が試みられている。 ## 新規性 1. **fault と failure の明確な分別**: 「観測レベルが異なる」という相対的視点の導入。従来は synonymous に使われていた。 2. **障害回避的措置(fault evasion)という概念の導入**: 仕様違反なしに異常挙動を検知し予防的再構成する実践を初めて命名・定義。 3. **橋とコンピュータという2種アナロジーによる具体化**: 抽象概念を異なるドメインで同時に例示する教育的手法。 4. **6アクションの統一フレームワーク**: 障害検知・診断・封じ込め・マスキング・補償・修復の6アクションを受け入れテストと比較という2検知手法に対応させて体系化。 ## 実験設定 技術報告書であり実験は含まない。概念フレームワークの提案のみ。 ## 実験結果 実験なし。 ## 考察 ### 6設計規則(§5) 著者が提示するフォールトトレラントシステム設計のための実践的規則: 1. **Rule 1**: システムが何をすべきかを正確に知る。仕様からの逸脱が何時間続いたら失敗とみなすかを決定する。 2. **Rule 2**: 何が問題になりうるかを見て、原因を管理可能なクラスにグルーピングする。障害フロアを定義する。 3. **Rule 3**: アプリケーションを分析し、適切な障害封じ込め領域と、潜在的障害への対処可能な最も早い時点を決定する。 4. **Rule 4**: アプリケーション要求を完全に理解し、適切な時間/空間のトレードオフを行う。 5. **Rule 5**: 可能な限り信頼できる障害に集中し、追加コストなしに対処できない限り低確率の障害は無視する。 6. **Rule 6**: アプリケーションの失敗マージンを慎重に決定し、必要なフォールトトレランスの程度とコストのバランスを取る。 ### 限界と課題 - ソフトウェアの定量的信頼性目標(例: 10^-9 failures/hour)の達成を統計的手法で示すことは不可能だと論じる(§2.3.1)——但書き: 現在のフォーマルメソッドはこの問題にある程度対処している。 - 設計多様性の実現には別チームの物理的分離が要件となり、コスト・規模の障壁が高い。 ## 強み / 弱点・課題 **強み**: - fault/failure/symptom/latent/detected/dormant/active/trajectory という統一語彙の確立 - 受け入れテストと比較の2検知手法を同一の6アクションフレームワークで対応させた対称的な構造 - 橋とコンピュータという2種アナロジーが概念の直感的理解を助ける **弱点・課題**: - 「error」を廃棄し「fault」に統合する選択は後の Avizienis 2004 の error 概念と緊張関係を生む - 設計多様性の実用的な実現方法は「別チームを分離」という手順論にとどまり、独立性の定量的評価方法を示さない - 障害封じ込め領域の境界設計をどう決定するかの具体的ガイダンスが乏しい ## 関連 - 概念: [[フォールトトレランス]] / [[ソフトウェア耐障害性]] / [[ディペンダビリティ]] / [[プロセスペア]] / [[チェックポイント]] - 人物: [[Walter Heimerdinger]] / [[Charles Weinstock]] / [[Algirdas Avizienis]](引用: n バージョンプログラミング・設計多様性) - 組織: [[Software Engineering Institute]] / [[Carnegie Mellon University]] / [[Honeywell]] - 参照 MOC: [[structures/SRE - MOC]] ## 出典 - 原本: `.raw/papers/1992_005_001_16112.pdf`(44p、CMU/SEI-92-TR-033) - 参照: [Laprie 92] Laprie, J.C. (ed.), *Dependability: Basic Concepts and Terminology*, Springer-Verlag, 1992 - 参照: [Avizienis 84] Avizienis, A. and J.P.J. Kelly, "Fault Tolerance by Design Diversity", IEEE Computer, 1984 - 参照: [Chen 78] Chen, L. and Avizienis, A., "N-version Programming", FTCS-8, 1978 - 参照: [Lamport 82] Lamport, Shostak, Pease, "The Byzantine Generals Problem", TOPLAS, 1982