JP2018063470A - 制御装置および制御方法 - Google Patents

Abstract

【課題】仮想マシンの枯渇を回避するとともに予備仮想マシンの削減を図ることができる。
【解決手段】制御装置５０は、所定の機能を実行する仮想マシンと所定の機能を実行するために用意される予備仮想マシンを割当てる。制御装置５０は、第１機能１０を実行する仮想マシンの増減と、第２機能２０を実行する仮想マシンの増減との相関の有無を判定し、相関があるとき、第１機能１０を実行する仮想マシンの増減に基づいて、第２機能２０を実行するために用意される予備仮想マシンの最大容量を決定する。
【選択図】図１

Description

本発明は、制御装置および制御方法に関する。

近年、コンピュータリソースの利用形態の１つとしてクラウドシステムが提案されている。クラウドシステムは、ユーザがネットワーク経由でコンピュータリソースを利用するシステムである。クラウドシステムは、複数のユーザに対して柔軟にリソースを割り振ることができるよう、複数の仮想的なコンピュータ（仮想マシン）を配置した仮想システムとして実装されることが多い。

また、仮想システムを提供する技術として、標準化団体であるＥＴＳＩ（European Telecommunications Standards Institute）が定義する網機能仮想化（ＮＦＶ：Network Function Virtualization）が提案されている。ＮＦＶは、ルータなどのネットワークノードを仮想化してソフトウエアパッケージ化し、汎用サーバ内の仮想マシンにおいて実行する技術である。

ＮＦＶを用いた技術として、仮想化されたネットワークノードの負荷に応じて、ネットワークノードのスケーリング制御を行う運用管理装置に関する技術が知られている。スケーリングとは、仮想マシンの台数を増減設（スケールイン／スケールアウト）する制御を行う技術である。

また、アプリケーションの実行環境となる仮想マシンを管理するシステムにおいて、仮想マシンの故障時の影響を少なくするため、アプリケーションを予めインストールした予備の仮想マシン群を用意する技術が知られている。

特開２０１５−１４９５７８号公報 特開２０１５−１９１２４６号公報

アプリケーションを予めインストールした予備の仮想マシン群を保持する領域（以下、リソースプールと記載する）には、アプリケーションが提供するサービスの需要が急激に増減する場合にも対応できる予備の仮想マシンの量を保持できる容量を確保することが求められている。このため、リソースプールの仮想マシンの量は、サービスの需要の増減に伴うアプリケーションの負荷変動に対応して仮想マシンが枯渇しないように設定する必要がある。

ただし、リソースプールの予備の仮想マシンの量を、サービスの最大需要の際に相当する量に定めた場合、仮想マシンが枯渇する事態を回避できるが、余分な仮想マシンを確保し続けるため、管理や運用コストが増大してしまう。

このため、仮想化システムにおいて、仮想マシンの枯渇を回避するとともに、顧客に対するサービスを損なわない範囲において予備の仮想マシンの量を抑えることが課題となっている。

１つの側面では、本発明は、仮想マシンの枯渇を回避するとともに予備の仮想マシンの削減を図ることができる制御装置および制御方法を提供することを目的とする。

上記目的を達成するために、以下に示すような制御装置が提供される。制御装置は、所定の機能を実行する仮想マシンと所定の機能を実行するために用意される予備仮想マシンを割当てる。制御装置は、第１機能を実行する仮想マシンの増減と、第２機能を実行する仮想マシンの増減との相関の有無を判定し、相関があるとき、第１機能を実行する仮想マシンの増減に基づいて、第２機能を実行するために用意される予備仮想マシンの最大容量を決定する。

一態様によれば、本発明は、仮想マシンの枯渇を回避するとともに予備の仮想マシンの削減を図ることができる制御装置および制御方法を提供できる。

第１の実施形態の制御装置の構成の一例を示す図である。 第２の実施形態の情報処理システムの構成の一例を示す図である。 第２の実施形態の仮想リソース管理サーバのハードウェア構成の一例を示す図である。 第２の実施形態のクラウドシステムにリソースを配置した一例を示す図である。 第２の実施形態のサービス接続情報の一例を示す図である。 第２の実施形態のアプリケーション管理情報の一例を示す図である。 第２の実施形態の情報処理システムにおけるシーケンスの一例を示す図である。 第２の実施形態のリソース制御処理のフローチャートを示す図である。 第２の実施形態の動作モード管理情報の一例を示す図である。 第２の実施形態の相関判定処理のフローチャートを示す図である。 第２の実施形態のイベントログの一例を示す図である。 第２の実施形態の相関観測情報の一例を示す図である。 第２の実施形態の相関判定情報の一例を示す図である。 第２の実施形態の相関制御処理のフローチャートを示す図である。 第２の実施形態のリソースプール状態情報の一例を示す図である。 第２の実施形態のリソースプール制御情報の一例を示す図である。 第２の実施形態のリソースプール空時処理のフローチャートを示す図である。 （Ａ）が第２の実施形態のスケールアウトの実行前後におけるリソースプールの制御概要を示す図であり、（Ｂ）がスケールインの実行前後におけるリソースプールの制御概要を示す図である。

以下、図面を参照して実施の形態を詳細に説明する。
［第１の実施形態］
まず、第１の実施形態の制御装置について図１を用いて説明する。図１は、第１の実施形態の制御装置の構成の一例を示す図である。

制御装置５０は、制御部５１を含む。制御装置５０は、所定の機能を実行する仮想マシンや、所定の機能を実行するために用意される予備仮想マシンを制御する情報処理装置であり、たとえば、コンピュータである。

仮想マシンは、各種のコンピュータ資源を含むものであり、たとえば、仮想マシンや、仮想マシンで実行するプログラムや、仮想マシンで待機するプログラムや、仮想マシンに割当てられるプロセッサやメモリ等がある。

所定の機能は、各種のプログラムを実行することで実現する機能であり、制御装置５０が制御対象とするコンピュータでプログラムを実行することで実現される機能である。第１機能１０は、たとえば、第１仮想マシン１１に含まれる仮想マシンにおいて第１プログラムを実行することで実現される機能である。第２機能２０は、たとえば、第２仮想マシン２１に含まれる仮想マシンにおいて第２プログラムを実行することで実現される機能である。第１仮想マシン１１は、第１機能１０を実行する仮想マシンを含む。言い換えると、第１仮想マシン１１は、第１プログラムを実行する仮想マシンを含む。第２仮想マシン２１は、第２機能２０を実行する仮想マシンを含む。言い換えると、第２仮想マシン２１は、第２プログラムを実行する仮想マシンを含む。ここで、第１プログラムと第２プログラムの機能は、異なる機能を備えたプログラムでもよいし、同一の機能を備えたプログラムでもよい。

制御部５１は、仮想マシン制御５１ａと、相関有無判定制御５１ｂと、予備仮想マシン制御５１ｃを行う。
仮想マシン制御５１ａは、仮想マシンを増加または減少させる制御である。具体的には、仮想マシン制御５１ａは、所定の機能を実行するために用意する予備仮想マシンを、所定の機能を実行する仮想マシンに割当てることで仮想マシンを増加させる制御である。また、仮想マシン制御５１ａは、所定の機能を実行する仮想マシンを解除し、所定の機能を実行するために用意する予備仮想マシンにすることで仮想マシンを減少させる制御である。

仮想マシン制御５１ａは、たとえば、スケールインやスケールアウトの制御である。仮想マシン制御５１ａは、所定の機能を実行する仮想マシンの負荷が高くなった場合、予備仮想マシンを仮想マシンに割当てることで仮想マシンを増やすスケールアウトを実行する。仮想マシン制御５１ａは、所定の機能を実行する仮想マシンの負荷が低くなった場合、所定の機能に割当てられた仮想マシンを解除して予備仮想マシンへ戻すことで、仮想マシンを減らすスケールインを実行する。

相関有無判定制御５１ｂは、仮想マシン制御５１ａが仮想マシンを増加または減少させる制御を行った所定の機能（たとえば、第１機能１０）と他の所定の機能（たとえば、第２機能２０）に相関関係があるか否かを判定する制御である。

