JP2009176097A - サービス管理装置及びプログラム - Google Patents

Abstract

【課題】複数の仮想テナントを構築したマルチテナントサービス提供システムにおいて、複数の仮想テナント間のリソース割当ての管理を公平に行う。
【解決手段】サービスの完了期限が決められている運用処理を行っている仮想テナント１８に割当てられているリソースが不足している場合に、サービス運用管理サーバ２の運用処理管理部１５が、ユーザごとにサービス実行時にリソースの制限が実施された制限実施時間を示す情報と、ユーザごとに仮想テナントによるサービスの契約期間を示す情報とに基づき、リソース制限の対象となる仮想テナントを選択し、選択した仮想テナントに割当てられているリソースを運用処理を行っている仮想テナントに割当てるとともに、リソースの制限が実施された制限実施時間を計測し、次回のリソース制限対象の仮想テナントの選択時に、計測した制限実施時間を利用する。
【選択図】図１

Description

本発明は、データ処理を伴うサービスをユーザに対して提供する際のリソース割当てを管理する技術に関し、例えば、仮想化技術を活用して実現される仮想テナントによりサービスを提供する際のリソース割当てを管理する技術に関する。
リソースとは、データ処理を伴うサービスを実現するために必要な計算機リソースであり、例えば、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）、メモリ等のハードウェアリソースが含まれる。

仮想化技術活用によりサービスサーバ上に構築した複数の仮想マシンにサービスソフトウェアを導入した仮想テナントを構築し、単一サービスサーバにて複数の仮想テナントにより複数の顧客にサービスを提供するマルチテナント環境がある。
このマルチテナント環境において、計算機リソースの上限に達し、ジョブの同時実行数に制約があるときに、優先度の高いユーザが利用する仮想テナントが処理実行を実施期間内に完了させるために、優先度の低いユーザが利用する仮想テナントから計算機リソースを剥奪し、優先度の高いユーザが利用する仮想テナントに計算機リソースを追加することで処理を実施させることが考えられる。
このとき、優先度が低い処理が複数存在するときに、公平に処理の実行権を管理する技術として文献１がある。
特開２００１−２４９８１９号公報

特許文献１では、同時実行数の上限値が設定されている環境において、優先度の高い処理が発生した場合には、実行中の他処理のうち制限される時間を超えて実行されている処理から実行権を剥奪し、優先度の高い処理に実行権を付与する。また、実行権が剥奪された処理に対して通常時の２倍の実行時間を与えることにより、次回の実行権剥奪対象の選定時に優遇することで優先度が低い処理が複数存在するときに、公平に処理の実行権を管理することを可能としている。

ただし特許文献１の場合、実行権が剥奪された処理に２倍の実行時間を与えるためには、実行権の剥奪対象の処理の実行時間を適切に予測できることが必要であるが、サービス提供環境の場合、ユーザから要求される対話的処理の実行に必要な時間を適切に予測することは不可能である。
また、実行権を剥奪された処理に対して一時的に実行時間もしくはリソース割当て優先度による優遇処置を与えた場合であったとしても、詳細にユーザのサービス利用タイミングを予測することは困難であり、ユーザのサービス利用タイミングとなる適切な時点で実行権が剥奪されたサービスに対して優先度優遇処理が適応されず、サービス利用期間内において、安定したサービス供給を実施出来ないという課題がある。

本発明は、上記のような課題を解決することを主な目的の一つとしており、ユーザのサービス契約期間、リソース割当てが制限された時間等に基づき、複数のサービス間のリソース割当ての管理を公平に行うことを主な目的の一つとする。

本発明に係るサービス管理装置は、
各々がユーザに対してデータ処理を伴うサービスを実行する複数のサービス実行手段を管理するサービス管理装置であって、
サービス実行手段ごとにサービスの実行先となるユーザを示すユーザサービス情報を管理するユーザサービス情報管理部と、
ユーザごとに優先順位を示す優先順位情報を管理する優先順位情報管理部と、
対応するサービス実行手段へのリソース割当てが制限されたリソース制限時間の実績値をユーザごとに示すリソース制限時間情報を管理するリソース制限時間情報管理部と、
特定の条件に合致する特定サービス実行手段がサービスを実行している際に、前記ユーザサービス情報に示されるユーザとサービス実行手段との対応付け及び前記優先順位情報に示される優先順位に基づいて、前記特定サービス実行手段よりも優先順位が低いサービス実行手段を１つ以上抽出し、前記ユーザサービス情報に示されるユーザとサービス実行手段との対応付け及び前記リソース制限時間情報に示されるリソース制限時間に基づいて、抽出したサービス実行手段の中から１つ以上のサービス実行手段をリソース制限対象サービス実行手段として選択する制限対象選択部と、
前記制限対象選択部により選択されたリソース制限対象サービス実行手段に割当てられているリソースの少なくとも一部を前記特定サービス実行手段に割当てるリソース管理部とを有することを特徴とする。

本発明によれば、リソース制限時間の実績値に基づいてリソース制限対象サービス実行手段を選択するため、サービス提供時の通常の処理実施時間を的確に予測することが困難な場合であっても、リソース制限におけるサービス実行手段間の公平を図りつつ、特定サービス実行手段にサービスの提供のために必要なリソースを安定的に割当てることが可能となる。

実施の形態１．
本実施の形態では、リソースを共有する仮想テナントのサービス利用期間と利用期間内におけるリソース制限履歴情報に基づくリソース割付け優先度変更を判定することで、リソース割当ての公平を図るマルチテナントサービス提供技術を説明する。

図１は、本実施の形態に係るマルチテナント環境でのサービスリソース管理方式の機能要素を示す機能構成図である。

図１において、マルチテナントサービス提供システム１は、ネットワークを介してソフトウェア２０の機能をユーザ端末４にサービスとして提供するシステムである。

サービスサーバ３は、仮想化技術を施すことにより１つのサーバ機に１つまたは複数の仮想テナント１８を構築したサーバである。

仮想テナント１８は、ルータ２１を介して接続された１つまたは複数のユーザ端末４に提供するソフトウェア２０の機能を処理する仮想実行装置である。
仮想テナント１８が提供するサービスには、ソフトウェア２０によるデータ処理が含まれる。
また、仮想テナント１８は、サービス実行手段の例である。
なお、サービスサーバ３に含まれる仮想テナント１８は、ユーザ端末４からの要求に
応じてサービスを提供する対話型サービス等の非時限サービス（サービス完了期限が
定められていないサービス）と、サービス完了期限が定められている時限サービスを
実行する時限サービス（時限サービス実行手段）とを実行することが可能である。
図１では、時限サービス仮想テナントのみが示されているが、非時限サービス仮想テナントもサービスサーバに含まれている。
また、以下では、時限サービスを運用処理ともいう。
各仮想テナント１８は特定のユーザと対応付けられており、原則として、ユーザは自己に対応付けられている仮想テナント１８のみからサービスの提供を受ける。

サービス運用管理サーバ２は、１つまたは複数のサービスサーバ３および１つまたは複数の仮想テナント１８に対する運用処理、パラメータ設定を行うサーバである。
つまり、サービス運用管理サーバ２は、サービス実行手段たる複数の仮想テナントを管理するサービス管理装置の例に相当する。

なお、図１及び以降の説明では、サービスサーバ１〜サービスサーバｍの複数のサービスサーバが存在する場合を例にして説明するが、必ずしも複数のサービスサーバが存在していなくてもよく、マルチテナントサービス提供システム１に含まれるサービスサーバが１つであってもよい。

マルチテナントサービス提供システム１は、従来パッケージソフトウェアとしてスタンドアロン形式で動作するソフトウェア２０を低コストかつ迅速にサービス化することを目的とするシステムである。

サービス運用管理サーバ２は、サービス契約情報７に示される契約内容に基づきリソース管理部１２による仮想テナント１８へのリソース割付け設定、運用処理管理部１５による運用処理の実施管理、テナント管理部８によるサービスサーバ３と仮想テナント１８とユーザ端末４の一元管理を行う。
また、サービス運用管理サーバ２の各要素を管理者端末５から一元的に操作することも可能である。

サービス運用管理サーバ２において、契約管理部６は、仮想テナント１８の運営者と仮想テナント１８を利用するユーザとの間で結ばれたサービスの実行品質レベル等が示される情報をサービス契約情報７として管理する。
詳細は後述するが、サービス契約情報７は例えば図６に示す情報である。
図６に示す実行品質レベル５８の値は、ユーザ間におけるサービス実行時のリソース割当ての優先順位を表す値として機能する。
この意味で、サービス契約情報７は優先順位情報の例であり、契約管理部６は優先順位情報管理部の例である。

