APSEC upto 10 page 日本語で13ページぐらい？ ## タイトル クラウドで発生する性能異常の迅速な診断に向いた時系列データの次元削減手法 ## 方針 - 背景: 分散アプリケーションの複雑化 （マイクロサービスに限定しない） - 問題: 根本原因がわからない - 高速性が必要。 - 既存手法: 原因箇所の特定が限定的 - 各グラフノードの系列の種別の組が同一でなければならない。 - 組の要素数が一定数。代表的なメトリックを指定する。 - 実システムでは複数次元ある - Knowledge Graphの研究では、複数次元かつ組の要素が不一致でも対応できるが、メトリックを指定して実行している。 ![[Pasted image 20210520161600.png]] - 全系列指定すると時間がかかる （実験で確認したほうがよい？ -> Knowledge Graphの実装と実験が必要） - 異種混合ノードでどれが重要なメトリックかがわからない。コンポーネントごとにメトリックを指定する設定管理が必要となる。 - 提案手法: 原因診断のための前処理である次元削減手法を提案。 - 貢献1: 正確性を維持しつつ、高速性・次元削減率を両立 - 貢献2: 次元削減により、系列数が増大したときに、実行時間が長くなる学習・推論アルゴリズムの実行時間を短縮を期待できる。余分なノイズを省いた結果、精度があがることもありえる？ ## メモ - 多数のメトリック系列をみないと原因にたどり着けないことを2章あたりで示す。 - 故障注入ケースを増やす。 - メモリ負荷 - I/O負荷 - max connections - ノイジーネイバー - 良い次元削減ができたかどうかの評価 - システム管理者が1データずつチェックする？ - 次元削減の効果を示すナイーブな解析手法がないか？ - 因果探索にかけるだけだとだめだった - カスタムメトリックのみが特徴的な挙動をするケース - ノイジーネイバー ## IOTS2020後の修正案 ![[Pasted image 20210520151414.png]] ![[Pasted image 20210520151428.png]] - max connections - ノイジーネイバー - Locust徐々に負荷増やす ![[Pasted image 20210520151525.png]] - メトリックの次元が揃わない状況へ対応する必要性があることに言及 ![[Pasted image 20210520151536.png]] - TSifterだけだと認知負荷が下がるわけではない。TSifterはあくまで、前処理。 ![[Pasted image 20210520151543.png]] ![[Pasted image 20210520151558.png]] - 2段階ステップのそれぞれの評価 ![[Pasted image 20210520151610.png]] - 距離の閾値パラメータを変化させて、次元削減率を評価する - 正確性の定義は、原因メトリックが残っているかだけでいいかなあ。実験で多数のデータがあればそれでいいか。 原因メトリック以外に、応答速度など特徴的な症状を示すメトリックが残っていればokとするのはいいかも。 ![[Pasted image 20210520151619.png]] - 系列の長さをかえるとどんな影響があるか ## 障害に関する文献 [[2019__ICSE__Automating chaos experiments in production]] - Gray Failureを新しい異常注入ケースにしようかと思ったけど、TSifterでどうにかできる異常なのかよくわからない。 [[2020__HOTOS__What bugs cause production cloud incidents?]] - あくまでバグに焦点をあてているので、ちょっと違うかも。 [[2016__SOCC__Why does the cloud stop computing? Lessons from hundreds of service outages]] - いろいろなサービス障害を分類してまとめてくれている。根本原因もまとめられているので、どんな異常を注入するかの根拠になりそう。