JP4527976B2 - ホストされるアプリケーションのためのサーバ・リソース管理 - Google Patents

Description

本発明は、サード・パーティにホストされるアプリケーションへのアクセスを提供するためのサーバ・リソースの管理に関し、詳細には、ただしそれだけには限らないが、アプリケーション・サービス・プロバイダによって運営されるサーバの自動管理に関する。

アプリケーション・サービス・プロバイダ（ＡＳＰ）は、しばしばサーバ・ファームと称される共用コンピューティング・インフラストラクチャを使用して、複数の顧客（すなわち、クライアント組織）に向けてアプリケーションをホストする。ＡＳＰは、（冗長性、ピーク負荷ハンドリング、専門技術などに関して）規模の経済性を利用し、複雑な情報テクノロジ管理よりも中核業務に注力しなければならない顧客の要求に便乗する。コンピューティング・インフラストラクチャはＡＳＰが所有し、顧客の間で共用されるので、ＡＳＰは、リソースの利用度を高め、それによって、費用対効果の高いサービスを提供する機会に恵まれている。

上述のことから見て、経済上、技術上、および競争上の理由から、企業ユーザが使用アプリケーションをＡＳＰにアウトソーシングする明らかな傾向があることがわかる。現在、大多数のＡＳＰは、顧客毎に専用のサーバを用意して、ウェブ・ホスティングのような単純なサービスを提供している。他のＡＳＰは、サービス内容を取り決めた非常に単純なサービス品質保証契約（ＳＬＡ）を伴った、比較的に静的な方式でのサーバの共用を可能にしている。

マシン使用度を高めるための１つの既存手法は、すべてのマシンを顧客間にどう割り当て、またそれをどう解除するかに関係する。この手法では、顧客は自らのニーズを、自分の裁量で、必要なマシン数の下限および上限の形で明確に指定する必要があるが、そのためには、顧客は技術的に相当知識を有していなければならない。大企業のクライアントにとって、これは難しいことではないが、小規模および中規模の企業にとっては一般に、簡単なことではない。

改良された手法が、カリフォルニア州サニーベールのエンシム・コーポレーション（EnsimCorporation）によって提案された。提案されたこの手法は、マシン・フラクション（machine fraction）という概念を使用したアプリケーション・ホスティングを提供する。エンシムのソリューションを用いると、ＡＳＰは、サーバ・リソースを顧客間で安全に共用できるようになり、またプライベート・サーバ（ＰＳ）と称されるものをサポートすることによって、サーバ・ファーム全体にわたるアプリケーションの配備を管理できるようになる。各ＰＳは、物理サーバ上でサポートされる市販のアプリケーションはどれでも実行することができる。エンシムのシステムはまた、障害を起したＰＳを復旧させ、ＰＳ間およびマシン間で顧客を移動させ、またＰＳリソースを手動で増加させるための管理プリミティブも提供する。ＡＳＰは、１台のコンソールから、複数のＰＳにデータを供給し（provision）、これを管理することができる。ホストされるアプリケーションは、ウェブ・ホスティングに対応していさえすればよく、その他の変更は必要としない。

様々な利点があるにもかかわらず、エンシムによって提案された手法には様々な制限がある。各ＰＳが物理サーバ・リソースの最低限の可用性を保証するという点で、ＰＳは比較的に静的である。その結果、エンシムによって提供されたソリューションは、リソース利用の点から見ると、まだ比較的に効果が薄い。また、システム管理をコンソールを介して手動で行わなければならない。

上述の点に鑑みて、アプリケーションをホストするための改良されたソリューションであって、少なくとも既存技法に伴う上記およびその他の制限への対処を試みるソリューションが明らかに必要とされている。

顧客はしばしば、専用ハードウェアの提供をＡＳＰに求めない。顧客スタッフの要求は一般に小さく、複数の顧客の要求をサーバ・ファームの１つのマシンでホストすることによって、そうした要求を同時に満たすことが可能である。したがって、フラクショナル・ホスティング（すなわち、マシンの一部分だけを特定の顧客に割り当てること）が一般に望ましい。これによって、ハイエンドなサービスの提供が見込まれる一方で、高価なマシンおよびソフトウェアの費用負担は顧客間で分担される。これとの関連で、フラクショナル・ホスティングを提供するための、後に説明する「仮想」サーバという概念を使用した柔軟な管理形態が提供される。

アプリケーション宛てのリクエストは、そのアプリケーション（または、そのアプリケーションの適切なコンポーネント）の特定の実行中インスタンスに転送される。転送先のインスタンスには、当該アプリケーションまたはそのコンポーネントの使用可能なインスタンスのうちで最も作業負荷の軽いものが選ばれる。そうしたインスタンスの数または容量あるいはその両方は、アプリケーションまたはそのコンポーネント宛てのリクエストの数が変化するにつれて、動的に増減する。

クライアント単位でリクエストが管理され、インスタンスが調整される。すなわち、アプリケーションまたはそのコンポーネントあるいはその両方のインスタンスが、個々の顧客または特定の顧客グループが使用するために確保される。このような方式による運営は、エンティティ毎に取り交したサービス品質保証契約の遵守を容易にする。

現在割り当てられているリソースおよび現在消費されているリソースについての記録が、アプリケーションまたはそのコンポーネントのインスタンスによって処理されるリクエストがそのインスタンスにかける負荷を表す負荷率の形で、インスタンスと顧客の組合せ毎に維持管理される。

顧客と取り交すサービス品質保証契約は、アプリケーションに対するリクエスト数の推定範囲の形で構造化される。この推定範囲を細分した１つまたは複数の異なる範囲でのサービス・リクエスト料率によって請求が行われる。インフラストラクチャのせいでリクエストにサービスを提供できない場合は、（顧客に支払われる）ペナルティ料率で請求される。

好ましい実施形態では、複数の顧客からのリクエストがピークに達したときの負荷を処理するのに必要とされるリソースを、またＳＬＡに違反しないように保証するのに必要とされるリソースを減少させることによって、ＡＳＰのリソース利用度を高めることができる。確保しておかなければならない予備の容量は、顧客数につれて線形に増加することはなく、顧客数が多くなっても、ほぼ一定の値に留まるようになる。それにもかかわらず、障害リスクが限られているのは、異なるユーザからの要求が一時に集中する（すなわち、同時に発生する）確率は大きくなく、もともと小さな確率の積によって表されるためである。

上述のシステムは、リソース割当ての最適化、自動システム管理、必要に基づくリソース（ハードウェアおよびソフトウェア）共用によって、ＡＳＰの収入を最大にする。

本明細書で説明する技法を用いれば、好都合にも、顧客は、使用を希望するアプリケーションと期待する使用レベルの形で、ハイレベルな要求を明確にするだけでよい。顧客は、裏に隠れたリソースに関するすべての決定をＡＳＰに委ねる。ＡＳＰは、異なるマシン・フラクションを顧客に割り当てることができ、それらは全体で、変動する負荷と障害に応じて時間と共に増減することのある１つの仮想サーバを構成する。

サーバ・リソースを管理するための技法および構成を、ＡＳＰによって提供されるサービスとの関連で説明する。ユーザ（ＡＳＰの顧客またはクライアント）は、ＡＳＰによって運営されるネットワーク接続された複数のマシン上でホストされる１つまたは複数のアプリケーションにアクセスすることができる。ネットワーク接続されたマシンのこの集合体は、一般に特定の物理サイトにおけるローカル・エリア・ネットワーク（ＬＡＮ）によって接続され、サーバ・ファームと呼ばれる。

アプリケーション・ホスティング
サーバ・ファームは、リソースの集合体と見ることができる。リソースには、ハードウェア（コンピュータ、電源機構、ネットワーク機器など）、およびＡＳＰがその潜在的カストマによって有用と考えるソフトウェア（アプリケーション、標準ミドルウェア、オペレーティング・システム）が含まれる。コンピュータは、異機種が混在してもよく、性能に大きな隔たりがあってもよい。例えば、ＡＳＰは、小規模ウェブサイトをホストするための簡単なパーソナル・コンピュータ・サーバを提供することができ、複雑な財務分析または科学的分析を実行するためのハイエンドのメインフレームを提供することもできる。

同様に、ＡＳＰによって提供されるソフトウェアも、簡単な生産性向上ツール（ワード・プロセッサ、スプレッドシート）から本格的なアプリケーション（給与計算、ｅコマース・ウェブサイト）や専門領域の複雑なアルゴリズム（チェスなどの対話型ゲーム、気象予報などの科学計算その他）まで多岐にわたる。

仮想サーバおよび仮想サーバ・ファーム
アプリケーションは、１組のリソース・クラスと考えることができる。仮想サーバ・タイプという用語は、そのような１組のリソース・クラスを指すために使用される。例えば、ウェブ・ベースの小売店アプリケーションを、以下のコンポーネントから構成することができる。
・フロントエンド・コンポーネント＜web server＞
・中間層コンポーネント＜e-commerce server＞
・バックエンド・コンポーネント＜database server＞

したがって、ＡＳＰのクライアントが一般に必要とするアプリケーションは、概念的に１組のリソース・クラスに区分化される。リソース・クラスは、特定タイプのリソースの属性および機能をカプセル化する。例を挙げると、
・ＤＢ２（商標）サーバは、リソースクラス＜database server＞のインスタンスである。
・WebSphere（商標）コマース・サーバ（ＷＣＳ）は、リソースクラス＜e-commerceserver＞のインスタンスである、など。

リソース・クラスは、異なるインスタンスをもつことができる。例えば、＜databaseserver＞クラスは、ＤＢ２サーバの他にも、OracleサーバやSybaseサーバを包含することができる。しかし、これらのインスタンスは、共用リレーショナル・データベースへのリモート・アクセスを提供する共通機能を共有する。

仮想サーバは、仮想サーバ・タイプのインスタンスである。例えば、ＡＳＰの顧客のウェブストア・アプリケーションは、Apache（商標）ウェブ・サーバ、WebSphere（商標）コマース・サーバ、およびＤＢ２（商標）データベース・サーバから構成することができる。このアプリケーションをＡＳＰのサーバ・ファーム上に配備する場合、すべての受信リクエストをタイムリーに処理できるように、各リソース・クラスの複数のインスタンスが存在してよいことに留意されたい。

ＡＳＰは、例えば、ウェブストアのその時の負荷次第で、Apache（商標）フロントエンドのインスタンスを５つ、ＷＣＳ（商標）のインスタンスを２つ、ＤＢ２（商標）データベースのインスタンスを１つ実行することにしてもよい。したがって、仮想サーバの実行時の実施形態は、仮想サーバ・タイプに含まれる各リソース・クラスの（おそらく複数の）インスタンスから構成される。

したがって、クライアントのアプリケーション要件は、仮想サーバ・タイプの指定に変換することができる。次のステップは、サーバ・ファームで使用可能な物理マシンにリソース・インスタンスをいかにマッピングするかを決定することである。

以下の説明では、ＡＳＰが顧客間でマシンを共用しているものとし、マシン・フラクションを、１つのクライアントに割り当てられた１組のリソースであって、そのすべてが同一の物理マシン上に存在する１組のリソースとして定義する。

以下で詳細に説明するように、仮想サーバのリソース・インスタンスはすべて、１つのマシン・フラクション内に共存することもできるが、一般にはＡＳＰは、仮想サーバを異なるマシン上に分散する１組のマシン・フラクションにマッピングする。例えば、顧客のウェブストアを表す仮想サーバは、２つのApache（商標）サーバと１つのＷＣＳ（商標）サーバを第１のマシン・フラクションで実行し、３つのApache（商標）サーバと１つのＷＣＳ（商標）サーバを別のマシンで実行し、ＤＢ２（商標）サーバを第３のマシンで実行することによってサポートすることができる。こうすることで、ＡＳＰは負荷をマシン間に分散させることができる。後になって、顧客のウェブストアの負荷が非常に低くなった場合、ＡＳＰは、仮想サーバを、１つのApache（商標）サーバと１つのＷＣＳ（商標）サーバとを含む第１のマシン・フラクションとＤＢ２（商標）サーバを実行する第２のフラクションとに再構成することもできる。

１つの手法は、マシンを特定のリソース・クラス専用にすることである。例えば、顧客の仮想サーバを、フロントエンドのウェブ・サーバだけを実行する第１のマシン・フラクションと、コマース・サーバだけを実行する別のマシンと、データベース・サーバだけを実行する第３のマシンとにマッピングすることができる。このようにすると、ＡＳＰのメンテナンス作業を容易にし、マシンが専門に扱うアプリケーションの監視および使用度測定の際に他のアプリケーションの干渉を抑制する利点がある。物理マシンを特定のリソース・クラスの専用にするというこの手法は、好ましい実施形態において採用されている手法である。

仮想サーバとマシン・フラクションという一対の概念を用いてモデル化され管理されるＡＳＰサーバ・ウェアハウスは、仮想サーバ・ファームと称される。仮想サーバ・ファームの目的は、ＡＳＰのリソースの効率的な自動管理を提供することであり、その管理の下で、顧客とのサービス品質保証契約に規定する合意されたサービス基準を維持しながら、最適化されたまたはほぼ最適化された方式で、リソースが要求に応じて顧客に割り当てられる。

