JP2017173894A

JP2017173894A - Orchestration server, orchestration method, and orchestration program

Info

Publication number: JP2017173894A
Application number: JP2016055819A
Authority: JP
Inventors: シュウイ陳; Shui Chen; 大輔岡部; Daisuke Okabe; 古橋　亮慈; Ryoji Furuhashi; 亮慈古橋
Original assignee: Hitachi Ltd
Current assignee: Hitachi Ltd
Priority date: 2016-03-18
Filing date: 2016-03-18
Publication date: 2017-09-28

Abstract

PROBLEM TO BE SOLVED: To achieve auto-scaling capable of corresponding to even an unknown event.SOLUTION: An orchestration server is an orchestration server for performing scaling of a virtual network which performs processing by a virtual machine, the orchestration server comprising: a data analysis part for, on the basis of event schedule data including information on a holding schedule of an event, creating event load data including information on occurrence time and load amounts of a processing load which occurs due to the event; a schedule part for, on the basis of the event load data, creating a scaling execution schedule for executing scale-out and scale-in in accordance with the processing load which occurs due to the event; and a virtual machine generation part for executing the scale-out and the scale-in in accordance with the scaling execution schedule.SELECTED DRAWING: Figure 2

Description

本発明は、仮想化されたネットワークにおける仮想ノードのスケーリングを行う技術に関する。 The present invention relates to a technique for scaling a virtual node in a virtualized network.

仮想ネットワークにおけるオートスケーリングは、仮想ネットワークで稼働する仮想ノードの台数を増やしたり、減らしたりする機能である。仮想ノードの台数を増やすことをスケールアウトといい、仮想ノードの台数を減らすことをスケールインという。仮想ネットワークサービスの提供者は、顧客の需要に基づき、遠隔からオートスケーリングを実施することが可能である。 Autoscaling in a virtual network is a function that increases or decreases the number of virtual nodes operating in the virtual network. Increasing the number of virtual nodes is called scale-out, and reducing the number of virtual nodes is called scale-in. A virtual network service provider can remotely perform autoscaling based on customer demand.

仮想ネットワークの負荷が増えたとき、スケールアウトすると、各仮想ノードの負荷を減らし、処理性能を向上させることができる。また、仮想ノードの負荷が減ったとき、スケールインすると、管理装置により管理する仮想ノードの個数を減らし、リソースの使用効率を向上することができる。 When the load on the virtual network increases, scaling out reduces the load on each virtual node and improves the processing performance. In addition, when the load on the virtual node is reduced, scaling in can reduce the number of virtual nodes managed by the management apparatus and improve resource use efficiency.

特許文献１は、時間帯別、地域別、曜日別に、仮想ノードの通信による物理サーバのリソースの使用率に閾値を設定し、使用率が閾値以上となったときあるいは使用率が閾値を超えたとき、その時点で使用率を示す情報を取得する。そして、その取得した使用率に基づいて、物理サーバのどの程度のリソースを仮想呼処理サーバ用として割り当てるかを決定し、その決定に従って、物理サーバ上に仮想呼処理サーバを生成する。 Patent Document 1 sets a threshold for the usage rate of a physical server resource by communication of a virtual node for each time zone, each region, and each day of the week, and when the usage rate exceeds the threshold or the usage rate exceeds the threshold At that time, information indicating the usage rate is acquired. Then, based on the acquired usage rate, it is determined how much resources of the physical server are allocated for the virtual call processing server, and a virtual call processing server is generated on the physical server according to the determination.

特許第５５３７６００号公報Japanese Patent No. 5537600

特許文献１の技術では、日常の通信によるリソースの使用率を学習し、学習結果に基づいて閾値を設定し、仮想ノードを拡張するために割り付けるリソース量を決定する。よって、過去に発生したことの無いイベントにより通信量が急激に上昇したような場合、過去の通信によるリソースの使用率のデータに基づく、仮想ノードの拡張のために割り当てるリソース量が不適当となる可能性がある。また、使用率の急激な変化に仮想ノードの追加生成が間に合わず、仮想ノードにおける輻輳が続いてしまう可能性がある。そのため、通信量が急激に上昇したときに迅速に通信の収容能力を高めることができるように、常時、余剰のリソースを確保しておかなければならず、コストが膨大となる。 In the technique of Patent Document 1, a resource usage rate by daily communication is learned, a threshold is set based on a learning result, and an amount of resources to be allocated for expanding a virtual node is determined. Therefore, when the amount of communication suddenly increases due to an event that has not occurred in the past, the amount of resources to be allocated for virtual node expansion based on data on the resource usage rate by past communication becomes inappropriate. there is a possibility. Moreover, there is a possibility that the virtual node will not continue to be created in time for the rapid change in the usage rate, and congestion in the virtual node will continue. For this reason, surplus resources must be secured at all times so that the capacity for communication can be quickly increased when the traffic volume rapidly increases, resulting in a huge cost.

本発明の目的は、未知のイベントにも対応できるオートスケーリングを実現する技術を提供することである。 An object of the present invention is to provide a technique for realizing autoscaling that can cope with an unknown event.

本発明の一態様によるオーケストレーションサーバは、仮想マシンにより処理を行う仮想ネットワークのスケーリングを行うオーケストレーションサーバであって、イベントの開催予定に関する情報を含むイベント予定データに基づいて、前記イベントに起因して発生する処理負荷の発生時間および負荷量に関する情報を含むイベント負荷データを作成するデータ分析部と、前記イベント負荷データに基づいて、前記イベントに起因して発生する処理負荷に応じてスケールアウトおよびスケールインを実施するためのスケーリング実施スケジュールを作成するスケジュール部と、前記スケーリング実施スケジュールに従って前記スケールアウトおよび前記スケールインを実施する仮想マシン生成部と、を有する。 An orchestration server according to an aspect of the present invention is an orchestration server that scales a virtual network that performs processing by a virtual machine, and is based on event schedule data that includes information related to an event schedule. A data analysis unit for creating event load data including information on the generation time and load amount of the processing load generated in response to the scale-out according to the processing load generated due to the event based on the event load data and A scheduling unit that creates a scaling execution schedule for performing scale-in, and a virtual machine generation unit that performs the scale-out and scale-in according to the scaling execution schedule.

本発明よれば、イベントの開催予定に基づいたスケジュールに従ってスケーリングを実施するので、過去に経験のないイベントに適切に対応可能なオートスケーリングが実現できる。 According to the present invention, the scaling is performed according to the schedule based on the event schedule, so that it is possible to realize autoscaling that can appropriately deal with events that have not been experienced in the past.

本実施形態の仮想ネットワークのブロック図である。It is a block diagram of the virtual network of this embodiment. オーケストレーションサーバ１０３の機能ブロック図である。3 is a functional block diagram of an orchestration server 103. FIG. クラウド管理サーバ１０４の機能ブロック図である。3 is a functional block diagram of a cloud management server 104. FIG. Ｃｏｍｐｕｔｅサーバ１０６の機能ブロック図である。4 is a functional block diagram of a Compute server 106. FIG. ジャンルテーブル２０６の一例を示す図である。It is a figure which shows an example of the genre table. ジャンル属性テーブル２０７の一例を示す図である。6 is a diagram illustrating an example of a genre attribute table 207. FIG. 場所管理テーブル２０８の一例を示す図である。5 is a diagram illustrating an example of a location management table 208. FIG. イベントテーブル２０９の一例を示す図である。It is a figure which shows an example of the event table 209. FIG. データ分析部２０３がイベントテーブル２０９のレコードを作成する処理を示すフローチャートである。10 is a flowchart showing processing for creating a record of an event table 209 by a data analysis unit 203. クライアント１０１におけるイベント予定データ入力画面の一例を示す図である。6 is a diagram illustrating an example of an event schedule data input screen in the client 101. FIG. ステップ９０５の詳細処理を示すフローチャートである。It is a flowchart which shows the detailed process of step 905. 作成例の説明に用いるジャンルテーブル２０６である。It is the genre table 206 used for description of a creation example. 作成例の説明に用いるジャンル属性テーブル２０７である。It is a genre attribute table 207 used for explanation of a creation example. 作成例の説明に用いる場所管理テーブル２０８である。It is the place management table 208 used for description of a creation example. 作成例の説明に用いるイベントテーブル２０９である。It is the event table 209 used for description of a creation example. スケジュール部２０４のシナリオテーブル２１０の一例を示す図である。It is a figure which shows an example of the scenario table 210 of the schedule part 204. FIG. スケジュール部２０４のスケジュールテーブル２１１の一例を示す図である。It is a figure which shows an example of the schedule table 211 of the schedule part 204. FIG. スケジュール部２０４がスケジュールテーブル２１１にスケーリングのスケジュールを登録する処理のフローチャートである。10 is a flowchart of processing in which a schedule unit 204 registers a scaling schedule in a schedule table 211. イベントテーブル２０９の一例を示す図である。It is a figure which shows an example of the event table 209. FIG. シナリオテーブル２１０の一例を示す図である。It is a figure which shows an example of the scenario table. スケジュールテーブル２１１の一例を示す図である。It is a figure which shows an example of the schedule table. ＶＭ生成部２０５がＶＭの使用状態を管理するためのＶＭ管理テーブル２１２の一例を示す図である。It is a figure which shows an example of the VM management table 212 for the VM production | generation part 205 to manage the usage condition of VM. ＶＭ生成部２０５がＶＭのスケールアウトを実施する処理を示すフローチャートである。It is a flowchart which shows the process in which the VM production | generation part 205 implements VM scale-out. ＶＭ生成部２０５がＶＭのスケールインを実施する処理を示すフローチャートである。It is a flowchart which shows the process in which the VM production | generation part 205 implements VM scale-in. ＶＭ管理テーブル２１２に管理されているＶＭのスケールアップによる変化の一例について説明するための図である。FIG. 10 is a diagram for describing an example of a change caused by scaling up a VM managed in a VM management table 212; ＶＭ管理テーブル２１２に管理されているＶＭのスケールアップによる変化の一例について説明するための図である。FIG. 10 is a diagram for describing an example of a change caused by scaling up a VM managed in a VM management table 212; オートスケーリングにおいて、オペレータが操作するクライアント１０１の画面表示を示す図である。It is a figure which shows the screen display of the client 101 which an operator operates in auto scaling. オートスケーリングにおいて、オペレータが操作するクライアント１０１の画面表示を示す図である。It is a figure which shows the screen display of the client 101 which an operator operates in auto scaling. ＶＭ管理テーブル２１２に管理されているＶＭのスケールインによる変化の一例について説明するための図である。FIG. 10 is a diagram for describing an example of a change in a VM managed in a VM management table 212 due to scale-in. ＶＭ管理テーブル２１２に管理されているＶＭのスケールインによる変化の一例について説明するための図である。FIG. 10 is a diagram for describing an example of a change in a VM managed in a VM management table 212 due to scale-in. オートスケーリングにおいて、オペレータが操作するクライアント１０１の画面表示を示す図である。It is a figure which shows the screen display of the client 101 which an operator operates in auto scaling. オートスケーリングにおいて、オペレータが操作するクライアント１０１の画面表示を示す図である。It is a figure which shows the screen display of the client 101 which an operator operates in auto scaling.

