JP2018032245A - 計算機システム及びリソース制御方法 - Google Patents

Abstract

【課題】突発的な通信量の増加時に伴って、ネットワークへの接続不良及び通信速度の低下等の問題が発生する。【解決手段】ネットワークサービスを構成する業務システムにリソースを提供する第１システム及び第１システムを管理する第２システムを含む計算機システムであって、第１システムには業務システムが構築され、第２システムは、スケーリングを実行するリソース管理部と、ネットワークサービスに影響を与えるイベントの発生を監視する監視部とを含み、監視部は、検出された第１イベントの後に発生する第２イベントの発生予測日時を算出し、第２イベントの影響を受けるネットワークサービスを特定し、ネットワークサービスを構成する業務システムに対するスケーリングの種別、変更リソース量、及び実行日時を含む設定情報を生成する。【選択図】図２

Description

本発明は、ネットワーク仮想化技術におけるスケーリングの制御方法に関する。

近年、ネットワークを介してサーバ群のリソースを活用して、仮想化されたサーバ装置、ストレージ装置、及びネットワーク装置等の運用の自動化を実現するクラウドコンピューティング(以下、クラウド)が普及している。

クラウドを使用することによって、システム管理者は、自前でサーバ等を保持することなく、必要なときに必要な量のリソースを調達し、低コストで柔軟なシステムを構築することができる。

クラウドを利用したシステムの例として、ネットワーク装置の機能を汎用的なサーバ装置上で稼働する仮想マシン（ＶＭ）上のソフトウェアを用いて実現するＮＦＶ（Ｎｅｔｗｏｒｋ Ｆｕｎｃｔｉｏｎｓ Ｖｉｒｔｕａｌｉｚａｔｉｏｎ）がある。

クラウド環境において、ＶＭの負荷に応じて処理性能を制御する方法として、スケーリングが利用されている。

スケーリングでは、監視装置等が、対象システムの処理負荷を監視し、処理負荷が一定の閾値より大きい場合、対象システム上で稼働するＶＭの数又はＶＭに割り当てるリソースを増減させることによって、リソースの利用効率を向上させることができる。

スケーリングには、ＶＭの数を追加するスケールアウト、ＶＭの数を削減するスケールイン、ＶＭに割り当てるリソース量を増やすスケールアップ、ＶＭに割り当てるリソースを減らすスケールダウンがある。

クラウド環境におけるスケーリングについては、特許文献１及び特許文献２に記載されている技術が知られている。

特許文献１には、「本システムは、対象システムの仮想サーバのスケール制御を行う機能を有し、対象システムを利用する顧客企業のカレンダー情報及びスケール制御のための実スケジュールを生成するための定義情報を設定する処理部と、設定情報を参照して、スケール制御のための実スケジュール情報を生成するスケジューリング処理を行う処理部と、実スケジュール情報に従う日時タイミングで、仮想サーバに対するスケール制御の指示を送信する処理を行う処理部とを有する。」ことが記載されている。

また、特許文献２には、「通信システムは通信装置と情報処理装置とを含む。通信装置は、通信インタフェース部を介して伝送されるパケットを処理する１つ以上の機能を含み、自通信装置の負荷の状態を監視し、負荷が閾値より高くなった場合に、負荷が閾値より高くなった状態の要因となっている１つ以上の機能の中の特定機能に関する情報を情報処理装置に供給した後、受信したパケットを情報処理装置に転送する。情報処理装置は、特定機能に関する情報を受信して、特定機能に対応する機能を含む仮想装置を動的に生成し、転送されたパケットを受け取って仮想装置に処理させる。」ことが記載されている。

特開２０１３−４１３９７号公報 特開２０１５−７０４４６号公報

OpenStack Foundation、"OpenStack Operations Guide"、［online］、［平成28年3月17日検索］、インターネット〈URL: http://docs.openstack.org/openstack-ops/openstack-ops-manual.pdf〉

近年、ＩｏＴの普及によって、ネットワークに接続されるＩｏＴデバイスの数が飛躍的に増加している。ＩｏＴデバイスは、センサ及び通信機能を内蔵し、センサによって収集された情報をデータ収集装置に送信する。

ＩｏＴデバイスとデータ収集装置との間の通信経路には、クラウド上で運用されるネットワーク機能を有するＶＭが存在し、当該ネットワーク機能によって転送処理が行われる。

ＩｏＴデバイスは、センサを用いてリアルタイムに情報を収集し、宛先の装置に収集した情報を送信するため、通信量は一定ではない。そのため、ＩｏＴデバイスと宛先の装置との間の通信量が、突発的に増加した場合、スケーリングが間に合わず、ネットワーク機能の処理負荷が増大することによってパケットロスが発生する。したがって、ＩｏＴデバイスの情報を有効に活用することが困難となる。

また、停電等、予測が困難な第１イベントが発生した場合、第１イベントが発生してから一定時間経過した後に発生が見込まれるネットワーク復旧等の第２イベントの発生に伴って通信量が増加する。この場合も、ネットワークへの接続不良及び通信速度の低下という問題が発生する。

特許文献１又は特許文献２に記載のシステムでは、第２イベントの予測に基づいてスケーリングが行われない。したがって、大規模なネットワーク障害が復旧した場合等、突発的に通信量が増加した場合、スケーリングが間に合わない可能性がある。ネットワーク機能の処理負荷に伴って発生するネットワークの輻輳によって、ネットワークへの接続不良及び通信速度の低下等の問題を引き起こす。

本願において開示される発明の代表的な一例を示せば以下の通りである。すなわち、ネットワークサービスを構成する業務システムにリソースを提供する複数の第１システム及び前記複数の第１システムを管理する第２システムを含む計算機システムであって、前記複数の第１システムの各々は、複数の第１計算機を含み、前記第２システムは、少なくとも一つの第２計算機を含み、前記第１システムには、異なるネットワークサービスを提供する業務システムが構築され、前記業務システムは、前記第１計算機のリソースを用いて生成され、かつ、ネットワーク機能を有する仮想計算機を含み、前記複数の第１計算機は、前記仮想計算機を管理する仮想化制御部を含み、前記少なくとも一つの第２計算機は、前記業務システムに割り当てるリソース量を制御するためのスケーリングを実行するリソース管理部と、前記ネットワークサービスに影響を与えるイベントの発生を監視する監視部と、を含み、前記監視部は、第１イベントの発生を検出した場合、前記第１イベントの後に発生する第２イベントの発生予測日時を算出し、前記第２イベントの影響を受けるネットワークサービスを特定し、前記特定されたネットワークサービスを構成する業務システムに対する前記スケーリングの種別、前記スケーリングによって変更される業務システムのリソース量を表す変更リソース量、及び前記スケーリングの実行日時を含む設定情報を生成することを特徴とする。

本発明によれば、監視部は、第２イベントに応じたスケーリングに必要なパラメータ及び実行タイミングを含むスケジュールを設定できる。当該スケジュールに基づいてスケーリングが行われることによって、突発的な通信量の増加に伴うネットワークの接続不良及び通信速度の低下等を防ぐことができる。前述した以外の課題、構成及び効果は、以下の実施例の説明によって明らかにされる。

実施例１の計算機システムの構成例を示す図である。 実施例１のイベント分析サーバのハードウェア構成及びソフトウェア構成の一例を示す図である。 実施例１のオーケストレーションサーバのハードウェア構成及びソフトウェア構成の一例を示す図である。 実施例１のイベント種別情報の一例を示す図である。 実施例１のイベント監視対象情報の一例を示す図である。 実施例１のスケーリング種別情報の一例を示す図である。 実施例１の場所管理情報の一例を示す図である。 実施例１のサービス情報の一例を示す図である。 実施例１のイベント情報の一例を示す図である。 実施例１のオーケストレーション設定情報の一例を示す図である。 実施例１のネットワーク機能情報の一例を示す図である。 実施例１のパッケージ情報の一例を示す図である。 実施例１のシナリオ情報の一例を示す図である。 実施例１のハイパバイザ情報の一例を示す図である。 実施例１のテナント情報の一例を示す図である。 実施例１のネットワーク機能インスタンス情報の一例を示す図である。 実施例１のスケジュール情報の一例を示す図である。 実施例１の実行中シナリオ情報の一例を示す図である。 実施例１のイベント分析サーバの監視部が実行する処理を説明するフローチャートである。 実施例１のイベント分析サーバのイベント分析部が実行する処理を説明するフローチャートである。 実施例１のイベント分析サーバのイベント分析部が実行するオーケストレーション設定情報の更新処理を説明するフローチャートである。 実施例１のイベント分析サーバのオーケストレーション設定部が実行する処理を説明するフローチャートである。 実施例１のオーケストレーションサーバのスケジュール部が実行する処理を説明するフローチャートである。 実施例１のオーケストレーションサーバのシナリオ登録部が実行する処理を説明するフローチャートである。 実施例１のオーケストレーションサーバのオーケストレーション実行部が実行する処理を説明するフローチャートである。 実施例１のオーケストレーションサーバのオーケストレーション実行部が実行するシナリオ処理の一例を説明するフローチャートである。

以下、添付図面を参照して本発明の実施例を説明する。各図において共通の構成については同一の参照符号が付されている。

図１は、実施例１の計算機システムの構成例を示す図である。

計算機システムは、クライアント端末１０１、イベント分析サーバ１０２、オーケストレーションサーバ１０３、クラウド管理サーバ１０４、イベント情報サーバ１０５、計算サーバ１０６、サービスＳＷ１０７、ＩｏＴ ＧＷ１０８、及びセンサノード１０９から構成される。

イベント分析サーバ１０２は、インターネット１１０を介してイベント情報サーバ１０５と接続する。クラウド管理サーバ１０４は、サービスＳＷ１０７を介して計算サーバ１０６と接続する。また、計算サーバ１０６は、外部ＮＷ１１１及びＩｏＴ ＧＷ１０８を介してセンサノード１０９と接続する。

なお、本実施例は、装置間を接続するネットワークの種別に限定されない。例えば、ＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）及びＷＡＮ（Ｗｉｄｅ Ａｒｅａ Ｎｅｔｗｏｒｋ）等を用いてもよい。装置間の接続形式は、無線又は有線のいずれであってもよい。また、各装置は、直接接続されてもよい。

クライアント端末１０１は、イベント分析サーバ１０２に接続し、監視対象のイベント情報サーバ１０５に関する情報等を登録する。また、クライアント端末１０１は、オーケストレーションサーバ１０３に接続し、計算サーバ１０６のリソースを制御するためのオーケストレーション処理に必要な情報を登録する。

計算サーバ１０６は、クラウドを実現する計算機基盤を構成する計算機であり、仮想ネットワークサービスを実現するシステムを構成するためのリソースを提供する。計算サーバ１０６は、図示しないＣＰＵ、メモリ、記憶装置、及びネットワークインタフェースを有する。計算サーバ１０６上では、仮想マシン（ＶＭ）を管理する仮想化制御部が稼働する。なお、計算サーバ１０６の詳細は、非特許文献１の８ページの９行目に「Ｃｏｍｐｕｔｅ ｎｏｄｅｓ」として記載されている。

本実施例では、仮想化制御部としてハイパバイザを例に説明する。なお、仮想化制御部は、ハイパバイザに限定されない。