サービス品質保証契約
ＡＳＰの顧客は望ましくは、ＡＳＰのリソースに関する技術的詳細について知らなくてよい。このため、ＡＳＰは、専門化向けの技術的なパラメータを参照する必要のない顧客や詳しい技術的知識の理解を必要としない顧客とも、サービス品質保証契約を取り交すことができることが理解されよう。一方で、そのようなサービス品質保証契約は、顧客のサービス要件を把握するのにも適している。顧客はただ、ホストされることを望むアプリケーションとアプリケーションへの予測要求または負荷とを示すことができさえすればよい。

本明細書で説明する実施形態との関連で提供することができるサービス品質保証契約は、アプリケーションのヒットという概念に基づいている。ヒットは、アプリケーションの使用を求めるリクエストを表す。ヒットは一般に、その重み、すなわち、アプリケーションに課される計算上の加重によって変化する。さらに、実際のリソース使用は、アプリケーションのベンチマークから得た予測使用と正確に合致しないかもしれない。本明細書で説明する実施形態は、この実際の挙動と予測された挙動との差のような小幅な変動であれば対処することができる。それにもかかわらず、ヒットはほぼ予測に従う（well behaved）ものと仮定される。すなわち、重みには限度がある。

顧客は、配備されるアプリケーションに対する予測リクエスト率の形で、自らの要件を指定する。異なる期間に対して、値が異なるヒット率を指定することもできる。ヒット率の指定に基づいて、顧客とＡＳＰは、サービス品質保証契約の料金を取り決める。価格モデルは望ましくは、システムから独立している。システムは、多様な価格体系をサポートすることができる。例えば、ＡＳＰは、どのようなサービスが提供されようとも、顧客に一定の月額料金を請求することができ、あるいは時間帯によって変化するアプリケーションのユーザ数に基づいて請求することもできる。一貫性を保つために、サービス品質保証契約は、以下のパラメータを含むものとする。
・顧客のアプリケーションが受信しサポートすると予測されるヒット範囲。さらに可能であれば、平均ヒット率。
・この範囲の中の異なるサブ範囲毎に、顧客が支払いに同意した価格。
・最低限の要件が満たされなかった場合に、ＡＳＰが顧客に支払う違約金。

このタイプの簡易的なサービス品質保証契約では、顧客は、使用されるハードウェアの種類、配備されるサーバの数、その他の技術的指定といった技術的詳細について詳しく知る必要はないが、アプリケーションが扱うことになる負荷量については知っておく必要がある。一方、ＡＳＰは、顧客要件の機能的指定を、サービス品質保証契約にある顧客の要求を満たすことができる特定の１組のリソースに移し変えることができる。この変換を達成するために、ＡＳＰは望ましくは、次に説明するようなタイプのベンチマーキング・データを参考にする。

ベンチマーキング
特定のアプリケーションをサポートするマシンの容量は、そのマシン上で実行した場合にアプリケーションがサポート可能なヒット率によって評価される。ホストされるアプリケーションはすべて、最初にベンチマーク・テストにかけられて、中央処理装置サイクル、ランダム・アクセス・メモリ要件、ディスク空間使用量など、マシンの物理リソースの消費状況に関する情報が取得される。このベンチマーキング・プロセスは、２つのレベルで実行される。（ａ）すべてのエンドユーザ・アプリケーションについてベンチマーク・テストを行う。（ｂ）エンドユーザ・アプリケーションの構成単位を構成するすべてのソフトウェア・リソース・クラスについて個別にベンチマーク・テストを行う。

後者の個別のリソース・クラスに関するベンチマーキング・プロセスによって、所与のヒット率を得るために必要な物理リソースが決定される。この情報は、ヒット率の形で要求が出されたときに、クライアントのアプリケーションを構成するリソース・クラスに割り当てる実際の物理リソース量を決定するのに必要となる。一方、エンドユーザのアプリケーションに関するベンチマーキング情報は、所与のヒット率をサポートするのに必要な異なる構成リソース・クラスの量を示す。この情報は、エンドユーザのアプリケーションのソフトウェア・コンポーネント間の関係を定めるが、この関係は、アプリケーションの負荷をこれら個々のコンポーネントの負荷に変換する割合を表す。

広く普及している多くのアプリケーションでは、関連するディベロッパから、こうしたベンチマーキング情報を容易に入手することができる。ベンチマーキング情報を入手できない場合、ＡＳＰは自ら、適切な試験および実験を行うことによって、ベンチマーキング情報を生成することができる。あるいは、必要とされる物理リソースについての公平な初期評価に基づいてリソースを割り当てた後、アプリケーションを配備することもできる。実験期間中に実際のリソース使用に関する情報を蓄え、それに基づき試行錯誤を繰り返しながら、リソース割当てを調整していくこともできる。

概要
図１に、ＡＳＰ管理システムの機能コンポーネントを示す。以下の概要で、これらの機能コンポーネントついて簡略に説明する。これらのコンポーネントは、システムによって制御されるネットワーク接続された１つまたは複数のマシン上に存在する。図１では、図示の機能コンポーネント間の情報フローは、これらの機能コンポーネントを結ぶ矢印で示される。機能コンポーネント同士の相互関係を以下に説明する。

リソース・マネージャ
リソース・マネージャ１５０は、エージェントと共に、１つの分散コンポーネントを構成する。エージェントは、サーバ・ファーム内の物理マシンに分散される。中核コンポーネントであるリソース・マネージャ１５０は、それ用のマシンに配置される単一のエンティティである。

ロード・ディストリビュータ
仮想サーバ・ファーム内の各サブファーム毎に１つの集中型のロード・ディストリビュータ１１０が存在する。

グローバル・ディシジョン・メーカ（ＧＤＭ）
グローバル・ディシジョン・メーカ１４０は、単一の集中型エンティティである。

ロード・モニタ
ロード・モニタ１３０は、図１に示唆するように、仮想サーバ・ファーム内の物理マシン全体に分散される。

アグレゲータ
アグレゲータ１２０は、以下に述べるように、異なるコンポーネントから構成される。

・レベル１・アグレゲータは、サーバ・ファーム全体に分散される。このコンポーネントの各インスタンスは、１つまたは複数のサブファーム、またはファームの１つの顧客グループを担当する。この実装上の決定は、負荷情報生成で表した対応するサブファームのサイズに依存する。各インスタンスは、異なるマシン上に配置される。

・レベル２ａ・アグレゲータは、レベル１・アグレゲータによって生成される負荷に応じて、分散型エンティティでも集中型エンティティでもよい。分散型の場合、各インスタンスは１つの顧客グループを処理する。

・レベル２ｂ・アグレゲータも同様に、レベル１・アグレゲータによって生成される負荷に応じて、分散型エンティティでも集中型エンティティでもよい。分散型の場合、各インスタンスはリソース・クラスの１グループを処理する。

コンフィグレーション・リポジトリ
コンフィグレーション・リポジトリ１６０は、集中型のデータベースである。

システム・アーキテクチャ概要
図１に示すシステム・アーキテクチャについて、次にやや詳細に論じる。ＡＳＰは複数の顧客をホストし、顧客のユーザはインターネットを介してＡＳＰのインフラストラクチャにアクセスする。サーバ・ファームへの加入時に、顧客は顧客要件に関する情報を含むサービス品質保証契約にサインする。顧客の仮想サーバを初期化するために、これが使用される。

顧客のアプリケーションは、リソース・クラス（上述したような、ウェブ・サーバ、コマース・サーバ、データベース・サーバから成る階層など）に分割され、各リソース・クラスは、任意の時に動作する複数のインスタンスをもつことができる。顧客のアプリケーションと様々なリソース・インスタンスの物理マシンへの配置とについての詳細な情報が、コンフィグレーション・リポジトリ１６０の中で動的に維持管理される。

ハイレベルな顧客要件は、ベンチマーキング情報およびアプリケーション特性を用いて、リソース・クラス毎の要件に変換される。システムは数多くのサブファームをもち、各サブファームは１つのリソース・クラスの数多くのインスタンスから構成される。特定のサブファームへのトラフィックは、そのサブファームのロード・ディストリビュータ１１０によって提供され、ロード・ディストリビュータ１１０は、その管理下にある異なるインスタンス間に均等に負荷を分配する。

各リソース・インスタンスは、関連するロード・モニタ１３０をもち、ロード・モニタ１３０は、リソース・インスタンスのパフォーマンスに関する計測値（metric）の継続的収集を担当する。この情報はロード・ディストリビュータ１１０から使用できるようになり、ロード・ディストリビュータ１１０は、この情報を使用して負荷を分散させる。モニタした情報はアグレゲータ１２０にも提供され、アグレゲータ１２０は、計測値を意味のある方式で蓄積し標準化する。こうすることで、測定値はリソース・クラス毎の全体的な使用状況、さらには顧客毎の使用状況の形に加工される。この後者の使用状況は、顧客のサービス品質保証契約に記載された許容範囲セットと比較される。これらの数値に基づいて、アグレゲータ１２０は、各顧客に対する現在のリソース割当てに何らかの変更が必要かどうか判断し、それをグローバル・ディシジョン・メーカ１４０に提示する。

グローバル・ディシジョン・メーカ１４０は、発生した収入、現在の割当てにおけるリソース利用度または変動（perturbation）など、何らかのパラメータを最適化する目的で、様々な顧客へのリソース割当てを再計算する。新しい割当ては、リソース・マネージャ１５０に提供され、リソース・マネージャ１５０は、変更された割当てプランの実際の実施を担当する。リソース・マネージャ１５０はまた、変更が完了した後、サーバ・ファームの中心的な構成定義ストレージであるコンフィグレーション・リポジトリ１６０を更新する。

サーバ・ファームの動作的構造
次に、リソース使用および割当てを管理するコンポーネントとの関連で、仮想サーバ・ファームの動作について説明する。

ロード・モニタ
論理モニタＩは、時系列のモニタ・データ（またはモニタ・イベント）−ｍ_Ｉ０、ｍ_Ｉ１、．．．、ｍ_Ｉｎを表す。論理モニタの組は動的である。２種類のモニタ、すなわち、ヒット率モニタとマシン負荷モニタがある。各リソース・インスタンス毎に、各種類のモニタが１つずつある。各モニタの最初のモニタ・イベント（第０イベント）は、一貫性の維持と単純化のために事前定義される。そうした初期化は、アプリケーションにかかると予測される初期負荷に基づいている。各モニタは、リソース・インスタンスに問い合せることができるモジュールのために、「最新の」１つのモニタ・イベントを常にバッファリングしている。より古いモニタ・イベントは、それらの値を永続的に保存しておく必要がないので、廃棄することができる。

アグレゲータ
アグレゲータ１２０は、２つのレベルのアグレゲータを含む。レベル１・アグレゲータは、モニタ・データを収集し統合する。クライアントとリソース・クラスの各対毎に、レベル１・アグレゲータが１つ存在する。クライアントとリソース・クラスの対に対応するインスタンスからのすべてのモニタ・データが、１つのアグレゲータに送られる。アグレゲータは、このデータをインスタンス毎の（自明な）ヒット率とインスタンス毎のヒット加重値（hit weight）に変換する。アグレゲータは、アグレゲータに関連する各モニタから「最新の」１つのモニタ・イベントを取得する。事前定義されたモニタ・イベントが常に使用可能なので、新しいモニタ・イベントが生成されなくとも、最新モニタ・イベントを収集するプロセスは不明確にはならず、無閉塞である。このプロセスですべてのモニタ・イベントが使用される保証はないので、統合を行う際に、所定のモニタ系列内のいくつかのイベントをスキップすることができる。

ヒット加重値を計算する際、アグレゲータは、モニタ・イベント収集プロセスは高速であり、すべての収集データが時間内に配列されるので、計算結果は意味があると仮定する。レベル１・アグレゲータの出力は、３種類のレベル１・イベントから成る。

・第１のイベントは、クライアントに対応する各アプリケーション・インスタンス毎にどれだけの負荷がかかっているかに関する、ロード・ディストリビュータに提供される負荷率である。

・第２のイベントは、レベル２ａ・アグレゲータに送られる新ヒット率である。レベル２ａ・アグレゲータは、クライアントのすべてのリソース・クラスにわたってデータを収集して統合し、ヒット率モニタ（のみ）から得た現在のデータとクライアントについての現在の割当てとに基づいてクライアントに関する要求予測を行う。レベル２ａ・アグレゲータは、コンフィグレーション・リポジトリを検索することによって、現在の割当てを取得する。

・第３のイベントは、レベル２ｂ・アグレゲータに送られる新ヒット加重値である。レベル２ｂ・アグレゲータは、各インスタンスについての補正率（correction factor）を計算し、それらを統合してクライアントについての（リソース・クラス毎の）全体的な補正率にする。

要約すると、統合は、顧客について、モニタ系列データの部分（slices）を検索することと、そのデータを、クライアントについてのクラス毎の加重値補正率（weightcorrection factor）、クライアントについての予測割当て要求、およびロード・ディストリビュータに対するフィードバック・イベントに変換することを含む。

