JP5449283B2 - クラウド共用型リソース提供システム - Google Patents

Description

本発明は、クラウドコンピューティング等の情報処理の技術に関する。特に、利用者がパブリッククラウド等を効果的に利用するための技術に関する。

クラウドコンピューティングシステムとして、各種のパブリッククラウドが存在する。例えばＡｍａｚｏｎ ＥＣ２（Amazon Elastic Compute Cloud）（非特許文献１）などが挙げられる。不特定の一般の利用者は、パブリッククラウド（そのリソース・サービス処理等）を利用する場合、利用者のコンピュータシステム・端末等からパブリッククラウドのサーバ等にアクセスし、仮想サーバにより提供されるサービス処理やストレージのデータ等を利用して、利用者の所望のソフトウェアプログラム処理（アプリケーション処理やバッチ処理など。例えば企業のオンライン業務処理等。）を実現する。

なおバッチ処理に係わる先行技術例として、特開２０１１−７０３１８号公報（特許文献１）などがある。

特開２０１１−７０３１８号公報

"Amazon Elastic Compute Cloud (Amazon EC2)"、amazon web services（登録商標）、［２０１１年８月１日検索］、インターネット＜ＵＲＬ：http://aws.amazon.com/ec2/＞

前述の各種のパブリッククラウドが存在し、利用者によるパブリッククラウドの利用方法は様々であり、利用者は、固有のパブリッククラウドに合わせた利用方法や課金方式を余儀なくされている。即ち、パブリッククラウドの利用における容易性（利便性）やコストパフォーマンス等に関して課題（改善余地）がある。

例えば、ある固有のパブリッククラウドを利用して利用者が所望のアプリケーション処理やバッチ処理などのプログラム処理を実現する場合、当該パブリッククラウドの仮想サーバ数単位での利用契約（課金方式）に基づき、課金がされる。しかし例えばバッチ処理で所定の限定された日時にしか処理が実行されなくても、利用契約で借りている仮想サーバ数単位の課金の料金になるため、利用者にとってはコストパフォーマンスがよくないと感じられる。

以上を鑑み、本発明の主な目的は、パブリッククラウドの利用に係わる新しいモデルのシステム・技術を提供することにより、利用者のパブリッククラウドの利用に係わる容易性（利便性）やコストパフォーマンス等を実現できることである。

上記目的を達成するため、本発明のうち代表的な形態は、パブリッククラウド等のクラウドコンピューティングシステム（そのサービス処理等）を利用者が効果的に利用するための情報処理システム（クラウド共用型リソース提供システム）、等であって、以下に示す構成を有することを特徴とする。

本形態のシステムは、複数の利用者の端末と、リソースプロバイダと、複数のパブリッククラウドとがネットワークで通信接続されて構成される。複数のパブリッククラウドは、各々に、リソースプロバイダが管理する共同利用型サーバが設置される。リソースプロバイダは、制御部と、記憶部と、モニタシステムとを有する。制御部は、登録部と、実行制御部とを有する。記憶部は、利用者のプログラムのデータを管理情報と共に格納する。登録部は、利用者からの指示に基づき、利用者のプログラムのデータを管理情報と共に記憶部に格納する処理を行う。実行制御部は、利用者からの指示に基づき、記憶部の利用者のプログラムを対象のパブリッククラウドの対象の共同利用型サーバで実行させるように制御する処理を行う。実行制御部からの制御に基づき、対象のパブリッククラウドの対象の共同利用型サーバは、利用者のプログラムの処理を稼働させる。モニタシステムは、対象のパブリッククラウドの対象の共同利用型サーバでの利用者のプログラムの処理の稼働の状態をモニタし、当該モニタ情報に基づいて、利用者に対する課金計算処理を行う。

本発明のうち代表的な形態によれば、パブリッククラウドの利用に係わる新しいモデルのシステム・技術を提供することにより、利用者のパブリッククラウドの利用に係わる容易性（利便性）やコストパフォーマンス等を実現できる。特に、企業等の利用者が各種のパブリッククラウドを容易に利用して所望のアプリケーション処理やバッチ処理を実現でき、なおかつコストパフォーマンスに優れるシステムを構築することができる。事業者側は新しいモデルのサービスを提供することができる。

本発明の一実施の形態のシステム（クラウド共用型リソース提供システム）の全体の構成を示す図である。 本実施の形態のシステムでの要素間の処理シーケンスを示す図である。 本実施の形態のシステムでの管理情報の構成例を示す図である。 本実施の形態のシステムでの複数の利用者がパブリッククラウドを共同利用する例（イメージ）を示す図である。 本実施の形態のより詳細な構成例として、ローカルプール等の構成例を示す図である。 従来の利用者のパブリッククラウドの利用例（イメージ）を示す図である。

