(57)【要約】【課題】リアクティブなシステムを構築する。【解決手段】管理サーバと、複数の処理サーバとを備える情報処理システムであって、  前記管理サーバは、前記利用者端末から前記実行アプリケーションプログラムへのアクセス要求を受信すると、当該実行アプリケーションプログラムへのアクセスに使用するＩ／Ｆアプリケーションプログラムが配置されている処理サーバを選定し、前記選定された処理サーバに配置されているＩ／Ｆアプリケーションプログラムの接続先を前記利用者端末に通知し、アクセスが要求された実行アプリケーションプログラムを前記複数の処理サーバの一つで起動して、前記起動した実行アプリケーションプログラムの接続先の情報を管理する。【選択図】図１
2020038477.tif 000002
【特許請求の範囲】
【請求項１】
管理サーバと、複数の処理サーバとを備える情報処理システムであって、
前記管理サーバは、アプリケーションプログラムを実行するための１以上のプロセッサと、前記プロセッサがアクセスするメモリとを有し、
前記複数の処理サーバの各々は、アプリケーションプログラムを実行するための１以上のプロセッサと、前記プロセッサがアクセスするメモリとを有し、
前記アプリケーションプログラムは、外部からの要求に従って実行されるＩ／Ｆアプリケーションプログラムと、前記Ｉ／Ｆアプリケーションプログラムからの要求に従って実行される実行アプリケーションプログラムとの２種類のアプリケーションプログラムを含み、
前記管理サーバは、
前記各処理サーバがプログラムを実行可能な計算機リソースと、前記処理サーバにおける前記Ｉ／Ｆアプリケーションプログラムの配置状態と、前記実行アプリケーションプログラムの実行状態とを管理しており、
利用者端末から前記実行アプリケーションプログラムへのアクセス要求を受信すると、当該実行アプリケーションプログラムへのアクセスに使用するＩ／Ｆアプリケーションプログラムが配置されている処理サーバを選定し、
前記選定された処理サーバに配置されているＩ／Ｆアプリケーションプログラムの接続先を前記利用者端末に通知し、
アクセスが要求された実行アプリケーションプログラムを前記複数の処理サーバの一つで起動し、
前記起動した実行アプリケーションプログラムの接続先の情報を管理することを特徴とする情報処理システム。
【請求項２】
請求項１に記載の情報処理システムであって、
前記Ｉ／Ｆアプリケーションプログラムは、実行時の負荷が低く、かつリソース消費量が少ない処理を実行するものであって、
前記実行アプリケーションプログラムは、実行時の負荷が高く、かつリソース消費量が大きい処理を実行するものであることを特徴とする情報処理システム。
【請求項３】
請求項１に記載の情報処理システムであって、
前記管理サーバは、前記起動した実行アプリケーションプログラムの接続先を前記Ｉ／Ｆアプリケーションプログラムに送信する応答部を有し、
前記Ｉ／Ｆアプリケーションプログラムは、前記応答部から受信した接続先に、前記実行アプリケーションプログラムの実行依頼を送信することを特徴とする情報処理システム。
【請求項４】
請求項１に記載の情報処理システムであって、
前記管理サーバは、
破棄監視部を有し、
前記利用者端末から前記Ｉ／Ｆアプリケーションプログラムへの接続状態を管理しており、
前記破棄監視部は、
前記利用者端末が前記Ｉ／Ｆアプリケーションプログラムに接続している接続情報と、前記Ｉ／Ｆアプリケーションプログラムに関連付けられている実行アプリケーションプログラムの実行状態とを判定し、
前記実行アプリケーションプログラムの実行状態が処理完了である場合、前記実行アプリケーションプログラムを停止し、
前記実行アプリケーションプログラムの実行状態が未実行であり、かつ前記実行アプリケーションプログラムに関連付けられているＩ／Ｆアプリケーションプログラムと前記利用者端末との接続が切断している場合、前記実行アプリケーションプログラムを停止することを特徴とする情報処理システム。
【請求項５】
請求項４に記載の情報処理システムであって、
ＨＴＴＰセッションの確立及び切断を用いて、前記Ｉ／Ｆアプリケーションプログラムへの前記利用者端末の接続数を管理し、各利用者端末と前記Ｉ／Ｆアプリケーションプログラムとの接続状態を管理する接続監視部を有することを特徴とする情報処理システム。
【請求項６】
請求項５に記載の情報処理システムであって、
前記管理サーバは、前記利用者端末の接続数に基づいて、前記Ｉ／Ｆアプリケーションプログラムが配置される処理サーバの計算機リソースを増加又は減少することを特徴とする情報処理システム。
【請求項７】
請求項６に記載の情報処理システムであって、
前記管理サーバは、前記利用者端末の接続数が所定の閾値を超えた場合、前記Ｉ／Ｆアプリケーションプログラムを実行中の計算機と異なる計算機で当該Ｉ／Ｆアプリケーションプログラムを起動することを特徴とする情報処理システム。
【請求項８】
管理サーバと、複数の処理サーバとを有する情報処理システムにおける制御方法であって、
前記管理サーバは、アプリケーションプログラムを実行するための１以上のプロセッサと、前記プロセッサがアクセスするメモリとを有し、
前記複数の処理サーバの各々は、アプリケーションプログラムを実行するための１以上のプロセッサと、前記プロセッサがアクセスするメモリとを有し、
前記アプリケーションプログラムは、外部からの要求に従って実行されるＩ／Ｆアプリケーションプログラムと、前記Ｉ／Ｆアプリケーションプログラムからの要求に従って実行される実行アプリケーションプログラムとの２種類のアプリケーションプログラムを含み、
前記制御方法は、
前記管理サーバが、前記各処理サーバがプログラムを実行可能な計算機リソースと、前記処理サーバにおける前記Ｉ／Ｆアプリケーションプログラムの配置状態と、前記実行アプリケーションプログラムの実行状態とを管理し、
前記管理サーバが、利用者端末から前記実行アプリケーションプログラムへのアクセス要求を受信すると、当該実行アプリケーションプログラムへのアクセスに使用するＩ／Ｆアプリケーションプログラムが配置されている処理サーバを選定し、
前記管理サーバが、前記選定された処理サーバに配置されているＩ／Ｆアプリケーションプログラムの接続先を前記利用者端末に通知し、
前記管理サーバが、アクセスが要求された実行アプリケーションプログラムを前記複数の処理サーバの一つで起動して、
前記管理サーバが、前記起動した実行アプリケーションプログラムの接続先の情報を管理することを特徴とする制御方法。
【請求項９】
請求項８に記載の制御方法であって、
前記Ｉ／Ｆアプリケーションプログラムは、実行時の負荷が低く、かつリソース消費量が少ない処理を実行するものであって、
前記実行アプリケーションプログラムは、実行時の負荷が高く、かつリソース消費量が大きい処理を実行するものであることを特徴とする制御方法。
【請求項１０】
請求項８に記載の制御方法であって、
前記管理サーバは、前記起動した実行アプリケーションプログラムの接続先を前記Ｉ／Ｆアプリケーションプログラムに送信し、
前記Ｉ／Ｆアプリケーションプログラムは、前記受信した接続先に、前記実行アプリケーションプログラムの実行依頼を送信することを特徴とする制御方法。
【請求項１１】
請求項８に記載の制御方法であって、
前記管理サーバは、前記利用者端末から前記Ｉ／Ｆアプリケーションプログラムへの接続状態を管理し、
前記管理サーバは、前記利用者端末が前記Ｉ／Ｆアプリケーションプログラムに接続している接続情報と、前記Ｉ／Ｆアプリケーションプログラムに関連付けられている実行アプリケーションプログラムの実行状態とを判定し、
前記管理サーバは、前記実行アプリケーションプログラムの実行状態が処理完了である場合、前記実行アプリケーションプログラムを停止し、
前記管理サーバは、前記実行アプリケーションプログラムの実行状態が未実行であり、かつ前記実行アプリケーションプログラムに関連付けられているＩ／Ｆアプリケーションプログラムと前記利用者端末との接続が切断している場合、前記実行アプリケーションプログラムを停止することを特徴とする制御方法。
【請求項１２】
請求項１１に記載の制御方法であって、
前記情報処理システムは、前記利用者端末から前記情報処理システムへのアクセスを監視する接続監視部を有し、
前記接続監視部は、ＨＴＴＰセッションの確立及び切断を用いて、前記Ｉ／Ｆアプリケーションプログラムへの前記利用者端末の接続数を管理し、各利用者端末と前記Ｉ／Ｆアプリケーションプログラムとの接続状態を管理することを特徴とする制御方法。
【請求項１３】
請求項１２に記載の制御方法であって、
前記管理サーバは、前記利用者端末の接続数に基づいて、前記Ｉ／Ｆアプリケーションプログラムが配置される処理サーバの計算機リソースを増加又は減少することを特徴とする制御方法。
【請求項１４】
請求項１３に記載の制御方法であって、
前記管理サーバは、前記利用者端末の接続数が所定の閾値を超えた場合、前記Ｉ／Ｆアプリケーションプログラムを実行中の計算機と異なる計算機で当該Ｉ／Ｆアプリケーションプログラムを起動することを特徴とする制御方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、情報処理システムに関し、特にその制御方法に関する。
【背景技術】
【０００２】
近年、コンテナと呼ばれるアプリ実行環境を提供するシステム仮想化技術の発展により、様々なアプリケーションプログラム（以下、アプリ）を迅速に起動できるようになってきた。クラウドサービス提供者は、リクエスト量や負荷などの需要変動に応じたアプリ実行環境のリソース量を、コンテナを用いてリアクティブに適時増減させるオートスケールサービスを提供している。例えば、非特許文献１では、Ａｍａｚｏｎ社が提供するＡｍａｚｏｎ  Ｅｌａｓｔｉｃ  Ｃｏｎｔａｉｎｅｒ  Ｓｅｒｖｉｅ（登録商標）、Ｅｌａｓｔｉｃ  Ｌｏａｄ  Ｂａｌａｎｃｉｎｇ（登録商標）、ＣｌｏｕｄＷａｔｃｈ  Ａｌａｒｍ（登録商標）、Ａｕｔｏ  Ｓｃａｌｉｎｇ（登録商標）を利用して、コンテナのＣＰＵなどの負荷変動からコンテナを自動でスケールイン及びスケールアウトするサービスを提供している。また、非特許文献２には、「ＨＴＴＰリクエスト毎に，コンテナの起動，起動時間，起動数およびリソース割り当てをリアクティブに決定する，実行環境の変化に素早く適応できる恒常性を持つシステムアーキテクチャを提案する」（概要）と記載されている。
【０００３】
これらのサービスによって、アプリ運営者は、アプリを配置するサーバを管理せずに、一定の応答性を担保できる。また、リクエスト量や負荷に応じた適正なリソース量のみを利用するため、低コストで運営できる。
【０００４】
しかし、コンテナを利用してもアプリの起動時間はアプリケーションごとに異なり、数秒程度で起動するものや、数十秒が必要なものなどがある。このため、ある程度余裕を持ってスケールアウトする必要があり、リクエスト毎など、高頻度なスケールアウトを実施する場合は、スケールアウト時に起動待ち時間が発生する問題が生じる。
【０００５】
本技術分野の背景技術として、特開２０１２−２０８７８１号公報（特許文献１）がある。特許文献１には、複数の処理サーバを含む処理サーバ群と、処理サーバ群に代替して応答するための代替サーバと、処理サーバ群にトラフィックを分散するとともに、上記処理サーバ群が過負荷状態となった際に代替サーバにトラフィックを転送するロードバランサとを含む情報処理システムが開示されている。さらに、特許文献１に開示された情報処理システムは、上記ロードバランサにより処理サーバ群へ転送される転送量と上記代替サーバへ転送される転送量とに応じて、処理サーバ群の目標規模を演算し、処理サーバ群の現在の規模から目標規模へ増強するため処理サーバ群の処理サーバを準備する。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開２０１２−２０８７８１号公報
【非特許文献】
【０００７】
【非特許文献１】"Automatic Scaling with Amazon ECS"、[Online]、Amazon Web Services(Tm)、[平成30年8月24日]、インターネット＜https://aws.amazon.com/jp/blogs/compute/automatic-scaling-with-amazon-ecs/＞
【非特許文献２】松本亮介，近藤宇智朗，三宅悠介，力武健次，栗林健太郎，”ＦａｓｔＣｏｎｔａｉｎｅｒ：実行環境の変化に素早く適応できる恒常性を持つシステムアーキテクチャ”，インターネットと運用技術シンポジウム２０１７論文集，２０１７，８９−９７（２０１７−１１−３０），２０１７年１１月３０日
【発明の概要】
【発明が解決しようとする課題】
【０００８】
特許文献１に記載された情報処理システムでは、急激な需要変動があった場合、ロードバランサにて代替サーバに振り分け、代替サーバに振り分けたリクエスト量に基づいて、追加するコンテナのスケールアウト量を決定する。これにより、一時的に過剰に受け付けたリクエストのみが起動待ちとなり、既存のアプリ処理には影響を与えず、またリクエストをドロップすることなくスケールアウトでき、リアクティブ性を確保できる。
【０００９】
しかしながら、特許文献１に記載されている情報処理システムでは、急激なリクエスト変動時に既存のアプリ処理に影響を与えないことを着眼しており、起動待ち時間の問題は解決されていない。また、大量データからデータ間の相関を分析するような人工知能技術を活用したアプリを想定した場合、アプリの処理はリソースをほぼ１００％利用するため、一つのリクエストで一つのコンテナのリソースを利用するなど、アプリへの処理リクエスト毎にスケールアウトをする必要が生じる。この場合、特許文献１で開示されている方法を利用しても、リクエスト毎に起動待ち時間が発生し、問題が解決されない。
【課題を解決するための手段】
【００１０】
本願において開示される発明の代表的な一例を示せば以下の通りである。すなわち、管理サーバと、複数の処理サーバとを備える情報処理システムであって、前記複数の処理サーバの各々は、アプリケーションプログラムを実行するための１以上のプロセッサと、前記プロセッサがアクセスするメモリとを有し、前記アプリケーションプログラムは、外部からの要求に従って実行されるＩ／Ｆアプリケーションプログラムと、前記Ｉ／Ｆアプリケーションプログラムからの要求に従って実行される実行アプリケーションプログラムとの２種類のアプリケーションプログラムを含み、前記管理サーバは、前記各処理サーバがプログラムを実行可能な計算機リソースと、前記処理サーバにおける前記Ｉ／Ｆアプリケーションプログラムの配置状態と、前記実行アプリケーションプログラムの実行状態と、利用者端末からの前記Ｉ／Ｆアプリケーションプログラムへの接続状態とを管理しており、前記利用者端末から前記実行アプリケーションプログラムへのアクセス要求を受信すると、当該実行アプリケーションプログラムへのアクセスに使用するＩ／Ｆアプリケーションプログラムが配置されている処理サーバを選定し、前記選定された処理サーバに配置されているＩ／Ｆアプリケーションプログラムの接続先を前記利用者端末に通知し、アクセスが要求された実行アプリケーションプログラムを前記複数の処理サーバの一つで起動して、前記起動した実行アプリケーションプログラムの接続先の情報を管理する。
【発明の効果】
【００１１】
本発明の一態様によれば、利用者からみた実行アプリケーションプログラムの起動時間を低減できる。前述した以外の課題、構成及び効果は、以下の実施例の説明によって明らかにされる。
【図面の簡単な説明】
【００１２】
【図１】情報処理システムの全体構成の例を示す図である。
【図２】情報処理システムを構成する計算機の物理的な構成を示す図である。
【図３】Ｉ／Ｆアプリ状態管理記憶部の構成例を示す図である。
【図４】実行アプリ管理記憶部の構成例を示す図である。
【図５】アプリ選択から実行アプリを実行するまでの処理を示すシーケンス図である。
【図６】アプリリソース制御部が実行する処理のフローチャートである。
【図７】実行アプリアドレス応答部が実行する処理のフローチャートである。
【図８】実行アプリ破棄監視部が実行する処理のフローチャートである。
【図９】アプリ利用者がアプリを選択するための画面の例を示す図である。
【図１０】アプリ利用者が実行アプリの実行状態を確認するための画面の例を示す図である。
【図１１】管理者がアプリの実行状態を確認するための画面の例を示す図である。
【発明を実施するための形態】
【００１３】
以下、各実施例における実施形態について図面を参照して説明する。なお、以下の実施例に用いる図において、同一の符号を付した部分は同一物を表し、それらの構造及び動作は同じである。
【００１４】
＜実施例１＞
図１は、実施例１に係る情報処理システムの全体構成の例を示す図である。
【００１５】
実施例１に係る情報システムは、クライアント端末１０１、ネットワーク１０２を介してクライアント端末１０１と接続されるフロントゲートウェイ１０３、ネットワーク１０９を介してフロントゲートウェイ１０３と接続されるアプリポータルサーバ１０４、アプリリソース制御管理サーバ１０５、状態監視管理サーバ１０６、アプリプログラム管理サーバ１０７、ユーザデータ管理サーバ１０８及び複数の処理サーバ１３０を有する。図１では、クライアント端末１０１と各種サーバ（フロントゲートウェイ１０３、アプリポータルサーバ１０４、アプリリソース制御管理サーバ１０５、状態監視管理サーバ１０６、アプリプログラム管理サーバ１０７、ユーザデータ管理サーバ１０８、処理サーバ１３０）が異なるネットワーク（１０２、１０９）に接続されているが、クライアント端末１０１と各種サーバを同一ネットワークに接続して情報処理システムを構成していてもよい。
【００１６】
クライアント端末１０１は、アプリ利用者が使用する端末であり、アプリ利用者が、選択したアプリと接続するためのアクセス要求や、入力データやパラメータ情報を含むアプリを実行するための実行要求などの処理要求を送信するために用いられる。クライアント端末１０１は、例えば、会社や工場内に設置されたパーソナルコンピュータやサーバである。又は、クライアント端末１０１は、スマートフォンやタブレット端末などの通信機能を有する通信デバイスでもよい。
【００１７】
ネットワーク１０２、１０９は、通信キャリアなどによって提供される無線ネットワーク又は有線ネットワークである。ネットワーク１０２、１０９は、個別の会社などが所有するネットワークを、その一部に含んでもよく、複数種類のプロトコルを通過させるネットワークでもよい。
【００１８】
フロントゲートウェイ１０３は、クライアント端末１０１から実行要求などの処理要求を受け付け、受け付けた処理要求に基づいて、各種サーバ（アプリポータルサーバ１０４、アプリリソース制御管理サーバ１０５、状態監視管理サーバ１０６、アプリプログラム管理サーバ１０７、ユーザデータ管理サーバ１０８、処理サーバ１３０）に処理依頼を送信し、処理結果をクライアント端末１０１に返信する処理を実行する計算機である。
【００１９】
アプリポータルサーバ１０４は、アプリ利用者に対して、利用可能なアプリを一覧表示して、各アプリの利用を選択できるようにまとめたポータルサイトを提供する計算機であり、その詳細は図９、図１０を参照して後述する。
【００２０】
アプリリソース制御管理サーバ１０５は、各処理サーバ１３０の利用状態を管理する計算機であり、処理サーバ１３０にアプリを配置したり破棄したり、またクライアント端末１０１と各処理サーバ１３０との接続先の管理を行う。アプリリソース制御管理サーバ１０５は、アプリリソース制御部１１１、実行アプリアドレス応答部１１２、実行アプリ破棄監視部１１３、Ｉ／Ｆアプリ状態管理記憶部１１４及び実行アプリ状態管理記憶部１１５を有する。アプリリソース制御管理サーバ１０５の詳細は後述する。
【００２１】
状態監視管理サーバ１０６は、クライアント端末１０１と各処理サーバ１３０との接続状態を監視するセッション監視部１２１、及び各処理サーバ１３０に配置される実行アプリケーションプログラムの実行状態を監視する実行アプリ監視部１２２を有し、各監視部（１２１、１２２）は、検出した状態変化をアプリリソース制御管理サーバ１０５に通知して、Ｉ／Ｆアプリ状態管理記憶部１１４及び実行アプリ状態管理記憶部１１５のレコードを追加又は更新する。
【００２２】
ここで、セッション監視部１２１及び実行アプリ監視部１２２は、所定のタイミングで繰り返し（例えば、１分や１時間などの定期的に）接続状態や実行状態を監視する。まｙた、セッション監視部１２１は、クライアント端末１０１と処理サーバ１３０との間の通信が通過するフロントゲートウェイ１０３にて接続確立及び接続断を検出して、セッション監視部１２１に通知することにより接続状態や実行状態を監視してもよい。例えば、クライアント端末１０１から送信されるＨＴＴＰセッションの接続確立及び接続断を用いて、クライアント端末１０１と処理サーバ（Ｉ／Ｆアプリ）１３０との接続を管理してもよい。また、実行アプリ監視部１２２は、各処理サーバ１３０にインストールされた、実行状態を監視するエージェントを用いて、実行状態が変化した際に通知を受け取ってもよい。
【００２３】
アプリプログラム管理サーバ１０７は、処理サーバ１３０に配置されるアプリケーションプログラムを格納する計算機である。アプリリソース制御管理サーバ１０５は、アプリプログラム管理サーバ１０７に格納されているアプリケーションプログラムをダウンロードして、処理サーバ１３０にアプリを配置する。アプリケーションプログラムをコンテナで管理する場合、例えばＧｉｔＨｕｂ（商標登録）を利用して管理してもよい。
【００２４】
ここで、アプリプログラム管理サーバ１０７が管理するアプリは、Ｉ／Ｆアプリケーションプログラム（以下、Ｉ／Ｆアプリと称する）と実行アプリケーションプログラム（以下、実行アプリと称する）の２種類を含む。Ｉ／Ｆアプリは、アプリリソース制御管理サーバ１０５からの起動要求に従って実行され、Ｗｅｂのインターフェースなどを有し、入力データの受け付け、処理の実行のためのパラメータ情報の受け付け、必要に応じてユーザデータ管理サーバ１０８にデータを格納する等の負荷が低くリソース消費量が少ない処理を実行する。実行アプリは、Ｉ／Ｆアプリからの起動要求に従って実行され、受け付けた入力データやパラメータに基づいて分析などの負荷が高くリソース消費量が大きい処理を実行する。負荷の高低やリソース消費量大小は、Ｉ／Ｆアプリと実行アプリとを比較したものでも、所定の閾値に対するものでもよい。一般的に、Ｉ／Ｆアプリは負荷が低くリソース消費量が少ない処理を実行し、実行アプリはＩ／Ｆアプリより負荷が高くリソース消費量が大きい処理を実行するが、これは一例であって、例えば、Ｉ／Ｆアプリが負荷が低くリソース消費量が大きい処理を実行し、実行アプリがＩ／Ｆアプリより負荷が高くリソース消費量が小さい処理を実行するものでもよい。図１に示す例では、Ｉ／ＦアプリＵＩ−ａｐｐＡによる処理の後、実行アプリａｐｐＡが実行され、一連のアプリケーション処理が完了する。
【００２５】
ユーザデータ管理サーバ１０８は、アプリの実行時に処理対象である入力データや、処理結果である出力データを格納する計算機である。具体的には、入力データ及び出力データがファイルの場合は共有ファイルサーバ、レコードとして格納しておく場合は構造データベースサーバ、ｊｓｏｎなどの形式で格納しておく場合はキーバリューストアなどの非構造データベースなどのデータを格納する計算機で構成される。
【００２６】
処理サーバ１３０は、アプリプログラム管理サーバ１０７が管理しているアプリを実行するための計算機である。一つの処理サーバ１３０に配置されるアプリは、複数登録することも可能である。アプリリソース制御管理サーバ１０５は、アプリのリソース利用量などの特性によって、アプリを配置する処理サーバ１３０を選定する。
【００２７】
本実施例では、これらのサーバがそれぞれ物理的に異なる計算機に構成される例を説明する。なお、これらのサーバが、異なる計算機に構成される必要はなく、前述したサーバが有する機能が、単一の計算機に実装されていてもよい。例えば、情報処理システム内に、前述したフロントゲートウェイ１０３、アプリポータルサーバ１０４、アプリリソース制御管理サーバ１０５、状態監視管理サーバ１０６、アプリプログラム管理サーバ１０７及びユーザデータ管理サーバ１０８に代えて、１台の計算機（「統合管理サーバ」と称する）を設け、前述した各サーバ１０４〜１０８の機能を、その管理サーバに実装してもよい。又は、処理サーバ１３０の一つ（又は複数）が、統合管理サーバとして機能してもよい。
【００２８】
さらに別の実施形態として、情報処理システム内に設けられた１台又は複数台の計算機上で、いわゆる仮想計算機を提供するためのソフトウェア（一般的にハイパーバイザと称される）を実行し、フロントゲートウェイ１０３の役割を果たす仮想計算機、アプリポータルサーバ１０４の役割を果たす仮想計算機、アプリリソース制御管理サーバ１０５の役割を果たす仮想計算機、状態監視管理サーバ１０６の役割を果たす仮想計算機、アプリプログラム管理サーバ１０７の役割を果たす仮想計算機、及びユーザデータ管理サーバ１０８の役割を果たす仮想計算機を計算機上に構築して、情報処理システムが構成されてもよい。仮想計算機は、コンテナを用いた仮想化技術によって構成されてもよい。また、アプリプログラム管理サーバ１０７など構成の一部を、ＧｉｔＨｕｂ（登録商標）などのＳａａＳ（Ｓｏｆｔｗａｒｅ  ａｓ  ａ  Ｓｅｒｖｉｃｅ）を利用してもよい。
【００２９】
図２は、図１で示したフロントゲートウェイ１０３、アプリポータルサーバ１０４、アプリリソース制御管理サーバ１０５、状態監視管理サーバ１０６、アプリプログラム管理サーバ１０７、ユーザデータ管理サーバ１０８、処理サーバ１３０及びクライアント端末１０１など、情報処理システムを構成する計算機の物理的な構成を示す図である。本実施例ではこれらのサーバ（又はクライアント端末１０１）には、プロセッサ（ＣＰＵ）２０１、メモリ２０２、補助記憶装置２０３及び通信インターフェース（通信Ｉ／Ｆ）２０４を有する計算機２００が用いられる。この計算機は一例として、パーソナルコンピュータ（ＰＣ）等の汎用的な計算機でよい。
【００３０】
プロセッサ２０１は、メモリ２０２に格納されたプログラムを実行する。プロセッサ２０１の数は１とは限らず、計算機２００は複数のプロセッサ２０１を有してもよい。また、プロセッサ２０１は複数のプロセッサコアを有する、いわゆるマルチコアプロセッサでもよい。メモリ２０２は、不揮発性の記憶素子であるＲＯＭ及び揮発性の記憶素子であるＲＡＭを含む。ＲＯＭは、不変のプログラム（例えば、ＢＩＯＳ）などを格納する。ＲＡＭは、ＤＲＡＭ（Dynamic Random Access Memory）のような高速かつ揮発性の記憶素子であり、プロセッサ２０１が実行するプログラム及びプログラムの実行時に使用されるデータを一時的に格納する。
【００３１】
補助記憶装置２０３は、例えば、磁気記憶装置（ＨＤＤ）、フラッシュメモリ（ＳＳＤ）等の大容量かつ不揮発性の記憶装置であり、プロセッサ２０１が実行するプログラム及びプログラムの実行時に使用されるデータを格納する。すなわち、プログラムは、補助記憶装置２０３から読み出されて、メモリ２０２にロードされて、プロセッサ２０１によって実行される。
【００３２】
通信インターフェース２０４は、所定のプロトコルに従って、他の装置との通信を制御するネットワークインターフェース装置である。
【００３３】
計算機２００は、入力インターフェース（入力Ｉ／Ｆ）２０５及び出力インターフェース（出力Ｉ／Ｆ）２０８を有してもよい。入力インターフェース２０５は、キーボード２０６やマウス２０７などが接続され、オペレータからの入力を受けるインターフェースである。出力インターフェース２０８は、ディスプレイ装置２０９やプリンタなどが接続され、プログラムの実行結果をオペレータが視認可能な形式で出力するインターフェースである。
【００３４】
なお、本実施例では、アプリリソース制御管理サーバ１０５、状態監視管理サーバ１０６、処理サーバ１３０の有する各機能部は、ソフトウェア（プログラム）によって実装される。例えば、アプリリソース制御管理サーバ１０５では、アプリリソース制御部１１１、実行アプリアドレス応答部１１２、実行アプリ破棄監視部１１３、Ｉ／Ｆアプリ状態管理記憶部１１４及び実行アプリ状態管理記憶部１１５としてアプリリソース制御管理サーバ１０５を機能させるためのプログラムが、アプリリソース制御管理サーバ１０５（計算機２００）のメモリ２０２上にロードされ、プロセッサ２０１によって実行される。これによりアプリリソース制御管理サーバ１０５は、アプリリソース制御部１１１、実行アプリアドレス応答部１１２、実行アプリ破棄監視部１１３、Ｉ／Ｆアプリ状態管理記憶部１１４及び実行アプリ状態管理記憶部１１５を有する装置として動作する。
【００３５】
処理サーバ１３０も同様に、計算機２００のプロセッサ２０１で、前述した各機能部を実現するためのプログラムを実行する。これによって処理サーバ１３０は、前述した各機能部を有する装置として動作する。以下では、アプリリソース制御管理サーバ１０５、状態監視管理サーバ１０６及び処理サーバ１３０等で実行される処理を説明する際に、アプリリソース制御部１１１や実行アプリアドレス応答部１１２等の機能部を主語として説明することがあるが、実際には、各機能部を有する計算機２００のプロセッサ２０１が処理を行うことを意味する。
【００３６】
また、プロセッサ２０１が実行するプログラムは、計算機が読み取り可能な記憶メディア又はネットワークを介して計算機２００に提供され、非一時的記憶媒体である補助記憶装置２０３に格納される。計算機が読み取り可能な記憶メディアとは、非一時的なコンピュータ可読媒体で、たとえばＣＤ−ＲＯＭやフラッシュメモリなどの、不揮発性のリムーバブルメディアである。このため計算機２００は、リムーバブルメディアからデータを読み込むインターフェースを有するとよい。
【００３７】
また、別の形態として、各機能部の一部又は全てにＦＰＧＡ（Field Programable Gate Array）やＡＳＩＣ（Application Specific Integrated Circuit）などのハードウェアを用いて実装されてもよい。
【００３８】
図３は、アプリリソース制御管理サーバ１０５内に保持されるＩ／Ｆアプリ状態管理記憶部１１４の構成例を示す図である。本実施例では、Ｉ／Ｆアプリ状態管理記憶部１１４は、メモリ２０２や補助記憶装置２０３の記憶領域に格納されたテーブルに各種情報を記憶する例を説明するが、他のデータ形式を採用してもよい。
【００３９】
Ｉ／Ｆアプリ状態管理記憶部１１４は、処理サーバ１３０に配置されているＩ／Ｆアプリの接続状態を管理している。
【００４０】
Ｉ／Ｆアプリ状態管理記憶部１１４が有するテーブル３００の各行（レコード）は、図３に示す三つのカラムを有し、各レコードは情報処理システム内の処理サーバ１３０の情報を格納する。Ｉ／Ｆアプリ種別３０１は、処理サーバ１３０に配置しているアプリの名称を格納する欄である。Ｉ／Ｆアプリアドレス３０２は、処理サーバ１３０に配置しているＩ／Ｆアプリにアクセスするための接続情報を格納する欄である。本実施例では、「ＵＩ−ａｐｐＡ１」など配置しているアプリ内で一意な名前でアプリへ接続する例を示している。接続情報はＩＰアドレスなどでもよい。セッション数３０３は、処理サーバ１３０に配置されているアプリに接続しているクライアント端末１０１の数を格納する欄である。
【００４１】
図４は、アプリリソース制御管理サーバ１０５内に保持される実行アプリ状態管理記憶部１１５の構成例を示す図である。
【００４２】
実行アプリ状態管理記憶部１１５は、処理サーバ１３０に配置している実行アプリの実行アプリ実行依頼における実行状態と、実行依頼に関連付けられたＩ／Ｆアプリとクライアント端末１０１との接続状態を管理する情報をメモリ２０２や補助記憶装置２０３の記憶領域に格納する。一例として、実行アプリ状態管理記憶部１１５は、公知のファイルシステムプログラム又はデータベース管理システム（ＤＢＭＳ）のようなプログラムを用いて実装されてもよい。
【００４３】
実行アプリ状態管理記憶部１１５が有するテーブル４００は、図４に示す四つのカラムを有する。実行アプリアドレス４０１は、処理サーバ１３０に配置されている実行アプリにアクセスするための接続情報を格納する欄であり、実行アプリを一意に特定するために用いられる。実行状態４０２は、処理サーバ１３０に配置される実行アプリが、実行前か実行中か実行完了しているかの３段階で状態を管理する。本実施例では、実行前では「Ｎｏｎｅ」、実行中では「Ｒｕｎ」、実行完了では「Ｃｏｍｐｌｅｔｅ」を格納している。タスクＩＤ４０３は、実行依頼を出すＩ／Ｆアプリとタスクとの関連付けを管理するために、クライアント端末１０１からＩ／Ｆアプリに接続される毎に発行される識別情報（タスクＩＤ）を格納する。ここで、タスクは、クライアント端末１０１から、アクセス要求に従って送信され、実行アプリに対する命令やパラメータを含む。本実施例では、クライアント端末１０１からＩ／Ｆアプリに新規に接続する際に、ネットワークのセッション情報に基づいて、フロントゲートウェイ１０３がタスクＩＤ発行する。セッションフラグ４０４は、タスクＩＤに関連付けられたクライアント端末１０１とＩ／Ｆアプリとのセッション情報の接続有無を管理する情報を格納する。本実施例では、セッションが確立されている状態では「Ｔｒｕｅ」、セッションが切断されている状態では「Ｆａｌｓｅ」を格納している。
【００４４】
図５は、アプリ利用者がクライアント端末１０１からアプリポータルサーバ１０４に接続して、アプリポータルサーバ１０４のＷｅｂ画面に表示されるアプリ選択画面からアプリを選択した後、実行アプリを実行するまでの処理を示すシーケンス図である。
【００４５】
まず、アプリ利用者は、クライアント端末１０１を操作し、フロントゲートウェイ１０３を経由してアプリポータルサーバ１０４と接続して、実行するアプリを選択する（５０１）。アプリの選択後、クライアント端末１０１は選択されたＩ／Ｆアプリ名称（ＵＩ−ａｐｐＡ）情報及びセッションＩＤを含むアクセス依頼５０２をフロントゲートウェイ１０３に送信する（５０２）。
【００４６】
フロントゲートウェイ１０３は、セッションＩＤが新規である場合、新規にタスクＩＤを払い出して（５０３）、タスクＩＤ及びＩ／Ｆアプリ名称を含む、Ｉ／Ｆアプリの接続先情報要求を、アプリリソース制御管理サーバ１０５に送信する。
【００４７】
アプリリソース制御管理サーバ１０５が接続先取得要求を受け取ると、アプリリソース制御部１１１は、処理サーバ１３０のリソース（例えば、プロセッサやメモリの空き状況）を管理しており、Ｉ／Ｆアプリが配置されている処理サーバ１３０を選定し、空いている処理サーバ１３０から実行アプリを事前に起動する（５０５、５０７）。また、Ｉ／Ｆアプリが配置されている処理サーバ１３０の負荷が大きくなると（処理サーバ１３０への接続数が所定の閾値以上となる等）、空いている処理サーバ１３０にＩ／Ｆアプリを新規に配置する。なお、Ｉ／Ｆアプリ及び実行アプリの起動に要する時間は、早いアプリだと数秒であるが、遅いアプリだと十数秒から数分かかる場合があり、起動要求後すぐにアクセスできない場合がある。アプリリソース制御部１１１の動作フローの詳細は図６を参照して後述する。
【００４８】
次に、アプリリソース制御部１１１は、選定したＩ／Ｆアプリの接続先情報であるＩ／Ｆアプリアドレスをフロントゲートウェイ１０３に返信する（５０８）。
【００４９】
フロントゲートウェイ１０３は、Ｉ／ＦアプリアドレスとタスクＩＤとセッションＩＤとの対応付けを記憶し（５０９）、クライアント端末１０１に、Ｉ／Ｆアプリアドレス及びタスクＩＤを返信する（５１０）。
【００５０】
クライアント端末１０１は、受信したＩ／Ｆアプリアドレスに対して、フロントゲートウェイ１０３経由でアクセスして、Ｉ／Ｆアプリにデータやパラメータを入力する（５１１）。この時、入力されたデータやパラメータを、ユーザデータ管理サーバ１０８に格納してもよい。入力されたデータやパラメータをユーザデータ管理サーバ１０８に格納することによって、当該アプリを再度実行する際に、この格納されたデータやパラメータを利用して、データやパラメータの入力を省略できる。入力完了後、クライアント端末１０１は、タスクＩＤを含む実行要求を、フロントゲートウェイ１０３経由でＩ／Ｆアプリに送信する（５１２、５１３）。
【００５１】
処理サーバ（Ｉ／Ｆアプリ）１３０は、Ｉ／Ｆアプリによる処理が完了した後に、実行アプリ接続先取得要求（タスクＩＤ）を、アプリリソース制御管理サーバ１０５に送信する（５１４）。
【００５２】
アプリリソース制御管理サーバ１０５が実行アプリ接続先取得要求を受け取ると、実行アプリアドレス応答部１１２が、タスクＩＤに対応する実行アプリアドレスを返信する（５１５、５１６）。実行アプリアドレス応答部１１２の動作フローの詳細は図７を参照して後述する。
【００５３】
処理サーバ（Ｉ／Ｆアプリ）１３０は、入力されたデータ及びパラメータを引数とした実行依頼を、取得した実行アプリアドレスの情報に送信する（５１７）。そして、処理サーバ（Ｉ／Ｆアプリ）１３０は、フロントゲートウェイ１０３経由でクライアント端末１０１にＯＫを返信して処理を終了する（５１８、５１９）。
【００５４】
また、処理サーバ（実行アプリ）１３０は、は、受け取った実行依頼に基づいて、処理を実行する。
【００５５】
本実施例において、Ｉ／Ｆアプリから実行アプリへの実行依頼５１７の後、直ちにＯＫ５１８が返信され、実行依頼５１７と実行結果が非同期である場合を例示したが、実行依頼５１７のあと、実行アプリの実行結果を待って、実行結果とともにＯＫ５１８をクライアント端末１０１に返信してもよい。
【００５６】
このシーケンスによって、クライアント端末１０１からのＩ／Ｆアプリのアクセス要求毎に実行アプリを処理サーバ１３０に配置しても、Ｉ／Ｆアプリのデータ入力やパラメータ入力の時間に実行アプリを起動するので、実行アプリを実行依頼する際には、実行アプリの起動が完了している、又は、実行アプリの起動完了までの時間を短縮でき、アプリ利用者からみて実質アプリの起動待ち時間をゼロにし又は短縮できる。
【００５７】
また、Ｉ／Ｆアプリと実行アプリとを分離し、Ｉ／Ｆアプリへの接続と実行アプリの実行との関連付けを、セッションＩＤ及びタスクＩＤを関連付けて管理することによって、実行アプリが未完了の状態でＩ／Ｆアプリとの接続が切断しても、実行アプリは単独で動作できる。
【００５８】
図６は、アプリリソース制御管理サーバ１０５のアプリリソース制御部１１１が実行する処理のフローチャートである。
【００５９】
まず、アプリリソース制御部１１１は、フロントゲートウェイ１０３から接続先取得要求５０４を受け取ると（ステップ６０１）、接続先取得要求５０４の引数であるＩ／Ｆアプリ名称に対応し、処理サーバ１３０上で稼働しているＩ／Ｆアプリを選定するために、アプリリソース制御管理サーバ１０５のＩ／Ｆアプリ状態管理記憶部１１４からＩ／Ｆアプリ名称に対応するＩ／Ｆアプリアドレス３０２とセッション数３０３を取得する。そして、取得したセッション数などの情報から、割り当てるＩ／Ｆアプリアドレスを決定する（ステップ６０２）。
【００６０】
アプリリソース制御部１１１は、Ｉ／Ｆアプリアドレスを決定すると、Ｉ／Ｆアプリ状態管理記憶部１１４のセッション数３０３を更新し（ステップ６０３）、更新されたセッション数が所定の閾値を超えていないかを判定する（ステップ６０４）。
【００６１】
更新後のセッション数が所定の閾値を超えている場合、アプリリソース制御部１１１は、Ｉ／Ｆアプリ及び実行アプリのいずれもが起動していない処理サーバ１３０を選定して、アプリプログラム管理サーバ１０７から該当するＩ／Ｆアプリをダウンロードして、Ｉ／Ｆアプリの起動要求を送信する（ステップ６０５）。
【００６２】
その後、アプリリソース制御部１１１は、Ｉ／Ｆアプリを起動すると、Ｉ／Ｆアプリアドレスを含むレコードをＩ／Ｆアプリ状態管理記憶部１１４に追加登録して（ステップ６０６）、ステップ６０６に進む。
【００６３】
一方、更新後のセッション数が所定の閾値を超えていなければ、アプリリソース制御部１１１は、Ｉ／Ｆアプリ及び実行アプリのいずれもが起動していない処理サーバ１３０から実行アプリを起動するための処理サーバ１３０を選定し、アプリプログラム管理サーバ１０７から該当する実行アプリをダウンロードして、実行アプリの起動要求を送信する（ステップ６０７）。
【００６４】
その際に、アプリリソース制御部１１１は、取得した実行アプリに接続するための実行アプリアドレスを、タスクＩＤ及び起動状態が「Ｎｏｎｅ」を含むレコードを、実行アプリ状態管理記憶部１１５に追加登録する（ステップ６０８）。
【００６５】
最後に、アプリリソース制御部１１１は、選定したＩ／Ｆアプリアドレスをフロントゲートウェイ１０３に返信して（ステップ６０９）、処理を終了する。
【００６６】
ここで、Ｉ／Ｆアプリと実行アプリとを新規に処理サーバ１３０で起動する際に、アプリプログラム管理サーバ１０７から該当するＩ／Ｆアプリをダウンロードするが、もし該当するアプリケーションプログラムが処理サーバ１３０に既に配置されているが起動していない場合、当該アプリケーションプログラムをダウンロードせず、既にダウンロードされているアプリケーションプログラムを起動する。また、空いている処理サーバ１３０を選択する際、アプリケーションプログラムが配置されているが起動していない処理サーバ１３０を優先的に選択すると、ダウンロード時間が不要となり、より早く起動できる。そのため、空いている処理サーバ１３０には、記憶容量が許す限り、予めＩ／Ｆアプリ及び実行アプリを配置しておくこととよい。起動しないアプリケーションプログラムを事前配置する方法は、アプリ毎の過去の利用履歴や、アプリのリソース消費特性などを考慮して、Ｉ／Ｆアプリ及び実行アプリを配置する処理サーバ１３０を決めるとよい。
【００６７】
なお、セッション数が少ない場合、Ｉ／Ｆアプリが起動している処理サーバ１３０を減らしてもよい。例えば、セッション数が、処理サーバ１３０の低稼働を示す閾値より小さければ、当該処理サーバ１３０への新たな接続を中止し、接続中の全てのセッションが切断した後に、当該処理サーバ１３０を解放するとよい。
【００６８】
図７は、アプリリソース制御管理サーバ１０５の実行アプリアドレス応答部１１２が実行する処理のフローチャートである。
【００６９】
まず、処理サーバ１３０上で稼働しているＩ／Ｆアプリから実行アプリ接続先取得要求５１４を受け取ると（ステップ７０１）、実行アプリ接続先取得要求５１４の引数にあるタスクＩＤに対応する実行アプリアドレスを実行アプリ状態管理記憶部１１５より取得する（ステップ７０２）。そして、取得した実行アプリアドレスをＩ／Ｆアプリに返信して（ステップ７０３）、処理を終了する。
【００７０】
図８は、アプリリソース制御管理サーバ１０５の実行アプリ破棄監視部１１３が実行する処理のフローチャートである。この処理は、定期的に動作してもよいし、状態監視管理サーバ１０６がアプリリソース制御管理サーバ１０５内の実行アプリ状態管理記憶部１１５を更新したことを契機に起動してもよい。
【００７１】
まず、アプリリソース制御管理サーバ１０５の実行アプリ状態管理記憶部１１５内に格納されている実行アプリの実行状態４０２及びセッションフラグ４０４を取得し（ステップ８０１）、全ての実行アプリアドレスの状態を確認する（ステップ８０２）。実行状態４０２が「Ｃｏｍｐｌｅｔｅ」である場合、及び実行状態４０２が「Ｎｏｎｅ」でありかつセッションフラグ４０４が「Ｆａｌｓｅ」である場合、該当する実行アプリアドレスの処理サーバ１３０から実行アプリの起動を停止する（ステップ８０３、８０４、８０５）。
【００７２】
例えば、図４に示す実行アプリ状態管理記憶部１１５の例では、実行状態４０２が「Ｃｏｍｐｌｅｔｅ」であるレコード４１０−１、４１０−２、４１０−５の実行アプリが停止し、また実行状態４０２が「Ｎｏｎｅ」であり、かつセッションフラグ４０４が「Ｆａｌｓｅ」であるレコード４１０−４の実行アプリが停止する。
【００７３】
この処理を、全ての実行アプリアドレス分実行することによって、実行が完了して不要となった実行アプリや、アプリ利用者が利用しようと試みたが、Ｉ／Ｆアプリ上でのデータ入力やパラメータ入力の段階で利用を止めて、Ｉ／Ｆアプリとの接続を切ったために不要となった実行アプリを、処理サーバ１３０から削除できる。
【００７４】
次に、アプリ利用者がアプリの選択や、実行依頼したアプリの実行状態を管理するための画面を説明する。これらの画面はアプリポータルサーバ１０４が提供する。
【００７５】
図９は、アプリ利用者がアプリを選択するための画面の例を示す図である。本実施例では、クライアント端末１０１からの最初の接続の際に、アプリポータルサーバ１０４がアプリポータル画面９００を作成して、フロントゲートウェイ１０３を経由して、クライアント端末１０１に提供する（クライアント端末１０１のディスプレイ装置２０９に表示される）例を説明する。
【００７６】
図９において、アプリポータル画面９００は、コンテンツ一覧として、「ａｐｐＡ」９０１ａ、「ａｐｐＢ」９０１ｂ、「ａｐｐＣ」９０１ｃなどのアプリを一覧で表示し、各アプリの表示領域内に、起動ボタン９０２ａ〜９０２ｃと、マニュアルボタン９０３ａ〜９０３ｃとが設けられている。起動ボタン９０２ａを操作すると、選択された実行アプリに対応するＩ／Ｆアプリ名称を含むアクセス依頼５０２がフロントゲートウェイ１０３に送信される。また、マニュアルボタン９０３を操作すると、そのアプリの概要や利用方法などのドキュメントが表示される。
【００７７】
このアプリポータル画面９００のコンテンツ一覧によって、アプリ利用者はアプリ名称やマニュアルなどを見ながらアプリを探して、利用したいアプリを選択するだけで、該当するアプリに簡単にアクセスできる。
【００７８】
図１０は、アプリ利用者が実行アプリの実行状態を確認し、実行アプリが未完了の状態でＩ／Ｆアプリとの接続を切断した際に実行アプリの実行結果を見るための画面の例を示す図である。本実施例では、図９と同様に、クライアント端末１０１からのアクセス要求に対して、アプリポータルサーバ１０４がアプリポータル画面１０００を作成して、フロントゲートウェイ１０３を経由して、クライアント端末１０１に提供する（クライアント端末１０１のディスプレイ装置２０９に表示される）例を説明する。
【００７９】
図１０において、アプリポータル画面１０００には、実行アプリの利用履歴として、実行依頼によって起動された実行アプリの名称であるアプリ欄１００１と、当該実行アプリの開始時刻欄１００２と、当該実行アプリの実行状態欄１００３と、当該実行アプリの実行が完了した完了時刻欄１００４とが表示される。
【００８０】
ここで、実行状態１００３に「Ｃｏｍｐｌｅｔｅ」が表示されている場合、例えば、アプリ欄１００１の「ＡｐｐＡ」又は実行状態欄１００３の「Ｃｏｍｐｌｅｔｅ」などをクリックするなどの操作によって、該当する実行アプリに対応するＩ／Ｆアプリに接続でき、実行結果を閲覧できる。
【００８１】
図１１は、管理者がアプリの実行状態を確認するための画面の例を示す図である。
【００８２】
本実施例では、管理者が使用するクライアント端末１０１からのアクセス要求に対して、アプリポータルサーバ１０４が管理者用のアプリポータル画面１１００を作成して、フロントゲートウェイ１０３を経由して、クライアント端末１０１に提供する（クライアント端末１０１のディスプレイ装置２０９に表示される）例を説明する。
【００８３】
図１１において、アプリポータル画面１１００には、処理サーバ毎のアプリの実行状態として、処理サーバ１３０の名称を表示する処理サーバ欄１１０１と、当該処理サーバ１３０で実行されているＩ／Ｆアプリ及び実行アプリの名称を表示するアプリ欄１１０２と、当該アプリにアクセスするためのアドレスを表示するアドレス欄１１０３と、当該アプリへの接続数を表示するアクセス数欄１１０４と、当該アプリの十個開始からの経過時間を示す継続時間欄１１０５とが表示される。
【００８４】
ここで、処理サーバ欄１１０１に表示されるサーバ名をクリックするなどの操作によって、該当する処理サーバ１３０の詳細な情報を表示可能としてもよい。また、アプリ欄１１０２に表示されるアプリ名や、アドレス欄１１０３に表示されるアプリのアドレスをクリックするなどの操作によって、該当するアプリの詳細な情報を表示可能としてもよい。
【００８５】
以上に説明したように、本発明の実施例によると、アプリリソース制御管理サーバ１０５は、各処理サーバ１３０がプログラムを実行可能な計算機リソースと、処理サーバ１３０におけるＩ／Ｆアプリケーションプログラムの配置状態（Ｉ／Ｆアプリ状態管理記憶部１１４）と、実行アプリケーションプログラムの実行状態（実行アプリ状態管理記憶部１１５）とを管理しており、利用者端末（クライアント端末１０１）から実行アプリケーションプログラムへのアクセス要求を受信すると、当該実行アプリケーションプログラムへのアクセスに使用するＩ／Ｆアプリケーションプログラムが配置されている処理サーバ１３０を選定し、選定された処理サーバに配置されているＩ／Ｆアプリケーションプログラムの接続先をクライアント端末１０１に通知し、アクセスが要求された実行アプリケーションプログラムを複数の処理サーバ１３０の一つ（例えば、空きサーバ）で起動し、起動した実行アプリケーションプログラムの接続先の情報を管理するので、実行アプリケーションプログラムのリソース消費量が多くても、利用者から見た起動待ち時間を低減し、リアクティブなスケールアウトが可能なシステムを構築できる。
【００８６】
また、Ｉ／Ｆアプリケーションプログラムは、実行時の負荷が低く、かつリソース消費量が少ない処理を実行するものであって、実行アプリケーションプログラムは、実行時の負荷が高く、かつリソース消費量が大きい処理を実行するものであるので、利用者から見た実行アプリケーションプログラムの起動待ち時間の低減の効果が大きくなる。
【００８７】
また、アプリリソース制御管理サーバ１０５は、起動した実行アプリケーションプログラムの接続先をＩ／Ｆアプリケーションプログラムに送信する実行アプリアドレス応答部１１２を有し、Ｉ／Ｆアプリケーションプログラムは、実行アプリアドレス応答部１１２から受信した接続先に、実行アプリケーションプログラムの実行依頼を送信するので、Ｉ／Ｆアプリケーションプログラムが実行アプリケーションプログラムの接続先の情報を確実に知ることができ、Ｉ／Ｆアプリケーションプログラムと実行アプリケーションプログラムとを確実に関連付けることができる。
【００８８】
また、アプリリソース制御管理サーバ１０５は、クライアント端末１０１からＩ／Ｆアプリケーションプログラムへの接続状態（実行アプリ状態管理記憶部１１５）を管理しており、アプリリソース制御管理サーバ１０５の実行アプリ破棄監視部１１３は、クライアント端末１０１がＩ／Ｆアプリケーションプログラムに接続している接続情報と、Ｉ／Ｆアプリケーションプログラムに関連付けられている実行アプリケーションプログラムの実行状態とを判定し、実行アプリケーションプログラムの実行状態４０２が処理完了（Ｃｏｍｐｌｅｔｅ）である場合、実行アプリケーションプログラムを停止し、実行アプリケーションプログラムの実行状態４０２が未実行（Ｎｏｎｅ）であり、かつ実行アプリケーションプログラムに関連付けられているＩ／Ｆアプリケーションプログラムとクライアント端末１０１との接続が切断している（セッションフラグ４０４＝Ｆａｌｓｅ）場合、実行アプリケーションプログラムを停止するので、無駄な計算機リソースの消費を低減できる。
【００８９】
また、ＨＴＴＰセッションの確立及び切断を用いて、Ｉ／Ｆアプリケーションプログラムへのクライアント端末１０１の接続数（セッション数３０３）を管理し、各クライアント端末１０１とＩ／Ｆアプリケーションプログラムとの接続状態（セッションフラグ４０４）を管理する接続監視部（セッション監視部１２１）を有するので、特別なプログラムや電文を実装することなく、クライアント端末１０１からＩ／Ｆアプリケーションプログラムへの接続数や接続状態を管理できる。
【００９０】
また、アプリリソース制御管理サーバ１０５は、クライアント端末１０１の接続数（セッション数３０３）に基づいて、Ｉ／Ｆアプリケーションプログラムが配置される処理サーバ１３０の計算機リソースを増加又は減少するので、予めＩ／Ｆアプリケーションプログラムを配置でき、Ｉ／Ｆアプリケーションプログラムの起動時間分だけリアクティブ性を向上できる。
【００９１】
また、アプリリソース制御管理サーバ１０５は、クライアント端末１０１の接続数（セッション数３０３）が所定の閾値を超えた場合、Ｉ／Ｆアプリケーションプログラムを実行中の計算機と異なる計算機（例えば、空いている処理サーバ１３０）で当該Ｉ／Ｆアプリケーションプログラムを起動するので、余裕を持ってＩ／Ｆアプリケーションプログラムを配置でき、Ｉ／Ｆアプリケーションプログラムの起動に伴う待ち時間を低減できる。
【００９２】
なお、本発明は前述した実施例に限定されるものではなく、添付した特許請求の範囲の趣旨内における様々な変形例及び同等の構成が含まれる。例えば、前述した実施例は本発明を分かりやすく説明するために詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに本発明は限定されない。また、ある実施例の構成の一部を他の実施例の構成に置き換えてもよい。また、ある実施例の構成に他の実施例の構成を加えてもよい。また、各実施例の構成の一部について、他の構成の追加・削除・置換をしてもよい。
【００９３】
また、前述した各構成、機能、処理部、処理手段等は、それらの一部又は全部を、例えば集積回路で設計する等により、ハードウェアで実現してもよく、プロセッサがそれぞれの機能を実現するプログラムを解釈し実行することにより、ソフトウェアで実現してもよい。
【００９４】
各機能を実現するプログラム、テーブル、ファイル等の情報は、メモリ、ハードディスク、ＳＳＤ（Ｓｏｌｉｄ  Ｓｔａｔｅ  Ｄｒｉｖｅ）等の記憶装置、又は、ＩＣカード、ＳＤカード、ＤＶＤ等の記録媒体に格納することができる。
【００９５】
また、制御線や情報線は説明上必要と考えられるものを示しており、実装上必要な全ての制御線や情報線を示しているとは限らない。実際には、ほとんど全ての構成が相互に接続されていると考えてよい。
【符号の説明】
【００９６】
１０１：クライアント端末、１０２：ネットワーク、１０３：フロントゲートウェイ、１０４：アプリポータルサーバ、１０５：アプリリソース制御管理サーバ、１０６：状態監視管理サーバ、１０７：アプリプログラム管理サーバ、１０８：ユーザデータ管理サーバ、１３０：処理サーバ
【図１】
2020038477.tif 000003
【図２】
2020038477.tif 000004
【図３】
2020038477.tif 000005
【図４】
2020038477.tif 000006
【図５】
2020038477.tif 000007
【図６】
2020038477.tif 000008
【図７】
2020038477.tif 000009
【図８】
2020038477.tif 000010
【図９】
2020038477.tif 000011
【図１０】
2020038477.tif 000012
【図１１】
2020038477.tif 000013