(57)【要約】【課題】リクエストの処理性能を向上させる。【解決手段】システム１は、到達リクエストを受け付けるアプリケーションサーバ１０と、到達リクエストに対応するＡＰＩリクエストに基づいて任意の処理を実行するイネーブラ装置５０と、１乃至複数の仮想マシン３７が構築され、かつ、アプリケーションサーバから送信されるＡＰＩリクエストを仮想マシン毎にキューイングしてイネーブラ装置に転送するＡＰＩ提供装置３０と、各仮想マシンの残リソース量を管理するリソース管理装置４０とを有し、リソース管理装置は、各仮想マシンの残リソース量を管理するリソース管理部４１と、各仮想マシンの残リソース量に応じて、ＡＰＩ提供装置に仮想マシンの台数をスケールアウト又はスケールインさせる増減処理部４２と、イネーブラ装置の残リソース量に応じて、各仮想マシンに対して、ＡＰＩリクエストのイネーブラ装置への転送を指示する転送指示部４３とを備える。【選択図】図１
2017033234.tif 000002
【特許請求の範囲】
【請求項１】
外部装置から到達した到達リクエストを受け付け、ＡＰＩを用いて任意の処理を実行するリクエスト受付システムであって、
前記到達リクエストを受け付けるアプリケーションサーバと、
イネーブラを実装し、かつ、前記到達リクエストに対応するＡＰＩリクエストに基づいて任意の処理を実行するイネーブラ装置と、
１乃至複数の仮想マシンが構築され、かつ、前記アプリケーションサーバから送信される前記ＡＰＩリクエストを前記仮想マシン毎にキューイングして前記イネーブラ装置に転送する前記ＡＰＩ提供装置と、
前記ＡＰＩ提供装置の各仮想マシンの残リソース量を管理するリソース管理装置とを有し、
前記リソース管理装置は、
前記ＡＰＩ提供装置の各仮想マシンの残リソース量を管理するリソース管理部と、
各仮想マシンの残リソース量に応じて、前記ＡＰＩ提供装置に前記仮想マシンの台数をスケールアウト又はスケールインさせる増減処理部と、
前記イネーブラ装置の残リソース量に応じて、各仮想マシンに対して、前記ＡＰＩリクエストの前記イネーブラ装置への転送を指示する転送指示部とを備える
ことを特徴とするリクエスト受付システム。
【請求項２】
請求項１に記載のリクエスト受付システムにおいて、
前記ＡＰＩ提供装置は、１つの前記仮想マシンにつき１つが構築されるように、各仮想マシン上に構築され、かつ、前記アプリケーションサーバから受信された前記ＡＰＩリクエストを前記イネーブラ装置に提供するＡＰＩ提供部を備えるとともに、
各ＡＰＩ提供部は、前記ＡＰＩリクエストをキューイングして格納するキュー格納部と、それぞれに対応する仮想マシンの残リソース量を監視するリソース監視部とを備えている
ことを特徴とするリクエスト受付システム。
【請求項３】
請求項２に記載のリクエスト受付システムにおいて、
前記リソース管理装置の前記転送指示部又は前記リソース管理部は、前記イネーブラ装置から受信される前記イネーブラ装置の残リソース量情報に基づいて、前記イネーブラ装置の残リソース量を識別し、
前記リソース管理装置の前記転送指示部は、前記イネーブラ装置の残リソース量に応じて、命令を実行するＡＰＩ提供部を指定して、転送命令を前記ＡＰＩ提供装置に送信することにより、各仮想マシンに対して、前記ＡＰＩリクエストの前記イネーブラ装置への転送を指示する
ことを特徴とするリクエスト受付システム。
【請求項４】
外部装置から到達した到達リクエストを受け付けるアプリケーションサーバと、イネーブラを実装し、かつ、前記到達リクエストに対応するＡＰＩリクエストに基づいて任意の処理を実行するイネーブラ装置と、１乃至複数の仮想マシンが構築され、かつ、前記アプリケーションサーバから送信される前記ＡＰＩリクエストを前記仮想マシン毎にキューイングして前記イネーブラ装置に転送する前記ＡＰＩ提供装置と、前記ＡＰＩ提供装置の各仮想マシンの残リソース量を管理するリソース管理装置とを用いて、外部装置から到達した到達リクエストを受け付け、ＡＰＩを用いて任意の処理を実行するリクエスト受付方法であって、
前記リソース管理装置が、前記ＡＰＩ提供装置の各仮想マシンの残リソース量を管理するリソース管理工程と、
前記リソース管理装置が、各仮想マシンの残リソース量に応じて、前記ＡＰＩ提供装置に前記仮想マシンの台数をスケールアウト又はスケールインさせる増減処理工程と、
前記リソース管理装置が、前記イネーブラ装置の残リソース量に応じて、各仮想マシンに対して、前記ＡＰＩリクエストの前記イネーブラ装置への転送を指示する転送指示工程とを含む
ことを特徴とするリクエスト受付方法。
【請求項５】
請求項４に記載のリクエスト受付方法において、
前記ＡＰＩ提供装置は、１つの前記仮想マシンにつき１つが構築されるように、各仮想マシン上に構築され、かつ、前記アプリケーションサーバから受信された前記ＡＰＩリクエストを前記イネーブラ装置に提供するＡＰＩ提供部を備えるとともに、各ＡＰＩ提供部は、前記ＡＰＩリクエストをキューイングして格納するキュー格納部と、それぞれに対応する仮想マシンの残リソース量を監視するリソース監視部とを備えており、
前記転送指示工程は、前記リソース管理装置が、前記イネーブラ装置の残リソース量に応じて、命令を実行するＡＰＩ提供部を指定して、転送命令を前記ＡＰＩ提供装置に送信して、各仮想マシンに対して、前記キュー格納部にキューイングされた格納された前記ＡＰＩリクエストを取り出させて、前記ＡＰＩリクエストの前記イネーブラ装置に順次転送させることにより行われる
ことを特徴とするリクエスト受付方法。
【請求項６】
外部装置から到達した到達リクエストを受け付けるアプリケーションサーバと、イネーブラを実装し、かつ、前記到達リクエストに対応するＡＰＩリクエストに基づいて任意の処理を実行するイネーブラ装置と、１乃至複数の仮想マシンが構築され、かつ、前記アプリケーションサーバから送信される前記ＡＰＩリクエストを前記仮想マシン毎にキューイングして前記イネーブラ装置に転送する前記ＡＰＩ提供装置と、前記ＡＰＩ提供装置の各仮想マシンの残リソース量を管理するリソース管理装置とを有するリクエスト受付システムに用いられ、コンピュータを前記リソース管理装置として機能させるためのプログラムであって、
前記コンピュータを、
前記ＡＰＩ提供装置の各仮想マシンの残リソース量を管理するリソース管理部と、
各仮想マシンの残リソース量に応じて、前記ＡＰＩ提供装置に前記仮想マシンの台数をスケールアウト又はスケールインさせる増減処理部と、
前記イネーブラ装置の残リソース量に応じて、各仮想マシンに対して、前記ＡＰＩリクエストの前記イネーブラ装置への転送を指示する転送指示部として機能させるためのプログラム。
【請求項７】
外部装置から到達した到達リクエストを受け付けるアプリケーションサーバと、イネーブラを実装し、かつ、前記到達リクエストに対応するＡＰＩリクエストに基づいて任意の処理を実行するイネーブラ装置と、１乃至複数の仮想マシンが構築され、かつ、前記アプリケーションサーバから送信される前記ＡＰＩリクエストを前記仮想マシン毎にキューイングして前記イネーブラ装置に転送する前記ＡＰＩ提供装置と、前記ＡＰＩ提供装置の各仮想マシンの残リソース量を管理するリソース管理装置とを有するリクエスト受付システムに用いられ、コンピュータを前記ＡＰＩ提供装置として機能させるためのプログラムであって、
前記コンピュータを、１つの前記仮想マシンにつき１つが構築されるように、各仮想マシン上に構築され、かつ、前記アプリケーションサーバから受信された前記ＡＰＩリクエストを前記イネーブラ装置に提供するＡＰＩ提供部として機能させ、
さらに、前記ＡＰＩ提供部を、前記ＡＰＩリクエストをキューイングして格納するキュー格納部と、それぞれに対応する仮想マシンの残リソース量を監視するリソース監視部として機能させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、外部装置から大量のリクエストを受け付けることができるリクエスト受付システム、リクエスト受付方法、及び、プログラムに関する。
【背景技術】
【０００２】
従来、外部装置からリクエストを受け付け、ＡＰＩ（Application Programmable Interface）を用いてリクエストに基づいて任意の処理を実行して、各種機能を提供するシステム（以下、「リクエスト受付システム」と称する）がある。ここで、ＡＰＩとは、ＯＳ（Operating System）等のプラットホームに予め備えられたソフトウェア資源のことである。
【０００３】
リクエスト受付システムに関連する技術としては、例えば、特許文献１〜特許文献３に記載された技術がある。
【０００４】
特許文献１には、アプリケーションサーバとＡＰＩサーバとでＷｅｂシステム（リクエスト受付システムに相当）を構成する技術が記載されている。特許文献１に記載されたシステムは、アプリケーションサーバが、クライアント（外部装置）から受信したリクエストの認証処理又はセッション処理を行い、認証処理結果又はセッション処理結果をリクエストに付随させてＡＰＩサーバに送信するとともに、ＡＰＩサーバが、アプリケーションサーバから受信したリクエストに付随されている認証処理結果又はセッション処理結果に基づいて、受信したリクエストを処理する構成になっている。
【０００５】
特許文献２や特許文献３には、仮想マシン（仮想サーバ）の処理負荷状況に応じて、仮想マシンリソース（仮想サーバリソース）を動的に配置して、スケールアウトする技術が記載されている。ここで、スケールアウトとは、コンピュータ（ここでは、仮想マシン）を増設することにより、システムやサービス全体の処理性能を向上させることである。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特許４９０２６３３号公報
【特許文献２】特許５１１９０７７号公報
【特許文献３】特開２０１４−２０３２３２号公報
【発明の概要】
【発明が解決しようとする課題】
【０００７】
しかしながら、特許文献１〜３に記載された従来技術は、以下に説明するように、リクエストの処理性能の向上が望まれている、という課題があった。
【０００８】
一般に、リクエスト受付システムでは、大量のリクエストが特定の時間帯に一斉に到達した場合に、輻輳が発生する可能性がある。ここで、輻輳とは、大量のリクエストが特定の時間帯に集中することにより、システムが過負荷状態になり、その結果、システムに不具合が生じたり、システムの機能が停止したりすることである。
【０００９】
例えば、オリンピックやコンサート等の様々な興業のチケットの予約受付時には、多数のユーザ端末から大量の予約依頼情報がリクエストとして一斉に到達するため、輻輳（企画型輻輳）が発生する可能性がある。また、例えば、大規模停電の復旧時には、多数のスマートメータから大量のセンシング情報がリクエストとして一斉に到達するため、輻輳（災害型輻輳）が発生する可能性がある。ここで、ユーザ端末とは、システムの利用者によって操作される端末装置である。また、スマートメータとは、各家庭の電力消費量を記録し、通信回線を介して定期的に電力事業者に電力消費量情報を送信する電力量計である。
【００１０】
特許文献１に記載された従来技術は、大量のリクエストがシステムに一斉に到達した場合に、ＡＰＩサーバが過負荷状態となり、その結果、レスポンスの遅延が発生したり又は無応答状態が発生したりする可能性があった。また、この場合に、特許文献１に記載された従来技術は、リクエストの遅延の発生や無応答状態の発生に起因して、リクエストがアプリケーションサーバからＡＰＩサーバに再送されることにより、輻輳を助長してしまい、過負荷状態の悪化を招く可能性もあった。そのため、特許文献１に記載された従来技術では、大量のリクエストがシステムに一斉に到達した場合に、リクエストの遅延の発生や無応答状態の発生を回避するために、また、リクエストの再送による輻輳の助長や過負荷状態の悪化等の発生を回避するために、リクエストの処理性能を向上させることが望まれていた。
【００１１】
特許文献２や特許文献３に記載された従来技術は、サーバが外部装置からリクエストを受け付けてイネーブラ装置に送信する構成になっている。ここで、イネーブラ装置とは、イネーブラが実装された装置のことである。また、イネーブラとは、何らかの機能を有効にするためのソフトウェアである。なお、サーバからイネーブラ装置に送信されるリクエストは、ＨＴＴＰ（ＴＣＰ／ＩＰ）を用いる場合が多い。
【００１２】
特許文献２や特許文献３に記載された従来技術は、イネーブラ装置が専用ハードウェアによって構成されており、イネーブラ装置の処理能力によっては、大量のリクエストがシステムに一斉に到達した場合に、分散処理に対応できない（すなわち、スケールアウトできない）ときがあった。この場合に、特許文献２や特許文献３に記載された従来技術では、リクエストに対してイネーブラ装置が容易に応答することができず、これにより、再送タイマが満了になり、その結果、再度同じリクエストがリクエストを受け付けたサーバからイネーブラ装置に再送されてしまっていた。したがって、特許文献２や特許文献３に記載された従来技術では、再度大量の同じリクエストがイネーブラ装置に送信されることがあった。その結果、イネーブラ装置は、同じリクエストをキューイングしてしまい、重複した無駄な処理を発生させることがあった。
【００１３】
また、特許文献２や特許文献３に記載された従来技術は、イネーブラ装置での重複した無駄な処理の発生を回避するために、再送タイマの設定を長くした場合に、イネーブラ装置でキューイングされたリクエストの処理が終了してからリクエストが再送されるまでの間に、イネーブラ装置の処理待ち時間を発生させてしまう。そのため、この場合に、特許文献２や特許文献３に記載された従来技術は、システムの処理効率を悪化させていた。
【００１４】
このような特許文献２や特許文献３に記載された従来技術では、大量のリクエストがシステムに一斉に到達した場合に、分散処理に対応できないイネーブラ装置を考慮した効率的な処理を行うことができるように、リクエストの処理性能を向上させることが望まれていた。
【００１５】
本発明は、前記した課題を解決するためになされたものであり、リクエストの処理性能を向上させたリクエスト受付システム、リクエスト受付方法、及び、プログラムを提供することを主な課題とする。
【課題を解決するための手段】
【００１６】
前記課題を解決するため、第１発明は、外部装置から到達した到達リクエストを受け付け、ＡＰＩを用いて任意の処理を実行するリクエスト受付システムであって、前記到達リクエストを受け付けるアプリケーションサーバと、イネーブラを実装し、かつ、前記到達リクエストに対応するＡＰＩリクエストに基づいて任意の処理を実行するイネーブラ装置と、１乃至複数の仮想マシンが構築され、かつ、前記アプリケーションサーバから送信される前記ＡＰＩリクエストを前記仮想マシン毎にキューイングして前記イネーブラ装置に転送する前記ＡＰＩ提供装置と、前記ＡＰＩ提供装置の各仮想マシンの残リソース量を管理するリソース管理装置とを有し、前記リソース管理装置は、前記ＡＰＩ提供装置の各仮想マシンの残リソース量を管理するリソース管理部と、各仮想マシンの残リソース量に応じて、前記ＡＰＩ提供装置に前記仮想マシンの台数をスケールアウト又はスケールインさせる増減処理部と、前記イネーブラ装置の残リソース量に応じて、各仮想マシンに対して、前記ＡＰＩリクエストの前記イネーブラ装置への転送を指示する転送指示部とを備える構成とする。
【００１７】
このリクエスト受付システムは、各仮想マシンの残リソース量に応じて、ＡＰＩ提供装置に構築された仮想マシンの台数をスケールアウト又はスケールインさせるとともに、イネーブラ装置の残リソース量に応じて、各仮想マシンに対して、ＡＰＩリクエストのイネーブラ装置への転送を行わせることができる。このリクエスト受付システムは、大量のリクエストが特定の時間帯にシステムに一斉に到達した場合であっても、そのことに起因する輻輳の発生を回避することができる。そのため、このリクエスト受付システムは、リクエストの処理性能を向上させることができる。
【００１８】
このリクエスト受付システムにおいて、前記ＡＰＩ提供装置は、１つの前記仮想マシンにつき１つが構築されるように、各仮想マシン上に構築され、かつ、前記アプリケーションサーバから受信された前記ＡＰＩリクエストを前記イネーブラ装置に提供するＡＰＩ提供部を備えるとともに、各ＡＰＩ提供部は、前記ＡＰＩリクエストをキューイングして格納するキュー格納部と、それぞれに対応する仮想マシンの残リソース量を監視するリソース監視部とを備えている構成にしてもよい。
【００１９】
この構成に係るリクエスト受付システムは、ＡＰＩ提供部を仮想マシン上に構築し、各ＡＰＩ提供部単位で、各ＡＰＩリクエストの転送処理と各仮想マシンの残リソース量の監視処理とを行うことができる。そのため、この構成に係るリクエスト受付システムは、各ＡＰＩ提供部（仮想マシンを含む）の残リソース量を容易に監視することができる。これにより、この構成に係るリクエスト受付システムは、各ＡＰＩ提供部（仮想マシンを含む）の残リソース量（例えば、ＡＰＩリクエスト数やＡＰＩ提供装置の処理負荷状況）に応じて、仮想マシンの台数を動的にスケールアウト又はスケールインさせることができる。そのため、この構成によれば、リクエストの処理性能を向上させることができ、その結果、大量のリクエストを一斉に受け付けることができる。
【００２０】
さらに、この構成に係るリクエスト受付システムにおいて、前記リソース管理装置の前記転送指示部又は前記リソース管理部は、前記イネーブラ装置から受信される前記イネーブラ装置の残リソース量情報に基づいて、前記イネーブラ装置の残リソース量を識別し、前記リソース管理装置の前記転送指示部は、前記イネーブラ装置の残リソース量に応じて、命令を実行するＡＰＩ提供部を指定して、転送命令を前記ＡＰＩ提供装置に送信することにより、各仮想マシンに対して、前記ＡＰＩリクエストの前記イネーブラ装置への転送を指示する構成にしてもよい。
【００２１】
この構成によれば、リソース管理装置の転送指示部が、イネーブラ装置の残リソース量に応じて、命令を実行するＡＰＩ提供部を指定して、転送命令をＡＰＩ提供装置に送信することにより、各仮想マシンに対して、ＡＰＩリクエストのイネーブラ装置への転送を指示することができる。
【００２２】
また、第２発明は、外部装置から到達した到達リクエストを受け付けるアプリケーションサーバと、イネーブラを実装し、かつ、前記到達リクエストに対応するＡＰＩリクエストに基づいて任意の処理を実行するイネーブラ装置と、１乃至複数の仮想マシンが構築され、かつ、前記アプリケーションサーバから送信される前記ＡＰＩリクエストを前記仮想マシン毎にキューイングして前記イネーブラ装置に転送する前記ＡＰＩ提供装置と、前記ＡＰＩ提供装置の各仮想マシンの残リソース量を管理するリソース管理装置とを用いて、外部装置から到達した到達リクエストを受け付け、ＡＰＩを用いて任意の処理を実行するリクエスト受付方法であって、前記リソース管理装置が、前記ＡＰＩ提供装置の各仮想マシンの残リソース量を管理するリソース管理工程と、前記リソース管理装置が、各仮想マシンの残リソース量に応じて、前記ＡＰＩ提供装置に前記仮想マシンの台数をスケールアウト又はスケールインさせる増減処理工程と、前記リソース管理装置が、前記イネーブラ装置の残リソース量に応じて、各仮想マシンに対して、前記ＡＰＩリクエストの前記イネーブラ装置への転送を指示する転送指示工程とを含む構成とする。
【００２３】
このリクエスト受付方法は、各仮想マシンの残リソース量に応じて、ＡＰＩ提供装置に構築された仮想マシンの台数をスケールアウト又はスケールインさせるとともに、イネーブラ装置の残リソース量に応じて、各仮想マシンに対して、ＡＰＩリクエストのイネーブラ装置への転送を行わせることができる。このリクエスト受付方法は、大量のリクエストが特定の時間帯にシステムに一斉に到達することに起因する輻輳の発生を回避することができるため、リクエストの処理性能を向上させることができる。
【００２４】
このリクエスト受付システムにおいて、前記ＡＰＩ提供装置は、１つの前記仮想マシンにつき１つが構築されるように、各仮想マシン上に構築され、かつ、前記アプリケーションサーバから受信された前記ＡＰＩリクエストを前記イネーブラ装置に提供するＡＰＩ提供部を備えるとともに、各ＡＰＩ提供部は、前記ＡＰＩリクエストをキューイングして格納するキュー格納部と、それぞれに対応する仮想マシンの残リソース量を監視するリソース監視部とを備えており、前記転送指示工程は、前記リソース管理装置が、前記イネーブラ装置の残リソース量に応じて、命令を実行するＡＰＩ提供部を指定して、転送命令を前記ＡＰＩ提供装置に送信して、各仮想マシンに対して、前記キュー格納部にキューイングされた格納された前記ＡＰＩリクエストを取り出させて、前記ＡＰＩリクエストの前記イネーブラ装置に順次転送させることにより行われる構成にしてもよい。
【００２５】
この構成によれば、リソース管理装置の転送指示部が、イネーブラ装置の残リソース量に応じて、命令を実行するＡＰＩ提供部を指定して、転送命令をＡＰＩ提供装置に送信することにより、各仮想マシンに対して、ＡＰＩリクエストのイネーブラ装置への転送を指示することができる。
【００２６】
また、第３発明は、外部装置から到達した到達リクエストを受け付けるアプリケーションサーバと、イネーブラを実装し、かつ、前記到達リクエストに対応するＡＰＩリクエストに基づいて任意の処理を実行するイネーブラ装置と、１乃至複数の仮想マシンが構築され、かつ、前記アプリケーションサーバから送信される前記ＡＰＩリクエストを前記仮想マシン毎にキューイングして前記イネーブラ装置に転送する前記ＡＰＩ提供装置と、前記ＡＰＩ提供装置の各仮想マシンの残リソース量を管理するリソース管理装置とを有するリクエスト受付システムに用いられ、コンピュータを前記リソース管理装置として機能させるためのプログラムであって、前記コンピュータを、前記ＡＰＩ提供装置の各仮想マシンの残リソース量を管理するリソース管理部と、各仮想マシンの残リソース量に応じて、前記ＡＰＩ提供装置に前記仮想マシンの台数をスケールアウト又はスケールインさせる増減処理部と、前記イネーブラ装置の残リソース量に応じて、各仮想マシンに対して、前記ＡＰＩリクエストの前記イネーブラ装置への転送を指示する転送指示部として機能させる構成とする。
【００２７】
この構成によれば、コンピュータで、第１発明に係るリクエスト受付システムに用いるリソース管理部を実現することができる。
【００２８】
また、第４発明は、外部装置から到達した到達リクエストを受け付けるアプリケーションサーバと、イネーブラを実装し、かつ、前記到達リクエストに対応するＡＰＩリクエストに基づいて任意の処理を実行するイネーブラ装置と、１乃至複数の仮想マシンが構築され、かつ、前記アプリケーションサーバから送信される前記ＡＰＩリクエストを前記仮想マシン毎にキューイングして前記イネーブラ装置に転送する前記ＡＰＩ提供装置と、前記ＡＰＩ提供装置の各仮想マシンの残リソース量を管理するリソース管理装置とを有するリクエスト受付システムに用いられ、コンピュータを前記ＡＰＩ提供装置として機能させるためのプログラムであって、前記コンピュータを、１つの前記仮想マシンにつき１つが構築されるように、各仮想マシン上に構築され、かつ、前記アプリケーションサーバから受信された前記ＡＰＩリクエストを前記イネーブラ装置に提供するＡＰＩ提供部として機能させ、さらに、前記ＡＰＩ提供部を、前記ＡＰＩリクエストをキューイングして格納するキュー格納部と、それぞれに対応する仮想マシンの残リソース量を監視するリソース監視部として機能させる構成とする。
【００２９】
この構成によれば、コンピュータで、第１発明に係るリクエスト受付システムに用いるＡＰＩ提供装置を実現することができる。
【発明の効果】
【００３０】
本発明によれば、リクエストの処理性能を向上させることができる。
【図面の簡単な説明】
【００３１】
【図１】実施形態に係るリクエスト受付システムの構成を示す図である。
【図２Ａ】実施形態に係るリクエスト受付システムの全体の動作を示すフローチャート（１）である。
【図２Ｂ】実施形態に係るリクエスト受付システムの全体の動作を示すフローチャート（２）である。
【図３】実施形態に係るリクエスト受付システムの全体の動作を示す図である。
【図４】実施形態に係るリクエスト受付システムのリソース管理装置の動作を示すフローチャートである。
【発明を実施するための形態】
【００３２】
以下、図面を参照して、本発明の実施の形態（以下、「本実施形態」と称する）について詳細に説明する。なお、各図は、本発明を十分に理解できる程度に、概略的に示してあるに過ぎない。よって、本発明は、図示例のみに限定されるものではない。また、各図において、共通する構成要素や同様な構成要素については、同一の符号を付し、それらの重複する説明を省略する。
【００３３】
［実施形態］
本実施形態に係るリクエスト受付システム１は、外部装置からリクエストを受け付け、ＡＰＩ（Application Programmable Interface）を用いてリクエストに基づいて任意の処理を実行して、各種機能を提供するシステムである。
【００３４】
＜リクエスト受付システムの構成＞
以下、図１を参照して、本実施形態に係るリクエスト受付システム１の構成について説明する。図１は、リクエスト受付システム１の構成を示す図である。
【００３５】
図１に示すように、本実施形態に係るリクエスト受付システム１は、アプリケーションサーバ１０、ロードバランサ２０、ＡＰＩ提供装置３０、リソース管理装置４０、及び、イネーブラ装置５０を有している。ただし、ロードバランサ２０は、後記するＡＰＩリクエストをＡＰＩ提供装置３０に構築された後記する各ＡＰＩ提供部３１（後記する仮想マシン３７を含む）に振り分けることが可能な装置であれば、他の装置（例えば、ＤＮＳ（Domain Name System）サーバ等）に置き換えることができる。
【００３６】
アプリケーションサーバ１０は、ユーザ端末３やスマートメータ４等の外部装置２から送信されたリクエストを受け付けるサーバである。アプリケーションサーバ１０は、公衆回線網６を介して多数の外部装置２と通信可能に接続される。ここで、ユーザ端末３とは、システムの利用者によって操作される端末装置である。また、スマートメータ４とは、各家庭の電力消費量を記録し、通信回線を介して定期的に電力事業者に電力消費量情報を送信する電力量計である。ユーザ端末３は、例えば、リクエスト受付システム１からＷｅｂ画面の提供を受けて、Ｗｅｂ画面で入力された情報をリクエストとしてアプリケーションサーバ１０に送信する。一方、スマートメータ４は、例えば、図示せぬセンサ等で検知されたセンシング情報をリクエストとしてアプリケーションサーバ１０に送信する。アプリケーションサーバ１０は、これらの外部装置２からユーザ情報やパスワード情報、リクエスト等を受信する。
【００３７】
アプリケーションサーバ１０は、リクエスト（以下、「到達リクエスト」と称する場合がある）を受信すると、到達リクエストに対応するＡＰＩリクエストをＡＰＩ提供装置３０に送信する。ＡＰＩリクエストは、ＡＰＩを利用することが可能な形式になっているリクエスト情報である。アプリケーションサーバ１０は、到達リクエストの形式がＡＰＩリクエストとは異なる形式になっている場合に、到達リクエストに基づいてＡＰＩリクエストを生成する。ただし、到達リクエストの形式がＡＰＩリクエストと同じ形式になっている場合もある。
【００３８】
ロードバランサ２０は、アプリケーションサーバ１０から送信されたＡＰＩリクエストをＡＰＩ提供装置３０に構築された後記する各ＡＰＩ提供部３１（仮想マシン３７）に振り分ける装置である。リクエスト受付システム１は、ロードバランサ２０でＡＰＩリクエストを各ＡＰＩ提供部３１（仮想マシン３７）に振り分けることによって、各ＡＰＩ提供部３１（仮想マシン３７）に負荷を分散させることができ、その結果、外部装置２からのリクエストに対する処理の遅延を防ぐことができる。
【００３９】
ＡＰＩ提供装置３０は、アプリケーションサーバ１０から送信されたＡＰＩリクエストを後記するＡＰＩ提供部３１（仮想マシン３７）毎にキューイングしてイネーブラ装置５０に提供（転送）する装置である。
【００４０】
リソース管理装置４０は、ＡＰＩ提供装置３０に構築された後記する各仮想マシン３７の残リソース量（処理負荷状況）を管理するとともに、後記する仮想マシン３７のリソースを確保し、確保された仮想マシン３７上にＡＰＩ提供部３１を増設する処理や、ＡＰＩ提供部３１（仮想マシン３７を含む）を減設する処理を行う装置である。
【００４１】
イネーブラ装置５０は、何らかの機能を有効にするためのソフトウェアであるイネーブラが実装され、ＡＰＩを用いて任意の処理を実行して、外部装置に各種機能を提供する装置である。
【００４２】
アプリケーションサーバ１０は、アプリケーション処理部１１、リクエスト処理部１５、レスポンス処理部１６、及び、通信部１９を備えている。これらの各構成要素は、アプリケーションサーバ１０の図示せぬＣＰＵが図示せぬ記憶部に予め格納された制御プログラムＰＲ１０を実行することによって構築される。
【００４３】
アプリケーション処理部１１は、任意の機能を有するアプリケーションプログラムを実行する機能手段である。アプリケーション処理部１１は、例えば、到達リクエストの形式がＡＰＩリクエストとは異なる形式になっている場合に、到達リクエストに基づいてＡＰＩリクエストを生成する。
リクエスト処理部１５は、到達リクエストやＡＰＩリクエストの入出力処理を実行する機能手段である。例えば、リクエスト処理部１５は、到達リクエストをアプリケーション処理部１１に出力したり、到達リクエストに対応するＡＰＩリクエストの後続の装置（ここでは、ロードバランサ２０）への送信を制御したりする。
【００４４】
レスポンス処理部１６は、イネーブラ装置５０によって生成されたＡＰＩレスポンスの入出力処理を実行する機能手段である。例えば、レスポンス処理部１６は、ＡＰＩレスポンスをアプリケーション処理部１１に出力したり、ＡＰＩレスポンスの到達リクエストの送信元の外部装置２への送信を制御したりする。
通信部１９は、通信を実行する機能手段である。
【００４５】
ロードバランサ２０は、振分ルール情報Ｄ２０を格納部に予め格納している。振分ルール情報Ｄ２０は、アプリケーションサーバ１０から送信されるＡＰＩリクエストを、ＡＰＩ提供装置３０に構築された各ＡＰＩ提供部３１に振り分けて送信する振分ルールを規定する情報である。
【００４６】
リクエスト受付システム１は、例えば、ＡＰＩリクエストの振分の実現方法がロードバランサ２０を用いる方法である場合に、ロードバランサ２０に振分ルール情報Ｄ２０を保持する。そして、リクエスト受付システム１は、仮想マシン３７が増設される場合に、仮想マシン３７（ＡＰＩ提供部３１）にＩＰアドレスを割り振り、ロードバランサ２０にエントリされている振分ルール情報Ｄ２０のＩＰアドレスプールに、増設した仮想マシン３７のＩＰアドレスを追加登録する。
【００４７】
また、リクエスト受付システム１は、仮想マシン３７が減設されて、減設により仮想マシン３７のリソースが開放される場合に、ロードバランサ２０にエントリされている振分ルール情報Ｄ２０のＩＰアドレスプールから、減設される仮想マシン３７のＩＰアドレスを削除する。
【００４８】
このようなロードバランサ２０の動作は、ロードバランサ２０の図示せぬＣＰＵが図示せぬ記憶部に格納された制御プログラムＰＲ２０を実行することによって実現される。
【００４９】
ただし、ＡＰＩリクエストの振分の実現方法は、複数存在しており、既存の技術を用いることができる。例えば、ＡＰＩリクエストの振分の実現方法としては、ロードバランサ２０でＡＰＩリクエストを各ＡＰＩ提供部３１に振り分ける方法以外に、ＤＮＳのラウンドロビンを基にＡＰＩリクエストを振り分ける方法等がある。なお、振分ルール情報Ｄ２０が登録される場所は、ＡＰＩリクエストの振分の実現方法によって異なることにより、複数箇所想定することができる。
【００５０】
ＡＰＩ提供装置３０は、ＡＰＩ提供部３１、ハイパーバイザ３８、及び、通信部３９を備えている。これらの各構成要素は、ＡＰＩ提供装置３０の図示せぬＣＰＵが図示せぬ記憶部に予め格納された制御プログラムＰＲ３０を実行することによって構築される。
【００５１】
ＡＰＩ提供部３１は、アプリケーションサーバ１０から受信されたＡＰＩリクエストをイネーブラ装置５０に提供（転送）する機能手段である。ＡＰＩ提供装置３０は、１乃至複数のＡＰＩ提供部３１を備えている。例えば、図１に示す例では、ＡＰＩ提供装置３０は、２つのＡＰＩ提供部３１ａ，３１ｂを備えている。ＡＰＩ提供部３１ａ，３１ｂは、同じ構成になっている。ＡＰＩ提供部３１は、１つの仮想マシン３７につき１つが構築されるように、各仮想マシン３７上に構築されている。すなわち、ＡＰＩ提供部３１は、１つにつき１つの仮想マシン３７を含む構成になっている。
【００５２】
ハイパーバイザ３８は、仮想マシン３７を実現するためのソフトウェアを実行する機能手段である。ハイパーバイザ３８は、ＯＳよりも上位のレベルで動作し、特定のＯＳを必要とせずに動作する。ハイパーバイザ３８は、ハードウェア構成を再現（エミュレート）することにより複数のＯＳを制御し、１台の装置上に複数の仮想マシン３７を構築することができる。
通信部３９は、通信を実行する機能手段である。
【００５３】
ＡＰＩ提供部３１は、ＡＰＩ処理部３２、キュー格納部３３、リソース監視部３４、リクエスト転送部３５、レスポンス転送部３６、及び、仮想マシン３７を備えている。
【００５４】
ＡＰＩ処理部３２は、アプリケーションサーバ１０から送信されるＡＰＩリクエストに対して、例えば、ＡＰＩリクエストに対して、認証やＩＦ（Intermediate Frequency）変換、Ｐｒｏｘｙ等の処理を行う機能手段である。
キュー格納部３３は、アプリケーションサーバ１０から送信されるＡＰＩリクエストをキューイングして格納する格納手段である。
リソース監視部３４は、仮想マシン３７の残リソース量（処理負荷状況）を監視する機能手段である。
【００５５】
リクエスト転送部３５は、アプリケーションサーバ１０から送信されるＡＰＩリクエストをイネーブラ装置５０に転送する機能手段である。
レスポンス転送部３６は、イネーブラ装置５０によって生成されたＡＰＩレスポンスをアプリケーションサーバ１０に転送する機能手段である。
仮想マシン３７は、キュー格納部３３に格納されたＡＰＩリクエストＤ３３のイネーブラ装置５０への転送を制御する機能手段である。
【００５６】
リソース管理装置４０は、リソース管理部４１、増減処理部４２、転送指示部４３、及び、通信部４９を備えている。これらの各構成要素は、リソース管理装置４０の図示せぬＣＰＵが図示せぬ記憶部に予め格納された制御プログラムＰＲ４０を実行することによって構築される。
【００５７】
リソース管理部４１は、ＡＰＩ提供装置３０の各仮想マシン３７の残リソース量（処理負荷状況）を管理する機能手段である。
増減処理部４２は、各仮想マシン３７の残リソース量に応じて、ＡＰＩ提供装置３０に仮想マシン３７の台数をスケールアウト又はスケールインさせる機能手段である。増減処理部４２には、ＡＰＩ提供部３１（仮想マシン３７を含む）の増設用プログラムＰＲ４２ａや減設用プログラムＰＲ４２ｂが格納されている。
【００５８】
転送指示部４３は、イネーブラ装置５０の残リソース量に応じて、各仮想マシン３７に対して、ＡＰＩリクエストのイネーブラ装置５０への転送を指示する機能手段である。
通信部４９は、通信を実行する機能手段である。
【００５９】
なお、増設用プログラムＰＲ４２ａによってＡＰＩ提供部３１（仮想マシン３７を含む）を増設する目的は、ＡＰＩ提供装置３０のＡＰＩ提供部３１（仮想マシン３７を含む）をスケールアウトすることで、アプリケーションサーバ１０からＡＰＩ提供装置３０への大量のＡＰＩリクエストの送信を可能にするため、及び、イネーブラ装置５０が分散処理できず（スケールアウトできず）、大量のＡＰＩリクエストによってイネーブラ装置５０が過負荷状態になりそうな場合に、輻輳の悪化を回避するためである。
【００６０】
一方、減設用プログラムＰＲ４２ｂによってＡＰＩ提供部３１（仮想マシン３７を含む）を減設する目的は、例えば、複数のイネーブラ装置５０が存在していて、ＡＰＩ提供部３１（仮想マシン３７を含む）の処理量に応じて各仮想マシン３７を複数のイネーブラ装置５０のいずれかに対応付けさせることによって、ＡＰＩ提供装置３０のリソースの使用効率を向上させるためである。また、ＡＰＩ提供装置３０の負荷が低い場合に、減設して、捻出されたＡＰＩ提供装置３０の下位ＰＦ（物理マシン、ハイパーバイザ３８、仮想マシン３７等）を、別の用途に流用するためでもある。
【００６１】
イネーブラ装置５０は、機能実行部５１、リソース監視部５４、リクエスト処理部５５、レスポンス処理部５６、及び、通信部５９を備えている。これらの各構成要素は、イネーブラ装置５０の図示せぬＣＰＵが図示せぬ記憶部に予め格納された制御プログラムＰＲ５０を実行することによって構築される。
【００６２】
機能実行部５１は、ＡＰＩリクエストに基づいて任意の処理を実行して、各種機能を実行する機能手段である。
リソース監視部５４は、イネーブラ装置５０の残リソース量（イネーブラ装置５０の機能実行部５１の処理負荷状況）を監視する機能手段である。
リクエスト処理部５５は、ＡＰＩ提供装置３０から転送されたＡＰＩリクエストの入出力処理を実行する機能手段である。リクエスト処理部５５は、例えば、ＡＰＩリクエストを機能実行部５１に出力する。
レスポンス処理部５６は、機能実行部５１によって生成されたＡＰＩレスポンスの入出力処理を実行する機能手段である。レスポンス処理部５６は、ＡＰＩレスポンスのＡＰＩリクエストの転送元のＡＰＩ提供部３１（仮想マシン３７）への送信を制御する。
通信部５９は、通信を実行する機能手段である。
【００６３】
＜リクエスト受付システムの動作＞
以下、図２Ａ、図２Ｂ、図３、及び、図４を参照して、リクエスト受付システム１の動作について説明する。図２Ａ及び図２Ｂは、それぞれ、リクエスト受付システム１の全体の動作を示すフローチャートである。図３は、リクエスト受付システム１の全体の動作を示す図である。図４は、リクエスト受付システム１のリソース管理装置４０の動作を示すフローチャートである。
【００６４】
なお、各装置は、図示せぬタイマによって計測された時間に基づいて動作する。また、各装置の動作は、各装置の記憶部に読み出し自在に予め格納されたプログラムによって規定されており、各装置のＣＰＵによって実行される。また、装置間の通信は、各装置の通信部によって実行される。また、装置間の通信は、受信側の装置が通信によって受信されたデータを記憶部に一旦格納し、その後に、データを記憶部から読み出すことによって、行われる。また、各データは、記憶部に読み出し自在に一旦格納されてから、その後の処理を行う所要の構成要素に出力される。以下、これらの点については、情報処理では常套手段であるので、その詳細な説明を省略する。
【００６５】
（リクエスト受付システムの全体の動作）
まず、図２Ａ、図２Ｂ、及び、図３を参照して、リクエスト受付システム１の全体の動作について説明する。
【００６６】
例えば、各外部装置２（図１参照）は、任意のタイミングでリクエストをリクエスト受付システム１に送信する。ここでは、多数の外部装置２が特定の時間帯にリクエストをリクエスト受付システム１に一斉に送信した場合を想定して説明する。これにより、大量のリクエストが到達リクエストとしてリクエスト受付システム１に一斉に到達する。リクエスト受付システム１には、複数のアプリケーションサーバ１０が配置されている。
【００６７】
図２Ａ及び図３に示すように、各アプリケーションサーバ１０は、大量の到達リクエストを順次受信して受け付け（ステップＳＴ１ａ）、受け付けられた到達リクエストに対応するＡＰＩリクエストをＡＰＩ提供装置３０に送信する（ステップＳＴ１ｂ）。このとき、大量のＡＰＩリクエストが各アプリケーションサーバ１０からＡＰＩ提供装置３０に一斉に送信される。
【００６８】
ＡＰＩ提供装置３０には、１乃至複数の仮想マシン３７が構築されている。仮想マシン３７は、任意に増設したり減設したりすることができる構成になっている。そして、仮想マシン３７上には、１つの仮想マシン３７につき１つのＡＰＩ提供部３１が構築されている。各ＡＰＩ提供部３１は、各仮想マシン３７に対応するキュー格納部３３及びリソース監視部３４を備えている。
【００６９】
リクエスト受付システム１は、予め定められた任意の振分方法により、ＡＰＩリクエストを各ＡＰＩ提供部３１に振り分ける。振分方法は、例えば、ロードバランサ２０等により、振分ルール情報Ｄ２０に基づいてＡＰＩリクエストを各ＡＰＩ提供部３１に振り分ける方法であってもよいし、又は、ＤＮＳサーバ等により、ＩＰアドレスに基づいてＡＰＩリクエストを各ＡＰＩ提供部３１に振り分ける方法であってもよい。
【００７０】
ＡＰＩ提供装置３０は、ＡＰＩリクエストを受信すると、受信されたＡＰＩリクエストを各ＡＰＩ提供部３１に振り分ける。各ＡＰＩ提供部３１は、振り分けられたＡＰＩリクエストをキューイングして自身の持つキュー格納部３３に格納する（ステップＳＴ２）。
【００７１】
リソース管理装置４０は、任意のタイミングで、ＡＰＩ提供装置３０に対して、各ＡＰＩ提供部３１のキュー残容量情報の通知（送信）を要求する（ステップＳＴ３ａ）。
【００７２】
ここで、キュー残容量情報とは、キュー格納部３３の残りの容量を表す情報である。各キュー格納部３３のキュー残容量や各キュー格納部３３に残っているＡＰＩリクエストＤ３３の数等は、各キュー格納部３３に対応するリソース監視部３４によって監視されている。
【００７３】
ＡＰＩ提供装置３０は、リソース管理装置４０から各ＡＰＩ提供部３１のキュー残容量情報の通知要求を受信すると、各ＡＰＩ提供部３１のキュー残容量情報（ただし、ＡＰＩ提供装置３０の残メモリ容量情報やＣＰＵ負荷情報であっても良い）を、リソース管理装置４０に通知（送信）する（ステップＳＴ３ｂ）。
【００７４】
リソース管理装置４０は、ＡＰＩ提供装置３０から各ＡＰＩ提供部３１のキュー残容量情報を受信すると、各ＡＰＩ提供部３１のキュー残容量情報から各ＡＰＩ提供部３１の残リソース量を識別し、残リソース量が少ないＡＰＩ提供部３１があるか否かを（具体的には、残リソース量が予め定められた第１閾値以下のＡＰＩ提供部３１があるか否かを）判定する（ステップＳＴ４ａ）。ここで、残リソース量とは、利用可能なリソース量のことであり、処理負荷状況を表している。
【００７５】
残リソース量が少ないＡＰＩ提供部３１があると判定された場合に、リソース管理装置４０は、仮想マシン３７のリソースを確保し、確保された仮想マシン３７上にＡＰＩ提供部３１を増設する（ステップＳＴ４ｂ）。図３中、破線部分は、増設されたＡＰＩ提供部３１（確保された仮想マシン３７を含む）を示している。
【００７６】
この場合に、リソース管理装置４０は、リクエスト受付システム１で採用されているＡＰＩリクエストの振分方法に応じて、増設したＡＰＩ提供部３１に関する情報（以下、「増設情報」と称する）を新たな振分先情報として振分ルール情報Ｄ２０（図１参照）に追加登録する（ステップＳＴ４ｃ）。ここでは、リソース管理装置４０がロードバランサ２０（図１参照）に増設情報を送信し、これに応答してロードバランサ２０が増設情報を振分ルール情報Ｄ２０（図１参照）に追加登録する場合を想定して説明する。
【００７７】
ステップＳＴ４ｃの後、処理は、図２Ａ中の符号「Ａ」を介して、図２ＢのステップＳＴ５ａに進む。すなわち、ステップＳＴ４ｃの後、リソース管理装置４０は、イネーブラ装置５０に対して、イネーブラ装置５０の残リソース情報の通知（送信）を要求する（ステップＳＴ５ａ）。ただし、通知要求動作は、このタイミングに限らず、いつ実施しても良い。
【００７８】
イネーブラ装置５０は、リソース管理装置４０からイネーブラ装置５０の残リソース情報の通知要求を受信すると、イネーブラ装置５０の残リソース情報をリソース管理装置４０に通知（送信）する（ステップＳＴ５ｂ）。
【００７９】
リソース管理装置４０は、イネーブラ装置５０からイネーブラ装置５０の残リソース情報を受信すると、イネーブラ装置５０の残リソース情報からイネーブラ装置５０の処理負荷状況を識別し、イネーブラ装置５０の処理負荷に余裕があるか否かを（具体的には、イネーブラ装置５０の残リソース量が予め定められた閾値を超えているか否かを）判定する（ステップＳＴ６ａ）。
【００８０】
イネーブラ装置５０の処理負荷に余裕がある（イネーブラ装置５０の残リソース量が予め定められた閾値を超えている）と判定された場合に、リソース管理装置４０は、例えば、ラウンドロビン等の分散手段を用いて命令を実行させるＡＰＩ提供部３１を指定して、ＡＰＩリクエストの転送命令をＡＰＩ提供装置３０に送信する（ステップＳＴ６ｂ）。ステップＳＴ６ｂの処理は、イネーブラ装置５０の残リソース量に応じて、ＡＰＩ提供装置３０の各ＡＰＩ提供部３１（各仮想マシン３７を含む）に対して、ＡＰＩリクエストのイネーブラ装置５０への転送を指示する転送指示工程に相当する。
【００８１】
ＡＰＩ提供装置３０は、リソース管理装置４０からＡＰＩリクエストの転送命令を受信すると、ＡＰＩリクエストの転送命令を指定されたＡＰＩ提供部３１に振り分ける。すると、指定されたＡＰＩ提供部３１が、ＦＩＦＯ（First In， First Out）等の順序制御を用いてキュー格納部３３からＡＰＩリクエストを取り出して、イネーブラ装置５０に転送する（ステップＳＴ７ａ）。
【００８２】
イネーブラ装置５０は、ＡＰＩ提供装置３０からＡＰＩリクエストを受信すると、受信されたＡＰＩリクエストに基づいて処理を実行し（ステップＳＴ７ｂ）、処理の実行結果であるＡＰＩレスポンスをＡＰＩ提供装置３０に送信する（ステップＳＴ７ｃ）。
【００８３】
ＡＰＩ提供装置３０は、イネーブラ装置５０からＡＰＩレスポンスを受信すると、受信されたＡＰＩレスポンスをＡＰＩリクエストの送信元のＡＰＩ提供部３１に振り分ける。すると、各ＡＰＩ提供部３１は、振り分けられたＡＰＩレスポンスをＡＰＩリクエストの受付元のアプリケーションサーバ１０に転送する（ステップＳＴ８ａ）。アプリケーションサーバ１０は、ＡＰＩレスポンスを受信すると、ＡＰＩレスポンスを到達リクエストの送信元の外部装置２に送信する（ステップＳＴ８ｂ）。
リクエスト受付システム１の全体の動作は、以上の通りである。
【００８４】
（リソース管理装置の動作）
次に、図４を参照して、リソース管理装置４０の動作について説明する。図４に示すリソース管理装置４０の動作は、図２ＡのステップＳＴ３ａ〜図２ＢのステップＳＴ６ｂの処理の動作を示している。
【００８５】
図４に示すように、リソース管理装置４０のリソース管理部４１は、通信部４９を介して、ＡＰＩ提供装置３０から、各ＡＰＩ提供部３１のキュー残容量情報を受信する（ステップＳ１００）。
【００８６】
ステップＳ１００の処理は、例えば、以下のようにして行われる。
ＡＰＩ提供装置３０の各ＡＰＩ提供部３１のリソース監視部３４は、キュー格納部３３のキュー残容量や各キュー格納部３３に残っているＡＰＩリクエストＤ３３の数等を常時監視している。リソース管理装置４０のリソース管理部４１は、任意のタイミングで、ＡＰＩ提供装置３０に対して、各ＡＰＩ提供部３１のキュー残容量情報の通知を要求（送信）する。これに応答して、ＡＰＩ提供装置３０の各ＡＰＩ提供部３１のリソース監視部３４は、各ＡＰＩ提供部３１のキュー残容量情報をリソース管理装置４０に送信（送信）する。これにより、リソース管理装置４０は、ＡＰＩ提供装置３０から、各ＡＰＩ提供部３１のキュー残容量情報を受信する。
このようにして、ステップＳ１００の処理が行われる。ステップＳ１００の処理は、図２ＡのステップＳＴ３ａ，ＳＴ３ｂの処理に該当する。
【００８７】
リソース管理装置４０のリソース管理部４１は、ＡＰＩ提供装置３０から各ＡＰＩ提供部３１のキュー残容量情報を受信すると、各ＡＰＩ提供部３１のキュー残容量情報から各ＡＰＩ提供部３１の残リソース量を識別する（ステップＳ１０５）。そして、リソース管理装置４０のリソース管理部４１は、残リソース量が予め定められた第１閾値以下のＡＰＩ提供部３１があるか否かを（すなわち、残リソース量が少ないＡＰＩ提供部３１があるか否かを）判定する（ステップＳ１１０）。ステップＳ１０５，Ｓ１１０の処理は、図２ＡのステップＳＴ４ａの処理に該当する。これらの処理は、リソース管理装置４０がＡＰＩ提供装置３０の各ＡＰＩ提供部３１（各仮想マシン３７を含む）の残リソース量を管理するリソース管理工程に相当する。
【００８８】
ステップＳ１１０の判定で、残リソース量が第１閾値以下のＡＰＩ提供部３１がある（すなわち、残リソース量が少ないＡＰＩ提供部３１がある）と判定された場合（“Ｙｅｓ”の場合）に、リソース管理装置４０の増減処理部４２は、ＡＰＩ提供装置３０に仮想マシン３７のリソースを確保し（ステップＳ１１５）、確保された仮想マシン３７上にＡＰＩ提供部３１を増設する（ステップＳ１２０）。ステップＳ１１５，Ｓ１２０の処理は、増減処理部４２が増設用プログラムＰＲ４２ａを実行することによって行われる。ステップＳ１１５，Ｓ１２０の処理は、図２ＡのステップＳＴ４ｂの処理に該当する。これらの処理は、各ＡＰＩ提供部３１（各仮想マシン３７を含む）の残リソース量に応じて、ＡＰＩ提供装置３０に各ＡＰＩ提供部３１（各仮想マシン３７を含む）の台数をスケールアウトさせる場合の増減処理工程に相当する。
【００８９】
ステップＳ１２０の後、リソース管理装置４０の増減処理部４２は、振分ルール情報Ｄ２０（図１参照）に、増設したＡＰＩ提供部３１に関する情報（増設情報）を新たな振分先情報として追加登録する（ステップＳ１２５）。具体的には、リソース管理装置４０は、例えば、ロードバランサ２０（図１参照）に増設情報を送信して、ロードバランサ２０に、増設情報を振分ルール情報Ｄ２０（図１参照）に追加登録させる。ステップＳ１２５の処理は、図２ＡのステップＳＴ４ｃの処理に該当する。この後、処理は、ステップＳ１５５に進む。
【００９０】
一方、ステップＳ１１０の判定で、残リソース量が第１閾値以下のＡＰＩ提供部３１がない（すなわち、残リソース量が少ないＡＰＩ提供部３１がない）と判定された場合（“Ｎｏ”の場合）に、リソース管理装置４０の増減処理部４２は、残リソース量が予め定められた第２閾値以上のＡＰＩ提供部３１があるか否かを（すなわち、残リソース量が多すぎるＡＰＩ提供部３１があるか否かを）判定する（ステップＳ１３０）。
【００９１】
ステップＳ１３０の判定で、残リソース量が第２閾値以上のＡＰＩ提供部３１がある（すなわち、残リソース量が多すぎるＡＰＩ提供部３１がある）と判定された場合（“Ｙｅｓ”の場合）に、リソース管理装置４０の増減処理部４２は、振分ルール情報Ｄ２０（図１参照）から、減設するＡＰＩ提供部３１に関する情報（以下、「減設情報」と称する）を削除する（ステップＳ１３５）。具体的には、リソース管理装置４０は、例えば、ロードバランサ２０（図１参照）に減設情報を送信して、ロードバランサ２０に、減設情報に該当するＡＰＩ提供部３１の登録情報を振分ルール情報Ｄ２０（図１参照）から削除させる。
【００９２】
ステップＳ１３５の後、リソース管理装置４０の増減処理部４２は、減設するＡＰＩ提供部３１を指定して、そのＡＰＩ提供部３１のキュー格納部３３に残っているＡＰＩリクエストＤ３３の数を表す残ＡＰＩリクエスト数情報の通知（送信）命令をＡＰＩ提供装置３０に送信する。これによって、リソース管理装置４０の増減処理部４２は、ＡＰＩ提供装置３０から減設するＡＰＩ提供部３１の残ＡＰＩリクエスト数情報を受信する。そして、リソース管理装置４０の増減処理部４２は、減設するＡＰＩ提供部３１のキュー格納部３３にＡＰＩリクエストＤ３３の残りがあるか否かを判定する（ステップＳ１４０）。
【００９３】
ステップＳ１４０の判定で、減設するＡＰＩ提供部３１のキュー格納部３３にＡＰＩリクエストＤ３３の残りがあると判定された場合（“Ｙｅｓ”の場合）に、処理は、ステップＳ１５５に進む。
【００９４】
一方、ステップＳ１４０の判定で、減設するＡＰＩ提供部３１のキュー格納部３３にＡＰＩリクエストＤ３３の残りがないと判定された場合（“Ｎｏ”の場合）に、リソース管理装置４０の増減処理部４２は、減設するＡＰＩ提供部３１をＡＰＩ提供装置３０から削除し（ステップＳ１４５）、減設するＡＰＩ提供部３１の仮想マシン３７のリソースを開放する（ステップＳ１５０）。ステップＳ１４５，Ｓ１５０の処理は、増減処理部４２が減設用プログラムＰＲ４２ｂを実行することによって行われる。これらの処理は、各ＡＰＩ提供部３１（各仮想マシン３７を含む）の残リソース量に応じて、ＡＰＩ提供装置３０に各ＡＰＩ提供部３１（各仮想マシン３７を含む）の台数をスケールインさせる場合の増減処理工程に相当する。この後、処理は、ステップＳ１５５に進む。
【００９５】
ステップＳ１２５の後、又は、ステップＳ１５０の後、ステップＳ１３０の判定で、残リソース量が第２閾値以上のＡＰＩ提供部３１がない（すなわち、残リソース量が多すぎるＡＰＩ提供部３１がない）と判定された場合（“Ｎｏ”の場合）、又は、ステップＳ１４０の判定で、減設するＡＰＩ提供部３１のキュー格納部３３にＡＰＩリクエストＤ３３の残りがあると判定された場合（“Ｙｅｓ”の場合）に、リソース管理装置４０の転送指示部４３（又はリソース管理部４１）は、イネーブラ装置５０に対して、イネーブラ装置５０の残リソース情報の通知（送信）を要求する。これによって、リソース管理装置４０の転送指示部４３（又はリソース管理部４１）は、イネーブラ装置５０からイネーブラ装置５０の残リソース情報を受信する（ステップＳ１５５）。
【００９６】
この後、リソース管理装置４０の転送指示部４３（又はリソース管理部４１）は、イネーブラ装置５０の残リソース量が予め定められた第３閾値以下であるか否かを判定する（ステップＳ１６０）。
【００９７】
ステップＳ１６０の判定で、イネーブラ装置５０の残リソース量が第３閾値以下である（すなわち、イネーブラ装置５０の処理負荷に余裕がない）と判定された場合（“Ｙｅｓ”の場合）に、リソース管理装置４０の転送指示部４３は、一定時間待機して（ステップＳ１６５）、ステップＳ１６０の判定処理を繰り返す。
【００９８】
一方、ステップＳ１６０の判定で、イネーブラ装置５０の残リソース量が第３閾値を超えている（すなわち、イネーブラ装置５０の処理負荷に余裕がある）と判定された場合（“Ｎｏ”の場合）に、リソース管理装置４０の転送指示部４３は、ＡＰＩ提供装置３０に対して、命令を実行させるＡＰＩ提供部３１を指定して、ＡＰＩリクエストの転送命令を送信する（ステップＳ１７０）。ステップＳ１７０の処理は、図２ＢのステップＳＴ６ｂの処理に該当する。リソース管理装置４０は、ステップＳ１７０の処理を行うことにより、一連のルーチンの処理を終了する。
【００９９】
＜リクエスト受付システムの主な特徴＞
（１）リクエスト受付システム１のＡＰＩ提供装置３０は、ＡＰＩ提供部３１が仮想マシン３７上に構築され、ＡＰＩ提供部３１（仮想マシン３７を含む）を動的にスケールアウト又はスケールインすることができる構成になっている。リクエスト受付システム１は、ＡＰＩ提供部３１のキュー格納部３３に残っている（格納されている）ＡＰＩリクエストＤ３３の数やＡＰＩ提供装置３０の処理負荷状況に応じて、ＡＰＩ提供装置３０のＡＰＩ提供部３１（仮想マシン３７を含む）を動的にスケールアウトすることで、可能な限り多くのＡＰＩリクエストをＡＰＩ提供装置３０に受け付けさせることができる。
【０１００】
このようなリクエスト受付システム１は、大量のリクエスト（到達リクエスト）が特定の時間帯にシステム１に一斉に到達した場合であっても、そのことに起因する輻輳の発生を回避することができる。つまり、リクエスト受付システム１は、リクエスト数に応じた動的な仮想マシン３７のリソースの確保によって、仮想マシン３７のリソースの利用効率を向上させることができる。そのため、リクエスト受付システム１は、リクエスト（到達リクエスト）の処理性能を向上させることができる。その結果、リクエスト受付システム１は、大量の到達リクエストの受け付けが可能となる。
【０１０１】
（２）リクエスト受付システム１は、イネーブラ装置５０が分散処理できない（スケールアウトできない）場合を考慮し、ＡＰＩ提供装置３０の各ＡＰＩ提供部３１でＡＰＩリクエストをキューイングし、イネーブラ装置５０の残リソース量（イネーブラ装置５０の機能実行部５１の処理負荷状況）に応じて、各仮想マシン３７に対して、ＡＰＩリクエストのイネーブラ装置５０への転送を順次行わせる構成になっている。
【０１０２】
このようなリクエスト受付システム１は、イネーブラ装置５０の処理待ち時間が発生しないように、各ＡＰＩ提供部３１のキュー格納部３３に格納されたＡＰＩリクエストＤ３３のイネーブラ装置５０への転送を流量的に制御することができる。その結果、リクエスト受付システム１は、システム１の処理効率の悪化を回避して、システム１の処理効率を向上させることができる。つまり、リクエスト受付システム１は、イネーブラ装置５０が分散処理できず（スケールアウトできず）に、大量のＡＰＩリクエストによってイネーブラ装置５０が過負荷状態になりそうな場合にも、輻輳の悪化を回避することができる。そのため、これによっても、リクエスト受付システム１は、リクエスト（到達リクエスト）の処理性能を向上させることができる。その結果、リクエスト受付システム１は、さらに、大量の到達リクエストの受け付けが可能となる。
【０１０３】
以上の通り、本実施形態に係るリクエスト受付システム１によれば、リクエストの処理性能を向上させることができる。
【０１０４】
本発明は、前記した実施形態に限定されることなく、本発明の要旨を逸脱しない範囲で種々の変更や変形を行うことができる。
【０１０５】
例えば、リクエスト受付システム１は、ＡＰＩ提供装置３０のＡＰＩ処理部３２によって、アプリケーションサーバ１０からＡＰＩ提供装置３０に送信されたＡＰＩリクエストが再送リクエストであるか否かを判別し、再送リクエストである場合に、そのＡＰＩリクエストをキュー格納部３３に格納せずに破棄するように構成してもよい。これにより、リクエスト受付システム１は、イネーブラ装置５０における重複処理を容易に回避することができる。
【符号の説明】
【０１０６】
１    リクエスト受付システム
２    外部装置
３    ユーザ端末
４    スマートメータ
６    公衆回線網
１０    アプリケーションサーバ
１１    アプリケーション処理部
１５    リクエスト処理部
１６    レスポンス処理部
１９    通信部
２０    ロードバランサ
３０    ＡＰＩ提供装置
３１（３１ａ，３１ｂ，…）    ＡＰＩ提供部
３２    ＡＰＩ処理部
３３    キュー格納部
３４    リソース監視部
３５    リクエスト転送部
３６    レスポンス転送部
３７    仮想マシン
３８    ハイパーバイザ
３９    通信部
４０    リソース管理装置
４１    リソース管理部
４２    増減処理部
４３    転送指示部
４９    通信部
５０    イネーブラ装置
５１    機能実行部
５４    リソース監視部
５５    リクエスト処理部
５６    レスポンス処理部
５９    通信部
Ｄ２０    振分ルール情報
Ｄ３３    ＡＰＩリクエスト
ＰＲ１０，ＰＲ２０，ＰＲ３０，ＰＲ４０，ＰＲ５０    制御プログラム
ＰＲ４２ａ    増設用プログラム
ＰＲ４２ｂ    減設用プログラム
【図１】
2017033234.tif 000003
【図２Ａ】
2017033234.tif 000004
【図２Ｂ】
2017033234.tif 000005
【図３】
2017033234.tif 000006
【図４】
2017033234.tif 000007