以下、本発明の実施の形態を図面に基づいて詳細に説明する。なお、実施の形態を説明するための全図において、同一部には原則として同一符号を付し、その繰り返しの説明は省略する。

＜従来例＞
本実施の形態と比較するため、図６を用いて、従来例のシステムにおける利用者がパブリッククラウドを利用する例及びその問題点などについて説明する。

図６で、複数の各種のパブリッククラウド、例えばＡ，Ｂを有し、それらを利用する複数の利用者、例えばＡ，Ｂを有する。例えば、利用者Ａ（例：企業Ａ）は、端末（コンピュータ）Ａ１に、利用者プログラム（ＵＰ）＃１，＃２を有する。ＵＰは、利用者（企業システム等）ごとの所望の内容の処理（アプリケーション処理やバッチ処理など）を実現するためのプログラムである。端末Ａ１は、例えば企業Ａシステム内に設置されたオンプレミスサーバ（自社設置サーバ）である。利用者Ｂ（例：企業Ｂ）は、端末Ｂ１に、利用者プログラム（ＵＰ）＃３を有する。端末Ｂ１は、例えば企業Ｂシステム内に設置されたオンプレミスサーバである。

端末Ａ１のＵＰ＃１の処理（例：バッチ処理Ａ）では、パブリッククラウドＡ（ＷｅｂＡＰサーバ６０１等）にアクセスしそのリソース６０５を使用して処理が行われる。同様に、端末Ａ１のＵＰ＃２の処理（例：アプリ処理Ａ）では、パブリッククラウドＢ（リソース６０５）にアクセスし処理が行われる。同様に、端末Ｂ１のＵＰ＃３の処理（例：バッチ処理Ｂ）では、パブリッククラウドＡ（リソース６０５）にアクセスし処理が行われる。

例えばパブリッククラウドＡでは、複数のＷｅｂＡＰ（ウェブアプリケーション）サーバ６０１やＤＢ６０２を有する。物理サーバであるＷｅｂＡＰサーバ６０１では、仮想化ソフトウェア等を用いて複数の仮想サーバ６０３が稼働し、仮想サーバ６０３を用いたサービス処理を提供する。ＤＢ２は、ＷｅｂＡＰサーバ６０１が処理するデータ情報（例えば利用者のデータ）を格納するデータベースやストレージである。６０５は、６０１〜６０３を含むリソース・サービス処理をまとめて表す。

パブリッククラウドＡの課金部６０４は、利用者による当該パブリッククラウドＡ（リソース６０５）の利用に係わる課金処理を行う。この課金方式として、例えば、利用契約で利用者が借りる（利用者に貸す）固定の仮想サーバ数を単位とした課金である。

同様に、パブリッククラウドＢでは、異なるサーバ等の構成によるリソース６０５を有する。パブリッククラウドＢの課金部６０４は、課金方式として、例えば、月固定の料金である。上記例のように各種のパブリッククラウドＡ，Ｂの利用方法・課金方式があり、利用者はそれぞれの利用方法・課金方式に応じて利用する。

ＵＰ＃１は例えば所定のバッチ処理Ａを実行するプログラムであり、所定の日時に稼働し、ネットワークを介してパブリッククラウドＡのリソース６０５（仮想サーバ６０３等）にアクセスしその処理を実現する。ＵＰ＃１の処理内容（コード）は、固有のパブリッククラウドＡに応じた内容として記述されている。利用者Ａ（端末Ａ１）は、ＵＰ＃１（バッチ処理Ａ）のため、パブリッククラウドＡの利用契約に応じた仮想サーバ数を使用する。

上記バッチ処理Ａが例えば１日のうち３０分といった限定された時間で実行されるとしても、上記課金方式によると、処理実行時間分ではなく、固定の仮想サーバ数単位で課金されるため、利用者にとっては比較的割高な料金に感じられる可能性がある。

また例えば端末Ａ１のＵＰ＃１からネットワークを介してパブリッククラウドＡにアクセスするが、パブリッククラウドの位置（物理サーバが設置されている地域など）は各種パブリッククラウドに応じて異なるため、端末Ａ１からのアクセスの距離などに応じた遅延やエラーも発生し得る。即ち、固有のパブリッククラウドの特性に応じて利用者のプログラム処理の結果へ影響する場合がある。

＜概要等＞
本実施の形態のシステムでは、インターネット上、不特定の利用者のコンピュータシステム・端末と複数の各種のパブリッククラウドとの間に、新たにリソースプロバイダ（対応する情報処理システム）を設ける。リソースプロバイダの提供するリソースとは、パブリッククラウド内に設けられる共同利用型サーバ（クラウド共用型サーバ）を指す。この共同利用型サーバとは、複数の利用者により対象のパブリッククラウド（そのリソース）を共同利用するための特徴的なサーバ（ハードウェア及びソフトウェアを含む）である。リソースプロバイダは、不特定の利用者に対して、利用契約（課金）に基づき、当該共同利用型サーバ（リソース）を提供する。例えば、従量課金方式でのリソース貸しである。利用者は、所望の利用者プログラムをリソースプロバイダに登録し、上記提供リソースを利用して、利用者プログラムの処理（アプリケーション処理やバッチ処理など）を実現する。利用者システム内では当該利用者プログラム及びその稼働用のオンプレミスサーバ等を保持する必要性が小さくなる。

