JP2016103179A - 計算機リソースの割り当て方法及び計算機システム - Google Patents

Abstract

【課題】クラウド・システムにおいて、性能の低下を抑制して、適切な計算機リソースを提供する【解決手段】物理計算機の計算機リソースを仮想計算機に割り当てる仮想化部と、１以上の仮想計算機でサービスを提供する仮想計算機群を制御する管理計算機と、を備えた計算機システムであって、管理計算機は、前記サービスを提供する前記仮想計算機群の性能を取得して、前記取得した前記仮想計算機群の性能と、予め設定された前記サービスの性能条件とを比較し、当該比較結果に応じて、前記仮想計算機群で変更する計算機リソースを決定する制御部と、前記変更の対象となる計算機リソースに応じた仮想計算機で前記サービスを試行して、当該仮想計算機の性能を測定する性能測定部と、を有し、前記制御部は、前記測定した性能が前記サービスの性能条件を満たす場合には前記変更を適用する。【選択図】図４

Description

本発明は、サービスに割り当てる計算機資源を動的に変更可能な計算機システムに関する。

近年のクラウド・コンピューティング技術の開発やクラウド・サービスの提供によって、サービスの利用者はハードウェアを管理する必要がなく、オペレーティング・システムやミドルウェアよりも上位のシステムのみを管理すればよいという環境が整いつつある。

クラウド・システムはＡＷＳ（Amazon Web Services）に代表されるようなパブリック・クラウドやプライベート・クラウド、あるいはそれらとオンプレミスのシステムを組み合わせたフェデレーテッド・クラウドがあり、構成方法は多岐にわたる。

多岐にわたるクラウド・システムの構成パターンの中から性能やコストに関して最適な構成を選択したいという要求が今後ますます大きくなると考えられる。さらにサービスはある程度需要予測が可能なものがある一方で、Ｗｅｂサービスなどでは需要予測が難しく、需要に対して動的にシステム性能を変更したいという要求は大きい。

特許文献１は、クラウド・システムにおけるクラウド・プロバイダ間あるいはクラウド基盤間の計算機資源（リソース）を共有する技術に関するものである。サービスがあるクラウド・システム上で稼働しており、当該クラウド・システムには余剰の計算機リソースがない場合、当該サービスが新たな計算機リソースを他のクラウド・プロバイダで獲得する技術が開示されている。

特表２０１３−５１３１３９

クラウド・システムでは複数のサービスが稼働していることが多い。あるいは、クラウド・システムでは複数のユーザが同じ計算機リソースを共有している場合がある。各クラウド・プロバイダが公表するカタログを参照することでユーザはクラウド・システムの性能を知ることができるが、クラウド・システムでは一般的に性能の保障はなく、いつ計算機リソースが獲得されたかによって実際の性能が大きく変わってしまうことがある。

これは、カタログ上は同じ性能でも実際には異なる物理リソースが割り当てられる場合がある。あるいは同じ計算機リソースを共有している他のプロセスがＣＰＵ、メモリ、ディスク、ネットワークなどを過剰に使用していることがあり、実際に割り当てられた計算機リソースでは、カタログのスペックよりも性能が低下することがある。これらはクラウド・システムにおいて、性能が保障されていない問題であることが広く認識されている。

そこで本発明は、上記問題点に鑑みてなされたもので、クラウド・システムにおいて、性能の低下を抑制して、適切な計算機リソースを提供することを目的とする。

本発明は、プロセッサとメモリを備えた物理計算機と、前記物理計算機の計算機リソースを仮想計算機に割り当てる仮想化部と、１以上の前記仮想計算機でサービスを提供する仮想計算機群を制御する管理計算機とを備えた計算機システムで、前記仮想計算機群を動的に変更する計算機リソースの割り当て方法であって、前記管理計算機が、前記サービスを提供する前記仮想計算機群の性能を取得する第１のステップと、前記管理計算機が、前記取得した前記仮想計算機群の性能と、予め設定された前記サービスの性能条件とを比較する第２のステップと、前記管理計算機が、前記比較結果に応じて、前記仮想計算機群で変更する計算機リソースを決定する第３のステップと、前記管理計算機が、前記変更の対象となる計算機リソースに応じた仮想計算機で前記サービスを試行して、当該仮想計算機の性能を測定する第４のステップと、前記管理計算機が、前記測定した性能が前記サービスの性能条件を満たすか否かを判定する第５のステップと、前記管理計算機が、前記測定した性能が前記サービスの性能条件を満たす場合には、前記変更を適用する第６のステップと、を含む。

したがって、本発明は、コストや性能において最適な計算機リソースを提供しながらも、負荷の増減に対して動的に対応することができる。

本発明の第１の実施例を示し、クラウド・システムの概略を示すブロック図である。 本発明の第１の実施例を示し、クラウド基盤の一例を示すブロック図である。 本発明の第１の実施例を示し、管理サーバの機能の一例を示すブロック図である。 本発明の第１の実施例を示し、管理サーバで行われる処理の一例を示すフローチャートである。 本発明の第１の実施例を示し、クラウド・システムで行われる性能テストの一例を示すシーケンス図である。 本発明の第１の実施例を示し、運用中システムの性能テストの結果の一例を示す図である。 本発明の第１の実施例を示し、テスト対象のＶＭセットの性能テストの結果の一例を示す図である。 本発明の第１の実施例を示し、インスタンス毎の性能テスト結果の一例を示す図である。 本発明の第１の実施例を示し、システム情報の一例を示す図である。 本発明の第１の実施例を示し、ＶＭ毎のシステム情報の一例を示す図である。 本発明の第１の実施例を示し、データセンタ毎のリソース情報の一例を示す図である。 本発明の第１の実施例を示し、リクエストの一例を示す図である。 本発明の第１の実施例を示し、リクエストパターンの一例を示す図である。 本発明の第１の実施例を示し、物理計算機の構成の一例を示すブロック図である。 本発明の第１の実施例を示し、ＳＬＡの入力画面の一例を示す画面イメージである。 本発明の第１の実施例の変形例を示し、クラウド・システムの機能の一例を示すブロック図である。

以下、本発明の実施形態を添付図面に基づいて説明する。

本発明は、単一あるいは複数のクラウド・システム上に構築された業務システム（またはクライアントシステム）について、ユーザからのリクエストに応じて動的に割り当てる計算機リソースを拡大及び縮小する技術であり、そのための基盤である。このクラウド・システムを用いることで、サービスは単一あるいは複数のクラウド基盤（またはデータセンタ）の中からコストや性能に基づいて最適な計算機リソースを獲得しながら、リクエストの増減に対して動的に応じることができる。

図１Ａは、本発明を適用したクラウド・システムの概略図を示すブロック図である。クラウド・システム１００、１０００は、複数の仮想計算機（ＶＭ）を含む計算機システムである。なお、クラウド・システム１００、１０００は本明細書に説明される構成や機能の範囲を限定するものではない。

クラウド・システム１００は第１のデータセンタを構成し、クラウド・システム１０００は第２のデータセンタを構成する。クラウド・システム１００とクラウド・システム１０００は地理的に異なる場所に配置され、あるいは、異なる建屋や、異なるフロアなどに配置することができる。

クラウド・システム１００とクラウド・システム１０００は、ＶＰＮ（Ｖｉｒｔｕａｌ Ｐｒｉｖａｔｅ Ｎｅｔｗｏｒｋ）９０を介してクラウド基盤１０１とクラウド基盤１００３が接続され、クラウド・システム１００とクラウド・システム１０００はひとつのネットワークとしてアクセス可能である。

