# Understanding, Detecting and Localizing Partial Failures in Large System Software **論文**: Understanding, Detecting and Localizing Partial Failures in Large System Software **媒体**: NSDI 2020 **対象**: 大規模システムソフトウェアにおける partial failure と OmegaGen **URL**: https://www.usenix.org/conference/nsdi20/presentation/lou > [!abstract] 概要 > 本論文は、ZooKeeper、Cassandra、HDFS、Apache、Mesos などの実障害から partial failure を分析し、それを検知・局所化する OmegaGen を提案する。partial failure はプロセス全体が停止するのではなく、一部の処理が停止、遅延、ゾンビ化する障害である。OmegaGen は静的解析とプログラム削減により、対象プログラム固有のウォッチドッグを生成し、実障害 22 件中 20 件を中央値 4.2 秒で検知し、18 件で障害範囲を局所化する。 ## 論文情報 | 項目 | 内容 | |---|---| | 著者 | Chang Lou, Peng Huang, Scott Smith | | 発表 | NSDI 2020 | | 対象 | ZooKeeper, Cassandra, HDFS, Apache, Mesos など | | 調査 | 5 システムから各 20 件、計 100 件の partial failure | | 手法 | OmegaGen: プログラム固有ウォッチドッグ生成 | ## 概要 分散システムの障害は、プロセスのクラッシュだけではない。 プロセスは生きており、ハートビートも出ているが、特定の要求処理だけが停止したり、極端に遅くなったり、不要な作業を続けたりする。 このような障害を partial failure と呼ぶ。 本論文は、partial failure の実態を調べたうえで、OmegaGen という検知・局所化手法を提案する。 OmegaGen は、対象プログラムのコードから、正常に進捗すべき処理経路を抽出し、その進捗を監視するプログラム固有ウォッチドッグを生成する。 **Figure 1: ZooKeeper の partial failure 事例** ![[_attachments/nsdi2020-omegagen/fig01-zookeeper-partial-failure.png]] (Figure 1. ZooKeeper の処理がプロセス停止ではなく一部処理の停止として現れる例を示す。partial failure が通常監視で見えにくい理由を具体化している。) ## 問題設定 一般的な監視は、プロセスの生死、CPU、メモリ、ポート応答、ハートビートを確認する。 しかし partial failure では、これらの監視が正常に見えることがある。 サービスの一部だけが止まり、他の機能は動き続けるため、障害検知と局所化が難しい。 本論文の問いは次である。 - partial failure は実システムでどのような形で現れるか。 - 既存の監視やタイムアウトではなぜ検知しにくいか。 - プログラム固有の進捗監視を自動生成できるか。 - 検知と局所化を低オーバーヘッドで実現できるか。 ## 調査方法 論文は 5 つの大規模システムから partial failure 事例を収集する。 ZooKeeper、Cassandra、HDFS、Apache、Mesos から各 20 件、合計 100 件を対象とする。 分類は次のような障害形態を含む。 | 分類 | 割合 | 意味 | |---|---:|---| | Stuck | 48% | 処理が進まない | | Slow | 17% | 処理が極端に遅い | | Zombie | 13% | 不要または誤った処理を継続する | | その他 | 残り | 複合的・分類困難な事例 | また、71% は production-dependent とされる。 つまり、特定の本番状態、データ、負荷、環境条件がなければ再現しにくい。 **Figure 2: partial failure の根本原因分布** ![[_attachments/nsdi2020-omegagen/fig02-root-cause-distribution.png]] (Figure 2. uncaught error、indefinite blocking、buggy error handling、deadlock など、調査対象 partial failure の原因分布を示す。) **Figure 3: partial failure の帰結** ![[_attachments/nsdi2020-omegagen/fig03-failure-consequence.png]] (Figure 3. stuck、slow、zombie など、partial failure がプロセス生存中に異なる失敗形態として現れることを示す。) ## 提案手法: OmegaGen OmegaGen は、プログラム固有のウォッチドッグを自動生成する。 一般的な外部監視ではなく、対象プログラムの処理構造を使って「進捗すべき処理が進んでいるか」を監視する。 大まかな流れは次である。 1. 静的解析により、長時間実行される可能性がある処理やブロッキングポイントを特定する。 2. プログラム削減により、監視対象に必要なコード範囲を絞る。 3. 進捗点を監視するウォッチドッグを生成する。 4. 実行時に進捗異常を検知し、関連する処理範囲を局所化する。 この設計により、アプリケーション非依存のメトリクスではなく、プログラム内部の意味に沿った監視が可能になる。 **Figure 4: intrinsic watchdog の例** ![[_attachments/nsdi2020-omegagen/fig04-intrinsic-watchdog.png]] (Figure 4. main program の状態・文脈・mimic checker・watchdog driver を組み合わせ、プログラム固有の進捗を監視する構成を示す。) ## 実験設定 評価対象は、ZooKeeper、Cassandra、HDFS に加え、HBase、MapReduce、YARN などを含む 6 システムである。 規模は 28K〜728K SLOC とされる。 実世界の partial failure 22 件を用いて、検知数、局所化数、検知時間、オーバーヘッドを評価する。 比較対象には、一般的な watchdog や既存の検知手法が含まれる。 OmegaGen は、プログラム固有性を持つ点で汎用監視と異なる。 ## 主な結果 ### 実障害の多くを検知できる OmegaGen は 22 件の実障害中 20 件を検知する。 中央値の検知時間は 4.2 秒である。 これは、partial failure を長時間放置せず、早期に検知できる可能性を示す。 ### 局所化も高い精度で行う OmegaGen は 18 件で障害範囲を局所化する。 最良の比較手法が 11 件検知、8 件局所化にとどまることと比べると、プログラム固有ウォッチドッグの効果が大きい。 ### オーバーヘッドは限定的である スループットへのオーバーヘッドは 5.0〜6.6% と報告される。 本番投入には慎重な評価が必要だが、常時監視として検討可能な範囲にある。 **Figure 6: 生成された watchdog checker のスレッドカバレッジ** ![[_attachments/nsdi2020-omegagen/fig06-thread-coverage.png]] (Figure 6. 各評価システムにおいて、生成された checker がどの程度スレッドをカバーするかを示す。) ### 未知バグも検出する 評価の中で、ZooKeeper 3.5.5 の実バグを発見している。 これは、OmegaGen が既知障害の再現だけでなく、新しい partial failure の発見にも使えることを示す。 ## 新規性 この論文の貢献は、partial failure を実証的に分類したうえで、検知・局所化の自動生成手法を提示した点にある。 通常のクラッシュ検出やハートビート監視では扱えない「生きているが進まない」障害を、プログラム内部の進捗として扱う。 ## 考察 partial failure は、分散システムの可用性を大きく損なうが、検知が遅れやすい。 この論文は、監視を外部メトリクスだけに依存する設計の限界を示す。 運用上は次の示唆がある。 - ハートビートが正常でも、処理進捗を別に監視する。 - 例外経路、ロック待ち、I/O 待ち、リトライループを partial failure の観点でテストする。 - 障害検知だけでなく、原因範囲の局所化まで考える。 - 本番依存の状態を再現できるテスト環境を整える。 ## 強み / 弱点・課題 ### 強み - partial failure の実例 100 件を分類している。 - 静的解析と実行時監視を組み合わせている。 - 検知時間、局所化、オーバーヘッドを評価している。 - 未知バグ発見の実績がある。 ### 弱点・課題 - プログラム解析の適用可能性は実装言語やコード構造に依存する。 - オーバーヘッド 5〜6% は、ワークロードによっては無視できない。 - 監視点の設計が誤ると、誤検知や見逃しの可能性が残る。 - 本番環境での運用導入には、アラート運用や自動復旧との統合が必要である。 ## 関連 - [[分散システム障害]] - [[@2016__ASPLOS__TaxDC - A Taxonomy of Non-Deterministic Concurrency Bugs in Datacenter Distributed Systems]] - [[@2019__HotOS__What Bugs Cause Production Cloud Incidents]] ## 出典 - [[.raw/papers/nsdi2020-omegagen.pdf]] - [[.raw/papers/nsdi2020-omegagen.txt]] - [[.raw/papers/nsdi2020-omegagen/images/images.json]]