分散処理を行うための現用クラスタを構成し、更新前ファイルを用いて対向装置にサービスを提供する複数の第1のサーバと、分散処理を行うための新設クラスタを構成し、更新後ファイルを用いて対向装置にサービスを提供する複数の第2のサーバと、対向装置からのリクエストを前記第1のサーバおよび第2のサーバに振り分けるロードバランサと、前記第1のサーバと、前記第2のサーバと、前記ロードバランサと連携し、前記第1のサーバおよび前記第2のサーバの分散処理を制御する分散処理管理装置と、を備えるサービス提供システムであって、前記分散処理管理装置の制御手段が、サーバリソースプールから所定量の資源が割り当てられる前記複数の第2のサーバの一部に更新後ファイルを送信し、前記更新後ファイルを送信した前記第2のサーバを起動させる起動制御と、前記現用クラスタおよび前記新設クラスタを監視し、前記現用クラスタおよび前記新設クラスタでのトラフィック量と、稼動中の前記第1のサーバおよび前記第2のサーバのCPU使用率とにより、稼動中の前記第2のサーバに振り分けるリクエストの新たなリクエスト量を算出し、前記算出したリクエスト量を実現するように、前記ロードバランサが前記第1のサーバおよび前記第2のサーバにリクエストを振り分けるための振り分けルールを作成し、作成した振り分けルールを前記ロードバランサに設定させる設定制御と、前記ロードバランサに設定した振り分けルールにより、割り当てが不要になった資源を前記サーバリソースプールに戻すため、前記複数の第1のサーバの一部を停止させる停止制御と、前記起動制御と、前記設定制御と、前記停止制御とを繰り返し、前記現用クラスタから前記新設クラスタへの切り替えを実行することを特徴とするサービス提供システム。前記分散処理管理装置の制御手段が、前記第2のサーバに送信した更新後ファイルのエラー監視を実行することを特徴とする請求項1に記載のサービス提供システム。分散処理を行うための現用クラスタを構成し、更新前ファイルを用いて対向装置にサービスを提供する複数の第1のサーバと、分散処理を行うための新設クラスタを構成し、更新後ファイルを用いて対向装置にサービスを提供する複数の第2のサーバと、対向装置からのリクエストを前記第1のサーバおよび第2のサーバに振り分けるロードバランサと、前記第1のサーバと、前記第2のサーバと、前記ロードバランサと連携し、前記第1のサーバおよび前記第2のサーバの分散処理を制御する分散処理管理装置と、を備えるサービス提供システムにおけるファイル更新方法であって、前記分散処理管理装置の制御手段が、サーバリソースプールから所定量の資源が割り当てられる前記複数の第2のサーバの一部に更新後ファイルを送信し、前記更新後ファイルを送信した前記第2のサーバを起動させる起動ステップと、前記現用クラスタおよび前記新設クラスタを監視し、前記現用クラスタおよび前記新設クラスタでのトラフィック量と、稼動中の前記第1のサーバおよび前記第2のサーバのCPU使用率とにより、稼動中の前記第2のサーバに振り分けるリクエストの新たなリクエスト量を算出し、前記算出したリクエスト量を実現するように、前記ロードバランサが前記第1のサーバおよび前記第2のサーバにリクエストを振り分けるための振り分けルールを作成し、作成した振り分けルールを前記ロードバランサに設定させる設定ステップと、前記ロードバランサに設定した振り分けルールにより、割り当てが不要になった資源を前記サーバリソースプールに戻すため、前記複数の第1のサーバの一部を停止させる停止ステップと、前記起動ステップと、前記設定ステップと、前記停止ステップとを繰り返し、前記現用クラスタから前記新設クラスタへの切り替えを実行することを特徴とするファイル更新方法。分散処理を行うための現用クラスタを構成し、更新前ファイルを用いて対向装置にサービスを提供する複数の第1のサーバと、分散処理を行うための新設クラスタを構成し、更新後ファイルを用いて対向装置にサービスを提供する複数の第2のサーバと、対向装置からのリクエストを前記第1のサーバおよび第2のサーバに振り分けるロードバランサと連携し、前記第1のサーバおよび前記第2のサーバの分散処理を制御する分散処理管理装置であって、前記分散処理管理装置の制御手段が、サーバリソースプールから所定量の資源が割り当てられる前記複数の第2のサーバの一部に更新後ファイルを送信し、前記更新後ファイルを送信した前記第2のサーバを起動させる起動制御と、前記現用クラスタおよび前記新設クラスタを監視し、前記現用クラスタおよび前記新設クラスタでのトラフィック量と、稼動中の前記第1のサーバおよび前記第2のサーバのCPU使用率とにより、稼動中の前記第2のサーバに振り分けるリクエストの新たなリクエスト量を算出し、前記算出したリクエスト量を実現するように、前記ロードバランサが前記第1のサーバおよび前記第2のサーバにリクエストを振り分けるための振り分けルールを作成し、作成した振り分けルールを前記ロードバランサに設定させる設定制御と、前記ロードバランサに設定した振り分けルールにより、割り当てが不要になった資源を前記サーバリソースプールに戻すため、前記複数の第1のサーバの一部を停止させる停止制御と、前記起動制御と、前記設定制御と、前記停止制御とを繰り返し、前記現用クラスタから前記新設クラスタへの切り替えを実行することを特徴とする分散処理管理装置。特許文献1の技術によれば、同程度の性能を持つ、例えば同数のサーバからなるクラスタを2系統分常備する必要があることを意味する。よって、2系統分のクラスタを構成するサーバに割り当てる資源2倍の資源を常に用意する必要がある。しかし、近年、サービスの提供に伴う通信のトラフィック量が増大傾向にあるなかで、それほどの資源を用意することは、システムの運用側にとって大きな負担となる。具体的には、クラスタを構成するサーバの購入コスト、および運用コストは増大し、また、サーバを設置する場所の確保が困難になる。そこで、このような事情に鑑みて、本発明は、サービスを中断することなくファイルの更新を行うサーバクラスタを構成するサーバに割り当てる資源の量を低減することを目的とする。前記課題を解決するため、請求項1に記載の発明は、分散処理を行うための現用クラスタを構成し、更新前ファイルを用いて対向装置にサービスを提供する複数の第1のサーバと、分散処理を行うための新設クラスタを構成し、更新後ファイルを用いて対向装置にサービスを提供する複数の第2のサーバと、対向装置からのリクエストを前記第1のサーバおよび第2のサーバに振り分けるロードバランサと、前記第1のサーバと、前記第2のサーバと、前記ロードバランサと連携し、前記第1のサーバおよび前記第2のサーバの分散処理を制御する分散処理管理装置と、を備えるサービス提供システムであって、前記分散処理管理装置の制御手段が、サーバリソースプールから所定量の資源が割り当てられる前記複数の第2のサーバの一部に更新後ファイルを送信し、前記更新後ファイルを送信した前記第2のサーバを起動させる起動制御と、前記現用クラスタおよび前記新設クラスタを監視し、前記現用クラスタおよび前記新設クラスタでのトラフィック量と、稼動中の前記第1のサーバおよび前記第2のサーバのCPU使用率とにより、稼動中の前記第2のサーバに振り分けるリクエストの新たなリクエスト量を算出し、前記算出したリクエスト量を実現するように、前記ロードバランサが前記第1のサーバおよび前記第2のサーバにリクエストを振り分けるための振り分けルールを作成し、作成した振り分けルールを前記ロードバランサに設定させる設定制御と、前記ロードバランサに設定した振り分けルールにより、割り当てが不要になった資源を前記サーバリソースプールに戻すため、前記複数の第1のサーバの一部を停止させる停止制御と、前記起動制御と、前記設定制御と、前記停止制御とを繰り返し、前記現用クラスタから前記新設クラスタへの切り替えを実行することを特徴とする。請求項2に記載の発明は、請求項1に記載のサービス提供システムにおいて、前記分散処理管理装置の制御手段が、前記第2のサーバに送信した更新後ファイルのエラー監視を実行することを特徴とする。請求項3に記載の発明は、分散処理を行うための現用クラスタを構成し、更新前ファイルを用いて対向装置にサービスを提供する複数の第1のサーバと、分散処理を行うための新設クラスタを構成し、更新後ファイルを用いて対向装置にサービスを提供する複数の第2のサーバと、対向装置からのリクエストを前記第1のサーバおよび第2のサーバに振り分けるロードバランサと、前記第1のサーバと、前記第2のサーバと、前記ロードバランサと連携し、前記第1のサーバおよび前記第2のサーバの分散処理を制御する分散処理管理装置と、を備えるサービス提供システムにおけるファイル更新方法であって、前記分散処理管理装置の制御手段が、サーバリソースプールから所定量の資源が割り当てられる前記複数の第2のサーバの一部に更新後ファイルを送信し、前記更新後ファイルを送信した前記第2のサーバを起動させる起動ステップと、前記現用クラスタおよび前記新設クラスタを監視し、前記現用クラスタおよび前記新設クラスタでのトラフィック量と、稼動中の前記第1のサーバおよび前記第2のサーバのCPU使用率とにより、稼動中の前記第2のサーバに振り分けるリクエストの新たなリクエスト量を算出し、前記算出したリクエスト量を実現するように、前記ロードバランサが前記第1のサーバおよび前記第2のサーバにリクエストを振り分けるための振り分けルールを作成し、作成した振り分けルールを前記ロードバランサに設定させる設定ステップと、前記ロードバランサに設定した振り分けルールにより、割り当てが不要になった資源を前記サーバリソースプールに戻すため、前記複数の第1のサーバの一部を停止させる停止ステップと、前記起動ステップと、前記設定ステップと、前記停止ステップとを繰り返し、前記現用クラスタから前記新設クラスタへの切り替えを実行することを特徴とする。請求項4に記載の発明は、分散処理を行うための現用クラスタを構成し、更新前ファイルを用いて対向装置にサービスを提供する複数の第1のサーバと、分散処理を行うための新設クラスタを構成し、更新後ファイルを用いて対向装置にサービスを提供する複数の第2のサーバと、対向装置からのリクエストを前記第1のサーバおよび第2のサーバに振り分けるロードバランサと連携し、前記第1のサーバおよび前記第2のサーバの分散処理を制御する分散処理管理装置であって、前記分散処理管理装置の制御手段が、サーバリソースプールから所定量の資源が割り当てられる前記複数の第2のサーバの一部に更新後ファイルを送信し、前記更新後ファイルを送信した前記第2のサーバを起動させる起動制御と、前記現用クラスタおよび前記新設クラスタを監視し、前記現用クラスタおよび前記新設クラスタでのトラフィック量と、稼動中の前記第1のサーバおよび前記第2のサーバのCPU使用率とにより、稼動中の前記第2のサーバに振り分けるリクエストの新たなリクエスト量を算出し、前記算出したリクエスト量を実現するように、前記ロードバランサが前記第1のサーバおよび前記第2のサーバにリクエストを振り分けるための振り分けルールを作成し、作成した振り分けルールを前記ロードバランサに設定させる設定制御と、前記ロードバランサに設定した振り分けルールにより、割り当てが不要になった資源を前記サーバリソースプールに戻すため、前記複数の第1のサーバの一部を停止させる停止制御と、前記起動制御と、前記設定制御と、前記停止制御とを繰り返し、前記現用クラスタから前記新設クラスタへの切り替えを実行することを特徴とする。請求項1、3、4に記載の発明によれば、リソースプールから新設クラスタの第2のサーバに割り当てる資源の量と、現用クラスタの第1のサーバからリソースプールへ回収する資源の量とを調整できるようにしたため、サービスを中断することなくファイルの更新を行うサーバクラスタを構成するサーバに割り当てる資源の量を低減することができる。請求項2に記載の発明によれば、新設クラスタの第2のサーバを少し追加した段階で、ファイルの安全性や安定性に関するエラー監視を行うので、ファイルの更新に失敗したときの影響および対応に要する手間を低減することができる。本発明によれば、サービスを中断することなくファイルの更新を行うサーバクラスタを構成するサーバに割り当てる資源の量を低減することができる。次に、本発明を実施するための形態以下、実施形態という。について、適宜図面を参照しながら説明する。図1は、本実施形態におけるサービス提供システムを含む全体図である。サービス提供システムSは、サーバクラスタ100と、分散処理管理装置400とを備える。サーバクラスタ100は、ネットワークの制御プロトコルとして、例えば、SIPSessionInitiationProtocolを使用するスケールアウト型のクラスタシステムである。SIPは、VoIPVoiceoverInternetProtocolを応用した、インターネット電話などで用いられる通話制御プロトコルの1つである。サーバクラスタ100は、IPネットワーク500を介して接続された対向装置600に対してサービスを提供する。本実施形態で対象とするサービスは、一般的に、呼処理制御サーバなどにおいてサービスを中断することなくファイルを更新することが期待されるサービスをいう。対向装置600は、主に、サーバ610や端末620を含む。サーバ610および端末620は、サービスを享受するために、サーバクラスタ100に対してリクエストを送信するコンピュータである。サーバクラスタ100は、ロードバランサ200と複数のサーバ300とを備えて構成される。なお、本実施形態において、従来技術と比較して特徴的な構成は分散処理管理装置400である。したがって、ロードバランサ200とサーバ300とについては、図示や説明を簡略化する。各サーバ300は、例えば、SIPサーバやHTTPHyperTextTransferProtocolサーバであり、対向装置600に対してサービスを提供するためのアプリケーション320を有する。ロードバランサ200は、振り分け機能210を有する。振り分け機能210は、振り分け先制御機能211と状態管理機能212とを具備する。振り分け先制御機能211とは、対向装置600から受信したリクエストを各サーバ300に振り分ける機能である。振り分け先の選択方法としては、ラウンドロビン、重み付けラウンドロビン、またはサーバ300の負荷に応じた選択、などの方法がある。アプリケーション320には、1セッションにつき、複数のリクエスト例:電話サービスに用いる継続リクエストを処理するものがあってもよい。ロードバランサ200は、そのようなアプリケーション320を有するサーバ300に対しては、2回目以降のリクエストも振り分けてもよい。前記したアプリケーション320とは、例えば、SIPのINVITE、ACK、BYE、またはHTTPのクッキーなどを用いたセッション管理を実現するアプリケーションである。なお、INVITEとは、通話の開始要求を行い、セッションを開始する信号である。ACKとは、送信先コンピュータから送信元コンピュータへ送られる、データ送信が正常に終了したことを示す信号である。BYEとは、通話の終了要求を行い、セッションを終了する信号である。状態管理機能212は、どのサーバ300にどのリクエストを振り分けたかを表す情報を、例えばデータベースとして保持する機能である。サーバ300に振り分けるリクエストには、そのリクエストを識別するリクエストIDIDentifierが付されている。状態管理機能212は、このリクエストIDを保持する。前記リクエストIDとは、例えば、SIP信号に含まれるセッションキーであることが好ましい。セッションキーとは、サービス提供システムSが対向装置600を認証するために発行する、ランダム値からなる鍵情報である。ロードバランサ200は、2回目以降の信号については、この状態管理機能212を参照することで、適切な振り分け先のサーバ300を特定することができる。対向装置600は、ロードバランサ200の振り分け機能210が公開するUDPUserDatagramProtocolやTCPTransmissionControlProtocolのポートを、サーバクラスタ100への宛先ポートとして認識する。ロードバランサ200は、対向装置600から送信されるSIPのINVITE、BYEなどのリクエストを受信する。そして、ロードバランサ200の振り分け機能210は、そのリクエストを複数のサーバ300に振り分ける。サーバ300は、クラスタ機能310によって、対向装置600に対するサーバクラスタ100の機能を実現する。クラスタ機能310は、アプリケーション320に対して、対向装置600に信号を返すための手段やセッションデータへのアクセス手段を提供する。ここでの手段とは、例えば、HTTPServletやSIPServletのようなAPIのことである。セッションデータとは、複数のリクエストによって更新される状態データであり、対向装置600のユーザのサービスの利用状況やリクエストIDなどを含む。前記状態データが示す状態とは、例えばIP電話における通話状態などが該当する。対向装置600とサーバクラスタ100とが信号を送受信する場合、実際にアプリケーション320の処理を実行しているのは分散されたサーバ300である。しかし、対向装置600からすると、ロードバランサ200上の振り分け機能210と信号をやりとりしているように見える。つまり、サーバクラスタ100において、内部サーバ構成が隠蔽される。クラスタ機能310は、そのような隠蔽を実現するために、トランスポート層転送機能311およびセッション管理機能312を有する。トランスポート層転送機能311は、各サーバ300上のアプリケーション320から対向装置600宛てへの信号を、サーバクラスタ100が実現するトランスポート層を経由して転送する機能である。各サーバ300上のアプリケーション320から信号を直接的に対向装置600へ送信するわけではないので、対向装置600は、受信した信号の送信元を知り得ない。セッション管理機能312は、アプリケーション320に、リクエストIDのみでセッションデータにアクセスさせる機能である。実際のセッションデータは、分散されたサーバ300またはデータベースのような外部装置不図示で管理されている。セッション管理機能312は、リクエストIDを除いてそのようなセッションデータの所在やアクセス手段を、アプリケーション320に意識させない。なお、前記セッションデータの所在とは、例えば、IPアドレスまたはメモリアドレスである。また、前記アクセス手段とは、例えば、SQLStructuredQueryLanguage送信である。これらのクラスタ機能310を実現するAPIにより、アプリケーション320は、分散処理されていることを意識せずにアプリケーション処理を実行できる。また、複数のサーバ300においてクラスタ機能310がクラスタメンバシップを構成し、ロードバランサ200の振り分け機能210がそれらのサーバ300にリクエストを振り分けることにより、サーバ300を追加増設すれば、サーバクラスタ100の処理能力を向上させることができる。サーバリソースプール800は、サーバ300に動的に割り当てる資源を蓄えている。サーバリソースプール800は、起動することが決定したサーバ300に対して資源を割り当て、停止することが決定したサーバ300に割り当てていた資源を回収する。サーバリソースプール800は、例えば、サービス提供システムSの設置場所とは離れたデータセンタなどに設置された計算機の処理により構成される。分散処理管理装置400は、ロードバランサ200の振り分け機能210と、クラスタ機能310とを連携制御する。分散処理管理装置400は、この連携制御により、サーバクラスタ100が提供するサービスを中断することなく、サーバ300のファイルを更新することができる。分散処理管理装置400は、コンピュータ装置であり、制御手段410、記憶手段420、通信手段430、入力手段440および出力手段450、といったハードウェアを備える。制御手段410は、例えばCPUCentralProcessingUnitとメモリによって構成され、ファイル送信部411、サーバクラスタ起動部412、振り分けルール設定部413、通信状態監視部414、エラー監視部415およびサーバクラスタ停止部416といったソフトウェアを実現する。記憶手段420は、HDDHardDiskDriveなどから構成され、ロードバランサ200の振り分け機能210とクラスタ機能310を連携制御するために必要な各種情報を記憶する。通信手段430は、ロードバランサ200やクラスタ機能310と通信するための通信インタフェースや通信ポートから構成される。入力手段440は、分散処理管理装置400を操作するオペレータが情報を入力する手段であり、例えばキーボードやマウスなどから構成される。なお、オペレータは、分散処理管理装置400が接続している保守ネットワーク700と接続している管理コンソール不図示を用いて情報を入力することもできる。出力手段450は、情報を出力する手段であり、例えば、液晶表示機やスピーカなどから構成される。ファイル送信部411は、サーバ300がサーバクラスタ100を構成し、サービスを提供するために必要なデータがまとめられているファイルをサーバ300に送信する。サーバクラスタ起動部412は、ファイルを受信したサーバ300に対し、そのサーバ300が属するサーバクラスタ100として起動するように指示する。サーバ300は、その指示を受信すると、ファイルの読み込み処理を行い、起動する。振り分けルール設定部413は、ロードバランサ200に対して、振り分けルールを設定する。振り分けルールとは、ロードバランサ200の振り分け機能210が、対向装置600から受信したリクエストをどのサーバ300にどの程度振り分けるかを定めた内容である。通信状態監視部414は、サーバクラスタ100の通信状態を監視する。具体的には、サーバクラスタ100のトラフィック量リクエスト量を集計したり、サーバ300のCPU使用率を計測したりなどする。振り分けルール設定部413は、その集計や計測の結果に基づいて、サーバ300に振り分けるリクエストの種類または量などを決定し、振り分けルールを作成する。エラー監視部415は、ファイル送信部411が送信したファイルの安全性や安定性を監視する。具体的には、そのファイルで起動したサーバ300の処理動作を監視し、処理動作が正常であるか否かを判定する。分散処理管理装置400は、処理動作にエラーがあると判定した場合は、そのサーバ300に対して動作の停止を指示する。サーバクラスタ停止部416は、対象となるサーバクラスタ100を構成するサーバ300に対して停止するように指示する。サーバ300は、その指示を受信すると、停止に必要な処理を実行し、サーバ300に割り当てられていた資源を、割り当てが不要になったため、サーバリソースプール800に戻す。ここで、対向装置600にサービスを提供中のサーバクラスタ100である現用クラスタを、新たなサーバクラスタ100である新設クラスタに切り替える場合を考える。従来技術の方法によると、サービスを継続するためには、現用クラスタから新設クラスタへの処理の引き継ぎが完了した後に、現用クラスタを停止する必要があった。この引き継ぎには、例えば、新設クラスタのサーバへのファイルの送信、新設クラスタのサーバの起動、現用クラスタから新設クラスタへのセッションデータの移行などが含まれる。また、一般的には、新設クラスタのサーバに送信したファイル更新後ファイルは、現用クラスタのサーバに送信したファイル更新前ファイルを更新したものである。このため、更新後のファイルに基づいてサービスを提供する新設クラスタのサーバにリクエストが振り分けられる傾向がある。しかし、サービスを継続するためには、現用クラスタのサーバを停止するわけにはいかない。よって、現用クラスタと新設クラスタとが同時に稼動している期間が存在する。また、処理を引き継ぐため、新設クラスタには、現用クラスタと同程度の性能が求められる。よって、サーバリソースプール800から新設クラスタのサーバ300に割り当てる資源の量は、現用クラスタのサーバ300に割り当てていた資源の量と同程度にする必要がある。したがって、現用クラスタと新設クラスタとが併存したサーバクラスタ100に対して、現用クラスタのみでサービスを提供していたときと比べて2倍の資源を割り当てる必要がある期間が存在する。しかし、それほど多くの資源を確保することは、サービス提供システムSの運用上大きな負担となる。本実施形態は、新設クラスタのサーバ300がサービスを提供しつつも、一時的ではあるが、現用クラスタのサーバ300によるサービスの提供を許容する。このことにより、現用クラスタと新設クラスタとが併存したサーバクラスタ100に対して、2倍の資源を割り当てないように済ませる。図2は、現用クラスタおよび新設クラスタに対するリクエストの振り分けの例を示す図である。元々は、ロードバランサ200は、現用クラスタのサーバ300第1のサーバに対向装置600からのリクエストを振り分けていた。ここで、すでに所定台数分用意されている新設クラスタのサーバ300第2のサーバの一部に対し、ファイルを送信し、サーバリソースプール800から資源を割り当て、そのサーバ300を起動する。ロードバランサ200は、起動した新設クラスタのサーバ300に対してリクエストを振り分け始めるが、現用クラスタのサーバ300へのリクエストの振り分けも継続する。その後、所定の時間をかけて、起動する新設クラスタのサーバ300の数を徐々に増やしつつ、停止する現用クラスタのサーバ300の数も徐々に増やすという調整をおこなう。この調整中、徐々に増える稼動中の新設クラスタのサーバ300には、より多くのリクエストが振り分けられる。この調整は、新設クラスタのすべてのサーバ300を起動し、現用クラスタのすべてのサーバ300を停止するまで続ける。このような手順を踏むことで、現用クラスタから新設クラスタへの切り替えに要する期間を含むいかなる期間においても、現用クラスタのサーバ300に割り当てる資源の量と新設クラスタのサーバ300に割り当てる資源の量との合計は、前記した2倍の資源の量を下回る。次に、図2に示したリクエストの振り分けを実現するための分散処理管理装置400の処理について説明する。図3は、分散処理管理装置における処理を示すフローチャートである。この処理の主体は、制御手段410である。この処理は、ステップS01から開始する。ステップS01において、制御手段410は、サーバクラスタ100において、新設クラスタのサーバ300を登録する。登録されるサーバ300は、新設クラスタを構成するすべてのサーバ300の一部ではあるが、一般的には複数である。新設クラスタのサーバ300を登録する数は、オペレータによる入力手段440の操作により、決定してもよいし、分散処理管理装置400が所定のアルゴリズムを用いて決定してもよい。記憶手段420が記憶するデータベースには、対象となる新設クラスタのサーバ300に関するレコードが書き込まれる。また、この登録により、分散処理管理装置400は、登録した新設クラスタのサーバ300を、ロードバランサ200によるリクエストの振り分け先として設定する。ステップS01の後、ステップS02に進む。ステップS02において、制御手段410は、ファイル送信部411を用いて、新設クラスタのサーバ300に対してファイルを送信する。ここで、送信するファイルは、現用クラスタのサーバ300に送信したファイルを更新したファイルである。ファイル送信部411によるファイルの送信は、例えば、オペレータによる入力手段440の操作があって行ってもよいし、ステップS01の処理の完了後、自動的に行ってもよい。ステップS02の後、ステップS03に進む。ステップS03において、制御手段410は、サーバクラスタ起動部412を用いて、新設クラスタのサーバ300に対して、送信したファイルを用いて起動するように指示する。新設クラスタのサーバ300は、この指示により、サーバリソースプール800から資源を取得して、起動する。ステップS03の後、ステップS04に進む。ステップS04において、制御手段410は、振り分けルール設定部413を用いて、ロードバランサ200に対して、稼動中のサーバ300のいずれかにどの程度の量のリクエストを振り分けるかを定めた振り分けルールを設定する。このとき、制御手段410は、通信状態監視部414を用いてサーバクラスタ100の通信状態を監視しており、その通信状態に基づいて、起動した新設クラスタのサーバ300に振り分ける最適な割合となるリクエスト量を算出する。前記最適な割合とは、例えば、通信状態監視部414により集計したトラフィック量や、計測したすべての稼動中のサーバ300のCPU使用率に基づいて算出することが好ましい。このとき、算出した最適な割合となるリクエストをサーバ300に振り分けるといった振り分けルールを作成する。また、前記最適な割合とは、例えば、新設クラスタのサーバ300の処理能力で所定時間を超える遅延が無く処理できるリクエストの最大量であることが好ましい。例えば、1リクエストあたりの処理負荷が均一例:5CPU利用単位であったと仮定し、新設クラスタのサーバ300は、100CPU単位で処理を行う能力を有しているとする。このとき、20=100/5リクエストをそのサーバ300に振り分ける、といった振り分けルールを作成する。この最適な割合は、オペレータが決定して、入力手段440の操作により入力してもよい。また、分散処理管理装置400が専用のアルゴリズムを用いて自動的に算出してもよい。振り分けルール設定部413は、少なくともリクエストIDと、そのリクエストIDで識別されるリクエストの振り分け先とを対応付けたリストの形式で振り分けルールを作成する。前記リストの振り分け先には、サーバ300と、そのサーバ300が属するクラスタとが登録される。記憶手段420は、作成した振り分けルールを記憶する。ステップS04では、振り分けルール設定部413が、現用クラスタのサーバ300、およびそのサーバ300に振り分けられるリクエストのリクエストIDを定めるだけでなく、ステップS01で登録した新設クラスタのサーバ300、およびそのサーバ300に振り分けられるリクエストのリクエストIDも定めた振り分けルールを作成する。そして、作成した振り分けルールを、ロードバランサ200に送信する。ロードバランサ200はその振り分けルールに基づいてリクエストを振り分ける。ステップS04の後、ステップS05に進む。ステップS05において、制御手段410は、エラー監視部415を用いて、稼動中の新設クラスタのサーバ300に送信したファイルの安全性や安定性に関するエラー監視を行う。エラー監視は所定の監視期間に亘って行う。もし、稼動中の新設クラスタのサーバ300のエラー発生を検知した場合、新設クラスタでの処理を中止し、新設クラスタに振り分けていたリクエストは、現用クラスタに振り分ける。このような対応を行うため、監視期間中は、現用クラスタのサーバ300は停止しない。エラー発生を検知しなかった場合、ステップS05の後、ステップS06に進む。ステップS06において、制御手段410は、サーバクラスタ100において、新設クラスタのサーバ300を追加登録する。ステップS06の処理は、基本的には、ステップS01の処理と同様である。ステップS06の処理により、起動する新設クラスタのサーバ300の数を徐々に増やす。ステップS06の後、ステップS07に進む。ステップS07において、制御手段410は、ファイル送信部411を用いて、追加分の新設クラスタのサーバ300に対してファイルを送信する。ステップS07の後、ステップS08に進む。ステップS08において、制御手段410は、サーバクラスタ起動部412を用いて、追加分の新設クラスタのサーバ300に対して、送信したファイルを用いて起動するように指示する。追加分の新設クラスタのサーバ300は、この指示により、サーバリソースプール800から資源を取得して、起動する。ステップS08の後、ステップS09に進む。ステップS09において、制御手段410は、振り分けルール設定部413を用いて、ロードバランサ200に対して、稼動中のサーバ300のいずれかにどの程度の量のリクエストを振り分けるかを定めた振り分けルールを設定する。ステップS09の処理は、基本的には、ステップS04の処理と同様であり、起動した新設クラスタのサーバ300に振り分ける最適な割合となるリクエスト量を新たに算出する。ステップS09では、振り分けルール設定部413が、ステップS06で追加登録した新設クラスタのサーバ300、およびそのサーバ300に振り分けられるリクエストのリクエストIDも定めた振り分けルールを作成する。そして、作成した振り分けルールを、ロードバランサ200に送信する。ステップS09の後、ステップS10に進む。ステップS10において、制御手段410は、サーバクラスタ停止部416を用いて、現用クラスタのサーバ300の一部に対して、停止するように指示する。停止することになる現用クラスタのサーバ300は、この指示により、サーバリソースプール800へ資源を戻し、最終的には停止する。なお、停止することになる現用クラスタのサーバ300は、自身に振り分けられるリクエストに対応するセッションデータを、そのリクエストの新しい振り分け先となるサーバ300に移行する。新しい振り分け先となるサーバ300は、後記するステップS11で設定した振り分けルールに従って決定される。新しい振り分け先となるサーバ300は、まだ稼動中の現用クラスタのサーバ300でもよいが、新設クラスタのサーバ300であることが好ましい。ステップS10の後、ステップS11に進む。ステップS11において、制御手段410は、振り分けルール設定部413を用いて、ロードバランサ200に対して、稼動中のサーバ300のいずれかにどの程度の量のリクエストを振り分けるかを定めた振り分けルールを設定する。ステップS11の処理は、基本的には、ステップS04の処理と同様であり、起動した新設クラスタのサーバ300に振り分ける最適な割合となるリクエスト量を新たに算出する。ステップS11では、振り分けルール設定部413が、ステップS10で停止が決定した現用クラスタのサーバ300を除外して、振り分けルールを作成する。また、除外したサーバ300に対応付けられていたリクエストIDは、残りのサーバ300に対応付けられる。そして、作成した振り分けルールを、ロードバランサ200に送信する。ステップS11の後、ステップS12に進む。ステップS12において、制御手段410は、現用クラスタのすべてのサーバが停止したか否か判定する。すべて停止した場合はステップS11でYes、図3の処理全体を終了する。このことは、現用クラスタから新設クラスタへの切り替えが完了したことを意味する。一方、すべて停止しない場合はステップS11でNo、ステップS06に戻る。このことは、稼動中の現用クラスタの残りのサーバ300を徐々に停止していくことを意味する。このような処理を実行することにより、サービスを中断することなくファイルの更新を行うサーバクラスタ100を構成するサーバ300に割り当てる資源の量を低減することができる。リソースプールから新設クラスタのサーバ300に割り当てる資源の量と、現用クラスタのサーバ300からリソースプールへ回収する資源の量とを調整できるようにしたためである。また、サーバクラスタ100に振り分けられるリクエストの量に関係なく、新設クラスタのサーバ300に割り当てる資源の量を調整することができる。また、新設クラスタのサーバ300を少し追加した段階で、ファイルの安全性や安定性に関するエラー監視を行うので図3のステップS05、ファイルの更新に失敗したときの影響および対応に要する手間を低減することができる。ステップS04で説明した最適な割合は、対向装置600を用いるユーザのユーザIDを基準にして決定することもできる。つまり、ユーザIDについて、リクエストを振り分けるための所定のグループ振り分け単位を決定し、どのグループに対応するサーバ300にどのリクエストを振り分けるかを決定することができる。ユーザIDは、サービス提供システムSの利用に関する認証結果が正当であるユーザごとに固有のランダム値である。そして、前記グループは、前記ランダム値がとり得る全範囲の一部に相当する。振り分けルール設定部413は、例えば、少なくともユーザIDと、そのユーザIDが属するグループとを対応付けたリストの形式で振り分けルールを作成する。もし、1度に大量のリクエストを新設クラスタのサーバ300に振り分けることができる場合には、新設クラスタのサーバ300に対応するグループを多数指定することで前記最適な割合を実現することができる。また、1度に少量のリクエストしか新設クラスタのサーバ300に振り分けることができない場合には、新設クラスタのサーバ300に対応するグループを少数指定することで前記最適な割合を実現することができる。また、ユーザIDの代わりに、ランダム値をとるリクエストIDを基準にして、上記と同様のやり方で、最適な割合を決定することもできる。第1の変形例これまでの説明は、ロードバランサ200が新設クラスタのサーバ300と現用クラスタのサーバ300とに所定の割合でリクエストを振り分ける技術に関するものであった図2参照。しかし、ロードバランサ200がすべてのリクエストを新設クラスタのサーバ300に振り分け、新設クラスタのサーバ300から現用クラスタのサーバ300にリクエストを振り分ける、という方法をとってもよい。図4は、現用クラスタおよび新設クラスタに対するリクエストの振り分けの他の例を示す図である。現用クラスタのサーバ300に対し、最小規模の新設クラスタのサーバ300を導入し、サーバリソースプール800から資源を割り当てる。この段階で、ロードバランサ200は、対向装置600からのリクエストをすべて新設クラスタのサーバ300に振り分ける。新設クラスタのサーバ300は、振り分けられたリクエストの一部を処理し、残りを現用クラスタのサーバ300に振り分けて処理させる。新設クラスタのサーバ300が処理するリクエスト量は、例えば、図2のステップS04の処理に倣って、最適な割合となるリクエスト量とすることが好ましい。分散処理管理装置400は、振り分けルール設定部413を用いて、新設クラスタのサーバ300が処理するリクエストのリクエストIDと、現用クラスタのサーバ300が処理するリクエストのリクエストIDとをまとめた振り分けルールを作成する。この振り分けルールには、ロードバランサ200がすべてのリクエストを新設クラスタのサーバ300に振り分けるという内容も記述されている。作成した振り分けルールは、ロードバランサ200および新設クラスタのサーバ300に送信して、設定される。その後、図3のステップS06~ステップS12の処理に倣って、ロードバランサ200が、すべてのリクエストを新設クラスタのサーバ300に振り分けつつも、新設クラスタを徐々に追加し、現用クラスタを徐々に停止し、現用クラスタから新設クラスタへの切り替えを実現する。このような方法を行うことで、図2で示した方法と比べて、ロードバランサ200が行う解析の負荷を低減することができる。つまり、図2で示した方法によれば、ロードバランサ200は、リクエストを振り分けるサーバ300が属するクラスタが現用クラスタであるか新設クラスタであるかを解析する必要があった。しかし、図4で示した方法によれば、ロードバランサ200からの振り分け先は新設クラスタだけであるため、クラスタを区別するための解析は不要となる。第2の変形例前記した方法とはさらに異なり、ロードバランサ200がすべてのリクエストを現用クラスタのサーバ300に振り分け、現用クラスタのサーバ300から新設クラスタのサーバ300にリクエストを振り分ける、という方法をとってもよい。図5は、現用クラスタおよび新設クラスタに対するリクエストの振り分けのさらに他の例を示す図である。現用クラスタのサーバ300に対し、最小規模の新設クラスタのサーバ300を導入し、サーバリソースプール800から資源を割り当てる。この段階で、ロードバランサ200は、対向装置600からのリクエストをすべて現用クラスタのサーバ300に振り分ける。現用クラスタのサーバ300は、振り分けられたリクエストの一部を処理し、残りを新設クラスタのサーバ300に振り分けて処理させる。新設クラスタのサーバ300が処理するリクエスト量は、例えば、図2のステップS04の処理に倣って、最適な割合となるリクエスト量とすることが好ましい。分散処理管理装置400は、振り分けルール設定部413を用いて、新設クラスタのサーバ300が処理するリクエストのリクエストIDと、現用クラスタのサーバ300が処理するリクエストのリクエストIDとをまとめた振り分けルールを作成する。この振り分けルールには、ロードバランサ200がすべてのリクエストを現用クラスタのサーバ300に振り分けるという内容も記述されている。作成した振り分けルールは、ロードバランサ200および現用クラスタのサーバ300に送信して、設定される。その後、図3のステップS06~ステップS12の処理に倣って、ロードバランサ200が、すべてのリクエストを現用クラスタのサーバ300に振り分けつつも、新設クラスタを徐々に追加し、現用クラスタを徐々に停止し、現用クラスタから新設クラスタへの切り替えを実現する。このような方法を行うことで、図4で示した方法と同様、ロードバランサ200が行う解析の負荷を低減することができる。つまり、図5で示した方法によれば、ロードバランサ200からの振り分け先は現用クラスタだけであるため、クラスタを区別するための解析は不要となる。その他前記実施形態は、本発明を実施するために好適のものであるが、その実施形式はこれらに限定されるものでなく、本発明の要旨を変更しない範囲内において種々変形することが可能である。例えば、本実施形態では、ロードバランサ200と分散処理管理装置400は、別筐体としているが、同一筐体としてもよい。したがって、分散処理管理装置400の通信状態監視部414が行ったトラフィック量の集計や、サーバ300のCPU使用率の計測は、ロードバランサ200が行ってもよい。また、ロードバランサ200が故障した場合に備えて、ホットスタンバイ状態の別のロードバランサを用意しておいてもよい。ロードバランサ200の障害時には瞬時にその別のロードバランサに切り替えれば、ロードバランサ200の障害による影響を最小限に抑えることができる。また、本実施形態で説明した種々の技術を適宜組み合わせた技術を実現することもできる。また、本実施形態で説明したソフトウェアは、ハードウェアとして実現することもでき、ハードウェアは、ソフトウェアとして実現することもできる。したがって、例えば、分散処理管理装置400の通信状態監視部414が行ったトラフィック量の集計や、サーバ300のCPU使用率の計測は、ハードウェアによる処理として実現することができる。その他、ハードウェア、ソフトウェア、フローチャートなどの具体的な構成について、本発明の趣旨を逸脱しない範囲で適宜変更が可能である。