JP4866636B2 - 分散型プログラム実行環境における稼動品質管理方法 - Google Patents

Description

本発明は、一つ以上のサーバそれぞれに各種ソフトウェアコンポーネントを配備し、業務のフロー定義に従って各ソフトウェアコンポーネントを呼び出すことにより個々の業務の処理を実行するアプリケーションプログラム実行環境における稼動品質（処理速度、ソフトウェアコンポーネントレスポンスタイムなど）を管理する方法に関するものである。

各種サーバ上に散在するソフトウェアコンポーネントの機能を、ネットワークを介してクライアントから利用するという利用環境が広まっている。このような利用環境においては、同じ機能を利用する場合でも、各クライアントにより要求する品質が異なっている場合があるため、それに応じた品質でサービスを提供するための技術が必要となる。

このような課題に対して、例えば、特許文献１には、クライアントからサービスの要求を受け取ると、要求に対応するポリシー情報をポリシーデータベースから取得し、ポリシー情報に基づいて、サービスを実行するサーバを選択して階層的なサービスを構成し、選択されたサーバによるサービスの実行結果をクライアントに送信する技術が開示されている。

また、例えば、特許文献２には、クライアントとサーバ間でそれぞれに取り決められたサービスレベル合意に従った品質でサービスを提供するために、実際に提供しているサービスの品質をリアルタイムに監視してサービスレベル合意と比較し、サービスレベル合意を満たせない場合、管理者に警告を表示したり、クライアントに対する違約のリベートを自動生成する技術が開示されている。
特開２００５−５６０７９号公報 特開２００５−９２８８６号公報

上述のように、各機能を提供するソフトウェアコンポーネントが複数のサーバ上に散在し、クライアントはネットワークを介しサーバに処理要求することで、自分の必要な機能を利用するという利用形態が進展し、企業における業務アプリケーションなどでも利用されるようになりつつある。このような企業システムでの利用においては、クライアントが必要とする処理品質を極力確保する必要がある。

また、上記特許文献１においては、ポリシー情報に書かれた目標で実現できない事態が生じた場合の解決手法が開示されておらず、また、上記特許文献２においては、サービス合意を満たさない場合の具体的な解決手段が示されていない。

本発明の目的は、複数サーバでの分散型プログラム実行環境においてクライアントが必要とする処理品質（一例として、アプリケーションプログラムの全体実行を通した処理速度）を確保する稼働品質管理方法を提供することにある。

前記課題を解決するために、本発明は主として次のような手法を採用する。
複数のサーバのそれぞれに配備された１つ以上の各種ソフトウェアコンポーネントを順次呼び出して処理を実行するアプリケーションプログラムの稼働品質管理方法であって、
前記アプリケーションプログラムの実行フロー定義データを用いて前記アプリケーションプログラムを実行するソフトウェアコンポーネント群を特定し、
前記特定したソフトウェアコンポーネント群の少なくとも１つのソフトウェアコンポーネントが複数のサーバに配備されている場合に、それぞれのサーバで前記１つのソフトウェアコンポーネントの実行を依頼したと仮定して前記ソフトウェアコンポーネント群全体のそれぞれの処理量の見積もりを行い、
当該ソフトウェアコンポーネント群全体のそれぞれの処理量の見積もりに際して、各ソフトウェアコンポーネント間の処理引継ぎのための処理負荷、通信負荷を考慮して行い、
前記見積もった処理量に基づいて、前記１つのソフトウェアコンポーネントの配備された複数サーバの内でいずれか１つのサーバを依頼先として決定する手法とする。

