JP2024078783A - 情報処理装置及びアプリケーション起動制御方法 - Google Patents

Abstract

【課題】アプリケーションの稼働時間の節減と、ユーザエクスペリエンスの低下の防止とを両立させる。
【解決手段】本発明の一態様のコンテナ実行基盤２０は、トリガの発生を検出するトリガ監部２１２と、トリガ監視部２１２で検出されたトリガに対応付けられたトリガアプリの次に呼び出される予定の制御対象アプリの呼び出しに要する次アプリ呼び出し時間の情報と、制御対象アプリの起動に要するアプリ起動時間の情報とに基づいて、制御対象アプリの起動タイミングを決定し、該起動タイミングにおいて制御対象アプリを起動させる制御を行うアプリ起動制御部２１１と、を備える。
【選択図】図２

Description

本発明は、情報処理装置及びアプリケーション起動制御方法に関する。

近年、クラウド環境（以下、単に「クラウド」とも称する）を用いて提供されるサービスの構築において、マイクロサービスアーキテクチャの仕組みが採用されることが増えている。マイクロサービスアーキテクチャは、単一機能を持つアプリケーションを複数組み合わせることによって一つのサービスを構築する仕組みである。

マイクロサービスアーキテクチャにおいては、機能又は目的ごとにアプリケーションが作成され、作成されたアプリケーションは統合されていく。したがって、サービスの規模が大きくなるにつれて、そのサービスで用いられるアプリケーションの数も増大する。パブリッククラウドにおいては、アプリケーションを使用した量に応じて課金が行われる従量課金が採用されていることが一般的である。よって、例えばパブリッククラウドを利用する場合、アプリケーション数が増えるにつれて、クラウドでの運用コストも増大してしまう。

特許文献１には、サスペンド中の仮想マシンへのアクセスが発生しない場合においても、サスペンド中の仮想マシンを、リジューム制御してから第２の時間経過後にサスペンド制御するリフレッシュ工程と、サスペンド中の仮想マシンへのアクセスが発生した場合に、当該仮想マシンをリジューム制御するリジューム工程と、を有する仮想マシン管理プログラムが開示されている。特許文献１に記載された技術を用いれば、リクエストのない時点で仮想マシンの動作を終了させることができるため、クラウドでの運用コストを節減することができる。

特許第６０７０３５５号公報

ところで、特許文献１に記載の技術では、サスペンド中の仮想マシンへのアクセスが発生した時点で仮想マシンがリジュームされるため、ユーザへの応答において遅延が発生し、ＵＸ（ユーザエクスペリエンス）が低下することが想定される。

本発明は、上記の状況を考慮してなされたものであり、本発明の目的は、アプリケーションの稼働時間の節減と、ユーザエクスペリエンスの低下の防止とを両立させることにある。

本発明の一態様に係る情報処理装置は、クラウド環境において複数のアプリケーションを連携して動作させることによりサービスを提供する情報処理装置である。本発明の一態様に係る情報処理装置は、定義されたトリガの発生を検出するトリガ検出部と、トリガ検出部が検出したトリガに対応付けられた第１アプリケーションの次に呼び出される予定の第２アプリケーションの呼び出しに要する第１時間の情報と、第２アプリケーションの起動に要する第２時間の情報とに基づいて、第２アプリケーションの起動タイミングを決定し、該起動タイミングにおいて第２アプリケーションを起動させる制御を行うアプリ起動制御部と、を備える。

本発明の少なくとも一態様によれば、アプリケーションの稼働時間の節減と、ユーザエクスペリエンスの低下の防止とを両立させることができるようになる。
上記した以外の課題、構成及び効果は、以下の実施形態の説明により明らかにされる。

本発明の一実施形態に係る情報処理システムの概略構成例を示す図である。 本発明の一実施形態に係るコンテナ実行基盤の制御系の構成例を示すブロック図である。 本発明の一実施形態に係るユーザ端末の制御系の構成例を示すブロック図である。 本発明の一実施形態に係るアプリ情報ＤＢの構成例を示す図である。 本発明の一実施形態に係る制御対象セット情報ＤＢの構成例を示す図である。 本発明の一実施形態に係る起動トリガ情報ＤＢの構成例を示す図である。 本発明の一実施形態に係るコンテナ実行基盤によるアプリ起動制御処理の手順の例を示すフローチャートである。 本発明の一実施形態に係るアプリ起動制御部による起動対象選択処理の手順の例を示すフローチャートである。 本発明の一実施形態に係る起動遅延制御部によるアプリ起動遅延制御処理の手順の例を示すフローチャートである。 本発明の一実施形態に係るアプリ起動制御部によるアプリ停止処理の手順の例を示すフローチャートである。

以下、本発明を実施するための形態（以下、「実施形態」と称する）の例について、添付図面を参照しながら説明する。本発明は実施形態に限定されるものではなく、実施形態における種々の数値等は例示である。また、本明細書及び図面において、同一の構成要素又は実質的に同一の機能を有する構成要素には同一の符号を付することとし、重複する説明は省略する。

＜情報処理システムの概略構成＞
まず、図１を参照して、本発明の一実施形態に係る情報処理システムの構成について説明する。図１は、本発明の一実施形態に係る情報処理システム１００の概略構成例を示す図である。

図１に示すように、情報処理システム１００は、ネットワーク１０に接続されるユーザ端末３０と、クラウド４０上に設けられたコンテナ実行基盤２０と、を有する。

コンテナ実行基盤２０（情報処理装置の一例）は、ユーザ端末３０を操作するユーザに対してコンテナの技術を用いてサービスを提供する基盤であり、アプリコンテナ２５０、アプリ起動制御部２１１、トリガ監視部２１２を含む。コンテナの技術とは、アプリケーションと動作環境とを一つのパッケージにしたコンテナ（アプリコンテナ２５０）を、プロセス単位で実行させる技術である。

アプリコンテナ２５０は、それぞれ単一の機能を有する複数のアプリケーション（以下、「アプリ」とも称する）によって構成される。アプリケーションには、ユーザが閲覧、操作を行うウェブアプリケーションや、ある時刻をトリガに処理を行うバッチ処理を実行するアプリケーションなどが含まれる。なお、アプリコンテナ２５０の機能、種類はこれらに限定されず、様々なものが存在してよい。

アプリ起動制御部２１１は、アプリコンテナ２５０の各アプリケーションの起動動作、停止動作の制御を行う。
トリガ監視部２１２（トリガ検出部の一例）は、定義されたトリガの発生を監視し、トリガの発生を検知した場合に、トリガの発生をアプリ起動制御部２１１に通知する。

なお、図１には、クラウド４０上にコンテナ実行基盤２０が１つのみ設けられた例を示すが、本発明はこれに限定されず、複数のコンテナ実行基盤が設けられてもよい。また、コンテナ実行基盤２０が有するアプリコンテナ２５０、アプリ起動制御部２１１、トリガ監視部２１２、又は、その他実行される不図示の機能は、ネットワーク１０によって接続された複数のコンテナ実行基盤上に分散して配置されてもよい。また、ユーザ端末３０も１台に限定されず、複数台が設けられてもよい。

ネットワーク１０は、例えば、構内ＬＡＮ（Local Area Network）で構成される。構内ＬＡＮは、例えば、有線ＬＡＮ、無線ＬＡＮ、短距離無線等で実現される。または、構内ＬＡＮは、これらの複数の接続形式の組合せにより実現されてもよい。

ユーザ端末３０は、例えばＰＣ（Personal Computer）等により構成され、ユーザ端末３０は、アプリコンテナ２５０により提供されるサービスに関する画面を表示したり、ユーザによる操作入力を受け付けたりする、入出力インタフェース（Ｉ／Ｏ３０３：図３参照）等を備える。本実施形態では、クラウド４０上のコンテナ実行基盤２０は、ユーザに対して、従量課金制のサービスを提供する。つまり、クラウド４０上においてアプリコンテナ２５０が稼働している時間の長さに応じた利用料金が、ユーザに課金される。

＜コンテナ実行基盤の制御系の構成＞
次に、図２を参照して、コンテナ実行基盤２０の制御系の機能を実現するためのハードウェアの構成について説明する。図２は、コンテナ実行基盤２０の制御系の構成例を示すブロック図である。

