# Localizing and Explaining Faults in Microservices Using Distributed Tracing **論文情報**: IEEE 15th International Conference on Cloud Computing (CLOUD), 2022, pp. 489–499 **著者**: [[Jesus Rios]], [[Saurabh Jha]], [[Larisa Shwartz]](いずれも [[IBM Research]]) **DOI**: 10.1109/CLOUD55607.2022.00072 ## 概要 コンテナ化されたクラウド環境で稼働する大規模マイクロサービスアプリケーションにおける障害箇所の特定は、困難かつ時間を要する作業である。本論文は分散トレーシングを用いて、アプリケーション層の障害を自動検知・箇所特定し、その説明支援を行う新しいフレームワーク **FSF(Faulty Service Finder)** を提案する。よく知られたマイクロサービスベンチマーク(Train-Ticket)への障害注入実験により FSF の有効性を実証し、他の障害箇所特定手法と比較した。 ## 問題設定 - マイクロサービスアーキテクチャでは障害が伝播する「障害嵐」が発生し、起点となる障害を特定することが困難。 - ログは大量に生成され情報過多になりやすく、マイクロサービスをまたがるリクエストの文脈が失われる。 - 監視・デバッグツールがモノリシックアプリ向けに設計されており、分散アプリに適用できない。 - 既存の因果推論アプローチは、リクエスト単位の因果モデルでなくアプリケーション全体の依存グラフに基づくため、エラー伝播とリクエストの相互作用を正確にモデル化できない。 ## 提案手法: FSF(Faulty Service Finder) FSF は以下の 3 サービスで構成される。 1. **トレースフィルタ**: リアルタイムにトレースキューを消費し、HTTP エラーを含むスパンを検出して障害箇所特定キューへ転送。 2. **障害箇所特定サービス**: アルゴリズム 1(後述)を実行し、障害を起こしたマイクロサービスを特定。関連ログも抽出。 3. **ダッシュボード**: SRE が `<trace_id, faulty_service, contextual_logs>` を参照できるウェブ API。 ### 設計原則(6 原則) 1. **アプリケーション層への集中**: マルチクラウド/ハイブリッドクラウドに対応するため、アプリ層テレメトリのみを使用。 2. **異種テレメトリの融合**: トレースとエラーログを組み合わせ、空間的・時間的オブザーバビリティを向上。 3. **因果推論による説明可能な箇所特定**: 障害伝播の知識とクライアント-サーバーモデルを組み込んだ因果推論。 4. **コンテキスト対応ログマイニング**: 特定した障害サービスのスパン時間窓内のログのみを抽出。 5. **教師なし ML**: ラベリングや学習データが不要。稀な障害にも対応。 6. **低コスト自動化**: モデルの学習・再学習が不要。 ### 障害箇所特定アルゴリズム(Algorithm 1) トレースをスパンの木として解析する因果推論手法: 1. すべてのスパンから **ERROR_SPANS** を収集(5xx かつ任意スパン、4xx かつクライアントスパン)。 2. エラーのある子スパンを持つスパンを除去(子の失敗が原因として説明できるため)。 3. 残ったスパン(子に失敗原因がない)が根本原因の箇所特定情報を持つと判断。 4. サーバースパンの場合: そのマイクロサービスを障害箇所と特定。 5. クライアントスパンの場合: - 4xx → そのマイクロサービス自身が原因(クライアント起因エラー)。 - 5xx → HTTP リクエスト先のホストが原因(サーバー側は応答不能)。 6. 障害箇所のスパン時間窓内のログを **GET_LOGS** で抽出。 **特徴**: 各トレースから実行時に因果モデルを動的に抽出するため、アプリ全体の静的依存グラフに依存しない。 ## 実験設定 - **基盤**: RedHat OpenShift Container Platform (OCP) クラスタ 6 ノード / OpenShift 4.7 - **テレメトリ**: Jaeger(分散トレーシング) + logDNA(ログ収集) + Istio サービスメッシュ - **ベンチマーク**: Train-Ticket(41 マイクロサービス、鉄道チケット予約システム) - **ユーザーフロー**: 41 サービスのうち 33 をカバーするユーザーシミュレーション - **障害種別**: - `http-service-unavailable`(HTTP 503): Istio の障害注入機能を使用。32 サービスに注入。 - `http-bad-request`(HTTP 400): ソースコード改変による。18 サービスに注入。 - `http-resource-not-found`(HTTP 404): ソースコード改変による。18 サービスに注入。 - 合計 68 件の障害注入実験(503 が 32 件、400/404 が各 18 件)。 - **評価指標**: loss = 推定セットに含まれる誤った箇所の数(0 が理想) ## 実験結果 - **FSF(Algorithm 1)**: 全 68 件の障害注入で完全に正確な検知・箇所特定を達成。偽陽性なし。**平均 loss = 0**。 - **比較手法(ログのみの因果推論)**: - ログのみ + 依存グラフ: 平均 loss = **10.84** - ログ + テキスト解析で改良: 平均 loss = **5.69** - 文献中の最良手法: 平均 loss = **8.24** ![[wiki/sources/_attachments/cloud22/fig2a-comparison-chart.png]] ![[wiki/sources/_attachments/cloud22/fig2b-comparison-chart.png]] *図 2: 分散トレーシングの有無による障害箇所特定結果の比較(loss が低いほど良い)* ログのみの手法が劣る理由: マイクロサービス A と B が共に C に依存する場合、C のエラーが A と B のどちらへ伝播するかは、実際のリクエストに基づく因果関係に依存する。静的依存グラフでは把握できず、トレースツリーが提供するリクエスト単位の因果モデルが必要。 ## 実践経験: 診断・緩和への応用 1. **非注入障害の自動発見**: Train-Ticket 動作開始時に MongoDB ソケット例外から発生する内部障害を FSF が自動検出し、設定変更で解消。 2. **ログの説明能力の強化**: 利用不能なマイクロサービスがログを出力できない場合でも、トレースデータから障害ホストを特定し、クライアントログで補完。 3. **複数同時障害の検出**: 注入した障害と内部的な JWT 障害(ts-assurance-service)を同時検出。ログが内部障害の原因(空の JWT 文字列・未処理例外)とコード行を特定。 ## 他手法との比較 | 手法 | 入力 | 精度 | |---|---|---| | MicroHECL | メトリクス | 48% | | MonitorRank | メトリクス | 32% | | Microscope | メトリクス | 35% | | Pinpoint | トレース(学習あり) | ~72%(検知+特定) | | MEPFL | トレース(学習あり) | localization 78.8% | | TFI | トレース(学習あり) | 11.7%(同一設定以外) | | **FSF(本手法)** | **トレース(学習なし)** | **100%(loss=0)** | ## 考察 - **分散トレーシングの価値**: テレメトリデータの種別が log → metric → trace と移行するにつれ、障害箇所特定の精度が向上する(§VII 結論)。 - **教師なしの利点**: 訓練データが不要で、本番環境でリアルタイムに機能し、アプリ変更後の再学習も不要。 - **本番適用のバリア**: 分散トレーシングの計装が前提。現代は OpenTelemetry 等で自動計装が容易になったが、オーバーヘッドは存在。 ## 強み - 教師なしでゼロショット動作: 学習フェーズ・障害注入データ・ラベリングが不要。 - 100% 精度の実証(Train-Ticket・68 件)。 - ログとトレースの融合による「どこで」「なぜ」の一体提供。 - 複数同時障害への対応。 - アプリケーション層への集中でクラウド中立性を確保。 ## 弱点・課題 - **障害モデルの限定性**: リクエスト失敗(フェイルストップ)のみ対象。性能関連障害(テールレイテンシ等)は SLO 違反をタイムアウト障害に変換する拡張が必要。 - **インフラ層障害への非対応**: ホスト障害やネットワーク輻輳が複数サービスに同時影響する場合、各サービス障害を個別検出するが、共通インフラ原因を識別できない。 - **トレーシングのオーバーヘッド**: 計装と実行時のオーバーヘッドが存在(小さいが無視できない)。 - **評価スケール**: Train-Ticket の 41 サービスでの評価であり、より大規模(数百〜数千サービス)での検証が必要。 ## 関連 - ソース: [[@2002__DSN__Pinpoint - Problem Determination in Large, Dynamic Internet Services]] / [[@2014__OSDI__lprof - A Non-intrusive Request Flow Profiler for Distributed Systems]] - 概念: [[Fault Localization]] / [[分散トレーシング]] / [[根本原因分析]] / [[マイクロサービスアーキテクチャ]] / [[因果推論ベースRCA]] - エンティティ: [[Jesus Rios]] / [[Saurabh Jha]] / [[Larisa Shwartz]] / [[IBM Research]] / [[Train-Ticket]] - 関連 MOC: [[AIOps - Failure Detection - MOC]] / [[SRE - MOC]] ## 出典 - 本論文全文 `.raw/papers/CLOUD22.txt`(§I〜§VIII)