JP2014501994A

JP2014501994A - 企業アプリケーションのシームレス・スケーリング

Info

Publication number: JP2014501994A
Application number: JP2013548414A
Authority: JP
Inventors: リ，リ; ウー，トーマス
Original assignee: アルカテル−ルーセント
Priority date: 2011-01-05
Filing date: 2011-12-19
Publication date: 2014-01-23
Also published as: CN103477323A; US20120173709A1; EP2661690A2; WO2012094138A3; WO2012094138A2

Abstract

さまざまな例示的実施形態は、コンピューティング・システムのリソースをスケーリングする方法であって、この方法は、システム性能のメトリックの閾値をセットするステップと、メトリックの閾値に基づいて少なくとも１つのリソースの理想的リソース負荷を判定するステップと、コンピューティング・システム・リソースの中でシステム作業負荷を分配するステップと、システム作業負荷、理想的リソース負荷、およびリソースの現在の個数に基づいてリソースの個数を調整するステップとを含むことができる。さまざまな例示的実施形態は、クラウド・リソースをスケーリングするコンピューティング・システムにも関する。このコンピューティング・システムは、内部リソースと、ロード・バランサと、性能モニタと、通信モジュールと、ジョブ・ディスパッチング・モジュールと、コントローラとを含むことができる。さまざまな例示的実施形態は、リソース性能メトリックを使用してリソース・スケーリング中に動的ボトルネックを検出する方法および履歴システム性能メトリックを使用してスケーリング閉塞点を検出する方法にも関する。

Description

本明細書で開示されるさまざまな例示的実施形態は、全般的にはネットワーク拡張に関する。

クラウド・コンピューティングは、エンティティが、インターネットなどのネットワーク上のどこかに配置されたコンピュータ・リソースを賃借し、使用することを可能にする。クラウド・リソースを、必要な時にプロバイダから賃借し、さまざまなサービスを実行するために構成することができる。データ・セキュリティを保証するために、データを、仮想プライベート・ネットワーク（ＶＰＮ）を使用してクラウド・リソースに送信することができる。クラウド・プロバイダは、仮想計算機を使用して、顧客にリソース・オプションのある範囲を提供することができる。クラウド・コンピューティングは、リソースの柔軟性、アジリティ、およびスケーラビリティを可能にする。

１つの現在のクラウド・コンピューティング・モデルが、Ａｍａｚｏｎのｖｉｒｔｕａｌｐｒｉｖａｔｅｃｌｏｕｄ（ＶＰＣ）である。ＶＰＣは、顧客が１時間あたりの料金で必要に応じてコンピューティング・リソースを賃借することを可能にする。ＶＰＣは、仮想計算機モデルを使用して、実際のコンピュータ・リソースをｅｌａｓｔｉｃｃｏｍｐｕｔｅｃｌｏｕｄ（ＥＣ２）に抽象化する。顧客は、ＥＣ２を用いて仮想計算機のインスタンスを賃借することができる。顧客は、彼らからの需要の変化に従って、仮想計算機の台数を変更することができる。Ａｍａｚｏｎは、仮想計算機を監視し、獲得し、または賃借することによってＥＣ２を管理するためのＡＰＩを提供する。

ＡｍａｚｏｎのＶＰＣなどのクラウド・コンピューティング・システムの利用を望む企業は、複数の懸念事項を有する。第１に、仮想計算機のセキュリティに疑問がある。ＶＰＣ顧客は、クラウド・リソースの正確な構成を知らず、機密データがクラウド・リソース上で処理されることを望まない場合がある。第２に、企業は、クラウド・リソースの使用について対価を支払わなければならないので、ＶＰＣ内のクラウド・リソースを獲得する前に、企業自体の内部コンピューティング・リソースを使用することを望む場合がある。企業は、クラウド・リソースのスケールおよびクラウド・リソースと内部リソースとの間の作業の割当てを効率的に制御できなければならない。最後に、追加のコンピューティング・リソースが、必ずすべての性能に関する問題を解決するとは限らない。

前述に鑑みて、賃借されるクラウド・リソースのスケールを制御するシステムおよび方法を提供することが望ましい。具体的には、内部企業リソースに関してクラウド・リソースをスケーリングするシステムを提供することが望ましい。また、システムが、過剰なコストを防ぐためにクラウド・リソースの使用を最適化できたならば、それは望ましいことであろう。

クラウド・リソースのスケールを制御するシステムおよび方法の現在の必要に鑑みて、さまざまな例示的実施形態の短い要約を提示する。次の要約では、いくつかの単純化および省略を行う場合があり、さまざまな例示的実施形態のいくつかの態様を強調し、紹介することが意図されているが、本発明の範囲を限定することは意図されていない。当業者が発明的概念を作り、利用することを可能にするのに適当な好ましい例示的実施形態の詳細な説明を、より後のセクションで続ける。

さまざまな例示的実施形態は、コンピューティング・システムのリソースをスケーリングする方法に関する。この方法は、システム性能の第１のメトリックの閾値をセットするステップと、コンピューティング・システム・リソースの中でシステム作業負荷を分配するステップと、以前の時間間隔中のシステムの性能に基づいてシステム性能の第１のメトリックを測定するステップと、測定された第１のメトリックを第１のメトリックの閾値と比較するステップと、第１のメトリックの閾値に基づいて各リソースの理想的リソース負荷を判定するステップと、システム作業負荷、各リソースの理想的リソース負荷、およびリソースの現在の個数に基づいて、リソースの個数を調整するステップとを含む。コンピューティング・システム・リソースの個数を調整するステップは、各リソースの理想的リソース負荷によってシステム作業負荷を割ることによってリソースの理想的個数を判定するステップと、リソースの理想的個数からリソースの現在の個数を引くことによってリソースの変化を判定するステップと、リソースの変化が負である場合に、少なくとも１つのリソースを解放するステップと、リソースの変化が正である場合に、少なくとも１つの追加リソースを獲得するステップとを含むことができる。この方法は、少なくとも１つのシステム・リソースが悪い領域で動作しつつあることを判定するステップと、追加のシステム・リソースを獲得するのをやめるステップと、サービス要求をシステム作業負荷から除去するステップとをも含むことができる。さまざまな例示的実施形態は、コンピューティング・システムのリソースをスケーリングする命令として機械可読記憶媒体上で符号化された上記の方法に関する。

