JP2019003245A - サービス提供システム、サービス提供サーバ、サービス提供方法およびサービス提供プログラム - Google Patents

Abstract

【課題】処理の滞留可能性を抑制する。
【解決手段】サービス提供サーバ５は、複数の部品提供サーバ７のそれぞれにリクエストを処理させるリクエスト処理手段２２と、アプリケーション実行装置３に、リクエストの処理結果を応答する応答手段２４を備える。リクエスト処理手段２２は、部品提供サーバでの処理を待機するリクエストを特定する処理待機データ１１を参照して、待機中のリクエスト数が上限数に達する場合、待機中の各リクエストの後続の処理で用いる他の部品提供サーバの状態に基づいて、廃棄リクエストを特定し、廃棄リクエスト以外のリクエストを、部品提供サーバ７に処理させる。
【選択図】 図３

Description

本発明は、アプリケーション実行装置から、アプリケーションの実行に用いられる複数の部品を特定する複数のリクエストを受信して、複数の部品提供サーバが、複数の部品が特定されたリクエストを処理するサービス提供システム、サービス提供サーバ、サービス提供方法およびサービス提供プログラムに関する。

近年、ＡＰＩ（Application Programming Interface）を介して、アプリケーションで用いられる部品をリクエストし、各部品を提供するイネーブラにリクエストを処理させて、アプリケーションを実行するシステムが普及している。このようなシステムにおいて、アプリケーションとイネーブラに接続し、ＷｅｂＡＰＩのＡＰＩリクエストの処理や、輻輳制御を担うサーバが導入されている。このようなサーバは、各アプリケーションから部品のリクエストを受信してイネーブラに処理させ、アプリケーションに処理結果を送信する。

ＷｅｂＡＰＩのＡＰＩリクエストは、ＨＴＴＰ（Hypertext Transfer Protocol）リクエストベースのベストエフォートで処理されるため、イネーブラが輻輳している場合、ＡＰＩリクエストの処理の完了は保証されない。一つのリクエストで複数のイネーブラを用いる場合、一つのイネーブラが輻輳状態であることによってリクエストが廃棄されるので、アプリケーションは所望の結果を得るために、リクエストを再送する場合がある。この結果、一つのイネーブラの輻輳に起因して再送が繰り返されるため、輻輳していない他のイネーブラのリソースも逼迫し、輻輳が拡大する場合がある。

そこでイネーブラごとに、ＡＰＩリクエストを格納するバッファを用意する方法が提案されている（非特許文献１参照）。非特許文献１は、イネーブラの輻輳によりＡＰＩリクエストを処理できない場合、ＡＰＩリクエストをバッファに格納し、イネーブラのリソースの空きに従って、バッファに格納されたＡＰＩリクエストを処理する。また非特許文献１は、バッファに格納しきれないＡＰＩリクエストを受け付けた場合、既に処理したイネーブラ数が少ないリクエストを廃棄することを提案する。具体的には、非特許文献１は、既にバッファに格納されたＡＰＩリクエストと新たに受け付けたＡＰＩリクエストのそれぞれについて、既に処理したイネーブラ数を比較し、既に処理したイネーブラ数が最も小さく、かつ最も新しいＡＰＩリクエストを廃棄する。

白井他, イネーブラのAPI処理リソース量を効率化する方法の提案, 電子情報通信学会ソサイエティ大会, 2016年9月, B-14-3

非特許文献１に記載の方法は、既に処理したイネーブラ数に基づいて廃棄するＡＰＩリクエストを決定するので、廃棄されなかったリクエストで後続の処理に用いるイネーブラで輻輳が発生している場合、処理が滞留する可能性がある。

従って本発明の目的は、処理の滞留可能性を抑制可能なサービス提供システム、サービス提供サーバ、サービス提供方法およびサービス提供プログラムを提供することである。

上記課題を解決するために、本発明の第１の特徴は、アプリケーション実行装置から、アプリケーションの実行に用いられる複数の部品を特定する複数のリクエストを受信するサービス提供サーバと、サービス提供サーバに接続し、少なくとも一つの部品を提供する複数の部品提供サーバを備えるサービス提供システムに関する。本発明の第１の特徴に係るサービス提供システムに用いられるサービス提供サーバは、複数の部品提供サーバのそれぞれにリクエストを処理させるリクエスト処理手段と、アプリケーション実行装置に、リクエストの処理結果を応答する応答手段を備える。リクエスト処理手段は、部品提供サーバでの処理を待機するリクエストを特定する処理待機データを参照して、待機中のリクエスト数が上限数に達する場合、待機中の各リクエストの後続の処理で用いる他の部品提供サーバの状態に基づいて、廃棄リクエストを特定し、廃棄リクエスト以外のリクエストを、部品提供サーバに処理させる。

