JP2012208781A - 情報処理システム、情報処理装置、スケーリング方法、プログラムおよび記録媒体 - Google Patents

Abstract

【課題】 クラウド環境において、需要変化に応答してサーバ規模を増減させるオートスケーリング機構を実現する情報処理システム、情報処理装置、スケーリング方法、プログラムおよび記録媒体を提供すること。
【解決手段】 本情報処理システム１００は、複数の処理サーバ１２２を含む処理サーバ群１２０と、処理サーバ群１２０に代替して応答するための代替サーバ１２４と、処理サーバ群１２０にトラフィックを分散するとともに、上記処理サーバ群１２０が過負荷状態となった際に代替サーバ１２４にトラフィックを転送するロードバランサ１１０とを含む。本情報処理システム１００は、さらに、上記ロードバランサ１１０により処理サーバ群１２０へ転送される転送量と上記代替サーバ１２４へ転送される転送量とに応じて、処理サーバ群１２０の目標規模を演算し、処理サーバ群の現在の規模から目標規模へ増強するため処理サーバ群の処理サーバを準備する。
【選択図】 図３

Description

本発明は、クラウド環境におけるオートスケーリング機構に関し、より詳細には、需要変化に応答してサーバ規模を増減させるオートスケーリング機構を実現する、情報処理システム、情報処理装置、スケーリング方法、プログラムおよび記録媒体に関する。

近年、システム仮想化技術の発展およびインターネット技術の進歩に伴い、仮想マシンなどのインフラストラクチャをインターネット経由のサービスとして提供する、いわゆるＩａａＳ（Infrastructure as a Service）と呼ばれるクラウド・サービスが普及している。上述したＩａａＳによれば、クラウド利用者は、アクセス数に対応させてウェブサーバのインスタンスを適時に増減させることが可能となる。ひいては、需要の変化に合わせて素早く能力を拡張または縮小することが可能なシステムが提供される。

上記インスタンスの増減は、クラウド利用者側でオペレータ監視の下、需要状況から必要な能力を予測し、マニュアルで行うこともできるが、一定のトリガ条件を設定して自動的に増減させるオートスケーリング技術も知られている。例えば、Ａｍａｚｏｎ社が提供するクラウド・サービスＡｍａｚｏｎ ＥＣ２（登録商標）では、クラウド利用者は、平均ＣＰＵ使用率などの観測可能な評価指標（メトリック）を用いてルールを定義し、仮想マシンのインスタンスの増減を条件づけることができる（非特許文献１）。上記従来技術のオートスケーリング機能によれば、クラウド利用者は、例えばＣＰＵの平均使用率が８０％を上回った場合に、新たに固定数台のインスタンスを追加し、ＣＰＵの平均使用率が２０％を下回った場合に、固定数台のインスタンスを除去するというような定義を行うことができる。また、トリガ条件に用いられる評価指標は、上記ＣＰＵの平均使用率に限られず、メモリの使用率、ディスク利用度、ネットワーク流量などの種々のメトリックを挙げることができる（非特許文献２）。

オートスケーリング技術としては、大きく分けて、上述したような需要に応答してスケールを増減させるリアクティブ・スケーリング（Reactive Scaling）と、過去の実績などから統計的に需要予測を計算し、予めサーバ・インスタンス数を調整するプロアクティブ・スケーリング（Proactive Scaling）という手法が知られている。

プロアクティブ・スケーリングに関連する従来技術としては、特開２００８−１２９８７８号公報（特許文献１）を挙げることができる。特許文献１は、業務要件に対して各サーバ群で必要とされる処理性能を定量的に予測することを目的として、フロントエンドサーバ群と、ミドルサーバ群と、バックエンドサーバ群とからなる３階層の業務処理システムの性能予測を行うシステムにおいて、業務処理システムで処理すべき追加業務要件を受け付けて、この業務要件を処理するのに要するミドルサーバ群の処理実行時間を予測する必要処理能力算出部と、予測された処理実行時間に基づいてバックエンドサーバ群の必要サーバマシンの台数を算出するサーバ台数算出部とを設ける技術を開示する。

さらに、過去の履歴情報を用いたスケーリング手法として、特許文献２は、レスポンスタイム監視結果、レスポンスタイム目標値、数量モデルおよび性能仕様情報に基づいて、スループット変化分を算出し、取得した数量モデルに、性能仕様情報を順次代入し、プールサーバごとにスループットを算出して、スループット変化分よりも大きく、かつ最も近い値を示すスループットに対応するプールサーバを選択し、選択したプールサーバに対して構成変更制御を実行するよう指示し、プールサーバに対しアプリケーション・サーバとして機能するよう構成を変更する技術を開示する。

特開２００８−１２９８７８号公報 国際公開第２００７／０３４８２６号

"Amazon Elastic Compute Cloud (Amazon EC2)"、［Online］、Amazon Web Services(TM)，Products & Services、［平成２３年３月２３日検索］，インターネット〈http://aws.amazon.com/ec2/> "ニフティ・クラウド サービスプラン"、［Online］、クラウドトップ、サービスプラン、サービス仕様、［平成２２年１２月０６日検索］，インターネット〈http://cloud.nifty.com/service/spec.htm>

しかしながら、上述したリアクティブ・スケーリングによれば、穏やかな需要変化であれば、対応して仮想マシンのインスタンスを増減することができるものの、急激な需要変化には対応することが難しかった。また、上記メトリックに対するしきい値を用いてインスタンス数を増減させる場合、スケール単位台数が固定値では需要変化に柔軟に対応することができない。また、スケール台数を負荷に応じて可変にしようとしても、過負荷状態にあるサーバのスループットはそれ以上増えないため、ＣＰＵの平均使用率やネットワーク流量などのメトリックは飽和し、需要に見合った追加台数を見積もることは困難である。したがって、従来のリアクティブ・スケーリングでは、トリガ条件の成立、所定数のサーバ・インスタンスの起動、そして起動完了後のトリガ条件の監視というサイクルを１以上の回数繰り返すことで、様子を見ながら段階的に最終的に必要な数のインスタンスが起動されることになり、インスタンスの起動時間分だけ需要の変化への追従に遅れが生じてしまう可能性があった。

上記特許文献２に開示されているように、履歴情報を用いて需要予測を行うこともできる場合があるが、過去の実績を超えた需要の変化には対応することができない。プロアクティブ・スケーリングも、過去の実績から需要予測を事前に行うため、予測を超えた需要の変化には対応することができない。例えば災害時などウェブサイトに突発的に負荷が集中する場合は、その需要を正確に定量して、必要台数のインスタンスを迅速に準備することが望ましい。しかしながら、上述までの従来技術では、予想外の需要変化が突発的に起こった場合には充分に対応することができなかった。

本発明は、上記従来技術における不充分な点に鑑みてなされたものであり、本発明は、予想外の需要変化が突発的に起こった場合にも対応してサーバ規模を増加させられるオートスケーリング機構を実現する、情報処理システム、情報処理装置、スケーリング方法、プログラムおよび記録媒体を提供することを目的とする。

本発明は、上記課題を解決するために、以下の特徴を有する情報処理システム、情報処理装置を提供する。本情報処理システムは、複数の処理サーバを含む処理サーバ群と、上記処理サーバ群に代替して応答するための代替サーバと、上記処理サーバ群の各処理サーバにトラフィックを分散するとともに、上記処理サーバ群が過負荷状態となった際に代替サーバにトラフィックを転送するロードバランサとを含む。本情報処理システムにおける情報処理装置は、上記ロードバランサにより処理サーバ群へ転送される転送量と代替サーバへ転送される転送量とに応じて、上記処理サーバ群の目標規模を演算し、上記処理サーバ群の現在の規模から目標規模へ増強するため処理サーバを準備する。

本発明ではさらに、上記目標規模を演算する際には、上記処理サーバ群の処理サーバで観測されたローカルな負荷を表す評価指標に依存させて上記処理サーバ群の目標規模を演算することができる。さらに、本情報処理システムは、上記処理サーバ群の後段に設けられる第２サーバ群を含むことができ、上記処理サーバ群の処理サーバで観測された評価指標からボトルネックを判定し、上記処理サーバ群の後段にボトルネックがあると判定された場合に、上記処理サーバ群への転送量と上記代替サーバへの転送量とに応じて上記第２サーバ群の目標規模を演算し、上記第２サーバ群の処理サーバを準備することができる。また、上記ロードバランサは、処理サーバ群の応答性能を監視し、応答性能が転送条件を満たした場合に処理サーバ群が過負荷状態であると判定することができ、上記転送量に応じた処理サーバ群の目標規模の演算および該目標規模へ増強するための処理サーバの準備は、上記転送条件と同一の条件が満たされることをトリガとして行うことができる。さらに本発明によれば、上記情報処理システムにおいて実行されるスケーリング方法、上記情報処理装置を実現するためのプログラム、および該プログラムを記録する記録媒体を提供することができる。

上記構成によれば、ロードバランサにより処理サーバ群へ転送されるトラフィックの転送量と、代替サーバへ転送されるトラフィックの転送量とを用いてウェブシステムの需要が定量されるため、高精度にシステムの潜在的な需要を定量することができ、ひいては、予想できない需要変化に対しても迅速に対応することが可能となる。

本発明の実施形態によるプロビジョニング・システムの概略図。 本発明の実施形態によるプロビジョニング・システムにおける、物理ホストマシンのハードウェア構成およびソフトウェア構成を示すブロック図。 本発明の実施形態によるプロビジョニング・システムにおいて実現される、需要変化に対応させたオートスケーリング機構に関連する機能ブロック図。 本発明の実施形態によるプロビジョニング・システムにおいて、管理ポータルが提供するオートスケーリング設定を行うための管理画面を例示する図。 本発明の実施形態によるプロビジョニング・システムにおいて実現される、需要変化に対応させたオートスケーリング処理を示すフローチャート。 本発明の実施形態によるプロビジョニング・システムにおいて実現される、需要変化に対応させた他のオートスケーリング処理を示すフローチャート（１／２）。 本発明の実施形態によるプロビジョニング・システムにおいて実現される、需要変化に対応させた他のオートスケーリング処理を示すフローチャート（２／２）。 本発明の実施形態によるプロビジョニング・システムにおいて、他の多層アーキテクチャ構成を採用するウェブシステムをスケーリングする事例について説明する図。 従来技術のオートスケーリングによるウェブサーバのインスタンス数の経時変化を示すグラフ。