なお、計算機基盤は、複数の地域に存在するデータセンタから構成される。データセンタは、複数の計算サーバ１０６から構成される。また、仮想ネットワークサービスは、仮想ネットワークサービスを実現するシステムであるテナントから構成される。テナントは、データセンタのリソースを用いて生成された一つ以上のＶＭから構成される。ＶＭは、所定のネットワーク機能を有する。

オーケストレーションサーバ１０３は、テナントに提供するリソースを管理する。具体的には、オーケストレーションサーバ１０３は、クライアント端末１０１又はイベント分析サーバ１０２からの指示にしたがって、リソースの制御内容（スケーリングの処理内容）を決定し、決定した制御内容を含むオーケストレーション指示をクラウド管理サーバ１０４に送信する。

クラウド管理サーバ１０４は、計算サーバ１０６のリソースを管理する。本実施例のクラウド管理サーバ１０４は、オーケストレーションサーバ１０３から受信したオーケストレーション指示にしたがって、スケーリングを実行する。クラウド管理サーバ１０４の詳細は、非特許文献の８ページの１行目に、「Ｃｌｏｕｄ ｃｏｎｔｒｏｌｌｅｒ」として記載されている。クラウド管理サーバ１０４は、オーケストレーションサーバ１０３と連携することによってリソース管理機能を実現する。

センサノード１０９は、図示しないセンサ、ＣＰＵ、メモリ、及びネットワークインタフェースを有し、センサを用いて計測対象の値を計測する。センサノード１０９は、ＩｏＴ ＧＷ１０８及び外部ＮＷ１１１を介して、計算サーバ１０６上で稼働するＶＭに計測値を送信する。ＶＭは、計測値を受信した場合、当該ＶＭが有するネットワーク機能に基づいて計測値の転送処理等を実行する。

イベント分析サーバ１０２は、イベント情報サーバ１０５に接続して、イベントの発生の有無を監視する。イベント分析サーバ１０２は、任意のイベントの発生を検出した場合、仮想ネットワークサービスに与える影響を分析し、分析結果に基づいてオーケストレーション指示を行うための情報を生成する。イベント分析サーバ１０２は、オーケストレーション指示を行うための情報をオーケストレーションサーバ１０３に送信する。以下の説明では、オーケストレーション指示を行うための設定情報を設定情報と記載する。

イベント情報サーバ１０５は、イベント分析サーバ１０２が監視するサーバである。イベント情報サーバ１０５は、任意のイベントの情報を発信する。例えば、イベント情報サーバ１０５は、電力会社が運用するＷｅｂサーバ等が考えられる。当該Ｗｅｂサーバには、予測することが困難な停電等のイベントの情報が掲載される。

本実施例では、複数の計算サーバ１０６及びサービスＳＷ１０７が計算機基盤を構成する一つのデータセンタを構成し、イベント分析サーバ１０２、オーケストレーションサーバ１０３、及びクラウド管理サーバ１０４が計算機基盤の監視及び管理を行うシステムを構成する。

図１では、クライアント端末１０１、イベント分析サーバ１０２、オーケストレーションサーバ１０３、クラウド管理サーバ１０４、及びイベント情報サーバ１０５の数は、それぞれ一つずつであるが、二つ以上であってもよい。

本実施例では、クライアント端末１０１、イベント分析サーバ１０２、オーケストレーションサーバ１０３、クラウド管理サーバ１０４、及びイベント情報サーバ１０５は、物理計算機として記載しているが、ＶＭを用いて実現してもよい。

また、各装置が有する機能は、一つの装置に集約してもよい。例えば、オーケストレーションサーバ１０３に、イベント分析サーバ１０２が有する機能を集約してもよい。また、クラウド管理サーバ１０４に、オーケストレーションサーバ１０３が有する機能を集約してもよい。

図２は、実施例１のイベント分析サーバ１０２のハードウェア構成及びソフトウェア構成の一例を示す図である。

イベント分析サーバ１０２は、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）２０１、メモリ２０２、及びネットワークＩＦ２０３を有する。各ハードウェアは、内部バス等を介して互いに接続される。なお、イベント分析サーバ１０２は、ＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）及びＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）等の記憶装置を有してもよい。

ＣＰＵ２０１は、メモリ２０２に格納されるプログラムを実行する。ＣＰＵ２０１がプログラムを実行することによって、イベント分析サーバ１０２が有する機能を実現する。以下の説明では、機能部を主語に処理を説明する場合、ＣＰＵ２０１が当該機能部を実現するプログラムを実行していることを表す。

メモリ２０２は、ＣＰＵ２０１が実行するプログラム及び当該プログラムによって使用される情報を格納する。また、メモリ２０２は、プログラムが一時的に使用するワークエリアを含む。

ネットワークＩＦ２０３は、ネットワークを介して外部装置と接続するインタフェースである。

ここで、メモリ２０２に格納されるプログラム及び情報について説明する。メモリ２０２は、監視部２１１、イベント分析部２１２、及びオーケストレーション設定部２１３を実現するプログラムを格納する。また、メモリ２０２は、イベント種別情報２２１、イベント監視対象情報２２２、スケーリング種別情報２２３、場所管理情報２２４、サービス情報２２５、イベント情報２２６、及びオーケストレーション設定情報２２７を格納する。

イベント種別情報２２１は、イベント分析サーバ１０２が監視するイベントの種別等の情報を格納する。イベント種別情報２２１の詳細は、図４を用いて説明する。

イベント監視対象情報２２２は、監視対象のイベント情報サーバ１０５の情報を格納する。イベント監視対象情報２２２の詳細は、図５を用いて説明する。

スケーリング種別情報２２３は、スケーリングの種別を格納する。スケーリング種別情報２２３の詳細は、図６を用いて説明する。

場所管理情報２２４は、データセンタの場所等の情報を格納する。場所管理情報２２４の詳細は、図７を用いて説明する。

サービス情報２２５は、仮想ネットワークサービスの情報を格納する。サービス情報２２５の詳細は、図８を用いて説明する。

イベント情報２２６は、検出されたイベントの情報を格納する。イベント情報２２６の詳細は、図９を用いて説明する。

オーケストレーション設定情報２２７は、イベント分析サーバ１０２によって生成される設定情報を格納する。オーケストレーション設定情報２２７の詳細は、図１０を用いて説明する。

監視部２１１は、イベント監視対象情報２２２に基づいて、イベント情報サーバ１０５を監視する。監視部２１１は、予測が困難なイベントの発生を検出した場合、当該イベントの後に発生する可能性があるイベントを特定し、イベント情報２２６に検出したイベント等に関する情報を書き込む。監視部２１１が実行する処理の詳細は、図１９を用いて説明する。

以下の説明では、イベント情報サーバ１０５から検出されたイベントを第１イベントと記載し、第１イベントの後に発生するイベントを第２イベントと記載する。

イベント分析部２１２は、監視部２１１によって検出された第１イベントを解析し、解析結果に基づいて設定情報を生成し、オーケストレーション設定情報２２７に設定情報を書き込む。イベント分析部２１２が実行する処理の詳細は、図２０及び図２１を用いて説明する。

オーケストレーション設定部２１３は、オーケストレーション設定情報２２７から設定情報を読み出し、オーケストレーションサーバ１０３に読み出された設定情報を送信する。オーケストレーション設定部２１３が実行する処理の詳細は、図２２を用いて説明する。

図３は、実施例１のオーケストレーションサーバ１０３のハードウェア構成及びソフトウェア構成の一例を示す図である。

オーケストレーションサーバ１０３は、ＣＰＵ３０１、メモリ３０２、及びネットワークＩＦ３０３を有する。各ハードウェアは、内部バス等を介して互いに接続される。なお、オーケストレーションサーバ１０３は、ＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）及びＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）等の記憶装置を有してもよい。

ＣＰＵ３０１、メモリ３０２、及びネットワークＩＦ３０３は、ＣＰＵ２０１、メモリ２０２、及びネットワークＩＦ２０３と同様のものである。

ここで、メモリ３０２に格納されるプログラム及び情報について説明する。メモリ３０２は、スケジュール部３１１、シナリオ登録部３１２、及びオーケストレーション実行部３１３を実現するプログラムを格納する。また、メモリ３０２は、ネットワーク機能情報３２１、パッケージ情報３２２、シナリオ情報３２３、ハイパバイザ情報３２４、テナント情報３２５、ネットワーク機能インスタンス情報３２６、スケジュール情報３２７、及び実行中シナリオ情報３２８を格納する。さらに、メモリ３０２は、各ネットワーク機能のシナリオとして、ＭＭＥシナリオ３３１、ＳＡＥ−ＧＷシナリオ３３２、及びＷＡＣシナリオ３３３を格納する。

ネットワーク機能情報３２１は、ネットワーク機能を実現するソフトウェア等の情報を格納する。ネットワーク機能情報３２１の詳細は、図１１を用いて説明する。

パッケージ情報３２２は、ネットワーク機能を実現するソフトウェア及び各種設定を含むパッケージに含まれるＶＭの設定情報を格納する。パッケージ情報３２２の詳細は、図１２を用いて説明する。

パッケージは、ＶＭの設定情報、ネットワークの設定情報、起動ディスク、及びシナリオ等を一つにまとめたアーカイブファイルである。オーケストレーションサーバ１０３は、ネットワーク機能及びシナリオの種別の組み合わせの数だけパッケージを含む。

シナリオ情報３２３は、スケーリングシナリオの情報を格納する。シナリオ情報３２３の詳細は、図１３を用いて説明する。

スケーリングシナリオは、スケーリングの手順及び設定項目を含む情報である。以下の説明では、スケーリングシナリオを単にシナリオと記載する。

ハイパバイザ情報３２４は、計算サーバ１０６上で稼働するハイパバイザの情報を格納する。ハイパバイザ情報３２４の詳細は、図１４を用いて説明する。

テナント情報３２５は、仮想ネットワークサービスを構成するテナントの情報を格納する。テナント情報３２５の詳細は、図１５を用いて説明する。

ネットワーク機能インスタンス情報３２６は、運用中の仮想ネットワークサービスの情報を格納する。ネットワーク機能インスタンス情報３２６の詳細は、図１６を用いて説明する。

スケジュール情報３２７は、オーケストレーション指示の具体的な内容を示す情報を格納する。スケジュール情報３２７の詳細は、図１７を用いて説明する。

実行中シナリオ情報３２８は、実行中のスケーリングの情報を格納する。実行中シナリオ情報３２８の詳細は、図１８を用いて説明する。

ＭＭＥシナリオ３３１は、ネットワーク機能の一つであるＭＭＥ（Ｍｏｂｉｌｉｔｙ Ｍａｎａｇｅｍｅｎｔ Ｅｎｔｉｔｙ）のスケーリングに関するファイル群であり、ＭＭＥスケールインシナリオ３４１、ＭＭＥスケールアウトシナリオ３４２、ＭＭＥスケールアップシナリオ３４３、及びＭＭＥスケールダウンシナリオ３４４を含む。

ＳＡＥ−ＧＷシナリオ３３２は、ネットワーク機能の一つであるＳＡＥ−ＧＷ（Ｓｙｓｔｅｍ Ａｒｃｈｉｔｅｃｔｕｒｅ Ｅｖｏｌｕｔｉｏｎ−Ｇａｔｅｗａｙ）のスケーリングに関するファイル群であり、ＳＡＥ−ＧＷスケールインシナリオ３５１、ＳＡＥ−ＧＷスケールアウトシナリオ３５２、ＳＡＥ−ＧＷスケールアップシナリオ３５３、及びＳＡＥ−ＧＷスケールダウンシナリオ３５４を含む。