リソース管理部１２は、リソース設定情報２２とリソース割付け情報１３とリソース制限履歴情報１４とを管理し、仮想テナント１８へのリソース割付け値の変更を命令する。

リソース設定情報２２は、実行品質とリソース割付け値の対応関係を示す。
詳細は後述するが、リソース設定情報２２は、例えば図１０に示す情報であり、実行品質に対して、ＣＰＵやメモリといったリソースの割付け値が示され、また、優先度が示される。
また、リソース割付け情報１３は、例えば図２に示す情報であり、サービス契約情報７から取得したサービス実行品質に基づくサービスサーバ３上で稼動する仮想テナント１８へのリソース割付け設定値を格納した情報である。
リソース制限履歴情報１４は、例えば図３に示す情報であり、ユーザごとに仮想テナント１８に対するリソースの割当てが制限された制限実施時間、リソース制限が実施された実施時刻、リソースの制限の原因となったユーザのＩＤである優先ユーザＩＤ等が示される。
つまり、リソース制限履歴情報１４は、契約管理部６に格納されるサービス実行品質の下位実行品質を結ぶユーザが利用する仮想テナント１８へ実施したリソース割付けの制限実施時間３７や実施時刻３９など実施履歴情報を記録する。
リソース制限履歴情報１４の制限実施時間３７の項目に示される値は、仮想テナント１８へのリソース割当が制限された時間（リソース制限時間）の実績値である。
なお、リソース制限履歴情報１４はリソース制限時間情報の例であり、リソース管理部１２はリソース制限時間情報管理部の例である。

また、リソース管理部１２は、後述する運用処理管理部１５によりリソースの制限対象となるリソース制限対象仮想テナントが選択された場合に、リソース制限対象仮想テナントに割当てられているリソースの少なくとも一部を運用処理を実行中の時限サービス仮想テナントに割当てる。
また、リソース管理部１２は、リソースを割当てた時限サービス仮想テナントが運用処理を完了した際に、当該割当てたリソースをリソース制限対象仮想テナントに返却する。
また、リソース管理部１２は、運用処理を実行中の時限サービス仮想テナントにリソース制限対象仮想テナントのリソースの少なくとも一部を割当てた時点から、運用処理を実行中であった時限サービス仮想テナントが運用処理を完了しリソース制限対象仮想テナントにリソースを返却した時点までをリソース制限対象仮想テナントの制限実施時間として計測し、計測した制限実施時間をリソース制限対象仮想テナントのユーザに対応付けてリソース制限履歴情報１４に追加する。

テナント管理部８は、サービスサーバ情報９とユーザ情報１０とテナント情報１１を管理する。

詳細は後述するが、サービスサーバ情報９は、例えば図９に示す情報であり、ユーザ端末４がルータ２１を介して接続する仮想テナント１８を特定するために必要なＩＰアドレス８４とポート番号８５などのサービスサーバ３上に構築された仮想テナント１８の設定情報を格納する。
換言すると、サービスサーバ情報９は、仮想テナント１８ごとにサービスの実行先となるユーザを示す。サービスサーバ情報９は、ユーザサービス情報の例である。
また、ユーザ情報１０は、例えば図７に示す情報であり、マルチテナントサービス提供システム１を利用するユーザの会社法人等番号６４などの識別情報、仮想テナント１８の運営者とユーザとの間で締結された契約期間等が示される。
ユーザ情報１０は、契約期間情報の例である。
テナント情報１１は、例えば図８に示す情報であり、ユーザのサービス利用状況７４などを示す。
なお、テナント管理部８は、ユーザサービス情報たるサービスサーバ情報、契約期間情報たるユーザ情報を管理しており、ユーザサービス情報管理部及び契約期間情報管理部の例である。

運用処理管理部１５は、契約管理部６から取得したサービス契約情報に格納される契約情報に基づく運用処理の実施に必要な実行品質４３や予定開始時刻４５や予定実施時間４６や実施コマンド４８などの情報を格納した運用処理情報１６とすでに定義されている処理スケジュールを元に運用処理の実施を仮想テナントに命令する手段を有する。
運用処理情報１６は、例えば図４に示す情報である。
図４において、実行品質４３の値は、サービス契約情報７の実行品質５８の値に一致している。
運用処理情報１６には、運用処理（時限サービス）に関する情報のみが記述されており、運用処理情報１６の実行品質４３の項目も運用処理に対する実行品質の値のみが示されている。
一方、サービス契約情報７の実行品質５８では、運用処理に限らず、全サービスの実行品質の値が示されている。
運用処理情報１６に示される実行品質４３も、ユーザ間におけるリソース割当の優先順位を示す値であり、運用処理情報１６は優先順位情報の例である。
なお、後述するように、本実施の形態では、運用処理については、運用処理情報１６の実行品質４３の値に基づき図１０に示すリソース設定情報２２を検索して、優先度９０の値を参照することとしている。
また、以降の説明と異なり、リソース設定情報２２の優先度９０の値を参照することなく、実行品質４３の値を直接利用して、リソース制限の優先・非優先を決定してもよい。

運用処理管理部１５は、時限サービス仮想テナント１８が運用処理（時限サービス）の実行を開始した後、運用処理の完了が予測される時刻までに運用処理の実行が完了していない場合に、サービスサーバ情報９に示されるユーザと仮想テナント１８との対応付け及び運用処理情報１６、サービス契約情報７から導出される実行品質（優先順位）に基づいて、当該運用処理を実行している時限サービス仮想テナント１８よりも実行品質が低い仮想テナントを１つ以上抽出し、サービスサーバ情報９に示されるユーザと仮想テナントとの対応付け、リソース制限履歴情報１４に示される制限実施時間、ユーザ情報１０に示される契約期間に基づき、抽出した仮想テナントの中から１つ以上の仮想テナントをリソース制限実施対象仮想テナント（リソース制限対象サービス実行手段）として選択する。
リソース制限実施対象仮想テナントの選択は、例えば、運用処理管理部１５は、ユーザごとに、リソース制限履歴情報１４に示される制限実施時間をユーザ情報に示される契約期間で除算し、除算値にユーザごとに設定されている係数を乗算し、乗算値が小さい順にｎ（ｎ≧１）人のユーザを選択し、サービスサーバ情報９に示されるユーザと仮想テナントとの対応付けに基づき、選択したユーザに対応する仮想テナントをリソース制限実施対象仮想テナントとして選択する。
リソース制限実施対象仮想テナントの選択後は、前述のように、リソース管理部１２が、リソース制限実施対象仮想テナントに割当てられているリソースの少なくとも一部を運用処理を実行中の時限サービス仮想テナント１８に割当てる。

更に、運用処理管理部１５は、所定の条件下で、仮想テナントのサービスの実行を中止させるとともに、サービスの実行を中止させたユーザについて運用処理情報１６にサービスの中止回数を書き込む。
具体的には、運用処理情報１６の未実施回数４２の項目に、サービスの中止回数の値が書き込まれる。
運用処理情報１６は、サービス中止回数情報の例でもある。
また、運用処理管理部１５は、運用処理情報１６に示される未実施回数と所定の閾値とを比較し、閾値以上の未実施回数が示されているユーザについては、サービス契約情報７の実行品質（優先順位）を一時的に上昇させる。

なお、図４において、予定開始時刻４５とは、運用処理の実行を開始する予定時刻であり、予定実施時間４６とは、運用処理の実行に予定されている時間であり、可能終了時刻４７とは、運用処理の実行が完了していなければならない時刻である。
また、実施コマンド４８とは、実行する運用処理の内容を示すコマンドであり、運用処理管理部１５から運用処理エージェント１９に通知される。

このように、運用処理管理部１５は、優先順位情報管理部、制限対象選択部、サービス中止部、サービス中止回数情報管理部の例として機能する。

接続受付部３０は、ユーザ端末４からの接続による利用開始時に仮想テナントへのリソース割付けをリソース管理部１２に命令する。

図２は、リソース割付け情報１３の一例である。
リソース割付け情報１３は、ユーザＩＤ３１を識別子としてＣＰＵ利用優先度を示すＣＰＵ−Ｗｅｉｇｈｔ３２とＣＰＵ利用上限値を示すＣＰＵ−Ｃａｐ３３とメモリ利用上限値を示すメモリ割付値３４を有するレコードの集まりとして定義される。
ユーザが利用する仮想テナント１８が動作するサービスサーバ３を変更する場合には、リソース割付け情報１３に示される値を変更先のサービスサーバ３上の管理テナント１７を介して設定することで複数のサービスサーバ３にて構成されるマルチテナントサービス提供システム１を構築した場合において、仮想テナントの配置変更を可能とする。
リソース割付け情報１３は、ファイルやデータベースといった形で外部記憶装置に格納され、実行時にリソース管理部１２が読み込んでもよい。

