JP6681484B2 - 計算機運用管理システムおよび方法 - Google Patents

Description

本発明は業務システムなどのアプリケーションソフトウェアを運用する技術に関する。

近年では業務システムに搭載するアプリケーションを海外で開発することが増えている。また、アプリケーションサーバレイヤにおいて、商用ソフトウェアとオープンソースソフトウェア（ＯＳＳ）を組み合わせて効率よく業務システムのトータルサービスを実現することが求められている。

実際に海外で開発された業務アプリケーションや商用ソフトウェアとオープンソースソフトウェアを組み合わせて実現された業務アプリケーションは、どのような構成になっており、どのような特性を持っているのか運用者でも分からないことがある（ブラックボックス化）。

また、Ｊａｖａ仮想マシン（ＪａｖａＶＭ）など自動でメモリ管理を行うマネジメント環境が普及してきている。それによってもアプリケーションの特性が分かりにくくなっている。なお、Ｊａｖａは登録商標である。

特開２０１６−５０７６１８号公報 特許５１４２５８号公報

アプリケーションの特性が分からないとシステム設計において処理装置および記憶装置の適切なリソース量を見積もることができない。そのため、処理装置および記憶装置のリソース量が不足あるいは過剰となる、サイジングの問題が起こる可能性がある。処理装置や記憶装置のリソースが不足すると、それによりシステム障害が引き起こされることがある。過剰なリソースは業務システムの運用コストを増大させることがある。

また、アプリケーションの特性が分からないと、業務システムの全体の中でアプリケーションをいつ実行するかという運用スケジュールが不適切になる可能性がある。不適切なスケジューリングにより処理完了の遅延が増えることがある。また、不適切なスケジュールによりアプリケーションが実行されないことがある。そして、その結果、業務システムの運用コストが増大したり、業務システムの信頼性が低下したりすることがある。また、アプリケーションの特性が分からないと、運用スケジュールの策定において、アプリケーションを実行する時期を決める手間が増大することがある。

また、アプリケーションの特性が分からないと、上述したサイジングあるいはスケジューリングの問題があった場合に、計算機に、どの程度の処理装置および記憶装置のリソース量を変更し、アプリケーションの運用をどのように改善したらよいか判断することが困難である。

そのため、業務システムにおける計算機への各リソースの割り当ておよび運用スケジュールを改善するために、未知のアプリケーションの特性を診断し、診断結果に基づいて、業務システムの処理装置および記憶装置のリソース量の改善策や業務システムの運用改善策を提案するアプリケーション診断サービスが重要となっている。

本発明の目的は、アプリケーションの特性が分からない業務システムの改善を可能にする技術を提供することである。

本発明の一つの実施態様に従う計算機運用管理装置は、アプリケーションの実行に利用するリソースを定めた第１リソース割り当ておよびリソースをアプリケーションの実行に利用する時間帯を定めた第１スケジュールに従って計算機にて実行されたアプリケーションの履歴を記録した稼働情報を与えられ、前記稼働情報に基づいて、前記アプリケーションの所定の定量的性質を表す特徴点情報を生成する稼働情報編集部と、前記特徴点情報に基づいて、前記アプリケーションの所定の定性的性質を表すアプリケーション特性を判定するアプリケーション特性判定部と、前記アプリケーションに関連して要求される性能を指定した運用要件と、前記計算機にて利用可能なリソースの制約を示すリソース制約と、前記計算機の運用の指針を示す運用ポリシとを与えられ、前記アプリケーションの前記特徴点情報および前記アプリケーション特性に基づいて、前記運用要件および前記リソース制約を満たし、前記運用ポリシに示された指針に従うように、前記計算機にて利用する第２リソース割り当ておよび第２スケジュールを算出する最適化実行部と、を有している。

稼働情報からアプリケーションの定量的性質である特徴点情報を生成し、その特徴点情報から定性的性質であるアプリケーション特性を判定し、特徴点情報とアプリケーション特性を利用して適切なリソースおよびスケジュールを算出することができるので、アプリケーション特性が未知であっても計算機の運用の改善が可能となる。

本実施形態による運用管理システムのブロック図である。 本実施形態による運用管理システムが実行する運用管理処理のフローチャートである。 本実施形態における特徴点抽出処理について説明するための図である。 本実施形態におけるアプリケーション特性判定処理のフローチャートである。 本実施形態におけるアプリケーション特性判定処理のフローチャートである。 本実施形態におけるサイジング式具体化処理のフローチャートである。 本実施形態におけるコスト優先のスケジューリング処理について説明するための図である。 本実施形態における性能優先のスケジューリング処理について説明するための図である。 本実施形態における運用改善候補探索処理のフローチャートである。 本実施形態における運用改善候補探索処理のフローチャートである。 本実施形態における運用管理システムが実行する再スケジューリング処理のフローチャートである。 本実施形態における運用管理システムが実行する運用要件見直し処理のフローチャートである。 本実施形態における特徴点情報テーブルの一例を示す図である。 本実施形態におけるアプリケーション特性テーブルの例を示す図である。 本実施形態における運用要件テーブルの例を示す図である。 運用ポリシの例について説明するための図である。 本実施形態におけるスケジューリング結果テーブルの例を示す図である。 本実施形態によるスケジューリング結果の第１例について説明するための図である。 本実施形態によるスケジューリング結果の第２例について説明するための図である。 本実施形態における運用改善候補の例を示す図である。 本実施形態におけるサイジング処理およびスケジューリング処理の様子を説明するための図である。

以下、本発明の実施形態について図面を参照して説明する。

図１は、本実施形態による運用管理システムのブロック図である。本実施形態による運用管理システム１００は、アプリケーション稼働環境２００上で動作する複数のアプリケーション３７０により実現された業務システムを運用するためのシステムである。本実施形態におけるアプリケーションは業務システムのジョブの単位に構成され、複数のアプリケーションを指定して実行することができる。

運用管理システム１００は、予め与えられる運用要件３１０、運用ポリシ３２０、およびスケジュール３３０と、アプリケーション稼働環境２００にてアプリケーション３７０が実行されたことで蓄積される稼働情報３８０とを入力とし、サイジング、スケジューリング、および運用改善候補探索の処理を実行し、サイジング情報３４０、スケジュール３５０、および運用改善候補３６０を出力する。

運用要件３１０は、アプリケーションに関連して要求される性能を含む業務システムがアプリケーションを実行することによりユーザに提供すべきサービスのレベルである。運用要件３１０は、例えば、業務システムのオペレータとユーザとの間で合意したＳＬＡ（Ｓｅｒｖｉｃｅ Ｌｅｖｅｌ Ａｇｒｅｅｍｅｎｔ）である。

運用ポリシ３２０は、業務システムの運用の指針である。運用ポリシ３２０には業務システムの運用にて、性能またはコスト等どのパラメータを優先させるかという情報が含まれる。

スケジュール３３０は、どの時間帯にどのアプリケーションにどのリソースを割り当てるかを示す情報である。スケジュール３３０は、運用管理システム１００による業務システムの運用管理処理前から適用されているスケジュールであり、運用管理処理により適宜改善される。運用管理処理は、業務システムの運用を改善するための処理であり、その処理結果には業務システムに適宜適用される情報と、運用改善策の候補（運用改善候補）としてオペレータに提案される情報とが含まれる。リソースには、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）、メモリなどハードウェアおよびソフトウェアのリソースが含まれる。

アプリケーション稼働環境２００は、複数のアプリケーションにより実現される業務システムを稼働させる計算機（不図示）のハードウェアおよびソフトウェアの構成および状態である。アプリケーションの実行に利用可能なリソースはアプリケーション稼働環境２００により決まる。

アプリケーション３７０は、業務システムのユーザが利用するソフトウェアプログラムである。業務システムは複数のアプリケーションにより実現される。

稼働情報３８０は、アプリケーションの実行に伴い発生するリクエストの開始あるいは完了のタイミングなど所定のタイミングで取得されるリソースの稼働に関する情報である。

サイジング情報３４０は、どのアプリケーションの実行にどれだけのリソースを利用するかを示す情報である。サイジング情報３４０は、運用管理システム１００による運用管理処理の処理結果であり、業務システムに適宜適用される。

スケジュール３５０は、スケジュール３３０と同様、どの時間帯にどのアプリケーションにどのリソースを割り当てるかを示す情報である。ただし、スケジュール３５０は、運用管理処理により得られたスケジュールであり、業務システムに適宜適用される情報である。業務システムにスケジュール３５０を適用することにより、業務システムのリソースの運用が改善されると考えられる。

運用改善候補３６０は、運用管理処理の処理結果であり、業務システムの運用を改善する改善策の候補である。ただし、運用改善候補３６０は、サイジング情報３４０およびスケジュール３５０とは異なり、業務システムに適用する前にオペレータに提示される。運用改善候補３６０は、例えばハードウェア構成の変更など自動的に適用することができない改善策である。オペレータへの提示は例えばディスプレイ画面への表示である。オペレータは提示された運用改善候補３６０を業務システムに適用するか否か判断することができる。

