## Memo 本論文は[[2017__CCS__DeepLog - Anomaly Detection and Diagnosis from System Logs through Deep Learning|DeepLog]]を応用した論文である，提案手法がだいたい理解できたのでまとめる． 多くの既存のマイクロサービスの異常検知の研究では，メトリクス間の相関関係，またはメトリクスと障害イベントとの相関関係に焦点を当てているが，この研究では，ログの異常検知に焦点を当てている． ログの異常検知で得られた異常スコアと相関の高い指標があれば，その指標が根本原因である可能性が高いという洞察に基づいている． ログの異常検知はDeepLogを採用している． 上のページにまとめているが，DeepLogにはログキー列を用いた実行パスの異常検知と，パラメータ値を用いた性能の異常検知の二つの異常検知の仕組みがある．本論文では前者はそのまま採用し，後者はログキー中に埋め込まれたパラメータ値は用いず，直前のログとのtimestampの差のみを入力するデータとしている． 二つの異常検知の仕組みから得られた異常スコアの加重平均を実際の異常スコアとしている．（実験ではwは0.5のため単純な平均と同じ） ここまでで得られた異常スコアの時系列データと相関が強いメトリックを探索する．相関の指標として，[[相互情報量]]を採用している．これは相関の指標として広く用いられる[[ピアソン相関係数]]よりも非線形依存性を捉えられると言及していた． 通常，相互情報量を計算するには，確率分布（確率密度関数）を仮定する必要があるが，それは多くの場合で困難である．そこで，[[k-最近傍法]]からのエントロピー推定に基づいて確率密度を推定するいくつかの手法を採用している．（詳細は以下の論文を参照） [Estimating Mutual Information](https://arxiv.org/abs/cond-mat/0305641) [Mutual Information between Discrete and Continuous Data Sets](https://journals.plos.org/plosone/article?id=10.1371/journal.pone.0087357) 相互情報量より得られた異常スコアと相関が強いものをソートして，そのTop-kから障害原因となるメトリックを特定する．評価では，おおよそTop-15には根本原因となるメトリックが含まれていたとしている． ## 手法の制約 ここは論文に書いてあるわけではなくて，論文を読んで考えたこと． まず，単純な話として，提案手法ではログとメトリックの情報を用いているが，異常検知はログでしか行っていないので，ログには異常が現れないけどメトリックに異常が現れているようなケースは検知できない． 次に，ログで異常を検知した後に，そこから相関に基づき原因特定をしようとしているが，単純な相互情報量ではデータの時系列性の情報が消失している．つまりログの異常スコアの変動と原因メトリックの変動が時間軸に対してずれた位置に現れるとき，おそらく検知ができない．つまりログの異常とメトリックの異常が同時に発生していることを想定している． この後者の制約を解決しようとするとどういったやり方があるのかは考えてみる価値があるかもしれない．[[ピアソンの相関係数]]や[[相互情報量]]では時間軸に対するずれを取り扱うことができないし，[[2015__SIGMOD__k-Shape - Efficient and Accurate Clustering of Time Series|k-Shape]]の[[Shape-based distance|SBD]]では時間軸に対するずれは取り扱うことはできるが，メトリック同士の形状が似ている必要がある．ここをうまく設計できると，TSifterの次元削減後のメトリックをダッシュボードなどでソートする際のスコアの設計にも繋がるかもしれないので，考えていきたい． ## Abstract マイクロサービスシステムは、その複雑さと大規模さから、一般的に壊れやすく、障害は避けられません。しかし、複雑な依存関係や膨大な数の様々なメトリクスがあるため、根本原因となるメトリクスを特定することは困難です。既存の手法は、メトリクス間の相関またはメトリクスと故障の相関のいずれかに基づいています。これらの手法は、マイクロサービスの重要なデータソースであるログを無視している。本論文では、ログの異常検知を組み込むことで、新しい根本原因のメトリックの特定方法を提案します。我々のアプローチは、障害が発生したシステムのログ異常スコアの変化に伴い、根本原因メトリックの値も変化するはずだという重要な観察に基づいている。具体的には、ログ異常検知アルゴリズムによる異常スコアの収集と、データ増強を伴うロバストな相関分析による根本原因メトリックの特定という2つの要素から構成されています。オープンソースのベンチマークであるマイクロサービスシステムを用いた実験では、本アプローチが既存の手法よりも正確に根本原因を特定でき、短いローカライズ時間で済むことが実証されました。その結果、本手法は既存の手法よりも正確に根本原因を特定することができ、かつ短時間で特定できることがわかりました。 ## I. INTRODUCTION クラウドインフラや大規模システムの利用が急増する中、デプロイやアップデートが独立して行えるマイクロサービス・アーキテクチャが、より多くの企業で広く利用されるようになりました[1]。サービスの品質を保証するために多大な努力が払われてきましたが，マイクロサービス・システムは一般的に脆弱であり，その複雑さと大規模さのために障害は避けられず，莫大な経済的損失やユーザー・エクスペリエンスの低下を招くことになります．例えば、2018年のPrime Day（同社の年間最大のセールイベント）におけるAmazon.comの1時間のダウンタイムによる損失は、最大で1億ドルに上ると言われています1。そのため、ひとたび障害が発生すると、その根本的な原因を突き止め、早急に障害を軽減することが急務となります。 一般的に、システムの稼働状況をリアルタイムに把握するために、監視システムは各マイクロサービス・コンポーネントから多数のメトリクス（CPU使用率やネットワーク遅延など）やログを収集します。システムに障害が発生した際には、障害の根本原因を大きく反映できる根本原因メトリクスを特定する必要があります。例えば、リソースが限られていることが原因で障害が発生した場合、マイクロサービスのCPU使用率を根本原因のメトリックとして特定することで、この障害を診断することができます。しかし、コンポーネント間の複雑な依存関係や障害の伝播などにより、ニュアンスの異なるメトリクスが異常な挙動を示すことがあります。例えば、図1に示す2つのマイクロサービスからなるシステムでは、マイクロサービスはリクエストやメッセージを送信することで相互に作用します。各マイクロサービスは複雑な呼び出しチェーンを持っているため、マイクロサービスAのネットワーク伝送が遅延すると、他のサービスBのCPU使用率や応答速度が不規則に低下します（Bは自分の作業を行うためにAからリクエストを受け取る必要があるからです）。また、A自身にとっても、ネットワーク速度や時間遅延などの指標が、この障害の影響を受ける可能性があります。この伝搬を考えると、どのマイクロサービスがトラブルメーカーなのかを特定することは難しく、ましてや障害の種類を特定することはできません。さらに、障害の伝播は非常に速いため、タイムラグによって根本原因の指標を特定することはできません[2]。そのため、大量のメトリクスの中から根本原因となるメトリクスを特定することは困難です。 故障を診断し，根本的な原因を突き止めるために，多くの取り組みがなされています[3]，[4]，[5]，[6]，[7]．これらの関連研究はすべて，メトリクス間の相関関係[3]，[4]，またはメトリクスと故障（イベント）の相関関係[5]，[6]，[7]に焦点を当てています．しかし、これらの研究では、各マイクロサービスの詳細な動作情報を記録するシステムログなど、監視システムの他のデータソースを十分に活用していません。より具体的には、長年にわたり、ログ異常検知に関する多くの研究努力がなされており、現在のログ異常検知は大きな効果を上げています[8], [9]。したがって、ログ異常検知の技術を活用して、各マイクロサービスの異常度（異常スコアともいう）を得ることができる。もし、ログ異常検知で得られた異常スコアと相関性の高い指標があれば、その指標が根本原因である可能性が高くなります。私たちが知る限り、現実のシステム例外は、IV.で紹介した3つのタイプを含め、システムログと監視指標の両方で観察することができます。つまり、私たちの重要な洞察は、ログ異常検知の蓄積された力を利用して、根本原因となる指標を特定することです。 この洞察に基づき、我々は、主に「異常スコアの収集」と「根本原因メトリックの特定」の2つのコンポーネントからなるアプローチを提案する。具体的には，まず，最先端のログ異常検知アルゴリズムであるDeepLog [8]を採用し，システムの異常スコアを取得する．その後，正常時と異常時のデータの不均衡を考慮して，データのオーグメンテーション（オーバーサンプリングとノイズの追加）を行い，相互情報量に基づくロバストな相関分析を行う．最後に、相関関係の結果に基づいて、エンジニアのための根本原因のランキングリストを提供します。 提案手法の有効性を評価するために，30以上のマイクロサービスを含むTrainTicketというマイクロサービスのベンチマークシステムを用いて実験を行いました[1]．ベンチマークシステムには，コンピューティングリソースの枯渇，ネットワーク伝送の遅延，ネットワーク伝送の中止という3種類の障害を発生させた．本手法は，数百のメトリクスの中から平均して上位15位までの根本原因のメトリクスを特定することができ，有効性と効率性の両面で既存の手法を凌駕している． 要約すると、本研究は以下のような大きな貢献をしています。 - ログの異常検知を利用した故障診断のための新たな原因究明手法を提案する。 - 堅牢な相関分析のために、データ増強の技術を創造的に活用し、その有効性を実証する。 - 本研究では，広く利用されているベンチマークシステムを用いて実験を行い，提案手法が他のベースライン手法と比較して正確かつ効率的に根本原因を特定できることを示した． ## IV. EVALUATION このセクションでは、我々の提案するアプローチのパフォーマンスを評価し、以下のリサーチクエスチョン（RQ）に答えることを目的としています。 - RQ1：我々のアプローチは、他のベースライン手法と比較して、根本原因のメトリックのローカリゼーションに有効か？ - RQ2：各コンポーネントは我々のアプローチに貢献しているか（データ増強と相関分析）？ - RQ3：我々の手法の時間効率はどの程度か？ ### A. Experiment Setup 我々は、[[TrainTicket]][27]という中規模のオープンソースのベンチマークマイクロサービスシステムに基づいて、我々のアプローチのパフォーマンスを評価しました。このプラットフォームは、列車のチケットを販売するシステムであり、マイクロサービス・アーキテクチャーに基づいており、ペイ、プライス、オーダー、フードなどの41のマイクロサービスを含んでいます。また，[[2018__Fault analysis and debugging of microservice systems - Industrial survey, benchmark system, and empirical study]] [1]で示したように，さまざまな種類の障害を手動で注入し，ベンチマークシステムから収集したログやメトリクスに基づいて，根本原因となるメトリクスを正確に特定できるかどうかを確認します．今回の評価では、次の3種類の障害を注入することにしました。 ![[Pasted image 20210819160129.png]] **コンピューティングリソースの枯渇** Stress-ng は、様々な種類のストレスに対処するためのコンピュータシステムの能力をテストするために広く使用されているツールです。stress-ngをデザインネイティブなDockerで実行すると、大量のコンピューティングリソースを必要とする余分なプロセスが存在するため、コンピューティングリソースが極端に不足する可能性があります。そのため、システムの動作に影響を与える必要があります。図6は、フード・マイクロサービスに注入された計算資源の枯渇に起因する、CPU使用率、メモリ使用率、時間遅延、トランザクション成功率などの異常メトリクスを示しています。 **ネットワークの伝送遅延** 全てのマイクロサービスをより信頼性の高い安全な方法で接続するために設計された[[Istio]]によって、HTTP遅延障害を注入します。直感的には、ネットワークの遅延はTrainTicketや、ネットワークの送受信率などのメトリクスにトラブルをもたらします。 **ネットワーク送信の中断** IstioによるHTTPアボート障害を注入します。この場合、障害が発生したマイクロサービスは他のコンポーネントと通信できなくなり、ネットワーク関連のメトリクスに影響を与えます。 ### B. Evaluation Metrics 直感的には，本アプローチの出力は，根本原因となるメトリクスのランキングリストであるため，本アプローチの性能を評価するために，ランキング問題で使用される一般的なメトリクスを採用する．具体的には、トップk精度と平均ランキングを評価指標として使用することにしました。さらに、我々のアプローチの実行時間も考慮に入れています。 ### C. Performance of Root-cause Metric Localization 直感的には，本アプローチの出力は，根本原因となるメトリクスのランキングリストであるため，本アプローチの性能を評価するために，ランキング問題で使用される一般的なメトリクスを採用する．具体的には、トップk精度と平均ランキングを評価指標として使用することにしました。さらに、我々のアプローチの実行時間も考慮に入れています。