JP5570030B2 - サービス要求受付制御方法、装置およびシステム - Google Patents

Description

本発明は、サービス提供の所要時間に基づきサービスの過負荷状態を検出し、新規サービス要求の受付拒否を行うサービス要求受付制御方法、装置およびシステムに関する。

サーバに対して多数のクライアントから独立に処理要求が発せられるサーバ・クライアント型システムにおいて、サーバの処理容量を超える要求が発生する場合、サーバ性能劣化、システムダウンといった問題が起こりうる。過負荷状態によるサービス品質の低下やシステムの停止を防ぐために、過剰なサービス要求の受け付けを拒否する方法が提案されている。

その第１の方法は、ソフトウェア設計で対応する方法であり、サーバシステムにおいて、予め受付可能なサービス要求量を設定しておき、それを超えるサービス要求を拒否する方法である。たとえば、受付可能なログイン数と現在のログイン数を比較することより、ログイン数を制限するウェブログイン制御システムがある（特許文献１参照）。また、要求当たりの「負荷」を数値化して管理し、閾値と比較する複数種類のサービス開始要求に対する規制方法がある（特許文献２参照）。

その第２の方法は、リソースの負荷状況の観察に基づく方法であり、ＣＰＵ・メモリ・ネットワーク帯域等、サーバ装置及びシステムを構成する物理的な資源の利用率を監視し、負荷が閾値を超えたら受け付け拒否を行う方法である。たとえば、サーバの機能毎にリソースの負荷状態をモニタリングし、閾値と比較するサーバコンピュータの受付制御方法がある（特許文献３参照）。また、ＣＰＵ利用率を直接モニタリングする呼受付制御装置及び呼受付制御方法がある（特許文献４参照）。

特開２００８−２４２６７６号公報 特開２００８−２８３３０７号公報 特開２０００−３２２３６５号公報 特開２００４−０４８５８０号公報

しかしながら、従来手法１では、ボトルネックが判明していないと使えない、または全てのボトルネック候補に対して設計する必要がある。さらに、ハードウェア資源の状態によらず上限が決められてしまうため、設計上の上限値を低く設定しすぎることによりハードウェア資源を十分使い切れない可能性がある。つまり、性能上限がハードウェア性能ではなく設計上の上限値で制限される。逆に設計上の上限値を高く設定しすぎることでハードウェア資源がボトルネックになってしまい、過負荷状態に陥ってしまう可能性があるといった課題があった。

また、従来手法２では、どのハードウェア資源がボトルネックになるかをあらかじめ知っておかなければならず、設計上困難を伴う点が課題であった。また、ソフトウェア実装がハードウェア性能を十分使い切れない実装であったりした場合、ハードウェア資源の逼迫の検出が困難である（例：マルチコアＣＰＵの場合、ソフトウェア実装により利用率上限が変わりうる）といった課題があった。

したがって本発明は、（１）利用可能なハードウェア資源量をあらかじめ知ることなくハードウェア資源を使い切ることが可能で、（２）ボトルネック原因をあらかじめ知ることなく過剰なサービス要求の受信を検出することが可能な、受付拒否の仕組みを伴うサービス要求受付制御方法、装置およびシステムを実現することを目的とする。

上記目的を実現するため本発明によるサービス要求受付制御方法は、複数クライアント装置からの処理要求を受け付けるサーバ装置における受付制御のためのサービス要求受付制御方法であって、前記クライアント装置からの要求に対する一連の処理に要した平均処理時間を算出するステップと、前記平均処理時間を目標サービス処理時間と比較することでサービスの負荷状態を判定するステップと、前記平均処理時間が前記目標サービス処理時間を超えた場合、前記クライアント装置からの仮要求を拒否するステップとを有し、前記平均処理時間を算出するステップは、２相コミット手法における仮要求メッセージの受信時刻を、前記クライアント装置からの要求に対する処理の開始時間とし、２相コミット手法における確定応答メッセージの送信時刻を、前記クライアント装置からの要求に対する処理の終了時間として前記平均処理時間を算出し、処理中のリクエストについては、前記仮要求メッセージの受信から現在時刻までの時間と、現時点での平均処理時間とのうちの大きい方を処理時間とする。

また、前記仮要求を拒否するステップは、２相コミット手法における仮要求メッセージのみを選択して、受付拒否の対象とするも好ましい。

また、前記サービスの負荷状態を判定するステップは、要求受付を拒否した後、処理中の要求が予め設定された一定数終了した場合、または、全ての要求が処理された場合、再度判定を行うことも好ましい。