ここで、他の部品提供サーバの状態は、輻輳中であるか否かであって、リクエスト処理手段は、後続の処理で用いる部品提供サーバであって、輻輳中の部品提供サーバが多いリクエストを、廃棄リクエストと特定しても良い。

また応答手段は、廃棄リクエストについて、アプリケーション実行装置にリクエストが廃棄された旨を応答しても良い。

本発明の第２の特徴は、アプリケーション実行装置から、アプリケーションの実行に用いられる複数の部品を特定する複数のリクエストを受信するサービス提供サーバと、サービス提供サーバに接続し、少なくとも一つの部品を提供する複数の部品提供サーバを備えるサービス提供システムに用いられるサービス提供サーバに関する。本発明の第２の特徴に係るサービス提供サーバは、複数の部品提供サーバのそれぞれにリクエストを処理させるリクエスト処理手段と、アプリケーション実行装置に、リクエストの処理結果を応答する応答手段を備える。リクエスト処理手段は、部品提供サーバでの処理を待機するリクエストを特定する処理待機データを参照して、待機中のリクエスト数が上限数に達する場合、待機中の各リクエストの後続の処理で用いる他の部品提供サーバの状態に基づいて、廃棄リクエストを特定し、廃棄リクエスト以外のリクエストを、部品提供サーバに処理させる。

応答手段は、廃棄リクエストについて、アプリケーション実行装置にリクエストが廃棄された旨を応答しても良い。

本発明の第３の特徴は、アプリケーション実行装置から、アプリケーションの実行に用いられる複数の部品を特定する複数のリクエストを受信するサービス提供サーバと、サービス提供サーバに接続し、少なくとも一つの部品を提供する複数の部品提供サーバを備えるサービス提供システムに用いられるサービス提供方法に関する。本発明の第３の特徴に係るサービス提供方法は、複数の部品提供サーバのそれぞれにリクエストを処理させるステップと、アプリケーション実行装置に、リクエストの処理結果を応答するステップと、部品提供サーバでの処理を待機するリクエストを特定する処理待機データを参照して、待機中のリクエスト数が上限数に達する場合、待機中の各リクエストの後続の処理で用いる他の部品提供サーバの状態に基づいて、廃棄リクエストを特定し、廃棄リクエスト以外のリクエストを、部品提供サーバに処理させるステップを備える。

廃棄リクエストについて、アプリケーション実行装置にリクエストが廃棄された旨を応答するステップをさらに備えても良い。

本発明の第４の特徴は、コンピュータに、本発明の第２の特徴に記載のサービス提供サーバとして機能させるためのサービス提供プログラムに関する。

本発明によれば、処理の滞留可能性を抑制可能なサービス提供システム、サービス提供サーバ、サービス提供方法およびサービス提供プログラムを提供することができる。

本発明の実施の形態に係るアプリケーション提供システムのシステム構成を説明する図である。 本発明の実施の形態に係るアプリケーション提供システムの処理の概要を説明する図である。 本発明の実施の形態に係るサービス提供サーバのハードウエア構成および機能ブロックを説明する図である。 本発明の実施の形態に係る処理待機データの一例を説明する図である。 本発明の実施の形態に係る処理待機データの更新の一例を説明する図である。 本発明の実施の形態に係る輻輳状態データの一例を説明する図である。 本発明の実施の形態に係る所定の部品提供サーバの処理待機データの一例を説明する図である。 本発明の実施の形態に係るリクエスト処理手段の処理を説明する図である。

次に、図面を参照して、本発明の実施の形態を説明する。以下の図面の記載において、同一または類似の部分には同一または類似の符号を付している。

（アプリケーション提供システム）
図１に示すアプリケーション提供システム１は、サービス提供システム２、第１のアプリケーション実行装置３ａおよび第２のアプリケーション実行装置３ｂを備える。サービス提供システム２は、第１のアプリケーション実行装置３ａおよび第２のアプリケーション実行装置３ｂのそれぞれと、通信ネットワーク４を介して相互に通信可能に接続される。本発明の実施の形態において、第１のアプリケーション実行装置３ａおよび第２のアプリケーション実行装置３ｂを特に区別しない場合、単にアプリケーション実行装置３と記載する場合がある。