以下、本発明について実施形態をもって説明するが、本発明は、後述する実施形態に限定されるものではない。以下説明する実施形態では、情報処理システムとして、物理ホストマシン上で稼働させる仮想マシンのオートスケーリング機構を実現する、プロビジョニング・システムについて説明する。また、以下の説明では、本発明の実施形態によるプロビジョニング・システムを用いて、多層アーキテクチャのウェブシステムをスケーリングする事例について説明する。

図１は、本発明の実施形態によるプロビジョニング・システムの概略図を示す。図１に示すプロビジョニング・システム１００では、インターネット１０２を介してエンドユーザにサービスを提供するウェブシステム１０４が、図示しない物理リソース上の仮想コンピューティングシステムとして構築されている。ウェブシステム１０４は、ロードバランサ１１０と、上記ロードバランサ１１０によりトラフィックが振り分けられ、エンドユーザ側のクライアント端末１８０からインターネット１０２を介して送られてくるリクエストを処理するウェブサーバ群１２０と、上記ウェブサーバ群１２０の過負荷時に代替してリクエストに対し応答するＳｏｒｒｙサーバ１２４とを含んで構成される。また、図１に示すウェブシステム１０４は、多層アーキテクチャ構成を採用しており、上記ウェブサーバ群１２０の後段に、ロードバランサ１２６によりウェブサーバ群１２０からのトラフィックが振り分けられるメモリキャッシュ・サーバ群１３０が設けられ、上記メモリキャッシュ・サーバ群１３０の後段に、データベース・サーバ群１４０が設けられている。

上述したウェブサーバ群１２０を構成するウェブサーバ１２２ａ〜１２２ｚ、メモリキャッシュ・サーバ群１３０を構成するメモリキャッシュ・サーバ１３２ａ〜１３２ｚ、およびデータベース・サーバ群１４０を構成するデータベース・サーバ１４２ａ〜１４２ｚは、それぞれ、図示しない物理ホストマシン上で稼働する仮想マシン（仮想サーバ）として実現される。物理ホストマシンは、それぞれ、プロセッサやメモリなどのハードウェア・リソースを含み、インストールされた仮想化ソフトウェアによって、これらハードウェア・リソースが抽象化され、その上で、仮想化されたコンピュータ、すなわち仮想マシンを実現する。物理ホストマシンは、ＴＣＰ／ＩＰおよびイーサネット（登録商標）によるＬＡＮ（Local Area Network）や、専用線やまたはＶＰＮ（Virtual Private Network）により公衆回線を介して構成される広域ネットワークを介して相互に接続されており、全体としてのリソースプールを提供する。

上記ロードバランサ１１０，１２６は、それぞれ、物理的な負荷分散装置として、または負荷分散機能を提供する上記仮想マシン上のソフトウェアとして提供される。Ｓｏｒｒｙサーバ１２４も同様に、物理的なサーバ装置として、またはＳｏｒｒｙサーバ機能を提供する上記仮想マシン上のソフトウェアとして提供される。なお、図１に示す実施形態では、Ｓｏｒｒｙサーバ１２４は、独立したモジュールとして説明しているが、上記ロードバランサ１１０が提供する機能の一部として実装したり、いずれかのウェブサーバ１２２が提供する機能の一部として実装したりすることもできる。

プロビジョニング・システム１００は、さらに、管理サーバ１５０を含む。管理サーバ１５０は、クラウド利用者側のオペレータ（以下、単にクラウド利用者という。）に対し、サービスを利用するための管理ポータルサイトを提供する。管理サーバ１５０は、クラウド利用者が上記管理ポータルサイトを介して行った各種管理要求を処理する管理アプリケーションを備え、管理アプリケーションは、物理リソース上に構築される仮想コンピューティング環境に関する情報を収集し、各種設定を管理し、上記クラウド利用者からの要求に対応して各物理ホストマシンで動作する仮想化ソフトウェアのリモート管理を行う。上述した仮想サーバのインスタンス１２２，１３２，１４２、Ｓｏｒｒｙサーバ１２４、ロードバランサ１１０，１２６は、管理サーバ１５０により管理される。

クラウド利用者は、管理端末１７０を用いてインターネット１０２経由で管理サーバ１５０にアクセスし、当該サービスの管理ポータルサイトから、予め準備されているＯＳイメージを選択してプロビジョニング申請することにより、上述したウェブサーバ１２２、メモリキャッシュ・サーバ１３２およびデータベース・サーバ１４２のインスタンスを起動させることができる。またクラウド利用者は、管理ポータルサイトから、ロードバランサ１１０，１２６の負荷分散の対象とするインスタンス（またはそのグループ）の登録、転送先の代替サーバの登録、上記ウェブサーバ１２２やメモリキャッシュ・サーバ１３２のインスタンスの増減を条件付けるオートスケーリング設定など行うことができる。

管理サーバ１５０は、概ね、ワークステーション、ラックマウント型サーバ、ブレード型サーバなどの汎用コンピュータ装置として構成される。管理サーバ１５０は、より具体的には、シングルコア・プロセッサまたはマルチコア・プロセッサなどの中央演算装置（ＣＰＵ）、キャッシュ・メモリ、ＲＡＭ（Random Access Memory）、ネットワーク・インタフェース・カード（ＮＩＣ）、ストレージ・デバイスなどのハードウェア・リソースを備え、Ｗｉｎｄｏｗｓ（登録商標）、ＵＮＩＸ（登録商標）、ＬＩＮＵＸ（登録商標）などの適切なＯＳの制御の下、仮想化環境の管理インタフェースとしての機能を提供する。管理サーバ１５０は、また、上記物理ホストマシン上で稼働する仮想マシンとして実装されてもよい。

上記管理端末１７０およびクライアント端末１８０ａ〜１８０ｚは、概ね、タワー型、デスクトップ型、ラップトップ型またはタブレット型のパーソナル・コンピュータ、ワークステーション、ネットブック、ＰＤＡ（Personal Data Assistance）などのコンピュータ装置として構成され、上記ＣＰＵなどのハードウェア・リソースを備えており、Ｗｉｎｄｏｗｓ（登録商標）、ＵＮＩＸ（登録商標）、ＬＩＮＵＸ（登録商標）、Ｍａｃ ＯＳ（登録商標）、ＡＩＸ（登録商標）などの適切なＯＳの制御の下動作する。本実施形態では、管理端末１７０およびクライアント端末１８０ａ〜１８０ｚは、上記ＯＳ上で動作するウェブ・ブラウザを実装し、ウェブ・ブラウザを介して管理ポータルサイトや、サービスの提供を受ける。

以下、上記ウェブサーバ１２２、メモリキャッシュ・サーバ１３２などの仮想マシンを稼働させる物理ホストマシンの構成について説明する。図２は、本発明の実施形態によるプロビジョニング・システムにおける、物理ホストマシンのハードウェア構成およびソフトウェア構成を示すブロック図である。物理ホストマシン１０は、概ね、ワークステーション、ラックマウント型サーバ、ブレード型サーバ、ミッドレンジ、メインフレームなどの汎用コンピュータ装置として構成される。物理ホストマシン１０は、ハードウェア・リソース２０として、ＣＰＵ２２と、メモリ２４と、ハードディスク・ドライブ（ＨＤＤ）やソリッド・ステート・ドライブ（ＳＳＤ）などのストレージ２６と、ＮＩＣ２８とを含む。

物理ホストマシン１０は、ハードウェア・リソース２０上で動作する、Ｘｅｎ（登録商標）、ＶＭＷａｒｅ（登録商標）、Ｈｙｐｅｒ−Ｖ（登録商標）などの仮想化ソフトウェアのハイパーバイザ（仮想機械モニタとも呼ばれることがある。）３０を備え、このハイパーバイザ３０上で、Ｗｉｎｄｏｗｓ（登録商標）、ＵＮＩＸ（登録商標）、ＬＩＮＵＸ（登録商標）などの種々のＯＳをゲストＯＳとした仮想マシン４０，５０を稼働させる。

仮想マシン４０は、ドメイン０またはペアレント・パーティションなどの呼ばれる管理用の仮想マシンであり、管理用仮想マシン４０は、仮想リソース４２と、管理用ＯＳ４４と、管理用ＯＳ４４上で動作する制御モジュール４６とを含む。制御モジュール４６は、管理サーバ１５０からの指令を受信して、当該制御モジュール４６が動作している物理ホストマシン１０上のハイパーバイザ３０に対しコマンドを発行するモジュールである。制御モジュール４６は、管理サーバ１５０からの指令に応答して、ハイパーバイザ３０に対し、ドメインＵまたはチャイルド・パーティションなどと呼ばれるユーザドメインの仮想マシンの作成やゲストＯＳの起動の命令を発行し、管理サーバ１５０による管理の下、仮想マシンの動作を制御する。

仮想マシン５０ａ，５０ｂは、クラウド利用者に対しコンピューティング能力を提供するユーザドメインの仮想マシンである。仮想マシン５０は、仮想ＣＰＵ５２、仮想メモリ５４、仮想ディスク５６および仮想ＮＩＣ５８などの仮想リソースと、ゲストＯＳ６０と、該ゲストＯＳ６０上で動作する種々のアプリケーション６２，６４とを含む。アプリケーションは、クラウド利用者に依存するものであり、種々の組み合わせを採用することができる。ウェブサーバ１２２として仮想マシン５０を動作させる場合は、Apache HTTP Server（登録商標）、Internet Information Services（登録商標）などのウェブサーバ機能を提供するアプリケーションが動作する。メモリキャッシュ・サーバ１３２として仮想マシン５０を動作させる場合は、memcachedなどの分散メモリキャッシュ機能を提供するアプリケーションが動作する。データベース・サーバ１４２として仮想マシン５０を動作させる場合は、ＤＢ２（登録商標）、ＭｙＳＱＬ（登録商標）、ＰｏｓｔｇｒｅＳＱＬ（登録商標）などのデータベース機能を提供するアプリケーションが動作する。

上記仮想マシン５０は、それぞれ、クラウド利用者からの仮想マシンのプロビジョニング申請に応答して、管理サーバ１５０の指令によりプロビジョニングされ、クラウド利用者からの仮想マシンのシャットダウン申請に応答して、管理サーバ１５０の指令によりシャットダウンされる。さらに本発明の実施形態では、需要変化に対応させた仮想マシンのオートスケーリング機構が利用可能とされており、仮想マシン５０は、クラウド利用者が定義した仮想マシンの増減を条件付けるオートスケーリング設定のトリガ条件が満たされたことに応答して、プロビジョニングまたはシャットダウンされる。本発明の実施形態によるオートスケーリング機構によれば、ウェブシステム１０４の需要が定量され、定量された需要に応じて必要な目標サーバ規模が求められ、目標サーバ規模と現状の規模との差分に応じて適時にウェブサーバ群１２０およびメモリキャッシュ・サーバ群１３０の各インスタンスを追加または除去することで、サーバ規模を自動調整することが可能とされる。以下、本発明の実施形態による需要変化に対応させた仮想マシンのオートスケーリング機構の詳細について、図３〜図７を参照して説明する。

