JP2007148469A - ビジネスプロセス定義を用いた事前リソース割り当て方法 - Google Patents

ビジネスプロセス定義を用いた事前リソース割り当て方法 Download PDF

Info

Publication number
JP2007148469A
JP2007148469A JP2005337997A JP2005337997A JP2007148469A JP 2007148469 A JP2007148469 A JP 2007148469A JP 2005337997 A JP2005337997 A JP 2005337997A JP 2005337997 A JP2005337997 A JP 2005337997A JP 2007148469 A JP2007148469 A JP 2007148469A
Authority
JP
Japan
Prior art keywords
business process
service
computer
executed
added
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.)
Pending
Application number
JP2005337997A
Other languages
English (en)
Inventor
Katsutoshi Asaki
克利 朝木
Nobuyuki Yamamoto
展之 山本
Mitsunobu Tasaka
光伸 田坂
Jun Yoshida
順 吉田
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.)
Hitachi Ltd
Original Assignee
Hitachi 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 Hitachi Ltd filed Critical Hitachi Ltd
Priority to JP2005337997A priority Critical patent/JP2007148469A/ja
Priority to US11/600,090 priority patent/US8386636B2/en
Publication of JP2007148469A publication Critical patent/JP2007148469A/ja
Pending legal-status Critical Current

Links

Images

Classifications

    • 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
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2209/00—Indexing scheme relating to G06F9/00
    • G06F2209/50—Indexing scheme relating to G06F9/50
    • G06F2209/5015—Service provider selection
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2209/00—Indexing scheme relating to G06F9/00
    • G06F2209/50—Indexing scheme relating to G06F9/50
    • G06F2209/5019—Workload prediction

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

【課題】
ビジネスプロセスのシステムへの配布時に、将来の計算機リソース使用量を適切に予測する。また、さらに、予測した計算機リソース使用量からリソースが不足する計算機を見つけ出し、計算機リソースを追加するといった運用を行う。
【解決手段】
本発明は上記の課題を解決するために、ビジネスプロセス定義から抽出するサービスの呼出関係を用いた、計算機リソース使用量の予測方法を備えることとした。
また、本発明は、計算機リソース使用量予測ステップを用いて、新たなビジネスプロセスをシステムに配布するより前に、計算機リソース予測使用量を計算し、計算機リソース予測使用量が所定の値を超えるサービス実行計算機に対して、該サービス実行計算機とは異なる計算機を新たにサービス実行計算機として割り当てることを特徴とするリソース割り当て方法を備えることとした。
【選択図】 図１

Description

