JP2009140079A - リソースの運用管理方法、運用管理プログラム、および、運用管理装置 - Google Patents

Abstract

【課題】呼び出されるサービスの実行時に使用するリソースを割り当てるときに、リソースの利用効率を高めつつ、サービスの実行時間を短縮すること。
【解決手段】リソース割当部２２は、通知されたサービス呼出通知の項目内容を、その項目内容を含む所定のリソース量見積もり式で評価することにより、通知されたサービス呼出通知のリソース要求量を求め、リソース割当量計算部２３は、リソース割当部２２が計算したリソース要求量をサービス実行装置４ごとに集計することで、各サービス実行装置４に割り当てるリソース要求量を求め、仮想計算機実行装置３に求めたリソース要求量分のリソース割当を要求し、リソース解放部２４は、リソース割当部２２が計算したリソース要求量分のリソース割当を解除する旨を、仮想計算機実行装置３に要求する。
【選択図】図５

Description

本発明は、リソースの運用管理方法、運用管理プログラム、および、運用管理装置に関するものである。

ＳＯＡ（Service Oriented Architecture）に基づき、複数のサービスを連携させてＢＰ（Business Process）として実行する技術が、知られている。ＢＰとは、開始イベント、終了イベント、サービス呼び出しアクティビティ、並行処理や分岐処理を行うためのゲートウェイ、などの各要素をフローで接続して構成される。ＢＰはサービス呼び出しアクティビティを介して各サービスを呼び出す。呼び出されたサービスは、割り当てられたＣＰＵなどの計算機資源（以下、単にリソースとする）を利用して、サービスの処理を実行する。

特許文献１は、ＢＰを対象にプロビジョニングを行い、サービスの実行前（事前）にサービスへリソースを割り当てる方法を開示している。この方法により、あらかじめ予想した高負荷に耐えうるだけの十分な計算機リソースを用意しておくため、予想の範囲内であれば実行時にリソース配分を意識せずともサービスの品質が確保される。

一方、複数のサーバマシンをクラスタ構成にして負荷分散を行い、サービスの品質を確保する技術が普及している。例えば、特許文献２では、限られたリソースを有効利用するため、サービスの実行後（事後）に負荷の高くなったサーバクラスタに対して動的にサーバを追加して、サービス品質を確保するグリッド技術が開示されている。
特開２００７−１４８４６９号公報 特開２００５−３２２４２号公報

高品質なＢＰ実行システムを構築するためには、サービスの実行時に使用するリソースの利用効率を高めることと、サービスの実行に要する実行時間を短くすることが、求められる。リソースの利用効率を向上することにより、サービスの提供者は、多くのＢＰを処理できる（換言すると、スループットが向上する）ため、収益率が高まるというメリットを得る。サービスの利用者は、自分のサービスの実行時間が少なくて済むので、利便性が向上するというメリットを得る。よって、この両方の性能（利用効率、実行時間）をバランス良く向上させることが、求められる。

しかし、前記した各従来の技術は、両方の性能のうち、片方を向上させるとその副作用としてもう片方の性能が低下してしまったため、バランスが悪かった。

事前割当方式（特許文献１など）では、プロビジョニングによる初期リソースの分配は、一時的な負荷の上昇に耐えるためにそれぞれのサービスに最大のリソースを割り当てねばならず、リソース効率が悪かった。

事後割当方式（特許文献２など）では、実行時間が長くなってしまう。具体的には、実行時に負荷の高いサービスへリソースを分配するのでサービスが稼動する装置を所定の時間観測した場合の負荷の上昇または下降を契機としてリソースを分配するため、サーバマシンの負荷の上昇または下降とリソースの分配の間には少なくとも観測時間分の遅れが生じてしまう。そのため、リソースの追加が間に合わず、スループット（単位時間当たりに処理可能なＢＰの分量）が十分にあがらなかったり、リソースの削減が間に合わずリソースが必要なほかのサービスにリソースが割り当てられなかったりし、一時的にだが全体の効率を下げてしまうことがある。

また、事後割当方式では、サービスが稼動するサーバ実行装置の負荷のみで計算機リソース追加・削減の判断を行なうため、適切なリソース配分となっていない場合がある。たとえば、２つのサービスＡ、Ｂを仮定し、どちらのサービスも高負荷になっているとする。従来技術では表面上の負荷の割合が同じならば双方に同じだけのリソースを割り振る。しかし、サービスＡは１００件処理をしており、Ｂは５０件しか処理をしておらず、どちらも１件あたりの負荷が同じだとすると、サービスＡには、サービスＢの２倍のリソースを割り振るべきである。

そこで、本発明は、前記した問題を解決し、呼び出されるサービスの実行時に使用するリソースを割り当てるときに、リソースの利用効率を高めつつ、サービスの実行時間を短縮することを主な目的とする。

前記課題を解決するため、本発明は、サービス実行装置が実行するサービスを呼び出すためのアクティビティを含むＢＰを実行するとともに、サービスを呼び出すためのサービス呼出通知、および、そのサービス呼出通知への応答であるサービス応答通知をイベントとして監視するＢＰ実行装置と、
前記サービス実行装置をリソースの動的割当が可能な仮想計算機として構築する仮想計算機実行装置と、
各前記サービス実行装置へのリソース割当量を管理する運用管理装置と、を用いるＢＰ実行システムにおけるリソースの運用管理方法であって、
前記運用管理装置が、ＢＰ実行状態受信部、リソース割当部、リソース割当量計算部、および、リソース解放部を有し、
前記ＢＰ実行状態受信部が、前記ＢＰ実行装置からイベントを受信したときに、前記サービス呼出通知のイベントを前記リソース割当部へ、前記サービス応答通知のイベントを前記リソース解放部へそれぞれ通知し、
前記リソース割当部が、通知された前記サービス呼出通知の項目内容を、その項目内容を含む所定のリソース量見積もり式で評価することにより、通知された前記サービス呼出通知のサービスを実行するために要するリソース要求量を求め、
前記リソース割当量計算部が、前記リソース割当部が計算したリソース要求量を前記サービス実行装置ごとに集計することで、各前記サービス実行装置に割り当てるリソース要求量を求め、前記仮想計算機実行装置に求めたリソース要求量分のリソース割当を要求し、
前記リソース解放部が、通知された前記サービス応答通知に対応する前記サービス呼出通知をもとに前記リソース割当部が計算したリソース要求量分のリソース割当を解除する旨を、前記仮想計算機実行装置に要求することを特徴とする。
その他の手段は、後記する。

