(57)【要約】【課題】計算機のリソースとリクエストの実行に必要なリソースとに応じて流量の制御が効率よくできる計算機の流量制御方法を提供する。【解決手段】計算機の流量制御方法は、クライアント３からリクエストを受け取ると該リクエストをキュー１２１に格納し、格納されたキュー１２１の先頭から１つずつリクエストを取り出し、リクエストの実行に必要なリソース量を、リソース算出テーブル１５１に基づいて該リクエストの宛先に該当する算出式から算出する。算出されたリソース量が、リソース管理テーブル１５２に基づいて確保できるか否かを判定し、算出されたリソース量が確保できたとき、リソース管理テーブル１５２に算出されたリソース量を含む使用情報を登録し、リクエストの宛先のＷｅｂアプリケーション１６０に処理の実行を指示する。【選択図】図１
2011243089.tif 000002
【特許請求の範囲】
【請求項１】
記憶部と処理部とを有する計算機における、キューを用いてクライアントからのリクエストの流量を制御する計算機の流量制御方法であって、
前記記憶部には、前記リクエストの宛先と該リクエストのリソース量を算出する算出式とが関連付けられたリソース算出情報と、総リソース量と実行中の該リクエストのリソース量とを管理するリソース管理情報と、が記憶されており、
前記処理部は、
前記リクエストを受け取ると該リクエストをキューに格納し、
前記格納されたキューの先頭から１つずつリクエストを取り出し、
前記リクエストの実行に必要なリソース量を、前記リソース算出情報に基づいて該リクエストの宛先に該当する前記算出式から算出し、前記算出されたリソース量が、前記リソース管理情報に基づいて確保できるか否かを判定し、
前記算出されたリソース量が確保できたとき、前記リソース管理情報に前記算出されたリソース量を含む使用情報を登録し、
前記リクエストの宛先のアプリケーションに処理の実行を指示する
ことを特徴とする計算機の流量制御方法。
【請求項２】
前記処理部は、
前記リクエストの宛先のアプリケーションから処理の実行結果を受け取ると、前記リソース管理情報から、該当するリクエストに係る前記使用情報を削除する
ことを特徴とする請求項１に記載の流量制御方法。
【請求項３】
前記処理部は、
前記リクエストの実行に必要なリソース量を算出する際に、リソース毎に算出し、
前記判定する際に、前記リソース管理情報に基づいてリソース毎に前記算出されたリソース量が使用可能なリソース量以下であるか否かを判定する
ことを特徴とする請求項１に記載の流量制御方法。
【請求項４】
前記リソース算出情報は、さらに、
リソース毎の関係を表すリソース関係式を有し、
前記処理部は、
前記リクエストの実行に必要なリソース量を算出する際に、リソース毎に算出し、
前記判定する際に、前記リソース管理情報に基づいてリソース毎に前記算出されたリソース量が使用可能なリソース量以下であるか否かを判定するとともに、前記リソース関係式を満たすか否かを判定する
ことを特徴とする請求項１に記載の流量制御方法。
【請求項５】
キューを用いてクライアントからのリクエストの流量を制御する流量制御装置であって、
前記リクエストの宛先と該リクエストのリソース量を算出する算出式とが関連付けられたリソース算出情報と、総リソース量と実行中の該リクエストのリソース量とを管理するリソース管理情報と、が記憶される記憶部と、
前記リクエストを受け取ると該リクエストをキューに格納するキュー管理部と、
前記リクエストの実行に必要なリソース量の算出要求を受け取ると、前記リソース算出情報に基づいて該リクエストの宛先に該当する前記算出式から算出し、前記算出されたリソース量が、前記リソース管理情報に基づいて確保できるか否かを判定し、前記算出されたリソース量が確保できたとき、前記リソース管理情報に前記算出されたリソース量を含む使用情報を登録するリソース管理部と、
前記格納されたキューの先頭から１つずつリクエストを取り出し、前記リソース管理部に前記リクエストの実行に必要なリソース量の算出要求を指示し、前記算出されたリソース量が確保できたときに、前記リクエストの宛先のアプリケーションに処理の実行を指示するアプリケーション実行部とを有する
ことを特徴とする流量制御装置。
【請求項６】
前記リソース算出情報は、さらに、
リソース毎の関係を表すリソース関係式を有し、
前記リソース管理部は、
前記リクエストの実行に必要なリソース量を算出する際に、リソース毎に算出し、
前記判定する際に、前記リソース管理情報に基づいてリソース毎に前記算出されたリソース量が使用可能なリソース量以下であるか否かを判定するとともに、前記リソース関係式を満たすか否かを判定する
ことを特徴とする請求項５に記載の流量制御装置。
【請求項７】
キューを用いてクライアントからのリクエストの流量を制御する流量制御プログラムであって、
コンピュータの記憶部には、前記リクエストの宛先と該リクエストのリソース量を算出する算出式とが関連付けられたリソース算出情報と、総リソース量と実行中の該リクエストのリソース量とを管理するリソース管理情報と、が記憶されており、
前記コンピュータに、
前記リクエストを受け取ると該リクエストをキューに格納する処理と、
前記格納されたキューの先頭から１つずつリクエストを取り出し、前記リクエストの実行に必要なリソース量を、前記リソース算出情報に基づいて該リクエストの宛先に該当する前記算出式から算出し、前記算出されたリソース量が、前記リソース管理情報に基づいて確保できるか否かを判定し、前記算出されたリソース量が確保できたとき、前記リソース管理情報に前記算出されたリソース量を含む使用情報を登録する処理と、
前記リクエストの宛先のアプリケーションに処理の実行を指示する処理とを
実行させるための流量制御プログラム。
【請求項８】
前記リソース算出情報は、さらに、
リソース毎の関係を表すリソース関係式を有し、
前記使用情報を登録する処理は、
前記リクエストの実行に必要なリソース量を算出する際に、リソース毎に算出し、
前記判定する際に、前記リソース管理情報に基づいてリソース毎に前記算出されたリソース量が使用可能なリソース量以下であるか否かを判定するとともに、前記リソース関係式を満たすか否かを判定する
ことを特徴とする請求項７に記載の流量制御プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、計算機の流量制御方法、流量制御装置および流量制御プログラムに係り、特に、計算機のリソースとリクエストの実行に必要なリソースとに応じて流量の制御が効率よくできる計算機の流量制御方法、流量制御装置および流量制御プログラムに関する。
【背景技術】
【０００２】
従来、アプリケーションサーバに対するリクエストを効率的かつ安全に実行するために、キューを使用して最大同時実行数を制御する流量制御が一般的に行われている。リクエストの実行には、リクエストの実行に必要な１種類乃至は複数種類のリソースと、リクエストの実行手順のプログラムとを、実行単位であるスレッドに割り当てる必要がある。なお、リソースとは、ＣＰＵ、メモリ、ネットワーク帯域、ディスク領域など、物理的な計算機リソースや、ミューテックスやセマフォ、データベースサーバとの最大コネクション数、特定の処理の最大同時実行数などの仮想的な計算機リソースを指す。
【０００３】
リクエストを効率的かつ安全に実行するためには、同時に複数のリクエストを実行した場合に、すべてのリクエストの実行に必要なリソースの総量が、アプリケーションサーバが使用可能なリソースの総量内に納める必要がある。
【０００４】
図９は、基本的な流量制御方法を示す説明図である。一般的な技術として単純にキューを用いた場合の流量制御を模式的に示している。クライアント５０００からのリクエスト（例えば、リクエスト５２０１，５２１１，５２２１）を、アプリケーションサーバのキュー管理部５０１０のキュー５１０１に溜めて、順にアプリケーション実行部５０２０のスレッド（スレッド５３０１，５３０２）で処理している。
【０００５】
図９では、リクエストの実行に必要なリソース量をその大きさで示しており、リクエスト５２０１は必要とするリソース量が少ないリクエスト、リクエスト５２１１は必要とするリソース量が中くらいのリクエスト、リクエスト５２２１は必要とするリソース量が大きいリクエストを示す。最大リクエスト５４０１はリクエストの実行に必要なリソース量の最大を示す。リクエスト５２０１，５２１１，５２２１が混在する場合であっても、総リソース使用量をアプリケーションサーバが使用可能な総リソース内に納めるために、すべてのリクエストが最大リクエスト５４０１分のリソース量を要求すると想定し、最大同時実行数を小さくせざるを得ない。
【０００６】
そのため、たとえ最大同時実行数分動いたとしても、すべてが最大リクエスト５４０１に相当するリソース量を使用しなければ、アプリケーションサーバが使用可能なリソースが余っていることになる。
【０００７】
特許文献１には、リソースを効率的に使用する一つの方法として、キューの粒度を細かくする方法が開示されており、リクエストを実行する際に、リクエストに含まれる宛先ＵＲＬ（Uniform Resource Locator）のグループ毎に処理待ちキューを用意することで、キュー毎に最大同時実行数を制御することが可能になる。
【０００８】
図１０は、従来技術による流量制御方法を示す説明図である。図１０において、特許文献１の方法をリソースの観点に応用した例を模式的に示す。クライアント５０００からのリクエスト（リクエスト５２０１，５２１１，５２２１）をキュー管理部５０１１が受け取ると、リクエストの宛先ＵＲＬでキュー管理テーブル５０１２にある宛先ＵＲＬを検索し対応するキュー情報を取得し、リクエストの宛先ＵＲＬに対応するキュー（キュー５１０１，５１１１，５１２１）にリクエストを溜めて、順にアプリケーション実行部５０２０のスレッド（スレッド５３０１〜５３０３，５３１１，５３２１）で処理している。
【０００９】
図１０においても図９と同様に、リクエストの実行に必要なリソース量をその大きさで示しており、リクエスト５２０１は必要とするリソース量が少ないリクエスト、リクエスト５２１１は必要とするリソース量が中くらいのリクエスト、リクエスト５２２１は必要とするリソース量が大きいリクエストを示す。最大リクエスト５４１１，５４１２，５４１３は、各キュー（キュー５１０１，５１１１，５１２１）がそれぞれ想定するリクエストの実行に必要なリソース量の最大を示す。
【００１０】
リクエストの宛先とそのリクエストの実行に必要なリソース量に相関がある場合、これを利用して、キュー５１０１は小さなリソースを要求するリクエストのみの宛先専用のキューとしており、キュー５１２１は大きなリソースを要求するリクエストのみの宛先専用のキューとしている。キュー毎にスレッドを割り当てることで、アプリケーションサーバプログラムが使用可能なリソース内で、最大同時実行スレッド数を増加させることができ、リソースの効率的な使用が可能になる。
【先行技術文献】
【特許文献】
【００１１】
【特許文献１】特開２００７−２２６４０２号公報
【発明の概要】
【発明が解決しようとする課題】
【００１２】
図１０に示す流量制御方式では、リクエストが特定のキューに集中した場合であって、他のキューが全く使用されていなかったとしても、リクエストが集中しているキューの最大同時実行数以上の実行はできず、結果としてリソースが有効活用できないという問題がある。また、キューの最大同時実行数は最小で１は必要であり、キューを細かく分けても、リソースを有効活用できないばかりか、リソースの効率を逆に悪化させる場合もある。
【００１３】
また、リクエストの宛先単位でのみキューを分割するため、リソースの観点で最大同時実行数を決定する場合、宛先情報とリソース量に相関がない場合には、その宛先で受け付けうるリクエストが必要としうる最大のリソース量を想定しなければならず、これもリソースの有効活用ができない問題がある。特にアプリケーションサーバのセッション情報とリクエストが必要とするリソース量に相関がある場合が多いが、それに対応できず、さらに、リソースが複数の種類の場合は、それぞれの総リソースを想定しなければならず、リソースの有効活用ができない問題がある。
【００１４】
また、図９、図１０の例ではリソースの種類を１種類としているが、対象とするリソースの種類が増えれば増えるほどリソース効率は低下する。なぜなら、最大リクエストは、リソースの種類毎の、リクエストの実行に必要な最大のリソース量であるためである。
【００１５】
本発明は、前記の課題を解決するための発明であって、計算機のリソースとリクエストの実行に必要なリソースとに応じて流量の制御が効率よくできる計算機の流量制御方法、流量制御装置および流量制御プログラムを提供することを目的とする。
【課題を解決するための手段】
【００１６】
前記目的を達成するため、本発明の流量制御方法は、リクエストを実行しようとする際、キューに格納し、リクエストの実行に必要な１種類乃至は複数のリソース量を算出し、算出されたリクエストの実行に必要な１種類乃至は複数のリソース量が確保できた場合（例えば、使用可能な総リソース量から現在実行中のリクエストの総使用リソース量を減じた量をすべて下回る場合）、リクエストにスレッドを割り当てて実行することを特徴とする。
【発明の効果】
【００１７】
本発明によれば、計算機のリソースとリクエストの実行に必要なリソースとに応じて流量の制御が効率よくできる。
【図面の簡単な説明】
【００１８】
【図１】実施形態１に係る計算機システムの構成を示すブロック図である。
【図２】キュー管理部が保持するキューの一例を模式的に示した説明図である。
【図３】実施形態１に係るリソース算出テーブルの一例を示す説明図である。
【図４】実施形態１に係るリソース管理テーブルの一例を示す説明図である。
【図５】実施形態１に係るリクエスト実行に必要なリソース確保処理を示すフローチャートである。
【図６】実施形態１に係るリクエスト実行に必要なリソース算出処理を示すフローチャートである。
【図７】実施形態１に係るリソース割当て処理を示すフローチャートである。
【図８】実施形態１に係るリソース開放処理を示すフローチャートである。
【図９】基本的な流量制御方法を示す説明図である。
【図１０】従来技術による流量制御方法を示す説明図である。
【図１１】本発明の実施形態に係る流量制御方法を示す説明図である。
【図１２】実施形態２に係るリソース算出テーブルの一例を示す説明図である。
【図１３】実施形態２に係るリクエスト実行に必要なリソース確保処理を示すフローチャートである。
【図１４】実施形態２に係るリクエスト実行に必要なリソース算出処理を示すフローチャートである。
【図１５】実施形態２に係るリソース割当て処理を示すフローチャートである。
【図１６】実施形態に係る計算機システムの処理フローを示す説明図である。
【発明を実施するための形態】
【００１９】
以下、本発明の実施形態を図面に基づいて詳細に説明する。
図１１は、本発明の実施形態に係る流量制御方法を示す説明図である。図１１を参照して、実施形態に係る流量制御方法の概要について説明する。クライアント３は、キュー管理部１２０にリクエストを送信する。キュー管理部１２０は、リクエストをキュー１２１に格納する。アプリケーション実行部１４０は、キュー１２１からリクエストを取り出し、リソース管理部１５０にリソースの割当てを依頼する。
【００２０】
リソース管理部１５０は、リソースの割当て依頼を受けると、受け取ったリクエストとリソース算出テーブル１５１（図３参照）（リソース算出情報）からリクエストの実行に必要なリソース量を求める。次に、そのリソース量をリソース管理テーブル１５２（図４参照）（リソース管理情報）に割り当てる。なお、総リソース量５５０１や使用中のリソース量は、リソース管理テーブル１５２で管理されており、現在使用中のリソースと要求されたリソースが総リソース５５０１を下回った場合、リソースが割り当てられる。そして、アプリケーション実行部１４０は、リソースが割り当てられると、リクエストの実行手順のプログラムにリクエストとスレッド５３０１を割り当て実行する。
【００２１】
本実施形態では、リクエストの最大同時実行数を予め固定することなく、リクエストを処理する際に、算出されたリクエストの実行に必要なリソース量と、現在実行中のリクエストが使用しているリソース量と、アプリケーションサーバプログラムが使用可能な総リソース量の情報により行うため、リクエストを効率的かつ安全に処理することが可能である。また、リソース種類毎にリソースを確保するため、従来技術の方法に比べて、考慮するリソース種類が増えた場合のリソース効率を改善することができる。
【００２２】
以降に説明する実施形態の例として、リソースＡ、リソースＢおよびリソースＣを対象に流量制御することを説明する。リソースＡ、リソースＢ、リソースＣは、例えばＣＰＵの処理性能やメモリの使用量であってもよい。この場合、リソースＡがＣＰＵ性能を示す場合、ＣＰＵの性能が例えば１００ＧＦｌｏｐｓでリソースの使用単位が１ＧＦｌｏｐｓとすると、最大が１００となる。あるリクエストがリソースＡを５必要とする場合は、そのうちの５ＧＦｌｏｐｓを利用するという意味になる。
【００２３】
また、別の例としてＣＰＵ使用率を指すこともできる。この場合、例えば最大を１００％とし、あるリクエストがリソースＡを５必要とする場合は、そのうちの５％を利用するという意味になる。
【００２４】
リソースがメモリである場合も、メモリ総量あたりの割合を示し、各リクエストはその割合を要求してもよく、また、具体的なメモリ総量を総リソース量にして、各リクエストは具体的なメモリ使用量を要求してもよい。また、リソースは最大数が規定でき増減可能なものであれば、計算機資源である必要はない。例えば、特定の処理の同時実行スレッド数などでもよい。
【００２５】
<<実施形態１>>
図１は、実施形態１に係る計算機システムの構成を示すブロック図である。本実施形態の計算機システムは、計算機１がネットワーク２を介して少なくとも１つ以上のクライアント３と接続されて構成されている。計算機１（流量制御装置）は、ＣＰＵ（Central Processing Unit）１１（処理部）、メモリ１２（記憶部）、インターフェース１３、補助記憶装置１４を備える。ＣＰＵ１１は、ワークエリアとしてのメモリ１２に、補助記憶装置１４に格納されたプログラムを展開し、各種プログラムを実行する。この処理を実行する単位はスレッドである。メモリ１２は、計算機１が処理を実行する各種プログラムおよび一時的なデータを保持する。補助記憶装置１４は、例えばＨＤＤ（Hard disk drive）などの不揮発メモリを指す。インターフェース１３は、ネットワーク２に接続され、クライアント３と通信する。
【００２６】
計算機１は、所定のアプリケーションサーバプログラム１００などを実行することによりアプリケーションサーバとして機能する。クライアント３は、ネットワーク２を介して計算機１に所定のリクエストを送信し、アプリケーションサーバプログラム１００は、リクエストに対する処理を実行し、その結果をクライアント３に送信するようになっている。なお、ネットワーク２は、ＬＡＮ（Local Area Network）、ＷＡＮ（Wide Area Network）、専用線およびインターネットなどの種々の構成を適用可能である、本実施形態では、ＬＡＮを適用するものとして説明する。
【００２７】
メモリ１２には、アプリケーションサーバプログラム１００が格納されている。アプリケーションサーバプログラム１００は、ディスパッチャ１１０、キュー管理部１２０、アプリケーション実行部１４０、リソース管理部１５０およびＷｅｂアプリケーション１６０（Ｗｅｂアプリケーション１６１，１６２）などによって構成されている。
【００２８】
ディスパッチャ１１０は、クライアント３から受信したリクエストをキュー管理部１２０に送信する。キュー管理部１２０は、リクエストを受け取るとそのリクエストをキュー１２１に格納し、アプリケーション実行部１４０に渡す。
【００２９】
アプリケーション実行部１４０は、キュー１２１の先頭から１つずつリクエストを取り出し、リソース管理部１５０にリクエストが必要とするリソース量分の確保を依頼する。アプリケーション実行部１４０は、リソースが確保された後、Ｗｅｂアプリケーション１６１または１６２に送信する（本実施形態では、１６１に送信するものとする。）。Ｗｅｂアプリケーション１６１がリクエストを受信すると、該当する業務１７０（業務１７１または業務１７２）が、リクエストに対応する処理を実行する（本実施形態では、業務１７１が実行するものとする）。すなわち、アプリケーション実行部１４０は、リソースが確保されたら、実行スレッドをＷｅｂアプリケーション１６０の業務１７０に割り当て、当該リクエストに対応する処理を実行する。
【００３０】
アプリケーション実行部１４０は、当該リクエストに対応する処理が完了したら、リソース管理部１５０に当該リクエストに対応するリソースの解放を依頼する。
【００３１】
リソース管理部１５０は、リソース算出テーブル１５１（図３参照）とリソース管理テーブル１５２（図４参照）を有しており、リクエストへのリソース割当てを受信すると、まず、リクエストの内容に基づいて、リクエストに対するリソース量の算出方法に関する情報を管理するリソース算出テーブル１５１を参照して、リクエストが必要とするリソース量を算出する。リソース管理部１５０は、そのリソース量の割当てを、リソース管理テーブル１５２（図４参照）を参照して実行する。
【００３２】
リソース量の算出は、受信したリクエストとリソース算出テーブル１５１を参照して、受信したリクエストが必要とするリソース量をリソースＡからリソースＣまですべて求める。このリソース量の算出の際、アプリケーションサーバプログラム１００が保持するセッション情報などにもアクセスでき、セッション情報などを利用したリソース量の算出もできる。なお、リソース算出テーブル１５１および具体的なリソース量の算出方法の詳細は後述する。
【００３３】
リソース量の割当ては、リソース管理テーブル１５２を参照してリソースの空き容量を求め、要求されたリソース量が割り当て可能か判断し、リソースが割り当て可能であれば、リソース管理テーブル１５２に対象のリソースの使用情報を追加する。割り当て不可能であれば、割当て要求を保留し割り当て可能になるまで待機する。また、リソース管理部１５０は、リソース解放依頼を受けると、リソース管理テーブル１５２から対象のリソースの使用情報を削除する。なお、リソース管理テーブル１５２および具体的なリソース量の割当て方法の詳細は後述する。
【００３４】
本実施形態によれば、リソース管理部１５０を使用することによって、Ｗｅｂアプリケーション１６０の業務１７０に対する流量を制御することができるようになっている。
【００３５】
図２は、キュー管理部１２０が保持するキュー１２１の一例を模式的に示した説明図である。キュー１２１は、リクエストフィールド２１０を有し、リクエストフィールド２１０は、そのリクエストを構成するすべての要素を含む。
【００３６】
リクエストフィールド２１０に格納されるエントリは、リクエストを構成するすべての要素である。リクエストは、ヘッダとボディから構成される。リクエストのヘッダには、宛先ＵＲＬやリクエストの電文長、クエリ文字列、クッキー情報などが含まれる。ボディには、ＰＯＳＴデータが含まれる。図２に示すリクエストフィールド２１０には、本実施形態で注目するヘッダ情報のみを示している。例えば図２の例では、ヘッダの宛先ＵＲＬである「ＵＲＬ：」で始まる文字列と、クエリ文字列である「Ｑｕｅｒｙ：」およびクッキー情報である「Ｃｏｏｋｉｅ：」で始まる文字列が含まれる。
【００３７】
１番目のエントリ２１０１のリクエストフィールド２１０には、「ＵＲＬ：／ＸＸＸ／ａａａ」が含まれるリクエストが格納されている。これは宛先ＵＲＬが「／ＸＸＸ／ａａａ」であることを示している。
【００３８】
また、２番目のエントリ２１０２のリクエストフィールド２１０には、「ＵＲＬ：／ＹＹＹ／ｂｂｂ」と「Ｑｕｅｒｙ：ｉｔｅｍ＝２０」が含まれるリクエストが格納されている。これは宛先ＵＲＬが「／ＹＹＹ／ｂｂｂ」であり、クエリ文字列が「ｉｔｅｍ＝２０」であることを示している。
【００３９】
また、４番目のエントリ２１０４のリクエストフィールド２１０には、「ＵＲＬ：／ＺＺＺ／」と「Ｃｏｏｋｉｅ：ＪＳＥＳＳＩＯＮＩＤ＝１２３４」というリクエストが格納されている。これは宛先ＵＲＬが「／ＺＺＺ／」であり、クッキー情報が「ＪＳＥＳＳＩＯＮＩＤ＝１２３４」であることを示している。
【００４０】
図３は、実施形態１に係るリソース算出テーブル１５１の一例を示す説明図である。図３を参照して、リソース管理部１５０が保持するリソース算出テーブル１５１について説明する。リソース算出テーブル１５１は、リクエストに対するリソース量の計算方法を示すテーブルである。リソース算出テーブル１５１は、マッチング式フィールド３１０と、リソース算出式フィールド３２０とを含む。リソース算出式フィールド３２０は、この例ではリソースＡ算出式フィールド３２１とリソースＢ算出式フィールド３２２とリソースＣ算出式フィールド３２３から構成される。本実施形態の計算機１（流量制御装置）では、リソースＡ、リソースＢおよびリソースＣを対象に流量制御するからである。
【００４１】
リソース算出テーブル１５１のマッチング式フィールド３１０は、リクエストとマッチする（一致する）エントリを探すために利用する。リソース算出式フィールド３２０はマッチしたリクエストのリソース量を算出するために利用する。
【００４２】
この例では、マッチング式フィールド３１０は、リクエストの宛先ＵＲＬに対する正規表現として記述している。リソース算出式フィールド３２０は、簡単なプログラム形式で記述している。この例によらず、マッチング式フィールド３１０はリクエストからリソース算出テーブル１５１のエントリを算出できれば、例えばプログラムでもよく、リソース算出式フィールド３２０はリテラルのみでもよい。
【００４３】
また、リクエスト内の情報だけではリクエストの実行に必要なリソース量を求められない場合がある。例えば、アプリケーションサーバプログラムが管理するＷｅｂアプリケーションのセッション情報内に必要な情報がある場合は、リクエスト中にあるセッションの識別情報であるＪＳＥＳＳＩＯＮＩＤなどを利用して、対応するセッション情報を検索し、そのセッション情報内のデータを利用して、リクエストの実行に必要なリソース量を求めることもできる。
【００４４】
なお、リソース算出テーブル１５１の最後のエントリは、すべてのリクエストにマッチするマッチング式で構成されている。このエントリは「デフォルト」と呼ぶ。リソース算出テーブル１５１の他のどのマッチング式にもマッチしなかったリクエストは結果的にこのエントリで処理され、リソースが算出される。
【００４５】
図４は、実施形態１に係るリソース管理テーブル１５２の一例を示す説明図である。図４を参照して、リソース管理部１５０が保持するリソース管理テーブル１５２について説明する。リソース管理テーブル１５２は、リソースフィールド４１０を含む。リソースフィールド４１０は、この例ではリソースＡフィールド４１１と、リソースＢフィールド４１２と、リソースＣフィールド４１３とから構成される。他のリソースを対象に流量制御する場合は、このフィールドは増減しうる。
【００４６】
なお、一番目のエントリ４１００は、アプリケーションサーバプログラム１００が使用可能な総リソース量を示しており、値は正である。一番目以外のエントリ４１０１〜４１０３は、実行しているリクエストが使用しているリソース量を示しており、値は負または０である。
【００４７】
リソースフィールド４１０の内訳毎（この例ではリソースＡフィールド４１１、リソースＢフィールド４１２およびリソースＣフィールド４１３毎）に全エントリを合算した確保済みのリソース量を求め、使用可能な総リソース量から、確保済みのリソース量を減算すると、現時点での使用可能なリソース量がリソースの種類毎に求まる。
【００４８】
具体的には、リソースＡに関しては、エントリ４１００から使用可能な総リソース量は５００であり、エントリ４１０１〜４１０３により、５、４０、５がすでに確保されており、現時点での使用可能なリソース量は、４５０（＝５００−５−４０−５）となる。同様に、リソースＢに関しては、使用可能なリソース量は０（＝１−０−１−０）であり、これ以上には割り当てできないことがわかる。
【００４９】
次に、流量制御の全体処理について説明する。
図１６は、実施形態に係る計算機システムの処理フローを示す説明図である。図１６は、図１に示したブロック図に、処理符号（ステップ符号）を付加したものである。クライアント３がリクエストを送信する。アプリケーションサーバプログラム１００において、ディスパッチャ１１０がクライアント３から送信されたリクエストを受信する（ステップＳ２００１）。
【００５０】
ディスパッチャ１１０は、受信したリクエストを、当該リクエストに対応するキュー管理部１２０に送信する（ステップＳ２００２）。キュー管理部１２０は、リクエストをキュー１２１に格納する（ステップＳ２００３）。
【００５１】
アプリケーション実行部１４０は、キュー１２１の先頭から１つエントリを取り出す（ステップＳ２００４）。アプリケーション実行部１４０は、リソース管理部１５０にリソース量分の確保を依頼する（ステップＳ２００５）。
【００５２】
リソース管理部１５０は、リソース算出テーブル１５１を参照して、リクエストにマッチするエントリを検索し、エントリを用いてリクエストの実行に必要なリソース量を算出する（ステップＳ２００６）。リソース管理部１５０は、リソース管理テーブル１５２を参照して、空きリソースの情報を取得し、空きリソースが要求リソースを上回るまで待つ。空きリソースが要求リソースを上回ったら、リソース管理テーブル１５２に要求リソースのエントリを追加してリソースを割り当てる（ステップＳ２００７）。
【００５３】
アプリケーション実行部１４０は、リソースが確保されたら、実行スレッドをＷｅｂアプリケーション１６１の業務１７１に割り当て、リクエストの情報に基づいて業務を実行する（ステップＳ２００８）。このリクエストの処理が終了すると、Ｗｅｂアプリケーション１６１は、アプリケーション実行部１４０に処理結果を送信する（ステップＳ２００９）。アプリケーション実行部１４０は、Ｗｅｂアプリケーション１６０の処理結果を受信すると、リソース管理部１５０に当該リクエストに対応するリソースの解放を依頼する（ステップＳ２０１０）。
【００５４】
リソース管理部１５０は、リソース管理テーブル１５２から当該リソースのエントリを削除し、リソースを解放する（ステップＳ２０１１）。アプリケーション実行部１４０は、リソース解放処理が終了すると、リクエストの処理結果をクライアント３に送信する（ステップＳ２０１２）。
【００５５】
次に、各機能部の詳細な処理について説明する。
図５は、実施形態１に係るリクエスト実行に必要なリソース確保処理を示すフローチャートである。図５を参照して、図１６で示した計算機システムの処理フローのうち、リソース管理部１５０のリソース確保処理について説明する。リソース管理部１５０は、リソースを確保するリクエストを、アプリケーション実行部１４０から受信すると（ステップＳ１００１）、リソース算出処理に前記リクエストを渡して呼び出し、リクエストの実行に必要なリソース量を算出し（ステップＳ１００２）、ステップＳ１００３に進む。
【００５６】
リソース管理部１５０は、リソース割当て処理に前記リソース量を渡して呼び出し、リソースを割り当て、そのエントリの識別子を取得する（ステップＳ１００３）。前記エントリの識別子を呼び出し元であるアプリケーション実行部１４０に返却する（ステップＳ１００４）。なお、ステップＳ１００２の詳細については図６を参照して、ステップＳ１００３の詳細については、図７を参照して説明する。
【００５７】
図６は、実施形態１に係るリクエスト実行に必要なリソース算出処理を示すフローチャートである。適宜図２および図３を参照する。リソース管理部１５０は、リソースを算出すべきリクエストを受信すると（ステップＳ１１０１）、リソース算出テーブル１５１のマッチング式フィールド３１０を使用して、リクエストの宛先ＵＲＬで検索する（ステップＳ１１０２）。
【００５８】
例えば、ステップＳ１１０１で受信したリクエストが図２のキュー１２１の１番目のエントリ２１０１に相当するリクエストの場合、リクエストの宛先ＵＲＬは「／ＸＸＸ／ａａａ」である。これをリソース算出テーブル１５１の先頭からマッチングしていく。図３のリソース算出テーブル１５１の一番目のエントリのマッチング式フィールド３１０は、「＾／ＸＸＸ／．＊」であるので、正規表現として解釈すると「／ＸＸＸ／」で始まる任意の文字列となる。よって、マッチすることからこのエントリを発見できる。
【００５９】
また、ステップＳ１１０１で受信したリクエストが図２のキュー１２１の５番目のエントリ２１０５に相当するリクエストの場合、宛先ＵＲＬ「／ｂｂｂ／」は、リソース算出テーブル１５１の１番目、２番目、３番目のマッチング式にはマッチしない。しかしながら、最後のエントリである「．＊」という正規表現には、すべての文字列がマッチするため、最後のエントリを発見できる。
【００６０】
発見したエントリのリソース算出式フィールド３２０とステップＳ１１０１で受信したリクエストを使用してリクエストの実行に必要なリソース量を求める。例えば、ステップＳ１１０１で受信したリクエストが図２のキュー１２１の１番目のエントリ２１０１に対応するリクエストの場合、リソース算出テーブル１５１の１番目のエントリが発見されているため、そのエントリのリソース算出式フィールド３２０をそれぞれ計算する。エントリのリソースＡ算出式３２１は、「５」であるためリソースＡを５必要とすることが求められる。同エントリのリソースＢ算出式３２２およびリソースＣ算出式３２３は、「０」であるためリソースＢとリソースＣの必要量は０、つまり必要としないことが求められる。
【００６１】
例えば、ステップＳ１１０１で受信したリクエストが図２のキュー１２１の２番目のエントリ２１０２に相当するリクエストの場合、リソース算出テーブル１５１の２番目のエントリが発見されているため、そのエントリのリソース算出式フィールド３２０をそれぞれ計算する。エントリのリソースＡ算出式３２１は、「Ｈｅａｄｅｒ［“Ｑｕｅｒｙ”］［“ｉｔｅｍ”］＊２」という式であるためヘッダから「Ｑｕｅｒｙ」という要素を抜き出し、つぎにその中から「ｉｔｅｍ」に対応する要素を取り出す。リクエストの「Ｑｕｅｒｙ」の「ｉｔｅｍ」「２０」である。この「２０＊２」を計算することにより「４０」が得られる。よってリソースＡを４０必要とすることが算出される。同様にエントリのリソースＢ算出式３２２は「１」であるため、リソースＢを１必要とし、エントリのリソースＣ算出式３２３は「１」であるため、リソースＣを１必要とすることが算出される。
【００６２】
同様に、ステップＳ１１０１で受信したリクエストが図２のキュー１２１の４番目のエントリ２１０４に相当するリクエストの場合、リソース算出テーブル１５１の３番目のエントリが発見されているため、そのエントリのリソース算出式フィールド３２０をそれぞれ計算する。エントリのリソースＡ算出式３２１は、「Ｓｅｓｓｉｏｎ［Ｈｅａｄｅｒ［“ｃｏｏｋｉｅ”］［“ＪＳＥＳＳＩＯＮＩＤ”］］［“ｉｔｅｍ”］＊５」という式であるためヘッダから「ｃｏｏｋｉｅ」という要素を抜き出し、その中から「ＪＳＥＳＳＩＯＮＩＤ」に対応する要素を取り出す。この例では「１２３４」となる。この「１２３４」で別途アプリケーションサーバプログラムが管理しているセッション情報を参照し、その中の「ｉｔｅｍ」に対応する要素を取り出す。ここではその値を「２」とする。そして、「２＊５」を計算することにより「１０」が得られる。よってリソースＡを１０必要とすることが算出される。同様にエントリのリソースＢ算出式３２２は「１」であるため、リソースＢを１必要とし、エントリのリソースＣ算出式３２３は「０」であるため、リソースＣを必要としないことが算出される。
【００６３】
リソース管理部１５０は、リクエストの実行に必要なリソース量の算出結果を返却する（ステップＳ１１０４）。例えば、ステップＳ１１０１で受信したリクエストが図２のキュー１２１の２番目のエントリに相当するリクエストの場合、リソースＡは４０、リソースＢは１、リソースＣは１という結果を返却する。
【００６４】
図７は、実施形態１に係るリソース割当て処理を示すフローチャートである。適宜図２、図４を参照する。リソース管理部１５０は、要求リソース量を受信すると（ステップＳ１２０１）、要求リソース量が総リソース量と同じか下回っているか判定する（ステップＳ１２１１）。このとき、総リソース量は、リソース管理テーブル１５２のリソースフィールド４１０に対応する最初のエントリ４１００である。
【００６５】
リソース管理部１５０は、要求リソースが総リソースを上回っていた場合（ステップＳ１２１１，Ｎｏ）、リソースの確保は不可能なので、エラーが発生したことを示す応答をクライアント３へ送信し（ステップＳ１２１２）、処理を終了する。リソース管理部１５０は、要求リソース量が総リソースと同じか下回っていた場合（ステップＳ１２１１，Ｙｅｓ）、ステップＳ１２０２に進む。なお、ステップＳ１２１１の判定は、リソースの種類毎に行い、リソースの種類の１つでも要求リソースが総リソース量を上回っていた場合はエラーとする。
【００６６】
リソース管理部１５０は、要求リソース量が空きリソース量と同じか下回っているか判定する（ステップＳ１２０２）。このとき、空きリソース量は、リソース管理テーブル１５２のリソースフィールド４１０に対応するフィールドを総計することで求める。また、判定は、リソースの種類毎に行う。
【００６７】
リソース管理部１５０は、リソースの種類の１つでも要求リソース量が空きリソース量を上回っていた場合（ステップＳ１２０２，Ｎｏ）、リソースが空くまで待つ（ステップＳ１２０３）。処理は時間の経過とともに終了していくので、後述するリソース管理部１５０のリソース解放処理によってリソースは解放され、空きリソース量は増加し、ステップＳ１２０３は終了し、ステップＳ１２０２に戻る。
【００６８】
リソース管理部１５０は、すべてのリソースの種類の要求リソース量が空きリソース量と同じか下回っていた場合（ステップＳ１２０２，Ｙｅｓ）、リソースフィールド４１０に要求リソース量のおのおのの値に−１を乗じた値をエントリとして追加し（ステップＳ１２０４）、追加したエントリの識別子を呼び出し元であるアプリケーション実行部１４０に返却し（ステップＳ１２０５）、リソース割当て処理を終了する。
【００６９】
図７に示すリソース割当て処理に関し、図２から図４を参照して、具体例を説明する。リソース管理テーブル１５２の状態が図４の状態であり、図２の状態のキュー１２１を処理していた場合、図２のキュー１２１の最初のエントリ２１０１は、リソースが確保可能なので、図２のキュー１２１のリソースフィールド２２０の各値に−１を乗じたものがリソース管理テーブルに追加され、ステップＳ１２０５によってエントリの識別子が返却される。
【００７０】
図２のキュー１２１の２番目のエントリ２１０２は、リソースＡを４０、リソースＢを１、リソースＣを１必要とする。図４のリソースのそれぞれの空き容量を求めるとリソースＡは４９５、リソースＢは０、リソースＣは４である。リソースＡの要求リソース量４０を満たし、リソースＣも要求リソース量０を満たすが、リソースＢは要求リソース量１に対して空きリソース量０である。リソースの種類中１つでも要求リソース量が空きリソース量を超えているという条件を満たすため、ステップＳ１２０３へ進む。
【００７１】
このとき、アプリケーション実行部１４０は、現在実行中のリクエストの処理は継続するが、リソース管理部１５０に対するリソース確保要求は同時に１回しか行わない。時間が進み、リソースＢを確保していたリクエストの処理が終わると、後述するリソース解放処理によってリソースＢが解放され、次回のステップＳ１２０２による判定により、ステップＳ１２０４へ進むことができる。
【００７２】
図８は、実施形態１に係るリソース開放処理を示すフローチャートである。本実施形態の計算機システムの処理のうち、リソース管理部１５０の処理のうちリソース解放処理について説明する。適宜図２、図４を参照する。
【００７３】
リソース管理部１５０は、アプリケーション実行部１４０からエントリの識別子を受信する（ステップＳ１３０１）。リソース管理部１５０は、リソース管理テーブルからエントリの識別子に対応するエントリを見つけ、削除する（ステップＳ１３０２）。具体的には、図２に示す最初のエントリ２１０１の処理が終了すると、図４に示す最初のエントリ４１０１の使用情報を削除することになる。
【００７４】
以上のように、実施形態では、空きリソース量によって流量制御が可能になる。従って、あらかじめキュー毎にリソースを確保するよりもリソースの効率化が可能となる。また、リクエストに直接含まれる情報だけでなく、リクエストに含まれる情報から間接的に参照されるセッションなどの情報からリソース量を求めることが可能になり、適切なリソース量算出が可能となる。
【００７５】
<<実施形態２>>
実施形態１においては、リソース管理部１５０は、リソース量を割り当てる際に、リソースの種類毎に要求リソース量をすべて満たすことが条件で処理していたが、これに限定されるものではない。実施形態２においては、性質の近しいリソースＢとリソースＣがあり、あるリクエストはどちらか片方のリソース量が満たせればよいという条件で処理できる（いいかえると、柔軟に対応できる）制御フローについて説明する。
【００７６】
具体的には、リソースの要求に柔軟性を持たせるため、リソース関係式を用いる。リソース関係式は、どのリソースが必ず必要で、どのリソースが他のリソースで代替できるのかを示す式である。実施形態２を、図４、図６、図１２〜図１５を用いて説明する。なお、実施形態１の図３に対応するのが図１２であり、図６に対応するのが図１４であり、図７に対応するのが図１５である。
【００７７】
図１２は、実施形態２に係るリソース算出テーブル１５１Ａの一例を示す説明図である。図１２に示すリソース算出テーブル１５１Ａには、図３のリソース算出テーブル１５１にリソース関係式フィールド３３０を加えたものである。リソース関係式３３０は、リソース算出式で求められたリソース量をどのように解釈するかを示した式で、「Ａ＆（Ｂ｜Ｃ）」のような論理式で示される。
【００７８】
リソース算出式３３０は、ブール代数として解釈する。つまり、「Ａ＆（Ｂ｜Ｃ）」のような論理式の場合、リソースＡのリソース確保は必要で、かつ、リソースＢまたはリソースＣのどちらかがのリソース確保が必要であるとする。例えば、リソースＡが確保できなければ常にリソース確保に失敗し、また、リソースＢもリソースＣもリソースが確保できない場合もリソース確保に失敗する。リソースＡとリソースＢが確保できた場合、または、リソースＡとリソースＣが確保できた場合、およびリソースＡ〜Ｃのすべてのリソースが確保できた場合はリソースの確保に成功する。
【００７９】
また、より好適には、この論理式の「｜」の評価順序を定義すると、どちらでもよいリソース量の解釈に優先度を持たせることができる。具体的には、必ず左から右の順でリソースの確保を試みるとすると、「Ａ｜Ｂ」はリソースＡの確保を試みて、リソースＡが確保できればそれでリソース確保とし、確保できなければリソースＢの確保を試みる。そして、リソースＢが確保できればリソース確保とし、確保できなければリソース確保失敗となる。これは、リソースＡを優先的に利用したい場合に効果的である。
【００８０】
次に、各機能部の詳細な処理について説明する。
図１３は、実施形態２に係るリクエスト実行に必要なリソース確保処理を示すフローチャートである。図１３は、図５に示すフローチャートに対応する図であり、図５のリソース量の算出結果を受け取るステップＳ１００２がリソース量だけでなくリソース関係式を受け取るように変更し（ステップＳ１００２Ａ）、また、リソースの割当て処理の呼び出しステップＳ１００３にリソース量だけでなく、リソースの関係式も渡すように変更した（ステップＳ１００３Ａ）。
【００８１】
図１４は、実施形態２に係るリクエスト実行に必要なリソース算出処理を示すフローチャートである。図１４に示すステップＳ１００２Ａは、図６に示すステップＳ１００２に対応する図である。図１４は、図６のリソース量の算出結果を呼び出し元に返却するステップＳ１１０４を、リソース量の算出結果だけでなく、追加でリソース関係式も返却するように変更している（ステップＳ１１０４Ａ）。
【００８２】
図１５は、実施形態２に係るリソース割当て処理を示すフローチャートである。図１５に示すステップＳ１００３Ａは、図７に示すステップＳ１００３に対応する図である。図１５は、図７のステップの内、ステップＳ１２０１、ステップＳ１２１１、ステップＳ１２０２、ステップＳ１２０４に変更がある。
【００８３】
ステップＳ１２０１Ａにおいて、リソース管理部１５０は、アプリケーション実行部１４０から、要求リソース量に加え、リソース関係式も受信する。ステップＳ１２１１Ａにおいて、リソース管理部１５０は、要求リソース量が総リソース量と同じか下回っているか判定する際に、リソース関係式を使用する。リソース関係式を解釈し、要求リソースが総リソースで確保できるか判定する。
【００８４】
例えば、リソース関係式が「Ａ」なら、リソースＡだけ要求リソース量と総リソース量を比較し、要求リソース量が総リソース量を上回っていた場合、リソースの確保は不可能と判定する。リソース関係式が「Ｂ＆Ｃ」なら、リソースＢとリソースＣだけ要求リソース量と総リソース量を比較し、リソースＢとリソースＣのどちらかが総リソース量を上回っていた場合、リソースの確保は不可能と判定する。リソース関係式が「Ｂ｜Ｃ」なら、リソースＢとリソースＣだけ要求リソース量と総リソース量を比較し、リソースＢとリソースＣのどちらも総リソース量を上回っていた場合、リソースの確保は不可能と判定する。
【００８５】
ステップＳ１２０２Ａにおいて、要求リソース量が空きリソース量と同じか下回っているか判定する際に、リソース関係式を使用する。このときの判定方法は、ステップＳ１２１１Ａと同様である。ステップＳ１２０４Ａでは、リソースをリソース管理テーブル１５２に登録する際に、確保したリソースだけを登録する。つまり、リソース関係式「Ａ＆Ｂ」の場合、リソースＡとリソースＢに対応する要求リソース量に−１を乗じた値をエントリとして追加する。また、「Ａ｜Ｂ」の場合は、確保できると判断できたリソースＡまたはリソースＢのどちらかに対応する要求リソース量に−１を乗じた値をエントリとして追加する。
【００８６】
以上のように、リソース関係式を用いることで、リソースＢがなければリソースＣでも代替可能のような、より柔軟なリソースの確保が可能になる。
【符号の説明】
【００８７】
１    計算機（流量制御装置）
２    ネットワーク
３    クライアント
１１    ＣＰＵ（処理部）
１２    メモリ（記憶部）
１３    インターフェース
１４    補助記憶装置
１００    アプリケーションサーバプログラム
１１０    ディスパッチャ
１２０    キュー管理部
１２１    キュー
１４０    アプリケーション実行部
１５０    リソース管理部
１５１    リソース算出テーブル（リソース算出情報）
１５２    リソース管理テーブル（リソース管理情報）
１６０    Ｗｅｂアプリケーション
１７０    業務
【図１】
2011243089.tif 000003
【図２】
2011243089.tif 000004
【図３】
2011243089.tif 000005
【図４】
2011243089.tif 000006
【図５】
2011243089.tif 000007
【図６】
2011243089.tif 000008
【図７】
2011243089.tif 000009
【図８】
2011243089.tif 000010
【図９】
2011243089.tif 000011
【図１０】
2011243089.tif 000012
【図１１】
2011243089.tif 000013
【図１２】
2011243089.tif 000014
【図１３】
2011243089.tif 000015
【図１４】
2011243089.tif 000016
【図１５】
2011243089.tif 000017
【図１６】
2011243089.tif 000018