図３は、リソース制限履歴情報１４の一例である。
管理ＩＤ３５を識別子としてユーザＩＤ３６とリソース割付けの制限実施時間３７とリソース割付け制限実施時点にてユーザが利用する仮想テナント１８が稼動するサービスサーバ３の識別子を示すサーバＩＤ３８と実施するリソース割付け制限の実施時刻３９とリソース割付け値制限を実施する元として優先されたユーザの識別子を示す優先ユーザＩＤ４０を有するレコードの集まりとして定義されるものである。
リソース制限履歴情報１４は、ファイルやデータベースといった形で外部記憶装置に格納され、実行時にリソース管理部１２が読み込んでもよい。
図３において、制限実施時間３７は、ユーザＩＤ３６の欄に示されるユーザが利用する仮想テナント１８に対するリソースの割当てが制限された時間の実績値である。また、実施時刻は、制限実施時間の開始時刻である。また、優先ユーザＩＤ４０は、リソースの制限の原因となったユーザのＩＤである。

図４は、運用処理情報１６の一例である。
ユーザＩＤ４１を識別子とし、未実施回数４２と、運用処理実行時の実施完了品質を示す実行品質４３と実行する運用処理の種別を示す実行種別４４と運用処理の実行開始時刻を示す予定開始時刻４５と予め見積もられた運用処理の実行に必要な時間を示す予定実施時間４６と運用処理実施のデッドラインを示す可能終了時刻４７と実行する運用処理の内容を示す実施コマンド４８を有するレコードの集まりとして定義される。
運用処理情報１６は、ファイルやデータベースといった形で外部記憶装置に格納され、実行時に運用処理管理部１５が読み込んでもよい。
実行品質４３が下位品質の場合に運用処理実施時のリソース割当てが不足したために処理実行を破棄した回数を管理する未実施回数４２を設けることにより、未実施回数が予め設定された閾値以上となった場合、一時的に実行品質４３を上位品質に昇格させることで有限期間内に運用処理の実施を完了させることができる。

図５は、運用処理管理部１５が運用処理実施履歴を記録する運用処理実施履歴テーブルの一例である。
運用処理実施履歴テーブルは、処理を識別する識別子５０、ユーザＩＤ５１と開始時刻５２と運用処理実施結果を示す実施結果５３と運用処理実施完了時刻を記録する終了時刻５４を有するレコードの集まりとして定義されるものである。
運用処理実施履歴テーブルは、ファイルやデータベースといった形で外部記憶装置に格納され、実行時に運用処理管理部１５が読み込んでもよい。

図６は、サービス契約情報７の一例である。
サービス契約情報７は、ユーザＩＤ５５を識別子とし、実行品質を設定する機能の種別を示す契約種別５６と契約種別５６内の分類を示す実行種別５７とサービスレベルを示す実行品質５８を有するレコードの集まりとして定義される。
接続受付部３０がユーザ端末４からの利用要求を受け付けたときにユーザＩＤ５５をキーとして契約管理部６から取得された実行品質５８の値に基づくリソース割付け値が仮想テナント１８に設定される。

図７は、ユーザ情報１０の一例である。
ユーザ情報１０は、ユーザＩＤ６１を識別子とし、利用継続期間を示す契約期間６２を有するレコードの集まりとして定義されるものである。
ユーザ識別情報として契約者名６３と現実世界においてユーザを一意に示す会社法人等番号６４を含むことにより、単一契約による複数ユーザ提供を行う場合に、ユーザの利用状況を契約者ごとに管理することができる。
ユーザ情報１０は、ファイルやデータベースといった形で外部記憶装置に格納され、実行時にテナント管理部８が読み込んでもよい。
会社法人等番号６４は、利用ユーザを特定する他の識別番号であってもよい。

図８は、テナント情報１１の一例である。
管理情報ＩＤ７１を識別子とし、ユーザＩＤ７２とサービスとして提供するソフトウェアを特定するソフトウェアＩＤ７３とユーザへのサービス提供の有無を示すサービス利用状況７４を有するレコードの集まりとして定義される。

図９は、サービスサーバ情報９の一例である。
サービスサーバ情報９は、サービスサーバ３で稼動する仮想テナント１８とユーザの関連を管理するテーブルであり、サービスサーバ３を特定するサーバＩＤ８１とユーザを特定するユーザＩＤ８２とサービスサーバ３上に構築された仮想テナントを特定する仮想テナントＩＤ８３と仮想テナント１８に設定されたＩＰアドレス８４とポート番号８５を有するレコードの集まりとして定義される。
サービス利用開始時には、新規契約ユーザに対して新たな仮想テナント１８がサービスサーバ３上に構築され、ルータ２１を介してユーザ端末４から接続されるために仮想テナント１８に設定されたＩＰアドレス８４とポート番号８５が記録される。
サービスサーバ情報９は、ファイルやデータベースといった形で外部記憶装置に格納され、実行時にテナント管理部８が読み込んでもよい。

図１０は、リソース設定情報２２の一例である。
サービス契約情報７の実行品質５８とサービスサーバ３で稼動する仮想テナント１８に設定されるリソース割付け値の対応関係を表すテーブルであり、実行品質８５、ＣＰＵ利用優先度を示すＣＰＵ−Ｗｅｉｇｈｔ８６とＣＰＵ利用上限値を示すＣＰＵ−Ｃａｐ８７とメモリ利用上限値を示すメモリ上限８８と優先度９０を有するレコードの集まりとして定義される。
優先度９０において、優先とは、仮想テナント１８がサービス実行する際に優先的にリソースが割当てられることを意味する。つまり、優先度９０が優先となっている仮想テナント１８がサービスを実行する際にリソースが不足している場合に、他の仮想テナント１８に割当てられているリソースを取得できることを意味する。一方、非優先とは、リソースの割当において優先的に扱われないことを意味する。
なお、本実施の形態では、運用処理（時限サービス）を行う時限サービス仮想テナ
ント１８では、優先度９０は優先又は非優先に設定されている。一定レベル以上の実
行品質の場合は、優先度９０は優先となる。
一方、サービス完了期限が定まっていないサービスを行う非時限サービス仮想テナン
ト１８でも、優先度９０は優先又は非優先に設定されている。一定レベル以上の実行
品質の場合は、優先度９０は優先となる。
また、図１０の例では、優先・非優先の２段階としているが、３段階以上の優先度を設けてもよい。

サービスサーバ３は、ユーザ端末４から接続され、ソフトウェア２０の機能をサービスとして提供する仮想実行装置である仮想テナント１８とリソース管理部１２からの命令を受け取り仮想テナント１８へサービスサーバ３のＣＰＵ優先度（ＣＰＵ−Ｗｅｉｇｈｔ）、ＣＰＵ利用上限（ＣＰＵ−Ｃａｐ）、メモリ利用上限（メモリ上限）からなる計算機リソース割付け値を設定する管理テナント１７を有する。

時限サービス仮想テナント１８は、ルータ２１を介して接続するユーザ端末４へ提供するソフトウェア２０とサービス運用管理サーバ２上の運用処理管理部１５から通知される実施コマンドを受け取り、仮想テナント１８上で実行する運用処理エージェント１９を有する仮想化実行装置である。

マルチテナントサービス提供システム１は、一般的なソフトウェア２０を仮想テナント１８上で動作させ、ネットワークを介して接続したユーザ端末４が仮想テナント１８上でソフトウェア２０の機能を実行することにより一般的なソフトウェアをｗｅｂサービス用に改修することなくサービスとして提供することができる。

次に動作について説明する。
マルチテナントサービス提供システム１におけるサービスリソース管理処理の流れを図１１、図１２及び図１３のフローチャートを用いて説明する。

図１１〜図１３は、本実施の形態の運用処理管理部１５が主に実行する任意の一運用処理実行におけるサービス運用管理サーバ２におけるサービスリソース管理手順を示すフローチャートであり、運用処理の実行では、図１１〜図１３の手順が繰り返される。

ステップＳ９１において、運用処理情報１６に記録される予定開始時刻４５の到来が近づくと既知のスケジューラなどから運用処理管理部１５が起動され、運用処理管理部１５は、運用処理実行に必要な情報を運用処理情報１６より取得する。
また、運用処理管理部１５は、起動の原因となった予定開始時刻４５が示されるレコードのユーザＩＤ４１に一致するユーザＩＤ８２が含まれるレコードをサービスサーバ情報９において検索し、検索したレコードに示されるサーバＩＤ８１の値と仮想テナントＩＤ８３の値とＩＰアドレス８４の値とポート番号８５の値を取得する。