図１を再び参照すると、運用管理システム１００は、稼働情報取得部１１０と、稼働情報編集部１２０と、特徴点解析部１３０と、入力部１４０と、最適化実行部１５０と、運用改善候補提示部１６０と、出力部１７０とを有している。

稼働情報編集部１２０は、特徴点抽出部１２１と、運用結果抽出部１２２と、スケジュール結果抽出部１２３とを有している。特徴点解析部１３０は、アプリケーション特性判定部１３１を有している。入力部１４０は、運用要件入力部１４１と、運用ポリシ入力部１４２と、スケジュール入力部１４３とを有している。

最適化実行部１５０は、サイジング計画部１５１と、スケジュール決定部１５２と、再スケジュール部１５３とを有している。運用改善候補提示部１６０は、運用改善候補探索部１６１を有している。出力部１７０は、サイジング出力部１７１と、スケジュール出力部１７２と、運用改善候補出力部１７３とを有している。

一方、アプリケーション稼働環境２００には運用管理システムの稼働情報取得部１１０と対をなす稼働情報取得部２１０が配置されている。運用管理システム１００の稼働情報取得部１１０がサーバとなり、アプリケーション稼働環境２００の稼働情報取得部２１０がエージェントとなり、運用管理システム１００による稼働情報３８０の取得を実現する。

入力部１４０は、運用要件３１０、運用ポリシ３２０、およびスケジュール３３０を運用管理システム１００に入力する。入力部１４０において、運用要件入力部１４１は、運用要件３１０を入力する。運用ポリシ入力部１４２は、運用ポリシ３２０を入力する。スケジュール入力部１４３は、スケジュール３３０を入力する。

稼働情報編集部１２０は、稼働情報取得部１１０、２１０により取得された稼働情報３８０から、アプリケーション３７０の特徴点情報と、業務システムの運用結果と、スケジュール結果とを抽出する。特徴点情報は、アプリケーション３７０の定量的性質を表す情報である。業務システムの運用結果は、業務システムが適切に運用されているか否かを示す。例えば、業務システムの運用結果として、与えられた運用要件３１０が満たされているかを示す情報が得られる。スケジュール結果は、業務システムが与えられたスケジュール３３０通りに適切に動作しているか否かを示す情報である。

稼働情報編集部１２０において、特徴点抽出部１２１は、稼働情報３８０から特徴点情報を抽出する。運用結果抽出部１２２は、稼働情報３８０から運用結果の情報を抽出する。スケジュール結果抽出部１２３は、稼働情報３８０からスケジュール結果の情報を抽出する。

特徴点解析部１３０は、特徴点抽出部１２１で抽出された、業務システムのアプリケーションの特徴点情報を解析し、アプリケーション特性判定部１３１にて、アプリケーション特性を判定する。アプリケーション特性は、アプリケーションの予め定められた定性的性質の項目に関する情報である。

最適化実行部１５０は、サイジング式具体化処理を行い、サイジング式を用いたサイジング（構成管理）処理およびスケジューリング処理または再スケジューリング処理を実行する。サイジング式具体化処理は、サイジング処理に用いるサイジング式の原型の式を基に、アプリケーションの特徴点情報およびアプリケーション特性と運用要件とに基づいて、サイジング式を具体化する処理である。なお、例えば、運用結果抽出部１２２にて、業務システムが適切に運用されていないという業務システムの運用結果が得られたときに、サイジングおよびスケジューリングの処理を開始することにしてもよい。また、スケジュール結果抽出部１２３にて、業務システムが与えられたスケジュール３３０通りに適切に動作していないというスケジュール結果が得られたときにサイジングおよびスケジューリングの処理を開始することにしてもよい。また、オペレータ操作により再スケジューリングの実行が指示されたときに、サイジングおよび再スケジューリングの処理を開始することにしてもよい。

サイジング処理およびスケジューリング処理を行う場合、最適化実行部１５０は、運用要件入力部１４１から与えられる運用要件３１０と、運用ポリシ入力部１４２から与えられる運用ポリシ３２０と、特徴点抽出部１２１から与えられる特徴点情報と、アプリケーション特性判定部１３１から与えられるアプリケーション特性と、アプリケーション稼働環境２００の有するリソースにより定まるリソース制約とを入力とし、運用要件３１０およびリソース制約を満たし、運用ポリシ３２０に示された指針に従うように、計算機にて利用するリソース割り当て（サイジング情報３４０）およびスケジュール３５０を算出する。

サイジング処理および再スケジューリング処理を行う場合、最適化実行部１５０は、運用要件３１０と、運用ポリシ３２０と、特徴点情報と、アプリケーション特性と、リソース制約とに加え、スケジュール入力部１４３から与えられるスケジュール３３０と、を入力とし、スケジュール３３０から得られる情報の範囲内で運用要件３１０およびリソース制約を満たし、運用ポリシ３２０に示された指針に従うように、計算機にて利用するリソース割り当て（サイジング情報３４０）およびスケジュール３５０を算出する。

サイジング処理は、アプリケーションの実行に利用するリソースを決定する処理である。リソースにはＣＰＵおよびメモリが含まれる。スケジューリング処理は、リソースをアプリケーションの実行に利用する時間帯を決定する処理である。サイジング処理にてアプリケーションの実行に利用すると決定されたリソースを、業務システムの各アプリケーションの実行にどの時間帯に利用するかが決定される。サイジング処理およびスケジューリング処理の結果は業務システムのアプリケーション稼働環境２００に通知され、適宜適用される。

再スケジューリング処理は、例えば既存のスケジュールのような与えられたスケジュールから情報を得て、その情報の範囲内でサイジングおよびスケジューリングを行う処理である。与えられたスケジュールから得る情報には、アプリケーションの実行に利用されるリソースの情報、アプリケーションの実行開始から実行完了までの時間の情報と、が含まれる。限られたリソースを用いてアプリケーションを実行し、限られた時間内に処理を完了させるスケジュールが算出される。

最適化実行部１５０において、サイジング計画部１５１は、サイジング処理を実行する。スケジュール決定部１５２は、スケジューリング処理を実行する。再スケジュール部１５３は、再スケジューリング処理を実行する。

運用改善候補提示部１６０は、運用改善候補探索部１６１により運用改善候補探索処理を実行する。運用改善候補探索処理は、アプリケーションの内部処理の変更またはアプリケーション稼働環境２００を実現する計算機のハードウェア構成の変更を伴う運用改善策を探索する処理である。例えば、リソース制約には計算機のハードウェア構成によるＣＰＵ数およびメモリ容量の制限が含まれているとする。運用改善候補探索部１６１は、リソース制約で制限された計算機のＣＰＵまたはメモリを追加または削除する運用改善策を提案する。運用改善候補探索処理の結果である運用改善策は、サイジング処理およびスケジューリング処理の結果と異なり、アプリケーションあるは計算機のハードウェア構成の変更を伴うので、すぐに適用することができない。運用改善策は、運用改善候補３６０としてオペレータに提示され、適用の可否が判断される。

出力部１７は、サイジング処理の結果であるサイジング情報３４０と、スケジューリング処理の結果であるスケジュール３５０と、運用改善候補探索処理の結果である運用改善候補３６０を出力する。出力部１７０において、サイジング出力部１７１はサイジング情報３４０を出力する。スケジュール出力部１７２は、スケジューリング処理あるいは再スケジューリング処理の結果であるスケジュール３５０を出力する。運用改善候補出力部１７３は運用改善候補３６０を出力する。

以上説明したように、本実施形態による運用管理システム１００は、稼働情報編集部１２０と、アプリケーション特性判定部１３１と、最適化実行部１５０と、を有している。稼働情報編集部１２０は、アプリケーションの実行に利用するリソースを定めた第１リソース割り当ておよびリソースをアプリケーションの実行に利用する時間帯を定めた第１スケジュールに従って計算機にて実行されたアプリケーションによるリソースの利用を記録した稼働情報を与えられ、その稼働情報に基づいて、アプリケーションの所定の定量的性質を表す特徴点情報を生成する。アプリケーション特性判定部１３１は、その特徴点情報に基づいて、アプリケーションの所定の定性的性質を表すアプリケーション特性を判定する。最適化実行部１５０は、アプリケーションに関連して要求される性能を指定した運用要件と、計算機にて利用可能なリソースの制約を示すリソース制約と、計算機の運用の指針を示す運用ポリシとを与えられ、前記アプリケーションの前記特徴点情報および前記アプリケーション特性に基づいて、前記運用要件および前記リソース制約を満たし、前記運用ポリシに示された指針に従うように、前記計算機にて利用する第２リソース割り当ておよび第２スケジュールを算出する。このように、稼働情報からアプリケーションの定量的性質である特徴点情報を生成し、その特徴点情報から定性的性質であるアプリケーション特性を判定し、特徴点情報とアプリケーション特性を利用して適切なリソースおよびスケジュールを算出することができるので、アプリケーション特性が未知であっても計算機の運用の改善が可能である。