さまざまな例示的実施形態は、クラウド・リソースをスケーリングするコンピューティング・システムに関する。このコンピューティング・システムは、コンピューティング・タスクを実行する内部リソースと、ロード・バランサと、クラウド・リソースをスケーリングするコントローラとを含むことができる。ロード・バランサは、時間間隔の間の第１の性能メトリックおよびシステム負荷を含むシステム性能メトリックを収集する性能モニタと、クラウド・リソースの量を含むクラウド・リソース情報を収集する通信モジュールと、内部リソースおよびクラウド・リソースにコンピューティング・タスクを向けるジョブ・ディスパッチング・モジュールとを含むことができる。コントローラは、第１の性能メトリックに基づいてクラウド・リソースをスケーリングし、クラウド・リソース情報をロード・バランサに提供することができる。コントローラは、予測されたシステム負荷を理想的リソース負荷によって割ることによってリソースの理想的個数を判定するスケーリング・モジュールと、クラウド・リソースを獲得することまたは解放することによって、リソースの理想的個数と等しくなるようにシステム・リソースの総数を調整するインスタンス・マネージャと含むことができる。さらに、性能モニタは、各リソースの個々のリソース負荷および性能メトリックを測定し、リソースの個々の性能メトリックを個々のリソース負荷に基づく許容可能な性能標準と比較することによって各リソースが悪い領域で動作しつつあるかどうかを判定することができる。

さまざまな例示的実施形態は、内部リソースおよびクラウド・リソースを使用するコンピューティング・システム内で性能ボトルネックを識別する方法に関する。この方法は、各リソースを検査するステップと、リソース特性およびリソース負荷に基づいてリソース性能メトリックの許容可能な値を判定するステップと、リソース性能メトリックを測定するステップと、リソース性能メトリックが許容可能な値を超える場合に、リソースが非効率的に動作しつつあると判定するステップと、少なくともリソースの所定の個数が非効率的に動作しつつある場合に、システムが性能ボトルネックに達したと判定するステップとを含むことができる。

さまざまな例示的実施形態は、クラウド・リソースを使用するコンピューティング・システム内でスケーリングの閉塞点を識別する方法に関する。この方法は、履歴システム・メトリック値を測定するステップと、履歴システム・メトリック値およびリソースの数に基づいて追加リソースを追加するためのシステム・メトリック値利得を推定するステップと、追加クラウド・リソースを追加するステップと、実際のシステム・メトリック値利得を測定するステップと、実際のシステム・メトリック値利得が推定されたシステム・メトリック値利得のセットされたパーセンテージ未満である場合に、コンピューティング・システムが性能ボトルネックに達したと判定するステップとを含むことができる。

このようにして、さまざまな例示的実施形態により、クラウド・リソースの最適化されたスケーリングのためのシステムおよび方法が使用可能となることは明白であるはずである。具体的には、性能メトリックを測定し、メトリックを閾値と比較することによって、この方法およびシステムは、クラウド・リソースをスケーリングするのにシステム・フィードバックを使用することができる。さらに、この方法およびシステムは、リソースが効率の期待されるレベル未満で動作しつつある時を判定することによって、動的ボトルネックを検出することもできる。

さまざまな例示的実施形態をよりよく理解するために、添付図面を参照する。

クラウド・リソースをスケーリングする例示的コンピューティング・システムを示す概略図である。フィードバックに基づいてクラウド・リソースをスケーリングする例示的方法を示す図である。クラウド・リソースの個数を調整する例示的方法を示す図である。クラウド・リソースの理想的個数の変化を判定する例示的方法を示す図である。リソースの例示的な応答時間を示すグラフである。リソースの例示的な理想的負荷を示すグラフである。リソースの例示的な動作領域を示すグラフである。

これから、同様の符号が同様のコンポーネントまたはステップを指す図面を参照して、さまざまな例示的実施形態の広義の態様を開示する。

図１に、クラウド・リソース１４０をスケーリングする例示的なコンピューティング・システム１００の概略図を示す。システム１００は、ロード・バランサ１１０およびコントローラ１２０を含むことができる。システム１００を、内部リソース１３０およびクラウド・リソース１４０に接続することができる。システム１００は、サービス要求を受信し、処理の要求を内部リソース１３０またはクラウド・リソース１４０のいずれかに分配することができる。サービス要求は、システム所有者によって提供されるサービスに応じて変化する可能性がある。たとえば、システム所有者は、テキスト、イメージ、オーディオ、ビデオ、およびゲーミングなどのコンテンツ、販売、計算、およびストレージなどのサービス、またはインターネット上で提供される任意の他のコンテンツもしくはサービスを提供することができる。サービス要求は、企業アプリケーションを含むこともでき、ここで、要求は、内部企業ネットワークから届く可能性がある。サービス要求を、システム作業負荷と考えることができる。システム作業負荷を、サービス要求の到着レートによって測定することができる。システム１００は、サービス要求負荷を効率的に管理するためにクラウド・リソース１４０をスケーリングすることもできる。

ロード・バランサ１１０は、インターネット上のどこかにいるユーザからサービス要求を受信することができる。ロード・バランサ１１０は、サービス要求を内部リソース１３０またはクラウド・リソース１４０のいずれかに分配することができる。ロード・バランサ１１０は、完了したサービス要求を受信して、要求しているユーザにその要求を返すこともできる。サービス要求の分配は、さまざまなリソースの性能に依存するものとすることができる。ロード・バランサ１１０は、総合システム性能ならびに個々の内部リソース１３０およびクラウド・リソース１４０の性能を監視することができる。ロード・バランサ１１０は、クラウド・リソース１４０のスケーリングが必要であるかどうかの判定を助けるために、コントローラ１２０に性能データを供給することができる。ロード・バランサ１１０は、クラウド・リソース１４０に関する構成情報および性能情報をコントローラ１２０から受け取ることができる。ロード・バランサ１１０は、性能モニタ１１２、ジョブ・ディスパッチャ１１４、および通信モジュール１１６を含むことができる。

