(57)【要約】【課題】重要なリクエストに対するレスポンスを適切に制御する。【解決手段】実施形態における負荷制御装置は、操作対象のリソースを識別する識別情報を含み、前記リソースの操作を要求するためのリクエストおよびこのリクエストの最新の受信時刻を、リクエストキューに追加する前のリクエストとして管理する管理手段と、新たなリクエストを受信する受信手段と、前記受信したリクエストの受信時刻と、前記管理する、このリクエストに含まれる識別情報と同じ識別情報を含むリクエストの受信時刻との差分である差分値を計算する計算手段と、前記管理する、前記識別情報が異なる複数のリクエストのうち、前記計算手段により計算した前記差分値が大きいリクエストを、優先して前記リクエストキューに追加するリクエストとして指定する指定手段とを有する。【選択図】図１
2018025864.tif 000002
【特許請求の範囲】
【請求項１】
操作対象のリソースを識別する識別情報を含み、前記リソースの操作を要求するためのリクエストおよびこのリクエストの最新の受信時刻を、リクエストキューに追加する前のリクエストとして管理する管理手段と、
新たなリクエストを受信する受信手段と、
前記受信したリクエストの受信時刻と、前記管理する、このリクエストに含まれる識別情報と同じ識別情報を含むリクエストの最新の受信時刻との差分である差分値を計算する計算手段と、
前記管理する、前記識別情報が異なる複数のリクエストのうち、前記計算手段により計算した前記差分値が大きいリクエストを、優先して前記リクエストキューに追加するリクエストとして指定する指定手段と
を備えたことを特徴とする負荷制御装置。
【請求項２】
前記リクエストは、前記要求する操作の種別を含み、
前記計算手段は、
前記受信したリクエストの受信時刻と、前記管理する、このリクエストに含まれる識別情報と同じ識別情報を含むリクエストの最新の受信時刻との差分である第１の差分値を計算する第１の計算手段、および、
前記受信したリクエストの受信時刻と、前記管理されて、前記受信したリクエストに含まれる識別情報と同じ識別情報を含み、前記受信したリクエストが要求する操作と同じ操作を要求するリクエストの最新の受信時刻との差分である第２の差分値を計算する第２の計算手段を含み、
前記指定手段は、
前記管理する、前記識別情報が異なる複数のリクエストについて、前記第１の計算手段により計算した前記第１の差分値が大きい順に、優先して前記リクエストキューに追加するリクエストとして指定し、
前記識別情報が異なる前記複数のリクエストについて前記計算した前記第１の差分値が同じである場合は、前記複数のリクエストについて、前記第２の計算手段により計算した前記第２の差分値が大きい順に、前記優先して前記リクエストキューに追加するリクエストとして指定する
ことを特徴とする請求項１に記載の負荷制御装置。
【請求項３】
前記指定手段は、
前記識別情報が異なる前記複数のリクエストについて前記計算した前記第１の差分値が同じであって、かつ、前記識別情報が異なる前記複数のリクエストについて前記計算した前記第２の差分値が同じである場合は、前記受信したリクエストの受信時刻が古い順に、優先して前記リクエストキューに追加するリクエストとして指定する
ことを特徴とする請求項２に記載の負荷制御装置。
【請求項４】
前記受信したリクエストを追加する前記リクエストキューは、リクエストが要求する操作の種別に応じて区分される
ことを特徴とする請求項１に記載の負荷制御装置。
【請求項５】
負荷制御装置に適用される方法であって、
操作対象のリソースを識別する識別情報を含み、前記リソースの操作を要求するためのリクエストおよびこのリクエストの最新の受信時刻を、リクエストキューに追加する前のリクエストとして管理し、
新たなリクエストを受信し、
前記受信したリクエストの受信時刻と、前記管理する、このリクエストに含まれる識別情報と同じ識別情報を含むリクエストの受信時刻との差分である差分値を計算し、
前記管理する、前記識別情報が異なる複数のリクエストのうち、前記計算した前記差分値が大きいリクエストを、優先して前記リクエストキューに追加するリクエストとして指定する
ことを特徴とする負荷制御方法。
【請求項６】
請求項１に記載の負荷制御装置の一部分として動作するコンピュータに用いられるプログラムであって、
前記コンピュータを、
前記管理手段、前記受信手段、前記計算手段、および前記指定手段
として機能させるための負荷制御処理プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明の実施形態は、負荷制御装置、負荷制御方法および負荷制御処理プログラムに関する。
【背景技術】
【０００２】
インターネットの普及に伴い、ネットワークを介して様々なサービスを利用できるようになっている。メール、ホームページの閲覧、検索、オンライン取引、ＩＰ電話、ビデオオンデマンドなどは、その一例である。これらのネットワークサービスは様々な形態で提供し得るが、近年、クライアントとのインタフェースとして、Ｗｅｂサーバの利用が主流となっている。
【０００３】
Ｗｅｂサーバを用いたサービス（Ｗｅｂサービス）の基本的な仕組みは以下のとおりである。まず、クライアントがＷｅｂサーバに対して、取得したいコンテンツを識別するＵＲＬ(Uniform Resource Locator)を付与したリクエストを送信する。Ｗｅｂサーバがリクエストを受け取ると、リクエスト中のＵＲＬに対するコンテンツをレスポンスとしてクライアントに送り返す。Ｗｅｂサービスは、このリクエスト−レスポンスの繰り返しによって提供される。
【０００４】
ここでは、Ｗｅｂサービスを行うサーバシステム全体をＷｅｂサーバ、また、Ｗｅｂサーバ上でリクエストに応じたコンテンツを生成する機能をＷｅｂアプリケーションと呼ぶ。
【０００５】
従来技術では、サーバは、リクエストに対するレスポンスの優先度を、リクエストの送信元のクライアントのIPアドレスごとに動的に決定する。
【０００６】
具体的には、クライアントによるWebページアクセス時の、サーバへの最初のアクセスから、サーバからページ内コンテンツを取得するまでの一連のリクエストや、セッション中の一連のページ遷移リクエストを、クライアントのIPアドレス単位で優先的に処理を行なう。
【０００７】
ここで、REST API（アプリケーションプログラミングインタフェース）に適用される負荷制御システムについて説明する。図７は、従来の負荷制御システムの機能構成例を示すブロック図である。  
図７に示すように、従来の負荷制御システムのサーバ１００は、アプリケーション通信部１０１、優先度付与部１０２、優先度予測部１０３、リクエストキュー管理部１０４、リクエスト実行部１０５、リソース操作部１０６、リソースDB（データベース）１０７を有する。
【０００８】
REST APIは、例えばWebコンテンツの記事やタグなどの情報であるリソースに対する操作（GET,POST,PUT,DELATE（リソースの取得、新規作成、更新、削除））をHTTPリクエストメソッドで示したリクエストに対するレスポンスを行う。このリクエストには、操作対象のリソースを一意に識別するURIが含まれる。
【０００９】
上記の操作は、CRUD、つまりCreate（作成−POST/PUT）、Read（読み込み−GET）、Update（更新−PUT）、Delete（削除−DELETE）というデータ操作の４つの処理をHTTPメソッドで実現するものである。
【００１０】
アプリケーション通信部１０１は、クライアントからのリクエストをネットワークを介して受け付け、このリクエストに対する適切なレスポンスをクライアントに返す。優先度付与部１０２は、上記のリクエストについて、レスポンスを返す前のリクエストが複数存在する場合に、リクエストに対し、レスポンスを優先して返す順番である優先度を付与する。
【００１１】
図８は、従来の負荷制御システムで用いる高優先度アドレス表の一例を示す図である。優先度予測部１０３は、図８に示す高優先度アドレス表を内部メモリに記憶する。  
この高優先度アドレス表では、レスポンスとしてのWebページ表示のための一連の処理の開始（ルートリソースへのアクセス）および、セッションが開始したリクエストの送信元のクライアントのIPアドレスが登録される。
【００１２】
以後、高優先度アドレス表に登録されているIPアドレスに対応するクライアントからのリクエストは、この高優先度アドレス表に登録されていないIPアドレスに対応するクライアントからのリクエストと比較して優先的に処理が行われる。  
この高優先度アドレス表に登録されたIPアドレスは、このIPアドレスに対応するクライアントからのリクエストに対するレスポンスの完了後、一定時間後に削除される。
【００１３】
リクエストキュー管理部１０４は、複数のリクエストについて、レスポンスの順番を管理する。  
リクエスト実行部１０５は、リクエストキュー管理部１０４で管理される順番に従って、リソース操作の指示を行ったり、およびレスポンスをアプリケーション通信部１０１に返したりする。
【００１４】
リソース操作部１０６は、リクエスト実行部１０５からの指示にしたがって、リソースの操作を行う。  
リソースDB１０７は、例えば不揮発性メモリなどの記憶媒体を含み、リソースに関する情報を記憶する。このリソースは、上記のようにリソース操作部１０６により操作される。
【先行技術文献】
【特許文献】
【００１５】
【特許文献１】特開２００８−０５９０４０号公報
【発明の概要】
【発明が解決しようとする課題】
【００１６】
上記のようにクライアントのIPアドレスごとにレスポンスの優先度を決定すると、NAT（ネットワークアドレストレンスレーション）やプロキシを経由した場合には、一部のクライアントによるリクエストが原因で、他のクライアントによる重要なリクエストに対しても不適切な優先度を設定してしまうことがある。
【００１７】
また、oneM2M（Machine to Machine）準拠のM2M/IoT（Internet of Things）プラットフォームでは、M2M/IoTデバイス、アプリケーション、および取得されたデータ等は全てツリー構造で管理され、APIへのリクエストによって、デバイスの操作や情報変更、デバイスからのデータなどを受信し、リソースとして管理および蓄積する。そして、サーバは、APIへのリクエストに含まれるURIによって操作対象を判別し、このリクエストに含まれるHTTPメソッドによってリソースの操作内容を判別する。
【００１８】
上記のM2M/IoTプラットフォームでは、あるIPアドレスに対応するクライアントからのリクエストをサーバ側で一度受信拒否した場合に、クライアント側のリクエスト頻度によっては、重要なリクエストに対するレスポンスとしてのデータが長期間取得されない状況となる可能性があり、システム全体の機能不全を招く。
【００１９】
本発明の目的は、重要なリクエストに対するレスポンスを適切に制御することができる負荷制御装置、負荷制御方法および負荷制御処理プログラムを提供することである。
【課題を解決するための手段】
【００２０】
上記目的を達成するために、この発明の実施形態における負荷制御装置の第１の態様は、操作対象のリソースを識別する識別情報を含み、前記リソースの操作を要求するためのリクエストおよびこのリクエストの最新の受信時刻を、リクエストキューに追加する前のリクエストとして管理する管理手段と、新たなリクエストを受信する受信手段と、前記受信したリクエストの受信時刻と、前記管理する、このリクエストに含まれる識別情報と同じ識別情報を含むリクエストの受信時刻との差分である差分値を計算する計算手段と、前記管理する、前記識別情報が異なる複数のリクエストのうち、前記計算手段により計算した前記差分値が大きいリクエストを、優先して前記リクエストキューに追加するリクエストとして指定する指定手段とを有する装置を提供する。
【００２１】
上記構成の負荷制御装置の第２の態様は、第１の態様において、前記リクエストは、前記要求する操作の種別を含み、前記計算手段は、前記受信したリクエストの受信時刻と、前記管理する、このリクエストに含まれる識別情報と同じ識別情報を含むリクエストの最新の受信時刻との差分である第１の差分値を計算する第１の計算手段、および、前記受信したリクエストの受信時刻と、前記管理されて、前記受信したリクエストに含まれる識別情報と同じ識別情報を含み、前記受信したリクエストが要求する操作と同じ操作を要求するリクエストの最新の受信時刻との差分である第２の差分値を計算する第２の計算手段を含み、前記指定手段は、前記管理する、前記識別情報が異なる複数のリクエストについて、前記第１の計算手段により計算した前記第１の差分値が大きい順に、優先して前記リクエストキューに追加するリクエストとして指定し、前記識別情報が異なる前記複数のリクエストについて前記計算した前記第１の差分値が同じである場合は、前記複数のリクエストについて、前記第２の計算手段により計算した前記第２の差分値が大きい順に、前記優先して前記リクエストキューに追加するリクエストとして指定する装置を提供する。
【００２２】
上記構成の負荷制御装置の第３の態様は、第２の態様において、前記指定手段は、前記識別情報が異なる前記複数のリクエストについて前記計算した前記第１の差分値が同じであって、かつ、前記識別情報が異なる前記複数のリクエストについて前記計算した前記第２の差分値が同じである場合は、前記受信したリクエストの受信時刻が古い順に、優先して前記リクエストキューに追加するリクエストとして指定する装置を提供する。
【００２３】
上記構成の負荷制御装置の第４の態様は、第１の態様において、前記受信したリクエストを追加する前記リクエストキューは、リクエストが要求する操作の種別に応じて区分される装置を提供する。
【００２４】
上記目的を達成するために、この発明の実施形態における負荷制御方法の態様は、負荷制御装置に適用される方法であって、操作対象のリソースを識別する識別情報を含み、前記リソースの操作を要求するためのリクエストおよびこのリクエストの最新の受信時刻を、リクエストキューに追加する前のリクエストとして管理し、新たなリクエストを受信し、前記受信したリクエストの受信時刻と、前記管理する、このリクエストに含まれる識別情報と同じ識別情報を含むリクエストの受信時刻との差分である差分値を計算し、前記管理する、前記識別情報が異なる複数のリクエストのうち、前記計算した前記差分値が大きいリクエストを、優先して前記リクエストキューに追加するリクエストとして指定する方法を提供する。
【００２５】
本発明の実施形態における負荷制御処理プログラムの態様は、第１の態様における負荷制御装置の一部分として動作するコンピュータに用いられるプログラムであって、前記コンピュータを、前記管理手段、前記受信手段、前記計算手段、および前記指定手段として機能させるためのプログラムを提供する。
【発明の効果】
【００２６】
本発明によれば、重要なリクエストに対するレスポンスを適切に制御することが可能になる。
【図面の簡単な説明】
【００２７】
【図１】本発明の実施形態における負荷制御システムの機能構成例を示す図。
【図２】本発明の実施形態における負荷制御システムのサーバの機能構成例を示すブロック図。
【図３】本発明の実施形態における負荷制御システムで用いる頻度テーブルの一例を表形式で示す図。
【図４】本発明の実施形態における負荷制御システムによるリクエストの受付から操作実行までの処理手順の一例を示すフローチャート。
【図５】本発明の実施形態における負荷制御システムによる、優先度付与および順序制御処理の手順の一例を示すフローチャート。
【図６】本発明の実施形態における負荷制御システムによる、キューへのリクエスト追加処理の手順の一例を示すフローチャート。
【図７】従来の負荷制御システムのサーバの機能構成例を示すブロック図。
【図８】従来の負荷制御システムで用いる高優先度アドレス表の一例を示す図。
【発明を実施するための形態】
【００２８】
以下、この発明に係わる実施形態を説明する。  
図１は、本発明の実施形態における負荷制御システムの機能例を示す図である。  
図１に示すように、本発明の実施形態における負荷制御システムは、複数のクライアントと、負荷制御装置である負荷制御機能付きサーバ（以下、単にサーバと称することがある）１０とが、ネットワーク２を介して接続されるシステムである。クライアントは、例えば、アプリ１−１、デバイス１−２、ゲートウェイ１−３である。ゲートウェイ１−３は、デバイス１−３ｂとネットワーク３との間に設けられる。
【００２９】
本発明では、クライアントからAPIへのリクエストに含まれるURI、HTTPメソッド、及びリクエストの頻度に基づいて、サーバ１０が重要なリクエストを先に処理できるように、リクエストに対するレスポンスの優先度を決定する。
【００３０】
図２は、本発明の実施形態における負荷制御システムのサーバの機能構成例を示すブロック図である。  
図２に示すように、本発明の実施形態における負荷制御システムのサーバ（M2M/IoTプラットフォーム）１０は、アプリケーション通信部１１、優先度付与部１２、頻度テーブル１３、リクエストキュー管理部１４、リクエスト実行部１５、リソース操作部１６、リソースDB１７を有する。
【００３１】
アプリケーション通信部１１は、クライアントからのリクエストをネットワークを介して受け付け（受信し）、このリクエストに対する適切なレスポンスをクライアントに返す。このアプリケーション通信部１１は、M2M/IoTデバイスを含む。
【００３２】
優先度付与部１２は、上記のリクエストについて、優先度付リクエストキュー（以下、単にリクエストキューと称することもある）に追加する前のリクエストが複数存在する場合に、リクエストに対し、リクエストキューに優先して追加する順番である優先度を付与する。
【００３３】
図３は、本発明の実施形態における負荷制御システムで用いる頻度テーブルの一例を表形式で示す図である。  
頻度テーブル１３は、例えば不揮発性メモリなどの記憶媒体で実現でき、受け付けたリクエストに含まれるツリーＵＲＬ、リソースの操作の種別(CRUD/ALL)、リクエストの最新の受信時刻（last_received_time）を対応付けて、リクエストキューへ追加する前のリクエストとして登録し、これを管理する。ツリーＵＲＬは、操作対象のリソースを識別する識別情報である。  
ここでは、操作の種別は、HTTPメソッドで実現するCRUD、つまりCreate（作成−POST/PUT）、Read（読み込み−GET）、Update（更新−PUT）、Delete（削除−DELETE）のいずれかであるとする。以下、上記のCRUDのいずれかの操作が指定されるリクエストをメソッド別リクエストと称する。
【００３４】
この頻度テーブル１３に登録されているリクエスのlast_received_timeは、この登録されているリクエストが指定するツリーＵＲＬ、操作の種別と同じツリーＵＲＬ、同じ操作の種別を指定するリクエストを新たに受け付けたときに、このリクエストの受信時刻に更新される。  
つまり、頻度テーブル１３では、受け付けたリクエストについて、どのツリーＵＲＬへのリクエストか、また、リソースに対してどのような操作を要求するかを管理し、また、各種のツリーＵＲＬや操作の種別に関わる最新のリクエストの受信時刻を管理する。  
頻度テーブル１３におけるツリーＵＲＬの、ワイルドカードより上の階層の深さは予め設定できる。図３に示した例では、この階層の深さは２である。
【００３５】
ここで、新たに受け付けられるリクエストとして、例えば、受付時刻順に「Request1：受付時刻T1 CREATE incse/ae0/container0/contentInstance1111」、「Request2：受付時刻T2 UPDATE incse/ae0/container1/contentInstance2222」、「Request3：受付時刻T3 DELETE incse/ae0/container0/contentInstance3333」でなる３つのリクエストが順次受け付けられ、これらの各リクエストのツリーＵＲＬ「incse/ae0/container0…」（Request1、Request3）、「incse/ae0/container1…」（Request2）の浅い層（ここでは２層目まで）では文字列が共通し、深い層（ここでは３層目）では文字列が一部異なる場合の、頻度テーブル１３の更新について説明する。
【００３６】
図３に示すように、頻度テーブル１３において、ワイルドカードより上の階層の深さが２であるツリーＵＲＬ「incse/ae0/*」を管理し、上記の各リクエストRequest1、Request2、Request3を順次受け付けた場合は、頻度テーブル１３における、上記の各リクエストのツリーＵＲＬの２層目までに対応するツリーＵＲＬ「incse/ae0/*」の種別ALLの行のlast_received_timeの列は、リクエストでの操作の種別に関わらず、最新の受け付けたリクエストの受付時刻に順次更新される。
【００３７】
また、頻度テーブル１３における上記のツリーＵＲＬ「incse/ae0/*」のメソッド別の各行のlast_received_timeの列は、各Request1、Request2、Request3が順次受け付けられるたびに、メソッド別の各行に対応する操作の種別を指定するリクエストの受付時刻に更新される。
【００３８】
具体的には、上記のRequest1、Request2、Request3が順次受け付けられたときは、Request1の受付時刻T1は、頻度テーブル１３上のツリーＵＲＬ「incse/ae0/*」の種別Cの行のlast_received_timeの列に、Request2の受付時刻T2は、頻度テーブル１３上の同じツリーＵＲＬ「incse/ae0/*」の種別Uの行のlast_received_timeの列に、Request3の受付時刻T3は、頻度テーブル１３上の同じツリーＵＲＬ「incse/ae0/*」の種別Dの行のlast_received_timeの列に反映される。  
ここで、頻度テーブル１３におけるツリーＵＲＬ「incse/ae0/*」の種別ALLの行に対応するlast_received_timeの列は、最後になされたRequest3の受付時刻T3に更新される。
【００３９】
また、頻度テーブル１３の構成は、深さが３以上であるツリーＵＲＬを管理する構成でもよい。  
例えば、ワイルドカードより上の階層の深さが３である、第１のツリーＵＲＬ「incse/ae0/container0/*」および、上から３階層目の文字列が第１のツリーＵＲＬと異なる第２のツリーＵＲＬ「incse/ae0/container1/*」が頻度テーブル１３で管理されていても良い。この場合、種別ALLに関わる登録情報やメソッド別の登録情報は、各ツリーＵＲＬについて個別に管理される。
【００４０】
上記のRequest1、Request2、Request3が新たに順次受け付けられたときは、Request1の受付時刻T1は、頻度テーブル１３上の第１のツリーＵＲＬ「incse/ae0/container0/*」の種別Cの行のlast_received_timeの列に、Request3の受付時刻T3は、頻度テーブル１３上の同じ第１のツリーＵＲＬ「incse/ae0/container0/*」の種別Dの行のlast_received_timeの列に反映される。  
ここで、頻度テーブル１３における、第１のツリーＵＲＬ「incse/ae0/container0/*」の種別ALLの行に対応するlast_received_timeの列は、Request1、Request3のうち、後に受け付けたRequest3の受付時刻T3に更新される。
【００４１】
また、Request2の受付時刻T2は、頻度テーブル１３上の第２のツリーＵＲＬ「incse/ae0/container1/*」の種別Uの行のlast_received_timeの列に反映される。  
ここで、頻度テーブル１３における、第２のツリーＵＲＬ「incse/ae0/container1/*」の種別ALLの行に対応するlast_received_timeの列は、Request2の受付時刻T2に更新される。
【００４２】
リクエストキュー管理部１４は、頻度テーブル１３に登録されたリクエストについてのリクエストキュー、および、このリクエストキューへリクエストを追加する順番を管理する。  
リクエスト実行部１５は、リクエストキュー管理部１４で管理されるリクエストキューに従って、リソース操作の指示を行ったり、レスポンスをアプリケーション通信部１１に返したりする。
【００４３】
リソース操作部１６は、リクエスト実行部１５からの指示にしたがって、リソースの操作を行う。  
リソースDB１７は、例えば不揮発性メモリなどの記憶媒体を含み、リソースに関する情報を記憶する。このリソースは、上記のようにリソース操作部１６により操作される。
【００４４】
図１に示した例では、サーバ１０は、リクエスト実行部１５、リソース操作部１６、リソースDB１７を含み、これらのリクエスト実行部１５、リソース操作部１６、リソースDB１７が１つずつである構成について説明した。しかし、これに限らず、リクエスト実行部１５、リソース操作部１６、リソースDB１７をサーバ１０から分け、かつ、複数のリクエスト実行部１５、およびこれに１対１で対応する複数のリソース操作部１６を設けてもよい。
【００４５】
構成としては、例えば、リクエスト実行部１５およびリソース操作部１６を含む装置をサーバ１０と異なる他のアプリサーバとして構成し、このアプリサーバをリクエスト実行部１５、リソース操作部１６の必要数に対応する数だけ設けて、サーバ１０や、各アプリサーバに対して共通のリソースDB１７とネットワークを介して接続する構成が挙げられる。
【００４６】
このように、リクエスト実行部１５による指示、およびこの指示に従うリソース操作部１６によるリソースの操作を、例えばリクエストの種別に応じて複数で分担することで、リソースの操作にかかる負荷を分散することができる。
【００４７】
次に、負荷制御システムによる各種処理の手順について説明する。  
全体的には、負荷制御システムは、ツリーＵＲＬ単位及び操作毎のリクエストの頻度を元に、リクエストキューへリクエストが追加され、このリクエストキューからリクエストを順次取り出して、レスポンスの処理を行う。
【００４８】
図４は、本発明の実施形態における負荷制御システムによるリクエストの受付から操作実行までの処理手順の一例を示すフローチャートである。  
まず、サーバ１０の優先度付与部１２は、クライアントからアプリケーション通信部１１により受信した新たなリクエストを受け付ける（Ｓ１）。優先度付与部１２は、このリクエストを受け付けた時点で内蔵タイマが計時する時刻を、上記の新たなリクエストを受け付けたときの現在時刻（以下、受付時現在時刻と称することがある）として内部メモリに記憶する。  
このリクエストは、ツリーURL、および、要求する操作の種別を含む。以下、上記のCRUDのいずれかの操作が指定されるリクエストをメソッド別リクエストと称する。
【００４９】
ここでは、このメソッド別リクエストで指定されるツリーURLと同じツリーURLが指定される過去のメソッド別リクエストが、このリクエストの最新の受信時刻と対応付けて、操作の種別ごとに頻度テーブル１３に登録されているとする。
【００５０】
また、この登録されるメソッド別リクエストが指定されるツリーURLと同じツリーURLを指定し、操作の種別として「ALL」を指定するリクエストが頻度テーブル１３に登録されているとする。以下、このリクエストをリクエスト(ALL)と称し、上記のメソッド別リクエストと区別する。また、リクエスト(ALL)とメソッド別リクエストとをあわせて単にリクエストと称することもある。
【００５１】
このリクエスト(ALL)は、操作の種別を問わないリクエストである。また、このリクエスト(ALL)におけるlast_received_timeは、頻度テーブル１３にすでに登録されて、このリクエスト(ALL)が指定するツリーURLと同じツリーURLを指定する各種のメソッド別リクエストに対応付けられる最新のlast_received_timeである。
【００５２】
また、このリクエスト(ALL)が指定するツリーURLと同じツリーURLを指定する、新たなメソッド別リクエストをさらに頻度テーブル１３に登録するときは、このリクエスト(ALL)のlast_received_timeは、上記のさらに登録するメソッド別リクエストのlast_received_timeにあわせるように更新される。
【００５３】
次に、優先度付与部１２は、頻度テーブル１３へ登録されたリクエストをリクエストキューへ追加するための、優先度付与及び順序制御処理を行う（Ｓ２）。この優先度付与及び順序制御処理の詳細については後述する。
【００５４】
次に、リクエスト実行部１５は、リクエストキューに追加されたリクエストについて、この追加された順番に沿ってリソースの操作を実行して、この実行の結果をレスポンスとして、アプリケーション通信部１１を介してクライアントに返す（Ｓ３）。
【００５５】
次に、上記のＳ２である、優先度付与及び順序制御処理の詳細について説明する。  
図５は、本発明の実施形態における負荷制御システムによる、優先度付与および順序制御処理の手順の一例を示すフローチャートである。  
まず、優先度付与部１２は、Ｓ１で受け付けたメソッド別リクエストが指定するツリーURLと同じツリーURLを指定するリクエスト(ALL)を頻度テーブル１３から選択し、このリクエスト(ALL)が指定するlast_received_timeであるlast_received_time(ALL)を取得する。
【００５６】
また、優先度付与部１２は、Ｓ１で受け付けたメソッド別リクエストが指定するツリーURL、操作の種別と同じツリーURL、同じ操作の種別を指定する過去のメソッド別リクエストを頻度テーブル１３から選択し、このリクエストが指定するlast_received_timeであるlast_received_time(メソッド別）を取得する（Ｓ２１）。  
優先度付与部１２の内蔵タイマは、Ｓ１で内部メモリに記憶した受付時現在時刻を取得する（Ｓ２２）。
【００５７】
次に、優先度付与部１２は、Ｓ２２で取得した受付時現在時刻と、Ｓ２１で取得したlast_received_time(ALL)とに基づいて、新たなリクエストが指定するツリーURLと同じをツリーURL指定し操作の種別を問わないリクエストに関する頻度値F_aを以下の式（１）にしたがって計算する。  
また、優先度付与部１２は、Ｓ２２で取得した受付時現在時刻と、Ｓ２１で取得したlast_received_time(メソッド別）とに基づいて、新たなリクエストが指定するツリーURLや操作の種別と同じツリーURLや操作の種別を指定するリクエストに関する頻度値F_mを以下の式（２）にしたがって計算する。優先度付与部１２は、これら計算した値を内部メモリにセットする（Ｓ２３）。
【００５８】
F_a = (受付時現在時刻)- last_received_time(ALL)  …式（１）
F_m = (受付時現在時刻)- last_received_time(メソッド別）  …式（２）
次に、優先度付与部１２は、Ｓ１で受け付けたリクエストを頻度テーブル１３に登録して更新する（Ｓ２４）。この登録されるリクエストは、ツリーURL、操作の種別、および、Ｓ１で内部メモリに記憶した受付時現在時刻としてのlast_received_timeを含む。
【００５９】
ここで、優先度付与部１２は、上記のように、頻度テーブル１３において、上記の新たに登録したメソッド別リクエストが指定するツリーURLと同じツリーURLを指定する、すでに頻度テーブル１３に登録されているリクエスト(ALL)のlast_received_timeを、この反映したメソッド別リクエストのlast_received_timeにあわせるように更新する。  
次に、優先度付与部１２は、所定の処理を経て、頻度テーブル１３に登録されたリクエストをリクエストキューへ順次追加する（Ｓ２５）。この処理の詳細については後述する。
【００６０】
次に、頻度テーブル１３に登録されたリクエストをリクエストキューへ順次追加する処理について説明する。
【００６１】
図６は、本発明の実施形態における負荷制御システムによる、キューへのリクエスト追加処理の手順の一例を示すフローチャートである。  
まず、リクエストキュー内にリクエストがない場合は（Ｓ２５−１のＮＯ）、優先度付与部１２は、頻度テーブル１３に登録されたリクエストを、リクエストキューに順次投入する（Ｓ２６−２）。つまり、頻度テーブル１３に登録されたリクエストは直ちに実行されることとなる。
【００６２】
また、リクエストキュー内にリクエストがある場合で（Ｓ２５−１のＹＥＳ）、このリクエストキューが満杯である、つまり所定の数に達している場合は（Ｓ２５−３のＮＯ）、優先度付与部１２は、リクエストキュー内への新たなリクエストの登録は行わず、サーバ１０のスリープ後に、リクエストキューが満杯か否かの再評価を行うために所定時間だけ保留する処理を行なったり、当該リクエストを拒否する等の処理を行なったりする（Ｓ２５−４）。
【００６３】
また、リクエストキューが満杯でない場合は（Ｓ２５−３のＹＥＳ）、優先度付与部１２は、頻度テーブル１３に登録されて、異なるツリーURLを指定する複数のリクエスト(ALL)のうち、大きい頻度値F_aの計算の元となったリクエスト(ALL)が指定するツリーURLと同じツリーURLを指定する各種のメソッド別リクエストが先に実行されるように、このリクエストをリクエストキューへ追加する（Ｓ２５−５）。
【００６４】
また、頻度テーブル１３に登録されている、異なるツリーURLを指定する複数のリクエストについて、頻度値F_aが同値である場合は（Ｓ２５−６のＹＥＳ）、優先度付与部１２は、この同値の頻度値F_aの計算の元となる、複数のリクエスト(ALL)が指定するツリーURLと同じツリーURLを指定する各種のメソッド別リクエストの内、このリクエストについて上記のように計算される頻度値F_mが大きい順に各種のメソッド別リクエストが先に実行されるように、このリクエストをリクエストキューへ追加する（Ｓ２５−７）。
【００６５】
また、上記のように、頻度テーブル１３に登録されている、異なるツリーURLを指定する複数のリクエストについて頻度値F_aが同値であって、かつ、これらの複数のリクエスト(ALL)に関わる各種のメソッド別リクエストの全てについて、頻度値F_mが同値である場合は（Ｓ２５−８のＹＥＳ）、優先度付与部１２は、これらのリクエストのうち、頻度テーブル１３に登録されているlast_received_time自体が古い各種のメソッド別リクエストが先に実行され、last_received_time自体が後である各種のメソッド別リクエストが後で実行されるよう、リクエストをキューへ追加する（Ｓ２５−９）。
【００６６】
以上のように、本発明の実施形態における負荷制御システムは、新たなリクエストを受け付けたときに、最新のリクエスト時刻が古い順に、リクエスト発行元の種別に関係なく、リクエスト単位で、このリクエストの処理の優先度を決定することができるので、プラットフォーム全体の機能不全を抑えながらサービスを継続することができる。この場合、リクエストの発行元のクライアントへの改造は不要である。
【００６７】
また、リクエストキューは複数であってもよく、この場合、例えば、CURDのうちCUD操作を指定するリクエストは頻度値F_mが大きい順に第１のリクエストキューに追加し、R操作を指定するリクエストは頻度値F_mが小さい順に第２のリクエストキューに追加するなどして、リクエストキュー毎に優先度付けの方法を異ならせてもよい。
【００６８】
また、各実施形態に記載した手法は、計算機（コンピュータ）に実行させることができるプログラム（ソフトウエア手段）として、例えば磁気ディスク（フロッピー（登録商標）ディスク、ハードディスク等）、光ディスク（ＣＤ−ＲＯＭ、ＤＶＤ、ＭＯ等）、半導体メモリ（ＲＯＭ、ＲＡＭ、フラッシュメモリ等）等の記録媒体に格納し、また通信媒体により伝送して頒布することもできる。なお、媒体側に格納されるプログラムには、計算機に実行させるソフトウエア手段（実行プログラムのみならずテーブルやデータ構造も含む）を計算機内に構成させる設定プログラムをも含む。本装置を実現する計算機は、記録媒体に記録されたプログラムを読み込み、また場合により設定プログラムによりソフトウエア手段を構築し、このソフトウエア手段によって動作が制御されることにより上述した処理を実行する。なお、本明細書でいう記録媒体は、頒布用に限らず、計算機内部あるいはネットワークを介して接続される機器に設けられた磁気ディスクや半導体メモリ等の記憶媒体を含むものである。
【符号の説明】
【００６９】
１１…アプリケーション通信部、１２…優先度付与部、１３…頻度テーブル、１４…リクエストキュー管理部、１５…リクエスト実行部、１６…リソース操作部、１７…リソースDB。
【図１】
2018025864.tif 000003
【図２】
2018025864.tif 000004
【図３】
2018025864.tif 000005
【図４】
2018025864.tif 000006
【図５】
2018025864.tif 000007
【図６】
2018025864.tif 000008
【図７】
2018025864.tif 000009
【図８】
2018025864.tif 000010