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

Abstract

【課題】Ｗｅｂサーバのスケールアウトに追従したＤＢサーバのスケールアップによって、テナントの性能を向上させる。【解決手段】複数の計算機を備える計算機システムであって、複数の計算機は、第１の計算機、業務システムに計算機リソースを提供する複数の第２の計算機を含み、業務システムは、スケールアウトによって処理性能を変更できる第１の業務計算機、及びスケールアップによって処理性能を変更できる第２の業務計算機を含み、第１の計算機はリソース最適化部を有し、リソース最適化部は、実行系の第２の業務計算機の負荷の増大の予兆を検出した場合、実行系の第２の業務計算機及び待機系の第２の業務計算機に処理負荷が低いリソース変更方法を適用し、実行系の第２の業務計算機の負荷を示す値が所定の閾値以上になった場合、実行系の第２の業務計算機及び待機系の第２の業務計算機に処理負荷が高いリソース変更方法を適用する。【選択図】図１５

Description

本発明はクラウドサービス、特にクラウドサービス上で提供されるＩＴサービス又はＩＴシステムの性能保証に関する。

近年、クラウドサービスと呼ばれる、インターネット等のネットワークを介して、計算機リソース又は計算機リソースを用いて動作するソフトウェアによるサービスを事業者が提供し、利用形態に応じて利用者に課金するサービスが普及している。

クラウドサービスをサービス提供形態の観点での分類した場合、ＩａａＳ（Ｉｎｆｒａｓｔｒｕｃｔｕｒｅ ａｓ ａ Ｓｅｒｖｉｃｅ）、ＳａａＳ（Ｓｏｆｔｗａｒｅ ａｓ ａ Ｓｅｒｖｉｃｅ）、及びＰａＳＳ（Ｐｌａｔｆｏｒｍ ａｓ ａ Ｓｅｒｖｉｃｅ）等がある。

ＩａａＳは、計算機リソースそのものを提供するクラウドサービスである。ＳａａＳは、主にＷｅｂブラウザからアクセス可能な方法でメール及び顧客管理等の機能をソフトウェアとして提供するクラウドサービスである。ＰａＳＳは、ＩａａＳ及びＳａａＳの中間に位置するものであり、ＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）及びデータベース（以下、ＤＢと記載する）等のミドルウェアを含めたソフトウェア開発の基盤を提供するクラウドサービスである。

クラウドサービスでは多くの場合、ＩａａＳで提供される計算機リソース、又はＰａＳＳ若しくはＳａａＳの基盤となる計算機リソースは、サーバ仮想化技術とよばれる仮想化技術が一般的に利用されている。サーバ仮想化技術では、物理サーバのＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）及びメモリ等の計算機リソースを論理的に分割し、仮想サーバ（ＶＭ）という単位で利用する。

仮想化された計算機リソースを活用するために、ＶＭを負荷状況等に応じて自動的又は手動でスケーリングを行う機能を提供するクラウドサービスが知られている。例えば、ＣＰＵ等の負荷が監視され、負荷が閾値を超えた場合、処理を分散するために処理を実行するＶＭが追加されるスケールアウト技術を提供するクラウドサービスが知られている。これによって、計算機リソースの柔軟な利用とＶＭの性能向上が可能となる。

さらに、近年では、１つのクラウドサービスで処理が完結しない場合に、他の複数のクラウドサービスをつなぎ合わせ、一つの大きなサービスを構築する、といった構成も一般的となりつつある。

特開２０１２−９９０６２号公報

特許文献１には、「中間サービスを実行するクラウドは、出力レート予測部によって、前段サービスの出力予測とクラウド管理サーバ４０１からの情報収集応答４０４等を受け、出力レートを予測し、後段サービスに予測を出力する。スケーリング制御部は、前段サービスの出力予測４０７と情報収集応答４０５を受け、中間サービスに割り当てる資源を決定し、スケーリング要求をクラウド管理サーバと出力レート予測部に出力する。」ことが記載されている。

特許文献１によれば、連結したサービス１とサービス２において、フロントエンド側となるサービス１のスケール又はリクエストの増加を検出し、バックエンド側となるサービス２をスケールアウト（ＶＭの追加）することができる。

一方で、特許文献１で開示される技術は、スケールアウトできる、すなわち、ＶＭを追加することによって処理性能の向上が可能な構成要素の連携を対象とする。そのため、スケールアウトできない構成要素を含むシステムには適用できない。

例えば、１つ以上のＷｅｂサーバと、１つ以上のアプリケーションサーバと、データベース処理を行う１つのＤＢサーバからなるＷｅｂ三階層システムにおいて、Ｗｅｂサーバには特許文献１の技術を用いることによって自動スケーリングが可能である。しかし、ＤＢサーバは、データの一貫性等の理由から複数に分割することはできない。そのため、ＤＢサーバの追加処理等によるスケールアウトによって、性能を向上させることができない。したがって、前述のような制約があるＷｅｂ三階層システムでは、システム全体として自動スケーリングが実現できず、性能を向上できないという課題がある。

ＤＢサーバの性能を向上させる別の方法として、ＤＢサーバに対するＣＰＵ及びメモリ等の計算機リソースを増強することによって、性能向上を実現することはできる。しかし、この方法では、計算機リソースの変更に伴うＤＢサーバの再起動が発生してしまう。そのため、計算機リソースの変更からＤＢサーバの再起動までの時間が長時間となるため、比較的短時間で行われるＷｅｂサーバのスケールアウトに追従できない。

その結果、例えば、通信販売のサービスを実行するＷｅｂ三階層システムでは、当該サービスの利用者の急増に対して柔軟な対応ができず、システムダウン又は負荷集中に伴うリクエスト拒否（Ｓｏｒｒｙページの表示）が発生することによって、機会損失が発生する。

また、ＤＢサーバの性能を向上させる別の方法として、予め、潤沢な計算機リソースを用いてＷｅｂ三階層システム等の業務システムを構築することが考えられる。しかし、通信販売等を行う事業者のコストが増大するという課題がある。

本願において開示される発明の代表的な一例を示せば以下の通りである。すなわち、複数の計算機を備える計算機システムであって、前記複数の計算機は、前記計算機システムを管理する少なくとも一つの第１の計算機、ユーザの業務に使用する業務システムを構築するための計算機リソースを提供する複数の第２の計算機を含み、前記第１の計算機は、第１のプロセッサ、前記第１のプロセッサに接続される第１のメモリ、及び前記第１のプロセッサに接続される第１のインタフェースを有し、前記複数の第２の計算機の各々は、第２のプロセッサ、前記第２のプロセッサに接続される第２のメモリ、前記第２のプロセッサに接続される第２のインタフェース、及び記憶装置を有し、前記業務システムは、スケールアウト処理を実行することによって処理性能を変更できる少なくとも一つの第１の業務計算機、及びスケールアップ処理を実行することによって処理性能を変更できる複数の第２の業務計算機を含み、前記複数の第２の業務計算機は、実行系の第２の業務計算機及び待機系の第２の業務計算機を含むクラスタを構成し、前記第１の計算機は、第２の業務計算機に対する前記計算機リソースの割り当ての変更を制御するための複数のリソース変更方法を管理し、前記複数のリソース変更方法に基づいて前記第２の業務計算機に対する前記計算機リソースの割当てを変更するリソース最適化部を有し、前記リソース最適化部は、前記業務システムの負荷を監視し、前記実行系の第２の業務計算機の負荷の増大の予兆を検出した場合、前記実行系の第２の業務計算機及び前記待機系の第２の業務計算機に処理負荷が低いリソース変更方法を適用する第１の処理を実行し、前記実行系の第２の業務計算機の負荷を示す値が所定の閾値以上になった場合、前記実行系の第２の業務計算機及び前記待機系の第２の業務計算機に処理負荷が高いリソース変更方法を適用する第２の処理を実行する。

本発明によれば、スケールアウト処理では対応できない構成を含む業務システムであっても、業務システムにおける業務に与える影響を最小限にし、かつ、コストを抑えつつ、業務システムの自動スケーリングが可能となる。

上記した以外の課題、構成及び効果は、以下の実施例の説明により明らかにされる。

実施例１の概要を示す説明図である。 実施例１のクラウドサービスの一例を示す説明図である。 実施例１のクラウドサービスを提供する計算機システムの構成例を示す説明図である。 実施例１の管理サーバのハードウェア構成の一例を示す説明図である。 実施例１のストレージ装置の構成の一例を示す説明図である。 実施例１の物理サーバ管理情報の一例を示す説明図である。 実施例１のストレージ装置管理情報の一例を示す説明図である。 実施例１の論理物理構成管理情報の一例を示す説明図である。 実施例１のテナント管理情報の一例を示す説明図である。 実施例１の性能管理情報の一例を示す説明図である。 実施例１のシステムテンプレート管理情報の一例を示す説明図である。 実施例１の顧客管理情報の一例を示す説明図である。 実施例１のスケール管理情報の一例を示す説明図である。 実施例１のリソース変更方法管理情報の一例を示す説明図である。 実施例１のリソース最適化プログラムが実行する処理の概要を説明するフローチャートである。 実施例１のリソース最適化プログラムがステップＳ３２００において実行するＤＢサーバのスケールアップ処理の詳細を説明するフローチャートである。 実施例１のリソース最適化プログラムがステップＳ３２００において実行するＤＢサーバのスケールアップ処理の詳細を説明するフローチャートである。 実施例１のリソース最適化プログラムが実行するＶＭの再配置処理を説明するフローチャートである。 実施例１のリソース最適化プログラムが実行するテイクオーバ処理を含むＤＢサーバのスケールアップ処理の詳細を説明するフローチャートである。 実施例１のリソース最適化プログラムが実行するスケールアップされたＤＢサーバに対するスケールダウン処理の詳細を説明するフローチャートである。 実施例１のサービス申込時に用いられる画面の一例を示す説明図である。 実施例１のテナントの状態を確認するために表示される画面の一例を示す説明図である。

以下、図面を用いて実施例について説明する。

図１は、実施例１の概要を示す説明図である。

実施例１では、２つのＷｅｂサーバ１４２０、及び２つのＤＢサーバ１４３０から構成されるテナント（業務システム）１４００を考える。初期のテナント１４００は、状態４１００に示す状態であるものとする。

テナント１４００は、図２に示すようなクラウドサービス１２００を提供する計算機システムが各利用者１１００に提供する計算機リソース空間である。したがって、Ｗｅｂサーバ１４２０及びＤＢサーバ１４３０は、仮想化技術を用いて実現される。

状態４１００のテナント１４００では、２つのＤＢサーバ１４３０が、ＨＡ（Ｈｉｇｈ Ａｖａｉｌａｂｉｌｉｔｙ、サーバ冗長化構成）を組む。ここでは、ＨＡ構成の２つのＤＢサーバ１４３０のうち、ＤＢサーバ１（１４３０）が正側（現用系）のＤＢサーバとして稼働し、ＤＢサーバ２（１４３０）が副側（待機系）のＤＢサーバとして稼働する。

テナント１４００の利用時にＤＢサーバ１４３０の負荷増大を示す予兆が検出された場合、管理サーバ１００（図３参照）は、後述する処理を実行して、テナント１４００の状態を状態４１００から状態４２００へ遷移させる。例えば、管理サーバ１００は、フロントエンド側の負荷の増大に伴うＷｅｂサーバ１４２０のスケールアウトが行われた場合、テナント１４００の状態を状態４１００から状態４２００へ遷移させる。

状態４２００では、Ｗｅｂサーバ３（１４２０）を追加することによって、Ｗｅｂサーバ１４２０のスケールアウトが行われ、また、ＤＢサーバ１４３０についてもスケールアップが行われる。管理サーバ１００は、ＤＢサーバ１４３０のスケールアップの方法として、正側のＤＢサーバ１（１４３０）にはＤＢサーバの停止を伴わないスケールアップの方法（無停止の変更方法）を適用し、副側のＤＢサーバ２（１４３０）にはＤＢサーバの停止を伴うスケールアップの方法（停止の変更方法）を適用する。正側のＤＢサーバ１（１４３０）に前述したようなスケールアップの方法を適用することによってＤＢサーバ１（１４３０）が稼働したまま性能を向上させることができる。

このとき、管理サーバ１００は、正側のＤＢサーバ１（１４３０）の負荷の増大に対応するため、正側のＤＢサーバ１（１４３０）より性能が高くなるように副側のＤＢサーバ２（１４３０）のスケールアップを行う。

状態４２００へ遷移した後にＤＢサーバ１（１４３０）の負荷が増大した場合、管理サーバ１００は、後述する処理を実行して、テナント１４００の状態を状態４２００から状態４３００に遷移させる。例えば、管理サーバ１００は、スケールアップしたＤＢサーバ１（１４３０）に割り当てられた計算機リソースの使用率が所定の閾値以上になった場合、又はＤＢサーバ１（１４３０）に性能障害が発生した場合に、テナント１４００の状態を状態４２００から状態４３００に遷移させる。

状態４３００では、管理サーバ１００は、テイクオーバ処理等を実行することによって、ＤＢサーバ１（１４３０）から、状態４２００に遷移する場合に最適なスケールアップが行われたＤＢサーバ２（１４３０）へ切り替える。これによって、ＤＢサーバ１（１４３０）より性能が高いＤＢサーバ２（１４３０）が処理を継続できる。

また、状態４３００では、管理サーバ１００は、ＤＢサーバ１（１４３０）からＤＢサーバ２（１４３０）へ切り替えた後、状態４２００において変更されたＤＢサーバ１（１４３０）の計算機リソースの設定を元に戻すために、スケールダウンを行う。すなわち、ＤＢサーバ１（１４３０）に追加等された計算機リソースの設定が初期化される。ＤＢサーバ１（１４３０）に対する計算機リソースの割当を元に戻すことによって、クラウドサービス１２００を提供する計算機システムの計算機リソースを有効に活用できる。

状態４２００又は状態４３００の状態において、ＤＢサーバ１４３０の負荷が減少した場合、管理サーバ１００は、後述する処理を実行して、テナント１４００の状態を状態４２００又は状態４３００から状態４４００へ遷移させる。

例えば、管理サーバ１００は、フロントエンド側の負荷の減少に伴うＷｅｂサーバ１４２０のスケールインが行われた場合、テナント１４００の状態を状態４２００又は状態４３００から状態４４００へ遷移させる。図１では、Ｗｅｂサーバ３（１４２０）をテナント１４００から削除するスケールインが行われる。このとき、管理サーバ１００は、ＤＢサーバ１（１４３０）及びＤＢサーバ２（１４３０）のそれぞれに対して、スケールアップにおいて変更された計算機リソースの設定を元に戻すために、スケールダウンを行う。

状態４２００から状態４４００に遷移する場合、管理サーバ１００は、ＤＢサーバ１（１４３０）及びＤＢサーバ２（１４３０）のそれぞれの計算機リソースの設定を元の状態に戻す。また、状態４３００から状態４４００に遷移する場合、管理サーバ１００は、ＤＢサーバ１（１４３０）の計算機リソースの設定は初期化されているため、ＤＢサーバ２（１４３０）の計算機リソースの設定を元の状態に戻す。

実施例１では、管理サーバ１００が前述したような一連の処理を実行することによって、状態４４００から状態４１００に遷移することとなる。すなわち、実施例１では、テナント１４００の負荷に応じて、テナント１４００の状態が状態４１００、４２００、４３００、４４００の間を循環する。

図２は、実施例１のクラウドサービスの一例を示す説明図である。

利用者１１００の視点で、クラウドサービス１２００の利用、及びクラウドサービス１２００内での処理を説明する。クラウドサービス１２００を提供する計算機システムの具体的な挙動については後述する。

クラウドサービス１２００は、ポータル２０００及び複数のテナント１４００を含む。

ポータル２０００は、利用者１１００がクラウドサービス１２００のサービスの申込み及びテナント１４００の管理を行うための管理インタフェースである。利用者１１００は、ポータル２０００を用いて利用するサービスの申込、及びテナント１４００の管理等を行う。

実施例１では、利用者１１００は、ポータル２０００を介してテナント１４００の管理等を行うものとするが、他の方法を用いてサービスの申込み及びテナント１４００の管理を行ってもよい。例えば、メール又は紙媒体を用いた方式を用いることが考えられる。この場合、クラウドサービス１２００は、ポータル２０００を含まなくてもよい。

クラウドサービス１２００では、利用者１１００からサービスの申込を受けつけた場合、利用者１１００専用の計算機リソース空間として割り当てられるテナント１４００に、サービスに対応した計算機リソースが用意される。なお、申し込んだサービスに応じて、一人の利用者１１００に１つ又は複数のテナント１４００が提供される。

ＩａａＳ又はＰａＳＳのクラウドサービス１２００において、利用者１１００がＷｅｂ三階層システムを申し込んだ場合、ロードバランサ（ＬＢ）１４１０、Ｗｅｂ機能を有するＷｅｂサーバ１４２０、ＤＢ機能を有するＤＢサーバ１４３０、及び記憶領域を提供するストレージ装置１４４０を含むテナント１４００が構築される。ＳａａＳのクラウドサービス１２００においてメールサービスが申し込まれた場合、Ｗｅｂ三階層システムを実現するテナント１４００に含まれるソフトウェアによってメールサービスが提供される。

クラウドサービス１２００では、テナント１４００の構築が完了した後、ポータル２０００を介して利用者１１００にその旨が通知される。その後、利用者１１００は、ポータル２０００又はその他の方法を用いて、テナント１４００を管理する。

テナント１４００は、利用者１１００に対する課金の単位でもあり、クラウドサービス１２００では、サービスの申込み時に合意した課金体系に基づいて利用金額が周期的に算出され、ポータル２０００等を用いて利用者１１００に利用金額が請求される。利用者１１００は、利用金額の請求を受け取った場合、ポータル２０００又はポータル２０００を介して指定された精算方法を用いて、利用金額を支払う。