リソースプロバイダは、予め、対象（事業対象、設置対象）の複数の各種のパブリッククラウド内に、共同利用型サーバ（各々１つ以上）を設置する。またリソースプロバイダは、利用者からの指示・要求に応じて、利用者プログラム（そのデータ）をプールに登録する。リソースプロバイダは、利用者からの指示・要求に応じて、プールの利用者プログラムを、対象パブリッククラウドの対象共同利用型サーバ上で実行させるように制御する。共同利用型サーバ上の利用者プログラムの処理では適宜パブリッククラウドのリソース・サービス処理（仮想サーバ等）を利用して自身の処理を行う。

また、リソースプロバイダは、モニタシステムにより、各パブリッククラウドの共同利用型サーバにおける利用者プログラムの稼働状況・実績をモニタし、そのモニタ情報に応じて利用者に対する課金処理を行う。利用者は、実際に利用者プログラムが稼働した時間や処理量などに応じた課金で済むため、利用者にとってコストパフォーマンスに優れる。

［システム構成］
図１において、本実施の形態のシステムの全体の構成例を示している。本システム全体は、リソースプロバイダ１と、利用者端末２（図示しないが複数）と、複数の各種のパブリッククラウド３（例：Ａ，Ｂ，Ｃ等）とを含み、これらは通信ネットワーク（インターネット）で接続されている。

（１） リソースプロバイダ１は、サーバ（主制御部）１０と、プール５０（利用者プログラム格納部）と、モニタシステム４０と、ＵＩ（ユーザインタフェース）部６０とを有し、各部は例えばＬＡＮ等で接続される。リソースプロバイダ１は、複数の利用者（２）と複数のパブリッククラウド３との間に介在する事業者のシステムであり、利用者（２）に対して、パブリッククラウド３を効果的に利用するためのリソースである、共同利用型サーバ３１を提供（利用契約によるリソース貸し）する。複数の利用者（２）が共同利用型サーバ３１を共同利用する仕組みにより、低コストで当該リソースを提供できる。

（２） 利用者端末２は、不特定の利用者が使用するコンピュータシステムないし端末等である。利用者端末２は、図示しないプロセッサ、メモリ、通信インタフェース、ＯＳ，Ｗｅｂブラウザ等の公知の要素の他に、利用者プログラム（ＵＰ）１０１を有する。ＵＰ１０１は、利用者（２）がパブリッククラウド３に対して実行させる所望の処理（アプリケーション処理やバッチ処理など）のプログラムのデータである。

（３） パブリッククラウド３は、公知技術部分であるリソース３０と、本システムの特徴要素である共同利用型サーバ（ＳＳ）３１と、ＳＳ３１上で稼働させる利用者プログラム（ＵＰ）１０３と、リソースプロバイダ１のモニタシステム４０と連携するエージェント３２とを有する。リソース（サービス）３０は、前述（６０５）と同様に、当該パブリッククラウド３が元々備えている物理サーバ、仮想サーバ、ＤＢ、等のリソース・サービス処理を含む。

（３１） 共同利用型サーバ（ＳＳ）３１は、リソースプロバイダ１により予め対象のパブリッククラウド３内に設置（用意）される。ＳＳ３１は、リソースプロバイダ１（サーバ１０）の実行制御部１２からの指示（ａ２−２）に従い、対象のＵＰ１０３の処理を当該ＳＳ３１上で稼働させる。ＵＰ１０３の処理は、適宜、パブリッククラウド３のリソース（サービス）３０を参照しながら行われる。ＳＳ３１上には複数のＵＰ１０３の処理を稼働させることができる。

（３２） エージェント３２は、例えば、対応する対象の共同利用型サーバ（ＳＳ）３１上で一緒に稼働する（別のサーバ等で稼働する形としてもよい）。エージェント３２は、モニタ設定情報に基づいて、モニタ内容として、対象のＳＳ３１の動作・状態（その変動）と、ＳＳ３１上で稼働するＵＰ１０３の動作・状態（その変動）とをモニタし、その内容を示すモニタ情報（ａ４）を発行し、ネットワークを介してモニタシステム４０（モニタ部４１）へ送信する。ＵＰ１０３のモニタは、少なくともＵＰ１０２の処理（プロセスないしインスタンス）の起動（開始）と停止（終了）の把握を含む。