ステップＳ９２において、運用処理管理部１５は、運用処理情報１６より取得した実行品質４３の値を基にリソース設定情報２２から実行品質８５が一致するレコードの優先度９０を調べ、優先（保証契約）であれば（Ｓ９２でＹＥＳ）、ステップＳ９３に進み、非優先であれば（Ｓ９２でＮＯ）、ステップＳ１０８に進む。
前述したように、優先とは可能終了時刻４７に示される時刻までに実行種別４４に示される処理を多処理より優先的に実施完了させることを表す。
非優先とは、可能終了時刻４７に示される時刻までに実行種別４４に示される処理を他処理より優先的に実施完了させる処置を施さないことを表す。

ステップＳ９３において、運用処理管理部１５は、実行品質４３とユーザＩＤ４１をリソース管理部１２に図１４に示すプロトコルで通知し、リソース管理部１２はリソース設定情報２２を調べ、ユーザＩＤ４１に示すユーザが利用する仮想テナント１８のリソース割付け値（ＣＰＵ−Ｗｅｉｇｈｔ８６、ＣＰＵ−Ｃａｐ８７）の設定変更を管理テナント１７に図１５に示すプロトコルで通知し、リソース管理部１２はリソース設定情報２２から指定された実行品質４３に基づくリソース割付け値の設定処理を実施する。

図１４は、リソース割付けを通知する際のプロトコルの一例を示す図であり、先頭にリソース割付け対象となるユーザＩＤ１２０、それに続いて割付けるリソース値を示す実行品質１２１、リソース割付け条件として現在設定値への追加もしくは再設定を表すフラグとなるリソース追加フラグ１２２を付与して送信される。

図１５は、リソース管理部１２から管理テナント１７に通知されるプロトコルの一例であり、仮想テナントＩＤ１２５を先頭に、設定するＣＰＵ−Ｗｅｉｇｈｔ１２６、ＣＰＵ−Ｃａｐ１２７を付与して送信される。
図１５では、ＣＰＵ−Ｗｅｉｇｈｔ１２６、ＣＰＵ−Ｃａｐ１２７のみが示されているが、メモリ割付値や他のリソースの値が含まれていてもよい。
なお、管理テナント１７はリソース管理部１２からの通知を受信したときに、仮想テナント１８のリソース割付け設定値を既知の手段を利用して変更し、変更後はリソース管理部１２からの通知を待つ待機状態となる処理を繰り返すプログラムである。

ステップＳ９４において、運用処理管理部１５は、サービスサーバ情報９のＩＰアドレス８４とポート番号８５を基に仮想テナントＩＤ８３が示す仮想テナント１８上の運用処理エージェント１９に対して運用処理情報１６の実施コマンド４８を通知する。
つまり、運用処理管理部１５は、運用処理情報１６において、現在対象となっている運用処理についてのレコード（予定開始時刻２５の到来が近い運用処理についてのレコード）のユーザＩＤ４１の値と一致するユーザＩＤ８２の値が記述されているレコードをサービスサーバ情報９において検索し、検索したレコードの仮想テナントＩＤ８３に示される仮想テナント１８に対して、ＩＰアドレス８４及びポート番号８５を用いて、運用処理情報１６の実施コマンド４８を通知する。

図１６は、実施コマンド４８を通知する際のプロトコルの一例であり、先頭に処理の識別子１３０、それに続いて、処理の実行を指示する実行フラグ１３１を、それに続いてユーザＩＤ１３２、実行種別１３３、実施コマンド１３４、予定開始時刻１３５を付与して送信される。
なお、運用処理エージェント１９は、運用処理管理部１５からの実施コマンド４８を受け取り、仮想テナント１８上に既知の手段を利用して運用処理の実行を開始し、運用処理の実行開始を運用処理管理部１５に通知し、運用処理管理部１５からの通知を待つ待機状態を繰り返す処理を含むプログラムである。

図１７は、運用処理エージェント１９が運用処理管理部１５に運用処理の実行開始を通知する際のプロトコルの一例を示す図であり、先頭に処理の識別子１４０、それに続いて、開始を示す開始フラグ１４１を、それに続いてユーザＩＤ１４２、実行種別１４３、実施コマンド１４４、開始時刻１４５を付与して送信される。

ステップＳ９５において、運用処理管理部１５は、運用処理エージェント１９からの運用処理開始通知（図１７）を受信し、運用処理の正常開始を確認し、図５の運用処理実施履歴テーブルに識別子５０、ユーザＩＤ５１、開始時刻５２を有するレコードを挿入する。
図５の運用処理実施履歴テーブルに挿入される識別子５０、ユーザＩＤ５１及び開始時刻５２は、運用処理エージェント１９からの運用処理開始通知（図１７）に示される識別子１４０、ユーザＩＤ１４２及び開始時刻１４５である。

ステップＳ９６において、運用処理管理部１５は、運用処理の実施を管理するための運用処理の実施時間の計測を開始し、実施時間の監視を開始する。

ステップＳ９７において、運用処理管理部１５は、運用処理エージェント１９からの運用処理完了通知を受信した場合には、運用処理完了通知の内容を調べ、ステップＳ１０５に進む。
運用処理エージェント１９から運用処理完了通知が通知されない場合は、ステップＳ９８に進む。
運用処理完了通知とは、ステップＳ９５で実行開始が通知された運用処理の実行が完了したことを知らせる通知である。

図１８は、運用処理エージェント１９から通知される運用処理完了通知の通信プロトコル例を示す図である。
処理を識別する識別子１５０を先頭に、それに続いて完了を示す完了フラグ１５１を先頭に、ユーザＩＤ１５２、実行種別１５３、実施コマンド１５４、終了時刻１５５を付与して送信される。
運用処理管理部１５は、受信内容を調べ、図５の運用処理実施履歴テーブルの識別子５０を検索し、該当するレコードの実施結果５３と終了時刻５４を更新し、運用処理情報１６のユーザＩＤ４１と実行種別４４が一致するレコードの未実施回数４２を初期化する。
図５の運用処理実施履歴テーブルに挿入される実施結果５３及び終了時刻５４は、運用処理エージェント１９からの運用処理完了通知（図１８）に示される実施コマンド１５４から導かれる値（実施結果）及び終了時刻１５５である。

運用処理完了通知が未着の場合（Ｓ９７でＹＥＳ）は、ステップＳ９８において、運用処理管理部１５は、ステップＳ９６から計測している実施時間が運用処理情報１６の予定実施時間４６となった場合には、実行完了が可能と考えられる時間内に運用処理の実行が完了していない状態であるため、ステップＳ９３で設定された仮想テナント１８のリソース割付け値が運用処理の実施に対して不足していると判断し、ステップＳ９９へ進む。

ステップＳ９９において、運用処理管理部１５は、現在時刻を取得し、現在時刻に予定実施時間４６（運用処理情報１６）を加算した値が可能終了時刻４７（運用処理情報１６）以内であるか否かを判定し、可能終了時刻４７以内であれば（Ｓ９９でＹＥＳ）ステップＳ９５から計測している計測時間を初期化し、改めて予定実施時間４６の監視を行い、ステップＳ１００に進む。
現在時刻に予定実施時間４６を加算した値が可能終了時刻４７を超える場合（Ｓ９９でＮＯ）は、以上終了と判定し、ステップＳ１１１に進む。

ステップＳ１００において、運用処理管理部１５は、対象となっている運用処理（リソースが不足している判定された運用処理）の実行品質４３（運用処理情報１６）をもとにリソース設定情報２２の優先度９０を判定し、優先（保証契約）の場合は、ステップＳ１０１に進む。非優先の場合は、ステップＳ９７に進む。

ステップＳ１０１において、運用処理管理部１５は、リソース管理部１２からリソース制限履歴情報１４に格納されている履歴情報の中で上記運用処理を実行する時限サービス仮想テナント１８が稼動するサービスサーバ３の情報をステップＳ９１で取得したサーバＩＤ８１から特定し、サービスサーバ情報９に対してサーバＩＤ８１が一致するユーザＩＤ８２の一覧を取得し、テナント情報１１から前記ユーザＩＤ８２とユーザＩＤ７２が一致するユーザのサービス利用状況７４がＳ−ＡＣＴＩＶＥであるユーザＩＤ一覧を抽出する。
また、運用処理管理部１５は、抽出したユーザＩＤ８２の一覧の中で、サービス契約情報７からユーザの実行品質５８が下位契約（対象となっている運用処理に対する実行品質よりも下位の実行品質）であるユーザＩＤ５５の一覧を取得し、該一覧に含まれるユーザＩＤ５５ごとに制限実施時間３７の合算値を取得する。ここでは、同一のユーザに複数の制限実施時間３７が存在する場合を想定して制限実施時間３７の合算値としている。
また、本実施の形態では、例えば、時限サービス仮想テナント１８を利用するユーザの実行品質は原則として非時限サービス仮想テナント１８を利用するユーザの実行品質よりも高いことを想定している。このため、対話型サービス等を実行する非時限サービス仮想テナントが、後述するリソース制限実施対象仮想テナントになる場合が多い。
また、運用処理管理部１５は、ユーザ情報１０より取得した一覧に含まれるユーザＩＤ８２の契約期間６２を取得し、ステップＳ１０２に進む。同一ユーザに複数の契約期間６２が存在する場合は、契約期間の合算値を取得する。