ロード・ディストリビュータ
サーバ・ファームは、複数の内部的なサブファームに分割され、各サブファームは、ファーム内の１つのリソース・クラスに対応する。リソース・クラスに対応するアプリケーション・インスタンスは、サブファームに含まれ、アプリケーション・インスタンスに対する受信負荷は、インスタンス間に分配される。各サブファーム毎にロード・ディストリビュータ１１０が１つ存在する。サーバ・ファームのゲートウェイは、顧客の識別情報に基づいて別個のフロントエンド・サブファームのディストリビュータに受信ヒットを転送する。フロントエンド・サブファームは、フロントエンドのコンポーネントが依存する中間層のリソース・クラスまたはバックエンドのリソース・クラスあるいはその両方にかかる内部負荷を生成する。この負荷は、中間層／バックエンドのリソース・クラスに対応するサブファームに対して生成される内部ヒットの形をとる。内部ヒットは、内部サブファームのロード・ディストリビュータ１１０に転送される。

サブファームのロード・ディストリビュータ１１０は、以下のように機能する。受信ヒットに関するクライアントが特定され、その次に、どのサブファーム・アプリケーション・インスタンスが、クライアントに割り当てられた割当て容量を、ヒットを処理できるのに十分なだけ残しているかを判断する。その次に、ヒットがそのアプリケーションに転送される。ヒットを処理する余分な割当て容量がない場合、そのヒットは取り除かれるか、遅延処理用のキューに入れられる。

ロード・ディストリビュータ１１０は、ディストリビュータがヒットを分配するインスタンスの現在の組について、割当て容量と現在の負荷を追跡する。各ロード・ディストリビュータ１１０は、レベル１・アグレゲータから最新の負荷情報を読み取ることによって、保有する情報を更新する。したがって、負荷情報は、先にモニタのようなモジュールについて論じたように、単位容量のバッファに保存することができる。バッファは、予測される初期負荷に基づいて事前定義された負荷を使用して初期化することができる。最新の負荷情報の他にも、各ロード・ディストリビュータ１１０は、最新のリソース割当て情報を取得する必要があり、これをコンフィグレーション・リポジトリ１６０から取得する。

グローバル・ディシジョン・メーカ
全体的な判断プロセスが１つ存在する。このプロセスには、すべてのクライアントについて、１組の「最新」要求が与えられる。この目的のため、レベル２ａ・アグレゲータは、モニタがそのデータに関して行ったように、単位容量の最新要求バッファを維持管理することができる。（モニタの場合と同様に）有効な「最新要求」が常に存在するように、バッファを事前定義された要求で最初に初期化しなければならない。グローバル・ディシジョン・メーカ１４０は、１組の最新要求によって呼び出された際、サーバ・ファームについての割当てプランを計算する。割当てプランは、グローバル・ディシジョン・メーカ１４０の単位容量の出力バッファ上から入手可能となる。モニタやアグレゲータの単位容量出力バッファとは異なり、グローバル・ディシジョン・メーカ１４０の出力バッファは、事前定義された割当てで初期化されることはない。したがって、グローバル・ディシジョン・メーカ１４０に依存するモジュールは、「最新」割当てプランが入手できない場合の閉塞にあらかじめ対処しておかなければならない。割当てプランを生成する過程で、グローバル・ディシジョン・メーカ１４０は、コンフィグレーション・リポジトリ１６０に格納された情報を使用する。

リソース・マネージャ
リソース・マネージャ１５０は、グローバル・ディシジョン・メーカ１４０によって作成された最新割当てプランに従って動作する単一のプロセスである。リソース・マネージャ１５０は、以下のタスクを担当する。
・割当てに従ってアプリケーション・インスタンスを生成する。
・モニタを生成し初期化する。
・廃棄されたアプリケーション・インスタンスをそのモニタと共に消滅させる。
・アプリケーション容量の縮小／拡大のために、任意のＯＳレベル技法とのインタフェースをとる。
・上記の変更に従ってアグレゲータを変更する（例えば、データ取得先のモニタ・セットの変更、アグレゲータからディストリビュータへの接続の変更、さらにグローバル・ディシジョン・メーカ１４０への接続の変更）。
・サブファームおよびロード・ディストリビュータ１１０の生成／削除を行う。

リソース・マネージャ１５０は、リソースの仮想世界とマシンおよびプロセスの物理世界との橋渡しをする。グローバル・ディシジョン・メーカ１４０は、抽象的な形でファーム全般のリソース割当てを計算し、リクエスト処理容量（request-serving capacity）の形でリソース・インスタンスを様々なクライアントに割り当てる。これらの割当てプランは、物理マシンおよび実際のプロセス上で実行される動作に変換して、望ましい構成を達成しなければならない。リソース・マネージャは、エージェントと共に、このタスクを実行する。

所与のクライアントについて、サブファームのアプリケーション・インスタンスがただ１つ必要とされるだけで、サブファームは存在し続けることができるので、一般にサブファームは静的である。しかし、サブファームは、新しいリソース・クラスを用いた新しいクライアントの追加に伴い、また古いクライアントと古いリソース・クラスの削除に伴い、生成および削除することができる。リソース・マネージャ１５０は、クライアントとそのヒットに関する限り、上記のすべての動作が透過的に行われることを保証しなければならない。上記の動作に関しては、サーバ・ファームは停止またはタイムアウトすることができない。これは、サブファームの生成および削除に関して、生成はサブファームへのすべてのヒットの到着の前に行われなければならず、削除はサブファームへのすべてのヒットの到着の後に行われなければならいことを意味する。

コンフィグレーション・リポジトリ
コンフィグレーション・リポジトリ１６０は、サーバ・ファームの中央ストレージとして動作する。コンフィグレーション・リポジトリ１６０は、以下の情報を格納する。
・ハードウェア情報。
・ソフトウェア情報：依存関係、必要とするハードウェアなど。
・マシン容量テーブル：ｋ個（様々な数）一組の参考ヒットで表した、様々なリソース・クラス（アプリケーション）に関するベンチマーキング情報。
・アロケーション・テーブル：処理することができる実際のヒットおよび様々なリソース・クラス・インスタンスについてのヒット加重値で表した、サーバ・ファームにおける各クライアント毎の現在の割当て。
・アプリケーション特性テーブル：アプリケーションを構成する様々なリソース・クラスに対する参考ヒットで表した、ホストされるアプリケーションに関するベンチマーキング情報。
・すべての顧客のＳＬＡ情報。
・システム・コンポーネントの構成情報。すべてのシステム管理コンポーネントは、初期化のとき、この情報、例えば、情報送信先のコンポーネントのアドレスなどを読み取る。

以下で説明する単純なスイープ・スケジュール（sweep schedule）に合せて、集中型のコンフィグレーション・リポジトリ１６０へのアクセス間の競合／依存は、以下の大まかな方針を用いて簡略化することができる。スケジュールされた所定の１組のスイープ（モニタの次がアグレゲータ、その次がグローバル・ディシジョン・メーカ１４０、その次がリソース・マネージャ１５０）の中で、データがスケジュール中の次のモジュールによって使用されることになるまで、どのモジュールもコンフィグレーション・リポジトリ１６０にデータを書き込まない。

言い換えると、データは、モジュールからモジュールへ、そのデータを使用する最後のモジュールまでメッセージ渡し方式で渡され、そのデータが後で使用される場合は、最後のモジュールが、コンフィグレーション・リポジトリ１６０へデータを書き込む。例を挙げると、ヒット加重値は、アグレゲータからグローバル・ディシジョン・メーカ１４０に渡され、グローバル・ディシジョン・メーカ１４０は、そのヒット加重値を割当てプランとともに、リソース・マネージャ１５０に渡すことができ、あるいはリソース・マネージャは、そのヒット加重値とプランとを、リソース・マネージャ１５０および後のスケジュールが使用できるように、コンフィグレーション・リポジトリ１６０へ書き込むことができる。上記の方針に従って、グローバル・ディシジョン・メーカ１４０は、コンフィグレーション・リポジトリへの書込みは一切行わず、そのすべてをリソース・マネージャ１５０に委ね、リソース・マネージャ１５０は、渡されたデータに基づいてすべての書込みを行う。

上記の方針の下では、現在のスケジュールで保存されたデータを対象としたコンフィグレーション・リポジトリへの読取りアクセスは発生しない。すべての読取りアクセスは、それ以前の長いスケジュール（または初期化のようなその他のより早い時期のイベント）において保存されたデータを対象にしており、そのデータを対象とした従属（dependency）間でのデッドロックは発生せず、そのデータに関する競合問題は単純である（読取りのみ）。これは、モニタリングと統合と負荷分配のみを含む短いスケジュールに関しても当てはまり、短いスケジュールは、グローバル・ディシジョン・メーカ１４０またはリソース・マネージャ１５０の呼び出しの間に何度も実行することができる。

スケジューリング
１つの単純なスケジュールは、モニタリング・スイープ（monitoring sweep）、統合スイープ（aggregationsweep）、グローバル・ディシジョン・メーカ１４０のプラン計算をこの順序で行い、最後にリソース・マネージャによるプラン展開を行うというものである。この後、同じサイクルを繰り返す。プランの計算と展開は比較的低速なプロセスであるので、直前で説明したようなサイクルには比較的長い時間を要する。モニタリング、並びに負荷情報をロード・ディストリビュータ１１０にフィードバックするための統合には、比較的短い時間しか要しないことがある。これに応じて（tocater to this）、ロード・ディストリビュータ１１０へのフィードバック・サイクルの多くは、グローバル・ディシジョン・メーカ１４０が関係するサイクル毎に実行することができる。したがって、僅かな少数ガイド・プランの再計算（asmall minority guiding plan recomputation）だけで、モニタ系列中の大多数のイベントを、ロード・ディストリビュータ１１０へのフィードバックに合せて調整することができる。この方式の簡単な任意選択の変形には、僅かな少数ガイド・プランの再計算に、その他のモニタ・イベントから計算された平均も含めるものがある。

仮想サーバ・ファームの実装
次に、仮想サーバ・ファーム・システムの個々のコンポーネントの実装について、図１を参照しながら具体的に説明する。仮想サーバと仮想サーバ・ファームの１つの例が、図２に示されている。

図２には、ＡＳＰホスティング・ソリューションのアーキテクチャが示されている。サーバ・ファームのゲートウェイは、別個のフロントエンド・サブファーム２１２、２４２にそれぞれ対応するディストリビュータ２１０、２４０に、受信ヒットを転送する。図２では、仮想サーバ１（実線で表す）は、サブファーム２１２、２２２、２３２にあるリソースのインスタンスから構成され、仮想サーバ２（破線で表す）は、サブファーム２４２、２２２、２３２にあるリソースのインスタンスから構成され、仮想サーバ３（一点鎖線で表す）は、サブファーム２１２、２５２、２６２にあるリソースのインスタンスから構成される。ヒットは、図示するように、これらのサーバファーム２１２、２２２、２３２、２４２、２５２、２６２の各々に、対応するロード・ディストリビュータ２１０、２２０、２３０、２４０、２５０、２６０によって分配される。

ロード・モニタ
ロード・モニタ１３０は、リソースの使用状況をモニタするために、様々なリソース・クラスのインスタンスによって使用される。この情報を使用して、サービス品質保証契約に従った割当ての変更が決定され、様々なリソース・クラスのインスタンス全体にわたって負荷の均衡が図られる。

各クライアントは、そのアプリケーションが必要とするリソース・クラスのインスタンスをもつ。このインスタンスを、以下の方法によって、実際の実装上にマッピングすることができる。

・クライアント毎に、リソース・クラスの別個の物理インスタンスが存在する。特定のクライアントに対応する複数のこうしたインスタンスは、複数の物理マシン上に存在することができる。

・異なるクライアントに対応するインスタンスが、同一の物理マシン上に存在することができる。

・単一の物理リソース・インスタンスは、複数のクライアントにサービスを提供する。各クライアントによるリソースの使用は、インスタンス自体によって、または外部エンティティによって制限される。

論理的に、ロード・モニタ１３０は、あるクライアントについて、リソース・クラスの各インスタンス毎に存在する。しかし、実際のシステムでは、物理マシン毎にある単一のロード・モニタが、そのマシン上のすべてのアプリケーション・インスタンスについての負荷情報をモニタし報告することができる。

２種類のモニタが存在する。
・各アプリケーション・インスタンスについて、単位時間当たりのヒット数を計測するヒット率モニタ。
・アプリケーション・インスタンスによって実際に消費された物理リソースを計測するマシン負荷モニタ。これは、中央処理装置サイクルや必要メモリ容量などのパラメータから成るｋ次元ベクトルとすることができる。

ロード・ディストリビュータ１１０は、それに転送されたヒット数を総計することによって、クライアントの各アプリケーション・インスタンスについてヒット率を計測する。したがって、ロード・ディストリビュータ１１０は、ロード・モニタとしても動作する。

マシン負荷モニタは、以下の技法のいずれかを使用して実施することができる。
・ＵＮＩＸ（Ｒ）のｐｓやｔｏｐなど、負荷情報を提供する既存の何らかのシステム・プログラムを使用する。
・ＵＮＩＸ（Ｒ）の／ｐｒｏｃファイル・システムのような、下層のオペレーティング・システムが提供する情報を使用する。
・Tivoli（商標）負荷モニタ・システムのような、既存の何らかの負荷モニタ技術。
・アプリケーションが提供する負荷情報（提供される場合）。