相関有無判定制御５１ｂは、第１機能１０を実行する第１仮想マシン１１の増減と、第２機能２０を実行する第２仮想マシン２１の増減との間の相関の有無を判定する。
ここで、相関の有無の判定について説明する。たとえば、第１機能１０を実行する第１仮想マシン１１にスケールインを実行したことに関連して、第２機能２０にもスケールインを実行したと認められる場合、第１機能１０と第２機能２０には相関があると判定できる。また、第１機能１０を実行する第１仮想マシン１１にスケールアウトを実行したことに関連して、第２機能２０を実行する第２仮想マシン２１にもスケールアウトを実行したと認められる場合、第１機能１０と第２機能２０には相関があると判定できる。相関有無判定制御５１ｂは、仮想マシンの増減を行った第１機能１０と相関関係のある第２機能２０を、相関のある機能として特定する。

予備仮想マシン制御５１ｃは、相関有無判定制御５１ｂにおいて相関があると判定した場合に、相関のある機能に割当てる予定の予備仮想マシンの容量を変更する制御である。たとえば、予備仮想マシン制御５１ｃは、相関のある機能を実行するために用意される予備仮想マシンの最大容量を決定できる。なお、予備仮想マシン制御５１ｃは、相関のある機能を実行するために用意される予備仮想マシンの最大容量に限らず、予備仮想マシンの最小容量等も決定できる。

予備仮想マシン制御５１ｃは、第２機能２０を相関のある機能として特定し、第１機能１０を実行する仮想マシンの増減に基づいて、第２機能２０を実行するために用意される第２予備仮想マシン２４の容量制御を行う。第１予備仮想マシン１４は、第１機能１０を実行するために用意される予備仮想マシンを含む。また、第１予備仮想マシン１４は、第１仮想マシン１１から割当てを解除された仮想マシンも予備仮想マシンとして含むことができる。第１予備仮想マシン１４は、たとえば、第１機能１０に対応するリソースプールである。第２予備仮想マシン２４は、第２機能２０を実行するために用意される予備仮想マシンを含む。また、第２予備仮想マシン２４は、第２仮想マシン２１から割当てを解除された仮想マシンも予備仮想マシンとして含むことができる。第２予備仮想マシン２４は、たとえば、第２機能２０に対応するリソースプールである。

たとえば、第１機能１０を実行する仮想マシンに対しスケールアウトを実行した場合について説明する。予備仮想マシン制御５１ｃが、第１予備仮想マシン１４に含まれる予備仮想マシンを第１仮想マシン１１に割当てることで仮想マシンが増加し（１２，１３）、第１予備仮想マシン１４の予備仮想マシン数が減少（１５，１６）する。予備仮想マシン制御５１ｃは、第１仮想マシン１１において仮想マシンが増加（１２，１３）したことに伴い、第２予備仮想マシン２４において予備仮想マシンを保持できる容量を増加させる（２５，２６）。予備仮想マシン制御５１ｃは、第２仮想マシン２１において仮想マシンの増減の制御を実行しておらず第２仮想マシン２１の増減がない場合（２２，２３）であっても、第２予備仮想マシン２４の容量を増加させることができる（２５，２６）。

このように、制御部５１は、第１機能１０を実行する仮想マシンを含む第１仮想マシン１１に対してスケールインまたはスケールアウトを実行した際に、相関関係のある第２機能２０に対応する第２予備仮想マシン２４の容量制御を行う。

制御部５１は、第２仮想マシン２１に対してスケールインまたはスケールアウトが実行されずとも、第２の予備仮想マシン２４の容量制御を行うことができる。言い換えると、制御部５１は、第２２仮想マシン２１に対してスケールアウトを実行する前に第２予備仮想マシン２４の容量を増加させることで、第２機能２０に対する予備仮想マシンの枯渇を低減できる。また、制御部５１は、第２仮想マシン２１に対してスケールインを実行する前に、第２予備仮想マシン２４の容量を減少させることで、第２機能２０に対して予備仮想マシンの過剰な割当てを低減することができる。

このように、制御装置５０は、第１機能１０を実行する仮想マシンを含む第１仮想マシン１１のスケーリングに応じて第２予備仮想マシン２４を制御することができる。これにより、制御装置５０は、第２機能２０に割当てる予備仮想マシンの枯渇を回避するとともに予備仮想マシンの削減を図ることができる。

［第２の実施形態］
次に、第２の実施形態の情報処理システムについて図２を用いて説明する。図２は、第２の実施形態の情報処理システムの構成の一例を示す図である。

情報処理システム５００は、管理システム４００と、クラウドシステム３００とを含む。管理システム４００とクラウドシステム３００は、ネットワークを介して接続されている。

管理システム４００は、仮想リソース管理サーバ１００と、ネットワーク１５０を介して仮想リソース管理サーバ１００と接続する仮想インフラ管理サーバ１８０と、アプリケーション管理サーバ１９０とを備える。管理システム４００は、クラウドシステム３００の物理リソースや仮想マシンに必要となるリソースの管理および制御を行う。管理システム４００は、たとえば、ＥＴＳＩが定義するＮＦＶ ＭＡＮＯ（Management and Orchestration），ＯＳＳ／ＢＳＳ（Operation Support System ／ Business Support System），ＮＦＶＩ（NFV Infrastructure）等の機能を備える。なお、情報処理システム５００で実行するアプリケーション等の各種プログラムは、ＶＮＦ（Virtual Network Function）で提供できる。

仮想リソース管理サーバ１００は、仮想リソースの管理および制御を行うコンピュータである。仮想リソース管理サーバ１００は、たとえば、スケールインおよびスケールアウトの管理および実行、リソースプールの管理および制御を行う。仮想リソース管理サーバ１００は、各種リソースの制御方法を実現するプログラムを実行できる。

仮想インフラ管理サーバ１８０は、仮想マシンを実行するための基板となるリソースの管理および制御を行うコンピュータである。
アプリケーション管理サーバ１９０は、クラウドシステム３００がユーザに提供するアプリケーションの管理及び制御を行うコンピュータである。

クラウドシステム３００は、企業等のユーザに提供されるシステムである。クラウドシステム３００は、ルータ２５０，２５１と、ネットワーク１６０を介してルータ２５０，２５１と接続する汎用サーバ２００，２０１，２０２を備える。

汎用サーバ２００，２０１，２０２は、複数の仮想マシンを動作させることができるコンピュータである。ユーザに提供するサービスを実現するアプリケーションは、仮想マシンで実行される。ルータ２５０，２５１は、ネットワークを中継する通信機器である。

なお、情報処理システム５００は、複数のクラウドシステム３００を備えてもよい。また、管理システム４００は、複数のクラウドシステム３００を管理してもよい。また、上述の構成は一例であり、クラウドシステム３００は、１以上の汎用サーバ２００と１以上のルータ２５０を備えればよい。

次に、第２の実施形態の仮想リソース管理サーバのハードウェア構成について図３を用いて説明する。図３は、第２の実施形態の仮想リソース管理サーバのハードウェア構成の一例を示す図である。

仮想リソース管理サーバ１００は、プロセッサ１０１によって装置全体が制御されている。プロセッサ１０１には、バス１０８を介してＲＡＭ（Random Access Memory）１０２と複数の周辺機器が接続されている。プロセッサ１０１は、マルチプロセッサであってもよい。プロセッサ１０１は、たとえばＣＰＵ（Central Processing Unit）、ＭＰＵ（Micro Processing Unit）、ＤＳＰ（Digital Signal Processor）、ＡＳＩＣ（Application Specific Integrated Circuit）、またはＰＬＤ（Programmable Logic Device）である。またプロセッサ１０１は、ＣＰＵ、ＭＰＵ、ＤＳＰ、ＡＳＩＣ、ＰＬＤのうちの２以上の要素の組み合わせであってもよい。なお、プロセッサ１０１は、第１の実施の形態の制御部５１の一例である。

ＲＡＭ１０２は、仮想リソース管理サーバ１００の主記憶装置として使用される。ＲＡＭ１０２は、プロセッサ１０１が実行するプログラムやプロセッサ１０１が演算に用いるデータを一時的に記憶する揮発性メモリである。なお、仮想リソース管理サーバ１００は、ＲＡＭ以外の種類のメモリを備えてもよく、複数個のメモリを備えてもよい。

バス１０８に接続されている周辺機器としては、ＨＤＤ（Hard Disk Drive）１０３、画像信号処理部１０４、入力信号処理部１０５、媒体リーダ１０６および通信インタフェース１０７がある。

ＨＤＤ１０３は、ＯＳ（Operating System）やミドルウェアやアプリケーションソフトウェアなどのソフトウェアのプログラム、および、データを記憶する不揮発性の記憶装置である。なお、仮想リソース管理サーバ１００は、フラッシュメモリやＳＳＤ（Solid State Drive）などの他の種類の記憶装置を備えてもよく、複数の不揮発性の記憶装置を備えてもよい。