（１０） サーバ１０は、本システム（リソースプロバイダ１）の主制御部であり、登録部１１と、実行制御部１２とを有する。各処理部（１１，１２）は例えば当該サーバ１０に備えるプロセッサ、メモリ、通信インタフェース等の公知の要素を用いたソフトウェアプログラム処理で実現される。

（５０） プール５０は、利用者プログラム格納部であり、ストレージやＤＢ及びその入出力制御処理を用いて実現される。プール５０には、利用者プログラム（ＵＰ１０２）データが、対応する管理情報５１と共に格納される。サーバ１０は管理情報５１を作成・管理する。

（６０） ＵＩ部６０は、利用者（２）に対して本システムの機能の設定や指示入力などのためのユーザインタフェースを提供する処理部であり、例えばＷｅｂサーバで実装される。利用者は、利用者端末２（Ｗｅｂブラウザ）から当該ＵＩ部６０の提供するＷｅｂページにアクセスし、当該Ｗｅｂページで表示情報（設定状態など）を確認したり、各種の設定や指示（ａ０，ａ１−１，ａ２−１等）の操作が可能である。

（４０） モニタシステム４０は、モニタ部４１と、課金部４２と、モニタ情報４３（履歴情報）とを有する。モニタシステム４０は、例えばサーバで実装され、主に利用者への課金のためのモニタ処理を行う。なおモニタシステム４０部分は、リソースプロバイダ１やサーバ１０から分離したシステムとして連携する形態としてもよい。モニタシステム４０部分として例えば既存の統合監視システム（クラウドの仮想サーバ等の動作・状態を監視するシステム）や課金管理システム等を利用してもよい。

（４１） モニタ部４１は、パブリッククラウド３内で稼働するエージェント３２と連携し、エージェント３２からのモニタ情報（ａ４）に基づき、共同利用型サーバ（ＳＳ）３１の動作・状態をモニタし、モニタ情報４３として記録する。モニタ内容は、ＳＳ３１の動作・状態と、ＳＳ３１上で稼働するＵＰ１０３の動作・状態とを含む。

（４２） 課金部４２は、モニタ情報４３に基づいて、及び利用者の課金設定情報に基づいて、課金計算処理（例えばＳＳ３１上のＵＰ１０３の稼働時間や処理量に応じた従量課金）を行い、結果情報を保存し、利用者端末２に対する課金請求通知（ａ５）をしたり、ＵＩ部６０のＷｅｂページに課金情報を表示したりする処理を行う。利用者（２）への課金請求は、既存の決済システム等との連携により行ってもよい。

（１１） 登録部１１は、利用者（２）からのＵＰ事前登録の指示（ａ１−１）に基づき、利用者プログラム（ＵＰ）１０１のデータ（コピー）を、管理情報５１を付けてプール５０に格納（登録）する処理を行う（ＵＰ１０２）。また登録部１１は、利用者からの指示に応じて、ＵＰ１０１の内容（バージョン）の更新の場合、プール５０の該当ＵＰ１０２のデータを利用者側からの新データによって更新し、また登録解除の場合、プール５０の該当ＵＰ１０２のデータを削除する。

（１２） 実行制御部１２は、利用者（２）からのＵＰ実行指示（ａ２−１）に基づき、プール５０の該当ＵＰ１０２のデータ及び管理情報５１を参照して、対象のパブリッククラウド３の対象のＳＳ３１へ、ＵＰ実行指示（ａ２−２）及び対象のＵＰ１０２のデータを送信（コピー）（ａ２−３）する処理を行う。

［処理シーケンス］
図２は、本システム（図１）の各要素間の処理シーケンスを示す（S101等は処理ステップを表す）。

（S101） まず利用者（２）とリソースプロバイダ（１）との利用契約があり、対象としてどのパブリッククラウド３、どの共同利用型サーバ（ＳＳ）３１及びその機能などを利用するのか、及び課金方式（例えば従量課金とその詳細）の指定、などを含め、基本的な設定（ａ０）が行われる。例えば、利用者または事業者側の管理者等により、当該基本設定（ａ０）の操作がサーバ１０のＵＩ部６０に対し行われ、基本設定情報（図示しない）がリソースプロバイダ１内に保存される。

（S102） 利用者端末２から、利用者の操作に基づき、サーバ１０のＵＩ部６０を介して登録部１１に対し、ＵＰ１０１のデータを事前登録する指示（ａ１−１）が行われる。

（S103） 上記指示（ａ１−１）に従い、登録部１１は、利用者端末２からのＵＰ１０１のデータ（コピー）を取得（受信）し、プール５０内に、当該ＵＰ１０２のデータを、当該ＵＰ１０２の管理情報５１（具体例は図３）を付けて格納する。

（S104） 登録済みの状態で、利用者端末２から、利用者の操作に基づく任意タイミングで、サーバ１０のＵＩ部６０を介して実行制御部１２に対し、ＵＰ実行指示（ａ２−１）を送信する。実行制御部１２は当該指示（ａ２−２）を受信する。