図２に示すように、コンテナ実行基盤２０は、メモリ２０１、ＣＰＵ（Central Processing Unit）２０２、Ｉ／Ｏ（Input/Output：入出力インタフェース）２０３、補助記憶装置２０４、ネットワークＩ／Ｆ（Interface）２０５等を含む。

ＣＰＵ２０２は、メモリ２０１又は補助記憶装置２０４に記憶されたプログラムを実行するプロセッサである。メモリ２０１は、不揮発性の記憶素子であるＲＯＭ（Read Only Memory）及び揮発性の記憶素子であるＲＡＭ（Random Access Memory）（いずれも図示略）を含む。ＲＯＭには、例えば、ＢＩＯＳ（Basic Input Output System）などの不変のプログラムが格納される。ＲＡＭは、ＤＲＡＭ（Dynamic Random Access Memory）等の高速かつ揮発性の記憶素子で構成される。ＲＡＭには、補助記憶装置２０４に格納されたプログラム及びプログラムの実行時に使用されるデータが、一時的に格納される。

Ｉ／Ｏ２０３は、ユーザがコンテナ実行基盤２０に指示を入力する入力インタフェースであるとともに、プログラムの実行結果などをユーザに提示する出力インタフェースでもある。Ｉ／Ｏ２０３には、例えば、キーボード、マウス、タッチパネル、ディスプレイ、プリンタなどの入出力デバイス（いずれも図示略）が接続される。なお、Ｉ／Ｏ２０３に、ネットワーク１０（図１参照）を介して接続された不図示の管理端末によって提供されるユーザインタフェースが接続されてもよい。

補助記憶装置２０４は、例えば、磁気記憶装置（ＨＤＤ：Hard Disk Drive）、フラッシュメモリ（ＳＳＤ：Solid State Drive）などで構成される、大容量かつ不揮発性の記憶装置である。補助記憶装置２０４には、ＣＰＵ２０２により実行されるプログラム及びプログラムの実行時に使用されるデータが格納される。つまり、補助記憶装置２０４は、コンピュータによって実行されるプログラムを格納した、コンピュータ読取可能な非一過性の記録媒体の一例として用いられる。

本発明の機能を実現するプログラムは、補助記憶装置２０４から読み出されて、メモリ２０１にロードされ、ＣＰＵ２０２によって実行される。図２には、コンテナ実行基盤２０が有する各機能部がメモリ２０１上にロードされた状態を示す。

コンテナ実行基盤２０は、物理的に一つの計算機上、又は、論理的又は物理的な複数の計算機上で構成される計算機システムである。メモリ２０１に格納されたプログラムは、同一の計算機上で別個のスレッドで動作してもよく、複数の物理的計算機資源上に構築された仮想計算機上で動作してもよい。

また、コンテナ実行基盤２０と他の不図示の装置とが、一つの物理的又は論理的計算機に収容されてもよい。なお、プログラムの実行によって実現される処理の全部又は一部の処理は、ハードウェア（例えば、ＦＰＧＡ：Field-Programmable Gate Array）によって実現されてもよい。

ネットワークＩ／Ｆ２０５は、ＮＩＣ（Network Interface Card）等で構成され、ネットワーク１０を介して接続される他のサーバやユーザ端末３０などと通信する。

なお、本実施形態では、本発明を実現する各機能がコンテナ形式で保存されて動作する例を示すが、本発明はこれに限定されない。起動、停止等の制御を本実施形態と同様に実施できる形式であれば、仮想マシンやＦａａＳ（Function as a Service）アプリケーションなどの他の形式が用いられてもよい。

図２に示す例では、メモリ２０１上に、アプリ起動制御部２１１、トリガ監視部２１２、ルーティング制御部２１３、アプリログ取得部２１４、起動遅延制御部２１５、アプリコンテナ２５０がロードされている。さらに、メモリ２０１には、アプリ情報ＤＢ（Database）２２１、制御対象セット情報ＤＢ２２２、起動トリガ情報ＤＢ２２３に格納された各情報もロードされている。

アプリ起動制御部２１１は、トリガ監視部２１２からの通知に従い、対象のアプリコンテナ２５０の起動タイミングの制御と停止タイミングの制御とを行う。例えば、アプリ起動制御部２１１は、ユーザからのリクエストに対する待ち時間を発生させることなく、かつ、アプリケーションの稼働時間を最小限とするための制御を行う。具体的には、トリガに対応付けられたアプリケーションであるトリガアプリの次に呼び出される、制御対象のアプリケーション（以下、「制御対象アプリ」とも称する）の起動タイミングを調整する。アプリ起動制御部２１１は、制御対象アプリの起動タイミングを、トリガアプリによる制御対象アプリの呼び出し時間の情報と、制御対象アプリの起動時間の情報とに基づいて、制御対象アプリの起動タイミングを決定する。アプリ起動制御部２１１による処理の詳細については、後述の図７を参照して詳述する。

トリガ監視部２１２は、アプリログ取得部２１４によって取得されたログから、起動トリガ情報ＤＢ２２３に格納されている情報に基づいてトリガを検知し、トリガの検知をアプリ起動制御部２１１に通知する。なお、トリガ監視部２１２は、各アプリケーションから出力される信号等によってトリガを直接検知してもよい。

ルーティング制御部２１３は、アプリコンテナ２５０と起動遅延制御部２１５とを対象として、リクエストの振り分けを行う。リクエストには、ユーザにより入力されたリクエストや、他のアプリコンテナ２５０からの起動リクエストなどがある。リクエストの送信先のアプリケーションの起動が完了している場合、ルーティング制御部２１３は、リクエストをアプリコンテナ２５０に振り分ける。一方、リクエスト対象のアプリケーションが停止中又は起動準備中である場合、ルーティング制御部２１３は、起動遅延制御部２１５にリクエストを振り分ける。

アプリログ取得部２１４は、アプリコンテナ２５０が出力するログを取得して格納する。アプリログ取得部２１４が所持するログの情報は、トリガ監視部２１２など他のプログラムによって参照される。

起動遅延制御部２１５は、制御対象アプリへのトリガアプリによるリクエストの転送タイミングを制御する。具体的には、起動遅延制御部２１５は、制御対象アプリによる処理実行タイミングにおいて、制御対象アプリの起動が完了していない場合に、トリガアプリからの処理のリクエストの制御対象アプリへの送信タイミングを遅延させる制御を行う。起動遅延制御部２１５については、後述の図９を参照して詳述する。

アプリ情報ＤＢ２２１は、コンテナ実行基盤２０上で実行されるアプリコンテナ２５０の各アプリケーションの情報が格納されるデータベースである。アプリ情報ＤＢ２２１については、後述の図４を参照して詳述する。

制御対象セット情報ＤＢ２２２は、複数のアプリケーションを組み合わせて実現される処理（機能）（以下、「制御対象セット」とも称する）の情報が格納されるデータベースである。制御対象セット情報ＤＢ２２２については、後述の図５を参照して詳述する。

起動トリガ情報ＤＢ２２３は、制御対象セットの起動トリガとなる事象に関する情報が格納されるデータベースである。起動トリガ情報ＤＢ２２３については、後述の図６を参照して詳述する。

＜ユーザ端末の制御系の構成＞
次に、図３を参照して、ユーザ端末３０の制御系の機能を実現するためのハードウェアの構成について説明する。図３は、ユーザ端末３０の制御系の構成例を示すブロック図である。

図３に示すように、ユーザ端末３０は、メモリ３０１、ＣＰＵ３０２、Ｉ／Ｏ３０３、補助記憶装置３０４、ネットワークＩ／Ｆ３０５等を含む。

ＣＰＵ３０２は、メモリ３０１に格納されたプログラムを実行するプロセッサである。メモリ３０１は、不揮発性の記憶素子であるＲＯＭ及び揮発性の記憶素子であるＲＡＭ（いずれも図示略）を含む。ＲＯＭには、例えば、ＢＩＯＳなどの不変のプログラムが格納される。ＲＡＭは、ＤＲＡＭ等の高速かつ揮発性の記憶素子で構成される。ＲＡＭには、補助記憶装置３０４に格納されたプログラム及びプログラムの実行時に使用されるデータが、一時的に格納される。