ステップＳ１０２において、運用処理管理部１５は、上記運用処理を実施する時限サービス仮想テナント１８に対して追加するリソース割付け値を導出するために、ステップＳ１０１で取得した上記一覧に含まれるユーザＩＤ５５それぞれに対する制限実施時間３７の合算値と契約期間６２を基に、契約期間６２に対する制限実施時間３７の合算値の比率に対して制限係数８９を掛けた値を算出し、最小の算出値から順にｎ（ｎ≧１）個のユーザＩＤ５５を選択する。そして、選択したユーザＩＤ５５に示されるユーザが利用する仮想テナントをリソース制限実施対象仮想テナント（リソース制限対象サービス実行手段）と判定し、サービスサーバ情報９からリソース制限実施対象仮想テナントの仮想テナントＩＤ８３を取得し、ステップＳ１０３に進む。
運用処理管理部１５は、例えば、ユーザの契約期間（又は契約期間の合算値）を分母とし、ユーザへのリソース制限実施時間の合算値を分子とする制限実施時間比を算出し、この比率に対して制限計数８９を掛けた値を算出する。
なお、同じ算出値が２つ以上存在する場合は、例えば、リソース制限の実施時刻３９が古い順にユーザＩＤ５５を選択する。
また、リソース設定情報２２に制限係数８９を設けない場合は、ステップＳ１０１で取得した上記一覧に含まれるユーザＩＤ５５それぞれに対する制限実施時間３７の合算値と契約期間６２を基に、契約期間６２に対する制限実施時間３７の積算値の比率に掛ける処理を省略してもよい。

ステップＳ１０３において、運用処理管理部１５は、ステップＳ１０２で取得したリソース制限実施対象の仮想テナントＩＤ８３を利用するユーザのユーザＩＤ１２０と予め設定されたリソース制限実施時の実行品質１２１とリソース追加フラグ１２２を図１４を一例とするプロトコルにてリソース管理部１２に通知し、リソース管理部１２はリソース制限実施対象の仮想テナントのリソース割付け値の設定処理（リソースの剥奪）を実施する。
そして、リソース管理部１２は、リソース制限実施対象ユーザＩＤ５５とサーバＩＤ８１と上記運用処理を実施するユーザ（リソースが不足している仮想テナント１８を利用するユーザ）のユーザＩＤ４１をユーザＩＤ３６とサーバＩＤ３８と優先ユーザＩＤ４０とするレコードをリソース制限履歴情報１４に追加し、リソース制限時間計測を開始し、ステップＳ１０４に進む。
リソース制限履歴情報１４に記述されるユーザＩＤ４１は、リソース制限実施対象ユーザＩＤ５５（ユーザＩＤ１２０と同じ）であり、優先ユーザＩＤ４０は、運用処理を実施するユーザのユーザＩＤ４１である。

なお、リソース管理部１２は、運用処理管理部１５から、図１４に示すフォーマットにて、ユーザＩＤ１２０と実行品質１２１とリソース追加フラグ１２２を含む通知を受信したときに、指定されたユーザＩＤ１２０から現時点で設定されているリソース割付け値（リソース制限実施対象仮想テナントのリソースの値）をリソース割付け情報１３から取得し、指定された実行品質１２１に対応するリソース割付け値（運用処理を行っている時限サービス仮想テナント１８のリソースの値）をリソース設定情報２２から取得し、両取得した値を加算する手段を含む。
また、リソース管理部１２は、両リソース割付け設定値を加算したリソース割付け設定値を運用処理を行っている時限サービス仮想テナント１８が動作するサービスサーバ３上の管理テナント１７に図１５を一例とするプロトコルにて送信する。
また、予め定められたリソース制限実施時のリソース割付け値は、ＣＰＵ−Ｗｅｉｇｈｔの極小値としてもよい。

ステップＳ１０４において、運用処理管理部１５は、ステップＳ１０３にて実施されたリソース割付け値の変更により上記運用処理を優先的に実施させ、ステップＳ９７に進む。

なお、運用処理が完了して運用処理管理部１５が運用処理完了通知を受信するか（Ｓ９７でＹＥＳ）、現在時刻に予定実施時間４６を加算した値が可能終了時刻４７を超過する（Ｓ９９でＮＯ）まで、ステップＳ９７〜Ｓ１０４の処理が繰り返される。

運用処理管理部１５が運用処理完了通知を受信した場合（Ｓ９７でＹＥＳ）は、ステップＳ１０５において、運用処理管理部１５は、リソース制限履歴情報１４から上記運用処理を実施するユーザＩＤ４１が優先ユーザＩＤ４０に格納され、かつ制限実施時間３７が記録されていないレコードを検索し、リソース割付け制限が実施されるユーザＩＤ３６の有無を調べ、そのようなユーザＩＤ３６が存在する場合には、他の仮想テナントのリソースが制限されている場合であるため、管理ＩＤ３５の一覧を取得し、ステップＳ１０６に進む。
ユーザＩＤ３６が存在しない場合にはステップＳ１１０に進む。

ステップＳ１０６では、運用処理管理部１５は、上記管理ＩＤ３５一覧に関連するユーザＩＤ３６と一致するレコードをサービス契約情報７より検索し、同レコードの実行品質５８を取得し、ユーザＩＤ３６と実行品質５８をリソース管理部１２に通知し、リソース管理部１２はリソース設定情報２２を用いて実行品質５８に基づくリソース割付け値をユーザＩＤ３６が利用する仮想テナント（リソースが制限されていた仮想テナント）に設定し、リソース制限実施を解除し、ステップＳ１０７に進む。
つまり、運用処理が完了した際に、リソース管理部１２は運用処理に追加して割当てたリソースを、リソースの制限元の仮想テナントに返却する。

ステップＳ１０７において、運用処理管理部１５は、ステップＳ１０４で取得した管理ＩＤ３５の一覧に関連するユーザＩＤのリソース制限時間計測値を取得し、リソース制限履歴情報１４において、管理ＩＤ３５に関連する制限実施時間３７の値を更新し、ステップＳ１１０に進む。
次回のリソース制限対象の仮想テナントの選択時には、更新した制限実施時間３７の値を利用する。

ステップＳ１１０において、運用処理管理部１５は、処理を終了し、スケジューラからの起動待機状態となる。

他方、現在時刻に予定実施時間４６を加算した値が可能終了時刻４７を超過する場合（Ｓ９９でＮＯ）は、運用処理管理部１５は、ステップＳ１１１において、運用処理情報１６の実行品質４３を基にリソース設定情報２２から実行品質８５が一致するレコードの優先度９０を取得し、優先（保証契約）の場合は、ステップＳ１１２に進む。
非優先の場合は、ステップＳ１１３に進む。

ステップＳ１１１の判定において優先（保証契約）と判断した場合は、運用処理管理部１５は、ステップＳ１１２において、上位サービス契約を結ぶユーザの運用処理が可能終了時間４７内に実施完了しないため、異常実行が生じていると判定し、管理者端末５にアラート通知を行い、ステップＳ１１０に進む。

以上から、仮想テナント１８で実施される処理のサービスレベル契約として締結されたサービスレベルにて供給するためのサービスリソース管理において、リソース制限対象となったユーザの処理実施時間を的確に予測することが不可能な場合であっても、リソース制限履歴情報１４を利用することで、サービス利用中のリソース制限対象選定において優遇され、マルチテナントサービス提供システムにおいて公平に安定したサービス提供を可能とすることができる。
換言すれば、制限実施時間３７を参照し、リソースが制限された時間の実績値に基づいてリソース制限の対象となる仮想テナントを決定するため、リソース制限の対象となるサービスの通常の処理実施時間を的確に予測する必要がない。このため、処理実施時間の予測が困難な対話型サービスであっても、過去のリソースの制限時間に対応させて適正にリソースの制限とすることができ、リソース制限における仮想テナント間の公平を図りつつ、運用処理を行う時限サービス仮想テナントにサービスの提供のために必要なリソースを安定的に割当てることが可能となる。
また、リソース制限対象の仮想テナントに対して２倍の実行時間を与えるといった手当てを行う場合であっても、実際にリソースが制限された時間を基準にして付与する実行時間を決定することができる。
更には、リソース制限時間の実績値に基づいてリソース制限の対象となる仮想テナントを決定するため、特定の仮想テナント、特定のユーザに偏ってリソースが制限されるという事態を回避することができ、リソースの制限における仮想テナント間の公平を図ることができる。
また、契約期間も含めてリソース制限の対象となる仮想テナント決定するため、契約期間の長短に応じて適切にリソース制限における仮想テナント間の公平を図ることができる。