本発明によれば、呼び出されるサービスの実行時に使用するリソースを割り当てるときに、リソースの利用効率を高めつつ、サービスの実行時間を短縮することができる。

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

図１は、ＢＰ実行システムを示す構成図である。ＢＰ実行システムは、ＢＰ実行装置１、運用管理装置２、仮想計算機実行装置３（１つ以上のサービス実行装置４を構成する）、および、ユーザ端末５がネットワーク９で相互に接続されて構成される。
ＢＰ実行装置１は、ユーザ端末５からのユーザ依頼の通知を受け、ＢＰを実行する。実行されたＢＰは、各サービス実行装置４が提供するサービスを呼び出す。
運用管理装置２は、ＢＰ実行装置１からのサービス呼び出しに関するイベント通知を受け、各サービス実行装置４に割り当てるリソース割当量を計算し、その結果を基にリソース割当およびリソース解除を指示する。
仮想計算機実行装置３は、各サービス実行装置４を構成するとともに、各サービス実行装置４に割り当てるリソースを提供する。
サービス実行装置４は、ＢＰ実行装置１が実行するＢＰから呼び出されたサービスを実行する。
ユーザ端末５は、ユーザからの入力を元に作成されたユーザ依頼の通知を、ＢＰ実行装置１に送信する。
ネットワーク９はＬＡＮ（Local Area Network）などのローカルネットワークであっても、ＷＡＮ（Wide Area Network）やインターネットなどのグローバルネットワークであってもよい。

図２は、ＢＰ実行装置１を示す構成図である。
ＢＰ実行装置１は、通信制御装置１０１ａ、ＣＰＵ１０２ａ、主記憶装置１０４ａ、二次記憶装置１０５ａ、システムバス１０６ａ、入力装置１０７ａ、および、出力装置１０８ａを備える。
通信制御装置１０１ａは、ＣＰＵ１０２ａの指示に従いネットワーク９上のメッセージを送受信する。
ＣＰＵ１０２ａは、二次記憶装置１０５ａに対して情報の読み出しおよび格納を指示するとともに、主記憶装置１０４ａに格納された各処理部を実行する。
主記憶装置１０４ａは、各処理部（ＢＰ実行部１１、ＢＰ定義読出部１２、ＢＰ実行状態監視部１３）に加え、それらを動作させるためのオペレーティングシステム１０３ａを格納する。主記憶装置１０４ａは、各処理部の処理に関するデータ（受信した情報や計算した結果値など）を格納する。なお、主記憶装置１０４ａに格納される各処理部は、プログラムとして実装する代わりに、ＡＳＩＣ（Application Specific Integrated Circuit）などのハードウェアとして実装してもよい。
二次記憶装置１０５ａは、ＢＰ定義格納部１６と、サービス管理テーブル１７と、を格納する。
システムバス１０６ａは、ＢＰ実行装置１の各構成要素を接続し、互いに通信可能とする。
入力装置１０７ａは、ユーザからのデータの入力を受け付けるためのキーボードやマウスなどで構成される。
出力装置１０８ａは、ユーザへのデータを提示するためのディスプレイなどで構成される。

図３は、運用管理装置２を示す構成図である。
運用管理装置２は、通信制御装置１０１ｂ、ＣＰＵ１０２ｂ、主記憶装置１０４ｂ、二次記憶装置１０５ｂ、システムバス１０６ｂ、入力装置１０７ｂ、および、出力装置１０８ｂを備える。
通信制御装置１０１ｂは、ＣＰＵ１０２ｂの指示に従いネットワーク９上のメッセージを送受信する。
ＣＰＵ１０２ｂは、二次記憶装置１０５ｂに対して情報の読み出しおよび格納を指示するとともに、主記憶装置１０４ｂに格納された各処理部を実行する。
主記憶装置１０４ｂは、各処理部（ＢＰ実行状態受信部２１、リソース割当部２２、リソース割当量計算部２３、リソース解放部２４）に加え、それらを動作させるためのオペレーティングシステム１０３ｂを格納する。主記憶装置１０４ｂは、各処理部の処理に関するデータ（受信した情報や計算した結果値など）を格納する。なお、主記憶装置１０４ｂに格納される各処理部は、プログラムとして実装する代わりに、ＡＳＩＣなどのハードウェアとして実装してもよい。
二次記憶装置１０５ｂは、ＢＰ実行状態管理テーブル２６、サービス実行状態管理テーブル２７、サービススペックテーブル２８、ＢＰフロー格納部２９を格納する。
システムバス１０６ｂは、運用管理装置２の各構成要素を接続し、互いに通信可能とする。
入力装置１０７ｂは、ユーザからのデータの入力を受け付けるためのキーボードやマウスなどで構成される。
出力装置１０８ｂは、ユーザへのデータを提示するためのディスプレイなどで構成される。

図４は、仮想計算機実行装置３を示す構成図である。
仮想計算機実行装置３は、通信制御装置１０１ｃ、ＣＰＵ１０２ｃ、主記憶装置１０４ｃ、二次記憶装置１０５ｃ、システムバス１０６ｃ、入力装置１０７ｃ、および、出力装置１０８ｃを備える。
通信制御装置１０１ｃは、ＣＰＵ１０２ｃの指示に従いネットワーク９上のメッセージを送受信する。
ＣＰＵ１０２ｃは、二次記憶装置１０５ｃに対して情報の読み出しおよび格納を指示するとともに、主記憶装置１０４ｃに格納された各処理部を実行する。
主記憶装置１０４ｃは、各処理部（サービス実行装置４を構成する仮想計算機管理部３１、リソース分配部３２）に加え、それらを動作させるためのオペレーティングシステム１０３ｃを格納する。主記憶装置１０４ｃは、各処理部の処理に関するデータ（受信した情報や計算した結果値など）を格納する。なお、主記憶装置１０４ｃに格納される各処理部は、プログラムとして実装する代わりに、ＡＳＩＣなどのハードウェアとして実装してもよい。
二次記憶装置１０５ｃは、リソース管理テーブル３６を格納する。
システムバス１０６ｃは、仮想計算機実行装置３の各構成要素を接続し、互いに通信可能とする。
入力装置１０７ｃは、ユーザからのデータの入力を受け付けるためのキーボードやマウスなどで構成される。
出力装置１０８ｃは、ユーザへのデータを提示するためのディスプレイなどで構成される。