図３は、本発明の実施形態によるプロビジョニング・システムにおいて実現される、需要変化に対応させた仮想マシンのオートスケーリング機構に関連する機能ブロックを示す図である。図３には、管理サーバ１５０と、管理端末１７０とが示されており、対象となるウェブシステム１０４のコンポーネントとして、さらに、ロードバランサ１１０と、ウェブサーバ群１２０と、Ｓｏｒｒｙサーバ１２４と、メモリキャッシュ・サーバ群１３０とが示されている。なお、説明する実施形態では、ウェブサーバ群１２０およびメモリキャッシュ・サーバ群１３０の両方、またはウェブサーバ群１２０のみをスケーリング対象にすることができる。また、ウェブシステム１０４の需要を定量するため、ウェブサーバ群１２０の前段（インターネット側）に設けられるロードバランサ１１０が用いられる。なお、スケーリング対象となり、かつ、需要を定量するためのロードバランサによる負荷分散の対象となるウェブサーバ群１２０は、本実施形態における処理サーバ群を構成し、ウェブサーバ群１２０の各インスタンス（ウェブサーバ）１２２は、処理サーバを構成する。

本実施形態の管理サーバ１５０は、サービス管理用のインタフェースを提供する管理ポータル１５２を含んで構成される。クラウド利用者は、管理端末１７０のブラウザ１７２を用いてＨＴＴＰプロトコルにより当該管理ポータル１５２にアクセスし、管理メニューから、オートスケーリング設定を含む種々の管理要求を行うことができる。上記管理ポータル１５２で行われるオートスケーリング設定としては、（１）オートスケーリングの基本設定、（２）需要変化に対応させたオートスケーリングで用いるロードバランサの指定、（３）指定ロードバランサの負荷分散設定、（４）サーバ規模の増強を条件付ける増強条件設定、および（５）サーバ規模の縮小を条件付ける縮小条件設定が含まれる。

（１）オートスケーリングの基本設定は、スケーリング対象となるサーバ群（以下、スケーリング対象サーバ群という。）の指定、並びに各スケーリング対象サーバ群の仮想マシンのＯＳイメージやスペック、初期マシン数、最小マシン数および最大マシン数などの設定項目を含む。説明する実施形態では、スケーリング対象サーバ群としては、ウェブサーバ群１２０およびメモリキャッシュ・サーバ群１３０の両方、またはウェブサーバ群１２０のみが指定される。また、ウェブサーバ群１２０の最小マシン数Ｎ_ｍｉｎ、メモリキャッシュ・サーバ群１３０の最小マシン数Ｍ_ｍｉｎが指定され、最大マシン数は指定されていないものとして説明する。

本発明の実施形態による需要変化に対応させた仮想マシンのオートスケーリング機構では、トリガおよび需要定量のためロードバランサを用いており、説明する実施形態では、（２）指定ロードバランサとして、インターネット１０２からのトラフィックをウェブサーバ群１２０の各ウェブサーバ１２２へ分散させているロードバランサ１１０が選択されている。

本発明の実施形態によるオートスケーリング機構では、指定ロードバランサの負荷分散設定が、オートスケーリング設定の設定項目として組み込まれている。（３）指定ロードバランサの負荷分散設定としては、（ｉ）負荷分散方式、（ｉｉ）負荷分散対象サーバ群の指定、（ｉｉｉ）代替サーバの指定、および（ｉｖ）代替サーバへの転送条件が含まれる。

（ｉ）負荷分散方式としては、特に限定されるものではないが、順番にリクエストを振り分けるラウンドロビン方式、所与の比率でリクエストを振り分ける重み付きラウンドロビン方式、コネクションが少ないインスタンスにリクエストを振り分ける最小コネクション数方式、接続中クライアントが少ないインスタンスにリクエストを振り分ける最小クライアント数方式、処理中のデータ通信量が少ないインスタンスにリクエストを振り分ける最小データ通信量方式、応答時間が短いインスタンスにリクエストを振り分ける最小応答時間方式、ＣＰＵ、メモリ、入出力の使用率が低いインスタンスにリクエストを振り分ける最小サーバ負荷などいかなる負荷分散方式を挙げることができる。

また、詳細を後述する既存のユーザによる仕掛かり中のセッションを好適に維持する観点からは、いずれの方式であっても、クライアントから送られてくるリクエストの中で関連のあるリクエストを同じサーバに振り分ける、いわゆるセッション維持機能が有効とされていることが好ましい。セッション維持機能は、リクエストの送信元ＩＰアドレスからクライアントを識別する方式、Ｃｏｏｋｉｅ（クッキー）に登録された情報からクライアントを識別する方式、ＵＲＬに埋め込まれた情報からクライアントを識別するＵＲＬリライト方式、ＨＴＴＰリクエスト・ヘッダの認証情報からクライアントを識別する方式、ＳＳＬセッションＩＤからクライアントを識別する方式など如何なる方式を採用することができる。

（ｉｉ）負荷分散対象サーバ群としては、説明する実施形態では、ウェブサーバ群１２０が指定されており、（ｉｉｉ）代替サーバとしては、Ｓｏｒｒｙサーバ１２４が指定されている。クラウド利用者による負荷分散対象サーバ群および代替サーバの指定に対応して、内部的には、負荷分散対象サーバ群のインスタンス１２２ａ〜１２２ｚおよびＳｏｒｒｙサーバ１２４のＩＰアドレスやポート番号などを含む通信設定が行われる。

（ｉｖ）代替サーバへの転送条件は、一般的には、指定ロードバランサ１１０の負荷分散対象サーバ群インスタンスの平均ＣＰＵ使用率、平均メモリ使用率、平均入出力利用度、平均スループット、平均コネクション数、平均クライアント数、平均データ通信量および平均応答性能値などの種々のメトリックに対するしきい値条件を挙げることができるが、ウェブシステム１０４の過負荷状況を好適に検知する観点からは、上記インスタンスの平均応答時間や平均応答速度などの平均応答性能値に対するしきい値条件を用いることが好ましい。説明する実施形態では、ウェブサーバ群１２０のインスタンスの平均応答時間がしきい値Ｒ_{ｔｈｒｅｓｈｏｌｄ}を超えるという条件を用いる。ここで「平均」は、時間平均およびインスタンス間平均の一方または両方の意味で用いる。平均応答時間のしきい値Ｒ_{ｔｈｒｅｓｈｏｌｄ}は、例えば、クラウド・サービスにおけるＳＬＡ（Service Level Agreement）で取り決められる値を用いることができる。

（４）増強条件設定は、サーバ規模を増強する方向のスケーリングにおけるトリガ条件（以下、増強方向のトリガ条件を増強トリガ条件という。）と、増強させるスケール単位（以下、増強方向のスケール単位を増強スケール単位という。）とを含む。増強スケール単位は、簡便には台数で指定され、固定値および需要に応じた可変値のいずれかを選択することができる。なお、増強スケール単位に需要に応じた可変値が選択された場合に、本発明の実施形態による需要変化に対応させたオートスケーリングが選択されることになる。また、需要に応じた可変値が選択される場合であって、可変値を求める演算方式が複数候補から選択可能である場合は、増強条件設定は、これら演算方式の指定を含むことができる。

増強トリガ条件は、一般的には、スケーリング対象サーバ群のインスタンスの平均ＣＰＵ使用率、平均メモリ使用率、平均入出力利用度、平均スループット、平均コネクション数、平均クライアント数、平均データ通信量および平均応答性能値などの種々のメトリックに対するしきい値条件を挙げることができるが、ウェブシステム１０４全体の過負荷状態を好適に検知してトリガをかける観点からは、上記指定ロードバランサの負荷分散対象となるウェブサーバ群１２０の平均応答時間や平均応答速度などの平均応答性能値に対するしきい値条件を用いることが好ましい。また、代替サーバへの転送が発生するということは、ウェブシステム１０４のサーバ規模が充分ではないことを意味するため、増強トリガ条件は、好適には、上記指定ロードバランサの転送条件と同一の条件を含むことができる。説明する実施形態では、ウェブサーバ群１２０の増強トリガ条件は、上記指定ロードバランサの転送条件に一致させ、ウェブサーバ群１２０の平均応答時間がしきい値Ｒ_{ｔｈｒｅｓｈｏｌｄ}を超えることを条件とする。

また増強トリガ条件は、スケーリング対象サーバ群が複数指定される場合には、各スケーリング対象サーバ群毎に個別に設定することができる。また図３に示すような多層アーキテクチャ構成が採用され、複数のレイヤをスケーリング対象とする場合は、いずれのレイヤが過負荷状態のボトルネックであるかを判定できるような条件を設定することが好ましい。

クラウド提供者側で簡単に観測可能なメトリックで、ウェブサーバ群１２０のインスタンス１２２のＣＰＵに関連するものとしては、ＣＰＵが実際に使用されている時間の割合を示すＣＰＵ使用率（以下、ＣＰＵ％という場合がある。）と、ローカルディスクへの入出力待ちの時間の割合を示す待ち率（以下、ＷＡＩＴ％という場合がある。）と、ＣＰＵが使用されていないアイドル時間の割合を示すアイドル率（以下、ＩＤＬＥ％という場合がある。）とを挙げることができる。上述したように、ウェブサーバ群１２０の平均応答時間がしきい値Ｒ_{ｔｈｒｅｓｈｏｌｄ}を超えるか否かでウェブシステム１０４の過負荷状態が判定される場合、平均応答時間がしきい値を超え過負荷状態であると判定されるにもかかわらず、ウェブサーバ群１２０のインスタンスの平均ＩＤＬＥ％が一定値以上あるときは、ウェブサーバ群１２０でボトルネックが発生しているのではなく、その後段でボトルネックが発生していると推定することができる。このような性質を利用して、ウェブサーバ群１２０の平均ＩＤＬＥ％に対するしきい値Ｕｗ_{ＩＤＬＥ−ｔｈｒｅｓｈｏｌｄ}を用いた条件により、ボトルネックがウェブサーバ群１２０であるか、またはその後段のメモリキャッシュ・サーバ群１３０であるかを判定することができる。説明する実施形態では、メモリキャッシュ・サーバ群１３０に対する増強トリガ条件は、ウェブサーバ群１２０の平均応答時間がしきい値Ｒ_{ｔｈｒｅｓｈｏｌｄ}を超え、かつ、ウェブサーバ群１２０の平均ＩＤＬＥ％がしきい値Ｕｗ_{ＩＤＬＥ−ｔｈｒｅｓｈｏｌｄ}を超えるという条件を用いる。

