JP6273866B2 - 制御プログラム、制御装置および制御方法 - Google Patents

制御プログラム、制御装置および制御方法 Download PDF

Info

Publication number
JP6273866B2
JP6273866B2 JP2014014203A JP2014014203A JP6273866B2 JP 6273866 B2 JP6273866 B2 JP 6273866B2 JP 2014014203 A JP2014014203 A JP 2014014203A JP 2014014203 A JP2014014203 A JP 2014014203A JP 6273866 B2 JP6273866 B2 JP 6273866B2
Authority
JP
Japan
Prior art keywords
batch
information
processing
server
processing request
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
JP2014014203A
Other languages
English (en)
Other versions
JP2015141574A (ja
Inventor
有希 鳥居
有希 鳥居
孝昭 中澤
孝昭 中澤
松田　聡
聡 松田
伊智郎 小谷
伊智郎 小谷
宏樹 松枝
宏樹 松枝
立石　直樹
直樹 立石
洋子 米本
洋子 米本
冴子 中村
冴子 中村
暉 李
暉 李
川口　剛
剛 川口
康英 當房
康英 當房
健男 飯塚
健男 飯塚
由紀 野尻
由紀 野尻
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Fujitsu Ltd
Original Assignee
Fujitsu Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Fujitsu Ltd filed Critical Fujitsu Ltd
Priority to JP2014014203A priority Critical patent/JP6273866B2/ja
Priority to US14/600,618 priority patent/US10171620B2/en
Publication of JP2015141574A publication Critical patent/JP2015141574A/ja
Application granted granted Critical
Publication of JP6273866B2 publication Critical patent/JP6273866B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/60—Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
    • G06F9/5027—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals
    • G06F9/5044—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals considering hardware capabilities
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
    • G06F9/5027—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals
    • G06F9/505—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals considering the load
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Description

本発明は、制御プログラム、制御装置および制御方法に関する。
業務システムの処理性能を向上させる方法としては、サーバの台数を増やし各サーバに負荷を分散するスケールアウトや、サーバにリソース（ＣＰＵ（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)〜(c23)を収集する。
(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)の適用を解除するように制御を行なうことができる。これにより、バッチ業務時にサーバ／リソースの処理性能が最大限に使用されても、バッチ業務が完了するまで際限なくスケールアウト／スケールアップが繰り返されるのを確実に抑止することができる。
〔５〕その他
以上、本発明の好ましい実施形態について詳述したが、本発明は、係る特定の実施形態に限定されるものではなく、本発明の趣旨を逸脱しない範囲内において、種々の変形、変更して実施することができる。
〔６〕付記
以上の各実施形態を含む実施形態に関し、さらに以下の付記を開示する。
（付記１）
第１のコンピュータに対する第２のコンピュータによる処理要求の処理要求内容を取得し、
前記の第１および第２のコンピュータそれぞれの動作に関する第１および第２の動作情報を取得し、
前記第１のコンピュータに対する前記処理要求の処理要求内容に含まれる当該処理要求に対応した前記第１のコンピュータによる処理履歴と当該処理要求を行なった前記第２のコンピュータの当該処理要求に関連した前記第２の動作情報とを対応づけた処理実績情報と、前記処理要求内容と、前記の第１および第２の動作情報とに基づき、前記処理要求の処理要求種別を判別する、
処理をプロセッサに実行させる、制御プログラム。
（付記２）
前記処理要求種別の判別結果に基づき前記コンピュータに割り当てられるリソースの制御を行なう、
処理を前記プロセッサに実行させる、付記１記載の制御プログラム。
（付記３）
前記第１のコンピュータとしてデータベースサーバを含み、前記第２のコンピュータとしてウエブサーバ，アプリケーションサーバおよびバッチサーバを含む場合、
前記処理要求の処理要求内容に含まれる当該処理要求の発行元プロセス識別情報が、前記データベースサーバから取得された前記第１の動作情報に含まれるプロセス情報にあるか否かを判別し、
当該処理要求の発行元プロセス識別情報が前記プロセス情報にあれば、前記処理要求の処理要求種別は、前記バッチサーバによるローカルバッチ処理であると判別し、
前記処理要求の処理要求内容と前記第１の動作情報とに基づき、前記ローカルバッチ処理の処理要求を発行した前記バッチサーバの第１アドレス情報を取得し、
前記第１アドレス情報を保存部に保存する、
処理を前記プロセッサに実行させる、付記１または付記２記載の制御プログラム。
（付記４）
当該処理要求の発行元プロセス識別情報が前記プロセス情報になければ、前記処理要求の処理要求内容と前記第１の動作情報とに基づき、当該処理要求を発行したサーバの第２アドレス情報を取得し、
前記第２アドレス情報で指定されるサーバから、前回の処理要求による処理開始から処理終了までの第１リソース使用量と前記処理終了から当該処理要求による処理開始までの第２リソース使用量とを前記処理実績情報として取得し、
前記第１リソース使用量に対して前記第２リソース使用量が増加しているか否かを判別し、
前記第１リソース使用量に対して前記第２リソース使用量が増加していれば、前記処理要求の処理要求種別は、前記バッチサーバによるリモートバッチ処理であると判別し、
前記第２アドレス情報を、前記バッチサーバのアドレス情報として前記保存部に保存する、
処理を前記プロセッサに実行させる、付記３記載の制御プログラム。
（付記５）
前記第１リソース使用量に対して前記第２リソース使用量が増加していなければ、前記第２アドレス情報を前記アプリケーションサーバのアドレス情報として取得し、
前記処理要求の処理要求内容と前記アプリケーションサーバのアドレス情報と前記ウエブサーバから取得された前記第１の動作情報とに基づき、当該処理要求の発行元サーバの第３アドレス情報を検出し、
前記第３アドレス情報が前記保存部に保存されているか否かを判別し、
前記第３アドレス情報が前記保存部に保存されていれば、前記処理要求の処理要求種別は、前記バッチサーバによって前記ウエブサーバ経由で行なわれるウエブサービスバッチ処理であると判別する、
処理を前記プロセッサに実行させる、付記４記載の制御プログラム。
（付記６）
前記第３アドレス情報が前記保存部に保存されていなければ、前記処理要求の処理要求種別は、オンライン処理であると判別する、
処理を前記プロセッサに実行させる、付記４または付記５記載の制御プログラム。
（付記７）
第１のコンピュータに対する第２のコンピュータによる処理要求の処理要求内容を取得する第１取得部と、
前記の第１および第２のコンピュータそれぞれの動作に関する第１および第２の動作情報を取得する第２取得部と、
前記第１のコンピュータに対する前記処理要求の処理要求内容に含まれる当該処理要求に対応した前記第１のコンピュータによる処理履歴と当該処理要求を行なった前記第２のコンピュータの当該処理要求に関連した前記第２の動作情報とを対応づけた処理実績情報と、前記処理要求内容と、前記の第１および第２の動作情報とに基づき、前記処理要求の処理要求種別を判別する判別部と、を有する、制御装置。
（付記８）
前記処理要求種別の判別結果に基づき前記コンピュータに割り当てられるリソースの制御を行なうリソース制御部を、さらに有する、付記７記載の制御装置。
（付記９）
前記第１のコンピュータとしてデータベースサーバを含み、前記第２のコンピュータとしてウエブサーバ，アプリケーションサーバおよびバッチサーバを含む場合、
前記判別部は、
前記処理要求の処理要求内容に含まれる当該処理要求の発行元プロセス識別情報が、前記データベースサーバから取得された前記第１の動作情報に含まれるプロセス情報にあるか否かを判別し、
当該処理要求の発行元プロセス識別情報が前記プロセス情報にあれば、前記処理要求の処理要求種別は、前記バッチサーバによるローカルバッチ処理であると判別し、
前記処理要求の処理要求内容と前記第１の動作情報とに基づき、前記ローカルバッチ処理の処理要求を発行した前記バッチサーバの第１アドレス情報を取得し、
前記第１アドレス情報を保存部に保存する、付記７または付記８記載の制御装置。
（付記１０）
前記判別部は、
当該処理要求の発行元プロセス識別情報が前記プロセス情報になければ、前記処理要求の処理要求内容と前記第１の動作情報とに基づき、前記第２取得部によって当該処理要求を発行したサーバの第２アドレス情報を取得し、
前記第２アドレス情報で指定されるサーバから、前回の処理要求による処理開始から処理終了までの第１リソース使用量と前記処理終了から当該処理要求による処理開始までの第２リソース使用量とを前記処理実績情報として取得し、
前記第１リソース使用量に対して前記第２リソース使用量が増加しているか否かを判別し、
前記第１リソース使用量に対して前記第２リソース使用量が増加していれば、前記処理要求の処理要求種別は、前記バッチサーバによるリモートバッチ処理であると判別し、
前記第２アドレス情報を、前記バッチサーバのアドレス情報として前記保存部に保存する、付記９記載の制御装置。
（付記１１）
前記判別部は、
前記第１リソース使用量に対して前記第２リソース使用量が増加していなければ、前記第２アドレス情報を前記アプリケーションサーバのアドレス情報として取得し、
前記処理要求の処理要求内容と前記アプリケーションサーバのアドレス情報と前記ウエブサーバから取得された前記第１の動作情報とに基づき、当該処理要求の発行元サーバの第３アドレス情報を検出し、
前記第３アドレス情報が前記保存部に保存されているか否かを判別し、
前記第３アドレス情報が前記保存部に保存されていれば、前記処理要求の処理要求種別は、前記バッチサーバによって前記ウエブサーバ経由で行なわれるウエブサービスバッチ処理であると判別する、付記１０記載の制御装置。
（付記１２）
前記判別部は、
前記第３アドレス情報が前記保存部に保存されていなければ、前記処理要求の処理要求種別は、オンライン処理であると判別する、付記１０または付記１１記載の制御装置。
（付記１３）
プロセッサが、
第１のコンピュータに対する第２のコンピュータによる処理要求の処理要求内容を取得し、
前記の第１および第２のコンピュータそれぞれの動作に関する第１および第２の動作情報を取得し、
前記第１のコンピュータに対する前記処理要求の処理要求内容に含まれる当該処理要求に対応した前記第１のコンピュータによる処理履歴と当該処理要求を行なった前記第２のコンピュータの当該処理要求に関連した前記第２の動作情報とを対応づけた処理実績情報と、前記処理要求内容と、前記の第１および第２の動作情報とに基づき、前記処理要求の処理要求種別を判別する、制御方法。
（付記１４）
前記プロセッサが、
前記処理要求種別の判別結果に基づき前記コンピュータに割り当てられるリソースの制御を行なう、付記１３記載の制御方法。
（付記１５）
前記第１のコンピュータとしてデータベースサーバを含み、前記第２のコンピュータとしてウエブサーバ，アプリケーションサーバおよびバッチサーバを含む場合、
前記プロセッサが、
前記処理要求の処理要求内容に含まれる当該処理要求の発行元プロセス識別情報が、前記データベースサーバから取得された前記第１の動作情報に含まれるプロセス情報にあるか否かを判別し、
当該処理要求の発行元プロセス識別情報が前記プロセス情報にあれば、前記処理要求の処理要求種別は、前記バッチサーバによるローカルバッチ処理であると判別し、
前記処理要求の処理要求内容と前記第１の動作情報とに基づき、前記ローカルバッチ処理の処理要求を発行した前記バッチサーバの第１アドレス情報を取得し、
前記第１アドレス情報を保存部に保存する、付記１３または付記１４記載の制御方法。
（付記１６）
前記プロセッサが、
当該処理要求の発行元プロセス識別情報が前記プロセス情報になければ、前記処理要求の処理要求内容と前記第１の動作情報とに基づき、当該処理要求を発行したサーバの第２アドレス情報を取得し、
前記第２アドレス情報で指定されるサーバから、前回の処理要求による処理開始から処理終了までの第１リソース使用量と前記処理終了から当該処理要求による処理開始までの第２リソース使用量とを前記処理実績情報として取得し、
前記第１リソース使用量に対して前記第２リソース使用量が増加しているか否かを判別し、
前記第１リソース使用量に対して前記第２リソース使用量が増加していれば、前記処理要求の処理要求種別は、前記バッチサーバによるリモートバッチ処理であると判別し、
前記第２アドレス情報を、前記バッチサーバのアドレス情報として前記保存部に保存する、付記１５記載の制御方法。
（付記１７）
前記プロセッサが、
前記第１リソース使用量に対して前記第２リソース使用量が増加していなければ、前記第２アドレス情報を前記アプリケーションサーバのアドレス情報として取得し、
前記処理要求の処理要求内容と前記アプリケーションサーバのアドレス情報と前記ウエブサーバから取得された前記第１の動作情報とに基づき、当該処理要求の発行元サーバの第３アドレス情報を検出し、
前記第３アドレス情報が前記保存部に保存されているか否かを判別し、
前記第３アドレス情報が前記保存部に保存されていれば、前記処理要求の処理要求種別は、前記バッチサーバによって前記ウエブサーバ経由で行なわれるウエブサービスバッチ処理であると判別する、付記１６記載の制御方法。
（付記１８）
前記プロセッサが、
前記第３アドレス情報が前記保存部に保存されていなければ、前記処理要求の処理要求種別は、オンライン処理であると判別する、付記１６または付記１７に記載の制御方法。
１ 業務システム
１ａ Ｗｅｂサーバ（ウエブサーバ，第２のコンピュータ）
１ｂ ＡＰサーバ（アプリケーションサーバ，第２のコンピュータ）
１ｃ ＤＢサーバ（データベースサーバ，第１のコンピュータ）
１ｄ バッチサーバ（第２のコンピュータ）
２ クライアント端末（エンドユーザ）
３ ネットワーク
１０ａ，１０ｂ，１０ｃ，１０ｄ 管理エージェント
１１ａ Ｗｅｂ情報収集部（第２取得部）
１１ｂ ＡＰ情報収集部（第２取得部）
１１ｃ ＤＢ情報収集部（第１取得部，第２取得部）
１１ｄ バッチ情報収集部（第２取得部）
１００ 管理サーバ（制御装置）
１０１ 管理マネージャ
１１０ 処理部（ＣＰＵ，プロセッサ，第１取得部，第２取得部）
１１１ 判別部
１１１ａ ローカルバッチ業務判断部（判別部）
１１１ｂ リモートバッチ業務判断部（判別部）
１１１ｃ Ｗｅｂサービスバッチ業務／オンライン業務判断部（判別部）
１１２ リソース制御部
１２０ 記憶部（メモリ，保存部）
１２１ ＳＱＬ・業務種別履歴ＤＢ
１２２ バッチサーバ一覧情報ＤＢ