図１に示すアプリケーション提供システム１は、２台のアプリケーション実行装置３を備えるが、これは一例であって、１台であっても良いし、３台以上であっても良い。またアプリケーション実行装置３は、さらに、エンドユーザに対してサービスを提供してもよく、アプリケーション提供システム１は、いわゆるBtoBtoXモデルのシステムであっても良い。

（サービス提供システム）
サービス提供システム２は、サービス提供サーバ５および部品提供サーバ群６を備える。サービス提供サーバ５は、第１のアプリケーション実行装置３ａおよび第２のアプリケーション実行装置３ｂのそれぞれと、通信ネットワーク４を介して相互に通信可能に接続するとともに、部品提供サーバ群６と、通信ネットワーク８を介して相互に通信可能に接続する。

部品提供サーバ群６は、Ａ部品提供サーバ７ａ、Ｂ部品提供サーバ７ｂ・・・と複数の部品提供サーバを備える。本発明の実施の形態において、Ａ部品提供サーバ７ａ、Ｂ部品提供サーバ７ｂ・・・の各部品提供サーバを特に区別しない場合、単に部品提供サーバ７と記載する場合がある。図１に示す部品提供サーバ群６は、２台の部品提供サーバ７を備えるが、これは一例であって、３台以上であっても良い。本発明の実施の形態において部品提供サーバ群６は、６台の部品提供サーバを備え、図示しないＣ部品提供サーバ７ｃ、Ｄ部品提供サーバ７ｄ、Ｅ部品提供サーバ７ｅおよびＦ部品提供サーバ７ｆを備える。

アプリケーション実行装置３は、アプリケーションを実行する際に、サービス提供システム２に対して、ＡＰＩを介してアプリケーションの部品の実行をサービス提供システム２にリクエストする。ここで、部品は、アプリケーションにおける一連の処理の単位である。アプリケーション実行装置３は、部品の実行をリクエストする際に、パラメータなどもあわせてサービス提供システム２に送信しても良い。

部品提供サーバ７は、アプリケーション実行装置３が実行するアプリケーションにおける部品を、アプリケーション実行装置３に代わって実行する。部品提供サーバ７は、アプリケーション実行装置３からパラメータが入力されると、入力されたパラメータを用いて部品を実行する。複数の部品提供サーバ７は、それぞれ、少なくとも一つの部品を提供する。複数の部品提供サーバ７が、複数の部品が特定されたリクエストを処理する。

サービス提供サーバ５は、アプリケーション実行装置３から、アプリケーションの実行に用いられる部品を特定する複数のリクエストを受信して、リクエストで特定された部品を提供する部品提供サーバ７に、リクエストを処理させる。またサービス提供サーバ５は、部品提供サーバ７において輻輳が発生している際、その部品提供サーバ７が処理すべきリクエストの待ち行列を管理し、部品提供サーバ７のリソースに空きができると、待ち行列に格納されたリクエストを部品提供サーバ７に入力する。

さらにサービス提供サーバ５は、各部品提供サーバ７が保有する待ち行列に、所定数以上のリクエストが格納されると、所定ロジックで選択されたリクエストを待ち行列から削除して、待機リクエスト数が一定数以下になるように制御する。

本発明の実施の形態において、アプリケーション実行装置３は、複数のリクエストをサービス提供システム２に送信する。また各リクエストには複数の部品が特定されており、一つのリクエストを処理するために、複数の部品提供サーバ７が携わる。さらに、サービス提供システム２に属する複数の部品提供サーバ７のうち、少なくとも一つの部品提供サーバ７で処理リソースが足りず、輻輳が発生している場合を説明する。

なお、図１に示す各サーバまたは装置は、それぞれ、物理サーバであっても良いし、仮想サーバであっても良い。

（処理の概要）
図２を参照して、本発明の実施の形態に係るアプリケーション提供システム１の処理の概要を説明する。図２のシーケンス図は、いずれの部品提供サーバ７においても輻輳が発生していない場合と、部品提供サーバ７（Ｂ部品提供サーバ７ｂ）で輻輳が発生している場合を示す。