なお課金体系としては、月額固定の利用金額を支払うもの、ＶＭのスペック及び記憶領域の利用量等に応じて算出される従量に基づいた利用金額を支払うものが考えられる。

実施例１のクラウドサービス１２００は、マルチテナントに対応しているものとする。マルチテナントでは、複数の利用者の各々に一つ以上のテナント１４００が提供される。マルチテナントに対応したクラウドサービス１２００では、当該サービスを提供する事業者が、利用者１１００が要求するＳＡＬ（Ｓｅｒｖｉｃｅ Ｌｅｖｅｌ Ａｇｒｅｅｍｅｎｔ）を満たすように計算機リソースを管理することが重要となる。本発明は、前述した課題の解決を主目的の一つとする。

図３は、実施例１のクラウドサービス１２００を提供する計算機システムの構成例を示す説明図である。

クラウドサービス１２００を提供する計算機システムは、管理サーバ１００、複数の物理サーバ１５０及びストレージ装置２００から構成される。管理サーバ１００、複数の物理サーバ１５０及びストレージ装置２００は、ネットワーク３００を介して互いに接続される。

ネットワーク３００は、例えば、Ｅｔｈｅｒｎｅｔ（Ｅｔｈｅｒｎｅｔは登録商標、以下同じ）等が考えられる。また、ネットワーク３００は、物理サーバ１５０とストレージ装置２００との間がＳＡＮを介して接続される場合、ＳＡＮ及びＥｔｈｅｒｎｅｔの両方を含んでいてもよいし、インターネットでもよい。

また、ネットワーク３００は、管理サーバ１００が物理サーバ１５０及びストレージ装置２００を制御するために通信する管理用のネットワークと、物理サーバ１５０及びストレージ装置２００が互いに通信するための業務用ネットワークとを含んでもよい。

また、ネットワーク３００は、各利用者１１００にテナント１４００を提供し、また、管理用の通信と利用者１１００の通信とを分離するために、１つのネットワークを論理的に分割する仮想ネットワーク（Ｖｉｒｔｕａｌ Ｎｅｔｗｏｒｋ、ＶＬＡＮとも呼ばれる）技術に対応したものでもよい。クラウドサービス１２００を提供する事業者は、利用者１１００がサービスを申込み時等に仮想ネットワークを設定し、論理的に分割されたネットワーク及び当該ネットワークを介して接続されるＶＭ４１０を用いて、独立した業務システムとしてテナント１４００を提供する。

物理サーバ１５０は、利用者１１００のテナント１４００に計算機リソースを提供する計算機である。物理サーバ１５０上では、ハイパバイザ４００が稼働する。ハイパバイザ４００は、物理サーバ１５０が有するＣＰＵ及びメモリ等の計算機リソースを論理的に分割し、複数のＶＭ４１０に割り当てる。ハイパバイザ４００上では、物理サーバ１５０の計算機リソースが割り当てられた一つ以上のＶＭ４１０が動作する。

実施例１では、仮想化技術に対応した物理サーバ１５０を前提として説明するが、仮想化技術に対応した物理サーバ１５０でなくてもよい。この場合、後述するリソース変更方法管理情報Ｔ８００には、物理サーバ１５０そのものに適用できる変更方法が格納される。

ストレージ装置２００は、物理サーバ１５０上で稼働するＶＭ４１０が使用する記憶領域としてボリューム２１０を提供する計算機である。ボリューム２１０には、ハイパバイザ４００を実現するプログラム、ハイパバイザ４００が稼働するための情報、ＶＭ４１０の構成情報、ＶＭ４１０上で実行されるＯＳ及びユーザデータ等が格納される。

ボリューム２１０とＶＭ４１０との対応関係については、１つのボリューム２１０に１つのＶＭ４１０を割り当ててもよいし、１つのボリューム２１０を複数のＶＭ４１０に割り当ててもよいし、複数のボリューム２１０を１つのＶＭ４１０に割り当ててもよい。

図３では、ストレージ装置２００は、ＤＢサーバ１４３０のＨＡ構成を実現する上で一般的なＳＡＮ（Ｓｔｏｒａｇｅ Ａｒｅａ Ｎｅｔｗｏｒｋ）又はＮＡＳ（Ｎｅｔｗｏｒｋ Ａｔｔａｃｈｅｄ Ｓｔｏｒａｇｅ）によって接続された外部ストレージ装置として記載しているがこれに限定されない。例えば、物理サーバ１５０がストレージ装置２００を含んでもよいし、また、物理サーバ１５０が有するＨＤＤ等の記憶装置を用いてもよい。

管理サーバ１００は、クラウドサービス１２００を提供する計算機システム全体を管理する計算機である。管理サーバ１００は、各種制御を行うためのプログラム及び各種情報を保持する。なお、図３では、管理サーバ１００は、一つの物理的な計算機として記載しているが、一つ又は複数のＶＭ４１０を用いて実現してもよい。また、複数の物理サーバ１５０にプログラム及び情報を分散して配置することによって、管理サーバ１００が有する機能を実現してもよい。

ここで、管理サーバ１００が保持するプログラム及び情報について説明する。

管理サーバ１００は、ポータルプログラム２１００、構成／性能管理プログラム２２００、構成変更プログラム２３００、課金プログラム、顧客管理プログラム２５００、及びリソース最適化プログラム３０００を保持する。また、管理サーバ１００は、物理サーバ管理情報Ｔ１００、ストレージ管理情報Ｔ２００、論理物理構成管理情報Ｔ３００、テナント管理情報Ｔ４００、性能管理情報Ｔ５００、顧客管理情報Ｔ６００、スケール管理情報Ｔ７００、リソース変更方法管理情報Ｔ８００、及びシステムテンプレート管理情報Ｔ９００を保持する。

物理サーバ管理情報Ｔ１００は、物理サーバ１５０の構成を管理するための情報である。物理サーバ管理情報Ｔ１００の詳細は、図６を用いて後述する。ストレージ管理情報Ｔ２００は、ストレージ装置２００によって提供されるボリューム２１０を管理するための情報である。ストレージ管理情報Ｔ２００の詳細は、図７を用いて後述する。論理物理構成管理情報Ｔ３００は、計算機システムに含まれるＶＭ４１０の構成及びＶＭ４１０の物理的な配置を管理するための情報である。論理物理構成管理情報Ｔ３００の詳細は、図８を用いて後述する。

テナント管理情報Ｔ４００は、計算機システムに構築されたテナント１４００の構成を管理するための情報である。テナント管理情報Ｔ４００の詳細は、図９を用いて後述する。性能管理情報Ｔ５００は、テナント１４００の性能を管理するための情報である。性能管理情報Ｔ５００の詳細は、図１０を用いて後述する。

顧客管理情報Ｔ６００は、各利用者１１００に提供されるテナント１４００の契約形態等を管理するための情報である。顧客管理情報Ｔ６００の詳細は、図１２を用いて後述する。スケール管理情報Ｔ７００は、業務システムを構成するＶＭの計算機リソースの構成を管理するための情報である。スケール管理情報Ｔ７００の詳細は、図１３を用いて後述する。

リソース変更方法管理情報Ｔ８００は、計算機リソースの変更方法を管理するための情報である。ここで、計算機リソースの変更方法とは、ＶＭ４１０等に対する計算機リソースの割り当ての変更を制御する方法である。リソース変更方法管理情報Ｔ８００の詳細は、図１４を用いて後述する。システムテンプレート管理情報Ｔ９００は、業務システムの詳細な構成を管理するための情報である。システムテンプレート管理情報Ｔ９００の詳細は、図１１を用いて後述する。

ポータルプログラム２１００は、利用者１１００に提供するポータル２０００を実現するためのプログラムである。具体的には、ポータルプログラム２１００は、利用者１１００に対してサービスの申込みに必要な情報、及びその他の情報を提示する画面等を表示する。また、ポータルプログラム２１００は、利用者１１００から入力された情報を他のプログラムに通知し、処理を依頼する。

構成／性能管理プログラム２２００は、物理サーバ１５０、ハイパバイザ４００、ＶＭ４１０、ネットワーク３００、ストレージ装置２００、及びボリューム２１０の構成情報及び性能情報を管理するためのプログラムである。構成／性能管理プログラム２２００は、物理サーバ１５０及びストレージ装置２００等から各種情報を取得し、管理情報として管理する。具体的には、構成／性能管理プログラム２２００は、物理サーバ管理情報Ｔ１００、ストレージ管理情報Ｔ２００、論理物理構成管理情報Ｔ３００、テナント管理情報Ｔ４００、性能管理情報Ｔ５００を管理する。

構成変更プログラム２３００は、ポータルプログラム２１００又はリソース最適化プログラム３０００からの指示にしたがって、計算機システムにおける計算機リソースの構成変更処理を実行するプログラムである。構成変更プログラム２３００は、処理結果に基づいて、各種情報を更新し、又は、各プログラムに各種情報の更新を指示する。

また、構成変更プログラム２３００は、変更処理を実行するための機能を保持する。例えば、構成変更プログラム２３００は、ＶＭ４１０のＣＰＵ数を変更する旨の指示等を受信した場合、当該プログラム内部に保持される、当該指示を実行するためのコマンド及びサブプログラムを呼び出し、ＶＭ４１０又はハイパバイザ４００に対して構成を変更するための処理を実行する。

また、構成変更プログラム２３００は、システムテンプレート管理情報Ｔ９００を管理する。構成変更プログラム２３００は、システムテンプレート管理情報Ｔ９００を用いて、指定された業務システムを実現するテナント１４００を構築する。例えば、業務システムとしてＷｅｂ三階層システムが指定された場合、構成変更プログラム２３００は、システムテンプレート管理情報Ｔ９００の当該Ｗｅｂ三階層システムに対応するレコードを参照し、業務システムを構築するための処理を実行する。なお、システムテンプレート管理情報Ｔ９００を用いた業務システムの構築処理は例えば特許文献１に記載されたものを用いればよい。

課金プログラム２４００は、構成／性能管理プログラム２２００からの指示にしたがって、各種管理情報に基づいて各利用者１１００の利用金額を算出し、ポータルプログラム２１００等を介して利用者に利用金額を請求する。

顧客管理プログラム２５００は、利用者１１００の契約情報等を管理する。具体的には、顧客管理プログラム２５００は、顧客管理情報Ｔ６００を管理する。例えば、顧客管理プログラム２５００は、ポータルプログラム２１００等から受け付けた利用者１１００の識別子、テナント１４００の識別子、及びテナントの契約形態等を対応付けて顧客管理情報Ｔ６００に格納し、また、他のプログラムから利用者１１００の契約情報に関する問合せを受信した場合、顧客管理情報Ｔ６００を参照して問い合わせに対して回答を行う。

リソース最適化プログラム３０００は、構成／性能管理プログラム２２００等と連携して、スケールアップ処理等のテナント１４００に割り当てる計算機リソースを制御する。リソース最適化プログラム３０００が実行する処理の詳細については後述する。また、リソース最適化プログラム３０００は、スケール管理情報Ｔ７００及びリソース変更方法管理情報Ｔ８００を管理する。

なお、各管理情報は、個別の情報として管理されているが、例えば、共通の記憶領域（データベース）に全ての管理情報を格納し、各プログラムが当該データベースに問い合わせる構成等でもよい。

図４は、実施例１の管理サーバ１００のハードウェア構成の一例を示す説明図である。なお、物理サーバ１５０も管理サーバ１００と同一のハードウェア構成であるものとする。

管理サーバ１００は、ＣＰＵ１０１、メモリ１０２、ＨＤＤ１０３、ネットワークインタフェース１０４、ディスクインタフェース１０５、及び入出力インタフェース１０６を有する。管理サーバ１００が有する各構成は、内部バス１０７で互いに接続される。管理サーバ１００が有する各構成は、内部バス１０７を介して互いに通信する。

ＣＰＵ１０１は、メモリ１０２に格納されるプログラムを実行する。ＣＰＵ１０１は、演算処理を実行する複数のコアを有する。ＣＰＵ１０１がプログラムを実行することによって、管理サーバ１００が有する機能を実現できる。なお、プログラムを主体にして処理を説明する場合、ＣＰＵ１０１によってプログラムが実行されていることを表す。

メモリ１０２は、ＣＰＵ１０１によって実行されるプログラム及び当該プログラムを実行するために必要な情報を格納する。また、メモリ１０２は、プログラムが使用するワークエリアを提供する記憶領域を含む。

管理サーバ１００のメモリ１０２には、図３に示すようなプログラム群及び情報群が格納される。また、物理サーバ１５０のメモリ１０２には、ハイパバイザ４００を実現するプログラム、及びＶＭ４１０上で稼働するＯＳを実現するプログラム等が格納される。

ＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）１０３は、各種データ及び各種情報を格納する。なお、管理サーバ１００は、ＨＤＤ１０３以外にＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）等のその他の記憶媒体を有してもよい。なお、メモリ１０２に格納されるプログラム及び情報は、ＨＤＤ１０３に格納されてもよい。この場合、ＣＰＵ１０１がＨＤＤ１０３からプログラム及び情報を読み出し、メモリ１０２にロードする。

ネットワークインタフェース１０４は、ネットワーク３００等を介して外部装置と接続するためのインタフェースである。ネットワークインタフェース１０４は、例えば、ＮＩＣＥ（Ｎｅｔｗｏｒｋ Ｉｎｔｅｒｆａｃｅ Ｃａｒｄ）が考えられる。

ディスクインタフェース１０５は、ＨＤＤ１０３又は外部記憶装置と接続するためのインタフェースである。ディスクインタフェース１０５は、例えば、ＨＢＡ（Ｈｏｓｔ Ｂｕｓ Ａｄａｐｔｅｒ）が考えられる。

入出力インタフェース１０６は、管理サーバ１００に各種データを入力し、また、各種データを出力するためのインタフェースである。入出力インタフェース１０６は、キーボード、マウス、タッチパネル、及びディスプレイ等を含む。なお、管理サーバ１００は、入出力インタフェース１０６を有しなくてもよい。この場合、例えば、ＳＳＨ（Ｓｅｃｕｒｅ Ｓｈｅｌｌ）等を用いてネットワーク経由で管理サーバ１００に対する入出力を行う方法が考えられる。

図５は、実施例１のストレージ装置２００の構成の一例を示す説明図である。

ストレージ装置２００は、管理インタフェース２０１、外部インタフェース２０２、コントローラユニット２２０、記憶ユニット２３０、及びディスクインタフェース２４０を有する。

管理インタフェース２０１は、管理用ネットワークを介して管理サーバ１００と接続するためのインタフェースである。外部インタフェース２０２は、業務用ネットワークを介してボリューム２１０等の記憶領域を提供する物理サーバ１５０と接続するためのインタフェースである。なお、管理用ネットワーク及び業務用ネットワークの区別がない場合、管理インタフェース２０１及び外部インタフェース２０２は、一つのインタフェースとしてもよい。

コントローラユニット２２０は、ストレージ装置２００の各種制御を行う。コントローラユニット２２０は、制御装置２２１及びメモリ２２２を含む。制御装置２２１は、ボリューム２１０等の記憶領域に対するアクセス、すなわちＩ／Ｏを制御する。また、制御装置２２１は、記憶ユニット２３０における記憶領域の構成を制御する。メモリ２２２は、制御領域及びＩ／Ｏのキャッシュとして使用される。

記憶ユニット２３０は、複数のＨＤＤ２３１を搭載する。なお、記憶ユニット２３０には、ＨＤＤ以外の記憶媒体が搭載されてもよい。実施例１では、コントローラユニット２２０が、記憶ユニット２３０に搭載される複数のＨＤＤ２３１を用いて冗長化された論理的な記憶領域をボリューム２１０として生成し、物理サーバ１５０に当該ボリューム２１０を提供する。なお、コントローラユニット２２０は、ボリューム２１０とＨＤＤ２３１との対応付けを管理する。

複数のＨＤＤ２３１を用いた冗長化手法としては、ＲＡＩＤ（Ｒｅｄｕｎｄａｎｔ Ａｒｒａｙｓ ｏｆ Ｉｎｅｘｐｅｎｓｉｖｅ Ｄｉｓｋｓ）及びＲＡＩＮ（Ｒｅｄｕｎｄａｎｔ Ａｒｒａｙｓ ｏｆ Ｉｎｅｘｐｅｎｓｉｖｅ Ｎｏｄｅｓ）等が一般的に用いられる。

ディスクインタフェース２４０は、コントローラユニット２２０と記憶ユニット２３０との間で通信するためのインタフェースである。

実施例１では、ストレージ装置２００は専用の装置を用いて実現しているが、一つ又は複数の計算機（例えば、物理サーバ１５０）を用いて実現してもよい。この場合、制御装置２２１はＣＰＵ１０１に対応し、メモリ２２２はメモリ１０２に対応し、外部インタフェース２０２はネットワークインタフェース１０４に対応し、ＨＤＤ２３１はＨＤＤ１０３に対応する。

なお、コントローラユニット２２０は、ボリューム２１０ごとに、ＩＯＰＳ（Ｉｎｐｕｔ Ｏｕｔｐｕｔ Ｐｅｒ Ｓｅｃｏｎｄ）等のアクセスを保証し、又は制限する機能を備えてもよい。

なお、ストレージ装置２００は、Ｉ／Ｏが高速なＳＳＤ、及びＩ／Ｏが低速なＨＤＤの二つを搭載し、ＨＤＤ及びＳＳＤを用いてボリューム２１０を構成してもよい。この場合、コントローラユニット２２０は、ボリューム２１０を構成するＨＤＤの記憶領域及びＳＳＤの記憶領域の比率を変えることによって、Ｉ／Ｏ性能を動的に変更する機能（Ｄｙｎａｍｉｃ Ｔｉｅｒｉｎｇ機能）を備えてもよい。

