複数の計算ノードを含むリソースを有するサーバシステムにおいて、該サーバシステムの処理により、クライアントコンピュータからのリクエストに応じて、動的にリソースを割り当てる方法であって、異なる準備状態にある複数のインスタンスを用意するステップと、クライアントコンピュータから、動的スケーリング条件のリクエストを受け取るステップと、前記動的スケーリング条件を満たすように前記異なる準備状態にある複数のインスタンスを組み合わせて起動するステップを有する、動的にリソースを割り当てる方法。前記リクエストのIDと、前記計算ノードのCPUのIDと、準備状態の段階のフィールドを含む予約テーブルを維持するステップと、前記クライアントコンピュータからの、計算ノードの使用を要求するリクエストを受領することに応答して、前記予約テーブルに基づき、計算ノードを割当可能かどうか判断し、もしそうなら、その割当を反映するように前記予約テーブルを更新して、該計算ノードを前記リクエストに割当てるステップをさらに有する、請求項1に記載の動的にリソースを割り当てる方法。前記動的スケーリング条件のリクエストが、前記動的スケーリング条件が満たされるかどうかの確実度を含み、前記計算ノードを前記リクエストに割当てるステップが、前記確実度が満たされるかどうかを判断するステップを有し、前記確実度が満たされる場合にのみ前記計算ノードを前記リクエストに割当てる、請求項2に記載の動的にリソースを割り当てる方法。前記確実度が満たされるかどうかを判断するステップが、計算ノードの使用を要求するリクエストを受け取る頻度の統計値に基づき実行される、請求項3に記載の動的にリソースを割り当てる方法。前記準備状態が、準備完了状態、スワップアウト状態、要起動状態、要ブート状態、及び要導入状態を含む、請求項1に記載の動的にリソースを割り当てる方法。前記計算ノードを前記リクエストに割当てることに応答して、前記予約テーブルの該当する準備状態の段階のフィールドを、準備完了状態にするステップをさらに有する、請求項5に記載の動的にリソースを割り当てる方法。複数の計算ノードを含むリソースを有するサーバシステムにおいて、該サーバシステムの処理により、クライアントコンピュータからのリクエストに応じて、動的にリソースを割り当てるプログラムであって、前記サーバシステムに、異なる準備状態にある複数のインスタンスを用意するステップと、クライアントコンピュータから、動的スケーリング条件のリクエストを受け取るステップと、前記動的スケーリング条件を満たすように前記異なる準備状態にある複数のインスタンスを組み合わせて起動するステップを実行させる、動的にリソースを割り当てるプログラム。前記リクエストのIDと、前記計算ノードのCPUのIDと、準備状態の段階のフィールドを含む予約テーブルを維持するステップと、前記クライアントコンピュータからの、計算ノードの使用を要求するリクエストを受領することに応答して、前記予約テーブルに基づき、計算ノードを割当可能かどうか判断し、もしそうなら、その割当を反映するように前記予約テーブルを更新して、該計算ノードを前記リクエストに割当てるステップをさらに有する、請求項7に記載の動的にリソースを割り当てるプログラム。前記動的スケーリング条件のリクエストが、前記動的スケーリング条件が満たされるかどうかの確実度を含み、前記計算ノードを前記リクエストに割当てるステップが、前記確実度が満たされるかどうかを判断するステップを有し、前記確実度が満たされる場合にのみ前記計算ノードを前記リクエストに割当てる、請求項8に記載の動的にリソースを割り当てるプログラム。前記確実度が満たされるかどうかを判断するステップが、計算ノードの使用を要求するリクエストを受け取る頻度の統計値に基づき実行される、請求項9に記載の動的にリソースを割り当てるプログラム。前記準備状態が、準備完了状態、スワップアウト状態、要起動状態、要ブート状態、及び要導入状態を含む、請求項7に記載の動的にリソースを割り当てるプログラム。前記計算ノードを前記リクエストに割当てることに応答して、前記予約テーブルの該当する準備状態の段階のフィールドを、準備完了状態にするステップをさらに有する、請求項11に記載の動的にリソースを割り当てるプログラム。複数の計算ノードを含むリソースを有するサーバシステムにおいて、該サーバシステムの処理により、クライアントコンピュータからのリクエストに応じて、動的にリソースを割り当てるシステムであって、異なる準備状態にある複数のインスタンスを用意する手段と、クライアントコンピュータから、動的スケーリング条件のリクエストを受け取る手段と、前記動的スケーリング条件を満たすように前記異なる準備状態にある複数のインスタンスを組み合わせて起動する手段を有する、動的にリソースを割り当てるシステム。前記サーバシステムの記憶手段に記憶された、前記リクエストのIDと、前記計算ノードのCPUのIDと、準備状態の段階のフィールドを含む予約テーブルと、前記クライアントコンピュータからの、計算ノードの使用を要求するリクエストを受領することに応答して、前記予約テーブルに基づき、計算ノードを割当可能かどうか判断し、もしそうなら、その割当を反映するように前記予約テーブルを更新して、該計算ノードを前記リクエストに割当てる手段をさらに有する、請求項13に記載の動的にリソースを割り当てるシステム。前記動的スケーリング条件のリクエストが、前記動的スケーリング条件が満たされるかどうかの確実度を含み、前記計算ノードを前記リクエストに割当てる手段が、前記確実度が満たされるかどうかを判断する手段を有し、前記確実度が満たされる場合にのみ前記計算ノードを前記リクエストに割当てる、請求項14に記載の動的にリソースを割り当てるシステム。前記確実度が満たされるかどうかを判断する手段が、計算ノードの使用を要求するリクエストを受け取る頻度の統計値に基づく、請求項15に記載の動的にリソースを割り当てるシステム。前記準備状態が、準備完了状態、スワップアウト状態、要起動状態、要ブート状態、及び要導入状態を含む、請求項13に記載の動的にリソースを割り当てるシステム。前記計算ノードを前記リクエストに割当てることに応答して、前記予約テーブルの該当する準備状態の段階のフィールドを、準備完了状態にする、請求項17に記載の動的にリソースを割り当てるシステム。従って、この発明の目的は、クラウドコンピューティングなどのサービスにおいて、クライアントに、所定の確実度の範囲で動的スケーラビリティの品質要求を可能ならしめることにある。上記目的は、本発明に従い、動的スケーラビリティの品質要求指標を可変にし、与えられた指標を満たすように、様々な手段からなる事前準備を組み合わせたプラットフォームサービスを提供することによって達成される。すなわち、プラットフォームの許容量拡大の上限と拡大スピードへの要求をもって、一定の確実性を担保された動的スケーラビリティの品質要求の指標とする。この要求を満たすように、本発明に従うクラウドサーバは、ホットスタンバイ、スワップアウト状態、コールドスタンバイなどの様々な事前準備状況のプラットフォームを組み合わせて提供する。本発明に従うクラウドサーバは、例えば、記憶系リソースを異なる予約間で共用する一方で、複数の実リソースに多重化して割り当てる。そして、すべての利用者のスケールアップの状況を常にモニタし、与えられた確実性を満たすように、共用と多重化を調整する。動作において、クラウドコンピューティングなどのサービスのユーザは、予め所定の動的スケーラビリティのサービス品質保証契約を、クラウドコンピューティングのプロバイダと結んでおく。これには限定されないが、ここでは、主としてPaaSを想定する。そして、ユーザは、必要に応じて、クラウドサーバに対してリクエストを送る。クラウドサーバは、受け取ったリクエストを一旦キューに入れて、順次処理していく。リクエストには、ユーザからの仮想マシンVM追加要求であるUpイベント処理と、ユーザからの仮想マシンVM削除要求であるDownイベント処理が含まれる。クラウドサーバは、リクエストがUpイベント処理である場合、リソースの予約テーブルを更新して、該当VMインスタンスを追加し、利用するCPUを、CPUのプール集合から削除し、リソース割当調整処理を行う。一方、クラウドサーバは、リクエストがDownイベント処理である場合、該当VMインスタンスを削除し、それによって利用可能になったCPUを、CPUのプール集合に戻し、確実性が満たされるかどうか判断する。ここで確実性が満たされるとは、予約の現在の確実性が、サービス品質保証契約で要求されている確実性より大きいということである。もしそうでないなら、クラウドサーバは、CPUのプール集合をみて、CPUが割当可能か判断し、もし割当可能なら、ハードウェアリソースを追加する。確実性は、例えば、ポアッソン分布などに従い、確率的に計算することができる。この発明によれば、クラウドサービスなどのサーバ提供サービスにおいて、動的スケーラビリティを妥当な価格でユーザに提供することが可能になる。例えば、100インスタンスを、30分で、80の確実性で増強できるように、というリクエストを受けることができ、またそのような条件に適切に価格設定可能である。これにより、従来考えられなかった新しいSLAが提示可能となる。以下、図面を参照して、本発明の実施例を説明する。特に断わらない限り、同一の参照番号は、図面を通して、同一の対象を指すものとする。また、以下で説明するのは、本発明の一実施形態であり、この発明を、この実施例で説明する内容に限定する意図はないことに留意されたい。図1は、本発明を実施するためのシステム全体の概要を示す図である。クラウドサーバのユーザが使うクライアントコンピュータ102a、102b102zは、詳細には図示しないが、適当なプロキシサーバなどを介して、インターネット104に接続されている。クライアントコンピュータ102a、102b102zはさらに、インターネット104を介して、クラウドサービス、特にPaaSサービスのプロバイダのシステム110に接続される。システム110は、スケジューラ112と、好適にはハードディスクに保存された、スケジューラ112の予約スケジュールのデータ114と、クライアントコンピュータからのリクエストを入れるためのキュー116と、リソースアロケータ118と、好適にはハードディスクに保存され、リソースアロケータ118が参照し更新する予約テーブルのデータ120と、キュー116のデータに基づきユーザの状況を監視するユーザモニタ122と、計算資源としての複数のコンピュータ計算ノード132、152と、記憶資源としてのストレージエリアネットワークSAN、ネットワーク接続ストレージNAS、あるいは遠隔ディスク装置であるディスクストレージ装置154、156、158からなるハードウェアリソースプール130を有する。スケジューラ112は、クライアントコンピュータ102a、102b102zからのリクエストを受付け、一旦予約スケジュール114に格納する。そして、リクエストによって指定された日時になると、そのリクエストをキュー116に入れ、リソースアロケータ118の処理に委ねる。この実施例では、クラウドコンピューティングなどのサービスのユーザは、予め所定の動的スケーラビリティのサービス品質保証契約を、クラウドコンピューティングのプロバイダと結んでおく。このような契約の内容は、予めプロバイダの所定のシステムに格納され、必要に応じて参照される。このような契約の内容は、例えば、予約スケジュール114に含めてもよい。リクエストには、動的スケーラビリティのサービス品質保証契約の内容、ユーザからの仮想マシンVM追加要求であるUpイベント処理と、ユーザからの仮想マシンVM削除要求であるDownイベント処理などが含まれえる。リソースアロケータ118は、リクエストがUpイベント処理である場合、予約テーブル120を更新して、VMインスタンスを追加し、利用するハードウェア資源特にCPUを、ハードウェアリソースプール130から、リソース割当調整する。なおここでCPUとは具体的に、ハードウェアリソースプール130におけるコンピュータ計算ノード132、134などのことである。一方、リソースアロケータ118は、リクエストがDownイベント処理である場合、該当VMインスタンスを削除し、それによって利用可能になったCPUを、CPUのリソースプールに戻し、確実性が満たされるかどうか判断する。ここで確実性が満たされるとは、サービス品質保証契約に従う予約の要求されている確実性が、予約の現在の確実性より大きいということである。もしそうなら、リソースアロケータ118は、予約テーブル120をみて、CPUが割当可能か判断し、もしそうなら、CPUを追加する。リソースアロケータ118は、クライアントからのリクエストに応じて、ハードウェアリソースプール130のリソースを割当あるいは開放するだけではなく、動作状況を監視する役割も果たす。なお、スケジューラ112、リソースアロケータ118、及びユーザモニタ122の機能は、コンピュータハードウェアのハードディスクに導入されたソフトウェアとして実現することができ、当該コンピュータに導入されたオペレーティングシステムの働きで、当該コンピュータの主記憶にロードされて実行される。スケジューラ112、リソースアロケータ118、及びユーザモニタ122は、好適には同一のコンピュータハードウェア上で実行され、予約スケジュール114と、予約テーブル120は、当該のコンピュータのハードディスクに保存されてもよく、あるいは、そのうちの一部が、ネットワーク接続された別のコンピュータハードウェア上にあってもよい。次に、図2を参照して、クライアントコンピュータ102a、102b102zの例示的な構成を説明する。次に、図2を参照して、図1で参照番号106a、106b106zのように示されているクライアントコンピュータのハードウェアブロック図について、説明する。図2において、クライアントコンピュータは、主記憶206、CPU204、IDEコントローラ208をもち、これらは、バス202に接続されている。バス202には更に、ディスプレイコントローラ214と、通信インターフェース218と、USBインターフェース220と、オーディオインターフェース222と、キーボードマウスコントローラ228が接続されている。IDEコントローラ208には、ハードディスクドライブHDD210と、DVDドライブ212が接続されている。DVDドライブ212は、必要に応じて、CD-ROMやDVDから、プログラムを導入するために使用する。ディスプレイコントローラ214には、好適には、LCD画面をもつディスプレイ装置216が接続されている。ディスプレイ装置216には、Webブラウザを通じて、アプリケーションの画面が表示される。USBインターフェース220には、必要に応じて、拡張ハードディスクなどのデバイスを接続をすることができる。キーボードマウスコントローラ228には、キーボード230と、マウス232が接続されている。キーボード230とマウス232は、テキストエディタなどの所定のプログラムを使って、プロバイダによって定義されたAPIを使用したプログラムを作成したり、使用される。CPU204は、例えば、32ビットアーキテクチャまたは64ビットアーキテクチャに基づく任意のものでよく、インテル社のPentiumインテルコーポレーションの商標4、Core2Duo、AMD社のAthlon商標などを使用することができる。ハードディスクドライブ210には、少なくとも、オペレーティングシステムと、オペレーティングシステム上で動作するWebブラウザ図示しないが格納されており、システムの起動時に、オペレーティングシステムは、メインメモリ206にロードされる。さらに、好適には、APIを呼び出すためのプログラムを作成するためのテキストエディタ、またはEclipseのタグをつけ、その中で、プロバイダが提供した所定のURLをsrcで指定し、APIで定義された関数を所定の引数とともに呼び出すような書き方をすることである。図3は、ハードウェアリソースプール130における個々のコンピュータ計算ノード132、134、、152のハードウェア構成の概要ブロック図である。これらは各々、通信インターフェース302をもつ。通信インターフェース302はさらに、バス304に接続され、バス304には、CPU306、主記憶RAM308、及びハードディスクドライブHDD310が接続されている。コンピュータ計算ノード132、134、、152は、好適には同じサイトに配置され、光ファイバなどの構内高速ネットワーク接続網により互いに接続されるが、あるいは、インターネット回線を介して接続され、遠隔地に配置されていてもよい。コンピュータ132、134、、152としては、IBMSystemX、IBMPowerSystemなどの、目的に応じた任意のコンピュータハードウェアシステムを使用することができる。スケジューラ112、予約スケジュール114、キュー116、リソースアロケータ118、予約テーブル120及びユーザモニタ122を走らせるコンピュータシステムは、コンピュータ132、134、、152などと同一タイプのものでよい。図1のハードウェアリソースプール130は、ディスク装置154、156、158などを統合するために、IBMSystemStorageSANボリュームコントローラのような、SAN管理ハードウェアを備えていてもよい。図4は、システム110に導入されているハードウェア仮想化環境を示す図である。リソースアロケータ118が導入されているコンピュータシステムには、ハイパーバイザ402が導入され、セットアップされている。ここで使用可能なハイパーバイザ402は、これらには限定されないが、Xen、Microsoft社のHyperV、VMware社のVMwareなどが使用可能である。この実施例では、Xenを想定する。ハイパーバイザ402は、ハードウェアリソースプール130にあるコンピュータ132、134152及びディスク装置154、156等を仮想化する。ハイパーバイザ402としてのXenの下では、ドメイン0とも呼ばれる特権的仮想マシンVM404が生成される。特権的仮想マシン404は、仮想マシンVMの作成、削除、ハードウェアリソースプール130へのアクセス、その他の機能を有する管理アプリケーションプログラムAPP404aを含む。図1に示すスケジューラ112、リソースアロケータ118、及びユーザモニタ122も、管理アプリケーションプログラム404aに含まれる。管理アプリケーションプログラム404aは、クライアントからのリクエストに応じて適宜、ドメインUと呼ばれる仮想マシンVM406、408、410を生成し、あるいは削除する。図5は、管理アプリケーションプログラム404aにおける、本発明に関連する処理モジュールを示す図である。図示されているように、管理アプリケーションプログラム404aは、キュー処理モジュール502、Upイベント処理モジュール504、Downイベント処理モジュール506、リソース割当調整モジュール508、及びテーブル更新モジュール510を含む。次に、図6のフローチャートを参照して、キュー処理モジュール502の処理について説明する。キュー処理モジュール502の基本的な動作は、システム停止まで、ステップ602からステップ626までのループを回り、キュー116内にあるリクエストを順次処理することである。キュー処理モジュール502は、ステップ604で、キュー116が空かどうか判断し、空でないなら、ステップ606で、キューの先頭がUp要求かどうか判断する。もしそうなら、キュー処理モジュール502は、ステップ608で、Upイベント処理モジュール504を呼び出す。Upイベント処理モジュール504の処理の詳細は、図7のフローチャートを参照して、後で説明する。キューの先頭がUp要求でないなら、キュー処理モジュール502は、ステップ610で、キューの先頭がDown要求かどうか判断する。もしそうなら、キュー処理モジュール502は、ステップ612で、Downイベント処理モジュール506を呼び出す。Downイベント処理モジュール506の処理の詳細は、図8のフローチャートを参照して、後で説明する。キューの先頭がDown要求でないなら、キュー処理モジュール502は、ステップ614で、キューの先頭が、予約追加削除かどうか判断する。もしそうなら、キュー処理モジュール502は、ステップ616で予約の追加削除処理をする。予約には、要求する動的スケジューリング条件が含まれる。ここでの予約の追加削除処理は、予約スケジュール114に反映される。ステップ616の次に、キュー処理モジュール502は、ステップ618でリソース割当調整モジュール508を呼び出す。リソース割当調整モジュール508については、図9のフローチャートを参照して、後で説明する。ステップ614で、キュー116の先頭が、予約追加削除でないなら、ステップ620でその他の制御処理を行う。ステップ608、612、618あるいは620の後、キュー処理モジュール502は、ステップ622でキューの先頭から要求を1つ取り除いて、ステップ626のループに戻る。ステップ604に戻って、キュー処理モジュール502が、キュー116が空であると判断すると、ステップ624で一定時間待機して、ステップ626のループに戻る。次に、図7のフローチャートを参照して、Upイベント処理モジュール504について説明する。ステップ702で、Upイベント処理モジュール504は、新規VM追加可能かどうか判断する。それを式で表すと、c∈CPUsReservation10かどうかの判断となる。ここで、CPUsは、ハードウェアリソースプール130におけるCPUのIDの集合であり、rkは予約IDであり、Reservation1は、予約IDにCPUsの要素cが予約されていることを意味する。すなわち、ステップ702は、当該予約IDに予約されたCPUsの要素が1つ以上あるかどうかの判断である。そうでないなら、Upイベント処理モジュール504は、直ちに処理を終わる。一方、ステップ702で、当該予約IDに予約されたCPUsの要素が1つ以上あると判断されると、Upイベント処理モジュール504は、ステップ704で、UpdateTable0この式の意味は、ステップ702で説明したとおりである。そして、リソース割当調整モジュール508は、もし割当可能であると判断すると、ステップ910で、CPUs←CPUs∪cにより、CPUsにハードウェアリソースを追加する。ステップ910の後、あるいはステップ908の判断が否定的である場合、リソース割当調整モジュール508は、ステップ912で、Reservation←1により、rkに新規割当の追加を行い、処理はステップ914に進み、kを1つインクリメントしてステップ904に戻る。次に、図10と図11のフローチャートを参照して、テーブル更新モジュール510の処理を説明する。テーブル更新モジュール510が扱うのは、図12に示すようなフォーマットをもつ予約テーブル120である。予約テーブル120において、RIDは拡張予約IDであり、拡張予約の1契約毎のIDである。STEPは、準備予約された仮想的なノードID例えば30分で10台のうち5台目で小さい方から段階的に準備完了していく段階である。GRADEは、準備状況の状態で、0が準備完了状態、1がスワップアウト状態、2が要起動状態、3が要ブート状態、4が要導入/構成状態、5が要購入ソフトウェア状態、6が要購入ハードウェア状態である。CPUIDは、実際に割当てられた計算ノードのIDである。図10に示すように、テーブル更新モジュール510であるUpdateTableは、拡張予約IDである引数ridをとる。ステップ1002で、テーブル更新モジュール510は、Promoteを呼び出す。Promote関数の詳細は、図11のフローチャートを参照して後で説明する。ステップ1004では、テーブル更新モジュール510は、ridをもつ、準備完了状態に昇格可能な予約テーブル120のレコードを1つ選択する。ステップ1006では、テーブル更新モジュール510は、当該レコードを準備完了状態にして戻る。次に、図11のフローチャートを参照して、UpdateTableで呼ばれるPromote関数の処理を説明する。Promote関数は、Promoteという引数で呼ばれる。ステップ1102で、Promote関数は、stepMaxStepcountであるかどうか判断する。ここでMaxStepは、予約テーブル120において、予約ridが準備予約した総数を返す。また、countは、ridをもち現在準備完了であるレコードの数である。もしstepMaxStepcountであるなら、Promote関数は、何もしないで戻る。stepMaxStepcountでないなら、Promote関数は、ステップ1104で、RIDrid、STEPstep、GRADEgradeであるレコードがあるかどうか判断し、もしあれば、ステップ1106で、その見つかったレコードを1つ選択する。Promote関数は、ステップ1108からステップ1120までのループで、ステップ1106でみつかったレコードの同じCPUを共有している、予約テーブル120のレコードを順次検索する。そこで、ステップ1104で見つかった目下のレコードをとする。ステップ1110で、Promote関数は、目下のレコードが、見つかったレコードそのものか判断し、もしそうなら、ステップ1112で、そのレコードのstepとgradeを1つずつデクリメントし、ステップ1114で、Promoteを再帰的に呼び出す。これは、STEPstepのレコードが1個減った分のリソースを確保するために行う。ステップ1110で、目下のレコードが、見つかったレコードそのものでないなら、Promote関数は、ステップ1116で、目下のレコードを削除し、ステップ1118で、Promoteにより、削除したレコード分のリソースの確保を行う。このような処理を予約テーブル120のすべてに亘って行うと、Promote関数は、ステップ1120を抜けて、戻る。ステップ1104に戻って、RIDrid、STEPstep、GRADEgradeであるレコードがないなら、Promote関数は、ステップ1122で、利用可能なcpuidを選択し、のエントリをもつ新しいレコードを挿入して、戻る。図13は、図10及び図11のフローチャートの処理に従い、図12の予約テーブル120を更新した結果を示す図である。次に動的スケジューリングの品質QoDSについて説明する。ここで、toverallは、全体の準備完了までの時間、λoverallは、全体のVMインスタンス数である。すなわち、QoDSと、準備完了までの時間t1t2tnのリストここでt1はほぼ0で、任意のiについてtiti1を与えたとき、最適なスタンバイ状態として、i番目のスタンバイ状態のVMインスタンス数λiは、次の式で得られる。ここで、N0は、0以上の整数の集合である。すなわち、図1のシステムは、クライアントに対して、このようにして決定されたi12nでVMインスタンスを立ち上げる。ここで、各tiの値の標準偏差は、過去のデータに基づき予め推定される。特に、各tiが正規分布に従うと仮定し、その標準偏差をσとすると、下記が成立する。ここで、Prは、括弧の中の条件が成立する確率である。下記に示すように、titaverage3σのように、時間的に相対的に高い確実性を実現しようとすると、時間はかかるが、リソース割当は、相対的に楽観的でよい。なおここで、Prは、動的スケーリング条件QoDSを満たす確率である。一方、下記に示すように、titaverage1σのように、時間的に相対的に低い確実性を実現しようとすると、時間は迅速になるが、リソース割当は、相対的に悲観的にする必要がある。図14は、準備状態、準備時間、確実性、上限、各リソース、及びコスト値付けの例を示す図である。示されているように、準備状態は、例として、準備完了、スワップアウト、要起動、要ブート、要導入/構成、要購入ソフトウェア、及び要購入ハートウェアを含む。図15は、このようにして用意された、異なる準備状態を組み合わせて、QoDSに対応するVMインスタンスの立ち上げ時間を達成する状態を示す図である。異なる準備状態毎のインスタンス数は、数5のアルゴリズムに従い、管理APP404aが決定する。VMインスタンスの立ち上げは、例えば、管理APP404aが、リソース割当調整処理を完了した直後、開始する。図16は、本発明の処理の効果を模式的に示す図である。すなわち、あるクライアントが、処理実行のために100クライアントを要するとすると、コールドスタンバイ1602の場合は、起動時に、全く準備できておらずそこから立ち上げるので、コストは安いが、立ち上げ時間がかかる。一方、ホットスタンバイ1604の場合は、最初からすべてのインスタンスが準備完了なので、立ち上げは迅速だが、コストは高い。本発明の場合は、事前に一部のインスタンスがある程度まで準備状態が進んでいるので、それらの異なる準備状態にあるインスタンスを組みあわせて順次起動することによって、コストを妥当な範囲に抑えつつ、要求を満たす立ち上げ時間が達成される。すなわち、従来技術では、100インスタンスをある時間でユーザに提供するなら、100インスタンスを常時走らせておかなくてはならず、それはクラウドサーバ側でリソースが消耗されており、一方で、ユーザに対して相対的に高い課金となる。それでは、従来技術で、100インスタンスを非稼動状態にしておくと、ユーザに対して相対的に低い課金で済むが、ユーザの要求する立ち上げ時間を達成できない。そこで、本発明によれば、実行中を1インスタンス、スワップアウトを2インスタンス、要起動を12インスタンス、要ブートを25インスタンス、要導入/構成を60インスタンスというように用意しておくことで、活動リソースを最小限にしつつ、ユーザが要求する時間内にリソースを用意することが可能になる。このことにより、ユーザの課金と、サーバ側の可用リソースの両面で最適化が図られることになる。以上、本発明の実施例を、特定のコンピュータプラットフォームに従い説明してきたが、このような特定のコンピュータプラットフォームに限定されず、複数の計算ノードと、それらの計算ノードを仮想化して複数の仮想マシンを生成できるサーバ環境であるなら、任意のサーバ環境で実施可能であることを、この分野の当業者であるなら理解するであろう。