(57)【特許請求の範囲】
【請求項１】
方法であって、
クラウドコンピュータシステムによって、サービスを提供するクラウドコンピュータ環境で実行されるコンポーネントを確立するステップを備え、前記サービスは、前記クラウドコンピュータシステム内のアセンブリをデプロイすることで生成される前記コンポーネントによって確立され、前記コンポーネントは、第１のコンテナおよび第２のコンテナを含み、前記第１のコンテナは、前記サービスのための前記第２のコンテナにおいて実行される子コンテナである仮想マシンを含み、前記第２のコンテナは、コンピュータシステムを含み、
前記クラウドコンピュータシステムによって、前記クラウドコンピュータ環境によって提供される前記サービスに関連するメトリックの正常範囲を定義する一組の値を求めるステップを備え、
前記第１のコンテナにおける１つ異常の異常イベントの解決のために、異常検出および解決コンポーネント（ＡＤＲＣ）を含むように前記第１のコンテナを構成するステップと、
前記ＡＤＲＣによって、前記クラウドコンピュータ環境によって提供される前記サービスのオペレーションに関連する異常の異常イベントを前記第１のコンテナにおいて検出するステップとを備え、前記異常イベントは、前記メトリックの値が前記メトリックの前記正常範囲を満たさないことに基づいて検出され、
前記ＡＤＲＣによって、前記第１のコンテナにおいて前記異常を解決するためのポリシーを特定するステップと、
前記ＡＤＲＣによって、前記ポリシーにおけるルールが前記異常によって満たされることを判断するステップと、
前記ＡＤＲＣによって、前記異常を解決するための前記第１のコンテナにおける修正アクションを起動するステップとを備え、前記修正アクションは、前記ルールが前記異常によって満たされたことに基づいて前記ポリシーで特定される、方法。
【請求項２】
前記正常範囲は、ユーザ定義の異常について定義される固定された範囲であり、前記一組の値は、ポーリング間隔値、前記メトリックの最小値尺度、前記メトリックのソフト限界、前記メトリックの最大値、および前記異常の最小発生回数を定義する最小連続読取値を含む、請求項１に記載の方法。
【請求項３】
前記異常イベントを検出するステップは、前記メトリックの値が前記正常範囲を満たすか否かを判断するステップを含み、前記メトリックの値は、前記メトリックの値が前記最小値尺度未満である場合および前記ソフト限界以上である場合には、前記正常範囲を満たさない、請求項２に記載の方法。
【請求項４】
前記異常イベントはさらに、前記最小連続読取値が満たされたことに基づいて検出される、請求項２または３に記載の方法。
【請求項５】
前記正常範囲は、ユーザ定義の異常について定義される周期的範囲であり、前記一組の値は、ポーリング間隔値、前記メトリックの最小値尺度、前記メトリックのソフト限界、前記メトリックの最大値、前記異常の連続発生期間、前記周期的範囲が有効である開始時刻、および前記周期的範囲が有効である終了時刻を含む、請求項４に記載の方法。
【請求項６】
前記異常イベントを検出するステップは、前記メトリックの値が前記正常範囲を満たすか否かを判断するステップを含み、前記メトリックの値は、前記メトリックの値が前記最小値尺度未満である場合および前記ソフト限界以上である場合、前記異常イベントが前記連続発生期間中に検出され、前記開始時刻後であって前記終了時刻前に検出される場合には、前記正常範囲を満たさない、請求項５に記載の方法。
【請求項７】
前記一組の値を求めるステップは、ログファイルの時系列データを分析して前記正常範囲について前記一組の値を計算するステップを含む、請求項１〜６のいずれか１項に記載の方法。
【請求項８】
前記第１のコンテナにおいて前記異常を解決するためのポリシーを特定できないと判断すると、前記第１のコンテナにおいて前記異常を解決できないことを前記第２のコンテナに通知するステップと、
前記第２のコンテナにおいて前記異常を解決するためのポリシーを特定するステップと、
前記第２のコンテナにおいて前記異常を解決するための前記ポリシーにおけるルールが前記異常によって満たされることを判断するステップと、
前記ルールが満たされたことに基づいて、前記第２のコンテナにおいて前記異常を解決するための、前記ポリシーで特定される修正アクションを起動するステップとをさらに備える、請求項１〜７のいずれか１項に記載の方法。
【請求項９】
前記サービスに関連する前記メトリックは、前記サービスを提供するためのサービス品質（ＱｏＳ）について監視される複数のメトリックのうちの１つである、請求項１〜８のいずれか１項に記載の方法。
【請求項１０】
クラウドコンピュータシステムであって、
１つ以上のプロセッサと、
前記１つ以上のプロセッサにアクセス可能なメモリとを備え、前記メモリは、命令を格納し、前記命令は、前記１つ以上のプロセッサによって実行されると、前記１つ以上のプロセッサに、
サービスを提供するクラウドコンピュータ環境で実行されるコンポーネントを確立するステップを実行させ、前記サービスは、前記クラウドコンピュータシステム内のアセンブリをデプロイすることで生成される前記コンポーネントによって確立され、前記コンポーネントは、前記サービスのための第１のコンテナおよび第２のコンテナを含み、前記第１のコンテナは、前記サービスのための前記第２のコンテナにおいて実行される子コンテナである仮想マシンを含み、前記第２のコンテナは、コンピュータシステムを含み、
前記クラウドコンピュータ環境によって提供される前記サービスに関連するメトリックの正常範囲を定義する一組の値を求めるステップを実行させ、
前記第１のコンテナにおける１つ異常の異常イベントの解決のために、異常検出および解決コンポーネント（ＡＤＲＣ）を含むように前記第１のコンテナを構成するステップを実行させ、
前記ＡＤＲＣによって、前記クラウドコンピュータ環境によって提供される前記サービスのオペレーションに関連する異常の異常イベントを前記第１のコンテナにおいて検出するステップを実行させ、前記異常イベントは、前記メトリックの値が前記メトリックの前記正常範囲を満たさないことに基づいて検出され、
前記ＡＤＲＣによって、前記第１のコンテナにおいて前記異常を解決するためのポリシーを特定するステップを実行させ、
前記ＡＤＲＣによって、前記ポリシーにおけるルールが前記異常によって満たされることを判断するステップを実行させ、
前記ＡＤＲＣによって、前記異常を解決するための前記第１のコンテナにおける修正アクションを起動するステップとを実行させ、前記修正アクションは、前記ルールが前記異常によって満たされたことに基づいて前記ポリシーで特定される、クラウドコンピュータシステム。
【請求項１１】
方法であって、
クラウドコンピュータシステムによって、サービスを提供するクラウドコンピュータ環境で実行されるコンポーネントを確立するステップを備え、前記サービスは、前記クラウドコンピュータシステム内のアセンブリをデプロイすることで生成される前記コンポーネントによって確立され、前記コンポーネントは、第１のコンテナおよび第２のコンテナを含み、前記第１のコンテナは、前記サービスのための前記第２のコンテナにおいて実行される子コンテナである仮想マシンを含み、前記第２のコンテナは、コンピュータシステムを含み、
前記クラウドコンピュータシステムによって、前記クラウドコンピュータ環境によって提供される前記サービスに関連するメトリックの正常範囲を定義する一組の値を求めるステップを備え、
前記第１のコンテナにおける１つ異常の異常イベントの解決のために、第１の異常検出および解決コンポーネント（ＡＤＲＣ）を含むように前記第１のコンテナを構成するステップと、
前記第２のコンテナにおける１つ異常の異常イベントの解決のために、第２のＡＤＲＣを含むように前記第２のコンテナを構成するステップと、
前記第１のＡＤＲＣによって、前記クラウドコンピュータ環境によって提供される前記サービスのオペレーションに関連する異常の異常イベントを前記第１のコンテナにおいて検出するステップとを備え、前記異常イベントは、前記メトリックの値が前記メトリックの前記正常範囲を満たさないことに基づいて検出され、
前記第１のＡＤＲＣが前記第１のコンテナにおいて前記異常を解決するためのポリシーを有するか否かを判断するステップと、
前記第１のＡＤＲＣが前記第１のコンテナにおいて前記異常を解決するためのポリシーを持たないと判断したことに基づいて、前記第１のコンテナにおいて前記異常を解決できないことを前記第２のコンテナに通知するステップと、
前記第２のＡＤＲＣによって、前記第２のコンテナにおいて前記異常を解決するためのポリシーを前記ＡＤＲＣのために特定するステップと、
前記第２のＡＤＲＣによって、前記第２のコンテナにおいて前記異常を解決するための前記ポリシーにおけるルールが前記異常によって満たされることを判断するステップと、
前記第２のＡＤＲＣによって、前記ルールが満たされたことに基づいて、前記第２のコンテナにおいて前記異常を解決するための、前記ポリシーで特定される修正アクションを起動するステップとを備える、方法。
【請求項１２】
前記第２のコンテナにおいて前記異常を解決するためのポリシーを持たないと前記第２のＡＤＲＣによって判断したことに基づいて、前記異常を解決できなかったという警告を通信システムを用いて送信するステップをさらに備える、請求項１１に記載の方法。
【請求項１３】
前記第２のコンテナにおいて前記異常を解決するためのポリシーを持たないと前記第２のＡＤＲＣによって判断したことに基づいて、前記異常を解決できないことを第３のコンテナに通知するステップをさらに備え、前記第３のコンテナは、前記コンポーネントのうちの１つであり、前記第３のコンテナは、前記第２のコンテナを含み、
前記第３のコンテナ内に構成される第３のＡＤＲＣによって、前記第３のコンテナにおいて前記異常を解決するためのポリシーを特定するステップと、
前記第３のコンテナにおいて前記異常を解決するための、前記ポリシーで特定される修正アクションを起動するステップとを備える、請求項１１または１２に記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
関連出願の相互参照
本願は、「自動異常検出および解決システム（AUTOMATIC ANOMALY DETECTION AND RESOLUTION SYSTEM）」と題される、２０１６年５月２６日に出願された米国非仮特許出願番号第１５／１６５，２９８号の利益および優先権を主張し、米国非仮特許出願番号第１５／１６５，２９８号は、以下の出願の利益および優先権を主張する：
１）「自動異常検出および解決（Automatic Anomaly Detection and Resolution）」と題される、２０１５年５月２８日に出願された米国仮出願番号第６２／１６７，８５１号
２）「自動異常検出および解決（Automatic Anomaly Detection and Resolution）」と題される、２０１５年７月３１日に出願された米国仮出願番号第６２／１９９，８９５号、および
３）「自動異常検出および解決（Automatic Anomaly Detection and Resolution）」と題される、２０１５年１０月２３日に出願された米国仮出願番号第６２／２４５，７０６号。
【０００２】
上記の特許出願の各々の内容全体は、全ての目的で引用によって本明細書に援用される。
【背景技術】
【０００３】
背景
クラウドコンピューティングは、構成可能な計算リソース（たとえば、ネットワーク、サーバ、ストレージ、アプリケーションおよびサービス）の共有プールへの便利なオンデマンドのネットワークアクセスを可能にするためのモデルである。ネットワークを介してなど、クラウドコンピューティングを介して提供またはアクセスされるサービスは、クラウドサービスと称することができる。契約している顧客がクラウドサービスを利用できるようにするためにクラウドサービスプロバイダが実行する必要がある処理は多数ある。その複雑さのために、この処理の多くは依然として手動でなされている。たとえば、このようなクラウドサービスを提供するためのプロビジョニングリソースは、非常に労働集約型のプロセスである可能性がある。
【０００４】
クラウドコンピューティングシステムをサポートするデータセンタは、サイズが非常に大きくなりがちであり、何千もの計算およびストレージサーバと何百ものネットワークおよび他のデバイスとを備える。たとえば、最近の統計が示唆しているところによると、８０，０００以上の仮想マシンが存在し、オラクル社によって世界全体に提供されているクラウドコンピューティングシステムでは５４０ＰＢ以上のストレージが利用されている。少なくとも１９層の４つのデータセンタがあり、６２００万人以上のアクティブユーザがいるため、日々のトランザクションは３００億以上になる。クラウドデータセンタの手動管理は、MCollectiveまたはChefなどのコマンドツールおよびGraphiteなどの監視ツールを使用したとしても、クラウドサービスのコストを増大させるおそれがあり、サービス品質を低下させるおそれがある。このようなツールは、サービスレベル合意（service level agreement：ＳＬＡ）およびセキュリティ違反に影響を及ぼす異常などのシステム挙動における起こり得る異常にタイムリーに反応して修正することができない。
【０００５】
いくつかのクラウドコンピューティングシステムプロバイダは、それらのクラウドコンピューティングシステムにおいて検出された問題を診断して修正するようにシステムを実現してきたが、このようなシステムがどのように問題を検出するように構成されるかについての詳細は、クラウドコンピューティングシステム全体では定義されてこなかった。中には、ログファイルおよび／または開発されたトレーニングデータを評価して何が正常なシステム挙動であるかを確立するように機械学習アルゴリズムを実現してきたものもいる。ログファイルおよび／またはデータは正常なパターンと比較され得て、いかなる相当な逸脱も異常として報告される。多変量解析技術（たとえば、ＭＳＥＴ）は、複数のログファイルを同時に比較することができる。教師なし機械学習技術によってログファイルのみから正常な挙動を推測することは、エラーを起こしやすい可能性がある。システムトポロジ、処理フローまたはログ関係に関係なくもっぱらログファイルで確認される計算問題は、多数のノイズを持ち込むおそれがある。なぜなら、問題の診断に悪影響を及ぼし得るログファイルの無関係の組み合わせが分析される可能性があるからである。このようなシステムによって検出されて報告される起こり得るエラーは、非常に広範であるのでプログラム修正アクションに適さない。人間が関与して問題に対処する必要があるかもしれない。
【０００６】
クラウドコンピューティングシステムまたはエンタープライズコンピューティングシステムにおける異常は、負荷スパイク、コンポーネント障害および／またはシステムの悪意ある使用を含む多くの要因によって引き起こされる可能性があり、それらの異常は、リソース使用の増加、重要業績指標（key performance indicator：ＫＰＩ）の悪化、および１つ以上のコンテナでのエラーのスパイクという形で顕在化する。上記の課題の結果、サービスレベル合意（ＳＬＡ）のサービス品質（quality of service：ＱｏＳ）保証をしばしば満たすことができない。クラウドコンピューティングシステムおよびエンタープライズコンピューティングシステムでは、任意の所与の時点で、何百万ものハードウェアおよびソフトウェアコンポーネントが機能しなくなる可能性がある。ユーザもオペレータも同様に、異常を引き起こすヒューマンエラーおよび不測の負荷の一因となり得る。悪意のあるユーザは、何百万人ものユーザに影響を及ぼす停止を生じさせる可能性がある。これらの状況は、不満足なＱｏＳにつながって、クラウドコンピューティング環境でＳＬＡの違反を生じさせるおそれがある。
【０００７】
異常に対処するために、中には、リアルタイムに近い態様で異常を監視しようと試みてきたものもいる。これらのアプローチは、集中型ストレージにおいて環境の状態（メトリック、ログなど）を収集して、異常があるかどうかプログラム的に状態を分析することを含む。環境の状態の収集は、このようなデータの通信および集約のために待ち時間を生じさせる可能性がある。分析はさらなる時間を必要とし、ガイドラインおよびスクリプトに従った異常の手動修正のために結果をオペレーションスタッフに通信しなければならない。このような修正アクションは、異常が発生したときと修正アクションを講じるときとの間に長い待ち時間を生じさせる可能性がある。全てのログエントリおよびメトリックを収集して分析することは、リソースの非効率的な使用である。なぜなら、ログファイル内の大半のデータは正常な状態に対応するからである。異常は特定すべき信号であるので、データは低い信号対雑音比を提供し得る。さらに、異常はクラッシュ、デッドロック、長い応答時間などのまれに起こるケースに関連するので、状態が正常であるかどうかのデータの分析は最小値を提供し得る。前兆事象を特定してまず第一にＳＬＡの違反を生じさせる状況を回避するために、異常のきめ細かい検出が求められる。
【発明の概要】
【課題を解決するための手段】
【０００８】
発明の簡単な概要
特定の実施例において、コンピューティング環境（たとえば、クラウドコンピューティングシステムおよびエンタープライズコンピューティングシステム）において異常を自動的に検出して解決するための異常検出および解決システム（anomaly detection and resolution system：ＡＤＲＳ）の技術が開示されている。これらの技術は、異常の自動検出および解決が、コンピューティングシステムにおいて提供されるサービスのサービスレベル合意（ＳＬＡ）違反を回避とまではいかなくても最小限にすることを可能にする。異常検出および解決は、可能な限り低いコストでＳＬＡ準拠期間を最大化することに関係している。本明細書に開示されている技術は、大規模コンピューティングシステム（たとえば、クラウドシステム）のサイズおよび複雑さに対処することへの人間の関与を排除とまではいかなくても減少させることができ、そのため、自律型コンピューティングシステムをもたらすことができる。
【０００９】
ＡＤＲＳは、応答時間異常、負荷異常、リソース使用異常、コンポーネント障害および停止などの異常を自動的に検出して修正することができ、当該異常は全て、コンピューティングシステムでのオペレーションのサービス品質（ＱｏＳ）に影響を及ぼし得る。ＡＤＲＳは、定義済みの異常および未定義の異常などのさまざまなカテゴリ（サブタイプ）の異常によって定義される異常分類システムを使用して実現され得る。定義済みの異常は、ユーザ定義の異常およびシステム推測の異常などの２つのサブカテゴリによって定義され得る。定義済みの異常は、監視する必要がある任意のメトリックの範囲に基づき得て、当該範囲は、固定されているかまたは周期的（seasonal）である。固定された範囲は、ＳＬＡに関連付けられるＱｏＳ保証を監視して実施するための不変量である。一般に、アプリケーション管理者またはシステム管理者は、ユーザ定義の異常について固定された範囲を定義するであろう。また、システム管理者は、リソース使用、負荷スパイク、悪意ある使用およびコンポーネント障害を監視してＳＬＡ違反を回避するためにさらなるメトリックを定義し得るが、それらの範囲は、周期的なものであり、ユーザ定義の異常に関連付けられるメトリックの傾向と組み合わせた履歴データから計算される。このタイプの異常は、システム推測の異常と呼ばれ、その範囲は通常周期的である。未定義の異常は、機械学習および他の統計的方法によって発見される異常（通常、外れ値）である。
【００１０】
ＡＤＲＳは、異常についてポリシーで定義される１つ以上のルールに基づいて修正アクションを講じることができる。ＡＤＲＳは、１つ以上の異常検出および解決コンポーネント（anomaly detection and resolution component：ＡＤＲＣ）で実現され得る。各ＡＤＲＣは、モジュールまたはサブシステムであってもよい。ＡＤＲＣは、コンピューティングシステムによって実行されるサービスまたはオペレーションを定義するコンポーネントの各コンポーネントにおいて実現され得る。各ＡＤＲＣは、コンポーネントにおいて局所的に異常を検出して解決しようと試みるように構成され得る。たとえば、サービスが実行されているコンテナなどのコンポーネントにおいて異常（たとえば、定義済みの異常）を検出すると、ＡＤＲＣは、異常を解決できるか否かを判断し得る。各ＡＤＲＣは、コンポーネントで検出された異常を管理するためのコンポーネントに特有の解決ポリシーで実現され得る。コンポーネントで定義される異常解決ポリシーによって異常の異常イベントを解決できる場合、ＡＤＲＣは、当該ポリシーに基づいて異常イベントを解決しようと試みることができる。ポリシーが定義されていないか、またはポリシーに基づいて異常イベントを解決できなかったといういずれかの理由で、ＡＤＲＣが異常イベントを解決できないと判断すると、コンポーネントは、存在する場合には当該コンポーネントの親コンポーネントに異常イベントを通信し得る。親コンポーネントが異常イベントを解決できるまで、異常イベントは、存在する場合には現在のコンポーネントの各々の次に続く親コンポーネントに至るまで通信され得る。コンポーネントが親コンポーネントを持たない（たとえば、物理マシンが親を持たない）と判断すると、異常イベントは、コンピューティングシステムの環境レベルにおけるＡＤＲＣのためのメッセージングシステムに対して発行されて、異常イベントに対処する。いくつかの実施例では、異常イベントは、ユーザに対する警告として通信され得る。異常解決のためのこの階層型アプローチは、集中型異常管理と比較して素早く、リソース使用の点で効率的である。具体的には、コンポーネント内の各ＡＤＲＣは、特定のタイプの異常に局所的に対処するように構成され得て、その結果、異常を解決できるコンポーネント内のリソースを利用することによって通信時間およびリソース使用を減少させることができる。
【００１１】
いくつかの実施例では、異常検出および解決のためのコンピュータシステムが実現され得る。コンピュータシステムは、異常検出および解決システムの一部であってもよい。コンピュータシステムは、クラウドコンピュータシステム（たとえば、クラウドインフラストラクチャシステム）またはエンタープライズコンピュータシステムにおいて実現され得る。コンピュータシステムは、本明細書に記載されている方法および動作を実現するように構成され得る。コンピュータシステムは、１つ以上のプロセッサと、１つ以上のプロセッサにアクセス可能なメモリとを含み得て、メモリは、命令を格納し、当該命令は、１つ以上のプロセッサによって実行されると、１つ以上のプロセッサに本明細書に記載されている１つ以上の方法または動作を実行させる。さらに他の実施例は、本明細書に記載されている方法および動作のための命令を利用または格納するシステムおよびマシン読取可能な有形の記憶媒体に関する。
【００１２】
少なくとも１つの実施例では、方法は、クラウドコンピュータシステムによって提供されるサービスに関連するメトリックの異常範囲を定義する一組の値を求めるステップを含む。上記サービスは、上記クラウドコンピュータシステム内のコンポーネントによって確立され得る。上記コンポーネントは、クラウドコンピュータ環境で実行される第１のコンテナおよび第２のコンテナを含み得る。上記第１のコンテナは、上記第２のコンテナにおける子コンテナであり得る。上記方法は、異常検出および解決コンポーネント（ＡＤＲＣ）を含むように上記第１のコンテナを構成するステップを含み得る。上記方法は、上記ＡＤＲＣによって、上記クラウドコンピュータシステム内での上記サービスのオペレーションに関連する異常の異常イベントを上記第１のコンテナにおいて検出するステップを含み得る。上記異常イベントは、上記メトリックの値が上記メトリックの上記異常範囲を満たさないことに基づいて検出され得る。上記方法は、上記第１のコンテナにおいて上記異常を解決するためのポリシーを特定するステップを含み得る。上記方法は、上記ポリシーにおけるルールが上記異常によって満たされることを判断するステップを含み得る。上記方法は、上記異常を解決するための修正アクションを起動するステップを含み得る。上記修正アクションは、上記ルールが満たされたことに基づいて上記ポリシーで特定され得る。
【００１３】
いくつかの実施例では、上記異常範囲は、ユーザ定義の異常について定義される固定された範囲である。上記一組の値は、ポーリング間隔値、上記メトリックの最小値尺度、上記メトリックのソフト限界、上記メトリックの最大値、および上記異常の最小発生回数を定義する最小連続読取値を含み得る。上記異常イベントを検出するステップは、上記メトリックの上記値が上記異常範囲を満たすか否かを判断するステップを含み得る。上記メトリックの上記値は、上記値が上記最小値尺度未満である場合および上記ソフト限界以上である場合には、上記異常範囲を満たし得ない。上記異常イベントは、上記最小連続読取値が満たされたことに基づいて検出され得る。
【００１４】
いくつかの実施例では、上記異常範囲は、ユーザ定義の異常について定義される周期的範囲である。上記一組の値は、ポーリング間隔値、上記メトリックの最小値尺度、上記メトリックのソフト限界、上記メトリックの最大値、上記異常の連続発生期間、上記周期的範囲が有効である開始時刻、および上記周期的範囲が有効である終了時刻を含み得る。上記異常イベントを検出するステップは、上記メトリックの上記値が上記異常範囲を満たすか否かを判断するステップを含み得る。上記メトリックの上記値は、上記値が上記最小値尺度未満である場合および上記ソフト限界以上である場合、上記異常イベントが上記期間中に検出され、上記開始時刻後であって上記終了時刻前に検出される場合には、上記異常範囲を満たし得ない。
【００１５】
少なくとも１つの実施例では、上記一組の値を求めるステップは、ログファイルの時系列データを分析して上記異常範囲について上記一組の値を計算するステップを含む。
【００１６】
いくつかの実施例では、上記方法は、上記第１のコンテナにおいて上記異常を解決するためのポリシーを特定できないと判断すると、上記第１のコンテナにおいて上記異常を解決できないことを上記第２のコンテナに通知するステップを含み得る。上記方法は、上記第２のコンテナにおいて上記異常を解決するためのポリシーを特定するステップを含み得る。上記方法は、上記第２のコンテナにおいて上記異常を解決するための上記ポリシーにおけるルールが上記異常によって満たされることを判断するステップを含み得る。上記方法は、上記ルールが満たされたことに基づいて、上記第２のコンテナにおいて上記異常を解決するための、上記ポリシーで特定される修正アクションを起動するステップを含み得る。
【００１７】
少なくとも１つの実施例では、上記サービスに関連する上記メトリックは、上記サービスを提供するためのサービス品質（ＱｏＳ）について監視される複数のメトリックのうちの１つである。
【００１８】
少なくとも１つの実施例では、方法は、クラウドコンピュータシステムによって提供されるサービスに関連するメトリックの異常範囲を定義する一組の値を求めるステップを含み得る。上記サービスは、上記クラウドコンピュータシステム内のコンポーネントによって確立され得る。上記コンポーネントは、クラウドコンピュータ環境で実行される第１のコンテナおよび第２のコンテナを含み得る。上記第１のコンテナは、上記第２のコンテナにおける子コンテナであり得る。上記方法は、第１の異常検出および解決コンポーネント（ＡＤＲＣ）を含むように上記第１のコンテナを構成するステップを含み得る。上記方法は、第２のＡＤＲＣを含むように上記第２のコンテナを構成するステップを含み得る。上記方法は、上記第１のＡＤＲＣによって、上記クラウドコンピュータシステム内での上記サービスのオペレーションに関連する異常の異常イベントを上記第１のコンテナにおいて検出するステップを含み得る。上記異常イベントは、上記メトリックの値が上記メトリックの上記異常範囲を満たさないことに基づいて検出される。上記方法は、上記第１のＡＤＲＣが上記第１のコンテナにおいて上記異常を解決するためのポリシーを有するか否かを判断するステップを含み得る。上記方法は、上記第１のＡＤＲＣが上記第１のコンテナにおいて上記異常を解決するためのポリシーを持たないと判断したことに基づいて、上記第１のコンテナにおいて上記異常を解決できないことを上記第２のコンテナに通知するステップを含み得る。上記方法は、上記第２のＡＤＲＣによって、上記第２のコンテナにおいて上記異常を解決するためのポリシーを上記ＡＤＲＣのために特定するステップを含み得る。上記方法は、上記第２のコンテナにおいて上記異常を解決するための上記ポリシーにおけるルールが上記異常によって満たされることを判断するステップを含み得る。上記方法は、上記ルールが満たされたことに基づいて、上記第２のコンテナにおいて上記異常を解決するための、上記ポリシーで特定される修正アクションを起動するステップを含み得る。
【００１９】
いくつかの実施例では、上記方法は、上記第２のＡＤＲＣが上記第２のコンテナにおいて上記異常を解決するためのポリシーを持たないと上記第２のＡＤＲＣによって判断したことに基づいて、上記異常を解決できなかったという警告を通信システムを用いて送信するステップを含み得る。
【００２０】
いくつかの実施例では、上記方法は、上記第２のＡＤＲＣが上記第２のコンテナにおいて上記異常を解決するためのポリシーを持たないと上記第２のＡＤＲＣによって判断したことに基づいて、上記異常を解決できないことを第３のコンテナに通知するステップを含み得て、上記第３のコンテナは、上記コンポーネントのうちの１つである。上記第３のコンテナは、上記第２のコンテナを含み得る。上記方法は、上記第３のコンテナ内に構成される第３のＡＤＲＣによって、上記第３のコンテナにおいて上記異常を解決するためのポリシーを特定するステップを含み得る。上記方法は、上記第３のコンテナにおいて上記異常を解決するための、上記ポリシーで特定される修正アクションを起動するステップを含み得る。
【００２１】
上記および下記の技術は、いくつかの方法およびいくつかの文脈で実現することができる。以下でより詳細に説明するように、以下の図面を参照して、いくつかの例示的な実現例および文脈を提供する。１つの特定の例示的な実現例は、非常に詳細に説明する自律型システムである。しかし、以下の実現例および文脈は、多くのうちの一部に過ぎない。
【図面の簡単な説明】
【００２２】
【図１】実施例に係るクラウドインフラストラクチャシステムの論理図である。
【図２】実施例に係るクラウドインフラストラクチャシステムの簡略ブロック図である。
【図３】いくつかの実施例に係るコンピューティングシステムにおいて異常を管理するための自律型システムの大まかな概要を示す。
【図４】いくつかの実施例に係るコンピューティングシステムのコンポーネントモデルを示す。
【図５】いくつかの実施例に係るコンポーネントモデルの要素間の関係を示す。
【図６】いくつかの実施例に係る異常検出および解決システム（ＡＤＲＳ）の異常検出および解決コンポーネント（ＡＤＲＣ）のブロック図を示す。
【図７】いくつかの実施例に係る異常検出および解決システム（ＡＤＲＳ）の異常検出および解決コンポーネント（ＡＤＲＣ）のブロック図を示す。
【図８】いくつかの実施例に係る階層型ＡＤＲＳで実現される自律型クラウドコンピューティングシステムの一例を示す。
【図９】いくつかの実施例に係る階層型異常分類構造を示す。
【図１０】いくつかの実施例に係る定義済みの異常の範囲を示すブロック図である。
【図１１】いくつかの実施例に係る自律型クラウドインフラストラクチャシステムにおいて実行されるオペレーションのブロック図を示す。
【図１２】いくつかの実施例に係るログファイルフローの大まかな図を示す。
【図１３】いくつかの実施例に係る異常検出および解決のためのプロセスのフローチャートを示す。
【図１４】いくつかの実施例に係る異常検出および解決のためのプロセスのフローチャートを示す。
【図１５】実施例を実現するための分散型システムの簡略図を示す。
【図１６】本開示の実施例に係る、サービスがクラウドサービスとして提供され得るシステム環境の１つ以上のコンポーネントの簡略ブロック図を示す。
【図１７】本発明の実施例を実現するために使用され得る例示的なコンピュータシステムを示す。
【図１８】本発明の実施例を実現するために使用され得るＡＤＲＳを示す。
【発明を実施するための形態】
【００２３】
発明の詳細な説明
以下の説明では、本発明の実施例が十分に理解されるようにするために、説明の目的で具体的詳細を記載する。しかし、これらの具体的詳細がなくてもさまざまな実施例を実施できることは明らかであろう。図面および説明は、限定的であるよう意図されるものではない。
【００２４】
特定の実施例では、クラウドインフラストラクチャシステムなどのコンピューティングシステムにおいて異常を自動的に検出して解決するための技術（たとえば、方法、システム、１つ以上のプロセッサによって実行可能なコードまたは命令を格納する非一時的なコンピュータ読取可能な媒体）を提供する。
【００２５】
Ｉ．クラウドインフラストラクチャシステム
図１は、一実施例に係るクラウドインフラストラクチャシステムの論理図である。クラウドインフラストラクチャシステムは、セルフサービスの、サブスクリプションベースの、弾性的にスケーラブルな、信頼性のある、高可用性の、安全な態様で顧客に与えられる一連のアプリケーション、ミドルウェアおよびデータベースサービス提供品へのアクセスを提供し得る。クラウドインフラストラクチャシステムは、オラクル（登録商標）社によって提供されるオラクルパブリッククラウドなどのパブリッククラウドのために実現され得る。
【００２６】
クラウドインフラストラクチャシステムは、クラウドインフラストラクチャシステムにおいてサービスおよびリソースについての顧客のサブスクリプションをプロビジョニング、管理および追跡する機能、クラウドインフラストラクチャシステムにおいてサービスを利用する顧客に予測可能な作業費用を提供する機能、クラウドインフラストラクチャシステムにおいて顧客のデータのロバストなアイデンティティドメインの分離および保護を提供する機能、クラウドインフラストラクチャシステムの設計の透過的なアーキテクチャおよび制御を顧客に提供する機能、データ保護の保証とデータプライバシ基準および規制の順守とを顧客に提供する機能、クラウドインフラストラクチャシステムにおいてサービスを構築およびデプロイするための統合された開発経験を顧客に提供する機能、ならびにクラウドインフラストラクチャシステムにおいてビジネスソフトウェア、ミドルウェア、データベースおよびインフラストラクチャサービスの間のシームレスな統合を顧客に提供する機能を含むがこれらに限定されない多くの機能を提供することができる。
【００２７】
特定の実施例では、クラウドインフラストラクチャシステムによって提供されるサービスは、オンラインデータストレージおよびバックアップソリューション、ウェブベースの電子メールサービス、ホスト型オフィススイートおよび文書コラボレーションサービス、データベース処理、管理された技術サポートサービスなどの、クラウドインフラストラクチャシステムのユーザがオンデマンドで利用可能な多数のサービスを含み得る。クラウドインフラストラクチャシステムによって提供されるサービスは、そのユーザのニーズを満たすように動的にスケーリング可能である。クラウドインフラストラクチャシステムによって提供されるサービスの具体的なインスタンス化は、本明細書ではサービスインスタンスと称される。一般に、クラウドサービスプロバイダのシステムからインターネットなどの通信ネットワークを介してユーザが利用可能なサービスはいずれも、クラウドサービスと称される。一般に、パブリッククラウド環境では、クラウドサービスプロバイダのシステムを構成するサーバおよびシステムは、顧客自身のオンプレミスサーバおよびシステムとは異なっている。たとえば、クラウドサービスプロバイダのシステムは、アプリケーションをホストし得て、ユーザは、インターネットなどの通信ネットワークを介してオンデマンドで当該アプリケーションをオーダーし、使用し得る。
【００２８】
コンピュータネットワーククラウドインフラストラクチャにおけるサービスは、クラウドベンダによってユーザに提供されるかまたはそうでなければ当該技術分野において公知のストレージ、ホスト型データベース、ホスト型ウェブサーバ、ソフトウェアアプリケーションまたは他のサービスへの保護されたコンピュータネットワークアクセスを含む。たとえば、サービスは、インターネットを介したクラウド上のリモートストレージへの、パスワードによって保護されたアクセスを含んでいてもよい。別の例として、サービスは、ネットワーク化された開発者による私的使用のためのウェブサービスベースのホスト型リレーショナルデータベースおよびスクリプト言語ミドルウェアエンジンを含んでいてもよい。別の例として、サービスは、クラウドベンダのウェブサイト上でホストされる電子メールソフトウェアアプリケーションへのアクセスを含んでいてもよい。
【００２９】
図１では、クラウドインフラストラクチャシステム１００は、クラウドまたはネットワーク化された環境を介してさまざまなサービスを提供し得る。これらのサービスは、ソフトウェア・アズ・ア・サービス（Software as a Service：ＳａａＳ）カテゴリ、プラットフォーム・アズ・ア・サービス（Platform as a Service：ＰａａＳ）カテゴリ、インフラストラクチャ・アズ・ア・サービス（Infrastructure as a Service：ＩａａＳ）カテゴリ、またはハイブリッドサービスを含むサービスの他のカテゴリの下で提供される１つ以上のサービスを含んでいてもよい。顧客は、サブスクリプションオーダーを介して、クラウドインフラストラクチャシステム１００によって提供される１つ以上のサービスをオーダーし得る。次いで、クラウドインフラストラクチャシステム１００は、顧客のサブスクリプションオーダーにおけるサービスを提供するために処理を実行する。
【００３０】
クラウドインフラストラクチャシステム１００は、さまざまなデプロイメントモデルを介してクラウドサービスを提供し得る。たとえば、サービスは、クラウドインフラストラクチャシステム１００が（たとえばオラクル（登録商標）社によって所有される）クラウドサービスを販売する組織によって所有され、サービスが一般的な公営企業またはさまざまな産業企業が利用可能であるパブリッククラウドモデルの下で提供されてもよい。別の例として、サービスは、クラウドインフラストラクチャシステム１００が単一の組織のために単独で運営され、当該組織内の１つ以上のエンティティにサービスを提供することができるプライベートクラウドモデルの下で提供されてもよい。また、クラウドサービスは、クラウドインフラストラクチャシステム１００およびシステム１００によって提供されるサービスが関連のコミュニティの中のいくつかの組織によって共有されるコミュニティクラウドモデルの下で提供されてもよい。また、クラウドサービスは、２つ以上の異なるモデルの組み合わせであるハイブリッドクラウドモデルの下で提供されてもよい。
【００３１】
図１に示されるように、クラウドインフラストラクチャシステム１００は、クラウドインフラストラクチャシステム１００によって提供されるサービスのプロビジョニングを可能にする、連携して動作する複数のコンポーネントを備えていてもよい。図１に示される実施例では、クラウドインフラストラクチャシステム１００は、ＳａａＳプラットフォーム１０２と、ＰａａＳプラットフォーム１０４と、ＩａａＳプラットフォーム１１０と、インフラストラクチャリソース１０６と、クラウド管理機能１０８とを含む。これらのコンポーネントは、ハードウェアまたはソフトウェアまたはそれらの組み合わせで実現されてもよい。
【００３２】
ＳａａＳプラットフォーム１０２は、ＳａａＳカテゴリに入るクラウドサービスを提供するように構成される。たとえば、ＳａａＳプラットフォーム１０２は、統合された開発およびデプロイメントプラットフォーム上で一連のオンデマンドのアプリケーションを構築および供給するための機能を提供し得る。ＳａａＳプラットフォーム１０２は、ＳａａＳサービスを提供するための基本的なソフトウェアおよびインフラストラクチャを管理および制御し得る。ＳａａＳプラットフォーム１０２によって提供されるサービスを利用することによって、顧客は、クラウドインフラストラクチャシステム１００上で実行されるアプリケーションを利用することができる。顧客は、顧客が別個のライセンスおよびサポートを購入する必要なくアプリケーションサービスを取得することができる。
【００３３】
さまざまな異なるＳａａＳサービスが提供され得る。例としては、大きな組織に販売実績管理、企業統合およびビジネスの柔軟性などのためのソリューションを提供するサービスが挙げられるが、これに限定されるものではない。一実施例では、ＳａａＳサービスは、顧客関係管理（Customer Relationship Management：ＣＲＭ）サービス１１０（たとえばオラクルクラウドによって提供されるフュージョンＣＲＭサービス）、人材管理（Human Capital Management：ＨＣＭ）／才能管理サービス１１２などを含んでいてもよい。ＣＲＭサービス１１０は、顧客への販売活動サイクルの報告および管理に向けられるサービスなどを含んでいてもよい。ＨＣＭ／才能サービス１１２は、顧客へのグローバルな労働力ライフサイクル管理および才能管理サービスの提供に向けられるサービスを含んでいてもよい。
【００３４】
標準化された、共有の、弾性的にスケーラブルなアプリケーション開発およびデプロイメントプラットフォームにおけるＰａａＳプラットフォーム１０４によって、さまざまな異なるＰａａＳサービスが提供され得る。ＰａａＳサービスの例としては、共有される共通のアーキテクチャ上で既存のアプリケーションを（オラクルなどの）組織が集約することを可能にするサービス、および、プラットフォームによって提供される共有のサービスを活用する新たなアプリケーションを構築する機能が挙げられ得るが、これらに限定されるものではない。ＰａａＳプラットフォーム１０４は、ＰａａＳサービスを提供するための基本的なソフトウェアおよびインフラストラクチャを管理および制御し得る。顧客は、顧客が別個のライセンスおよびサポートを購入する必要なく、クラウドインフラストラクチャシステム１００によって提供されるＰａａＳサービスを取得することができる。ＰａａＳサービスの例としては、オラクルＪａｖａ（登録商標）クラウドサービス（Java Cloud Service：ＪＣＳ）、オラクルデータベースクラウドサービス（Oracle Database Cloud Service：ＤＢＣＳ）などが挙げられるが、これらに限定されるものではない。
【００３５】
ＰａａＳプラットフォーム１０４によって提供されるサービスを利用することによって、顧客は、クラウドインフラストラクチャシステム１００によってサポートされるプログラミング言語およびツールを利用することができ、デプロイされたサービスを制御することもできる。いくつかの実施例では、クラウドインフラストラクチャシステム１００によって提供されるＰａａＳサービスは、データベースクラウドサービス１１４と、ミドルウェアクラウドサービス（たとえばオラクルフュージョンミドルウェアサービス）１１６と、Ｊａｖａクラウドサービス１１７とを含んでいてもよい。一実施例では、データベースクラウドサービス１１４は、組織がデータベースリソースをプールし、データベースクラウドの形態でデータベース・アズ・ア・サービスを顧客に提供することを可能にする共有のサービスデプロイメントモデルをサポートし得て、ミドルウェアクラウドサービス１１６は、さまざまなビジネスアプリケーションを開発およびデプロイするために顧客にプラットフォームを提供し、Ｊａｖａクラウドサービス１１７は、クラウドインフラストラクチャシステム１００においてＪａｖａアプリケーションをデプロイするために顧客にプラットフォームを提供する。図１に示されるＳａａＳプラットフォーム１０２およびＰａａＳプラットフォーム１０４におけるコンポーネントは、単に例示の目的で示されており、本発明の実施例の範囲を限定することを意図したものではない。代替的な実施例では、ＳａａＳプラットフォーム１０２およびＰａａＳプラットフォーム１０４は、クラウドインフラストラクチャシステム１００の顧客に追加のサービスを提供するための追加のコンポーネントを含んでいてもよい。
【００３６】
ＩａａＳプラットフォーム１１０によってさまざまな異なるＩａａＳサービスが提供され得る。ＩａａＳサービスは、ＳａａＳプラットフォームおよびＰａａＳプラットフォームによって提供されるサービスを利用する顧客のために、ストレージ、ネットワークおよび他の基礎的な計算リソースなどの基本的な計算リソースの管理および制御を容易にする。
【００３７】
特定の実施例では、クラウドインフラストラクチャシステム１００は、クラウドインフラストラクチャシステム１００の顧客にさまざまなサービスを提供するために使用されるリソースを提供するためのインフラストラクチャリソース１０６を含む。一実施例では、インフラストラクチャリソース１０６は、ＰａａＳプラットフォームおよびＳａａＳプラットフォームによって提供されるサービスを実行するために、サーバ、ストレージおよびネットワーキングリソースなどのハードウェアの予め統合された、最適化された組み合わせを含む。
【００３８】
特定の実施例では、クラウド管理機能１０８は、クラウドインフラストラクチャシステム１００においてクラウドサービス（たとえばＳａａＳ、ＰａａＳ、ＩａａＳサービス）の包括的な管理を提供する。一実施例では、クラウド管理機能１０８は、クラウドインフラストラクチャシステム１００によって受取られた顧客のサブスクリプションをプロビジョニング、管理および追跡するための機能などを含む。
【００３９】
図２は、実施例に係るクラウドインフラストラクチャシステム１００の簡略ブロック図である。図２に示される実現例は、図２に示されるもの以外の他のコンポーネントを有していてもよいということが理解されるべきである。さらに、図２に示される実施例は、本発明の実施例を組込むことができるクラウドインフラストラクチャシステムの一例に過ぎない。いくつかの他の実施例では、クラウドインフラストラクチャシステム１００は、図２に示されるものよりも多くのまたは少ないコンポーネントを有していてもよく、２つ以上のコンポーネントを組み合わせてもよく、またはコンポーネントの異なる構成もしくは配置を有していてもよい。特定の実施例では、最適な性能を提供する垂直統合を提供するようにハードウェアおよびソフトウェアコンポーネントが積層される。
【００４０】
さまざまなタイプのユーザがクラウドインフラストラクチャシステム１００と対話し得る。これらのユーザは、たとえば、デスクトップ、モバイル機器、タブレットなどのさまざまなクライアント装置を使用してクラウドインフラストラクチャシステム１００と対話し得るエンドユーザ１５０を含んでいてもよい。また、ユーザは、さまざまな統合された開発環境（integrated development environment：ＩＤＥ）を介して、および他のアプリケーションを介して、コマンドラインインターフェース（command line interface：ＣＬＩ）、アプリケーションプログラミングインターフェース（application programming interface：ＡＰＩ）を使用してクラウドインフラストラクチャシステム１００と対話し得る開発者／プログラマ１５２を含んでいてもよい。また、ユーザは、オペレーションスタッフ１５４を含んでいてもよい。これらは、クラウドサービスプロバイダのスタッフまたは他のユーザのスタッフを含んでいてもよい。
【００４１】
アプリケーションサービス層１５６は、クラウドインフラストラクチャシステム１００によって提供され得るさまざまなクラウドサービスを特定する。これらのサービスは、サービス統合および連結層１５８を介してそれぞれのソフトウェアコンポーネント１６０（たとえばＪａｖａサービスを提供するためのオラクルウェブロジックサーバ、データベースサービスを提供するためのオラクルデータベースなど）にマッピングされるか、または関連付けられ得る。
【００４２】
特定の実施例では、クラウドインフラストラクチャシステム１００のさまざまなコンポーネントまたはモジュールおよびクラウドインフラストラクチャシステム１００によって提供されるサービスによって共有されるいくつかの内部サービス１６２が提供され得る。これらの内部共有サービスは、セキュリティおよびアイデンティティサービス、統合サービス、エンタープライズリポジトリサービス、エンタープライズマネージャサービス、ウイルススキャンおよびホワイトリストサービス、高可用性、バックアップおよび回復サービス、ＩＤＥにおいてクラウドサポートを可能にするためのサービス、電子メールサービス、通知サービス、ファイル転送サービスなどを含み得るが、これらに限定されるものではない。
【００４３】
ランタイムインフラストラクチャ層１６４は、さまざまな他の層およびコンポーネントが構築されるハードウェア層を表わす。特定の実施例では、ランタイムインフラストラクチャ層１６４は、ストレージ、処理およびネットワーキングリソースを提供するための１つのオラクルのExadataマシンを備えていてもよい。Exadataマシンは、さまざまなデータベースサーバ、ストレージサーバ、ネットワーキングリソース、およびクラウドサービス関連のソフトウェア層をホストするための他のコンポーネントから構成され得る。特定の実施例では、Exadataマシンは、ストレージ、計算、ネットワークおよびソフトウェアリソースの集合体を提供するエンジニアド・システムであるOracle Exalogicと連携するように設計され得る。ExadataおよびExalogicの組み合わせは、クラウドサービスを提供するための高性能で、高可用性で、スケーラブルで、安全な、管理されたプラットフォームを与える完全なハードウェアおよびソフトウェアエンジニアドソリューションを提供する。
【００４４】
ＩＩ．異常検出および解決システムの大まかな概要
図３は、クラウドインフラストラクチャシステム３００などのコンピューティングシステムにおいて異常を管理するための自律型システム３００の大まかな概要を示す。下記の技術のうちの１つ以上は、１つ以上のコンピュータシステムにおいて実現されてもよく、または１つ以上のコンピュータシステムを含んでいてもよい。
【００４５】
システム３００は、クライアントシステム３０２，クライアントシステム３０４...クライアントシステム３０８（総称して「クライアントシステム」または「クライアント」３１０）と、自律型システムコンポーネント（autonomic system component：ＡＳＣ）３１８と、図１および図２のクラウドインフラストラクチャシステム１００と、異常検出および解決システム（ＡＤＲＳ）３２０とを含み得る。ＡＳＣ３１８は、クラウドインフラストラクチャシステム１００のクラウド管理機能１０８に含まれ得る。クライアントシステム３１０は、クラウドインフラストラクチャシステム１００によって提供されるサービスにアクセスするために１人以上のユーザによって操作され得る。クライアントシステム３１０およびクラウドインフラストラクチャシステム１００は、１つ以上の通信ネットワーク３３０を介して通信可能に接続され得る。通信ネットワークの例としては、インターネット、広域ネットワーク（wide area network：ＷＡＮ）、ローカルエリアネットワーク（local area network：ＬＡＮ）、イーサネット（登録商標）ネットワーク、パブリックまたはプライベートネットワーク、有線ネットワーク、無線ネットワークなど、およびそれらの組み合わせが挙げられるが、これらに限定されるものではない。さまざまな通信プロトコルを使用して、ＩＥＥＥ  ８０２．ＸＸのプロトコル一式、ＴＣＰ／ＩＰ、ＩＰＸ、ＳＡＮ、ＡｐｐｌｅＴａｌｋ、ブルートゥース（登録商標）および他のプロトコルなどの有線プロトコルも無線プロトコルも含む通信を容易にすることができる。
【００４６】
いくつかの実施例では、クラウドインフラストラクチャシステム１００などのコンピューティングシステムは、システムを動作させるための１つ以上のコンポーネント、多くの場合多くのコンポーネント、で実現され得る。コンポーネントのうちの全てまたはいくつかは関係付けられ得る。コンポーネントは、図４および図５を参照して説明するコンポーネントモデルなどのコンポーネントモデルに基づいて定義され得る。以下でさらに説明するように、コンポーネントは、物理的コンポーネント（たとえば、物理マシン、ネットワークスイッチおよびストレージデバイス）、仮想コンポーネント（たとえば、計算仮想マシン、Ｊａｖａ仮想マシン（Java Virtual Machine：ＪＶＭ）および仮想ネットワークインターフェイスコントローラ（network interface controller：ＮＩＣ））、およびソフトウェアコンポーネント（たとえば、オペレーティングシステムおよびアプリケーション）を含み得る。
【００４７】
図３の例では、クラウドインフラストラクチャシステム１００は、１つ以上のコンポーネントを含む。たとえば、クラウドインフラストラクチャシステム１００は、１つ以上のコンテナを含む。コンテナ（たとえば、サービスコンテナ）は、特別なタイプのコンポーネントである。コンテナは、そこで実行されるコンポーネントにリソースを提供することができ、またはコンテナは、コンポーネントに含まれていてもよい。コンテナは、実行されるコンポーネントに名前空間およびリソースプール（resource pool：ＲＰ）を提供することができる。コンテナは、リソースプールを有し、当該コンテナで実行される他のコンポーネントのための環境を提供するコンポーネントであり得る。クラウドインフラストラクチャシステム１００は、コンテナ名前空間を提供するコンテナ３５０などのコンポーネントを含む。コンテナ３５０は、コンテナ３６０（「コンテナ名前空間」）、コンテナ３７０（「コンテナ名前空間」）および１つ以上の異常検出および解決コンポーネント（ＡＤＲＣ）（たとえば、ＡＤＲＣ３５４）などの、コンテナ３５０内に埋め込まれた複数のコンポーネントを含み得る。ＡＤＲＣ３５４は、環境レベルのＡＤＲＣであってもよい。ＡＤＲＣについては以下でさらに説明する。たとえば、ＪＶＭは、コンテナであるＶＭ内で実行されている埋め込みコンテナであってもよい。コンポーネントは、１つのコンポーネントが複数の埋め込みコンポーネントを有することができ、当該複数の埋め込みコンポーネントが複数のコンポーネントをさらに有することができるような階層型の態様で実現され得る。コンポーネントは、複数レベルの階層で定義され得て、各レベルは、当該階層の別のレベルに複数のコンポーネントを有する１つのコンポーネントに対応する。
【００４８】
コンテナ３５０は、コンテナ３５０に埋め込まれたコンテナにリソースを提供するためにリソースプール（ＲＰ）３５２を含み得る。一般に、本開示では、リソースは、ハードウェアリソース、ソフトウェアリソース、ファームウェアリソース、またはそれらの組み合わせを含み得る。たとえば、ＲＰは、ＣＰＵ、メモリ、ストレージ、ＩＯ帯域幅、ネットワーク帯域幅などの一組のリソースを含んでいてもよい。ＲＰは、ＲＵがそこからリソースを入手してそこにリソースを戻すことを可能にし得る。いくつかの実施例では、ＲＰは、実行時にリソースを増加または減少させることができるようにダイナミックリソースプール（dynamic resource pool：ＤＲＰ）であってもよい。ＤＲＰは、実行中に個別にリソースを提供するように動的であってもよく、または実行中にコンテナと共有されてもよい。ＲＰは、１つ以上のリソースプロバイダを含んでいてもよく、または１つ以上のリソースプロバイダによってサポートされてもよい。いくつかの実施例では、コンテナは、リソースを提供するリソースプロバイダを含み得る。
【００４９】
コンテナ３５０などのコンポーネントは、少なくとも１人のリソースユーザ（resource user：ＲＵ）を含み得る。ＲＵは、コンテナを動作させるスレッドまたはプロセスを含み得る。別のコンポーネント（たとえば、コンテナ）内のコンポーネントがＲＵと考えられてもよい。システム３００における例では、コンテナ３５０は、各々がＲＵであるコンテナ３６０および３７０などの１つ以上のコンポーネントを含み得る。たとえば、コンテナ３６０およびコンテナ３７０は、物理マシンであるコンテナ３５０のための仮想マシンであってもよい。ＲＰ３５２は、コンテナ３５０内のコンテナ３６０，３７０にリソースを提供し得る。コンポーネントは、別のコンポーネント内のリソースプロバイダであってもよい。たとえば、Ｊａｖａ仮想マシン（ＪＶＭ）は、オペレーティングシステムリソースのユーザであり、そこで実行されるＪａｖａアプリケーションに対するリソースのプロバイダである。したがって、ＪＶＭは、別のコンテナ内に組み込まれたコンテナであってもよい。コンテナが利用できるリソースは、当該コンテナが特定の量のリソースを保証されるが過剰なリソースを使用することになってしまわないように制約される（制限される）可能性がある。各々の組み込まれたコンテナ３６０およびコンテナ３７０は、リソースプール３６２およびリソースプール３７２をそれぞれ含み得る。
【００５０】
ＡＤＲＳ３２０は、クラウドインフラストラクチャシステム１００において実行される処理の中で異常を監視して、異常を解決するためのアクションを講じ得る。特に、ＡＤＲＳは、クライアントシステム３１０に提供されるサービスにおける異常を検出して解決し得る。ＡＤＲＳ３２０は、ＡＳＣ３１８のコンポーネントであってもよい。ＡＳＣ３１８はクラウドインフラストラクチャシステム１００とは別個であるものとして示されているが、ＡＤＲＳ３２０は、図１のクラウド管理機能１０８などのクラウドインフラストラクチャシステム１００に含まれてもよく、またはクラウドインフラストラクチャシステム１００と一体化されてもよい。ＡＳＣ３１８は、クラウドインフラストラクチャシステム１００の外側にあってもよく、ネットワーク３３０を介してクラウドインフラストラクチャシステム１００に通信可能に結合されてもよい。ＡＳＣ３１８は、本明細書に開示されているオペレーションを、異常の管理、検出および解決のために実行されるものとして実行し得る。
【００５１】
ＡＤＲＳ３２０は、１つ以上のコンピュータおよび／またはサーバを備え得るコンピュータシステムを使用して実現されてもよく、当該１つ以上のコンピュータおよび／またはサーバは、汎用コンピュータ、（一例として、ＰＣサーバ、ＵＮＩＸ（登録商標）サーバ、ミッドレンジサーバ、メインフレームコンピュータ、ラックマウント型サーバなどを含む）専用のサーバコンピュータ、サーバファーム、サーバクラスタ、分散型サーバ、またはそれらのその他の適切な配置および／もしくは組み合わせであってもよい。たとえば、ＡＤＲＳ３２０は、本開示の実施例に従って本明細書に記載されている処理を実行するためのコンピュータシステムに対応し得る。ＡＤＲＳ３２０を構成するコンピューティングシステムは、ＨＴＴＰサーバ、ＦＴＰサーバ、ＣＧＩサーバ、Ｊａｖａサーバ、データベースサーバなどを含む、任意の数のオペレーティングシステムまたはさまざまなさらなるサーバアプリケーションおよび／もしくは中間層アプリケーションを実行し得る。例示的なデータベースサーバは、マイクロソフト社から市場で入手可能なものなどを含むが、それらの限定されるものではない。一例では、ＡＤＲＳ３２０は、オラクル（登録商標）社によって提供されるオラクルパブリッククラウドなどの、クラウドインフラストラクチャシステム１００によって提供されるサービスに含まれてもよく、または当該サービスとして実現されてもよい。さまざまな実施例では、ＡＤＲＳ３２０は、上記の開示に記載されている１つ以上のサービスまたはソフトウェアアプリケーションを実行するように構成され得る。
【００５２】
いくつかの実施例では、ＡＳＣ３１８は、上記のものを含み得る１つ以上のコンピュータおよび／またはサーバを備えたエンタープライズコンピューティングシステムまたはクラウドコンピューティングシステムとして実現されてもよい。ＡＳＣ３１８は、いくつかのサブシステムおよび／またはモジュールを含み得て、いくつかは図示されていないかもしれない。たとえば、ＡＳＣ３１８は、ＡＤＲＳ３２０と、サービス作成およびデプロイメント管理システム（service creation and deployment management system：ＳＣＤＭＳ）３２２と、構造および構成管理システム（composition and configuration management system：ＣＣＭＳ）３２４と、ログリザーバおよび分析システム（log reservoir and analytics system：ＬＲＡＳ）３２８とを含み得る。ＡＤＲＳ３２０は、ＳＣＤＭＳ３２０、ＣＣＭＳ３２４およびＬＲＡＳ３２６とともに使用され得る。ＡＳＣ３１８は、１つ以上のＡＤＲＣで実現されてもよく、または１つ以上のＡＤＲＣを使用して動作してもよい。さらに以下で説明するように、ＡＳＣ３１８は、クラウドインフラストラクチャシステム１００における（たとえば、組み込まれる）１つ以上のサブシステムおよび／またはモジュールを含んでいてもよく、または当該１つ以上のサブシステムおよび／またはモジュールで実現されてもよい。ＡＤＲＣは、クラウドインフラストラクチャシステム１００におけるサブシステムおよび／またはモジュールであってもよい。ＡＤＲＣは、１つ以上のサブシステムおよび／またはモジュールを有するコンピューティングシステムであってもよい。ＡＳＣ３１８は、図に示されているよりも多くのサブシステムおよび／またはモジュールを有していてもよく、または図に示されているよりも少ないサブシステムおよび／またはモジュールを有していてもよく、２つ以上のサブシステムおよび／またはモジュールを組み合わせてもよく、またはサブシステムおよび／またはモジュールの異なる構成または配置を有していてもよい。ＡＳＣ３１８のサブシステムおよびモジュールは、ソフトウェア（たとえば、プロセッサによって実行可能なプログラムコード、命令）、ファームウェア、ハードウェア、またはそれらの組み合わせで実現されてもよい。いくつかの実施例では、ソフトウェアは、メモリ（たとえば、非一時的なコンピュータ読取可能な媒体）内、メモリデバイス上、または何らかの他の物理メモリ上に格納されてもよく、１つ以上の処理ユニット（たとえば、１つ以上のプロセッサ、１つ以上のプロセッサコア、１つ以上のＧＰＵなど）によって実行されてもよい。
【００５３】
特定の実施例では、ＡＳＣ３１８は、他のサービスも提供し得て、または、ソフトウェアアプリケーションは、非仮想環境および仮想環境を含み得る。いくつかの実施例では、これらのサービスは、ウェブベースのサービスもしくはクラウドサービスとして、またはソフトウェア・アズ・ア・サービス（ＳａａＳ）モデルの下で、クライアントシステム３１０のユーザに提供され得る。たとえば、ＡＳＣ３１８のＡＤＲＳ３２０は、クラウドインフラストラクチャシステム１００において異常を検出して解決し得る。ＡＳＣ３１８によって提供されるサービスは、アプリケーションサービスを含み得る。アプリケーションサービスは、ＳａａＳプラットフォームを介してＡＳＣ３１８によって提供され得る。ＳａａＳプラットフォームは、ＳａａＳカテゴリに該当するサービスを提供するように構成され得る。ＳａａＳプラットフォームは、ＳａａＳサービスを提供するための基本的なソフトウェアおよびインフラストラクチャを管理して制御し得る。ＳａａＳプラットフォームによって提供されるサービスを利用することによって、顧客は、クラウドインフラストラクチャシステムとして実現され得る、ＡＳＣ３１８で実行されるアプリケーションを利用することができる。ユーザは、別個のライセンスおよびサポートを購入する必要なくアプリケーションサービスを取得することができる。さまざまな異なるＳａａＳサービスが提供されてもよい。そして、クライアントシステム３１０を操作するユーザは、１つ以上のアプリケーションを利用して、ＡＳＣ３１８と対話して、ＡＳＣ３１８のサブシステムおよび／またはモジュールによって提供されるサービスを利用し得る。
【００５４】
ＡＳＣ３１８は、少なくとも１つのメモリと、１つ以上の処理ユニット（またはプロセッサ）と、ストレージとを含み得る。処理ユニットは、適宜、ハードウェア、コンピュータによって実行可能な命令、ファームウェア、またはそれらの組み合わせで実現されてもよい。処理ユニットのコンピュータによって実行可能な命令またはファームウェアの実現例は、本明細書に記載されているさまざまなオペレーション、機能、方法および／またはプロセスを実行するように任意の好適なプログラミング言語で書き込まれるコンピュータによって実行可能なまたはマシンによって実行可能な命令を含み得る。ＡＳＣ３１８におけるメモリは、処理ユニットでロード可能および実行可能なプログラム命令と、これらのプログラムの実行中に生成されるデータとを格納し得る。メモリは、揮発性（ランダムアクセスメモリ（random access memory：ＲＡＭ）など）であってもよく、および／または、不揮発性（リードオンリメモリ（read-only memory：ＲＯＭ）、フラッシュメモリなど）であってもよい。メモリは、コンピュータ読取可能な記憶媒体などのいずれかのタイプの永久的ストレージデバイスを使用して実現されてもよい。いくつかの実施例では、コンピュータ読取可能な記憶媒体は、悪質なコードを含む電子通信からコンピュータを保護するように構成され得る。コンピュータ読取可能な記憶媒体は、プロセッサで実行されたときに本明細書に記載されているオペレーションを実行する命令を格納し得る。
【００５５】
ＡＳＣ３１８は、ストレージも含んでいてもよく、またはストレージに結合されていてもよく、当該ストレージは、メモリストレージデバイスまたは他の非一時的なコンピュータ読取可能な記憶媒体などのいずれかのタイプの永久的ストレージデバイスを使用して実現されてもよい。いくつかの実施例では、ローカルストレージは、１つ以上のデータベース（たとえば、ドキュメントデータベース、リレーショナルデータベースまたは他のタイプのデータベース）、１つ以上のファイルストア、１つ以上のファイルシステム、またはそれらの組み合わせを含み得る、または実現し得る。たとえば、ＡＳＣ３１８は、１つ以上のデータストアに結合されてもよく、または１つ以上のデータストアを含んでいてもよい。メモリおよびさらなるストレージは全て、コンピュータ読取可能な記憶媒体の例である。たとえば、コンピュータ読取可能な記憶媒体は、コンピュータ読取可能な命令、データ構造、プログラムモジュールまたは他のデータなどの情報の格納のためのいずれかの方法または技術で実現される揮発性または不揮発性のリムーバブルまたは非リムーバブルメディアを含み得る。データストアは、ネットワーク３３０を介してアクセス可能であり得る。本明細書に開示されている技術に従ってデータを格納するためにより多くのデータストアが実現されてもよく、またはより少ないデータストアが実現されてもよい。
【００５６】
ＡＳＣ３１８は、エンタープライズコンピューティングシステムまたはクラウドシステム（たとえば、クラウドインフラストラクチャシステム１００）などのコンピューティングシステムのために実現されて、コンピューティングシステムが自律的に動作することを可能にし得る。例示の目的で、ＡＳＣ３１８は、クラウドインフラストラクチャシステム１００での実現の一例として示されている。このような実現例は、コンピューティングシステムのオペレーションに対するメリットおよび改善点を示すように図示されている。しかし、クラウドシステムに関して図に示されている実施例は、クラウドシステムに限定されるよう意図されるものではなく、多くの異なるタイプのコンピューティングシステムで実現されてもよい。ＡＳＣ３１８は、コンピューティングシステムの性能における異常を自動的に検出して、軽減とまではいかなくても解決するためのアクションを講じることができる。異常の例としては、応答時間異常、負荷異常、リソース使用異常、コンポーネント障害異常、および停止異常を挙げることができる。さまざまなタイプの異常については、図９および図１０を参照してさらに説明する。
【００５７】
クラウドインフラストラクチャシステム１００で発生する多くの異常は、負荷スパイク、コンポーネント障害および／またはシステムの悪意ある使用を含む要因によって引き起こされる可能性があり、それらの異常は、リソース使用の増加、重要業績指標（ＫＰＩ）の悪化、および１つ以上のコンテナでのエラーのスパイクという形で顕在化する。クラウドインフラストラクチャシステム１００にサービスをデプロイする開発チーム、製品マネージャ、ビジネス開発マネージャおよびシステム管理者は、一組のイベント−条件−アクション（event-condition-action：：ＥＣＡ）ルールを思い付き、時間をかけてそれらを改良して、異常をプログラム的に解決できるように各サービスについてのこれらの一時的な異常に対処することができる。異常が長期間にわたって持続する場合、それは新たな常態であると考えなければならないかもしれず、サービスについてのリソース割り当てポリシーを再評価しなければならないかもしれない。異常に対する修正アクションは、いくつか例を挙げると、より多くのサーバをスピンアップすること、サービス要求到着率を抑制すること、いくつかのスレッドまたはプロセスを中止すること、および、リソースを使用していないサービスから臨時にそれらを必要とするサービスにリソースを動的に再割り当てすることを含む。
【００５８】
ＡＤＲＳ３２０は、異常の分類システム（「異常分類システム」）ならびに階層型のルールベースの異常検出および解決技術に基づいて異常を検出して解決することができる。ＡＤＲＳ異常分類については、図９および図１０を参照してさらに説明する。異常は、定義済みの異常および未定義の異常などの１つ以上のカテゴリに分類され得る。異常は、クラウドインフラストラクチャシステム１００の性能基準を維持するようにＡＤＲＳ３２０によって監視され解決され得る。性能基準は、１つ以上のシステムメトリックに基づいて定義することができる。たとえば、性能基準は、クラウドインフラストラクチャシステム１００によって提供されるサービスについての１つ以上のサービス品質（ＱｏＳ）属性に基づいて定義されてもよい。ＱｏＳ属性は、サービスレベル合意（ＳＬＡ）などのサービスについての合意によってまたは当該合意のために定義され得る。異常は、クラウドインフラストラクチャシステム１００などの、監視されているシステムの管理者によって定義され得る。異常は、管理者によって定義され得る１つ以上のユーザ定義のシステムメトリックに基づいて定義され得る。ユーザ定義のシステムメトリックは、リソース使用、負荷スパイク、悪意ある使用およびコンポーネント障害を含み得る。
【００５９】
１つ以上のＡＤＲＣは、クラウドインフラストラクチャシステムの外側で実現されてもよく、クラウドインフラストラクチャシステム１００内で実現されてもよく、またはそれらの組み合わせで実現されてもよい。ＡＤＲＣは、ＡＤＲＳ３２０のために実現され得る。異常を検出して、問題を軽減するためのアクションを直ちに講じるために、１つ以上のＡＤＲＣは、クラウドインフラストラクチャシステム１００内の１つ以上のコンポーネントに挿入され得る。たとえば、ＡＤＲＣは、各々の組み込まれたコンテナを含むコンテナ３５０，３６０，３７０の各々などのクラウドインフラストラクチャシステム１００の各コンポーネントにおいて実現されてもよい。コンテナ３６０，３７０における各コンポーネントは、専用のＡＤＲＣを含み得る。ＡＤＲＣは、クラウド環境レベルでクラウドインフラストラクチャシステム１００において実現され得る。たとえば、ＡＤＲＣは、クラウドインフラストラクチャシステム１００における各コンポーネントに加えて、クラウドインフラストラクチャシステム１００全体（たとえば、クラウド環境レベル）のために実現されてもよい。ＡＳＣ３１８は、ＡＤＲＣを含み得て、またはクラウドインフラストラクチャシステム１００のためのクラウド環境レベルでのＡＤＲＣとして動作し得る。クラウドインフラストラクチャシステム１００におけるＡＤＲＣはいずれも、それ自体で、ＡＤＲＳ３２０からの制御によって、またはそれらの組み合わせで実行されるように実現され得る。図５〜図７でさらに説明するように、ＡＤＲＣは、異常の検出および解決をコンポーネントレベルで支援するために複数のコンポーネントを含み得る。
【００６０】
コンポーネント内のＡＤＲＣは、実行されているプロセス中に発生するイベントの異常を検出することができる。当該プロセスは、クライアントシステムに提供されているサービスの一部であってもよい。ＡＤＲＣは、異常検出器を利用して、ＡＤＲＳ３２０について定義される異常を検出し得る。ＡＤＲＣ（たとえば、ＡＤＲＣ３５４）は、ＡＤＲＣを含むコンポーネントについて異常解決ポリシーが定義されるか否かを判断し得る。ポリシーが定義される場合、ＡＤＲＣは、ポリシーエンジンを利用して、ポリシーに基づいて異常を解決しようと試みることになる。異常を解決できない場合、または異常について定義されるポリシーがない場合には、ＡＤＲＣは、イベントの異常についての情報を親コンポーネント（たとえば、コンテナ３５０）に通信して解決し得る。親コンポーネントは、どのように異常を解決するかおよび親コンポーネントにおいてそのようなポリシーが定義されるか否かを判断することができるＡＤＲＣ（たとえば、ＡＤＲＣ３５４）を含み得る。
【００６１】
親コンポーネントが異常を解決できない場合、イベントの異常についての情報は、クラウドインフラストラクチャシステムにおけるコンポーネントの階層内に定義される親コンポーネントのより高いレベルの親コンポーネントに通信され得る。イベントの異常についての情報は、クラウドインフラストラクチャシステム１００に定義されるコンポーネントの階層内の関連する各々の後続の親コンポーネントに通信され得る。コンポーネントが親コンポーネントを持たないと判断すると、イベントの異常についての情報は、ＡＤＲＳのためのメッセージングシステムに発行され、クラウド環境レベルで異常に対処する、または警告を発行する。
【００６２】
異常解決に対するこの階層型アプローチは、集中型異常管理と比較して素早く、リソース使用の点で効率的である。コンポーネントレベルまで異常検出および解決を分離することによって、異常の発生に限局されるコンポーネントまたは親コンポーネントにおいて異常が対処されるので、異常の解決に消費される計算リソースを少なくすることができる。集中型システムへの異常の通信を減少させることによって、クラウドインフラストラクチャシステム１００は、異常の解決のための応答時間を減少させることができ、場合によっては、異常が局所コンポーネントにおいて解決されるので、さらなる問題または異常が発生することを防止することができる。異常検出および管理に対する局所的アプローチは、クラウドシステムなどの大規模コンピューティングシステムにおいて何千もの異常に対処することへの人間の関与を減少させることができる。異常検出および解決をコンポーネントレベルに限局することによって、クラウドインフラストラクチャシステムは、人間の関与がほとんどない状態で、さらに自律的に動作することができる。
【００６３】
ＡＤＲＳ３２０は、ＡＤＲＣによってコンポーネントレベルで対処される異常の検出および解決を連係させ管理し得る。ＡＤＲＣは、２つのサブシステム、すなわち異常検出および通知システム（Anomaly Detection and Notification System：ＡＤＮＳ）および異常解決サブシステム（Anomaly Resolution Subsystem：ＡＲＳ）で構成される。ＡＤＮＳサブシステムは、異常について監視するためにどのメトリックが必要であるか、イベントを発行する前に、異常が検出された場合にどの条件をテストするか、イベントデータに何を含めるかをシステム管理者が指定することを可能にする。ＡＤＮＳは、異常についての関連するメトリックを監視し、異常が検出されると条件を評価し、条件が事実である場合には、ＡＤＲＣが実現されるコンポーネントに対してローカルなデータストアに、異常に対応するイベントをイベントデータとともに格納する。異常を検出するための条件の一例は、イベントが生成される前に異常であるメトリックの連続読取値の数である。異常検出のためのメトリックおよび範囲は、サービスが作成されたときにＡＳＣ３１８のＳＣＤＭＳ３２２から得られる。負荷およびリソース消費などのメトリックは、システム管理者によって定義され、ＡＳＣ３１８のＬＲＡＳ３２６によって提供され得る。
【００６４】
いくつかの実施例では、ＡＤＮＳは、イベントを発行するように通信システムを実現し得る。通信システムは、通知サービスを実現し得る。通知サービスは、クラウドインフラストラクチャシステム３００内のコンポーネントおよび／またはＡＳＣ３１８との通信を容易にし得る。通信は、ネットワーク３３０を介して容易にされ得る。イベントおよび異常についての情報は、通信のためのプルおよび／またはプッシュ機構、たとえばプッシュまたはプル通知サービスを使用して、通信システムを介して通信され得る。プッシュおよび／またはプル機構は、ＡＤＲＳおよびＡＤＲＣのためにサブスクリプションベースで構成され得る。
【００６５】
ＣＣＭＳ３２４は、図４のコンポーネントモデルを利用して、システム（たとえば、クラウドインフラストラクチャシステム１００）のハードウェアおよびサービス（ソフトウェア）コンポーネント、ならびにそれらの間の関係、ならびにそれらが生成するログおよびメトリックストリームを記述する。ＣＣＭＳ３２４は、構成リポジトリなどのデータストアを管理し得て、当該データストアは、とりわけサービスのセルフサービスデプロイメント、仮想マシン（ＶＭ）のライブマイグレーション、容量スケールアウトおよびフェイルオーバに起因して構成の動的な性質を示す時間データベースである。構成リポジトリは、図４のコンポーネントモデルに基づいて定義され得る。ＣＣＭＳ３２４は、オラクル（登録商標）社によるオラクルエンタープライズマネージャリポジトリなどの他の構成リポジトリ、および、Ｎｉｍｂｕｌａまたはオープンスタック構成データベースなどの基本的なクラウドオペレーティングシステム（ＩａａＳ）によって維持される構成リポジトリ内の情報を活用し得る。
【００６６】
いくつかの実施例では、ＳＣＤＭＳ３２２は、オーケストレータと呼ばれるサブシステムを使用または実現し得て、当該サブシステムは、異なるインフラストラクチャ・アズ・ア・サービス（ＩａａＳ）に加えて抽象化層を提供して、コンテナを作成および構成する。作成された全てのサブシステムは、新たにデプロイされるコンポーネントのアイデンティティを生成し、割り当てを行い、デプロイされているコンポーネントについてのデータおよび他のサービスへのそれらの依存性で構成リポジトリを更新する。個々のコンポーネントは、ホームディレクトリならびに関連付けられるログおよびメトリックストリームで構成リポジトリを更新する。作成されたこれらのサブシステムには、アセンブリのプログラム的デプロイメントのための、表現可能な状態の転送（representation state transfer：ＲＥＳＴ）アプリケーションプログラミングインターフェイス（application programing interface：ＡＰＩ）およびコマンドラインインターフェイス（command line interface：ＣＬＩ）を介してアクセスすることができる。
【００６７】
ＳＣＤＭＳ３２２は、ユーザ（たとえば、アプリケーション開発者および管理者）がサービスを実現するようにコンポーネントを定義することを可能にし得る。図４および図５で説明するように、サービスを定義するコンポーネントは、１つ以上のアセンブリにおいて定義され得る。アセンブリを使用して、クラウドにおいて仮想環境をプロビジョニングしてサービスをデプロイする高度に自動化されたプロセスを提供し得る。
【００６８】
少なくとも１つの実施例では、ＳＣＤＭＳ３２２は、ユーザが異常の属性を定義することを可能にするために、１つ以上のインターフェイスを生成してクライアントシステムに提供し得る。インターフェイスは、物理インターフェイス、グラフィカルインターフェイス（たとえば、グラフィカルユーザインターフェイス）、またはそれらの組み合わせを含み得る。グラフィカルインターフェイスは、ＳＣＤＭＳ３２２によって生成され、クライアントシステム３１０に提供され得る。インターフェイスは、サービス（たとえば、クラウドサービス）またはアプリケーションの一部として、ネットワーク３３０を介して、ＳＣＤＭＳ３２２の一部として提供され得る。異常の属性は、宣言型の態様で定義され得る。たとえば、ユーザは、正常なシステム挙動を定義するキーメトリックについて範囲を指定することによって異常を定義してもよく、当該キーメトリックは、サービスの応答時間、サービスの可用性、サービスに割り当てられるべきリソース、システム負荷、許容エラー率、および他のメトリックに対する期待値を含む。ユーザは、サービスのＳＬＡに関連付けられるＱｏＳを顧客のために実施するためにメトリックについて範囲を指定し得る。メトリックの範囲は、図９および図１０を参照して説明する異常データ構造に従って定義され得る。また、ＳＣＤＭＳ３２２は、新たにデプロイされるコンポーネントのアイデンティティを生成し、コンポーネント情報、ならびに、ログおよびメトリックストリームとのそれらの関係および他のコンポーネントとのそれらの関係で構成リポジトリを更新する。
【００６９】
オーケストレータは、クラウドインフラストラクチャシステム１００へのアセンブリの作成およびデプロイメントのためのサービスアプリケーションであってもよく、アセンブリは、１つ以上のＶＭと、ストレージと、ソフトウェアと、ネットワーク接続とで構成され、システムがアセンブリ定義通りに動作することを可能にするシステムの一種である。オーケストレータは、インターフェイスを介してセルフサービス層を提供し、当該セルフサービス層から、ユーザはソフトウェアシステム全体の迅速なデプロイメントのためにコンポーネントおよびアセンブリのカタログを容易に利用することができ、ＤＮＳセットアップ、ソフトウェアブートストラップ、デプロイメント後のサイズ変更機能：ＶＭサイズ決め（垂直スケーリング）、およびアセンブリスケーリング（水平スケーリング）をさらに提供する。オーケストレータカタログは、単純なバージョニング、発行および宣言型構成特徴も提供する。開発者は、オーケストレータのコンポーネントフレームワークを使用して、全ての種類のシステム（たとえば、組織または機能標準化ＯＳ画像、テストのためのソフトウェアアプリケーションの新バージョンおよび旧バージョン、公表されたラベルなど）を定義するいくつものアセンブリを実現し得る。オーケストレータによって提供されるインターフェイスは、以下の通りプロビジョニングを可能にし得る。すなわち、（１）オーケストレータによって提供されるユーザインターフェイスに対して、ＳＳＯを介して認証し、（２）オーケストレータのカタログからアセンブリを選択し、（３）アセンブリインスタンスに対して名前およびサイズ決め情報を提供し、（４）割り当ておよび計測が不利に働くプロジェクト名を提供し、（５）クラウド環境にデプロイされるアセンブリインスタンスを設定し、（６）任意に、アセンブリインスタンスを停止／開始／アンデプロイし、アセンブリインスタンスのＶＭをサイズ変更する、またはアセンブリインスタンスをスケーリングする。オーケストレータは、オーケストレータ管理者が、デプロイメントを監視し、オーケストレータのそのインスタンスのために全てのユーザ、デプロイメントおよびカタログに対して「スーパーユーザ」アクションをログ記録して実行することを可能にするための管理者インターフェイスを含む。
【００７０】
ＬＲＡＳ３２８は、クラウドインフラストラクチャシステム１００内の全てのコンポーネントからログおよびメトリックストリームを収集し、統計を計算し、時系列分析を適用してメトリックの周期的範囲を判断し得る。ＬＲＡＳ３２８は、ユーザ定義の範囲が一定割合の時間以上にわたって満たされる正常なシステムオペレーションについて、各期間にわたって（たとえば、週に１回）、各間隔で（たとえば、１時間ごとに）、各メトリックについて、メトリックおよび各コンポーネントのリソース使用の傾向および周期的変動を計算する。これらの周期的範囲は、異常についてリソース使用を含むメトリックを監視できるように適切なコンポーネントに押し出される。このシステムは、教師なし機械学習技術を使用して将来の障害も予測する。
【００７１】
ＩＩＩ．コンポーネントモデル
図４および図５は、クラウドインフラストラクチャシステム１００を実現するためのコンポーネントモデルを示す。図４および図５における要素は、１つ以上のデータ構造を使用して実現されてもよい。データ構造は、コンポーネントモデルを利用するＡＳＣ３１８またはＡＤＲＣにアクセス可能なストレージ（たとえば、データストア）において管理することができる。示されている要素の各々は、どのようにデータが格納されるか、どのデータが格納されるか、および／または、どこにデータが格納されるかに応じてさまざまな方法で編成される１つ以上のデータ構造を使用して実現されてもよい。データ構造の各々は特定のデータを含むものとして示されているが、データを格納するためにより多くのデータ構造が実現されてもよく、またはより少ないデータ構造が実現されてもよい。データ構造は、他のデータ構造への参照を含み得る。さまざまなセキュリティアーチファクトの格納を管理するために、データ構造の各々のインスタンスが作成され得る。データ構造は、１つ以上のタイプのデータ構造を使用して実現されてもよく、当該１つ以上のタイプのデータ構造は、連結リスト、アレイ、キュー、ハッシュテーブル、マップ、レコード、グラフ、または他のタイプのデータ構造を含むが、それらに限定されるものではない。データ構造の各々は、ＡＳＣ３１８への入力に基づいて、宣言型の態様で定義され得る。
【００７２】
図４は、クラウドインフラストラクチャシステム１００などのコンピューティングシステムのコンポーネントモデル４００を示す。図３におけるコンポーネント（たとえば、コンテナ３５０，３６０，３７０）は、コンポーネントモデル４００に基づく。コンポーネントモデル４００は、異なるメトリックおよびログストリームの相関付けに使用され得る。任意のサービスデプロイメントシステムは、１つ以上のコンポーネント４０２を含み得て、当該１つ以上のコンポーネント４０２のうちのいくつかまたは全ては関係付けられ得る。各コンポーネントは、デプロイメント４１０によって、１つ以上の異なるコンポーネントタイプ４０６のうちの１つのインスタンスとして作成される。コンポーネント同士は、さまざまな種類の関係によって関係付けることができ、当該関係は、親−子関係、たとえば物理ＮＩＣが、それがインストールされるベアメタルサーバの子である関係、および、アイデンティティプロバイダを使用してそのユーザを認証する補償アプリケーションなどの対等の関係を含む。いくつかのコンポーネントは、他のコンポーネントにリソースを提供するコンテナである。コンポーネントは、１つ以上のログストリームおよび１つ以上のメトリックストリームを生成し得る。
【００７３】
コンポーネント４０２は、コンポーネントタイプ４０６のインスタンスとして作成され、アセンブリ４０８に基づいてデプロイメント４１０のために作成され得る。アセンブリ４０８は、コンポーネントとコンテナとの関係、サービスタイプのインスタンスを作成するのに必要な相互接続、およびサービスを構成するためのコードなどの他の情報の中で１つ以上のコンポーネントタイプを記述するテンプレートであり得る。アセンブリにおいて指定されるコンポーネントタイプは、コンポーネントにデプロイされるべきコンポーネントを特定するためのものである。デプロイメント４１０は、アセンブリ４０８によって示されるコンポーネントタイプに基づき得る。いくつかの実施例では、アセンブリは、サービスを提供するためのコンポーネント、各コンポーネントに必要なリソース、ネットワークおよびストレージ構成、各コンポーネントに構成されるべきソフトウェア、ならびに、サービスを監視するためのメトリックおよび応答時間の範囲を定義する。たとえば、アセンブリは、複数のＣＰＵおよびメモリ量を有し、ソフトウェアコンポーネントがデプロイされる１つ以上のＶＭと、それらが使用するストレージおよび他のサービスと、ネットワーク接続とで構成され得て、システムがアセンブリ開発者の設計通りに動作することを可能にする。アセンブリを使用して、ＩａａＳサービス、ＰａａＳサービスまたはＳａａＳサービスなどの任意の複雑さの単一または複数ＶＭベースのシステムを構築することができる。アセンブリは、ＶＭサイズ決め情報（ｖＣＰＵカウント、メモリ量）、割り当てられるべきディスクストレージ、インストールされるべきコンポーネントのリスト、ネットワーク通信情報（送信元、出力先、ポート）、およびアセンブリデプロイメント中に値が提供され得るコンポーネントによって必要とされる変数を含み得る。
【００７４】
各コンポーネントは、汎用一意識別子（universally unique identifier：ＵＵＩＤ）である固有の識別子（intrinsic identifier：ＩＩＤ）などの識別子を有し得る。ＩＩＤは、不変であり、グローバルにおよび時間的に固有であり得て、常に同一のコンポーネントを参照する。すなわち、過去に存在したコンポーネントまたは将来出現するであろうコンポーネントを考えても、２つのコンポーネントが同一のＩＩＤを有することはない。コンポーネントは、複数の外来的な識別子（extrinsic identifier：ＥＩＤ）を有し得る。これらは、コンポーネントに与えられる同様の主キーまたは他の識別子である。たとえば、物理マシンに与えられるＩＰアドレスがＥＩＤである。ＥＩＤは、永久的なものであることはなく、コンポーネントの存続期間中に変化する可能性がある。２つのコンポーネントが親−子関係、すなわちあるコンポーネントが別のコンポーネント内に組み込まれる関係によって関係付けられる場合、子コンポーネントはそれ自体のＩＩＤを有する必要はない。なお、子（または組み込まれた）コンポーネントは、親を１つだけ有し得る。
【００７５】
コンポーネント４０２は、多くの異なるコンポーネントタイプのうちの１つとして定義され得て、ネットワークデバイス４１４、サービスインスタンス４１６、コンテナ４１８、ストレージインスタンス４２０またはデータベースインスタンス４２２を含むが、それらに限定されるものではない。たとえば、コンポーネントは、オペレーティングシステム、データベース、ミドルウェアシステム、アプリケーション、プログラムまたはスクリプトを含んでいてもよい。図４の例では、コンテナは、物理マシン４２４、仮想マシン４２６、オペレーティングシステム（ＯＳ）コンテナ４２８、Ｊａｖａ仮想マシン４３０およびクラスタ４３２を含み得るが、それらに限定されるものではない。ＯＳコンテナは、リナックス（登録商標）（ＬＸＣ）コンテナ４３４、ドッカーコンテナ４３６またはソラリスゾーン４３８を含み得るが、それらに限定されるものではない。別の例では、コンポーネントは、オーケストレータを実行させるためのプラグインモジュールを含んでいてもよい。オーケストレータは、仮想マシンのブートストラップ中に呼び出されるプログラムレシピとしてデータおよびブートストラップロジックを含み得る。コンポーネントは、アセンブリのコンポーネントによって使用される一組の変数の宣言を含み得る。
【００７６】
コンポーネントタイプ４０６は、いくつかある特性の中で特に、１つ以上のログストリーム４１２および１つ以上のメトリックストリーム４０４を定義することができる。コンポーネントタイプ４０６のインスタンスとして作成されるコンポーネント４０２は、コンポーネントタイプ４０６によって定義されるメトリックストリーム４０４およびログストリーム４１２を生成し得る。メトリックストリーム４０４もログストリーム４１２も、時系列データのストリームであってもよい。メトリックストリーム４０４もログストリーム４１２も、１つ以上のファイル、データベースに書き込まれてもよく、またはメッセージングシステムの１つ以上のトピックまたはキューに直接発行されてもよい。ストリームは、親−子関係の中で、それらを生成するコンポーネントに関連付けられる。エントリは、サービスの同一の制御フローを形成するさまざまなコンポーネントへのエントリを関係付けるために、（ＯＤＬログにおけるＥＣＩＤおよびＲＩＤなどの）いくつかのコンテキスト識別子を含み得る。
【００７７】
図５は、図４におけるコンポーネントモデル４００の要素間の関係を示すサービスモデル５００を示す。具体的には、サービスモデル５００がクラウドインフラストラクチャシステム１００によって利用されて、サービス５１０などのサービス（たとえば、サービスインスタンス）がクライアントシステム３１０に提供される。サービス５１０またはサービスインスタンスは、サービステンプレート５０２のインスタンスとして作成され得る。サービスは、クラウドインフラストラクチャシステム１００に対する要求／応答通信を介して作成され得る。このような通信は、ＨＴＴＰ（Ｓ）または直接ＴＣＰ／ＩＰ（たとえば、ＩＭＡＰ）プロトコルを使用して円滑化することができる。サービステンプレートは、それに関連付けられる１つ以上のアセンブリテンプレート（たとえば、アセンブリテンプレート５０４）に基づいて定義され得る。
【００７８】
アセンブリテンプレートは、アセンブリ（たとえば、アセンブリ５１２）を定義する。アセンブリは、アセンブリテンプレートのインスタンスとして作成され得る。アセンブリテンプレートは、共有ファイルシステム、ネットワーク、アセンブリにおいて定義されるコンテナが利用できるストレージ、およびクラウド環境にアセンブリをデプロイするように実行されるワークフローなどの環境レベルのリソースを定義し得る。たとえば、クラウド環境がオラクルＨＴＴＰサービス（Oracle HTTP Service：ＯＨＳ）などのＨＴＴＰリスニングサービスを提供し、各サービスがＯＨＳ内に仮想ホストを作成する場合、ＯＨＳサービスを実行している既存のシステムコンテナ内に仮想ホストを作成するために、ワークフローがサービスのアセンブリテンプレートに含まれてもよい。各々のアセンブリテンプレートは、ＱｏＳ特性および価格付けを定義し得る。たとえば、サービステンプレートは、２つのアセンブリテンプレート、すなわち機能をテストするための一方のアセンブリテンプレートおよびスケーラブルな生成デプロイメントのための他方のアセンブリテンプレートによって定義されてもよい。
【００７９】
サービスは、それに関連付けられるいくつかのエントリＵＲＩを有し得る。サービスのリスナは、クラスタであり得る専用のまたは共有のコンテナにデプロイされる。サービスは、これらのＵＲＩとの一連の要求−応答対話によって提供される。アセンブリの作成者は、サービス品質監視コンポーネントを含み得て、当該サービス品質監視コンポーネントは、アセンブリによってサポートされるエントリＵＲＩおよびサポートされる一組のサービスを表わす一組の変数を指定し、各サービスは、エントリＵＲＩのリストである。エラー特性の変数は、特定のタイプの許容エラー率を定義する。
【００８０】
アセンブリのデプロイメント中、ユーザは、ＡＤＲＳに対して入力を提供して、ＳＣＤＭＳが、応答時間に関する固定された範囲または周期的範囲と、各サービスの可用性と、サービスを確立するために作成されるサービスインスタンスによって対処すべき負荷とを定義することによって、所望のサービス品質を決定することを可能にし得る。多くのサービスは、ＱｏＳ特性が恐らく異なっている異なるアセンブリテンプレートを各々が使用して、単一のサービステンプレートから作成することができる。サービスは、サービスの全てのコンポーネントについて定義される全てのメトリックが、サービスおよびサービスが実行されているコンテナについて指定される範囲の範囲内であるように作成され得る。当該範囲の範囲外であると認められるいかなるメトリック値も異常であると考えられ、異常は、指定の期間にわたって持続すると、ＡＤＲＳ３２０によってリアルタイムで対処されることになる。
【００８１】
アセンブリテンプレートは、コンテナテンプレート５０６などの１つ以上のコンテナテンプレートを参照し得る。コンテナテンプレートは、コンテナタイプ、割り当てられるべきリソース、デプロイされるべきコンポーネント、コンテナに特有のメトリック、およびコンテナに特有の異常検出および解決ポリシーを定義し得る。たとえば、１つ以上のコンテナ（たとえば、コンテナ５１４）は、それ自体の専用のコンテナにデプロイされてもよく、または共有のコンテナにデプロイされてもよい。専用のコンテナは、さらなるコンポーネントがそこにデプロイされることを認めないが、既存のコンポーネントに対する更新は依然として実行することができる。コンテナは、２つの状態のうちの１つ、すなわち開放状態または閉鎖状態であり得る。コンポーネントは、閉鎖したコンテナにデプロイ可能であることはない。
【００８２】
コンポーネントテンプレート５０８などの非コンテナコンポーネントテンプレートは、構成仕様、（インストルメンテーションを含む）サービスに特有のメトリック、およびコンポーネント（たとえば、コンポーネント５１６）に特有の異常検出および解決ポリシーを定義し得る。コンポーネントは、コンテナ内で実行され得る。コンテナは、コンポーネントを使用し得る。コンテナテンプレートは、コンテナテンプレートに基づいて作成されるコンテナ内で実行されるようにコンポーネントのためのコンポーネントテンプレートを参照し得る。コンポーネントは、コンポーネントテンプレートのインスタンスとして作成され得る。コンポーネントテンプレートは、コンポーネントテンプレートに依存し得る。コンポーネントテンプレートは、キーＵＲＩの応答時間などのメトリックを宣言し得る。アセンブリがデプロイされると、所与のソフトウェア／ハードウェア環境にデプロイされるサービスを作成するために、アセンブリにおいて定義される各メトリック（たとえば、アプリケーションコンポーネントの応答時間、コンテナのためのＣＰＵ、ＲＡＭなどの数）について範囲が設けられなければならない。
【００８３】
ＩＶ．異常検出および解決コンポーネント（ＡＤＲＣ）の詳細な概要
図６および図７は、いくつかの実施例に係るＡＤＲＳのＡＤＲＣ６００のブロック図を示す。ＡＤＲＣは、図３のＡＤＲＳ３２０の一部として実現されてもよい。ＡＤＲＣは、クラウドインフラストラクチャシステム１００内の各コンポーネントについて作成され得る。たとえば、ＡＤＲＣ３５４，３６４，３７４の各々は、ＡＤＲＣ６００のインスタンスであってもよい。上記のように、ＡＤＲＣは、クラウドインフラストラクチャシステム１００のコンテナなどのコンポーネントにデプロイすることができる。ＡＤＲＣは、異常を検出して解決するように実現され得る。ＡＤＲＣは、Ｊａｖａ（登録商標）などのさまざまなプログラミング言語を使用して実現され得る。
【００８４】
いくつかの実施例では、ＡＤＲＣ６００は、１つ以上のサブシステムおよび／またはモジュールを含み得る。ＡＤＲＣ６００は、異常検出および通知システム（ＡＤＮＳ）６３０と、異常解決サブシステム（ＡＲＳ）６２０とを含み得て、ＡＤＮＳ６３０およびＡＲＳ６２０の各々は、１つ以上のサブシステムおよび／またはモジュールを含む。ＡＤＮＳ６３０は、１つ以上の異常検出器（ＡＤ）６０８と、データストア６１２とを含み得る。ＡＲＳ６２０は、ポリスエンジン（police engine：ＰＥ）６０２と、通信エージェント（communication agent：ＣＡ）６０４と、アクションライブラリ（action library：ＡＬ）６０６と、イベントディスパッチャ（event dispatcher：ＥＤ）６１０と、ログハーベスタ（log harvester：ＬＨ）６１４と、ポリシーストア６１６とを含み得る。
【００８５】
また、ＡＤＲＣ６００は、メモリストレージデバイスまたは他の非一時的なコンピュータ読取可能な記憶媒体などのいずれかのタイプの永続的ストレージデバイスを使用して実現され得るストレージを含むか、または当該ストレージに結合される。いくつかの実施例では、ローカルストレージは、１つ以上のデータベース（たとえば、ドキュメントデータベース、リレーショナルデータベースまたは他のタイプのデータベース）、１つ以上のファイルストア、１つ以上のファイルシステム、またはそれらの組み合わせを含み得る、または実現し得る。たとえば、ＡＤＲＣ６００は、１つ以上のデータストアに結合されてもよく、または１つ以上のデータストアを含んでいてもよい。メモリおよびさらなるストレージは全て、コンピュータ読取可能な記憶媒体の例である。たとえば、コンピュータ読取可能な記憶媒体は、コンピュータ読取可能な命令、データ構造、プログラムモジュールまたは他のデータなどの情報の格納のためのいずれかの方法または技術で実現される揮発性または不揮発性のリムーバブルまたは非リムーバブルメディアを含み得る。本明細書に開示されている技術に従ってデータを格納するためにより多くのデータストアが実現されてもよく、またはより少ないデータストアが実現されてもよい。
【００８６】
少なくとも１つの実施例では、ＡＤＲＣ６００は、データストア６１２と、ポリシーストア６１６と、ＡＬ６０６とを含み得る。データストア６１２は、ラウンドロビンデータベース（round-robin database：ＲＲＤ）または巡回待ち行列として実現されてもよい。ＲＲＤは、巡回待ち行列（たとえば、先入れ先出し巡回待ち行列）を使用して実現されてもよい。たとえば、図７では、ＡＤＲＣ６００は、ＲＲＤ７０４、ＲＲＤ７０６、ＲＲＤ７０８、ＲＲＤ７１０およびＲＲＤ７１２などの複数のＲＲＤを含み、各々のＲＲＤは、異常検出器によって検出される異なるタイプの異常に対応する異なるイベントデータに特有である。イベントデータは、ＡＤＲＣ６００が実現されるコンポーネントにおける異常イベントのソース、異常イベントの原因、異常イベントがいつ検出されたかについての情報、および異常イベントについてのその他の情報を含み得る。ＲＲＤ７０４は、ＲＡＭで検出される異常のイベントデータを格納し得る。ＲＲＤ７０６は、ＣＰＵで検出される異常のイベントデータを格納し得る。ＲＲＤ７０８は、ストレージで検出される異常のイベントデータを格納し得る。ＲＲＤ７１０は、ネットワークベースの異常のイベントデータを格納し得る。ＲＲＤ７１２は、コンポーネントに特有の異常のイベントデータを格納し得る。
【００８７】
ＡＤＮＳ６３０は、クラウドインフラストラクチャシステム１００において１つ以上のメトリックを監視し得る。ＡＤＮＳ６３０は、ネットワークリソースを異常の監視に使用することを最小限にするように設計される。特に、ＡＤＮＳ６３０は、ＡＤＲＣ６００が実現されるコンポーネントにおいてメトリックを監視し得る。１つ以上の異常検出器６０８を利用してメトリックを監視し得て、当該メトリックは、ポーリングによってまたはイベントをリッスンすることによって、何らかのメトリックストリームにおいて直接入手可能であるかまたは何らかのログストリームから計算される。いくつかの実施例では、コンポーネントは、複数のＡＤ、すなわちコンポーネントにおける各リソースについて１つのＡＤを有し得る。ＡＤは、監視すべき各々個別のメトリックについて実現されてもよい。ＡＤは、各々のログタイプについて実現されてもよい。
【００８８】
メトリックは、図９を参照して説明する異常分類システムを使用して監視され得る。異常は、異常の定義に基づいてメトリックについて監視され得る。ＡＤは、リソース使用に対応するメトリックについて定義され得る。リソースは、エラー率ターゲットに関して監視され得る。異常は、固定された範囲または周期的範囲によって定義され得る。閾値が満たされた場合にイベントを発行するようにＡＤが構成されるように、閾値がメトリックについて定義され得る。メトリックを監視するために、ＡＤは、さまざまな技術によって１つ以上の重要業績指標（ＫＰＩ）、リソース使用およびエラーを監視し得る。メトリックは、ＡＤＲＣが実現されるコンポーネントのシステムにおけるイベントへのサブスクリプションまたはポーリングメトリックによって監視され得る。たとえば、ＡＤは、オペレーティングシステムにおいてポーリングオペレーティングシステムメトリックまたはＭＢｅａｎ（管理されたＪａｖａオブジェクト）属性によってリソース使用を監視してもよい。ＡＤは、関連するログファイルを定期的にスキャンして、ｓｙｓｌｏｇなどのオペレーティングシステムログをリッスンし得る。
【００８９】
ＡＤは、コンポーネントに特有のものであってもよく、そのため、ＡＤは、ＡＤを含むＡＤＲＣが実現されるコンポーネントのタイプに特有の特徴を使用してメトリックを監視する。たとえば、ＪＶＭタイプのコンテナであるコンポーネントでは、ＡＤは、異常を検出するためにＪＶＭにデプロイされたＭＸＢｅａｎからのＪａｖａ管理拡張機能（Java management extensions：ＪＭＸ）通知をリッスンしてもよい。別の例では、ＬＸＣコンテナのＡＤは、異常を検出するためにＨｅｋａなどのストリーム処理ソフトウェアを使用してもよい。ストリーム処理ソフトウェアは、ＡＤＮＳがログおよびメトリックストリームを監視してそれらの値にフィルタを適用することを可能にし得る。当該フィルタは、範囲外の値を検出するように設計される。ＡＤは、ＡＤが実現されるコンポーネントのタイプに特有の言語を使用して実現され得る。たとえば、ＪＶＭコンテナタイプのＡＤは、Ｊａｖａ式言語（Java expression language：ＪＥＸＬ）を使用して実現されてもよい。いくつかの実施例では、ＡＤＮＳは、監視すべきメトリックのために異常分類システムに基づいて初期化される砂箱スタイルのフィルタを使用して実現されてもよい。当該フィルタは、値をテストして、範囲外の連続読取値の数を記憶する。異常についての閾値に達すると、異常が検出され得る。
【００９０】
図７では、ＡＤＲＣ６００は、ＲＡＭ  ＡＤ７２０、ＣＰＵ  ＡＤ７２２、ストレージＡＤ７２４、ネットワークＡＤ７２６およびコンポーネントＡＤ７２８などの複数の異常検出器を有するものとして示されている。ＲＡＭ  ＡＤ７２０、ＣＰＵ  ＡＤ７２２、ストレージＡＤ７２４、ネットワークＡＤ７２６およびコンポーネントＡＤ７２８の各々は、ＡＤＲＣ６００が実現されるコンポーネントにおいて個別のタイプの異常を検出するように実現され得る。ＲＡＭ  ＡＤ７２０は、ＲＡＭ使用に関連する異常を検出し得る。ＣＰＵ  ＡＤ７２２は、ＣＰＵ使用に関連する異常を検出し得る。ストレージＡＤ７２４は、ストレージ使用に関連する異常を検出し得る。ネットワークＡＤ７２６は、ネットワークアクティビティに関連する異常を検出し得る。コンポーネントＡＤ７２８は、コンポーネントに特有の異常を検出し得る。ＲＡＭ  ＡＤ７２０、ＣＰＵ  ＡＤ７２２、ストレージＡＤ７２４、ネットワークＡＤ７２６およびコンポーネントＡＤ７２８の各々は、ＲＲＤ７０４、ＲＲＤ７０６、ＲＲＤ７０８、ＲＲＤ７１０およびＲＲＤ７１２などの個別のデータストアをそれぞれ有し得る。ＡＤのための個別のデータストアは、ＡＤのために検出される異常のイベントデータの格納に利用され得る。Ａｄ７２０〜７２８の各々は、個別の異常を検出するように定義され得る。上記のように、およびさらに以下で説明するように、異常は、メトリックの特定の範囲によって定義され得る。たとえば、ＡＤ７２０〜７２６の各々は、周期的範囲に従った異常について定義されてもよく、ＡＤ７２８は、固定された範囲に従った異常について定義されてもよい。
【００９１】
ＡＤは、異常分類システムを使用して、メトリックの値が、異常について定義された閾値を満たす場合にイベント（「異常イベント」）を検出し得る。ＡＤは、当該イベントについてイベントデータを定義し、当該イベントデータをデータストア６１２に格納し得る。たとえば、異常イベントのイベントデータは、Ｕｎｉｘデータグラムを使用してデータストア６１２に挿入されてもよい。イベントデータは、さらなるメトリックを含み得て、当該さらなるメトリックは、リアルタイムで収集され、次いで異常イベントについてのデータとともに格納される。ＡＤは、定義済みの異常の範囲（たとえば、固定された範囲または周期的範囲）を監視し得る。メトリックの値が定義済みの異常の範囲の範囲内でなく、そのため、当該値が最小値尺度を下回るまたはソフト限界を上回ることを検出すると、ＡＤは、異常が発生していることを検出し得て、当該異常を引き起こすイベントについての情報をログ記録し得る。ＡＤは、データストア６１２へのログエントリを書き込んで、異常と、メトリックの値がｍｉｎを下回る（たとえば、低である）またはソフト限界を上回る（たとえば、高である）か否かとを表示し得る。
【００９２】
ＡＲＳ６２０は、ＡＤＮＳ６３０によって検出されるイベントに基づいて動作する。イベントディスパッチャ６１０は、ＡＤＲＣ６００が実現されるコンポーネントで実行され得る。イベントディスパッチャ６１０は、ＡＤＮＳ６３０によって特定されるイベントをリッスンし得る。いくつかの実施例では、イベントディスパッチャ６１０は、ＡＤによって検出されたイベントを通知され得る。イベントディスパッチャ６１０は、ＡＤＮＳ６３０におけるＡＤによって挿入されたイベントデータによって特定される異常イベントがあるかどうかデータストア６１２を検査し得る。たとえば、ＡＤ７２０〜７２８の各々が、検出される異常イベントについてイベントディスパッチャ６１０に通知してもよい。イベントディスパッチャ６１０は、ＡＤ７２０〜７２８の各々を定期的にチェックして、異常イベントについての情報が記録されたか否かを判断する。いくつかの実施例では、イベントディスパッチャ６１０は、メッセージキュー７０２に基づいて異常イベントを検出し得る。ＡＤ７２０〜７２８の各々は、メッセージキュー７０２にメッセージを載せることによってイベントディスパッチャ６１０に異常イベントを通知し得る。イベントディスパッチャ６１０は、通知およびＲＲＤの検査に基づいて異常イベントを処理し得る。
【００９３】
イベントディスパッチャ６１０は、ポリシーストア６１６をサーチして、異常イベントについて定義される各々のポリシー（たとえば、ディスパッチポリシー）を特定し得る。ポリシーストア６１６は、どのように異常イベントに対処するかを判断するためにディスパッチポリシーを格納し得る。たとえば、ポリシーは、異常イベントのタイプについて定義されるように、異常に特有のものであってもよい。ポリシーは、ＡＤＲＣ６００が実現されるコンポーネントのタイプに特有の言語で実現（たとえば、定義）され得る。たとえば、ＪＶＭでは、ポリシーは、ＪＥＸＬを使用して定義されてもよい。ＡＤＲＣ６００は、ポリシーの１つ以上のルールの変更に対してポリシーストア６１６を更新することができる。
【００９４】
ポリシーは、異常イベントに対処するために実行すべきアクションを定義し得る。ポリシーで定義されるアクションは、ＡＬ６０６において特定される予め定義されたアクションであってもよい。ポリシーは、１つ以上のタイプの異常イベントについての１つ以上の基準（たとえば、ルールまたは条件）を含み得る。各ルールは、修正アクションペアとして少なくとも１つの修正アクションに関連付けられ得る。ポリシーの各々は、異常イベントについて登録され得る。ポリシーにおけるルールは、異常を解決してＱｏＳ違反を回避するためのイベント−条件−アクション（ＥＣＡ）ルールとして定義され得る。各ポリシーは、１つ以上のイベントに関連付けられ得る。コンポーネント間の関係、特に制御フローにおけるコンポーネントの直接先行するコンポーネントおよび後続のコンポーネントで発生する異常は、ユーザ定義のルールおよびシステム定義のルールにおいて考慮される。プログラム的アクションを講じることができる場合には、それはルールのアクション部分として符号化される。ルールは、１つ以上のパラメータで定義され得る。いくつかの実施例では、５つのパラメータを有するルール（たとえば、５つの要素からなるルール）が定義され得る。５つのパラメータは、（１）異常（ｌ）のリストと、（２）異常の最小数（ｌ（ｍ））と、（３）ｍ個の異常が発生した期間または間隔と、（４）ｍ個の異常を解決するために講じるべきアクション（ａ）と、（５）ルールが二度と考慮されない、アクションが起動された後の期間（ｑ）（たとえば、クワイエットピリオド）とを含み得る。アクションは、オペレーティングシステムまたはシェルコマンド、ならびに、Ｐｕｐｐｅｔ、Ｃｈｅｆおよびウェブロジック・スクリプティング・ツールのようなツールを含むさまざまな技術を使用して符号化され得る。
【００９５】
ルールは、宣言型であってもよく、または手続き型であってもよい。宣言型ルールは、ポリシーストア６１６に格納され得る。宣言型ルールは、オラクル社によって提供されるオラクルビジネスルールエンジンなどのルールエンジンによって実行され得る。宣言型ルールシステムは、オラクル社によって提供されるウェブロジック診断フレームワークウォッチルールシステムなどのコンテナに特有のルールシステムによってサポートされ得る。手続き型ルールは、手続きおよびポリシーエンジン６０２によって使用されるパラメータ（たとえば、パラメータのタプル）のベクトルとして定義することができる。手続き型ルールの一例は、オラクル社によって提供されるオラクルウェブロジックサーバの２層適応ヒープ管理システムである。手続き型ルールを有するポリシーは、管理されたｂｅａｎを使用して実現されてもよく、その挙動は、手続き型ルールを使用して一組のパラメータによって制御され得る。
【００９６】
イベントディスパッチャ６１０は、ポリシーストア６１６をサーチして、異常イベントを解決するための１つ以上のポリシーを特定し得る。イベントディスパッチャ６１０は、異常についてポリシーが定義されるか否かに基づいて、異常イベントをどのように処理するかを判断し得る。異常イベントについて少なくとも１つのポリシーが定義されると判断すると、イベントディスパッチャ６１０は、異常イベントについて定義されたポリシーをポリシーストア６１６から検索し得る（７３０）。イベントディスパッチャ６１０は、ポリシーエンジン６０２を呼び出して、異常イベントについて判断されたポリシーに基づいて異常に対処し得る。いくつかの実施例では、イベントディスパッチャ６１０は、異常イベントを解決するための複数のポリシーを特定し得る。イベントディスパッチャ６１０は、ポリシーにおけるルールによって定義される異常のリストの中で、異常の最大適合を備えたルールを有するポリシーを選択し得る。ポリシーエンジン６０２は、異常イベントを管理するためのポリシーにおけるルールが満たされると当該異常イベントに対処するように要求され得る。少なくとも１つの実施例では、５つの要素からなるルールを定義するポリシーの場合、イベントディスパッチャ６１０は、ある期間中に最小数の異常が満たされるなど、ポリシーの５つの要素からなるルールのパラメータが満たされると判断すると、異常に対処するようにポリシーエンジン６０２に要求し得る。イベントディスパッチャ６１０は、ルールについて定義される異常のリストの中で、異常の最大適合を備えたポリシーのルールを選択し得る。異常イベントについてのルールが満たされるポリシーを特定すると、イベントディスパッチャ６１０は、異常イベントの異常を解決するようにポリシーエンジン６０２に要求を送信し得る（７４０）。当該要求は、特定されたポリシーおよび異常イベントについてのイベントデータを含み得る。いくつかの実施例では、一組の異常を解決するためにポリシーエンジン６０２が呼び出され得て、ポリシーのルールは、当該ルールを満たす複数の異常イベントの発生に基づいて満たされる。イベントディスパッチャ６１０は、異常イベントに対応するイベントデータを送信するようにポリシーエンジン６０２に要求し得る。
【００９７】
いくつかの実施例では、異常イベントについてポリシーが定義されないと判断すると、イベントディスパッチャ６１０は、異常イベントについて親コンポーネント（たとえば、親コンテナ）に知らせ得る（７５０）。通信エージェント６０４は、ＡＤＲＣ６００を含むコンポーネントならびにＡＤＲＣ６００を含むコンポーネントの親および子コンポーネント内で通信するように構成され得る。このように、ＡＤＲＳ３２０のＡＤＲＣ６００は、ルールベースの階層型異常検出および解決システムであると考えることができる。親コンポーネントは、ＡＤＲＣ６００が実現されるコンポーネントの親であるコンポーネントであってもよい。たとえば、図３のＡＤＲＣ３６４が異常イベントについて定義されたポリシーをコンテナ３６０内で見つけられない場合、ＡＤＲＣ３６４におけるイベントディスパッチャは、コンテナ３６０の親であるコンテナ３５０のＡＤＲＣ３５４に異常イベントを通信し得る（７５０）。親コンポーネントが異常イベントを解決できない（たとえば、異常イベントについてポリシーが特定されない）と判断すると、親コンポーネントは、異常イベントの解決のために、存在する場合にはその親コンポーネントに異常イベントのイベントデータを通信し得る。異常イベントを解決できない最高レベルの親コンポーネント（たとえば、最上位のコンテナ）に到達すると、最高レベルの親コンポーネントは、異常イベントについての情報を一斉送信し得る。いくつかの実施例では、ＡＤＲＣ６００を含むコンポーネントが最高レベルのコンポーネントであってもよい。最高レベルのコンポーネントは、異常イベントについての情報を、１人以上のユーザまたはクラウドインフラストラクチャシステム１００によって契約されるトピックに発行し得る。いくつかの実施例では、最高レベルのコンポーネント内のＡＤＲＣまたはＡＤＲＳ３２０は、解決ルールに基づいて異常イベントを解決しようと試み得て、および／または、影響を受けたコンポーネント（たとえば、コンテナ）を含む異常イベントの詳細な説明を用いてオペレータに知らせる。最高レベルのコンポーネントのＡＤＲＣのポリシーエンジン６０２は、ダイナミックリソースマネージャのように作用して異常イベントを解決しようと試み得る。たとえば、ポリシーエンジン６０２は、異常イベントを解決するために、サービスに割り当てられるリソースを調整してもよい（たとえば、クラスタのより多くのコンテナをスピンアップ／ダウンしてもよい）。
【００９８】
イベントディスパッチャ６１０は、さまざまな方法で異常イベントを親コンポーネントに通信し得る。イベントディスパッチャ６１０は、異常イベントについての通知を親コンポーネントのＡＤＲＣに送信し得る。親コンポーネントのＡＤＲＣは、ＡＤＲＣ６００から通知を受け取るように契約し得る。したがって、イベントディスパッチャ６１０が異常についての通知を送信する（たとえば、押し出す）と、親コンポーネントのＡＤＲＣは、サブスクリプションの一部として通知を受け取ることができる。いくつかの実施例では、イベントディスパッチャ６１０は、異常イベントについてのイベントデータを親コンポーネントのキューまたはＲＲＤなどのデータストアに入れ得る。親コンポーネントのＡＤＲＣは、イベントデータがあるかどうかデータストアをチェックするイベントディスパッチャを含み得て、当該イベントデータは、イベントディスパッチャ６１０がイベントデータをデータストアに入れると特定される。いくつかの実施例では、イベントディスパッチャ６１０は、１人以上の受け手（たとえば、オペレータまたは管理者）に異常イベントを通知するために１人以上の受け手に警告７６０を送信し得る。警告７６０は、親コンポーネントに通知を送信することまたはポリシーに基づいて異常イベントを解決することの代替案として、またはそれに加えて、送信され得る。たとえば、警告７６０は、Ｓａｍｚａなどの分散型ストリーム処理フレームワークを使用してＫａｆｔａトピックとして送信されてもよい。
【００９９】
ステップ７１４において、ポリシーエンジン６０２は、イベントディスパッチャ６１０によって特定された異常イベントに関して１つ以上のオペレーションを実行し得る。オペレーションは、異常イベントのソースまたは原因を解決とまではいかなくても軽減するための修正アクションを実行することを含み得る。ポリシーエンジン６０２は、イベントディスパッチャ６１０によって特定されたポリシーにおける各ルールについて条件を評価し得る。各ルールは、それが満たされるか否かを判断するように評価され得て、満たされる場合には、ルールに関連付けられる修正アクションがポリシーエンジン６０２によって起動され得る。ポリシーのルールについて定義される修正アクションは、サービスをイネーブルにするためのリソースを提供することに関連し得る。修正アクションの例としては、未使用のリソースを現在のコンポーネントに戻すこと、より多くのリソースをコンポーネントから要求すること、サービス要求を抑制／停止すること、スレッドまたはプロセスを中止すること、異常イベントに関連するリソース使用スパイクについてコンポーネントのＡＤＲＳ３２０に知らせること、ＶＭプロセスへのリソース割り当てを増加させること、ＶＭへのリソース割り当てを増加させること、クラスタにおけるサーバの数を増加させること、製品の電源を入れること、クラスタ内のサーバを減少させること、製品内のＶＭを減少させること、負荷を抑制すること、および製品の電源を切ることを挙げることができる。
【０１００】
図６では、ＬＨ６１４は、異常イベントの分析のためにログファイルを収集するように実現され得る。ＬＨ６１４は、ＡＤＲＣ６００を含むコンポーネントについてログストリームおよびメトリックストリームからデータを収集し得る。ＬＨ６１４は、各々のストリームを、当該ストリームを生成したコンポーネントのアイデンティティと関連付け得る。ＬＨ６１４は、回転されるログファイルを定期的に、またはライブログでは一定の間隔で（たとえば、１時間ごとに）収集し、それらに対して関連するメタデータを添付して、それらをログアーカイブに送信するように、スクリプトとして実現されてもよい。ログファイルは、異常イベントを検出するためにＡＤによって分析され得る。ログ収集については、図１３〜図１５を参照してさらに説明する。ＬＨ６１４は、中央管理のためにログファイルをＡＤＲＳ３２０のＬＲＡＳ３２６に送信し得る。
【０１０１】
Ｖ．ＡＤＲＳの階層型実現の例
図８は、いくつかの実施例に係る階層型ＡＤＲＳで実現される自律型クラウドコンピューティングシステム８００の一例を示す。図３のＡＳＣ３１８および１つ以上のＡＤＲＣがクラウドコンピューティングシステム８００において実現されて階層型ＡＤＲＳを提供することができる。図８における例は、図３〜図７に示されるＡＤＲＳの特徴をさらに詳しく説明している。
【０１０２】
クラウドコンピューティングシステム８００は、クラウドコンピューティングシステム８００のクラウド環境レベルでＡＤＲＣ８０２を含み得る。ＡＤＲＣ８０２は、クラウドコンピューティングシステム８００内の物理ホストコンピューティングシステム８２０および物理ホストコンピューティングシステム８４０などの複数のコンポーネントのための環境コントローラとして動作し得る。ホストシステム８２０およびホストシステム８４０の各々は、それ自体のＡＤＲＣ８２２およびＡＤＲＣ８４２をそれぞれ含む。
【０１０３】
ホストシステム８２０は、ＶＭであるサブコンテナ８２４を含む。コンテナ８２４は、ＪａｖａＶＭ（ＪＶＭ）であるサブコンテナ８２８を含む。コンテナ８２４およびコンテナ８２８の各々は、それ自体のそれぞれのＡＤＲＣ８２６およびＡＤＲＣ８３０を含む。同様に、ホストシステム８４０は、ＶＭであるサブコンテナ８４４を含む。コンテナ８４４は、ＪａｖａＶＭ（ＪＶＭ）であるサブコンテナ８４８を含む。コンテナ８４４およびコンテナ８４８の各々は、それ自体のそれぞれのＡＤＲＣ８４６およびＡＤＲＣ８５０を含む。クラウドコンピューティングシステム８００に示されているＡＤＲＣの各々は、階層型ＡＤＲＳの一部であってもよい。階層型ＡＤＲＳでは、コンポーネント内の各ＡＤＲＣは、異常イベントを特定するためのアクティビティを監視する。ＡＤＲＣ６００を参照して説明したように、ＡＤＲＣは、ＡＤＲＣにおいて検出される異常イベントについてポリシーが定義されるか否かを判断し得る。異常イベントに対処するためのポリシーが定義されないと判断すると、ＡＤＲＣは、存在する場合には親コンポーネントに異常イベントを通信し得る。親コンポーネントのＡＤＲＣが異常イベントに対処するためのポリシーを特定できるまで、異常イベントは、親コンポーネントのＡＤＲＣ、さらには親コンポーネントに至るまで伝搬され得る。異常イベントのイベントデータは、クラウドコンピューティングシステム８００における最高レベルのコンポーネントのＡＤＲＣ８０２に伝搬され得る。最高レベルのコンポーネントは、クラウドコンピューティングシステム８００のクラウド環境レベルにあってもよい。たとえば、ＡＤＲＣ８３０においてポリシーが判断されない場合、ＡＤＲＣ８３０において検出された異常イベントは、コンポーネント８２８の親であるコンポーネント８２４のＡＤＲＣ８２６に通信されてもよい。ＡＤＲＣ８２６においてポリシーが判断されない場合、ＡＤＲＣ８２６は、コンポーネント８２４の親コンポーネントであるコンポーネント８２０のＡＤＲＣ８２２に異常イベントを通信してもよい。ＡＤＲＣ８２２において異常イベントについてのポリシーが判断されない場合、コンポーネント８２０は、クラウドコンピューティングシステム８００のクラウドコンピューティング環境レベルのＡＤＲＣ８０２に異常イベントを通信してもよい。
【０１０４】
クラウドコンピューティングシステム８００内のＡＤＲＣの各々は、それぞれのコンポーネントの各々において異常イベントのアクティビティを監視し得る。ＡＤＲＳのＬＲＡＳを使用して、各々のＡＤＲＣは、異常イベントを含むアクティビティについての情報を得て、またはログ記録し、当該情報は、データストア、たとえば周期的傾向ＤＢ８０４に報告される。以下で説明するように、周期的傾向ＤＢ８０４は、周期的な定義済みの異常に基づいて異常イベントを評価するのに利用され得る。
【０１０５】
データストア８０４は、メモリストレージデバイスまたは他の非一時的なコンピュータ読取可能な記憶媒体などのいずれかのタイプの永続的ストレージデバイスを使用して実現され得る。いくつかの実施例では、ローカルストレージは、１つ以上のデータベース（たとえば、ドキュメントデータベース、リレーショナルデータベースまたは他のタイプのデータベース）、１つ以上のファイルストア、１つ以上のファイルシステム、またはそれらの組み合わせを含み得る、または実現し得る。メモリおよびさらなるストレージは全て、コンピュータ読取可能な記憶媒体の例である。たとえば、コンピュータ読取可能な記憶媒体は、コンピュータ読取可能な命令、データ構造、プログラムモジュールまたは他のデータなどの情報の格納のためのいずれかの方法または技術で実現される揮発性または不揮発性のリムーバブルまたは非リムーバブルメディアを含み得る。本明細書に開示されている技術に従ってデータを格納するためにより多くのデータストアが実現されてもよく、またはより少ないデータストアが実現されてもよい。
【０１０６】
ＶＩ．異常の分類
図９は、いくつかの実施例に係る階層型異常分類構造９００を示す。異常分類構造９００は、どのようにデータが格納されるか、どのデータが格納されるか、および／または、どこにデータが格納されるかに応じてさまざまな方法で編成される１つ以上のデータ構造を使用して実現されてもよい。データ構造の各々は特定のデータを含むものとして示されているが、データを格納するためにより多くのデータ構造が実現されてもよく、またはより少ないデータ構造が実現されてもよい。データ構造は、他のデータ構造への参照を含み得る。さまざまなセキュリティアーチファクトの格納を管理するために、データ構造の各々のインスタンスが作成され得る。データ構造は、１つ以上のタイプのデータ構造を使用して実現されてもよく、当該１つ以上のタイプのデータ構造は、連結リスト、アレイ、キュー、ハッシュテーブル、マップ、レコード、グラフ、または他のタイプのデータ構造を含むが、それらに限定されるものではない。データ構造の各々は、ＡＤＲＳ３２０への入力に基づいて、宣言型の態様で定義され得る。
【０１０７】
性能、スケーラビリティ、可用性、リソース消費およびエラー特性が各々恐らく異なっている多くのサービスインスタンスは、サービスタイプから作成することができる。サービスを定義する各メトリック（または変数）の値は、最小値（ｍｉｎ）尺度と最大値（ｍａｘ）尺度とｍａｘソフト限界（ＳＬ）尺度とを含む尺度を使用して定義することができる。管理者は、正常なシステム挙動を定義する各々のキーメトリックについてｍｉｎ、ｍａｘおよびｍａｘ  ＳＬを指定し得て、当該キーメトリックは、サービスの応答時間、サービスの可用性、サービスに割り当てられるべきリソース、システム負荷、および他のメトリックに対する期待値を含む。管理者は、これらのメトリックに関する範囲を指定して、サービスのサービスレベル合意（ＳＬＡ）を実施し得る。全てのメトリックが、サービスインスタンスおよびサービスインスタンスが実行されているコンテナについて指定されたｍｉｎおよびｍａｘ  ＳＬの範囲内である場合、サービスインスタンスは正常であると考えられる。メトリックのうちのいずれかがｍｉｎを下回るかまたはｍａｘ  ＳＬを上回る場合、サービスは異常状態であると考えることができ、リアルタイムの異常解決が起動されることになる。エラー特性の変数は、特定のタイプの許容エラー率を定義する。
【０１０８】
異常は、構造９００を使用してさまざまなタイプとして定義することができる。異常９０２は、定義済みの異常９０４または未定義の異常９０６のうちのいずれか１つとして定義することができる。各々の異常は、範囲（「異常範囲」）によって定義することができ、当該範囲に基づいて異常イベントが検出される。未定義の異常９０６は、定義されておらず、機械学習または統計的方法などの技術によって発見され得る異常である。ＬＲＡＳ３２６は、メトリックおよびログストリームをオフラインで分析して未定義の異常を発見するように構成され得る。未定義の異常は、重要業績指標またはログ統計に関する範囲によって定義されない異常を含み得る。
【０１０９】
定義済みの異常９０４は、２つのカテゴリ、すなわちユーザ定義の異常９０８またはシステム定義のもしくはシステム推測の異常９１０、に分類することができる。定義済みの異常９０４は、監視すべき任意のメトリックに関する範囲に基づいて定義され、固定された範囲または周期的範囲のいずれかである範囲によって定義され得る。アプリケーション管理者は、ＳＣＤＭＳ３２２を使用して、ユーザ定義の異常について固定された範囲または周期的範囲を定義して、サービスレベル合意（ＳＬＡ）のサービス品質、リソース使用および他の制約を監視および実施し得る。また、システム管理者は、とりわけリソース使用、負荷スパイク、悪意ある使用およびコンポーネント障害を監視するために、たとえばさらなるメトリックを定義し得る。
【０１１０】
定義済みの異常９０４は、ＱｏＳ（たとえば、サービスの応答時間）を実施するようにユーザ（たとえば、管理者）によって定義され得る。ユーザ定義の異常を構成するために、固定された範囲が使用されてもよい。固定された範囲は、５つのパラメータによって５つの要素からなるものとして指定することができ、当該５つの要素は、（１）通知がメトリック値の変化に利用できない場合にのみ使用されるメトリック値のポーリング間隔（ｐｉ）と、（２）メトリック値に求められる最小値である最小値尺度と、（３）最大値に対するソフト限界である最大ＳＬと、（４）ハード最大限界である最大値尺度と、（５）イベントが生成される前の異常な読取値の連続読取値の最小数である最小連続読取値（ｍｃｒ）とを含む。異常検出のために定義されたメトリックの全ての値がｍｉｎおよびｍａｘ  ＳＬ値の範囲内である場合、システムは正常、すなわち異常なしであると考えることができる。これらのメトリックのうちのいずれかがこの範囲を超えると、システムは異常状態であると考えられる。メトリック値が異常なｍｃｒ連続読取値である場合、異常イベントが生成され得る。
【０１１１】
システム管理者などのユーザは、範囲がシステムによって推測される指標メトリックを監視して、ＱｏＳメトリックを範囲（たとえば、ＣＰＵ負荷）内に維持し得る。また、システム管理者は、コンテナ（コンポーネントのサブタイプ）について一組のメトリックを定義し、異常を回避するためにシステムにそれらの値の周期的範囲を自動的に計算させ得る。この種類の異常は、システム定義の異常９１０と称される。システム定義の異常９１０の周期的範囲は、ＬＲＡＳ３２６によって、毎日一時間ごとに、各々のコンテナについて、各々のメトリックについて、計算することができる。たとえば、特定の差し迫った異常を検出するために、コンテナで実行されるプロセスもしくはスレッドの数、またはコンテナのＣＰＵ負荷を監視する必要があるかもしれないが、システム管理者は、それらの適切な範囲を判断することはできない。これらの例では、これらのメトリックは、システム推測の異常９１０で使用され、システムは、履歴データの傾向に基づいてそれらの周期的範囲を計算することになる。
【０１１２】
周期的範囲は、ある期間にわたる固定された範囲として定義することができる。周期的範囲の異常は、５つのパラメータによって７つの要素からなるものとして指定することができ、当該７つの要素は、ポーリング間隔（ｐｉ）と、メトリック値に求められる最小値である最小値尺度と、最大値に対するソフト限界である最大ＳＬと、ハード最大限界である最大値尺度と、連続読取値の数として指定される期間（ｄ）と、範囲が有効である開始時刻（ｓｔ）および終了時刻（ｅｔ）とを含む。ｓｔおよびｅｔは、ある週のある日の開始に対するものとして指定することができる。この種類の範囲は、一般に、ユーザ定義の異常についてのメトリックおよびメトリック値の傾向に関する履歴データから範囲が計算される、システム推測の異常で使用される。システム推測の異常では、重要業績指標およびログエントリに関する統計などの指標メトリックに関する傾向および周期的変動が、ユーザ定義の異常によって定義される正常なシステム挙動を使用して計算される（たとえば、特定の種類の例外の平均数は、一定の時間枠において一定数を超えるべきではない）。ログファイルの時系列データを分析して、システム推測の異常の周期的範囲を計算する際、サービスについてのユーザ定義の異常が正常から異常になるまたは異常から正常になる時間間隔、サービスの直接先行するコンポーネントおよび後続のコンポーネントにおける関連するログファイル内の当該間隔でのメトリック値およびログエントリに焦点を合わせて、周期的範囲を計算する。
【０１１３】
ＶＩＩ．定義済みの異常の検出のための範囲
ここで図１０を参照して、図１０は、定義済みの異常の範囲を示すブロック図１０００である。クラウドコンピューティングシステムにおけるサービスまたはオペレーションのメトリック値は、５つの要素からなるパラメータによって固定された範囲として定義される場合もあれば、７つの要素からなるパラメータによって周期的範囲として定義される場合もある。どちらの範囲のパラメータも、ｍｉｎ尺度１００２と、ｍａｘ尺度１００６と、ＳＬ１００４（たとえば、ｍａｘ  ＳＬ）とを含み得る。メトリックは、メトリックの尺度がＳＬ閾値１００４を満たす値１０１４である場合に異常状態を示すものとして特定され得て、そのため、メトリックの値は、ＳＬおよびｍａｘの範囲内になる。異常検出器は、メトリックの値が最小値１００２を下回るもしくはＳＬを上回る低い値１０１０である場合、または、メトリックの値がＳＬ１００４であるかもしくはそれを上回るがｍａｘ１００６未満である高い値１０１４である場合に発生するものとして異常イベントを特定し得る。言い換えれば、メトリック値は、最小値１００２であるかもしくはそれを上回りＳＬ１００４未満である場合に、正常範囲１０１２の範囲内の正常値（たとえば、異常なし）である。メトリックの値は、メトリックの値１０１６がｍａｘ１００６を上回る場合に、異常を超えて問題のある状態を示し得る。問題のある状態が検出されると、問題を解決するために定義されたポリシーによってアクションが講じられ得る。
【０１１４】
ＶＩＩＩ．異常検出および解決のためのオペレーション
図１１は、いくつかの実施例に係る図３のＡＳＣ３１８によって自律型クラウドコンピューティングシステム（たとえば、クラウドインフラストラクチャシステム１００）において実行されるオペレーションのブロック図１１００を示す。ステップ１１３２（ステップ１）において、ユーザ（たとえば、デプロイヤ１１３０）は、クラウドインフラストラクチャシステム１００においてサービスを作成するための１つ以上のアセンブリを選択する。ＳＣＤＭＳ３２２は、アセンブリを定義することによってサービスを構成するように、ユーザによって操作されるクライアントシステムに対して１つ以上のインターフェイスを提供し得る。インターフェイスを介して、ユーザは、アセンブリをデプロイしてサービスをインスタンス化することを要求し得る。ステップ１１３２において、ユーザは、クラウドインフラストラクチャシステム１００によって提供されるサービスについてのＳＬＡ合意のＱｏＳに従ったアセンブリにおける固定された範囲または周期的範囲を含む変数の値を提供し得る。
【０１１５】
ステップ１１３４（ステップ２）において、ＳＣＤＭＳ３２２は、１つ以上のコンポーネントタイプを作成して（たとえば、１つ以上のコンポーネントタイプのインスタンスを作成して）、コンポーネントを作成して、サービスを確立し得る。ＳＣＭＤＳ３２２は、サービスのためのコンポーネントを作成するようにＣＣＭＳ３２４に要求し得る。１つ以上のＡＤＲＣ（サブシステム）が作成され、デプロイされ得る。各コンポーネントは、ＡＤＲＣサブシステムを含み得る。ＣＣＭＳ３２４は、新たに作成されたコンテナにＡＤＲＣサブシステムおよびサービスのコンポーネントをデプロイし得る。たとえば、ＡＤＲＣ３５４は、クラウドインフラストラクチャシステム１００のクラウド環境レベルで作成され、デプロイされてもよい。コンテナ１１０２および１１２０の各々は、ＡＤＲＣ１１０４およびＡＤＲＣ１１２４をそれぞれ含み得る。コンテナ１１０４におけるコンテナ１１０６は、ＡＤＲＣ１１０８を含み得る。コンテナ１１２４におけるコンテナ１１２６は、ＡＤＲＣ１１２８を含み得る。
【０１１６】
ＳＣＤＭＳ３２４は、各コンポーネントにそれ自体を構成するように要求し得る。各コンポーネントは、そのホームディレクトリを作成し、必要なソフトウェアをインストールし、構成パラメータを設定し、デプロイされたコンポーネント（インスタンス）、ログおよびメトリックストリームとのそれらの関係、ならびにコンポーネントの上流および下流制御フローにおけるコンポーネントでコンポーネントリポジトリを更新し得る。ＣＣＭＳ３２４は、クラウドインフラストラクチャシステム１００の現在および過去の構成のデータストア（たとえば、構成リポジトリ）を含み得る。構成リポジトリは、コンポーネントモデルを使用して、クラウド環境のコンポーネント間の関係ならびにそれらが生成するログおよびメトリックストリームを記述することができる。
【０１１７】
ステップ１１３６（ステップ３）において、サービスが使用されているとき、ＡＤＲＣの各々におけるログハーベスタは、設定された間隔で、ライブログおよび回転されたログから、ログおよびメトリックストリームをコンポーネントから収集して、それらをＬＲＡＳ３２６に送信し得る。
【０１１８】
ステップ１１３８（ステップ４）において、ＬＡＲＳ３２６は、アルゴリズム（たとえば、属性関連付けアルゴリズム）を使用して、ユーザ定義のメトリックに影響を及ぼすメトリックを見つけ得る。次いで、ＬＲＡＳ３２６は、構成リポジトリに格納された構成データを利用して、ログおよびメトリックストリームに対して時系列分析を実行し得る。システム推測の異常の周期的範囲は、このステップで計算される。
【０１１９】
ステップ１１４０（ステップ５）において、周期的範囲および他の情報が適切なコンテナのＡＤＲＣに押し出され、そこでＡＤの範囲が更新される。ステップ１１４２（ステップ６）において、ユーザ１１５０（たとえば、管理者）によって、異常および属性関連付けが分析され得て、ポリシーにおけるルールが修正され得る。ステップ１１４４（ステップ７）において、コンテナ内のＡＤＲＣにおける未解決の異常イベントは、環境レベルＡＤＲＣ３５４に到達するまで、親コンテナ内の高レベルのＡＤＲＣに至るまで伝搬される。異常に対処するためのポリシーを突き止めることができない場合、異常イベントは未解決であり得る。ＡＤＲＣ３５４は、未解決の異常についてユーザに通知するためにユーザに警告を発行し得る。
【０１２０】
ステップ１１４６（ステップ８）において、ＡＤＲＣ３５４は、構成リポジトリにおいて構成の変更を更新するように操作され得る。次いで、オペレーションチームは、未対処の異常があるかどうかシステムを監視し得る。未対処の異常の各々について、チームは、異常に対処するためにどのさらなるメトリックを監視すべきであるかおよび／またはどのルールを開発または修正する必要があるかに対応して決定する必要がある。
【０１２１】
ＩＸ．ログファイルフローの大まかな概要
図１２は、いくつかの実施例に係るログファイルフロー１２００の大まかな図を示す。クラウドシステムは、多数のログファイル、診断データおよびメトリックを生成する。ログファイルは、クラウドインフラストラクチャシステム１００内の１つ以上のコンポーネント（たとえば、ソースコンポーネント１２０２）によって生成され得る。ログファイルに対応するメタデータは、ログファイルとともに、データセンタまたはセキュリティゾーンに特有のデータストア（たとえば、ログアーカイブ１２０４）に押し出される。
【０１２２】
ログファイルは、性能メトリックからログイン試行の失敗までのさまざまなデータを含む。また、ログファイルは、フォレンジック分析を行うセキュリティ専門家および弁護士からホスティング環境のトラブルを解決するサポートエンジニアおよびアプリケーションをデバッグする製品開発者までの多様なユーザグループによって使用される。どのクラウドサービスプロバイダも、ログファイル保存およびアクセスを規定するいくつかのポリシーを有している。一般に、ログファイルは、アクセスおよび保存ポリシーが実施されるログアーカイブ１２０４に、内容が変更されない状態で移される。権限が付与されたスタッフには、関連するログファイルをアーカイブ内でサーチする権限が与えられ、このようなサーチは、手動でまたは単純なＯＳスクリプトを介して、通常はオンラインで行われ、メタデータベースのサーチおよびキーワードベースのサーチを含み得る。
【０１２３】
最近になって、ログファイル使用の新たなパターンが出現してきている。当該パターンは一般にログ分析と称される。その目的は、長期間にわたって、多数のシステムにわたって多数のログタイプの多数のログファイルに含まれる潜在情報を発見することである。より具体的には、ログ分析は、ログファイル内にデータを生成したシステム挙動を理解し、差し迫った問題を予測するためのモデルを開発し、異常を監視し、膨大な同様のシステムの長期挙動に基づいて最適なリソース使用のためにフィードバックを提供することを目指している。このパターンは、機密データが１つ以上のデータマーカ（１２０６）によってマスキングされた後に多くのログアーカイブから収集される膨大なログファイルに最良に適用される。ログ分析に使用されるデータストアは、ログリザーバと称される。表１に示されるように、ログリザーバの特性は、ログアーカイブの特性とは異なっている。
【０１２４】
【表１】
0006731424.tif 000002
【０１２５】
コンテナ１２０２で実行されるサービスは、それらのログエントリをログファイルに書き込み、ログファイルは、定期的に、たとえば１日に１回、回転される。ソースマシンで実行されるログ収集スクリプトは、回転されたログファイルを定期的に、またはライブログでは一定の間隔で（たとえば、１時間ごとに）収集し、それらに対して関連するメタデータを添付して、それらをログアーカイブ１２０４に送信し得る。次いで、データマスカ１２０６は、ログアーカイブからデータを読み取って、機密データをマスキングし、それをログリザーバ１２０８に送信する。データマスカ１２０６は、ログタイプに特有の処理パイプラインを有し、当該処理パイプラインは、ログエントリにおけるＰＩＩデータをログリザーバ１２０８にロードする前に、それが実行する機能の中で特に、それらをハッシュコードと置き換えるか、またはそれらをマスキングする。
【０１２６】
いくつかの実施例では、データセンタは、１つ以上のセキュリティゾーンを有し得る。セキュリティゾーンで生成される全てのログファイルは、データホーダを介してログアーカイブ１２０４（たとえば、局所データハブ）にアーカイブされ得る。データマスカ１２０６は、ＰＩＩおよび機密データをマスキングし、マスキングされたログファイルをログリザーバ１２０８（たとえば、中央ハブ）に送信し得る。データマスカ１２０６は、アーカイブからログファイルを読み取ってそれらをマスキングすることによって、マスキングされたログファイルをログリザーバ１２０４に送信し得る。
【０１２７】
コンテナ内で実行されるアプリケーションは、ログおよびメトリックストリームを生成し（一組のログファイルにし）得る。いくつかのログファイルは、リアルタイムの監視のために、ローカル異常リゾルバを呼び出すように構成された（ＥＬＫスタックのための）ログスタッシュ・フォワーダまたはＨｅｋａなどのリアルタイムストリームコレクタによって処理される。ＥＬＫスタックは、ログスタッシュ処理およびフィルタリングノードを使用し、次いで索引付けのためにデータをＥｌａｓｔｉｃｓｅａｒｃｈクラスタに転送する。Ｅｌａｓｔｉｃｓｅａｒｃｈに加えて、Ｋｉｂａｎａを使用してウェブベースのサーチＵＩおよびレンダリングを行ってもよい。１つ以上のリアルタイム監視システムがあってもよい。各々のログスタッシュ・フォワーダは、１つのこのようなシステムにのみログを転送することができる。Ｋａｆｋａが使用される場合、Ｈｅｋａは、１つのトピックまたはキューにのみ異常を発行することになる。
【０１２８】
いくつかの実施例では、ログファイルは、ＨＴＴＰＳを使用してデータホーダに押し出されて、データセンタまたはゾーンに特有のアーカイブ（現時点ではＯＣＬＡのためのＺＦＳおよび局所ハブのためのＨａｄｏｏｐ）に格納される。Ｍａｐ−Ｒｅｄｕｃｅ  ＪａｖａおよびＲプログラムを使用して、これらのログファイルがプログラム的に分析される。いくつかのログファイルが特定の時間間隔にわたってオラクルデータベースにロードされ、オラクルデータウェアハウスおよびビジネスインテリジェンスツールを使用して、手動分析がサポートされる。中央ハブ（リザーバ１２０４）を使用して傾向の計算および予測分析も行うことができる。アーカイブおよびデータハブ（リザーバ）のためにＥＬＫおよびＳｏｌｒ＋Ｂａｎａｎａスタックもサポートされる。
【０１２９】
ＬＲＡＳ３２６は、ＣＣＭＳ３２４コンポーネントモデルを使用して、システムによって提供されるサービスの処理フローに関して、アプリケーションおよびシステムコンポーネントによって生成されるログおよびメトリックストリーム間の関係を理解することができる。ＬＲＡＳ３２６は、アルゴリズム（たとえば、属性関連付けアルゴリズム）を使用して、恐らくユーザ定義のメトリックに影響を及ぼしている指標メトリックを見つけることができる。ユーザ定義の異常によって定義される正常なシステム挙動を使用して、重要業績指標（ＫＰＩ）およびログエントリに関する統計などの指標メトリックで予想される傾向および周期的変動を計算し（たとえば、特定の種類の例外の平均数は、一定の時間枠において一定数を超えるべきではない）、当該傾向および周期的変動は、システム推測の異常について定義される。ＬＲＡＳ３２６は、機械学習技術を使用して、未定義の異常、すなわちＫＰＩまたはログ統計の範囲によって定義されない異常を検出することができる。ＬＲＡＳ３２６は、将来の異常を予測することができる。
【０１３０】
メトリックおよびログストリームはオフラインで分析され、システム定義の異常の周期的範囲が推測され、未定義の異常が発見される。たとえば、システム管理者は、コンテナで実行されるスレッドの数を監視し、それが正常値を超えると異常イベントを発生させたいと思うかもしれない。システム管理者は、このメトリックの範囲（ｍｉｎ、ｍａｘおよびｍａｘ  ＳＬ）を指定する必要はない。値の周期的変動は、ＬＲＡＳ３２６によってメトリックおよびログストリームから計算され、２４×７×３の表としてコンテナに送信され得て、当該表は、時間別に分類された１週間のｍｉｎ、ｍａｘおよびｍａｘ  ＳＬを含む。コンテナで実行されるＡＤＮＳコンポーネントは、この情報を使用して異常検出のためにスレッドの数を監視することができる。
【０１３１】
まず、ログおよびメトリックファイル内の時系列データが、４つのカテゴリ、すなわちユーザ定義の異常に関連付けられるメトリック、システム推測の異常に関連付けられるメトリック、一般に重要であると考えられるメトリック、およびエラー、に分類される。次いで、各カテゴリにおけるシリーズは、Ｒプログラムを使用して、一定のまたは不規則なサンプリング間隔で傾向および周期的要因に分解される。次いで、これらをユーザ定義の異常に関連する時系列メトリックと比較して、異常の原因を理解し、これらの異常を回避するために他のメトリックおよびエラーの周期的範囲を推測する。これらの周期的範囲は、それぞれのコンテナにフィードバックされて、システムのリアルタイムの監視で使用される。
【０１３２】
時系列データを分析して、システム推測の異常および他のメトリックの周期的範囲を計算する際、ＬＲＡＳ３２６は、サービスについてのユーザ定義の異常が正常から異常になるまたは異常から正常になる時間間隔に焦点を合わせ、サービスの直接先行するコンポーネントおよび後続のコンポーネントにおける関連するログファイル内の当該間隔でのメトリック値およびログエントリに焦点を合わせて、周期的範囲を計算し得る。
【０１３３】
アーカイブされたデータから計算されるコンテナに特有の傾向および周期性は、コンテナに送られる。このデータは、Ｈｅｋａフィルタによって使用され、当該傾向および周期性に基づいて、いずれかのメトリックが正常の範囲外であるか否かがテストされる。メトリック値が異常であると判断すると、各コンテナで実行されるＨｅｋａデーモンは、コンテナ内のＡＤＲＣのイベントディスパッチャを呼び出す。イベントディスパッチャは、異常を解決するための適切なポリシーを見つけることができない場合には、異常を解決するように親コンテナに知らせることになる。親コンテナは、異常を解決できない場合には、メトリックのベクトル全体をＫａｆｋａトピックに発行することになる。Ｓａｍｚａを使用してそれらを検索して、異常検出コードによるさらなる分析のためにそれらをデータストア（たとえば、ＲＲＤ）に格納してもよい。
【０１３４】
Ｘ．異常検出および解決のためのプロセス
図１３および図１４は、本発明のいくつかの実施例に係る異常検出および解決のためのプロセスを示すフローチャートを提供する。個々の実施例は、フローチャート、フロー図、データフロー図、構造図またはブロック図として示されるプロセスとして説明することができる。フローチャートはオペレーションをシーケンシャルなプロセスとして説明し得るが、オペレーションの多くは並列にまたは同時に実行されてもよい。また、オペレーションの順序は並べ替えられてもよい。プロセスは、そのオペレーションが完了すると終了するが、図に含まれないさらなるステップを有していてもよい。プロセスは、方法、機能、手順、サブルーチン、サブプログラムなどに対応し得る。プロセスが機能に対応する場合、その終了は、呼び出し関数またはメイン関数への関数の戻りに対応し得る。
【０１３５】
図１３および図１４に示されるプロセスは、１つ以上の処理ユニット（たとえば、プロセッサ、コア）によって実行されるソフトウェア（たとえば、コード、命令、プログラム）で実行されてもよく、ハードウェアで実行されてもよく、またはそれらの組み合わせで実行されてもよい。ソフトウェアは、メモリ（たとえば、メモリデバイス、非一時的なコンピュータ読取可能な記憶媒体）に格納され得る。たとえば、図３のＡＳＣ３１８の全てまたは一部および／または１つ以上のＡＤＲＣは、図１３および図１４のいずれかを参照して説明するプロセスを実行し得る。プロセスはいずれもサービスとして実行され得る。サービスは、クライアントシステムおよびオブジェクトへのアクセスを提供するサービスプロバイダに提供され得る。
【０１３６】
図１３および図１４における特定の一連の処理ステップは、限定的であるよう意図されるものではない。ステップの他のシーケンスも代替的な実施例に従って実行されてもよい。たとえば、本発明の代替的な実施例は、上記のステップを異なる順序で実行してもよい。さらに、図１３および図１４に示される個々のステップは、個々のステップに適切であるようにさまざまなシーケンスで実行され得る複数のサブステップを含んでいてもよい。さらに、特定のアプリケーションに従ってさらなるステップが追加または除去されてもよい。図１３および図１４に示される処理は、単一のアプリケーションに関するものであるが、このような処理は、いくつかのアプリケーションについて実行されてもよい。図１３および図１４に示される処理は、単一の異常イベントに関するものであるが、このような処理は、いくつかの異常イベントについて実行されてもよく、当該いくつかの異常イベントのうちのいくつかまたは全ては関連していてもよい。当業者は、多くの変更例、変形例および代替例を認識するであろう。
【０１３７】
図１３において、フローチャートは、コンピュータシステムによって提供されるサービスのオペレーションに関連する異常の解決のためのプロセス１３００を示す。コンピュータシステムは、クラウドコンピュータシステム（たとえば、クラウドインフラストラクチャシステム１００）またはエンタープライズコンピュータシステムであり得る。サービスを提供するために複数のコンポーネントがデプロイされ得る。コンポーネントは、子コンポーネントとして別のコンポーネント内で実現され得る。各コンポーネントは、コンピュータシステムにおいて実行され得る。コンポーネントは、コンポーネント上で検出された異常の解決のためのＡＤＲＣを含むように構成され得る。
【０１３８】
プロセス１３００は、コンピュータシステムによって提供されるサービスに関連するメトリックの異常範囲を定義する一組の値を求めることによってステップ１３０２から開始し得る。コンピュータシステムで実現されるＡＤＲＳは、異常範囲を決定し得る。一組の値は、ユーザ定義のものであり得る。値は、インターフェイスまたは宣言型ファイルを介して受け取られた入力に基づいて定義され得る。異常範囲は、ユーザ定義の異常については固定されたものであり得て、またはシステム推測の異常については周期的範囲であり得る。メトリックは、サービスのＱｏＳについて監視されるいくつかのメトリックのうちの１つであり得る。異常は、図９および図１０の異常分類システムに基づいて定義され得る。
【０１３９】
サービスは、コンピュータシステム内のコンポーネントによって確立され得る。コンポーネントは、コンピュータシステムで実行されるコンテナを含み得る。コンテナは、子コンテナとして別のコンテナにおいて実現され得る。ステップ１３０４において、ＡＤＲＣを含むように各コンポーネントを構成し得る。ＡＳＣは、各コンポーネントにＡＤＲＣを構成し得る。
【０１４０】
ステップ１３０６において、サービスのオペレーションに関連する異常イベントを、サービスのために確立されたコンポーネントにおいて検出し得る。異常イベントは、コンポーネントに構成されたＡＤＲＣによって検出され得る。異常イベントは、メトリックの値が異常範囲を満たさないことに基づいて検出され得る。たとえば、図１０では、メトリックの値は、最小値１００２未満の値１０１０である場合、またはソフト限界最大値以上の値１０１４である場合には、異常範囲を満たし得ない。異常イベントは、ポーリング間隔中および最大連続読取値の発生中に異常範囲が満たされる場合に生成され得る。異常イベントは、異常分類システムを用いて定義される異常の全てのパラメータを満たしたことに基づいて検出され得る。
【０１４１】
ステップ１３０８において、異常を解決するためのポリシーを特定する。当該ポリシーは、コンポーネント内のＡＤＲＣによって特定され得る。異常によって満たされる１つ以上のルールを有する１つ以上のポリシーを特定するためにポリシーストアがサーチされ得る。ステップ１３１０において、ポリシーにおけるルールが異常によって満たされることを判断し得る。当該判断は、コンポーネント内のＡＤＲＣによってなされ得る。ポリシーは、異常イベントが検出されるコンポーネントにおいて異常を解決するための１つ以上の修正アクションを示し得る。ステップ１３１２において、ルールが満たされたことに基づいて、ポリシーで特定される修正アクションを起動し得る。
【０１４２】
いくつかの実施例では、コンポーネントにおいて異常を解決するためのポリシーが特定されなくてもよい。このような場合、コンポーネントのＡＤＲＣは、コンポーネントを含む親コンポーネント（存在する場合）に異常イベントを通信し得る。図１４を参照して説明する実施例などのいくつかの実施例では、親コンポーネントは、異常を解決するためのポリシーを特定することによって異常を解決し得る。
【０１４３】
プロセス１３００は、ステップ１３１４で終了する。
図１４は、コンピュータシステムにおけるサービスのために確立されたコンポーネントの階層内のコンポーネントに異常を伝搬するためのプロセス１４００のフローチャートを示す。プロセス１４００は、コンピュータシステムによって提供されるサービスに関連するメトリックの異常範囲を定義する一組の値を求めることによってステップ１４０２から開始し得る。コンピュータシステムで実現されるＡＤＲＳは、異常範囲を決定し得る。一組の値は、ユーザ定義のものであり得る。値は、インターフェイスまたは宣言型ファイルを介して受け取られた入力に基づいて定義され得る。異常範囲は、ユーザ定義の異常については固定されたものであり得て、またはシステム推測の異常については周期的範囲であり得る。メトリックは、サービスのＱｏＳについて監視されるいくつかのメトリックのうちの１つであり得る。異常は、図９および図１０の異常分類システムに基づいて定義され得る。
【０１４４】
サービスは、コンピュータシステム内のコンポーネントによって確立され得る。コンポーネントは、コンピュータシステムで実行されるコンテナを含み得る。コンテナは、子コンテナとして別のコンテナにおいて実現され得る。ステップ１４０４において、ＡＤＲＣを含むように各コンポーネントを構成し得る。ＡＳＣは、各コンポーネントにＡＤＲＣを構成し得る。
【０１４５】
ステップ１４０６において、サービスのオペレーションに関連する異常イベントを、サービスのために確立されたコンポーネントにおいて検出し得る。異常イベントは、コンポーネントに構成されたＡＤＲＣによって検出され得る。異常イベントは、メトリックの値が異常範囲を満たさないことに基づいて検出され得る。異常イベントは、異常分類システムを用いて定義される異常の全てのパラメータを満たしたことに基づいて検出され得る。
【０１４６】
ステップ１４０８において、コンポーネント内のＡＤＲＣがコンポーネントにおいて異常を解決するためのポリシーを有しているか否かを判断する。ステップ１４１０において、コンポーネント内のＡＤＲＣが異常を解決するためのポリシーを有していると判断したことに基づいて、ＡＤＲＣは、ポリシーに基づいて、異常を解決するための修正アクションを起動し得る。ステップ１４１２において、コンポーネント内のＡＤＲＣが異常を解決するためのポリシーを持たないと判断したことに基づいて、ＡＤＲＣは、異常についてコンポーネントの親である親コンポーネントのＡＤＲＣに通知し得る。ＡＤＲＣは、コンポーネントによって異常を解決できないことを親コンポーネントのＡＤＲＣに通知し得る。プロセス１４００は、ステップ１４１２からステップ１４１８における終了まで進み得る。
【０１４７】
ステップ１４１４において、親コンポーネントのＡＤＲＣは、それが親コンポーネントにおいて異常を解決するためのポリシーを特定し得る。ステップ１４１６において、親コンポーネントのＡＤＲＣは、親コンポーネントにおいて異常を解決するための、ポリシーで特定される修正アクションを起動し得る。プロセス１４００は、ステップ１４１６からステップ１４１８における終了まで進み得る。
【０１４８】
いくつかの実施例では、親コンポーネントのＡＤＲＣは、親コンポーネントにおいて異常を解決するためのポリシーを持っていないかもしれない。親コンポーネントは、親コンポーネントの親コンポーネントなどのより高いレベルのコンポーネントに異常イベントについてのデータを伝搬し得る。親コンポーネントのＡＤＲＣは、異常についてその親コンポーネントに通知し得る。より高いレベルの親コンポーネントのＡＤＲＣは、ＡＤＲＣがより高いレベルの親コンポーネントにおいて異常を解決するためのポリシーを特定できる限り、異常を解決するための修正アクションを起動し得る。
【０１４９】
ＸＩ．コンピューティング環境
図１５は、実施例を実現するための分散型システム１５００の簡略図を示す。示されている実施例では、分散型システム１５００は、１つ以上のクライアントコンピューティングデバイス１５０２，１５０４，１５０６および１５０８を含み、それらは、１つ以上のネットワーク１５１０を介してウェブブラウザ、所有権付きクライアント（たとえばオラクルフォームズ（Oracle Forms））などのクライアントアプリケーションを実行および動作させるよう構成される。サーバ１５１２は、リモートクライアントコンピューティングデバイス１５０２，１５０４，１５０６および１５０８とネットワーク１５１０を介して通信可能に結合されてもよい。
【０１５０】
さまざまな実施例では、サーバ１５１２は、セキュリティアーチファクトを管理することができるサービスおよびアプリケーションなどの１つ以上のサービスまたはソフトウェアアプリケーションを実行するように適合されてもよい。特定の実施例では、サーバ１５１２は、非仮想および仮想環境を含むことができる他のサービスまたはソフトウェアアプリケーションも提供してもよい。いくつかの実施例では、これらのサービスは、ウェブに基づくサービスもしくはクラウドサービスとして、またはソフトウェア・アズ・ア・サービス（ＳａａＳ）モデルの下で、クライアントコンピューティングデバイス１５０２，１５０４，１５０６および／または１５０８のユーザに対して提供されてもよい。クライアントコンピューティングデバイス１５０２，１５０４，１５０６および／または１５０８を動作させるユーザは、次いで、１つ以上のクライアントアプリケーションを利用してサーバ１５１２と対話して、これらのコンポーネントによって提供されるサービスを利用してもよい。
【０１５１】
図１５に示される構成では、システム１５００のソフトウェアコンポーネント１５１８，１５２０および１５２２は、サーバ１５１２上で実現されるものとして示されている。他の実施例では、システム１５００のコンポーネントのうちの１つ以上および／またはこれらのコンポーネントによって提供されるサービスは、クライアントコンピューティングデバイス１５０２，１５０４，１５０６および／または１５０８のうちの１つ以上によって実現されてもよい。クライアントコンピューティングデバイスを動作させるユーザは、次いで、１つ以上のクライアントアプリケーションを利用して、これらのコンポーネントによって提供されるサービスを用いてもよい。これらのコンポーネントは、ハードウェア、ファームウェア、ソフトウェア、またはそれらの組み合わせで実現されてもよい。分散型システム１５００とは異なってもよいさまざまな異なるシステム構成が可能であることが理解されるべきである。図１５に示される実施例は、したがって、実施例のシステムを実現するための分散型システムの一例であり、限定的であるよう意図されるものではない。
【０１５２】
クライアントコンピューティングデバイス１５０２，１５０４，１５０６および／または１５０８は、さまざまなタイプのコンピューティングシステムを含んでもよい。たとえば、クライアントコンピューティングデバイスは、携帯可能な手持ち式のデバイス（たとえばｉＰｈｏｎｅ（登録商標）、セルラー電話、ｉＰａｄ（登録商標）、コンピューティングタブレット、携帯情報端末（personal digital assistant：ＰＤＡ））またはウェアラブルデバイス（たとえばＧｏｏｇｌｅ  Ｇｌａｓｓ（登録商標）頭部装着型ディスプレイ）を含んでもよく、Ｍｉｃｒｏｓｏｆｔ  Ｗｉｎｄｏｗｓ  Ｍｏｂｉｌｅ（登録商標）などのソフトウェア、および／もしくは、ｉＯＳ、Ｗｉｎｄｏｗｓ  Ｐｈｏｎｅ、Ａｎｄｒｏｉｄ、ＢｌａｃｋＢｅｒｒｙ  １０、Ｐａｌｍ  ＯＳなどのさまざまなモバイルオペレーティングシステムを実行する。デバイスは、さまざまなインターネット関連アプリ、電子メール、ショートメッセージサービス（short message service：ＳＭＳ）アプリケーションなどのさまざまなアプリケーションをサポートしてもよく、さまざまな他の通信プロトコルを使用してもよい。クライアントコンピューティングデバイスは、汎用パーソナルコンピュータも含んでもよく、一例として、Ｍｉｃｒｏｓｏｆｔ  Ｗｉｎｄｏｗｓ（登録商標）、Ａｐｐｌｅ  Ｍａｃｉｎｔｏｓｈ（登録商標）および／またはＬｉｎｕｘ（登録商標）オペレーティングシステムのさまざまなバージョンを実行するパーソナルコンピュータおよび／またはラップトップコンピュータを含む。クライアントコンピューティングデバイスは、たとえばＧｏｏｇｌｅ  Ｃｈｒｏｍｅ  ＯＳなどのさまざまなＧＮＵ／Ｌｉｎｕｘオペレーティングシステムを限定を伴うことなく含む、さまざまな市場で入手可能なＵＮＩＸ（登録商標）またはＵＮＩＸのようなオペレーティングシステムのいずれかを実行するワークステーションコンピュータであり得る。クライアントコンピューティングデバイスは、ネットワーク１５１０を介して通信することができる、シンクライアントコンピュータ、インターネットにより可能化されるゲームシステム（たとえばＫｉｎｅｃｔ（登録商標）ジェスチャ入力デバイスを伴うかまたは伴わないＭｉｃｒｏｓｏｆｔ  Ｘｂｏｘゲームコンソール）および／または個人メッセージ伝達デバイスなどの電子デバイスも含んでもよい。
【０１５３】
図１５の分散型システム１５００は４つのクライアントコンピューティングデバイスとともに示されているが、任意の数のクライアントコンピューティングデバイスがサポートされてもよい。センサを伴うデバイスなど、他のデバイスがサーバ１５１２と対話してもよい。
【０１５４】
分散型システム１５００におけるネットワーク１５１０は、ＴＣＰ／ＩＰ（伝送制御プロトコル／インターネットプロトコル）、ＳＮＡ（システムネットワークアーキテクチャ）、ＩＰＸ（インターネットパケット交換）、ＡｐｐｌｅＴａｌｋなどを限定を伴うことなく含む、さまざまな入手可能なプロトコルのうちのいずれかを用いてデータ通信をサポートすることができる、当業者が精通している任意のタイプのネットワークであってもよい。単に一例として、ネットワーク１５１０は、ローカルエリアネットワーク（ＬＡＮ）、イーサネット、トークンリングに基づくネットワーク、ワイドエリアネットワーク、インターネット、仮想ネットワーク、仮想プライベートネットワーク（virtual private network：ＶＰＮ）、イントラネット、エクストラネット、公衆交換電話網（public switched telephone network：ＰＳＴＮ）、赤外線ネットワーク、無線ネットワーク（たとえば米国電気電子学会（ＩＥＥＥ）８０２．１１のプロトコル一式、ブルートゥース（登録商標）、および／もしくはその他の無線プロトコルのうちのいずれかの下で動作するネットワーク）、ならびに／またはこれらの任意の組み合わせおよび／もしくは他のネットワークであり得る。
【０１５５】
サーバ１５１２は、１つ以上の汎用コンピュータ、専用のサーバコンピュータ（一例としてＰＣ（パーソナルコンピュータ）サーバ、ＵＮＩＸ（登録商標）サーバ、ミッドレンジサーバ、メインフレームコンピュータ、ラックマウント型サーバなどを含む）、サーバファーム、サーバクラスタ、またはその他の適切な構成および／もしくは組み合わせで構成されてもよい。サーバ１５１２は、仮想オペレーティングシステムを実行する１つ以上の仮想マシン、または仮想化を伴う他のコンピューティングアーキテクチャを含み得る。論理ストレージデバイスの１つ以上の柔軟なプールを仮想化してサーバのために仮想ストレージデバイスを維持することができる。仮想ネットワークを、サーバ１５１２によって、ソフトウェア定義のネットワーク接続を用いて制御することができる。さまざまな実施例において、サーバ１５１２は、前述の開示に記載される１つ以上のサービスまたはソフトウェアアプリケーションを実行するように適合されてもよい。たとえば、サーバ１５１２は、本開示の実施例に従って上記の処理を実行するためのサーバに対応してもよい。
【０１５６】
サーバ１５１２は、上記のもののうちのいずれかを含むオペレーティングシステム、および任意の市場で入手可能なサーバオペレーティングシステムを実行してもよい。サーバ１５１２は、ＨＴＴＰ（ハイパーテキスト転送プロトコル）サーバ、ＦＴＰ（ファイル転送プロトコル）サーバ、ＣＧＩ（コモンゲートウェイインターフェイス）サーバ、ＪＡＶＡ（登録商標）サーバ、データベースサーバなどを含むさまざまなさらなるサーバアプリケーションおよび／または中間層アプリケーションのうちのいずれかも実行してもよい。例示的なデータベースサーバは、オラクル、マイクロソフト、サイベース、ＩＢＭ（インターナショナルビジネスマシンズ）などから市場で入手可能なものを含むが、それらに限定されるものではない。
【０１５７】
いくつかの実現例では、サーバ１５１２は、クライアントコンピューティングデバイス１５０２，１５０４，１５０６および１５０８のユーザから受信されるデータフィードおよび／またはイベント更新情報を解析および整理統合するための１つ以上のアプリケーションを含んでもよい。一例として、データフィードおよび／またはイベント更新情報は、センサデータアプリケーション、金融株式相場表示板、ネットワーク性能測定ツール（たとえばネットワーク監視およびトラフィック管理アプリケーション）、クリックストリーム解析ツール、自動車交通監視などに関連するリアルタイムのイベントを含んでもよい、１つ以上の第三者情報源および連続データストリームから受信される、Ｔｗｉｔｔｅｒ（登録商標）フィード、Ｆａｃｅｂｏｏｋ（登録商標）更新情報またはリアルタイムの更新情報を含んでもよいが、それらに限定されるものではない。サーバ１５１２は、データフィードおよび／またはリアルタイムのイベントをクライアントコンピューティングデバイス１５０２，１５０４，１５０６および１５０８の１つ以上の表示デバイスを介して表示するための１つ以上のアプリケーションも含んでもよい。
【０１５８】
分散型システム１５００は、１つ以上のデータベース１５１４および１５１６も含んでもよい。これらのデータベースは、ユーザ対話情報、使用パターン情報、適応ルール情報などの情報および本発明の実施例によって使用される他の情報を記憶するための機構を提供してもよい。データベース１５１４および１５１６は、さまざまな位置にあってもよい。一例として、データベース１５１４および１５１６のうちの１つ以上は、サーバ１５１２に局在する（および／またはサーバ１５１２に常駐する）非一時的な記憶媒体にあってもよい。代替的に、データベース１５１４および１５１６は、サーバ１５１２から遠隔にあり、ネットワークに基づくかまたは専用の接続を介してサーバ１５１２と通信してもよい。一組の実施例では、データベース１５１４および１５１６は、記憶域ネットワーク（storage-area network：ＳＡＮ）にあってもよい。同様に、サーバ１５１２に帰する機能を実行するための任意の必要なファイルが、適宜、サーバ１５１２上においてローカルに、および／または遠隔で記憶されてもよい。一組の実施例では、データベース１５１４および１５１６は、ＳＱＬフォーマットされたコマンドに応答してデータを記憶、更新および検索取得するように適合される、オラクルによって提供されるデータベースなどのリレーショナルデータベースを含んでもよい。
【０１５９】
いくつかの実施例では、クラウド環境は、セキュリティアーチファクトを管理するための１つ以上のサービスを提供してもよい。図１６は、本開示の実施例に従って、サービスがクラウドサービスとして提供されてもよいシステム環境１６００の１つ以上のコンポーネントの簡略ブロック図である。図１６における示されている実施例では、システム環境１６００は、１つ以上のクライアントコンピューティングデバイス１６０４，１６０６および１６０８を含み、１つ以上のクライアントコンピューティングデバイス１６０４，１６０６および１６０８は、セキュリティアーチファクトを管理するためのサービスを含むクラウドサービスを提供するクラウドインフラストラクチャシステム１６０２と対話するようにユーザによって使用されてもよい。クラウドインフラストラクチャシステム１６０２は、サーバ１５１２のための上記のものを含んでもよい１つ以上のコンピュータおよび／またはサーバを備えてもよい。
【０１６０】
図１６に示されるクラウドインフラストラクチャシステム１６０２は図示されるもの以外のコンポーネントを有してもよいことが理解されるべきである。さらに、図１６に示される実施例は、本発明の実施例を組み込んでもよいクラウドインフラストラクチャシステムの一例に過ぎない。いくつかの他の実施例では、クラウドインフラストラクチャシステム１６０２は、図に示されるよりも多いコンポーネントもしくは少ないコンポーネントを有してもよく、２つ以上のコンポーネントを組み合わせてもよく、またはコンポーネントの異なる構成もしくは配置を有してもよい。
【０１６１】
クライアントコンピューティングデバイス１６０４，１６０６および１６０８は、クライアントコンピューティングデバイス１５０２，１５０４，１５０６および１５０８に対して上記されたものと同様のデバイスであってもよい。クライアントコンピューティングデバイス１６０４，１６０６および１６０８は、ウェブブラウザ、所有権付きクライアントアプリケーション（たとえばオラクルフォームズ）、または何らかの他のアプリケーションなどのクライアントアプリケーションを動作させるよう構成されてもよく、当該クライアントアプリケーションは、クラウドインフラストラクチャシステム１６０２と対話して、クラウドインフラストラクチャシステム１６０２によって提供されるサービスを使用するようにクライアントコンピューティングデバイスのユーザによって使用されてもよい。例示的なシステム環境１６００が３つのクライアントコンピューティングデバイスとともに示されているが、任意の数のクライアントコンピューティングデバイスがサポートされてもよい。センサを伴うデバイスなどの他のデバイスがクラウドインフラストラクチャシステム１６０２と対話してもよい。
【０１６２】
ネットワーク１６１０は、クライアントコンピューティングデバイス１６０４，１６０６および１６０８とクラウドインフラストラクチャシステム１６０２との間におけるデータの通信および交換を容易にしてもよい。各ネットワークは、ネットワーク１５１０に対して上記されたものを含む、さまざまな市場で入手可能なプロトコルのうちのいずれかを用いてデータ通信をサポートすることができる、当業者が精通している任意のタイプのネットワークであってもよい。
【０１６３】
特定の実施例では、クラウドインフラストラクチャシステム１６０２によって提供されるサービスは、オンデマンドでクラウドインフラストラクチャシステムのユーザに利用可能にされるサービスのホストを含んでもよい。セキュリティアーチファクトの管理に関連するサービスに加えて、オンラインデータストレージおよびバックアップソリューション、ウェブベースの電子メールサービス、ホスト型オフィススイートおよび文書コラボレーションサービス、データベース処理、管理された技術サポートサービスなどを限定を伴うことなく含むさまざまな他のサービスも提供されてもよい。クラウドインフラストラクチャシステムによって提供されるサービスは、動的にスケーリングしてそのユーザのニーズを満たすことができる。
【０１６４】
特定の実施例では、クラウドインフラストラクチャシステム１６０２によって提供されるあるサービスのある具体的なインスタンス化は、本明細書では「サービスインスタンス」と称される。一般に、クラウドサービスプロバイダのシステムからインターネットなどの通信ネットワークを介してユーザに利用可能にされる任意のサービスは、「クラウドサービス」と称される。典型的には、パブリックなクラウド環境においては、クラウドサービスプロバイダのシステムを構成するサーバおよびシステムは、顧客自身のオンプレミスのサーバおよびシステムとは異なる。たとえば、クラウドサービスプロバイダのシステムは、アプリケーションを運営管理してもよく、ユーザは、インターネットなどの通信ネットワークを介して、オンデマンドで、アプリケーションをオーダーし使用してもよい。
【０１６５】
いくつかの例では、コンピュータネットワーククラウドインフラストラクチャにおけるサービスは、ストレージ、ホスト型データベース、ホスト型ウェブサーバ、ソフトウェアアプリケーション、またはクラウドベンダによってユーザに提供されるかもしくは他の態様で当該技術分野において公知であるような他のサービスに対する保護されたコンピュータネットワークアクセスを含んでもよい。たとえば、サービスは、クラウド上のリモートストレージに対するインターネットを介してのパスワード保護されたアクセスを含むことができる。別の例として、サービスは、ネットワーク接続された開発者による個人的な使用のために、ウェブサービスに基づくホスト型リレーショナルデータベースおよびスクリプト言語ミドルウェアエンジンを含むことができる。別の例として、サービスは、クラウドベンダのウェブサイトにおいて運営管理される電子メールソフトウェアアプリケーションに対するアクセスを含むことができる。
【０１６６】
特定の実施例では、クラウドインフラストラクチャシステム１６０２は、セルフサービスの、サブスクリプションに基づく、弾性的にスケーラブルで、信頼性があり、高可用性の、安全な態様で顧客に対して配送される一連のアプリケーション、ミドルウェア、およびデータベースサービス提供品を含んでもよい。そのようなクラウドインフラストラクチャシステムの一例は、本譲受人によって提供されるオラクルパブリッククラウド（Oracle Public Cloud）である。
【０１６７】
クラウドインフラストラクチャシステム１６０２は、「ビッグデータ」関連の計算および解析サービスも提供してもよい。「ビッグデータ」という語は、一般に、大量のデータを視覚化し、傾向を検出し、および／またはその他の態様でデータと対話するようにアナリストおよび研究者によって記憶および操作され得る非常に大きなデータセットを指すように用いられる。このビッグデータおよび関連のアプリケーションは、インフラストラクチャシステムによって、多数のレベルにおいて、および異なるスケールで運営管理および／または操作され得る。そのようなデータを表示するため、またはデータもしくはデータが表現するものに対する外部の力をシミュレートするために、並列に連結された何十、何百または何千ものプロセッサがそのようなデータに対して作用することができる。これらのデータセットは、データベース状にもしくはさもなければ構造モデルに従って編成されたものなどの構造化データ、および／または非構造化データ（たとえば電子メール、画像、データブロブ（バイナリラージオブジェクト）、ウェブページ、複合イベント処理）を含み得る。より多くの（またはより少ない）計算リソースを比較的迅速に対象に集中させることができる実施例の機能を活用することによって、クラウドインフラストラクチャシステムは、会社、政府機関、研究組織、私人、同じ考えを持った個人もしくは組織のグループ、または他のエンティティからの要求に基づいて大きなデータセットに対してタスクを実行することにさらに利用できるであろう。
【０１６８】
さまざまな実施例では、クラウドインフラストラクチャシステム１６０２は、クラウドインフラストラクチャシステム１６０２によって提供されるサービスに対する顧客のサブスクリプションを自動的にプロビジョニングし、管理し、および追跡するように適合されてもよい。クラウドインフラストラクチャシステム１６０２は、クラウドサービスをさまざまなデプロイメントモデルを介して提供してもよい。たとえば、サービスは、クラウドインフラストラクチャシステム１６０２が（たとえばオラクル社によって所有される）クラウドサービスを販売する組織によって所有され、サービスが一般大衆または異なる業界企業に対して利用可能にされるパブリッククラウドモデルの下で提供されてもよい。別の例として、サービスは、クラウドインフラストラクチャシステム１６０２が単一の組織に対してのみ動作され、その組織内における１つ以上のエンティティに対してサービスを提供してもよいプライベートクラウドモデルの下で提供されてもよい。また、クラウドサービスは、クラウドインフラストラクチャシステム１６０２およびクラウドインフラストラクチャシステム１６０２によって提供されるサービスが、関連するコミュニティにおけるいくつかの組織によって共有されるコミュニティクラウドモデルの下で提供されてもよい。また、クラウドサービスは、２つ以上の異なるモデルの組み合わせであるハイブリッドクラウドモデルの下で提供されてもよい。
【０１６９】
いくつかの実施例では、クラウドインフラストラクチャシステム１６０２によって提供されるサービスは、ソフトウェア・アズ・ア・サービス（ＳａａＳ）カテゴリ、プラットフォーム・アズ・ア・サービス（ＰａａＳ）カテゴリ、インフラストラクチャ・アズ・ア・サービス（ＩａａＳ）カテゴリ、またはハイブリッドサービスを含む他のサービスのカテゴリの下で提供される１つ以上のサービスを含んでもよい。顧客は、サブスクリプションオーダーを介して、クラウドインフラストラクチャシステム１６０２によって提供される１つ以上のサービスをオーダーしてもよい。クラウドインフラストラクチャシステム１６０２は、次いで、処理を実行して、顧客のサブスクリプションオーダーにおけるサービスを提供する。
【０１７０】
いくつかの実施例では、クラウドインフラストラクチャシステム１６０２によって提供されるサービスは、アプリケーションサービス、プラットフォームサービスおよびインフラストラクチャサービスを含んでもよいが、それらに限定されるものではない。いくつかの例では、アプリケーションサービスは、クラウドインフラストラクチャシステムによってＳａａＳプラットフォームを介して提供されてもよい。ＳａａＳプラットフォームは、ＳａａＳカテゴリに入るクラウドサービスを提供するよう構成されてもよい。たとえば、ＳａａＳプラットフォームは、一連のオンデマンドアプリケーションを統合された開発およびデプロイメントプラットフォーム上で構築し配送する機能を提供してもよい。ＳａａＳプラットフォームは、ＳａａＳサービスを提供するための基本的なソフトウェアおよびインフラストラクチャを管理および制御してもよい。ＳａａＳプラットフォームによって提供されるサービスを利用することによって、顧客は、クラウドインフラストラクチャシステムにおいて実行されるアプリケーションを利用することができる。顧客は、別個のライセンスおよびサポートを購入する必要なくアプリケーションサービスを取得することができる。さまざまな異なるＳａａＳサービスが提供されてもよい。その例としては、大きな組織に販売実績管理、企業統合、およびビジネスの柔軟性のためのソリューションを提供するサービスが挙げられるが、それらに限定されるものではない。
【０１７１】
いくつかの実施例では、プラットフォームサービスは、クラウドインフラストラクチャシステム１６０２によってＰａａＳプラットフォームを介して提供されてもよい。ＰａａＳプラットフォームは、ＰａａＳカテゴリに入るクラウドサービスを提供するよう構成されてもよい。プラットフォームサービスの例としては、（オラクルなどの）組織が既存のアプリケーションを共有の共通のアーキテクチャにおいて整理統合することができるサービス、およびプラットフォームによって提供される共有のサービスを活用する新たなアプリケーションを構築する機能を挙げることができるが、それらに限定されるものではない。ＰａａＳプラットフォームは、ＰａａＳサービスを提供するための基本的なソフトウェアおよびインフラストラクチャを管理および制御してもよい。顧客は、クラウドインフラストラクチャシステム１６０２によって提供されるＰａａＳサービスを、別個のライセンスおよびサポートを購入する必要なく取得することができる。プラットフォームサービスの例としては、オラクル・Ｊａｖａ・クラウド・サービス（Oracle Java Cloud Service：ＪＣＳ）、オラクル・データベース・クラウド・サービス（Oracle Database Cloud Service：ＤＢＣＳ）などが挙げられるが、それらに限定されるものではない。
【０１７２】
ＰａａＳプラットフォームによって提供されるサービスを利用することによって、顧客は、クラウドインフラストラクチャシステムによってサポートされるプログラミング言語およびツールを使用することができ、デプロイされたサービスを制御することもできる。いくつかの実施例では、クラウドインフラストラクチャシステムによって提供されるプラットフォームサービスは、データベースクラウドサービス、ミドルウェアクラウドサービス（たとえばオラクル・フュージョン・ミドルウェアサービス）、およびＪａｖａクラウドサービスを含んでもよい。一実施例では、データベースクラウドサービスは、組織がデータベースリソースをプールし、顧客にデータベース・アズ・ア・サービスをデータベースクラウドの形式で提供することを可能にする共有のサービスデプロイメントモデルをサポートしてもよい。ミドルウェアクラウドサービスは、顧客がさまざまなビジネスアプリケーションを開発およびデプロイするためのプラットフォームをクラウドインフラストラクチャシステムにおいて提供してもよく、Ｊａｖａクラウドサービスは、顧客がＪａｖａアプリケーションをデプロイするためのプラットフォームをクラウドインフラストラクチャシステムにおいて提供してもよい。
【０１７３】
さまざまな異なるインフラストラクチャサービスがＩａａＳプラットフォームによってクラウドインフラストラクチャシステムにおいて提供されてもよい。インフラストラクチャサービスは、ストレージ、ネットワーク、ならびにＳａａＳプラットフォームおよびＰａａＳプラットフォームによって提供されるサービスを利用する顧客に対する他の基礎的計算リソースなどの基本的な計算リソースの管理および制御を容易にする。
【０１７４】
特定の実施例では、クラウドインフラストラクチャシステム１６０２は、クラウドインフラストラクチャシステムの顧客に対してさまざまなサービスを提供するよう用いられるリソースを提供するためのインフラストラクチャリソース１６３０も含んでもよい。一実施例では、インフラストラクチャリソース１６３０は、サーバ、ストレージ、ならびにＰａａＳプラットフォームおよびＳａａＳプラットフォームによって提供されるサービスを実行するためのネットワーキングリソース、ならびに他のリソースなどの、ハードウェアの予め統合され最適化された組み合わせを含んでもよい。
【０１７５】
いくつかの実施例では、クラウドインフラストラクチャシステム１６０２におけるリソースは、複数のユーザによって共有され、要求につき動的に再割り当てされてもよい。また、リソースは、ユーザに対してさまざまな時間ゾーンで割り当てられてもよい。たとえば、クラウドインフラストラクチャシステム１６０２は、第１の時間ゾーンにおけるユーザの第１の組がクラウドインフラストラクチャシステムのリソースをある特定の時間の間利用することを可能にし、次いで、異なる時間ゾーンに位置するユーザの別の組に対する同じリソースの再割り当てを可能にし、それによって、リソースの利用を最大化してもよい。
【０１７６】
特定の実施例では、クラウドインフラストラクチャシステム１６０２のさまざまなコンポーネントまたはモジュールによって共有されてクラウドインフラストラクチャシステム１６０２によるサービスのプロビジョニングを可能にするある数の内部共有サービス１６３２が提供されてもよい。これらの内部共有サービスは、セキュリティおよびアイデンティティサービス、統合サービス、エンタープライズリポジトリサービス、エンタープライズマネージャサービス、ウイルススキャンおよびホワイトリストサービス、高可用性、バックアップおよび回復サービス、クラウドサポートを可能にするためのサービス、電子メールサービス、通知サービス、ファイル転送サービスなどを含んでもよいが、それらに限定されるものではない。
【０１７７】
特定の実施例では、クラウドインフラストラクチャシステム１６０２は、クラウドインフラストラクチャシステムにおいてクラウドサービス（たとえばＳａａＳ、ＰａａＳ、およびＩａａＳサービス）の包括的な管理を提供してもよい。一実施例では、クラウド管理機能は、クラウドインフラストラクチャシステム１６０２によって受信される顧客のサブスクリプションをプロビジョニングし、管理し、および追跡する機能などを含んでもよい。
【０１７８】
一実施例では、図１６に示されるように、クラウド管理機能は、オーダー管理モジュール１６２０、オーダーオーケストレーションモジュール１６２２、オーダープロビジョニングモジュール１６２４、オーダー管理および監視モジュール１６２６、ならびにアイデンティティ管理モジュール１６２８などの１つ以上のモジュールによって提供されてもよい。これらのモジュールは、１つ以上のコンピュータおよび／もしくはサーバを含んでもよく、またはそれらを用いて提供されてもよく、それらは、汎用コンピュータ、専用のサーバコンピュータ、サーバファーム、サーバクラスタ、またはその他の適切な構成および／もしくは組み合わせであってもよい。
【０１７９】
例示的な動作では、ステップ１６３４において、クライアントコンピューティングデバイス１６０４、１６０６または１６０８などのクライアントデバイスを用いる顧客は、クラウドインフラストラクチャシステム１６０２によって提供される１つ以上のサービスを要求し、クラウドインフラストラクチャシステム１６０２によって提供される１つ以上のサービスに対するサブスクリプションに対するオーダーを行なうことによって、クラウドインフラストラクチャシステム１６０２と対話してもよい。特定の実施例では、顧客は、クラウドＵＩ１６１２、クラウドＵＩ１６１４および／またはクラウドＵＩ１６１６などのクラウドユーザインターフェイス（ＵＩ）にアクセスし、サブスクリプションオーダーをこれらのＵＩを介して行なってもよい。顧客がオーダーを行なうことに応答してクラウドインフラストラクチャシステム１６０２によって受信されるオーダー情報は、顧客を識別する情報、およびクラウドインフラストラクチャシステム１６０２によって提供される、その顧客が契約する予定の１つ以上のサービスを含んでもよい。
【０１８０】
ステップ１６３６において、顧客から受信されたオーダー情報は、オーダーデータベース１６１８に保存されてもよい。これが新たなオーダーである場合には、当該オーダーに対して新たなレコードが作成されてもよい。一実施例では、オーダーデータベース１６１８は、クラウドインフラストラクチャシステム１６１８によって動作されるいくつかのデータベースのうちの１つであり得、他のシステム要素と連携して動作され得る。
【０１８１】
ステップ１６３８において、オーダー情報は、オーダー管理モジュール１６２０に転送されてもよく、当該オーダー管理モジュール１６２０は、オーダーを検証すること、および検証次第そのオーダーを予約することなど、オーダーに関連する請求および課金機能を実行するよう構成されてもよい。
【０１８２】
ステップ１６４０において、オーダーに関する情報は、オーダーオーケストレーションモジュール１６２２に通信されてもよく、当該オーダーオーケストレーションモジュール１６２２は、顧客によってなされたオーダーに対してサービスおよびリソースのプロビジョニングをオーケストレーションするよう構成される。いくつかの例では、オーダーオーケストレーションモジュール１６２２は、オーダープロビジョニングモジュール１６２４のサービスをプロビジョニングに使用してもよい。特定の実施例では、オーダーオーケストレーションモジュール１６２２は、各オーダーに関連付けられるビジネスプロセスの管理を可能にし、ビジネス論理を適用して、オーダーがプロビジョニングに進むべきか否かを判断する。
【０１８３】
図１６に示される実施例に示されているように、ステップ１６４２において、新たなサブスクリプションに対するオーダーを受信すると、オーダーオーケストレーションモジュール１６２２は、リソースを割り当てて、サブスクリプションオーダーを満たすのに必要とされるリソースを構成するよう、オーダープロビジョニングモジュール１６２４に対して要求を送信する。オーダープロビジョニングモジュール１６２４は、顧客によってオーダーされたサービスに対するリソースの割り当てを可能にする。オーダープロビジョニングモジュール１６２４は、クラウドインフラストラクチャシステム１６００によって提供されるクラウドサービスと、要求されたサービスを提供するためのリソースをプロビジョニングするよう用いられる物理的インプリメンテーション層との間にある抽象化レベルを提供する。これにより、サービスおよびリソースが実際にオンザフライでプロビジョニングされるか、サービスおよびリソースが予めプロビジョニングされて要求時にのみ割り当てられる／あてがわれるかなどの、インプリメンテーション詳細からオーダーオーケストレーションモジュール１６２２を分離することができる。
【０１８４】
ステップ１６４４において、サービスおよびリソースがプロビジョニングされると、要求されたサービスが使用できる状態であることを示す通知が、契約している顧客に送信されてもよい。いくつかの例では、顧客が要求されたサービスの使用を開始することを可能にする情報（たとえばリンク）が顧客に送信されてもよい。
【０１８５】
ステップ１６４６において、顧客のサブスクリプションオーダーは、オーダー管理および監視モジュール１６２６によって管理および追跡されてもよい。いくつかの例では、オーダー管理および監視モジュール１６２６は、契約したサービスの顧客使用に関する使用統計を収集するよう構成されてもよい。たとえば、統計は、使用されるストレージの量、転送されるデータの量、ユーザの人数、ならびにシステムアップ時間およびシステムダウン時間の量などについて収集されてもよい。
【０１８６】
特定の実施例では、クラウドインフラストラクチャシステム１６００は、アイデンティティ管理モジュール１６２８を含んでもよく、当該アイデンティティ管理モジュール１６２８は、クラウドインフラストラクチャシステム１６００におけるアクセス管理および承認サービスなどのアイデンティティサービスを提供するよう構成される。いくつかの実施例では、アイデンティティ管理モジュール１６２８は、クラウドインフラストラクチャシステム１６０２によって提供されるサービスを利用することを望む顧客についての情報を制御してもよい。そのような情報は、そのような顧客のアイデンティティを認証する情報、およびそれらの顧客がさまざまなシステムリソース（たとえばファイル、ディレクトリ、アプリケーション、通信ポート、メモリセグメントなど）に対してどのアクションを実行することが承認されるかを記述する情報を含み得る。アイデンティティ管理モジュール１６２８は、各顧客についての記述的情報ならびにどのように誰によってその記述的情報がアクセスおよび修正され得るかについての情報の管理も含んでもよい。
【０１８７】
図１７は、本発明の実施例を実現するために使用され得る例示的なコンピュータシステム１７００を示す。いくつかの実施例では、コンピュータシステム１７００は、上記のさまざまなサーバおよびコンピュータシステムのうちのいずれかを実現するよう用いられてもよい。図１７に示されるように、コンピュータシステム１７００は、多数の周辺サブシステムとバスサブシステム１７０２を介して通信する処理ユニット１７０４を含むさまざまなサブシステムを含む。これらの周辺サブシステムは、処理加速ユニット１７０６、Ｉ／Ｏサブシステム１７０８、ストレージサブシステム１７１８および通信サブシステム１７２４を含んでもよい。ストレージサブシステム１７１８は、有形のコンピュータ読取可能な記憶媒体１７２２およびシステムメモリ１７１０を含んでもよい。
【０１８８】
バスサブシステム１７０２は、コンピュータシステム１７００のさまざまなコンポーネントおよびサブシステムに意図されるように互いに通信させるための機構を提供する。バスサブシステム１７０２は単一のバスとして概略的に示されているが、バスサブシステムの代替的実施例は、複数のバスを利用してもよい。バスサブシステム１７０２は、さまざまなバスアーキテクチャのうちのいずれかを用いるメモリバスまたはメモリコントローラ、周辺バスおよびローカルバスを含むいくつかのタイプのバス構造のうちのいずれかであってもよい。たとえば、そのようなアーキテクチャは、業界標準アーキテクチャ（Industry Standard Architecture：ＩＳＡ）バス、マイクロチャネルアーキテクチャ（Micro Channel Architecture：ＭＣＡ）バス、エンハンストＩＳＡ（Enhanced ISA：ＥＩＳＡ）バス、ビデオ・エレクトロニクス・スタンダーズ・アソシエーション（Video Electronics Standards Association：ＶＥＳＡ）ローカルバス、およびＩＥＥＥ  Ｐ１３８６．１規格に従って製造される中二階バスとして実現され得る周辺コンポーネントインターコネクト（Peripheral Component Interconnect：ＰＣＩ）バスなどを含んでもよい。
【０１８９】
処理サブシステム１７０４は、コンピュータシステム１７００の動作を制御し、１つ以上の処理ユニット１７３２，１７３４などを備えてもよい。処理ユニットは、単一コアもしくはマルチコアプロセッサを含む１つ以上のプロセッサ、プロセッサの１つ以上のコア、またはそれらの組み合わせを含んでもよい。いくつかの実施例では、処理サブシステム１７０４は、グラフィックスプロセッサ、デジタル信号プロセッサ（digital signal processor：ＤＳＰ）などの１つ以上の特殊用途コプロセッサを含み得る。いくつかの実施例では、処理サブシステム１７０４の処理ユニットの一部または全ては、特定用途向け集積回路（application specific integrated circuit：ＡＳＩＣ）またはフィールドプログラマブルゲートアレイ（field programmable gate array：ＦＰＧＡ）などのカスタマイズされた回路を用いて実現され得る。
【０１９０】
いくつかの実施例では、処理サブシステム１７０４における処理ユニットは、システムメモリ１７１０またはコンピュータ読取可能な記憶媒体１７２２に記憶された命令を実行することができる。さまざまな実施例では、処理ユニットは、さまざまなプログラムまたはコード命令を実行することができ、複数の同時に実行されるプログラムまたはプロセスを維持することができる。任意の所与の時点で、実行されるべきプログラムコードの一部または全ては、システムメモリ１７１０、および／または、場合によっては１つ以上のストレージデバイスを含むコンピュータ読取可能な記憶媒体１７２２に常駐することができる。好適なプログラミングを介して、処理サブシステム１７０４は、セキュリティアーチファクトを管理するための上記のさまざまな機能を提供することができる。
【０１９１】
特定の実施例では、コンピュータシステム１７００によって実行される処理全体を加速させるように、カスタマイズされた処理を実行するため、または処理サブシステム１７０４によって実行される処理の一部をオフロードするための処理加速ユニット１７０６が設けられてもよい。
【０１９２】
Ｉ／Ｏサブシステム１７０８は、コンピュータシステム１７００に情報を入力するため、および／または、コンピュータシステム１７００からもしくはコンピュータシステム１７００を介して情報を出力するためのデバイスおよび機構を含んでもよい。一般に、「入力デバイス」という語の使用は、コンピュータシステム１７００に情報を入力するための全ての考えられ得るタイプのデバイスおよび機構を含むよう意図される。ユーザインターフェイス入力デバイスは、たとえば、キーボード、マウスまたはトラックボールなどのポインティングデバイス、ディスプレイに組み込まれたタッチパッドまたはタッチスクリーン、スクロールホイール、クリックホイール、ダイアル、ボタン、スイッチ、キーパッド、音声コマンド認識システムを伴う音声入力デバイス、マイクロフォン、および他のタイプの入力デバイスを含んでもよい。ユーザインターフェイス入力デバイスは、ユーザが入力デバイスを制御して入力デバイスと対話することを可能にするＭｉｃｒｏｓｏｆｔ  Ｋｉｎｅｃｔ（登録商標）モーションセンサ、Ｍｉｃｒｏｓｏｆｔ  Ｘｂｏｘ（登録商標）３６０ゲームコントローラ、ジェスチャおよび話し言葉コマンドを用いて入力を受信するためのインターフェイスを提供するデバイスなどのモーション感知および／またはジェスチャ認識デバイスも含んでもよい。ユーザインターフェイス入力デバイスは、ユーザから目の活動（たとえば写真を撮っている間および／またはメニュー選択を行なっている間の「まばたき」）を検出し、アイジェスチャを入力デバイス（たとえばＧｏｏｇｌｅ  Ｇｌａｓｓ（登録商標））への入力として変換するＧｏｏｇｌｅ  Ｇｌａｓｓ（登録商標）瞬き検出器などのアイジェスチャ認識デバイスも含んでもよい。また、ユーザインターフェイス入力デバイスは、ユーザが音声コマンドを介して音声認識システム（たとえばＳｉｒｉ（登録商標）ナビゲータ）と対話することを可能にする音声認識感知デバイスを含んでもよい。
【０１９３】
ユーザインターフェイス入力デバイスの他の例としては、三次元（３Ｄ）マウス、ジョイスティックまたはポインティングスティック、ゲームパッドおよびグラフィックタブレット、ならびにスピーカ、デジタルカメラ、デジタルカムコーダ、ポータブルメディアプレーヤ、ウェブカム、画像スキャナ、指紋スキャナ、バーコードリーダ３Ｄスキャナ、３Ｄプリンタ、レーザレンジファインダ、および視線追跡デバイスなどの聴覚／視覚デバイスが挙げられるが、それらに限定されるものではない。また、ユーザインターフェイス入力デバイスは、たとえば、コンピュータ断層撮影、磁気共鳴撮像、ポジションエミッショントモグラフィー、医療超音波検査デバイスなどの医療画像化入力デバイスを含んでもよい。ユーザインターフェイス入力デバイスは、たとえば、ＭＩＤＩキーボード、デジタル楽器などの音声入力デバイスも含んでもよい。
【０１９４】
ユーザインターフェイス出力デバイスは、ディスプレイサブシステム、インジケータライト、または音声出力デバイスなどの非ビジュアルディスプレイなどを含んでもよい。ディスプレイサブシステムは、陰極線管（cathode ray tube：ＣＲＴ）、液晶ディスプレイ（liquid crystal display：ＬＣＤ）またはプラズマディスプレイを使うものなどのフラットパネルデバイス、投影デバイス、タッチスクリーンなどであってもよい。一般に、「出力デバイス」という語の使用は、コンピュータシステム１７００からユーザまたは他のコンピュータに情報を出力するための全ての考えられ得るタイプのデバイスおよび機構を含むよう意図される。たとえば、ユーザインターフェイス出力デバイスは、モニタ、プリンタ、スピーカ、ヘッドフォン、自動車ナビゲーションシステム、プロッタ、音声出力デバイスおよびモデムなどの、テキスト、グラフィックスおよび音声／映像情報を視覚的に伝えるさまざまな表示デバイスを含んでもよいが、それらに限定されるものではない。
【０１９５】
ストレージサブシステム１７１８は、コンピュータシステム１７００によって使用される情報を記憶するためのリポジトリまたはデータストアを提供する。ストレージサブシステム１７１８は、いくつかの実施例の機能を提供する基本的なプログラミングおよびデータ構造を記憶するための有形の非一時的なコンピュータ読取可能な記憶媒体を提供する。処理サブシステム１７０４によって実行されたときに上記の機能を提供するソフトウェア（プログラム、コードモジュール、命令）がストレージサブシステム１７１８に記憶されてもよい。当該ソフトウェアは、処理サブシステム１７０４の１つ以上の処理ユニットによって実行されてもよい。ストレージサブシステム１７１８は、本発明に従って使用されるデータを記憶するためのリポジトリも提供してもよい。
【０１９６】
ストレージサブシステム１７１８は、揮発性および不揮発性メモリデバイスを含む１つ以上の非一時的なメモリデバイスを含んでもよい。図１７に示されるように、ストレージサブシステム１７１８は、システムメモリ１７１０と、コンピュータ読取可能な記憶媒体１７２２とを含む。システムメモリ１７１０は、プログラム実行中に命令およびデータを記憶するための揮発性メインランダムアクセスメモリ（random access memory：ＲＡＭ）および固定命令が記憶される不揮発性リードオンリメモリ（read only memory：ＲＯＭ）またはフラッシュメモリを含む複数のメモリを含んでもよい。いくつかの実現例では、起動中などにコンピュータシステム１７００内の要素間における情報の転送を助ける基本的なルーティンを含むベーシックインプット／アウトプットシステム（basic input/output system：ＢＩＯＳ）は、一般に、ＲＯＭに記憶されてもよい。ＲＡＭは、一般に、処理サブシステム１７０４によって現在動作および実行されているデータおよび／またはプログラムモジュールを含む。いくつかの実現例では、システムメモリ１７１０は、スタティックランダムアクセスメモリ（static random access memory：ＳＲＡＭ）またはダイナミックランダムアクセスメモリ（dynamic random access memory：ＤＲＡＭ）などの複数の異なるタイプのメモリを含んでもよい。
【０１９７】
一例として、限定を伴うことなく、図１７に示されるように、システムメモリ１７１０は、アプリケーションプログラム１７１２を記憶してもよく、当該アプリケーションプログラム１７１２は、クライアントアプリケーション、ウェブブラウザ、中間層アプリケーション、リレーショナルデータベース管理システム（relational database management system：ＲＤＢＭＳ）など、プログラムデータ１７１４およびオペレーティングシステム１７１６を含んでもよい。一例として、オペレーティングシステム１７１６は、Ｍｉｃｒｏｓｏｆｔ  Ｗｉｎｄｏｗｓ（登録商標）、Ａｐｐｌｅ  Ｍａｃｉｎｔｏｓｈ（登録商標）および／もしくはＬｉｎｕｘオペレーティングシステム、さまざまな市場で入手可能なＵＮＩＸ（登録商標）またはＵＮＩＸのようなオペレーティングシステム（さまざまなＧＮＵ／Ｌｉｎｕｘオペレーティングシステム、Ｇｏｏｇｌｅ  Ｃｈｒｏｍｅ（登録商標）ＯＳなどを含むがそれらに限定されない）、ならびに／または、ｉＯＳ、Ｗｉｎｄｏｗｓ（登録商標）  Ｐｈｏｎｅ、Ａｎｄｒｏｉｄ（登録商標）  ＯＳ、ＢｌａｃｋＢｅｒｒｙ（登録商標）  １０  ＯＳ、およびＰａｌｍ（登録商標）  ＯＳオペレーティングシステムなどのモバイルオペレーティングシステムのさまざまなバージョンを含んでもよい。
【０１９８】
コンピュータ読取可能な記憶媒体１７２２は、いくつかの実施例の機能を提供するプログラミングおよびデータ構造を記憶してもよい。処理サブシステム１７０４によって実行されたときにプロセッサが上記の機能を提供するソフトウェア（プログラム、コードモジュール、命令）は、ストレージサブシステム１７１８に記憶されてもよい。一例として、コンピュータ読取可能な記憶媒体１７２２は、ハードディスクドライブ、磁気ディスクドライブ、ＣＤ  ＲＯＭ、ＤＶＤ、ブルーレイ（登録商標）ディスクなどの光ディスクドライブ、または他の光学式媒体などの不揮発性メモリを含んでもよい。コンピュータ読取可能な記憶媒体１７２２は、Ｚｉｐ（登録商標）ドライブ、フラッシュメモリカード、ユニバーサルシリアルバス（universal serial bus：ＵＳＢ）フラッシュドライブ、セキュアデジタル（secure digital：ＳＤ）カード、ＤＶＤディスク、デジタルビデオテープなどを含んでもよいが、それらに限定されるものではない。コンピュータ読取可能な記憶媒体１７２２は、フラッシュメモリベースのＳＳＤ、エンタープライズフラッシュドライブ、ソリッドステートＲＯＭなどの不揮発性メモリに基づくソリッドステートドライブ（solid-state drive：ＳＳＤ）、ソリッドステートＲＡＭ、ダイナミックＲＡＭ、スタティックＲＡＭなどの揮発性メモリに基づくＳＳＤ、ＤＲＡＭベースのＳＳＤ、磁気抵抗ＲＡＭ（magnetoresistive RAM：ＭＲＡＭ）ＳＳＤ、およびＤＲＡＭとフラッシュメモリベースのＳＳＤとの組み合わせを使用するハイブリッドＳＳＤも含んでもよい。コンピュータ読取可能な媒体１７２２は、コンピュータ読取可能な命令、データ構造、プログラムモジュールおよび他のデータのストレージをコンピュータシステム１７００に提供してもよい。
【０１９９】
特定の実施例では、ストレージサブシステム１７００は、コンピュータ読取可能な記憶媒体１７２２にさらに接続可能なコンピュータ読取可能記憶媒体リーダ１７２０も含んでもよい。システムメモリ１７１０とともに、およびオプションとしてシステムメモリ１７１０との組み合わせで、コンピュータ読取可能な記憶媒体１７２２は、コンピュータ読取可能な情報を記憶するための、遠隔の、ローカルな、固定された、および／またはリムーバブルなストレージデバイスに記憶媒体を加えたものを包括的に表わしてもよい。
【０２００】
特定の実施例では、コンピュータシステム１７００は、１つ以上の仮想マシンを実行するためのサポートを提供してもよい。コンピュータシステム１７００は、仮想マシンの構成および管理を容易にするためのハイパーバイザなどのプログラムを実行してもよい。各仮想マシンは、割り当てられたメモリ、計算（たとえばプロセッサ、コア）、Ｉ／Ｏおよびネットワーキングリソースであってもよい。各仮想マシンは、一般に、それ自体のオペレーティングシステムを実行し、当該オペレーティングシステムは、コンピュータシステム１７００によって実行される他の仮想マシンによって実行されるオペレーティングシステムと同一であってもよく、または異なっていてもよい。したがって、場合によっては、複数のオペレーティングシステムがコンピュータシステム１７００によって同時に実行されてもよい。各仮想マシンは、一般に、他の仮想マシンから独立して実行される。
【０２０１】
通信サブシステム１７２４は、他のコンピュータシステムおよびネットワークへのインターフェイスを提供する。通信サブシステム１７２４は、他のシステムとコンピュータシステム１７００との間のデータの送受のためのインターフェイスとして働く。たとえば、通信サブシステム１７２４は、コンピュータシステム１７００が１つ以上のクライアントコンピューティングデバイスとの情報の送受のためにインターネットを介したクライアントコンピューティングデバイスへの通信チャネルを確立することを可能にしてもよい。
【０２０２】
通信サブシステム１７２４は、有線通信プロトコルおよび／または無線通信プロトコルをサポートしてもよい。たとえば、特定の実施例では、通信サブシステム１７２４は、（たとえばセルラー電話技術、３Ｇ、４ＧもしくはＥＤＧＥ（グローバル進化のための高速データレート）などの先進データネットワーク技術、ＷｉＦｉ（ＩＥＥＥ８０２．１１ファミリー規格、もしくは他のモバイル通信技術、またはそれらの任意の組み合わせを用いて）無線音声および／またはデータネットワークにアクセスするための無線周波数（radio frequency：ＲＦ）送受信機コンポーネント、グローバルポジショニングシステム（global positioning system：ＧＰＳ）受信機コンポーネント、ならびに／または他のコンポーネントを含んでもよい。いくつかの実施例では、通信サブシステム１７２４は、無線インターフェイスに加えて、またはその代わりに、有線ネットワーク接続（たとえばイーサネット）を提供することができる。
【０２０３】
通信サブシステム１７２４は、さまざまな形式でデータを送受信することができる。たとえば、いくつかの実施例では、通信サブシステム１７２４は、構造化されたおよび／または構造化されていないデータフィード１７２６、イベントストリーム１７２８、イベント更新情報１７３０などの形式で入力通信を受信してもよい。たとえば、通信サブシステム１７２４は、ソーシャルメディアネットワークおよび／またはＴｗｉｔｔｅｒ（登録商標）フィード、Ｆａｃｅｂｏｏｋ（登録商標）更新情報、Ｒｉｃｈ  Ｓｉｔｅ  Ｓｕｍｍａｒｙ（ＲＳＳ）フィードなどのウェブフィード、および／もしくは１つ以上の第三者情報源からのリアルタイム更新情報などの他の通信サービスのユーザからリアルタイムでデータフィード１７２６を受信（または送信）するよう構成されてもよい。
【０２０４】
特定の実施例では、通信サブシステム１７２４は、連続データストリームの形式でデータを受信するよう構成されてもよく、当該連続データストリームは、明示的な端部を有さない本質的に連続的または無限であってもよい、リアルタイムイベントのイベントストリーム１７２８および／またはイベント更新情報１７３０を含んでもよい。連続データを生成するアプリケーションの例としては、たとえば、センサデータアプリケーション、金融株式相場表示板、ネットワーク性能測定ツール（たとえばネットワーク監視およびトラフィック管理アプリケーション）、クリックストリーム解析ツール、自動車交通監視などを挙げることができる。
【０２０５】
また、通信サブシステム１７２４は、構造化されたおよび／または構造化されていないデータフィード１７２６、イベントストリーム１７２８、イベント更新情報１７３０などを、コンピュータシステム１７００に結合される１つ以上のストリーミングデータソースコンピュータと通信し得る１つ以上のデータベースに出力するよう構成されてもよい。
【０２０６】
コンピュータシステム１７００は、手持ち式の携帯デバイス（たとえばｉＰｈｏｎｅ（登録商標）携帯電話、ｉＰａｄ（登録商標）コンピューティングタブレット、ＰＤＡ）、ウェアラブルデバイス（たとえばＧｏｏｇｌｅ  Ｇｌａｓｓ（登録商標）頭部装着型ディスプレイ）、パーソナルコンピュータ、ワークステーション、メインフレーム、キオスク、サーバラック、またはその他のデータ処理システムを含む、さまざまなタイプのもののうちの１つであり得る。
【０２０７】
常に変化するコンピュータおよびネットワークの性質のため、図１７に示されるコンピュータシステム１７００の記載は、単に具体的な例として意図される。図１７に示されるシステムよりも多いまたは少ないコンポーネントを有する多くの他の構成が可能である。本明細書における開示および教示に基づいて、当業者は、さまざまな実施例を実現するための他の態様および／または方法を理解するであろう。
【０２０８】
図１８は、本発明の実施例を実現するために使用され得る例示的な異常検出および解決システム（ＡＤＲＳ）１８００を示す。図１８に示されるように、ＡＤＲＳ１８００は、ＡＳＣ１８２０を含み得る。ＡＳＣ１８２０は、ＡＤＲＳ１８０２モジュールと、ＳＣＤＭＳ１８０４と、ＣＣＭＳ１８０６と、ＬＲＡＳ１８０８とを含み得る。ＡＤＲＳ１８００は、１つ以上のＡＤＲＣ１８１０を含み得る。ＡＤＲＣ１８１０は、ＡＤＲＳ１８００の一部として実現されてもよい。ＡＳＣ１８２０は、図１３のＡＳＣ３１８であってもよい。ＳＣＤＭＳ１８０４は３２２であってもよく、ＣＣＭＳ１８０６はＣＣＭＳ３２４であってもよく、ＬＲＡＳ１８０８はＬＲＡＳ３２６であってもよく、ＡＤＲＳ１８０２モジュールはＡＤＲＳ３２０であってもよい。ＡＤＲＣ１８１０は、図３のＡＤＲＣ３５４，３６４，３７４であってもよい。
【０２０９】
少なくとも１つの実施例では、ＡＤＲＳモジュール１８０２は、クラウドコンピュータシステムによって提供されるサービスに関連するメトリックの異常範囲を定義する一組の値を求めるように構成され得る。サービスは、クラウドコンピュータシステム内のコンポーネントによって確立され得る。コンポーネントは、クラウドコンピュータ環境で実行される第１のコンテナおよび第２のコンテナを含み得る。第１のコンテナは、第２のコンテナにおける子コンテナであり得る。ＡＤＲＳモジュール１８０２は、ＡＤＲＣ１８１０のうちの１つなどの異常検出および解決コンポーネント（ＡＤＲＣ）を含むように第１のコンテナを構成するように構成され得る。ＡＤＲＣは、クラウドコンピュータシステム内でのサービスのオペレーションに関連する異常の異常イベントを第１のコンテナにおいて検出するように構成され得る。異常イベントは、メトリックの値がメトリックの異常範囲を満たさないことに基づいて検出され得る。ＡＤＲＣは、第１のコンテナにおいて異常を解決するためのポリシーを特定するように構成され得る。ＡＤＲＣは、ポリシーにおけるルールが異常によって満たされることを判断するように構成され得る。ＡＤＲＣは、異常を解決するための修正アクションを起動するように構成され得る。修正アクションは、ルールが満たされたことに基づいてポリシーで特定され得る。
【０２１０】
いくつかの実施例では、異常範囲は、ユーザ定義の異常について定義される固定された範囲である。一組の値は、ポーリング間隔値、メトリックの最小値尺度、メトリックのソフト限界、メトリックの最大値、および異常の最小発生回数を定義する最小連続読取値を含み得る。異常イベントを検出することは、メトリックの値が異常範囲を満たすか否かを判断することを含み得る。メトリックの値は、値が最小値尺度未満である場合およびソフト限界以上である場合には、異常範囲を満たし得ない。異常イベントは、最小連続読取値が満たされたことに基づいて検出され得る。
【０２１１】
いくつかの実施例では、異常範囲は、ユーザ定義の異常について定義される周期的範囲である。一組の値は、ポーリング間隔値、メトリックの最小値尺度、メトリックのソフト限界、メトリックの最大値、異常の連続発生期間、周期的範囲が有効である開始時刻、および周期的範囲が有効である終了時刻を含み得る。異常イベントを検出することは、メトリックの値が異常範囲を満たすか否かを判断することを含み得る。メトリックの値は、値が最小値尺度未満である場合およびソフト限界以上である場合、異常イベントが当該期間中に検出され、開始時刻後であって終了時刻前に検出される場合には、異常範囲を満たし得ない。
【０２１２】
少なくとも１つの実施例では、一組の値を求めることは、ログファイルの時系列データを分析して異常範囲について一組の値を計算することを含む。
【０２１３】
いくつかの実施例では、ＡＤＲＣは、第１のコンテナにおいて異常を解決するためのポリシーを特定できないと判断すると、第１のコンテナにおいて異常を解決できないことを第２のコンテナに通知するように構成され得る。ＡＤＲＣは、第２のコンテナにおいて異常を解決するためのポリシーを特定するように構成され得る。当該方法は、第２のコンテナにおいて異常を解決するためのポリシーにおけるルールが異常によって満たされることを判断することを含み得る。ＡＤＲＣは、ルールが満たされたことに基づいて、第２のコンテナにおいて異常を解決するための、ポリシーで特定される修正アクションを起動するように構成され得る。
【０２１４】
少なくとも１つの実施例では、サービスに関連するメトリックは、サービスを提供するためのサービス品質（ＱｏＳ）について監視される複数のメトリックのうちの１つである。
【０２１５】
少なくとも１つの実施例では、ＡＤＲＳモジュール１８０２は、クラウドコンピュータシステムによって提供されるサービスに関連するメトリックの異常範囲を定義する一組の値を求めるように構成され得る。サービスは、クラウドコンピュータシステム内のコンポーネントによって確立され得る。コンポーネントは、クラウドコンピュータ環境で実行される第１のコンテナおよび第２のコンテナを含み得る。第１のコンテナは、第２のコンテナにおける子コンテナであり得る。ＡＤＲＳモジュール１８０２は、ＡＤＲＣ１８１０のうちの１つなどの第１の異常検出および解決コンポーネント（ＡＤＲＣ）を含むように第１のコンテナを構成するように構成され得る。ＡＤＲＳモジュール１８０２は、第２のＡＤＲＣを含むように第２のコンテナを構成するように構成され得る。第１のＡＤＲＣは、クラウドコンピュータシステム内でのサービスのオペレーションに関連する異常の異常イベントを第１のコンテナにおいて検出するように構成され得る。異常イベントは、メトリックの値がメトリックの異常範囲を満たさないことに基づいて検出される。第１のＡＤＲＣは、第１のＡＤＲＣが第１のコンテナにおいて異常を解決するためのポリシーを有するか否かを判断するように構成され得る。第１のＡＤＲＣは、第１のＡＤＲＣが第１のコンテナにおいて異常を解決するためのポリシーを持たないと判断したことに基づいて、第１のコンテナにおいて異常を解決できないことを第２のコンテナに通知するように構成され得る。第２のＡＤＲＣは、第２のコンテナにおいて異常を解決するためのポリシーをＡＤＲＣのために特定するように構成され得る。第２のＡＤＲＣは、第２のコンテナにおいて異常を解決するためのポリシーにおけるルールが異常によって満たされることを判断するように構成され得る。第２のＡＤＲＣは、ルールが満たされたことに基づいて、第２のコンテナにおいて異常を解決するための、ポリシーで特定される修正アクションを起動するように構成され得る。
【０２１６】
いくつかの実施例では、第２のＡＤＲＣは、第２のＡＤＲＣが第２のコンテナにおいて異常を解決するためのポリシーを持たないと判断したことに基づいて、異常を解決できなかったという警告を通信システムを用いて送信するように構成され得る。
【０２１７】
いくつかの実施例では、第２のＡＤＲＣは、第２のＡＤＲＣが第２のコンテナにおいて異常を解決するためのポリシーを持たないと判断したことに基づいて、異常を解決できないことを第３のコンテナに通知するように構成され得て、第３のコンテナは、コンポーネントのうちの１つである。第３のコンテナは、第２のコンテナを含み得る。第３のＡＤＲＣは、第３のコンテナにおいて異常を解決するためのポリシーを特定するように第３のコンテナ内に構成され得る。第３のＡＤＲＣは、第３のコンテナにおいて異常を解決するための、ポリシーで特定される修正アクションを起動するように構成され得る。
【０２１８】
本発明の具体的な実施例について説明してきたが、さまざまな変形例、変更例、代替的な構成および等価物も本発明の範囲内に包含される。変形例は、開示されている特徴のいかなる関連の組み合わせも含む。本発明の実施例は、特定の具体的なデータ処理環境内でのオペレーションに限定されるものではなく、複数のデータ処理環境内で自由に動作できる。また、特定の一連のトランザクションおよびステップを用いて本発明の実施例について説明してきたが、本発明の範囲は、記載されている一連のトランザクションおよびステップに限定されるものではない、ということが当業者に明らかであるべきである。上記の実施例のさまざまな特徴および局面は、個々にまたは一緒に使用されてもよい。
【０２１９】
さらに、ハードウェアとソフトウェアとの特定の組み合わせを用いて本発明の実施例について説明してきたが、ハードウェアとソフトウェアとの他の組み合わせも本発明の範囲内であることが認識されるべきである。本発明の実施例は、ハードウェアのみで実現されてもよく、またはソフトウェアのみで実現されてもよく、またはそれらの組み合わせを用いて実現されてもよい。本明細書に記載されているさまざまなプロセスは、任意の組み合わせで同一のプロセッサまたは異なるプロセッサ上で実現され得る。したがって、コンポーネントまたはモジュールが特定のオペレーションを実行するよう構成されるものとして記載されている場合、このような構成は、たとえばオペレーションを実行するように電子回路を設計することによって、オペレーションを実行するように（マイクロプロセッサなどの）プログラム可能な電子回路をプログラミングすることによって、またはそれらの任意の組み合わせによって、達成されることができる。プロセスは、従来のプロセス間通信技術を含むがそれに限定されないさまざまな技術を用いて通信することができ、プロセスの異なる対は、異なる技術を使用してもよく、またはプロセスの同一の対は、異なるときに異なる技術を使用してもよい。
【０２２０】
したがって、明細書および図面は、限定的な意味ではなく例示的な意味で考えられるべきである。しかし、特許請求の範囲に記載されているより広範な精神および範囲から逸脱することなく、追加、減算、削除、ならびに他の変形および変更がそれに対してなされてもよい、ということは明白であろう。したがって、具体的な本発明の実施例について説明してきたが、これらは限定的であるよう意図されるものではない。さまざまな変形例および等価物は、以下の特許請求の範囲の範囲内である。
【図１】
0006731424.tif 000003
【図２】
0006731424.tif 000004
【図３】
0006731424.tif 000005
【図４】
0006731424.tif 000006
【図５】
0006731424.tif 000007
【図６】
0006731424.tif 000008
【図７】
0006731424.tif 000009
【図８】
0006731424.tif 000010
【図９】
0006731424.tif 000011
【図１０】
0006731424.tif 000012
【図１１】
0006731424.tif 000013
【図１２】
0006731424.tif 000014
【図１３】
0006731424.tif 000015
【図１４】
0006731424.tif 000016
【図１５】
0006731424.tif 000017
【図１６】
0006731424.tif 000018
【図１７】
0006731424.tif 000019
【図１８】
0006731424.tif 000020