図６は、実施例１の物理サーバ管理情報Ｔ１００の一例を示す説明図である。

物理サーバ管理情報Ｔ１００は、各物理サーバ１５０の物理構成を管理するための情報（レコード）を格納する。具体的には、物理サーバ管理情報Ｔ１００は、サーバＩＤ（Ｔ１１０）、物理ＣＰＵ数（Ｔ１２０）、ＣＰＵ周波数（Ｔ１３０）、メモリ容量（Ｔ１４０）、及びハイパバイザ／ＯＳ（Ｔ１５０）を含む。

サーバＩＤ（Ｔ１１０）は、物理サーバ１５０を一意に識別するための識別子である。物理ＣＰＵ数（Ｔ１２０）は、物理サーバ１５０が有するＣＰＵ１０１の数である。ＣＰＵ周波数（Ｔ１３０）は、物理サーバ１５０が有するＣＰＵ１０１の周波数である。メモリ容量（Ｔ１４０）は、物理サーバ１５０が有するメモリ１０２の総量である。

ハイパバイザ／ＯＳ（Ｔ１５０）は、物理サーバ１５０を制御するソフトウェア、すなわち、ハイパバイザ４００又はＯＳの種別である。

なお、物理サーバ管理情報Ｔ１００には、ネットワークインタフェース１０４の種類、通信帯域、及びＨＤＤ１０３の種類又は品番等を含んでもよい。また、物理ＣＰＵ数（Ｔ１２０）には、物理サーバ１５０が有するソケット数、一つのソケットあたりのＣＰＵコア数等の細かい粒度の情報が格納されてもよい。

なお、クラウドサービスでは、運用管理コスト上の観点等から、業務用途で使用される物理サーバ１５０は同一の構成であることが一般的である。したがって、図６に示す物理サーバ管理情報Ｔ１００は、クラウドサービス１２００の一般的な構成に対応した情報が格納される。ただし、各物理サーバ１５０の構成が異なる、ヘテロな構成であってもよい。

図７は、実施例１のストレージ管理情報Ｔ２００の一例を示す説明図である。

ストレージ管理情報Ｔ２００は、ストレージ装置２００の記憶領域を管理するための情報（レコード）を格納する。具体的には、ストレージ管理情報Ｔ２００は、ストレージ装置ＩＤ（Ｔ２１０）、ボリュームＩＤ（Ｔ２２０）、容量（Ｔ２３０）、及びＩＯＰＳ（Ｔ２４０）を含む。

ストレージ装置ＩＤ（Ｔ２１０）は、ストレージ装置２００を一意に識別するための識別子である。ボリュームＩＤ（Ｔ２２０）は、ストレージ装置２００が提供するボリューム２１０を一意に識別するための識別子である。容量（Ｔ２３０）は、ボリューム２１０の容量である。ＩＯＰＳ（Ｔ２４０）は、ボリューム２１０のＩＯＰＳである。

なお、ＩＯＰＳ（Ｔ２４０）は、ストレージ装置２００がボリューム２１０毎にＩＯＰＳを保証し、又は制限する機能を有する場合に含まれるカラムである。実施例１では、ＩＯＰＳの値が指定できる構成を前提として説明する。

なお、ストレージ装置２００がＤｙｎａｍｉｃ Ｔｉｅｒｉｎｇ機能を有する場合、Ｄｙｎａｍｉｃ Ｔｉｅｒｉｎｇ機能の性能を格納するカラムが含んでもよい。前述したＩＯＰＳ（Ｔ２４０）には、例えば、ボリューム２１０毎に性能指標として「高」、「中」、「低」といった値が格納されてもよいし、ボリューム２１０を構成するＨＤＤ及びＳＳＤの構成比率を示す値が格納されてもよいし、また、ＨＤＤ及びＳＳＤの構成比率等から推定されるＩＯＰＳの値が格納されてもよい。

なお、ストレージ管理情報Ｔ２００は、ボリューム２１０の使用量、及び各ボリューム２１０に対して設定されたキャッシュの容量等を含んでもよい。

図８は、実施例１の論理物理構成管理情報Ｔ３００の一例を示す説明図である。

論理物理構成管理情報Ｔ３００は、ＶＭ４１０の計算機リソース、及びＶＭ４１０の物理的な配置等を管理するための情報（レコード）を格納する。具体的には、論理物理構成管理情報Ｔ３００は、ＶＭ ＩＤ（Ｔ３１０）、仮想リソース（Ｔ３２０）、及び物理リソース（Ｔ３３０）を含む。

ＶＭ ＩＤ（Ｔ３１０）は、計算機システム上でＶＭ４１０を一意に識別するための識別子である。仮想リソース（Ｔ３２０）は、ＶＭ４１０に割り当てられる仮想的な計算機リソースに関する情報である。物理リソース（Ｔ３３０）は、ＶＭ４１０の物理的な配置に関する情報である。ここで、仮想リソース（Ｔ３２０）及び物理リソース（Ｔ３３０）の具体的な情報について説明する。

仮想リソース（Ｔ３２０）は、ＣＰＵ数（Ｔ３２１）、メモリ容量（Ｔ３２２）、ＩＯＰＳ（Ｔ３２３）、ＣＰＵシェア（Ｔ３２４）、メモリシェア（Ｔ３２５）、Ｉ／Ｏシェア（Ｔ３２６）を含む。

ＣＰＵ数（Ｔ３２１）は、ＶＭ４１０に割り当てられた仮想ＣＰＵの数である。メモリ容量（Ｔ３２２）は、ＶＭ４１０に割り当てられた仮想メモリの容量である。

ＩＯＰＳ（Ｔ３２３）は、ＶＭ４１０に割り当てられたボリューム２１０のＩＯＰＳの値である。なお、ＶＭ４１０又はハイパバイザ４００がストレージ装置２００に対するＩ／Ｏを保証し、又は制限する機能を有しない場合、論理物理構成管理情報Ｔ３００にはＩＯＰＳ（Ｔ３２３）が含まれなくてもよい。

ＣＰＵシェア（Ｔ３２４）、メモリシェア（Ｔ３２５）、及びＩ／Ｏシェア（Ｔ３２６）は、同一の物理サーバ１５０上で稼働する複数のＶＭ４１０間の計算機リソースの共有度合いを示す。ハイパバイザ４００が、テナント１４００の構築時に管理サーバ１００空の指示にしたがって、各カラムの値を設定し、また、テナント１４００の運用中に適宜変更する。

サーバ仮想化技術の特徴の１つとして、オーバープロビジョニングという機能がある。オーバープロビジョニングとは、一つの物理サーバ１５０が有する計算機リソース以上の計算機リソースを、各ＶＭ４１０に割り当てる機能である。すなわち、同一の物理サーバ１５０上で稼働する複数のＶＭ４１０の各々に割り当てられるＣＰＵ数（Ｔ３２１）の総和が物理サーバ１５０が有するＣＰＵ１０１の数より多くなるように設定し、又は、複数のＶＭ４１０の各々に割り当てられるメモリ容量（Ｔ３２２）の総和が、物理サーバ１５０が有するメモリ容量より多くなるように設定することができる。

例えば、サーバＩＤ（Ｔ１１０）が「Ｓｅｒｖ１」の場合、下式（１）を満たすように各ＶＭ４１０にメモリ容量を割り当てることができる。

オーバープロビジョニング機能を有する物理サーバ１５０では、複数のＶＭ４１０が当該物理サーバ１５０が有する計算機リソースを共有する。したがって、同一の物理サーバ１５０上で稼働する全てのＶＭ４１０の各々が割り当てられた仮想ＣＰＵ及び割り当てられた仮想メモリを最大限に利用する場合、計算機リソースを共有するＶＭ４１０の計算機リソースの割り当てを決定する指標がＣＰＵシェア（Ｔ３２４）、メモリシェア（Ｔ３２５）、及びＩ／Ｏシェア（Ｔ３２６）となる。

実施例１のＣＰＵシェア（Ｔ３２４）、メモリシェア（Ｔ３２５）、及びＩ／Ｏシェア（Ｔ３２６）のそれぞれには、「高」、「中」、「低」のいずれかが格納される。例えば、メモリシェア（Ｔ３２５）に「高」が設定される場合、ハイパバイザ４００は、計算機リソースを共有する複数のＶＭ４１０のうち、「高」が設定されたＶＭ４１０に優先的にメモリを割り当てる。

なお、ＣＰＵシェア（Ｔ３２４）及びメモリシェア（Ｔ３２５）には、「占有」が設定されてもよい。この場合、「占有」が設定されたＶＭ４１０に必ずＣＰＵ数（Ｔ３２１）等に設定された計算機リソースを割り当てる。これによって、所定のＶＭ４１０対する必要な計算機リソースの割り当てを保証する。また、ＩＯＰＳ（Ｔ３２６）は、１つのＩ／Ｏにあたりのレスポンスタイムが設定されてもよい。

なお、ＣＰＵシェア（Ｔ３２４）、メモリシェア（Ｔ３２５）、及びＩ／Ｏシェア（Ｔ３２６）には、共有の度合いを表す数値が設定されてもよい。

なお、仮想リソース（Ｔ３２０）には、前述したカラム以外に、ＣＰＵ数の予約値及び制限値、並びにメモリ容量の予約値及び制限値を含んでいてもよい。また、ＣＰＵ数の予約値及び制限値のほか、ＣＰＵの周波数に関する予約値及び制限値を含んでもよい。

ここで、予約値とは、常に、ＶＭ４１０への割り当てが保証される計算機リソースの値を表す。また、制限値とは、ＶＭ４１０に割り当てることができる計算機リソースの上限値を表す。

例えば、メモリ容量（Ｔ３２２）が「４ＧＢ」、メモリ容量の予約値が「１ＧＢ」、メモリ容量の制限値が「２ＧＢ」であるＶＭ４１０を想定する。この場合、ＶＭ４１０が認識する仮想メモリのメモリ容量は「４ＧＢ」であり、そのうち「１ＧＢ」は常に物理サーバ１５０のメモリ空間が確保され、かつ、当該ＶＭ４１０が利用できる物理サーバ１５０のメモリ空間の最大量は「２ＧＢ」であることを意味する。

次に、物理リソース（Ｔ３３０）について説明する。物理リソース（Ｔ３３０）は、サーバＩＤ（Ｔ３３１）及びボリュームＩＤ（Ｔ３３２）を含む。

サーバＩＤ（Ｔ３３１）はサーバＩＤ（Ｔ１１０）と同一のものである。管理サーバ１００は、サーバＩＤ（Ｔ３３１）の値に基づいて、ＶＭ４１０が現在稼働する物理サーバ１５０を把握できる。

ボリュームＩＤ（Ｔ３３２）は、ボリュームＩＤ（Ｔ２２０）と同一のものである。管理サーバ１００は、ボリュームＩＤ（Ｔ３３２）に基づいて、ＶＭ４１０の管理データ等が格納されるボリューム２１０、及び当該ボリューム２１０を提供するストレージ装置２００を把握できる。

実施例１では、ボリューム２１０の識別子に基づいて一意にボリューム２１０を識別できるため、物理リソース（Ｔ３３０）には、ボリュームＩＤ（Ｔ３３２）のみが含まれる。しかし、ボリューム２１０の識別子及びストレージ装置２００の識別子に基づいて一意にボリューム２１０を識別することができる場合、物理リソース（Ｔ３３０）は、ボリューム２１０の識別子の他に、ストレージ装置ＩＤ（Ｔ２１０）に相当するカラムを含んでもよい。

実施例１では、ＶＭ４１０が認識する記憶領域（ドライブ）とボリューム２１０とが１対１に対応付けられるように、ＶＭ４１０に記憶領域が提供される。しかし、ＶＭ４１０が認識するドライブ単位で記憶領域が指定される構成、すなわち、ＶＭ４１０上で実行されるＯＳが認識する一つのドライブと複数のボリューム２１０とを対応付ける構成の場合、ボリュームＩＤ（Ｔ３３２）には、対応付けられる複数のボリューム２１０の識別子が格納される。

なお、図８では、複数のＶＭ４１０のデータが同一のボリューム２１０に格納されることを示している。

図９は、実施例１のテナント管理情報Ｔ４００の一例を示す説明図である。

テナント管理情報Ｔ４００は、利用者１１００に提供されるテナント１４００、及びテナント１４００の構成を管理するための情報（レコード）を格納する。具体的には、テナント管理情報Ｔ４００は、テナントＩＤ（Ｔ４１０）、ＶＭ ＩＤ（Ｔ４２０）、ＩＰアドレス（Ｔ４３０）、機能（Ｔ４４０）、接続先（Ｔ４５０）、及び状態（Ｔ４６０）を含む。

テナントＩＤ（Ｔ４１０）は、テナント１４００の識別子である。ＶＭ ＩＤ（Ｔ４２０）は、テナント１４００に含まれるＶＭ４１０の識別子であり、ＶＭ ＩＤ（Ｔ３１０）と同一のものである。

ＩＰアドレス（Ｔ４３０）は、ＶＭ４１０のＩＰアドレスである。ＩＰアドレス（Ｔ４３０）に格納されるＩＰアドレスは、ＶＭ４１０が外部の装置と通信するために用いられるアドレスである。なお、ＩＰアドレス（Ｔ４３０）には複数のＩＰアドレスが格納されてもよい。

機能（Ｔ４４０）は、ＶＭ４１０によって提供される機能（サービス）を示す。より具体的には、ＶＭ４１０にインストールされたソフトウェア等によって実現される役割を意味する。ＶＭ４１０の役割は、サービス申込時又はＶＭ４１０の構築時に設定される。

接続先（Ｔ４５０）は、ＶＭ ＩＤ（Ｔ４２０）に対応するＶＭ４１０が通信する他のＶＭ４１０のＩＰアドレスである。複数のＶＭ４１０の各々に役割を分担する業務システムでは各ＶＭ４１０が他のＶＭ４１０と通信する。そのため、接続先（Ｔ４５０）には、接続先のＶＭ４１０のＩＰアドレスが格納される。なお、複数のＶＭ４１０と接続される場合、接続先（Ｔ４５０）には、複数のＩＰアドレスが格納される。

状態（Ｔ４６０）は、ＶＭ４１０の状態である。実施例１の状態（Ｔ４６０）には、リソース最適化プログラム３０００によって変更された状態を示す値が格納される。具体的には、「スケールアウト」、「スケールイン」、「スケールアップ」、及び「スケールダウン」のいずれかが格納される。リソース最適化プログラム３０００が実行する処理の説明において状態（Ｔ４６０）の具体的な扱い方について述べる。

図９に示す、テナントＩＤ（Ｔ４１０）が「Ｔｅｎａｎｔ１」のテナント１４００は、５つのＶＭ４１０から構成されるＷｅｂ三階層システムであることを示す。

ＶＭ ＩＤ（Ｔ４２０）が「ＬＢ１」であるＶＭ４１０は、ＩＰアドレス「１０．０．０．１」が設定され、かつ、フロントエンドとなるＬＢ１４１０である。ＶＭ ＩＤ（Ｔ４２０）が「ＶＭ１１」、「ＶＭ１２」である２つのＶＭ４１０は、ＬＢから受け付けたリクエストを処理するＷｅｂ機能を有するＷｅｂサーバ１４２０である。ＶＭ ＩＤ（Ｔ４２０）が「ＶＭ１３」、「ＶＭ１４」である２つのＶＭ４１０は、Ｗｅｂサーバ１４２０からのリクエストを処理するＤＢ機能を有するＤＢサーバ１４３０である。

「ＶＭ１３」のＶＭ４１０及び「ＶＭ１４」のＶＭ４１０は冗長構成（ＨＡ）が組まれている。また、「ＶＭ１３」のＶＭ４１０は、Ｗｅｂサーバ１４２０から受け付けたリクエストを処理する正側（実行系）のＤＢサーバ１４３０であり、「ＶＭ１４」のＶＭ４１０は、副側（待機系）のＤＢサーバ１４３０である。

実施例１では、利用者１１００のサービス申込時に、テナント管理情報Ｔ４００に当該利用者１１００のテナント１４００のレコードが生成されることを想定する。例えば、利用者１１００が、サービス申込時に、システムテンプレート管理情報Ｔ９００に格納された情報に基づいて、業務システムの構成を選択することによって、テナント管理情報Ｔ４００に当該利用者１１００のテナント１４００のレコードが追加される。また、ＶＭ ＩＤ（Ｔ４２０）及びＩＰアドレス（Ｔ４３０）は、利用者１１００がテナント１４００の構築時に、手動又は自動的に設定される。また、テナント管理情報Ｔ４００は、リソース最適化プログラム３０００等が実行する処理によって、随時更新される。

図１０は、実施例１の性能管理情報Ｔ５００の一例を示す説明図である。

性能管理情報Ｔ５００は、各テナント１４００の性能に関する履歴情報（レコード）を格納する。具体的には、性能管理情報Ｔ５００は、テナントＩＤ（Ｔ５１０）に対応するテナント１４００毎に、時間（Ｔ５２０）、Ｗｅｂ使用リソース（Ｔ５３０）、総Ｗｅｂセッション数（Ｔ５４０）、ＳＱＬリクエスト数（Ｔ５５０）、及び正側ＤＢ使用リソース（Ｔ５６０）を含む。

テナントＩＤ（Ｔ５１０）は、テナントＩＤ（Ｔ４１０）と同一のものである。時間（Ｔ５２０）は、テナント１４００について、Ｗｅｂ使用リソース（Ｔ５３０）、総Ｗｅｂセッション数（Ｔ５４０）、ＳＱＬリクエスト数（Ｔ５５０）、及び正側ＤＢ使用リソース（Ｔ５６０）に格納する値、すなわち、テナント１４００の性能に関する情報を取得した時間である。