（S105） 実行制御部１２は、上記指示（ａ２−２）に従い、プール５０内の該当のＵＰ１０２データ及び管理情報５１を参照・取得し、対象パブリッククラウド３の対象ＳＳ３１へ、まず対象ＵＰの実行指示（ａ２−２）を送信する。ここではまだＵＰ１０２データは送信しない。

（S106） 対象パブリッククラウド３の対象ＳＳ３１は、上記指示（ａ２−２）を受けると、例えば、当該ＳＳ３１で対象ＵＰの実行が可能な状態である場合（「ＯＫ」）は、そのＯＫの旨をサーバ１０へ応答する。また不可能な状態である場合（「ＮＧ」）は、そのＮＧの旨を応答する。上記状態（ＯＫ／ＮＧ）は、例えばＳＳ３１の負荷やリソースの状況に応じて判断される。

（S107） 実行制御部１２は、対象ＳＳ３１から上記ＯＫの応答を受けた場合は、該当のＵＰ１０２のデータ（そのコピー）をネットワークを介して対象パブリッククラウド３の対象ＳＳ３１へ送信する（ａ２−３）。対象ＳＳ３１は、当該ＵＰデータを受信・取得する。

（S108） 続いて、対象ＳＳ３１は、当該ＳＳ３１上で、上記指示され受信した対象のＵＰ（１０２）の処理を起動（開始）させる（ＵＰ１０３）。なおＵＰ１０３がバッチ処理である場合、所定の日時で起動する。

（S109） エージェント３２は、対象ＳＳ３１の動作・状態をモニタしている。例えばS108で対象ＳＳ３１がＵＰ１０３の処理を起動した時、そのことを示すモニタデータ（ａ４）を発行し、ネットワークを介して、モニタ部４１へ送信する。モニタ部４１は、当該モニタデータ（ａ４）を受信し、履歴情報（モニタ情報４３）として記録する。

（S110） 対象ＳＳ３１では、該当ＵＰ１０３は、適宜、パブリッククラウド３のリソース（サービス）３０を利用しながら、自身の所定の処理（例えばバッチ処理）を実行する。ＳＳ３１のプロセッサ、メモリ、通信インタフェース等の公知の要素を用いて当該プログラム処理が実行される。また必要に応じて利用者端末２からネットワークを介してＳＳ３１のＵＰ１０３へアクセスして処理を行ってもよい（ａ６）。

（S111） 対象ＳＳ３１は、当該ＳＳ３１上の該当のＵＰ１０３の処理を所定の契機で停止（終了）させる。例えばＵＰ１０３がバッチ処理である場合、所定の日時の処理が終わると起動終了する。またこの契機は、利用者（２）側からのＵＰの停止の指示によるものとしてもよい。この場合、前述同様に、指示を受けた実行制御部１２から対象ＳＳ３１へ該当ＵＰ１０３の停止の指示を送信し、ＳＳ３１がＵＰ１０３の稼働を停止させる。

（S112） 前述同様に、エージェント３２は、対象ＳＳ３１上のＵＰ１０３の処理の終了をモニタしており、当該終了した時、そのことを示すモニタデータ（ａ４）を発行し、ネットワークを介して、モニタ部４１へ送信する。モニタ部４１は、当該モニタデータ（ａ４）を受信し、履歴情報（モニタ情報４３）として記録する。モニタ部４１は、モニタデータ（ａ４）及びモニタ情報４３を参照することにより、ＳＳ３１及びＵＰ１０３の動作・状態を把握できる。特に上記ＵＰ１０３がバッチ処理の場合は、所定の日時のみの起動の状況がモニタされる。

（S113） 課金部４２は、モニタ部４１と連携し、ＳＳ３１及びＵＰ１０３の動作・状態を示すモニタ情報４３等を参照し、該当利用者の課金設定情報（課金方式）に基づいた課金計算処理（例えばＵＰ１０３の処理の稼働時間に応じた従量課金）を行う。課金部４２は、課金計算の結果情報を記録し、利用者（２）への課金請求の通知（ａ５）を行ったり、ＵＩ部６０で表示するＷｅｂページに課金請求情報を表示させる。

上記モニタ部４１または課金部４２は、モニタ情報４３から課金計算用の情報を別途作成して保存してもよい。課金方式に応じて、例えばＵＰ１０３の処理でリソース３０を使用した量の情報や、ＵＰ１０３の処理の開始から終了までの時間の情報などを作成してもよい。

［管理情報］
図３は、サーバ（主制御部）１０で管理するＵＰ１０２の管理情報５１の構成例を示す。管理情報５１で管理する情報項目の例として、（ａ）ＵＰ情報、（ｂ）利用者情報、（ｃ）対象パブリッククラウド情報、（ｄ）対象共同利用型サーバ（ＳＳ）情報、（ｅ）課金方式、等を有し、更にオプション情報として、（ｆ）対象機能、（ｇ）タイプ、等を有する。