性能モニタ１１２は、サービス要求を処理する際に全体としてのシステムの性能を監視するように構成された、ハードウェアおよび／または機械可読記憶媒体上の実行可能命令を含むことができる。性能モニタ１１２は、システムが適当に実行しつつあるかどうかを評価するのにメトリックを使用することができる。さまざまな例示的実施形態では、性能モニタ１１２は、システム性能を測定するメトリックとして、ロード・バランサ１１０でのサービス要求の到着からロード・バランサ１１０での応答のリターンまでの、システム応答時間を計算することができる。たとえば、性能モニタは、システム性能のメトリックを提供するために、たとえば、第９５パーセンタイル内に含まれるサービス要求の応答時間など、サービス要求応答時間のあるパーセンタイルを測定することができる。閾値をまたぐ時に性能が不適切であることを示すために、性能モニタ１１２をメトリックに関する閾値を用いて構成することができる。性能モニタ１１２は、システム性能を測定するのに適当である可能性がある他のメトリックを測定することもできる。性能モニタ１１２は、たとえば、内部リソース１３０、通信モジュール１１６、およびコントローラ１２０などの他のコンポーネントから測定値を収集することもできる。

ジョブ・ディスパッチャ１１４は、内部リソース１３０およびクラウド・リソース１４０の間で着信サービス要求を分配するように構成された、ハードウェアおよび／または機械可読記憶媒体上の実行可能命令を含むことができる。以下でより詳細に説明するように、内部リソース１３０は、プライベート・リソースを含む複数のタイプのリソースを含むことができる。同様に、クラウド・リソース１４０は、異なるタイプのリソースを含むことができる。ジョブ・ディスパッチャ１１４は、サービス要求を、その要求を処理するのに適当なタイプのリソースに分配することができる。ジョブ・ディスパッチャ１１４は、同一タイプのリソースの間で要求負荷を平衡化することもできる。ジョブ・ディスパッチャ１１４は、内部リソース１３０とクラウド・リソース１４０との間での要求の割当てを判定するのに、ポリシーを使用することができる。たとえば、コストを節約しようとするポリシーは、性能メトリックが閾値以内に留まる限り、クラウド・リソースより内部リソースを優先することができる。代替の例のポリシーは、要求を最もよく処理することができるリソースに要求を割り当てることによって、メトリックを最適化しようと努めることができる。たとえば、加重ラウンド・ロビン、最少接続、または最速応答などの負荷平衡化に関して当技術分野で既知の方法を、ポリシーによって使用して、要求負荷を平衡化することができる。

通信モジュール１１６は、クラウド・リソースをスケーリングするためにコントローラ１２０と相互作用するように構成された、ハードウェアおよび／または機械可読記憶媒体上の実行可能命令を含むことができる。通信モジュール１１６は、性能モニタ１１２からコントローラ１２０へ性能メトリックを供給することができる。通信モジュール１１６を、メトリックが閾値を超える場合にそれらのメトリックを報告するコールバック関数を用いて構成することができる。コントローラ１２０は、性能モニタ１１２での収集のためにクラウド・リソース１４０の性能メトリックを通信モジュール１１６に送ることができる。通信モジュール１１６は、たとえば、クラウド・リソースとして使用される計算機または仮想計算機の個数および特性などのクラウド・リソース情報をコントローラ１２０から受け取ることもできる。通信モジュール１１６は、有効な性能測定および要求分配を可能にするために、このクラウド・リソース情報を性能モニタ１１２およびジョブ・ディスパッチャ１１４に渡すことができる。さまざまな代替実施形態では、コントローラ１２０を、ロード・バランサ１１０と統合することができ、その場合には、通信モジュール１１６を不要とすることができる。

コントローラ１２０は、クラウド・リソース１４０を制御することができる。コントローラ１２０を、二進フィードバック・コントローラ、比例コントローラ（Ｐコントローラ）、比例積分コントローラ（ＰＩコントローラ）、または比例積分偏差コントローラ（ＰＩＤコントローラ）とすることができる。コントローラ１２０は、通信モジュール１１６およびクラウド・リソース１４０から受け取った情報に基づいてクラウド・リソース１４０の適当なスケールを判定することができる。コントローラ１２０は、クラウド・リソース１４０に適当な要求を送信することによって、クラウド・リソースを解放しまたは獲得することができる。コントローラ１２０は、スケーリング・モジュール１２２およびインスタンス・マネージャ１２４を含むことができる。

スケーリング・モジュール１２２は、性能モニタ１１２によって供給される性能メトリックに基づいてクラウド・リソース１４０の適当な個数を判定するように構成されたハードウェアおよび／または機械可読記憶媒体上の実行可能命令を含むことができる。スケーリング・モジュール１２２は、クラウド・リソースの適当な個数を判定し、その個数をインスタンス・マネージャ１２４に渡すことができる。スケーリング・モジュール１２２は、利用すべきクラウド・リソースの個数を判定するのに、性能モニタ１１２によって供給される性能メトリックおよび他のデータを使用することができる。以下で図４および７に関して説明するように、スケーリング・モジュール１２２は、システムが閉塞しつつあるかどうかを判定することもできる。システム１００は、システムがクラウド・リソースのスケール以外の動的ボトルネックに直面する場合に、閉塞する可能性がある。たとえば、多数の要求が、あまりに多くの帯域幅を使用し、ネットワーク制約が、クラウド・リソースに対してサービス要求をスケーリングする能力を制限する場合がある。スケーリング・モジュール１２２は、性能モニタ１１２およびクラウド・リソース１４０からの情報を使用して、少なくとも１つのリソースが悪い領域で動作しつつあることを性能データが示す場合に、動的ボトルネックがあると判定することができる。スケーリング・モジュール１２２によって使用される例示的方法を、以下で図３に関してさらに詳細に説明する。

