特開 2025-8611 計算機システムおよびパラメータの決定方法

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】公開特許公報(A)

(11)【公開番号】P2025008611

(43)【公開日】2025-01-20

(54)【発明の名称】計算機システムおよびパラメータの決定方法

(51)【国際特許分類】

   G06F 9/50 20060101AFI20250109BHJP

   G06F 11/34 20060101ALI20250109BHJP

   G06F 11/30 20060101ALI20250109BHJP

【ＦＩ】

G06F9/50 150D

G06F11/34 133

G06F11/30 140A

【審査請求】未請求

【請求項の数】11

【出願形態】ＯＬ

(21)【出願番号】P 2023110923

(22)【出願日】2023-07-05

(71)【出願人】

【識別番号】000005108

【氏名又は名称】株式会社日立製作所

(74)【代理人】

【識別番号】110001678

【氏名又は名称】藤央弁理士法人

(72)【発明者】

【氏名】郡浦 宏明

(72)【発明者】

【氏名】大久保 敬子

(72)【発明者】

【氏名】宮田 辰彦

(72)【発明者】

【氏名】米山 元樹

(72)【発明者】

【氏名】藤木 伸浩

【テーマコード（参考）】

5B042

【Ｆターム（参考）】

5B042HH07

5B042KK17

5B042MA08

5B042MC22

5B042MC40

(57)【要約】

【課題】イベント駆動型分散アプリケーションを実行するためのリソースのスケーリングを制御する判定用メトリクスの閾値を決定する。
【解決手段】計算機システムは、インスタンスを提供する実行環境システム、およびインスタンスのスケーリングを制御するオートスケーリングシステムと接続する。実行環境システムでは、インスタンスを用いて、同じサービスを提供するアプリケーションが複数実行される。計算機システムは、対象アプリケーションの処理の実行ログを取得し、実行ログを用いて負荷パターンを生成し、負荷パターンに基づいて、スケーリングの実行を制御するための判定用メトリクスの閾値を設定し、対象アプリケーションの処理およびスケーリングをシミュレーションするシミュレーション処理を複数回実行し、シミュレーション処理の結果に基づいて、判定用メトリクスの閾値を決定する。
【選択図】図３

【特許請求の範囲】

【請求項1】

計算機システムであって、
プロセッサ、前記プロセッサに接続されるメモリ、および前記プロセッサに接続されるネットワークインタフェースを備え、
インスタンスを提供する実行環境システム、および前記インスタンスのスケーリングを制御するオートスケーリングシステムと接続し、
前記実行環境システムでは、前記インスタンスを用いて、同じサービスを提供するアプリケーションが複数実行され、
前記アプリケーションは、複数のイベント駆動型のイベント処理を含み、
前記プロセッサは、
対象アプリケーションの処理の実行ログを取得し、
前記実行ログを用いて、前記対象アプリケーションにおける前記イベント処理の処理フロー、および前記処理フローが処理するリクエスト数の時間推移の組みを一つ以上含む負荷パターンを生成し、
前記負荷パターンに基づいて、前記スケーリングの実行を制御するための判定用メトリクスの閾値を設定し、前記対象アプリケーションの処理および前記スケーリングをシミュレーションするシミュレーション処理を複数回実行し、
前記シミュレーション処理の結果に基づいて、前記判定用メトリクスの閾値を決定することを特徴とする計算機システム。

【請求項2】

請求項１に記載の計算機システムであって、
前記プロセッサは、
前記実行ログに基づいて、複数の前記処理フローを生成し、
前記実行ログに基づいて、前記対象アプリケーションが処理するリクエスト処理数の時間推移を算出し、
前記実行ログに基づいて、複数の前記処理フローの各々について、前記処理フローにおける前記イベント処理間の遷移確率を算出し、
複数の前記処理フローの各々について、前記処理フローにおける前記イベント処理間の遷移確率に基づいて、発生頻度を算出し、
複数の前記処理フローの各々の発生頻度に基づいて、前記対象アプリケーションが処理するリクエスト処理数の時間推移における各時間のリクエスト処理数を分配することによって、複数の前記処理フローの各々が処理するリクエストの数の時間推移を算出することを特徴とする計算機システム。

【請求項3】

請求項２に記載の計算機システムであって、
前記プロセッサは、サービスレベルおよび運用方針を定義した運用プランを満たすように前記判定用メトリクスの閾値を決定することを特徴とする計算機システム。

【請求項4】

請求項２に記載の計算機システムであって、
前記プロセッサは、前記負荷パターンおよび前記判定用メトリクスの閾値に基づいて、前記インスタンスの数を設定して、前記対象アプリケーションの処理をシミュレーションするシミュレーション処理を複数回実行することによって、前記インスタンスの最大数および最小数を決定することを特徴とする計算機システム。

【請求項5】

請求項２に記載の計算機システムであって、
前記プロセッサは、前記負荷パターン、前記シミュレーションの結果、および前記判定用メトリクスの閾値を表示するため表示情報を生成することを特徴とする計算機システム。

【請求項6】

計算機システムが実行するオートスケーリングを制御するためのパラメータの決定方法であって、
前記計算機システムは、
プロセッサ、前記プロセッサに接続されるメモリ、および前記プロセッサに接続されるネットワークインタフェースを備え、
インスタンスを提供する実行環境システム、および前記インスタンスのスケーリングを制御するオートスケーリングシステムと接続し、
前記実行環境システムでは、前記インスタンスを用いて、同じサービスを提供するアプリケーションが複数実行され、
前記アプリケーションは、複数のイベント駆動型のイベント処理を含み、
前記パラメータの決定方法は、
前記プロセッサが、対象アプリケーションの処理の実行ログを取得し、前記メモリに格納する第１のステップと、
前記プロセッサが、前記実行ログを用いて、前記対象アプリケーションにおける前記イベント処理の処理フロー、および前記処理フローが処理するリクエスト数の時間推移の組みを一つ以上含む負荷パターンを生成し、前記メモリに格納する第２のステップと、
前記プロセッサが、前記負荷パターンに基づいて、前記スケーリングの実行を制御するための判定用メトリクスの閾値を設定し、前記対象アプリケーションの処理および前記スケーリングをシミュレーションするシミュレーション処理を複数回実行する第３のステップと、
前記プロセッサが、前記シミュレーション処理の結果に基づいて、前記判定用メトリクスの閾値を決定し、前記メモリに格納する第４のステップと、
を含むことを特徴とするパラメータの決定方法。