サービス実行装置４は、サービスを実行するＡＰ（Application Server）の機能を有する仮想計算機である。仮想計算機は、仮想計算機実行装置３の各ハードウェア資源をリソースとして動的に追加または削除して処理能力を変更させることができる。よって、各仮想計算機は、仮想計算機実行装置３の各ハードウェア資源を、あたかも自装置に搭載されたものとして、実行する処理に提供する。

サービス実行装置４は、サービスの処理内容ごとに存在する。サービス実行装置４は、サービス呼出通知に応じてサービスを実行し、その結果をサービス応答通知に含めて返答する。なお、サービス呼出通知およびサービス応答通知は、ネットワーク９を介してＨＴＴＰ（Hyper Text Transfer Protocol）や、ＳＯＡＰ（Simple Object Access Protocol）などの形式のメッセージのやり取りにより実現される。

図５は、図１のＢＰ実行システムについて、機能に着目した構成図である。

ＢＰ実行部１１は、ユーザ端末５からのユーザ依頼通知を受け付けると、ＢＰ定義読出部１２を介して、ＢＰ定義格納部１６からＢＰ定義情報を読み出し、インスタンス化する。ＢＰ実行部１１は、各インスタンスに対して、他のインスタンスと区別するためのインスタンスＩＤを割り当てる。

以下、ユーザ依頼通知の一例をＸＭＬ（eXtensible Markup Language）形式で示す。このユーザ依頼通知は、「U1234」で識別されるユーザが、「I0501」の商品１つと、「I0502」の商品２つとを、「My Express」のカードで買うことを示している。
<order userid="U1234">
<defrayment type="card">
<card number="1234-5678-9012-3456" company="My Express" />
<expiration month="10" year="07" />
</defrayment >
<items>
<item1 id="I0501" quantity="1"/>
<item2 id="I0102" quantity="2"/>
</items>
</order>

図６は、ＢＰ定義格納部１６に格納されているＢＰ定義の一例を示す説明図である。ＢＰ「決済出荷」３００は、商品の決済および出荷を行うため、サービス群３１０の各サービスを呼び出す。サービス群３１０は、サービス「代金計算」３１１、サービス「カード決済」３１２、サービス「代引配送」３１３、および、サービス「通常配送」３１４を有する。

サービス「代金計算」３１１は、商品の種類、数および決済方法によって代金を求め、その結果を返すサービスである。このサービスは商品の種類が多くなるほど、処理に必要なリソース量が増える。

以下、サービス「代金計算」３１１へのサービス呼出通知の一例を示す。このサービス呼出通知は、「I0501」の商品１つと、「I0502」の商品２つとを、カードで買うときの代金計算を行う旨を示している。
<getPrice>
<settlement type="card" />
<items>
<item1 id="I0501" quantity="1"/>
<item2 id="I0102" quantity="2"/>
</items>
</getPrice>

以下、サービス「代金計算」３１１からのサービス呼出応答の一例を示す。このサービス呼出応答は、代金が「25000」円であることを示している。
<price value="25000" />

サービス「カード決済」３１２は、カード情報と代金を元に、カード決済を行なうサービスである。このサービスは、カードの種類によって処理に必要なリソース量が異なる。

以下、サービス「カード決済」３１２へのサービス呼出通知の一例を示す。このサービス呼出通知は、「U1234」で識別されるユーザが、代金「25000」円分のカード決済を、「My Express」のカードで実施することを示している。
<pay userid="U1234">
<defrayment type="card">
<card number="1234-5678-9012-3456"
company="My Express" />
<expiration month="10" year="07" />
<price value="25000" />
</defrayment >
</pay>

以下、サービス「カード決済」３１２からのサービス呼出応答の一例を示す。このサービス呼出応答は、カード決済が成功（OK）した旨を示している。
<result value="OK" />

サービス「代引配送」３１３は、代引指定で商品の配送を指示するサービスである。このサービスは商品の種類が多くなるほど、処理に必要なリソース量が増える。サービス「通常配送」３１４は、商品の配送を指示するサービスである。このサービスは商品の種類が多くなるほど、処理に必要なリソース量が増える。

ＢＰ「決済出荷」３００は、要素３０１〜要素３０８と、各要素の順序を規定する矢印（シーケンスフロー）により構成される。つまり、ＢＰ「決済出荷」３００は、要素３０１から要素３０８に向けて、矢印の方向へ順に処理する。なお、各要素は、ＢＰＭＮ（Business Process Modeling Notation）の記述法に従っている。

要素３０１は、ユーザ端末５からのユーザ依頼通知を受け付けることを契機とする、ＢＰ「決済出荷」３００の開始イベントである。

要素３０２は、サービス「代金計算」３１１のサービス呼び出しアクティビティである。要素３０２では、要素３０１で受け付けたユーザ依頼通知を元に生成されたサービス呼出通知を、サービス「代金計算」３１１へ送信し、そのサービスの実行結果としてサービス応答通知を得る。

要素３０３は、要素３０４または要素３０６のいずれか一方へ分岐するＸＯＲゲートウェイ（排他的判断）である。要素３０３では、要素３０１のユーザ依頼通知中の決済の種類を元に、カード決済ならば要素３０４へ分岐し、代引決済ならば要素３０６へ分岐する。なお、前記した一例では、「My Express」のカードで買うので、要素３０４へ分岐する。

要素３０４は、サービス「カード決済」３１２のサービス呼び出しアクティビティである。ここでは、要素３０１でのカード決済に関する情報と、要素３０２での代金計算の結果とをもとに、サービス呼出通知を作成する。

要素３０５は、サービス「通常配送」３１４のサービス呼び出しアクティビティである。ここでは、要素３０１での通常配送に関する情報（配送先住所を特定するためのユーザＩＤなど）をもとに、サービス呼出通知を作成する。

要素３０６は、サービス「代引配送」３１３のサービス呼び出しアクティビティである。ここでは、要素３０１での代引決済に関する情報と、要素３０２での代金計算の結果とをもとに、サービス呼出通知を作成する。

要素３０７は、要素３０３に対応するＸＯＲゲートウェイ（排他併合）である。
要素３０８は、要素３０１に対応する終了イベントである。

