JP2023551029A - プロアクティブ異常検出 - Google Patents

Abstract

コンピュータ実装方法、コンピュータプログラム製品、およびコンピュータシステムが提供される。例えば、本発明の実施形態は、要求を受信することに応答して、マイクロサービスアプリケーションの正常動作のための一連の要求のトレースデータおよび仕様を収集することができる。本発明の実施形態は、収集されたトレースデータおよび仕様から、要求文脈的特徴を生成することができる。本発明の実施形態は、生成された文脈的特徴に基づいて、ニューラルネットワークモデルを訓練することと、訓練されたニューラルネットワークモデルを使用して、マイクロサービスアプリケーションの異常動作を予測することができる。

Description

本発明は、一般的にはプロアクティブ異常検出に関し、特に要求文脈的データおよびニューラルネットワークを用いたマイクロサービスアプリケーションのためのプロアクティブ異常検出に関するものである。

マイクロサービスアーキテクチャは、アプリケーションを疎結合のサービスの集合体として配置するものである。マイクロサービスは、モノリシックなアプリケーション（例えば、ウェブコントローラーまたはbackend-for-frontend）内の層ではない。このように、マイクロサービスアーキテクチャは、継続的な配信ソフトウェア開発プロセスに適している。アプリケーションのごく一部に変更を加えても、１または少数のサービスだけを再構築および再展開する必要があるだけである。

一般的に、マイクロサービスアーキテクチャは、クラウドネイティブアプリケーション、サーバーレスコンピューティング、および軽量コンテナ展開を用いたアプリケーションに採用することができる。モノリシックなアプローチでは、３つの機能（フレームワーク、データベース、メッセージブローカーなど）をサポートするアプリケーションは、これらの機能のうちの１つだけがリソースに制約があったとしても、全体をスケールインさせる必要がある。マイクロサービスでは、リソースに制約のある機能をサポートするマイクロサービスのみをスケールアウトする必要があるため、リソースとコストの最適化の利点を提供する。

機械学習（ＭＬ）とは、明示的な指示を使用しない代わりにパターンや推論に依存して特定のタスクを実行するためにコンピュータシステムが使用するアルゴリズムや統計モデルに関する科学的研究である。機械学習は、人工知能のサブセットと考えられている。機械学習アルゴリズムは、訓練データと呼ばれるサンプルデータに基づいて数学的モデルを構築し、タスクを実行するように明示的にプログラムされていなくても予測または意思決定を行う。機械学習アルゴリズムは、電子メールのフィルタリングやコンピュータビジョンなど、タスクを効果的に実行するための従来のアルゴリズムを開発することが困難または不可能な、さまざまなアプリケーションで使用されている。

機械学習において、ハイパーパラメータとは、モデルの外部にあり、その値をデータから推定することができない設定のことである。ハイパーパラメータは、モデルパラメータの推定を支援するプロセスで使用される。ハイパーパラメータは、学習（例えば、訓練）プロセスが始まる前に設定され、対照的に、他のパラメータの値は、訓練によって導かれる。モデル訓練のアルゴリズムによって、必要とされるハイパーパラメータは異なるが、最小二乗回帰のようないくつかの単純なアルゴリズムでは、ハイパーパラメータを必要としない場合もある。ハイパーパラメータのセットが与えられると、訓練アルゴリズムがデータからパラメータ値を学習する。例えば、最小絶対収縮選択演算子（ＬＡＳＳＯ）は、最小二乗回帰に正則化のハイパーパラメータを追加するアルゴリズムで、訓練アルゴリズムでパラメータを推定する前に設定する必要がある。類似の機械学習モデルは、異なるデータパターンを一般化するために、異なるハイパーパラメータ（例えば、異なる制約、重み、または学習率）を必要とすることがある。

深層学習は、複雑な構造などを持つ、あるいはそうでなければ、しばしば複数の非線形変換で構成されるモデルアーキテクチャを使用することによって、データ内のハイレベルの抽象化をモデル化するアルゴリズムのセットに基づく機械学習の一分野である。深層学習は、データの表現を学習することに基づく、より広範な機械学習手法のファミリーの一部である。観測（例えば画像）は、ピクセルごとの強度値のベクトルなどの多くの方法で、またはエッジのセット、特定の形状の領域などのより抽象的な方法で表現することができる。いくつかの表現では、例からタスク（例えば、顔認識または表情認識）を学習することが容易になる。深層学習アルゴリズムでは、特徴抽出と変換のために、非線形処理ユニットの多くの層からなるカスケードを使用することが多い。連続する各層は、前の層からの出力を入力として使用する。アルゴリズムは教師あり、教師なしの場合があり、アプリケーションはパターン分析（教師なし）および分類（教師あり）を含む。深層学習モデルは、生体システムにおける情報処理や分散通信ノードに着想を得た人工ニューラルネットワーク（ＡＮＮ）を含む。ＡＮＮは、生物学的な脳とは様々な違いがある。

ニューラルネットワーク（ＮＮ）は、生物学的なニューラルネットワークから着想を得たコンピューティングシステムである。ＮＮは単なるアルゴリズムではなく、多くの異なる機械学習アルゴリズムが連携して複雑なデータ入力を処理するためのフレームワークである。このようなシステムは、一般に、タスク固有のルールをプログラムされることなく、例を考慮することによってタスクを実行するよう「学習」する。例えば、画像認識において、ＮＮは、他の画像に含まれる猫を識別するために、「猫」または「猫ではない」と正しくラベル付けされた画像例を分析し、その結果を用いることにより、猫を含む画像を識別することを学習する。ＮＮは、例えば、猫には毛・しっぽ・ひげ・とがった耳がある、など、猫に関する予備知識を一切持たずに学習する。その代わりに、ＮＮは学習教材から識別特性を自動的に生成する。ＮＮは、人工ニューロンと呼ばれる接続されたユニットまたはノードの集合体に基づいており、生物学的な脳のニューロンを緩やかにモデル化する。それぞれの接続は、生物学的な脳のシナプスのように、ある人工ニューロンから別の人工ニューロンへ信号を伝達することができる。信号を受信した人工ニューロンは、その信号を処理し、さらに別の人工ニューロンに信号を伝達することができる。

一般的なＮＮの実装では、人工ニューロン間の接続における信号は実数であり、各人工ニューロンの出力は、その入力の合計の何らかの非線形関数によって計算される。人工ニューロン間の接続は「エッジ」と呼ばれる。人工ニューロンおよびエッジは、通常、学習が進むにつれて調整される重みを有する。重みは、接続部の信号の強さを増加または減少させる。人工ニューロンは、集約された信号がその閾値を超えた場合にのみ信号が送信されるような閾値を持つ場合もある。一般的に、人工ニューロンは層に集約される。異なる層は、その入力に対して異なる種類の変換を実行することができる。信号は、最初の層（入力層）から最後の層（出力層）へ、場合によっては層を複数回横断した後に送られる。

本発明の一態様によれば、コンピュータ実装方法が提供される。本方法は、要求を受信することに応答して、マイクロサービスアプリケーションの正常動作のための一連の要求のトレースデータおよび仕様を収集することと、収集されたトレースデータおよび仕様から、要求文脈的特徴を生成することと、生成された文脈的特徴に基づいて、ニューラルネットワークモデルを訓練することと、訓練されたニューラルネットワークモデルを使用して、マイクロサービスアプリケーションの異常動作を予測することと、を含む。

以下、本発明の好ましい実施形態について、以下の図面を参照しながら、例示的にのみ説明する。

本発明の一実施形態に係るコンピューティング環境のブロック図を示す。 本発明の一実施形態に係るマイクロサービスの異常検出器のブロック図の一例を示す図である。 本発明の一実施形態に係るニューラルネットワークモデルを設計するためのブロック図の一例を示す図である。 本発明の一実施形態に係る個々の要求に対する要求内要因を捕捉するニューラルネットワークモデルの例示的なブロック図である。 本発明の一実施形態に係る異常動作の予測のための動作ステップを示す図である。 本発明の一実施形態に係る図例である。 （Ａ）および（Ｂ）は、本発明の一実施形態に係る例示的なデータ収集コードを示す。 本発明の一実施形態に係るシステムの一例のブロック図である。

疎結合コンポーネントがより優れたスケーラビリティ、柔軟性、保守性、および開発者の生産性の加速を提供するため、マイクロサービスアーキテクチャは、ハイブリッドクラウド環境に展開されるアプリケーションにしばしば使用されるという本発明の実施形態がある。このようなアプリケーションは、多くのサービスで構成され、これらのサービスは、順に複数のインスタンスに複製され、異なる地理的位置で実行される。時間の経過とともに、異常による性能低下が発生する可能性がある。このように、本発明の実施形態は、マイクロサービスアプリケーションの異常を検出することが、ダウンタイムおよび生産性の損失を軽減するのに役立つ可能性がある特定の行動を取ることを可能にする重要なタスクであることをさらに認識する。現在のシステムは、観測可能性が限られているため、マイクロサービスアプリケーションを監視し、パフォーマンスを最適化することに苦労している。さらに、本発明の実施形態は、異常検出への典型的なアプローチは、現在、より多くの誤検出をもたらし得るサービス間の空間的および時間的依存性を考慮する能力を欠いていることを認識する。したがって、本発明の実施形態は、現在の異常検出システムを改善するためのソリューションを提供し、複雑なマイクロサービスアプリケーションを管理する技術サービスサポート担当者に効率的なツールを提供する。例えば、本発明の実施形態は、ニューラルネットワークを使用して、文脈的データに基づいて異常を検出する。この態様では、本明細書でより詳細に後述するように、本発明の実施形態は、ニューラルネットワークのアプローチを使用して、要求文脈的データで利用可能な依存関係を共同で考慮するアプリケーションにおけるパフォーマンス異常（例えば、サービス品質保証（ＳＬＡ）違反）を予測する。本発明の実施形態は、その後、通知を生成し、その後、ユーザが意識する前に、検出された異常を修正することができる。

図１は、本発明の一実施形態に係る一般にコンピューティング環境１００と指定されるコンピューティング環境を示す機能ブロック図である。図１は、１つの実装の例示を提供するに過ぎず、異なる実施形態が実施され得る環境に関するいかなる制限も意味しない。当業者であれば、特許請求の範囲に記載された本発明の範囲から逸脱することなく、図示された環境に対する多くの修正を行うことができる。

コンピューティング環境１００は、ネットワーク１０６を介してすべて相互接続されたクライアントコンピューティングデバイス１０２およびサーバコンピュータ１０８を含む。クライアントコンピューティングデバイス１０２およびサーバコンピュータ１０８は、スタンドアロンコンピュータデバイス、管理サーバ、ウェブサーバ、モバイルコンピューティングデバイス、またはデータを受信、送信、および処理できる任意の他の電子デバイスまたはコンピューティングシステムであり得る。他の実施形態では、クライアントコンピューティングデバイス１０２およびサーバコンピュータ１０８は、クラウドコンピューティング環境など、サーバシステムとして複数のコンピュータを利用するサーバコンピューティングシステムを表すことができる。別の実施形態では、クライアントコンピューティングデバイス１０２およびサーバコンピュータ１０８は、ラップトップコンピュータ、タブレットコンピュータ、ネットブックコンピュータ、パーソナルコンピュータ（ＰＣ）、デスクトップコンピュータ、パーソナルデジタルアシスタント（ＰＤＡ）、スマートフォン、またはコンピューティング環境１００内の種々のコンポーネントおよび他のコンピューティングデバイス（図示せず）と通信できる任意のプログラム可能電子デバイスであり得る。別の実施形態では、クライアントコンピューティングデバイス１０２およびサーバコンピュータ１０８はそれぞれ、コンピューティング環境１００内でアクセスされるとシームレスリソースの単一のプールとして機能するクラスタ化されたコンピュータおよびコンポーネント（例えば、データベースサーバコンピュータ、アプリケーションサーバコンピュータなど）を利用するコンピューティングシステムを表す。いくつかの実施形態では、クライアントコンピューティングデバイス１０２およびサーバコンピュータ１０８は、単一のデバイスである。クライアントコンピューティングデバイス１０２およびサーバコンピュータ１０８は、図６に関してさらに詳細に描かれ説明されるように、機械可読プログラム命令を実行することができる内部および外部のハードウェアコンポーネントを含むことがある。