画像信号処理部１０４は、プロセッサ１０１からの命令に従って、仮想リソース管理サーバ１００に接続されたディスプレイ１１１に画像を出力する。ディスプレイ１１１としては、ＣＲＴ（Cathode Ray Tube）ディスプレイ、液晶ディスプレイ（ＬＣＤ：Liquid Crystal Display）、プラズマディスプレイ（ＰＤＰ：Plasma Display Panel）、有機ＥＬ（ＯＥＬ：Organic Electro-Luminescence）ディスプレイなどを用いることができる。

入力信号処理部１０５は、仮想リソース管理サーバ１００に接続された入力デバイス１１２から入力信号を取得し、プロセッサ１０１に出力する。入力デバイス１１２としては、マウスやタッチパネルやタッチパッドやトラックボールなどのポインティングデバイス、キーボード、リモートコントローラ、ボタンスイッチなどを用いることができる。また、仮想リソース管理サーバ１００に、複数の種類の入力デバイスが接続されていてもよい。

媒体リーダ１０６は、記録媒体１１３に記録されたプログラムやデータを読み取る読み取り装置である。記録媒体１１３として、例えば、フレキシブルディスク（ＦＤ：Flexible Disk）やＨＤＤなどの磁気ディスク、ＣＤ（Compact Disc）やＤＶＤ（Digital Versatile Disc）などの光ディスク、光磁気ディスク（ＭＯ：Magneto-Optical disk）、半導体メモリなどを使用できる。媒体リーダ１０６は、例えば、記録媒体１１３から読み取ったプログラムやデータをＲＡＭ１０２またはＨＤＤ１０３に格納する。

通信インタフェース１０７は、ネットワーク１５０に接続され、ネットワーク１５０を介して他のコンピュータと通信を行うインタフェースである。通信インタフェース１０７は、ケーブルで通信装置と接続される有線通信インタフェースでもよいし、基地局と無線リンクで接続される無線通信インタフェースでもよい。

なお、仮想リソース管理サーバ１００は、媒体リーダ１０６を備えていなくてもよく、ユーザが操作する端末装置から制御可能である場合には画像信号処理部１０４や入力信号処理部１０５を備えていなくてもよい。また、ディスプレイ１１１や入力デバイス１１２が、仮想リソース管理サーバ１００の筐体と一体に形成されていてもよい。仮想インフラ管理サーバ１８０、アプリケーション管理サーバ１９０、汎用サーバ２００，２０１，２０２も、仮想リソース管理サーバ１００と同様のハードウェアを用いて実現することができる。

次に、第２の実施形態のクラウドシステムにおけるリソースの配置について図４を用いて説明する。図４は、第２の実施形態のクラウドシステムにリソースを配置した一例を示す図である。

クラウドシステム３００は、リソース実行エリア３１０とリソースプール３５０とを含む。リソース実行エリア３１０は、サービスを提供するアプリケーションが実行する仮想的な領域である。リソースプール３５０は、リソースを準備しておく仮想的な領域である。リソースには、ＣＰＵやメモリやＨＤＤなどのハードウェアリソースと、仮想マシンやアプリケーション等のソフトウェアリソースを含む。アプリケーションには、Ｗｅｂサーバの機能を提供するプログラムや、データベースの機能を提供するプログラム等の各種のプログラムを含む。リソース実行エリア３１０とリソースプール３５０は、汎用サーバ２００，２０１，２０２のいずれかで提供される。以下の説明において、仮想マシンおよびアプリケーションをリソースとして図示し、仮想マシンを実現するためのハイパーバイザやハードウェアリソースの図示は省略する。

クラウドシステム３００に含まれるリソースは、仮想リソース管理サーバ１００によって制御される。仮想リソース管理サーバ１００は、リソース実行エリア３１０で実行するアプリケーションの負荷が所定の値以上に増加した場合、リソース実行エリア３１０にリソースプール３５０で準備しているリソースを組み込むことで提供するリソースを増やす。仮想リソース管理サーバ１００は、リソース実行エリア３１０で実行するアプリケーションの負荷が所定の値以下に減少した場合、リソース実行エリア３１０で実行するリソースの組み込みを解除して提供するリソースを減らす。仮想リソース管理サーバ１００は、リソースプール３５０に必要以上のリソースが存在する場合、リソースを初期化し特定のアプリケーションに対応づけられていない状態にし、他のサービスにも使用できるようにする。

リソース実行エリア３１０は、アプリケーションＡ実行エリア３２０とアプリケーションＢ実行エリア３３０とを含む。アプリケーションＡ実行エリア３２０は、アプリケーションＡ３２２ａ，３２２ｂを実行させた仮想マシン３２１ａ，３２１ｂを含む仮想的な領域である。アプリケーションＢ実行エリア３３０は、アプリケーションＢ３３２ａ，３３２ｂを実行させた仮想マシン３３１ａ，３３１ｂを含む仮想的な領域である。

リソースプール３５０は、アプリケーションＡリソースプール３６０とアプリケーションＢリソースプール３７０とを含む。アプリケーションＡリソースプール３６０は、アプリケーションＡ３６２ａ，３６２ｂを待機させた仮想マシン３６１ａ，３６１ｂを含む仮想的な領域である。アプリケーションＢリソースプール３７０は、アプリケーションＢ３７２ａ，３７２ｂを待機させた仮想マシン３７１ａ，３７１ｂを含む仮想的な領域である。

なお、上述のリソースの配置は一例であり、リソース実行エリア３１０には１以上のリソースが実行状態であればよく、リソースプール３５０には１以上のリソースが準備状態であればよい。

次に、第２の実施形態のサービス接続情報について図５を用いて説明する。図５は、第２の実施形態のサービス接続情報の一例を示す図である。
サービス接続情報６００は、クラウドシステム３００で提供するアプリケーションのサービスにおけるデータの流れを概念的に示している。

サービス接続情報６００は、サービスＩＤとサービス接続構成とを含む。サービスＩＤは、サービスを識別するための識別情報である。サービス接続構成は、識別情報を用いてデータの流れを示している。ユーザは、サービスＩＤで識別される複数のサービスを、同時に複数利用することも出来る。

データが流れる経路の起点または終点は、エンドポイントを識別するためのエンドポイントＩＤ（ＥＰ０１，ＥＰ０２，ＥＰ０３）で示す。データが流れる経路の起点または終点は、ルータ２５０，２５１に対応する。

データが流れる中継点は、サービスを提供するアプリケーションの識別情報であるアプリケーションＩＤ（ＡＰＬ−Ａ，ＡＰＬ−Ｂ，ＡＰＬ−Ｃ）で示す。データが流れる中継点は、汎用サーバ２００，２０１，２０２のいずれか、あるいは、その一部、で実行するアプリケーションに対応する。ここで、アプリケーションＡの識別情報をＡＰＬ−Ａとし、アプリケーションＢの識別情報をＡＰＬ−Ｂとし、アプリケーションＣの識別情報をＡＰＬ−Ｃとする。

サービスＩＤ「１」は、ＥＰ０１を起点とし、ＡＰＬ−ＡとＡＰＬ−Ｂを経由し、ＥＰ０２を終点とする順でデータが流れることを示す。また、サービスＩＤ「２」は、ＥＰ０１を起点とし、ＡＰＬ−ＡからＡＰＬ−ＢおよびＡＰＬ−Ｃに分岐してデータが流れ、ＥＰ０２およびＥＰ０３を終点とする順でデータが流れることを示す。

なお、データの流れは、通信プロトコルに応じて送信元アドレスおよび宛先アドレスや、ポート番号や、ルータ２５０，２５１で定義されたルーチングテーブル等で定義されるが詳細については省略する。

次に、第２の実施形態のアプリケーション管理情報について図６を用いて説明する。図６は、第２の実施形態のアプリケーション管理情報の一例を示す図である。
アプリケーション管理情報６１０は、アプリケーションごとに割当リソースと運用ルールとを設定した情報である。アプリケーション管理情報６１０は、仮想リソース管理サーバ１００のＨＤＤ１０３等の記憶部に記憶される情報である。アプリケーション管理情報６１０は、管理システム４００の運用者によって設定される情報である。