クラウド・システム１００は、外部のネットワーク８０を介してエンドユーザ端末１０３に接続される。クラウド・システム１００は、管理ネットワーク６０を介してクラウド基盤管理者端末１０２とアプリ管理者端末１１６に接続される。

クラウド・システム１００は、クラウド基盤１０１によって中心的な部分が構成されている。クラウド基盤１０１はクラウド基盤管理者端末１０２に管理されている。クラウド基盤１０１は、構成要素として管理サーバ１０４と、管理データ１０５と、リソースプール１１８と、ロードバランサ１０６と、データベース（図中ＤＢ）１１５を備える。

また、クラウド・システム１００は、リソースプール１１８から割り当てられた仮想計算機（ＶＭ）セット１１７を備える。ＶＭセット１１７は、アプリ管理者端末１１６が生成したウェブアプリケーション（図中ＷｅｂＡｐｐ）によるサービスを提供するＷｅｂＡｐｐサーバ１１２−１〜１１２−３を含む。なお、ＷｅｂＡｐｐサーバの総称を添え字のない符号１１２で表す。また、他の構成要素についても同様であり、構成要素の総称を添え字のない符号で示す。

また、エンドユーザ端末１０３へサービスを提供する１以上の仮想計算機群（ＷｅｂＡｐｐサーバ１１２−１〜１１２−３）を、運用中システムまたはクライアントシステムとする。

ロードバランサ１０６と、ＷｅｂＡｐｐサーバ１１２とデータベース１１５は、業務ネットワーク７０と管理ネットワーク６０に接続される。管理サーバ１０４と、リソースプール１１８と、クラウド基盤管理者端末１０２と、アプリ管理者端末１１６は管理ネットワーク６０のみに接続される。

これらのＷｅｂＡｐｐサーバ１１２はロードバランサ（図中ＬＢ）１０６を介してネットワーク８０に接続される。エンドユーザ端末１０３から送信されたリクエストは、ネットワーク８０を介してロードバランサ１０６で受信され、各ＷｅｂＡｐｐサーバ１１２−１〜１１２−３に振り分けられる。

データベース１１５は、ウェブアプリケーションが使用するサービスのデータを格納し、ＷｅｂＡｐｐサーバ１１２に接続される。

ロードバランサ１０６、ＷｅｂＡｐｐサーバ１１２では性能測定とリソースの使用状況の取得のために監視エージェントが稼働している。各ＷｅｂＡｐｐサーバ１１２及びロードバランサ１０６の監視エージェントのログは管理サーバ１０４に送られ、管理データ１０５に蓄積される。

管理サーバ１０４は、後述するように、ＷｅｂＡｐｐサーバ１１２に割り当てる仮想計算機の拡大または縮小を行う前に、クライアントシステムを構成する仮想計算機の性能テストを実行する。そして、性能テストの結果、所定の性能条件を満足する仮想計算機を選択して、仮想計算機の追加または削減を動的に実施する。

ロードバランサ１０６は、性能測定を行うための機能として、上記性能テストが開始されるとエンドユーザ端末１０３からのリクエストをランダムにコピーして、性能テストの対象になるＶＭセットに振り分ける機能を備える。ＨＴＴＰリクエストのコピーは、すべてランダムに選択する場合、ロードバランサ１０６がＨＴＴＰセッションを維持した上でランダムに選択する場合が考えられる。

さらに、ロードバランサ１０６はエンドユーザ端末１０３からのリクエストに対する平均応答時間を測定し、管理サーバ１０４に送信する機能を備える。ロードバランサ１０６は、また、エンドユーザ端末１０３からのリクエストを蓄積するために、管理サーバ１０４にコピーしたリクエストを送信する機能を備える。

データベース１１５では、性能テストを行う際に不整合がおきないようにする機能が必要である。データベース１１５では、スナップショットを使う。性能テストで発生した読み込みまたは書き込みアクセスを、データベース１１５のスナップショットで処理することで本番環境のデータに不整合が発生するのを防止する。

リソースプール１１８は、新たに仮想計算機（ＶＭ）を生成するためのＣＰＵ、メモリ、ディスクを含む計算機リソースである。リソースプール１１８は管理サーバ１０４に接続されており、ＶＭの生成や削除などの命令は管理サーバ１０４から受け、ハイパバイザがＶＭの生成、削除を実施する。

クラウド・システム１００に接続されたクラウド・システム１０００は、リソースプール１０１０と、仮想計算機１１１２−１〜１１１２−２を含むＶＭセット１０９をクラウド基盤１００３に含む。

図１Ｂは、本発明の第１の実施例を示し、クラウド基盤１０１の一例を示すブロック図である。クラウド基盤１０１は、管理ネットワーク６０を介して物理計算機１と、ロードバランサ１０６と、管理サーバ１０４と、リソースプール１１８と、データベース１１５を格納するストレージ装置５０が接続される。また、ロードバランサ１０６と、ＶＭセット１１７を構成するＶＭ＃１（１１２−１）、ＶＭ＃２（１１２−２）、ＶＭ＃３（１１２−３）と、データベース１１５は業務ネットワーク７０を介して接続される。

物理計算機１は、後述する図１２に示す物理リソース１０と、物理リソース１０上で稼働するハイパバイザ（仮想化部）２０と、ハイパバイザ２０上で稼働する複数のＶＭ＃１〜ＶＭ＃３からなるＶＭセット１１７とを含む。

ＶＭ＃１〜ＶＭ＃３では、それぞれ、性能及び計算機リソースを監視する監視エージェント２２と、ウェブアプリケーション（図中ＷｅｂＡｐｐ）２１が稼働する。このため、ＶＭ＃１〜ＶＭ＃３はＷｅｂＡｐｐサーバ１１２−１〜１１２−３として機能する。ウェブアプリケーション２１は、ＨＴＴＰサーバとアプリケーションサーバの機能を備え、データベース１１５を利用する。

リソースプール１１８も上記と同様であり、後述する図１２に示す物理計算機と、物理計算機上で稼働するハイパバイザ（仮想化部）２０と、ハイパバイザ２０上で稼働する複数の仮想計算機を含む。

図示はしないが、クラウド・システム１０００も同様であり、１以上の物理計算機と複数の仮想計算機が含まれ、管理サーバ１０４によって未割当の仮想計算機１１１２−１、１１１２−２がリソースプール１０１０に登録されている。

なお、ハイパバイザ２０に代わって、ＶＭＭ（Ｖｉｒｔｕａｌ Ｍａｃｈｉｎｅ Ｍｏｎｉｔｏｒ）を採用しても良い。

図１２は、物理計算機１の構成の一例を示すブロック図である。物理計算機１は通信装置１４０２と、ＣＰＵ１４０３と、メモリ１４０４と、表示装置１４０５と、入力装置１４０６と、記憶装置１４０７とを備え、管理ネットワーク６０と、業務ネットワーク７０に接続される。

本実施例では、管理サーバ１０４とロードバランサ１０６は図１２と同様の物理計算機で構成する例を示すが、仮想計算機で構成してもよい。なお、クラウド・システム１０００の仮想計算機１１１２−１、１１１２−２も図１２と同様の物理計算機１上で稼働する。なお、ＣＰＵ１４０３は、マルチコアプロセッサで構成することができる。

図２は、管理サーバ１０４の詳細を示すブロック図である。管理サーバ１０４は表示内容生成部２０３、制御プログラム２０８、管理データ１０５を備える。表示内容生成部２０３、制御プログラム２０８は、図１２に示したメモリ１４０４にロードされて、ＣＰＵ１４０３によって実行される。