ＷＡＣシナリオ３３３は、ネットワーク機能の一つであるＷＡＣ（ＷＡＮ Ａｃｃｅｌｅｒａｔｏｒ）のスケーリングに関するファイル群であり、ＷＡＣスケールインシナリオ３６１、ＷＡＣスケールアウトシナリオ３６２、ＷＡＣスケールアップシナリオ３６３、及びＷＡＣスケールダウンシナリオ３６４を含む。

スケジュール部３１１は、イベント分析サーバ１０２のオーケストレーション設定部２１３から設定情報を受信した場合、当該設定情報をスケーリングのスケジュールとしてスケジュール情報３２７に書き込む。スケジュール部３１１が実行する処理の詳細は、図２３を用いて説明する。

シナリオ登録部３１２は、スケジュール情報３２７を参照し、実行日時を経過したスケジュールの情報を実行中シナリオ情報３２８に書き込む。シナリオ登録部３１２が実行する処理の詳細は、図２４を用いて説明する。

オーケストレーション実行部３１３は、実行中シナリオ情報３２８に登録されたスケジュールの情報に基づいて、クラウド管理サーバ１０４にオーケストレーション指示を送信する。オーケストレーション実行部３１３が実行する処理の詳細は、図２５及び図２６を用いて説明する。

なお、クライアント端末１０１、クラウド管理サーバ１０４、イベント情報サーバ１０５、サービスＳＷ１０７、及びＩｏＴ ＧＷ１０８のハードウェア構成は、イベント分析サーバ１０２と同様のものであるものとする。

次に、図４から図１０を用いて、イベント分析サーバ１０２が管理する情報について説明する。

図４は、実施例１のイベント種別情報２２１の一例を示す図である。

イベント種別情報２２１は、クライアント端末１０１を操作するシステム管理者によって設定される情報であり、イベント種別ＩＤ４０１、イベント種別名４０２、及び影響度４０３から構成されるレコードを含む。

イベント種別ＩＤ４０１は、イベントの種別を一意に識別するための識別情報である。イベント種別ＩＤ４０１は、イベント種別情報２２１のレコードを一意に識別する識別情報としても用いられる。

イベント種別名４０２は、イベントの種別を表す名称である。本実施例では、停電、強風、及び列車事故等の障害を第１イベントと定義し、また、障害の復旧を第２イベントと定義している。そのため、イベント種別情報２２１には、第２イベントを識別するカラムを含めていないが、イベント種別情報２２１に第２イベントを設定するカラムを設けてもよい。なお、第１イベント及び第２イベントの組合わせは、前述したものに限定されない。

影響度４０３は、レコードに対応するイベント（第１イベント）の後に発生するイベント（第２イベント）が仮想ネットワークサービスに与える影響の大きさを示す数値である。影響度４０３は、後述するようにシナリオ（スケーリングの制御内容）を決定する場合に使用される。なお、影響度４０３の値が「１」より大きい場合、リソース量を追加するためのスケーリングが行われ、影響度４０３の値が「１」より小さい場合、リソース量を削減するためのスケーリングが行われる。

図５は、実施例１のイベント監視対象情報２２２の一例を示す図である。

イベント監視対象情報２２２は、クライアント端末１０１を操作するシステム管理者によって設定される情報であり、イベント監視対象ＩＤ５０１、イベント種別ＩＤ５０２、監視対象名５０３、及び公開ＵＲＬ５０４から構成されるレコードを含む。

イベント監視対象ＩＤ５０１は、監視対象を一意に識別するための識別情報である。イベント監視対象ＩＤ５０１は、イベント監視対象情報２２２のレコードを一意に識別する識別情報としても用いられる。

イベント種別ＩＤ５０２は、イベント種別ＩＤ４０１と同一のものである。

監視対象名５０３は、監視対象の名称である。監視対象名５０３には、Ｗｅｂページを公開している企業の名称等が格納される。なお、監視対象名５０３に格納される企業は、仮想ネットワークサービスを運用するユーザとは必ずしも一致するわけではない。

公開ＵＲＬ５０４は、監視するＷｅｂサイトのＵＲＬである。イベント分析サーバ１０２は、公開ＵＲＬ５０４に設定されたＵＲＬに基づいて、Ｗｅｂサイトにアクセスし、イベントの発生の有無を判定する。

図６は、実施例１のスケーリング種別情報２２３の一例を示す図である。

スケーリング種別情報２２３は、クライアント端末１０１を操作するシステム管理者によって設定される情報であり、スケーリング種別ＩＤ６０１及びスケーリング種別６０２から構成されるレコードを含む。

スケーリング種別ＩＤ６０１は、スケーリングの種別を一意に識別するための識別情報である。スケーリング種別ＩＤ６０１は、スケーリング種別情報２２３のレコードを一意に識別するための識別情報としても用いられる。

スケーリング種別６０２は、スケーリングの種別の名称である。本実施例では、スケーリングの種別は、「スケールイン」、「スケールアウト」、「スケールアップ」、及び「スケールダウン」の四つであるため、スケーリング種別情報２２３は四つのレコードを含む。

図７は、実施例１の場所管理情報２２４の一例を示す図である。

場所管理情報２２４は、クライアント端末１０１を操作するシステム管理者によって設定される情報であり、場所ＩＤ７０１、イベント監視対象ＩＤ７０２、場所７０３、及びユーザ数７０４から構成されるレコードを含む。

場所ＩＤ７０１は、データセンタが存在する場所を一意に識別するための識別情報である。場所ＩＤ７０１は、場所管理情報２２４のレコードを一意に識別するための識別情報としても用いられる。

イベント監視対象ＩＤ７０２は、イベント監視対象ＩＤ５０１と同一のものである。

場所７０３は、場所の名称である。場所７０３には、例えば、データセンタが存在する地域の名称が格納される。

ユーザ数７０４は、場所７０３に対応する場所に収容可能なユーザの数である。

図８は、実施例１のサービス情報２２５の一例を示す図である。

サービス情報２２５は、クライアント端末１０１を操作するシステム管理者によって設定される情報であり、サービスＩＤ８０１、サービス名８０２、及び場所リスト８０３から構成されるレコードを含む。

サービスＩＤ８０１は、仮想ネットワークサービスを一意に識別するための識別情報である。サービスＩＤ８０１は、サービス情報２２５のレコードを一意に識別する識別情報としても用いられる。

サービス名８０２は、仮想ネットワークサービスの名称である。例えば、ネットワーク機能及びサービスの提供地域を組み合わせた名称がサービス名８０２に設定される。

場所リスト８０３は、サービス名８０２に対応する仮想ネットワークサービスを構成するテナントが存在する場所のリストである。場所リスト８０３には、場所管理情報２２４に定義された場所ＩＤ７０１が格納される。

図９は、実施例１のイベント情報２２６の一例を示す図である。

イベント情報２２６は、監視部２１１によって生成される情報であり、イベントＩＤ９０１、イベント種別ＩＤ９０２、イベント監視対象ＩＤ９０３、場所ＩＤ９０４、発生日時９０５、及び次イベント予測日時９０６から構成されるレコードを含む。なお、レコードは、第２イベントの識別情報を格納するカラムを含んでもよい。

イベントＩＤ９０１は、検出された第１イベントを一意に識別するための識別情報である。イベントＩＤ９０１は、イベント情報２２６のレコードを一意に識別するための識別情報としても用いられる。

イベント種別ＩＤ９０２は、イベント種別ＩＤ４０１と同一のものである。また、イベント監視対象ＩＤ９０３は、イベント監視対象ＩＤ５０１と同一のものである。場所ＩＤ９０４は、場所ＩＤ７０１と同一のものである。

発生日時９０５は、第１イベントが発生した日時である。発生日時９０５には、実際に第１イベントが発生した日時が格納されてもよいし、また、イベント分析サーバ１０２が第１イベントの発生を検出した日時が格納されてもよい。

次イベント予測日時９０６は、第２イベントの発生予測日時である。

図１０は、実施例１のオーケストレーション設定情報２２７の一例を示す図である。

オーケストレーション設定情報２２７は、イベント分析部２１２によって生成される情報であり、オーケストレーション設定ＩＤ１００１、実行日時１００２、スケーリング種別ＩＤ１００３、規模１００４、及びサービスＩＤ１００５から構成されるレコードを含む。

オーケストレーション設定ＩＤ１００１は、設定情報を一意に識別するための識別情報である。オーケストレーション設定ＩＤ１００１は、オーケストレーション設定情報２２７のレコードを一意に識別するための識別情報としても用いられる。

実行日時１００２は、スケーリングが開始される日時である。例えば、オーケストレーションサーバ１０３がオーケストレーション指示を送信する日時が、実行日時１００２に格納される。

スケーリング種別ＩＤ１００３は、スケーリング種別ＩＤ６０１と同一のものである。また、サービスＩＤ１００５は、サービスＩＤ８０１と同一のものである。

規模１００４は、テナントに割り当てるリソースの変更量（変更リソース量）を表す情報である。例えば、スケールアウトの場合、規模１００４には、追加するＶＭの数が格納される。スケールアップの場合、規模１００４には、ＶＭに追加するＣＰＵコア及びメモリ容量等の値が格納される。スケールインの場合、規模１００４には、削除するＶＭの数が格納される。スケールダウンの場合、規模１００４には、ＶＭから削減するＣＰＵコア及びメモリ容量等の値が格納される。

なお、イベント種別情報２２１、イベント監視対象情報２２２、スケーリング種別情報２２３、場所管理情報２２４、及びサービス情報２２５は、システム管理者によって設定される情報と記載したが、これに限定されない。例えば、場所管理情報２２４は、クラウド管理サーバ１０４から取得してもよい。

次に、図１１から図１８を用いて、オーケストレーションサーバ１０３が管理する情報について説明する。

図１１は、実施例１のネットワーク機能情報３２１の一例を示す図である。

ネットワーク機能情報３２１は、クライアント端末１０１を操作するシステム管理者によって設定される情報であり、ネットワーク機能ＩＤ１１０１、ネットワーク機能名１１０２、及び起動イメージファイル１１０３を含む。

ネットワーク機能ＩＤ１１０１は、ネットワーク機能を一意に識別するための識別情報である。ネットワーク機能ＩＤ１１０１は、ネットワーク機能情報３２１のレコードを一意に識別するための識別情報としても用いられる。

ネットワーク機能名１１０２は、ネットワーク機能の名称である。

起動イメージファイル１１０３は、ネットワーク機能を有するＶＭを起動するための起動イメージファイルである。

図１２は、実施例１のパッケージ情報３２２の一例を示す図である。

パッケージ情報３２２は、クライアント端末１０１を操作するシステム管理者によって設定される情報であり、パッケージＩＤ１２０１、ネットワーク機能ＩＤ１２０２、仮想ＣＰＵコア数１２０３、メモリ容量１２０４、及びディスク容量１２０５から構成されるレコードを含む。

パッケージＩＤ１２０１は、パッケージを一意に識別するための識別情報である。パッケージＩＤ１２０１は、パッケージ情報３２２のレコードを一意に識別するための識別情報としても用いられる。

