(57)【要約】  本明細書で説明するシステムおよび方法は、エンタープライズリソースプランニングシステムのためのコンピューティングリソースの動的プロビジョニングに備える。動的プロビジョニングシステムは、クライアントデバイスからの選択時にコンピューティングリソースの元の構成をプロビジョニングし、その後、ＥＲＰシステムのリアルタイム性能を評価することによって、またはＥＲＰシステムの履歴性能および履歴消費情報を分析することによって、またはＥＲＰシステムの将来の性能によってもたらされるコンピューティングリソースへの予想されるストレスを予測するために組合せを使用することによって、さらなる動的なプロビジョニングに備える。
2019507932.tif 000002
【特許請求の範囲】
【請求項１】
エンタープライズリソースプランニングシステムのためのコンピューティングリソースの動的プロビジョニング方法であって、当該方法は、
動的プロビジョニングシステムの少なくとも１つのサーバによって、エンタープライズリソースプランニングシステムのための第１の複数のコンピューティングリソースの選択をクライアントデバイスから受信し、リソース管理データベースに第１の複数のレコードとして格納するステップと、
前記動的プロビジョニングシステムの前記少なくとも１つのサーバによって、前記クライアントデバイスによるアクセスのための元の構成を定義する前記第１の複数のコンピューティングリソースを割り当てて配備するステップと、
前記動的プロビジョニングシステムの前記少なくとも１つのサーバによって、前記元の構成を含む前記エンタープライズリソースプランニングシステムからリアルタイム消費情報を受信するステップであって、前記リアルタイム消費情報はリアルタイム性能測定値およびリアルタイム容量測定値を含み、前記リソース管理データベースに第２の複数のレコードとして格納される、ステップと、
前記動的プロビジョニングシステムの前記少なくとも１つのサーバによって、前記元の構成に関連し、前記リソース管理データベースに第３の複数のレコードとして格納されるプロビジョニング閾値を決定するステップであって、前記プロビジョニング閾値は、事前定義された性能測定値および事前定義された容量測定値を含む、ステップと、
前記動的プロビジョニングシステムの前記少なくとも１つのサーバによって、前記第２の複数のレコードのうちの２つ以上に対して事前設定された関係を満たす前記第３の複数のレコードのうちの２つ以上に応答して、前記元の構成を修正する必要があると判断するステップと、
前記動的プロビジョニングシステムの前記少なくとも１つのサーバによって、元の構成を修正する必要があると判断したことに応答して、修正構成を定義する第２の複数のリソースを割り当てるステップと、
前記動的プロビジョニングシステムの前記少なくとも１つのサーバによって、前記クライアントデバイスによるアクセスのために前記修正構成を配備するステップと、
を含む、方法。
【請求項２】
前記事前定義された性能測定値および前記事前定義された容量測定値が、前記元の構成に関連する履歴性能情報および履歴消費情報を分析することによって決定される、請求項１に記載の方法。
【請求項３】
前記事前定義された性能測定値および前記事前定義された容量測定値が、前記元の構成に関連するリアルタイム性能測定値およびリアルタイム容量測定値を分析することによって決定される、請求項１に記載の方法。
【請求項４】
前記事前定義された性能測定値が、トランザクション数、トランザクションレート、コミット数、平均ダウンタイム、最大ダウンタイム、およびアプリケーション応答時間のうちの１つまたは複数である、請求項１に記載の方法。
【請求項５】
前記事前定義された容量測定値が、システムＣＰＵ使用率メトリック、アプリケーションＣＰＵ使用率メトリック、使用されたメモリ量、使用可能メモリ量、およびインフラストラクチャ構成要素の可用性のうちの１つまたは複数である、請求項１に記載の方法。
【請求項６】
エンタープライズリソースプランニングシステムのためのコンピューティングリソースの動的プロビジョニングのためのシステムであって、当該システムは、
リソース管理データベースと、
前記リソース管理データベースに通信可能に結合された１つまたは複数のプロセッサと、
前記１つまたは複数のプロセッサと通信して配置され、命令のセットを含むコンピュータプログラムが格納された非一時的コンピュータ可読媒体と、
を含み、前記命令のセットが前記１つまたは複数のプロセッサによって実行されると、前記１つまたは複数のプロセッサは、
エンタープライズリソースプランニングシステムのための第１の複数のコンピューティングリソースの選択をクライアントデバイスから受信し、リソース管理データベースに第１の複数のレコードとして格納し、
前記クライアントデバイスによるアクセスのための元の構成を定義する前記第１の複数のコンピューティングリソースを割り当てて配備し、
前記元の構成を含む前記エンタープライズリソースプランニングシステムから、リアルタイム性能測定値およびリアルタイム容量測定値を含み、前記リソース管理データベースに第２の複数のレコードとして格納されるリアルタイム消費情報を受信し、
前記元の構成に関連し、前記リソース管理データベースに第３の複数のレコードとして格納され、事前定義された性能測定値および事前定義された容量測定値を含むプロビジョニング閾値を決定し、
前記第２の複数のレコードのうちの２つ以上に対して事前設定された関係を満たす前記第３の複数のレコードのうちの２つ以上に応答して、前記元の構成を修正する必要があると判断し、
元の構成を修正する必要があると判断したことに応答して、修正構成を定義する第２の複数のリソースを割り当て、
動的プロビジョニングシステムによって、前記クライアントデバイスによるアクセスのために前記修正構成を配備する、
動作を実行する、システム。
【請求項７】
前記事前定義された性能測定値および前記事前定義された容量測定値が、前記元の構成に関連する履歴性能情報および履歴消費情報を分析することによって決定される、請求項６に記載のシステム。
【請求項８】
前記事前定義された性能測定値および前記事前定義された容量測定値が、前記元の構成に関連するリアルタイム性能測定値およびリアルタイム容量測定値を分析することによって決定される、請求項６に記載のシステム。
【請求項９】
前記事前定義された性能測定値が、トランザクション数、トランザクションレート、コミット数、平均ダウンタイム、最大ダウンタイム、およびアプリケーション応答時間のうちの１つまたは複数である、請求項６に記載のシステム。
【請求項１０】
前記事前定義された容量測定値が、システムＣＰＵ使用率メトリック、アプリケーションＣＰＵ使用率メトリック、使用されたメモリ量、使用可能メモリ量、およびインフラストラクチャ構成要素の可用性のうちの１つまたは複数である、請求項６に記載のシステム。
【請求項１１】
実行されると、動的プロビジョニングシステムの少なくとも１つのサーバに、エンタープライズリソースプランニングシステムのためのコンピューティングリソースの動的プロビジョニング方法を実行させるプログラム命令を格納する、非一時的コンピュータ可読記憶デバイスであって、前記方法は、
前記動的プロビジョニングシステムによって、エンタープライズリソースプランニングシステムのための第１の複数のコンピューティングリソースの選択をクライアントデバイスから受信し、リソース管理データベースに第１の複数のレコードとして格納するステップと、
前記動的プロビジョニングシステムによって、前記クライアントデバイスによるアクセスのための元の構成を定義する前記第１の複数のコンピューティングリソースを割り当てて配備するステップと、
前記動的プロビジョニングシステムによって、前記元の構成を含む前記エンタープライズリソースプランニングシステムからリアルタイム消費情報を受信するステップであって、前記リアルタイム消費情報はリアルタイム性能測定値およびリアルタイム容量測定値を含み、前記リソース管理データベースに第２の複数のレコードとして格納される、ステップと、
前記動的プロビジョニングシステムによって、前記元の構成に関連し、前記リソース管理データベースに第３の複数のレコードとして格納されるプロビジョニング閾値を決定するステップであって、前記プロビジョニング閾値は、事前定義された性能測定値および事前定義された容量測定値を含む、ステップと、
前記動的プロビジョニングシステムによって、前記第２の複数のレコードのうちの２つ以上に対して事前設定された関係を満たす前記第３の複数のレコードのうちの２つ以上に応答して、前記元の構成を修正する必要があると判断するステップと、
前記動的プロビジョニングシステムによって、前記元の構成を修正する必要があると判断したことに応答して、修正構成を定義する第２の複数のリソースを割り当てるステップと、
前記動的プロビジョニングシステムによって、前記クライアントデバイスによるアクセスのために前記修正構成を配備するステップと、
を含む、非一時的コンピュータ可読記憶デバイス。
【請求項１２】
前記事前定義された性能測定値および前記事前定義された容量測定値が、前記元の構成に関連する履歴性能情報および履歴消費情報を分析することによって決定される、請求項１１に記載の非一時的コンピュータ可読記憶デバイス。
【請求項１３】
前記事前定義された性能測定値および前記事前定義された容量測定値が、前記元の構成に関連するリアルタイム性能測定値およびリアルタイム容量測定値を分析することによって決定される、請求項１１に記載の非一時的コンピュータ可読記憶デバイス。
【請求項１４】
前記事前定義された性能測定値が、トランザクション数、トランザクションレート、コミット数、平均ダウンタイム、最大ダウンタイム、およびアプリケーション応答時間のうちの１つまたは複数である、請求項１１に記載の非一時的コンピュータ可読記憶デバイス。
【請求項１５】
前記事前定義された容量測定値が、システムＣＰＵ使用率メトリック、アプリケーションＣＰＵ使用率メトリック、使用されたメモリ量、使用可能メモリ量、およびインフラストラクチャ構成要素の可用性のうちの１つまたは複数である、請求項１１に記載の非一時的コンピュータ可読記憶デバイス。
【発明の詳細な説明】
【技術分野】
【０００１】
関連出願の相互参照
本出願は、参照によりその全体が本明細書に組み込まれる、２０１６年３月１０日に出願された米国仮特許出願第６２／３０６，４２９号に対する優先権を主張する。
【０００２】
本開示は、一般に、分散コンピュータシステム上の企業レベルの情報をサポートするためにコンピューティングリソースを管理し割り当てるシステムおよび方法に関し、より詳細には、情報システムを稼働するために必要とされるそのようなリソースの消費の増加を予測して、またはそれに応答して、コンピューティングリソースを動的にプロビジョニングするためのシステムおよび方法に関する。
【背景技術】
【０００３】
エンタープライズリソースプランニング（ＥＲＰ）システムなどの情報システムは、組織の様々な領域内や領域間、または通信可能に結合された異なるエンティティ間で情報とプロセスを統合するソフトウェアソリューションを含み得るため、企業全体の情報を表示し、企業全体の意思決定を行い、実施することができる。ＥＲＰシステムは、ユーザ、顧客、マネージャ、および他の利害関係者からの情報として膨大な量のデータの生成、収集、および処理に継続的に従事している。特定の期間には、ＥＲＰシステムに割り当てられたコンピューティングリソースに高い要求が課せられ、これらのリソースは、割り当てられたリソースが、給与支払い前後のトランザクションの増加や季節販売の顧客注文数の増加など、リソース消費の突然の急増を満たすのに十分ではないため、ストレスがかかる。そのため、クライアントは通常、リソースに対するこれらの低頻度の要求をサポートするために必要なリソースよりも多くのリソースを購入する。他の期間では、ＥＲＰシステムに割り当てられたリソースが十分に活用されていないため、クライアントは消費されていないリソースに対して高いコストを支払うことになる。変化するニーズに対応してコンピューティングリソースを迅速にプロビジョニングするためのテクノロジは、手動プロセスを伴う傾向があり、ベンダや技術に特有のもの、特定のクラウド環境に限定されているものがある。
【発明の概要】
【発明が解決しようとする課題】
【０００４】
本明細書では、当技術分野の欠点に対処するシステムおよび方法が開示され、情報システムの効率および生産性の向上、コストの削減、ビジネス競争上の利点の獲得などの任意の数の追加の利点を提供することができる。本明細書で説明するシステムおよび方法は、エンタープライズリソースプランニングシステムのためのコンピューティングリソースの動的プロビジョニングを提供する。動的プロビジョニングシステムは、クライアントデバイスからの選択時にコンピューティングリソースの元の構成をプロビジョニングし、その後、情報システムのリアルタイム性能を評価することによって、または情報システムの履歴性能および履歴消費情報を分析することによって、または情報システムの将来の性能によってもたらされるコンピューティングリソースへの予想されるストレスを予測するための組合せを使用することによって、さらに動的なプロビジョニングを提供する。
【課題を解決するための手段】
【０００５】
特定の実施形態は、エンタープライズリソースプランニングシステムのためのコンピューティングリソースの動的プロビジョニング方法を含む。この方法は、動的プロビジョニングシステム（例えば、サーバ）によって、エンタープライズリソースプランニングシステムのための第１の複数のコンピューティングリソースの選択をクライアントデバイスから受信し、リソース管理データベースに第１の複数のレコードとして格納するステップと、動的プロビジョニングシステムによって、クライアントデバイスによるアクセスのための元の構成を定義する第１の複数のコンピューティングリソースを割り当てて配備するステップと、元の構成を含むエンタープライズリソースプランニングシステムからリアルタイム消費情報を受信するステップと、元の構成に関連し、リソース管理データベースに第３の複数のレコードとして格納されるプロビジョニング閾値を決定するステップと、第２の複数のレコードのうちの２つ以上に対して事前設定された関係を満たす第３の複数のレコードのうちの２つ以上に応答して、元の構成を修正する必要があると判断するステップと、元の構成を修正する必要があると判断したことに応答して、修正構成を定義する第２の複数のリソースを割り当てるステップと、動的プロビジョニングシステムによって、クライアントデバイスによるアクセスのために修正構成を配備するステップと、を含む。リアルタイム消費情報は、リアルタイム性能測定値およびリアルタイム容量測定値を含み、リソース管理データベースに第２の複数のレコードとして格納される。プロビジョニング閾値は、事前定義された性能測定値および事前定義された容量測定値を含む。事前定義された性能測定値および事前定義された容量測定値を、元の構成情報に関連する履歴性能情報および履歴消費情報を分析することによって決定することができる。事前定義された性能測定値および事前定義された容量測定値を、元の構成に関連するリアルタイム性能測定値およびリアルタイム容量測定値を分析することによって決定することができる。
【０００６】
事前定義された性能測定値を、限定されないが、トランザクション数、トランザクションレート、コミット数、平均ダウンタイム、最大ダウンタイム、ダウンタイム期間、ログイン試行回数、およびアプリケーション応答時間のうちの１つもしくは複数または任意の組合せとすることができる。事前定義された容量測定値を、システムＣＰＵ使用率メトリック、アプリケーションＣＰＵ使用率メトリック、使用されたメモリ量、使用可能メモリ量、ネットワークリソース消費量、インフラストラクチャ構成要素の可用性のうちの１つまたは複数とすることができる。事前定義された性能測定値を、新しいアプリケーション環境の作成、アプリケーションの配備または再配備、および新しいライフサイクル段階へのアプリケーションの統合で消費される時間とリソースに焦点を当てた１つまたは複数のメトリックとすることができる。他の事前定義された性能測定値は、ネットワーク待ち時間、輻輳、サービス品質測定値を含むことができる。事前定義された容量測定値を、リソースプールで利用可能なプラットフォームおよびビジネスサービスの測定値、ならびに、限定されないが、ハードウェアシステム、ストレージ、およびネットワーキングリソースを含むインフラストラクチャのサイズ、使用率、および可用性の１つまたは複数とすることができる。特定の実施形態は、ＰａａＳ（Platform as a Service）またはＩａａＳ（Infrastructure as a Service）などのクラウドベースのサービスを含む他のサービスを提供するエンタープライズリソースプランニングシステムを含むことができる。事前定義された性能測定値と事前定義された容量測定値を、クライアントのニーズに合わせて調整すること、または企業システムによって提供されるサービスに関連する標準的な測定値にすることができる。
【０００７】
特定の実施形態は、エンタープライズリソースプランニングシステムのためのコンピューティングリソースを動的にプロビジョニングするためのシステムを含む。このシステムは、リソース管理データベースと、リソース管理データベースに通信可能に結合された１つまたは複数のプロセッサと、１つまたは複数のプロセッサと通信して配置され、命令のセットを含むコンピュータプログラムが格納された非一時的コンピュータ可読媒体とを含む。命令のセットが１つまたは複数のプロセッサによって実行されると、１つまたは複数のプロセッサは、エンタープライズリソースプランニングシステムのための第１の複数のコンピューティングリソースの選択をクライアントデバイスから受信し、リソース管理データベースに第１の複数のレコードとして格納し；クライアントデバイスによるアクセスのための元の構成を定義する第１の複数のコンピューティングリソースを割り当てて配備し；元の構成を含むエンタープライズリソースプランニングシステムからリアルタイム消費情報を受信し；元の構成に関連するプロビジョニング閾値を決定し、リソース管理データベースに第３の複数のレコードとして格納し；第２の複数のレコードのうちの２つ以上に対して事前設定された関係を満たす第３の複数のレコードのうちの２つ以上に応答して、元の構成を修正する必要があると判断し；元の構成を修正する必要があると判断したことに応答して、修正構成を定義する第２の複数のリソースを割り当て；動的プロビジョニングシステムによって、クライアントデバイスによるアクセスのために修正構成を配備する動作を実行する。
【０００８】
本開示の複数の他の態様、特徴および利点は、図面と併せて以下の詳細な説明から明らかとされよう。システムには、必要な分析目標に応じて、より少ない構成要素、より多くの構成要素、または異なる構成要素を含めることができる。前述の一般的な説明および以下の詳細な説明の両方は、例示的かつ説明的であり、特許請求の範囲に記載された発明のさらなる説明を提供することが意図されていることもさらに理解されるべきである。
【０００９】
本開示は、以下の図面を参照することにより、よりよく理解することができる。図面の構成要素は、必ずしも縮尺通りではない。代わりに、本開示の原理を説明することに重点を置く。図面において、参照番号は、異なる図を通して対応する部分を示している。
【図面の簡単な説明】
【００１０】
【図１】例示的な実施形態による、ＥＲＰシステムのための動的プロビジョニングシステムを含むシステムを示すブロック図である。
【図２】例示的な実施形態による、ＥＲＰシステムのための動的プロビジョニングシステムを含む別のシステムを示すブロック図である。
【図３】例示的な実施形態による、ＥＲＰシステムのための動的プロビジョニングシステムを含む方法を示すフローチャートである。
【図４】一実施形態による、所与の期間にわたるトランザクションパターンを示す例示的なトランザクションヒートマップである。
【図５】一実施形態による、所与の期間にわたるログインパターンを示す例示的なログインヒートマップである。
【図６】例示的な実施形態による、所与の期間にわたるトランザクションおよび対応するＣＰＵ使用率の重ねられたプロットのグラフ表示である。
【図７】別の例示的な実施形態による、所与の期間にわたるトランザクションおよび対応するＣＰＵ使用率の重ねられたプロットのグラフ表示である。
【発明を実施するための形態】
【００１１】
ここで、図面に示された例示的な実施形態を参照し、特定の用語を用いてこれを説明する。ただし、本発明の範囲を限定するものではないことを理解されたい。本開示を所有する当業者が考えつく、本明細書に示された本発明の特徴の改変およびさらなる修正、および本明細書に示されている本発明の原理の追加的な適用は可能であり、これらは本発明の範囲内であるとみなされるべきである。
【００１２】
本明細書で使用される場合、以下の用語は、以下の定義を有することができる：
【００１３】
「動的プロビジョニングシステム」は、限定はされないが、エンタープライズリソースプランニングシステムのための適切なシステム、データ、およびソフトウェアでコンピューティングリソースを割り当ててプロビジョニングするソフトウェアを含む適切なロジックを使用して、データを処理し、ルールを実行し、データマッチングを実行する１つまたは複数のソフトウェアモジュールを指す。動的プロビジョニングシステムは、システムオプションの利用可能なカタログからシステムを動的に作成し、オペレーティングシステム、デバイスドライバ、ミドルウェア、およびアプリケーションなどの適切なソフトウェアを使用してそれらを設定し、新しくプロビジョニングされたシステムは、クライアントデバイスでのＥＲＰシステムの要求をサポートする準備が整う。
【００１４】
「コンピューティングリソース」は、動的プロビジョニングシステムがアクセスできる共有プール内のネットワーク、システム、サーバ、ストレージ、アプリケーション、アプライアンス、およびサービス、ならびに待ち時間、ジオグラフィ、応答性、帯域幅、記憶容量、処理速度、処理タイプ、関連するプラットフォーム、関連するデータ、使用されるプロトコル、および特定の組織要件など、これらのリソースの開発、配備、または性能に関連する特性や属性に関する情報を指す。
【００１５】
通常、企業システムは過剰にプロビジョニングされている。企業システムは複雑であり、このため、単純なシステムのようにストレスを示さない。したがって、単純なインフラストラクチャまたはプラットフォームメトリックに基づいて利用可能なコンピューティングリソースを自動的に拡張および縮小することは、ほとんどの企業アプリケーションでは不十分である。動的プロビジョニングシステムは、企業アプリケーション自体の内部性能を評価することによってＥＲＰをサポートするリソースへのストレスを測定し、企業アプリケーションの内部性能に関する履歴性能および履歴消費データを分析することによって、将来の性能によってもたらされるリソースへの予想されるストレスを予測する。リアルタイム分析は、アプリケーション内からのリアルタイムの性能データに基づいており、一方予測分析はアプリケーション内からの性能の履歴データに基づいている。これらの分析の一方または両方は、動的プロビジョニングシステムによって利用され、企業アプリケーション構成要素および／またはインフラストラクチャのスケーリングされた構成を自動的に提供する。
【００１６】
特定の実施形態は、エンタープライズリソースプランニングシステムにおけるコンピューティングリソースの動的プロビジョニングのためのシステムを含む。このシステムは、リソース管理データベースと、リソース管理データベースに通信可能に結合された１つまたは複数のプロセッサと、１つまたは複数のプロセッサと通信して配置され、命令のセットを含むコンピュータプログラムが格納された非一時的コンピュータ可読媒体とを含む。これらの命令が１つまたは複数のプロセッサによって実行されると、１つまたは複数のプロセッサは、第１の複数のコンピューティングリソースの選択をクライアントデバイスから受信し、リソース管理データベースに第１の複数のレコードとして格納し；クライアントデバイスによるアクセスのための元の構成を定義する第１の複数のコンピューティングリソースを割り当てて配備し；元の構成に関連するプロビジョニング閾値を指定し、第２の複数のレコードとしてリソース管理データベースに格納し；元の構成を含むエンタープライズリソースプランニングシステムからリアルタイム消費情報を受信し、第３の複数のレコードとしてリソース管理データベースに格納し；第２の複数のレコードのうちの２つ以上に対して事前設定された関係を満たす第３の複数のレコードのうちの２つ以上に応答して、元の構成を修正する必要があると判断し；元の構成を修正する必要があると判断したことに応答して、修正構成を定義する第２の複数のリソースを割り当て；動的プロビジョニングシステムによって、クライアントデバイスによるアクセスのために修正構成を配備する動作を実行する。
【００１７】
図１は、一実施形態による、ＥＲＰシステムのための動的プロビジョニングシステムを含むシステムを示すブロック図である。本開示全体に使用される例示的な実施形態は、ＥＲＰシステムを説明するが、任意の情報システムを使用することができることが意図される。本明細書で説明される方法に含まれる複数のステップは、例えば、１００に記載されたシステムなどの１つまたは複数のコンピューティングデバイスによって実行されてもよい。動的プロビジョニングシステム１１８の様々な構成要素のそれぞれは、上述のように構成された、デジタルデータを受信、処理、および／または送信する適切なプロセッサ制御デバイスを含む、任意のタイプのコンピュータベースのアーキテクチャで実装され得る。１つまたは複数の適切なプロセッサ制御デバイスを組み込んだデバイスの例には、スマートフォン、デスクトップコンピュータ、ラップトップコンピュータ、サーバ、タブレット、ＰＤＡ、ならびに企業データ処理、ルールマッチング、および通知アルゴリズムを実行する特殊コンピューティングプラットフォームなどが含まれる。
【００１８】
特定の実施形態では、ユーザデバイス１０２，１０４，および１０６は、個々にまたは組み合わせて、ＥＲＰシステムにおいて１または複数のトランザクションを実行し、ネットワーク１１６を介して動的プロビジョニングシステム１１８と対話するクライアントデバイス１０１を備える。動的プロビジョニングシステム１１８は、１つまたは複数のデータストアに結合されるか、または１つまたは複数のデータストアを含むことができる１つまたは複数のサーバを含むことができる。１つまたは複数のユーザデバイス１０２，１０４，および１０６は、許可されたユーザデバイスであってもよく、許可されたユーザによってアクセスされてもよく、コンピューティングリソースのセットを選択して、組織のＥＲＰシステムの要件に最適にサービスすることができる。ユーザは事前に設定された構成の一覧から選択するか、独自の構成を構築することができる。動的プロビジョニングシステム１１８は、プロビジョニングのために利用可能なコンピューティングリソース１２２に問い合わせを行い、サーバ１２４ａ，１２４ｂ，〜１２４ｎの１つまたは複数、サービス１２６ａ，１２６ｂ，〜サービス１２６ｎの１つまたは複数、およびアプリケーション１２８ａ，１２８ｂ，〜１２８ｎの１つまたは複数を評価して、クライアントデバイス１０１からの選択された構成とコンピューティングリソースのタイプ（複数可）、容量、および組合せを一致させる。コンピューティングリソースの成功した一致はまた、コンピューティングリソースをクライアントデバイス１０１にプロビジョニングするための適用可能なポリシーのチェックを含む。例えば、クライアントデバイス１０１からのコンピューティングリソースの選択は、クライアントとプロバイダとの間の契約上の制限、および要求されているコンピューティングリソースの様々な構成要素間の関係に関する他のベストプラクティス制限に対してチェックされる。プロビジョニングのために利用可能なコンピューティングリソース１２２は、限定されないが、クラウドインフラストラクチャ内にあってもよく、複数のクラウドコンピューティングリソースから構築されてもよく、またはクラウドコンピューティングリソースとノンクラウドコンピューティングリソースとの組合せであってもよい。クラウドコンピューティングリソースは、内部クラウド、外部クラウド、プライベートクラウド、パブリッククラウド（例えば、商業クラウド）、またはこれらのリソースのハイブリッドを含むことができる。クラウドコンピューティングリソースは、限定されないが、内部プライベートクラウドリソース、外部プライベートクラウドリソース、セキュアパブリッククラウドリソース、またはそれらの組合せを含むことができる。プライベートクラウドは、限定されないが、Ｅｕｃａｌｙｐｔｕｓ  Ｓｙｓｔｅｍｓ、ＶＭＷａｒｅ  ｖＳｐｈｅｒｅ（登録商標）、またはＭｉｃｒｏｓｏｆｔ（登録商標）ＨｙｐｅｒＶなどを含む様々なクラウドシステムを使用して実装されてもよい。パブリッククラウドのプロバイダには、Ａｍａｚｏｎ  Ｗｅｂ  Ｓｅｒｖｉｃｅｓ（登録商標）、Ｔｅｒｒｅｍａｒｋ（登録商標）、Ｓａｖｖｉｓ（登録商標）、ＧｏＧｒｉｄ（登録商標）、Ｍｉｃｒ���ｓｏｆｔ  Ａｚｕｒｅ、Ｇｏｏｇｌｅクラウドなどが含まれてもよい。プロビジョニングのために利用可能なコンピューティングリソース１２２には、限定されないが、ストレージリソース（ストレージエリアネットワーク（ＳＡＮ）、ネットワークファイルシステム（ＮＦＳ）、およびＡｍａｚｏｎ  Ｓ３（登録商標）など）、ネットワークリソース（ファイアウォール、ロードバランサ、プロキシサーバなど）、内部プライベートリソース、外部プライベートリソース、セキュアパブリックリソース、ＩａａＳ（Infrastructure as a Service）、ＰａａＳ（Platform as a Service）、またはサービスとしてのソフトウェア（ＳａａＳ）などが含まれてもよい。
【００１９】
動的プロビジョニングシステム１１８は、サーバ１および２のすべてまたは一部を有するパッケージ１１０、サービス１および２のすべてまたは一部を有するパッケージ１１２、アプリケーション１および２へのアクセスを有するパッケージ１１４などの物理および仮想環境を含む元の構成１０８として知られているこのリソースのセットを配備する。動的プロビジョニングシステム１１８は、関連アルゴリズムまたはコンピュータ実行可能プログラム命令を実行するための処理ユニットを含むシステム（例えば、サーバ）上で動作するソフトウェアとして実装されてもよい。動的プロビジョニングシステム１１８は、１つのプロセッサを含む単一プロセッサシステムを使用して実装されてもよく、または、本明細書で説明される技術の１つまたは複数の部分の並列および／または順次実行を提供するために使用され得る任意の数の適切なプロセッサを含むマルチプロセッサシステムを使用して実装されてもよい。本明細書で説明するプロセスおよび論理フローは、入力データを操作して対応する出力を生成することによって機能を実行する１つまたは複数のコンピュータプログラムを実行する１つまたは複数のプログラム可能なプロセッサによって実行されてもよい。処理ユニットは、プロセッサに結合されたランダムアクセスメモリ（ＲＡＭ）（図示せず）などのコンピュータ可読媒体を備えたプロセッサを含むことができる。プロセッサの例には、マイクロプロセッサ、特定用途向け集積回路（ＡＳＩＣ）、およびフィールドプログラマブルオブジェクトアレイ（ＦＰＯＡ）などが含まれてもよい。
【００２０】
いくつかの実施形態では、動的プロビジョニングシステム１１８を、サーバやユーザコンピューティングデバイスなどの一部として実装することができる。動的プロビジョニングシステム１１８の適切な実装の例には、デジタルデータを受信、処理、および／または送信するサーバおよび他のタイプのプロセッサ制御デバイスが含まれる。一例では、動的プロビジョニングシステム１１８は、システムアーキテクチャ１００の適切な動作に必要な特定の動作を実行する。適切な動的プロビジョニングシステム１１８は、メモリなどのコンピュータ可読媒体内に含まれるソフトウェア命令を実行する中央処理ユニットの結果として、これらの動作を実行する。一実施形態では、システムのソフトウェア命令は、動的プロビジョニングシステム１１８に関連するメモリに、記憶デバイスなどの別のメモリロケーションから、または通信インタフェースを介して別のコンピューティングデバイスから読み込まれる。この実施形態では、メモリ内に含まれるソフトウェア命令は、動的プロビジョニングシステム１１８に上述のプロセスを実行するよう指示する。あるいは、本明細書で説明するプロセスを実装するために、ハードウェア回路が、ソフトウェア命令の代わりに、またはソフトウェア命令と組み合わせて使用されてもよい。したがって、本明細書で説明される実装形態は、ハードウェア回路およびソフトウェアの特定の組合せに限定されない。
【００２１】
動的プロビジョニングシステム１１８は、リソース管理データベース１２０に通信可能に結合される。１つまたは複数の実施形態では、リソース管理データベース１２０は、限定されないが、会計および財務、人的リソース、製造、在庫管理、販売およびマーケティング、購入、倉庫、出荷、および他の物流からのデータを含むＥＲＰシステムからのデータ、ならびに、各クライアントデバイス１０１または個々のユーザデバイス１０２，１０４，および１０６に対応する性能および容量測定値に関連するデータを含むクライアントシステムからのデータも含む。
【００２２】
リソース管理データベース１２０は、外部ソースと内部データベースの組合せとして構成されてもよく、データの取り出し、索引付け、および格納の機能を提供するように実装される。これらの実施形態では、リソース管理データベース１２０は、さらなる分析のために、前述のデータおよび他の格納されたデータおよびファイルを動的プロビジョニングシステム１００内の１つまたは複数のソフトウェアモジュールに提供する。外部ソースから受け取ったデータの例には、在庫管理、販売、顧客対話、財務記録などが含まれる。リソース管理データベース１２０は、限定されないが、ＭｙＳＱＬ、ＰｏｓｔｇｒｅＳＱＬ、ＳＱＬｉｔｅ、Ｍｉｃｒｏｓｏｆｔ  ＳＱＬ  Ｓｅｒｖｅｒ、Ｍｉｃｒｏｓｏｆｔ  Ａｃｃｅｓｓ、Ｏｒａｃｌｅ、ＳＡＰ、ｄＢＡＳＥ、ＦｏｘＰｒｏ、ＩＢＭ  ＤＢ２、ＬｉｂｒｅＯｆｆｉｃｅ  Ｂａｓｅ、ＦｉｌｅＭａｋｅｒ  Ｐｒｏ、および／またはデータの集合を編成することができるその他のタイプのデータベースなどのデータベース管理システム（ＤＢＭＳ）を介して実装されてもよい。これらの実施形態では、リソース管理データベース１２０は、例えば、軽量ディレクトリアクセスコントロール（Lightweight Directory Access Control、ＬＤＡＰ）などの分散ディレクトリ情報サービスまたはデータフィードにアクセスし、それを維持するためのアプリケーションプロトコルを使用して実装されることができる。データベースのフィールドに格納されたデータは、必要に応じて、例えばデータベースへの管理アクセス権を持つユーザによって更新され、サポートされるようにデータベースのライブラリに新しいデータを追加することができる。当業者であれば、本明細書に記載のデータベースに格納されているデータを非一時的メモリに格納または維持し、サブルーチン、関数、モジュール、オブジェクト、プログラム製品またはプロセスの間で、例えば、そのようなサブルーチン、関数、モジュール、オブジェクト、プログラム製品またはプロセスのオブジェクトおよび／または変数に従って、アクセスすることもできることを理解されよう。データベースのレコード、テーブル、ライブラリなどのフィールドは、配列や行列に似た多次元構造にされることができ、値や他のフィールド、レコード、テーブル、ライブラリへの参照を含むことができる。前述のフィールドは、実際の値、またはそのような値のリンク、結合、参照、他のローカルソースもしくはリモートソースへのポインタを含むことができる。外部ソースを、例えば、Ｗｏｒｌｄ  Ｗｉｄｅ  Ｗｅｂ上のサーバなど、複数のソースからのデータを含む、単一のデータベース、複数のデータベース、または仮想データベースとすることができる。
【００２３】
電子通信ネットワーク１１６は、任意の通信アーキテクチャを含むことができる。例えば、限定されないが、システム１００を形成する１つまたは複数のコンピューティングデバイスに存在する送信機と受信機との間の通信を容易にするデバイスおよびソフトウェアが含まれる。また、当業者には、ネットワーク構成要素が専用処理装置内に、あるいはクラウド処理ネットワーク内に実装されてもよいことは明らかである。ネットワーク１１６は、イントラネット、ローカルエリアネットワーク（ＬＡＮ）、クラウドネットワーク、仮想プライベートネットワーク（ＶＰＮ）、無線エリアネットワーク（ＷＡＮ）、インターネット、またはサーバとユーザデバイスとの相互作用を可能にする他のネットワークであってもよい。ネットワークを構成するデバイスの非限定的な例には、ルータ、スイッチ、ハブ、ファイアウォール、プロキシサーバ、電気通信トランクなどが含まれてもよい。したがって、電子通信ネットワークを、無線もしくは有線の通信ネットワークまたはその両方の組合せによって、全体的または部分的に実装することができる。さらに、本発明の様々な例示的な実施形態によれば、無線通信ネットワークは、様々な無線通信技術、例えば、符号分割多重アクセス（code division multiplexed access、ＣＤＭＡ）、移動通信のためのグローバルシステム（global system for mobile communications、ＧＳＭ（登録商標））、およびＷｉＦｉ、ワイマックス（World Interoperability for Microwave Access、ＷｉＭＡＸ）、またはＢｌｕｅｔｏｏｔｈ（登録商標）などの無線ローカルエリアネットワークのいずれかで実装されることができる。
【００２４】
動的プロビジョニングシステム１１８は、ユーザデバイス１０２，１０４，および１０６を含むコンピューティングデバイス上のユーザインタフェースを生成する。そのようなデバイスは、動的プロビジョニングシステム１００の他のデバイス、データベース、および構成要素と通信可能に結合され、双方向通信している。ユーザデバイス１０２，１０４，および１０６を、ラップトップコンピュータもしくはデスクトップコンピュータ、またはスマートフォン、携帯電話、タブレット、パーソナルデジタルアシスタント（ＰＤＡ）などのモバイルコンピューティングデバイス、スマート電話クライアントを備えたモバイルコンピュータ、またはその他のデータアクセスが可能なデバイスとすることができる。動的プロビジョニングシステム１１８は、ユーザインタフェースを利用して、１人または複数のユーザとの間で情報を要求し、収集し、提示する。ユーザは、タッチスクリーンまたはマウス、ディスプレイと協働して動作するキーボードおよび／またはキーパッドなどの入出力（Ｉ／Ｏ）デバイスを介してユーザインタフェースと対話する。いくつかの実施形態では、動的プロビジョニングシステム１１８のデータ処理モジュールは、１つまたは複数のコンピューティングデバイス１０２，１０４，および１０６または１つまたは複数のソフトウェアモジュールによって要求された情報を自動的に検索するようにさらに構成される。特定の実施形態では、この情報は、ＥＲＰシステム内の１つまたは複数のソフトウェアモジュールの動作から得られる。動的プロビジョニングシステム１１８は、限定されないが、元の構成１０８のサーバパッケージ１１０、オペレーティングサービスパッケージ１１２、およびアプリケーションパッケージ１１４を含む１つまたは複数の物理および仮想環境に通信可能に結合される。１つまたは複数の実施形態では、動的プロビジョニングシステム１１８は、１つまたは複数のアプリケーションプログラミングインタフェース（ＡＰＩ）、ＲＳＳフィード、または他の構造化されたフォーマットを介して、これらのサービス、アプリケーション、およびデータベースと対話することができる。ＡＰＩを、１つまたは複数のＡＰＩを制御および管理する任意のＲｅｐｒｅｓｅｎｔａｔｉｏｎａｌ  Ｓｔａｔｅ  Ｔｒａｎｓｆｅｒ（ＲＥＳＴ）のアプリケーションプログラミングインタフェース（ＡＰＩ）とすることができる。
【００２５】
特定の実施形態では、動的プロビジョニングシステム１１８がクライアントデバイス１０１から要求を受信すると、動的プロビジョニングシステム１１８は、適切な数の仮想マシンを作成し、それらをサポートするためにリソースを割り当てる。このプロセスは、いくつかの方法で起こり得る。例えば、事前プロビジョニングの場合、クライアントはサービスのためにプロバイダと契約することができ、両当事者間の契約内容に従って、フラット料金が課金されるか、毎月請求される。動的プロビジョニングでは、プロバイダはクライアントが必要とするときにさらに多くのリソースを割り当て、クライアントが必要としなくなったときにリソースをデコミットする。クライアントは、クライアントシステムによって実際に利用されるリソースに対してのみ支払いを行う。
【００２６】
次いで、動的プロビジョニングシステム１１８は、元の構成に関連するプロビジョニング閾値を決定し、それをリソース管理データベース１２０に複数のレコードとして格納することができる。特定の実施形態では、図１に示すように、プロビジョニング閾値は、拡張プロビジョニング閾値であってもよく、ＥＲＰシステムへのより多くのコンピューティングリソースのプロビジョニングをトリガする性能および容量測定値の上限を含む。このプロビジョニング閾値は、１つまたは複数のシステムＣＰＵ使用率メトリック、アプリケーションＣＰＵ使用率メトリック、メモリ消費量および可用性メトリックの上限を確立することができる。プロビジョニング閾値は、ネットワークバイト／秒、トランザクション数、レート、コミット数などのアプリケーション測定値、平均ダウンタイム、最大ダウンタイム、およびアプリケーション応答時間などのネットワーク測定値の上限を確立することができる。また、プロビジョニング閾値は、応答時間、待ち時間、構成要素の可用性、他の性能および容量測定値などのインフラストラクチャ構成要素の測定値の上限を確立することもできる。プロビジョニング閾値は、ＥＲＰシステム内およびすべての情報システムからの生データ、きれいにされたデータ、および／または充実されたデータを使用して決定されることができる。
【００２７】
動的プロビジョニングシステム１１８は、元の構成１０８を含むエンタープライズリソースプランニングシステムからリアルタイム消費情報を受信し、それを複数のレコードとしてリソース管理データベース１２０に格納する。リアルタイム消費情報は、システムのリアルタイム性能および容量測定値を含み、リソース管理データベース１２０に複数のレコードとして格納される。リアルタイム消費情報は、リアルタイムシステムＣＰＵ使用率メトリック、リアルタイムアプリケーションＣＰＵ使用率メトリック、リアルタイムメモリ消費量および可用性メトリック、ネットワークバイト／秒などのリアルタイムネットワーク測定値、トランザクション数やレート、コミット数、平均ダウンタイム、最大ダウンタイム、アプリケーション応答時間などのリアルタイムのアプリケーション測定値、応答時間、待ち時間、構成要素の可用性などのインフラストラクチャ構成要素の測定値、および他のリアルタイムの性能と容量測定値のうちの１つまたは複数を含む。リアルタイム消費情報を、ＥＲＰシステム内およびすべての情報システムからの生データまたはきれいにされたデータまたは充実されたデータを使用して決定することができる。
【００２８】
次に、動的プロビジョニングシステム１１８は、リアルタイム消費情報に関連する複数のレコードのうちの２つ以上を、プロビジョニング閾値に関連する複数のレコードのうちの２つ以上と比較して、事前設定された関係が満たされているかどうかを評価する。事前設定された関係の例には、限定されないが、リアルタイムシステムＣＰＵ使用率が、プロビジョニング閾値として設定されたシステムＣＰＵ使用率の７５％以上かどうか、またはトランザクションレートが１０００トランザクション／秒を超えるかどうかを判断することが含まれる。事前設定された関係が満たされている場合、動的プロビジョニングシステムは、元の構成１０８をＥＲＰシステムのニーズに対応するためのより適切な構成に拡張する必要があると判断する。動的プロビジョニングシステム１１８は、プロビジョニングのために利用可能なコンピューティングリソース１２２に問い合わせを行い、サーバ１２４ａ，１２４ｂ，〜１２４ｎ、サービス１２６ａ，１２６ｂ，〜サービス１２６ｎ、アプリケーション１２８ａ，１２８ｂ，〜１２８ｎを評価して、リアルタイム消費情報がプロビジョニング閾値を超えたときにクライアントデバイスのニーズを満たすために必要なコンピューティングリソースのタイプ（複数可）、容量、および組合せを一致させる。コンピューティングリソースの成功した一致はまた、コンピューティングリソースをクライアントデバイス１０１にプロビジョニングするための適用可能なポリシーのチェックを含む。例えば、クライアントデバイス１０１からのコンピューティングリソースの選択は、クライアントとプロバイダとの間の契約上の制限、および拡張構成１３０の下で組み立てられるコンピューティングリソースの様々な構成要素間の関係に関する他のベストプラクティス制限に対してチェックされる。
【００２９】
拡張構成１３０として提示される複数のリソースは、サーバ１，２，３，および４のすべてまたは一部を有するサーバパッケージ１３２、サービス１，２，３，４，および５のすべてまたは一部を有するサービスパッケージ１３４、およびアプリケーション１，２，３，４，５，および６へのアクセスを有するアプリケーションパッケージ１３６などのより多くのコンピューティングリソースを有する物理および仮想環境を含む。特定の実施形態では、動的プロビジョニングシステム１１８は、これらのリソースを評価して、ＥＲＰシステムの差し迫ったまたは将来のニーズに対応する機能の最適な配信を行う。拡張構成１３０は、エンタープライズリソースプランニングシステムの差し迫ったまたは将来のニーズに対応するためにクライアントデバイスによって必要とされる１つまたは複数のサーバ、アプリケーション、およびサービスを含む。拡張構成１３０は、これらのリソースの開発、配備、または性能に関連する特性または属性に関する情報も含む。特性または属性は、待ち時間、ジオグラフィ、応答性、帯域幅、記憶容量、処理速度、処理タイプ、関連するプラットフォーム、関連データ、使用されるプロトコル、および特定の組織要件を含むことができる。動的プロビジョニングシステム１１８は、クライアントデバイスによるアクセスのために拡張構成を配備することができる。拡張構成１１８の配備には、修正構成１３０を構成する複数のリソースを組み立て、検証し、利用可能にするために必要なすべてのタスクが含まれてもよい。
【００３０】
プロビジョニング閾値は、静的でも動的でもよい。プロビジョニング閾値は、クライアントデバイスに関連するエンタープライズリソースプランニングシステムに関連する履歴消費情報、またはクライアントデバイスに関連するエンタープライズリソースプランニングシステムから得られるリアルタイム消費情報、または両方のタイプの情報の組合せに基づいて決定されてもよい。動的プロビジョニングシステムを、限定されないが、Ｗｅｂ注文システム、サプライチェーンシステム、または顧客関係管理システムを含むＥＲＰシステムに通信可能に結合された他の組織システムとの間でデータを受信するように構成することができる。履歴消費情報およびリアルタイム消費情報を、ＥＲＰシステム内およびすべての情報システムからの生データまたはきれいにされたデータまたは充実されたデータとすることができる。プロビジョニング閾値は、事前定義された性能測定値および事前定義された容量測定値を含む。事前定義された性能測定値および事前定義された容量測定値を、元の構成情報に関連する履歴性能情報および履歴消費情報を分析することによって決定することができる。事前定義された性能測定値および事前定義された容量測定値を、元の構成に関連するリアルタイム性能測定値およびリアルタイム容量測定値を分析することによって決定することができる。
【００３１】
事前定義された性能測定値は、限定されないが、トランザクション数、トランザクションレート、コミット数、平均ダウンタイム、最大ダウンタイム、ダウンタイム期間、ログイン試行回数、および／またはアプリケーション応答時間であってもよい。事前定義された容量測定値は、システムＣＰＵ使用率メトリック、アプリケーションＣＰＵ使用率メトリック、使用されたメモリ量、使用可能メモリ量、ネットワークリソース消費量、および／またはインフラストラクチャ構成要素の可用性であってもよい。事前定義された性能測定値を、新しいアプリケーション環境の作成、アプリケーションの配備または再配備、および新しいライフサイクル段階へのアプリケーションの統合で消費される時間とリソースに焦点を当てた１つまたは複数のメトリックとすることができる。他の事前定義された性能測定値には、ネットワーク待ち時間、輻輳、サービス品質測定値が含まれてもよい。事前定義された容量測定値には、リソースプールで利用可能なプラットフォームおよびビジネスサービスの測定値、ならびに、限定されないが、ハードウェアサーバ、ストレージ、およびネットワーキングリソースを含むインフラストラクチャのサイズ、使用率、および可用性が含まれもよい。特定の実施形態は、ＰａａＳ（Platform as a Service）またはＩａａＳ（Infrastructure as a Service）などのクラウドベースのサービスを含む他のサービスを提供するエンタープライズリソースプランニングシステムを含んでもよい。事前定義された性能測定値と事前定義された容量測定値を、クライアントのニーズに合わせて調整してもよいし、企業システムによって提供されるサービスに関連する標準的な測定値にしてもよい。
【００３２】
プロビジョニング閾値は、本質的にリアクティブであり得る。例えば、動的プロビジョニングシステムは予想外に多数のトランザクションを検出する可能性があり、これはプロビジョニング閾値の一部として提供される測定値よりもはるかに高いため、追加のハードウェアとソフトウェアをプロビジョニングする。プロビジョニング閾値は、予測分析によって決定されてもよい。例えば、動的プロビジョニングシステム１１８は、履歴消費情報を分析することによって特定の使用パターンを認識することができる。これらのパターンを使用して、動的プロビジョニングシステム１１８は、クライアントデバイス上のユーザインタフェースに予測スケーリングオプションを提示することができる。ＥＲＰシステムで識別されたこれらのパターンの例としては、限定されないが、給与計算実行、ベネフィットオープンエンロールメントピリオド（benefit open enrollment period）、給与明細書セルフサービスなどがある。したがって、コンピューティングリソースに対する拡張されたストレスに先行する期間において、動的プロビジョニングシステム１１８は、システムのニーズに対処するためにコンピューティングリソースの拡張構成を提供することができる。動的プロビジョニングシステム１１８は、将来の分析のためにリソース管理データベース１２０に情報を送信することもできる。
【００３３】
図２は、一実施形態による、ＥＲＰシステムのための動的プロビジョニングシステムを含むシステムを示すブロック図である。本明細書で説明される方法に含まれる複数のステップは、例えば、２００に記載されたシステムなどの１つまたは複数のコンピューティングデバイスによって実行されてもよい。動的プロビジョニングシステム２００の様々な構成要素のそれぞれは、上述のように構成された、デジタルデータを受信、処理、および／または送信する適切なプロセッサ制御デバイスを含む、任意のタイプのコンピュータベースのアーキテクチャに実装され得る。特定の実施形態では、ユーザデバイス２０２，２０４，および２０６は、個々にまたは組み合わせて、ＥＲＰシステムにおいて１または複数のトランザクションを実行し、ネットワーク２１６を介して動的プロビジョニングシステム２１８と対話するクライアントデバイス２０１を備える。ユーザデバイス２０２，２０４，および２０６の１つまたは複数は、許可されたユーザデバイスであってもよく、許可されたユーザによってアクセスされてもよく、コンピューティングリソースのセットを選択して、組織のＥＲＰシステムの要件に最適にサービスすることができる。ユーザは事前に設定された構成の一覧から選択するか、独自の構成を構築することができる。動的プロビジョニングシステム２１８は、プロビジョニングのために利用可能なコンピューティングリソース２２２に問い合わせを行い、サーバ２２４ａ，２２４ｂ，〜２２４ｎの１つまたは複数、サービス２２６ａ，２２６ｂ，〜サービス２２６ｎの１つまたは複数、アプリケーション２２８ａ，２２８ｂ，〜２２８ｎの１つまたは複数を評価して、クライアントデバイス２０１からの選択された構成とコンピューティングリソースのタイプ（複数可）、容量、および組合せを一致させる。コンピューティングリソースの成功した一致はまた、コンピューティングリソースをクライアントデバイス２０１にプロビジョニングするための適用可能なポリシーのチェックを含む。プロビジョニングのために利用可能なコンピューティングリソース２２２は、クラウドインフラストラクチャ内にあってもよく、複数のクラウドコンピューティングリソースから構築されてもよく、またはクラウドコンピューティングリソースとノンクラウドコンピューティングリソースとの組合せであってもよい。
【００３４】
動的プロビジョニングシステム２１８は、サーバ１，２，３，および４のすべてまたは一部を有するサーバパッケージ２１０、サービス１，２，３，４，および５のすべてまたは一部を有するサービスパッケージ２１２、アプリケーション１，２，３，４，５，および６へのアクセスを有するアプリケーションパッケージ２１４などの物理および仮想環境を含む元の構成２０８として知られているこのリソースのセットを配備する。動的プロビジョニングシステム２１８は、リソース管理データベース２２０に通信可能に結合される。１つまたは複数の実施形態では、リソース管理データベース２２０は、限定されないが、会計および財務、人的リソース、製造、在庫管理、販売およびマーケティング、購入、倉庫、出荷、および他の物流からのデータを含むＥＲＰシステムからのデータ、ならびに、クライアントデバイス２０１のそれぞれに対応する性能および容量測定値に関連するデータ、または個々のユーザデバイス２０２，２０４，および２０６に関連するデータを含むクライアントシステムからのデータも含む。
【００３５】
リソース管理データベース２２０は、外部ソースと内部データベースの組合せとして構成されてもよく、データの取り出し、索引付け、および格納の機能を提供するリレーショナルデータベースとして実装される。動的プロビジョニングシステム２１８は、ユーザデバイス２０２，２０４，および２０６を含むコンピューティングデバイス上のユーザインタフェースを生成する。そのようなデバイスは、動的プロビジョニングシステム２００の他のデバイス、データベース、および構成要素と通信可能に結合され、双方向通信している。
【００３６】
特定の実施形態では、動的プロビジョニングシステム２１８がクライアントデバイス２０１から要求を受信すると、動的プロビジョニングシステム２１８は、適切な数の仮想マシンを作成し、それらをサポートするためにリソースを割り当てる。このプロセスは、いくつかの方法で起こり得る。例えば、事前プロビジョニングの場合、クライアントはプロバイダとサービス契約を締結し、両当事者間の契約内容に従って、フラット料金が課金されるか、毎月請求される。動的プロビジョニングでは、プロバイダはクライアントが必要とするときにさらに多くのリソースを割り当て、クライアントが必要としなくなったときにリソースをデコミットする。クライアントは、クライアントシステムによって実際に利用されるリソースに対してのみ支払いを行う。
【００３７】
次いで、動的プロビジョニングシステム２１８は、元の構成に関連するプロビジョニング閾値を決定し、それをリソース管理データベース２２０に複数のレコードとして格納する。  特定の実施形態では、図２に示されるように、プロビジョニング閾値は収縮プロビジョニング閾値であり、より少ないコンピューティングリソースのＥＲＰシステムへのプロビジョニングをトリガする性能および容量測定値の下限を含む。このプロビジョニング閾値は、システムＣＰＵ使用率メトリック、アプリケーションＣＰＵ使用率メトリック、メモリ消費量および可用性メトリック、ネットワークバイト／秒などのネットワーク測定値、トランザクション数やレート、コミット数、平均ダウンタイム、最大ダウンタイム、アプリケーション応答時間などのアプリケーション測定値、応答時間、待ち時間、構成要素の可用性などのインフラストラクチャ構成要素の測定値、および他の性能および容量測定値のうちの１つまたは複数の下限を確立する。プロビジョニング閾値は、ＥＲＰシステム内およびすべての情報システムからの生データ、きれいにされたデータ、または充実されたデータを使用して決定されることができる。
【００３８】
動的プロビジョニングシステム２１８は、元の構成２０８を含むエンタープライズリソースプランニングシステムからリアルタイム消費情報を受信し、それを複数のレコードとしてリソース管理データベース２２０に格納する。リアルタイム消費情報には、システムのリアルタイム性能および容量測定値が含まれる。次に、動的プロビジョニングシステム２１８は、リアルタイム消費情報に関連する複数のレコードのうちの２つ以上を、プロビジョニング閾値に関連する第２の複数のレコードのうちの２つ以上と比較して、事前設定された関係が満たされているかどうかを評価する。事前設定された関係の例には、限定されないが、リアルタイムシステムＣＰＵ使用率がプロビジョニング閾値として設定されたシステムＣＰＵ使用率の２５％以下かどうか、またはトランザクションレートが１００トランザクション／秒未満であるかどうかを判断することが含まれる。事前設定された関係が満たされている場合、動的プロビジョニングサーバは、元の構成２０８をＥＲＰシステムのニーズに対応するためにより適切な構成に縮小する必要があると判断する。動的プロビジョニングシステム２１８は、プロビジョニングのために利用可能なコンピューティングリソース２２２に問い合わせを行い、サーバ２２４ａ，２２４ｂ，〜２２４ｎ、サービス２２６ａ，２２６ｂ，〜サービス２２６ｎ、アプリケーション２２８ａ，２２８ｂ，〜２２８ｎを評価して、リアルタイム消費情報がプロビジョニング閾値未満であるときにクライアントデバイスのニーズを満たすために必要なコンピューティングリソースのタイプ（複数可）、容量、および組合せを一致させる。コンピューティングリソースの成功した一致はまた、コンピューティングリソースをクライアントデバイス２０１にプロビジョニングするための適用可能なポリシーのチェックを含む。例えば、クライアントデバイス２０１からのコンピューティングリソースの選択は、クライアントとプロバイダとの間の契約上の制限、および拡張構成２３０の下で組み立てられるコンピューティングリソースの様々な構成要素間の関係に関する他のベストプラクティス制限に対してチェックされる。
【００３９】
縮小構成２３０として提示される複数のリソースは、サーバ１および２のすべてまたは一部を有するサーバパッケージ２３２、サービス１，２，および３のすべてまたは一部を有するサービスパッケージ２３４、およびアプリケーション１，２，および３へのアクセスを有するアプリケーションパッケージ２３６などのより少ないコンピューティングリソースを有する物理および仮想環境を含む。縮小構成２３０には、エンタープライズリソースプランニングシステムの差し迫ったまたは将来のニーズに対応するためにクライアントデバイスによって必要とされる１つまたは複数のサーバ、アプリケーション、およびサービスが含まれ、待ち時間、ジオグラフィ、応答性、帯域幅、記憶容量、処理速度、処理タイプ、関連するプラットフォーム、関連するデータ、使用されるプロトコル、および特定の組織要件など、これらのリソースの開発、配備、または性能に関連する特性や属性に関する情報も含まれる。動的プロビジョニングシステム２１８は、クライアントデバイスによるアクセスのために縮小構成２３０を配備する。縮小構成２３０の配備には、縮小構成２３０を構成する複数のリソースを組み立て、検証し、利用可能にするために必要なすべてのタスクが含まれる。
【００４０】
縮小プロビジョニング閾値は、静的でも動的でもよい。このプロビジョニング閾値は、クライアントデバイスに関連するエンタープライズリソースプランニングシステムに関連する履歴消費情報、またはクライアントデバイスに関連するエンタープライズリソースプランニングシステムから得られるリアルタイム消費情報、または両方のタイプの情報の組合せに基づいて決定され得る。動的プロビジョニングシステムを、限定されないが、Ｗｅｂ注文システム、サプライチェーンシステム、または顧客関係管理システムを含むＥＲＰシステムに通信可能に結合された他の組織システムとの間でデータを受信するように構成することができる。履歴消費情報およびリアルタイム消費情報を、ＥＲＰシステム内およびすべての情報システムからの生データまたはきれいにされたデータまたは充実されたデータとすることができる。
【００４１】
縮小プロビジョニング閾値は、本質的にリアクティブであり得る。例えば、動的プロビジョニングシステムは予想外に少ない数のトランザクションを検出し、これはプロビジョニング閾値の一部として提供される測定値よりもはるかに少ないため、より少ないハードウェアおよびソフトウェアリソースをプロビジョニングする。プロビジョニング閾値を、予測分析によって決定することができる。例えば、動的プロビジョニングシステム２１８は、履歴消費情報を分析することによって特定の使用パターンを認識する。これらのパターンを使用して、動的プロビジョニングシステム２１８は、クライアントデバイス上のユーザインタフェースに予測スケーリングオプションを提示し、これにより、より少ないコンピューティングリソースが消費される。ＥＲＰシステムで識別されたこれらのパターンの例には、休暇スケジュールまたは金融四半期の中間が含まれるが、これらに限定されない。したがって、コンピューティングリソースに対するこれらのストレス期間の減少に先立って、動的プロビジョニングシステム２１８は、システムの必要性に対処するためにコンピューティングリソースの縮小構成を提供する。
【００４２】
特定の実施形態は、エンタープライズリソースプランニングシステムにおいてコンピューティングリソースを動的にプロビジョニングするための方法を含むことができる。図３は、例示的な実施形態による、ＥＲＰシステムのための動的プロビジョニングシステムを含む方法を示すフローチャートである。この方法は、ステップ３０２において、動的プロビジョニングシステムによって、クライアントデバイスから第１の複数のリソースの選択を受信し、リソース管理データベース３１４に第１の複数のレコードとして格納するステップを含むことができる。第１の複数のリソースは、エンタープライズリソースプランニングシステムを動作するためにクライアントデバイスによって必要とされる１つまたは複数のサーバ、アプリケーション、およびサービスを含み、待ち時間、ジオグラフィ、応答性、帯域幅、記憶容量、処理速度、処理タイプ、関連するプラットフォーム、関連するデータ、使用されるプロトコル、および特定の組織要件など、これらのリソースの開発、配備、または性能に関連する特性や属性に関する情報も含むことができる。次に、動的プロビジョニングシステムは、ステップ３０４において、クライアントデバイスによるアクセスのための元の構成を定義する第１の複数のコンピューティングリソースを割り当てて配備する。
【００４３】
元の構成に関連するプロビジョニング閾値は、ステップ３０６において動的プロビジョニングシステムによって決定され、リソース管理データベース３１４に複数のレコードとして格納されてもよい。特定の実施形態では、図１に示すように、プロビジョニング閾値は、ＥＲＰシステムへのより多くのコンピューティングリソースのプロビジョニングをトリガする性能および容量測定値の上限を含む拡張プロビジョニング閾値であってもよい。特定の実施形態では、図２に示すように、プロビジョニング閾値は、より少ないコンピューティングリソースのＥＲＰシステムへのプロビジョニングをトリガする性能および容量測定値の下限を含む収縮プロビジョニング閾値であってもよい。他の実施形態では、プロビジョニング閾値を、異なるコンピューティングリソースに適用される両方の組合せとすることができる。例えば、プロビジョニング閾値は、処理リソースの性能および容量測定値の上限と、アプリケーションリソースの性能および容量測定値の下限とを含むことができる。この場合、動的プロビジョニングシステムは、処理リソースを拡張し、アプリケーションリソースを減少させる、修正構成をクライアントデバイスに提示することができる。
【００４４】
元の構成を含むエンタープライズリソースプランニングシステムからのリアルタイム消費情報は、ステップ３０８において動的プロビジョニングシステムによって受信され、リソース管理データベース３１４に複数のレコードとして格納される。リアルタイム消費情報は、システムのリアルタイム性能および容量測定値を含むことができる。リアルタイム消費情報に関連する複数のレコードのうちの２つ以上が、ステップ３１０において、プロビジョニング閾値に関連する第２の複数のレコードの２つ以上と比較され、事前設定された関係が満たされているかどうかを評価する。拡張および縮小プロビジョニング閾値の組合せを含む事前設定された関係の例には、リアルタイムシステムＣＰＵ使用率がプロビジョニング閾値として設定されたシステムＣＰＵ使用率の７５％以上であるかどうか、および／またはトランザクションレートが１０００トランザクション／秒を超え、消費されるアプリケーションリソースの数が３であるかどうかを決定することが含まれる。この場合、事前設定された関係が満たされれば（３１２）、動的プロビジョニングシステムは、プロビジョニングのために利用可能なコンピューティングリソースに問い合わせを行い、評価することができる。コンピュータリソースは、例えば、サーバ、サービス、およびアプリケーションを含み、クライアントデバイスのニーズを満たすために必要とされるコンピューティングリソースのタイプ（複数可）、容量、および組合せを一致させることができる。コンピューティングリソースの一致が成功すると、修正構成を構成する第２の複数のリソースが、ステップ３１６において、クライアントデバイスによるアクセスのために組み立てられ、割り当てられ、配備される。上述の例において修正構成として提示された複数のリソースは、特定の拡張されたリソースと、より多くのサーバであるがより少ないアプリケーションのような特定の縮小リソースとを含む。修正構成には、エンタープライズリソースプランニングシステムの差し迫ったまたは将来のニーズに対応するためにクライアントデバイスによって必要とされる１つまたは複数のサーバ、アプリケーション、およびサービスが含まれ、待ち時間、ジオグラフィ、応答性、帯域幅、記憶容量、処理速度、処理タイプ、関連するプラットフォーム、関連するデータ、使用されるプロトコル、および特定の組織要件など、これらのリソースの開発、配備、または性能に関連する特性や属性に関する情報も含まれる。事前設定された関係が満たされない場合（３１８）、動的プロビジョニングシステムは元の構成に変更を加えず、リアルタイム消費を監視し続ける。修正構成の配備には、縮小構成を構成する複数のリソースを組み立て、検証し、利用可能にするために必要なすべてのタスクが含まれる。
【実施例１】
【００４５】
例示的な動的プロビジョニングシステムでは、ユーザは、動的プロビジョニングシステムによって提示されるウェブインタフェースにログインし、ユーザに提示される標準的な製品カタログから製品を選択する。一例として、最大５０人の指定ユーザの中規模の情報システムがある。ユーザには、給与税システムやＡ／Ｐ請求書スキャンのためのコンピューティングリソースなど、電子インタフェースでの選択のための付加的な補助アプリケーションも提示される。動的プロビジョニングシステムは、サービスプロバイダ、ＡＷＳ（Ａｍａｚｏｎ）、Ｍｉｃｒｏｓｏｆｔ  Ａｚｕｒｅ、またはユーザの内部データセンターによるカスタマイズされたデータセンターなど、この新しいシステムの宛先に関する詳細を表示するユーザインタフェースを提示する。すべての選択が完了すると、動的プロビジョニングシステムは、製品カタログからユーザ選択に対応するコンピューティングリソースパッケージを検索する。これらのパッケージは、インフラストラクチャのプロビジョニングと選択されたソフトウェアのインストールを実現するために何を行う必要があるかを示す。これらのパッケージには、インフラストラクチャのためのサーバ（仮想）、ネットワーク、セキュリティ、ゾーンの可用性、負荷分散、ストレージなどの定義が含まれ、さらにインフラストラクチャの完成後にアプリケーションに必要なソフトウェアと構成が含まれる。ここで、これらのパッケージは、プロプライエタリとオープンソースのソフトウェアの組合せを使用して、選択された宛先データセンターでＡＰＩを呼び出して指示を送信するときに、動的プロビジョニングシステムをガイドする。ユーザが所望されるまたは必要とされるコンピューティングリソースに関する選択を行うことができる標準製品のカタログは、ユーザデバイス上で利用可能にされる。この製品カタログおよび自動化により、ユーザは１００％一貫したシステムを作成および再作成することができる（つまり、練習用に製品の複製を作成する）。これらのカタログおよび選択を、サービスレベル契約の一部とすることができる。動的プロビジョニングシステムは、事実上任意のデータセンター（プライベートまたはパブリック）で動作することができ、また、異種クラウドにあるシステムのためにユーザデバイスをシステム管理の単一ポイントにすることもできる。動的プロビジョニングシステムの機能の一部として、顧客の課金が統合され自動化される。ユーザデバイスが練習用の製品の複製のようなリソースを必要としなくなったときに、コンピューティングリソースを容易にデコミットすることができる。
【実施例２】
【００４６】
１つのサイズは、ＥＲＰに必要なすべてのクライアントに適合しない。ビジネスのタイプ、ユーザの数、データベースのサイズ、トランザクションの数、バッチ要件の複雑さ、ビジネスの季節性などはすべて、ＥＲＰシステムの様々な部分に適したサイズを見つけるのに影響する。ＥＲＰシステムは、「ピーク使用」期間を考慮して適切なサイズにする必要がある。例えば、顧客の「ピーク使用」期間には、月末決算、祝日ショッピングの季節、アニュアルベネフィットエンロールメント（annual benefits enrollment）、半月ごとの給与（給与明細書を確認する従業員）などが含まれる。従来、システムはこのピーク使用に加えて安全のためのいくつかの追加のヘッドルームを満たすようなサイズになっている。潜在的に高価なリソースが長期間アイドル状態になる可能性があるため、これは最適ではない。
【００４７】
図４は、ユーザインタフェースを介してコンピュータスクリーン上に見える３１日間２４時間にわたって発生するトランザクションの数を示す、クライアント用の特定のコンピューティングリソースの高い使用パターンを認識するために作成されたトランザクションヒートマップ４００である。日付は行４０２に示され、時間間隔は列４０４に示され、合計トランザクションは行４０６に示される２４時間間隔で発生する。トランザクションヒートマップ４００は、様々なタイプの強調表示を含むことができる。視覚的に異なる方法で異なる数字をマークすることができる。例えば、異なる数の範囲が異なって着色されてもよい。連続セクションには、同系色またはアセンディングカラーのパターンが使用されてもよい。例えば、２００〜３００の範囲ではより濃いオレンジ色を使用し、１００〜２００の範囲ではより明るいオレンジ色を使用することができる。マークされているように、異なる範囲のいくつかは、ドット、左ギザギザの線、右ギザギザの線、十字線などのパターンで埋められている。任意のパターンまたはスタイル（色など）が、数値／データの任意のシーケンスまたは集合に使用されてもよい。このトランザクションヒートマップ４００は、１００未満のトランザクション（４０８などの強調表示のないフィールド）で示されるように、１か月間の大半の時間がどのようにほとんどアイドル状態であるかを示している。特定の期間は、左斜めのハッチング（例えば、青色でもよい）４１０のフィールドで示されるような午前７時から午後４時までの約１０００〜２０００のトランザクション、または十字形のハッチング（例えば、緑色でもよい）４１２のフィールドで示されるような約５０００のトランザクション、または密集した左斜めのハッチング（例えば、橙色でもよい）４１６のフィールドで示されるような約７０００のトランザクション、または右斜めのハッチング（例えば、赤色でもよい）４１４のフィールドで示されるような８０００を超えるトランザクションのような頻度の増加を示す。一部のパブリッククラウドは、ＣＰＵ使用率、メモリ使用率、ネットワーク使用率などのインフラストラクチャメトリックに基づいて、自動拡張および縮小機能を提供することができる。一例として、Ａｐａｃｈｅ  Ｗｅｂ  Ｓｅｒｖｅｒ（ＡＷＳ）があり、これは通常は１日当たり数千のヒットを受信する。このＷｅｂサイトがウイルスに感染し、１分間に何千ものヒットを受信し始めると、ＡＷＳはＣＰＵとメモリにストレスがかかることを認識し、ＡＷＳはこのＷｅｂサーバの１つまたは複数の追加コピーを自動的にプロビジョニングして負荷を軽減することができる。ウイルス性が低下すると、ＡＷＳはこれらの１つまたは複数のコピーを自動的に削除することができる。しかし、いくつかのインフラストラクチャメトリックに基づくこの単純なスケーリングは、ＥＲＰシステムの動的プロビジョニングには十分ではない。クライアントデバイスでのＥＲＰシステムのニーズに応じたコンピューティングリソースのスケーリングは、多層企業アプリケーションでははるかに複雑である。Ｗｅｂベースの注文を格納するための追加のデータベースリソースを追加すると、複雑さが増し、企業アプリケー��ョンでは単純なスケーリングがほとんど不可能になる。単純なスケーリングは、ＣＰＵ使用率やメモリ消費量などの従来のインフラストラクチャメトリックを使用する。これらの本質的な複雑さのために、企業アプリケーションは、通常、これらの基本的なインフラストラクチャメトリックがシステムのストレスを示す前に拡張する必要がある。
【００４８】
本明細書で説明される動的プロビジョニングシステムは、エンタープライズリソースプランニングシステムにおけるトランザクションまたはソフトウェアオペレーションに関連するメタデータを受信し、分析する。動的プロビジョニングシステムは、トランザクション使用率、バッチリソース消費量、ログイン試行回数、および他の監視メトリックなどの情報を収集し、処理し、格納する。動的プロビジョニングシステムは、他の分析フレームワークと連携して、インフラストラクチャメトリックだけでなく、企業アプリケーション自体から来る実際のデータに基づいて自動的に拡張および縮小を行う。これらの拡張要求および縮小要求は、動的プロビジョニングシステムによって提供されるＡＰＩを介して行われる。コンピューティングリソースのこれらの拡張および縮小プロビジョニングは、本質的にリアクティブであり、すなわち、いくつかの重要なバッチジョブと関連して予想外に多数のトランザクションが発生した場合に、リアクティブである。動的プロビジョニングシステムの特定の構成要素がベースメトリックデータと共にこのトランザクションメタデータを受信すると、プロビジョニング閾値がトリガされ、動的プロビジョニングシステムがより多くのコンピューティングリソースを提供するように動作する。コンピューティングリソースのこれらの拡張および縮小プロビジョニングも、予測的に配備されることができる。動的プロビジョニングシステムは、特定の使用パターンを認識し、プロビジョニング要求を自動的にトリガする予測プロビジョニング閾値を作成する。これらのパターンの例としては、給与計算実行、ベネフィットオープンエンロールメントピリオド（benefit open enrollment period）、給与明細書セルフサービスなどがある。予測プロビジョニングモデルに基づいて、プロビジョニングはシステム内のストレスまたはスランプに先立って開始される。
【００４９】
図５は、例示的な実施形態による、３１日間２４時間にわたって発生するログインパターンを示す、クライアントのための特定のコンピューティングリソースの高い使用パターンを認識するために作成された例示的なログイントランザクションヒートマップ５００である。日付は行５０２に示され、時間間隔は列５０４に示され、合計トランザクションは行５０６に示される２４時間間隔で発生する。トランザクションヒートマップ５００は、様々なタイプの強調表示を含むことができる。視覚的に異なる方法で異なる数字をマークすることができる。例えば、異なる数の範囲が異なって着色されてもよい。連続セクションには、同系色またはアセンディングカラーのパターンが使用されてもよい。例えば、明るい青は０〜１００の範囲で使用され、明るい緑は１００〜２５０の範囲で使用されてもよい。マークされているように、異なる範囲のいくつかは、ドット、左ギザギザの線、右ギザギザの線、十字線などのパターンで埋められている。任意のパターンまたはスタイル（色など）が、数値／データの任意のシーケンスまたは集合に使用されてもよい。このトランザクションヒートマップ５００は、１００回未満のログイン（点線のパターンのフィールド、５０８などの薄い青色のフィールドであってもよい）で示されるように、１か月の時間の大半の時間がどのようにほとんどアイドル状態であるかを示している。特定の期間は、左にギザギザの線（例えば、青色でもよい）５１０のフィールドで示されるような午前７時から午後４時までの約２００回のログイン、または十字形のハッチング（例えば、黄色でもよい）５１２のフィールドで示されるような約５００回のログイン、または右斜めのハッチング（例えば、赤色でもよい）５１４のフィールドで示されるような７００回を超えるログインのような頻度の増加を示す。このパターンを分析すると、従業員は午前７時〜午前９時ごろに２週間ごとにログインし、給与明細を確認している。動的プロビジョニングシステムは、システムの異なるコンピューティングリソースのストレスに応じて、特定の時間前後のログインの増加を予想し、コンピューティングリソースを適切にプロビジョニングする。
【００５０】
例えば、図４および図５に示すようなヒートマップからの情報は、プロビジョニング要求を定量化するために同じ期間中にコンピューティングリソースの消費に関する情報とオーバーレイされる。図６は、例示的な一実施形態による、対応するＣＰＵ使用率のプロットに課せられた５日間の期間中のトランザクションの時間当たりの数のプロットのグラフ視覚化６００である。異なるセクションを、視覚的に異なる方法でマークすることができる。例えば、いくつかのオーバーレイドチャートは、異なる色を使用する別のオーバーレイに対して、１つの色であってもよい。この視覚化は、ピーク使用期間の識別をサポートし、例えば、実線の黒線で描かれている「赤色」領域６０２として示される重度の使用期間、または例えば、キー内にあるように半破線で描かれている「ティール色」領域６０４として示される軽度の使用期間の異なるタイプをサポートするのに必要なコンピューティングリソースのタイプをドリルダウンするのに役立つことができる。図７は、例示的な一実施形態による、対応するＣＰＵ使用率のプロットに課された１ヶ月間のトランザクションの時間当たりの数のプロットのグラフ視覚化７００である。この視覚化は、ピーク使用期間の識別をサポートし、例えば、実線の黒線で描かれている「赤色」領域６０２として示される重度の使用期間、または例えば、キー内にあるように半破線で描かれている「ティール色」領域６０４として示される軽度の使用期間の異なるタイプをサポートするのに必要なコンピューティングリソースのタイプをドリルダウンするのに役立つことができる。図６と図７のこれらの２つのグラフ表示は、１週間と１ヶ月間の実際のオンライン活動（例えば、トランザクション、クエリ、ドリル）の様々なタイプと監視データ（例えば、ＣＰＵ使用率）を組み合わせた視覚化である。実際の応答時間と関連したこれらの組合せは、プロビジョニング要求を決定するために使用される。
【００５１】
前述の方法の説明およびプロセスの流れ図は、単に説明的な例として提供されており、様々な実施形態のステップを提示された順序で実行しなければならないことを暗示または示唆するものではない。当業者には理解されるように、前述の実施形態におけるステップは、任意の順序で実行されてもよい。「ｔｈｅｎ」、「ｎｅｘｔ」などの用語は、ステップの順序を限定するものではなく、これらの用語は、単に方法の説明を通じて読み手を案内するために使用される。プロセスフロー図は、動作を順次処理として記述しているが、動作の多くは並行してまたは同時に実行されてもよい。さらに、動作の順序は再構成されてもよい。プロセスは、方法、関数、プロシージャ、サブルーチン、サブプログラムなどに対応していてもよい。プロセスが関数に対応する場合、その終了は、関数を呼び出し元関数または主関数に戻すことに対応することができる。
【００５２】
本明細書で開示された実施形態に関連して説明された様々な例示的な論理ブロック、モジュール、回路、およびアルゴリズムステップは、電子ハードウェア、コンピュータソフトウェア、またはその両方の組合せとして実装されてもよい。ハードウェアとソフトウェアとのこの互換性を明確に説明するために、様々な例示的な構成要素、ブロック、モジュール、回路、およびステップが、それらの機能性の点で一般的に上述されている。そのような機能性がハードウェアまたはソフトウェアとして実装されるかどうかは、特定のアプリケーションおよびシステム全体に課される設計制約に依存する。当業者は、特定のアプリケーションごとに様々な方法で説明した機能を実装することができるが、このような実装の決定は本発明の範囲から逸脱するものと解釈されるべきではない。
【００５３】
コンピュータソフトウェアに実装される実施形態は、ソフトウェア、ファームウェア、ミドルウェア、マイクロコード、ハードウェア記述言語、またはそれらの任意の組合せで実装されてもよい。コードセグメントまたは機械実行可能命令は、プロシージャ、関数、サブプログラム、プログラム、ルーチン、サブルーチン、モジュール、ソフトウェアパッケージ、クラス、または命令、データ構造、もしくはプログラムステートメントの任意の組合せを表すことができる。コードセグメントは、情報、データ、引数、パラメータ、またはメモリ内容を渡しおよび／または受け取ることによって、別のコードセグメントまたはハードウェア回路に結合されてもよい。情報、引数、パラメータ、データなどは、メモリ共有、メッセージパッシング、トークンパッシング、ネットワーク送信などの任意の適切な手段を介して渡され、転送され、または送信されてもよい。
【００５４】
本明細書に開示された態様に関連して説明された様々な例示的ロジック、論理ブロック、モジュール、および回路を実装するために使用されるハードウェアは、汎用プロセッサ、デジタル信号プロセッサ（ＤＳＰ）、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、または他のプログラマブルロジックデバイス、ディスクリートゲートもしくはトランジスタロジック、ディスクリートハードウェア構成要素、または本明細書に記載された機能を実行するように設計されたそれらの任意の組合せで実装または実行されてもよい。汎用プロセッサは、マイクロプロセッサであってもよいが、代替として、プロセッサは、任意の従来のプロセッサ、コントローラ、マイクロコントローラ、または状態機械であってもよい。プロセッサは、コンピューティングデバイスの組合せ、例えば、ＤＳＰとマイクロプロセッサとの組合せ、複数のマイクロプロセッサ、ＤＳＰコアと組み合わせた１つまたは複数のマイクロプロセッサ、またはその他のそのような構成として実装されてもよい。あるいは、いくつかのステップまたは方法は、所与の機能に特有の回路によって実行されてもよい。
【００５５】
例えば、冠詞”ａ”、”ａｎ”、または”ｔｈｅ”を用いて単数形で請求項要素を参照することは、その要素を単数形に限定するものとして解釈されるべきではない。開示された実施形態の前述の説明は、当業者が本発明を実施または使用することを可能にするために提供される。これらの実施形態に対する様々な変更は、当業者には容易に明らかであり、本明細書で定義される一般的な原理は、本発明の趣旨または範囲から逸脱することなく他の実施形態に適用されてもよい。したがって、本発明は、本明細書に示される実施形態に限定されることを意図するものではなく、本明細書に開示された特許請求の範囲および趣旨および新規な特徴と一致する最も広い範囲が与えられるべきである。
【図１】
2019507932.tif 000003
【図２】
2019507932.tif 000004
【図３】
2019507932.tif 000005
【図４】
2019507932.tif 000006
【図５】
2019507932.tif 000007
【図６】
2019507932.tif 000008
【図７】
2019507932.tif 000009
【国際調査報告】
2019507932.tif 000010