管理サーバ１０４は、クラウド基盤管理者端末１０２およびアプリ管理者端末１１６が表示内容生成部２０３に接続されており、入出力の処理を行う。表示内容生成部２０３が出力する入力画面２１４０は、図１３に示す。

制御プログラム２０８は全体統制部２０５と、ログ記憶部２０６と、ＤＢ管理部２０７と、性能測定部２２０とを備える。

全体統制部２０５は、アプリ管理者端末１１６が決定した入力を満たすように仮想計算機をリソースプール１１８から切り出す機能を備える。

ログ記憶部２０６は、各ＷｅｂＡｐｐサーバ１１２やデータベース１１５やロードバランサ１０６などの管理サーバ１０４の管理下の装置で稼働する監視エージェント２２から応答時間等の性能情報とＶＭのサイズなどのリソースの使用状況を収集し、管理データ１０５の運用中システムの性能ログ２０９に蓄積する。

また、ログ記憶部２０６は、エンドユーザ端末１０３からロードバランサ１０６に送られるリクエストを取得し、管理データ１０５のリクエストパターン２１５に格納する。あるいは、ロードバランサ１０６がリクエストの複製を管理サーバ１０４へ送信し、ログ記憶部２０６が取得してリクエストパターン２１５に蓄積することができる。なお、運用中システムの性能ログ２０９は、ロードバランサ１０６で稼働する監視エージェント２２がＷｅｂＡｐｐサーバ１１２の応答時間等の性能情報を取得した性能情報である。ロードバランサ１０６は、性能情報を管理サーバ１０４へ送信し、管理サーバ１０４は、受信した性能情報を運用中システムの性能ログ２０９に蓄積する。なお、この性能情報は、運用中システム（クライアントシステム）の性能情報となる。

ＤＢ管理部２０７は、データベース１１５を管理する。特に本発明では後述する図３や図４に記述されるように仮想計算機の性能テストストを行うが、ＤＢ管理部２０７は性能テスト中に運用中のシステムに不整合が起こらないようにする機能を備える。

性能測定部２２０は、クラウド・システム１００が拡大または縮小するときに生成される仮想計算機（ＶＭ）の性能テストを行う。本実施例では、管理サーバ１０４は、ＷｅｂＡｐｐサーバ１１２に割り当てる仮想計算機の拡大または縮小を行う前に、テスト用の仮想計算機を生成し、性能測定部２２０が当該仮想計算機の性能テストを実行する。そして、管理サーバ１０４は、テスト用の仮想計算機のうちＳＬＡ情報を満足する仮想計算機を拡大または縮小の対象として選択する。なお、ＳＬＡ情報は、後述するように、性能条件とコスト条件を含む運用情報である。

管理データ１０５は運用中のシステムの性能ログ２０９と、テストシステムの性能ログ２１０と、リソース一覧２１１と、ＳＬＡ情報２１４と、リクエストパターン２１５と、ＶＭ性能情報２１６とを備える。

運用中システムの性能ログ２０９は、図５Ａで示すように、秒間リクエスト数５０３と応答時間５０４を含む。秒間リクエスト数５０３は、ロードバランサ１０６が受け付けた単位時間当たりのリクエスト数を示す。応答時間５０４は、ロードバランサ１０６がエンドユーザ端末１０３からリクエストを受け付けてから応答するまでの時間を示す。なお、本実施例では、１つのサービスをＷｅｂＡｐｐサーバ１１２−１〜１１２−３で提供する例を示すが、複数のサービスを提供する場合には、サービス毎に運用中システムの性能ログ２０９を生成することができる。

テストシステムの性能ログ２１０は、図５Ｂで示すように、新しく生成されたＶＭの性能テストにおける秒間リクエスト数５０５と応答時間５０６を含む性能ログである。秒間リクエスト数５０５と応答時間５０６は、図５Ａの運用中システムの性能ログ２０９と同様である。

リソース一覧２１１は、クラウド・システム１００、１０００ごとに利用可能なＣＰＵ、メモリ、ディスク、利用料金など計算機リソースの情報を含む。図９はデータセンタ毎のリソース一覧２１１を示す図である。

リソース一覧２１１は、クラウド・システム１００またはクラウド基盤１０１の識別子（名称やＩＰアドレス）を格納するＶＭ基盤９０１と、クラウド基盤１０１内のストレージの容量を格納するＤｉｓｋ９０２と、クラウド基盤１０１内の主記憶の容量を格納するメモリ９０３と、クラウド基盤１０１内のＣＰＵのコア数を格納するＣＰＵ（コア数）９０４と、仮想計算機の使用料金を格納するＶＭ価格（￥／ｈ）９０５と、クラウド基盤１０１の稼働率を格納する可用性９０６をひとつのエントリに含む。

ここで、ＶＭ価格（￥／ｈ）９０５には、クラウド・システム１００が割り当てる計算機リソースのサイズに応じて、小規模の割り当て量である“Ｓ（Ｓｍａｌｌ）”と、Ｓｍａｌｌの２．５倍の計算機リソースを割り当てる“Ｌ（Ｌａｒｇｅ）”のそれぞれについて、単位時間当たりの仮想計算機の使用料金が格納される。なお、計算機リソースのサイズは、メモリ容量やストレージ容量やＣＰＵコア数などで表すことができる。なお、ＶＭ基盤９０１には、リソースプールのＩＰアドレスを含んでもよい。

なお、上記では計算機リソースのサイズをＳｍａｌｌやＬａｒｇｅなどにより段階的に設定する例を示したが、ＣＰＵ１４０３のコア数やメモリ容量などで示してもよい。

ＳＬＡ（Ｓｅｒｖｉｃｅ Ｌｅｖｅｌ Ａｇｒｅｅｍｅｎｔ）情報２１４は、図７で示すように、エンドユーザが定めるコスト７０３と、要求応答時間７０４と、要件の優先順位７０５と、可用性７０６と、クラウド・プロバイダ７０７と、デプロイするアプリ７０８と、システム構成７０９とを含む。ＳＬＡ情報２１４は、アプリ管理者端末１１６が予め設定する情報または条件である。

図７は、ＳＬＡ情報２１４の一例を示す図である。ＳＬＡ情報２１４は、要件７０１と内容７０２のフィールドをひとつのエントリに含む。

コスト７０３には、エンドユーザとクラウド・システム１００のデータセンタが契約した時間当たりの利用料金の上限が設定される。要求応答時間７０４には、クラウド・システム１００がリクエストを受け付けてから応答を送信するまでの許容時間を設定される。要件の優先順位７０５には、要件７０１のうち第１に優先すべき要件と、第２に優先すべき要件が設定される。可用性７０６には、エンドユーザとクラウド・システム１００が契約した稼働率が設定される。クラウド・プロバイダ７０７には、利用可能な１以上のクラウド・プロバイダの名称が設定される。デプロイするアプリ７０８には、エンドユーザが使用するアプリケーションとアプリケーションの配置に関する情報が設定される。システム構成７０９には、エンドユーザが使用するシステムの内容が設定される。

なお、本実施例では、１つのエンドユーザがクラウド・システム１００を利用する例を示すが、クラウド・システム１００が複数のエンドユーザにサービスを提供する場合には、エンドユーザ毎にＳＬＡ情報２１４が設定される。

次に、リクエストパターン２１５は、エンドユーザ端末１０３が過去にクラウド・システム１００へ送ったリクエストを蓄積した集合である。図１０は、リクエストの一例を示す図である。図１０は、一つのＰＯＳＴリクエスト１１０１の一例を示す。ＨＴＴＰリクエストではＧＥＴリクエストも含まれる。