ロード・モニタ１３０は最新の負荷情報を単位バッファに保持し、レベル１・アグレゲータがそれを取り出す。

負荷情報を使用して、リソース使用状況に応じてクライアントに請求を行うこともできる。さらに、ある時間帯に到着した１組のリクエストによって生成された負荷をモニタすることによって、価値のある情報を獲得することができる。こうした情報を収集して、システムを微調整し、またより良い方針を立案することができる。

ロード・ディストリビュータＬＤ−ｎは、ＶＳＦシステムの以下のコンポーネントと相互に情報交換して、上で列挙したそのすべてのタスクを実施する。

レベル１・ロード・アグレゲータ
ＬＤ−ｎは、レベル１・ロード・アグレゲータにＳ_ｊｋを送信し、レベル１・ロード・アグレゲータからＬ_ｊｋと各クライアントのインスタンスの可用性ステータスとを受信する。

リソース・マネージャ
ＬＤ−ｎは、リソース・マネージャ１５０から以下の点に関するメッセージを受信する。
・既存インスタンスのシャットダウン。
・インスタンスの生成、クライアント毎のインスタンスへの割当て容量。
・クライアント毎のインスタンスへの割当て容量の変更。
・新しい割当てに変更するための「プラン切替え」メッセージ。

リソース・クラスｉのサブファームのロード・ディストリビュータをＬＤ−ｎとする。０からＴ_ｕの間の値をとるタイマをｔとする。ｔはシステム・クロックに基づいて増加する。タイマはロード・ディストリビュータのローカル・タイマである。開始時およびサブファーム生成中は、すべてのクライアントについての各インスタンスのＳ_ｊｋおよびＬ_ｊｋは、０であると仮定する。クライアントｋ毎の各インスタンスｊのＨ_ｊｋは、リソース・マネージャから受信した値に初期化される。ｔは０に初期化される。ＬＤ−ｎは、リソース・マネージャ１５０によって通知された、クライアント毎の各インスタンスの割当てＨ_ｊｋに基づいて、受信リクエストの転送を開始する。

アグレゲータ
アグレゲータ１２０は、モニタ・エージェントから負荷情報を収集し、効果的な判断を行うために様々なレベルでそれを統合する。図３には、統合データのフローを処理する方法が概略的に示されている。図３を参照すると、アグレゲータ１２０は、以下のサブコンポーネントから構成されている。

レベル１・アグレゲータ３２２は、ロード・モニタ１３０（Ｒ１、Ｒ２、Ｒ３）から負荷情報（各アプリケーション・インスタンス毎の現在の受信ヒット率、および各アプリケーション・インスタンスによる現在のリソース消費を表すｋ個１組のリソース使用状況）を受け取り、その情報をユーザ単位かつリソース・クラス単位に統合する。アグレゲータ１２０は、以下に与える式を用いて、以下のパラメータを計算する。

・新ヒット率：特定ユーザ、特定リソース・クラスの各インスタンスのヒット率を合計することによって獲得した、ユーザ単位かつリソース・クラス単位に統合したヒット率。レベル１・アグレゲータ３２２は、この情報をレベル２ａ・アグレゲータ３２４に送信する。

・新ヒット加重値：各リソース・クラスのインスタンス毎のヒットの重み。レベル１・アグレゲータ３２２は、この情報を対応するヒット率とともに、レベル２ｂ・アグレゲータ３２６に送信する。

・負荷率：各リソース・クラスのインスタンス毎の消費された割当てリソースの割合。この情報は、ロード・ディストリビュータ１１０に送信される。

ヒットの重み＝ｍａｘ．（“_ｉ（実際に処理したヒット数に対するリソース使用率_ｉ）／（参考ヒットに対するリソース使用率_ｉ×実際に処理したヒット数））。ただし、ｉは、ＣＰＵ、メモリなどのｋ個の要素を含む組。

負荷率＝（処理したヒットの数×現在のヒットの重み）／（実際の割当てヒット×割当てヒットの重み）

参考ヒットによるあるマシン上の特定リソースのリソース使用率（先に述べたように、ＣＰＵ、メモリなどのｋ個の要素を含む組）は、コンフィグレーション・リポジトリ１６０に格納されたベンチマーキング情報から取得される。これに加えて、各リソース・インスタンスに割り当てたヒットの数および割り当てた重みも、コンフィグレーション・リポジトリ１６０から読み取られる。

レベル２・アグレゲータ３２４、３２６は、レベル１・アグレゲータ３２２から統合された負荷情報を受け取り、ユーザの各リソース・クラスについてのリソース要件の変化を計算し、それを要求としてグローバル・ディシジョン・メーカ１４０に送信する。新しいリソース要件が現在の割当てと異なり、クライアントのＳＬＡに適合している場合、変更が要求される。ユーザのこれらの要求は、参考ヒット数の（増減の）形で送信される。

先に述べたように、要求は、各クライアント毎、そのクライアントのアプリケーションを構成しているリソース・クラス毎に送信される。これらの要求は、２種類のリクエストから構成される。第１のタイプの要求は、リソース・クラスの受信ヒット率に変化があり、この変化に対応するためにシステムがリソース割当ての調整を必要としたときに発生する。これらの要求は、レベル２ａ・アグレゲータ３２４によって、識別され、検証され、生成される。レベル２ａ・アグレゲータ３２４は、図３において、グローバル・ディシジョン・メーカ１４０と対比させて、ローカル・ディシジョン・メーカと呼ばれる。

（訂正率と呼ばれる）第２のタイプの要求は、受信ヒットの重みが参考ヒットと異なり、変化を反映させてリソース割当てを訂正する必要があるときに、生成する必要がある。これらの要求は、レベル２ｂ・アグレゲータ３２６によって、識別され、生成される。

レベル２ａ・アグレゲータ３２４は、クライアントについての各リソース・クラスの現在のヒット率を表す負荷情報の一部を受け取る。この情報と（コンフィグレーション・リポジトリ１６０から取得した）現在のリソース割当て情報とに基づいて、アグレゲータ１２０は、クライアントに対する割当て（割当て無しの場合あり）をどう変更する必要があるか計算する。

図４は、新しいリソース要求を計算するのに使用されるアルゴリズムのフローチャートである。このアルゴリズムでは、クライアントが異なれば異なることがある４つのコンフィグレーション・パラメータ（α、β、γ、δ）を使用する。パラメータαは、過負荷トリガを表す。すなわち、クライアントの作業負荷が、現在の割当てに係数αを乗じた値に達した場合、βで表される増分量がそのクライアントのために要求される。パラメータγおよびδは、対応する過少負荷パラメータである。これらのパラメータα、β、γ、δは、定数であるか、または現在の負荷、現在の割当て、およびＳＬＡの制限の関数であるが、いずれの場合も、それらはシステム・パフォーマンスが向上するように調整することができる。しかし、βを計算した後、アグレゲータは、割当ての要求された増分がクライアントのＳＬＡに適合していることを検証し、適合している場合にだけ、その要求をグローバル・ディシジョン・メーカ１４０に送信する。

同様に、変化がマイナスである場合、すなわち、割当てを減少させる場合、アグレゲータは、その減少がＳＬＡ毎に定めたリソース割当ての最小レベルを下回らないことをチェックする必要がある。

図４のアルゴリズムの流れは、上で概説したように単純である。ステップ４１０で、現在の負荷が、現在の割当てにパラメータαを乗じた値と比較される。現在の負荷の方が小さい場合、ステップ４２０で、現在の負荷が、現在の割当てにパラメータγを乗じた値より小さいかどうかチェックされる。それぞれの場合において、現在の負荷の方が大きい場合、また現在の負荷の方が小さい場合、現在の負荷が、最小リソース要件と最大リソース要件の間にあるかどうかが、ステップ４３０、４４０でそれぞれチェックされる。

現在の負荷が、現在の割当てにパラメータαを乗じた値より大きく、このリソース要件範囲の外にある場合、ステップ４５０で、現在の負荷が、最小リソース要件に同じパラメータαを乗じた値より大きいかどうかチェックされる。大きい場合、新しい割当てが、最大リソース割当てと現在の割当てにパラメータβを加算した値のうち小さい方に決まる。ステップ４３０で、現在の負荷が、リソース要件の範囲内にあった場合、新しい割当てはやはり、最大リソース割当てと現在の割当てにパラメータβを加算した値のうち小さい方に決まる。

同様に、現在の負荷が、現在の割当てにパラメータγを乗じた値より小さく、リソース要件範囲の外にある場合、ステップ４６０で、現在の負荷が、最大リソース要件に同じパラメータγを乗じた値より大きいかどうかチェックされる。大きい場合、新しい割当てが、最小リソース割当てと現在の割当てからパラメータδを減算した値のうち大きい方に決まる。ステップ４４０で、現在の負荷が、リソース要件の範囲内にあった場合、新しい割当てはやはり、最小リソース割当てと現在の割当てからパラメータδを減算した値のうち大きい方に決まる。

そうではなくて、ステップ４５０または４６０で、（ｉ）現在の割当てが、最小リソース割当てにパラメータαを乗じた値より大きいこと（ステップ４５０）、または（ｉｉ）現在の割当てが、最大リソース要件にパラメータγを乗じた値より大きいこと（ステップ４６０）が分った場合、単に最小リソース要件が新しい割当てになる。

さらに、要件の変化が、クライアント・アプリケーションのフロントエンドとして動作するリソース・クラスに対応する場合、この要求はアプリケーション・レベルの要求であり、異なる扱いを受ける。言い換えると、こうしたリクエストは、クライアント・アプリケーションのすべてのリソース・クラス毎の適切なヒット数から成る複合リクエストに変換される。根底にあるリソース・クラスに対応するヒット要求を計算するために、アグレゲータは、そのクライアントに関する、そのアプリケーションのリソース・クラス毎の現在の対応率を計算する。

アプリケーションの対応率は、そのアプリケーションのフロントエンド・リソース・クラスに到着した各ヒットについて、根底にあるリソース・クラスで生成される参考ヒットの数を指定する。この情報は、クライアントに関する、各リソース・クラス毎の現在のヒット率を取得し、その値を比較することによって、計算することができる。システム初期化時に、この比率はベンチマーキング情報から取得され、コンフィグレーション・リポジトリに格納される。新たに計算した比率に著しい変化があった場合、コンフィグレーション・リポジトリ中の古い値は、新しい値で上書きされる。アグレゲータは、構成比率を取得した後、その比率を使用して、そのアプリケーションのすべてのリソース・クラスについて、適切なリソース要求を生成する。

レベル２ｂ・アグレゲータ３２６は、各クライアントの各リソース・クラス・インスタンス毎に、参考ヒットで表した訂正率を計算する。レベル２ｂ・アグレゲータ３２６は、各リソース・クラス・インスタンス毎に、現在のヒット率を対応する重みとともに、レベル１・アグレゲータから受信する。アグレゲータ１２０は、コンフィグレーション・リポジトリ１６０から前のヒット加重値を取得し、以下に示す式を用いて訂正率を計算する。

訂正率＝（新ヒット加重値−前のヒット加重値）×割り当てられた参考ヒット数

各クライアントの各リソース・クラス毎のすべてのインスタンスについて、これらの訂正率を統合することによって、要求の全体的な変化も計算される。これらの要求は、各リソース・クラス・インスタンスについての、現在の割当て、現在のヒット加重値、訂正率とともに、グローバル・ディシジョン・メーカ１４０に転送される。

ロード・ディストリビュータ
ロード・ディストリビュータ１１０は、転送されて来たリクエストを、リクエストのクライアント識別情報に従って、適切なアプリケーション・インスタンスにマッピングする。サブファームのインスタンスによって生成されたリクエストは、次のレベルのロード・ディストリビュータによって、次のレベルのサブファームの１つに転送される。

図５には、受信リクエストがいかに分配されるかが概略的に示されている。図５に示すように、受信リクエストは、レベル１・ロード・ディストリビュータ５１２で受信される。これらのリクエストは、レベル１・ロード・ディストリビュータ５１２によって、例えば、インスタンス１、２、３（５２２、５２４、５２６）をホストする、リソース・クラス１のサブファーム１（５４０）に分配される。リクエストは、リソース・クラス１のサブファーム１（５４０）で処理された後、レベル２・ロード・ディストリビュータ（５１４）に送られる。これらのリクエストは次に、レベル２・ロード・ディストリビュータ５１４によって、例えば、インスタンス１、２（５３２、５３４）をホストする、リソース・クラス２のサブファーム２（５６０）に分配される。