表１のＢＰフロー格納部２９（図５参照）は、図６のＢＰ「決済出荷」３００の概要（フローに関する部分）を抽出したものである。ＢＰフロー格納部２９は、「ＢＰ名」と、「要素ＩＤ」と、「次要素ＩＤ」と、「要素種類」と、「サービス名」とを対応づけて管理する。
「ＢＰ名」は、ＢＰ定義格納部１６に格納されているＢＰ定義を特定する名称である。
「要素ＩＤ」は、ＢＰ定義の各構成要素を特定する。
「次要素ＩＤ」は、「要素ＩＤ」の要素から、矢印を辿ることにより、次に実行する要素を特定する。
「要素種類」は、「要素ＩＤ」の要素の種類（分類）を示す。
「サービス名」は、「要素種類」がサービス呼び出しアクティビティであるときに、呼び出し先のサービスを特定する。

図５に戻り、ＢＰ実行部１１は、読み出したＢＰ定義情報中のフローの定義に従ってＢＰのインスタンスを実行する。ここで、ＢＰ実行部１１は、ＢＰ定義中のサービス呼び出しアクティビティを実行するときに、サービス管理テーブル１７を参照して、呼び出し先のサービスを実行するためのサービス実行装置４を特定する。

表２のサービス管理テーブル１７は、ＢＰが呼び出す「サービス名」と、サービスが稼動している「サービス実行装置４のＩＤ」との対応関係を管理するものであり、管理者が設定する。

ＢＰ実行状態監視部１３は、ＢＰ実行部１１が実行するＢＰのインスタンスの実行状態を監視する。そして、ＢＰ実行状態監視部１３は、サービス実行前にＢＰ実行部１１により作成されるサービス呼出通知、および、サービス実行後にサービス実行装置４により作成されるサービス応答通知を、それぞれ検知してその内容をＢＰ実行状態受信部２１にイベントとして送信する。

ＢＰ実行状態受信部２１は、ＢＰ実行状態監視部１３から通知されたイベントについて、そのイベントの内容が、サービス呼出通知であるときにはリソース割当部２２へ、サービス応答通知であるときにはリソース解放部２４へ、それぞれ転送する。リソース割当部２２およびリソース解放部２４は、それぞれ通知されたイベントに従い、ＢＰ実行状態管理テーブル２６を更新する。

表３のＢＰ実行状態管理テーブル２６は、イベントの特定情報（インスタンスＩＤ、ＢＰ名、要素ＩＤ、サービス名）と、そのイベントの「要素ＩＤ」のサービス呼び出しアクティビティからのサービス呼出通知によって呼び出されるサービスの実行に要する「リソース要求量」と、を対応づけて管理する。リソース割当部２２は、ＢＰ実行状態管理テーブル２６に対してレコードを追加し、リソース解放部２４は、ＢＰ実行状態管理テーブル２６からレコードを削除する。

なお、リソース割当部２２は、ＢＰ実行状態管理テーブル２６に追加するレコードの「リソース要求量」を計算するときに、サービススペックテーブル２８と、前記したＢＰフロー格納部２９とを参照する。

表４のサービススペックテーブル２８は、「サービス名」ごとに、過去の統計情報である「平均リソース使用量／件」と、サービス呼出通知の内容に応じて計算するための「リソース見積もり式／件」と、を対応づけて管理する。
「サービス名」は、ＢＰフロー格納部２９に格納されているＢＰ定義より管理者が設定する。
「平均リソース使用量／件」は、実機による動作テストを実施した結果を、管理者が設定する。
「リソース見積もり式／件」は、サービス呼出通知によりサービスの必要とするリソースが変化する場合に、サービス呼出通知に対応するリソースを見積もる式であり、管理者が定義し入力する。

リソース割当量計算部２３は、リソース割当部２２により更新されたＢＰ実行状態管理テーブル２６のレコードをもとに、リソース割当部２２からの指示により、サービス実行状態管理テーブル２７を更新する。

表５のサービス実行状態管理テーブル２７は、サービス名と、初期リソース割当量と、リソース要求量と、リソース過不足と、リソース割当量と、を対応づけて管理する。
「サービス名」は、ＢＰ定義格納部１６に格納されているＢＰ定義から、管理者が設定する。
「初期リソース割当量」は、実機による動作テストを実施し管理者が設定する。
「リソース要求量」、「リソース過不足」、「リソース割当量」は、それぞれリソース割当量計算部２３が計算して設定する。「リソース過不足」の値が正の場合、既に割り当てられている「初期リソース割当量」が、サービスの実行に要する「リソース要求量」に対して余っている。一方、「リソース過不足」の値が負の場合、既に割り当てられている「初期リソース割当量」が、サービスの実行に要する「リソース要求量」に対して不足している。

サービス実行装置４は、呼び出されるサービスの実行に要するリソースを、仮想計算機管理部３１（図４参照）から割り当てられる。リソース分配部３２は、サービス実行状態管理テーブル２７の「リソース割当量」をもとに設定されたリソース管理テーブル３６の「リソース割当量」を参照して、各サービス実行装置４にリソースを割り当てるよう、仮想計算機管理部３１に指示する。これにより、各サービス実行装置４は、サービスの実行に要するリソースの確保を適切な量だけ受けることができ、そのリソースを活用して効率的にサービスを実行することができる。

表６のリソース管理テーブル３６は、サービス実行装置４のＩＤごとに、割り当てる「リソース割当量」を示す。ここでの「リソース割当量」は、一例として合計が１００％となるＣＰＵ使用率が示されている。サービス実行装置４のＩＤは、管理者が設定する。「リソース割当量」は、リソース割当量計算部２３からサービス実行状態管理テーブル２７が更新されたときに、その更新された値が通知される。

図７（ａ）は、リソース割当部２２が、サービス呼出通知のリソースを見積もる処理を示すフローチャートである。

まず、ＢＰ実行状態監視部１３が送信したイベント通知（サービス呼出通知）を、ネットワーク９を介して受信する（Ｓ１０１）。サービス呼出通知は、「インスタンスＩＤ」、「ＢＰ名」、「要素ＩＤ」を含む。

次に、Ｓ１０１で受信したサービス呼出通知の「ＢＰ名」と「要素ＩＤ」とに対応するレコードをＢＰフロー格納部２９から抽出し、そのレコードから「サービス名」を取り出す（Ｓ１０２）。そして、Ｓ１０２で取得した「サービス名」を持つレコードをサービススペックテーブル２８から抽出する（Ｓ１０３）。