ネットワーク機能ＩＤ１２０２は、ネットワーク機能ＩＤ１１０１と同一のものである。

仮想ＣＰＵコア数１２０３、メモリ容量１２０４は、及びディスク容量１２０５、ＶＭに割り当てるリソース量である。具体的には、仮想ＣＰＵコア数１２０３はＶＭに割り当てる仮想ＣＰＵコアの数であり、メモリ容量１２０４はＶＭに割り当てるメモリの記憶容量であり、ディスク容量１２０５はＶＭに割り当てる記憶装置の記憶容量である。

図１３は、実施例１のシナリオ情報３２３の一例を示す図である。

シナリオ情報３２３は、クライアント端末１０１を操作するシステム管理者によって設定される情報であり、シナリオＩＤ１３０１、スケーリング種別ＩＤ１３０２、ネットワーク機能ＩＤ１３０３、及びシナリオ１３０４から構成されるレコードを含む。

シナリオＩＤ１３０１は、スケーリングに使用するシナリオを一意に識別するための識別情報である。シナリオＩＤ１３０１は、シナリオ情報３２３のレコードを一意に識別するための識別情報としても用いられる。

スケーリング種別ＩＤ１３０２は、スケーリング種別ＩＤ６０１と同一のものである。ネットワーク機能ＩＤ１３０３は、ネットワーク機能ＩＤ１１０１と同一のものである。

シナリオ１３０４は、スケーリング種別ＩＤ１３０２及びネットワーク機能ＩＤ１３０３に対応するシナリオである。

図１４は、実施例１のハイパバイザ情報３２４の一例を示す図である。

ハイパバイザ情報３２４は、クライアント端末１０１を操作するシステム管理者によって設定される情報であり、ハイパバイザＩＤ１４０１、ハイパバイザ名１４０２、ＣＰＵコア数１４０３、メモリ容量１４０４、及びディスク容量１４０５から構成されるレコードを含む。

ハイパバイザＩＤ１４０１は、ハイパバイザを一意に識別するための識別情報である。ハイパバイザＩＤ１４０１は、ハイパバイザ情報３２４のレコードを一意に識別するための識別情報としても用いられる。

ハイパバイザ名１４０２は、ハイパバイザＩＤ１４０１に対応するハイパバイザの名称である。

ＣＰＵコア数１４０３、メモリ容量１４０４、及びディスク容量１４０５は、ハイパバイザＩＤ１４０１に対応するハイパバイザが稼働する計算サーバ１０６が有するリソース量である。具体的には、ＣＰＵコア数１４０３は計算サーバ１０６が有するＣＰＵに含まれるコアの総数であり、メモリ容量１４０４は計算サーバ１０６が有するメモリの全記憶容量であり、ディスク容量１４０５は、計算サーバ１０６が有する記憶装置の記憶容量である。

図１５は、実施例１のテナント情報３２５の一例を示す図である。

テナント情報３２５は、クライアント端末１０１を操作するシステム管理者によって設定される情報であり、テナントＩＤ１５０１、テナント名１５０２、及びハイパバイザリスト１５０３から構成されるレコードを含む。

テナントＩＤ１５０１は、テナントを一意に識別するための識別情報である。テナントＩＤ１５０１は、テナント情報３２５のレコードを一意に識別するための識別情報としても用いられる。

テナント名１５０２は、テナントＩＤ１５０１に対応するテナントの名称である。

ハイパバイザリスト１５０３は、テナントを構成するＶＭに割り当てるリソース量を制御するハイパバイザのリストである。すなわち、テナントにリソースを提供する計算サーバ１０６のリストである。ハイパバイザリスト１５０３には、ハイパバイザ情報３２４に定義されたハイパバイザＩＤ１４０１が格納される。

図１６は、実施例１のネットワーク機能インスタンス情報３２６の一例を示す図である。

ネットワーク機能インスタンス情報３２６は、クライアント端末１０１を操作するシステム管理者によって設定される情報であり、インスタンスＩＤ１６０１、ネットワーク機能ＩＤ１６０２、パッケージＩＤ１６０３、テナントＩＤ１６０４、及び起動ハイパバイザリスト１６０５から構成されるレコードを含む。

インスタンスＩＤ１６０１は、任意のネットワーク機能を提供する稼働中の仮想ネットワークサービスのインスタンスを一意に識別するための識別情報である。インスタンスＩＤ１６０１は、ネットワーク機能インスタンス情報３２６のレコードを一意に識別するための識別情報としても用いられる。また、インスタンスＩＤ１６０１は、サービスＩＤ８０１と対応付けられる。これによって、オーケストレーションサーバ１０３は、受信した設定情報の対象がどのインスタンス（仮想ネットワークサービス）であるかを把握できる。

ネットワーク機能ＩＤ１６０２は、ネットワーク機能ＩＤ１１０１と同一のものである。パッケージＩＤ１６０３は、パッケージＩＤ１２０１と同一のものである。テナントＩＤ１６０４は、テナントＩＤ１５０１と同一のものである。本実施例では、一つのテナントを用いて、一つの仮想ネットワークサービスが提供されるものとする。

起動ハイパバイザリスト１６０５は、ネットワーク機能ＩＤ１６０２に対応するネットワーク機能を有するＶＭが稼働しているハイパバイザのリストである。起動ハイパバイザリスト１６０５には、ハイパバイザ情報３２４に定義されたハイパバイザＩＤ１４０１が格納される。

図１７は、実施例１のスケジュール情報３２７の一例を示す図である。

スケジュール情報３２７は、スケジュール部３１１によって生成される情報であり、スケジュールＩＤ１７０１、インスタンスＩＤ１７０２、シナリオＩＤ１７０３、パッケージＩＤ１７０４、テナントＩＤ１７０５、実行日時１７０６、及び規模１７０７から構成されるレコードを含む。

スケジュールＩＤ１７０１は、スケジュールを一意に識別するための識別情報である。スケジュールＩＤ１７０１は、スケジュール情報３２７のレコードを一意に識別するための識別情報としても用いられる。

インスタンスＩＤ１７０２は、インスタンスＩＤ１６０１と同一のものである。シナリオＩＤ１７０３は、シナリオＩＤ１３０１と同一のものである。パッケージＩＤ１７０４は、パッケージＩＤ１２０１と同一のものである。テナントＩＤ１７０５は、テナントＩＤ１５０１と同一のものである。実行日時１７０６は、実行日時１００２と同一のものである。規模１７０７は、規模１００４と同一のものである。

図１８は、実施例１の実行中シナリオ情報３２８の一例を示す図である。

実行中シナリオ情報３２８は、シナリオ登録部３１２によって生成される情報であり、実行中シナリオＩＤ１８０１、インスタンスＩＤ１８０２、シナリオＩＤ１８０３、パッケージＩＤ１８０４、テナントＩＤ１８０５、及び規模１８０６から構成されるレコードを含む。

実行中シナリオＩＤ１８０１は、実行中のスケーリングを一意に識別するための識別情報である。実行中シナリオＩＤ１８０１は、実行中シナリオ情報３２８のレコードを一意に識別するための識別情報としても用いられる。

インスタンスＩＤ１８０２は、インスタンスＩＤ１６０１と同一のものである。シナリオＩＤ１８０３は、シナリオＩＤ１３０１と同一のものである。パッケージＩＤ１８０４は、パッケージＩＤ１２０１と同一のものである。テナントＩＤ１８０５は、テナントＩＤ１５０１と同一のものである。規模１８０６は、規模１００４と同一のものである。

なお、ネットワーク機能情報３２１、パッケージ情報３２２、シナリオ情報３２３、ハイパバイザ情報３２４、テナント情報３２５、及びネットワーク機能インスタンス情報３２６は、システム管理者によって設定される情報と記載したが、これに限定されない。例えば、ハイパバイザ情報３２４、テナント情報３２５、及びネットワーク機能インスタンス情報３２６は、クラウド管理サーバ１０４から取得してもよい。

イベント分析サーバ１０２及びオーケストレーションサーバ１０３が保持する情報は、図４から図１８に示すようにテーブル形式の情報であるが、本実施例はこれに限定されない。

次に、図１９から図２２を用いてイベント分析サーバ１０２が実行する処理について説明する。以下の説明では、符号を含まないカラムの名称は、カラムから取得された値を表すものとする。例えば、イベントＩＤは、イベント情報２２６に含まれるレコードのイベントＩＤ９０１の値を示す。

図１９は、実施例１のイベント分析サーバ１０２の監視部２１１が実行する処理を説明するフローチャートである。

イベント分析サーバ１０２は、起動後、監視部２１１を実現するプログラムをメモリ２０２にロードし、実行する。これによって、監視部２１１は、処理を開始する（ステップＳ１９０１）。

監視部２１１は、プログラムの終了指示を受け付けたか否かを判定する（ステップＳ１９０２）。

プログラムの終了指示を受け付けたと判定された場合、監視部２１１は、処理を終了する（ステップＳ１９１０）。

プログラムの終了指示を受け付けていないと判定された場合、監視部２１１は、第１ループ処理を開始する（ステップＳ１９０３）。このとき、監視部２１１は、イベント監視対象情報２２２からレコードを一つ選択し、選択されたレコードについてステップＳ１９０４からステップＳ１９０８までの処理を実行する。なお、監視部２１１は、周期的に第１ループ処理を実行する場合、前回の第１ループ処理が終了してから一定時間経過した後に第１ループ処理を開始する。

監視部２１１は、イベント監視対象情報２２２から選択されたレコードの公開ＵＲＬに基づいてイベント情報サーバ１０５にアクセスして、イベント発生情報を取得する（ステップＳ１９０４）。例えば、監視部２１１は、障害情報を提示するＷｅｂページにアクセスし、当該Ｗｅｂページに表示された情報（例えば、テキストデータ）をイベント発生情報として取得する。

監視部２１１は、取得されたイベント発生情報に基づいて、監視対象のイベントが発生しているか否かを判定する（ステップＳ１９０５）。すなわち、第１イベントが発生したか否かが判定される。例えば、以下のような処理が実行される。

監視部２１１は、Ｗｅｂページが更新されているか否かを判定する。例えば、監視部２１１は、前回のイベント発生情報の更新日時を履歴情報として保持し、新たに取得したイベント発生情報の更新日時と履歴情報とを比較し、Ｗｅｂページが更新されているか否かを判定する。

Ｗｅｂページが更新されていると判定された場合、監視部２１１は、イベント種別情報２２１を参照して、イベント種別ＩＤ４０１がイベント監視対象情報２２２から選択されたレコードのイベント種別ＩＤに一致するレコードを検索する。監視部２１１は、イベント種別情報２２１から検索されたレコードのイベント種別名４０２に対応するイベントがイベント発生情報に含まれるか否かを判定する。例えば、監視部２１１は、イベント種別名４０２に設定された文字がテキストデータに含まれるか否かを判定する。

なお、前述の処理は一例であって、これに限定されない。以上がステップＳ１９０５の処理の説明である。

監視対象のイベントが発生していないと判定された場合、監視部２１１は、イベント監視対象情報２２２の全てのレコードについて処理が完了したか否かを判定する（ステップＳ１９０９）。

イベント監視対象情報２２２の全てのレコードについて処理が完了していないと判定された場合、監視部２１１は、ステップＳ１９０３に戻り、イベント監視対象情報２２２から新たなレコードを選択し、ステップＳ１９０４からステップＳ１９０８までの処理を実行する。

