イベントとリソース定義から作成した依存グラフを用いた連鎖障害の調査時間の短縮 / DPS-206

第206回DPS・第112回CSEC合同研究発表会

Transcript

1. 小山 智之*†，串田 高幸*，生野 壮一郎* *東京工科大学大学院 バイオ・情報メディア研究科 コンピュータサイエンス専攻 †株式会社メルカリ 2026年3月18日，第206回 マルチメディア通信と分散処理 研究会，@神奈川工科大学 イベントとリソース定義から 作成した依存グラフを用いた 連鎖障害の調査時間の短縮 1
2. はじめに • Webアプリケーション“Doktor” • クラウド・分散システム研究室の論文を公開 • マイクロサービスアーキテクチャで設計 • システム障害が発生 • 根本原因：Rook Ceph *のノードがダウン *ソフトウェア定義ストレージのミドルウェア • 根本原因の分析（RCA: Root Cause Analysis） • システム管理者はログ，メトリクス，トレース から根本原因を特定 • マイクロサービスの数だけ調査対象が存在 • 経験の浅いエンジニアは調査に時間を消費 * https://rook.io/ DoktorのWeb UI 2
3. 課題 • インフラ・ミドルウェアに関連する 障害原因の調査． • 実際の根本原因が，障害原因の候補リストに 含まれない． • 既存研究 • 調査範囲がアプリケーションに限られている． • ミドルウェア・インフラへの対応が必要 • 目的 • ミドルウェアやインフラに根本原因のある障害で， 根本原因を出力する． 3 根本原因 # リソース名 1 OSD Pod 2 Persistent Volume 3 MongoDB Pod 4 アプリPod 障害原因の候補リスト
4. 関連研究 シングルモーダル型[1,2] マルチモーダル型[3,4] ログ トレース • 単一データソースをRCAに使用 • ミドルウェア状態の分析に情報不足 [1] L. Wu, et al., "MicroDiag: Fine-grained Performance Diagnosis for Microservice Systems," 2021 IEEE/ACM International Workshop on Cloud Intelligence, Madrid, Spain, 2021, pp. 31-36 [2] L. Pham, et al., “BARO: Robust Root Cause Analysis for Microservices via Multivariate Bayesian Online Change Point Detection,” Proc. ACM on Software Engineering, vol. 1, no. FSE, pp. 2214-2237, Jul. 2024, [3] H. Wang, et al., "Groot: An Event-graph-based Approach for Root Cause Analysis in Industrial Settings," 2021 36th IEEE/ACM International Conference on Automated Software Engineering, Melbourne, Australia, 2021, pp. 419-429 [4] C. Lee, et al., "Eadro: An End-to-End Troubleshooting Framework for Microservices on Multi-source Data," 2023 IEEE/ACM 45th International Conference on Software Engineering, Melbourne, Australia, 2023, pp. 1750-1762 [5] 小山 智之，串田 高幸，生野 壮一郎， "Kubernetesのリソースイベントと依存グラフとトレースによる障害の原因調査にかかる時間の短縮," 第33回マルチメディア通信と分散処理ワークショップ (DPSWS 2025) 講演論文集, 2025, pp. 268–275. • 複数データソースをRCAに使用 • Kubernetesリソース依存関係の分析が 不足 根本 原因 メトリクス ログ 根本 原因 根本 原因 4 • 以前の研究[5]ではイベントとトレース，マニフェストによる根本原因の分析を提案 • エラーの有無に関わらずトレースを抽出しており，混在する状況での精度に課題
5. 提案方式: EventRCA • ミドルウェアの障害に対する 根本原因分析の手法 • マルチモーダルアプローチ • データソース： トレース，イベント，リソース定義 • トレースとリソース定義から リソース依存グラフを構築 • 各リソースのイベント数を集計 • エンドツーエンド経路ごとにイベント 数の増加を検出 • 原因とスコアを出力 0.0495 stats/ConfigMap/istio-ca-root-cert 0.0495 stats/LocalStorage/empty-dir 0.0495 /StorageProvisioner/rook-ceph.rbd.csi.ceph.com スコアの例 Type Reason Age From Message ---- ------ ---- ---- ------- Normal Scheduled 69s default-scheduler Successfully assigned default/ubuntu to clematis-worker2 イベントの例 5
6. 提案方式: EventRCA 6 依存グラフの作成 (1) トレースフィルタでエラーを含む トレースのみ収集 (2) トレースに含まれる各スパンから 対応するリソース名を取得 (3) Kubernetesクラスタのコントロール プレーンからリソース定義を取得 (4) リソース定義同士を比較し， パラメータの一致するリソースを探す． (5) 一致するリソース同士を 依存グラフとして書き出す． { "from":"front/Pod/front-app-deploy-6b4dbf8d84-rbwvx", "to":"front/ConfigMap/istio-ca-root-cert" } 依存グラフの例
7. 提案方式: EventRCA スコアの計算 7 𝑒1 𝑒2 Pod1 Pod2 Service 依存グラフ イベント Service 𝑒3 𝑒4 Pod1 イベント数=2 イベント数=2 Pod2 𝑒5 イベント数=1 Type Reason Age From Message ---- ------ ---- ---- ------- Normal Scheduled 69s default-scheduler Successfully assigned default/ubuntu to clematis-worker2 イベントの例 リソース イベント 1 Service イベント数=2 Pod1 イベント数=2 Service イベント数=2 Pod2 イベント数=1 合計=4 合計=3 2 # リソース名 1 Pod2 2 Pod1 3 .. 4 .. 障害原因の候補リスト
8. 評価指標・実験環境 評価指標 • 情報検索の評価(Hits@k, MRR)を利用 • 根本原因(1件)がスコアリストに含まれるか (1)Hits@k (k=1,2,3,4,5) • エンジニア 386 人への調査結果によると，障害の原 因調査の出力のうち重視する結果は上位 5 件[1] • 上位k件に正解が含まれる場合に1, 含まれない場合に0をとり，その平均を求める． (2)Mean Reciprocal Rank (MRR) • MRR = 1 𝑁 σ𝑖=1 𝑁 1 𝑟𝑎𝑛𝑘𝑖 (3)実行時間 • プログラムの実行開始から終了までにかかる時間 𝑟𝑎𝑛𝑘𝑖 :𝑖番目の結果で最初に 正解が出現する順位 実験環境 • 比較対象：MicroRCA • VMware ESXi上に4ノードの Kubernetesクラスタを構築 • アプリケーション：Doktor* 論文検索サイト *https://github.com/cdsl-research/doktor-v2 7つのマイクロ サービス システム構成図 8 [1] Kochhar, Pavneet Singh, et al. "Practitioners' expectations on automated fault localization." Proceedings of the 25th international symposium on software testing and analysis. 2016.
9. 障害シナリオ • S1：Rook Cephの不整合エラーを再現 • 2025年6月にDoktorのWebサービスの商用環境で，1台のKubernetesノードがメモリ不足で外部 から接続不能に • Kubernetesノードの再起動を行った後に，Rook Cephの不整合が発生した • (シナリオ) 1台のノード(VM)の電源OFFを行い，ノードが応答しない障害を再現 • S2：Rook Cephの実際の不整合エラー • 2025年11月にKubernetesノードがメモリ不足で外部から 接続不能に • (シナリオ) 実際に発生した障害を対象に実験 9 *関連事例 https://github.com/rook/rook/discussions/14474 https://github.com/rook/rook/issues/13995
10. 実験結果 Hits@k(k=1,2,3,4,5) • 2種類の障害シナリオでHits@kを比較 • 凡例: 手法とシナリオ名のペア • 提案手法(Event RCA)のMicroRCAに比べてHits@kがk=5で平均で0.88高い →88%の確率で上位5件に原因箇所が含まれる． better k=1 ConfigMap/istio-ca-root-cert k=2 LocalStorage/empty-dir k=3 StorageProvisioner/rook- ceph.rbd.csi.ceph.com 原因箇所の候補(上位3件, k=3) 10 リソースA リソースB リソースC リソースD リソースE 依存グラフの別の リソースが選択される
11. 実験結果 MRR (Mean Reciprocal Rank) • 2種類の障害シナリオでMRRを比較 • 提案方式(EventRCA)はMicroRCAに 比べてMRRが28.0%高い • 3位~5位に分布 better 実行時間 • 障害シナリオ1で実行時間を10回計測 し，平均を比較 • 提案方式(EventRCA)はMicroRCAに比べ て実行時間が平均で2.18秒短い • 依存グラフの解析が実行時間を消費 better 11
12. 議論 • リソースのライフサイクル(作成，更新，削除)に応じて出力 • 提案手法ではリソースイベントの件数に着目 • リソースの内部状態の解析は含まれない． • リソースの内部状態の詳細な解析(なぜエラーか)が可能 • ログの肥大化 • Tencent社の商用システムでは1秒あたり数千万件のログが出力[1] • 固定した割合でのサンプリングは調査に必要なログを破棄 →システムの異常度にもとづく動的なサンプリング[2] 12 [1] Yu, Muzhi, et al. "TencentCLS: the cloud log service with high query performances." Proceedings of the VLDB Endowment 15.12 (2022): 3472-3482. [2] Meng, Shicong, and Ling Liu. "Enhanced monitoring-as-a-service for effective cloud management." IEEE Transactions on Computers 62.9 (2012): 1705-1720. リソース イベント ログ
13. まとめ 目的 • Kubernetesにおけるミドルウェアの障害に対する障害原因の分析 課題 • 既存のRCA手法ではアプリケーションを対象にしており，ミドルウェア・インフラからア プリケーションへの連鎖障害に対応できず． 提案手法 • ミドルウェア・インフラの障害を対象にイベント，依存グラフ，トレースを使ったRCA • リソース依存関係に着目し，イベント増加と根本原因を検出 結果 • 提案手法のHits@k (k=5)はベースライン手法に比べて0.88高い • 提案手法の実行時間はベースライン手法に比べて2.18秒短い 13
14. 付録 • 依存グラフ 14