次に、ステップＳ９２の判定において優先（保証契約）でないと判断した場合（Ｓ９２でＮＯ）は、運用処理管理部１５は、ステップＳ１０８において、ステップＳ９２で取得した実行品質４３の値に対して予め設定されている未実施回数４２の閾値を取得し、運用処理情報１６の未実施回数４２が該閾値未満であるか調べる。
未実施回数４２が閾値未満である場合はステップＳ９３に進む。未実施回数４２が閾値以上である場合は、最低保証適用と判定し、ステップＳ１０９に進む。
なお、上記未実施回数の閾値は、実行品質４３に格納される値が複数の段階に区別される場合は、段階に応じて閾値を設定する場合と全ての段階にて同一の閾値を予め設定する場合を含む。

ステップＳ１０９において、運用処理管理部１５は、ステップＳ９２で取得したユーザＩＤ４１と同一レコードの実行品質４３の値を上位契約（より上位の実行品質）に変更し、ステップＳ９３に進む。
つまり、運用処理情報１６に閾値以上の未実施回数が示されている場合は、当該仮想テナントの優先順位を上昇させる。

また、ステップＳ１１１の判定において優先（保証契約）でないと判断した場合（Ｓ１１１でＮＯ）は、運用処理管理部１５は、ステップＳ１１３において、予定実施時間４６を超過した運用処理の実施破棄を運用処理エージェント１９に通知し、運用処理エージェント１９は仮想テナント１８で実行する運用処理を破棄し、運用処理管理部１５に運用処理破棄通知を返し、運用処理管理部１５は、運用処理破棄通知を受け取り、ステップＳ１１０に進む。

図１９は、運用処理破棄通知の通信プロトコルの一例を示す図である。
このプロトコルは、処理を識別する識別子１６０を先頭に、破棄フラグ１６１、ユーザＩＤ１６２、実行種別１６３、実施コマンド１６４を付与して運用処理エージェント１９に通知される。

図２０は、運用処理破棄完了通知の通信プロトコルの一例を示す。
処理を識別する識別子１７０を先頭に破棄完了フラグ１７１、ユーザＩＤ１７２、実行種別１７３、実施コマンド１７４を付与し、運用処理エージェント１９から運用処理管理部１５へ通知される。

次に、ステップＳ１１４において、運用処理管理部１５は、運用処理情報１６のユーザＩＤ４１と実行種別４４が一致するレコードを検索し、未実施回数４２の値を１追加させた値で更新し、識別子１７０を基に図５の運用処理実施履歴テーブルの識別子５０が一致するレコードを検索し、実施結果５３を未完了に更新し、ステップＳ１１０に進む。

以上から仮想テナント１８で実施される処理のサービスレベル契約を下位契約にて締結した場合においても運用処理情報１６の未実施回数４２を利用することで、マルチテナントサービス提供システムにおいて有限時間内で処理を完了することができる。

以上のように、マルチテナントサービス提供システムにおいて同時実行数の制限がある時に、下位サービス契約を結ぶユーザの利用する仮想テナントのリソース割付け値を制限することで、上位サービス契約を結ぶユーザの利用する仮想テナントの処理を優先的に実行させるときに、サービスリソース管理における下位サービスレベル契約を締結するユーザに対するリソース割付け制限履歴情報を定義し、過去のリソース制限履歴時間の最小積算値を利用するユーザをリソース割付け制限対象とすることで、次回の処理実施時間を適切に予測することが不可能であっても、リソース割付け対象となったユーザへの優遇処理を施すことができる。

また、サービス利用期間を記録し、リソース割付け制限対象となるユーザを判定するときにサービス利用期間に対するリソース割付け制限履歴時間の最小積算値の比率が最も小さいユーザをリソース割付け制限対象と判定することで、サービス利用期間が短いユーザとサービス利用期間が長いユーザを公平にリソース割付け制限対象として判定することができる。

また、サービスレベル契約に応じたリソース割付け判定の重み付け係数を定義することにより、複数段階のサービスレベル契約を設けた場合において、リソース割付け制限対象となるユーザを判定する際に最下位レベル契約を締結するユーザのみがリソース割付け制限対象となることを防ぐことができる。

さらに、下位サービスレベル契約において処理の未実施回数に対する保証閾値を定義することにより、未実施回数が保証閾値を超える場合には一時的に上位サービスレベルに契約を昇格させることにより、下位サービスレベル契約を締結するユーザであっても有限期間内において、処理を実施完了することができる。

なお、以上の説明では、ユーザの契約期間を分母とし、ユーザへのリソース制限実施時間を分子とする制限実施時間比を用いてリソース制限対象の仮想テナントを決定することとしたが、リソース制限実施時間の長短のみに基づいてリソース制限対象の仮想テナントを決定してもよい。

以上、本実施の形態では、仮想化技術を施したサーバ上に複数の仮想テナントを構築したサービスサーバと、複数のサービスサーバに対するパラメータ設定、サービス運用情報を管理するサービス管理サーバを備えたマルチテナントサービス提供システムにおいて、
上記サービスサーバ上に、
該サービスサーバ上で稼動する仮想テナントのリソース割付け値を管理する管理部を備え、
上記サービス管理サーバ上に、
仮想テナントを利用するユーザと結ぶ契約情報と、
上記サービス管理サーバ上にユーザと仮想テナントとサービスサーバの関連を表すサービスサーバ情報と、
仮想テナントへのリソース割付け設定状態を表すリソース割付け情報と、
サービス利用継続期間において実施された仮想テナントへのリソース割付け制限履歴を記録する情報と、
仮想テナントが実行する処理実行に必要な運用処理情報と、
仮想テナントの処理実施を管理する管理部と、
を備え、
上記情報を基に上記処理実施管理部にユーザと締結した契約の一覧情報に基づく仮想テナントの処理実行の優劣を判定する手段と、
上記手段にてジョブの同時実行数に制約があるときに優先度が高いと判定した処理を完了させるために該処理を実行する仮想テナントに対するリソース割付け追加を実施するとき、割付け追加リソースを導出するためにリソースを制限するユーザを選定するため、リソース割付け制限情報から取得したリソース割付け制限実施時間を算出する手段と、
上記算出値を基に仮想テナントのリソース割付け値を剥奪し、上記リソース割付け追加を要求する仮想テナントへ剥奪したリソース割付け値を加算したリソース割付け値への変更を上記サービスサーバ上でリソース割付け値を管理する手段に指示する手段とを備えたことにより、
仮想テナントを利用するユーザと結んだ契約に基づきサービスを安定供給するリソース割付け制御をサービス利用継続期間内において公平に実施するマルチテナント環境でのサービスリソース管理方式について説明した。

また、本実施の形態では、
上記マルチテナントサービス提供システムにおいて、
サービス管理サーバ上に、
仮想テナントを利用するユーザと結ぶサービス契約の契約時間の積算値を含むユーザ情報と、
ユーザの契約期間の積算値を分母とし、ユーザへのリソース制限実施積算時間の積算値を分子とする制限実施時間比を算出する手段とを備えることにより、
契約期間に対する制限実施時間比の最小値を示すユーザをリソース制限対象と判定することにより、上記マルチテナントサービス提供システムにおいてサービス契約期間に基づき、公平なるリソース割付け制御を可能とする、マルチテナント環境でのサービスリソース管理方式について説明した。

また、本実施の形態では、
上記マルチテナントサービス提供システムにおいて、
上記サービス管理サーバ上に、
サービス管理サーバ上に仮想テナントを利用するユーザと結ぶ、１つまたは複数段階のサービスレベル契約を含むサービス契約情報と、
上記サービス契約段階に基づく重み付け係数を含むリソース設定情報と、
と備えたことにより、
上記優先度が高いと判定した処理を完了させるために該処理を実行する仮想テナントにソース割付け追加を要求した場合に、リソース割付け制限情報から取得したリソース割付け制限実施時間の最小積算値を算出する手段と、
最小積算値に対して上記重み付け係数を掛ける手段と、
を備えたことにより、
複数段階の最下位サービス契約を結ぶユーザのみがリソース制限対象となることなく公平に安定したサービス提供を可能とする、マルチテナント環境でのサービスリソース管理方式について説明した。