【請求項7】

請求項６に記載のパラメータの決定方法であって、
前記第２のステップは、
前記プロセッサが、前記実行ログに基づいて、複数の前記処理フローを生成するステップと、
前記プロセッサが、前記実行ログに基づいて、前記対象アプリケーションが処理するリクエスト処理数の時間推移を算出するステップと、
前記プロセッサが、前記実行ログに基づいて、複数の前記処理フローの各々について、前記処理フローにおける前記イベント処理間の遷移確率を算出するステップと、
前記プロセッサが、複数の前記処理フローの各々について、前記処理フローにおける前記イベント処理間の遷移確率に基づいて、発生頻度を算出するステップと、
前記プロセッサが、複数の前記処理フローの各々の発生頻度に基づいて、前記対象アプリケーションが処理するリクエスト処理数の時間推移における各時間のリクエスト処理数を分配することによって、複数の前記処理フローの各々が処理するリクエストの数の時間推移を算出するステップと、を含むことを特徴とするパラメータの決定方法。

【請求項8】

請求項７に記載のパラメータの決定方法であって、
前記第４のステップは、前記プロセッサが、サービスレベルおよび運用方針を定義した運用プランを満たすように前記判定用メトリクスの閾値を決定するステップを含むことを特徴とするパラメータの決定方法。

【請求項9】

請求項７に記載のパラメータの決定方法であって、
前記プロセッサが、前記負荷パターンおよび前記判定用メトリクスの閾値に基づいて、前記インスタンスの数を設定して、前記対象アプリケーションの処理をシミュレーションするシミュレーション処理を複数回実行することによって、前記インスタンスの最大数および最小数を決定するステップを含むことを特徴とするパラメータの決定方法。

【請求項10】

請求項７に記載のパラメータの決定方法であって、
前記プロセッサが、前記負荷パターン、前記シミュレーションの結果、および前記判定用メトリクスの閾値を表示するため表示情報を生成するステップを含むことを特徴とするパラメータの決定方法。

【請求項11】

インスタンスを提供する実行環境システム、前記インスタンスのスケーリングを制御するオートスケーリングシステム、および前記スケーリングを制御するための判定用メトリクスの閾値を決定する評価システムを備える計算機システムであって、
前記実行環境システムでは、前記インスタンスを用いて、同じサービスを提供するアプリケーションが複数実行され、
前記アプリケーションは、複数のイベント駆動型のイベント処理を含み、
前記評価システムは、
前記実行環境システムから、対象アプリケーションの処理の実行ログを取得し、
前記実行ログを用いて、前記対象アプリケーションにおける前記イベント処理の処理フロー、および前記処理フローが処理するリクエスト数の時間推移の組みを一つ以上含む負荷パターンを生成し、
前記負荷パターンに基づいて、前記判定用メトリクスの閾値を設定し、前記対象アプリケーションの処理および前記スケーリングをシミュレーションするシミュレーション処理を複数回実行し、
前記シミュレーション処理の結果に基づいて、前記判定用メトリクスの閾値を決定し、前記オートスケーリングシステムに送信することを特徴とする計算機システム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、イベント駆動型分散アプリケーションを実行するためのリソースのオートスケーリング技術に関する。

【背景技術】

【0002】

クラウド環境等で各種アプリケーションサービスを展開するにあたり、複数のサーバに配置されたコンテナの運用負荷を低減するためのＫｕｂｅｒｎｅｔｅｓ（ｋ８ｓ）やＡｍａｚｏｎ ＥＣＳ（Ｅｌａｓｔｉｃ Ｃｏｎｔａｉｎｅｒ Ｓｅｒｖｉｃｅ）など、オーケストレーションツールおよびサービスの活用が進んでいる。

【0003】

オーケストレーションツールの主要機能の一つとして、リソースのオートスケーリング機能がある。オートスケーリング機能では、アプリケーションが使用するリソースの負荷状況を示す判定用メトリクスの監視、判定用メトリクスがスケーリング基準値（閾値）を超えた場合にリソースの動的な追加、アプリケーションの処理スループットを高め、判定用メトリクスが閾値を下回った場合のリソースの停止が行われる。リソースの追加によってアプリケーションの処理スループットを高めることができ、また、リソースの停止によってリソース使用量を抑えることができる。たとえば、クラウドのマネージドコンテナサービスなど、リソースを常時起動していると従量課金額が高くなるようなサービス利用では、オートスケーリング機能の利用が推奨される。

【0004】

業務ロジックをアプリケーションに落とし込むとき、１件のリクエストに対して異なる処理を呼び出すイベントが発生し、イベント駆動で並列分散処理を実行するケースがある。このようなケースでは、あるイベントに対応する処理が別のイベントに対応する処理を待ったり、別のイベントを生成するなど、複雑な並列分散処理を含んだアプリケーションとなる。以降、前述の性質を持つアプリケーションを、イベント駆動型分散アプリケーションと記載する。

【0005】

オートスケーリングに用いる判定用メトリクスの変動を捉えて評価し、リソースをオートスケーリングする技術として、特許文献１、２に記載の技術が知られている。

【0006】

特許文献１は、課金の効率がよいシステムの運用が可能となる技術を提供することを課題とする。要求された処理を複数のコンピュータノードに分散して実行するシステムにおいて、該システムで実行するタスクの管理を行うコンピュータノードが、納期が指定された処理要求を受け付けた際に、記憶部に記憶された、前記システムが備えるコンピュータノードが実行するタスクを管理する管理情報を参照して、該処理要求のタスクをコンピュータノードに割り当てるシミュレーションを実行し、前記割り当てのシミュレーションにより、前記処理要求のタスクを納期内に処理終了可能なコンピュータノードがなく、さらに他のコンピュータノードでも納期内に処理終了可能なタスクを移動しても前記処理要求のタスクを納期内に処理終了可能なコンピュータノードを用意できないと判定された場合に、前記システムにコンピュータノードを増設する処理を実行することを特徴とするオートスケーリング方法について開示している。

【0007】

特許文献２は、プロアクティブな自動スケーリングシステムは、発見的手法と機械学習を使用して、負荷レベルの変化を引き起こすスケーリングイベントの前に、アプリケーションに割り当てられたコンピューティングリソースを積極的かつ動的かつ自動的にスケーリングする方法について開示している。