本発明は、将来の計算機リソース使用量を予測して、事前に計算機リソースを適切に割り当てる方法に係わり、特に、将来の計算機リソース使用量の予測方法に関する。
個々のサービスに関し過去の稼働履歴を用いて計算機リソース使用量を予測し、その予測値に基づいて計算機リソースを確保する従来技術として特許文献１がある。この公知例では、過去の負荷の周期性から将来のリソース使用量の予測を行い、その予測値があらかじめ設定しておいた条件を満たした場合に、事前に計算機リソースの確保を行う方法を開示している。
特開２００５−１４１６０５号公報
ビジネスプロセス統合の考えに基づきサービスを階層化し、分散ネットワーク環境においてそれらを組み合わせることによって、システムの保守性の向上やビジネスの変化に対する柔軟性が得られる反面、システム構成を変更した場合の計算機リソースの配分といった運用の複雑さが増加することが懸念される。
例えば、システムに新たにビジネスプロセス定義を配布して、新たなビジネスプロセスを配布する場合、そのビジネスプロセスから利用される既存のサービスは呼び出される機会が増えるため、当然そのサービスが配布されている計算機のCPU使用率は増加する。さらにサービスの呼び出しは階層化されているため、そのサービスからまた別のサービスが呼び出され、同様にして、呼び出されるサービスが配布されている計算機のCPU使用率は増加する。
このように、粗い粒度のサービスから細かい粒度のサービスまで連鎖的に、呼び出し回数が増えるため、ビジネスプロセスの配布によって、どの計算機のリソースが不足するのかを把握するのはシステム管理者では困難になる。さらに、呼び出し回数の増えるサービスが稼動している計算機のCPUリソースが不足し、それに伴いサービスのレスポンスタイムが増加すると、そのサービスを使用する既存のビジネスプロセスのレスポンスタイムも増加し、最終的に、呼び出し階層の一番高いビジネスプロセスのレスポンスタイムも増加してしまう。
近年では、ITコストの適正化を目的として、サービスの提供者とサービス利用者の間で最低限のサービス提供水準についての合意（SLA：Service Level Agreement）が実施されるようになってきているため、そのような場合には、SLAで定めたサービス提供水準を維持する必要があり、上記のようなビジネスプロセスの追加といったイベントに対して、事前にリソースが不足する計算機を予測し、その予測に基づいて計算機リソースを追加する必要がある。なお、サービス提供水準には様々な種類があるが、レスポンスタイムやスループット、稼働率などがよく使用される。
上記の従来技術によれば、定常時の周期的な負荷の増減に対しては、その周期性を利用し、事前に負荷を予測することができ、その予測負荷から将来の計算機リソース使用量を予測して、その予測に基づいた計算機リソースの割当を行うことができる。
しかし、ビジネスプロセスの配布や削除という非定常的なイベントによるサービスの負荷の増加に対しては周期性がないため、適切なリソース使用量の予測を行うことができない。そのため、従来技術では、新たなビジネスプロセスの配布が行われた場合、そのビジネスプロセスの配布後に、実際の計算機リソース使用量が増加し、あらかじめ設定していた閾値に達してから計算機リソースの割当を行うため、閾値を超えたことを検知してから実際に計算機リソースの割当が行われるまでの間は、そのサービスの性能が悪化し、結果としてそのサービスを利用している他のビジネスプロセスの性能に影響が及んでしまう。その結果、影響が及んだビジネスプロセスのサービスレベルを遵守できない可能性がある。
本発明では、ビジネスプロセスのシステムへの配布時においても、将来の計算機リソース使用量を適切に予測するという課題を解決することを目的とする。また、さらに、予測した計算機リソース使用量からリソースが不足する計算機を見つけ出し、計算機リソースを追加するといった運用を行うことを目的とする。
本発明は上記の課題を解決するために、ビジネスプロセス定義から抽出するサービスの呼出関係を用いた、計算機リソース使用量の予測方法を備えることとした。
具体的には、システムを構成するビジネスプロセスがどのサービスを呼び出すのかを示すサービス呼出関係とその呼出割合を格納したサービス管理テーブルを有し、システムを構成するサービスおよびビジネスプロセス毎に、リクエスト１件あたりの計算機リソース使用量を格納したサービス管理テーブルを有する。
そして、システムに新たなビジネスプロセスを配布する際に、少なくとも新たなビジネスプロセスの想定使用頻度をシステム管理者の入力により求め、新たなビジネスプロセスが呼び出すサービスとその呼出割合をビジネスプロセス定義およびサービス呼出関係テーブルから抽出し、抽出したサービスそれぞれについて、リクエスト１件あたりの計算機リソース使用量をサービス管理テーブルから抽出する。
さらに、システム管理者の入力により求めた新たなビジネスプロセスの想定使用頻度と、新たなビジネスプロセスが呼び出すサービスとその呼出割合と、サービスを実行するサービス実行計算機の実稼動情報として把握可能な計算機リソース使用量と、サービス管理テーブルから求まるサービスのリクエスト１件あたりの計算機リソース使用量から、新たなビジネスプロセスを配布した場合のサービス実行計算機毎の計算機リソース使用量である計算機リソース予測使用量を計算する計算機リソース使用量予測ステップを備えることとした。
また、本発明は、計算機リソース使用量予測ステップを用いて、新たなビジネスプロセスをシステムに配布するより前に、計算機リソース予測使用量を計算し、計算機リソース予測使用量が所定の値を超えるサービス実行計算機に対して、該サービス実行計算機とは異なる計算機を新たにサービス実行計算機として割り当てることを特徴とするリソース割り当て方法を備えることとした。
本発明によれば、ビジネスプロセス定義から抽出できるサービスの呼出関係を用いた、計算機リソース使用量の予測方法を備えることにより、新たなビジネスプロセスを配布した場合のシステムを構成する各計算機の計算機リソース使用量を事前に予測することができ、さらに、その予測値が所定の値以上になった計算機に対して、空き計算機リソースを追加することが可能となる。
その結果、ビジネスプロセスの配布という非定常なイベントに対しても、事前に不足する計算機リソースを確保でき、システムの安定運用を行うことができる。
近年、ビジネスが目まぐるしく変化する中で、ビジネスの変化に応じて短期間で柔軟に作り直しや統合のできるシステムが求められている。また、同時に、IT投資やITコストを削減するために、既存のソフトウェア資産をできるだけ有効活用することも求められている。
そういったニーズを踏まえて、BPEL（Business Process Execution Language）などのビジネスプロセス定義言語によって複数のソフトウェア資産を組み合わせ、新たな機能を提供するというビジネスプロセス統合と呼ばれる考え方が注目されている。
この考え方に基づき、できるだけ既存のソフトウェア資産を再利用し、必要に応じて新規にソフトウェア資産を作成し、それらソフトウェア資産を組み合わせることによって、短期間、そして低コストで新たな機能を提供するシステムを構築することが可能となる。
ここでは、ソフトウェア資産をサービスと呼び、サービスの組み合わせのフローを定義したものをビジネスプロセス定義と呼ぶ。通常、ビジネスプロセス定義又はその定義から派生したプログラムはビジネスプロセス実行基盤プログラムに配布されると、クライアントから呼び出し可能なサービスとなる。呼び出し可能となった状態で、ビジネスプロセス実行基盤プログラムがクライアントからのリクエストを受け付けると、リクエストに対応するビジネスプロセス定義又はその定義から派生したプログラムを特定し、そのビジネスプロセス定義に記述されたサービスの組み合わせのフローに従って、次々とサービスの呼び出しを実行する。ビジネスプロセス定義をビジネスプロセス実行基盤プログラムに配布することによってクライアントから利用可能となるサービスのことを特にビジネスプロセスと呼ぶ。
ビジネスプロセス定義の記述方法の例としては先に挙げたBPELがある。ビジネスプロセスやサービスの実装の例としては、Enterprise JavaBeans（登録商標）やWeb Servicesなどがある。また、ビジネスプロセスやサービスの実行基盤プログラムの例としては、J2EE Serversなどがあり、これを以降ではサービス実行基盤プログラムと呼ぶ。
ビジネスプロセスもサービスであるため、ビジネスプロセスを組み合わせて、さらに新たなビジネスプロセスを構築することも可能である。
上記ビジネスプロセス統合の有効な適用先として考えられているのが、企業情報システムの全体最適化である。既存の典型的な企業情報システムは、企業の部門毎に部分最適化されたシステムが存在しており、部門毎に同様な処理を行うシステムを有していることが多く、そのような重複機能を有することは保守性に問題がある。また、ビジネスの変化に伴い、いざそれらのシステムを連携しようとしたときに、同じ意味のデータであってもデータのフォーマットが異なるなど、そのままでは繋がらないといった問題もある。
そこで、企業情報システム全体を分析し、共通な処理やデータを抽出した上でそれらをサービスとして実装し、さらにビジネスプロセス統合の考え方を導入してサービスを組み合わせ、システムを再構築することで、全体の無駄を省き、また、ビジネスの変化に対して柔軟に対応できるようなシステムを作り上げるというソリューションが主流になりつつある。
この場合のサービスには、データベースアクセスサービスといった業務的には意味のない、プログラムコンポーネントとほぼ同意の細かい粒度のサービスから、インターネットバンキングにおける振込みサービスといった業務的に意味のある粗い粒度のサービスまで、様々な粒度のサービスが存在し、粗い粒度のサービスはビジネスプロセスによってより細かい粒度のサービスを組み合わせて構築する。また、一般的にはシステムを構成する多数のサービスは複数の計算機上に分散して配置し、それらの間の呼び出しには、SOAP(Simple Object Access Protocol) over HTTP(Hyper Text Transfer Protocol)などの標準的なプロトコルを用いることによって、サービス間の連携を行う。
例えば、商品を販売するシステムを考えた場合、顧客の注文を受けて、受注システムで処理し、物流システムで納品され、請求システムで代金が回収される。このような注文システム、受注システム、物流システム、請求システムをそれぞれ独立したサービスとして再構築し、これらのサービスを統合した商品販売システムをビジネスプロセスとしてWeb サービスやXML などの標準技術を利用して実現する。こうすることで、例えば販売量が爆発的に増加した場合でも、請求処理をクレジット会社の決済代行システムに移管する、他社と共同の物流センターを設立し、物流システムを統合するなど、各サービスを別のサービスに入れ替えたり、新たなビジネスプロセスを構築したりすることが容易に実現できるようになる。
複数のサービスからなる商品販売システムをビジネスプロセスとして構築している場合に、新たに別の商品販売システムを構築するとすると、すなわち新たな商品販売システムのビジネスプロセスをシステムに追加するとすると、この新たなビジネスプロセスでも、従来から稼働しているビジネスプロセスが使用する受注システムや請求システムなどのサービスを使用することが可能である。
このような場合に、新たなビジネスプロセスが追加されると、受注システムや請求システムの負荷が増大し、従来から稼働しているビジネスプロセスに影響を及ぼすおそれがある。そこで、本実施例では、新たに追加されるビジネスプロセスが使用する各サービスの呼出関係や負荷を考慮することで、従来から稼働しているビジネスプロセスが処理不能におちいることを防止する。
以下に、本発明の実施例を図面を用いて詳細に説明する。まず、第一の実施例について説明する。
図１８は本実施例における、計算機の構成と計算機へのサービスおよびビジネスプロセスの配布状況の一例を示している。この図は、サービスとビジネスプロセスの呼出関係および計算機への配布状況を説明するものであるため、計算機内部の詳細は後述する。
本実施例では、サービスやビジネスプロセスを実行するためのサービス実行計算機201, 202, 203, 204, 205, 206と、これらのサービス実行計算機から成るシステムを運用管理するためのサービス運用管理計算機100がネットワーク1000を介して接続されている。ネットワーク1000はLANなどのローカルネットワークであっても、WANやインターネットなどのグローバルネットワークであってもよい。
図１８では、サービス実行計算機201“ホストA”上のサービス実行基盤プログラム400にはビジネスプロセスA 500が、サービス実行計算機202“ホストB”上のサービス実行基盤プログラム400にはビジネスプロセスB 520とビジネスプロセスC 540が、サービス実行計算機203“ホストC”上のサービス実行基盤プログラム400にはサービスA 590が, サービス実行計算機204“ホストD”上のサービス実行基盤プログラム400にはサービスB 591とサービスC 592が, サービス実行計算機205“ホストE”上のサービス実行基盤プログラム400にはサービスD 593が配布されていることを示している。
一方、サービス実行計算機206“ホストF”上のサービス実行基盤プログラム400には何もサービス又はビジネスプロセスが配布されていないことを示している。計算機とそこに配布されているサービスとの対応関係は、後述する計算機管理テーブル312に格納される。
本実施例では、以上で説明した構成のシステムに対して、システム管理者900が新たにビジネスプロセス定義D 570をホストAに配布する操作を実行する場合を例にとって本発明の実施手順を説明する。
また、図１８では、ビジネスプロセスからサービス、サービスからサービスへの呼出関係を矢印で示している。呼出関係の矢印が実線の場合には、必ず呼び出しが行われることを示し、破線の場合には、入力データやサービスの状態がある条件を満たした場合にのみ、条件的に呼び出しが行われることを示している。図８に示すビジネスプロセス定義Dを分析した結果のフローチャートを例にすると、ビジネスプロセスDはまず、ビジネスプロセスBを無条件に必ず呼び出す。よって、この場合には、ビジネスプロセスDからビジネスプロセスBへの呼出関係の矢印は実線で示す。次に、ビジネスプロセスDはビジネスプロセスBを呼び出した後、ある条件判定を行い、ある条件を満たしていた場合にはサービスDを呼び出し、条件を満たさない場合には、そのまま終了する。この場合、ビジネスプロセスDはサービスDを条件的に呼び出すため、ビジネスプロセスDからサービスDへの呼出関係の矢印は破線で示す。
同様に、ビジネスプロセスA 500はビジネスプロセスB 520を必ず呼び出し、ビジネスプロセスC 540を条件的に呼び出す。また、ビジネスプロセスA 500に呼び出さるビジネスプロセスB 520は必ずサービスA 590を呼び出し、条件的にサービスB 591を呼び出す。
ビジネスプロセスD 560配布後は、ビジネスプロセスB 520とサービスD 593の呼び出し回数が増える。また、さらに、ビジネスプロセスBから呼び出されるサービスA 590 とサービスB 591も呼び出し回数が増える。特にサービスA 590はビジネスプロセスB 520から必ず呼び出され、且つ、ビジネスプロセスB 520 もビジネスプロセスD 560から必ず呼び出されるため、ビジネスプロセスD 560の配布に伴う呼出回数の増加は顕著である。
仮にサービスAがCPUリソースを多量に必要とする処理を行っているとすると、ビジネスプロセスD 560の配布により、サービスAの計算機のCPUリソースが不足する可能性がある。これは、新たに追加するビジネスプロセスDの定義からだけでは、ビジネスプロセスBとサービスDを呼び出すことしかわからないため、別途システム管理者等が呼出関係の階層を把握する必要がある。しかし、ビジネスプロセスDからサービスAまでの呼び出し階層が深い場合には、システム管理者といえども容易に、サービスAの計算機のCPUリソースが不足することはわかりえない。
本実施例では、ビジネスプロセス定義から抽出するシステム全体のビジネスプロセスとサービスの呼出関係と呼出割合を管理し、且つ、その呼出関係を辿り、新たなビジネスプロセスを配布した場合の各計算機のリソース使用量を予測することによって、この問題を解決する。また、さらに、予測した計算機リソース使用量を元に、新たに計算機リソースを追加する方法について述べる。
以降で、本実施例の詳細について述べる。
図１は本実施例の詳細なシステム構成例を示している。
ここで、サービス実行計算機201, 202, 203, 204, 205, 206をパーソナルコンピュータ（以下、パソコンと呼ぶ）などの汎用の計算機と、その上で実行される、ビジネスプロセスやサービスを実行するためのサーバプログラムであるサービス実行基盤プログラム400と、サービス運用管理計算機100上のサービス運用管理プログラム300とやりとりを行う運用管理エージェント210によって構成している。
運用管理エージェント210は、サービス運用管理計算機100上のサービス運用管理プログラム300からのサービス配布要求やビジネスプロセス定義の配布要求を受けて、サービス実行基盤プログラムへのサービスやビジネスプロセス定義の配布を行う。また、さらに、運用管理エージェント210は、サービス実行基盤プログラム400やそこに配布されているサービスやビジネスプロセス毎の性能情報や実行時情報、さらには自身が動作している計算機のリソース使用状況を取得し、それらの情報をサービス運用管理プログラム300に定期的に送信する。
本実施例では、計算機リソースの中でも、特にCPUリソースを取り扱うため、運用管理エージェント210は、計算機のリソース使用状況として平均CPU使用率を、そして、サービスやビジネスプロセス毎の性能情報として１件当たりのCPU使用率を取得し、サービス運用管理プログラム300に送信することとする。また、扱う計算機リソースに関係なく取得する情報として、ビジネスプロセス毎の実行時情報である、各ビジネスプロセスが呼ばれた回数と、そのビジネスプロセスがサービスを呼び出した回数のセットをサービス毎に取得し、サービス運用管理プログラム300に送信することとする。
これらの運用管理エージェント210からサービス運用管理プログラム300に送信される情報は本実施例の実施時に使用する情報であり、これらの実稼動情報を元に、将来の計算機リソース使用量が計算される。取り扱う計算機リソースとしては、上記CPU以外にも、メモリやディスクなど一般的にその使用量や使用率を取得可能なリソースであれば何であってもよい。
サービス実行基盤プログラム400は、J2EEサーバなどの市販のアプリケーションサーバで実現可能であり、サービスやビジネスプロセスはEnterprise JavaBeansやWeb Servicesで実現可能である。この場合、ビジネスプロセスの実装であるEnterprise JavaBeansやWeb Servicesは、ビジネスプロセス定義を参照しながら、定義に記述されたフローに従って次々とサービスを呼び出す処理を行う。サービス実行基盤プログラム400およびサービスやビジネスプロセスの実現方法は本実施例とは関係ないため説明を省略する。
また、本実施例では、サービス運用管理計算機100を、パソコンなどの汎用の計算機と、その上で実行される本実施例によるサービス運用管理プログラム300によって構成している。システム管理者900は、システム内のあるサービス実行計算機上のサービス実行基盤プログラム400にサービス又はビジネスプロセス定義を配布する場合、サービス運用管理プログラム300に対して配布操作を行う。具体的には、サービス又はビジネスプロセス定義とそれを配布するサービス実行基盤プログラム400を識別する情報を入力する。本実施例では、サービス実行計算機上に１つのサービス実行基盤プログラム400しか起動しないため、サービス実行基盤プログラム400を識別する情報として、サービス実行計算機を識別する名前（計算機名）を用いる。
配布操作が実行されると、サービス運用管理プログラム300は入力された計算機名に基づき、そのサービス実行計算機上の運用管理エージェント210にサービスの配布要求、又は、ビジネスプロセス定義の配布要求を送信する。その結果、運用管理エージェント210により目的のサービス実行計算機上のサービス実行基盤プログラム400へのサービス又はビジネスプロセス定義の配布が行われる。システム管理者900がサービス運用管理プログラム300にビジネスプロセス定義の配布操作を行ってから、実際にサービス実行基盤プログラム400にビジネスプロセス配布されるまでの間に本実施例による計算機リソース使用量の予測値計算が実施され、その予測値を元に不足する計算機リソースの確保を行う。
本実施例の実施形態をさらに説明するために、サービス運用管理計算機100の詳細な構成を図２に示し、説明する。図２において、サービス運用管理計算機100はCPU101とネットワークインタフェース回路102、二次記憶装置制御回路103、主記憶装置104、二次記憶装置105から構成される。ネットワークインタフェース回路102はCPU101の指示に従い、ネットワーク上のメッセージを送受信する。二次記憶装置制御回路103は、CPU101からの指示に従い、二次記憶装置105上にデータを入出力する。また、主記憶装置104上には、サービス運用管理プログラム300と、OS（Operating System）106が格納される。主記憶装置はメモリ等であり、二次記憶装置はハードディスク等の磁気記憶装置や、CD、DVDドライブ等の光及び磁気記憶装置などであるがこれらに限られるものではない。
上記のサービス運用管理計算機100の主記憶装置104内の構成において、OS106としては、市販の汎用OSを使用することが可能である。一方、サービス運用管理プログラム300は、本実施例を実施するプログラムであるため、以下で詳細に説明する。
サービス運用管理プログラム300は、エージェント管理部301、ポリシーベース運用部302、配布操作実行部303、プロビジョニング部304から成る。これらの各処理部は、サービス運用管理プログラムがCPU101で実行されることにより実現される。呼出関係テーブル310、サービス管理テーブル311、計算機管理テーブル312、運用ポリシーテーブル313は主記憶装置に格納されており、サービス運用管理プログラム300によって管理されている。
サービス実行計算機201,202,203,204,205,206のハードウェア構成は、図２に示すサービス運用管理計算機100のハードウェア構成と同様である。サービス運用管理計算機100との違いは、主記憶装置104に展開され、CPUにより実行されるプログラムである。サービス実行計算機201,202,203,204,205,206では、OS 106とサービス実行基盤プログラム400および、サービス実行基盤プログラム400に配布・管理・実行されるサービスやビジネスプロセス、そして、運用管理エージェント210が主記憶装置104に展開され、CPUにより実行される。運用管理エージェント210は計算機のCPU101の使用率（CPU使用率）や主記憶装置104の使用量（メモリ使用量）、二次記憶装置105の使用量（ハードディスク使用量）等の計算機リソースの使用量又は使用率を取得し、サービス運用管理計算機100に送信する。
なお、運用管理エージェントはプログラムでありCPUで実行されるが、これに限られず、リソース使用量を取得することができればハードウェア（集積回路チップ等）で実装してもよい。
以降では、本実施例の実施の手順を説明しつつ、上記のサービス運用管理プログラム300の各構成要素の役割について説明を行う。本実施例の実施の手順は、実施の準備段階としてのシステム構築フェーズと本実施例の実施段階であるサービスおよびビジネスプロセス定義追加フェーズの２つのフェーズから成る。
まず、システム構築フェーズでは最初に、システム管理者900はシステムを構成する１台以上のサービス実行計算機と１台のサービス運用管理計算機を用意する。本実施例では図１に示すとおり、６台のサービス実行計算機201, 202, 203, 204, 205, 206と１台のサービス運用管理計算機100を用意する。そして、サービス運用管理計算機100には、OS107とサービス運用管理プログラム300をインストールし、サービス実行計算機201, 202, 203, 204, 205, 206にはOS106およびサービス実行基盤プログラム400と運用管理エージェント210をインストールする。
次に、システム管理者900は、サービス運用管理計算機100上のサービス運用管理プログラム300に対して、システムの構成定義を行う。具体的には、システムを構成するサービス実行計算機201, 202, 203, 204, 205, 206について、計算機名と、そのサービス実行計算機上の運用管理エージェント210と通信を行うためのアドレスをサービス運用管理プログラム300に入力する。これらの情報の入力方法は、サービス運用管理プログラム300に入力用のGUIを設けて行ってもよいし、ファイルに記述させて、それをサービス運用管理プログラム300が読み込んでもよい。
システム管理者900によって、上記の入力がなされると、サービス運用管理プログラム300は図３に示す計算機管理テーブル312の計算機名335に、システム管理者900が入力した計算機名を、エージェントアドレス336に、システム管理者900が入力した運用管理エージェントと通信を行うためのアドレスを登録する。
本実施例では、６台のサービス実行計算機201, 202, 203, 204, 205, 206 の計算機名をそれぞれ ホストA、ホストB、ホストC、ホストD、ホストE、ホストFとした。また、計算機管理テーブル312のその他のカラムについてもここで説明する。
稼動サービス337は各計算機上で稼動しているサービス名又はビジネスプロセス名を格納する。サービス又はビジネスプロセスがサービス実行計算機に配布又は削除される度に、このカラムに追加・削除される。平均CPU使用率338は、各計算機の平均CPU使用率を示す。前述の通り、この値は各計算機上の運用管理エージェント210から定期的に送信されてくるため、それを受信するエージェント管理部によって定期的に更新される。
予測CPU使用率339は、本実施例によるプロビジョニング部304によって計算される、ビジネスプロセス配布後のCPU使用率の予測値を格納するカラムである。なお、図３の計算機管理テーブル312は、本実施例のシナリオであるビジネスプロセスDの配布後の状態を示している。
さらにシステム管理者900は、システム構築フェーズにおいて、後のポリシーベース運用で使用するシステムの運用ポリシーを設定する。具体的には、図４に示す運用ポリシーテーブル313のイベント340、実行条件341、アクション342の値を入力する。イベント340は、ポリシーベース運用が参照するイベント情報を示している。実行条件341は、イベント340に対し、アクション342を起こす閾値と条件を示している。そしてアクション342は、実行条件341を満たした場合に実行する処理内容を示している。
このように、あらかじめあるアクションを行うイベントと実行条件を設定しておき、あるタイミングでそのイベントが指し示す値が実行条件を満たしているかどうかを判定し、満たしているようであれば所定のアクションを行うという運用をポリシーベース運用と呼んでいる。
本実施例では、イベント340として、計算機管理テーブル312の予測CPU使用率339を設定し、それぞれのイベントに対する実行条件341はCPU使用率が70%以上とし、アクション342は計算機リソースの追加とする。これは、予測CPU使用率が70％以上になると、その計算機上で稼動するサービスやビジネスプロセスのレスポンスに影響が及び、そのような計算機には新たに計算機リソースを追加する必要があると、システム管理者が判断したためであるとする。
本実施例では、上記のように、本実施例によって計算されるビジネスプロセス配布後の予測CPU使用率339をポリシーベース運用のイベントとして扱い、ビジネスプロセスの配布より前に、ポリシーベース運用を実施すれば、予測CPU使用率が70％以上の計算機に対して、新たな計算機リソースを追加するというアクションが実行される。このように、ビジネスプロセスの配布前、すなわち、実際の負荷上昇より前に、計算機リソースの確保を行うことが可能となる。
本実施例では、計算機のリソースとして、CPUを想定しているが、メモリやディスクなどの他の計算機リソースを想定することも可能である。例えば、システム運用においてメモリ不足を懸念するのであれば、本実施例により予測計算機リソース使用量として予測メモリ使用量を計算し、その予測メモリ使用量をイベントとする運用ポリシーを定義し、ビジネスプロセス配布より前に、ポリシーベース運用を実施すれば、あらかじめ運用ポリシーに設定した条件に従って、計算機リソースを追加することができる。
本実施例における予測CPU使用率339に対してポリシーベース運用を適用するポリシーベース運用部302についての詳細な処理内容は後述する。
上記システム構築フェーズにおいて、システムの構成定義を行うと、サービス運用管理プログラム300は、システムを構成するサービス実行計算機上の運用管理エージェント210と通信を開始する。運用管理エージェント210と通信を行うサービス運用管理プログラム300のコンポーネントがエージェント管理部301である。
エージェント管理部301の役割は、システムを構成するサービス実行計算機201, 202, 203, 204, 205, 206上の運用管理エージェント210から送信されてくる各サービス実行計算機や各サービス・ビジネスプロセスの性能情報や実行時情報を受信し、呼出関係テーブル310やサービス管理テーブル311、計算機管理テーブル312にその情報を反映させることである。
具体的には、運用管理エージェント210から送信されてくる呼出元ビジネスプロセス名と呼出先サービス名のペア毎のビジネスプロセスの呼び出し回数とサービスの呼び出し回数は、図５に示す呼出関係テーブル310の呼出元320と呼出元ビジネスプロセス名が一致し、かつ呼出先321と呼出先サービス名が一致するレコードの呼出割合322に反映させる。
同様に、運用管理エージェント210から送信されてくるサービス実行計算機毎の平均CPU使用率は計算機管理テーブル312の平均CPU使用率338に、運用管理エージェント210から送信されてくる計算機名とサービス名のペア毎の１件当たりのCPU使用率は、図６に示すサービス管理テーブル311の計算機名330と送信されてくる計算機名が一致し、かつ、サービス名331と送信されてくるサービス名が一致するレコードの１件あたりのCPU使用率332に反映させる。ビジネスプロセスやサービスに関するCPU使用率やメモリ使用率等のシステム情報は、サービスやビジネスプロセスがサービス実行計算機に追加されてからサービス計算機から送信される。
これらのエージェントから送信されてくる実稼動情報により、図３の平均CPU使用率338、図６の１件当たりのCPU使用率332を更新する。実稼働情報は後述するプロビジョニング部304での計算機リソース使用量の予測値計算において使用される。実稼動情報を、計算機リソース使用量の予測値計算に用いることで、予測の精度を高めることができる。
なお、エージェント管理部301および運用管理エージェント210の詳細は、市販の運用管理ツールで実現可能であり、本実施例とは関係ないため、説明を省略する。
次に、本実施例の実施段階であるサービスおよびビジネスプロセス定義配布フェーズについて説明する。サービスおよびビジネスプロセス定義配布フェーズでは、システム管理者900は、配布するサービスまたはビジネスプロセス定義とその名前（どちらもサービス名と呼ぶ）と配布対象の計算機名を指定して、サービス運用管理プログラム300の配布操作を実行する。サービス運用管理プログラム300は配布操作の実行を受けると、システム管理者900からの入力を受け取り、サービス運用管理プログラム300の配布操作実行部303が呼び出される。配布操作実行部303のおおまかな処理の流れを図７のPAD図を用いて示す。
（ステップ3031）配布対象のサービス又はビジネスプロセスのサービス名と計算機名に基づき、サービス管理テーブル311にレコードを追加し、サービス名331と計算機名330を格納する。また、計算機管理テーブル312の稼動中サービスの情報337を更新する。
（ステップ3032）配布操作によって配布するのがサービスであればステップ3033を実行する。ビジネスプロセス定義であればステップ3034を実行する。
（ステップ3033）システム管理者900に指定された計算機名とサービスをエージェント管理部210に渡してサービスの配布を実行し、終了する。
（ステップ3034）本実施例によるプロビジョニング部304を実行し、ステップ3035を実行する。
（ステップ3035）システム管理者900に指定された計算機名とビジネスプロセス定義をエージェント管理部210に渡してビジネスプロセス定義の配布を実行し、終了する。
次に、配布操作実行部303の中で配布対象がビジネスプロセスである場合に実行するプロビジョニング部304の説明を行う。
図１６には、プロビジョニング部304のおおまかな処理の流れをPAD図を用いて示す。
（ステップ3041）配布操作によって配布するビジネスプロセス定義を分析して、このビジネスプロセスから呼び出すサービスを特定し、呼出関係テーブル310にその分析結果を反映する呼出関係分析ステップ305を実行する。呼出関係分析ステップ305は、ビジネスプロセスの想定使用頻度と、ビジネスプロセスから条件的に呼び出すサービス毎に、そのサービスの想定呼び出し割合を求める処理を行う。呼出関係分析ステップ305を実行後、ステップ3042を実行する。
（ステップ3042）計算機リソース使用量予測ステップ306の準備段階として、計算機管理テーブル312の平均CPU使用率338のカラムの値を予測CPU使用率339のカラムにコピーし、ステップ3043を実行する。
（ステップ3043）配布するビジネスプロセスから呼出関係テーブル310を元に呼出関係をたどり、ビジネスプロセス配布後の各計算機の予測CPU使用率を計算し、計算機管理テーブル312の予測CPU使用率339に計算結果を格納する計算機リソース使用量予測ステップ306を実行する。このステップを実行後、ステップ3044を実行する。
（ステップ3044）計算機管理テーブル312の予測CPU使用率339に対してポリシーベース運用を適用し、事前に設定した運用ポリシーに適合する計算機に対してリソースの追加を行うポリシーベース運用実行ステップ308を実行する。
さらに、以降では呼出関係分析ステップ305、計算機リソース使用量予測ステップ306、ポリシーベース運用実行ステップ308について、PAD図を用いて詳細に説明する。
まず呼出関係分析ステップ305について、図９のPAD図を用いて説明する。
（ステップ3051）ビジネスプロセス定義を分析して、配布するビジネスプロセスから呼び出すサービスと呼び出し関係を抽出する。呼び出し関係とは、図８のフローチャートに示すような、サービスの呼び出しの順序とどのような条件で呼び出されるかを示す情報である。このステップの詳細については後述する。この処理が終了したら、ステップ3052を実行する。
（ステップ3052）ステップ3051で抽出したサービスとその呼び出し関係を元に、図20に示すようなサービス呼出関係入力用GUI 700を生成し、システム管理者に配布するビジネスプロセスの想定使用頻度および１件あたりの想定CPU使用率、条件的に呼ばれるサービスの呼出割合を入力してもらう。必ず呼び出すサービスは、呼び出し割合を1.0とする。これらの値は、システム管理者が追加するビジネスプロセスの業務内容を考慮して入力する。ただし、ビジネスプロセスの１件あたりの想定CPU使用率はビジネスプロセスから呼び出すサービスの数から自動的に算出してデフォルト値としておいても良い。また、サービスの呼出割合についても、ビジネスプロセスから必ず呼び出される場合を１として、サービスの呼出までに条件分岐がある度に、一定の割合（例えば0.5）を乗じ、その値をデフォルト値としておいても良い。このように機械的な方法でデフォルト値を設けることは、後に行う計算機リソース使用量の予測計算の精度を多少悪化させてしまうものの、システム管理者の入力を省くことができる。
このように、条件分岐に一定の割合を自動設定する場合には、図２０のようなGUI（Graphical User Interface）をユーザに提示することなく呼出関係テーブル310のレコードを追加することができる。
（ステップ3053）ステップ3051で抽出したサービスの呼出関係を呼出関係テーブル310のレコードを追加し、呼出元320には配布するビジネスプロセス名を、呼出先321には抽出したサービス名を、呼出割合322にはステップ3052で求めたサービスの呼出割合を格納する。なお、ビジネスプロセスから複数回同じサービスを呼び出す場合には、サービス毎に呼び出し割合を合計した値を、呼出関係テーブル310の呼出割合322に格納する。よって、呼出割合322の値は1.0以上の値になってもよい。
（ステップ 3054）サービス管理テーブル311に、配布するビジネスプロセスのレコードを追加し、ステップ3052で求めたビジネスプロセスの１件あたりの想定CPU使用率を、サービス管理テーブル311の１件あたりのCPU使用率322に格納する。
ここで、上記ステップ3051におけるビジネスプロセス定義の分析の詳細について説明する。図１９には、BPELによって記述されたビジネスプロセスの一例として、ビジネスプロセス定義D 570の内容を示す。
BPELではXMLによってビジネスプロセスの処理手順を記述し、XMLのタグをアクティビティと呼ぶ。<flow>アクティビティは、子要素として出現するアクティビティを並列して実行するように定義するタグである。<flow>アクティビティの中には、<receive>アクティビティと<invoke>アクティビティ、<reply>アクティビティが存在する。<receive>アクティビティによりリクエストを受信すると次に実行するアクティビティを決定する。この場合、<receive>アクティビティの子要素である<source>アクティビティのlinkName属性の値と一致するlinkName属性の値の名前を持つ<target>アクティビティを子要素に持つアクティビティが次に実行するアクティビティとなる。すなわち、invoke_BP-BというName属性を持つ<invoke>アクティビティが次に実行されるアクティビティである。この<invoke>アクティビティはこのビジネスプロセスが他のサービスを呼び出すことを示すため、<invoke>アクティビティの出現を検知すれば、サービスの呼出関係を知ることができる。
呼出先のサービスの情報は<invoke>アクティビティの属性に記述されているがここでは省略する。ここではこの<invoke>アクティビティでビジネスプロセスDを呼び出すものとする。また、この<invoke>アクティビティの子要素には、複数の<source>アクティビティがあり、しかもtransitionConditionという属性値を持っている。これはtransitionCondition属性値の条件式がtrueであれば、その<source>アクティビティのリンクを実行することを示している。ここでは、２つの<source>アクティビティがあり、transitionCondition属性値の条件式が排他的であるため、条件分岐することを示している。分岐先は、invoke_S-DというName属性を持つ<invoke>アクティビティか、<reply>アクティビティである。分岐先の前者の<invoke>アクティビティ（ここではサービスDを呼び出すアクティビティとする）を実行すると<reply>アクティビティにリンクされている。
このことから、このビジネスプロセス定義D 570は、まずビジネスプロセスBを呼び出し、次にある条件を満たせば、サービスDを呼び出し、クライアントに返信し、先のある条件を満たさなければ、そのままクライアントに返信することを示す。すなわち、図８のようなフローチャートで表すことができる。
また、上記ステップ3052でシステム管理者に提示する図20のサービス呼出関係入力用GUI 700を説明する。図20は、上記ステップ3051におけるビジネスプロセス定義の分析結果である図8のフローチャートに、幾つかのシステム管理者入力用のテキストボックスを追加した画面である。配布するビジネスプロセスに関する入力用テキストボックスとして、ビジネスプロセスの想定使用頻度701と、１件あたりの想定CPU使用率702を追加し、条件分岐の後にサービスやビジネスプロセスを呼び出す場合には、その分岐線上に、呼出割合703の入力用テキストボックスを追加する。このように、配布するビジネスプロセス自体に関する情報と、配布するビジネスプロセスからサービスへの呼出割合をシステム管理者に入力させることで、本実施例における計算機リソース使用量の予測計算の準備が整う。
以上の呼出関係分析ステップ305によって、システムに配布されるビジネスプロセスからサービスへの呼出関係が呼出関係テーブル310に全て格納される。図５に示す呼出関係テーブル310は、先に図１９や図８を用いて説明したビジネスプロセス定義D 570の配布操作をシステム管理者900が実行し、その結果、呼出関係分析ステップ305が実行された後の状態を示す。ビジネスプロセスDからビジネスプロセスBへの呼び出しは必ず行われるため、呼出割合322には1.0という値が格納されている。またビジネスプロセスDからサービスDへの呼び出しは条件的に行われるため、システム管理者に呼び出し割合を入力してもらい、その結果、0.5という値が呼出割合322に格納されている。
また、呼出関係テーブル310のその他のレコードの呼出割合については、先に述べたように運用管理エージェントからの実稼動情報である。すなわち、ビジネスプロセスAは実際に、ビジネスプロセスBを必ず呼び出し、ビジネスプロセスCを条件的に0.3という割合で呼び出していることを示す。また、同様にして、ビジネスプロセスBは実際に、サービスAを必ず呼び出し、サービスBを条件的に0.5という割合で呼び出しており、ビジネスプロセスCはサービスCを条件的に0.4という割合で呼び出し、サービスDを必ず呼び出していることを示す。
このようなビジネスプロセス及びサービスが、どのビジネスプロセス又はサービスを呼び出しているかの呼出関係は、呼出関係テーブル310の呼出元320、呼出先321に格納されているサービス名、ビジネスプロセス名をたどることで特定することができるが、呼出関係テーブル310のサービス、ビジネスプロセスを特定するものとしては、サービス名、ビジネスプロセス名などの「名前」だけでなく、IDやアドレス情報など、サービス、ビジネスプロセスを特定することが可能な識別子であればよい。
追加するビジネスプロセスからのサービスへの呼出割合以外の既に稼働しているビジネスプロセス及びサービスについての呼出割合は、実稼動情報を用いることによって、次に説明する計算機リソース使用量予測ステップ306における計算機リソース使用量の予測計算の精度を高めることを可能としている。
例えば、図８のフローでは、新たにビジネスプロセスDを追加するときにはサービスD呼出割合を所定の例えば0.5を入力するが、実際にビジネスプロセスDが追加され、ある程度の期間稼働した後には、ビジネスプロセスDがサービスDを呼び出す割合は、ビジネスプロセスDの実行回数に対するサービスDの実行回数を計算することで、実際の稼働情報から計算することが可能である。この実稼働情報から求めたサービスDの呼出割合により、呼出関係テーブル310の呼出割合322を更新する。呼出関係テーブル310の更新は定期的に行ってもよいし、ビジネスプロセスの追加時やビジネスプロセスの実行時等、所定のイベントが発生した際に行ってもよい。
次に、呼出関係分析ステップ305の後に実行される計算機リソース使用量予測ステップ306を図１０のPAD図を用いて詳細に説明する。
計算機リソース使用量予測ステップ306を呼び出す際には分析対象のサービス名と分析対象の使用頻度の増加分を引数にして呼び出す。ここでは、分析対象のサービス名を、配布するビジネスプロセスの名前、分析対象の使用頻度の増加分を呼出関係分析ステップ305でシステム管理者900に入力してもらった想定使用頻度として、実行する。
（ステップ3061）計算機リソース使用量予測ステップ306の入力である、分析対象のサービス名とその使用頻度の増加分を取得し、ステップ3062を実行する。
（ステップ3062） 分析対象のサービス名をキーにして、サービス管理テーブル311を検索し、ステップ3063を実行する。
（ステップ3063）ステップ3062の検索で見つかったレコード数で、ステップ3061で求めた使用頻度の増加分を割り、それを個別使用頻度増加分とし、ステップ3064を実行する。
（ステップ3064）ステップ3062の検索で見つかったレコードについてステップ3065からステップ3068を繰り返す。繰り返しが終了したら、ステップ3069を実行する。
（ステップ3065）ステップ3062の検索結果のレコードから計算機名330と１件あたりのCPU使用率332を取得し、ステップ3066を実行する。
（ステップ3066）ステップ3065で求めた計算機名をキーに計算機管理テーブル312を検索し、検索結果のレコードの予測CPU使用率339をテンポラリの予測CPU使用率とする。その後、ステップ3067を実行する。
（ステップ3067）ステップ3065で求めた１件あたりのCPU使用率332にステップ3063で求めた個別使用頻度増加分を乗じて、CPU使用率の予測増加分を求め、ステップ3068を実行する。
（ステップ3068）ステップ3067で求めたCPU使用率の予測増加分とステップ3066で求めたテンポラリの予測CPU使用率を足した値を計算機管理テーブル312の予測CPU使用率339に格納する。
（ステップ3069）呼出関係テーブル310で、分析対象のサービスが呼出元320と一致するレコードを検索し、3070を実行する。
（ステップ3070）ステップ3069の検索で見つかったレコードについてステップ3071を繰り返す。繰り返しが終了したら、計算機リソース使用量予測ステップ306を終了する。
（ステップ3071）ステップ3069の検索結果のレコードから呼出先321を求め、これを新たな分析対象とし、さらに検索結果のレコードから呼出割合322を求め、ステップ3061で取得した使用頻度の増加分を乗じて、新たな分析対象の使用頻度の増加分として計算機リソース使用量予測ステップ306を再帰的に呼び出す。
以上で説明した計算機リソース使用量予測ステップ306を、配布するビジネスプロセスを最初の分析対象として実行すれば、分析対象の配布先計算機に関して予測CPU使用率を計算した後、呼出関係テーブル310を元にして、分析対象から呼び出すサービスを求め、それを新たな分析対象として再帰的に計算機リソース使用量予測ステップ306を呼び出す。それにより、配布するビジネスプロセスから直接又は間接的に呼び出すサービスの配布先計算機全てについて網羅的に、ビジネスプロセス配布後のCPU使用率の予測値を計算することができる。
例えば、ビジネスプロセスDをホストAに配布する場合、上記の説明によれば、分析対象をビジネスプロセスDとして計算機リソース使用量予測ステップ306を実行する。すると、まずは、ビジネスプロセスDの配布に伴うホストAの予測CPU使用率を計算する。呼出関係分析ステップ305でシステム管理者から入力されたビジネスプロセスDの想定使用頻度を４件／時間、1件あたりのCPU使用率を2.5％／件とすると、図５、図６の数値を用いた例では、ホストAのCPU使用率の増加分が4*2.5=10%／時間となり、計算機管理テーブル312の予測CPU使用率339からわかるホストAのテンポラリの予測CPU使用率30%／時間にこの増加分を加えると、40％／時間となる。この値を計算機管理テーブル312のホストAの予測CPU使用率339に格納する。
想定使用頻度とは、新たに追加するビジネスプロセスが実行される実行回数の見積りであり、システム管理者が入力するものであるが、これに限られず、似たような処理を行うビジネスプロセス等の実行回数に基づき、システムが自動的に入力することも可能である。
その後、ビジネスプロセスDから呼び出すサービスを呼出関係テーブル310から求めるとビジネスプロセスBとサービスDであるため、分析対象をビジネスプロセスB、サービスDとして順番に計算機リソース使用量予測ステップ306を実行する。ビジネスプロセスBを分析対象とした計算機リソース使用量予測ステップ306を呼び出す際には、ビジネスプロセスDの想定使用頻度４件／時間に、呼出関係テーブル310の呼出元がビジネスプロセスDで呼出先がビジネスプロセスBであるレコードの呼出割合である1.0を乗じた値である、４件／時間を、ビジネスプロセスBの使用頻度の増加分として、計算機リソース使用量予測ステップ306を実行する。
同様にして、サービスDを分析対象とした計算機リソース使用量予測ステップ306を呼び出す際には、ビジネスプロセスDの想定使用頻度４件／時間に、呼出関係テーブル310の呼出元がビジネスプロセスDで呼出先がサービスDであるレコードの呼出割合である0.5を乗じた値である、２件／時間を、サービスDの使用頻度の増加分として、計算機リソース使用量予測ステップ306を実行する。
ビジネスプロセスBを分析対象とした計算機リソース使用量予測ステップ306では、ビジネスプロセスDの場合と同様に、ビジネスプロセスBの配布先計算機であるホストBの予測CPU使用率を計算する。ホストBのCPU使用率増加分は、使用頻度の増加分４件／時間に、サービス管理テーブル312からわかるビジネスプロセスBの１件あたりのCPU使用率332である5%／件を乗じた値 20%／時間であるため、ホストBの予測CPU使用率339はテンポラリの予測CPU使用率40%／時間に20%／時間を加えた60%／時間となる。そして、ビジネスプロセスBがサービスAとサービスBを呼び出すことが呼出関係テーブルより求まるので、さらにサービスAとサービスBを分析対象として順番に計算機リソース使用量予測ステップ306を実行する。
その結果、サービスAとサービスBの配布先計算機であるホストCとホストDの予測CPU使用率をこれまでと同様に計算すると、ホストCが80%／時間、ホストDが60%／時間となる。サービスAやサービスBは他のサービスを呼び出さないことが呼出関係テーブル310から判明するため、これ以上は再帰的な計算機リソース使用量予測ステップ306の呼び出しは行わずに、ビジネスプロセスBを分析対象とする計算機リソース使用量予測ステップ306に戻る。そして、ビジネスプロセスBを分析対象とする計算機リソース使用量予測ステップ306が終了すると、サービスDを分析対象とする計算機リソース使用量予測ステップ306が実行され、サービスDの配布先計算機であるホストEの予測CPU使用率は、30%／時間となる。以上の処理の結果、ビジネスプロセスDからの呼び出し関係を全てたどって、予測CPU使用率の計算が完了する。
このように、呼出関係テーブル310のサービスの呼出関係と呼出割合を用いた計算機リソース使用量予測ステップ306により、新規ビジネスプロセスの追加時に、そのビジネスプロセスから呼び出すサービスの呼出割合や、ビジネスプロセスの想定使用頻度および１件あたりのCPU使用率という、追加するビジネスプロセスだけに関連する情報をシステム管理者が入力するだけで、半自動的に、システム全体の計算機について、ビジネスプロセスを追加した場合の将来の計算機リソース使用量を計算することが可能となる。
また、計算機リソース使用量予測ステップ306は、計算機リソース使用量として、CPU使用率だけに限らず、メモリ使用量やディスク使用量についても同様に計算が可能である。この計算機リソース使用量予測ステップ306で計算した将来の計算機リソース使用量をシステム管理者に提示することによって、システム管理者が不足しそうなリソースを判断し、手動で事前にリソースを追加することが可能となる。また、将来の計算機リソース使用量に対してポリシーベース運用を実施することによって、あらかじめ定義したポリシーに従って、リソースの確保を自動的に行うことが可能となる。
以下に、計算機リソース使用量予測ステップ306の後に実行するポリシーベース運用実行ステップ308を図１１のPAD図を用いて説明する。
（ステップ3081）計算機管理テーブルの予測CPU使用率に対して、ポリシーベース運用600を適用する。ただし、このポリシーベース運用の延長で計算機リソースが確保され、新たにサービスやビジネスプロセスの配布が行われる場合には、配布操作実行部303を実行せずに、運用管理エージェント210に直接サービスやビジネスプロセスの配布の実行依頼のみを行うものとする。
計算機管理テーブルの予測CPU使用率に対するポリシーベース運用600について、図１７のPAD図を用いて説明する。
（ステップ601）運用ポリシーテーブル313の全レコードについて602から604までのステップを繰り返す。本実施例では、図４のように、イベント340が計算機の予測CPU利用率、実行条件が70%以上、アクション342が計算機の追加というレコードのみが存在するとする。
（ステップ602）運用ポリシーテーブル313のイベント340が示す値を求める。この実施例では、イベント340の値が計算機の予測CPU利用率であることから、計算機管理テーブル312の各計算機の予測CPU利用率339の値を求める。
（ステップ603）運用ポリシーテーブル313の実行条件341にステップ602で求めた値が適合するかどうかチェックし、適合する場合には604を実行する。本実施例の場合、計算機管理テーブル312の各計算機の予測CPU利用率339の値に対して、実行条件である70%以上という条件が適合するかどうかチェックを行う。すると、ホストCの計算機の予測CPU使用率が80%となっており、70％以上という実行条件に適合するため、ホストCに対して、計算機リソースの追加というアクション342を実行する。本実施例では、計算機管理テーブルより、ホストFが空き計算機リソースであることが判断できるため、ホストFにホストC上で稼動しているサービスと同じサービスであるサービスAをホストFのサービス実行計算機に配布する。このように、ある計算機と同じサービスが稼動する計算機を追加することをスケールアウトと呼ぶ。
上記ポリシーベース運用600では、図４の運用ポリシーテーブル313にあらかじめ様々な運用ポリシーを設定しておくことにより、上記のようなスケールアウトだけでなく、様々な運用を行うことができる。
例えば、上記と同じイベント340（計算機の予測CPU利用率）、実行条件 341（70%以上）で、アクション342をCPUのスケールアップという運用ポリシーのレコードをあらかじめ運用ポリシーテーブル313に設定しておくことにより、予測CPU利用率が70％を超えた計算機のCPUを現在のCPUよりも高性能なCPUに交換するといった運用が可能になる。スケールアップの方法としては、現在サービスを実行している計算機よりCPUやメモリなど処理能力の高い計算機に、現在実行しているサービスを移行することにより、処理能力の高い計算機にスケールアップして、サービスを実行することができる。
同様に、上記と同じイベント340、実行条件 341で、アクション342を、負荷の高いサービスを負荷の低いサービスと交換という運用ポリシーをあらかじめ設定しておくことにより、予測CPU利用率が70％を超えた計算機上のサービスのうち、負荷の高いサービスを他の計算機上の負荷の低いサービスと入れ替えるといった運用が可能となる。また、同様に、アクション342次第では、実行条件を満たした計算機上の負荷の高いサービスを空き計算機に移動するといった運用や、実行条件を満たした計算機上の負荷の低いサービスを他の計算機に移動するといった運用も可能となる。
なお、サービスを他の計算機に移動するとは、他の計算機で同様のサービスを実行し、元の計算機で稼働していたサービスを停止又は削除すればよい。この際に、移動するサービスを使用していたクライアント等には、サービスを引き継いだ後の移動先計算機のＩＰアドレス等の識別子を通知することで、サービスを引き継ぐことが可能となる。また、別の方法としては、サービスの移動後の計算機のＩＰアドレスをサービスの移動前の計算機が使用していたＩＰアドレスにしてやれば、クライアントから見れば同じ宛先ＩＰアドレスで同じサービスの提供を受けることができる。
また、イベント340を計算機の予測CPU利用率、実行条件341を30%以下として、アクションをサービスの他の計算機への移動という運用ポリシーのレコードをあらかじめ運用ポリシーテーブル313に設定しておくことにより、CPU利用率の下がる計算機上のサービスを他の計算機に移動させ、空き計算機リソースを作り出すといった運用も可能となる。また同じイベント340、実行条件 341で、アクション342を、サービスの削除という運用ポリシーを設定しておくと、予測CPU使用率が30%以下になった計算機上のサービスについて、他の計算機上で同じサービスが稼動しているのであれば、削除するといった運用も可能となる。また、同じイベント340、実行条件 341で、アクション342を、スケールダウンやスケールインと設定しておくことによって、同じ構成の計算機の数を減らしたり、計算機リソースの縮小を行うといった運用も可能となる。 他にも、新たなサービスを計算機Ａに追加したい場合に、計算機Ａ上で既に稼働しているサービスを実行条件を満たした他の計算機Ｂに移動したうえで、移動により負荷の下がる計算機Ａで新たなサービスを実行する運用などが可能となる。
さらに、上記ステップ603における計算機リソースの追加やサービスの追加・移動・削除の際には、サービスやビジネスプロセスの特性に基づいて行うことも可能である。例えば、サービスによっては、アクセス制限などの業務上の要件から、特定の計算機上で動作していなくてはならないといった制限や、サービスの可用性・信頼性が必要となるために、他のサービスとの共存は避けたいといった制限が考えられる。このような要件を考慮した計算機リソースの追加を行うために、サービス毎の制限を格納するテーブルを設け、そのテーブルのレコードをサービスの配布時に設定しておき、その情報を元に、計算機リソースの追加を行うことが可能である。
例えば、上記本実施例のように、ホストCのリソース使用量が運用ポリシーに設定した条件を満たし、計算機リソースを追加する場合、ホストCに配布されているサービスAに何も制限がない場合には、計算機管理テーブル312を参照し、空き計算機リソースであるホストFを確保し、ホストF上にサービスAを配布することによって、負荷分散を行うことができる。また、サービスAにホストCでのみ稼動可能という制限がある場合には、ホストCをスケールアップするしかないため、システム管理者に警告を発するといった対処を行う。また、システム全体で空きの計算機リソースがなく、サービスAに何も制限がなければ、他のCPU使用率が低い計算機にサービスAを配布して負荷分散を行うことが可能であるが、サービスAに他のサービスとの共存は負荷という制限がある場合には、やはりシステム管理者に警告を発するという対処を行う。
上記ポリシーベース運用実行ステップ308をサービス実行基盤プログラム400へのビジネスプロセスの配布より前に実施することにより、予測CPU使用率をイベントとするポリシーベースの運用が実行され、あらかじめ設定した条件に合致した計算機の計算機リソースを確保することが可能となる。図３の例では、ホストCが運用ポリシーテーブル313に設定した、予測CPU使用率が70%以上という条件を満たすため、何もサービスが稼動していない空き計算機リソースであるホストFに、ホストCで稼動しているサービスと同じサービスであるサービスAが配布される。この結果、ビジネスプロセスDの配布によるサービスAへの負荷の増大を事前に防止し、その結果、サービスAを間接的又は直接的に使用するビジネスプロセスのパフォーマンスに影響が出ないようにすることができる。
これまで述べたように、本実施例によれば、ビジネスプロセス定義から抽出可能なビジネスプロセスとサービスの呼出関係に基づいて作成される呼出関係テーブルを元に、ビジネスプロセスの追加によって影響を受ける計算機を特定し、それらの計算機について予測CPU使用率を計算し、予測CPU利用率が一定の値以上になるようであれば、計算機リソースを追加するという運用ポリシーに従ってポリシーベース運用を適用することによって、実際にビジネスプロセスを配布するより、将来リソースが不足しそうな計算機に対して別の計算機リソースを確保することが可能となる。
また、第一の実施例では、計算機リソース使用量として、計算機のCPU使用率にのみ着目したが、計算機のメモリ使用量や記憶装置の使用率等に着目し、それらの予測値を計算し、予測値に対する運用ポリシーを記述することによって、CPU使用率以外の計算機リソース使用量を元に、リソースの追加の必要性の有無を判断し、必要であれば事前にリソースを追加することが可能となる。
また、さらに、予測値に対する運用ポリシーのアクションとして、単純なスケールアウトだけでなく、スケールアップや、サービスの移動といった運用ポリシーを設定することによって、計算機リソース使用量の低減を行うという運用も可能となる。
なお、本実施例ではサービス運用管理プログラム300とサービス実行基盤プログラム400を別計算機上で起動しているが、同一計算機上で起動してもよい。また、図１のシステム構成は本実施例の手順を示すための一例であり、サービスとビジネスプロセスが同一のサービス実行基盤プログラム400に配布されていてもよい。
次に、第二の実施例について説明する。第一の実施例では、システムを構成するサービス実行計算機全てが１つのサービス運用管理プログラム300によって運用管理されているケース（管理ドメインが１つの場合）について、実施例を示した。しかし、BtoBなどのシステム間連携を考えると、管理ドメインが複数存在し、他の管理ドメインに存在するサービスを呼び出す場合も考えられる。
本実施例は、図１２に示すような、複数の管理ドメインがある場合にも、計算機リソース使用量の予測および、その予測値に基づく計算機リソースの確保が可能であることを示すものである。まず、図１２に示すように、複数の管理ドメインがある場合には、それぞれの管理ドメイン毎に、サービス運用管理プログラム300を設置する構成を採る。また、プロビジョニング部304の処理の流れは第一の実施例と同じであるが、本実施例は第一の実施例と以下の点が異なる。
まず、それぞれのドメインに存在するサービス運用管理プログラム300が連携するためのドメイン連携テーブル314を新たに設ける。そして、プロビジョニング部304の内部の処理である計算機リソース使用量予測ステップ306とポリシーベース運用適用ステップ308ではこのドメイン連携テーブル314を用いて、サービス運用管理プログラム300間で通信を行い、複数のドメイン間で本実施例を実施する。以下では、これらの相違点についてのみ説明する。
まず、ドメイン連携テーブル314の構成を図１３を用いて説明する。ドメイン連携テーブル314は、サービス名350と運用管理サーバアドレス351を有する。サービス名350には、外部の管理ドメインに存在するサービス又はビジネスプロセスのサービス名を格納する。また、運用管理サーバアドレス351は、外部のドメインのサービス毎に、そのサービスを管理するサービス運用管理プログラム300のアドレスを格納する。このドメイン連携テーブル314は、システム管理者900があらかじめ設定してもよいし、ネットワーク管理装置等と連携することで自動的に設定してもよい。
次に、第二の実施例における計算機リソース使用量予測ステップ306の詳細を図１４に示す。
（ステップ3091）計算機リソース使用量予測ステップ306の入力である、分析対象のサービス名とその使用頻度の増加分を取得し、ステップ3092を実行する。
（ステップ3092） 分析対象のサービス名をキーにして、サービス管理テーブル311を検索し、ステップ3093を実行する。
（ステップ3093）ステップ3092の検索の結果、該当するレコードがない場合には、ステップ3094を実行する。該当するレコードがある場合には、ステップ3097を実行する。
（ステップ3094） 分析対象のサービス名をキーにドメイン連携テーブル314を検索し、ステップ3095を実行する
（ステップ3095）ステップ3094の検索の結果、該当するレコードがない場合にはエラー終了する。エラーケースは本実施例とは関係ないため、詳細は省略する。該当するレコードがある場合には、ステップ3096を実行する。
（ステップ3096）検索結果のレコードの運用管理サーバアドレス351に対して、ステップ3091で求めた分析対象のサービス名とその使用頻度の増加分を引数として、計算機リソース使用量予測ステップの実行要求を送信し、送信先のアドレスを連携先アドレスとして主記憶装置上または二次記憶装置上に記憶して終了する。連携先アドレスは、計算機リソース使用量予測ステップの後に実行されるポリシーベース運用実行ステップで使用する。この計算機リソース使用量予測ステップの実行要求を受信したサービス運用管理プログラム300は、受信した引数をそのまま、自身の計算機リソース使用量予測ステップ306の引数にして、計算機リソース使用量予測ステップ306を実行する。
（ステップ3097）ステップ3092の検索で見つかったレコード数で、ステップ3091で求めた使用頻度の増加分を割り、それを個別使用頻度増加分とし、ステップ3098を実行する。
（ステップ3098）ステップ3092の検索で見つかったレコードについてステップ3099からステップ3102を繰り返す。繰り返しが終了したら、ステップ3103を実行する。
（ステップ3099）ステップ3092の検索結果のレコードから計算機名330と１件あたりのCPU使用率332を取得し、ステップ3100を実行する。
（ステップ3100）ステップ3099で求めた計算機名をキーに計算機管理テーブル312を検索し、検索結果のレコードの予測CPU使用率339をテンポラリの予測CPU使用率とする。その後、ステップ3101を実行する。
（ステップ3101）ステップ3099で求めた１件あたりのCPU使用率332にステップ3097で求めた個別使用頻度増加分を乗じて、CPU使用率の予測増加分を求め、ステップ3102を実行する。
（ステップ3102）ステップ3101で求めたCPU使用率の予測増加分とステップ3100で求めたテンポラリの予測CPU使用率を足した値を計算機管理テーブル312の予測CPU使用率339に格納する。
（ステップ3103）呼出関係テーブル310で、分析対象のサービスが呼出元320と一致するレコードを検索し、3104を実行する。
（ステップ3104）ステップ3103の検索で見つかったレコードについてステップ3105を繰り返す。繰り返しが終了したら、計算機リソース使用量予測ステップ306を終了する。
（ステップ3105）ステップ3103の検索結果のレコードから呼出先321を求め、これを新たな分析対象とし、さらに検索結果のレコードから呼出割合322を求め、ステップ3091で取得した使用頻度の増加分を乗じて、新たな分析対象の使用頻度の増加分として計算機リソース使用量予測ステップを再帰的に呼び出す。
以上の計算機リソース使用量予測ステップ306では、分析対象のサービスがそのドメインにない場合、すなわち、サービス名をキーにしてサービス管理テーブル311を検索して見つからない場合に、ドメイン連携テーブル314をサービス名をキーにして検索し、その結果得られる運用管理サーバアドレスに、計算機リソース使用量予測ステップ306の実行依頼を送信することによって、計算機リソース使用量予測ステップの実行を他の管理ドメインのサービス運用管理プログラム300に伝播させている。これにより、複数のドメイン間で本実施例を実施することを可能にしている。
最後に第二の実施例におけるポリシーベース運用実行ステップ308の詳細を図１５に示す。
（ステップ3130）計算機管理テーブル312の予測CPU使用率339に対して、ポリシーベース運用を適用する。
（ステップ3131）計算機リソース使用量予測ステップ306のステップ3096で記憶した、連携先アドレスに対して、ポリシーベース運用実行ステップ308の実行依頼を送信する。ポリシーベース運用実行ステップ308の実行依頼を受信したサービス運用管理プログラム300は、自身のポリシーベース運用実行ステップ308を実行する。
以上で説明した、ポリシーベース運用実行ステップ308により、計算機リソース使用量予測ステップ306実行時に連携したサービス運用管理プログラム300に、ポリシーベース運用実行ステップ308の実行依頼を送信することにより、ポリシーベース運用実行ステップ308の実行も他の管理ドメインに伝播させることができ、複数のドメイン間で本実施例を実施することを可能にしている。
上述した実施形態は、本発明の趣旨を逸脱しない範囲で適宜変更や組み合わせ可能である。
第一の実施例における全体のシステム構成図の例 サービス運用管理計算機100の構成図の例 計算機管理テーブル312の構成図の例 運用ポリシーテーブル313の構成図の例 呼出関係テーブルの310構成図の例 サービス管理テーブル311の構成図の例 配布操作実行部303のPAD図の例 ビジネスプロセスの例を示す図の例 呼出関係分析ステップ305のPAD図の例 計算機リソース使用量予測ステップ306のPAD図の例 ポリシーベース運用実行ステップ308のPAD図の例 第二の実施例における全体のシステム構成図の例 ドメイン連携テーブルの構成図の例 第二の実施例における計算機リソース使用量予測ステップ306のPAD図の例 第二の実施例におけるポリシーベース運用実行ステップ308のPAD図の例 プロビジョニング部のPAD図の例 ポリシーベース運用のPAD図の例 第一の実施例における計算機の構成とサービスおよびビジネスプロセスの配布状況の例 ビジネスプロセス定義Dの内容の例 サービス呼出関係入力用GUIの構成図の例
符号の説明
100:サービス運用管理計算機
101:CPU
102:ネットワークインタフェース回路
103:二時記憶装置制御回路
104:主記憶装置
105:二時記憶装置
106:OS
201,202,203,204,205,206:サービス実行計算機
210:運用管理エージェント
300: サービス運用管理プログラム
301:エージェント管理部
302:ポリシーベース運用部
303:配布操作実行部
305:呼出関係分析ステップ
306:計算機リソース使用量予測ステップ
308:ポリシーベース運用実行ステップ
310:呼出関係テーブル
311:サービス管理テーブル
312:計算機管理テーブル
313:運用ポリシーテーブル
314:ドメイン連携テーブル
400:サービス実行基盤プログラム
500:ビジネスプロセスA
520:ビジネスプロセスB
540:ビジネスプロセスC
560:ビジネスプロセスD
570:ビジネスプロセス定義D
590:サービスA
591:サービスB
592:サービスC
593:サービスD
700:サービス呼出関係入力用GUI
900:システム管理者
1000:ネットワーク