また、本実施形態では、運用改善候補探索部１６１は、アプリケーション特性に基づき、アプリケーションまたは計算機の変更を伴う運用改善策を提案する。このように、稼働情報に基づいてアプリケーション特性を推定し、そのアプリケーション特性に基づいて運用改善策を算出するので、アプリケーション特性が未知であっても改善策により計算機システムの改善が可能となる。

また、本実施形態では、出力部１７０は、第２リソース割り当ておよび第２スケジュールを計算機に適用し、運用改善策を、計算機を運用するオペレータ（運用者）に提示する。現在のアプリケーションおよび計算機の構成により適用可能なリソース割り当ておよびスケジュールを計算機に適用するとともに、アプリケーションおよび計算機の構成の変更を伴う運用改善策をオペレータに提示するので、現状での良好な計算機の運用を実現するとともに将来の更なる改善も可能となる。

次に本実施形態による運用管理システムが実行する処理について説明する。

図２は、本実施形態による運用管理システムが実行する運用管理処理のフローチャートである。

図２を参照すると、運用管理処理において、稼働情報取得部１１０は、ステップＳ１０１において、アプリケーション稼働環境２００の稼働情報取得部２１０と連携して、アプリケーション３７０の稼働情報３８０を取得する。次に、特徴点抽出部１２１は、ステップＳ１０２にて、稼働情報３８０から、アプリケーション３７０の特徴点情報を抽出する。続いて、アプリケーション特性判定部１３１は、ステップＳ１０３にて、特徴点情報に基づき、アプリケーション３７０のアプリケーション特性を判定する。次に、運用要件入力部１４１は、ステップＳ１０４にて、最適化実行部１５０に運用要件３１０を入力する。次に、運用ポリシ入力部１４２は、ステップＳ１０５にて、最適化実行部１５０に運用ポリシ３２０を入力する。

次に、サイジング計画部１５１は、ステップＳ１０６にて、サイジング式具体化処理を実行する。更に、最適化実行部１５０では、ステップＳ１０７にて、サイジング計画部１５１がサイジング処理（構成管理処理）を行い、スケジュール決定部１５２がスケジューリング処理を実行する。サイジング処理の結果としてサイジング情報３４０（第２リソース割り当て）が生成される。スケジューリング処理の結果として、スケジュール３５０（第２スケジュール）が生成される。サイジング処理およびスケジューリング処理は最適化エンジンにより行われる。例えば、最適化実行部１５０は、第２リソース割り当てとして、アプリケーションに割り当てるＣＰＵ、メモリ領域、およびプロセスの同時実行数を算出する。また、最適化実行部１５０は、第２スケジュールとして、計算機上で実行されるアプリケーションの開始時刻および終了時刻と利用するリソースとを算出する。

次に、運用改善候補探索部１６１は、ステップＳ１０８にて、運用候補改善処理を実行する。運用改善候補探索処理の結果として、運用改善候補３６０が生成される。更に、出力部１７０は、ステップＳ１０９にて、サイジング出力部１７１によりサイジング情報３４０を出力し、スケジュール出力部１７２によりスケジュール３５０が出力され、運用改善候補出力部１７３により運用改善候補３６０が出力される。

なお、図２にて、破線の四角形で囲われた部分は、１つ以上のアプリケーションに対する処理である。その詳細処理は後述する。つまり、ステップＳ１０１~Ｓ１０２、ステップＳ１０３、ステップＳ１０６、ステップＳ１０７、ステップＳ１０８の詳細な処理は後述する。

以下、図２に示した各処理の詳細について説明する。

図３は、本実施形態における特徴点抽出処理について説明するための図である。特徴点抽出部１２１は、図３に示すように予め定められた特徴点情報の各項目の値を稼働情報３８０から抽出する。

図３には、特徴点情報の各項目について、その項目の情報が抽出される稼働ログの種類と、そのログが出力される単位とを記載したテーブルが示されている。稼働ログは稼働情報３８０としてアプリケーション稼働環境２００にて取得された履歴情報である。図３の例では、特徴点情報として抽出される項目として、実行時間、ＣＰＵ時間、総メモリアロケート量、最大メモリ参照サイズ、最大メモリ参照寿命、実行後参照メモリサイズ、ＤＢ（データベース）アクセス時間、ファイルＩＯ（ファイル入出力処理）時間、ＮＷＩＯ（ネットワーク入出力処理）時間、排他待ち時間、スループット、その他待ち時間、ＧＣ（ガベージコレクション）占有率、Ｊａｖａヒープ確保サイズ、ＧＣ所要時間、ＧＣ後Ｊａｖａヒープサイズ残量がある。

その中で例えば、実行時間は、リクエストトレースというログから抽出されることが示されている。また、リクエストトレースの出力単位がアプリケーション別あるいはプロセス別であることが示されている。実行時間とは、所定の実行単位を実行するのに要する時間であり、具体的には、１トランザクションでの応答時間、あるいは１つの実行単位に含まれる複数（数千から数万）の処理を行うのに要する時間である。ここでいう実行単位は、アプリケーションにおいてＣＰＵを利用して実行するひとまとまりの処理単位であり、例えば、プログラム、トランザクション、プロセス、スレッドなどである。１つの実行単位に含まれる処理の例としてデータベースへのアクセスがある。実行時間は、ＣＰＵ時間、ＩＯ時間及び待ち時間の合計であり、ＥＴＩＭＥと呼ばれることもある。特徴点抽出部１２１は、アプリケーション毎に出力されたリクエストトレースからアプリケーションの実行時間を抽出することができる。

また、例えば、ＣＰＵ時間は、リクエストトレースというログから抽出されることが示されている。また、リクエストトレースの出力単位がアプリケーション別あるいはプロセス別であることが示されている。ＣＰＵ時間は、所定の実行単位を実行するのにＣＰＵが稼働する時間である。特徴点抽出部１２１は、アプリケーション毎に出力されたリクエストトレースからアプリケーションのＣＰＵ時間を抽出することができる。

また、例えば、総メモリアロケート量は、メモリプロファイルというログから抽出されることが示されている。また、メモリプロファイルの出力単位がアプリケーション別あるいはプロセス別であることが示されている。総メモリアロケート量は、アプリケーションの所定の実行単位を実行するために割り当てられたメモリ領域の総容量である。特徴点抽出部１２１は、アプリケーション毎に出力されたメモリプロファイルから総メモリアロケート量を抽出することができる。

本実施形態による運用管理システム１００では、管理対象の業務システムを実行する計算機がリソースとしてメモリおよびＣＰＵを有している。本実施形態では、稼働情報編集部１２０において、特徴点抽出部１２１は、稼働情報３８０から値を抽出することにより、特徴点情報として少なくとも、アプリケーションの所定の実行単位ごとに割り当てるメモリ領域の総量である総メモリアロケート量と、所定の実行単位を実行するのにＣＰＵが稼働した時間であるＣＰＵ時間と、所定の実行単位を実行するのに要した時間である実行時間と、を生成する。総メモリアロケート量、ＣＰＵ時間、および実行時間があると、リソース割り当ておよびスケジュールが適切かどうか診断するうえで主要なアプリケーション特性を判定することができる。最小構成の特徴点情報（総メモリアロケート量、ＣＰＵ時間、および実行時間）によりプログラムの主要な特徴を把握し、適切なリソース割り当ておよびスケジュールを算出することができる。

以下、アプリケーション特性判定処理を更に詳細に説明する。

図４、図５は、本実施形態におけるアプリケーション特性判定処理のフローチャートである。

図４を参照すると、アプリケーション特性判定部１３１は、ステップＳ２０１にて、実行時間が６０秒よりも短いか否か判定する。実行時間を以下Ｒと記す場合がある。実行時間が６０秒よりも短ければ、アプリケーション特性判定部１３１は、ステップＳ２０３にて、アプリケーション特性のアプリケーション種別の項目をオンライン処理「オンライン」と決定する。

実行時間が６０秒よりも短くなければ、アプリケーション特性判定部１３１は、ステップＳ２０２にて、実行時間が３６００秒よりも短いか否か判定する。実行時間が３６００秒よりも短ければ、アプリケーション特性判定部１３１は、ステップＳ２０４にて、アプリケーション種別の項目をオンバッチ処理「オンバッチ」と決定する。

実行時間が３６００秒よりも短くなければ、アプリケーション特性判定部１３１は、ステップＳ２０５にて、アプリケーション種別の項目をオフバッチ処理「オフバッチ」と決定する。

なお、ステップＳ２０１、Ｓ２０２にて用いる閾値はアプリケーション種別を識別するのに適切な値に予め設定しておけばよい。例えば、多数のアプリケーションとその実行時間を関連づけた情報を収集し、その情報から適切な閾値を決定することにしてもよい。