本実施形態では、クライアントコンピューティングデバイス１０２は、ユーザに関連するユーザデバイスであり、アプリケーション１０４を含む。アプリケーション１０４は、異常検出器１１０にアクセスするため（例えば、ＴＣＰ／ＩＰを使用して）、またはサービス要求およびデータベース情報を受信するためにサーバコンピュータ１０８と通信する。アプリケーション１０４は、図２～５に関してより詳細に議論されるように、受信した要求に関連する文脈的特徴を識別し、ニューラルネットワークモデルを生成または訓練し、生成されたニューラルネットワークモデルを使用して、マイクロサービスアプリケーション内で処理される将来の要求を予測するために、異常検出器１１０とさらに通信し得る。

ネットワーク１０６は、例えば、電気通信ネットワーク、ローカルエリアネットワーク（ＬＡＮ）、インターネットなどのワイドエリアネットワーク（ＷＡＮ）、またはこれら３つの組み合わせであることができ、有線、無線、または光ファイバー接続を含むことができる。ネットワーク１０６は、音声、データ、およびビデオ情報を含むマルチメディア信号を含む、データ、音声、もしくはビデオ信号、またはその組み合わせを受信および送信することが可能な１または複数の有線もしくは無線またはその両方のネットワークを含むことができる。一般に、ネットワーク１０６は、クライアントコンピューティングデバイス１０２およびサーバコンピュータ１０８、およびコンピューティング環境１００内の他のコンピューティングデバイス（図示せず）間の通信をサポートする接続およびプロトコルの任意の組み合わせであり得る。

サーバコンピュータ１０８は、異常検出器１１０およびデータベース１１２をホストするデジタルデバイスである。本実施形態では、サーバコンピュータ１０８は、クラウドアーキテクチャ（例えば、パブリック、ハイブリッド、またはプライベート）に常駐することができる。本実施形態では、異常検出器１１０はサーバコンピュータ１０８に常駐する。他の実施形態では、異常検出器１１０は、クライアントコンピュータデバイス１０２にローカルに記憶されたプログラム（図示せず）のインスタンスを有することができる。他の実施形態では、異常検出器１１０は、多言語ニューラルネットワークインテント分類器を訓練するスタンドアロンプログラムまたはシステムであることができる。さらに他の実施形態では、異常検出器１１０は、任意の数またはコンピューティングデバイスに記憶することができる。

異常検出器１１０は、ニューラルネットワークアプローチを使用して要求文脈的データの依存関係を考慮することによって、マイクロサービスアプリケーションのためのプロアクティブ異常検出を可能にする。異常検出器１１０によって提供されるソリューションは、マイクロサービスアプリケーションのデプロイメント（例えば、プライベートクラウド、パブリッククラウド、またはハイブリッド）に依存せず、様々なコンテナオーケストレーター（例えば、Ｋｕｂｅｎｅｔｅｓ、ＯｐｅｎＳｈｉｆｔ等）をサポートする。異常検出器１１０は、アプリケーションとシステムの両方の動作に基づくハイブリッドデータ収集のためのメカニズムを提供する。本実施形態では、異常検出器１１０は、図２に関してより詳細に説明される１または複数のコンポーネントを含むことができる。

例えば、異常検出器１１０は、Ｎ個のマイクロサービスを含むアプリケーションのエンドユーザ要求を受信することができる。各マイクロサービスインスタンスにおいて、（異常検出器１１０に関連する）それぞれの収集エージェントが、それぞれのインスタンスのトレースデータおよび仕様を抽出する。そして、異常検出器１１０のコレクタエージェントは、受信した情報（それぞれのトレースデータおよび仕様）をコンパイルし、受信した情報を正規化する。そこから、コレクタエージェントは、データを永続化のためのキューにプッシュすることができる。特徴抽出モジュール（図２に示し、説明する）は、生データを要求文脈的特徴に変換する。次に、異常検出器１１０は、フォーマットされた文脈的特徴を使用して、ニューラルネットワークモデルを構築し、その後、構築されたモデルを使用して予測を生成することができる。異常検出器１１０は、その後、プロアクティブな警告を生成することができる。

本実施形態では、異常検出器１１０は、異常動作を予測するための要求を受信することに応答して、それぞれのマイクロサービスから追加の情報を要求することができる。追加情報は、文脈的特徴、すなわち、要求のエンドツーエンドの詳細を表す階層的データ構造を含むことができる。文脈的特徴は、１または複数の因果関係のあるサービスおよびコールパスを含むことができる。文脈的特徴は、さらに、各サービスインスタンスにおける実行文脈（例えば、ＣＰＵ、アクセラレータ、メモリ利用率、ポッドの領域、ネットワークトラフィック、Ｉ／Ｏ要求など）を含むことができる。

例えば、追加情報の要求（例えば、要求仕様）、マイクロサービスパス、および関数パスである。追加情報の例としては、ユーザに関連するユーザ名（匿名化ＩＤ）、企業名（匿名化ＩＤ）、レイテンシ（例えば、５００ｍｓ）、地域（例えば、欧州）、ブラウザタイプ、デバイスタイプ、オペレーティングシステム、時間（例えば、２０２０年２月２８日金曜日、午後２：５５：０２ ＧＭＴ－０５：００）を挙げることができる。

マイクロサービスのパスの例には、マイクロサービスＡからマイクロサービスＢへのパスを含むことができる。例えば、マイクロサービスＡに関連するクラスタＩＤ、地域（ｕｓ）、インスタンスＩＤ、期間（１００ｍｓ）、ＯＳ仕様（ＣＰＵ、メモリ、ディスク、ネットワーク）、およびマイクロサービスＢのそれぞれのクラスタＩＤ、地域（ｕｓ）、インスタンスＩＤ、期間（４００ｍｓ）、ＯＳ仕様（ＣＰＵ、メモリ、ディスク、ネットワーク）である。

コールパス（すなわち、関数パス）の例では、１または複数の関数を含むことができる。例えば、関数１から３まで：関数１は、期間（４０ｍｓ）、リソース利用率（２０％、１００ＭＢ）を含み、関数２は、期間（６０ｍｓ）、リソース利用率（２０％、１００ＭＢ）を含み、期間（４００ｍｓ）、リソース利用率（２０％、１００ＭＢ）を含む関数１に戻る。

本実施形態では、異常検出器１１０は、文脈的特徴を要求するためにハイブリッドデータ収集を提供し、すなわち、文脈的特徴の要求は、異なるソースに送信され得るか、または収集され得る。本実施形態では、異常検出器１１０は、各マイクロサービスインスタンス内にサイドカーとして展開される収集エージェント（図２に示し、説明する）を含み（例えば、単一のＫｕｂｅｒｎｅｔｅｓ Ｐｏｄの２つのコンテナ）、２つの異なるソース：Ｊａｅｇｅｒなどのマイクロサービスからのトレースデータ、およびＯｐｅｎＴｅｌｅｍｅｔｒｙ）およびマイクロサービスのランタイムの特性（例えば、ＣＰＵ、メモリ利用率、ネットワーク、他のコロケーションサイドカー、Ｚａｂｂｉｘ－Ａｇｅｎｔ（例えば、ＣＰＵ、Ｄｉｓｋ、メモリなど）、ＩｓｔｉｏのＥｎｖｏｙ（例えばネットワーク）、など）から引き出すことができる。

これらのソースから、異常検出器１１０は、カテゴリカルデータおよび数値データを収集することができる。本実施形態において、カテゴリカルデータは、要求ヘッダまたはデプロイメントホスト上の環境変数のいずれかから抽出される要求およびマイクロサービスインスタンスを指す。本実施形態において、数値データは、ＯｐｅｎＴｅｌｅｍｅｔｒｙまたはＪａｅｇｅｒなどの分散トレースライブラリから、各マイクロサービスに費やされた時間やその重要な機能を報告するデータを指す。このように、異常検出器１１０は、適切な権限でそれぞれのシステム利用情報を報告、記録、および取得する数値データ報告を活用することができる。したがって、異なるソースから文脈的特徴を収集することによって、異常検出器１１０は、層をまたいで要求を処理する総合的な見方を可能にすることができる。

次に、異常検出器１１０は、収集された文脈的特徴（すなわち、追加情報）を使用して、前述の要求文脈的特徴を入力として階層的に扱い、それぞれのマイクロサービスアプリケーション内で処理される将来の要求を予測できるニューラルネットワークモデルを構築および訓練できる。

このようにして、異常検出器１１０は（構築されたニューラルネットワークモデルを使用して）要求間要因および要求内要因を捕捉し、捕捉した要因を使用して将来の要求を予測することができる。本実施形態において、要求間要因は、要求仕様における特性間のつながりを記述する（例えば、特定の地域からのユーザＩＤのログイン要求は、同じ地域のユーザＩＤからの製品カタログページへのget_requestに続く可能性が高い）。本実施形態では、要求内要因として、個々の要求の要因を考慮し、因果関係のあるマイクロサービスパスと関数パスのデータから、処理パス中のどのサービスが将来の要求にとって最も重要な役割を果たすかを理解する。これら２つの要素を考慮することで、構築されたニューラルネットワークモデルは、それぞれのマイクロサービスと最後のステップの間の相関関係を捕捉することができる。例えば、マイクロサービスからの履歴要求は、２つのパスを取ることができる。第１のパスは、４０ｍｓ、１５ｍｓ、３００ｍｓのそれぞれのレイテンシを持つマイクロサービスＡ、Ｂ、Ｃを利用することができる。第２のパスは、２００ｍｓ、４０ｍｓ、１．２ｓのレイテンシを持つマイクロサービスＡ、Ｂ、Ｄを利用することができる。構築されたニューラルネットワークは、マイクロサービスＡでのレイテンシが高い場合にマイクロサービスＤを利用して、マイクロサービスＡ、Ｂ、およびＤを使用する経路を予測することができる。例えば、マイクロサービスＡのレイテンシは３００ｍｓ、マイクロサービスＢのレイテンシは５０ｍｓであり得る。この例では、異常検出器１１０は、次の要求が１００ｍｓのレイテンシを有するＣではなく、２ｓのレイテンシを有するマイクロサービスＤで処理されるべきであることを（構築されたニューラルネットワークを用いて）予測することができ、時間２．３５ｓで、異常検出器１１０は警告を送信することができる（例えば、２．３５ｓ＝３００ｍｓ（Ａ）＋５０ｍｓ（Ｂ）＋２ｓ（Ｄ））。トレースパス（Ａ→Ｂ→Ｄ）は、ニューラルネットワークモデルの予測結果であり、Ａの継続時間と前回の選択時間との相関を捕捉する。これは、構築され、後に図３および図４に関して示され、説明されるニューラルネットワークモデルを通じて（予測に対して）要求される。具体的には、ＬＳＴＭモデルは、マイクロサービス間の順序関係を学習し、次に使用されるのがどれであるかを予測するために訓練されることになる。

本実施形態では、異常検出器１１０は、コントローラ（図２に示し、説明する）を利用して、予測のシーケンスを解釈し、異常が発生するかどうかを決定することができる。本実施形態では、コントローラは、キーパフォーマンスメトリクス（例えば、レイテンシ、スループット、失敗したＲＰＣコールなど）を重み付けする。本実施形態では、キーパフォーマンスメトリクスは、マイクロサービスアプリケーションの所有者によって決定または定義されることができる。コントローラは、統計的尺度（例えば、偏差、パーセンタイル）を計算し、プロアクティブな警告を発するかどうかを決定する。例えば、コントローラは、次の式に従って偏差を計算することができる：偏差＝｜ｘｉ－平均（Ｘ）｜。本実施形態では、偏差が大きいほど、特定の異常を示すデータセットがより不安定になる。本実施形態において、パーセンタイルは、スコアの特定の割合がその数値を下回るように定義される。例えば、数値の順序リストの５０パーセンタイルは、その中央値である。