なお、本発明の実施の形態において、「Ａ部品提供サーバ７ａ」を単に「Ａ」と表記し、「Ｂ部品提供サーバ７ｂ」を単に「Ｂ」と表記するなど、省略して記載する場合がある。例えば、Ａ部品提供サーバ７ａ、Ｂ部品提供サーバ７ｂ、Ｃ部品提供サーバ７ｃおよびＥ部品提供サーバ７ｅの順でリクエストを処理する場合、「Ａ→Ｂ→Ｃ→Ｅ」と表記する。

まず、いずれの部品提供サーバ７も輻輳していない場合を説明する。

ステップＳ１においてアプリケーション実行装置３は、サービス提供サーバ５に、Ａ→Ｂ→Ｃ→Ｅの順序で処理させるリクエストＲ１を送信する。サービス提供サーバ５は、このリクエストＲ１を処理するために、リクエストＲ１を、Ａ→Ｂ→Ｃ→Ｅの順に入力するよう試みる。

まずステップＳ２においてサービス提供サーバ５は、Ａ部品提供サーバ７ａが輻輳しているか否かを判定する。輻輳していないので、ステップＳ３において、Ａ部品提供サーバ７ａに処理させるリクエストＲ１を入力するとともに、その処理結果を受信する。

次にステップＳ４においてサービス提供サーバ５は、Ｂ部品提供サーバ７ｂが輻輳しているか否かを判定する。輻輳していないので、ステップＳ４において、Ｂ部品提供サーバ７ｂに処理させるリクエストＲ１を入力するとともに、その処理結果を受信する。

サービス提供サーバ５は、ステップＳ６ないしステップＳ９において、Ｃ部品提供サーバ７ｃおよびＥ部品提供サーバ７ｅについても同様の処理を繰り返す。ステップＳ１でアプリケーション実行装置３が送信したリクエストＲ１に対する処理結果が得られると、サービス提供サーバ５は、ステップＳ１０において処理結果をアプリケーション実行装置３に返信する。

このような処理に並行してサービス提供サーバ５は、部品提供サーバ群６の各部品提供サーバについて、輻輳状態を取得する。ステップＳ２１においてサービス提供サーバ５は、Ｂ部品提供サーバ７ｂ、Ｄ部品提供サーバ７ｄおよびＥ部品提供サーバ７ｅが輻輳中であることを把握するとする。このような状況で、ステップＳ１と同様の部品提供サーバ７に処理させるリクエストＲ２が入力された場合を説明する。

ステップＳ１と同様に、ステップＳ３１においてアプリケーション実行装置３は、サービス提供サーバ５に、Ａ→Ｂ→Ｃ→Ｅの順序で処理させるリクエストＲ２を送信する。サービス提供サーバ５は、このリクエストＲ２を処理するために、リクエストＲ２を、Ａ→Ｂ→Ｃ→Ｅの順に入力するよう試みる。

まずステップＳ３２においてサービス提供サーバ５は、Ａ部品提供サーバ７ａが輻輳しているか否かを判定する。輻輳していないので、ステップＳ３３において、Ａ部品提供サーバ７ａに処理させるリクエストＲ２を入力するとともに、その処理結果を受信する。

次にステップＳ３４においてサービス提供サーバ５は、Ｂ部品提供サーバ７ｂが輻輳しているか否かを判定する。輻輳しているので、Ｂ部品提供サーバ７ｂが処理すべきリクエストの待ち行列にリクエストＲ２が設定された後、リクエストＲ２がＢ部品提供サーバ７ｂによって処理されるまでの間に、リクエストＲ２は、廃棄される可能性がある。

具体的には、リクエストＲ２が待ち行列に設定された際、或いは他のリクエストがこの待ち行列に設定された際、この待ち行列の待機リクエスト数が一定数以上になる可能性がある。待ち行列の待機リクエスト数が一定数以上になると、サービス提供サーバ５は、Ｂ部品提供サーバ７ｂの待ち行列に格納されたリクエストから、所定のルールに従って廃棄するリクエストを特定する。

ここで、ステップＳ３５において、リクエストＲ２がＢ部品提供サーバ７ｂによって処理される前に、廃棄するリクエストに特定されると、サービス提供サーバ５は、リクエストＲ２について、Ｂ部品提供サーバ７ｂ以降の処理を断念する。ステップＳ３６においてサービス提供サーバ５は、リクエストＲ２について処理を完了できなかった旨を、アプリケーション実行装置３に返信する。

（サービス提供サーバ）
図３を参照して、本発明の実施の形態に係るサービス提供サーバ５を説明する。サービス提供サーバ５は、記憶装置１０、処理装置２０および通信制御装置３０を備える一般的なコンピュータである。一般的なコンピュータがサービス提供プログラムを実行することにより、図３に示す機能を実現する。