具体的には、メモリ３０１には、ウェブブラウザ３１１が格納される。ウェブブラウザ３１１は、ユーザがアプリコンテナ２５０（図１参照）に含まれるウェブアプリケーション等を実行、表示する際のＵＩ（User Interface）を、ユーザに提供する。

Ｉ／Ｏ３０３は、ユーザがユーザ端末３０に指示を入力する入力インタフェースであるとともに、プログラムの実行結果などをユーザに提示する出力インタフェースでもある。Ｉ／Ｏ３０３には、例えば、例えば、キーボード、マウス、タッチパネル、ディスプレイ、プリンタなどの入出力デバイス（いずれも図示略）が接続される。なお、Ｉ／Ｏ３０３に、ネットワーク１０（図１参照）を介して接続された不図示の管理端末によって提供されるユーザインタフェースが接続されてもよい。

補助記憶装置３０４は、例えば、磁気記憶装置（ＨＤＤ）、フラッシュメモリ（ＳＳＤ）などで構成される、大容量かつ不揮発性の記憶装置である。補助記憶装置３０４には、ＣＰＵ３０２により実行されるプログラム及びプログラムの実行時に使用されるデータが格納される。つまり、補助記憶装置３０４は、コンピュータによって実行されるプログラムを格納した、コンピュータ読取可能な非一過性の記録媒体の一例として用いられる。

プログラムは、補助記憶装置３０４から読み出されて、メモリ３０１にロードされ、ＣＰＵ３０２によって実行される。図３には、ユーザ端末３０が有する各機能部がメモリ３０１上にロードされた状態を示す。

＜アプリ情報ＤＢの構成＞
次に、図４を参照して、アプリ情報ＤＢ２２１の構成について説明する。図４は、アプリ情報ＤＢ２２１の構成例を示す図である。

図４に示すように、アプリ情報ＤＢ２２１は、「アプリ識別子」、「アプリ名称」、「呼び出し元アプリ情報」、「次呼び出しアプリ情報」、「次アプリ呼び出し時間」、「アプリ起動時間」、「リクエストタイムアウト時間」及び「呼び出し回数」の各項目を有する。

「アプリ識別子」の項目には、アプリコンテナ２５０内の各アプリケーションに設定されたアプリケーション識別子の情報が格納される。図４に示す例では、アプリ識別子は、“００１”、“００２”等の３桁の数値で示される。
「アプリ名称」の項目には、アプリケーションの名称の情報が格納される。図４に示す例では、アプリケーションの名称として、“認証”、“情報登録”、“情報変更”、“変更通知”、“差分抽出”、“バックアップ”、“超過データ削除”等の名称が格納されている。

“認証”アプリは、ユーザから入力されたユーザＩＤ、パスワードを照合し、照合できた場合にユーザをシステムにログインさせるアプリケーションである。“情報登録”アプリは、ユーザによるログインの完了後に表示されるページ（図示略）において、ユーザによる登録ボタンの押下を検知した場合に、ユーザの情報をシステムに登録する機能を提供するアプリケーションである。

“情報変更”アプリは、ユーザによるログインの完了後に表示されるページ（図示略）において、ユーザによる不図示の変更ボタンの押下を検知した場合に、既に登録済みのユーザ情報を変更する機能を提供するアプリケーションである。“変更通知”アプリは、“情報変更”アプリの処理が実行されると自動的に実行されるアプリケーションであり、ユーザ情報が変更されたことをユーザに対して通知する機能を提供する。“差分抽出”アプリは、その日に登録又は変更が行われた情報を抽出する機能を提供するアプリケーションである。

“バックアップ”アプリは、“差分抽出”アプリから呼び出されるアプリケーションであり、“差分抽出”アプリによって抽出された内容をバックアップする機能を提供する。“超過データ削除”アプリも、“差分抽出”アプリから呼び出されるアプリケーションであり、予め定められた閾値よりも古いデータがバックアップデータに保存されていた場合に、そのデータを削除する機能を提供する。

「呼び出し元情報」の項目には、アプリ識別子が付与されたアプリケーションの実行のトリガとなる事象に関する情報が格納される。トリガとなる事象には、そのアプリケーションの呼び出し元となるトリガアプリの実行開始や、ユーザによる操作入力等のアクションなどがある。トリガが、特定のアプリケーションの実行開始である場合には、呼び出し元情報にはそのアプリケーションのアプリ識別子が格納される。トリガが特定のアクションである場合には、呼び出し元情報には、そのアクションを示す識別子が格納される。

図４に示す例では、呼び出し元情報の“１０００”はユーザによる入力操作を示し、“２０００”は定期的に実施されるバッチ処理を示す。例えば、“差分抽出”アプリは、バッチ処理によって定期的に（例えば、一日に一度）実行されるものであるため、“差分抽出”アプリの「呼び出し元情報」には、定期実行を示す“２０００”の識別子が格納される。なお、呼び出し元のアプリケーション又はアクションが複数ある場合には、「呼び出し元情報」にはそれらに対応する複数の識別子が格納される。

「次呼び出しアプリ情報」の項目には、アプリ識別子が付与されたアプリケーションが実行された後に実行される（呼び出される）予定の、次のアプリケーション（制御対象アプリ）の情報（アプリ識別子）が格納される。次に呼び出されるアプリケーションが複数ある場合には、「次呼び出しアプリ情報」にはそれらに対応する複数の識別子が格納される。なお、そのアプリケーションの次に呼び出されるアプリケーションが存在しない場合には、「次呼び出しアプリ情報」の欄は空欄とされる。

「次アプリ呼び出し時間」の項目には、アプリ識別子が付与されたアプリケーションの実行が開始されてから、次のアプリケーションの呼び出しが行われるまでの時間（第１時間の一例）の情報が格納される。そのアプリケーションの実行が開始してから、次のアプリケーションが呼び出されるまでの間において、ユーザによる入力操作が必要となる場合には、該入力操作に要すると想定される時間も「次アプリ呼び出し時間」に組み込まれる。なお、そのアプリケーションの「次呼び出しアプリ情報」の項目に、複数のアプリの情報が格納されている場合、「次アプリ呼び出し時間」には、複数のアプリのそれぞれに対応して複数の時間の情報が格納される。

「アプリ起動時間」の項目には、アプリ識別子が付与されたアプリケーションの起動が指示されてから起動が完了するまで（処理を開始できる状態となるまで）に要する時間（第２時間の一例）の情報が格納される。

「リクエストタイムアウト時間」の項目には、アプリ識別子が付与されたアプリケーションが出したリクエストに対する、応答の許容待ち時間の情報が格納される。例えば、あるアプリケーションに設定されたリクエストタイムアウト時間が、１０秒であるとする。そして、このアプリケーションが、次の制御対象アプリに出したリクエストに対する応答を、１０秒経った時点においても得られなかったとする。この場合、リクエストの送信元のアプリケーションの処理はタイムアウトとなり、そのアプリケーションの処理はその時点で終了となる。

「呼び出し回数」の項目には、アプリ識別子が付与されたアプリケーションが制御対象アプリとして何回呼び出されたかを示す呼び出し回数の情報が格納される。「呼び出し回数」の項目に格納される値（回数）は、アプリ起動制御部２１１（図１参照）によって増減される。具体的には、「呼び出し回数」の値は、そのアプリケーションが呼び出される都度“１”が加算され、そのアプリケーションの処理が終了した時点で“１”が減算される。

したがって、複数のアプリケーションによる呼び出しが行われており、かつ、該呼び出しに基づく処理が終了していない場合には、「呼び出し回数」の項目には２以上の数が格納される。「呼び出し回数」の項目の情報は、アプリ起動制御部２１１（図１参照）によるアプリ停止処理の実行時に参照される。アプリ停止処理については、後述の図１０を参照して詳述する。

なお、次アプリ呼び出し時間及びアプリ起動時間の情報は、各アプリケーションが行った複数回の起動、処理等に示される稼働実績に基づいて設定される。次アプリ呼び出し時間及びアプリ起動時間には、稼働実績に示される時間の平均、最大、最小等の値を設定することができる。また、これらの値にマージンとして固定値を付加した値が使用されてもよい。次アプリ呼び出し時間及びアプリ起動時間は、アプリ起動制御部２１１による処理の実施の前段階で予め設定されることを想定しているが、処理の実行中に値が更新されてもよい。