また、本実施の形態では、
上記マルチテナントサービス提供システムにおいて、
サービス管理サーバ上に、
仮想テナントが実行する処理を仮想テナントに通知する手段を備え、
仮想テナント上に、
上記手段から通知された処理の実行を管理する手段と、
サービス管理サーバに処理結果を通知する手段と、
を備えることにより上記処理結果が通知を受け取った際にリソース割付け制限対象となるユーザが利用する仮想テナントに対してリソース割付け制限実施前に設定されたリソース割付け値を設定することにより、
仮想テナントを利用するユーザと結ぶ契約に基づく、リソース割付け制御を可能とする、マルチテナント環境でのサービスリソース管理方式について説明した。

また、本実施の形態では、
上記マルチテナントサービス提供システムにおいて、
サービス管理サーバ上に、
仮想テナントの処理の未実施回数を格納する手段と、
処理実施における未実施回数の最低保証閾値を含む仮想テナントを利用するユーザと締結したサービス契約情報と、
上記サービス契約情報に基づく処理実施優先度を一時的に変更する手段と備えることにより、未実施回数が、最低保証閾値を超えるときに、一時的にサービス契約を上位契約に昇格させることにより、下位契約であっても有限期間内に処理の実施を可能とする、マルチテナント環境でのサービスリソース管理方式について説明した。

最後に、実施の形態１に示したマルチテナントサービス提供システム１のハードウェア構成例について説明する。
図２１は、実施の形態１に示すマルチテナントサービス提供システム１のハードウェア資源の一例を示す図である。
なお、図２１の構成は、あくまでもマルチテナントサービス提供システム１のハードウェア構成の一例を示すものであり、マルチテナントサービス提供システム１のハードウェア構成は図２１に記載の構成に限らず、他の構成であってもよい。

図２１において、マルチテナントサービス提供システム１は、プログラムを実行するＣＰＵ９１１（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ、中央処理装置、処理装置、演算装置、マイクロプロセッサ、マイクロコンピュータ、プロセッサともいう）を備えている。
ＣＰＵ９１１は、バス９１２を介して、例えば、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）９１３、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）９１４、通信ボード９１５、表示装置９０１、キーボード９０２、マウス９０３、磁気ディスク装置９２０と接続され、これらのハードウェアデバイスを制御する。
更に、ＣＰＵ９１１は、ＦＤＤ９０４（Ｆｌｅｘｉｂｌｅ Ｄｉｓｋ Ｄｒｉｖｅ）、コンパクトディスク装置９０５（ＣＤＤ）、プリンタ装置９０６、スキャナ装置９０７と接続していてもよい。また、磁気ディスク装置９２０の代わりに、光ディスク装置、メモリカード（登録商標）読み書き装置などの記憶装置でもよい。
ＲＡＭ９１４は、揮発性メモリの一例である。ＲＯＭ９１３、ＦＤＤ９０４、ＣＤＤ９０５、磁気ディスク装置９２０の記憶媒体は、不揮発性メモリの一例である。これらは、記憶装置の一例である。
通信ボード９１５、キーボード９０２、マウス９０３、スキャナ装置９０７、ＦＤＤ９０４などは、入力装置の一例である。
また、通信ボード９１５、表示装置９０１、プリンタ装置９０６などは、出力装置の一例である。

通信ボード９１５は、ネットワークに接続されている。例えば、通信ボード９１５は、ＬＡＮ（ローカルエリアネットワーク）に接続されていてもよく、また、図１に示すように、ルータ２１を介してインターネット、ＷＡＮ（ワイドエリアネットワーク）などに接続されていてもよい。

磁気ディスク装置９２０には、仮想マシンモニタ９２１、ホストＯＳ９２２（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）９２２、プログラム群９２３、ファイル群９２４が記憶されている。
プログラム群９２３のプログラムは、ＣＰＵ９１１、仮想マシンモニタ９２１、ホストＯＳ９２２により実行される。
また、仮想マシンモニタ９２１自身がホストＯＳ９２２の機能を含む場合や、ホストＯＳ９２２内に仮想マシンモニタ９２１が存在する場合もある。

ＲＯＭ９１３には、ＢＩＯＳ（Ｂａｓｉｃ Ｉｎｐｕｔ Ｏｕｔｐｕｔ Ｓｙｓｔｅｍ）プログラムが格納され、磁気ディスク装置９２０にはブートプログラムが格納されている。
マルチテナントサービス提供システム１の起動時には、ＲＯＭ９１３のＢＩＯＳプログラム及び磁気ディスク装置９２０のブートプログラムが実行され、ＢＩＯＳプログラム及びブートプログラムにより仮想マシンモニタ９２１、ホストＯＳ９２２が起動される。

プログラム群９２３には、例えば、図１に示される契約管理部６、テナント管理部８、リソース管理部１２、運用処理管理部１５及び接続受付部３０を実現するプログラムが含まれる。
また、プログラム群９２３には、サービスサーバ３及びその内部構成を実現するプログラムが含まれる。
また、ファイル群９２４には、例えば、図１に示されるサービス契約情報７、サービスサーバ情報９、ユーザ情報１０、テナント情報１１、リソース割付け情報１３、リソース制限履歴情報１４、運用処理情報１６、リソース設定情報２２等が含まれる。

ファイル群９２４には、実施の形態１の説明において、「〜の判断」、「〜の計算」、「〜の比較」、「〜の通知」、「〜の更新」、「〜の設定」、「〜の登録」、「〜の選択」、「〜の取得」等として説明している処理の結果を示す情報やデータや信号値や変数値やパラメータが、「〜ファイル」や「〜データベース」の各項目として記憶されている。
「〜ファイル」や「〜データベース」は、ディスクやメモリなどの記録媒体に記憶される。ディスクやメモリなどの記憶媒体に記憶された情報やデータや信号値や変数値やパラメータは、読み書き回路を介してＣＰＵ９１１によりメインメモリやキャッシュメモリに読み出され、抽出・検索・参照・比較・演算・計算・処理・編集・出力・印刷・表示などのＣＰＵの動作に用いられる。
抽出・検索・参照・比較・演算・計算・処理・編集・出力・印刷・表示のＣＰＵの動作の間、情報やデータや信号値や変数値やパラメータは、メインメモリ、レジスタ、キャッシュメモリ、バッファメモリ等に一時的に記憶される。
また、実施の形態１で説明しているフローチャートの矢印の部分は主としてデータや信号の入出力を示し、データや信号値は、ＲＡＭ９１４のメモリ、ＦＤＤ９０４のフレキシブルディスク、ＣＤＤ９０５のコンパクトディスク、磁気ディスク装置９２０の磁気ディスク、その他光ディスク、ミニディスク、ＤＶＤ等の記録媒体に記録される。また、データや信号は、バス９１２や信号線やケーブルその他の伝送媒体によりオンライン伝送される。

また、実施の形態１の説明において「〜部」、として説明しているものは、「〜回路」、「〜装置」、「〜機器」であってもよく、また、「〜ステップ」、「〜手順」であってもよい。すなわち、「〜部」として説明しているものは、ＲＯＭ９１３に記憶されたファームウェアで実現されていても構わない。或いは、ソフトウェアのみ、或いは、素子・デバイス・基板・配線などのハードウェアのみ、或いは、ソフトウェアとハードウェアとの組み合わせ、さらには、ファームウェアとの組み合わせで実施されても構わない。ファームウェアとソフトウェアは、プログラムとして、磁気ディスク、フレキシブルディスク、光ディスク、コンパクトディスク、ミニディスク、ＤＶＤ等の記録媒体に記憶される。プログラムはＣＰＵ９１１により読み出され、ＣＰＵ９１１により実行される。すなわち、プログラムは、実施の形態１の「〜部」としてコンピュータを機能させるものである。あるいは、実施の形態１の「〜部」の手順や方法をコンピュータに実行させるものである。

このように、実施の形態１に示すマルチテナントサービス提供システム１は、処理装置たるＣＰＵ、記憶装置たるメモリ、磁気ディスク等、入力装置たるキーボード、マウス、通信ボード等、出力装置たる表示装置、通信ボード等を備えるコンピュータであり、上記したように「〜部」として示された機能をこれら処理装置、記憶装置、入力装置、出力装置を用いて実現するものである。