（５）縮小条件設定は、サーバ規模を縮小する方向のスケーリングにおけるトリガ条件（以下、縮小方向のトリガ条件を縮小トリガ条件という。）と、縮小させるスケール単位（以下、縮小方向のスケール単位を縮小スケール単位という。）とを含む。縮小スケール単位は、簡便には台数で指定され、固定値または需要に応じた可変値を選択することができる。縮小トリガ条件は、上述したものと同様の種々のメトリックに対するしきい値条件を用いることができる。説明する実施形態では、ウェブサーバ群１２０の縮小トリガ条件としては、ウェブサーバ群１２０の平均リソース使用率に対するしきい値Ｕｗ_{ａｖｇ−ｔｈｒｅｓｈｏｌｄ}が用いられ、メモリキャッシュ・サーバ群１３０の縮小トリガ条件は、メモリキャッシュ・サーバ群１３０の平均リソース使用率に対するしきい値Ｕｍ_{ａｖｇ−ｔｈｒｅｓｈｏｌｄ}が用いられる。

図４は、本発明の実施形態によるプロビジョニング・システム１００において、管理ポータルが提供するオートスケーリング設定を行うための管理画面を例示する。図４に示す管理画面２００は、オートスケーリング基本設定タブ２１０ａと、ウェブサーバ群用設定タブ２１０ｂと、メモリキャッシュ・サーバ群用設定タブ２１０ｃとを含む。図４に示す状態では、ウェブサーバ群用設定タブ２１０ｂが選択されており、ウェブサーバ群１２０に関連する設定項目を指定するためのグラフィカル・ユーザ・インタフェース（ＧＵＩ）部品が配置されている。

図４に示す例では、ウェブサーバ群１２０のオートスケーリング機能の有効または無効を選択するチェックボックス２１２と、ウェブサーバ群１２０のスケーリング方式を選択するためのラジオボタン２１４ａ，２１４ｂとが示されている。オートスケーリング方式としては、スケール単位台数固定方式２１４ａと、スケール単位台数可変方式２１４ｂとが選択可能に示されており、図４ではスケール単位台数可変方式２１４ｂが選択されている。なお、本発明の実施形態による需要変化に対応した仮想マシンのオートスケーリング機構は、スケール単位台数可変方式に相当する。

スケール単位台数可変方式２１４ｂの詳細な設定項目としては、増強条件設定と、縮小条件設定とが含まれる。増強条件設定および縮小条件設定は、各プルダウンメニュー２１６，２１８，２２０，２２２の各選択肢を選択することによりそれぞれ設定される。図４は、増強条件設定に関連して、「ロードバランサが計測するウェブサーバ群１２０の平均応答時間が５０ｍｓを上回ること」を転送条件および増強トリガ条件とするという設定内容を表している。また、図４は、ウェブサーバ群１２０の平均ＣＰＵ使用率が２０％以下となることを縮小トリガ条件とし、縮小スケール単位を固定台数１とするという設定内容を表している。なお、図４は、ウェブサーバ群１２０のための管理設定画面を例示しているが、メモリキャッシュ・サーバ群１３０のための管理設定画面や、基本設定のための管理設定画面については、詳細な説明は割愛する。

再び図３を参照すると、管理サーバ１５０は、さらに、オートスケーリング機構を実現するための機能部として、負荷分散設定部１５４と、カウンタ更新部１５６と、目標規模演算部１５８と、縮小規模決定部１６０と、サーバ準備部１６２とを含んで構成される。負荷分散設定部１５４は、クラウド利用者から管理ポータル１５２を介してなされる上記オートスケーリング設定の管理要求に応答して、上述した指定ロードバランサの負荷分散設定をロードバランサ１１０に対して行う。ロードバランサ１１０に対して行われる設定項目としては、具体的には、負荷分散方式の設定、負荷分散対象の仮想マシンおよび代替サーバのＩＰアドレスなどの通信設定、並びに転送条件が含まれる。

ロードバランサ１１０は、上記負荷分散設定部１５４による設定を受けて、インターネット１０２を介して行われるリクエストをウェブサーバ群１２０の各インスタンス１２２に振り分けるとともに、上記転送条件の成立を監視し、上記ウェブシステム１０４が過負荷状態となったことを検知した際には、Ｓｏｒｒｙサーバ１２４へリクエストを転送する。Ｓｏｒｒｙサーバ１２４は、ウェブサーバ群１２０が過負荷状態になった場合に、転送されるリクエストに対し、ユーザに対し混雑中である旨のメッセージを代替して応答するウェブサーバである。また、Ｓｏｒｒｙサーバ１２４は、代替応答という処理に関して、実質的に無限大の処理能力を有すると見なせるサーバである。なお、代替サーバとしてのＳｏｒｒｙサーバは、説明する実施形態では１台としているが、複数台用意してもよい。

本実施形態のロードバランサ１１０は、負荷分散対象である各ウェブサーバ１２２が正常に動作していることを確認するために、また転送条件の成立を監視するために、各ウェブサーバ１２２に対しキープアライブ・パケットを定期的に送り、各ウェブサーバ１２２の応答時間Ｒａ〜Ｒｃをモニタしている。ロードバランサ１１０は、応答時間が所与の時間を越える事象が所与の回数連続して確認された場合、そのウェブサーバ１２２がダウン状態であると判断し、負荷分散対象から切り離す。またロードバランサ１１０は、計測された応答時間の時間平均およびインスタンス平均を計算し、平均応答時間がしきい値Ｒ_{ｔｈｒｅｓｈｏｌｄ}を超え上記転送条件が満たされる場合には、Ｓｏｒｒｙサーバ１２４に対するリクエストの転送を行う。

ロードバランサ１１０がＳｏｒｒｙサーバ１２４へ転送するリクエストとしては、好適には、新規ユーザからのリクエストのみを対象とし、既にセッションを確立している既存ユーザからのリクエストを転送対象から除外することができる。これにより、既存ユーザによる仕掛かり中のセッションに影響を与えずに、過剰なリクエストを処理することが可能となる。また本実施形態のロードバランサ１１０は、ウェブシステム１０４の需要を定量するために、ウェブサーバ群１２０への単位時間当たりの転送量と、Ｓｏｒｒｙサーバ１２４への単位時間当たりの転送量とを計測し、計測値を記憶する。上記転送量は、ウェブサーバ１２２またはＳｏｒｒｙサーバ１２４へ転送されるコネクション数やデータ通信量を用いて定量することができるが、ウェブシステム１０４の需要を正確に定量する観点からは、コネクション数、クライアント数またはセッション数などを用いることが好ましい。これは、ウェブサーバ１２２によるレスポンスでは大きなデータトラフィックが発生し得るのに対して、Ｓｏｒｒｙサーバ１２４へ転送されるリクエストに対しては、混雑中である旨のメッセージという小さなデータのレスポンスを主として発生させるにすぎず、コネクション数、クライアント数またはセッション数を用いた方が、ウェブシステム１０４の需要をより精度良く定量できるためである。

カウンタ更新部１５６は、本発明の実施形態による需要変化に対応させたオートスケーリングを行うために必要な監視カウンタ値を、定期的または不定期に情報を収集して更新する。必要な監視カウンタ値としては、ロードバランサ１１０の平均応答時間Ｒ_ａｖｇ、ウェブサーバ群１２０への単位時間当たりの転送量Ｔ_ｗｅｂ、Ｓｏｒｒｙサーバ１２４への単位時間当たりの転送量Ｔ_{ｓｏｒｒｙ}といったロードバランサ１１０から取得されるメトリックが含まれる。必要な監視カウンタ値としては、さらに、ウェブサーバ群１２０のインスタンス１２２の平均ＣＰＵ％Ｕｗ_ＣＰＵ、平均ＷＡＩＴ％Ｕｗ_ＷＡＩＴおよびＩＤＬＥ％Ｕｗ_ＩＤＬＥ、並びにメモリキャッシュ・サーバ群１３０のインスタンス１３２のＣＰＵ％Ｕｍ_ＣＰＵ、ＷＡＩＴ％Ｕｍ_ＷＡＩＴおよびＩＤＬＥ％Ｕｍ_ＩＤＬＥといったスケール対象サーバ群のインスタンスから取得されるメトリックが含まれる。これらインスタンスから取得されるメトリックは、時間平均またはインスタンス平均が計算されてカウンタに保持される。なお、上記ウェブサーバ群１２０のインスタンス１２２の平均ＣＰＵ％Ｕｗ_ＣＰＵおよび平均ＷＡＩＴ％Ｕｗ_ＷＡＩＴは、上記ウェブサーバ１２２のローカルな負荷を評価する評価指標として用いられ、ＩＤＬＥ％Ｕｗ_ＩＤＬＥは、上述したボトルネックを判定するための評価指標として用いられる。必要な監視カウンタ値としては、さらに、ウェブサーバ群１２０において稼働中のインスタンス数Ｎ_{ｒｕｎｎｉｎｇ}および準備中のインスタンス数Ｎ_{ｐｒｏｖｉｓｉｏｎｉｎｇ}、並びにメモリキャッシュ・サーバ群１３０において稼働中のインスタンス数Ｍ_{ｒｕｎｎｉｎｇ}および準備中のインスタンス数Ｍ_{ｐｒｏｖｉｓｉｏｎｉｎｇ}といった仮想マシンのプロビジョニングを管理するサーバ準備部１６２から取得される状態変数が含まれる。カウンタ更新部１５６は、本実施形態の転送量取得部を構成する。

