JPWO2012023625A1 - 拡張性評価装置、拡張性評価方法および拡張性評価プログラム - Google Patents
拡張性評価装置、拡張性評価方法および拡張性評価プログラム Download PDFInfo
- Publication number
- JPWO2012023625A1 JPWO2012023625A1 JP2012529637A JP2012529637A JPWO2012023625A1 JP WO2012023625 A1 JPWO2012023625 A1 JP WO2012023625A1 JP 2012529637 A JP2012529637 A JP 2012529637A JP 2012529637 A JP2012529637 A JP 2012529637A JP WO2012023625 A1 JPWO2012023625 A1 JP WO2012023625A1
- Authority
- JP
- Japan
- Prior art keywords
- request
- model
- request model
- change
- extension point
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F30/00—Computer-aided design [CAD]
- G06F30/20—Design optimisation, verification or simulation
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/30—Monitoring
- G06F11/34—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment
- G06F11/3442—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment for planning or managing the needed capacity
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/30—Monitoring
- G06F11/34—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment
- G06F11/3447—Performance evaluation by modeling
Abstract
システムへのリクエストの変動に基づいてシステムの拡張性を評価できるシステム拡張性評価装置、拡張性評価方法および拡張性評価プログラムを提供する。拡張性評価装置であって、システムへのリクエストの変化予測情報（リクエストモデル）を入力し、前記リクエストモデルの期間ごとの条件を満たす前記システムの構成（拡張ポイント）を所定の規則に基づき変更するプランニング手段と、前記拡張ポイントの変更に要するコスト（拡張コスト）を算出する拡張コスト算出手段と、前記プランニング手段によって前記拡張ポイントが変更された場合のシステムの性能を表す値（性能値）を算出する性能算出手段と、を備える。
Description
本発明は拡張性評価装置、拡張性評価方法および拡張性評価プログラムに関する。
この分野に関し、特許文献１には、ＩＴシステムの設計支援システムが、ＩＴシステムの設計に必要なデータを基に、処理性能の設計基準値を満たすシステム案を処理性能評価部で作成することが記載されている。
また、特許文献２には、コンテキストアウェアサーバ性能評価システムが、評価モジュールを制御してコンテキストアウェアサーバの拡張性、処理速度、安定性を評価することが記載されている。
また、特許文献３には、アクションの実行にかかる処理時間と待ち時間とのそれぞれについて開発対象システムの性能を評価する性能評価部を備える性能評価装置性能評価装置が記載されている。
また、特許文献２には、コンテキストアウェアサーバ性能評価システムが、評価モジュールを制御してコンテキストアウェアサーバの拡張性、処理速度、安定性を評価することが記載されている。
また、特許文献３には、アクションの実行にかかる処理時間と待ち時間とのそれぞれについて開発対象システムの性能を評価する性能評価部を備える性能評価装置性能評価装置が記載されている。
しかし、上述した技術においては、システムへのリクエストの変動に基づいて、システムの拡張性を評価できないという問題点があった。
このため、本発明の目的は、上述の課題を解決する、システムへのリクエストの変動に基づいてシステムの拡張性を評価できる拡張性評価装置、拡張性評価方法および拡張性評価プログラムを提供することである。
このため、本発明の目的は、上述の課題を解決する、システムへのリクエストの変動に基づいてシステムの拡張性を評価できる拡張性評価装置、拡張性評価方法および拡張性評価プログラムを提供することである。
かかる目的を達成するため、本発明の一形態は、拡張性評価装置であって、システムへのリクエストの変化予測情報（リクエストモデル）を入力し、前記リクエストモデルの期間ごとの条件を満たす前記システムの構成（拡張ポイント）を所定の規則に基づき変更するプランニング手段と、前記拡張ポイントの変更に要するコスト（拡張コスト）を計算して出力する拡張コスト算出手段と、前記プランニング手段によって前記拡張ポイントが変更された場合のシステムの性能を表す値（性能値）を計算して出力する性能算出手段と、を備える。
また、本発明によれば、システムへのリクエストの変化予測情報（リクエストモデル）を入力し、前記リクエストモデルの期間ごとの条件を満たす前記システムの構成（拡張ポイント）を所定の規則に基づき変更するプランニングステップと、前記拡張ポイントの変更に要するコスト（拡張コスト）を計算して出力する拡張コスト算出ステップと、前記プランニング手段によって前記拡張ポイントが変更された場合のシステムの性能を表す値（性能値）を計算して出力する性能算出ステップと、をコンピュータに実行させる拡張性評価プログラムが提供される。
また、本発明によれば、システムへのリクエストの変化予測情報（リクエストモデル）を入力し、前記リクエストモデルの期間ごとの条件を満たす前記システムの構成（拡張ポイント）を所定の規則に基づき変更し、前記拡張ポイントの変更に要するコスト（拡張コスト）を計算して出力し、前記拡張ポイントが変更された場合のシステムの性能を表す値（性能値）を計算して出力する拡張性評価方法が提供される。
また、本発明によれば、システムへのリクエストの変化予測情報（リクエストモデル）を入力し、前記リクエストモデルの期間ごとの条件を満たす前記システムの構成（拡張ポイント）を所定の規則に基づき変更するプランニングステップと、前記拡張ポイントの変更に要するコスト（拡張コスト）を計算して出力する拡張コスト算出ステップと、前記プランニング手段によって前記拡張ポイントが変更された場合のシステムの性能を表す値（性能値）を計算して出力する性能算出ステップと、をコンピュータに実行させる拡張性評価プログラムが提供される。
また、本発明によれば、システムへのリクエストの変化予測情報（リクエストモデル）を入力し、前記リクエストモデルの期間ごとの条件を満たす前記システムの構成（拡張ポイント）を所定の規則に基づき変更し、前記拡張ポイントの変更に要するコスト（拡張コスト）を計算して出力し、前記拡張ポイントが変更された場合のシステムの性能を表す値（性能値）を計算して出力する拡張性評価方法が提供される。
本発明は、システムへのリクエストの変動に基づいてシステムの拡張性を評価できる拡張性評価装置、拡張性評価方法および拡張性評価用プログラムを提供する。
以下、本発明の実施の形態について、図面を用いて説明する。すべての図面において、同様な構成要素には同様の符号を付し、適宜説明を省略する。
なお、各実施形態の拡張性評価装置１００を構成する各部は、制御部、メモリ、メモリにロードされたプログラム、プログラムを格納するハードディスク等の記憶ユニット、ネットワーク接続用インターフェースなどからなり、ハードウェアとソフトウェアの任意の組合せによって実現される。そして特に断りのない限り、その実現方法、装置は限定されない。
また、制御部はＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）などからなり、オペレーティングシステムを動作させて拡張性評価装置１００の全体を制御するとともに、例えばドライブ装置などに装着された記録媒体からメモリにプログラムやデータを読み出し、これに従って各種の処理を実行する。
記録媒体は、例えば光ディスク、フレキシブルディスク、磁気光ディスク、外付けハードディスク、半導体メモリ等であって、コンピュータプログラムをコンピュータが読み取り可能に記録する。また、コンピュータプログラムは、通信網に接続されている図示しない外部コンピュータからダウンロードされても良い。なお、特に断りの無い限り、通信網とは、インターネット、ＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）、公衆回線網、無線通信網、または、これらの組み合わせ等によって構成されるネットワーク等であって良い。
また、各実施形態の説明において利用するブロック図は、ハードウェア単位の構成ではなく、機能単位の構成を示している。これらの機能ブロックはハードウェア、ソフトウェアの任意の組み合わせによって実現される。また、これらの図においては、各実施形態の構成部は物理的に結合した一つの装置により実現されるよう記載されている場合もあるが、その実現手段はこれに限定されない。すなわち、二つ以上の物理的に分離した装置を有線または無線で接続し、これら複数の装置により、各実施形態の各構成部、装置、システムを実現してもよい。また、各構成部が物理的に分離した２つ以上装置として記載されている場合もあるが、その実現手段はこれに限定されない。すなわち、物理的に結合した一つの装置によりそれらが実現されるようにハードウェア、ソフトウェアを任意に組み合わせて各実施形態の各構成部、装置、システムを実現してもよい。
＜実施形態１＞
次に、発明を実施するための第１の実施の形態について図１を参照して詳細に説明する。
図１を参照すると、本発明の第１の実施の形態における拡張性評価装置１００は、モデル格納部１と、リクエストモデル入力部２と、プランニング部３と、性能算出部４と、構成変更コスト格納部５と、拡張コスト算出部６と、コスト／性能データ格納部７と、拡張性評価値算出部８と、拡張性評価値格納部９とを含む。
これらの各部について説明する。
モデル格納部１は、システムの構成とその動作についてモデル化した、モデル情報を格納する。ここで、モデル情報とは、例えば、図８に記載のようなサーバの構成やそこに含まれるアプリケーションの情報、それらの拡張可能な構成や拡張可能な範囲、各サーバのリソース消費量（ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）使用率など）など、シミュレーションに必要な情報であり、例えばＵＭＬ（Ｕｎｉｆｉｅｄ Ｍｏｄｅｌｉｎｇ Ｌａｎｇｕａｇｅ）などの標準的なモデル記述言語で記述されたものである。
リクエストモデル入力部２は、システムの利用状況の変化を記載したリクエストモデルを入力する。ここで、システムの利用状況とは、システムに対するリクエストやトラフィックの状況などである。また、リクエストモデルとは、例えば図９に示したように、リクエストの想定到着率、データ量、データの書き込み／読み込み比率、（リクエストモデルの「条件」）のうちの一つ以上を用いてシステムの利用状況の時間変化を表したものである。図９は、リクエストモデルが、Ｃａｓｅ１、Ｃａｓｅ２、Ｃａｓｅ３（リクエストモデルの「期間」）の時間順で変化することを示しており、それぞれの場合のリクエストの想定到着率、リクエストに含まれるデータ量、データの書き込み／読み込み比率が与えられている。
プランニング部３は、入力されたリクエストを満たすようにモデルを拡張する箇所を求める。具体的には、プランニング部３は、モデル格納部１に格納されたモデルが、リクエストモデル入力部２で入力されたそれぞれのリクエストモデルで要求される時間変化に対応できるように、モデルに含まれる可変の構成箇所（拡張ポイント）を決定し、その拡張内容を性能算出部４へ出力する。プランニング部３は、例えば、システムの利用状況の時間変化をリクエストモデルから取得し、その時間変化にシステムが対応するために要する構成の変更箇所（ＣＰＵ数、ＤＢ（Ｄａｔａｂａｓｅ、以下同様）数、ＶＭ（Ｖｉｒｔｕａｌ Ｍａｃｈｉｎｅ、以下同様）台数など）を、リクエストにより変化する負荷と各構成の処理能力等から計算して求める。プランニング部３は、例えば、リクエストにより変化するシステムへの負荷、あるいは、リクエストモデルの想定到着率、データ量、データの書き込み／読み込み比率などの条件を成分とするベクトル（想定到着率、データ量、データの書き込み／読み込み比率）を入力として、システムを構成する構成部品の数であるＣＰＵ数、ＤＢ数、ＶＭ数などを成分とするベクトル（ＣＰＵ数、ＤＢ数、ＶＭ数）を出力する所定の関数（すなわち、ｆ（（想定到着率、データ量、データの書き込み／読み込み比率））＝（ＣＰＵ数、ＤＢ数、ＶＭ数）となる所定の関数ｆ）を用いてリクエストモデルの変化条件に適うシステム構成箇所を決定しても良い。この関数は経験則に従ってユーザが適宜設定できる。あるいは、プランニング部３は、システムの利用状況、リクエストの変化とそれに対応できるシステムの構成とを関連づけて記憶する記憶部を参照して、リクエストモデルの変化条件に適うシステム構成箇所を決定しても良い。このような記憶部が記憶するテーブルの例を図１９に示す。例えば、図１９のテーブルの一行目は、リクエストモデルのＣａｓｅ（期間）の変化によって変わる想定到着率の変化率がａ１％〜ａ２％であり、データ量の変化率がｂ１％〜ｂ２％であり、データ書き込み／読み込み比率の変化率がｃ１％〜ｃ２％であるときに、変更が必要なＣＰＵの台数が＋１台、ＶＭの台数が＋１台、ＤＢの台数が０台（すなわちＤＢの台数は変更が不要）であることを示している。変化率を表すａ１、ａ２、ｂ１、ｂ２、ｃ１、ｃ２などの数は経験則にしたがってユーザが適宜設定できる。
性能算出部４は、機器を拡張変更したときの性能を評価する。具体的には、性能算出部４は、プランニング部３が出力した構成の拡張内容をモデルに当てはめて、構成が変更されたシステムのＣＰＵ数、ＤＢ数、ＶＭ数などから得られるシステムの性能（計算可能量、計算速度等の処理能力を数値化した値、性能値、例えば毎秒処理可能なリクエスト数など）を計算する。性能算出部４は、例えば、システムを構成する部品の数を成分とするベクトル（ＣＰＵ数、ＤＢ数、ＶＭ数）を入力として、システムの性能値を出力する所定の関数（すなわち、ｇ（（ＣＰＵ数、ＤＢ数、ＶＭ数））＝システム性能値、となる所定の関数ｇ）を用いてシステムの性能を求めても良い。この関数は経験則に従ってユーザが適宜設定できる。あるいは、性能算出部４は、システムの構成とシステムの性能とを対応付けて記憶する図示しない記憶部を参照して、システムの性能を求めても良い。
構成変更コスト格納部５は、機器を構成・拡張する際に必要なコストを格納する。具体的には、構成変更コスト格納部５は、機器を拡張する際に変更する部品と、初期コスト（リクエストモデルの各Ｃａｓｅ（期間）における条件をみたす構成を最初から構築するために必要なコスト）と、拡張する際に部品変更に要するコストとを対応付けて記憶する。構成変更コスト格納部５が格納するデータの例を図７に示す。
拡張コスト算出部６は、構成変更コスト格納部５に格納されたコストをもとに、拡張ポイントを拡張するために必要なコスト（拡張コスト）の算出を行なう。具体的には、拡張コスト算出部６は、拡張ポイントの構成ごとに構成変更に要するコストを構成変更コスト格納部５から抽出して拡張ポイントを拡張するために必要なコストを算出する。
コスト／性能データ格納部７は、算出されたコストと性能とを格納する。具体的には、コスト／性能データ格納部７は、プランニング部３によって算出された拡張ポイントと、性能算出部４が算出した性能と、拡張コスト算出部６が算出した拡張コストとを格納する。コスト／性能データ格納部７に格納されているデータの例を図１０に示す。図１０の拡張ポイント列は、Ｃａｓｅ１ではＣＰＵとＶＭがそれぞれ１つずつの構成であることを示している。また、Ｃａｓｅ２は、Ｃａｓｅ１からみてＶＭが＋１、すなわちＶＭを１台増やす必要があることを示している。また、Ｃａｓｅ３は、Ｃａｓｅ１からみてＣＰＵが＋２、ＶＭが＋１であり、ＣＰＵを２台、ＶＭを１台増やす必要があることを示している。
拡張性評価値算出部８は、コスト／性能データ格納部７に格納されたデータからリクエストデータ毎に拡張性評価値を算出する。具体的には、拡張性評価値算出部８は、コスト／性能データ格納部７に格納されたシステムの性能や拡張コストを用いて、リクエストモデルに含まれるリクエスト毎に拡張性評価値を算出する。例えば、拡張性評価値算出部８は、拡張性評価値を、拡張性評価値＝（向上した性能／コスト）によって算出してもよい。なお、拡張性評価値は、向上したシステム性能値が大きく、必要なコストが小さいほど大きくなるような評価値、あるいは、向上したシステムの性能値が小さく、必要なコストが大きいほど小さくなるような評価値であってもよく、特に限定されない。
拡張性評価値格納部９は、拡張性評価値算出部８が算出した各構成の変更パターンごとの拡張性評価値を格納する。拡張性評価値格納部９が格納する拡張性評価値の例を図１１に示す。
次に、図２のフローチャートを参照して本実施の形態の全体の動作の一例について詳細に説明する。
まず、リクエストモデル入力部２は、リクエストモデルを入力する（図２のステップＳ１）。次に、プランニング部３は、入力されたリクエストモデルをモデル格納部１に格納されているモデルに当てはめ、入力されたリクエストを処理可能なシステム構成から拡張ポイントを決定する（図２のステップＳ２）。さらに、性能算出部４は、その拡張ポイントをモデルに当てはめてシステムの性能を計算する（図２のステップＳ３）。さらに、拡張コスト算出部６は、構成変更コスト格納部５が格納する構成変更コストデータを用いて、拡張されたシステムを生成するために必要なコストを計算する（図２のステップＳ４）。拡張性評価装置１００は、入力されたすべてのリクエストモデルでプランニング部３がプランニングを行なっていない場合には、ステップＳ２からＳ４までのステップを繰り返す（図２のステップＳ５）。プランニング部３が、入力されたすべてのリクエストモデルでプランニングを行った場合には、算出したコストとシステムの性能とに基づいて、拡張性評価値算出部８が拡張性評価値を算出する（図２のステップＳ６）。
次に、本実施の形態の効果について説明する。
本実施の形態における拡張性評価装置１００は、入力されたリクエストモデルに合わせて、システムの拡張ポイントを求めて拡張性を評価する。したがって、本実施の形態における拡張性評価装置１００は、予め拡張ポイントを指定しておくことなく、システムへのリクエストの変動に適合したシステムの拡張性を評価できる。
＜実施形態２＞
次に、本発明の第２の実施の形態について図３を参照して詳細に説明する。
図３を参照すると、本発明の第２の実施の形態における拡張性評価装置１００は、運用サービスレベル格納部１０と、状況別対策レベル格納部１１と、対応知識格納部１２と、状況別リクエストモデル格納部１３と、想定トラフィック合成部１４と、拡張可能性箇所判定部１５と、状況別リクエストモデル選択部１６と、リクエストモデル格納部１７と、拡張ポイントを格納する構成変更データ格納部１８と、を有する点で第一の実施の形態と異なる。
これらの各部について説明する。
運用サービスレベル格納部１０は、モデルに含まれる拡張ポイントごとに、拡張するために必要な運用上の時間（即応レベル）を記述した運用サービスレベルを格納する。運用サービスレベルとは、システム運用で保証されるサービスレベルである。具体的には、図１６に示すように、運用サービスレベル格納部１０は拡張ポイントと即応レベルとを対応付けて記憶する。
状況別対策レベル格納部１１は、非常時におけるシステムへのリクエストの変化などの、短時間におけるリクエストの変化に対して、システムがどの程度の時間で対策すべきかを記述した状況別対策レベルを格納する。具体的には、図１４に示すように、状況別対策レベル格納部１１は、業務内容の変更を伴わないリクエストのトラフィックの変化に対して、トラフィックの種類ごとに、システムが運用上どの程度の時間で対応すべきかの上限時間を表す対応時間を記述した状況別対策レベルを格納する。
対応知識格納部１２は、モデルの拡張可能な拡張ポイントごとに、各拡張ポイントがシステム上で即応可能かどうかを示す対応知識を格納する。具体的には、図１５に示すように、対応知識格納部１２は、モデルの拡張ポイントと、各拡張ポイントがシステム上ですぐに（所定時間以内に）対応できるかどうかの情報（即応性）と、を対応付けて記憶する。
状況別リクエストモデル格納部１３は、業務拡張以外を原因とする短時間におけるリクエストの変化を記述した状況別リクエストを格納する。この短時間におけるリクエストの変化（トラフィックの種類）には、例えば図１２Ａに示すような短時間の間だけリクエスト数が増大する「短時間ピーク」や、急激にリクエスト数が増大しつづける「急増」などがある。図１２に示すように、状況別リクエストモデル格納部１３は、業務内容の変更を伴わないリクエストのトラフィックの変化について、トラフィックの種類ごとに、トラフィックの変化状況を記述した状況別リクエストモデルを格納している。
想定トラフィック合成部１４は、リクエストモデルと状況別リクエストモデルとを合成した合成モデルをつくり、プランニング部３に入力する。具体的には、想定トラフィック合成部１４は、リクエストモデル中のどの期間（図９の例ではＣａｓｅ１、Ｃａｓｅ２、Ｃａｓｅ３のどのケース）に状況別リクエストが発生するかをユーザから入力して、その期間のトラフィックを合成する。この具体例は後述する。
拡張可能性箇所判定部１５は、状況別リクエストに応じた運用サービスレベル情報（図１６）、対応時間情報（図１４）、対応知識情報（図１５）に基づき、モデルに含まれる拡張ポイントを判定する。具体的には、拡張可能性箇所判定部１５は、状況別リクエストモデルにおけるトラフィックの種類に対応する対応時間を状況別対策レベル格納部１１（図１４）から抽出し、その対応時間以内で対応可能な拡張ポイントを図１５に示す対応知識情報または図１６に示す運用サービスレベル情報の少なくとも一方から決定する。例えば、拡張可能性箇所判定部１５が運用サービスレベルを用いて拡張ポイントの候補を決定する例について説明する。状況別リクエストモデルにおけるトラフィックの種類が「短時間ピーク」である場合、対応時間は「１時間以内」であり（図１４）、ＶＭの即応レベルが「即座」であるため（図１６）、ＶＭ数の変更は１時間以内で対応可能であることが分かる。そこで、拡張可能性箇所判定部１５は、拡張ポイントをＶＭと決定する。拡張可能性箇所判定部１５は、対応可能な拡張ポイントが複数ある場合には、それらを実際に拡張する拡張ポイントの候補として決定する。
状況別リクエストモデル選択部１６は、状況別リクエストモデル格納部１３に格納された状況別リクエストモデルのうち、プランニング部３がプランニングに利用する状況別リクエストモデルを１つ以上選択する。状況別リクエストモデル選択部１６は、システムに対するリクエストを予測して状況別リクエストモデルを自動的に選択しても良いし、ユーザが状況別リクエストモデルを直接選択しても良い。
リクエストモデル格納部１７は、業務内容の変更やサービスの成長に合わせて想定されるリクエストの時間変化を表したリクエストモデルを格納する。リクエストモデルについては実施形態１で述べたので詳細説明は省略する。
他の構成については第１の実施の形態と概略同様であるため詳細説明を省略するが、概略を述べると以下のようになる。第２の実施の形態における拡張性評価装置１００では、プランニング部３は、システムが想定トラフィックを処理できるようにモデルの拡張ポイントを決定する。性能算出部４は、拡張ポイントを反映したモデルの性能を算出する。拡張コスト算出部６は、拡張ポイントと構成変更コストとを用いて拡張コストを算出する。拡張性評価値算出部８は、性能と拡張コストから拡張性評価値を算出する。拡張性評価値格納部９は、算出した拡張性を格納する。
次に、図４のフローチャートを用いて、本実施の形態の全体の動作の一例について詳細に説明する。
まず、図示しないリクエストモデル入力部２は、リクエストモデルを入力する（図４のステップＳ１）。次に、状況別リクエストモデル選択部１６は、状況別リクエストモデルを状況別リクエストモデル格納部１３から選択する（図４のステップＳ２）。次に、拡張性可能箇所判断部１５は、状況別対策レベル格納部１１から、前記状況別リクエストモデルに対応した状況別対策レベルを抽出する（図４のステップＳ３）。また、拡張性可能箇所判断部１５は、運用サービスレベル格納部１０から、前記状況別リクエストモデルに対応した運用サービスレベルを抽出する（図４のステップＳ４）。また、拡張可能箇所判断部１５は、対応知識格納部１２から、前記状況別リクエストモデルに対応した対応知識を抽出する（図４のステップＳ５）。そして、拡張可能箇所判定部１５は、前記状況別対策レベルの対応時間（図１４）と、前記運用サービスレベルの即応レベル（図１６）と、前記対応知識の即応性（図１５）とに基づき、対応時間以内に対応可能な拡張ポイントを抽出し、モデル中の拡張ポイントの候補を特定する（図４のステップＳ６）。さらに、想定トラフィック合成部１４は、選択された状況別リクエストモデルをリクエストモデルと合成する（図４のステップＳ７）。さらに、プランニング部３は、拡張可能箇所判定部１５で抽出した拡張ポイントから、前記合成されたリクエストモデルの条件を満たすように拡張ポイントを決定し、構成変更データとして構成変更データ格納部１８に格納するとともに、その構成の最大処理能力を計算する（図４のステップＳ８）。さらに、拡張コスト算出部６は、生成されたシステム構成と構成変更コストデータを用いて、拡張されたシステムを生成（もとのシステムを変更）するために必要なコストを計算する（図４のステップＳ９）。拡張性評価装置１００は、入力されたすべてのリクエストモデルでプランニング部３がプランニングしていない場合には、図４のステップＳ８からステップＳ９までを繰り返す（図４のステップＳ１０）。プランニング部３がすべてのリクエストモデルでプランニングしている場合には、算出したコストと性能とをもとに、拡張性評価値を拡張性評価値算出部８で計算して、状況別拡張性評価データとして拡張性評価値格納部９に格納する（図４のステップＳ１１）。
次に、本実施の形態の動作についてより具体的な説明をする。
図８に示すように、モデル格納部１には、システムの構成と、その構成を拡張可能なポイントや動作が、モデルとして記述されたモデル情報が格納されている。図８を用いて、本モデルの拡張性を評価する具体例を説明する。本モデルでは、例えばアプリケーションサーバ内にＶＭが配置されていることを表しており、その台数が１台から３台の間で可変であることを表している。次にリクエストモデル入力部２により、図９に示すリクエストモデルが与えられる。図９では、リクエストモデルが、Ｃａｓｅ１、Ｃａｓｅ２、Ｃａｓｅ３の時間順で変化することを示しており、それぞれの場合のリクエストの想定到着率、リクエストに含まれるデータ量、データの書き込み／読み込み比率が与えられている。次に状況別リクエストモデル選択部１６により、図１２Ｂに示す状況別リクエストモデルが与えられる。本実施例では図１２Ｂに示すトラフィックの種類が「短時間ピーク」の想定到着率である場合を説明する。ユーザは、リクエストモデル中、どの期間に状況別リクエストが発生するかを指定する。該指定を入力して想定トラフィック合成部１４がトラフィックを合成する。本実施の形態では、想定トラフィック合成部１４は、状況別リクエストモデルをリクエストモデルのＣａｓｅ２に合成する場合を例に説明する。この場合、想定トラフィック合成部１４が合成した結果のリクエストモデルは、図１７が示すように、Ｃａｓｅ２の想定到着率が、状況別リクエストの想定到着率９０％となる点で図９のリクエストモデルと異なる。次に、拡張可能箇所判断部１５は、状況別対策レベル（図１４参照）からモデル中の拡張可能な拡張ポイントを限定する。本実施形態では、状況別リクエストモデルはトラフィックの種類が「短時間ピーク」である。そのため、拡張可能性箇所判定部１５は、図１４に示す状況別対策レベルから、短時間ピークの状況別リクエストモデルに対応する対応時間（１時間以内）を抽出する。この対応時間以内で対応可能なシステムを、例えば運用サービスレベル（図１６）から求めると、ＶＭの即応レベルが「即座」であるため、ＶＭ台数は１時間以内で対応可能なことが分かる。そこで、Ｃａｓｅ２のプランニングでは、プランニング部３は、このＶＭ台数に拡張ポイントを限定してプランニングを実施する。Ｃａｓｅ１、Ｃａｓｅ２、Ｃａｓｅ３のそれぞれの期間ごとのプランニング結果を図１０の拡張ポイント列に示す。図１０のプランニング結果によれば、Ｃａｓｅ１のリクエストを満たすためにＣＰＵ台数が１である必要があり、Ｃａｓｅ２では、拡張ポイントであるＶＭ台数を＋１、すなわち１台増やす必要があることがわかる。拡張コスト算出部６は、このプランニング結果から拡張に必要なコストを構成変更コスト格納部５を参照して計算する。また、性能算出部４は、その拡張をシステムに当てはめた場合のシステムの性能を計算する。次に拡張性評価値算出部８は、拡張性評価値を、例えば拡張性評価値＝（向上した性能／コスト）により計算する。計算された拡張性評価値の例を図１１に示す。図１１では、Ｃａｓｅ１からＣａｓｅ２、Ｃａｓｅ２からＣａｓｅ３、Ｃａｓｅ１からＣａｓｅ３の３つのパターンの拡張性評価値が示されている。本例では、拡張性評価装置１００は、Ｃａｓｅ１からＣａｓｅ３への拡張が最も拡張性が高いと評価し、その結果を出力する。
次に、本実施の形態の効果について説明する。
本実施の形態における拡張性評価装置１００は、状況別リクエストに対応可能なモデルの構成要素を、状況別対策レベルと、運用サービスレベルと、対策知識とから限定し、状況別リクエストモデルとリクエストモデルとを合成したトラフィックをもとに、モデルをプランニングして拡張性評価値を算出する。そのため、本実施の形態における拡張性評価装置１００は、通常のシステム拡張だけでなく突発的なリクエスト変動であっても、リクエスト変動に適合したシステムの拡張性を評価できる。
＜実施形態３＞
次に、本発明の第３の実施の形態について図５を参照して詳細に説明する。
図５を参照すると、本発明の第３の実施の形態は、本発明の第２の実施の形態における状況別リクエストモデル格納部１３の代わりにリクエストモデル変動知識格納部２３を備え、状況別リクエストモデル選択部１６の代わりにリクエストモデル変動判定部２６を備える。他の各部については第１あるいは第２の実施の形態と同様であるから詳細説明を省略する。
上述の各部を説明する。
リクエストモデル変動知識格納部２３は、リクエストの増加率や増加継続時間などのリクエストの変化をもとにリクエストの状況を判定するための知識であるリクエストモデル変動知識を格納する。リクエストモデル変動知識格納部２３が格納するリクエストモデル変動知識の例を図１３に示す。
リクエストモデル変動知識格納部２３は、例えば、図１３のように、リクエスト到着率の変化率が３以上であり、そのピークの維持時間が２時間以内である状況と、リクエストの状況「短時間ピーク」とを対応付けて格納する。
リクエストモデル変動判定部２６は、入力されたリクエストモデルに対し、リクエストモデル変動知識格納部２３が格納しているリクエストモデル変動知識に基づいて、リクエストモデルの変化状況（時間変化状況）を判定する。
次に、図５及び図６のフローチャートを参照して本実施の形態の全体の動作の一例について詳細に説明する。
まず、図示しないリクエストモデル入力部２は、リクエストモデルを入力する（図６のステップＳ１）。次に、リクエストモデル変動判定部２６は、リクエストモデル変動知識格納部２３が格納するリクエスト変動知識を参照して、入力されたリクエストモデルの変動の状況を判定する（図６のステップＳ２）。拡張可能箇所判断部１５は、リクエストモデル変動判定部２６が判定したリクエストモデルの状況に合わせて状況別対策レベル格納部１１から状況別対策レベルの対応時間を抽出する（図６のステップＳ３）。また、拡張可能箇所判断部１５は、リクエストモデルの状況に合わせて、運用サービスレベル格納部１０から運用サービスレベルの即応レベルを抽出する（図６のステップＳ４）。また、拡張可能箇所判断部１５は、リクエストモデルの状況に合わせて、対応知識格納部１２から対応知識の即応性を抽出する（図６のステップＳ５）。そして、拡張可能性箇所判定部１５は、状況別対策レベルの対応時間（図１４参照）、運用サービスレベルの即応レベル（図１６参照）あるいは対応知識の即応性（図１５参照）から、対応時間内に対応可能な拡張ポイントの候補を抽出し、モデル中の拡張ポイントの候補を特定する（図６のステップＳ６）。さらに、プランニング部３は、拡張可能箇所判定部１５で抽出した拡張ポイントの候補の中から、リクエストモデルを満たすような拡張ポイントを決定し、構成変更データとして構成変更データ格納部１８に格納し、その構成の最大処理能力を計算する（図６のステップＳ７）。さらに、拡張コスト算出部６は、生成されたシステム構成と構成変更コストデータを用いてシステムを構築または変更するために必要なコストを計算する（図６のステップＳ８）。拡張性評価装置１００は、プランニング部３が、入力されたすべてのリクエストモデルでプランニングしていない場合は、ステップＳ７からステップＳ８までを繰り返す（図６のステップＳ９）。プランニング部３が、入力されたすべてのリクエストモデルでプランニングした場合は、拡張性評価値算出部８は、構成変更データと構成変更コストをもとに拡張性評価値を計算し、状況別拡張性評価データとして、拡張性評価値格納部９に格納する（図４のステップＳ１０）。
次に、本実施の形態の効果について説明する。
本実施の形態における拡張性評価装置１００は、リクエスト変動知識をもとに状況別のリクエストモデルの変化を判定し、その状況別リクエストに対応可能なモデル上の構成要素を限定し、そのうえでリクエストモデルを満たすようにシステム拡張を決定し、拡張性を評価する。そのため、本実施の形態における拡張性評価装置１００は、システムへのリクエストの変動に適合したシステムの拡張性を評価できる。
＜実施形態４＞
次に、本発明の第４の実施の形態について説明する。
図１８は、本発明の第４の実施の形態の構成を示す図である。図１８を参照すると、本発明の第４の実施の形態における拡張性評価装置１００は、プランニング部３と、性能算出部４と、拡張コスト算出部６と、からなる。これらの構成、動作については第１の実施の形態と同様であるから詳細説明を省略する。
この構成により、入力されたリクエストモデルの条件を満たすように、システムの構成の拡張ポイントを決定するプランニング手段と、システムの構成の変更に要する拡張コストを前記拡張ポイントについて計算して出力する拡張コスト算出手段と、プランニング手段が決定した拡張ポイントが変更された場合のシステムの性能値を計算して出力する性能算出手段と、を備える拡張性評価装置が提供される。
本実施の形態における拡張性評価装置１００によれば、システムへのリクエストの変動に基づいた拡張性を評価できる、拡張性評価装置、拡張性評価方法および拡張性評価用プログラムが提供される。
以上、実施形態を参照して本願発明を説明したが、本願発明は上記実施形態に限定されるものではない。本願発明の構成や詳細には、本願発明のスコープ内で当業者が理解しうる様々な変更をすることができる。
この出願は、２０１０年８月１８日に出願された日本出願特願２０１０−１８３３２０を基礎とする優先権を主張し、その開示の全てをここに取り込む。
なお、各実施形態の拡張性評価装置１００を構成する各部は、制御部、メモリ、メモリにロードされたプログラム、プログラムを格納するハードディスク等の記憶ユニット、ネットワーク接続用インターフェースなどからなり、ハードウェアとソフトウェアの任意の組合せによって実現される。そして特に断りのない限り、その実現方法、装置は限定されない。
また、制御部はＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）などからなり、オペレーティングシステムを動作させて拡張性評価装置１００の全体を制御するとともに、例えばドライブ装置などに装着された記録媒体からメモリにプログラムやデータを読み出し、これに従って各種の処理を実行する。
記録媒体は、例えば光ディスク、フレキシブルディスク、磁気光ディスク、外付けハードディスク、半導体メモリ等であって、コンピュータプログラムをコンピュータが読み取り可能に記録する。また、コンピュータプログラムは、通信網に接続されている図示しない外部コンピュータからダウンロードされても良い。なお、特に断りの無い限り、通信網とは、インターネット、ＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）、公衆回線網、無線通信網、または、これらの組み合わせ等によって構成されるネットワーク等であって良い。
また、各実施形態の説明において利用するブロック図は、ハードウェア単位の構成ではなく、機能単位の構成を示している。これらの機能ブロックはハードウェア、ソフトウェアの任意の組み合わせによって実現される。また、これらの図においては、各実施形態の構成部は物理的に結合した一つの装置により実現されるよう記載されている場合もあるが、その実現手段はこれに限定されない。すなわち、二つ以上の物理的に分離した装置を有線または無線で接続し、これら複数の装置により、各実施形態の各構成部、装置、システムを実現してもよい。また、各構成部が物理的に分離した２つ以上装置として記載されている場合もあるが、その実現手段はこれに限定されない。すなわち、物理的に結合した一つの装置によりそれらが実現されるようにハードウェア、ソフトウェアを任意に組み合わせて各実施形態の各構成部、装置、システムを実現してもよい。
＜実施形態１＞
次に、発明を実施するための第１の実施の形態について図１を参照して詳細に説明する。
図１を参照すると、本発明の第１の実施の形態における拡張性評価装置１００は、モデル格納部１と、リクエストモデル入力部２と、プランニング部３と、性能算出部４と、構成変更コスト格納部５と、拡張コスト算出部６と、コスト／性能データ格納部７と、拡張性評価値算出部８と、拡張性評価値格納部９とを含む。
これらの各部について説明する。
モデル格納部１は、システムの構成とその動作についてモデル化した、モデル情報を格納する。ここで、モデル情報とは、例えば、図８に記載のようなサーバの構成やそこに含まれるアプリケーションの情報、それらの拡張可能な構成や拡張可能な範囲、各サーバのリソース消費量（ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）使用率など）など、シミュレーションに必要な情報であり、例えばＵＭＬ（Ｕｎｉｆｉｅｄ Ｍｏｄｅｌｉｎｇ Ｌａｎｇｕａｇｅ）などの標準的なモデル記述言語で記述されたものである。
リクエストモデル入力部２は、システムの利用状況の変化を記載したリクエストモデルを入力する。ここで、システムの利用状況とは、システムに対するリクエストやトラフィックの状況などである。また、リクエストモデルとは、例えば図９に示したように、リクエストの想定到着率、データ量、データの書き込み／読み込み比率、（リクエストモデルの「条件」）のうちの一つ以上を用いてシステムの利用状況の時間変化を表したものである。図９は、リクエストモデルが、Ｃａｓｅ１、Ｃａｓｅ２、Ｃａｓｅ３（リクエストモデルの「期間」）の時間順で変化することを示しており、それぞれの場合のリクエストの想定到着率、リクエストに含まれるデータ量、データの書き込み／読み込み比率が与えられている。
プランニング部３は、入力されたリクエストを満たすようにモデルを拡張する箇所を求める。具体的には、プランニング部３は、モデル格納部１に格納されたモデルが、リクエストモデル入力部２で入力されたそれぞれのリクエストモデルで要求される時間変化に対応できるように、モデルに含まれる可変の構成箇所（拡張ポイント）を決定し、その拡張内容を性能算出部４へ出力する。プランニング部３は、例えば、システムの利用状況の時間変化をリクエストモデルから取得し、その時間変化にシステムが対応するために要する構成の変更箇所（ＣＰＵ数、ＤＢ（Ｄａｔａｂａｓｅ、以下同様）数、ＶＭ（Ｖｉｒｔｕａｌ Ｍａｃｈｉｎｅ、以下同様）台数など）を、リクエストにより変化する負荷と各構成の処理能力等から計算して求める。プランニング部３は、例えば、リクエストにより変化するシステムへの負荷、あるいは、リクエストモデルの想定到着率、データ量、データの書き込み／読み込み比率などの条件を成分とするベクトル（想定到着率、データ量、データの書き込み／読み込み比率）を入力として、システムを構成する構成部品の数であるＣＰＵ数、ＤＢ数、ＶＭ数などを成分とするベクトル（ＣＰＵ数、ＤＢ数、ＶＭ数）を出力する所定の関数（すなわち、ｆ（（想定到着率、データ量、データの書き込み／読み込み比率））＝（ＣＰＵ数、ＤＢ数、ＶＭ数）となる所定の関数ｆ）を用いてリクエストモデルの変化条件に適うシステム構成箇所を決定しても良い。この関数は経験則に従ってユーザが適宜設定できる。あるいは、プランニング部３は、システムの利用状況、リクエストの変化とそれに対応できるシステムの構成とを関連づけて記憶する記憶部を参照して、リクエストモデルの変化条件に適うシステム構成箇所を決定しても良い。このような記憶部が記憶するテーブルの例を図１９に示す。例えば、図１９のテーブルの一行目は、リクエストモデルのＣａｓｅ（期間）の変化によって変わる想定到着率の変化率がａ１％〜ａ２％であり、データ量の変化率がｂ１％〜ｂ２％であり、データ書き込み／読み込み比率の変化率がｃ１％〜ｃ２％であるときに、変更が必要なＣＰＵの台数が＋１台、ＶＭの台数が＋１台、ＤＢの台数が０台（すなわちＤＢの台数は変更が不要）であることを示している。変化率を表すａ１、ａ２、ｂ１、ｂ２、ｃ１、ｃ２などの数は経験則にしたがってユーザが適宜設定できる。
性能算出部４は、機器を拡張変更したときの性能を評価する。具体的には、性能算出部４は、プランニング部３が出力した構成の拡張内容をモデルに当てはめて、構成が変更されたシステムのＣＰＵ数、ＤＢ数、ＶＭ数などから得られるシステムの性能（計算可能量、計算速度等の処理能力を数値化した値、性能値、例えば毎秒処理可能なリクエスト数など）を計算する。性能算出部４は、例えば、システムを構成する部品の数を成分とするベクトル（ＣＰＵ数、ＤＢ数、ＶＭ数）を入力として、システムの性能値を出力する所定の関数（すなわち、ｇ（（ＣＰＵ数、ＤＢ数、ＶＭ数））＝システム性能値、となる所定の関数ｇ）を用いてシステムの性能を求めても良い。この関数は経験則に従ってユーザが適宜設定できる。あるいは、性能算出部４は、システムの構成とシステムの性能とを対応付けて記憶する図示しない記憶部を参照して、システムの性能を求めても良い。
構成変更コスト格納部５は、機器を構成・拡張する際に必要なコストを格納する。具体的には、構成変更コスト格納部５は、機器を拡張する際に変更する部品と、初期コスト（リクエストモデルの各Ｃａｓｅ（期間）における条件をみたす構成を最初から構築するために必要なコスト）と、拡張する際に部品変更に要するコストとを対応付けて記憶する。構成変更コスト格納部５が格納するデータの例を図７に示す。
拡張コスト算出部６は、構成変更コスト格納部５に格納されたコストをもとに、拡張ポイントを拡張するために必要なコスト（拡張コスト）の算出を行なう。具体的には、拡張コスト算出部６は、拡張ポイントの構成ごとに構成変更に要するコストを構成変更コスト格納部５から抽出して拡張ポイントを拡張するために必要なコストを算出する。
コスト／性能データ格納部７は、算出されたコストと性能とを格納する。具体的には、コスト／性能データ格納部７は、プランニング部３によって算出された拡張ポイントと、性能算出部４が算出した性能と、拡張コスト算出部６が算出した拡張コストとを格納する。コスト／性能データ格納部７に格納されているデータの例を図１０に示す。図１０の拡張ポイント列は、Ｃａｓｅ１ではＣＰＵとＶＭがそれぞれ１つずつの構成であることを示している。また、Ｃａｓｅ２は、Ｃａｓｅ１からみてＶＭが＋１、すなわちＶＭを１台増やす必要があることを示している。また、Ｃａｓｅ３は、Ｃａｓｅ１からみてＣＰＵが＋２、ＶＭが＋１であり、ＣＰＵを２台、ＶＭを１台増やす必要があることを示している。
拡張性評価値算出部８は、コスト／性能データ格納部７に格納されたデータからリクエストデータ毎に拡張性評価値を算出する。具体的には、拡張性評価値算出部８は、コスト／性能データ格納部７に格納されたシステムの性能や拡張コストを用いて、リクエストモデルに含まれるリクエスト毎に拡張性評価値を算出する。例えば、拡張性評価値算出部８は、拡張性評価値を、拡張性評価値＝（向上した性能／コスト）によって算出してもよい。なお、拡張性評価値は、向上したシステム性能値が大きく、必要なコストが小さいほど大きくなるような評価値、あるいは、向上したシステムの性能値が小さく、必要なコストが大きいほど小さくなるような評価値であってもよく、特に限定されない。
拡張性評価値格納部９は、拡張性評価値算出部８が算出した各構成の変更パターンごとの拡張性評価値を格納する。拡張性評価値格納部９が格納する拡張性評価値の例を図１１に示す。
次に、図２のフローチャートを参照して本実施の形態の全体の動作の一例について詳細に説明する。
まず、リクエストモデル入力部２は、リクエストモデルを入力する（図２のステップＳ１）。次に、プランニング部３は、入力されたリクエストモデルをモデル格納部１に格納されているモデルに当てはめ、入力されたリクエストを処理可能なシステム構成から拡張ポイントを決定する（図２のステップＳ２）。さらに、性能算出部４は、その拡張ポイントをモデルに当てはめてシステムの性能を計算する（図２のステップＳ３）。さらに、拡張コスト算出部６は、構成変更コスト格納部５が格納する構成変更コストデータを用いて、拡張されたシステムを生成するために必要なコストを計算する（図２のステップＳ４）。拡張性評価装置１００は、入力されたすべてのリクエストモデルでプランニング部３がプランニングを行なっていない場合には、ステップＳ２からＳ４までのステップを繰り返す（図２のステップＳ５）。プランニング部３が、入力されたすべてのリクエストモデルでプランニングを行った場合には、算出したコストとシステムの性能とに基づいて、拡張性評価値算出部８が拡張性評価値を算出する（図２のステップＳ６）。
次に、本実施の形態の効果について説明する。
本実施の形態における拡張性評価装置１００は、入力されたリクエストモデルに合わせて、システムの拡張ポイントを求めて拡張性を評価する。したがって、本実施の形態における拡張性評価装置１００は、予め拡張ポイントを指定しておくことなく、システムへのリクエストの変動に適合したシステムの拡張性を評価できる。
＜実施形態２＞
次に、本発明の第２の実施の形態について図３を参照して詳細に説明する。
図３を参照すると、本発明の第２の実施の形態における拡張性評価装置１００は、運用サービスレベル格納部１０と、状況別対策レベル格納部１１と、対応知識格納部１２と、状況別リクエストモデル格納部１３と、想定トラフィック合成部１４と、拡張可能性箇所判定部１５と、状況別リクエストモデル選択部１６と、リクエストモデル格納部１７と、拡張ポイントを格納する構成変更データ格納部１８と、を有する点で第一の実施の形態と異なる。
これらの各部について説明する。
運用サービスレベル格納部１０は、モデルに含まれる拡張ポイントごとに、拡張するために必要な運用上の時間（即応レベル）を記述した運用サービスレベルを格納する。運用サービスレベルとは、システム運用で保証されるサービスレベルである。具体的には、図１６に示すように、運用サービスレベル格納部１０は拡張ポイントと即応レベルとを対応付けて記憶する。
状況別対策レベル格納部１１は、非常時におけるシステムへのリクエストの変化などの、短時間におけるリクエストの変化に対して、システムがどの程度の時間で対策すべきかを記述した状況別対策レベルを格納する。具体的には、図１４に示すように、状況別対策レベル格納部１１は、業務内容の変更を伴わないリクエストのトラフィックの変化に対して、トラフィックの種類ごとに、システムが運用上どの程度の時間で対応すべきかの上限時間を表す対応時間を記述した状況別対策レベルを格納する。
対応知識格納部１２は、モデルの拡張可能な拡張ポイントごとに、各拡張ポイントがシステム上で即応可能かどうかを示す対応知識を格納する。具体的には、図１５に示すように、対応知識格納部１２は、モデルの拡張ポイントと、各拡張ポイントがシステム上ですぐに（所定時間以内に）対応できるかどうかの情報（即応性）と、を対応付けて記憶する。
状況別リクエストモデル格納部１３は、業務拡張以外を原因とする短時間におけるリクエストの変化を記述した状況別リクエストを格納する。この短時間におけるリクエストの変化（トラフィックの種類）には、例えば図１２Ａに示すような短時間の間だけリクエスト数が増大する「短時間ピーク」や、急激にリクエスト数が増大しつづける「急増」などがある。図１２に示すように、状況別リクエストモデル格納部１３は、業務内容の変更を伴わないリクエストのトラフィックの変化について、トラフィックの種類ごとに、トラフィックの変化状況を記述した状況別リクエストモデルを格納している。
想定トラフィック合成部１４は、リクエストモデルと状況別リクエストモデルとを合成した合成モデルをつくり、プランニング部３に入力する。具体的には、想定トラフィック合成部１４は、リクエストモデル中のどの期間（図９の例ではＣａｓｅ１、Ｃａｓｅ２、Ｃａｓｅ３のどのケース）に状況別リクエストが発生するかをユーザから入力して、その期間のトラフィックを合成する。この具体例は後述する。
拡張可能性箇所判定部１５は、状況別リクエストに応じた運用サービスレベル情報（図１６）、対応時間情報（図１４）、対応知識情報（図１５）に基づき、モデルに含まれる拡張ポイントを判定する。具体的には、拡張可能性箇所判定部１５は、状況別リクエストモデルにおけるトラフィックの種類に対応する対応時間を状況別対策レベル格納部１１（図１４）から抽出し、その対応時間以内で対応可能な拡張ポイントを図１５に示す対応知識情報または図１６に示す運用サービスレベル情報の少なくとも一方から決定する。例えば、拡張可能性箇所判定部１５が運用サービスレベルを用いて拡張ポイントの候補を決定する例について説明する。状況別リクエストモデルにおけるトラフィックの種類が「短時間ピーク」である場合、対応時間は「１時間以内」であり（図１４）、ＶＭの即応レベルが「即座」であるため（図１６）、ＶＭ数の変更は１時間以内で対応可能であることが分かる。そこで、拡張可能性箇所判定部１５は、拡張ポイントをＶＭと決定する。拡張可能性箇所判定部１５は、対応可能な拡張ポイントが複数ある場合には、それらを実際に拡張する拡張ポイントの候補として決定する。
状況別リクエストモデル選択部１６は、状況別リクエストモデル格納部１３に格納された状況別リクエストモデルのうち、プランニング部３がプランニングに利用する状況別リクエストモデルを１つ以上選択する。状況別リクエストモデル選択部１６は、システムに対するリクエストを予測して状況別リクエストモデルを自動的に選択しても良いし、ユーザが状況別リクエストモデルを直接選択しても良い。
リクエストモデル格納部１７は、業務内容の変更やサービスの成長に合わせて想定されるリクエストの時間変化を表したリクエストモデルを格納する。リクエストモデルについては実施形態１で述べたので詳細説明は省略する。
他の構成については第１の実施の形態と概略同様であるため詳細説明を省略するが、概略を述べると以下のようになる。第２の実施の形態における拡張性評価装置１００では、プランニング部３は、システムが想定トラフィックを処理できるようにモデルの拡張ポイントを決定する。性能算出部４は、拡張ポイントを反映したモデルの性能を算出する。拡張コスト算出部６は、拡張ポイントと構成変更コストとを用いて拡張コストを算出する。拡張性評価値算出部８は、性能と拡張コストから拡張性評価値を算出する。拡張性評価値格納部９は、算出した拡張性を格納する。
次に、図４のフローチャートを用いて、本実施の形態の全体の動作の一例について詳細に説明する。
まず、図示しないリクエストモデル入力部２は、リクエストモデルを入力する（図４のステップＳ１）。次に、状況別リクエストモデル選択部１６は、状況別リクエストモデルを状況別リクエストモデル格納部１３から選択する（図４のステップＳ２）。次に、拡張性可能箇所判断部１５は、状況別対策レベル格納部１１から、前記状況別リクエストモデルに対応した状況別対策レベルを抽出する（図４のステップＳ３）。また、拡張性可能箇所判断部１５は、運用サービスレベル格納部１０から、前記状況別リクエストモデルに対応した運用サービスレベルを抽出する（図４のステップＳ４）。また、拡張可能箇所判断部１５は、対応知識格納部１２から、前記状況別リクエストモデルに対応した対応知識を抽出する（図４のステップＳ５）。そして、拡張可能箇所判定部１５は、前記状況別対策レベルの対応時間（図１４）と、前記運用サービスレベルの即応レベル（図１６）と、前記対応知識の即応性（図１５）とに基づき、対応時間以内に対応可能な拡張ポイントを抽出し、モデル中の拡張ポイントの候補を特定する（図４のステップＳ６）。さらに、想定トラフィック合成部１４は、選択された状況別リクエストモデルをリクエストモデルと合成する（図４のステップＳ７）。さらに、プランニング部３は、拡張可能箇所判定部１５で抽出した拡張ポイントから、前記合成されたリクエストモデルの条件を満たすように拡張ポイントを決定し、構成変更データとして構成変更データ格納部１８に格納するとともに、その構成の最大処理能力を計算する（図４のステップＳ８）。さらに、拡張コスト算出部６は、生成されたシステム構成と構成変更コストデータを用いて、拡張されたシステムを生成（もとのシステムを変更）するために必要なコストを計算する（図４のステップＳ９）。拡張性評価装置１００は、入力されたすべてのリクエストモデルでプランニング部３がプランニングしていない場合には、図４のステップＳ８からステップＳ９までを繰り返す（図４のステップＳ１０）。プランニング部３がすべてのリクエストモデルでプランニングしている場合には、算出したコストと性能とをもとに、拡張性評価値を拡張性評価値算出部８で計算して、状況別拡張性評価データとして拡張性評価値格納部９に格納する（図４のステップＳ１１）。
次に、本実施の形態の動作についてより具体的な説明をする。
図８に示すように、モデル格納部１には、システムの構成と、その構成を拡張可能なポイントや動作が、モデルとして記述されたモデル情報が格納されている。図８を用いて、本モデルの拡張性を評価する具体例を説明する。本モデルでは、例えばアプリケーションサーバ内にＶＭが配置されていることを表しており、その台数が１台から３台の間で可変であることを表している。次にリクエストモデル入力部２により、図９に示すリクエストモデルが与えられる。図９では、リクエストモデルが、Ｃａｓｅ１、Ｃａｓｅ２、Ｃａｓｅ３の時間順で変化することを示しており、それぞれの場合のリクエストの想定到着率、リクエストに含まれるデータ量、データの書き込み／読み込み比率が与えられている。次に状況別リクエストモデル選択部１６により、図１２Ｂに示す状況別リクエストモデルが与えられる。本実施例では図１２Ｂに示すトラフィックの種類が「短時間ピーク」の想定到着率である場合を説明する。ユーザは、リクエストモデル中、どの期間に状況別リクエストが発生するかを指定する。該指定を入力して想定トラフィック合成部１４がトラフィックを合成する。本実施の形態では、想定トラフィック合成部１４は、状況別リクエストモデルをリクエストモデルのＣａｓｅ２に合成する場合を例に説明する。この場合、想定トラフィック合成部１４が合成した結果のリクエストモデルは、図１７が示すように、Ｃａｓｅ２の想定到着率が、状況別リクエストの想定到着率９０％となる点で図９のリクエストモデルと異なる。次に、拡張可能箇所判断部１５は、状況別対策レベル（図１４参照）からモデル中の拡張可能な拡張ポイントを限定する。本実施形態では、状況別リクエストモデルはトラフィックの種類が「短時間ピーク」である。そのため、拡張可能性箇所判定部１５は、図１４に示す状況別対策レベルから、短時間ピークの状況別リクエストモデルに対応する対応時間（１時間以内）を抽出する。この対応時間以内で対応可能なシステムを、例えば運用サービスレベル（図１６）から求めると、ＶＭの即応レベルが「即座」であるため、ＶＭ台数は１時間以内で対応可能なことが分かる。そこで、Ｃａｓｅ２のプランニングでは、プランニング部３は、このＶＭ台数に拡張ポイントを限定してプランニングを実施する。Ｃａｓｅ１、Ｃａｓｅ２、Ｃａｓｅ３のそれぞれの期間ごとのプランニング結果を図１０の拡張ポイント列に示す。図１０のプランニング結果によれば、Ｃａｓｅ１のリクエストを満たすためにＣＰＵ台数が１である必要があり、Ｃａｓｅ２では、拡張ポイントであるＶＭ台数を＋１、すなわち１台増やす必要があることがわかる。拡張コスト算出部６は、このプランニング結果から拡張に必要なコストを構成変更コスト格納部５を参照して計算する。また、性能算出部４は、その拡張をシステムに当てはめた場合のシステムの性能を計算する。次に拡張性評価値算出部８は、拡張性評価値を、例えば拡張性評価値＝（向上した性能／コスト）により計算する。計算された拡張性評価値の例を図１１に示す。図１１では、Ｃａｓｅ１からＣａｓｅ２、Ｃａｓｅ２からＣａｓｅ３、Ｃａｓｅ１からＣａｓｅ３の３つのパターンの拡張性評価値が示されている。本例では、拡張性評価装置１００は、Ｃａｓｅ１からＣａｓｅ３への拡張が最も拡張性が高いと評価し、その結果を出力する。
次に、本実施の形態の効果について説明する。
本実施の形態における拡張性評価装置１００は、状況別リクエストに対応可能なモデルの構成要素を、状況別対策レベルと、運用サービスレベルと、対策知識とから限定し、状況別リクエストモデルとリクエストモデルとを合成したトラフィックをもとに、モデルをプランニングして拡張性評価値を算出する。そのため、本実施の形態における拡張性評価装置１００は、通常のシステム拡張だけでなく突発的なリクエスト変動であっても、リクエスト変動に適合したシステムの拡張性を評価できる。
＜実施形態３＞
次に、本発明の第３の実施の形態について図５を参照して詳細に説明する。
図５を参照すると、本発明の第３の実施の形態は、本発明の第２の実施の形態における状況別リクエストモデル格納部１３の代わりにリクエストモデル変動知識格納部２３を備え、状況別リクエストモデル選択部１６の代わりにリクエストモデル変動判定部２６を備える。他の各部については第１あるいは第２の実施の形態と同様であるから詳細説明を省略する。
上述の各部を説明する。
リクエストモデル変動知識格納部２３は、リクエストの増加率や増加継続時間などのリクエストの変化をもとにリクエストの状況を判定するための知識であるリクエストモデル変動知識を格納する。リクエストモデル変動知識格納部２３が格納するリクエストモデル変動知識の例を図１３に示す。
リクエストモデル変動知識格納部２３は、例えば、図１３のように、リクエスト到着率の変化率が３以上であり、そのピークの維持時間が２時間以内である状況と、リクエストの状況「短時間ピーク」とを対応付けて格納する。
リクエストモデル変動判定部２６は、入力されたリクエストモデルに対し、リクエストモデル変動知識格納部２３が格納しているリクエストモデル変動知識に基づいて、リクエストモデルの変化状況（時間変化状況）を判定する。
次に、図５及び図６のフローチャートを参照して本実施の形態の全体の動作の一例について詳細に説明する。
まず、図示しないリクエストモデル入力部２は、リクエストモデルを入力する（図６のステップＳ１）。次に、リクエストモデル変動判定部２６は、リクエストモデル変動知識格納部２３が格納するリクエスト変動知識を参照して、入力されたリクエストモデルの変動の状況を判定する（図６のステップＳ２）。拡張可能箇所判断部１５は、リクエストモデル変動判定部２６が判定したリクエストモデルの状況に合わせて状況別対策レベル格納部１１から状況別対策レベルの対応時間を抽出する（図６のステップＳ３）。また、拡張可能箇所判断部１５は、リクエストモデルの状況に合わせて、運用サービスレベル格納部１０から運用サービスレベルの即応レベルを抽出する（図６のステップＳ４）。また、拡張可能箇所判断部１５は、リクエストモデルの状況に合わせて、対応知識格納部１２から対応知識の即応性を抽出する（図６のステップＳ５）。そして、拡張可能性箇所判定部１５は、状況別対策レベルの対応時間（図１４参照）、運用サービスレベルの即応レベル（図１６参照）あるいは対応知識の即応性（図１５参照）から、対応時間内に対応可能な拡張ポイントの候補を抽出し、モデル中の拡張ポイントの候補を特定する（図６のステップＳ６）。さらに、プランニング部３は、拡張可能箇所判定部１５で抽出した拡張ポイントの候補の中から、リクエストモデルを満たすような拡張ポイントを決定し、構成変更データとして構成変更データ格納部１８に格納し、その構成の最大処理能力を計算する（図６のステップＳ７）。さらに、拡張コスト算出部６は、生成されたシステム構成と構成変更コストデータを用いてシステムを構築または変更するために必要なコストを計算する（図６のステップＳ８）。拡張性評価装置１００は、プランニング部３が、入力されたすべてのリクエストモデルでプランニングしていない場合は、ステップＳ７からステップＳ８までを繰り返す（図６のステップＳ９）。プランニング部３が、入力されたすべてのリクエストモデルでプランニングした場合は、拡張性評価値算出部８は、構成変更データと構成変更コストをもとに拡張性評価値を計算し、状況別拡張性評価データとして、拡張性評価値格納部９に格納する（図４のステップＳ１０）。
次に、本実施の形態の効果について説明する。
本実施の形態における拡張性評価装置１００は、リクエスト変動知識をもとに状況別のリクエストモデルの変化を判定し、その状況別リクエストに対応可能なモデル上の構成要素を限定し、そのうえでリクエストモデルを満たすようにシステム拡張を決定し、拡張性を評価する。そのため、本実施の形態における拡張性評価装置１００は、システムへのリクエストの変動に適合したシステムの拡張性を評価できる。
＜実施形態４＞
次に、本発明の第４の実施の形態について説明する。
図１８は、本発明の第４の実施の形態の構成を示す図である。図１８を参照すると、本発明の第４の実施の形態における拡張性評価装置１００は、プランニング部３と、性能算出部４と、拡張コスト算出部６と、からなる。これらの構成、動作については第１の実施の形態と同様であるから詳細説明を省略する。
この構成により、入力されたリクエストモデルの条件を満たすように、システムの構成の拡張ポイントを決定するプランニング手段と、システムの構成の変更に要する拡張コストを前記拡張ポイントについて計算して出力する拡張コスト算出手段と、プランニング手段が決定した拡張ポイントが変更された場合のシステムの性能値を計算して出力する性能算出手段と、を備える拡張性評価装置が提供される。
本実施の形態における拡張性評価装置１００によれば、システムへのリクエストの変動に基づいた拡張性を評価できる、拡張性評価装置、拡張性評価方法および拡張性評価用プログラムが提供される。
以上、実施形態を参照して本願発明を説明したが、本願発明は上記実施形態に限定されるものではない。本願発明の構成や詳細には、本願発明のスコープ内で当業者が理解しうる様々な変更をすることができる。
この出願は、２０１０年８月１８日に出願された日本出願特願２０１０−１８３３２０を基礎とする優先権を主張し、その開示の全てをここに取り込む。
１ モデル格納部
２ リクエストモデル入力部
３ プランニング部
４ 性能算出部
５ 構成変更コスト格納部
６ 拡張コスト算出部
７ コスト／性能データ格納部
８ 拡張性評価値算出部
９ 拡張性評価値格納部
１０ 運用サービスレベル格納部
１１ 状況別対策レベル格納部
１２ 対応知識格納部
１３ 状況別リクエストモデル格納部
１４ 想定トラフィック合成部
１５ 拡張可能性箇所判定部
１６ 状況別リクエストモデル選択部
１７ リクエストモデル格納部
１８ 構成変更データ格納部
２３ リクエストモデル変動知識格納部
２６ リクエストモデル変動判定部
１００ 拡張性評価装置
２ リクエストモデル入力部
３ プランニング部
４ 性能算出部
５ 構成変更コスト格納部
６ 拡張コスト算出部
７ コスト／性能データ格納部
８ 拡張性評価値算出部
９ 拡張性評価値格納部
１０ 運用サービスレベル格納部
１１ 状況別対策レベル格納部
１２ 対応知識格納部
１３ 状況別リクエストモデル格納部
１４ 想定トラフィック合成部
１５ 拡張可能性箇所判定部
１６ 状況別リクエストモデル選択部
１７ リクエストモデル格納部
１８ 構成変更データ格納部
２３ リクエストモデル変動知識格納部
２６ リクエストモデル変動判定部
１００ 拡張性評価装置
Claims (10)
- システムへのリクエストの変化予測情報（リクエストモデル）を入力し、前記リクエストモデルの期間ごとの条件を満たす前記システムの構成（拡張ポイント）を所定の規則に基づき変更するプランニング手段と、
前記拡張ポイントの変更に要するコスト（拡張コスト）を計算して出力する拡張コスト算出手段と、
前記プランニング手段によって前記拡張ポイントが変更された場合のシステムの性能を表す値（性能値）を計算して出力する性能算出手段と、
を備える拡張性評価装置。 - 前記システムに対するリクエストの第２の条件と前記リクエストモデル内の１つの期間とを入力し、前記リクエストモデルの前記入力された期間における条件を前記第２の条件に置き換えた合成モデルを出力する想定トラフィック合成手段と、
前記合成モデルによって定まるリクエストモデルの期間ごとの条件を満たす前記拡張ポイントを変更する前記プランニング手段と、
を備える請求項１に記載の拡張性評価装置。 - 前記第２の条件と対応付けられたリクエストモデルのトラフィックの種類と、そのトラフィックの種類に対してシステムが対応するまでの上限時間（対応時間）と、を対応付けて記憶する状況別対策レベル格納手段と、
拡張ポイントと、拡張ポイントの変更に要する時間（即応レベル）と、を対応付けて記憶する運用サービスレベル格納手段と、
前記トラフィックの種類に基づいて、前記対応時間と前記即応レベルとを参照し、前記対応時間以内で変更できる構成の変更箇所を前記拡張ポイントの候補として前記運用サービスレベル格納手段から抽出する拡張可能箇所判定手段と、
をさらに備える請求項２に記載の拡張性評価装置。 - 前記トラフィックの種類と前記リクエストモデルの条件の変化量とを対応付けて記憶するリクエストモデル変動知識格納手段と、
前記リクエストモデル変動知識格納手段を参照して、前記入力されたリクエストモデルの条件の変化量から、トラフィックの種類を判定するリクエストモデル変動判定手段と、
をさらに備え、
前記拡張可能箇所判定手段は、判定された前記リクエストモデルのトラフィックの種類に基づいて、前記対応時間と前記即応レベルとを参照し、前記対応時間以内で変更できる変更箇所を拡張ポイントの候補として前記運用サービスレベル格納手段から抽出する請求項３記載の拡張性評価装置。 - システムへのリクエストの変化予測情報（リクエストモデル）を入力し、前記リクエストモデルの期間ごとの条件を満たす前記システムの構成（拡張ポイント）を所定の規則に基づき変更するプランニングステップと、
前記拡張ポイントの変更に要するコスト（拡張コスト）を計算して出力する拡張コスト算出ステップと、
前記拡張ポイントが変更された場合のシステムの性能を表す値（性能値）を計算して出力する性能算出ステップと、
をコンピュータに実行させる拡張性評価プログラム。 - 前記システムに対するリクエストの第２の条件と前記リクエストモデル内の１つの期間とを入力し、前記リクエストモデルの前記入力された期間における条件を前記第２の条件に置き換えた合成モデルを出力する想定トラフィック合成ステップと、
前記合成モデルによって定まるリクエストモデルの期間ごとの条件を満たす前記拡張ポイントを変更する前記プランニングステップと、
をコンピュータに実行させる請求項５に記載の拡張性評価プログラム。 - 前記状況別リクエストモデルのトラフィックの種類とそのトラフィックの種類に対してシステムが対応するまでの上限時間（対応時間）とを対応付けて記憶する状況別対策レベル格納手段と、拡張ポイントと拡張ポイントの変更に要する時間（即応レベル）とを対応付けて記憶する運用サービスレベル格納手段と、から、前記第２の条件と対応付けられたリクエストモデルのトラフィックの種類に基づいて前記対応時間と前記即応レベルとを参照し、前記対応時間以内で変更できる構成の変更箇所を前記拡張ポイントの候補として前記運用サービスレベル格納手段から抽出する拡張可能箇所判定ステップを、
さらにコンピュータに実行させる請求項６に記載の拡張性評価プログラム。 - 前記トラフィックの種類と前記リクエストモデルの条件の変化量とを対応付けて記憶するリクエストモデル変動知識格納手段を参照して、前記入力されたリクエストモデルの条件の変化量から、トラフィックの種類を判定するリクエストモデル変動判定ステップと、
判定された前記リクエストモデルのトラフィックの種類に基づいて、前記対応時間と前記即応レベルとを参照し、前記対応時間以内で変更できる変更箇所を拡張ポイントの候補として前記運用サービスレベル格納手段から抽出する前記拡張可能箇所判定ステップと、
をコンピュータに実行させる請求項７記載の拡張性評価プログラム。 - システムへのリクエストの変化予測情報（リクエストモデル）を入力し、前記リクエストモデルの期間ごとの条件を満たす前記システムの構成（拡張ポイント）を所定の規則に基づき変更し、
前記拡張ポイントの変更に要するコスト（拡張コスト）を計算して出力し、
前記拡張ポイントが変更された場合のシステムの性能を表す値（性能値）を計算して出力する拡張性評価方法。 - 前記システムに対するリクエストの第２の条件と前記リクエストモデル内の１つの期間とを入力し、前記リクエストモデルの前記入力された期間における条件を前記第２の条件に置き換えた合成モデルを出力し、
前記合成モデルによって定まるリクエストモデルの期間ごとの条件を満たす前記拡張ポイントを変更する請求項９に記載の拡張性評価方法。
Applications Claiming Priority (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2010183320 | 2010-08-18 | ||
| JP2010183320 | 2010-08-18 | ||
| PCT/JP2011/068817 WO2012023625A1 (ja) | 2010-08-18 | 2011-08-16 | 拡張性評価装置、拡張性評価方法および拡張性評価プログラム |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JPWO2012023625A1 true JPWO2012023625A1 (ja) | 2013-10-28 |
| JP5910499B2 JP5910499B2 (ja) | 2016-04-27 |
Family
ID=45605276
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2012529637A Active JP5910499B2 (ja) | 2010-08-18 | 2011-08-16 | 拡張性評価装置、拡張性評価方法および拡張性評価プログラム |
Country Status (3)
| Country | Link |
|---|---|
| US (1) | US20130144587A1 (ja) |
| JP (1) | JP5910499B2 (ja) |
| WO (1) | WO2012023625A1 (ja) |
Families Citing this family (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20150248507A1 (en) * | 2012-10-02 | 2015-09-03 | Nec Corporation | Information system construction support device, information system construction support method, and storage medium |
| US20150248508A1 (en) * | 2012-10-02 | 2015-09-03 | Nec Corporation | Information system construction device, information system construction method, and storage medium |
| US9274817B1 (en) * | 2012-12-31 | 2016-03-01 | Emc Corporation | Storage quality-of-service control in distributed virtual infrastructure |
| WO2015145677A1 (ja) * | 2014-03-27 | 2015-10-01 | 株式会社日立製作所 | 管理計算機及びプラットフォーム改善方法 |
| US9940033B1 (en) * | 2015-12-30 | 2018-04-10 | EMC IP Holding Company LLC | Method, system and computer readable medium for controlling performance of storage pools |
| JP2019117605A (ja) * | 2017-12-27 | 2019-07-18 | 富士通株式会社 | 情報処理装置、情報処理システム及び情報処理方法 |
Family Cites Families (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP3690721B2 (ja) * | 1999-10-25 | 2005-08-31 | 株式会社日立製作所 | システム性能見積システム及びシステム性能見積方法 |
| JP2002183416A (ja) * | 2000-12-15 | 2002-06-28 | Hitachi Ltd | システム提案方法及びその実施装置並びにその処理プログラムを記録した記録媒体 |
| US20030158765A1 (en) * | 2002-02-11 | 2003-08-21 | Alex Ngi | Method and apparatus for integrated network planning and business modeling |
| JP4592325B2 (ja) * | 2004-04-28 | 2010-12-01 | 株式会社東芝 | Ｉｔシステムの設計支援システムおよび設計支援方法 |
-
2011
- 2011-08-16 JP JP2012529637A patent/JP5910499B2/ja active Active
- 2011-08-16 WO PCT/JP2011/068817 patent/WO2012023625A1/ja active Application Filing
- 2011-08-16 US US13/816,994 patent/US20130144587A1/en not_active Abandoned
Also Published As
| Publication number | Publication date |
|---|---|
| US20130144587A1 (en) | 2013-06-06 |
| JP5910499B2 (ja) | 2016-04-27 |
| WO2012023625A1 (ja) | 2012-02-23 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP5910499B2 (ja) | 拡張性評価装置、拡張性評価方法および拡張性評価プログラム | |
| JP5571518B2 (ja) | コンピュータによって実施される方法、コンピュータ可読媒体、動的に再構成可能な最適化集積回路 | |
| JP2014513494A (ja) | ポータブルコンピューティングデバイスのスイッチファブリック内およびスイッチファブリック間でマスタースレーブペアを動的に作成しサービスするための方法およびシステム | |
| JP6222225B2 (ja) | 仮想マシン配置決定装置、仮想マシン配置決定方法および仮想マシン配置決定プログラム | |
| US20210174189A1 (en) | Optimization Framework for Real-Time Rendering of Media Using Machine Learning Techniques | |
| WO2018143019A1 (ja) | 情報処理装置、情報処理方法およびプログラム記録媒体 | |
| JP2017146888A (ja) | 設計支援装置及び方法及びプログラム | |
| JP2008250721A (ja) | モデル生成方法及びモデル生成装置 | |
| JP2011192049A (ja) | 仮想マシンシステム、自動マイグレーション方法および自動マイグレーションプログラム | |
| WO2016017111A1 (ja) | 情報処理システム及びシステム設計方法 | |
| US20120204181A1 (en) | Reconfigurable device, processing assignment method, processing arrangement method, information processing apparatus, and control method therefor | |
| Zareian et al. | K-Feed-a data-oriented approach to application performance management in cloud | |
| JP6016128B2 (ja) | 可用性モデル生成支援装置、可用性モデル生成支援方法、およびプログラム | |
| JP2011222020A (ja) | ソフトウェアシステムの自律管理提供方法、これを実行するプログラムを記録した記録媒体及びソフトウェアの自律管理機能を備えたシステム | |
| JP2023505783A (ja) | Ｇｐｕパケット集約システム | |
| JP2023508591A (ja) | クラウド・テナントのオンボード／オフボードの間の外部システムのためのスケーリング計画の生成 | |
| US20210089360A1 (en) | Hardware and software resource optimization | |
| JP6065843B2 (ja) | サービスレベル管理装置、プログラム、及び、方法 | |
| CN111506414A (zh) | 资源调度方法、装置、设备、系统及可读存储介质 | |
| JP2016018269A (ja) | 情報処理装置、情報処理方法及びプログラム | |
| JP5871018B2 (ja) | 性能予測装置、性能モデル生成方法およびプログラム | |
| JP6226895B2 (ja) | ネットワーク評価システム及びネットワーク評価方法 | |
| JP6726312B2 (ja) | シミュレーション方法、システム、及びプログラム | |
| JP2004272582A (ja) | 計算機システムの性能予測プログラムおよび設計支援システム | |
| JP7332425B2 (ja) | 計算機システム |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20140716 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20150929 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20151119 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20160301 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20160314 |
|
| R150 | Certificate of patent or registration of utility model |
Ref document number: 5910499 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 |