図１１は、リクエストパターン２１５の一例を示す図である。リクエストパターン２１５は、番号１２０１と、リクエスト１２０２をひとつのエントリに含む。リクエスト１２０２には、アクセスのメソッドや、ＵＲＬなどが含まる。

ＶＭ性能情報２１６は、運用中のクラウド・システム１００のＶＭの性能情報であり、ＶＭごとにサイズと応答時間を備える。

図８は、ＶＭ性能情報２１６の一例を示す図である。ＶＭ性能情報２１６は、ＶＭの識別子及び場所を格納するＶＭ ＩＤ８０１と、ＶＭの規模を格納するＶＭサイズ８０２と、ロードバランサ１０６がリクエストを送信してからＶＭが応答を受信するまでの時間を格納する応答時間８０３とを含む。

ＶＭサイズ８０２は、上記リソース一覧２１１と同様であり、Ｓｍａｌｌに割り当てる計算機リソースを１とすると、Ｌａｒｇｅに割り当てる計算機リソースは２．５倍となる。したがって、ＶＭサイズ８０２＝Ｓｍａｌｌ×２は、Ｓｍａｌｌの２倍の計算機リソース量となる。なお、ＶＭ性能情報２１６は、管理サーバ１０４が、ロードバランサ１０６から所定の周期などで取得し、更新する。

なお、管理サーバ１０４が実行する制御プログラム２０８は、大きく分けて、全体統制部２０５と、ログ記憶部２０６と、ＤＢ管理部２０７と、性能測定部２２０の４つの機能を有するが、それらの機能は独立したサーバで分散して実行されても良い。

図３は、管理サーバ１０４で行われる割り当て計算機リソースを増加する処理の一例を示すフローチャートである。

クラウド・システム１００では、ＷｅｂＡｐｐサーバ１１２−１〜１１２−３でエンドユーザ端末１０３に対して所定のサービスを提供している。エンドユーザ端末１０３はＷｅｂＡｐｐサーバ１１２で稼働しているサービスに対してリクエストを送信し、ＷｅｂＡｐｐサーバ１１２は逐次処理して応答する。

応答時間などの性能情報と計算機リソースの使用状況は、ロードバランサ１０６やＶＭ＃１〜ＶＭ＃３の監視エージェント２２によって常に監視されている。アプリ管理者端末１１６は、予めＳＬＡ情報２１４を定めて管理サーバ１０４に送信し、管理サーバ１０４で保存されている。管理サーバ１０４は、所定の周期で各監視エージェント２２からの性能情報と計算機リソースの使用状況を取得し、運用中システムの性能ログ２０９を更新する。

管理サーバ１０４の、全体統制部２０５は、ロードバランサ１０６等の監視エージェント２２からの監視結果がＳＬＡ情報２１４を満たさないと判定すると、図３のフローチャートを開始して、監視対象のＷｅｂＡｐｐサーバ１１２にＳＬＡ情報２１４を満たす計算機リソースを追加する。なお、管理サーバ１０４が図３の処理を開始する契機としては、運用中システムの性能ログ２０９を監視してＳＬＡ情報２１４を維持できなくなったときの他、クラウド基盤管理者端末１０２からの指令を受信したときなど、所定の契機であればよい。

ステップ３０１では、管理サーバ１０４のＤＢ管理部２０７が、データベース１１５の記憶領域のスナップショットを生成する。生成されたスナップショットは、例えば、ストレージ装置５０に格納しておけば良い。

ステップ３０２では、管理サーバ１０４の全体統制部２０５が現在稼働しているクラウド基盤１０１で、計算機リソースに余剰があるかを判定する。この判定は、全体統制部２０５が、現在運用中のＷｅｂＡｐｐサーバ１１２に割り当てた計算機リソースと同等の計算機リソースをリソースプール１１８で確保可能であるかを基準として判定する。現在ＷｅｂＡｐｐサーバ１１２が稼働しているクラウド基盤１０１で、十分な計算機リソースがリソースプール１１８で確保できない場合はステップ３０３に進む。

ステップ３０３では、全体統制部２０５が、リソース一覧２１１のうちからＶＭを生成するのに十分な計算機リソースをリソースプールで確保可能な他のクラウド基盤を選択する。このとき、全体統制部２０５が、図９に示されるデータセンタごとの利用可能な計算機リソースを示すリソース一覧２１１を参照する。このリソース一覧２１１は、全体統制部２０５が各クラウド・プロバイダや、データセンタに所定の周期でアクセスすることで情報を取得して更新する。

なお、全体統制部２０５が選択するクラウド基盤は、ひとつではなく、複数のクラウド基盤を選択して遅延や処理性能が異なる計算機リソースを確保して性能テスト用のＶＭを生成してもよい。

上記ステップ３０２、３０３で、テスト用のＶＭを生成するクラウド基盤で計算機リソースが確保されると、ステップ３０４に進む。

ステップ３０４では、全体統制部２０５及び性能測定部２２０が、上記ステップ３０２、３０３で確保された計算機リソースを割り当てたＶＭを複数生成して、性能テストを実行する。

ここで、管理サーバ１０４の全体統制部２０５は、図６に示す、インスタンス毎のテスト結果テーブル６０１を生成する。

ここでは簡単のためクラウド・プロバイダごとに定義されるインスタンス（ＶＭインスタンス）のサイズがＳｍａｌｌとＬａｒｇｅのラベルは、同じ物理リソース量を指すものとする。さらにサイズＬａｒｇｅはＳｍａｌｌの計算機リソースの２．５倍とする。ただし、クラウド・プロバイダごとにインスタンス名や計算機リソースの性能値は異なる。なお、運用中のＷｅｂＡｐｐサーバ１１２のＶＭのサイズと応答時間の関係は、図８に示したＶＭ性能情報２１６から取得する。

さらに、全体統制部２０５は、ＳＬＡ情報２１４と運用中システムの性能ログ２０９を参照することで、クライアントシステムに追加する計算機リソースで処理すべきリクエストの量を推定することができる。

全体統制部２０５は、推定したリクエストの量から、サイズがＳｍａｌｌとＬａｒｇｅの計算機リソース（ＶＭ）をいくつ用意すれば良いかを推定することが可能である。すなわち、全体統制部２０５は、クライアントシステムに割り当てた計算機リソースについて、割り当てを変更する計算機リソースの量を決定する。

ただし、サイズがＳｍａｌｌとＬａｒｇｅの計算機リソース（ＶＭ）で、単位時間当たりに処理可能なリクエスト数は予め設定しておいてもよい。全体統制部２０５は、上記推測結果と各データセンタの情報を併せて、ＶＭセットの一覧を性能テスト結果テーブル６０１として生成する。

図６は、インスタンス毎の性能テスト結果テーブル６０１の一例を示す図である。図６の性能テスト結果テーブル６０１は、運用中システム（クライアントシステム）にＶＭを追加するため、テストを実行したＶＭセットの一覧を示すものである。

性能テスト結果テーブル６０１は、インスタンスの種類を格納するインスタンス６０２と、当該インスタンスを提供するクラウド・システムの場所とクラウド・プロバイダを格納する場所（事業者）６０３と、性能テストの結果、当該インスタンスの応答時間（秒）を格納する応答時間６０４と、単位時間当たりの使用料金を格納する価格６０５と、利用可能なクラウド・システム全体の単位時間当たりの使用料金を格納するシステム全体の価格６０６とがひとつのエントリに含まれる。

次に、クラウド・システム１００システムが、図８に示されるＶＭ＃１、ＶＭ＃２、ＶＭ＃３で構成され、図５Ａに示した運用中システムの性能ログ２０９のようにリクエストを１秒間で３００件程度受け付けているとする。