Claims (20)

  1. サービスの組み合わせであるビジネスプロセスを処理するビジネスプロセス処理システムへのビジネスプロセス追加方法であって、
    前記追加するビジネスプロセスへの処理要求が処理されるときに実行される前記追加するビジネスプロセスを構成するサービスの実行回数から、前記ビジネスプロセス処理システムを構成する計算機の負荷の予測値を求め、
    前記計算機の負荷の予測値が所定の条件を満たすか否かを判定し、
    前記判定結果に応じて、前記追加するビジネスプロセスを前記ビジネスプロセス処理システムに追加するかどうかを決定する
    ことを特徴とするビジネスプロセス追加方法。
  2. 請求項１に記載のビジネスプロセス追加方法であって、
    前記ビジネスプロセス処理システムは、ビジネスプロセスが呼び出すサービスの呼び出し関係を格納した呼出関係テーブルを有し、
    前記追加するビジネスプロセスへの処理要求が処理されるときに実行される前記追加するビジネスプロセスを構成するサービスは、前記呼出関係テーブルから特定する
    ことを特徴とするビジネスプロセス追加方法。
  3. 請求項２に記載のビジネスプロセス追加方法であって、
    前記呼出関係テーブルは、ビジネスプロセスが該ビジネスプロセスを構成するサービスを呼び出す場合の呼出割合を格納し、
    前記サービスの実行回数は、前記追加するビジネスプロセスが実行された場合の想定使用頻度と、前記呼出関係テーブルから抽出したサービスの呼出割合とから求める
    ことを特徴とするビジネスプロセス追加方法。
  4. 請求項３に記載のビジネスプロセス追加方法であって、
    前記呼出関係テーブルは、ビジネスプロセス定義に記載された、ビジネスプロセスがサービスを呼び出す呼出関係を基に作成される
    ことを特徴とするビジネスプロセス追加方法。
  5. 請求項１乃至４のいずれか１に記載のビジネスプロセス追加方法であって、
    計算機の負荷の予測値は、前記実行回数と、サービスを実行した場合の単位実行回数当たりの計算機の負荷の値とから求める
    ことを特徴とするビジネスプロセス追加方法。
  6. 請求項１乃至５のいずれか１に記載のビジネスプロセス追加方法であって、
    前記計算機の負荷は、計算機の、ＣＰＵ、主記憶装置、二次記憶装置のうちの少なくとも１の負荷であることを特徴とするビジネスプロセス追加方法。
  7. 請求項１乃至６のいずれか１に記載のビジネスプロセス追加方法であって、
    前記計算機の負荷の予測値が所定の条件を満たすか否かの判定は、前記計算機の負荷の予測値が所定の値を超えるかどうかで判定する
    ことを特徴とするビジネスプロセス追加方法。
  8. 請求項１乃至７のいずれか１に記載のビジネスプロセス追加方法であって、
    前記追加するビジネスプロセスを追加することを決定した場合に、負荷の予測値が所定の条件を満たすか否かを判定した前記計算機とは異なる他の計算機を、前記追加するビジネスプロセスを構成するサービスを実行する計算機として割り当てる
    ことを特徴とするビジネスプロセス追加方法。
  9. 請求項１乃至７のいずれか１に記載のビジネスプロセス追加方法であって、
    前記追加するビジネスプロセスを追加することを決定した場合に、負荷の予測値が所定の条件を満たすか否かを判定した前記計算機で実行されているサービスを他の計算機に移動し、前記条件を満たす計算機で前記追加するビジネスプロセスを構成するサービスを実行する
    ことを特徴とするビジネスプロセス追加方法。
  10. 請求項１乃至７のいずれか１に記載のビジネスプロセス追加方法であって、
    前記追加するビジネスプロセスを追加することを決定した場合に、負荷の予測値が所定の条件を満たすか否かを判定した前記計算機に対し、スケールアウト、スケールアップ、スケールイン、スケールダウンのうちの少なくとも１を実施する
    ことを特徴とするビジネスプロセス追加方法。
  11. 請求項１乃至７の記載のいずれか１に記載のビジネスプロセス追加方法であって、
    前記追加するビジネスプロセスを追加することを決定した場合に、負荷の予測値が所定の条件を満たすか否かを判定した前記計算機で実行されているサービスを、削除、他の計算機への複製、他の計算機への移動、他の計算機で実行されているサービスとの交換、のうちの少なくとも１の処理を実施する
    ことを特徴とするビジネスプロセス追加方法。
  12. サービスの組み合わせであるビジネスプロセスを処理するビジネスプロセス処理システムであって、
    前記追加するビジネスプロセスへの処理要求が処理されるときに実行される前記追加するビジネスプロセスを構成するサービスの実行回数から、前記ビジネスプロセス処理システムを構成する計算機の負荷の予測値を求めるプロビジョニング部と、
    前記計算機の負荷の予測値が所定の条件を満たすか否かを判定し、前記判定結果に応じて、前記追加するビジネスプロセスを前記ビジネスプロセス処理システムに追加するかどうかを決定するポリシーベース運用部と
    を有することを特徴とするビジネスプロセス処理システム。
  13. 請求項１２記載のサービスの組み合わせであるビジネスプロセスを処理するビジネスプロセス処理システムであって、
    前記ビジネスプロセス処理システムは、ビジネスプロセスが呼び出すサービスの呼び出し関係を格納した呼出関係テーブルを有する
    ことを特徴とするビジネスプロセス処理システム。
  14. 請求項１３記載のビジネスプロセス処理システムであって、
    前記呼出関係テーブルは、ビジネスプロセスが該ビジネスプロセスを構成するサービスを呼び出す場合の呼出割合を格納し、
    前記プロビジョニング部は、前記追加するビジネスプロセスが実行された場合の想定使用頻度と、前記呼出関係テーブルから抽出したサービスの呼出割合とから前記サービスの実行回数を求める
    ことを特徴とするビジネスプロセス処理システム。
  15. 請求項１２乃至１４のいずれか１に記載のビジネスプロセス処理システムであって、
    前記プロビジョニング部は、前記実行回数と、サービスを実行した場合の単位実行回数当たりの計算機の負荷の値とから、計算機の負荷の予測値を求める
    ことを特徴とするビジネスプロセス処理システム。
  16. 請求項１２乃至１５のいずれか１に記載のビジネスプロセス処理システムであって、
    計算機の、ＣＰＵ、主記憶装置、二次記憶装置のうちの少なくとも１の負荷を監視するエージェント管理部を有する
    ことを特徴とするビジネスプロセス処理システム。
  17. 請求項１２乃至１６のいずれか１に記載のビジネスプロセス処理システムであって、
    前記ポリシーベース運用部は、前記追加するビジネスプロセスを追加することを決定した場合に、負荷の予測値が所定の条件を満たすか否かを判定した前記計算機とは異なる他の計算機を、前記追加するビジネスプロセスを構成するサービスを実行する計算機として割り当てる
    ことを特徴とするビジネスプロセス処理システム。
  18. 請求項１２乃至１６のいずれか１に記載のビジネスプロセス処理システムであって、
    前記ポリシーベース運用部は、前記追加するビジネスプロセスを追加することを決定した場合に、負荷の予測値が所定の条件を満たすか否かを判定した前記計算機で実行されているサービスを他の計算機に移動し、前記条件を満たす計算機で前記追加するビジネスプロセスを構成するサービスを実行する
    ことを特徴とするビジネスプロセス処理システム。
  19. 請求項１２乃至１６のいずれか１に記載のビジネスプロセス処理システムであって、
    前記ポリシーベース運用部は、前記追加するビジネスプロセスを追加することを決定した場合に、負荷の予測値が所定の条件を満たすか否かを判定した前記計算機に対し、スケールアウト、スケールアップ、スケールイン、スケールダウンのうちの少なくとも１を実施する
    ことを特徴とするビジネスプロセス処理システム。
  20. 請求項１２乃至１６の記載のいずれか１に記載のビジネスプロセス処理システムであって、
    前記ポリシーベース運用部は、前記追加するビジネスプロセスを追加することを決定した場合に、負荷の予測値が所定の条件を満たすか否かを判定した前記計算機で実行されているサービスを、削除、他の計算機への複製、他の計算機への移動、他の計算機で実行されているサービスとの交換、のうちの少なくとも１を実施する
    ことを特徴とするビジネスプロセス処理システム。