【先行技術文献】

【特許文献】

【0008】

【特許文献1】特開２０１３－２１０６８３号公報

【特許文献2】米国特許第１１２２６８４４号明細書

【発明の概要】

【発明が解決しようとする課題】

【0009】

ＳＬＡおよび運用方針を満たすようにスケーリングを制御するためには、判定用メトリクスの閾値を適切に設定する必要がある。そのために、特許文献１、２に記載の技術を用いてイベント駆動型分散アプリケーションおよびオートスケーリングサービスのシミュレーションを実行し、判定用メトリクスの閾値を算出する方法が考えられる。

【0010】

同じサービスを提供するイベント駆動型分散アプリケーションであっても、リージョンおよびユーザによってイベント駆動型分散アプリケーションの実装は異なる。そのため、イベント駆動型分散アプリケーションのイベントのフローは様々あり、また、イベントの分岐の傾向も異なる。したがって、イベントのフローを特定し、また、イベントのフローの発生頻度を特定した上でシミュレーションを行う必要がある。また、クラウドシステム上でのアプリケーションサービスの運用によって、アプリケーションサービスを提供する基盤の管理も複雑化している。そのため、各イベント駆動型分散アプリケーションの挙動を把握することは難しい。そのため、従来技術をそのまま適用することは難しい。

【0011】

本発明は、複数のイベント駆動型分散アプリケーションが稼働するシステムにおいて、各イベント駆動型分散アプリケーションのオートスケーリングの判定用メトリクスの閾値を設定することを目的とする。

【課題を解決するための手段】

【0012】

本願において開示される発明の代表的な一例を示せば以下の通りである。すなわち、計算機システムであって、プロセッサ、前記プロセッサに接続されるメモリ、および前記プロセッサに接続されるネットワークインタフェースを備え、インスタンスを提供する実行環境システム、および前記インスタンスのスケーリングを制御するオートスケーリングシステムと接続し、前記実行環境システムでは、前記インスタンスを用いて、同じサービスを提供するアプリケーションが複数実行され、前記アプリケーションは、複数のイベント駆動型のイベント処理を含み、前記プロセッサは、対象アプリケーションの処理の実行ログを取得し、前記実行ログを用いて、前記対象アプリケーションにおける前記イベント処理の処理フロー、および前記処理フローが処理するリクエスト数の時間推移の組みを一つ以上含む負荷パターンを生成し、前記負荷パターンに基づいて、前記スケーリングの実行を制御するための判定用メトリクスの閾値を設定し、前記対象アプリケーションの処理および前記スケーリングをシミュレーションするシミュレーション処理を複数回実行し、前記シミュレーション処理の結果に基づいて、前記判定用メトリクスの閾値を決定する。

【発明の効果】

【0013】

本発明の一形態によれば、複数のイベント駆動型分散アプリケーションが稼働するシステムにおいて、各イベント駆動型分散アプリケーションのオートスケーリングの判定用メトリクスの閾値を設定することができる。上記した以外の課題、構成および効果は、以下の実施形態の説明により明らかにされる。

【図面の簡単な説明】

【0014】

【図1】実施例１のＩＴシステムの構成例を示す図である。

【図2】実施例１のサーバを実現する計算機の構成の一例を示す図である。

【図3】実施例１のＩＴシステムにおけるサーバ間の連携の一例を示す図である。

【図4】実施例１の評価サーバの機能構成の一例を示す図である。

【図5A】実施例１のシミュレーションＤＢに格納される情報のデータ構造の一例を示す図である。

【図5B】実施例１のシミュレーションＤＢに格納される情報のデータ構造の一例を示す図である。

【図5C】実施例１のシミュレーションＤＢに格納される情報のデータ構造の一例を示す図である。

【図5D】実施例１のシミュレーションＤＢに格納される情報のデータ構造の一例を示す図である。

【図5E】実施例１のシミュレーションＤＢに格納される情報のデータ構造の一例を示す図である。

【図6】実施例１のＩＴシステムにおける収集部のデプロイ／制御の流れを示すシーケンス図である。

【図7】実施例１の評価サーバが実行する処理の概要を説明するフローチャートである。

【図8】実施例１の評価サーバが実行する負荷パターン生成処理の一例を説明するフローチャートである。

【図9】実施例１の評価サーバが実行する閾値決定処理の一例を説明するフローチャートである。

【図10】実施例１の評価サーバが実行する最小／最大サーバ数決定処理の一例を説明するフローチャートである。

【図11】実施例１の評価サーバが提示するＧＵＩの一例を示す図である。

【発明を実施するための形態】

【0015】

以下、本発明の実施例を、図面を用いて説明する。ただし、本発明は以下に示す実施例の記載内容に限定して解釈されるものではない。本発明の思想ないし趣旨から逸脱しない範囲で、その具体的構成を変更し得ることは当業者であれば容易に理解される。

【0016】

以下に説明する発明の構成において、同一または類似する構成または機能には同一の符号を付し、重複する説明は省略する。

【0017】

本明細書等における「第１」、「第２」、「第３」等の表記は、構成要素を識別するために付するものであり、必ずしも、数または順序を限定するものではない。

【実施例0018】

図１は、実施例１のＩＴシステムの構成例を示す図である。図２は、実施例１のサーバを実現する計算機の構成の一例を示す図である。

【0019】

ＩＴシステムは、オートスケーリングサーバ１０１、ロードバランサ１０２、複数のアプリケーション実行サーバ１０４、データベースサーバ１０５、監視サーバ１０６、収集サーバ１０７、および評価サーバ１０８を含む。各サーバはネットワーク１２０を介して相互に接続される。ネットワーク１２０は、ＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）、ＷＡＮ（Ｗｉｄｅ Ａｒｅａ Ｎｅｔｗｏｒｋ）、インターネット等である。ネットワークの接続方式は有線および無線のいずれでもよい。また、ネットワーク１２０は、プライベートネットワークでもよいし、パブリックネットワークでもよい。

【0020】

ＩＴシステムのサーバは、たとえば、図２のような計算機２００を用いて実現される。計算機２００は、プロセッサ２０１、主記憶装置２０２、副記憶装置２０３、およびネットワークインタフェース２０４を有する。各ハードウェア要素はバスを介して互いに接続される。なお、計算機２００は、ユーザからの入力を受け付ける入力装置およびユーザが視認可能なデータを出力する出力装置を有してもよい。入力装置は、たとえば、キーボード、マウス、およびタッチパネル等であり、出力装置は、たとえば、ディスプレイおよびプリンタ等である。