図４に示す例では、アプリ識別子が“００１”であるアプリケーションの名称は“認証”であり、“認証”アプリの呼び出し元情報は“１０００”、すなわち、ユーザによる入力操作であることが示されている。また、“認証”アプリの次に呼び出されるアプリケーションは、アプリ識別子が“００２”の“情報登録”アプリ、及び、“００３”の“情報変更”アプリであり、これらのアプリに対応付けられた「次アプリ呼び出し時間」は、それぞれ“１０秒”、“１５秒”であることが示されている。また、“認証”アプリのアプリ起動時間は“５秒”であり、リクエストタイムアウト時間は“１０秒”であり、呼び出し回数は“０（回）”であることが示されている。

また、アプリ識別子が“０２５”であるアプリケーションの名称は“差分抽出”であり、“差分抽出”アプリの呼び出し元情報は“２０００”、すなわち、定期的に実行されるバッチ処理であることが示されている。また、“差分抽出”アプリの次に呼び出されるアプリケーションは、アプリ識別子が“０２６”の“バックアップ”アプリ、及び、“０２７”の“超過データ削除”アプリであり、これらのアプリに対応付けられた「次アプリ呼び出し時間」は“２０秒”であることが示されている。また、“差分抽出”アプリのアプリ起動時間は設定されておらず、リクエストタイムアウト時間は“３０秒”であり、呼び出し回数は“０（回）”であることが示されている。

＜制御対象セット情報ＤＢの構成＞
次に、図５を参照して、制御対象セット情報ＤＢ２２２の構成について説明する。図５は、制御対象セット情報ＤＢ２２２の構成例を示す図である。

図５に示すように、制御対象セット情報ＤＢ２２２は、「制御対象セット識別子」、「制御対象セット名称」及び「制御対象アプリ」の各項目を有する。

「制御対象セット識別子」の項目には、制御対象セット、すなわち、複数のアプリケーションの組合せにより実現される処理のそれぞれに付与された識別子（制御対象セット識別子）の情報が格納される。図５に示す例では、制御対象セット識別子は、“００１”、“００２”等の３桁の数値で示される。

「制御対象セット名称」の項目には、“登録処理”、“変更処理”等の、制御対象セットに付与された名称が格納される。
「制御対象アプリ」の項目には、制御対象セットの処理において制御対象となるアプリケーション（制御対象アプリ）の情報として、アプリ識別子が格納される。

図５に示す例では、制御対象セット識別子が“００１”である制御対象セットの名称は“登録処理”であり、登録処理の制御対象セットの制御対象となるアプリケーションは、アプリ識別子が“００２”のアプリケーション（“情報登録”アプリ）であることが示されている。

また、制御対象セット識別子が“００２”である制御対象セットの名称は“変更処理”であり、変更処理の制御対象セットの制御対象となるアプリケーションは、アプリ識別子が“００３”のアプリケーション（“情報変更”アプリ）、及び、“００４”のアプリケーション（“変更通知”アプリ）であることが示されている。

＜起動トリガ情報ＤＢの構成＞
次に、図６を参照して、起動トリガ情報ＤＢ２２３の構成について説明する。図６は、起動トリガ情報ＤＢ２２３の構成例を示す図である。図６に示すように、起動トリガ情報ＤＢ２２３は、「起動トリガ識別子」、「制御対象セット情報」、「トリガアプリ」、「トリガ内容」及び「呼び出し確率」の各項目を有する。

「起動トリガ識別子」の項目には、制御対象セットの処理の起動トリガとなる事象に付与された識別子（起動トリガ識別子）が格納される。図６に示す例では、起動トリガ識別子は、“００１”、“００２”等の３桁の数値で示される。
「制御対象セット情報」の項目には、制御対象セット識別子が格納される。

「トリガアプリ」の項目には、制御対象セットの処理の起動トリガとなる事象に関連するアプリケーション（トリガアプリ）の情報として、アプリ識別子が格納される。なお、トリガアプリの項目には、制御対象セット情報ＤＢ２２２（図５参照）の「制御対象アプリ」と対応付けられた、アプリ情報ＤＢ２２１（図４対象）の「呼び出し元情報」に記載のアプリケーションの情報が、自動的に入力されてもよい。

「トリガ内容」の項目には、制御対象セットの処理の起動トリガとなる事象の情報が格納される。制御対象セットの処理の起動トリガとなる事象には、例えば、ユーザによる特定の入力処理、特定のアプリケーションから出力された特定のログの検知、特定の処理の実行等がある。
「呼び出し確率」の項目には、起動トリガとなる事象が発生した後に、制御対象セットの処理が呼び出される確率の情報が格納される。

図６に示す例では、起動トリガ識別子が“００１”である起動トリガによって起動される対象の制御対象セットは、制御対象セット識別子が“００１”の制御対象セットであることが示されている。また、制御対象セットの処理のトリガとなるトリガアプリは、アプリ識別子が“００１”のアプリケーション（“認証”アプリ）であることが示されている。また、トリガ内容は“トリガアプリの処理実行開始”であり、制御対象セットの処理の呼び出し確率は“４０％”であることが示されている。

起動トリガ情報ＤＢ２２３の「呼び出し確率」の情報は、アプリ起動制御部２１１（図１参照）による起動対象選択処理の実行時に参照される。起動対象選択処理は、トリガ監視部２１２が検知したトリガに対応付けられた制御対象アプリが複数存在する場合に、アプリ起動制御部２１１によって実行される処理である。トリガに対応付けられた制御対象アプリが複数存在する場合、アプリ起動制御部２１１は、起動トリガ情報ＤＢ２２３の「呼び出し確率」が、予め定められた所定の閾値より高いアプリケーションを、起動（制御）対象のアプリケーションとして選択する。アプリ起動制御部２１１による起動対象選択処理については、後述の図８を参照して詳述する。

＜情報処理装置によるアプリケーション起動制御処理＞
次に、図７を参照して、コンテナ実行基盤２０（図１参照）によるアプリ（アプリケーション）起動制御処理について説明する。図７は、コンテナ実行基盤２０によるアプリ起動制御処理の手順の例を示すフローチャートである。

まず、コンテナ実行基盤２０のトリガ監視部２１２は、制御対象セットの処理の起動トリガとなる事象の発生を検知し、トリガの発生をアプリ起動制御部２１１に通知する（ステップＳ１）。トリガ監視部２１２は、例えば、アプリログ取得部２１４が各アプリケーションから取得したログの情報を監視することにより、制御対象セットの処理の起動トリガとなる事象の発生を検知することができる。

次いで、アプリ起動制御部２１１は、ステップＳ１で検出された事象に関連付けられたアプリケーションが、起動トリガ情報ＤＢ２２３の「トリガアプリ」の項目にいくつ設定されているかをカウントする（ステップＳ２）。例えば、ステップＳ１で検出された制御対象セットの処理の起動トリガとなる事象が、“認証アプリ”の処理実行開始であったとする。この場合、アプリ識別子が“００１”である“認証アプリ”の、起動トリガ情報ＤＢ２２３（図６参照）の「トリガアプリ」における設定数は、２つとなる。

次いで、アプリ起動制御部２１１は、ステップＳ２でカウントした設定数は“１”であるか否かを判定する（ステップＳ３）。ステップＳ３で、設定数は“１”であると判定された場合（ステップＳ３がＹＥＳ判定の場合）、アプリ起動制御部２１１は、起動トリガ情報ＤＢ２２３より、「トリガアプリ」に対応付けられた「制御対象セット情報」を取得する（ステップＳ４）。

一方、ステップＳ３で、設定数は“２”以上であると判定された場合（ステップＳ３がＮＯ判定の場合）、アプリ起動制御部２１１は、起動対象選択処理を行う（ステップＳ５）。アプリ起動制御部２１１による起動対象選択処理については、次の図８を参照して詳述する。

ステップＳ４又はステップＳ５の処理後、アプリ起動制御部２１１は、取得した制御対象セット情報に基づいて制御対象アプリを決定する（ステップＳ６）。例えば、ステップＳ４又はステップＳ５において、「制御対象セット情報」として、制御対象セット識別子が“００１”である“登録処理”の情報が取得されたとする。この場合、アプリ起動制御部２１１は、制御対象セット情報ＤＢ２２２（図５参照）において制御対象セット識別子の“００１”と対応付けられた、アプリ識別子が“００２”であるアプリケーション（“情報登録”アプリ）を、制御対象アプリに決定する。

