情報処理装置、情報処理方法及びプログラム
【課題】ＡＰＰの動作品質や、レスポンスタイムを含んだサービスレベルに関する品質を保証する技術を提供することを目的とする。
【解決手段】実行要求に係るアプリケーションに対応する、アプリケーションの動作に関する動作情報を読み込む読み込み手段と、読み込み手段で読み込まれた動作情報に基づいて、アプリケーションを動作させる実行環境を構築する構築手段と、を有することによって課題を解決する。
【解決手段】実行要求に係るアプリケーションに対応する、アプリケーションの動作に関する動作情報を読み込む読み込み手段と、読み込み手段で読み込まれた動作情報に基づいて、アプリケーションを動作させる実行環境を構築する構築手段と、を有することによって課題を解決する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、情報処理装置、情報処理方法及びプログラムに関する。
【背景技術】
【０００２】
近年、システムインフラストラクチャーリソースの有効活用を目指すために、システムインフラストラクチャーのユーティリティ化やクラウド化が進んでいる。その結果、従来の、アプリケーション（以下、ＡＰＰという）が特定のシステムインフラストラクチャーで実行されているシステムと違い、ＡＰＰが実行される環境をユニークに特定できないことはもとより、ＡＰＰがどこで実行されているのかもインフラストラクチャーの空き状況により異なるシステムが存在する。
【０００３】
一方、ＡＰＰは、複雑化しており、ＡＰＰが使用される使用環境を考慮しないでシステム構築等がなされることもある。つまり本来であれば、実使用環境下でＡＰＰの連携テスト等を行うべきであるが、そのようなテスト環境を設定することも容易ではなく、ＡＰＰの単体テストだけを行ってシステム構築されることも少なくない。また、あるＡＰＰを性能Ｘのサーバ１０台で実行することを想定して開発した場合であっても、そのＡＰＰを実行するときには性能Ｘより高性能なサーバが開発され、このようなサーバが投入され、リソースが余ってしまうこともあれば、サーバの性能の向上に伴い、サーバの数が８台に減らされる場合もある。しかも、システムインフラストラクチャーのユーティリティ化によって、ＡＰＰがいつどのサーバに割り当てられるかも分からないし、どこのどのようなストレージにデータが格納されてしまうかもシステムインフラストラクチャーのクラウド化によって分からなくなってきている。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特許第２５２１０２０号明細書
【発明の概要】
【発明が解決しようとする課題】
【０００５】
上述したように、ＡＰＰの開発時と異なる実行環境でＡＰＰが動作する可能性がある。つまり、ＡＰＰの実行環境が開発環境と異なった場合のＡＰＰの動作に関する品質が保証されていない問題があった。例えば、実行環境においてレスポンスタイムの低下やシステムのサービスレベルの低下が発生してしまうという問題があった。
【０００６】
本発明はこのような問題点に鑑みなされたもので、ＡＰＰの動作品質や、レスポンスタイムを含んだサービスレベルに関する品質を保証する技術を提供することを目的とする。
【課題を解決するための手段】
【０００７】
そこで、本発明の情報処理装置は、実行要求に係るアプリケーションに対応する、前記アプリケーションの動作に関する動作情報を読み込む読み込み手段と、前記読み込み手段で読み込まれた前記動作情報に基づいて、前記アプリケーションを動作させる実行環境を構築する構築手段と、を有する。
【０００８】
本発明の情報処理装置は、実行要求に係るアプリケーションに対応する、前記アプリケーションの動作に関する動作情報を読み込む読み込み手段と、前記読み込み手段で読み込まれた前記動作情報に基づいて、前記アプリケーションを動作させる実行環境を構築する構築手段と、を有することにより、例えば、ＡＰＰの実行環境等の情報を含む動作情報に基づいて、構築された実行環境でＡＰＰを動作させることが可能なので、ＡＰＰの実行環境が開発環境と異なった場合でもＡＰＰの動作に関する品質を保証する技術を提供することができる。
【０００９】
なお、情報処理装置とは、例えば、後述するサーバ装置２、又はクライアント装置１等に対応する。より具体的に説明すると、後述する実施形態１のように本発明を、ユーティリティシステムを含むシステムに適用する場合、情報処理装置は、例えば後述するサーバ装置２に対応する。また、後述する実施形態５のように本発明を、ＰＣ、単体に適用する場合、情報処理装置は、例えば後述するクライアント装置（ＰＣ）に対応する。
また、動作情報とは、例えば、後述するＴａｇ情報に対応する。
【００１０】
また、本発明の情報処理方法は、情報処理装置が、実行要求に係るアプリケーションに対応する、前記アプリケーションの動作に関する動作情報を読み込む読み込みステップと、前記情報処理装置が、前記読み込みステップで読み込まれた前記動作情報に基づいて、前記アプリケーションを動作させる実行環境を構築する構築ステップと、を含む。
【００１１】
また、本発明のプログラムは、コンピュータを、実行要求に係るアプリケーションに対応する、前記アプリケーションの動作に関する動作情報を読み込む読み込み手段と、前記読み込み手段で読み込まれた前記動作情報に基づいて、前記アプリケーションを動作させる実行環境を構築する構築手段と、して機能させる。
【発明の効果】
【００１２】
本発明によれば、ＡＰＰの動作品質や、レスポンスタイムを含んだサービスレベルに関する品質を保証する技術を提供することができる。
【図面の簡単な説明】
【００１３】
【図１】本実施形態で説明するシステムのシステム構成の一例を示す図である。
【図２】サーバ装置のハードウェア構成の一例を示す図である。
【図３】サーバ装置の機能構成の一例を示す図（その１）である。
【図４】ＡＰＰプロビジョニングエンジンの処理の一例を示すフローチャート（その１）である。
【図５】ＡＰＰプロビジョニングエンジンの処理を説明するための図である。
【図６】Ｔａｇ情報の一例を示す図である。
【図７】アプリケーションＡのＴａｇ情報の一例を示す図である。
【図８】アプリケーションＢのＴａｇ情報の一例を示す図である。
【図９】アプリケーションＣのＴａｇ情報の一例を示す図である。
【図１０】ＡＰＰプロビジョニングエンジンにおける実行環境の構築を説明するための図である。
【図１１】サーバ装置の機能構成の一例を示す図（その２）である。
【図１２】ＡＰＰプロビジョニングエンジンの処理の一例を示すフローチャート（その２）である。
【図１３】ユーザごとの利用可能なＡＰＰ及び選択可能な処理性能を格納したテーブルを示す図である。
【図１４】アプリケーションの性能情報と動作環境とが対応付けられて記述されたＴａｇ情報を示す図である。
【図１５】クライアント装置のハードウェア構成の一例を示す図である。
【発明を実施するための形態】
【００１４】
以下、本発明の実施形態について図面に基づいて説明する。
【００１５】
なお、本明細書中では、ユーティリティシステムとは、ＣＰＵや記憶装置（記憶媒体）等のシステムリソースを自由に追加／削除できるシステムのことをいう。また、クラウドシステムとは、インターネット上に分散した各種リソースを使ってサービスを提供する（又は、サービスの提供を受ける）システムのこという。クラウドシステムでは、ユーザはクライアントコンピュータ（ＰＣ）だけを持っていればよく、アプリケーションはネットの向こう側（クラウドシステム側）から提供され、情報も向こう側（クラウドシステム側）が管理する。
【００１６】
＜実施形態１＞
図１は、本実施形態で説明するシステムのシステム構成の一例を示す図である。
図１に示されるように、クライアント装置１は、ユーティリティシステム（又は、ユーティリティシステム＋クラウドシステム等）とネットワークを介して通信可能に接続されている。なお、図１では説明の簡略化のためクライアント装置１は、１つのみとしているが複数のクライアント装置がネットワークに接続されていてもよい。また、説明の簡略化のため、以下に示す実施形態ではクライアント装置１は、ユーティリティシステムとネットワークを介して通信可能に接続されているものとする。
ユーティリティシステムは、後述するように複数の物理ソース（ハードウェア等）を含み、これらを管理している。なお、ユーティリティシステム全体の制御は、サーバ装置２が行っているものとする。サーバ装置２は単体の場合もあるが、クラウドシステム中に複数存在し、それぞれが互いに通信しながら制御を行ってもよい。また、本明細書では、クライアント装置、サーバ装置、或いはユーティリティシステムなど、ハードウェアの形態についていくつかの表現を用いているが、これはあくまでも理解を助けるものであり、ＡＰＰの利用を要求する側をクライアント装置、ＡＰＰの機能を提供する側をサーバ装置と仮に呼ぶこととする。ある装置が物理的にクライアント装置とサーバ装置を兼ねていたり、更にその装置がユーティリティシステムを構成する装置のうちの一つとして存在していたりしてもよい。
【００１７】
図２は、サーバ装置のハードウェア構成の一例を示す図である。図２に示されるようにサーバ装置２は、ハードウェア構成として、ＣＰＵ１１を含む。
ＣＰＵ１１が、記憶装置１２に記憶されている、プログラム（例えば、APPプロビジョニングエンジンプログラム）に基づき処理を行うことによって、サーバ装置２の機能、又は後述するフローチャートに係る処理を実現する。
【００１８】
また、ＣＰＵ１１には、バスを介して、記憶装置１２が接続されている。記憶装置１２は、例えば、ＲＯＭ、ＲＡＭ、ハードディスク装置等からなり、上述した各プログラム以外に、プログラムに基づく処理で用いられるデータを記憶する。
【００１９】
図３は、サーバ装置の機能構成の一例を示す図（その１）である。図３に示されるように、サーバ装置２は、ＣＰＵ１１が、プログラムを実行することによって実現されるＡＰＰプロビジョニングエンジン２１を機能構成として含む。
また、ＡＰＰプロビジョニングエンジン２１は、機能として、読み込み部３１と、構築部３２と、を含む。
【００２０】
読み込み部３１は、クライアント装置１等から実行要求されたＡＰＰに対応する、Ｔａｇ情報を読み込む。なお、本実施形態では、Ｔａｇ情報は、ＡＰＰの特定の位置に格納されているものとする。
ここで、Ｔａｇ情報は、例えば、以下のような情報を含む
・ＡＰＰ識別子（単体動作 ｏｒ ＳＯＡモジュール ｏｒ ライブラリ等）
・オブジェクトの種類（機械語 ｏｒ インタープリター使用［ＯＳ依存 ｏｒ 非依存］）
−機械語の場合は、ＣＰＵの種類（ＩＡ−８６ ｏｒ Ｉｔａｎｉｕｍ ｏｒ Ｓｐａｒｃ ｏｒ ＩＢＭ−Ｐ等）
・動作ＯＳ情報（ＯＳ識別子 ａｎｄ Ｖｅｒ識別子 ａｎｄ パッチ識別子等）
・コード形式
・インタープリターの種類
・動作Ｍｉｄｄｌｅｗａｒｅ情報１（ＤＢの種類 ａｎｄ ＡＰＰ実行環境の種類等）
・動作Ｍｉｄｄｌｅｗａｒｅ情報２（Ｖｅｒ識別子 ａｎｄ パッチ識別子）
・サービスレベル情報１（レスポンスタイム ｏｒ アベイラビリティタイム等）
・サービスレベル情報２（使用ＣＰＵリソース量 ｏｒ メモリー使用量等）
・バックアップアーカイブ情報
・関連Ｔａｇ（当該Ｔａｇに関連する別のＴａｇ）
なお、Ｔａｇ情報は、上記全ての情報を含まなくてもよく、上記情報の一部のみを含んでもよい。
【００２１】
構築部３２は、読み込み部３１が読み込んだＴａｇ情報に基づいて、断片化された仮想化リソースを組み合わせ、ＡＰＰを動作させる実行環境を構築する。また、構築部３２は、読み込み部３１が読み込んだＴａｇ情報に基づいて、断片化された仮想化リソースを組み合わせ、ＡＰＰを動作させる実行環境を構築することができなかった場合は、例えばＡＰＰが動作可能な実行環境を構築することができないためＡＰＰを動作させることができない旨の情報等を、ＡＰＰの実行要求を行ったクライアント装置１等に出力（又は返信）する。
【００２２】
図４は、ＡＰＰプロビジョニングエンジンの処理の一例を示すフローチャート（その１）である。
ステップＳ１０において、読み込み部３１は、クライアント装置１等から実行要求されたＡＰＰからＴａｇ情報を読み込む。
ステップＳ１１において、構築部３２は、ステップＳ１０で読み込み部３１が読み込んだＴａｇ情報と、図５に示されるような断片化された仮想化リソースのうち、現在使用可能（又は実行要求を行ったクライアント装置１のユーザが使用可能）な仮想化リソースと、に基づいて、前記ＡＰＰが動作可能な実行環境（例えば図５に示されるようなプロビジョニングリソースセット）を構築可能か否か判定する。
【００２３】
構築部３２は、ＡＰＰが動作可能な実行環境を構築可能であると判定するとステップＳ１３に進み、ＡＰＰが動作可能な実行環境を構築可能でないと判定するとステップＳ１２に進む。
ステップＳ１２において、構築部３２は、ＡＰＰが動作可能な実行環境を構築することができないためＡＰＰを動作させることができない旨の情報等を、ＡＰＰの実行要求を行ったクライアント装置１等に出力（又は返信）する。
【００２４】
一方、ステップＳ１３において、構築部３２は、ステップＳ１０で読み込み部３１が読み込んだＴａｇ情報に基づいて、ＡＰＰを動作させる実行環境を構築する。
【００２５】
図５は、ＡＰＰプロビジョニングエンジンの処理を説明するための図である。
図５に示される物理リソースは、ユーティリティシステムが管理している複数の物理リソースである。ユーティリティシステムは、これらの物理リソースを仮想化して管理している。ＡＰＰプロビジョニングエンジン２１は、Ｔａｇ情報を読み込み、読み込んだＴａｇ情報に基づいて、これら仮想化して管理されている仮想化リソースを組み合わせて実行環境を構築し、この実行環境上でＡＰＰを実行させる。
【００２６】
以下、より具体的な例を用いてＡＰＰプロビジョニングエンジン２１の処理を説明する。まず、ＡＰＰの一例として、勤怠情報管理アプリケーションを例に説明を行う。勤怠情報管理アプリケーションは、
１．営業日に社員各自から就業開示時間、就業終了時間の入力を受け付ける。
２．月末に社員それぞれの就労情報（休暇、欠勤、残業、休日出勤等の情報）を給与システムに送信する。
機能を有するものとする。
また、勤怠情報管理アプリケーションは、
１．社員個々の就労状況を管理するアプリケーションＡ（社員が入力を行うための入力インタフェース）
２．月末時点でその月の就労情報をバッチ処理するアプリケーションＢ
３．アプリケーションＡとアプリケーションＢとで使う社員就労情報を管理するアプリケーションＣ
で構成され、
それぞれのアプリケーションは、
１．ＩＡ−８６のアーキテクチャーが搭載されたサーバ
２．ＬｉｎｕｘＯＳ Ｖｅｒ○、パッチ○○
３．ＷｅｂＬｏｇｉｃアプリケーションサーバＶｅｒ．○、パッチ○○
４．Ｏｒａｃｌｅ（登録商標） １０Ｇ ＤＢ ＰＳＲ○○
で動作するものとする。
【００２７】
また、アプリケーションＡは、２４時間３６５日ノンストップの可用性を要求され、アプリケーションＢは、毎月末処理２時間での確実な実行を要求されるものとする。
また、アプリケーションＡのサービスレベルを維持するためには、４ＣＰＵ、メモリー２ＧＢ、ストレージ５ＧＢを必要とするものとする。また、アプリケーションＢのサービスレベルを維持するためには、１０ＣＰＵ、メモリー４ＧＢ、ストレージ５ＧＢを必要とするものとする。また、アプリケーションＣは、アプリケーションＡ実行時に、２ＣＰＵ、メモリー２ＧＢ、アプリケーションＢ実行時に、１６ＣＰＵ、メモリー４ＧＢと、それぞれのアプリケーションのサービスレベルを維持する演算能力と、社員ＤＢが既に構成されている３００ＧＢのストレージの特定エリアと、を必要とするものとする。
【００２８】
また、Ｔａｇ情報は、図６に示されるような順に従って格納されているものとする。図６は、Ｔａｇ情報の一例を示す図である。図７は、アプリケーションＡのＴａｇ情報の一例を示す図である。図８は、アプリケーションＢのＴａｇ情報の一例を示す図である。図９は、アプリケーションＣのＴａｇ情報の一例を示す図である。
また、図１０は、ＡＰＰプロビジョニングエンジンにおける実行環境の構築を説明するための図である。ＡＰＰプロビジョニングエンジン２１は、図７、図８、図９で示されるアプリケーションＡのＴａｇ情報、アプリケーションＢのＴａｇ情報、アプリケーションＣのＴａｇ情報を読み込み、これらのＴａｇ情報に基づいて、図１０に示されるように、各アプリケーションを動作させる実行環境を構築する。
より具体的に説明すると、ＡＰＰプロビジョニングエンジン２１は、図７、図８、図９で示されるアプリケーションＡのＴａｇ情報、アプリケーションＢのＴａｇ情報、アプリケーションＣのＴａｇ情報を読み込み、これらのＴａｇ情報に基づいて、図１０の４１、４２に示される実行環境を構築する。図１０の４１は、アプリケーションＡを稼動させるための実行環境であり、ＡＰＰプロビジョニングエンジン２１は、サーバプールから４つのＣＰＵ等を確保し、また、アプリケーションＣの実行環境も構築している。
この実行環境によって、ユーザは、クライアント装置１を介して就労状況の入力を、アプリケーションＡを用いて行うことができる。なお、図１０の４２は、アプリケーションＢを稼動させるための実行環境である。
【００２９】
以上、上述したように本実施形態によれば、Ｔａｇ情報に基づいて、構築された実行環境でＡＰＰを動作させることが可能なので、ＡＰＰの実行環境が開発環境と異なった場合でもＡＰＰの動作に関する品質を保証する技術を提供することができる。
【００３０】
＜実施形態２＞
実施形態１では、Ｔａｇ情報はＡＰＰの特定位置に格納されているものとして説明を行った。しかしながら、Ｔａｇ情報は、ＡＰＰとは別に、ＤＢ等でＡＰＰと対応付けて格納されていてもよい。
このような構成の場合、読み込み部３１は、ＡＰＰ識別子等に基づいて、ＡＰＰに対応するＴａｇ情報をＤＢから取得し、読み込む。
このような構成とすることによって既に存在するＡＰＰに対してもＡＰＰプロビジョニングエンジン２１は、ＡＰＰの動作に関する品質を保証する技術を提供することができる。
【００３１】
＜実施形態３＞
また、Ｔａｇ情報は、ユーティリティシステムのファイルシステム上に存在するＡＰＰごとのヘッダー情報に格納（記載）されていてもよい。
このような構成の場合、読み込み部３１は、ＡＰＰ識別子等に基づいて、ＡＰＰに対応するＴａｇ情報をファイルシステム上のヘッダー情報から取得し、読み込む。
【００３２】
＜実施形態４＞
また、Ｔａｇ情報の格納場所に関して、上述した各実施形態を組み合わせて実施してもよい。つまり、Ｔａｇ情報は、上述した格納場所の何れか１つに限られず、例えばＡＰＰに応じて格納場所が異なっていてもよい。
【００３３】
＜実施形態５＞
Ｔａｇ情報に含まれる情報は、上述した実施形態に示したものに限られない。本実施形態では、Ｔａｇ情報に課金に関する基本情報が含まれている場合を例に説明を行う。
ここで、課金に関する基本情報とは、例えば、利用時間あたりの料金、トランザクション数あたりの料金、記憶容量あたりの料金、ユーザ識別子あたりの料金、課金に関するオプション情報（前記単位でのディスカウント率等が含まれるものとする。
【００３４】
図１１は、サーバ装置の機能構成の一例を示す図（その２）である。図１１に示されるように、サーバ装置２は、ＣＰＵ１１が、プログラムを実行することによって実現されるＡＰＰプロビジョニングエンジン２１を機能構成として含む。
本実施形態のＡＰＰプロビジョニングエンジン２１は、機能として、上述した実施形態１の機能に加えて、計数部３３を更に含む。
【００３５】
計数部３３は、ＡＰＰが実行された場合、Ｔａｇ情報に含まれる課金に関する基本情報及びＡＰＰの実行に関する情報に基づいて、前記ＡＰＰの実行に伴う課金情報（つまり、ＡＰＰの利用に伴う料金）を計数する。例えば、課金に関する情報として利用時間あたりの料金が含まれていた場合、計数部３３は、前記利用時間あたりの料金と、ＡＰＰの実行時間の情報と、に基づいて、ＡＰＰの利用に伴う料金を計数する。
そして、計数部３３は、計数した課金情報を例えば、ユーティリティシステムとネットワークを介して通信可能な課金サーバ等に送信し、課金サーバ等に課金情報を格納させる。
【００３６】
図１２は、ＡＰＰプロビジョニングエンジンの処理の一例を示すフローチャート（その２）である。
図１２のフローチャートは、図４のフローチャートに比べて、ステップＳ１４〜ステップＳ１６の処理が新たに加わっている。
ステップＳ１４において、計数部３３は、ＡＰＰの実行が終了したか否かを判定する。計数部３３は、ＡＰＰの実行が終了した場合は、ステップＳ１５に進み、ＡＰＰの実行が終了していない場合は、ステップＳ１４の処理を繰り返す。
【００３７】
ステップＳ１５において、計数部３３は、Ｔａｇ情報に含まれる課金に関する基本情報及びＡＰＰの実行に関する情報に基づいて、前記ＡＰＰの実行に伴う課金情報を計数する。
ステップＳ１６において、計数部３３は、ステップＳ１５で計数した課金情報を課金サーバ等に出力する。
【００３８】
以上、本実施形態によれば、ＡＰＰの動作に関する品質を保証する共に、ＡＰＰの利用に伴う課金の処理を速やかに行うことができる。
【００３９】
＜実施形態６＞
上述した実施形態では、Ｔａｇ情報に、対応するＡＰＰが一定の品質で動作するために必要な情報（例えば、ＣＰＵの種類や、ＯＳの種類、パッチの情報、サービスレベルを維持するためのリソース量等）が含まれている例を説明した。しかしながら、Ｔａｇ情報に、ＡＰＰが一定の品質で動作するための禁止情報（例えば、ＡＰＰが一定の品質で動作するためにＯＳの種類としてＬｉｎｕｘ Ｖｅｒ ｘｘ．ｘは駄目な場合はＬｉｎｕｘ Ｖｅｒ ｘｘ．ｘ−ＮＯ等の記述）が含まれていてもよい。
【００４０】
構築部３２は、読み込み部３１が読み込んだＴａｇ情報に上述したような禁止情報が含まれている場合は、このような構成は含まないように、断片化された仮想化リソースを組み合わせ、ＡＰＰを動作させる実行環境を構築する。
また、Ｔａｇ情報には、ＡＰＰを実行するために最低限必要となる動作環境の情報だけでなく、ＡＰＰを実行可能な複数の動作環境の情報と、各動作環境において提供可能な処理性能を表す性能情報（レスポンスタイム、スループットなど）とが対応付けられて記述されていてもよい。この場合、Ｔａｇ情報には、例えば、「動作環境−ｘ（ＣＰＵ−ｘ、ＯＳ−ｘ、パッチ−ｘ）では、レスポンスタイムはｘ（ｓ）、スループットはｘ（ｂｐｓ）」等の記述が含まれることになる。
これにより、例えば、高速な応答性が要求される場合、ユーザは、必要とするＡＰＰの処理性能（例えばレスポンスタイムやスループットなど）を指定する。構築部３２は、Ｔａｇ情報を参照して、ユーザによって指定された処理性能のレスポンスタイムやスループットなどを満たす動作環境を構築することが可能となる。
さらには、Ｔａｇ情報に含まれる課金に関する基本情報において、利用する処理性能に応じた料金の設定（例えば、提供される処理性能が高いほど、利用料金も高くするなど）がなされてもよい。この構成によれば、例えば高速な処理が要求されない場合には、ユーザは、スループットは低いものの低料金のサービスを選択することができ、構築部３２は、Ｔａｇ情報を参照して、ユーザによって選択された処理性能を提供可能な動作環境を構築することが可能となる。
【００４１】
ここで、ユーザがサービスの提供を受ける仕組みの一例について、より詳細に説明する。ユーザは、はじめに、サービスを提供する会社（以下ではサービス会社と称する）との間でＡＰＰの利用について契約を交わす。ユーザは、一つのＡＰＰだけでなく、複数のＡＰＰを利用することや、各ＡＰＰについて、複数の処理性能で利用することができる。そして、サービス会社は、各ユーザが利用可能なＡＰＰ及びＡＰＰごとの処理性能をユーザ情報管理用のサーバに登録する。
【００４２】
図１３は、ユーザごとの利用可能なＡＰＰ及び選択可能な処理性能を格納したテーブルを示す図である。図１３に示す例では、ユーザ００１は、ＡＰＰ−ｘ及びＡＰＰ−ｙを利用することができ、ユーザ００２は、ＡＰＰ−ｚのみを利用することができる。また、ユーザ００１は、サービス会社との契約により、ＡＰＰ−ｘを利用する場合、処理性能ａ（レスポンスタイム１ｍｓ以内で動作）又は処理性能ｂ（レスポンスタイム１ｓ以内で動作）の何れかを選択することができる。この処理性能ａ及び処理性能ｂは、例えば、最低限保証されるレスポンスタイムやスループットを表している。この場合、処理性能に応じた料金設定（つまり、処理性能が高いほど高額な料金設定）がなされることになる。
【００４３】
ユーザ００１は、サービスを利用する場合、端末装置からサービス会社の認証用のサーバにアクセスし、ログイン要求を送信する。認証用のサーバは、ユーザ００１からのログイン要求を受け付け、認証が完了すると、ユーザ情報管理用のサーバから、ユーザ００１の情報を取得し、端末装置にユーザ００１のメニュー画面用の情報を送信する。そして、ユーザ００１の端末装置は、メニュー画面において、ＡＰＰ−ｘとＡＰＰ−ｙとのいずれを利用するかをユーザに確認するメッセージを提示する。ユーザ００１がＡＰＰ−ｘを選択すると、端末装置は、メニュー画面において、処理性能ａと処理性能ｂとのいずれの処理性能で利用するかを確認するメッセージを提示する。ユーザ００１が処理性能ａを選択すると、端末装置は、サーバ装置２に対して、処理性能ａでのＡＰＰ−ｘの利用を要求する。そして、サーバ装置２では、ＡＰＰプロビジョニングエンジン２１の構築部３２がＡＰＰ−ｘのＴａｇ情報を参照し、処理性能ａを満たすＡＰＰ−ｘの動作環境の情報を検索して、該当する動作環境の情報に基づいてＡＰＰ−ｘの動作環境を構築する。
【００４４】
以下に、構築部３２がＴａｇ情報を参照して処理性能ａを満たす動作環境を構築する場合の処理について、より詳細に説明する。図１４は、ＡＰＰ−ｘの性能情報と動作環境とが対応付けられて記述されたＴａｇ情報を示す図である。図１４の（ａ）は０．５ｍｓのレスポンスタイムを保証する動作環境が記述されたＴａｇ情報１を示す図であり、図１４の（ｂ）は０．５ｓのレスポンスタイムを保証する動作環境が記述されたＴａｇ情報２を示す図である。Ｔａｇ情報１は、０．５ｍｓ以内のレスポンスタイムを保証する動作環境がＣＰＵ−１、ＯＳ−１、ＤＢ−１によって構成されることを示しており、Ｔａｇ情報２は、０．５ｓ以内のレスポンスタイムを保証する動作環境がＣＰＵ−２、ＯＳ−２、ＤＢ−２によって構成されることを示している。なお、図１４に示すＡＰＰ−ｘのＴａｇ情報１及びＴａｇ情報２は、それぞれ個別のＴａｇ情報として管理される構成であってもよいし、ＡＰＰごとに１つのＴａｇ情報に含めて管理される構成であってもよい。
【００４５】
ユーザの端末装置から処理性能ａ（レスポンスタイム１ｍｓ以内）でＡＰＰ−ｘを利用する要求があった場合、構築部３２は、図１４に示すＡＰＰ−ｘのＴａｇ情報１及びＴａｇ情報２を参照し、各Ｔａｇ情報の動作環境が要求される処理性能ａ（即ち、レスポンスタイム１ｍｓ以内）を満たすことができるか否かを判定する。図１４に示す例では、Ｔａｇ情報１には、レスポンスタイム０．５ｍｓ以内を保証する動作環境が記述されており、構築部３２は、Ｔａｇ情報１の動作環境が処理性能ａ（レスポンスタイム１ｍｓ以内）を満たしていると判定する。一方、Ｔａｇ情報２には、レスポンスタイム０．５ｓ以内を保証する動作環境が記述されており、構築部３２は、Ｔａｇ情報２の動作環境が処理性能ａ（レスポンスタイム１ｍｓ以内）を満たしていないと判定する。したがって、この場合、構築部３２は、Ｔａｇ情報１を用いて、ＣＰＵ−１、ＯＳ−１、ＤＢ−１によって構成される動作環境を構築する。なお、処理性能ａを満たすＴａｇ情報が複数存在する場合には、予めＴａｇ情報に優先順位を設定しておくことにより、構築部３２は、設定された優先順位に基づいてＴａｇ情報を選択し、動作環境を構築することができる。
【００４６】
また、図１４に示す例では、Ｔａｇ情報としてユーザ識別子及び処理性能ごとの課金情報が含まれており、Ｔａｇ情報１の動作環境の場合、１０００円／時間で課金されることが示されている。そして、処理性能ａでＡＰＰが利用される場合、計数部３３は、１０００円／時間で利用料金を計算する。
これにより、ユーザは、状況に応じてＡＰＰの処理性能を選択することができるようになる。したがって、高速な応答性を必要とする場合には高度な処理性能でＡＰＰを利用することができる一方、必ずしも高度な処理性能を必要としない場合には、低い処理性能でＡＰＰを利用することにより料金を節約することがきるため、利便性が向上する。
【００４７】
なお、図１３に示す例では、ユーザは利用可能な処理性能をメニュー画面から選択する構成であるが、処理性能について予め契約することなく、利用の都度、ユーザが必要とする処理性能を直接入力し、入力された処理性能を満たす動作環境での単位時間あたりの利用料金がＴａｇ情報に基づいてサーバ装置２で見積もられ、その見積もり結果をユーザが確認した上で利用を開始（或いは、他の処理性能に変更）する構成であってもよい。また、図１３に示す例では、ユーザは処理性能を選択することになるが、ＡＰＰのＴａｇ情報において複数のＳＬＡ情報（例えば、２４時間３６５日稼動など）が設定されている場合、ユーザがログイン時にＳＬＡを選択可能な構成であってもよい。また、ログイン用のサーバやユーザ情報管理用のサーバは、独立したサーバ装置として設けられる構成であってもよいし、サーバ装置２の機能として一体的に備えられた構成であってもよく、特に限定はされない。
本実施形態によっても、ＡＰＰの動作に関する品質を保証する技術を提供することができる。
【００４８】
＜実施形態７＞
上述した各実施形態では、クライアント装置１と、ユーティリティシステム（又は、ユーティリティシステム＋クラウドシステム等）と、がネットワークを介して通信可能に接続されているシステムを例に説明を行った。しかしながら、本実施形態のシステムは、クライアント装置１のみを含むものとする。つまり、上述したように、ＡＰＰの利用を要求する側であるクライアント装置と、ＡＰＰの機能を提供する側であるサーバ装置とが一つの装置に実装されている形態で実現される例である。
【００４９】
図１５は、クライアント装置のハードウェア構成の一例を示す図である。図１５に示されるようにクライアント装置１は、ハードウェア構成として、ＣＰＵ５１を含む。
ＣＰＵ５１が、記憶装置５３に記憶されている、プログラム（例えば、ＡＰＰプロビジョニングエンジンプログラム）に基づき処理を行うことによって、クライアント装置１の機能（前述した図３のＡＰＰプロビジョニングエンジン２１の機能）、又は前述した図４のフローチャートに係る処理を実現する。
【００５０】
また、ＣＰＵ５１には、バスを介して、入力装置５２、記憶装置５３及び表示装置５４が接続されている。記憶装置５３は、例えば、ＲＯＭ、ＲＡＭ、ハードディスク装置等からなり、上述した各プログラム以外に、プログラムに基づく処理で用いられるデータを記憶する。表示装置５４は、情報を表示する例えばディスプレイ等である。入力装置５２は、情報を入力する例えば操作キー等である。
【００５１】
上述したように、本実施形態のＡＰＰプロビジョニングエンジン２１は、実施形態１に示した機能と同様であるが、本実施形態のようにクライアント装置１に実装されている場合、クライアント装置１にインストール等されているＡＰＰを動作させるのに必要な実行環境を構築する。例えば、複数のＡＰＰがクライアント装置１に実行されており、複数のＡＰＰを動作させるよう要求があった場合、ＡＰＰプロビジョニングエンジン２１は、各ＡＰＰに対応するＴａｇ情報を読み込み、各ＡＰＰを動作させるのに必要な実行環境をクライアント装置１の物理ソースを用いて構築する。そして、ＡＰＰプロビジョニングエンジン２１は、あるＡＰＰを動作させるのに必要な実行環境を構築することができなかった場合は、例えばＡＰＰが動作可能な実行環境を構築することができないためＡＰＰを動作させることができない旨の情報等を、表示装置５４等に出力する。
【００５２】
以上、本実施形態によれば、単体の装置内で動作するＡＰＰの動作に関する品質も保証することができる。
【００５３】
以上、本発明の好ましい実施形態について詳述したが、本発明は係る特定の実施形態に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形・変更が可能である。
また、上述した各実施形態を任意に組み合わせてもよい。
【符号の説明】
【００５４】
１ クライアント装置
２ サーバ装置
【技術分野】
【０００１】
本発明は、情報処理装置、情報処理方法及びプログラムに関する。
【背景技術】
【０００２】
近年、システムインフラストラクチャーリソースの有効活用を目指すために、システムインフラストラクチャーのユーティリティ化やクラウド化が進んでいる。その結果、従来の、アプリケーション（以下、ＡＰＰという）が特定のシステムインフラストラクチャーで実行されているシステムと違い、ＡＰＰが実行される環境をユニークに特定できないことはもとより、ＡＰＰがどこで実行されているのかもインフラストラクチャーの空き状況により異なるシステムが存在する。
【０００３】
一方、ＡＰＰは、複雑化しており、ＡＰＰが使用される使用環境を考慮しないでシステム構築等がなされることもある。つまり本来であれば、実使用環境下でＡＰＰの連携テスト等を行うべきであるが、そのようなテスト環境を設定することも容易ではなく、ＡＰＰの単体テストだけを行ってシステム構築されることも少なくない。また、あるＡＰＰを性能Ｘのサーバ１０台で実行することを想定して開発した場合であっても、そのＡＰＰを実行するときには性能Ｘより高性能なサーバが開発され、このようなサーバが投入され、リソースが余ってしまうこともあれば、サーバの性能の向上に伴い、サーバの数が８台に減らされる場合もある。しかも、システムインフラストラクチャーのユーティリティ化によって、ＡＰＰがいつどのサーバに割り当てられるかも分からないし、どこのどのようなストレージにデータが格納されてしまうかもシステムインフラストラクチャーのクラウド化によって分からなくなってきている。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特許第２５２１０２０号明細書
【発明の概要】
【発明が解決しようとする課題】
【０００５】
上述したように、ＡＰＰの開発時と異なる実行環境でＡＰＰが動作する可能性がある。つまり、ＡＰＰの実行環境が開発環境と異なった場合のＡＰＰの動作に関する品質が保証されていない問題があった。例えば、実行環境においてレスポンスタイムの低下やシステムのサービスレベルの低下が発生してしまうという問題があった。
【０００６】
本発明はこのような問題点に鑑みなされたもので、ＡＰＰの動作品質や、レスポンスタイムを含んだサービスレベルに関する品質を保証する技術を提供することを目的とする。
【課題を解決するための手段】
【０００７】
そこで、本発明の情報処理装置は、実行要求に係るアプリケーションに対応する、前記アプリケーションの動作に関する動作情報を読み込む読み込み手段と、前記読み込み手段で読み込まれた前記動作情報に基づいて、前記アプリケーションを動作させる実行環境を構築する構築手段と、を有する。
【０００８】
本発明の情報処理装置は、実行要求に係るアプリケーションに対応する、前記アプリケーションの動作に関する動作情報を読み込む読み込み手段と、前記読み込み手段で読み込まれた前記動作情報に基づいて、前記アプリケーションを動作させる実行環境を構築する構築手段と、を有することにより、例えば、ＡＰＰの実行環境等の情報を含む動作情報に基づいて、構築された実行環境でＡＰＰを動作させることが可能なので、ＡＰＰの実行環境が開発環境と異なった場合でもＡＰＰの動作に関する品質を保証する技術を提供することができる。
【０００９】
なお、情報処理装置とは、例えば、後述するサーバ装置２、又はクライアント装置１等に対応する。より具体的に説明すると、後述する実施形態１のように本発明を、ユーティリティシステムを含むシステムに適用する場合、情報処理装置は、例えば後述するサーバ装置２に対応する。また、後述する実施形態５のように本発明を、ＰＣ、単体に適用する場合、情報処理装置は、例えば後述するクライアント装置（ＰＣ）に対応する。
また、動作情報とは、例えば、後述するＴａｇ情報に対応する。
【００１０】
また、本発明の情報処理方法は、情報処理装置が、実行要求に係るアプリケーションに対応する、前記アプリケーションの動作に関する動作情報を読み込む読み込みステップと、前記情報処理装置が、前記読み込みステップで読み込まれた前記動作情報に基づいて、前記アプリケーションを動作させる実行環境を構築する構築ステップと、を含む。
【００１１】
また、本発明のプログラムは、コンピュータを、実行要求に係るアプリケーションに対応する、前記アプリケーションの動作に関する動作情報を読み込む読み込み手段と、前記読み込み手段で読み込まれた前記動作情報に基づいて、前記アプリケーションを動作させる実行環境を構築する構築手段と、して機能させる。
【発明の効果】
【００１２】
本発明によれば、ＡＰＰの動作品質や、レスポンスタイムを含んだサービスレベルに関する品質を保証する技術を提供することができる。
【図面の簡単な説明】
【００１３】
【図１】本実施形態で説明するシステムのシステム構成の一例を示す図である。
【図２】サーバ装置のハードウェア構成の一例を示す図である。
【図３】サーバ装置の機能構成の一例を示す図（その１）である。
【図４】ＡＰＰプロビジョニングエンジンの処理の一例を示すフローチャート（その１）である。
【図５】ＡＰＰプロビジョニングエンジンの処理を説明するための図である。
【図６】Ｔａｇ情報の一例を示す図である。
【図７】アプリケーションＡのＴａｇ情報の一例を示す図である。
【図８】アプリケーションＢのＴａｇ情報の一例を示す図である。
【図９】アプリケーションＣのＴａｇ情報の一例を示す図である。
【図１０】ＡＰＰプロビジョニングエンジンにおける実行環境の構築を説明するための図である。
【図１１】サーバ装置の機能構成の一例を示す図（その２）である。
【図１２】ＡＰＰプロビジョニングエンジンの処理の一例を示すフローチャート（その２）である。
【図１３】ユーザごとの利用可能なＡＰＰ及び選択可能な処理性能を格納したテーブルを示す図である。
【図１４】アプリケーションの性能情報と動作環境とが対応付けられて記述されたＴａｇ情報を示す図である。
【図１５】クライアント装置のハードウェア構成の一例を示す図である。
【発明を実施するための形態】
【００１４】
以下、本発明の実施形態について図面に基づいて説明する。
【００１５】
なお、本明細書中では、ユーティリティシステムとは、ＣＰＵや記憶装置（記憶媒体）等のシステムリソースを自由に追加／削除できるシステムのことをいう。また、クラウドシステムとは、インターネット上に分散した各種リソースを使ってサービスを提供する（又は、サービスの提供を受ける）システムのこという。クラウドシステムでは、ユーザはクライアントコンピュータ（ＰＣ）だけを持っていればよく、アプリケーションはネットの向こう側（クラウドシステム側）から提供され、情報も向こう側（クラウドシステム側）が管理する。
【００１６】
＜実施形態１＞
図１は、本実施形態で説明するシステムのシステム構成の一例を示す図である。
図１に示されるように、クライアント装置１は、ユーティリティシステム（又は、ユーティリティシステム＋クラウドシステム等）とネットワークを介して通信可能に接続されている。なお、図１では説明の簡略化のためクライアント装置１は、１つのみとしているが複数のクライアント装置がネットワークに接続されていてもよい。また、説明の簡略化のため、以下に示す実施形態ではクライアント装置１は、ユーティリティシステムとネットワークを介して通信可能に接続されているものとする。
ユーティリティシステムは、後述するように複数の物理ソース（ハードウェア等）を含み、これらを管理している。なお、ユーティリティシステム全体の制御は、サーバ装置２が行っているものとする。サーバ装置２は単体の場合もあるが、クラウドシステム中に複数存在し、それぞれが互いに通信しながら制御を行ってもよい。また、本明細書では、クライアント装置、サーバ装置、或いはユーティリティシステムなど、ハードウェアの形態についていくつかの表現を用いているが、これはあくまでも理解を助けるものであり、ＡＰＰの利用を要求する側をクライアント装置、ＡＰＰの機能を提供する側をサーバ装置と仮に呼ぶこととする。ある装置が物理的にクライアント装置とサーバ装置を兼ねていたり、更にその装置がユーティリティシステムを構成する装置のうちの一つとして存在していたりしてもよい。
【００１７】
図２は、サーバ装置のハードウェア構成の一例を示す図である。図２に示されるようにサーバ装置２は、ハードウェア構成として、ＣＰＵ１１を含む。
ＣＰＵ１１が、記憶装置１２に記憶されている、プログラム（例えば、APPプロビジョニングエンジンプログラム）に基づき処理を行うことによって、サーバ装置２の機能、又は後述するフローチャートに係る処理を実現する。
【００１８】
また、ＣＰＵ１１には、バスを介して、記憶装置１２が接続されている。記憶装置１２は、例えば、ＲＯＭ、ＲＡＭ、ハードディスク装置等からなり、上述した各プログラム以外に、プログラムに基づく処理で用いられるデータを記憶する。
【００１９】
図３は、サーバ装置の機能構成の一例を示す図（その１）である。図３に示されるように、サーバ装置２は、ＣＰＵ１１が、プログラムを実行することによって実現されるＡＰＰプロビジョニングエンジン２１を機能構成として含む。
また、ＡＰＰプロビジョニングエンジン２１は、機能として、読み込み部３１と、構築部３２と、を含む。
【００２０】
読み込み部３１は、クライアント装置１等から実行要求されたＡＰＰに対応する、Ｔａｇ情報を読み込む。なお、本実施形態では、Ｔａｇ情報は、ＡＰＰの特定の位置に格納されているものとする。
ここで、Ｔａｇ情報は、例えば、以下のような情報を含む
・ＡＰＰ識別子（単体動作 ｏｒ ＳＯＡモジュール ｏｒ ライブラリ等）
・オブジェクトの種類（機械語 ｏｒ インタープリター使用［ＯＳ依存 ｏｒ 非依存］）
−機械語の場合は、ＣＰＵの種類（ＩＡ−８６ ｏｒ Ｉｔａｎｉｕｍ ｏｒ Ｓｐａｒｃ ｏｒ ＩＢＭ−Ｐ等）
・動作ＯＳ情報（ＯＳ識別子 ａｎｄ Ｖｅｒ識別子 ａｎｄ パッチ識別子等）
・コード形式
・インタープリターの種類
・動作Ｍｉｄｄｌｅｗａｒｅ情報１（ＤＢの種類 ａｎｄ ＡＰＰ実行環境の種類等）
・動作Ｍｉｄｄｌｅｗａｒｅ情報２（Ｖｅｒ識別子 ａｎｄ パッチ識別子）
・サービスレベル情報１（レスポンスタイム ｏｒ アベイラビリティタイム等）
・サービスレベル情報２（使用ＣＰＵリソース量 ｏｒ メモリー使用量等）
・バックアップアーカイブ情報
・関連Ｔａｇ（当該Ｔａｇに関連する別のＴａｇ）
なお、Ｔａｇ情報は、上記全ての情報を含まなくてもよく、上記情報の一部のみを含んでもよい。
【００２１】
構築部３２は、読み込み部３１が読み込んだＴａｇ情報に基づいて、断片化された仮想化リソースを組み合わせ、ＡＰＰを動作させる実行環境を構築する。また、構築部３２は、読み込み部３１が読み込んだＴａｇ情報に基づいて、断片化された仮想化リソースを組み合わせ、ＡＰＰを動作させる実行環境を構築することができなかった場合は、例えばＡＰＰが動作可能な実行環境を構築することができないためＡＰＰを動作させることができない旨の情報等を、ＡＰＰの実行要求を行ったクライアント装置１等に出力（又は返信）する。
【００２２】
図４は、ＡＰＰプロビジョニングエンジンの処理の一例を示すフローチャート（その１）である。
ステップＳ１０において、読み込み部３１は、クライアント装置１等から実行要求されたＡＰＰからＴａｇ情報を読み込む。
ステップＳ１１において、構築部３２は、ステップＳ１０で読み込み部３１が読み込んだＴａｇ情報と、図５に示されるような断片化された仮想化リソースのうち、現在使用可能（又は実行要求を行ったクライアント装置１のユーザが使用可能）な仮想化リソースと、に基づいて、前記ＡＰＰが動作可能な実行環境（例えば図５に示されるようなプロビジョニングリソースセット）を構築可能か否か判定する。
【００２３】
構築部３２は、ＡＰＰが動作可能な実行環境を構築可能であると判定するとステップＳ１３に進み、ＡＰＰが動作可能な実行環境を構築可能でないと判定するとステップＳ１２に進む。
ステップＳ１２において、構築部３２は、ＡＰＰが動作可能な実行環境を構築することができないためＡＰＰを動作させることができない旨の情報等を、ＡＰＰの実行要求を行ったクライアント装置１等に出力（又は返信）する。
【００２４】
一方、ステップＳ１３において、構築部３２は、ステップＳ１０で読み込み部３１が読み込んだＴａｇ情報に基づいて、ＡＰＰを動作させる実行環境を構築する。
【００２５】
図５は、ＡＰＰプロビジョニングエンジンの処理を説明するための図である。
図５に示される物理リソースは、ユーティリティシステムが管理している複数の物理リソースである。ユーティリティシステムは、これらの物理リソースを仮想化して管理している。ＡＰＰプロビジョニングエンジン２１は、Ｔａｇ情報を読み込み、読み込んだＴａｇ情報に基づいて、これら仮想化して管理されている仮想化リソースを組み合わせて実行環境を構築し、この実行環境上でＡＰＰを実行させる。
【００２６】
以下、より具体的な例を用いてＡＰＰプロビジョニングエンジン２１の処理を説明する。まず、ＡＰＰの一例として、勤怠情報管理アプリケーションを例に説明を行う。勤怠情報管理アプリケーションは、
１．営業日に社員各自から就業開示時間、就業終了時間の入力を受け付ける。
２．月末に社員それぞれの就労情報（休暇、欠勤、残業、休日出勤等の情報）を給与システムに送信する。
機能を有するものとする。
また、勤怠情報管理アプリケーションは、
１．社員個々の就労状況を管理するアプリケーションＡ（社員が入力を行うための入力インタフェース）
２．月末時点でその月の就労情報をバッチ処理するアプリケーションＢ
３．アプリケーションＡとアプリケーションＢとで使う社員就労情報を管理するアプリケーションＣ
で構成され、
それぞれのアプリケーションは、
１．ＩＡ−８６のアーキテクチャーが搭載されたサーバ
２．ＬｉｎｕｘＯＳ Ｖｅｒ○、パッチ○○
３．ＷｅｂＬｏｇｉｃアプリケーションサーバＶｅｒ．○、パッチ○○
４．Ｏｒａｃｌｅ（登録商標） １０Ｇ ＤＢ ＰＳＲ○○
で動作するものとする。
【００２７】
また、アプリケーションＡは、２４時間３６５日ノンストップの可用性を要求され、アプリケーションＢは、毎月末処理２時間での確実な実行を要求されるものとする。
また、アプリケーションＡのサービスレベルを維持するためには、４ＣＰＵ、メモリー２ＧＢ、ストレージ５ＧＢを必要とするものとする。また、アプリケーションＢのサービスレベルを維持するためには、１０ＣＰＵ、メモリー４ＧＢ、ストレージ５ＧＢを必要とするものとする。また、アプリケーションＣは、アプリケーションＡ実行時に、２ＣＰＵ、メモリー２ＧＢ、アプリケーションＢ実行時に、１６ＣＰＵ、メモリー４ＧＢと、それぞれのアプリケーションのサービスレベルを維持する演算能力と、社員ＤＢが既に構成されている３００ＧＢのストレージの特定エリアと、を必要とするものとする。
【００２８】
また、Ｔａｇ情報は、図６に示されるような順に従って格納されているものとする。図６は、Ｔａｇ情報の一例を示す図である。図７は、アプリケーションＡのＴａｇ情報の一例を示す図である。図８は、アプリケーションＢのＴａｇ情報の一例を示す図である。図９は、アプリケーションＣのＴａｇ情報の一例を示す図である。
また、図１０は、ＡＰＰプロビジョニングエンジンにおける実行環境の構築を説明するための図である。ＡＰＰプロビジョニングエンジン２１は、図７、図８、図９で示されるアプリケーションＡのＴａｇ情報、アプリケーションＢのＴａｇ情報、アプリケーションＣのＴａｇ情報を読み込み、これらのＴａｇ情報に基づいて、図１０に示されるように、各アプリケーションを動作させる実行環境を構築する。
より具体的に説明すると、ＡＰＰプロビジョニングエンジン２１は、図７、図８、図９で示されるアプリケーションＡのＴａｇ情報、アプリケーションＢのＴａｇ情報、アプリケーションＣのＴａｇ情報を読み込み、これらのＴａｇ情報に基づいて、図１０の４１、４２に示される実行環境を構築する。図１０の４１は、アプリケーションＡを稼動させるための実行環境であり、ＡＰＰプロビジョニングエンジン２１は、サーバプールから４つのＣＰＵ等を確保し、また、アプリケーションＣの実行環境も構築している。
この実行環境によって、ユーザは、クライアント装置１を介して就労状況の入力を、アプリケーションＡを用いて行うことができる。なお、図１０の４２は、アプリケーションＢを稼動させるための実行環境である。
【００２９】
以上、上述したように本実施形態によれば、Ｔａｇ情報に基づいて、構築された実行環境でＡＰＰを動作させることが可能なので、ＡＰＰの実行環境が開発環境と異なった場合でもＡＰＰの動作に関する品質を保証する技術を提供することができる。
【００３０】
＜実施形態２＞
実施形態１では、Ｔａｇ情報はＡＰＰの特定位置に格納されているものとして説明を行った。しかしながら、Ｔａｇ情報は、ＡＰＰとは別に、ＤＢ等でＡＰＰと対応付けて格納されていてもよい。
このような構成の場合、読み込み部３１は、ＡＰＰ識別子等に基づいて、ＡＰＰに対応するＴａｇ情報をＤＢから取得し、読み込む。
このような構成とすることによって既に存在するＡＰＰに対してもＡＰＰプロビジョニングエンジン２１は、ＡＰＰの動作に関する品質を保証する技術を提供することができる。
【００３１】
＜実施形態３＞
また、Ｔａｇ情報は、ユーティリティシステムのファイルシステム上に存在するＡＰＰごとのヘッダー情報に格納（記載）されていてもよい。
このような構成の場合、読み込み部３１は、ＡＰＰ識別子等に基づいて、ＡＰＰに対応するＴａｇ情報をファイルシステム上のヘッダー情報から取得し、読み込む。
【００３２】
＜実施形態４＞
また、Ｔａｇ情報の格納場所に関して、上述した各実施形態を組み合わせて実施してもよい。つまり、Ｔａｇ情報は、上述した格納場所の何れか１つに限られず、例えばＡＰＰに応じて格納場所が異なっていてもよい。
【００３３】
＜実施形態５＞
Ｔａｇ情報に含まれる情報は、上述した実施形態に示したものに限られない。本実施形態では、Ｔａｇ情報に課金に関する基本情報が含まれている場合を例に説明を行う。
ここで、課金に関する基本情報とは、例えば、利用時間あたりの料金、トランザクション数あたりの料金、記憶容量あたりの料金、ユーザ識別子あたりの料金、課金に関するオプション情報（前記単位でのディスカウント率等が含まれるものとする。
【００３４】
図１１は、サーバ装置の機能構成の一例を示す図（その２）である。図１１に示されるように、サーバ装置２は、ＣＰＵ１１が、プログラムを実行することによって実現されるＡＰＰプロビジョニングエンジン２１を機能構成として含む。
本実施形態のＡＰＰプロビジョニングエンジン２１は、機能として、上述した実施形態１の機能に加えて、計数部３３を更に含む。
【００３５】
計数部３３は、ＡＰＰが実行された場合、Ｔａｇ情報に含まれる課金に関する基本情報及びＡＰＰの実行に関する情報に基づいて、前記ＡＰＰの実行に伴う課金情報（つまり、ＡＰＰの利用に伴う料金）を計数する。例えば、課金に関する情報として利用時間あたりの料金が含まれていた場合、計数部３３は、前記利用時間あたりの料金と、ＡＰＰの実行時間の情報と、に基づいて、ＡＰＰの利用に伴う料金を計数する。
そして、計数部３３は、計数した課金情報を例えば、ユーティリティシステムとネットワークを介して通信可能な課金サーバ等に送信し、課金サーバ等に課金情報を格納させる。
【００３６】
図１２は、ＡＰＰプロビジョニングエンジンの処理の一例を示すフローチャート（その２）である。
図１２のフローチャートは、図４のフローチャートに比べて、ステップＳ１４〜ステップＳ１６の処理が新たに加わっている。
ステップＳ１４において、計数部３３は、ＡＰＰの実行が終了したか否かを判定する。計数部３３は、ＡＰＰの実行が終了した場合は、ステップＳ１５に進み、ＡＰＰの実行が終了していない場合は、ステップＳ１４の処理を繰り返す。
【００３７】
ステップＳ１５において、計数部３３は、Ｔａｇ情報に含まれる課金に関する基本情報及びＡＰＰの実行に関する情報に基づいて、前記ＡＰＰの実行に伴う課金情報を計数する。
ステップＳ１６において、計数部３３は、ステップＳ１５で計数した課金情報を課金サーバ等に出力する。
【００３８】
以上、本実施形態によれば、ＡＰＰの動作に関する品質を保証する共に、ＡＰＰの利用に伴う課金の処理を速やかに行うことができる。
【００３９】
＜実施形態６＞
上述した実施形態では、Ｔａｇ情報に、対応するＡＰＰが一定の品質で動作するために必要な情報（例えば、ＣＰＵの種類や、ＯＳの種類、パッチの情報、サービスレベルを維持するためのリソース量等）が含まれている例を説明した。しかしながら、Ｔａｇ情報に、ＡＰＰが一定の品質で動作するための禁止情報（例えば、ＡＰＰが一定の品質で動作するためにＯＳの種類としてＬｉｎｕｘ Ｖｅｒ ｘｘ．ｘは駄目な場合はＬｉｎｕｘ Ｖｅｒ ｘｘ．ｘ−ＮＯ等の記述）が含まれていてもよい。
【００４０】
構築部３２は、読み込み部３１が読み込んだＴａｇ情報に上述したような禁止情報が含まれている場合は、このような構成は含まないように、断片化された仮想化リソースを組み合わせ、ＡＰＰを動作させる実行環境を構築する。
また、Ｔａｇ情報には、ＡＰＰを実行するために最低限必要となる動作環境の情報だけでなく、ＡＰＰを実行可能な複数の動作環境の情報と、各動作環境において提供可能な処理性能を表す性能情報（レスポンスタイム、スループットなど）とが対応付けられて記述されていてもよい。この場合、Ｔａｇ情報には、例えば、「動作環境−ｘ（ＣＰＵ−ｘ、ＯＳ−ｘ、パッチ−ｘ）では、レスポンスタイムはｘ（ｓ）、スループットはｘ（ｂｐｓ）」等の記述が含まれることになる。
これにより、例えば、高速な応答性が要求される場合、ユーザは、必要とするＡＰＰの処理性能（例えばレスポンスタイムやスループットなど）を指定する。構築部３２は、Ｔａｇ情報を参照して、ユーザによって指定された処理性能のレスポンスタイムやスループットなどを満たす動作環境を構築することが可能となる。
さらには、Ｔａｇ情報に含まれる課金に関する基本情報において、利用する処理性能に応じた料金の設定（例えば、提供される処理性能が高いほど、利用料金も高くするなど）がなされてもよい。この構成によれば、例えば高速な処理が要求されない場合には、ユーザは、スループットは低いものの低料金のサービスを選択することができ、構築部３２は、Ｔａｇ情報を参照して、ユーザによって選択された処理性能を提供可能な動作環境を構築することが可能となる。
【００４１】
ここで、ユーザがサービスの提供を受ける仕組みの一例について、より詳細に説明する。ユーザは、はじめに、サービスを提供する会社（以下ではサービス会社と称する）との間でＡＰＰの利用について契約を交わす。ユーザは、一つのＡＰＰだけでなく、複数のＡＰＰを利用することや、各ＡＰＰについて、複数の処理性能で利用することができる。そして、サービス会社は、各ユーザが利用可能なＡＰＰ及びＡＰＰごとの処理性能をユーザ情報管理用のサーバに登録する。
【００４２】
図１３は、ユーザごとの利用可能なＡＰＰ及び選択可能な処理性能を格納したテーブルを示す図である。図１３に示す例では、ユーザ００１は、ＡＰＰ−ｘ及びＡＰＰ−ｙを利用することができ、ユーザ００２は、ＡＰＰ−ｚのみを利用することができる。また、ユーザ００１は、サービス会社との契約により、ＡＰＰ−ｘを利用する場合、処理性能ａ（レスポンスタイム１ｍｓ以内で動作）又は処理性能ｂ（レスポンスタイム１ｓ以内で動作）の何れかを選択することができる。この処理性能ａ及び処理性能ｂは、例えば、最低限保証されるレスポンスタイムやスループットを表している。この場合、処理性能に応じた料金設定（つまり、処理性能が高いほど高額な料金設定）がなされることになる。
【００４３】
ユーザ００１は、サービスを利用する場合、端末装置からサービス会社の認証用のサーバにアクセスし、ログイン要求を送信する。認証用のサーバは、ユーザ００１からのログイン要求を受け付け、認証が完了すると、ユーザ情報管理用のサーバから、ユーザ００１の情報を取得し、端末装置にユーザ００１のメニュー画面用の情報を送信する。そして、ユーザ００１の端末装置は、メニュー画面において、ＡＰＰ−ｘとＡＰＰ−ｙとのいずれを利用するかをユーザに確認するメッセージを提示する。ユーザ００１がＡＰＰ−ｘを選択すると、端末装置は、メニュー画面において、処理性能ａと処理性能ｂとのいずれの処理性能で利用するかを確認するメッセージを提示する。ユーザ００１が処理性能ａを選択すると、端末装置は、サーバ装置２に対して、処理性能ａでのＡＰＰ−ｘの利用を要求する。そして、サーバ装置２では、ＡＰＰプロビジョニングエンジン２１の構築部３２がＡＰＰ−ｘのＴａｇ情報を参照し、処理性能ａを満たすＡＰＰ−ｘの動作環境の情報を検索して、該当する動作環境の情報に基づいてＡＰＰ−ｘの動作環境を構築する。
【００４４】
以下に、構築部３２がＴａｇ情報を参照して処理性能ａを満たす動作環境を構築する場合の処理について、より詳細に説明する。図１４は、ＡＰＰ−ｘの性能情報と動作環境とが対応付けられて記述されたＴａｇ情報を示す図である。図１４の（ａ）は０．５ｍｓのレスポンスタイムを保証する動作環境が記述されたＴａｇ情報１を示す図であり、図１４の（ｂ）は０．５ｓのレスポンスタイムを保証する動作環境が記述されたＴａｇ情報２を示す図である。Ｔａｇ情報１は、０．５ｍｓ以内のレスポンスタイムを保証する動作環境がＣＰＵ−１、ＯＳ−１、ＤＢ−１によって構成されることを示しており、Ｔａｇ情報２は、０．５ｓ以内のレスポンスタイムを保証する動作環境がＣＰＵ−２、ＯＳ−２、ＤＢ−２によって構成されることを示している。なお、図１４に示すＡＰＰ−ｘのＴａｇ情報１及びＴａｇ情報２は、それぞれ個別のＴａｇ情報として管理される構成であってもよいし、ＡＰＰごとに１つのＴａｇ情報に含めて管理される構成であってもよい。
【００４５】
ユーザの端末装置から処理性能ａ（レスポンスタイム１ｍｓ以内）でＡＰＰ−ｘを利用する要求があった場合、構築部３２は、図１４に示すＡＰＰ−ｘのＴａｇ情報１及びＴａｇ情報２を参照し、各Ｔａｇ情報の動作環境が要求される処理性能ａ（即ち、レスポンスタイム１ｍｓ以内）を満たすことができるか否かを判定する。図１４に示す例では、Ｔａｇ情報１には、レスポンスタイム０．５ｍｓ以内を保証する動作環境が記述されており、構築部３２は、Ｔａｇ情報１の動作環境が処理性能ａ（レスポンスタイム１ｍｓ以内）を満たしていると判定する。一方、Ｔａｇ情報２には、レスポンスタイム０．５ｓ以内を保証する動作環境が記述されており、構築部３２は、Ｔａｇ情報２の動作環境が処理性能ａ（レスポンスタイム１ｍｓ以内）を満たしていないと判定する。したがって、この場合、構築部３２は、Ｔａｇ情報１を用いて、ＣＰＵ−１、ＯＳ−１、ＤＢ−１によって構成される動作環境を構築する。なお、処理性能ａを満たすＴａｇ情報が複数存在する場合には、予めＴａｇ情報に優先順位を設定しておくことにより、構築部３２は、設定された優先順位に基づいてＴａｇ情報を選択し、動作環境を構築することができる。
【００４６】
また、図１４に示す例では、Ｔａｇ情報としてユーザ識別子及び処理性能ごとの課金情報が含まれており、Ｔａｇ情報１の動作環境の場合、１０００円／時間で課金されることが示されている。そして、処理性能ａでＡＰＰが利用される場合、計数部３３は、１０００円／時間で利用料金を計算する。
これにより、ユーザは、状況に応じてＡＰＰの処理性能を選択することができるようになる。したがって、高速な応答性を必要とする場合には高度な処理性能でＡＰＰを利用することができる一方、必ずしも高度な処理性能を必要としない場合には、低い処理性能でＡＰＰを利用することにより料金を節約することがきるため、利便性が向上する。
【００４７】
なお、図１３に示す例では、ユーザは利用可能な処理性能をメニュー画面から選択する構成であるが、処理性能について予め契約することなく、利用の都度、ユーザが必要とする処理性能を直接入力し、入力された処理性能を満たす動作環境での単位時間あたりの利用料金がＴａｇ情報に基づいてサーバ装置２で見積もられ、その見積もり結果をユーザが確認した上で利用を開始（或いは、他の処理性能に変更）する構成であってもよい。また、図１３に示す例では、ユーザは処理性能を選択することになるが、ＡＰＰのＴａｇ情報において複数のＳＬＡ情報（例えば、２４時間３６５日稼動など）が設定されている場合、ユーザがログイン時にＳＬＡを選択可能な構成であってもよい。また、ログイン用のサーバやユーザ情報管理用のサーバは、独立したサーバ装置として設けられる構成であってもよいし、サーバ装置２の機能として一体的に備えられた構成であってもよく、特に限定はされない。
本実施形態によっても、ＡＰＰの動作に関する品質を保証する技術を提供することができる。
【００４８】
＜実施形態７＞
上述した各実施形態では、クライアント装置１と、ユーティリティシステム（又は、ユーティリティシステム＋クラウドシステム等）と、がネットワークを介して通信可能に接続されているシステムを例に説明を行った。しかしながら、本実施形態のシステムは、クライアント装置１のみを含むものとする。つまり、上述したように、ＡＰＰの利用を要求する側であるクライアント装置と、ＡＰＰの機能を提供する側であるサーバ装置とが一つの装置に実装されている形態で実現される例である。
【００４９】
図１５は、クライアント装置のハードウェア構成の一例を示す図である。図１５に示されるようにクライアント装置１は、ハードウェア構成として、ＣＰＵ５１を含む。
ＣＰＵ５１が、記憶装置５３に記憶されている、プログラム（例えば、ＡＰＰプロビジョニングエンジンプログラム）に基づき処理を行うことによって、クライアント装置１の機能（前述した図３のＡＰＰプロビジョニングエンジン２１の機能）、又は前述した図４のフローチャートに係る処理を実現する。
【００５０】
また、ＣＰＵ５１には、バスを介して、入力装置５２、記憶装置５３及び表示装置５４が接続されている。記憶装置５３は、例えば、ＲＯＭ、ＲＡＭ、ハードディスク装置等からなり、上述した各プログラム以外に、プログラムに基づく処理で用いられるデータを記憶する。表示装置５４は、情報を表示する例えばディスプレイ等である。入力装置５２は、情報を入力する例えば操作キー等である。
【００５１】
上述したように、本実施形態のＡＰＰプロビジョニングエンジン２１は、実施形態１に示した機能と同様であるが、本実施形態のようにクライアント装置１に実装されている場合、クライアント装置１にインストール等されているＡＰＰを動作させるのに必要な実行環境を構築する。例えば、複数のＡＰＰがクライアント装置１に実行されており、複数のＡＰＰを動作させるよう要求があった場合、ＡＰＰプロビジョニングエンジン２１は、各ＡＰＰに対応するＴａｇ情報を読み込み、各ＡＰＰを動作させるのに必要な実行環境をクライアント装置１の物理ソースを用いて構築する。そして、ＡＰＰプロビジョニングエンジン２１は、あるＡＰＰを動作させるのに必要な実行環境を構築することができなかった場合は、例えばＡＰＰが動作可能な実行環境を構築することができないためＡＰＰを動作させることができない旨の情報等を、表示装置５４等に出力する。
【００５２】
以上、本実施形態によれば、単体の装置内で動作するＡＰＰの動作に関する品質も保証することができる。
【００５３】
以上、本発明の好ましい実施形態について詳述したが、本発明は係る特定の実施形態に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形・変更が可能である。
また、上述した各実施形態を任意に組み合わせてもよい。
【符号の説明】
【００５４】
１ クライアント装置
２ サーバ装置
【特許請求の範囲】
【請求項１】
実行要求に係るアプリケーションに対応する、前記アプリケーションの動作に関する動作情報を読み込む読み込み手段と、
前記読み込み手段で読み込まれた前記動作情報に基づいて、前記アプリケーションを動作させる実行環境を構築する構築手段と、
を有する情報処理装置。
【請求項２】
前記構築手段は、前記動作情報に基づいて、断片化された仮想化リソースを組み合わせ、前記アプリケーションを動作させる実行環境を構築する請求項１記載の情報処理装置。
【請求項３】
前記構築手段は、前記読み込み手段で読み込まれた前記動作情報に基づいて、前記アプリケーションを動作させる実行環境を構築することができなかった場合、前記アプリケーションを動作させることができない旨の情報を出力する請求項１又は２記載の情報処理装置。
【請求項４】
前記動作情報には、前記アプリケーションの実行に伴う課金に関する基本情報が含まれ、
前記アプリケーションが実行された場合、前記基本情報及び前記実行に関する情報に基づいて、前記アプリケーションの実行に伴う課金情報を計数する計数手段を更に有する請求項１乃至３の何れか１項記載の情報処理装置。
【請求項５】
前記動作情報には、前記アプリケーションの動作環境ごとの性能を表す性能情報が含まれ、
前記構築手段は、前記読み込み手段で読み込まれた前記動作情報に含まれる性能情報に基づいて、前記アプリケーションを動作させる実行環境を構築する請求項１乃至４の何れか１項記載の情報処理装置。
【請求項６】
前記動作情報は、前記アプリケーションに付加されており、
前記読み込み手段は、前記アプリケーションに付加された前記動作情報を読み込む請求項１乃至５の何れか１項記載の情報処理装置。
【請求項７】
前記動作情報は、前記アプリケーションと対応付けられて記憶装置に記憶されており、
前記読み込み手段は、前記アプリケーションと対応付けられた前記動作情報を前記記憶装置から読み込む請求項１乃至５の何れか１項記載の情報処理装置。
【請求項８】
前記動作情報は、ファイルシステム上のアプリケーションごとのヘッダー情報に含まれており、
前記読み込み手段は、前記ヘッダー情報から前記アプリケーションの前記動作情報を読み込む請求項１乃至５の何れか１項記載の情報処理装置。
【請求項９】
情報処理装置が、実行要求に係るアプリケーションに対応する、前記アプリケーションの動作に関する動作情報を読み込む読み込みステップと、
前記情報処理装置が、前記読み込みステップで読み込まれた前記動作情報に基づいて、前記アプリケーションを動作させる実行環境を構築する構築ステップと、
を含む情報処理方法。
【請求項１０】
コンピュータを、
実行要求に係るアプリケーションに対応する、前記アプリケーションの動作に関する動作情報を読み込む読み込み手段と、
前記読み込み手段で読み込まれた前記動作情報に基づいて、前記アプリケーションを動作させる実行環境を構築する構築手段と、
して機能させるプログラム。
【請求項１】
実行要求に係るアプリケーションに対応する、前記アプリケーションの動作に関する動作情報を読み込む読み込み手段と、
前記読み込み手段で読み込まれた前記動作情報に基づいて、前記アプリケーションを動作させる実行環境を構築する構築手段と、
を有する情報処理装置。
【請求項２】
前記構築手段は、前記動作情報に基づいて、断片化された仮想化リソースを組み合わせ、前記アプリケーションを動作させる実行環境を構築する請求項１記載の情報処理装置。
【請求項３】
前記構築手段は、前記読み込み手段で読み込まれた前記動作情報に基づいて、前記アプリケーションを動作させる実行環境を構築することができなかった場合、前記アプリケーションを動作させることができない旨の情報を出力する請求項１又は２記載の情報処理装置。
【請求項４】
前記動作情報には、前記アプリケーションの実行に伴う課金に関する基本情報が含まれ、
前記アプリケーションが実行された場合、前記基本情報及び前記実行に関する情報に基づいて、前記アプリケーションの実行に伴う課金情報を計数する計数手段を更に有する請求項１乃至３の何れか１項記載の情報処理装置。
【請求項５】
前記動作情報には、前記アプリケーションの動作環境ごとの性能を表す性能情報が含まれ、
前記構築手段は、前記読み込み手段で読み込まれた前記動作情報に含まれる性能情報に基づいて、前記アプリケーションを動作させる実行環境を構築する請求項１乃至４の何れか１項記載の情報処理装置。
【請求項６】
前記動作情報は、前記アプリケーションに付加されており、
前記読み込み手段は、前記アプリケーションに付加された前記動作情報を読み込む請求項１乃至５の何れか１項記載の情報処理装置。
【請求項７】
前記動作情報は、前記アプリケーションと対応付けられて記憶装置に記憶されており、
前記読み込み手段は、前記アプリケーションと対応付けられた前記動作情報を前記記憶装置から読み込む請求項１乃至５の何れか１項記載の情報処理装置。
【請求項８】
前記動作情報は、ファイルシステム上のアプリケーションごとのヘッダー情報に含まれており、
前記読み込み手段は、前記ヘッダー情報から前記アプリケーションの前記動作情報を読み込む請求項１乃至５の何れか１項記載の情報処理装置。
【請求項９】
情報処理装置が、実行要求に係るアプリケーションに対応する、前記アプリケーションの動作に関する動作情報を読み込む読み込みステップと、
前記情報処理装置が、前記読み込みステップで読み込まれた前記動作情報に基づいて、前記アプリケーションを動作させる実行環境を構築する構築ステップと、
を含む情報処理方法。
【請求項１０】
コンピュータを、
実行要求に係るアプリケーションに対応する、前記アプリケーションの動作に関する動作情報を読み込む読み込み手段と、
前記読み込み手段で読み込まれた前記動作情報に基づいて、前記アプリケーションを動作させる実行環境を構築する構築手段と、
して機能させるプログラム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【公開番号】特開２０１０−２１８０４９（Ｐ２０１０−２１８０４９Ａ）
【公開日】平成２２年９月３０日（２０１０．９．３０）
【国際特許分類】
【出願番号】特願２００９−６１９０５（Ｐ２００９−６１９０５）
【出願日】平成２１年３月１３日（２００９．３．１３）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．Ｌｉｎｕｘ
【出願人】（０００１９１０７６）新日鉄ソリューションズ株式会社 (136)
【Ｆターム（参考）】
【公開日】平成２２年９月３０日（２０１０．９．３０）
【国際特許分類】
【出願日】平成２１年３月１３日（２００９．３．１３）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．Ｌｉｎｕｘ
【出願人】（０００１９１０７６）新日鉄ソリューションズ株式会社 (136)
【Ｆターム（参考）】
[ Back to top ]