JP6595419B2 - Ａｐｉ提供装置及びａｐｉリクエスト制御方法 - Google Patents

Description

本発明は、ＡＰＩリクエストを制御する技術に関する。

現在、ＷｅｂＡＰＩの普及に伴い、ＡＰＩ（Application Program Interface）のマッシュアップ（複数のＡＰＩを連携させる技術）によるアプリケーション開発が一般的になっている。ＡＰＩの用途は多様化しているが、特にイネーブラをＡＰＩとして提供するＡＰＩ提供装置が考案されている。

ＡＰＩ提供装置は、イネーブラの備える機能をＡＰＩとして提供し、各ＡＰＩをコールするためのエンドポイントが実装されている。このようなＡＰＩ提供装置を利用することにより、アプリケーション開発者は、提供するサービスに応じて各機能のＡＰＩを利用可能なアプリケーションを開発することができる。

例えば、図６に示すように、イネーブラＡの機能ａからイネーブラＤの機能ｄをその順番で利用するＡＰＩリクエストにより、それら各機能を提供可能なアプリケーションを開発することができる。開発されるアプリケーションの種類は様々であるため、ＡＰＩ提供装置には、ＡＰＩリクエストが利用する各イネーブラの利用順を管理するＡＰＩアグリゲーション部が具備されている。

特開２０１６−１３５５号公報

ここで、例えば、一連の機能を完結した上で意味を成すサービスにおいて、一部のイネーブラで輻輳が発生して処理が完結しない場合、アプリケーションはＡＰＩリクエストを再送し、ＡＰＩ提供装置は、その再送に応じて、ＡＰＩへアクセスするＡＰＩ処理を最初から実行する必要がある。これにより、既に処理が完了していたイネーブラの機能が再実行されるため、イネーブラの再利用によりリソース消費の無駄が生じ、更に所定のイネーブラで発生した輻輳に起因して他のイネーブラにも輻輳が波及する可能性がある（図７参照）。

上記特許文献１では、ＡＰＩ処理を実行する際に、各イネーブラの処理リソースを事前に予約する方法が提案されている。これにより、ＡＰＩ処理の再実行を防止することができる。しかし、事前にリソースを確保しておくため、イネーブラＡとイネーブラＢの間で時間が空くような場合には予約したリソースを他のＡＰＩリクエストに振り分けできない等、イネーブラのリソースを適切に活用することは難しい。

すなわち、従来のＡＰＩ提供装置は、イネーブラで輻輳等が発生した場合に、イネーブラのリソースを有効に活用できないという課題があった。

本発明は、上記事情を鑑みてなされたものであり、イネーブラのリソースを有効に活用することを目的とする。

以上の課題を解決するため、請求項１に係るＡＰＩ提供装置は、複数のイネーブラでそれぞれ提供される複数の機能をそれぞれＡＰＩとしてアプリケーションに提供するＡＰＩ提供装置において、アプリケーションから要求された複数のＡＰＩリクエストの各処理優先度をそれぞれ求め、前記複数のＡＰＩリクエストが利用予定の所定のイネーブラで更なるＡＰＩリクエストを受け付けられない場合、最も処理優先度の低いＡＰＩリクエストを破棄する調整部、を備えることを要旨とする。

請求項２に係るＡＰＩ提供装置は、請求項１に記載のＡＰＩ提供装置において、前記複数のＡＰＩリクエストは、前記複数のイネーブラのうち少なくとも１つ以上を利用するＡＰＩリクエストであって、前記複数のＡＰＩリクエストが前記所定のイネーブラを利用する迄にそれぞれ利用した各イネーブラの数又は消費した各リソースの量を記憶する記憶部を更に備え、前記調整部は、前記複数のＡＰＩリクエストの各処理優先度を前記各イネーブラの数又は前記各リソースの量に応じて決定することを要旨とする。

請求項３に係るＡＰＩ提供装置は、請求項２に記載のＡＰＩ提供装置において、前記調整部は、前記イネーブラの数又は前記リソースの量の最も小さいＡＰＩリクエストを破棄することを要旨とする。

請求項４に係るＡＰＩリクエスト制御方法は、複数のイネーブラでそれぞれ提供される複数の機能をそれぞれＡＰＩとしてアプリケーションに提供するＡＰＩ提供装置で行うＡＰＩリクエスト制御方法において、アプリケーションから要求された複数のＡＰＩリクエストの各処理優先度をそれぞれ求め、前記複数のＡＰＩリクエストが利用予定の所定のイネーブラで更なるＡＰＩリクエストを受け付けられない場合、最も処理優先度の低いＡＰＩリクエストを破棄する調整ステップ、を実行させることを要旨とする。