ここで、Ｓ１０３で抽出したレコードの「リソース見積もり式／件」が存在するか否かを判定する（Ｓ１０４）。存在するときには（Ｓ１０４，Ｙｅｓ）、Ｓ１０３で抽出したレコードの「リソース見積もり式／件」に対して、サービス呼出通知の内容を判定し、得られた結果を「リソース要求量」とする（Ｓ１０６）。存在しないときには（Ｓ１０４，Ｎｏ）、Ｓ１０３で抽出したレコードの「平均リソース使用量／件」の値を「リソース要求量」とする（Ｓ１０５）。

Ｓ１０１で受信したサービス呼出通知に関するレコードを、ＢＰ実行状態管理テーブル２６に追加する（Ｓ１０７）。具体的には、Ｓ１０１で受信したサービス呼出通知（「インスタンスＩＤ」、「ＢＰ名」、「要素ＩＤ」）と、Ｓ１０２で取得した「サービス名」と、Ｓ１０５またはＳ１０６で計算した「リソース要求量」と、を対応づけるレコードを追加する。

そして、Ｓ１０７で追加したレコードについて、サービスへのリソース割当指示をするため、リソース割当量計算部２３を呼び出す（Ｓ１０８）。

図７（ｂ）は、リソース解放部２４が、図７（ａ）で割り当てたリソースについて、サービス呼出応答により不要となったので、リソースの割当を解除する処理を示すフローチャートである。

まず、ＢＰ実行状態監視部１３が送信したイベント通知（サービス呼出応答）を、ネットワーク９を介して受信する。サービス呼出応答は、「インスタンスＩＤ」、「ＢＰ名」、「要素ＩＤ」を含む（Ｓ２０１）。

次に、Ｓ２０１で受信したサービス呼出応答の「インスタンスＩＤ」と、「ＢＰ名」とに対応するレコードをＢＰ実行状態管理テーブル２６から抽出し、そのレコードを削除する（Ｓ２０２）。そして、サービスへのリソース割当解除指示をするため、リソース割当量計算部２３を呼び出す（Ｓ２０３）。

図８〜図１０は、リソース割当量計算部２３が、サービスに割り当てるリソースを計算するフローチャートである。図８のフローチャートは、Ｓ１０８またはＳ２０３から呼び出されたときに実行される。図９，図１０のフローチャートは、図８の各処理から呼ばれるサブルーチンである。

まず、リソース割当量計算部２３の呼び出し時に渡される「サービス名」を取得する（Ｓ３０１）。Ｓ３０１で取得した「サービス名」のレコードをＢＰ実行状態管理テーブル２６から取り出し、取り出したレコードの「リソース要求量」の値の総和を計算し（Ｓ３０２）、その結果をサービス実行状態管理テーブル２７のＳ３０１で取得した「サービス名」のレコードの「リソース要求量」に書き込む。

次に、サービス実行状態管理テーブル２７のすべてのレコードについて、サービス実行状態管理テーブル２７の「リソース過不足」を、「リソース過不足」＝「初期リソース割当量」−「リソース要求量」により計算する（Ｓ３０３）。そして、サービス実行状態管理テーブル２７のすべてのレコードについて、「リソース過不足」が負の値のものの総和を取り、その総和の絶対値をリソース不足分を示す変数「Ｘ」とする（Ｓ３０４）。

ここで、３種類の「リソース割当量」の計算法から１つの計算法を選択するための分岐を行う。

まず、未割当のリソースでリソース要求量をまかなえるとき（Ｓ３０５，Ｙｅｓ）、未割当のリソースでリソース要求量をまかなうように、サービス実行状態管理テーブル２７の各レコードの「リソース割当量」を計算する（Ｓ３０６）。なお、Ｓ３０５は、判定式「Ｘ≦リソース未割当量」を満たすときに、Ｙｅｓとなる。ここで、リソース未割当量とは、１００％から「初期リソース割当量」の総和を引いたもので、リソース不足に備えて予め余らせておく未割当のリソースである。一方、未割当のリソースでリソース要求量をまかなえないとき（Ｓ３０５，Ｎｏ）、Ｓ３０７に進む。

次に、リソースの移動をしてリソース要求量をまかなえるとき（Ｓ３０７，Ｙｅｓ）、既に所定のサービス実行装置４に割り当てられたリソースを、別のサービス実行装置４に移動することで、リソース要求量をまかなうように、サービス実行状態管理テーブル２７の各レコードの「リソース割当量」を計算する（Ｓ３０８）。なお、Ｓ３０７は、サービス実行状態管理テーブル２７の「リソース要求量」の総和が全体のリソース量（１００％）を下回るときに、Ｙｅｓとなる。

一方、Ｓ３０７でＮｏなら、要求されたリソース全部はまかなえないものの、各サービス実行装置４へのリソース要求量の比率に応じ、サービス実行状態管理テーブル２７の各レコードの「リソース割当量」を計算する（Ｓ３０９）。

以上、「リソース割当量」がいずれかの計算法で計算された後、サービス実行状態管理テーブル２７のすべてのレコードについて、Ｓ３０１の「サービス名」から対応するサービス管理テーブル１７の「サービス実行装置４のＩＤ」を取得し、取得した「サービス実行装置４のＩＤ」に対応するリソース管理テーブル３６の「リソース割当量」について、更新されたサービス実行状態管理テーブル２７の「リソース割当量」の値を書き込む（Ｓ３１０）。

そして、書き込まれたリソース管理テーブル３６の「リソース割当量」に基づいて、リソース分配部３２に対して、仮想計算機管理部３１にリソース割当を行うように指示する（Ｓ３１１）。

図９は、Ｓ３０６の詳細を示すフローチャートである。

サービス実行状態管理テーブル２７の各レコードについて順に選択し、選択したレコードの「リソース割当量」を設定するループを実行する（Ｓ３０６１〜Ｓ３０６５）。

選択したレコードの「リソース過不足」が負の場合（Ｓ３０６２，Ｙｅｓ）、レコードの「リソース要求量」をそのままレコードの「リソース割当量」に設定する。これにより、リソース要求量に対して初期リソース割当量が不足しているサービスに対して、リソース要求量分のリソースを確保する（Ｓ３０６３）。

選択したレコードの「リソース過不足」が負でない場合（Ｓ３０６２，Ｎｏ）、レコードの「初期リソース割当量」をそのままレコードの「リソース割当量」に設定する。これにより、初期リソース割当量分のリソースを確保する（Ｓ３０６４）。

図１０（ａ）は、Ｓ３０８の詳細を示すフローチャートである。