目標規模演算部１５８は、更新される監視カウンタ値を参照して、増強トリガ条件の成立を監視し、増強トリガ条件が成立した場合に、指定ロードバランサにより処理サーバ群へ転送される単位時間当たりの転送量と、代替サーバへ転送される単位時間当たりの転送量とを基準として、処理サーバ群の目標サーバ規模を演算する。図３に示す例では、目標規模演算部１５８は、ウェブサーバ群１２０への転送量Ｔ_ｗｅｂと、Ｓｏｒｒｙサーバ１２４への転送量Ｔ_ｗｅｂとから、ウェブシステム１０４の需要を定量し、需要に応じてウェブサーバ群１２０およびメモリキャッシュ・サーバ群１３０の目標サーバ規模を演算する。上述した目標サーバ規模は、目標とすべきサーバの規模を表し、サーバ群のインスタンスのスペックが概ね同一であれば、単純にサーバ台数（インスタンス数）で定量することができる。処理サーバ群のインスタンスのスペックが異なる場合は、適宜各インスタンスのスペックに応じて適切な補正を施せばよい。なお、本実施形態では、説明の便宜上、目標サーバ規模をサーバ台数で定量する。下記式（１）〜（３）は、目標サーバ規模を求めるための演算式を例示する。なお、下記式（１）〜（３）中の関数Ｃｅｉｌ（）は、天井関数を表す。

上記式（１）および式（２）は、それぞれ、ウェブサーバ群１２０のみをスケーリング対象とした場合に用いることができる演算式を表す。上記式（２）および式（３）は、ウェブサーバ群１２０およびメモリキャッシュ・サーバ群１３０の両方をスケーリング対象とした場合に、ウェブサーバ群１２０およびメモリキャッシュ・サーバ群１３０それぞれについて用いられる演算式を表す。上記式（１）および上記式（２）は、ウェブサーバ群１２０の目標サーバ規模Ｎ_{ｔａｒｇｅｔ}を算出し、上記式（３）は、メモリキャッシュ・サーバ群１３０の目標サーバ規模Ｍ_{ｔａｒｇｅｔ}を演算するための演算式を表す。上記式（２）中、（Ｕｗ_ＣＰＵ＋Ｕｗ_ＷＡＩＴ）は、ウェブサーバ１２２のローカルでの負荷の評価を反映させるために導入されたものである。

目標規模演算部１５８は、さらに、上記目標サーバ規模と現在のサーバ規模との差分から、増強スケール単位を計算し、サーバ準備部１６２に対し、処理サーバ群のインスタンスのプロビジョニングを依頼する。現在のサーバ規模および増強スケール単位も同様に、処理サーバ群のインスタンスのスペックが概ね同一であれば、単純にサーバ台数で定量することができ、本実施形態では、説明の便宜上、上述した現在のサーバ規模およびスケール単位をサーバ台数で定量する。現在のサーバ規模は、観測時点での稼働中のインスタンスの台数と、プロビジョニングが完了していない準備中のインスタンスの台数との和で求められ、増強スケール単位は、目標サーバ規模と現在のサーバ規模との差分として求められる。説明する実施形態では、目標規模演算部１５８は、ウェブサーバ群１２０の目標サーバ規模Ｎ_{ｔａｒｇｅｔ}と現在のサーバ規模（Ｎ_{ｒｕｎｎｉｎｇ}＋Ｎ_{ｐｒｏｖｉｓｉｏｎｉｎｇ}）との差分からウェブサーバ群１２０のインスタンスの追加台数Ｎ_ａｄｄを算出し、必要に応じて、メモリキャッシュ・サーバ群１３０の目標サーバ規模Ｍ_{ｔａｒｇｅｔ}と現在のサーバ規模（Ｍ_{ｒｕｎｎｉｎｇ}＋Ｍ_{ｐｒｏｖｉｓｉｏｎｉｎｇ}）との差分からメモリキャッシュ・サーバ群１３０のインスタンスの追加台数Ｍ_ａｄｄを算出することができる。

なお、説明する実施形態では、ウェブサーバ群１２０の目標サーバ規模Ｎ_{ｔａｒｇｅｔ}と現在のサーバ規模（Ｎ_{ｒｕｎｎｉｎｇ}＋Ｎ_{ｐｒｏｖｉｓｉｏｎｉｎｇ}）との差分からウェブサーバ群１２０のインスタンスの追加台数Ｎ_ａｄｄを算出し、一律に追加台数として決定するものとして説明する。しかしながら、他の実施形態では、履歴を用いた需要予測を行う手法と組み合わせることもできる。例えば、ロードバランサを用いて定量された需要に応じて目標サーバ規模を求めるとともに、履歴情報を用いた需要予測により予測サーバ規模を求め、ロードバランサを用いて定量された需要が、履歴情報からの需要予測よりも過小評価されている場合に、需要予測に基づいて求められたサーバ規模を選択することができる。これにより、予測できない需要変化に対応させつつ、需要予測からの補正を行うことが可能となる。

縮小規模決定部１６０は、更新されるカウンタを参照して縮小トリガ条件の成立を監視し、縮小トリガ条件が成立した場合に、処理サーバ群の縮小サーバ規模を決定する。縮小規模決定部１６０は、縮小スケール単位が、固定台数であればその値に決定し、可変台数であれば、リソース使用率から適切なサーバ規模を演算し、現在のサーバ規模と演算したサーバ規模との差分から必要な縮小スケール単位を求めることができる。なお、縮小スケーリングの際の適切なサーバ規模は、縮小スケーリング時は通常余剰リソースが存在するため、上述した転送量を用いずともＣＰＵ使用率などのリソース使用率から簡単に計算することができる。図３に示す実施形態では、縮小規模決定部１６０は、ウェブサーバ群１２０のインスタンスの除去台数Ｎ_{ｒｅｍｏｖｅ}を決定し、必要に応じてメモリキャッシュ・サーバ群１３０のインスタンスの除去台数Ｍ_{ｒｅｍｏｖｅ}を決定することができる。

サーバ準備部１６２は、増強方向のスケーリングにおいては、処理サーバ群の現在のサーバ規模から目標サーバ規模へ増強するため、処理サーバ群のインスタンスをプロビジョニングする処理を行う。さらに、サーバ準備部１６２は、縮小方向のスケーリングにおいては、縮小規模決定部１６０が決定した縮小スケール単位に応じて、処理サーバ群のインスタンスのシャットダウンする処理を行う。図３に示す実施形態では、サーバ準備部１６２は、増強方向のスケーリングでは、目標規模演算部１５８により演算された追加台数Ｎ_ａｄｄのウェブサーバ群１２０のインスタンスのプロビジョニングを実行し、適宜、追加台数Ｍ_ａｄｄのメモリキャッシュ・サーバ群１３０のインスタンスのプロビジョニングを実行する。また、サーバ準備部１６２は、稼働中インスタンス数Ｎ_{ｒｕｎｎｉｎｇ}，Ｍ_{ｒｕｎｎｉｎｇ}と、準備中インスタンス数Ｎ_{ｐｒｏｖｉｓｉｏｎｉｎｇ}，Ｍ_{ｐｒｏｖｉｓｉｏｎｉｎｇ}とを管理しており、カウンタ更新部１５６に通知する。縮小方向のスケーリングでは、サーバ準備部１６２は、縮小規模決定部１６０により決定された除去台数Ｎ_{ｒｅｍｏｖｅ}，Ｍ_{ｒｅｍｏｖｅ，}のウェブサーバ群１２０およびメモリキャッシュ・サーバ群１３０のインスタンスのシャットダウンを実行することができる。

図５は、本発明の実施形態によるプロビジョニング・システムにおいて実現される、需要変化に対応させたオートスケーリング処理を示すフローチャートである。なお、図５は、ウェブサーバ群１２０のみをスケーリング対象サーバ群とし、上記式（１）を用いて目標サーバ規模を演算する場合のオートスケーリング処理を示す。また、図５に示す処理が開始される時点において、ウェブサーバ群１２０、メモリキャッシュ・サーバ群１３０およびデータベース・サーバ群１４０の各インスタンスは、既に所定数配備されており、転送条件および増強トリガ条件である平均応答時間に対するしきい値Ｒ_{ｔｈｒｅｓｈｏｌｄ}、ウェブサーバ群１２０の最小マシン数Ｎ_ｍｉｎ、縮小条件としてのウェブサーバ群１２０の平均リソース使用率に対するしきい値Ｕｗ_{ａｖｇ−ｔｈｒｅｓｈｏｌｄ}を含むオートスケーリング設定が設定済みであるとして説明する。

図５に示す処理は、例えばウェブシステム１０４のオートスケーリング機能が有効化されたことに応答してステップＳ１００から開始される。ステップＳ１０１では、カウンタ更新部１５６は、ロードバランサ１１０、ウェブサーバ１２２およびサーバ準備部１６２から情報を収集し、監視カウンタ値を更新する。図５に示す処理で用いられる監視カウンタ値は、平均応答時間Ｒ_ａｖｇ、ウェブサーバ群１２０への単位時間当たりの転送量Ｔ_ｗｅｂ、Ｓｏｒｒｙサーバ１２４への単位時間当たりの転送量Ｔ_{ｓｏｒｒｙ}、ウェブサーバ群１２０の平均リソース使用率Ｕｗ_ａｖｇ、ウェブサーバ群１２０の稼働中インスタンス数Ｎ_{ｒｕｎｎｉｎｇ}、ウェブサーバ群１２０の準備中インスタンス数Ｎ_{ｐｒｏｖｉｓｉｏｎｉｎｇ}である。

ステップＳ１０２では、目標規模演算部１５８は、監視カウンタ値を参照して、平均応答時間Ｒ_ａｖｇがしきい値Ｒ_{ｔｈｒｅｓｈｏｌｄ}を超えているか否かを判定する。ステップＳ１０２で、平均応答時間Ｒ_ａｖｇがしきい値Ｒ_{ｔｈｒｅｓｈｏｌｄ}を超えていると判定された場合（ＹＥＳ）には、ステップＳ１０３へ処理が進められる。ステップＳ１０３では、目標規模演算部１５８は、上記監視カウンタ値を参照し、上記式（１）に従いウェブサーバ群１２０の目標サーバ規模Ｎ_{ｔａｒｇｅｔ}を演算する。ステップＳ１０４では、目標規模演算部１５８は、目標サーバ規模Ｎ_{ｔａｒｇｅｔ}と、稼働中および準備中のインスタンス数の和（Ｎ_{ｒｕｎｎｉｎｇ}＋Ｎ_{ｐｒｏｖｉｓｉｏｎｉｎｇ}）とを比較して、目標サーバ規模Ｎ_{ｔａｒｇｅｔ}の方が大きいか否かを判定する。ステップＳ１０４で、目標サーバ規模Ｎ_{ｔａｒｇｅｔ}の方が大きいと判定された場合（ＹＥＳ）には、ステップＳ１０５へ処理が進められる。ステップＳ１０５では、目標規模演算部１５８は、目標サーバ規模と現在規模との差分（Ｎ_{ｔａｒｇｅｔ}−（Ｎ_{ｒｕｎｎｉｎｇ}＋Ｎ_{ｐｒｏｖｉｓｉｏｎｉｎｇ}））を算出し、これを追加台数Ｎ_ａｄｄとして、サーバ準備部１６２にプロビジョニングを依頼する。