インスタンス・マネージャ１２４は、スケーリング・モジュール１２２によって示されるスケールを実施するためにクラウド・リソース１４０を制御するように構成されたハードウェアおよび／または機械可読記憶媒体上の実行可能命令を含むことができる。さまざまな例示的実施形態では、クラウド・リソース１４０は、インスタンス・マネージャ１２４が追加リソースを獲得しまたは不必要なリソースを解放することを可能にするアプリケーション・プログラミング・インターフェース（ＡＰＩ）と共に提供される。インスタンス・マネージャ１２４は、現在賃借されている各リソースを追跡し、賃借が終わる時を知ることができる。インスタンス・マネージャ１２４は、スケーリング・モジュール１２２によって示されるものより多くのリソースがある場合に、解放のためにリソースをマークすることができる。インスタンス・マネージャ１２４は、スケーリング・モジュール１２２によって示されたクラウド・リソースの個数を実施するために、新しい賃借を獲得すべきかどうか、およびいつ獲得すべきかを判断することができる。インスタンス・マネージャ１２４は、新しいリソースを獲得するのではなく、削除についてマークされたリソースを再アクティブ化することができる。インスタンス・マネージャ１２４は、ＡＰＩを使用してクラウド・リソース１４０からクラウド・リソース情報を入手し、この情報をスケーリング・モジュール１２２および通信モジュール１１６に渡すこともできる。さまざまな代替実施形態では、クラウド・リソース１４０は、オートスケーラ（ａｕｔｏ−ｓｃａｌｅｒ）および負荷マネージャを含むことができる。これらの実施形態では、インスタンス・マネージャ１２４は、クラウド・リソースの所望の個数を達成するために、クラウド・リソース１４０をオートスケーラとして構成するか、オートスケーラを有効／無効にすることができる。さまざまな代替実施形態では、システム１００は、クラウド・リソースの異なるプロバイダと相互作用することができる。これらの実施形態では、異なるクラウド・リソース１４０を制御する複数のインスタンス・マネージャ１２４があるものとすることができる。

内部リソース１３０は、システム所有者によって所有され、運営されるコンピュータ・リソースを含むことができる。内部リソース１３０は、サービス要求の満足などのさまざまなコンピューティング・タスクを実行することができる。内部リソース１３０を、複数の層に分割することができる。たとえば、３層システムは、ユーザと通信するフロントエンド・サーバ１３２、ビジネス・ロジックを実施するアプリケーション・サーバ１３４、およびデータベース・サーバ１３６を含むことができる。さまざまな例示的実施形態では、１つまたは複数の層を非公開とすることができる。たとえば、データベース・サーバ１３６は、法によって所有者が共有してはならない機密非公開情報を含むので、非公開とすることができる。クラウド・リソースなどのデータベース・サーバをインスタンス化することが、高価で時間がかかる場合もある。ロード・バランサ１１０は、非公開リソースに関する要求をクラウド要求として複製することを回避することができる。ロード・バランサ１１０は、ある種のサービス要求が非公開リソースへのアクセスを要求する場合に、必ずその要求を内部リソース１３０に割り当てることができる。

クラウド・リソース１４０を、クラウド・リソース・プロバイダによって所有され、システム所有者に賃貸されるコンピュータ・リソースとすることができる。さまざまな例示的実施形態では、クラウド・リソースは、仮想計算機として編成される。システム所有者は、内部リソースをエミュレートするために仮想計算機を賃借することができる。たとえば、クラウド・サーバ１４２が、フロントエンド・サーバ１３２をエミュレートすることができ、クラウド・サーバ１４４が、アプリケーション・サーバ１３４をエミュレートすることができる。クラウド・リソース・プロバイダは、実際には仮想計算機を異なった形で実装することができるが、エミュレートされた内部リソースと同一の性能を保証することができる。システム１００は、クラウド・リソース１４０を、対応する内部リソース１３０と同一として扱うことができる。システム１００は、クラウド・リソース１４０が、通信遅延に起因して内部リソース１３０より長い応答時間を有する場合があることを認識する場合もある。クラウド・リソースは、必要に応じて賃借され得るが、仮想計算機がインスタンス化される時に、かなりのスタート・アップ時間を必要とする場合がある。クラウド・リソース・プロバイダは、１時間あたりの料金、実際の使用量、または任意の他の請求方法に基づいて、クラウド・リソースを賃貸することができる。

システム１００のコンポーネントを説明したので、例示的実施形態の動作の短い説明を説明する。このプロセスは、内部リソース１３０がすべてのサービス要求を処理できる、比較的非ビジーの状態で始めることができる。この状態では、ロード・バランサ１１０は、すべての要求を内部リソース１３０の間で分配することができる。サービス要求のレートが増える時に、システム性能が劣化する可能性があり、性能メトリックが閾値を超えたことを、性能モニタ１１２が検出する場合がある。通信モジュール１１６は、性能メトリックが閾値を超えたことをコントローラ１２０に知らせ、他のシステム情報を提供することができる。スケーリング・モジュール１２２は、性能メトリック閾値を満足するために何個のクラウド・リソースが必要であるのかを判定することができる。インスタンス・マネージャ１２４は、たとえばクラウド・サーバ１４２などの追加リソースを獲得するために、クラウド・リソース１４０と通信することができる。各クラウド・リソース１４０が動作状態になった後に、インスタンス・マネージャ１２４は、リソースが使用可能であることを通信モジュールに知らせることができる。その後、ジョブ・ディスパッチャ１１４は、サービス要求を内部リソース１３０とクラウド・リソース１４０との両方に割り当てることができる。スケーリング・モジュール１２２は、何個のクラウド・リソースが必要であるのかを判定し続けることができ、インスタンス・マネージャ１２４は、必要に応じてリソースを追加しまたは解放することができる。スケーリング・モジュール１２２は、追加リソースを追加する前に、システム１００が閉塞しつつあるかどうかを判定することもできる。このようにして、システム１００は、所望の性能メトリックを達成するためにクラウド・リソースをスケーリングすることができる。

図２に、フィードバックに基づいてクラウド・リソース１４０をスケーリングする例示的方法２００の流れ図を示す。方法２００を、システム１００のコンポーネントによって実行することができる。システム１００は、クラウド・リソース１４０の個数を継続的に調整するために、方法２００を繰り返して実行することができる。システム１００は、固定された時間間隔中に方法２００を実行することができる。さまざまな例示的実施形態では、時間間隔を１０秒とすることができるが、任意の時間間隔を選択することができる。