まず、変数「Ｙ」を計算する。変数「Ｙ」は、サービスに割り当てられているが使用されないリソース量の総和を示す（Ｓ３０８１）。変数「Ｙ」は、サービス実行状態管理テーブル２７のすべてのレコードについて、「リソース過不足」の値が正のものの総和として計算される。

次に、変数「Ｚ」を計算する。変数「Ｚ」は、リソースが余っているサービスからリソースが足りないサービスへ、どの割合でリソースを移動するかを表す値である（Ｓ３０８２）。変数「Ｚ」は、Ｘの絶対値（｜Ｘ｜）をもとに、計算式「Ｚ＝１−（（｜Ｘ｜−リソース未割当量）／Ｙ）」により、計算される。

ここで、サービス実行状態管理テーブル２７の各レコードについて順に選択し、選択したレコードの「リソース割当量」を設定するループを実行する（Ｓ３０８３〜Ｓ３０８７）。

選択したレコードの「リソース過不足」が負の場合（Ｓ３０８４，Ｙｅｓ）、選択したレコードの「リソース要求量」をそのままレコードの「リソース割当量」に設定する。これにより、リソース要求量に対して初期リソース割当量が不足しているサービスに対して、リソース要求量分のリソースを確保する（Ｓ３０８５）。

選択したレコードの「リソース過不足」が負でない場合（Ｓ３０８４，Ｎｏ）、選択したレコードの「リソース要求量」＋「リソース過不足」＊Ｚを、レコードの「リソース割当量」に設定する。これにより、レコードに対応するサービスに割り当たっているが使用されないリソースの一部または全部を、リソースが不足しているサービスに移動する（Ｓ３０８６）。

図１０（ｂ）は、Ｓ３０９の詳細を示すフローチャートである。

まず、変数「Ｚ」を計算する。変数「Ｚ」は、要求するリソース量の何割をサービスに割り当てるかを表す（Ｓ３０９１）。具体的には、サービス実行状態管理テーブル２７のすべてのレコードについて、「リソース要求量」の総和を計算し、計算式「Ｚ＝１００％／「リソース要求量」の総和」により、変数「Ｚ」を計算する。

そして、サービス実行状態管理テーブル２７の各レコードについて順に選択し、選択したレコードの「リソース割当量」を設定するループを実行する（Ｓ３０９２〜Ｓ３０９４）。このループにおいて、選択したレコードの「リソース要求量」＊Ｚを、「リソース割当量」に設定する（Ｓ３０９３）これにより、これにより要求された性能は出ないものの、どこか一カ所がボトルネックなり、処理が進まないといった事態が避けられる。

以下、フローチャートを用いて説明した各処理について、図６のＢＰ定義を元にした実例を用いて詳細に説明する。

まず、サービス呼出通知内容のばらつきなどによりサービス実行装置４への負荷が増大したときに、未使用のリソースを割り当てることで、効率的にサービスを実行する例を説明する。

ＢＰ実行装置１は、ユーザ端末５からユーザ依頼を受け、ＢＰ定義をインスタンス化して実行する。このときのインスタンスＩＤは「＃１１３」が割り振られ（表３参照）、処理が進行中だとする。

ＢＰ実行状態監視部１３は、サービス「カード決済」３１２に対するサービス呼出通知のアクティビティ（要素３０４）を実行する前に、そのサービス呼出通知の内容がＢＰ実行部１１によって作成されたとき、そのサービス呼出通知をイベントとしてＢＰ実行状態受信部２１に通知する。このときサービス呼出通知には、呼び出すサービス「カード決済」３１２の特定情報に加え、インスタンスＩＤ「＃１１３」、ＢＰ名「決済出荷ＢＰ」、要素ＩＤ「＃５」が含まれる。

リソース割当部２２は、イベントを受け（Ｓ１０１）、リソースの見積もりを実施する。サービススペックテーブル２８のサービス名「カード決済」を含むレコードの「リソース見積もり式／件」は、「カードの種類について、「MY CB」なら１％、「MY Express」なら１０％」である。そして、受信したイベント（サービス呼出通知）には、カードの種類が「MY Express」である旨が記述されているので、リソース要求量を１件あたり「１０％」と計算する（Ｓ１０６）。

このリソース要求量「１０％」は、表３のＢＰ実行状態管理テーブル２６のサービス呼出通知の内容であるインスタンスＩＤ「＃１１３」、ＢＰ名「決済出荷ＢＰ」、要素ＩＤ「＃５」、サービス名「カード決済」で特定されるレコードの「リソース要求量」列に書き込まれる（Ｓ１０７）。そして、リソースを要求するために、Ｓ１０１でのサービス名「カード決済」を通知して、リソース割当量計算部２３にリソース割当を指示する（Ｓ１０８）。

表３のＢＰ実行状態管理テーブル２６、および、表５のサービス実行状態管理テーブル２７は、Ｓ１０８から実行されるＳ３０１からＳ３０４まで完了した時点の例を示している。サービス実行状態管理テーブル２７の「リソース過不足」（Ｓ３０３）を集計した変数「Ｘ」は−３５％となり（Ｓ３０４）、リソース未割当量は「初期リソース割当量」の総和が７０％であるため、３０％となる。よって、Ｓ３０５でＮｏとなり、Ｓ３０７でＹｅｓとなるので、Ｓ３０８の計算法により、「リソース割当量」が計算される。

Ｓ３０８の計算法では、変数「Ｙ」は１５％となり（Ｓ３０８１）、変数「Ｚ」は０．６７となる（Ｓ３０８２）。そして、Ｓ３０８３からＳ３０８７までのループを実行することで、表５に示すサービス実行状態管理テーブル２７の「リソース割当量」がそれぞれ計算される。この計算された「リソース割当量」に基づいて、サービスへリソースが割り当てられる（Ｓ３１０，Ｓ３１１）。

以上説明したように、サービス「カード決済」３１２の呼び出しが追加されたことにより、サービス「カード決済」３１２はリソース不足になるところであった。しかし、サービススペックテーブル２８の「リソース見積もり式／件」を元にした高精度の「リソース要求量」の計算（Ｓ１０６）の結果により、未割当のリソースを融通することで、リソース不足を回避することができる。

また、サービス呼び出しアクティビティ実行前に、サービスへのリソース割当を実施するため、サービス呼出通知時には必要なリソース量が確保された状態で実行が開始でき、リソース割当のタイムラグによる一時的な処理効率の低下を回避できる。