【0021】

プロセッサ２０１は、主記憶装置２０２に格納されるプログラムを実行する。プロセッサ２０１がプログラムにしたがって処理を実行することによって、特定の機能を実現する機能部（モジュール）として動作する。以下の説明では、機能部を主語に処理を説明する場合、プロセッサ２０１が当該機能部を実現するプログラムを実行していることを示す。

【0022】

なお、プロセッサ２０１の代わりに、ＦＰＧＡ（Ｆｉｅｌｄ Ｐｒｏｇｒａｍａｂｌｅ Ｇａｔｅ Ａｒｒａｙ）またはＡＳＩＣ（Ａｐｐｌｉｃａｔｉｏｎ Ｓｐｅｃｉｆｉｃ Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔ）を用いてもよい。また、プロセッサ２０１と、ＦＰＧＡまたはＡＳＩＣとを併用してもよい。

【0023】

主記憶装置２０２は、ＤＲＡＭ（Ｄｙｎａｍｉｃ Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）等の高速な記憶装置であり、プロセッサ２０１が実行するプログラムおよびプログラムの実行時に使用されるデータを格納する。主記憶装置２０２はワークエリアとしても用いられる。なお、計算機２００は、ＢＩＯＳ等を格納するＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）を有してもよい。

【0024】

副記憶装置２０３は、ＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）およびＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）等の大容量の記憶装置であり、データを永続的に格納する。なお、主記憶装置２０２に格納されるプログラムおよびデータは、副記憶装置２０３に格納されてもよい。この場合、プロセッサ２０１は、副記憶装置２０３からプログラムおよびデータを読み出し、主記憶装置２０２にロードする。

【0025】

ネットワークインタフェース２０４は、所定のプロトコルにしたがって、ネットワークを介して他の装置と通信を行う。

【0026】

なお、サーバは仮想マシンを用いて実現してもよい。また、サーバはコンテナを用いて実現してもよい。

【0027】

アプリケーション実行サーバ１０４は、イベント駆動型分散アプリケーション３０１（図３参照）を実行するためのインスタンスを実現するサーバである。アプリケーション実行サーバ１０４は、実行環境システム１１０上に構成される。

【0028】

以下の説明では、イベント駆動型分散アプリケーションを単にアプリケーションと記載する。

【0029】

ロードバランサ１０２は、アプリケーション３０１に対するリクエストの振り分けを行う。

【0030】

アプリケーション３０１は、受信したリクエストに対応した、イベント処理のフローであるイベント処理フローにしたがってイベント処理を実行する。

【0031】

アプリケーション実行サーバ１０４は、スレッドにイベント処理を割り当てることによって複数のイベント処理を並列実行する。なお、アプリケーション実行サーバ１０４は、未処理のイベント処理の滞留数、並びに、イベント処理着手、完了、リトライ中、およびエラー終了等のイベント処理進捗状態を記録および参照するために、データベースサーバ１０５を用いる。

【0032】

また、アプリケーション実行サーバ１０４は、当該サーバの負荷状況（未処理のイベント処理の滞留数など）に応じて、他のアプリケーション実行サーバ１０４に対してイベント処理を転送し、イベント処理の引継ぎを依頼することができる。

【0033】

本実施例では、リージョンおよびユーザの組合せ毎に、同じサービスを実現するアプリケーション３０１が存在するものとする。アプリケーション３０１は、リージョンおよびユーザの組合せ毎にカスタマイズされているものとする。

【0034】

データベースサーバ１０５は、アプリケーション実行サーバ１０４の未処理のイベント処理の滞留数、イベント処理進捗状態、およびイベント処理時間など格納するイベント制御情報３１０を管理する。なお、データベースサーバ１０５は、アプリケーション３０１が記録および参照するデータも管理する。なお、前者と後者のデータ管理用途で、データベースサーバ１０５を分けてもよい。

【0035】

オートスケーリングサーバ１０１は、アプリケーション実行サーバ１０４の数を増減させるオートスケーリングサービスを実現するサーバである。たとえば、オートスケーリングサーバ１０１は、アプリケーション実行サーバ１０４のＣＰＵ使用率などの判定用メトリクスを取得し、判定用メトリクスが閾値より大きい場合、アプリケーション実行サーバ１０４を追加し、判定用メトリクスが閾値より小さい場合、アプリケーション実行サーバ１０４を削減するものとする。たとえば、Ａｍａｚｏｎ ＥＫＳ（Ｅｌａｓｔｉｃ Ｋｕｂｅｒｎｅｔｅｓ Ｓｅｒｖｉｃｅ）をはじめとするオーケストレーションサービスのスケーリング機能を想定する。

【0036】

監視サーバ１０６は、判定用メトリクスを算出するために、アプリケーション実行サーバ１０４、データベースサーバ１０５、およびロードバランサ１０２から各種情報を取得する。たとえば、受け付けたリクエストの数、イベント処理ログ、アプリケーション実行サーバ１０４の稼働情報、データベースサーバ１０５に対するデータのライト処理およびリード処理のログ等を取得する。イベント処理ログには、イベント処理の種別、処理時間、他のイベント処理の呼出等が含まれる。以下の説明では、アプリケーション３０１の実行に関する情報をアプリケーションログとも記載する。

【0037】

監視サーバ１０６は、取得したアプリケーションログを用いて、判定用メトリクスを算出し、オートスケーリングサーバ１０１に送信する。なお、取得した情報に含まれる値をそのまま判定用メトリクスとして算出してもよいし、取得した情報を用いて情報処理によって判定用メトリクスを算出してもよい。また、監視サーバ１０６は、判定用メトリクスを判定値に変換し、判定値を送信してもよい。

【0038】

収集サーバ１０７は、監視サーバ１０６からアプリケーションログを取得し、評価サーバ１０８に送信する。

【0039】

評価サーバ１０８は、アプリケーション３０１およびオートスケーリングサーバ１０１の各々のシミュレーションを実行する。以下の説明では、アプリケーション３０１およびオートスケーリングサーバ１０１の各々のシミュレーションをまとめて運用シミュレーションと記載する。評価サーバ１０８は、運用シミュレーションの結果に基づいて、オートスケーリングを制御するための制御値を決定し、オートスケーリングサーバ１０１および監視サーバ１０６の各種設定情報に反映する。