ステップＳ１０６では、サーバ準備部１６２は、適当な物理ホストマシン１０を選択して、物理ホストマシン１０上の制御モジュール４６に対しプロビジョニングを要求し、合計Ｎ_ａｄｄ台のウェブサーバ群１２０のインスタンスを準備し、所与のインターバルが経過した後ステップＳ１０１へ処理をループし、カウンタ更新および増強トリガ条件の成立の監視を繰り返す。一方、ステップＳ１０４で、目標サーバ規模Ｎ_{ｔａｒｇｅｔ}の方が大きくないと判定された場合（ＮＯ）は、適当なインターバルが経過した後、直接ステップＳ１０１へ処理をループし、カウンタ更新およびトリガ条件の成立の監視を繰り返す。

一方、ステップＳ１０２で、平均応答時間Ｒ_ａｖｇがしきい値Ｒ_{ｔｈｒｅｓｈｏｌｄ}を超えないと判定された場合（ＮＯ）には、ステップＳ１０７へ処理が分岐される。この場合は、増強トリガ条件が成立しておらず、続いて、縮小トリガ条件の成立を監視する。ステップＳ１０７では、縮小規模決定部１６０は、ウェブサーバ群１２０の準備中インスタンスが存在せず（Ｎ_{ｐｒｏｖｉｓｉｏｎｉｎｇ}＝０）、かつ、ウェブサーバ群１２０の稼働中インスタンス数が最小マシン数Ｎ_ｍｉｎを超えており（Ｎ_{ｒｕｎｎｉｎｇ}＞Ｎ_ｍｉｎ）、かつウェブサーバ群１２０の平均リソース使用率Ｕｗ_ａｖｇが閾値Ｕｗ_{ａｖｇ−ｔｈｒｅｓｏｌｄ}未満であるか否かを判定する。ここで、平均リソース使用率Ｕｗ_ａｖｇは、ウェブサーバ群１２０のローカルの負荷を指標するものであり、例えばウェブサーバ群１２０の平均ＣＰＵ使用率ＣＰＵ％、または平均ＣＰＵ使用率ＣＰＵ％と待ち率ＷＡＩＴ％との和を用いることができる。

ステップＳ１０７で、すべての条件が満たされると判定された場合（ＹＥＳ）には、ステップＳ１０８へ処理を進める。ステップＳ１０８では、縮小規模決定部１６０は、現時点の稼働中インスタンス数Ｎ_{ｒｕｎｎｉｎｇ}から除去台数Ｎ_{ｒｅｍｏｖｅ}のインスタンスを除去する結果として最小マシン数Ｎ_ｍｉｎを下回らない限度において、除去台数Ｎ_{ｒｅｍｏｖｅ}を決定し、サーバ準備部１６２にシャットダウンを依頼する。例えば、縮小条件として除去台数に固定数が設定されているのであれば、上記限度を満たす範囲で１〜固定数を除去台数Ｎ_{ｒｅｍｏｖｅ}として決定する。縮小条件として除去台数に可変数が設定されているのであれば、可変数を一旦計算し、上記限度を満たす範囲で１〜可変数を除去台数Ｎ_{ｒｅｍｏｖｅ}として決定する。可変数の値は、上述したように、ウェブサーバ群１２０の平均リソース使用率Ｕｗ_ａｖｇから求めることができる。

ステップＳ１０９では、サーバ準備部１６２は、ウェブサーバ群１２０の全インスタンスから上記除去台数Ｎ_{ｒｅｍｏｖｅ}分のインスタンスを選択して、選択されたインスタンスが稼働する各物理ホストマシン１０の制御モジュール４６に対しシャットダウンを要求し、合計Ｎ_{Ｒｅｍｏｖｅ}個のウェブサーバ群１２０のインスタンスを除去し、適当なインターバルが経過した後ステップＳ１０１へ処理をループし、カウンタ更新およびトリガ条件の成立の監視を繰り返す。一方、ステップＳ１０７で、すべての条件が満たされるわけではないと判定された場合（ＮＯ）には、適当なインターバルが経過した後、直接ステップＳ１０１へ処理をループし、カウンタ更新およびトリガ条件の成立の監視を繰り返す。

図６および図７は、本発明の実施形態によるプロビジョニング・システムにおいて実現される、需要変化に対応させた他のオートスケーリング処理を示すフローチャートである。なお、図６および図７は、ウェブサーバ群１２０およびメモリキャッシュ・サーバ群１３０の両方をスケーリング対象サーバ群とし、上記式（２）および式（３）を用いて各目標サーバ規模を演算する場合のオートスケーリング処理を示す。また、図６および図７に示す処理が開始される時点において、図５と同様に、ウェブサーバ群１２０、メモリキャッシュ・サーバ群１３０およびデータベース・サーバ群１４０の各インスタンスは、既に所定数配備されており、転送条件および増強トリガ条件である平均応答時間に対するしきい値Ｒ_{ｔｈｒｅｓｈｏｌｄ}と、メモリキャッシュ・サーバ群１３０の増強トリガ条件であるウェブサーバ群１２０の平均ＩＤＬＥ％に対するしきい値Ｕｗ_{ＩＤＬＥ−ｔｈｒｅｓｈｏｌｄ}と、ウェブサーバ群１２０の最小マシン数Ｎ_ｍｉｎと、メモリキャッシュ・サーバ群１３０の最小マシン数Ｍ_ｍｉｎと、縮小条件としてのウェブサーバ群１２０の平均リソース使用率Ｕｗ_ａｖｇに対するしきい値Ｕｗ_{ａｖｇ−ｔｈｒｅｓｈｏｌｄ}、メモリキャッシュ・サーバ群１３０の平均リソース使用率Ｕｍ_ａｖｇに対するしきい値Ｕｍ_{ａｖｇ−ｔｈｒｅｓｈｏｌｄ}とを含むオートスケーリング設定が設定済みであるとして説明する。

図６および図７に示す処理は、例えばウェブシステム１０４のオートスケーリング機能が有効化されたことに応答してステップＳ２００から開始される。ステップＳ２０１では、カウンタ更新部１５６は、ロードバランサ１１０、ウェブサーバ１２２、メモリキャッシュ・サーバ１３２およびサーバ準備部１６２から情報を収集し、監視カウンタ値を更新する。図６および図７に示す処理で用いられる監視カウンタ値は、図５を参照して説明した平均応答時間Ｒ_ａｖｇ、ウェブサーバ群１２０への転送量Ｔ_ｗｅｂ、Ｓｏｒｒｙサーバ１２４への転送量Ｔ_{ｓｏｒｒｙ}、平均リソース使用率Ｕｗ_ａｖｇ、稼働中インスタンス数Ｎ_{ｒｕｎｎｉｎｇ}、準備中インスタンス数Ｎ_{ｐｒｏｖｉｓｉｏｎｉｎｇ}に加えて、さらに、メモリキャッシュ・サーバ群１３０の平均リソース使用率Ｕｍ_ａｖｇと、メモリキャッシュ・サーバ群１３０の稼働中インスタンス数Ｍ_{ｒｕｎｎｉｎｇ}と、メモリキャッシュ・サーバ群１３０の準備中インスタンス数Ｍ_{ｐｒｏｖｉｓｉｏｎｉｎｇ}とを含む。

ステップＳ２０２では、目標規模演算部１５８は、監視カウンタ値を参照して、平均応答時間Ｒ_ａｖｇがしきい値Ｒ_{ｔｈｒｅｓｈｏｌｄ}を超えているか否かを判定する。ステップＳ２０２で、平均応答時間Ｒ_ａｖｇがしきい値Ｒ_{ｔｈｒｅｓｈｏｌｄ}を超えていると判定された場合（ＹＥＳ）には、ステップＳ２０３へ処理が進められる。ステップＳ２０３では、目標規模演算部１５８は、監視カウンタ値を参照して、上記メモリキャッシュ・サーバ群１３０の増強トリガ条件のひとつであるウェブサーバ群１２０の平均ＩＤＬＥ％Ｕｗ_ＩＤＬＥがしきい値Ｕｗ_{ＩＤＬＥ−ｔｈｒｅｓｈｏｌｄ}を超えているか否かを判定する。ステップＳ２０３で、平均ＩＤＬＥ％Ｕｗ_ＩＤＬＥがしきい値Ｕｗ_{ＩＤＬＥ−ｔｈｒｅｓｈｏｌｄ}を超えていると判定された場合（ＹＥＳ）には、ステップＳ２０４へ処理が進められる。

ステップＳ２０４では、目標規模演算部１５８は、上記監視カウンタ値を参照し、上記式（３）に従いメモリキャッシュ・サーバ群１３０の目標サーバ規模Ｍ_{ｔａｒｇｅｔ}を演算する。ステップＳ２０５では、目標規模演算部１５８は、メモリキャッシュ・サーバ群１３０の目標サーバ規模Ｍ_{ｔａｒｇｅｔ}の方が、稼働中および準備中のインスタンスの和（Ｍ_{ｒｕｎｎｉｎｇ}＋Ｍ_{ｐｒｏｖｉｓｉｏｎｉｎｇ}）よりも大きいか否かを判定する。ステップＳ２０５で、目標サーバ規模Ｍ_{ｔａｒｇｅｔ}の方が大きいと判定された場合（ＹＥＳ）には、ステップＳ２０６へ処理が進められる。ステップＳ２０６では、目標規模演算部１５８は、目標サーバ規模と現在規模との差分（Ｍ_{ｔａｒｇｅｔ}−（Ｍ_{ｒｕｎｎｉｎｇ}＋Ｍ_{ｐｒｏｖｉｓｉｏｎｉｎｇ}））を算出し、これをメモリキャッシュ・サーバ１３２の追加台数Ｍ_ａｄｄとして、サーバ準備部１６２にプロビジョニングを依頼する。ステップＳ２０７では、サーバ準備部１６２は、適当な物理ホストマシン１０を選択してプロビジョニングを要求し、合計Ｍ_ａｄｄ台のメモリキャッシュ・サーバ群１３０のインスタンスを準備し、ステップＳ２０８へ処理を進める。