次いで、アプリ起動制御部２１１は、ステップＳ６で決定した制御対象アプリの、アプリ情報ＤＢ２２１（図４参照）における「呼び出し回数」の項目に、“１”を加算する（ステップＳ７）。例えば、ステップＳ６で決定された制御対象アプリに対して、複数の「トリガアプリ」が対応付けられている場合であって、それらのトリガアプリからの呼び出しが行われているとする。この場合、アプリ情報ＤＢ２２１の「呼び出し回数」の項目の数は、２以上の数となる。

次いで、アプリ起動制御部２１１は、制御対象アプリの起動のトリガとなるアプリ（トリガアプリ）の次アプリ呼び出し時間と、制御対象アプリのアプリ起動時間とに基づいて、制御アプリの起動タイミングを決定する（ステップＳ８）。例えば、制御対象アプリに決定されたアプリケーションが、アプリ識別子が“００２”の“情報登録”アプリである場合、“情報登録”アプリのトリガアプリは、アプリ情報ＤＢ２２１の「呼び出し元情報」に格納されている、アプリ識別子“００１”の“認証”アプリとなる。

そして、アプリ起動制御部２１１は、“情報登録”アプリのトリガアプリである“認証”アプリの「次アプリ呼び出し時間」の情報を、アプリ情報ＤＢ２２１から取得する。図４に示す例では、アプリ識別子が“００１”である“認証”アプリの「次アプリ呼び出し時間」には、“１０秒”及び“１５秒”の２つの情報が格納されている。“１０秒”は、「次呼び出し情報」に格納されたアプリ識別子“００２”のアプリケーション（“情報登録”アプリ）に対応付けられた「次アプリ呼び出し時間」である。“１５秒”は、「次呼び出し情報」に格納されたアプリ識別子“００３”のアプリケーション（“情報変更”アプリ）に対応付けられた「次アプリ呼び出し時間」である。

ステップＳ６で制御対象アプリに決定されたアプリケーションが、例えば“情報登録”である場合、アプリ起動制御部２１１は、トリガアプリである“認証”アプリの「次アプリ呼び出し時間」として“１０秒”の情報を取得する。さらに、アプリ起動制御部２１１は、制御対象アプリのアプリ起動時間として“５秒”の情報を取得する。アプリ情報ＤＢ２２１によれば、制御対象アプリである“情報登録”アプリのアプリ起動時間は、“５秒”であるためである。

次いで、アプリ起動制御部２１１は、トリガアプリの「次アプリ呼び出し時間」である“１０秒”から、制御対象アプリのアプリ起動時間である“５秒”を減算することにより、差分の時間である“５秒”（第３時間の一例）を算出する。そして、アプリ起動制御部２１１は、トリガアプリの処理が開始されてから差分の“５秒”が経過した時点を、制御対象アプリである“情報登録”アプリの起動タイミングに決定する。

アプリ起動制御部２１１がこのような制御を行うことにより、トリガアプリである“認証”アプリが、制御アプリである“情報登録”アプリを呼び出す場合に要する１０秒が経過する時点において、制御対象アプリである“情報登録”アプリの起動も完了させておくことができる。つまり、トリガアプリからの呼び出しが行われた時点において、制御対象アプリがまだ起動していない事態の発生を防ぐことができる。トリガアプリからの呼び出しが行われたにも関わらず、制御対象アプリが起動していない場合、制御対象アプリの起動の待ち時間が発生してしまう。本実施形態によれば、制御対象アプリの起動の待ち時間、すなわち、ユーザへの応答における遅延の発生を防ぐことができるため、ＵＸ（ユーザエクスペリエンス）の低下を防ぐことができる。

また、本実施形態では、制御対象アプリの起動が完了するタイミングと、トリガアプリによる制御対象アプリの呼び出しが完了するタイミングを略同一にすることができる。すなわち、制御対象アプリの起動後にトリガアプリによる呼び出しを待つ待ち時間が発生してしまうことを防ぐことができる。つまり、制御対象アプリが起動している時間を必要最小限の時間とすることができるため、コンテナ実行基盤２０により提供されるサービスの課金を節減することができる。したがって、本実施形態によれば、アプリケーションの稼働時間の節減と、ユーザエクスペリエンスの低下の防止とを両立させることができる。

次に、アプリ起動制御部２１１は、ステップＳ８で決定した制御対象アプリの起動タイミングまで待機した後に、制御対象アプリに対して起動を指示する（ステップＳ９）。なお、トリガアプリの次アプリ呼び出し時間が制御対象アプリの起動時間より短い場合には、アプリ起動制御部２１１は、トリガアプリの処理開始後すぐに制御対象アプリも起動させるものとする。

次いで、アプリ起動制御部２１１は、制御対象アプリの処理が実行されるまでの間に、トリガアプリの処理がタイムアウトしたかどうか、すなわち、トリガアプリのリクエストタイムアウト時間が経過したか否かを判定する（ステップＳ１０）。ステップＳ１０で、タイムアウトはしていないと判定された場合（ステップＳ１０がＮＯ判定の場合）、アプリ起動制御部２１１は、制御対象アプリの処理実行時点において、制御対象アプリの起動は完了していたかを判定する（ステップＳ１１）。

ステップＳ１１で、制御対象アプリの起動は完了していると判定された場合（ステップＳ１１がＹＥＳ判定の場合）、制御対象アプリによる処理は実行される（ステップＳ１２）。一方、ステップＳ１１で、制御対象アプリの起動は完了していないと判定された場合（ステップＳ１１がＮＯ判定の場合）、起動遅延制御部２１５（図２参照）は、アプリ起動遅延制御処理を実行する（ステップＳ１３）。起動遅延制御部２１５によるアプリ起動遅延制御処理については、後述の図９を参照して詳述する。

ステップＳ１２の処理後、又は、ステップＳ１０がＹＥＳ判定の場合、アプリ起動制御部２１１は、アプリ停止処理を実行する（ステップＳ１４）。アプリ起動制御部２１１によるアプリ停止処理については、後述の図１０を参照して詳述する。ステップＳ１４の処理後、情報処理システム１００によるアプリケーション起動制御処理は終了する。

［起動対象選択処理］
次に、図８を参照して、図７のステップＳ５で実行される起動対象選択処理について説明する。図８は、アプリ起動制御部２１１による起動対象選択処理の手順の例を示すフローチャートである。

まず、アプリ起動制御部２１１は、トリガアプリに対応付けられた制御対象セットの「呼び出し確率」の情報を、起動トリガ情報ＤＢ２２３（図６参照）から取得する（ステップＳ２１）。次いで、アプリ起動制御部２１１は、ステップＳ２１で取得した呼び出し確率が予め定められた閾値を超える制御対象セットを抽出し、該制御対象セットを起動対象として選択する（ステップＳ２２）。

例えば、呼び出し確率の閾値として“２５％”が予め設定されているとする。また、トリガアプリに対応付けられた制御対象セットは、制御対象セット識別子が“００１”である“登録処理”と、“００２”である“変更処理”であるとする。起動トリガ情報ＤＢ２２３によれば、“登録処理”の呼び出し確率は“４０％”であり、“変更処理”の呼び出し確率は“６０％”である。つまり、“登録処理”及び“変更処理”のいずれの呼び出し確率も閾値を超えている。

したがって、アプリ起動制御部２１１は、制御対象セット情報ＤＢ２２２（図５参照）において“登録処理”の制御対象セットと対応付けられた、アプリ識別子が“００２”である“情報登録”アプリを、制御対象アプリとして選択する。さらに、アプリ起動制御部２１１は、“変更処理”と対応付けられた、アプリ識別子が“００３”である“情報変更”アプリと、アプリ識別子が“００４”である“変更通知”アプリとを、制御対象アプリとして選択する。ステップＳ２２の処理後、アプリ起動制御部２１１による起動対象選択処理は終了する。