本発明の実施形態について図面を参照して詳細に説明する。 Embodiments of the present invention will be described in detail with reference to the drawings.

図１は、本実施形態の仮想ネットワークのブロック図である。仮想ネットワークは、ＭＧＭＴＳＷ（マネジメントスイッチ）１０２、オーケストレーションサーバ１０３、クラウド管理サーバ１０４、サービスＳＷ（スイッチ）１０５、およびＣｏｍｐｕｔｅサーバ１０６を有している。 FIG. 1 is a block diagram of the virtual network of this embodiment. The virtual network includes an MGMTSW (management switch) 102, an orchestration server 103, a cloud management server 104, a service SW (switch) 105, and a compute server 106.

複数のＣｏｍｐｕｔｅサーバ１０６、１０７、１０８がサービスＳＷ１０５に接続されている。本実施形態のＣｏｍｐｕｔｅサーバ１０６、１０７、１０８は、通信処理を実行する仮想ノードが作成される計算機である。サービスＳＷ１０５は、通信サービスネットワークを実現するスイッチ群である。ＭＧＭＴＳＷ１０２は、管理ネットワークを実現するスイッチ群である。 A plurality of Compute servers 106, 107 and 108 are connected to the service SW 105. The Compute servers 106, 107, and 108 of this embodiment are computers in which virtual nodes that execute communication processing are created. The service SW 105 is a switch group that realizes a communication service network. The MGMTSW 102 is a switch group that realizes a management network.

オーケストレーションサーバ１０３は、クラウド管理サーバ１０４と連携し、クラウド上の仮想ネットワークのリソースの運用を管理する。図１に示したように、オーケストレーションサーバ１０３はクラウド管理サーバ１０４と接続し、サービスＳＷ１０５を介して、Ｃｏｍｐｕｔｅサーバ１０６、１０７、１０８上の仮想ノードを管理する。オーケストレーションサーバ１０３は、ＭＧＭＴＳＷ１０２を介して提供されたクライアント１０１に対するオペレータの操作により各種処理を実行する。 The orchestration server 103 cooperates with the cloud management server 104 to manage the operation of virtual network resources on the cloud. As shown in FIG. 1, the orchestration server 103 is connected to the cloud management server 104 and manages virtual nodes on the Compute servers 106, 107, and 108 via the service SW 105. The orchestration server 103 executes various processes in accordance with operator operations on the client 101 provided via the MGMTSW 102.

図２はオーケストレーションサーバ１０３の機能ブロック図である。オーケストレーションサーバ１０３はＣＰＵ２０１およびメモリ２０２を有している。ＣＰＵ２０１がメモリ２０２上のプログラムを実行することにより、データ分析部２０３、スケジュール部２０４、およびＶＭ（仮想マシン）生成部２０５が実現される。 FIG. 2 is a functional block diagram of the orchestration server 103. The orchestration server 103 has a CPU 201 and a memory 202. When the CPU 201 executes a program on the memory 202, a data analysis unit 203, a schedule unit 204, and a VM (virtual machine) generation unit 205 are realized.

データ分析部２０３は、クライアント１０１により入力されたデータを、ＭＧＭＴＳＷ１０２を介して受信し、処理する。スケジュール部２０４およびＶＭ生成部２０５はデータ分析部２０３から受け取った情報を基にして、クラウド管理サーバ１０４を介して、Ｃｏｍｐｕｔｅサーバ１０６、１０７、１０８上でのＶＭの起動および停止を制御する。 The data analysis unit 203 receives the data input by the client 101 via the MGMTSW 102 and processes it. Based on the information received from the data analysis unit 203, the schedule unit 204 and the VM generation unit 205 control the activation and termination of the VM on the Compute servers 106, 107, and 108 via the cloud management server 104.

データ分析部２０３は、ジャンルテーブル２０６、ジャンル属性テーブル２０７、場所管理テーブル２０８、およびイベントテーブル２０９を備える。 The data analysis unit 203 includes a genre table 206, a genre attribute table 207, a location management table 208, and an event table 209.

ジャンルテーブル２０６、ジャンル属性テーブル２０７、場所管理テーブル２０８はイベントのジャンル、属性、開催場所といった、イベントが持つ客観的な性質に関する情報を保持する。イベントテーブル２０９は、予定されているイベントに起因して発生する処理負荷（トラフィック）の発生時間および負荷量に関する情報を含むイベント負荷データである。イベントテーブル２０９は、イベントに関連して仮想ネットワークのスケーリングを行うために用いられる。 The genre table 206, the genre attribute table 207, and the place management table 208 hold information related to the objective properties of the event, such as the event genre, attributes, and venue. The event table 209 is event load data including information on the generation time and load amount of processing load (traffic) generated due to a scheduled event. The event table 209 is used to scale the virtual network in relation to the event.

スケジュール部２０４は、シナリオテーブル２１０およびスケジュールテーブル２１１を備え、オーケストレーションサーバ１０３としてスケジュール通り計画的にシナリオを適用する。スケジュール部２０４の詳細は後述する。 The schedule unit 204 includes a scenario table 210 and a schedule table 211, and applies the scenario in a planned manner as the orchestration server 103 according to the schedule. Details of the schedule unit 204 will be described later.

ＶＭ生成部２０５は、ＶＭ管理テーブル２１２を備える。ＶＭ生成部２０５は、シナリオに従って、ＶＭのスケールイン、スケールアウトなどの処理を実行する。ＶＭ生成部２０５の詳細は後述する。 The VM generation unit 205 includes a VM management table 212. The VM generation unit 205 executes processing such as VM scale-in and scale-out according to the scenario. Details of the VM generation unit 205 will be described later.

図３はクラウド管理サーバ１０４の機能ブロック図である。クラウド管理サーバ１０４はＣＰＵ３０１およびメモリ３０２を有している。メモリ３０２上には、Ｃｏｍｐｕｔｅ管理プログラム３０３、Ｎｅｔｗｏｒｋ管理プログラム３０４、Ｃｏｍｐｕｔｅ管理テーブル３０５、Ｎｅｔｗｏｒｋ管理テーブル３０６が記録されている。クラウド管理サーバ１０４はＣｏｍｐｕｔｅ管理プログラム３０３およびＮｅｔｗｏｒｋ管理プログラム３０４の実行を介して、ＶＭ等の仮想ネットワークのリソースを制御する。 FIG. 3 is a functional block diagram of the cloud management server 104. The cloud management server 104 has a CPU 301 and a memory 302. On the memory 302, a Computer management program 303, a Network management program 304, a Compute management table 305, and a Network management table 306 are recorded. The cloud management server 104 controls virtual network resources such as VMs through the execution of the Compute management program 303 and the Network management program 304.

図４はＣｏｍｐｕｔｅサーバ１０６の機能ブロック図である。Ｃｏｍｐｕｔｅサーバ１０６はＣＰＵ４０１、メモリ４０２、およびディスク装置４０７を有している。メモリ４０２上には、クラウド管理エージェント４０３、Ｈｙｐｅｒｖｉｓｏｒ４０４、およびＶＭ管理テーブル４０５が記録されている。ディスク装置４０７上にはＶＭイメージ４０６が格納されている。Ｃｏｍｐｕｔｅサーバ１０６は、ＣＰＵ４０１によるクラウド管理エージェント４０３の実行を介して、Ｈｙｐｅｒｖｉｓｏｒ４０４上にＶＭを立ち上げる。
ＶＭイメージはＶＭを画面上にＶＭを表示するときの表示イメージを示すデータである。 FIG. 4 is a functional block diagram of the Compute server 106. The Compute server 106 includes a CPU 401, a memory 402, and a disk device 407. On the memory 402, a cloud management agent 403, a hypervisor 404, and a VM management table 405 are recorded. A VM image 406 is stored on the disk device 407. The Compute server 106 starts up a VM on the hypervisor 404 through execution of the cloud management agent 403 by the CPU 401.
The VM image is data indicating a display image when the VM is displayed on the screen.

図５、図６、図７、および図８を用いて、データ分析部２０３が管理するイベントの開催情報（イベント予定データ）およびそのトラフィックについて説明する。 Event holding information (event schedule data) managed by the data analysis unit 203 and its traffic will be described with reference to FIGS. 5, 6, 7, and 8.

図５は、ジャンルテーブル２０６の一例を示す図である。図５には、イベントのジャンル識別情報（ジャンルＩＤ）とジャンル名の対応が示されている。各ジャンルにはジャンルＩＤとジャンル名が付与されており、それがジャンルテーブル２０６に格納される。ジャンル名５０２、ジャンルＩＤ５０１は、イベントの主題およびスタイルなどの構成要素により事前に分類される。 FIG. 5 is a diagram illustrating an example of the genre table 206. FIG. 5 shows correspondence between event genre identification information (genre ID) and genre names. Each genre is given a genre ID and a genre name, which are stored in the genre table 206. The genre name 502 and the genre ID 501 are classified in advance by components such as the theme and style of the event.

本実施形態では、レコード５０３はジャンルＩＤ＝１でジャンル名がコンサートである。また、レコード５０４は、ジャンルＩＤ＝２でジャンル名がスポーツである。また、レコード５０５は、ジャンルＩＤ＝３でジャンル名が花火大会である。なお、このジャンルの定義は一例であり、他の分類を用いてもよい。例えば、仮想ネットワークのサービス提供対象により、イベント・チケット情報会社と連携し、そのイベント・チケット情報会社が用いている分類方法を用いてもよい。 In this embodiment, the record 503 has a genre ID = 1 and a genre name of concert. In the record 504, the genre ID = 2 and the genre name is sports. In the record 505, the genre ID = 3 and the genre name is a fireworks display. Note that this genre definition is an example, and other classifications may be used. For example, the classification method used by the event / ticket information company may be used in cooperation with the event / ticket information company depending on the service provision target of the virtual network.

図６は、ジャンル属性テーブル２０７の一例を示す図である。図６には、ジャンルＩＤ６０１、属性ＩＤ６０２、属性名６０３、および観客動員率６０４の対応が示されている。大分類である各ジャンルには、１つ以上の中分類である属性が含まれている。各属性には、属性ＩＤ６０２および属性名が付与されている。また、各属性には、観客動員率６０４が設定されている。観客動員率６０４とは、その属性のイベントにより動員可能な人数の、開催場所の収容人数に対する割合である。例えば、過去の履歴から予測した観客動員数が設定される。予測は、例えば過去のデータの平均値を算出することである。収容人数および観客動員率は、イベントの人的規模に関連する情報（人的規模関連情報）である。 FIG. 6 is a diagram illustrating an example of the genre attribute table 207. FIG. 6 shows the correspondence between the genre ID 601, the attribute ID 602, the attribute name 603, and the audience mobilization rate 604. Each genre that is a major classification includes one or more attributes that are a middle classification. Each attribute is given an attribute ID 602 and an attribute name. In addition, the audience mobilization rate 604 is set for each attribute. The audience mobilization rate 604 is the ratio of the number of people who can be mobilized by an event of that attribute to the number of people accommodated in the venue. For example, the number of spectators mobilized predicted from the past history is set. Prediction is, for example, calculating an average value of past data. The number of persons accommodated and the audience mobilization rate are information related to the human scale of the event (human scale related information).