また、前記アプリケーションプログラムの稼働品質管理方法において、前記ソフトウェアコンポーネント群全体のそれぞれの処理量の見積もりに際して、各ソフトウェアコンポーネントの処理に必要な各サーバの処理リソース量を考慮して行う。さらに、各ソフトウェアコンポーネントの処理量の見積もりが、前記サーバに設定された処理リソース量の許容量の閾値を越えている場合に、システム管理者に警告を表示する。さらに、各ソフトウェアコンポーネントの処理量の見積もりが、前記サーバに設定された処理リソース量の許容量の閾値を越えている場合に、当該サーバで実行することが予測されるソフトウェアコンポーネントのいずれかを他のサーバに配備し、前記の他のサーバに当該ソフトウェアコンポーネントの実行を依頼する。

本発明によると、或るソフトウェアコンポーネントの処理依頼を行う際に、その後引き続き実行されるソフトウェアコンポーネントまで考慮して、全体的な処理負荷、通信負荷を軽減する適切な依頼先サーバを選択することができる。

また、処理負荷の集中の予測を少し前の時点で行うことができるため、それに基づいて処理リソースの増強などの対応をシステム管理者に促したり、あるいは事前に自動的に増強処理を行うことができる。

本実施形態に係る分散型プログラム実行環境における稼働品質管理方法について、図面を参照しながら以下詳細に説明する。図１は分散型アプリケーションプログラム実行環境の全体構成を示すブロック図である。図２はアプリケーションプログラムの実行フロー定義データの一の例を示す図である。

また、図３はアプリケーションプログラムの稼働管理処理のフローを示す図である。図４はアプリケーションプログラムの実行フロー定義データの他の例を示す図である。図５はアプリケーションプログラムの実行フロー定義データの別の例を示す図である。図６は分散型アプリケーションプログラム実行環境の全体構成を示す他のブロック図である。図７は分散型アプリケーションプログラム実行環境で使用される情報処理装置のハードウェア構成を示す図である。

図面において、１００はクライアント装置、１０２は実行フロー定義データ、１０４は実行管理処理部、１０６は稼動管理処理部、１０８，１２２，１４２はメッセージング処理部、１２０，１４０はサーバ、１６０はネットワーク、１７０は待機系サーバ、７００は処理装置、７０２はメモリ、７０４は外部記憶装置、７０６はプログラム、７０８はデータ、７１０は入力装置、７１２は出力装置、をそれぞれ表す。

図１において、実行環境におけるアプリケーションプログラムの実行の流れについて説明する。図１の構成例では、クライアント装置１００、サーバ１２０およびサーバ１４０がネットワーク１６０を介して接続している。クライアント装置１００には、各アプリケーションプログラムの処理の流れを規定した実行フロー定義データ１０２が格納されている。ここで、実行フロー定義データは、アプリケーションの実行に必要なソフトウェアコンポーネントのフローを定義したデータである（このデータは後述する図２に示す）。

アプリケーションプログラム（いくつかのソフトウェアコンポーネントの連携により実行されるプログラム）は、対応する実行フロー定義データ１０２を指定して実行管理処理部１０４に処理要求を行うことで実行される。実行管理処理部１０４は指定された実行フロー定義データ１０２に従って実行位置（プログラムの進捗状況、例えば、図２に示すＰ位置）を管理し、次に実行するソフトウェアコンポーネントを特定する。実行管理処理部１０４は実行するソフトウェアコンポーネントを指定して、稼動管理処理部１０６に実行依頼先のサーバを問い合わせ、返答したサーバに対して、メッセージング処理部１０８，１２２または１４２を介してソフトウェアコンポーネント１２４，１２６，１４４，または１４６の実行を依頼する。

ソフトウェアコンポーネントの実行結果は逆の経路で実行管理処理部１０４に返され、実行管理処理部１０４はアプリケーションプログラムの実行位置を更新し、次の処理に進む。各サーバ１２０，１４０の稼動監視処理部１２８，１４８は、それぞれのソフトウェアコンポーネントの実行に関するデータを蓄積し、稼動管理処理部１０６から問い合わせを受けてデータを応答する。