請求項５に係るＡＰＩリクエスト制御方法は、請求項４に記載のＡＰＩリクエスト制御方法において、前記複数のＡＰＩリクエストは、前記複数のイネーブラのうち少なくとも１つ以上を利用するＡＰＩリクエストであって、前記複数のＡＰＩリクエストが前記所定のイネーブラを利用する迄にそれぞれ利用した各イネーブラの数又は消費した各リソースの量を記憶部に記憶する記憶ステップを更に実行させ、前記調整ステップでは、前記複数のＡＰＩリクエストの各処理優先度を前記各イネーブラの数又は前記各リソースの量に応じて決定することを要旨とする。

請求項６に係るＡＰＩリクエスト制御方法は、請求項５に記載のＡＰＩリクエスト制御方法において、前記調整ステップでは、前記イネーブラの数又は前記リソースの量の最も小さいＡＰＩリクエストを破棄することを要旨とする。

本発明によれば、イネーブラのリソースを有効に活用することができる。

システムの全体構成を示す図である。 バッファ部の機能ブロック構成を示す図である。 ＡＰＩリクエスト制御方法の動作を示す図である。 ＡＰＩリクエスト処理情報の例を示す図である。 新たなＡＰＩリクエスト情報の例を示す図である。 提供サービスのイメージを示す図である。 課題説明時の参照図である。

本発明は、アプリケーションから要求された複数のＡＰＩリクエストの各処理優先度をそれぞれ求め、複数のＡＰＩリクエストが利用予定の所定のイネーブラで更なるＡＰＩリクエストを受け付けられない場合、最も処理優先度の低いＡＰＩリクエストを破棄することを特徴とする。これにより、処理優先度の高いＡＰＩリクエストを優先して処理するので、イネーブラのリソースを有効に活用することができる。

また、本発明は、複数のＡＰＩリクエストの各処理優先度を、複数のＡＰＩリクエストが上記所定のイネーブラを利用する迄にそれぞれ利用した各イネーブラの数又は消費した各リソースの量に応じて決定することを特徴とする。特に、イネーブラの利用数又はリソースの消費量の最も小さいＡＰＩリクエストを破棄することを特徴とする。つまり、イネーブラの利用数又はリソースの消費量の大きいＡＰＩリクエストの処理を優先するので、該ＡＰＩリクエストが上記所定のイネーブラを利用する迄にそれぞれ利用していたイネーブラが再利用・再実行されることを防止することができる。これにより、イネーブラの再利用・再実行による無駄なリソース消費を低減でき、イネーブラのリソースを有効に活用することができる。

以下、本発明を実施する一実施の形態について図面を用いて説明する。

＜第１の実施の形態＞
図１は、第１の実施の形態に係るシステムの全体構成を示す図である。本実施の形態に係るシステム１は、イネーブラ装置１０と、ＡＰＩ提供装置２０と、アプリケーション利用装置３０と、を備えて構成される。

イネーブラ装置１０は、ＡＰＩリクエストに応じて自身が備える機能を提供するイネーブラ（ソフトウェアプログラム）を備える装置である。具体的には、機能ａを提供するイネーブラＡを備えるイネーブラ装置１０、機能ａとは異なる機能ｂを提供するイネーブラＢを備えるイネーブラ装置１０等、少なくとも１つ以上のイネーブラ装置により構成される。

例えば、イネーブラＡは、ユーザ単位に住所録（住所、氏名、電話番号、所定サービスのＩＤ等）を管理するデータベースの機能ａを提供し、イネーブラＢは、電話発信・切断する機能ｂを提供し、イネーブラＣは、メッセージを送信する機能ｃを提供する。

ＡＰＩ提供装置２０は、イネーブラ装置１０が備えるイネーブラの機能のＡＰＩをアプリケーションに提供する装置であり、アプリケーションが各ＡＰＩをコールするためのエンドポイントが実装されている。

例えば、上記例の場合、ＡＰＩ提供装置２０は、住所録への情報の登録・取得・変更・削除を行うＡＰＩ（イネーブラＡのＡＰＩ）、電話発信・切断を行うＡＰＩ（イネーブラＢのＡＰＩ）、メッセージ送信を行うＡＰＩ（イネーブラＣのＡＰＩ）、を全て提供し、アプリケーションから送信されたＡＰＩリクエストを該当のＡＰＩを介して該当のイネーブラへ転送する。

本実施の形態に係るＡＰＩ提供装置２０は、図１に示したように、ＡＰＩアグリゲーション部２０１と、バッファ部２０２と、を備えて構成される。