図６には、受信リクエストの流れが概略的に示されている。図６では、クライアントＣに属するリクエストＲを、ＬＤ−１（６１０）が受信するものとする。リクエストＲは、サブファームＳ１（６１２）内のクライアントＣに属する最も負荷の軽いインスタンスＩに転送される。リクエストＲを処理した後、インスタンスＩは、次の階層のリソース宛ての内部リクエストを生成することができる。サブファームＳ２（６２２）の一部を、次の階層のリソースのインスタンスとする。そのようなリクエストは、ＬＤ−２（６２０）（すなわち、ＬＤ−１（６１０）の次のレベルのディストリビュータ）によって、サブファームＳ２（６２２）内のクライアントＣについての第２層リソースのインスタンスのうち最も負荷の軽いインスタンスに転送される。図６に示すように、リクエストはこのようにして、その他のロード・ディストリビュータＬＤ−４（６４０）、ＬＤ−５（６５０）に送られ、そこからそれぞれ、サブファームＳ４（６４２）、サブファームＳ５（６５２）内のクライアントＣに属する最も負荷の軽いインスタンスに送られる。

ロード・ディストリビュータ１１０は、ヒット率の計算に関する単位時間間隔Ｔ_ｕを有する。また受信リクエストに関するＦＩＦＯキューも有する。各ロード・ディストリビュータは、２つの２次元テーブル、すなわち、各行がサブファーム内のリソース・インスタンスに対応し、各列がクライアントに対応するテーブルも有する。一方のテーブルは、グローバル・ディシジョン・メーカ１４０によるリソース割当てに関して静的であり、ＲＡＴ（リソース・アロケーション・テーブル）と呼ばれる。もう一方のテーブルは動的であり、ＲＣＴ（リソース消費テーブル）と呼ばれる。Ｈ_ｊｋ、すなわち、時間間隔Ｔ_ｕの間に、クライアントｋの第ｊインスタンスによって処理される割当てヒットが、ＲＡＴのエントリである。（Ｓ_ｊｋ，Ｌ_ｊｋ）が、ＲＣＴのエントリである。Ｓ_ｊｋは、現在の時間間隔Ｔ_ｕの間に、クライアントｋの第ｊインスタンス宛てに送られたヒットの数である。Ｌ_ｊｋは、現在の時間間隔Ｔ_ｕの間の、クライアントｋの第ｊインスタンスの負荷情報（負荷率）である。

ロード・ディストリビュータＬＤ−ｎによって実行される、ヒットをベスト・エフォート方式でインスタンス間に分配するタスクについて、以下で説明する。

・ロード・ディストリビュータは、受信した各リクエスト毎に、最小負荷インスタンスｍを見つけ、そこにヒットを転送する。

・現在の時間間隔の間にあるインスタンスに転送したヒット数をクライアント単位に追跡し、この情報をレベル１・アグレゲータに送信する。

・障害を起したインスタンスをＲＡＴとＲＣＴから削除する。

・リソース・マネージャによって新しいリソース割当てプランが実施された時、インスタンス毎に割当て容量を更新し、新しい割当てに従ったリクエストの転送を開始する。

・シャットダウンしたインスタンスへのリクエストの転送を中止し、新しく生成されたインスタンスへのリクエストの転送を開始する。

・リクエストＦＩＦＯキューが空ではない場合、キューの先頭のリクエストを処理（転送／削除）する。

グローバル・ディシジョン・メーカ
グローバル・ディシジョン・メーカ１４０は、現在のシステム状態をクライアントのＳＬＡとともに入力として取得し、新しいリソース割当てプランを出力として生成する、システム・コンポーネントである。グローバル・ディシジョン・メーカ１４０は、以下の情報を入力として受け取る。

・レベル２ａ・アグレゲータ３２４によって維持管理される単位出力バッファからの、参考ヒットで表したリソース要求。当該サイクルにおいて、＜リソース・クラス，クライアント＞の組についての要求が存在しない場合、出力バッファは古い値（古いことはフラグで示される）を含んでおり、無視される。

・レベル２ｂ・アグレゲータ３２６によって維持管理される単位出力バッファからの、参考ヒットで表した訂正率要求。上記の場合と同様に、入力が前のサイクルに属する場合、その入力は無視される。

・対応率。システム初期化時、クライアントのベンチマーキング情報によって、クライアントが使用するリソース・クラス間で相互依存関係がある場合に、対応率が定義される。この比率は、リソース割当ての際に使用される。アプリケーションが特定のリソース・クラスに対する要求を承認されていない場合、そのアプリケーションのその他のリソース・クラスの対応するリソースを確保しておいても意味はないので、これは重要である。この比率は時間につれて著しく変動することがある。その値はアグレゲータによって更新され、コンフィグレーション・リポジトリに格納される。グローバル・ディシジョン・メーカ１４０は、この値をコンフィグレーション・リポジトリ１６０から読み取る。

・その他のクライアント固有のアプリケーション情報（コンフィグレーション・リポジトリ１６０から取得）。

・割り当てられる各リソース・クラスの最小および最大量（ＳＬＡから取得。０も可能）。

・あるクライアントについて、あるリソース・クラスで許容されているインスタンスの最大数。

・あるリソース・クラスの新しいインスタンスを開始する際のコスト、または既存インスタンスをシャットダウンする際のコストを表す数（正数、０、負数が可能）。

・あるマシンから別のマシンへ、あるリソース・インスタンスを移動させる際のコストを表す数。

・インフラストラクチャ情報（コンフィグレーション・リポジトリ１６０から取得）。

・各リソース・クラスで使用可能なマシンの抽象的識別情報（名前）、それらのマシンの中で、各クライアントが使用可能なマシン。

・リソース・クラスに関する各マシンの容量。これは、Ｏ／Ｓのオーバヘッドおよびアプリケーションのオーバヘッドを明らかにし、負荷の短時間の変動に対処するための事前定義された予備の容量を差し引いた後に算出される。

・それら各マシン上で許容されるインスタンスの数の限度（限度がある場合）。

・実ヒット率で表した、ファーム内のマシン上での各クライアントの既存割当て。これらとともにヒット加重値も供給される。この２つの積によって、参考ヒットで表した割当てが与えられる。

・クライアントのＳＬＡからの請求情報。これには、ＳＬＡが遵守されなかった様々な場合に支払われる違約金が含まれる。

システム障害は（発生した場合は）、マシン容量を減少させる（０になる場合もある）。グローバル・ディシジョン・メーカ１４０は、そうした障害による使用可能容量の減少がコンフィグレーション・リポジトリ１６０に反映されていると仮定する。

ＧＤＭソルバ・アルゴリズムが、上記の要求に応じて、負荷のマシンへの割当てを決定する。ホスティング・コストは、システムの混合整数線形計画法モデルを用いて最小限に抑えられる。線形モデルについて説明し、その後でこのモデルの解法について説明する。

線形計画法モデル
（線形計画法を使用した）モデルの目的は、様々なリソース・クラスにおいて、マシンの供給をクライアントの要求に合致させることである。複数のタイプのマシンと異なる金額を支払うクライアントとがあると仮定すると、モデルは、収入が最大になるように供給と要求を合致させる（線形計画法の分野における）輸送問題となる。主として、各マシンを単一のリソース・クラスに割り当てるという要件によって、複雑さが増す。

余分な割当ては無駄になるので、たかだか要求される容量が供給されるだけである（式（２）参照）。また、システムが十分な容量を有していない場合、優先度が最低のクライアントによる要求の一部を削除することができる。

供給制約（以下の式（３、４）参照）は２つの制約に変更される。一方の制約は、１つのリソース・クラスを各マシンに割り当てる。もう一方の制約は、そのリソース・クラスの要求のみをそれに割り付けることを可能にする。

１つのマシン上に存在することができるクライアントの数と、１つのリソース・クラスに関する１つのクライアントの要件が分散されるマシンの数とによって、制限がモデル化される。最初の制限は、多数のクライアントを単一のマシン上でサポートすることから生じるオーバヘッドを制限する。第２の制限を使用するのは、クライアントが分散されるマシンの数が増加するにつれて、複数インスタンスの管理がより難しくなるためである（式（５、６）参照）。

次の制約は、異なるリソース・クラスのリソースに対する要件が互いに依存している場合（例えば、あるリソース・クラスが別のリソース・クラスを呼び出している場合）、割り当てられる量が比率で表されることを保証する（式（７）参照）。線形モデルは正確なモデルではないが、２つのリソース間の実際の依存関係を近似する。

モデルを試験してみると、すべてのクライアントの最小要求を満たすだけのリソースが十分ある限り、この問題には常に実現可能な解があることが明らかになる。式（７）を満たすために、関連するリソース・クラスへの割当ては、ボトルネックとなるリソース・クラスが使用可能な容量に従って減らされる。

最後に、クライアントに約束されたＳＬＡに従う各クライアントの最小要件が常に満たされるという制約（式（８）参照）。マシンは常に、この制約の実現可能性を保証するのに十分なだけ供給されるが、大規模なシステム障害の場合は、この制約は守られないこともある。最小要件もまた対応率の形で表さなければならない。

以下のコスト・モデルを最適化しながら、上記モデルについて、実現可能な割当てが決められる。

第１に、クライアントは、ＳＬＡ、使用マシン、および利用リソース・クラスに応じた使用リソース単位（単位は参考ヒット）で請求される。請求は、その時点でクライアントに該当する使用「範囲」によっても左右される。例えば、請求単位が請求周期内でのヒットの全数である場合、最初のＡ個の単位には次のＡ個の単位よりも低い料率がかけられ、その後の単位も同様であることもある（以下の式（１）の第１項参照）。また、請求に参考ヒットのヒット加重値に従った重み付けを施して、クライアントがヒットに支払う実際の金額に反映させることもできる。

第２に、クライアントを追加するシステム・コスト（セットアップ・コスト）とクライアントをマシンから削除するシステム・コスト（「クリーニング」・コスト）がある（式（１）の第２項参照）。

第３に、あるリソース・クラスについて、クライアントのインスタンスの数が増えるにつれて、システムがデータ一貫性を管理するのに要するコストが大きくなる（式（１）の第３項参照）。

最後に、システムがシステム障害など何らかの理由でクライアントの最小要件を処理できない場合にかかる違約金がある。すべてのクライアントの最小要求を満たすだけのリソースが十分にない場合にのみ、モデルに違約金が追加され、その場合、この制約（式（８））は取り除かれ、この制約を外し代りに違約金を加えてモデルが再度解かれる。線形計画法に違約金を取り込んだ標準モデルがあるが、そのモデルは話を簡単にするため省略する（例えば［１２］参照）。

詳細にモデルを説明するには、いくつかの表記を使用する必要がある。以下の文字は、変数（その値が求められる）、またはＧＤＭソルバへの入力（システムについてのデータ）を表すことができる。添字ｉ、ｊ、ｋはそれぞれ、１からＮ_ｉ、Ｎ_ｊ、Ｎ_ｋまでのすべての整数値をとり、システム上のクライアントの全数をＮ_ｉ、リソース・クラスの全数をＮ_ｊ、マシンの全数をＮ_ｋとする。

明確にするため、以下に入力を示す。
Ａ_ｉｊｋ：現在の割当て。
Ｃ_ｊｊ’：対応率。
Ｄ_ｉｊ：要求。
Ｌ_ｊｋ：ｍａｘ．あるマシン上のクライアント数。
Ｍ_ｉｊ：ｍａｘ．あるクライアントが存在するマシンの数。
Ｍｉｎ_ｉｊ：要求。
Ｎ_ｉ：クライアント数。
Ｎ_ｊ：リソース・クラス数。
Ｎ_ｋ：マシン数。
Ｐ_ｉｊｋ：請求金額。
Ｓ_ｊｋ：リソース・クラス毎のマシン容量。
Ｔ_ｉｊｋ：インスタンスの追加または削除についての違約金。
Ｕ_ｉｊ：インスタンス数についての違約金。
Ｖ_ｉｊｋ：ヒット加重値要求。
Ｙ_ｉｊｋ：現在マシン上にあるインスタンス。

以下に変数を示す。
Ｂ_ｉｊｋ：クライアントへの割当て。
Ｚ_ｉｊｋ：マシン上のインスタンスの割当て。
Ｒ_ｊｋ：リソース・クラスへのマシンの割当て。

Ｄ_ｉｊを、クライアントｉによるリソース・クラスｊ宛てのすべての要求とする。Ｄ_ｉｊは、特定クライアントについての最大許容負荷を超える分を除外した、参考ヒット単位で表したアグレゲータ２ａ、２ｂからの要求の総和である。Ｄ_ｉｊは、リソース割当ての減少に関するリクエストである場合には、負数であることもある。コンフィグレーション・リポジトリから、リソース・クラスｊ上、マシンｋ上のクライアントｉについて、Ａ_ｉｊｋ、すなわち、参考ヒットで表した現在の割当てを取得する。これを解いて、最終的な割当てＢ_ｉｊｋを求める。

Ｐ_ｉｊｋは、クライアントｉとリソース・クラスｊとマシンｋとの組合せに割り付けられたリソースＢ_ｉｊｋの単位分当たりの請求総額を表すものとする。クライアントを追加または削除するシステム・コストはともに、こうした各変化毎に、料率Ｔ_ｉｊｋで請求される。Ｕ_ｉｊは、これらのインスタンス間で一貫性を維持するためのシステム・コストを表すものとする。
（１） Maximize S_iS_jS_k(P_ij×B_ijk)-S_iS_jS_kT_ijk×|Y_ijk-Z_ijk|-S_iS_j(U_ij×S_kZ_ijk)