割当リソースは、アプリケーションＩＤで示されるアプリケーションに対して割当てるリソースを定めた情報である。割当リソースは、リソース単位タイプと、最大数と、最小数と、スケーリンググループＩＤを含む。リソース単位タイプは、アプリケーションＩＤで示されるアプリケーションが実行する仮想マシンの種別を示す。最大数は、リソース単位タイプで示されたリソースが実行する最大数を示す。最小数は、リソース単位タイプで示されたリソースが実行する最小数を示す。スケーリンググループＩＤは、アプリケーションＩＤに対応する仮想マシンのスケーリングの制御を行う単位を識別する情報である。

運用ルールは、仮想リソース管理サーバ１００によってスケーリングの運用をするために用いられる情報である。運用ルールは、負荷上限値と負荷下限値を含む。
負荷上限値は、仮想リソース管理サーバ１００がアプリケーションに対するスケールアウトの実行の可否を判定するために用いる値である。アプリケーションＩＤで示されるアプリケーションの負荷が負荷上限値を超えた場合、仮想リソース管理サーバ１００がスケールアウトを実行する指示を出す。

負荷下限値は、仮想リソース管理サーバ１００がアプリケーションに対するスケールインの実行の可否を判定するために用いる値である。アプリケーションＩＤで示されるアプリケーションの負荷が負荷下限値よりも低い場合、仮想リソース管理サーバ１００がスケールインを実行する指示を出す。

負荷上限値と負荷下限値は、ＣＰＵ使用率と、メモリ使用率と、スループットを含む。ＣＰＵ使用率と、メモリ使用率と、スループットの値は、割当リソース単位の値である。言い換えると、仮想マシンに割当てられたＣＰＵの使用率、仮想マシンに割当てられたメモリの使用率、仮想マシンで実行するアプリケーションのスループットの値である。なお、ＣＰＵ使用率等は、負荷を計測するための指標の１つにすぎず、これら以外の値であってもよい。

次に、第２の実施形態の情報処理システムにおけるシーケンスについて図７を用いて説明する。図７は、第２の実施形態の情報処理システムにおけるシーケンスの一例を示す図である。

仮想リソース管理サーバ１００、仮想インフラ管理サーバ１８０、アプリケーション管理サーバ１９０の処理は、それぞれのコンピュータが有する制御部（プロセッサ１０１）が実行する処理である。また、汎用サーバ２００の制御部（プロセッサ１０１）がアプリケーションＡを実行し、汎用サーバ２０１の制御部（プロセッサ１０１）がアプリケーションＢを実行するものとする。

［ステップＳ１１］汎用サーバ２００において、アプリケーションＡについて負荷増加の事象が発生する。
［ステップＳ１２］アプリケーション管理サーバ１９０は、クラウドシステム３００で実行するアプリケーションを管理し、アプリケーションＡの負荷増加（スループット増加）を検知し、仮想リソース管理サーバ１００に通知する。

［ステップＳ１３］仮想インフラ管理サーバ１８０は、クラウドシステム３００で実行する仮想システムを提供する基板システムを管理し、アプリケーションＡの負荷増加（ＣＰＵまたはメモリ使用率増加）を検知し、仮想リソース管理サーバ１００に通知する。

［ステップＳ１４］仮想リソース管理サーバ１００は、アプリケーション管理サーバ１９０および仮想インフラ管理サーバ１８０から負荷増加の情報を受信し、負荷増加の事象が発生したアプリケーションＡのスケーリングについて実行の可否を判定する。

ここで、仮想リソース管理サーバ１００は、アプリケーションＡの負荷がアプリケーション管理情報６１０の負荷上限値を超えたことに伴い、アプリケーションＡのスケールアウトの実行を可と判定する。

［ステップＳ１５］仮想リソース管理サーバ１００は、アプリケーションＡのスケールアウトの実行を仮想インフラ管理サーバ１８０とアプリケーション管理サーバ１９０に指示する。

仮想インフラ管理サーバ１８０は、ＣＰＵやメモリ等のリソースを汎用サーバ２００で実行させる仮想マシンに割当てる制御を行う。また、アプリケーション管理サーバ１９０は、追加する仮想マシンおよびアプリケーションＡを汎用サーバ２００で実行させる制御を行う。

［ステップＳ１６］汎用サーバ２００は、仮想インフラ管理サーバ１８０およびアプリケーション管理サーバ１９０からの制御に基づき、スケールアウトを実行する。言い換えると、汎用サーバ２００は、アプリケーションＡ実行エリア３２０においてアプリケーションＡを実行する仮想マシンの量を増加させる。なお、仮想マシンの量を増加させることは、仮想マシンの数を増加させることを含む。

［ステップＳ１７］仮想リソース管理サーバ１００は、スケールアウトを実行したことに伴い、相関観測情報を更新する。相関観測情報は、相関アプリケーションを特定するための情報である。相関観測情報は、後で図１２を用いて説明する。

［ステップＳ１８］仮想リソース管理サーバ１００は、相関観測情報を用いて事象が発生したアプリケーションＡと相関関係にあるアプリケーションを特定する。以下の説明において、事象発生アプリケーションに対して相関関係にあるアプリケーションを相関アプリケーションと記載する。

相関アプリケーションとは、たとえば、負荷増加の事象が発生したアプリケーションに対してスケールアウトを実行した場合に、所定の時間内にスケールアウトを実行した他のアプリケーションである。また、相関アプリケーションとは、たとえば、負荷減少の事象が発生したアプリケーションに対してスケールインを実行した場合に、所定の時間内にスケールインを実行した他のアプリケーションである。相関アプリケーションを特定する処理の詳細は、後で図１０を用いて説明する。

ここで、アプリケーションＡに対する相関アプリケーションをアプリケーションＢとする。
［ステップＳ１９］仮想リソース管理サーバ１００は、相関アプリケーションのリソースプール容量の制御の実行について判定する。リソースプール容量は、リソースプールが保持可能なリソースの最大量である。

たとえば、事象が発生したアプリケーションＡについてスケールアウトを実行したことに伴い、仮想リソース管理サーバ１００は、相関アプリケーションであるアプリケーションＢに対応するリソースプール容量を増加する制御を実行すると判定する。

［ステップＳ２０］仮想リソース管理サーバ１００は、アプリケーションＢのリソースプール容量を増加させる指示を仮想インフラ管理サーバ１８０とアプリケーション管理サーバ１９０に送信する。

仮想インフラ管理サーバ１８０は、アプリケーションＢのリソースプールに割当てるＣＰＵやメモリや仮想マシン等のリソースプール容量の上限を増加させる制御を行う。また、アプリケーション管理サーバ１９０は、アプリケーションＢのリソースプールに割当てる仮想マシンおよびアプリケーションＢの数（リソース量）を増加させる制御を行う。

［ステップＳ２１］汎用サーバ２０１は、仮想インフラ管理サーバ１８０およびアプリケーション管理サーバ１９０からの制御に基づき、アプリケーションＢリソースプール３７０のリソースプール容量とリソース量とを増加させる。

なお、上述のシーケンスは、負荷増加の事象が発生した例を示したが、負荷減少の事象が発生した場合にも適用が可能である。負荷減少の事象が発生した場合、仮想リソース管理サーバ１００は、ステップＳ１５でスケールインの実行を指示し、汎用サーバ２００がスケールインを実行する。また、仮想リソース管理サーバ１００は、ステップＳ２０でリソースプールのリソースプール容量の削減を指示し、汎用サーバ２０１がリソースプール容量を削減する。仮想リソース管理サーバ１００の処理の詳細については、後で図８，図１０，図１４，図１７を用いて説明する。

このように、仮想リソース管理サーバ１００は、事象発生アプリケーションのスケーリングに応じて、相関アプリケーションのリソースプールの容量を増減させる。仮想リソース管理サーバ１００は、相関アプリケーションについて負荷増加を検知する前にリソースプール容量とリソース量を増加させることで、ユーザに提供するアプリケーションの性能が損なわれないようにできる。また、仮想リソース管理サーバ１００は、相関アプリケーションについて負荷減少を検知する前にリソースプール内のリソース量を削減させることで、リソースを早く開放できる。

次に、第２の実施形態のリソース制御処理について図８を用いて説明する。図８は、第２の実施形態のリソース制御処理のフローチャートを示す図である。
リソース制御処理は、仮想リソース管理サーバ１００がスケーリングの実行を判断し、相関アプリケーションを判定する指示および相関アプリケーションのリソースプールの制御を指示する処理である。