（ａ）ＵＰ情報は、ＵＰ１０１の識別情報（ＩＤ）やアドレス等である。例えば「ＵＰ＃Ａ１」等で示す。（ｂ）利用者情報は、ＵＰ１０１の利用者（２）のＩＤやアドレス等である。例えば「利用者Ａ」等で示す。（ｃ）対象パブリッククラウド情報は、当該ＵＰを稼働させる対象となるパブリッククラウド３のＩＤやアドレス等である。例えば「パブリッククラウドＡ」等で示す。（ｄ）対象共同利用型サーバ（ＳＳ）情報は、当該ＵＰを稼働させる対象となるＳＳ３１のＩＤやアドレス等である。例えば「ＳＳ＃Ａ１」等で示す。対象パブリッククラウド３内に複数のＳＳ３１が存在する場合はそれらの中から指定することができる。

（ｅ）課金方式は、課金設定情報として、例えば当該ＵＰ（１０３）の稼動に応じた従量課金方式などを選択可能とする。

（ｆ）対象機能は、対象ＳＳ３１の持つ機能のうち、当該ＵＰで使用したい機能（実行クラス）を示す情報である。機能の例としてＰＤＦ機能の有無などがある。ＳＳ３１毎に機能が異なる場合は上記（ｄ）対象ＳＳ情報で指定すればよい。

（ｇ）タイプは、例えばＳＳ３１の共同利用のタイプ（方式）を指定する情報である。例えばパブリッククラウド３内の特定のＳＳ３１のみでＵＰ１０３を稼働させることや、パブリッククラウド３内の複数の任意のＳＳ３１でＵＰ１０３を稼働させることや、更には、パブリッククラウド３内の複数のＳＳ３１における利用の優先順位の指定、等が挙げられる（後述）。

［利用例］
図４では、本システム（図１）のリソースプロバイダ１を介して複数の利用者（２）（複数のＵＰ１０１）がそれぞれパブリッククラウド３（ＳＳ３１）を利用する例を示している。利用者Ａ（端末Ａ１），利用者Ｂ（端末Ｂ１），利用者Ｃ（端末Ｃ１，Ｃ２），利用者Ｄ（端末Ｄ１）を有し、パブリッククラウドＡ（ＳＳ＃Ａ１），パブリッククラウドＢ（ＳＳ＃Ｂ１），パブリッククラウドＣ（ＳＳ＃Ｃ１，ＳＳ＃Ｃ２，ＳＳ＃Ｃ３）を有する。

利用者Ａ（端末Ａ１）は、第１のプログラムであるＵＰ＃Ａ１を登録し、対象のパブリッククラウドＡのＳＳ＃Ａ１上で稼働させる。また第２のプログラムであるＵＰ＃Ａ２を登録し、対象のパブリッククラウドＢのＳＳ＃Ｂ１上で稼働させる。

利用者Ｂ（端末Ｂ１）は、ＵＰ＃Ｂ１を登録し、対象のパブリッククラウドＢのＳＳ＃Ｂ１上で稼働させる。利用者Ｃ（端末Ｃ１）は、ＵＰ＃Ｃ１を登録し、対象のパブリッククラウドＢのＳＳ＃Ｂ１上で稼働させる。ＳＳ＃Ｂ１上では、ＵＰ＃Ａ２，ＵＰ＃Ｂ１，ＵＰ＃Ｃ１を含む複数のＵＰ１０３が共同で稼働する。

利用者Ｃ（端末Ｃ２）は、ＵＰ＃Ｃ２を登録し、対象のパブリッククラウドＣのＳＳ＃Ｃ１上で稼働させる。利用者Ｄ（端末Ｄ１）は、ＵＰ＃Ｄ１を登録し、対象のパブリッククラウドＣのＳＳ＃Ｃ２上で稼働させる。パブリッククラウドＣ内のＳＳ＃Ｃ１，ＳＳ＃Ｃ２，ＳＳ＃Ｃ３でそれぞれＵＰ１０３が稼動する。

［詳細構成例］
次に、図５を用いて、上述の実施の形態に基づいたより詳しい構成例について説明する。基本構成は図１等と同様であり、異なる構成について以下説明する。

図５において、対象のパブリッククラウド３内に、利用者プログラム（ＵＰ）を格納するためのローカルプール７０を有する。ローカルプール７０は、リソースプロバイダ１側のプール５０と対応関係であり、ストレージやＤＢ等で実現され、プール５０のＵＰ１０２のデータのコピーをＵＰ１０４として格納する。またＵＰ１０４にはプール５０側と同様に必要な管理情報が付与される。