アプリ起動制御部２１１によって、アプリケーションの呼び出し確率に基づく制御対象アプリの選択が行われることにより、呼び出し確率が所定の閾値を超えたアプリケーションのみが、制御対象アプリとして選択される。したがって、例えば、トリガアプリの次のアプリケーションとして呼び出される見込みが非常に少ないアプリケーションが、制御アプリとして選択及び起動されてしまうことを防ぐことができる。このようなアプリケーションが制御対象アプリとして選択及び起動された場合であって、実際にはそのアプリケーションが使用されなかった場合、該アプリケーションの稼働時間が無駄になってしまう。本実施形態によれば、そのような動作が行われることを防げるため、課金料金を節減することができる。

なお、本実施形態では、トリガアプリの次にそのアプリケーションが呼び出される確率（予め定められた条件の一例）の情報に基づいて、制御対象アプリを決定する例を挙げたが、本発明はこれに限定されない。例えば、ユーザの情報と、そのユーザによる各アプリケーションの利用率の情報とを予め対応付けておき、ユーザによる利用率が高いアプリケーションを制御対象アプリに決定する制御が行われてもよい。

また、例えば、ユーザによる操作時間の長さと、トリガアプリの次に呼び出されるアプリケーションの種類とを対応付けておいてもよい。そして、ユーザによる操作がＸ秒以内に完了した場合にはアプリケーションＡを、Ｘ秒を超えた場合にはアプリケーションＢを選択する等のように、操作時間に対応付けられたアプリケーションを制御対象アプリに選択する制御が行われてもよい。

または、トリガアプリが処理するデータのデータ量と、トリガアプリの次に呼び出されるアプリケーションの種類とを対応付けておいてもよい。そして、トリガアプリが処理するデータ量がＹ以上である場合にはアプリケーションＣを選択する等のように、データ量に対応付けられたアプリケーションを制御対象アプリに選択する制御が行われてもよい。

つまり、制御対象アプリの決定時に判断する条件として、システムの使用用途に合った条件を設定することにより、次に呼び出されるアプリケーションが複数存在する場合における制御対象アプリの選択を、適切に行えるようになる。

［アプリ起動遅延制御処理］
次に、図９を参照して、図７のステップＳ１３で実行されるアプリ起動遅延制御処理について説明する。図９は、起動遅延制御部２１５（図２参照）によるアプリ起動遅延制御処理の手順の例を示すフローチャートである。

アプリ起動遅延制御処理は、トリガアプリのタイムアウトまでの間に制御対象アプリの起動が完了していない場合に実行される処理である。タイムアウトまでの時間内に制御対象アプリの起動が完了していない場合、アプリ起動制御部２１１は、ルーティング制御部２１３に対して、トリガアプリからのリクエストの起動遅延制御部２１５への仕分けを指示する。この指示が実行された場合、起動遅延制御部２１５は、ルーティング制御部２１３からのリクエストを受け付ける（ステップＳ３１）。次いで、起動遅延制御部２１５は、起動トリガ情報ＤＢ２２３の「トリガアプリ」に格納されたアプリケーションのリクエストタイムアウト時間の情報を、アプリ情報ＤＢ２２１（図４参照）から取得する（ステップＳ３２）。例えば、トリガアプリが、アプリ識別子が“０２５”の“差分抽出”アプリであるとする。この場合、起動遅延制御部２１５は、ステップＳ３２において“３０秒”の情報を取得する。

次いで、起動遅延制御部２１５は、トリガアプリに対応付けられた制御対象アプリが起動完了するまでの時間（アプリ起動時間）の情報を、アプリ情報ＤＢ２２１から取得する（ステップＳ３３）。アプリ情報ＤＢ２２１において、“差分抽出”アプリの「次呼び出し情報」には、アプリ識別子が“０２６”の“バックアップ”アプリと、アプリ識別子が“０２７”の“超過データ削除”アプリとが対応付けられている。そして、アプリ情報ＤＢ２２１によれば、アプリ識別子が“０２６”の“バックアップ”アプリと、アプリ識別子が“０２７”の“超過データ削除”アプリに設定された「アプリ起動時間」は、それぞれ“５秒”である。したがって、起動遅延制御部２１５は、ステップＳ３３において“５秒”の情報を取得する。

次いで、起動遅延制御部２１５は、トリガアプリのタイムアウト前、すなわち、トリガアプリに設定されたリクエストタイムアウト時間が到来するまでの間に、制御対象アプリの起動は完了するか否かを判定する（ステップＳ３４）。ステップＳ３２で取得したリクエストタイムアウト時間は“３０秒”であり、ステップＳ３３で取得したアプリ起動時間は“５秒”である場合、制御対象アプリである“差分抽出”アプリ及び“超過データ削除”アプリの各起動は、いずれもトリガアプリのタイムアウト前に完了することが分かる。この場合、ステップＳ３４はＹＥＳ判定となる。

ステップＳ３４がＹＥＳ判定の場合、起動遅延制御部２１５は、制御対象アプリの起動が完了するまでの間、制御対象アプリへのリクエストの送信を実行せず、制御対象アプリの起動完了後に、制御対象アプリへのリクエストを転送する（ステップＳ３５）。ステップＳ３５の処理が行われることにより、制御対象アプリへのリクエストの送信が、制御対象アプリの起動完了後に実行されるようになる。

一方、ステップＳ３４で、トリガアプリのタイムアウト前に制御対象アプリの起動は完了しないと判定された場合（ステップＳ３４がＮＯ判定の場合）、起動遅延制御部２１５は、制御対象アプリの起動完了までに要する時間の情報を含むエラー応答を、トリガアプリに送信する（ステップＳ３６）。

次いで、トリガアプリは、エラー応答に記載された制御対象アプリの起動完了タイミングまで待機し、待機完了後に、制御対象アプリに対して再度リクエストを送信する（ステップＳ３７）。起動遅延制御部２１５によってこのような制御が行われることにより、例えば、イレギュラーな動作が行われたことにより、想定より早いタイミングでトリガアプリからリクエストが発行された場合であっても、リクエストの対象となる制御対象アプリの起動が完了した後に、トリガアプリから制御対象アプリへのリクエストが発行される。したがって、本実施形態によれば、リクエストの対象となる制御対象アプリが起動していないことによるエラーの発生を防ぐことができる。ステップＳ３５又はステップＳ３７の処理後、起動遅延制御部２１５によるアプリ起動遅延制御処理は終了する。

なお、ステップＳ３４で、タイムアウト前に制御対象アプリの起動は完了しないと判定された場合、起動遅延制御部２１５による制御を行わずに、単純にエラーを発生させる制御が行われてもよい。この場合、エラーが通知されたトリガアプリによって、制御対象アプリへのリクエスト発行のリトライが行われることになる。

［アプリ停止処理］
次に、図１０を参照して、図７のステップＳ１４で実行されるアプリ停止処理について説明する。図１０は、アプリ起動制御部２１１によるアプリ停止処理の手順の例を示すフローチャートである。

図１０に示すアプリ停止処理は、図７のステップＳ５の起動対象選択処理において、起動対象として選択された制御対象アプリのそれぞれを対象として行われる。まず、アプリ起動制御部２１１は、アプリ停止処理の対象となる制御アプリの「呼び出し回数」から“１”減算する（ステップＳ４１）。

次いで、アプリ起動制御部２１１は、アプリ停止処理の対象となる制御アプリの「呼び出し回数」を確認する（ステップＳ４２）。次いで、アプリ起動制御部２１１は、呼び出し回数は“０回”であるか否かを判定する（ステップＳ４３）。ステップＳ４３で、「呼び出し回数」は“０回”であると判定された場合（ステップＳ４３がＹＥＳ判定の場合）、アプリ起動制御部２１１は、アプリ停止処理の対象となっている制御アプリの動作を停止する（ステップＳ４４）。ステップＳ４４の処理後、アプリ起動制御部２１１によるアプリ停止処理は終了する。

一方、ステップＳ４３で、「呼び出し回数」は“０回”ではない、すなわち、“１”以上であると判定された場合（ステップＳ４３がＮＯ判定の場合）、アプリ起動制御部２１１は、アプリ停止処理を終了する。