さらに、全体統制部２０５は、図９に示したデータセンタごとのリソース一覧２１１と、図７に示したＳＬＡ情報２１４を参照する。全体統制部２０５は、ＳＬＡ情報２１４の行７０４を参照し、要求応答時間は６秒以内という定義を取得する。全体統制部２０５は、図５Ａの運用中システムの性能ログ２０９を参照し、応答時間６秒とするには運用中システムで２００件のリクエストを処理し、残りの１００件のリクエストを他のシステム（計算機リソース）で処理する必要があることを判定することができる。

また、クラウド・システム１００の構成が変更される前は、図８に示したようにＶＭ＃１、ＶＭ＃２、ＶＭ＃３のＬａｒｇｅ＝１台、Ｓｍａｌｌ＝３台分で稼働しているので、全体統制部２０５は、外部の計算機リソースからＳｍａｌｌ＝２．２５台分を確保する必要があると判定できる。すなわち、ＷｅｂＡｐｐサーバ１１２は、Ｓｍａｌｌ相当で５．５台分の計算機リソースで２００のリクエストを処理し、残りの１００のリクエストをＳｍａｌｌ相当で２．２５台分の計算機リソースで処理することを示す。

全体統制部２０５が、Ｓｍａｌｌ＝２．２５台分の計算機リソースを確保する方法として、Ｓｍａｌｌ＝１台、Ｓｍａｌｌ＝×２台、Ｌａｒｇｅ＝１台が価格の上限（図７のコスト７０３）から候補となりうる。

その結果、全体統制部２０５は、図７の行７０７から利用可能なクラウド・プロバイダを取得し、クラウド・プロバイダ毎に、Ｓｍａｌｌ＝１台、Ｓｍａｌｌ＝×２台、Ｌａｒｇｅ＝１台のエントリを、図６に示した性能テスト結果テーブル６０１のインスタンス６０２、場所６０３に生成する。また。全体統制部２０５は、図６の価格６０５、システム全体の価格６０６には、図示しないカタログ情報の値を設定する。

ステップ３０４では、全体統制部２０５が生成した性能テスト結果テーブル６０１に基づいてテスト用のＶＭを生成して、性能テストを行う。全体統制部２０５がテスト用のＶＭを生成するとき、単一のＶＭセットあるいは複数のＶＭセットを生成して同時にテストを行う。性能測定部２２０は、テスト用のＶＭでクライアントシステムと同様のウェブアプリケーション２１を実行し、サービスを試行させる。そして、サービスを試行中のテスト用のＶＭの性能を測定する。

本実施例では、図１に示すように、全体統制部２０５、異なるクラウド・プロバイダのクラウド・システム１０００で、リソースプール１０１０からテスト用のＶＭセット１０９を生成する例を示す。また、全体統制部２０５、クラウド・システム１００でも、リソースプール１１８からテスト用のＶＭセット４０５（図４参照）を生成する。

図１のクラウド・システム１０００は、ＷｅｂＡｐｐサーバにおけるスケールアウトを示しており、ＶＭセット１０９、４０５（図示省略）がテストされる例である。１つのＶＭセット１０９であるＶＭ１１１２−１、１１１２−２が、クラウド・システム１００のロードバランサ１０６に登録される。

性能測定部２２０は、生成したＶＭ１１１２−１、１１１２−２にウェブアプリケーション２１を実行させる。ロードバランサ１０６は、ＷｅｂＡｐｐサーバ１１２へのリクエストをコピーし、コピーしたリクエストをテスト用のＶＭ１１１２へ送信する。テスト用のＶＭ１１１２は、ロードバランサ１０６からのリクエストの複製を受信して、ウェブアプリケーション２１が処理を実行し、クライアントシステムのサービスを試行する。性能測定部２２０は、サービスを試行している期間で、テスト用のＶＭ１１１２の性能を測定する。性能の測定は、ロードバランサ１０６の監視エージェント２２がテスト用のＶＭの応答時間を測定し、管理サーバ１０４へ送信する。

ステップ３０４では、テスト用のＶＭセット１０９、４０５の性能テストを並列で行う場合があるが、運用中システム（ＷｅｂＡｐｐサーバ１１２）の性能に対して影響がないようにする必要がある。このため、性能テストを行うＶＭセットは性能測定部２２０によって開始時刻をずらすことで運用中システムの計算機リソースの稼働率が徐々に上昇する。

そして、全体統制部２０５は、配下の監視する監視エージェント２２からの性能ログを取得して、運用中システムのハードウェア計算機リソースの稼働率と、クラウド・システム１００の性能を常に監視することで運用中システムに影響を与えないようにする。

１つ以上のＶＭセット１０９、４０５を生成した場合、全体統制部２０５がステップ３０５でＶＭに対する性能テストの結果から、ＳＬＡ情報２１４を満たす最適なＶＭセット１０９を選択する。

上記図６の性能テスト結果テーブル６０１を生成した時点では、応答時間６０４が未定であったが、上記性能テストを行うことで、性能測定部２２０が応答時間６０４に値を設定することができる。なお、図６において、Ａ社のＶＭが図１のＶＭセット１０９に相当する。その他のＶＭセットは、クラウド・システム１００の図示しないテスト用のＶＭとして生成されたものである（ＶＭセット２）。

図６に示す性能テスト結果テーブル６０１では、図７のＳＬＡ情報２１４のコスト９５０円／時間以内、要求応答時間６秒以内を満たすものとしてＶＭセット（６０７）が選ばれる。なお、図６の行６０８は、運用中システム（ＷｅｂＡｐｐサーバ１１２）の性能劣化を引き起こす可能性があったため、性能測定部２２０が性能測定をしなかった場合を示す。

ここで、性能測定部２２０は、性能テストを実施した各ＶＭセット１０９、４０５について、図５Ｂに示したテストシステムの性能ログ２１０を生成する。図５Ａの運用中システムの性能ログ２０９は、運用中のＷｅｂＡｐｐサーバ１１２に対して生成されたテーブルである。

また、ステップ３０６では、全体統制部２０５が選択したＶＭ（１１１２）を運用中システムに組み込む。このとき、全体統制部２０５は、ロードバランサ１０６に追加されたＶＭについてリクエストの振り分け割合の設定を行う。すなわち、全体統制部２０５は、クラウド・システム１００のＷｅｂＡｐｐサーバ１１２へリクエストの２／３を振り分け、クラウド・システム１０００のＷｅｂＡｐｐサーバ１１１２へリクエストの１／３を振り分けるように、ロードバランサ１０６に指令する。これにより、全体統制部２０５は、選択したＶＭセットをクライアントシステムに追加して計算機リソースの変更を動的に適用する。

上記ステップ３０４で複数のテスト用のＶＭセットが生成された場合は、性能測定部２２０が、選択されたテスト用のＶＭセット以外を削除する。また、性能テストで用いられたデータベース１１５のスナップショットは全体統制部２０５が削除する。

図４は、上記ステップ３０４で行われる性能テストの一例を示すシーケンス図である。 管理サーバ１０４の全体統制部２０５からリソースプール１１８、１０１０にＶＭセットを生成する命令が出される。なお、ＶＭセットの生成命令は、リソースプール１１８，１０１０の物理計算機上で稼働するハイパバイザ２０に対して送信される。全体統制部２０５から命令を受けるリソースプールは１つあるいは複数である。本実施例では、クラウド・システム１００のリソースプール１１８と、クラウド・システム１００のリソースプール１０１０でテスト用のＶＭを生成する例を示す。