本実施形態では、異常検出器１１０は、予測された異常動作に応答して、プロアクティブな警告を生成することができる。生成されたプロアクティブな警告は、異常が予測された理由もしくはフラグを立てられた理由またはその両方を含むことができる。本実施形態では、プロアクティブな警告は、異常検出器１１０のコンポーネント（例えば、図２に示され説明されているコントローラ）によって生成することができる。本実施形態では、コントローラは、適切なビジュアライゼーション、プロアクティブな警告の生成、根本原因レポートの生成、リソース管理機能の提供、およびシステムシミュレーションを行うことができる。

例えば、異常検出器１１０は、エンドユーザ要求を処理するそれぞれのコンポーネントのビジュアライゼーションを生成することができる。要求は、以下のコンポーネントを含む以下のクラウドインフラストラクチャに送信される：フロントエンドサービス、ルータサービス、ディスパッチャサービス、アダプタサービス、オンプレミスインフラストラクチャ（例えば、レガシーコード）、消費者、バックエンドサービス、および２つの異なる場所（例えば、米国および欧州）にあるデータベースを含むサービスとしてのプライベートクラウドソフトウェア（ＳａａＳ）。この例では、異常検出器１１０は、要求のそれぞれのコンポーネントおよび関数パスのビジュアライゼーションを生成するとともに、検出された根本原因がサービス（例えば、ディスパッチャ）のうちの１つであり得ることを視覚的に示すために１または複数のグラフィックアイコンを生成することができる。このように、異常検出器１１０は、異常な要求のエンドツーエンドの実行フローのビジュアライゼーションを生成し、ディスパッチャサーバを根本原因として強調することができる。

本実施形態では、根本原因レポートには、予測された異常なサービスおよび考えられる理由、およびその理由を含む生成されるプロアクティブな警告が含まれる。上記の例を続けると、根本原因レポートは、ディスパッチャにおける異常動作の説明を含むことができ、サービス品質保証に違反する長いレイテンシがエンドユーザに影響を与えるというプロアクティブな警告を生成することができる。

本実施形態では、異常検出器１１０は、システム管理者に警告し、適切な行動をとるリソース管理機能を提供することができる。例えば、予測された異常の理由が、ＣＰＵ、低メモリ、低速ネットワークレイテンシなどの不十分なコンピューティングリソースに起因する場合、システム管理者は、アプリケーションクライアントに影響を与える前に、より多くのリソースをプロビジョニングすることができる。

本実施形態では、異常検出器１１０は、システムシミュレーションも提供することができる。例えば、予測結果は、ＣＰＵ、メモリ、ディスク、およびネットワーク使用量を含む各マイクロサービスにおけるエンドツーエンドの実行フローの詳細を含む。このようなきめ細かい特徴的なトレースは、基礎となるハードウェアシステム上で要求されるアプリケーションの洞察を提供し、これをシステムシミュレータのドライバとして使用して、潜在的なクラウドシステム設計を評価し、課題およびトレードオフ（例えば、ローカル対リモート、ルーティングフロー／トラフィックコントロール、頑丈なコア対非力なコア、レイテンシ要件、オフロードの利点、等）を学習することができる。このプロセスは、クラウドシステム設計者が、ストレージ、ネットワーク、ＣＰＵ、メモリ、アクセラレータなど、さまざまなアプリケーションから構成されるさまざまなハードウェアコンポーネント間の相互作用を理解するために役立つ。また、さまざまなハードウェア構成による潜在的な利点と劣化を分析し、将来のクラウドシステムの設計決定を導くのに役立つ。

エンドツーエンドの例では、異常検出器１１０によって扱われるシステムは、処理のための要求を受け取ることができる。要求は、以下のコンポーネントを含む以下のクラウドインフラストラクチャに送信され得る：フロントエンドサービス、ルータサービス、ディスパッチャサービス、アダプタサービス、オンプレミスインフラストラクチャ（例えば、レガシーコード）、消費者、バックエンドサービス、および２つの異なる場所（例えば、米国および欧州）にあるデータベースを含むサービスとしてのプライベートクラウドソフトウェア（ＳａａＳ）。

第１のシナリオでは、要求は、フロントエンドサービスによって処理され、ルータに送られ、消費者に戻るアダプタに送信され、最後にバックエンドコンポーネントに送信されることができる。このシナリオでは、異常検出器１１０は、ディスパッチャおよびバックエンドサービスのいずれかが、エンドユーザに影響を与える長いレイテンシを経験し、ＳＬＡに違反することを予測することに応答して、プロアクティブな警告を生成することができる。異常検出器１１０を使用することによって、ディスパッチャおよびバックエンドサービスにおける異常動作が検出され、遅延を引き起こしているサービスインスタンスとして適切に帰着することができる。これに対し、予測モデルを用いた現在のシステムでは、同時要求から収集されたログが混在するため、精度の低い結果（例えば、低精度）が得られる。本発明の実施形態（例えば、異常検出器１１０）は、要求文脈データが、ログを個々の要求に分離するトレースを含む点で現在のアプローチと異なる。例えば、ルータサービスが１０個の要求を同時に処理している場合、そのうちの４個はディスパッチャにルーティングされ、他のものはバックエンドにルーティングされるだろう。現在のアプローチでは、同時処理のためにインターリーブされた混合ログデータしか見ることができないかもしれない。したがって、１または複数の要求が失敗した場合、どの要求が失敗したかを特定することは困難である。対照的に、異常検出器１１０は、トレースデータ（すなわち、要求文脈的データ）を提供し、我々は、どの要求がどのサービスで失敗したかを特定することができる。

上記のコンポーネントを利用した第２のシナリオでは、異常検出器１１０は、バックエンドサービスがユーザ情報を記憶するデータベースから遅い応答を経験していることを予測し、ユーザの特定のセットに対する応答の遅延をユーザに伝えるプロアクティブな警告を生成することができる。対照的に、現在のシステムは、集約されたメトリクス上の統計に対する問題を検出することが困難である。いくつかのシナリオでは、集約されたメトリクスが監視コンポーネントを誤解させる可能性がある。例えば、平均レイテンシが特定の閾値を下回っても、必ずしもシステムが健全であるとは限らない。この例では、トラフィックの９０％が欧州（ＥＵ）ＤＢに、１０％が米国（ＵＳ）ＤＢにルーティングされているとする。ＥＵＤＢが正常でＵＳＤＢのサービスに異常がある場合、要求の９０％は正常なレイテンシを持つため、平均レイテンシはやはり正常に見えるだろう。その代わりに、我々のモデル（例えば、異常検出器１１０）は、ＵＳＤＢへの実行パス上の異常を特定できるように、個々のトレースのレイテンシを考慮する。

上記のコンポーネントを利用した第３のシナリオでは、異常検出器１１０は、ディスパッチャサービスによって開始されたジョブがレガシーコードでの性能低下により完了できないことを予測し、消費者から結果を受信するバックエンドにおける遅延の警告を生成できる。これに対して、現在のシステムは、生産者と消費者のログのメトリクスを使用して非同期関係をモデル化することが困難である。現在のシステムでは、機械学習モデルの訓練にログデータを使用している。前述したように、個人から収集されたログデータは、因果関係を導き出すことが困難なようにインターリーブされる。その代わり、要求文脈的はトレースの上に構築されるので、異常検出器１１０はこの問題を回避することができる。

異常検出器１１０は、さらに、予測の結果を活用して、根本原因分析、リソース管理、およびシステムシミュレーションを実行することができる。例えば、予測の結果は、システムシミュレータを駆動して、様々なハードウェア構成からの潜在的な利点と劣化を理解するため、また、将来のクラウドシステムの設計決定を導くために使用することができる。

データベース１１２は、受信した情報を記憶し、異常検出器１１０に許可されたアクセスを与える１または複数のデータベースまたは一般に利用可能なデータベースを代表とすることができる。一般に、データベース１１２は、当技術分野で知られている任意の不揮発性記憶媒体を用いて実装することができる。例えば、データベース１１２は、テープライブラリ、光学ライブラリ、１または複数の独立したハードディスクドライブ、または独立したディスクの冗長配列（ＲＡＩＤ）内の複数のハードディスクドライブを使用して実装することができる。本実施形態では、データベース１１２は、サーバコンピュータ１０８上に記憶される。

図２は、本発明の一実施形態に係るマイクロサービスの異常検出器のブロック図２００の一例を示す図である。

この例示的な図は、異常検出器１１０の１または複数のコンポーネントを示す。いくつかの実施形態では、異常検出器１１０は、それぞれのマイクロサービスおよび収集エージェントを有する１または複数のホストを含むことができるが、異常検出器１１０は、クラウドアーキテクチャにわたってマイクロサービスおよび収集エージェントにアクセスできることを理解されたい。

この例では、異常検出器は、ホスト２０２Ａ、ホスト２０２Ｂ～２０２Ｎを含むことができる。各ホストは、それぞれのマイクロサービスおよび収集エージェント、（例えば、それぞれのマイクロサービス２０４Ａ～Ｎおよび収集エージェント２０６Ａ～Ｎ）を有することができる。

この例では、異常検出器１１０は、収集エージェント２０６Ａを介してエンドユーザ要求マイクロサービス２０４Ａを受信することができる。この例では、収集エージェント２０６は、エンドユーザからの要求を受信することができ、１または複数の他のコンポーネント（例えば、他のコロケーションサイドカー、Ｚａｂｂｉｘ－Ａｇｅｎｔ（例えば、ＣＰＵ、Ｄｉｓｋ、メモリ等）、ＩｓｔｉｏのＥｎｖｏｙ（例えば、ネットワーク）等）からの要求も受信することができる。

収集エージェント２０６Ａは、収集要求を行い、それぞれのインスタンスのトレースデータおよび仕様を抽出する責任を負う。本実施形態では、それぞれの収集エージェントは、異常検出器１１０のコレクタモジュール（例えば、コレクタモジュール２０６）とインタフェースすることができる。コレクタモジュール２０６は、受信した情報（それぞれのトレースデータおよび仕様）をコンパイルする責任を負う。コレクタモジュール２０６は、次に、正規化モジュール２１０を使用してデータを正規化することができ、すなわち、正規化モジュール２１０は、データを一貫したフォーマット、（例えば、ＪＳＯＮまたは共通のデータ構造）へ正規化する。コレクタモジュール２０６は、その後、コンパイルされた情報を永続化のためのキューにプッシュすることができる。

次に、特徴抽出モジュール２１３は、キュー内のデータにアクセスし、コンパイルされたデータから文脈的特徴を抽出することができる。言い換えれば、特徴抽出モジュール２１０は、生データを要求文脈的特徴に変換する。例えば、要求文脈的特徴（すなわち、要求仕様）は、以下を含むことができる：ユーザ名（匿名化ＩＤ）、企業名（匿名化ＩＤ）、レイテンシ（５００ｍｓ）、地域（欧州）、ブラウザ（Ｆｉｒｅｆｏｘ）、デバイス（ｉＯＳ）、オペレーティングシステム、時間（例えば、２０２０年２月２８日金曜日、午後２：５５：０２ ＧＭＴ－０５：００）、それぞれのマイクロサービスパス（例えば、マイクロサービスＡからマイクロサービスＢへのパス。例えば、マイクロサービスＡに関連するクラスタＩＤ、地域（ｕｓ）、インスタンスＩＤ、期間（１００ｍｓ）、ＯＳ仕様（ＣＰＵ、メモリ、ディスク、ネットワーク）、マイクロサービスＢのそれぞれのクラスタＩＤ、地域（ｕｓ）、インスタンスＩＤ、期間（４００ｍｓ）、ＯＳ仕様（ＣＰＵ、メモリ、ディスク、ネットワーク）、および関数パス（例えば、関数１から３まで：関数１は、期間（４０ｍｓ）、リソース利用率（２０％、１００ＭＢ）を含み、関数２は、期間（６０ｍｓ）、リソース利用率（２０％、１００ＭＢ）を含み、期間（４００ｍｓ）、リソース利用率（２０％、１００ＭＢ）を含む関数１に戻る。）である。

