(57)【特許請求の範囲】
【請求項１】
複数の顧客組織の各々について、応答保証を行う時間帯である保証時間帯と、当該保証時間帯における前記応答保証の内容と、を記憶した記憶手段であって、前記応答保証の内容には、少なくとも当該顧客組織に割り当てられた最大同時要求処理数が含まれる、記憶手段と、
前記複数の顧客組織内の各ユーザからの処理要求に応答してデータ処理を実行するデータ処理システムであって同一時刻における各顧客組織の前記最大同時要求処理数の合計値の、全時間帯の中での最大値を同時に処理できる能力を持つデータ処理システム、の負荷を監視する監視手段と、
前記監視手段の監視により前記データ処理システムの高負荷状態が検知されている期間は、当該期間を前記保証時間帯内に含む顧客組織である保証時間内組織内のユーザからの処理要求は前記データ処理システムに実行させ、当該期間を前記保証時間帯に含んでいない顧客組織である保証時間外組織内のユーザからの処理要求は前記データ処理システムに実行させないようにする制御を行う制御手段と、
を備える処理要求実行管理装置。
【請求項２】
前記制御手段は、前記各顧客組織内の各ユーザからの処理要求を一時的に保持するキューを備えており、前記データ処理システムの高負荷状態が検知されていない期間は、保証時間内組織及び保証時間外組織のいずれのユーザからの処理要求であるかを区別せずに前記キューの先頭から順に処理要求を前記キューから取り出して前記データ処理システムに実行させると共に、前記データ処理システムの高負荷状態が検知されている期間は、保証時間外組織内のユーザからの処理要求は前記キューから取り出さず、保証時間内組織内のユーザからの処理要求のみを前記キューから取り出して前記データ処理システムに実行させる、ことを特徴とする請求項１に記載の処理要求実行管理装置。
【請求項３】
前記制御手段は、前記データ処理システムの高負荷状態が検知されている期間において前記保証時間内組織が複数存在する場合に、前記キューからそれら各保証時間内組織の処理要求が取り出される割合が、それら各保証時間内組織に割り当てられた前記最大同時要求処理数同士の比率に応じたものとなるように制御する、
ことを特徴とする請求項１又は２に記載の処理要求実行管理装置。
【請求項４】
処理要求が再実行可能か否かを判定する再実行可否判定手段を更に備え、
前記制御手段は、前記データ処理システムの高負荷状態が検知されている期間において、前記データ処理システムが実行中の前記保証外組織内のユーザからの処理要求のうち、前記再実行可否判定手段で再実行可能と判定される処理要求の実行を強制終了するよう前記データ処理システムに指示する、
ことを特徴とする請求項１〜３のいずれか１項に記載の処理要求実行管理装置。
【請求項５】
処理要求が、前記データ処理システムによる実行に予め定められた時間以下の時間しか要さない軽負荷タイプであるか否かを判定する要求タイプ判定手段を更に備え、
前記監視手段は、前記顧客組織ごとに前記データ処理システムが同時に実行している当該顧客組織からの処理要求のうち軽負荷タイプでないと判定される処理要求の数を同時実行数として監視しており、監視している前記各顧客組織の前記同時実行数に基づいて前記データ処理システムが高負荷状態であるか否かを判定する、
ことを特徴とする請求項１〜４のいずれか１項に記載の処理要求実行管理装置。
【請求項６】
コンピュータを、
複数の顧客組織の各々について、応答保証を行う時間帯である保証時間帯と、当該保証時間帯における前記応答保証の内容と、を記憶した記憶手段であって、前記応答保証の内容には、少なくとも当該顧客組織に割り当てられた最大同時要求処理数が含まれる、記憶手段、
前記複数の顧客組織内の各ユーザからの処理要求に応答してデータ処理を実行するデータ処理システムであって同一時刻における各顧客組織の前記最大同時要求処理数の合計値の、全時間帯の中での最大値を同時に処理できる能力を持つデータ処理システム、の負荷を監視する監視手段、
前記監視手段の監視により前記データ処理システムの高負荷状態が検知されている期間は、当該期間を前記保証時間帯内に含む顧客組織である保証時間内組織内のユーザからの処理要求は前記データ処理システムに実行させ、当該期間を前記保証時間帯に含んでいない顧客組織である保証時間外組織内のユーザからの処理要求は前記データ処理システムに実行させないようにする制御を行う制御手段、
として機能させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、処理要求実行管理装置及びプログラムに関する。
【背景技術】
【０００２】
特許文献１には、特定のデータ処理に対する各端末装置からのデータ処理要求が集中しても、許容される特定ユーザに対しては当該データ処理要求を優先して分散処理させるためのシステムが開示されている。このシステムでは、各クライアントからのデータ処理要求受け付け時に、データ要求元のユーザ属性を記憶される判定ファイルに基づいて判定して、特定のユーザからのデータ処理要求を他の情報処理装置に配信させて優先処理させる。
【０００３】
特許文献２には、データセンタにおいて、ユーザ企業ごとに夫々独立な計算資源を割り当て、負荷に応じてその割当てを自動的にリアルタイムに変更するシステムが開示される。このシステムでは、制御プログラムは、ユーザ企業識別子ごとの計算機割当て制御表を作成し、負荷分散装置に設定する。ユーザ要求パケット中のIPアドレスからユーザ企業識別子を識別する手段を設ける。負荷分散装置は、ユーザ要求パケットからユーザ企業を識別し、しかるべき計算機群にそれを転送する。さらに制御プログラムはユーザごとのサービスレベル契約と、計算機の稼動状況モニタ結果を比較、契約条件未達時は割当て計算機を増やす。具体的には制御表を変更し、負荷分散装置に再設定する。さらに、制御プログラムは、それに基づく課金情報を変更する。
【０００４】
特許文献３に開示される動的負荷分散システムは、複数のＷｅｂサーバが複数の業務を分散して処理する際、インターネットの外側においてレスポンスを監視し且つ各サーバ側のＣＰＵ使用率等のリソースを監視し、予め定めたスケジュールルールに応じて各サーバに対する業務の振り分けを行い、更に予め設定したレスポンスルールの閾値を越えてレスポンスタイムが遅くなったサーバを検出したときや、予め設定したサーバリソースルールの上限値を越えてＣＰＵ使用率が高いサーバを検出したとき、サーバ監視・制御エージェントが各Ｗｅｂサーバに対する複数の業務の割り振りを動的に変更する。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２００２−１４０２９９号公報
【特許文献２】特開２００２−０２４１９２号公報
【特許文献３】特開２００５−１８２６４１号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
本発明は、データ処理システムに余力がある場合には応答保証の時間帯の外にある顧客組織内のユーザの処理要求も受け付けつつも、高負荷状態となった場合には応答保証の時間帯内にある顧客組織の応答保証ができるようにすることを目的とする。
【課題を解決するための手段】
【０００７】
請求項１に記載の発明は、複数の顧客組織の各々について、応答保証を行う時間帯である保証時間帯と、当該保証時間帯における前記応答保証の内容と、を記憶した記憶手段であって、前記応答保証の内容には、少なくとも当該顧客組織に割り当てられた最大同時要求処理数が含まれる、記憶手段と、前記複数の顧客組織内の各ユーザからの処理要求に応答してデータ処理を実行するデータ処理システムであって同一時刻における各顧客組織の前記最大同時要求処理数の合計値の、全時間帯の中での最大値を同時に処理できる能力を持つデータ処理システム、の負荷を監視する監視手段と、前記監視手段の監視により前記データ処理システムの高負荷状態が検知されている期間は、当該期間を前記保証時間帯内に含む顧客組織である保証時間内組織内のユーザからの処理要求は前記データ処理システムに実行させ、当該期間を前記保証時間帯に含んでいない顧客組織である保証時間外組織内のユーザからの処理要求は前記データ処理システムに実行させないようにする制御を行う制御手段と、を備える処理要求実行管理装置である。
【０００８】
請求項２に記載の発明は、前記制御手段は、前記各顧客組織内の各ユーザからの処理要求を一時的に保持するキューを備えており、前記データ処理システムの高負荷状態が検知されていない期間は、保証時間内組織及び保証時間外組織のいずれのユーザからの処理要求であるかを区別せずに前記キューの先頭から順に処理要求を前記キューから取り出して前記データ処理システムに実行させると共に、前記データ処理システムの高負荷状態が検知されている期間は、保証時間外組織内のユーザからの処理要求は前記キューから取り出さず、保証時間内組織内のユーザからの処理要求のみを前記キューから取り出して前記データ処理システムに実行させる、ことを特徴とする請求項１に記載の処理要求実行管理装置である。
【０００９】
請求項３に記載の発明は、前記制御手段は、前記データ処理システムの高負荷状態が検知されている期間において前記保証時間内組織が複数存在する場合に、前記キューからそれら各保証時間内組織の処理要求が取り出される割合が、それら各保証時間内組織に割り当てられた前記最大同時要求処理数同士の比率に応じたものとなるように制御する、ことを特徴とする請求項１又は２に記載の処理要求実行管理装置である。
【００１０】
請求項４に記載の発明は、処理要求が再実行可能か否かを判定する再実行可否判定手段を更に備え、前記制御手段は、前記データ処理システムの高負荷状態が検知されている期間において、前記データ処理システムが実行中の前記保証外組織内のユーザからの処理要求のうち、前記再実行可否判定手段で再実行可能と判定される処理要求の実行を強制終了するよう前記データ処理システムに指示する、ことを特徴とする請求項１〜３のいずれか１項に記載の処理要求実行管理装置である。
【００１１】
請求項５に記載の発明は、処理要求が、前記データ処理システムによる実行に予め定められた時間以下の時間しか要さない軽負荷タイプであるか否かを判定する要求タイプ判定手段を更に備え、前記監視手段は、前記顧客組織ごとに前記データ処理システムが同時に実行している当該顧客組織からの処理要求のうち軽負荷タイプでないと判定される処理要求の数を同時実行数として監視しており、監視している前記各顧客組織の前記同時実行数に基づいて前記データ処理システムが高負荷状態であるか否かを判定する、ことを特徴とする請求項１〜４のいずれか１項に記載の処理要求実行管理装置である。
【００１２】
請求項６に記載の発明は、コンピュータを、複数の顧客組織の各々について、応答保証を行う時間帯である保証時間帯と、当該保証時間帯における前記応答保証の内容と、を記憶した記憶手段であって、前記応答保証の内容には、少なくとも当該顧客組織に割り当てられた最大同時要求処理数が含まれる、記憶手段、前記複数の顧客組織内の各ユーザからの処理要求に応答してデータ処理を実行するデータ処理システムであって同一時刻における各顧客組織の前記最大同時要求処理数の合計値の、全時間帯の中での最大値を同時に処理できる能力を持つデータ処理システム、の負荷を監視する監視手段、前記監視手段の監視により前記データ処理システムの高負荷状態が検知されている期間は、当該期間を前記保証時間帯内に含む顧客組織である保証時間内組織内のユーザからの処理要求は前記データ処理システムに実行させ、当該期間を前記保証時間帯に含んでいない顧客組織である保証時間外組織内のユーザからの処理要求は前記データ処理システムに実行させないようにする制御を行う制御手段、として機能させるためのプログラムである。
【発明の効果】
【００１３】
請求項１又は６に係る発明によれば、データ処理システムが高負荷状態でなければ保証時間外組織内のユーザの処理要求も受け付けつつも、高負荷状態となった場合には保証時間内組織の応答保証の内容を満たすよう制御することができる。
【００１４】
請求項２に係る発明によれば、データ処理システムが高負荷状態である間、保証時間外組織の処理要求が実行される数が減っていき、これにより生じたデータ処理システムの処理余力を保証時間内組織の処理要求の処理に振り向けることができる。
【００１５】
請求項３に係る発明によれば、最大同時要求処理数が多い保証時間内組織ほど処理要求が実行されやすくし、応答保証が実現されやすくすることができる。
【００１６】
請求項４に係る発明によれば、保証時間外組織の処理要求の実行が完了するのを単に待つよりも、データ処理システムの負荷を急速に低減させ、その負荷低減により生じた余力を保証時間内組織の処理要求に振り向けることができる。
【００１７】
請求項５に係る発明によれば、処理要求が軽負荷タイプであるか否かの区別をせずに単に同時実行数により高負荷状態であるか否かを判定する方式よりも、高負荷状態の判定をより適切に行うことができる。
【図面の簡単な説明】
【００１８】
【図１】実施形態のシステム構成の一例を示す図である。
【図２】サービスレベルデータ保持部に記憶されるサービスレベルデータの例を示す図である。
【図３】図２に示したサービスレベルデータが示す保証内容を模式的に示す図である。
【図４】応答時間記録部が管理する応答時間の実測値データのデータ構造の一例を示す図である。
【図５】処理要求スケジュール部のモード切り換えの手順の一例を示すフローチャートである。
【図６】保証モード時のキュー内の処理要求の取り出し処理の手順の一例を示すフローチャートである。
【図７】保証モード時のキュー内の処理要求の取り出し処理の手順の別の一例を示すフローチャートである。
【発明を実施するための形態】
【００１９】
図１を参照して、本発明に係る処理要求実行管理装置１０を備えるＡＳＰ（アプリケーションサービスプロバイダ）システムの一実施形態を説明する。このＡＳＰシステムは、顧客に対して、インターネット等のデータ通信ネットワークを介してデータ処理サービスを提供するシステムである。ここでは、個々の顧客は企業等の組織（図１では、「Ａ社」、「Ｂ社」など）であるとする。ＡＳＰシステムは、それら各顧客に所属する個々のユーザのＰＣ（パーソナルコンピュータ）から処理要求を受け、その処理要求に対応するデータ処理を実行する。各顧客（及びその顧客に所属する個々のユーザ）はあらかじめＡＳＰシステム（の中の例えば処理要求実行管理装置１０）に登録されている。各顧客に属するユーザは、このシステムにログインし、必要とするアプリケーションを呼び出し、そのアプリケーションによるデータ処理を要求する。ＡＳＰシステムは、この処理要求に応じたデータ処理を実行する。
【００２０】
このＡＳＰシステムは、処理要求実行管理装置１０と、サービスレベル登録部２０と、データ処理システム３０とを備える。
【００２１】
データ処理システム３０は、顧客に対するアプリケーションサービスのためのデータ処理を実行するシステムであり、複数のデータ処理部３２−１，３２−２，…３２−Ｎ（Ｎは２以上の整数）と、処理用データ保持部３４とを備えている。データ処理部３２−１，３２−２，…３２−Ｎ（以下、区別の必要がない場合は「データ処理部３２」と総称する）は、アプリケーションを実行する個々のコンピュータである。データ処理部３２は、必要なアプリケーションを実行することで、ユーザから処理要求に応じた個々のデータ処理を実現する。データ処理部３２が実行するアプリケーションには特に限定はない。処理用データ保持部３４は、各データ処理部３２のデータ処理に用いられるデータを記憶した記憶装置であり、例えばデータベースとして構築されている。処理用データ保持部３４は、物理的に単一の装置であってもよいし、複数の装置から構成されていてもよい。各データ処理部３２は、ユーザからの処理要求に応じて、必要なデータを処理用データ保持部３４から取得し、取得したデータを用いてデータ処理を実行する。また、実行したデータ処理が、処理用データ保持部３４内のデータを変更するものであれば、データ処理部３２は、そのデータ処理の結果により処理用データ保持部３４内のデータを更新する。
【００２２】
データ処理部３２が実行する処理の流れの具体例を以下に示す。例えば、ある顧客内のユーザが自身のＰＣ上のブラウザからデータ処理部３２上のウェブサーバにアクセスし、データベースの検索ＵＩ（ユーザインタフェース）画面を要求する処理要求をＨＴＴＰリクエストの形で送信すると、データ処理部３２はその要求に応じた検索ＵＩ画面のウェブページを提供する。また、ユーザがそのＵＩ画面に検索条件を入力して検索の処理要求を発すると、データ処理部３２はその処理要求に応じて処理用データ保持部３４内の当該顧客のデータベースを検索し、検索結果を表示したウェブページを生成してユーザに返す。また、ユーザがデータベースへの入力フォームに対してデータを入力し、データ入力の要求を発すると、データ処理部３２はその入力データにより処理用データ保持部３４内の当該顧客のデータベースを更新する。なお、この具体例はあくまで説明のための一例に過ぎず、データ処理部３２が実行するアプリケーションの種類やそのアプリケーションに対する処理要求の種類は、上に例示したものに限られない。
【００２３】
処理要求実行管理装置１０は、各顧客に属する各ユーザからの処理要求を、データ処理システム３０内の各データ処理部３２−１，３２−２，…３２−Ｎに割り振る処理を行う。処理要求実行管理装置１０は、処理要求受付部１１、処理要求保持部１３、処理要求スケジュール部１５、サービスレベルデータ保持部１７、及び応答時間記録部１９を備える。
【００２４】
処理要求受付部１１は、ネットワークを介して、各顧客（図示例ではＡ，Ｂ，Ｃ社）内のユーザからの処理要求を受け付ける。受け付けた処理要求は、処理要求保持部１３に入れられる。処理要求保持部１３は、処理要求を保持するキュー（待ち行列）である。処理要求受付部１１が処理要求を受け付けるごとに、新たに受け付けられた処理要求はそのキューの末尾に追加される。処理要求保持部１３に保持された処理要求は、次に説明する処理要求スケジュール部１５により取り出され、いずれかのデータ処理部３２に渡される。取り出された処理要求は、処理要求保持部１３から削除される。
【００２５】
処理要求スケジュール部１５は、処理要求保持部１３内のキュー内の処理要求を、データ処理システム３０内の各データ処理部３２に分配して実行させる。例えば、いずれかのデータ処理部３２が次の処理要求を受け入れ可能になると、処理要求スケジュール部１５は、処理要求保持部１３から処理要求を取り出し、取り出した処理要求をそのデータ処理部３２に対して割り当てる。処理要求スケジュール部１５は、キュー（処理要求保持部１３）からの処理要求の取り出し方のモードとして、少なくとも通常モードと保証モードと呼ぶ２つのモードを有している。通常モードは、処理要求保持部１３のキューの先頭から順に処理要求を取り出すという一般的なＦＩＦＯ（先入れ先出し）方式のモードである。保証モードは、顧客に保証したサービスレベルを達成するために、保証対象の顧客からの処理要求を保証対象でない顧客からの処理要求よりも優先してキューから取り出すモードである。一つの例では、すべての顧客に保証したサービスレベルが達成できている状況では、処理要求スケジュール部１５は通常モードで動作し、データ処理システム３０が高負荷状態となった場合には、処理要求スケジュール部１５は保証モードで動作する。なお、高負荷状態とは、少なくとも１つの顧客に保証したサービスレベルが達成されなくなった（あるいは達成できなくなりそうになった）状態のことである。
【００２６】
サービスレベルデータ保持部１７には、各顧客に保証したサービスレベルの内容を示すデータが記憶されている。サービスレベルとは、このシステムを運用するプロバイダが各顧客に対して保証するＡＳＰサービスの品質の内容である。
【００２７】
図２に、サービスレベルデータ保持部１７に記憶されるサービスレベルデータの例を示す。この例では、ＡＳＰサービスの品質として、最大同時セッション数と目標応答時間の組合せを用いている。ここで、最大同時セッション数は、プロバイダが顧客に保証する同時セッション数の上限値である。なお、同時セッション数は、データ処理システム３０が同時に実行する一つの顧客からの処理要求の数である。また、目標応答時間は、ユーザのＰＣが処理要求を発してから、データ処理部３２がその処理要求の実行結果をユーザのＰＣに返すまでの時間（この時間を「応答時間」と呼ぶ）の目標上限値である。この実施形態では、処理要求スケジュール部１５は、顧客からの処理要求の数が最大同時セッション数に達するまでは、その顧客からの処理要求に対するデータ処理システム３０の応答時間が目標応答時間を超えないよう保証すべく、処理要求保持部１３内の処理要求の実行順序を制御する。ここで、目標応答時間は、個々の処理要求についての応答時間についてのものであってもよいし、直近のある期間における当該顧客からの処理要求についての応答時間の平均についてものであってもよい。すなわち、処理要求スケジュール部１５は、顧客からの個々の処理要求についての応答時間がすべてその顧客の目標応答時間を超えないように制御するものであってもよいし、直近のある期間における当該顧客からの処理要求についての応答時間の平均が目標応答時間を超えないように制御するものであってもよい。処理要求スケジュール部１５がこれら２つの方式のうちのいずれの方式で動作するかを選択できるようにしてもよい。
【００２８】
また、図２の例では、ＡＳＰサービスのレベル（応答保証の内容）を時間帯ごとに登録している。例えば、顧客企業Ａについては、午前９時〜午前１０時の時間帯に最大セッション数１００、目標応答時間５秒という応答保証内容が登録され、顧客企業Ｃについては、午前８時〜午後６時の時間帯に最大同時セッション数３０、目標応答時間８秒という応答保証内容が登録されている。一方、顧客企業Ｂについては、午前１１時〜正午の時間帯に最大同時セッション数５０、目標応答時間５秒という応答保証内容が、午後１時〜午後２時の時間帯に最大同時セッション数１００、目標応答時間５秒という応答保証内容が登録されている。このように、サービスレベル（応答保証内容）が登録された時間帯のことを、以下では「保証時間帯」と呼ぶ。図２の例では、顧客Ａ及びＣは保証時間帯を１つだけ登録しており、顧客Ｂは保証時間帯を２つ登録している。
【００２９】
なお、ある顧客の保証時間帯以外の時間帯でも、その顧客内のユーザはデータ処理システム３０を利用する（すなわちデータ処理システム３０に処理要求を送ってデータ処理を実行させる）ことはできる。しかし、サービスレベルの保証は行われない。したがって、ユーザが保証時間帯以外の時間帯にデータ処理システム３０を利用していたとしても、保証時間帯内に他の顧客の応答保証が必要となった等の理由で、利用が制限される（例えば新たな処理要求が受け付けられなくなる）ことがある。
【００３０】
図２に示したサービスレベルデータが示す保証内容を、図３に模式的に示す。保証時間帯の設定がない場合、顧客Ａ、Ｂ、Ｃの最大同時セッション数を満たすには、データ処理システム３０は２３０セッション（２３０の処理要求）を同時に実行する処理能力を有する。これに対し、図２のように各顧客の保証時間帯が設定されている場合、データ処理システム３０は１３０セッションを同時に実行する処理能力を持てばよい。すなわち、データ処理システム３０は、同一時刻における各顧客の最大同時セッション数の合計値の、全時間帯の中での最大値を同時に処理できる能力を持っていればよい。
【００３１】
サービスレベル登録部２０は、サービスレベルデータ保持部１７に対してサービスレベルデータの登録を行うためのＵＩである。サービスレベル登録部２０は、例えばウェブページの形で処理要求実行管理装置１０から顧客内のユーザ（例えば顧客内のシステム管理者）に提供してもよい。この場合、そのユーザがそのウェブページ内の入力欄に保証時間帯、最大同時セッション数、目標応答時間等を入力し、入力結果を送信することで、サービスレベルデータ保持部１７内に当該顧客のサービスレベルの情報が登録される。同様にして、顧客の既登録のサービスレベルデータを更新できるようにしてもよい。また、サービスレベル登録部２０をＡＳＰシステム内に設け、ＡＳＰシステムの職員が顧客からの要請に応じてサービスレベルデータ保持部１７へのデータの登録又は更新を行ってもよい。
【００３２】
応答時間記録部１９は、各顧客の各ユーザが発した処理要求に対するデータ処理システム３０の応答時間を計測し、顧客ごとに処理要求の応答時間の実測値を記録する。
【００３３】
応答時間記録部１９が管理する応答時間の実測値データのデータ構造の一例を図４に示す。図示のように、応答時間記録部１９は、顧客ごとに、現在実行しているその顧客の処理要求の数（「実行中セッション数」）と、現時点でのその顧客の処理要求についての応答時間の実測値と、をメモリに記憶する。
【００３４】
例えば、応答時間記録部１９は、処理要求受付部１１がある顧客の所属ユーザからの処理要求を受け付けると、その処理要求にＩＤ（識別情報）を付与し、その処理要求ＩＤに対応づけて、その処理要求を発したユーザのＩＤと、その処理要求の受付時刻を記録する。処理要求スケジュール部１５が処理要求保持部１３から処理要求を取り出していずれかのデータ処理部３２に割り当てると、応答時間記録部１９はその処理要求の発行元ユーザの属する顧客の「実行中セッション数」を１増加させる。処理要求を発したユーザがどの顧客に属するかどうかは、顧客ＩＤとユーザＩＤの対応関係のデータベースを参照する等の処理により判別すればよい。また、データ処理部３２から処理要求の実行が完了した旨の通知（その処理要求のＩＤを含む）を受けると、その処理要求を発したユーザの属する顧客の実行中セッション数を１つ減少させる。また、このとき、その処理要求の受付時刻から完了時刻までの時間、すなわちその処理要求についての応答時間、を計算し、その応答時間により当該顧客の応答時間の実測値を更新する。「応答時間実測値」として、単一の処理要求についての応答時間を用いる場合には、そのとき計算した応答時間を当該顧客の「応答時間実測値」の値に上書きすればよい。また、応答時間の平均を用いる場合は、例えば過去ある一定の期間の間に実行が完了した処理要求の応答時間を顧客ごとに分類して記憶しておき、新たにある顧客内のユーザからの処理要求の応答時間が計算された場合、その新たに計算された応答時間を考慮して応答時間の平均を更新すればよい。このように、応答時間記録部１９は、処理要求保持部１３内の処理要求をデータ処理システム３０に渡す都度、その処理要求の発行元の顧客の「実行中セッション数」をインクリメントし、データ処理部３２で処理要求の実行が完了する都度、その処理要求の発行元の顧客の「実行中セッション数」をデクリメントし、「応答時間実測値」を更新する。このような処理により、各顧客の実行中セッション数及び応答時間実測値が常に最新状況を表すように管理される。
【００３５】
処理要求スケジュール部１５は、応答時間記録部１９が管理する各顧客の実行中セッション数及び応答時間実測値の情報と、サービスレベルデータ保持部１７に保持された各顧客のサービスレベルデータとを参照して、処理要求保持部１３からの処理要求の取り出しの制御を行う。
【００３６】
この取り出し制御には、前述のように少なくとも通常モードと保証モードの２つの動作モードがある。処理要求スケジュール部１５は、データ処理システム３０が高負荷状態になった場合に、通常モードから保証モードへの切換を行う。一つの例では、保証時間帯内にある顧客のうちの少なくとも１つの目標応答時間が達成されていない（又は近いうちに達成できなくなる可能性が高いと判定される）場合に、データ処理システム３０が高負荷状態となったと判定する。ある顧客の目標応答時間が達成されているか否かは、その顧客の目標応答時間と応答時間実測値とを比較することで判定すればよい。応答時間実測値が目標応答時間よりも長ければ目標応答時間が達成されておらず、応答時間実測値が目標応答時間以下であれば目標応答時間が達成できているということである。また、応答時間実測値が、目標応答時間より少し短く設定した閾値時間よりも長くなった場合に、近いうちに目標応答時間が達成できなくなる可能性が高いと判定し、高負荷状態と判定してもよい。また、応答時間実測値の履歴を記録しておき、その履歴から、このままでは近いうちに応答時間実測値が目標応答時間を超えると判定される場合に、目標応答時間が達成できなくなる可能性が高いと判定し、高負荷状態と判定してもよい。なお、以下では、記載を簡潔にするために、目標応答時間が近いうちに達成できなくなる可能性が高い状態も、「目標応答時間が達成されていない」という記載で包括して表現することとする。同様に、目標応答時間が近いうちに達成できなくなる可能性が低い状態を、「目標応答時間が達成されている」という記載で包括して表現することとする。
【００３７】
高負荷状態と判定した場合、処理要求スケジュール部１５は、サービスレベルデータ保持部１７に保持された各顧客の保証時間帯や目標応答時間等の情報と、応答時間記録部１９が保持している各顧客の応答時間実測値等の情報とを参照して、高負荷状態か否かを判定する。高負荷状態と判定し、保証モードに移行した場合、処理要求スケジュール部１５は、保証時間帯内の顧客（以下、「保証時間内顧客」と呼ぶ）の処理要求を保証時間帯外の顧客（以下、「保証時間外顧客」と呼ぶ）の処理要求よりも優先的に処理要求保持部１３から取り出し、データ処理システム３０に処理させる。また、保証モードでは、同じ保証時間内顧客のうちでも、目標応答時間が達成されていない顧客の処理要求を、目標応答時間が達成されている顧客の処理要求よりも優先して処理要求保持部１３から取り出すようにしてもよい。また、保証モードでは、同じ保証時間内顧客のうちでも、実行中セッション数（図４参照）が最大同時セッション数よりも少ない顧客の処理要求を、そうでない顧客の処理要求よりも優先して処理要求保持部１３から取り出すようにしてもよい。
【００３８】
保証モードにおける処理要求の実行の優先関係をまとめると以下のようになる。
【００３９】
（１）保証モードのときに最も優先するのは、目標応答時間が達成されておらず、且つ実行中セッション数が最大同時セッション数に達していない保証時間内顧客である。このような顧客の処理要求を優先して処理することで、目標応答時間が達成されやすくするのである。
【００４０】
（２）次に優先するのは、実行中セッション数は最大同時セッション数に達しているが目標応答時間は達成できていない保証時間内顧客である。最大同時セッション数以上の処理要求を現在処理中であるからといって、このような顧客の処理要求を待機させたのでは、応答時間実測値がますます延びることになり、目標応答時間の達成が更に難しくなるからである。
【００４１】
（３）その次に優先するのは、目標応答時間は達成できているが実行中セッション数は最大同時セッション数に達していない保証時間内顧客である。このような顧客は、目標応答時間が達成されているので、処理要求の実行を多少待たせても上記（１）及び（２）のケースよりは問題が少ない。したがって、上記（１）及び（２）のケースよりは優先度は下がる。しかし、最大同時セッション数までの同時実行は保証しているので、応答時間実測値が目標応答時間を超過してしまうことのないよう、ある程度の優先度で処理要求を実行していく必要はある。
【００４２】
（４）その次に優先するのは、実行中セッション数が最大同時セッション数に達しており、且つ目標応答時間が達成されている保証時間内顧客である。このような顧客は、目標応答時間が達成されているので、処理要求の実行を多少待たせても上記（１）及び（２）のケースよりは問題が少ない。また、最大同時セッション数以上の処理要求を現に処理しているので、更に同時実行数を増やす必要もない。したがって、このケースは、上記（３）のケースよりも優先度が下がる。
【００４３】
（５）優先度が最も低いのは、保証時間外顧客である。保証時間外顧客は、応答保証の時間帯から外れているのだから応答保証の必要がない。そこで、保証モードでは、保証時間外顧客の処理要求を処理要求保持部１３から新たに取り出す（そしてデータ処理システム３０に実行させる）ことはしない。これにより、データ処理システム３０の持つ限られた処理能力が、より優先度の高い顧客に振り向けられるようにする。
【００４４】
以上、ケース（１）〜（５）の優先順位を例示したが、システムに実装する場合にこれら５段階のすべてを区別する必要は必ずしもない。例えば、ケース（１）〜（４）を同じ扱いとするなど（後述する図６の例）、優先順位が隣り合う複数のケースの取扱を同じレベルとしてもよい。
【００４５】
また、優先順位（取扱のレベル）が同じ顧客が複数存在する場合には、処理要求保持部１３からの処理要求の取り出し数のそれら顧客間での比率が、それら顧客の最大同時セッション数の比率と等しくなるよう、処理要求保持部１３からの処理要求の取り出しを制御してもよい。
【００４６】
以上、処理要求スケジュール部１５の制御内容について概説した。次に、その制御の具体例を、図５を参照して説明する。
【００４７】
まず、システムの起動時点では、処理要求スケジュール部１５の動作モードは「通常モード」に設定される。処理要求スケジュール部１５は、自身の動作モードをデータ処理システム３０の最新の状態に合わせて動的に切り換えるために、定期的に図５の処理を繰り返す。図５の手順では、処理要求スケジュール部１５は、現在時刻とサービスレベルデータ保持部１７に記憶された各顧客の保証時間帯とを比較し、保証時間内顧客（自身の保証時間帯内に現在時刻が含まれる顧客）を特定する（Ｓ１２）。Ｓ１２で、保証時間内顧客が１つもなければ、動作モードを通常モードとし（Ｓ１４）、Ｓ１２に戻る。
【００４８】
また、Ｓ１２で保証時間内顧客が１つでも見つかれば、応答時間記録部１９から各保証時間内顧客の応答時間実測値を取得し（Ｓ１６）、取得した応答時間実測値をサービスレベルデータ保持部１７内の当該顧客の目標応答時間と比較することで、目標応答時間が達成されていない保証時間内顧客が存在するかどうかを判定する（Ｓ１８）。目標応答時間が達成されていない保証時間内顧客が存在しない場合、この例ではデータ処理システム３０は高負荷状態ではないと判定し、動作モードを通常モードとし（Ｓ１４）、Ｓ１２に戻る。Ｓ１８で目標応答時間が達成されていない保証時間内顧客が存在すると判定した場合、処理要求スケジュール部１５は、動作モードを保証モードとし（Ｓ２０）、Ｓ１２に戻る。
【００４９】
データ処理システム３０内の各データ処理部３２は、新たな処理要求の処理が可能になる都度、処理要求スケジュール部１５に対して、新たな処理要求を割り当てるよう要求する。処理要求スケジュール部１５は、データ処理部３２から新たな処理要求を要求されると、処理要求スケジュール部１５から処理要求を取り出し、要求元のデータ処理部３２に供給する。
【００５０】
ここで、動作モードが通常モードである場合は、処理要求スケジュール部１５は、処理要求保持部１３（キュー）内の順序に従い、その順序の先頭の処理要求を取り出して要求元のデータ処理部３２に供給する。
【００５１】
一方、動作モードが保証モードである場合の処理要求スケジュール部１５の処理手順の一例を図６に示す。
【００５２】
この手順では、処理要求スケジュール部１５は、データ処理システム３０内の各データ処理部３２からの割当要求を待ち（Ｓ２２）、割当要求が到来すると、制御変数ｎ（ｎは１以上の整数）を１に初期化する（Ｓ２４）。そして、キュー（処理要求保持部１３）の先頭からｎ番目の処理要求の発行元の顧客を特定し、サービスレベルデータ保持部１７を参照してその顧客が保証時間内顧客であるかどうかを判定する（Ｓ２６）。ｎ番目の処理要求の発行元の顧客が保証時間内顧客でなければ、その処理要求は処理要求保持部１３から取り出さずに、ｎを１増加させて（Ｓ２８）Ｓ２６に戻り、キュー内の次の処理要求を検査する。
【００５３】
Ｓ２６で、キュー内のｎ番目の処理要求が保証時間内顧客のものであると判定した場合、処理要求スケジュール部１５は、そのｎ番目の処理要求を処理要求保持部１３から取り出し、割当要求発行元のデータ処理部３２に割り当て（Ｓ３０）、Ｓ２２に戻る。
【００５４】
図６の処理手順では、キューの先頭からみて最初に見つかる保証時間内顧客（上述したケース（１）〜（４）のいずれかに該当）の処理要求が処理要求保持部１３から取り出され、処理されることとなる。逆に、保証時間外顧客（上述したケース（５）に該当）の処理要求は、処理要求保持部１３内に残ったままとなる。このような処理によれば、保証モードの間は、保証時間外顧客の新たな処理要求は実行されないので、現に実行中の保証時間外顧客の各処理要求の処理が時間の経過に伴って完了していくにつれて、データ処理システム３０の余力が増大していく。そして、その増大した余力が保証時間内顧客の新たな処理要求に振り向けられることになる。これにより、保証時間内顧客の処理要求の実行が加速され、目標応答時間が達成される方向に推移していく。
【００５５】
図６の処理手順では、保証時間内顧客が複数存在する場合、高負荷状態では、それら各保証時間内顧客の処理要求が単純にキュー内の順序に従って処理されていく。これに対し、別の例として、データ処理システム３０が高負荷状態にある期間において保証時間内顧客が複数存在する場合、キューからそれら各保証時間内顧客の処理要求が取り出される割合が、それら各保証時間内顧客に割り当てられた最大同時セッション数同士の比率に応じたものとなるように制御してもよい。例えば、キューから取り出す数の比率が最大同時セッション数同士の比率と等しくなるように、各保証時間内顧客の処理要求のキューからの取り出しの間引きを行ってもよい（例えば、最大同時セッション数同士の比率よりも実際の取り出し数の比率が高い保証時間内顧客の処理要求はキューからの取り出しの間引き率を高くするなど）。
【００５６】
次に、図７を参照して、保証モードにおける処理要求スケジュール部１５の別の処理手順の例を説明する。
【００５７】
この手順では、処理要求スケジュール部１５は、データ処理システム３０内の各データ処理部３２からの割当要求を待ち（Ｓ２２）、割当要求が到来すると、制御変数ｎ（ｎは１以上の整数）を１に初期化する（Ｓ２４）。そして、キュー（処理要求保持部１３）の先頭からｎ番目の処理要求の発行元の顧客を特定し、サービスレベルデータ保持部１７を参照してその顧客が保証時間内顧客であるかどうかを判定する（Ｓ２６）。ｎ番目の処理要求の発行元の顧客が保証時間内顧客でなければ、その処理要求は処理要求保持部１３から取り出さずに、ｎを１増加させて（Ｓ２８）Ｓ２６に戻り、キュー内の次の処理要求を検査する。
【００５８】
Ｓ２６で、キュー内のｎ番目の処理要求が保証時間内顧客のものであると判定した場合、処理要求スケジュール部１５は、応答時間記録部１９とサービスレベルデータ保持部１７を参照して、当該保証時間内顧客の目標応答時間が達成されているかどうかを判定する（Ｓ３２）。達成されていない場合は、そのｎ番目の処理要求を処理要求保持部１３から取り出し、割当要求発行元のデータ処理部３２に割り当て（Ｓ３０）、Ｓ２２に戻る。
【００５９】
Ｓ３２で、その保証時間内顧客の目標応答時間が達成されていると判定した場合、処理要求スケジュール部１５は、更にその保証時間内顧客の実行中セッション数が最大同時セッション数に達しているかを判定する（Ｓ３４）。達している場合は、そのｎ番目の処理要求は処理要求保持部１３から取り出さず、ｎを１増加させて（Ｓ２８）、Ｓ２６に戻る。達していない場合は、そのｎ番目の処理要求を処理要求保持部１３から取り出し、割当要求発行元のデータ処理部３２に割り当て（Ｓ３０）、Ｓ２２に戻る。
【００６０】
図７の処理手順では、キューの先頭からみて最初に見つかる、上述したケース（１）〜（３）に該当する顧客の処理要求が処理要求保持部１３から取り出され、処理されることとなる。逆に、上述したケース（４）又は（５）に該当する顧客の処理要求は、処理要求保持部１３内に残ったままとなる。すなわち、この手順では、ケース（４）又は（５）に該当する顧客の処理要求を待たせることでデータ処理システム３０の負荷を低減し、この負荷低減により生じた余力でケース（１）〜（３）に該当する顧客の処理要求が早く実行されるようにするのである。
【００６１】
以上に説明した図６及び図７の例では、処理要求保持部１３内の処理要求を待たせるかどうかの区切りを、図６の手順ではケース（５）と（４）の間に置き、図７の手順ではケース（４）と（３）の間に置いた。しかし、これらはあくまで一例に過ぎず、例えば別の例としてその区切りをケース（３）と（２）の間に設定してもよい。
【００６２】
以上の例では、保証モード時の制御は、優先されない顧客の処理要求は処理要求保持部１３内で待たせ、優先される顧客の処理要求は先入れ先出し順に実行するという２段階の段階分けであったが、これは一例に過ぎない。別の例として、例えば、優先順位が高いほど、相対的に高い頻度で処理要求が処理要求保持部１３内から取り出されるように制御してもよい。この例では、例えば、ケース（５）（保証時間外顧客）の処理要求はキュー（処理要求保持部１３）内で完全に待たせ、ケース（１）〜（４）の顧客は、優先順位が高いほど処理要求がキューから取り出されやすくする。例えば、キューを先頭から調べていく過程で、ケース（１）の顧客の処理要求は見つけるたびにすべてキューから取り出し、ケース（２）の顧客の処理要求は２回見つけるごとに１回の割合でキューから取り出す等というように、優先順位が下がるほどキューから取り出す割合を下げていくのである。
【００６３】
また、同じ優先順位の保証時間内顧客が複数存在している場合には、キューからそれら同順位の各保証時間内顧客の処理要求が取り出される割合が、それら各保証時間内顧客に割り当てられた最大同時セッション数同士の比率に応じたものとなるように制御してもよい。
【００６４】
また、以上の例では、保証時間外顧客のように優先されない顧客の現に実行中の処理要求は実行が完了するまで待ったが、これも一例に過ぎない。この代わりに、次のような制御を行ってもよい。
【００６５】
すなわち、この例では、処理要求を、再実行可能なものと再実行不可能なものとに分類しておき、保証モードでは、優先されない顧客の現にデータ処理システム３０内で実行中の処理要求のうち、再実行可能な処理要求については、その実行を強制的に取りやめる（途中までの処理結果を破棄）。また、別の例として、再実行可能な処理要求は強制的に中断（途中までの処理結果を保持してサスペンド）してもよい。再実行不可能な処理要求については、そのような強制的な取りやめ又は中断は行わず、実行が完了するのを待つ。実行を取りやめた再実行可能な処理要求は、例えばキューの先頭に戻すなどにより、動作モードが通常モードに戻ったときにその取りやめた処理要求から実行されるようにしてもよい。また中断した処理要求は、動作モードが通常モードに戻り次第、途中の処理結果を用いて再開する。なお、再実行可能な処理要求としては、例えば、データベースの内容の閲覧などのように、実行を取りやめ又は中断して後で再開しても、最初の実行時と再開後の実行時で実行結果が変わらない種類の処理要求がある。再実行不可能な処理要求には、例えば、データベースへの書き込み処理の要求などがある。
【００６６】
この制御のためには、処理要求スケジュール部１５は、各処理要求が再実行可能か否かを示す分類情報を保持していればよい。
【００６７】
このように優先されない顧客の再実行可能な処理要求の実行を取りやめ又は中断することで、そのような取りやめ又は中断をしない場合よりも急速にデータ処理システム３０の余力を増大させ、その余力が優先される顧客に振り向けられることとなる。
【００６８】
また、以上の例では、データ処理システム３０が高負荷状態であるか否かを、各顧客の目標応答時間の達成状況に基づいて判定したが、これは一例に過ぎない。この他に、例えば、すべての顧客の実行中セッション数の総和が予め定められた閾値を超えた場合に、高負荷状態と判定してもよい。
【００６９】
また、各顧客の目標応答時間の達成状況と、全顧客の実行中セッション数の総和との組合せにより、高負荷状態か否かを判定してもよい。この場合、例えば、少なくとも１つの顧客の目標応答時間が達成されていない場合は高負荷状態と判定すると共に、すべての顧客の目標応答時間が達成されている場合でも、全顧客の実行中セッション数の総和が閾値を超えていれば高負荷状態と判定する、等の判定条件を用いればよい。
【００７０】
また、各顧客の目標応答時間の達成状況や全顧客の実行中セッション数ではなく、各データ処理部３２のＣＰＵ（中央演算装置）の使用率等といった、ハードウエアの負荷状況の計測値に基づき、データ処理システム３０が高負荷状態であるか否かを判定してもよい。
【００７１】
さて、処理要求の中には、単純な画面遷移の要求等のように、極めて短時間で処理が完了する（すなわちデータ処理システム３０にとっての負荷が極めて低い）ものが存在する。またその一方で、大量のデータ処理や大量のデータ更新などを伴う処理のように、ある程度以上の処理時間を要する（すなわち処理負荷が高い）処理要求も存在する。一般に、各ユーザからの処理要求にはそのような負荷の異なるものが混在している。このような状況において、処理負荷が極めて軽い処理要求と、そうでない処理要求とを同列に取り扱ったのでは、不都合な場合もある。例えば、保証モード時に、保証時間外顧客の単純な画面遷移の要求をキュー内で待たせたとしても、データ処理システム３０の負荷軽減にはあまり寄与しないが、その顧客にとっての操作の快適性は著しく低下する。また、データ処理システム３０が高負荷状態か否かの判定に実行中セッション数を用いる場合に、単純な画面遷移要求のようなほとんど負荷のない処理要求も１つのセッションとしてカウントすると、カウント結果と実際の負荷との乖離が激しくなってしまう。
【００７２】
そこで、処理要求を、極めて短時間で処理が完了するものとそうでないものとに分類しておき、前者は実行中セッション数にカウントしないようにしてもよい。この場合、極めて短時間で処理が完了する処理要求を、保証時間外顧客からのものであっても、キュー内で待機させずに、先入れ先出し順に実行するようにしてもよい。
【００７３】
以上に例示した処理要求実行管理装置１０は、例えば、汎用のコンピュータに上述の各機能モジュールの処理を表すプログラムを実行させることにより実現してもよい。ここで、コンピュータは、例えば、ハードウエアとして、ＣＰＵ等のマイクロプロセッサ、ランダムアクセスメモリ（ＲＡＭ）およびリードオンリメモリ（ＲＯＭ）等のメモリ（一次記憶）、ＨＤＤ（ハードディスクドライブ）を制御するＨＤＤコントローラ、各種Ｉ／Ｏ（入出力）インタフェース、ローカル・エリア・ネットワークなどのネットワークとの接続のための制御を行うネットワークインタフェース等が、たとえばバスを介して接続された回路構成を有する。また、そのバスに対し、例えばＩ／Ｏインタフェース経由で、ＣＤやＤＶＤなどの可搬型ディスク記録媒体に対する読み取り及び／又は書き込みのためのディスクドライブ、フラッシュメモリなどの各種規格の可搬型の不揮発性記録媒体に対する読み取り及び／又は書き込みのためのメモリリーダライタ、などが接続されてもよい。上に例示した各機能モジュールの処理内容が記述されたプログラムがＣＤやＤＶＤ等の記録媒体を経由して、又はネットワーク等の通信手段経由で、ハードディスクドライブ等の固定記憶装置に保存され、コンピュータにインストールされる。固定記憶装置に記憶されたプログラムがＲＡＭに読み出されＣＰＵ等のマイクロプロセッサにより実行されることにより、上に例示した機能モジュール群が実現される。
【符号の説明】
【００７４】
１０  処理要求実行管理装置、１１  処理要求受付部、１３  処理要求保持部、１５  処理要求スケジュール部、１７  サービスレベルデータ保持部、１９  応答時間記録部、２０  サービスレベル登録部、３０  データ処理システム、３２  データ処理部、３４  処理用データ保持部。
【図１】
0005870635.tif 000002
【図２】
0005870635.tif 000003
【図３】
0005870635.tif 000004
【図４】
0005870635.tif 000005
【図５】
0005870635.tif 000006
【図６】
0005870635.tif 000007
【図７】
0005870635.tif 000008