図２は実行フロー定義データ１０２の一例を示す図である。図２の例は、サービスＡ、サービスＢ、サービスＣ（各ソフトウェアコンポーネントによって実行されるサービス）を逐次的に行う場合を図式形態で示したものであり、実行フロー定義データの表現形式に限定するものではなく、例えば、処理フローを規定するプログラム言語形式のデータであってもよい。

図１と図２に示した構成例と実行フロー定義データ例を用いて、稼動管理処理部１０６における処理の流れについて、図３を参照しながら以下説明する。

稼動管理処理部１０６は実行管理処理１０４から次処理の依頼先決定の要求を受け取る（ステップ３００）。このとき、対象アプリケーションプログラムの実行フロー定義データ１０２とその現在の実行位置（例えば、図２のＰ位置）を受け取る。ここで、実行位置はフローの一番最初であり、次処理はサービスＡであるという状況であるとする。

実行管理処理部１０４は受け取った実行フロー定義データ１０２と現在の実行位置から、次処理以降で実行するソフトウェアコンポーネントとして、サービスＡ、サービスＢ、サービスＣを特定し、その配備状況（サーバ１２０にはコンポーネントＡ，Ｃが配備され、サーバ１４０にはコンポーネントＡ，Ｂが配備されている状況）を収集する（ステップ３０２）。いま、サーバ１２０上に、サービスＡを提供するソフトウェアコンポーネント１２４およびサービスＣを提供するソフトウェアコンポーネント１２６が稼動しており、サーバ１４０上にサービスＡを提供するソフトウェアコンポーネント１４４およびサービスＢを提供するソフトウェアコンポーネント１４６が稼動している。

稼動管理処理部１０６は、コンポーネント間の引継ぎ処理の処理負荷、通信負荷も考慮して、次処理以降で実行するソフトウェアコンポーネント群全体の処理量の見積りを行う（ステップ３０４）。具体的には、次処理であるサービスＡがサーバ１２０、サーバ１４０の両方に配備されているので、それぞれに依頼した場合の処理量を見積もる。サービスＡの実行をサーバ１２０に依頼した場合、サービスＢはサーバ１４０にのみ配備されているのでサーバ１４０に依頼し、サービスＣはサーバ１２０に依頼することになる。一方、サービスＡをサーバ１４０に依頼する場合、引き続きのサービスＢもサーバ１４０に依頼し、サービスＣをサーバ１２０に依頼する。

処理量の見積り（ステップ３０４）に従って、いずれかのサーバに過剰な負荷が掛かる可能性があるかどうか判定する（ステップ３０６）。過剰な負荷が掛からない場合、ステップ３０８に進む。

いま、サービスＡの依頼先候補が複数あるので、ステップ３０４で行った処理量の見積りを比較する。処理の内容やその時点で各サーバがどの程度の処理要求を受け付けているかによってステップ３０２で収集される処理実勢値（ソフトウェアコンポーネントの現在の処理品質値（例、レスポンスタイムなど））の値が変化するため、定量的な見積り値も変化するが、例えば、ソフトウェアコンポーネント間（例えば、Ａ→Ｂ間）で受け渡しするデータ量が大きい場合、同一サーバ内でデータを受け渡す場合より、サーバ間で受け渡す場合の方が大きな通信負荷が掛かることが予測される。

この場合、サーバＡの実行をサーバ１４０に依頼する場合の方が、サーバ間での引継ぎが１回で済むため、全体の処理量が小さくて済むこととなる。このような比較により、サービスＡの実行依頼先をサーバ１４０に決定し、実行管理処理部１０４に回答する（ステップ３０８）。

なお、以上の説明では、最初に実行するソフトウェアコンポーネントＡが複数サーバに配備されている場合を例示して述べたが、これに限らず、２番目以降で実行するソフトウェアコンポーネントが複数サーバに配備されている場合にも同様に本実施形態を適用できるものであり、幾通りもあるソフトウェアコンポーネント群全体の処理量を事前に見積もって、見積もった処理負荷に基づいてソフトウェアコンポーネントで処理するサーバを決定するものである。