方法２００は、ステップ２０５で開始し、ステップ２１０に進むことができ、ステップ２１０では、システム１００が、システム１００を構成すべきかどうかを判定することができる。方法２００が、初めて実行されつつある場合には、システム１００は、構成を実行すると判断することができ、この方法は、ステップ２１５に進むことができる。システム１００が既に構成されている場合には、この方法は、ステップ２２０に進むことができる。

ステップ２１５では、システム１００は、さまざまな閾値をセットすることができる。たとえば、性能モニタ１１２は、システム応答時間の閾値をセットすることができる。このメトリックは、サービス要求の処理に関する性能目標を表すことができる。性能モニタ１１２を、システム性能を測定する時間間隔を用いて構成することもできる。システム１００は、他の構成タスクを実行することもできる。たとえば、インスタンス・マネージャ１２４は、各内部リソース１３０をエミュレートするのに使用すべきクラウド・リソース１４０の中の仮想計算機を判定することができる。ジョブ・ディスパッチャ１１４を、サービス要求を処理するのに使用できる内部リソース１３０の個数を用いて初期化することができる。その後、方法２００は、ステップ２２０に進むことができる。

ステップ２２０では、ジョブ・ディスパッチャ１１４が、内部リソース１３０およびクラウド・リソース１４０の中で着信サービス要求を分配することができる。ジョブ・ディスパッチャ１１４は、サービス要求を分配するポリシーを実施することができる。たとえば、ジョブ・ディスパッチャ１１４は、応答時間が性能閾値を超えない限り、内部リソース１３０を優先することができる。このポリシーは、クラウド・リソース１４０の使用およびコストを最小にすることができる。その後、内部リソース１３０およびクラウド・リソース１４０は、サービス要求を処理することができる。完了したサービス要求応答を、ロード・バランサ１１０を介して返すことができる。その後、この方法は、ステップ２２５に進むことができる。

ステップ２２５では、性能モニタ１１２が、たとえばシステム応答時間などのシステム性能メトリックを測定することができる。さまざまな実施形態では、個々のサービス要求応答時間の第９５パーセンタイルの測定値を、システム性能の有効な測定値として使用することができる。性能モニタ１１２は、システム・サービス要求負荷を測定することもできる。他のパーセンタイルまたは性能メトリックを使用することもできる。その後、この方法は、ステップ２３０に進むことができる。

ステップ２３０では、性能メトリックを、ステップ２１５で構成された閾値と比較することができる。測定されたシステム・メトリックが閾値を超える場合には、方法２００は、ステップ２３５に進むことができる。測定されたシステム・メトリックが閾値を超えない場合には、システム１００は、リソースの調整が不要であると判定することができ、この方法は、ステップ２５０に進むことができ、ステップ２５０では、この方法が終了する。

ステップ２３５では、スケーリング・モジュール１２２が、性能閾値を満足するための各リソースの理想的なリソース負荷を判定することができる。図５および図６に関してさらに詳細に説明するように、各リソースの理想的な要求負荷は、リソース特性およびシステム負荷に依存して変化する可能性がある。同一タイプの各リソースの理想的な要求負荷を、同一とすることができる。たとえば、各フロントエンド・サーバ１３２は、同一の理想的な要求負荷を有することができる。同様に、フロントエンド・サーバ１３２をエミュレートする各クラウド・サーバ１４２は、同一の理想的な要求負荷を有することができる。その後、方法２００は、ステップ２４０に進むことができる。

ステップ２４０では、スケーリング・モジュール１２２が、クラウド・リソースの正しい個数を判定することができる。コントローラ１２０が二進フィードバック・コントローラであるさまざまな例示的実施形態では、スケーリング・モジュール１２２は、測定された性能メトリックがステップ２３０で判定された閾値を超える場合に、単純に、追加のクラウド・リソースのセットされた個数を追加することができる。その代わりに、スケーリング・モジュール１２２が、システム性能をより早く向上させるために、クラウド・リソース１４０の個数を増やすことができる。コントローラ１２０がＰコントローラであるさまざまな例示的実施形態では、スケーリング・モジュール１２２は、測定されたシステム負荷をステップ２３５で判定された理想的なリソース負荷によって割ることによって、クラウド・リソース１４０の正しい個数を判定することができる。これらの実施形態では、クラウド・リソースの変化を、性能を超えるシステム負荷の分数に比例するものとすることができる。コントローラ１２０がＰＩコントローラであるさまざまな例示的実施形態では、スケーリング・モジュール１２２は、理想的なリソース負荷によって割る前に、測定されたシステム負荷に整数成分を加算することによって、クラウド・リソース１４０の正しい個数を判定することができる。この整数成分は、セットされた時間間隔にわたるシステム負荷の変化の合計とすることができる。スケーリング・モジュール１２２は、コントローラ１２０がＰＩＤコントローラであるさまざまな実施形態で、微分成分を使用することもできる。スケーリング・モジュール１２２の動作を、図３に関して以下でさらに詳細に説明する。その後、方法２００は、ステップ２４５に進むことができる。

ステップ２４５では、インスタンス・マネージャ１２４が、ステップ２４０で判定されたクラウド・リソース１４０の個数に従ってクラウド・リソースを調整することができる。インスタンス・マネージャ１２４は、追加のクラウド・リソース１４０を追加するためにクラウド・リソース・プロバイダと通信することができる。さまざまな実施形態では、インスタンス・マネージャ１２４は、さらに、追加のクラウド・リソース１４０を追加する前に、システム１００が閉塞しつつあるかどうかを判定するのに性能モニタ１１２を使用することができる。インスタンス・マネージャ１２４は、解放のためにクラウド・リソース１４０をマークすることもできる。インスタンス・マネージャ１２４の動作を、図３に関して以下でさらに詳細に説明する。インスタンス・マネージャ１２４がリソースの個数を調整した後に、方法２００はステップ２５０に進むことができ、ここで、この方法は終了する。

図３に、クラウド・リソースの理想的個数の変化を判定する例示的方法３００の流れ図を示す。方法３００は、方法２００のステップ２４０中のシステム１００の動作を説明することができる。