ステップＳ２０３、Ｓ２０４、またはＳ２０５の後、アプリケーション特性判定部１３１は、ステップＳ２０６にて、ＣＰＵ時間／実行時間が８０％よりも大きいか否か判定する。ＣＰＵ時間／実行時間が８０％よりも大きければ、アプリケーション特性判定部１３１は、ステップＳ２１０にて、ＣＰＵバウンドであるか否かを示す項目を、ＣＰＵバウンドであることを示す「１」と決定する。

ＣＰＵ時間／実行時間が８０％よりも大きくなければ、アプリケーション特性判定部１３１は、ステップＳ２０７にて、ＤＢアクセス時間／実行時間が８０％よりも大きいか否か判定する。ＤＢアクセス時間／実行時間が８０％よりも大きければ、アプリケーション特性判定部１３１は、ステップＳ２１１にて、ＤＢアクセスバウンドであるか否かを示す項目を、ＤＢアクセスバウンドであることを示す「１」と決定する。

ＤＢアクセス時間／実行時間が８０％よりも大きくなければ、アプリケーション特性判定部１３１は、ステップＳ２０８にて、ファイルＩＯ時間／実行時間が８０％よりも大きいか否か判定する。ファイルＩＯ時間／実行時間が８０％よりも大きければ、アプリケーション特性判定部１３１は、ステップＳ２１２にて、ファイルＩＯバウンドであるか否かを示す項目を、ファイルＩＯバウンドであることを示す「１」と決定する。

ファイルＩＯ時間／実行時間が８０％よりも大きくなければ、アプリケーション特性判定部１３１は、ステップＳ２０９にて、ＮＷＩＯ時間／実行時間が８０％よりも大きいか否か判定する。ＮＷＩＯ時間／実行時間が８０％よりも大きければ、アプリケーション特性判定部１３１は、ステップＳ２１３にて、ＮＷＩＯバウンドであるか否かを示す項目を、ＮＷＩＯバウンドであることを示す「１」と決定する。

なお、ステップＳ２０６、Ｓ２０７、Ｓ２０８、およびＳ２０９にて用いる閾値はアプリケーションの特徴を判断するのに適切な値に設定すればよい。ここではアプリケーションの特徴を判定する際に一般的に用いられる８０％という値を用いた。

ステップＳ２１０、Ｓ２１１、Ｓ２１２、あるいはＳ２１３の後、あるいはステップＳ２０９にてＮＯと判定されたとき、アプリケーション特性判定部１３１は、ステップＳ２１４にて、アプリケーション種別がオンラインであるか否か判定する。アプリケーション種別がオンラインであれば、アプリケーション特性判定部１３１は、ステップＳ２１５にて、ＣＰＵ時間が１００ｍｓｅｃより大きいか否か判定する。ＣＰＵ時間が１００ｍｓｅｃより大きければ、アプリケーション特性判定部１３１は、ステップＳ２１７にて、ＣＰＵコストが大きいか否かを示す項目をＣＰＵコストが大きいことを示す「１」と決定する。

ＣＰＵ時間が１００ｍｓｅｃより大きくなければ、アプリケーション特性判定部１３１は、ステップＳ２１６にて、総メモリアロケート量が１００ＭＢより大きいか否か判定する。総メモリアロケート量が１００ＭＢより大きければ、アプリケーション特性判定部１３１は、メモリコストが大きいか否かを示す項目をメモリコストが大きいことを示す「１」と決定する。

なお、ステップＳ２１５、Ｓ２１６にて用いる閾値はコストの大小を判定するのに適切な値に予め設定しておけばよい。例えば、多数のアプリケーションについて情報を収集し、その情報から適切な閾値を決定することにしてもよい。

ステップＳ２１４の判定でＮＯのとき、あるいはステップＳ２１７、Ｓ２１８の後、図５に移り、アプリケーション特性判定部１３１は、ステップＳ３０１にて、排他待ち時間／実行時間が５％より大きいか否か判定する。排他待ち時間／実行時間が５％より大きければ、アプリケーション特性判定部１３１は、ステップＳ３０２にて、実行時間のうち排他待ち時間の割合が大きいか否かを示す項目を、その割合が大きいことを示す「１」と決定する。

ステップＳ３０２の後、あるいはステップＳ３０１にてＮＯと判定されたとき、アプリケーション特性判定部１３１は、ステップＳ３０３にて、ＧＣ所要時間が１０秒より大きいか否か判定する。ＧＣ所要時間が１０秒よりも大きければ、アプリケーション特性判定部１３１は、ステップＳ３０５にて、ＧＣ所要時間が大きいか否かを示す項目を、ＧＣ所要時間が大きいことを示す「１」と決定する。

ＧＣ所要時間が１０秒よりも大きくなれば、アプリケーション特性判定部１３１は、ステップＳ３０４にて、ＧＣ占有率が２％より大きいか否か判定する。ＧＣ占有率が２％より大きければ、アプリケーション特性判定部１３１は、ＧＣ占有率が大きいか否かを示す項目をＧＣ占有率が大きいことを示す「１」と決定する。

ステップＳ３０５、Ｓ３０６の後、あるいはステップＳ３０４にてＮＯと判定されたとき、アプリケーション特性判定部１３１は、ステップＳ３０７にて、これまでの判定で得られたアプリケーション特性の各項目の情報をアプリケーション特性テーブルに出力する。

なお、ステップＳ３０１、Ｓ３０３、Ｓ３０４にて用いる閾値はアプリケーションの各特徴を判定するのに適切な値に予め設定しておけばよい。例えば、多数のアプリケーションについて情報を収集し、その情報から適切な閾値を決定することにしてもよい。

以上説明したように、本実施形態では、アプリケーション特性判定部１３１は、特徴点情報に基づいてアプリケーション特性の各項目について判定する。特に、アプリケーション特性判定部１３１は、アプリケーション特性として、オンライン処理か否かを含むアプリケーション種別を実行時間に基づいて判定し、アプリケーション種別がオンラインであれば、メモリコストを総メモリアロケート量に基づいて判定し、ＣＰＵコストをＣＰＵ時間に基づいて判定する。これらはアプリケーション特性として最小構成であり、本実施形態では、これらの項目を容易に判定することができる。

図６は、本実施形態におけるサイジング式具体化処理のフローチャートである。

図６を参照すると、サイジング計画部１５１は、ステップＳ４０１にて、アプリケーション種別がオンライン処理であるか否か判定する。この判定はアプリケーション特性テーブルを参照することにより行う。アプリケーション種別がオンライン処理であれば、サイジング計画部１５１は、ステップＳ４０３にて、オンライン処理のサイジング式の原型の式の設定可能箇所に対して、特徴点情報および運用要件の各値を設定し、具体的なサイジング式を生成する。

ステップＳ４０１にてＮＯと判定された場合、サイジング計画部１５１は、ステップＳ４０２にて、アプリケーション種別がオンバッチ処理であるか否か判定する。アプリケーション種別がオンバッチ処理であれば、サイジング計画部１５１は、ステップＳ４０３に進み、オンライン処理のサイジング式の原型の式を用いて、具体的なサイジング式を生成する。

ステップＳ４０２にてＮＯと判定された場合、サイジング計画部１５１は、バッチ処理のサイジング式の原型の式の設定可能箇所に対して、特徴点情報および運用要件の各値を設定し、具体的なサイジング式を生成する。

ステップＳ４０３、Ｓ４０４の後、サイジング計画部１５１は、ステップＳ４０５にて、ステップＳ４０３またはＳ４０４で生成したサイジング式をスケジュール処理に渡す。

図７は、本実施形態におけるコスト優先のスケジューリング処理について説明するための図である。図７を参照すると、特徴点情報、アプリケーション特性、および運用要件をサイジング式の原型に適用することにより各アプリケーションのサイジング式が具体化されている。その各アプリケーションのサイジング式と運用ポリシを、構成管理（サイジング）およびスケジューリングを行う最適化エンジンに適用する。

ここではコスト優先の運用ポリシが用いられている。コスト優先の運用ポリシには、最適化目標として、運用コストが２００００００円以下という内容が設定されている。また、制約条件として先行条件や開始時刻および終了時刻が設定されている。

サイジングの結果として得られた構成定義には、それぞれにＪａｖａＶＭを実行基盤として動作するアプリケーション１およびアプリケーション２にはＣＰＵ＃１、ＣＰＵ＃２、および１０ＧＢのメモリが割り当てられることが示されている。

スケジューリングの結果として得られるスケジュール結果テーブルには、６：００〜１８：００の時間帯にはＣＰＵ＃１およびＣＰＵ＃２上でアプリケーション１（０００１）が動作し、１８：００以降はＣＰＵ＃１およびＣＰＵ＃２上でアプリケーション２（０００２）が動作することが示されている。