トリガアプリの処理開始が複数回実施された場合や、複数のトリガアプリからの呼び出しがあった場合であって、呼び出しに基づく処理が終了していない場合には、制御対象アプリの呼び出し回数は“１回”以上の数となる。呼び出し回数が“１回”以上である場合、該当する制御対象アプリは、いずれかのトリガアプリからのリクエストに基づく処理を実行中である可能性が高いため、アプリ起動制御部２１１は、このアプリケーションをアプリ停止処理の対象から外す。そして、「呼び出し回数」が“０回”になった時点で、該アプリケーションを停止させる。

アプリ起動制御部２１１によってこのような制御が行われることにより、実行中のアプリケーション、又は、処理の実行待ちの状態にあるアプリケーションが誤って停止されてしまうことを防ぐことができる。

＜アプリ起動制御処理の具体例＞
次に、図７に示したアプリ起動制御処理（図８に示した起動対象選択処理、図９に示したアプリ起動遅延制御処理、図１０に示したアプリ停止処理を含む）について、具体例を挙げて説明する。
［具体例１］
まず、具体例１として、トリガ監視部２１２がトリガを検知したアプリケーションが、アプリ識別子が“００１”の“認証”アプリである場合を例に挙げる。以下に説明する具体例１においては、アプリケーションの呼び出し確率の閾値には“２５％”が設定されており、トリガの検知時点におけるすべてのアプリケーションの呼び出し回数は“０回”であるものとする。

まず、ユーザによる入力操作に基づいて、“認証”アプリが実行されたとする。“認証”アプリは、起動トリガ情報ＤＢ２２３（図６参照）の「トリガアプリ」に格納されたアプリケーションであるため、トリガ監視部２１２は、制御対象セットの処理の起動トリガとなる事象の発生、すなわち、“認証”アプリの実行を検知する（図７のステップＳ１）。

次いで、アプリ起動制御部２１１は、起動トリガのアプリケーションのトリガアプリとしての設定数をカウントする（ステップＳ２）。起動トリガ情報ＤＢ２２３において、アプリ識別子が“００１”である“認証”アプリは、「トリガアプリ」の項目に２つ登録されている。したがって、次のステップＳ３における「設定数は１？」の判定においては、“ＮＯ”が選択される。これにより、アプリ起動制御部２１１による起動対象選択処理が行われる（ステップＳ５）。

アプリ起動制御部２１１は、起動対象選択処理において、まず、起動トリガ情報ＤＢ２２３より、トリガアプリに対応付けられた制御対象セットの呼び出し確率の情報を取得する（図８のステップＳ２１）。トリガアプリに対応付けられた制御対象セットは、制御対象セット識別子が“００１”である“登録処理”と、“００２”である“変更処理”である。したがって、ステップＳ２１では、アプリ起動制御部２１１は、“登録処理”の呼び出し確率である“４０％”と、“変更処理”の呼び出し確率である“６０％”の各情報を取得する。

そして、これらの２つの呼び出し確率は、予め定められた閾値である“２５％”を超えているため、アプリ起動制御部２１１は、次のステップＳ２２において、“登録処理”及び“変更処理”の２つの制御対象セットを、起動対象の制御対象セットとして選択する。

制御対象セット情報ＤＢ２２２（図５参照）によれば、制御対象セット識別子が“００１”である“登録処理”の制御対象アプリは、アプリ識別子が“００２”である“情報登録”アプリである。また、制御対象セット識別子が“００２”である“変更処理”の制御対象アプリは、アプリ識別子が“００３”である“情報変更”アプリ、及び、アプリ識別子が“００４”である“変更通知”アプリである。したがって、起動対象選択処理の次に行われる、図７のステップＳ６では、アプリ起動制御部２１１は、“登録処理”アプリ、“情報変更”アプリ及び“情報通知”アプリの３つアプリケーションを、制御対象アプリとして選択する。

次いで、アプリ起動制御部２１１は、制御対象アプリに設定したこれらのアプリケーションの「呼び出し回数」に、それぞれ“１”を加算する（ステップＳ７）。次いで、アプリ起動制御部２１１は、トリガアプリの次アプリ呼び出し時間と、制御対象アプリのアプリ起動時間とに基づいて、制御対象アプリの起動タイミングを決定する（ステップＳ８）。そして、決定した起動タイミングの到来時に、制御対象アプリを起動させる（ステップＳ９）。

例えば、制御対象に設定されたアプリケーションが、アプリ識別子が“００２”の“情報登録”アプリである場合を想定する。アプリ情報ＤＢ２２１によれば、“情報登録”アプリのトリガアプリである、アプリ識別子が“００１”の“認証”アプリの「次アプリ呼び出し時間」は“１０秒”である。また、制御対象アプリに設定された“情報登録”アプリの「アプリ起動時間」は“５秒”である。したがって、アプリ起動制御部２１１は、トリガアプリの“認証”アプリが実行を開始してから５秒後のタイミングを、“情報登録”アプリの起動タイミングに決定する。

例えば、ユーザによる操作に基づいて“認証”アプリによるログイン処理が実行され、ログイン処理から１２秒が経過したタイミングにおいて、ユーザによる情報の登録操作が行われたとする。この場合、ログイン処理から１２秒が経過した時点においては、“情報登録”アプリは既に起動しているため、情報登録処理は予定通り実行される（ステップＳ１２）。

その後、アプリ起動制御部２１１によってアプリ停止処理が行われる（ステップＳ１４）。アプリ停止処理では、“情報登録”アプリ、“情報変更”アプリ及び“変更通知”アプリのそれぞれにおいて、「呼び出し回数」から“１”が減算される（図１０のステップＳ４１）。

これらのアプリケーションの「呼び出し回数」は、アプリ起動制御処理の実行前にはすべて“０”であったため、図７のステップＳ７で加算された“１”が減算されることにより、「呼び出し回数」は“０”となる。したがって、ステップＳ４３はＹＥＳ判定となり、“情報登録”アプリ、“情報変更”アプリ及び“変更通知”アプリのそれぞれの動作が停止される（図１０のステップＳ４４）。

［具体例２］
次に、具体例２として、トリガ監視部２１２がトリガとして、アプリ識別子が“０２５”の“差分抽出”アプリの実行タイミングの到来を検知した場合を例に挙げる。以下に説明する具体例２においても、アプリケーションの呼び出し確率の閾値には“２５％”が設定されており、トリガの検知時点におけるすべてのアプリケーションの呼び出し回数は“０回”であるものとする。

まず、アプリ識別子が“０２５”の“差分抽出”アプリが指定の時刻に自動的に実行されると、アプリ起動制御部２１１は、起動トリガとなるアプリケーションのトリガアプリとしての設定数をカウントする（図７のステップＳ２）。起動トリガ情報ＤＢ２２３において、アプリ識別子が“０２５”である“差分抽出”アプリは、「トリガアプリ」の項目において２つ登録されている。したがって、次のステップＳ３における「設定数は１？」の判定においては、“ＮＯ”が選択される。これにより、アプリ起動制御部２１１は起動対象選択処理を行う（ステップＳ５）。

アプリ起動制御部２１１は、起動対象選択処理において、まず、起動トリガ情報ＤＢ２２３より、トリガアプリに対応付けられた制御対象セットの呼び出し確率の情報を取得する（図８のステップＳ２１）。トリガアプリである“差分抽出”に対応付けられた制御対象セットは、制御対象セット識別子が“００８”である“バックアップ処理”と、“００９”である“期限超過データ削除処理”である。したがって、ステップＳ２１では、アプリ起動制御部２１１は、“バックアップ処理”の呼び出し確率である“７０％”、及び、“期限超過データ削除処理”の呼び出し確率である“１０％”の各情報を取得する。

そして、これらの２つの呼び出し確率のうち、“期限超過データ削除処理”の呼び出し確率である“１０％”は、予め定められた閾値である“２５％”を下回る。一方、“バックアップ処理”の呼び出し確率である“７０％”は、予め定められた閾値である“２５％”を上回る。したがって、アプリ起動制御部２１１は、呼び出し確率が閾値を上回る“バックアップ処理”を、起動対象の制御対象セットとして選択する（図８のステップＳ２２）。

制御対象セット情報ＤＢ２２２（図５参照）によれば、制御対象セット識別子が“００８”である“バックアップ処理”の制御対象アプリは、アプリ識別子が“０２６”である“バックアップ”アプリである。したがって、起動対象選択処理の次に行われる、図７のステップＳ６では、アプリ起動制御部２１１は、“バックアップ”アプリを、制御対象アプリとして選択する。