方法３００は、ステップ３０５で開始し、ステップ３１０に進むことができ、ステップ３１０では、性能モニタ１１２が、現在のシステム負荷を判定する。現在のシステム負荷を、前の時間間隔中のサービス要求の到着レートとして測定することができる。現在のシステム負荷は、内部リソース１３０とクラウド・リソース１４０との両方によって処理されるサービス要求を含むことができる。代替案では、内部リソース１３０が固定されているので、内部リソース１３０に関する負荷を引くことができる。性能モニタ１１２は、通信モジュール１１６を介してスケーリング・モジュール１２２に現在のシステム負荷を送ることができる。この方法は、その後、ステップ３１５に進むことができる。

ステップ３１５では、スケーリング・モジュール１２２が、積分成分に従って現在の負荷を調整する。積分成分を、前の時間間隔にわたるシステム負荷の変化の合計とすることができる。積分成分は、システム負荷の傾向を示すのを助けることができる。積分成分は、重み付け係数を含むこともできる。コントローラ１２０がＰコントローラであるさまざまな例示的実施形態では、ステップ３１５をオプションとすることができる。さまざまな代替実施形態では、ステップ３１５は、微分成分に従って現在の負荷を調整することを含むことができる。その後、この方法はステップ３２０に進むことができる。

ステップ３２０では、スケーリング・モジュール１２２が、各サーバの理想的負荷を判定することができる。以下で図５および６に関して説明するように、リソースあたりの理想的負荷を、システム性能メトリック閾値以内に留まりながらリソースが処理できる最大負荷とすることができる。リソースあたりの理想的負荷を、内部リソース１３０とクラウド・リソース１４０との両方を含む、同一タイプの各リソースについて同一とすることができる。その後、この方法はステップ３２５に進むことができる。

ステップ３２５では、スケーリング・モジュール１２２が、リソースあたりの理想的負荷によって現在の負荷を割る。その結果は、期待される着信要求負荷を処理するのに必要なリソースの個数を示すことができる。その後、この方法はステップ３３０に進むことができ、ステップ３３０では、スケーリング・モジュール１２２が、クラウド・リソースの個数における必要な変化を判定することができる。スケーリング・モジュール１２２は、リソースの必要な個数から、内部リソース１３０の個数およびクラウド・リソース１４０の現在の個数を引くことができる。代替案では、内部リソースに対する負荷が既に引かれている場合に、スケーリング・モジュール１２２は、クラウド・リソースの現在の個数だけを引くことができる。スケーリング・モジュール１２２は、クラウド・リソースの変化をインスタンス・マネージャ１２４に渡すことができる。方法３００は、その後、ステップ３３５に進むことができ、ここで、この方法は終了する。

図４に、クラウド・リソースの個数を調整する例示的方法４００の流れ図を示す。方法４００は、方法２００のステップ２４５中のシステム１００の動作を説明することができる。方法４００は、ステップ４０５で開始し、ステップ４１０に進むことができ、ステップ４１０では、インスタンス・マネージャ１２４が、クラウド・リソースの変化が正であるかどうかを判定することができる。クラウド・リソースの変化が正である場合には、方法４００は、ステップ４１５に進むことができる。クラウド・リソースの変化が負である場合には、方法４００は、ステップ４４０に進むことができる。

ステップ４１５では、インスタンス・マネージャ１２４が、追加のクラウド・リソースを追加する前に、システムが閉塞しつつあるかどうかを判定するのに性能モニタ１１２を使用することができる。以下で図７に関してさらに詳細に説明するように、性能モニタ１１２は、個々のリソースのシステム性能メトリックが、システム入力を与えられて期待値を超える場合に、そのリソースが悪い領域で動作しつつあると判定することができる。この性能メトリックの格差は、リソースが非効率的に動作しつつあることを示す可能性がある。性能モニタ１１２が、少なくとも１つのリソースが悪い領域で動作しつつあると判定する場合には、性能モニタ１１２は、システムが閉塞しつつあると判定することができる。代替案では、性能モニタ１１２は、システムが閉塞しつつあると判定する前に、リソースのセットされたパーセンテージが悪い領域で動作しつつあることを要求することができる。さまざまな代替実施形態では、性能モニタ１１２は、追加リソースのスループット利得を測定することによって、システムが閉塞しつつあるかどうかを判定することができる。性能モニタ１１２は、測定されたスループット利得を、リソースあたりの履歴最大スループットに基づいて推定された利得と比較することができる。測定されたスループット利得が、推定されたスループット利得のセットされたパーセンテージ未満である場合には、性能モニタ１１２は、システムが閉塞しつつあると判定することができる。これらの代替実施形態では、性能モニタ１１２は、測定されたスループットがリソースあたりの履歴最大スループットに基づいて推定されたスループットに達する時に、システムがもはや閉塞してはいないと判定することができる。性能モニタ１１２が、システムが閉塞しつつあるのではないと判定する場合には、方法４００は、ステップ４２０に進むことができる。性能モニタ１１２が、システムが閉塞しつつあると判定する場合には、方法４００は、ステップ４３０に進むことができる。

ステップ４２０では、インスタンス・マネージャ１２４が、追加のクラウド・リソース１４０をアクティブ化することができる。既存のクラウド・リソース１４０のいずれかが解放のためにマークされている場合には、インスタンス・マネージャ１２４は、そのマークを解除することによって、そのクラウド・リソース１４０をアクティブ化することができる。解放のためにマークされたクラウド・リソース１４０がない場合には、インスタンス・マネージャ１２４は、追加のクラウド・リソース１４０をインスタンス化するために、クラウド・リソース・プロバイダと通信することができる。インスタンス・マネージャ１２４は、クラウド・リソースの変化から１を引くこともできる。その後、方法４００は、ステップ４２５に進むことができる。

ステップ４２５では、インスタンス・マネージャ１２４は、追加のクラウド・リソースが追加されたことをロード・バランサ１１０に示すことができる。性能モニタ１１２は、新しいクラウド・リソースの監視を開始することができる。ジョブ・ディスパッチャ１１４は、新しいクラウド・リソースにサービス要求を分配することができる。その後、方法４００は、ステップ４１０に戻って、追加のクラウド・リソースを追加するかどうかを判定することができる。