記憶装置１０は、ＲＯＭ（Read Only Memory）、ＲＡＭ（Random access memory）、ハードディスク等であって、処理装置２０が処理を実行するための入力データ、出力データおよび中間データを記憶する。処理装置２０は、ＣＰＵ（Central Processing Unit）であって、サービス提供サーバ５における処理を実行する。通信制御装置３０は、サービス提供サーバ５が、アプリケーション実行装置３および部品提供サーバ７に通信可能に接続するためのインタフェースである。

記憶装置１０は、サービス提供プログラム（図示せず）を記憶するとともに、処理待機データ１１および輻輳状態データ１２を記憶する。

処理待機データ１１は、部品提供サーバ７で処理を待機するリクエストを特定する。処理待機データ１１は、各部品提供サーバ７に待機中のリクエストの識別子を含み、いわゆる待ち行列のデータである。処理待機データ１１は、待機中のリクエストについて、部品提供サーバ７の識別子および処理順を含み、そのほか、各部品提供サーバ７に入力するパラメータを含んでも良い。

処理待機データ１１は、例えば、図４に示すように、Ａ部品提供サーバ７ａの処理を待機するＡ処理待機データ１１ａ、Ｂ部品提供サーバ７ｂの処理を待機するＢ処理待機データ１１ｂ、…を備える。処理待機データ１１で設定される「処理順」は、所定のアルゴリズムにより適宜設定される。

処理待機データ１１は、部品提供サーバ７が輻輳した際に作成され、輻輳中でない部品提供サーバ７については作成されない。輻輳中でない場合、部品提供サーバ７によってリクエストがすぐに処理されるので、処理を待機する必要がないからである。

図４に示す様に、Ａ部品提供サーバ７ａおよびＢ部品提供サーバ７ｂの両方が輻輳しており、Ａ→Ｂの順で処理されるリクエストＲ１０１およびＲ１０２があり、リクエストＲ１０１がＡ部品提供サーバ７ａによって処理されると、図５に示す処理待機データ１１’に更新される。

図５に示すＡ部品提供サーバ７ａのＡ処理待機データ１１ａ’において、リクエストＲ１０１が削除され、リクエストＲ１０２のみが残る。また、Ｂ部品提供サーバ７ｂのＢ処理待機データ１１ｂ’において、リクエストＲ１０１が新たに挿入される。このように、処理待機データ１１は、各部品提供サーバ７の処理の進捗に従って、適宜更新される。

輻輳状態データ１２は、各部品提供サーバ７が輻輳しているか否かを特定するデータである。輻輳状態データ１２は、例えば、図６に示すように、各部品提供サーバ７の識別子と、各部品提供サーバの輻輳状態とを対応づけて記憶する。

処理装置２０は、受付手段２１、リクエスト処理手段２２、応答手段２４および輻輳管理手段２５を備える。

受付手段２１は、アプリケーション実行装置３から、アプリケーションの実行に用いられる複数の部品を特定する複数のリクエストを受信する。ここで入力されるリクエストは、複数の部品提供サーバ７にわたって処理される部品の識別子と、その処理順序を含み、各部品提供サーバ７に入力するパラメータを含んでも良い。

リクエスト処理手段２２は、複数の部品提供サーバ７のそれぞれにリクエストを処理させる。リクエスト処理手段２２は、入力されたリクエストで特定される部品とその処理順序に従って、各部品提供サーバ７にリクエストを入力させる。

ここでリクエスト処理手段２２は、部品提供サーバ７が輻輳していない場合、より具体的には、部品提供サーバ７にリクエストを処理するリソースがある場合、リクエストを待機させることなく、入力されたリクエストを、部品提供サーバ７に入力し、処理させる。

またリクエスト処理手段２２は、部品提供サーバ７が輻輳している場合、この部品提供サーバ７に対応する処理待機データ１１の待ち行列に、入力されたリクエストを格納する。またリクエスト処理手段２２は、部品提供サーバ７のリソースが空くと、この部品提供サーバ７に対応する処理待機データ１１を参照して、待機中のリクエストを部品提供サーバ７に入力する。部品提供サーバ７に入力されたリクエストは、処理待機データ１１から削除される。