図８は、本実施形態における性能優先のスケジューリング処理について説明するための図である。図８を参照すると、ここでは性能優先の運用ポリシが用いられている。性能優先の運用ポリシには、最適化目標として、完了時刻が１８：００以前であることが必須であるという内容が設定されている。また、制約条件として先行条件や開始時刻および終了時刻が設定されている。

サイジングの結果として得られた構成定義には、それぞれにＪａｖａＶＭを実行基盤として動作するアプリケーション１およびアプリケーション２にはＣＰＵ＃１、ＣＰＵ＃２、ＣＰＵ＃３、および１５ＧＢのメモリが割り当てられることが示されている。

スケジューリングの結果として得られるスケジュール結果テーブルには、６：００〜１８：００の時間帯に、ＣＰＵ＃１およびＣＰＵ＃２上でアプリケーション１（０００１）が動作し、ＣＰＵ＃３上でアプリケーション２（０００２）が動作することが示されている。

図７と図８の構成定義を比較すると、図７の場合の方が図８の場合よりも少ないＣＰＵおよびメモリでアプリケーション１、２を動作させることが分かる。また、図７と図８のスケジュール結果テーブルを比較すると、図８の場合の方が図７の場合よりもアプリケーション１、２の処理を短い時間で完了させることが分かる。

なお、サイジングおよびスケジューリングの処理には制約条件が課される場合がある。その場合、サイジング計画部１５１およびスケジュール決定部１５２は、運用要件および運用ポリシに加え、制約条件を満たすようにして構成定義およびスケジュールを算出する。

どのような制約条件を用いるかは特に限定されないが、以下に制約条件のいくつかの例を示す。

＜１＞ガベージコレクションの要件が厳しいＪａｖａ固有のアプリケーションに課される制約条件の例
本例の制約条件は式（１）を満たすようにスケジューリングを行うことという制約条件である。数式中の各項の「：」は、「テーブル名：項目」を意味する。

なお、この制約条件は、アプリケーション特性におけるＧＣ占有率が大きいか否かという項目に、大きいことを意味するフラグ「１」が設定されているアプリケーションが対象となる。

＜２＞ガベージコレクションの要件が厳しいＪａｖａ固有のアプリケーションに課される制約条件の他の例
本例の制約条件は式（２）を満たすようにスケジューリングを行うことという制約条件である。式（２）により算出される１プロセスあたりのスループットを基に、サイジング式により1プロセスについてのサイジングを行う。サイジング処理は、上述した通り、アプリケーションの実行に利用するリソースを決定する処理である。得られたリソースに基づいて、運用要件を満たすためのプロセス数を決定する。運用要件を満たすプロセス数は式（３）により算出することができる。数式中の各項の「：」は、「テーブル名：項目」を意味する。

なお、この制約条件は、アプリケーション特性におけるＧＣ所要時間が大きいか否かという項目に、大きいことを意味するフラグ「１」が設定されているアプリケーションが対象となる。

＜３＞アプリケーション間でリソースを平準化するための制約条件（Ｊａｖａアプリケーションに限定されない）
本例の制約条件は、ファイルＩＯバウンドであることを示すフラグが「１」またはＮＷＩＯバウンドであることを示すフラグが「１」であるアプリケーションが同時に実行されないようにスケジューリングを行うという制約条件である。ファイルＩＯバウンドとＮＷＩＯバウンドを総称してＩＯバウンドと呼ぶことがある。この制約条件は、ＩＯバウンドのいずれかのフラグが「１」であるアプリケーションが対象となる。

図９および図１０は、本実施形態における運用改善候補探索処理のフローチャートである。

図９を参照すると、運用改善候補探索部１６１は、ステップＳ５０１にて、アプリケーション種別がオンライン処理か否か判定する。オンライン処理であれば、運用改善候補探索部１６１は、ステップＳ５０２にて、ＣＰＵコストが大きいか否か判定する。ＣＰＵコストが大きければ、アプリケーションがオンライン処理であるかつＣＰＵ時間が重いため、運用改善候補探索部１６１は、ステップＳ５０３にて、ダイナミックステップの見直しを提案する。

更に、運用改善候補探索部１６１は、ステップＳ５０４にて、メモリコストが大きいか否か判定する。メモリコストが大きければ、アプリケーションがオンライン処理かつメモリ使用量が多いため、運用改善候補探索部１６１は、ステップＳ５０５にて、メモリの使い方の見直しを提案する。

更に、運用改善候補探索部１６１は、ステップＳ５０６にて、実行時間のうち排他待ち時間の割合が大きいか否か判定する。実行時間のうち排他待ち時間の割合が大きければ、排他待ち時間が比較的大きいため、運用改善候補探索部１６１は、ステップＳ５０７にて、排他処理の見直しを提案する。

更に、運用改善候補探索部１６１は、ステップＳ５０８にて、アプリケーションがＤＢアクセスバウンドであるか否か判定する。アプリケーションがＤＢアクセスバウンドであれば、運用改善候補探索部１６１は、ＤＢアクセスが重いため、ステップＳ５０９にて、ＳＱＬまたはＤＢサーバチューニングを提案する。

更に、運用改善候補探索部１６１は、ステップＳ５１０にて、アプリケーションがファイルＩＯバウンドであるか否か判定する。アプリケーションがファイルＩＯバウンドであれば、ファイルＩＯが重いため、運用改善候補探索部１６１は、ステップＳ５１１にて、ＩＯ処理またはディスクチューニングを提案する。

更に、運用改善候補探索部１６１は、ステップＳ５１２にて、アプリケーションがＮＷＩＯバウンドであるか否か判定する。アプリケーションがＮＷＩＯバウンドであれば、ＮＷＩＯが重いため、運用改善候補探索部１６１は、ステップＳ５１３にて、ＮＷ処理またはＮＷチューニングを提案する。

ステップＳ５０１の判定でアプリケーション種別がオンライン処理でなければ、図１０に示すように、運用改善候補探索部１６１は、ステップＳ６０１にて、実行時間のうち排他待ち時間の割合が大きいか否か判定する。実行時間のうち排他待ち時間の割合が大きければ、運用改善候補探索部１６１は、ステップＳ６０２にて、排他処理の見直しを提案する。

更に、運用改善候補探索部１６１は、ステップＳ６０３にて、アプリケーションがＤＢアクセスバウンドであるか否か判定する。アプリケーションがＤＢアクセスバウンドであれば、運用改善候補探索部１６１は、ＤＢアクセスが重いため、ステップＳ６０４にて、ＳＱＬまたはＤＢサーバのチューニングを提案する。

更に、運用改善候補探索部１６１は、ステップＳ６０５にて、アプリケーションがファイルＩＯバウンドであるか否か判定する。アプリケーションがファイルＩＯバウンドであれば、運用改善候補探索部１６１は、ファイルＩＯが重いため、ステップＳ６０６にて、ＩＯ処理またはディスクのチューニングを提案する。

更に、運用改善候補探索部１６１は、ステップＳ６０７にて、アプリケーションがＮＷＩＯバウンドであるか否か判定する。アプリケーションがＮＷＩＯバウンドであれば、運用改善候補探索部１６１は、ＮＷＩＯが重いため、ステップＳ６０８にて、ＮＷ処理またはＮＷおｎのチューニングを提案する。

図１１は、本実施形態における運用管理システムが実行する再スケジューリング処理のフローチャートである。再スケジューリング処理は既存のスケジュールを改善するための処理である。そのため、既存のスケジュールから得られる情報の範囲でのスケジュールの最適化を行う。

オペレータは、本実施形態による運用管理システムを用いて、スケジュールを再度生成しなおすことができる。

図１１を参照すると、運用ポリシ入力部１４２が、ステップＳ７０１にて、運用ポリシ３２０を取得する。続いて、ステップＳ７０２にて、再スケジュール部１５３は、スケジュール入力部１４３が入力した既存のスケジュール３３０を取得する。この既存のスケジュール３３０は例えばアプリケーション稼働環境２００に現在適用されているスケジュール３３０であってもよい。

サイジング計画部１５１は、ステップＳ７０３にて、予め得られている特徴点情報、アプリケーション特性、および運用要件と、ステップＳ７０１で取得された運用ポリシ３２０とを用いてサイジングを行う。更に、再スケジュール部１５３は、ステップＳ７０４にて、ステップＳ７０２で取得した既存のスケジュール３３０を改善するスケジュールを生成する。このとき再スケジュール部１５３は、スケジュール決定部１５２に指示し、スケジューリング処理を実行させる。既存のスケジュール３３０よりも改善したスケジュールというのは、例えば、運用ポリシ３２０に適合したスケジュールである。

続いて、運用改善候補探索部１６１は、ステップＳ７０５にて、運用改善候補を探索する。運用改善候補探索部１６１は、図９および図１０に示した運用改善候補探索処理を実行する。

最後に、ステップＳ７０６にて、サイジング出力部１７１がステップＳ７０３のサイジングの結果を出力し、スケジュール出力部１７２がステップＳ７０４のスケジューリングの結果を出力し、運用改善候補出力部１７３がステップＳ７０５の運用改善候補探索の結果を出力する。