一方、単純な方法である「平均リソース使用量／件」に処理件数を乗じる場合（Ｓ１０５）では、おおざっぱに計算された「リソース要求量」の精度が低いので、リソース不足が生じてしまう。例えば、表４のサービススペックテーブル２８のサービス名「カード決済」に対応する「平均リソース使用量／件」の３％を参照した場合でも、本来要求するべきリソースが３０％なのに対して、２３％しか要求しないことになる。フローチャートの各ステップを実行すると、初期リソース割当量である２５％が、サービス「カード決済」３１２に割り当てられる。よって、３０％−２５％＝５％分のリソースが不足することになる。

次に、サービス実行装置４への負荷が増大したことで、システム全体のリソース不足が発生したときに、サービスの実行に必要なリソースを適切な比率で振り分けることにより、ボトルネックの発生（スループットの低下など）を抑制する例を説明する。まず、ＢＰ実行装置１が、ユーザ端末５からユーザ依頼の通知を受け、ＢＰ定義をインスタンス化して実行する。このときのインスタンスＩＤは「＃１１３」が割り振られる。

表７のサービス実行状態管理テーブル２７は、サービス「カード決済」３１２のサービス呼出通知アクティビティ（要素３０４）の実行前で、Ｓ３０４まで完了した時点のデータ内容を示す。変数「Ｘ」は−４０％（Ｓ３０４）、「リソース要求量」の総和は１１０％となるので、（Ｓ３０５，Ｎｏ）および（Ｓ３０７，Ｎｏ）により、Ｓ３０９の計算法が選択される。そして、Ｓ３０９の計算法では、変数「Ｚ」は０．９１となり（Ｓ３０９１）、ループ（Ｓ３０９２〜Ｓ３０９４）を実行すると、表７のサービス実行状態管理テーブル２７の「リソース割当量」が得られる。

以上説明したように、サービス「カード決済」３１２の呼び出しが追加されたことにより、サービス「カード決済」３１２がリソース不足になったが、システム全体でリソースを融通することにより、一部のサービスの実行速度が極端に遅くなり、スループットが低下するなどといった事態を防ぐことができた。

一方、リソースの事前割当を行なって、同様のリソース不足になった場合は、ボトルネックが発生してしまう。つまり、事前割当がなされているサービス「代引配送」３１３による買い物の場合は正常に動作するが、事前割当がなされていないサービス「カード決済」３１２による買い物の場合はリソース不足によりＢＰの実行処理が２倍以上遅くなり、さらに未使用のリソースを活用できない。

さらに、現在のサービス実行装置４の負荷に応じてリソースを割り当てる方法でも、ボトルネックが発生してしまう。つまり、システム全体でリソース不足になった場合に、本来必要なリソース量に応じたリソースを振り分けることができず、サービス「カード決済」３１２で処理が滞留してしまう。

図１１は、本実施形態のリソース割当方式の顕著な効果を示す説明図である。図１１（ａ）は、各リソース割当方式について、時間軸におけるリソース割当量の変化を示すグラフである。
方式（１）は、本実施形態におけるサービス呼出通知の内容をもとにサービススペックテーブル２８を用いた見積もり方式である。サービス呼出通知からサービス応答通知までのサービスの実行中に、必要分だけのリソースが割り当てられる。
方式（２）は、比較例として、サービスの実行に伴う負荷増大による、リソースの事後（実行後）割当方式である。負荷増大を検知するたびに、リソースが適宜追加されるので、グラフは階段状になる。
方式（３）は、比較例として、サービスの実行前（事前）割当として、割当可能なリソースのうち、最大分をあらかじめ割り当てる方式である。リソース割当量は、サービスの実行にかかわらず不変である。
方式（４）は、比較例として、サービスの実行前（事前）割当として、割当可能なリソースのうち、過去に使用された平均分をあらかじめ割り当てる方式である。リソース割当量は、サービスの実行にかかわらず不変である。

図１１（ｂ）は、図１１（ａ）の各リソース割当方式について、２つの評価軸を元にした効果を比較する表である。以下に示すように、本実施形態の方式（１）は、他の方式に比べ、２つの評価軸ともに高評価であるという顕著な効果を有する。

まず、評価軸「リソース利用効率」は、サービスの実行中ではないとき（サービスの実行外）に、余分なリソースを割り当てないほど、良いと評価される。方式（１）（２）は、サービスの実行外にはリソースを割り当てないので、良い旨の評価である。一方、方式（４）は、サービスの実行外に少量のリソースが割り当てられているのでやや悪く、方式（３）は、サービスの実行外に多量（最大分）のリソースが割り当てられているので悪い。

次に、評価軸「サービス処理時間」は、サービスの実行中に、その実行に要するリソースが多く割り当てられているほど、短いと評価される。方式（１）（３）は、サービスの実行中に充分なリソースが割り当てられるので、短い旨の評価である。一方、方式（２）は、サービスの実行中にリソースが徐々に割り当てられるのでやや長く、方式（４）は、サービスの実行中にリソースが少量（平均量）しか割り当てられないので長い。

以上説明した本実施形態では、サービスに必要なリソース量を事前に見積もり、それを元にリソースを逐次配分する機構を用意する。サービスに必要なリソース量はサービス呼出通知ごとに刻々と変化するため、ＢＰを適切なタイミングで監視する。

さらに、サービスを呼び出す際のサービス呼出通知により必要なリソース量が変化することがあるため、サービス呼出通知から必要なリソース量を計算する。サービスに必要なリソース量がもともと割り当てていたリソース量を上回った場合、対象のサービスにリソースを追加する。

これにより、サービスの実行に必要なリソースを事前に求め、その結果に基づいてサービスへリソースを割り振るため、リソース割当のタイムラグを防ぐとともに、リソース不足が発生した場合に、適切なリソースの追加を実行することができる。

本発明の一実施形態に関するＢＰ実行システムを示す構成図である。 本発明の一実施形態に関するＢＰ実行システムのＢＰ実行装置を示す構成図である。 本発明の一実施形態に関するＢＰ実行システムの運用管理装置を示す構成図である。 本発明の一実施形態に関するＢＰ実行システムの仮想計算機実行装置を示す構成図である。 本発明の一実施形態に関するＢＰ実行システムの機能を示す構成図である。 本発明の一実施形態に関するＢＰ定義の一例を示す説明図である。 本発明の一実施形態に関するリソースの割当処理および解除処理を示すフローチャートである。 本発明の一実施形態に関するサービスに割り当てるリソースの計算処理を示すフローチャートである。 本発明の一実施形態に関するサービスに割り当てるリソースの計算処理を示すフローチャートである。 本発明の一実施形態に関するサービスに割り当てるリソースの計算処理を示すフローチャートである。 本発明の一実施形態に関するリソース割当方式の顕著な効果を示す説明図である。