図７は、図１に示すクライアント装置１００、サーバ１２０，１４０、または待機系サーバ１７０（図６参照）に使用される情報処理装置のハードウェア構成図である。この情報処理装置は、メモリ７０２を内蔵した処理装置７００と、外部記憶装置７０４と、入力装置７１０と、出力装置７１２を備えている。外部記憶装置７０４には、実行管理処理部１０４、稼動管理処理部１０６などのプログラム７０６、および実行フロー定義データ１０２などのデータ７０８が格納されている。本発明の実施形態が提供する各機能は、処理装置７００がメモリ７０２にプログラム７０６およびデータ７０８を読み込んで処理を行うことにより実現される。また、クライアント装置の利用者やサーバの管理者からの入力を受け付ける入力装置７１０と、利用者への処理結果や管理者への警告表示を行う出力装置７１２を備えている。

図４は、実行フロー定義データ１０２の他の例である。図４のフローでは、サービスＡの実行結果によって条件判定を行い、条件が成立した場合に応じて、サービスＢ（Ｂ１，Ｂ２…Ｂｎ）が並行して複数実行され得る。そして、サービスＢ（Ｂ１，Ｂ２…Ｂｎ）の処理がすべて完了するとサービスＣを実行する。具体的に云えば、図４に示す定義データは条件分岐であって、サービスＡの実行結果によって、例えば、サービスＢ１のみ実行、又はサービスＢ１とＢ２を実行ということがあり，サービスＢを完了後にサービスＣに移行することとなる。この際、サービスＢ１とＢ２とはそれぞれに対応するソフトウェアコンポーネントに関連性があるとは限らない。

図４の例の場合で処理量の見積り（ステップ３０４）を、各処理に必要なリソース量（例えば、処理計算するのに必要なメモリ量）も考慮して行う。この例の場合、条件の成立状況次第ではサービスＢ（Ｂ１，Ｂ２…Ｂｎ）の並行処理数が多くなる可能性があり、サーバ１４０の処理リソースが大量になってネックが発生する場合が考えられる。よって、サービスＢ（Ｂ１，Ｂ２…Ｂｎ）だけがサーバ１４０で実行され、サービスＡとサービスＣがサーバ１２０で実行される方が処理負荷が偏らないため、サービスＡの実行依頼先をサーバ１４０ではなくてサーバ１２０とする。なお、サービスＢ１，Ｂ２…Ｂｎがサーバ１４０に存在するとして説明してきたが、これに限らず各々のサービスＢ１，Ｂ２…Ｂｎがサーバ１２０と１４０に分散配置されていてもよい。

さらに、図４の例のアプリケーションの処理要求が増加した場合、サーバ１４０で実行するサービスＢ（Ｂ１，Ｂ２…Ｂｎ）の処理負荷が大きくなり、サーバの許容量を越える可能性がある。この場合、ステップ３０６での判定で過剰な負荷が掛かると判定され、過剰な負荷が予測された場合の処理（ステップ３１０）を行う。

過剰負荷への対応としては、図６に示すように待機系のサーバ１７０を設けておくことが考えられる。サービスＡの依頼が増加した時点で、事前に待機系のサーバ１７０にサービスＢのソフトウェアコンポーネント１７６の配備を依頼し、サービスＢの要求の発生時点で、サービスＢの依頼先サーバを２つのサーバ１４０、１７０に振り分けることで負荷分散を行う。また、このような過負荷状況の発生予告を、システム運用管理者に警告するという運用も考えられる。

図４の例は、次処理以降に、実行確率が未定な（すなわち、サービスＢの実行がサービスＡの実行結果に依存するため）ソフトウェアコンポーネントが含まれる場合である。処理量の見積りに不確定な要素が含まれる他の例としては、図５（サービスＡの実行結果次第でサービスＢを１回実行するか複数回実行するかが決まる定義データ）のように、サービスＢが逐次実行で複数回実行されるが、その実行回数がサービスＡに実行結果に依存して決まる、というものもある。これらの場合、実行確率や実行回数が統計的に安定している場合、稼動監視処理部１２８，１４８で収集した各アプリケーションプログラム実行時の履歴データから実行比率や平均実行回数を求め、処理量の見積りに利用することで、より精度の高い見積りを行うことができる。