ステップ４３０では、システムが閉塞するのを防ぐために、ロード・バランサ１１０が、過剰なサービス要求を除去することができる。システム１００は、追加のクラウド・リソース１４０がシステム性能メトリックを改善しない可能性があると判定したので、ロード・バランサ１１０は、既存リソースに対するサービス要求負荷を減らすことができる。性能モニタ１１２は、どのタイプの動的ボトルネックがシステム１００を閉塞させつつあるのかを判定することもできる。たとえば、データベース・サーバ１３６などの非公開リソースの性能メトリックが閾値を超えていると性能モニタ１１２が判定する場合には、性能モニタ１１２は、非公開リソースが動的ボトルネックを引き起こしつつあると判定することができる。もう１つの例として、クラウド・リソース１４０の応答時間が内部リソース１３０の応答時間よりはるかに長いことを性能モニタ１１２が検出する場合には、性能モニタ１１２は、ネットワーク輻輳が動的ボトルネックを引き起こしつつあると判定することができる。性能モニタ１１２は、システム管理者に動的ボトルネックを報告することができる。その後、方法４００は、ステップ４５０に進むことができ、ここで、この方法は終了する。

ステップ４４０では、インスタンス・マネージャ１２４が、クラウド・リソース１４０の変化が負であるかどうかを判定することができる。クラウド・リソース１４０の変化が負である場合には、方法４００は、ステップ４４５に進むことができる。クラウド・リソース１４０の変化が負ではない場合には、インスタンス・マネージャ１２４は、何もしないものとすることができる。方法４００は、ステップ４５０に進むことができ、ここで、この方法は終了する。

ステップ４４５では、インスタンス・マネージャ１２４が、解放のためにクラウド・リソース１４０をマークすることができる。インスタンス・マネージャ１２４は、賃借が終りに近づきつつあり、割り当てられたサービス要求を完了する可能性が高い、個々のクラウド・リソース１４０を選択することができる。インスタンス・マネージャ１２４は、賃借が満了する時に、マークされたクラウド・リソースを解放することができる。その後、方法４００は、ステップ４５０に進むことができ、ここで、この方法は終了する。

図５に、リソースの例示的な応答時間を示すグラフ５００を示す。グラフ５００は、サービス要求の到着レート５１０が増える時に、リソースの応答時間５０５が増えることを示す。ある点Ｃａｐ_ｉ（ｔ）５１５で、リソースがサービス要求の到着レートを処理することが不可能になる。到着レートがＣａｐ_ｉ（ｔ）５１５に近付く時に、応答時間５０５は、劇的に増える。グラフ５００は、所与の閾応答時間Ｔｈ_ｒｅｓｐ５２５を満足するために、理想的リソース要求負荷λ_ｉ ^＊５２０をどのようにして予測できるのかをも示す。

図６に、リソースの例示的な理想的負荷を示すグラフ６００を示す。システム到着レートΛ_ｓｙｓ６０５がある点を超えて増える時に、理想的リソース要求負荷λ_ｉ ^＊５２０が減る。この影響は、多数のサービス要求を分配するためにシステム１００によって要求されるオーバーヘッドによって説明することができる。非スケーラブル非公開リソースまたはネットワーク輻輳などの動的ボトルネックは、応答時間を増やし、個々のリソースが閾応答時間内に応答することをより困難にする可能性がある。したがって、理想的リソース要求負荷λ_ｉ ^＊５２０が減少することにより、リソースが閾値を満足することを可能にする。

図７に、リソースの例示的な動作領域を示すグラフ７００を示す。グラフ７００は、たとえば、実際の個々のリソース要求負荷λ_ｉ５１０およびシステム到着レートΛ_ｓｙｓ６０５など、システム入力を与えられて許容可能な応答レートを示すことができる。応答時間がグラフ７００の下にある場合には、リソースが、良い領域で動作しつつある可能性があり、これは、そのリソースが効率的に動作しつつあることを示す。たとえば、リソースが、理想的リソース要求負荷λ_ｉ ^＊５２０で動作しつつあり、閾応答時間Ｔｈ_ｒｅｓｐ５２５と等しい応答時間を有する場合には、そのリソースは、良い領域の中央で動作しつつある可能性がある。その一方で、応答レートがグラフ７００の上にあるか、実際の個々のリソース要求負荷λ_ｉ５１０がＣａｐ_ｉ（ｔ）５１５より大きい場合には、そのリソースは、悪い領域で動作しつつあるか、非効率的に実行しつつある可能性がある。リソースの各タイプに、たとえば、関数またはクリティカル・ポイントのリストなどのグラフ７００の表現を与えることができる。代替案では、グラフ７００を、テスト・データに基づいて性能モニタ１１２によって判定することができる。内部リソース１３０をエミュレートするクラウド・リソース１４０に、それらがエミュレートするリソースと同一のグラフ７００を割り当てることができる。動作領域を、応答時間以外のメトリックを使用して判定できることは明白である。たとえばリソース・スループットなどの他のメトリックについて、より大きいメトリック値が、望ましい場合があり、グラフは、それ相応に変化する可能性がある。

前述によれば、さまざまな例示的実施形態は、クラウド・リソースをスケーリングするシステムおよび方法を提供する。具体的には、性能メトリックを測定し、メトリックを閾値と比較することによって、この方法およびシステムは、クラウド・リソースをスケーリングするフィードバック・コントローラを実施する。さらに、システム負荷および理想的リソース負荷に基づいてクラウド・リソースを調整することによって、調整は、性能を超える負荷の分数に比例する。さらに、この方法およびシステムは、リソースが悪い領域で動作しつつある時を判定することによって、動的ボトルネックをも検出することができる。

前述の説明から、本発明のさまざまな例示的実施形態を、ハードウェアおよび／またはファームウェアで実施できることは明白である。さらに、さまざまな例示的実施形態を、機械可読記憶媒体上に格納された命令として実施することができ、この命令を、本明細書で詳細に説明した動作を実行するために少なくとも１つのプロセッサによって読み取り、実行することができる。機械可読記憶媒体は、パーソナル・コンピュータもしくはラップトップ・コンピュータ、サーバ、または他のコンピューティング・デバイスなどの機械によって可読の形で情報を格納するすべての機構を含むことができる。したがって、機械可読記憶媒体は、読取専用メモリ（ＲＯＭ）、ランダム・アクセス・メモリ（ＲＡＭ）、磁気ディスク記憶媒体、光記憶媒体、フラッシュ・メモリ・デバイス、および類似する記憶媒体を含むことができる。