リソースプール１１８、１０１０のハイパバイザ２０は一つあるいは複数のＶＭセットの生成命令をそれぞれ受け付け、テスト対象となるＶＭセット１０９、４０５を予め設定したＶＭイメージから生成する。

図４では２つのＶＭセット１０９、４０５が生成される場合を示しているが、２つのＶＭセットに限定されない。

図１において、運用中システムのＶＭセット１１７以外にテスト用のＶＭセット４０５と、クラウド・システム１０００にはテスト用のＶＭセット１０９が生成され、クラウド基盤１０１とクラウド基盤１００３が接続される。この例では、特にＷｅｂＡｐｐサーバにおけるスケールアウトを示しており、ＷｅｂＡｐｐサーバの候補としてテスト用のＶＭ１１１２−１、１１１２−２がロードバランサ１０６に追加される。なお、図４のＶＭセット４０５は、図１においては図示を省略した。

リソースプール１１８，１０１０のハイパバイザはＶＭ生成命令を受け付けると、管理サーバ１０４の全体統制部２０５にＶＭ生成の受け付け通知を送信する。その後、管理サーバ１０４の性能測定部２２０は、ロードバランサ１０６に対してＶＭセット１０９、４０５に負荷をかけるように命令する。このときロードバランサ１０６は運用中システムに対するリクエストをコピーして、リクエストの複製をＶＭセット１０９、４０５に送信する。

ロードバランサ１０６はＶＭセット１０９、４０５からの応答を受け付け、管理サーバ１０４の性能測定部２２０に応答時間などの測定結果を送る。管理サーバ１０４の全体統制部２０５は測定結果から上述のように最適なテスト対象のＶＭセット１０９を選択し、それ以外のテスト対象のＶＭセット４０５を削除するようにリソースプール１１８に通知する。そして、全体統制部２０５は、選択されたＶＭセット１０９を運用中システム（クライアントシステム）に追加する。

上記図４の性能テストにおいて、ロードバランサ１０６がリクエストのコピーをテスト用ＶＭに送信して、運用中システムと並列的に性能テストを行う例を示したが、性能テストの入力データは、リクエストのコピーに限定されるものではない。

管理サーバ１０４の性能測定部２２０が、リクエストパターン２１５に蓄積された過去のリクエストをテスト用のＶＭセット１０９、４０５へ送信することで、性能テストを実施しても良い。

この場合、まず全体統制部２０５が性能測定部２２０に対して負荷かけ開始の命令を出力する。続いて性能測定部２２０がロードバランサ１０６にリクエストを送り、ロードバランサ１０６がＶＭセット１０９、４０５にリクエストを振り分ける。

この例では、ロードバランサ１０６はリクエストをコピーする機能を持つ必要はない。ロードバランサ１０６に複数のポートあるいはＩＰアドレスを設定し、第１のポートあるいは第１のＩＰアドレスで受けたリクエストは運用中のシステムに振り分け、第２のポートあるいは第２のＩＰアドレスで受けたリクエストは性能テストの対象ＶＭセットに送られるように設定する。

上記ロードバランサ１０６で行うリクエストのコピーの機能はロードバランサ１０６とエンドユーザ端末１０３の間にスイッチを配置し、スイッチで代替することもできる。

図５Ａは、運用中のシステムの性能ログの一例を示す図である。図５Ｂは、テスト対象のＶＭセットの性能ログの一例を示す図である。

管理サーバ１０４は、テスト対象のＶＭセット１０９を運用中システムに追加する際に、運用中システムと追加されるテスト対象ＶＭセット１０９に対する負荷の割合を決定し、ＶＭが追加された後にシステム全体として応答性能が確保できるかを推定する。

運用中システムの性能ログ２０９は、運用中システムに関する性能情報を記録したテーブルである。運用中システムの性能ログ２０９は運用中システムの性能であり、運用開始後に生成されるテーブルである。

運用中システムの性能ログ２０９の、秒間リクエスト数５０３には、エンドユーザ端末１０３からのリクエスト数あるいはシステムに対する負荷を表す値が格納される。応答時間５０４は平均応答時間あるいは性能に関する情報を表す。

テストシステムの性能ログ２１０はテスト対象のＶＭセットに関する性能のテーブルである。テストシステムの性能ログ２１０は、性能テストの開始後に生成されるテーブルである。秒間リクエスト数５０５は、秒間リクエスト数５０３と同様にリクエスト数あるいはシステムに対する負荷の量を表す値が格納される。応答時間５０６は応答時間５０４同様に応答時間あるいは性能に関する情報を表すカラムである。

図１３は、ＳＬＡ情報２１４の入力画面２１４０の一例を示す画面イメージである。この入力画面２１４０は、管理サーバ１０４がアプリ管理者端末１１６へ提供する。図示の入力画面２１４０のフォーマットは、図７に示したＳＬＡ情報２１４と同様である。

入力画面２１４０は、要件２１４１と内容２１４２のフィールドをひとつのエントリに含む。コスト２１４３には、時間当たりの利用料金の上限が設定される。要求応答時間２１４４には、クラウド・システム１００がリクエストを受け付けてからＷｅｂＡｐｐ２１が応答を出力するまでの許容時間が設定される。要件の優先順位２１４５には、要件２１４１のうち第１に優先すべき要件と、第２に優先すべき要件が設定される。可用性２１４６には、エンドユーザとクラウド・システム１００が契約した稼働率が設定される。クラウド・プロバイダ２１４７には、利用可能な１以上のクラウド・プロバイダの名称が設定される。デプロイするアプリ２１４８には、エンドユーザが使用するアプリケーションとアプリケーションの配置に関する情報が設定される。システム構成２１４９には、エンドユーザが使用するシステムの内容が設定される。

図１４は、第１の実施例の変形例を示し、クラウド・システムの機能の一例を示すブロック図である。

図１４では、管理サーバ１０４がデータベース１１５のレプリカ１１９を生成し、レプリカに対してスナップショットを生成する。そして、テスト用のＶＭセット１０９はレプリカ１１９のスナップショットを利用して性能テストを実行する。この場合、運用中システムへの影響は、レプリカ１１９を用いない場合に比して小さくなる。

以上の処理によって、管理サーバ１０４は、運用中システムの性能ログ２０９を参照して、ＳＬＡ情報２１４を満足できないと判定すると、ＳＬＡ情報２１４を満足する計算機リソース量を決定し、当該計算機リソース量に相当するＶＭを生成して性能テストを実施する。管理サーバ１０４は、性能テストによりＳＬＡ情報２１４を満足することができると判定すると、当該計算機リソースを現在運用中のクライアントシステムに追加する。

これにより、クラウド・システム１００のカタログの性能ではなく、実際の性能に応じた計算機リソースをクライアントシステム（仮想計算機群）に割り当てることができる。
そして、クラウド・システム１００において、クライアントシステムの性能を保証して前記従来例のような性能の低下を抑制し、適切な計算機リソースを提供することが可能となる。また、クライアントシステムに追加する計算機リソースは、管理サーバ１０４が自動的に最適な量の計算機リソース（ＶＭのサイズまたは量）を演算し、演算結果に応じた計算機リソースを有するＶＭを生成する。そして、管理サーバ１０４は、生成したＶＭについて性能テストを実施して、性能テストの結果、ＳＬＡ情報２１４を満たすＶＭを選択することでＳＬＡ情報２１４を保証することができる。これにより、クラウド・システム１００でサービスを提供するクライアントシステムに割り当てる計算機リソースを効率よく制御することが可能となる。

