(57)【要約】【課題】処理要求種別の判別を適切に行なえるようにする。【解決手段】第１のコンピュータ１ｃに対する第２のコンピュータ１ａ，１ｂ，１ｄによる処理要求の処理要求内容を取得し、第１および第２のコンピュータ１ａ〜１ｄそれぞれの動作に関する第１および第２の動作情報を取得し、処理実績情報と、前記第１の処理要求の処理要求内容と、前記の第１および第２の動作情報とに基づき、前記処理要求の処理要求種別を判定する。前記処理実績情報は、第１のコンピュータ１ｃに対する前記処理要求の処理要求内容に含まれる当該処理要求に対応した第１のコンピュータ１ｃによる処理履歴と当該処理要求を行なった第２のコンピュータ１ｂ，１ｄの当該処理要求に関連した前記第２の動作情報とを対応づけたものである。【選択図】図１
2015141574.tif 000002
【特許請求の範囲】
【請求項１】
第１のコンピュータに対する第２のコンピュータによる処理要求の処理要求内容を取得し、
前記の第１および第２のコンピュータそれぞれの動作に関する第１および第２の動作情報を取得し、
前記第１のコンピュータに対する前記処理要求の処理要求内容に含まれる当該処理要求に対応した前記第１のコンピュータによる処理履歴と当該処理要求を行なった前記第２のコンピュータの当該処理要求に関連した前記第２の動作情報とを対応づけた処理実績情報と、前記処理要求内容と、前記の第１および第２の動作情報とに基づき、前記処理要求の処理要求種別を判別する、
処理をプロセッサに実行させる、制御プログラム。
【請求項２】
前記処理要求種別の判別結果に基づき前記コンピュータに割り当てられるリソースの制御を行なう、
処理を前記プロセッサに実行させる、請求項１記載の制御プログラム。
【請求項３】
前記第１のコンピュータとしてデータベースサーバを含み、前記第２のコンピュータとしてウエブサーバ，アプリケーションサーバおよびバッチサーバを含む場合、
前記処理要求の処理要求内容に含まれる当該処理要求の発行元プロセス識別情報が、前記データベースサーバから取得された前記第１の動作情報に含まれるプロセス情報にあるか否かを判別し、
当該処理要求の発行元プロセス識別情報が前記プロセス情報にあれば、前記処理要求の処理要求種別は、前記バッチサーバによるローカルバッチ処理であると判別し、
前記処理要求の処理要求内容と前記第１の動作情報とに基づき、前記ローカルバッチ処理の処理要求を発行した前記バッチサーバの第１アドレス情報を取得し、
前記第１アドレス情報を保存部に保存する、
処理を前記プロセッサに実行させる、請求項１または請求項２記載の制御プログラム。
【請求項４】
当該処理要求の発行元プロセス識別情報が前記プロセス情報になければ、前記処理要求の処理要求内容と前記第１の動作情報とに基づき、当該処理要求を発行したサーバの第２アドレス情報を取得し、
前記第２アドレス情報で指定されるサーバから、前回の処理要求による処理開始から処理終了までの第１リソース使用量と前記処理終了から当該処理要求による処理開始までの第２リソース使用量とを前記処理実績情報として取得し、
前記第１リソース使用量に対して前記第２リソース使用量が増加しているか否かを判別し、
前記第１リソース使用量に対して前記第２リソース使用量が増加していれば、前記処理要求の処理要求種別は、前記バッチサーバによるリモートバッチ処理であると判別し、
前記第２アドレス情報を、前記バッチサーバのアドレス情報として前記保存部に保存する、
処理を前記プロセッサに実行させる、請求項３記載の制御プログラム。
【請求項５】
前記第１リソース使用量に対して前記第２リソース使用量が増加していなければ、前記第２アドレス情報を前記アプリケーションサーバのアドレス情報として取得し、
前記処理要求の処理要求内容と前記アプリケーションサーバのアドレス情報と前記ウエブサーバから取得された前記第１の動作情報とに基づき、当該処理要求の発行元サーバの第３アドレス情報を検出し、
前記第３アドレス情報が前記保存部に保存されているか否かを判別し、
前記第３アドレス情報が前記保存部に保存されていれば、前記処理要求の処理要求種別は、前記バッチサーバによって前記ウエブサーバ経由で行なわれるウエブサービスバッチ処理であると判別する、
処理を前記プロセッサに実行させる、請求項４記載の制御プログラム。
【請求項６】
前記第３アドレス情報が前記保存部に保存されていなければ、前記処理要求の処理要求種別は、オンライン処理であると判別する、
処理を前記プロセッサに実行させる、請求項４または請求項５記載の制御プログラム。
【請求項７】
第１のコンピュータに対する第２のコンピュータによる処理要求の処理要求内容を取得する第１取得部と、
前記の第１および第２のコンピュータそれぞれの動作に関する第１および第２の動作情報を取得する第２取得部と、
前記第１のコンピュータに対する前記処理要求の処理要求内容に含まれる当該処理要求に対応した前記第１のコンピュータによる処理履歴と当該処理要求を行なった前記第２のコンピュータの当該処理要求に関連した前記第２の動作情報とを対応づけた処理実績情報と、前記処理要求内容と、前記の第１および第２の動作情報とに基づき、前記処理要求の処理要求種別を判別する判別部と、を有する、制御装置。
【請求項８】
プロセッサが、
第１のコンピュータに対する第２のコンピュータによる処理要求の処理要求内容を取得し、
前記の第１および第２のコンピュータそれぞれの動作に関する第１および第２の動作情報を取得し、
前記第１のコンピュータに対する前記処理要求の処理要求内容に含まれる当該処理要求に対応した前記第１のコンピュータによる処理履歴と当該処理要求を行なった前記第２のコンピュータの当該処理要求に関連した前記第２の動作情報とを対応づけた処理実績情報と、前記処理要求内容と、前記の第１および第２の動作情報とに基づき、前記処理要求の処理要求種別を判別する、制御方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、制御プログラム、制御装置および制御方法に関する。
【背景技術】
【０００２】
業務システムの処理性能を向上させる方法としては、サーバの台数を増やし各サーバに負荷を分散するスケールアウトや、サーバにリソース（ＣＰＵ（Central Processing Unit），メモリ等）を追加するスケールアップが知られている。また、近年、クラウドコンピューティング技術が発達してきており、クラウド環境下では、処理要求量に応じてスケールアウトやスケールアップを行なうオートスケールが可能である。
【０００３】
一方、業務システムでは、オンライン業務とバッチ業務とが行なわれる。図３６に示すように、オンライン業務では、エンドユーザからネットワーク，ウエブ（Ｗｅｂ）サーバ，アプリケーション（ＡＰ）サーバ経由でデータベース（ＤＢ）サーバに対するアクセスが行なわれる。バッチ業務では、バッチサーバによってＤＢサーバに対するアクセスが行なわれる。なお、図３６は、業務システムの構成例を示す図である。
【０００４】
オンライン業務とバッチ業務とでは、求められる性能指標や、リソースの利用手法が、以下のように異なる。
【０００５】
オンライン業務では、レスポンス時間がＳＬＡ（Service Level Agreement）の設定値を超えない性能を維持することが求められる。したがって、オンライン業務では、処理要求量が増加してもレスポンス時間が遅くならないように、余裕をもってサーバ数やサーバスペックの割当を行なう必要がある（図３７参照）。なお、図３７は、ＤＢサーバのリソース利用状況の例を示す図である。
【０００６】
バッチ業務では、バッチ処理を決められた時間内に完了させることが求められる。例えば、バッチ処理を夜間に実行しオンライン業務が始まるまでに完了させることが求められる。したがって、バッチ業務では、時間内にバッチ処理を完了させることができるのであれば、サーバ数やサーバスペックを最大限に利用することができる（図３７参照）。
【０００７】
上述のようなオンライン業務やバッチ業務を実行する業務システムにおいて性能維持とリソースの有効活用とを両立するには、業務システム上で稼動している業務が、オンライン業務であるかバッチ業務であるかの切り分けを行なわなければならない。つまり、業務特性に応じたスケーリング（オートスケール）を実現するためには、業務システムで実行される業務がオンライン業務かバッチ業務かの判別を適切に行なえるようにすることが重要になる。
【０００８】
オンライン業務とバッチ業務との判別を行なう技術としては、判別対象のメッセージが直上層のプロトコルのメッセージと親子関係を有しているか否かによって当該判別を行なう技術が知られている。なお、上記直上層のプロトコルは、例えばＩＩＯＰ（Internet Inter-ORB (Object Request Broker) Protocol）である。より具体的に、当該判別技術では、Ｗｅｂサーバ，ＡＰサーバ，ＤＢサーバで構成されたシステム内で受け渡されるメッセージが対象になっている。そして、ＷｅｂサーバからＡＰサーバに受け渡されるメッセージと、ＡＰサーバからＤＢサーバに受け渡されるメッセージとに関連があるか否かに基づき、オンライン業務かバッチ業務かの判別が行なわれる。
【先行技術文献】
【特許文献】
【０００９】
【特許文献１】特開２０１２−１５０７３３号公報
【特許文献２】特開平１１−２８８３８２号公報
【特許文献３】特開２００４−３０２７５１号公報
【発明の概要】
【発明が解決しようとする課題】
【００１０】
しかしながら、上述した判別技術では、以下のようなバッチ業務(a1)〜(a3)の場合、業務システム上で処理されるＳＱＬ（Structured Query Language）が、オンライン業務で発行されたものかバッチ業務で発行されたものかを判別することができない。
【００１１】
(a1) ＤＢサーバでローカルバッチ業務が行なわれた場合：  上記判別技術は、通信で使用されるプロトコルのメッセージのオブジェクトについてバッチ処理かオンライン処理かの判別を行なうもので、通信を使用しないローカルバッチ業務がＤＢサーバ内で行なわれた場合、当該判別を行なうことができない。
【００１２】
(a2) バッチサーバからＤＢサーバに対しリモートバッチ業務が行なわれた場合：  上記判別技術では、上述の通り、Ｗｅｂサーバ，ＡＰサーバ，ＤＢサーバで構成されたシステム内で受け渡されるメッセージが対象になっている。このため、図３８に示すように、対象のシステム構成から外れているバッチサーバとＤＢサーバとの間で受け渡されるたメッセージに対する考慮はされておらず、当該メッセージの検出工程がない。したがって、オンライン業務かバッチ業務かの判別を行なうことができない。なお、図３８は、上記判別技術（公知技術）の課題を説明する図である。また、図３８において、ＲＤＢＭＳは、Relational DataBase Management Systemの略記である。
【００１３】
(a3) ＷｅｂサーバおよびＡＰサーバを通じてＷｅｂサービスバッチ業務が行なわれた場合：  上記判別技術では、上述の通り、ＡＰサーバからＤＢサーバに向けて発行されるメッセージと、Ｗｅｂサーバから発行されるＩＩＯＰのメッセージとの関連性を判断基準としている。また、Ｗｅｂサービスバッチ業務とオンライン業務とでは、図３９に示すように、ＳＱＬの発行元がエンドユーザであるかバッチサーバであるかが異なるのみでＷｅｂサーバ以降の経路は同じである。このため、ＡＰサーバから発行されるメッセージに対し、ＩＩＯＰとの関連がオンライン業務およびバッチ業務のどちらに際しても発生してしまい、オンライン業務かバッチ業務かの判別を行なうことができない。なお、図３９は、上記判別技術（公知技術）の課題を説明する図である。
【００１４】
一つの側面で、本発明は、処理要求種別の判別を適切に行なえるようにすることを目的とする。
なお、前記目的に限らず、後述する発明を実施するための最良の形態に示す各構成により導かれる作用効果であって、従来の技術によっては得られない作用効果を奏することも本件の他の目的の一つとして位置付けることができる。
【課題を解決するための手段】
【００１５】
本件の制御プログラムは、以下の処理をプロセッサに実行させる。第１のコンピュータに対する第２のコンピュータによる処理要求の処理要求内容を取得する処理。前記の第１および第２のコンピュータそれぞれの動作に関する第１および第２の動作情報を取得する処理。処理実績情報と、前記処理要求内容と、前記の第１および第２の動作情報とに基づき、前記処理要求の処理要求種別を判別する処理。なお、前記処理実績情報は、前記第１のコンピュータに対する前記処理要求の処理要求内容に含まれる当該処理要求に対応した前記第１のコンピュータによる処理履歴と当該処理要求を行なった前記第２のコンピュータの当該処理要求に関連した前記第２の動作情報とを対応づけたものである。
【発明の効果】
【００１６】
一実施形態によれば、処理要求種別の判別を適切に行なうことができる。
【図面の簡単な説明】
【００１７】
【図１】本実施形態における業務種別の判別手法の概要を説明する図である。
【図２】本実施形態における業務種別の判別手法の概要を説明する図である。
【図３】本実施形態の判別手法による判別可否と公知技術による判別可否とを比較して示す図である。
【図４】公知技術によるリソース利用状況の例を示す図である。
【図５】公知技術によるリソース利用状況の例を示す図である。
【図６】本実施形態に係る業務システムおよび管理サーバ（制御装置）のハードウエア構成例および機能構成例を示すブロック図である。
【図７】本実施形態における業務種別の判別手法による処理の流れを説明する図である。
【図８】図６に示すＤＢ情報収集部の機能および動作を説明する図である。
【図９】図６に示すＤＢ情報収集部によって取得されるＳＱＬ情報の一例を示す図である。
【図１０】図６に示すＤＢ情報収集部によって取得されるプロセス情報の一例を示す図である。
【図１１】図６に示すＤＢ情報収集部によって取得されるネットワーク情報の一例を示す図である。
【図１２】図６に示すローカルバッチ業務判断部の機能および動作を説明する図である。
【図１３】図６に示すＳＱＬ・業務種別履歴ＤＢに対する保存処理について説明する図である。
【図１４】図６に示すＳＱＬ・業務種別履歴ＤＢに保存される情報の一例を示す図である。
【図１５】図６に示すバッチサーバ一覧情報ＤＢに対する保存処理について説明する図である。
【図１６】図６に示すバッチサーバ一覧情報ＤＢに保存される情報の一例を示す図である。
【図１７】図６に示すリモートバッチ業務判断部の機能および動作を説明する図である。
【図１８】図６に示すＡＰ情報収集部またはバッチ情報収集部の機能および動作を説明する図である。
【図１９】図６に示すリモートバッチ業務判断部の判別基準について説明する図である。
【図２０】図６に示すリモートバッチ業務判断部の機能および動作を説明する図である。
【図２１】図６に示すＷｅｂサービスバッチ業務／オンライン業務判断部の機能および動作を説明する図である。
【図２２】図６に示す管理マネージャの動作を説明するフローチャートである。
【図２３】図２２に示すステップＳ３のローカルバッチ業務判断処理を説明するフローチャートである。
【図２４】図２２に示すステップＳ５のリモートバッチ業務判断処理を説明するフローチャートである。
【図２５】図２２に示すステップＳ７のＷｅｂサービスバッチ業務／オンライン業務判断処理を説明するフローチャートである。
【図２６】本実施形態のローカルバッチ業務判断処理を説明すべくＳＱＬ情報の一例を示す図である。
【図２７】本実施形態のローカルバッチ業務判断処理を説明すべくプロセス情報の一例を示す図である。
【図２８】本実施形態のローカルバッチ業務判断処理を説明すべくネットワーク情報の一例を示す図である。
【図２９】本実施形態のリモートバッチ業務判断処理を説明すべくＳＱＬ情報の一例を示す図である。
【図３０】本実施形態のリモートバッチ業務判断処理を説明すべくネットワーク情報の一例を示す図である。
【図３１】本実施形態のリモートバッチ業務判断処理を説明すべくリソース使用状況（処理実績情報）の一例を示す図である。
【図３２】本実施形態のＷｅｂサービスバッチ業務／オンライン業務判断処理を説明すべくＳＱＬ情報の一例を示す図である。
【図３３】本実施形態のＷｅｂサービスバッチ業務／オンライン業務判断処理を説明すべくネットワーク情報の一例を示す図である。
【図３４】本実施形態のＷｅｂサービスバッチ業務／オンライン業務判断処理を説明すべくバッチサーバ一覧情報ＤＢに保存される情報の一例を示す図である。
【図３５】本実施形態による判別結果として出力される、ＳＱＬ・業務種別履歴ＤＢの情報の一例を示す図である。
【図３６】業務システムの構成例を示す図である。
【図３７】データベースサーバのリソース利用状況の例を示す図である。
【図３８】公知技術の課題を説明する図である。
【図３９】公知技術の課題を説明する図である。
【発明を実施するための形態】
【００１８】
以下に、図面を参照し、本願の開示する制御プログラム、制御装置および制御方法の実施形態について、詳細に説明する。ただし、以下に示す実施形態は、あくまでも例示に過ぎず、実施形態で明示しない種々の変形例や技術の適用を排除する意図はない。すなわち、本実施形態を、その趣旨を逸脱しない範囲で種々変形して実施することができる。また、各図は、図中に示す構成要素のみを備えるという趣旨ではなく、他の機能を含むことができる。そして、各実施形態は、処理内容を矛盾させない範囲で適宜組み合わせることが可能である。
【００１９】
〔１〕本実施形態における業務種別の判断手法の概要について
業務システムをオートスケールするための技術としては、以下の技術(b1)，(b2)が知られている。
【００２０】
(b1) 事前に設定されたリソース使用率やレスポンス時間の閾値に基づきオートスケールする技術（一般的なクラウドサービスで提供されている機能）。
当該技術(b1)では、ＣＰＵ，メモリなどのリソース使用率の閾値（例えば７０％）や、レスポンス時間の閾値（例えば１秒）が事前に設定される。そして、リソース使用率やレスポンス時間が閾値を超えた場合にスケールアウトまたはスケールアップが行なわれる。一方、リソース使用率やレスポンス時間が閾値以下になった場合にスケールインまたはスケールダウンが行なわれる。このようなオートスケール機能では、リソース使用率やレスポンス時間が閾値を超えた後にサーバ／リソースが追加されるため、閾値超過が発生した時点から実際にサーバ／リソースが追加されるまでに時間がかかる。これにより、オンライン業務のレスポンス時間が遅くなってＳＬＡ違反が生じたり、バッチ業務が所定時刻までに完了しないといった影響が生じたりする。通常、閾値超過のアラーム検知後、追加されたサーバ／リソースが使用可能になるまでに約５分を要する。その時間もクラウド側の混雑状況や作成するサーバタイプによって左右されるため、場合によっては５分以上かかる場合もある。
【００２１】
(b2) 事前に設定されたリソース使用率やレスポンス時間の閾値値と、将来予測結果とに基づき、オートスケールする技術。
当該技術(b2)でも、ＣＰＵ，メモリなどのリソース使用率の閾値（例えば７０％）や、レスポンス時間の閾値（例えば１秒）が事前に設定される。そして、過去の実績などから将来予測（回帰直線等）によりリソースの需要（リソース使用率やレスポンス時間）が予測され、予測値が閾値を超えた場合にスケールアウトまたはスケールアップが行なわれる。一方、予測値が閾値以下になった場合にスケールインまたはスケールダウンが行なわれる。当該技術(b2)により上記技術(b1)の課題は解消される。しかし、上記技術(b1)や(b2)は、主にオンライン業務に対応するもので、バッチ業務の業務特性による考慮がなされていない。
【００２２】
このため、上記技術(b1)や(b2)では、バッチ業務時には、サーバ／リソースの処理性能が最大限に使用されるため、例えば図４に示すように、バッチ業務が完了するまで際限なくスケールアウト／スケールアップが繰り返されてしまう。図４に示す例では、４回のスケールアウトが行なわれている。その結果、バッチ業務の実処理時間は短縮されバッチ業務の完了時刻は早まることになるが、バッチ業務時間を最大限に利用することができないため無駄な時間が発生する。つまり、必要のないスケールアウトが実行されコストがかかることになる。なお、図４は、上記技術(b1)や(b2)によるリソース利用状況の例を示す図である。
【００２３】
また、複数種別の業務に対応するため、業務種別毎に時間帯を分けてオートスケール（上記技術(b1)や(b2)参照）をスケジュールすることはできる。このとき、バッチ業務時間帯に実行していたバッチ業務が何らかの理由で異常終了した場合、異常終了したバッチ業務は、当該バッチ業務の復旧後に必ず直ちに再実行して完了させなければならない。しかし、例えば図５に示すように、バッチ業務時間帯の夜間にバッチ業務を復旧できずオンライン業務時間帯の日中に再実行を行なう状況が生じると、不適切なスケーリングが行なわれてしまう。つまり、日中は、通常、オンライン業務用のオートスケール（上記技術(b1)や(b2)参照）が適用されているため、そのままでは、図５に示すように、状況に適していない不適切なスケーリングが行なわれてしまう。なお、図５は、公知技術によるリソース利用状況の例を示す図である。
【００２４】
その他にも、例えば海外拡販のため１２時間前後の時差があるアメリカなどの海外からのアクセスが一時的に増える場合、現地における業務時間は日本時間における夜間となり、バッチ業務時間帯に突発的にオンライン業務が増える。しかし、夜間はオートスケールを抑止する場合が多いため、オンライン業務に対応するスケーリングを行なうことができず、その結果、レスポンス遅延等のＳＬＡ違反が発生してしまう。
【００２５】
以上のように、過去の履歴のみに頼って、リソースの使用方法が異なる複数種別の業務（例えばオンライン業務やバッチ業務）を両立したオートスケールのスケジューリングを実現することはできない。加えて、予測できない突発的な業務増加に対し全て人手で対応することは困難である。
【００２６】
複数種別の業務を含む業務システムにおいて処理性能の維持とリソースの有効活用とを両立するには、業務システム上で稼働している業務が、オンライン業務であるかバッチ業務であるかの切り分けを行なう必要がある。しかしながら、上述した従来の判別技術では、上記バッチ業務(a1)〜(a3)の場合、業務システム上で処理されるＳＱＬが、オンライン業務で発行されたものかバッチ業務で発行されたものかを判別することができない。
【００２７】
特に、近年、オンラインサービス（Ｗｅｂサービス）によってバッチ処理（上記バッチ業務(a3)参照）が提供されるようになってきている。オンラインサービスによって提供されるバッチ処理は、図３９に示すように、オンライン業務と同様、ＷｅｂサーバおよびＡＰサーバを使用する。そのため、ＤＢサーバ上で実行される業務がオンライン業務であるかバッチ業務であるの判別が難しく、処理要求（ＳＱＬ）の発行元がエンドユーザであるかバッチサーバであるかを見極めなければならない。現状、Ｗｅｂサービスを利用したバッチ業務について、オンライン業務かバッチ業務かの判別を行なう手法が確立されていない。
【００２８】
そこで、本実施形態では、以下に説明するように、性能情報や接続情報といった表面上の情報、即ちＯＳ（Operating System）などから取得できる一般的な情報に基づき、オンライン業務かバッチ業務かを適切に自動判別可能にする。これにより、業務特性に応じたオートスケールが実現される。
【００２９】
ここで、図１および図２を参照しながら、本実施形態における業務種別（処理要求種別）の判別手法の概要について説明する。なお、図１および図２は、本実施形態における業務種別の判別手法の概要を説明する図である。また、図１に示す業務システム１は、Ｗｅｂサーバ１ａ，ＡＰサーバ１ｂ，ＤＢサーバ１ｃおよびバッチサーバ１ｄを含んでいる。各サーバ１ａ〜１ｄの機能等については、図６を参照しながら後述する。また、業務システム１（Ｗｅｂサーバ１ａ）には、エンドユーザ（クライアント端末）２がネットワーク３を介して接続されており、業務システム１は、エンドユーザ２からの処理要求等に応じオンライン業務を実行するようになっている。
【００３０】
オンライン業務およびバッチ業務のパターンとしては、図１に示すように、４つのパターンＡ〜Ｄがあり、パターンＡ〜Ｄそれぞれの業務種別および特徴は、以下の通りである。なお、以下の説明において「業務」を「処理」という場合がある。
【００３１】
パターンＡ：  オンライン業務（当該業務の処理の流れについては図１中の矢印Ａ参照）。オンライン業務の特徴は以下の項目(A1)〜(A3)の通りである。
(A1) エンドユーザ２からのアクセスがＷｅｂサーバ１ａおよびＡＰサーバ１ｂを経由する。
(A2) ＡＰサーバ１ｂがリモートでＤＢサーバ１ｃにＳＱＬを発行する。
(A3) ＤＢサーバ１ｃ内のＲＤＢＭＳのスレッドが起動され、オンライン処理が実行される。
【００３２】
パターンＢ：  ローカルバッチ業務（当該業務の処理の流れについては図１中の矢印Ｂ参照）。ローカルバッチ業務の特徴は以下の項目(B1)〜(B3)の通りである。
(B1) バッチサーバ１ｄがＤＢサーバ１ｃ内のローカルバッチを起動する。
(B2) ＤＢサーバ１ｃ内のローカルバッチプロセスが起動される。
(B3) ＤＢサーバ１ｃ内のＲＤＢＭＳのスレッドが起動され、バッチ処理が実行される。
【００３３】
パターンＣ：  リモートバッチ業務（当該業務の処理の流れについては図１中の矢印Ｃ参照）。リモートバッチ業務の特徴は以下の項目(C1)および(C2)の通りである。
(C1) バッチサーバ１ｄがリモートでＤＢサーバ１ｃにＳＱＬを発行する。
(C2) ＤＢサーバ１ｃ内のＲＤＢＭＳのスレッドが起動され、バッチ処理が実行される。
【００３４】
パターンＤ：  Ｗｅｂサービスバッチ業務（当該業務の処理の流れについては図１中の矢印Ｄ参照）。ローカルバッチ業務の特徴は、以下の項目(D1)〜(D3)の通りである。
(D1) バッチサーバ１ｄからのアクセスが、Ｗｅｂサービスを通じて、Ｗｅｂサーバ１ａおよびＡＰサーバ１ｂを経由する。
(D2) ＡＰサーバ１ｂがリモートでＤＢサーバ１ｃにＳＱＬを発行する。
(D3) ＤＢサーバ１ｃ内のＲＤＢＭＳのスレッドが起動され、バッチ処理が実行される。
【００３５】
以上の特徴をまとめると、図２に示す表の通りである。そして、図２を参照しながら、パターンＡ〜Ｄを判別する基準I〜IIIについて説明する。
【００３６】
まず、図２の基準Ｉに基づき、判別対象業務がローカルバッチ業務であるかそれ以外の業務であるかを判別する。つまり、まず、判別対象業務を実行するに際しＤＢサーバ１ｃでローカルバッチプロセスが起動されていれば、判別対象業務はローカルバッチ業務であると判別する。
【００３７】
ＤＢサーバ１ｃでローカルバッチプロセスが起動されていなければ、判別対象業務はローカルバッチ業務以外の業務であると判別し、図２の基準IIに基づき、判別対象業務がリモートバッチ業務であるかそれ以外の業務であるかを判別する。つまり、判別対象業務についてのリモートＳＱＬの発行元がバッチサーバ１ｄであれば、判別対象業務はリモートバッチ業務であると判別する。
【００３８】
判別対象業務についてのリモートＳＱＬの発行元がバッチサーバ１ｄでなければ、判別対象業務はリモートバッチ業務以外の業務であると判別し、図２の基準IIIに基づき、判別対象業務がＷｅｂサービスバッチ業務であるかオンライン業務であるかを判別する。つまり、後述するごとく、保存部（記憶部）１２０（バッチサーバ一覧情報ＤＢ１２２；図６参照）にＳＱＬ発行元サーバのアドレスが登録されていれば、判別対象業務はＷｅｂサービスバッチ業務であると判別する。一方、保存部１２０（バッチサーバ一覧情報ＤＢ１２２）にＳＱＬ発行元サーバのアドレスが登録されていなければ、判別対象業務はオンライン業務であると判別する。
【００３９】
以上のような基準I〜IIIに基づきパターンＡ〜Ｄを自動判別する手法の概要を、以下に説明する。本実施形態の手法では、後述する処理部（プロセッサ）１１０（図６参照）が、以下の手順１〜４で判別処理／制御処理を実行する。
【００４０】
手順１：  第１のコンピュータ（ＤＢサーバ１ｃ）に対する第２のコンピュータ（Ｗｅｂサーバ１ａ，ＡＰサーバ１ｂ，バッチサーバ１ｄ）による処理要求の処理要求内容（ＳＱＬ情報）を取得する。
手順２：  サーバ１ａ〜１ｄそれぞれの動作に関する第１および第２の動作情報（プロセス情報，ネットワーク情報）を取得する。
手順３：  処理実績情報と、前記処理要求内容（ＳＱＬ情報）と、前記の第１および第２の動作情報（プロセス情報，ネットワーク情報）とに基づき、前記処理要求の処理要求種別（バッチ処理／オンライン処理）を判別する。なお、前記処理実績情報は、ＤＢサーバ１ｃに対する前記処理要求の処理要求内容に含まれる当該処理要求に対応したＤＢサーバ１ｃによる処理履歴と当該処理要求を行なったＡＰサーバ１ｂまたはバッチサーバ１ｄの当該処理要求に関連した前記第２の動作情報（プロセス情報）とを対応づけたものである。前記処理実績情報の具体例については、図１９や図３１を参照しながら後述する。
手順４：  前記処理要求種別の判別結果に基づき業務システム１（サーバ１ａ〜１ｄ）に割り当てられるリソースの制御を行なう。
【００４１】
このとき、本実施形態の手法では、処理部１１０が、以下の手順１１〜１４でローカルバッチ処理の判別処理を実行する。
手順１１：  前記処理要求の処理要求内容に含まれる当該処理要求の発行元プロセス識別情報が、ＤＢサーバ１ｃから取得された前記第１の動作情報に含まれるプロセス情報にあるか否かを判別する。
手順１２：  当該処理要求の発行元プロセス識別情報が前記プロセス情報にあれば、前記処理要求の処理要求種別は、バッチサーバ１ｄによるローカルバッチ処理であると判別する。
手順１３：  前記処理要求の処理要求内容と前記第１の動作情報（ネットワーク情報）とに基づき、前記ローカルバッチ処理の処理要求を発行したバッチサーバ１ｄの第１アドレス情報を取得する。
手順１４：  前記第１アドレス情報を保存部１２０（バッチサーバ一覧情報ＤＢ１２２）に保存する。
【００４２】
ついで、本実施形態の手法では、処理部１１０が、以下の手順２１〜２５でリモートバッチ処理の判別処理を実行する。
手順２１：  当該処理要求の発行元プロセス識別情報が前記プロセス情報になければ、前記処理要求の処理要求内容と前記第１の動作情報（ネットワーク情報）とに基づき、当該処理要求を発行したサーバ１ｂ／１ｄの第２アドレス情報を取得する。
手順２２：  前記第２アドレス情報で指定されるサーバ１ｂ／１ｄから、前回の処理要求による処理開始から処理終了までの第１リソース使用量と前記処理終了から当該処理要求による処理開始までの第２リソース使用量とを前記処理実績情報として取得する。
手順２３：  前記第１リソース使用量に対して前記第２リソース使用量が増加しているか否かを判別する。
手順２４：  前記第１リソース使用量に対して前記第２リソース使用量が増加していれば、前記処理要求の処理要求種別は、バッチサーバ１ｄによるリモートバッチ処理であると判別する。
手順２５：  前記第２アドレス情報を、バッチサーバ１ｄのアドレス情報として保存部１２０（バッチサーバ一覧情報ＤＢ１２２）に保存する。
【００４３】
ついで、本実施形態の手法では、処理部１１０が、以下の手順３１〜３５でＷｅｂサービスバッチ処理であるかオンライン処理であるかの判別処理を実行する。
手順３１：  前記第１リソース使用量に対して前記第２リソース使用量が増加していなければ、前記第２アドレス情報をＡＰサーバ１ｂのアドレス情報として取得する。
手順３２：  前記処理要求の処理要求内容とＡＰサーバ１ｂのアドレス情報とＷｅｂサーバ１ａから取得された前記第１の動作情報（ネットワーク情報）とに基づき、当該処理要求の発行元サーバの第３アドレス情報を検出する。
手順３３：  前記第３アドレス情報がバッチサーバ一覧情報ＤＢ１２２に保存されているか否かを判別する。
手順３４：  前記第３アドレス情報がバッチサーバ一覧情報ＤＢ１２２に保存されていれば、前記処理要求の処理要求種別は、バッチサーバ１ｄによってＷｅｂサーバ１ａ経由で行なわれるＷｅｂサービスバッチ処理であると判別する。
手順３５：  前記第３アドレス情報が保存部１２０（バッチサーバ一覧情報ＤＢ１２２）に保存されていなければ、前記処理要求の処理要求種別は、オンライン処理であると判別する。
【００４４】
以上のような本実施形態の判別手法による判別可否と、上述した公知技術による判別可否とを比較して、図３に示す。なお、図３では、業務種別と、各業務種別のシステム構成および処理の流れと、公知技術による判別可否と、本実施形態の判別手法による判別可否とが対応付けて示されている。
【００４５】
図３に示すように、上述した公知技術では、ローカルバッチ業務およびＷｅｂサービスバッチ業務を判別することはできない（ＮＧ）。リモートバッチ業務およびオンライン業務については、一部、判別することができる（一部ＯＫ）。リモートバッチ業務については、ＡＰサーバ１ｂから発行されたバッチ業務は判別可能であるが、バッチサーバ１ｄから発行されたバッチ業務は判別不可である。また、オンライン業務については、Ｗｅｂサービスバッチ業務もオンライン業務と判別してしまう。
【００４６】
これに対し、本実施形態の判別手法では、図３に示すように、４つのパターンＡ〜Ｄであるローカルバッチ業務，リモートバッチ業務，Ｗｅｂサービスバッチ業務，オンライン業務のいずれについても判別可能である。
【００４７】
〔２〕本実施形態の構成
まず、図６を参照しながら、本実施形態の業務システム１および管理サーバ（制御装置）１００の構成について説明する。図６は、本実施形態に係る業務システム１および管理サーバ（制御装置）１００のハードウエア構成例および機能構成例を示すブロック図である。
【００４８】
図６に示す本実施形態の業務システム１も、図１を参照しながら前述した業務システム１と同様に構成されている。つまり、業務システム１は、Ｗｅｂサーバ１ａ，ＡＰサーバ１ｂ，ＤＢサーバ１ｃ，バッチサーバ１ｄおよびデータベース（ＤＢ）１ｅを含んでいる。また、業務システム１（Ｗｅｂサーバ１ａ）には、エンドユーザ（クライアント端末）２がネットワーク３を介して接続されており、業務システム１は、エンドユーザ２からの処理要求等に応じオンライン業務を実行するようになっている。ネットワーク３としては、インターネット，ＬＡＮ（Local Area Network），ＷＡＮ（Wide Area Network）などが用いられている。
【００４９】
また、業務システム１は、オンライン業務（パターンＡ）とバッチ業務（パターンＢ〜Ｄ）とが混在するシステムである。オンライン業務は、クライアント端末２からの処理要求に応じて処理を行なう業務である。バッチ業務は、例えば、一定期間収集したデータを一括処理、または、複数の手順からなる処理を予め決められた手順に従って連続処理する業務であり、前述した３つのパターンＢ，Ｃ，Ｄをもつ。
【００５０】
さらに、業務システム１には、管理サーバ（制御装置）１００が接続されている。管理サーバ１００は、ＤＢサーバ１ｃに対する処理要求（業務）の種別を判別し、判別結果に基づき当該業務システム１のリソース（サーバ，ＣＰＵ，メモリ等）の追加／削減つまりオートスケールを行なう。なお、Ｗｅｂサーバ１ａ，ＡＰサーバ１ｂ，ＤＢサーバ１ｃ，バッチサーバ１ｄおよび管理サーバ１００は、インターネット，ＬＡＮ，ＷＡＮなどのネットワークを介して相互に通信可能に接続されている。
【００５１】
ここで、Ｗｅｂサーバ１ａは、クライアント端末２に搭載されたブラウザからの処理要求に応じて、ＨＴＭＬ（HyperText Markup Language）文書を送信するコンピュータである。ＡＰサーバ１ｂは、Ｗｅｂサーバ１ａとＤＢサーバ１ｃとの橋渡しを行ない、ＤＢ１ｅに対する処理（検索処理，更新処理，削除処理など）を制御するコンピュータである。ＤＢサーバ１ｃは、データ群を格納するＤＢ１ｅを備え、当該ＤＢ１ｅに対する処理を実行するコンピュータである。バッチサーバ１ｄは、ＤＢサーバ１ｃを介してＤＢ１ｅに格納されたデータ群にアクセスし当該データ群に基づくバッチ業務を実行するコンピュータである。クライアント端末２は、ブラウザを備え、Ｗｅｂサーバ１ａと通信するコンピュータである。クライアント端末２は、例えば、パーソナル・コンピュータ，スマートフォン，携帯電話端末である。
【００５２】
そして、本実施形態の管理サーバ１００には、管理マネージャ１０１が配置されている。管理マネージャ１０１は、少なくとも、ＣＰＵ，ＭＰＵ（Micro-Processing Unit），コンピュータ等の処理部（プロセッサ）１１０と、ＲＡＭ（Random Access Memory），ＨＤＤ（Hard Disk Drive），ＳＳＤ（Solid State Device）等の記憶部（メモリ，保存部）１２０とを有している。
【００５３】
処理部１１０は、記憶部１２０から所定のアプリケーションプログラム（制御プログラム）を読み出して実行することで、後述する第１取得部や第２取得部としての機能のほか、判定部１１１およびリソース制御部１１２としての機能を果たす。なお、前記所定のアプリケーションプログラムは、例えばフレキシブルディスク，ＣＤ（ＣＤ−ＲＯＭ，ＣＤ−Ｒ，ＣＤ−ＲＷなど），ＤＶＤ（ＤＶＤ−ＲＯＭ，ＤＶＤ−ＲＡＭ，ＤＶＤ−Ｒ，ＤＶＤ−ＲＷ，ＤＶＤ＋Ｒ，ＤＶＤ＋ＲＷなど），ブルーレイディスク等のコンピュータ読取可能な記録媒体に記録された形態で提供される。この場合、処理部１１０は、当該記録媒体からプログラムを読み取って内部記憶装置または外部記憶装置としての記憶部１２０に転送し格納して用いる。
【００５４】
記憶部１２０は、前記所定のアプリケーションプログラムを保存するほか、処理部１１０による処理に必要な各種情報等を保存する。例えば、記憶部１２０は、前記各種情報等として、ＳＱＬ・業務種別履歴ＤＢ１２１およびバッチサーバ一覧情報ＤＢ１２２を保存する。ＳＱＬ・業務種別履歴ＤＢ１２１については、図１３および図１４を参照しながら後述する。バッチサーバ一覧情報ＤＢ１２２については、図１５および図１６を参照しながら後述する。
【００５５】
管理サーバ１００に配置される管理マネージャ１０１（処理部１１０）は、業務システム１内のサーバ群（サーバ１ａ〜１ｄ）にそれぞれ配置されている管理エージェント１０ａ〜１０ｄから、後述する各種情報を収集取得する第１取得部および第２取得部としての機能を果たす。管理エージェント１０ａ〜１０ｄは、それぞれ、Ｗｅｂ情報収集部１１ａ，ＡＰ情報収集部１１ｂ，ＤＢ情報収集部１１ｃおよびバッチ情報収集部１１ｄとしての機能を有している。
【００５６】
Ｗｅｂ情報収集部１１ａは、Ｗｅｂサーバ１ａのネットワーク情報を収集して処理部１１０（Ｗｅｂサービスバッチ業務／オンライン業務判断部１１１ｃ）に通知する（図７，図２１参照）。処理部１１０は、Ｗｅｂ情報収集部１１ａからＷｅｂサーバ１ａのネットワーク情報を受信することで、Ｗｅｂ情報収集部１１ａとともに、Ｗｅｂサーバ１ａの動作に関する第２の動作情報を取得する第２取得部としての機能を果たす。
【００５７】
ＡＰ情報収集部１１ｂは、ＡＰサーバ１ｂのプロセス情報およびネットワーク情報を収集して処理部１１０（リモートバッチ業務判断部１１１ｂ）に通知する（図７，図１８，図２０参照）。処理部１１０は、ＡＰ情報収集部１１ｂからＡＰサーバ１ｂのプロセス情報およびネットワーク情報を受信することで、ＡＰ情報収集部１１ｂとともに、ＡＰサーバ１ｂの動作に関する第２の動作情報を取得する第２取得部としての機能を果たす。
【００５８】
ＤＢ情報収集部１１ｃは、ＤＢサーバ１ｃに対するＳＱＬ情報（サーバ１ａ〜１ｃによる処理要求の処理要求内容）と、ＤＢサーバ１ｃのプロセス情報およびネットワーク情報を収集して処理部１１０（ローカルバッチ業務判断部１１１ａ）に通知する（図７〜図１２参照）。処理部１１０は、ＤＢ情報収集部１１ｃからＳＱＬ情報を受信することで、ＤＢ情報収集部１１ｃとともに、サーバ１ａ〜１ｃによる処理要求の処理要求内容を取得する第１としての機能を果たす。また、処理部１１０は、ＤＢ情報収集部１１ｃからＤＢサーバ１ｃのプロセス情報およびネットワーク情報を受信することで、ＤＢ情報収集部１１ｃとともに、ＤＢサーバ１ｃの動作に関する第２の動作情報を取得する第２取得部としての機能を果たす。
【００５９】
バッチ情報収集部１１ｄは、バッチサーバ１ｄのプロセス情報およびネットワーク情報を収集して処理部１１０（リモートバッチ業務判断部１１１ｂ）に通知する（図７，図１８，図２０参照）。処理部１１０は、バッチ情報収集部１１ｄからバッチサーバ１ｄのプロセス情報およびネットワーク情報を受信することで、バッチ情報収集部１１ｄとともに、バッチサーバ１ｄの動作に関する第２の動作情報を取得する第２取得部としての機能を果たす。
【００６０】
ついで、処理部１１０によって実現される判別部１１（ローカルバッチ業務判断部１１１ａ，リモートバッチ業務判断部１１１ｂ，Ｗｅｂサービスバッチ業務／オンライン業務判断部１１１ｃ）およびリソース制御部１１２としての機能について説明する。
【００６１】
判別部１１１は、処理実績情報と、ＤＢ情報収集部１１ｃから通知されたＳＱＬ情報（ＤＢサーバ１ｃに対する処理要求の内容）と、収集部１１ａ〜１１ｄから通知されたプロセス情報およびネットワーク情報とに基づき、前記処理要求の処理要求種別つまり業務システム１で実行される業務種別（バッチ業務かオンライン処理か）を判別する。
【００６２】
なお、処理実績情報は、ＡＰ情報収集部１１ｂまたはバッチ情報収集部１１ｄからプロセス情報として通知される。そして、当該処理実績情報は、ＤＢサーバ１ｃに対する処理要求のＳＱＬ情報に含まれる当該処理要求に対応したＤＢサーバ１ｃによる処理履歴と当該処理要求を行なったＡＰサーバ１ｂまたはバッチサーバ１ｄの当該処理要求に関連したプロセス情報とを対応づけたものである。当該処理実績情報の具体例については、図１９や図３１を参照しながら後述する。
【００６３】
より具体的に、判別部１１１は、ローカルバッチ業務判断部１１１ａ，リモートバッチ業務判断部１１１ｂ，Ｗｅｂサービスバッチ業務／オンライン業務判断部１１１ｃを含み、これらの判断部１１１ａ〜１１１ｃを用いて業務種別の判別を行なう。
【００６４】
ローカルバッチ業務判断部１１１ａは、上述した手順１１〜１４でローカルバッチ業務（パターンＢ；上記バッチ業務(a1)）の判断処理を実行する。つまり、ローカルバッチ業務判断部１１１ａは、まず、ＳＱＬ情報に含まれる処理要求の発行元プロセスＩＤ（識別情報）が、ＤＢサーバ１ｃから取得されたプロセス情報にあるか否かを判別する（手順１１）。当該処理要求の発行元プロセス識別情報が前記プロセス情報にあれば、ローカルバッチ業務判断部１１１ａは、業務種別はバッチサーバ１ｄによるローカルバッチ処理であると判別する（手順１２）。このとき、ローカルバッチ業務判断部１１１ａは、ＳＱＬ情報とバッチサーバ１ｄから取得されたネットワーク情報とに基づき、ローカルバッチ処理の処理要求を発行したバッチサーバ１ｄのＩＰ（Internet Protocol）アドレス（第１アドレス情報）を取得する（手順１３）。そして、ローカルバッチ業務判断部１１１ａは、バッチサーバ１ｄのＩＰアドレスを保存部１２０のバッチサーバ一覧情報ＤＢ１２２に保存する（手順１４）。ローカルバッチ業務判断部１１１ａによるローカルバッチ業務（パターンＢ；上記バッチ業務(a1)）の具体的な判断処理については、図１２および図２３を参照しながら後述する。
【００６５】
リモートバッチ業務判断部１１１ｂは、上述した手順２１〜２５でリモートバッチ業務（パターンＣ；上記バッチ業務(a2)）の判断処理を実行する。つまり、当該処理要求の発行元プロセスＩＤが前記プロセス情報になければ、リモートバッチ業務判断部１１１ｂは、ＳＱＬ情報とネットワーク情報とに基づき、当該処理要求を発行したサーバ１ｂまたは１ｄのＩＰアドレス（第２アドレス情報）を取得する（手順２１）。ついで、リモートバッチ業務判断部１１１ｂは、取得した当該ＩＰアドレスで指定されるサーバ１ｂまたは１ｄから、前回の処理要求による処理開始から処理終了までの第１リソース使用量と前記処理終了から当該処理要求による処理開始までの第２リソース使用量とを前記処理実績情報として取得する（手順２２）。そして、リモートバッチ業務判断部１１１ｂは、第１リソース使用量に対して第２リソース使用量が増加しているか否かを判別する（手順２３）。第１リソース使用量に対して第２リソース使用量が増加していれば、リモートバッチ業務判断部１１１ｂは、業務種別はバッチサーバ１ｄによるリモートバッチ処理であると判別する（手順２４）。そして、リモートバッチ業務判断部１１１ｂは、前記第２アドレス情報として得られたＩＰアドレスを、バッチサーバ１ｄのアドレス情報として保存部１２０のバッチサーバ一覧情報ＤＢ１２２に保存する（手順２５）。リモートバッチ業務判断部１１１ｂによるリモートバッチ業務（パターンＣ；上記バッチ業務(a2)）の具体的な判断処理については、図１７〜図２０および図２４を参照しながら後述する。なお、第１リソース使用量は、例えば図１９に示す期間ＴＡにおける使用量であり、第１リソース使用量は、例えば図１９に示す期間ＴＢにおける使用量である。
【００６６】
Ｗｅｂサービスバッチ業務／オンライン業務判断部１１１ｃは、上述した手順３１〜３５でＷｅｂサービスバッチ業務（パターンＤ；上記業務(a3)）かオンライン業務（パターンＡ）かの判断処理を実行する。つまり、第１リソース使用量に対して第２リソース使用量が増加していなければ、判断部１１１ｃは、前記第２アドレス情報として得られたＩＰアドレスを、ＡＰサーバ１ｂのアドレス情報として取得する（手順３１）。判断部１１１ｃは、ＳＱＬ情報とＡＰサーバ１ｂのＩＰアドレスとＷｅｂサーバ１ａから取得されたネットワーク情報とに基づき、当該処理要求の発行元サーバのＩＰアドレス（第３アドレス情報）を検出する（手順３２）。そして、判断部１１１ｃは、当該ＩＰアドレス（第３アドレス情報）がバッチサーバ一覧情報ＤＢ１２２に保存されているか否かを判別する（手順３３）。当該ＩＰアドレス（第３アドレス情報）がバッチサーバ一覧情報ＤＢ１２２に保存されていれば、判断部１１１ｃは、業務種別はバッチサーバ１ｄによってＷｅｂサーバ１ａ経由で行なわれるＷｅｂサービスバッチ業務であると判別する（手順３４）。一方、当該ＩＰアドレス（第３アドレス情報）がバッチサーバ一覧情報ＤＢ１２２に保存されていなければ、判断部１１１ｃは、業務種別はオンライン処理であると判別する。判断部１１１ｃによるＷｅｂサービスバッチ業務（パターンＤ；上記業務(a3)）かオンライン業務（パターンＡ）かの具体的な判断処理については、図２１および図２５を参照しながら後述する。
【００６７】
リソース制御部１１２は、判別部１１１による判別結果に基づき（つまり業務システム１において実行すべき業務の業務種別がオンライン業務かバッチ業務かに応じ）サーバ１ａ〜１ｄに割り当てられるリソースの制御を行なう。例えば、リソース制御部１１２は、実行すべき業務がオンライン業務である場合、上記技術(b2)を業務システム１に適用するように制御を行なう。一方、リソース制御部１１２は、実行すべき業務がバッチ業務である場合、上記技術(b2)の適用を解除するように制御を行なう。これにより、バッチ業務時にサーバ／リソースの処理性能が最大限に使用されても、バッチ業務が完了するまで際限なくスケールアウト／スケールアップが繰り返されるのを抑止することができる。
【００６８】
〔３〕本実施形態の具体的な機能および動作
次に、図７〜図３５を参照しながら、本実施形態に係る業務システム１および管理サーバ１００の具体的な機能および動作（処理）について説明する。
【００６９】
〔３−１〕本実施形態における業務種別の判別手法による処理の流れ
図７の矢印Ａ１〜Ａ１２を参照しながら、本実施形態における業務種別の判別手法による処理の流れについて説明する。
【００７０】
ＤＢ情報収集部１１ｃは、ＤＢサーバ１ｃのＳＱＬ情報を定期的に取得する。新たなＳＱＬアクセスが発生したとき、ＤＢ情報収集部１１ｃは、ＳＱＬ情報，プロセス情報，ネットワーク情報を、ローカルバッチ業務判断部１１１ａに渡す（矢印Ａ１参照）。なお、ＤＢ情報収集部１１ｃの動作、および、ＤＢ情報収集部１１ｃによって収集されるＳＱＬ情報，プロセス情報，ネットワーク情報については、図８〜図１１を参照しながら後述する。
【００７１】
ローカルバッチ業務判断部１１１ａは、ＳＱＬ発行時にＤＢサーバ１ｃにプロセスが追加されたか否かによって、当該ＳＱＬに対応する業務（判別対象業務）がローカルバッチ業務であるかそれ以外の業務であるかを判別する（上記手順１１および図２の基準Ｉ参照）。ＳＱＬ発行時にＤＢサーバ１ｃにプロセスが追加された場合、ローカルバッチ業務判断部１１１ａは、判別対象業務はローカルバッチ業務（パターンＢ；バッチ業務(a1)）であると判別する。そして、ローカルバッチ業務判断部１１１ａは、ＳＱＬと判別結果の業務種別情報“バッチ”とをＳＱＬ・業務特性履歴ＤＢ１２１に格納する（矢印Ａ２参照）。また、ローカルバッチ業務判断部１１１ａは、ＳＱＬ発行元のバッチサーバ１ｄのＩＰアドレスを取得し、バッチサーバ一覧情報ＤＢ１２２に格納する（矢印Ａ３参照）。一方、プロセスが追加されていない場合、ローカルバッチ業務判断部１１１ａは、判別対象業務はローカルバッチ業務以外であると判別し、リモートバッチ業務判断部１１１ｂの処理に移行する（矢印Ａ４参照）。ここまでの処理で、判別対象業務は、ローカルバッチ業務ではないことが確定し、リモートバッチ業務，Ｗｅｂサービスバッチ業務，オンライン業務のいずれかである。
【００７２】
リモートバッチ業務判断部１１１ｂは、ローカルバッチ業務判断部１１１ａから受け渡されたＤＢサーバ１ｃのネットワーク情報から、ＳＱＬを発行したサーバ１ｂまたは１ｄのＩＰアドレスを取得する。この段階で、リモートバッチ業務判断部１１１ｂは、ＳＱＬを発行したサーバがＡＰサーバ１ｂであるかバッチサーバ１ｄであるかは見えていない。そこで、リモートバッチ業務判断部１１１ｂはＳＱＬ発行元サーバがサーバ１ｂかサーバ１ｄかを特定すべく、取得したＩＰアドレスで指定されるサーバ１ｂまたは１ｄに、プロセス情報およびネットワーク情報の収集を要求する（矢印Ａ５，Ａ６参照）。
【００７３】
当該要求を受けたサーバ１ｂまたは１ｄにおける収集部１１ｂまたは１１ｄは、サーバ１ｂまたは１ｄのプロセス情報（プロセスのリソース使用状況を含む）とネットワーク情報とを収集し、リモートバッチ業務判断部１１１ｂに通知する（矢印Ａ５，Ａ６）。
【００７４】
リモートバッチ業務判断部１１１ｂは、通知されたプロセス情報を参照し、当該ＳＱＬを発行したプロセスのリソースの利用特性に基づき、判別対象業務がリモートバッチ業務であるかそれ以外の業務であるかを判別する（上記手順２３，２４および図２の基準II参照）。リモートバッチ業務判断部１１１ｂは、判別対象業務がリモートバッチ業務であると判別した場合、ＳＱＬと判別結果の業務種別情報“バッチ”とをＳＱＬ・業務特性履歴ＤＢ１２１に格納する（矢印Ａ７参照）。また、リモートバッチ業務判断部１１１ｂは、ＳＱＬ発行元のバッチサーバ１ｄのＩＰアドレスをバッチサーバ一覧情報ＤＢ１２２に格納する（矢印Ａ８参照）。一方、リモートバッチ業務判断部１１１ｂは、判別対象業務がリモートバッチ業務以外であると判別した場合、判別対象業務はリモートバッチ業務以外であると判別し、Ｗｅｂサービスバッチ業務判断部１１１ｃの処理に移行する（矢印Ａ９参照）。ここまでの処理で、判別対象業務は、ローカルバッチ業務でもリモートバッチでもないことが確定し、Ｗｅｂサービスバッチ業務およびオンライン業務のいずれかである。
【００７５】
そして、Ｗｅｂサービスバッチ業務／オンライン業務判断部１１１ｃは、判断部１１１ｂで取得されたＩＰアドレス（第２アドレス情報）をＡＰサーバ１ｂのＩＰアドレスとして取得する。判断部１１１ｃは、取得されたＡＰサーバ１ｂのＩＰアドレスと、判断部１１１ｂから受け渡されたＳＱＬと、収集部１１ａを通じて取得されたＷｅｂサーバ１ａのネットワーク情報とに基づき、ＳＱＬの発行元サーバのＩＰアドレス（第３アドレス情報）を検出する。そして、判断部１１１ｃは、検出されたＩＰアドレスがバッチサーバ一覧情報ＤＢ１２２に含まれているか否かによって、判別対象業務がＷｅｂサービスバッチ業務であるかオンライン業務であるかを判別する（矢印Ａ１０，Ａ１１；上記手順３３〜３５および図２の基準III参照）。検出されたＩＰアドレスがＤＢ１２２に含まれていて判別対象業務がＷｅｂサービスバッチ業務であると判別された場合、判断部１１１ｃは、ＳＱＬと判別結果の業務種別情報“バッチ”とをＳＱＬ・業務特性履歴ＤＢ１２１に格納する（矢印Ａ１２参照）。一方、検出されたＩＰアドレスがＤＢ１２２に含まれておらず判別対象業務がオンライン業務であると判別された場合、判断部１１１ｃは、ＳＱＬと判別結果の業務種別情報“オンライン”とをＳＱＬ・業務特性履歴ＤＢ１２１に格納する（矢印Ａ１２参照）。
【００７６】
〔３−２〕ＤＢ情報収集部の機能および動作
次に、図８〜図１１を参照しながら、ＤＢ情報収集部１１ｃの機能および動作と、ＤＢ情報収集部１１ｃによって取得されるＳＱＬ情報，プロセス情報およびネットワーク情報とについて、より具体的に説明する。なお、図８は、ＤＢ情報収集部１１ｃの機能および動作を説明する図である。図９は、ＤＢ情報収集部１１ｃによって取得されるＳＱＬ情報の一例を示す図である。図１０は、ＤＢ情報収集部１１ｃによって取得されるプロセス情報の一例を示す図である。図１１は、ＤＢ情報収集部１１ｃによって取得されるネットワーク情報の一例を示す図である。
【００７７】
ＤＢ情報収集部１１ｃは、下記の動作(c1)〜(c3)を行なう。
(c1) ＤＢ情報収集部１１ｃは、ＤＢサーバ１ｃにおいて、定期的に以下の情報(c11)および(c12)を収集する。
(c11) ＲＤＢＭＳの監査ログ等からＳＱＬ情報を収集する（図８の矢印Ａ２１参照）。
(c12) ＯＳのｐｓコマンド等を用いてＤＢサーバ１ｃのＯＳからプロセス情報を収集する（図８の矢印Ａ２２参照）。
【００７８】
(c2) ＤＢ情報収集部１１ｃは、ＤＢサーバ１ｃにおいて、ＳＱＬ情報に新規ＳＱＬログが追加されたときに以下の情報(c21)および(c22)を収集する。
(c21) ＲＤＢＭＳの監査ログ等からＳＱＬ情報を収集する（図８の矢印Ａ２１参照）。
(c22) ＯＳのｐｓコマンド等を用いてＤＢサーバ１ｃのＯＳからプロセス情報を収集する（図８の矢印Ａ２２参照）。
(c23)ＯＳのnetstatコマンドを用いてＤＢサーバ１ｃのＯＳからネットワーク情報を収集する（図８の矢印Ａ２３参照）。
【００７９】
(c3) ＤＢ情報収集部１１ｃは、上記(c1)および(c2)で収集・取得した以下の情報(c31)〜(c33)をローカルバッチ業務判断部１１１ａに通知する（図８の矢印Ａ１参照）。
(c31) ＲＤＢＭＳのＳＱＬ情報（新規ＳＱＬログの追加前と追加後のＳＱＬ情報）
(c32) ＯＳのプロセス情報（新規ＳＱＬログの追加前と追加後のプロセス情報）
(c33) ＯＳのネットワーク情報（新規ＳＱＬログの追加後のネットワーク情報）
【００８０】
なお、上記(c11)および(c21)において、ＤＢサーバ１ｃ内におけるＲＤＢＭＳの監査ログ等から、図９に示すようなＳＱＬ情報がＳＱＬ毎に収集される。図９に示す例では、ＳＱＬ情報として、情報取得時刻，プロセスＩＤ，セッションＩＤ，ＳＱＬ文，ＳＱＬの処理開始時刻およびＳＱＬの処理終了時刻が含まれている。
【００８１】
また、上記(c12)および(c22)において、ＯＳのｐｓコマンド等を用いてＤＢサーバ１ｃのＯＳから、図１０に示すようなプロセス情報がプロセス毎に収集される。図１０に示す例では、プロセス情報として、情報取得時刻，使用プロセス名，プロセスＩＤ，セッションＩＤ，ＣＰＵ使用率（％），メモリ使用量およびスレッド数が含まれている。
【００８２】
さらに、上記(c23)において、ＯＳのnetstatコマンドを用いてＤＢサーバ１ｃのＯＳから、図１１に示すようなネットワーク情報が収集される。図１１に示す例では、ネットワーク情報として、情報取得時刻，実行プロセス名，プロセスＩＤ，ローカルアドレスおよび外部アドレスが含まれている。
【００８３】
〔３−３〕ローカルバッチ業務判断部の機能および動作
次に、図１２〜図１６を参照しながら、ローカルバッチ業務判断部１１１ａの機能および動作について、より具体的に説明する。なお、図１２は、ローカルバッチ業務判断部１１１ａの機能および動作を説明する図である。図１３は、ＳＱＬ・業務種別履歴ＤＢ１２１に対する保存処理について説明する図である。図１４は、ＳＱＬ・業務種別履歴ＤＢ１２１に保存される情報の一例を示す図である。図１５は、バッチサーバ一覧情報ＤＢ１２２に対する保存処理について説明する図である。図１６は、バッチサーバ一覧情報ＤＢ１２２に保存される情報の一例を示す図である。
【００８４】
ローカルバッチ業務判断部１１１ａは、下記の動作(d1)〜(d5)を行なう。
(d1) ローカルバッチ業務判断部１１１ａは、ＤＢ情報収集部１１ｃから、ＲＤＢＭＳのＳＱＬ情報，ＯＳのプロセス情報およびＯＳのネットワーク情報を受け取る（図１２の矢印Ａ１参照）。
【００８５】
(d2) ローカルバッチ業務判断部１１１ａは、ＲＤＢＭＳのＳＱＬ情報から、追加されたＳＱＬの発行元プロセスＩＤを取得する。
【００８６】
(d3) ローカルバッチ業務判断部１１１ａは、ＤＢ情報収集部１１ｃから取得したＯＳのプロセス情報を参照し、当該ＯＳのプロセス情報に上記(d2)で取得したプロセスＩＤがあるか否かを判断する。
【００８７】
(d4) プロセスＩＤがあった場合、ローカルバッチ業務判断部１１１ａは、判別対象業務はローカルバッチ業務であると判別し、ＳＱＬと判別結果の業務種別情報“バッチ”とをＳＱＬ・業務特性履歴ＤＢ１２１に格納する（図１２の矢印Ａ２参照）。また、ローカルバッチ業務判断部１１１ａは、ＳＱＬ情報とネットワーク情報とに基づき、ローカルバッチを発行しているリモートバッチサーバ１ｄのＩＰアドレスを取得し、バッチサーバ一覧情報ＤＢ１２２に格納する（図１２の矢印Ａ３参照）。
【００８８】
(d5) プロセスＩＤがない場合つまりプロセスが追加されていない場合、ローカルバッチ業務判断部１１１ａは、判別対象業務はローカルバッチ業務以外であると判別する。そして、ローカルバッチ業務判断部１１１ａは、取得した各種情報をリモートバッチ業務判断部１１１ｂに通知するとともに、判断をリモートバッチ業務判断部１１１ｂに委譲する（図１２の矢印Ａ４参照）。
【００８９】
なお、ＳＱＬ・業務種別履歴ＤＢ１２１には、各判断部１１１ａ〜１１１ｃで業務種別がバッチ業務またはオンライン業務であると判別された場合、図１４に示すような情報が保存される（図１３の矢印Ａ２，Ａ７，Ａ１２参照）。つまり、ＳＱＬ・業務種別履歴ＤＢ１２１には、ＳＱＬ情報と、業務種別判別結果（バッチ業務／オンライン業務）と、ＳＱＬ発行元サーバのＩＰアドレスとが、ＳＱＬ毎に保存される。ＳＱＬ情報としては、図９に示したものと同様、情報取得時刻，プロセスＩＤ，セッションＩＤ，ＳＱＬ文，ＳＱＬの処理開始時刻およびＳＱＬの処理終了時刻が含まれている。
【００９０】
また、バッチサーバ一覧情報ＤＢ１２２には、各判断部１１１ａ，１１１ｂにおいて業務種別がバッチ業務であると判別された場合、図１６に示すような情報が保存される（図１５の矢印Ａ３，Ａ８参照）。つまり、バッチサーバ一覧情報ＤＢ１２２には、登録日時と、バッチ業務であると判別された業務の要求を発行しているバッチサーバのＩＰアドレスと、最終更新日時とが保存される。各判断部１１１ａ，１１１ｂからＤＢ１２２に送信されたバッチサーバのＩＰアドレスが新規である場合、ＤＢ１２２に新たなレコードが追加され、追加されたレコードに新たなＩＰアドレスが登録される。一方、当該ＩＰアドレスが新規でない場合（重複する場合）、当該ＩＰアドレスを登録されているレコードの最終更新日時の更新が行なわれる。
【００９１】
〔３−４〕リモートバッチ業務判断部およびＡＰ情報収集部／バッチ情報収集部の機能および動作
次に、図１７〜図２０を参照しながら、リモートバッチ業務判断部１１１ｂおよびＡＰ情報収集部１１ｂ／バッチ情報収集部１１ｄの機能および動作について、より具体的に説明する。なお、図１７および図２０は、リモートバッチ業務判断部１１１ｂの機能および動作を説明する図である。図１８は、ＡＰ情報収集部１１ｂまたはバッチ情報収集部１１ｄの機能および動作を説明する図である。図１９は、リモートバッチ業務判断部１１１ｂの判別基準について説明する図である。
【００９２】
リモートバッチ業務判断部１１１ｂは、まず、下記の動作(e1)〜(e3)を行なう。
(e1) リモートバッチ業務判断部１１１ｂは、ＳＱＬ情報に基づき、当該ＳＱＬの属するセッションで発行された連続するＳＱＬを特定し、前回のＳＱＬ開始時刻およびＳＱＬ終了時刻と、新規に発行された今回のＳＱＬの開始時刻とを取得する。
【００９３】
(e2) リモートバッチ業務判断部１１１ｂは、ＳＱＬ情報，プロセス情報およびネットワーク情報に基づき、リモートでＳＱＬを発行しているサーバのＩＰアドレスを取得する。前述したように、この時点で、リモートバッチ業務判断部１１１ｂは、ＳＱＬを発行したサーバがＡＰサーバ１ｂであるかバッチサーバ１ｄであるかは見えていない。
【００９４】
(e3) リモートバッチ業務判断部１１１ｂは、ＳＱＬ発行元サーバがサーバ１ｂかサーバ１ｄかを特定すべく、上記(e1)で取得した情報を、上記(e2)で取得したＩＰアドレスによって指定されるサーバ１ｂまたは１ｄに通知する（図１７の矢印Ａ５／Ａ６参照）。これにより、ＳＱＬ発行元サーバがサーバ１ｂかサーバ１ｄかを特定すべく、取得したＩＰアドレスで指定されるサーバ１ｂまたは１ｄに、プロセス情報およびネットワーク情報の収集が要求される。
【００９５】
この後、ＡＰ情報収集部１１ｂまたはバッチ情報収集部１１ｄは、下記の動作(f1)および(f2)を行なう。
(f1) 収集部１１ｂ／１１ｄは、以下の期間(f11)および(f12)におけるリソース使用状況（ＣＰＵ使用率，メモリ使用量）を、プロセス情報（処理実績情報）として取得する（図１８の矢印Ａ２４参照）。また、収集部１１ｂ／１１ｄは、ＯＳのnetstatコマンドを用いてサーバ１ｂ／１ｄのＯＳからネットワーク情報を取得する（図１８の矢印Ａ２５参照）。
【００９６】
(f11) 前回のＳＱＬの開始時刻から終了時刻までの間（図１９の期間ＴＡ）におけるリソース使用量（第１リソース使用量）。第１リソース使用量としては、期間ＴＡにおけるリソース使用量の平均値を用いることができる。
(f12) 前回のＳＱＬの終了時刻から今回のＳＱＬ（新規ＳＱＬ）の開始時刻までの間（図１９の期間ＴＢ）におけるリソース使用量（第２リソース使用量）。第２リソース使用量としては、期間ＴＢにおけるリソース使用量の平均値を用いることができる。
【００９７】
(f2) 収集部１１ｂ／１１ｄは、上記(f1)で取得した第１リソース使用量および第２リソース使用量を含むプロセス情報やサーバ１ｂ／１ｄのネットワーク情報をリモートバッチ業務判断部１１１ｂに通知する（図１８の矢印Ａ５／Ａ６参照）。
【００９８】
ここで、図１９を参照しながら、リモートバッチ業務判断部１１１ｂの判別基準、つまり判別対象業務がリモートバッチ業務であるかそれ以外の業務であるかの判別を行なう基準について説明する。
【００９９】
図１９（Ａ）に示すように、ＡＰサーバ１ｂでのプロセスのリソース使用量は、通常、期間ＴＡ，ＴＢに関係なくほぼ一定である。図１９（Ｂ）に示すように、ＤＢサーバ１ｃでは、期間ＴＡにＳＱＬの処理を行なうため、期間ＴＡのリソース使用量が多くなり、ＳＱＬ処理を終了した後の期間ＴＢのリソース使用量は、期間ＴＡのリソース使用量に対し減少する。図１９（Ｃ）に示すように、バッチサーバ１ｄでは、期間ＴＡの間はＤＢサーバ１ｃのＳＱＬ処理待ちであるためリソース使用量は少ないが、ＳＱＬ処理終了後にはバッチ処理が実行されるため、期間ＴＢのリソース使用量は、期間ＴＡのリソース使用量に対し増加する。
【０１００】
このようなリソースの使用状況（処理実績情報）の特性に基づき、リモートバッチ業務判断部１１１ｂは、期間ＴＡのリソース使用量（第１リソース使用量）に対して期間ＴＢのリソース使用量（第２リソース使用量）が増加する場合に、判別対象業務がリモートバッチ業務であると判別することができる。
【０１０１】
そこで、リモートバッチ業務判断部１１１ｂは、収集部１１ｂ／１１ｄからの通知を受けると（図２０の矢印Ａ５／Ａ６参照）、下記の動作(e4)〜(e6)を行なう。
(e4) リモートバッチ業務判断部１１１ｂは、収集部１１ｂ／１１ｄから受け取った情報（第１リソース使用量および第２リソース使用量）に基づき、判別対象業務がリモートバッチ業務であるかそれ以外の業務であるかの判別を行なう。つまり、リモートバッチ業務判断部１１１ｂは、第１リソース使用量に対して第２リソース使用量が増加しているか否かを判別する。
【０１０２】
(e5)第１リソース使用量に対して第２リソース使用量が増加していれば、リモートバッチ業務判断部１１１ｂは、判別対象業務はバッチサーバ１ｄによるリモートバッチ業務であると判別する。そして、リモートバッチ業務判断部１１１ｂは、ＳＱＬと判別結果の業務種別情報“バッチ”とをＳＱＬ・業務特性履歴ＤＢ１２１に格納する（図２０の矢印Ａ７参照）。また、リモートバッチ業務判断部１１１ｂは、ネットワーク情報に基づき、バッチサーバ１ｄのＩＰアドレスを取得し、バッチサーバ一覧情報ＤＢ１２２に格納する（図２０の矢印Ａ８参照）。
【０１０３】
(e6) 第１リソース使用量に対して第２リソース使用量が増加していない場合、リモートバッチ業務判断部１１１ｂは、判別対象業務はローカルバッチ業務およびリモートバッチ業務以外であると判別する。そして、リモートバッチ業務判断部１１１ｂは、取得した各種情報を判断部１１１ｃに通知するとともに、判断を判断部１１１ｃに委譲する（図２０の矢印Ａ９参照）。
【０１０４】
〔３−５〕Ｗｅｂサービスバッチ業務／オンライン業務判断部の機能および動作
次に、図２１を参照しながら、Ｗｅｂサービスバッチ業務／オンライン業務判断部１１１ｃの機能および動作について、より具体的に説明する。なお、図２１は、図６に示すＷｅｂサービスバッチ業務／オンライン業務判断部１１１ｃの機能および動作を説明する図である。
【０１０５】
判断部１１１ｃは、下記の動作(g1)〜(g4)を行なう。
(g1) 判断部１１１ｃは、リモートバッチ業務判断部１１１ｂから受け取ったＳＱＬ情報等（図２１の矢印Ａ９参照）と、収集部１１ａを通じて取得されたＷｅｂサーバ１ａのネットワーク情報（図２１の矢印Ａ１０参照）とに基づき、ＳＱＬ発行元サーバのＩＰアドレスを検出する。このとき、プロセスＩＤとローカルＩＰアドレス／外部ＩＰアドレスおよびポートとの組合せに基づきＷｅｂサーバ１ａの上流側を辿ることにより、ＳＱＬ発行元サーバのＩＰアドレスが検出される。
【０１０６】
(g2) 判断部１１１ｃは、上記(g1)で検出されたＳＱＬ発行元サーバのＩＰアドレスとバッチサーバ一覧情報ＤＢ１２２に格納されているＩＰアドレス（図２１の矢印Ａ１１参照）とを比較する。これにより、判断部１１１ｃは、バッチサーバ一覧情報ＤＢ１２２に、上記(g1)で検出されたＳＱＬ発行元サーバのＩＰアドレスと一致するものが保存されているか否かを判断する。
【０１０７】
(g3) ＳＱＬ発行元サーバのＩＰアドレスと一致するものがある場合、判断部１１１ｃは、判別対象業務はバッチサーバ１ｄによるＷｅｂサービスバッチ業務であると判別する。そして、判断部１１１ｃは、ＳＱＬと判別結果の業務種別情報“バッチ”とをＳＱＬ・業務特性履歴ＤＢ１２１に格納する（図２１の矢印Ａ１２参照）。
【０１０８】
(g4) ＳＱＬ発行元サーバのＩＰアドレスと一致するものがない場合、判断部１１１ｃは、判別対象業務はオンライン業務であると判別する。そして、判断部１１１ｃは、ＳＱＬと判別結果の業務種別情報“オンライン”とをＳＱＬ・業務特性履歴ＤＢ１２１に格納する（図２１の矢印Ａ１２参照）。
【０１０９】
〔３−６〕本実施形態の処理手順のフローチャートによる説明
次に、図２２〜図２５に示すフローチャートに従って、本実施形態の処理手順について説明する。
【０１１０】
〔３−６−１〕管理マネージャによる処理全体
まず、図２２に示すフローチャート（ステップＳ１〜Ｓ８）に従って、管理マネージャ１０１の動作（処理全体）について概略的に説明する。
【０１１１】
管理マネージャ１０１（処理部１１０）は、ＤＢサーバ１ｃにおいてＳＱＬログが出力される都度、ＤＢサーバ１ｃのＤＢ情報収集部１１ｃを通じて、ＤＢサーバ１ｃのＳＱＬ情報を取得する（ステップＳ１）。この後、管理マネージャ１０１は、ＳＱＬアクセスの発生ログが出力されたか否かを判定する（ステップＳ２）。ＳＱＬアクセスの発生ログが出力されていない場合（ステップＳ２のＮＯルート）、管理マネージャ１０１は、ステップＳ１の処理に戻る。
【０１１２】
ＳＱＬアクセスの発生ログが出力された場合（ステップＳ２のＹＥＳルート）、管理マネージャ１０１（判断部１１１ａ）は、判別対象業務がローカルバッチ業務であるかそれ以外の業務であるかを判別する（ステップＳ３；図２３参照）。判別対象業務がローカルバッチ業務である場合（ステップＳ４のＹＥＳルート）、管理マネージャ１０１（処理部１１０）は、ステップＳ８の処理に移行する。
【０１１３】
判別対象業務がローカルバッチ業務でない場合（ステップＳ４のＮＯルート）、管理マネージャ１０１（判断部１１１ｂ）は、判別対象業務がリモートバッチ業務であるかそれ以外の業務であるかを判別する（ステップＳ５；図２４参照）。判別対象業務がリモートバッチ業務である場合（ステップＳ６のＹＥＳルート）、管理マネージャ１０１（処理部１１０）は、ステップＳ８の処理に移行する。
【０１１４】
判別対象業務がリモートバッチ業務でない場合（ステップＳ６のＮＯルート）、管理マネージャ１０１（判断部１１１ｃ）は、判別対象業務がＷｅｂサービスバッチ業務であるかオンライン業務であるかを判別する（ステップＳ７；図２５参照）。
【０１１５】
以上のようにして判別対象業務がバッチ業務であるかオンライン業務であるかが判別されると、管理マネージャ１０１（リソース制御部１１２）は、ステップＳ８において、判別部１１１による判別結果に基づき業務システム１（サーバ１ａ〜１ｄ）に割り当てられるリソースの制御を行なう（ステップＳ８）。つまり、業務システム１において実行すべき業務の業務種別がオンライン業務かバッチ業務かに応じたリソース制御（オートスケール）が実行される。
【０１１６】
〔３−６−２〕ローカルバッチ業務判断処理
次に、図２３に示すフローチャート（ステップＳ３１〜Ｓ３７）に従って、図２２に示すステップＳ３のローカルバッチ業務判断処理について説明する。
【０１１７】
まず、ローカルバッチ業務判断部１１１ａは、ＤＢサーバ１ｃのＤＢ情報収集部１１ｃを通じて、ＯＳのプロセス情報，ＲＤＢＭＳのＳＱＬ情報，ＯＳのネットワーク情報を取得する（ステップＳ３１）。
【０１１８】
ローカルバッチ業務判断部１１１ａは、ＤＢ情報収集部１１ｃから情報を取得すると、ＲＤＢＭＳのＳＱＬ情報から、追加されたＳＱＬの発行元プロセスＩＤを取得する（ステップＳ３２）。
【０１１９】
そして、ローカルバッチ業務判断部１１１ａは、ＤＢ情報収集部１１ｃから取得したＯＳのプロセス情報を参照し、当該ＯＳのプロセス情報にステップＳ３２で取得したプロセスＩＤがあるか否かを判断する（ステップＳ３３）。
【０１２０】
プロセスＩＤがあった場合（ステップＳ３３のＹＥＳルート）、ローカルバッチ業務判断部１１１ａは、判別対象業務はローカルバッチ業務であると判別し、ＳＱＬと判別結果の業務種別情報“バッチ”とをＳＱＬ・業務特性履歴ＤＢ１２１に格納する（ステップＳ３４）。また、ローカルバッチ業務判断部１１１ａは、追加されたＳＱＬの情報とネットワーク情報とに基づき、ローカルバッチを発行しているリモートバッチサーバ１ｄのＩＰアドレスを取得し（ステップＳ３５）、バッチサーバ一覧情報ＤＢ１２２に格納する（ステップＳ３６）。この後、管理マネージャ１０１は、ステップＳ８の処理へ移行する（図２２のステップＳ４のＹＥＳルート参照）。
【０１２１】
一方、プロセスＩＤがない場合つまりプロセスが追加されていない場合（ステップＳ３３のＮＯルート）、ローカルバッチ業務判断部１１１ａは、判別対象業務はローカルバッチ業務以外であると判別する。そして、ローカルバッチ業務判断部１１１ａは、ＤＢサーバ１ｃのプロセス情報，ネットワーク情報，ＳＱＬ情報と、追加されたＳＱＬ情報とを、ステップＳ５の処理つまりリモートバッチ業務判断部１１１ｂに通知する（ステップＳ３８）。この後、管理マネージャ１０１は、ステップＳ５の処理へ移行する（図２２のステップＳ４のＮＯルート参照）。
【０１２２】
〔３−６−３〕リモートバッチ業務判断処理
次に、図２４に示すフローチャート（ステップＳ５１〜Ｓ５８）に従って、図２２に示すステップＳ５のリモートバッチ業務判断処理について説明する。
【０１２３】
まず、リモートバッチ業務判断部１１１ｂは、ステップＳ３の処理（ローカルバッチ業務判断部１１１ａ）から、ＤＢサーバ１ｃのプロセス情報，ネットワーク情報，ＳＱＬ情報と、追加されたＳＱＬ情報とを取得する（ステップＳ５１）。
【０１２４】
リモートバッチ業務判断部１１１ｂは、各種情報を取得すると、ＳＱＬ情報に基づき、当該ＳＱＬの属するセッションで発行された連続するＳＱＬを特定し、前回のＳＱＬ開始時刻およびＳＱＬ終了時刻と、新規に発行された今回のＳＱＬの開始時刻とを取得する（ステップＳ５２）。
【０１２５】
また、リモートバッチ業務判断部１１１ｂは、ＳＱＬ情報，プロセス情報およびネットワーク情報に基づき、リモートでＳＱＬを発行しているサーバのＩＰアドレスを取得する（ステップＳ５３）。
【０１２６】
そして、リモートバッチ業務判断部１１１ｂは、ステップＳ５３で取得したＩＰアドレスによって指定されるサーバ１ｂまたは１ｄから、図１９を参照しながら前述した第１リソース使用量および第２リソース使用量を、収集部１１ｂまたは１１ｄにより取得する（ステップＳ５４）。ここで、前述した通り、第１リソース使用量は、前回のＳＱＬの開始時刻から終了時刻までの間（図１９の期間ＴＡ）におけるリソース使用量である。また、第２リソース使用量は、前回のＳＱＬの終了時刻から今回のＳＱＬ（新規ＳＱＬ）の開始時刻までの間（図１９の期間ＴＢ）におけるリソース使用量である。
【０１２７】
リモートバッチ業務判断部１１１ｂは、収集部１１ｂまたは１１ｄから受け取った第１リソース使用量および第２リソース使用量に基づき、判別対象業務がリモートバッチ業務であるかそれ以外の業務であるかの判別を行なう。つまり、リモートバッチ業務判断部１１１ｂは、期間ＴＡのプロセスの第１リソース使用量に対して期間ＴＢのプロセスの第２リソース使用量が増加しているか否かを判別する（ステップＳ５５）。
【０１２８】
第１リソース使用量に対して第２リソース使用量が増加していれば（ステップＳ５５のＹＥＳルート）、リモートバッチ業務判断部１１１ｂは、判別対象業務はバッチサーバ１ｄによるリモートバッチ業務であると判別する。そして、リモートバッチ業務判断部１１１ｂは、ＳＱＬと判別結果の業務種別情報“バッチ”とをＳＱＬ・業務特性履歴ＤＢ１２１に格納する（ステップＳ５６）。また、リモートバッチ業務判断部１１１ｂは、ネットワーク情報に基づき、バッチサーバ１ｄのＩＰアドレスを取得し、バッチサーバ一覧情報ＤＢ１２２に格納する（ステップＳ５７）。この後、管理マネージャ１０１は、ステップＳ８の処理へ移行する（図２２のステップＳ６のＹＥＳルート参照）。
【０１２９】
一方、第１リソース使用量に対して第２リソース使用量が増加していない場合（ステップＳ５５のＮＯルート）、リモートバッチ業務判断部１１１ｂは、判別対象業務はローカルバッチ業務およびリモートバッチ業務以外であると判別する。そして、リモートバッチ業務判断部１１１ｂは、追加されたＳＱＬ情報と、ステップＳ５３で取得されたＡＰサーバ１ｂのＩＰアドレスとを、ステップＳ７の処理つまり判断部１１１ｃに通知する（ステップＳ５８）。管理マネージャ１０１は、ステップＳ７の処理へ移行する（図２２のステップＳ６のＮＯルート参照）。
【０１３０】
〔３−６−４〕Ｗｅｂサービスバッチ業務／オンライン業務判断処理
次に、図２５に示すフローチャート（ステップＳ７１〜Ｓ７５）に従って、図２２に示すステップＳ７のＷｅｂサービスバッチ業務／オンライン業務判断処理について説明する。
【０１３１】
判断部１１１ｃは、ステップＳ５の処理（リモートバッチ業務判断部１１１ｂ）から、追加されたＳＱＬ情報とＡＰサーバ１ｂのＩＰアドレスとを取得する（ステップＳ７１）。
【０１３２】
判断部１１１ｃは、ＡＰサーバ１ｂのＩＰアドレスと、収集部１１ａを通じて取得されたＷｅｂサーバ１ａのネットワーク情報とに基づき、ＳＱＬ発行元サーバのＩＰアドレスを検出する（ステップＳ７２）。
【０１３３】
そして、判断部１１１ｃは、バッチサーバ一覧情報ＤＢ１２２に、ステップＳ７２で検出されたＳＱＬ発行元サーバのＩＰアドレスと一致するものが保存されているか否かを判断する（ステップＳ７３）。
【０１３４】
ＳＱＬ発行元サーバのＩＰアドレスと一致するものが保存されている場合（ステップＳ７３のＹＥＳルート）、判断部１１１ｃは、判別対象業務はバッチサーバ１ｄによるＷｅｂサービスバッチ業務であると判別する。そして、判断部１１１ｃは、ＳＱＬと判別結果の業務種別情報“バッチ”とをＳＱＬ・業務特性履歴ＤＢ１２１に格納する（ステップＳ７４）。この後、管理マネージャ１０１は、ステップＳ８の処理へ移行する。
【０１３５】
一方、ＳＱＬ発行元サーバのＩＰアドレスと一致するものが保存されていない場合（ステップＳ７３のＮＯルート）、判断部１１１ｃは、判別対象業務はオンライン業務であると判別する。そして、判断部１１１ｃは、ＳＱＬと判別結果の業務種別情報“オンライン”とをＳＱＬ・業務特性履歴ＤＢ１２１に格納する（ステップＳ７５）。この後、管理マネージャ１０１は、ステップＳ８の処理へ移行する。
【０１３６】
〔３−７〕具体例による動作説明
次に、図２６〜図３５を参照しながら、本実施形態による判断動作について具体的に説明する。
【０１３７】
〔３−７−１〕ローカルバッチ業務判断処理
まず、図２６〜図２８を参照しながら、本実施形態のローカルバッチ業務判断処理について具体的に説明する。なお、図２６はＳＱＬ情報の一例を示す図、図２７はプロセス情報の一例を示す図、図２８はネットワーク情報の一例を示す図である。
【０１３８】
図２６に示すように、新規ＳＱＬ情報がレコードＲ１として追加された場合、ローカルバッチ業務判断部１１１ａは、レコードＲ１のプロセスＩＤ“2483”とＳＱＬの処理開始時刻“2013/07/10_17:41:56”とをキーとして、図２７に示すプロセス情報を検索する。
【０１３９】
図２７に示す例では、レコードＲ２がヒットするので、ローカルバッチ業務判断部１１１ａは、判別対象業務はローカルバッチ業務であると判別する。そして、ローカルバッチ業務判断部１１１ａは、プロセスＩＤ“2483”をキーとして、図２８に示すネットワーク情報を検索する。
【０１４０】
このとき、図２８に示す例では、レコードＲ３が検索され、当該レコードＲ３のローカルアドレスおよび外部アドレスから、ローカルバッチを発行しているリモートバッチサーバ１ｄのＩＰアドレスが取得される。取得されたＩＰアドレスは、バッチサーバ一覧情報ＤＢ１２２に登録される。一方、プロセス情報を検索してもヒットしなかった場合、ローカルバッチ業務判断部１１１ａは、判断をリモートバッチ業務判断部１１１ｂに委譲する。
【０１４１】
〔３−７−２〕リモートバッチ業務判断処理
次に、図２９〜図３１を参照しながら、本実施形態のローカルバッチ業務判断処理について具体的に説明する。なお、図２９はＳＱＬ情報の一例を示す図、図３０はネットワーク情報の一例を示す図、図３１はリソース使用状況（処理実績情報）の一例を示す図である。
【０１４２】
リモートバッチ業務判断部１１１ｂは、図２９に示すＳＱＬ情報に基づき、前回のＳＱＬ情報としてレコードＲ４を検索し、今回のＳＱＬ情報としてレコードＲ５を検索する。これらのレコードＲ４，Ｒ５は、同じプロセスＩＤ“2483”を有し、同じセッションで発行された連続するＳＱＬに対応している。このとき、レコードＲ４から前回のＳＱＬの処理開始時刻“2013/07/10_17:40:51”および処理終了時刻“2013/07/10_17:40:59”が取得され、レコードＲ５から今回のＳＱＬの処理開始時刻“2013/07/10_17:41:56”が取得される。
【０１４３】
さらに、リモートバッチ業務判断部１１１ｂは、プロセスＩＤ“2483”をキーとして、図３０に示すネットワーク情報を検索する。このとき、図３０に示す例では、レコードＲ６が検索され、当該レコードＲ６のローカルアドレスおよび外部アドレスから、リモートでＳＱＬを発行しているサーバ１ｂまたは１ｄのＩＰアドレスが取得される。
【０１４４】
そして、リモートバッチ業務判断部１１１ｂは、図３０のレコードＲ６から取得されたＩＰアドレスによって指定されるサーバ１ｂまたは１ｄから、図３１に示すようなリソース使用状況を取得する。このとき、リモートバッチ業務判断部１１１ｂは、当該リソース使用状況を取得してから、当該リソース使用状況に基づき第１リソース使用量および第２リソース使用量を取得してもよい。また、リモートバッチ業務判断部１１１ｂは、サーバ１ｂまたは１ｄの収集部１１ｂまたは１１ｄ側で当該リソース使用状況に基づき取得された第１リソース使用量および第２リソース使用量を、収集部１１ｂまたは１１ｄから取得してもよい。
【０１４５】
図２９および図３１に示す例では、前回のＳＱＬの処理開始時刻“2013/07/10_17:40:51”から処理終了時刻“2013/07/10_17:40:59”までの間（図１９の期間ＴＡ）におけるリソース使用量が第１リソース使用量となる。また、前回のＳＱＬの処理終了時刻“2013/07/10_17:40:59”から今回のＳＱＬの処理開始時刻“2013/07/10_17:41:56”までの間（図１９の期間ＴＢ）におけるリソース使用量が第２リソース使用量となる。
【０１４６】
従って、図３１に示すリソース使用状況から、第１リソース使用量（ＣＰＵ使用率およびメモリ使用量）としては３５．２％および３２０ＭＢが取得される。また、図３１に示すリソース使用状況から、第２リソース使用量（ＣＰＵ使用率およびメモリ使用量）としては、符号Ｐ１，Ｐ２を付した領域の値が取得される。つまり、第２リソース使用量としては、例えば平均値３５．１％および３０５ＭＢが取得される。
【０１４７】
このとき、第１リソース使用量に対して第２リソース使用量が増加していないため、リモートバッチ業務判断部１１１ｂは、判別対象業務はバッチサーバ１ｄによるリモートバッチ業務ではないと判別する。そして、リモートバッチ業務判断部１１１ｂは、図３０のレコードＲ６から取得されたＩＰアドレスをＡＰサーバ１ｂのＩＰアドレスを判断部１１１ｃに通知するとともに、判断を判断部１１１ｃに委譲する。一方、第１リソース使用量に対して第２リソース使用量が増加していれば、図３０のレコードＲ６から取得されたＩＰアドレスは、バッチサーバ１ｄのＩＰアドレスとしてバッチサーバ一覧情報ＤＢ１２２に登録される。
【０１４８】
〔３−７−３〕Ｗｅｂサービスバッチ業務／オンライン業務判断処理
次に、図３２〜図３４を参照しながら、本実施形態のＷｅｂサービスバッチ業務／オンライン業務判断処理について具体的に説明する。なお、図３２はＳＱＬ情報の一例を示す図、図３３はネットワーク情報の一例を示す図、図３４はバッチサーバ一覧情報ＤＢ１２２に保存される情報の一例を示す図である。
【０１４９】
判断部１１１ｃは、図３２に示す新規ＳＱＬ情報のレコードＲ７のプロセスＩＤ“2483”をキーとして、Ｗｅｂサーバ１ａから取得された図３３に示すネットワーク情報を検索する。図３３に示す例では、レコードＲ８がヒットし、ＳＱＬ発行元サーバのＩＰアドレスとして“192.168.1.90”が検出される。
【０１５０】
そして、判断部１１１ｃは、検出されたＩＰアドレス“192.168.1.90”をキーとして、図３４に示すようなバッチサーバ一覧情報を検索する。図３４に示す例では、レコードＲ９がヒットするため、判断部１１１ｃは、判別対象業務はバッチサーバ１ｄによるＷｅｂサービスバッチ業務であると判別する。一方、バッチサーバ一覧情報を検索してもヒットしなかった場合、判断部１１１ｃは、判別対象業務はオンライン業務であると判別する。
【０１５１】
〔３−７−４〕判別処理終了時のアウトプット
次に、図３５を参照しながら、本実施形態による判別処理終了時のアウトプット例について具体的に説明する。なお、図３５は、本実施形態による判別結果として出力される、ＳＱＬ・業務種別履歴ＤＢ１２１の情報の一例を示す図である。
【０１５２】
本実施形態においては、全ての業務が、ＳＱＬ単位で、オンライン業務であるかバッチ業務であるかを判別される。そして、ＳＱＬ・業務種別履歴ＤＢ１２１において、例えば図３５に示すように、ＳＱＬ情報と判別結果である業務種別と処理要求（業務）の発行元サーバのＩＰアドレスとが対応付けられて登録される。このようなＳＱＬ・業務種別履歴ＤＢ１２１が、本実施形態による判別結果として出力される
【０１５３】
〔４〕本実施形態の効果
本実施形態によれば、複数のサーバ１ａ〜１ｄを含む業務システム１上で稼働している全ての業務処理について、ＤＢサーバ１ｃを利用しているメイン業務がオンライン業務であるかバッチ業務であるかを適切に判別することができる。このため、今まで対応が困難であったメイン業務の種別によってスケーリング方法を変更するなど、業務特性に応じた運用を行なうことができる。つまり、業務の切替えタイミングや業務特性に応じて適切なスケーリングを自動的に行なうことができる。したがって、性能維持しつつ低コストでシステム運用を行なうことができる。
【０１５４】
また、本実施形態によれば、ＯＳ等から取得できる一般的な情報（ＳＱＬ情報，プロセス情報，ネットワーク情報）に基づき、オンライン業務かバッチ業務かを適切に自動判別可能になる。このため、上述のように業務特性に応じたオートスケールが実現されるだけでなく、ミドルウェアの連携情報や利用サーバがオンライン業務用であるかバッチ業務用であるかといった情報が無くても、オンライン業務であるかバッチ業務であるかの判別を適切に行なうことができる。つまり、本実施形態によれば、特別な情報を必要とすることなく、外観から観察できる情報に基づきＤＢサーバ１ｃへの要求発行元の業務種別を適切に自動判別することができる。
【０１５５】
さらに、本実施形態によれば、バッチ業務については、ローカルバッチ業務，リモートバッチ業務，Ｗｅｂサービスバッチ業務を判別することが可能である。バッチ業務をＷｅｂサービス経由で行なう技術は新しく確立された技術であるため、公知技術では、Ｗｅｂサービスバッチ業務とオンライン業務との区別がつかず、オンライン業務かバッチ業務かの判断を行なうことができなかった。本実施形態によれば、業務の発信源（ＳＱＬ発行元サーバ）まで辿ることができるため、上述した技術にも対応でき、業務種別を正確に判別することができる。
【０１５６】
また、本実施形態によれば、リソース制御部１１２は、業務種別がオンライン業務かバッチ業務かに応じてサーバ１ａ〜１ｄに割り当てられるリソースの制御を行なうことができる。このため、例えば、リソース制御部１１２は、実行すべき業務がオンライン業務である場合、上記技術(b2)を業務システム１に適用するように制御を行なう一方、実行すべき業務がバッチ業務である場合、上記技術(b2)の適用を解除するように制御を行なうことができる。これにより、バッチ業務時にサーバ／リソースの処理性能が最大限に使用されても、バッチ業務が完了するまで際限なくスケールアウト／スケールアップが繰り返されるのを確実に抑止することができる。
【０１５７】
〔５〕その他
以上、本発明の好ましい実施形態について詳述したが、本発明は、係る特定の実施形態に限定されるものではなく、本発明の趣旨を逸脱しない範囲内において、種々の変形、変更して実施することができる。
【０１５８】
〔６〕付記
以上の各実施形態を含む実施形態に関し、さらに以下の付記を開示する。
（付記１）
第１のコンピュータに対する第２のコンピュータによる処理要求の処理要求内容を取得し、
前記の第１および第２のコンピュータそれぞれの動作に関する第１および第２の動作情報を取得し、
前記第１のコンピュータに対する前記処理要求の処理要求内容に含まれる当該処理要求に対応した前記第１のコンピュータによる処理履歴と当該処理要求を行なった前記第２のコンピュータの当該処理要求に関連した前記第２の動作情報とを対応づけた処理実績情報と、前記処理要求内容と、前記の第１および第２の動作情報とに基づき、前記処理要求の処理要求種別を判別する、
処理をプロセッサに実行させる、制御プログラム。
【０１５９】
（付記２）
前記処理要求種別の判別結果に基づき前記コンピュータに割り当てられるリソースの制御を行なう、
処理を前記プロセッサに実行させる、付記１記載の制御プログラム。
【０１６０】
（付記３）
前記第１のコンピュータとしてデータベースサーバを含み、前記第２のコンピュータとしてウエブサーバ，アプリケーションサーバおよびバッチサーバを含む場合、
前記処理要求の処理要求内容に含まれる当該処理要求の発行元プロセス識別情報が、前記データベースサーバから取得された前記第１の動作情報に含まれるプロセス情報にあるか否かを判別し、
当該処理要求の発行元プロセス識別情報が前記プロセス情報にあれば、前記処理要求の処理要求種別は、前記バッチサーバによるローカルバッチ処理であると判別し、
前記処理要求の処理要求内容と前記第１の動作情報とに基づき、前記ローカルバッチ処理の処理要求を発行した前記バッチサーバの第１アドレス情報を取得し、
前記第１アドレス情報を保存部に保存する、
処理を前記プロセッサに実行させる、付記１または付記２記載の制御プログラム。
【０１６１】
（付記４）
当該処理要求の発行元プロセス識別情報が前記プロセス情報になければ、前記処理要求の処理要求内容と前記第１の動作情報とに基づき、当該処理要求を発行したサーバの第２アドレス情報を取得し、
前記第２アドレス情報で指定されるサーバから、前回の処理要求による処理開始から処理終了までの第１リソース使用量と前記処理終了から当該処理要求による処理開始までの第２リソース使用量とを前記処理実績情報として取得し、
前記第１リソース使用量に対して前記第２リソース使用量が増加しているか否かを判別し、
前記第１リソース使用量に対して前記第２リソース使用量が増加していれば、前記処理要求の処理要求種別は、前記バッチサーバによるリモートバッチ処理であると判別し、
前記第２アドレス情報を、前記バッチサーバのアドレス情報として前記保存部に保存する、
処理を前記プロセッサに実行させる、付記３記載の制御プログラム。
【０１６２】
（付記５）
前記第１リソース使用量に対して前記第２リソース使用量が増加していなければ、前記第２アドレス情報を前記アプリケーションサーバのアドレス情報として取得し、
前記処理要求の処理要求内容と前記アプリケーションサーバのアドレス情報と前記ウエブサーバから取得された前記第１の動作情報とに基づき、当該処理要求の発行元サーバの第３アドレス情報を検出し、
前記第３アドレス情報が前記保存部に保存されているか否かを判別し、
前記第３アドレス情報が前記保存部に保存されていれば、前記処理要求の処理要求種別は、前記バッチサーバによって前記ウエブサーバ経由で行なわれるウエブサービスバッチ処理であると判別する、
処理を前記プロセッサに実行させる、付記４記載の制御プログラム。
【０１６３】
（付記６）
前記第３アドレス情報が前記保存部に保存されていなければ、前記処理要求の処理要求種別は、オンライン処理であると判別する、
処理を前記プロセッサに実行させる、付記４または付記５記載の制御プログラム。
【０１６４】
（付記７）
第１のコンピュータに対する第２のコンピュータによる処理要求の処理要求内容を取得する第１取得部と、
前記の第１および第２のコンピュータそれぞれの動作に関する第１および第２の動作情報を取得する第２取得部と、
前記第１のコンピュータに対する前記処理要求の処理要求内容に含まれる当該処理要求に対応した前記第１のコンピュータによる処理履歴と当該処理要求を行なった前記第２のコンピュータの当該処理要求に関連した前記第２の動作情報とを対応づけた処理実績情報と、前記処理要求内容と、前記の第１および第２の動作情報とに基づき、前記処理要求の処理要求種別を判別する判別部と、を有する、制御装置。
【０１６５】
（付記８）
前記処理要求種別の判別結果に基づき前記コンピュータに割り当てられるリソースの制御を行なうリソース制御部を、さらに有する、付記７記載の制御装置。
【０１６６】
（付記９）
前記第１のコンピュータとしてデータベースサーバを含み、前記第２のコンピュータとしてウエブサーバ，アプリケーションサーバおよびバッチサーバを含む場合、
前記判別部は、
前記処理要求の処理要求内容に含まれる当該処理要求の発行元プロセス識別情報が、前記データベースサーバから取得された前記第１の動作情報に含まれるプロセス情報にあるか否かを判別し、
当該処理要求の発行元プロセス識別情報が前記プロセス情報にあれば、前記処理要求の処理要求種別は、前記バッチサーバによるローカルバッチ処理であると判別し、
前記処理要求の処理要求内容と前記第１の動作情報とに基づき、前記ローカルバッチ処理の処理要求を発行した前記バッチサーバの第１アドレス情報を取得し、
前記第１アドレス情報を保存部に保存する、付記７または付記８記載の制御装置。
【０１６７】
（付記１０）
前記判別部は、
当該処理要求の発行元プロセス識別情報が前記プロセス情報になければ、前記処理要求の処理要求内容と前記第１の動作情報とに基づき、前記第２取得部によって当該処理要求を発行したサーバの第２アドレス情報を取得し、
前記第２アドレス情報で指定されるサーバから、前回の処理要求による処理開始から処理終了までの第１リソース使用量と前記処理終了から当該処理要求による処理開始までの第２リソース使用量とを前記処理実績情報として取得し、
前記第１リソース使用量に対して前記第２リソース使用量が増加しているか否かを判別し、
前記第１リソース使用量に対して前記第２リソース使用量が増加していれば、前記処理要求の処理要求種別は、前記バッチサーバによるリモートバッチ処理であると判別し、
前記第２アドレス情報を、前記バッチサーバのアドレス情報として前記保存部に保存する、付記９記載の制御装置。
【０１６８】
（付記１１）
前記判別部は、
前記第１リソース使用量に対して前記第２リソース使用量が増加していなければ、前記第２アドレス情報を前記アプリケーションサーバのアドレス情報として取得し、
前記処理要求の処理要求内容と前記アプリケーションサーバのアドレス情報と前記ウエブサーバから取得された前記第１の動作情報とに基づき、当該処理要求の発行元サーバの第３アドレス情報を検出し、
前記第３アドレス情報が前記保存部に保存されているか否かを判別し、
前記第３アドレス情報が前記保存部に保存されていれば、前記処理要求の処理要求種別は、前記バッチサーバによって前記ウエブサーバ経由で行なわれるウエブサービスバッチ処理であると判別する、付記１０記載の制御装置。
【０１６９】
（付記１２）
前記判別部は、
前記第３アドレス情報が前記保存部に保存されていなければ、前記処理要求の処理要求種別は、オンライン処理であると判別する、付記１０または付記１１記載の制御装置。
【０１７０】
（付記１３）
プロセッサが、
第１のコンピュータに対する第２のコンピュータによる処理要求の処理要求内容を取得し、
前記の第１および第２のコンピュータそれぞれの動作に関する第１および第２の動作情報を取得し、
前記第１のコンピュータに対する前記処理要求の処理要求内容に含まれる当該処理要求に対応した前記第１のコンピュータによる処理履歴と当該処理要求を行なった前記第２のコンピュータの当該処理要求に関連した前記第２の動作情報とを対応づけた処理実績情報と、前記処理要求内容と、前記の第１および第２の動作情報とに基づき、前記処理要求の処理要求種別を判別する、制御方法。
【０１７１】
（付記１４）
前記プロセッサが、
前記処理要求種別の判別結果に基づき前記コンピュータに割り当てられるリソースの制御を行なう、付記１３記載の制御方法。
【０１７２】
（付記１５）
前記第１のコンピュータとしてデータベースサーバを含み、前記第２のコンピュータとしてウエブサーバ，アプリケーションサーバおよびバッチサーバを含む場合、
前記プロセッサが、
前記処理要求の処理要求内容に含まれる当該処理要求の発行元プロセス識別情報が、前記データベースサーバから取得された前記第１の動作情報に含まれるプロセス情報にあるか否かを判別し、
当該処理要求の発行元プロセス識別情報が前記プロセス情報にあれば、前記処理要求の処理要求種別は、前記バッチサーバによるローカルバッチ処理であると判別し、
前記処理要求の処理要求内容と前記第１の動作情報とに基づき、前記ローカルバッチ処理の処理要求を発行した前記バッチサーバの第１アドレス情報を取得し、
前記第１アドレス情報を保存部に保存する、付記１３または付記１４記載の制御方法。
【０１７３】
（付記１６）
前記プロセッサが、
当該処理要求の発行元プロセス識別情報が前記プロセス情報になければ、前記処理要求の処理要求内容と前記第１の動作情報とに基づき、当該処理要求を発行したサーバの第２アドレス情報を取得し、
前記第２アドレス情報で指定されるサーバから、前回の処理要求による処理開始から処理終了までの第１リソース使用量と前記処理終了から当該処理要求による処理開始までの第２リソース使用量とを前記処理実績情報として取得し、
前記第１リソース使用量に対して前記第２リソース使用量が増加しているか否かを判別し、
前記第１リソース使用量に対して前記第２リソース使用量が増加していれば、前記処理要求の処理要求種別は、前記バッチサーバによるリモートバッチ処理であると判別し、
前記第２アドレス情報を、前記バッチサーバのアドレス情報として前記保存部に保存する、付記１５記載の制御方法。
【０１７４】
（付記１７）
前記プロセッサが、
前記第１リソース使用量に対して前記第２リソース使用量が増加していなければ、前記第２アドレス情報を前記アプリケーションサーバのアドレス情報として取得し、
前記処理要求の処理要求内容と前記アプリケーションサーバのアドレス情報と前記ウエブサーバから取得された前記第１の動作情報とに基づき、当該処理要求の発行元サーバの第３アドレス情報を検出し、
前記第３アドレス情報が前記保存部に保存されているか否かを判別し、
前記第３アドレス情報が前記保存部に保存されていれば、前記処理要求の処理要求種別は、前記バッチサーバによって前記ウエブサーバ経由で行なわれるウエブサービスバッチ処理であると判別する、付記１６記載の制御方法。
【０１７５】
（付記１８）
前記プロセッサが、
前記第３アドレス情報が前記保存部に保存されていなければ、前記処理要求の処理要求種別は、オンライン処理であると判別する、付記１６または付記１７に記載の制御方法。
【符号の説明】
【０１７６】
１    業務システム
１ａ    Ｗｅｂサーバ（ウエブサーバ，第２のコンピュータ）
１ｂ    ＡＰサーバ（アプリケーションサーバ，第２のコンピュータ）
１ｃ    ＤＢサーバ（データベースサーバ，第１のコンピュータ）
１ｄ    バッチサーバ（第２のコンピュータ）
２    クライアント端末（エンドユーザ）
３    ネットワーク
１０ａ，１０ｂ，１０ｃ，１０ｄ    管理エージェント
１１ａ    Ｗｅｂ情報収集部（第２取得部）
１１ｂ    ＡＰ情報収集部（第２取得部）
１１ｃ    ＤＢ情報収集部（第１取得部，第２取得部）
１１ｄ    バッチ情報収集部（第２取得部）
１００    管理サーバ（制御装置）
１０１    管理マネージャ
１１０    処理部（ＣＰＵ，プロセッサ，第１取得部，第２取得部）
１１１    判別部
１１１ａ    ローカルバッチ業務判断部（判別部）
１１１ｂ    リモートバッチ業務判断部（判別部）
１１１ｃ    Ｗｅｂサービスバッチ業務／オンライン業務判断部（判別部）
１１２    リソース制御部
１２０    記憶部（メモリ，保存部）
１２１    ＳＱＬ・業務種別履歴ＤＢ
１２２    バッチサーバ一覧情報ＤＢ
【図１】
2015141574.tif 000003
【図２】
2015141574.tif 000004
【図３】
2015141574.tif 000005
【図４】
2015141574.tif 000006
【図５】
2015141574.tif 000007
【図６】
2015141574.tif 000008
【図７】
2015141574.tif 000009
【図８】
2015141574.tif 000010
【図９】
2015141574.tif 000011
【図１０】
2015141574.tif 000012
【図１１】
2015141574.tif 000013
【図１２】
2015141574.tif 000014
【図１３】
2015141574.tif 000015
【図１４】
2015141574.tif 000016
【図１５】
2015141574.tif 000017
【図１６】
2015141574.tif 000018
【図１７】
2015141574.tif 000019
【図１８】
2015141574.tif 000020
【図１９】
2015141574.tif 000021
【図２０】
2015141574.tif 000022
【図２１】
2015141574.tif 000023
【図２２】
2015141574.tif 000024
【図２３】
2015141574.tif 000025
【図２４】
2015141574.tif 000026
【図２５】
2015141574.tif 000027
【図２６】
2015141574.tif 000028
【図２７】
2015141574.tif 000029
【図２８】
2015141574.tif 000030
【図２９】
2015141574.tif 000031
【図３０】
2015141574.tif 000032
【図３１】
2015141574.tif 000033
【図３２】
2015141574.tif 000034
【図３３】
2015141574.tif 000035
【図３４】
2015141574.tif 000036
【図３５】
2015141574.tif 000037
【図３６】
2015141574.tif 000038
【図３７】
2015141574.tif 000039
【図３８】
2015141574.tif 000040
【図３９】
2015141574.tif 000041