異常検出器１１０は、次に、ニューラルネットワークモジュール２１４（図３および図４に示し、説明する）を使用してニューラルネットワークモデルを構築するために、フォーマットされた文脈的特徴を使用することができる。コントローラモジュール２１６は、その後、構築されたニューラルネットワークモデルを使用して予測を生成することができ、適切なビジュアライゼーション、プロアクティブな警告、根本原因レポートの生成、リソース管理能力の提供、およびシステムシミュレーションを行うことができる。

図３は、本発明の一実施形態に係るニューラルネットワークモデルを設計するためのブロック図３００の一例を示す図である。

具体的には、ブロック図３００は、ニューラルネットワークの設計を描いている（いくつかのの隠れ層は省略されている）。入力は、一連の要求の要求仕様である。要求内埋め込み層への入力Ｓｉは、図４に示され説明されたマイクロサービスパスニューラルネットワークモデルの出力である。

この例では、異常検出器１１０は、入力３０２Ａ、３０２Ｂ、から３０２Ｎ（ｒ１仕様）を受信する。例えば、要求入力、すなわち追加情報は、指定された時間（例えば、時間ウィンドウ、Ｔ）の間に収集された文脈的階層構造トレースデータを含むことができる。この要求入力は、要求仕様、マイクロサービスパス、および関数パスを含むことができる。要求仕様の付加情報の例としては、ユーザに関連するユーザ名（匿名化ＩＤ）、企業名（匿名化ＩＤ）、レイテンシ（例えば、５００ｍｓ）、地域（例えば、欧州）、ブラウザタイプ、デバイスタイプ、オペレーティングシステム、時間（例えば、２０２０年２月２８日金曜日、午後２：５５：０２ ＧＭＴ－０５：００）を挙げることができる。

マイクロサービスのパスの例には、マイクロサービスＡからマイクロサービスＢへのパスを含むことができる。例えば、マイクロサービスＡに関連するクラスタＩＤ、地域（ｕｓ）、インスタンスＩＤ、期間（１００ｍｓ）、ＯＳ仕様（ＣＰＵ、メモリ、ディスク、ネットワーク）、およびマイクロサービスＢのそれぞれのクラスタＩＤ、地域（ｕｓ）、インスタンスＩＤ、期間（４００ｍｓ）、ＯＳ仕様（ＣＰＵ、メモリ、ディスク、ネットワーク）である。

コールパス（すなわち、関数パス）の例では、１または複数の関数を含むことができる。例えば、関数１から３まで：関数１は、期間（４０ｍｓ）、リソース利用率（２０％、１００ＭＢ）を含み、関数２は、期間（６０ｍｓ）、リソース利用率（２０％、１００ＭＢ）を含み、期間（４００ｍｓ）、リソース利用率（２０％、１００ＭＢ）を含む関数１に戻る。

次に、受信した入力は、ブロック３２０において、要求仕様の埋め込み処理（例えば、Ｒ１およびＡ１、それぞれ３０４Ａ～Ｎおよび３０６Ａ～Ｎ）を行う。本実施形態において、「Ｒ１」は、要求仕様における文字列部分、（例えば、ユーザ名、ブラウザタイプなど）の埋め込み結果であり、「Ａ１」は、要求仕様に関連する数値部分を指す。本実施形態では、異常検出器１１０は、埋め込み結果を要求仕様の数値部分（例えば、レイテンシ、Ａ１～ＡＮと呼ばれる）と連結させる。

異常検出器は、次に、埋め込まれた要求仕様を、それぞれ３０８Ａ～Ｎおよび３１０Ａ～Ｎと呼ばれるコンポーネントＢ１およびＳ１と組み合わせることができる。本実施形態において、Ｂ１～ＢＮは、要求仕様を埋め込んだ出力である。本実施形態において、Ｓ１は、図４で説明したモデルの出力である。本実施形態において、Ｓ１は、単一の要求のエンドツーエンドの実行フローのモデル化された出力を表す。

ブロック３３０で要求内埋め込みのための処理が継続される。要求内要因は、Ｂ１、Ｓ１およびＣ１を含む。本実施形態では、Ｂ１、Ｓ１およびＣ１は、単一の要求仕様に関連する。同様に、Ｂ２、Ｓ２およびＣ１は、別の要求仕様に関連する。Ｃ１は、Ｂ１とＳ１の組み合わせをベクトルに変換するための埋め込み層（３１２Ａ～Ｎと呼ばれる）である。

処理は、ブロック３４０および３５０（例えば、ＬＴＳＭ３４０および密度３５０）を含む要求間因子を追加するために継続される。ブロック３４０において、文脈的特徴は、深層学習の分野で使用される長短期（ＬＳＴＭ）アーキテクチャを介して供給され、Ｄ１が追加され、それぞれ３１４Ａ～Ｎと呼ばれる。本実施形態では、Ｄ１は、ＬＳＴＭモデルの単一のユニットである。Ｃ１、Ｃ２、...ＣＮは、個々の要求のモデル化された出力であることを想起されたい。異常検出器１１０は、ＬＳＴＭモデルを用いて、要求間の要求内関係を学習する。本実施形態では、Ｄ１～ＤｎはＬＳＴＭモデルのユニットである。最後に、密度３５０において、３１６Ａ～Ｎと呼ばれるＥ１が追加される。本実施形態では、Ｅ１～ＥＮは密結合ネットワークのユニットであり、それらの内部相関を見つけるために、入力の次元を下げるものである。結果の出力はＹ_１、Ｙ_２～Ｙ_Ｎであり、それぞれ３１８_Ａ～Ｎとして参照される。

図４は、本発明の一実施形態に係る個々の要求に対する要求内要因を捕捉するニューラルネットワークモデルの例示的なブロック図４００である。

入力（例えば、Ｆ_１，１、Ｆ_１，２、Ｆ_２，１およびＦ_Ｂ１、それぞれ４０２Ａ、４０２Ｂ、４０２Ｃ、４０２Ｎと呼ばれる）は、一連の要求の要求仕様における関数の記述である。異常検出器１１０は、受信した入力を受けて、要求仕様の埋め込みを行う（例えば、ブロック４２０）。本実施形態では、Ｇ_１，１、Ｇ_１，２、Ｇ_２，１およびＧ_Ｂ，１は４０４Ａ、４０４Ｂ、４０４Ｃ～４０４Ｎとして参照され、Ｈ_１，１、Ｈ_１，２、Ｈ_２，１、Ｈ_Ｂ，１はそれぞれ４０６Ａ、４０６Ｂ、４０６Ｃ、４０６Ｎとして参照される。Ｇ_１，１、Ｇ_１，２は、関数Ｆ_１，１における文字列部分の埋め込み層である。同様に、Ｇ_２，１は、関数Ｆ_２，１における文字列部分の埋め込みユニットである。Ｈ_１，１は、Ｇ_１，１とＦ_１，１の数値部分の連結を表す。まとめて４０４Ａ～Ｎと４０６Ａ～Ｎは、図３で説明した３０４Ａ～Ｎ、３０６Ａ～Ｎと同様の方法で機能する。

本実施形態では、ブロック４３０において、埋め込まれた要求仕様が長短期記憶（ＬＳＴＭ）、人工リカレントニューラルネットワーク（ＲＮＮ）を介して供給され、それぞれのＫ_１，１、Ｋ_１，２、Ｋ_２，１およびＫ_Ｂ，１（すなわち、ＬＴＳＭモデルのユニットがそれぞれ４０８Ａ、４０８Ｂ、４０８Ｃおよび４０８Ｎとして参照される）が追加される。

処理はマイクロサービス埋め込みのためのブロック４４０に続き、Ｍ_１、Ｍ_２およびＭ_ＢとＯ_１、Ｏ_２およびＯ_Ｂがそれぞれ追加される。Ｍ_１、Ｍ_２およびＭ_Ｂはブロック４１０Ａ、４１０Ｂ、４１０Ｎとして参照され、Ｂマイクロサービスを表すＬＴＳＭモデルの出力（例えば、ブロック４３０）であり、Ｏ_１、Ｏ_２およびＯ_Ｂはそれぞれブロック４１２Ａ、４１２Ｂ、４１２Ｎとして参照され、Ｂマイクロサービスの仕様の埋め込みを参照する。

処理はブロック４５０に続き、ブロック４４０の結果が別のＬＴＳ層を介して供給され、Ｐ_１、Ｐ_２およびＰ_Ｂがそれぞれ追加される。Ｐ_１、Ｐ_２およびＰ_Ｂは、それぞれブロック４１４Ａ、４１４Ｂ、４１４Ｎとして参照される。本実施形態では、Ｐ_１、Ｐ_２およびＰ_Ｂはブロック４５０のＬＴＳＭモデルのユニットである。

ブロック４５０の結果出力は、ブロック４６０を介して供給される。ブロック４６０は、前の層の特徴のすべての組み合わせから学習特徴を提供する密度層であり、４１６Ａ、４１６Ｂおよび４１６Ｎとして参照されるＱ１、Ｑ２およびＱＢをそれぞれ追加する。

本実施形態では、Ｚ_１、Ｚ_２およびＺ_Ｎ（それぞれ４１８_Ａ、４１８_Ｂおよび４１８_Ｎとして参照される）は、ブロック図４００のワークフローの結果出力である。まとめて４１８_Ａ、４１８_Ｂおよび４１８_Ｎは、単一の要求のエンドツーエンド実行フローのモデル化された出力を表す。４１８_Ｂおよび４１８_ＮはＳ１として参照され、図３に説明されたモデルに組み込まれて描かれる。

図５は、本発明の一実施形態に係るエンドツーエンドスピーチ、多言語インテント分類器を訓練するための動作ステップを示すフローチャート５００である。

ステップ５０２において、異常検出器１１０は、情報を受信する。本実施形態において、受信した情報は、Ｎ個のマイクロサービスを含むアプリケーションに対するエンドユーザ要求を含むことができる。例えば、エンドユーザ要求は、フロントエンドサービスに対するユーザの要求によってトリガされる要求である。例えば、ユーザがウェブページにアクセスし、ログインボタンを押すと、ログイン要求がアプリケーションに生成される。

本実施形態では、異常検出器１１０は、クライアントコンピューティングデバイス１０２から要求を受信する。他の実施形態では、異常検出器１１０は、コンピューティング環境１００の１または複数の他のコンポーネントから情報を受信することができる。

ステップ５０４において、異常検出器１１０は、受信した情報から文脈的情報を生成する。本実施形態において、異常検出器１１０は、追加情報を要求し、受信した要求のエンドツーエンドの詳細を表す階層的データ構造を作成することによって、受信した要求から文脈的情報を生成する。

具体的には、異常検出器１１０は、ユーザに関連するユーザ名（匿名化ＩＤ）、企業名（匿名化ＩＤ）、レイテンシ（例えば、５００ｍｓ）、地域（例えば、欧州）、ブラウザタイプ、デバイスタイプ、オペレーティングシステム、時間（例えば、２０２０年２月２８日金曜日、午後２：５５：０２ ＧＭＴ－０５：００）、マイクロサービスパス、および関数パスを含み得る追加情報（例えば、要求仕様）を要求することができる。

文脈的特徴の要求は、差分ソースに送信されるか、またはそうでなければ差分ソースから収集され得る。本実施形態では、異常検出器１１０は、サイドカーとして各マイクロサービスインスタンス内に展開される収集エージェント（図２に示し、議論される）を含み（例えば、単一のＫｕｂｅｒｎｅｔｅｓ Ｐｏｄの２つのコンテナ）であり、２つの異なるソース：Ｊａｅｇｅｒなどのマイクロサービスからのトレースデータ、およびＯｐｅｎＴｅｌｅｍｅｔｒｙ）およびマイクロサービスのランタイムの特性（例えば、ＣＰＵ、メモリ利用率、ネットワーク、他のコロケーションサイドカー、Ｚａｂｂｉｘ－Ａｇｅｎｔ（例えば、ＣＰＵ、Ｄｉｓｋ、メモリなど）、ＩｓｔｉｏのＥｎｖｏｙ（例えばネットワーク）など）から引き出すことができる。