仮想リソース管理サーバ１００の制御部（プロセッサ１０１）は、アプリケーションの負荷が変動した旨の通知を受信してリソース制御処理を実行する。
［ステップＳ３１］制御部は、負荷変動通知を仮想インフラ管理サーバ１８０またはアプリケーション管理サーバ１９０から受信したか否かを判定する。制御部は、負荷変動通知を受信した場合にステップＳ３２にすすみ、受信しない場合にステップＳ３１にすすむ。

負荷変動通知は、アプリケーションの負荷が変動した旨を通知する情報である。負荷変動通知には、負荷の増加または減少があったアプリケーションを識別するアプリケーションＩＤと負荷観測値が含まれる。負荷観測値には、ＣＰＵ使用率、メモリ使用率、スループットのいずれかの値が含まれる。

［ステップＳ３２］制御部は、負荷変動のあったアプリケーションを事象発生アプリケーションとして特定する。
［ステップＳ３３］制御部は、スケーリングの実行の可否を判断する。具体的には、制御部は、事象発生アプリケーションの負荷観測値とアプリケーション管理情報６１０の運用ルールで定められた負荷上限値および負荷下限値とを比較し、スケーリングの可否を判定する。制御部は、負荷観測値のいずれかが負荷上限値を超えている場合、スケールアウトを実行すると判断する。制御部は、負荷観測値のいずれかが負荷下限値よりも低い場合、スケールインを実行すると判断する。制御部は、負荷観測値のいずれもが負荷上限値と負荷下限値の間の値である場合、スケーリングを実行しないと判断する。制御部は、スケーリングを実行する場合にステップＳ３４にすすみ、スケーリングを実行しない場合にステップＳ３１にすすむ。

［ステップＳ３４］制御部は、事象発生アプリケーションのスケーリングの指示を仮想インフラ管理サーバ１８０とアプリケーション管理サーバ１９０に送信する。
制御部がスケールアウトの指示を送信した場合、仮想インフラ管理サーバ１８０は、ＣＰＵやメモリ等のリソースを仮想マシンに割当てる制御を行う。また、アプリケーション管理サーバ１９０は、追加する仮想マシンおよび事象発生アプリケーションを実行させる制御を行う。こうして、制御部は、リソース実行エリア３１０において事象発生アプリケーションが実行する仮想マシンの数を増加させる。

制御部がスケールインの指示を送信した場合、アプリケーション管理サーバ１９０は、ユーザからの処理を実行していない仮想マシンおよび事象発生アプリケーションを停止させる制御を行う。また、仮想インフラ管理サーバ１８０は、ＣＰＵやメモリ等のリソースを仮想マシンに対する割当てを解除する。こうして、制御部は、リソース実行エリア３１０において事象発生アプリケーションが実行する仮想マシンの数を削減する。

なお、制御部は、スケーリングを実行した履歴をイベントログとして記録する。イベントログに記録するイベントは、スケールインまたはスケールアウトである。イベントログは、後で図１１を用いて説明する。

［ステップＳ３５］制御部は、動作モード管理情報を記憶部から読み出し、事象発生アプリケーションが所属するスケーリンググループの動作モードを判定する。なお、スケーリンググループは、アプリケーション管理情報６１０に含まれるスケーリンググループＩＤで識別される。制御部は、動作モードが相関判定モードである場合にステップＳ３６にすすみ、動作モードが相関制御モードである場合にステップＳ３７にすすむ。

ここで、第２の実施形態の動作モード管理情報について図９を用いて説明する。図９は、第２の実施形態の動作モード管理情報の一例を示す図である。
動作モード管理情報６２０は、スケーリンググループごとに動作モードを管理する情報である。動作モード管理情報６２０は、仮想リソース管理サーバ１００のＨＤＤ１０３等の記憶部に記憶される情報である。動作モード管理情報６２０は、動作モードと、動作モード遷移条件とを含む。

動作モードは、仮想リソース管理サーバ１００が実行する処理を決定する情報である。動作モードは、相関判定モードまたは相関制御モードのどちらかの値が設定される。動作モードに相関判定モードが設定された場合、仮想リソース管理サーバ１００は、相関判定処理を実行する。動作モードに相関制御モードが設定された場合、仮想リソース管理サーバ１００は、相関制御処理を実行する。動作モードを設定する処理については、後で図１０，図１４を用いて説明する。なお、動作モードの初期値は、相関判定モードが運用者によって設定される。

動作モード遷移条件は、動作モードを現在の動作モードから他の動作モードに設定する場合の条件を定めた情報である。動作モード遷移条件は、自律遷移または運用者指示のどちらかの値が設定される。動作モード遷移条件に自律遷移が設定された場合、仮想リソース管理サーバ１００は、相関判定処理の終了時に動作モードを相関制御モードに設定し、相関制御処理の終了時に動作モードを相関判定モードに設定する。動作モード遷移条件に運用者指示が設定された場合、仮想リソース管理サーバ１００は、管理システム４００の運用者の指示によって動作モードを設定する。

再び、リソース制御処理のフローチャートの説明に戻る。
［ステップＳ３６］制御部は、相関判定処理を実行する。相関判定処理は、相関アプリケーションを特定する処理である。相関判定処理は、後で図１０を用いて説明する。

［ステップＳ３７］制御部は、相関制御処理を実行する。相関制御処理は、相関アプリケーションのリソースプールの容量制御を行う処理である。相関制御処理は、後で図１４を用いて説明する。

次に、第２の実施形態の相関判定処理について図１０を用いて説明する。図１０は、第２の実施形態の相関判定処理のフローチャートを示す図である。
相関判定処理は、相関アプリケーションを特定する処理である。相関判定処理は、リソース制御処理のステップＳ３６で仮想リソース管理サーバ１００の制御部（プロセッサ１０１）が実行する。

［ステップＳ４１］制御部は、イベントログに基づき相関観測情報を更新する。言い換えると、制御部は、イベントログに記録したデータから、判定時間間隔の間に同一のイベントタイプのイベントを実行したデータの組み合せを抽出し、相関観測情報に反映する。

ここで、第２の実施形態のイベントログについて図１１を用いて説明する。図１１は、第２の実施形態のイベントログの一例を示す図である。
イベントログ６３０は、仮想リソース管理サーバ１００がスケーリングを実行した履歴を記録した履歴情報である。イベントログ６３０は、仮想リソース管理サーバ１００のＨＤＤ１０３等の記憶部に記憶される情報である。イベントログ６３０は、実行時刻と、イベントタイプと、イベント実行アプリケーションＩＤとを含む。実行時刻は、スケールインまたはスケールアウトが仮想リソース管理サーバ１００によって実行された時刻である。イベントタイプは、スケールインまたはスケールアウトのいずれかを示す。イベント実行アプリケーションＩＤは、スケールインまたはスケールアウトを実行したアプリケーションを識別する情報である。

次に、第２の実施形態の相関観測情報について図１２を用いて説明する。図１２は、第２の実施形態の相関観測情報の一例を示す図である。
相関観測情報６４０は、イベントログ６３０から判定時間間隔の間に同一イベントタイプのイベントを実行したデータの組み合せを抽出して反映した情報である。また、相関観測情報６４０は、相関アプリケーションを特定するための情報である。相関観測情報６４０は、アプリケーションＩＤと、連動アプリケーション観測数とアプリ単位標本数と、全標本数とを含む。アプリケーションＩＤは、アプリケーションを識別する情報である。連動アプリケーション観測数は、アプリケーションＩＤで特定されるアプリケーションに対してイベントを実行してから判定時間間隔の間に他のアプリケーションで同一イベントを実行した件数である。アプリ単位標本数は、連動アプリケーション観測数に登録された件数をアプリケーション単位に合計した数である。全標本数は、全てのアプリ単位標本数の合計値である。なお、図１２の相関観測情報の対象、すなわち、標本の母集団となる対象は、情報処理システム５００単位、ユーザ単位、あるいは、サービスＩＤ単位のいずれの場合も含む。

次に、第２の実施形態の相関判定情報について図１３を用いて説明する。図１３は、第２の実施形態の相関判定情報の一例を示す図である。
相関判定情報６５０は、イベントログからデータを抽出し、相関観測情報６４０から相関アプリケーションを判定する際に用いられる情報である。相関判定情報６５０は、仮想リソース管理サーバ１００のＨＤＤ１０３等の記憶部に記憶される情報である。相関判定情報６５０は、判定時間間隔と、全標本数閾値と、アプリ単位標本数閾値と、相関閾値とを含む。判定時間間隔は、イベントログ６３０から同一のイベントタイプを実行したデータを抽出するために用いる時間である。全標本数閾値は、全標本数の閾値である。アプリ単位標本数閾値は、アプリ単位標本数の閾値である。相関閾値は、相関係数の閾値である。相関係数は、連動アプリケーション観測数の標本数をアプリ単位標本数で割った値である。