上記目的を実現するため本発明によるサービス要求受付制御装置は、複数クライアント装置からの処理要求を受け付けるサーバ装置における受付制御のためのサービス要求受付制御装置であって、前記クライアント装置からの要求に対する一連の処理に要した平均処理時間を算出する手段と、前記平均処理時間を目標サービス処理時間と比較することでサービスの負荷状態を判定する手段と、前記平均処理時間が前記目標サービス処理時間を超えた場合、前記クライアント装置からの仮要求を拒否する手段とを備え、前記平均処理時間を算出する手段は、２相コミット手法における仮要求メッセージの受信時刻を、前記クライアント装置からの要求に対する処理の開始時間とし、２相コミット手法における確定応答メッセージの送信時刻を、前記クライアント装置からの要求に対する処理の終了時間として前記平均処理時間を算出し、処理中のリクエストについては、前記仮要求メッセージの受信から現在時刻までの時間と、現時点での平均処理時間とのうちの大きい方を処理時間とする。

上記目的を実現するため本発明によるサービス要求受付制御システムは、複数クライアント装置と、該複数クライアント装置からの処理要求を受け付けるサーバ装置と、上記に記載のサービス要求受付制御装置とを備える。

本発明の「利用可能なハードウェア資源量をあらかじめ知ることなくハードウェア資源を使い切ることが可能」という特徴によれば、ＯＳやソフトウェアで設定された設計上の受付上限値が実際に利用可能なハードウェア資源量からずれることによって生じるハードウェア資源の余剰や不足を防止するという効果を得ることができる。

また、本発明の「ボトルネック原因をあらかじめ知ることなく過剰なサービス要求を検出することが可能」という特徴によれば、システム導入時のハードウェア形態によらず過負荷を防止可能という効果を得ることができる。

本発明の実施形態におけるシステム構成図を示す。 本発明の制御要求受付サーバの機能構成図を示す。 本発明を用いたシステムの処理フローを示す。 平均処理時間算出のイメージを示す。

本発明を実施するための最良の実施形態について、以下では図面を用いて詳細に説明する。図１は、本発明の実施形態におけるシステム構成図である。本システムは、制御要求受付サーバ１、複数のクライアント装置２、および複数の制御対象装置３から構成される。制御要求受付サーバ１は、クライアント２が発生する制御対象装置３への制御要求を受け付け、要求内容に基づき適切な装置を選択し制御する。その際、クライアント２からの要求を仮要求・確定要求の２段階で受け付ける（２相コミット手法）。

図２に本発明の制御要求受付サーバの機能構成を示す。制御要求受付サーバ１は、メッセージ処理部１１、受付可否判定部１２、処理時間監視部１３、および要求処理部１４を備えている。

メッセージ処理部１１は、クライアント２からの要求メッセージを受信しメッセージの種別（仮要求か確定要求かその他の制御メッセージか）やパラメータを抽出する機能を持つ。また、クライアント２に対して応答メッセージを送信する機能を持つ。

受付可否判定部１２は、現在の負荷状況に基づき仮要求の受付が可能かどうかを判定する。仮要求の受付が可能な場合は、仮要求処理を進めるよう要求処理部１４へ通知し、受付が不可能な場合は拒否応答を行う。また、確定要求については負荷に関係なく要求処理部１４へ通知する。

処理時間監視部１３は、仮要求の受信から確定応答の送信までの時間（＝処理時間）の履歴を蓄積しておき、処理時間に基づく負荷状況を受付可否判定部１２に通知する。平均処理時間が目標として予め設定された閾値（目標サービス処理時間）を超えることが検出された場合には、これ以上の仮要求の受付を行わないように通知する。また、受付拒否状態を解除可能な場合、再度仮要求の受付を行うよう受付可否判定部１２に通知する（受付拒否状態の解除は以下で詳細に説明される）。

要求処理部１４では、リクエストに基づいた制御を制御対象装置３に対して行う。制御対象機器３からの応答が全て返ってくるのを待機してから、処理の成否をメッセージ処理部１１に応答する。