さらにリクエスト処理手段２２は、部品提供サーバ７によって処理されるとその結果を保持する。リクエストにおいて未処理の部品が特定されている場合、その部品を提供する部品提供サーバ７に、リクエストを処理させる。一方、アプリケーション実行装置３から受信したリクエストで特定される全ての部品が処理されると、リクエスト処理手段２２は、応答手段２４に通知する。

応答手段２４は、アプリケーション実行装置３に、リクエストの処理結果を応答する。アプリケーション実行装置３から受信したリクエストで特定される全ての部品が処理されたとリクエスト処理手段２２から通知されると、応答手段２４は、その処理結果を、リクエストの送信元のアプリケーション実行装置３に返信する。

輻輳管理手段２５は、部品提供サーバ群６の各部品提供サーバ７の輻輳状態を監視し、輻輳状態データ１２を逐次更新する。

ここで、リクエスト処理手段２２は、廃棄手段２３を備える。廃棄手段２３は、所定の部品提供サーバ７の処理待機データ１１において、既に多くの待機中のリクエストが格納されており、所定の上限数に達する場合、所定のロジックで選択されたリクエストを廃棄する。

廃棄手段２３は、部品提供サーバ７での処理を待機するリクエストを特定する処理待機データ１１を参照して、待機中のリクエスト数が上限数に達するか否かを確認する。上限数は、予め定められており、部品提供サーバ７毎に異なる数が設定されても良い。待機中のリクエスト数が上限数に達する場合、廃棄手段２３は、待機中の各リクエストの後続の処理で用いる部品提供サーバ７の状態に基づいて、廃棄リクエストを特定し、廃棄リクエスト以外のリクエストを、この所定の部品提供サーバ７に処理させる。

ここで、部品提供サーバ７の「状態」は、部品提供サーバ７のリソースの混雑状態であって、より具体的には、輻輳中であるか否かの状態である。廃棄手段２３は、後続の処理で用いる部品提供サーバ７であって、輻輳中の部品提供サーバ７が多いリクエストを、廃棄リクエストと特定する。

例えば、Ｂ処理待機データ１１ｂにおいて、図７に示すように、リクエストＲ２０１、Ｒ２０２・・・Ｒ２１１の１１個のリクエストが格納されているとする。Ｂ処理待機データ１１ｂの上限数が「１０」の場合、現在の格納数は上限数を上回っているので、いずれかのリクエストを廃棄する必要がある。

そこで本発明の実施の形態に係る廃棄手段２３は、Ｂ処理待機データ１１ｂに格納された各リクエストについて、今後用いる予定の各部品提供サーバ７のうち輻輳中の部品提供サーバ７の数を特定する。

例えば、リクエストＲ２０１は、「Ａ→Ｂ→Ｃ→Ｄ」の順で処理され、Ａ部品提供サーバ７ａでの処理は完了している。図６に示すように、Ｂ部品提供サーバ７ｂ、Ｄ部品提供サーバ７ｄおよびＥ部品提供サーバ７ｅが輻輳状態の場合、リクエストＲ２０１の今後用いる予定の輻輳中の部品提供サーバ７の数は、Ｂ部品提供サーバ７ｂおよびＤ部品提供サーバ７ｄの２つである。

同様にリクエストＲ２０２は、「Ａ→Ｂ→Ｄ→Ｅ」の順で処理され、Ａ部品提供サーバ７ａでの処理は完了している。従って、リクエストＲ２０２の今後用いる予定の輻輳中の部品提供サーバ７の数は、Ｂ部品提供サーバ７ｂ、Ｄ部品提供サーバ７ｄおよびＥ部品提供サーバ７ｅの３つである。リクエストＲ２１１は、「Ｂ→Ｆ」の順で処理され、Ａ部品提供サーバ７ａでの処理は完了している。従って、リクエストＲ２１１の今後用いる予定の輻輳中の部品提供サーバ７の数は、Ｂ部品提供サーバ７ｂのみの１つである。また、図７に示す例において、処理順３ないし１０の各リクエストについて、今後用いる予定の輻輳中の部品提供サーバ７の数は、０ないし２のいずれかであるとする。

従って図７に示す例の場合、Ｂ部品提供サーバ７ｂにおいて今後用いる予定の輻輳中の部品提供サーバ７の数が最も多いのは、リクエストＲ２０２である。リクエストＲ２０２は、Ｂ部品提供サーバ７ｂに処理をさせたとしても、後続の処理でも待機時間が発生したり廃棄されたりする可能性が高いので、廃棄手段２３は、リクエストＲ２０２を廃棄リクエストとして特定する。