ここで、｛０，１｝内のＹ_ｉｊｋは、Ａ_ｉｊｋ＞０かどうかを表し、｛０，１｝内のＺ_ｉｊｋは、Ｂ_ｉｊｋ＞０かどうかを表す。Ｓ_ｊｋは、リソース・クラスｊについてのマシンｋの容量、すなわち、そのマシンがサポートできるリソース・クラスｊの参考ヒットの数を表すものとする。第２式だけが制約となる以下の式が得られる。
Y_ijk>=A_ijk/S_jk,Z_ijk>=B_ijk/S_jk

要求制約は以下のようになる。
（２） S_k B_ijk<=S_kA_ijk+D_ij、すべてのｉ、ｊについて。

各マシンｋは、第ｊリソース・クラスの容量Ｓ_ｊｋに関して、その容量を超えて割り当てることはできない。｛０，１｝内の変数Ｒ_ｊｋは、リソース・クラスｊがマシンｋ上に存在するかどうかを表す。
（３） S_i B_ijk<=S_jk×R_jk、すべてのｊ、ｋについて。

１つのマシン上には、ただ１つのリソース・クラスの存在が許される。
（４） S_j R_jk<=1、すべてのｋについて。

各マシン上のインスタンスの数には限度Ｌ_ｊｋがある。
（５） S_i Z_ijk<=L_jk、すべてのｊ、ｋについて。

所与のリソース・クラスに関して、各クライアント毎のインスタンスの数には別の限度Ｍ_ｉｊがある。
（６） S_k Z_ijk<=M_ij、すべてのｉ、ｊについて。

Ｃ_ｊｊ’は、対応率（リソース・クラスｊ’の使用量とリソース・クラスｊの使用量との比率として先に定義）を表すものとする。割当てが対応率Ｃ_ｊｊ’に対応することを保証するために、以下の式を満たすものとする。
（７） S_k B_ij’k=C_jj’×S_kB_ijk、依存関係にあるすべてのｊ、ｊ’について。

各クライアントには最小量を割り当てなければならない。
（８） S_k B_ijk>=Min_ij、すべてのｉ、ｊについて。

上記の制約に加えて、変数の数を減らすために、以下の単純化を施すことができる。あるクライアントとリソースの組合せは、特定の１組のマシン上にのみ存在する。上記の組の中にないすべてのｋ’マシンについて、対応するＢ_ｉｊｋ’を削除する。また、１つの特定のリソース・クラスに割り当てられたすべてのマシンｋ’について、対応するＲ_ｊｋ’を１に設定し、ｋ’と等しくないｋについての、その他のＲ_ｊｋを０に設定する。

式（８）中の以下の最小値を求めるために、上記の問題を最初に解く。
Min_ij=maximum（ＳＬＡで指定される最小値，（S_kA_ijk+S_k V_ijk））、ただし、（S_k A_ijk+S_kV_ijk）は、現在の割当てと、やはり参考ヒットによって指定されるそれに対応するヒット加重値要求Ｖ_ｉｊｋとの総和を表す。システム内の既存の割当ては維持されるので、このオプションによってすべてのクライアントへのより高い品質のサービスがサポートされる。これが実現可能でない場合、元の式（８）によって置き換える。それが実現不能である場合、先に述べたように、最小リソース要件が満たされないので、制約を違約金によって置き換える。

上記の問題は一般に、厳密に解くのは困難である。しかし、上記の問題に対する近似解を効果的に生成することのできる、標準的な線形計画法の技法、問題線形計画リラクゼーション（problem linear programming relaxation）、切除平面法、分岐限定法、カラム生成技法（columngeneration technique）が存在する。単純な発見的手続きで、線形計画リラクゼーションによって解を生成し、次に、整数変数を丸められた（しかし、実現可能な）値に設定した後、単純化した問題を再度解く。前処理モジュールの追加によって、解法が高速化するように、余分な変数、制約を取り除くことができる。解法プロセスは、その時までに得られた最良の解を求めるための短い時間の後、停止させられる。

新しい割当てプランを取得した後、リソース・マネージャは、新しい割当てを実行するよう指示される。グローバル・ディシジョン・メーカ１４０がリソース・マネージャ１５０に渡す情報は、マシン上での現在のヒット加重値を伴った、仮想サーバ・ファーム内のマシン上でのリソース割当てに関するクライアント単位のリストから構成される。これらの割当ては、参考ヒットの形で指定される。実行が成功すると、リソース・マネージャ１５０は、（参考ヒットで表した割当てを対応するヒット加重値で除算することによって取得される）処理可能な実際のヒットの形による新しい割当て値で、コンフィグレーション・リポジトリ１６０を更新する。ヒット加重値の値も更新される。

リソース・マネージャ
リソース・マネージャ・エージェント（ＲＭエージェント）を、マシンをブート・アップしたときに自動的に開始するプログラムとして、サーバ・ファームの各マシン上にインストールする。ＲＭエージェントは、リソース・マネージャ１５０だけが、そのマシン上のリソース・インスタンスを管理するために使用することができるインタフェースを提供する。ファーム内で使用可能なリソースの各タイプについて、低レベルのstartupコマンドとshutdownコマンドの適切な１組が、ファームのコンフィグレーション・リポジトリ１６０に登録される。サブファームの各マシンは、１つのタイプのリソースをホストするだけなので、ＲＭエージェントは、１組のstartupコマンドとshutdownコマンドについて知りさえすればよい。ＲＭエージェントは、そのマシン上でホストされるリソースのタイプを知ると、コンフィグレーション・リポジトリ１６０に問い合せて、適切なコマンドを取得する。これを行った後、エージェントはそのロケーションをコンフィグレーション・リポジトリ１６０に登録して、リソース・マネージャ１５０が必要なときにエージェントと通信が行えるようにする。

サブファーム内のマシンは、リソースの複数のインスタンスをホストすることができる。各インスタンスには、そのマシン上で一意の識別子（instanceID）が与えられる。これは、単にオペレーティング・システムのプロセス識別子（pid）をインスタンスＩＤとして使用することで、実施することができる。各インスタンスは、複数のクライアントからのヒットをサポートすることができ、そのインスタンス上で、各クライアントには、それぞれ異なる最大ヒット率を割り当てることができる。したがって、マシンのＲＭエージェントは、クライアント毎のこれらのヒット率割当てを含むテーブルを、各インスタンス毎に維持管理する。エージェントは、以下の抽象インタフェースをＲＭに提示する。

startup() returns instanceID
このstartup()コマンドは、そのマシン上でリソースのインスタンスを開始し、それにＩＤを割り当てるようエージェントに要求する。

shutdown(instanceID)
このshutdown()コマンドは、指定されたリソース・インスタンスをシャットダウンするようエージェントに要求する。

setAllocation(instanceID,clientName,hitRate)
このsetAllocation()コマンドは、指定されたインスタンスについて、ヒット率で表したクライアントのリソース割当てを設定する。

これらの動作のいずれかが要求されたとき、エージェントはその動作の実行を試み、それが成功したか失敗したかについてリソース・マネージャ１５０に報告する。これらの動作各々の実施について以下で詳しく説明する。

リソース・マネージャ１５０は、グローバル・ディシジョン・メーカ１４０によって作成された割当てプランを実施するために、エージェントの動作、さらには仮想サーバ・ファームの他のコンポーネントを調整する中央エンティティである。リソース・マネージャ１５０は、割当ての２つのコピー、すなわち、ファームの現在の状態を反映している現在プランと、グローバル・ディシジョン・メーカ１４０によって提供された新プランとを維持管理する。ファームの起動時、現在プランは、どのクライアントにもリソースが割り当てられていないことを表すように初期化される。リソース・マネージャ１５０は始動すると、グローバル・ディシジョン・メーカ１４０の出力バッファを検査して、新しい割当てプランが生成されたかどうか判断する。生成されていない場合、リソース・マネージャ１５０は、そのようなプランが入手できるようになるまで、単に待機する。

グローバル・ディシジョン・メーカ１４０の割当てプランは、３次元テーブルの形で定義される。各クライアント毎に、プランは、クライアントが必要とするすべてのリソース・クラスの各インスタンスの更新された割当てを列挙する。割当ては通常通り、ヒット率の形で表現される。グローバル・ディシジョン・メーカ１４０は、新プランの生成を完了すると、リソース・マネージャ１５０を呼び出し、実施すべきプランをパラメータとして供給する。次にリソース・マネージャ１５０は、３次元のプラン・テーブルをリソース・インスタンス軸に沿って調べる。リソース・マネージャ１５０は、各リソース・インスタンスについて、各クライアント毎の現在の割当てを新しい割当てと比較する。いくつかのケースが考えられる。
Ｉ．現在の割当てと新しい割当てが等しいケース。
Ｉ．現在の割当てが０で、新しい割当てが非０のケース。
Ｉ．現在の割当てが非０で、新しい割当てが０のケース。
Ｉ．現在の割当てと新しい割当てが共に非０で、現在の割当てと新しい割当てが等しくないケース。

ケースＩ
リソース・マネージャ１５０は、どんな動作も行う必要がない。

ケースＩＩ
新しいリソース・インスタンスがまだ存在していない場合、すなわち、そのインスタンスに関して他のすべてのクライアントも現時点での割当てが０である場合、新しいリソース・インスタンスを生成しなければならない。リソース・マネージャ１５０は、ＲＭエージェント上でstartup()動作を呼び出す。リソース・マネージャ１５０は、コンフィグレーション・リポジトリ１６０においてエージェントのアドレスを検索して、適切なエージェントを探し出す。エージェントは、リソースのstartupスクリプトを用いてインスタンスを生成することによって応答する。各インスタンスは、関連するモニタをもたなければならない。したがって、ＲＭエージェントは、新しいモニタを生成し、またはそのマシン上の既存モニタに新しいインスタンスをモニタする任務を割り当てる。ＲＭエージェントは、これらのタスクを正常に完了した場合、肯定応答メッセージをリソース・マネージャ１５０に送信し、次にリソース・マネージャ１５０は、エージェントのsetAllocation動作を使用して、クライアントのヒット率割当てを新しい値に初期化する。次にＲＭエージェントは、そのサブファームのロード・ディストリビュータ１１０にメッセージを送信して、新しいインスタンスの生成を通知し、ロード・ディストリビュータ１１０が受信リクエストを処理できるようにする。

ケースＩＩＩ
リソース・インスタンスがもはや必要でない場合、すなわち、そのインスタンスに関して他のすべてのクライアントも割当てが０に減少した場合、そのインスタンスを破棄しなければならない。リソース・マネージャ１５０は、適切なＲＭエージェント上で、インスタンスＩＤを与えてshutdown動作を呼び出す。エージェントは最初に、そのリソース・インスタンスがもはや使用できないことをサブファームのロード・ディストリビュータ１１０に通知し、それ以降のヒットがそのインスタンスに転送されることがないようにする。次にエージェントは、リソースのshutdownスクリプトを用いてそのインスタンスを破棄し、関連するモニタを無効にし、そのインスタンスに属する内部データ・テーブルを削除する。リソース・クラスによって提供されるshutdownスクリプトは、インスタンスを直ちに破棄する必要はない。インスタンスは、すでに受信したリクエストの処理は続行し、さらなる受信リクエストは拒絶することができる。保留中だったリクエストを処理し終えた後で、インスタンスは自らを完全にシャットダウンすることができる。

ケースＩＶ
リソース・インスタンスの割当てを変更する必要がある。リソース・マネージャ１５０は、ＲＭエージェント上でsetAllocation動作を使用して、これを実現する。エージェントは、新しい最大ヒット率を示すように、その内部テーブルを更新する。エージェントはこの割当てを実施する必要がある。この目的のために、エージェントは、メッセージをサブファームのロード・ディストリビュータ１１０に送信して、リソース・インスタンス上のクライアントについての新しい割当てを通知する。ロード・ディストリビュータ１１０は、この割り当てられた限度を超えたリソースの使用を防止するために、クライアントの受信リクエストを抑制する任務を担う。このケースには特殊なサブケースが存在する。

ケースＩＶ−Ａ
このケースでは、新しい割当て＞現在の割当て、すなわち、割当てが増加する。一般に、グローバル・ディシジョン・メーカ１４０が特定のインスタンスの割当てを増やす場合、そのクライアントのアプリケーションが必要とするその他のリソース・クラスの割当ても増やす必要がある。第ｎ層のリソース・インスタンスを増加させる際にそれと対応する第（ｎ＋１）層を増加させないと増加の効果はなく、第（ｎ＋１）層のインスタンスが併せて拡張されるまで、超過リクエストが抑制されるだけである。各エージェントへのメッセージ送信に関係する予期せぬ遅延のため、ケースＩＶ−Ａでは、ロード・ディストリビュータ１１０は、このインスタンスの使用を直ちに増やすことができない。ロード・ディストリビュータ１１０は、依存するすべてのリソース・インスタンスもメッセージを受信するまで、待機しなければならない。したがって、ＲＭエージェントは、肯定応答メッセージをリソース・マネージャ１５０に送信する必要があり、リソース・マネージャ１５０は、効果的にバリア同期（barrier synchronization）を実施する。インスタンスが拡張されたことをすべてのエージェントが確認した後で、リソース・マネージャは、すべてのロード・ディストリビュータ１１０宛てに「プラン切替え」メッセージを発行する。ロード・ディストリビュータ１１０は、このメッセージを受信したときに、新しい増加された割当てへの切替えを実行することができる。