図１２は、本実施形態における運用管理システムが実行する運用要件見直し処理のフローチャートである。運用要件見直し処理は、実際のアプリケーションの稼働に基づいて運用要件の充足を評価する処理である。稼働情報に基づいてアプリケーションの特徴点情報およびアプリケーション特性を再度取得し、その新たな情報に基づいて運用要件の充足を評価する。

図１２を参照すると、稼働情報取得部１１０は、ステップＳ８０１にて、アプリケーション稼働環境２００の稼働情報取得部２１０と連携し、稼働情報３８０を取得する。次に、運用結果抽出部１２２が、ステップＳ８０２にて、稼働情報から運用結果を抽出する。

次に、特徴点抽出部１２１は、ステップＳ８０３にて、アプリケーションの特徴点を抽出し、特徴点情報を生成する。続いて、アプリケーション特性判定部１３１は、ステップＳ８０４にて、特徴点情報に基づきアプリケーション特性を判定する。更に、運用ポリシ入力部１４２が、ステップＳ８０５にて、運用ポリシ３２０を入力する。

サイジング計画部１５１は、ステップＳ８０６にて、ステップＳ８０３で取得された特徴点情報、ステップＳ８０４で取得されたアプリケーション特性、ステップＳ８０２にて、稼働情報から抽出した運用結果に含まれる運用要件、およびステップＳ８０５で取得された運用ポリシ３２０を用いてサイジングを行う。更に、スケジュール決定部１５２は、ステップＳ８０７にて、スケジューリング処理を実行する。

続いて、運用改善候補探索部１６１は、ステップＳ８０８にて、運用改善候補を探索する。運用改善候補探索部１６１は、図９および図１０に示した運用改善候補探索処理を実行する。

最後に、ステップＳ８０９にて、サイジング出力部１７１がステップＳ８０６のサイジングの結果を出力し、スケジュール出力部１７２がステップＳ８０７のスケジューリングの結果を出力し、運用改善候補出力部１７３がステップＳ８０８の運用改善候補探索の結果を出力する。オペレータは，実際の稼働情報に基づいて取得しなおした特徴点情報およびアプリケーション特性に基づいて実行したサイジング、スケジューリング、および運用改善候補探索の結果を見ることで、運用要件が適切かどうかを評価することができる。サイジングおよびスケジューリングが適切に行われていれば運用要件が適切であると推定できる。また、運用改善候補探索の結果を見れば、運用要件をどのように修正するとよいのかを知ることができる。

続いて、サイジング式の例について説明する。

オンライン処理とバッチ処理とではサイジングの考え方が異なるため、上述したようにそれぞれに基本構成に異なるサイジング式を用いる。最適化実行部１５０のサイジング計画部１５１は、アプリケーション種別に応じたサイジング式を用いて、リソース割り当てを算出する。リアルタイム性が要求されるアプリケーションであるか否かによりサイジングの仕方が異なるので、それらの算出式を分けることにより適切なサイジングが容易に可能となる。

＜１＞オンライン処理のサイジング式の例
オンライン処理のサイジング式の基本構成について説明する。ここでは、サイジング式により算出する対象を、アプリケーションの実行に割り当てる、Ｊａｖａヒープサイズ、ＣＰＵ数、および同時実行数とする。Ｊａｖａヒープサイズはメモリサイズに相当する。

ＪａｖａヒープサイズはＪａｖａヒープサイズ＝Ｎｅｗ＋Ｏｌｄにより算出する。Ｎｅｗは、Ｎｅｗ＝（Ｔ×ＭＴ×ｃｄ）＋（Ｔ×Ｒ×ＭＲ×２）であり、ＯｌｄはＯｌｄ＝（Ｔ×ＭＡ×ｆｄ）＋（Ｔ×ＭＡ×ＭＬ）＋αである。Ｔはスループットであり、Ｔ＝総処理件数（ＴＴ）÷アプリケーションのスケジュール時間と表される。スケジュール時間は、スケジュールされた実行時間であり、スケジュールに依存する。なお、運用要件にてスループットが指定されている場合には、その指定されたスループットの値をＴに用いる。ＭＴは、総メモリアロケート量である。ｃｄは、ＣｏｐｙＧＣ発生間隔であり、例えば１０秒といった通常値を用いることができる。Ｒは、実行時間である。ＭＲは、最大メモリ参照サイズである。ＭＡは、実行後参照メモリサイズである。ｆｄは、ｆｕｌｌＧＣ発生間隔である。運用要件に指定されたｆｄを用いればよい。運用要件にｆｄが指定されていない場合には、例えば３６００秒といった通常値を用いてもよい。また、ガベージコレクションが無い場合、ｆｄはアプリケーションのスケジュール時間と同じとなる。ＭＬは、最大メモリ参照寿命である。αは、アプリケーションが業務以外に使用する管理用のメモリ領域のサイズであり、例えば、１００ＭＢ程度を見込んでおけばよい。

ＣＰＵ数は、ＣＰＵ数＝Ｃ×Ｔにより算出する。ＣはＣＰＵ時間である。

同時実行数は、同時実行数＝Ｔ×（Ｒ−特徴点：その他の待ち時間）により算出する。特徴点情報である、その他待ち時間は、ＪａｖａＶＭにおける実行待ちキューでの待ち時間を指す。

＜２＞バッチ処理のサイジング式の例
バッチ処理のサイジング式の基本構成について説明する。ここでも、サイジング式により算出する対象を、アプリケーションの実行に割り当てる、Ｊａｖａヒープサイズ、ＣＰＵ数、および同時実行数とする。

ＪａｖａヒープサイズはＪａｖａヒープサイズ＝Ｎｅｗ＋Ｏｌｄにより算出する。ここでは、Ｎｅｗは、Ｎｅｗ＝αであり、ＯｌｄはＯｌｄ＝（Ｔ×ＭＴ×ｆｄ）＋（Ｔ×Ｒ×ＭＲ）＋βである。αは、アプリケーションが業務以外に使用する管理用のメモリ領域のサイズであり、例えば５００ＭＢ程度を見込んでおけばよい。ＭＴは、＜１＞と同様、総メモリアロケート量である。ｆｄは、＜１＞と同様、ｆｕｌｌＧＣ発生間隔である。Ｒは、＜１＞と同様、実行時間である。ＭＲは、＜１＞と同様、最大メモリ参照サイズである。βは、アプリケーションが業務以外に使用する管理用のメモリ領域のサイズであり、例えば、１００ＭＢ程度を見込んでおけばよい。

ＣＰＵ数は、＜１＞と同様、ＣＰＵ数＝Ｃ×Ｔにより算出する。Ｃは＜１＞と同様、ＣＰＵ時間である。

同時実行数は、＜１＞と同様、同時実行数＝Ｔ×（Ｒ−特徴点：その他の待ち時間）により算出する。特徴点情報である、その他待ち時間は、やはり、ＪａｖａＶＭにおける実行待ちキューでの待ち時間を指す。

以上説明したように、特徴点情報には、アプリケーションに割り当てるＣＰＵの個数を示すＣＰＵ数があり、＜１＞および＜２＞のいずれにおいても同様に、最適化実行部１５０は、アプリケーションのプロセスがＣＰＵを使用する時間であるＣＰＵ時間に応じてＣＰＵ数を決定する。アプリケーションのプロセスに要する時間が長ければＣＰＵ数を増やして、運用要件にて要求されるスループットを実現するといった運用が可能である。

また、特徴点情報には、アプリケーションのプロセスを並行して実行可能な個数である同時実行数があり、＜１＞および＜２＞のいずれにおいても同様に、最適化実行部１５０は、アプリケーションのプロセスが実行された時間である実行時間から、実行待ちキューでの待ち時間を減算して得られた時間に応じて同時実行数を決定する。アプリケーションのプロセスに実際に要する時間が長ければ同時実行数を増やして運用要件にて要求されるスループットを実現することができる。

図１３は、本実施形態における特徴点情報テーブルの一例を示す図である。

図１３を参照すると、アプリケーション毎に、アプリケーションＩＤ（アプリＩＤ）、実行時間（Ｒ）、ＣＰＵ時間（Ｃ）、総メモリアロケート量（ＭＴ）、最大メモリ参照サイズ（ＭＲ）、最大メモリ参照寿命（ＭＬ）、実行後参照メモリサイズ（ＭＡ）、ＤＢアクセス時間、ファイルＩＯ時間、ＮＷＩＯ時間、排他待ち時間、スループット、その他待ち時間、ＧＣ占有率、Ｊａｖａヒープ確保サイズ、ＧＣ所要時間、ＧＣ後ヒープサイズ残量が記録されている。