Ｗｅｂ使用リソース（Ｔ５３０）は、テナント１４００に含まれるＷｅｂサーバ１４２０における計算機リソースの平均使用率又は平均使用量である。Ｗｅｂ使用リソース（Ｔ５３０）は、ＣＰＵ使用率（Ｔ５３１）及びメモリ使用量（Ｔ５３２）を含む。

ＣＰＵ使用率（Ｔ５３１）及びメモリ使用量（Ｔ５３２）は、Ｗｅｂサーバ１４２０として設定されたＶＭ４１０に割り当てられた仮想ＣＰＵの使用率及び仮想メモリの使用量の平均値である。

総Ｗｅｂセッション数（Ｔ５４０）は、Ｗｅｂサーバ１４２０が管理するＷｅｂセッションの数である。ＳＱＬリクエスト数（Ｔ５５０）は、Ｗｅｂサーバ１４２０からＤＢサーバ１４３０へ送信されたリクエストの数である。

正側ＤＢ使用リソース（Ｔ５６０）は、Ｗｅｂサーバ１４２０から受け付けたリクエストを実際に処理する正側のＤＢサーバ１４３０における計算機リソースの使用率又は使用量である。正側ＤＢ使用リソース（Ｔ５６０）は、ＣＰＵ使用率（Ｔ５６１）、メモリ使用量（Ｔ５６２）、及びＩＯＰＳ（Ｔ５６３）を含む。

ＣＰＵ使用率（Ｔ５６１）及びメモリ使用量（Ｔ５６２）は、ＤＢサーバ１４３０として設定されたＶＭ４１０に割り当てられた仮想ＣＰＵの使用率及び仮想メモリの使用容量である。ＩＯＰＳ（Ｔ５６３）は、ボリューム２１０へのＩＯＰＳである。

なお、正側ＤＢ使用リソース（Ｔ５６０）には、性能障害イベント等を含む、ＤＢサーバ１４３０の性能に関する状態を管理するカラムが含まれてもよい。

管理サーバ１００は、テナント管理情報Ｔ４００及び性能管理情報Ｔ５００に基づいて、各テナント１４００を構成するＶＭ４１０等の性能を管理する。

例えば、図１０は、テナントＩＤ（Ｔ５１０）が「Ｔｅｎａｎｔ１」であるテナント１４００の性能の履歴情報を示す。管理サーバ１００は、時刻（Ｔ５２０）が「９：００」の時、２つのＷｅｂサーバ１４２０、すなわち、「ＶＭ１１」及び「ＶＭ１２」のＶＭ４１０のＣＰＵ使用率の平均値が「３０％」であり、メモリ使用量の平均値が「１ＧＢ」であり、Ｗｅｂセッションの数が「１０」であることが分かる。また、管理サーバ１００は、「ＶＭ１１」及び「ＶＭ１２」のＶＭ４１０がＤＢサーバ１４３０、すなわち、「ＶＭ１３」及び「ＶＭ１４」のＶＭ４１０に送信するＳＱＬリクエストの数が「２０」であることが分かる。

また、管理サーバ１００は、「Ｔｅｎａｎｔ１」のテナント１４００の性能の履歴情報に基づいて、時間の経過とともに負荷が増大していることが分かる。

なお、正側ＤＢ使用リソース（Ｔ５６０）の使用方法については、リソース最適化プログラム３０００等が実行する処理の説明において述べる。

なお、性能管理情報Ｔ５００は、例えば、構成／性能管理プログラム２２００によって生成される。具体的には、構成／性能管理プログラム２２００が、物理サーバ１５０のハイパバイザ４００等から各構成要素の情報を取得し、取得された情報に基づいて性能管理情報Ｔ５００に情報を追加する。

なお、性能管理情報Ｔ５００は、テナント１４００内の性能に関するデータを集計した情報を格納しているが、これに限定されない。例えば、テナント１４００に含まれる各ＶＭ４１０の性能情報を時系列で格納する形式であってもよい。この場合、管理サーバ１００は、外部からの要求に応じて、性能管理情報Ｔ５００の各ＶＭ４１０の性能情報を集計することによって、図１０に示すようなＣＰＵ使用率（Ｔ５３１）等の各種情報を算出する。

図１１は、実施例１のシステムテンプレート管理情報Ｔ９００の一例を示す説明図である。

システムテンプレート管理情報Ｔ９００は、利用者１１００が要求する業務システムの構成に関する情報（レコード）、すなわち、システムテンプレートを格納する。具体的には、システムテンプレート管理情報Ｔ９００は、パターンＩＤ（Ｔ９１０）、Ｗｅｂサーバ（Ｔ９２０）、ＤＢサーバ（Ｔ９３０）、及びＴｂｌ ＩＤ（Ｔ９４０）を含む。

概念的には、Ｗｅｂサーバ（Ｔ９２０）はスケールアウト可能なサーバに対応するカラム、ＤＢサーバ（Ｔ９３０）はスケールアウト可能なサーバに接続され、かつ、スケールアップが必要なサーバに対応するカラムを意味する。

パターンＩＤ（Ｔ９１０）は、システムテンプレート管理情報Ｔ９００において管理するシステムテンプレートを一意に識別するための識別子である。

Ｗｅｂサーバ（Ｔ９２０）は、業務システムにおけるＷｅｂサーバ１４２０の構成を示す情報である。Ｗｅｂサーバ（Ｔ９２０）は、ＯＳ（Ｔ９２１）、ソフトウェア（Ｔ９２２）、ＣＰＵ数（Ｔ９２３）、メモリ容量（Ｔ９２４）、ＩＯＰＳ（Ｔ９２５）、及び初期数（Ｔ９２６）を含む。

ＯＳ（Ｔ９２１）は、Ｗｅｂサーバ１４２０にインストールされるＯＳの名称又は種別である。ソフトウェア（Ｔ９２２）は、Ｗｅｂサーバ１４２０にインストールされるソフトウェアの名称又は種別である。ＣＰＵ数（Ｔ９２３）、メモリ容量（Ｔ９２４）及びＩＯＰＳ（Ｔ９２５）は、Ｗｅｂサーバ１４２０に要求されるスペックに関する情報である。初期数（Ｔ９２６）は、業務システムに設定されるＷｅｂサーバ１４２０の数である。

ＤＢサーバ（Ｔ９３０）は、業務システムにおけるＤＢサーバ１４３０の構成を示す情報である。ＤＢサーバ（Ｔ９３０）は、ＯＳ（Ｔ９３１）、ソフトウェア（Ｔ９３２）、ＣＰＵ数（Ｔ９３３）、メモリ容量（Ｔ９３４）、ＩＯＰＳ（Ｔ９３５）、及び構成（Ｔ９３６）を含む。

ＯＳ（Ｔ９３１）は、ＤＢサーバ１４３０にインストールされるＯＳの名称又は種別である。ソフトウェア（Ｔ９３２）は、ＤＢサーバ１４３０にインストールされるソフトウェアの名称又は種別である。ＣＰＵ数（Ｔ９３３）、メモリ容量（Ｔ９３４）及びＩＯＰＳ（Ｔ９３５）は、ＤＢサーバ１４３０に要求されるスペックに関する情報である。構成（Ｔ９３６）は、ＤＢサーバ１４３０についてＨＡ構成を組むか否かを示す情報等である。例えば、構成（Ｔ９３６）に「ＨＡ」が格納される場合、冗長構成であることを示す。一方、構成（Ｔ９３６）に「単一」が格納される場合、冗長構成ではないことを示す。

Ｔｂｌ ＩＤ（Ｔ９４０）は、後述するリソース変更方法管理情報Ｔ８００のレコードの識別子である。Ｔｂｌ ＩＤ（Ｔ９４０）によって、業務システムに適用する計算機リソースの変更方法が指定される。

なお、システムテンプレート管理情報Ｔ９００は、構成変更プログラム２３００が業務システムを構築するために用いるスクリプト等の情報へのリンクを含んでもよい。

なお、実施例１では、業務システムとしてＷｅｂ三階層システムを前提としているため、システムテンプレート管理情報Ｔ９００には、Ｗｅｂサーバ１４２０及びＤＢサーバ１４３０のカラムが含まれるが、これに限定されない。Ｗｅｂ三階層システム以外の業務システムを管理するシステムテンプレート管理情報Ｔ９００であってもよい。

図１２は、実施例１の顧客管理情報Ｔ６００の一例を示す説明図である。

顧客管理情報Ｔ６００は、顧客である利用者１１００が利用するテナント１４００を管理する情報（レコード）を格納する。具体的には、顧客管理情報Ｔ６００は、利用者ＩＤ（Ｔ６１０）、テナントＩＤ（Ｔ６２０）、種別（Ｔ６３０）、及びパターンＩＤ（Ｔ６４０）を含む。

利用者ＩＤ（Ｔ６１０）は、クラウドサービス１２００を利用する利用者１１００を識別するための識別子である。テナントＩＤ（Ｔ６２０）は、利用者１１００が利用するテナント１４００を識別するための識別子であり、テナントＩＤ（Ｔ４１０）と同一のものである。

種別（Ｔ６３０）は、テナント１４００の性能保証等に関する契約形態の種別を示す情報である。実施例１の種別（Ｔ６３０）には、「性能保証型」、「性能固定型」、及び「ベストエフォート型」のいずれかが格納される。

「性能保証型」の契約形態は、テナント１４００の性能が所定の基準以上であることを保証する契約形態である。「性能固定型」の契約形態は、指定された性能を変更することなくテナント１４００が稼働することを保証する契約形態である。「ベストエフォート型」は、他の利用者１１００のテナント１４００等の利用状況に応じて、自己のテナント１４００の性能が変動することを利用者１１００が許容する契約形態である。実施例１では、「性能保証型」のテナント１４００を管理対象としている。

なお、契約形態（Ｔ６３２）には、前述の契約形態を示す情報の代わりに、Ｗｅｂサーバ１４２０のスケール変更の可否を示す情報、及びＤＢサーバ１４３０のスケール変更の可否を示す情報等、テナント１４００の構成ごとのスケーリングに関する情報が格納されてもよい。

パターンＩＤ（Ｔ６４０）は、テナント１４００の構築時に指定されたシステムテンプレートの識別子であり、パターンＩＤ（Ｔ９１０）と同一のものである。

なお、顧客管理情報Ｔ６００は、利用者１１００がサービスを申し込む時等に顧客管理プログラム２５００によって生成され、また、更新される。なお、顧客管理プログラム２５００が課金プログラム２４００と連携する場合、顧客管理情報Ｔ６００に課金情報又は課金時に用いられる情報を含めることもできる。

図１３は、実施例１のスケール管理情報Ｔ７００の一例を示す説明図である。

スケール管理情報Ｔ７００は、契約形態が「性能保証型」であるＷｅｂ三階層システムにおいて、Ｗｅｂサーバ１４２０の数と、ＤＢサーバ１４３０に割り当てるべき計算機リソースとの関係を示す情報（レコード）を格納する。具体的には、スケール管理情報Ｔ７００は、パターンＩＤ（Ｔ７１０）、Ｗｅｂサーバ数（Ｔ７２０）、及びＤＢサーバ（Ｔ７３０）を含む。

パターンＩＤ（Ｔ７１０）は、システムテンプレートの一意に識別するための識別子であり、パターンＩＤ（Ｔ９１０）と同一のものである。Ｗｅｂサーバ数（Ｔ７２０）は、システムテンプレートに対応する業務システムに含まれるＷｅｂサーバ１４２０の数である。

ＤＢサーバ（Ｔ７３０）は、Ｗｅｂサーバ１４２０の数に応じて、業務システムに必要なＤＢサーバ１４３０の計算機リソースに関する情報であり、ＣＰＵ数（Ｔ７３１）、メモリ容量（Ｔ７３２）、及びＩＯＰＳ（Ｔ７３３）を含む。なお、ＤＢサーバ（Ｔ７３０）は、ＣＰＵの周波数などのカラムを含んでもよい。

また、ＤＢサーバ（Ｔ７３０）は、ＳＱＬリクエスト限界数（Ｔ７３４）を含む。ＳＱＬリクエスト限界数（Ｔ７３４）は、ＣＰＵ数（Ｔ７３１）、メモリ容量（Ｔ７３２）、及びＩＯＰＳ（Ｔ７３３）に示された値の計算機リソース（スペック）を有するＤＢサーバ１４３０が処理可能なＳＱＬリクエストの数である。実施例１では、ＳＱＬリクエスト限界数（Ｔ７３４）は、ＤＢサーバ１４３０の負荷を判定するための指標として用いられる。

なお、スケール管理情報Ｔ７００は、ＳＱＬリクエスト限界数（Ｔ７３４）の代わりに、例えば、ＣＰＵ使用率、メモリ使用量、若しくはＩＯＰＳの上限値、又は性能障害イベントの一覧等をＤＢサーバ１４３０の負荷を判定するための指標として格納してもよい。

なお、スケール管理情報Ｔ７００には、予めシステム毎に定義された値が格納されてもよいし、テナント１４００の構築時に当該テナント１４００の性能を評価することによって決定された値が格納されてもよい。

Ｗｅｂ三階層システムでは、システムの負荷に応じてＷｅｂサーバ１４２０の数が動的に増加又は減少する。スケール管理情報Ｔ７００は、Ｗｅｂサーバ１４２０の数の追加又は削除に伴って、ＤＢサーバ１４３０に必要な計算機リソースを決定するために使用される。

例えば、Ｗｅｂ三階層システムに２つのＷｅｂサーバ１４２０が含まれる場合、管理サーバ１００は、スケール管理情報Ｔ７００を参照して、ＤＢサーバ１４３０にはＣＰＵの数が「２」、メモリ容量が「５ＧＢ」、ＩＯＰＳが「３００」だけ計算機リソースが必要であることが分かる。

実施例１では、管理サーバ１００は、スケール管理情報Ｔ７００を参照し、Ｗｅｂサーバ１４２０が管理するＷｅｂセッションにおけるリクエストを処理可能な計算機リソースをＤＢサーバ１４３０に割り当てる。これによって、ＤＢサーバ１４３０の処理性能が不足することによって、Ｗｅｂサーバ１４２０から送信されたＳＱＬリクエストを処理できない等の障害を回避できる。

なお、ＤＢサーバ１４３０に割り当てる計算機リソースを決定する方法としては、管理サーバ１００は、スケール管理情報Ｔ７００のようなテーブル形式の情報を用いるのではなく、論理物理構成管理情報Ｔ３００及び性能管理情報Ｔ５００に基づいて動的に算出してもよい。

例えば、Ｗｅｂサーバ１４２０の数又はＳＱＬリクエストの数を入力することによってＤＢサーバ１４３０に必要な計算機リソースを算出する関数等を用いることが考えられる。また、管理サーバ１００は、ＳＱＬリクエスト数（Ｔ５５０）の増減と、ＤＢサーバ１４３０のＣＰＵ利用率、メモリ使用量、及びＩＯＰＳ値の履歴情報とに基づいて、ＳＱＬリクエストを処理するために必要なＤＢサーバ１４３０の計算機リソースを予測（プロファイル）し、必要な計算機リソースを決定する方法も考えられる。この場合、性能管理情報Ｔ５００には、ＤＢサーバ１４３０のＣＰＵ使用率及びメモリ使用量等が格納されている必要がある。

図１４は、実施例１のリソース変更方法管理情報Ｔ８００の一例を示す説明図である。

リソース変更方法管理情報Ｔ８００は、リソース最適化プログラム３０００がＶＭ４１０の計算機リソースの割当てを変更する場合に使用する変更方法の管理情報（レコード）を格納する。具体的には、リソース変更方法管理情報Ｔ８００は、Ｔｂｌ ＩＤ（Ｔ８１０）、対象（Ｔ８２０）、変更方法（Ｔ８３０）、及び分類（Ｔ８４０）を含む。

適用できる計算機リソースの変更方法は、ＯＳ及びソフトウェアの組み合わせ毎に異なる。そのため、変更対象の計算機リソース毎に適用できる変更方法、及び変更方法を適用した場合に業務システムへの影響を示す情報を対応付けて、一つにまとめておく必要がある。

そこで、実施例１では、管理サーバ１００は、リソース変更方法管理情報Ｔ８００を用いて、変更対象の計算機リソースに対する複数の計算機リソースの変更方法の集合を一つの業務システムに適用する変更方法（レコード）として管理する。

なお、ハイパバイザの種別によっても適用可能な計算機リソースの変更方法が異なる場合がある。この場合、ＯＳ、ソフトウェア及びハイパバイザの組合せをも考慮した情報をリソース変更方法管理情報Ｔ８００に格納すればよい。

Ｔｂｌ Ｉ（Ｔ８１０）は、リソース変更方法管理情報Ｔ８００のレコードを一意に識別するための識別子である。対象（Ｔ８２０）は、変更対象の計算機リソースの種別である。

変更方法（Ｔ８３０）は、変更対象の計算機リソースの割当てを変更するための制御内容である。図１４に示す例では、変更方法（Ｔ８３０）には、制御内容が格納されているが、構成変更プログラム２３００に変更処理を指示するためのコマンド又はスクリプトが格納されてもよい。また、変更方法（Ｔ８３０）には、各変更方法の実行順番又は実行する順番を決定するための優先度、又は、排他関係にある変更方法に関する情報等が格納されてもよい。

分類（Ｔ８４０）は、変更方法（Ｔ８３０）に対応する変更方法を適用した場合に、ＶＭ又はＶＭ上のＯＳ若しくはソフトウェアに及ぼす影響を示す情報である。実施例１の分類（Ｔ８４０）には、変更方法が適用された時にＶＭ４１０が停止するか否かを示す情報が格納される。分類（Ｔ８４０）が「無停止」である場合、変更方法が適用されたＶＭ４１０が停止しないこと、すなわち、業務システムに与える影響が小さいことを示す。分類（Ｔ８４０）が「停止」である場合、変更方法が適用されたＶＭ４１０が停止すること、すなわち、業務システムに与える影響が大きいことを示す。

