(57)【要約】  【課題】  本発明は、ビジネスポリシーからサービスポリシーへの変換、サービスポリシーから制御ポリシーへの変換の制御を開示し、ビジネスポリシーを利用して実行ポリシーへの変換制御を行う事ができる自律制御装置・自律制御方法、及び自律制御プログラムを提供する事を目的とする。  【解決手段】ビジネス要件を示すビジネスポリシー情報が入力された場合、その構成要件を示すサービスポリシー情報１０４を生成するサービス構造分析部１０２と、前記サービスポリシー構造分析部１０２によって生成されたサービスポリシー情報を、過去の事例を記憶した運用データベース１０７の事例情報を基に、実際のＩＴリソースの制御要件である制御ポリシー１０８を生成するポリシーコンパイラ１０５と、前記ポリシーコンパイラ１０５で生成した制御ポリシー１０８に応じてＩＴリソースの制御を行うフロー制御部１０９とを設けた。  【選択図】  図３
2007047845.tif 000002
【特許請求の範囲】
【請求項１】
コンピュータを、
ビジネス要件を示すビジネスポリシー情報が入力された場合、その構成要件を示すサービスポリシー情報を生成するサービス構造分析部と、
前記サービスポリシー構造分析部によって生成されたサービスポリシー情報を、過去の事例もしくはシミュレーションによる検証の結果を基に、実際のＩＴリソースの制御要件である制御ポリシーを生成するポリシーコンパイラと、
前記ポリシーコンパイラで生成した制御ポリシーに応じてＩＴリソースの制御を行うフロー制御部と、
して機能させることを特長とする自律制御プログラム。
【請求項２】
前記サービス構造分析部が生成するサービスポリシー情報には、ＩＴリソースを減少する手順の項目を含む
事を特徴とする請求項１記載の自律制御プログラム。
【請求項３】
前記ＩＴリソースを減少する項目には、稼動ＩＴリソースを1台とする制御指示を規定す
る事が可能である
事を特徴とする請求項２記載の自律制御プログラム。
【請求項４】
前記ＩＴリソースを減少する項目には、稼動ＩＴリソースを1台ずつ減少する制御指示を
規定する事が可能である
事を特徴とする請求項２または請求項３記載の自律制御プログラム。
【請求項５】
前記サービス構造分析部が生成するサービスポリシー情報には、平均レスポンス時間及びピークレスポンス時間を規定する項目を含み、
前記ポリシーコンパイラは、前記サービス構造分析部が生成したサービスポリシー情報の平均レスポンス時間及びピークレスポンス時間の項目が規定されているか否かを参照しながら制御ポリシー情報を生成する
事を特徴とする請求項１記載の自律制御プログラム。
【請求項６】
前記フロー制御部は、
各機能の機能モジュールを有するとともに、
機能モジュール毎に定義した共通インターフェースを利用して、各機能モジュールを呼び出す制御部と、
前記制御部からの共通インターフェースによる呼び出しを対象となる機能モジュールが理解できる形式に変換し、対象となる機能モジュールに提供するアダプタと
を有する事を特徴とする請求項１から請求項５の何れかに記載の自律制御プログラム。
【請求項７】
前記フロー制御部は、制御ポリシーにより、複数のフロー制御が可能であるとともに、
各フロー制御間でのＩＴリソース調整を行う上位フロー制御部を有する
事を特徴とする請求項１から請求項６の何れかに記載の自律制御プログラム。
【請求項８】
コンピュータが、
ビジネス要件を示すビジネスポリシー情報が入力された場合、その構成要件を示すサービスポリシー情報を生成するサービス構造分析ステップと、
前記サービスポリシー構造分析ステップによって生成されたサービスポリシー情報を、過去の事例もしくはシミュレーションによる検証の結果を基に、実際のＩＴリソースの制御要件である制御ポリシーを生成するポリシー生成ステップと、
前記ポリシー生成ステップで生成した制御ポリシーに応じてＩＴリソースの制御を行うフロー制御ステップと、
を実行することを特長とする自律制御方法。
【請求項９】
前記サービス構造分析部が生成するサービスポリシー情報には、平均レスポンス時間及びピークレスポンス時間を規定する項目を含み、
前記ポリシーコンパイラは、前記サービス構造分析部が生成したサービスポリシー情報の平均レスポンス時間及びピークレスポンス時間の項目が規定されているか否かを参照しながら制御ポリシー情報を生成する
事を特徴とする請求項６記載の自律制御方法。
【請求項１０】
ビジネス要件を示すビジネスポリシー情報が入力された場合、その構成要件を示すサービスポリシー情報を生成するサービス構造分析部と、
前記サービスポリシー構造分析部によって生成されたサービスポリシー情報を、過去の事例もしくはシミュレーションによる検証の結果を基に、実際のＩＴリソースの制御要件である制御ポリシーを生成するポリシーコンパイラと、
前記ポリシーコンパイラで生成した制御ポリシーに応じてＩＴリソースの制御を行うフロー制御部と、
して機能させることを特長とする自律制御装置。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は、ネットワークにより接続され複数の情報処理装置から構成される情報処理システムを自律制御する自律制御装置・自律制御方法、及び自律制御プログラムに関し、特に、情報処理システムの制御要件（ポリシー）にしたがって柔軟な自律制御を行うことができる自律制御装置・自律制御方法、及び自律制御プログラムに関するものである。
【背景技術】
【０００２】
今日、Ｗｅｂシステムなどでは、随時大量の処理が行われており、単体のＩＴリソースでは対応が不可能となっている。
【０００３】
そこで、クライアントからの窓口であるＷｅｂサーバ、Ｗｅｂサーバでうけたクライアントからの要求を元に各種処理を行うアプリＩＴリソース、及びアプリＩＴリソースに要求に応じたデータベース検索を行うデータベースＩＴリソースを利用する３階層システムを筆頭に複数のＩＴリソースに連携におけるシステムが構築されるようになり、更に、これか各ＩＴリソースも複数のＩＴリソースからなるＩＴリソースシステムとして構築する事で、大量の処理を可能としている。
しかしながら、上記きた様に、システムは複雑化し、それが連携して最適な状態で稼動させる事が難しくなっている。
【０００４】
例えば、サービスにより時間帯・曜日・月などによる負荷変動が発生するものがあり、ある時点で最適な状態にシステムを構築してみても、トータルの運用効率が良いとは限らない。
【０００５】
また、障害対応に伴う、縮退運転・代替えＩＴリソースへの切り替えは、迅速かつ適切に行う事が必要と成るが、上記したように、現状のシステムではその複雑さのためにその障害の基となる異常個所の特定、及びその対応を迅速に行う事は難しい。
【０００６】
さらに、将来の予測を行い、将来の状態を加味した運用を行う事が望ましい。
【０００７】
上記した処理は、従前は、そのシステムの管理者が、システムの状態を監視し、その監視状態に合わせたシステムを構築する事が必要であり、効率的な運用は、システム管理者のノウハウに依存する事になり、かつ、システムが複雑化していくごとに、管理者での効率的な運用が難しいものとなっている。
【０００８】
これら安定運用に関わる制御に加え、システムの大規模化に伴い、システム自体が高価となり、また、規模が大きく複雑になるほど、管理面でも手間も増加するので、ハードウエア・ソフトウエアの増設に伴う効果と、その導入費用との対比についての検討を行いながら柔軟にシステム変更を行っていく必要がある。
【０００９】
例えば、レスポンス確保のためにＩＴリソースを増設する事が検討されるが、不用意にＩＴリソースを増設しても運用コストがかかるだけであり、また、各ＩＴリソースの稼働率も最適なものとはならない、などである。
【００１０】
近年では、これらに対応すべく、非特許文献１に示されるように、システム自身に階層型のポリシーに基づき、各種制御を行わせる事により、管理者の手を煩わせることなく、制御を行う、自律運転制御の検討が行われている。
【００１１】
このポリシー制御は、階層が上がるごとに抽象的な概念が明記されており、ポリシーの階層が下位になるほど具体的なポリシーが定義され、最下位の実行ポリシーにおいては、各ハードウエア・ソフトウエアに対する指示
また、柔軟なポリシー運用のためには、ある程度の予備ＩＴリソースが必要であり、かつ、それらのＩＴリソースが、システム内で必要とされる処理に迅速に対応するために、柔軟な運用を行わせる事が望ましい。
【００１２】
この様なポリシー制御のための予備ＩＴリソースの制御に関しては、特許出願人は、特許文献１に示す特許出願を行っている。
【非特許文献１】「ビジネスを支えるＴＲＩＯＬＥ」、雑誌ＦＵＪＩＴＳＵ  Ｖｏｌ    ．５６  Ｎｏ．１（通巻３２６号）  Ｐ９〜Ｐ１５、２００５年１月１１日発行
【特許文献１】特願２００４−１６２４４２（出願時非公開）
【発明の開示】
【発明が解決しようとする課題】
【００１３】
非特許文献１においては、ビジネス要件をビジネスポリシー、定量的なシステム性能要件動作ルールを示したサービスポリシー、論理アクションを記載する制御ポリシー、実際の実行コマンドである実行ポリシーの各階層における概念の記載があり、上位のポリシーから下位のポリシーへの変換が必要である点について記載されている。
【００１４】
また、特許文献１には、制御ポリシーから実行ポリシーの具体的な記載が成されている。
【００１５】
しかしながら、これらの従来の技術においては、ビジネスポリシーからサービスポリシーへの変換、サービスポリシーから制御ポリシーへの変換についての具体的な制御については開示が無い。
【００１６】
本発明は、ビジネスポリシーからサービスポリシーへの変換、サービスポリシーから制御ポリシーへの変換の制御を開示し、ビジネスポリシーを利用して実行ポリシーへの変換制御を行う事ができる自律制御装置・自律制御方法、及び自律制御プログラムを提供する事を目的とする。
【課題を解決するための手段】
【００１７】
本発明は、上記従来の課題を解決するために、
ビジネス要件を示すビジネスポリシー情報が入力された場合、その構成要件を示すサービスポリシー情報を生成するサービス構造分析部と、
前記サービスポリシー構造分析部によって生成されたサービスポリシー情報を、過去の事例もしくはシミュレーションによる検証の結果を基に、実際のＩＴリソースの制御要件である制御ポリシーを生成するポリシーコンパイラと、
前記ポリシーコンパイラで生成した制御ポリシーに応じてＩＴリソースの制御を行うフロー制御部と、を設けたものである。
【００１８】
このように構成する事で、過去の事例を利用しながら、もしくは、シミュレーションの結果を利用する事により、ビジネスポリシー情報を制御ポリシー情報へ変換させる事ができる様になり、ビジネスポリシー情報を入力するだけで、制御ポリシー情報を使った自律制御が可能となる。
【発明を実施するための最良の形態】
【００１９】
以下に添付図面を参照して、この発明に係る自律制御装置・自律制御方法、及び自律制御プログラムの好適な実施例を詳細に説明する。
【実施例】
【００２０】
まず、本実施例に係る自律制御システムの構成について図１を用いて説明する。
【００２１】
本実施例での自律制御システムは、インターネットなどの広域ネットワーク１を経由して、広域ネットワーク1に接続されている多数のクライアント（本実施例ではクライアン
ト２〜５）から到来するリクエストを処理し、要求を行ったクライアント（本実施例ではクライアント２〜５のいずれか）に処理結果を送信する、Ｗｅｂシステム６を対象としている。
【００２２】
このＷｅｂシステム６の各構成要素は、広域ネットワーク１とは異なる、専用の高速ネットワーク７に接続され、この高速ネットワーク７を経由して他の構成要件との情報の授受を行っている。
【００２３】
このＷｅｂシステム６構成要件に付いて説明する。
【００２４】
まず、８は広域ネットワーク１にも接続され、広域ネットワーク１経由で受信したリクエストを所定の定義に従い他の構成要件へ送信する処理を行うロードバランサである。
【００２５】
また、９〜１６は、汎用のＩＴリソースであり、導入するソフトウエア（ＯＳ・ミドルウエア）により、各種役割を果たす事ができることから、一般にＩＴリソースと呼ばれる。
【００２６】
１７は、ＩＴリソース９〜１６の役割を決定し、各ＩＴリソースがその役割に応じた処理を行いつつ、連携システムとして運用できるよう、各ＩＴリソース９〜１６の管理を行う管理サーバである。
【００２７】
次に、管理サーバ１７によって、役割を決められたＩＴリソースの概要を図２に示す。
【００２８】
図１のように構成しておけば、設定によりロードバランサ７が、ＩＴリソース８，９のみにリクエストを送信するなど、各ＩＴリソースに設定を行う事で適宜通信相手を決めていく事が可能となる。このため、物理的な接続は図１に示すとおりであるが、各ＩＴリソース９〜１６に対し、それぞれ、実行させる処理を決め、その処理が可能となるよう、各ＩＴリソースに対し、オペレーティングシステム（ＯＳ）、ミドルウエア、アプリケーションソフトウエアを導入し、また、通信可能なＩＴリソースを適切に限定する事により、連携システムとして動作させる事が可能である。
【００２９】
この概要を図２に示す。
【００３０】
この例は、ＩＴリソース９〜１６に各種ソフトウエアが導入され、クライアントからのリクエストを解析し、サーチサーバへ送信するＷｅｂサーバ２０，２１、ディレクタサーバ２４、サーチサーバ２２，２３として処理可能とし、かつ、その通信相手を適宜決めたものである。
【００３１】
この構成要件は、管理サーバ１７によって決定され、各ＩＴリソースが指定された処理ができるよう管理サーバ１７によりソフトウエア導入制御及び各種設定の指示を行ったものである。
【００３２】
この構成では、クライアント２〜５よるリクエストをロードバランサ７が受け、Ｗｅｂサーバ２０，２１に適宜分配し、そのリクエストを受けた方のＷｅｂサーバ２０もしくは２１が、ＳＱＬ分などのデータベース検索用言語へ変換し、ディレクタサーバ２４へ送信、更にディレクトリＩＴリソースが、実際の検索処理を行うサーチサーバ２２，２３の何れかに、対しその変換されたリクエストを送信し、そのリクエストを受けた方のサーチサーバ２２または２３が、ＸＭＬデータベース２５に対し、検索処理を行う連携システムとなっている。
【００３３】
また、２６〜３２はＩＴリソースプールで、これは、現在、役割を与えられていない、いわば余剰ＩＴリソースであり、管理サーバ６により構成を変更されたときに、新たに役割を与え、Ｗｅｂサーバ、サーチサーバの機能を強化させることも可能である。
【００３４】
逆にリクエストの頻度が低い場合は、例えば２台のＷｅｂサーバ２０，２１のうち、1
台（実施例ではＷｅｂサーバ２１）のＷｅｂサーバ機能を停止し、ＩＴリソースプールに変更し、他の不足するリソースへの転用を図れるようにする事も可能である。
【００３５】
また、構成要件の変更要件としては、ビジネス的な要因が考えられる。
【００３６】
例えば、近年、ある企業のＩＴリソースを、ＩＴリソースを利用したい企業が、必要なＩＴリソース量・時間で貸与するオンデマンドサービスと呼ばれるサービスがある。
【００３７】
このサービスは、システムとしては、ＩＴリソースを保有する企業のシステム構成を、ＩＴリソースを必要とする企業が要望するシステムに変更する処理を行う事によって行われるが、貸与である以上、各ＩＴリソース量に応じて課金が行われるため、サービスを受ける企業としては、必要以上のＩＴリソースを必要以上に保持したくない。よって、サ＾ビスを受ける企業が求めるスペックを、適切なＩＴリソース数で実現する必要性がある。
【００３８】
この状況に応じた最適ＩＴリソース管理処理を行うのが管理サーバ１７である。
【００３９】
この管理サーバ１７が管理者から与えられたビジネス要件（ビジネスポリシー）を基に最適なリソース管理処理を行う。
【００４０】
以下に、この管理サーバ１７の構成について説明する。
【００４１】
図３は、管理サーバ１７の構成図である。
【００４２】
まず、１０１はビジネスポリシー入力部であり、システムの管理者が入力したビジネスポリシー情報を受け付ける。
【００４３】
このビジネスポリシー入力部１０１は、キーボード・マウスに、ＧＵＩに入力内容の表示を行う事等により、利用者からの入力を受け付ける。
【００４４】
１０２は、ビジネスポリシー入力部１０１からのビジネスポリシー情報を分析し、サービスポリシー情報を出力するサービス構造分析部であり、ビジネスポリシー入力部１０１よりのビジネスポリシー情報、サービス構造分析部１０２のサービスポリシー情報生成に伴う各種情報（生成中のサービスポリシー情報など）を記憶するポリシー記憶部１０３へのアクセスが可能となっている。なお、１０４はサービス構造分析部１０２により分析されたサービスポリシー情報である。
【００４５】
１０５は、サービスポリシー情報を元に制御ポリシー情報を生成するポリシーコンパイラで、サービス構造分析部が出力したサービスポリシー情報１０４を記憶するとともにポリシーコンパイラ１０５が生成もしくは生成中の制御ポリシー情報を記憶するポリシー記憶部１０６へのアクセスが可能である。
【００４６】
１０７は、過去の運用における各種履歴情報が記憶された運用データベースである。
【００４７】
１０９はポリシーコンパイラ１０５が生成した制御ポリシー情報１０８に従い、各ＩＴリソースへの制御を行うフロー制御部である。
【００４８】
このフロー制御部１０９は、現在のＩＴリソースの構成／性能情報を記憶する記憶部１１０にアクセス可能であるとともに、ポリシーコンパイラ１０５が生成した制御ポリシー情報を記憶するポリシー記憶部１１１とアクセス可能である。
【００４９】
また、フロー制御部１０９は、対象のＩＴリソースを制御ポリシーで既定された条件で監視／計測する監視・計測部１１２、監視・計測部からの情報を制御ポリシー情報に合致するか分析する分析部１１３、分析部１１３の分析結果を基に、制御ポリシー情報に基づいたＩＴリソース配置などを設計・検証する設計・検証部１１４、設計・検証部１１４によって設定されたＩＴリソース配分になるよう、各ＩＴリソースへ制御の指示などの操作を行う操作部１１５を有し、かつ、ポリシーコンパイラにより生成された制御ポリシー情報に合致する制御を行うべく、上記した監視・計測部１１２、分析部１１３、設計・検証部１１４、操作部１１５に対する制御指示を行う制御部１１６を有する。
【００５０】
なお、上記した各種ポリシー情報について補足する。
【００５１】
ビジネスポリシー入力部１０１で入力されるビジネスポリシー情報は、ビジネス計画・収益条件などを記入したポリシー情報である。
【００５２】
利用者は、限られた予算で効率的に収益をあげることを目的としており、その目的を入力した際に、その目的に合致するシステムを、ＩＴリソースを自律構成する事を目的としている。
【００５３】
また、サービス構造分析部１０２により生成されるサービスポリシー情報は、「システムの平均レスポンス時間：１３００ｍｓ未満」「利用可能ＩＴリソース：１０台」など、システムの性能要件の制約や、満たすべき条件（上記では平均レスポンス時間など）を示すポリシー情報である。サービス構造分析部１０２は、ビジネスポリシー入力部１０１で入力されるビジネスポリシー情報を分析し、サービスポリシー情報を生成する。
【００５４】
次に、ポリシーコンパイラ１０５で生成される制御ポリシー情報は、サービス構造分析部１０２からのサービスポリシー情報に基づいて、実際のシステムの性能・構成制約を満たすために具体的に各ＩＴリソースをどのような条件でどのように制御するかを示すポリシー情報である。ポリシーコンパイラ１０５は、サービスポリシー情報と過去の運用データベースに記憶されている過去の運用事例情報を基に、この制御ポリシー情報の生成を行う。
【００５５】
更に操作部１１５から各ＩＴリソースに送られる実行コマンドなどのＩＴリソース制御指示情報、もしくは、ＩＴリソースから監視・計測部１１２へ送られてくるＩＴリソースの状態情報など、直接フロー制御部１０９とＩＴリソースとの通信を行う際の情報を実行ポリシー情報としており、実際には通信用のコマンド形式情報である。
【００５６】
以上のように構成された自律制御システムにおいて、以下その処理に付いて説明する。
【００５７】
なお、ポリシー記憶部１０３には、図５のテーブル図に示すように、「経済性重視・平均レスポンス保持」「性能重視・最悪状況でもレスポンス保証」に対応する、システムのスペック情報であるサービスポリシー情報が記憶されている。本実施例では、１つのビジネスポリシーに対し、「平均レスポンス時間」「ピークレスポンス時間」「負荷増加ペース」「データ無し（がある場合の対応）」「ＩＴリソース最大保有数」の５項目のサービスポリシー情報が対応付けられ、記憶されている。
【００５８】
また、各ビジネスポリシーに対するサービスポリシーの定義について補足する。
【００５９】
まず、ビジネスポリシー情報が、「経済性重視・平均レスポンス保持」では、最大にかかるレスポンス時間（ピークレスポンス）は多少犠牲としても、平均のレスポンス時間を所定以下に抑え、かつ、稼動中のＩＴリソース数を少なくすることを目的として、定義されている。即ち、図５に示すように、「平均レスポンス時間」の項目の定義は行うが「ピークレスポンス時間」の項目については特に規定しない。また、「データ無し」項目は、処理中データが無い場合を定義しており、経済性重視のため、最低限の稼働台数である１台のＩＴリソースを残し、それ以外のＩＴリソースは全て切り離す事を示す「即時切り離し」を定義する。また、経済性重視のため、「ＩＴリソース最大確保数」項目は、後述する「性能重視・最悪状況でもレスポンス保証」の場合に比べ少ない台数となっている。
【００６０】
次に、ビジネスポリシー情報が、「性能重視・最悪状況でもレスポンス保証」は、平均レスポンスを維持する事に加え、どのようなリクエストに対しても所定レスポンス時間以内での処理を保証するということを目的として定義されている。このため、「平均レスポンス時間」「ピークレスポンス時間」の各盲目について規定が成され、更に、処理中のデータが一旦なくなった後、大量のリクエストがあるような場合にも対処できるように、「データ無し」項目は、処理中データがなくなったら、所定間隔で、1台ずつ稼動ＩＴリソ
ースを減らす事を示す「順次切り離し」を定義している。
【００６１】
なお、本実施例は、負荷増加ペースが早いと予めわかっている事を前提としており、サービスポリシー情報の「負荷増加ペース情報」項目は双方のビジネスポリシー情報とも「大」として定義されている。
【００６２】
以上の点を基に、ビジネスポリシー入力部１０１にビジネスポリシー情報が入力された場合の、サービス構造分析部１０２の処理について図４のフローチャートを用いて説明する。
【００６３】
まず、ビジネスポリシー入力部１０１にビジネスポリシー情報が入力されると（Ｓ１００１）、サービス構造分析部１０２は、このビジネスポリシー情報をポリシー記憶部１０３に記憶する（Ｓ１００２）。本実施例の場合、「経済性重視・平均レスポンス保持」とするビジネスポリシー情報が入力されたものとする。
【００６４】
次に、サービス構造分析部１０２は、ポリシー情報記憶部１０３に予め記憶されているビジネスポリシー情報−サービスポリシー情報対応テーブルを参照し、Ｓ１００２で記憶したビジネスポリシー情報に対応するサービスポリシー情報を抽出する（Ｓ１００３）。
【００６５】
上記したようにこの実施例では、「経済性重視・平均レスポンス保持」とするビジネスポリシー情報が入力され、ポリシー情報記憶部１０３に予め記憶されているビジネスポリシー情報−サービスポリシー情報対応テーブルは、上記したように、図５のテーブル図のとおりであるので、サービスポリシー情報１０４として、図６に示すように「平均レスポンス時間：１３００ｍｓ」「ピークレスポンス時間規定無し」「負荷増加ペース：大」「データ無し：即時切り離し」「データ最大保有数：１０台」が抽出される。
【００６６】
サービス構造分析部１０２は、この抽出したサービスポリシー情報をポリシーコンパイラ１０５へ送信する。
【００６７】
次に、このサービスポリシー情報を受けたポリシーコンパイラ１０５が行う制御ポリシー生成処理について、図７を用いて説明する。
【００６８】
なお、本実施例のポリシーコンパイラ１０５がアクセス可能なポリシー記憶部１０６は、サービス構造分析部１０２からのサービスポリシー情報１０４や、ポリシーコンパイラ１０５で制御ポリシー生成処理を行う際の生成中制御ポリシーの一時記憶を行うとともに、図７のテーブル図に示すに示すＩＴリソース数減少時の基本ポリシー情報、図８のテーブル図に示すようなＩＴリソース数増加基本ポリシー情報を予め記憶している。
【００６９】
このうち、ＩＴリソース数減少時の基本ポリシー情報には、サービスポリシー情報のうち、データ無しの値（即時切り離し、順次切り離し）に応じて、２つの基本制御ポリシー情報が記憶されている。
【００７０】
まず、ポリシーコンパイラ１０５は、サービス構造分析部１０２からサービスポリシー情報を受信する処理を行う（Ｓ２００１）。
【００７１】
ここで、受信できなければ、ポリシーコンパイラ１０５は、ステップＳ２００１の処理を繰り返す（Ｓ２００２）。
【００７２】
また、ポリシーコンパイラ１０５は、ステップＳ２００２の処理において、サービスポリシー情報を受信したと判断すると、ポリシー記憶部１０６にサービスポリシー情報を記憶する（Ｓ２００３）。
【００７３】
その後、ポリシーコンパイラ１０５は、このポリシー記憶部１０６に記憶したサービスポリシー情報、上記した基本制御ポリシー情報及び運用データベース１０７にある過去の事例情報を基に、制御ポリシー情報を生成する（Ｓ２００４）。
【００７４】
このステップＳ２００４における、制御ポリシー情報生成処理に付いて詳しく説明する。
【００７５】
この制御ポリシー生成処理Ｓ２００４は、本実施例においては、図１０に示されるように、監視間隔設定処理（ステップＳ３００１）、ＩＴリソース数減少設定処理（ステップＳ３００２）、ＩＴリソース数増設設定処理（ステップＳ３００３）の処理の順に処理される。
【００７６】
まず、監視間隔設定処理（ステップＳ３００１）の処理について図１１を用いて説明する。
【００７７】
まず、ポリシーコンパイラ１０５は、運用データベース１０７を参照し、ポリシー記憶部１０６に記憶したサービスポリシー情報の「平均レスポンス時間」「ピークレスポンス時間」の値未満で処理が成された事例を抽出する（Ｓ４００１）。
【００７８】
このとき、複数の事例が抽出された場合（Ｓ４００２）、ポリシーコンパイラ１０５は、平均レスポンス時間が一番短い事例を選択する（Ｓ４００３）。
【００７９】
そして、ポリシーコンパイラ１０５は、抽出・選択された事例で使用された監視時間情報を、制御ポリシー情報として、ポリシー記憶部１０６に記憶する（Ｓ４００４）。
【００８０】
本実施例の場合、この処理によって、抽出・選択された事例の監視間隔が、５０００ｍｓであったので、図１２に示す様に監視間隔を５０００ｍｓである事を示す制御ポリシー情報が生成され、ポリシー記憶部１０６へ記憶される。
【００８１】
この処理が完了すると、上記したように、ポリシーコンパイラ１０５は、ＩＴリソース数減少設定処理（Ｓ３００２）を行う。
【００８２】
このＩＴリソース数減少設定処理（Ｓ３００２）について、図１３を用い、その処理の説明を行う。
【００８３】
まず、ポリシーコンパイラ１０５は、ポリシー記憶部１０６から、図７に示されるＩＴリソース減少基本ポリシーのうち、同じく、ポリシー記憶部１０６に記憶されているサービスポリシー情報の条件に対応した基本ポリシー情報を抽出する（Ｓ５００１）。
【００８４】
本実施例では、図７のＩＴリソース数減少基本ポリシー記憶テーブルに示されるＩＴリソース数減少基本ポリシーであり、このＩＴリソース数減少基本ポリシー情報の選択の条件は「サービスポリシーのデータ無し」項目を対象としているので、ポリシーコンパイラ１０５は、ポリシー記憶部１０６に記憶されているサービスポリシー情報の「データ無し」の項目を参照する。
【００８５】
そして、上記してきた様に、本実施例では、図６に示されるサービスポリシー情報が、ポリシー記憶部１０６に記憶されているので、本実施例のポリシー記憶部１０６に記憶されているサービスポリシー情報の「データ無し」の項目「即時切り離し」の条件に合致するＩＴリソース数減少基本ポリシー情報が選択され、この選択されたＩＴリソース数減少基本ポリシー情報を、ステップＳ４００４にて記憶された制御ポリシー情報に追加記憶する。この際、ポリシーコンパイラ１０５は、基本ポリシーに、サービスポリシー情報の項目が規定されていれば、その項目部分を、ポリシー記憶部１０６に記憶されているサービスポリシー情報の対応項目で規定されている値に変更する処理を行う。
【００８６】
本実施例では、抽出した基本ポリシーに、サービスポリシー項目を規定している部分はない為、この変更の処理は行われない。なお、本実施例で、ステップＳ５００１の処理が完了したときにポリシー記憶部１０６に記憶されている制御ポリシー情報を図１４に示す。
【００８７】
ここで、制御ポリシー情報について補足する。
【００８８】
制御ポリシー情報は、基本的にｉｆ・・・ｔｈｅｎ・・・の形式で定義され、ｉｆとｔｈｅｎの間の条件に合致した場合、ｔｈｅｎ以下の処理を行う事をポリシー情報として定義している。
【００８９】
また、ｉｆとｔｈｅｎの間の条件ａｎｄ（かつ）／ｏｒ（または）を演算子として、複数の条件を設定する事が可能である。
【００９０】
よって、図１４に示される制御ポリシー情報の「ｉｆ」以下の項目では、
「もし、分析部１１３の分析結果、平均レスポンスが１０００ｍｓ以下で、かつ、稼動中のＩＴリソース数が２以上であれば、稼動ＩＴリソース数を１にする。」という制御ポリシーが示されている。
【００９１】
次に、ポリシーコンパイラ１０５は、ポリシー記憶部１０６に記憶しているサービスポリシー情報の「平均レスポンス時間」項目に値が規定されているかを確認し（Ｓ５００２）、規定されていれば、運用データベース１０７を参照し、過去の事例からデータ無し時の応答時間を抽出し、抽出した応答時間の平均時間を算出し（Ｓ５００３）、現在記憶している制御時ポリシー情報に示される「平均レスポンス時間」の値を更新する（Ｓ５００４）。なお、ステップＳ５００２の処理で、ポリシーコンパイラ１０５は、ポリシー記憶部１０６に記憶しているサービスポリシー情報の「平均レスポンス時間」項目に値が規定されていない場合には、ポリシーコンパイラ１０５は、ステップＳ５００３，ステップＳ５００４に示される処理は行わない。
【００９２】
本実施例の場合、上記してきた様にポリシー記憶部１０６に記憶されているサービスポリシー情報は、図６のとおりであり、このサービスポリシー情報では、「平均レスポンス時間」項目の規定は「１３００ｍｓ」成されているので、Ｓ５００３，Ｓ５００４の処理を実行する。本実施例では、ステップＳ５００３の処理において、「応答時間」の平均値は「３００ｍｓ」だったとする。よって、プＳ５００４の処理において、ポリシー記憶部１０６に記憶されている制御ポリシー情報は、ステップＳ５００４の処理完了時点において、図１５に示すように平均レスポンスの値が「１０００ｍｓ」を「３００ｍｓ」に更新されている。
【００９３】
このステップＳ５００４の処理が完了すると、ポリシーコンパイラ１０５は、ポリシー記憶部１０６に記憶しているサービスポリシー情報の「ピークレスポンス時間」項目に値が規定されているかを確認し（Ｓ５００５）、規定されていれば、運用データベース１０７を参照し、過去の事例でデータ無し時の応答時間に最大にかかったレスポンス時間を抽出し（Ｓ５００６）、現在記憶している制御時ポリシー情報に示される「ピークレスポンス時間」の値を条件に追加する（Ｓ５００７）。なお、ステップＳ５００５の処理で、ポリシーコンパイラ１０５は、ポリシー記憶部１０６に記憶しているサービスポリシー情報の「ピークレスポンス時間」項目に値が規定されていない場合には、ポリシーコンパイラ１０５は、ステップＳ５００６，ステップＳ５００７に示される処理は行わない。
【００９４】
本実施例の場合、上記してきた様にポリシー記憶部１０６に記憶されているサービスポリシー情報は、図６のとおりであり、このサービスポリシー情報では、「ピークレスポンス時間」項目の規定は「規定無し」であるので、Ｓ５００５，Ｓ５００６の処理は実行されない。本実施例の、この処理の完了時点でポリシー記憶部１０６に記憶されている制御ポリシー情報の更新は無い。
【００９５】
本実施例において、図１０のステップＳ３００２の処理が完了した時点でポリシー記憶部１０６に記憶されている制御ポリシー情報を図１６に示す。本実施の形態では、Ｓ５００６，Ｓ５００７の処理は行わなかったので、図１６に示す制御ポリシー情報は、図１５に示すステップＳ５００４の処理完了時の制御ポリシー情報と同じ制御ポリシー情報である。
【００９６】
このｉｆ以下がＩＴリソース減少処理（Ｓ３００２）により追加された制御ポリシー情報である。「分析部の分析の結果、平均レスポンス時間が３００ｍｓ以下」で、かつ、「ＩＴリソース数」が「２」以上であれば、「ＩＴリソース数」を「１」にする。というポリシーであることを示している。
【００９７】
なお、上記しＩＴリソース数減少設定処理では、サービスポリシー情報における、「平均レスポンス時間」・「ピークレスポンス時間」の各項目で、その値が規定されているか否かは判定しているもののその項目の値は反映されていない。これは、平均レスポンス時間・ピークレスポンスのポリシーは、これ以上レスポンスが「遅く」ならないようにという設定値であり、データが無い場合のレスポンス値ではない。このためこのレスポンス値を利用するわけにはいかないので、運用データベース１０７に記憶されている事例を基に各レスポンスの値の設定を行うようにしている。
【００９８】
ただし、どこを「観点」としてポリシーを設定していくかという事が問題であるので、その判断を行う条件として「平均レスポンス時間」「ピークレスポンス時間」の項目の規定の有無を参照している。今回の場合、平均レスポンス時間のみ規定があるので、上位（ビジネスもしくはサービス）ポリシー情報では、平均レスポンス時間のみ条件として設定している。
【００９９】
このＩＴリソース数減少設定処理（ステップＳ３００２）が完了すると、次に、ＩＴリソース数増設処理（ステップＳ３００３）が行われる。
【０１００】
この、ＩＴリソース数増設処理（ステップＳ３００３）について、図１７を用い説明する。
【０１０１】
まず、ポリシーコンパイラ１０６は、ポリシー記憶部１０６より、ＩＴリソース増加時の基本ポリシー情報を抽出し、同じくポリシー記憶部１０６に記憶されている制御ポリシー情報にこの基本ポリシー情報を追加する（Ｓ６００１）。この際、ポリシーコンパイラ１０５は、基本ポリシーに、サービスポリシー情報の項目が規定されていれば、その項目部分を、ポリシー記憶部１０６に記憶されているサービスポリシー情報の対応項目で規定されている値に変更する処理を行う。
【０１０２】
このＳ６００１の処理完了時点でポリシー記憶部１０６に記憶されている情報を図１８に示す。Ｓ６００１の処理により、２つ目の「ｉｆ」以降が追加され、かつ、基本ポリシー情報では、「サービスポリシー／ＩＴリソース最大確保数」と規定されていた部分に、サービスポリシー情報で規定された「１０台」に更新されている事がわかる。
【０１０３】
次に、ポリシーコンパイラ１０５は、ポリシー記憶部１０６に記憶しているサービスポリシー情報の「平均レスポンス時間」項目に値が規定されているかを確認し（Ｓ６００２）、規定されていれば、その「平均レスポンス時間」項目で規定されているレスポンス時間を制御ポリシー情報の条件に追加する。この際、当初条件である「分析部／分析結果／ＩＴリソース／メモリ使用率  <=  ９０％」とあるが、平均レスポンス・メモリ使用率の
どちらかの条件を達成すればＩＴリソース増加の条件となりうるため、ポリシーコンパイラ１０５は、ポリシー記憶部１０６に記憶されている制御ポリシー情報に条件を追加するとともに既にある条件との間に「ｏｒ（または）」の演算子を追加する（Ｓ６００３）。
【０１０４】
本実施例の場合は、サービスポリシー情報での「平均レスポンス時間」項目は「１３００ｍｓ」と規定されているので、分析部１１３の分析結果がこの「１３００ｍｓ」以上と成った場合をＩＴリソース追加の条件として追加する。その追加された制御ポリシー情報を図１９に示す。この図１９のアンダーライン部分が追加された制御ポリシー情報である。
【０１０５】
このステップＳ６００３の処理が完了すると、ポリシーコンパイラ１０５は、ポリシー記憶部１０６に記憶しているサービスポリシー情報の「ピークレスポンス時間」項目に値が規定されているかを確認し（Ｓ６００４）、規定されていれば、その「ピークレスポンス時間」項目で規定されているレスポンス時間を制御ポリシー情報の条件に追加する（Ｓ６００５）。この際の追加処理も、Ｓ６００３の処理と同様の処理を行う。
【０１０６】
ただし、本実施例の場合、「ピークレスポンス時間」項目は「規定無し」であるため、処理は行われない。
【０１０７】
よって、このＩＴリソース数増加処理（Ｓ３００３）処理完了時にポリシー記憶部１０６に記憶されている制御ポリシー情報は図２０に示されるようにＳ６００３処理完了時の状態のままである。
【０１０８】
また、上記してきた様に図２０の２つ目の「ｉｆ」以下が、ＩＴリソース数増加処理（Ｓ３００３）で追加された制御ポリシー情報であり、「分析部の分析の結果、平均レスポンスが１３００ｍｓ以上」もしくは「分析部の分析の結果、ＩＴリソースが使用するメモリの使用率が９０％以上」の何れかの条件時で、かつ、「ＩＴリソース数が１０台未満」であれば、「ＩＴリソース数を１台増加する」という制御ポリシー情報が追加されていることがわかる。
【０１０９】
このようにして図１７で示される処理が完了すると、図１０で示される制御ポリシー生成処理、即ち、図９で示されるステップＳ２００４の処理が完了した事になるので、ポリシーコンパイラ１０５は、図９にステップＳ２００５に示される様に。ポリシー記憶部１０６に示される制御ポリシー情報、即ち、図２０に示される制御ポリシー情報をフロー制御部１０９へ、送信する。
【０１１０】
この情報を受けたフロー制御部１０９の制御部１１０は、ポリシー記憶部１１１にこの制御ポリシーを記憶するとともに、この記憶した制御ポリシー１１１に基づき、監視・計測部１１２、分析部１１３、設計・検証部１１４、操作部１１５の制御を行う。この制御自体は、先願である［先行技術文献１］に示したものと同様の処理であり、その詳細の説明は省略する。
【０１１１】
以上のように、本実施例によれば、利用者がビジネス要件であるビジネスポリシー情報を、構成要件の規定であるサービスポリシー情報を仲介する事により、実際にＩＴリソースの制御を行うべき、制御ポリシー情報に変換する事が可能となる。
【０１１２】
なお、本実施例において、ビジネスポリシー入力部１０１に「ビジネスポリシー情報」を「性能重視・最悪条件でもレスポンス保証」が入力された場合に、サービス構造分析部１０２から出力されるサービスポリシー情報を図２１に、ポリシーコンパイラ１０５から出力される制御ポリシー情報を図２２に示す。なお、処理自体は上記したものと同じであるので、その説明は省略する。
【０１１３】
上記のようにして制御ポリシー情報が生成された状態で、レスポンスに対する実際のＩＴリソースの増減状態について図２３，図２４を使用し、説明する。
【０１１４】
まず図２３は、上記実施例において、利用者がビジネスポリシー入力部１０１において、「経済性重視・平均レスポンス保持」のビジネスポリシーを入力した場合のＩＴリソースの増減を説明するグラフ図である。
【０１１５】
この図において、上のグラフは、監視・計測部１１２からの情報を基に分析部１１３が出力した、平均レスポンス時間、ピークレスポンス時間の時間経過推移グラフである。
【０１１６】
なお、このグラフにおいて、実線は平均レスポンス時間、破線はピークレスポンス時間を示す。
【０１１７】
また、下のグラフ図は、稼動ＩＴリソースの増減を示す図である。
【０１１８】
利用者がビジネスポリシー入力部１０１において、「経済性重視・平均レスポンス保持」を入力した場合の制御ポリシー情報は、上記してきた様に図２０に示される制御ポリシーであり、その制御ポリシーに従い、フロー制御部１０９が、各ＩＴリソースの制御を行っている。
【０１１９】
このビジネスポリシーの場合、制御ポリシーでは平均しか見ていないため、実際のピークレスポンス時間が、「性能重視・最悪状況でもレスポンス保証」のビジネスポリシーでは設定される「ピークレスポンス時間：１５００ｍｓ」を超えたとしても、平均レスポンス時間の閾値である１３００ｍｓを超えなければ、ＩＴリソースの増加はない（ａ点参照）。
【０１２０】
逆に平均レスポンス時間の閾値が１３００ｍｓを超えると、ｂ点に示すように、ＩＴリソースを1台追加する制御を行う。
【０１２１】
同じように、データなしと判断されるピークレスポンス時間は見ていないので、ｃ点でのＩＴリソース減少の制御は行われない。
【０１２２】
また、平均レスポンス時間がデータなしと判断する基準レスポンス時間である３００ｍｓを切るような場合（ｄ点参照）、それまで4台のＩＴリソースが稼動していたシステム
が、一挙に一台の稼動状態となる。
【０１２３】
このようにする事で、レスポンス時間より、稼動ＩＴリソースを少なくする制御が行われる、即ち、経済性重視の制御が行われている事がわかる。
【０１２４】
次に、図２４は、上記実施例において、利用者がビジネスポリシー入力部１０１において、「性能重視・最悪状況でもレスポンス保証」のビジネスポリシーを入力した場合のＩＴリソースの増減を説明するグラフ図である。
【０１２５】
この制御ポリシー情報は上記したように、図２２に示される制御ポリシー情報となる。
【０１２６】
この制御ポリシーでは、ピークレスポンス時間も１５００ｍｓに規定され、平均レスポンス時間の規定値１３００ｍｓもしくは、上記ピークレスポンス時間の何れかを超えれば、ＩＴリソースの増設処理が行われる。（ａ点〜ｄ点参照）
また、ＩＴリソース減少の判断もピークレスポンス時間・平均レスポンス時間いずれかが規定値（各々５００ｍｓ、３００ｍｓ）以下となれば、ＩＴリソースの減少を行う。ただし、前記した「経済性重視・平均レスポンス保持」のビジネスポリシー情報を入力した場合は、ＩＴリソースの減少は、一気に1台の稼動までとするが、ｅ点、ｆ点に示すように、このビジネスポリシー情報では、1台ずつ順次減らす制御を行っていることがわかる
。
【０１２７】
なお、本実施例においては、サービス構造分析部１０２では、ポリシー記憶部１０３に記憶されたビジネスポリシー−サービスポリシーの対応テーブルを参照し、サービスポリシー情報を出力するのみであったが、図２５に示すように、この対応テーブルに、各ビジネスポリシーにおける基本構成情報も対応付けてポリシー記憶部１０３に記憶しておき、ビジネスポリシー入力部１０１からの入力に応じて、フロー制御部１０９で使用する構成／性能情報記憶部の基本構成情報１２０を出力するようにしても良い。
【０１２８】
更に、上記実施例ではポリシー記憶部１０３に記憶されたビジネスポリシー−サービスポリシーの対応テーブルでサービスポリシー情報を出力していたが、ビジネス分析における、シミュレーション処理を行った上で、基本構成情報１２０を生成しても良い。
【０１２９】
更に、ポリシーコンパイラ１０５では、運用データベース１０７に蓄積されている事例情報を参照して処理を行っていたが、この事例情報に代え、検証部（シミュレータ）１３０を設け、シミュレータによる検証を行った情報を利用して制御ポリシー情報を生成しても良い。更に、基本的に運用データベース１０７の情報を用い、その事例に無い情報をポリシーコンパイラ１０５が利用した場合に、検証部１３０による検証を行うようにしても良い。
【０１３０】
更に、本実施例では、１つのポリシー運用のみ説明してきたが、１つのポリシーでシステム全体を制御するのではなく、１つのポリシーの制御する範囲を部分（サブシステム）にとどめ、サブシステムポリシーの組み合わせにより全体を制御するようにすることも可能である。このように、システム内で1つのポリシーの制御する範囲を限定することで、個々のポリシーの定義が行いやすく、かつ、見やすいものとなる。
【０１３１】
例えば、Ｗｅｂサービスでは、Ｗｅｂサーバ、アプリケーションサーバ、ＤＢサーバなどを階層的に接続し処理を行う事が一般的であるが、Ｗｅｂサーバの負荷を監視して分析を行う制御ポリシーと、アプリケーションサーバの障害を監視し、分析をおこなう制御ポリシーは、ほぼ独立しており、これを１つのポリシーで定義しようとした場合、そのポリシーは複雑なものとなってしまうため、このように独立どの他界制御ポリシー同士は、別個の制御ポリシーで実行される事が望まれる。
【０１３２】
これに対応するためには、同一システム内に別途のサブシステムが複数稼動することになるため、どのＩＴリソースがどのサブシステムの基に処理を行っているかの制御を行う必要がある。
【０１３３】
一番単純な方式として、システムにおいて、サブシステム単位で使用可能なＩＴリソースを予め決定しておき、そのＩＴリソースの利用を単一サブシステムに制限し、完全に独立させてしまう事が考えられる。
【０１３４】
しかしながらと、一方のサブシステムのＩＴリソースに余裕があるにもかかわらず、他方のサブシステムにはＩＴリソースの余裕が無いという事象が発生する事が考えられ、ＩＴリソースの有効活用ができない場合が発生する。
【０１３５】
このため、例えば待機中のＩＴリソースはサブシステム間で共有とし、ＩＴリソースの追加を必要とするサブシステムに共有待機ＩＴリソースを割り当てることで、ＩＴリソース活用の効率化を図る事が考えられる。
【０１３６】
しかしながら、個々のサブシステムが独立して待機中の共有ＩＴリソースの割り当てをできるようにした場合、サブシステム間で同一のＩＴリソースの確保を行う処理が成されてしまうという事象が発生してしまう。
【０１３７】
このため、この様な制御を行う際には、サブシステム間の連携が必要である。
【０１３８】
図２７は、この点に鑑みて成されたシステムの例である。
【０１３９】
本システムにおいては、各サブシステム１０９ａ〜ｃ（各サブシステムは図３におけるフロー制御部１０９に相当）、制御ポリシーに基づきフロー制御を行うもので、監視・設計部１１２ａ〜ｃ・分析部１１３ａ〜ｃは、それぞれ、図３における監視・設計部１１２、分析部１１３の構成とは変わらない。
【０１４０】
１１７ａ〜ｃは、夫々、分析部１１３ａ〜ｃの分析の結果、システムの再設計が必要かを判断する判断部１５０ａ〜ｃで、必要の無い場合は、監視・計測部へ処理を移行し、ある場合には、他のサブシステムの判断部との間で設計・検証のタイミングをそろえる「同期処理」を行う。
【０１４１】
また、１１４ａ〜ｃは、各々のサブシステムの設計・検証部であり、図３における設計検証部１１４との違いは、判定部１５０ａ〜ｃの同期処理による同期タイミングにて、設計・検証の処理を行うようにしている点である。
【０１４２】
１０９ｄは、各設計・検証部１１４ａ〜ｃにおいて、同一予備ＩＴリソースの取得など、連携に関する問題が発生する判断される場合に、個々のサブシステムへその通知を行い、上位システム１０９ｄにてＩＴリソース取得の調整を行う上位システム１０９ｄである。
【０１４３】
この上位システム１０９は、各サブシステムでの設計・問題の状態を監視・計測部１１２ｄで観測し、その結果を分析部１１３ｄにて分析し、設計・検証部１１４ｄにて設計・検証処理を行った後、その結果を操作部１１５ｄのいて各サブシステムの設計・検証部１１５ａ〜ｃの全て、もしくは、操作の必要のあるサブシステムの設計・検証部に対し、通知する。
【０１４４】
この通知を受けた、設計・検証部１１５ａ〜ｃは、この情報を基に再設計を行い、その結果を基にＩＴリソースの取得・開放処理を行う。
【０１４５】
なお、このシステムにおいて、各システムの同期は、各サブシステムが複数のパターンを記憶しておき、そのパターンを制御ポリシーで選択するようにしている。
【０１４６】
これは設計において共有資源獲得の競合を防ぎ、優先度の高いものから順に資源を獲得できるようにするためである。
【０１４７】
これらの同期処理・競合回避処理について具体的な例を説明する。
【０１４８】
本例では、サブシステム１０９ａの分析部１１３ａの分析の結果、ＩＴリソース追加処理が必要とした場合について説明する。
【０１４９】
まず、上記したように、各判断部１５０ａ〜ｃは夫々自サブシステム１０９ａ〜ｃ内の分析部１１３ａ〜ｃより、再設計を必要とする旨の出力を監視している。
【０１５０】
ここで、分析部１１３ａが、ＩＴリソース追加処理が必要との出力を行うと、それを受けた判断部１５０ａは、他サブシステムの判断部１５０ｂ、ｃに対し再設計が必要である事を示す再設計通知及び待機時間（例えば５分間）を通知する。また、判断部１５０ａは、この待機時間が経過時点で、設計・検証部１１４ａに対し、再設計を依頼する旨の通知を行う。
【０１５１】
また、再設計・待機時間の情報を受けた、他のサブシステムｂ、ｃの判断部１５０ｂ、ｃは、通知を受けた待機時間経過までに自サブシステム１０９ｂ、ｃ内の分析部１１３ｂ、ｃより、再設計要の出力があるかをチェックする。
【０１５２】
ここで、待機時間経過前にサブシステム１０９ｂの分析部１１３ｂより、再設計の必要要の出力があった場合、待機時間経過時点で設計・検証部に再設計の支持を出力する。
【０１５３】
この状態において、設計・検証部１１４ａ・１１４ｂが、同時に設計・検証部により、再設計を行っている。
【０１５４】
なお、判断部１５０ａ〜ｃは、上記経過時間後に到来した分析部１１３ａ〜ｃの処理については、上記設計・検証部１１４ａ、ｂの設計・検証処理が完了した時点で、設計・検証部１１４ａ〜ｃに、再設計に対する出力を行うようにする。
【０１５５】
この各サブシステムでの、設計・再設計部１１４ａ，ｂによる再設計情報は、上システム１０９ｄの監視・計測部１１２ｄへ送られる。
【０１５６】
上記したように、設計・再設計部１１４ａ，ｂは、同時に再設計の処理を行うため、ほぼ同じ程度のタイミングで、各々の設計・検証部１１４ａ．ｂの再設計情報が監視・計測部１１２ｄへ送られる。
【０１５７】
この情報を受けた監視・設計部１１２ｄが、その結果を分析部１１３ｄへ渡すと、互いのサブシステム内で、競合して取得しようとするＩＴリソースの有無・また、システム全体としてＩＴリソースが不足する設計になっていないかを分析し、設計・検証部１１４ｄへ渡す。
【０１５８】
この分析結果を受けた設計・検証部１１４ｄは、優先してＩＴリソースを取得すべきサブシステムの判断や、稼動中の他のサブシステムのＩＴリソースの開放及びその開放したＩＴリソースを、必要とするサブシステムへ追加する設計及び検証を行い、操作部へ出力する。
【０１５９】
この情報を受けた操作部１１５ｄは、この情報を基に各設計・検証部１１４ａ〜ｃに、設計・検証システムで再設計・検証された、各サブシステムの再設計情報を各サブシステムの設計・検証部１１４ａ〜ｃに通知する。
【０１６０】
この情報を受けた設計・検証部１１４ａ〜ｃは、この上位システム１０９ｄからの再設計情報を基に再設計・検証処理を行い、その結果を各サブシステム１１４ａ〜ｃの操作部１１５ａ〜ｃへ出力し、操作部１１５ａ〜ｃは、その出力に応じたＩＴリソース再編成処理を行う。
【０１６１】
なお、上記した例では、あるサブシステムの判断部からの再設計依頼から所定時間経過後に設計・検証処理という同期処理を行ったが、他の同期の取り方として他に、１つのサブシステムで異常が発生した場合に、他のサブシステム全てについて監視・計測の周期に関わりなくその時点での計測・分析を行わせ、必要な資源・処理を判断させるという事も可能である。
【０１６２】
このようにする事により、他のシステムに対して「監視は５分おきになっていて 1 分前に監視したばかりだが、現時点には閾値を越えている可能性がある」、あるいは「定められた閾値は越えていない場合でも、再設計の機会があるのならば少しだけ資源を増やして適正化する」等、積極的に確認する（待ち合わせではなく）制御を行う事が可能である。
【０１６３】
また、再設計を必要とするものについて優先順位を定めて順次実行するのは前記のパターンと同じである。
【０１６４】
また、この例の場合では、図２８に示すように各サブシステム間において、各競合制御ポリシーが各サブシステムがどのような同期パターンを取るかを記し、上位システムはサブサブシステムの同期パターンに合わせて同期を実行するポリシーが定義される。なお、この例における上位システム１０９ｄの制御ポリシーの定義例を示すもので、ＸＭＬ形式で明記している。また、図２８では、文面自体が入れ子になっているが、分けても良い。
さらに上記したシステムでは、設計・検証部１４ａ〜ｃからの出力を、上位システム１０９の監視・計測部１１２ｄが監視することにより、問題点を検出しているが、通常は設計・検証部１１４ａ〜ｃ同士で通信を行い、問題点があるかを検出し、問題点の発生を契機に上位システム１０９ｄの監視・計測部１１２ｄに通知するようにし、監視・計測部１１２ｄは、この通知を契機に分析部１１３ｄへ通知を行っても良い。
【０１６５】
以上のように上位システム１０９ｄにより、各サブシステムの連携を取る制御を行う事により、例えば上位のシステムでは他の（兄弟の）サブシステムにサーバを解放させたり、上位で用意されているサーバプールから取得したりという解決が可能となり、システムの更なるＩＴリソースの有効利用が可能となるシステムの自動構成を行う事が可能となる。
【０１６６】
なお、上記した同期のパターンは「既定のパターンから選ぶ」という形を取れば、フロー制御部の実装を容易にし、かつ、運用管理フローは定型的でありパターン化して列挙することが可能となる。また、この際、同期パターンを編集する機能を付加する手段を設ければ、容易にかつ、適切な同期パターンを定義する事ができる。
【０１６７】
また、上記例では、各フロー制御部１０９ａ〜ｃの設計・検証部１１４ａ〜ｃは、基本的に、独立・並行して設計を行っているが、設計・検証部１１４ａ→ｂ→ｃの順で設計する様にし、まず設計検証部１１４ａが共有リソースを自由に使用して設計し、設計・検証部１１４ｂは設計・検証部１１４ａが使わなかった共有リソースの範囲で設計し、更に設計検証部１１４ｃが設計・検証部１１４ａ、ｂが使わなかった共有リソースの範囲で設計する制御を行い、設計・検証部１１４ａ〜ｃのいずれかで設計に問題が出た時点で上位フロー制御部１０９ｄへ通知するようにしても良い。
【０１６８】
なお、上記してきた実施例では、ビジネスポリシーからサービスポリシーの生成、サービスポリシーから制御ポリシーへの変換時、サービス構造分析部やポリシーコンパイラの結果を直接、反映させていたが、この変換結果を管理者へ提示し、管理者からの修正が行える修正手段を加える事により、管理者の意図する変換ができたかの確認、できていない場合の修正を行う事が可能となる。
【０１６９】
更に、制御ポリシーにおいてサーバ台数増加のトリガとなるピーク／平均レスポンス時間はサービスポリシーからの引き写しとしているが、例えば、サービスポリシーでは「平均を２０００ｍｓ以下に抑えたい」と書いてある場合、実際には、平均が２０００ｍｓを超えてから対処したのでは遅いため、それを加味して制御ポリシーを定義するようにしても良い。
【０１７０】
例えば、サービスポリシーからの要求値に対し、経験則から得られた一定の係数（０．７等）を掛けるようにしておき、この値に変換する。
【０１７１】
もしくは、「１０００ｍｓを超えてから対処した場合」「１１００ｍｓを超えてから対処した場合」など、段階的に事前シミュレーションを行い、サービスポリシーを２０００ｍｓ以下を確保できる安全値のを選ぶ、というような変換を行う。
【０１７２】
これらの何れかの処理を行う事により、より確実なポリシー運用を行う事が可能となる。
【０１７３】
また、フロー制御部の構成要件である、監視・計測部１１２、分析部１１３、設計検証部１１４、操作部１１５を機能モジュール化するとともに、制御部１１６は、機能モジュール毎に定義した共通インターフェースを利用して、各機能モジュールを呼び出す構成としておき、更に、共通インターフェースの呼び出しを各機能モジュールが理解できる形式に変換するアダプタを設けることにより、使用用途に応じて容易に各機能モジュールを適用できるようになる。
【０１７４】
（付記１）
コンピュータを、
ビジネス要件を示すビジネスポリシー情報が入力された場合、その構成要件を示すサービスポリシー情報を生成するサービス構造分析部と、
前記サービスポリシー構造分析部によって生成されたサービスポリシー情報を、過去の事例もしくはシミュレーションによる検証の結果を基に、実際のＩＴリソースの制御要件である制御ポリシーを生成するポリシーコンパイラと、
前記ポリシーコンパイラで生成した制御ポリシーに応じてＩＴリソースの制御を行うフロー制御部と、
して機能させることを特長とする自律制御プログラム。
【０１７５】
（付記２）
前記サービス構造分析部が生成するサービスポリシー情報には、ＩＴリソースを減少する手順の項目を含む
事を特徴とする付記１記載の自律制御プログラム。
【０１７６】
（付記３）
前記ＩＴリソースを減少する項目には、稼動ＩＴリソースを1台とする制御指示を規定す
る事が可能である
事を特徴とする付記２記載の自律制御プログラム。
【０１７７】
（付記４）
前記ＩＴリソースを減少する項目には、稼動ＩＴリソースを1台ずつ減少する制御指示を
規定する事が可能である
事を特徴とする付記２または付記３記載の自律制御プログラム。
【０１７８】
（付記５）
前記サービス構造分析部が生成するサービスポリシー情報には、平均レスポンス時間及びピークレスポンス時間を規定する項目を含み、
前記ポリシーコンパイラは、前記サービス構造分析部が生成したサービスポリシー情報の平均レスポンス時間及びピークレスポンス時間の項目が規定されているか否かを参照しながら制御ポリシー情報を生成する
事を特徴とする付記１記載の自律制御プログラム。
【０１７９】
（付記６）
前記フロー制御部は、
各機能の機能モジュールを有するとともに、
機能モジュール毎に定義した共通インターフェースを利用して、各機能モジュールを呼び出す制御部と、
前記制御部からの共通インターフェースによる呼び出しを対象となる機能モジュールが理解できる形式に変換し、対象となる機能モジュールに提供するアダプタと
を有する事を特徴とする付記１から付記５の何れかに記載の自律制御プログラム。
【０１８０】
（付記７）
前記フロー制御部は、制御ポリシーにより、複数のフロー制御が可能であるとともに、
各フロー制御間でのＩＴリソース調整を行う上位フロー制御部を有する
事を特徴とする請求項１から請求項６の何れかに記載の自律制御プログラム。
【０１８１】
（付記８）
コンピュータが、
ビジネス要件を示すビジネスポリシー情報が入力された場合、その構成要件を示すサービスポリシー情報を生成するサービス構造分析ステップと、
前記サービスポリシー構造分析ステップによって生成されたサービスポリシー情報を、過去の事例もしくはシミュレーションによる検証の結果を基に、実際のＩＴリソースの制御要件である制御ポリシーを生成するポリシー生成ステップと、
前記ポリシー生成ステップで生成した制御ポリシーに応じてＩＴリソースの制御を行うフロー制御ステップと、
を実行することを特長とする自律制御方法。
【０１８２】
（付記９）
前記サービス構造分析ステップが生成するサービスポリシー情報には、ＩＴリソースを減少する手順の項目を含む
事を特徴とする付記８記載の自律制御方法。
【０１８３】
（付記１０）
前記サービス構造分析部が生成するサービスポリシー情報には、平均レスポンス時間及びピークレスポンス時間を規定する項目を含み、
前記ポリシーコンパイラは、前記サービス構造分析部が生成したサービスポリシー情報の平均レスポンス時間及びピークレスポンス時間の項目が規定されているか否かを参照しながら制御ポリシー情報を生成する
事を特徴とする付記８記載の自律制御方法。
【０１８４】
（付記１１）
前記フロー制御ステップでは、
機能モジュール毎に定義した共通インターフェースを利用して、各機能モジュールを呼び出すモジュール制御ステップと、
前記モジュール制御ステップからの共通インターフェースによる呼び出しを対象となる機能モジュールが理解できる形式に変換し、対象となる機能モジュールに提供するステップと
が実行される事を特徴とする付記８から付記１０のいずれかに記載の自律制御方法。
【０１８５】
（付記１１）
前記フロー制御ステップは、制御ポリシーにより、複数のフロー制御が可能であるとともに、
各フロー制御間でのＩＴリソース調整を行う上位フロー制御ステップを
実行する事を特徴とする付記８から付記１１の何れかに記載の自律制御方法。
【０１８６】
（付記１２）
ビジネス要件を示すビジネスポリシー情報が入力された場合、その構成要件を示すサービスポリシー情報を生成するサービス構造分析部と、
前記サービスポリシー構造分析部によって生成されたサービスポリシー情報を、過去の事例もしくはシミュレーションによる検証の結果を基に、実際のＩＴリソースの制御要件である制御ポリシーを生成するポリシーコンパイラと、
前記ポリシーコンパイラで生成した制御ポリシーに応じてＩＴリソースの制御を行うフロー制御部と、
して機能させることを特長とする自律制御装置。
【０１８７】
（付記１３）
前記サービス構造分析部が生成するサービスポリシー情報には、ＩＴリソースを減少する手順の項目を含む
事を特徴とする付記１２記載の自律制御装置。
【０１８８】
（付記１４）
前記サービス構造分析部が生成するサービスポリシー情報には、平均レスポンス時間及びピークレスポンス時間を規定する項目を含み、
前記ポリシーコンパイラは、前記サービス構造分析部が生成したサービスポリシー情報の平均レスポンス時間及びピークレスポンス時間の項目が規定されているか否かを参照しながら制御ポリシー情報を生成する
事を特徴とする付記１２または付記１３のいずれかに記載の自律制御装置。
【０１８９】
（付記１５）
前記フロー制御部は、
各機能の機能モジュールを有するとともに、
機能モジュール毎に定義した共通インターフェースを利用して、各機能モジュールを呼び出す制御部と、
前記制御部からの共通インターフェースによる呼び出しを対象となる機能モジュールが理解できる形式に変換し、対象となる機能モジュールに提供するアダプタと
を有する事を特徴とする付記１２から付記１４の何れかに記載の自律制御装置。
【０１９０】
（付記１６）
前記フロー制御部は、制御ポリシーにより、複数のフロー制御が可能であるとともに、
各フロー制御間でのＩＴリソース調整を行う上位フロー制御部を有する
事を特徴とする請求項１２から請求項１５の何れかに記載の自律制御装置。
【図面の簡単な説明】
【０１９１】
【図１】本発明の実施例における自律制御システムの構成図
【図２】本発明の実施例における自律制御システムで、管理サーバ１７が、各ＩＴリ    ソースに役割を与えた場合の例を示した図
【図３】本発明の実施例の自律制御システムにおける、管理サーバ１７の構成図。
【図４】サービス構造分析部１０２の処理を示すフローチャート
【図５】ポリシー記憶部１０３に記憶されているビジネスポリシーとサービスポリシ    ーとの対応情報を示すテーブル図
【図６】サービスポリシー情報１０４の例を示した図
【図７】ポリシー記憶部１０６に記憶されているＩＴリソース数減少基本ポリシー情    報を示すテーブル図
【図８】ポリシー記憶部１０６に記憶されているＩＴリソース数増加基本ポリシー情    報を示すテーブル図
【図９】ポリシーコンパイラ１０５の処理手順を示したフローチャート
【図１０】ポリシーコンパイラ１０５の処理手順を示したフローチャート
【図１１】ポリシーコンパイラ１０５の処理手順を示したフローチャート
【図１２】制御ポリシーの例を示した図
【図１３】ポリシーコンパイラ１０５の処理手順を示したフローチャート
【図１４】制御ポリシーの例を示した図
【図１５】制御ポリシーの例を示した図
【図１６】制御ポリシーの例を示した図
【図１７】ポリシーコンパイラ１０５の処理手順を示したフローチャート
【図１８】制御ポリシーの例を示した図
【図１９】制御ポリシーの例を示した図
【図２０】制御ポリシーの例を示した図
【図２１】サービスポリシー情報１０４の例を示した図
【図２２】制御ポリシーの例を示した図
【図２３】本発明の実施例において、ビジネスポリシーに基づく自律制御を行った際    のシステムのレスポンスと稼動ＩＴリソース数との時間推移を示したグラフ図
【図２４】本発明の実施例において、ビジネスポリシーに基づく自律制御を行った際    のシステムのレスポンスと稼動ＩＴリソース数との時間推移を示したグラフ図
【図２５】本発明の他の実施例の自律制御システムにおける、管理サーバ１７の構成    図。
【図２６】本発明の他の実施例の自律制御システムにおける、管理サーバ１７の構成    図。
【図２７】本発明のポリシー運用を同一システムで２以上行得るように構成したフロ    ー制御部１０９の構成例を示した図。
【図２８】制御ポリシーの例を示した図
【図１】
2007047845.tif 000003
【図２】
2007047845.tif 000004
【図３】
2007047845.tif 000005
【図４】
2007047845.tif 000006
【図５】
2007047845.tif 000007
【図６】
2007047845.tif 000008
【図７】
2007047845.tif 000009
【図８】
2007047845.tif 000010
【図９】
2007047845.tif 000011
【図１０】
2007047845.tif 000012
【図１１】
2007047845.tif 000013
【図１２】
2007047845.tif 000014
【図１３】
2007047845.tif 000015
【図１４】
2007047845.tif 000016
【図１５】
2007047845.tif 000017
【図１６】
2007047845.tif 000018
【図１７】
2007047845.tif 000019
【図１８】
2007047845.tif 000020
【図１９】
2007047845.tif 000021
【図２０】
2007047845.tif 000022
【図２１】
2007047845.tif 000023
【図２２】
2007047845.tif 000024
【図２３】
2007047845.tif 000025
【図２４】
2007047845.tif 000026
【図２５】
2007047845.tif 000027
【図２６】
2007047845.tif 000028
【図２７】
2007047845.tif 000029
【図２８】
2007047845.tif 000030