例として、人気歌手のコンサートが観客動員率９２％であったという情報が与えられた場合のジャンル属性テーブル２０７への登録について例示する。 As an example, registration in the genre attribute table 207 when information indicating that a popular singer concert was an audience mobilization rate of 92% is given.

図５を参照すると、ジャンル名がコンサートのジャンルＩＤ＝１が得られる。図６には、ジャンル属性テーブル２０７には、ジャンルＩＤ６０１の列に当該ジャンルＩＤ＝１が、属性名６０３の列にジャンルＩＤに所属する属性名として人気歌手が、属性名に対応する属性ＩＤ＝１が、属性名のイベントに対する観客動員率を９２％としたレコード６０５が格納される。 Referring to FIG. 5, the genre name is the genre ID = 1 of the concert. In FIG. 6, the genre attribute table 207 includes a genre ID = 1 in the genre ID 601 column and a popular singer as an attribute name belonging to the genre ID in the attribute name 603 column. 1 stores a record 605 in which the audience mobilization rate for the attribute name event is 92%.

また、ジャンル名がコンサート、属性名が人気歌手、という情報が与えられ、観客動員率を求める場合を例示する。 Further, a case where information that the genre name is a concert and the attribute name is a popular singer is given and the audience mobilization rate is obtained is illustrated.

ジャンル名がコンサートという情報が与えられているので、図５を参照することによりジャンルＩＤ＝１が得られる。このジャンルＩＤ＝１を持って図６を参照すると、属性名が人気歌手の属性ＩＤ＝１と観客動員率＝９２％が得られる。 Since the information that the genre name is concert is given, genre ID = 1 is obtained by referring to FIG. Referring to FIG. 6 with this genre ID = 1, the attribute name is the popular singer attribute ID = 1 and the audience mobilization rate = 92%.

属性の区分は、ジャンルと同様に、オペレータが事前に設定してもよく、またはイベント・チケット情報会社と連携し、イベント・チケット情報会社で用いられている属性の区分を用いることにしてもよい。 The attribute classification may be set in advance by the operator in the same manner as the genre, or the attribute classification used in the event / ticket information company may be used in cooperation with the event / ticket information company. .

過去に開催された実績があるイベントに対して、各属性に対応する観客動員率はインターネット、リサーチ会社などを介して入手することが可能である。開催された実績がないイベントに対しては、開催されたイベントのデータに対する学習処理により、観客動員率を計算することが可能である。 For events that have been held in the past, the audience mobilization rate corresponding to each attribute can be obtained via the Internet, a research company, or the like. For events that have not been held, it is possible to calculate the audience mobilization rate by performing learning processing on the data of the held events.

図７は、場所管理テーブル２０８の一例を示す図である。図７に示す場所管理テーブル２０８に、イベントが開催される場所名７０２、場所識別情報（場所ＩＤ）が格納される場所ＩＤ７０１、および当該場所の収容人数７０３が格納される。場所名および収容人数など場所に関するデータはインターネットまたは各地域が管理する地域情報から入手することが可能である。 FIG. 7 is a diagram illustrating an example of the location management table 208. The place management table 208 shown in FIG. 7 stores a place name 702 where an event is held, a place ID 701 where place identification information (place ID) is stored, and a capacity 703 of the place. The location data such as the location name and the number of people can be obtained from the Internet or regional information managed by each region.

図８は、イベントテーブル２０９の一例を示す図である。図８に示すイベントテーブル２０９には、イベントの開催予定および開催時に予想される負荷（トラフィック）に関する情報が記録される。１つのイベントが１つのレコードに紐付けられる。 FIG. 8 is a diagram illustrating an example of the event table 209. In the event table 209 shown in FIG. 8, information related to the schedule of the event and the load (traffic) expected at the time of the event is recorded. One event is linked to one record.

イベント識別情報が格納されるイベントＩＤ８０１、図５に示されたジャンルテーブル２０６に格納されているジャンルＩＤ８０２、図６に示されたジャンル属性テーブル２０７に格納される属性ＩＤ８０３、図７に示された場所管理テーブル２０８に格納される場所ＩＤ８０４、イベントの開始日時８０５、終了日時８０６、イベントが開催される会場へ来場する観客の来場に要する時間および退場に要する時間に基づいて設定されたスケジューリング時間８０７、図６に示されたジャンル属性テーブル２０７の観客動員率６０４および図７に示された場所管理テーブル２０８の収容人数から計算されたトラフィック８０８が格納される。 Event ID 801 for storing event identification information, genre ID 802 stored in the genre table 206 shown in FIG. 5, attribute ID 803 stored in the genre attribute table 207 shown in FIG. 6, and shown in FIG. Scheduling time 807 set based on the location ID 804 stored in the location management table 208, the start date / time 805 of the event, the end date / time 806, the time required for the audience to visit the venue where the event is held, and the time required for exit The traffic 808 calculated from the audience mobilization rate 604 of the genre attribute table 207 shown in FIG. 6 and the capacity of the place management table 208 shown in FIG. 7 is stored.

本実施形態では、スケーリングをイベントの開始の何時間前から開始し、終了の何時間後まで行うかを示すスケジューリング時間を、予め定めた前後２時間としている。これはイベントの開始の２時間前から観客が集まり、終了の２時間後には観客の退場が終了するという想定による。 In the present embodiment, the scheduling time indicating how many hours before the start of the event starts and how many hours after the end of the event is set to 2 hours before and after the predetermined time. This is based on the assumption that the audience gathers 2 hours before the start of the event, and that the audience exits 2 hours after the end.

図９は、データ分析部２０３がイベントテーブル２０９のレコードを作成する処理を示すフローチャートである。データ分析部２０３は、図５に示したジャンルテーブル２０６、図６に示したジャンル属性テーブル２０７、および図７に示した場所管理テーブル２０８に格納されたイベント予定情報（イベント予定データ）から、図８に示したイベントテーブル２０９のレコードを作成する。 FIG. 9 is a flowchart illustrating processing in which the data analysis unit 203 creates a record in the event table 209. The data analysis unit 203 uses the event schedule information (event schedule data) stored in the genre table 206 shown in FIG. 5, the genre attribute table 207 shown in FIG. 6, and the place management table 208 shown in FIG. A record of the event table 209 shown in FIG.

データ分析部２０３は、イベントデータ分析を開始すると（ステップ９０１）、イベント予定データからイベントデータ要素を抽出する（ステップ９０２）。 When starting the event data analysis (step 901), the data analysis unit 203 extracts an event data element from the event schedule data (step 902).

図１０は、クライアント１０１におけるイベント予定データ入力画面の一例を示す図である。オペレータがクライアント１０１を介してイベント予定データにおけるイベントの項目１００２、場所の項目１００３、開始日時の項目１００４、および終了日時の項目１００５を入力し、スケジュール登録ボタン１００６を押下すると、それを契機として、データ分析部２０３は自動的にイベントのジャンル名、属性名、場所名、および開始時刻、終了時刻を抽出する。 FIG. 10 is a diagram illustrating an example of an event schedule data input screen in the client 101. When an operator inputs an event item 1002, a place item 1003, a start date / time item 1004, and an end date / time item 1005 in the event schedule data via the client 101 and presses the schedule registration button 1006, The data analysis unit 203 automatically extracts the event genre name, attribute name, location name, start time, and end time.

さらに、データ分析部２０３は、入力したイベント１００２から抽出されたジャンル名５０２を、ジャンルテーブル２０６を検索する検索キーとし、当該レコードに格納されたジャンルＩＤを取得する。 Further, the data analysis unit 203 uses the genre name 502 extracted from the input event 1002 as a search key for searching the genre table 206, and acquires the genre ID stored in the record.

同様に、データ分析部２０３は、ステップ９０２で抽出されたジャンルＩＤ６０１および属性名６０３を、ジャンル属性テーブル２０７を検索する検索キーとし、そのジャンルＩＤおよび属性名を有するレコードが存在するか否かを確認する（ステップ９０３）。 Similarly, the data analysis unit 203 uses the genre ID 601 and attribute name 603 extracted in step 902 as a search key for searching the genre attribute table 207, and determines whether or not a record having the genre ID and attribute name exists. Confirmation (step 903).

また、データ分析部２０３は、ステップ９０２で抽出された場所名１００３を、場所管理テーブル２０８を検索する検索キーとし、場所名が存在するか否かを確認する（ステップ９０３）。 Also, the data analysis unit 203 uses the place name 1003 extracted in step 902 as a search key for searching the place management table 208, and checks whether the place name exists (step 903).

ステップ９０２で抽出されたジャンルＩＤ６０１および属性名６０３を有するレコードが存在し、ステップ９０２で抽出された場所名１００３が存在する場合、開催予定のイベントは過去にも実施されたイベントである。一方、ステップ９０２で抽出されたジャンルＩＤ６０１および属性名６０３を有するレコードが存在しないか、ステップ９０２で抽出された場所名１００３が存在しない場合、開催予定のイベントは過去に実施されていないイベントである。 When there is a record having the genre ID 601 and the attribute name 603 extracted in step 902 and the place name 1003 extracted in step 902 exists, the event scheduled to be held is an event that has been performed in the past. On the other hand, if there is no record having the genre ID 601 and the attribute name 603 extracted in step 902 or the place name 1003 extracted in step 902 does not exist, the event scheduled to be held is an event that has not been performed in the past. .

ステップ９０２で抽出されたジャンルＩＤ６０１および属性名６０３を有するレコードが存在し、ステップ９０２で抽出された場所名１００３が存在する場合、データ分析部２０３は、ジャンル属性テーブル２０７から属性ＩＤ６０２および観客動員率６０４を、場所管理テーブル２０８から場所ＩＤ７０１および収容人数７０３を取得する。続けてフロー９０４以降の処理を実施する。 If there is a record having the genre ID 601 and attribute name 603 extracted in step 902 and the place name 1003 extracted in step 902 is present, the data analysis unit 203 reads the attribute ID 602 and the audience mobilization rate from the genre attribute table 207. In step 604, the place ID 701 and the accommodation number 703 are acquired from the place management table 208. Subsequently, the processes after the flow 904 are performed.

一方、ステップ９０２で抽出されたジャンルＩＤ６０１および属性名６０３を有するレコードが存在しないか、ステップ９０２で抽出された場所名１００３が存在しない場合、データ分析部２０３は、イベントデータ学習処理を実施し（ステップ９０５）、ステップ９０４へ進む。 On the other hand, if there is no record having the genre ID 601 and the attribute name 603 extracted in step 902 or the place name 1003 extracted in step 902 does not exist, the data analysis unit 203 performs an event data learning process ( Step 905), the process proceeds to Step 904.