ＡＰＩアグリゲーション部２０１は、アプリケーション利用装置３０から送信されるＡＰＩリクエストが利用する各イネーブラの利用順を管理する機能を備える。ＡＰＩリクエストが複数の場合、複数のＡＰＩリクエストがそれぞれ利用する各イネーブラの利用順をそれぞれ管理する。例えば、あるＡＰＩリクエストが「イネーブラＡのＡＰＩ→イネーブラＢのＡＰＩ→イネーブラＣのＡＰＩ→イネーブラＤのＡＰＩ」の順で各イネーブラを利用することを管理する。

バッファ部２０２は、イネーブラ毎に設けられ、輻輳等の理由により自身に対応するイネーブラが処理できない等、ＡＰＩリクエストが利用予定のイネーブラで更なるＡＰＩリクエストを受け付けられない場合に、そのイネーブラを利用予定のＡＰＩリクエストを一時的に格納する機能を備える。

また、バッファ部２０２は、輻輳等の理由によりイネーブラで更なるＡＰＩリクエストを受け付けられない場合に、ＡＰＩリクエストが自身に対応するイネーブラを利用する迄に利用したイネーブラに関する情報を記憶する機能を備える。

例えば、あるＡＰＩリクエストが「イネーブラＡのＡＰＩ→イネーブラＢのＡＰＩ→イネーブラＣのＡＰＩ→イネーブラＤのＡＰＩ」の順番で各イネーブラを経由するが、イネーブラＤのイネーブラ装置１０ｄで輻輳が発生した場合、イネーブラＤに対応するバッファ部２０２ｄは、そのＡＰＩリクエストを一旦格納し、そのＡＰＩがこれまでに経由してきた「イネーブラＡのＡＰＩ→イネーブラＢのＡＰＩ→イネーブラＣのＡＰＩ」に関する情報を処理済イネーブラ情報として記憶する。

引き続き、バッファ部２０２の構成について詳述する。図２は、本実施の形態に係るバッファ部２０２の機能ブロック構成を示す図である。本実施の形態に係るバッファ部２０２は、ＡＰＩリクエスト調整部２００１と、ＡＰＩリクエスト格納部２００２と、データ記憶部２００３と、を備えて構成される。

ＡＰＩリクエスト格納部２００２は、上述した通り、「ＡＰＩリクエストが利用予定のイネーブラで更なるＡＰＩリクエストを受け付けられない場合に、そのイネーブラを利用予定のＡＰＩリクエストを一時的に格納する機能」を備える。

データ記憶部２００３は、上述した「ＡＰＩリクエストが自身に対応するイネーブラを利用する迄に利用したイネーブラに関する情報（処理済イネーブラ情報）」等、ＡＰＩリクエスト格納部２００２に格納されたＡＰＩリクエストに関する情報をＡＰＩリクエスト処理情報として記憶する機能を備える。

ＡＰＩリクエスト調整部２００１は、上記ＡＰＩリクエスト処理情報を用いて、受信したＡＰＩリクエストとＡＰＩリクエスト格納部２００２に格納されている複数のＡＰＩリクエストとの各処理優先度をそれぞれ求め、最も処理優先度の低いＡＰＩリクエストを破棄する機能を備える。なお、処理優先度の算出方法については後述する。

次にアプリケーション利用装置３０について説明する。アプリケーション利用装置３０は、ＡＰＩリクエストを送信し、その送信に応じて返信されたＡＰＩレスポンスを受信するアプリケーションを備えたサーバ装置である。ここで、アプリケーションとは、１つ以上のイネーブラ装置１０とＡＰＩ提供装置２０とを用いて、各イネーブラの機能のＡＰＩを活用することにより、所定のサービスを提供するソフトウェアプログラムである。

また、ＡＰＩリクエストとは、複数のイネーブラのうち少なくとも１つ以上を所定順・非所定順で利用するＡＰＩリクエストである。例えば、電話発信を行うアプリケーションの場合、ＡＰＩリクエストは、相手の電話番号を住所録から取得するイネーブラＡのＡＰＩと、電話発信・切断を行うイネーブラＢのＡＰＩと、をその順序で経由する。一方、それに加えてウェブブラウジングを行うアプリケーションの場合、それら２つのＡＰＩとウェブブラウジングを行うイネーブラＥのＡＰＩとの間で利用順はない。この場合、イネーブラＥのＡＰＩは任意のタイミングで経由される。

次に、本実施の形態に係るＡＰＩ提供装置２０で行うＡＰＩリクエスト制御方法について説明する。図３は、本実施の形態に係るＡＰＩリクエスト制御方法の動作を示す図である。