ステップＳ２０３で、平均ＩＤＬＥ％Ｕｗ_ＩＤＬＥがしきい値Ｕｗ_{ＩＤＬＥ−ｔｈｒｅｓｈｏｌｄ}を超えていないと判定された場合（ＮＯ）、およびステップＳ２０５で目標サーバ規模Ｍ_{ｔａｒｇｅｔ}の方が大きくはないと判定された場合（ＮＯ）には、直接ステップＳ２０８へ処理を進める。ステップＳ２０８では、目標規模演算部１５８は、上記監視カウンタ値を参照し、上記式（２）に従いウェブサーバ群１２０の目標サーバ規模Ｎ_{ｔａｒｇｅｔ}を演算する。ステップＳ２０９では、目標規模演算部１５８は、ウェブサーバ群１２０の目標サーバ規模Ｎ_{ｔａｒｇｅｔ}の方が稼働中および準備中のインスタンスの和（Ｎ_{ｒｕｎｎｉｎｇ}＋Ｎ_{ｐｒｏｖｉｓｉｏｎｉｎｇ}）よりも大きいか否かを判定する。

ステップＳ２０９で、目標サーバ規模Ｎ_{ｔａｒｇｅｔ}の方が大きいと判定された場合（ＹＥＳ）には、ステップＳ２１０へ処理が進められる。ステップＳ２１０では、目標規模演算部１５８は、目標サーバ規模と現在規模との差分（Ｎ_{ｔａｒｇｅｔ}−（Ｎ_{ｒｕｎｎｉｎｇ}＋Ｎ_{ｐｒｏｖｉｓｉｏｎｉｎｇ}））をウェブサーバ１２２の追加台数Ｎ_ａｄｄとして、サーバ準備部１６２にプロビジョニングを依頼する。ステップＳ２１１では、サーバ準備部１６２は、適当な物理ホストマシン１０を選択してプロビジョニングを要求し、合計Ｎ_ａｄｄ台のウェブサーバ群１２０のインスタンスを準備し、所与のインターバルが経過した後ステップＳ２０１へ処理をループし、カウンタ更新および増強トリガ条件の成立の監視を繰り返す。ステップＳ２０９で、目標サーバ規模Ｎ_{ｔａｒｇｅｔ}の方が大きくはないと判定された場合（ＮＯ）には、所与のインターバルが経過した後ステップＳ２０１へ処理をループさせられる。

一方、ステップＳ２０２で、平均応答時間Ｒ_ａｖｇがしきい値Ｒ_{ｔｈｒｅｓｈｏｌｄ}を超えないと判定された場合（ＮＯ）には、ポイントＡを経て、図７に示すステップＳ２１２へ処理が分岐される。この場合は、増強トリガ条件が成立しておらず、続けて縮小トリガ条件の成立を監視する。ステップＳ２１２では、縮小規模決定部１６０は、ウェブサーバ群１２０の準備中インスタンスが存在せず（Ｎ_{ｐｒｏｖｉｓｉｏｎｉｎｇ}＝０）、かつ、ウェブサーバ群１２０の稼働中インスタンス数が最小マシン数Ｎ_ｍｉｎを超えており（Ｎ_{ｒｕｎｎｉｎｇ}＞Ｎ_ｍｉｎ）、かつウェブサーバ１２２の平均リソース使用率Ｕｗ_ａｖｇが閾値Ｕｗ_{ａｖｇ−ｔｈｒｅｓｏｌｄ}未満であるか否かを判定する。ステップＳ２１２で、すべての条件が満たされると判定された場合（ＹＥＳ）には、ステップＳ２１３へ処理を進める。ステップＳ２１３では、縮小規模決定部１６０は、現時点の稼働中インスタンス数Ｎ_{ｒｕｎｎｉｎｇ}から除去台数Ｎ_{ｒｅｍｏｖｅ}のインスタンスを除去する結果として最小マシン数Ｎ_ｍｉｎを下回らない限度において、除去台数Ｎ_{ｒｅｍｏｖｅ}を決定し、サーバ準備部１６２にシャットダウンを依頼する。ステップＳ２１４では、サーバ準備部１６２は、ウェブサーバ群１２０のインスタンスを稼働させている物理ホストマシン１０に対しシャットダウンを要求し、合計Ｎ_{ｒｅｍｏｖｅ}台のインスタンスを除去し、ステップＳ２１５へ処理を進める。ステップＳ２１２で、すべての条件が満たされるわけではないと判定された場合（ＮＯ）には、直接ステップＳ２１５へ処理を進める。

ステップＳ２１５では、縮小規模決定部１６０は、メモリキャッシュ・サーバ群１３０の準備中インスタンスが存在せず（Ｍ_{ｐｒｏｖｉｓｉｏｎｉｎｇ}＝０）、かつ、メモリキャッシュ・サーバ群１３０の稼働中インスタンス数が最小マシン数を超えており（Ｍ_{ｒｕｎｎｉｎｇ}＞Ｍ_ｍｉｎ）、かつメモリキャッシュ・サーバ１３２の平均リソース使用率Ｕｍ_ａｖｇがしきい値Ｕｍ_{ａｖｇ−ｔｈｒｅｓｏｌｄ}未満であるか否かを判定する。ステップＳ２１５で、すべての条件が満たされると判定された場合（ＹＥＳ）には、ステップＳ２１６へ処理を進める。ステップＳ２１６では、縮小規模決定部１６０は、現時点の稼働中インスタンス数Ｍ_{ｒｕｎｎｉｎｇ}から除去台数Ｍ_{ｒｅｍｏｖｅ}のインスタンスを除去する結果として最小マシン数Ｍ_ｍｉｎを下回らない限度において、除去台数Ｍ_{ｒｅｍｏｖｅ}を決定し、サーバ準備部１６２にシャットダウンを依頼する。ステップＳ２１７では、サーバ準備部１６２は、メモリキャッシュ・サーバ群１３０のインスタンスを稼働させている物理ホストマシン１０に対しシャットダウンを要求し、合計Ｍ_{ｒｅｍｏｖｅ}個のインスタンスを除去し、適当なインターバルが経過した後、ポイントＢを経て図６に示すステップＳ２０１へ処理をループし、カウンタ更新およびトリガ条件の成立の監視を繰り返す。一方、ステップＳ２１５で、すべての条件が満たされるわけではないと判定された場合（ＮＯ）には、適当なインターバルが経過した後、直接ポイントＢを経て図６に示すステップＳ２０１へ処理をループし、カウンタ更新およびトリガ条件の成立の監視を繰り返す。

図８は、本発明の実施形態によるプロビジョニング・システムにおいて、他の多層アーキテクチャ構成を採用するウェブシステムをスケーリングする事例について説明する図である。図８に示すウェブシステム３００において、需要変化に応じたオートスケーリングを行う場合、スケーリング対象サーバ群として、さらにアプリケーション・サーバ群３４４を追加することができる。この場合、アプリケーション・サーバ群３４４の目標サーバ規模は、ウェブサーバ群３２０の目標サーバ規模に連動させて、または上記（１）〜（３）と同様な演算式を用いて独立して求めればよい。

以上説明した本発明の実施形態のオートスケーリング機構によれば、増強方向のスケーリングにおいて、ロードバランサにより処理サーバ群へ転送されるトラフィックの転送量と、代替サーバへ転送されるトラフィックの転送量とを用いてウェブシステムの需要が定量され、定量された需要から求められた目標サーバ規模と、現在のサーバ規模との差分を補うように処理サーバ群のインスタンスが準備される。

増強方向のスケーリングにおいては、一般に、システムの潜在的な需要を定量することは困難である。図９は、従来技術のオートスケーリングによるウェブサーバのインスタンス数の経時変化を示すグラフである。図９に示す従来技術のオートスケーリングでは、平均ＣＰＵ使用率が８０％以上となった場合に新たに１台のインスタンスを追加し、平均ＣＰＵ使用率が２０％以下となった場合に１台のインスタンスを除去するという定義によるものである。図９においては、ウェブサーバの平均ＣＰＵ使用率の経時変化を棒グラフ（左軸）で示し、ウェブサーバのインスタンス数を折れ線グラフ（右軸）で表している。図９を参照すると、急激に増加されたウェブトラフィックに対応して、平均ＣＰＵ使用率がほぼ飽和状態となり、一方、ウェブサーバのインスタンスが順次追加され、１時間以上をかけて最終的な１４台までウェブサーバのインスタンスが起動されている様子がわかる。

図９に示す従来技術では、スケール単位台数が固定台数であり、固定台数分のインスタンスで賄える負荷を超えた需要には迅速対応することができず、インスタンスの起動時間分だけ需要の変化への追従に遅れが生じてしまう可能性がある。また固定台数ずつ増加させるため、不必要なインスタンスが準備されてしまう可能性もある。仮にスケール台数を負荷に応じて可変にしようとしても、過負荷状態にあるサーバのスループットはそれ以上増えないため、ＣＰＵの平均使用率やネットワーク流量などのメトリックは飽和してしまい、需要に見合った追加台数を見積もることは通常困難である。例えば、図９に示す例において、当初より最終的に必要となった１４台分の１４００％の合計ＣＰＵ使用率を測定することができれば、１４台のインスタンスを一挙に起動することができるが、棒グラフにも示すように、平均ＣＰＵ使用率は１００％で飽和するため、平均ＣＰＵ使用率をメトリックとしても需要を正確に見積もることはできない。これは、ネットワーク流量、メモリ使用率などの各インスタンスから取得されるメトリックを用いる場合でも同様である。

これに対して本発明の実施形態のオートスケーリング機構では、ロードバランサおよび代替サーバを用いており、ロードバランサにより処理サーバ群へ転送されるトラフィックの転送量と、代替サーバへ転送されるトラフィックの転送量とを用いてウェブシステムの需要が定量されるため、上記ＣＰＵやネットワーク流量などのメトリックが飽和してしまうような需要変化があっても、正しく需要を定量することができ、ひいては、予想できない需要変化に対しても迅速に対応することが可能である。さらに、代替サーバは、代替応答という処理に関しては、実質的に無限大の処理能力を有すると見なせるサーバであり、容易にはスループットが飽和しないため、現時点のサーバ規模で賄える需要を大幅に超える急変が起こったとしても需要を正確に定量することが可能となる。

また、本発明の実施形態では、ロードバランサおよび仮想マシンから取得されるメトリックだけを用いて目標サーバ規模を求めることができるため、仮想マシン自体の構成がクラウド利用者側にゆだねられるためにクラウド提供者側でその内部情報を取得することが一般に困難であるクラウド環境においても、正確なリアクティブ・オートスケーリングを実現することが可能となる。