ステップ９０４では、データ分析部２０３は、ステップ９０３にて取得したジャンルＩＤ５０１、属性ＩＤ６０２、および場所ＩＤ７０１を用いて、イベントテーブル２０９に当該イベントレコードがあるかどうか確認する。 In step 904, the data analysis unit 203 confirms whether the event table 209 has the event record using the genre ID 501, attribute ID 602, and location ID 701 acquired in step 903.

当該イベントレコードがある場合、データ分析部２０３は当該レコード８０９からスケジューリング時間８０７およびトラフィック８０８を抽出する。そして、データ分析部２０３は、イベントテーブル２０９に、イベントＩＤ８０１を新たに採番し、ステップ９０３にて取得したジャンルＩＤ８０２、属性ＩＤ８０３、場所ＩＤ８０４、前の処理で取得したスケジューリング時間８０７、トラフィック８０８、およびステップ９０２にて抽出した開始日時８０５および終了日時８０６を格納し、イベントレコードを登録する。 When there is the event record, the data analysis unit 203 extracts the scheduling time 807 and the traffic 808 from the record 809. Then, the data analysis unit 203 assigns a new event ID 801 to the event table 209, and acquires the genre ID 802, attribute ID 803, location ID 804 acquired in step 903, scheduling time 807 acquired in the previous processing, traffic 808, The start date 805 and end date 806 extracted in step 902 are stored, and an event record is registered.

一方、イベントレコードがない場合、データ分析部２０３は、イベントＩＤ８０１を採番し、ステップ９０３にて取得したジャンルＩＤ８０２、属性ＩＤ８０３、場所ＩＤ８０４、ステップ９０２にて抽出した開始日時８０５、および終了日時８０６をイベントテーブル２０９に格納する。 On the other hand, if there is no event record, the data analysis unit 203 assigns an event ID 801, and acquires the genre ID 802, attribute ID 803, location ID 804 acquired in step 903, start date 805 extracted in step 902, and end date 806. Are stored in the event table 209.

また、データ分析部２０３は、スケジューリング時間として、観客の入場する時間および退場する時間を考慮し、固定値の±２時間を設定する。 In addition, the data analysis unit 203 sets a fixed value of ± 2 hours as the scheduling time in consideration of the time for the audience to enter and the time to leave.

また、データ分析部２０３は、トラフィックについては、ステップ９０３にて取得した収容人数に観客動員率を乗算することで得た予測接続端末数を、イベントテーブル２０９に格納し、データ分析の処理を終了する（ステップ９０６）。 In addition, for the traffic, the data analysis unit 203 stores, in the event table 209, the predicted number of connected terminals obtained by multiplying the number of accommodated persons acquired in step 903 by the audience mobilization rate, and ends the data analysis process. (Step 906).

図１１は、ステップ９０５の詳細処理を示すフローチャートである。 FIG. 11 is a flowchart showing detailed processing of step 905.

ステップ９０５は、開催予定のイベントが過去に実施されていないイベントである場合に実行されるので、データ分析部２０３は、イベントデータ学習を開始すると、ジャンル属性テーブル２０７に、入力されたイベント予定データに該当するレコードが存在しないのか、場所管理テーブル２０８に、入力されたイベント予定データに該当するレコードが存在しないのかを判定する（ステップ１１０２）。 Step 905 is executed when the event scheduled to be held is an event that has not been carried out in the past. Therefore, when the event analysis is started, the data analysis unit 203 inputs the event schedule data input to the genre attribute table 207. It is determined whether there is a record corresponding to the event management data 208 or whether there is a record corresponding to the input event schedule data in the location management table 208 (step 1102).

場所管理テーブル２０８に、入力されたイベント予定データに該当するレコードが存在しない場合、データ分析部２０３は、開催予定のイベントが開催される会場の場所情報を場所管理テーブル２０８に登録し（ステップ１１０６）、処理を終了する。 If there is no record corresponding to the input event schedule data in the location management table 208, the data analysis unit 203 registers the location information of the venue where the scheduled event is held in the location management table 208 (step 1106). ), The process is terminated.

一方、ジャンル属性テーブル２０７に、入力されたイベント予定データに該当するレコードが存在しない場合、データ分析部２０３は、過去に実施されたイベントに関する情報に対して特徴抽出を行い（ステップ１１０３）、ベクトルに変換する。更に、データ分析部２０３は、特徴抽出により得られたベクトルを入力データとして機械学習を行う（ステップ１１０４）。この機械学習に用いる学習アルゴリズムは特に限定されない。ここでは一例として教師あり学習である分類問題が例示される。 On the other hand, when there is no record corresponding to the input event schedule data in the genre attribute table 207, the data analysis unit 203 performs feature extraction on information related to events performed in the past (step 1103), and the vector Convert to Further, the data analysis unit 203 performs machine learning using the vector obtained by the feature extraction as input data (step 1104). The learning algorithm used for this machine learning is not particularly limited. Here, a classification problem that is supervised learning is illustrated as an example.

データ分析部２０３は、分類問題の機械学習において、過去に実施されたイベントの属性を予測する（ステップ１１０５）。そして、イベント予定データと同じジャンルおよび属性のレコードを登録する。 The data analysis unit 203 predicts an attribute of an event performed in the past in the machine learning of the classification problem (step 1105). And the record of the same genre and attribute as event schedule data is registered.

以下、イベントテーブル２０９のレコードの作成例を示す。 Hereinafter, an example of creating a record of the event table 209 will be shown.

図１２Ａは作成例の説明に用いるジャンルテーブル２０６である。図１２Ｂは作成例の説明に用いるジャンル属性テーブル２０７である。図１２Ｃは作成例の説明に用いる場所管理テーブル２０８である。図１３は作成例の説明に用いるイベントテーブル２０９である。 FIG. 12A shows a genre table 206 used for explaining a creation example. FIG. 12B is a genre attribute table 207 used to explain the creation example. FIG. 12C is a location management table 208 used for explaining the creation example. FIG. 13 shows an event table 209 used for explaining a creation example.

イベントテーブル２０９のレコード作成は、図９に示したフローチャートに従って行われる。 The record creation of the event table 209 is performed according to the flowchart shown in FIG.

まず、図１０に示したイベント予定データ入力画面からイベント予定データが入力される。ここで入力されるデータは、イベントの項目１００２が「コンサート―人気歌手」であり、場所の項目１００３が「神奈川県―横浜―ＡＢＣアリーナ」であり、開始日時の項目が「２０１５/１２/２５１８：３０：００」であり、終了日時の項目が「２０１５/１２/２５２１：００：００」である。 First, event schedule data is input from the event schedule data input screen shown in FIG. In the data input here, the event item 1002 is “concert-popular singer”, the place item 1003 is “Kanagawa-Yokohama-ABC arena”, and the start date / time item is “2015/12/25”. 18:30 ”and the end date / time item is“ 2015/12/25 21:00:00 ”.

イベントのジャンル名＝コンサートは、図１２Ａのジャンルテーブル２０６における項目１２０３のジャンルＩＤ＝１に対応する。図１２Ｂのジャンル属性テーブル２０７には、ジャンルＩＤ＝１、イベントの属性名＝人気歌手に紐付く属性ＩＤ＝１、属性観客動員率＝９２％というレコード１２０８が登録されている。イベントの場所名＝ＡＢＣアリーナから、図１２Ｃの場所管理テーブル２０８を参照して、場所ＩＤ＝１および収容人数＝１７０００というレコード１２１２を取得する。 The genre name of the event = concert corresponds to the genre ID = 1 of the item 1203 in the genre table 206 of FIG. 12A. In the genre attribute table 207 of FIG. 12B, a record 1208 is registered with genre ID = 1, event attribute name = attribute ID associated with a popular singer = 1, and attribute audience mobilization rate = 92%. From the event location name = ABC arena, the record 1212 of location ID = 1 and the number of accommodated persons = 17000 is acquired with reference to the location management table 208 of FIG. 12C.

当該イベントのイベント予定データのレコードを登録するときイベントテーブル２０９が空であれば、図１３のレコード１３０９のように、イベントＩＤ＝１を自動的に採番し、そのレコードに割り当てる。以上の手順により、ジャンルＩＤ＝１、属性ＩＤ＝１、場所ＩＤ＝１、開始時間＝２０１５/１２/２５１８：３０：００、終了時間＝２０１５/１２/２５２１：００：００、およびスケーリング時間＝±２をトラフィック＝１７０００×９２％＝１５６４０のイベントのレコード１３０９が登録される。 If the event table 209 is empty when registering the event schedule data record of the event, event ID = 1 is automatically assigned and assigned to the record as shown in the record 1309 in FIG. By the above procedure, genre ID = 1, attribute ID = 1, place ID = 1, start time = 2015/12/25 18:30, end time = 2015/12/25 21:00, and scaling An event record 1309 of time = ± 2 and traffic = 17000 × 92% = 15640 is registered.

図１４は、スケジュール部２０４のシナリオテーブル２１０の一例を示す図である。シナリオテーブル２１０にはスケジュール部２０４にて管理される実行対象のシナリオである。 FIG. 14 is a diagram illustrating an example of the scenario table 210 of the schedule unit 204. The scenario table 210 is a scenario to be executed managed by the schedule unit 204.

図１４を参照すると、シナリオテーブル２１０には、シナリオ名１４０２と、シナリオの識別情報が格納されるシナリオＩＤ１４０１とが含まれる。本実施形態では、ＶＭのスケールイン１４０３とスケールアウト１４０４のみを実施するシナリオが例示されるが、オーケストレーションサーバ１０３が実施可能な他のシナリオをシナリオテーブル２１０に格納してもよい。 Referring to FIG. 14, the scenario table 210 includes a scenario name 1402 and a scenario ID 1401 in which scenario identification information is stored. In this embodiment, a scenario in which only VM scale-in 1403 and scale-out 1404 are executed is illustrated, but other scenarios that can be executed by the orchestration server 103 may be stored in the scenario table 210.

図１５は、スケジュール部２０４のスケジュールテーブル２１１の一例を示す図である。スケジュールテーブル２１１は、ＶＭのオートスケーリングの実施日時、実施範囲、および実施承認有無を管理するテーブルである。スケジュールテーブル２１１のレコード１５０６、１５０７は、スケジュール部２０４により設定される。スケジュールテーブル２１１の１つのレコード１５０６、１５０７がそれぞれ１つのシナリオに対応する。 FIG. 15 is a diagram illustrating an example of the schedule table 211 of the schedule unit 204. The schedule table 211 is a table for managing the execution date and time of VM autoscaling, the execution range, and the presence / absence of execution approval. Records 1506 and 1507 in the schedule table 211 are set by the schedule unit 204. Each record 1506 and 1507 in the schedule table 211 corresponds to one scenario.

実施日時１５０２に示された日時において実施承認状態１５０５が「ＯＫ」であれば、シナリオＩＤ１５０３に示されたシナリオが実施される。また、実施日時１５０２に示された日時において実施承認状態１５０５が「ＮＧ」であれば、シナリオＩＤ１５０３に示されたシナリオの実施を行われない。 If the execution approval status 1505 is “OK” at the date and time indicated by the execution date and time 1502, the scenario indicated by the scenario ID 1503 is executed. If the execution approval status 1505 is “NG” at the date indicated by the execution date 1502, the scenario indicated by the scenario ID 1503 is not executed.