実行時間は、内部保留時間であり、クライアントから見たレスポンス時間からネットワークによる通信時間を引いた時間である。その他待ち時間は、ＪａｖａＶＭにおける実行待ちキューでの待ち時間を指し、実行時間から、ＣＰＵ時間、ＤＢアクセス時間、ファイルＩＯ時間、ＮＷＩＯ時間、排他待ち時間を除いた時間である。

アプリケーションの実行時間の間に、累積的にメモリのアロケートが行われる。実行時間の間にアロケートされたメモリの総量が、総メモリアロケート量である。実行中のアプリケーションにアロケートされているメモリのうち、参照されなくなった部分（ゴミ）を除いた部分（アクティブなメモリ）のメモリサイズを最大メモリ参照サイズと呼ぶ。また、アプリケーションの実行が終わったときに参照される部分として残っていたメモリのメモリサイズを実行後参照メモリサイズと呼ぶ。また、実行後参照メモリサイズのメモリが残り続ける期間を最大メモリ参照寿命と呼ぶ。

なお、図１３においては、図１４に示すアプリケーション特性の判定にて参照される値を〇（丸印）で示している。

図１４は、本実施形態におけるアプリケーション特性テーブルの例を示す図である。

図１４を参照すると、アプリケーション毎に、アプリケーションＩＤ、アプリケーション種別、ＣＰＵバウンド、ＤＢアクセスバウンド、ファイルＩＯバウンド、ＮＷＩＯバウンド、ＣＰＵコスト大、メモリコスト大、排他割合大、ＧＣ所要時間大、ＧＣ占有率大という項目の値が記録されている。ＣＰＵバウンド、ＤＢアクセスバウンド、ファイルＩＯバウンド、ＮＷＩＯバウンド、ＣＰＵコスト大、メモリコスト大、排他割合大、ＧＣ所要時間大、およびＧＣ占有率大には、該当することを「１」により示すフラグが記録される。アプリケーション種別としては、オンライン処理、オンバッチ処理、オフバッチ処理の種別が記録されている。

図１５は、本実施形態における運用要件テーブルの例を示す図である。

図１５を参照すると、アプリケーション毎に、アプリケーションＩＤ、総処理件数（ＴＴ）、スループット（Ｔ）、実行時間（Ｒ）、サービス時間帯（ＳＴ）、先行条件、フルＧＣ間隔（ＦＬ）、およびフルＧＣ時間（ＦＤ）が記録されている。先行条件は、当該アプリケーションを実行する前に完了している必要のあるアプリケーションが設定されている。先行条件の欄には、事前に完了している必要のあるアプリケーションのアプリケーションＩＤが記録されている。実行時間の欄に括弧で示された数値は、最悪値を表している。最悪値は、括弧なしで示されている通常の実行時間に加えて、フルＧＣが発生した場合にフルＧＣに要する時間（フルＧＣ時間（ＦＤ））を考慮した時間である。

次に、運用ポリシの例について説明する。

運用ポリシは、運用要件およびその他の条件に基づいてアプリケーション毎に設定される。その他の条件は例えば運用コストなどである。運用ポリシには、複数項目が指定された運用要件のうち、どの項目を優先させるかというような内容が設定される。図１６は、運用ポリシの例について説明するための図である。図１６の例では、４項目の運用要件が設定されている。要件（１）は、ピーク時のスループットが１万件という要件である。要件（２）は、実行時間が２秒以内という要件である。要件（３）は、データ検索対象件数が１０万件という要件である。また、要件（４）は、平均表示件数が、１リクエスト当たり３０件という要件である。

図１６には２つの運用ポリシの例が示されている。最初の運用ポリシは、月末の繁忙期に適用することを想定した運用ポリシである。目的関数として、要件（２）を絶対条件とすることが設定されている。また、制約条件として、要件（１）、要件（３）、要件（４）、およびＧＣがないという条件が課されている。最適化処理において目的関数は制約条件よりも優先度が高い。２つ目の運用ポリシは、通常時に適用することを想定した運用ポリシである。目的関数として、運用コストを最小化することが設定されている。また、制約条件として、要件（２）の実行時間が２．６秒以内され、更に、要件（１）、要件（３）、要件（４）、およびＧＣを許容するという条件が設定されている。

図１６に示したように、運用ポリシには、コストに関する指定項目と性能に関する指定項目を含む複数の指定項目に優先度の重みづけが可能である。例えば、運用コスト最小化というのはコストに関する指定項目である。一方、要件（２）の実行時間など運用要件には性能に関する指定項目が含まれている。コスト優先あるいは性能優先など指定項目に優先度をつけて業務システムを適切に運用することができる。

また、図１６に示したように、同じ運用要件から複数の異なる運用ポリシを設定することができ、また複数の運用ポリシを時期により切り替えて適用することが可能である。

次にスケジュールの例について説明する。スケジューリング処理の結果であるスケジュールがスケジューリング結果テーブルに記録される。スケジューリング処理に適用した運用ポリシが異なれば、同じ運用要件、リソース制約、アプリケーションに対して得られえるスケジュールも異なる。

図１７は、本実施形態におけるスケジューリング結果テーブルの例を示す図である。

図１７には、運用ポリシがコスト優先の場合と、運用ポリシが性能優先の場合のそれぞれのスケジューリング結果テーブルが対比可能に示されている。スケジューリング結果テーブルには、当該アプリケーションのアプリケーションＩＤ、当該アプリケーションが利用可能なＣＰＵ数およびメモリサイズ、当該アプリケーションに許容されるプロセス数および同時実行数、当該アプリケーションを実行する実行期間、開始時刻および終了時刻が示されている。スケジューリングの結果は、各アプリケーションの開始時刻および終了時刻に表されている。テーブルを対比すると分かるように、複数のアプリケーションによる全体業務が終了する時刻が、コスト優先の場合には翌日の１：００となっているのに対して、性能優先の場合には２２：００と早まっている。

図１８は、本実施形態によるスケジューリング結果の第１例について説明するための図である。第１例としてコスト優先のスケジューリング結果のタイムチャートが示されている。これは図１７の上段に示したスケジューリング結果テーブルに対応する。

図１９は、本実施形態によるスケジューリング結果の第２例について説明するための図である。第２例として性能優先のスケジューリング結果のタイムチャートが示されている。これは図１７の下段に示したスケジューリング結果テーブルに対応する。

図１８と図１９を対比すると、図１８のスケジュールよりも図１９のスケジュールの方がＣＰＵおよびメモリを多く使用するが、全体業務の終了時刻が早くなっていることが分かる。

運用管理システム１００は、スケジューリング結果を図１８や図１９に示したように画面に視覚的に表示することにしてもよい。それにより、オペレータはスケジューリング結果を視覚により容易に理解し、把握することが可能となる。

図２０は、本実施形態における運用改善候補の例を示す図である。

運用改善候補探索部１６１により得られた運用要改善候補は運用改善候補出力部１７３から出力される。運用改善候補出力部１７３は、運用改善候補探索部１６１が図９および図１０に示した改善候補探索処理を実行することにより抽出された運用改善候補を出力する。図２０を参照すると、運用改善の対象となるアプリケーションのアプリケーションＩＤと、提示する運用改善候補の内容とが対応付けて示されている。その際、運用改善候補出力部１７３は、例えば運用改善候補の一覧を画面に表示してもよいし、運用改善候補の一覧情報をファイルに出力してもよい。

次に、特徴点情報に基づくスケジューリングの一例について説明する。ここではガベージコレクションを考慮したスケジューリングについて説明する。

図２１は、本実施形態におけるサイジング処理およびスケジューリング処理の様子を説明するための図である。図２１には、特徴点情報テーブルとスケジューリング結果テーブルが示されている。特徴点情報テーブルにて太線の四角形で囲われた部分の情報が、その四角形と矢印で結ばれた、スケジューリング結果テーブルにて楕円で囲われた部分の情報の生成に利用される。

図２１においてアプリケーションＩＤ＝０００１のアプリケーションに着目すると、特徴点情報テーブルのスループット、その他待ち時間、ＧＣ占有率、およびＪａｖａヒープ確保サイズの情報が、スケジューリング結果テーブルのメモリサイズを決めるのに用いられていることが分かる。具体的には、ＧＣ占有率が高いことを考慮してＪａｖａヒープ確保サイズを拡大するために、メモリサイズを１０ＧＢから１２ＧＢに拡大している。

このように、本例では、特徴点情報としてガベージコレクションのＧＣ占有率があり、最適化実行部１５０は、ガベージコレクションのＧＣ占有率に基づいてアプリケーションに割り当てるメモリのサイズを決定している。ここでＧＣ占有率とは、ＧＣの処理時間（アプリケーションの実行が停止する時間と同じ）が、単位時間あたりに占める割合を示す。一般にＧＣによるオーバヘッドに起因してアプリケーションのスループットやレスポンスといった性能が劣化する。しかし、本例の上記構成によれば、ＧＣによるオーバヘッドの指標としてＧＣ占有率を算出し、その値に基づいてアプリケーションに割り当てるメモリのサイズを決定するので、ＧＣによる性能劣化を考慮しても運用要件を満たすようなサイジングおよびスケジューリングを行うことができる。

