(57)【要約】【課題】複数のサーバを連携させたシステムで、システム全体としてサービス品質要件を満たした処理を実現するサービス制御装置を提供する。【解決手段】メッセージ受信制御部１１０は、処理要求メッセージを受信し、メッセージキュー１３０に格納する。メッセージ重み計算部１２１は、処理要求メッセージに対するサーバでの処理量を計算する。スレッド１４２は、メッセージキュー１３０から処理要求メッセージを取り出し、サーバでの処理を実行させる。制御ルール決定部１５０は、処理要求メッセージのメッセージキュー滞留時間と、メッセージ重み計算部１２１で計算されたサーバでの処理量と、サービス品質性能保管部１６０の保管されたサービス品質要件とに基づいて、サービス品質要件を満たすように、メッセージキュー１３０のサイズと、スレッド１４２の並列処理数とを決定する。【選択図】図１
2008077266.tif 000002
【特許請求の範囲】
【請求項１】
処理要求メッセージの受信制御を行い、受信した処理要求メッセージをメッセージキューに格納するメッセージ受信制御部と、
前記処理要求メッセージの構造を利用してサーバでの処理時間を計算するためのルールを定めたメッセージ重みルールを記憶するメッセージ重み保管部を参照し、前記処理要求メッセージと、前記メッセージ重みルールとに基づいて、前記処理要求メッセージに対するサーバでの処理時間を計算するメッセージ重み計算部と、
前記処理要求メッセージをサーバに送信して処理を実行させるスレッドを複数有するスレッド群を制御するスレッド群制御部であって、前記処理要求メッセージに対して前記スレッドを割り当てると共に、前記スレッドの並列処理数を制御するスレッド群制御部と、
前記サーバで満たされるべき品質要件に関する品質要件情報を記憶する品質要件情報保管部を参照し、前記処理要求メッセージの前記メッセージキューでの滞留時間と、前記計算されたサーバでの処理時間と、前記品質要件情報とに基づいて、前記メッセージキューのサイズと、前記スレッド群制御部におけるスレッドの並列処理数の上限値とを制御する制御ルール決定部とを備えることを特徴とするサービス制御装置。
【請求項２】
前記制御ルール決定部は、前記メッセージの滞留時間と、前記計算されたサーバでの処理時間と、前記品質要件とに基づいて、前記処理要求メッセージに対する処理が品質要件を満たすか否かを判断し、満たさないと判断すると、前記メッセージキューのサイズ減少と、前記スレッドの並列処理数の上限値の減少との少なくとも一方を行う、請求項１に記載のサービス制御装置。
【請求項３】
前記制御ルール決定部は、前記処理要求メッセージに対する処理が前記品質要件を満たさないと判断すると、前記スレッドの並列処理数の上限値を減らし、該スレッドの並列処理数の上限値の減少後での前記サーバでの処理時間と、前記メッセージの滞留時間と、前記品質要件とに基づいて、前記スレッドの並列処理数の上限値が減少した状態における前記処理要求メッセージに対する処理が品質要件を満たすか否かを判断し、満たさないと判断すると、前記メッセージキューのサイズを減らす、請求項２に記載のサービス制御装置。
【請求項４】
前記制御ルール決定部は、前記メッセージの滞留時間と、前記計算されたサーバでの処理時間と、前記品質要件とに基づいて、前記処理要求メッセージに対する処理が品質要件を満たすか否かを判断し、満たすと判断すると、前記メッセージキューのサイズの増加と、前記スレッドの並列処理数の上限値の増加との少なくとも一方を行う、請求項１に記載のサービス制御装置。
【請求項５】
前記制御ルール決定部は、前記処理要求メッセージに対する処理が前記品質要件を満たすと判断すると、前記メッセージキューのサイズが所定の初期値よりも小さいか否かを調べ、前記初期値よりも小さいときには、前記メッセージキューのサイズを増やし、前記メッセージキューのサイズが前記初期値よりも小さくないときには、前記スレッドの並列処理数の上限値を増やす、請求項４に記載のサービス制御装置。
【請求項６】
前記スレッドは、前記サーバでの前記処理要求メッセージに対する処理の開始から処理の終了までの間の処理時間の実測値を計測し、前記制御ルール決定部は、前記計算されたサーバでの処理時間と、前記処理時間の実測値とに基づいて、前記計算されたサーバでの処理時間と前記処理時間の実測値との差が小さくなるように、前記メッセージ重みルールを補正する、請求項１〜５の何れか一に記載のサービス制御装置。
【請求項７】
前記メッセージ受信制御部は、前記処理要求メッセージを受信すると、前記メッセージキューに空きがあるか否かを判断し、空きがないと判断すると、空きが発生するまで前記処理要求メッセージの受信処理を遅延する、請求項１〜６の何れか一に記載のサービス制御装置。
【請求項８】
前記メッセージ受信制御部は、前記メッセージキューに処理要求メッセージを格納すると、該処理要求メッセージの送信元に、受信完了を示す応答を送信する、請求項７に記載のサービス制御装置。
【請求項９】
複数のサーバ間で処理要求メッセージを受け渡し、連携動作する分散サービス制御システムであって、
前記各サーバが、前記処理要求メッセージの入力段に、請求項１〜８の何れか一に記載のサービス制御装置を有することを特徴とする分散サービス制御システム。
【請求項１０】
サービス制御装置を用いて、サーバに対する処理要求メッセージを制御するサービス制御方法であって、
前記サービス制御装置が、処理要求メッセージを受信し、該受信した処理要求メッセージをメッセージキューに格納するメッセージ受信ステップと、
前記サービス制御装置が、前記処理要求メッセージの構造を利用してサーバでの処理時間を計算するためのルールを定めたメッセージ重みルールを記憶するメッセージ重み保管部を参照し、前記処理要求メッセージと、前記メッセージ重みルールとに基づいて、前記処理要求メッセージに対するサーバでの処理時間を計算するメッセージ重み計算ステップと、
前記サービス制御装置が、前記処理要求メッセージをサーバに送信して処理を実行させるスレッドを複数有するスレッド群を制御し、前記処理要求メッセージに対して前記スレッドを割り当てるスレッド割当てステップと、
前記サービス制御装置が、前記サーバで満たされるべき品質要件に関する品質要件情報を記憶する品質要件情報保管部を参照し、前記処理要求メッセージの前記メッセージキューでの滞留時間と、前記計算されたサーバでの処理時間と、前記品質要件情報とに基づいて、前記メッセージキューのサイズと、前記スレッドの並列処理数の上限値とを制御する制御ルール決定ステップとを有することを特徴とするサービス制御方法。
【請求項１１】
前記制御ルール決定ステップでは、前記サービス制御装置は、前記メッセージの滞留時間と、前記計算されたサーバでの処理時間と、前記品質要件とに基づいて、前記処理要求メッセージに対する処理が品質要件を満たすか否かを判断し、満たさないと判断すると、前記メッセージキューのサイズ減少と、前記スレッドの並列処理数の上限値の減少との少なくとも一方を行う、請求項１０に記載のサービス制御方法。
【請求項１２】
前記制御ルール決定ステップでは、前記サービス制御装置は、前記処理要求メッセージに対する処理が前記品質要件を満たさないと判断すると、前記スレッドの並列処理数の上限値を減らし、該スレッドの並列処理数の上限値の減少後での前記サーバでの処理時間と、前記メッセージの滞留時間と、前記品質要件とに基づいて、前記スレッドの並列処理数の上限値が減少した状態における前記処理要求メッセージに対する処理が品質要件を満たすか否かを判断し、満たさないと判断すると、前記メッセージキューのサイズを減らす、請求項１１に記載のサービス制御方法。
【請求項１３】
前記制御ルール決定ステップでは、前記サービス制御装置は、前記メッセージの滞留時間と、前記計算されたサーバでの処理時間と、前記品質要件とに基づいて、前記処理要求メッセージに対する処理が品質要件を満たすか否かを判断し、満たすと判断すると、前記メッセージキューのサイズの増加と、前記スレッドの並列処理数の上限値の増加との少なくとも一方を行う、請求項１０に記載のサービス制御方法。
【請求項１４】
前記制御ルール決定ステップでは、前記サービス制御装置は、前記処理要求メッセージに対する処理が前記品質要件を満たすと判断すると、前記メッセージキューのサイズが所定の初期値よりも小さいか否かを調べ、前記初期値よりも小さいときには、前記メッセージキューのサイズを増やし、前記メッセージキューのサイズが前記初期値よりも小さくないときには、前記スレッドの並列処理数の上限値を増やす、請求項１３に記載のサービス制御方法。
【請求項１５】
前記サービス制御装置が、前記スレッドにおける、前記サーバでの前記処理要求メッセージに対する処理の開始から処理の終了までの間の処理時間の実測値を計測するステップと、
前記サービス制御装置が、前記計算されたサーバでの処理時間と、前記処理時間の実測値とに基づいて、前記計算されたサーバでの処理時間と前記処理時間の実測値との差が小さくなるように、前記メッセージ重みルールを補正するステップとを更に有する、請求項１０〜１４の何れか一に記載のサービス制御方法。
【請求項１６】
前記メッセージ受信ステップでは、前記サービス制御装置は、前記処理要求メッセージを受信すると、前記メッセージキューに空きがあるか否かを判断し、空きがないと判断すると、空きが発生するまで前記処理要求メッセージの受信処理を遅延する、請求項１０〜１５の何れか一に記載のサービス制御方法。
【請求項１７】
前記メッセージ受信ステップでは、前記サービス制御装置は、前記メッセージキューに処理要求メッセージを格納すると、該処理要求メッセージの送信元に、受信完了を示す応答を送信する、請求項１６に記載のサービス制御方法。
【請求項１８】
コンピュータに、サーバに対する処理要求メッセージを制御する処理を実行させるプログラムであって、前記コンピュータに、
処理要求メッセージを受信し、該受信した処理要求メッセージをメッセージキューに格納するメッセージ受信ステップと、
前記処理要求メッセージの構造を利用してサーバでの処理時間を計算するためのルールを定めたメッセージ重みルールを記憶するメッセージ重み保管部を参照し、前記処理要求メッセージと、前記メッセージ重みルールとに基づいて、前記処理要求メッセージに対するサーバでの処理時間を計算するメッセージ重み計算ステップと、
前記処理要求メッセージをサーバに送信して処理を実行させるスレッドを複数有するスレッド群を制御し、前記処理要求メッセージに対して前記スレッドを割り当てるスレッド割当てステップと、
前記サーバで満たされるべき品質要件に関する品質要件情報を記憶する品質要件情報保管部を参照し、前記処理要求メッセージの前記メッセージキューでの滞留時間と、前記計算されたサーバでの処理時間と、前記品質要件情報とに基づいて、前記メッセージキューのサイズと、前記スレッドの並列処理数の上限値とを制御する制御ルール決定ステップとを実行させることを特徴とするプログラム。
【請求項１９】
前記制御ルール決定ステップでは、前記メッセージの滞留時間と、前記計算されたサーバでの処理時間と、前記品質要件とに基づいて、前記処理要求メッセージに対する処理が品質要件を満たすか否かを判断し、満たさないと判断すると、前記メッセージキューのサイズ減少と、前記スレッドの並列処理数の上限値の減少との少なくとも一方を行う、請求項１８に記載のプログラム。
【請求項２０】
前記制御ルール決定ステップでは、前記処理要求メッセージに対する処理が前記品質要件を満たさないと判断すると、前記スレッドの並列処理数の上限値を減らし、該スレッドの並列処理数の上限値の減少後での前記サーバでの処理時間と、前記メッセージの滞留時間と、前記品質要件とに基づいて、前記スレッドの並列処理数の上限値が減少した状態における前記処理要求メッセージに対する処理が品質要件を満たすか否かを判断し、満たさないと判断すると、前記メッセージキューのサイズを減らす、請求項１９に記載のプログラム。
【請求項２１】
前記制御ルール決定ステップでは、前記メッセージの滞留時間と、前記計算されたサーバでの処理時間と、前記品質要件とに基づいて、前記処理要求メッセージに対する処理が品質要件を満たすか否かを判断し、満たすと判断すると、前記メッセージキューのサイズの増加と、前記スレッドの並列処理数の上限値の増加との少なくとも一方を行う、請求項１８に記載のプログラム。
【請求項２２】
前記制御ルール決定ステップでは、前記処理要求メッセージに対する処理が前記品質要件を満たすと判断すると、前記メッセージキューのサイズが所定の初期値よりも小さいか否かを調べ、前記初期値よりも小さいときには、前記メッセージキューのサイズを増やし、前記メッセージキューのサイズが前記初期値よりも小さくないときには、前記スレッドの並列処理数の上限値を増やす、請求項２１に記載のプログラム。
【請求項２３】
前記コンピュータに、
前記スレッドにおける、前記サーバでの前記処理要求メッセージに対する処理の開始から処理の終了までの間の処理時間の実測値を計測するステップと、
前記計算されたサーバでの処理時間と、前記処理時間の実測値とに基づいて、前記計算されたサーバでの処理時間と前記処理時間の実測値との差が小さくなるように、前記メッセージ重みルールを補正するステップとを更に実行させる、請求項１８〜２２の何れか一に記載のプログラム。
【請求項２４】
前記メッセージ受信ステップでは、前記処理要求メッセージを受信すると、前記メッセージキューに空きがあるか否かを判断し、空きがないと判断すると、空きが発生するまで前記処理要求メッセージの受信処理を遅延する、請求項１８〜２３の何れか一に記載のプログラム。
【請求項２５】
前記メッセージ受信ステップでは、前記メッセージキューに処理要求メッセージを格納すると、該処理要求メッセージの送信元に、受信完了を示す応答を送信する、請求項２４に記載のプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、サービス制御装置、分散サービス制御システム、サービス制御方法、及び、プログラムに関し、更に詳しくは、処理要求メッセージを送受信して処理を行うサーバに対する処理要求メッセージの制御を行うサービス制御装置、方法、及び、プログラム、並びに、そのようなサービス制御装置を連携させた分散サービス制御システムに関する。
【背景技術】
【０００２】
ＸＭＬを初めとする計算機で処理しやすい構造化文書の普及に伴い、構造化文書メッセージの交換により、受注サーバ、在庫管理サーバ、配送サーバなどの一連の流れに沿ったサーバ連携による業務システムが普及しつつある。また、従来、各サーバにおいて、他のサーバから受信した複数の要求を、サーバ資源に余裕のある夜間時間帯などにまとめたバッチ処理を行う方法が広く用いられてきたが、業務要件として業務システム全体の処理時間を短縮化する即時性が求められるに連れ、各サーバにおいてバッチ処理から個々の要求の逐次処理に置き換わりつつある。
【０００３】
業務システムでは、特に、インターネットを通じた連携においては、電子メールをはじめとする様々な通信が同時に使用されるため、通信ネットワークの混雑状況はばらつきが大きく、また、相手サーバからの処理要求メッセージの送信パターンも均質ではない場合があり、同一時間に大量の処理要求メッセージが到着することがある。そのため、そのような状況にもサービス品質を保持するために、処理要求数・量の変動をシステムの設計段階で想定して、あらかじめ十分な性能のサーバを導入し、サービス品質を確保している。また、運用時には、動的な計算機資源の割当てや、特定処理要求の優先処理などを行って、サービス品質を確保している。
【０００４】
上記の問題を踏まえて、従来の分散ビジネスプロセスの実行を最適化するための技術の一例が、特許文献１に記載されている。特許文献１には、ビジネスプロセス処理において、プロセス定義とデータとをサーバ間で持ち回り、サーバとは独立したビジネスプロセス全体を制御する計算機ノードの導入を不要としている。また、複数の計算機ノードで実行されるワークフローの実行を最適化する技術の一例が、特許文献２に記載されている。特許文献２では、あらかじめ計算機の構成や性能、全体のワークフロー定義をワークフローサーバが集中管理し、ワークフローサーバにより、実行状態を監視しながら、実行配分を決定する。
【特許文献１】特開２００４−２５８８２３号公報
【特許文献２】特開２００２−２５９６３９号公報
【発明の開示】
【発明が解決しようとする課題】
【０００５】
従来技術の第１の問題点は、複数のサーバがメッセージ交換により連携して動作するシステムでは、連携フローの下流にあるサーバにおいて、サーバ性能を超える処理要求メッセージ数を受け付けて性能劣化が発生した場合に、サーバが連携したシステム全体での処理時間に関するサービス品質を保つことができないという点である。これは、下流に置かれるサーバで発生した性能劣化により、このサーバで処理要求メッセージを受け付けられなくなり、結果として、上流のサーバに下流のサーバ向けの処理要求プロセスが滞留し、下流サーバの性能劣化の影響が上位のサーバにも波及して、複数のサーバ全体での処理性能を見積もることが困難になるためである。
【０００６】
第２の問題点は、前記システムにおいて、単位時間当たりに到着する処理要求メッセージ数に比べて、十分に大きな処理要求メッセージ数を想定した余剰計算機資源を必要とするという点である。その理由は、ネットワークを通じた処理要求メッセージは、電子メールなどの様々な通信と共存により通信品質の差が生じやすいため、処理要求が均質に到着するとは限らないからである。特に、要求処理メッセージの到着が間欠的で一時に集中するバースト性を持つ場合もあるため、前記システムのように処理要求メッセージを逐次処理するシステムでは、十分な計算機資源が必要となる。
【０００７】
本発明は、上記従来技術の問題点を解消し、複数のサーバがメッセージ交換により連携して動作するシステムにおいて、システム全体としてサービス品質を満たした処理を実行できるサービス制御装置、方法、プログラム、及び、分散サービス制御システムを提供することを目的とする。
【０００８】
本発明の他の目的は、一時的に大量の処理要求メッセージがサーバに送信される場合でも、最小の計算機資源でサーバの処理不能を起こさないようにするサービス制御装置、方法、プログラム、及び、分散サービス制御システムを提供することである。
【０００９】
本発明の他の目的は、処理要求メッセージの増減の変動に俊敏に対応できるサービス制御装置、方法、プログラム、及び、分散サービス制御システムを提供することである。
【課題を解決するための手段】
【００１０】
上記目的を達成するために、本発明のサービス制御装置は、処理要求メッセージの受信制御を行い、受信した処理要求メッセージをメッセージキューに格納するメッセージ受信制御部と、前記処理要求メッセージの構造を利用してサーバでの処理時間を計算するためのルールを定めたメッセージ重みルールを記憶するメッセージ重み保管部を参照し、前記処理要求メッセージと、前記メッセージ重みルールとに基づいて、前記処理要求メッセージに対するサーバでの処理時間を計算するメッセージ重み計算部と、前記処理要求メッセージをサーバに送信して処理を実行させるスレッドを複数有するスレッド群を制御するスレッド群制御部であって、前記処理要求メッセージに対して前記スレッドを割り当てると共に、前記スレッドの並列処理数の上限値を制御するスレッド群制御部と、前記サーバで満たされるべき品質要件に関する品質要件情報を記憶する品質要件情報保管部を参照し、前記処理要求メッセージの前記メッセージキューでの滞留時間と、前記計算されたサーバでの処理時間と、前記品質要件情報とに基づいて、前記メッセージキューのサイズと、前記スレッド群制御部におけるスレッドの並列処理数の上限値とを制御する制御ルール決定部とを備えることを特徴とする。
【００１１】
本発明のサービス制御方法は、サービス制御装置を用いて、サーバに対する処理要求メッセージを制御するサービス方法であって、前記サービス制御装置が、処理要求メッセージを受信し、該受信した処理要求メッセージをメッセージキューに格納するメッセージ受信ステップと、前記サービス制御装置が、前記処理要求メッセージの構造を利用してサーバでの処理時間を計算するためのルールを定めたメッセージ重みルールを記憶するメッセージ重み保管部を参照し、前記処理要求メッセージと、前記メッセージ重みルールとに基づいて、前記処理要求メッセージに対するサーバでの処理時間を計算するメッセージ重み計算ステップと、前記サービス制御装置が、前記処理要求メッセージをサーバに送信して処理を実行させるスレッドを複数有するスレッド群を制御し、前記処理要求メッセージに対して前記スレッドを割り当てるスレッド割当てステップと、前記サービス制御装置が、前記サーバで満たされるべき品質要件に関する品質要件情報を記憶する品質要件情報保管部を参照し、前記処理要求メッセージの前記メッセージキューでの滞留時間と、前記計算されたサーバでの処理時間と、前記品質要件情報とに基づいて、前記メッセージキューのサイズと、前記スレッド群制御部におけるスレッドの並列処理数の上限値とを制御する制御ルール決定ステップとを有することを特徴とする。
【００１２】
本発明のプログラムは、コンピュータに、サーバに対する処理要求メッセージを制御する処理を実行させるプログラムであって、前記コンピュータに、処理要求メッセージを受信し、該受信した処理要求メッセージをメッセージキューに格納するメッセージ受信ステップと、前記処理要求メッセージの構造を利用してサーバでの処理時間を計算するためのルールを定めたメッセージ重みルールを記憶するメッセージ重み保管部を参照し、前記処理要求メッセージと、前記メッセージ重みルールとに基づいて、前記処理要求メッセージに対するサーバでの処理時間を計算するメッセージ重み計算ステップと、前記処理要求メッセージをサーバに送信して処理を実行させるスレッドを複数有するスレッド群を制御し、前記処理要求メッセージに対して前記スレッドを割り当てるスレッド割当てステップと、前記サーバで満たされるべき品質要件に関する品質要件情報を記憶する品質要件情報保管部を参照し、前記処理要求メッセージの前記メッセージキューでの滞留時間と、前記計算されたサーバでの処理時間と、前記品質要件情報とに基づいて、前記メッセージキューのサイズと、前記スレッド群制御部におけるスレッドの並列処理数の上限値とを制御する制御ルール決定ステップとを実行させることを特徴とする。
【００１３】
本発明のサービス制御装置、方法、及び、プログラムでは、受信した処理要求メッセージに対するサーバでの処理量と、処理要求メッセージのメッセージキュー滞留時間とに基づいて、所定のサービス品質要件が満たされるか否かを判断し、メッセージキューのサイズと、サーバでの並列処理数の上限値とを制御する。サーバにて、サービス品質要件が満たされるように、メッセージキューのサイズと並列処理数の上限値とを制御することで、例えば大量の処理要求メッセージが送信され、処理要求メッセージに対する処理がサービス品質要件を満たさなくなることが予想される場合には、メッセージキューのサイズを小さくして受信遅延を行って処理要求メッセージの入力数を抑制し、並列処理数の上限値を減少させることでサーバ負荷が増大することを防ぎ、サービス品質要件を満たした処理を実現する。また、処理能力に余裕があるときには、メッセージキューのサイズを大きくして処理要求メッセージの入力数を増加させ、並列処理数の上限値を増加させてサーバで処理される処理要求メッセージの数を増やす。このような制御を行うことで、サービス品質を満たしつつ、サーバの処理能力を最大限に引き出した処理を実現できる。
【００１４】
本発明のサービス制御装置では、前記制御ルール決定部は、前記メッセージの滞留時間と、前記計算されたサーバでの処理時間と、前記品質要件とに基づいて、前記処理要求メッセージに対する処理が品質要件を満たすか否かを判断し、満たさないと判断すると、前記メッセージキューのサイズ減少と、前記スレッドの並列処理数の上限値の減少との少なくとも一方を行う構成を採用できる。メッセージキューのサイズを小さくすると、メッセージ受信制御部が新規に受信する処理要求メッセージが遅延されることで、処理要求メッセージの入力数を抑制することができる。また、スレッドの並列処理数の上限値を減少させると、サーバでの並列処理数が減少して、サーバ負荷を下げることができ、個々の処理要求メッセージに対する処理時間を短くできる。これらにより、処理要求メッセージ受信してから、サーバでの処理を完了するまでの時間を短縮することができ、サービス品質要件を満たした処理を実現できる。
【００１５】
本発明のサービス制御装置では、前記制御ルール決定部は、前記処理要求メッセージに対する処理が前記品質要件を満たさないと判断すると、前記スレッドの並列処理数の上限値を減らし、該スレッドの並列処理数の上限値の減少後での前記サーバでの処理時間と、前記メッセージの滞留時間と、前記品質要件とに基づいて、前記スレッドの並列処理数の上限値が減少した状態における前記処理要求メッセージに対する処理が品質要件を満たすか否かを判断し、満たさないと判断すると、前記メッセージキューのサイズを減らす構成を採用できる。
【００１６】
本発明のサービス制御装置では、前記制御ルール決定部は、前記メッセージの滞留時間と、前記計算されたサーバでの処理時間と、前記品質要件とに基づいて、前記処理要求メッセージに対する処理が品質要件を満たすか否かを判断し、満たすと判断すると、前記メッセージキューのサイズの増加と、前記スレッドの並列処理数の上限値の増加との少なくとも一方を行う構成を採用できる。処理要求メッセージに対する処理が、品質要件を満たすときには、メッセージキューのサイズを大きくして処理要求メッセージの入力数を増やし、スレッドの並列処理数を増やして、サーバで同時に処理される処理要求メッセージ数を増やす。品質要件を満たす範囲で、処理要求メッセージの入力数、サーバでの処理の同時実行数を増やすことで、サーバ性能を最大限に活用することができる。
【００１７】
本発明のサービス制御装置では、前記制御ルール決定部は、前記処理要求メッセージに対する処理が前記品質要件を満たすと判断すると、前記メッセージキューのサイズが所定の初期値よりも小さいか否かを調べ、前記初期値よりも小さいときには、前記メッセージキューのサイズを増やし、前記メッセージキューのサイズが前記初期値よりも小さくないときには、前記スレッドの並列処理数の上限値を増やす構成を採用できる。品質要件を満たす場合であって、現在の状態が、メッセージキューのサイズを小さくして処理要求メッセージの入力数を抑制している状態であるときには、メッセージキューのサイズを大きくすることで、受信遅延を解除し、入力処理要求メッセージの抑制を解除する。また、入力処理要求メッセージの抑制を行っていない状態であるときには、スレッドの並列処理数の上限値を増加させて、サーバでの並列処理数を増加させる。このように制御することで、サーバ性能を最大限に活用できる。
【００１８】
本発明のサービス制御装置では、前記スレッドは、前記サーバでの前記処理要求メッセージに対する処理の開始から処理の終了までの間の処理時間の実測値を計測し、前記制御ルール決定部は、前記計算されたサーバでの処理時間と、前記処理時間の実測値とに基づいて、前記計算されたサーバでの処理時間と前記処理時間の実測値との差が小さくなるように、前記メッセージ重みルールを補正する構成を採用できる。この場合、受信した処理要求メッセージに基づいて計算されたサーバでの処理時間の精度を向上できる。
【００１９】
本発明のサービス制御装置では、前記メッセージ受信制御部は、前記処理要求メッセージを受信すると、前記メッセージキューに空きがあるか否かを判断し、空きがないと判断すると、空きが発生するまで前記処理要求メッセージの受信処理を遅延する構成を採用できる。この場合、前記メッセージ受信制御部は、前記メッセージキューに処理要求メッセージを格納すると、該処理要求メッセージの送信元に、受信完了を示す応答を送信する構成を採用できる。このようにする場合には、送信元のサーバでは、送信した処理要求メッセージがメッセージキューに格納されるまでメッセージ送信が完了しないことで、次の処理要求メッセージに対する処理を開始できない。これにより、メッセージキューのサイズに応じた受信遅延を行うことができ、メッセージキューのサイズに応じて、送信元サーバから送信される処理要求メッセージの数を抑制することができる。
【００２０】
本発明のサービス制御方法及びプログラムは、前記制御ルール決定ステップでは、前記メッセージの滞留時間と、前記計算されたサーバでの処理時間と、前記品質要件とに基づいて、前記処理要求メッセージに対する処理が品質要件を満たすか否かを判断し、満たさないと判断すると、前記メッセージキューのサイズ減少と、前記スレッドの並列処理数の上限値の減少との少なくとも一方を行う構成を採用できる。
【００２１】
本発明のサービス制御方法及びプログラムは、制御ルール決定ステップでは、前記処理要求メッセージに対する処理が前記品質要件を満たさないと判断すると、前記スレッドの並列処理数の上限値を減らし、該スレッドの並列処理数の上限値の減少後での前記サーバでの処理時間と、前記メッセージの滞留時間と、前記品質要件とに基づいて、前記スレッドの並列処理数の上限値が減少した状態における前記処理要求メッセージに対する処理が品質要件を満たすか否かを判断し、満たさないと判断すると、前記メッセージキューのサイズを減らす構成を採用できる。
【００２２】
本発明のサービス制御方法及びプログラムは、前記制御ルール決定ステップでは、前記メッセージの滞留時間と、前記計算されたサーバでの処理時間と、前記品質要件とに基づいて、前記処理要求メッセージに対する処理が品質要件を満たすか否かを判断し、満たすと判断すると、前記メッセージキューのサイズの増加と、前記スレッドの並列処理数の上限値の増加との少なくとも一方を行う構成を採用できる。
【００２３】
本発明のサービス制御方法及びプログラムは、前記制御ルール決定ステップでは、前記処理要求メッセージに対する処理が前記品質要件を満たすと判断すると、前記メッセージキューのサイズが所定の初期値よりも小さいか否かを調べ、前記初期値よりも小さいときには、前記メッセージキューのサイズを増やし、前記メッセージキューのサイズが前記初期値よりも小さくないときには、前記スレッドの並列処理数の上限値を増やす構成を採用できる。
【００２４】
本発明のサービス制御方法は、前記サービス制御装置が、前記スレッドにおける、前記サーバでの前記処理要求メッセージに対する処理の開始から処理の終了までの間の処理時間の実測値を計測するステップと、前記サービス制御装置が、前記計算されたサーバでの処理時間と、前記処理時間の実測値とに基づいて、前記計算されたサーバでの処理時間と前記処理時間の実測値との差が小さくなるように、前記メッセージ重みルールを補正するステップとを更に有する構成を採用できる。本発明のプログラムは、前記コンピュータに、前記スレッドにおける、前記サーバでの前記処理要求メッセージに対する処理の開始から処理の終了までの間の処理時間の実測値を計測するステップと、前記計算されたサーバでの処理時間と、前記処理時間の実測値とに基づいて、前記計算されたサーバでの処理時間と前記処理時間の実測値との差が小さくなるように、前記メッセージ重みルールを補正するステップとを更に実行させる構成を採用できる。
【００２５】
本発明のサービス制御方法及びプログラムは、前記メッセージ受信ステップでは、前記処理要求メッセージを受信すると、前記メッセージキューに空きがあるか否かを判断し、空きがないと判断すると、空きが発生するまで前記処理要求メッセージの受信処理を遅延する構成を採用できる。
【００２６】
本発明のサービス制御方法及びプログラムは、前記メッセージ受信ステップでは、前記メッセージキューに処理要求メッセージを格納すると、該処理要求メッセージの送信元に、受信完了を示す応答を送信する構成を採用できる。
【００２７】
本発明の分散サービス制御システムは、複数のサーバ間で処理要求メッセージを受け渡し、連携動作する分散サービス制御システムであって、前記各サーバが、前記処理要求メッセージの入力段に、上記本発明のサービス制御装置を有することを特徴とする。
【００２８】
本発明の分散サービス制御システムでは、サービス制御装置によって、各サーバにてサービス品質要件が満たされるように、メッセージキューのサイズ変更による受信遅延やスレッドの並列処理数の上限値が制御される。このため、システム全体として、サービス品質要件を満たした処理を実現できる。また、このとき、サーバ間の連携フローにて、隣接するサーバの分散サービス制御装置間で、受信遅延や並列処理数が相互に影響し、自動的に適切な実行配分に到達する。これにより、システム全体として、サービス品質要件を満たしつつ、各サーバの能力を活用した処理が実現できる。
【発明の効果】
【００２９】
本発明のサービス制御装置、方法、及び、プログラムでは、受信した処理要求メッセージに対するサーバでの処理量と、処理要求メッセージのメッセージキュー滞留時間とに基づいて、所定のサービス品質要件が満たされるか否かを判断し、メッセージキューのサイズと、サーバでの並列処理数の上限値とを制御する。サービス品質要件が満たせなくなると予想されるときには、処理要求メッセージの処理数を抑制し、満たせると予想されるときには、処理要求メッセージの処理数を増加させることで、サービス品質を満たしつつ、サーバの処理能力を最大限に引き出した処理を実現できる。
【００３０】
本発明の分散サービス制御システムでは、本発明のサービス制御装置が、各サーバでサービス品質を満たした処理を実現することで、システム全体として、サービス品質を満たした処理を実現できる。また、サーバ間の連携フローにて、隣接するサーバの分散サービス制御装置間で、受信遅延や並列処理数が相互に影響し、自動的に適切な実行配分に到達することで、システム全体として、サービス品質要件を満たしつつ、各サーバの能力を活用した処理が実現できる。
【発明を実施するための最良の形態】
【００３１】
以下、図面を参照し、本発明の実施の形態を詳細に説明する。図１は、本発明の一実施形態の分散サービス制御装置の構成を示している。分散サービス制御装置１００は、メッセージ受信制御部１１０、メッセージ状態管理部１２０、メッセージキュー１３０、処理要求管理部１４０、制御ルール決定部１５０、及び、サービス品質性能保管部１６０を有する。分散サービス制御装置１００は、複数のサーバがメッセージ交換により連携して動作するシステム中に、サービスを実行するサーバ（メッセージ処理部）の前段に中継装置として配置され、処理要求メッセージの送信及び受信を中継する。分散サービス制御装置１００は、サーバがサービスの性能に関する品質を保つように、自動的に、メッセージ通信及びサーバ処理の制御を行う。分散サービス制御装置１００は、サーバと同一のコンピュータシステム内に構築されていてもよく、又は、サーバとは別のコンピュータを用いて構築されてもよい。
【００３２】
メッセージ受信制御部１１０は、他サーバからの処理要求メッセージの受信を制御する。メッセージ状態管理部１２０は、メッセージ重み計算部１２１と、メッセージ重み保管部１２２とを備える。メッセージ状態管理部１２０は、処理要求メッセージごとに、サーバ処理量を計算する。メッセージ重み保管部１２２は、処理要求メッセージの構造に基づいてサーバでの処理量を計算するためのメッセージ重みルールを保管する。メッセージ重み計算部１２１は、処理要求メッセージと、メッセージ重みルールとに基づいて、処理要求メッセージに対する処理量、すなわちサーバでの処理時間の予測値を計算する。メッセージ重み計算部１２１は、計算したサーバでの処理量を、メッセージ重み情報としてメッセージ重み保管部１２２に保管する。
【００３３】
メッセージキュー１３０は、サーバへの処理要求メッセージを一時的に蓄積する。メッセージキュー１３０のサイズは、可変に設定される。処理要求管理部１４０は、処理要求メッセージをサーバに送信し、サーバに、処理要求メッセージに対する処理を実行させる。処理要求管理部１４０は、複数の実行可能なスレッド１４２と、スレッド群制御部１４１とを有する。スレッド群制御部１４１は、スレッド１４２の管理と、スレッド１４２に対する処理の割り当てとを行いう。スレッド１４２は、処理要求メッセージをサーバに送信し、処理を実行させる。このスレッド１４２の数が、サーバ上の並列処理数となる。
【００３４】
サービス品質性能保管部１６０は、サーバの性能要件として、満たされるべきサービス品質要件に関する情報を保管する。制御ルール決定部１５０は、処理要求メッセージに対する処理時間とサービス品質要件とに基づいて、メッセージキュー１３０のサイズ、及び、処理要求管理部１４０における処理要求メッセージの並列処理数の制御を行う。また、制御ルール決定部１５０は、メッセージ重みルールを利用して計算されたメッセージ重み情報（サーバ処理量）と、実際のサーバでの処理時間の測定結果とを用いて、メッセージ重みルールの補正（学習）を行う。
【００３５】
メッセージ受信制御部１１０は、処理要求メッセージを受信する。受信された処理要求メッセージは、メッセージ重み計算部１２１にて、処理要求メッセージに対する処理量が計算された後に、メッセージキュー１３０に格納される。その際、メッセージ受信制御部１１０は、メッセージキュー１３０に空きがあるか否かを調べ、空きがないときには、空きが発生するまで処理要求メッセージの受信を遅延する。メッセージ受信制御部１１０は、処理要求メッセージをメッセージキュー１３０に格納すると、メッセージ受信完了を示す応答を、メッセージ送信元に送信する。
【００３６】
スレッド群制御部１４１は、メッセージキュー１３０から処理要求メッセージを１つ取り出し、スレッド１４２に対して、サーバに処理要求メッセージを転送して監視する処理を割り当てる。メッセージ受信制御部１１０は、処理要求メッセージの受信完了後、処理要求メッセージがメッセージキュー１３０に保管されてから、取り出されるまでの間の時間（キュー滞留時間）を計測する。スレッド１４２は、サーバに処理要求メッセージを送信して処理を行わせる。その際、スレッド１４２は、サーバでの処理時間を計測する。
【００３７】
制御ルール決定部１５０は、定期的に、メッセージ重み計算部１２１にて計算された処理要求メッセージに対する処理量、及び、キュー滞留時間と、サービス品質性能保管部１６０に保管されたサービス品質要件情報とに基づいて、サーバでの処理時間が、サービス品質要件を満たすように、メッセージキュー１３０のサイズと、処理要求管理部１４０におけるスレッド１４２の並列処理数の上限値とを制御する。例えば、サーバ負荷が高く、処理時間がサービス品質性能要件を満たさないときには、スレッド１４２の並列処理数の上限値を減少させてサーバでの並列処理数を減らし、サーバ負荷を下げる。また、メッセージキュー１３０のサイズを減らし、処理要求メッセージの受信を遅延させ、処理要求メッセージの受信量を抑制する。
【００３８】
制御ルール決定部１５０は、メッセージ重み計算部１２１にて計算されたサーバでの処理時間の予測値と、スレッド１４２にて計測されたサーバでの処理時間の実測値とを比較し、メッセージ重み計算に用いるメッセージ重みルールの補正を行う。この補正では、サーバ処理時間の予測値と、実測値との差が少なくなるように、メッセージ重みルールを補正する。この補正により、メッセージ重み計算部１２１で計算されるサーバ処理時間の予測値と、実測値との誤差を減少させることができる。
【００３９】
図２は、受信処理の動作手順を示している。メッセージ受信制御部１１０は、処理要求メッセージの受信を開始し（ステップＳ１１１）、メッセージキュー１３０に空きがあるか否かを判断する（ステップＳ１１２）。ステップＳ１１２では、例えばメッセージキュー１３０のサイズが「２０」に設定されているときには、メッセージキュー１３０のエントリがすでに２０個使用されているか否かを判断する。空きがない場合には、空きが発声するまで、受信遅延を行う（ステップＳ１２１）。
【００４０】
メッセージ受信制御部１１０は、メッセージキュー１３０に空きが存在する場合、すなわち処理要求メッセージをメッセージキュー１３０に格納可能な状態であれば、処理要求メッセージの送信元に、受信完了のメッセージを送信する（ステップＳ１１３）。ステップＳ１１３では、例えば、ＨＴＴＰプロトコルのＰＯＳＴリクエストで処理要求メッセージが送信されたときには、受信完了を示す値を返却する。その後、メッセージ受信制御部１１０は、メッセージ重み計算部１２１に受信した要求処理メッセージを送る。メッセージ重み計算部１２１は、受け取った要求処理メッセージのメッセージ構造を解析し、解析したメッセージ構造と、メッセージ重み保管部１２２に保管されたメッセージ重みルールとに基づいて、処理要求メッセージに対するサーバでの処理量の計算を行う（ステップＳ１１４）。
【００４１】
図３に、一般的な処理要求メッセージのエンベロープの具体例を示す。処理要求メッセージ１８０は、エンベロープのヘッダに、処理要求メッセージの宛先等を持つ。また、エンベロープのボディに構造化文書を持ち、オプションとして、添付データに画像等のバイナリデータを含む。構造化文書は、例えば機器発注書に相当するデータの場合には、部品の個数分だけタグが繰り返される。サーバでの処理量（処理時間）は、タグの個数や添付データの有無、サイズ等に依存する。このサーバ処理量に関わる部分をメッセージ重みルールとして保管し、サーバ処理時間の予測に用いる。
【００４２】
図４に、メッセージ重みルールの構造を示す。メッセージ重みルール１９０は、メッセージの種類ごとに、ルール（１９１〜１９ｎ）を管理する。各ルールには、メッセージ種別に応じた処理量計算のルールが記述される。例えば、あるメッセージ種別については、タグの個数が０〜５のときは、タグの個数×時間Ａをサーバ処理量とし、タグ個数が５を超えるときにはタグの個数×時間Ｂをサーバ処理量として計算する旨のルールが記述される。また、「添付ファイルあり」のときには、処理量を処理量Ａだけ増加させる旨のルールが記述される。
【００４３】
図２に戻り、ステップＳ１１４では、まず、処理要求メッセージのメッセージ種別を判別して、メッセージ重みルール１９０のうちの何れのルールを用いるかを決定する。その後、処理要求メッセージに含まれるタグの個数、添付ファイルの有無等のメッセージ構造と、処理要求メッセージのメッセージ種別に対応したルールとに基づいて、サーバ処理量を計算する。メッセージ重みルールは、サービスの処理内容があらかじめわかっている場合には、外部から設定することができる。サービスの処理内容がわからない場合には、サーバでの処理を実際に行い、その処理時間の実測値に基づいて導出しても良い。
【００４４】
メッセージ重み計算部１２１は、サーバ処理量を計算すると、その計算結果を、メッセージ重み情報としてメッセージ重み保管部１２２に保管する（ステップＳ１１５）。メッセージ重み情報の構造を図５に示す。メッセージ重み情報２００は、処理要求メッセージのメッセージＩＤと、サーバでの処理量を示すメッセージ重み２０１〜２０ｎとを有する。メッセージ重み計算部１２１は、メッセージ重み情報の保管後、処理要求メッセージをメッセージキュー１３０に転送し、処理要求メッセージをメッセージキュー１３０に各のゆする（ステップＳ１１６）。なお、この処理要求メッセージのメッセージキューへの格納と、メッセージ重み計算とは、どちらを先に行ってもよい。
【００４５】
図６は、スレッド割当ての処理手順を示している。スレッドの割当ては、図２に示す受信処理とは独立して実行される。スレッド群制御部１４１は、システムの運用開始前にあらかじめ設定された複数の実行可能なスレッド１４２を持つ。システムの運用開始後、スレッド群制御部１４１は、自身が管理するスレッド群に空きスレッドが存在するか否かを判断する（ステップＳ２１１）。空きスレッドがない場合には、ステップＳ２１１を繰り返し実行し、空きスレッドの監視を続行する。
【００４６】
スレッド群制御部１４１は、ステップＳ２１１で空きスレッドがあると判断すると、メッセージキュー１３０にメッセージが滞留しているか否かを調べる（ステップＳ２１２）。メッセージが滞留している場合には、スレッド１４２に対して起動通知を通知する（ステップＳ２１３）。メッセージが滞留していない場合には、ステップＳ２１１に戻り、空きスレッドの監視を続ける。
【００４７】
図７は、スレッド１４２の動作手順を示している。スレッド１４２は、スレッド群制御部１４１から起動通知を受けると（ステップＳ３１１）、メッセージキュー１３０から処理要求メッセージを１つ取得する（ステップＳ３１２）。その後、サービスの開始時刻を計測して（ステップＳ３１３）、処理要求メッセージをサービスを実行するサーバに転送する（ステップＳ３１４）。スレッド１４２は、処理要求メッセージの転送後、サーバでの処理が終了したか否かを判断し、サーバでの処理（サービス）が実行終了されるまで待機する（ステップＳ３１５）。
【００４８】
スレッド１４２は、サーバで処理が終了したと判断すると、サービスの終了時刻を計測する（ステップＳ３１６）。スレッド１４２は、ステップＳ３１３で計測したサービスの開始時刻と、ステップＳ３１６で計測したサービスの終了時刻との差から、サービスの実行時間を割り出す。スレッド１４２は、サービス実行時間を割りだすと、サービス実行時間を制御ルール決定部１５０に通知する（ステップＳ３１７）。その後、サービスの完了をスレッド群制御部１４１に通知する（ステップＳ３１８）。この通知を受けたスレッド群制御部１４１は、処理が終了したスレッド１４２を、空きスレッドとして管理する。
【００４９】
図８は、制御ルール決定部１５０におけるメッセージ重みルール補正の動作手順を示している。制御ルール決定部１５０は、スレッド１４２から、サービス実行時間、すなわち、処理要求メッセージに対する実際のサーバでの処理時間を取得する（ステップＳ３５１）。また、制御ルール決定部１５０は、メッセージ重み保管部１２２から、メッセージ重み情報２００（図５）と、メッセージ重みルール１９０（図４）とを取得する（ステップＳ３５２）。
【００５０】
制御ルール決定部１５０は、処理要求メッセージに対する実際のサービス実行時間と、メッセージ重みルールを用いて計算されたサーバでの処理時間の予測値との差に基づいて、メッセージ重みルールを補正する（ステップＳ３５３）。この補正では、処理要求メッセージのメッセージ構造を用いてメッセージ重みを計算した際に、そのメッセージ重みが実際のサービス実行時間に近づくように、メッセージ重みルールを補正する。このメッセージ重みルールの補正を繰り返し行うことで、サーバでの処理時間の予測値の精度が向上する。
【００５１】
図９は、制御ルール決定部１５０における制御ルール導出の動作手順を示している。この制御ルール導出の動作は、周期的に繰り返し行われ、上記メッセージ重みルールの補正の動作とは独立して行われる。制御ルール決定部１５０は、メッセージ重み保管部１２２からメッセージ重み情報２００（図５）を取得し（ステップＳ４１１）、メッセージ受信制御部１１０から、メッセージキュー１３０の平均メッセージ滞留時間を取得する（ステップＳ４１２）。
【００５２】
続いて、制御ルール決定部１５０は、サービス品質性能保管部１６０から、あらかじめサービスレベルの要件として設定されたサービス品質要件情報を取得する（ステップＳ４１３）。図１０に、サービス品質要件情報の構造を示す。サービス品質要件情報１７０は、サービスごとに、満たされるべきサービス品質要件として要件１７１〜１７ｎを有する。制御ルール決定部１５０は、取得したメッセージ重み情報とメッセージ滞留時間とに対して、サービス品質要件が満たせるか否かを判断する（ステップＳ４１４）。
【００５３】
図１１に、処理要求メッセージに対する処理の実行時間を示す。処理実行時間は、大きく分けて、受信処理に要する時間、処理待ちに要する時間（キュー滞留時間）、サービス実行に要する時間、及び、次サービス（次サーバ）への送信処理に要する時間の４つの要素がある。ステップＳ４１１で取得されたメッセージ重みは、サービスの実行開始から、次サーバへのメッセージ送信完了までの間のサービス実行時間の予測値に相当する。このサービス実行時間（予測値）に、キュー滞留時間（処理待ち時間）を加えたものが見かけ上のサービス実行時間（予測値）となる。ステップＳ４１４では、この見かけ上のサービス実行時間の予測値がサービス品質要件を満たすか否かを判断する。
【００５４】
制御ルール決定部１５０は、ステップＳ４１４でサービス品質要件を満たせないと判断すると、スレッド群制御部１４１に、並列実行可能なスレッド数の減少を通知する（ステップＳ４２１）。この通知を受けたスレッド群制御部１４１は、その通知内容に従って、実行可能なスレッド１４２の上限値を減少させる。スレッド１４２の上限値を減少させることで、サーバでの並列処理数が減少し、サーバ負荷が下がることで、サービス実行時間の短縮が期待できる。ステップＳ４２１では、例えば、メッセージ重みとサービス品質要件との差に基づいて、その差が大きいほど、スレッド数の減少数を大きくする。
【００５５】
続いて、制御ルール決定部１５０は、スレッド数の減少後に、サービス品質要件を満たせるか否かを判断する（ステップＳ４２２）。ステップＳ４２２では、例えば、あらかじめスレッド数の減少によりサービス実行時間がどの程度短縮されるのかを見込んでおき、ステップＳ４１１で取得したメッセージ重みからサービス実行時間の短縮分を減算した値とメッセージキュー滞留時間との和が、サービス品質要件を満たせるか否かを判断する。
【００５６】
制御ルール決定部１５０は、ステップＳ４２２で、スレッド数の減少後においてもサービス品質要件を満たせないと判断すると、受信遅延を行う旨を決定し、メッセージキュー１３０のサイズを減少させる（ステップＳ４２３）。ステップＳ４２３では、例えば、ステップＳ４２２でサービス品質要件を満たせるかを判断した際のサービス実行時間の予測値とサービス品質要件との差が大きいほど、メッセージキュー１３０のサイズを小さく設定する。ステップＳ４２２でサービス品質要件を満たせると判断したときには、受信遅延は行わない。
【００５７】
ステップＳ４２３では、例えばメッセージキュー１３０のサイズを、あらかじめ定められた初期値よりも小さいサイズに設定する。これにより、サイズ減少後、そのサイズの減少分に見合った分だけ、メッセージ受信制御部１１０にて受信遅延が行われる（図２のステップＳ１２１）ことになり、処理要求メッセージの単位時間当たりの受付け数が減少する。このように、処理要求メッセージの受付け数を抑制することで、メッセージキュー１３０に処理要求メッセージが滞留する時間が減少して、見かけ上のサービス時間（図１１）の短縮を図ることができる。
【００５８】
ステップＳ４１４で、サービス品質要件を満たせると判断した場合には、制御ルール決定部１５０は、メッセージ受信制御部１１０にて受信遅延が行われているか否かを調べる（ステップＳ４１５）。ステップＳ４１５では、例えばメッセージキュー１３０のサイズが、所定の初期値よりも小さければ、受信遅延が行われていると判断する。受信遅延が行われている場合には、メッセージキュー１３０のサイズを所定数だけ増加させ、受信遅延を解除する（ステップＳ４３１）。以降、メッセージ受信制御部１１０は、増加したメッセージキュー１３０のサイズに見合った入力数の処理要求メッセージを受信する。
【００５９】
制御ルール決定部１５０は、ステップＳ４１５で、受信遅延が行われていないと判断したときには、スレッド群制御部１４１に対して、並列実行可能なスレッド数の上限値の増加を通知する（ステップＳ４１６）。スレッド群制御部１４１は、通知に従って、スレッド数の上限値を増加させ、サーバでの並列処理数の最大値を増加させる。このとき、並列処理数の増加にあわせて、メッセージキュー１３０のサイズを、初期値よりも増やしてもよい。
【００６０】
ステップＳ４２３でメッセージキュー１３０のサイズを小さくし、メッセージ受信制御部１１０での処理要求メッセージの受信遅延を行うと、処理要求メッセージ送信元のサーバは、メッセージ送信後直ちにメッセージ送信処理が完了せずに、相手先のサーバに、処理要求メッセージが到達していないと見える。従って、メッセージ送信元のサーバでは、メッセージ送信にかかる時間が延び、サービス実行時間（図１１）が長くなる。メッセージ送信元のサーバにて、サービス実行時間が長くなったことでサービス品質要件を満たせなくなった場合には、スレッドの減少又はメッセージキューのサイズ減少が行われる。このとき、メッセージ送信先のサーバでは、メッセージ受信後の見かけ上のサービス実行時間は処理要求メッセージの受信遅延によって影響を受けないので、メッセージ受信遅延によってサービス処理性能は劣化しない。
【００６１】
以下、具体例を用いて説明する。図１２は、複数のサーバと分散サービス制御装置とを用いた分散サービス制御システムの構成を示している。各サーバ１０は、ネットワーク２０を介して処理要求メッセージの交換を行い、各サーバ１０に割り当てられた業務（サービス）を行う。各サーバ１０は、サービスの実行を行うサービス部１２のメッセージ入力段に、分散サービス制御装置１１を有する。分散サービス制御装置１１の構成は、図１に示す分散サービス制御装置１００の構成と同じである。各サーバ１０のサービス部１２は、通信部２１と、サービス実行部２２とを有する。処理要求メッセージに対する処理は、サービス実行部２２で実行される。
【００６２】
図１３は、サーバ間での処理要求メッセージのやり取りを示している。図１３におけるサーバ５１、５２、５３は、図１２における各サーバ１０に対応する。また、各サーバの分散サービス制御装置１０１、１０２、１０３は、図１２における各サーバの分散サービス制御装置１１に対応する。ここでは、業務として、受注業務を考え、分散サービス制御システムで、在庫確認、配送、請求書発行などの一連の業務を、複数のサーバにまたがって実行するものとする。処理要求メッセージは、部品発注に関する情報を含んでいる。各サーバは、処理要求メッセージから部品データを抽出して保管した後に、次のサーバへ処理要求メッセージをそのまま転送する。各サーバにて、処理要求メッセージを分割して複数の処理要求メッセージを生成し、或いは、複数の処理要求メッセージを１つにまとめてバッチ処理を実行することはないものとする。
【００６３】
サーバ性能について、サーバ５１、５２、５３の性能は、それぞれ「高」、「中」、「低」とする。また、各サーバの分散サービス制御装置１０１、１０２、１０３では、処理要求メッセージに対する処理時間の品質要件として、「３秒」が設定されている。メッセージキュー１３０の初期サイズは、「２０」とする。処理要求管理部１４０におけるスレッド数の上限値は「８」とする。メッセージ状態管理部１２０のメッセージ重み保管部１２２（図１）に保管されるメッセージ重みルールには、処理要求メッセージのボディのＸＭＬ文書に含まれる部品データを示すタグの個数に対する処理時間が設定されている。
【００６４】
サーバ５０からサーバ５１に、処理要求メッセージが、５件／秒で送信されており、サーバ５１からサーバ５２、サーバ５２からサーバ５３、サーバ５３からサーバ５４にも、処理要求メッセージが、それぞれ５件／秒で送信されているとする。各処理要求メッセージには、３〜５個の部分データ（タグ）が含まれている。この状態で、サーバ５３の分散サービス制御装置１０３では、メッセージキュー１３０に滞留する処理要求メッセージの平均処理待ち時間は１秒であり、サービス実行部２２でのサービス時間は１．５秒であるとする。
【００６５】
サーバ５０から送信される処理要求メッセージ数が増加し、サーバ５０からサーバ５１へ、１秒当たり１０件の処理要求メッセージが送信されたとする。上流側で処理要求メッセージが増加することで、下流にあるサーバ５２、５３、５４への単位時間当たりの処理要求メッセージ数は増加する。その結果、サーバ５１、５２、５３の中でサーバ性能が最も低いサーバ５３では、処理要求メッセージに対する処理が追いつかずに、分散サービス制御装置１０３のメッセージキュー１３０に滞留する処理要求メッセージ数が増加して、平均処理待ち時間が増加する。
【００６６】
分散サービス制御装置１０３では、平均処理待ち時間が増加することで、見かけ上のサービス実行時間（図１１）が増加する。制御ルール決定部１５０は、図９のステップＳ４１４で、見かけ上のサービス実行時間がサービス品質要件「３秒」を満たさないと判断すると、ステップＳ４２１に移行して、スレッド数を減らし、更に、ステップＳ４２２で、見かけ上のサービス時間を３秒以内とするためには受信遅延、すなわち、処理要求メッセージの入力数の抑制を行う必要があると判断して、メッセージキュー１３０のサイズを「２０」から「１０」に減らし、メッセージ受信制御部１１０にて受信遅延を行う。
【００６７】
メッセージ受信制御部１１０は、変更後のメッセージキューのサイズ「１０」を維持するために、以降に受信する処理要求メッセージの受信処理を遅延し、処理要求メッセージの単位時間当たりの受付数を抑制する。これによりサーバ５３の前段のサーバ５２のサービス実行部２２では、処理要求メッセージの送信処理が完了しないことでメッセージ送信時間（図１１）が長くなり、サービス実行時間が延びる。また、その結果、サーバ５２の分散サービス制御装置１０２のメッセージキュー１３０に処理要求メッセージが滞留する時間も長くなる。
【００６８】
制御ルール決定部１５０は、サーバ５２のサービス実行時間（見かけ上のサービス実行時間）が品質要件「３秒」を満たさないと判断すると、サーバ５３の分散サービス制御装置１０３での動作と同様に、スレッド数の減少と、メッセージキュー１３０のサイズ変更とを行う。これにより、サーバ５２の上流側のサーバ５１においても、サーバ５２と同様に受信処理が完了しないことでサービス実行時間が延び、処理要求メッセージのキュー滞留時間が長くなる。その結果、サーバ５１は、サービス品質要件を満たすように、スレッド数の減少と、メッセージキュー１３０のサイズ変更とを行う。
【００６９】
上記のように、サーバ５３にてサービス品質要件を満たせなくなると、処理要求メッセージの受信遅延を行うことで、上流側のサーバ５２にてサービス処理時間が延び、サーバ５２にてサービス品質要件が満たせなくなって、サーバ５２にて処理要求メッセージの遅延設定を行う。サーバ５２で受信遅延を行うことで、サーバ５１のサービス実行時間が延び、サービス品質要件が満たさなくなると、受信遅延を行って、処理要求メッセージの入力数を抑制する。このように、分散サービス制御システム（図１２、図１３）は、特定のサーバに負荷が集中した場合には、上流のサーバまで、順に処理要求メッセージの受信を遅延させ、複数サーバで構成されるシステムの系全体の性能を維持するように動作する。これにより、各サーバで、サービス品質要件を満たした処理が可能となる。
【００７０】
次に、サーバ５０からサーバ５１へ処理要求メッセージが５件／秒で送信されている際に、サーバ５１にてサービス品質要件を満たしている場合を考える。サーバ５１の分散サービス制御装置の制御ルール決定部１５０は、図９に示す制御ルール判定の処理のステップＳ４１４で、サービス品質性能要件を満たしていると判断すると、処理要求管理部１４０におけるスレッドの並列処理数を漸次増加し、サーバ５１のサービス時間が悪化しない範囲で、サービス実行部２２の並列処理数を増やす。このようにすることで、サーバ５１の性能を最大限に活用することができる。
【００７１】
サーバ５１で並列処理数が増えすぎ、処理要求メッセージが下流側のサーバ５２に大量に送信されて、サーバ５２にてサービス品質要件を満たせなくなると、サーバ５２の分散サービス制御装置１０２が受信遅延を行う。この場合には、サーバ５１にて、サービス品質要件を満たせなくなり、制御ルール決定部１５０はスレッド数を減少させる。このようにサーバ５１は、自身のサービス時間、及び、下流側のサーバのサービス時間が悪化しない範囲で、サービス実行部２２の並列処理数を増加し、処理する処理要求メッセージ数を制御する。このようにすることで、各サーバにてサーバ性能に応じた処理を実現しつつ、各サーバでサービス品質要件を満たした処理を実現できる。
【００７２】
以上、まとめると、本実施形態では、分散サービス制御装置１００（図１）により、処理要求メッセージに対する処理がサービス品質要件を満たせなくなると、サーバ（図１２、図１３におけるサービス実行部２２）での並列処理数を減少させ、或いは、メッセージキュー１３０のサイズを小さくしてメッセージ受信制御部１１０にて受信遅延を行うことで、サーバでの処理負担を軽減する。サーバへの処理要求メッセージの入力段において、このような制御を行うことで、サービス実行時間（図１１における見かけ上のサービス実行時間）が長くなってサービス品質要件を満たさない事態を避けることができ、サービス品質要件を満たした処理を実現できる。
【００７３】
本実施形態では、受信した処理要求メッセージに対して単純な構造解析を行い、その内容に応じて、サーバでのサービス実行時間を予測し、予測したサービス実行時間を用いてサービス品質要件を満たすか否かを判断し、スレッド１４２の並列処理数の上限値を制御する。このようにすることで、サーバで同時に処理される処理要求メッセージを一定の範囲に抑えることができ、サーバ性能を最大限に活用できる。また、一時的に、単位時間当たりの処理要求メッセージの入力数が増大した場合でも、大量に到着した処理要求メッセージを、スレッド１４２の並列処理数の上限値を超えて一度に処理しないため、サーバ内で処理不能が発生せず、サービス品質要件を満たした処理を実現できる。
【００７４】
本実施形態では、処理要求メッセージに対する処理時間がサービス品質要件を満たすか否かの判断に際して、メッセージ重みルールを利用して計算したサーバ処理時間を用いる。サーバで実際に処理要求メッセージが処理される前に、メッセージ構造に基づいて予測した負荷に基づいて制御を行うことで、処理要求メッセージの変動に俊敏に追随しやすくなる。また、制御ルール決定部１５０にて、メッセージ重みルールを、実際のサーバでの処理時間と、処理時間の予測値との差に基づいて、メッセージ重みルールを補正することで、処理時間予測の精度を上げることができる。
【００７５】
複数のサーバが連携して動作するシステムで、各サーバに対応して分散サービス制御装置１００を配置すると、分散サービス制御装置１００は、それぞれメッセージキューのサイズ変更による受信遅延やスレッドの並列処理数の変更を行い、サーバ間の連携フローにて隣接するサーバの分散サービス制御装置間で、受信遅延や並列処理数が相互に影響し合う。個々のサーバがサービス品質要件を満たすように動作する結果、自動的に最適な実行配分に到達し、各サーバにてサービス時間がサービス品質要件を満たすことを保証することで、システム全体としてのサービス時間を保証することができる。また、処理要求メッセージの蓄積による直列化を行うことで、大量の処理要求によるサーバの処理不能を防ぐと同時に、蓄積されたメッセージのサーバへの転送量がシステムのボトルネックとならないように、サーバの並列処理数を変更することができる。
【００７６】
また、本実施形態では、各サーバのメッセージ入力段に分散サービス制御装置を配置することでサービス品質要件を満たした処理を実現するため、特許文献２に記載の技術とは異なり、複数の独立したサービスから成る業務に対して、性能に関するサービスレベル合意（Service Level Agreement：ＳＬＡ）を保証するために、複数サービス全体の監視や制御を集中管理するサーバを導入する必要がない。本実施形態では、分散サービス制御装置１００により、各サーバにおいて、サービス時間がサービス品質要件を満たすように制御することで、業務全体の処理時間を一定の範囲に収めることができ、特許文献１に記載の技術のように、集中管理サーバが管理する情報に相当するサービス間の関係情報を、サービス間で持ちまわる必要がない。
【００７７】
本実施形態では、分散サービス制御装置１００は、サーバ性能に余力がある限りスレッド数を増加させるため、サーバの処理性能が、メッセージキュー１３０及びスレッド数の初期値によって抑えられることがなく、サーバの性能を最大限に活用できる。また、複数の分散サービス制御装置を用いたシステムでは、連携フローの下流にあるサーバの性能が、上流のサーバの性能よりも低い場合、下流のサーバにて性能劣化が発生しない範囲で、上流のサーバ性能を最大限に活用できる。このように、分散サービス制御装置によって、自動的にサービス実行に緩急をつけることで、各サーバにてサービス品質要件を満たした処理を実現しつつ、各サーバのサーバ性能を最大限に活用できる。
【００７８】
以上、本発明をその好適な実施形態に基づいて説明したが、本発明のサービス制御装置、方法、プログラム、及び、分散サービス制御システムは、上記実施形態にのみ限定されるものではなく、上記実施形態の構成から種々の修正及び変更を施したものも、本発明の範囲に含まれる。
【産業上の利用可能性】
【００７９】
本発明は、複数のサービスが互いの処理性能を元に協調動作しサービス品質を保つための制御プログラムといった用途に適用できる。また、サービスを実行するサーバとは独立した計算機上で動作するサービス制御装置といった用途にも適用できる。
【図面の簡単な説明】
【００８０】
【図１】本発明の一実施形態の分散サービス制御装置の構成を示すブロック図。
【図２】受信処理の動作手順を示すフローチャート。
【図３】一般的な処理要求メッセージのエンベロープの具体例を示す図。
【図４】メッセージ重みルールの構造を示す図。
【図５】メッセージ重み情報の構造を示す図。
【図６】スレッド割当ての処理手順を示すフローチャート。
【図７】スレッドの動作手順を示すフローチャート。
【図８】制御ルール決定部におけるメッセージ重みルール補正の動作手順を示すフローチャート。
【図９】制御ルール決定部における制御ルール導出の動作手順を示すフローチャート。
【図１０】サービス品質要件情報の構造を示す図。
【図１１】処理要求メッセージに対する処理の実行時間を示す図。
【図１２】複数のサーバと分散サービス制御装置とを用いた分散サービス制御システムの構成を示すブロック図。
【図１３】分散サービス制御システムにおけるサーバ間での処理要求メッセージのやり取りを示すブロック図。
【符号の説明】
【００８１】
１０、５１〜５４：サーバ
１２：サービス部
２１：通信部
２２：サービス実行部
１１、１００〜１０３：分散サービス制御装置
１１０：メッセージ受信制御部
１２０：メッセージ状態管理部
１２１：メッセージ重み計算部
１２２：メッセージ重み保管部
１３０：メッセージキュー
１４０：処理要求管理部
１５０：制御ルール決定部
１６０：サービス品質性能保管部
１７０：サービス品質要件情報
１８０：処理要求メッセージ
１９０：メッセージ重みルール
２００：メッセージ重み情報
【図１】
2008077266.tif 000003
【図２】
2008077266.tif 000004
【図３】
2008077266.tif 000005
【図４】
2008077266.tif 000006
【図５】
2008077266.tif 000007
【図６】
2008077266.tif 000008
【図７】
2008077266.tif 000009
【図８】
2008077266.tif 000010
【図９】
2008077266.tif 000011
【図１０】
2008077266.tif 000012
【図１１】
2008077266.tif 000013
【図１２】
2008077266.tif 000014
【図１３】
2008077266.tif 000015