スケジュールテーブル２１１には、スケジュール毎に、その実施するスケジュールを識別するための情報であるスケジュールＩＤ１５０１、スケーリングの実施日時１５０２、実行対象となるシナリオを識別するための情報であるシナリオＩＤ１５０３、スケーリングの実施範囲となるトラフィック１５０４、および当該スケジュールに対するオペレータの承認の有無が格納される実施承認状態１５０５が設定される。 In the schedule table 211, for each schedule, a schedule ID 1501 that is information for identifying a schedule to be executed, a scaling execution date and time 1502, a scenario ID 1503 that is information for identifying a scenario to be executed, and the execution of scaling An execution approval state 1505 is set in which the traffic 1504 as the range and the presence / absence of the operator's approval for the schedule are stored.

図１６は、スケジュール部２０４がスケジュールテーブル２１１にスケーリングのスケジュールを登録する処理のフローチャートである。スケジュール部２０４は、図８に示すイベントテーブル２０９に格納されたイベントデータから、図１５に示すスケジュールテーブル２１１にＶＭのスケーリングを実施するスケジュールを作成する。 FIG. 16 is a flowchart of processing in which the schedule unit 204 registers a scaling schedule in the schedule table 211. The schedule unit 204 creates a schedule for performing VM scaling in the schedule table 211 shown in FIG. 15 from the event data stored in the event table 209 shown in FIG.

スケジュール登録の処理が開始されると（ステップ１６０１）、スケジュール部２０４は、まずスケーリングを実施する時刻と範囲を取得する（ステップ１６０２）。 When the schedule registration process is started (step 1601), the schedule unit 204 first acquires the time and range for performing scaling (step 1602).

その際、スケジュール部２０４は、図８に示したイベントテーブル２０９から、イベントの開催日時８０５、終了日時８０６、スケジューリング時間８０７およびトラフィック８０８を取得する。 At that time, the schedule unit 204 obtains the event date / time 805, the end date / time 806, the scheduling time 807, and the traffic 808 from the event table 209 shown in FIG.

イベントの開始に合わせてスケールアウトを行い、イベントの終了に合わせてスケールインを行うので、スケールアウトの実施日時がスケールインの実施日時よりも時間的に前となる。イベントの開催日時８０５からスケジューリング時間８０７だけ遡った時刻がスケールアウトの実施時刻となる。イベントの終了日時８０６にスケジューリング時間８０７を加えた時刻がスケールインの実施時刻となる。 Since the scale-out is performed at the start of the event and the scale-in is performed at the end of the event, the scale-out implementation date is before the scale-in implementation date. The time that goes back by the scheduling time 807 from the event date and time 805 is the scale-out execution time. The time obtained by adding the scheduling time 807 to the event end date and time 806 is the scale-in implementation time.

スケジュール部２０４は、イベントの開催日時８０５からスケジューリング時間８０７を減算し、スケールアウトの実施時刻を算出する。スケジュール部２０４は、また、イベントの終了日時８０６にスケジューリング時間８０７を加算し、スケールインの実施時刻を算出する。また、スケジュール部２０４は、取得したトラフィックをスケーリングを実施する範囲（増減するＶＭの個数）とする。 The schedule unit 204 subtracts the scheduling time 807 from the event date and time 805 to calculate the scale-out execution time. The schedule unit 204 also adds the scheduling time 807 to the event end date and time 806 to calculate the scale-in execution time. Further, the schedule unit 204 sets the acquired traffic as a range for performing scaling (the number of VMs to be increased or decreased).

次に、スケジュール部２０４はスケジュールを作成する（ステップ１６０３）。その際、スケジュール部２０４は、ＶＭのスケールアウトとＶＭスケールインの各スケジュールを作成する。 Next, the schedule unit 204 creates a schedule (step 1603). At that time, the schedule unit 204 creates schedules for VM scale-out and VM scale-in.

ＶＭのスケールアウトに関するスケジュールを作成するとき、スケジュール部２０４は、まずスケジュールＩＤを自動的に採番する。次に、スケジュール部２０４は、ステップ１６０２にて算出した時刻を実施時刻に設定する。更に、スケジュール部２０４は、シナリオテーブル２１０に設定されたスケールアウトのシナリオＩＤを、スケールアウトのシナリオＩＤとして設定する。 When creating a schedule related to VM scale-out, the schedule unit 204 first automatically assigns a schedule ID. Next, the schedule unit 204 sets the time calculated in step 1602 as the execution time. Further, the schedule unit 204 sets the scale-out scenario ID set in the scenario table 210 as the scale-out scenario ID.

更に、スケジュール部２０４は、スケールアウトのスケジュールにおいて、ステップ１６０２で取得したトラフィックに、スケールアウトを示す記号「＋」を加える。スケジュール部２０４は、
実施承認状態については、スケジュール部２０４は、新たにスケジュールを登録するときのデフォルト初期値として「ＮＧ」を設定する。 Furthermore, the schedule unit 204 adds a symbol “+” indicating scale-out to the traffic acquired in step 1602 in the scale-out schedule. The schedule unit 204
For the execution approval state, the schedule unit 204 sets “NG” as a default initial value when a new schedule is registered.

ＶＭのスケールインに関するスケジュールを作成するとき、スケジュール部２０４は、まずスケールアウトのスケジュールを作成するときと同様にスケジュールＩＤを自動的に採番する。次に、スケジュール部２０４は、ステップ１６０２にて算出した時刻を実施時刻に設定する。更に、スケジュール部２０４は、シナリオテーブル２１０に設定されたスケールインのシナリオＩＤを、スケールインのシナリオＩＤとして設定する。 When creating a schedule related to VM scale-in, the schedule unit 204 automatically assigns a schedule ID in the same manner as when creating a scale-out schedule. Next, the schedule unit 204 sets the time calculated in step 1602 as the execution time. Further, the schedule unit 204 sets the scale-in scenario ID set in the scenario table 210 as the scale-in scenario ID.

更に、スケジュール部２０４は、スケールインのスケジュールにおいて、ステップ１６０２で取得したトラフィックに、スケールインインを示す記号「−」を加える。実施承認状態についても、スケジュール部２０４は、スケールアウトのときと同様にデフォルト触知として「ＮＧ」を設定する。 Further, the schedule unit 204 adds a symbol “-” indicating the scale-in in the traffic acquired in step 1602 in the scale-in schedule. Regarding the execution approval state, the schedule unit 204 sets “NG” as the default tactile in the same manner as the scale-out.

次に、スケジュール部２０４は、作成したスケジュールのレコードをスケジュールテーブル２１１に格納する（ステップ１６０４）。 Next, the schedule unit 204 stores the created schedule record in the schedule table 211 (step 1604).

なお、スケジュール部２０４は、登録したスケジュールをＭＧＭＴＳＷ１０２経由でクライアント１０１に送信する。クライアントでは登録されたスケジュールが画面に表示される。当該実施日時になる前にオペレータがそのスケジュールの実施を承認すると、実施承認状態が「ＮＧ」から「ＯＫ」に変わる。その状態で実施日時になると、ＶＭ生成部２０５がシナリオを実行する。また、オペレータがそのスケジュールの実施を承認しなかったら、あるいはそのスケジュールを削除したら、その実施日時になってもＶＭ生成部２０５はシナリオを実行しない。 Note that the schedule unit 204 transmits the registered schedule to the client 101 via the MGMTSW 102. The registered schedule is displayed on the client screen. If the operator approves the execution of the schedule before the execution date and time, the execution approval status changes from “NG” to “OK”. When the execution date / time is reached in this state, the VM generation unit 205 executes the scenario. If the operator does not approve the execution of the schedule or deletes the schedule, the VM generation unit 205 does not execute the scenario even when the execution date / time is reached.

図１７Ａは、イベントテーブル２０９の一例を示す図である。図１７Ｂは、シナリオテーブル２１０の一例を示す図である。図１７Ｃは、スケジュールテーブル２１１の一例を示す図である。 FIG. 17A is a diagram illustrating an example of the event table 209. FIG. 17B is a diagram illustrating an example of the scenario table 210. FIG. 17C is a diagram illustrating an example of the schedule table 211.

以下、図１７Ａ〜１７Ｃを用いて、イベント予定データに基づいて、ＶＭのスケーリングを実施するためのスケジュールを作成する例について説明する。 Hereinafter, an example of creating a schedule for performing VM scaling based on the event schedule data will be described with reference to FIGS. 17A to 17C.

ここで、図１７Ａのイベントテーブル２０９におけるイベントＩＤ＝１のレコード１７０９に対するスケジュールを作成する。図１７Ａを参照すると、イベントＩＤ＝１のイベントは、開始日時＝２０１５/１２/２５１８：３０：００であり、終了日時＝２０１５/１２/２５２１：００：００であり、スケジューリング時間＝±２であり、トラフィック＝１５６４０である。このイベントの間はトラフィックが増大するので、まずＶＭのスケールアウトを実行し、次にＶＭのスケールインを実行するようなスケジュールが作成される。 Here, a schedule is created for the record 1709 with event ID = 1 in the event table 209 of FIG. 17A. Referring to FIG. 17A, the event with event ID = 1 has a start date / time = 2015/12/25 18:30, an end date / time = 2015/12/25 21:00, and a scheduling time = ± 2 and traffic = 15640. Because traffic increases during this event, a schedule is created that first performs a VM scale-out and then a VM scale-in.

ＶＭのスケールアウトのスケジュールは、スケジュールテーブル２１１に示すように、シナリオＩＤ＝２であり、実施日時＝２０１５/１２/２５１６：３０：００であり、実施範囲はトラフィック＝＋１５６４０であり、実施承認状態は初期値＝ＮＧである。シナリオＩＤ＝２はシナリオテーブル２１０のレコード１７１３から取得される。実施日時は開始日時から２時間を減算した実施日時＝２０１５/１２/２５１６：３０：００とされる。また、ここで仮に登録前のスケジュールテーブル２１１が空であったと想定すると、図１７Ｃに示すようにスケジュールＩＤ＝１となる。 As shown in the schedule table 211, the scale-out schedule of the VM is scenario ID = 2, implementation date / time = 2015/12/25 16:30, and the implementation range is traffic = + 15640, which is approved for implementation. The state is initial value = NG. Scenario ID = 2 is acquired from the record 1713 of the scenario table 210. The implementation date and time is calculated by subtracting 2 hours from the start date and time = 2015/12/25 16:30. Also, assuming that the pre-registration schedule table 211 is empty, the schedule ID = 1 as shown in FIG. 17C.

同様に、ＶＭスケールインのスケジュールは、図１７Ｃのレコード１７２０に示すように、スケジュールＩＤ＝２であり、実施日時＝２０１５/１２/２５２３：００：００であり、シナリオＩＤ＝１であり、トラフィック＝−１５６４０であり、実施承認状態の初期値＝ＮＧである。 Similarly, as shown in the record 1720 in FIG. 17C, the schedule of VM scale-in is schedule ID = 2, implementation date / time = 2015/12/25 23: 00: 00: 00, scenario ID = 1, Traffic = -15640, and the initial value of the execution approval state = NG.