廃棄手段２３は、廃棄リクエストを、Ｂ処理待機データ１１ｂからリクエストＲ２０２を削除して、廃棄リクエスト以外のリクエストを、適宜処理順を更新する。また廃棄手段２３は、Ｂ処理待機データ１１ｂからリクエストＲ２０２を削除した旨を、応答手段２４に通知する。

応答手段２４、廃棄リクエストについて、アプリケーション実行装置にリクエストが廃棄された旨を応答する。図７の例では応答手段２４は、リクエストＲ２０２が削除された旨を、リクエストＲ２０２の送信元のアプリケーション実行装置３に通知する。

図８を参照して、リクエスト処理手段２２の処理を説明する。図８は、処理待ちリクエストのある所定の部品提供サーバ７についてのリクエスト処理手段２２の処理を示す。

まずリクエスト処理手段２２は、事象の発生を待機する。部品提供サーバ７へのリクエストが新たに発生した場合、ステップＳ１１１に進む。ステップＳ１１１においてリクエスト処理手段２２は、処理待機データ１１に、新たに発生したリクエストに関する情報を設定する。ステップＳ１１２においてリクエスト処理手段２２が、処理待機データ１１において、この所定の部品提供サーバ７の処理を待機中のリクエスト数が、上限値を超えないと判定する場合、ステップＳ１０１に戻り、新たな事象の発生を待機する。

ステップＳ１１２においてリクエスト処理手段２２が、所定の部品提供サーバ７の処理を待機中のリクエスト数が、上限値を超えると判定する場合、ステップＳ１１３に進む。ステップＳ１１３においてリクエスト処理手段２２は、処理待機データ１１において、この所定の部品提供サーバ７の処理を待機する各リクエストについて、後続の処理で用いる輻輳中の部品提供サーバ７の数を特定する。ステップＳ１１４において、ステップＳ１１３の結果に基づいて、後続の処理で用いる輻輳中の部品提供サーバ７の数が最も多いリクエストを廃棄リクエストと特定する。

ステップＳ１１５においてリクエスト処理手段２２は、ステップＳ１１４で特定された廃棄リクエストを、処理待機データ１１から削除して、その旨を、応答手段２４に通知する。その後、リクエスト処理手段２２は、ステップＳ１０１に戻り、新たな事象の発生を待機する。

一方、部品提供サーバ７が、リソースが空くなどにより、新たなリクエストを処理可能になった場合、ステップＳ１２１に進む。ステップＳ１２１においてリクエスト処理手段２２は、処理待機データ１１を参照して、最も処理順位の高いリクエストを、部品提供サーバ７に処理させる。ステップＳ１２２において部品提供サーバ７は、ステップＳ１２１で部品提供サーバ７に入力したリクエストを処理待機データ１１から削除する。

ステップＳ１２３においてリクエスト処理手段２２は、部品提供サーバ７から処理結果を取得すると、ステップＳ１２４において、後続の処理がある場合、後続の処理を担う部品提供サーバ７に、リクエストが発生することを通知し、後続の処理がなくリクエストで指定された全ての部品提供サーバ７による処理が完了した場合、応答手段２４にその旨を通知する。その後リクエスト処理手段２２は、ステップＳ１０１に戻り、新たな事象の発生を待機する。

このような本発明の実施の形態に係るサービス提供システム２は、所定数を超える数のリクエストが、部品提供サーバ７の処理を待機している場合、後続の処理で滞留する可能性の高いリクエストを廃棄する。これにより、サービス提供システム２において、待機中のリクエスト数を制限するとともに、滞留しない可能性の高いリクエストを優先的に処理することにより、アプリケーション実行装置３によるリクエストの再送数を抑制し、処理の滞留可能性を抑制することができる。

（その他の実施の形態）
上記のように、本発明の実施の形態によって記載したが、この開示の一部をなす論述および図面はこの発明を限定するものであると理解すべきではない。この開示から当業者には様々な代替実施の形態、実施例および運用技術が明らかとなる。

例えば、本発明の実施の形態に記載したサービス提供サーバは、図３に示すように一つのハードウエア上に構成されても良いし、その機能や処理数に応じて複数のハードウエア上に構成されても良い。また、既存の情報処理システム上に実現されても良い。

本発明はここでは記載していない様々な実施の形態等を含むことは勿論である。従って、本発明の技術的範囲は上記の説明から妥当な特許請求の範囲に係る発明特定事項によってのみ定められるものである。