イベント監視対象情報２２２の全てのレコードについて処理が完了したと判定された場合、監視部２１１は、第１ループ処理を終了する。その後、監視部２１１は、ステップＳ１９０２に戻り、同様の処理を実行する。

ステップＳ１９０５において、監視対象のイベントが発生していると判定された場合、監視部２１１は、イベント発生情報から第１イベントの発生場所及び発生日時を取得し、また、イベント発生情報に基づいて第２イベントの予測日時を算出する（ステップＳ１９０６）。

第２イベントの予測日時の算出方法は、様々な方法が考えられる。例えば、イベント発生情報に第２イベントの発生日時が含まれる場合、監視部２１１は、当該発生日時を第２イベントの予測日時として算出する。他の方法としては、監視部２１１は、第１イベントの発生日時に所定の時間を加算することによって、第２イベントの予測日時を算出する。なお、本実施例は、第２イベントの予測日時の算出方法に限定されない。

次に、監視部２１１は、第１イベントの発生場所に基づいて場所管理情報２２４を参照し、発生場所の識別情報を取得する（ステップＳ１９０７）。

具体的には、監視部２１１は、イベント監視対象ＩＤ７０２がイベント監視対象情報２２２から選択されたレコードのイベント監視対象ＩＤに一致し、かつ、場所７０３が第１イベントの発生場所に一致するレコードを検索し、検索されたレコードの場所ＩＤ７０１の値を取得する。

次に、監視部２１１は、イベント情報２２６を更新する（ステップＳ１９０８）。その後、監視部２１１は、ステップＳ１９０９に進む。具体的には、以下のような処理が実行される。

監視部２１１は、イベント情報２２６にレコードを一つ追加し、追加されたレコードのイベントＩＤ９０１に識別情報を設定する。なお、監視部２１１は、採番機能を有し、当該採番機能に基づいて、他のレコードと重複しないように識別情報を設定する。

監視部２１１は、追加されたレコードのイベント種別ＩＤ９０２及びイベント監視対象ＩＤ９０３に、イベント監視対象情報２２２から選択されたレコードのイベント種別ＩＤ及びイベント監視対象ＩＤを設定する。

また、監視部２１１は、追加されたレコードの場所ＩＤ９０４に、場所管理情報２２４から取得された場所ＩＤを設定する。さらに、監視部２１１は、追加されたレコードの発生日時９０５にイベント発生情報から取得された第１イベントの発生日時を設定し、追加されたレコードの次イベント予測日時９０６に算出された第２イベントの予測日時を設定する。以上が、ステップＳ１９０８の処理の説明である。

図２０は、実施例１のイベント分析サーバ１０２のイベント分析部２１２が実行する処理を説明するフローチャートである。

なお、本実施例のイベント分析部２１２は、イベント情報２２６の更新日時を更新履歴として管理しているものとする。

イベント分析サーバ１０２は、起動後、イベント分析部２１２を実現するプログラムをメモリ２０２にロードし、実行する。これによって、イベント分析部２１２は、処理を開始する（ステップＳ２００１）。

イベント分析部２１２は、プログラムの終了指示を受け付けたか否かを判定する（ステップＳ２００２）。

プログラムの終了指示を受け付けたと判定された場合、イベント分析部２１２は、処理を終了する（ステップＳ２０１２）。

プログラムの終了指示を受け付けていないと判定された場合、イベント分析部２１２は、イベント情報２２６を参照し（ステップＳ２００３）、イベント情報２２６が更新されているか否かを判定する（ステップＳ２００４）。なお、イベント分析部２１２は、周期的にイベント情報２２６を参照する場合、前回、イベント情報２２６を参照してから一定時間経過した後にイベント情報２２６を参照する。

具体的には、イベント分析部２１２は、現在のイベント情報２２６の更新日時と更新履歴とを比較することによって、イベント情報２２６が更新されているか否かを判定する。このとき、イベント分析部２１２は、現在のイベント情報２２６の更新日時を更新履歴に設定する。

イベント情報２２６が更新されていないと判定された場合、イベント分析部２１２は、ステップＳ２００２に戻り、同様の処理を実行する。

イベント情報２２６が更新されていると判定された場合、イベント分析部２１２は、第１ループ処理を開始する（ステップＳ２００５）。このとき、イベント分析部２１２は、イベント情報２２６からレコードを一つ選択し、選択されたレコードについてステップＳ２００６からステップＳ２０１０までの処理を実行する。

イベント分析部２１２は、イベント情報２２６から選択されたレコードの値を取得し、イベント情報２２６から選択されたレコードを削除する（ステップＳ２００６）。具体的には、以下のような処理が実行される。

イベント分析部２１２は、選択されたレコードに含まれる全てのカラムの値を取得する。すなわち、イベントＩＤ、イベント種別ＩＤ、イベント監視対象ＩＤ、場所ＩＤ、発生日時、及び次イベント予測日時が取得される。

また、イベント分析部２１２は、イベント種別情報２２１を参照し、イベント種別ＩＤ４０１がイベント情報２２６から選択されたレコードのイベント種別ＩＤに一致するレコードを検索する。イベント分析部２１２は、検索されたレコードの影響度４０３の値を取得する。以上がステップＳ２００６の処理の説明である。

次に、イベント分析部２１２は、サービス情報２２５を参照し、第２イベントの影響を受ける仮想ネットワークサービスを特定する（ステップＳ２００７）。

具体的には、イベント分析部２１２は、サービス情報２２５を参照し、場所リスト８０３に、イベント情報２２６から選択されたレコードの場所ＩＤを含むレコードを検索する。イベント分析部２１２は、検索されたレコードのサービスＩＤ８０１の値を取得する。取得されたサービスＩＤに対応する仮想ネットワークサービスが第２イベントの影響を受ける仮想ネットワークサービスとなる。

次に、イベント分析部２１２は、第２ループ処理を開始する（ステップＳ２００８）。このとき、イベント分析部２１２は、ステップＳ２００７において取得したサービスＩＤの中から、対象のサービスＩＤを一つ選択する。イベント分析部２１２は、選択されたサービスＩＤに対してステップＳ２０１０の処理を実行する。

イベント分析部２１２は、選択されたサービスＩＤに対して、オーケストレーション設定情報２２７の更新処理を実行する（ステップＳ２００９）。これによって、第２イベントの影響を受ける仮想ネットワークサービスに対するスケーリングに必要な設定情報が生成される。当該処理の詳細は、図２１を用いて説明する。

オーケストレーション設定情報２２７の更新処理が終了した後、イベント分析部２１２は、ステップＳ２００７において特定された全ての仮想ネットワークサービスについて処理が完了したか否かを判定する（ステップＳ２０１０）。

ステップＳ２００７において特定された全ての仮想ネットワークサービスについて処理が完了していないと判定された場合、イベント分析部２１２は、ステップＳ２００８に戻り、新たなサービスＩＤを選択し、ステップＳ２００９の処理を実行する。

ステップＳ２００７において特定された全ての仮想ネットワークサービスについて処理が完了したと判定された場合、イベント分析部２１２は、第２ループ処理を終了する。その後、イベント分析部２１２は、イベント情報２２６の全てのレコードについて処理が完了したか否かを判定する（ステップＳ２０１１）。

イベント情報２２６の全てのレコードについて処理が完了していないと判定された場合、イベント分析部２１２は、ステップＳ２００５に戻り、イベント情報２２６から新たなレコードを選択し、ステップＳ２００６からステップＳ２０１０までの処理を実行する。

イベント情報２２６の全てのレコードについて処理が完了したと判定された場合、イベント分析部２１２は、ステップＳ２００２に戻り、同様の処理を実行する。

図２１は、実施例１のイベント分析サーバ１０２のイベント分析部２１２が実行するオーケストレーション設定情報２２７の更新処理を説明するフローチャートである。

イベント分析部２１２は、次イベント予測日時、影響度、及びサービスＩＤを入力パラメータとして処理を開始する（ステップＳ２１０１）。なお、次イベント予測日時はイベント情報２２６から選択されたレコードから取得された値であり、影響度はイベント種別情報２２１から検索されたレコードから取得された値であり、サービスＩＤはステップＳ２００８において選択された値である。

イベント分析部２１２は、次イベント予測日時に基づいて実行日時を算出する（ステップＳ２１０２）。

具体的には、イベント分析部２１２は、次イベント予測日時から所定の時間前を実行日時として算出する。例えば、イベント分析部２１２は、次イベント予測日時の２時間前を実行日時として算出する。

次に、イベント分析部２１２は、影響を受けるテナントの使用リソース量を算出する（ステップＳ２１０３）。具体的には以下のような処理が実行される。

イベント分析部２１２は、サービスＩＤを含むリソース量の算出要求をオーケストレーションサーバ１０３に送信する。オーケストレーションサーバ１０３は、当該算出要求を受信した場合、以下の（１）、（２）、（３）の処理を実行する。

（１）オーケストレーションサーバ１０３は、影響を受けるテナントを特定する。具体的には、オーケストレーションサーバ１０３は、ネットワーク機能インスタンス情報３２６を参照し、インスタンスＩＤ１６０１が算出要求に含まれるサービスＩＤに一致するレコードを検索する。オーケストレーションサーバ１０３は、検索されたレコードのテナントＩＤ１６０４の値を取得する。取得されたテナントＩＤに対応するテナントが影響を受けるテナントとなる。

（２）オーケストレーションサーバ１０３は、特定されたテナントについて、テナントを構成するＶＭが稼働するハイパバイザのリソース量、当該ハイパバイザの使用リソース量、及び当該ハイパバイザの残りリソース量を算出する。なお、各リソース量の算出方法は以下の通りである。

（ハイパバイザのリソース量）
オーケストレーションサーバ１０３は、（１）において、ネットワーク機能インスタンス情報３２６から検索されたレコードの起動ハイパバイザリスト１６０５からハイパバイザＩＤを取得する。オーケストレーションサーバ１０３は、取得したハイパバイザＩＤの中から対象のハイパバイザＩＤを選択する。オーケストレーションサーバ１０３は、ハイパバイザ情報３２４を参照し、ハイパバイザＩＤ１４０１が選択されたハイパバイザＩＤに一致するレコードを検索する。オーケストレーションサーバ１０３は、検索されたレコードのＣＰＵコア数１４０３、メモリ容量１４０４、及びディスク容量１４０５の値を、ハイパバイザのリソース量として算出する。オーケストレーションサーバ１０３は、起動ハイパバイザリスト１６０５から取得された全てのテナントＩＤについて同様の処理を実行する。

（ハイパバイザの使用リソース量）
オーケストレーションサーバ１０３は、起動ハイパバイザリスト１６０５から取得されたハイパバイザＩＤの中から対象のハイパバイザＩＤを選択する。オーケストレーションサーバ１０３は、ネットワーク機能インスタンス情報３２６を参照し、起動ハイパバイザリスト１６０５に選択されたハイパバイザＩＤを含むレコードを検索する。オーケストレーションサーバ１０３は、検索された各レコードについて以下の処理を実行する。

