(57)【要約】【課題】未知のイベントにも対応できるオートスケーリングを実現する。【解決手段】オーケストレーションサーバは、仮想マシンにより処理を行う仮想ネットワークのスケーリングを行うオーケストレーションサーバであって、イベントの開催予定に関する情報を含むイベント予定データに基づいて、前記イベントに起因して発生する処理負荷の発生時間および負荷量に関する情報を含むイベント負荷データを作成するデータ分析部と、前記イベント負荷データに基づいて、前記イベントに起因して発生する処理負荷に応じてスケールアウトおよびスケールインを実施するためのスケーリング実施スケジュールを作成するスケジュール部と、前記スケーリング実施スケジュールに従って前記スケールアウトおよび前記スケールインを実施する仮想マシン生成部と、を有する。【選択図】  図２
2017173894.tif 000002
【特許請求の範囲】
【請求項１】
仮想マシンにより処理を行う仮想ネットワークのスケーリングを行うオーケストレーションサーバであって、
イベントの開催予定に関する情報を含むイベント予定データに基づいて、前記イベントに起因して発生する処理負荷の発生時間および負荷量に関する情報を含むイベント負荷データを作成するデータ分析部と、
前記イベント負荷データに基づいて、前記イベントに起因して発生する処理負荷に応じてスケールアウトおよびスケールインを実施するためのスケーリング実施スケジュールを作成するスケジュール部と、
前記スケーリング実施スケジュールに従って前記スケールアウトおよび前記スケールインを実施する仮想マシン生成部と、
を有するオーケストレーションサーバ。
【請求項２】
前記イベント予定データは、前記イベントの開催場所と開始日時と集まる人の数に関連する人的規模関連情報とをイベントデータ要素として含み、
前記データ分析部は、過去に実施されたイベントに関する情報に基づいて、前記イベントのイベントデータ要素と、前記イベントに起因して発生した処理負荷の負荷量との対応関係を予め算出してイベント開催データとして保持しておき、前記イベント予定データからイベントデータ要素を抽出し、抽出した該イベントデータ要素に相当するイベントデータ要素を含むイベント開催データに基づいて前記イベント負荷データを作成する、
請求項１に記載のオーケストレーションサーバ。
【請求項３】
前記イベント予定データは、更に、前記イベントのジャンル、属性、および終了時刻をイベントデータ要素として含む、
請求項２に記載のオーケストレーションサーバ。
【請求項４】
前記データ分析部は、前記イベント予定データに対応するイベント開催データが存在すれば該イベント開催データに基づいて前記イベント負荷データを作成し、前記イベント予定データに対応するイベント開催データが存在しなければ、過去に実施されたイベントに関する情報に基づく学習で、前記イベント予定データに対応するイベント開催データを作成する、請求項３に記載のオーケストレーションサーバ。
【請求項５】
前記スケジュール部は、前記イベントに起因する前記処理負荷の発生に合わせてスケールアウトを実施し、前記処理負荷の終了に合わせてスケールインを実施するように前記スケーリング実施スケジュールを作成する、
請求項１に記載のオーケストレーションサーバ。
【請求項６】
前記スケジュール部は、前記イベントの開始日時の所定時間前にスケールアウトを実施し、前記処理負荷の終了時刻の所定時間後にスケールインを実施するように前記スケーリング実施スケジュールを作成する、
請求項１に記載のオーケストレーションサーバ。
【請求項７】
前記仮想マシン生成部は、オペレータの操作に応じて、前記スケールアウトおよび前記スケールインを実施するか否かを選択する、請求項１に記載のオーケストレーションサーバ。
【請求項８】
前記データ分析部は、イベントに起因する処理負荷が発生している間の複数の範囲のそれぞれを対象とする仮想ノードの使用率の最大値を取得し、それ以降に、前記イベントに用いたものと同じイベント開催データを用いてスケーリングを実施するとき、該最大値が大きかった範囲を優先して仮想ノードを作成するように、前記スケーリングを実施する範囲を決定する、請求項１に記載のオーケストレーションサーバ。
【請求項９】
前記データ分析部は、
イベントを分類するジャンルの一覧を示すジャンルテーブルと、前記ジャンルテーブルに記載された各ジャンルについて該ジャンルに属する属性と該属性の開催場所の収容人数に対する動員人数の割合である動員率とを示すジャンル属性テーブルと、イベントが実施される開催場所のそれぞれの収容人数を示す場所管理テーブルと、開催予定のイベントについて、ジャンルと属性と開催場所と開始日時と終了日時と処理負荷とを示すイベントテーブルとを管理し、
開催予定のイベントのジャンル、属性、開催場所、開始日時、および終了日時が指定されると、前記ジャンルおよび前記属性により前記ジャンル属性テーブルを参照して前記動員率を取得し、前記開催場所により前記場所管理テーブルを参照して前記収容人数を取得し、前記収容人数と前記動員率を乗算して動員数を算出し、前記動員数を前記処理負荷とする、
請求項１に記載のオーケストレーションサーバ。
【請求項１０】
仮想マシンにより処理を行う仮想ネットワークのスケーリングを行うためのオーケストレーション方法であって、
データ分析手段が、イベントの開催予定に関する情報を含むイベント予定データに基づいて、前記イベントに起因して発生する処理負荷の発生時間および負荷量に関する情報を含むイベント負荷データを作成し、
スケジュール手段が、前記イベント負荷データに基づいて、前記イベントに起因して発生する処理負荷に応じてスケールアウトおよびスケールインを実施するためのスケーリング実施スケジュールを作成し、
仮想マシン生成手段が、前記スケーリング実施スケジュールに従って前記スケールアウトおよび前記スケールインを実施する、
オーケストレーション方法。
【請求項１１】
コンピュータに、仮想マシンにより処理を行う仮想ネットワークのスケーリングを行わせるためのオーケストレーションプログラムであって、
イベントの開催予定に関する情報を含むイベント予定データに基づいて、前記イベントに起因して発生する処理負荷の発生時間および負荷量に関する情報を含むイベント負荷データを作成する手順と、
スケジュール手段が、前記イベント負荷データに基づいて、前記イベントに起因して発生する処理負荷に応じてスケールアウトおよびスケールインを実施するためのスケーリング実施スケジュールを作成する手順と、
仮想マシン生成手段が、前記スケーリング実施スケジュールに従って前記スケールアウトおよび前記スケールインを実施する手順と、
をコンピュータに実行させるためのオーケストレーションプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、仮想化されたネットワークにおける仮想ノードのスケーリングを行う技術に関する。
【背景技術】
【０００２】
仮想ネットワークにおけるオートスケーリングは、仮想ネットワークで稼働する仮想ノードの台数を増やしたり、減らしたりする機能である。仮想ノードの台数を増やすことをスケールアウトといい、仮想ノードの台数を減らすことをスケールインという。仮想ネットワークサービスの提供者は、顧客の需要に基づき、遠隔からオートスケーリングを実施することが可能である。
【０００３】
仮想ネットワークの負荷が増えたとき、スケールアウトすると、各仮想ノードの負荷を減らし、処理性能を向上させることができる。また、仮想ノードの負荷が減ったとき、スケールインすると、管理装置により管理する仮想ノードの個数を減らし、リソースの使用効率を向上することができる。
【０００４】
特許文献１は、時間帯別、地域別、曜日別に、仮想ノードの通信による物理サーバのリソースの使用率に閾値を設定し、使用率が閾値以上となったときあるいは使用率が閾値を超えたとき、その時点で使用率を示す情報を取得する。そして、その取得した使用率に基づいて、物理サーバのどの程度のリソースを仮想呼処理サーバ用として割り当てるかを決定し、その決定に従って、物理サーバ上に仮想呼処理サーバを生成する。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特許第５５３７６００号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
特許文献１の技術では、日常の通信によるリソースの使用率を学習し、学習結果に基づいて閾値を設定し、仮想ノードを拡張するために割り付けるリソース量を決定する。よって、過去に発生したことの無いイベントにより通信量が急激に上昇したような場合、過去の通信によるリソースの使用率のデータに基づく、仮想ノードの拡張のために割り当てるリソース量が不適当となる可能性がある。また、使用率の急激な変化に仮想ノードの追加生成が間に合わず、仮想ノードにおける輻輳が続いてしまう可能性がある。そのため、通信量が急激に上昇したときに迅速に通信の収容能力を高めることができるように、常時、余剰のリソースを確保しておかなければならず、コストが膨大となる。
【０００７】
本発明の目的は、未知のイベントにも対応できるオートスケーリングを実現する技術を提供することである。
【課題を解決するための手段】
【０００８】
本発明の一態様によるオーケストレーションサーバは、仮想マシンにより処理を行う仮想ネットワークのスケーリングを行うオーケストレーションサーバであって、イベントの開催予定に関する情報を含むイベント予定データに基づいて、前記イベントに起因して発生する処理負荷の発生時間および負荷量に関する情報を含むイベント負荷データを作成するデータ分析部と、前記イベント負荷データに基づいて、前記イベントに起因して発生する処理負荷に応じてスケールアウトおよびスケールインを実施するためのスケーリング実施スケジュールを作成するスケジュール部と、前記スケーリング実施スケジュールに従って前記スケールアウトおよび前記スケールインを実施する仮想マシン生成部と、を有する。
【発明の効果】
【０００９】
本発明よれば、イベントの開催予定に基づいたスケジュールに従ってスケーリングを実施するので、過去に経験のないイベントに適切に対応可能なオートスケーリングが実現できる。
【図面の簡単な説明】
【００１０】
【図１】本実施形態の仮想ネットワークのブロック図である。
【図２】オーケストレーションサーバ１０３の機能ブロック図である。
【図３】クラウド管理サーバ１０４の機能ブロック図である。
【図４】Ｃｏｍｐｕｔｅサーバ１０６の機能ブロック図である。
【図５】ジャンルテーブル２０６の一例を示す図である。
【図６】ジャンル属性テーブル２０７の一例を示す図である。
【図７】場所管理テーブル２０８の一例を示す図である。
【図８】イベントテーブル２０９の一例を示す図である。
【図９】データ分析部２０３がイベントテーブル２０９のレコードを作成する処理を示すフローチャートである。
【図１０】クライアント１０１におけるイベント予定データ入力画面の一例を示す図である。
【図１１】ステップ９０５の詳細処理を示すフローチャートである。
【図１２Ａ】作成例の説明に用いるジャンルテーブル２０６である。
【図１２Ｂ】作成例の説明に用いるジャンル属性テーブル２０７である。
【図１２Ｃ】作成例の説明に用いる場所管理テーブル２０８である。
【図１３】作成例の説明に用いるイベントテーブル２０９である。
【図１４】スケジュール部２０４のシナリオテーブル２１０の一例を示す図である。
【図１５】スケジュール部２０４のスケジュールテーブル２１１の一例を示す図である。
【図１６】スケジュール部２０４がスケジュールテーブル２１１にスケーリングのスケジュールを登録する処理のフローチャートである。
【図１７Ａ】イベントテーブル２０９の一例を示す図である。
【図１７Ｂ】シナリオテーブル２１０の一例を示す図である。
【図１７Ｃ】スケジュールテーブル２１１の一例を示す図である。
【図１８】ＶＭ生成部２０５がＶＭの使用状態を管理するためのＶＭ管理テーブル２１２の一例を示す図である。
【図１９】ＶＭ生成部２０５がＶＭのスケールアウトを実施する処理を示すフローチャートである。
【図２０】ＶＭ生成部２０５がＶＭのスケールインを実施する処理を示すフローチャートである。
【図２１Ａ】ＶＭ管理テーブル２１２に管理されているＶＭのスケールアップによる変化の一例について説明するための図である。
【図２１Ｂ】ＶＭ管理テーブル２１２に管理されているＶＭのスケールアップによる変化の一例について説明するための図である。
【図２２Ａ】オートスケーリングにおいて、オペレータが操作するクライアント１０１の画面表示を示す図である。
【図２２Ｂ】オートスケーリングにおいて、オペレータが操作するクライアント１０１の画面表示を示す図である。
【図２３Ａ】ＶＭ管理テーブル２１２に管理されているＶＭのスケールインによる変化の一例について説明するための図である。
【図２３Ｂ】ＶＭ管理テーブル２１２に管理されているＶＭのスケールインによる変化の一例について説明するための図である。
【図２４Ａ】オートスケーリングにおいて、オペレータが操作するクライアント１０１の画面表示を示す図である。
【図２４Ｂ】オートスケーリングにおいて、オペレータが操作するクライアント１０１の画面表示を示す図である。
【発明を実施するための形態】
【００１１】
本発明の実施形態について図面を参照して詳細に説明する。
【００１２】
図１は、本実施形態の仮想ネットワークのブロック図である。仮想ネットワークは、ＭＧＭＴＳＷ（マネジメントスイッチ）１０２、オーケストレーションサーバ１０３、クラウド管理サーバ１０４、サービスＳＷ（スイッチ）１０５、およびＣｏｍｐｕｔｅサーバ１０６を有している。
【００１３】
複数のＣｏｍｐｕｔｅサーバ１０６、１０７、１０８がサービスＳＷ１０５に接続されている。本実施形態のＣｏｍｐｕｔｅサーバ１０６、１０７、１０８は、通信処理を実行する仮想ノードが作成される計算機である。サービスＳＷ１０５は、通信サービスネットワークを実現するスイッチ群である。ＭＧＭＴＳＷ１０２は、管理ネットワークを実現するスイッチ群である。
【００１４】
オーケストレーションサーバ１０３は、クラウド管理サーバ１０４と連携し、クラウド上の仮想ネットワークのリソースの運用を管理する。図１に示したように、オーケストレーションサーバ１０３はクラウド管理サーバ１０４と接続し、サービスＳＷ１０５を介して、Ｃｏｍｐｕｔｅサーバ１０６、１０７、１０８上の仮想ノードを管理する。オーケストレーションサーバ１０３は、ＭＧＭＴＳＷ１０２を介して提供されたクライアント１０１に対するオペレータの操作により各種処理を実行する。
【００１５】
図２はオーケストレーションサーバ１０３の機能ブロック図である。オーケストレーションサーバ１０３はＣＰＵ２０１およびメモリ２０２を有している。ＣＰＵ２０１がメモリ２０２上のプログラムを実行することにより、データ分析部２０３、スケジュール部２０４、およびＶＭ（仮想マシン）生成部２０５が実現される。
【００１６】
データ分析部２０３は、クライアント１０１により入力されたデータを、ＭＧＭＴＳＷ１０２を介して受信し、処理する。スケジュール部２０４およびＶＭ生成部２０５はデータ分析部２０３から受け取った情報を基にして、クラウド管理サーバ１０４を介して、Ｃｏｍｐｕｔｅサーバ１０６、１０７、１０８上でのＶＭの起動および停止を制御する。
【００１７】
データ分析部２０３は、ジャンルテーブル２０６、ジャンル属性テーブル２０７、場所管理テーブル２０８、およびイベントテーブル２０９を備える。
【００１８】
ジャンルテーブル２０６、ジャンル属性テーブル２０７、場所管理テーブル２０８はイベントのジャンル、属性、開催場所といった、イベントが持つ客観的な性質に関する情報を保持する。イベントテーブル２０９は、予定されているイベントに起因して発生する処理負荷（トラフィック）の発生時間および負荷量に関する情報を含むイベント負荷データである。イベントテーブル２０９は、イベントに関連して仮想ネットワークのスケーリングを行うために用いられる。
【００１９】
スケジュール部２０４は、シナリオテーブル２１０およびスケジュールテーブル２１１を備え、オーケストレーションサーバ１０３としてスケジュール通り計画的にシナリオを適用する。スケジュール部２０４の詳細は後述する。
【００２０】
ＶＭ生成部２０５は、ＶＭ管理テーブル２１２を備える。ＶＭ生成部２０５は、シナリオに従って、ＶＭのスケールイン、スケールアウトなどの処理を実行する。ＶＭ生成部２０５の詳細は後述する。
【００２１】
図３はクラウド管理サーバ１０４の機能ブロック図である。クラウド管理サーバ１０４はＣＰＵ３０１およびメモリ３０２を有している。メモリ３０２上には、Ｃｏｍｐｕｔｅ管理プログラム３０３、Ｎｅｔｗｏｒｋ管理プログラム３０４、Ｃｏｍｐｕｔｅ管理テーブル３０５、Ｎｅｔｗｏｒｋ管理テーブル３０６が記録されている。クラウド管理サーバ１０４はＣｏｍｐｕｔｅ管理プログラム３０３およびＮｅｔｗｏｒｋ管理プログラム３０４の実行を介して、ＶＭ等の仮想ネットワークのリソースを制御する。
【００２２】
図４はＣｏｍｐｕｔｅサーバ１０６の機能ブロック図である。Ｃｏｍｐｕｔｅサーバ１０６はＣＰＵ４０１、メモリ４０２、およびディスク装置４０７を有している。メモリ４０２上には、クラウド管理エージェント４０３、Ｈｙｐｅｒｖｉｓｏｒ４０４、およびＶＭ管理テーブル４０５が記録されている。ディスク装置４０７上にはＶＭイメージ４０６が格納されている。Ｃｏｍｐｕｔｅサーバ１０６は、ＣＰＵ４０１によるクラウド管理エージェント４０３の実行を介して、Ｈｙｐｅｒｖｉｓｏｒ４０４上にＶＭを立ち上げる。
ＶＭイメージはＶＭを画面上にＶＭを表示するときの表示イメージを示すデータである。
【００２３】
図５、図６、図７、および図８を用いて、データ分析部２０３が管理するイベントの開催情報（イベント予定データ）およびそのトラフィックについて説明する。
【００２４】
図５は、ジャンルテーブル２０６の一例を示す図である。図５には、イベントのジャンル識別情報（ジャンルＩＤ）とジャンル名の対応が示されている。各ジャンルにはジャンルＩＤとジャンル名が付与されており、それがジャンルテーブル２０６に格納される。ジャンル名５０２、ジャンルＩＤ５０１は、イベントの主題およびスタイルなどの構成要素により事前に分類される。
【００２５】
本実施形態では、レコード５０３はジャンルＩＤ＝１でジャンル名がコンサートである。また、レコード５０４は、ジャンルＩＤ＝２でジャンル名がスポーツである。また、レコード５０５は、ジャンルＩＤ＝３でジャンル名が花火大会である。なお、このジャンルの定義は一例であり、他の分類を用いてもよい。例えば、仮想ネットワークのサービス提供対象により、イベント・チケット情報会社と連携し、そのイベント・チケット情報会社が用いている分類方法を用いてもよい。
【００２６】
図６は、ジャンル属性テーブル２０７の一例を示す図である。図６には、ジャンルＩＤ６０１、属性ＩＤ６０２、属性名６０３、および観客動員率６０４の対応が示されている。大分類である各ジャンルには、１つ以上の中分類である属性が含まれている。各属性には、属性ＩＤ６０２および属性名が付与されている。また、各属性には、観客動員率６０４が設定されている。観客動員率６０４とは、その属性のイベントにより動員可能な人数の、開催場所の収容人数に対する割合である。例えば、過去の履歴から予測した観客動員数が設定される。予測は、例えば過去のデータの平均値を算出することである。収容人数および観客動員率は、イベントの人的規模に関連する情報（人的規模関連情報）である。
【００２７】
例として、人気歌手のコンサートが観客動員率９２％であったという情報が与えられた場合のジャンル属性テーブル２０７への登録について例示する。
【００２８】
図５を参照すると、ジャンル名がコンサートのジャンルＩＤ＝１が得られる。図６には、ジャンル属性テーブル２０７には、ジャンルＩＤ６０１の列に当該ジャンルＩＤ＝１が、属性名６０３の列にジャンルＩＤに所属する属性名として人気歌手が、属性名に対応する属性ＩＤ＝１が、属性名のイベントに対する観客動員率を９２％としたレコード６０５が格納される。
【００２９】
また、ジャンル名がコンサート、属性名が人気歌手、という情報が与えられ、観客動員率を求める場合を例示する。
【００３０】
ジャンル名がコンサートという情報が与えられているので、図５を参照することによりジャンルＩＤ＝１が得られる。このジャンルＩＤ＝１を持って図６を参照すると、属性名が人気歌手の属性ＩＤ＝１と観客動員率＝９２％が得られる。
【００３１】
属性の区分は、ジャンルと同様に、オペレータが事前に設定してもよく、またはイベント・チケット情報会社と連携し、イベント・チケット情報会社で用いられている属性の区分を用いることにしてもよい。
【００３２】
過去に開催された実績があるイベントに対して、各属性に対応する観客動員率はインターネット、リサーチ会社などを介して入手することが可能である。開催された実績がないイベントに対しては、開催されたイベントのデータに対する学習処理により、観客動員率を計算することが可能である。
【００３３】
図７は、場所管理テーブル２０８の一例を示す図である。図７に示す場所管理テーブル２０８に、イベントが開催される場所名７０２、場所識別情報（場所ＩＤ）が格納される場所ＩＤ７０１、および当該場所の収容人数７０３が格納される。場所名および収容人数など場所に関するデータはインターネットまたは各地域が管理する地域情報から入手することが可能である。
【００３４】
図８は、イベントテーブル２０９の一例を示す図である。図８に示すイベントテーブル２０９には、イベントの開催予定および開催時に予想される負荷（トラフィック）に関する情報が記録される。１つのイベントが１つのレコードに紐付けられる。
【００３５】
イベント識別情報が格納されるイベントＩＤ８０１、図５に示されたジャンルテーブル２０６に格納されているジャンルＩＤ８０２、図６に示されたジャンル属性テーブル２０７に格納される属性ＩＤ８０３、図７に示された場所管理テーブル２０８に格納される場所ＩＤ８０４、イベントの開始日時８０５、終了日時８０６、イベントが開催される会場へ来場する観客の来場に要する時間および退場に要する時間に基づいて設定されたスケジューリング時間８０７、図６に示されたジャンル属性テーブル２０７の観客動員率６０４および図７に示された場所管理テーブル２０８の収容人数から計算されたトラフィック８０８が格納される。
【００３６】
本実施形態では、スケーリングをイベントの開始の何時間前から開始し、終了の何時間後まで行うかを示すスケジューリング時間を、予め定めた前後２時間としている。これはイベントの開始の２時間前から観客が集まり、終了の２時間後には観客の退場が終了するという想定による。
【００３７】
図９は、データ分析部２０３がイベントテーブル２０９のレコードを作成する処理を示すフローチャートである。データ分析部２０３は、図５に示したジャンルテーブル２０６、図６に示したジャンル属性テーブル２０７、および図７に示した場所管理テーブル２０８に格納されたイベント予定情報（イベント予定データ）から、図８に示したイベントテーブル２０９のレコードを作成する。
【００３８】
データ分析部２０３は、イベントデータ分析を開始すると（ステップ９０１）、イベント予定データからイベントデータ要素を抽出する（ステップ９０２）。
【００３９】
図１０は、クライアント１０１におけるイベント予定データ入力画面の一例を示す図である。オペレータがクライアント１０１を介してイベント予定データにおけるイベントの項目１００２、場所の項目１００３、開始日時の項目１００４、および終了日時の項目１００５を入力し、スケジュール登録ボタン１００６を押下すると、それを契機として、データ分析部２０３は自動的にイベントのジャンル名、属性名、場所名、および開始時刻、終了時刻を抽出する。
【００４０】
さらに、データ分析部２０３は、入力したイベント１００２から抽出されたジャンル名５０２を、ジャンルテーブル２０６を検索する検索キーとし、当該レコードに格納されたジャンルＩＤを取得する。
【００４１】
同様に、データ分析部２０３は、ステップ９０２で抽出されたジャンルＩＤ６０１および属性名６０３を、ジャンル属性テーブル２０７を検索する検索キーとし、そのジャンルＩＤおよび属性名を有するレコードが存在するか否かを確認する（ステップ９０３）。
【００４２】
また、データ分析部２０３は、ステップ９０２で抽出された場所名１００３を、場所管理テーブル２０８を検索する検索キーとし、場所名が存在するか否かを確認する（ステップ９０３）。
【００４３】
ステップ９０２で抽出されたジャンルＩＤ６０１および属性名６０３を有するレコードが存在し、ステップ９０２で抽出された場所名１００３が存在する場合、開催予定のイベントは過去にも実施されたイベントである。一方、ステップ９０２で抽出されたジャンルＩＤ６０１および属性名６０３を有するレコードが存在しないか、ステップ９０２で抽出された場所名１００３が存在しない場合、開催予定のイベントは過去に実施されていないイベントである。
【００４４】
ステップ９０２で抽出されたジャンルＩＤ６０１および属性名６０３を有するレコードが存在し、ステップ９０２で抽出された場所名１００３が存在する場合、データ分析部２０３は、ジャンル属性テーブル２０７から属性ＩＤ６０２および観客動員率６０４を、場所管理テーブル２０８から場所ＩＤ７０１および収容人数７０３を取得する。続けてフロー９０４以降の処理を実施する。
【００４５】
一方、ステップ９０２で抽出されたジャンルＩＤ６０１および属性名６０３を有するレコードが存在しないか、ステップ９０２で抽出された場所名１００３が存在しない場合、データ分析部２０３は、イベントデータ学習処理を実施し（ステップ９０５）、ステップ９０４へ進む。
【００４６】
ステップ９０４では、データ分析部２０３は、ステップ９０３にて取得したジャンルＩＤ５０１、属性ＩＤ６０２、および場所ＩＤ７０１を用いて、イベントテーブル２０９に当該イベントレコードがあるかどうか確認する。
【００４７】
当該イベントレコードがある場合、データ分析部２０３は当該レコード８０９からスケジューリング時間８０７およびトラフィック８０８を抽出する。そして、データ分析部２０３は、イベントテーブル２０９に、イベントＩＤ８０１を新たに採番し、ステップ９０３にて取得したジャンルＩＤ８０２、属性ＩＤ８０３、場所ＩＤ８０４、前の処理で取得したスケジューリング時間８０７、トラフィック８０８、およびステップ９０２にて抽出した開始日時８０５および終了日時８０６を格納し、イベントレコードを登録する。
【００４８】
一方、イベントレコードがない場合、データ分析部２０３は、イベントＩＤ８０１を採番し、ステップ９０３にて取得したジャンルＩＤ８０２、属性ＩＤ８０３、場所ＩＤ８０４、ステップ９０２にて抽出した開始日時８０５、および終了日時８０６をイベントテーブル２０９に格納する。
【００４９】
また、データ分析部２０３は、スケジューリング時間として、観客の入場する時間および退場する時間を考慮し、固定値の±２時間を設定する。
【００５０】
また、データ分析部２０３は、トラフィックについては、ステップ９０３にて取得した収容人数に観客動員率を乗算することで得た予測接続端末数を、イベントテーブル２０９に格納し、データ分析の処理を終了する（ステップ９０６）。
【００５１】
図１１は、ステップ９０５の詳細処理を示すフローチャートである。
【００５２】
ステップ９０５は、開催予定のイベントが過去に実施されていないイベントである場合に実行されるので、データ分析部２０３は、イベントデータ学習を開始すると、ジャンル属性テーブル２０７に、入力されたイベント予定データに該当するレコードが存在しないのか、場所管理テーブル２０８に、入力されたイベント予定データに該当するレコードが存在しないのかを判定する（ステップ１１０２）。
【００５３】
場所管理テーブル２０８に、入力されたイベント予定データに該当するレコードが存在しない場合、データ分析部２０３は、開催予定のイベントが開催される会場の場所情報を場所管理テーブル２０８に登録し（ステップ１１０６）、処理を終了する。
【００５４】
一方、ジャンル属性テーブル２０７に、入力されたイベント予定データに該当するレコードが存在しない場合、データ分析部２０３は、過去に実施されたイベントに関する情報に対して特徴抽出を行い（ステップ１１０３）、ベクトルに変換する。更に、データ分析部２０３は、特徴抽出により得られたベクトルを入力データとして機械学習を行う（ステップ１１０４）。この機械学習に用いる学習アルゴリズムは特に限定されない。ここでは一例として教師あり学習である分類問題が例示される。
【００５５】
データ分析部２０３は、分類問題の機械学習において、過去に実施されたイベントの属性を予測する（ステップ１１０５）。そして、イベント予定データと同じジャンルおよび属性のレコードを登録する。
【００５６】
以下、イベントテーブル２０９のレコードの作成例を示す。
【００５７】
図１２Ａは作成例の説明に用いるジャンルテーブル２０６である。図１２Ｂは作成例の説明に用いるジャンル属性テーブル２０７である。図１２Ｃは作成例の説明に用いる場所管理テーブル２０８である。図１３は作成例の説明に用いるイベントテーブル２０９である。
【００５８】
イベントテーブル２０９のレコード作成は、図９に示したフローチャートに従って行われる。
【００５９】
まず、図１０に示したイベント予定データ入力画面からイベント予定データが入力される。ここで入力されるデータは、イベントの項目１００２が「コンサート―人気歌手」であり、場所の項目１００３が「神奈川県―横浜―ＡＢＣアリーナ」であり、開始日時の項目が「２０１５/１２/２５  １８：３０：００」であり、終了日時の項目が「２０１５/１２/２５  ２１：００：００」である。
【００６０】
イベントのジャンル名＝コンサートは、図１２Ａのジャンルテーブル２０６における項目１２０３のジャンルＩＤ＝１に対応する。図１２Ｂのジャンル属性テーブル２０７には、ジャンルＩＤ＝１、イベントの属性名＝人気歌手に紐付く属性ＩＤ＝１、属性観客動員率＝９２％というレコード１２０８が登録されている。イベントの場所名＝ＡＢＣアリーナから、図１２Ｃの場所管理テーブル２０８を参照して、場所ＩＤ＝１および収容人数＝１７０００というレコード１２１２を取得する。
【００６１】
当該イベントのイベント予定データのレコードを登録するときイベントテーブル２０９が空であれば、図１３のレコード１３０９のように、イベントＩＤ＝１を自動的に採番し、そのレコードに割り当てる。以上の手順により、ジャンルＩＤ＝１、属性ＩＤ＝１、場所ＩＤ＝１、開始時間＝２０１５/１２/２５  １８：３０：００、終了時間＝２０１５/１２/２５  ２１：００：００、およびスケーリング時間＝±２をトラフィック＝１７０００×９２％＝１５６４０のイベントのレコード１３０９が登録される。
【００６２】
図１４は、スケジュール部２０４のシナリオテーブル２１０の一例を示す図である。シナリオテーブル２１０にはスケジュール部２０４にて管理される実行対象のシナリオである。
【００６３】
図１４を参照すると、シナリオテーブル２１０には、シナリオ名１４０２と、シナリオの識別情報が格納されるシナリオＩＤ１４０１とが含まれる。本実施形態では、ＶＭのスケールイン１４０３とスケールアウト１４０４のみを実施するシナリオが例示されるが、オーケストレーションサーバ１０３が実施可能な他のシナリオをシナリオテーブル２１０に格納してもよい。
【００６４】
図１５は、スケジュール部２０４のスケジュールテーブル２１１の一例を示す図である。スケジュールテーブル２１１は、ＶＭのオートスケーリングの実施日時、実施範囲、および実施承認有無を管理するテーブルである。スケジュールテーブル２１１のレコード１５０６、１５０７は、スケジュール部２０４により設定される。スケジュールテーブル２１１の１つのレコード１５０６、１５０７がそれぞれ１つのシナリオに対応する。
【００６５】
実施日時１５０２に示された日時において実施承認状態１５０５が「ＯＫ」であれば、シナリオＩＤ１５０３に示されたシナリオが実施される。また、実施日時１５０２に示された日時において実施承認状態１５０５が「ＮＧ」であれば、シナリオＩＤ１５０３に示されたシナリオの実施を行われない。
【００６６】
スケジュールテーブル２１１には、スケジュール毎に、その実施するスケジュールを識別するための情報であるスケジュールＩＤ１５０１、スケーリングの実施日時１５０２、実行対象となるシナリオを識別するための情報であるシナリオＩＤ１５０３、スケーリングの実施範囲となるトラフィック１５０４、および当該スケジュールに対するオペレータの承認の有無が格納される実施承認状態１５０５が設定される。
【００６７】
図１６は、スケジュール部２０４がスケジュールテーブル２１１にスケーリングのスケジュールを登録する処理のフローチャートである。スケジュール部２０４は、図８に示すイベントテーブル２０９に格納されたイベントデータから、図１５に示すスケジュールテーブル２１１にＶＭのスケーリングを実施するスケジュールを作成する。
【００６８】
スケジュール登録の処理が開始されると（ステップ１６０１）、スケジュール部２０４は、まずスケーリングを実施する時刻と範囲を取得する（ステップ１６０２）。
【００６９】
その際、スケジュール部２０４は、図８に示したイベントテーブル２０９から、イベントの開催日時８０５、終了日時８０６、スケジューリング時間８０７およびトラフィック８０８を取得する。
【００７０】
イベントの開始に合わせてスケールアウトを行い、イベントの終了に合わせてスケールインを行うので、スケールアウトの実施日時がスケールインの実施日時よりも時間的に前となる。イベントの開催日時８０５からスケジューリング時間８０７だけ遡った時刻がスケールアウトの実施時刻となる。イベントの終了日時８０６にスケジューリング時間８０７を加えた時刻がスケールインの実施時刻となる。
【００７１】
スケジュール部２０４は、イベントの開催日時８０５からスケジューリング時間８０７を減算し、スケールアウトの実施時刻を算出する。スケジュール部２０４は、また、イベントの終了日時８０６にスケジューリング時間８０７を加算し、スケールインの実施時刻を算出する。また、スケジュール部２０４は、取得したトラフィックをスケーリングを実施する範囲（増減するＶＭの個数）とする。
【００７２】
次に、スケジュール部２０４はスケジュールを作成する（ステップ１６０３）。その際、スケジュール部２０４は、ＶＭのスケールアウトとＶＭスケールインの各スケジュールを作成する。
【００７３】
ＶＭのスケールアウトに関するスケジュールを作成するとき、スケジュール部２０４は、まずスケジュールＩＤを自動的に採番する。次に、スケジュール部２０４は、ステップ１６０２にて算出した時刻を実施時刻に設定する。更に、スケジュール部２０４は、シナリオテーブル２１０に設定されたスケールアウトのシナリオＩＤを、スケールアウトのシナリオＩＤとして設定する。
【００７４】
更に、スケジュール部２０４は、スケールアウトのスケジュールにおいて、ステップ１６０２で取得したトラフィックに、スケールアウトを示す記号「＋」を加える。スケジュール部２０４は、
実施承認状態については、スケジュール部２０４は、新たにスケジュールを登録するときのデフォルト初期値として「ＮＧ」を設定する。
【００７５】
ＶＭのスケールインに関するスケジュールを作成するとき、スケジュール部２０４は、まずスケールアウトのスケジュールを作成するときと同様にスケジュールＩＤを自動的に採番する。次に、スケジュール部２０４は、ステップ１６０２にて算出した時刻を実施時刻に設定する。更に、スケジュール部２０４は、シナリオテーブル２１０に設定されたスケールインのシナリオＩＤを、スケールインのシナリオＩＤとして設定する。
【００７６】
更に、スケジュール部２０４は、スケールインのスケジュールにおいて、ステップ１６０２で取得したトラフィックに、スケールインインを示す記号「−」を加える。実施承認状態についても、スケジュール部２０４は、スケールアウトのときと同様にデフォルト触知として「ＮＧ」を設定する。
【００７７】
次に、スケジュール部２０４は、作成したスケジュールのレコードをスケジュールテーブル２１１に格納する（ステップ１６０４）。
【００７８】
なお、スケジュール部２０４は、登録したスケジュールをＭＧＭＴＳＷ１０２経由でクライアント１０１に送信する。クライアントでは登録されたスケジュールが画面に表示される。当該実施日時になる前にオペレータがそのスケジュールの実施を承認すると、実施承認状態が「ＮＧ」から「ＯＫ」に変わる。その状態で実施日時になると、ＶＭ生成部２０５がシナリオを実行する。また、オペレータがそのスケジュールの実施を承認しなかったら、あるいはそのスケジュールを削除したら、その実施日時になってもＶＭ生成部２０５はシナリオを実行しない。
【００７９】
図１７Ａは、イベントテーブル２０９の一例を示す図である。図１７Ｂは、シナリオテーブル２１０の一例を示す図である。図１７Ｃは、スケジュールテーブル２１１の一例を示す図である。
【００８０】
以下、図１７Ａ〜１７Ｃを用いて、イベント予定データに基づいて、ＶＭのスケーリングを実施するためのスケジュールを作成する例について説明する。
【００８１】
ここで、図１７Ａのイベントテーブル２０９におけるイベントＩＤ＝１のレコード１７０９に対するスケジュールを作成する。図１７Ａを参照すると、イベントＩＤ＝１のイベントは、開始日時＝２０１５/１２/２５  １８：３０：００であり、終了日時＝２０１５/１２/２５  ２１：００：００であり、スケジューリング時間＝±２であり、トラフィック＝１５６４０である。このイベントの間はトラフィックが増大するので、まずＶＭのスケールアウトを実行し、次にＶＭのスケールインを実行するようなスケジュールが作成される。
【００８２】
ＶＭのスケールアウトのスケジュールは、スケジュールテーブル２１１に示すように、シナリオＩＤ＝２であり、実施日時＝２０１５/１２/２５  １６：３０：００であり、実施範囲はトラフィック＝＋１５６４０であり、実施承認状態は初期値＝ＮＧである。シナリオＩＤ＝２はシナリオテーブル２１０のレコード１７１３から取得される。実施日時は開始日時から２時間を減算した実施日時＝２０１５/１２/２５  １６：３０：００とされる。また、ここで仮に登録前のスケジュールテーブル２１１が空であったと想定すると、図１７Ｃに示すようにスケジュールＩＤ＝１となる。
【００８３】
同様に、ＶＭスケールインのスケジュールは、図１７Ｃのレコード１７２０に示すように、スケジュールＩＤ＝２であり、実施日時＝２０１５/１２/２５  ２３：００：００であり、シナリオＩＤ＝１であり、トラフィック＝−１５６４０であり、実施承認状態の初期値＝ＮＧである。
【００８４】
レコード１７１９のスケールアウトは、スケールアウトの実施日時である２０１５/１２/２５  １６：３０：００の時点で実施承認状態が「ＯＫ」となっていれば、＋１５６４０トラフィック量のＶＭスケールアウトが自動的に実施される。また、レコード１７２０のスケールインは、スケールインの実施日時である２０１５/１２/２５  ２３：００：００の時点で実施承認状態が「ＯＫ」となっていれば、−１５６４０のトラフィック量のＶＭスケールインが自動的に実施される。
【００８５】
図１８は、ＶＭ生成部２０５がＶＭの使用状態を管理するためのＶＭ管理テーブル２１２の一例を示す図である。ＶＭ管理テーブル２１２は、ＶＭ毎に、ＶＭの識別情報が格納されるＶＭ ＩＤ１８０１、現時点での各ＶＭが使用されるトラフィックが格納される使用率１８０２、および各ＶＭが収容できるトラフィックの最大の接続数が格納されるトラフィック収容力１８０３を記憶する。
【００８６】
ＶＭを新たに登録するとき、ＶＭ管理テーブル２１２にはレコードが生成され、ＶＭを削除するとき、ＶＭ管理テーブル２１２からレコードが削除される。また、使用率１８０２は、周期的にＶＭからリアルタイムで取得した値が反映される。
【００８７】
イベントテーブル２０９の当該イベントに関する、スケジュールテーブル２１１に記載されたスケーリングを実施している間、この使用率の最大値を計測し、スケーリングの実施後に、その最大値をイベントテーブル２０９の当該イベントのレコードのトラフィック１７０８に反映することにしてもよい。
【００８８】
図１９はＶＭ生成部２０５がＶＭのスケールアウトを実施する処理を示すフローチャートである。
【００８９】
ステップ１９０１にてＶＭのスケールアウトのスケジュールの実施日時に実施承認状態がＯＫであれば、ＶＭ生成部２０５は、ＶＭのスケールアウトを開始する（ステップ１９０３）。一方、ＶＭのスケールアウトのスケジュールの実施時期に実施承認状態がＯＫでなければ、ＶＭ生成部２０５は、そのスケジュールを破棄する（ステップ１９０２）。
【００９０】
スケールアウトを開始したＶＭ生成部２０５は、ＶＭ管理テーブル２１２にて管理されているトラフィック収容力およびリアルタイムの使用率を参照することによりＶＭの収容能力を確認し（ステップ１９０４）、スケールアウトを実施するのに十分な収容能力がある場合、ＶＭを生成する（ステップ１９０５）。
【００９１】
ステップ１９０４にてスケールアウトを実施するのに十分な収容能力が無い場合、ＶＭ生成部２０５は、ＶＭの収容能力を増強した後（ステップ１９０６）、ＶＭを生成する（ステップ１９０５）。ＶＭの収容能力の増強は例えば削除可能なＶＭを削除することにより行えばよい。ステップ１９０５では、ＶＭ生成部２０５は、スケジュールテーブル２１１に記載されているトラフィック１５０４に応じた収容能力を確保するようにＶＭを生成する。
【００９２】
更に、ＶＭ生成部２０５はＶＭをロードバランスする（ステップ１９０７）。ステップ１９０７では、ＶＭ生成部２０５は、ＶＭ管理テーブル２１２に格納されている各ＶＭの使用率１８０２を参照し、各ＶＭの負荷が閾値を超えないように、ロードバランスを実施する。
【００９３】
図２０はＶＭ生成部２０５がＶＭのスケールインを実施する処理を示すフローチャートである。
【００９４】
ステップ２００１にてＶＭのスケールインのスケジュールの実施日時に実施承認状態がＯＫであれば、ＶＭ生成部２０５は、ＶＭのスケールインを開始する（ステップ２００３）。一方、ＶＭのスケールアウトのスケジュールの実施時期に実施承認状態がＯＫでなければ、ＶＭ生成部２０５は、そのスケジュールを破棄する（ステップ２００２）。
【００９５】
スケールインを開始したＶＭ生成部２０５は、スケジュールテーブル２１１に記載されているトラフィック１５０４に相当するＶＭの使用を停止させる（ステップ２００４）。次に、ＶＭ生成部２０５は、使用を停止したＶＭをシャットダウンする（ステップ２００５）。次に、ＶＭ生成部２０５は、シャットダウンしたＶＭをＶＭ管理テーブル２１２から削除する（ステップ２００６）。
【００９６】
図２１Ａ、図２１Ｂは、ＶＭ管理テーブル２１２に管理されているＶＭのスケールアップによる変化の一例について説明するための図である。図２１Ａはスケールアウトの前のＶＭの使用状態であり、図２１Ｂはスケールアウト後のＶＭの使用状態である。
【００９７】
図１９に示したフローチャートにおいて、ＶＭ生成部２０５は、ＶＭを追加するのに十分な収容能力があれば（ステップ１９０４のＹＥＳ）、スケジュールテーブル２１１に記載されているトラフィック１７１８の＋１５６４０と、１つのＶＭのトラフィック収容力が１００００であることを確認し、増加した１５６４０のトラフィック量を収容できるように２つのＶＭを生成する。そして、ＶＭ生成部２０５は、ＶＭ管理テーブル２１２にＶＭ  ＩＤ＝３のレコード２１１１とＶＭ  ＩＤ＝４のレコード２１１２を新たに登録する。
【００９８】
各ＶＭにかかる負荷の閾値として、トラフィック収容力の８０％が設定されている場合、元から動作していた２つのＶＭと新たに追加された２つのＶＭの合計４つのＶＭについてロードバランスが行われる。ここでは一例として、ＶＭ  ＩＤ＝1のＶＭは使用率＝６０％（図２１Ａのレコード２１０４）から使用率＝８０％（図２１Ｂのレコード２１０９）へ変更される。また、ＶＭ  ＩＤ＝２のＶＭも使用率＝６０％（図２１Ａのレコード２１０５）から使用率＝８０％（図２１Ｂのレコード２１１０）へ変更される。また、新たに生成されたＶＭ  ＩＤ＝３のＶＭ（図２１Ｂのレコード２１１１）とＶＭ  ＩＤ＝４のＶＭ（図２１Ｂのレコード２１１２）は使用率＝６０％とされる。
【００９９】
ＶＭ生成部２０５が管理しているＶＭのトラフィック収容量の合計は１２０００（１００００×６０％＋１００００×６０％）から２８０００（１００００×８０％×２＋１００００×６０％×２）に増量され、レコード１７１９にあるスケールアウトのトラフィック＋１５６４０が収容可能となる。
【０１００】
図２２Ａ、図２２Ｂは、オートスケーリングにおいて、オペレータが操作するクライアント１０１の画面表示を示す図である。
【０１０１】
図２２Ａには、各スケジュールについて実施承認の操作が可能なスケジュール一覧画面が示されている。図１９に示されたスケールアウトの処理を実施するために、オペレータは、図２２Ａに示されたスケジュール一覧画面より、スケールアウトの実施を承認する操作を行う。具体的には、オペレータはスケールアウトの実施承認の「ＯＫ」ボタンを押下する。
【０１０２】
実施承認状態が「ＯＫ」になり、その状態でスケールアウトの実施日時である１６：３０になると、図２２Ｂに示すＶＭビュー画面に、各ＶＭの登録状態が表示される。図２２Ｂには、もともと登録されているＶＭ  ＩＤ＝１のＶＭとＶＭ  ＩＤ＝２のＶＭは実線の円で表示される。また、生成中のＶＭ  ＩＤ＝３のＶＭとＶＭ  ＩＤ＝４のＶＭは破線の円で表示される。
【０１０３】
図２３Ａ、図２３Ｂは、ＶＭ管理テーブル２１２に管理されているＶＭのスケールインによる変化の一例について説明するための図である。図２３Ａはスケールインの前のＶＭの使用状態であり、図２３Ｂはスケールイン後のＶＭの使用状態である。
【０１０４】
図２０に示したフローチャートにおいて、ＶＭ生成部２０５は、図１９に示したスケールアウトの処理で生成したＶＭ  ＩＤ＝３のＶＭ（図２３Ａのレコード２３０６）とＶＭ  ＩＤ＝４のＶＭ（図２３Ａのレコード２３０７）の使用を停止し、それらのＶＭをシャットダウンし、削除する。さらに、ＶＭのオートスケーリングにより、ＶＭ  ＩＤ＝１のＶＭと、ＶＭ  ＩＤ＝２のＶＭの使用率は、実際のトラフィック量に応じてスケールアウト前の状態に戻る。
【０１０５】
その結果、ＶＭ生成部２０５が管理しているＶＭのトラフィック収容量の合計は２８０００（１００００×８０％×２＋１００００×６０％×２）から１２０００（１００００×６０％＋１００００×６０％）に戻り、レコード１７２０にあるスケールインのトラフィック−１５６４０が実現される。
【０１０６】
図２４Ａ、図２５Ｂは、オートスケーリングにおいて、オペレータが操作するクライアント１０１の画面表示を示す図である。
【０１０７】
図２４Ａには、未実施のスケジュールすなわちスケールインについて実施承認の操作が可能なスケジュール一覧画面が示されている。図２０に示されたスケールインの処理を実施するために、オペレータは、図２４Ａに示されたスケジュール一覧画面より、スケールインの実施を承認する操作を行う。具体的には、オペレータはスケールインの実施承認の「ＯＫ」ボタンを押下する。
【０１０８】
実施承認状態が「ＯＫ」になり、その状態でスケールインの実施日時である２３：００になると、図２４Ｂに示すＶＭビュー画面に、各ＶＭの登録状態が表示される。図２４Ｂには、登録が維持されるＶＭ  ＩＤ＝１のＶＭとＶＭ  ＩＤ＝２のＶＭは実線の円で表示される。また、削除中のＶＭ  ＩＤ＝３のＶＭとＶＭ  ＩＤ＝４のＶＭは破線の円で表示される。
【０１０９】
以上説明した本実施形態の構成および動作を整理すると以下のように説明することができる。
【０１１０】
本実施形態のオーケストレーションサーバ１０３は、仮想マシンにより処理を行う仮想ネットワークのスケーリングを行うサーバ装置であり、データ分析部２０３と、スケジュール部２０４と、仮想マシン生成部２０５と、を有する。
【０１１１】
データ分析部２０３は、イベントの開催予定に関する情報を含むイベント予定データに基づいて、イベントに起因して発生する処理負荷の発生時間および負荷量に関する情報を含むイベント負荷データを作成する。スケジュール部２０４は、イベント負荷データに基づいて、イベントに起因して発生する処理負荷に応じてスケールアウトおよびスケールインを実施するためのスケーリング実施スケジュールを作成する。仮想マシン生成部２０５は、スケーリング実施スケジュールに従ってスケールアウトおよびスケールインを実施する。
【０１１２】
これによれば、イベントの開催予定に基づいたスケジュールに従ってスケーリングを実施するので、過去に経験のないイベントに適切に対応可能なオートスケーリングが実現できる。
【０１１３】
また、イベント予定データは、イベントの開催場所と、開始日時と、集まる人の数に関連する人的規模関連情報とをイベントデータ要素として含み、データ分析部２０３は、過去に実施されたイベントに関する情報に基づいて、イベントのイベントデータ要素と、イベントに起因して発生した処理負荷の負荷量との対応関係を予め算出してイベント開催データとして保持しておき、イベント予定データからイベントデータ要素を抽出し、抽出したイベントデータ要素に相当するイベントデータ要素を含むイベント開催データに基づいてイベント負荷データを作成する。
【０１１４】
これによれば、過去のイベントに関する、開催場所、開始時刻、および人的規模関連情報とイベントに起因して発生する処理負荷の負荷量との対応関係を予め算出しておき、開催予定のイベントに相当するイベント開催データに基づいてイベント負荷データを作成するので、過去の実績を基にイベントに起因する処理負荷を正確に予測することが可能である。
【０１１５】
また、イベント予定データは、更に、イベントのジャンル、属性、および終了時刻をイベントデータ要素として含む。
【０１１６】
これによれば、ジャンル、属性、開催場所、開始時刻、終了時刻、および人的規模関連情報で、開催予定のイベントに相当するイベント開催データを決定するので、より多くの情報を用いて、過去の実績を基にイベントに起因する処理負荷を正確に予測することが可能である。
【０１１７】
また、データ分析部２０３は、イベント予定データに対応するイベント開催データが存在すればそのイベント開催データに基づいてイベント負荷データを作成し、イベント予定データに対応するイベント開催データが存在しなければ、過去に実施されたイベントに関する情報に基づく学習で、イベント予定データに対応するイベント開催データを作成する。
【０１１８】
学習によりイベント開催データを追加して、処理負荷を予測する精度を向上させることができる。
【０１１９】
また、スケジュール部２０４は、イベントに起因する処理負荷の発生に合わせてスケールアウトを実施し、処理負荷の終了に合わせてスケールインを実施するようにスケーリング実施スケジュールを作成する。
【０１２０】
これにより、イベントに起因する処理負荷が発生する期間、その処理負荷の処理にリソースを割り当てるので、イベントに起因する処理負荷を適切に処理することが可能となる。
【０１２１】
また、スケジュール部２０４は、イベントの開始日時の所定時間前にスケールアウトを実施し、処理負荷の終了時刻の所定時間後にスケールインを実施するようにスケーリング実施スケジュールを作成する。ここでいう所定時間は、上述したスケジューリング時間８０７である。
【０１２２】
これによれば、イベントに起因する処理負荷がイベントの開始前から始まり、イベントの終了後まで続く場合にも、イベントに起因する処理負荷を適切に処理することが可能となる。
【０１２３】
また、仮想マシン生成部２０５は、オペレータの操作に応じて、スケールアウトおよびスケールインを実施するか否かを選択する。
【０１２４】
これによれば、オーケストレーションサーバ１０３が自動的に生成したスケジュールをオペレータが実施前に確認するので、安全性を向上することができる。
【０１２５】
また、データ分析部２０３は、イベントに起因する処理負荷が発生している間の複数の範囲のそれぞれを対象とする仮想ノードの使用率の最大値を取得し、それ以降に、イベントに用いたものと同じイベント開催データを用いてスケーリングを実施するとき、その最大値が大きかった範囲を優先して仮想ノードを作成するように、スケーリングを実施する範囲を決定する。
【０１２６】
これによれば、各範囲について仮想ノードの使用率の最大値から、大きな処理負荷が生じている範囲に対して仮想ノードを追加作成するので、適切な範囲に対して効率よく仮想ノードを作成することができる。
【０１２７】
上述した本発明の実施形態は、本発明の説明のための例示であり、本発明の範囲をそれらの実施形態にのみ限定する趣旨ではない。当業者は、本発明の要旨を逸脱することなしに、他の様々な態様で本発明を実施することができる。
【符号の説明】
【０１２８】
１００２…イベント、１００３…場所名、１００６…スケジュール登録ボタン、１０１…クライアント、１０２…ＭＧＭＴＳＷ、１０３…オーケストレーションサーバ、１０４…クラウド管理サーバ、１０５…サービスＳＷ、１０６…Ｃｏｍｐｕｔｅサーバ、１３０９…レコード、１４０１…シナリオＩＤ、１４０２…シナリオ名、１４０３…スケールイン、１４０４…スケールアウト、１５０１…スケジュールＩＤ、１５０２…実施日時、１５０３…シナリオＩＤ、１５０４…トラフィック、１５０５…実施承認状態、１５０６…レコード、１７０８…トラフィック、１７０９…レコード、１７１３…レコード、１７１９…レコード、１７２０…レコード、１８０２…使用率、１８０３…トラフィック収容力、２０１…ＣＰＵ、２０２…メモリ、２０３…データ分析部、２０４…スケジュール部、２０５…ＶＭ生成部、２０６…ジャンルテーブル、２０７…ジャンル属性テーブル、２０８…場所管理テーブル、２０９…イベントテーブル、２１０…シナリオテーブル、２１１…スケジュールテーブル、２１２…ＶＭ管理テーブル、３０１…ＣＰＵ、３０２…メモリ、３０３…Ｃｏｍｐｕｔｅ管理プログラム、３０４…Ｎｅｔｗｏｒｋ管理プログラム、３０５…Ｃｏｍｐｕｔｅ管理テーブル、３０６…Ｎｅｔｗｏｒｋ管理テーブル、４０１…ＣＰＵ、４０２…メモリ、４０３…クラウド管理エージェント、４０４…Ｈｙｐｅｒｖｉｓｏｒ、４０５…ＶＭ管理テーブル、４０６…ＶＭイメージ、４０７…ディスク装置、５０１…ジャンルＩＤ、５０２…ジャンル名、６０１…ジャンルＩＤ、６０２…属性ＩＤ、６０３…属性名、６０４…観客動員率、７０１…場所ＩＤ、７０２…場所名、７０３…収容人数、８０１…イベントＩＤ、８０２…ジャンルＩＤ、８０３…属性ＩＤ、８０４…場所ＩＤ、８０５…開催日時、８０６…終了日時、８０７…スケジューリング時間、８０８…トラフィック
【図１】
2017173894.tif 000003
【図２】
2017173894.tif 000004
【図３】
2017173894.tif 000005
【図４】
2017173894.tif 000006
【図５】
2017173894.tif 000007
【図６】
2017173894.tif 000008
【図７】
2017173894.tif 000009
【図８】
2017173894.tif 000010
【図９】
2017173894.tif 000011
【図１０】
2017173894.tif 000012
【図１１】
2017173894.tif 000013
【図１２Ａ】
2017173894.tif 000014
【図１２Ｂ】
2017173894.tif 000015
【図１２Ｃ】
2017173894.tif 000016
【図１３】
2017173894.tif 000017
【図１４】
2017173894.tif 000018
【図１５】
2017173894.tif 000019
【図１６】
2017173894.tif 000020
【図１７Ａ】
2017173894.tif 000021
【図１７Ｂ】
2017173894.tif 000022
【図１７Ｃ】
2017173894.tif 000023
【図１８】
2017173894.tif 000024
【図１９】
2017173894.tif 000025
【図２０】
2017173894.tif 000026
【図２１Ａ】
2017173894.tif 000027
【図２１Ｂ】
2017173894.tif 000028
【図２２Ａ】
2017173894.tif 000029
【図２２Ｂ】
2017173894.tif 000030
【図２３Ａ】
2017173894.tif 000031
【図２３Ｂ】
2017173894.tif 000032
【図２４Ａ】
2017173894.tif 000033
【図２４Ｂ】
2017173894.tif 000034