これらのソースから、異常検出器１１０は、カテゴリカルデータおよび数値データを収集することができる。本実施形態において、カテゴリカルデータは、要求ヘッダまたはデプロイメントホスト上の環境変数のいずれかから抽出される要求およびマイクロサービスインスタンスを指す。本実施形態において、数値データは、ＯｐｅｎＴｅｌｅｍｅｔｒｙまたはＪａｅｇｅｒなどの分散トレースライブラリから、各マイクロサービスに費やされた時間やその重要な機能を報告するデータを指す。このように、異常検出器１１０は、適切な権限でそれぞれのシステム利用情報を報告、記録、および取得する数値データ報告を活用することができる。したがって、異なるソースから文脈的特徴を収集することによって、異常検出器１１０は、層をまたいで要求を処理する総合的な見方を可能にすることができる。

ステップ５０６において、異常検出器１１０は、生成された文脈的情報に基づいてニューラルネットワークを訓練する。本実施形態において、異常検出器１１０は、要求間要因および要求内要因を含む生成された文脈的情報に基づいてニューラルネットワークを訓練する。上述のように、要求間要因は、要求仕様における特性間のつながりを記述する（例えば、特定の地域からのユーザＩＤのログイン要求は、同じ地域のユーザＩＤからの製品カタログページへのget_requestに続く可能性が高い）。対して、要求内要因は、個々の要求の要因を考慮し、因果関係のあるマイクロサービスパスと関数パスのデータから、処理パス中のどのサービスが将来の要求にとって最も重要な役割を果たすかを理解する。これら２つの要素を考慮することで、構築されたニューラルネットワークモデルは、それぞれのマイクロサービスと最後のステップの間の相関関係を捕捉することができる。このようにして、訓練されたニューラルネットワークは、次の一連の要求とその文脈的要求がどのようなものかを予測することができる。そして、その予測に基づいて、コントローラモジュールは異常があるかどうかを判断する。

ステップ５０８において、異常検出器１１０は、訓練されたニューラルネットワークモデルを使用して異常動作を予測する。例えば、異常検出器１１０は、ＳＬＡ違反（例えば、次の１０分間に、テールレイテンシが増加する）、影響を受けるであろうユーザ（例えば、Ｕの南部地域のユーザのサブセット）、および要求のサブセットの影響（例えば、分析結果の取得が失敗する）などの異常を予測することができる。

ステップ５１０において、異常検出器１１０は、予測された異常動作に基づき、適切な行動をとる。本実施形態では、適切な行動は、プロアクティブな警告の生成、根本原因レポートの生成、リソース管理能力の提供、およびシステムシミュレーションであり得る。例えば、異常検出器１１０は、その後、予測に基づいてプロアクティブな警告を送信するか否かを決定することができる。本実施形態において、異常検出器１１０は、異常を予測することに応答して、自動的にプロアクティブな警告を生成することができる。別の実施形態では、異常検出器は、予測された異常に対する加重スコアを生成することができ、予測された異常が異常動作に対する閾値を満たすかまたは超えることに応答して、プロアクティブな警告を生成することができる。

例えば、プロアクティブな警告には、以下のような予測を含めることができる：ＳＬＡ違反（例えば、次の１０分間に、テールレイテンシが増加する）、影響を受けるであろうユーザ（例えば、Ｕの南部地域のユーザのサブセット）、および要求のサブセットの影響（例えば、分析結果の取得が失敗する）。

根本原因レポートの例には、失敗したマイクロサービスインスタンスの特定と、失敗の理由を含むことができる。例えば、データベース接続が遅い、コンピューティングリソースが不足している、などである。

いくつかの実施形態では、リソース管理は、推奨される修正を含むことができる。例えば、異常検出器１１０は、より大容量を有するノードでマイクロサービスインスタンスをプロビジョニングすることを推奨すること、バックエンドとデータベースとの間のネットワーク帯域幅を増加させること、より強力なＣＰＵを有するノードを追加すること等が可能である。

図６は、本発明の一実施形態に係る例示的な図６００を示す。

例えば、図６は、エンコーダおよびデコーダ部分、それらの入力および出力を有するシーケンストゥシークエンス（ｓｅｑ２ｓｅｑ）モデルの概要を示す（上述した方法論を表す）。エンコーダ（例えば、ブロック６０２）およびデコーダ（例えば、ブロック６０４）部分は両方とも、ＲＮＮベースであり、複数の時間ステップに対応する出力シーケンスを消費して返すことが可能である。モデルは、前のＮ個の値から入力を取得し、それは次のＮ個の予測を返す。Ｎはハイパーパラメータであり、この図では経験的に１０分として設定されている。図の中央には、階層型ＲＮＮベースの異常検出ニューラルネットワークがあり、３つの主要なコンポーネント（要求内要因、要求間要因、および埋め込み）を含む。

具体的には、図６の図は、エンコーダ－デコーダアーキテクチャ（通称ｓｅｑ２ｓｅｑモデル）である。本実施形態において、Ｘ、Ｘ_１、Ｘ_２、・・・、Ｘｎは、一連の要求の要求文脈的データであるモデルへの入力を表す。本実施形態において、Ｙ、Ｙ_１、Ｙ_２、・・・Ｙ_ｎは、モデルの出力であり、モデルの予測値である。モデルの内部アーキテクチャは、図３および図４を通して詳細に説明され、以前に議論された。

図７（Ａ）および図７（Ｂ）は、本発明の一実施形態に係る例示的なデータ収集コードを示す図である。

具体的には、図７（Ａ）は、それぞれのマイクロサービスにおける例示的なアプリケーションコードである例示的なデータ収集コード７００を描写している。

図７（Ｂ）に関して、図７（Ｂ）は、例示的なデータ収集コード７５０を描写している。具体的には、例示的なデータ収集コード７５０は、収集エージェントのコードを表す。

図８は、本発明の一実施形態に係る図１のコンピューティング環境１００内のコンピューティングシステムのコンポーネントのブロック図である。図８は、１つの実装の例示を提供するのみであり、異なる実施形態が実装され得る環境に関していかなる制限も意味しないことを理解されたい。描かれた環境に対する多くの修正を行うことができる。

本明細書に記載されたプログラムは、本発明の特定の実施形態においてそれらが実装されるアプリケーションに基づいて識別される。しかしながら、本明細書における任意の特定のプログラム命名法は、単に便宜上使用されており、したがって、本発明は、かかる命名法によって識別される、もしくは暗示される、またはその両方である任意の特定のアプリケーションにおける使用のみに限定されるべきではないことを理解されたい。

コンピュータシステム８００は、キャッシュ８１６、メモリ８０６、永続ストレージ８０８、通信ユニット８１２、および入力／出力（Ｉ／Ｏ）インタフェース８１４間の通信を提供する、通信ファブリック８０２を含む。通信ファブリック８０２は、プロセッサ（マイクロプロセッサ、通信およびネットワークプロセッサなど）、システムメモリ、周辺デバイス、およびシステム内の他の任意のハードウェアコンポーネント間でデータもしくは制御情報またはその両方を渡すために設計された任意のアーキテクチャで実装することができる。例えば、通信ファブリック８０２は、１または複数のバスまたはクロスバースイッチを用いて実装することができる。

メモリ８０６および永続ストレージ８０８は、コンピュータ可読記憶媒体である。本実施形態では、メモリ８０６はランダムアクセスメモリ（ＲＡＭ）を含む。概して、メモリ８０６は、任意の適切な揮発性または不揮発性のコンピュータ可読記憶媒体を含むことができる。キャッシュ８１６は高速メモリ（fast memory）であり、最近アクセスされたデータ、および最近アクセスされたデータに近いデータをメモリ８０６から保持することによって、プロセッサ８０４の性能を向上させる。

異常検出器１１０（図示せず）は、キャッシュ８１６を介してそれぞれのコンピュータプロセッサ８０４の１または複数による実行のために、永続ストレージ８０８およびメモリ８０６に格納され得る。一実施形態では、永続ストレージ８０８は、磁気ハードディスクドライブを含む。代替的に、または磁気ハードディスクドライブに加えて、永続ストレージ８０８は、ソリッドステートハードディスクドライブ、半導体記憶装置、読み取り専用メモリ（ＲＯＭ）、消去可能プログラマブル読み取り専用メモリ（ＥＰＲＯＭ）、フラッシュメモリ、またはプログラム命令またはデジタル情報を記憶することができる任意の他のコンピュータ可読可能記憶媒体を含むことができる。

永続ストレージ８０８が使用する媒体は、取り外し可能であってもよい。例えば、永続ストレージ８０８には、取り外し可能なハードドライブを用いてもよい。他の例としては、光ディスク、磁気ディスク、サムドライブ、およびスマートカードが挙げられ、これらは、永続ストレージ８０８の一部でもある別のコンピュータ可読記憶媒体に転送するためにドライブに挿入される。

これらの例において、通信ユニット８１２は、他のデータ処理システムまたは装置との通信を可能にする。これらの例において、通信ユニット８１２は、１つ以上のネットワークインタフェースカードを含む。通信ユニット８１２は、物理通信リンクおよび無線通信リンクのいずれかまたは両方を用いて通信を可能にしてもよい。異常検出器１１０は、通信ユニット８１２を介して永続ストレージ８０８にダウンロードしてもよい。

Ｉ／Ｏインタフェース８１４は、クライアントコンピューティングデバイスもしくはサーバコンピュータまたはその両方に接続され得る他のデバイスとのデータの入力および出力を可能にする。例えば、Ｉ／Ｏインタフェース８１４は、キーボード、キーパッド、タッチスクリーン、もしくは他の適切な入力装置またはこれらの組み合わせなどの外部装置８２０との接続を可能にする。また、外部装置８２０は、例えば、サムドライブ、ポータブル光ディスク、ポータブル磁気ディスク、およびメモリカードなどのポータブル・コンピュータ可読記憶媒体を含むこともできる。本発明の実施形態を実施するために用いられるソフトウェアおよびデータ（例えば、異常検出器１１０）は、かかるポータブル・コンピュータ可読記憶媒体に記憶することができ、Ｉ／Ｏインタフェース８１４を介して永続ストレージ８０８にロードすることができる。Ｉ／Ｏインタフェース８１４は、ディスプレイ８２２にも接続する。

ディスプレイ８２２は、ユーザにデータを表示する機構を実現するものであり、例えば、コンピュータモニタとすることができる。

本発明は、システム、方法もしくはコンピュータプログラム製品またはそれらの組み合せとすることができる。コンピュータプログラム製品は、プロセッサに本発明の態様を実行させるためのコンピュータ可読プログラム命令を記憶したコンピュータ可読記憶媒体を含んでよい。

コンピュータ可読記憶媒体は、命令実行装置によって使用される命令を保持し、記憶することができる有形の装置とすることができる。コンピュータ可読記憶媒体は、一例として、電子記憶装置、磁気記憶装置、光学記憶装置、電磁記憶装置、半導体記憶装置またはこれらの適切な組み合わせであってよい。コンピュータ可読記憶媒体のより具体的な一例としては、ポータブルコンピュータディスケット、ハードディスク、ＲＡＭ、ＲＯＭ、ＥＰＲＯＭ（またはフラッシュメモリ）、ＳＲＡＭ、ＣＤ－ＲＯＭ、ＤＶＤ、メモリスティック、フロッピーディスク、パンチカードまたは溝内の隆起構造などに命令を記録した機械的に符号化された装置、およびこれらの適切な組み合せが挙げられる。本明細書で使用されるコンピュータ可読記憶装置は、電波もしくは他の自由に伝播する電磁波、導波管もしくは他の伝送媒体を介して伝播する電磁波（例えば、光ファイバケーブルを通過する光パルス）、またはワイヤを介して送信される電気信号のような、一過性の信号それ自体として解釈されるべきではない。