再び、相関判定処理のフローチャートの説明に戻る。
ここで、制御部が、イベントログに記録したデータから、判定時間間隔の間に同一のイベントタイプのイベントを実行したデータの組み合せを抽出し、相関観測情報６４０に反映する処理について説明する。

制御部は、イベントログ６３０から、あるアプリケーションに対してスケールインを実行した時刻から判定時間間隔内に他のアプリケーションに対してスケールインを実行したデータを抽出する。また、制御部は、イベントログ６３０から、あるアプリケーションに対してスケールアウトを実行した時刻から判定時間間隔内に他のアプリケーションに対してスケールアウトを実行したデータを抽出する。

たとえば、イベントログ６３０のデータを用いて説明する。制御部は、１５時３６分１２秒にスケールアウトがＡＰＬ−Ａに対して実行したデータを読み出す。制御部は、ＡＰＬ−Ａに対しスケールアウトを実行した時刻から判定時間間隔（１５分）内である１５時４２分０９秒にＡＰＬ−Ｂに対してスケールアウトを実行したデータを読み出す。制御部は、１５時３６分１２秒にスケールアウトがＡＰＬ−Ａに対して実行したデータと、１５時４２分０９秒にスケールアウトがＡＰＬ−Ｂに対して実行したデータとを関係情報としてイベントログ６３０から抽出する。抽出した関係情報は、実行時刻が前である「ＡＰＬ−Ａ」をアプリケーションＩＤとし、実行時刻が後である「ＡＰＬ−Ｂ」を連動アプリケーションのアプリケーションＩＤであるものとする。アプリケーションＩＤ「ＡＰＬ−Ａ」に対応する連動アプリケーション観測数「ＡＰＬ−Ｂ」のエントリに標本数「１」が加算されることで相関観測情報６４０に反映される。

［ステップＳ４２］制御部は、全標本数が全標本数閾値以上であるか否かを判定する。制御部は、全標本数が全標本数閾値以上である場合にステップＳ４３にすすみ、全標本数が全標本数閾値以上でない場合にステップＳ３１にすすむ。

［ステップＳ４３］制御部は、事象発生アプリケーションについて、アプリ単位標本数がアプリ単位標本数閾値以上であるか否かを判定する。制御部は、アプリ単位標本数がアプリ単位標本数閾値以上である場合にステップＳ４４にすすみ、アプリ単位標本数がアプリ単位標本数閾値以上でない場合にステップＳ３１にすすむ。

［ステップＳ４４］制御部は、事象発生アプリケーションについて相関係数を算出する。言い換えると、制御部は、事象発生アプリケーションの連動アプリケーション観測数について相関係数を算出する。

ここで、事象発生アプリケーションが「ＡＰＬ−Ａ」である場合、相関係数の算出について相関観測情報６４０を用いて説明する。
アプリケーションＩＤ「ＡＰＬ−Ａ」に対する連動アプリケーション観測数「ＡＰＬ−Ｂ」のエントリは「１７」である。アプリケーションＩＤ「ＡＰＬ−Ａ」に対するアプリ単位標本数は「２０」である。アプリケーションＩＤ「ＡＰＬ−Ａ」と連動アプリケーション観測数「ＡＰＬ−Ｂ」の相関係数は、分子を１７とし、分母を２０とした除算の結果（１７／２０＝０．８５）を百分率で表した８５％となる。同様にして、アプリケーションＩＤ「ＡＰＬ−Ａ」と連動アプリケーション観測数「ＡＰＬ−Ｃ」の相関係数は、分子を１とし、分母を２０とした除算の結果（１／２０＝０．０５）を百分率で表した５％となる。

［ステップＳ４５］制御部は、相関係数が相関閾値以上のアプリケーションを事象発生アプリケーションに対する相関アプリケーションとして特定する。
たとえば、事象発生アプリケーションが「ＡＰＬ−Ａ」である場合について説明する。ここで、相関閾値の値は、相関判定情報６５０に基づき８０％である。制御部は、アプリケーションＩＤ「ＡＰＬ−Ａ」と連動アプリケーション観測数「ＡＰＬ−Ｂ」の相関係数が８５％であり相関閾値８０％以上であるため、「ＡＰＬ−Ｂ」を相関アプリケーションとして特定する。

［ステップＳ４６］制御部は、動作モード遷移条件が自律遷移であるか否かを判定する。制御部は、動作モード遷移条件が自律遷移である場合にステップＳ４７にすすみ、運用者指示である場合（自律遷移でない場合）にステップＳ４８にすすむ。

［ステップＳ４７］制御部は、動作モードを相関制御モードに設定し、ステップＳ３５にすすむ。
［ステップＳ４８］制御部は、相関アプリケーションのアプリケーション識別情報を運用者に通知し、動作モード遷移指示の受付待ち画面をディスプレイ１１１に表示する。

なお、制御部は、相関アプリケーションのアプリケーション識別情報をディスプレイ１１１に表示することにより運用者に通知してもよいし、メールで送信することにより運用者に通知してもよいし、その他の方法であってもよい。

［ステップＳ４９］制御部は、動作モードを相関制御モードに設定する遷移指示を受け付け、ステップＳ３５にすすむ。
なお、上述の方法は一例であり、他の方法で相関アプリケーションを特定してもよい。たとえば、イベントログ６３０に記録したデータから、判定時間間隔の間に異なるイベントタイプのイベントを実行したデータの組み合せを抽出して、相関アプリケーションを特定してもよいし、他の方法で相関関係を特定してもよい。

次に、第２の実施形態の相関制御処理について図１４を用いて説明する。図１４は、第２の実施形態の相関制御処理のフローチャートを示す図である。
相関制御処理は、相関アプリケーションのリソースプールの容量制御を行う処理である。相関制御処理は、リソース制御処理のステップＳ３７で仮想リソース管理サーバ１００の制御部（プロセッサ１０１）が実行する処理である。

［ステップＳ５１］制御部は、事象発生アプリケーションに対する相関アプリケーションが存在するか否かを判定する。制御部は、相関アプリケーションが存在する場合はステップＳ５２にすすみ、存在しない場合はステップＳ５９にすすむ。

［ステップＳ５２］制御部は、相関アプリケーションの１つを対象アプリケーションとして特定する。たとえば、複数の相関アプリケーションが存在する場合、制御部は、相関係数が高い順に１つのアプリケーションを対象アプリケーションとして特定する。

［ステップＳ５３］制御部は、リソースプール空時処理を実行する。リソースプール空時処理は、対象アプリケーションのリソースプールに含まれるリソースが空（ゼロ）であるか否かを判定し、リソースプールの制御を指示する処理である。リソースプール空時処理は、後で図１７を用いて説明する。

［ステップＳ５４］制御部は、ステップＳ３４におけるスケーリングの指示がスケールインまたはスケールアウトのいずれであるかを判定する。制御部は、スケーリングの指示がスケールインである場合にステップＳ５５にすすみ、スケーリングの指示がスケールアウトである場合にステップＳ５６にすすむ。

［ステップＳ５５］制御部は、対象アプリケーションのリソースプールの容量を削減し、リソースプールに含まれるリソースの量を削減する。
ここで、第２の実施形態のリソースプール状態情報について図１５を用いて説明する。図１５は、第２の実施形態のリソースプール状態情報の一例を示す図である。

リソースプール状態情報６６０は、リソースプールに含まれるリソースの状態を示す情報である。リソースプール状態情報６６０は、アプリケーションごとのリソースプールに対応して存在する情報であり、言い換えると、スケーリンググループＩＤごとに存在する。リソースプール状態情報６６０は、仮想リソース管理サーバ１００のＨＤＤ１０３等の記憶部に記憶される情報である。

リソースプール状態情報６６０は、可用リソース量と、可用リソースＩＤとを含む。
可用リソース量は、リソースプールに含まれるリソースの量であり、たとえば、スタンバイ状態のアプリケーションを備えた仮想マシンの数である。可用リソースＩＤは、リソースプールに含まれるリソースを識別する識別情報である。可用リソースＩＤは、リソースプールに含まれる仮想マシンの識別情報やアプリケーションの識別情報等を含めることができる。