レコード１７１９のスケールアウトは、スケールアウトの実施日時である２０１５/１２/２５１６：３０：００の時点で実施承認状態が「ＯＫ」となっていれば、＋１５６４０トラフィック量のＶＭスケールアウトが自動的に実施される。また、レコード１７２０のスケールインは、スケールインの実施日時である２０１５/１２/２５２３：００：００の時点で実施承認状態が「ＯＫ」となっていれば、−１５６４０のトラフィック量のＶＭスケールインが自動的に実施される。 If scale 17 of record 1719 is “OK” at the time of scale out implementation date 2015/12/25 16:30, VM scale out of +15640 traffic volume is automatically To be implemented. In addition, the scale-in of the record 1720 indicates that the VM scale of the traffic amount of -15640 if the execution approval state is “OK” at the time of 2015/12/25 23:00:00, which is the date and time of the scale-in. In automatically.

図１８は、ＶＭ生成部２０５がＶＭの使用状態を管理するためのＶＭ管理テーブル２１２の一例を示す図である。ＶＭ管理テーブル２１２は、ＶＭ毎に、ＶＭの識別情報が格納されるＶＭＩＤ１８０１、現時点での各ＶＭが使用されるトラフィックが格納される使用率１８０２、および各ＶＭが収容できるトラフィックの最大の接続数が格納されるトラフィック収容力１８０３を記憶する。 FIG. 18 is a diagram illustrating an example of the VM management table 212 for the VM generation unit 205 to manage the usage state of the VM. The VM management table 212 includes, for each VM, a VM ID 1801 in which VM identification information is stored, a usage rate 1802 in which traffic currently used by each VM is stored, and a maximum connection of traffic that can be accommodated by each VM The traffic capacity 1803 in which the number is stored is stored.

ＶＭを新たに登録するとき、ＶＭ管理テーブル２１２にはレコードが生成され、ＶＭを削除するとき、ＶＭ管理テーブル２１２からレコードが削除される。また、使用率１８０２は、周期的にＶＭからリアルタイムで取得した値が反映される。 When newly registering a VM, a record is generated in the VM management table 212, and when deleting a VM, the record is deleted from the VM management table 212. The usage rate 1802 reflects a value periodically acquired in real time from the VM.

イベントテーブル２０９の当該イベントに関する、スケジュールテーブル２１１に記載されたスケーリングを実施している間、この使用率の最大値を計測し、スケーリングの実施後に、その最大値をイベントテーブル２０９の当該イベントのレコードのトラフィック１７０８に反映することにしてもよい。 While performing the scaling described in the schedule table 211 regarding the event in the event table 209, the maximum value of this usage rate is measured, and after the scaling is performed, the maximum value is recorded in the event table 209 record of the event. May be reflected in the traffic 1708.

図１９はＶＭ生成部２０５がＶＭのスケールアウトを実施する処理を示すフローチャートである。 FIG. 19 is a flowchart illustrating processing in which the VM generation unit 205 performs VM scale-out.

ステップ１９０１にてＶＭのスケールアウトのスケジュールの実施日時に実施承認状態がＯＫであれば、ＶＭ生成部２０５は、ＶＭのスケールアウトを開始する（ステップ１９０３）。一方、ＶＭのスケールアウトのスケジュールの実施時期に実施承認状態がＯＫでなければ、ＶＭ生成部２０５は、そのスケジュールを破棄する（ステップ１９０２）。 If the execution approval status is OK at the execution date and time of the VM scale-out schedule in step 1901, the VM generation unit 205 starts VM scale-out (step 1903). On the other hand, if the execution approval state is not OK at the execution time of the VM scale-out schedule, the VM generation unit 205 discards the schedule (step 1902).

スケールアウトを開始したＶＭ生成部２０５は、ＶＭ管理テーブル２１２にて管理されているトラフィック収容力およびリアルタイムの使用率を参照することによりＶＭの収容能力を確認し（ステップ１９０４）、スケールアウトを実施するのに十分な収容能力がある場合、ＶＭを生成する（ステップ１９０５）。 The VM generation unit 205 that started the scale-out confirms the capacity of the VM by referring to the traffic capacity and the real-time usage rate managed in the VM management table 212 (step 1904), and performs the scale-out. If there is sufficient capacity to do this, a VM is generated (step 1905).

ステップ１９０４にてスケールアウトを実施するのに十分な収容能力が無い場合、ＶＭ生成部２０５は、ＶＭの収容能力を増強した後（ステップ１９０６）、ＶＭを生成する（ステップ１９０５）。ＶＭの収容能力の増強は例えば削除可能なＶＭを削除することにより行えばよい。ステップ１９０５では、ＶＭ生成部２０５は、スケジュールテーブル２１１に記載されているトラフィック１５０４に応じた収容能力を確保するようにＶＭを生成する。 If there is not enough capacity to perform scale-out in step 1904, the VM generation unit 205 increases the capacity of the VM (step 1906) and then generates a VM (step 1905). For example, the capacity of a VM may be increased by deleting a VM that can be deleted. In step 1905, the VM generation unit 205 generates a VM so as to ensure the capacity according to the traffic 1504 described in the schedule table 211.

更に、ＶＭ生成部２０５はＶＭをロードバランスする（ステップ１９０７）。ステップ１９０７では、ＶＭ生成部２０５は、ＶＭ管理テーブル２１２に格納されている各ＶＭの使用率１８０２を参照し、各ＶＭの負荷が閾値を超えないように、ロードバランスを実施する。 Further, the VM generation unit 205 performs load balancing of the VM (step 1907). In step 1907, the VM generation unit 205 refers to the usage rate 1802 of each VM stored in the VM management table 212, and performs load balancing so that the load of each VM does not exceed the threshold value.

図２０はＶＭ生成部２０５がＶＭのスケールインを実施する処理を示すフローチャートである。 FIG. 20 is a flowchart illustrating processing in which the VM generation unit 205 performs VM scale-in.

ステップ２００１にてＶＭのスケールインのスケジュールの実施日時に実施承認状態がＯＫであれば、ＶＭ生成部２０５は、ＶＭのスケールインを開始する（ステップ２００３）。一方、ＶＭのスケールアウトのスケジュールの実施時期に実施承認状態がＯＫでなければ、ＶＭ生成部２０５は、そのスケジュールを破棄する（ステップ２００２）。 If the execution approval state is OK at the execution date and time of the VM scale-in schedule in step 2001, the VM generation unit 205 starts the VM scale-in (step 2003). On the other hand, if the execution approval state is not OK at the execution time of the VM scale-out schedule, the VM generation unit 205 discards the schedule (step 2002).

スケールインを開始したＶＭ生成部２０５は、スケジュールテーブル２１１に記載されているトラフィック１５０４に相当するＶＭの使用を停止させる（ステップ２００４）。次に、ＶＭ生成部２０５は、使用を停止したＶＭをシャットダウンする（ステップ２００５）。次に、ＶＭ生成部２０５は、シャットダウンしたＶＭをＶＭ管理テーブル２１２から削除する（ステップ２００６）。 The VM generation unit 205 that has started the scale-in stops the use of the VM corresponding to the traffic 1504 described in the schedule table 211 (step 2004). Next, the VM generation unit 205 shuts down the VM that has been stopped being used (step 2005). Next, the VM generation unit 205 deletes the shut down VM from the VM management table 212 (Step 2006).

図２１Ａ、図２１Ｂは、ＶＭ管理テーブル２１２に管理されているＶＭのスケールアップによる変化の一例について説明するための図である。図２１Ａはスケールアウトの前のＶＭの使用状態であり、図２１Ｂはスケールアウト後のＶＭの使用状態である。 FIG. 21A and FIG. 21B are diagrams for explaining an example of a change caused by scaling up a VM managed in the VM management table 212. FIG. 21A shows the usage state of the VM before the scale-out, and FIG. 21B shows the usage state of the VM after the scale-out.

図１９に示したフローチャートにおいて、ＶＭ生成部２０５は、ＶＭを追加するのに十分な収容能力があれば（ステップ１９０４のＹＥＳ）、スケジュールテーブル２１１に記載されているトラフィック１７１８の＋１５６４０と、１つのＶＭのトラフィック収容力が１００００であることを確認し、増加した１５６４０のトラフィック量を収容できるように２つのＶＭを生成する。そして、ＶＭ生成部２０５は、ＶＭ管理テーブル２１２にＶＭＩＤ＝３のレコード２１１１とＶＭＩＤ＝４のレコード２１１２を新たに登録する。 In the flowchart illustrated in FIG. 19, if the VM generation unit 205 has sufficient capacity to add a VM (YES in Step 1904), +15640 of the traffic 1718 described in the schedule table 211 and one It is confirmed that the traffic capacity of the VM is 10,000, and two VMs are generated so that the increased amount of traffic of 15640 can be accommodated. Then, the VM generation unit 205 newly registers a record 2111 with VM ID = 3 and a record 2112 with VM ID = 4 in the VM management table 212.

各ＶＭにかかる負荷の閾値として、トラフィック収容力の８０％が設定されている場合、元から動作していた２つのＶＭと新たに追加された２つのＶＭの合計４つのＶＭについてロードバランスが行われる。ここでは一例として、ＶＭＩＤ＝1のＶＭは使用率＝６０％（図２１Ａのレコード２１０４）から使用率＝８０％（図２１Ｂのレコード２１０９）へ変更される。また、ＶＭＩＤ＝２のＶＭも使用率＝６０％（図２１Ａのレコード２１０５）から使用率＝８０％（図２１Ｂのレコード２１１０）へ変更される。また、新たに生成されたＶＭＩＤ＝３のＶＭ（図２１Ｂのレコード２１１１）とＶＭＩＤ＝４のＶＭ（図２１Ｂのレコード２１１２）は使用率＝６０％とされる。 If 80% of the traffic capacity is set as the load threshold for each VM, load balancing is performed for a total of four VMs: two VMs that were originally operating and two newly added VMs. Is called. Here, as an example, the VM with VM ID = 1 is changed from usage rate = 60% (record 2104 in FIG. 21A) to usage rate = 80% (record 2109 in FIG. 21B). The VM with VM ID = 2 is also changed from usage rate = 60% (record 2105 in FIG. 21A) to usage rate = 80% (record 2110 in FIG. 21B). Further, the newly generated VM with VM ID = 3 (record 2111 in FIG. 21B) and VM with VM ID = 4 (record 2112 in FIG. 21B) have a usage rate of 60%.

ＶＭ生成部２０５が管理しているＶＭのトラフィック収容量の合計は１２０００（１００００×６０％＋１００００×６０％）から２８０００（１００００×８０％×２＋１００００×６０％×２）に増量され、レコード１７１９にあるスケールアウトのトラフィック＋１５６４０が収容可能となる。 The total traffic capacity of the VMs managed by the VM generation unit 205 is increased from 12000 (10000 × 60% + 10000 × 60%) to 28000 (10000 × 80% × 2 + 10000 × 60% × 2), and the record 1719 A certain scale-out traffic +15640 can be accommodated.