図３に本発明を用いたシステムの処理フローを示す。本フローに基づいて、制御要求受付サーバ１の動作を説明する。
（１）解読処理・パラメータ抽出：制御要求受付サーバ１は、クライアント２から仮要求の要求メッセージを受信する。メッセージ処理部１１は、要求メッセージを解読して、メッセージの種別を判別する。仮要求であるため、パラメータを抽出し、受付可否判定部１２に渡す。
（２）新規要求の受付可否判定：受付可否判定部１２は、現在の負荷状況に基づき仮要求の受付が可能かどうかを判定する。
・新規要求拒否が有効化されている場合、現在の負荷状況では仮要求の受付が不可能として、拒否応答を行う。
・新規要求拒否が有効化されていない場合、受付が可能であるため、処理時間監視部１３に仮要求受付時刻の通知を行い、要求処理部１４に仮要求の要求メッセージのパラメータを渡す。
（３）処理時間測定の開始：処理時間監視部１３は、処理時間測定のため、仮要求メッセージ受信時刻を仮要求受付時間として記録する。
（４）制御可否判定：要求処理部１４は、上記パラメータを解析し、制御可能かどうか判定する。
・パラメータ異常等により制御できない要求の場合、制御不可能として、メッセージ処理部１１に拒否応答を行う。メッセージ処理部１１はこの拒否応答をクライアント２に通知する。なお、この場合、処理時間監視部１３に、処理時間測定の停止通知を行う。
・制御可能な場合、次の処理に進む。
（５）制御対象機器への問い合わせ：要求処理部１４は、上記パラメータで制御対象機器３に処理が可能であるか問い合わせを行う。ここで、複数の制御対象機器３に処理を依頼する必要がときは、複数の制御対象機器３に問い合わせを行う。
（６）成否判定：制御対象機器３からの応答が全て返ってくるのを待機してから、処理の成否を受付可否判定部１２を介して、メッセージ処理部１１に応答する。メッセージ処理部１１はクライアント２に仮応答を返す。制御対象機器３からの応答が処理否である場合、処理時間監視部１３に、処理時間測定の停止通知を行う。制御対象機器３からの応答が処理成功である場合、制御要求受付サーバ１は、クライアント２から、確定要求の要求メッセージを受信する。メッセージ処理部１１は受付可否判定部１２を介して、要求処理部１３に通知する。
（７）制御対象機器への制御実施：要求処理部１４では、リクエストに基づいた制御を制御対象装置３に対して行う。
（８）成否判定：制御対象機器３からの応答が全て返ってくるのを待機してから、処理の成否をメッセージ処理部１１に応答する。メッセージ処理部１１は、処理時間監視部１３に処理終了時刻の通知を行い、クライアント２に確定応答を返す。
（９）処理時間測定の終了：処理時間監視部１３は、仮要求受付時刻と、確定応答メッセージ送信時刻間を処理時間として記録する。

上記の（１）から（９）により、クライアント２からの仮要求から確定応答に至るまでの一連の処理が実行される。処理時間監視部１３では、これとは独立に、平均処理時間の閾値超過判定と滞留要求数の計測が以下のように行われる。
（１０）平均処理時間の閾値超過判定：平均処理時間が閾値Ｔｔｈを超えた場合、受付可否判定部１２に、閾値超過通知を行い、受付可否判定部１２は新規要求拒否を有効化する。上記に記載したように、新規要求拒否が有効化されると、仮要求が拒否対象になる。確定要求は、拒否すると非効率なため拒否対象にならない。
（１１）滞留要求数の計測：クライアント２からの仮要求から確定応答に至るまでの処理中の要求数を計測する。

処理時間監視部１３における、平均処理時間は以下のように検出される。図４は、平均処理時間算出のイメージを示す。

１リクエストの処理時間は、仮要求メッセージの受信から確定応答の送信までの時間である。ただし、滞留中のリクエストを考慮に入れるため、処理中のリクエストについては、「仮要求メッセージの受信〜現在時刻」と「現時点での平均処理時間」のうち大きい方とする。例えば、図４において、下の３つのリクエストは、現時点での平均処理時間で考慮し、その２つ上のリクエストは、滞留時間が平均処理時間より既に大きいため、滞留時間で考慮する。

平均処理時間の算出対象リクエストは、極端に古いリクエストの処理時間を排除するため、「直近Ｎ個」と「直近Ｔｒｅｃ秒までに受け付けたリクエスト数」の少ない方とする。図４の場合、Ｎ個前のリクエストの仮要求メッセージの受信が、Ｔｒｅｃ秒前以前にあるため、図４の上の２つのリクエスト算出対象外となる。なお、図３において、制御可否判定で制御できない要求と判定された要求、および成否判定で制御対象機器３からの応答が処理否である要求は、途中で処理時間測定が停止されているため、算出対象リクエストに含めない。