まず、ＡＰＩ提供装置２０は、アプリケーション利用装置３０のアプリケーションからＡＰＩリクエストを受信した後（ステップＳ１）、そのＡＰＩリクエストがイネーブラを要求しているか否かを判定し（ステップＳ２）、イネーブラを要求している場合には、要求するイネーブラのＩＤを判定する（ステップＳ３）。例えば、ＡＰＩアグリゲーション部２０１に格納されたイネーブラの利用順情報を参照することにより、受信したＡＰＩリクエストがイネーブラを要求しているのか、どのイネーブラのＡＰＩを要求しているのか、更にはイネーブラへの要求が完了したかを判定することができる。

次に、受信したＡＰＩリクエストで要求されたイネーブラのＡＰＩがイネーブラＡの場合、イネーブラＡに対応するバッファ部２０２は、イネーブラＡで輻輳が発生しているか否かを判定し（ステップＳ４）、イネーブラＡで輻輳が発生していない場合には、受信したＡＰＩリクエストを処理可能、すなわち、イネーブラＡの機能を現在提供可能であることから、ＡＰＩリクエストをそのままイネーブラＡへ転送する（ステップＳ５）。その後、バッファ部２０２は、自身で記憶しているＡＰＩリクエスト処理情報に含まれる処理済イネーブラ情報を更新し（ステップＳ６）、該ＡＰＩリクエスト情報に更に含まれる処理済イネーブラ数を更新する（ステップＳ７）。

ここで、ＡＰＩリクエスト処理情報の例を図４に示す。ＡＰＩリクエスト処理情報には、例えば、ＡＰＩ提供装置２０又はバッファ部２０２がＡＰＩリクエストを受け付けた処理順、該ＡＰＩリクエストに関するＡＰＩリクエスト情報（例えば、ＡＰＩリクエストのＩＤ、パラメータ等）、該ＡＰＩリクエストで既に処理されたイネーブラのＩＤに関する処理済イネーブラ情報、該ＡＰＩリクエストで既に処理されたイネーブラの数に関する処理済みイネーブラ数、が格納されている。

例えば、受信したＡＰＩリクエストで既にイネーブラＡが利用され、次にイネーブラＢを利用する場合、イネーブラＢに対応するバッファ部２０２は、そのイネーブラＢで輻輳が発生していなければ、その受信したＡＰＩリクエストをイネーブラＢへ転送し、そして、ＡＰＩリクエスト処理情報の処理済イネーブラ情報を「Ａ」から「Ａ→Ｂ」に変更し、処理済イネーブラ数を「１」から「２」に変更する。

図３に戻り、ステップＳ４において、イネーブラＡで輻輳が発生している場合、イネーブラＡに対応するバッファ部２０２（ＡＰＩリクエスト調整部２００１）は、ＡＰＩリクエスト格納部２００２にＡＰＩリクエストを格納するための空き容量があるか否かを判定する（ステップＳ８）。ＡＰＩリクエスト格納部２００２に該空き容量がある場合、ＡＰＩリクエスト調整部２００１は、受信したＩＰリクエストをただちに破棄することなくＡＰＩリクエスト格納部２００２に一旦格納し（ステップＳ９）、イネーブラＡの輻輳が解消した後にステップＳ５へ進み、ＡＰＩリクエスト格納部２００２に格納していたＡＰＩリクエストをイネーブラＡへ順次転送する。

一方、ステップＳ８において、ＡＰＩリクエスト格納部２００２に空き容量がない場合、ＡＰＩリクエスト調整部２００１は、受信したＡＰＩリクエストの処理優先度と、ＡＰＩリクエスト格納部２００２に格納されている各ＡＰＩリクエストの処理優先度と、をそれぞれ算出する（ステップＳ１０）。

そして、ＡＰＩリクエスト調整部２００１は、受信したＡＰＩリクエストの処理優先度が複数の処理優先度のうち最も小さいか否かを判定し（ステップＳ１１）、受信したＡＰＩリクエストの処理優先度が最も小さい場合には、その受信したＡＰＩリクエストを破棄する（ステップＳ１２）。その後、ステップＳ５→ステップＳ６→ステップＳ７へ進む。

一方、ＡＰＩリクエスト格納部２００２に格納されている各ＡＰＩリクエストの中に最も処理優先度が小さいものがある場合、ＡＰＩリクエスト調整部２００１は、その最も処理優先度の小さいＡＰＩリクエストをＡＰＩリクエスト格納部２００２から削除し（ステップＳ１３）、ステップＳ９へ進み、受信していたＡＰＩリクエストをＡＰＩリクエスト格納部２００２に格納する。その後、ステップＳ５→ステップＳ６→ステップＳ７へ進む。