本明細書に記載のコンピュータ可読プログラム命令は、コンピュータ可読記憶媒体からそれぞれのコンピューティング／処理装置に、または、ネットワーク（例えば、インターネット、ローカルエリアネットワーク、ワイドエリアネットワーク、もしくはワイヤレスネットワークまたはその組み合わせ）を介して外部コンピュータまたは外部記憶装置にダウンロードすることができる。ネットワークは、銅線伝送ケーブル、光伝送ファイバー、無線伝送、ルーター、ファイアウォール、スイッチ、ゲートウェイコンピュータ、もしくはエッジサーバーまたはその組み合わせで構成される。各コンピューティング／処理装置のネットワークアダプタカードまたはネットワークインタフェースは、ネットワークからコンピュータ可読プログラム命令を受信し、それぞれのコンピューティング／処理装置内のコンピュータ可読記憶媒体に格納するためにコンピュータ可読プログラム命令を転送する。

本発明の動作を実行するためのコンピュータ可読プログラム命令は、アセンブラ命令、命令セットアーキテクチャ（ＩＳＡ）命令、機械命令、機械依存命令、マイクロコード、ファームウェア命令、状態設定データ、またはＳｍａｌｌｔａｌｋ、Ｃ＋＋などのオブジェクト指向プログラミング言語と「Ｃ」プログラミング言語や類似のプログラミング言語などの従来の手続き型プログラミング言語を含む、１つ以上のプログラミング言語の任意の組み合わせで記述されたソースコードまたはオブジェクトコードのいずれかであってよい。コンピュータ可読プログラム命令は、スタンドアロンソフトウェアパッケージとして、完全にユーザのコンピュータ上で、または部分的にユーザのコンピュータ上で実行可能である。あるいは、部分的にユーザのコンピュータ上でかつ部分的にリモートコンピュータ上で、または完全にリモートコンピュータまたはサーバ上で実行可能である。後者のシナリオでは、リモートコンピュータは、ローカルエリアネットワーク（ＬＡＮ）またはワイドエリアネットワーク（ＷＡＮ）を含む任意のタイプのネットワークを介してユーザのコンピュータに接続され、または（例えば、インターネットサービスプロバイダーを使用したインターネット経由で）外部コンピュータに接続されてよい。いくつかの実施形態では、例えば、プログラマブルロジック回路、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、またはプログラマブルロジックアレイ（ＰＬＡ）を含む電子回路は、本発明の態様を実行するために、コンピュータ可読プログラム命令の状態情報を利用してパーソナライズすることにより、コンピュータ可読プログラム命令を実行することができる。

本発明の態様は、本発明の実施形態による方法、装置（システム）、およびコンピュータプログラム製品のフローチャート図もしくはブロック図またはその両方を参照して本明細書に記載されている。フローチャート図もしくはブロック図またはその両方の各ブロック、およびフローチャート図もしくはブロック図またはその両方のブロックの組み合わせは、コンピュータ可読プログラム命令によって実装できることが理解されよう。

これらのコンピュータ可読プログラム命令は、コンピュータまたは他のプログラム可能なデータ処理装置のプロセッサを介して実行される命令がフローチャートもしくはブロック図またはその両方の１つまたは複数のブロックで指定された機能／動作を実装するための手段を生成するように、機械を生成するために汎用コンピュータ、専用コンピュータのプロセッサまたは他のプログラム可能なデータ処理装置に提供されることができる。これらのコンピュータ可読プログラム命令はまた、フローチャートもしくはブロック図またはその両方の１つまたは複数のブロックで指定された機能／行為の態様を実装する命令を含む生成品の１つを命令が記憶されたコンピュータ可読プログラム命令が構成するように、コンピュータ、プログラム可能なデータ処理装置、もしくは特定の方法で機能する他のデバイスまたはその組み合わせに接続可能なコンピュータ可読記憶媒体の中に記憶されることができる。

コンピュータ、他のプログラム可能な装置、または他のデバイス上でフローチャートもしくはブロック図またはその両方の１つまたは複数のブロックで指定された機能／行為を実行する命令のように、コンピュータ可読プログラム命令はまた、コンピュータ、他のプログラム可能なデータ処理装置、または他のデバイスにロードされ、コンピュータ、他のプログラム可能な装置、または他のデバイス上で一連の操作ステップを実行し、コンピュータ実装された過程を生成することができる。

図中のフローチャートおよびブロック図は、本発明の様々な実施形態によるシステム、方法、およびコンピュータプログラム製品が実行可能な実装の構成、機能、および動作を示している。これに関して、フローチャートまたはブロック図の各ブロックは、モジュール、セグメント、または命令の一部を表してよく、これは、指定された論理機能を実装するための１つまたは複数の実行可能命令を構成する。いくつかの代替の実施形態では、ブロックに示されている機能は、図に示されている順序とは異なる場合がある。例えば、連続して示される２つのブロックは、実際には、実質的に同時に実行されるか、またはブロックは、関係する機能に応じて逆の順序で実行される場合がある。ブロック図もしくはフローチャート図またはその両方の各ブロック、およびブロック図もしくはフローチャート図またはその両方のブロックの組み合わせは、指定された機能または動作を実行する、または特別な目的のハードウェアとコンピュータ命令の組み合わせを実行する特別な目的のハードウェアベースのシステムによって実装できることにも留意されたい。

本発明の様々な実施形態の説明は、例示の目的で提示されているが、網羅的であることを意図するものではなく、開示される実施形態に限定されることを意図するものでもない。本発明の範囲から逸脱することなく、多くの修正および変更が可能であることは当業者には明らかであろう。本明細書で使用される用語は、実施形態の原理、市場で見られる技術に対する実際の適用または技術的改善を最もよく説明するため、または当業者が本明細書に記載の実施形態を理解できるようにするために選択された。

（さらなるコメントもしくは実施形態またはその両方）
本発明のいくつかの実施形態は、現在の最新技術に関して、以下の事実、潜在的な問題、もしくは潜在的な改善領域またはその組み合わせを認識する。マイクロサービスアーキテクチャは、疎結合コンポーネントがより優れたスケーラビリティ、柔軟性、開発者の生産性の加速などを提供するため、ハイブリッドクラウド環境に展開されるアプリケーションにとって魅力的である。ＳＬＡ違反による深刻な財務・ビジネス上の損失を回避するために、マイクロサービスアプリケーションの管理における最も重要なタスクの１つは、ＤｅｖＯｐｓ／ＳＲＥがタイムリーに根本的な問題を解決するためにさらなる行動を起こすことができるように、特定の時間ステップで効果的かつ効率的に異常を検出し診断することである。しかし、検出された異常に対してプロアクティブな警告を発するための既存のアプローチは、マイクロサービスアプリケーションにはまだ有効ではない。なぜなら、それらは、切り離されたサービスやエンドユーザの要求から得られる多変量の時系列データに埋もれた空間および時間の依存関係を考慮していないからである。

本発明のいくつかの実施形態は、以下の特徴、特性もしくは利点またはその組み合わせのうちの１つ、または複数を含むことができる。テールレイテンシの問題は、モデルで学習され、潜在的な異常が発生する前に予測するのに役立つ。

本発明の実施形態は、マイクロサービスアプリケーションの異常を予測し、根本的なケースを特定する。異常予測の既存の研究の中で、本発明の実施形態は、要求パターンとそのパス（すなわち、要求が通過するサービス）を予測するためのデュアルタスクを実施する最初のものである。本発明の実施形態は、アプリケーションのデプロイメントからデータを収集するための収集エージェントを設計する。このシステムは、プライベート、パブリックおよびハイブリッドという異なる環境でのマイクロサービスアプリケーションのデプロイメントをサポートする。

本発明の実施形態では、要求の３つのレベルの情報（要求仕様、マイクロサービスパス、関数パス）を含むデータ構造である要求文脈的特徴の概念を定義する。この提案された特徴は、受信要求の性能と処理パスに影響を与える２つの履歴データである、要求間要因と要求内要因を統合する。

本発明の実施形態では、要求文脈的特徴の訓練データを統合するために、階層型ニューラルネットワークモデルを設計する。このモデルは、異種データの埋め込みと注意メカニズムを持つｓｅｑ２ｓｅｑアーキテクチャに基づいており、結果の解釈可能性を一定レベルまで高めることができる。

アプリケーション固有のシステムトレース情報のユニークな利点は２つある。タイムスタンプされたシステム利用情報を活用して、システムリソース要件を理解・予測し、ＱｏＳ要件を満たすためにリソースを再割り当てするようシステム管理者をさらに導く。また、アプリケーションから得られる詳細できめ細かいシステム特性は、システムシミュレーションを通じて様々なハードウェアの影響やトレードオフを理解し、その教訓を将来のクラウドシステム設計のインプットとして活用することができる。

本発明の実施形態は、深層学習を用いて要求文脈的データで利用可能な前述の依存関係を水平および垂直方向に分析することにより、マイクロサービスアプリケーションのプロアクティブな警告および異常診断を強化する。提案されたアプローチは、次の２つの具体的な質問に対処する：（１）現在の瞬間から経過した特定の時間ステップでパフォーマンス異常（例えば、ＳＬＡ違反、テールレイテンシの増加）が発生するか？、および（２）（１）が真である場合、異常を引き起こす可能性が最も高いマイクロサービスは何であるのか？。１つ目の質問は異常の予測に関するもので、２番目の質問は予測された異常の根本原因に関するものである。

プロアクティブな警告と異常診断の問題は、一連のマイクロサービスが将来の要求をどのように協調的に処理するかの事前予測タスクと見なすことができる。我々が提案する技術は、履歴要求の詳細な特性を統合するニューラルネットワークアプローチであり、その仕様とパスに沿った各マイクロサービスインスタンスのトレース情報の両方を含む。このニューラルネットワークモデルは、異常（テールレイテンシ、ＳＬＡ違反など）が発生するかどうか、またその根本的な原因は何かを予測することができる。このソリューションは、マイクロサービスアプリケーション（プライベートクラウド、パブリッククラウド、またはハイブリッド）のデプロイメントから独立しており、Ｋｕｂｅｒｎｅｔｅｓ、ＯｐｅｎＳｈｉｆｔなどのさまざまなコンテナオーケストレーターをサポートする。

（キーアイデア）
キーアイディア１：要求文脈的特徴という概念を導入する。これは、因果関係のあるサービスやコールパス、各マイクロサービスでの実行コンテキスト（ＣＰＵ、アクセラレータ、メモリ使用率、ポッドの領域、ネットワークトラック、ＩＯ要求など）を含む要求のエンドツーエンドの詳細を表す階層的データ構造である。要求文脈的特徴は、要求仕様、マイクロサービスパス、関数パスの３つのカテゴリの情報で構成される（詳細はセクション６．２参照）。各カテゴリには、スカラー、ベクトル、カテゴリカルなど、異種形式のデータが含まれる。これらの収集された特徴点は、ニューラルネットワークの訓練データとして提供される。

キーアイディア２：要求文脈的特徴のデータを異なるソースから収集する方法を開発する（セクション６．１）。要求とマイクロサービスのインスタンスを記述するカテゴリカルデータは、要求ヘッダまたはデプロイメントホストの環境変数のいずれかから抽出される。各マイクロサービスに費やされた時間とその重要な機能を報告する数値データは、Ｏｐｅｎ ＴｅｌｅｍｅｔｒｙやＪａｅｇｅｒなどの分散トレーシングライブラリから、リソース使用量を報告するデータは、適切な権限でシステム使用状況の情報を取得することで記録される。その結果、要求の文脈的特徴は、層をまたいで要求の処理を全体的に把握することができるようになる。