次いで、アプリ起動制御部２１１は、制御対象アプリに設定したアプリケーション（“バックアップ”アプリ）の「呼び出し回数」に“１”を加算する（ステップＳ７）。次いで、アプリ起動制御部２１１は、トリガアプリの次アプリ呼び出し時間と、制御対象アプリのアプリ起動時間とに基づいて、制御対象アプリの起動タイミングを決定する（ステップＳ８）。そして、決定した起動タイミングの到来時に、制御対象アプリを起動させる（ステップＳ９）。

“バックアップ”アプリのトリガアプリである、アプリ識別子が“０２５”の“差分抽出”アプリの「次アプリ呼び出し時間」は“２０秒”である。また、制御対象アプリに設定された“バックアップ”アプリの「アプリ起動時間」は“５秒”である。したがって、アプリ起動制御部２１１は、トリガアプリの“差分抽出”アプリが実行を開始してから１５秒（２０秒－５秒）後のタイミングを、“バックアップ”アプリの起動タイミングに決定する。

アプリ識別子が“０２５”の差分抽出処理は、通常２０秒後に次の処理が呼び出すが、例えば、抽出すべき差分情報が極端に少なかったこと等に起因して、１０秒が経過した時点で次のアプリケーションを呼び出したとする。この場合、トリガアプリである“差分抽出”アプリが実行を開始してから１５秒後に起動を開始する予定の、次の“バックアップ”アプリは、まだ起動していない。

この場合、図７のステップＳ１１はＮＯ判定となり、アプリ起動遅延制御処理が実行される（ステップＳ１３）。アプリ起動遅延制御処理において、起動遅延制御部２１５（図２参照）は、ルーティング制御部２１３からのリクエストを受け付ける（図９のステップＳ３１）。次のステップＳ３２において、起動遅延制御部２１５は、トリガアプリの“差分抽出”アプリのリクエストタイムアウト時間として“３０”秒を取得する。そして、その次のステップＳ３３において、起動遅延制御部２１５は、制御対象アプリが起動完了するまでの時間（アプリ起動時間）として、“５秒”を取得する。

次いで、起動遅延制御部２１５は、トリガアプリである“差分抽出”アプリがタイムアウトするまでの間に、制御対象アプリである“バックアップ”アプリの起動が完了するか否かを判定する（ステップＳ３４）。ステップＳ３２及びステップＳ３３で取得した情報に基づき、“差分抽出”アプリがタイムアウトするまでの間に、制御対象アプリである“バックアップ”アプリの起動は完了すると判定される（ステップＳ３４がＹＥＳ判定）。

したがって、起動遅延制御部２１５は、“バックアップ”アプリの起動に要する５秒間リクエストを保持した後に、制御対象アプリである“バックアップ”アプリにリクエストを転送する（ステップＳ３５）。これにより、制御対象アプリである “バックアップ”アプリは、自身の起動が完了した後に、“差分抽出”アプリからのリクエストを受け付けることができる。

そして、起動遅延制御部２１５によるアプリ起動遅延制御処理の次に行われる図７のステップＳ１２において、バックアップ処理が実行され、次のステップＳ１４において、“バックアップ”アプリが停止されてバックアップ処理は終了される。

なお、上述した実施形態は本発明を分かりやすく説明するために装置及びシステムの構成を詳細且つ具体的に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。

また、図１において実線で示した制御線又は情報線は説明上必要と考えられるものを示しており、製品上必ずしも全ての制御線や情報線を示しているとは限らない。実際には殆ど全ての構成が相互に接続されていると考えてもよい。

また、本明細書において、時系列的な処理を記述する処理ステップは、記載された順序に沿って時系列的に行われる処理はもちろん、必ずしも時系列的に処理されなくとも、並列的あるいは個別に実行される処理（例えば、並列処理あるいはオブジェクトによる処理）をも含むものである。

２０…コンテナ実行基盤、３０…ユーザ端末、４０…クラウド、１００…情報処理システム、２１１…アプリ起動制御部、２１２…トリガ監視部、２１３…ルーティング制御部、２１４…アプリログ取得部、２１５…起動遅延制御部、２２１…アプリ情報ＤＢ、２５０…アプリコンテナ、２２１…アプリ情報ＤＢ、２２２…制御対象セット情報ＤＢ、２２３…起動トリガ情報ＤＢ

Claims (9)

1. クラウド環境において複数のアプリケーションを連携して動作させることによりサービスを提供する情報処理装置であって、
   定義されたトリガの発生を検出するトリガ検出部と、
   前記トリガ検出部が検出した前記トリガに対応付けられた第１アプリケーションの次に呼び出される予定の第２アプリケーションの呼び出しに要する第１時間の情報と、前記第２アプリケーションの起動に要する第２時間の情報とに基づいて、前記第２アプリケーションの起動タイミングを決定し、該起動タイミングにおいて前記第２アプリケーションを起動させる制御を行うアプリ起動制御部と、を備える
   情報処理装置。
2. 前記第１時間は、前記第１アプリケーションの実行開始から、前記第１アプリケーションによる前記第２アプリケーションの呼び出しが実行されるまでの時間であり、
   前記アプリ起動制御部は、前記第１時間から前記第２時間を減算した時間である第３時間を算出し、前記第１アプリケーションの実行開始後から前記第３時間が経過した時点を、前記第２アプリケーションの起動タイミングに決定する
   請求項１に記載の情報処理装置。
3. 前記アプリ起動制御部は、前記第１アプリケーションに対応付けられた前記第２アプリケーションが複数存在する場合、予め定められた条件を満たすアプリケーションを起動対象として選択する
   請求項２に記載の情報処理装置。
4. 前記条件は、前記第１アプリケーションによる呼び出しが実行される確率が所定の閾値を超えるという条件である
   請求項３に記載の情報処理装置。
5. 前記アプリ起動制御部は、前記第１アプリケーションによる前記第２アプリケーションの呼び出し回数の情報を管理し、前記呼び出し回数は、前記第１アプリケーションによる前記第２アプリケーションの呼び出しが行われた場合に１加算され、前記第２アプリケーションの実行が完了した時点で１減算され、
   前記アプリ起動制御部は、前記呼び出し回数が０になったことを確認後に前記第２アプリケーションの動作を停止させる
   請求項２に記載の情報処理装置。
6. 前記第２アプリケーションによる処理実行タイミングにおいて、前記第２アプリケーションの起動が完了していない場合に、前記第１アプリケーションからの処理のリクエストの前記第２アプリケーションへの送信タイミングを遅延させる起動遅延制御部をさらに備える
   請求項２に記載の情報処理装置。
7. 前記起動遅延制御部は、前記第１アプリケーションに設定されたタイムアウト時間が経過するまでの間に、前記第２アプリケーションの起動が完了すると判定した場合、前記第２アプリケーションの起動が完了した後に、前記第１アプリケーションからの処理のリクエストを前記第２アプリケーションに送信する
   請求項６に記載の情報処理装置。
8. 前記起動遅延制御部は、前記第１アプリケーションに設定されたタイムアウト時間が経過するまでの間に、前記第２アプリケーションの起動が完了しないと判定した場合、前記第２アプリケーションの起動完了までに要する時間の情報を前記第１アプリケーションに通知し、
   前記第１アプリケーションは、前記第２アプリケーションの起動完了時間まで待機後に、処理のリクエストを前記第２アプリケーションに送信する
   請求項６に記載の情報処理装置。
9. クラウド環境において複数のアプリケーションを連携して動作させることによりサービスを提供する情報処理装置によるアプリケーション起動制御方法であって、
   定義されたトリガの発生を検出するトリガ検出手順と、
   前記トリガ検出手順によって検出された前記トリガに対応付けられた第１アプリケーションの次に呼び出される予定の第２アプリケーションの呼び出しに要する第１時間の情報と、前記第２アプリケーションの起動に要する第２時間の情報とに基づいて、前記第２アプリケーションの起動タイミングを決定し、該起動タイミングにおいて前記第２アプリケーションを起動させる制御を行うアプリ起動手順と、を有する
   アプリケーション起動制御方法。

Images