そして、ステップＳ７の後はステップＳ２に戻り、受信中のＡＰＩリクエストが他のイネーブラを引き続き要求している場合には、該当のイネーブラに対応するバッファ部２０２が、ステップＳ４〜ステップＳ１３と同様の処理を行う（ステップＳ１００）。その後、受信中のＡＰＩリクエストがイネーブラへの要求を完了した場合に、ＡＰＩ提供装置２０は、受信していたＡＰＩリクエストに対するＡＰＩレスポンスを要求元のアプリケーションへ返信する（ステップＳ１４）。

続いて、ＡＰＩリクエストの処理優先度の算出方法及び破棄するＡＰＩリクエストの決定方法について説明する。この動作は、上述したステップＳ１０〜ステップＳ１３で行われる。ＡＰＩリクエスト調整部２００１は、データ記憶部２００３に記憶しているＡＰＩリクエスト処理情報を参照することができる。このＡＰＩリクエスト処理情報には、図４に示したように処理済イネーブラ数が格納されている。

ここで、イネーブラのリソースの有効利用を考えると、ＡＰＩリクエストが次のイネーブラを利用する迄に既に利用していた処理済のイネーブラを再び利用・実行することは避けるべきである。それゆえ、本実施の形態では、処理済イネーブラ数に応じてＡＰＩリクエストの処理優先度を決定する。具体的には、処理済イネーブラ数の大きい方のＡＰＩリクエストの処理優先度を高くし、処理済イネーブラ数の小さい方のＡＰＩリクエストの処理優先度を低くする。

例えば、図４に示したＡＰＩリクエスト処理情報のＡＰＩリクエストがイネーブラＤに対応するバッファ部２０２のＡＰＩリクエスト格納部２００２に格納されている場合、ＡＰＩリクエスト調整部２００１は、処理順「１」のＡＰＩリクエストの処理優先度を、該ＡＰＩリクエストの処理済イネーブラ数が「２」であることから、「２」と算出する。同様に、処理順「２」のＡＰＩリクエストの処理優先度を「３」、処理順「３」のＡＰＩリクエストの処理優先度を「０」と算出する。

ここで、新たに受信したＡＰＩリクエストが図５（ａ）に示すＡＰＩリクエスト情報を備える場合、このＡＰＩリクエストの処理優先度についても同様の計算方法より「０」と算出する。その後、ＡＰＩリクエスト調整部２００１は、新たに受信したＡＰＩリクエストとＡＰＩリクエスト格納部２００２に格納されているＡＰＩリクエストとの各処理優先度を比較し、新たに受信したＡＰＩリクエストの処理優先度が最も小さいので、その新たに受信したＡＰＩリクエストを破棄する。これにより、ＡＰＩリクエスト格納部２００２に格納されていた処理順が「１」のＡＰＩリクエストについて、イネーブラＡとイネーブラＢの処理が再利用・再実行されることを防ぐことができる。なお、処理優先度が同じ場合、ＡＰＩリクエスト格納部２００２に格納されているＡＰＩリクエストの処理を優先する。

一方、新たに受信したＡＰＩリクエストが図５（ｂ）に示すＡＰＩリクエスト情報を備える場合、このＡＰＩリクエストの処理優先度についても同様の計算方法より「３」と算出する。この場合、ＡＰＩリクエスト格納部２００２に格納されているＡＰＩリクエストの方に処理優先度が低いものがあるので、その中から処理優先度が最も低いＡＰＩリクエストをＡＰＩリクエスト格納部２００２から削除し、新たに受信したＡＰＩリクエストをＡＰＩリクエスト格納部２００２に格納する。なお、図４に示したＡＰＩリクエスト処理情報の場合、ＡＰＩリクエスト格納部２００２には処理優先度が最も低いＡＰＩリクエストが２つあるが（処理順「３」のＡＰＩリクエストと処理順「９」のＡＰＩリクエスト）、この場合は処理順の早い方（処理順「３」のＡＰＩリクエスト）を優先する。

以上より、本実施の形態によれば、イネーブラ毎にバッファ部２０２を設け、バッファ部２０２は、複数のＡＰＩリクエストが自身のイネーブラを利用する迄にそれぞれ利用した各イネーブラの数を記憶するデータ記憶部２００３と、アプリケーションから要求された複数のＡＰＩリクエストの各処理優先度をそれぞれ求め、複数のＡＰＩリクエストが利用予定の自身のイネーブラで更なるＡＰＩリクエストを受け付けられない場合、最も処理優先度の低いＡＰＩリクエストを破棄するＡＰＩリクエスト調整部２００１と、を備え、ＡＰＩリクエスト調整部２００１は、複数のＡＰＩリクエストの各処理優先度を各イネーブラの数に応じて決定する。具体的には、イネーブラの数の最も小さいＡＰＩリクエストを破棄する。