当業者は、本明細書のすべてのブロック図が、本発明の原理を実施する例示的な回路網の概念図を表すことを理解するはずである。同様に、すべてのフロー・チャート、流れ図、状態遷移図、擬似コード、および類似物が、機械可読媒体内で実質的に表され、コンピュータまたはプロセッサが明示的に図示されようとされまいと、そのようなコンピュータまたはプロセッサによって実行され得るさまざまなプロセスを表すことを了解されたい。

さまざまな例示的実施形態を、そのある種の例示的態様への特定の参照を用いて詳細に説明したが、本発明が、他の実施形態が可能であり、その詳細が、さまざまな明白な面で変更が可能であることを理解されたい。当業者にたやすく理解されるように、本発明の趣旨および範囲の中に留まりながら、変形および変更を行うことができる。したがって、前述の開示、説明、および図面は、例示的であるのみであって、いかなる形でも本発明を限定せず、本発明は、特許請求の範囲のみによって定義される。

Claims

コンピューティング・システムのリソースをスケーリングする方法であって、
システム性能の第１のメトリックの閾値をセットするステップと、
前記第１のメトリックの前記閾値に基づいて少なくとも１つのリソースの少なくとも１つの理想的リソース負荷を判定するステップと、
前記コンピューティング・システム・リソースの中でシステム作業負荷を分配するステップと、
前記システム作業負荷、前記理想的リソース負荷、およびリソースの現在の個数に基づいて、リソースの個数を調整するステップと
を含む方法。
コンピューティング・システム・リソースの前記個数を調整する前記ステップは、
前記理想的リソース負荷によって前記システム作業負荷を割ることによってリソースの理想的個数を判定するステップと、
リソースの前記理想的個数からリソースの前記現在の個数を引くことによってリソースの変化を判定するステップと、
リソースの前記変化が負である場合に、少なくとも１つのリソースを解放するステップと、
リソースの前記変化が正である場合に、少なくとも１つの追加リソースを獲得するステップと
を含む、請求項１に記載の方法。
少なくとも１つのリソースを解放する前記ステップは、
解放のために少なくとも１つのリソースをマークするステップと、
解放のためにマークされた前記リソースに作業を分配するのをやめるステップと、
リソースの賃借が満了する時に前記リソースを解放するステップと
を含む、請求項２に記載の方法。
少なくとも１つの追加リソースを獲得する前記ステップは、
解放のためにマークされた少なくとも１つのリソースがあるかどうかを判定するステップと、
解放のためにマークされた少なくとも１つのリソースがある場合に、前記少なくとも１つのリソースのマークを解除し、前記少なくとも１つのリソースに作業を分配するステップと、
解放のためにマークされた少なくとも１つのリソースがない場合に、追加リソースを獲得するステップと
を含む、請求項２に記載の方法。
各リソースについて、前記リソースの第１の性能メトリックを判定することと、前記リソースの実際の作業負荷を判定することと、前記性能メトリックを前記実際の作業負荷およびシステム作業負荷に基づく許容可能な性能標準と比較することとによって、少なくとも１つのシステム・リソースが悪い領域で動作しつつあることを判定するステップと、
前記第１の性能メトリックが前記許容可能な性能標準を超える場合に、前記リソースが悪い領域で動作しつつあると判定するステップと、
追加のシステム・リソースを獲得するのをやめるステップと、
前記システム作業負荷からサービス要求を除去するステップと
をさらに含む、請求項１に記載の方法。
コンピューティング・システム・リソースの前記個数を調整する前記ステップは、
前記システム作業負荷および積分成分の和を各リソースの前記理想的リソース負荷によって割ることによってリソースの理想的個数を判定するステップと、
リソースの前記理想的個数からリソースの前記現在の個数を引くことによってリソースの変化を判定するステップであって、前記積分成分は、第２の以前の時間間隔にわたるシステム作業負荷の変化の合計である、ステップと
を含む、請求項１に記載の方法。
コンピューティング・タスクを実行する内部リソースと、
時間間隔の間の第１の性能メトリックおよびシステム負荷を含むシステム性能メトリックを収集する性能モニタと、クラウド・リソースの量を含むクラウド・リソース情報を収集する通信モジュールと、前記内部リソースおよび前記クラウド・リソースにコンピューティング・タスクを向けるジョブ・ディスパッチング・モジュールとを含むロード・バランサと、
前記第１の性能メトリックに基づいて前記クラウド・リソースをスケーリングし、クラウド・リソース情報を前記ロード・バランサに提供するコントローラと
を含む、クラウド・リソースをスケーリングするコンピューティング・システム。
前記コントローラは、
予測されたシステム負荷を理想的リソース負荷によって割ることによってリソースの理想的個数を判定するスケーリング・モジュールと、
クラウド・リソースを獲得することまたは解放することによって、リソースの前記理想的個数と等しくなるようにシステム・リソースの総数を調整するインスタンス・マネージャと
をさらに含む、請求項７に記載のシステム。
内部リソースおよびクラウド・リソースを使用するコンピューティング・システム内で性能ボトルネックを識別する方法であって、
リソースごとに、
リソース特性およびリソース負荷に基づいてリソース性能メトリックの許容可能な値を判定するステップと、
前記リソース性能メトリックを測定するステップと、
前記リソース性能メトリックが前記許容可能な値を超える場合に、前記リソースが非効率的に動作しつつあると判定するステップと、
少なくとも前記リソースの所定の個数が非効率的に動作しつつある場合に、前記システムが性能ボトルネックに達したと判定するステップと
を含む方法。
クラウド・リソースを使用するコンピューティング・システム内でスケーリング閉塞点を識別する方法であって、
履歴システム・メトリック値を測定するステップと、
前記履歴システム・メトリック値およびリソースの数に基づいて追加リソースを追加するためのシステム・メトリック値利得を推定するステップと、
前記追加クラウド・リソースを追加するステップと、
実際のシステム・メトリック値利得を測定するステップと、
前記実際のシステム・メトリック値利得が前記推定されたシステム・メトリック値利得のセットされたパーセンテージ未満である場合に、前記コンピューティング・システムが性能ボトルネックに達したと判定するステップと
を含む方法。