(57)【要約】【課題】システムの性能の予測の精度を高める。【解決手段】サーバ装置は、情報処理システムが提供するサービスが利用する仮想環境のリソースを管理する。サーバ装置は、負荷計測部と、負荷予測部と、性能計測部と、除去部と、性能予測部と、リソース制御部と、を備える。負荷計測部は、サービスに掛かる負荷を計測する。負荷予測部は、計測された負荷に基づいて、サービスに掛かる将来の負荷を予測する。性能計測部は、サービスの性能を計測する。除去部は、計測された性能から、計測された負荷による影響を除去する。性能予測部は、負荷による影響が除去された性能に基づいて、サービスの将来の性能を予測する。リソース制御部は、予測された負荷と、予測された性能とに基づいて、リソースを制御する。【選択図】図２
2018084986.tif 000002
【特許請求の範囲】
【請求項１】
情報処理システムが提供するサービスが利用する仮想環境のリソースを管理するサーバ装置であって、
前記サービスに掛かる負荷を計測する負荷計測部と、
計測された負荷に基づいて、前記サービスに掛かる将来の負荷を予測する負荷予測部と、
前記サービスの性能を計測する性能計測部と、
計測された性能から、計測された負荷による影響を除去する除去部と、
負荷による影響が除去された性能に基づいて、前記サービスの将来の性能を予測する性能予測部と、
予測された負荷と、予測された性能とに基づいて、前記リソースを制御するリソース制御部と、
を備えるサーバ装置。
【請求項２】
前記リソースは、仮想マシンおよびコンテナの少なくとも一方の個数であり、
前記リソース制御部は、予測された負荷と、予測された性能とに基づいて、前記仮想マシンおよび前記コンテナの少なくとも一方の個数を制御する、
請求項１に記載のサーバ装置。
【請求項３】
前記リソースは、仮想マシンおよびコンテナの少なくとも一方に割り当てる物理リソースであり、
前記リソース制御部は、予測された負荷と、予測された性能とに基づいて、前記仮想マシンおよび前記コンテナの少なくとも一方に割り当てる物理リソースを制御する、
請求項１に記載のサーバ装置。
【請求項４】
前記負荷予測部は、現在時刻から仮想環境の起動に要する時間が経過した後の負荷を予測し、
前記性能予測部は、現在時刻から仮想環境の起動に要する時間が経過した後の性能を予測する、
請求項１に記載のサーバ装置。
【請求項５】
前記情報処理システムは、前記仮想環境に掛かる負荷を分散する負荷分散部を備え、
前記リソース制御部により制御される前記リソースの情報を前記負荷分散部に送信する分散制御部をさらに備える、
請求項１に記載のサーバ装置。
【請求項６】
情報処理システムが提供するサービスが利用する仮想環境のリソースを管理するコンピュータを、
前記サービスに掛かる負荷を計測する負荷計測部と、
計測された負荷に基づいて、前記サービスに掛かる将来の負荷を予測する負荷予測部と、
前記サービスの性能を計測する性能計測部と、
計測された性能から、計測された負荷による影響を除去する除去部と、
負荷による影響が除去された性能に基づいて、前記サービスの将来の性能を予測する性能予測部と、
予測された負荷と、予測された性能とに基づいて、前記リソースを制御するリソース制御部、
として機能させるためのプログラム。
【請求項７】
仮想環境を利用するサービスを提供する情報処理システムと、
前記仮想環境のリソースを管理するサーバ装置と、を備え、
前記サーバ装置は、
前記サービスに掛かる負荷を計測する負荷計測部と、
計測された負荷に基づいて、前記サービスに掛かる将来の負荷を予測する負荷予測部と、
前記サービスの性能を計測する性能計測部と、
計測された性能から、計測された負荷による影響を除去する除去部と、
負荷による影響が除去された性能に基づいて、前記サービスの将来の性能を予測する性能予測部と、
予測された負荷と、予測された性能とに基づいて、前記リソースを制御するリソース制御部と、を備える
通信システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明の実施形態は、サーバ装置、プログラム、および、通信システムに関する。
【背景技術】
【０００２】
クラウドコンピューティングが普及している。クラウドコンピューティングの実現形態の１つは、パブリッククラウドである。パブリッククラウドは、仮想マシン（ＶＭ;Virtual  Machine）などの仮想環境により実現される場合がある。また、利用するＶＭの個数を制御するＶＭスケーリングという手法が知られている。例えば、システムの応答時間の変化をモニタリングし、応答時間が増加傾向であればＶＭを増やし、応答時間が減少傾向であればＶＭを減らす技術が知られている。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２０１５−１９４９５８号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
しかしながら、従来技術では、必要なＶＭ数の見積もりの精度が低く、応答時間の目標性能が達成できない状態が発生しやすいという問題がある。
【課題を解決するための手段】
【０００５】
実施形態のサーバ装置は、情報処理システムが提供するサービスが利用する仮想環境のリソースを管理する。サーバ装置は、負荷計測部と、負荷予測部と、性能計測部と、除去部と、性能予測部と、リソース制御部と、を備える。負荷計測部は、サービスに掛かる負荷を計測する。負荷予測部は、計測された負荷に基づいて、サービスに掛かる将来の負荷を予測する。性能計測部は、サービスの性能を計測する。除去部は、計測された性能から、計測された負荷による影響を除去する。性能予測部は、負荷による影響が除去された性能に基づいて、サービスの将来の性能を予測する。リソース制御部は、予測された負荷と、予測された性能とに基づいて、リソースを制御する。
【図面の簡単な説明】
【０００６】
【図１】本実施形態の通信システムのブロック図。
【図２】管理サーバのブロック図。
【図３】負荷履歴記憶部に記憶される情報のデータ構造を示す図。
【図４】負荷履歴記憶部に記憶される情報のデータ構造を示す図。
【図５】外部負荷と応答時間との関係の一例を示す図。
【図６】性能履歴記憶部に記憶される情報のデータ構造を示す図。
【図７】リソース制御処理のフローチャート。
【図８】ＶＭ数の算出処理のフローチャート。
【図９】サーバ装置のハードウェア構成図。
【発明を実施するための形態】
【０００７】
以下に添付図面を参照して、この発明にかかるサーバ装置の好適な実施形態を詳細に説明する。
【０００８】
ＶＭを用いたパブリッククラウドは、例えば以下のように利用される。ユーザは、パブリッククラウドのプロバイダに対して、ＶＭの作成要求を送る。ＶＭは、ソフトウェアにより実現される仮想的な計算機である。パブリッククラウドのプロバイダは、自身が保持する物理マシン（ＰＭ;Physical  Machine）群の中から、ＶＭを作成するＰＭを選び、ＶＭを作成する。ユーザは、作成されたＶＭの上で、自身が作成したアプリケーションを動かすことができる。ユーザは、ＶＭの利用料金をプロバイダに支払う。利用料金は、利用したＶＭの数、ＶＭを利用した時間、および、ＶＭの通信料などから決まる。ユーザは、不要になったＶＭを削除することもできる。
【０００９】
パブリッククラウドを利用してユーザが実現するシステム（例えば複数のアプリケーションにより構成されるシステム）には、性能要件が定められる。例えば、ウェブアプリケーションシステムであれば「応答時間」が性能要件となる。ユーザは、性能要件を満たすために、必要最低限の数および性能のＶＭを作成しようとする。それが、ＶＭの利用料金の低減につながるためである。
【００１０】
ユーザが実現するシステムの性能は、一定とは限らない。例えば、ウェブアプリケーションシステムであれば、単位時間あたりのシステムに対するリクエストの数が多くなると、性能が下がる。そして、単位時間あたりのリクエスト数は一定ではないため、システムの性能は変動する。この結果、性能要件を満たせない時間帯が生じる可能性がある。
【００１１】
また、パブリッククラウドでは、異なるユーザのＶＭが、同一のＰＭ上で動作する場合がある。例えば、ユーザＡのＶＭと、ユーザＢのＶＭが、同一の物理マシン上で動作する場合がある。このとき、ユーザＡのアプリケーションの性能と、ユーザＢのアプリケーションの性能は、互いに影響を与える。そして、ユーザＡとユーザＢは、互いのアプリケーションの負荷の特性がわからない。これも、システムの性能の変動要因の１つである。
【００１２】
さらに、パブリッククラウドのプロバイダの都合により、ユーザのＶＭが、別のＰＭに勝手に移動させられる場合がある。ＶＭのＰＭ間の移動は、ライブマイグレーションと呼ばれる技術により可能である。移動中のＶＭの性能は低下する。これも、システムの性能の変動要因の１つである。
【００１３】
以降、パブリッククラウドの外を「外部」、パブリッククラウドの中を「内部」とみなし、システムの外部を要因とするシステムへの負荷を「外部負荷」と呼ぶ。また、システムの内部を要因とするシステムへの負荷を「内部負荷」と呼ぶ。例えば、システムに対するリクエストは、「外部負荷」の一例である。また、他ユーザのＶＭの処理、および、ＶＭのライブマイグレーションは、「内部負荷」の一例である。
【００１４】
上述のＶＭスケーリングは、例えば、性能要件を満たせない時間帯を減らしつつ、かつ、ＶＭの利用料金を低減するために用いられる。従来のＶＭスケーリングでは、システムの性能の指標である「応答時間」を時系列データとして扱い、その変動を予測し、予測結果に基づいてＶＭ数を増減する。このような技術では、「外部負荷」および「内部負荷」を区別せずに応答時間を予測しているため、必要なＶＭ数の見積もりの精度が低くなる場合がある。
【００１５】
一般的に、時系列データの予測では、時系列データを分解したほうが、予測の精度が高くなる。分解することで、時系列データのノイズを除去できたり、個々の時系列データに最適な予測アルゴリズムを適用できたりするためである。
【００１６】
そこで本実施形態では、パブリッククラウドなどの仮想環境を用いた通信システムにおいて、外部負荷と内部負荷を区別して考慮してシステムの性能を予測し、予測結果に基づいて仮想環境のリソースを制御する。これにより、従来技術と比較して、システムの性能の予測の精度が高くなる。また、リソースを適切に調節できるようになり、システムの性能を安定させることが可能となる。
【００１７】
なお、パブリッククラウドなどを利用する場合は、プロバイダが異なることなどに起因して、内部負荷を計測できない場合がある。このため、本実施形態では、内部負荷が存在しない状況での性能を事前に求めておき、この性能と外部負荷による影響を含む性能の計測値とから、内部負荷による変動成分のみを持つ性能を算出する。
【００１８】
以下では、パブリッククラウド（情報処理システムの一例）と、パブリッククラウドを利用する仮想環境（例えばＶＭ）を管理する管理サーバ（サーバ装置の一例）とを含む通信システムを例に説明する。情報処理システムはパブリッククラウドに限られず、仮想環境を利用してサービスを提供するシステムであればどのようなシステムであってもよい。またＶＭは仮想環境の一例であり、コンテナなどのＶＭ以外の仮想環境に対しても本実施形態を適用できる。
【００１９】
図１は、本実施形態の通信システムの構成例を示すブロック図である。図１に示すように、本実施形態の通信システムは、サーバ装置としての管理サーバ１００と、情報処理装置としてのパブリッククラウド２００と、クライアント３００と、を含む。
【００２０】
パブリッククラウド２００は、ロードバランサ（ＬＢ）２０１と、ＶＭ群２１０と、を備えている。ＶＭ群２１０は、複数のＶＭ２１１、２１２、２１３を含む。なおＶＭの個数は３に限られず、任意である。各ＶＭ上では、任意のアプリケーションが動作する。クライアント３００は、各ＶＭ上で動作するアプリケーションにアクセスして利用する別のアプリケーションなどが動作する。
【００２１】
以下では、各ＶＭ上でウェブアプリケーションサーバ（ＷｅｂＡＳ）が動作し、クライアント３００でウェブブラウザが動作する場合を例に説明する。
【００２２】
クライアント３００（ウェブブラウザ）は、例えば、ＶＭ上のＷｅｂＡＳに対してＨＴＴＰ（Hypertext  Transfer  Protocol）リクエストを送信する。このＨＴＴＰリクエストを、外部負荷とする。
【００２３】
ＬＢ２０１は、各ＷｅｂＡＳの負荷を均等にするための機能である。すなわちＬＢ２０１は、各ＶＭに掛かる負荷を分散する負荷分散部として機能する。なおＬＢ２０１の機能は、パブリッククラウド２００のプロバイダがサービスとして提供する場合もあるし、ＶＭのユーザが自ら構築する場合もある。ＬＢ２０１は、クライアント３００からのＨＴＴＰリクエストを受信し、いずれのＷｅｂＡＳに転送するかを決定し、転送する。転送先の決め方はどのような方法であってもよい。例えばＬＢ２０１は、各ＷｅｂＡＳの負荷が均等になるように、ＨＴＴＰリクエストの転送先を決定する。
【００２４】
次に管理サーバ１００の機能の詳細について説明する。管理サーバ１００は、各アプリケーション（本実施形態ではＷｅｂＡＳ）に送られてくるＨＴＴＰリクエスト（外部負荷）、および、アプリケーションの性能の両方を計測する。本実施形態では、管理サーバ１００は、計測したアプリケーションの性能から外部負荷による性能変動成分を除去し、変動成分を除去した性能を用いて必要なＶＭ数を予測する。
【００２５】
図２は、管理サーバ１００の内部構成の一例を示すブロック図である。図２に示すように、管理サーバ１００は、負荷計測部１０１と、性能計測部１０２と、除去部１０３と、負荷履歴記憶部１２１と、負荷予測部１０４と、性能履歴記憶部１２２と、性能予測部１０５と、算出部１０６と、リソース制御部１０７と、分散制御部１０８と、を備えている。
【００２６】
負荷計測部１０１は、パブリッククラウドが提供するサービスに掛かる負荷を計測する。例えば負荷計測部１０１は、単位時間ごとに、外部負荷（ＨＴＴＰリクエスト）を計測する。例えば、１秒ごとに計測するなら、１秒間に発生したＨＴＴＰリクエスト数（ＲＰＳ;Request  Per  Second）が外部負荷となる。計測方法は、例えば、各ＷｅｂＡＳにて受信したＨＴＴＰリクエスト数を数える方法を適用できる。これによりＲＰＳを算出できるため、負荷計測部１０１は、各ＷｅｂＡＳからＲＰＳを取得できる。外部負荷の計測方法はこれに限られるものではなく任意の方法を適用できる。例えば、リクエストのサイズなども考慮して外部負荷を計測してもよい。
【００２７】
負荷履歴記憶部１２１は、計測された負荷を記憶する。図３は、負荷履歴記憶部１２１に記憶される情報のデータ構造の一例を示す図である。図３に示すように、例えば負荷履歴記憶部１２１は、計測された外部負荷を、ＶＭの識別情報（ＶＭ  ＩＤ）と、時刻情報とともに記憶する。これにより、外部負荷が時系列データとなる。
【００２８】
また、負荷履歴記憶部１２１は、全ＶＭに対して発生した外部負荷を合計し、合計した値（総外部負荷）を時刻情報とともに記憶する。図４は、このように記憶した情報のデータ構造の一例を示す図である。この情報も時系列データとなる。
【００２９】
負荷予測部１０４は、計測された負荷に基づいて、サービスに掛かる将来の負荷を予測する。例えば負荷予測部１０４は、負荷履歴記憶部１２１に記憶されている外部負荷を用いて、将来の外部負荷を予測する。負荷予測部１０４は、各ＶＭに対する外部負荷と、全ＶＭに対する外部負荷の両方を予測する。負荷予測部１０４による予測方法はどのような方法であってもよい。例えば、移動平均（Moving  Average）を予測値とする方法、および、自己回帰移動平均（Auto  Regressive  Moving  Average）により予測する方法などを適用できる。外部負荷の変動の特徴に応じて、適切な予測の方法を選べばよい。
【００３０】
また、どこまで将来を予測するか、および、予測の単位は、任意である。例えば、１分先まで、１秒単位で予測してもよいし、１０分先まで１分単位で予測してもよい。ＶＭの起動にかかる時間を考慮する方法もある。すなわち負荷予測部１０４は、現在時刻からＶＭの起動に要する時間が経過した後の負荷を予測してもよい。例えばパブリッククラウド２００に「ＶＭ作成の要求」を送信してから、ＶＭの作成が完了するまでは、数十秒から数分を要する場合がある。管理サーバ１００を運用する過程で、ＶＭ作成に要した時間を計測して記憶しておけば、負荷予測部１０４は、ＶＭ作成に必要な時間の平均値を算出できる。負荷予測部１０４は、例えば、現在時刻に、算出した平均値を加えた時刻の外部負荷を予測してもよい。
【００３１】
性能計測部１０２は、サービスの性能を計測する。例えば性能計測部１０２は、単位時間ごとにアプリケーションの性能を計測する。アプリケーションとしてＷｅｂＡＳを用いる場合であれば、性能計測部１０２は、例えばＷｅｂＡＳの性能として、単位時間ごとの応答時間の平均値を計測する。応答時間とは、ＷｅｂＡＳがＨＴＴＰリクエストを受信してから、ＨＴＴＰレスポンスを返すまでの時間である。例えば、１秒ごとに性能を計測する場合、性能計測部１０２は、１秒間に受信した各ＨＴＴＰリクエストに対する応答時間の平均値を、性能として計測する。ＷｅｂＡＳ（ＶＭ）が５個あれば、単位時間ごとに５個の計測値が得られる。
【００３２】
除去部１０３は、性能計測部１０２により計測された性能から、負荷計測部１０１により計測された負荷による影響（外部負荷による変動成分）を除去する。この結果、得られる性能は、内部負荷による変動成分のみを持つ性能となる。
【００３３】
本実施形態では、外部負荷による変動成分除去のために、内部負荷が存在しない環境において、事前に以下の情報を把握しておく。
・単位時間あたりに処理できる外部負荷の最大量
・外部負荷と性能の関係
【００３４】
これらの情報は、パブリッククラウド２００で作成する予定のＶＭと同等の性能を持つＰＭを用意し、簡単な評価試験を行うことで把握できる。評価試験用のＰＭを選ぶ際は、ＣＰＵ（Central  Processing  Unit）およびメモリなどの物理リソースの性能を、作成予定のＶＭと合わせるとよい。
【００３５】
例えばユーザは、パブリッククラウド２００上で実行する予定のＷｅｂＡＳを、用意したＰＭ上で実行し、そのＷｅｂＡＳに対して、様々な送信レート（ＲＰＳ）に従いＨＴＴＰリクエストを送り、応答時間を計測すればよい。これにより、単位時間あたりに処理できる外部負荷（ＲＰＳ）の最大量を把握できる。以降、この「単位時間あたりに処理できるＲＰＳの最大量」のことを、ＭａｘＲＰＳと記載する。このＭａｘＲＰＳは、内部負荷が存在しない環境で評価して得られる値である。従って、内部負荷が存在するパブリッククラウド２００上で実行されるＷｅｂＡＳの性能は、ＭａｘＲＰＳ以下になる。
【００３６】
また、評価試験により、多くの（ＲＰＳ、応答時間）の組み合わせを得られる。この組み合わせ群に対して、例えば線形回帰分析を適用することで、外部負荷（ＲＰＳ）と性能の関係を以下の（１）式のように定式化できる。この式は、パブリッククラウド２００における内部負荷が存在しない状況（外部負荷のみが存在する理想的な状況）における、ＲＰＳと応答性能の関係を表す。このようにして求められた（１）式を、事前に除去部１０３に与えておくものとする。
応答時間＝ｆ（ＲＰＳ）  ・・・（１）
【００３７】
図５は、外部負荷（ＲＰＳ）と応答時間との関係の一例を示す図である。図５は、ＲＰＳと応答時間とが線形の関係にある例を示している。
【００３８】
除去部１０３は、（１）式と、負荷計測部１０１が計測した外部負荷とを用いて、性能計測部１０２が計測した性能から、外部負荷による変動成分を除去する。例えば除去部１０３は、負荷計測部１０１から、ある単位時間Ｔ１における、あるＶＭ（ＶＭ１とする）における外部負荷（ＲＰＳ）の計測値ＲＰＳ１を受け取る。また除去部１０３は、性能計測部１０２から、単位時間Ｔ１における、ＶＭ１のＷｅｂＡＳの応答時間の平均値ｒｔ１を受け取る。除去部１０３は、ＲＰＳ１を（１）式に代入し、応答時間ｒｔ２を得る。そして除去部１０３は、以下の（２）式により、外部負荷による変動成分を除去した性能を算出する。
性能＝ｒｔ２−ｒｔ１  ・・・（２）
【００３９】
（２）式は、内部負荷による性能の低下度を算出する式であると言い換えることができる。
【００４０】
性能履歴記憶部１２２は、変動成分が除去された性能を記憶する。図６は、性能履歴記憶部１２２に記憶される情報のデータ構造の一例を示す図である。図６に示すように、例えば性能履歴記憶部１２２は、（２）式で算出された性能を、ＶＭのＩＤと、時刻情報とともに記憶する。これにより、アプリケーションの性能が、外部負荷による変動成分が除去された状態で、時系列データとして記憶される。
【００４１】
性能予測部１０５は、負荷による影響が除去された性能に基づいて、サービスの将来の性能を予測する。例えば性能予測部１０５は、性能履歴記憶部１２２に記憶されている性能を用いて、将来のアプリケーションの性能（アプリ性能）を予測する。すなわち、アプリ性能はＶＭごとに予測される。
【００４２】
負荷予測部１０４と同様に、性能予測部１０５による予測方法はどのような方法であってもよい。例えば、移動平均を予測値とする方法、および、自己回帰移動平均により予測する方法などを適用できる。性能の変動の特徴に応じて、適切な予測の方法を選べばよい。
【００４３】
負荷予測部１０４と同様に、どこまで将来を予測するか、および、予測の単位は、任意である。例えば性能予測部１０５は、現在時刻からＶＭの起動に要する時間が経過した後の性能を予測してもよい。性能を予測する将来の時刻、および、予測の単位は、負荷予測部１０４と合わせておいたほうがよい。
【００４４】
算出部１０６は、外部負荷の予測結果と、アプリ性能の予測結果から、将来に必要になるＶＭ数を算出する。ＶＭ数の算出方法の詳細は後述する。
【００４５】
リソース制御部１０７は、算出部１０６の決定に従いリソースを制御する。例えばリソース制御部１０７は、算出部１０６の決定に従い、ＶＭを作成したり、停止したりする。ＶＭを増やす場合、リソース制御部１０７は、ＶＭを作成して、ＷｅｂＡＳをインストールしてもよい。または、ＷｅｂＡＳをインストール済みのＶＭのイメージをテンプレートとして記憶しておき、リソース制御部１０７が、テンプレートを用いてＶＭを作成してもよい。リソース制御部１０７は、ＶＭ数の制御が完了したことを、分散制御部１０８に伝える。
【００４６】
なお、制御するリソースは、ＶＭの個数（ＶＭ数）に限られるものではない。仮想環境としてコンテナを用いる場合は、ＶＭおよびコンテナの少なくとも一方の個数を制御してもよい。また、ＶＭ（コンテナ）に割り当てるＣＰＵおよびメモリなどの物理リソースを制御してもよい。
【００４７】
分散制御部１０８は、リソース制御部１０７により制御されるＶＭの情報をＬＢ２０１に送信し、ＬＢ２０１による負荷分散処理を制御する。例えばＶＭが増えた場合は、分散制御部１０８は、増えたＶＭのＩＤおよびＩＰ（Internet  Protocol）アドレスをＬＢ２０１に伝える。ＶＭが減った場合は、分散制御部１０８は、停止されたＶＭのＩＤおよびＩＰアドレスをＬＢ２０１に伝える。これにより、ＬＢ２０１は、各ＶＭの負荷が均等になるように、ＨＴＴＰリクエストの転送先を算出できる。
【００４８】
負荷計測部１０１、性能計測部１０２、除去部１０３、負荷予測部１０４、性能予測部１０５、算出部１０６、リソース制御部１０７、および、分散制御部１０８は、例えば、ＣＰＵなどの処理装置にプログラムを実行させること、すなわち、ソフトウェアにより実現してもよいし、ＩＣ（Integrated  Circuit）などのハードウェアにより実現してもよいし、ソフトウェアおよびハードウェアを併用して実現してもよい。
【００４９】
負荷履歴記憶部１２１および性能履歴記憶部１２２は、ＨＤＤ（Hard  Disk  Drive）、光ディスク、メモリカード、ＲＡＭ（Random  Access  Memory）などの一般的に利用されているあらゆる記憶媒体により構成することができる。
【００５０】
次に、算出部１０６によるＶＭ数の算出方法の一例について説明する。負荷予測部１０４が予測する、総外部負荷をｆ＿ｌｏａｄ＿ａｌｌと記述する。ｆ＿ｌｏａｄ＿ａｌｌは以下のように表される。
ｆ＿ｌｏａｄ＿ａｌｌ＝
（（ｔ１，ｌｏａｄ＿ａｌｌ（ｔ１）），
（ｔ２，ｌｏａｄ＿ａｌｌ（ｔ２）），
・・・，
（ｔＮ，ｌｏａｄ＿ａｌｌ（ｔＮ）））
【００５１】
ｌｏａｄ＿ａｌｌ（ｔ）は、時刻ｔにおける総外部負荷の予測値である。Ｎは１以上の任意の整数である。現在稼働しているＶＭの総数をＭ個とすると、全ＶＭにより処理可能な外部負荷の最大値はＭ×ＭａｘＲＰＳとなる。算出部１０６は、時刻ｔ（ｔ１からｔＮ）ごとに、以下の（３）式が成り立つかを算出する。
ｌｏａｄ＿ａｌｌ（ｔ）＞Ｍ×ＭａｘＲＰＳ  ・・・（３）
【００５２】
（３）式が成り立つ場合は、内部負荷が無かったとしても、現在のＶＭ群２１０では外部負荷を処理しきれないことを意味する。（３）式が成り立つｔの数をＰ個とする。算出部１０６は、Ｐが予め設定された閾値を超えた場合、または、Ｎに対するＰの比率が予め設定された閾値を超えた場合に、ＶＭを増やすと判断する。算出部１０６は、例えば、「一度でも（３）式を満たした場合は、ＶＭを増やす」と判断してもよい。
【００５３】
一度に増やすＶＭの数の決め方は様々である。例えば、必ず１個ずつ増やす方法でもよい。（３）式によりＶＭを増やすと判断した場合は、以下の（４）式により、増やすＶＭの数を算出してもよい。
ＶＭ増加数＝ｃｅｉｌ（ｍａｘ（ｔ，ａｂｓ（ｌｏａｄ＿ａｌｌ（ｔ）−（Ｍ×ＭａｘＲＰＳ）））÷ＭａｘＲＰＳ）＋α  ・・・（４）
【００５４】
ａｂｓ（ｘ）は、ｘの絶対値を意味する。ｍａｘ（ｔ，ｘ）は、すべてのｔにおける、最大のｘを意味する。ｃｅｉｌ（ｘ）は、ｘを切り上げた値を意味する。すなわち、算出部１０６は、（４）式に従い、外部負荷の予測値と、ＶＭ群２１０により処理できる外部負荷との差の最大値を選択し、選択した最大値をＭａｘＲＰＳで商算し、切り上げる。算出部１０６は、その結果に、微調整のための変数α（０以上の整数）を加算した値を、増やすＶＭの数とする。
【００５５】
また、算出部１０６は、内部負荷を考慮した場合の、ＶＭ数の増減についても算出する。性能予測部１０５が予測するアプリ性能予測を、ｆ＿ｐｅｒｆ（ｉ）と記述する。ｉは、ＶＭのＩＤである。ｆ＿ｐｅｒｆ（ｉ）は、以下のように表される。
ｆ＿ｐｅｒｆ（ｉ）＝
（（ｔ１，ｐｅｒｆ＿ｉ（ｔ１）），
（ｔ２，ｐｅｒｆ＿ｉ（ｔ２）），
・・・，
（ｔＮ，ｐｅｒｆ＿ｉ（ｔＮ）））
【００５６】
算出部１０６は、時刻ｔ（ｔ１からｔＮ）ごとに、かつ、ＶＭ＿ｉごとに、以下の（５）式が成り立つかを算出する。
ｆ（ｌｏａｄ＿ａｌｌ（ｔ）÷Ｍ）−ｐｅｒｆ＿ｉ（ｔ）
＞応答時間の閾値  ・・・（５）
【００５７】
ｆは、（１）式である。f（ｌｏａｄ＿ａｌｌ（ｔ）÷Ｍ）は、ＶＭ単体に対する外部負荷から予測される、内部負荷を考慮しない場合の応答時間である。この応答時間が、アプリ性能予測結果（ｐｅｒｆ＿ｉ（ｔ））により補正される。
【００５８】
（５）式が成り立つ場合は、ＶＭ＿ｉのＷｅｂＡＳによる応答時間が、許容範囲を超えることを意味する。応答時間の閾値は、予め与えられているものとする。応答時間の閾値は例えば１００ミリ秒である。
【００５９】
算出部１０６は、（５）式が成り立つｔの数をＱ個とする。Ｑが予め設定された閾値を超えた場合、または、Ｎに対するＱの比率が予め設定された閾値を超えた場合に、算出部１０６は、ＶＭを増やす。例えば算出部１０６は、「一度でも（５）式を満たした場合は、ＶＭを増やす」と判断してもよい。または、一時的な性能低下を許容できるのであれば、算出部１０６は、「Ｎに対するＱの比率が０．５を超えた場合は、ＶＭを増やす」と判断してもよい。
【００６０】
（５）式により、ＶＭを増やすと判断した場合は、算出部１０６は、以下の（６）式を満たす最小のＭ’を見つけ、（Ｍ’−Ｍ）をＶＭの追加数とする。
f（ｌｏａｄ＿ａｌｌ（ｔ）÷Ｍ’）−ｐｅｒｆ＿ｉ（ｔ）
≦応答時間の閾値  ・・・（６）
【００６１】
Ｍ’を見つけた場合は、以降、算出部１０６は、別のＶＭに対して、Ｍ’を新たなＭとして（５）式による算出を行う。これにより、不必要にＶＭを増やすことを避けられる。
【００６２】
また、算出部１０６は、ＶＭを減らせる可能性についても検討する。時刻ｔ（ｔ１からｔＮ）ごとに、かつ、ＶＭ＿ｉごとに、以下の（７）式が成り立つかを算出する。
【００６３】
ｆ（ｌｏａｄ＿ａｌｌ（ｔ）÷Ｍ”）−ｐｅｒｆ＿ｉ（ｔ）
≦応答時間の閾値・・・（７）
【００６４】
（７）式において、Ｍ”は、Ｍよりも小さい整数である。例えば、Ｍ”＝Ｍ−１である。（７）式が、すべての「時刻ｔ（ｔ１からｔＮ）とＶＭ＿ｉの組み合わせ」において成り立つなら、算出部１０６は、ＶＭ数を減らす。この場合、ＶＭの削減数は（Ｍ−Ｍ”）となる。
【００６５】
算出部１０６は、（３）式、（５）式、および、（７）式が成立しなければ、ＶＭの数は変更しないと判断する。
【００６６】
次に、このように構成された本実施形態にかかる管理サーバ１００によるリソース制御処理について図７を用いて説明する。図７は、本実施形態におけるリソース制御処理の一例を示すフローチャートである。
【００６７】
ある時刻ｔにおいて、負荷計測部１０１は外部負荷を計測する（ステップＳ１０１）。計測されたＶＭごとの外部負荷は、除去部１０３に渡される。また、負荷履歴記憶部１２１は、ＶＭごとの外部負荷、および、ＶＭごとの外部負荷を合算した総外部負荷を記憶する（ステップＳ１０２）。負荷予測部１０４は、記憶された情報をもとに外部負荷を予測する（ステップＳ１０３）。
【００６８】
同様にある時刻ｔにおいて、性能計測部１０２は応答時間を計測する（ステップＳ１０４）。除去部１０３は、計測された応答時間から、外部負荷による変動成分を除去する（ステップＳ１０５）。性能履歴記憶部１２２は、除去の結果を、アプリ性能として記憶する（ステップＳ１０６）。性能予測部１０５はアプリ性能を予測する（ステップＳ１０７）。
【００６９】
算出部１０６は、外部負荷の予測結果、および、アプリ性能の予測結果から、ＶＭ数の増減を算出する（ステップＳ１０８）。ＶＭ数の増減を算出する算出処理の詳細は後述する。算出結果はリソース制御部１０７に伝えられる。リソース制御部１０７は、算出結果に従い実際にＶＭを増やしたり、減らしたりする（ステップＳ１０９）。リソース制御部１０７は、ＶＭの増減を示す情報を分散制御部１０８を介してＬＢ２０１へ通知する（ステップＳ１１０）。ＬＢ２０１は、この通知に従い、以降の負荷分散処理に反映する。
【００７０】
次に、ステップＳ１０８の算出処理の詳細について説明する。図８は、ＶＭ数の算出処理の一例を示すフローチャートである。
【００７１】
まず算出部１０６は、予測される外部負荷を現在の数のＶＭで処理可能か否かを判断する（ステップＳ２０１）。例えば算出部１０６は、（３）式が成立する場合に、現在のＶＭ群２１０では外部負荷を処理できないと判断する。予測時のＮが１よりも大きい場合は、算出部１０６は、（３）式が成り立つ回数や割合から判断してもよい。
【００７２】
現在のＶＭ群２１０で処理可能でない場合（ステップＳ２０１：Ｎｏ）、外部負荷を処理するためにＶＭ数が足りないことを意味するため、算出部１０６は、例えば（４）式により、追加するＶＭ数を算出する（ステップＳ２０５）。
【００７３】
現在のＶＭ群２１０で処理可能な場合（ステップＳ２０１：Ｙｅｓ）、算出部１０６は、予測されるアプリ性能（応答時間）が、閾値より大きいか否かを判断する（ステップＳ２０２）。例えば算出部１０６は、（５）式が成立するかを判断する。予測時のＮが１よりも大きい場合は、算出部１０６は、（５）式が成り立つ回数や割合から判断してもよい。
【００７４】
なお応答時間とは異なり、値が小さいほど性能が低いことを示す指標をアプリ性能とする場合は、算出部１０６は、この指標の値が閾値より小さいか否かを判断すればよい。
【００７５】
予測されるアプリ性能が閾値より大きい場合（ステップＳ２０２：Ｙｅｓ）、外部負荷を処理するためにＶＭ数が足りないことを意味するため、算出部１０６は、例えば（６）式により、追加するＶＭ数を算出する（ステップＳ２０５）。
【００７６】
予測されるアプリ性能が閾値以下である場合（ステップＳ２０２：Ｎｏ）、算出部１０６は、ＶＭ数を減らした場合のアプリ性能が、閾値以下であるか否かを判断する（ステップＳ２０３）。例えば算出部１０６は、（７）式が成立するかを判断する。
【００７７】
ＶＭ数を減らした場合のアプリ性能が閾値以下である場合（ステップＳ２０３：Ｙｅｓ）、外部負荷を処理するためにＶＭ数が余っていることを意味するため、算出部１０６は、例えば（７）式により、削減するＶＭ数を算出する（ステップＳ２０４）。
【００７８】
ＶＭ数を減らした場合のアプリ性能が閾値より大きい場合（ステップＳ２０３：Ｎｏ）、算出部１０６は、ＶＭ数を増減しないと判断する。
【００７９】
（変形例）
性能予測部１０５は、各ＶＭのアプリ性能の予測結果を、ＬＢ２０１に通知してもよい。ＶＭごとに、内部負荷が生じるタイミングは異なる。すなわち、想定よりも性能が低下するタイミングは異なる。各ＶＭのアプリ性能の予測結果をＬＢ２０１に通知することで、ＬＢ２０１は、各ＶＭの性能の違いを考慮して、ＨＴＴＰリクエストの転送先を算出できる。例えばＬＢ２０１は、内部負荷により大きく性能が低下することが予測されるＶＭには、ＨＴＴＰリクエストの転送数を減らすという判断を下せる。
【００８０】
本実施形態ではＶＭ上で動作させるアプリケーションとして、ＷｅｂＡＳを例にあげて説明したが、本実施形態の適用先はＷｅｂＡＳに限らない。同様に、外部負荷は、ＨＴＴＰリクエスト以外でもよい。同様に、アプリケーションの性能の指標は、応答時間でなくてもよい。
【００８１】
例えば、センサーから送信される計測データを収集するアプリケーションに適用してもよい。この場合、例えば計測データ（計測データの個数など）が外部負荷となる。
【００８２】
上記実施形態では、管理サーバ１００は、パブリッククラウド２００の外部にあるという構成を説明した。管理サーバ１００は、パブリッククラウド２００の内部にあってもよい。管理サーバ１００およびＬＢ２０１の少なくとも一方は、パブリッククラウド２００上のＶＭの上で稼働してもよい。
【００８３】
このように、本実施形態にかかるサーバ装置では、外部負荷と内部負荷を区別して考慮してシステムの性能を予測し、予測結果に基づいて仮想環境のリソースを制御する。これにより、システムの性能をより高精度に予測可能となる。その結果、リソースを適切に調節できるようになり、システムの性能を安定させることが可能となる。
【００８４】
次に、本実施形態にかかるサーバ装置のハードウェア構成について図９を用いて説明する。図９は、本実施形態にかかるサーバ装置のハードウェア構成例を示す説明図である。
【００８５】
本実施形態にかかるサーバ装置は、ＣＰＵ５１などの制御装置と、ＲＯＭ（Read  Only  Memory）５２やＲＡＭ５３などの記憶装置と、ネットワークに接続して通信を行う通信Ｉ／Ｆ５４と、各部を接続するバス６１を備えている。
【００８６】
本実施形態にかかるサーバ装置で実行されるプログラムは、ＲＯＭ５２等に予め組み込まれて提供される。
【００８７】
本実施形態にかかるサーバ装置で実行されるプログラムは、インストール可能な形式又は実行可能な形式のファイルでＣＤ−ＲＯＭ（Compact  Disk  Read  Only  Memory）、フレキシブルディスク（ＦＤ）、ＣＤ−Ｒ（Compact  Disk  Recordable）、ＤＶＤ（Digital  Versatile  Disk）等のコンピュータで読み取り可能な記録媒体に記録してコンピュータプログラムプロダクトとして提供されるように構成してもよい。
【００８８】
さらに、本実施形態にかかるサーバ装置で実行されるプログラムを、インターネット等のネットワークに接続されたコンピュータ上に格納し、ネットワーク経由でダウンロードさせることにより提供するように構成してもよい。また、本実施形態にかかるサーバ装置で実行されるプログラムをインターネット等のネットワーク経由で提供または配布するように構成してもよい。
【００８９】
本実施形態にかかるサーバ装置で実行されるプログラムは、コンピュータを上述したサーバ装置の各部として機能させうる。このコンピュータは、ＣＰＵ５１がコンピュータ読取可能な記憶媒体からプログラムを主記憶装置上に読み出して実行することができる。
【００９０】
本発明のいくつかの実施形態を説明したが、これらの実施形態は、例として提示したものであり、発明の範囲を限定することは意図していない。これら新規な実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。これら実施形態やその変形は、発明の範囲や要旨に含まれるとともに、特許請求の範囲に記載された発明とその均等の範囲に含まれる。
【符号の説明】
【００９１】
１００  管理サーバ
１０１  負荷計測部
１０２  性能計測部
１０３  除去部
１０４  負荷予測部
１０５  性能予測部
１０６  算出部
１０７  リソース制御部
１０８  分散制御部
１２１  負荷履歴記憶部
１２２  性能履歴記憶部
２００  パブリッククラウド
２０１  ＬＢ
２１０  ＶＭ群
２１１、２１２、２１３  ＶＭ
３００  クライアント
【図１】
2018084986.tif 000003
【図２】
2018084986.tif 000004
【図３】
2018084986.tif 000005
【図４】
2018084986.tif 000006
【図５】
2018084986.tif 000007
【図６】
2018084986.tif 000008
【図７】
2018084986.tif 000009
【図８】
2018084986.tif 000010
【図９】
2018084986.tif 000011