コンピューティングシステムのリソースをスケーリングする方法であって、システム性能の第1のメトリックの閾値をセットするステップと、前記第1のメトリックの前記閾値に基づいて少なくとも1つのリソースの少なくとも1つの理想的リソース負荷を判定するステップと、前記コンピューティングシステムリソースの中でシステム作業負荷を分配するステップと、前記システム作業負荷、前記理想的リソース負荷、およびリソースの現在の個数に基づいて、リソースの個数を調整するステップとを含む方法。コンピューティングシステムリソースの前記個数を調整する前記ステップは、前記理想的リソース負荷によって前記システム作業負荷を割ることによってリソースの理想的個数を判定するステップと、リソースの前記理想的個数からリソースの前記現在の個数を引くことによってリソースの変化を判定するステップと、リソースの前記変化が負である場合に、少なくとも1つのリソースを解放するステップと、リソースの前記変化が正である場合に、少なくとも1つの追加リソースを獲得するステップとを含む、請求項1に記載の方法。少なくとも1つのリソースを解放する前記ステップは、解放のために少なくとも1つのリソースをマークするステップと、解放のためにマークされた前記リソースに作業を分配するのをやめるステップと、リソースの賃借が満了する時に前記リソースを解放するステップとを含む、請求項2に記載の方法。少なくとも1つの追加リソースを獲得する前記ステップは、解放のためにマークされた少なくとも1つのリソースがあるかどうかを判定するステップと、解放のためにマークされた少なくとも1つのリソースがある場合に、前記少なくとも1つのリソースのマークを解除し、前記少なくとも1つのリソースに作業を分配するステップと、解放のためにマークされた少なくとも1つのリソースがない場合に、追加リソースを獲得するステップとを含む、請求項2に記載の方法。各リソースについて、前記リソースの第1の性能メトリックを判定することと、前記リソースの実際の作業負荷を判定することと、前記性能メトリックを前記実際の作業負荷およびシステム作業負荷に基づく許容可能な性能標準と比較することとによって、少なくとも1つのシステムリソースが悪い領域で動作しつつあることを判定するステップと、前記第1の性能メトリックが前記許容可能な性能標準を超える場合に、前記リソースが悪い領域で動作しつつあると判定するステップと、追加のシステムリソースを獲得するのをやめるステップと、前記システム作業負荷からサービス要求を除去するステップとをさらに含む、請求項1に記載の方法。コンピューティングシステムリソースの前記個数を調整する前記ステップは、前記システム作業負荷および積分成分の和を各リソースの前記理想的リソース負荷によって割ることによってリソースの理想的個数を判定するステップと、リソースの前記理想的個数からリソースの前記現在の個数を引くことによってリソースの変化を判定するステップであって、前記積分成分は、第2の以前の時間間隔にわたるシステム作業負荷の変化の合計である、ステップとを含む、請求項1に記載の方法。コンピューティングタスクを実行する内部リソースと、時間間隔の間の第1の性能メトリックおよびシステム負荷を含むシステム性能メトリックを収集する性能モニタと、クラウドリソースの量を含むクラウドリソース情報を収集する通信モジュールと、前記内部リソースおよび前記クラウドリソースにコンピューティングタスクを向けるジョブディスパッチングモジュールとを含むロードバランサと、前記第1の性能メトリックに基づいて前記クラウドリソースをスケーリングし、クラウドリソース情報を前記ロードバランサに提供するコントローラとを含む、クラウドリソースをスケーリングするコンピューティングシステム。前記コントローラは、予測されたシステム負荷を理想的リソース負荷によって割ることによってリソースの理想的個数を判定するスケーリングモジュールと、クラウドリソースを獲得することまたは解放することによって、リソースの前記理想的個数と等しくなるようにシステムリソースの総数を調整するインスタンスマネージャとをさらに含む、請求項7に記載のシステム。内部リソースおよびクラウドリソースを使用するコンピューティングシステム内で性能ボトルネックを識別する方法であって、リソースごとに、リソース特性およびリソース負荷に基づいてリソース性能メトリックの許容可能な値を判定するステップと、前記リソース性能メトリックを測定するステップと、前記リソース性能メトリックが前記許容可能な値を超える場合に、前記リソースが非効率的に動作しつつあると判定するステップと、少なくとも前記リソースの所定の個数が非効率的に動作しつつある場合に、前記システムが性能ボトルネックに達したと判定するステップとを含む方法。クラウドリソースを使用するコンピューティングシステム内でスケーリング閉塞点を識別する方法であって、履歴システムメトリック値を測定するステップと、前記履歴システムメトリック値およびリソースの数に基づいて追加リソースを追加するためのシステムメトリック値利得を推定するステップと、前記追加クラウドリソースを追加するステップと、実際のシステムメトリック値利得を測定するステップと、前記実際のシステムメトリック値利得が前記推定されたシステムメトリック値利得のセットされたパーセンテージ未満である場合に、前記コンピューティングシステムが性能ボトルネックに達したと判定するステップとを含む方法。前述に鑑みて、賃借されるクラウドリソースのスケールを制御するシステムおよび方法を提供することが望ましい。具体的には、内部企業リソースに関してクラウドリソースをスケーリングするシステムを提供することが望ましい。また、システムが、過剰なコストを防ぐためにクラウドリソースの使用を最適化できたならば、それは望ましいことであろう。クラウドリソースのスケールを制御するシステムおよび方法の現在の必要に鑑みて、さまざまな例示的実施形態の短い要約を提示する。次の要約では、いくつかの単純化および省略を行う場合があり、さまざまな例示的実施形態のいくつかの態様を強調し、紹介することが意図されているが、本発明の範囲を限定することは意図されていない。当業者が発明的概念を作り、利用することを可能にするのに適当な好ましい例示的実施形態の詳細な説明を、より後のセクションで続ける。さまざまな例示的実施形態は、コンピューティングシステムのリソースをスケーリングする方法に関する。この方法は、システム性能の第1のメトリックの閾値をセットするステップと、コンピューティングシステムリソースの中でシステム作業負荷を分配するステップと、以前の時間間隔中のシステムの性能に基づいてシステム性能の第1のメトリックを測定するステップと、測定された第1のメトリックを第1のメトリックの閾値と比較するステップと、第1のメトリックの閾値に基づいて各リソースの理想的リソース負荷を判定するステップと、システム作業負荷、各リソースの理想的リソース負荷、およびリソースの現在の個数に基づいて、リソースの個数を調整するステップとを含む。コンピューティングシステムリソースの個数を調整するステップは、各リソースの理想的リソース負荷によってシステム作業負荷を割ることによってリソースの理想的個数を判定するステップと、リソースの理想的個数からリソースの現在の個数を引くことによってリソースの変化を判定するステップと、リソースの変化が負である場合に、少なくとも1つのリソースを解放するステップと、リソースの変化が正である場合に、少なくとも1つの追加リソースを獲得するステップとを含むことができる。この方法は、少なくとも1つのシステムリソースが悪い領域で動作しつつあることを判定するステップと、追加のシステムリソースを獲得するのをやめるステップと、サービス要求をシステム作業負荷から除去するステップとをも含むことができる。さまざまな例示的実施形態は、コンピューティングシステムのリソースをスケーリングする命令として機械可読記憶媒体上で符号化された上記の方法に関する。さまざまな例示的実施形態は、クラウドリソースをスケーリングするコンピューティングシステムに関する。このコンピューティングシステムは、コンピューティングタスクを実行する内部リソースと、ロードバランサと、クラウドリソースをスケーリングするコントローラとを含むことができる。ロードバランサは、時間間隔の間の第1の性能メトリックおよびシステム負荷を含むシステム性能メトリックを収集する性能モニタと、クラウドリソースの量を含むクラウドリソース情報を収集する通信モジュールと、内部リソースおよびクラウドリソースにコンピューティングタスクを向けるジョブディスパッチングモジュールとを含むことができる。コントローラは、第1の性能メトリックに基づいてクラウドリソースをスケーリングし、クラウドリソース情報をロードバランサに提供することができる。コントローラは、予測されたシステム負荷を理想的リソース負荷によって割ることによってリソースの理想的個数を判定するスケーリングモジュールと、クラウドリソースを獲得することまたは解放することによって、リソースの理想的個数と等しくなるようにシステムリソースの総数を調整するインスタンスマネージャと含むことができる。さらに、性能モニタは、各リソースの個々のリソース負荷および性能メトリックを測定し、リソースの個々の性能メトリックを個々のリソース負荷に基づく許容可能な性能標準と比較することによって各リソースが悪い領域で動作しつつあるかどうかを判定することができる。さまざまな例示的実施形態は、内部リソースおよびクラウドリソースを使用するコンピューティングシステム内で性能ボトルネックを識別する方法に関する。この方法は、各リソースを検査するステップと、リソース特性およびリソース負荷に基づいてリソース性能メトリックの許容可能な値を判定するステップと、リソース性能メトリックを測定するステップと、リソース性能メトリックが許容可能な値を超える場合に、リソースが非効率的に動作しつつあると判定するステップと、少なくともリソースの所定の個数が非効率的に動作しつつある場合に、システムが性能ボトルネックに達したと判定するステップとを含むことができる。さまざまな例示的実施形態は、クラウドリソースを使用するコンピューティングシステム内でスケーリングの閉塞点を識別する方法に関する。この方法は、履歴システムメトリック値を測定するステップと、履歴システムメトリック値およびリソースの数に基づいて追加リソースを追加するためのシステムメトリック値利得を推定するステップと、追加クラウドリソースを追加するステップと、実際のシステムメトリック値利得を測定するステップと、実際のシステムメトリック値利得が推定されたシステムメトリック値利得のセットされたパーセンテージ未満である場合に、コンピューティングシステムが性能ボトルネックに達したと判定するステップとを含むことができる。このようにして、さまざまな例示的実施形態により、クラウドリソースの最適化されたスケーリングのためのシステムおよび方法が使用可能となることは明白であるはずである。具体的には、性能メトリックを測定し、メトリックを閾値と比較することによって、この方法およびシステムは、クラウドリソースをスケーリングするのにシステムフィードバックを使用することができる。さらに、この方法およびシステムは、リソースが効率の期待されるレベル未満で動作しつつある時を判定することによって、動的ボトルネックを検出することもできる。さまざまな例示的実施形態をよりよく理解するために、添付図面を参照する。これから、同様の符号が同様のコンポーネントまたはステップを指す図面を参照して、さまざまな例示的実施形態の広義の態様を開示する。図1に、クラウドリソース140をスケーリングする例示的なコンピューティングシステム100の概略図を示す。システム100は、ロードバランサ110およびコントローラ120を含むことができる。システム100を、内部リソース130およびクラウドリソース140に接続することができる。システム100は、サービス要求を受信し、処理の要求を内部リソース130またはクラウドリソース140のいずれかに分配することができる。サービス要求は、システム所有者によって提供されるサービスに応じて変化する可能性がある。たとえば、システム所有者は、テキスト、イメージ、オーディオ、ビデオ、およびゲーミングなどのコンテンツ、販売、計算、およびストレージなどのサービス、またはインターネット上で提供される任意の他のコンテンツもしくはサービスを提供することができる。サービス要求は、企業アプリケーションを含むこともでき、ここで、要求は、内部企業ネットワークから届く可能性がある。サービス要求を、システム作業負荷と考えることができる。システム作業負荷を、サービス要求の到着レートによって測定することができる。システム100は、サービス要求負荷を効率的に管理するためにクラウドリソース140をスケーリングすることもできる。ロードバランサ110は、インターネット上のどこかにいるユーザからサービス要求を受信することができる。ロードバランサ110は、サービス要求を内部リソース130またはクラウドリソース140のいずれかに分配することができる。ロードバランサ110は、完了したサービス要求を受信して、要求しているユーザにその要求を返すこともできる。サービス要求の分配は、さまざまなリソースの性能に依存するものとすることができる。ロードバランサ110は、総合システム性能ならびに個々の内部リソース130およびクラウドリソース140の性能を監視することができる。ロードバランサ110は、クラウドリソース140のスケーリングが必要であるかどうかの判定を助けるために、コントローラ120に性能データを供給することができる。ロードバランサ110は、クラウドリソース140に関する構成情報および性能情報をコントローラ120から受け取ることができる。ロードバランサ110は、性能モニタ112、ジョブディスパッチャ114、および通信モジュール116を含むことができる。性能モニタ112は、サービス要求を処理する際に全体としてのシステムの性能を監視するように構成された、ハードウェアおよび/または機械可読記憶媒体上の実行可能命令を含むことができる。性能モニタ112は、システムが適当に実行しつつあるかどうかを評価するのにメトリックを使用することができる。さまざまな例示的実施形態では、性能モニタ112は、システム性能を測定するメトリックとして、ロードバランサ110でのサービス要求の到着からロードバランサ110での応答のリターンまでの、システム応答時間を計算することができる。たとえば、性能モニタは、システム性能のメトリックを提供するために、たとえば、第95パーセンタイル内に含まれるサービス要求の応答時間など、サービス要求応答時間のあるパーセンタイルを測定することができる。閾値をまたぐ時に性能が不適切であることを示すために、性能モニタ112をメトリックに関する閾値を用いて構成することができる。性能モニタ112は、システム性能を測定するのに適当である可能性がある他のメトリックを測定することもできる。性能モニタ112は、たとえば、内部リソース130、通信モジュール116、およびコントローラ120などの他のコンポーネントから測定値を収集することもできる。ジョブディスパッチャ114は、内部リソース130およびクラウドリソース140の間で着信サービス要求を分配するように構成された、ハードウェアおよび/または機械可読記憶媒体上の実行可能命令を含むことができる。以下でより詳細に説明するように、内部リソース130は、プライベートリソースを含む複数のタイプのリソースを含むことができる。同様に、クラウドリソース140は、異なるタイプのリソースを含むことができる。ジョブディスパッチャ114は、サービス要求を、その要求を処理するのに適当なタイプのリソースに分配することができる。ジョブディスパッチャ114は、同一タイプのリソースの間で要求負荷を平衡化することもできる。ジョブディスパッチャ114は、内部リソース130とクラウドリソース140との間での要求の割当てを判定するのに、ポリシーを使用することができる。たとえば、コストを節約しようとするポリシーは、性能メトリックが閾値以内に留まる限り、クラウドリソースより内部リソースを優先することができる。代替の例のポリシーは、要求を最もよく処理することができるリソースに要求を割り当てることによって、メトリックを最適化しようと努めることができる。たとえば、加重ラウンドロビン、最少接続、または最速応答などの負荷平衡化に関して当技術分野で既知の方法を、ポリシーによって使用して、要求負荷を平衡化することができる。通信モジュール116は、クラウドリソースをスケーリングするためにコントローラ120と相互作用するように構成された、ハードウェアおよび/または機械可読記憶媒体上の実行可能命令を含むことができる。通信モジュール116は、性能モニタ112からコントローラ120へ性能メトリックを供給することができる。通信モジュール116を、メトリックが閾値を超える場合にそれらのメトリックを報告するコールバック関数を用いて構成することができる。コントローラ120は、性能モニタ112での収集のためにクラウドリソース140の性能メトリックを通信モジュール116に送ることができる。通信モジュール116は、たとえば、クラウドリソースとして使用される計算機または仮想計算機の個数および特性などのクラウドリソース情報をコントローラ120から受け取ることもできる。通信モジュール116は、有効な性能測定および要求分配を可能にするために、このクラウドリソース情報を性能モニタ112およびジョブディスパッチャ114に渡すことができる。さまざまな代替実施形態では、コントローラ120を、ロードバランサ110と統合することができ、その場合には、通信モジュール116を不要とすることができる。コントローラ120は、クラウドリソース140を制御することができる。コントローラ120を、二進フィードバックコントローラ、比例コントローラPコントローラ、比例積分コントローラPIコントローラ、または比例積分偏差コントローラPIDコントローラとすることができる。コントローラ120は、通信モジュール116およびクラウドリソース140から受け取った情報に基づいてクラウドリソース140の適当なスケールを判定することができる。コントローラ120は、クラウドリソース140に適当な要求を送信することによって、クラウドリソースを解放しまたは獲得することができる。コントローラ120は、スケーリングモジュール122およびインスタンスマネージャ124を含むことができる。スケーリングモジュール122は、性能モニタ112によって供給される性能メトリックに基づいてクラウドリソース140の適当な個数を判定するように構成されたハードウェアおよび/または機械可読記憶媒体上の実行可能命令を含むことができる。スケーリングモジュール122は、クラウドリソースの適当な個数を判定し、その個数をインスタンスマネージャ124に渡すことができる。スケーリングモジュール122は、利用すべきクラウドリソースの個数を判定するのに、性能モニタ112によって供給される性能メトリックおよび他のデータを使用することができる。以下で図4および7に関して説明するように、スケーリングモジュール122は、システムが閉塞しつつあるかどうかを判定することもできる。システム100は、システムがクラウドリソースのスケール以外の動的ボトルネックに直面する場合に、閉塞する可能性がある。たとえば、多数の要求が、あまりに多くの帯域幅を使用し、ネットワーク制約が、クラウドリソースに対してサービス要求をスケーリングする能力を制限する場合がある。スケーリングモジュール122は、性能モニタ112およびクラウドリソース140からの情報を使用して、少なくとも1つのリソースが悪い領域で動作しつつあることを性能データが示す場合に、動的ボトルネックがあると判定することができる。スケーリングモジュール122によって使用される例示的方法を、以下で図3に関してさらに詳細に説明する。インスタンスマネージャ124は、スケーリングモジュール122によって示されるスケールを実施するためにクラウドリソース140を制御するように構成されたハードウェアおよび/または機械可読記憶媒体上の実行可能命令を含むことができる。さまざまな例示的実施形態では、クラウドリソース140は、インスタンスマネージャ124が追加リソースを獲得しまたは不必要なリソースを解放することを可能にするアプリケーションプログラミングインターフェースAPIと共に提供される。インスタンスマネージャ124は、現在賃借されている各リソースを追跡し、賃借が終わる時を知ることができる。インスタンスマネージャ124は、スケーリングモジュール122によって示されるものより多くのリソースがある場合に、解放のためにリソースをマークすることができる。インスタンスマネージャ124は、スケーリングモジュール122によって示されたクラウドリソースの個数を実施するために、新しい賃借を獲得すべきかどうか、およびいつ獲得すべきかを判断することができる。インスタンスマネージャ124は、新しいリソースを獲得するのではなく、削除についてマークされたリソースを再アクティブ化することができる。インスタンスマネージャ124は、APIを使用してクラウドリソース140からクラウドリソース情報を入手し、この情報をスケーリングモジュール122および通信モジュール116に渡すこともできる。さまざまな代替実施形態では、クラウドリソース140は、オートスケーラauto-scalerおよび負荷マネージャを含むことができる。これらの実施形態では、インスタンスマネージャ124は、クラウドリソースの所望の個数を達成するために、クラウドリソース140をオートスケーラとして構成するか、オートスケーラを有効/無効にすることができる。さまざまな代替実施形態では、システム100は、クラウドリソースの異なるプロバイダと相互作用することができる。これらの実施形態では、異なるクラウドリソース140を制御する複数のインスタンスマネージャ124があるものとすることができる。内部リソース130は、システム所有者によって所有され、運営されるコンピュータリソースを含むことができる。内部リソース130は、サービス要求の満足などのさまざまなコンピューティングタスクを実行することができる。内部リソース130を、複数の層に分割することができる。たとえば、3層システムは、ユーザと通信するフロントエンドサーバ132、ビジネスロジックを実施するアプリケーションサーバ134、およびデータベースサーバ136を含むことができる。さまざまな例示的実施形態では、1つまたは複数の層を非公開とすることができる。たとえば、データベースサーバ136は、法によって所有者が共有してはならない機密非公開情報を含むので、非公開とすることができる。クラウドリソースなどのデータベースサーバをインスタンス化することが、高価で時間がかかる場合もある。ロードバランサ110は、非公開リソースに関する要求をクラウド要求として複製することを回避することができる。ロードバランサ110は、ある種のサービス要求が非公開リソースへのアクセスを要求する場合に、必ずその要求を内部リソース130に割り当てることができる。クラウドリソース140を、クラウドリソースプロバイダによって所有され、システム所有者に賃貸されるコンピュータリソースとすることができる。さまざまな例示的実施形態では、クラウドリソースは、仮想計算機として編成される。システム所有者は、内部リソースをエミュレートするために仮想計算機を賃借することができる。たとえば、クラウドサーバ142が、フロントエンドサーバ132をエミュレートすることができ、クラウドサーバ144が、アプリケーションサーバ134をエミュレートすることができる。クラウドリソースプロバイダは、実際には仮想計算機を異なった形で実装することができるが、エミュレートされた内部リソースと同一の性能を保証することができる。システム100は、クラウドリソース140を、対応する内部リソース130と同一として扱うことができる。システム100は、クラウドリソース140が、通信遅延に起因して内部リソース130より長い応答時間を有する場合があることを認識する場合もある。クラウドリソースは、必要に応じて賃借され得るが、仮想計算機がインスタンス化される時に、かなりのスタートアップ時間を必要とする場合がある。クラウドリソースプロバイダは、1時間あたりの料金、実際の使用量、または任意の他の請求方法に基づいて、クラウドリソースを賃貸することができる。システム100のコンポーネントを説明したので、例示的実施形態の動作の短い説明を説明する。このプロセスは、内部リソース130がすべてのサービス要求を処理できる、比較的非ビジーの状態で始めることができる。この状態では、ロードバランサ110は、すべての要求を内部リソース130の間で分配することができる。サービス要求のレートが増える時に、システム性能が劣化する可能性があり、性能メトリックが閾値を超えたことを、性能モニタ112が検出する場合がある。通信モジュール116は、性能メトリックが閾値を超えたことをコントローラ120に知らせ、他のシステム情報を提供することができる。スケーリングモジュール122は、性能メトリック閾値を満足するために何個のクラウドリソースが必要であるのかを判定することができる。インスタンスマネージャ124は、たとえばクラウドサーバ142などの追加リソースを獲得するために、クラウドリソース140と通信することができる。各クラウドリソース140が動作状態になった後に、インスタンスマネージャ124は、リソースが使用可能であることを通信モジュールに知らせることができる。その後、ジョブディスパッチャ114は、サービス要求を内部リソース130とクラウドリソース140との両方に割り当てることができる。スケーリングモジュール122は、何個のクラウドリソースが必要であるのかを判定し続けることができ、インスタンスマネージャ124は、必要に応じてリソースを追加しまたは解放することができる。スケーリングモジュール122は、追加リソースを追加する前に、システム100が閉塞しつつあるかどうかを判定することもできる。このようにして、システム100は、所望の性能メトリックを達成するためにクラウドリソースをスケーリングすることができる。図2に、フィードバックに基づいてクラウドリソース140をスケーリングする例示的方法200の流れ図を示す。方法200を、システム100のコンポーネントによって実行することができる。システム100は、クラウドリソース140の個数を継続的に調整するために、方法200を繰り返して実行することができる。システム100は、固定された時間間隔中に方法200を実行することができる。さまざまな例示的実施形態では、時間間隔を10秒とすることができるが、任意の時間間隔を選択することができる。方法200は、ステップ205で開始し、ステップ210に進むことができ、ステップ210では、システム100が、システム100を構成すべきかどうかを判定することができる。方法200が、初めて実行されつつある場合には、システム100は、構成を実行すると判断することができ、この方法は、ステップ215に進むことができる。システム100が既に構成されている場合には、この方法は、ステップ220に進むことができる。ステップ215では、システム100は、さまざまな閾値をセットすることができる。たとえば、性能モニタ112は、システム応答時間の閾値をセットすることができる。このメトリックは、サービス要求の処理に関する性能目標を表すことができる。性能モニタ112を、システム性能を測定する時間間隔を用いて構成することもできる。システム100は、他の構成タスクを実行することもできる。たとえば、インスタンスマネージャ124は、各内部リソース130をエミュレートするのに使用すべきクラウドリソース140の中の仮想計算機を判定することができる。ジョブディスパッチャ114を、サービス要求を処理するのに使用できる内部リソース130の個数を用いて初期化することができる。その後、方法200は、ステップ220に進むことができる。ステップ220では、ジョブディスパッチャ114が、内部リソース130およびクラウドリソース140の中で着信サービス要求を分配することができる。ジョブディスパッチャ114は、サービス要求を分配するポリシーを実施することができる。たとえば、ジョブディスパッチャ114は、応答時間が性能閾値を超えない限り、内部リソース130を優先することができる。このポリシーは、クラウドリソース140の使用およびコストを最小にすることができる。その後、内部リソース130およびクラウドリソース140は、サービス要求を処理することができる。完了したサービス要求応答を、ロードバランサ110を介して返すことができる。その後、この方法は、ステップ225に進むことができる。ステップ225では、性能モニタ112が、たとえばシステム応答時間などのシステム性能メトリックを測定することができる。さまざまな実施形態では、個々のサービス要求応答時間の第95パーセンタイルの測定値を、システム性能の有効な測定値として使用することができる。性能モニタ112は、システムサービス要求負荷を測定することもできる。他のパーセンタイルまたは性能メトリックを使用することもできる。その後、この方法は、ステップ230に進むことができる。ステップ230では、性能メトリックを、ステップ215で構成された閾値と比較することができる。測定されたシステムメトリックが閾値を超える場合には、方法200は、ステップ235に進むことができる。測定されたシステムメトリックが閾値を超えない場合には、システム100は、リソースの調整が不要であると判定することができ、この方法は、ステップ250に進むことができ、ステップ250では、この方法が終了する。ステップ235では、スケーリングモジュール122が、性能閾値を満足するための各リソースの理想的なリソース負荷を判定することができる。図5および図6に関してさらに詳細に説明するように、各リソースの理想的な要求負荷は、リソース特性およびシステム負荷に依存して変化する可能性がある。同一タイプの各リソースの理想的な要求負荷を、同一とすることができる。たとえば、各フロントエンドサーバ132は、同一の理想的な要求負荷を有することができる。同様に、フロントエンドサーバ132をエミュレートする各クラウドサーバ142は、同一の理想的な要求負荷を有することができる。その後、方法200は、ステップ240に進むことができる。ステップ240では、スケーリングモジュール122が、クラウドリソースの正しい個数を判定することができる。コントローラ120が二進フィードバックコントローラであるさまざまな例示的実施形態では、スケーリングモジュール122は、測定された性能メトリックがステップ230で判定された閾値を超える場合に、単純に、追加のクラウドリソースのセットされた個数を追加することができる。その代わりに、スケーリングモジュール122が、システム性能をより早く向上させるために、クラウドリソース140の個数を増やすことができる。コントローラ120がPコントローラであるさまざまな例示的実施形態では、スケーリングモジュール122は、測定されたシステム負荷をステップ235で判定された理想的なリソース負荷によって割ることによって、クラウドリソース140の正しい個数を判定することができる。これらの実施形態では、クラウドリソースの変化を、性能を超えるシステム負荷の分数に比例するものとすることができる。コントローラ120がPIコントローラであるさまざまな例示的実施形態では、スケーリングモジュール122は、理想的なリソース負荷によって割る前に、測定されたシステム負荷に整数成分を加算することによって、クラウドリソース140の正しい個数を判定することができる。この整数成分は、セットされた時間間隔にわたるシステム負荷の変化の合計とすることができる。スケーリングモジュール122は、コントローラ120がPIDコントローラであるさまざまな実施形態で、微分成分を使用することもできる。スケーリングモジュール122の動作を、図3に関して以下でさらに詳細に説明する。その後、方法200は、ステップ245に進むことができる。ステップ245では、インスタンスマネージャ124が、ステップ240で判定されたクラウドリソース140の個数に従ってクラウドリソースを調整することができる。インスタンスマネージャ124は、追加のクラウドリソース140を追加するためにクラウドリソースプロバイダと通信することができる。さまざまな実施形態では、インスタンスマネージャ124は、さらに、追加のクラウドリソース140を追加する前に、システム100が閉塞しつつあるかどうかを判定するのに性能モニタ112を使用することができる。インスタンスマネージャ124は、解放のためにクラウドリソース140をマークすることもできる。インスタンスマネージャ124の動作を、図3に関して以下でさらに詳細に説明する。インスタンスマネージャ124がリソースの個数を調整した後に、方法200はステップ250に進むことができ、ここで、この方法は終了する。図3に、クラウドリソースの理想的個数の変化を判定する例示的方法300の流れ図を示す。方法300は、方法200のステップ240中のシステム100の動作を説明することができる。方法300は、ステップ305で開始し、ステップ310に進むことができ、ステップ310では、性能モニタ112が、現在のシステム負荷を判定する。現在のシステム負荷を、前の時間間隔中のサービス要求の到着レートとして測定することができる。現在のシステム負荷は、内部リソース130とクラウドリソース140との両方によって処理されるサービス要求を含むことができる。代替案では、内部リソース130が固定されているので、内部リソース130に関する負荷を引くことができる。性能モニタ112は、通信モジュール116を介してスケーリングモジュール122に現在のシステム負荷を送ることができる。この方法は、その後、ステップ315に進むことができる。ステップ315では、スケーリングモジュール122が、積分成分に従って現在の負荷を調整する。積分成分を、前の時間間隔にわたるシステム負荷の変化の合計とすることができる。積分成分は、システム負荷の傾向を示すのを助けることができる。積分成分は、重み付け係数を含むこともできる。コントローラ120がPコントローラであるさまざまな例示的実施形態では、ステップ315をオプションとすることができる。さまざまな代替実施形態では、ステップ315は、微分成分に従って現在の負荷を調整することを含むことができる。その後、この方法はステップ320に進むことができる。ステップ320では、スケーリングモジュール122が、各サーバの理想的負荷を判定することができる。以下で図5および6に関して説明するように、リソースあたりの理想的負荷を、システム性能メトリック閾値以内に留まりながらリソースが処理できる最大負荷とすることができる。リソースあたりの理想的負荷を、内部リソース130とクラウドリソース140との両方を含む、同一タイプの各リソースについて同一とすることができる。その後、この方法はステップ325に進むことができる。ステップ325では、スケーリングモジュール122が、リソースあたりの理想的負荷によって現在の負荷を割る。その結果は、期待される着信要求負荷を処理するのに必要なリソースの個数を示すことができる。その後、この方法はステップ330に進むことができ、ステップ330では、スケーリングモジュール122が、クラウドリソースの個数における必要な変化を判定することができる。スケーリングモジュール122は、リソースの必要な個数から、内部リソース130の個数およびクラウドリソース140の現在の個数を引くことができる。代替案では、内部リソースに対する負荷が既に引かれている場合に、スケーリングモジュール122は、クラウドリソースの現在の個数だけを引くことができる。スケーリングモジュール122は、クラウドリソースの変化をインスタンスマネージャ124に渡すことができる。方法300は、その後、ステップ335に進むことができ、ここで、この方法は終了する。図4に、クラウドリソースの個数を調整する例示的方法400の流れ図を示す。方法400は、方法200のステップ245中のシステム100の動作を説明することができる。方法400は、ステップ405で開始し、ステップ410に進むことができ、ステップ410では、インスタンスマネージャ124が、クラウドリソースの変化が正であるかどうかを判定することができる。クラウドリソースの変化が正である場合には、方法400は、ステップ415に進むことができる。クラウドリソースの変化が負である場合には、方法400は、ステップ440に進むことができる。ステップ415では、インスタンスマネージャ124が、追加のクラウドリソースを追加する前に、システムが閉塞しつつあるかどうかを判定するのに性能モニタ112を使用することができる。以下で図7に関してさらに詳細に説明するように、性能モニタ112は、個々のリソースのシステム性能メトリックが、システム入力を与えられて期待値を超える場合に、そのリソースが悪い領域で動作しつつあると判定することができる。この性能メトリックの格差は、リソースが非効率的に動作しつつあることを示す可能性がある。性能モニタ112が、少なくとも1つのリソースが悪い領域で動作しつつあると判定する場合には、性能モニタ112は、システムが閉塞しつつあると判定することができる。代替案では、性能モニタ112は、システムが閉塞しつつあると判定する前に、リソースのセットされたパーセンテージが悪い領域で動作しつつあることを要求することができる。さまざまな代替実施形態では、性能モニタ112は、追加リソースのスループット利得を測定することによって、システムが閉塞しつつあるかどうかを判定することができる。性能モニタ112は、測定されたスループット利得を、リソースあたりの履歴最大スループットに基づいて推定された利得と比較することができる。測定されたスループット利得が、推定されたスループット利得のセットされたパーセンテージ未満である場合には、性能モニタ112は、システムが閉塞しつつあると判定することができる。これらの代替実施形態では、性能モニタ112は、測定されたスループットがリソースあたりの履歴最大スループットに基づいて推定されたスループットに達する時に、システムがもはや閉塞してはいないと判定することができる。性能モニタ112が、システムが閉塞しつつあるのではないと判定する場合には、方法400は、ステップ420に進むことができる。性能モニタ112が、システムが閉塞しつつあると判定する場合には、方法400は、ステップ430に進むことができる。ステップ420では、インスタンスマネージャ124が、追加のクラウドリソース140をアクティブ化することができる。既存のクラウドリソース140のいずれかが解放のためにマークされている場合には、インスタンスマネージャ124は、そのマークを解除することによって、そのクラウドリソース140をアクティブ化することができる。解放のためにマークされたクラウドリソース140がない場合には、インスタンスマネージャ124は、追加のクラウドリソース140をインスタンス化するために、クラウドリソースプロバイダと通信することができる。インスタンスマネージャ124は、クラウドリソースの変化から1を引くこともできる。その後、方法400は、ステップ425に進むことができる。ステップ425では、インスタンスマネージャ124は、追加のクラウドリソースが追加されたことをロードバランサ110に示すことができる。性能モニタ112は、新しいクラウドリソースの監視を開始することができる。ジョブディスパッチャ114は、新しいクラウドリソースにサービス要求を分配することができる。その後、方法400は、ステップ410に戻って、追加のクラウドリソースを追加するかどうかを判定することができる。ステップ430では、システムが閉塞するのを防ぐために、ロードバランサ110が、過剰なサービス要求を除去することができる。システム100は、追加のクラウドリソース140がシステム性能メトリックを改善しない可能性があると判定したので、ロードバランサ110は、既存リソースに対するサービス要求負荷を減らすことができる。性能モニタ112は、どのタイプの動的ボトルネックがシステム100を閉塞させつつあるのかを判定することもできる。たとえば、データベースサーバ136などの非公開リソースの性能メトリックが閾値を超えていると性能モニタ112が判定する場合には、性能モニタ112は、非公開リソースが動的ボトルネックを引き起こしつつあると判定することができる。もう1つの例として、クラウドリソース140の応答時間が内部リソース130の応答時間よりはるかに長いことを性能モニタ112が検出する場合には、性能モニタ112は、ネットワーク輻輳が動的ボトルネックを引き起こしつつあると判定することができる。性能モニタ112は、システム管理者に動的ボトルネックを報告することができる。その後、方法400は、ステップ450に進むことができ、ここで、この方法は終了する。ステップ440では、インスタンスマネージャ124が、クラウドリソース140の変化が負であるかどうかを判定することができる。クラウドリソース140の変化が負である場合には、方法400は、ステップ445に進むことができる。クラウドリソース140の変化が負ではない場合には、インスタンスマネージャ124は、何もしないものとすることができる。方法400は、ステップ450に進むことができ、ここで、この方法は終了する。ステップ445では、インスタンスマネージャ124が、解放のためにクラウドリソース140をマークすることができる。インスタンスマネージャ124は、賃借が終りに近づきつつあり、割り当てられたサービス要求を完了する可能性が高い、個々のクラウドリソース140を選択することができる。インスタンスマネージャ124は、賃借が満了する時に、マークされたクラウドリソースを解放することができる。その後、方法400は、ステップ450に進むことができ、ここで、この方法は終了する。図5に、リソースの例示的な応答時間を示すグラフ500を示す。グラフ500は、サービス要求の到着レート510が増える時に、リソースの応答時間505が増えることを示す。ある点Capit515で、リソースがサービス要求の到着レートを処理することが不可能になる。到着レートがCapit515に近付く時に、応答時間505は、劇的に増える。グラフ500は、所与の閾応答時間Thresp525を満足するために、理想的リソース要求負荷λi520をどのようにして予測できるのかをも示す。図6に、リソースの例示的な理想的負荷を示すグラフ600を示す。システム到着レートΛsys605がある点を超えて増える時に、理想的リソース要求負荷λi520が減る。この影響は、多数のサービス要求を分配するためにシステム100によって要求されるオーバーヘッドによって説明することができる。非スケーラブル非公開リソースまたはネットワーク輻輳などの動的ボトルネックは、応答時間を増やし、個々のリソースが閾応答時間内に応答することをより困難にする可能性がある。したがって、理想的リソース要求負荷λi520が減少することにより、リソースが閾値を満足することを可能にする。図7に、リソースの例示的な動作領域を示すグラフ700を示す。グラフ700は、たとえば、実際の個々のリソース要求負荷λi510およびシステム到着レートΛsys605など、システム入力を与えられて許容可能な応答レートを示すことができる。応答時間がグラフ700の下にある場合には、リソースが、良い領域で動作しつつある可能性があり、これは、そのリソースが効率的に動作しつつあることを示す。たとえば、リソースが、理想的リソース要求負荷λi520で動作しつつあり、閾応答時間Thresp525と等しい応答時間を有する場合には、そのリソースは、良い領域の中央で動作しつつある可能性がある。その一方で、応答レートがグラフ700の上にあるか、実際の個々のリソース要求負荷λi510がCapit515より大きい場合には、そのリソースは、悪い領域で動作しつつあるか、非効率的に実行しつつある可能性がある。リソースの各タイプに、たとえば、関数またはクリティカルポイントのリストなどのグラフ700の表現を与えることができる。代替案では、グラフ700を、テストデータに基づいて性能モニタ112によって判定することができる。内部リソース130をエミュレートするクラウドリソース140に、それらがエミュレートするリソースと同一のグラフ700を割り当てることができる。動作領域を、応答時間以外のメトリックを使用して判定できることは明白である。たとえばリソーススループットなどの他のメトリックについて、より大きいメトリック値が、望ましい場合があり、グラフは、それ相応に変化する可能性がある。前述によれば、さまざまな例示的実施形態は、クラウドリソースをスケーリングするシステムおよび方法を提供する。具体的には、性能メトリックを測定し、メトリックを閾値と比較することによって、この方法およびシステムは、クラウドリソースをスケーリングするフィードバックコントローラを実施する。さらに、システム負荷および理想的リソース負荷に基づいてクラウドリソースを調整することによって、調整は、性能を超える負荷の分数に比例する。さらに、この方法およびシステムは、リソースが悪い領域で動作しつつある時を判定することによって、動的ボトルネックをも検出することができる。前述の説明から、本発明のさまざまな例示的実施形態を、ハードウェアおよび/またはファームウェアで実施できることは明白である。さらに、さまざまな例示的実施形態を、機械可読記憶媒体上に格納された命令として実施することができ、この命令を、本明細書で詳細に説明した動作を実行するために少なくとも1つのプロセッサによって読み取り、実行することができる。機械可読記憶媒体は、パーソナルコンピュータもしくはラップトップコンピュータ、サーバ、または他のコンピューティングデバイスなどの機械によって可読の形で情報を格納するすべての機構を含むことができる。したがって、機械可読記憶媒体は、読取専用メモリROM、ランダムアクセスメモリRAM、磁気ディスク記憶媒体、光記憶媒体、フラッシュメモリデバイス、および類似する記憶媒体を含むことができる。当業者は、本明細書のすべてのブロック図が、本発明の原理を実施する例示的な回路網の概念図を表すことを理解するはずである。同様に、すべてのフローチャート、流れ図、状態遷移図、擬似コード、および類似物が、機械可読媒体内で実質的に表され、コンピュータまたはプロセッサが明示的に図示されようとされまいと、そのようなコンピュータまたはプロセッサによって実行され得るさまざまなプロセスを表すことを了解されたい。さまざまな例示的実施形態を、そのある種の例示的態様への特定の参照を用いて詳細に説明したが、本発明が、他の実施形態が可能であり、その詳細が、さまざまな明白な面で変更が可能であることを理解されたい。当業者にたやすく理解されるように、本発明の趣旨および範囲の中に留まりながら、変形および変更を行うことができる。したがって、前述の開示、説明、および図面は、例示的であるのみであって、いかなる形でも本発明を限定せず、本発明は、特許請求の範囲のみによって定義される。