前記実施例１では、クラウド・システム１００のクライアントシステムをスケールアウトさせ、計算機リソースを増加させる例を示した。本実施例２ではクラウド・システム１００のクライアントシステムが過剰な計算機リソースを保有する場合に、計算機リソースを解放する例について説明する。なお、クラウド・システム１００等の構成は前記実施例１と同様である。

管理サーバ１０４は運用中システムの性能ログ２０９を参照し、クライアントシステムの性能がアプリ管理者端末１１６が設定したＳＬＡ情報２１４を過剰に満たす場合、当該ＷｅｂＡｐｐサーバ１１２に割り当てられているＶＭの負荷を徐々に解除してＳＬＡ情報２１４を満たしていれば当該ＶＭを削除し、運用中システムを縮小する。ＳＬＡ情報２１４を過剰に満たす場合は、例えば、要求応答時間７０４が６秒の場合に、応答時間の平均が３秒の場合などで、計算機リソースが過剰に割り当てられている場合である。

なお、クライアントシステムの性能が、ＳＬＡ情報２１４を過剰に満たす場合とは、例えば、ＳＬＡ情報２１４で設定した性能条件の２倍以上など、所定の閾値を超えた性能を有する場合である。

図８は、運用中のＶＭごとのＶＭ性能情報２１６であり、図８において、ＶＭ ＩＤ８０１の場所がＴｏｋｙｏのＶＭ＃１〜ＶＭ＃３が図１のＷｅｂＡｐｐサーバ１１２−１〜１１２−３に相当し、図中ＶＭ＃４、ＶＭ＃５がクラウド・システム１０００の仮想計算機１１１２−１、１１１２−２に相当する。

全体統制部２０５は、応答時間８０３のうち応答時間が最も長いＶＭ＃５（１１１２−２）を選択する。次に、全体統制部２０５は、ロードバランサ１０６のリクエストを振り分ける機能の設定を変更し、ＶＭ＃５へのリクエストを徐々に減らす。そして、全体統制部２０５は、ＶＭ＃５へのリクエストの配信を完全に停止できるかを判定する。

なお、ＶＭ＃５へのリクエストを徐々に減らす手法としては、ロードバランサ１０６が、所定の周期（例えば、５秒）ごとに所定数ずつリクエストを減じて、最終的にリクエスト数を０にしてＶＭ＃５の負荷を開示すれば良い。

この判定は、全体統制部２０５が、ＷｅｂＡｐｐサーバとして機能しているＶＭ＃５（仮想計算機１１１２−２）へのリクエストを、他のＶＭで処理してもＳＬＡ情報２１４を満たすことができるか否かを判定する。

全体統制部２０５は、ＶＭ＃５へのリクエストを徐々に減らす過程で、運用中システムの応答時間を監視し、ＳＬＡ情報２１４を満足できない場合には、ＶＭを削除する試みを停止する。

全体統制部２０５は、ＶＭ＃５へのリクエストの配信を完全に停止するまでＳＬＡ情報２１４を満足する場合、クラウド基盤１００３のハイパバイザに対してＶＭ＃５を削除する指令を送信する。

全体統制部２０５は、続いて、ＶＭ＃４（ＷｅｂＡｐｐサーバ１１２−１）に対しても上記と同様にＶＭ＃４の削除を試みる。全体統制部２０５はＳＬＡ情報２１４を満足できなくなると、ＶＭ＃４の削除を中止して、現在運用中システムで最大限の性能が得られるリクエストの振り分けに戻す。

以上の処理によって、管理サーバ１０４は、運用中システム（クライアントシステム）の性能ログ２０９を参照して、ＳＬＡ情報２１４を上回る性能を付与している場合には、応答時間の最も長い（最も性能の低い）ＶＭを削除する。このとき、管理サーバ１０４は、削除対象のＶＭへ送信するリクエスト数を徐々に減らしながら運用中システム全体でＳＬＡ情報２１４を満足するかを監視する。管理サーバ１０４は、単位時間当たりのリクエスト数を所定数ずつ減じることで、リクエスト数を徐々に減らす。そして、管理サーバ１０４は、削除対象のＶＭへのリクエストを停止してもＳＬＡ情報２１４を満足していれば、当該ＶＭを削除し、当該ＶＭの計算機リソースをリソースプール１１８，１０１０に戻すことができる。

以上の処理により、運用中システムのＳＬＡ情報２１４を満足させながら計算機リソースの割り当て増大と、割り当ての削減を動的に行うことが出来る。

また、動的に変更する計算機リソースは、管理サーバ１０４が自動的に最適な量の計算機リソースを演算し、性能テストによってＳＬＡ情報２１４を保証する。これにより、クラウド・システム１００の計算機リソースの割り当てを効率よく自動化することが可能となる。

なお、本発明は上記した実施例に限定されるものではなく、様々な変形例が含まれる。例えば、上記した実施例は本発明を分かりやすく説明するために詳細に記載したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。また、ある実施例の構成の一部を他の実施例の構成に置き換えることが可能であり、また、ある実施例の構成に他の実施例の構成を加えることも可能である。また、各実施例の構成の一部について、他の構成の追加、削除、又は置換のいずれもが、単独で、又は組み合わせても適用可能である。

また、上記の各構成、機能、処理部、及び処理手段等は、それらの一部又は全部を、例えば集積回路で設計する等によりハードウェアで実現してもよい。また、上記の各構成、及び機能等は、プロセッサがそれぞれの機能を実現するプログラムを解釈し、実行することによりソフトウェアで実現してもよい。各機能を実現するプログラム、テーブル、ファイル等の情報は、メモリや、ハードディスク、ＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）等の記録装置、または、ＩＣカード、ＳＤカード、ＤＶＤ等の記録媒体に置くことができる。

また、制御線や情報線は説明上必要と考えられるものを示しており、製品上必ずしも全ての制御線や情報線を示しているとは限らない。実際には殆ど全ての構成が相互に接続されていると考えてもよい。

１ 物理計算機
２０ ハイパバイザ
１００ クラウド・システム
１０４ 管理サーバ
１０５ 管理データ
１０６ ロードバランサ
１１２−１〜１１２−３ ＷｅｂＡｐｐサーバ
１１５ データベース
１１８ リソースプール
２０９ 運用中システムの性能ログ
２１０ テストシステムの性能ログ
２１４ ＳＬＡ情報

Claims (15)

1. プロセッサとメモリを備えた物理計算機と、前記物理計算機の計算機リソースを仮想計算機に割り当てる仮想化部と、１以上の前記仮想計算機でサービスを提供する仮想計算機群を制御する管理計算機とを備えた計算機システムで、前記仮想計算機群を動的に変更する計算機リソースの割り当て方法であって、
   前記管理計算機が、前記サービスを提供する前記仮想計算機群の性能を取得する第１のステップと、
   前記管理計算機が、前記取得した前記仮想計算機群の性能と、予め設定された前記サービスの性能条件とを比較する第２のステップと、
   前記管理計算機が、前記比較結果に応じて、前記仮想計算機群で変更する計算機リソースを決定する第３のステップと、
   前記管理計算機が、前記変更の対象となる計算機リソースに応じた仮想計算機で前記サービスを試行して、当該仮想計算機の性能を測定する第４のステップと、
   前記管理計算機が、前記測定した性能が前記サービスの性能条件を満たすか否かを判定する第５のステップと、
   前記管理計算機が、前記測定した性能が前記サービスの性能条件を満たす場合には、前記変更を適用する第６のステップと、
   を含むことを特徴とする計算機リソースの割り当て方法。
