システムへのリクエストの変化予測情報リクエストモデルを入力し、前記リクエストモデルの期間ごとの条件を満たす前記システムの構成拡張ポイントを所定の規則に基づき変更するプランニング手段と、前記拡張ポイントの変更に要するコスト拡張コストを計算して出力する拡張コスト算出手段と、前記プランニング手段によって前記拡張ポイントが変更された場合のシステムの性能を表す値性能値を計算して出力する性能算出手段と、を備える拡張性評価装置。前記システムに対するリクエストの第2の条件と前記リクエストモデル内の1つの期間とを入力し、前記リクエストモデルの前記入力された期間における条件を前記第2の条件に置き換えた合成モデルを出力する想定トラフィック合成手段と、前記合成モデルによって定まるリクエストモデルの期間ごとの条件を満たす前記拡張ポイントを変更する前記プランニング手段と、を備える請求項1に記載の拡張性評価装置。前記第2の条件と対応付けられたリクエストモデルのトラフィックの種類と、そのトラフィックの種類に対してシステムが対応するまでの上限時間対応時間と、を対応付けて記憶する状況別対策レベル格納手段と、拡張ポイントと、拡張ポイントの変更に要する時間即応レベルと、を対応付けて記憶する運用サービスレベル格納手段と、前記トラフィックの種類に基づいて、前記対応時間と前記即応レベルとを参照し、前記対応時間以内で変更できる構成の変更箇所を前記拡張ポイントの候補として前記運用サービスレベル格納手段から抽出する拡張可能箇所判定手段と、をさらに備える請求項2に記載の拡張性評価装置。前記トラフィックの種類と前記リクエストモデルの条件の変化量とを対応付けて記憶するリクエストモデル変動知識格納手段と、前記リクエストモデル変動知識格納手段を参照して、前記入力されたリクエストモデルの条件の変化量から、トラフィックの種類を判定するリクエストモデル変動判定手段と、をさらに備え、前記拡張可能箇所判定手段は、判定された前記リクエストモデルのトラフィックの種類に基づいて、前記対応時間と前記即応レベルとを参照し、前記対応時間以内で変更できる変更箇所を拡張ポイントの候補として前記運用サービスレベル格納手段から抽出する請求項3記載の拡張性評価装置。システムへのリクエストの変化予測情報リクエストモデルを入力し、前記リクエストモデルの期間ごとの条件を満たす前記システムの構成拡張ポイントを所定の規則に基づき変更するプランニングステップと、前記拡張ポイントの変更に要するコスト拡張コストを計算して出力する拡張コスト算出ステップと、前記拡張ポイントが変更された場合のシステムの性能を表す値性能値を計算して出力する性能算出ステップと、をコンピュータに実行させる拡張性評価プログラム。前記システムに対するリクエストの第2の条件と前記リクエストモデル内の1つの期間とを入力し、前記リクエストモデルの前記入力された期間における条件を前記第2の条件に置き換えた合成モデルを出力する想定トラフィック合成ステップと、前記合成モデルによって定まるリクエストモデルの期間ごとの条件を満たす前記拡張ポイントを変更する前記プランニングステップと、をコンピュータに実行させる請求項5に記載の拡張性評価プログラム。前記状況別リクエストモデルのトラフィックの種類とそのトラフィックの種類に対してシステムが対応するまでの上限時間対応時間とを対応付けて記憶する状況別対策レベル格納手段と、拡張ポイントと拡張ポイントの変更に要する時間即応レベルとを対応付けて記憶する運用サービスレベル格納手段と、から、前記第2の条件と対応付けられたリクエストモデルのトラフィックの種類に基づいて前記対応時間と前記即応レベルとを参照し、前記対応時間以内で変更できる構成の変更箇所を前記拡張ポイントの候補として前記運用サービスレベル格納手段から抽出する拡張可能箇所判定ステップを、さらにコンピュータに実行させる請求項6に記載の拡張性評価プログラム。前記トラフィックの種類と前記リクエストモデルの条件の変化量とを対応付けて記憶するリクエストモデル変動知識格納手段を参照して、前記入力されたリクエストモデルの条件の変化量から、トラフィックの種類を判定するリクエストモデル変動判定ステップと、判定された前記リクエストモデルのトラフィックの種類に基づいて、前記対応時間と前記即応レベルとを参照し、前記対応時間以内で変更できる変更箇所を拡張ポイントの候補として前記運用サービスレベル格納手段から抽出する前記拡張可能箇所判定ステップと、をコンピュータに実行させる請求項7記載の拡張性評価プログラム。システムへのリクエストの変化予測情報リクエストモデルを入力し、前記リクエストモデルの期間ごとの条件を満たす前記システムの構成拡張ポイントを所定の規則に基づき変更し、前記拡張ポイントの変更に要するコスト拡張コストを計算して出力し、前記拡張ポイントが変更された場合のシステムの性能を表す値性能値を計算して出力する拡張性評価方法。前記システムに対するリクエストの第2の条件と前記リクエストモデル内の1つの期間とを入力し、前記リクエストモデルの前記入力された期間における条件を前記第2の条件に置き換えた合成モデルを出力し、前記合成モデルによって定まるリクエストモデルの期間ごとの条件を満たす前記拡張ポイントを変更する請求項9に記載の拡張性評価方法。しかし、上述した技術においては、システムへのリクエストの変動に基づいて、システムの拡張性を評価できないという問題点があった。このため、本発明の目的は、上述の課題を解決する、システムへのリクエストの変動に基づいてシステムの拡張性を評価できる拡張性評価装置、拡張性評価方法および拡張性評価プログラムを提供することである。かかる目的を達成するため、本発明の一形態は、拡張性評価装置であって、システムへのリクエストの変化予測情報リクエストモデルを入力し、前記リクエストモデルの期間ごとの条件を満たす前記システムの構成拡張ポイントを所定の規則に基づき変更するプランニング手段と、前記拡張ポイントの変更に要するコスト拡張コストを計算して出力する拡張コスト算出手段と、前記プランニング手段によって前記拡張ポイントが変更された場合のシステムの性能を表す値性能値を計算して出力する性能算出手段と、を備える。また、本発明によれば、システムへのリクエストの変化予測情報リクエストモデルを入力し、前記リクエストモデルの期間ごとの条件を満たす前記システムの構成拡張ポイントを所定の規則に基づき変更するプランニングステップと、前記拡張ポイントの変更に要するコスト拡張コストを計算して出力する拡張コスト算出ステップと、前記プランニング手段によって前記拡張ポイントが変更された場合のシステムの性能を表す値性能値を計算して出力する性能算出ステップと、をコンピュータに実行させる拡張性評価プログラムが提供される。また、本発明によれば、システムへのリクエストの変化予測情報リクエストモデルを入力し、前記リクエストモデルの期間ごとの条件を満たす前記システムの構成拡張ポイントを所定の規則に基づき変更し、前記拡張ポイントの変更に要するコスト拡張コストを計算して出力し、前記拡張ポイントが変更された場合のシステムの性能を表す値性能値を計算して出力する拡張性評価方法が提供される。本発明は、システムへのリクエストの変動に基づいてシステムの拡張性を評価できる拡張性評価装置、拡張性評価方法および拡張性評価用プログラムを提供する。以下、本発明の実施の形態について、図面を用いて説明する。すべての図面において、同様な構成要素には同様の符号を付し、適宜説明を省略する。なお、各実施形態の拡張性評価装置100を構成する各部は、制御部、メモリ、メモリにロードされたプログラム、プログラムを格納するハードディスク等の記憶ユニット、ネットワーク接続用インターフェースなどからなり、ハードウェアとソフトウェアの任意の組合せによって実現される。そして特に断りのない限り、その実現方法、装置は限定されない。また、制御部はCPUCentralProcessingUnitなどからなり、オペレーティングシステムを動作させて拡張性評価装置100の全体を制御するとともに、例えばドライブ装置などに装着された記録媒体からメモリにプログラムやデータを読み出し、これに従って各種の処理を実行する。記録媒体は、例えば光ディスク、フレキシブルディスク、磁気光ディスク、外付けハードディスク、半導体メモリ等であって、コンピュータプログラムをコンピュータが読み取り可能に記録する。また、コンピュータプログラムは、通信網に接続されている図示しない外部コンピュータからダウンロードされても良い。なお、特に断りの無い限り、通信網とは、インターネット、LANLocalAreaNetwork、公衆回線網、無線通信網、または、これらの組み合わせ等によって構成されるネットワーク等であって良い。また、各実施形態の説明において利用するブロック図は、ハードウェア単位の構成ではなく、機能単位の構成を示している。これらの機能ブロックはハードウェア、ソフトウェアの任意の組み合わせによって実現される。また、これらの図においては、各実施形態の構成部は物理的に結合した一つの装置により実現されるよう記載されている場合もあるが、その実現手段はこれに限定されない。すなわち、二つ以上の物理的に分離した装置を有線または無線で接続し、これら複数の装置により、各実施形態の各構成部、装置、システムを実現してもよい。また、各構成部が物理的に分離した2つ以上装置として記載されている場合もあるが、その実現手段はこれに限定されない。すなわち、物理的に結合した一つの装置によりそれらが実現されるようにハードウェア、ソフトウェアを任意に組み合わせて各実施形態の各構成部、装置、システムを実現してもよい。<実施形態1>次に、発明を実施するための第1の実施の形態について図1を参照して詳細に説明する。図1を参照すると、本発明の第1の実施の形態における拡張性評価装置100は、モデル格納部1と、リクエストモデル入力部2と、プランニング部3と、性能算出部4と、構成変更コスト格納部5と、拡張コスト算出部6と、コスト/性能データ格納部7と、拡張性評価値算出部8と、拡張性評価値格納部9とを含む。これらの各部について説明する。モデル格納部1は、システムの構成とその動作についてモデル化した、モデル情報を格納する。ここで、モデル情報とは、例えば、図8に記載のようなサーバの構成やそこに含まれるアプリケーションの情報、それらの拡張可能な構成や拡張可能な範囲、各サーバのリソース消費量CPUCentralProcessingUnit使用率などなど、シミュレーションに必要な情報であり、例えばUMLUnifiedModelingLanguageなどの標準的なモデル記述言語で記述されたものである。リクエストモデル入力部2は、システムの利用状況の変化を記載したリクエストモデルを入力する。ここで、システムの利用状況とは、システムに対するリクエストやトラフィックの状況などである。また、リクエストモデルとは、例えば図9に示したように、リクエストの想定到着率、データ量、データの書き込み/読み込み比率、リクエストモデルの条件のうちの一つ以上を用いてシステムの利用状況の時間変化を表したものである。図9は、リクエストモデルが、Case1、Case2、Case3リクエストモデルの期間の時間順で変化することを示しており、それぞれの場合のリクエストの想定到着率、リクエストに含まれるデータ量、データの書き込み/読み込み比率が与えられている。プランニング部3は、入力されたリクエストを満たすようにモデルを拡張する箇所を求める。具体的には、プランニング部3は、モデル格納部1に格納されたモデルが、リクエストモデル入力部2で入力されたそれぞれのリクエストモデルで要求される時間変化に対応できるように、モデルに含まれる可変の構成箇所拡張ポイントを決定し、その拡張内容を性能算出部4へ出力する。プランニング部3は、例えば、システムの利用状況の時間変化をリクエストモデルから取得し、その時間変化にシステムが対応するために要する構成の変更箇所CPU数、DBDatabase、以下同様数、VMVirtualMachine、以下同様台数などを、リクエストにより変化する負荷と各構成の処理能力等から計算して求める。プランニング部3は、例えば、リクエストにより変化するシステムへの負荷、あるいは、リクエストモデルの想定到着率、データ量、データの書き込み/読み込み比率などの条件を成分とするベクトル想定到着率、データ量、データの書き込み/読み込み比率を入力として、システムを構成する構成部品の数であるCPU数、DB数、VM数などを成分とするベクトルCPU数、DB数、VM数を出力する所定の関数すなわち、f想定到着率、データ量、データの書き込み/読み込み比率=CPU数、DB数、VM数となる所定の関数fを用いてリクエストモデルの変化条件に適うシステム構成箇所を決定しても良い。この関数は経験則に従ってユーザが適宜設定できる。あるいは、プランニング部3は、システムの利用状況、リクエストの変化とそれに対応できるシステムの構成とを関連づけて記憶する記憶部を参照して、リクエストモデルの変化条件に適うシステム構成箇所を決定しても良い。このような記憶部が記憶するテーブルの例を図19に示す。例えば、図19のテーブルの一行目は、リクエストモデルのCase期間の変化によって変わる想定到着率の変化率がa1~a2であり、データ量の変化率がb1~b2であり、データ書き込み/読み込み比率の変化率がc1~c2であるときに、変更が必要なCPUの台数が1台、VMの台数が1台、DBの台数が0台すなわちDBの台数は変更が不要であることを示している。変化率を表すa1、a2、b1、b2、c1、c2などの数は経験則にしたがってユーザが適宜設定できる。性能算出部4は、機器を拡張変更したときの性能を評価する。具体的には、性能算出部4は、プランニング部3が出力した構成の拡張内容をモデルに当てはめて、構成が変更されたシステムのCPU数、DB数、VM数などから得られるシステムの性能計算可能量、計算速度等の処理能力を数値化した値、性能値、例えば毎秒処理可能なリクエスト数などを計算する。性能算出部4は、例えば、システムを構成する部品の数を成分とするベクトルCPU数、DB数、VM数を入力として、システムの性能値を出力する所定の関数すなわち、gCPU数、DB数、VM数=システム性能値、となる所定の関数gを用いてシステムの性能を求めても良い。この関数は経験則に従ってユーザが適宜設定できる。あるいは、性能算出部4は、システムの構成とシステムの性能とを対応付けて記憶する図示しない記憶部を参照して、システムの性能を求めても良い。構成変更コスト格納部5は、機器を構成拡張する際に必要なコストを格納する。具体的には、構成変更コスト格納部5は、機器を拡張する際に変更する部品と、初期コストリクエストモデルの各Case期間における条件をみたす構成を最初から構築するために必要なコストと、拡張する際に部品変更に要するコストとを対応付けて記憶する。構成変更コスト格納部5が格納するデータの例を図7に示す。拡張コスト算出部6は、構成変更コスト格納部5に格納されたコストをもとに、拡張ポイントを拡張するために必要なコスト拡張コストの算出を行なう。具体的には、拡張コスト算出部6は、拡張ポイントの構成ごとに構成変更に要するコストを構成変更コスト格納部5から抽出して拡張ポイントを拡張するために必要なコストを算出する。コスト/性能データ格納部7は、算出されたコストと性能とを格納する。具体的には、コスト/性能データ格納部7は、プランニング部3によって算出された拡張ポイントと、性能算出部4が算出した性能と、拡張コスト算出部6が算出した拡張コストとを格納する。コスト/性能データ格納部7に格納されているデータの例を図10に示す。図10の拡張ポイント列は、Case1ではCPUとVMがそれぞれ1つずつの構成であることを示している。また、Case2は、Case1からみてVMが1、すなわちVMを1台増やす必要があることを示している。また、Case3は、Case1からみてCPUが2、VMが1であり、CPUを2台、VMを1台増やす必要があることを示している。拡張性評価値算出部8は、コスト/性能データ格納部7に格納されたデータからリクエストデータ毎に拡張性評価値を算出する。具体的には、拡張性評価値算出部8は、コスト/性能データ格納部7に格納されたシステムの性能や拡張コストを用いて、リクエストモデルに含まれるリクエスト毎に拡張性評価値を算出する。例えば、拡張性評価値算出部8は、拡張性評価値を、拡張性評価値=向上した性能/コストによって算出してもよい。なお、拡張性評価値は、向上したシステム性能値が大きく、必要なコストが小さいほど大きくなるような評価値、あるいは、向上したシステムの性能値が小さく、必要なコストが大きいほど小さくなるような評価値であってもよく、特に限定されない。拡張性評価値格納部9は、拡張性評価値算出部8が算出した各構成の変更パターンごとの拡張性評価値を格納する。拡張性評価値格納部9が格納する拡張性評価値の例を図11に示す。次に、図2のフローチャートを参照して本実施の形態の全体の動作の一例について詳細に説明する。まず、リクエストモデル入力部2は、リクエストモデルを入力する図2のステップS1。次に、プランニング部3は、入力されたリクエストモデルをモデル格納部1に格納されているモデルに当てはめ、入力されたリクエストを処理可能なシステム構成から拡張ポイントを決定する図2のステップS2。さらに、性能算出部4は、その拡張ポイントをモデルに当てはめてシステムの性能を計算する図2のステップS3。さらに、拡張コスト算出部6は、構成変更コスト格納部5が格納する構成変更コストデータを用いて、拡張されたシステムを生成するために必要なコストを計算する図2のステップS4。拡張性評価装置100は、入力されたすべてのリクエストモデルでプランニング部3がプランニングを行なっていない場合には、ステップS2からS4までのステップを繰り返す図2のステップS5。プランニング部3が、入力されたすべてのリクエストモデルでプランニングを行った場合には、算出したコストとシステムの性能とに基づいて、拡張性評価値算出部8が拡張性評価値を算出する図2のステップS6。次に、本実施の形態の効果について説明する。本実施の形態における拡張性評価装置100は、入力されたリクエストモデルに合わせて、システムの拡張ポイントを求めて拡張性を評価する。したがって、本実施の形態における拡張性評価装置100は、予め拡張ポイントを指定しておくことなく、システムへのリクエストの変動に適合したシステムの拡張性を評価できる。<実施形態2>次に、本発明の第2の実施の形態について図3を参照して詳細に説明する。図3を参照すると、本発明の第2の実施の形態における拡張性評価装置100は、運用サービスレベル格納部10と、状況別対策レベル格納部11と、対応知識格納部12と、状況別リクエストモデル格納部13と、想定トラフィック合成部14と、拡張可能性箇所判定部15と、状況別リクエストモデル選択部16と、リクエストモデル格納部17と、拡張ポイントを格納する構成変更データ格納部18と、を有する点で第一の実施の形態と異なる。これらの各部について説明する。運用サービスレベル格納部10は、モデルに含まれる拡張ポイントごとに、拡張するために必要な運用上の時間即応レベルを記述した運用サービスレベルを格納する。運用サービスレベルとは、システム運用で保証されるサービスレベルである。具体的には、図16に示すように、運用サービスレベル格納部10は拡張ポイントと即応レベルとを対応付けて記憶する。状況別対策レベル格納部11は、非常時におけるシステムへのリクエストの変化などの、短時間におけるリクエストの変化に対して、システムがどの程度の時間で対策すべきかを記述した状況別対策レベルを格納する。具体的には、図14に示すように、状況別対策レベル格納部11は、業務内容の変更を伴わないリクエストのトラフィックの変化に対して、トラフィックの種類ごとに、システムが運用上どの程度の時間で対応すべきかの上限時間を表す対応時間を記述した状況別対策レベルを格納する。対応知識格納部12は、モデルの拡張可能な拡張ポイントごとに、各拡張ポイントがシステム上で即応可能かどうかを示す対応知識を格納する。具体的には、図15に示すように、対応知識格納部12は、モデルの拡張ポイントと、各拡張ポイントがシステム上ですぐに所定時間以内に対応できるかどうかの情報即応性と、を対応付けて記憶する。状況別リクエストモデル格納部13は、業務拡張以外を原因とする短時間におけるリクエストの変化を記述した状況別リクエストを格納する。この短時間におけるリクエストの変化トラフィックの種類には、例えば図12Aに示すような短時間の間だけリクエスト数が増大する短時間ピークや、急激にリクエスト数が増大しつづける急増などがある。図12に示すように、状況別リクエストモデル格納部13は、業務内容の変更を伴わないリクエストのトラフィックの変化について、トラフィックの種類ごとに、トラフィックの変化状況を記述した状況別リクエストモデルを格納している。想定トラフィック合成部14は、リクエストモデルと状況別リクエストモデルとを合成した合成モデルをつくり、プランニング部3に入力する。具体的には、想定トラフィック合成部14は、リクエストモデル中のどの期間図9の例ではCase1、Case2、Case3のどのケースに状況別リクエストが発生するかをユーザから入力して、その期間のトラフィックを合成する。この具体例は後述する。拡張可能性箇所判定部15は、状況別リクエストに応じた運用サービスレベル情報図16、対応時間情報図14、対応知識情報図15に基づき、モデルに含まれる拡張ポイントを判定する。具体的には、拡張可能性箇所判定部15は、状況別リクエストモデルにおけるトラフィックの種類に対応する対応時間を状況別対策レベル格納部11図14から抽出し、その対応時間以内で対応可能な拡張ポイントを図15に示す対応知識情報または図16に示す運用サービスレベル情報の少なくとも一方から決定する。例えば、拡張可能性箇所判定部15が運用サービスレベルを用いて拡張ポイントの候補を決定する例について説明する。状況別リクエストモデルにおけるトラフィックの種類が短時間ピークである場合、対応時間は1時間以内であり図14、VMの即応レベルが即座であるため図16、VM数の変更は1時間以内で対応可能であることが分かる。そこで、拡張可能性箇所判定部15は、拡張ポイントをVMと決定する。拡張可能性箇所判定部15は、対応可能な拡張ポイントが複数ある場合には、それらを実際に拡張する拡張ポイントの候補として決定する。状況別リクエストモデル選択部16は、状況別リクエストモデル格納部13に格納された状況別リクエストモデルのうち、プランニング部3がプランニングに利用する状況別リクエストモデルを1つ以上選択する。状況別リクエストモデル選択部16は、システムに対するリクエストを予測して状況別リクエストモデルを自動的に選択しても良いし、ユーザが状況別リクエストモデルを直接選択しても良い。リクエストモデル格納部17は、業務内容の変更やサービスの成長に合わせて想定されるリクエストの時間変化を表したリクエストモデルを格納する。リクエストモデルについては実施形態1で述べたので詳細説明は省略する。他の構成については第1の実施の形態と概略同様であるため詳細説明を省略するが、概略を述べると以下のようになる。第2の実施の形態における拡張性評価装置100では、プランニング部3は、システムが想定トラフィックを処理できるようにモデルの拡張ポイントを決定する。性能算出部4は、拡張ポイントを反映したモデルの性能を算出する。拡張コスト算出部6は、拡張ポイントと構成変更コストとを用いて拡張コストを算出する。拡張性評価値算出部8は、性能と拡張コストから拡張性評価値を算出する。拡張性評価値格納部9は、算出した拡張性を格納する。次に、図4のフローチャートを用いて、本実施の形態の全体の動作の一例について詳細に説明する。まず、図示しないリクエストモデル入力部2は、リクエストモデルを入力する図4のステップS1。次に、状況別リクエストモデル選択部16は、状況別リクエストモデルを状況別リクエストモデル格納部13から選択する図4のステップS2。次に、拡張性可能箇所判断部15は、状況別対策レベル格納部11から、前記状況別リクエストモデルに対応した状況別対策レベルを抽出する図4のステップS3。また、拡張性可能箇所判断部15は、運用サービスレベル格納部10から、前記状況別リクエストモデルに対応した運用サービスレベルを抽出する図4のステップS4。また、拡張可能箇所判断部15は、対応知識格納部12から、前記状況別リクエストモデルに対応した対応知識を抽出する図4のステップS5。そして、拡張可能箇所判定部15は、前記状況別対策レベルの対応時間図14と、前記運用サービスレベルの即応レベル図16と、前記対応知識の即応性図15とに基づき、対応時間以内に対応可能な拡張ポイントを抽出し、モデル中の拡張ポイントの候補を特定する図4のステップS6。さらに、想定トラフィック合成部14は、選択された状況別リクエストモデルをリクエストモデルと合成する図4のステップS7。さらに、プランニング部3は、拡張可能箇所判定部15で抽出した拡張ポイントから、前記合成されたリクエストモデルの条件を満たすように拡張ポイントを決定し、構成変更データとして構成変更データ格納部18に格納するとともに、その構成の最大処理能力を計算する図4のステップS8。さらに、拡張コスト算出部6は、生成されたシステム構成と構成変更コストデータを用いて、拡張されたシステムを生成もとのシステムを変更するために必要なコストを計算する図4のステップS9。拡張性評価装置100は、入力されたすべてのリクエストモデルでプランニング部3がプランニングしていない場合には、図4のステップS8からステップS9までを繰り返す図4のステップS10。プランニング部3がすべてのリクエストモデルでプランニングしている場合には、算出したコストと性能とをもとに、拡張性評価値を拡張性評価値算出部8で計算して、状況別拡張性評価データとして拡張性評価値格納部9に格納する図4のステップS11。次に、本実施の形態の動作についてより具体的な説明をする。図8に示すように、モデル格納部1には、システムの構成と、その構成を拡張可能なポイントや動作が、モデルとして記述されたモデル情報が格納されている。図8を用いて、本モデルの拡張性を評価する具体例を説明する。本モデルでは、例えばアプリケーションサーバ内にVMが配置されていることを表しており、その台数が1台から3台の間で可変であることを表している。次にリクエストモデル入力部2により、図9に示すリクエストモデルが与えられる。図9では、リクエストモデルが、Case1、Case2、Case3の時間順で変化することを示しており、それぞれの場合のリクエストの想定到着率、リクエストに含まれるデータ量、データの書き込み/読み込み比率が与えられている。次に状況別リクエストモデル選択部16により、図12Bに示す状況別リクエストモデルが与えられる。本実施例では図12Bに示すトラフィックの種類が短時間ピークの想定到着率である場合を説明する。ユーザは、リクエストモデル中、どの期間に状況別リクエストが発生するかを指定する。該指定を入力して想定トラフィック合成部14がトラフィックを合成する。本実施の形態では、想定トラフィック合成部14は、状況別リクエストモデルをリクエストモデルのCase2に合成する場合を例に説明する。この場合、想定トラフィック合成部14が合成した結果のリクエストモデルは、図17が示すように、Case2の想定到着率が、状況別リクエストの想定到着率90となる点で図9のリクエストモデルと異なる。次に、拡張可能箇所判断部15は、状況別対策レベル図14参照からモデル中の拡張可能な拡張ポイントを限定する。本実施形態では、状況別リクエストモデルはトラフィックの種類が短時間ピークである。そのため、拡張可能性箇所判定部15は、図14に示す状況別対策レベルから、短時間ピークの状況別リクエストモデルに対応する対応時間1時間以内を抽出する。この対応時間以内で対応可能なシステムを、例えば運用サービスレベル図16から求めると、VMの即応レベルが即座であるため、VM台数は1時間以内で対応可能なことが分かる。そこで、Case2のプランニングでは、プランニング部3は、このVM台数に拡張ポイントを限定してプランニングを実施する。Case1、Case2、Case3のそれぞれの期間ごとのプランニング結果を図10の拡張ポイント列に示す。図10のプランニング結果によれば、Case1のリクエストを満たすためにCPU台数が1である必要があり、Case2では、拡張ポイントであるVM台数を1、すなわち1台増やす必要があることがわかる。拡張コスト算出部6は、このプランニング結果から拡張に必要なコストを構成変更コスト格納部5を参照して計算する。また、性能算出部4は、その拡張をシステムに当てはめた場合のシステムの性能を計算する。次に拡張性評価値算出部8は、拡張性評価値を、例えば拡張性評価値=向上した性能/コストにより計算する。計算された拡張性評価値の例を図11に示す。図11では、Case1からCase2、Case2からCase3、Case1からCase3の3つのパターンの拡張性評価値が示されている。本例では、拡張性評価装置100は、Case1からCase3への拡張が最も拡張性が高いと評価し、その結果を出力する。次に、本実施の形態の効果について説明する。本実施の形態における拡張性評価装置100は、状況別リクエストに対応可能なモデルの構成要素を、状況別対策レベルと、運用サービスレベルと、対策知識とから限定し、状況別リクエストモデルとリクエストモデルとを合成したトラフィックをもとに、モデルをプランニングして拡張性評価値を算出する。そのため、本実施の形態における拡張性評価装置100は、通常のシステム拡張だけでなく突発的なリクエスト変動であっても、リクエスト変動に適合したシステムの拡張性を評価できる。<実施形態3>次に、本発明の第3の実施の形態について図5を参照して詳細に説明する。図5を参照すると、本発明の第3の実施の形態は、本発明の第2の実施の形態における状況別リクエストモデル格納部13の代わりにリクエストモデル変動知識格納部23を備え、状況別リクエストモデル選択部16の代わりにリクエストモデル変動判定部26を備える。他の各部については第1あるいは第2の実施の形態と同様であるから詳細説明を省略する。上述の各部を説明する。リクエストモデル変動知識格納部23は、リクエストの増加率や増加継続時間などのリクエストの変化をもとにリクエストの状況を判定するための知識であるリクエストモデル変動知識を格納する。リクエストモデル変動知識格納部23が格納するリクエストモデル変動知識の例を図13に示す。リクエストモデル変動知識格納部23は、例えば、図13のように、リクエスト到着率の変化率が3以上であり、そのピークの維持時間が2時間以内である状況と、リクエストの状況短時間ピークとを対応付けて格納する。リクエストモデル変動判定部26は、入力されたリクエストモデルに対し、リクエストモデル変動知識格納部23が格納しているリクエストモデル変動知識に基づいて、リクエストモデルの変化状況時間変化状況を判定する。次に、図5及び図6のフローチャートを参照して本実施の形態の全体の動作の一例について詳細に説明する。まず、図示しないリクエストモデル入力部2は、リクエストモデルを入力する図6のステップS1。次に、リクエストモデル変動判定部26は、リクエストモデル変動知識格納部23が格納するリクエスト変動知識を参照して、入力されたリクエストモデルの変動の状況を判定する図6のステップS2。拡張可能箇所判断部15は、リクエストモデル変動判定部26が判定したリクエストモデルの状況に合わせて状況別対策レベル格納部11から状況別対策レベルの対応時間を抽出する図6のステップS3。また、拡張可能箇所判断部15は、リクエストモデルの状況に合わせて、運用サービスレベル格納部10から運用サービスレベルの即応レベルを抽出する図6のステップS4。また、拡張可能箇所判断部15は、リクエストモデルの状況に合わせて、対応知識格納部12から対応知識の即応性を抽出する図6のステップS5。そして、拡張可能性箇所判定部15は、状況別対策レベルの対応時間図14参照、運用サービスレベルの即応レベル図16参照あるいは対応知識の即応性図15参照から、対応時間内に対応可能な拡張ポイントの候補を抽出し、モデル中の拡張ポイントの候補を特定する図6のステップS6。さらに、プランニング部3は、拡張可能箇所判定部15で抽出した拡張ポイントの候補の中から、リクエストモデルを満たすような拡張ポイントを決定し、構成変更データとして構成変更データ格納部18に格納し、その構成の最大処理能力を計算する図6のステップS7。さらに、拡張コスト算出部6は、生成されたシステム構成と構成変更コストデータを用いてシステムを構築または変更するために必要なコストを計算する図6のステップS8。拡張性評価装置100は、プランニング部3が、入力されたすべてのリクエストモデルでプランニングしていない場合は、ステップS7からステップS8までを繰り返す図6のステップS9。プランニング部3が、入力されたすべてのリクエストモデルでプランニングした場合は、拡張性評価値算出部8は、構成変更データと構成変更コストをもとに拡張性評価値を計算し、状況別拡張性評価データとして、拡張性評価値格納部9に格納する図4のステップS10。次に、本実施の形態の効果について説明する。本実施の形態における拡張性評価装置100は、リクエスト変動知識をもとに状況別のリクエストモデルの変化を判定し、その状況別リクエストに対応可能なモデル上の構成要素を限定し、そのうえでリクエストモデルを満たすようにシステム拡張を決定し、拡張性を評価する。そのため、本実施の形態における拡張性評価装置100は、システムへのリクエストの変動に適合したシステムの拡張性を評価できる。<実施形態4>次に、本発明の第4の実施の形態について説明する。図18は、本発明の第4の実施の形態の構成を示す図である。図18を参照すると、本発明の第4の実施の形態における拡張性評価装置100は、プランニング部3と、性能算出部4と、拡張コスト算出部6と、からなる。これらの構成、動作については第1の実施の形態と同様であるから詳細説明を省略する。この構成により、入力されたリクエストモデルの条件を満たすように、システムの構成の拡張ポイントを決定するプランニング手段と、システムの構成の変更に要する拡張コストを前記拡張ポイントについて計算して出力する拡張コスト算出手段と、プランニング手段が決定した拡張ポイントが変更された場合のシステムの性能値を計算して出力する性能算出手段と、を備える拡張性評価装置が提供される。本実施の形態における拡張性評価装置100によれば、システムへのリクエストの変動に基づいた拡張性を評価できる、拡張性評価装置、拡張性評価方法および拡張性評価用プログラムが提供される。以上、実施形態を参照して本願発明を説明したが、本願発明は上記実施形態に限定されるものではない。本願発明の構成や詳細には、本願発明のスコープ内で当業者が理解しうる様々な変更をすることができる。この出願は、2010年8月18日に出願された日本出願特願2010-183320を基礎とする優先権を主張し、その開示の全てをここに取り込む。