Claims (8)

  1. 第１のコンピュータに対する第２のコンピュータによる処理要求の処理要求内容を取得し、
    前記の第１および第２のコンピュータそれぞれの動作に関する第１および第２の動作情報を取得し、
    前記第１のコンピュータに対する前記処理要求の処理要求内容に含まれる当該処理要求に対応した前記第１のコンピュータによる処理履歴と当該処理要求を行なった前記第２のコンピュータの当該処理要求に関連した前記第２の動作情報とを対応づけた処理実績情報と、前記処理要求内容と、前記の第１および第２の動作情報とに基づき、前記処理要求の処理要求種別を判別し、
    前記第１のコンピュータはデータベースサーバを含み、前記第２のコンピュータは少なくともバッチサーバを含み、前記処理要求の処理要求内容に含まれる当該処理要求の発行元プロセス識別情報が、前記データベースサーバから取得された前記第１の動作情報に含まれるプロセス情報にあるか否かを判別し、
    当該処理要求の発行元プロセス識別情報が前記プロセス情報にあれば、前記処理要求の処理要求種別は、前記バッチサーバにより実行されるバッチ処理のうち、特定種別のバッチ処理であると判別し、
    前記処理要求の処理要求内容と前記第１の動作情報とに基づき、前記特定種別のバッチ処理の処理要求を発行した前記バッチサーバの第１アドレス情報を取得し、
    前記第１アドレス情報を保存部に保存する
    処理をプロセッサに実行させる、制御プログラム。
  2. 前記処理要求種別の判別結果に基づき前記第１のコンピュータ及び前記第２のコンピュータに割り当てられるリソースの制御を行なう、
    処理を前記プロセッサに実行させる、請求項１記載の制御プログラム。
  3. 当該処理要求の発行元プロセス識別情報が前記プロセス情報になければ、前記処理要求の処理要求内容と前記第１の動作情報とに基づき、当該処理要求を発行したサーバの第２アドレス情報を取得し、
    前記第２アドレス情報で指定されるサーバから、前回の処理要求による処理開始から処理終了までの第１リソース使用量と前記処理終了から当該処理要求による処理開始までの第２リソース使用量とを前記処理実績情報として取得し、
    前記第１リソース使用量に対して前記第２リソース使用量が増加しているか否かを判別し、
    前記第１リソース使用量に対して前記第２リソース使用量が増加していれば、前記処理要求の処理要求種別は、前記バッチサーバによるリモートバッチ処理であると判別し、
    前記第２アドレス情報を、前記バッチサーバのアドレス情報として前記保存部に保存する、
    処理を前記プロセッサに実行させる、請求項１または請求項２記載の制御プログラム。
  4. 前記第２のコンピュータはさらにウエブサーバおよびアプリケーションサーバを含み、
    前記第１リソース使用量に対して前記第２リソース使用量が増加していなければ、前記第２アドレス情報を前記アプリケーションサーバのアドレス情報として取得し、
    前記処理要求の処理要求内容と前記アプリケーションサーバのアドレス情報と前記ウエブサーバから取得された前記第１の動作情報とに基づき、当該処理要求の発行元サーバの第３アドレス情報を検出し、
    前記第３アドレス情報が前記保存部に保存されているか否かを判別し、
    前記第３アドレス情報が前記保存部に保存されていれば、前記処理要求の処理要求種別は、前記バッチサーバによって前記ウエブサーバ経由で行なわれるウエブサービスバッチ処理であると判別する、
    処理を前記プロセッサに実行させる、請求項３記載の制御プログラム。
  5. 前記第３アドレス情報が前記保存部に保存されていなければ、前記処理要求の処理要求種別は、オンライン処理であると判別する、
    処理を前記プロセッサに実行させる、請求項４記載の制御プログラム。
  6. 第１のコンピュータに対する第２のコンピュータによる処理要求の処理要求内容を取得する第１取得部と、
    前記の第１および第２のコンピュータそれぞれの動作に関する第１および第２の動作情報を取得する第２取得部と、
    前記第１のコンピュータに対する前記処理要求の処理要求内容に含まれる当該処理要求に対応した前記第１のコンピュータによる処理履歴と当該処理要求を行なった前記第２のコンピュータの当該処理要求に関連した前記第２の動作情報とを対応づけた処理実績情報と、前記処理要求内容と、前記の第１および第２の動作情報とに基づき、前記処理要求の処理要求種別を判別する判別部と、を有し、
    前記第１のコンピュータはデータベースサーバを含み、前記第２のコンピュータは少なくともバッチサーバを含み、前記判別部は、前記処理要求の処理要求内容に含まれる当該処理要求の発行元プロセス識別情報が、前記データベースサーバから取得された前記第１の動作情報に含まれるプロセス情報にあるか否かを判別し、当該処理要求の発行元プロセス識別情報が前記プロセス情報にあれば、前記処理要求の処理要求種別は、前記バッチサーバにより実行されるバッチ処理のうち、特定種別のバッチ処理であると判別し、前記処理要求の処理要求内容と前記第１の動作情報とに基づき、前記特定種別のバッチ処理の処理要求を発行した前記バッチサーバの第１アドレス情報を取得し、前記第１アドレス情報を保存部に保存する、制御装置。
  7. プロセッサが、
    第１のコンピュータに対する第２のコンピュータによる処理要求の処理要求内容を取得し、
    前記の第１および第２のコンピュータそれぞれの動作に関する第１および第２の動作情報を取得し、
    前記第１のコンピュータに対する前記処理要求の処理要求内容に含まれる当該処理要求に対応した前記第１のコンピュータによる処理履歴と当該処理要求を行なった前記第２のコンピュータの当該処理要求に関連した前記第２の動作情報とを対応づけた処理実績情報と、前記処理要求内容と、前記の第１および第２の動作情報とに基づき、前記処理要求の処理要求種別を判別し、
    前記第１のコンピュータはデータベースサーバを含み、前記第２のコンピュータは少なくともバッチサーバを含み、前記処理要求の処理要求内容に含まれる当該処理要求の発行元プロセス識別情報が、前記データベースサーバから取得された前記第１の動作情報に含まれるプロセス情報にあるか否かを判別し、
    当該処理要求の発行元プロセス識別情報が前記プロセス情報にあれば、前記処理要求の処理要求種別は、前記バッチサーバにより実行されるバッチ処理のうち、特定種別のバッチ処理であると判別し、
    前記処理要求の処理要求内容と前記第１の動作情報とに基づき、前記特定種別のバッチ処理の処理要求を発行した前記バッチサーバの第１アドレス情報を取得し、
    前記第１アドレス情報を保存部に保存する、制御方法。
  8. 前記特定種別のバッチ処理はローカルバッチ処理である、請求項１記載の制御プログラム。