実施の形態１に係るマルチテナントサービス提供システムの構成例を示す図。 実施の形態１に係るリソース割付け情報の例を示す図。 実施の形態１に係るリソース制限履歴情報の例を示す図。 実施の形態１に係る運用処理情報の例を示す図。 実施の形態１に係る運用処理実施履歴テーブルの例を示す図。 実施の形態１に係るサービス契約情報の例を示す図。 実施の形態１に係るユーザ情報の例を示す図。 実施の形態１に係るテナント情報の例を示す図。 実施の形態１に係るサービスサーバ情報の例を示す図。 実施の形態１に係るリソース設定情報の例を示す図。 実施の形態１に係るサービス運用管理サーバの動作例を示すフローチャート図。 実施の形態１に係るサービス運用管理サーバの動作例を示すフローチャート図。 実施の形態１に係るサービス運用管理サーバの動作例を示すフローチャート図。 実施の形態１に係る通知プロトコルの例を示す図。 実施の形態１に係る通知プロトコルの例を示す図。 実施の形態１に係る通知プロトコルの例を示す図。 実施の形態１に係る通知プロトコルの例を示す図。 実施の形態１に係る通知プロトコルの例を示す図。 実施の形態１に係る通知プロトコルの例を示す図。 実施の形態１に係る通知プロトコルの例を示す図。 実施の形態１に係るマルチテナントサービス提供システムのハードウェア構成例を示す図。

符号の説明

１ マルチテナントサービス提供システム、２ サービス運用管理サーバ、３ サービスサーバ、４ ユーザ端末、５ 管理者端末、６ 契約管理部、７ サービス契約情報、８ テナント管理部、９ サービスサーバ情報、１０ ユーザ情報、１１ テナント情報、１２ リソース管理部、１３ リソース割付け情報、１４ リソース制限履歴情報、１５ 運用処理管理部、１６ 運用処理情報、１７ 管理テナント、１８ 仮想テナント、１９ 運用処理エージェント、２０ ソフトウェア、２１ ルータ、２２ リソース設定情報、３０ 接続受付部。

Claims (10)

1. 各々がユーザに対してデータ処理を伴うサービスを実行する複数のサービス実行手段を管理するサービス管理装置であって、
   サービス実行手段ごとにサービスの実行先となるユーザを示すユーザサービス情報を管理するユーザサービス情報管理部と、
   ユーザごとに優先順位を示す優先順位情報を管理する優先順位情報管理部と、
   対応するサービス実行手段へのリソース割当てが制限されたリソース制限時間の実績値をユーザごとに示すリソース制限時間情報を管理するリソース制限時間情報管理部と、
   特定の条件に合致する特定サービス実行手段がサービスを実行している際に、前記ユーザサービス情報に示されるユーザとサービス実行手段との対応付け及び前記優先順位情報に示される優先順位に基づいて、前記特定サービス実行手段よりも優先順位が低いサービス実行手段を１つ以上抽出し、前記ユーザサービス情報に示されるユーザとサービス実行手段との対応付け及び前記リソース制限時間情報に示されるリソース制限時間に基づいて、抽出したサービス実行手段の中から１つ以上のサービス実行手段をリソース制限対象サービス実行手段として選択する制限対象選択部と、
   前記制限対象選択部により選択されたリソース制限対象サービス実行手段に割当てられているリソースの少なくとも一部を前記特定サービス実行手段に割当てるリソース管理部とを有することを特徴とするサービス管理装置。
2. 前記サービス管理装置は、更に、
   ユーザごとに、対応するサービス実行手段によるサービスの提供を受ける契約期間を示す契約期間情報を管理する契約期間情報管理部を有し、
   前記制限対象選択部は、
   前記ユーザサービス情報に示されるユーザとサービス実行手段との対応付け、前記リソース制限時間情報に示されるリソース制限時間及び前記契約期間情報に示される契約期間に基づいて、抽出したサービス実行手段の中から１つ以上のサービス実行手段をリソース制限対象サービス実行手段として選択することを特徴とする請求項１に記載のサービス管理装置。
3. 前記制限対象選択部は、
   ユーザごとに、前記リソース制限時間情報に示されるリソース制限時間と前記契約期間情報に示される契約期間とを用いて演算を行い、演算値に基づきいずれかのユーザを選択し、前記ユーザサービス情報に示されるユーザとサービス実行手段との対応付けに基づき、選択したユーザに対応するサービス実行手段をリソース制限対象サービス実行手段として選択することを特徴とする請求項２に記載のサービス管理装置。
4. 前記制限対象選択部は、
   ユーザごとに、前記リソース制限時間情報に示されるリソース制限時間を前記契約期間情報に示される契約期間で除算し、除算値が小さい順にｎ（ｎ≧１）人のユーザを選択し、前記ユーザサービス情報に示されるユーザとサービス実行手段との対応付けに基づき、選択したユーザに対応するサービス実行手段をリソース制限対象サービス実行手段として選択することを特徴とする請求項２又は３に記載のサービス管理装置。
5. 前記制限対象選択部は、
   ユーザごとに、前記リソース制限時間情報に示されるリソース制限時間を前記契約期間情報に示される契約期間で除算し、除算値にユーザごとに設定されている係数を乗算し、乗算値が小さい順にｎ（ｎ≧１）人のユーザを選択し、前記ユーザサービス情報に示されるユーザとサービス実行手段との対応付けに基づき、選択したユーザに対応するサービス実行手段をリソース制限対象サービス実行手段として選択することを特徴とする請求項２又は３に記載のサービス管理装置。
6. 前記リソース管理部は、
   前記特定サービス実行手段によるサービスの実行が完了した際に、前記特定サービス実行手段に割当てたリソースを前記リソース制限対象サービス実行手段に返却することを特徴とする請求項１〜５のいずれかに記載のサービス管理装置。
7. 前記リソース管理部は、
   前記特定サービス実行手段に前記リソース制限対象サービス実行手段のリソースの少なくとも一部を割当てた時点から、前記特定サービス実行手段によるサービスの実行が完了し前記特定サービス実行手段に割当てたリソースを前記リソース制限対象サービス実行手段に返却した時点までを前記リソース制限対象サービス実行手段のリソース制限時間として計測し、
   前記リソース制限時間情報管理部は、
   前記リソース管理部により計測された前記リソース制限対象サービス実行手段のリソース制限時間を前記リソース制限対象サービス実行手段のユーザに対応付けてリソース制限時間情報に追加し、追加後のリソース制限時間情報を管理することを特徴とする請求項６に記載のサービス管理装置。
8. 前記サービス管理装置は、更に、
   所定の条件下で、サービス実行手段のサービスの実行を中止させるサービス中止部と、
   ユーザごとに、前記サービス中止部によりサービスが中止された中止回数を示すサービス中止回数情報を管理するサービス中止回数情報管理部とを有し、
   前記制限対象選択部は、
   前記サービス中止回数情報に示されるサービス中止回数と所定の閾値とを比較し、前記閾値以上のサービス中止回数が示されているユーザについては、前記優先順位情報の優先順位を上昇させることを特徴とする請求項１〜７のいずれかに記載のサービス管理装置。
9. 前記制限対象選択部は、
   サービス完了期限が定められている時限サービスを実行する時限サービス実行手段が時限サービスの実行を開始した後、時限サービスの完了が予測される時刻までに時限サービスの実行が完了していない場合であって、当該時限サービス実行手段のユーザの優先順位が所定のレベル以上である場合に、当該時限サービス実行手段を前記特定サービス実行手段とすることを特徴とする請求項１〜８のいずれかに記載のサービス管理装置。
10. 各々がユーザに対してデータ処理を伴うサービスを実行する複数のサービス実行手段を管理するコンピュータに、
    サービス実行手段ごとにサービスの実行先となるユーザを示すユーザサービス情報を参照するユーザサービス情報参照手順と、
    ユーザごとに優先順位を示す優先順位情報を参照する優先順位情報参照手順と、
    対応するサービス実行手段へのリソース割当てが制限されたリソース制限時間の実績値をユーザごとに示すリソース制限時間情報を参照するリソース制限時間情報参照手順と、
    特定の条件に合致する特定サービス実行手段がサービスを実行している際に、前記ユーザサービス情報に示されるユーザとサービス実行手段との対応付け及び前記優先順位情報に示される優先順位に基づいて、前記特定サービス実行手段よりも優先順位が低いサービス実行手段を１つ以上抽出し、前記ユーザサービス情報に示されるユーザとサービス実行手段との対応付け及び前記リソース制限時間情報に示されるリソース制限時間に基づいて、抽出したサービス実行手段の中から１つ以上のサービス実行手段をリソース制限対象サービス実行手段として選択する制限対象選択手順と、
    前記制限対象選択手順により選択されたリソース制限対象サービス実行手段に割当てられているリソースの少なくとも一部を前記特定サービス実行手段に割当てるリソース管理手順とを実行させることを特徴とするプログラム。

Images