符号の説明

１ ＢＰ実行装置
２ 運用管理装置
３ 仮想計算機実行装置
４ サービス実行装置
５ ユーザ端末
９ ネットワーク
１１ ＢＰ実行部
１２ ＢＰ定義読出部
１３ ＢＰ実行状態監視部
１６ ＢＰ定義格納部
１７ サービス管理テーブル
２１ ＢＰ実行状態受信部
２２ リソース割当部
２３ リソース割当量計算部
２４ リソース解放部
２６ ＢＰ実行状態管理テーブル
２７ サービス実行状態管理テーブル
２８ サービススペックテーブル
２９ ＢＰフロー格納部
３１ 仮想計算機管理部
３２ リソース分配部
３６ リソース管理テーブル

Claims (9)

1. サービス実行装置が実行するサービスを呼び出すためのアクティビティを含むＢＰ（Business Process）を実行するとともに、サービスを呼び出すためのサービス呼出通知、および、そのサービス呼出通知への応答であるサービス応答通知をイベントとして監視するＢＰ実行装置と、
   前記サービス実行装置をリソースの動的割当が可能な仮想計算機として構築する仮想計算機実行装置と、
   各前記サービス実行装置へのリソース割当量を管理する運用管理装置と、を用いるＢＰ実行システムにおけるリソースの運用管理方法であって、
   前記運用管理装置は、ＢＰ実行状態受信部、リソース割当部、リソース割当量計算部、および、リソース解放部を有し、
   前記ＢＰ実行状態受信部は、前記ＢＰ実行装置からイベントを受信したときに、前記サービス呼出通知のイベントを前記リソース割当部へ、前記サービス応答通知のイベントを前記リソース解放部へそれぞれ通知し、
   前記リソース割当部は、通知された前記サービス呼出通知の項目内容を、その項目内容を含む所定のリソース量見積もり式で評価することにより、通知された前記サービス呼出通知のサービスを実行するために要するリソース要求量を求め、
   前記リソース割当量計算部は、前記リソース割当部が計算したリソース要求量を前記サービス実行装置ごとに集計することで、各前記サービス実行装置に割り当てるリソース要求量を求め、前記仮想計算機実行装置に求めたリソース要求量分のリソース割当を要求し、
   前記リソース解放部は、通知された前記サービス応答通知に対応する前記サービス呼出通知をもとに前記リソース割当部が計算したリソース要求量分のリソース割当を解除する旨を、前記仮想計算機実行装置に要求することを特徴とする
   リソースの運用管理方法。
2. 前記リソース割当部は、項目内容の種別毎にリソース量を特定する前記リソース量見積もり式をもとに、前記リソース要求量を求めることを特徴とする
   請求項１に記載のリソースの運用管理方法。
3. 前記リソース割当部は、項目内容の数値と所定数との積によりリソース量を特定する前記リソース量見積もり式をもとに、前記リソース要求量を求めることを特徴とする
   請求項１に記載のリソースの運用管理方法。
4. 前記リソース割当部は、サービスの呼び出し件数と所定数との積によりリソース量を特定する前記リソース量見積もり式をもとに、前記リソース要求量を求めることを特徴とする
   請求項１に記載のリソースの運用管理方法。
5. 前記リソース割当量計算部は、どの前記サービス実行装置からも使用されていない前記仮想計算機実行装置の未使用リソースから、前記リソース要求量分のリソース割当を要求することを特徴とする
   請求項１ないし請求項４のいずれか１項に記載のリソースの運用管理方法。
6. 前記リソース割当量計算部は、既に前記サービス実行装置に割り当てられたが、そのサービス実行装置へのリソース要求量を超過した余剰割当リソースから、前記リソース要求量分のリソース割当を要求することを特徴とする
   請求項１ないし請求項４のいずれか１項に記載のリソースの運用管理方法。
7. 前記リソース割当量計算部は、所定の前記サービス実行装置に割り当てるリソース要求量を求めた後、その求めたリソース要求量が各前記サービス実行装置に割り当てるリソース要求量の総量における比率を計算し、求めたリソース要求量と計算した比率との積に相当するリソース要求量分のリソース割当を要求することを特徴とする
   請求項１ないし請求項４のいずれか１項に記載のリソースの運用管理方法。
8. 請求項１ないし請求項７のいずれか１項に記載のリソースの運用管理方法を、前記運用管理装置に実行させるためのリソースの運用管理プログラム。
9. サービス実行装置が実行するサービスを呼び出すためのアクティビティを含むＢＰ（Business Process）を実行するとともに、サービスを呼び出すためのサービス呼出通知、および、そのサービス呼出通知への応答であるサービス応答通知をイベントとして監視するＢＰ実行装置と、
   前記サービス実行装置をリソースの動的割当が可能な仮想計算機として構築する仮想計算機実行装置と、
   各前記サービス実行装置へのリソース割当量を管理する運用管理装置と、を用いるＢＰ実行システムにおけるリソースの前記運用管理装置であって、
   前記運用管理装置は、ＢＰ実行状態受信部、リソース割当部、リソース割当量計算部、および、リソース解放部を有し、
   前記ＢＰ実行状態受信部は、前記ＢＰ実行装置からイベントを受信したときに、前記サービス呼出通知のイベントを前記リソース割当部へ、前記サービス応答通知のイベントを前記リソース解放部へそれぞれ通知し、
   前記リソース割当部は、通知された前記サービス呼出通知の項目内容を、その項目内容を含む所定のリソース量見積もり式で評価することにより、通知された前記サービス呼出通知のサービスを実行するために要するリソース要求量を求め、
   前記リソース割当量計算部は、前記リソース割当部が計算したリソース要求量を前記サービス実行装置ごとに集計することで、各前記サービス実行装置に割り当てるリソース要求量を求め、前記仮想計算機実行装置に求めたリソース要求量分のリソース割当を要求し、
   前記リソース解放部は、通知された前記サービス応答通知に対応する前記サービス呼出通知をもとに前記リソース割当部が計算したリソース要求量分のリソース割当を解除する旨を、前記仮想計算機実行装置に要求することを特徴とする
   リソースの運用管理装置。

Images