また、アプリケーションＩＤ＝０００２で示されたアプリケーションに着目すると、特徴点情報テーブルにおけるＧＣ所要時間とＧＣ後Ｊａｖａヒープサイズ残量との情報が、スケジューリング結果テーブルのメモリサイズ、プロセス数、および同時実行数を決めるのに用いられていることが分かる。具体的には、ＧＣ所要時間が長いため、アプリケーションをプロセスに分割してプロセス数を１から３に増やしていることが分かる。

このように、本例では、特徴点情報としてガベージコレクションの所要時間があり、最適化実行部１５０は、ガベージコレクションの所要時間に応じて、アプリケーションのプロセス数を決定している。本例の上記構成によれば、ＧＣによるオーバヘッドの指標としてＧＣの所要時間を算出し、その値に基づいてアプリケーションのプロセス数を決定するので、ＧＣによる性能劣化を考慮して運用要件を満たすようなサイジングおよびスケジューリングを行うことができる。

以上説明したように、本実施形態によれば、アプリケーション稼働環境２００は、リソースとしてメモリを有し、最適化実行部１５０は、メモリの割り当てについて、アプリケーション特性に基づいて、メモリをどのような領域の構成とするか決定し、特徴点情報に基づいて各領域のサイズを決定する。アプリケーションの定量的性質に基づいてメモリの領域構成を決定し、定量的性質に基づいて各領域のサイズを決定するので、好適な領域構成および領域サイズを有するメモリをアプリケーションに提供することができる。

なお、上述した本発明の実施形態は、本発明の説明のための例示であり、本発明の範囲をそれらの実施形態にのみ限定する趣旨ではない。当業者は、本発明の要旨を逸脱することなしに、他の様々な態様で本発明を実施することができる。

１００…運用管理システム、１１０…稼働情報取得部、１２０…稼働情報編集部、１２１…特徴点抽出部、１２２…運用結果抽出部、１２３…スケジュール結果抽出部、１３０…特徴点解析部、１３１…アプリケーション特性判定部、１４０…入力部、１４１…運用要件入力部、１４２…運用ポリシ入力部、１４３…スケジュール入力部、１５０…最適化実行部、１５１…サイジング計画部、１５２…スケジュール決定部、１５３…再スケジュール部、１６０…運用改善候補提示部、１６１…運用改善候補探索部、１７０…出力部、１７１…サイジング出力部、１７２…スケジュール出力部、１７３…運用改善候補出力部、２００…アプリケーション稼働環境、２１０…稼働情報取得部、３１０…運用要件、３２０…運用ポリシ、３３０…スケジュール、３４０…サイジング情報、３５０…スケジュール、３６０…運用改善候補、３７０…アプリケーション、３８０…稼働情報

Claims (16)

1. アプリケーションの実行に利用するリソースを定めた第１リソース割り当ておよびリソースをアプリケーションの実行に利用する時間帯を定めた第１スケジュールに従って計算機にて実行されたアプリケーションの履歴を記録した稼働情報を与えられ、前記稼働情報に基づいて、前記アプリケーションの所定の定量的性質を表す特徴点情報を生成する稼働情報編集部と、
   前記特徴点情報に基づいて、前記アプリケーションの所定の定性的性質を表すアプリケーション特性を判定するアプリケーション特性判定部と、
   前記アプリケーションに関連して要求される性能を指定した運用要件と、前記計算機にて利用可能なリソースの制約を示すリソース制約と、前記計算機の運用の指針を示す運用ポリシとを与えられ、前記アプリケーションの前記特徴点情報および前記アプリケーション特性に基づいて、前記運用要件および前記リソース制約を満たし、前記運用ポリシに示された指針に従うように、前記計算機にて利用する第２リソース割り当ておよび第２スケジュールを算出する最適化実行部と、
   を有する計算機運用管理システム。
2. 前記アプリケーション特性に基づき、前記アプリケーションまたは前記計算機の変更を伴う運用改善策を提案する運用改善候補探索部を更に有する、請求項１に記載の計算機運用管理システム。
3. 前記第２リソース割り当ておよび前記第２スケジュールを前記計算機に適用し、前記運用改善策を、前記計算機を運用する運用者に提示する出力部を更に有する、請求項２に記載の計算機運用管理システム。
4. 前記計算機は、前記リソースとしてメモリおよびＣＰＵを有し、
   前記稼働情報編集部は、前記特徴点情報として少なくとも、前記アプリケーションの所定の実行単位ごとに割り当てるメモリ領域の総量である総メモリアロケート量と、前記実行単位を実行するのに前記ＣＰＵが稼働した時間であるＣＰＵ時間と、前記実行単位を実行するのに要した時間である実行時間と、を生成する、
   請求項１に記載の計算機運用管理システム。
5. 前記アプリケーション特性判定部は、前記アプリケーション特性として、オンライン処理か否かを含むアプリケーション種別を前記実行時間に基づいて判定し、前記アプリケーション種別がオンラインであれば、メモリコストを前記総メモリアロケート量に基づいて判定し、ＣＰＵコストを前記ＣＰＵ時間に基づいて判定する、請求項４に記載の計算機運用管理システム。
6. 前記最適化実行部は、前記アプリケーション種別に応じて前記第２リソース割り当てを算出する算出式を選択する、
   請求項５に記載の計算機運用管理システム。
7. 前記運用ポリシは、コストに関する指定項目と性能に関する指定項目を含む複数の指定項目に優先度の重みづけが可能である、請求項１に記載の計算機運用管理システム。
8. 前記計算機は、前記リソースとしてメモリを有し、
   前記最適化実行部は、前記メモリの割り当てについて、前記アプリケーション特性に基づいて、前記メモリをどのような領域の構成とするか決定し、前記特徴点情報に基づいて前記各領域のサイズを決定する、請求項１に記載の計算機運用管理システム。
9. 前記特徴点情報としてガベージコレクションのメモリ占有率があり、
   前記最適化実行部は、前記ガベージコレクションのメモリ占有率に基づいて前記アプリケーションに割り当てるメモリのサイズを決定する、
   請求項１に記載の計算機運用管理システム。
10. 前記特徴点情報としてガベージコレクションの所要時間があり、
    前記最適化実行部は、前記ガベージコレクションの所要時間に応じて、前記アプリケーションのプロセス数を決定する、
    請求項１に記載の計算機運用管理システム。
11. 前記特徴点情報には、前記アプリケーションに割り当てるＣＰＵの個数を示すＣＰＵ数があり、
    前記最適化実行部は、前記アプリケーションのプロセスがＣＰＵを使用する時間であるＣＰＵ時間に応じて前記ＣＰＵ数を決定する、
    請求項１に記載の計算機運用管理システム。
12. 前記特徴点情報には、前記アプリケーションのプロセスを並行して実行可能な個数である同時実行数があり、
    前記最適化実行部は、前記アプリケーションのプロセスが実行された時間である実行時間から、実行待ちキューでの待ち時間を減算して得られた時間に応じて前記同時実行数を決定する、
    請求項１に記載の計算機運用管理システム。
13. 前記リソース制約は、前記計算機のハードウェア構成によるＣＰＵ数およびメモリ容量の制限を含み、
    前記運用改善候補探索部は、前記計算機のＣＰＵまたはメモリを追加または削除する運用改善策を提案する、
    請求項２に記載の計算機運用管理システム。
14. 前記最適化実行部は、前記第２リソース割り当てとして、前記アプリケーションに割り当てるＣＰＵ、メモリ領域、およびプロセスの同時実行数を算出する、請求項１に記載の計算機運用管理システム。
15. 前記最適化実行部は、前記第２スケジュールとして、前記アプリケーションの開始時刻および終了時刻と利用するリソースとを算出する、請求項１に記載の計算機運用管理システム。
16. コンピュータが、
    アプリケーションの実行に利用するリソースを定めた第１リソース割り当ておよびリソースをアプリケーションの実行に利用する時間帯を定めた第１スケジュールに従って計算機にて実行されたアプリケーションの履歴を記録した稼働情報を与えられ、前記稼働情報に基づいて、前記アプリケーションの所定の定量的性質を表す特徴点情報を生成し、
    前記特徴点情報に基づいて、前記アプリケーションの所定の定性的性質を表すアプリケーション特性を判定し、
    前記アプリケーションに関連して要求される性能を指定した運用要件と、前記計算機にて利用可能なリソースの制約を示すリソース制約と、前記計算機の運用の指針を示す運用ポリシとを与えられ、前記アプリケーションの前記特徴点情報および前記アプリケーション特性に基づいて、前記運用要件および前記リソース制約を満たし、前記運用ポリシに示された指針に従うように、前記計算機にて利用する第２リソース割り当ておよび第２スケジュールを算出する、
    計算機運用管理方法。

Images