以上述べたように、本発明の実施形態によればアプリケーションプログラムの実行フロー定義データや、各ソフトウェアコンポーネントの実行実勢値、過去の実行に関する統計情報を利用して、全体としての処理量を低減したり、過剰な負荷の発生を事前に予測して、処理リソースを準備するなどにより、安定した稼動を実現することができる。なお、本実施形態は図示したシステムの構成を限定するものではなく、クライアント装置、サーバの数はそれぞれいくつであってもよく、また、クライアント装置とサーバの両方の役割を兼ねた装置があってもよい。また、ネットワークを介して接続していればよく、複数の組織にまたがって連携するシステムであってもよい。繰り返して述べると、本発明の実施形態は、アプリケーションプログラムの実行フロー定義データから、次処理以降で実行するソフトウェアコンポーネント群を特定し、特定したソフトウェアコンポーネント群のうち、最初に実行するソフトウェアコンポーネントが複数のサーバに配備されており依頼するサーバの候補が複数ある場合に、それぞれのサーバにソフトウェアコンポーネントの実行を依頼したと仮定した場合の次処理以降のソフトウェアコンポーネント群全体の処理量の見積りを行い、予測される処理負荷の小さい方のサーバに処理を依頼することを主要な特徴とする。さらに、処理負荷の予測により、将来的にあるサーバへの処理負荷の集中が予測される場合、システム管理者に警告を表示して対処を促したり、負荷集中が予測されるサーバのソフトウェアコンポーネントを事前に別のサーバに動的に配備し、この別サーバに要求を行うことで処理負荷を分散させることを特徴とする。

本発明が適用される一例について説明すると、企業システムにおいては、自社内に複数サーバがあることが一般的で、それらのサーバ上のソフトウェアコンポーネントの機能を連携させることで業務アプリケーションを実現させるという形態が多くなりつつあり、このような環境において本発明を有効に利用可能である。また、企業間においても、互いにネットワークを介して連携した業務を行うということが増えつつあり、このような企業間連携のアプリケーションにおいても本発明を有効に利用することが可能である。

このように、本発明の実施形態は、次のような課題を解決し、構成を備えることを主たる特徴とするものである。すなわち、各機能を提供する複数のソフトウェアコンポーネントが複数のサーバ上に散在し、クライアントはネットワークを介し複数のサーバに処理要求することで、自分の必要な機能を各ソフトウェアコンポーネントで果たすという利用形態でクライアントがアプリケーションプログラムの実行で全体を通しての必要とする処理品質を確保しようとするものであり、アプリケーションプログラムの実行フロー定義データから、次処理（実行位置が図２のＰであればソフトウェアコンポーネントＡ）以降で実行するソフトウェアコンポーネント群（Ａ，Ｂ，Ｃ）を特定し、特定したソフトウェアコンポーネント群のうち、最初のソフトウェアコンポーネント（図２の例でＡ）の実行を依頼するサーバの候補が複数ある場合に、それぞれのサーバ（図１の例でサーバ１２０，１４０）にソフトウェアコンポーネントの実行を依頼したと仮定した場合の次処理以降のソフトウェアコンポーネント群全体（アプリケーションプログラムに対応）の処理量の見積りに基づいて依頼先サーバを決定する構成とする。

分散型アプリケーションプログラム実行環境の全体構成を示すブロック図。 アプリケーションプログラムの実行フロー定義データの一の例を示す図。 アプリケーションプログラムの稼働管理処理のフローを示す図。 アプリケーションプログラムの実行フロー定義データの他の例を示す図。 アプリケーションプログラムの実行フロー定義データの別の例を示す図。 分散型アプリケーションプログラム実行環境の全体構成を示す他のブロック図。 分散型アプリケーションプログラム実行環境で使用される情報処理装置のハードウェア構成を示す図。