つまり、過去に利用したイネーブラ数の大きいＡＰＩリクエストの処理を優先するので、該ＡＰＩリクエストが上記自身のイネーブラを利用する迄にそれぞれ利用していたイネーブラが再利用・再実行されることを防止することができる。これにより、イネーブラの再利用・再実行による無駄なリソース消費を低減でき、イネーブラのリソースを有効に活用することができる。

＜第２の実施の形態＞
第１の実施の形態では、ＡＰＩリクエストの処理優先度を処理済イネーブラ数に応じて決定する場合について説明した。この方法は、全てのイネーブラの処理リソースが等価（例えば、イネーブラＡとイネーブラＢの２つのイネーブラ装置１０の処理能力は等しい）であると仮定している。

一方、複数のイネーブラは、それぞれ、ＡＰＩリクエストを処理するための処理リソースが異なる可能性が高い。そこで、第２の実施の形態では、ＡＰＩリクエストが所定のイネーブラを利用する迄に消費したリソースの量に応じて処理優先度を決定する場合について説明する。なお、本実施の形態に係るＡＰＩ提供装置２０の構成は、第１の実施の形態で用いたＡＰＩ提供装置２０の構成と同様である。

リソースの量とは、イネーブラがＡＰＩリクエストを処理するのに要した計算リソースである。例えば、「ＣＰＵ使用率×時間」等、ＡＰＩリクエストの処理に要したリソース要素（例えば、ＣＰＵ使用率、時間、占有したメモリ量等）を加算・積算した合計値である。算出された消費リソース量は、図４に示したＡＰＩリクエスト処理情報に追加される。なお、各ＡＰＩリクエストについて、過去に同じＡＰＩリクエストを受け付けていた場合にはその受付数、流通する任意のデータ数（例えば、ＡＰＩリクエストに含まれるパラメータ数）等の統計量を算出し、その統計値を重みとして各ＡＰＩリクエストの消費リソース量に加算又は積算してもよい。

ここで、第１の実施の形態と同様にイネーブラのリソースの有効利用を考えると、次のイネーブラを利用する迄に既に消費したリソース量の大きいＡＰＩリクエストを再び処理することは避けるべきである。それゆえ、本実施の形態では、消費していたリソース量の大きい方のＡＰＩリクエストの処理優先度を高くし、消費していたリソース量の小さい方のＡＰＩリクエストの処理優先度を低くする。

それゆえ、図３に示したステップＳ１〜ステップＳ１３において、ＡＰＩリクエスト調整部２００１は、受信したＡＰＩリクエストとＡＰＩリクエスト格納部２００２に格納されている複数のＡＰＩリクエストとの過去の各消費リソース量をそれぞれ求め、最も消費リソース量の小さいＡＰＩリクエストを破棄する。

例えば、１秒当たり５つのＡＰＩリクエストを処理できるイネーブラＡ、１秒当たり１０つのＡＰＩリクエストを処理できるイネーブラＢがある場合、各イネーブラＡ，Ｂは１つのＡＰＩリクエストを処理するのに１秒かかると仮定すると、１つのＡＰＩリクエストが占有するＣＰＵやメモリ量等のリソース量は、イネーブラＡで２０％となりイネーブラＢで１０％となる。この場合、イネーブラＡのリソースの方がリソース消費量の点で価値が稀少なので、イネーブラＢを利用したＡＰＩリクエストよりもイネーブラＡを利用したＡＰＩリクエストを優先し、イネーブラＢを利用したＡＰＩリクエストを破棄する。

以上より、本実施の形態によれば、イネーブラ毎にバッファ部２０２を設け、バッファ部２０２は、複数のＡＰＩリクエストが自身のイネーブラを利用する迄にそれぞれ消費した各リソースの量を記憶するデータ記憶部２００３と、アプリケーションから要求された複数のＡＰＩリクエストの各処理優先度をそれぞれ求め、複数のＡＰＩリクエストが利用予定の自身のイネーブラで更なるＡＰＩリクエストを受け付けられない場合、最も処理優先度の低いＡＰＩリクエストを破棄するＡＰＩリクエスト調整部２００１と、を備え、ＡＰＩリクエスト調整部２００１は、複数のＡＰＩリクエストの各処理優先度を各リソースの量に応じて決定する。具体的には、消費リソース量の最も小さいＡＰＩリクエストを破棄する。

つまり、過去に消費したリソース量の大きいＡＰＩリクエストの処理を優先するので、該ＡＰＩリクエストが上記自身のイネーブラを利用する迄にそれぞれ利用していたイネーブラが再利用・再実行されることを防止することができる。これにより、イネーブラの再利用・再実行による無駄なリソース消費を低減でき、イネーブラのリソースを有効に活用することができる。