オーケストレーションサーバ１０３は、検索されたレコードの中から対象のレコードを選択し、選択されたレコードのネットワーク機能ＩＤ１６０２及びパッケージＩＤ１６０３の値を取得する。オーケストレーションサーバ１０３は、パッケージ情報３２２を参照し、パッケージＩＤ１２０１及びネットワーク機能ＩＤ１２０２が取得したパッケージＩＤ及びネットワーク機能ＩＤに一致するレコードを検索する。オーケストレーションサーバ１０３は、検索されたレコードの仮想ＣＰＵコア数１２０３、メモリ容量１２０４、及びディスク容量１２０５の値を取得する。オーケストレーションサーバ１０３は、ネットワーク機能インスタンス情報３２６から検索された全てのレコードについて同様の処理を実行し、取得された値の合計値を選択されたハイパバイザＩＤに対応するハイパバイザの使用リソース量として算出する。

（ハイパバイザの残りリソース量）
オーケストレーションサーバ１０３は、ハイパバイザのリソース量からハイパバイザの使用リソース量を減算することによって、ハイパバイザの残りリソース量を算出する。以上が、リソース量の算出方法の説明である。

なお、リソース量はクラウド管理サーバ１０４によって管理されているため、イベント分析部２１２は、オーケストレーションサーバ１０３を介してクラウド管理サーバ１０４から各種リソース量を取得してもよい。

（３）オーケストレーションサーバ１０３は、サービスＩＤ、テナントＩＤ、ハイパバイザのリソース量、ハイパバイザの使用リソース量、及びハイパバイザの残りリソース量を含む応答をイベント分析サーバ１０２に送信する。以上がステップＳ２１０３の処理の説明である。

次に、イベント分析部２１２は、影響を受けるテナントの予測リソース量を算出する（ステップＳ２１０４）。

具体的には、イベント分析部２１２は、テナントを構成するＶＭが稼働するハイパバイザの使用リソース量に影響度を乗算することによって予測リソース量を算出する。なお、前述した算出方法は一例であってこれに限定されない。ハイパバイザのリソース量及び影響度を用いた算出方法であればよい。

なお、ユーザ数７０４を重みとして用いてもよい。これによって、より適切な予測リソース量を算出することができる。

次に、イベント分析部２１２は、影響を受けるテナントのスケーリング種別を決定する（ステップＳ２１０５）。ステップＳ２１０５の処理は、以下で説明するように、入力された影響度の大きさに応じて二通りの処理に分かれる。なお、以下で示す数式に用いるリソース量は、ＣＰＵコア数であるものとする。

影響度が「１」より大きい場合は以下のような処理が実行される。イベント分析部２１２は、各ハイパバイザの残りリソース量の合計値及び各ハイパバイザの使用リソース量の合計値を算出する。イベント分析部２１２は、式（１）及び式（２）のいずれを満たすかを判定する。式（１）を満たす場合、イベント分析部２１２は、スケーリング種別を「スケールアウト」に決定する。式（２）を満たす場合、イベント分析部２１２は、スケーリング種別を「スケールアップ」に決定する。

影響度が「１」より小さい場合は以下のような処理が実行される。イベント分析部２１２は、式（３）及び式（４）のいずれを満たすかを判定する。式（３）を満たす場合、イベント分析部２１２は、スケーリング種別を「スケールイン」に決定する。式（４）を満たす場合、イベント分析部２１２は、スケーリング種別を「スケールダウン」に決定する。

なお、前述した判定方法は一例であってこれに限定されない。

イベント分析部２１２は、スケーリング種別情報２２３を参照し、スケーリング種別６０２が決定されたスケーリング種別に一致するレコードを検索する。イベント分析部２１２は、検索されたレコードのスケーリング種別ＩＤ６０１の値を取得する。以上がステップＳ２１０５の処理の説明である。

次に、イベント分析部２１２は、影響を受けるテナントのスケーリングの規模を算出する（ステップＳ２１０６）。具体的には、以下のような処理が実行される。

スケーリング種別が「スケールアウト」である場合、イベント分析部２１２は、式（５）に基づいて規模を算出する。なお、予測リソース量の合計値は、各ハイパバイザの予測リソース量の合計値を表す。式（５）に基づいてテナントに追加するＶＭの数が規模として算出される。ここで、式（５）の（ＶＭのリソース量）は、テナントを構成するＶＭの仮想ＣＰＵコア数の最小を用いるものとする。なお、ＶＭの仮想ＣＰＵコア数の平均値を（ＶＭのリソース量）としてもよい。

スケーリング種別が「スケールアップ」である場合、イベント分析部２１２は、式（６）に基づいて規模を算出する。この場合、既存のＶＭに追加するリソース量が規模として算出される。

スケーリング種別が「スケールイン」である場合、イベント分析部２１２は、式（７）に基づいて規模を算出する。この場合、テナントから削除するＶＭの数が規模として算出される。ここで、（ＶＭのリソース量）は、式（５）の（ＶＭのリソース量）と同一のものである。

スケーリング種別が「スケールダウン」である場合、イベント分析部２１２は、式（８）に基づいて規模を算出する。この場合、既存のＶＭから削減するリソース量が規模として算出される。

なお、前述した算出方法は一例であってこれに限定されない。以上がステップＳ２１０６の処理の説明である。

次に、イベント分析部２１２は、オーケストレーション設定情報２２７を更新する（ステップＳ２１０７）。その後、イベント分析部２１２は、オーケストレーション設定情報の更新処理を終了する（ステップＳ２１０８）。ステップＳ２１０７では、以下のような処理が実行される。

イベント分析部２１２は、オーケストレーション設定情報２２７に、影響を受けるテナントの数だけレコードを追加する。本実施例では、一つの仮想ネットワークサービスは一つのテナントから構成されるため、オーケストレーション設定情報２２７には一つのレコードが追加される。イベント分析部２１２は、追加されたレコードのオーケストレーション設定ＩＤ１００１に識別情報を設定する。なお、イベント分析部２１２は、採番機能を有し、当該採番機能に基づいて、他のレコードと重複しないように識別情報を設定する。

イベント分析部２１２は、追加されたレコードの実行日時１００２にステップＳ２１０２において算出された実行日時を設定する。イベント分析部２１２は、追加されたレコードのサービスＩＤ１００５に入力パラメータであるサービスＩＤを設定する。また、イベント分析部２１２は、追加されたレコードのスケーリング種別ＩＤ１００３にステップＳ２１０５において決定されたスケーリング種別ＩＤを設定し、追加されたレコードの規模１００４にステップＳ２１０６において算出された規模を設定する。一つのレコードが一つの設定情報に対応する。

なお、イベント分析部２１２は、オーケストレーション設定情報２２７にテナントＩＤを設定してもよい。この場合、オーケストレーション設定情報２２７のレコードは、テナントＩＤのカラムを含む。以上がステップＳ２１０７の処理の説明である。

以上の処理によって、影響を受ける仮想ネットワークサービスに対するスケーリングの制御内容が決定される。これによって、第２イベントの発生前に適切なスケーリングを行うことができる。

図２２は、実施例１のイベント分析サーバ１０２のオーケストレーション設定部２１３が実行する処理を説明するフローチャートである。

なお、本実施例のオーケストレーション設定部２１３は、更新前のオーケストレーション設定情報２２７を更新履歴として管理しているものとする。

イベント分析サーバ１０２は、起動後、メモリ２０２にオーケストレーション設定部２１３を実現するプログラムをロードし、実行する。これによって、オーケストレーション設定部２１３は、処理を開始する（ステップＳ２２０１）。

オーケストレーション設定部２１３は、プログラムの終了指示を受け付けたか否かを判定する（ステップＳ２２０２）。

プログラムの終了指示を受け付けたと判定された場合、オーケストレーション設定部２１３は、処理を終了する（ステップＳ２２０８）。

プログラムの終了指示を受け付けていないと判定された場合、オーケストレーション設定部２１３は、オーケストレーション設定情報２２７を参照し（ステップＳ２２０３）、オーケストレーション設定情報２２７が更新されているか否かを判定する（ステップＳ２２０４）。なお、周期的にオーケストレーション設定情報２２７を参照する場合、オーケストレーション設定部２１３は、前回、オーケストレーション設定情報２２７を参照してから一定時間経過した後にオーケストレーション設定情報２２７を参照する。

具体的には、オーケストレーション設定部２１３は、現在のオーケストレーション設定情報２２７と更新履歴とを比較することによって、オーケストレーション設定情報２２７が更新されているか否かを判定する。

オーケストレーション設定情報２２７が更新されていないと判定された場合、オーケストレーション設定部２１３は、ステップＳ２２０２に戻り、同様の処理を実行する。

オーケストレーション設定情報２２７が更新されたと判定された場合、オーケストレーション設定部２１３は、第１ループ処理を開始する（ステップＳ２２０５）。このとき、オーケストレーション設定部２１３は、オーケストレーション設定情報２２７の更新されたレコードを特定し、特定されたレコードの中から対象のレコードを一つ選択し、選択されたレコードについてステップＳ２２０６の処理を実行する。

オーケストレーション設定部２１３は、オーケストレーションサーバ１０３に設定情報を送信する（ステップＳ２２０６）。

具体的には、オーケストレーション設定部２１３は、選択されたレコードの実行日時１００２、スケーリング種別ＩＤ１００３、規模１００４、及びサービスＩＤ１００５の値を取得し、オーケストレーションサーバ１０３に、設定情報として取得した値を送信する。なお、選択されたレコードにテナントＩＤが含まれる場合、テナントＩＤも送信される。

次に、オーケストレーション設定部２１３は、更新された全てのレコードについて処理が完了したか否かを判定する（ステップＳ２２０７）。

更新された全てのレコードについて処理が完了していないと判定された場合、オーケストレーション設定部２１３は、ステップＳ２２０５に戻り、新たなレコードを選択し、選択されたレコードに対してステップＳ２２０６の処理を実行する。

更新された全てのレコードについて処理が完了したと判定された場合、オーケストレーション設定部２１３は、第１ループ処理を終了する。このとき、オーケストレーション設定部２１３は、現在のオーケストレーション設定情報２２７を更新履歴に設定する。その後、オーケストレーション設定部２１３は、ステップＳ２２０２に戻り、同様の処理を実行する。

次に、図２３から図２６を用いてオーケストレーションサーバ１０３が実行する処理について説明する。以下の説明では、符号を含まないカラムの名称は、カラムから取得された値を表すものとする。例えば、シナリオＩＤは、シナリオ情報３２３に含まれるレコードのシナリオＩＤ１３０１の値を示す。

図２３は、実施例１のオーケストレーションサーバ１０３のスケジュール部３１１が実行する処理を説明するフローチャートである。

オーケストレーションサーバ１０３は、起動後、メモリ３０２にスケジュール部３１１を実現するプログラムをロードし、実行する。これによって、スケジュール部３１１は、処理を開始する（ステップＳ２３０１）。

スケジュール部３１１は、プログラムの終了指示を受け付けたか否かを判定する（ステップＳ２３０２）。

プログラムの終了指示を受け付けたと判定された場合、スケジュール部３１１は、処理を終了する（ステップＳ２３０６）。

プログラムの終了指示を受け付けていないと判定された場合、スケジュール部３１１は、イベント分析サーバ１０２から設定情報が送信されるまで待ち続ける。スケジュール部３１１は、設定情報を受信した場合（ステップＳ２３０３）、影響を受ける仮想ネットワークサービスのネットワーク機能、テナント、パッケージ、及びシナリオを特定する（ステップＳ２３０４）。具体的には、以下のような処理が実行される。

