## Summary for Tweet #SRE論文紹介 [Nguyen+, ICDCS'13]:システムメトリクスとコンポーネント間の依存関係のみで、障害発生時にオンラインで故障箇所を特定するFChainが提案されている論文。 依存関係だけでは、依存方向の逆方向にも異常が伝搬するバックプレッシャー問題に対応できないため、FChainではメトリクスの異常変化の「開始時刻」を用いる。 FChainは各メトリクスの異常変化の「開始時刻」を検出し、開始時刻順に異常の伝播経路を特定する。さらに、コンポーネント間の依存関係から、誤った異常伝搬をフィルタリングする。 メトリクスの収集インターバル1秒のデータセットで、ベースラインより90%以上高いPrecision、20%以上高いRecallを達成した。 [ICDCS'13]: FChain: Toward Black-box Online Fault Localization for Cloud Systems paper: http://dance.csc.ncsu.edu/papers/icdcs13_fchain.pdf ## Memo - USのノースカロライナ大学とMathWorks社の著者らによる会議論文。2023/04時点で被引用数は103件である。第三者による紹介スライド https://speakerdeck.com/stefanozanella/fchain-toward-black-box-online-fault-localization-for-cloud-systems がある。 - アプリケーションの事前知識を用いずに、動的に取得可能な低レベルのシステムメトリクスとコンポーネント間の依存関係のみで、障害発生時にオンラインで故障箇所を特定する手法が提案されている。 - [13]のような時系列順序のみに依存するだけではバックプレッシャーのような偽の異常伝搬を捉えられない。 - 提案法は、1)異常な変化点を通常の作業負荷変動による多くの変化点から区別し、異常動作開始時刻を発見する。 2)異常な変化の伝播パターンとコンポーネント間の依存関係に基づいて、故障したコンポーネントを特定する。3)誤報をさらにフィルタリングするためにランタイム検証を行う。 - 異常変化点検出について、一般的なCUSUM + Bootstrapでは、故障と関係ないランダムなピークポイントを検出している。[[2011__SLAML__PAL - Propagation-aware Anomaly Localization for Cloud Hosted Distributed Applications|PAL]]は平滑化と変化の大きさの外れ値検出により、いくつかの正常な変化点をフィルタリングできるが、正常実行中に大きな変動があるとうまくいかない（図３：Disk Write）。そこで、オンライン学習モデル[12]PRESSにより、異なるメトリクス値間の遷移確率を捉え、予測誤差が閾値を超えるかをチェックする。予測誤差の閾値を固定ではなく動的に決定するために、バースト性メトリックであれば、予測誤差の閾値を大きくする。20秒ごとなどに時系列データの小ウィンドウを分割し、[[高速フーリエ変換|FFT]]を適用し、周波数スペクトルのtop-kを高周波とみなし、高周波成分に対して逆FFTを適用し、バースト信号を合成する。バースト信号のmagnitude（バースト値の90%tileなど）を期待予測誤差とし、これを予測誤差の閾値とする。最後に、変化点の開始時刻を特定するために、接線ベースのロ ールバックを行い、異常変化の正確な開始時刻を特定する。 - ![[Pasted image 20230430081806.png|400]] - 故障箇所特定：異常変化の開始時刻でソートし、異常な変化の伝搬経路を導出し、経路にしたがって、故障箇所をピンポイントで特定し、最後に依存関係データから偽の異常な変化の伝搬経路をフィルタリングする。 - オンライン検証：[20]PREPAREと同等の動的リソーススケーリング技術を使用して、メトリクスレベルで特定する。 - 実験設定：データセットは、サンプリング間隔１秒で、各アプリケーションの実行時間は1時間程度である。故障内容は、単一箇所故障：CPUHog、MemHog、NetHog（httperfで負荷をかける）、複数箇所の同時故障：ロードバランサ故障、Hadoopの全Mapノードへの注入など、ボトルネック故障：低いCPUキャップをいれる。 ベースラインは、ヒストグラム（最新ウィンドウと全体ウィンドウでの[[KLダイバージェンス]]）、[[2009__SIGCOMM__Detailed Diagnosis in Enterprise Networks|NetMedic]]、アプリケーショントポロジー、依存関係、[[2011__SLAML__PAL - Propagation-aware Anomaly Localization for Cloud Hosted Distributed Applications|PAL]]、固定フィルタリングである。評価指標はPrecision/Recall。ルックバックウィンドウ(W)を100秒である。 - 実験結果：FChainが最良だが、PALを圧倒するわけではない（図６）非常に高速に発現するCpuHogとNetHogに対しては、ヒストグラム方式がうまく機能しないが、メモリリークでは効果的である。Topology方式とDependency方式は 、MemHogとCpuHogの故障に対して非常に低い精度であり、最終階層であるDBサーバに注入したため、バックプレッシャー効果が観察された。ボトルネック故障については、故障が非常に速く伝播するため全方式で精度が低い（図７）。同時複数故障では、システムSのCPUHogで低い結果は平滑化により変化開始時刻を真の原因成分よりも早くしてしまう副作用のためである。しかし、オンライン検証により、ボトルネック故障とCPUHogの精度は改善される。 - ![[Pasted image 20230430084825.png|400]] - ![[Pasted image 20230430085537.png|400]] - 感想：提案法の特定精度は、異常の時刻時刻に依存するため、故障伝搬速度が速い故障では精度が低いと予想しながら読むと、実験のボトルネック故障で精度が低いことが検証されており、好感がもてる。後続論文では、[[2019__ISSRE__FluxRank―A Widely-Deployable Framework to Automatically Localizing Root Cause Machines for Software Service Failure Mitigation|FluxRank]]以外で、異常の開始時刻に着目している論文はない。しかし、メトリクス収集インターバルとして1秒に設定していることは、特に2013年当時に高解像度でメトリクス取得することは監視システムの負荷を考慮すると困難であったはずなので、FChainが有利に働くような恣意性があるようにみえる。 15秒や60秒インターバルなら異常の開始時刻に差がみられず、特定精度が大幅に低下するのではないか。また、オンライン検出問題であるにも関わらず、診断全体の実行時間について ## Abstract クラウドシステムで動作する分散アプリケーションは，リソース競合，ソフトウェアバグ，ハードウェア障害など様々な理由により，性能異常を起こしやすい．異常な分散アプリケーションを診断するための大きな課題の1つは、故障したコンポーネントをピンポイントで特定することです。本論文では、性能異常が検出された直後に故障したコンポーネントをピンポイントで特定できるFChainと呼ばれるブラックボックス型オンライン故障特定システムを提案する。FChainは、まず、正常な作業負荷の変動による多くの変化点から異常な変化点を識別することにより、異なる構成要素における異常動作の開始時刻を発見する。次に、異常な変化の伝播パターンとコンポーネント間の依存関係から、原因コンポーネントを特定する。FChainは、さらに誤報を排除するために、実行時検証を行う。我々は、Xenプラットフォームの上にFChainを実装し、いくつかのベンチマークアプリケーション（RUBiS、Hadoop、IBM System S）を使用してテストしました。その結果、FChainは数秒以内に高い精度で欠陥のあるコンポーネントを迅速に特定できることが分かりました。FChainは既存の方式と比較して、最大で90%の高精度、20%の高リコールを達成することができます。FChainは非侵入型で軽量であるため，クラウドシステムに与えるオーバーヘッドは1%未満である． [[2013__DCS__FChain―Toward Black-box Online Fault Localization for Cloud Systems__translations]]