2. 請求項１に記載の計算機リソースの割り当て方法であって、
   前記第３のステップは、
   前記比較結果が、前記仮想計算機群の性能が前記サービスの性能条件を満たしていないときには、前記仮想計算機群に追加する計算機リソースを決定し、
   前記第４のステップは、
   前記決定された計算機リソースに応じたテスト用の仮想計算機を生成するステップと、
   前記テスト用の仮想計算機で前記サービスを試行させるステップと、
   前記テスト用の仮想計算機の性能を測定するステップと、を含み、
   前記第６のステップは、
   前記測定したテスト用の仮想計算機の性能が前記サービスの性能条件を満たす場合には、前記テスト用の仮想計算機を前記仮想計算機群に追加することを特徴とする計算機リソースの割り当て方法。
3. 請求項１に記載の計算機リソースの割り当て方法であって、
   前記第３のステップは、
   前記比較結果が、前記仮想計算機群の性能が前記サービスの性能条件を満たしていないときには、前記仮想計算機群に追加する計算機リソースを決定し、
   前記第４のステップは、
   前記決定された計算機リソースに応じたテスト用の仮想計算機を複数生成するステップと、
   複数の前記テスト用の仮想計算機で前記サービスをそれぞれ試行させるステップと、
   前記テスト用の仮想計算機の性能をそれぞれ測定するステップと、を含み、
   前記第６のステップは、
   前記複数のテスト用の仮想計算機のうち前記測定した性能が前記サービスの性能条件を満たすテスト用の仮想計算機を選択し、前記仮想計算機群に追加することを特徴とする計算機リソースの割り当て方法。
4. 請求項３に記載の計算機リソースの割り当て方法であって、
   前記第４のステップは、
   前記決定された計算機リソースに応じたテスト用の仮想計算機を当該計算機システムと、他の計算機システムでそれぞれ生成することを特徴とする計算機リソースの割り当て方法。
5. 請求項１に記載の計算機リソースの割り当て方法であって、
   前記計算機システムは、前記仮想計算機群へリクエストを配信するロードバランサを含み、
   前記第４のステップは、
   前記管理計算機が前記ロードバランサに指令して、前記リクエストの複製を前記変更の対象となる計算機リソースに応じた仮想計算機に送信させ、当該リクエストに応じた処理を実行させることを特徴とする計算機リソースの割り当て方法。
6. 請求項１に記載の計算機リソースの割り当て方法であって、
   前記計算機システムは、前記仮想計算機群へリクエストを配信するロードバランサを含み、
   前記第４のステップは、
   前記管理計算機が前記ロードバランサから前記リクエストを取得して蓄積し、前記蓄積したリクエストを、変更の対象となる計算機リソースに応じた仮想計算機に送信し、当該リクエストに応じた処理を実行させることを特徴とする計算機リソースの割り当て方法。
7. 請求項１に記載の計算機リソースの割り当て方法であって、
   前記計算機システムは、前記サービスで使用するデータベースを含み、
   前記第４のステップは、
   前記データベースのスナップショットを生成するステップと、
   前記変更の対象となる計算機リソースに応じた仮想計算機で前記スナップショットを用いて前記サービスを試行して、当該仮想計算機の性能を測定するステップと、を含むことを特徴とする計算機リソースの割り当て方法。
8. 請求項１に記載の計算機リソースの割り当て方法であって、
   前記計算機システムは、前記サービスで使用するデータベースと、当該データベースのレプリカとを含み、
   前記第４のステップは、
   前記レプリカのスナップショットを生成するステップと、
   前記変更の対象となる計算機リソースに応じた仮想計算機で前記スナップショットを用いて前記サービスを試行して、当該仮想計算機の性能を測定するステップと、を含むことを特徴とする計算機リソースの割り当て方法。
9. 請求項１に記載の計算機リソースの割り当て方法であって、
   前記第３のステップは、
   前記比較結果が、前記仮想計算機群の性能が前記サービスの性能条件よりも所定の閾値を超えたきには、前記仮想計算機群から削除する計算機リソースを決定し、
   前記第４のステップは、
   前記決定された計算機リソースに応じた仮想計算機の負荷を漸次解除して前記サービスを試行させるステップと、
   前記仮想計算機群の性能を測定するステップと、を含み、
   前記第６のステップは、
   前記仮想計算機群の性能が前記サービスの性能条件を満たす場合には、前記仮想計算機を前記仮想計算機群から削除することを特徴とする計算機リソースの割り当て方法。
10. プロセッサとメモリを備えた物理計算機と、
    前記物理計算機の計算機リソースを仮想計算機に割り当てる仮想化部と、
    １以上の前記仮想計算機でサービスを提供する仮想計算機群を制御する管理計算機と、を備えた計算機システムであって、
    前記管理計算機は、
    前記サービスを提供する前記仮想計算機群の性能を取得して、前記取得した前記仮想計算機群の性能と、予め設定された前記サービスの性能条件とを比較し、当該比較結果に応じて、前記仮想計算機群で変更する計算機リソースを決定する制御部と、
    前記変更の対象となる計算機リソースに応じた仮想計算機で前記サービスを試行して、当該仮想計算機の性能を測定する性能測定部と、を有し、
    前記制御部は、
    前記測定した性能が前記サービスの性能条件を満たす場合には、前記変更を適用することを特徴とする計算機システム。
11. 請求項１０に記載の計算機システムであって、
    前記制御部は、
    前記比較結果が、前記仮想計算機群の性能が前記サービスの性能条件を満たしていないときには、前記仮想計算機群に追加する計算機リソースを決定し、前記決定された計算機リソースに応じたテスト用の仮想計算機を生成し、
    前記性能測定部は、
    前記テスト用の仮想計算機で前記サービスを試行させて、前記テスト用の仮想計算機の性能を測定し、
    さらに、前記制御部は、
    前記測定したテスト用の仮想計算機の性能が前記サービスの性能条件を満たす場合には、前記テスト用の仮想計算機を前記仮想計算機群に追加することを特徴とする計算機システム。
12. 請求項１０に記載の計算機システムであって、
    前記制御部は、
    前記比較結果が、前記仮想計算機群の性能が前記サービスの性能条件を満たしていないときには、前記仮想計算機群に追加する計算機リソースを決定し、前記決定された計算機リソースに応じたテスト用の仮想計算機を複数生成し、
    前記性能測定部は、
    複数の前記テスト用の仮想計算機で前記サービスをそれぞれ試行させて、前記テスト用の仮想計算機の性能をそれぞれ測定し、
    さらに、前記制御部は、
    前記複数のテスト用の仮想計算機のうち前記測定した性能が前記サービスの性能条件を満たすテスト用の仮想計算機を選択し、前記仮想計算機群に追加することを特徴とする計算機システム。
13. 請求項１２に記載の計算機システムであって、
    前記制御部は、
    前記決定された計算機リソースに応じたテスト用の仮想計算機を当該計算機システムと、他の計算機システムでそれぞれ生成することを特徴とする計算機システム。
14. 請求項１０に記載の計算機システムであって、
    前記計算機システムは、前記仮想計算機群へリクエストを配信するロードバランサをさらに含み、
    前記制御部は、
    前記ロードバランサに指令して、前記リクエストの複製を前記変更の対象となる計算機リソースに応じた仮想計算機に送信させ、当該リクエストに応じた処理を実行させることを特徴とする計算機システム。
15. 請求項１０に記載の計算機システムであって、
    前記計算機システムは、前記仮想計算機群へリクエストを配信するロードバランサをさらに含み、
    前記制御部は、
    前記ロードバランサから前記リクエストを取得して蓄積し、前記蓄積したリクエストを、変更の対象となる計算機リソースに応じた仮想計算機に送信し、当該リクエストに応じた処理を実行させることを特徴とする計算機システム。

Images