符号の説明

１００ クライアント装置
１０２ 実行フロー定義データ
１０４ 実行管理処理部
１０６ 稼動管理処理部
１０８，１２２，１４２ メッセージング処理部
１２０，１４０ サーバ
１６０ ネットワーク
１７０ 待機系サーバ
７００ 処理装置
７０２ メモリ
７０４ 外部記憶装置
７０６ プログラム
７０８ データ
７１０ 入力装置
７１２ 出力装置

Claims (5)

1. 複数のサーバのそれぞれに配備された１つ以上の各種ソフトウェアコンポーネントを順次呼び出して処理を実行するアプリケーションプログラムの稼働品質管理方法であって、
   前記アプリケーションプログラムの実行フロー定義データを用いて前記アプリケーションプログラムを実行するソフトウェアコンポーネント群を特定し、
   前記特定したソフトウェアコンポーネント群の少なくとも１つのソフトウェアコンポーネントが複数のサーバに配備されている場合に、それぞれのサーバで前記１つのソフトウェアコンポーネントの実行を依頼したと仮定して前記ソフトウェアコンポーネント群全体のそれぞれの処理量の見積もりを行い、
   当該ソフトウェアコンポーネント群全体のそれぞれの処理量の見積もりに際して、各ソフトウェアコンポーネント間の処理引継ぎのための処理負荷、通信負荷を考慮して行い、
   前記見積もった処理量に基づいて、前記１つのソフトウェアコンポーネントの配備された複数サーバの内でいずれか１つのサーバを依頼先として決定する
   ことを特徴とするアプリケーションプログラムの稼働品質管理方法。
2. 請求項１において、
   前記ソフトウェアコンポーネント群全体のそれぞれの処理量の見積もりに際して、各ソフトウェアコンポーネントの処理に必要な各サーバの処理リソース量を考慮して行うことを特徴とするアプリケーションプログラムの稼働品質管理方法。
3. 請求項２において、
   各ソフトウェアコンポーネントの処理量の見積もりが、前記サーバに設定された処理リソース量の許容量の閾値を越えている場合に、システム管理者に警告を表示することを特徴とするアプリケーションプログラムの稼働品質管理方法。
4. 請求項２において、
   各ソフトウェアコンポーネントの処理量の見積もりが、前記サーバに設定された処理リソース量の許容量の閾値を越えている場合に、当該サーバで実行することが予測されるソフトウェアコンポーネントのいずれかを他のサーバに配備し、
   前記の他のサーバに当該ソフトウェアコンポーネントの実行を依頼する
   ことを特徴とした稼動品質管理方法。
5. 複数のサーバのそれぞれに配備された１つ以上の各種ソフトウェアコンポーネントを順次呼び出して処理を実行するアプリケーションプログラムの稼働品質管理を行うクライアント装置であって、
   前記アプリケーションプログラムの実行フロー定義データを用いて前記アプリケーションプログラムを実行するソフトウェアコンポーネント群を特定し、
   前記特定したソフトウェアコンポーネント群の少なくとも１つのソフトウェアコンポーネントが複数のサーバに配備されている場合に、それぞれのサーバで前記１つのソフトウェアコンポーネントの実行を依頼したと仮定して前記ソフトウェアコンポーネント群全体のそれぞれの処理量の見積もりを行い、
   当該ソフトウェアコンポーネント群全体のそれぞれの処理量の見積もりに際して、各ソフトウェアコンポーネント間の処理引継ぎのための処理負荷、通信負荷を考慮して行い、
   前記見積もった処理量に基づいて、前記１つのソフトウェアコンポーネントの配備された複数サーバの内でいずれか１つのサーバを依頼先として決定する
   ことを特徴とするアプリケーションプログラムの稼働品質管理を行うクライアント装置。

Images