キーアイディア３：前述の要求文脈的特徴を入力として階層的に扱うことで、マイクロサービスアプリケーション内で将来の要求がどのように処理されるかを予測するニューラルネットワークモデルを構築する。我々は、要求処理予測は長距離依存の逐次問題であると考える。つまり、近い将来の要求処理は、要求間要因と要求内要因の２つの群の要因に依存する。要求間要因とは、ｈｔｔｐメソッド、ユーザ名、地域などの要求仕様に含まれる特性間のつながりを表す。例えば、ある地域からのユーザＩＤによるログイン要求は、同じ地域および同じユーザＩＤからの商品カタログページへの取得要求に続く可能性が高い。要求内要因は、個々の要求の要因を考慮したものである。要求を処理する際、アプリケーションのマイクロサービスは、互いにＲＰＣコールを送信することで連携している。さらに、各マイクロサービスには多くのレプリカが存在することが多いため、すべてのインスタンスがコールパスに現れるとは限らない。効果的なモデルは、因果関係のあるマイクロサービスパスと関数パスのデータから、処理パス中のどのサービスが将来の要求に対して最も重要な役割を果たすかを理解することができるはずである。上記の全ての要因は、提案モデルによって訓練処理中に捕捉される。

キーアイディア４：監視中、モデルは予測された要求の表現を一度に１タイムステップずつ生成し、複雑な要求間および要求内の依存関係を捕捉する。キーパフォーマンス指標（例えば、レイテンシ）を調べ、統計的指標（例えば、偏差値、パーセンタイル）を計算し、警告を発するかどうかを決定する、という一連の事前予測を解釈するコントローラが作成される。コントローラが警告を発することを決定すると、根本原因分析モジュールは、現在のトレンドに補足された一連の表現を解釈し、根本原因（例えば、ある地域の特定のマイクロサービスインスタンスのメモリ不足、特定のマイクロサービスインスタンスとバックエンドストレージ間の遅い接続）を特定する。

（動機となる例）
この予測問題の動機となる例として、４つのサービスからなるマイクロサービスアプリケーションについて説明する。各要求はＡとＢ、そしてＣかＤのいずれかで処理されなければならない。この特定のシナリオでは、２つの履歴要求がある。サービスパスはＡ→Ｂ→ＣとＡ→Ｂ→Ｄである。次の要求とそのパスを予測するために、これらの要求の順序（つまり、要求間要因）だけを考慮すると、結果はＡ→Ｂ→Ｃとなる。要求間要因から学習したモデルは、要求の順序を予測処理における重要な特徴として考慮する。負荷分散の効果で履歴データにおいてＣとＤが交互に現れることを考えると、この結果は妥当であり、予測された総遅延は＜１秒である。一方、我々が提案したモデルは、サービスパスに沿ったレイテンシに対する注意をより多く維持するため、インテリジェントに機能する。これは、サービスインスタンスＡでの処理時間の増加や、Ａとラストホップの選択との間の相関に起因している可能性がある。したがって、Ａでのレイテンシが高い場合、サービスＤが選択される可能性が高いので、正しい次の要求とそのパスＡ→Ｂ→Ｄをうまく予測することができる。予測された要求のレイテンシの合計は２．３秒で、閾値（１．５秒）より大きいので、ＳＲＥにプロアクティブな警告が送信されることになる。正しい予測を行うためには、個々の要求における要求間要因と要求内要因を共同で考慮する必要がある。これらの要因は、トレースデータ、リソース利用率、仕様などの要求パスの詳細情報から発見することができる。

（説明）
本セクションでは、マイクロサービスアプリケーションのプロアクティブな警告と異常診断の問題に対処するために提案した方法論と技術的な詳細を紹介する。第１段階では、正常な動作と異常動作の両方について、一連の要求のトレースデータと仕様を収集し、特徴抽出のために準備する。この第２段階では、収集したデータから要求文脈的特徴を組み立て、ニューラルネットワークモデルを生成する。第３段階では、事前に訓練させたモデルを用いて異常を予測し、根本原因のリストを提示する役割を果たす。

図２に示すように、提案システムのハイレベルなアーキテクチャは、独自に設計した収集エージェントを有するＮ個のマイクロサービスからなるアプリケーション、およびモデル作成と予測パイプラインで構成される。このセクションの残りでは、エンドツーエンドを詳細に説明する。

（データ収集）
まず（フローチャート５００のステップ５０２～５０４に記載されているように）収集エージェントは、同じ場所に配置されたマイクロサービスからトレースデータを収集する。マイクロサービスとコレクトエージェントのペアは、単一のＫｕｂｅｒｎｅｔｅｓポッドの別々のコンテナで実行される。マイクロサービスはアプリケーションコードを実行して要求を処理し、ダウンストリームサービスに渡す。さらに、収集エージェントは、ＺａｂｂｉｘエージェントやＩｓｔｉｏのＥｎｖｏｙプロキシなどのサイドカーから重要なシステム情報を集約することができる。

マイクロサービス内で動作するアプリケーションコードは、ＪａｅｇｅｒやＯｐｅｎ Ｔｅｌｅｍｅｔｒｙのような分散トレーシングライブラリを使用して、ビジネスロジックにとって重要な機能に費やされた時間を記録し、トレースデータをＵＤＰパケットで収集エージェントに送信する。なお、提案する方法では、フロントエンドサービスにおいて、ユーザ要求の仕様を１回だけ取り込む必要がある（例えば、先に説明した図７（Ａ）を参照）。マイクロサービス内のトレース情報に加えて、収集エージェントは、マイクロサービスインスタンスの静的構成だけでなく、マイクロサービスからトレースを受信する際の動的リソース使用率も取得する必要がある（例えば、既に説明した図７（Ｂ）を参照）。このようなデータは、前述したようにサイドカーから取得することができる。収集エージェントは、これらのデータをバッチに配置し、集中型コレクタに配信する。

コレクタはステートレスサーバとして実装されているため、多数のレプリカに拡張することができる。コレクタは、トレースデータや要求の仕様を受信し、ある共通の表現に正規化し、キューにプッシュする。キューの一例として、Ｋａｆｋａがある。Ｋａｆｋａは、リアルタイムのデータフィードを扱うための高スループット、低レイテンシのプラットフォームを提供するオープンソースソフトウェアである（最大で毎秒１００万件の書き込みができる）。

異常検出器は、キューから、Ｆｌｉｎｋフレームワークの上でストリーミングベースのジョブとして開発された特徴抽出モジュールにプルすることができる。特徴抽出のジョブは、収集されたデータを要求文脈的特徴の形に変換することである。

（特徴の詳細）
収集された特徴は、要求仕様、マイクロサービスパス、関数パスの３つのカテゴリに要約される。要求仕様は静的で、要求の自己記述情報を含み、最も重要なのはアプリケーションを構成する一連のマイクロサービス間のエンドツーエンドのレイテンシである。マイクロサービスパスの特徴とファンクションパスの特徴は、要求の処理パスを記述するために、因果関係のあるデータとして収集される。図６は、タイムウィンドウ内の各ステップで収集される階層的なデータ構造を示している。

（ニューラルネットワークモデル）
ニューラルネットワークモデルの設計は、ｓｅｑ２ｓｅｑアーキテクチャに根ざしている。図６で説明したように、ニューラルネットワークモデルには、エンコーダおよびデコーダ部分、それらの入力と出力が含まれる。エンコーダとデコーダの部分は両方ともＲＮＮベースであり、複数の時間ステップに対応する出力シーケンスを消費して返すことが可能である。モデルは、前のＮ個の値から入力を取得し、それは次のＮ個の予測を返す。Ｎはハイパーパラメータであり、この図では経験的に１０分として設定されている。図の中央には、階層型ＲＮＮベースの異常検出ニューラルネットワークがあり、３つの主要なコンポーネント（要求内要因、要求間要因、および埋め込み）を含む。本セクションの残りでは、ニューラルネットワークの詳細について説明する。

前述したように図３はニューラルネットワークの設計を示すものである。要求内要因については、一連のマイクロサービスパスの特徴と対応する要求仕様を組み合わせている。マイクロサービスパスの特徴は、図４に詳述されており、これもＲＮＮベースのネットワークである。要求間要因については、要求間パターンを訓練するために、一連の要求の要求内要因を別のＲＮＮ層（例えば、ＬＳＴＭ）に供給した。ネットワーク全体を通して、異なる埋め込み層（例えば、ｗｏｒｄ２ｖｅｃ、ＥＬＭＯ）を適用して、異種データをＮ次元ベクトル（例えば、Ｎ＝３００）に変換する。階層型要求予測ニューラルネットワークは、要求間パターンおよび要求内パターンが将来の要求の処理に及ぼす影響を学習する能力を有する。先に強調したように、本発明の実施形態は、将来の要求の仕様、およびアプリケーションのマイクロサービスインスタンスを通るそのパスを予測することを目的とする。

（監視および洞察）
我々のプロアクティブ異常検出問題には、２つの主要なタスクが含まれる：詳細なサービスパスによる将来の要求の予測と、予測に基づくＳＬＡ違反の予期（図５のステップ５０８）。１つ目は、予測モジュールによって実行される（例えば、図５のステップ５１０）。監視段階では、システムは実行中のアプリケーションから要求文脈的データを継続的に収集し、それらを予測モジュールに取り込む。これらのデータは、ストレージからフェッチされたニューラルネットワークモデルに供給される。予測モジュールの出力は、次のＷｔ秒以内に発生する、実行内容が予測された要求のシーケンスである。例えば、自動リソース分割ソフトウェアが行動を起こす機会を持つように、経験則からＷｔを５００ｍｓに設定する。

プロアクティブな警告を決定する第２のタスクのために、予測モジュールからの出力を解釈するコントローラを統合する。図２および図５のステップ５１０に示すように、コントローラは複数の機能を備えている。プロアクティブな警告に関しては、予測されたレイテンシのテールを計算する。その結果が特定の閾値より大きい場合、プロアクティブな警告が発せられる。予測結果の詳細は、根本原因分析、リソース管理、システムシミュレーションなどの高度なミッションのためにさらに活用される。

システムシミュレーション：図３の出力には、Ｚａｂｂｉｘエージェントからオンザフライのアプリケーションの詳細なシステム（ＣＰＵ、メモリ、ディスク、およびネットワーク使用量など）のトレース情報が含まれている。図１で説明したように、システムシミュレーションでは、このようなきめ細かい特徴的なトレースは、基礎となるハードウェアシステム上で要求されるアプリケーションの洞察を提供し、これをシステムシミュレータのドライバとして使用して、潜在的なクラウドシステム設計を評価し、課題およびトレードオフを学習することができる。このプロセスは、クラウドシステム設計者が、ストレージ、ネットワーク、ＣＰＵ、メモリ、アクセラレータなど、さまざまなアプリケーションから構成されるさまざまなハードウェアコンポーネント間の相互作用を理解するために役立つ。また、さまざまなハードウェア構成による潜在的な利点と劣化を分析し、将来のクラウドシステムの設計決定を導くのに役立つ。

（定義）
本発明：「本発明」という用語で説明される主題が、出願時の特許請求の範囲、または特許審査後に最終的に発行される可能性のある特許請求の範囲によってカバーされることを絶対的に示すものとして解釈されるべきではない。「本発明」という用語は、読者が本明細書におけるどの開示が潜在的に新しいと考えられるか一般感をつかむのに役立つために使用されているが、この「本発明」の用語の使用で示された理解は、暫定かつ仮のものであり、特許審査の過程で関連情報の開発および特許請求の範囲の修正により変化し得るということを示している。

実施形態：上記の「本発明」の定義を参照のこと。「実施形態」という用語にも同様の注意事項が適用される。

および／または（and/or）：包含的論理和；例えば、Ａ、Ｂ「および／または」Ｃは、ＡまたはＢまたはＣの少なくとも１つが真であり適用可能であることを意味する。

含む（inducing/include/includes）：特に明示しない限り、「含むが、必ずしも限定はされない」ことを意味する。

ユーザ／加入者：以下を含むが、必ずしもこれらに限定されるものではない：（ｉ）一人の人間、（ｉｉ）ユーザまたは加入者として行動するのに十分な知能を有する人工知能エンティティ、もしくは、（ｉｉｉ）関連するユーザまたは加入者の群、またはその組み合わせ。