＜第３の実施の形態＞
第１の実施の形態及び第２の実施の形態では、図２に示した構成に基づき、バッファ部２０２の内部でＡＰＩリクエストの優先度付を行う場合について説明した。一方、図１に示したＡＰＩ提供装置２０の内部構成、図２に示したバッファ部２０２の内部構成は、あくまでも一例である。例えば、ＡＰＩ提供装置２０が自身で全てのイネーブラを管轄する集中制御のような方法も考えられる。この場合、例えば、バッファ部２０２は、ＡＰＩリクエスト格納部２００２及びデータ記憶部２００３のみを備え、ＡＰＩリクエスト調整部２００１は、バッファ内の機能ではなく、バッファ部２０２の外部において、ＡＰＩ提供装置２０の内部直下の機能として、ＡＰＩアグリゲーション部２０１と並列に配置される。

以上、各実施の形態によれば、ＡＰＩリクエストが破棄された際の再処理による無駄なリソースの利用を低減することができる。これにより、あるイネーブラにて輻輳が発生した場合に、再処理による当該イネーブラ以外のイネーブラでの輻輳を防止することができる。再処理を防止することにより、他のアプリケーションがイネーブラを利用することができ、イネーブラのリソース利用の効率化を達成することができる。

なお、イネーブラの利用順序性が無いＡＰＩリクエスト（例えば、イネーブラＡ，Ｂを利用する必要はあるが、イネーブラＡ→ＢでもイネーブラＢ→Ａでも提供サービスに影響がないＡＰＩリクエスト）場合、各イネーブラのリソースの空き状況を見て、空いているイネーブラから先にリクエストすることも可能である。この場合、ＡＰＩアグリゲーション部２０１により、ＡＰＩリクエストの転送先が適宜決定される。

各実施の形態では、ＡＰＩリクエストの処理優先度をイネーブラの数又はリソースの量に応じて決定する場合について説明したが、バッファ部２０２に記憶する情報には拡張性があるので、必ずしもイネーブラの数又はリソースの量である必要はない。ＡＰＩリクエスト毎の優先度付けを行える指標であればどのような情報でも構わない。

最後に、本実施の形態で説明した、イネーブラ装置１０、ＡＰＩ提供装置２０、アプリケーション利用装置３０は、ＣＰＵ、メモリ、ハードディスク等を備えたコンピュータ（情報処理装置）で実現できる。また、イネーブラ装置１０、ＡＰＩ提供装置２０、アプリケーション利用装置３０としてコンピュータを機能させるためのプログラムや該プログラムの記憶媒体を作成することも可能である。

１…システム
１０…イネーブラ装置
２０…ＡＰＩ提供装置
２０１…ＡＰＩアグリゲーション部
２０２…バッファ部
２００１…ＡＰＩリクエスト調整部
２００２…ＡＰＩリクエスト格納部
２００３…データ記憶部
３０…アプリケーション利用装置

Claims (6)

1. 複数のイネーブラで提供される複数の機能をそれぞれＡＰＩとしてアプリケーションに提供するＡＰＩ提供装置において、
   アプリケーションから要求された複数のＡＰＩリクエストであって、前記複数のイネーブラのうち少なくとも２つ以上を利用する複数のＡＰＩリクエストの各処理優先度をそれぞれ求め、前記複数のＡＰＩリクエストが利用予定の所定のイネーブラで更なるＡＰＩリクエストを受け付けられない場合、最も処理優先度の低いＡＰＩリクエストを破棄する調整部と、
   前記複数のＡＰＩリクエストが前記所定のイネーブラを利用する迄にそれぞれ利用した各イネーブラの数、又は前記複数のＡＰＩリクエストが前記所定のイネーブラを利用する迄にそれぞれ消費した各リソースの量を記憶する記憶部と、を備え、
   前記調整部は、
   前記複数のＡＰＩリクエストの各処理優先度を前記各イネーブラの数又は前記各リソースの量に応じて決定する
   ことを特徴とするＡＰＩ提供装置。
2. 複数のイネーブラで提供される複数の機能をそれぞれＡＰＩとしてアプリケーションに提供するＡＰＩ提供装置において、
   アプリケーションから要求された複数のＡＰＩリクエストであって、前記複数のイネーブラのうち少なくとも２つ以上を利用する複数のＡＰＩリクエストの各処理優先度をそれぞれ求め、前記複数のＡＰＩリクエストが利用予定の所定のイネーブラで更なるＡＰＩリクエストを受け付けられない場合、最も処理優先度の低いＡＰＩリクエストを破棄する調整部と、
   前記複数のＡＰＩリクエストが前記所定のイネーブラを利用する迄にそれぞれ利用した各イネーブラの数を記憶する記憶部と、を備え、
   前記調整部は、
   前記複数のＡＰＩリクエストの各処理優先度を前記各イネーブラの数に応じて決定する
   ことを特徴とするＡＰＩ提供装置。
