## I.Introduction マイクロサービスアーキテクチャの出現は、きめ細かな自律型サービスを用いてソフトウェアアプリケーションを開発、デプロイ、保守する新しいパラダイムを推進している[1]。マイクロサービスアーキテクチャでは、各サービスは独立して動作し、Web APIを介して通信を行います。マイクロサービスアーキテクチャは、実装、再利用、コンポーネントの独立したスケーリングのための抽象化とモジュール化を容易にします[2]。マイクロサービスベースのアプリケーションやサービスは、継続的なリファクタリングによって急速に進化するため、このような複雑なシステムを確実に稼働させ続けるための新たな課題を提示しています。マイクロサービスアプリケーションを監視するための様々なソリューションが開発されてきましたが、残念ながら、絶えず変化するマイクロサービス指向のアプリケーションの異常を診断する場合、単一のQoS（Quality-of-Service）指標に基づくアルゴリズムは通常失敗します。その結果、調査すべきメトリクスやサービスが非常に多いため、根本的な原因を特定するのに時間がかかり、専門家であってもイライラしてしまいます。 この問題を解決するために、マイクロサービスアーキテクチャから収集した複数のメトリクスを分析するための自己適応型の根本原因診断フレームワーク（MS-Rank）を提案します。我々の貢献は以下の通りです。まず、MS-Rankに基本的なメトリクスと暗黙のメトリクスを導入し、異常時のサービス間の因果関係を発見するためのインパクトグラフ構築アルゴリズムを提案する。第二に、ランダムウォークに基づく根本原因診断アルゴリズムを提案し、根本原因となるサービスをヒューリスティックに特定するために、前方遷移、自己遷移、後方遷移を設計する。第三に、診断精度に応じて異なるメトリクスの信頼度を動的に更新する自己最適化メカニズムを確立する。 MS-Rankを検証し、選択したベンチマークと比較するために、プロトタイプを開発し、IBMクラウドに統合する。実験結果は、MS-Rankが高速な識別と正確な診断結果を提供することを示しています。MS-Rankは、予備知識を必要とせず、複数の種類のマイクロサービスシステムに迅速に導入することができます。また、専門家の経験と簡単に組み合わせることができ、診断効率と診断結果の精度を向上させることができます。 ## SECTION II. Related Works マイクロサービスアーキテクチャが登場する以前から、ネットワークトラフィック解析 [3] や Web サービスの異常検知 [4] など、関連する問題に対して様々な研究が行われてきた。複雑なネットワークシステムの根本原因を特定するために，しきい値処理 [5], [6]，決定木 [7]，ベイズネットワーク [8]，クラスタリング [9], [10]，マルコフ予測モデル [11]，機械学習 [12] などの様々な手法が活用されてきた． 最近の研究では、一般的にパフォーマンスメトリクス[9]とシステムトポロジー[10]に基づいた知識マイニングに焦点が当てられている。分散監視施設からメトリクスを収集するためには、中央エージェントが必要とされるのが一般的である[13]。これらのアプローチのほとんどは、トポロジー[14]、トランスポート層のパケットフロー[15]、またはサービス呼び出し関係[13]などの事前知識を必要とする。この要件は、このようなアプローチの適用性に影響を与える。そのため、システムプロファイルを発見することからこの問題を探り、ヒューリスティックな方法で異常を特定する取り組みもある[16] [17] [23]。例えば，異常伝播を表現するために不変グラフ[18]が提案されている．静的なネットワーク構造におけるこれらの伝搬リンクは，ある種の信頼性の高い依存関係を表しているが，マイクロサービスアーキテクチャにおいては，より動的なものとなる．Microscope [30] や Sieve [31] などの因果関係発見アルゴリズムを用いて動的なサービス依存関係を取得することを提案している研究者もいる。Microscope は、単一のメトリックに基づいて因果関係グラフを構築するために並列化された PC アルゴリズム [26] を使用し、条件付きグラフトラバースアルゴリズムを活用して根本原因を特定しています。Sieve は、サービスコンポーネント間の依存関係を取得するために Granger Causality [32] を使用しています。サービスの依存関係を構築するために、ネットワーク・トラフィック・データの収集に依存しています。しかし、既存のシステムでそのようなデータを収集するためにエージェントを配備するには、追加のコストが必要です。 NetMedic [19]、Sherlock [20]、SherLog [21]、Gestalt [22]、LOUD [12]を参照のこと。しかし、マイクロサービスアーキテクチャは、より高次元で動的な依存関係を生成し、根本原因を特定するための新たな課題を提起しています。そこで本研究では，システム知識を必要とせず，マイクロサービスシステムにおける複数の種類のメトリックを自動的に処理できる動的な根本原因診断手法を確立することを目的としている． ## 3. Problem Statement A. 背景と動機 サービスの欠陥は、時折、マイクロサービスアーキテクチャのシステム異常を引き起こすことがあります。このような信頼性の問題は、ホストのリソースの制限、ハードウェアの可用性、ネットワークの不安定性など、様々な理由によって引き起こされることがあります。サービスを信頼性の高い形で定期的に稼働させるために、通常、マイクロサービスベースのアプリケーションには、健全なチェックエンドポイントとパフォーマンスメトリック収集メカニズム（例えば、レイテンシやスループット）が導入されています。これらは、アプリケーションやサービスが健全に動作していることを確認するのに役立ちます。しかし、アプリケーションは様々なマイクロサービスで構成された複雑なシステム上で実行されているため、異常が発生したときに根本的な原因を特定することは困難です。実際の運用では、サービスの欠陥が高レイテンシ、低スループット、許容できないユーザビリティなどの異常を引き起こすことがあります。これらの商用システムの中には、SRE (Site Reliability Engineer) チームが異常を無意識のうちに監視し、修正しているものもあります。システムが複雑なため、経験と知識のあるSREであっても根本原因を特定することは困難です。 B. 予備的な前提と問題定義 サービスV（ここでは他のサービスをバックエンドと呼ぶ）から一定期間内にフロントエンドサービスvfeに異常が観測されたとする．本研究の目的は，vfeと他のバックエンドサービスから収集した複数種類のメトリクスに基づいて，異常の原因となっているサービスを特定することである．本研究では、マイクロサービスアーキテクチャをブラックボックスとして扱う。本研究では，マイクロサービスアーキテクチャをブラックボックスとして扱う．その結果、本研究では、異なるサービス間の通信パケットを収集するモジュールなどには依存しない。この要件は、提案されているソリューションでは一般的である。しかし，この要件は通常，より高い導入コストをもたらし，提案手法の適用性に影響を与える．言い換えれば、我々の仮定は、我々の解決策がより多くのシナリオに適合することを保証するものである。さらに、本論文では、領域知識をどのようにして解決策と組み合わせるかを議論し、その有効性を実証する。 ## IV. Proposed Solution