図２２Ａ、図２２Ｂは、オートスケーリングにおいて、オペレータが操作するクライアント１０１の画面表示を示す図である。 22A and 22B are diagrams showing screen displays of the client 101 operated by the operator in auto scaling.

図２２Ａには、各スケジュールについて実施承認の操作が可能なスケジュール一覧画面が示されている。図１９に示されたスケールアウトの処理を実施するために、オペレータは、図２２Ａに示されたスケジュール一覧画面より、スケールアウトの実施を承認する操作を行う。具体的には、オペレータはスケールアウトの実施承認の「ＯＫ」ボタンを押下する。 FIG. 22A shows a schedule list screen on which an operation of approval for each schedule can be performed. In order to implement the scale-out process shown in FIG. 19, the operator performs an operation of approving the implementation of scale-out from the schedule list screen shown in FIG. 22A. Specifically, the operator presses an “OK” button for approval of scale-out execution.

実施承認状態が「ＯＫ」になり、その状態でスケールアウトの実施日時である１６：３０になると、図２２Ｂに示すＶＭビュー画面に、各ＶＭの登録状態が表示される。図２２Ｂには、もともと登録されているＶＭＩＤ＝１のＶＭとＶＭＩＤ＝２のＶＭは実線の円で表示される。また、生成中のＶＭＩＤ＝３のＶＭとＶＭＩＤ＝４のＶＭは破線の円で表示される。 When the execution approval state becomes “OK” and the scale-out execution date and time becomes 16:30 in that state, the registration state of each VM is displayed on the VM view screen shown in FIG. 22B. In FIG. 22B, the VM with originally registered VM ID = 1 and the VM with VM ID = 2 are displayed with solid circles. In addition, the VM with VM ID = 3 and the VM with VM ID = 4 being generated are displayed as a broken-line circle.

図２３Ａ、図２３Ｂは、ＶＭ管理テーブル２１２に管理されているＶＭのスケールインによる変化の一例について説明するための図である。図２３Ａはスケールインの前のＶＭの使用状態であり、図２３Ｂはスケールイン後のＶＭの使用状態である。 FIG. 23A and FIG. 23B are diagrams for explaining an example of changes caused by scale-in of VMs managed in the VM management table 212. FIG. FIG. 23A shows the usage state of the VM before the scale-in, and FIG. 23B shows the usage state of the VM after the scale-in.

図２０に示したフローチャートにおいて、ＶＭ生成部２０５は、図１９に示したスケールアウトの処理で生成したＶＭＩＤ＝３のＶＭ（図２３Ａのレコード２３０６）とＶＭＩＤ＝４のＶＭ（図２３Ａのレコード２３０７）の使用を停止し、それらのＶＭをシャットダウンし、削除する。さらに、ＶＭのオートスケーリングにより、ＶＭＩＤ＝１のＶＭと、ＶＭＩＤ＝２のＶＭの使用率は、実際のトラフィック量に応じてスケールアウト前の状態に戻る。 In the flowchart shown in FIG. 20, the VM generation unit 205 generates a VM with VM ID = 3 (record 2306 in FIG. 23A) generated by the scale-out process shown in FIG. 19 and a VM with VM ID = 4 (in FIG. 23A). Stop using record 2307) and shut down and delete those VMs. Further, the VM autoscaling causes the VM ID = 1 VM usage rate and the VM ID = 2 VM usage rate to return to the state before the scale-out according to the actual traffic volume.

その結果、ＶＭ生成部２０５が管理しているＶＭのトラフィック収容量の合計は２８０００（１００００×８０％×２＋１００００×６０％×２）から１２０００（１００００×６０％＋１００００×６０％）に戻り、レコード１７２０にあるスケールインのトラフィック−１５６４０が実現される。 As a result, the total traffic capacity of the VMs managed by the VM generation unit 205 returns from 28000 (10000 × 80% × 2 + 10000 × 60% × 2) to 12000 (10000 × 60% + 10000 × 60%), and the record 1720 scale-in traffic-15640 is realized.

図２４Ａ、図２５Ｂは、オートスケーリングにおいて、オペレータが操作するクライアント１０１の画面表示を示す図である。 24A and 25B are diagrams showing screen displays of the client 101 operated by the operator in auto scaling.

図２４Ａには、未実施のスケジュールすなわちスケールインについて実施承認の操作が可能なスケジュール一覧画面が示されている。図２０に示されたスケールインの処理を実施するために、オペレータは、図２４Ａに示されたスケジュール一覧画面より、スケールインの実施を承認する操作を行う。具体的には、オペレータはスケールインの実施承認の「ＯＫ」ボタンを押下する。 FIG. 24A shows a schedule list screen on which an operation for approval of an unexecuted schedule, that is, scale-in, can be performed. In order to implement the scale-in process shown in FIG. 20, the operator performs an operation of approving the implementation of scale-in from the schedule list screen shown in FIG. 24A. Specifically, the operator presses an “OK” button for approval of scale-in execution.

実施承認状態が「ＯＫ」になり、その状態でスケールインの実施日時である２３：００になると、図２４Ｂに示すＶＭビュー画面に、各ＶＭの登録状態が表示される。図２４Ｂには、登録が維持されるＶＭＩＤ＝１のＶＭとＶＭＩＤ＝２のＶＭは実線の円で表示される。また、削除中のＶＭＩＤ＝３のＶＭとＶＭＩＤ＝４のＶＭは破線の円で表示される。 When the execution approval state becomes “OK” and the scale-in execution date and time becomes 23:00 in that state, the registration state of each VM is displayed on the VM view screen shown in FIG. 24B. In FIG. 24B, the VMs with the VM ID = 1 and the VMs with the VM ID = 2 that are maintained are displayed as solid circles. In addition, the VM with VM ID = 3 and the VM with VM ID = 4 being deleted are displayed as broken-line circles.

以上説明した本実施形態の構成および動作を整理すると以下のように説明することができる。 The configuration and operation of the present embodiment described above can be summarized as follows.

本実施形態のオーケストレーションサーバ１０３は、仮想マシンにより処理を行う仮想ネットワークのスケーリングを行うサーバ装置であり、データ分析部２０３と、スケジュール部２０４と、仮想マシン生成部２０５と、を有する。 The orchestration server 103 of this embodiment is a server device that performs scaling of a virtual network that performs processing by a virtual machine, and includes a data analysis unit 203, a schedule unit 204, and a virtual machine generation unit 205.

データ分析部２０３は、イベントの開催予定に関する情報を含むイベント予定データに基づいて、イベントに起因して発生する処理負荷の発生時間および負荷量に関する情報を含むイベント負荷データを作成する。スケジュール部２０４は、イベント負荷データに基づいて、イベントに起因して発生する処理負荷に応じてスケールアウトおよびスケールインを実施するためのスケーリング実施スケジュールを作成する。仮想マシン生成部２０５は、スケーリング実施スケジュールに従ってスケールアウトおよびスケールインを実施する。 The data analysis unit 203 creates event load data including information on the generation time and load amount of the processing load generated due to the event based on the event schedule data including information on the event schedule. The schedule unit 204 creates a scaling execution schedule for performing scale-out and scale-in according to the processing load generated due to the event, based on the event load data. The virtual machine generation unit 205 performs scale-out and scale-in according to the scaling execution schedule.

これによれば、イベントの開催予定に基づいたスケジュールに従ってスケーリングを実施するので、過去に経験のないイベントに適切に対応可能なオートスケーリングが実現できる。 According to this, since the scaling is performed according to the schedule based on the event schedule, it is possible to realize auto-scaling that can appropriately deal with events that have not been experienced in the past.

また、イベント予定データは、イベントの開催場所と、開始日時と、集まる人の数に関連する人的規模関連情報とをイベントデータ要素として含み、データ分析部２０３は、過去に実施されたイベントに関する情報に基づいて、イベントのイベントデータ要素と、イベントに起因して発生した処理負荷の負荷量との対応関係を予め算出してイベント開催データとして保持しておき、イベント予定データからイベントデータ要素を抽出し、抽出したイベントデータ要素に相当するイベントデータ要素を含むイベント開催データに基づいてイベント負荷データを作成する。 The event schedule data includes event location, start date and time, and human scale related information related to the number of people gathered as event data elements, and the data analysis unit 203 relates to events performed in the past. Based on the information, the correspondence between the event data element of the event and the load amount of the processing load caused by the event is calculated in advance and held as event holding data, and the event data element is determined from the event schedule data. Event load data is created based on event data that is extracted and includes event data elements corresponding to the extracted event data elements.

これによれば、過去のイベントに関する、開催場所、開始時刻、および人的規模関連情報とイベントに起因して発生する処理負荷の負荷量との対応関係を予め算出しておき、開催予定のイベントに相当するイベント開催データに基づいてイベント負荷データを作成するので、過去の実績を基にイベントに起因する処理負荷を正確に予測することが可能である。 According to this, the correspondence between the event location, start time, and human scale related information related to the past event and the amount of processing load caused by the event is calculated in advance, and the event scheduled to be held Since event load data is created based on event holding data corresponding to the above, it is possible to accurately predict the processing load caused by an event based on past results.

また、イベント予定データは、更に、イベントのジャンル、属性、および終了時刻をイベントデータ要素として含む。 The event schedule data further includes the event genre, attributes, and end time as event data elements.

これによれば、ジャンル、属性、開催場所、開始時刻、終了時刻、および人的規模関連情報で、開催予定のイベントに相当するイベント開催データを決定するので、より多くの情報を用いて、過去の実績を基にイベントに起因する処理負荷を正確に予測することが可能である。 According to this, since the event holding data corresponding to the event scheduled to be held is determined based on the genre, the attribute, the holding place, the start time, the end time, and the human scale related information, more information is used to It is possible to accurately predict the processing load due to the event based on the actual results of the above.

また、データ分析部２０３は、イベント予定データに対応するイベント開催データが存在すればそのイベント開催データに基づいてイベント負荷データを作成し、イベント予定データに対応するイベント開催データが存在しなければ、過去に実施されたイベントに関する情報に基づく学習で、イベント予定データに対応するイベント開催データを作成する。 Further, the data analysis unit 203 creates event load data based on the event holding data if there is event holding data corresponding to the event schedule data, and if the event holding data corresponding to the event schedule data does not exist, Event holding data corresponding to the event schedule data is created by learning based on information on events performed in the past.

学習によりイベント開催データを追加して、処理負荷を予測する精度を向上させることができる。 By adding event holding data through learning, the accuracy of predicting the processing load can be improved.

また、スケジュール部２０４は、イベントに起因する処理負荷の発生に合わせてスケールアウトを実施し、処理負荷の終了に合わせてスケールインを実施するようにスケーリング実施スケジュールを作成する。 Further, the schedule unit 204 creates a scaling execution schedule so that scale-out is performed in accordance with the occurrence of a processing load caused by an event, and scale-in is performed in accordance with the end of the processing load.