3. 複数のイネーブラで提供される複数の機能をそれぞれＡＰＩとしてアプリケーションに提供するＡＰＩ提供装置において、
   アプリケーションから要求された複数のＡＰＩリクエストであって、前記複数のイネーブラのうち少なくとも２つ以上を利用する複数のＡＰＩリクエストの各処理優先度をそれぞれ求め、前記複数のＡＰＩリクエストが利用予定の所定のイネーブラで更なるＡＰＩリクエストを受け付けられない場合、最も処理優先度の低いＡＰＩリクエストを破棄する調整部と、
   前記複数のＡＰＩリクエストが前記所定のイネーブラを利用する迄にそれぞれ利用した各イネーブラの数又は消費した各リソースの量を記憶する記憶部と、を備え、
   前記調整部は、
   前記複数のＡＰＩリクエストの各処理優先度を前記各イネーブラの数又は前記各リソースの量に応じて決定し、前記イネーブラの数又は前記リソースの量の最も小さいＡＰＩリクエストを破棄する
   ことを特徴とするＡＰＩ提供装置。
4. 複数のイネーブラで提供される複数の機能をそれぞれＡＰＩとしてアプリケーションに提供するＡＰＩ提供装置で行うＡＰＩリクエスト制御方法において、
   アプリケーションから要求された複数のＡＰＩリクエストであって、前記複数のイネーブラのうち少なくとも２つ以上を利用する複数のＡＰＩリクエストの各処理優先度をそれぞれ求め、前記複数のＡＰＩリクエストが利用予定の所定のイネーブラで更なるＡＰＩリクエストを受け付けられない場合、最も処理優先度の低いＡＰＩリクエストを破棄する調整ステップと、
   前記複数のＡＰＩリクエストが前記所定のイネーブラを利用する迄にそれぞれ利用した各イネーブラの数、又は前記複数のＡＰＩリクエストが前記所定のイネーブラを利用する迄にそれぞれ消費した各リソースの量を記憶部に記憶する記憶ステップと、を行い、
   前記調整ステップでは、
   前記複数のＡＰＩリクエストの各処理優先度を前記各イネーブラの数又は前記各リソースの量に応じて決定する
   ことを特徴とするＡＰＩリクエスト制御方法。
5. 複数のイネーブラで提供される複数の機能をそれぞれＡＰＩとしてアプリケーションに提供するＡＰＩ提供装置で行うＡＰＩリクエスト制御方法において、
   アプリケーションから要求された複数のＡＰＩリクエストであって、前記複数のイネーブラのうち少なくとも２つ以上を利用する複数のＡＰＩリクエストの各処理優先度をそれぞれ求め、前記複数のＡＰＩリクエストが利用予定の所定のイネーブラで更なるＡＰＩリクエストを受け付けられない場合、最も処理優先度の低いＡＰＩリクエストを破棄する調整ステップと、
   前記複数のＡＰＩリクエストが前記所定のイネーブラを利用する迄にそれぞれ利用した各イネーブラの数を記憶部に記憶する記憶ステップと、を行い、
   前記調整ステップでは、
   前記複数のＡＰＩリクエストの各処理優先度を前記各イネーブラの数に応じて決定する
   ことを特徴とするＡＰＩリクエスト制御方法。
6. 複数のイネーブラで提供される複数の機能をそれぞれＡＰＩとしてアプリケーションに提供するＡＰＩ提供装置で行うＡＰＩリクエスト制御方法において、
   アプリケーションから要求された複数のＡＰＩリクエストであって、前記複数のイネーブラのうち少なくとも２つ以上を利用する複数のＡＰＩリクエストの各処理優先度をそれぞれ求め、前記複数のＡＰＩリクエストが利用予定の所定のイネーブラで更なるＡＰＩリクエストを受け付けられない場合、最も処理優先度の低いＡＰＩリクエストを破棄する調整ステップと、
   前記複数のＡＰＩリクエストが前記所定のイネーブラを利用する迄にそれぞれ利用した各イネーブラの数又は消費した各リソースの量を記憶部に記憶する記憶ステップと、を行い、
   前記調整ステップでは、
   前記複数のＡＰＩリクエストの各処理優先度を前記各イネーブラの数又は前記各リソースの量に応じて決定し、前記イネーブラの数又は前記リソースの量の最も小さいＡＰＩリクエストを破棄する
   ことを特徴とするＡＰＩリクエスト制御方法。

Images