モジュール／サブモジュール：ある種の機能を果たすために動作的に機能するハードウェア、ファームウェア、もしくはソフトウェア、またはその組み合わせの任意のセットであり、モジュールが、（ｉ）単一のローカルな近接した場所にあるか、（ｉｉ）広範囲に分散しているか、（ｉｉｉ）大きなソフトウェアコード内の単一の近接した場所にあるか、（ｉｖ）単一のソフトウェアコード内にあるか、（ｖ）単一のストレージデバイス、メモリまたは媒体内にあるか、（ｖｉ）機械的につながっているか、（ｖｉｉ）電気的につながっているか、（ｖｉｉｉ）データ通信でつながっているか、を問わず、あらゆるものがある。

コンピュータ：デスクトップコンピュータ、メインフレームコンピュータ、ラップトップコンピュータ、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）ベースのデバイス、スマートフォン、パーソナルデジタルアシスタント（ＰＤＡ）、ボディマウント型または挿入型コンピュータ、組み込みデバイススタイルのコンピュータ、特定用途向け集積回路（ＡＳＩＣ）ベースのデバイスなど（ただし、これらに限らない）を含む、重要なデータ処理もしくは機械可読命令読み取り機能またはその両方を持つあらゆるデバイス。

収集エージェント２０６Ａは、収集要求を行い、それぞれのインスタンスのトレースデータおよび仕様を抽出する責任を負う。本実施形態では、それぞれの収集エージェントは、異常検出器１１０のコレクタモジュール（例えば、コレクタモジュール２０８）とインタフェースすることができる。コレクタモジュール２０８は、受信した情報（それぞれのトレースデータおよび仕様）をコンパイルする責任を負う。コレクタモジュール２０８は、次に、正規化モジュール２１０を使用してデータを正規化することができ、すなわち、正規化モジュール２１０は、データを一貫したフォーマット、（例えば、ＪＳＯＮまたは共通のデータ構造）へ正規化する。コレクタモジュール２０８は、その後、コンパイルされた情報を永続化のためのキューにプッシュすることができる。

次に、特徴抽出モジュール２１２は、キュー内のデータにアクセスし、コンパイルされたデータから文脈的特徴を抽出することができる。言い換えれば、特徴抽出モジュール２１２は、生データを要求文脈的特徴に変換する。例えば、要求文脈的特徴（すなわち、要求仕様）は、以下を含むことができる：ユーザ名（匿名化ＩＤ）、企業名（匿名化ＩＤ）、レイテンシ（５００ｍｓ）、地域（欧州）、ブラウザ（Ｆｉｒｅｆｏｘ）、デバイス（ｉＯＳ）、オペレーティングシステム、時間（例えば、２０２０年２月２８日金曜日、午後２：５５：０２ ＧＭＴ－０５：００）、それぞれのマイクロサービスパス（例えば、マイクロサービスＡからマイクロサービスＢへのパス。例えば、マイクロサービスＡに関連するクラスタＩＤ、地域（ｕｓ）、インスタンスＩＤ、期間（１００ｍｓ）、ＯＳ仕様（ＣＰＵ、メモリ、ディスク、ネットワーク）、マイクロサービスＢのそれぞれのクラスタＩＤ、地域（ｕｓ）、インスタンスＩＤ、期間（４００ｍｓ）、ＯＳ仕様（ＣＰＵ、メモリ、ディスク、ネットワーク）、および関数パス（例えば、関数１から３まで：関数１は、期間（４０ｍｓ）、リソース利用率（２０％、１００ＭＢ）を含み、関数２は、期間（６０ｍｓ）、リソース利用率（２０％、１００ＭＢ）を含み、期間（４００ｍｓ）、リソース利用率（２０％、１００ＭＢ）を含む関数１に戻る。）である。

処理は、ブロック３４０および３５０（例えば、ＬＳＴＭ３４０および密度３５０）を含む要求間因子を追加するために継続される。ブロック３４０において、文脈的特徴は、深層学習の分野で使用される長短期（ＬＳＴＭ）アーキテクチャを介して供給され、Ｄ１が追加され、それぞれ３１４Ａ～Ｎと呼ばれる。本実施形態では、Ｄ１は、ＬＳＴＭモデルの単一のユニットである。Ｃ１、Ｃ２、...ＣＮは、個々の要求のモデル化された出力であることを想起されたい。異常検出器１１０は、ＬＳＴＭモデルを用いて、要求間の要求内関係を学習する。本実施形態では、Ｄ１～ＤｎはＬＳＴＭモデルのユニットである。最後に、密度３５０において、３１６Ａ～Ｎと呼ばれるＥ１が追加される。本実施形態では、Ｅ１～ＥＮは密結合ネットワークのユニットであり、それらの内部相関を見つけるために、入力の次元を下げるものである。結果の出力はＹ_１、Ｙ_２～Ｙ_Ｎであり、それぞれ３１８_Ａ～Ｎとして参照される。

本実施形態では、ブロック４３０において、埋め込まれた要求仕様が長短期記憶（ＬＳＴＭ）、人工リカレントニューラルネットワーク（ＲＮＮ）を介して供給され、それぞれのＫ_１，１、Ｋ_１，２、Ｋ_２，１およびＫ_Ｂ，１（すなわち、ＬＳＴＭモデルのユニットがそれぞれ４０８Ａ、４０８Ｂ、４０８Ｃおよび４０８Ｎとして参照される）が追加される。

処理はマイクロサービス埋め込みのためのブロック４４０に続き、Ｍ_１、Ｍ_２およびＭ_ＢとＯ_１、Ｏ_２およびＯ_Ｂがそれぞれ追加される。Ｍ_１、Ｍ_２およびＭ_Ｂはブロック４１０Ａ、４１０Ｂ、４１０Ｎとして参照され、Ｂマイクロサービスを表すＬＳＴＭモデルの出力（例えば、ブロック４３０）であり、Ｏ_１、Ｏ_２およびＯ_Ｂはそれぞれブロック４１２Ａ、４１２Ｂ、４１２Ｎとして参照され、Ｂマイクロサービスの仕様の埋め込みを参照する。

処理はブロック４５０に続き、ブロック４４０の結果が別のＬＴＳ層を介して供給され、Ｐ_１、Ｐ_２およびＰ_Ｂがそれぞれ追加される。Ｐ_１、Ｐ_２およびＰ_Ｂは、それぞれブロック４１４Ａ、４１４Ｂ、４１４Ｎとして参照される。本実施形態では、Ｐ_１、Ｐ_２およびＰ_Ｂはブロック４５０のＬＳＴＭモデルのユニットである。

Claims (20)

1. 要求を受信することに応答して、マイクロサービスアプリケーションの正常動作のための一連の要求のトレースデータおよび仕様を収集することと、
   前記収集されたトレースデータおよび仕様から、要求文脈的特徴を生成することと、
   前記生成された文脈的特徴に基づいて、ニューラルネットワークモデルを訓練することと、
   前記訓練されたニューラルネットワークモデルを使用して、前記マイクロサービスアプリケーションの異常動作を予測することと、
   を含む、コンピュータ実装方法。
2. 前記予測された異常動作に関連するビジュアライゼーションを生成すること
   をさらに含む、請求項１に記載のコンピュータ実装方法。
3. 前記予測された異常動作の根本原因レポートを生成すること
   をさらに含む、請求項１に記載のコンピュータ実装方法。
4. 前記予測された異常動作に対するシステムシミュレーションを提供すること
   をさらに含む、請求項１に記載のコンピュータ実装方法。
5. 前記トレースデータは、ログを個々の要求に分離する階層的なデータ構造を提供する、請求項１に記載のコンピュータ実装方法。
6. 前記ニューラルネットワークモデルはリカレントニューラルネットワークである、請求項１に記載のコンピュータ実装方法。
7. 前記要求文脈的特徴は、
   要求の仕様、マイクロサービスパスおよび関数パス、の要求の３つのレベルの情報を含むデータ構造を含む、請求項１に記載のコンピュータ実装方法。
8. 前記収集されたトレースデータおよび仕様から要求文脈的特徴を生成することは、
   前記要求に関連する要求間要因および要求内要因を統合することを含む、請求項１に記載のコンピュータ実装方法。
9. １または複数のコンピュータ可読記憶媒体と、前記１または複数のコンピュータ可読記憶媒体に記憶されたプログラム命令と、を含み、前記プログラム命令は、
   要求を受信することに応答して、マイクロサービスアプリケーションの正常動作のための一連の要求のトレースデータおよび仕様を収集するプログラム命令と、
   前記収集されたトレースデータおよび仕様から、要求文脈的特徴を生成するプログラム命令と、
   前記生成された文脈的特徴に基づいて、ニューラルネットワークモデルを訓練するプログラム命令と、
   前記訓練されたニューラルネットワークモデルを使用して、前記マイクロサービスアプリケーションの異常動作を予測するプログラム命令と、
   を含む、コンピュータプログラム製品。
10. 前記１または複数のコンピュータ可読記憶媒体に記憶された前記プログラム命令は、
    前記予測された異常動作に関連するビジュアライゼーションを生成するプログラム命令
    をさらに含む、請求項９に記載のコンピュータプログラム製品。
11. 前記１または複数のコンピュータ可読記憶媒体に記憶された前記プログラム命令は、
    前記予測された異常動作の根本原因レポートを生成するプログラム命令
    をさらに含む、請求項９に記載のコンピュータプログラム製品。
12. 前記１または複数のコンピュータ可読記憶媒体に記憶された前記プログラム命令は、
    前記予測された異常動作に対するシステムシミュレーションを提供するプログラム命令
    をさらに含む、請求項９に記載のコンピュータプログラム製品。
13. 前記トレースデータは、ログを個々の要求に分離する階層的なデータ構造を提供する、請求項９に記載のコンピュータプログラム製品。
14. 前記ニューラルネットワークモデルはリカレントニューラルネットワークである、請求項９に記載のコンピュータプログラム製品。
15. 前記要求文脈的特徴は、
    要求の仕様、マイクロサービスパスおよび関数パス、の要求の３つのレベルの情報を含むデータ構造を含む、請求項９に記載のコンピュータプログラム製品。
16. 前記収集されたトレースデータおよび仕様から要求文脈的特徴を生成する前記プログラム命令は、
    前記要求に関連する要求間要因および要求内要因を統合するプログラム命令を含む、請求項９に記載のコンピュータプログラム製品。
17. １または複数のコンピュータプロセッサと、
    １または複数のコンピュータ可読記憶媒体と、
    前記１または複数のコンピュータプロセッサの少なくとも１つによって実行するための前記１または複数のコンピュータ可読記憶媒体に記憶されたプログラム命令と、を含み、前記プログラム命令は、
    要求を受信することに応答して、マイクロサービスアプリケーションの正常動作のための一連の要求のトレースデータおよび仕様を収集するプログラム命令と、
    前記収集されたトレースデータおよび仕様から、要求文脈的特徴を生成するプログラム命令と、
    前記生成された文脈的特徴に基づいて、ニューラルネットワークモデルを訓練するプログラム命令と、
    前記訓練されたニューラルネットワークモデルを使用して、前記マイクロサービスアプリケーションの異常動作を予測するプログラム命令と、
    を含む、コンピュータシステム。
18. 前記１または複数のコンピュータ可読記憶媒体に記憶された前記プログラム命令は、
    前記予測された異常動作に関連するビジュアライゼーションを生成するプログラム命令
    をさらに含む、請求項１７に記載のコンピュータシステム。
19. 前記１または複数のコンピュータ可読記憶媒体に記憶された前記プログラム命令は、
    前記予測された異常動作の根本原因レポートを生成するプログラム命令
    をさらに含む、請求項１７に記載のコンピュータシステム。
20. 前記１または複数のコンピュータ可読記憶媒体に記憶された前記プログラム命令は、
    前記予測された異常動作に対するシステムシミュレーションを提供するプログラム命令
    をさらに含む、請求項１７に記載のコンピュータシステム。

Images