処理時間監視部１３における、受付拒否状態の解除は以下のように行われる。処理時間監視部１３は、下記のいずれかを満たすとき、受付拒否状態を解除可能か確認する。
（１）受付拒否後Ｍ個のリクエストの処理が完了
（２）全ての待機中リクエストの処理が完了
この場合、処理時間監視部１３は、直近のデータで改めて平均処理時間と閾値を比較して、閾値以下であれば受付拒否状態を解除する。閾値を超えていたら、受付拒否状態を継続（再度Ｍリクエスト／全リクエストの処理終了を待つ）する。

なお、上記に記載された各種制御パラメータ（Ｔｔｈ、Ｔｒｅｃ、Ｎ、Ｍ）はサーバ管理者が手動で制御要求受付サーバ１に事前に設定する。

本発明は、ネットワーク機器の制御サーバシステムに適用できる。ネットワーク機器の制御サーバは、１台のサーバで複数の機器を管理しており、設定要求の集中が発生しうる。また、制御にかかる時間がサーバ外（制御対象となる機器）の過負荷による可能性があり、ボトルネック推定が容易ではない。そのため、本発明が効果的に機能する。

以上のように本発明は、クライアントからの要求の処理時間をモニタリングして処理性能の劣化を検出し、受付制御を行う。このため、ボトルネックの箇所を意識しないで済み、性能逼迫の検出が容易（ソフトウェア実装におけるハードウェア資源利用の特性等を意識しないですむ）であり、設計上の上限値に制限されず、システムのハードウェア性能を使い切ることができる。特に本発明は、ボトルネックが分かりにくいサーバシステム（例：多段サーバ、機器制御サーバ）に容易に適用可能である。

また、以上述べた実施形態は全て本発明を例示的に示すものであって限定的に示すものではなく、本発明は他の種々の変形態様および変更態様で実施することができる。従って本発明の範囲は特許請求の範囲およびその均等範囲によってのみ規定されるものである。

１ 制御要求受付サーバ
２ クライアント装置
３ 制御対象装置
１１ メッセージ処理部
１２ 受付可否判定部
１３ 処理時間監視部
１４ 要求処理部

Claims (5)

1. 複数クライアント装置からの処理要求を受け付けるサーバ装置における受付制御のためのサービス要求受付制御方法であって、
   前記クライアント装置からの要求に対する一連の処理に要した平均処理時間を算出するステップと、
   前記平均処理時間を目標サービス処理時間と比較することでサービスの負荷状態を判定するステップと、
   前記平均処理時間が前記目標サービス処理時間を超えた場合、前記クライアント装置からの仮要求を拒否するステップと、
   を有し、
   前記平均処理時間を算出するステップは、
   ２相コミット手法における仮要求メッセージの受信時刻を、前記クライアント装置からの要求に対する処理の開始時間とし、２相コミット手法における確定応答メッセージの送信時刻を、前記クライアント装置からの要求に対する処理の終了時間として前記平均処理時間を算出し、
   処理中のリクエストについては、前記仮要求メッセージの受信から現在時刻までの時間と、現時点での平均処理時間とのうちの大きい方を処理時間とするサービス要求受付制御方法。
2. 前記仮要求を拒否するステップは、
   ２相コミット手法における仮要求メッセージのみを選択して、受付拒否の対象とすることを特徴とする請求項１に記載のサービス要求受付制御方法。
3. 前記サービスの負荷状態を判定するステップは、
   要求受付を拒否した後、処理中の要求が予め設定された一定数終了した場合、または、全ての要求が処理された場合、再度判定を行うことを特徴とする請求項１または２に記載のサービス要求受付制御方法。
4. 複数クライアント装置からの処理要求を受け付けるサーバ装置における受付制御のためのサービス要求受付制御装置であって、
   前記クライアント装置からの要求に対する一連の処理に要した平均処理時間を算出する手段と、
   前記平均処理時間を目標サービス処理時間と比較することでサービスの負荷状態を判定する手段と、
   前記平均処理時間が前記目標サービス処理時間を超えた場合、前記クライアント装置からの仮要求を拒否する手段と、
   を備え、
   前記平均処理時間を算出する手段は、
   ２相コミット手法における仮要求メッセージの受信時刻を、前記クライアント装置からの要求に対する処理の開始時間とし、２相コミット手法における確定応答メッセージの送信時刻を、前記クライアント装置からの要求に対する処理の終了時間として前記平均処理時間を算出し、
   処理中のリクエストについては、前記仮要求メッセージの受信から現在時刻までの時間と、現時点での平均処理時間とのうちの大きい方を処理時間とするサービス要求受付制御装置。
5. 複数クライアント装置と、該複数クライアント装置からの処理要求を受け付けるサーバ装置と、請求項４に記載のサービス要求受付制御装置とを備えることを特徴とするサービス要求受付制御システム。

Images