【0040】

図３は、実施例１のＩＴシステムにおけるサーバ間の連携の一例を示す図である。

【0041】

実行環境システム１１０では、複数のアプリケーション実行サーバ１０４がイベント処理を実行しているものとする。

【0042】

アプリケーション実行サーバ１０４は、アプリケーション３０１、分散処理基盤３００、アプリケーションログ収集エージェント３０２を含む。

【0043】

アプリケーション３０１は、分散処理基盤３００上で稼働する。分散処理基盤３００は、アプリケーション３０１のフレームワークとして機能する。具体的には、分散処理基盤３００は、イベント処理フローおよび各イベント処理について、データベースサーバ１０５のイベント制御情報３１０へのアクセスによるイベント進捗管理、イベント呼出、イベント処理へのスレッド割当、およびアプリケーション実行サーバ１０４間のイベント転送を行う。

【0044】

アプリケーションログ収集エージェント３０２は、周期的に、分散処理基盤３００から、イベントの実行履歴、ＣＰＵ使用率、ヒープメモリの使用量、イベント処理の滞留数、およびイベント処理時間等のアプリケーション３０１の実行に関するログ（アプリケーションログ）を取得する。なお、アプリケーションログ収集エージェント３０２は、データベースサーバ１０５またはオートスケーリングサーバ１０１から必要な情報を取得してもよい。

【0045】

まず、オートスケーリングの処理フローについて説明する。

【0046】

監視サーバ１０６の監視部３２０は、アプリケーションログ収集エージェント３０２からアプリケーションログを取得する。なお、監視部３２０は、アプリケーションログ収集エージェント３０２以外の構成から判定用メトリクスを算出するための情報を取得してもよい。たとえば、オートスケーリングサーバ１０１から現在のアプリケーション実行サーバ１０４の稼働数を取得してもよい。

【0047】

監視サーバ１０６の監視部３２０は、監視設定情報３２１に基づいて、取得した情報を用いて判定用メトリクスを算出し、オートスケーリングサーバ１０１に送信する。監視設定情報３２１には、判定用メトリクスを算出するためのアルゴリズム等が格納される。

【0048】

監視部３２０は、取得したアプリケーションログおよび算出した判定用メトリクスを履歴ＤＢ３２２に格納する。

【0049】

オートスケーリングサーバ１０１は、オートスケーリング設定情報３５０および判定用メトリクスに基づいて、スケーリングの要否を判定し、アプリケーション実行サーバ１０４の追加または削除を行う。なお、オートスケーリング設定情報３５０には、閾値、並びに、アプリケーション実行サーバ１０４の最大数および最小数等が含まれる。

【0050】

次に、制御値を算出するための処理フローについて説明する。

【0051】

評価サーバ１０８は、アプリケーションログの取得を収集サーバ１０７の収集部３３０に指示する。収集部３３０は、監視サーバ１０６の履歴ＤＢ３２２からアプリケーションログを取得し、必要に応じて加工を行う。収集部３３０は、アプリケーションログを評価サーバ１０８に送信する。

【0052】

本実施例では、評価サーバ１０８のデプロイ部３４２が、収集サーバ１０７に収集部３３０を実現するプログラムをデプロイするものとする。また、評価サーバ１０８のデプロイ部３４２が、収集部３３０に対する収集指示および停止指示を送信するものとする。

【0053】

評価サーバ１０８は、収集サーバ１０７から受信したアプリケーションログをシミュレーションＤＢ３４３に格納する。

【0054】

設定情報生成部３４１は、アプリケーションログを用いて負荷パターンを生成し、また、負荷パターンを用いて判定用メトリクスの閾値等の制御値を決定するための運用シミュレーションを実行する。設定情報生成部３４１は、運用シミュレーションの結果に基づいて、制御値情報４３５（図４参照）を生成する。また、設定情報生成部３４１は、オートスケーリングサーバ１０１および監視サーバ１０６に決定した制御値の情報を送信する。

【0055】

なお、評価サーバ１０８は、監視サーバ１０６から直接アプリケーションログを取得してもよい。この場合、収集サーバ１０７は必要ない。

【0056】

図４は、実施例１の評価サーバ１０８の機能構成の一例を示す図である。

【0057】

評価サーバ１０８は、インタフェース部３４０、設定情報生成部３４１、およびデプロイ部３４２を有する。また、評価サーバ１０８は、シミュレーションＤＢ３４３および収集プログラム４４０を保持する。

【0058】

インタフェース部３４０は、評価サーバ１０８の機能部またはＤＢにアクセスするためのＡＰＩ４１１、および各種情報を提示するためのＧＵＩ４１０を提供する。

【0059】

デプロイ部３４２は、収集部３３０を実現する収集プログラム４４０をデプロイし、また、収集部３３０に収集指示および停止指示を送信する。

【0060】

設定情報生成部３４１は、負荷パターン生成部４２０、シミュレーション制御部４２１、シミュレーション実行部４２２、および情報更新部４２３を含む。

【0061】

負荷パターン生成部４２０は、アプリケーションログに基づいて負荷パターンを生成する。シミュレーション制御部４２１は、アプリケーション３０１のシミュレーション（離散イベントシミュレーション）およびオートスケーリングサーバ１０１のシミュレーションの実行を制御する。シミュレーション実行部４２２は、アプリケーション３０１のシミュレーションおよびオートスケーリングサーバ１０１のシミュレーションを実行する。情報更新部４２３は、運用シミュレーションの結果に基づいて制御値を決定し、監視設定情報３２１およびオートスケーリング設定情報３５０を反映させる。

【0062】

シミュレーションＤＢ３４３は、アプリケーションログ情報４３０、基本設定情報４３１、目標プラン情報４３２、アプリケーション解析情報４３３、負荷パターン情報４３４、および制御値情報４３５を格納する。

【0063】

アプリケーションログ情報４３０は、収集サーバ１０７から取得したアプリケーションログを格納する。基本設定情報４３１は、アプリケーション３０１の離散イベントシミュレーションの基本的な設定を管理するための情報である。目標プラン情報４３２は、運用シミュレーションの評価指標等を設定した目標プランを格納する。アプリケーション解析情報４３３は、アプリケーション３０１の挙動の解析結果を格納する。負荷パターン情報４３４は、負荷パターンを格納する。制御値情報４３５は、スケーリングを制御するための制御値を格納する。