次に、第２の実施形態のリソースプール制御情報について図１６を用いて説明する。図１６は、第２の実施形態のリソースプール制御情報の一例を示す図である。
リソースプール制御情報６７０は、リソースプールの制御を行うために用いる情報である。リソースプール制御情報６７０は、アプリケーションごとのリソースプールに対応して存在する情報であり、言い換えると、スケーリンググループＩＤごとに存在する。リソースプール制御情報６７０は、仮想リソース管理サーバ１００のＨＤＤ１０３等の記憶部に記憶される情報である。

リソースプール制御情報６７０は制御項目として、リソース容量上限値と、リソース容量下限値と、リソース増加量と、リソース削減量と、増加量導出係数と、削減量導出係数とを含む。リソース容量上限値は、リソースプールの容量の上限を示す値である。リソース容量下限値は、リソースプールの容量の下限を示す値である。リソース増加量は、リソースプールに含まれるリソース量を増加させる場合に、増加させるリソースの単位量である。なお、リソースの量は、メモリやＣＰＵ等のコンピュータ資源の割当て量や、仮想マシンの台数等を含む。リソース削減量は、リソースプールに含まれるリソース量を削減させる場合に、削減させるリソースの単位量である。増加量導出係数は、リソース増加量を変更する値である。削減量導出係数は、リソース削減量を変更する値である。各制御項目の初期値は、運用者が予め設定できる。

リソースプール制御情報６７０の有効／無効は、制御項目を有効とするか、無効とするかを示す情報である。制御項目を有効とした場合、制御項目で指定された値に従ってリソースプールのリソースの容量制御を行う。制御項目を無効とした場合、各制御項目の値は運用者の入力で設定する。

再び、相関制御処理のフローチャートの説明に戻る。
ここで、制御部がリソースプールの容量を削減する処理について説明する。制御部は、リソースプール制御情報６７０からリソースプール容量上限値とリソース削減量とを取得し、リソースプール容量上限値からリソース削減量を減算した値をリソース容量上限値として設定する。なお、制御部は、リソースプール容量上限値からリソース削減量を減算した値が、リソース容量下限値以下になる場合、本処理を実行することを要しない。

次に、制御部がリソースプールに含まれるリソースの量を削減する処理について説明する。制御部は、リソースプール状態情報６６０から可用リソース量を読み出し、リソースプール制御情報６７０からリソース容量下限値と削減量導出係数を読み出す。制御部は、可用リソース量がリソース容量下限値以下でない場合、リソースプールからリソース削減量のリソースを削減する。また、制御部は、リソース削減量の値に削減量導出係数を加算した値をリソース削減量として設定する。

なお、制御部は、可用リソース量からリソース削減量を減算した値が、リソース容量下限値以下になる場合には、本処理を実行することを要しない。
［ステップＳ５６］制御部は、対象アプリケーションのリソースプールの容量を増加し、リソースプールに含まれるリソースの量を増加する。

ここで、制御部がリソースプールの容量を増加する処理について説明する。制御部は、リソースプール制御情報６７０からリソースプール容量上限値とリソース増加量とを取得し、リソースプール容量上限値とリソース増加量とを合計した値をリソース容量上限値として設定する。

次に、制御部がリソースプールに含まれるリソースの量を増加する処理について説明する。制御部は、リソースプール状態情報６６０から可用リソース量を読み出し、リソースプール制御情報６７０からリソース容量上限値と増加量導出係数を読み出す。制御部は、可用リソース量がリソース容量上限値を超えない場合、リソースプールにリソース増加量のリソースを生成してリソースの量を増加する。また、制御部は、リソース増加量の値に増加量導出係数を加算した値をリソース増加量として設定する。

なお、制御部は、可用リソース量にリソース増加量を加算した値が、リソース容量上限値を超える場合には、本ステップを実行することを要しない。
［ステップＳ５７］制御部は、ステップＳ５３から本ステップまでを未処理の相関アプリケーションが存在するか否かを判定する。制御部は、未処理の相関アプリケーションが存在する場合にステップＳ５８にすすみ、未処理の相関アプリケーションが存在しない場合にステップＳ５９にすすむ。

［ステップＳ５８］制御部は、ステップＳ５３からステップＳ５７までが未処理の相関アプリケーションを対象アプリケーションとして特定し、ステップＳ５３にすすむ。
［ステップＳ５９］制御部は、動作モードを相関判定モードに設定し、相関制御処理を終了する。

次に、第２の実施形態のリソースプール空時処理について図１７を用いて説明する。図１７は、第２の実施形態のリソースプール空時処理のフローチャートを示す図である。
リソースプール空時処理は、対象アプリケーションのリソースプールに含まれるリソースが空（ゼロ）であるか否かを判定し、リソースプールの制御を指示する処理である。リソースプール空時処理は、相関制御処理のステップＳ５３で仮想リソース管理サーバ１００の制御部（プロセッサ１０１）が実行する処理である。

［ステップＳ６１］制御部は、対象アプリケーションに対応するリソースプールのリソースがゼロであるか否かを判定する。制御部は、リソースがゼロである場合にステップＳ６２にすすみ、リソースがゼロではない場合にステップＳ５７にすすむ。

なお、リソースプールのリソースがゼロとは、リソースプールにリソースが含まれていない状態である。
［ステップＳ６２］制御部は、ステップＳ３４におけるスケーリングの指示がスケールインまたはスケールアウトのいずれであるかを判定する。制御部は、スケーリングの指示がスケールアウトである場合にステップＳ６３にすすみ、スケーリングの指示がスケールインである場合にリソースプール空時処理を終了する。

［ステップＳ６３］制御部は、リソース容量上限値を増加する。たとえば、制御部は、リソース容量上限値にリソース増加量を加えた値をリソース容量上限値として設定する。
［ステップＳ６４］制御部は、対象アプリケーションのスケールアウトの実行を仮想インフラ管理サーバ１８０とアプリケーション管理サーバ１９０に指示する。たとえば、制御部は、リソース増加量のリソースを生成し、対象アプリケーションのリソース実行エリア３１０に組み込む指示を送信する。言い換えると、制御部は、リソースプール３５０を介さずに（リソースプール３５０のリソースを増やさずに）、直接、リソース実行エリア３１０のリソースを増やす。

なお、上述したリソースプール空時処理は、リソースプールにリソースが含まれていない場合のみではなく、リソースの量が所定の量に満たない場合や、アプリケーションに割当てるべきリソースが不足している場合について適用してもよい。

次に、第２の実施形態のスケールアウトの実行前後におけるリソースプールの制御概要と、スケールインの実行前後におけるリソースプールの制御概要について図１８を用いて説明する。図１８は、（Ａ）が第２の実施形態のスケールアウトの実行前後におけるリソースプールの制御概要を示す図であり、（Ｂ）がスケールインの実行前後におけるリソースプールの制御概要を示す図である。

図１８の説明において、アプリケーションＡリソースプール３６０が事象発生アプリケーションに対応するリソースプールであり、アプリケーションＢリソースプール３７０が相関アプリケーションに対応するリソースプールであるものとする。

図１８（Ａ）は、スケールアウトの実行前後におけるリソースプール容量とリソース量の制御について示した図である。アプリケーションＡリソースプール３６０は、スケールアウトが発生したことに伴い、アプリケーションＡ実行エリア３２０に対するリソース割当てが発生するためリソース量が減少する（８１０，８１１）。アプリケーションＢリソースプール３７０は、仮想リソース管理サーバ１００によりリソース制御が実行されるため、アプリケーションＡでスケールアウトが発生した後、リソースプールの容量が増加しリソース量も増加する（８２０，８２１）。このように、スケールアウトがアプリケーションＡに実行された場合、アプリケーションＢリソースプール３７０のリソースプール容量とリソース量は、共に増加する正比例の関係になる。

図１８（Ｂ）は、スケールインの実行前後におけるリソースプール容量とリソース量の制御について示した図である。アプリケーションＡリソースプール３６０は、スケールインが発生したことに伴い、アプリケーションＡ実行エリア３２０におけるリソースの組み込みが解除されてアプリケーションＡリソースプール３６０に戻るためリソース量が増加する（８５０，８５１）。アプリケーションＢリソースプール３７０は、仮想リソース管理サーバ１００によりリソース制御が実行され、リソースプール容量とリソース量は減少する。しかし、アプリケーションＢ実行エリア３３０においてもスケールインが発生した場合、アプリケーションＢ実行エリア３３０におけるリソースの組み込みが解除されてアプリケーションＢリソースプール３７０に戻るため、リソース量が増加する（８６０，８６１）。このように、スケールインがアプリケーションＡに実行された後にアプリケーションＢにも実行された場合、アプリケーションＢリソースプール３７０のリソースプール容量が減少しリソース量が増加し、リソースプール容量とリソース量は逆比例の関係になる。