これにより、イベントに起因する処理負荷が発生する期間、その処理負荷の処理にリソースを割り当てるので、イベントに起因する処理負荷を適切に処理することが可能となる。 Thereby, during the period when the processing load due to the event occurs, resources are allocated to the processing of the processing load, so that the processing load due to the event can be appropriately processed.

また、スケジュール部２０４は、イベントの開始日時の所定時間前にスケールアウトを実施し、処理負荷の終了時刻の所定時間後にスケールインを実施するようにスケーリング実施スケジュールを作成する。ここでいう所定時間は、上述したスケジューリング時間８０７である。 In addition, the schedule unit 204 creates a scaling execution schedule so that the scale-out is performed a predetermined time before the start date and time of the event and the scale-in is performed after a predetermined time after the end time of the processing load. The predetermined time here is the scheduling time 807 described above.

これによれば、イベントに起因する処理負荷がイベントの開始前から始まり、イベントの終了後まで続く場合にも、イベントに起因する処理負荷を適切に処理することが可能となる。 According to this, even when the processing load due to the event starts before the start of the event and continues until after the end of the event, the processing load due to the event can be appropriately processed.

また、仮想マシン生成部２０５は、オペレータの操作に応じて、スケールアウトおよびスケールインを実施するか否かを選択する。 In addition, the virtual machine generation unit 205 selects whether or not to perform scale-out and scale-in according to the operation of the operator.

これによれば、オーケストレーションサーバ１０３が自動的に生成したスケジュールをオペレータが実施前に確認するので、安全性を向上することができる。 According to this, since the operator confirms the schedule automatically generated by the orchestration server 103 before implementation, safety can be improved.

また、データ分析部２０３は、イベントに起因する処理負荷が発生している間の複数の範囲のそれぞれを対象とする仮想ノードの使用率の最大値を取得し、それ以降に、イベントに用いたものと同じイベント開催データを用いてスケーリングを実施するとき、その最大値が大きかった範囲を優先して仮想ノードを作成するように、スケーリングを実施する範囲を決定する。 In addition, the data analysis unit 203 acquires the maximum value of the usage rate of the virtual node for each of a plurality of ranges while the processing load caused by the event is generated, and thereafter used for the event When scaling is performed using the same event holding data, the range in which scaling is performed is determined so as to create a virtual node with priority given to the range in which the maximum value is large.

これによれば、各範囲について仮想ノードの使用率の最大値から、大きな処理負荷が生じている範囲に対して仮想ノードを追加作成するので、適切な範囲に対して効率よく仮想ノードを作成することができる。 According to this, since a virtual node is additionally created for a range where a large processing load occurs from the maximum value of the virtual node usage rate for each range, a virtual node is efficiently created for an appropriate range. be able to.

上述した本発明の実施形態は、本発明の説明のための例示であり、本発明の範囲をそれらの実施形態にのみ限定する趣旨ではない。当業者は、本発明の要旨を逸脱することなしに、他の様々な態様で本発明を実施することができる。 The above-described embodiments of the present invention are examples for explaining the present invention, and are not intended to limit the scope of the present invention only to those embodiments. Those skilled in the art can implement the present invention in various other modes without departing from the gist of the present invention.

１００２…イベント、１００３…場所名、１００６…スケジュール登録ボタン、１０１…クライアント、１０２…ＭＧＭＴＳＷ、１０３…オーケストレーションサーバ、１０４…クラウド管理サーバ、１０５…サービスＳＷ、１０６…Ｃｏｍｐｕｔｅサーバ、１３０９…レコード、１４０１…シナリオＩＤ、１４０２…シナリオ名、１４０３…スケールイン、１４０４…スケールアウト、１５０１…スケジュールＩＤ、１５０２…実施日時、１５０３…シナリオＩＤ、１５０４…トラフィック、１５０５…実施承認状態、１５０６…レコード、１７０８…トラフィック、１７０９…レコード、１７１３…レコード、１７１９…レコード、１７２０…レコード、１８０２…使用率、１８０３…トラフィック収容力、２０１…ＣＰＵ、２０２…メモリ、２０３…データ分析部、２０４…スケジュール部、２０５…ＶＭ生成部、２０６…ジャンルテーブル、２０７…ジャンル属性テーブル、２０８…場所管理テーブル、２０９…イベントテーブル、２１０…シナリオテーブル、２１１…スケジュールテーブル、２１２…ＶＭ管理テーブル、３０１…ＣＰＵ、３０２…メモリ、３０３…Ｃｏｍｐｕｔｅ管理プログラム、３０４…Ｎｅｔｗｏｒｋ管理プログラム、３０５…Ｃｏｍｐｕｔｅ管理テーブル、３０６…Ｎｅｔｗｏｒｋ管理テーブル、４０１…ＣＰＵ、４０２…メモリ、４０３…クラウド管理エージェント、４０４…Ｈｙｐｅｒｖｉｓｏｒ、４０５…ＶＭ管理テーブル、４０６…ＶＭイメージ、４０７…ディスク装置、５０１…ジャンルＩＤ、５０２…ジャンル名、６０１…ジャンルＩＤ、６０２…属性ＩＤ、６０３…属性名、６０４…観客動員率、７０１…場所ＩＤ、７０２…場所名、７０３…収容人数、８０１…イベントＩＤ、８０２…ジャンルＩＤ、８０３…属性ＩＤ、８０４…場所ＩＤ、８０５…開催日時、８０６…終了日時、８０７…スケジューリング時間、８０８…トラフィック 1002 ... Event, 1003 ... Location name, 1006 ... Schedule registration button, 101 ... Client, 102 ... MGMTSW, 103 ... Orchestration server, 104 ... Cloud management server, 105 ... Service SW, 106 ... Compute server, 1309 ... Record, 1401 ... Scenario ID, 1402 ... Scenario name, 1403 ... Scale in, 1404 ... Scale out, 1501 ... Schedule ID, 1502 ... Execution date and time, 1503 ... Scenario ID, 1504 ... Traffic, 1505 ... Execution approval status, 1506 ... Record, 1708 ... Traffic, 1709 ... record, 1713 ... record, 1719 ... record, 1720 ... record, 1802 ... usage rate, 1803 ... traffic capacity, 201 ... CPU, 202 ... memory 203 ... Data analysis unit 204 ... Schedule unit 205 ... VM generation unit 206 ... Genre table 207 ... Genre attribute table 208 ... Location management table 209 ... Event table 210 ... Scenario table 211 ... Schedule table 212 ... VM management table 301 ... CPU 302 ... Memory 303 ... Compute management program 304 ... Network management program 305 ... Compute management table 306 ... Network management table 401 ... CPU 402 ... Memory 403 ... Cloud Management agent 404 ... Hypervisor 405 ... VM management table 406 ... VM image 407 ... Disk device 501 ... Genre ID 502 ... Genre name 601 ... Genre D, 602 ... attribute ID, 603 ... attribute name, 604 ... audience mobilization rate, 701 ... place ID, 702 ... place name, 703 ... capacity, 801 ... event ID, 802 ... genre ID, 803 ... attribute ID, 804 ... Location ID, 805 ... Date / time, 806 ... End date / time, 807 ... Scheduling time, 808 ... Traffic

Claims

An orchestration server that scales a virtual network for processing by a virtual machine,
A data analysis unit for creating event load data including information on an occurrence time and a load amount of a processing load caused by the event based on event schedule data including information on an event schedule; and
Based on the event load data, a schedule unit that creates a scaling execution schedule for performing scale-out and scale-in according to the processing load generated due to the event;
A virtual machine generation unit that performs the scale-out and the scale-in according to the scaling execution schedule;
An orchestration server.

The event schedule data includes, as event data elements, the event location, start date and time, and human scale related information related to the number of people gathered,
The data analysis unit pre-calculates the correspondence between the event data element of the event and the load amount of the processing load generated due to the event based on information on the event executed in the past, and the event holding Holding as data, extracting event data elements from the event schedule data, and creating the event load data based on event holding data including event data elements corresponding to the extracted event data elements;
The orchestration server according to claim 1.

The event schedule data further includes the event genre, attributes, and end time as event data elements.
The orchestration server according to claim 2.

The data analysis unit creates the event load data based on the event holding data if the event holding data corresponding to the event scheduled data exists, and if the event holding data corresponding to the event scheduled data does not exist The orchestration server according to claim 3, wherein event holding data corresponding to the event schedule data is created by learning based on information on events that have been performed in the past.

The schedule unit performs scale-out according to the occurrence of the processing load caused by the event, and creates the scaling execution schedule so as to perform scale-in according to the end of the processing load.
The orchestration server according to claim 1.

The schedule unit performs scale-out before a predetermined time before the start date and time of the event, and creates the scaling execution schedule so as to perform scale-in after a predetermined time after the end time of the processing load.
The orchestration server according to claim 1.

The orchestration server according to claim 1, wherein the virtual machine generation unit selects whether to perform the scale-out and the scale-in according to an operation of an operator.

The data analysis unit obtains the maximum value of the usage rate of the virtual node for each of a plurality of ranges while the processing load due to the event is occurring, and thereafter used for the event The orchestration according to claim 1, wherein when the scaling is performed using the same event holding data as described above, the range in which the scaling is performed is determined so as to create a virtual node in preference to the range in which the maximum value is large. Server.

The data analysis unit
A genre table showing a list of genres to classify events, and a genre indicating an attribute belonging to the genre and a mobilization rate that is a ratio of the number of mobilizations with respect to the number of people accommodated in the venue of the attribute for each genre described in the genre table An attribute table, a place management table indicating the number of persons in each holding place where the event is held, an event table indicating a genre, an attribute, a holding place, a start date / time, an end date / time, and a processing load for an event to be held Manage
When a genre, an attribute, a venue, a start date / time, and an end date / time of an event scheduled to be held are specified, the mobilization rate is obtained by referring to the genre attribute table by the genre and the attribute, Obtaining the number of persons accommodated with reference to a place management table, calculating the number of mobilization by multiplying the number of persons accommodated and the mobilization rate, the mobilization number as the processing load,
The orchestration server according to claim 1.

An orchestration method for scaling a virtual network for processing by a virtual machine,
The data analysis means creates event load data including information on the processing load occurrence time and the amount of load generated due to the event based on the event schedule data including information on the event schedule,
A schedule unit creates a scaling execution schedule for performing scale-out and scale-in according to the processing load generated due to the event based on the event load data,
A virtual machine generating means performs the scale-out and the scale-in according to the scaling execution schedule;
Orchestration method.

An orchestration program for causing a computer to scale a virtual network for processing by a virtual machine,
A procedure for creating event load data including information on processing load occurrence time and load amount generated due to the event based on event schedule data including information on an event schedule, and
A step of creating a scaling execution schedule for performing a scale-out and a scale-in according to a processing load caused by the event based on the event load data;
A virtual machine generating means for performing the scale-out and the scale-in according to the scaling execution schedule;
Orchestration program for running a computer on a computer.