管理サーバ１００は、リソース変更方法管理情報Ｔ８００に基づいて各変更方法を管理できる。例えば、対象（Ｔ８２０）が「ＣＰＵ」、変更方法（Ｔ８３０）が「ＣＰＵシェア値変更」、分類（Ｔ８４０）が「無停止」である変更方法は、ＶＭ４１０に対するＣＰＵのシェア値を当該ＶＭ４１０を停止させることなく実行できることが分かる。

また、ＣＰＵ数の変更等は、ハイパバイザ４００並びにＯＳ及びソフトウェアの組合せによっては、Ｈｏｔ−Ａｄｄと呼ばれる稼働中に追加できる機能があり、当該機能を利用可能なソフトウェアの組み合わせによっては、「停止」での実行が可能な場合がある。

Ｔｂｌ ＩＤ（Ｔ８１０）毎に管理される変更方法は、業務システムを構成する要素に基づいて決定される。実施例１では、仮想化技術を前提としているが、物理的なサーバを対象としてもよい。この場合、図１４に示す変更方法のうち、外部ストレージ装置への変更等の変更方法を適用できる。したがって、本発明は、仮想化技術に対応した計算機システムのみならず、仮想化技術に対応していない計算機システム、すなわち、物理サーバ１５０そのものを用いて構築された業務システムに対しても効果を奏する。

以下の説明では、分類（Ｔ８４０）が「無停止」である変更方法を無停止の変更方法と記載し、また、分類（Ｔ８４０）が「停止」である変更方法を停止の変更方法とも記載する。

図１５は、実施例１のリソース最適化プログラム３０００が実行する処理の概要を説明するフローチャートである。

リソース最適化プログラム３０００は、所定の契機で処理を開始する（ステップＳ３０１０）。

例えば、リソース最適化プログラム３０００は、テナント１４００が構築された後に処理を開始する。より具体的には、利用者１１００が、テナント１４００の構築時に図２０に示すような画面を用いてサービスを申し込み、構成変更プログラム２３００が申込みされたサービスに基づいて業務システム（テナント１４００）を構築した後に処理が開始される。

なお、本処理の対象となる業務システムは、サービス申込時に、スケールアウト又はスケールアップを行う旨の設定が行われた業務システムを対象とすることを想定する。

ここで、図２０を用いてサービスの申込時に用いられる画面について説明する。図２０は、実施例１のサービス申込時に用いられる画面の一例を示す説明図である。

利用者１１００が、例えばＷｅｂブラウザを用いてポータル２０００にアクセスした場合に、図２０に示すような画面２０１０が表示される。

画面２０１０は、パターン入力２０１１、種別入力２０１２、表示項目２０１３、及び申込み操作ボタン２０１４を含む。

パターン入力２０１１は、利用者１１００が希望する業務システム（テナント１４００）のパターンを選択するための入力項目である。パターン入力２０１１には、例えば、システムテンプレート管理情報Ｔ９００のパターンＩＤ（Ｔ９１０）に対応した値等が表示される。

種別入力２０１２は、業務システムの性能の特徴を指定するための入力項目である。種別入力２０１２は、顧客管理情報Ｔ６００の種別（Ｔ６３０）に対応する。

表示項目２０１３は、パターン入力２０１１及び種別入力２０１２の操作に基づいてサービスの概要を表示する項目である。例えば、業務システムの構成の概要、又はＷｅｂサーバ（Ｔ９２０）及びＤＢサーバ（Ｔ９３０）等の業務システムの構成要素等が表示される。

申込み操作ボタン２０１４は、パターン入力２０１１及び種別入力２０１２を操作することによって設定された業務システムに関するサービスを利用者１１００が申し込む場合に操作するボタンである。図２０に示す例では、契約形態が「性能保証型」であり、かつ、「Ｗｅｂ三階層システム１」に対応する業務システムのサービスが申し込まれる。

また、画面２０１０には種別入力２０１２の代わりに、テナント管理情報Ｔ４００の機能（Ｔ４４０）の値毎に挙動を指定する入力項目があってもよい。例えば、Ｗｅｂサーバ１４２０をスケールアウト及びスケールインが可能な構成とするか否か、ＤＢサーバ１４３０をスケールアップ及びスケールダウンが可能な構成とするか否かを選択させる入力項目等が考えられる。

また、他の入力項目として、前述の各スケーリング処理を自動的に、又は利用者１１００に判断させるか否かを選択する入力項目があってもよい。また、入力項目の操作とあわせて、テナント管理情報Ｔ４００の各項目、例えばＩＰアドレス等を指定する画面であってもよい。

以上が図２０の説明である。図１５の説明に戻る。

リソース最適化プログラム３０００は、性能管理情報Ｔ５００を参照して、対象のテナント１４００負荷の増大の予兆が検出されたか否かを判定する（ステップＳ３１００）。なお、リソース最適化プログラム３０００は、周期的に性能管理情報Ｔ５００を参照するものとする。また、テナント１４００の負荷とは、テナント１４００全体の負荷、又はテナント１４００に含まれるＤＢサーバ１４３０の負荷のことを示す。

例えば、リソース最適化プログラム３０００は、性能管理情報Ｔ５００のＷｅｂ使用リソース（Ｔ５３０）又は総Ｗｅｂセッション数（Ｔ５４０）等の値が所定の閾値より大きいか否かを判定する。リソース最適化プログラム３０００は、Ｗｅｂ使用リソース（Ｔ５３０）等の値が所定の閾値より大きい場合、対象のテナント１４００の負荷の増大の予兆が検出されたものと判定する。

なお、テナント１４００の負荷の増大の予兆を検出する方法としては、Ｗｅｂ使用リソース（Ｔ５３０）又は総Ｗｅｂセッション数（Ｔ５４０）等な値そのものではなく、当該値の上昇率（速度）も用いてもよい。また、特許文献１に示されるような、Ｗｅｂサーバ１４２０等のスケールアウト判定処理において用いられる一般的なメトリックに基づいてテナント１４００の負荷の増大の予兆を検出する方法でもよい。

なお、リソース最適化プログラム３０００は、ステップＳ３１５０の処理、すなわち、Ｗｅｂサーバ１４２０のスケールアウトの実行イベントを対象のテナント１４００の負荷の増大の予兆として検出してもよい。

対象のテナント１４００の負荷の増大の予兆が検出されない場合、リソース最適化プログラム３０００は、ステップＳ３１００に戻り、同様の処理を繰り返し実行する。

対象のテナント１４００の負荷の増大の予兆が検出された場合、リソース最適化プログラム３０００は、Ｗｅｂサーバ１４２０のスケールアウト処理を実行する（ステップＳ３１５０）。

なお、Ｗｅｂサーバ１４２０のスケールアウト処理の開始基準は、ステップＳ３１００と同一のものでもよいし、また、オートスケール専用に設定された開始基準でもよい。オートスケール専用に設定される開始基準を用いる場合、構成変更プログラム２３００が実行したイベントをリソース最適化プログラム３０００が受け取ることによって、Ｗｅｂサーバ１４２０のスケールアウト処理が実行される。

なお、リソース最適化プログラム３０００は、Ｗｅｂサーバ１４２０のスケールアウト処理と連動して、ＬＢ１４１０の設定を変更してもよい。例えば、追加されたＷｅｂサーバ１４２０へのリクエストを分配する等の設定変更が行われる。ＬＢ１４１０の設定を変更する方法は、例えば特許文献１に記載されている方法を用いればよい。

なお、追加されるＷｅｂサーバ１４２０については、現稼働中のＶＭを用いてもよいし、テナント構築時に使用されたＷｅｂサーバ１４２０の情報に基づいて新たに生成されてもよい。

リソース最適化プログラム３０００は、Ｗｅｂサーバ１４２０のスケールアウト処理の実行後、ＤＢサーバ１４３０のスケールアップ処理を実行する（ステップＳ３２００）。

ステップＳ３２００では、リソース最適化プログラム３０００は、正側のＤＢサーバ１４３０に対して当該ＤＢサーバ１４３０を無停止の変更方法を適用することによって正側のＤＢサーバ１４３０のスケールアップを行う。また、リソース最適化プログラム３０００は、副側のＤＢサーバ１４３０に対して変更方法を適用することによって、副側のＤＢサーバ１４３０のスケールアップを行う。副側のＤＢサーバ１４３０に適用される変更方法は、停止の変更方法又は無停止の変更方法のいずれであってもよい。なお、ステップＳ３２００の処理の詳細は、図１６Ａ及び図１６Ｂを用いて後述する。

なお、リソース最適化プログラム３０００は、ステップＳ３２００の処理の前に、ＤＢサーバ１４３０に割り当てられた仮想ＣＰＵ及び仮想メモリ等の計算機リソースの割当量を追加する必要があるかを判定し、当該判定結果に基づいて、処理を分岐させてもよい。例えば、リソース最適化プログラム３０００は、ＤＢサーバ１４３０に割り当てられる計算機リソースの割当量を追加する必要があると判定した場合にステップＳ３２００に進み、ＤＢサーバ１４３０に割り当てられる計算機リソースの割当量を追加する必要がないと判定した場合にステップＳ３１００に戻る。

前述した判定処理は以下のような処理が考えられる。リソース最適化プログラム３０００は、Ｗｅｂサーバ１４２０のスケールアウト処理の実行前及び実行後のＷｅｂサーバ１４２０の数を入力として受け付け、当該Ｗｅｂサーバ１４２０の数に基づいてスケール管理情報Ｔ７００を参照してＤＢサーバ１４３０の計算機リソースの割当量を追加する必要があるか否かを判定する。

例えば、Ｗｅｂサーバ１４２０のスケールアウト処理を実行することによって、Ｗｅｂサーバ１４２０の数が「１」から「２」に変化した場合、リソース最適化プログラム３０００は、ＤＢサーバ１４３０に割り当てられる計算機リソースを追加する必要がないと判定する。Ｗｅｂサーバ１４２０のスケールアウト処理を実行することによって、Ｗｅｂサーバ１４２０の数が「２」から「３」に変化した場合、リソース最適化プログラム３０００は、ＤＢサーバ１４３０に割り当てられる計算機リソースを追加する必要があると判定する。

リソース最適化プログラム３０００は、ＤＢサーバ１４３０のスケールアップ処理の実行後、ＤＢサーバ１４３０の負荷を監視し、当該監視結果に基づいてＤＢサーバ１４３０の負荷が増大しているか否かを判定する（ステップＳ３４００）。

例えば、リソース最適化プログラム３０００は、スケール管理情報Ｔ７００のＳＱＬリクエスト限界数（Ｔ７３４）に基づいて、ＤＢサーバ１４３０の負荷が増大しているか否かを判定する。なお、リソース最適化プログラム３０００は、ＳＱＬリクエスト限界数（Ｔ７３４）の代わりに、ＣＰＵ使用率又はメモリ使用量を用いてもよいし、また、性能障害イベント等が登録されている場合には登録された情報を判定条件として用いてもよい。

ここで、具体的な一例として、パターンＩＤ（Ｔ７１０）が「ＳＹＳ１」であるＷｅｂ三階層システムにおいて、Ｗｅｂサーバ１４２０の数が「２」から「３」に変化した場合を想定する。このとき、ＤＢサーバ１４３０が受け付けたＳＱＬリクエストの数が、Ｗｅｂサーバ１４２０数が「２」、すなわち、Ｗｅｂサーバ１４２０のスケールアウト処理の実行前のＳＱＬリクエスト限界数（Ｔ７３４）の値「３５」より大きい場合、ステップＳ３５００の処理が実行される。

ステップＳ３４００の処理は、ＤＢサーバ１４３０の切り替え、すなわち、テイクオーバ処理にリスクがあるため設けられている。これは、ＤＢサーバ１４３０の切り替え時に何らかの障害が起こる可能性があり、また、ＤＢサーバ１４３０の切り替え中にフロントエンド側からの接続が不安定になる可能性があるためである。

なお、実施例１では、リソース最適化プログラム３０００は、ＤＢサーバ１４３０の負荷の増大が検出された場合に、自動的にステップＳ３５００の処理を実行しているがこれに限定されない。例えば、リソース最適化プログラム３０００は、ステップＳ３４００の判定結果を業務システムの管理者（例えば利用者１１００）に通知することによって、ステップＳ３５００等の処理の実行可否又は実行タイミングを管理者が決定できるようにしてもよい。これによって、プログラムで知り得ない外的要因、例えば、提供サービスのサービスイン等のビジネス的要因を考慮できる。

ＤＢサーバ１４３０の負荷が増大していない場合、リソース最適化プログラム３０００は、ステップＳ３６００に進む。

ＤＢサーバ１４３０の負荷が増大している場合、リソース最適化プログラム３０００は、正側のＤＢサーバ１４３０及び副側のＤＢサーバ１４３０の切り替えによるＤＢサーバ１４３０のスケールアップ処理を実行する（ステップＳ３５００）。なお、ステップＳ３５００の処理の詳細は、図１７を用いて後述する。

ステップＳ３４００の判定結果がＮＯ、又は、ステップＳ３５００の処理の実行後、リソース最適化プログラム３０００は、対象のテナント１４００の負荷が収束したか否かを判定する（ステップＳ３６００）。

ステップＳ３６００では、リソース最適化プログラム３０００は、ステップＳ３１００と同様に性能管理情報Ｔ５００に基づいて判定する。例えば、Ｗｅｂ使用リソース（Ｔ５３０）又は総Ｗｅｂセッション数（Ｔ５４０）の値が所定の閾値より小さい場合、リソース最適化プログラム３０００は、対象のテナント１４００の負荷が収束したと判定する。

また、リソース最適化プログラム３０００は、Ｗｅｂサーバ１４２０のスケールイン処理の実行を、対象のテナント１４００の負荷の収束として検出してもよい。また、リソース最適化プログラム３０００は、所定のイベントの終了を検出した場合に、対象テナント１４００の負荷が収束したと判定してもよい。また、リソース最適化プログラム３０００は、タイマを用いて設定された時間が経過した場合に、対象テナント１４００の負荷が収束したと判定してもよい。

また、リソース最適化プログラム３０００は、追加条件として、Ｗｅｂ使用リソース（Ｔ５３０）又は総Ｗｅｂセッション数（Ｔ５４０）の値が閾値より小さい状態が「一定期間」継続することを考慮してもよい。すなわち、リソース最適化プログラム３０００は、負荷の収束が予測される場合に、対象のテナント１４００の負荷が収束したと判定する。

対象テナント１４００の負荷が収束していない場合、リソース最適化プログラム３０００は、ステップＳ３４００に戻り同様の処理を実行する。

対象テナント１４００の負荷が収束した場合、リソース最適化プログラム３０００は、Ｗｅｂサーバ１４２０のスケールイン処理を実行する（ステップＳ３７００）。Ｗｅｂサーバ１４２０のスケールイン処理は、公知の技術を用いればよい。その後、リソース最適化プログラム３０００は、スケールアップされたＤＢサーバ１４３０を元の状態に戻すための処理、すなわち、スケールダウンするための処理を実行する（ステップＳ３８００）。なお、ステップＳ３８００の処理の詳細は、図１９を用いて後述する。

リソース最適化プログラム３０００は、ステップＳ３８００の処理が完了した後、全ての処理を終了する（ステップＳ３０２０）。なお、実施例１では、ステップＳ３８００の処理が完了した後、処理が終了しているが、ステップＳ３０１０に戻り処理を継続するようなループ処理でもよい。図１では、前述したようなループ処理の場合におけるテナント１４００の状態の遷移を表現している。

図１５に示す処理フローでは、ステップＳ３２００においてＤＢサーバ１４３０のスケールアップ処理の実行中に、さらに、テナント１４００の負荷の増大の予兆が検出された場合に対応することができない。例えば、Ｗｅｂサーバ１４２０の数「２」から「３」に変化したことに伴ってＤＢサーバ１４３０のスケールアップ処理が開始された後、さらに、Ｗｅｂサーバ１４２０の数が「３」から「４」に変化した場合等に対応できない。

前述したような場合には、例えば、図１５の処理を再帰的に実行することによって、段階的にＤＢサーバ１４３０をスケールアップし、負荷の状況に応じて、段階的にＤＢサーバ１４３０をスケールダウンさせることによって対応すればよい。

図１６Ａ及び図１６Ｂは、実施例１のリソース最適化プログラム３０００がステップＳ３２００において実行するＤＢサーバ１４３０のスケールアップ処理の詳細を説明するフローチャートである。

リソース最適化プログラム３０００は、現在、ＤＢサーバ１４３０に割り当てられた計算機リソース量、及びＷｅｂサーバ１４２０の数等のフロントエンド側の情報を取得し、取得された情報及びスケール管理情報Ｔ７００に基づいて不足が予想される計算機リソースを判定する。

例えば、Ｗｅｂサーバ１４２０の数が「２」から「３」に変更された場合、ＤＢサーバ１４３０のＣＰＵの数は「２」から「３」に、メモリ容量は「５ＧＢ」から「７．５ＧＢ」に、ＩＯＰＳは「３００」から「６００」に変更される。そのため、リソース最適化プログラム３０００は、ＣＰＵの数が「１」不足し、メモリ容量が「２．５ＧＢ」不足し、また、ＩＯＰＳが「３００」不足すると判定する。

まず、リソース最適化プログラム３０００は、正側のＤＢサーバ１４３０のＣＰＵが不足するか否かを判定する（ステップＳ３２１０）。ＣＰＵが不足していないと判定された場合、リソース最適化プログラム３０００は、ステップＳ３２２０に進む。