JP2014014203A 2014-01-29 2014-01-29 制御プログラム、制御装置および制御方法 Active JP6273866B2 (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
JP2014014203A JP6273866B2 (ja) 2014-01-29 2014-01-29 制御プログラム、制御装置および制御方法
US14/600,618 US10171620B2 (en) 2014-01-29 2015-01-20 Non-transitory computer-readable recording medium having stored therein control program, control apparatus and control method

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2014014203A JP6273866B2 (ja) 2014-01-29 2014-01-29 制御プログラム、制御装置および制御方法

Publications (2)

Publication Number Publication Date
JP2015141574A JP2015141574A (ja) 2015-08-03
JP6273866B2 true JP6273866B2 (ja) 2018-02-07

Family

ID=53680256

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2014014203A Active JP6273866B2 (ja) 2014-01-29 2014-01-29 制御プログラム、制御装置および制御方法

Country Status (2)

Country Link
US (1) US10171620B2 (ja)
JP (1) JP6273866B2 (ja)

Families Citing this family (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8560604B2 (en) 2009-10-08 2013-10-15 Hola Networks Ltd. System and method for providing faster and more efficient data communication
US9241044B2 (en) 2013-08-28 2016-01-19 Hola Networks, Ltd. System and method for improving internet communication by using intermediate nodes
CN103795804A (zh) * 2014-02-24 2014-05-14 华为技术有限公司 存储资源调度方法及存储计算系统
US9672064B2 (en) * 2015-07-13 2017-06-06 Palo Alto Research Center Incorporated Dynamically adaptive, resource aware system and method for scheduling
US10476742B1 (en) * 2015-09-24 2019-11-12 Amazon Technologies, Inc. Classification of auto scaling events impacting computing resources
US10574723B2 (en) * 2016-11-30 2020-02-25 Nutanix, Inc. Web services communication management
JP6903926B2 (ja) 2017-02-08 2021-07-14 富士通株式会社 情報処理装置、情報処理プログラム、情報処理方法及び情報処理システム
EP4311204A3 (en) * 2017-08-28 2024-04-10 Bright Data Ltd. Method for improving content fetching by selecting tunnel devices
US11070489B2 (en) * 2017-11-02 2021-07-20 International Business Machines Corporation Resource consumption control
EP4030318A1 (en) 2019-04-02 2022-07-20 Bright Data Ltd. System and method for managing non-direct url fetching service
CN111049894B (zh) * 2019-12-07 2023-08-29 深圳市万佳安物联科技股份有限公司 云端物联网数据处理方法、装置以及电子设备

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH0778118A (ja) * 1993-06-18 1995-03-20 Hitachi Ltd 資源競合回避スケジューリング方法
JPH11288382A (ja) 1998-04-03 1999-10-19 Nec Software Ltd システム資源使用情報収集装置、システム資源使用情報収集方法、およびプログラムを記録する記録媒体
JP2004302751A (ja) 2003-03-31 2004-10-28 Hitachi Ltd 計算機システムの性能管理方法、および、記憶装置の性能を管理する計算機システム
JP4610240B2 (ja) * 2004-06-24 2011-01-12 富士通株式会社 分析プログラム、分析方法及び分析装置
WO2006043309A1 (ja) * 2004-10-18 2006-04-27 Fujitsu Limited 運用管理プログラム、運用管理方法および運用管理装置
JP5298717B2 (ja) * 2008-09-11 2013-09-25 富士通株式会社 特徴抽出方法及び装置
JP5471400B2 (ja) * 2009-12-17 2014-04-16 富士通株式会社 ジョブ分析プログラム及び方法、並びにジョブ分析装置
JP5561182B2 (ja) * 2011-01-20 2014-07-30 富士通株式会社 システム分析支援プログラム、システム分析支援装置、およびシステム分析支援方法
US9251032B2 (en) * 2011-11-03 2016-02-02 Fujitsu Limited Method, computer program, and information processing apparatus for analyzing performance of computer system

Also Published As

Publication number Publication date
JP2015141574A (ja) 2015-08-03
US20150215426A1 (en) 2015-07-30
US10171620B2 (en) 2019-01-01

Similar Documents

Publication Publication Date Title
JP6273866B2 (ja) 制御プログラム、制御装置および制御方法
US8099379B2 (en) Performance evaluating apparatus, performance evaluating method, and program
TWI685226B (zh) 分散式環境下的服務定址方法及裝置
US10318391B2 (en) Non-blocking listener registration in the presence of data grid nodes joining the cluster
WO2018014811A1 (zh) 风险识别方法、客户端设备及风险识别系统
EP2327024B1 (en) Techniques for resource location and migration across data centers
JP6160064B2 (ja) 適用判定プログラム、障害検出装置および適用判定方法
US20070168201A1 (en) Formula for automatic prioritization of the business impact based on a failure on a service in a loosely coupled application
CN111443867B (zh) 一种数据存储方法、装置、设备及存储介质
JP5269394B2 (ja) データベース振分装置、データベース振分方法、プログラム、および記録媒体
JP6252309B2 (ja) 監視漏れ特定処理プログラム，監視漏れ特定処理方法及び監視漏れ特定処理装置
CN107291601B (zh) 一种安全运维方法及系统
JP6225606B2 (ja) データベース監視装置、データベース監視方法、並びにコンピュータ・プログラム
US9560027B1 (en) User authentication
CN109976944B (zh) 数据处理方法和系统，存储介质和电子设备
JP2018025944A (ja) リソース制御ブログラム、リソース制御方法及びリソース制御装置
JP2023530996A (ja) クラスタの容量縮小・拡張方法及びシステム、容量縮小・拡張制御端末、及び媒体
US11061937B2 (en) Method and system for classifying user identifiers into similar segments
JP2009230275A (ja) 株式銘柄通知装置、株式銘柄通知方法、および株式銘柄抽出方法
US9830339B2 (en) Data processing system for processing interactions
KR100479360B1 (ko) 명령어의 유효성 판단 방법 및 그 시스템
CN109739883A (zh) 提升数据查询性能的方法、装置和电子设备
CN113791935B (zh) 一种数据备份方法、网络节点及系统
JP5607205B2 (ja) 情報提供装置、情報提供方法および情報提供システム
US20240064032A1 (en) Systems and methods for managing metrics in blockchain networks

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20161004

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20170726

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20170808

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20171010

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20171212

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20171225

R150 Certificate of patent or registration of utility model

Ref document number: 6273866

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150