スケジュール部３１１は、ネットワーク機能インスタンス情報３２６を参照し、インスタンスＩＤ１６０１が設定情報に含まれるサービスＩＤと一致するレコードを検索する。スケジュール部３１１は、検索されたレコードのネットワーク機能ＩＤ１６０２、パッケージＩＤ１６０３、及びテナントＩＤ１６０４の値を取得する。なお、設定情報にテナントＩＤが含まれる場合、スケジュール部３１１は、テナントＩＤ１６０４から値を取得しなくてもよい。

スケジュール部３１１は、シナリオ情報３２３を参照し、スケーリング種別ＩＤ１３０２が設定情報に含まれるスケーリング種別ＩＤに一致し、かつ、ネットワーク機能ＩＤ１３０３がネットワーク機能インスタンス情報３２６から検索されたレコードのネットワーク機能ＩＤに一致するレコードを検索する。スケジュール部３１１は、検索されたレコードのシナリオＩＤ１３０１の値を取得する。以上がステップＳ２３０４の処理の説明である。

次に、スケジュール部３１１は、スケジュール情報３２７を更新する（ステップＳ２３０５）。その後、スケジュール部３１１は、ステップＳ２３０２に戻り、同様の処理を実行する。具体的には、以下のような処理が実行される。

スケジュール部３１１は、スケジュール情報３２７にレコードを一つ追加し、追加されたレコードのスケジュールＩＤ１７０１に識別情報を設定する。なお、スケジュール部３１１は、採番機能を有し、当該採番機能に基づいて、他のレコードと重複しないように識別情報を設定する。

スケジュール部３１１は、追加されたレコードのインスタンスＩＤ１７０２、実行日時１７０６、及び規模１７０７に、設定情報に含まれるサービスＩＤ、実行日時、及び規模を設定する。

また、スケジュール部３１１は、追加されたレコードのシナリオＩＤ１７０３、パッケージＩＤ１７０４、及びテナントＩＤ１７０５に、ステップＳ２３０５において取得したシナリオＩＤ、パッケージＩＤ、及びテナントＩＤを設定する。以上がステップＳ２３０６の処理の説明である。

図２４は、実施例１のオーケストレーションサーバ１０３のシナリオ登録部３１２が実行する処理を説明するフローチャートである。

オーケストレーションサーバ１０３は、起動後、メモリ３０２にシナリオ登録部３１２を実現するプログラムをロードし、実行する。これによって、シナリオ登録部３１２は、処理を開始する（ステップＳ２４０１）。

シナリオ登録部３１２は、プログラムの終了指示を受け付けたか否かを判定する（ステップＳ２４０２）。

プログラムの終了指示を受け付けたと判定された場合、シナリオ登録部３１２は、処理を終了する（ステップＳ２４０８）。

プログラムの終了指示を受け付けていないと判定された場合、シナリオ登録部３１２は、第１ループ処理を開始する（ステップＳ２４０３）。このとき、シナリオ登録部３１２は、スケジュール情報３２７のレコードの中から対象のレコードを一つ選択し、選択されたレコードに対してステップＳ２４０４からステップＳ２４０６までの処理を実行する。なお、周期的に第１ループ処理が実行される場合、シナリオ登録部３１２は、前回の第１ループ処理が終了してから一定時間経過した後に第１ループ処理を開始する。

次に、シナリオ登録部３１２は、現在時刻が実行日時を経過しているか否かを判定する（ステップＳ２４０４）。

具体的には、シナリオ登録部３１２は、スケジュール情報３２７から選択されたレコードの実行日時１７０６と現在時刻とを比較し、現在時刻が実行日時を経過しているか否かを判定する。

現在時刻が実行日時を経過していないと判定された場合、シナリオ登録部３１２は、スケジュール情報３２７の全てのレコードについて処理が完了したか否かを判定する（ステップＳ２４０７）。

スケジュール情報３２７の全てのレコードについて処理が完了していないと判定された場合、シナリオ登録部３１２は、ステップＳ２４０３に戻り、スケジュール情報３２７から新たなレコードを選択し、選択されたレコードに対してステップＳ２４０４からステップＳ２４０６の処理を実行する。

スケジュール情報３２７の全てのレコードについて処理が完了したと判定された場合、シナリオ登録部３１２は、ステップＳ２４０２に戻り、同様の処理を実行する。

ステップＳ２４０４において、現在時刻が実行日時を経過していると判定された場合、シナリオ登録部３１２は、実行中シナリオ情報３２８を更新する（ステップＳ２４０５）。具体的には、以下のような処理が実行される。

シナリオ登録部３１２は、実行中シナリオ情報３２８にレコードを一つ追加し、追加されたレコードの実行中シナリオＩＤ１８０１に識別情報を設定する。なお、シナリオ登録部３１２は、採番機能を有し、当該採番機能に基づいて、他のレコードと重複しないように識別情報を設定する。

シナリオ登録部３１２は、追加されたレコードのインスタンスＩＤ１８０２、シナリオＩＤ１８０３、パッケージＩＤ１８０４、テナントＩＤ１８０５、及び規模１８０６に、スケジュール情報３２７から選択されたレコードのインスタンスＩＤ、シナリオＩＤ、パッケージＩＤ、テナントＩＤ、及び規模を設定する。以上がステップＳ２４０５の処理の説明である。

次に、シナリオ登録部３１２は、スケジュール情報３２７から選択されたレコードを削除する（ステップＳ２４０６）。その後、シナリオ登録部３１２は、ステップＳ２４０７に進む。

図２５は、実施例１のオーケストレーションサーバ１０３のオーケストレーション実行部３１３が実行する処理を説明するフローチャートである。

なお、本実施例のオーケストレーション実行部３１３は、実行中シナリオ情報３２８の更新日時を更新履歴として管理しているものとする。

オーケストレーションサーバ１０３は、起動後、メモリ３０２にオーケストレーション実行部３１３を実現するプログラムをロードし、実行する。これによって、オーケストレーション実行部３１３は、処理を開始する（ステップＳ２５０１）。

オーケストレーション実行部３１３は、プログラムの終了指示を受け付けたか否かを判定する（ステップＳ２５０２）。

プログラムの終了指示を受け付けたと判定された場合、オーケストレーション実行部３１３は、処理を終了する（ステップＳ２５１０）。

プログラムの終了指示を受け付けていないと判定された場合、オーケストレーション実行部３１３は、実行中シナリオ情報３２８を参照し（ステップＳ２５０３）、実行中シナリオ情報３２８が更新されているか否かを判定する（ステップＳ２５０４）。なお、周期的に実行中シナリオ情報３２８を参照する場合、オーケストレーション実行部３１３は、前回、実行中シナリオ情報３２８を参照してから一定時間経過した後に実行中シナリオ情報３２８を参照する。

具体的には、オーケストレーション実行部３１３は、現在の実行中シナリオ情報３２８の更新日時と更新履歴とを比較することによって、実行中シナリオ情報３２８が更新されているか否かを判定する。このとき、オーケストレーション実行部３１３は、現在の実行中シナリオ情報３２８の更新日時を更新履歴に設定する。

実行中シナリオ情報３２８が更新されていないと判定された場合、オーケストレーション実行部３１３は、ステップＳ２５０２に戻り、同様の処理を実行する。

実行中シナリオ情報３２８が更新されたと判定された場合、オーケストレーション実行部３１３は、第１ループ処理を開始する（ステップＳ２５０５）。このとき、オーケストレーション実行部３１３は、実行中シナリオ情報３２８の更新されたレコードを特定し、特定されたレコードの中から対象のレコードを一つ選択し、選択されたレコードについてステップＳ２５０６からステップＳ２５０８までの処理を実行する。

次に、オーケストレーション実行部３１３は、シナリオ情報３２３からシナリオを取得する（ステップＳ２５０６）。

具体的には、オーケストレーション実行部３１３は、シナリオＩＤ１３０１が実行中シナリオ情報３２８から選択したレコードのシナリオＩＤと一致するレコードを検索し、検索されたレコードのシナリオ１３０４からシナリオを取得する。

次に、オーケストレーション実行部３１３は、取得されたシナリオに基づいて、シナリオ処理を実行する（ステップＳ２５０７）。なお、インスタンスＩＤ、パッケージＩＤ、テナントＩＤ、及び規模は、シナリオ処理のパラメータとして扱われる。図２６を用いてシナリオ処理の一例を説明する。

オーケストレーション実行部３１３は、シナリオ処理の実行後、実行中シナリオ情報３２８から選択されたレコードを削除する（ステップＳ２５０８）。また、オーケストレーション実行部３１３は、更新された全てのレコードについて処理が完了したか否かを判定する（ステップＳ２５０９）。

更新された全てのレコードについて処理が完了していないと判定された場合、オーケストレーション実行部３１３は、ステップＳ２５０５に戻り、新たなレコードを選択し、選択されたレコードに対してステップＳ２５０６からステップＳ２５０８までの処理を実行する。

更新された全てのレコードについて処理が完了したと判定された場合、オーケストレーション実行部３１３は、第１ループ処理を終了する。その後、オーケストレーション実行部３１３は、ステップＳ２５０２に戻り、同様の処理を実行する。

図２６は、実施例１のオーケストレーションサーバ１０３のオーケストレーション実行部３１３が実行するシナリオ処理の一例を説明するフローチャートである。

ここでは、シナリオＩＤ１３０１が「２」である場合のシナリオ処理（スケールアウト処理）について説明する。

オーケストレーション実行部３１３は、シナリオを取得した後、シナリオ処理を開始する（ステップＳ２６０１）。まず、オーケストレーション実行部３１３は、インスタンスＩＤ、パッケージＩＤ、テナントＩＤ、及び規模を引数として受け取る（ステップＳ２６０２）。

次に、オーケストレーション実行部３１３は、スケールアウト処理に必要なリソース量を算出する（ステップＳ２６０３）。

具体的には、オーケストレーション実行部３１３は、パッケージ情報３２２を参照し、パッケージＩＤ１２０１が引数として受け取ったパッケージＩＤと一致するレコードを検索する。オーケストレーション実行部３１３は、検索されたレコードのネットワーク機能ＩＤ、仮想ＣＰＵコア数、メモリ容量、及びディスク容量を取得する。取得した値は、スケールアウト処理に必要なリソース量として算出される。

次に、オーケストレーション実行部３１３は、ネットワーク機能の起動イメージファイル名を取得する（ステップＳ２６０４）。

具体的には、オーケストレーション実行部３１３は、ネットワーク機能情報３２１を参照し、ネットワーク機能ＩＤ１１０１がパッケージ情報３２２から検索されたレコードのネットワーク機能ＩＤと一致するレコードを検索する。オーケストレーション実行部３１３は、検索されたレコードの起動イメージファイル１１０３から起動イメージファイルを取得する。

次に、オーケストレーション実行部３１３は、テナントを構成するＶＭが稼働するハイパバイザを特定する（ステップＳ２６０５）。

具体的には、オーケストレーション実行部３１３は、テナント情報３２５を参照し、テナントＩＤ１５０１が引数として受け取ったテナントＩＤと一致するレコードを検索する。オーケストレーション実行部３１３は、検索されたレコードのハイパバイザリスト１５０３からハイパバイザＩＤを取得する。

次に、オーケストレーション実行部３１３は、特定されたハイパバイザのリソース量を算出する（ステップＳ２６０６）。具体的には、以下のような処理が実行される。

