> [!abstract] 概要(Abstract の日本語訳) > 現代のインターネットアプリケーションの複雑化とマイクロサービスアーキテクチャの普及は、システム安定性を維持するための効率的なトレース異常検知の必要性を増大させた。多くのトレース異常検知アルゴリズムが異常挙動の識別のために提案されてきたにもかかわらず、これらの手法の包括的な評価は欠如しており、開発者が実世界のアプリケーションに最も適したアルゴリズムを選ぶことを困難にしている。このギャップに対処するため、我々はトレース異常検知のための包括的かつ拡張可能なベンチマークである TADBench を提示する。TADBench は多様な公開トレースデータセットとアルゴリズムを統一リポジトリに集約し、データフォーマットを標準化し、人手による異常ラベルを組み込む。再現性と公平な比較を確保するため、我々はエンドツーエンドのモデル評価をサポートするモジュール化された評価フレームワークを提案する。加えて、我々は特定のデータ属性に基づくアルゴリズム選択の実践的ガイダンスを、異なる特性を持つデータセット群にわたる性能評価によって提供し、学術研究と産業展開のギャップを効果的に埋める。我々の知る限り、これはトレース異常検知アルゴリズムの初の包括的な実証研究である。我々の知見は、これらの手法の本番環境への導入を促進し、開発者と研究者に実用的な洞察を提供することを目指す。 > > インデックス用語 — トレース異常検知、実証研究。 ## 論文情報 - タイトル: A Comprehensive Benchmark and Empirical Study of Trace Anomaly Detection - 著者: Yongqian Sun(Member, IEEE)・Minyi Shao・Xiaohui Nie(Member, IEEE)・Kaiwen Yang・Xingda Li・Bowen Hao・Shenglin Zhang(Member, IEEE)・Changhua Pei・Dongbiao He・Yanbiao Li・Dan Pei(Senior Member, IEEE) - 所属: [[Yongqian Sun]]・Minyi Shao・Kaiwen Yang・Xingda Li・Bowen Hao・[[Shenglin Zhang]] は [[Nankai University]] College of Software。[[Xiaohui Nie]]・[[Changhua Pei]]・Dongbiao He・Yanbiao Li は Computer Network Information Center (CNIC), Chinese Academy of Sciences (CAS)。[[Dan Pei]] は [[Tsinghua University]] Department of Computer Science and Technology(corresponding author: Xiaohui Nie)。 - 媒体: IEEE Transactions on Services Computing(2025 年に accepted、著者版。最終出版に向け編集中との注記あり) - DOI: 10.1109/TSC.2025.3622122 - コード・データ: https://github.com/nkalgo/TADBench.git(オープンソースデータリポジトリ 3.6GB、約 104 万トレース) ## 概要 本論文は、マイクロサービスのトレース異常検知アルゴリズムを横断比較する初の包括的ベンチマーク TADBench を提案する。トレース収集・前処理・モデル適合・モデル評価の 4 段階からなる評価フレームワークを構築し、5 つの公開データセット(TrainTicket, GAIA, AIOps2020, AIOps2022, AIOps2023)を統一データフォーマットに標準化した上で人手ラベルを付与し、VAE ベース・GNN ベース・LSTM ベースの 7 アルゴリズムを同一条件で比較する実証研究を行う。単一の万能アルゴリズムは存在しないという知見に基づき、トレース深さ・スパン数・サービス数・異常比率という 4 つのデータ特性から最適アルゴリズムを選ぶ決定木ベースの推奨戦略を提示する。 ## 問題設定 - **入力**: OpenTracing 形式に準拠する分散トレース(Jaeger・Zipkin・SkyWalking 等が生成)。トレースは trace_id で一意に識別され、各スパンは trace_id・span_id・parent_span_id・start_time・duration・service_name・operation_name・status_code を持つ。 - **出力**: トレース単位(および将来的にはスパン単位)の異常判定。異常は latency anomaly(スパンの実行時間が正常範囲を逸脱)と structural anomaly(サービス呼び出し順序の逸脱。さらに unexpected service call・missing call・call order error の 3 種に細分)の 2 種類に大別される(Fig. 2〜5、`wiki/sources/_attachments/TSC3622122/fig01-microservice-system-trace.png` 参照)。 - **前提条件・必要データ**: 障害注入情報(fault microservice 情報・fault 発生時刻)を持つ生トレースデータ。TADBench の 5 データセットのうち TrainTicket・AIOps2022・AIOps2023 は障害注入で、GAIA は CloudWise マイクロサービスシミュレーションシステム由来、AIOps2020 は実本番マイクロサービスシステム由来。 **Figure 1: Microservice System and Trace** ![[_attachments/TSC3622122/fig01-microservice-system-trace.png]] (Fig. 1. マイクロサービスシステムはサービス層・コンテナ層・サーバー層の 3 層からなり(ts-travel-service・ts-ticketinfo-service 等の例)、1 つのトレースは trace_id で識別される 7 スパンの木構造として表現される。各スパンは trace_id・span_id・parent_span_id・service_name・operation_name・start_time・duration・status_code を記録する。Source: 論文 Fig. 1、Section II-A。) ## 提案手法 - **評価フレームワーク(アーキテクチャ)**: trace collection → trace preprocessing → model adaptation → model evaluation の 4 段階(Fig. 7)。まず利用可能なトレースデータを収集し、次に統一フォーマットへ前処理し、各アルゴリズムのデータフォーマット要件へ適合させ、最終的に実験結果に基づき性能を評価する。 **Figure 7: Evaluation Framework** ![[_attachments/TSC3622122/fig07-evaluation-framework.png]] (Fig. 7. ① Trace Collection(SkyWalking/Zipkin 等由来の生トレース)→ ② Trace Preprocessing(データフォーマット統一・異常ラベリング)→ ③ Model Adaptation(Multimodal LSTM・TraceAnomaly・CRISP 等各アルゴリズムへの入力適合)→ ④ Model Evaluation(Leaderboard・モデル選択戦略)の 4 段階パイプライン。Source: 論文 Fig. 7、Section III。) - **統一データフォーマット**: GAIA と AIOps2022 のように、データセットごとにフィールド名・フィールド数・値の単位が異なる問題(Fig. 8a/8b)に対処するため、Trace クラスと Span クラスの 2 クラスからなる統一フォーマットを提案する。Trace クラスは trace_id・root_span・span_count・anomaly_type(0=正常, 1=レイテンシ異常のみ, 2=構造異常のみ, 3=両方)・source を持つ。Span クラスは trace_id・span_id・parent_span_id・children_span_id・start_time・duration・service_name・operation_name・anomaly・status_code・latency・structure・extra を持つ(Fig. 9)。この統一化により、新規データセットは 1 度統一フォーマットへ変換するだけで、追加の前処理なしに全アルゴリズムと互換になる。 **Figure 9: Unified Format** ![[_attachments/TSC3622122/fig09-unified-format.png]] (Fig. 9. Trace クラス(trace_id・root_span・span_count・anomaly_type・source)と Span クラス(trace_id・span_id・parent_span_id・children_span_id・start_time・duration・service_name・operation_name・anomaly・status_code・latency・structure・extra)からなる統一フォーマットの定義。Source: 論文 Fig. 9、Section III-A。) - **データラベリング**: 障害注入情報を用いてトレースを正常トレースと fault-injected トレースに分割する(Fig. 10)。 - レイテンシ異常検知: 呼び出しパスに基づきサービスをグループ化し、正常トレースにおけるサービスレイテンシをガウス分布でモデル化する。平均 µ・標準偏差 σ に対し `L ∉ [µ-3σ, µ+3σ]` を満たすレイテンシ L を異常と判定する(3-sigma rule、式 1)。 - 構造異常検知: 正常トレースから全パターンとその頻度を収集し、fault-injected トレースの構造が正常データセットに存在するか(稀か)を判定する。稀・不在の場合、Jaccard 類似度 `J(T,P) = |S(T)∩S(P)| / |S(T)∪S(P)|`(式 2)により最も類似する正常パターン `P* = argmax J(T, Pi)`(式 3)を選び、最終的に人手で欠落呼び出し・予期しない呼び出し・呼び出し順序誤りの有無を確認して構造異常ラベルを確定する。 **Figure 10: Trace Labeling Process** ![[_attachments/TSC3622122/fig10-trace-labeling-process.png]] (Fig. 10. Fault Injection Information と Unlabeled Traces から Pre-classification を経て、Latency Anomaly Labeling(Grouped Service's Latency Statistics → Gaussian Distribution Detection)と Structural Anomaly Labeling(Trace Pattern's Frequency Computing → Jaccard Similarity Comparison → Human Feedback)の 2 系統に分岐し、Labeled Traces に至る。Source: 論文 Fig. 10、Section III-B。) - **アルゴリズム SDK**: 各アルゴリズムに共通の抽象基底クラス `TADTemplate(ABC)` を継承させ、`preprocess_data()`・`train()`・`test()` の 3 抽象メソッドで入出力フォーマットを標準化する(Fig. 11)。これにより新規アルゴリズムの評価パイプラインへの統合が簡素化され、フォーマット適合のための追加実装コストが削減される。 - **アルゴリズム分類**: 統計ベース/モデルベースという従来の分類は深層学習モデルの多様化に対応できないため、本論文はアーキテクチャに基づく VAE ベース・GNN ベース・LSTM ベースの 3 分類を提案する(Fig. 6、`wiki/sources/_attachments/TSC3622122/fig06-algorithm-taxonomy.png`)。PUTraceAD のみ半教師あり(semi-supervised)で、他は教師なし(unsupervised)。 - VAE ベース: TraceAnomaly(deep variational Bayesian network + posterior flow、Service Trace Vector で正常パターンを再構成)、CRISP(critical path 抽出による Service Critical Path Vector、再帰アルゴリズム)、TraceVAE(Graph-VAE で構造 VAE・時間 VAE を分離モデル化、GAT で trace graph のノード間相関を捕捉)、GTrace(graph-wise・node-wise VAE の組み合わせ、Tree-LSTM で同一部分木構造の共有エンコーディングを生成し substructure-based グループ化で検知効率を向上)。 - GNN ベース: PUTraceAD(GAT + nnPU アルゴリズムによる半教師あり検知、WordPiece + 事前学習 BERT で service/operation 名を 768 次元埋め込み化)、TraceCRL(GraphCL に基づく contrastive learning、DeepWalk で操作のベクトル表現を生成、invocation の開始時刻分位点・局所実行時間比率などの詳細時間特徴を利用、One-Class SVM で後段検知)。 - LSTM ベース: Multimodal LSTM(各スパンを one-hot call path encoding + 正規化 duration のベクトルで表現し、時間・構造特徴を結合表現に統合、LSTM で系列依存をモデル化)。 ## 新規性 - 既存研究は個別の閉じたデータセットで評価されており、公開トレースデータセット・アルゴリズムを体系的に集約した公開ベンチマークが存在しなかった(Data availability の課題)。TADBench はこれを 3.6GB・約 104 万トレースの単一オープンソースリポジトリとして解消する。 - 既存トレースデータセットには明確な異常ラベルが一般的に欠如していた。TADBench は Gaussian 分布検知(レイテンシ異常)+ Jaccard 類似度 + 人手確認(構造異常)の 2 系統ラベリングプロセスで約 21 万トレースにラベルを付与した。 - 標準化された評価フレームワーク・アルゴリズム SDK の欠如(再現性問題)に対し、統一データフォーマット + 共通抽象基底クラスによるモジュール化評価フレームワークを提案した。 - アルゴリズム選択の実証的知見・推奨戦略の欠如に対し、著者らの知る限り初めてトレース異常検知アルゴリズムの包括的実証研究を行い、決定木に基づくデータ駆動型の推奨戦略を提示した。 ## 実験設定 - **ハードウェア**: Intel(R) Xeon(R) Gold 5416S CPU × 2、RAM 376GB、NVIDIA RTX A6000 GPU × 7(各 48GB)。 - **データセット**: TrainTicket(PUTraceAD 論文由来のオープンソースデータ、TrainTicket マイクロサービスシステムへの障害注入で生成)、GAIA(CloudWise マイクロサービスシミュレーションシステム由来、異常検知・ログ解析・障害箇所特定用)、AIOps2020/2022/2023(CCF International AIOps Challenge 2020/2022/2023 データ、AIOps2020 は実本番システム由来、AIOps2022/2023 は障害注入によるシミュレーション)。 - データセット特性(Table I): 平均トレース深さ 3.3(TrainTicket)〜5.5(AIOps2020)、平均スパン数/トレース 9.3(GAIA)〜39.0(TrainTicket)、監視粒度は Operation(TrainTicket, AIOps2022)/Service(GAIA, AIOps2020, AIOps2023)、サービス規模 10(GAIA, AIOps2020)〜40(AIOps2022)、平均サービス数/トレース 1.3(AIOps2023)〜7.8(AIOps2020)。 - 異常比率(Table II): 全体 21.8%(AIOps2020)〜53.6%(AIOps2023)、構造異常 3.5%(AIOps2020)〜39.0%(AIOps2023)、レイテンシ異常 21.5%(AIOps2020)〜35.9%(AIOps2022)。 - **比較対象**: Multimodal LSTM、TraceAnomaly、CRISP、PUTraceAD、TraceCRL、TraceVAE、GTrace の 7 アルゴリズム。原論文既定のハイパーパラメータを基本とし、性能が不十分な場合のみ調整。各実験は最低 3 回実施。 - **データ分割**: 各データセットで正常トレースを 2:1 の比率で訓練/テストに分割。全異常トレースはテストセットに含める。 - **評価指標**: Precision `TP/(TP+FP)`(式 4)、Recall `TP/(TP+FN)`(式 5)、F1-score(Precision と Recall の調和平均、式 6)、Accuracy `(TP+TN)/(TP+TN+FP+FN)`(式 7)、Time Consumption(訓練・検出時間)。 ## 実験結果 - **RQ1(全データセット一貫最良アルゴリズムの有無、Table III)**: 存在しない。GTrace が TrainTicket(F1=99.4%)・AIOps2020(F1=71.8%)で最良、TraceVAE が GAIA(F1=90.9%)・AIOps2022(F1=78.9%)で最良、PUTraceAD が AIOps2023(F1=74.7%)で最良。 **Figure 13: F1-score Comparison Across Datasets** ![[_attachments/TSC3622122/fig13-f1score-comparison.png]] (Fig. 13. TrainTicket・GAIA・AIOps2020・AIOps2022・AIOps2023 の 5 軸レーダーチャートで 7 アルゴリズムの F1-score を比較。GTrace(灰色破線)は TrainTicket・AIOps2020 で外周に達し優位、TraceVAE(緑色)は GAIA・AIOps2022 で優位、PUTraceAD(黄色)は AIOps2023 寄りでは中位。Source: 論文 Fig. 13、Section IV-B。) - **異常タイプ別性能(Table IV、データセット横断集計)**: TraceVAE は構造異常検知 F1=96.8%(GNN エンコーダによるトポロジ依存関係の明示的捕捉に起因)。GTrace はレイテンシ異常検知 F1=78.2%(span レベルでのレイテンシ特徴モデリングに起因、他手法は trace レベルのみで動作)。 - **リーダーボード(Fig. 12)**: precision・recall・F1-score・accuracy・time consumption を total/structural/latency の 3 異常タイプ別に対話的にソート可能な形で提示。 **Figure 12: Trace Anomaly Detection Algorithm Leaderboard** ![[_attachments/TSC3622122/fig12-leaderboard.png]] (Fig. 12. TrainTicket ベンチマークの Latency タブ表示例。GTrace が F1=93.1%(Precision 94.0%, Recall 92.3%, Accuracy 98.8%, Time 3201.0s)で 1 位、PUTraceAD が 2 位(F1=90.7%)、TraceVAE が 3 位(F1=85.2%, ただし Time=51496.0s と最も遅い)。CRISP・Multimodal LSTM・TraceAnomaly・TraceCRL が続く。Source: 論文 Fig. 12、Section IV-E。) - **RQ2(データ特性の影響)**: - トレース深さ(Fig. 14): 深さ ≤3 では TraceVAE が最良(F1=92.2%、PUTraceAD 91.6%・GTrace 91.4%が僅差で続く)。深さ >6 では TraceVAE が F1=82.3% で GTrace(66.5%)を大きく上回る。 - スパン数(Fig. 15): 1〜5 スパンでは GTrace(F1=99.7%)・TraceVAE(99.4%)・PUTraceAD(99.1%)がいずれも約 99%。11〜30 スパンと 30 超では GTrace が最良(70.7%・60.8%)。6〜10 スパンでは TraceVAE が最良(74.2%)。CRISP はスパン数増加とともに単調に性能向上(1〜5 スパン 24.3% → 30 超 59.3%)。 - サービス数(Fig. 16): 1〜4 サービスでは TraceVAE(89.7%)>GTrace(83.5%)>Multimodal LSTM(78.3%)。5〜8 サービスでも TraceVAE が最良(67.9%)。8 超では GTrace が最良(68.1%、TraceAnomaly は 59.6%)。 - 異常比率(Fig. 17): 異常比率 0%では GTrace(68.7%)、0.5%では TraceVAE(69.1%)、1%では GTrace(61.8%)、3%では TraceVAE(56.6%)が最良。PUTraceAD は 0%/0.5%で検知能力を失うが 1%で 41.9%・3%で 55.0%に達する(positive-unlabeled learning の性質上、十分な正例(異常)サンプルが必要なため)。 - **効率性分析(Table V、TrainTicket 51,386 訓練トレース・51,309 正常+25,197 異常テストトレース)**: 訓練時間は Multimodal LSTM が最短(419s)、TraceVAE が最長(23497s)。検出速度は GTrace が最速(10211 traces/s、キャッシュ技術とトレースグループ化による)、TraceAnomaly・CRISP が最遅(107 traces/s)。 - **RQ3(推奨戦略、Fig. 18)**: 決定木モデルにより異常比率・スパン数・トレース深さの複合条件からアルゴリズムを推奨。異常比率 ≥10%では PUTraceAD。10%未満かつスパン数 ≤5 または >30 では GTrace。スパン数 6〜10 ではトレース深さ ≤3 で TraceVAE、>3 で GTrace。スパン数 11〜30 では異常比率 ≤1%または >3%で TraceVAE、それ以外(1〜3%)で GTrace。 **Figure 18: A decision tree based on multiple datasets' characteristics** ![[_attachments/TSC3622122/fig18-decision-tree.png]] (Fig. 18. anomaly ratio ≥10% → PUTraceAD。<10% → span count で分岐: ≤5 または >30 → GTrace。5〜10 → trace depth で分岐(≤3 → TraceVAE、>3 → GTrace)。10〜30 → anomaly ratio で再分岐(≤1%または >3% → TraceVAE、1〜3% → GTrace)。Source: 論文 Fig. 18、Section IV-E。) ## 考察 - **既存アルゴリズム選択への示唆**: 最もアーキテクチャが複雑または最新の手法が全シナリオで最良とは限らない。実践者はまず自身の本番トレースデータのスパン数・サービス数・トレース深さ・異常比率を分析した上で推奨戦略に従うべき。高異常比率データには PUTraceAD、多スパン/多サービスには GTrace、浅いトレース深さには TraceVAE を推奨。 - **限界と今後の方向性**: (1) 既存の多くのアルゴリズムは trace レベルでの判定にとどまり、根本原因分析に必要な span レベルの詳細診断ができていない。(2) 既存手法の強みを統合する方向性として、TraceVAE の Bernoulli & Categorical Scaling・Node Count Normalization・Gaussian Std-Limit(エントロピーギャップ削減)を GTrace の階層的グラフエンコーディングアーキテクチャ(global structure modeling と node-level feature processing の分離、dynamic programming + LRU キャッシュされた木によるバッチ処理)と組み合わせる構想を提示する。 - **脅威(Threats to Validity)**: アルゴリズム側は原論文既定ハイパーパラメータへの依存(データセット固有のチューニングでより良い結果が得られる可能性)、データセット側は 5 データセットが実世界シナリオの多様性を完全には反映しない可能性。 ## 強み / 弱点・課題 - **強み**: 5 データセット・7 アルゴリズムを統一フォーマット・共通評価パイプラインで横断比較した初のベンチマーク。約 21 万トレースの人手ラベルとコード・データのオープンソース公開により再現性を確保。トレース深さ・スパン数・サービス数・異常比率という 4 軸でのアルゴリズム性能の定量的な傾向分析と、決定木による実践的な選択指針を提供。 - **弱点・課題**: 著者ら自身が認める限界として、span レベルの細粒度異常検知への対応が手薄(trace レベル判定が主流)。ハイパーパラメータは原論文既定値ベースで、データセット固有の最適化余地がある。5 データセットのみでの評価であり、実世界の多様なシナリオを完全にはカバーしない。