さらに、オペレーティング・システム・レベルの機構が、クライアント間でのマシン区画化に使用できる場合、ＲＭエージェントはその機構とのインタフェースを担当する。そのような区画化機構は一般に、ＣＰＵ使用、ディスク空間、ネットワーク帯域幅、およびその他の同様のＯＳレベルのリソースに関して各アプリケーション毎に厳格な境界を定める。これにより、アプリケーションは互いに安全に隔てられ、加えて、リソースの過剰消費が防止される。クライアントのアプリケーションが変更されると、ＲＭエージェントはそれに従って、オペレーティング・システムにマシン区画の縮小または拡張を要求する。しかし、そのような機構が使用できない場合でも、抑制に基づく独立した機構がいずれにせよ割当て限度を緩やかに定めるので、システムは機能し続ける。

ＲＭエージェントが要求された再割当てを実行した後、リソース・マネージャ１５０は、新しい割当てプランをコンフィグレーション・リポジトリ１６０に対してコミットする。

サブファームの生成および削除
リソース・マネージャ１５０は、すべてのサブファームの生成および削除も担当する。クライアントが到着し、サーバ・ファームで現在使用できないリソース・クラスの使用を要求した場合、そのリソース・クラスのインスタンスを実行するために、新しいサブファームを生成しなければならない。リソース・マネージャ１５０は、コンフィグレーション・リポジトリ１６０に問合せを行って、フリー・プール内にある当該リソース・クラスがインストールされた使用可能なマシンを見つける。次に、それらを新しいサブファームの一部として指定し、このサブファーム宛ての受信リクエストを管理するためのロード・ディストリビュータ１１０のインスタンスを生成する。この段階では、リソース・インスタンスは実際には生成されない。グローバル・ディシジョン・メーカ１４０がインスタンスに対して非０ヒット率を割り当てたとき、先に概略を述べたように、インスタンスが生成される。

ある段階で、あるサブファームにインストールされたリソース・クラスを必要とするクライアントが存在しないために、サブファームがもはや必要でなくなることもある。グローバル・ディシジョン・メーカ１４０は、そのサブファーム専用のマシンを回収して、重い負荷がかかっている他のサブファームでそれを再利用することを決定することができる。グローバル・ディシジョン・メーカ１４０は、リソース・マネージャ１５０にそのサブファームを削除するよう要求する。リソース・マネージャ１５０はそのエージェントを使用して、そのサブファーム上で動作しているすべてのリソース・インスタンス（およびそのモニタ）をシャットダウンし、次に同様にファームのロード・ディストリビュータ１１０のシャットダウン動作を呼び出す。ファームが活動停止状態になった後で、リソース・マネージャ１５０は、コンフィグレーション・リポジトリ１６０を更新して、ファーム内の各マシンのステータスを変更し、それらが再びフリー・プール内で使用可能になったことを知らせる。

ロード・ディストリビュータ１１０は、クライアントに割り当てられた特定のリソース・インスタンス間に受信ヒットを分配し、同じリソース・クラスの他のインスタンスが比較的軽負荷であるにもかかわらず、ある１つのインスタンスだけが過負荷になることがないようにする。ロード・ディストリビュータ１１０はまた、グローバル・ディシジョン・メーカ１４０によってクライアントに割り当てられた容量に従って、クライアントによる使用を制御する。同じリソース・クラスの１組のインスタンスを含む各サブファーム毎に、ロード・ディストリビュータ１１０が１つ使用される。

障害処理
本明細書で説明するモデルを実施して、サブファームのマシン障害を処理する。マシンが障害を起しているかどうか判断するために、中枢的な機構（heartbeat mechanism）が使用される。障害マシンが識別された場合、この機構はアグレゲータ１２０に通知する。アグレゲータは、障害通知を受信すると、システム管理者に通知を送る。アグレゲータは、影響を受けるロード・ディストリビュータ１１０に、ヒットを障害マシン宛てに送るのを中止するよう通知する。この情報は、通常の負荷フィードバック情報とともに、ロード・ディストリビュータに渡される。その後、ヒットを可能ならば他のマシンに送信し、いくつかの処理できないヒットを抑制するのは、ロード・ディストリビュータが担当する。

アグレゲータ１２０は、障害データをグローバル・ディシジョン・メーカ１４０に渡すように変更され、それによって、グローバル・ディシジョン・メーカ１４０は、その割当てプランから障害マシンを削除できるようになる。割当てプランの作成の前に、グローバル・ディシジョン・メーカ１４０は、マシンのフリー・プールの最新ステータスを収集し（使用可能な新しいマシンまたは新たに修理されたマシンがプールに追加されていることもある）、削除しなければならないすべての障害マシンを考慮する。

リソース・マネージャ１５０は、その新しいプラン展開の一環として、削除しなければならないマシン上のアプリケーション・インスタンスを破棄する。リソース・マネージャ１５０は、それらのマシンをシャットダウンし、システム管理者コンソールに、マシンを分離して修理してよいことを通知する。

マシン上の障害を発見するために、中枢的な機構が以下のように使用される。エージェントは周期的に、マシン上のアプリケーション・インスタンスにその可用性ステータスを要求するポーリング／pingを行う。アプリケーションは、障害を起していなければ、ある時間間隔内にこのエージェントに応答するように、機能を設け（instrumented）／ラップしなければならない。エージェントは次に、以下のような文脈依存規則に基づいて応答を照合する。マシンが障害を起している場合、アプリケーション・インスタンスはどれも応答しない。マシンが障害を起しておらず、ｘパーセント未満のアプリケーション・インスタンスが障害を起している場合、このマシンのいずれかの負荷を処理するために、ロード・ディストリビュータ１１０が使用できる代替マシンはない。マシンが障害を起しており、ｙパーセント超えるアプリケーション・インスタンスが障害を起している場合、このマシンと置き換えて使用できるマシンがフリー・プール内にある。これらの規則は互いに無関係であるか（disjoint）、マシンについて決定論的な答に到達するように明確な順序で適用される。ＸやＹのようなパラメータは、アプリケーション／文脈依存であり、その他の文脈依存情報とともに、グローバル・ディシジョン・メーカ１４０のプランがリソース・マネージャ１５０によって新たに展開されるたびに、エージェントについて新しくされる。リモート・エージェントとアプリケーション・インスタンスとの間で発生するネットワーク・トラフィックを減少させるために、リモート・エージェントを使用しないでおく（すなわち、エージェントをインスタンスと配置する）ことができる。この場合、ローカル・エージェントは、アグレゲータ１２０がローカル・エージェントを信頼できるように、（あまり長い時間を費やすことなく、すなわち、タイムアウトすることなく）その障害決定を周期的に関連するアグレゲータ１２０に通知しなければならない。ローカル・エージェントがタイムアウトした場合、関連するアグレゲータは、マシン障害およびプロセス障害の発生を相応に仮定しなければならない。すべてのアグレゲータ１２０は、共通プロセスによって実施されるので、すべてのアグレゲータはただ１つの仮定に到達し、したがって、一貫性が維持される。ローカル・エージェントを利用しない場合、リモート・エージェントは、アグレゲータとの通信コストを削減するために、アグレゲータ１２０とともに配置することができる。

中枢的な機構が障害検出のためにｐｉｎｇを行う時間間隔は、ロード・モニタがスケジュールされる時間間隔から独立させることができる。アグレゲータ１２０は、最新の障害情報を取得して、それを負荷情報とともに他のモジュールへ送信しさえすればよい。

図７は、ローカル・エージェントによるマシン上での障害発見の手順を表したフローチャートである。図８には、同時に行われるアグレゲータの動作が示されており、その動作によって、エージェントの入力に基づき障害が判定される。図７では、ステップ７１０で、エージェントが、障害をテストするために、マシン上のアプリケーション・インスタンスに向けてｐｉｎｇを行う。次にステップ７２０で、アプリケーション・インスタンスからの応答が、先に論じた文脈依存規則に照らして、エージェントによって評価される。エージェントは、この評価の結果として、マシンが障害を起しているかどうか結論を下し、ステップ７３０で、エージェントはこの判定をアグレゲータに通知する。

図８は、アグレゲータによるマシン上の障害検出プロセスを表すフローチャートである。図８では、アグレゲータは同時に、マシン上の障害についての判定に関するエージェントからの周期的な通信を聴取する。ステップ７４０で、アグレゲータは、障害関連通知をエージェントから取得する（図７のステップ７３０に対応）。エージェントからの通知が遅延した場合、ステップ７５０で、アグレゲータは、エージェントによって報告されるマシンは障害を起しているという結論に分岐する（ステップ７６０）。

エージェントからの通知が遅延しなかった場合、アグレゲータは、通知の内容を調べて、マシンについてのエージェントの判定を見つける。ステップ７７０で、エージェントがマシン上で障害が起っていると判定した場合、アグレゲータは、マシンは障害を起しているという結論に分岐し（ステップ７６０）、それ以外の場合は、マシンは障害を起していないと結論する（ステップ７８０）。図８のステップは、マシン上のエージェントからの次の通知が予期されるときに、再び繰り返される。

ロード・ディストリビュータ
図９および図１０は、上で説明したロード・ディストリビュータに関連するプロセスを表すフローチャートである。

リクエスト受信時（ステップ８２０）：ロード・ディストリビュータは、ステップ８６０で受信リクエストをキューの末尾に追加する。

リクエスト処理：ロード・ディストリビュータは、ステップ８１２で、キューの先頭からリクエストＲを取り出す。ロード・ディストリビュータは、リクエストＲからそのリクエストが求めるリソースのクライアントＣを特定する。次にロード・ディストリビュータは、リクエストを転送することのできる、当該クライアントのリソースのインスタンスを見つける。そのようなインスタンスは、レベル１・ロード・アグレゲータから受信した負荷情報（負荷率）から見て、作業負荷の最も軽いインスタンスである。これはステップ８１４で実行される。ステップ８７０でインスタンスに割り当てられた容量がすっかり消費されている（負荷率が１以上である）と判定された場合、ロード・ディストリビュータは、ステップ８９０で当該リクエストを削除する。容量が残っている場合、ロード・ディストリビュータは、ステップ８９１でリクエストをインスタンスに転送し、当該インスタンスに送信されたリクエストのカウントを１だけインクリメントする。ロード・ディストリビュータは、時間間隔ｄＴ（ｄＴはＴ_ｕに比べて非常に短い）が経過した後、あるいはステップ８９１で当該インスタンスに各リクエストを転送した後、このカウントをレベル１・ロード・アグレゲータに送信する。これは実装レベルのパラメータであり、ロード・ディストリビュータ１１０の起動時に構成可能であるべきである。

リソース・マネージャからのメッセージ受信時（ステップ８３０）：ステップ８５０でメッセージが、インスタンスがシャットダウンされていることを通知していた場合、ロード・ディストリビュータは、そのインスタンスへのリクエスト転送をすべて中止する。ステップ８５０でメッセージが、インスタンス内のクライアントへの割付け量が減少したことを通知していた場合、ロード・ディストリビュータは、直ちに新しい割付け量の確保を図る。新しいインスタンスが生成された場合、あるいはインスタンス内のクライアントへのア割付け量が増加した場合、ステップ８５０でリソース・マネージャからバリア・メッセージ−「切替えプラン」を受信するまで、新しい値はロード・ディストリビュータによって使用されない。新しいインスタンス・メッセージは、生成された新しいインスタンスについての情報、新しいインスタンス上に非０の容量を割付けられたクライアントについての情報、およびヒット率で表した対応する割付け量についての情報を含んでいる。ステップ８５０で「切替えプラン」メッセージを受信した後、どちらのテーブルにも新しい各クライアント用のカラムがないクライアントがいてもよい。同様に、ＲＡＴのあるクライアントのカラムのすべてのエントリが０になった場合、ＲＡＴおよびＲＣＴのそのクライアントのカラムは削除される。

レベル１・ロード・アグレゲータからのメッセージ受信時：ステップ８４０でメッセージがインスタンスのクライアントについての負荷率を含んでいる場合、ロード・ディストリビュータは、リソース消費テーブル（ＲＣＴ）内の値を更新する。メッセージが、インスタンスがダウンしていることを通知していた場合、ロード・ディストリビュータは、ステップ８４０でそのインスタンスへのリクエスト転送をすべて中止し、当該インスタンスをＲＡＴおよびＲＣＴから削除する。

システム初期化
システムを初期化する時、システム管理コンポーネント（グローバル・ディシジョン・メーカ１４０、アグレゲータ１２０、ロード・モニタ１３０、リソース・マネージャ１５０など）を動作させるマシンとして指定されたマシンを起動し、事前定義されたスクリプトを実行する。これらのスクリプトは各システム管理コンポーネントをそれぞれ起動し初期化する。すべてのアプリケーションをインストールすることができる分散ファイル・システムが使用でき、すべてのマシンにファイル・システムの統一的ビューが提供される。

初期セットに含まれる顧客が、以下に説明する新しい顧客を追加するための手順に従って、サーバ・ファームに一つずつ追加される。