オーケストレーション実行部３１３は、テナント情報３２５から取得されたハイパバイザＩＤの中から対象のハイパバイザＩＤを選択する。

オーケストレーション実行部３１３は、ハイパバイザ情報３２４を参照し、ハイパバイザＩＤ１４０１が選択されたハイパバイザＩＤに一致するレコードを検索する。オーケストレーション実行部３１３は、検索されたレコードのＣＰＵコア数、メモリ容量、及びディスク容量を取得する。取得された値は、ハイパバイザのリソース量として算出される。

オーケストレーション実行部３１３は、ハイパバイザリスト１５０３に含まれる全てのハイパバイザＩＤについて同様の処理を実行する。これによって、テナントに含まれるＶＭが稼働するハイパバイザのリソース量を把握できる。以上がステップＳ２６０６の処理の説明である。

次に、オーケストレーション実行部３１３は、ステップＳ２６０３において算出されたリソース量と、ステップＳ２６０６において算出されたリソース量とを比較し（ステップＳ２６０７）、スケールアウト処理に必要なリソース量が不足しているか否かを判定する（ステップＳ２６０８）。なお、リソース量に基づく判定処理は公知の技術であるため詳細な説明を省略する。

スケールアウト処理に必要なリソース量が不足していないと判定された場合、オーケストレーション実行部３１３は、起動イメージファイル、シナリオ、及び引数に基づいてスケールアウト処理を実行する（ステップＳ２６０９）。スケールアウト処理は、公知のものであるため詳細な説明は省略する。

オーケストレーション実行部３１３は、スケールアウト処理の実行後、処理を終了する（ステップＳ２６１０）。

ステップＳ２６０８において、スケールアウト処理に必要なリソース量が不足していると判定された場合、オーケストレーション実行部３１３は、エラーを出力し、処理を終了する（ステップＳ２６１１）。

以上で説明したように、イベント分析サーバ１０２は、第１イベントを検出した場合、第１イベントの後に発生する第２イベントの影響を受ける仮想ネットワークサービスを特定し、仮想ネットワークサービスを構成するテナント（ＶＭ）のリソース量を変更するためのスケーリングのパラメータ及び実行日時等を含む設定情報を生成する。第２イベントの発生前に、設定情報に基づくスケーリングが行われることによって、ネットワーク機能の処理性能の低下等を回避することができる。

また、突発的な通信量の増加に備えて、予め、余分なリソースを確保する必要がないため、システムの運用にかかるコストの増加を抑えることができる。

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

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

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

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

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

１０１ クライアント端末
１０２ イベント分析サーバ
１０３ オーケストレーションサーバ
１０４ クラウド管理サーバ
１０５ イベント情報サーバ
１０６ 計算サーバ
１０７ サービスＳＷ
１０８ ＩｏＴ ＧＷ
１０９ センサノード
１１０ インターネット
１１１ 外部ＮＷ
２０１、３０１ ＣＰＵ
２０２、３０２ メモリ
２０３、３０３ ネットワークＩＦ
２１１ 監視部
２１２ イベント分析部
２１３ オーケストレーション設定部
２２１ イベント種別情報
２２２ イベント監視対象情報
２２３ スケーリング種別情報
２２４ 場所管理情報
２２５ サービス情報
２２６ イベント情報
２２７ オーケストレーション設定情報
３１１ スケジュール部
３１２ シナリオ登録部
３１３ オーケストレーション実行部
３２１ ネットワーク機能情報
３２２ パッケージ情報
３２３ シナリオ情報
３２４ ハイパバイザ情報
３２５ テナント情報
３２６ ネットワーク機能インスタンス情報
３２７ スケジュール情報
３２８ 実行中シナリオ情報

Claims (10)

1. ネットワークサービスを構成する業務システムにリソースを提供する複数の第１システム及び前記複数の第１システムを管理する第２システムを含む計算機システムであって、
   前記複数の第１システムの各々は、複数の第１計算機を含み、
   前記第２システムは、少なくとも一つの第２計算機を含み、
   前記第１システムには、異なるネットワークサービスを提供する業務システムが構築され、
   前記業務システムは、前記第１計算機のリソースを用いて生成され、かつ、ネットワーク機能を有する仮想計算機を含み、
   前記複数の第１計算機は、前記仮想計算機を管理する仮想化制御部を含み、
   前記少なくとも一つの第２計算機は、前記業務システムに割り当てるリソース量を制御するためのスケーリングを実行するリソース管理部と、前記ネットワークサービスに影響を与えるイベントの発生を監視する監視部と、を含み、
   前記監視部は、
   第１イベントの発生を検出した場合、前記第１イベントの後に発生する第２イベントの発生予測日時を算出し、
   前記第２イベントの影響を受けるネットワークサービスを特定し、
   前記特定されたネットワークサービスを構成する業務システムに対する前記スケーリングの種別、前記スケーリングによって変更される業務システムのリソース量を表す変更リソース量、及び前記スケーリングの実行日時を含む設定情報を生成することを特徴とする計算機システム。
2. 請求項１に記載の計算機システムであって、
   前記監視部は、
   前記第１イベントの識別情報及び前記第２イベントによって受ける影響の大きさを示す影響度から構成されるレコードを含むイベント種別情報を管理し、
   前記第２イベントの発生予測日時に基づいて、前記スケーリングの実行日時を算出し、
   前記特定されたネットワークサービスを構成する業務システムを特定し、
   前記特定された業務システムの使用リソース量及び前記影響度に基づいて、前記特定された業務システムの予測リソース量を算出し、
   前記特定された業務システムの使用リソース量及び前記特定された業務システムの予測リソース量に基づいて、前記スケーリングの種別を決定し、
   前記特定された業務システムの使用リソース量、前記特定された業務システムの予測リソース量、及び前記スケーリングの種別に基づいて、前記変更リソース量を算出することを特徴とする計算機システム。
3. 請求項２に記載の計算機システムであって、
   前記監視部は、前記ネットワークサービスの識別情報及び前記ネットワークサービスを構成する業務システムが構築された前記第１システムの場所を示す識別情報から構成されるレコードを含むサービス情報を管理し、
   前記リソース管理部は、前記ネットワークサービスの識別情報及び前記ネットワークサービスを構成する業務システムの識別情報から構成されるレコードを含むインスタンス情報を管理し、
   前記監視部は、
   前記第１イベントが発生した場所を特定し、
   前記第１イベントが発生した場所に基づいて前記サービス情報を参照して、前記第２イベントの影響を受けるネットワークサービスの識別情報を取得し、
   前記リソース管理部を介して前記インスタンス情報を参照することによって、前記取得されたネットワークサービスの識別情報に一致する業務システムを特定することを特徴とする計算機システム。
4. 請求項３に記載の計算機システムであって、
   前記監視部は、
   イベントが発生する監視対象にアクセスするための情報を含む監視対象情報を管理し、
   前記監視対象情報に基づいて、前記監視対象にアクセスすることによって前記第１イベントが発生しているか否かを判定することを特徴とする計算機システム。
5. 請求項２に記載の計算機システムであって、
   前記監視部は、前記第１イベントの発生日時に基づいて、前記第２イベントの発生予測日時を算出することを特徴とする計算機システム。
6. ネットワークサービスを構成する業務システムにリソースを提供する複数の第１システム及び前記複数の第１システムを管理する第２システムを含む計算機システムにおけるリソース制御方法であって、
   前記複数の第１システムの各々は、複数の第１計算機を含み、
   前記第２システムは、少なくとも一つの第２計算機を含み、
   前記第１システムには、異なるネットワークサービスを提供する業務システムが構築され、
   前記業務システムは、前記第１計算機のリソースを用いて生成され、かつ、ネットワーク機能を有する仮想計算機を含み、
   前記複数の第１計算機は、前記仮想計算機を管理する仮想化制御部を含み、
   前記少なくとも一つの第２計算機は、前記業務システムに割り当てるリソース量を制御するためのスケーリングを実行するリソース管理部と、前記ネットワークサービスに影響を与えるイベントの発生を監視する監視部と、を含み、
   前記リソース制御方法は、
   前記監視部が、第１イベントの発生を検出した場合、前記第１イベントの後に発生する第２イベントの発生予測日時を算出する第１のステップと、
   前記監視部が、前記第２イベントの影響を受けるネットワークサービスを特定する第２のステップと、
   前記監視部が、前記特定されたネットワークサービスを構成する業務システムに対する前記スケーリングの種別、前記スケーリングによって変更される業務システムのリソース量を表す変更リソース量、及び前記スケーリングの実行日時を含む設定情報を生成する第３のステップと、を含むことを特徴とするリソース制御方法。
7. 請求項６に記載のリソース制御方法であって、
   前記監視部は、前記第１イベントの識別情報及び前記第２イベントによって受ける影響の大きさを示す影響度から構成されるレコードを含むイベント種別情報を管理し、
   前記第３のステップは、
   前記監視部が、前記第２イベントの発生予測日時に基づいて、前記スケーリングの実行日時を算出する第４のステップと、
   前記監視部が、前記特定されたネットワークサービスを構成する業務システムを特定する第５のステップと、
   前記監視部が、前記特定された業務システムの使用リソース量及び前記影響度に基づいて、前記特定された業務システムの予測リソース量を算出する第６のステップと、
   前記監視部が、前記特定された業務システムの使用リソース量及び前記特定された業務システムの予測リソース量に基づいて、前記スケーリングの種別を決定する第７のステップと、
   前記監視部が、前記特定された業務システムの使用リソース量、前記特定された業務システムの予測リソース量、及び前記スケーリングの種別に基づいて、前記変更リソース量を算出する第８のステップと、を含むことを特徴とするリソース制御方法。
8. 請求項７に記載のリソース制御方法であって、
   前記監視部は、前記ネットワークサービスの識別情報及び前記ネットワークサービスを構成する業務システムが構築された前記第１システムの場所を示す識別情報から構成されるレコードを含むサービス情報を管理し、
   前記リソース管理部は、前記ネットワークサービスの識別情報及び前記ネットワークサービスを構成する業務システムの識別情報から構成されるレコードを含むインスタンス情報を管理し、
   前記第１のステップは、前記監視部が、前記第１イベントが発生した場所を特定するステップを含み、
   前記第２のステップは、前記監視部が、前記第１イベントが発生した場所に基づいて前記サービス情報を参照して、前記第２イベントの影響を受けるネットワークサービスの識別情報を取得するステップを含み、
   前記第５のステップは、前記監視部が、前記リソース管理部を介して前記インスタンス情報を参照することによって、前記取得されたネットワークサービスの識別情報に一致する業務システムを特定するステップを含むことを特徴とするリソース制御方法。
9. 請求項８に記載のリソース制御方法であって、
   前記監視部は、イベントが発生する監視対象にアクセスするための情報を含む監視対象情報を管理し、
   前記第１のステップは、前記監視部が、前記監視対象情報に基づいて、前記監視対象にアクセスすることによって前記第１イベントが発生しているか否かを判定するステップを含むことを特徴とするリソース制御方法。
10. 請求項７に記載のリソース制御方法であって、
    前記第１のステップは、前記監視部が、前記第１イベントの発生日時に基づいて、前記第２イベントの発生予測日時を算出するステップを含むことを特徴とするリソース制御方法。

Images