(57)【要約】分散システムにおいて能力計画及びリソース最適化を実行する方法及び装置が開示される。特に、分散システムから収集された測定値間の関係を用いて、分散システム内の個々のコンポーネント（例えば、サーバ、オペレーティングシステム、ＣＰＵ、アプリケーションソフトウェア、メモリ、ネットワークデバイス、記憶装置など）の能力ニーズを解析することができる。不変式と呼ばれるこのような測定値間の関係は、経時的に変化することはない。これらの測定値から、不変式のネットワークが決定される。不変式のネットワークは、測定値間の関係を特徴づける。分散システムにおける少なくとも１つのコンポーネントについての能力ニーズをこの不変式のネットワークから決定することができる。
2010507146.tif 000002
【特許請求の範囲】
【請求項１】
分散システムにおける少なくとも１つのコンポーネントについての能力ニーズを決定する方法であって、
収集された複数の測定値から、前記測定値間の関係を特徴づける不変式のネットワークを決定すること、
前記不変式のネットワークから前記少なくとも１つのコンポーネントについての能力ニーズを決定すること、
を含む方法。
【請求項２】
前記少なくとも１つのコンポーネントの前記能力ニーズを現在のコンポーネントの割り当てと比較することにより、前記分散システムにおけるコンポーネントの使用を最適化することをさらに含む、請求項１に記載の方法。
【請求項３】
前記少なくとも１つのコンポーネントは、オペレーティングシステム、アプリケーションソフトウェア、中央処理装置（ＣＰＵ）、メモリ、サーバ、ネットワークデバイス及び記憶装置のうちの少なくとも１つをさらに含む、請求項１に記載の方法。
【請求項４】
前記分散システムの種々のコンポーネントから前記複数の測定値を収集することをさらに含む、請求項１に記載の方法。
【請求項５】
前記測定値はフロー強度測定値である、請求項１に記載の方法。
【請求項６】
前記複数の測定値から自動的に不変式を抽出することをさらに含む、請求項１に記載の方法。
【請求項７】
前記自動的に不変式を抽出することは、前記複数の測定値の中の少なくとも２つの測定値からモデルを生成することをさらに含む、請求項６に記載の方法。
【請求項８】
前記モデルが前記測定値にどの程度近似しているかをテストすることにより、前記モデルの適合スコアを計算することをさらに含む、請求項７に記載の方法。
【請求項９】
前記適合スコアがしきい値未満である場合に、可能性のある不変式としての前記モデルを削除することをさらに含む、請求項８に記載の方法。
【請求項１０】
前記モデルは外部入力付自己回帰モデル（ＡＲＸ）である、請求項７に記載の方法。
【請求項１１】
前記不変式のネットワークにおける各経路の信頼度スコアを計算することをさらに含む、請求項１に記載の方法。
【請求項１２】
分散システムにおける少なくとも１つのコンポーネントについての能力ニーズを決定する装置であって、
収集された複数の測定値から、前記測定値間の関係を特徴づける不変式のネットワークを決定する手段と、
前記不変式のネットワークから前記少なくとも１つのコンポーネントについての能力ニーズを決定する手段と、
を有する装置。
【請求項１３】
前記少なくとも１つのコンポーネントの前記能力ニーズを現在のコンポーネントの割り当てと比較することにより、前記分散システムにおけるコンポーネントの使用を最適化する手段をさらに有する、請求項１２に記載の装置。
【請求項１４】
前記少なくとも１つのコンポーネントは、オペレーティングシステム、アプリケーションソフトウェア、中央処理装置（ＣＰＵ）、メモリ、サーバ、ネットワークデバイス及び記憶装置のうちの少なくとも１つをさらに含む、請求項１２に記載の装置。
【請求項１５】
前記分散システムの種々のコンポーネントから前記複数の測定値を収集する手段をさらに有する、請求項１２に記載の装置。
【請求項１６】
前記複数の測定値から自動的に不変式を抽出する手段をさらに有する、請求項１２に記載の装置。
【請求項１７】
前記複数の測定値の中の少なくとも２つの測定値からモデルを生成する手段をさらに有する、請求項１６に記載の装置。
【請求項１８】
前記モデルが前記測定値にどの程度近似しているかをテストすることにより、前記モデルの適合スコアを計算する手段をさらに有する、請求項１７に記載の装置。
【請求項１９】
前記適合スコアがしきい値未満である場合に、可能性のある不変式としての前記モデルを削除する手段をさらに有する、請求項１８に記載の装置。
【請求項２０】
前記不変式のネットワークにおける各経路の信頼度スコアを計算する手段をさらに有する、請求項１２に記載の装置。
【請求項２１】
プロセッサで実行可能なコンピュータプログラム命令を有するコンピュータ可読媒体であって、前記コンピュータプログラム命令は、
分散システムから収集された複数の測定値から、該測定値間の関係を特徴づける不変式のネットワークを決定するステップと、
前記不変式のネットワークから、前記分散システムの少なくとも１つのコンポーネントの能力ニーズを決定するステップと、
を規定する、コンピュータ可読媒体。
【請求項２２】
前記少なくとも１つのコンポーネントの前記能力ニーズを現在のコンポーネントの割り当てと比較することにより、前記分散システムにおけるコンポーネントの使用を最適化するステップを規定するコンピュータプログラム命令をさらに含む、請求項２１に記載のコンピュータ可読媒体。
【請求項２３】
前記少なくとも１つのコンポーネントは、オペレーティングシステム、アプリケーションソフトウェア、中央処理装置（ＣＰＵ）、メモリ、サーバ、ネットワークデバイス及び記憶装置のうちの少なくとも１つをさらに含む、請求項２１に記載のコンピュータ可読媒体。
【請求項２４】
前記分散システムの種々のコンポーネントから前記複数の測定値を収集するステップを規定するコンピュータプログラム命令をさらに含む、請求項２１に記載のコンピュータ可読媒体。
【請求項２５】
前記複数の測定値から自動的に不変式を抽出するステップを規定するコンピュータプログラム命令をさらに含む、請求項２１に記載のコンピュータ可読媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、概して、分散システム(distributed system)に関し、特に、分散システムにおける能力計画(capacity planning)及びリソース最適化(resource optimization)に関する。
【背景技術】
【０００２】
インターネット上に拠点を有する会社は、一般に、ユーザが閲覧し、トランザクションを実行するための単一のウェブサイトを備えている。ユーザには単一のウェブサイトが見えるだけかもしれないが、通常は、大規模な分散システムが、そのウェブサイトによって提供されるサービスを実行している。大規模な分散システムとは、サーバ、オペレーティングシステム、中央処理装置（ＣＰＵ；central processing unit）、メモリ、アプリケーションソフトウェア、ネットワークデバイス及び記憶装置のような複数（例えば、何千もの）のコンポーネントを含んだシステムである。これらの大規模な分散システムは、多くの場合、大量のトランザクション要求を同時に処理することができる。例えば、大きなインターネット検索サイトは数千もののサーバを備えて、毎日、数百万ものユーザクエリを処理している。
【０００３】
顧客は、オンライントランザクションサービスに対し、短い待ち時間（レイテンシ）及び高い可用性のような高いサービス品質（ＱｏＳ；quality of service）を期待している。顧客は、信頼度の低いサービスによってまたは応答時間の数秒の遅延によってすら、容易に不満を抱く可能性がある。ユーザ負荷及び挙動のダイナミクス及び不確定性の結果として、分散システムのいくつかのコンポーネントが性能上のボトルネックになり、システムのＱｏＳを低下させることもあり得る。これらの問題は、一般的に、分散システムにおける１または２以上のコンポーネントに対する不十分な能力計画が招く結果である。したがって、任意のユーザ負荷に対するシステムの許容可能なＱｏＳを維持するために、各コンポーネントの正確な能力計画を行うことが望ましい。
【０００４】
能力計画とリソース（すなわちコンポーネント）最適化とは、しばしば、釣り合いをとるようなものである。一方では、十分なハードウェアリソースが、顧客のＱｏＳに対する期待を満たすように配置されなければならない。他方、特大の(oversized)スケーラブルなシステムは、ハードウェアリソースを浪費し、情報技術（ＩＴ；information technology）コストを増加させ、利益を減少させることもあり得るであろう。分散システムでは、一般に、分散配置された複数のコンポーネント全体にわたってリソースのバランスをとり、システムレベルでの最大の能力を達成することが重要である。さもないと、コンポーネントの能力の不整合がシステムのいくつかのセグメントで性能ボトルネックを招く一方、他のセグメントではリソースの浪費を招き得る。このように、分散システムにおいて個々のコンポーネントについての能力ニーズ（能力に対する要求；capacity needs）を正確かつ系統的に解析することは一般に難しい。
【０００５】
一般に、設計者らは、分散システムのコンポーネントの能力を設計する間に、多くの手順を実行する。これらの手順は、しばしば、分散システムでのコンポーネントの能力を整合させる試行錯誤の戦略の結果である。設計者らは、通常、自らの直観、実際的経験、または経験則に基づいて、リソースを割り当てる。例えば設計者らは、ウェブページに関連付けられたユーザトランザクションを処理する分散システムの一部として、１０台のサーバを設けることができる。このサーバを１０台設置しようとする判断は、類似の形態のウェブページにおける以前の経験に基づいていてもよい。ウェブページがクラッシュしあるいは多数のユーザ要求を処理できない場合には、システムは過負荷になりやすく、ユーザが不満を抱くことになるであろう。設計者らは、システムに１台の追加のサーバを付加し、それが上記の問題を解決するかどうかを確かめることにより、後追いでこの問題に対処することもできる。設計者らは、問題が解決されるまで、追加のサーバを付加し続けてもよい。さらなるクラッシュはユーザを一層苛立たせるであろう。また、最初のサーバ１０台中の１台のサーバが過負荷になる可能性があるので（例えば、データベースサーバは、多数のユーザ要求に関連付けられた多数のデータベース読み取り値を処理できない可能性がある）、その１台のサーバが問題の原因であるかもしれず、システム全体に対して追加のサーバを加えることが実際にはリソースを浪費しているにすぎない可能性もある。
【０００６】
したがって、分散システムにおける個々のコンポーネントの能力のニーズを系統的かつ正確に解析する必要性が依然として存在する。
【先行技術文献】
【特許文献】
【０００７】
【特許文献１】ＵＳ  ２００７／０１７９７４６号公報
【特許文献２】ＵＳ  ２００８／００２７６８８号公報
【発明の概要】
【発明が解決しようとする課題】
【０００８】
分散システムのコンポーネントの能力ニーズは、一般に、サービスを要求するユーザの数に依存している。経時的に顧客数が変化する場合には（例えば、ユーザ数は、ホリデーシーズンの商戦期間中により多くなる）、能力計画を定期的にやり直して、新規のユーザニーズに適合するようにシステム能力をアップグレードする必要がある。
【課題を解決するための手段】
【０００９】
本発明の例示実施形態によれば、分散システム内の個々のコンポーネント（例えば、サーバ、オペレーティングシステム、ＣＰＵ、アプリケーションソフトウェア、メモリ、ネットワークデバイス、記憶装置など）の能力ニーズは、分散システムから収集された測定値間の関係を用いて解析される。不変式(invariants)と呼ばれるこのような測定値間の関係は、経時的に変化することはない。これらの測定値から、不変式のネットワークが決定される。不変式のネットワークは測定値間の関係を特徴づける。分散システムにおけるコンポーネントの能力ニーズは、不変式のネットワークから決定される。
【００１０】
一例示実施形態では、システムでのコンポーネントの使用は、コンポーネントの推定された能力ニーズを現在のコンポーネントの割り当てと比較することにより、最適化される。
【００１１】
一例示実施形態では、測定値は、フロー強度(flow intensity)測定値である。フロー強度は、それによって内部測定値がユーザ負荷の大きさに反応する強度である。次に、これらのフロー強度測定値から不変式を自動的に抽出することができる。この抽出は、複数のモデルを生成することを含んでいてもよい。ここで各モデルは、少なくとも２つの測定値から生成される。次に、モデルが測定値にどの程度近似しているかをテストすることにより、各モデルの適合スコア(fitness score)を計算することができる。モデルが所望するように機能しない場合（例えば、適合スコア未満である場合）には、このモデルを廃棄することができる。一例示実施形態では、次に、信頼度スコア(confidence score)が不変式のネットワークの各ノードに対して決定される。信頼度スコアは、不変式のロバスト性を測定するものであり、コンポーネントの能力ニーズを決定するのに使用することができる。いったんコンポーネントの能力ニーズが決定されると、システムのリソースを最適化することができる。
【００１２】
本発明のこれら及びその他の利点は、以下の詳細な説明及び添付の図面を参照することにより、当業者に明白になるであろう。
【図面の簡単な説明】
【００１３】
【図１】図１は、能力計画モジュールを有する分散システムと通信しているクライアントのブロック図である。
【図２】図２は、分散システム内のコンポーネントの能力要件を決定するために能力計画モジュールによって実行されるステップを説明する、ハイレベルでのフローチャートを示している。。
【図３】図３は、図１の分散システムのような３階層(three-tier)ウェブシステムから収集された、ＨＴＴＰ要求及びＳＱＬクエリの強度のグラフを示している。
【図４】図４は。本発明の例示実施形態による不変式のネットワークのブロック図を示している。
【図５Ａ】図５Ａは、不変式を抽出するために実行されるステップのさらなる詳細を説明するフローチャートを示している。
【図５Ｂ】図５Ｂは、不変式抽出アルゴリズムの擬似コードを示している。
【図６】図６は、不変式ネットワークのブロック図を示している。
【図７Ａ】図７Ａは、分散システムの１または２以上のコンポーネントの能力ニーズを決定するフローチャートを示している。
【図７Ｂ】図７Ｂは、分散システムの１または２以上のコンポーネントの能力ニーズを決定するアルゴリズムの擬似コードを示している。
【図８Ａ】図８Ａは、コンポーネントの能力ニーズに基づいてリソースを最適化するために実行されるステップを説明するフローチャートである。
【図８Ｂ】図８Ｂは、リソース最適化アルコリズムの擬似コードである。
【図９】図９は、オーバーシュートを有するシステム応答のグラフを示している。
【図１０】図１０は、本発明の例示実施形態に使用できるコンピュータシステムのハイレベルでのブロック図を示している。
【発明を実施するための形態】
【００１４】
スタンドアロンのソフトウェアに対しては、しばしば、ＣＰＵ周波数及び記憶容量のような、ソフトウェアを実行するシステムのハードウェア要件を特定する定数が用いられる。しかしながら、それらのシステム要件は主として外部要因すなわちユーザ負荷の大きさによって決まるので、オンラインサービスに対するそのような仕様値を得るのは困難である。本発明の例示実施形態によれば、定数ではなくモデルまたは関数が、分散システムの各コンポーネントの能力ニーズを解析するのに用いられる。従来、待ち行列モデルのようなモデルが性能モデリングに適用されているが、これらのモデルは、しばしば、種々の仮定の下で、限られた数のコンポーネントを解析するのに使用される（例えば、待ち行列モデルでは、作業負荷(workload)はポアソン分布のような特定の分布に従い、かつ定常でなければならない、というようないくつかの仮定がある）。このような仮定は、分散システムにおけるコンポーネントについての能力ニーズを決定する場合には用いることができない。
【００１５】
動作中、分散システムは、伝統的には、大量の監視データを生成して、それらの動作ステータスを追跡する。本発明の例示実施形態によれば、この監視データは分散システムの種々のコンポーネントから収集される。ＣＰＵ使用量、ネットワークトラフィック量及びＳＱＬクエリ数は、収集できる監視データの例である。
【００１６】
システム不変式及び能力計画：
大量のユーザ要求がシステム内の種々のコンポーネントを流れている間、リソース消費に関連する多くの測定値が、ユーザ負荷の強度にしたがって応答する。フロー強度とは、本明細書で用いているように、それによって内部測定値がユーザ負荷の大きさ（すなわち、数）に応答する強度を指している。次に、フロー強度間の恒常的関係がシステム全体にわたって種々の点（ポイント）で決定される。このような関係が経時的に種々の作業負荷の下で常に保持される場合、この関係をここでは分散システムの不変式(invariants)と呼ぶ。一例示実施形態では、コンピュータがこれらの不変式を自動的に検索し抽出する。多くの不変式を分散システムから抽出した後、任意の大きさのユーザ負荷が与えられると、その不変関係が順次適用され、個々のコンポーネントの能力ニーズを推定することができる。現在のリソースの割り当てを推定された能力ニーズと比較することにより、システム性能を低下させる可能性のある、システムの最弱ポイントの位置を見つけ、順位付けすることができる。操作者はこのような解析結果を使用してリソースの割り当てを最適化し、潜在的な性能ボトルネックを取り除くことができる。
【００１７】
図１は、ネットワーク１１５を介してウェブサーバ１１０と通信しているクライアント１０５の例示実施形態のブロック図を示している。例えば、クライアント１０５は、ウェブサーバ１１０によって提供されたウェブページを、ネットワーク１１５を介して閲覧しているかもしれない。ウェブサーバ１１０は、アプリケーションサーバ１２０、データベースサーバ１２５及び１または２以上のデータベース（不図示）のような、１または２以上の他のサーバ及びコンポーネントとも通信している。これらのサーバ１１０，１２０，１２５は、ウェブページ及びこのウェブページに関連付けられたトランザクションを生成し管理するのに使用される分散システム１３０を形成している。
【００１８】
１つのウェブサーバ１１０、１つのアプリケーションサーバ１２０及び１つのデータベースサーバ１２５により示しているが、任意の数のこれらのサーバ１１０，１２０，１２５が分散システム１３０に含まれていてもよい。分散システム１３０は、この分散システム１３０に必要とされるリソースを決定する能力計画モジュール１３５も含んでいる。能力計画モジュール１３５は、サーバ１１０，１２０，１２５のうちの１つのサーバの部分であってもよく、またはそれ自身のサーバ上で動作してもよい。
【００１９】
能力計画(capacity planning)は、図１に示した３階層システムだけでなく、他の多くの分散されたシステムにも適用することができる。このように、３階層システムは一般的な分散システムの例である。
【００２０】
図２は、分散システム１３０におけるコンポーネントの能力要件を決定する能力計画モジュール１３５によって実行されるステップを説明するハイレベルのフローチャートを示している。能力計画モジュール１３５は、ステップ２０５において、分散システム１３０の種々のコンポーネント（例えば、ウェブサーバ１１０及びアプリケーションサーバ１２０）からデータを収集する。特に、分散システム１３０は、典型的には、ログファイルのような大量の監視データを生成して、それらの動作ステータスを追跡する。
【００２１】
ステップ２１０において、能力計画モジュール１３５は、収集されたデータからフロー強度測定値を決定する。オンラインサービスについては、大量のユーザ要求が種々のコンポーネントのアプリケーションのロジックにしたがってそれらのコンポーネントを流れている間、多くの内部測定値がユーザ負荷の強度にしたがってそれに反応する。例えば、ネットワークトラフィック量及びＣＰＵ使用量は、通常、ユーザ要求の量にしたがって変化する。これは、特に、リソース消費に関連する測定値の多くに当てはまる。というのはそれらの測定値が主としてユーザ負荷の強度によって駆動されるからである。上述のように、ここでは、フロー強度を使用して、このような内部測定値がユーザ要求の量に反応する強度を測定する。例えば、（サンプリング単位ごとの）ＳＱＬクエリ数及び平均ＣＰＵ使用量は、このようなフロー強度測定値である。
【００２２】
一般に、強い相関関係がこれらのフロー強度測定値間に存在している。時間経過に対してこれらのフロー強度測定値をグラフによって表した場合、測定値は主として同一の外部要因すなわちユーザ要求の量に応答するので、これらのグラフは類似したものになるであろう。図３は、分散システム１３０のような３階層ウェブシステムから収集された、ＨＴＴＰ要求及びＳＱＬクエリの強度のグラフ３００，３０５をそれぞれ示している。グラフ３００及びグラフ３０５の曲線は互いに類似している。システム１３０のような分散システムは、これらの内部測定値間の関係に多くの制約を課している。そのような制約は、ハードウェア能力、アプリケーションソフトウェアのロジック、システムアーキテクチャ及び機能性のような多くの要因から生じ得るであろう。
【００２３】
例えばウェブシステムでは、特定のＨＴＴＰ要求ｘが常に２つの関連するＳＱＬクエリｙをもたらす場合、２つのＳＱＬクエリを生じさせる命令がシステムのアプリケーションソフトウェアに記述されているので、関数Ｉ(ｙ)＝２Ｉ(ｘ)は常に正確となるであろう。なおここで、Ｉ(ｘ)及びＩ(ｙ)はそれぞれ点ｘ及び点ｙで測定されたフロー強度を表すのに使用されていることに留意されたい。フロー強度Ｉ(ｘ)，Ｉ(ｙ)がユーザ負荷の変化にしたがってどれほど変化しようとも、上記の関係Ｉ(ｙ)＝２Ｉ(ｘ)は常に一定である。測定値間のこのような恒常的関係を、ここでは、基礎をなすシステム(underlying system)の不変式と呼ぶ。なお、関係Ｉ(ｙ)＝２Ｉ(ｘ)（ただし、測定値ではない）は不変式と考えられることに留意されたい。
【００２４】
ステップ２１５において、このような不変式が、分散システム１３０全体にわたる種々の位置で収集された複数の測定値から自動的に抽出される。これらの不変式は、種々のフロー強度測定値間の恒常的関係を特徴づけている。
【００２５】
次にステップ２２０において、不変式のネットワークが編成される。そのようなネットワークの例を図４に示している。このネットワークでは、各ノード（例えば、ノード４０４，４０８）は測定値を表し、一方、各エッジ（例えば、エッジ４１２）は、２つの関連付けられた測定値間の不変関係（例えば、ｙ＝ｆ(ｘ)）を表している。以下にさらに詳細に説明するように、不変式ネットワークを使用して、能力計画及びリソース最適化のサービスをプロファイリングすることができる。
【００２６】
不変式の有効性はユーザ負荷の変化による影響を受けないので、一例示実施形態では、ステップ２２５において、起点ノードとしてユーザ要求の量を選択し、不変式ネットワークのエッジを順次追跡して、分散システム内の種々のコンポーネントの能力ニーズを決定する。ユーザ要求の量（起点）を作業負荷の履歴及び傾向分析(trend analysis)に基づいて予測することができる。上記の例において、ＨＴＴＰ要求の予測数をＩ(ｘ1)とすると、不変関係Ｉ(ｙ)＝２Ｉ(ｘ)を用いて、結果的に発生するＳＱＬクエリ数が２Ｉ(ｘ1)であると結論付けることができる。
【００２７】
コンポーネントの能力ニーズは、これらのリソース消費に関連する測定値によって定量的に表される。例えば、ユーザ負荷が最大であるとした場合、サーバは、２つの１ＧＨｚのＣＰＵ、４ＧＢのメモリ、及び１００ＭＢ／秒のネットワーク帯域幅、等を有する必要があるであろう。これらの数値は、この負荷の下で予想されるＣＰＵ使用量及びメモリ使用量、及びネットワーク帯域幅からそれぞれ導き出すことができる。現在のリソースの割り当てを推定された能力ニーズと比較することによって、性能ボトルネックになる可能性がある最弱ポイントを見つけ出すことができる。このように、システムの種々のコンポーネントの能力ニーズを用いて、分散システムのリソースを最適化することができる（ステップ２３０）。したがって、任意の大きさのユーザ負荷が与えられると、操作者は、上記のような不変式のネットワークを使用して、種々のコンポーネントの能力ニーズを推定し、リソースの割り当て間のバランスをとり、潜在的な性能ボトルネックを取り除くことができる。
【００２８】
フロー強度の相関関係：
システムにまたがって種々の点で測定されたフロー強度を用いて、これらの測定値間の関係をモデル化することが重要である。すなわち、測定値ｘ，ｙを用いて、ｙ＝ｆ(ｘ)を与える関数ｆを決定することが重要である。上述のように、リソース消費に関連する測定値の多くはユーザ要求の量にしたがって変化する。時系列として、これらの測定値は時間ｔに沿って類似の発展曲線(evolving curve)を描く傾向がある。したがって、測定値の多くは線形の関係を有すると仮定できる。一例示実施形態では、外部入力付自己回帰モデル（ＡＲＸ；autoregressive model with exogenous input）を用いて測定値間の線形関係を決定する。
【００２９】
時刻ｔにおいて、コンポーネントの入力及び出力で測定されたフロー強度は、それぞれ、ｘ(ｔ)及びｙ(ｔ)によって表される。ＡＲＸモデルでは２つのフロー強度間の以下の関係を記述している。
【００３０】
【数１】
2010507146.tif 000003
【００３１】
ここで、［ｎ，ｍ，ｋ］はモデルの次数であり、このモデルは、先行する何個のステップが現在の出力に影響を及ぼしているかどうかを判断する。ａi及びｂjは、先行するステップがどれくらい強く現在の出力に影響を及ぼしているかを反映する係数パラメータである。以下のように表わすこととする。
【００３２】
【数２】
2010507146.tif 000004
【００３３】
すると、式(1)は次のように書き換えることができる。
【００３４】
【数３】
2010507146.tif 000005
【００３５】
２つの測定値が時間期間１≦ｔ≦Ｎにわたって観測されていると仮定して、この観測を以下のように表すこととする。
【００３６】
【数４】
2010507146.tif 000006
【００３７】
所与のθについて、観測された入力ｘ(ｔ)を用いて、式(1)にしたがってシミュレートされた出力
【００３８】
【数５】
2010507146.tif 000007
【００３９】
を計算することができる。したがって、シミュレートされた出力を観測された出力と比較して、以下の式によって推定誤差をさらに定義することができる。
【００４０】
【数６】
2010507146.tif 000008
【００４１】
最小二乗法（ＬＳＭ；Least Squares Method）により、推定誤差ＥN(θ，ＯN)を最小化する次の
【００４２】
【数７】
2010507146.tif 000009
【００４３】
を以下のように見つけることができる。
【００４４】
【数８】
2010507146.tif 000010
【００４５】
決定されたモデルが真の観測値にどの程度よく適合しているかを評価する基準がいくつかある。一例示実施形態では、以下の式を用いて、モデル検証に対する正規化適合スコアを計算する。
【００４６】
【数９】
2010507146.tif 000011
【００４７】
ここで、
【００４８】
【数１０】
2010507146.tif 000012
【００４９】
は実出力ｙ(ｔ)の平均値である。式(8)は、メトリックを導入して、決定されたモデルが実データにどの程度よく近似しているかを評価する。より高い適合スコアは、モデルが観測されたデータにより良く適合することを示し、その上限は１である。２つのフロー強度の観測値が与えられると、たとえこのモデルがそれらの真の関係を反映していなくても、式(7)を用いてモデルを決定することができる。したがって、高い適合スコアを有するモデルは、データの関係を特徴づける点で、意味がある。定数ではなく、一連の次数［ｎ，ｍ，ｋ］を設定して、モデル候補のリストを決定することができる。その後、最も高い適合スコアを持つモデルを選択することができる。最小記述長（ＭＤＬ；minimum description length）のような他の基準もモデルを選択するのに使用することができる。なお、ＡＲＸモデルを用いて２つの測定値間の長期にわたる関係を決定できること、すなわち、モデルｙ＝ｆ(ｘ)がそれらの関係の主な特徴を捉えることに留意されたい。２つの測定値間の正確な関係は、ｙ＝ｆ(ｘ)＋εで表すことができ、ここで、εはモデル化誤差である。なお、高い適合スコアを有するモデルについては、通常の場合、εは小さいことに留意されたい。
【００５０】
不変式の抽出：
上記の説明は、２つの測定値が与えられた場合に自動的にモデルを決定する方法を示している。実際、リソース消費に関連する多くの測定値を複合システムから収集することができるが、それら測定値の対には線形関係はなくてもよい。システムのダイナミクス及び不確定性により、決定されたモデルの中には経時的にはロバストではないものがある可能性がある。
【００５１】
図２のステップ２１５に関するさらなる詳細において及び一例示実施形態では、多数の測定値から不変式を抽出するために、いくつかの関係を事前のシステム知識から構築することができる。他の例示実施形態では、測定値から不変式を自動的に検索し抽出するアルゴリズムを用いることができる。
【００５２】
なお、能力計画の目的のために、リソース消費に関連する測定値の中から不変式が検索されることに留意されたい。Ｉi（１≦ｉ≦ｍ）によって表されるｍ個の測定値を仮定する。一例示実施形態では、総当たり検索を行って、まず不変式のすべての仮説を構築し（これらの仮説を検証するのに十分な運用システムからの監視データがあるので）、次に、動作中に、順次、これらの仮説の有効性をテストする。式(8)によって与えられる適合スコアＦk(θ)を用いて、決定されたモデルがｋ番目の時間窓中に観測されたデータとどの程度適合するかを評価することができる。この窓の長さはｌによって表される。すなわち各窓は、測定値のｌ個のサンプリング点を含んでいる。上述のように、２つの測定値が与えられると、式(7)を用いてモデルを決定することもできる。しかしながら、低い適合スコアを有するモデルはあまり良好には実データの関係を特徴づけないので、しきい値
【００５３】
【数１１】
2010507146.tif 000013
【００５４】
を選択して、順次のテストにおいてそのようなモデルをフィルタリング除去する。Ｍkによって、時刻ｔ＝ｋ・ｌ（すなわち、ｋ個の時間窓の後）における有効モデルの集合を表す。順次のテスト中、いったん
【００５５】
【数１２】
2010507146.tif 000014
【００５６】
になると、このモデルのテストは中止され、それはＭkから取り除かれる。
【００５７】
このようなｋ個の窓の監視データ（すなわち、全部でｋ・ｌ個のサンプリング点）を受け取った後、信頼度スコアを以下の式を用いて計算することができる。
【００５８】
【数１３】
2010507146.tif 000015
【００５９】
事実、ｐk(θ)は、ｋ個の時間窓に対する平均的な適合スコアである。集合Ｍkは有効モデルしか含んでいないので、
【００６０】
【数１４】
2010507146.tif 000016
【００６１】
を得る。
【００６２】
図５Ａは、（図２のステップ２１５に関して最初に上で説明したように）不変式を抽出するアルゴリズムのさらなる詳細を説明するフローチャートを示している。能力計画モジュール１３５は、ステップ５０５において、分散システム１３０の種々のコンポーネントから測定値を得る。一例示実施形態では、能力計画モジュール１３５は、定期的に測定値を得る。あるいは能力計画モジュール１３５は、所定期間が経過した後の測定値を取得してもよいし、設定された回数だけ測定値を取得してもよいし、アクションまたはイベントが生じた後に測定値を取得してもよい。能力計画モジュール１３５は、次にステップ５１０において、取得された測定値から２つずつ測定値を選択する。一例示実施形態では、この選択は無作為抽出である。他の例示実施形態では、選択は前もって決められている（例えば、まず第１及び第２の測定値を選択し、次に第１及び第３の測定値を選択するなど。これは総当たり検索なので、２つの測定値の対ごとにモデルを学習する）。ステップ５１５において、能力計画モジュール１３５は選択された測定値のモデルを構築し、次にステップ５２０において、新しい観測値を用いてモデルを評価する。適合スコアも、ステップ５２０においてモデルに対して計算される。次にステップ５２５において、適合スコアがしきい値より大きいかどうかが判断される。大きくなければ、そのモデルはステップ５２８において廃棄される。適合スコアがステップ５２５においてしきい値より大きい場合、モデルに対して長期にわたりさらなるテストが行われ、ステップ５３０において、そのモデルが不変関係を記述するかどうかを判断する。例えば、さらなるテストを設定されたデータ点の数または設定期間に対して行うことができる。
【００６３】
図５Ｂは、図５Ａの不変式抽出アルゴリズムの例示実施形態を説明する擬似コード(pseudo code)５５０を示している。上述のようにアルゴリズム５５０は、ブロック５６０において、（上の式(7)を用いて）任意の２つの測定値のモデルを決定し、次に、新しい観測値を用いてこれらのモデルを増分的(incrementally)に検証する。各ステップでは、各モデルを評価して、各モデルが新しい時間窓の間に収集された監視データにどの程度適合するかを判断する。モデルの適合スコアがしきい値より低い場合、このモデルは、さらなるテストを受けなければならない不変式の候補の集合から取り除かれる（ブロック５７０）。
【００６４】
一例示実施形態では、アルゴリズム５５０を用いて抽出された不変式は、可能性のある不変式であると考えられる。上述のように、モデルが経時的に不変のままである場合に、そのモデルを基礎をなすシステムの不変式と見なすことができる。しかしながら、たとえモデルの有効性が長い間（例えば、数日のような所定量の時間）にわたって順次にテストされたとしても、これはこのモデルが常に有効であるということを保証しているわけではない。したがって、可能性のある不変式としてこれらの有効モデルを考える方が、より正確である。各信頼度スコアｐk(θ)は、監視データの履歴に基づいて、不変式のロバスト性を評価することができる。なお、２つの測定値が与えられた場合、複合システムにおいてどの測定値が入力または出力（すなわち、式(1)のｘまたはｙ）として選ばれるべきかということは、論理的には不明であることに留意されたい。したがって一例示実施形態では、逆の入力及び出力を有する２つのモデルが構築される。２つの決定されたモデルが異なる適合スコアを有する場合、ＡＲＸモデルでなくＡＲ（Auto Regressive：自己回帰）モデルが構築された。２つの測定値間の強い相関関係が興味の対象であるので、それらのＡＲモデルは、両方のモデルの適合スコアにしきい値を越えるように要求することにより、フィルタリング除去される。したがって、一例示実施形態では、２つの測定値間の不変関係は双方向である。
【００６５】
フロー強度及び不変式の抽出のさらなる詳細は、"Automated Modeling and Tracking of Transaction Flow Dynamics for Fault Detection in Complex Systems"と題する米国特許出願第11/275,796号（US 2007/0179746号公報）、及び"Method and System for Modeling Likely Invariants in Distributed Systems"と題する米国特許出願第11/685,805号（US 2008/0027688号公報）に説明されており、その両方は参照によりここに組み込まれている。
【００６６】
能力ニーズの推定：
上述のように、アルゴリズム５５０は、測定値Ｉi（１≦ｉ≦ｍ）の中から可能性のある不変式を自動的に検索し、抽出する。さらに、これらの測定値及び不変式は、体系的にサービスをプロファイリングするモデルとして使用可能な関係ネットワークを編成する。少量のユーザ要求の下では、システムのサービス品質がクライアントの期待を満たしている場合には、不変式のネットワークがそのシステムから決定される。したがって、一例示実施形態では、システムが所定の状態であるときには、そのシステムをプロファイリングすることができる。リソース消費に関連する測定値がシステム１３０から１０個（すなわち、ｍ＝１０）収集され、さらに図６に示すように、アルゴリズム５５０がこれらの測定値から不変式ネットワーク６００を抽出すると仮定する。このネットワーク６００で、数ｉを付された各ノード（例えば、ノード６０５）は測定値Ｉを表し、各エッジ（例えば、エッジ６１０）は、（例えば、ノード６０５，６１５によって表された）２つの関連付けられた測定値間の不変関係を表している。
【００６７】
しきい値
【００６８】
【数１５】
2010507146.tif 000017
【００６９】
を用いて上記の低い適合スコアを有するモデルをフィルタリング除去できる場合、測定値対の中には不変関係を持たないものもある。例えば、切断された２つのサブネットワーク、及びノード１  ６２０のような分離されたノードが存在する。分離されたノードは、この測定値が他の測定値とはいかなる線形関係にもないことを示唆している。２つのモデルが２つの測定値間で（逆の入力及び出力を有して）構築されるので、エッジは双方向である。
【００７０】
３の測定値｛Ｉ10，Ｉ3，Ｉ4｝間の三角関係を考える。Ｉ3＝ｆ(Ｉ10)，Ｉ4＝ｇ(Ｉ3)と仮定する。ここで、ｆ及びｇはいずれも式(1)で示すような一次関数である。三角関係に基づいて、Ｉ4＝ｇ(Ｉ3)＝ｇ(ｆ(Ｉ10))を決定することができる。関数ｆ，ｇの線形特性によると、関数ｇ(ｆ(・))も線形のはずであり、これは測定値Ｉ10とＩ4との間に不変関係が必ず存在することを示唆している。しきい値を用いてそれらの低い適合スコアを有するモデルをフィルタリング除去するので、そのような線形関係は、モデル化誤差により、不変式と考えられるほどにはロバストではないかもしれない。これは、エッジがＩ10とＩ4との間にない理由を説明している。
【００７１】
上述のように、不変式は、測定値間での長期にわたって一定である関係を特徴づけており、それらの有効性は、基礎をなすシステムが正常に動作する場合、長期にわたるユーザ負荷のダイナミクスによって影響を受けることはない。各不変式がその関連付けられた測定値間のいくつかの局所的関係をモデル化する一方、不変式のネットワークは、分散システム全体の根底にある多くの不変制約を捉えることができる。１またはいくつかの解析モデルを用いてサービスをプロファイリングするのではなく、多くの不変式のモデルを組み合わせてネットワークを構築し、能力ニーズを解析し、リソースの割り当ての最適化を行う。実際、傾向分析または他の統計的方法を用いて、ユーザ要求の量を予測することもできる。
【００７２】
時刻ｔ（例えば、１か月またはセールス期間中）において、ユーザ要求の最大量がｘまで増加すると予測されるものとする。図６において、（ノード６２５によって表された）測定値Ｉ10がユーザ要求の量を表すのに使用される。すなわち、Ｉ10＝ｘである。
【００７３】
ネットワーク６００内の他のノードの能力は、この量のユーザ要求をサービスするようにアップグレードされる。なお、システムコンポーネントの能力ニーズは、リソース消費に関連した測定値により、定量的に特定されることに留意されたい。例えば、ネットワークの帯域幅（ビット／秒）を用いて、ネットワークの能力を特定することができる。
【００７４】
ノード６２５（すなわち、Ｉ10＝ｘ）から始まり、次にエッジ（例えば、エッジ６３０）が続いて、不変式ネットワーク６００内の他のノードの能力ニーズを推定する。１回のホップ(hop)でノード｛Ｉ3，Ｉ5，Ｉ7｝に到達することができる。Ｉ10＝ｘとすると、問題なのは、いかにして不変式を追ってこれらの測定値を推定するかである。上述のように、一例示実施形態では、式(1)で示されるモデルを用いて測定値間の不変関係を検索するので、すべての不変式をこのモデルテンプレートのインスタンスと考えることができる。モデルの線形特性によれば、ユーザ負荷の量が増加するにつれて、システムコンポーネントの能力ニーズは単調に増加する。したがって、一例示実施形態では、ユーザ負荷は上下に不規則に変化するが、能力解析ではユーザ負荷の最大量が使用される。ここで、ｘはＩ10の最大値を表すのに使用される。式(1)において、入力ｘ(ｔ)がすべての時間ステップでｘに設定される場合、出力ｙ(ｔ)は、定数値ｙ(ｔ)＝ｙに収束すると予想され、ここで、ｙは以下の式から導き出すことができる。
【００７５】
【数１６】
2010507146.tif 000018
【００７６】
一例示実施形態では、ｆ(θij)はＩiからＩjへの伝播関数(propagation function)、すなわち
【００７７】
【数１７】
2010507146.tif 000019
【００７８】
を表すのに使用され、ここで式(2)に示すように、すべての係数パラメータはベクトルθijからのものである。
【００７９】
入力ｘが与えられると、式(10)に基づいて、出力ｙを不変式の係数パラメータによって一意に決定することができる。不変式の線形特性によれば、ｘが入力の最大値の場合、ｙは出力測定値の最大値となる。したがって、入力測定値の値が与えられると、式(10)を使用して出力測定値の値を推定することができる。例えば、Ｉ10＝ｘが与えられると、不変式を使用してＩ3，Ｉ5，Ｉ7の値を導き出すことができる。これらの測定値は他の不変式への入力であるので、それらの値をノードＩ4，Ｉ6のようなネットワーク内の他のノードに対して同様に伝播させることができる。
【００８０】
図６に示すように、Ｉ4，Ｉ7のようないくつかのノードは、複数の経路を通って起点ノードＩ10から到達することができる。同一の２つのノード間では、複数の経路は異なる数のエッジを含んでいてもよく、各不変式（エッジ）も、２つのノードの関係をモデル化する際に質が異なっていてもよい。したがって、ノードの能力ニーズは異なる精度を有して異なる経路を通して推定することができる。各ノードについて、問題なのは、ユーザ負荷の量を起点ノードから伝播させるための最良の経路の位置をどのように見つけかである。一例示実施形態では、最短経路（すなわち、最小ホップ数を有する）が、この値を伝播するために選ばれる。上述のように、各不変式は、２つの測定値間の関係を特徴づけるとき、いくばくかのモデル化誤差εを含んでいてもよい。これらのモデル化誤差は経路に沿って累積する場合があり、より長い経路は、通常、より大きな推定誤差をもたらすことになる。信頼度スコアｐk(θ)を使用して不変式のロバスト性を評価することができる。信頼度スコアの定義によれば、より高い適合スコアを有する不変式は、能力推定におけるより高い精度をもたらすことができる。一例示実施形態では、ｐijが測定値ＩiとＩjとの間のｐk(θ)を表すのに使用され、ＩiとＩjとの間に関係がない場合、ｐijは０に設定される。特定の経路ｓが与えられると、累積されたスコア
【００８１】
【数１８】
2010507146.tif 000020
【００８２】
を導き出して、この経路全体の精度を評価することができる。したがって、同数のエッジを含む複数の経路については、最も高いスコアｑsを有する経路を選択して能力ニーズを推定する。
【００８３】
また、ノードの中には、起点ノードから到達可能でないものもある。しかしながら、ユーザ負荷に応答するための、類似してはいるが非線形または確率的なやり方があるかもしれないので、これらの測定値はなお他のノードの集合との線形関係を持つことができる。性能モデリングにおいて、待ち行列モデルのようなモデル（例えば、利用法則(utilization law)、サービス需要の法則(service demand law)、及び／または強制フローの法則(forced flow low)など法則にしたがうもの）が、個々のコンポーネントを特徴づけるのに開発されている。これらの法則及び古典的理論にしたがうと、非線形モデルまたは確率モデルを手動で構築して、切断されたサブネットワークにおける測定値（これらの測定値には式(1)に示すような線形関係はなくてもよいが）を接続することができる。他の例示実施形態では、境界解析(bound analysis)を使用して測定値間の大まかな関係を導き出す。したがって、一例示実施形態では、ユーザ負荷の量をこれらの分離されたノードに伝播することができる。
【００８４】
例えば、任意の２つのノードに対し、２つの切断されたサブネットワークから手動でブリッジを架けることができる場合、ユーザ負荷の量をさらにいくつかのホップにより伝播することができる。この場合でも、２つの切断されたサブネットワーク間のどこにブリッジを架ければよいかについてのガイダンスを提供することができるので、抽出された不変式ネットワークはなお有用であろう。例えば、システム依存性は局所的文脈においてより直接的であるので、通常、同一タイプの個々のコンポーネントから測定値間のモデルを構築する方が容易である。分散された複数のシステム全体にわたってモデルを構築するのではなく、いくつかの局所モデルを手動で構築して、切断されたサブネットワークを接続することができる。一例示実施形態では、このような複雑なモデルは、システム知識から、他のクラスの不変式であると考えられ、区別されない。
【００８５】
図２のステップ２２５に関するさらなる詳細において、図７Ａは、分散システム１３０の１または２以上のコンポーネントの能力ニーズを決定するフローチャートを示している。不変式のネットワークは、上述のように、抽出された不変式から取得される（ステップ７０５）。ステップ７１０において、起点ノードから不変式ネットワークの各ノードまでの最短経路が決定される。最短経路がいくつかある場合、ステップ７１５において、起点ノードを現在のノードに接続する経路ごとに信頼度スコアが決定され、ステップ７２０において、各ノード（すなわち、コンポーネント）の能力ニーズが、最も高い信頼度スコアを有する最良の経路によって決定される。特に、この最良の経路に沿って累積された関係（例えば、ｙ＝ｆ(ｘ)かつｘ＝ｇ(ｚ)ならばｙ＝ｇ(ｆ(ｚ))、ここで、ｚはここでの起点である）を用いて、所与の作業負荷下での能力ニーズを推定する。信頼度スコアは、経路の品質を判断することはできるが、一般的には、能力ニーズを計算することには使用することができない。経路に沿った関数を用いて能力ニーズの伝播を計算する。
【００８６】
図７Ｂは、分散システムの１または２以上のコンポーネントの能力ニーズを決定するアルゴリズム７５０の擬似コードを示している。図７Ｂのアルゴリズムは、図７Ａで示したステップの擬似コードである。以下の変数がアルゴリズム７５０に対して定義される。
【００８７】
Ｉi：個々の測定値であって、１≦ｉ≦Ｎ；
Ｕ：すべての測定値の集合、すなわち、Ｕ＝Ｉi；
Ｍ：すべての不変式の集合、すなわち、Ｍ＝｛θij｝であり、ここでθijは測定値ＩiとＩjとの間の不変式モデルである；
ｐij：モデルθijの信頼度スコア。なお、測定値ＩiとＩjとの間に不変式（エッジ）がない場合、ｐij＝０であることに留意されたい；
Ｐ：すべての信頼度スコアの集合、すなわちＰ＝｛ｐij｝；
ｘ：ユーザ負荷の予測された最大量；
Ｉ1：不変式ネットワークの起点ノード、すなわちＩ1＝ｘ；
Ｓk：Ｉ1からのｋ番目のホップでのみ到達可能であってそれ以前のホップでは到達できないノードの集合；
Ｖk：ｋ番目のホップまででアクセスされたすべてのノードの集合；
Ｒ：Ｉiから到達可能なすべてのノードの集合；
φ：空集合；
ｆ(θij)：ＩiからＩjへの伝播関数；
ｑs：起点ノードＩ1からＩsまでの最良の経路の最大累積信頼度スコア。
【００８８】
図５に関して上述したように、アルゴリズム５５０は、順次のテスト段階ののちに、自動的に、ロバストな不変式を抽出する。図７Ｂに示すように、アルゴリズム７５０は、Ｍ及びＰによって特定された抽出された不変式ネットワークをたどって能力ニーズを推定する。起点ノードから他のノードへと伝播する最短経路を選ぶことができるので、アルゴリズム７５０は、各ステップにおいて、さらなる伝播のために、これまでアクセスされていないノードだけを検索する。これは、このステップの以前に既にアクセスされたすべてのノードは既に起点ノードへのそれぞれの最短経路を有しているからである。さらに、これらの新しくアクセスされたノードだけをいくつかのアクセスされていないノードに接続することができるので、アルゴリズム７５０は、各ステップにおいて、これらの新しくアクセスされたノードを使用して、それらの次のホップを検索する。起点ノードへの同じ長さの複数の経路を有するノードについては、一例示実施形態では、最も高い累積信頼度スコアを有する最良の経路を選択して能力ニーズを推定する。このようにアルゴリズム７５０は、動的プログラミングに基づいたグラフアルゴリズムである。これらの新しくアクセスされたノードの能力ニーズは増分的に推定され、起点ノードから到達可能なノードがそれ以上見つからなくなるまで、それらの累積信頼度スコアが各ステップで計算される。
【００８９】
リソース最適化：
上述のように、アルゴリズム７５０は、所与の量のユーザ負荷によってもたらされるリソースの消費に関連する測定値を順次に推定する。これらの測定値をさらに用いて、分散システムにおけるそれらの関連するコンポーネントの能力ニーズを評価することができる。多数の（例えば、数千もの）サーバを備える大規模分散システムについては、一般的に、コンポーネントの能力を正確に計画し、リソースの割り当てを最適化することが重要事項である。ユーザ負荷のダイナミクス及び不確定性により、十分な能力を持たないシステムはシステム性能を低下させ、それによりユーザの不満を招くおそれがある。逆に、「過大能力の」システムは、リソースを浪費し、ＩＴコストを増加させる可能性がある。大規模な分散システムにおける１つの課題は、どのようにしてシステム内の種々のコンポーネントの能力を整合させて潜在的な性能ボトルネックを取り除き、システムレベルでの最大能力を達成するかである。システムコンポーネントの能力の不整合は、システムの１つのセグメントで性能ボトルネックをもたらし、他のセグメントではリソースを浪費をもたらす可能性がある。
【００９０】
分散システムの現在のリソース構造に関する情報が収集されたものとする。例えばこの情報は、システムが配置またはアップグレードされたときに記録されていてもよい。各測定値Ｉiについては、関連するリソース構造をＣiで表すことができる。一例示実施形態では、この構成情報は、データベース接続の最大数のようなソフトウェア構成だけでなく、メモリサイズのようなハードウェア仕様も含んでいる。ユーザ負荷の量ｘが与えられると、アルゴリズム７５０を使用してＩiの値を推定できる。ここで、すべての測定値Ｉi（１≦ｉ≦Ｎ）が起点ノードから到達可能であるものとする。測定値が起点ノードから到達可能でない場合、それらの到達不能な測定値は能力解析から取り除かれる、すなわち
【００９１】
【数１９】
2010507146.tif 000021
【００９２】
の場合、Ｉiを取り除く。ＩiをＣiと比較することによって、潜在的な性能ボトルネックに関する情報の位置を見つけ、リソースの割り当てのバランスをとることができる。
【００９３】
図８Ａは図２のステップ２３０のさらなる詳細を示し、コンポーネントの能力ニーズに基づいてリソースを最適化するために行われるステップを説明するフローチャートである。上述（図７Ａ及び図７Ｂ）のように、不変式のネットワークを使用して、所与のユーザ負荷に対するシステムのコンポーネントの能力ニーズを決定する（ステップ８０５）。能力計画モジュール１３５は、次にステップ８１０において、所与のユーザ負荷に対する能力がコンポーネントにおいて不足しているかどうかを判断する。コンポーネントにおいて所与のユーザ負荷に対する能力が不足している場合、ステップ８１５において、追加リソースをコンポーネントに割り当てて性能ボトルネックを取り除くことができる。
【００９４】
ステップ８１０において所与のユーザ負荷に対する能力がコンポーネントに不足していない場合、ステップ８２０において、所与のユーザ負荷に対してコンポーネントが過大な能力をもっていないかどうかが判断される。能力が過剰でない場合、コンポーネントの能力は調整されない（ステップ８２５）。能力が過剰な場合、ステップ８３０においていくつかのリソースがコンポーネントから取り除かれる。
【００９５】
図８Ｂは、本発明の例示実施形態に基づくリソース最適化アルコリズム８５０を示す擬似コードである。アルゴリズム８５０では、
【００９６】
【数２０】
2010507146.tif 000022
【００９７】
であり、ここでＯiはリソース不足または利用可能なマージンの割合を表している。ユーザ負荷の量が与えられた場合、負のＯiを有するコンポーネントは能力が不足しているので、より多くのリソースを割り当てて性能ボトルネックを取り除くことができる。逆に、正のＯiを持つコンポーネントについては、そのコンポーネントは、上記のユーザ負荷の量をサービスするには過剰な能力を有するので、いくつかのリソースをこれらのコンポーネントから取り除いてＩＴコストを下げることができる。アルゴリズム８５０において、Ｏiの値は、リソースの割り当て及び最適化の優先順位をリストアップするためにソートされる。
【００９８】
なお、最大量のユーザ負荷ｘが、能力ニーズを推定するために、不変式ネットワークを通して伝播されることに留意されたい。アルゴリズム７５０から生じるＩiはすべて、この最大量のユーザ負荷をサービスする種々のコンポーネントの能力ニーズを表している。ステップ入力ｘ(ｔ)＝ｘが与えられると、その安定出力ｙ(ｔ)＝ｙが式(10)を用いて導き出される。しかしながら、安定値ｙに収束する以前の、ｙ(ｔ)の過渡応答は考慮されていない。図９は、基準値ｙ  ９１０を上回るオーバーシュート９０５を有するシステム応答のグラフ９００を示している。図示のように、理論的には、ｙ(ｔ)はオーバーシュート９０５に応答する可能性があり、その過渡値は安定値ｙ  ９１０より大きいかもしれない。システムコンポーネントは、ユーザ負荷の急な変化に対してはあまり迅速に応答しないので、オーバーシュート９０５が発生する。例えば、３階層ウェブシステムでは、ユーザ負荷が突然増加すると、アプリケーションサーバはしばらくの時間をかけてより多くのエンタープライズジャバビーンズ（ＥＪＢ；Enterprise JavaBeans）のインスタンスを初期化し、より多くのデータベース接続を生成することかもしれない。このオーバーシュートの期間中には、ユーザ要求へのより長いレイテンシ（待ち時間）が観測されるだろう。
【００９９】
機械システムと異なってコンピューティングシステムは、多くの場合、ユーザ負荷のダイナミクスに迅速に応答する。したがってたとえオーバーシュートが存在していても、一般にはそれは短時間しか継続しない。多くのインスタンスでは、オーバーシュート応答を観測することはできない。一例示実施形態では、システムにオーバーシュートを処理するのに十分な能力があることを確保するために、オーバーシュートの量を計算することができ、安定値ｙでなくこれらのオーバーシュート値を伝播して能力ニーズを推定することができる。ｎ，ｍ≦２である低次のＡＲＸモデルについては、古典制御理論を用いてオーバーシュートを計算することができる。高次のＡＲＸモデルについては、入力ｘ(ｔ)＝ｘが与えられると、一例示実施形態では、過渡応答ｙ(ｔ)をシミュレートすることができ、式(1)を用いてオーバーシュートを推定することができる。アルゴリズム７５０の各ステップにおいて、関数ｆ(θij)を用いて安定値Ｉjを推定するのではなく、シミュレーション結果を用いて過渡的Ｉiを推定し、さらにオーバーシュート値を伝播して他のノードの能力ニーズを推定することができる。アルゴリズム７５０の他のすべての部分は同じままである。
【０１００】
コンピュータ実装：
本明細書での記載は、本発明の例示実施形態を実施するのに必要とされる処理ステップによって本発明を説明している。これらのステップは適切にプログラミングされたコンピュータによって実行することができ、そのコンピュータの構成は当技術分野においてよく知られている。適切なコンピュータは、例えば、よく知られているコンピュータプロセッサ、メモリ装置、記憶装置、コンピュータソフトウェア、及び他のモジュールを使用して実装されてもよい。このようなコンピュータのハイレベルでのブロック図を図１０に示している。コンピュータ１０００は、そのコンピュータ１０００の全体的動作を定義したコンピュータプログラム命令を実行することによって、そのような全体的動作を制御するプロセッサ１００４を含んでいる。コンピュータプログラム命令は記憶装置１００８（例えば、磁気ディスク）に格納されており、コンピュータプログラム命令の実行が所望される場合にメモリ１０１２にロードされることができる。コンピュータ１０００は、（例えば、ローカルにまたはネットワークを介して）他の装置と通信するための１または２以上のインタフェース１０１６も含んでいる。コンピュータ１０００は、そのコンピュータ１０００とのユーザの相互作用を可能にする装置を代表するＩ／Ｏ（入出力装置）１０２０（例えば、表示装置、キーボード、マウス、スピーカ、ボタン等）も含んでいる。コンピュータ１０００は、能力計画モジュールを表していてもよく、及び／または上述のアルゴリズムを実行してもよい。
【０１０１】
当業者は、実際のコンピュータの実装は他の要素も含んでおり、図１０は、例示のためにそのようなコンピュータの要素のいくつかをハイレベルに表現したものであることを認識するであろう。さらに当業者は、本明細書で説明した処理ステップも専用ハードウェアを使用して実装でき、その専用ハードウェアの回路を特にそのような処理ステップの実行用に構成できることを認識するであろう。あるいは、処理ステップはハードウェアとソフトウェアとの種々の組み合わせを使用して実装されてもよい。また、処理ステップはコンピュータで行われてもよいし、またはより大きいマシンの一部であってもよい。
【０１０２】
以上の「発明を実施するための形態」は、あらゆる面で例示的なものであって、限定するためのものではなく、本明細書に開示された発明の範囲は、「発明を実施するための形態」から決定されるものではなく、特許法によって認められる全幅にしたがって解釈されるように請求項から決定されるものであることは理解されるべきであろう。本明細書に示し説明した例示実施形態は、本発明の原理の例示にすぎず、種々の修正が当業者によって本発明の範囲及び精神から逸脱することなく実行されてもよいことは理解されるべきであろう。当業者は、本発明の範囲及び精神から逸脱することなく種々の他の特徴の組み合わせを実行することができるであろう。
【０１０３】
本出願は、2006年10月12日に出願された米国仮出願第60/829,186号の利益を主張し、それは参照によりここに組み込まれている。
【図１】
2010507146.tif 000023
【図２】
2010507146.tif 000024
【図３】
2010507146.tif 000025
【図４】
2010507146.tif 000026
【図５Ａ】
2010507146.tif 000027
【図５Ｂ】
2010507146.tif 000028
【図６】
2010507146.tif 000029
【図７Ａ】
2010507146.tif 000030
【図７Ｂ】
2010507146.tif 000031
【図８Ａ】
2010507146.tif 000032
【図８Ｂ】
2010507146.tif 000033
【図９】
2010507146.tif 000034
【図１０】
2010507146.tif 000035
【国際調査報告】
2010507146.tif 000036
2010507146.tif 000037