また、上述したオートスケーリング機構によれば、エンドユーザは、トラフィック急増時の待ち時間が低減されるというメリットを得ることができる。さらに、新規リクエストのみを代替サーバへの転送対象とすれば、エンドユーザは、さらに、混雑時でも既存のセッションがタイムアウトすることがないというメリットを得ることができる。また、クラウド利用者側の視点では、サーバダウンによるチャンスロスを低減し、不必要なサーバを減らすことで運用コストを削減し、詳細な需要予測や監視に費やす人件費を削減できるというメリットを得ることができる。

以上説明したように、本発明の実施形態によれば、予想外の需要変化が突発的に起こった場合にも対応してサーバ規模を増加させられるオートスケーリング機構を実現する、情報処理システム、情報処理装置、スケーリング方法、プログラムおよび記録媒体を提供することができる。

本発明の実施形態によるプロビジョニング・システムは、コンピュータ実行可能なプログラムを、コンピュータ・システムにロードして各機能部を実現することにより提供される。このようなプログラムとしては、例えば、ＦＯＲＴＲＡＮ、ＣＯＢＯＬ、ＰＬ／Ｉ、Ｃ、Ｃ＋＋、Ｊａｖａ（登録商標）、Ｊａｖａ（登録商標）Ｂｅａｎｓ、Ｊａｖａ（登録商標）Ａｐｐｌｅｔ、Ｊａｖａ（登録商標）Ｓｃｒｉｐｔ、Ｐｅｒｌ、Ｒｕｂｙなどのレガシー・プログラミング言語や、オブジェクト指向プログラミング言語などで記述された、コンピュータ実行可能なプログラムにより実現でき、装置可読な記録媒体に格納して頒布することができる。

これまで本発明を図面に示した実施形態および実施例をもって説明してきたが、本発明は図面に示した実施形態に限定されるものではなく、他の実施形態、追加、変更、削除など、当業者が想到することができる範囲内で変更することができ、いずれの態様においても本発明の作用・効果を奏する限り、本発明の範囲に含まれるものである。

１０…物理ホストマシン、２０…ハードウェア・リソース、２２…ＣＰＵ、２４…メモリ、２６…ストレージ、２８…ＮＩＣ、３０…ハイパーバイザ、４０…管理用仮想マシン、４２…仮想リソース、４４…管理用ＯＳ、４６…制御モジュール、５０…ユーザドメイン仮想マシン、５２…仮想ＣＰＵ、５４…仮想メモリ、５６…仮想ディスク、５８…仮想ＮＩＣ、６０…ゲストＯＳ、６２，６４…アプリケーション、１００…プロビジョニング・システム、１０２…インターネット、１０４，３００…ウェブシステム、１１０…ロードバランサ、１２０，３２０…ウェブサーバ群、１２２，３２２…ウェブサーバ、１２４，３２４…Ｓｏｒｒｙサーバ、１２６，３２６…ロードバランサ、１３０，３３０…メモリキャッシュ・サーバ群、１３２，３３２…メモリキャッシュ・サーバ、１４０，３４０…データベース・サーバ群、１４２，３４２…データベース・サーバ、１５０…管理サーバ、１５２…管理ポータル、１５４…負荷分散設定部、１５６…カウンタ更新部、１５８…目標規模演算部、１６０…縮小規模決定部、１６２…サーバ準備部、１７０…管理端末、１７２…ウェブ・ブラウザ、１８０…クライアント端末、２００…管理画面、２１０…タブ、２１２…チェックボックス、２１４…ラジオボタン、２１６〜２２２…プルダウンメニュー、ボタン、３４４…アプリケーション・サーバ群、３４６…アプリケーション・サーバ

Claims (17)

1. 複数の処理サーバを含む処理サーバ群と、
   前記処理サーバ群に代替して応答するための代替サーバと、
   前記処理サーバ群の各処理サーバにトラフィックを分散するとともに、前記処理サーバ群が過負荷状態となった際に前記代替サーバにトラフィックを転送するロードバランサと、
   前記ロードバランサにより前記処理サーバ群へ転送される転送量と前記代替サーバへ転送される転送量とに応じて、前記処理サーバ群の目標規模を演算する目標規模演算部と、
   前記処理サーバ群の現在の規模から目標規模へ増強するため前記処理サーバ群の処理サーバを準備するサーバ準備部と
   を含む、情報処理システム。
2. 前記目標規模演算部は、前記処理サーバ群の処理サーバで観測されたローカルな負荷を表す評価指標に依存させて前記処理サーバ群の目標規模を演算する、請求項１に記載の情報処理システム。
3. 前記情報処理システムは、さらに、前記処理サーバ群の後段に設けられる第２サーバ群を含み、
   前記目標規模演算部は、前記処理サーバ群の処理サーバで観測された評価指標からボトルネックを判定し、前記処理サーバ群の後段にボトルネックがあると判定された場合に、前記処理サーバ群への転送量と前記代替サーバへの転送量とに応じて前記第２サーバ群の目標規模を演算し、
   前記サーバ準備部は、前記第２サーバ群の現在の規模から目標規模へ増強するため前記第２サーバ群の処理サーバを準備する請求項２に記載の情報処理システム。
4. 前記ロードバランサは、前記処理サーバ群の応答性能を監視し、前記応答性能が転送条件を満たした場合に前記処理サーバ群が過負荷状態であると判定する、請求項１に記載の情報処理システム。
5. 前記転送量は、コネクション数、クライアント数またはセッション数で定量されることを特徴とする、請求項１に記載の情報処理システム。
6. 前記代替サーバは、Ｓｏｒｒｙサーバであることを特徴とする、請求項１に記載の情報処理システム。
7. 前記目標規模演算部は、前記処理サーバ群への転送量と前記代替サーバへの転送量との比に依存させて前記処理サーバ群の目標規模を演算する、請求項１に記載の情報処理システム。
8. 前記処理サーバは、それぞれ仮想マシン上で稼働し、前記ローカルな負荷を表す評価指標は、前記処理サーバが稼働する仮想マシンのリソース使用率であり、前記サーバ準備部は、物理マシン上のハイパーバイザに対し、前記処理サーバ群の処理サーバを稼働させる仮想マシンのインスタンスの起動を指令することにより前記処理サーバを準備し、前記処理サーバ群の目標規模は、前記処理サーバ群の処理サーバを稼働させる仮想マシンのインスタンス数で定量されることを特徴とする、請求項２に記載の情報処理システム。
9. 前記処理サーバ群は、処理サーバとしてウェブサーバを含み、前記第２サーバ群は、処理サーバとしてアプリケーション・サーバまたはメモリキャッシュ・サーバを含む、請求項３に記載の情報処理システム。
10. 処理サーバ群を構成する複数の処理サーバの各々にトラフィックを分散するとともに前記処理サーバ群が過負荷状態となった際に代替サーバにトラフィックを転送するロードバランサから、前記処理サーバ群へ転送される転送量と前記代替サーバへ転送される転送量とを取得する転送量取得部と、
    前記処理サーバ群への転送量と前記代替サーバへの転送量とに応じて前記処理サーバ群の目標規模を演算する目標規模演算部と、
    前記処理サーバ群の現在の規模から目標規模へ増強するため前記処理サーバ群の処理サーバを準備するサーバ準備部と
    を含む、情報処理装置。
11. 前記目標規模演算部は、前記処理サーバ群の処理サーバで観測されたローカルな負荷を表す評価指標に依存させて前記処理サーバ群の目標規模を演算する、請求項１０に記載の情報処理装置。
12. 前記目標規模演算部は、前記処理サーバ群の処理サーバで観測された評価指標からボトルネックを判定し、前記処理サーバ群の後段にボトルネックがあると判定された場合に、前記処理サーバ群への転送量と前記代替サーバへの転送量とに応じて、前記処理サーバ群の後段に設けられる第２サーバ群の目標規模を演算し、
    前記サーバ準備部は、前記第２サーバ群の現在の規模から目標規模へ増強するため前記第２サーバ群の処理サーバを準備する、請求項１１に記載の情報処理装置。
13. 処理サーバ群を構成する複数の処理サーバの各々にトラフィックを分散するとともに前記処理サーバ群の負荷状態を監視し、前記処理サーバ群が過負荷状態となった際に代替サーバにトラフィックを転送するロードバランサに接続される、情報処理装置が実行するスケーリング方法であって、
    情報処理装置が、前記処理サーバ群の規模を増強するための増強方向のトリガ条件が成立したことを検知するステップと、
    情報処理装置が、前記ロードバランサから、前記処理サーバ群へ転送される転送量と前記代替サーバへ転送される転送量とを取得するステップと、
    情報処理装置が、前記処理サーバ群への転送量と前記代替サーバへの転送量とに応じて前記処理サーバ群の目標規模を演算するステップと、
    情報処理装置が、前記処理サーバ群の現在の規模から目標規模へ増強するため前記処理サーバ群の処理サーバを準備するステップと
    を含む、スケーリング方法。
14. 前記目標規模を演算するステップは、情報処理装置が、前記処理サーバ群の処理サーバで観測されたローカルな負荷を表す評価指標に依存させて前記処理サーバ群の目標規模を演算するステップであることを特徴とする、請求項１３に記載のスケーリング方法。
15. 前記スケーリング方法は、
    情報処理装置が、前記処理サーバ群の処理サーバで観測された評価指標からボトルネックを判定するステップと、
    情報処理装置が、前記処理サーバ群の後段にボトルネックがあると判定された場合に、前記処理サーバ群への転送量と前記代替サーバへの転送量とに応じて、前記処理サーバ群の後段に設けられる第２サーバ群の目標規模を演算するステップと、
    情報処理装置が、前記第２サーバ群の現在の規模から目標規模へ増強するため前記第２サーバ群の処理サーバを準備するステップと
    をさらに含む、請求項１４に記載のスケーリング方法。
16. コンピュータ実行可能なプログラムであって、前記プログラムは、コンピュータを、
    処理サーバ群を構成する複数の処理サーバの各々にトラフィックを分散するとともに前記処理サーバ群が過負荷状態となった際に代替サーバにトラフィックを転送するロードバランサから、前記処理サーバ群へ転送される転送量と前記代替サーバへ転送される転送量とを取得する転送量取得部、
    前記処理サーバ群への転送量と前記代替サーバへの転送量とに応じて前記処理サーバ群の目標規模を演算する目標規模演算部、および
    前記処理サーバ群の現在の規模から目標規模へ増強するため前記処理サーバ群の処理サーバを準備するサーバ準備部
    として機能させるためのプログラム。
17. 請求項１６に記載のコンピュータ実行可能なプログラムをコンピュータ可読に記録する記録媒体。