"複数の処理サーバを含む処理サーバ群と、前記処理サーバ群に代替して応答するための代替サーバと、前記処理サーバ群の各処理サーバにトラフィックを分散するとともに、前記処理サーバ群が過負荷状態となった際に前記代替サーバにトラフィックを転送するロードバランサと、前記ロードバランサにより前記処理サーバ群へ転送される転送量と前記代替サーバへ転送される転送量とに応じて、前記処理サーバ群の目標規模を演算する目標規模演算部と、前記処理サーバ群の現在の規模から目標規模へ増強するため前記処理サーバ群の処理サーバを準備するサーバ準備部とを含む、情報処理システム。前記目標規模演算部は、前記処理サーバ群の処理サーバで観測されたローカルな負荷を表す評価指標に依存させて前記処理サーバ群の目標規模を演算する、請求項1に記載の情報処理システム。前記情報処理システムは、さらに、前記処理サーバ群の後段に設けられる第2サーバ群を含み、前記目標規模演算部は、前記処理サーバ群の処理サーバで観測された評価指標からボトルネックを判定し、前記処理サーバ群の後段にボトルネックがあると判定された場合に、前記処理サーバ群への転送量と前記代替サーバへの転送量とに応じて前記第2サーバ群の目標規模を演算し、前記サーバ準備部は、前記第2サーバ群の現在の規模から目標規模へ増強するため前記第2サーバ群の処理サーバを準備する請求項2に記載の情報処理システム。前記ロードバランサは、前記処理サーバ群の応答性能を監視し、前記応答性能が転送条件を満たした場合に前記処理サーバ群が過負荷状態であると判定する、請求項1に記載の情報処理システム。前記転送量は、コネクション数、クライアント数またはセッション数で定量されることを特徴とする、請求項1に記載の情報処理システム。前記代替サーバは、Sorryサーバであることを特徴とする、請求項1に記載の情報処理システム。前記目標規模演算部は、前記処理サーバ群への転送量と前記代替サーバへの転送量との比に依存させて前記処理サーバ群の目標規模を演算する、請求項1に記載の情報処理システム。前記処理サーバは、それぞれ仮想マシン上で稼働し、前記ローカルな負荷を表す評価指標は、前記処理サーバが稼働する仮想マシンのリソース使用率であり、前記サーバ準備部は、物理マシン上のハイパーバイザに対し、前記処理サーバ群の処理サーバを稼働させる仮想マシンのインスタンスの起動を指令することにより前記処理サーバを準備し、前記処理サーバ群の目標規模は、前記処理サーバ群の処理サーバを稼働させる仮想マシンのインスタンス数で定量されることを特徴とする、請求項2に記載の情報処理システム。前記処理サーバ群は、処理サーバとしてウェブサーバを含み、前記第2サーバ群は、処理サーバとしてアプリケーションサーバまたはメモリキャッシュサーバを含む、請求項3に記載の情報処理システム。処理サーバ群を構成する複数の処理サーバの各々にトラフィックを分散するとともに前記処理サーバ群が過負荷状態となった際に代替サーバにトラフィックを転送するロードバランサから、前記処理サーバ群へ転送される転送量と前記代替サーバへ転送される転送量とを取得する転送量取得部と、前記処理サーバ群への転送量と前記代替サーバへの転送量とに応じて前記処理サーバ群の目標規模を演算する目標規模演算部と、前記処理サーバ群の現在の規模から目標規模へ増強するため前記処理サーバ群の処理サーバを準備するサーバ準備部とを含む、情報処理装置。前記目標規模演算部は、前記処理サーバ群の処理サーバで観測されたローカルな負荷を表す評価指標に依存させて前記処理サーバ群の目標規模を演算する、請求項10に記載の情報処理装置。前記目標規模演算部は、前記処理サーバ群の処理サーバで観測された評価指標からボトルネックを判定し、前記処理サーバ群の後段にボトルネックがあると判定された場合に、前記処理サーバ群への転送量と前記代替サーバへの転送量とに応じて、前記処理サーバ群の後段に設けられる第2サーバ群の目標規模を演算し、前記サーバ準備部は、前記第2サーバ群の現在の規模から目標規模へ増強するため前記第2サーバ群の処理サーバを準備する、請求項11に記載の情報処理装置。処理サーバ群を構成する複数の処理サーバの各々にトラフィックを分散するとともに前記処理サーバ群の負荷状態を監視し、前記処理サーバ群が過負荷状態となった際に代替サーバにトラフィックを転送するロードバランサに接続される、情報処理装置が実行するスケーリング方法であって、情報処理装置が、前記処理サーバ群の規模を増強するための増強方向のトリガ条件が成立したことを検知するステップと、情報処理装置が、前記ロードバランサから、前記処理サーバ群へ転送される転送量と前記代替サーバへ転送される転送量とを取得するステップと、情報処理装置が、前記処理サーバ群への転送量と前記代替サーバへの転送量とに応じて前記処理サーバ群の目標規模を演算するステップと、情報処理装置が、前記処理サーバ群の現在の規模から目標規模へ増強するため前記処理サーバ群の処理サーバを準備するステップとを含む、スケーリング方法。前記目標規模を演算するステップは、情報処理装置が、前記処理サーバ群の処理サーバで観測されたローカルな負荷を表す評価指標に依存させて前記処理サーバ群の目標規模を演算するステップであることを特徴とする、請求項13に記載のスケーリング方法。前記スケーリング方法は、情報処理装置が、前記処理サーバ群の処理サーバで観測された評価指標からボトルネックを判定するステップと、情報処理装置が、前記処理サーバ群の後段にボトルネックがあると判定された場合に、前記処理サーバ群への転送量と前記代替サーバへの転送量とに応じて、前記処理サーバ群の後段に設けられる第2サーバ群の目標規模を演算するステップと、情報処理装置が、前記第2サーバ群の現在の規模から目標規模へ増強するため前記第2サーバ群の処理サーバを準備するステップとをさらに含む、請求項14に記載のスケーリング方法。コンピュータ実行可能なプログラムであって、前記プログラムは、コンピュータを、処理サーバ群を構成する複数の処理サーバの各々にトラフィックを分散するとともに前記処理サーバ群が過負荷状態となった際に代替サーバにトラフィックを転送するロードバランサから、前記処理サーバ群へ転送される転送量と前記代替サーバへ転送される転送量とを取得する転送量取得部、前記処理サーバ群への転送量と前記代替サーバへの転送量とに応じて前記処理サーバ群の目標規模を演算する目標規模演算部、および前記処理サーバ群の現在の規模から目標規模へ増強するため前記処理サーバ群の処理サーバを準備するサーバ準備部として機能させるためのプログラム。請求項16に記載のコンピュータ実行可能なプログラムをコンピュータ可読に記録する記録媒体。しかしながら、上述したリアクティブスケーリングによれば、穏やかな需要変化であれば、対応して仮想マシンのインスタンスを増減することができるものの、急激な需要変化には対応することが難しかった。また、上記メトリックに対するしきい値を用いてインスタンス数を増減させる場合、スケール単位台数が固定値では需要変化に柔軟に対応することができない。また、スケール台数を負荷に応じて可変にしようとしても、過負荷状態にあるサーバのスループットはそれ以上増えないため、CPUの平均使用率やネットワーク流量などのメトリックは飽和し、需要に見合った追加台数を見積もることは困難である。したがって、従来のリアクティブスケーリングでは、トリガ条件の成立、所定数のサーバインスタンスの起動、そして起動完了後のトリガ条件の監視というサイクルを1以上の回数繰り返すことで、様子を見ながら段階的に最終的に必要な数のインスタンスが起動されることになり、インスタンスの起動時間分だけ需要の変化への追従に遅れが生じてしまう可能性があった。上記特許文献2に開示されているように、履歴情報を用いて需要予測を行うこともできる場合があるが、過去の実績を超えた需要の変化には対応することができない。プロアクティブスケーリングも、過去の実績から需要予測を事前に行うため、予測を超えた需要の変化には対応することができない。例えば災害時などウェブサイトに突発的に負荷が集中する場合は、その需要を正確に定量して、必要台数のインスタンスを迅速に準備することが望ましい。しかしながら、上述までの従来技術では、予想外の需要変化が突発的に起こった場合には充分に対応することができなかった。本発明は、上記従来技術における不充分な点に鑑みてなされたものであり、本発明は、予想外の需要変化が突発的に起こった場合にも対応してサーバ規模を増加させられるオートスケーリング機構を実現する、情報処理システム、情報処理装置、スケーリング方法、プログラムおよび記録媒体を提供することを目的とする。本発明は、上記課題を解決するために、以下の特徴を有する情報処理システム、情報処理装置を提供する。本情報処理システムは、複数の処理サーバを含む処理サーバ群と、上記処理サーバ群に代替して応答するための代替サーバと、上記処理サーバ群の各処理サーバにトラフィックを分散するとともに、上記処理サーバ群が過負荷状態となった際に代替サーバにトラフィックを転送するロードバランサとを含む。本情報処理システムにおける情報処理装置は、上記ロードバランサにより処理サーバ群へ転送される転送量と代替サーバへ転送される転送量とに応じて、上記処理サーバ群の目標規模を演算し、上記処理サーバ群の現在の規模から目標規模へ増強するため処理サーバを準備する。本発明ではさらに、上記目標規模を演算する際には、上記処理サーバ群の処理サーバで観測されたローカルな負荷を表す評価指標に依存させて上記処理サーバ群の目標規模を演算することができる。さらに、本情報処理システムは、上記処理サーバ群の後段に設けられる第2サーバ群を含むことができ、上記処理サーバ群の処理サーバで観測された評価指標からボトルネックを判定し、上記処理サーバ群の後段にボトルネックがあると判定された場合に、上記処理サーバ群への転送量と上記代替サーバへの転送量とに応じて上記第2サーバ群の目標規模を演算し、上記第2サーバ群の処理サーバを準備することができる。また、上記ロードバランサは、処理サーバ群の応答性能を監視し、応答性能が転送条件を満たした場合に処理サーバ群が過負荷状態であると判定することができ、上記転送量に応じた処理サーバ群の目標規模の演算および該目標規模へ増強するための処理サーバの準備は、上記転送条件と同一の条件が満たされることをトリガとして行うことができる。さらに本発明によれば、上記情報処理システムにおいて実行されるスケーリング方法、上記情報処理装置を実現するためのプログラム、および該プログラムを記録する記録媒体を提供することができる。上記構成によれば、ロードバランサにより処理サーバ群へ転送されるトラフィックの転送量と、代替サーバへ転送されるトラフィックの転送量とを用いてウェブシステムの需要が定量されるため、高精度にシステムの潜在的な需要を定量することができ、ひいては、予想できない需要変化に対しても迅速に対応することが可能となる。以下、本発明について実施形態をもって説明するが、本発明は、後述する実施形態に限定されるものではない。以下説明する実施形態では、情報処理システムとして、物理ホストマシン上で稼働させる仮想マシンのオートスケーリング機構を実現する、プロビジョニングシステムについて説明する。また、以下の説明では、本発明の実施形態によるプロビジョニングシステムを用いて、多層アーキテクチャのウェブシステムをスケーリングする事例について説明する。図1は、本発明の実施形態によるプロビジョニングシステムの概略図を示す。図1に示すプロビジョニングシステム100では、インターネット102を介してエンドユーザにサービスを提供するウェブシステム104が、図示しない物理リソース上の仮想コンピューティングシステムとして構築されている。ウェブシステム104は、ロードバランサ110と、上記ロードバランサ110によりトラフィックが振り分けられ、エンドユーザ側のクライアント端末180からインターネット102を介して送られてくるリクエストを処理するウェブサーバ群120と、上記ウェブサーバ群120の過負荷時に代替してリクエストに対し応答するSorryサーバ124とを含んで構成される。また、図1に示すウェブシステム104は、多層アーキテクチャ構成を採用しており、上記ウェブサーバ群120の後段に、ロードバランサ126によりウェブサーバ群120からのトラフィックが振り分けられるメモリキャッシュサーバ群130が設けられ、上記メモリキャッシュサーバ群130の後段に、データベースサーバ群140が設けられている。上述したウェブサーバ群120を構成するウェブサーバ122a~122z、メモリキャッシュサーバ群130を構成するメモリキャッシュサーバ132a~132z、およびデータベースサーバ群140を構成するデータベースサーバ142a~142zは、それぞれ、図示しない物理ホストマシン上で稼働する仮想マシン仮想サーバとして実現される。物理ホストマシンは、それぞれ、プロセッサやメモリなどのハードウェアリソースを含み、インストールされた仮想化ソフトウェアによって、これらハードウェアリソースが抽象化され、その上で、仮想化されたコンピュータ、すなわち仮想マシンを実現する。物理ホストマシンは、TCP/IPおよびイーサネット登録商標によるLANLocalAreaNetworkや、専用線やまたはVPNVirtualPrivateNetworkにより公衆回線を介して構成される広域ネットワークを介して相互に接続されており、全体としてのリソースプールを提供する。上記ロードバランサ110,126は、それぞれ、物理的な負荷分散装置として、または負荷分散機能を提供する上記仮想マシン上のソフトウェアとして提供される。Sorryサーバ124も同様に、物理的なサーバ装置として、またはSorryサーバ機能を提供する上記仮想マシン上のソフトウェアとして提供される。なお、図1に示す実施形態では、Sorryサーバ124は、独立したモジュールとして説明しているが、上記ロードバランサ110が提供する機能の一部として実装したり、いずれかのウェブサーバ122が提供する機能の一部として実装したりすることもできる。プロビジョニングシステム100は、さらに、管理サーバ150を含む。管理サーバ150は、クラウド利用者側のオペレータ以下、単にクラウド利用者という。に対し、サービスを利用するための管理ポータルサイトを提供する。管理サーバ150は、クラウド利用者が上記管理ポータルサイトを介して行った各種管理要求を処理する管理アプリケーションを備え、管理アプリケーションは、物理リソース上に構築される仮想コンピューティング環境に関する情報を収集し、各種設定を管理し、上記クラウド利用者からの要求に対応して各物理ホストマシンで動作する仮想化ソフトウェアのリモート管理を行う。上述した仮想サーバのインスタンス122,132,142、Sorryサーバ124、ロードバランサ110,126は、管理サーバ150により管理される。クラウド利用者は、管理端末170を用いてインターネット102経由で管理サーバ150にアクセスし、当該サービスの管理ポータルサイトから、予め準備されているOSイメージを選択してプロビジョニング申請することにより、上述したウェブサーバ122、メモリキャッシュサーバ132およびデータベースサーバ142のインスタンスを起動させることができる。またクラウド利用者は、管理ポータルサイトから、ロードバランサ110,126の負荷分散の対象とするインスタンスまたはそのグループの登録、転送先の代替サーバの登録、上記ウェブサーバ122やメモリキャッシュサーバ132のインスタンスの増減を条件付けるオートスケーリング設定など行うことができる。管理サーバ150は、概ね、ワークステーション、ラックマウント型サーバ、ブレード型サーバなどの汎用コンピュータ装置として構成される。管理サーバ150は、より具体的には、シングルコアプロセッサまたはマルチコアプロセッサなどの中央演算装置CPU、キャッシュメモリ、RAMRandomAccessMemory、ネットワークインタフェースカードNIC、ストレージデバイスなどのハードウェアリソースを備え、Windows登録商標、UNIX登録商標、LINUX登録商標などの適切なOSの制御の下、仮想化環境の管理インタフェースとしての機能を提供する。管理サーバ150は、また、上記物理ホストマシン上で稼働する仮想マシンとして実装されてもよい。上記管理端末170およびクライアント端末180a~180zは、概ね、タワー型、デスクトップ型、ラップトップ型またはタブレット型のパーソナルコンピュータ、ワークステーション、ネットブック、PDAPersonalDataAssistanceなどのコンピュータ装置として構成され、上記CPUなどのハードウェアリソースを備えており、Windows登録商標、UNIX登録商標、LINUX登録商標、MacOS登録商標、AIX登録商標などの適切なOSの制御の下動作する。本実施形態では、管理端末170およびクライアント端末180a~180zは、上記OS上で動作するウェブブラウザを実装し、ウェブブラウザを介して管理ポータルサイトや、サービスの提供を受ける。以下、上記ウェブサーバ122、メモリキャッシュサーバ132などの仮想マシンを稼働させる物理ホストマシンの構成について説明する。図2は、本発明の実施形態によるプロビジョニングシステムにおける、物理ホストマシンのハードウェア構成およびソフトウェア構成を示すブロック図である。物理ホストマシン10は、概ね、ワークステーション、ラックマウント型サーバ、ブレード型サーバ、ミッドレンジ、メインフレームなどの汎用コンピュータ装置として構成される。物理ホストマシン10は、ハードウェアリソース20として、CPU22と、メモリ24と、ハードディスクドライブHDDやソリッドステートドライブSSDなどのストレージ26と、NIC28とを含む。物理ホストマシン10は、ハードウェアリソース20上で動作する、Xen登録商標、VMWare登録商標、Hyper-V登録商標などの仮想化ソフトウェアのハイパーバイザ仮想機械モニタとも呼ばれることがある。30を備え、このハイパーバイザ30上で、Windows登録商標、UNIX登録商標、LINUX登録商標などの種々のOSをゲストOSとした仮想マシン40,50を稼働させる。仮想マシン40は、ドメイン0またはペアレントパーティションなどの呼ばれる管理用の仮想マシンであり、管理用仮想マシン40は、仮想リソース42と、管理用OS44と、管理用OS44上で動作する制御モジュール46とを含む。制御モジュール46は、管理サーバ150からの指令を受信して、当該制御モジュール46が動作している物理ホストマシン10上のハイパーバイザ30に対しコマンドを発行するモジュールである。制御モジュール46は、管理サーバ150からの指令に応答して、ハイパーバイザ30に対し、ドメインUまたはチャイルドパーティションなどと呼ばれるユーザドメインの仮想マシンの作成やゲストOSの起動の命令を発行し、管理サーバ150による管理の下、仮想マシンの動作を制御する。仮想マシン50a,50bは、クラウド利用者に対しコンピューティング能力を提供するユーザドメインの仮想マシンである。仮想マシン50は、仮想CPU52、仮想メモリ54、仮想ディスク56および仮想NIC58などの仮想リソースと、ゲストOS60と、該ゲストOS60上で動作する種々のアプリケーション62,64とを含む。アプリケーションは、クラウド利用者に依存するものであり、種々の組み合わせを採用することができる。ウェブサーバ122として仮想マシン50を動作させる場合は、ApacheHTTPServer登録商標、InternetInformationServices登録商標などのウェブサーバ機能を提供するアプリケーションが動作する。メモリキャッシュサーバ132として仮想マシン50を動作させる場合は、memcachedなどの分散メモリキャッシュ機能を提供するアプリケーションが動作する。データベースサーバ142として仮想マシン50を動作させる場合は、DB2登録商標、MySQL登録商標、PostgreSQL登録商標などのデータベース機能を提供するアプリケーションが動作する。上記仮想マシン50は、それぞれ、クラウド利用者からの仮想マシンのプロビジョニング申請に応答して、管理サーバ150の指令によりプロビジョニングされ、クラウド利用者からの仮想マシンのシャットダウン申請に応答して、管理サーバ150の指令によりシャットダウンされる。さらに本発明の実施形態では、需要変化に対応させた仮想マシンのオートスケーリング機構が利用可能とされており、仮想マシン50は、クラウド利用者が定義した仮想マシンの増減を条件付けるオートスケーリング設定のトリガ条件が満たされたことに応答して、プロビジョニングまたはシャットダウンされる。本発明の実施形態によるオートスケーリング機構によれば、ウェブシステム104の需要が定量され、定量された需要に応じて必要な目標サーバ規模が求められ、目標サーバ規模と現状の規模との差分に応じて適時にウェブサーバ群120およびメモリキャッシュサーバ群130の各インスタンスを追加または除去することで、サーバ規模を自動調整することが可能とされる。以下、本発明の実施形態による需要変化に対応させた仮想マシンのオートスケーリング機構の詳細について、図3~図7を参照して説明する。図3は、本発明の実施形態によるプロビジョニングシステムにおいて実現される、需要変化に対応させた仮想マシンのオートスケーリング機構に関連する機能ブロックを示す図である。図3には、管理サーバ150と、管理端末170とが示されており、対象となるウェブシステム104のコンポーネントとして、さらに、ロードバランサ110と、ウェブサーバ群120と、Sorryサーバ124と、メモリキャッシュサーバ群130とが示されている。なお、説明する実施形態では、ウェブサーバ群120およびメモリキャッシュサーバ群130の両方、またはウェブサーバ群120のみをスケーリング対象にすることができる。また、ウェブシステム104の需要を定量するため、ウェブサーバ群120の前段インターネット側に設けられるロードバランサ110が用いられる。なお、スケーリング対象となり、かつ、需要を定量するためのロードバランサによる負荷分散の対象となるウェブサーバ群120は、本実施形態における処理サーバ群を構成し、ウェブサーバ群120の各インスタンスウェブサーバ122は、処理サーバを構成する。本実施形態の管理サーバ150は、サービス管理用のインタフェースを提供する管理ポータル152を含んで構成される。クラウド利用者は、管理端末170のブラウザ172を用いてHTTPプロトコルにより当該管理ポータル152にアクセスし、管理メニューから、オートスケーリング設定を含む種々の管理要求を行うことができる。上記管理ポータル152で行われるオートスケーリング設定としては、1オートスケーリングの基本設定、2需要変化に対応させたオートスケーリングで用いるロードバランサの指定、3指定ロードバランサの負荷分散設定、4サーバ規模の増強を条件付ける増強条件設定、および5サーバ規模の縮小を条件付ける縮小条件設定が含まれる。1オートスケーリングの基本設定は、スケーリング対象となるサーバ群以下、スケーリング対象サーバ群という。の指定、並びに各スケーリング対象サーバ群の仮想マシンのOSイメージやスペック、初期マシン数、最小マシン数および最大マシン数などの設定項目を含む。説明する実施形態では、スケーリング対象サーバ群としては、ウェブサーバ群120およびメモリキャッシュサーバ群130の両方、またはウェブサーバ群120のみが指定される。また、ウェブサーバ群120の最小マシン数Nmin、メモリキャッシュサーバ群130の最小マシン数Mminが指定され、最大マシン数は指定されていないものとして説明する。本発明の実施形態による需要変化に対応させた仮想マシンのオートスケーリング機構では、トリガおよび需要定量のためロードバランサを用いており、説明する実施形態では、2指定ロードバランサとして、インターネット102からのトラフィックをウェブサーバ群120の各ウェブサーバ122へ分散させているロードバランサ110が選択されている。本発明の実施形態によるオートスケーリング機構では、指定ロードバランサの負荷分散設定が、オートスケーリング設定の設定項目として組み込まれている。3指定ロードバランサの負荷分散設定としては、i負荷分散方式、ii負荷分散対象サーバ群の指定、iii代替サーバの指定、およびiv代替サーバへの転送条件が含まれる。i負荷分散方式としては、特に限定されるものではないが、順番にリクエストを振り分けるラウンドロビン方式、所与の比率でリクエストを振り分ける重み付きラウンドロビン方式、コネクションが少ないインスタンスにリクエストを振り分ける最小コネクション数方式、接続中クライアントが少ないインスタンスにリクエストを振り分ける最小クライアント数方式、処理中のデータ通信量が少ないインスタンスにリクエストを振り分ける最小データ通信量方式、応答時間が短いインスタンスにリクエストを振り分ける最小応答時間方式、CPU、メモリ、入出力の使用率が低いインスタンスにリクエストを振り分ける最小サーバ負荷などいかなる負荷分散方式を挙げることができる。また、詳細を後述する既存のユーザによる仕掛かり中のセッションを好適に維持する観点からは、いずれの方式であっても、クライアントから送られてくるリクエストの中で関連のあるリクエストを同じサーバに振り分ける、いわゆるセッション維持機能が有効とされていることが好ましい。セッション維持機能は、リクエストの送信元IPアドレスからクライアントを識別する方式、Cookieクッキーに登録された情報からクライアントを識別する方式、URLに埋め込まれた情報からクライアントを識別するURLリライト方式、HTTPリクエストヘッダの認証情報からクライアントを識別する方式、SSLセッションIDからクライアントを識別する方式など如何なる方式を採用することができる。ii負荷分散対象サーバ群としては、説明する実施形態では、ウェブサーバ群120が指定されており、iii代替サーバとしては、Sorryサーバ124が指定されている。クラウド利用者による負荷分散対象サーバ群および代替サーバの指定に対応して、内部的には、負荷分散対象サーバ群のインスタンス122a~122zおよびSorryサーバ124のIPアドレスやポート番号などを含む通信設定が行われる。iv代替サーバへの転送条件は、一般的には、指定ロードバランサ110の負荷分散対象サーバ群インスタンスの平均CPU使用率、平均メモリ使用率、平均入出力利用度、平均スループット、平均コネクション数、平均クライアント数、平均データ通信量および平均応答性能値などの種々のメトリックに対するしきい値条件を挙げることができるが、ウェブシステム104の過負荷状況を好適に検知する観点からは、上記インスタンスの平均応答時間や平均応答速度などの平均応答性能値に対するしきい値条件を用いることが好ましい。説明する実施形態では、ウェブサーバ群120のインスタンスの平均応答時間がしきい値Rthresholdを超えるという条件を用いる。ここで平均は、時間平均およびインスタンス間平均の一方または両方の意味で用いる。平均応答時間のしきい値Rthresholdは、例えば、クラウドサービスにおけるSLAServiceLevelAgreementで取り決められる値を用いることができる。4増強条件設定は、サーバ規模を増強する方向のスケーリングにおけるトリガ条件以下、増強方向のトリガ条件を増強トリガ条件という。と、増強させるスケール単位以下、増強方向のスケール単位を増強スケール単位という。とを含む。増強スケール単位は、簡便には台数で指定され、固定値および需要に応じた可変値のいずれかを選択することができる。なお、増強スケール単位に需要に応じた可変値が選択された場合に、本発明の実施形態による需要変化に対応させたオートスケーリングが選択されることになる。また、需要に応じた可変値が選択される場合であって、可変値を求める演算方式が複数候補から選択可能である場合は、増強条件設定は、これら演算方式の指定を含むことができる。増強トリガ条件は、一般的には、スケーリング対象サーバ群のインスタンスの平均CPU使用率、平均メモリ使用率、平均入出力利用度、平均スループット、平均コネクション数、平均クライアント数、平均データ通信量および平均応答性能値などの種々のメトリックに対するしきい値条件を挙げることができるが、ウェブシステム104全体の過負荷状態を好適に検知してトリガをかける観点からは、上記指定ロードバランサの負荷分散対象となるウェブサーバ群120の平均応答時間や平均応答速度などの平均応答性能値に対するしきい値条件を用いることが好ましい。また、代替サーバへの転送が発生するということは、ウェブシステム104のサーバ規模が充分ではないことを意味するため、増強トリガ条件は、好適には、上記指定ロードバランサの転送条件と同一の条件を含むことができる。説明する実施形態では、ウェブサーバ群120の増強トリガ条件は、上記指定ロードバランサの転送条件に一致させ、ウェブサーバ群120の平均応答時間がしきい値Rthresholdを超えることを条件とする。また増強トリガ条件は、スケーリング対象サーバ群が複数指定される場合には、各スケーリング対象サーバ群毎に個別に設定することができる。また図3に示すような多層アーキテクチャ構成が採用され、複数のレイヤをスケーリング対象とする場合は、いずれのレイヤが過負荷状態のボトルネックであるかを判定できるような条件を設定することが好ましい。クラウド提供者側で簡単に観測可能なメトリックで、ウェブサーバ群120のインスタンス122のCPUに関連するものとしては、CPUが実際に使用されている時間の割合を示すCPU使用率以下、CPUという場合がある。と、ローカルディスクへの入出力待ちの時間の割合を示す待ち率以下、WAITという場合がある。と、CPUが使用されていないアイドル時間の割合を示すアイドル率以下、IDLEという場合がある。とを挙げることができる。上述したように、ウェブサーバ群120の平均応答時間がしきい値Rthresholdを超えるか否かでウェブシステム104の過負荷状態が判定される場合、平均応答時間がしきい値を超え過負荷状態であると判定されるにもかかわらず、ウェブサーバ群120のインスタンスの平均IDLEが一定値以上あるときは、ウェブサーバ群120でボトルネックが発生しているのではなく、その後段でボトルネックが発生していると推定することができる。このような性質を利用して、ウェブサーバ群120の平均IDLEに対するしきい値UwIDLE-thresholdを用いた条件により、ボトルネックがウェブサーバ群120であるか、またはその後段のメモリキャッシュサーバ群130であるかを判定することができる。説明する実施形態では、メモリキャッシュサーバ群130に対する増強トリガ条件は、ウェブサーバ群120の平均応答時間がしきい値Rthresholdを超え、かつ、ウェブサーバ群120の平均IDLEがしきい値UwIDLE-thresholdを超えるという条件を用いる。5縮小条件設定は、サーバ規模を縮小する方向のスケーリングにおけるトリガ条件以下、縮小方向のトリガ条件を縮小トリガ条件という。と、縮小させるスケール単位以下、縮小方向のスケール単位を縮小スケール単位という。とを含む。縮小スケール単位は、簡便には台数で指定され、固定値または需要に応じた可変値を選択することができる。縮小トリガ条件は、上述したものと同様の種々のメトリックに対するしきい値条件を用いることができる。説明する実施形態では、ウェブサーバ群120の縮小トリガ条件としては、ウェブサーバ群120の平均リソース使用率に対するしきい値Uwavg-thresholdが用いられ、メモリキャッシュサーバ群130の縮小トリガ条件は、メモリキャッシュサーバ群130の平均リソース使用率に対するしきい値Umavg-thresholdが用いられる。図4は、本発明の実施形態によるプロビジョニングシステム100において、管理ポータルが提供するオートスケーリング設定を行うための管理画面を例示する。図4に示す管理画面200は、オートスケーリング基本設定タブ210aと、ウェブサーバ群用設定タブ210bと、メモリキャッシュサーバ群用設定タブ210cとを含む。図4に示す状態では、ウェブサーバ群用設定タブ210bが選択されており、ウェブサーバ群120に関連する設定項目を指定するためのグラフィカルユーザインタフェースGUI部品が配置されている。図4に示す例では、ウェブサーバ群120のオートスケーリング機能の有効または無効を選択するチェックボックス212と、ウェブサーバ群120のスケーリング方式を選択するためのラジオボタン214a,214bとが示されている。オートスケーリング方式としては、スケール単位台数固定方式214aと、スケール単位台数可変方式214bとが選択可能に示されており、図4ではスケール単位台数可変方式214bが選択されている。なお、本発明の実施形態による需要変化に対応した仮想マシンのオートスケーリング機構は、スケール単位台数可変方式に相当する。スケール単位台数可変方式214bの詳細な設定項目としては、増強条件設定と、縮小条件設定とが含まれる。増強条件設定および縮小条件設定は、各プルダウンメニュー216,218,220,222の各選択肢を選択することによりそれぞれ設定される。図4は、増強条件設定に関連して、ロードバランサが計測するウェブサーバ群120の平均応答時間が50msを上回ることを転送条件および増強トリガ条件とするという設定内容を表している。また、図4は、ウェブサーバ群120の平均CPU使用率が20以下となることを縮小トリガ条件とし、縮小スケール単位を固定台数1とするという設定内容を表している。なお、図4は、ウェブサーバ群120のための管理設定画面を例示しているが、メモリキャッシュサーバ群130のための管理設定画面や、基本設定のための管理設定画面については、詳細な説明は割愛する。再び図3を参照すると、管理サーバ150は、さらに、オートスケーリング機構を実現するための機能部として、負荷分散設定部154と、カウンタ更新部156と、目標規模演算部158と、縮小規模決定部160と、サーバ準備部162とを含んで構成される。負荷分散設定部154は、クラウド利用者から管理ポータル152を介してなされる上記オートスケーリング設定の管理要求に応答して、上述した指定ロードバランサの負荷分散設定をロードバランサ110に対して行う。ロードバランサ110に対して行われる設定項目としては、具体的には、負荷分散方式の設定、負荷分散対象の仮想マシンおよび代替サーバのIPアドレスなどの通信設定、並びに転送条件が含まれる。ロードバランサ110は、上記負荷分散設定部154による設定を受けて、インターネット102を介して行われるリクエストをウェブサーバ群120の各インスタンス122に振り分けるとともに、上記転送条件の成立を監視し、上記ウェブシステム104が過負荷状態となったことを検知した際には、Sorryサーバ124へリクエストを転送する。Sorryサーバ124は、ウェブサーバ群120が過負荷状態になった場合に、転送されるリクエストに対し、ユーザに対し混雑中である旨のメッセージを代替して応答するウェブサーバである。また、Sorryサーバ124は、代替応答という処理に関して、実質的に無限大の処理能力を有すると見なせるサーバである。なお、代替サーバとしてのSorryサーバは、説明する実施形態では1台としているが、複数台用意してもよい。本実施形態のロードバランサ110は、負荷分散対象である各ウェブサーバ122が正常に動作していることを確認するために、また転送条件の成立を監視するために、各ウェブサーバ122に対しキープアライブパケットを定期的に送り、各ウェブサーバ122の応答時間Ra~Rcをモニタしている。ロードバランサ110は、応答時間が所与の時間を越える事象が所与の回数連続して確認された場合、そのウェブサーバ122がダウン状態であると判断し、負荷分散対象から切り離す。またロードバランサ110は、計測された応答時間の時間平均およびインスタンス平均を計算し、平均応答時間がしきい値Rthresholdを超え上記転送条件が満たされる場合には、Sorryサーバ124に対するリクエストの転送を行う。ロードバランサ110がSorryサーバ124へ転送するリクエストとしては、好適には、新規ユーザからのリクエストのみを対象とし、既にセッションを確立している既存ユーザからのリクエストを転送対象から除外することができる。これにより、既存ユーザによる仕掛かり中のセッションに影響を与えずに、過剰なリクエストを処理することが可能となる。また本実施形態のロードバランサ110は、ウェブシステム104の需要を定量するために、ウェブサーバ群120への単位時間当たりの転送量と、Sorryサーバ124への単位時間当たりの転送量とを計測し、計測値を記憶する。上記転送量は、ウェブサーバ122またはSorryサーバ124へ転送されるコネクション数やデータ通信量を用いて定量することができるが、ウェブシステム104の需要を正確に定量する観点からは、コネクション数、クライアント数またはセッション数などを用いることが好ましい。これは、ウェブサーバ122によるレスポンスでは大きなデータトラフィックが発生し得るのに対して、Sorryサーバ124へ転送されるリクエストに対しては、混雑中である旨のメッセージという小さなデータのレスポンスを主として発生させるにすぎず、コネクション数、クライアント数またはセッション数を用いた方が、ウェブシステム104の需要をより精度良く定量できるためである。カウンタ更新部156は、本発明の実施形態による需要変化に対応させたオートスケーリングを行うために必要な監視カウンタ値を、定期的または不定期に情報を収集して更新する。必要な監視カウンタ値としては、ロードバランサ110の平均応答時間Ravg、ウェブサーバ群120への単位時間当たりの転送量Tweb、Sorryサーバ124への単位時間当たりの転送量Tsorryといったロードバランサ110から取得されるメトリックが含まれる。必要な監視カウンタ値としては、さらに、ウェブサーバ群120のインスタンス122の平均CPUUwCPU、平均WAITUwWAITおよびIDLEUwIDLE、並びにメモリキャッシュサーバ群130のインスタンス132のCPUUmCPU、WAITUmWAITおよびIDLEUmIDLEといったスケール対象サーバ群のインスタンスから取得されるメトリックが含まれる。これらインスタンスから取得されるメトリックは、時間平均またはインスタンス平均が計算されてカウンタに保持される。なお、上記ウェブサーバ群120のインスタンス122の平均CPUUwCPUおよび平均WAITUwWAITは、上記ウェブサーバ122のローカルな負荷を評価する評価指標として用いられ、IDLEUwIDLEは、上述したボトルネックを判定するための評価指標として用いられる。必要な監視カウンタ値としては、さらに、ウェブサーバ群120において稼働中のインスタンス数Nrunningおよび準備中のインスタンス数Nprovisioning、並びにメモリキャッシュサーバ群130において稼働中のインスタンス数Mrunningおよび準備中のインスタンス数Mprovisioningといった仮想マシンのプロビジョニングを管理するサーバ準備部162から取得される状態変数が含まれる。カウンタ更新部156は、本実施形態の転送量取得部を構成する。目標規模演算部158は、更新される監視カウンタ値を参照して、増強トリガ条件の成立を監視し、増強トリガ条件が成立した場合に、指定ロードバランサにより処理サーバ群へ転送される単位時間当たりの転送量と、代替サーバへ転送される単位時間当たりの転送量とを基準として、処理サーバ群の目標サーバ規模を演算する。図3に示す例では、目標規模演算部158は、ウェブサーバ群120への転送量Twebと、Sorryサーバ124への転送量Twebとから、ウェブシステム104の需要を定量し、需要に応じてウェブサーバ群120およびメモリキャッシュサーバ群130の目標サーバ規模を演算する。上述した目標サーバ規模は、目標とすべきサーバの規模を表し、サーバ群のインスタンスのスペックが概ね同一であれば、単純にサーバ台数インスタンス数で定量することができる。処理サーバ群のインスタンスのスペックが異なる場合は、適宜各インスタンスのスペックに応じて適切な補正を施せばよい。なお、本実施形態では、説明の便宜上、目標サーバ規模をサーバ台数で定量する。下記式1~3は、目標サーバ規模を求めるための演算式を例示する。なお、下記式1~3中の関数Ceilは、天井関数を表す。上記式1および式2は、それぞれ、ウェブサーバ群120のみをスケーリング対象とした場合に用いることができる演算式を表す。上記式2および式3は、ウェブサーバ群120およびメモリキャッシュサーバ群130の両方をスケーリング対象とした場合に、ウェブサーバ群120およびメモリキャッシュサーバ群130それぞれについて用いられる演算式を表す。上記式1および上記式2は、ウェブサーバ群120の目標サーバ規模Ntargetを算出し、上記式3は、メモリキャッシュサーバ群130の目標サーバ規模Mtargetを演算するための演算式を表す。上記式2中、UwCPUUwWAITは、ウェブサーバ122のローカルでの負荷の評価を反映させるために導入されたものである。目標規模演算部158は、さらに、上記目標サーバ規模と現在のサーバ規模との差分から、増強スケール単位を計算し、サーバ準備部162に対し、処理サーバ群のインスタンスのプロビジョニングを依頼する。現在のサーバ規模および増強スケール単位も同様に、処理サーバ群のインスタンスのスペックが概ね同一であれば、単純にサーバ台数で定量することができ、本実施形態では、説明の便宜上、上述した現在のサーバ規模およびスケール単位をサーバ台数で定量する。現在のサーバ規模は、観測時点での稼働中のインスタンスの台数と、プロビジョニングが完了していない準備中のインスタンスの台数との和で求められ、増強スケール単位は、目標サーバ規模と現在のサーバ規模との差分として求められる。説明する実施形態では、目標規模演算部158は、ウェブサーバ群120の目標サーバ規模Ntargetと現在のサーバ規模NrunningNprovisioningとの差分からウェブサーバ群120のインスタンスの追加台数Naddを算出し、必要に応じて、メモリキャッシュサーバ群130の目標サーバ規模Mtargetと現在のサーバ規模MrunningMprovisioningとの差分からメモリキャッシュサーバ群130のインスタンスの追加台数Maddを算出することができる。なお、説明する実施形態では、ウェブサーバ群120の目標サーバ規模Ntargetと現在のサーバ規模NrunningNprovisioningとの差分からウェブサーバ群120のインスタンスの追加台数Naddを算出し、一律に追加台数として決定するものとして説明する。しかしながら、他の実施形態では、履歴を用いた需要予測を行う手法と組み合わせることもできる。例えば、ロードバランサを用いて定量された需要に応じて目標サーバ規模を求めるとともに、履歴情報を用いた需要予測により予測サーバ規模を求め、ロードバランサを用いて定量された需要が、履歴情報からの需要予測よりも過小評価されている場合に、需要予測に基づいて求められたサーバ規模を選択することができる。これにより、予測できない需要変化に対応させつつ、需要予測からの補正を行うことが可能となる。縮小規模決定部160は、更新されるカウンタを参照して縮小トリガ条件の成立を監視し、縮小トリガ条件が成立した場合に、処理サーバ群の縮小サーバ規模を決定する。縮小規模決定部160は、縮小スケール単位が、固定台数であればその値に決定し、可変台数であれば、リソース使用率から適切なサーバ規模を演算し、現在のサーバ規模と演算したサーバ規模との差分から必要な縮小スケール単位を求めることができる。なお、縮小スケーリングの際の適切なサーバ規模は、縮小スケーリング時は通常余剰リソースが存在するため、上述した転送量を用いずともCPU使用率などのリソース使用率から簡単に計算することができる。図3に示す実施形態では、縮小規模決定部160は、ウェブサーバ群120のインスタンスの除去台数Nremoveを決定し、必要に応じてメモリキャッシュサーバ群130のインスタンスの除去台数Mremoveを決定することができる。サーバ準備部162は、増強方向のスケーリングにおいては、処理サーバ群の現在のサーバ規模から目標サーバ規模へ増強するため、処理サーバ群のインスタンスをプロビジョニングする処理を行う。さらに、サーバ準備部162は、縮小方向のスケーリングにおいては、縮小規模決定部160が決定した縮小スケール単位に応じて、処理サーバ群のインスタンスのシャットダウンする処理を行う。図3に示す実施形態では、サーバ準備部162は、増強方向のスケーリングでは、目標規模演算部158により演算された追加台数Naddのウェブサーバ群120のインスタンスのプロビジョニングを実行し、適宜、追加台数Maddのメモリキャッシュサーバ群130のインスタンスのプロビジョニングを実行する。また、サーバ準備部162は、稼働中インスタンス数Nrunning,Mrunningと、準備中インスタンス数Nprovisioning,Mprovisioningとを管理しており、カウンタ更新部156に通知する。縮小方向のスケーリングでは、サーバ準備部162は、縮小規模決定部160により決定された除去台数Nremove,Mremove,のウェブサーバ群120およびメモリキャッシュサーバ群130のインスタンスのシャットダウンを実行することができる。図5は、本発明の実施形態によるプロビジョニングシステムにおいて実現される、需要変化に対応させたオートスケーリング処理を示すフローチャートである。なお、図5は、ウェブサーバ群120のみをスケーリング対象サーバ群とし、上記式1を用いて目標サーバ規模を演算する場合のオートスケーリング処理を示す。また、図5に示す処理が開始される時点において、ウェブサーバ群120、メモリキャッシュサーバ群130およびデータベースサーバ群140の各インスタンスは、既に所定数配備されており、転送条件および増強トリガ条件である平均応答時間に対するしきい値Rthreshold、ウェブサーバ群120の最小マシン数Nmin、縮小条件としてのウェブサーバ群120の平均リソース使用率に対するしきい値Uwavg-thresholdを含むオートスケーリング設定が設定済みであるとして説明する。図5に示す処理は、例えばウェブシステム104のオートスケーリング機能が有効化されたことに応答してステップS100から開始される。ステップS101では、カウンタ更新部156は、ロードバランサ110、ウェブサーバ122およびサーバ準備部162から情報を収集し、監視カウンタ値を更新する。図5に示す処理で用いられる監視カウンタ値は、平均応答時間Ravg、ウェブサーバ群120への単位時間当たりの転送量Tweb、Sorryサーバ124への単位時間当たりの転送量Tsorry、ウェブサーバ群120の平均リソース使用率Uwavg、ウェブサーバ群120の稼働中インスタンス数Nrunning、ウェブサーバ群120の準備中インスタンス数Nprovisioningである。ステップS102では、目標規模演算部158は、監視カウンタ値を参照して、平均応答時間Ravgがしきい値Rthresholdを超えているか否かを判定する。ステップS102で、平均応答時間Ravgがしきい値Rthresholdを超えていると判定された場合YESには、ステップS103へ処理が進められる。ステップS103では、目標規模演算部158は、上記監視カウンタ値を参照し、上記式1に従いウェブサーバ群120の目標サーバ規模Ntargetを演算する。ステップS104では、目標規模演算部158は、目標サーバ規模Ntargetと、稼働中および準備中のインスタンス数の和NrunningNprovisioningとを比較して、目標サーバ規模Ntargetの方が大きいか否かを判定する。ステップS104で、目標サーバ規模Ntargetの方が大きいと判定された場合YESには、ステップS105へ処理が進められる。ステップS105では、目標規模演算部158は、目標サーバ規模と現在規模との差分Ntarget-NrunningNprovisioningを算出し、これを追加台数Naddとして、サーバ準備部162にプロビジョニングを依頼する。ステップS106では、サーバ準備部162は、適当な物理ホストマシン10を選択して、物理ホストマシン10上の制御モジュール46に対しプロビジョニングを要求し、合計Nadd台のウェブサーバ群120のインスタンスを準備し、所与のインターバルが経過した後ステップS101へ処理をループし、カウンタ更新および増強トリガ条件の成立の監視を繰り返す。一方、ステップS104で、目標サーバ規模Ntargetの方が大きくないと判定された場合NOは、適当なインターバルが経過した後、直接ステップS101へ処理をループし、カウンタ更新およびトリガ条件の成立の監視を繰り返す。一方、ステップS102で、平均応答時間Ravgがしきい値Rthresholdを超えないと判定された場合NOには、ステップS107へ処理が分岐される。この場合は、増強トリガ条件が成立しておらず、続いて、縮小トリガ条件の成立を監視する。ステップS107では、縮小規模決定部160は、ウェブサーバ群120の準備中インスタンスが存在せずNprovisioning=0、かつ、ウェブサーバ群120の稼働中インスタンス数が最小マシン数Nminを超えておりNrunning>Nmin、かつウェブサーバ群120の平均リソース使用率Uwavgが閾値Uwavg-thresold未満であるか否かを判定する。ここで、平均リソース使用率Uwavgは、ウェブサーバ群120のローカルの負荷を指標するものであり、例えばウェブサーバ群120の平均CPU使用率CPU、または平均CPU使用率CPUと待ち率WAITとの和を用いることができる。ステップS107で、すべての条件が満たされると判定された場合YESには、ステップS108へ処理を進める。ステップS108では、縮小規模決定部160は、現時点の稼働中インスタンス数Nrunningから除去台数Nremoveのインスタンスを除去する結果として最小マシン数Nminを下回らない限度において、除去台数Nremoveを決定し、サーバ準備部162にシャットダウンを依頼する。例えば、縮小条件として除去台数に固定数が設定されているのであれば、上記限度を満たす範囲で1~固定数を除去台数Nremoveとして決定する。縮小条件として除去台数に可変数が設定されているのであれば、可変数を一旦計算し、上記限度を満たす範囲で1~可変数を除去台数Nremoveとして決定する。可変数の値は、上述したように、ウェブサーバ群120の平均リソース使用率Uwavgから求めることができる。ステップS109では、サーバ準備部162は、ウェブサーバ群120の全インスタンスから上記除去台数Nremove分のインスタンスを選択して、選択されたインスタンスが稼働する各物理ホストマシン10の制御モジュール46に対しシャットダウンを要求し、合計NRemove個のウェブサーバ群120のインスタンスを除去し、適当なインターバルが経過した後ステップS101へ処理をループし、カウンタ更新およびトリガ条件の成立の監視を繰り返す。一方、ステップS107で、すべての条件が満たされるわけではないと判定された場合NOには、適当なインターバルが経過した後、直接ステップS101へ処理をループし、カウンタ更新およびトリガ条件の成立の監視を繰り返す。図6および図7は、本発明の実施形態によるプロビジョニングシステムにおいて実現される、需要変化に対応させた他のオートスケーリング処理を示すフローチャートである。なお、図6および図7は、ウェブサーバ群120およびメモリキャッシュサーバ群130の両方をスケーリング対象サーバ群とし、上記式2および式3を用いて各目標サーバ規模を演算する場合のオートスケーリング処理を示す。また、図6および図7に示す処理が開始される時点において、図5と同様に、ウェブサーバ群120、メモリキャッシュサーバ群130およびデータベースサーバ群140の各インスタンスは、既に所定数配備されており、転送条件および増強トリガ条件である平均応答時間に対するしきい値Rthresholdと、メモリキャッシュサーバ群130の増強トリガ条件であるウェブサーバ群120の平均IDLEに対するしきい値UwIDLE-thresholdと、ウェブサーバ群120の最小マシン数Nminと、メモリキャッシュサーバ群130の最小マシン数Mminと、縮小条件としてのウェブサーバ群120の平均リソース使用率Uwavgに対するしきい値Uwavg-threshold、メモリキャッシュサーバ群130の平均リソース使用率Umavgに対するしきい値Umavg-thresholdとを含むオートスケーリング設定が設定済みであるとして説明する。図6および図7に示す処理は、例えばウェブシステム104のオートスケーリング機能が有効化されたことに応答してステップS200から開始される。ステップS201では、カウンタ更新部156は、ロードバランサ110、ウェブサーバ122、メモリキャッシュサーバ132およびサーバ準備部162から情報を収集し、監視カウンタ値を更新する。図6および図7に示す処理で用いられる監視カウンタ値は、図5を参照して説明した平均応答時間Ravg、ウェブサーバ群120への転送量Tweb、Sorryサーバ124への転送量Tsorry、平均リソース使用率Uwavg、稼働中インスタンス数Nrunning、準備中インスタンス数Nprovisioningに加えて、さらに、メモリキャッシュサーバ群130の平均リソース使用率Umavgと、メモリキャッシュサーバ群130の稼働中インスタンス数Mrunningと、メモリキャッシュサーバ群130の準備中インスタンス数Mprovisioningとを含む。ステップS202では、目標規模演算部158は、監視カウンタ値を参照して、平均応答時間Ravgがしきい値Rthresholdを超えているか否かを判定する。ステップS202で、平均応答時間Ravgがしきい値Rthresholdを超えていると判定された場合YESには、ステップS203へ処理が進められる。ステップS203では、目標規模演算部158は、監視カウンタ値を参照して、上記メモリキャッシュサーバ群130の増強トリガ条件のひとつであるウェブサーバ群120の平均IDLEUwIDLEがしきい値UwIDLE-thresholdを超えているか否かを判定する。ステップS203で、平均IDLEUwIDLEがしきい値UwIDLE-thresholdを超えていると判定された場合YESには、ステップS204へ処理が進められる。ステップS204では、目標規模演算部158は、上記監視カウンタ値を参照し、上記式3に従いメモリキャッシュサーバ群130の目標サーバ規模Mtargetを演算する。ステップS205では、目標規模演算部158は、メモリキャッシュサーバ群130の目標サーバ規模Mtargetの方が、稼働中および準備中のインスタンスの和MrunningMprovisioningよりも大きいか否かを判定する。ステップS205で、目標サーバ規模Mtargetの方が大きいと判定された場合YESには、ステップS206へ処理が進められる。ステップS206では、目標規模演算部158は、目標サーバ規模と現在規模との差分Mtarget-MrunningMprovisioningを算出し、これをメモリキャッシュサーバ132の追加台数Maddとして、サーバ準備部162にプロビジョニングを依頼する。ステップS207では、サーバ準備部162は、適当な物理ホストマシン10を選択してプロビジョニングを要求し、合計Madd台のメモリキャッシュサーバ群130のインスタンスを準備し、ステップS208へ処理を進める。ステップS203で、平均IDLEUwIDLEがしきい値UwIDLE-thresholdを超えていないと判定された場合NO、およびステップS205で目標サーバ規模Mtargetの方が大きくはないと判定された場合NOには、直接ステップS208へ処理を進める。ステップS208では、目標規模演算部158は、上記監視カウンタ値を参照し、上記式2に従いウェブサーバ群120の目標サーバ規模Ntargetを演算する。ステップS209では、目標規模演算部158は、ウェブサーバ群120の目標サーバ規模Ntargetの方が稼働中および準備中のインスタンスの和NrunningNprovisioningよりも大きいか否かを判定する。ステップS209で、目標サーバ規模Ntargetの方が大きいと判定された場合YESには、ステップS210へ処理が進められる。ステップS210では、目標規模演算部158は、目標サーバ規模と現在規模との差分Ntarget-NrunningNprovisioningをウェブサーバ122の追加台数Naddとして、サーバ準備部162にプロビジョニングを依頼する。ステップS211では、サーバ準備部162は、適当な物理ホストマシン10を選択してプロビジョニングを要求し、合計Nadd台のウェブサーバ群120のインスタンスを準備し、所与のインターバルが経過した後ステップS201へ処理をループし、カウンタ更新および増強トリガ条件の成立の監視を繰り返す。ステップS209で、目標サーバ規模Ntargetの方が大きくはないと判定された場合NOには、所与のインターバルが経過した後ステップS201へ処理をループさせられる。一方、ステップS202で、平均応答時間Ravgがしきい値Rthresholdを超えないと判定された場合NOには、ポイントAを経て、図7に示すステップS212へ処理が分岐される。この場合は、増強トリガ条件が成立しておらず、続けて縮小トリガ条件の成立を監視する。ステップS212では、縮小規模決定部160は、ウェブサーバ群120の準備中インスタンスが存在せずNprovisioning=0、かつ、ウェブサーバ群120の稼働中インスタンス数が最小マシン数Nminを超えておりNrunning>Nmin、かつウェブサーバ122の平均リソース使用率Uwavgが閾値Uwavg-thresold未満であるか否かを判定する。ステップS212で、すべての条件が満たされると判定された場合YESには、ステップS213へ処理を進める。ステップS213では、縮小規模決定部160は、現時点の稼働中インスタンス数Nrunningから除去台数Nremoveのインスタンスを除去する結果として最小マシン数Nminを下回らない限度において、除去台数Nremoveを決定し、サーバ準備部162にシャットダウンを依頼する。ステップS214では、サーバ準備部162は、ウェブサーバ群120のインスタンスを稼働させている物理ホストマシン10に対しシャットダウンを要求し、合計Nremove台のインスタンスを除去し、ステップS215へ処理を進める。ステップS212で、すべての条件が満たされるわけではないと判定された場合NOには、直接ステップS215へ処理を進める。ステップS215では、縮小規模決定部160は、メモリキャッシュサーバ群130の準備中インスタンスが存在せずMprovisioning=0、かつ、メモリキャッシュサーバ群130の稼働中インスタンス数が最小マシン数を超えておりMrunning>Mmin、かつメモリキャッシュサーバ132の平均リソース使用率Umavgがしきい値Umavg-thresold未満であるか否かを判定する。ステップS215で、すべての条件が満たされると判定された場合YESには、ステップS216へ処理を進める。ステップS216では、縮小規模決定部160は、現時点の稼働中インスタンス数Mrunningから除去台数Mremoveのインスタンスを除去する結果として最小マシン数Mminを下回らない限度において、除去台数Mremoveを決定し、サーバ準備部162にシャットダウンを依頼する。ステップS217では、サーバ準備部162は、メモリキャッシュサーバ群130のインスタンスを稼働させている物理ホストマシン10に対しシャットダウンを要求し、合計Mremove個のインスタンスを除去し、適当なインターバルが経過した後、ポイントBを経て図6に示すステップS201へ処理をループし、カウンタ更新およびトリガ条件の成立の監視を繰り返す。一方、ステップS215で、すべての条件が満たされるわけではないと判定された場合NOには、適当なインターバルが経過した後、直接ポイントBを経て図6に示すステップS201へ処理をループし、カウンタ更新およびトリガ条件の成立の監視を繰り返す。図8は、本発明の実施形態によるプロビジョニングシステムにおいて、他の多層アーキテクチャ構成を採用するウェブシステムをスケーリングする事例について説明する図である。図8に示すウェブシステム300において、需要変化に応じたオートスケーリングを行う場合、スケーリング対象サーバ群として、さらにアプリケーションサーバ群344を追加することができる。この場合、アプリケーションサーバ群344の目標サーバ規模は、ウェブサーバ群320の目標サーバ規模に連動させて、または上記1~3と同様な演算式を用いて独立して求めればよい。以上説明した本発明の実施形態のオートスケーリング機構によれば、増強方向のスケーリングにおいて、ロードバランサにより処理サーバ群へ転送されるトラフィックの転送量と、代替サーバへ転送されるトラフィックの転送量とを用いてウェブシステムの需要が定量され、定量された需要から求められた目標サーバ規模と、現在のサーバ規模との差分を補うように処理サーバ群のインスタンスが準備される。増強方向のスケーリングにおいては、一般に、システムの潜在的な需要を定量することは困難である。図9は、従来技術のオートスケーリングによるウェブサーバのインスタンス数の経時変化を示すグラフである。図9に示す従来技術のオートスケーリングでは、平均CPU使用率が80以上となった場合に新たに1台のインスタンスを追加し、平均CPU使用率が20以下となった場合に1台のインスタンスを除去するという定義によるものである。図9においては、ウェブサーバの平均CPU使用率の経時変化を棒グラフ左軸で示し、ウェブサーバのインスタンス数を折れ線グラフ右軸で表している。図9を参照すると、急激に増加されたウェブトラフィックに対応して、平均CPU使用率がほぼ飽和状態となり、一方、ウェブサーバのインスタンスが順次追加され、1時間以上をかけて最終的な14台までウェブサーバのインスタンスが起動されている様子がわかる。図9に示す従来技術では、スケール単位台数が固定台数であり、固定台数分のインスタンスで賄える負荷を超えた需要には迅速対応することができず、インスタンスの起動時間分だけ需要の変化への追従に遅れが生じてしまう可能性がある。また固定台数ずつ増加させるため、不必要なインスタンスが準備されてしまう可能性もある。仮にスケール台数を負荷に応じて可変にしようとしても、過負荷状態にあるサーバのスループットはそれ以上増えないため、CPUの平均使用率やネットワーク流量などのメトリックは飽和してしまい、需要に見合った追加台数を見積もることは通常困難である。例えば、図9に示す例において、当初より最終的に必要となった14台分の1400の合計CPU使用率を測定することができれば、14台のインスタンスを一挙に起動することができるが、棒グラフにも示すように、平均CPU使用率は100で飽和するため、平均CPU使用率をメトリックとしても需要を正確に見積もることはできない。これは、ネットワーク流量、メモリ使用率などの各インスタンスから取得されるメトリックを用いる場合でも同様である。これに対して本発明の実施形態のオートスケーリング機構では、ロードバランサおよび代替サーバを用いており、ロードバランサにより処理サーバ群へ転送されるトラフィックの転送量と、代替サーバへ転送されるトラフィックの転送量とを用いてウェブシステムの需要が定量されるため、上記CPUやネットワーク流量などのメトリックが飽和してしまうような需要変化があっても、正しく需要を定量することができ、ひいては、予想できない需要変化に対しても迅速に対応することが可能である。さらに、代替サーバは、代替応答という処理に関しては、実質的に無限大の処理能力を有すると見なせるサーバであり、容易にはスループットが飽和しないため、現時点のサーバ規模で賄える需要を大幅に超える急変が起こったとしても需要を正確に定量することが可能となる。また、本発明の実施形態では、ロードバランサおよび仮想マシンから取得されるメトリックだけを用いて目標サーバ規模を求めることができるため、仮想マシン自体の構成がクラウド利用者側にゆだねられるためにクラウド提供者側でその内部情報を取得することが一般に困難であるクラウド環境においても、正確なリアクティブオートスケーリングを実現することが可能となる。また、上述したオートスケーリング機構によれば、エンドユーザは、トラフィック急増時の待ち時間が低減されるというメリットを得ることができる。さらに、新規リクエストのみを代替サーバへの転送対象とすれば、エンドユーザは、さらに、混雑時でも既存のセッションがタイムアウトすることがないというメリットを得ることができる。また、クラウド利用者側の視点では、サーバダウンによるチャンスロスを低減し、不必要なサーバを減らすことで運用コストを削減し、詳細な需要予測や監視に費やす人件費を削減できるというメリットを得ることができる。以上説明したように、本発明の実施形態によれば、予想外の需要変化が突発的に起こった場合にも対応してサーバ規模を増加させられるオートスケーリング機構を実現する、情報処理システム、情報処理装置、スケーリング方法、プログラムおよび記録媒体を提供することができる。本発明の実施形態によるプロビジョニングシステムは、コンピュータ実行可能なプログラムを、コンピュータシステムにロードして各機能部を実現することにより提供される。このようなプログラムとしては、例えば、FORTRAN、COBOL、PL/I、C、C、Java登録商標、Java登録商標Beans、Java登録商標Applet、Java登録商標Script、Perl、Rubyなどのレガシープログラミング言語や、オブジェクト指向プログラミング言語などで記述された、コンピュータ実行可能なプログラムにより実現でき、装置可読な記録媒体に格納して頒布することができる。これまで本発明を図面に示した実施形態および実施例をもって説明してきたが、本発明は図面に示した実施形態に限定されるものではなく、他の実施形態、追加、変更、削除など、当業者が想到することができる範囲内で変更することができ、いずれの態様においても本発明の作用効果を奏する限り、本発明の範囲に含まれるものである。"