(57)【要約】【課題】  近年のシステムでは、同一システムの上で複数種類の業務が稼動している。その業務の割合(業務パターン)は設計・開発段階で定義される。しかし設計・開発段階で運用段階の業務パターンを正確に予測することは困難である。また、業務パターンは、時間変動，季節変動，機能変更等の要因により刻一刻と変動する。【解決手段】  システムのアクセスログを監視することにより業務パターンを抽出する。その業務パターンにおける応答時間およびスループットを性能予測シミュレーション部により算出する。予測性能がシステムの要求性能を満足しない場合には、判定ポリシーにより構成変更の対象を特定し、性能予測シミュレーションにより再計算を繰り返す。そして要求性能を満足する最適な構成を提案構成として出力装置に提示する。【選択図】  図１
2005099973.tif 000002
【特許請求の範囲】
【請求項１】
業務パターンの変動を考慮したシステムの運用管理において、システムのアクセスログを収集して業務パターンを抽出する手段と、システム構成からハードウェア構成情報を抽出する手段と、前記に抽出した業務パターンおよびハードウェア構成情報から性能予測シミュレーションによって応答時間とスループットおよび各構成のリソース消費量を算出する手段と、前記に算出した応答時間とスループットから要求性能を満足していることを判定する手段と、システム管理者にハードウェア構成の拡張または縮小を警告する手段を備えることを特徴とする運用管理システム。
【請求項２】
前記の性能予測シミュレーションにおいて算出された各構成のリソース消費量から、拡張または縮小するハードウェア構成の対象を特定して最適な構成を提示する手段、を備えることを特徴とする請求項１記載の運用管理システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、性能と価格を考慮したシステムを保守するシステム運用管理方法に関し、特にサービスレベルの低下やサーバダウンを予防するための技術に関する。
【背景技術】
【０００２】
近年のシステムでは、ビジネス環境の急変に伴い、多くの既存ＩＴシステムとの統合や再編が行われており、同一システムの上で複数種類の業務が稼動している。その業務の割合(以降では業務パターンと呼ぶ)は、設計・開発段階で性能要件として定義し、その性能要件を満足するシステム構成を決定する（例えば、特許文献１参照）。
【０００３】
しかし、設計・開発段階で運用段階の業務パターンを正確に予測することは困難である。また、業務パターンは、時間変動，季節変動，機能変更等の要因により刻一刻と変動する。時間変動とは、朝にはログイン処理、夜にはバッチ処理など、時間により特定の業務が集中するような変動を指す。季節変動とは、月末や大型連休前などに、特定の業務が特定の時期にのみ集中するような変動を指す。機能変更とは、システム機能の追加や変更等により、システムに要求される負荷がダイナミックに変更されるような変動を指す。
【０００４】
業務パターンの変動により、システムへの負荷の高い業務の割合が高くなると、システムの最大処理件数(限界スループット)が低下し、要求性能を満足しない状態が発生する。この状態でピーク時を迎えると、設計・開発段階での要求性能よりも前にサービスレベルの低下(応答時間が遅くなる状態)やサーバダウン(サーバが停止する状態)が発生する、という問題が発生する。
【０００５】
一方、業務パターンの変動により、システムへの負荷の高い業務の割合が低くなると、限界スループットが高くなり、要求性能を過剰に満足している状態が発生する。この状態ではシステムに過剰な投資を行っている、という問題が発生する。
【０００６】
計算機システムの業務量の変動やハードウェア構成の変更時の性能を予測する性能予測装置については、特許文献２に記載されている。その概要は、計算機システムの稼動情報とハードウェア構成情報とジョブ実行情報によりジョブ稼動状況をシミュレーションし、ユーザ指定による業務量の変更やハードウェア構成変更の指示により、ジョブ稼動状況の変化を予測するものである。
【０００７】
性能維持のための予防的対処を実現するＷＷＷサイトの性能監視装置については、特許文献３に記載されている。その概要は、ＷＷＷサイトにおけるアクセス量の時系列データを蓄積し、統計的な手法で将来的なアクセス変動を予測してアクセス毎の性能値を算出し、算出された性能値を元に定められた性能が維持できるか否かを判断するものである。
【０００８】
性能と価格を考慮したシステムを提案するシステム提案方法については、特許文献４に記載されている。その概要は、性能と価格を考慮したシステムを提案するシステム提案装置において、システム構成の定義内容を組み合わせたそれぞれの構成について応答時間及び合計価格を算出し、性能要件及び価格要件を満たすものを提案対象の構成として出力するものである。
【０００９】
【特許文献１】特開平８−１３７７２５号公報
【００１０】
【特許文献２】特開平５−３２４３５８号公報
【特許文献３】特開２００２−２６８９２２号公報
【特許文献４】特開２００２−１８３４１６号公報
【発明の開示】
【発明が解決しようとする課題】
【００１１】
上記の従来技術では業務パターンの変動の点について配慮がされていない。業務パターンが変動することにより、各サーバにおけるリソース消費量のパターンが変動するため、システムの最大処理件数(限界スループット)も変動してしまう。そのため限界スループットが要求性能を満足しない場合には、ピーク時にシステムのサービスレベルの低下やサーバダウンが発生するという問題があった。また要求性能を過剰に満足する場合には、システムに過剰な投資を行っているという問題があった。
【００１２】
本発明の目的は、刻一刻と変動する業務パターンを監視して、その業務パターンを元に性能予測を行うことにより、現在の業務パターンにおいて要求性能を満足する最適なシステム構成を提示することにある。
【課題を解決するための手段】
【００１３】
上記目的を達成するために、運用管理対象システムのアクセスログを監視することにより業務パターンを抽出し、その業務パターンにおける応答時間およびスループットおよび各構成におけるリソース消費量を算出し、性能要件を満足する最適な構成を提案構成として提示するものである。
【００１４】
本発明では、まずアクセスログを常時監視することにより、業務パターンを抽出する。
【００１５】
次に、前記抽出した業務パターン及び現在のハードウェア構成情報を元に、性能予測シミュレーションを実行し、システムの応答時間とスループット、および各構成におけるリソース消費量を算出する。
【００１６】
前記の算出により得られた応答時間とスループットが、要求性能を満足していることを判定し、不足または過剰であればハードウェア構成の拡張または縮小の警告メッセージを発行する。
【００１７】
リソース消費量の情報から、拡張または縮小するべきハードウェア構成を特定する条件を、判定ポリシーとして格納する。前記の算出により得られたリソース消費量と、判定ポリシーにより、システムの拡張または縮小の対象を特定する。
【００１８】
ハードウェア構成の拡張または縮小をハードウェア構成情報にフィードバックし、性能予測シミュレーションによりシステムの拡張または縮小の効果を算出する。前記の算出を、要求性能を満足するまで繰り返す。
【発明の効果】
【００１９】
本発明によれば、現在の業務パターンにおいて要求性能を満足する最適な構成を提示できるので、業務パターンの変動に合わせたシステム構成に最適化することができる。そのためシステムの性能不足を事前に検知することができるため、ピーク時におけるシステムのサービスレベルの低下やサーバダウンを事前に予防する効果がある。
【００２０】
また、過剰なシステムリソースを検知することができるため、過剰なシステム投資を抑え、コストを低減する効果がある。
【発明を実施するための最良の形態】
【００２１】
以下、本発明の実施例を図面を用いて具体的に説明する。
【実施例１】
【００２２】
図１は、本発明の実施例の構成を示す。図において、運用管理対象システム１０１は運用管理の対象となるシステム、運用管理装置１０２は運用管理対象システムの最適な構成を提示するための運用管理装置である。
【００２３】
運用管理対象システム１０１は、複数のサーバ群で構成されており、各サーバ群で異なる業務を実行する。図１の例では、業務Ａがサーバ群１、業務Ｂがサーバ群１とサーバ群２とサーバ群３、業務Ｃがサーバ群１とサーバ群２を使用することを示している。各サーバ群はさらに複数のサーバで構成されており、同じサーバ群では同じ業務を実行することができ、負荷を分散する。情報収集エージェント１０３は、各サーバにおける業務の稼動情報を収集し、アクセスログ１０４に格納する。また情報収集エージェント１０３は、各サーバのＣＰＵやメモリおよびディスク等のサーバ固有情報を、サーバ性能情報１０５に格納する。アクセスログ１０４およびサーバ性能情報１０５は、ネットワークを用いて定期的に運用管理装置１０２に収集される。このネットワークはＬＡＮでも公衆網でもかまわない。したがって運用管理装置１０２は、運用管理対象システム１０１と同じサイトに存在しても良いし、公衆網を経由して異なるサイトに存在しても良い。
【００２４】
業務パターン抽出部１０６は、各サーバから収集されたアクセスログ１０４から、業務が実行されている割合（以降では業務パターン１０７と呼ぶ）を抽出する。また構成情報抽出部１０８は、各サーバから収集されたサーバ性能情報１０５からハードウェア構成情報１０９を抽出する。性能データベース１１０は、業務毎に消費するサーバのリソース量を格納する。性能予測シミュレーション部１１１は、運用管理対象システムの応答時間とスループットを算出する。システムの要求性能１１２は運用管理対象システムに要求される処理件数や応答時間およびピーク時の多重度の情報を格納する。判定ポリシー１１３は、拡張または縮小するハードウェア構成を特定する条件を格納する。要求性能判定部１１４は、予測された性能が要求性能を満足していることを判定する。出力装置１１５は、判定の結果およびハードウェア構成の変更箇所と効果を表示する。出力装置１１５と性能予測装置１０２は、同一の装置に実装しても良い。
【００２５】
以下、図２のフローチャートを参照しながら、性能最適化要求が入力されてから、性能最適化が終了するまでの本発明の動作を説明する。最適化要求は、１時間毎など一定の間隔で入力しても良いし、障害発生時やシステム管理者の手入力でも良い。ただし最適化要求の間隔を短くするとアクセスログ１０４やサーバ性能情報１０５を収集する負荷やハードウェア構成変更の負荷が高くなるため、適度な間隔で入力する。
【００２６】
ステップ２０１は、各サーバに格納されているアクセスログ１０４を収集するステップである。ステップ２０２は、収集したアクセスログ１０４から業務パターン１０７を抽出するステップである。
【００２７】
ステップ２０３は、各サーバに格納されているサーバ性能情報１０５を収集するステップである。
【００２８】
ステップ２０４は、収集したサーバ性能情報１０５からハードウェア構成情報１０９を抽出するステップである。
【００２９】
ステップ２０５は、性能予測のシミュレーションを実行するステップである。このステップにおいて、現状または構成変更後の予測性能を算出する。性能予測シミュレーション部１１１は、前記で抽出された業務パターン１０７およびハードウェア構成情報１０９と、性能データベース１１０を元に、待ち行列理論や性能シミュレータを用いて、業務を同時に実行する人数（以降では多重度と呼ぶ）を変化したときの応答時間やスループットおよびリソース消費量を算出する。待ち行列理論や性能シミュレータでは、業務毎のリソース使用時間と発生頻度を入力することにより、応答時間とスループットおよび各構成におけるリソース消費量を算出することができる。業務毎のリソース使用時間は、性能データベース１１０に格納されている情報を入力する。業務毎の発生頻度は、抽出された業務パターン１０７と１から順に変化させた多重度を元に入力する。
【００３０】
ステップ２０６は、前記で算出された予測性能がシステムの要求性能１１２を満足していることを判定するステップである。要求性能判定部１１４により、性能予測シミュレーション部１１１で算出された予測性能と、システムの要求性能１１２とを比較する。予測性能がシステムの要求性能１１２の許容範囲（例えば１００％〜１２０％）に収まっている場合には、ステップ２０７において出力装置１１５に現在のハードウェア構成を最適構成として提示し、性能最適化を終了する。
【００３１】
ステップ２０８は、システム管理者にハードウェア構成の拡張または縮小を警告するステップである。ステップ２０６の判定において許容範囲を下回っている場合、システムの要求性能を満たしていない状態であるため、システム管理者にハードウェア構成の拡張を要求する警告メッセージを発行する。一方、ステップ２０６の判定において許容範囲を上回っている場合、システムの要求性能を過剰に満たしている状態であるため、システム管理者にハードウェア構成の縮小を要求する警告メッセージを発行する。
【００３２】
ステップ２０９は、システム管理者に予測性能の結果を表示するステップである。ステップ２０５で算出された予測性能およびシステムの限界時における各サーバのリソース消費量を表示する。また、システムの限界時における各サーバのリソース消費量と判定ポリシー１１３から、拡張および縮小するハードウェア構成の対象を特定し、システム管理者に提示する。
【００３３】
ステップ２１０は、ハードウェア構成の拡張および縮小をハードウェア構成情報１０９にフィードバックするステップである。ハードウェア構成の拡張および縮小の対象は、システム管理者が対話的に指示しても良い。
【００３４】
運用管理対象システム１０１が、自動的に構成を変更する機能（システム管理者の手作業によるシステム構成の変更が不要な機能）を持つ場合には、ハードウェア構成を変更するステップ２１０と連動することにより、自動的に最適構成を維持することができる。
【００３５】
前記でフィードバックされたハードウェア構成情報１０９を用いて、ステップ２０５の性能予測シミュレーションにおいて、システムの拡張または縮小後の予測性能を再計算する。前記の再計算を、予測性能が要求性能を満足するまで繰り返す。
【００３６】
図３は、業務パターン抽出部１０６で作成されるテーブルの一例を示す。図３（ａ）の  キーワードテーブル３０１は、業務が実行されたことを特定するキーワード３０４を格納する。図の例では、/homepage.htmlが業務Ａ（ホームページの表示)、/jsp/kensaku.jspが業務Ｂ（ファイルの検索)、/cgi/download.cgiが業務Ｃ（ファイルのダウンロード）を特定するキーワードである。図３（ｂ）のアクセスログテーブル３０２は、各サーバで採取されたアクセスログ１０４を収集して格納する。キーワード３０４がアクセスログテーブル３０２に記録されているとき、対応する業務が１件実行されたことを示す。したがってアクセスログテーブル３０２から、実行された業務を特定するキーワード３０４を検索して集計することにより、各業務の実行件数３０５が算出される。図３（ｃ）の業務パターンテーブル３０３は、各業務の実行件数３０５と、各業務が実行している割合を表す業務パターン１０７を格納する。図の例では２０件の業務が実行され、その内訳は、業務Ａ（ホームページの表示）が５０％（１０件）、業務Ｂ（ファイルの検索）が２０％（４件）、業務Ｃ（ファイルのダウンロード）が１５％（３件）であったことを示す。
【００３７】
図４は、構成情報抽出部１０８で作成されるテーブルの一例を示す。図４（ａ）のサーバ性能情報１０５は、各サーバに格納されている。図４（ｂ）のハードウェア構成情報１０９は、各サーバのサーバ性能情報１０５を収集して作成され、各サーバ群を構成するサーバ台数４０１と、ＣＰＵの種類４０２と、ＣＰＵの数４０３と、メモリ量４０４と、ディスクの転送能力を示すディスク性能４０５が格納されている。図の例ではサーバ群１は４台のサーバで構成されており、ＣＰＵの種類はＣＰＵ名１、ＣＰＵ数は２個、メモリ量は２ＧＢ、ディスク性能は１ＭＢ／秒であることを示している。
【００３８】
図５は、各業務を１件実行するために必要な各サーバ群のリソース消費量を格納する性能データベース１１０の一例を示す。このリソース消費量は設計・開発段階にあらかじめ測定して、性能データベースに格納する。図の例では、サーバの構成５０１、サーバ群１で消費されるＣＰＵ使用時間５０２、メモリ使用量５０３、ディスク使用時間５０４、サーバ群２で消費されるＣＰＵ使用時間５０５、メモリ使用量５０６、ディスク使用時間５０７が格納されている。業務Ａでサーバ構成にＣＰＵ名１を使用した場合には、サーバ群１において、ＣＰＵを０．３３秒、メモリを１０ＫＢ、ディスクを０．２５秒消費することを示している。
【００３９】
図６は、待ち行列理論を用いた性能予測シミュレーションの算出モデルを示す。
サーバ群毎に待ち行列が発生する。各待ち行列の窓口数は、そのサーバ群のサーバ台数である。業務毎の発生頻度は、業務パターン１０７と１から順に変化させた多重度を元に入力する。多重度２０人の場合、５０％の１０人が業務Ａ、２０％の４人が業務Ｂ、１５％の３人が業務Ｃを同時に行っている。業務毎のリソース消費量は、性能データベース１１０を用いる。この算出モデルにより、各構成における応答時間やスループットおよびリソース消費量が算出される。各構成における応答時間の合計が、システムの応答時間を示す。
【００４０】
図７は、応答時間とスループットの算出結果一例を示す。多重度７０１は運用管理対象システム１０１において業務を同時に実行する人数、応答時間７０２は多重度７０１を変化したときの応答時間（秒）、スループット７０３は多重度７０１を変化したときのスループット（件／秒）を示す。変曲値７０５は、リソースの競合により応答時間が急激に変化する多重度を示す。多重度７０１が増加すると、応答時間７０２は変曲値７０５までは緩やかに上昇し、変曲値７０５を越えると急激に上昇する。一方スループット７０３は、変曲値７０５までは多重度７０１に比例して増加し、変曲値７０５を越えると一定値（限界スループット７０４）に近づく。この関係グラフより、運用管理対象システム１０１に対して業務パターン１０７で業務を実行した場合には、変曲値７０５でシステムの限界となることを示している。
【００４１】
図８は、ステップ２０５で算出されるリソース消費量の一例を示す。図の例では多重度毎に、サーバ群１で消費されるＣＰＵ使用率８０１、メモリ使用率８０２、ディスク使用率８０３、サーバ群２で消費されるＣＰＵ使用率８０４、メモリ使用率８０５、ディスク使用率８０６が算出されている。
【００４２】
図９は、ハードウェア構成を変更する条件を格納する判定ポリシー１１３の一例を示す。この例では、ＣＰＵ使用率の判定条件９０１、メモリ使用率の判定条件９０２、ディスク使用率の判定条件９０３、判定結果９０４が格納されている。図８の例では、サーバ群１のリソース使用率８０７が高く、図９の判定ポリシー項番１の条件に合致するため、サーバ群１のサーバ台数を増加する、と判定する。またサーバ群２のＣＰＵ使用率８０８が低く、判定ポリシー項番６の条件に合致するため、サーバ群２のＣＰＵ数を減少する、と判定する。
【００４３】
図１０は、出力装置１１５で表示される判定の結果およびハードウェア構成の変更箇所と効果の一例を示す。この例では、現状の業務パターン１００１、現状のハードウェア構成１００２、現状の予測性能１００３、現状のシステム限界時における各サーバのリソース消費量１００４、性能最適化後のハードウェア構成１００５、性能最適化後の予測性能１００６、性能最適化後のシステム限界時における各サーバのリソース消費量１００７、システム管理者への警告メッセージ１００８が表示されている。図の例では、サーバ群１のサーバ台数を増加するメッセージと、サーバ群２のＣＰＵ数を減少するメッセージを発行し、性能最適化後の予測性能に与える効果を表示している。
【００４４】
以上の様に、刻一刻と変動する業務パターンを監視して、その業務パターンを元に性能予測を行うことにより、現在の業務パターンにおいて要求性能を満足する最適なシステム構成を提示することができる。これにより、サービスレベルの低下やサーバダウンを事前に予防することができる。また、過剰なシステム投資を抑え、コストを低減することができる。
【図面の簡単な説明】
【００４５】
【図１】本発明の概要である。
【図２】本発明の一実施例のフローチャートである。
【図３】業務パターンの抽出の例である。
【図４】ハードウェア構成情報の抽出の例である。
【図５】性能データベースの例である。
【図６】性能予測シミュレーションモデルの例である。
【図７】応答時間とスループットの算出結果の例である。
【図８】リソース消費量の算出結果の例である。
【図９】判定ポリシーの例である。
【図１０】ハードウェア構成の表示の例である。
【符号の説明】
【００４６】
１０１：運用管理対象システム、１０２：運用管理装置、１０３：情報収集エージェント、
１０４：アクセスログ、１０５：サーバ性能情報、１０６：業務パターン抽出部、
１０７：業務パターン、１０８：構成情報抽出部、１０９：ハードウェア構成情報、
１１０：性能データベース、１１１：性能予測シミュレーション部、
１１２：システム要求性能、１１３：判定ポリシー、１１４：要求性能判定部、
１１５：出力装置
【図１】
2005099973.tif 000003
【図２】
2005099973.tif 000004
【図３】
2005099973.tif 000005
【図４】
2005099973.tif 000006
【図５】
2005099973.tif 000007
【図６】
2005099973.tif 000008
【図７】
2005099973.tif 000009
【図８】
2005099973.tif 000010
【図９】
2005099973.tif 000011
【図１０】
2005099973.tif 000012