# ソフトウェア耐障害性 ## 定義 ソフトウェア耐障害性(software fault tolerance)とは、ソフトウェアのバグや異常状態が存在してもシステムの可用性とデータ完全性を維持するための設計原則・機構の総体である。[[Jim Gray]] は [[@1985__Tandem__Why Do Computers Stop and What Can Be Done About It]] において、(1) プロセスとメッセージによるソフトウェアモジュール性、(2) 防御的プログラミングによるフェイルファスト、(3) 本番障害の大多数が一時的である([[Heisenbug]])という仮説の活用、(4) [[プロセスペア]]による冗長実行、(5) トランザクション機構によるデータ完全性、の 5 要素を鍵として提示した。ハードウェア耐障害設計の原則——モジュール性と冗長性——をソフトウェアに適用する考え方であり、耐障害設計は「ハードウェアは解決済み、ソフトウェアと運用が主戦場」という認識に立脚する。 ## 横断的知見 - **Gray 1985 の非公式な分類と Avizienis 2004 の形式的タクソノミーは同じ現象を異なる粒度で記述する**: [[Jim Gray]] は「ハードウェア障害・ソフトウェアバグ・管理エラー」という実践的な 3 分類を示した。[[Algirdas Avizienis]] ら [[@2004__TDSC__Basic Concepts and Taxonomy of Dependable and Secure Computing]] は同じ現象を 8 視点 × 31 複合障害クラスに形式化した。管理エラーは「意図的でない非悪意の運用障害」(クラス 16–21)、ソフトウェアバグは「開発フェーズの内部人為的障害」(クラス 1–4)に対応する。Gray の「Heisenbug が大多数」という実践的観察は、Avizienis の「断続的(intermittent)障害は再現不可能」という定義と対応する。(Source: [[@1985__Tandem__Why Do Computers Stop and What Can Be Done About It]], [[@2004__TDSC__Basic Concepts and Taxonomy of Dependable and Secure Computing]]) - **Gray のプロセスペア + トランザクションは Avizienis のフォールトトレランス手段(エラー検知 + システム回復)の実装である**: Avizienis 2004 はフォールトトレランスを「エラー検知 + エラー処理 + 障害処理」の組み合わせとして形式化する。Gray のプロセスペアはエラーが発生したプロセスの状態を除去して再初期化するロールバックに相当し、トランザクションはエラー処理のためのロールバック機構を提供する。Gray が「フォールトトレランスはハードウェアでは解決済み、ソフトウェアが主戦場」と述べた際の直感を、Avizienis は「固体開発障害(solid development fault)には設計多様性(design diversity)が必要だが、断続的な Heisenbug にはロールバックが有効」という形式的な命題に変換した。(Source: [[@1985__Tandem__Why Do Computers Stop and What Can Be Done About It]] §3, [[@2004__TDSC__Basic Concepts and Taxonomy of Dependable and Secure Computing]] §5.2.2) - **古典的なソフトウェア信頼性章は、同一コード冗長化が効かない理由をハードウェアとの差分として整理する**: [[@2012__Wiley__Practical Reliability Engineering|Practical Reliability Engineering]] は、ソフトウェアには摩耗・個体差・時間依存の故障率が基本的になく、故障は仕様・設計・コードの欠陥が特定条件で実行された結果だと整理する。同一プログラムを並列に置いても同じ欠陥を共有するため、冗長化には設計多様性が必要になる。この議論は Gray の Heisenbug/Bohrbug 論と、Avizienis の設計多様性の位置づけを、工学ソフトウェアの仕様完全性・ロバスト性・試験へ接続する。(Source: [[@1985__Tandem__Why Do Computers Stop and What Can Be Done About It]], [[@2004__TDSC__Basic Concepts and Taxonomy of Dependable and Secure Computing]], [[@2012__Wiley__Practical Reliability Engineering]] ch.10 §10.1-§10.4) - **Heimerdinger+Weinstock 1992 はソフトウェア FT をシステム FT の1レベルとして位置づけ、Gray 1985 の「ソフトウェアが主戦場」という焦点をより広いシステム視点に拡張した**: Gray はソフトウェアに集中したが、[[@1992__CMU SEI__A Conceptual Framework for System Fault Tolerance]] はハードウェア FT(冗長ハードウェア管理)→ソフトウェア FT(チェックポイント/リカバリブロック/マルチバージョン)→システム FT(非コンピュータ構成要素の失敗の補償)という3段階を設定する。ソフトウェア FT はシステム全体のフォールトトレランスの中間レベルに位置する。また Gray が「エラー」を概念として使い続けたのに対し、1992 年報告書は fault/failure の2項で error を吸収し、Avizienis 2004 はさらに3段連鎖 fault → error → failure を復元する——用語の進化が実務と理論の間で交互に起きた。(Source: [[@1985__Tandem__Why Do Computers Stop and What Can Be Done About It]], [[@1992__CMU SEI__A Conceptual Framework for System Fault Tolerance]], [[@2004__TDSC__Basic Concepts and Taxonomy of Dependable and Secure Computing]]) - **Lyu 2007 はシングルバージョン技法とマルチバージョン技法の 2 群を整理し、設計多様性の有効性は依然論争中だと指摘する**: Gray 1985 の「Heisenbug が大多数」という観察は、シングルバージョン技法（チェックポイント・ロールバック・プロセスペア）の有効性を支持する。一方で Lyu 2007 が整理する設計多様性（N-version programming・リカバリブロック）の有効性は、Eckhardt と Lee (1985) の正の相関仮説と Littlewood と Miller (1989) の負の相関の可能性という対立する主張がある。Avizienis 2004 が「固体設計障害には設計多様性が必要」と形式化した枠組みと、Lyu 2007 の実証的な留保（設計多様性の有効性が続けて議論されている）は、理論と実証の間のギャップとして残る。(Source: [[@1985__Tandem__Why Do Computers Stop and What Can Be Done About It]], [[@2004__TDSC__Basic Concepts and Taxonomy of Dependable and Secure Computing]], [[@2007__FOSE__Software Reliability Engineering - A Roadmap]]) - **Lyu 2007 の障害耐性の 8 段階（障害封じ込め・検知・診断・再構成・回復・再起動・修復・再統合）は、Gray 1985 のフェイルファスト + プロセスペア + トランザクションをより細かい段階に分解したものとみなせる**: Gray がシンプルな 5 要素で捉えた耐障害設計を、Lyu は運用システムの応答シーケンスとして 8 段階に展開する。特に Gray の「チェックポイントとロールバック」が Lyu の「回復」段階に対応し、Gray の「プロセスペア」が「再起動・修復・再統合」の段階に対応する。ただし Lyu の枠組みはソフトウェア設計の抽象レベルで記述するのに対し、Gray は実際のシステム実装（スプーラ・データベース）に基づく観察である。(Source: [[@1985__Tandem__Why Do Computers Stop and What Can Be Done About It]], [[@2007__FOSE__Software Reliability Engineering - A Roadmap]]) ## 未解決の問い - **フェイルファスト vs. グレースフルデグレーデーションのスコープ境界**: Gray 1985 のフェイルファスト設計は単一コンポーネント内の障害隔離に有効だが、[[Datadog]] の 2023 年事例([[@2025__Datadog Engineering Blog__Failure is inevitable - Learning from a large outage and building for reliability in depth at Datadog]])は分散システムの部分障害時に全停止を引き起こした（スクエアウェーブ障害パターン）。フェイルファスト（コンポーネント内の早期停止）と[[グレースフルデグレーデーション]]（システム全体での継続運用）はどのアーキテクチャ層で切り替わるべきか。 - Gray 1985 のフェイルファスト仮定は、モジュールが「正しく動くか停止する」ことを前提とする。現代のサイレントデータ破壊(SDC)やフェイルスロー障害([[GPUレジリエンス]])はこの仮定を破る——フェイルファストの仮定が成り立たないとき、ソフトウェア耐障害性はどのように再構成されるか。 - Gray のデータは 1985 年の Tandem システム(4 百万行のコード、2,000 台)に基づく。「管理 42%、ソフトウェア 25%」という比率は、数万 GPU・数十億行のコードベースを持つ現代の大規模 AI 基盤や[[耐障害LLM訓練]]にどの程度外挿できるか。 - トランザクション機構 + 永続プロセスペアの設計パターンは、状態を持つ長時間実行ワークロード(LLM 訓練、ストリーム処理)にどのような形で再現されているか——[[チェックポイント]] + 再起動はこのパターンの現代的変形と見なせるか。 - Heisenbug の比率(132 件中 131 件)は 1985 年のスプーラに限定された測定である。現代の分散ソフトウェアスタックにおける Bohrbug/Heisenbug の比率は定量的に測定されているか。 ## 関連 - [[Heisenbug]] — ソフトウェア耐障害性を支える中心仮説 - [[プロセスペア]] — 冗長実行の設計パターン - [[チェックポイント]] — 状態保存と復旧の機構(トランザクションジャーナルの現代的継承) - [[耐障害LLM訓練]] — 大規模 LLM 訓練における耐障害設計の現代的適用 - [[GPUレジリエンス]] — ハードウェアの信頼性が耐障害ソフトウェアの必要性を規定する - [[障害緩和]] — 障害検知後の緩和戦略 - [[グレースフルデグレーデーション]] — 分散部分障害時の継続運用設計（フェイルファストとの対比） - [[structures/SRE - MOC]] — 運用信頼性の MOC ## 出典 - [[@1985__Tandem__Why Do Computers Stop and What Can Be Done About It]] - [[@2004__TDSC__Basic Concepts and Taxonomy of Dependable and Secure Computing]](§3.2 障害タクソノミー, §5.2 フォールトトレランス手段) - [[@2012__Wiley__Practical Reliability Engineering]](ch.10) - [[@2007__FOSE__Software Reliability Engineering - A Roadmap]](§2.1, §2.3, §4.2) - [[@2025__Datadog Engineering Blog__Failure is inevitable - Learning from a large outage and building for reliability in depth at Datadog]](グレースフルデグレーデーション vs. フェイルファスト、2025-10-15)