１ アプリケーション提供システム
２ サービス提供システム
３ アプリケーション実行装置
４、８ 通信ネットワーク
５ サービス提供サーバ
６ 部品提供サーバ群
７ 部品提供サーバ
１０ 記憶装置
１１ 処理待機データ
１２ 輻輳状態データ
２０ 処理装置
２１ 受付手段
２２ リクエスト処理手段
２３ 廃棄手段
２４ 応答手段
２５ 輻輳管理手段

Claims (8)

1. アプリケーション実行装置から、アプリケーションの実行に用いられる複数の部品を特定する複数のリクエストを受信するサービス提供サーバと、前記サービス提供サーバに接続し、少なくとも一つの部品を提供する複数の部品提供サーバを備えるサービス提供システムであって、
   前記サービス提供サーバは、
   前記複数の部品提供サーバのそれぞれにリクエストを処理させるリクエスト処理手段と、
   前記アプリケーション実行装置に、リクエストの処理結果を応答する応答手段を備え、
   前記リクエスト処理手段は、
   部品提供サーバでの処理を待機するリクエストを特定する処理待機データを参照して、待機中のリクエスト数が上限数に達する場合、
   待機中の各リクエストの後続の処理で用いる他の部品提供サーバの状態に基づいて、廃棄リクエストを特定し、前記廃棄リクエスト以外のリクエストを、部品提供サーバに処理させる
   ことを特徴とするサービス提供システム。
2. 前記他の部品提供サーバの状態は、輻輳中であるか否かであって、
   前記リクエスト処理手段は、後続の処理で用いる部品提供サーバであって、輻輳中の部品提供サーバが多いリクエストを、前記廃棄リクエストと特定する
   ことを特徴とする請求項１に記載のサービス提供システム。
3. 前記応答手段は、前記廃棄リクエストについて、前記アプリケーション実行装置にリクエストが廃棄された旨を応答する
   ことを特徴とする請求項１または２に記載のサービス提供システム。
4. アプリケーション実行装置から、アプリケーションの実行に用いられる複数の部品を特定する複数のリクエストを受信するサービス提供サーバと、前記サービス提供サーバに接続し、少なくとも一つの部品を提供する複数の部品提供サーバを備えるサービス提供システムに用いられる前記サービス提供サーバであって、
   前記複数の部品提供サーバのそれぞれにリクエストを処理させるリクエスト処理手段と、
   前記アプリケーション実行装置に、リクエストの処理結果を応答する応答手段を備え、
   前記リクエスト処理手段は、
   部品提供サーバでの処理を待機するリクエストを特定する処理待機データを参照して、待機中のリクエスト数が上限数に達する場合、
   待機中の各リクエストの後続の処理で用いる他の部品提供サーバの状態に基づいて、廃棄リクエストを特定し、前記廃棄リクエスト以外のリクエストを、部品提供サーバに処理させる
   ことを特徴とするサービス提供サーバ。
5. 前記応答手段は、前記廃棄リクエストについて、前記アプリケーション実行装置にリクエストが廃棄された旨を応答する
   ことを特徴とする請求項４に記載のサービス提供サーバ。
6. アプリケーション実行装置から、アプリケーションの実行に用いられる複数の部品を特定する複数のリクエストを受信するサービス提供サーバと、前記サービス提供サーバに接続し、少なくとも一つの部品を提供する複数の部品提供サーバを備えるサービス提供システムに用いられるサービス提供方法であって、
   前記複数の部品提供サーバのそれぞれにリクエストを処理させるステップと、
   前記アプリケーション実行装置に、リクエストの処理結果を応答するステップと、
   部品提供サーバでの処理を待機するリクエストを特定する処理待機データを参照して、待機中のリクエスト数が上限数に達する場合、
   待機中の各リクエストの後続の処理で用いる他の部品提供サーバの状態に基づいて、廃棄リクエストを特定し、前記廃棄リクエスト以外のリクエストを、部品提供サーバに処理させるステップ
   を備えることを特徴とするサービス提供方法。
7. 前記廃棄リクエストについて、前記アプリケーション実行装置にリクエストが廃棄された旨を応答するステップ
   をさらに備えることを特徴とする請求項６に記載のサービス提供方法。
8. コンピュータに、請求項４または５に記載のサービス提供サーバとして機能させるためのサービス提供プログラム。

Images