【0064】

図５Ａ、図５Ｂ、図５Ｃ、図５Ｄ、および図５Ｅは、実施例１のシミュレーションＤＢ３４３に格納される情報のデータ構造の一例を示す図である。

【0065】

図５Ａは、基本設定情報４３１のデータ構造を示す。基本設定情報４３１は、実行環境システム１１０の構成、イベントの振り分けルール、オートスケーリングサービスの有効化設定、最小サーバ数、最大サーバ数、および閾値を含む。なお、最小サーバ数および最大サーバ数は空欄でもよい。最小サーバ数および最大サーバ数については後述する処理によって決定される。基本設定情報４３１に含まれる閾値は運用シミュレーションにおける閾値の初期値である。

【0066】

図５Ｂは、目標プラン情報４３２のデータ構造を示す。目標プラン情報４３２は、プランＩＤ５０１およびプラン詳細５０２を含むエントリを格納する。一つのエントリが一つの目標プラン（運用方針）に対応する。

【0067】

プランＩＤ５０１は目標プランのＩＤを格納するフィールドである。プラン詳細５０２は、目標プランの詳細を格納するフィールドである。プラン詳細５０２には、ＳＬＡに関する値、閾値の決定において重要視する項目等が格納される。プランＩＤ「ＰＬＡＮ＿Ａ」では、応答時間の上限値が３，０００ｍｓであり、応答時間が２，１００ｍｓ以内を遵守し、コストが最安となる閾値が決定される。

【0068】

図５Ｃは、アプリケーション解析情報４３３のデータ構造を示す。アプリケーション解析情報４３３は、アプリケーションログを解析して得られた、アプリケーション実行サーバ１０４の起動時間、アプリケーション３０１におけるイベントの種別、アプリケーション３０１の処理時間、およびデータベースサーバ１０５に対するリード／ライト時間等が格納される。

【0069】

図５Ｄは、負荷パターン情報４３４に格納される負荷パターン５１０のデータ構造を示す。負荷パターン５１０は、イベント処理フローおよびリクエスト流量推移グラフから構成されるデータ５１１を一つ以上含む。イベント処理フローは、イベントの種別を示すノードとイベント間の遷移を示すエッジとから構成される。エッジには遷移確率を設定できる。

【0070】

図５Ｅは、制御値情報４３５のデータ構造を示す。一つの目標プランに対して一つの制御値情報４３５が出力される。制御値情報４３５には、たとえば、最小サーバ数、最大サーバ数、閾値、および基準値が含まれる。

【0071】

基準値は、判定用メトリクスからリソース使用量を見積もるための値である。たとえば、基準値が１００であり、判定用メトリクスが５０である場合、５０％（＝５０／１００）を判定値として算出する。

【0072】

閾値が判定値より大きい場合、リソースに余裕があり、閾値が判定値より小さい場合リソースがひっ迫していることがわかる。たとえば、判定値が５０％で閾値が１００％である場合、リソースを半分に減らせる可能性があり、判定値が２００％で閾値が１００％である場合、リソースを２倍に増やす必要があるといえる。

【0073】

閾値および基準値を決める場合、どちらかを固定して運用シミュレーションを実行すればよい。本実施例では、基準値は固定しておき、閾値を決定する前提で記述している。なお、スケーリングの制御に判定用メトリクスをそのまま用いる場合、基準値は不要である。

【0074】

制御値情報４３５に含まれる基準値は、監視サーバ１０６の監視設定情報３２１に反映される。制御値情報４３５に含まれる最大サーバ数、最小サーバ数、および閾値は、オートスケーリングサーバ１０１のオートスケーリング設定情報３５０に反映される。

【0075】

図６は、実施例１のＩＴシステムにおける収集部３３０のデプロイ／制御の流れを示すシーケンス図である。

【0076】

評価サーバ１０８のデプロイ部３４２は、インタフェース部３４０を介してユーザからデプロイリクエストを受け付けた場合、インタフェース部３４０を介してユーザに応答を出力し、その後、収集サーバ１０７に収集プログラム４４０をデプロイする（ステップＳ６０１）。

【0077】

デプロイ部３４２は、インタフェース部３４０を介してユーザから起動リクエストを受け付けた場合、収集サーバ１０７に起動指示を送信する（ステップＳ６０２）。

【0078】

収集サーバ１０７は、起動指示を受信した場合、収集プログラム４４０を実行し、収集部３３０を起動させる（ステップＳ６０３）。収集サーバ１０７は、起動の完了を評価サーバ１０８に通知する（ステップＳ６０４）。評価サーバ１０８は、インタフェース部３４０を介して起動リクエストに対する応答を出力する。

【0079】

収集サーバ１０７は、周期的にアプリケーションログ収集処理を実行する（ステップＳ６１０）。具体的には、収集サーバ１０７は、監視サーバ１０６からアプリケーションログを取得し（ステップＳ６１１）、評価サーバ１０８に送信する（ステップＳ６１２）。評価サーバ１０８は、アプリケーションログ情報４３０を更新する（ステップＳ６１３）。具体的には、受信したアプリケーションログがアプリケーションログ情報４３０に登録される。

【0080】

デプロイ部３４２は、インタフェース部３４０を介してユーザから停止リクエストを受け付けた場合、収集サーバ１０７に停止指示を送信する（ステップＳ６２１）。収集サーバ１０７は、アプリケーションログ収集処理を停止する（ステップＳ６２２）。収集サーバ１０７は、処理の停止を評価サーバ１０８に通知する（ステップＳ６２３）。評価サーバ１０８は、インタフェース部３４０を介して停止リクエストに対する応答を出力する。

【0081】

図７は、実施例１の評価サーバ１０８が実行する処理の概要を説明するフローチャートである。

【0082】

評価サーバ１０８は、インタフェース部３４０を介して負荷パターンの生成リクエストを受け付けた場合、インタフェース部３４０を介して応答を出力した後、負荷パターン生成処理を実行する（ステップＳ７０１）。生成リクエストには、対象のアプリケーション３０１を特定するための情報が含まれる。たとえば、リージョンおよびユーザＩＤ等が含まれる。

【0083】