また、対象のパブリッククラウド３内に、複数の共同利用型サーバ（ＳＳ）３１を設ける。例えばＳＳグループ５００における、ＳＳ＃Ａ１，ＳＳ＃Ａ２，ＳＳ＃Ａ３の３つのＳＳ３１を示す。ＳＳグループ５００の各ＳＳ３１は、前述同様にリソース３０を利用する。また複数のＳＳ３１に併せて、各エージェント３２が稼働し、各ＳＳ３１の動作・状態を前述同様にモニタする。例えばＳＳ３１ごとのエージェント３２（Ａ＃Ａ１，Ａ＃Ａ２，Ａ＃Ａ３）を有する。

リソースプロバイダ１の制御部１０の実行制御部１２は、初回、プール５０のＵＰ１０２データを、ローカルプール７０へ送信（コピー）し格納させる（ｂ１）。また２回目以降の場合、実行制御部１２は、プール５０のＵＰ１０２データと、ローカルプール７０のＵＰ１０４データとの違い（バージョン等）をチェックし、最新データへの更新が必要な場合はプール５０のＵＰ１０２のデータを送信（コピー）してローカル（７０）側のＵＰ１０４データを更新させ、必要でない場合は送信しない（ｂ２）。これによりリソースプロバイダ１とパブリッククラウド３との通信を抑制する。

パブリッククラウド３側で、ローカルプール７０の管理・参照は、例えばＳＳ３１により行う。各ＳＳ３１は、ローカルプール７０にアクセスし、ローカルプール７０内のＵＰ１０４データ及び管理情報を読み書きする（ｂ５）。

また、前述の利用者（２）からの指示に基づきＳＳ３１上でＵＰ１０３を稼働させる実行制御の際には、ＳＳグループ５００（候補）の中から当該ＵＰ１０３を稼働させる対象となるＳＳ３１を選択可能である（ｂ３）。例えばパブリッククラウド３側（各ＳＳ３１）で、当該ＵＰ１０４を稼働させる１つのＳＳ３１を動的に決定する（ｂ４）。例えば複数のＳＳ３１の負荷・リソース状況を比較し、負荷が少ない良好な状態のＳＳ３１を選択する。当該選択された１つのＳＳ３１（例：ＳＳ＃Ａ１）は、ローカルプール７０の該当ＵＰ１０４データ（コピー）を取り出し、当該ＳＳ３１（ＳＳ＃Ａ１）上で稼働させる。

また、上記動的な決定に限らず、１つのＳＳ３１を利用者（２）が選択（指示）する形としてもよいし、複数の候補のＳＳ３１の中から順番に１つを選択する形などとしてもよい。

また、パブリッククラウド３内に備える複数のＳＳ３１（５００）としては、同タイプのＳＳ３１のみでなく、各種のタイプ（例えばサーバ種別や機能が異なる）のＳＳ３１を並存させてもよい。例えば、機能が異なるＳＳ３１として、ＰＤＦ機能を持つＳＳ３１と持たないＳＳ３１とを設ける。この場合、利用者（ＵＰ）の設定や指示などに応じて、所望のＳＳ３１の機能（例：ＰＤＦ機能）を選択して実行させるように制御する（図３の５１のｆの対象機能でも設定可能）。利用者（２）側からのＵＰ実行指示（前記ａ２−１）の際に、利用者の所望の機能（例：ＰＤＦ機能）に対応する実行クラスを指定可能とする。この場合は指定に応じた実行クラス（機能）を持つＳＳ３１が選択されることになる。

また、複数のＳＳ３１から選択可能とする場合、利用者（２）側からの設定や指示などにより、複数のＳＳ３１における選択の優先順位などを付けてもよい。実行制御の際には優先順位に応じてＳＳ３１が選択されることになる。

［効果等］
以上説明したように、本実施の形態によれば、リソースプロバイダ１を含む新しいモデルのシステムを提供することにより、利用者（２）のパブリッククラウド３の利用に係わる容易性（利便性）やコストパフォーマンス等を実現できる。特に、企業等の利用者（２）が各種のパブリッククラウド３を容易に利用して所望のアプリケーション処理やバッチ処理などを実現でき、なおかつコストパフォーマンスに優れるシステム（企業システム等）を構築することができる。事業者側は新しいモデルのサービスを提供できる。

特に、共同利用型サーバ（ＳＳ）３１でのＵＰ１０３の稼働分による従量課金方式などにより、ＵＰ１０１が例えばバッチ処理プログラムである場合も、限定された日時のバッチ処理の実行時間分の料金で済むことになるため、また利用者システム内のオンプレミスサーバ等の具備も必要ではないため、利用者（２）にとっては安価となる。

以上、本発明者によってなされた発明を実施の形態に基づき具体的に説明したが、本発明は前記実施の形態に限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能であることは言うまでもない。

本発明は、企業や一般個人などの不特定の利用者がネットワーク上のパブリッククラウド等のリソース・サービスを効果的に利用するための新しいシステムとして利用可能である。