このようにして、仮想リソース管理サーバ１００は、負荷変動が発生したアプリケーションと相関関係のある相関アプリケーションを特定し、相関アプリケーションについてスケーリングを実行する前にリソースプールのリソースの容量制御を行うことができる。これにより、仮想リソース管理サーバ１００は、相関アプリケーションに対するリソースの枯渇や、過剰なリソースの割当てを低減できる。

クラウドシステム３００では、アプリケーションごとに必要となるリソースの容量やリソースの消費単位やリソースの消費パターンが異なるため、全てのアプリケーションに対して余裕を見込んだ設定にならざるを得ず、過剰なリソース割当てになる場合があった。あるサービスに対して過剰にリソースが割当てられた場合、クラウドシステム３００を共有して利用する他のサービスに利用できるリソースが減少するため、他のサービスに対して別途リソース割当てが必要となり、管理や運用コストが増大する懸念があった。また、クラウドシステム３００において、複数のアプリケーションで１つのサービスを提供する場合、アプリケーションのいずれかに対応するリソースプールのリソースが枯渇したことに伴い、サービス全体の処理能力が低下する等の影響が出る場合もあった。

仮想リソース管理サーバ１００が、相関アプリケーションについてスケーリングの実行前にリソースプールの制御を行うことで、リソースの過剰な割当てやサービス全体の処理能力の低下を軽減できる。

また、クラウドシステム３００において多数のアプリケーションが多段または分岐接続する複雑な構成である場合、運用者は、多数のアプリケーションの負荷変動や必要となるリソース量を事前に把握することは困難であり、制御に多大な労力を必要とした。

仮想リソース管理サーバ１００は、相関アプリケーションを特定してリソース量の制御を行うことで、運用者が多数のアプリケーションのリソース量の制御を行う労力を軽減できる。

こうして、仮想リソース管理サーバ１００は、あるアプリケーションのスケーリングに応じて他のアプリケーションのリソースプールの容量を制御し、リソースの枯渇を回避するとともに予備リソースの削減を図ることができる。

なお、上記の処理機能は、コンピュータによって実現することができる。その場合、制御装置５０、仮想リソース管理サーバ１００、仮想インフラ管理サーバ１８０、アプリケーション管理サーバ１９０、汎用サーバ２００，２０１，２０２が有すべき機能の処理内容を記述したプログラムが提供される。そのプログラムをコンピュータで実行することにより、上記処理機能がコンピュータ上で実現される。処理内容を記述したプログラムは、コンピュータで読み取り可能な記録媒体に記録しておくことができる。コンピュータで読み取り可能な記録媒体としては、磁気記憶装置、光ディスク、光磁気記録媒体、半導体メモリなどがある。磁気記憶装置には、ハードディスク装置（ＨＤＤ）、フレキシブルディスク（ＦＤ）、磁気テープなどがある。光ディスクには、ＤＶＤ、ＤＶＤ−ＲＡＭ、ＣＤ−ＲＯＭ（Read Only Memory）／ＲＷ（ReWritable）などがある。光磁気記録媒体には、ＭＯなどがある。

プログラムを流通させる場合には、たとえば、そのプログラムが記録されたＤＶＤ、ＣＤ−ＲＯＭなどの可搬型記録媒体が販売される。また、プログラムをサーバコンピュータの記憶装置に格納しておき、ネットワークを介して、サーバコンピュータから他のコンピュータにそのプログラムを転送することもできる。

プログラムを実行するコンピュータは、たとえば、可搬型記録媒体に記録されたプログラムもしくはサーバコンピュータから転送されたプログラムを、自己の記憶装置に格納する。そして、コンピュータは、自己の記憶装置からプログラムを読み取り、プログラムにしたがった処理を実行する。なお、コンピュータは、可搬型記録媒体から直接プログラムを読み取り、そのプログラムにしたがった処理を実行することもできる。また、コンピュータは、ネットワークを介して接続されたサーバコンピュータからプログラムが転送されるごとに、逐次、受け取ったプログラムにしたがった処理を実行することもできる。

また、上記の処理機能の少なくとも一部を、ＤＳＰ、ＡＳＩＣ、ＰＬＤなどの電子回路で実現することもできる。

１０ 第１機能
１１ 第１仮想マシン
１２，１３ 第１仮想マシンに含まれる仮想マシンの増加
１４ 第１予備仮想マシン
１５，１６ 第１予備仮想マシンに含まれる予備仮想マシンの減少
２０ 第２機能
２１ 第２仮想マシン
２２，２３ 第２仮想マシンの増減なし
２４ 第２予備仮想マシン
２５，２６ 第２予備仮想マシンの容量の増加
５０ 制御装置
５１ 制御部
５１ａ 仮想マシン制御
５１ｂ 相関有無判定制御
５１ｃ 予備仮想マシン制御

Claims (8)

1. 所定の機能を実行する仮想マシンと前記所定の機能を実行するために用意される予備仮想マシンを割当てる制御装置であって、
   第１機能を実行する仮想マシンの増減と、第２機能を実行する仮想マシンの増減との相関の有無を判定し、
   前記相関があるとき、前記第１機能を実行する仮想マシンの増減に基づいて、前記第２機能を実行するために用意される予備仮想マシンの最大容量を決定する制御部、
   を備える制御装置。
2. 前記制御部は、
   前記第１機能を実行する仮想マシンを増減した時間と、前記第２機能を実行する仮想マシンを増減した時間とを履歴情報として記憶部に記憶し、
   前記第１機能を実行する仮想マシンの増減と、前記第２機能を実行する仮想マシンの増減とが、所定の時間内に行われている関係情報を前記履歴情報から抽出し、
   前記抽出した関係情報に基づいて前記第２機能を前記相関があると判定する、
   請求項１記載の制御装置。
3. 前記制御部は、
   前記第１機能を実行する仮想マシンの増減に基づいて、前記第２機能を実行するために用意される予備仮想マシンの容量を増減し、前記第２機能を実行するために用意される予備仮想マシンの量を増減する制御を行う、
   請求項１記載の制御装置。
4. 前記制御部は、
   前記第１機能を実行する仮想マシンの増減が前記仮想マシンを増やすものであった場合、
   前記第２機能を実行するために用意される予備仮想マシンの容量を増やし、前記第２機能を実行するために用意される予備仮想マシンの量を増やす制御を行う、
   請求項１記載の制御装置。
5. 前記制御部は、
   前記第１機能を実行する仮想マシンの増減が前記仮想マシンを減らすものであった場合、
   前記第２機能を実行するために用意される予備仮想マシンの容量を減らし、前記第２機能を実行するために用意される予備仮想マシンの量を減らす制御を行う、
   請求項１記載の制御装置。
6. 前記制御部は、
   前記第２機能を実行するために用意される予備仮想マシンの容量に基づいて前記第２機能を実行するために用意される予備仮想マシンの容量を増減する容量を決定し、
   前記第２機能を実行するために用意される予備仮想マシンの量に基づいて前記第２機能を実行するために用意される予備仮想マシンの量を増減する量を決定する、
   請求項１記載の制御装置。
7. 前記制御部は、
   前記第１機能を実行する仮想マシンの増減が前記仮想マシンを増やすものであった場合、かつ、前記第２機能を実行するために用意される予備仮想マシンの量が所定の量に満たない場合、前記第２機能を実行するために用意される予備仮想マシンの量を増やさずに、前記第２機能を実行する仮想マシンを増やす、
   請求項１記載の制御装置。
8. 所定の機能を実行する仮想マシンと前記所定の機能を実行するために用意される予備仮想マシンを割当てる制御方法であって、
   コンピュータが、
   第１機能を実行する仮想マシンの増減と、第２機能を実行する仮想マシンの増減との相関の有無を判定し、
   前記相関があるとき、前記第１機能を実行する仮想マシンの増減に基づいて、前記第２機能を実行するために用意される予備仮想マシンの最大容量を決定する、
   処理を実行する制御方法。

Images