ＣＰＵが不足すると判定された場合、リソース最適化プログラム３０００は、リソース変更方法管理情報Ｔ８００を参照して、正側のＤＢサーバ１４３０に対してＣＰＵに関連する計算機リソースの変更方法を適用する（ステップＳ３２１５）。具体的には、以下のような処理が実行される。

リソース最適化プログラム３０００は、システムテンプレート管理情報Ｔ９００のパターンＩＤ（Ｔ９１０）を参照して、対象のテナント１４００の構築時に使用されたシステムテンプレートの識別子と一致するレコードを検索する。検索されたレコードのＴｂｌ ＩＤ（Ｔ９４０）から識別子を取得する。

リソース最適化プログラム３０００は、リソース変更方法管理情報Ｔ８００のＴｂｌ ＩＤ（Ｔ８１０）が取得された識別子と一致するレコードを検索する。さらに、リソース最適化プログラム３０００は、検索されたレコードの対象（Ｔ８２０）が「ＣＰＵ」かつ分類（Ｔ８４０）が「無停止」である計算機リソースの変更方法を順次適用する。

例えば、変更方法（Ｔ８３０）が「ＣＰＵシェア値変更」の場合、リソース最適化プログラム３０００は、正側のＤＢサーバ１４３０のＣＰＵのシェア値を「高」に変更するように構成変更プログラム２３００に指示する。また、変更方法（Ｔ８３０）が「ＣＰＵ数変更」の場合、リソース最適化プログラム３０００は、不足分のＣＰＵの追加を構成変更プログラム２３００に指示する。

次に、リソース最適化プログラム３０００は、正側のＤＢサーバ１４３０のメモリが不足しているか否かを判定する（ステップＳ３２２０）。メモリが不足していないと判定された場合、リソース最適化プログラム３０００は、ステップＳ３２３０に進む。

メモリが不足していると判定された場合、リソース最適化プログラム３０００は、リソース変更方法管理情報Ｔ８００を参照して、正側のＤＢサーバ１４３０に対してメモリに関連する計算機リソースの変更方法を適用する（ステップＳ３２２５）。

具体的には、リソース最適化プログラム３０００は、リソース変更方法管理情報Ｔ８００から検索されたレコードの対象（Ｔ８２０）が「メモリ」かつ分類（Ｔ８４０）が「無停止」である計算機リソースの変更方法を順次適用する。

例えば、変更方法（Ｔ８３０）が「メモリシェア値変更」の場合、リソース最適化プログラム３０００は、正側のＤＢサーバ１４３０のメモリのシェア値を「高」に変更するように構成変更プログラム２３００に指示する。なお、変更方法（Ｔ８３０）が「メモリ容量変更」である計算機リソースの変更方法は、ＤＢサーバ１４３０を停止させる必要があるため、ステップＳ３２１５では適用されない。

次に、リソース最適化プログラム３０００は、正側のＤＢサーバ１４３０のＩＯＰＳが不足しているか否かを判定する（ステップＳ３２３０）。ＩＯＰＳが不足していないと判定された場合、リソース最適化プログラム３０００は、ステップＳ３２４０に進む。

ＩＯＰＳが不足していると判定された場合、リソース最適化プログラム３０００は、リソース変更方法管理情報Ｔ８００を参照して、正側のＤＢサーバ１４３０及び当該ＤＢサーバ１４３０に対応するＶＭ４１０が利用するボリューム２１０に対して計算機リソースの変更方法を適用する（ステップＳ３２３５）。

具体的には、リソース最適化プログラム３０００は、リソース変更方法管理情報Ｔ８００から検索されたレコードの対象（Ｔ８２０）が「ＩＯＰＳ」かつ分類（Ｔ８４０）が「無停止」である計算機リソースの変更方法を順次適用する。

ＩＯＰＳの変更では、一般にＣＰＵ及びメモリの変更とは異なり、ＶＭ４１０又はＶＭ４１０が動作するハイパバイザ４００、及びストレージ装置２００のそれぞれに対して設定が可能であることが多い。図１４に示す例では、無停止の変更方法として、「ハイパバイザ上のＩＯＰＳ制限値の変更」と「ストレージ装置へＩＯＰＳ値の変更」を示す。

変更方法（Ｔ８３０）が「ハイパバイザ上のＩＯＰＳ制限値の変更」の場合、リソース最適化プログラム３０００は、正側のＤＢサーバ１４３０に対応するＶＭ４１０に対するＩＯＰＳの制限がハイパバイザ４００又は当該ＶＭ４１０に設定されているか否か確認する。ＩＯＰＳの制限が設定され、かつ、設定されているＩＯＰＳの上限値が必要なＩＯＰＳより小さい場合、リソース最適化プログラム３０００は、制限されたＩＯＰＳを緩和するように構成変更プログラム２３００に指示する。

例えば、現在のＩＯＰＳが必要なＩＯＰＳ「６００」より小さい場合、リソース最適化プログラム３０００は、ＩＯＰＳを「６００」に設定するように構成変更プログラム２３００に指示する。

また、変更方法（Ｔ８３０）が「ストレージ装置へＩＯＰＳ値の変更」の場合、リソース最適化プログラム３０００は、正側のＤＢサーバ１４３０に対応するＶＭ４１０が利用するストレージ装置２００及びボリューム２１０について、必要となるＩＯＰＳを確保できるか否か判定する。必要なＩＯＰＳを確保できないと判定された場合、リソース最適化プログラム３０００は、ＩＯＰＳの拡張を構成変更プログラム２３００に指示する。

ここで、図８を用いて具体的な処理について説明する。なお、正側のＤＢサーバ１４３０に対応するＶＭ４１０の識別子は「ＶＭ１３」であるものとし、また、ＩＯＰＳが「３００」から「６００」に増加することが予測されているものとする。

まず、リソース最適化プログラム３０００は、論理物理構成管理情報Ｔ３００に基づいて、対象とするＶＭ４１０が利用するボリューム２１０の総ＩＯＰＳを算出する。この場合、ボリュームＩＤ（Ｔ３３２）が「Ｖｏｌ２」であるボリューム２１０は、「ＶＭ１３」及び「ＶＭ１４」によって利用されているため、総ＩＯＰＳが「６００」と算出される。

「ＶＭ１３」のＩＯＰＳが「３００」から「６００」へ増加することが予測される場合、「Ｖｏｌ２」のボリューム２１０の総ＩＯＰＳ「９００」となる。一方、ストレージ管理情報Ｔ２００のボリュームＩＤ（Ｔ２２０）が「Ｖｏｌ２」である行を参照すると、確保されているＩＯＰＳは「６００」である。そのため、リソース最適化プログラム３０００は、「３００」だけＩＯＰＳが不足することが分かる。したがって、リソース最適化プログラム３０００は、「Ｖｏｌ２」のボリューム２１０に対して「３００」だけＩＯＰＳを増加、すなわち、ＩＯＰＳ（Ｔ２４０）が「９００」となるように構成変更プログラム２３００に指示する。

なお、ストレージ装置２００がＤｙｎａｍｉｃ Ｔｉｅｒｉｎｇ機能を有する場合、リソース最適化プログラム３０００は、その指定方法に応じて、性能指標を「高」に設定するように構成変更プログラム２３００に指示してもよいし、また、ＳＳＤの構成比率が高くなるようにボリューム２１０の構成変更を構成変更プログラム２３００に指示してもよい。

なお、ステップＳ３２１５、ステップＳ３２２５及びステップＳ３２３５の処理では、リソース変更方法管理情報Ｔ８００に登録された計算機リソースの変更方法のうち、条件に一致する計算機リソースの変更方法を全て適用しているが、これに限定されない。

例えば、計算機リソースの変更方法のそれぞれに適用順番を示す優先度が設定されている場合、リソース最適化プログラム３０００は、優先度に基づいて、１つ又は２つ以上の変更方法を選択し、選択されたものを実行してもよい。さらに、複数の計算機リソースの変更方法の間に排他関係が設定されている場合、リソース最適化プログラム３０００は、優先度及び排他関係に基づいて、１つ又は２つ以上の計算機リソースの変更方法を適用してもよい。

なお、ステップＳ３２１５、ステップＳ３２２５及びステップＳ３２３５の処理では、計算機リソースの各々について割当量を変更していたがこれに限定されない。例えば、クラウドサービス１２００によっては、ＶＭ４１０のタイプ（フレーバーとも呼ばれる）として、予め決定されたＣＰＵ、メモリ、及びＩＯＰＳの組み合わせが複数規定されおり、当該タイプを選択することによって性能、すなわち、ＤＢサーバ１４３０の計算機リソースの割当量を変更できる。

このようなクラウドサービス１２００の場合、ＣＰＵ又はメモリ等の１つの計算機リソースについて不足が発生している場合、不足が発生している計算機リソースを確保可能なタイプにしたがった処理を実行することによって、ステップＳ３２１５、ステップＳ３２２５及びステップＳ３２３５と同様の処理を実現できる。また、スケール管理情報Ｔ７００のＤＢサーバ（Ｔ７３０）に、Ｗｅｂサーバ１４２０の数に応じたタイプを設定することによって、前述した処理に対応させることもできる。

なお、実施例１では、ＣＰＵ、メモリ、ＩＯＰＳの順に処理を実行していたが、処理の順番はこれに限定されない。ただし、メモリ及びＩＯＰＳとの間には、メモリ容量を変更することによってボリューム２１０へのＩＯが減るという相関関係が存在するため、処理の順番は、メモリ及びＩＯＰＳの順に実行されることが望ましい。

次に、リソース最適化プログラム３０００は、正側のＤＢサーバ１４３０の計算機リソースの変更後（ステップＳ３２１０からステップＳ３２３５までの処理の完了後）、正側のＤＢサーバ１４３０に対応するＶＭ４１０の再配置処理を実行する（ステップＳ３３００）。これは、正側のＤＢサーバ１４３０に割り当てる計算機リソースをより多く確保するためである。ステップＳ３３００の処理の詳細は、図１７を用いて後述する。

次に、リソース最適化プログラム３０００は、ＤＢサーバ１４３０がＨＡ構成であるか否かを判定する（ステップＳ３２４０）。すなわち、副側のＤＢサーバ１４３０が存在するか否かが判定される。

例えば、リソース最適化プログラム３０００は、システムテンプレート管理情報Ｔ９００の構成（Ｔ９３６）、又は、テナント管理情報Ｔ４００の機能（Ｔ４４０）に基づいて、ＤＢサーバ１４３０がＨＡ構成であるか否かを判定できる。

ＤＢサーバ１４３０がＨＡ構成でないと判定された場合、リソース最適化プログラム３０００は、ステップＳ３２９０に進む。

ＤＢサーバ１４３０がＨＡ構成であると判定された場合、リソース最適化プログラム３０００は、副側のＤＢサーバ１４３０のＣＰＵ、メモリ、及びＩＯＰＳのそれぞれが不足しているか否かを判定する（ステップＳ３２５０、ステップＳ３２６０、ステップＳ３２７０）。ステップＳ３２５０、ステップＳ３２６０、及びステップＳ３２７０の処理は、ステップＳ３２１０、ステップＳ３２２０、及びステップＳ３２３０の処理と同一の処理内容である。ただし、対象が副側のＤＢサーバ１４３０である点が異なる。

ＣＰＵ又はメモリ容量が不足している場合、リソース最適化プログラム３０００は、副側のＤＢサーバ１４３０に対してＣＰＵ又はメモリに関連する計算機リソースの変更方法を適用する（ステップＳ３２５５、ステップＳ３２６５）。また、リソース最適化プログラム３０００は、副側のＤＢサーバ１４３０及び当該ＤＢサーバ１４３０に対応するＶＭ４１０が利用するボリューム２１０に対して計算機リソースの変更方法を適用する（ステップＳ３２７５）。

ステップＳ３２５５及びステップＳ３２６５の処理は、ステップＳ３２１５及びステップＳ３２２５とほぼ同一の処理であるが、以下の点が異なる。まず、対象が副側のＤＢサーバ１４３０である点が異なる。また、ステップＳ３２５５及びステップＳ３２６５の処理では、無停止の変更方法のみが適用されていたが、ステップＳ３２５５及びステップＳ３２６５の処理では、停止の変更方法及び無停止の変更方法のいずれもが適用される。

ステップＳ３２７５の処理は、ステップＳ３２３５の処理とほぼ同一の処理であるが以下の点が異なる。ＨＡ構成の構成方法によっては、正側のＤＢサーバ１４３０及び副側のＤＢサーバ１４３０が同一の記憶領域（ボリューム２１０）を共有している場合があるため、リソース最適化プログラム３０００は、ＨＡ構成に応じて、計算機リソースの変更方法を適用しない場合がある。また、計算機リソースの変更方法が適用される場合には、停止の変更方法及び無停止の変更方法のいずれもが適用される。

なお、ＤＢサーバ１４３０に対応するＶＭ４１０が稼働する物理サーバ１５０においてＣＰＵの数及びメモリ容量を変更するために必要な計算機リソースが確保できない場合、計算機リソースに空きがある他の物理サーバ１５０にＶＭ４１０を移動すればよい。なお、ＶＭ４１０の移動方法は、後述するステップＳ３３００と同一の方法を用いればよい。

ステップＳ３２７０の判定結果が「ＮＯ」又はステップＳ３２７５の処理が完了した後、リソース最適化プログラム３０００は、副側のＤＢサーバ１４３０に対する計算機リソースのシェア値を変更する（ステップＳ３２８０）。

具体的には、リソース最適化プログラム３０００は、副側のＤＢサーバ１４３０に対する計算機リソースのシェア値を下げる。これは、テイクオーバ処理の実行前では、正側のＤＢサーバ１４３０がＷｅｂサーバ１４２０からのアクセスに対する処理を実行しているが、当該処理の実行後は、テイクオーバ処理前に正側のＤＢサーバ１４３０であった副側のＤＢサーバ１４３０に多くの計算機リソースを割り当てる必要がないためである。

そのため、リソース最適化プログラム３０００は、副側のＤＢサーバ１４３０に対応するＶＭ４１０が認識可能なＣＰＵ及びメモリ容量等の計算機リソースはスケールアップさせるが、シェア値を変更することによって実際に割り当てる計算機リソース量を低く設定する。これによって、ハイパバイザ４００は、同一の物理サーバ１５０上で稼働する他のＶＭ４１０に割り当てる計算機リソースを確保することができる。したがって、クラウドサービス１２００全体として計算機リソースを有効に活用することが可能となる。

次に、リソース最適化プログラム３０００は、副側のＤＢサーバ１４３０の配置変更処理を実行する（ステップＳ３３００）。これは、副側のＤＢサーバ１４３０に割り当てる計算機リソースをより多く確保するためである。なお、ステップＳ３３００の処理の詳細は、図１７を用いて後述する。

ステップＳ３２４０の判定結果が「Ｎｏ」又はステップＳ３３００の処理が完了した後、リソース最適化プログラム３０００は、テナント１４００の構成の変更内容を課金プログラム２４００及びポータルプログラム２１００に通知し（ステップＳ３２９０）、その後ステップＳ３４００に進む。

課金プログラム２４００は、リソース最適化プログラム３０００からテナント１４００の構成の変更内容を受け付けると、所定の課金体系にしたがってテナント１４００の利用者１１００に対して課金する。なお、課金プログラム２４００は、正側のＤＢサーバ１４３０の計算機リソースの変更分に対する料金のみを課金してもよいし、また、正側のＤＢサーバ１４３０及び副側のＤＢサーバ１４３０の両方の計算機リソースの変更分に対する料金を課金してもよい。課金の形態は、初期の契約又は事業者が提供するサービスメニューに応じて決定されるものである。

図１７は、実施例１のリソース最適化プログラム３０００が実行するＶＭ４１０の再配置処理を説明するフローチャートである。

図１６Ａ及び図１６Ｂを用いて説明したように、ステップＳ３３００では、シェア値を効果的に利用するために、ハイパバイザ４００間におけるＶＭ４１０の再配置処理が実行される。

シェア値は、物理サーバ１５０が有する計算機リソースを複数のＶＭ４１０に分配する指標である。ハイパバイザ４００上で動作する全てのＶＭ４１０のシェア値が「高」に設定されている場合、いずれのＶＭ４１０にも優先的に計算機リソースを割り当てることができない。すなわち、シェア値を設定しても計算機リソースの効率的な割り当てを実現できない。このような状況を回避するために、正側のＤＢサーバ１４３０に対応するＶＭ４１０の再配置処理が実行される。

副側のＤＢサーバ１４３０に対応するＶＭ４１０は、テイクオーバ処理の実行前は、シェア値が「低」に設定されている。しかし、テイクオーバ処理等によって将来ＶＭ４１０に割り当てられた計算機リソースを最大値まで使用する可能性がある。そのため、ＶＭ４１０に割り当てられた計算機リソースを最大値分確保できない状況を回避するために、副側のＤＢサーバ１４３０に対応するＶＭ４１０の再配置処理が実行される。

なお、ＶＭ４１０を停止させることなく、ハイパバイザ４００間、すなわち、物理サーバ１５０間で移動させる技術として、例えば、ＶＭｏｔｉｏｎ機能がある。ＶＭｏｔｉｏｎ機能では、事前にクラスタ設定がされた複数のハイパバイザの間でＶＭが停止させることなく移動させることが可能な技術である。このような技術を用いることによって、ＶＭ４１０を停止させることなく、ハイパバイザ４００間でＶＭ４１０を移動できる。

なお、シェア値は、同一の物理サーバ１５０上で動作するＶＭ４１０に対する当該物理サーバ１５０の計算機リソースの配分率を決定するものとして用いられているが、他の対象にも適用可能である。例えば、複数の物理サーバ１５０から構成されるクラスタに対してシェア値を適用してもよい。この場合、クラスタに含まれる全ての物理サーバ１５０の計算機リソースの合計値を母数とし、クラスタ内のＶＭ４１０に対する計算機リソースの配分率を決定するものとしてシェア値が用いられる。

