"外部からのリクエストに対してサービスを提供するネットワークシステムであって、前記サービスを実行するための情報処理装置及び通信装置と、前記サービスを管理するソフトウェアを記憶する記憶装置と、前記ソフトウェアと連動して前記情報処理装置及び前記通信装置の管理を行う管理装置とを備え、前記情報処理装置は、前記リクエストを受信し、前記リクエストに対する前記サービスの処理結果を送信する送受信部と、前記リクエストを解析し、前記サービスのいずれに対するリクエストかを判定した結果に基づき、前記リクエストを振分けるサービス振分部と、前記リクエストに対する、前記サービス毎のQoS違反を監視するQoS監視部と、前記QoS監視部が、QoS違反を検出した場合、前記リクエストの処理を、前記ネットワークシステム内のリソース再割当てで対応するか、他ネットワークシステムに振分るかの判断結果に基づき、前記リクエストの処理の振分先を決定する振分け先決定部と、前記決定された振分け先に基づいて作成される構成確認要求を前記管理装置に送信する制御用送受信部を備え、前記管理装置は、前記構成確認要求に基づいて、前記サービスを実行する前記情報処理装置の位置を変更する、ことを特徴とするネットワークシステム。請求項1に記載のネットワークシステムであって、前記管理装置は、前記ネットワークシステム内に発生する通信量を削減し、電力を下げることにより、前記ネットワークシステム全体の省電力化のために、前記情報処理装置の位置を変更することを特徴とするネットワークシステム。請求項2に記載のネットワークシステムであって、前記情報処理装置は、前記振分先決定部の決定を受け、リクエスト振分率及びQoS情報を含むサービス管理情報を策定するQoS情報策定部を備え、前記制御用送受信部は、前記QoS情報策定部が策定した前記サービス管理情報を、構成確認要求とともに前記管理装置に送信する、ことを特徴とするネットワークシステム。請求項3に記載のネットワークシステムであって、前記情報処理装置は、前記サービス管理情報をサービス管理テーブルに蓄積する、ことを特徴とするネットワークシステム。請求項4に記載のネットワークシステムであって、前記情報処理装置は、前記サービス管理テーブルに管理する前記サービス管理情報として、前記他ネットワークシステムが提供するサービスとの接続関係を記録する、ことを特徴とするネットワークシステム。請求項3に記載のネットワークシステムであって、前記管理装置は、前記制御用送受信部から受信した前記サービス管理情報を用いて、前記管理装置が管理する前記情報処理装置及び前記通信装置を制御し、前記サービスの実行場所を決定する、ことを特徴とするネットワークシステム。請求項6に記載のネットワークシステムであって、前記管理装置は、前記構成確認要求を受信した場合、前記サービス管理情報に基づき、前記サービスに連携するサービスが存在するか否かを確認し、存在する場合にサービスグルーピング処理を実行する、ことを特徴とするネットワークシステム。外部からのリクエストに対してサービスを提供するネットワークシステムのサービス品質制御方法であって、前記ネットワークシステムは、前記サービスを実行するための情報処理装置及び通信装置と、前記サービスを管理するソフトウェアを記憶する記憶装置と、前記ソフトウェアと連動して前記情報処理装置及び前記通信装置の管理を行う管理装置とを備え、前記ネットワークシステムの前記管理装置は、前記サービスを実行する前記情報処理装置の位置を変更することにより、前記ネットワークシステム内に発生する通信量を削減し、電力を下げることにより、前記ネットワークシステム全体の省電力化を図る、ことを特徴とするサービス品質制御方法。請求項8に記載のサービス品質制御方法であって、前記情報処理装置は、前記リクエストを受信し、前記リクエストを解析し、前記サービスのいずれに対するリクエストかを判定した結果に基づき、前記リクエストを振分け、前記リクエストに対する、前記サービス毎のQoS違反を監視し、前記QoS違反を検出した場合、前記リクエストの処理を、前記ネットワークシステム内のリソース再割当てで対応するか、他ネットワークシステムに振分るかの判断結果に基づき、前記リクエストの処理の振分先を決定する、ことを特徴とするサービス品質制御方法。請求項9に記載のサービス品質制御方法であって、前記情報処理装置は、前記リソース内の再割当てで対応すると決定した場合、サービス管理情報を作成し、作成した前記サービス管理情報と構成確認要求を前記管理装置に送信する、ことを特徴とするサービス品質制御方法。請求項10に記載のサービス品質制御方法であって、前記情報処理装置は、前記サービス管理情報をサービス管理テーブルに蓄積すると共に、前記サービス管理情報として、前記他ネットワークシステムが提供するサービスとの接続関係を記録する、ことを特徴とするサービス品質制御方法。請求項10に記載のサービス品質制御方法であって、前記管理装置は、前記情報処理装置から受信した前記サービス管理情報を用いて、前記管理装置が管理する前記情報処理装置及び前記通信装置を制御し、前記サービスの実行場所を決定する、ことを特徴とするサービス品質制御方法。請求項10に記載のサービス品質制御方法であって、前記管理装置は、前記構成確認要求を受信した場合、前記サービス管理情報に基づき、前記サービスに連携するサービスが存在するか否かを確認し、存在する場合にサービスグルーピング処理を実行する、ことを特徴とするサービス品質制御方法。請求項10に記載のサービス品質制御方法であって、前記サービス管理テーブルに、前記サービスの接続関係を規定し、更に前記ネットワークシステム各々が提供する前記サービスの入出力の違いを前記ソフトウェアで変換して吸収することで入出力の異なる前記サービス間を連携させる、ことを特徴とするサービス品質制御方法。請求項9に記載のサービス品質制御方法であって、前記情報処理装置は、前記リクエストの処理を、前記他ネットワークシステムに振分ると決定した場合、前記リクエストに係るサービス管理情報を前記他ネットワークシステムに送信する、ことを特徴とするサービス品質制御方法。しかし,特許文献1、特許文献2、特許文献3では、仮想マシンが必要とするネットワーク容量等を鑑みていない。従って,仮想マシンの集約後のQoS性能保証が課題となる。さらに、特許文献4では、データセンタ間で仮想マシンの移行に関して、省電力化を踏まえた方式は含まれておらず、移行後の性能レベルは維持できるものの、物理サーバへ効率的に仮想マシンを稼働させる方法については検討されていない。本発明の目的は、上記の課題を解決し、ネットワークシステムであるデータセンタ内のサーバ位置及び通信経路の適正化を行い、さらに連携するデータセンタの処理状況を把握して資源配置適正化を行うことで、QoSの確保及び省電力化を実現することが可能な、ネットワークシステム、及びそのサービス品質制御方法を提供することにある。上記の目的を達成するため、本発明においては、外部からのリクエストに対してサービスを提供するネットワークシステム、及びそのサービス品質制御方法であって、サービスを実行するための情報処理装置及び通信装置と、サービスを管理するソフトウェアを記憶する記憶装置と、ソフトウェアと連動して情報処理装置及び通信装置の管理を行う管理装置とを備え、管理装置は、サービスを実行する情報処理装置の位置を変更することにより、ネットワークシステム内に発生する通信量を削減し、電力を下げることにより、ネットワークシステム全体の省電力化を図る構成のネットワークシステム、及びそのサービス品質制御方法を提供する。また、上記の目的を達成するため、本発明においては、外部からのリクエストに対してサービスを提供するネットワークシステム、及びそのサービス品質制御方法であって、サービスを実行するための情報処理装置及び通信装置と、サービスを管理するソフトウェアを記憶する記憶装置と、ソフトウェアと連動して情報処理装置及び通信装置の管理を行う管理装置とを備え、情報処理装置は、リクエストを受信し、受信したリクエストを解析し、いずれのサービスに対するリクエストかを判定した結果に基づき、リクエストを振分け、リクエストに対するサービス毎のQoS違反を監視し、QoS違反を検出した場合、リクエストの処理を、ネットワークシステム内のリソース再割当てで対応するか、他ネットワークシステムに振分るかの判断結果に基づき、リクエストの処理の振分先を決定し、管理装置は、サービスを実行する情報処理装置の位置を変更することにより、ネットワークシステム内に発生する通信量を削減し、電力を下げることにより、ネットワークシステム全体の省電力化を図る構成のネットワークシステム、及びそのサービス品質制御方法を提供する。すなわち、上記の目的を達成するため、本発明の好適な実施態様においては、データセンタなどのネットワークシステムは外部のネットワークシステムからの要求に対してサービスを提供するシステムであって、当該ネットワークシステムはサービスを管理するソフトウェアと、ソフトウェアと連動してネットワークシステムを構成する情報処理装置や通信機器などの管理を行う管理装置と、ネットワークシステムを構成し、サービスを実行するための情報処理装置及び通信装置によって構成されたネットワークシステムにおいて、サービスを実行する情報処理装置の位置を変更することでネットワークシステム内に発生する通信量を削減し、利用していない装置等の電力を下げ、さらには省電力向けのシステムが備わる装置については管理装置から省電力を実現する状態に変更することで、ネットワークシステム全体の省電力化を実現するリソース割当方法を実現する。これによって課題となる資源の配置を適正化し、QoSを保証しつつ省電力化できるネットワークシステムが構築できる。ネットワークを考慮した資源の適正配置を実施することによってQoSを保証しつつ省電力化可能なネットワークシステムを実現できる。以下、本発明の各種の実施例を図面に従い説明する。本明細書において、ネットワークシステムとは、主に、クライアントのリクエストに対して、複数のデータセンタが連携して、1つのサービスを提供するシステムを意味するが、サーバ、ネットワーク、ストレージリソースと、リソース管理マネージャとして機能するデータセンタ管理ノードとから構成されるデータセンタ自身をネットワークシステムと呼ぶ場合がある。また、本明細書において、データセンタ内の記憶装置で記憶され、情報処理装置で実行される各種のプログラム、ソフトウェアの機能を機能以外に手段や部と呼ぶ場合がある点留意されたい。例えば、サービス振分機能やQoS情報策定機能等は、サービス振分手段やQoS情報策定手段、或いはサービス振分部やQoS情報策定部等となる。監視部、フォーマット変換部、振分け先決定部、負荷予測部他も同様である。図1は第一の実施例に係る、データセンタ間連携サービスシステムの一構成例を示す図である。データセンタ間連携サービスシステムは、クライアントのリクエストに対して、複数のデータセンタが連携して1つのサービスを提供するネットワークシステムである。データセンタは、それぞれ複数のサービスを提供し、それぞれのサービスは、連携して動作することを想定している。サービス間を連携させるために、各データセンタにサービスを仲介するプロキシProxyを設置し、サービス連携に必要な入出力フォーマットの変換や次サービスへのデータ転送を実施する。また、Proxy間で負荷情報を交換することによって、各データセンタで動作するサービスに必要なリソースにおいて、過剰分を削減し、省電力化されたシステムを提供することができる。各データセンタは、情報を安全かつ高速に処理できるように、高性能のサーバや大容量のネットワークやストレージをセンタに集約したネットワークシステムである。データセンタ内の物理的なリソースであるサーバ、ネットワーク、ストレージは仮想化され、物理装置以上にリソースが存在するように提供することが可能である。仮想化されたリソースを使用して、様々なサービスをクライアントに提供することが可能である。上述のように、各データセンタは、これらのリソース以外に、ネットワーク経由で受信したデータを情報処理し、送信者に対して相応のレスポンスを実施するサービスと、サービス間を仲介するプロキシProxyによって構成される。データセンタ内にはProxyもサービスも複数あってもよく、あるサービスグループを束ねるProxyが存在する構成を取り得る。仮想化されたリソース上に構築されたProxyは、DC間のサービス連携時の仲介役として存在する。Proxyはサービス間のインタフェースの整合性をとり、同じDC内のサービスを管理するために存在する。Proxyは、同じ機能を有した装置であってもよい。図1のデータセンタ間連携サービスシステムにおいて、符号101はクライアントClient、符号102はWAN、符号103は親管理ノードであるクラウドマネージャーCloudManager、符号104はDC4、符号105はプロキシProxy、符号106はserviceA、符号107はDC3、符号108はProxy、符号109はserviceB、符号110はDC2、符号111はProxy、符号112はserviceC、符号113はDC1、符号114はProxy、符号115はserviceD、符号116はサービス連携情報、符号120はDNS、符号121はQoS情報、符号124はQoS情報、符号127はServiceEである。DC4104はProxy105、serviceA106から構成されている。Proxy105はClient101、serviceA106、Proxy108、CloudManager103と接続されている。ServiceA106はProxy105と接続されている。同様に、DC3107はProxy108、serviceB109から構成されている。Proxy108はserviceB109、Proxy105、Proxy111、CloudManager103と接続されている。ServiceB109はProxy108と接続されている。DC2110の構成要素は、Proxy111、serviceC112、ServiceE127から構成されている。Proxy111はserviceC112、Proxy108、Proxy114、CloudManager103と接続されている。ServiceC112はProxy111と接続されている。更に、DC1113は、Proxy114、serviceD115から構成されている。Proxy114はserviceD115、Proxy111、CloudManager103、Client101と接続されている。ここで、Client101とは、サービスを利用する顧客であり、各データセンタが提供するサービス、連携サービスを使用することが可能であり、Proxy105、Proxy114、DNS120と接続されている。WAN102は広域ネットワークである。また、親管理ノードとなるCloudManager103は、サービス提供者が構築したサービスフローを解釈し、連携方法を各データセンタのProxyに示す機能も持つ。サービス提供者は、サービスの接続関係とサービス間を接続する際に必要なインタフェースの接続方法を定義する。CloudManager103は、親管理ノードとして機能し、Proxy114、Proxy111、Proxy108、Proxy105と接続しており、各Proxyから取得できるサービス情報を基に接続関係と接続方法を決定し、各Proxyに対してサービス連携情報を送信する。各ProxyはこのCloudManager103からのサービス連携情報を基に、サービスの接続関係を認識する。サービス中は、要求の中の連携サービスの連携サービス識別子IDと連携先のサービス識別子IDと処理識別子IDによって、振り分け先のサービスと処理内容を識別して、該当するサービスへ処理を振り分け、処理結果を連携サービス識別子と処理識別子によって後段のサービスを特定して送信する。Proxy114は、上述の通りソフトウェアとしてその機能を提供してもよいし、ハードウェアとしてその機能を提供してもよい。すなわち、Proxyは、ネットワーク経由で送信されてきたRequestのヘッダ情報を読み取り、各Proxyが管理しているデータセンタ内の複数のサービスに対して、ヘッダ情報に適合したサービスへ処理を振り分ける。また、処理を振り分ける際に、サービスに適したフォーマットに変換する。本実施例の構成において、複数のサービスが連携する際には、前段のサービスを管理するProxyが前段のサービスの負荷状況を次段のサービスを管理するProxyに送信することによって、負荷状況を事前に通知し、適切なリソースを確保することでサービス毎に設定されたQoS情報を満足することを可能にする。また、Proxyはデータセンタ内のリソース管理マネージャである、後で詳述されるデータセンタ管理ノードと連動し、サーバリソース、ネットワークリソース、ストレージリソースをサービス稼働状態のときにQoSを満たすだけのリソースを利用することによって、データセンタ内の電力利用を適切にし、ひいてはシステム全体が省電力化を実現することを可能にする。serviceD115は、ソフトウェアの機能をネットワークを経由して、利用できるようにしたものである。サービスが複数連携することによって提供することも可能であり、Proxy114と接続されている。サービス連携情報116は連携サービスを提供するにあたり必要なサービスの接続関係とインタフェースが異なる場合の変換ルールが記載されている。サービス連携情報は1連携サービスごとに存在し、この情報を各Proxyに送信することによってProxy間の接続関係を明確にでき、各Proxyが管理するサービスを連携させることが可能になる。DNS120は、URLの名前解決するためのシステムである。クライアントからサービスにアクセスする際に使用する。QoS情報121はProxyが管理する各サービスのQoSを定義する情報であって、各サービスはQoS情報の範囲でサービスを提供することが望ましい。QoS情報はサービス提供者である顧客と交わす契約から構築した情報であり、たとえばSLAといった情報を基に、サービスの応答時間、サービスの接続可能数といったクライアントから見たサービスの品質にかかわる情報を定義している。連携サービスのおいてもQoS情報は定義することができ、連携サービスも同様にサービス提供者とデータセンタ事業者が交わす契約であるSLAを基本として作成するものである。図2は、データセンタによる連携サービスの一具体例を示す図である。同図においては、データセンタDC1202、DC2209、DC4206により、複数のサービスが連携して1つのServiceAA207を提供している。すなわち、ServiceA205とServiceC203とServiceD204が、シーケンシャルに処理が実施されることで、ServiceAAに定義するServiceを実現する。同図において、点線は処理の流れを示している。サービス名は、サービスの名前にアルファベット2つ並んでいる場合には、連携サービスを指し、1つの場合には、自分以外の構成要素を含まないサービスを指すものとする。図3Aは図1に示した本実施例のシステム中のデータセンタ内のProxyの機能構成の一例を示す構成図である。このProxyは、上述の通り、ソフトウェアとしてその機能を提供してもよいし、ハードウェアとしてその機能を提供してもよい。ハードウェアとして提供する場合、例えば、Proxyの機能を搭載した負荷分散装置が利用できる。図3Aにおいて、符号301はサービス、符号302はフォーマット変換部、符号303は送受信部、符号304はサービス振分部、符号305はサービス管理情報を記録するサービス管理テーブル、符号306は負荷予測部、符号307はサービス振分判断部、符号308は負荷情報送受信部、符号309は前段サービス、符号310はQoS監視部、符号311はQoS情報策定部、符号312は振分け先決定部、符号313は制御用送受信部、符号314はQOS定義テーブル、符号315は後段サービス、符号316は構成確認要求、符号317は子管理ノードであり、各データセンタ内のリソース管理マネージャとして機能するデータセンタ管理ノード、符号318は親管理ノードであるCloudManager、符号332は他データセンタDC、符号333はトラフィック監視テーブル、符号334は監視部である。なお、他データセンタ332は、データセンタ300と同様、サーバリソース、ストレージリソース、ネットワークリソースとリソース管理マネージャであるDC管理ノード等で構成される。すなわち、他DC332は、同図にそのハードウェア構成を示すように、リソースとして機能する通信装置335、通信経路336、情報処理装置337、各種ソフトウェアを保持する記憶装置338、及びDC管理ノード339などから構成される。次に図3Aに示すProxy内の各機能ブロックを使ってその動作、処理の流れを説明する。まず、他のデータセンタからWAN経由で送信されてきたサービスリクエストに対してProxy内の送受信部303が受信する。送受信部303は、フォーマット変換部302、QoS監視部310、サービス301等と接続され、他データセンタやクライアントとサービスに関する情報をやり取りするインタフェースである。他データセンタやクライアントからProxyが管理するサービスへのRequestを受信し、処理結果を他のデータセンタやクライアントへ送信する。サービスのRequestには、SOAPやRESTのような分散処理システムで利用するメッセージ交換プロトコルを想定している。送受信部303は、受信データをフォーマット変換部302へ転送、さらにはサービス処理結果に対してサービス管理テーブル305のサービス管理情報から送信先を参照し、ヘッダ情報を付けて送信する役目を持つ。一方、送受信部303に入力されるデータは、監視部334によってモニタリングされており、サービス単位でトラヒック量の時間変動を計測し、トラヒック監視テーブル333に蓄積する。蓄積する際、監視部334によって計測データに圧縮処理を実施してもよい。そして、送受信部303は受信データから送信元のサービス識別子と処理識別子を取得し、フォーマット変換部302へ取得した情報を転送する。図4に本実施例において使用するトラヒック監視テーブル333の一例を示した。同図において、401はサービス識別子、402は連携サービス識別子、403は圧縮フラグ、404は監視期間、405はデータ参照先である。Proxyが管理するサービスにおいて、当該Proxyが存在するデータセンタに対してWAN側から流れ込むトラヒック量と、WAN側へ送出するトラヒック量をProxyの監視部334で監視する。本テーブル333は、サービスごとに抽出したトラヒックデータを蓄積するために必要なテーブルである。以下、トラヒック監視情報テーブル333の説明をする。サービス識別子401は観測したトラヒックのサービスを特定する情報である。連携サービス識別子402は、サービスリクエストを発行したクライアントやサービス及び応答先を識別する情報である。この連携サービス識別子402をキーとして、後で説明する、図5に示すサービス管理テーブル305から送信元情報と送信先情報を取得するために用いられる。圧縮フラグ403はデータ参照先のファイルに記載されているデータが圧縮されているか否かをデータ利用者やプログラムに提示するための情報である。監視期間404はデータ参照先にあるデータの監視開始時間と監視終了時間が記載されている項目である。データ参照先405は実際のトラヒック監視情報が記載されているファイル名である。なお、すべてのサービスの単位時間ごとのトラヒック量を蓄積する場合、蓄積する期間やサンプリングの間隔によってProxyが管理するストレージを圧迫しかねないため、蓄積するデータをある程度可逆性のあるデータへ圧縮する方法をとることも可能である。たとえば、サービスのトラヒック量の時間的変動を、wavelet変換等を用いることにより、サービスのトラヒック特性を踏まえて圧縮することが可能になる。このときの圧縮に利用した関数や関数の入力パラメータ等の情報を蓄積データとして登録することもできる。ファイルがwavelet変換等で圧縮されている場合には、ファイルのフォーマットを読み取り、フォーマットを確認し、展開して利用する。図3Aのフォーマット変換部302は、送受信部303から受信したデータを解析し、Proxyが管理するいずれのサービスの入力値であるかを判定し、そのサービスの入力フォーマットへ変換処理を行う機能を持つ。フォーマット変換ルールはサービス管理テーブル305で管理されており、受信データの中に記載されたサービス識別子や処理識別子等をキーとして変換ルールを取得する。すなわち、フォーマット変換部302は、取得した情報を基にサービス管理テーブル305を参照して、処理内容を決定し、必要であれば、受信データを処理内容に合わせてフォーマット変換を行う。異なるデータセンタ間でサービスを連携させる場合、サービス間のインタフェースの違いを吸収するモジュールが必要になる場合がある。これに対し、サービスを開発する際にサービスの入出力を定義する、図示を省略したインタフェース定義ファイルを作成し、サービス連携時に、入力側のインタフェース定義ファイルと出力側のインタフェース定義ファイルを比較し、変換ルールを作成することで対応できる。この変換ルールは、図5を用いて説明するサービス管理テーブル305の変換ルールと同義である。たとえば、インタフェースがXMLeXtensibleMarkupLanguageであれば、XSLTで作成された変換ルールファイルを作成することになる。そこで、このときの変換ルールに関してはサービス管理テーブル305を参照する。図5に本実施例のサービス管理情報を記録するサービス管理テーブル305の一例を示した。サービス管理テーブル305はサービス間の連携方法を記載したサービス管理情報を示すデータを保存するテーブルであって、データセンタ内のサービスを管理するProxy毎に持つ管理テーブルである。Proxyはデータセンタ内のサービスグループを管理するため、サービスグループが複数存在すれば、Proxyも複数存在してもよく、その場合、サービス管理テーブルはProxy分存在する。このサービス管理テーブル305は、RAMやHDDなどの記録用媒体、記憶装置に蓄積されており、例えばデータベースのようなソフトウェアで管理されている。前段のProxyが送信してきたサービスリクエストに対して、いずれのサービスへ処理を振り分ければよいかを判断し、リクエストの値とProxyが管理するサービスの入力値が異なる場合であれば、それを変換するためのルールを持つ。さらに、サービスの処理結果の送信先をも管理する。図5において、符号601はサービス名、符号602はサービス識別子、符号603は処理識別子、符号604は送信元情報、符号605は振分ルール、符号606は送信先情報、符号607は変換ルール、符号608は連携サービス識別子である。この連携サービス識別子608は複数サービスが連携して、1つのサービスを提供するときのサービス識別子を示す。本実施例では使用しないが連携サービス毎に優先順位を付ける場合に、他データセンタ等からのリクエストと優先順位を対応づける場合に利用する。ここで、サービス名601はProxyが管理しているサービス名である。サービス識別子602はProxyが管理しているサービスの識別子を示す。サービス振分部604においてデータセンタ内のサービスを呼び出すときに利用する。処理識別子603は同じ連携サービスで、複数回同じサービスを利用する場合の識別情報をとして利用する。送信元情報604はサービスの要求元情報を示す。サービス要求元に対して他データセンタへの負荷分散指示を出すことから、サービス要求元のProxyに接続でき、さらに要求元のサービスを特定できる情報を登録する。例えば、Proxyへの接続URL、及びサービス識別子である。振分ルール605は複数のデータセンタに対して処理振り分けを実施する場合の振分ルール及び重みを示す。送信先情報606は振分ルール605に従って処理を依頼するためのURIUniformResourceIdentifierを示す。具体的には、振り分け先のサービスが特定できるURLである。変換ルール607はProxyでサービス要求を受信した際に、サービスの入力フォーマットに変換するためのルールを示す。ここでは入力情報としてXMLを受信したことを想定し、変換するためのXLSTファイル名を例に示した。図3Aのフォーマット変換部302でフォーマット変換された受信データは、サービス振分部304に転送され、該当するサービスへ処理を依頼する。フォーマット変換部302がサービス振分部304にデータを転送する。サービス振分部304は、処理内容に従い、該当するサービスへ処理を依頼する。サービス振分部304はフォーマット変換部302、サービス301と接続され、フォーマット変換部302もしくは送受信部303から転送されたデータを、サービス管理テーブル305記載のルールに従って、該当するサービスへ当該データを転送する。このとき依頼するサービスは、当該Proxyが管理するサービス301である。サービス301は、後で説明するデータセンタ内の仮想マシン等の上で動作するプログラムであり、送受信部303、サービス振分部304と接続されている。サービス301は処理を完了すると送受信部303へサービス情報と処理識別子とともに処理結果を転送する。送受信部303は、各サービスからの処理結果を受け、サービス管理テーブル305を参照して、次の転送先サービスを検索してWAN経由で送信する。一方、図3AのQoS監視部310は、以上の説明したサービスへのリクエストが随時発生している際に、送受信部303からのサービスごとのスループットを参照してQoS違反が発生していないかを監視する。QoS監視部310は、送受信部303、サービス振分判断部307と接続され、送受信部303を常時監視し、サービス毎のQoSをチェックする。QoS定義テーブル記載の確認項目に対して違反を検出するとQoS監視部310は、サービス振分判断部307に対してサービス識別子と違反内容を通知する。違反情報の検出方法の例として、QoS定義テーブル314には応答時間に対して単位時間内における許容可能な違反回数が記載されており、その回数を超えた場合にサービス振分判断部307に対して応答時間を超えたことを通知するなどである。すなわち、QoS監視部310によって違反が検出された場合、サービス振分判断部307にその違反情報が転送される。なお、図3AのQoS定義テーブル314は、Proxyが管理するサービスのQoS情報が登録されたテーブルである。サービス毎に定義された同時接続可能数や応答時間等の性能情報が登録されている。本情報は、サービス提供者がSLAとして顧客と締結した内容に関連して定義される情報である。図10に本実施例で用いるQoS定義テーブル314の一構成例を示した。図10に明らかなように、QoS定義テーブル314は、サービス名1001毎に、サービス識別子1002、同時接続可能数1003、応答時間1004、利用帯域上限値1005が蓄積されている。サービス名1001はProxyが管理しているサービス名を示す。サービス識別子1002はProxyが管理しているサービスの識別子を示す。次に説明するサービス振分部307においてデータセンタ内のサービスを呼び出すときに利用する。同時接続可能数1003はサービスが単位時間当たり接続できる接続数を規定する。応答時間1004はここではProxyにリクエストが到着して、サービスが実施されてProxyを経由して応答をかえすまでの時間をさす。利用帯域上限値1005は契約上サービス毎に規定されている利用帯域の上限値を示す。図3Aのサービス振分判断部307は、事前に負荷予測部306から各サービスのリクエスト状況予測値を取得し、受け取った違反情報と合わせて他データセンタへ振り分けるか、当該Proxyが存在するデータセンタ内のリソース再割当によって処理性能を向上させるかを判断する。すなわち、サービス振分判断部307は、負荷予測部306、QoS監視部310、振分け先決定部312と接続され、QoS監視部310が検出した違反情報と、後で説明する負荷予測部306が計算した今後の負荷予測結果を基に、他データセンタへ処理を振り分けるか、内部のリソース再割り当てで対応可能かを判断する。振分け先決定部312は、サービス振分判断部307の判断の結果、他データセンタへ処理振り分けを実施する場合、候補となるデータセンタを検索して決定する。この検索方法は、既に候補として登録されているデータセンタDCの中からサービスの要求性能、及びQoS定義テーブル314記載のサービス品質を提供するのに十分なリソースが存在するか否かを登録情報の中から検索してもよいし、現状に沿った振り分けを実施するのであれば、登録情報の検索結果に加えて現在の負荷情報をとり合わせるインタフェースを用いて、候補となるデータセンタDCに問い合わせてもよい。振り分け先のデータセンタが決まると、必要であればサービスイメージ及び処理結果の転送先を記載したサービス管理テーブル305を該当するデータセンタへ転送して、サービスの起動を行う。他データセンタへ処理振り分けを行う際、制御用送受信部313を経由して、前段サービスを管理するProxyへ振り分け処理を依頼する。振り分けルールはQoS情報策定部311で作成したQoS情報を基に作成する。内部リソースの再割当を行う際には、同じ連携サービスで利用するサービスをグルーピングし、可能な限り同じ物理サーバ上で処理を実施させることによって、サービス要求時に発生する通信を軽減させることが可能になる。QoS情報策定部311は、振分け先決定部312、制御用送受信部313と接続され、振分け先決定部312の振分け先決定を受け、リクエスト振り分け率及びQoS情報をあらたに作成する。例えば、応答時間は元のQoS情報と同じにし、同時接続可能数を現在のデータセンタ分と振分け先のデータセンタ分で分割する。分割にあたり、負荷予測部306による負荷変動データセンタの能力を超える場合、超えた分を他データセンタへ処理を振り分ける。振り分ける際には、上述のとおり、前段のサービスを管理するProxyに対して振り分け処理を依頼する。QoS情報策定部311は、受信データのヘッダ部記載のサービス名を読み取り、上位階層のサービス名を取得する。受信データの本体部から送信元のサービス名を取得し、両者のサービス名をキーにサービス管理テーブル305で変換先のサービス名と変換ルールを検索し、フォーマット変換部302に変換ルールとサービス名、受信データの本体部を送信する。ここでは、複数のデータセンタがユーザシームレスに連携してサービスを提供する場合、その複数のデータセンタのリソースは1つのデータセンタのリソースとして見えることが望ましい。その時、複数のデータセンタが提供する同時接続可能数を合わせた数をQoS情報として定義できることを想定している。また、当該Proxyが存在するデータセンタにおいて、十分なリソースが存在し、かつサービスの契約帯域上限値まで当該サービスが利用していない場合には、制御用送受信部313から、管理装置であるDC管理ノード317に対してリソース再割当要求である構成確認要求316を送信し、負荷予測に合わせたサーバリソース、ネットワークリソースを再割当てる。他データセンタ332を利用した処理振り分けによるQoS違反の回避、及びデータセンタ内の余剰リソースの再割当によるQoS違反の回避は、実施するまでのコストを考慮し、まずは後者を優先的に実施し、他データセンタへの処理振り分けはその後に実施することが望ましい。後者においても、サービス管理情報等の必要な情報が、他データセンタ332のプロキシに送信される。制御用送受信部313は、QoS情報策定部311、CloudManager318、他DC332、管理装置であるDC管理ノード317と接続され、サービス管理情報、QoS情報や、構成確認要求316などの情報等を送受信するインタフェースである。なお、DC管理ノード317は構成確認要求316を受信すると、その内部に構成確認要求テーブルを作成することもできる。構成確認要求テーブルの構成は、図5を用いて説明したサービス管理テーブルと同様な形式となり、その一例を図12として示したが、図5のサービス確認要求テーブル同様、振分ルール605も記録しても良い。その内容は、図5と同様であるのでここでは図示、説明を省略する。すなわち、番号1201~1207は図5の番号601~607に対応している。負荷予測部306は、制御用送受信部313、サービス振分判断部307と接続され、前段サービスと連携したサービスを提供するサービスが存在し、該サービスは前段サービスの負荷変動に関連した負荷変動とすることを想定した場合、前段のサービスの直近の負荷変動を取得することで、過去の変動履歴と合わせて、該サービスの負荷変動を予測する。図3Aにおいて、WANに接続される前段サービスのサービス309は、受信データのヘッダ部記載のサービス名を読み取り、上位階層のサービス名を取得する。受信データの本体部から送信元のサービス名を取得し、両者のサービス名をキーに、サービス変換テーブルから変換先のサービス名と変換ルールを検索し、フォーマット変換部に変換ルールとサービス名、受信データの本体部を送信する。同様に、後段サービスのサービス315は受信データのヘッダ部記載のサービス名を読み取り、上位階層のサービス名を取得する。受信データの本体部から送信元のサービス名を取得し、両者のサービス名をキーにサービス変換テーブルから変換先のサービス名と変換ルールを検索し、フォーマット変換部に変換ルールとサービス名、受信データの本体部を送信する。CloudManager318や他DC332は受信データのヘッダ部記載のサービス名を読み取り、上位階層のサービス名を取得する。受信データの本体部から送信元のサービス名を取得し、両者のサービス名をキーにサービス変換テーブルから変換先のサービス名と変換ルールを検索し、フォーマット変換部に変換ルールとサービス名、受信データの本体部を送信する。図3Bは、以上説明した、実施例1のプロキシにおける負荷予測から振り分け処理実施までのシーケンスの一例を示す図である。まず、制御用送受信部313は、前段サービス負荷情報を負荷予測部306に送信するS406。負荷予測部306は、受信した情報の復号化処理を行いS407、予測期間等のパラメータ設定を行いS408、トラフィック量予測処理を行い、予測情報をサービス振分判断部307に送信するS409、S410。サービス振分判断部307は回線帯域確認を行いS411、回線帯域超過分の振分け先決定依頼を送信するS412。依頼を受けた振分け先決定部312は、超過分の振分け先決定を行い、QoS情報策定依頼と共に、決定した振分け先一覧と振分けスループットをQoS情報策定部311に送信するS414。QoS情報策定部311は、振分けたトラフィックそれぞれに対しQoSを設定するS415。設定したQoS情報を振分ルールとしてサービス管理テーブル305に格納するS416。なお、以上説明した実施例1のデータセンタのプロキシにおける振分け処理方法の変形例を説明する。本実施例のデータセンタ間連携サービスシステムに利用される、いずれの通信回線も有限であることから、効率的に通信回線を使用できるように、夫々のサービスに優先度を設定する。すなわち、複数のサービスで使用する通信回線が競合し、他の要素で通信帯域の割り当てを解決できなかった場合に、振分け先決定部312は、図6に示す優先度制御管理テーブル609を利用して、割り当てる通信帯域の内訳を決定することができる。同図の優先度制御管理テーブル609は、サービス識別子602に対応する優先度制御情報610を記録する。この優先度制御管理テーブル609はサービスを管理するProxy単位で存在し、Proxyが存在するデータセンタ内サービスの優先順位を定義するものである。この優先度制御管理テーブル609は、図5に示したサービス管理テーブル305を拡張する形で蓄積することも可能であるが、別個に用意する形でも良い。以上のように、プロキシが各サービスにおいて、複数のサービス間の使用帯域の割り当てを調整する際に、振分先決定部312は、この優先度制御管理テーブル609を参照して優先度の高いサービスから帯域割り当て実施する。図6に示すように、優先度制御情報記載の優先度は3種類存在し、優先順位の高いほうから帯域保証型、帯域確保型、ベストエフォート型とする。帯域保証型は、サービスを提供する上で決められた最大帯域を保証するものであり、他の優先度を持つ連携サービスと使用回線が競合した場合、優先的に通信帯域を割り当てる。帯域確保型は、使用回線の通信帯域に余裕がある場合は、必要な通信帯域を割り当てるが、帯域保証型のサービスと帯域確保型のサービスで使用回線が競合する場合には、帯域保証型のサービスを優先して帯域を割り当て、帯域確保型サービスの使用帯域は要求帯域以下で運用することを許容する。また、ベストエフォート型の連携サービスと使用回線が競合する場合には、帯域確保型のサービスに優先的に帯域を割り当てる。ベストエフォート型は、最大帯域は決められているが、その帯域を保証されない。サービスを提供するタイミングで使用回線の帯域が余っていなければ、大きな遅延が発生する可能性もある。図7は第1の実施例におけるデータセンタDC構成の一具体例を示す図である。このデータセンタDCは、図1のDC1、DC2、DC3、DC4に対応する。同図に示すように、データセンタは、DC管理ノード、プロキシ、通信制御装置、複数の物理マシン、及び記憶装置から構成されている。符号501はサービスグループ構築部、符号502はサービス構成情報、符号503は機器構成情報、符号504はネットワーク構成情報、符号505はネットワーク構成情報収集部、符号506はサービス稼働情報、符号507は制御パラメータ生成部、符号508はDC管理ノード、符号509は物理マシン、符号510はWAN、符号511は通信制御装置、符号512は物理マシン、符号513は仮想マシン、符号514は仮想マシン、符号515は仮想マシン、符号516は仮想マシン、符号517は仮想マシン、符号518はServiceA、符号519はServiceB、符号520はServiceC、符号521はServiceD、符号522はServiceD、符号523は構成確認要求、符号524は制御用送受信部、符号525は送受信部である。図7のデータセンタDC構成において、物理マシン509はデータセンタ内において業務向けの情報処理を行うサーバ、すなわち情報処理装置337である。物理マシン509のハードウェア構成については、図示を省略した、一般のサーバの処理部であるCPUや記憶部であるメモリ等から構成されるコンピュータの構成と同じである。WAN510はデータセンタが接続される広域ネットワークの一例である。通信制御装置511はいわゆるスイッチやルータ等に代表される通信装置であり、通信装置335に対応するる。利用しないポート等を発見した場合には、外部からポートやNIF単位で省電力化モードにする機能を持っていることが望ましい。仮想マシン513は、例えばXen等の通常の仮想マシンをさす。サービスを実行するための動作環境をこの仮想マシン上に構築する。サービス構成情報502、機器構成情報503、ネットワーク構成情報504、サービス稼働情報506は、データセンタの磁気記憶装置等の記憶装置に記憶されている。この記憶装置は、記憶装置338に対応している。また、ServiceA518はソフトウェアで実装されたアプリケーションであり、図7の例においては、ServiceD522と接続されている。ServiceB519はServiceD522と接続されている。ServiceD522はServiceB519、ServiceA518と接続されている。これらのサービスは、図3Aのサービス301に対応していることは言うまでもない。Proxy内の送受信部525は、他データセンタやクライアントとサービスに関する情報をやり取りするインタフェースである。他データセンタやクライアントからProxyが管理するサービスへのRequestを受信し、処理結果を他のデータセンタやクライアントへ送信する。サービスのRequestには、SOAPやRESTのような分散処理システムで利用するメッセージ交換プロトコルを想定している。送受信部525では、受信データをフォーマット変換部へ転送、さらにはサービス処理結果に対して、先に説明したサービス管理テーブル305から送信先を参照し、ヘッダ情報を付けて送信する役目を持つ。なお、この送受信部525と制御用送受信部524は、それぞれ図3Aの送受信部303と制御用送受信部313に対応する。図7において、Proxyの制御用送受信部524からDC管理ノード508に対して、サービス管理テーブル305から自データセンタが送信元情報、送信先情報両者とも記録されていないサービスに関する情報は削除し、図3Aの構成確認情報316相当する構成確認要求523として送信する。同じくDC管理ノード317に対応するDC管理ノード508は構成確認要求523を受信してサービスグループ構成部501によって、隣接するサービスごとにグルーピングする。また、連携サービスが異なる場合でも、同じサービスを利用している場合もグルーピングの対象とする。そして、その内部に構成確認要求テーブルを蓄積することができる。その後、DC管理ノード508は、サービス構成情報502及びサービス稼働情報506、機器構成情報503を記憶装置から取得し、各サービスが動作している仮想マシンと物理マシンの対応を確認し、グルーピングの結果と対応結果とが異なる場合に、移行コストが一番小さい仮想マシンを見つけ出す。ネットワーク構成情報収集部505によってネットワークトポロジーを確認でき、トラヒックが削減されたことを確認する。以上のように移行する仮想マシンを発見すると、移行に関して必要なマイグレーションMigrationに関するサーバやスイッチ、ソフトウェアに対する制御方法を制御パラメータ生成部507で生成し、実際の物理マシンへの制御を実施する。より具体的に説明すると、サービスグループ構築部501は、送信されてきた構成確認要求523に対して、前後に隣接するサービスや、同じサービスを利用している連携サービスなど、いくつかの状況に合致したサービスを後で説明する手法でグルーピングし、現在のサービス構成情報及び機器の構成情報を考慮して、移動コストが一番少ない仮想マシンを検索する。サービス構成情報502はデータセンタ内の物理マシン、仮想マシン、サービスの組み合わせにおいていずれのサービスがどこの物理マシン、仮想マシンで動作しているかを把握するための情報である。機器構成情報503はデータセンタ内の機器情報を把握するための情報であり、物理マシン509、512や通信制御装置511が何台存在し、何台稼働しているかを把握する。ネットワーク構成情報504は物理マシンや通信制御装置などの物理的なネットワークの接続関係について把握するための情報である。ネットワーク構成情報収集部505はネットワーク構成情報を収集し、現在のネットワークトポロジーを作成する。物理マシン、仮想マシン、ネットワークトポロジーの情報を基に、マイグレーションの結果利用しないマシンやネットワークがあるか否かを検索し、検索の結果利用しないノード等が有った場合、対象となるノードを省電力化モードにして電力を削減する。サービス稼働情報506はサービスが現時点どのくらい稼働率で動作しているのかを把握するための情報である。サービス毎の負荷変動情報を格納するである。制御パラメータ生成部507はサービスグループ構成部501とネットワーク構成情報収集部506の結果を反映するために、実際の制御パラメータに変換して制御を行う。機器によるインタフェースの違い等はここで吸収する。DC管理ノード508はデータセンタ内の情報処理リソースを統合管理する。リソースを監視し、稼働状況に合わせて仮想マシンの集約分散を実施することによってデータセンタ内の省電力化を実現する。基本的には、サービスの稼働情報や機器構成情報等の収集機能を持っていればよい。以上、図7を用いて本実施例におけるデータセンタの構成の一具体例を説明したが、その構成の変形例を図8Aと図8Bを用いて説明する。まず、図8AにデータセンタDC内のプロキシのソフトウェアバージョンを示す。同図に見るように図3Aを用いて詳述したプロキシを図7の物理マシン上の仮想マシンの1つで構成する変形例である。同図において、図7と同一符号は、同一物を示している。プロキシ531は複数の物理マシンが収納されたサーバラック529中の物理マシン512の上に形成された仮想マシン530によって実現される。図7の構成同様、各種のプロキシ機能を実現すると共に、制御用送受信部532と送受信部533により、通信制御装置526、528、511、更には534を介して各種の通信を行う。一方、図8Bに、データセンタDC内のプロキシのハードウェアバージョンを示す。同図に見るように図3Aで詳述したプロキシを、通信制御装置中に設置された拡張ボード上で構成する変形例である。同図において、図7と同一符号は、同一物を示しているが、一部符号表示を省略した。本変形例においては、通信制御装置534上の拡張ボード535にプロキシ536が構成され、プロキシ機能を実現すると共に、制御用送受信部537と送受信部538により各種の通信を行う。図9A、図9Bは実施例1における、データセンタ内のリソース割当時の動作を示すフローチャートを示す図である。すなわち、データセンタDC内の情報処理位置を決定するためのフローチャートである。なお、フローチャート1、2は連続するフローチャートであり、丸印のA、丸印のBにおいて連続する。本フローチャートでは、連携するサービスでグルーピングをし、サービス間のデータ受け渡しをサーバ内のメモリ上での受け渡しで完了するようにすることでネットワーク上の通信量を削減することを可能にする。まず、ステップ901はProxyの制御用送受信部からDC管理ノードに対して構成確認要求とQoS管理定義テーブルを送信し、DC管理ノード317が受信を行う処理である。ステップ902はDC管理ノード317で構成確認要求523を受信し、サービスグループ構築部501においてサービスグルーピング開始し、内部に保持する構成確認要求テーブル等を用いて、同じ連携サービス内で接続関係にあるサービスの存在を確認する処理である。すなわち、送信元情報及び送信先情報を参照し、あるサービスの送信元情報が、あるサービスの送信先情報になっていることを確認できるかを調べる処理である。もしあるサービスの送信元情報があるサービスの送信先情報になっていることを確認できれば、ステップ903へ進む。送信元情報及び送信先情報を参照し、あるサービスの送信元情報があるサービスの送信先情報になっていることを確認できなければ、ステップ914、すなわちENDへ進む。ステップ903はグループ番号を発番し、該当するサービスにグループ番号を付与する処理である。ステップ904はグループが存在する複数の連携サービスにおいて、グループ間で同じサービスが存在するか否かを確認かどうか調べる処理である。もしグループが存在する複数の連携サービスにおいて、グループ間で同じサービスが存在するか否かを確認できれば、ステップ905へ進む。もしグループが存在する複数の連携サービスにおいて、グループ間で同じサービスが存在するか否かを確認できなければ、ステップ906へ進む。ステップ905はグループ番号を発番し、該当するグループにグループ番号を付与する処理である。ステップ906で、DC管理ノード908は、機器構成情報903とサービス構成情報902から現在のサービス配置状況を取得する。続いて、図9Bのフローに移り、ステップ907で、グループごとにサービスが物理マシン上に集約するようにサービス配置案を作成する。ステップ908において、作成した配置案のうち、グループ内のサービスの帯域変動の時間変化予測値を重畳させ、物理マシンの持つ通信帯域を超えないサービスの組み合わせを持つ配置案を抽出する。ステップ909において、抽出した配置案のうち、グループ内のサービスの負荷変動の時間変化予測値を重畳させ、物理マシンのCPU使用率が100以下になるサービスの組み合わせを持つ配置案を抽出する。更に、ステップ910において、抽出した配置案のうち、サービスの移動コスト、すなわち、転送時間、転送時の消費電力が最小になる配置案を抽出する。ステップ911において、抽出した配置案をもとに、VLANの設定を実施し、ステップ912において、該当するサービスに対して移動指示を発行する。ステップ913において、負荷分散装置の振分け先を設定し、終了するステップ914。なお、以上説明したデータセンタ内のサービスグループ構築部501でのサービスグルーピングの処理フロー901914の理解を助けるため、図11のタイミングチャートとしてその概略を示した。同図におい明らかなように、子管理ノードであるDC管理ノード1102中のプロキシ1104が、構成確認要求とQoS定義テーブルをDC管理ノード1102に送信する801ことで処理が開始される。まず、子管理ノード1102では、サービスグルーピング処理を開始する。すなわち、DC内で同じ連携サービスに属するサービスを検索する。もし、同じ連携サービスに属するサービスを発見した場合、グループ番号IDを発番し、サービス管理テーブルに登録する。複数のグループの中から重複するサービスを持つグループを検索し、重複するサービスを持つグループを発見した場合、新たにグループIDを発番し、サービス管理テーブルに登録する。全ての検索終了後、グループIDと各サービスの移動コストを基にして、サービスの配置を決定し、サービスの移動を指示する。以上、実施例1における、Proxyを利用したサービス振り分け方法を説明してきた。本実施例の方法では、応答時間と同時接続可能数で性能を評価しながら目的とするサービスのQoSを管理している。過剰なリソースが動作していることを検知すると、負荷に応じて過剰なリソースを省電力モードに移行させ、データセンタ内の消費電力を低減するシステムにおいて、データセンタをまたいで複数サービスが連携する場合、前段のサービスの稼働状況に応じて、後段のサービスを処理するためのリソースを増加させる。そのとき、前段のサービスは、常時サービスの負荷を計測しているデータセンタ内のDC管理ノードで、各サービスでQoSを違反した場合、スタンバイ状態のリソースを割り当て、即時対処するが、急激な負荷が発生した場合には、対応できず、複数のサービスを連携させて提供するサービスでは、QoS違反が他のサービスへも伝搬し、元々の違反以上の遅延や接続数の低下につながる可能性がある。そこで、複数のDC内のサービスを管理するProxyと、これら複数のProxyを管理する親管理ノードを連携させ、この親管理ノードで、違反の伝搬を事前に検知して、違反を発生したサービス以降のサービスで違反を吸収し、システム全体で自律的にQoSを保証することを可能にする。第2の実施例として、複数のProxyを管理する親管理ノードで違反の伝搬を事前に検知して、違反を発生したサービス以降のサービスで違反を吸収し、システム全体で自律的にQoSを保証することを可能とするネットワークシステムについて説明する。図3A、図7等に示したように、各データセンタには、管理装置としてのDC管理ノードが設置されているが、第2の実施例のネットワークシステムには、WAN等の広域ネットワークを介して、複数のデータセンタDCの複数の管理装置、すなわち複数のDC管理ノードと情報を送受信可能な、親管理装置としての親管理ノード318が設置されており、この親管理ノード318は、実施例1のおける、各Proxyから取得できるサービス情報を基に接続関係と接続方法を決定し、各Proxyに対してサービス連携情報を送信するよう機能することに加え、違反の伝搬を事前に検知し、違反を発生したサービス以降のサービスで違反を吸収し、システム全体で自律的にQoSを保証する。図13に、本実施例における親管理ノードが、システム全体で自律的にQoSを保証する機能を説明するシーケンス図である。なお、図3A等で説明した各データセンタ内の管理ノードを本実施例の説明においては、子管理ノードと呼び、親管理ノードと区別する。まず、図13において、データセンタの子管理ノード1102がデータセンタのプロキシ1104に対して、サービスIDリストと各サービスのQoS定義テーブルを送信する。この送信を受け、プロキシ1104は、サービスIDリスト記載のサービスを監視対象に登録し、サービスが利用する通信帯域の監視を開始する。そして、サービスの通信帯域のQoS警戒点超えを検出した場合、検出したサービスのServiceIDを子管理ノード1102に送信する。子管理ノード1102は移行先要求条件を決定し、決定した移行先要求条件を親管理ノード1101に送信する。親管理ノード1101では、移行先要求条件に合致するデータセンタリストを作成し、作成したDCリストを要求元の子管理ノード1102送信する。子管理ノード1102ではDCリストを受け、DCリストのRTTを調査して、優先順位決定を行い、優先順位上位のものからサーバのリソース確認要求を、決定したデータセンタの子管理ノード1103に送信すると共に、直近未来のService1のトラフィック変動を算出し、算出したService1のトラフィック変動データ送信を行う。トラフィック変動データを受信した子管理ノード1103では、Service2が動作するサーバを優先的に、Service1のトラフィックと重畳できるサービスの検出を行い、検出後、子管理ノード1103にOKを返信する1124。返信に応答し、子管理ノード1102は当該サービスの対象となるイメージデータ等と負荷分散制御ルールを子管理ノード1103に送信する。子管理ノード1103はそのイメージデータ等を該当するサーバに送信し、例えば、VMWareを利用するシステムにあっては、vCenterに登録し、負荷分散装置へ負荷分散制御ルールを設定し、完了通知を行う。更に、本実施例おける親管理ノード1101が更に、データセンタ間の仮想マシンの配置最適化処理を施すよう機能する場合について説明する。図14に本実施例に係わる、データセンタ間仮想マシン配置最適化処理を示すシーケンス図である。同図において、CloudServerである親管理ノード1101はサービスのフロー情報を各データセンタの子管理ノードに対して定期的に収集を行う1408。この定期的な情報収集は、図12の場合、子管理ノード1102、1103、1130に対し順次フロー情報取得要求を送信し1409、1411、1413、サービス単位のフロー情報を収集する。取得したサービスフロー情報からデータセンタ間でデータの送受信が存在するDCを複数選択し、選択したDCのリストを作成し1416、最適化処理指示とDCリストを送信する1417、1418。DC21103に移動可能仮想マシンリスト要求を行う。これに対応し、DC21103において、各サービスの移動制約条件を基に、DC11102へ移動可能なVMリストを作成し、DC11102に送信する1421。これを受け、子管理ノードDC11102では、図12のステップ1422~1429を実行する。すなわち、選択したVMが動作中の物理サーバのCPU負荷情報及びと送受信しているトラヒックの時系列データの予測値を取得、選択したVMのフロー情報とVMリストを基に選択したVMと通信が発生しているVMを検索、検索結果とDC1内で選択したVM以外のVMのCPU利用率及びトラヒック量の時系列データの予測値を選択したVMが動作中の物理サーバのそれに時間を合わせて重ね合わせ、CPU利用率が100、トラヒック量が物理サーバに接続された回線条件を超えないVMを検索、物理サーバにVMが一番たくさん搭載される場合を最適解とし、集約するVMのリストを作成、集約VMリストを基に、VMを物理サーバに移動、VMの集約が終了し、これまで選択されていないDC1内のVMを選択し、移動可能VMリスト要求から繰り返し実施する。本実施例によれば、複数のProxyを管理する親管理ノードで違反の伝搬を事前に検知して、違反を発生したサービス以降のサービスで違反を吸収し、システム全体で自律的にQoSを保証することを可能となる。さらに、親管理ノードにより、データセンタ間の仮想マシンの配置最適化処理を施し、システム全体で自律的にQoSを保証し、省電力化を図ることができる。なお、本発明の種々の実施例について説明してきたが、本発明はこれらの実施例に限定されるものなく、様々な変形例が含まれうることは言うまでもない。上述した実施例は本発明のより良い理解のために説明したものであり、本発明はそれに限定されるもので無い。また、ある実施例構成の一部を他の実施例の構成に置き換えることも可能であり、ある実施例の構成に他の実施例の構成を加えることも可能である。また、上述した各実施例の構成、機能、処理手段等は、それらの一部又は全部をソフトウェア構成のみならず、専用のハードウェア構成、あるいはそれらを共用した構成としても良いことは言うまでもない。また、以上詳述した本発明の開示内容から明らかなように、特許請求の範囲に記載された請求項に係る発明以外の発明も、本願明細書に多数存在する。その一部を例示すれば下記のとおりである。例示1:ネットワークシステムは外部のネットワークシステムからの要求に対してサービスを提供するシステムであって、当該ネットワークシステムは当該サービスを管理するソフトウェアと、前記ソフトウェアと連動してネットワークシステムを構成する情報処理装置や通信機器などの管理を行う管理装置と、当該ネットワークシステムを構成し、当該サービスを実行するための情報処理装置及び通信装置によって構成された前記ネットワークシステムにおいて、サービスを実行する情報処理装置の位置を変更することでネットワークシステム内に発生する通信量を削減し、利用していない装置等の電力を下げ、さらには省電力向けのシステムが備わる装置については前記管理装置から省電力を実現する状態に変更することで、前記ネットワークシステム全体の省電力化を実現するリソース割当方法。例示2:例示1のネットワークシステムを複数連動させることによって高負荷なサービス要求に対してもお応答性能を確保しつつ省電力化を実現できるネットワークシステム。例示3:例示2の連動したネットワークシステムにおいて、ネットワークシステム上で提供するサービスを連携させることによって、前段で発生した高負荷なサービス要求に対しても、必要十分な資源を各ネットワークシステムから確保し、決められたサービス品櫃保証を実現することができる例示1のソフトウェア。例示4:ネットワークシステムの構成要素を管理する管理装置がネットワークシステムとネットワークシステム外部のネットワークシステムをつなぐネットワークを管理する例示1のソフトウェアにおいて、前記ソフトウェアが管理するサービス間の連携方式が記載されているサービス管理情報を例示1の管理装置が前記ソフトウェアから取得し、前記管理装置が管理する情報処理装置及び通信機器を制御し、サービスの実行場所を決定することで通信量を削減することを可能にする管理装置。例示5:例示1のネットワークシステムにおいて、当該ネットワークシステム以外の複数のネットワークシステムが提供するサービスとの接続関係が記載された前記ソフトウェアが管理するサービス管理情報。例示6:例示3の前記ソフトウェアに関して複数のネットワークシステムにそれぞれ例示3の前記ソフトウェアと前記ソフトウェアが管理する例示5のサービス管理情報を所有させてサービスの接続関係を規定し、さらにそれぞれネットワークシステムが提供するサービスの入出力の違いを前記ソフトウェアで変換して吸収することで入出力の異なるサービス間を連携させることを可能にするサービス連携方法。例示7:ネットワークシステムが提供するサービスを例示3のソフトウェアで管理し、さらにそれぞれのサービスのサービス品質をサービス品質定義情報によって管理することで、サービス品質の劣化を検知することが可能な例示3のソフトウェア。例示8:ネットワークシステムが提供するサービスを例示3のソフトウェアで管理し、さらにそれぞれのサービスのサービス品質をサービス品質定義情報によって管理することで、サービス品質の劣化を検知することが可能なサービス品質定義情報。例示9:ネットワークシステム内の通信量削減するためのサービスの実行位置を決定する例示4の管理装置において、前記実行位置を決定するために、前記ネットワークシステムが提供するサービスのソフトウェアの入出力先情報に対して当該ネットワークシステム外のサービスからの入力や当該ネットワークシステム外のサービスへの出力になる当該ネットワークシステムが提供するサービスを除いた情報として例示3のソフトウェアが生成して例示4の管理装置へ転送する構成要素確認要求情報。例示10:例示1のソフトウェアが実装されたサービス管理装置。"