(57)【要約】      （修正有）【課題】負荷状況に応じてシステムをスケール制御し、仮想サーバの運用コストの無駄を減らす。【解決手段】クライアント端末からジョブの実行要求を受けた場合に、ジョブ管理データベースが記憶するそのジョブの実行条件と、リソース監視部が監視する負荷状況とに基づいて、そのジョブを実行させる台数分のサーバを決定してそのジョブを実行させる。さらに、その実行時間を実行結果として処理履歴データベースに記憶させ、ジョブ管理部が記憶させたジョブの実行時間と、スケジュール管理データベースに記憶されている実行スケジュールおよびバッファで管理された時間とに基づいて、実行スケジュールまたはバッファをジョブの実行時間に更新する。【選択図】図８
2015060279.tif 000002
【特許請求の範囲】
【請求項１】
ジョブを実行する複数のサーバを有したクラウドをスケール制御するスケール制御サーバであって、
前記ジョブと、前記ジョブを実行するサーバの台数と、前記ジョブの実行条件とを対応付けて記憶するジョブ管理データベースと、前記ジョブの実行スケジュールと前記ジョブの処理時間の余裕分を示すバッファとを対応付けて記憶するスケジュール管理データベースと、前記ジョブの実行履歴を記憶する処理履歴データベースと、を記憶する記憶部と、
前記複数のサーバのそれぞれの負荷状況を監視するリソース監視部と、
クライアント端末から前記ジョブの実行要求を受けた場合に、前記ジョブ管理データベースが記憶するそのジョブの実行条件と、前記リソース監視部が監視する負荷状況とに基づいて、そのジョブを実行させる台数分のサーバを決定してそのジョブを実行させ、その実行時間を実行結果として前記処理履歴データベースに記憶させるジョブ管理部と、
前記ジョブ管理部が記憶させた前記ジョブの実行時間と、前記スケジュール管理データベースに記憶されている実行スケジュールおよび前記バッファで管理された時間とに基づいて、前記実行スケジュールまたは前記バッファを前記ジョブの実行時間に更新するスケール制御部と、
を備えることを特徴とするスケール制御サーバ。
【請求項２】
前記スケール制御部は、前記ジョブの実行時間と前記実行スケジュールおよび前記バッファで管理された時間との差が一定以上あるか否かを判定し、前記ジョブの実行時間と前記実行スケジュールおよび前記バッファで管理された時間との差が一定以上あると判定した場合に、前記実行スケジュールまたは前記バッファを前記ジョブの実行時間に更新する、
ことを特徴とする請求項１に記載のスケール制御サーバ。
【請求項３】
前記スケール制御部は、前記ジョブの実行時間が前記実行スケジュールおよび前記バッファよりも一定以上少ないと判定した場合には、前記ジョブ管理データベースに記憶されている前記サーバ台数を減らし、または前記ジョブの実行時間が前記実行スケジュールおよび前記バッファよりも一定以上多いと判定した場合には、前記ジョブ管理データベースに記憶されている前記サーバ台数を増やす、
ことを特徴とする請求項１または２に記載のスケール制御サーバ。
【請求項４】
前記ジョブ管理データベースは、前記実行条件としてＣＰＵ使用率を記憶し、
前記スケール制御部は、前記ジョブの実行時間が前記実行スケジュールおよび前記バッファよりも一定以上少ないと判定した場合には前記ＣＰＵ使用率を低くし、または前記ジョブの実行時間が前記実行スケジュールおよび前記バッファよりも一定以上多いと判定した場合には前記ＣＰＵ使用率を高くする、
ことを特徴とする請求項１〜３のいずれか１項に記載のスケール制御サーバ。
【請求項５】
前記ジョブ管理部は、前記ＣＰＵ使用率を満たすサーバが前記サーバの台数以上存在する場合には、その中でもＣＰＵ使用率が低い順に、そのサーバ台数分のサーバを用いて前記ジョブを実行させる、
ことを特徴とする請求項４に記載のスケール制御サーバ。
【請求項６】
前記記憶部は、前記ジョブをキューイングするキュー管理データベースをさらに記憶し、
前記ジョブ管理データベースは、前記ジョブを実行する優先度をさらに記憶し、
前記ジョブ管理部１０５は、クライアント端末から前記ジョブの実行要求を受けた場合に、そのジョブを前記キュー管理データベースにキューイングし、キューイングしたジョブの優先度が先にキューイングされたジョブよりも高い場合にはそのジョブを先に実行させる、
ことを特徴とする請求項１〜５のいずれか１項に記載のスケール制御サーバ。
【請求項７】
前記記憶部は、カレンダーを記憶するカレンダーデータベースをさらに記憶し、
前記スケール制御部は、前記実行スケジュールおよび前記バッファを更新する際に前記カレンダーデータベースを参照し、前記ジョブが週末、月初、月末を含む特定日に実行された場合には、多くのジョブが処理されることによって処理時間が通常よりも多くかかると判断し、前記バッファにさらに予備の時間を加える、
ことを特徴とする請求項１〜６のいずれか１項に記載のスケール制御サーバ。
【請求項８】
ジョブを実行する複数のサーバを有したクラウドをスケール制御するスケール制御方法であって、
前記複数のサーバのそれぞれの負荷状況を監視する第１のステップと、
クライアント端末から前記ジョブの実行要求を受けた場合に、前記ジョブと、前記ジョブを実行するサーバの台数と、前記ジョブの実行条件とを対応付けて記憶するジョブ管理データベースが記憶するそのジョブの実行条件と、監視された負荷状況とに基づいて、そのジョブを実行させる台数分のサーバを決定してそのジョブを実行させる第２のステップと、
その実行時間を実行結果として前記ジョブの実行履歴を記憶する処理履歴データベースに記憶させる第３のステップと、
前記ジョブの実行時間と、前記ジョブの実行スケジュールと前記ジョブの処理時間の余裕分を示すバッファとを対応付けて記憶するスケジュール管理データベースに記憶されている実行スケジュールおよびバッファとに基づいて、前記実行スケジュールおよび前記バッファを前記ジョブの実行時間に更新する第４のステップと、
を含むことを特徴とするスケール制御方法。
【請求項９】
前記第４のステップにおいて、前記ジョブの実行時間と前記実行スケジュールおよび前記バッファとの差が一定以上あるか否かを判定するステップをさらに含み、前記ジョブの実行時間と前記実行スケジュールおよび前記バッファとの差が一定以上あると判定された場合に、前記実行スケジュールおよび前記バッファを前記ジョブの実行時間に更新する、
ことを特徴とする請求項８に記載のスケール制御方法。
【請求項１０】
コンピュータに、
スケール制御するクラウドに含まれ、ジョブを実行する複数のサーバのそれぞれの負荷状況を監視する第１のステップと、
クライアント端末から前記ジョブの実行要求を受けた場合に、前記ジョブと、前記ジョブを実行するサーバの台数と、前記ジョブの実行条件とを対応付けて記憶するジョブ管理データベースが記憶するそのジョブの実行条件と、監視された負荷状況とに基づいて、そのジョブを実行させる台数分のサーバを決定してそのジョブを実行させる第２のステップと、
その実行時間を実行結果として前記ジョブの実行履歴を記憶する処理履歴データベースに記憶させる第３のステップと、
前記ジョブの実行時間と、前記ジョブの実行スケジュールと前記ジョブの処理時間の余裕分を示すバッファとを対応付けて記憶するスケジュール管理データベースに記憶されている実行スケジュールおよびバッファとに基づいて、前記実行スケジュールおよび前記バッファを前記ジョブの実行時間に更新する第４のステップと、
を実行させることを特徴とするスケール制御プログラム。
【請求項１１】
前記第４のステップにおいて、前記ジョブの実行時間と前記実行スケジュールおよび前記バッファとの差が一定以上あるか否かを判定するステップをさらに含み、前記ジョブの実行時間と前記実行スケジュールおよび前記バッファとの差が一定以上あると判定された場合に、前記実行スケジュールおよび前記バッファを前記ジョブの実行時間に更新する、
ことを特徴とするスケール制御プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、スケール制御サーバ、スケール制御方法、およびスケール制御プログラムに関する。
【背景技術】
【０００２】
昨今、クラウドコンピューティングが盛んである。クラウドコンピューティングとは、一般には、ネットワーク、サーバ、ストレージ等の共用可能なコンピューティングリソースにネットワーク経由でアクセスすることを可能とするモデルである。クラウドコンピューティングによって構築されたクラウド規模の拡大や縮小、コンピューティングリソースの起動時間の延長や短縮等を行うことをスケール制御という。
【０００３】
クラウドを提供するデータセンタ事業者、通信事業者、プロバイダ等の各種の事業者は、クラウドに割り当てられたサーバの利用状況を監視し、その負荷状況に応じてクラウドをスケール制御することで効率よくリソースを運用することがよく行われている。例えば、特許文献１では、負荷に伴う仮想サーバの起動時間の遅延を過去の実績から予測してスケジュールを生成し、そのスケジュールに従って仮想サーバを起動させることにより、遅延のないサービスを顧客に提供する技術が開示されている。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２０１３−４１３９７号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
上述した特許文献１に記載された技術では、仮想サーバの起動時間の遅延を考慮することにより、その時間だけ早めに仮想サーバを起動させ、目標日時までにサービスを提供可能な状態にしている。しかしながら、特許文献１では、仮想サーバが複数存在する場合、各仮想サーバの負荷状況に応じてどのようにスケール制御して効率よくサービスを提供させるかという具体的な手法については開示されていない。
【０００６】
また、システムの管理者等は、例えば、月次、週次といったサイクリックな処理を実行する場合、処理の実行タイミングや処理予測時間を見積もってスケジューリングし、その情報をジョブとともにクラウドを管理する管理サーバ上に登録し、処理を実行させることがある。通常、その管理者等は、他の仮想サーバでの処理やネットワークの負荷の影響を考慮し、ある程度の時間的なバッファを設けた上で、実行タイミングや処理予測時間を定める。しかし、仮想サーバが実際に受ける負荷によっては、設定したバッファを超えたり、バッファが余りすぎたりする場合が生じ、その結果、スケジュール通りに処理を実行させることができず、仮想サーバの運用コストに無駄が発生してしまう場合がある。
【０００７】
本発明は、上記に鑑みてなされたものであって、負荷状況に応じてシステムをスケール制御し、仮想サーバの運用コストの無駄を減らすことが可能なスケール制御サーバ、スケール制御方法、およびスケール制御プログラムを提供することを目的とする。
【課題を解決するための手段】
【０００８】
上述した課題を解決し、目的を達成するために、本発明にかかるスケール制御サーバは、ジョブを実行する複数のサーバを有したクラウドをスケール制御するスケール制御サーバであって、前記ジョブと、前記ジョブを実行するサーバの台数と、前記ジョブの実行条件とを対応付けて記憶するジョブ管理データベースと、前記ジョブの実行スケジュールと前記ジョブの処理時間の余裕分を示すバッファとを対応付けて記憶するスケジュール管理データベースと、前記ジョブの実行履歴を記憶する処理履歴データベースと、を記憶する記憶部と、前記複数のサーバのそれぞれの負荷状況を監視するリソース監視部と、クライアント端末から前記ジョブの実行要求を受けた場合に、前記ジョブ管理データベースが記憶するそのジョブの実行条件と、前記リソース監視部が監視する負荷状況とに基づいて、そのジョブを実行させる台数分のサーバを決定してそのジョブを実行させ、その実行時間を実行結果として前記処理履歴データベースに記憶させるジョブ管理部と、前記ジョブ管理部が記憶させた前記ジョブの実行時間と、前記スケジュール管理データベースに記憶されている実行スケジュールおよび前記バッファで管理された時間とに基づいて、前記実行スケジュールまたは前記バッファを前記ジョブの実行時間に更新するスケール制御部と、を備えるスケール制御サーバとして構成される。
【０００９】
また、本発明は、上記スケール制御サーバで行われるスケール制御方法、およびスケール制御プログラムとして構成される。
【発明の効果】
【００１０】
本発明によれば、負荷状況に応じてシステムをスケール制御し、仮想サーバの運用コストの無駄を減らすことが可能となる。
【図面の簡単な説明】
【００１１】
【図１】スケール制御システムの構成例を示す図である。
【図２】スケジュールＤＢの構成例を示す図である。
【図３】ジョブ管理ＤＢの構成例を示す図である。
【図４】処理履歴ＤＢの構成例を示す図である。
【図５】キュー管理ＤＢの構成例を示す図である。
【図６】カレンダーＤＢの構成例を示す図である。
【図７】リソース管理ＤＢの構成例を示す図である。
【図８】スケール制御処理の処理手順を示すフローチャートである。
【発明を実施するための形態】
【００１２】
以下に添付図面を参照して、本発明にかかるスケール制御サーバ、スケール制御方法、およびスケール制御プログラムの実施の形態を詳細に説明する。
【００１３】
図１は、本発明にかかるスケール制御サーバ、スケール制御方法、およびスケール制御プログラムの一実施形態であるスケール制御システム１０００の構成例を示す図である。図１に示すように、スケール制御システム１０００は、スケール制御サーバ１００と、クラウド２００と、クライアント端末３００とを有して構成されている。また、これらの各装置は、一般的な公衆回線網、ＬＡＮ（Local  Area  Network）等のネットワークＮ１、Ｎ２によって互いに接続されている。まず、スケール制御サーバ１００について説明する。
【００１４】
図１に示すように、スケール制御サーバ１００は、記憶部１０１と、スケール制御部１０２と、リソース制御部１０３と、ジョブ管理部１０４とを有して構成されている。また、記憶部１０１は、ＨＤＤ（Hard  Disk  Drive）等の記憶装置から構成され、スケジュールＤＢ１０１１と、ジョブ管理ＤＢ１０１２と、処理履歴ＤＢ１０１３と、キュー管理ＤＢ１０１４と、カレンダーＤＢ１０１５と、リソース管理ＤＢ１０１６とを有している。
【００１５】
スケジュールＤＢ１０１１は、クラウド２００を構成する仮想サーバ２１０が処理を実行するジョブのスケジュールを管理するデータベースである。図２は、スケジュールＤＢ１０１１の構成例を示す図である。図２に示すように、スケジュールＤＢ１０１１は、ジョブを識別するためのジョブＩＤと、そのジョブ名と、そのジョブを実行するサイクルと、そのジョブの開始時刻および終了時刻と、そのジョブの処理遅延等による処理時間の余裕分を示すバッファと、そのジョブに続く後続ジョブを識別するための後続ジョブＩＤとを対応付けて記憶している。図２では、例えば、ジョブＩＤ「Ｄ００００１」によって識別されるジョブ「日時売上集計」は、デイリー処理であり、２２：００に開始され、２３：３０に終了するようにスケジュールが設定されていることを示している。また、その後続ジョブにはジョブ「Ｓ００００１」があることを示している。さらに、処理時間のバッファとして３０分が設定され、通常の実行条件（後述）であればそのジョブは６０分（２２：００〜２３：００）で終了するところ、３０分の余裕をみて、開始時刻および終了時刻が上述した時刻に設定されていることがわかる。スケジュールＤＢ１０１１は、システムの管理者等によってあらかじめ設定される。
【００１６】
後述するように、本システムでは、あらかじめスケジュールＤＢ１０１１に登録された処理時間でスケジューリングされたジョブが、仮想サーバ２１０の負荷や他のジョブとの関係で処理が早く終了する頻度が高い場合には、上述した終了時刻やバッファにより管理される時間が短くなるようにそのジョブのスケジュールを自動的に更新することにより、そのジョブによる仮想サーバ２１０の使用時間を減らしている。クラウド２００を利用するユーザは、スケジュールされたジョブによる仮想サーバ２１０の使用時間によって料金が課金される利用形態であることが多いが、そのような課金による運用コストの負担を抑制することができる。また、システム側から見て仮想サーバ２１０の台数が減る場合には、余った仮想サーバ２１０のＣＰＵを有効活用できる。
【００１７】
また、これとは逆に、あらかじめスケジュールＤＢ１０１１に登録された処理時間でスケジューリングされたジョブが、仮想サーバ２１０の負荷や他のジョブとの関係で処理が遅く終了する頻度が高い場合には、上述した終了時刻やバッファにより管理される時間が長くなるようにそのジョブのスケジュールを自動的に更新することにより、そのジョブによる仮想サーバ２１０の使用時間を増やしている。クラウド２００を管理する管理者等は、スケジュールされたジョブによる仮想サーバ２１０の使用時間によって料金を課金することが多いが、そのような課金のための仮想サーバ２１０の使用状況の調査やスケジュールの設定変更等による更新コストの負担を抑制することができる。また、システム側から見て仮想サーバ２１０の台数が増える場合には、その仮想サーバ２１０の負荷を軽減できるとともに、他の余っている仮想サーバ２１０のＣＰＵを有効活用できる。
【００１８】
ジョブ管理ＤＢ１０１２は、上述したジョブ実行時にクラウド２００をスケール制御する範囲を管理するデータベースである。図３は、ジョブ管理ＤＢ１０１２の構成例を示す図である。図３に示すように、ジョブ管理ＤＢ１０１２は、上述したジョブＩＤおよびジョブ名およびサイクルと、上述したバッファと、そのジョブを実行する優先度と、そのジョブを実行する仮想サーバ２１０の最大台数を示すサーバ台数と、ジョブの実行する際の仮想サーバ２１０の条件を示す実行条件とを対応付けて記憶している。図３では、例えば、ジョブＩＤ「Ｄ０００００１」によって識別されるジョブは、最大３台の仮想サーバ２１０を用いて実行されることを示している。また、実行条件として、ＣＰＵ使用率が７０％以下の仮想サーバ２１０を用いてそのジョブを実行させることを示している。さらにそのジョブは、他のジョブと比べて優先して実行されることを示している。ジョブ管理ＤＢ１０１２は、システムの管理者等によってあらかじめ設定される。
【００１９】
処理履歴ＤＢ１０１３は、ジョブの処理結果を履歴形式で管理するデータベースである。図４は、処理履歴ＤＢ１０１３の構成例を示す図である。図４に示すように、処理履歴ＤＢ１０１３は、上述したジョブＩＤと、そのジョブの実際の処理開始時刻を示す開始実績時刻と、そのジョブの実際の処理終了時刻を示す終了実績時刻と、そのジョブを実行した仮想サーバ２１０を示す処理サーバとを対応付けて記憶している。また、これらの情報が、１つのレコードにサイクリックに（図４に示す例では、１つのレコードの右側に順次追加して）記憶されている。図４では、例えば、ジョブＩＤ「Ｄ０００００１」によって識別されるジョブが直近で実際処理を開始した時刻は「２２：００」であり、その終了時刻は「２３：１０」であったことを示している。また、このときジョブを実行した仮想サーバ２１０は、「Ｓ００００１、Ｓ００００５、Ｓ００００６」の３台であったことを示している。さらにその後のサイクルでは、そのジョブが「２２：０５」に開始され、「２３：４０」に終了し、「Ｓ００００１、Ｓ００００２、Ｓ００００３」の３台の仮想サーバ２１０によって実行されたことを示している。処理履歴ＤＢ１０１３は、実際にジョブ実行部１０５がジョブを実行した際に更新される。
【００２０】
キュー管理ＤＢ１０１４は、ジョブのキューイングを管理するデータベースである。図５は、キュー管理ＤＢ１０１４の構成例を示す図である。図５に示すように、キュー管理ＤＢ１０１４は、キューを識別するためのキューＩＤと、そのキューによってキューイングされているジョブを示す待ちジョブＩＤとを対応付けて記憶している。図５では、例えば、最初の順番にキューイングされているジョブは「Ｄ０００００１」であることを示している。キュー管理ＤＢ１０１４は、ジョブ管理部１０５がクライアント端末３００からジョブの実行要求を受けた場合やスケジュールされた時刻が到来した場合に、そのジョブが待ちジョブＩＤに追加される。
【００２１】
カレンダーＤＢ１０１５は、一般的な年月日や暦等のカレンダー情報や企業固有の情報を管理するデータベースである。図６は、カレンダーＤＢ１０１５の構成例を示す図である。図６に示すように、カレンダーＤＢ１０１５は、一般的なカレンダー情報として、年月日や曜日、さらには企業固有の情報（例えば、特売日等のセール日程）を対応付けて記憶している。図６では、例えば、２０１３年３月のカレンダー情報に加え、１日、５日、１０日等の網かけされた日が特売日であることを示している。カレンダーＤＢ１０１５は、システムの管理者等によってあらかじめ設定される。
【００２２】
リソース管理ＤＢ１０１６は、仮想サーバ２１０の稼働状況を管理するデータベースである。図７は、リソース管理ＤＢ１０１６の構成例を示す図である。図７に示すように、リソース管理ＤＢ１０１６は、仮想サーバ２１０を識別するためのサーバＩＤと、その仮想サーバ２１０のＣＰＵ使用率と、メモリ使用量と、ディスク使用量とを対応付けて記憶している。図７では、例えば、サーバＩＤ「Ｓ００００１」によって識別される仮想サーバ２１０のＣＰＵ使用率およびメモリ使用量およびディスク使用量は、それぞれ３０％、５０％、５０％であることを示している。リソース管理ＤＢ１０１６のＣＰＵ使用率およびメモリ使用量およびディスク使用量それぞれの数値は、リソース監視部１０４によって定期的（例えば、図７に示す例では、５分ごとにｎ回分。）に更新される。続いて、図１に戻って、スケール制御部１０２について説明する。
【００２３】
スケール制御部１０２は、図２に示したスケジュールＤＢ１０１１に登録されたジョブの開始時刻および終了時刻から標準的な処理時間（標準処理時間）を算出し、図４に示した処理履歴ＤＢ１０１３に記憶されている開始実績時刻および終了実績時刻から実際にかかった処理時間（実績処理時間）をサイクルごとに算出する。スケール制御部１０２は、標準処理時間と平均的な実績処理時間との差分の時間がバッファにより管理される時間よりも長い時間となった場合（すなわち、標準処理時間から実績処理時間を差し引いた時間がバッファにより管理される時間以上となって余裕がある場合）には、その差分の時間でスケジュールＤＢ１０１１のバッファを更新し、平均的な終了実績時刻でスケジュールＤＢ１０１１の終了時刻を更新する。スケール制御部１０２がスケジュールＤＢ１０１１の終了時刻やバッファを更新することにより、上述したようにクラウド２００を利用するユーザおよび管理者にとって、運用コストや更新コストの負担が抑制されるとともに、仮想サーバのＣＰＵを有効活用できる。
【００２４】
なお、以下では主に実績処理時間が、標準処理時間からバッファにより管理される時間を差し引いてもさらに余裕がある場合について説明しているが、これとは逆に、スケール制御部１０２が算出した標準処理時間と平均的な実績処理時間との差分の時間がバッファにより管理される時間を超えた場合（すなわち、標準処理時間から実績処理時間を差し引くとバッファにより管理される時間を使い果たしてマイナスになる場合）、上述した場合と同様に、その差分の時間でスケジュールＤＢ１０１１のバッファを更新し、平均的な終了実績時刻でスケジュールＤＢ１０１１の終了時刻を更新することも可能である。スケール制御部１０２がスケジュールＤＢ１０１１の終了時刻やバッファを更新することにより、上述したようにクラウド２００を利用するユーザおよび管理者にとって、運用コストや更新コストの負担が抑制されるとともに、仮想サーバのＣＰＵを有効活用できる。
【００２５】
リソース監視部１０４は、それぞれの仮想サーバ２１０の稼働状況を監視し、図７に示したリソース管理ＤＢ１０１６のＣＰＵ使用率およびメモリ使用量およびディスク使用量を定期的に（例えば、５分ごと）更新する。なお、図７に示した例ではそれぞれの値を更新する場合について示しているが、リソース監視部１０４が、これらの情報を分、時、日、月、年等のサイクル（例えば、５分ごとにｎ回分）で、履歴形式でリソース管理ＤＢ１０１６に記憶させることとしてもよい。この場合、リソース監視部１０４が、過去の同時期における仮想サーバ２１０の稼働状況から今後の稼働状況を予測してその結果をスケール制御部１０３に出力し、スケール制御部１０３がスケジュールＤＢ１０１１のサーバ台数や実行条件を更新することとしてもよい。例えば、リソース監視部１０４が、５分ごとに監視したＣＰＵ使用率およびメモリ使用量およびディスク使用量を１年分蓄積した場合には、月次処理として登録されているジョブが実行される時間帯において、それぞれの仮想サーバ２１０のＣＰＵ使用率は、ある月では平均して６０％でありその翌月や翌々月では平均して３０％であった場合には、今後はそのジョブが実行される時間帯では仮想サーバ２１０のＣＰＵ使用率は平均して３０％であると判断してその結果をスケール制御部１０３に出力する。スケール制御部１０３は、リソース監視部１０４からその結果を受け取ると、スケジュールＤＢ１０１１の実行条件を６０％から３０％に更新したり、あるいはジョブで使用するサーバの台数を集約してサーバ台数を８台から４台に更新することとしてもよい。
【００２６】
ジョブ管理部１０５は、クライアント端末３００から実行要求されたジョブやスケジュールされた時刻が到来したジョブをキューイングして仮想サーバ２１０に実行させる。ジョブ管理部１０５は、図５に示したキュー管理ＤＢ１０１４にキューイングされている待ちジョブを、キューＩＤが小さい順に（すなわち、早くキューイングされた順序で）仮想サーバ２１０に実行させる。ジョブ管理部１０５は、仮想サーバ２１０にジョブを実行させる際に、図７に示したリソース管理ＤＢ１０１６のＣＰＵ使用率および図３に示したジョブ管理ＤＢ１０１２の実行条件を参照し、実行しようとしているジョブの実行条件およびサーバ台数を満たす仮想サーバ２１０を用いて処理を行う。このとき、ジョブ管理部１０５は、ジョブの開始時刻と終了時刻を図４に示した処理履歴ＤＢ１０１３に書き込む。
【００２７】
なお、ジョブ管理部１０５は、ジョブの実行条件を満たす仮想サーバ２１０がサーバ台数以上存在する場合には、その中でも最もＣＰＵ使用率が低い仮想サーバを特定し、さらにその仮想サーバ２１０の次にＣＰＵ使用率が低い仮想サーバを特定するというように、ＣＰＵ使用率が低い順に、そのサーバ台数分の仮想サーバ２１０を用いてジョブを実行させる。ジョブ管理部１０５は、新たにジョブを実行させる都度、リソース管理ＤＢ１０１６にアクセスして仮想サーバ２１０のＣＰＵ使用率をチェックし、実行条件を満たす仮想サーバを特定する。以下の説明では、新たにジョブを実行させるタイミングで、使用する仮想サーバ２１０を特定しているが、ジョブが終了したタイミングで仮想サーバ２１０のＣＰＵ使用率をチェックし、次のジョブを実行する仮想サーバを特定することとしてもよい。このように、ジョブ管理部１０５が、ＣＰＵ使用率が低い仮想サーバ２１０に対してジョブを実行させるので、クラウド２００全体のロードバランスを平準化することができる。
【００２８】
また、ジョブ管理部１０５が、ジョブＩＤをキーとして処理履歴ＤＢ１０１３を参照し、過去にそのジョブが実行されたタイミングで、他のジョブがどの仮想サーバ２１０（処理サーバ）で実行されていたのかをチェックし、最も少ないジョブが実行されていた仮想サーバ２１０に、そのジョブを処理させることとしてもよい。この場合も、ジョブ管理部１０５が、各仮想サーバ２１０でどの程度の数のジョブが過去に実行されているのかといった処理傾向を把握した上で、実行させるジョブを仮想サーバ２１０に割り振るので、クラウド２００全体のロードバランスを平準化することができる。
【００２９】
さらに、ジョブ管理部１０５が、キューＩＤをキーとしてキュー管理ＤＢ１０１４を参照し、その時点のキュー待ちのジョブ数をカウントするとともに、さらにそのキューＩＤに対応する待ちジョブＩＤをキーとして処理履歴ＤＢ１０１３を参照し、そのジョブの過去の処理時間をチェックする。そして、ジョブ管理部１０５は、チェックしたそのジョブの過去の処理時間から仮想サーバ２１０にかかる負荷を予測し、キューＩＤが１つ前のジョブをある仮想サーバ２１０に処理させた場合には、次のジョブは別の仮想サーバ２１０に処理させることとしてもよい。負荷の予測については、例えば、ジョブ管理部１０５は、ジョブの過去の処理時間が長いほど、あるいは仮想サーバ２１０の数が多いほど仮想サーバ２１０にかかる負荷が大きいと判断し、そのような負荷が一定の閾値以上（処理時間が規定時間以上、バッファにより管理される時間を超えた時間が規定時間以上、仮想サーバ２１０の台数が規定台数以上等）となった場合、その仮想サーバ２１０以外のサーバに次にキューイングされているジョブを処理させる。この場合も、ジョブ管理部１０５が、過去のジョブの処理時間を考慮して実行させるジョブを仮想サーバ２１０に割り振るので、クラウド２００全体のロードバランスを平準化することができる。続いて、図１に戻って、クラウド２００について説明する。
【００３０】
クラウド２００は、例えば、ネットワーク、サーバ、ストレージ等の共用可能なコンピューティングリソースの集合体である。図１に示すように、クラウド２００は、複数の仮想サーバ２１０を有して構成されている。仮想サーバ２１０は、制御部２１０１と、記憶部２１０２とを有している。制御部２１０１は、ＣＰＵ等の演算装置から構成され、例えば、スケール制御サーバ１００からの要求に応じて、ジョブを実行する。また、記憶部２１０１は、メモリやＨＤＤ（Hard  Disk  Drive）等の記憶媒体から構成され、例えば、ジョブに使用する様々なデータを一時的に記憶したり、あるいはその処理結果を記憶する。
【００３１】
クライアント端末３００は、例えば、デスクトップ型、ノート型の一般的なコンピュータである。システムの利用者は、このクライアント端末３００を操作して所望のジョブを実行させる。図１に示すように、クライアント端末３００は、制御部３０１と、表示部３０２とを有して構成されている。制御部３０１は、ＣＰＵ等の演算装置から構成され、ジョブの実行要求やその結果を取得する。表示部３０２は、ＬＣＤ等のディスプレイ装置から構成され、ジョブの実行指示画面やその結果画面（いずれも不図示）を表示させる。
【００３２】
なお、本実施の形態では特に説明していないが、例えば、スケール制御部１０２は、スケジュールＤＢ１０１１の終了時刻やバッファを更新する際に、カレンダーＤＢ１０１５を参照し、例えば、週末や月初、月末、あるいは特売日等のセール日にジョブが実行されるスケジュールとなっている場合には、多くのジョブが処理されることによって処理時間が通常よりも多くかかると判断し、さらにその終了時刻に予備の時間を加えた時刻をスケジュールＤＢ１０１１の終了時刻として設定したり、あるいはバッファにさらに予備のバッファを加えたバッファをスケジュールＤＢ１０１１のバッファに設定することとしてもよい。この場合、ジョブが実行される状況に合ったスケジュールの設定が可能となる。
【００３３】
さらに、キューイングされたジョブの中には他のジョブよりも優先して処理すべきジョブが存在するケースもある。そのような場合、ジョブ管理部１０５は、キュー管理ＤＢ１０１４にキューイングされているジョブのジョブＩＤ（待ちジョブＩＤ）をキーとしてジョブ管理ＤＢ１０１２にアクセスし、そのジョブに対応する優先度を参照する。そして、ジョブ管理部１０５は、参照した優先度と、キューイングされている前後のジョブの優先度とを比較し、参照したジョブの優先度のほうが高いと判定した場合、そのジョブを比較対象としたジョブよりも前にキューイングさせることとしてもよい。この場合、優先度を考慮してジョブを実行させることができる。続いて、本システムで行われるスケール制御処理について説明する。
【００３４】
図８は、スケール制御処理の処理手順を示すフローチャートである。図８に示すように、スケール制御処理では、まず、ジョブ管理部１０５は、クライアント端末３００からジョブの実行要求があったか否か、あるいはジョブを実行するスケジュールが到来したか否かを判定し（ステップＳ８０１）、その実行要求がない、あるいはジョブを実行するスケジュールが到来していないと判定した場合（ステップＳ８０１；Ｎｏ）、これらのタイミングが到来するまでそのまま待機する。
【００３５】
一方、ジョブ管理部１０５は、その実行要求があった、あるいはジョブを実行するスケジュールが到来したと判定した場合（ステップＳ８０１；Ｙｅｓ）、そのジョブをキュー管理ＤＢ１０１４にキューイングし（ステップＳ８０２）、ジョブを実行する順番になったか否かを判定する（ステップＳ８０３）。このとき、ジョブ管理部１０５は、ジョブを実行する順番になっていないと判定した場合（ステップＳ８０３；Ｎｏ）、その順番が到来するまでそのまま待機する。
【００３６】
一方、ジョブ管理部１０５は、ジョブを実行する順番になったと判定した場合（ステップＳ８０３；Ｙｅｓ）、リソース管理ＤＢ１０１６のＣＰＵ使用率およびジョブ管理ＤＢ１０１２の実行条件を参照し、実行しようとしているジョブの実行条件およびサーバ台数を満たす仮想サーバ２１０を決定し（ステップＳ８０４）、決定した仮想サーバ２１０を用いてそのジョブの処理を実行する（ステップＳ８０５）。そして、ジョブ管理部１０５は、ジョブの開始時刻と終了時刻を、実行結果として処理履歴ＤＢ１０１３に書き込む（ステップＳ８０６）。
【００３７】
スケール制御部１０２は、スケジュールＤＢ１０１１に登録されたジョブの標準処理時間と、処理履歴ＤＢ１０１３に記憶されている実績処理時間とを算出し、現在のバッファ、仮想サーバ台数、実行条件をチェック（確認）し（ステップＳ８０７）、これらの内容が現在の内容で妥当か否かを判定する（ステップＳ８０８）。具体的には、スケール制御部１０２は、標準処理時間と平均的な実績処理時間との差分の時間がバッファにより管理される時間よりも長い時間であるか否かを判定する。
【００３８】
そして、スケール制御部１０２は、これらの内容が現在の内容で妥当であると判定した場合（ステップＳ８０８；Ｙｅｓ）、何もせずに処理を終了する。一方、スケール制御部１０２は、これらの内容が現在の内容で妥当でないと判定した場合（ステップＳ８０８；Ｎｏ）、すなわち、標準処理時間から実績処理時間を差し引いた時間がバッファにより管理される時間以上となって余裕がある場合には、その差分の時間でジョブ管理ＤＢ１０１１、スケジュールＤＢ１０１１のバッファを更新し、平均的な終了実績時刻でスケジュールＤＢ１０１１の終了時刻を更新し、その結果画面（例えば、図２に示したスケジュールＤＢ、図３に示したジョブ管理ＤＢと同様の画面）をクライアント端末３００の表示部３０２に表示させる（ステップＳ８０９）。
【００３９】
ここでは、処理の終了時刻についてのみ記載したが、上述したように、ＣＰＵの使用率やメモリの使用量、ディスク使用量等のリソースの各値の使用実績値の平均値を算出し、その値が現在の実行条件（例えば、ＣＰＵ使用率７０％）を一定以上下回った場合（例えば、１０％下回った６０％である場合）、現在の実行条件をその値に更新することとしてもよい。このステップＳ８０９の処理が終了すると、図８に示したスケール制御処理が終了する。
【００４０】
このように、本実施の形態におけるスケール制御処理を行うことにより、負荷状況に応じてシステムをスケール制御し、仮想サーバの運用コストの無駄を減らすことが可能となる。
【００４１】
本実施形態のスケール制御サーバで実行される処理は、実際にはプログラムによって実行されるが、例えば、インストール可能な形式又は実行可能な形式のファイルでＣＤ−ＲＯＭ、フレキシブルディスク（ＦＤ）、ＣＤ−Ｒ、ＤＶＤ（Ｄｉｇｉｔａｌ  Ｖｅｒｓａｔｉｌｅ  Ｄｉｓｋ）等のコンピュータで読み取り可能な記録媒体に記録されて提供することも可能である。また、そのプログラムを、インターネット等のネットワークに接続されたコンピュータ上に格納し、ネットワーク経由でダウンロードさせたり、インターネット等のネットワーク経由で提供または配布するように構成しても良い。さらには、そのプログラムを、ＲＯＭ等に予め組み込んで提供するように構成してもよい。
【００４２】
なお、本実施の形態のスケール制御サーバで実行されるプログラムは、上述した各部（スケール制御部１０２、リソース監視部１０３、ジョブ管理部１０４等）を含むモジュール構成となっており、実際のハードウェアとしてはＣＰＵが上記記憶媒体からプログラムを読み出して実行することにより上記各部が不図示の主記憶装置上にロードされ、スケール制御部１０２、リソース監視部１０３、ジョブ管理部１０４等がその主記憶装置上に生成されるようになっている。
【００４３】
本発明は上記した実施例に限定されるものではなく、様々な変形例が含まれる。例えば、上記した実施例は本発明を分かりやすく説明するために詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。また、ある実施例の構成の一部を他の実施例の構成に置き換えることが可能であり、例えば、ジョブの数が多い場合には、ジョブ管理部１０５の機能を１つのサーバに設け、スケール制御部１０２、リソース監視部１０３等の他の機能を別のサーバに設けて負荷を分散させることとしてもよい。
【００４４】
また、スケール制御部１０２が仮想サーバ台数、実行条件をチェックしてその内容が現在の内容で妥当か否かを判定する場合、標準処理時間から実績処理時間を差し引いた時間がバッファにより管理される時間以上と記載しているが、標準処理時間から実績処理時間を差し引いた時間がバッファにより管理される時間よりも長いか否か、あるいはバッファにより管理される時間よりも短い（あるいは長い）時間を基準時間として設定し、その時間と標準処理時間から実績処理時間を差し引いた時間とを比較して判定することも可能である。すなわち、スケール制御部１０２は、必ずしも本実施の形態で示したバッファによって仮想サーバ台数、実行条件をチェックしてその内容が現在の内容で妥当か否かを判定するわけではなく、このような様々な基準によって判定することができる。
【符号の説明】
【００４５】
１０００            スケール制御システム
１００              スケール制御サーバ
１０１              記憶部
１０１１            スケジュールＤＢ
１０１２            ジョブ管理ＤＢ
１０１３            処理履歴ＤＢ
１０１４            キュー管理ＤＢ
１０１５            カレンダーＤＢ
１０１６            リソース管理ＤＢ
１０２              スケール制御部
１０３              リソース制御部
１０４              ジョブ管理部
２００              クラウド
２１０              仮想サーバ
２１０１            制御部
２１０２            記憶部
３００              クライアント端末
３０１              制御部
３０２              表示部
Ｎ１、Ｎ２          ネットワーク。
【図１】
2015060279.tif 000003
【図２】
2015060279.tif 000004
【図３】
2015060279.tif 000005
【図４】
2015060279.tif 000006
【図５】
2015060279.tif 000007
【図６】
2015060279.tif 000008
【図７】
2015060279.tif 000009
【図８】
2015060279.tif 000010