１…リソースプロバイダ、２…利用者端末、３…パブリッククラウド、１０…サーバ（主制御部）、１１…登録部、１２…実行制御部、３０…リソース（サービス処理）、３１…共同利用型サーバ（ＳＳ）、３２…エージェント、４０…モニタシステム（サーバ）、４１…モニタ部、４２…課金部、４３…モニタ情報、５０…プール（利用者プログラム格納部）、５１…管理情報、６０…ＵＩ部（ユーザインタフェース部）、７０…ローカルプール、１０１，１０２，１０３，１０４…ＵＰ（利用者プログラム）。

Claims (8)

1. 複数の利用者の端末と、リソースプロバイダと、複数のパブリッククラウドとがネットワークで通信接続され、
   前記複数のパブリッククラウドは、各々に、前記リソースプロバイダが管理する共同利用型サーバが設置され、
   前記リソースプロバイダは、
   制御部と、記憶部と、を有し、
   前記制御部は、登録部と、実行制御部とを有し、
   前記記憶部は、前記利用者のプログラムのデータを管理情報と共に格納し、
   前記登録部は、前記利用者からの指示に基づき、前記利用者のプログラムのデータを管理情報と共に前記記憶部に格納する処理を行い、
   前記実行制御部は、前記利用者からの指示に基づき、前記記憶部の前記利用者のプログラムを対象のパブリッククラウドの対象の共同利用型サーバで実行させるように制御する処理を行い、
   前記実行制御部からの制御に基づき、前記対象のパブリッククラウドの対象の共同利用型サーバは、前記利用者のプログラムの処理を稼働させること、を特徴とするクラウド共用型リソース提供システム。
2. 請求項１記載のクラウド共用型リソース提供システムにおいて、
   前記リソースプロバイダは、モニタシステムを有し、
   前記モニタシステムは、前記対象のパブリッククラウドの対象の共同利用型サーバでの前記利用者のプログラムの処理の稼働の状態をモニタし、当該モニタ情報に基づいて、前記利用者に対する課金計算処理を行うこと、を特徴とするクラウド共用型リソース提供システム。
3. 請求項１記載のクラウド共用型リソース提供システムにおいて、
   前記利用者により、前記リソースプロバイダに対し、前記利用者のプログラムを稼働させる対象となるパブリッククラウド、及び共同利用型サーバを指定可能とすること、を特徴とするクラウド共用型リソース提供システム。
4. 請求項２記載のクラウド共用型リソース提供システムにおいて、
   前記モニタシステムは、前記利用者に対する課金方式として、前記対象のパブリッククラウドの対象の共同利用型サーバでの前記利用者のプログラムの処理の稼働時間または処理量に応じた従量課金方式の課金計算処理を行うこと、を特徴とするクラウド共用型リソース提供システム。
5. 請求項１記載のクラウド共用型リソース提供システムにおいて、
   前記パブリッククラウド内に、前記共同利用型サーバが複数設けられ、
   前記実行制御部は、前記記憶部の前記利用者のプログラムを対象のパブリッククラウドの複数の共同利用型サーバのうち選択された１つで実行されるように制御する処理を行うこと、を特徴とするクラウド共用型リソース提供システム。
6. 請求項５記載のクラウド共用型リソース提供システムにおいて、
   前記実行制御部は、前記対象のパブリッククラウドの複数の共同利用型サーバのうち１つを選択する際に、負荷が小さい１つを選択すること、を特徴とするクラウド共用型リソース提供システム。
7. 請求項５記載のクラウド共用型リソース提供システムにおいて、
   前記パブリッククラウド内の複数の共同利用型サーバは、機能が異なり、
   前記実行制御部は、前記対象のパブリッククラウドの複数の共同利用型サーバのうち１つを選択する際には、前記利用者からの指示または設定に基づいて、所定の機能を持つ１つを選択すること、を特徴とするクラウド共用型リソース提供システム。
8. 請求項１記載のクラウド共用型リソース提供システムにおいて、
   前記パブリッククラウド内に、前記リソースプロバイダ側の記憶部の前記利用者のプログラムのデータのコピーを管理情報と共に格納するローカル記憶部を有し、
   前記リソースプロバイダ側の記憶部の前記利用者のプログラムの第１のデータを、初回、前記パブリッククラウド側のローカル記憶部に第２のデータとしてコピーし、２回目以降は、前記第１と第２のデータで違いがある場合のみ前記ローカル記憶部へのコピーを行い、
   前記利用者のプログラムを対象のパブリッククラウドの対象の共同利用型サーバで実行させる際に、対象の共同利用型サーバは、前記ローカル記憶部の前記利用者のプログラムの第２のデータを取り出し、当該利用者のプログラムの処理を実行すること、を特徴とするクラウド共用型リソース提供システム。

Images