まず、リソース最適化プログラム３０００は、正側のＤＢサーバ１４３０に対応するＶＭ４１０の再配置処理であるか否かを判定する（ステップＳ３３１０）。例えば、ステップＳ３２３０又はステップＳ３２３５の処理の後にＶＭ４１０の再配置処理が開始された場合、リソース最適化プログラム３０００は、正側のＤＢサーバ１４３０に対応するＶＭ４１０の再配置処理であると判定する。以下の説明では、再配置処理の対象となるＶＭ４１０を単に対象のＶＭ４１０とも記載する。

正側のＤＢサーバ１４３０に対応するＶＭ４１０の再配置処理であると判定された場合、リソース最適化プログラム３０００は、対象のＶＭ４１０が稼働する物理サーバ１５０上で稼働する他のＶＭ４１０のうち、負荷の増大が予想されるＶＭ４１０が存在するか否かを判定する（ステップＳ３３２０）。

具体的には、リソース最適化プログラム３０００は、論理物理構成管理情報Ｔ３００のサーバＩＤ（Ｔ３３１）が対象のＶＭ４１０が稼働する物理サーバ１５０の識別子と一致するレコードを検索する。これによって、対象のＶＭ４１０が稼働する物理サーバ１５０上で稼働する他のＶＭ４１０の一覧を取得することができる。

リソース最適化プログラム３０００は、検索されたレコードのＣＰＵシェア（Ｔ３２４）、メモリシェア（Ｔ３２５）、及びＩ／Ｏシェア（Ｔ３２５）の値を参照して、負荷の増大が予想されるＶＭ４１０が存在するか否かを判定する。

例えば、リソース最適化プログラム３０００は、対象のＶＭ４１０のシェア値を上げるカラムに着目し、当該カラムに「高」が設定されるＶＭ４１０が存在するか否かを判定する。着目するカラムに「高」が設定されるＶＭ４１０が存在する場合、負荷の増大が予想されるＶＭ４１０が存在すると判定される。

なお、リソース最適化プログラム３０００は、テナント管理情報Ｔ４００の状態（Ｔ４６０）に基づいて前述した判定を行ってもよい。例えば、対象のＶＭ４１０のレコード以外に状態（Ｔ４６０）に「スケールアップ」が設定されたレコードが存在する場合、負荷の増大が予想されるＶＭ４１０が存在すると判定される。

また、リソース最適化プログラム３０００は、性能管理情報Ｔ５００のＳＱＬリクエスト数（Ｔ５５０）に基づいて、ＳＱＬリクエストの増加傾向が検出されるか否かを判定することによって前述した判定を行ってもよい。ＳＱＬリクエストの増加傾向が検出された場合、負荷の増大が予想されるＶＭ４１０が存在すると判定される。

負荷の増大が予想されるＶＭ４１０が存在しないと判定された場合、リソース最適化プログラム３０００は、特に処理を実行することなく、ステップＳ３２４０に進む。この場合、シェア値を「高」に変更しても他のＶＭ４１０に影響がなく、ＶＭ４１０を移動させる必要がないためである。

負荷の増大が予想されるＶＭ４１０が存在すると判定された場合、リソース最適化プログラム３０００は、対象のＶＭ４１０が稼働する物理サーバ１５０とは異なる物理サーバ１５０の中に、対象のＶＭ４１０に必要な計算機リソースを確保できる物理サーバ１５０が存在するか否かを判定する（ステップＳ３３３０）。

ステップＳ３３３０では、各物理サーバ１５０に対してステップＳ３３２０の同一の処理が実行される。例えば、リソース最適化プログラム３０００は、論理物理構成管理情報Ｔ３００を参照し、各物理サーバ１５０上で稼働する全てのＶＭ４１０について、着目するカラムの値を確認する。一つの物理サーバ１５０上で稼働する全てのＶＭ４１０について、着目するカラムに「高」が設定されていない場合、リソース最適化プログラム３０００は、当該物理サーバ１５０を、ＤＢサーバ１４３０に必要な計算機リソースを確保できる物理サーバ１５０と判定する。

ＤＢサーバ１４３０に必要な計算機リソースを確保できる物理サーバ１５０が存在しないと判定された場合、リソース最適化プログラム３０００は、ＶＭ４１０の移動ができないため特に処理を実行することなくステップＳ３２４０に進む。

ＤＢサーバ１４３０に必要な計算機リソースを確保できる物理サーバ１５０が存在すると判定された場合、リソース最適化プログラム３０００は、既存の技術を用いて、対象のＶＭ４１０が稼働する物理サーバ１５０から検索された物理サーバ１５０に当該ＶＭ４１０を停止させることなく移動する（ステップＳ３３４０）。その後、リソース最適化プログラム３０００は、ステップＳ３２４０に進む。

ステップＳ３３１０において、副側のＤＢサーバ１４３０に対応するＶＭ４１０の再配置処理であると判定された場合、リソース最適化プログラム３０００は、副側のＤＢサーバ１４３０が存在するか否かを判定する（ステップＳ３３５０）。例えば、リソース最適化プログラム３０００は、テナント管理情報Ｔ４００の状態（Ｔ４４０）を参照することによって、副側のＤＢサーバ１４３０が存在するか否かを判定する。

副側のＤＢサーバ１４３０が存在しないと判定された場合、リソース最適化プログラム３０００は、ステップＳ３２９０に進む。

副側のＤＢサーバ１４３０が存在すると判定された場合、リソース最適化プログラム３０００は、対象のＶＭ４１０が稼働する物理サーバ１５０が、スケールアップ処理の実行によって新たに割り当てられた計算機リソースを確保できるか否かを判定する（ステップＳ３３６０）。具体的には、以下のような処理が実行される。

リソース最適化プログラム３０００は、論理物理構成管理情報Ｔ３００のサーバＩＤ（Ｔ３３１）が対象のＶＭ４１０が稼働する物理サーバ１５０の識別子と一致するコードを検索する。リソース最適化プログラム３０００は、スケールアップ処理の実行後に追加された計算機リソースのカラム、すなわち、ＣＰＵシェア（Ｔ３２４）、メモリシェア（Ｔ３２５）、及びＩ／Ｏシェア（Ｔ３２５）の値が「高」であるＶＭ４１０を特定する。

リソース最適化プログラム３０００は、特定されたＶＭ４１０について、スケールアップ処理の実行前の計算機リソース量を合計値、及びスケールアップ処理の実行後の計算機リソース量の合計値を算出する。リソース最適化プログラム３０００は、算出されたいずれの合計値もが物理サーバ１５０が有する計算機リソース量より小さいか否かを判定する。

算出されたいずれの合計値もが物理サーバ１５０が有する計算機リソース量より小さい場合、リソース最適化プログラム３０００は、対象のＶＭ４１０が稼働する物理サーバ１５０が、スケールアップ処理の実行によって新たに割り当てられた計算機リソースを確保できると判定する。

対象のＶＭ４１０が稼働する物理サーバ１５０が、スケールアップ処理の実行によって新たに割り当てられた計算機リソースを確保できると判定された場合、リソース最適化プログラム３０００は、ステップＳ３２９０に進む。これは、ＶＭ４１０を移動させなくても必要な計算機リソースを割り当てられない状況が発生しないためである。

対象のＶＭ４１０が稼働する物理サーバ１５０が、スケールアップ処理の実行によって新たに割り当てられた計算機リソースを確保できないと判定された場合、リソース最適化プログラム３０００は、対象のＶＭ４１０が稼働する物理サーバ１５０とは異なる物理サーバ１５０の中に、ＤＢサーバ１４３０に必要な計算機リソースを確保できる物理サーバ１５０が存在するか否かを判定する（ステップＳ３３７０）。ステップＳ３３７０の処理はステップＳ３３３０と同一の処理である。

ＤＢサーバ１４３０に必要な計算機リソースを確保できる物理サーバ１５０が存在しないと判定された場合、リソース最適化プログラム３０００は、ＶＭ４１０の移動ができないため特に処理を実行することなくステップＳ３２９０に進む。

ＤＢサーバ１４３０に必要な計算機リソースを確保できる物理サーバ１５０が存在すると判定された場合、リソース最適化プログラム３０００は、既存の技術を用いて、対象のＶＭ４１０が稼働する物理サーバ１５０から検索された物理サーバ１５０に当該ＶＭ４１０を移動する（ステップＳ３３４０）。その後、リソース最適化プログラム３０００は、ステップＳ３２９０に進む。

なお、稼働する物理サーバ１５０が指定されているケースを考慮してもよい。例えば、論理物理構成管理情報Ｔ３００に、稼働する物理サーバ１５０を固定するか否かを示すフラグを設定するカラムを含めておけばよい。これによって、ＶＭ４１０の再配置処理の開始時点、又は、ステップＳ３３４０若しくはステップＳ３３８０においてＶＭ４１０が指定された物理サーバ１５０から移動しないように制御できる。

また、正側及び副側のＤＢサーバ１４３０に対応する２つのＶＭ４１０を同一の物理サーバ１５０又は同一のクラスタ上で稼働させない旨の条件を考慮することもできる。この場合、ステップＳ３３３０又はステップＳ３３７０の処理において、リソース最適化プログラム３０００は、前述した条件に一致する物理サーバ１５０を移動候補から除外することができる。

図１８は、実施例１のリソース最適化プログラム３０００が実行するテイクオーバ処理を含むＤＢサーバ１４３０のスケールアップ処理の詳細を説明するフローチャートである。

まず、リソース最適化プログラム３０００は、ＤＢサーバ１４３０がＨＡ構成で組まれているか否かを判定する（ステップＳ３５１０）。例えば、リソース最適化プログラム３０００は、テナント管理情報Ｔ４００の機能（Ｔ４４０）又はシステムテンプレート管理情報Ｔ９００の構成（Ｔ９３６）等を参照してＤＢサーバ１４３０がＨＡ構成で組まれているか否かを判定する。

ＤＢサーバ１４３０がＨＡ構成で組まれていない場合、リソース最適化プログラム３０００は、テイクオーバ処理を実行できないため、特に処理を実行することなくステップＳ３６００に進む。

ＤＢサーバ１４３０がＨＡ構成で組まれている場合、リソース最適化プログラム３０００は、副側のＤＢサーバ１４３０に割り当てられた計算機リソースのシェア値を変更する（ステップＳ３５２０）。具体的には、リソース最適化プログラム３０００は、論理物理構成管理情報Ｔ３００を参照して、副側のＤＢサーバ１４３０に対応するＶＭ４１０のレコードのＣＰＵシェア（Ｔ３２４）、メモリシェア（Ｔ３２５）、又はＩ／Ｏシェア（Ｔ３２５）の値を「高」に変更する。このとき、リソース最適化プログラム３０００は、構成変更プログラム２３００等を介して、シェア値の変更をハイパバイザ４００に通知する。

リソース最適化プログラム３０００は、テイクオーバ処理の実行する（ステップＳ３５３０）。具体的には、リソース最適化プログラム３０００は、構成変更プログラム２３００にテイクオーバ処理の実行を指示する。

リソース最適化プログラム３０００は、テイクオーバ処理が完了した後、切り替え後の副側のＤＢサーバ１４３０、すなわち、テイクオーバ処理の実行前の正側のＤＢサーバ１４３０に割り当てられた計算機リソースのシェア値を変更する（ステップＳ３５４０）。具体的には、リソース最適化プログラム３０００は、論理物理構成管理情報Ｔ３００を参照して、テイクオーバ処理の実行後の副側のＤＢサーバ１４３０に対応するＶＭ４１０のレコードのＣＰＵシェア（Ｔ３２４）、メモリシェア（Ｔ３２５）、又はＩ／Ｏシェア（Ｔ３２５）の値を「低」に変更する。このとき、リソース最適化プログラム３０００は、構成変更プログラム２３００等を介して、シェア値の変更をハイパバイザ４００に通知する。

リソース最適化プログラム３０００は、テイクオーバ処理に関する情報を課金プログラム２４００及びポータルプログラム２１００に通知し（ステップＳ３５５０）、その後、ステップＳ３６００に進む。

従量課金、かつ、正側のＤＢサーバ１４３０のみに課金するような課金体系の場合、課金プログラム２４００にＤＢサーバ１４３０に関する情報を通知することによって、テイクオーバ処理に柔軟に追従した課金が可能となる。また、ポータルプログラム２１００が、ポータル２０００にＤＢサーバ１４３０に関する情報を表示することによって、利用者１１００に対して処理の効果等を視覚的に認識させることができる。

なお、本実施例では、ステップＳ３５２０、ステップＳ３５３０、及びステップＳ３５４０の順に処理が実行される。これは、ＤＢサーバ１４３０の性能を確実に確保するためである。

例えば、ステップＳ３５２０の処理を他の処理の後に実行した場合、テイクオーバ処理後に正側のＤＢサーバ１４３０となるＤＢサーバ１４３０に割り当てられた計算機リソースのシェア値は低いままとなっている。この場合、正側のＤＢサーバ１４３０が認識する計算機リソース量は増加しているが、実際に割り当てられている計算機リソースは少ないため、スケールアップ処理（テイクオーバ処理）の効果が得られない。

したがって、前述したような問題を回避するため、本実施例では、ステップＳ３５３０、ステップＳ３５３０、及びステップＳ３５４０の順に処理が実行される。

なお、図１８に示すスケールアップ処理の開始時点において、ステップＳ３２００の処理が完了していない場合、リソース最適化プログラム３０００は、ステップＳ３２００の処理が完了するまで、処理の開始を待ってもよい。また、スケールアップ処理が完了する前に負荷が収束した場合、リソース最適化プログラム３０００は、当該スケールアップ処理をスキップしてもよい。

図１９は、実施例１のリソース最適化プログラム３０００が実行するスケールアップされたＤＢサーバ１４３０に対するスケールダウン処理の詳細を説明するフローチャートである。

まず、リソース最適化プログラム３０００は、ＤＢサーバ１４３０がＨＡ構成で組まれているか否かを判定する（ステップＳ３８１０）。ステップＳ３８１０の処理は、ステップＳ３５１０と同一の処理である。

ＤＢサーバ１４３０がＨＡ構成で組まれていないと判定された場合、リソース最適化プログラム３０００は、正側のＤＢサーバ１４３０に割り当てられた計算機リソースの割当量及びシェア値をスケールアップ処理の実行前の値に戻し（ステップＳ３８６０）、その後、ステップＳ３８５０に進む。例えば、リソース最適化プログラム３０００は、Ｗｅｂサーバ１４２０のスケールイン処理の実行に合わせて、正側のＤＢサーバ１４３０の計算機リソース量を削減する。

ＤＢサーバ１４３０がＨＡ構成で組まれていると判定された場合、リソース最適化プログラム３０００は、副側のＤＢサーバ１４３０の計算機リソース量及びシェア値を、スケールアップ処理の実行前の値に戻す（ステップＳ３８２０）。例えば、リソース最適化プログラム３０００は、スケール管理情報Ｔ７００に基づいて、Ｗｅｂサーバ１４２０のスケールイン処理の実行後のＷｅｂサーバ１４２０の数に応じてＤＢサーバ１４３０の計算機リソース量を戻す。このとき、リソース最適化プログラム３０００は、構成変更プログラム２３００等を介して、シェア値の変更をハイパバイザ４００に通知する。

ＤＢサーバ１４３０の停止が必要な計算機リソースの変更方法が含まれている場合、テイクオーバ処理の実行後に正側のＤＢサーバ１４３０となるＤＢサーバ１４３０の計算機リソースを変更できない可能性がある。そのため、リソース最適化プログラム３０００は、テイクオーバ処理の実行前に、副側のＤＢサーバ１４３０の計算機リソースの状態をスケールアップ処理の実行される前の状態に戻す。

リソース最適化プログラム３０００は、テイクオーバ処理を実行する（ステップＳ３８３０）。これによって、テナント１４００に含まれるＤＢサーバ１４３０は、ステップＳ３２００の処理が実行される前の状態に戻る。

リソース最適化プログラム３０００は、テイクオーバ処理が完了した後、副側のＤＢサーバ１４３０の計算機リソース量及びシェア値を、スケールアップ処理の実行前の値に戻す（ステップＳ３８４０）。このとき、リソース最適化プログラム３０００は、構成変更プログラム２３００等を介して、シェア値の変更をハイパバイザ４００に通知する。

ステップＳ３８４０又はステップＳ３８６０の処理の完了後、リソース最適化プログラム３０００は、現在のテナント１４００の構成情報を課金プログラム２４００及びポータルプログラム２１００に通知し（ステップＳ３８５０）、その後、ステップＳ３０２０に進む。

例えば、従量課金であり、かつ、正側のＤＢサーバ１４３０にのみ課金する課金体系の場合、課金プログラム２４００にＤＢサーバ１４３０に関する情報を通知することによって、スケールダウン処理に柔軟に追従した課金が可能となる。

図２１は、実施例１のテナント１４００の状態を確認するために表示される画面の一例を示す説明図である。

利用者１１００が、例えばＷｅｂブラウザを用いてポータル２０００にアクセスした場合に、図２１に示すような画面２０５０が表示される。

画面２０５０には、利用者１１００が利用するテナント１４００の状態を示す状態情報２０６０及びＯＫボタン２０７０が表示される。状態情報２０６０の表示項目はテナントＩＤ（２０６１）、パターン（２０６２）、種別（２０６３）、及び状態（２０６４）を含む。

テナントＩＤ（２０６１）はテナントＩＤ（Ｔ６２０）と同一のものである。パターン（２０６２）はパターンＩＤ（Ｔ６４０）と同一のものであり、パターン入力２０１１にて選択されたものである。種別（２０６３）は種別（Ｔ６３０）と同一のものであり、種別入力２０１２にて選択されたものである。