評価サーバ１０８は、インタフェース部３４０を介して運用シミュレーション実行リクエストを受け付けた場合、インタフェース部３４０を介して応答を出力した後、閾値決定処理を実行する（ステップＳ７０２）。運用シミュレーション実行リクエストには対象のアプリケーション３０１を特定するための情報が含まれる。

【0084】

図８は、実施例１の評価サーバ１０８が実行する負荷パターン生成処理の一例を説明するフローチャートである。

【0085】

負荷パターン生成部４２０は、アプリケーションログ情報４３０から、指定されたアプリケーション３０１のアプリケーションログを読み出す（ステップＳ８０１）。

【0086】

負荷パターン生成部４２０は、アプリケーションログを解析することによってアプリケーション解析情報４３３を生成する（ステップＳ８０２）。

【0087】

たとえば、負荷パターン生成部４２０は、アプリケーション３０１の処理開始から処理完了までのアプリケーションログにまとめて、解析を行う。アプリケーションログを解析することによって、アプリケーション実行サーバ１０４の起動時間、実行されるイベント処理の種別、イベント処理の実行時間、イベント処理に伴うデータベースサーバ１０５に対するリード／ライト時間を算出する。

【0088】

負荷パターン生成部４２０は、アプリケーションログの解析結果に基づいて、イベント処理フローを生成する（ステップＳ８０３）。たとえば、以下のような処理が実行される。

【0089】

（Ｓ８０３－１）負荷パターン生成部４２０は、遷移するイベント処理のペアを生成する。ここでは、イベント処理の組合せが重複しないようにペアが生成される。

【0090】

（Ｓ８０３－２）負荷パターン生成部４２０は、遷移先のイベント処理が同一であるペアを特定し、当該ペアの遷移先のイベント処理に異なる識別情報を設定する。たとえば、イベント処理「Ｂ」から呼び出されるイベント処理「Ｄ」のペアと、イベント処理「Ｃ」から呼び出されるイベント処理「Ｄ」のペアとがある場合、前者のペアのイベント処理「Ｄ」の識別子を「Ｄ１」と設定し、後者のペアのイベント処理「Ｄ」の識別子を「Ｄ２」と設定する。同じイベント処理であっても呼出元のイベント処理が異なる場合、呼出先のイベント処理の処理時間等に違いがある。そのため、別々の識別子を設定する。

【0091】

（Ｓ８０３－３）負荷パターン生成部４２０は、ペアおよびイベント処理情報に基づいて、イベント処理を連結されてイベント処理フローを生成する。

【0092】

負荷パターン生成部４２０は、アプリケーションログに基づいて、各イベント処理フローのイベント処理間の遷移確率を算出する（ステップＳ８０４）。イベント処理間の遷移確率は条件付き確率として算出される。

【0093】

負荷パターン生成部４２０は、各イベント処理フローのリクエスト数の時間推移を算出する（ステップＳ８０５）。

【0094】

（Ｓ８０５－１）負荷パターン生成部４２０は、アプリケーションログに基づいて、アプリケーション３０１が処理したリクエスト数の時間推移を算出する。

【0095】

（Ｓ８０５－２）負荷パターン生成部４２０は、イベント処理フローのイベント処理間の遷移確率を用いて、イベント処理フローの発生頻度を算出する。たとえば、イベント処理間の遷移確率の乗算値から発生頻度を算出する方法が考えられる。イベント処理フロー（１）の遷移確率の乗算値が０．０７であり、イベント処理フロー（２）の遷移確率の乗算値が０．０３である場合、イベント処理フロー（１）の発生頻度は７／１０、イベント処理フロー（２）の発生頻度は３／１０と算出できる。

【0096】

（Ｓ８０５－３）負荷パターン生成部４２０は、発生頻度に基づいて、アプリケーション３０１が処理したリクエスト数の時間推移を分配する。

【0097】

負荷パターン生成部４２０は、イベント処理フローおよびリクエスト数の時間推移を関連付けることによって負荷パターンを生成する（ステップＳ８０６）。負荷パターン生成部４２０は、アプリケーション３０１を特定するための情報と共に、生成された負荷パターンを負荷パターン情報４３４に登録する。

【0098】

なお、負荷パターンは手動で設定してもよい。たとえば、実環境でアプリケーション３０１を動作させる前に様々な負荷パターンで離散イベントシミュレーションを実行して目標プランを検討する場合、スケーリングの挙動を把握する場合に有効である。

【0099】

図９は、実施例１の評価サーバ１０８が実行する閾値決定処理の一例を説明するフローチャートである。

【0100】

シミュレーション制御部４２１は、目標プランを設定する（ステップＳ９０１）。目標プランはユーザによって入力される。

【0101】

シミュレーション制御部４２１は、基本設定情報４３１、アプリケーション解析情報４３３、負荷パターンを読み出す（ステップＳ９０２）。

【0102】

シミュレーション制御部４２１は、最小／最大サーバ数決定処理を実行する（ステップＳ９０３）。当該処理の詳細は後述する。当該処理では、最小サーバ数および最大サーバ数が決定される。なお、最小サーバ数および最大サーバ数が与えられている場合、ステップＳ９０３の処理は省略できる。なお、最小／最大サーバ数決定処理は、基本設定情報４３１のオートスケールサービス有効化フラグが「ＯＦＦ」の場合にのみ実行するようにしてもよい。

【0103】

シミュレーション制御部４２１は、判定用メトリクスの閾値を設定し（ステップＳ９０４）、シミュレーション実行部４２２に運用シミュレーションの実行を指示する（ステップＳ９０５）。当該指示には、基本設定情報４３１、アプリケーション解析情報４３３、負荷パターン、および判定用メトリクスの閾値等が含まれる。

【0104】

初回では、基本設定情報４３１に格納される値が判定用メトリクスの閾値として設定される。運用シミュレーションの実行後、新たに閾値を設定する場合、運用シミュレーションの結果に基づいて判定用メトリクスの閾値が設定される。閾値の更新のアルゴリズムは任意に設定できる。

【0105】

なお、アプリケーション３０１のシミュレーションおよびスケーリングのシミュレーションは公知の技術を用いればよいため詳細な説明は省略する。

【0106】

シミュレーション制御部４２１は、シミュレーション実行部４２２から運用シミュレーションの結果を取得した後、運用シミュレーションを終了するか否かを判定する（ステップＳ９０６）。たとえば、シミュレーション制御部４２１は、目標プランを満たす場合、運用シミュレーションを終了すると判定する。また、シミュレーション制御部４２１は、運用シミュレーションの実行回数が閾値より大きい場合、運用シミュレーションを終了すると判定する。

