## 定義 フェイルスローハードウェア(fail-slow hardware, 略して FSH)とは、停止せずに稼働し機能し続けるが、劣化した状態にあり期待される性能より遅いハードウェアを指す。フェイルストップ(完全停止)と対比される概念であり、限界性能で動き続けるという意味で limpware とも呼ばれる。(Source: [[@2026__TOCS__Fail-Slow Hardware Failure Bug Analysis and Detection for Cloud Systems]]) FSH の本質は**障害の粒度**にある。ディスク I/O 操作の集合を \(D\)、ネットワーク I/O 操作の集合を \(N\) とすると、フェイルストップディスクは \(D\) 全体を、ノードクラッシュは \(D \cup N\) を落とす**粗粒度**障害である。これに対し FSH は、フェイルスロー NIC が \(N\) の部分集合 \(N_{sub} \subset N\) だけを遅くする**細粒度**障害を生む。粗粒度障害は既存のフォールトトレランス機構で扱われてきたが、細粒度障害は「内部チェッカの検知網をすり抜ける」という新しい課題を突きつける。(Source: [[@2026__TOCS__Fail-Slow Hardware Failure Bug Analysis and Detection for Cloud Systems]] §1) ## 実測される規模 - 100 万台超の NVMe SSD を 4 か月監視した結果、平均 1.41% が FSH の影響下にあった(Lu ら、[[@2026__TOCS__Fail-Slow Hardware Failure Bug Analysis and Detection for Cloud Systems]] が引用)。 - 1 Gbps NIC のスループットが部分バッファ破損と再送により 1 Kbps へ数桁低下する事例がある。 - FSH インシデントの検知には数時間から数か月を要し、**分単位で検知できたのは全ケースの 1% にすぎない**(Gunawi ら 2018 "Fail-slow at scale" の調査、同論文が引用)。ZooKeeper のフェイルスロー NIC 障害では診断に 5 か月かかった事例がある。 ## FSH が引き起こすバグの構造 [[@2026__TOCS__Fail-Slow Hardware Failure Bug Analysis and Detection for Cloud Systems]] は ZooKeeper・HDFS・HBase・MapReduce・Cassandra の実障害 48 件を分析し、次の構造を示した。 1. **脆弱点は同期機構とタイムアウト機構に集中する**。全 48 件がこの 2 つの機構の脆弱性に起因していた。同期ブロック内の I/O が遅くなると、他タスクを無期限にブロックする(根本原因の 41.6%)。タイムアウトタスクとタイムアウトハンドラの間には、複雑なスレッドインタリーブ制御なしにデータ競合が起きうる(16.7%)。 2. **細粒度性が発現の必要条件である**。フェイルスロー NIC が `serializeNode` だけを遅くし heartbeat を遅くしないため、leader は生きていると見なされ続けクラスタが準凍結する。もし粗粒度のフェイルストップ NIC を注入していれば heartbeat も止まり、follower がリーダー選出を始めてクラスタは健全に戻る。**粗粒度障害の注入では FSH バグは再現しない**。 3. **症状の半数以上(58.3%)はノードサービス利用不能**であり、**20.8% はデータ欠損・不整合というサイレント障害**である。後者は正しさの仕様なしには検知できない。 4. **89.6% は単一の FSH で引き起こされる**。複数障害の組み合わせを要しないため、テストにおける注入空間は指数的には増えない。 ## 横断的知見 - **FSH は「グレイ障害の原因側」であり、グレイ障害は「FSH の観測側」である**。[[グレイ障害]] は Huang+ 2017 が Observer とアプリの観測非対称性(差分可観測性)として定式化した現象で、DDIA 2E 第9章はこれを「劣化性能(limping node / gray failure / fail-slow)」というノード故障モデルとして形式化する。TOCS 2026 論文はその原因側であるハードウェア劣化がソフトウェアのどの構造(同期・タイムアウト)を突き崩すかを 48 件の実障害から特定した。Sieve のグレイ障害チェッカが Panorama の簡略版であることは、両概念が同じ現象の因果の両端を見ていることを実装レベルで示す。(Source: [[@2026__TOCS__Fail-Slow Hardware Failure Bug Analysis and Detection for Cloud Systems]] §4.6, [[@2017__HotOS__Gray Failure - The Achilles' Heel of Cloud-Scale Systems]], [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 9 The Trouble with Distributed Systems]]) - **「冗長・フォールトトレランス機構こそが FSH の隠れ蓑になる」という逆説が複数ソースで一致する**。[[グレイ障害]] では、コアスイッチの冗長度が上がるほど少なくとも 1 台がグレイ障害を起こす確率も上がるという Huang+ 2017 の逆説、および SuperBench の「部分修復の罠」が報告されている。TOCS 2026 論文はこれをテスト側から裏づける——heartbeat やリーダー選出といったフォールトトレランス機構が正常に働くからこそ FSH は検知されず、システムは準凍結状態のまま健全と報告され続ける。冗長設計が fail-stop を前提にしている限り、FSH に対しては無力かむしろ有害である。(Source: [[@2026__TOCS__Fail-Slow Hardware Failure Bug Analysis and Detection for Cloud Systems]] §1・§3.1, [[@2017__HotOS__Gray Failure - The Achilles' Heel of Cloud-Scale Systems]], [[@2024__USENIX ATC__SuperBench - Improving Cloud AI Infrastructure Reliability with Proactive Validation]]) - **本番監視による検知と、リリース前テストによる検知は目的が異なる**。Panorama・IASO・OmegaGen・PERSEUS はいずれも本番監視で FSH 障害を検知する系統だが、検知時点で既に被害が出ており、IASO は 1.5 年以上の運用を経てフェイルスロー障害を捕捉している。TOCS 2026 論文はこの時間差を問題視し、リリース前の障害注入テストという別の位置を主張する。[[プロアクティブ検証]] の SuperBench は「本番だが事前」という第三の位置にあり、3 者は時間軸上で補完関係にある。(Source: [[@2026__TOCS__Fail-Slow Hardware Failure Bug Analysis and Detection for Cloud Systems]] §8, [[@2024__USENIX ATC__SuperBench - Improving Cloud AI Infrastructure Reliability with Proactive Validation]]) ## 未解決の問い - FSH バグの回避策として著者が挙げる「同期構造の内部で I/O をしない」は、実際のクラウドシステムでどこまで機械的に強制できるか。静的解析による lint ルールとして実装可能か、それとも直列化のコピーコストが許容されない場面が多いか。 - 単一障害注入(89.6% を覆う)で取りこぼす残り 10.4% の複数 FSH 障害を、注入空間を爆発させずに扱う戦略は設計できるか。Chronos の深さ優先探索は組み合わせを狙うが、TOCS 論文は「狙う場面が違う」として比較を避けている。両者を統合した戦略はありうるか。 - 同期・タイムアウトのキーワード列挙に依存する障害点解析は、Go の `select`/`context.WithTimeout` や Rust の `async`/`tokio::time::timeout` のような非 Java の並行性モデルにどこまで移植できるか。著者は C++ の `mutex`/`ctime` を例に「1 回の手作業で済む」と述べるが、非同期ランタイム上の I/O では「同期スコープ」の定義自体が変わるのではないか。 - FSH の細粒度性が発現の必要条件であるなら、既存のカオスエンジニアリング基盤([[カオスエンジニアリング]])が提供する粗粒度障害(ノード kill・ネットワーク分断)は FSH バグに対して構造的に無力ということになる。細粒度注入を既存基盤に載せる現実的な経路は何か。 - エージェントによる障害検証(LLM が checker report・ログ・設計文書を突き合わせて TRUE_BUG/FALSE_POSITIVE/UNCERTAIN を判定)は ZooKeeper の 10 件でしか評価されていない。正解ラベルが著者判定に依存する状況で、この種の検証の外部妥当性をどう確立するか。[[LLMによる根本原因分析]] の評価設計と共通の課題ではないか。 ## 関連 - ソース: [[@2026__TOCS__Fail-Slow Hardware Failure Bug Analysis and Detection for Cloud Systems]] - ツール: [[Sieve]] - 概念: [[グレイ障害]] / [[部分故障]] / [[差分可観測性]] / [[障害注入]] / [[遅延注入]] / [[ストラグラー]] / [[プロアクティブ検証]] / [[フォールトトレランス]] / [[カオスエンジニアリング]] / [[分散システム障害]] - 対象システム: [[ZooKeeper]] / [[Apache Kafka]] / [[HDFS]] / [[Apache HBase]] / [[Apache Cassandra]] - MOC: `[[structures/AIOps.MOC]]`(該当があれば一方向参照) ## 出典 - Gen Dong, Yu Hua, Yongle Zhang, Zhangyu Chen, Menglei Chen. "Fail-Slow Hardware Failure Bug Analysis and Detection for Cloud Systems." *ACM Transactions on Computer Systems*, 2026. DOI: 10.1145/3838187.