> [!abstract] 概要(記事冒頭の要旨の日本語訳) > 現代のデータセンターは、フェイルストップ・フェイルパーシャル・ビザンチンなど様々な種類の障害を受けやすい。ソフトウェアとハードウェア双方の近年の進歩により、これまで見過ごされてきたフェイルスロー障害が前面に出てきた。フル速度と機能不全の中間状態で立ち往生するフェイルスローなコンポーネントは、かなり低い性能を示す傾向にある。先行研究と我々自身の分析は、フェイルスロー障害が現場において広く見られるだけでなく、影響も大きいことを示唆している。本記事では、クラウド上のストレージデバイス向けに実用的なフェイルスロー検知フレームワークを構築した際の教訓と経験を共有する。 ## 論文情報 - タイトル: Detecting Fail-Slow Failures in Large-Scale Cloud Storage Systems - 著者: Ruiming Lu, Erci Xu, Yiming Zhang, Fengyi Zhu, Zhaosheng Zhu, Mengtian Wang, Zongpeng Zhu, Guangtao Xue, Jiwu Shu, Minglu Li, Jiesheng Wu - 所属: 上海交通大学(Ruiming Lu 他)・[[Alibaba Cloud]](Erci Xu, Fengyi Zhu, Zhaosheng Zhu, Mengtian Wang, Zongpeng Zhu, Jiesheng Wu)・厦門大学(Yiming Zhang)・清華大学/厦門大学(Jiwu Shu)・浙江師範大学(Minglu Li) - 媒体: USENIX ;login: online、「Deployed System」区分。2023-02-06 公開(2023-02-09 最終更新)。編集担当(shepherd): Rik Farrow - 位置づけ: 本記事は査読論文そのものではなく、著者ら自身による FAST '23 論文「PERSEUS: A Fail-Slow Detection Framework for Cloud Storage Systems」の実務者向けサマリー([6])。参考文献 [7] は同じ著者グループによる USENIX ATC '22 論文「NVMe SSD failures in the field: the Fail-Stop and the Fail-Slow」で、[[@2026__TOCS__Fail-Slow Hardware Failure Bug Analysis and Detection for Cloud Systems]] が引用する Lu らの実測(NVMe SSD の年間フェイルスロー率 1.41%)と同一系列の実測データに基づく - データセット: 公開データセット「Fail-slow detection open dataset」(https://tianchi.aliyun.com/dataset/144479)として公開 ## 概要 Alibaba のクラウドストレージ運用チームが、ストレージデバイス(HDD/SSD)のフェイルスロー障害を非侵入的・細粒度・高精度・汎用的に検知するフレームワーク PERSEUS を開発した経緯を報告する。3 つの失敗した先行アプローチ(閾値フィルタリング・ピア評価・IASO ベースモデル)から得た教訓を設計指針に転化し、レイテンシ対スループット(LvT)分布への多項式回帰でノードごとの適応的しきい値を自動導出する PERSEUS を提案、実運用データで既存手法を大きく上回る精度を達成した。 ## 問題設定 入力はストレージデバイス(HDD/SSD)の運用統計時系列——各ノードに配置された監視デーモンが 15 秒ごとにドライブのレイテンシとスループットの平均を記録する(1 日 3 時間・1 ドライブあたり 720 エントリ、総計約 1000 億エントリのデータセットを構築)。出力は各ドライブがフェイルスローである尤度(risk score)であり、二値のフェイルスロー/非フェイルスロー判定ではない。制約条件として、クラウドベンダーはテナントのソフトウェアを改変できない(non-intrusive)、根本原因の箇所特定にはデバイス単位の細粒度が必要(fine-grained)、誤検知を避けて高精度でなければならない(accurate)、多様なクラウドサービス(ブロックストレージ・データベース等)に最小限の調整で適用できる必要がある(general)、という 4 つの設計目標(Design Goals of Fail-slow Detection)が課される。 ## 提案手法 ### 3 つの失敗した先行試行とそこから得た教訓 **試行1: 閾値フィルタリング(Threshold Filtering)**。ドライブレイテンシに固定の閾値(例: 45µs)を設け、誤ラベリングを避けるため最小継続時間も併せて要求する。 **Figure 1: 高負荷による急激なレイテンシ上昇** ![[_attachments/usenix-loginonline-detecting-fail-slow-failures-2023/fig01-latency-throughput-spikes.png]] ((a) 書き込みレイテンシと (b) 書き込みスループットの時系列。赤い点はレイテンシが素朴な警報閾値(45µs、破線)を超える区間を示す。21:29・21:34・21:40 頃の 3 回のレイテンシスパイクは、対応するスループットのスパイクと重なっており、ワークロード負荷の増加が原因であることが分かる。Source: 記事 Figure 1) 限界: レイテンシはワークロードに強く左右されるため、緩い閾値は正常な性能変動をフェイルスローと誤ラベリングし、厳しい閾値は多くのフェイルスロー事例を見逃す。ドライブモデル・ワークロードごとに閾値を個別チューニングするのは時間がかかりすぎる(実運用ではタイムアウトのようなフェイルセーフ手段として閾値ベース検知を併用するにとどめている)。 **試行2: ピア評価(Peer Evaluation)**。負荷分散された分散ストレージシステムでは同一ノード内のドライブが類似のワークロード圧力を受けるという前提のもと、ノードレベルの移動中央値レイテンシを 15 秒ごとに計算し、監視ウィンドウ(例: 5 分)の半分超で中央値の 2 倍を継続的に超えるドライブをフェイルスローと判定する。 **Figure 2: ピア評価** ![[_attachments/usenix-loginonline-detecting-fail-slow-failures-2023/fig02-peer-evaluation.png]] (候補ドライブのレイテンシ(赤)をノードレベルの中央値(青)と比較するピア評価の結果。5 分のスライディングウィンドウを使用。候補ドライブは灰色区間で示された 3 つの時間窓(①②③)で低速(50% 超のレコードが中央値の 2 倍を上回る)と判定される。Source: 記事 Figure 2) 限界: 適応的な閾値(青線)は得られるが、低速度の程度や監視ウィンドウ幅など経験的パラメータのチューニングが必要で、300 ノード規模のクラスタでオンサイトエンジニアが 2 時間を要した割に、同一サービス・同一ドライブモデルの別クラスタには通用しなかった。 **試行3: IASO ベースモデル**。IASO はソフトウェアのタイムアウトを情報量のあるメトリクスに変換してフェイルスローをベンチマークするノードレベル検知フレームワークである[9]。Alibaba はテナントコードに手を入れられないためソフトウェアタイムアウトを直接使えず、試行2 のピア評価によるフェイルスローイベント報告で代替する形で再構築を試みた。 限界: 自前のベンチマークで Precision 0.48 と不満足な性能に留まった。ソフトウェアタイムアウトの代替としてピア評価のイベント報告を使ったことが主因と推測され、閾値による代替も試したが同様に不満足だった。 ### PERSEUS の設計指針(3 つのリサーチクエスチョン) 3 つの失敗から導かれた設計指針: - **RQ1: ワークロード圧力をどうモデル化するか**——Figure 1a/1b の観察から、レイテンシはスループットとより強い相関を持つ(IOPS よりも)ため、スループットでワークロード圧力をモデル化する。 - **RQ2: 適応的閾値をどう自動導出するか**——レイテンシ対スループット(LvT)分布に回帰モデルを適用し、正常ドライブの振る舞いを記述してその予測上限を適応的閾値とする。回帰対象の粒度(サービス単位・クラスタ単位・ノード単位)を検討する必要がある。 **Figure 3: 異なる LvT 分布** ![[_attachments/usenix-loginonline-detecting-fail-slow-failures-2023/fig03-lvt-distribution-scales.png]] (データベースサービスにおける (a) 3 クラスタのサービス単位 LvT 分布(黄・青・赤で色分け)、(b) 同一クラスタ内 2 ノードのクラスタ単位分布、(c) 同一ノード内ドライブのノード単位分布。スループット(単位: B/s)は log10 スケール。サービス単位・クラスタ単位ではクラスタ間・ノード間で分布が大きく乖離する一方、同一ノード内のドライブ群(c)は色分けされていてもよく重なり合っている。Source: 記事 Figure 3) 同一サービス内の複数クラスタ((a))・同一クラスタ内の複数ノード((b))は分布が大きく乖離する一方、同一ノード内の複数ドライブ((c))は明確にクラスタして重なる。他サービスのノードでも同様の傾向が確認されたため、**ノード単位の回帰**を採用する。 - **RQ3: 基準なしにどうフェイルスローを判定するか**——フェイルストップと異なりフェイルスローには明確な判定基準が存在しない。二値判定ではなく、ドライブがフェイルスローである尤度を出力する設計に転換する。 ### PERSEUS の 4 ステップ **Figure 4: PERSEUS 設計図** ![[_attachments/usenix-loginonline-detecting-fail-slow-failures-2023/fig04-perseus-design-diagram.png]] (生データから、PERSEUS は低速(赤)を正常(灰)から区別するため、予備的な外れ値検知(①)を伴う回帰モデル(②)を構築する。スライディングウィンドウで、連続する低速レコードをフェイルスローイベント(③)として定式化し、低速の継続時間と度合いに基づきリスクスコアを割り当てる(④)。Source: 記事 Figure 4) **Step 1: 外れ値検知**。回帰モデル構築前にノイズの多いサンプル(外れ値)を除去する。まず DBSCAN で外れ値をラベル付けするが、レイテンシとスループットが正相関するためサンプルが特定方向に偏り、外れ値が内側点として誤ラベルされる(下図(a)の黒丸)。 **Figure 5: 外れ値検知** ![[_attachments/usenix-loginonline-detecting-fail-slow-failures-2023/fig05-outlier-detection-dbscan-pca.png]] ((a) DBSCAN 単独、(b) DBSCAN の前に PCA を適用した場合の回帰モデル性能。同一ノードの日次生データにフィッティングした多項式回帰(青の実線が回帰曲線、緑の破線が 99.9% 予測上限)を示す。(a)では DBSCAN が低速エントリの 63.83% しか検知できていない(黒丸内が誤ラベルされた外れ値)。(b)PCA で座標変換し偏った方向に垂直な外れ値にペナルティを課すことで、DBSCAN+PCA は 92.55% を検知する。Source: 記事 Figure 5) PCA(主成分分析)で座標変換し、偏った方向に垂直な外れ値にペナルティを課すことで DBSCAN+PCA は 92.55% を検知するよう改善する。外れ値の二値判定結果自体は直接フェイルスローの判定には使わず(Step 2・3 を経て低速度合いを測るためのより良い回帰モデルを作るためだけに使う)。 **Step 2: 回帰モデル**。同一ノード内の正常ドライブは類似した LvT マッピングを持つため、回帰モデルで「正常」ドライブの振る舞いを記述しフェイルスロー検知の変動範囲を画定する。線形回帰は非線形性を捉えられないため不採用、カーネル回帰のような高度なモデルは LvT マッピングがほぼ単調(スループット増加に伴いレイテンシも増加)であるため不要。多項式回帰が非線形性への対応とパラメータの節約(モデル簡潔性)を両立する。 **Step 3: フェイルスローイベントの特定**。回帰モデルから予測上限(例: 99.9% 上限、すなわち 99.9% の変動を正常、残り 0.01% を低速とみなす)を計算し、低速エントリを識別する。ドライブレイテンシを予測上限で割った時系列を Slowdown Ratio(SR)として定義し、固定長のスライディングウィンドウ(最小継続時間)内で SR の中央値が閾値を超える割合が一定の比率に達すればフェイルスローイベントとして記録する。一過性のスパイクエントリのみでは記録しない(持続的な低速エントリ列のみを対象とする)。 **Figure 6: 低速イベントの特定** ![[_attachments/usenix-loginonline-detecting-fail-slow-failures-2023/fig06-slowdown-event-identification.png]] ((a) 元のドライブレイテンシ時系列("Data")と、回帰モデルから計算したフィッティング値("Fit.")・上限値("Upp.")。(b) 上限値を元データで割ったスローダウン比の時系列。SR が 1 を超えるレコードは低速とみなされる。灰色ボックス2つはレイテンシスパイク(①)と一過性のスローダウンイベント(②)を示すが、フェイルスローイベントとして記録されるのは持続的な②のみ。Source: 記事 Figure 6) **Step 4: リスクスコア**。フェイルスローイベントが 1 回でもあれば即座に「フェイルスロー」とラベル付けすると、悪い日には約 6000 件もの「フェイルスロー」候補が発生してしまう。そこで性能回帰テストのリスクスコア手法[5]に倣い、低速の継続時間と度合いをリスクレベルに分類する。 **Table 1: フェイルスローリスクマトリクス** | Slowness \ Duration(min) | Long-term ≥120 | Moderate [60,120) | Temporal [30,60) | |---|---|---|---| | Severe (SR≥5) | Extreme | High | Moderate | | Moderate (SR∈[2,5)) | High | Moderate | Low | | Mild (SR∈[1,2)) | Moderate | Low | Minor | (Table 1. 日次累積スローダウンイベントに基づくリスクレベル割当。例えば 1 日の Extreme リスクは長時間(120〜180 分)の持続的低速かつ SR≥5 の重度スローダウンを要する。) さらにドライブごとのリスクスコアを、各リスクレベルに重みを付けて累算する: $Risk\ Score = N_{extreme} \times 100 + N_{high} \times 25 + N_{moderate} \times 10 + N_{low} \times 5 + N_{minor} \times 1$ ($N_{extreme}$ は Extreme リスク該当日数を指す。以下同様。数日にわたりリスクスコアが最小値を超えるドライブは即時の隔離・ハードウェア点検が推奨される。HDD・SSD 問わず全ドライブに同一のスコアリング機構を適用する。) ## 実験設定 - データセット: 前述の約 1000 億エントリの自前収集データセットに基づき、明確にラベル付けされた大規模公開ベンチマークを構築・公開(https://tianchi.aliyun.com/dataset/144479) - 評価指標: Precision(適合率)・Recall(再現率)・Matthews Correlation Coefficient(MCC) - 比較対象: Thresh-Stat(統計的閾値ベース)・Thresh-Emp(経験的閾値ベース)・PeerEval(ピア評価)・IASO-Based(IASO ベースモデル) ## 実験結果 **Table 2: 総合評価結果** | Metric | Thresh-Stat | Thresh-Emp | PeerEval | IASO-Based | PERSEUS | |---|---|---|---|---|---| | Precision | 1.00 | 1.00 | 0.98 | 0.48 | 0.99 | | Recall | 0.52 | 0.02 | 0.57 | 0.24 | 1.00 | | MCC | 0.72 | 0.14 | 0.74 | 0.32 | 0.99 | (Table 2. 統計的境界(Thresh-Stat)・経験的境界(Thresh-Emp)による閾値フィルタリング、ピア評価(PeerEval)、IASO ベースモデル、PERSEUS の評価スコア。) PERSEUS は Recall 1.00・MCC 0.99 と、全フェイルスロードライブを検出しつつ正常ドライブをほぼ誤ラベリングしない。閾値ベース手法は高 Precision だが低 Recall(見逃しが多い)、IASO-Based は Precision・Recall とも低い。デプロイ後、PERSEUS は約 25 万台のドライブをカバーし、304 台のフェイルスロードライブを検出した。 ## 考察 著者らは PERSEUS が非侵入的(コード改変なし)・細粒度(ドライブ単位)・汎用的(異なる設定に同一パラメータ集合)・高精度(高 Precision・Recall)という 4 つの設計目標を達成したと結論づける。核心はワークロード圧力をスループットでモデル化し、ノード単位の LvT 分布に多項式回帰を適用することで、サービス単位・クラスタ単位では成立しない適応的しきい値をノード単位でのみ自動導出できるという発見にある。 ## 強み / 弱点・課題 **強み**: 3 つの失敗した先行試行(閾値フィルタリング・ピア評価・IASO ベースモデル)を単に失敗として片付けず、各々の限界を具体的な設計指針(RQ1〜RQ3)へ転化している点が本記事の実務的価値である。特に「ノード単位でのみ LvT 分布が均質になる」という Figure 3 の観察は、既存研究のピア評価(ノードレベルの中央値比較)がなぜ適応的しきい値のチューニングを要したかを、回帰の粒度選択という観点から説明し直すものである。約 1000 億エントリの実データセットに基づく大規模公開ベンチマークの提供も、後続研究([[@2026__TOCS__Fail-Slow Hardware Failure Bug Analysis and Detection for Cloud Systems]] が引用する Lu らの実測値等)の基盤になっている。 **弱点・課題**: - 本記事は査読論文の実務者向けサマリーであり、FAST '23 本体([6])に比べて実装の詳細(回帰の次数、ハイパーパラメータの選定方法、リスクスコアの重み係数の根拠)は省略されている。 - 対象はストレージデバイス(HDD/SSD)のレイテンシ/スループットに限定されており、[[@2026__TOCS__Fail-Slow Hardware Failure Bug Analysis and Detection for Cloud Systems]] が扱うネットワーク由来の細粒度フェイルスロー(NIC 等)や、ソフトウェア(同期・タイムアウト機構)を突き崩す因果連鎖は本記事のスコープ外である。 - 「悪い日には約 6000 件のフェイルスロー候補」という数字の元になったベースライン手法(単純な二値検知)の詳細が示されておらず、この数字の再現性は検証できない。 - 精度評価はデータベースサービスを中心とした事例(Figure 1〜3)に基づいており、他サービス(ブロックストレージ等)での定量評価は記事内に明示されていない。