【0107】

運用シミュレーションを終了しない場合、シミュレーション制御部４２１は、ステップＳ９０４に戻る。運用シミュレーションを終了する場合、シミュレーション制御部４２１は、運用プランに最も適当する運用シミュレーションの結果に基づいて制御値情報４３５を生成する（ステップＳ９０７）。シミュレーション制御部４２１は、負荷パターンおよび運用シミュレーションの結果と関連付けて制御値情報４３５を格納する。

【0108】

なお、シミュレーション制御部４２１は、運用シミュレーションの結果に基づいて、判定用メトリクスの閾値以外の制御値を決定してもよい。たとえば、運用シミュレーションにおけるアプリケーション実行サーバ１０４の数の最小値に基づいて、最小サーバ数を決定してもよい。

【0109】

なお、評価サーバ１０８は、目標プランについてループ処理を実行し、複数の目標プランの制御値情報４３５を生成してもよい。

【0110】

図１０は、実施例１の評価サーバ１０８が実行する最小／最大サーバ数決定処理の一例を説明するフローチャートである。

【0111】

シミュレーション制御部４２１は、アプリケーション実行サーバ１０４の数の初期値を設定する（ステップＳ１００１）。たとえば、初期値として「１」が設定される。

【0112】

シミュレーション制御部４２１は、シミュレーション実行部４２２に離散イベントシミュレーションの実行を指示する（ステップＳ１００２）。当該指示には、基本設定情報４３１、アプリケーション解析情報４３３、および負荷パターン等が含まれる。

【0113】

シミュレーション制御部４２１は、シミュレーション実行部４２２から離散イベントシミュレーションの実行結果を取得し、離散イベントシミュレーションの実行結果に基づいて、運用プランに設定されたＳＬＡを満たすか否かを判定する（ステップＳ１００３）。

【0114】

運用プランに設定されたＳＬＡを満たさない場合、シミュレーション制御部４２１は、アプリケーション実行サーバ１０４の数を１加算し（ステップＳ１００４）、その後、ステップＳ１００２に戻る。

【0115】

運用プランに設定されたＳＬＡを満たす場合、シミュレーション制御部４２１は、現在のアプリケーション実行サーバ１０４の数を最大サーバ数に設定する（ステップＳ１００５）。

【0116】

シミュレーション制御部４２１は、シミュレーション実行部４２２に離散イベントシミュレーションの実行を指示する（ステップＳ１００６）。ステップＳ１００６の処理はステップＳ１００２の処理と同一である。

【0117】

シミュレーション制御部４２１は、離散イベントシミュレーションの実行結果に基づいて、運用プランに設定されたＳＬＡを満たすか否かを判定する（ステップＳ１００７）。ステップＳ１００７の処理はステップＳ１００３の処理と同一である。

【0118】

運用プランに設定されたＳＬＡを満たす場合、シミュレーション制御部４２１は、アプリケーション実行サーバ１０４の数を１減算し（ステップＳ１００８）、その後、ステップＳ１００６に戻る。

【0119】

運用プランに設定されたＳＬＡを満たさない場合、シミュレーション制御部４２１は、アプリケーション実行サーバ１０４の数に１を加算した値を最小サーバ数に設定する（ステップＳ１００９）。

【0120】

図１１は、実施例１の評価サーバ１０８が提示するＧＵＩ４１０の一例を示す図である。

【0121】

ボタン１１０１は、運用シミュレーションの各種設定を行うための操作ボタンである。ユーザは、ボタン１１０１を押下し、基本設定情報４３１および運用プラン等の設定および編集を行い、また、シミュレーション対象のアプリケーション３０１の指定等を行う。

【0122】

表示欄１１０２は、運用シミュレーションのサマリを表示する欄である。ユーザは表示欄１１０２を参照することによって、登録した運用シミュレーションの総数、運用シミュレーションの実行中、運用シミュレーションの実行スケジュール等を確認できる。また、ユーザは、表示欄１１０２のアイコンを操作することによって、実行済みの運用シミュレーションの結果およびアラート情報を確認できる。また、ユーザは、表示欄１１０２のアイコンを操作することによって、運用シミュレーションの実行および停止を指示できる。

【0123】

表示欄１１０３は、運用シミュレーションの結果を表示する欄である。ユーザは、表示欄１１０３を参照することによって、運用シミュレーションの設定、負荷パターン、運用シミュレーションの結果、および制御値情報４３５を確認できる。図では、運用シミュレーションの結果は、アプリケーション実行サーバ１０４の数の時間推移、アプリケーション３０１の応答時間の時間推移を示すグラフとして表示されている。

【0124】

以上で説明したように、本発明によれば、複数のアプリケーション３０１が稼働するシステムにおいて、アプリケーション３０１のオートスケーリングの判定用メトリクスの閾値を設定することができる。

【符号の説明】

【0125】

１０１ オートスケーリングサーバ
１０２ ロードバランサ
１０４ アプリケーション実行サーバ
１０５ データベースサーバ
１０６ 監視サーバ
１０７ 収集サーバ
１０８ 評価サーバ
１１０ 実行環境システム
１２０ ネットワーク
２００ 計算機
２０１ プロセッサ
２０２ 主記憶装置
２０３ 副記憶装置
２０４ ネットワークインタフェース
３００ 分散処理基盤
３０１ イベント駆動型分散アプリケーション
３０２ アプリケーションログ収集エージェント
３１０ イベント制御情報
３２０ 監視部
３２１ 監視設定情報
３２２ 履歴ＤＢ
３３０ 収集部
３４０ インタフェース部
３４１ 設定情報生成部
３４２ デプロイ部
３４３ シミュレーションＤＢ
３５０ オートスケーリング設定情報
４１０ ＧＵＩ
４１１ ＡＰＩ
４２０ 負荷パターン生成部
４２１ シミュレーション制御部
４２２ シミュレーション実行部
４２３ 情報更新部
４３０ アプリケーションログ情報
４３１ 基本設定情報
４３２ 目標プラン情報
４３３ アプリケーション解析情報
４３４ 負荷パターン情報
４３５ 制御値情報
４４０ 収集プログラム

【図1】

【図2】

【図3】

【図4】

【図5A】

【図5B】

【図5C】

【図5D】

【図5E】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】