新しい顧客がサーバ・ファームに加入する場合、顧客アプリケーションのベンチマーク情報がまだ未取得であれば、その顧客はアプリケーションのベンチマーク・テストを行うための試験的な設定の下でホストされ、ベンチマーク情報はコンフィグレーション・リポジトリに追加される。次に、（仮想）サブファームがその顧客向けに構成され、予測負荷要求に応じて初期化される。これを受けて、グローバル・ディシジョン・メーカ１４０はリソースを割り当てることができる。フリー・プールだけでは顧客をサポートできない場合、顧客は拒絶される。グローバル・ディシジョン・メーカ１４０が割当てプランを計算すると、リソース・マネージャ１５０は、新しいサブファームをマシン上に生成することを含めて、そのプランを実施することができる。

コンピュータ・ハードウェアおよびソフトウェア
図１１は、本明細書で説明した技法を実施するプロセスに含まれるステップを実行するのに使用することができるコンピュータ・システム９００の概略図である。コンピュータ・システム９００は、説明した技法の実行を支援するようにプログラムされたコンピュータ・ソフトウェアを実行する目的で提供される。このコンピュータ・ソフトウェアは、コンピュータ・システム９００にインストールされた適切なオペレーティング・システムの下で動作する。

コンピュータ・ソフトウェアは、コンピュータ・システム９００によって解釈可能な１組のプログラムされた論理命令を含み、これらの命令は、コンピュータ・システム９００に指示を与えて、これらの命令によって指定される所定の機能を実行させる。コンピュータ・ソフトウェアは、どんな言語、コード、または表記を用いて記録された表現とすることもでき、この表現は、適合する情報処理システムに特定の機能を直接実行させる、あるいは別の言語、コード、または表記に変換した後で実行させるための１組の命令を含む。

コンピュータ・ソフトウェアは、適切なコンピュータ言語で記述されたステートメントを含むコンピュータ・プログラムによってプログラムされる。コンピュータ・プログラムは、コンパイラを用いて、オペレーティング・システムによる実行に適したバイナリ形式のコンピュータ・ソフトウェアに変換される。コンピュータ・ソフトウェアは、説明した技法のプロセスに含まれる特定のステップを実行する様々なソフトウェア・コンポーネントやコード手段が関与するような方式でプログラムされる。

コンピュータ・システム９００のコンポーネントには、コンピュータ９２０、入力装置９１０、９１５、ビデオ・ディスプレイ９９０が含まれる。コンピュータ９２０は、プロセッサ９４０、メモリ・モジュール９５０、入出力（Ｉ／Ｏ）インタフェース９６０、９６５、ビデオ・インタフェース９４５、ストレージ装置９５５を含む。

プロセッサ９４０は、オペレーティング・システムとオペレーティング・システムの下で動作するコンピュータ・ソフトウェアとを実行する中央処理装置（ＣＰＵ）である。メモリ・モジュール９５０は、ランダム・アクセス・メモリ（ＲＡＭ）と読出し専用メモリ（ＲＯＭ）とを含み、プロセッサ９４０の指揮下で使用される。

ビデオ・インタフェース９４５は、ビデオ・ディスプレイ９９０に接続され、ビデオ・ディスプレイ９９０のディスプレイにビデオ信号を提供する。コンピュータ９２０を操作するためのユーザ入力は、キーボード９１０とマウス９１５で構成される入力装置９１０、９１５から提供される。ストレージ装置９５５は、ディスク・ドライブ、またはその他の適切な不揮発性ストレージ媒体を含む。

コンピュータ９２０の各コンポーネントは、データ・バス、アドレス・バス、制御バスを含むバス９３０に接続され、これらのコンポーネントは、バス９３０を介して互いに通信を行うことができる。

コンピュータ・システム９００は、インターネットに代表されるネットワーク９８０への通信チャネル９８５を使用して、入出力（Ｉ／Ｏ）インタフェース９６５経由で１つまたは複数の他の類似のコンピュータに接続することができる。

コンピュータ・ソフトウェア・プログラムは、コンピュータ・プログラム製品として提供することができ、可搬ストレージ媒体に記録することができる。この場合、コンピュータ・システム９００は、ストレージ装置９５５から読み取ることによって、コンピュータ・ソフトウェア・プログラムにアクセスする。あるいは、コンピュータ９２０は、ネットワーク９８０を介して、コンピュータ・ソフトウェアに直接アクセスすることもできる。いずれの場合も、ユーザは、キーボード９１０およびマウス９１５を使用してコンピュータ・システム９００と対話しながら、コンピュータ９２０上で動作するプログラムされたコンピュータ・ソフトウェアを操作する。

例示のためにコンピュータ・システム９００について説明したが、他の構成またはタイプのコンピュータ・システムを同じようにうまく使用して、説明した技法を実施することができる。上記の説明は、説明した技法を実施するのに適した特定のタイプのコンピュータ・システムの一例にすぎない。

ＡＳＰホスティング・システムの様々な機能コンポーネントを示す概略図である。 図１のＡＳＰホスティング・システムのアーキテクチャを示す概略図である。 集められたデータ・フローが、グローバル・ディシジョン・メーカ・コンポーネントによる処理の前に、図１のシステムでいかに処理されるかを示す概略図である。 図１のシステムのレベル２ａ・アグレゲータに関するアルゴリズムを概略的に表すフローチャートである。 図１のシステムにおいて受信リクエストがいかに分配されるかを示す概略図である。 図１のシステムの異なる仮想部分に関するロード・ディストリビュータの概略図である。 エージェントに関する、図１のシステムの障害検出用アルゴリズムを概略的に示すフローチャートである。 アグレゲータに関する、図１のシステムの障害検出用アルゴリズムを概略的に示すフローチャートである。 図１のシステムのロード・ディストリビュータに関するアルゴリズムを概略的に表すフローチャートである。 図１のシステムのロード・ディストリビュータに関するアルゴリズムを概略的に表すフローチャートである。 図１のシステムを実施するのに使用可能な例示的なコンピュータ・システムの概略図である。

Claims (16)

1. ネットワーク接続された複数のマシン上で一括して実行される複数のリソース・クラス・コンポーネントを含むアプリケーションへのアクセスを複数のクライアント・ユーザに提供する方法であって、前記ユーザは、アプリケーションサービスプロバイダによって運営されるネットワーク接続された複数のマシン上でホストされる１つ又は複数のアプリケーションにアクセスでき、
   前記方法は、
   （ｉ）ユーザからのアプリケーションの使用を求めるリクエストを受信するステップと、
   （ｉｉ）各ユーザからの前記アプリケーションの使用を求める前記受信したリクエストを処理するために、前記ユーザ毎に、各リソース・クラス・コンポーネントの複数のインスタンスの組を複数のマシン上の前記アプリケーションに提供するステップと、
   （ｉｉｉ）前記受信したリクエストの各々をリソース・クラス・コンポーネントのインスタンスのうちで最も負荷が軽いインスタンス宛てに送るステップと、
   （ｉｖ）前記ユーザ毎に、前記アプリケーションの前記リソース・クラス・コンポーネントの前記インスタンスによって処理されたリクエストの数をモニタするステップと、
   （ｖ）前記複数のネットワーク化されたマシンのいずれかに障害があるかどうかをある時間間隔ごとに判定するステップと、
   （ｖｉ）各リソース・クラス・コンポーネント毎にモニタされた前記リクエストの数に応じて且つマシンが障害を起こしていることに基づいて、複数のリソース・クラス・コンポーネントのインスタンスの数を増減させて、該増減された後のインスタンスから構成される異なるマシン・フラクションを特定のユーザに割り当てるステップと、
   を含む、前記方法。
2. 前記提供するステップが、
   前記アプリケーションの使用を求めるリクエストを処理する、複数のマシン上の複数のリソース・クラスの複数のインスタンスを起動するステップと、
   前記アプリケーションの使用を求めるリクエストを処理する、複数のマシン上の各リソース・クラスの複数のインスタンスを終了するステップと
   をさらに含む、請求項１に記載の方法。
3. ユーザからの前記アプリケーションの使用を求める前記リクエストが、適切なリソース・クラスの特定のインスタンスによる実行のためのキューに先入れ先出し方式で格納される、請求項１に記載の方法。
4. 個々のユーザに対するサービス品質保証契約の記録を維持管理するステップをさらに含む、請求項１に記載の方法。
5. 各リソース・クラス・コンポーネント毎にモニタされた前記リクエストの数に応じて、各リソース・クラス・コンポーネントのインスタンスの数を、前記ユーザ毎に増減させるステップをさらに含み、個々のユーザに対する前記サービス品質保証契約が少なくとも満たされる、請求項４に記載の方法。
6. 現在使用可能なリソースと、処理されるリクエストによって現在消費されているリソースとが、各ユーザ毎にモニタされ、
   （ｉ）個々のユーザが現在使用可能なリソースの記録と、（ｉｉ）個々のユーザによって現在消費されているリソースの記録とを維持管理し、前記両方のリソースの記録を、各リソース・クラス・コンポーネントの複数のインスタンスの各々に関して維持管理するステップをさらに含む、請求項１〜５のいずれか一項に記載の方法。
7. 前記複数のリソース・クラス・コンポーネントが、ウェブ・サーバ・コンポーネント、コマース・サーバ・コンポーネント、及びデータベース・サーバ・コンポーネントを含む、請求項１に記載の方法。
8. 前記複数のリソース・クラス・コンポーネントは、フロントエンド・コンポーネント、中間層コンポーネント、及びバックエンド・コンポーネントを含む、請求項１に記載の方法。
9. ネットワーク接続された複数のマシン上で一括して実行される複数のリソース・クラス・コンポーネントを含むアプリケーションへのアクセスを複数のユーザに提供するためのシステムであって、前記ユーザは、アプリケーションサービスプロバイダによって運営されるネットワーク接続された複数のマシン上でホストされる１つ又は複数のアプリケーションにアクセスでき、
   前記システムは、
   （ｉ）ユーザからのアプリケーションの使用を求めるリクエストを受信する手段と、
   （ｉｉ）各ユーザからの前記アプリケーションの使用を求める前記受信したリクエストを処理するために、前記ユーザ毎に、各リソース・クラス・コンポーネントの複数のインスタンスの組を複数のマシン上の前記アプリケーションに提供する手段と、
   （ｉｉｉ）前記受信したリクエストの各々をリソース・クラス・コンポーネントのインスタンスのうちで最も負荷が軽いインスタンス宛てに送る手段と、
   （ｉｖ）前記ユーザ毎に、前記アプリケーションの前記リソース・クラス・コンポーネントの前記インスタンスによって処理されたリクエストの数をモニタする手段と、
   （ｖ）前記複数のネットワーク化されたマシンのいずれかに障害があるかどうかをある時間間隔ごとに判定する手段と、
   （ｖｉ）各リソース・クラス・コンポーネント毎にモニタされた前記リクエストの数に応じて且つマシンが障害を起こしていることに基づいて、複数のリソース・クラス・コンポーネントのインスタンスの数を増減させて、該増減された後のインスタンスから構成される異なるマシン・フラクションを特定のユーザに割り当てる手段と
   を含む、前記システム。
10. 前記提供する手段が、
    前記アプリケーションの使用を求めるリクエストを処理する、複数のマシン上の複数のリソース・クラスの複数のインスタンスを起動する手段と、
    前記アプリケーションの使用を求めるリクエストを処理する、複数のマシン上の各リソース・クラスの複数のインスタンスを終了する手段と
    をさらに含む、請求項９に記載のシステム。
11. ユーザからの前記アプリケーションの使用を求める前記リクエストが、適切なリソース・クラスの特定のインスタンスによる実行のためのキューに先入れ先出し方式で格納される、請求項９に記載のシステム。
12. 個々のユーザに対するサービス品質保証契約の記録を維持管理する手段をさらに含む、請求項９に記載のシステム。
13. 各リソース・クラス・コンポーネント毎にモニタされた前記リクエストの数に応じて、各リソース・クラス・コンポーネントのインスタンスの数を、前記ユーザ毎に増減させるステップをさらに含み、個々のユーザに対する前記サービス品質保証契約が少なくとも満たされる、請求項１２に記載のシステム。
14. 前記モニタ手段が、各ユーザ毎に、現在使用可能なリソースと、処理されるリクエストによって現在消費されているリソースとをモニタし、
    （ｉ）個々のユーザが現在使用可能なリソースの記録と、（ｉｉ）個々のユーザによって現在消費されているリソースの記録とを維持管理し、前記両方のリソースの記録を、各リソース・クラス・コンポーネントの複数のインスタンスの各々に関して維持管理する手段をさらに含む、請求項９〜１３のいずれか一項に記載のシステム。
15. 前記複数のリソース・クラス・コンポーネントが、ウェブ・サーバ・コンポーネント、コマース・サーバ・コンポーネント、及びデータベース・サーバ・コンポーネントを含む、請求項９に記載のシステム。
16. 前記複数のリソース・クラス・コンポーネントは、フロントエンド・コンポーネント、中間層コンポーネント、及びバックエンド・コンポーネントを含む、請求項９に記載のシステム。

Images