ソフトウェア耐障害性 - yuuk1's Digital Garden

# ソフトウェア耐障害性 ## 定義ソフトウェア耐障害性(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 要素を鍵として提示した。ハードウェア耐障害設計の原則——モジュール性と冗長性——をソフトウェアに適用する考え方であり、耐障害設計は「ハードウェアは解決済み、ソフトウェアと運用が主戦場」という認識に立脚する。 ### 多版ソフトウェアによる方式の構造分類(McAllister & Vouk 1996) [[@1996__McGrawHill__Handbook of Software Reliability Engineering - Chapter 14 Fault-Tolerant Software Reliability Engineering]] は、機能的に等価な複数版(version)の冗長性を用いる耐障害ソフトウェア方式を、判定機構(受け入れテスト対投票器)と実行様式(逐次対並列)の組み合わせで分類する。 | 方式 | 判定機構 | 実行様式 | 構造の要点 | |---|---|---|---| | リカバリブロック(recovery block, RB) | 受け入れテスト(acceptance test) | 逐次(最初の版が失敗したら次へフォールバック) | 単一プロセッサでは逐次実行がボトルネック。分散環境では並列化可能(分散リカバリブロックは[[@1996__McGrawHill__Handbook of Software Reliability Engineering - Chapter 15 Software System Analysis Using Fault Trees]]が詳述) | | Nバージョンプログラミング(N-version programming, NVP) | 投票器(voter) | 並列(全版を同時実行) | サービス中断が原則不要。投票器自体の信頼性がシステム全体の上界になる | | N自己点検プログラミング(N self-checking programming, NSCP) | ペア比較(compare) | 並列(ペア単位) | Airbus A310で採用。ペア内不一致でそのペアを棄却する階層構造 | | コンセンサスリカバリブロック(consensus recovery block, CRB) | NVP失敗時にRBへフォールバック | 並列→逐次のハイブリッド | 高い版間故障相関下でも比較的頑健(§14.7.4) | | 受け入れ投票(acceptance voting, AV) | 受け入れテスト→投票器の直列 | 並列 | 受け入れテストの信頼性に強く依存。一般にCRBより信頼性が劣る | これは本 concept が既に持つ「空間冗長・時間冗長・設計多様性」という冗長性の分類([[@1992__CMU SEI__A Conceptual Framework for System Fault Tolerance]] 経由、[[フォールトトレランス]]参照)を、多版ソフトウェア固有の判定機構の違いという軸でさらに細分化するものである。 ## 横断的知見 - **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) - **古典的なソフトウェア信頼性章は、同一コード冗長化が効かない理由をハードウェアとの差分として整理する**: [[wiki/entities/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]], [[wiki/entities/Practical Reliability Engineering|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]]) - **Practical Reliability Engineering ch.10 §10.8 が述べる多様性(diversity)による冗長化の前提は、Lyu 2007 が指摘する有効性論争を素通りしている**: PRE は「独立に書かれた 2 つのプログラムが同じコーディング誤りを含む可能性は低い」という前提を、投票・選択ルーチンの実装手法として淡々と述べるにとどまり、限界として明記するのは「仕様誤りには効かない」という一点のみである。一方 Lyu 2007 は同じ多様性の主題について、Eckhardt と Lee (1985) の正の相関仮説と Littlewood と Miller (1989) の負の相関の可能性という対立する実証研究を紹介し、有効性が依然論争中だと明言する。実務教科書(PRE)と学術サーベイ(Lyu 2007)とで、同じ技法に対する留保の深さが異なる。(Source: [[@2012__Wiley__Practical Reliability Engineering - Chapter 10 Software Reliability]] §10.8, [[@2007__FOSE__Software Reliability Engineering - A Roadmap]]) - **PRE ch.10 §10.7 の工学系ソフトウェア向けフォールトトレランス手法は、Gray 1985 / Avizienis 2004 が扱う汎用計算機システムの FT 機構とは異なる実装粒度に位置する**: Gray と Avizienis はデータベースや分散システムにおけるプロセス・トランザクション単位のソフトウェア冗長性を扱うのに対し、PRE §10.7 はサイクルタイム監視・エラー時の安全状態設定・入力変化率チェック・複数サイクルでの入力待機といった、センサ・アクチュエータと直結したリアルタイム制御ソフトウェアの入出力レベルの安全機構を扱う。これは PRE §10.2 が述べる「工学ソフトウェアはハードウェアインターフェースをより広く共有する」という特性の帰結であり、耐障害設計の実装粒度が適用ドメイン(汎用計算機システム対組み込み制御システム)によって異なることを示す。(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 - Chapter 10 Software Reliability]] §10.2, §10.7) - **McAllister & Vouk 1996 は、Lyu 2007 が「設計多様性の有効性は依然論争中」と留保していた Eckhardt と Lee (1985) / Littlewood と Miller (1989) の対立を裏付ける一次実験データを提供する**: 本 concept が既に指摘した「Lyu 2007 の実証的な留保」(横断的知見の既出項目)に対し、[[@1996__McGrawHill__Handbook of Software Reliability Engineering - Chapter 14 Fault-Tolerant Software Reliability Engineering]] §14.7 は、20版のアビオニクスアプリケーション(4大学・20チームが独立開発)を用いた大規模実験の生データを提示する。17版部分集合で9版が同時故障するイベントは、独立故障を仮定した二項分布モデルでは約8回と期待されるのに対し、実測では約105回観測された(表14.2)。この定量的な乖離は、Lyu 2007 が抽象的に紹介した「設計多様性の有効性論争」の実体――独立に開発された版どうしが実際にどれだけ相関して故障するか――を、具体的な頻度データとして裏付ける一次資料である。(Source: [[@1996__McGrawHill__Handbook of Software Reliability Engineering - Chapter 14 Fault-Tolerant Software Reliability Engineering]] §14.7.1-14.7.2, [[@2007__FOSE__Software Reliability Engineering - A Roadmap]]) - **Practical Reliability Engineering ch.10 §10.8 が明記する多様性冗長化の唯一の限界(「仕様誤りには効かない」)を、McAllister & Vouk 1996 の実験はさらに狭める**: 本 concept の既出の横断的知見は、PRE ch.10 §10.8 が多様性による冗長化の限界を「仕様誤りに効かない」の一点のみに絞っていることを指摘した。McAllister & Vouk 1996 §14.7.2 の表14.3(IAW = identical-and-wrong 応答の頻度)は、17版のうち8版が*同一の誤った*答えを返すイベントが500試行中15回観測されたことを示す――これは版が共有する仕様誤りだけでなく、独立に実装されたにもかかわらず類似した設計判断・境界条件の見落としに収束すること(同一かつ誤った応答, IAW)が現実に起きることを意味する。PRE が単一の限界(仕様誤り)として片付けた問題は、実際にはより広い「独立開発チームが収束的に同じ誤りに至る」現象として観測される。(Source: [[@2012__Wiley__Practical Reliability Engineering - Chapter 10 Software Reliability]] §10.8, [[@1996__McGrawHill__Handbook of Software Reliability Engineering - Chapter 14 Fault-Tolerant Software Reliability Engineering]] §14.7.2) - **Gray 1985 の「複製された欠陥は同時に励起される」という直感的説明を、McAllister & Vouk 1996 は投票・受け入れテストという判定機構の構造的な違いに変換する**: Gray はソフトウェア障害の単純複製が無効である理由を一文で述べるにとどめたが(本 concept 定義節)、McAllister & Vouk 1996 は同じ問題を「判定機構(受け入れテスト対投票器)と実行様式(逐次対並列)」という2軸で構造化し、リカバリブロック・NVP・NSCP・CRB・AVという5方式に分岐させた上で、高い版間相関の条件下でCRBが比較的頑健であることを実験的に示す(図14.14-14.15)。Grayが提示した直感(「複製は効かない」)から30年強を経て、どの構造がどの条件で複製の限界を緩和できるかが定量的に整理されたことを示す。(Source: [[@1985__Tandem__Why Do Computers Stop and What Can Be Done About It]] §3, [[@1996__McGrawHill__Handbook of Software Reliability Engineering - Chapter 14 Fault-Tolerant Software Reliability Engineering]] §14.3.2, §14.7.4) - **McAllister & Vouk 1996 は、関連故障と無関係故障の統計的関係について文献上の仮定が分岐していることを両論併記し、この分岐は同一書籍第15章(Dugan)の記述と符合する**: §14.7 冒頭は「関連(related)故障と無関係(unrelated)故障は、統計的に独立([Duga94c])、排反(mutually exclusive、[Lapr90a])、またはその他の関係にあると仮定できる」と明記する。[Duga94c] は[[@1996__McGrawHill__Handbook of Software Reliability Engineering - Chapter 15 Software System Analysis Using Fault Trees]]の著者 Joanne Bechta Dugan の別論文であり、[Lapr90a] は同章が「原モデル」として参照する Arlat/Kanoun/Laprie の枠組みである。第15章はDugan自身のモデルが原モデル(Laprie)の「排反」仮定から「統計的独立」仮定へ変更されている点を§15.5で明記しており、本章の両論併記はこの食い違いの存在を独立に裏付ける一次資料である。(Source: [[@1996__McGrawHill__Handbook of Software Reliability Engineering - Chapter 14 Fault-Tolerant Software Reliability Engineering]] §14.7 p.596, [[@1996__McGrawHill__Handbook of Software Reliability Engineering - Chapter 15 Software System Analysis Using Fault Trees]] §15.5) - **機能安全の実務(FMEA)は、Gray 1985 が観察した「複製された欠陥の同時励起」を、抵抗器という物理部品との対比によって独立に再確認し、多点故障という別の語彙でその帰結を述べる**: 本 concept は既に、Gray がソフトウェア障害の単純複製が無効である理由として「複製された欠陥は同時に励起される」と述べたこと、および McAllister & Vouk (1996) の多版ソフトウェア実験がこの現象を `RALL`(全バージョンとdeciderに影響する関連故障)という基本事象で構造化したことを記録している(既出)。[[機能安全]]が集約するカオスエンジニアリング17章(Nathan Aschbacher著)は同じ現象を、耐障害性研究とは独立の機能安全という文脈で「1つの物理的な抵抗器が1000種類の方法で呼ばれることはまずないが、ソフトウェアの機能は1000箇所から呼び出され毎回同じ機能でありうる」という比喩で述べ、その帰結を「多点故障(同時多発的な故障モード)」という機能安全側の語彙で表現する。さらに17章は、FMEAが通常この種の多点故障を分析の考慮に含めないという実務プロセス側の限界を明示しており、これは McAllister & Vouk が扱う統計的独立性の仮定の分岐(既出)とは異なる角度から——「実務の分析手法がそもそも多点故障を扱う設計になっていない」という手続き上の欠落として——同じ問題の別の側面を照らす。(Source: [[@1985__Tandem__Why Do Computers Stop and What Can Be Done About It]] §3, [[@2022__OReillyJapan__カオスエンジニアリング - Chapter 17 サイバーフィジカルで行こう]] §17.3, §17.4) ## 未解決の問い - FMEAのプロセス自体を、ソフトウェアが引き起こす多点故障(同一欠陥の同時多発)に対応できるよう改修する具体案は、[[機能安全]]・本 concept のどちらのソースにも示されていない。(Source: [[@2022__OReillyJapan__カオスエンジニアリング - Chapter 17 サイバーフィジカルで行こう]] §17.4) - **フェイルファスト 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 の比率は定量的に測定されているか。 - McAllister & Vouk 1996 の20版実験は独立検証前の版(validation phase前)を意図的に用いており、著者ら自身「実運用では厳格な検証を経る」と断っている(§14.7.1)。十分に検証された商用版どうしでも、同程度の版間相関(9版同時故障で理論の10倍超)が観測されるのか、それとも検証プロセスが相関故障を実務上無視できる水準まで下げるのか、定量的な追試データはあるか。 - コンセンサスリカバリブロック(CRB)が高相関下で頑健である理由は、NVPが投票の失敗時にRBへフォールバックする「二段構え」の構造にあると本章は示唆する(§14.7.4)が、この頑健性は版数Nや出力空間の濃度にどこまで一般化するか。LLMエージェントを複数独立実装する現代の設計多様性(本 concept の既存の問い参照)にCRBのような二段フォールバック構造を適用する余地はあるか。 ## 関連 - [[機能安全]] — FMEAの実務的限界としての多点故障、CPS(サイバーフィジカルシステム)への拡張 - [[Heisenbug]] — ソフトウェア耐障害性を支える中心仮説 - [[プロセスペア]] — 冗長実行の設計パターン - [[チェックポイント]] — 状態保存と復旧の機構(トランザクションジャーナルの現代的継承) - [[耐障害LLM訓練]] — 大規模 LLM 訓練における耐障害設計の現代的適用 - [[GPUレジリエンス]] — ハードウェアの信頼性が耐障害ソフトウェアの必要性を規定する - [[障害緩和]] — 障害検知後の緩和戦略 - [[グレースフルデグレーデーション]] — 分散部分障害時の継続運用設計（フェイルファストとの対比） - [[フォールトトレランス]] — ハードウェア冗長化の一般枠組み(本 concept はそのソフトウェア固有の難しさを担う) - [[David McAllister]] / [[Mladen Vouk]] — 多版ソフトウェアの構造分類と版間相関故障実験の著者 - [[structures/SRE - MOC]] — 運用信頼性の MOC ## 出典 - Nathan Aschbacher, 「サイバーフィジカルで行こう」, Casey Rosenthal・Nora Jones 編『カオスエンジニアリング ― 回復力のあるシステムの実践』, オライリー・ジャパン, 2022, 17章 §17.3-§17.4。 - [[@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 フォールトトレランス手段) - [[wiki/entities/Practical Reliability Engineering|Practical Reliability Engineering]](ch.10) - [[@2012__Wiley__Practical Reliability Engineering - Chapter 10 Software Reliability]](§10.2, §10.7, §10.8) - [[@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) - [[@1996__McGrawHill__Handbook of Software Reliability Engineering - Chapter 14 Fault-Tolerant Software Reliability Engineering]](§14.3, §14.4, §14.5, §14.7)