JP2005337997A 2005-11-24 2005-11-24 ビジネスプロセス定義を用いた事前リソース割り当て方法 Pending JP2007148469A (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
JP2005337997A JP2007148469A (ja) 2005-11-24 2005-11-24 ビジネスプロセス定義を用いた事前リソース割り当て方法
US11/600,090 US8386636B2 (en) 2005-11-24 2006-11-16 Business process system management method

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2005337997A JP2007148469A (ja) 2005-11-24 2005-11-24 ビジネスプロセス定義を用いた事前リソース割り当て方法

Publications (1)

Publication Number Publication Date
JP2007148469A true JP2007148469A (ja) 2007-06-14

Family

ID=38054629

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2005337997A Pending JP2007148469A (ja) 2005-11-24 2005-11-24 ビジネスプロセス定義を用いた事前リソース割り当て方法

Country Status (2)

Country Link
US (1) US8386636B2 (ja)
JP (1) JP2007148469A (ja)

Cited By (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2010066828A (ja) * 2008-09-08 2010-03-25 Ns Solutions Corp 情報処理装置、情報処理方法及びプログラム
JP2010086317A (ja) * 2008-09-30 2010-04-15 Hitachi Ltd リソース割当方法、リソース割当プログラム、および、フロー処理システム
JP2010108409A (ja) * 2008-10-31 2010-05-13 Hitachi Ltd ストレージ管理方法及び管理サーバ
JP2010176192A (ja) * 2009-01-27 2010-08-12 Mitsubishi Electric Corp システム連携基盤設計支援方法、システム連携基盤設計支援装置および設計支援プログラム
WO2010106861A1 (ja) * 2009-03-18 2010-09-23 株式会社日立製作所 サービス連携装置、プログラム、サービス連携方法及びサービス提供システム
JP2011044054A (ja) * 2009-08-24 2011-03-03 Fuji Xerox Co Ltd 情報処理システム、情報処理装置、及びプログラム
JP2011186531A (ja) * 2010-03-04 2011-09-22 Nec Corp Ｓｍｔ対応ｃｐｕを有する情報処理装置の消費電力低減方法、消費電力低減装置及び消費電力低減プログラム
JP2012137865A (ja) * 2010-12-24 2012-07-19 Toshiba Corp サービス提供システム、装置及びプログラム
JP2014007438A (ja) * 2012-06-21 2014-01-16 Ntt Comware Corp ノード管理装置、ノード管理方法、及びプログラム
US8966492B2 (en) 2008-01-31 2015-02-24 Nec Corporation Service provision quality control device
JP2015225399A (ja) * 2014-05-26 2015-12-14 ソフトバンク株式会社 業務処理システム、業務処理能力の監視システムおよび監視方法

Families Citing this family (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20080140469A1 (en) * 2006-12-06 2008-06-12 International Business Machines Corporation Method, system and program product for determining an optimal configuration and operational costs for implementing a capacity management service
US8472330B2 (en) * 2007-06-22 2013-06-25 International Business Machines Corporation System and method for determining and optimizing resources of a data processing system utilized by a service request
US9009309B2 (en) * 2007-07-11 2015-04-14 Verizon Patent And Licensing Inc. Token-based crediting of network usage
US7961610B1 (en) * 2008-04-03 2011-06-14 Clear Wireless Llc Method and system for overload control
KR101812583B1 (ko) * 2011-07-21 2018-01-30 삼성전자주식회사 태스크 할당 장치, 태스크 할당 방법 및 컴퓨터로 읽을 수 있는 저장 매체
US20140358626A1 (en) * 2013-06-04 2014-12-04 Hewlett-Packard Development Company, L.P. Assessing the impact of an incident in a service level agreement
US9979669B1 (en) * 2013-12-13 2018-05-22 Emc Corporation Projecting resource allocation to achieve specific application operation times in a virtually provisioned environment
CN106779363A (zh) * 2016-12-02 2017-05-31 浪潮通信信息系统有限公司 一种业务处理方法及装置
US10924410B1 (en) * 2018-09-24 2021-02-16 Amazon Technologies, Inc. Traffic distribution mapping in a service-oriented system
US20220038390A1 (en) * 2018-09-25 2022-02-03 Nec Corporation Design management apparatus, control method thereof, program and management system
US10838735B2 (en) * 2018-12-07 2020-11-17 Nutanix, Inc. Systems and methods for selecting a target host for migration of a virtual machine
CN111338798A (zh) * 2020-02-21 2020-06-26 北京天融信网络安全技术有限公司 一种cpu使用率预测方法及装置

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2002351852A (ja) * 2001-05-28 2002-12-06 Mitsubishi Electric Corp システム運用管理方式
JP2005100387A (ja) * 2003-09-02 2005-04-14 Toshiba Corp 計算機システム及びクラスタシステム用プログラム

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP3284956B2 (ja) * 1998-01-26 2002-05-27 日本電気株式会社 プログラム変換方法、プログラム変換装置及びプログラム変換プログラムを記憶した記憶媒体
JP2002007364A (ja) * 2000-06-22 2002-01-11 Fujitsu Ltd 並列計算機システムのジョブスケジューリングを行うスケジューリング装置
US7117500B2 (en) * 2001-12-20 2006-10-03 Cadence Design Systems, Inc. Mechanism for managing execution of interdependent aggregated processes
US7783759B2 (en) * 2002-12-10 2010-08-24 International Business Machines Corporation Methods and apparatus for dynamic allocation of servers to a plurality of customers to maximize the revenue of a server farm
JP4066932B2 (ja) 2003-11-10 2008-03-26 株式会社日立製作所 予測に基づいた計算機リソース配分方法

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2002351852A (ja) * 2001-05-28 2002-12-06 Mitsubishi Electric Corp システム運用管理方式
JP2005100387A (ja) * 2003-09-02 2005-04-14 Toshiba Corp 計算機システム及びクラスタシステム用プログラム

Cited By (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8966492B2 (en) 2008-01-31 2015-02-24 Nec Corporation Service provision quality control device
JP2010066828A (ja) * 2008-09-08 2010-03-25 Ns Solutions Corp 情報処理装置、情報処理方法及びプログラム
JP2010086317A (ja) * 2008-09-30 2010-04-15 Hitachi Ltd リソース割当方法、リソース割当プログラム、および、フロー処理システム
JP2010108409A (ja) * 2008-10-31 2010-05-13 Hitachi Ltd ストレージ管理方法及び管理サーバ
JP2010176192A (ja) * 2009-01-27 2010-08-12 Mitsubishi Electric Corp システム連携基盤設計支援方法、システム連携基盤設計支援装置および設計支援プログラム
WO2010106861A1 (ja) * 2009-03-18 2010-09-23 株式会社日立製作所 サービス連携装置、プログラム、サービス連携方法及びサービス提供システム
JP2011044054A (ja) * 2009-08-24 2011-03-03 Fuji Xerox Co Ltd 情報処理システム、情報処理装置、及びプログラム
JP2011186531A (ja) * 2010-03-04 2011-09-22 Nec Corp Ｓｍｔ対応ｃｐｕを有する情報処理装置の消費電力低減方法、消費電力低減装置及び消費電力低減プログラム
US9116689B2 (en) 2010-03-04 2015-08-25 Nec Corporation Power consumption reduction method of swapping high load threads with low load threads on a candidate core of a multicore processor
JP2012137865A (ja) * 2010-12-24 2012-07-19 Toshiba Corp サービス提供システム、装置及びプログラム
JP2014007438A (ja) * 2012-06-21 2014-01-16 Ntt Comware Corp ノード管理装置、ノード管理方法、及びプログラム
JP2015225399A (ja) * 2014-05-26 2015-12-14 ソフトバンク株式会社 業務処理システム、業務処理能力の監視システムおよび監視方法

Also Published As

Publication number Publication date
US20070118414A1 (en) 2007-05-24
US8386636B2 (en) 2013-02-26

Similar Documents

Publication Publication Date Title
JP2007148469A (ja) ビジネスプロセス定義を用いた事前リソース割り当て方法
US11037077B2 (en) Dynamically optimized distributed cloud computing-based business process management (BPM) system
US8869165B2 (en) Integrating flow orchestration and scheduling of jobs and data activities for a batch of workflows over multiple domains subject to constraints
US7788375B2 (en) Coordinating the monitoring, management, and prediction of unintended changes within a grid environment
Leff et al. Meeting service level agreements in a commercial grid
US9009294B2 (en) Dynamic provisioning of resources within a cloud computing environment
Jindal et al. Function delivery network: Extending serverless computing for heterogeneous platforms
CA2621946C (en) Improvements in and relating to service oriented architecture
Tsai et al. RTSOA: real-time service-oriented architecture
US20070266029A1 (en) Recovery segment identification in a computing infrastructure
US9996888B2 (en) Obtaining software asset insight by analyzing collected metrics using analytic services
US9672545B2 (en) Optimizing license use for software license attribution
Baur et al. A provider-agnostic approach to multi-cloud orchestration using a constraint language
US7490077B2 (en) Extensible dependency management framework and method
Mukhopadhyay et al. Qos based framework for effective web services in cloud computing
Chaturvedi et al. Cost-effective sharing of streaming dataflows for IoT applications
Zerva et al. Towards design support for provenance awareness: A classification of provenance questions
Akram et al. Managing changes to virtual enterprises on the semantic web
Ranaldo et al. A framework for qos-based resource brokering in grid computing
Sheshasaayee et al. SLA based utility analysis for improving QoS in cloud computing
Guo et al. Enabling QoS for service-oriented workflow on GRID
Al-Wesabi et al. Improving performance in component based distributed systems
US11113119B2 (en) Managing computer resources
Vasile et al. Evaluation of cloud systems
Nastic Self-Provisioning Infrastructures for the Next Generation Serverless Computing

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20070315

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20090813

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20090825

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20091023

A02 Decision of refusal

Free format text: JAPANESE INTERMEDIATE CODE: A02

Effective date: 20100323

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20100622

A911 Transfer to examiner for re-examination before appeal (zenchi)

Free format text: JAPANESE INTERMEDIATE CODE: A911

Effective date: 20100701

A912 Re-examination (zenchi) completed and case transferred to appeal board

Free format text: JAPANESE INTERMEDIATE CODE: A912

Effective date: 20100716