状態（２０６４）は、状態（Ｔ４６０）を要約した情報、又はリソース最適化プログラム３０００によって出力されるスケールアップイベント又はスケールダウンイベント等を表示する。また、状態（２０６４）は、テナント１４００を構成するサーバ（ＶＭ４１０）の計算機リソースの状態、例えば、性能管理情報Ｔ５００を表示してもよい。

利用者１１００は、状態情報２０６０を参照することによって、種別（２０６３）に表示された契約形態のテナント１４００が正常に稼働していることを視覚的に確認することができる。

（変形例）
実施例１では、複数のテナントが１つ又は複数の物理サーバ１５０上に混在するマルチテナント環境のクラウドサービスを想定している。しかし、本発明は、１つ又は複数の物理サーバ１５０上に一つのテナント１４００のみが存在するシングルテナントの環境にも適用できる。

また、実施例１では、パブリッククラウド、すなわち、事業者が複数の異なる団体に属する利用者１１００のテナントが混在する環境への適用例を示した。これ以外にもプライベートクラウド、すなわち企業内で情報システム部門が各企業内部門に提供する環境にも適用できる。

また、実施例１では、ＩａａＳを想定しているが、提供形態としてＰａＳＳであってもよい。

また、実施例１では、業務システムとしてＷｅｂ三階層システムを前提としているが、例えば、ステップＳ３４００の処理において、ＤＢサーバ１４３０へのＳＱＬリクエスト数の増加率等を用いることによって、ＤＢサーバ１４３０単体への適用も可能である。また、ＤＢサーバ１４３０は必ずしもＨＡ構成が組まれていなくてもよい。

また、実施例１では、サーバ仮想化環境を前提としているが、物理サーバ１５０そのものを用いてＤＢサーバ１４３０等を構成してもよい。この場合、ＨＡ構成を組んで副側のＤＢサーバ１４３０において、ＤＢサーバ１４３０の停止を伴った計算機リソースの変更を行うことによって、同様の処理を適用することができる。

本発明によれば、フロントエンド側のＷｅｂサーバ１４２０のスケールアウト処理等を契機とし、バックエンド側のＤＢサーバ１４３０をスケールアップ処理が可能とする。これによって、スケールアウトができない構成要素を含む業務システムにおいても、フロントエンド側の処理性能の向上に追従したバックエンド側の処理性能の向上が可能となり、システム全体として自動スケーリングが可能となる。

したがって、例えば、通信販売システムを実現するＷｅｂ三階層システムに本発明を適用した場合、等が通信販売システムを運用する事業者に対して、通信販売の利用者の機会損失等を回避でき、また、当該通信販売システムの投資コストを削減できる。

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

また、上記の各構成、機能、処理部、処理手段等は、それらの一部又は全部を、例えば集積回路で設計する等によりハードウェアで実現してもよい。また、本発明は、実施例の機能を実現するソフトウェアのプログラムコードによっても実現できる。この場合、プログラムコードを記録した記憶媒体をコンピュータに提供し、そのコンピュータが備えるプロセッサが記憶媒体に格納されたプログラムコードを読み出す。この場合、記憶媒体から読み出されたプログラムコード自体が前述した実施例の機能を実現することになり、そのプログラムコード自体、及びそれを記憶した記憶媒体は本発明を構成することになる。このようなプログラムコードを供給するための記憶媒体としては、例えば、フレキシブルディスク、ＣＤ−ＲＯＭ、ＤＶＤ−ＲＯＭ、ハードディスク、ＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）、光ディスク、光磁気ディスク、ＣＤ−Ｒ、磁気テープ、不揮発性のメモリカード、ＲＯＭ等が用いられる。

また、本実施例に記載の機能を実現するプログラムコードは、例えば、アセンブラ、Ｃ／Ｃ＋＋、ｐｅｒｌ、Ｓｈｅｌｌ、ＰＨＰ、Ｊａｖａ（Ｊａｖａは登録商標）等の広範囲のプログラム又はスクリプト言語で実装できる。

さらに、実施例の機能を実現するソフトウェアのプログラムコードを、ネットワークを介して配信することによって、それをコンピュータのハードディスクやメモリ等の記憶手段又はＣＤ−ＲＷ、ＣＤ−Ｒ等の記憶媒体に格納し、コンピュータが備えるプロセッサが当該記憶手段や当該記憶媒体に格納されたプログラムコードを読み出して実行するようにしてもよい。

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

１００ 管理サーバ
１５０ 物理サーバ
２００ ストレージ装置
４００ ハイパバイザ
４１０ ＶＭ
１２００ クラウドサービス
１４００ テナント
１４１０ ロードバランサ
１４２０ Ｗｅｂサーバ
１４３０ ＤＢサーバ
１４４０ ストレージ装置
２０００ ポータル
Ｔ１００ 物理サーバ管理情報
Ｔ２００ ストレージ管理情報
Ｔ３００ 論理物理構成管理情報
Ｔ４００ テナント管理情報
Ｔ５００ 性能管理情報
Ｔ６００ 顧客管理情報
Ｔ７００ スケール管理情報
Ｔ８００ リソース変更方法管理情報
Ｔ９００ システムテンプレート管理情報

Claims (15)

1. 複数の計算機を備える計算機システムであって、
   前記複数の計算機は、前記計算機システムを管理する少なくとも一つの第１の計算機、ユーザの業務に使用する業務システムを構築するための計算機リソースを提供する複数の第２の計算機を含み、
   前記第１の計算機は、第１のプロセッサ、前記第１のプロセッサに接続される第１のメモリ、及び前記第１のプロセッサに接続される第１のインタフェースを有し、
   前記複数の第２の計算機の各々は、第２のプロセッサ、前記第２のプロセッサに接続される第２のメモリ、前記第２のプロセッサに接続される第２のインタフェース、及び記憶装置を有し、
   前記業務システムは、スケールアウト処理を実行することによって処理性能を変更できる少なくとも一つの第１の業務計算機、及びスケールアップ処理を実行することによって処理性能を変更できる複数の第２の業務計算機を含み、
   前記複数の第２の業務計算機は、実行系の第２の業務計算機及び待機系の第２の業務計算機を含むクラスタを構成し、
   前記第１の計算機は、
   第２の業務計算機に対する前記計算機リソースの割り当ての変更を制御するための複数のリソース変更方法を管理し、前記複数のリソース変更方法に基づいて前記第２の業務計算機に対する前記計算機リソースの割当てを変更するリソース最適化部を有し、
   前記リソース最適化部は、
   前記業務システムの負荷を監視し、
   前記実行系の第２の業務計算機の負荷の増大の予兆を検出した場合、前記実行系の第２の業務計算機及び前記待機系の第２の業務計算機に処理負荷が低いリソース変更方法を適用する第１の処理を実行し、
   前記実行系の第２の業務計算機の負荷を示す値が所定の閾値以上になった場合、前記実行系の第２の業務計算機及び前記待機系の第２の業務計算機に処理負荷が高いリソース変更方法を適用する第２の処理を実行することを特徴とする計算機システム。
2. 請求項１に記載の計算機システムであって、
   前記複数のリソース変更方法は、前記計算機リソースの種別毎の第２の業務計算機の再起動を伴わない複数の第１のリソース変更方法、及び前記計算機リソースの種別毎の前記第２の業務計算機の再起動を伴う複数の第２のリソース変更方法を含み、
   前記第１の処理では、
   前記リソース最適化部が、前記少なくとも一つの第１の業務計算機の負荷の増大を前記実行系の第２の業務計算機の負荷の増大の予兆として検出し、
   前記リソース最適化部が、前記実行系の第２の業務計算機における変更対象の前記計算機リソースの種別を特定して、前記特定された計算機リソースの種別に対応する第１のリソース変更方法を前記実行系の第２の業務計算機に適用し、
   前記リソース最適化部が、前記待機系の第２の業務計算機における変更対象の前記計算機リソースの種別を特定して、前記特定された計算機リソースの種別に対応する第２のリソース変更方法を前記待機系の第２の業務計算機に適用し、
   前記第２の処理では、前記リソース最適化部が、前記第１の計算機リソース変更方法が適用された前記実行系の第２の業務計算機と、前記第２の計算機リソース変更方法が適用された前記待機系の第２の業務計算機とを切り替える第１の切替処理を実行することを特徴とする計算機システム。
3. 請求項２に記載の計算機システムであって、
   前記リソース最適化部は、
   前記第１の処理及び前記第２の処理が実行された後に、前記第１の切替処理後の前記実行系の第２の業務計算機の負荷を示す値が所定の閾値より小さくなった場合、前記第１の切替処理後の前記待機系の第２の業務計算機に適用された前記リソース変更方法に応じて、当該リソース変更方法が適用される前の状態に変更するための前記第２のリソース変更方法を当該待機系の第２の業務計算機に適用し、
   前記第１の切替処理後の前記実行系の第２の業務計算機と、前記第２の計算機リソース変更方法が適用された前記第１の切替処理後の前記待機系の第２の業務計算機とを切り替える第２の切替処理を実行し、
   前記第２の切替処理の実行後の前記待機系の第２の業務計算機に適用された前記リソース変更方法に応じて、当該リソース変更方法が適用される前の状態に変更するための前記第２のリソース変更方法を当該待機系の第２の業務計算機に適用することを特徴とする計算機システム。
4. 請求項３に記載の計算機システムであって、
   前記複数の第２の計算機の各々は、前記計算機リソースを論理的に分割することによって生成された仮想計算機を管理する仮想化部を有し、
   第１の業務計算機及び第２の業務計算機は前記仮想計算機を用いて実現され、
   前記仮想化部は、当該仮想化部が管理する複数の仮想計算機に対する前記計算機リソースの配分率を決定するためのシェア値を設定し、
   前記第１のリソース変更方法は、前記特定された計算機リソースの種別における前記シェア値を変更する変更方法であることを特徴とする計算機システム。
5. 請求項４に記載の計算機システムであって、
   前記リソース最適化部は、
   前記第２のリソース変更方法が適用された前記待機系の第２の業務計算機に対する前記計算機リソースの配分率が最も低くなるように前記シェア値を変更し、
   前記第１の切替処理が実行された後の前記実行系の第２の業務計算機に対する前記計算機リソースの配分率が最も高くなるように前記シェア値を変更することを特徴とする計算機システム。
6. 請求項４に記載の計算機システムであって、
   前記第１の処理では、
   前記リソース最適化部が、前記特定された計算機リソースの種別に対応する第１のリソース変更方法を前記実行系の第２の業務計算機に適用した後、前記シェア値に基づいて、前記実行系の第２の業務計算機を実現する前記仮想計算機を、当該仮想計算機が稼働する第２の計算機から他の第２の計算機に移動させるか否かを決定することを特徴とする計算機システム。
7. 請求項１に記載の計算機システムであって、
   前記第１の計算機は、前記業務システムの利用者の利用金額を算出する課金部を有し、
   前記リソース最適化部は、前記第１の処理又は前記第２の処理の実行後に処理の結果を前記課金部に通知し、
   前記課金部は、前記通知された処理の結果に基づいて前記業務システムの利用者に対する利用金額を算出することを特徴とする計算機システム。
8. 請求項１に記載の計算機システムであって、
   前記第１の計算機は、前記業務システムを利用するユーザに、前記第１の処理又は前記第２の処理が実行された後の前記業務システムの状態を通知するためのユーザインタフェースを有することを特徴とする計算機システム。
9. 複数の計算機を備える計算機システムにおける計算機リソースの割当て管理方法であって、
   前記複数の計算機は、前記計算機システムを管理する少なくとも一つの第１の計算機、ユーザの業務に使用する業務システムを構築するための計算機リソースを提供する複数の第２の計算機を含み、
   前記第１の計算機は、第１のプロセッサ、前記第１のプロセッサに接続される第１のメモリ、及び前記第１のプロセッサに接続される第１のインタフェースを有し、
   前記複数の第２の計算機の各々は、第２のプロセッサ、前記第２のプロセッサに接続される第２のメモリ、前記第２のプロセッサに接続される第２のインタフェース、及び記憶装置を有し、
   前記業務システムは、スケールアウト処理を実行することによって処理性能を変更できる少なくとも一つの第１の業務計算機、及びスケールアップ処理を実行することによって処理性能を変更できる複数の第２の業務計算機を含み、
   前記複数の第２の業務計算機は、実行系の第２の業務計算機及び待機系の第２の業務計算機を含むクラスタを構成し、
   前記第１の計算機は、
   第２の業務計算機に対する前記計算機リソースの割り当ての変更を制御するための複数のリソース変更方法を管理し、前記複数のリソース変更方法に基づいて前記第２の業務計算機に対する前記計算機リソースの割当てを変更するリソース最適化部を有し、
   前記計算機リソースの割当て管理方法は、
   前記リソース最適化部が、前記業務システムの負荷を監視する第１のステップと、
   前記リソース最適化部が、前記実行系の第２の業務計算機の負荷の増大の予兆を検出した場合、前記実行系の第２の業務計算機及び前記待機系の第２の業務計算機に処理負荷が低いリソース変更方法を適用する第２のステップと、
   前記リソース最適化部が、前記実行系の第２の業務計算機の負荷を示す値が所定の閾値以上になった場合、前記実行系の第２の業務計算機及び前記待機系の第２の業務計算機に処理負荷が高いリソース変更方法を適用する第３のステップと、を含むことを特徴とする計算機リソースの割当て管理方法。
10. 請求項９に記載の計算機リソースの割当て管理方法であって、
    前記複数のリソース変更方法は、前記計算機リソースの種別毎の第２の業務計算機の再起動を伴わない複数の第１のリソース変更方法、及び前記計算機リソースの種別毎の前記第２の業務計算機の再起動を伴う複数の第２のリソース変更方法を含み、
    前記第２のステップは、
    前記リソース最適化部が、前記少なくとも一つの第１の業務計算機の負荷の増大を前記実行系の第２の業務計算機の負荷の増大の予兆として検出する第４のステップと、
    前記リソース最適化部が、前記実行系の第２の業務計算機における変更対象の前記計算機リソースの種別を特定して、前記特定された計算機リソースの種別に対応する第１のリソース変更方法を前記実行系の第２の業務計算機に適用する第５のステップと、
    前記リソース最適化部が、前記待機系の第２の業務計算機における変更対象の前記計算機リソースの種別を特定して、前記特定された計算機リソースの種別に対応する第２のリソース変更方法を前記待機系の第２の業務計算機に適用する第６のステップと、を含み、
    前記第３のステップは、前記リソース最適化部が、前記第１の計算機リソース変更方法が適用された前記実行系の第２の業務計算機と、前記第２の計算機リソース変更方法が適用された前記待機系の第２の業務計算機とを切り替える第１の切替処理を実行する第７のステップを含むことを特徴とする計算機リソースの割当て管理方法。
11. 請求項１０に記載の計算機リソースの割当て管理方法であって、
    前記リソース最適化部が、前記第１の切替処理後の前記実行系の第２の業務計算機の負荷を示す値が所定の閾値より小さくなった場合、前記第１の切替処理後の前記待機系の第２の業務計算機に適用された前記リソース変更方法に応じて、当該リソース変更方法が適用される前の状態に変更するための前記第２のリソース変更方法を当該待機系の第２の業務計算機に適用するステップ、
    前記リソース最適化部が、前記第１の切替処理後の前記実行系の第２の業務計算機と、前記第２の計算機リソース変更方法が適用された前記第１の切替処理後の前記待機系の第２の業務計算機とを切り替える第２の切替処理を実行するステップと、
    前記リソース最適化部が、前記第２の切替処理の実行後の前記待機系の第２の業務計算機に適用された前記リソース変更方法に応じて、当該リソース変更方法が適用される前の状態に変更するための前記第２のリソース変更方法を当該待機系の第２の業務計算機に適用するステップと、を含むことを特徴とする計算機リソースの割当て管理方法。
12. 請求項１１に記載の計算機リソースの割当て管理方法であって、
    前記複数の第２の計算機の各々は、前記計算機リソースを論理的に分割することによって生成された仮想計算機を管理する仮想化部を有し、
    第１の業務計算機及び第２の業務計算機は前記仮想計算機を用いて実現され、
    前記仮想化部は、当該仮想化部が管理する複数の仮想計算機に対する前記計算機リソースの配分率を決定するためのシェア値を設定し、
    前記第１のリソース変更方法は、前記特定された計算機リソースの種別における前記シェア値を変更する変更方法であることを特徴とする計算機リソースの割当て管理方法。
13. 請求項１２に記載の計算機リソースの割当て管理方法であって、
    前記第６のステップは、前記第２のリソース変更方法が適用された前記待機系の第２の業務計算機に対する前記計算機リソースの配分率が最も低くなるように前記シェア値を変更するステップを含み、
    前記第７のステップは、前記第１の切替処理が実行された後の前記実行系の第２の業務計算機に対する前記計算機リソースの配分率が最も高くなるように前記シェア値を変更するステップを含むことを特徴とする計算機リソースの割当て管理方法。
14. 請求項１２に記載の計算機リソースの割当て管理方法であって、
    前記第５のステップは、前記シェア値に基づいて、前記実行系の第２の業務計算機を実現する前記仮想計算機を、当該仮想計算機が稼働する第２の計算機から他の第２の計算機に移動させるか否かを決定するステップを含むことを特徴とする計算機リソースの割当て管理方法。
15. 請求項９に記載の計算機リソースの割当て管理方法であって、
    前記第１の計算機は、前記業務システムの利用者の利用金額を算出する課金部を有し、
    前記計算機リソースの割当て管理方法は、
    前記リソース最適化部が、前記第１の処理又は前記第２の処理の実行後に処理の結果を前記課金部に通知するステップと、
    前記課金部が、前記通知された処理の結果に基づいて前記業務システムの利用者に対する利用金額を算出するステップと、を含むことを特徴とする計算機リソースの割当て管理方法。

Images