JP6960444B2 - 計算機システム及びリソース管理方法 - Google Patents

Description

本発明は、マイクロサービスにおけるリソースの割当の管理方法に関する。

近年、複数のサービスを組み合わせて任意の機能を実現するシステム（マイクロサービス）の利用が広がっている。一般的に、サービスはコンテナ技術を用いて実現されている。コンテナ技術は、一つの物理計算機のリソースを利用して複数のアプリケーションを稼働させる仮想化技術の一つであり、一つの物理計算機で稼働するＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）上に隔離されたアプリケーションの実行環境を提供する技術である。本明細書では、隔離されたアプリケーションの実行環境をコンテナと記載する。コンテナは軽量かつ起動が高速という特徴を有する。

マイクロサービスでは、コンテナの特徴を利用して、サービスの負荷に応じてコンテナの数を調整することによって、負荷の分散及びリソースの効率的な利用を実現している。

物理計算機のリソースを利用して複数のアプリケーションを実行するシステムにおいて、負荷に応じてリソースの割当てを変更する技術として特許文献１及び特許文献２に記載の技術が知られている。

特許文献１には、「コンピュータプログラムは、複数の処理を負荷分散して実行する処理ノードの数を変更可能なコンピュータシステムに、第１の処理の負荷を監視させる。そして、コンピュータプログラムは、このコンピュータシステムに、第１の処理の負荷が第１の条件を超えるときに、第１の処理に関係する第２の処理を実行する処理プログラムを第２の処理を実行するために増加される処理ノードにネットワークを通じて転送することを実行させる。」ことが記載されている。

特許文献２には、「負荷情報収集部は、物理サーバと仮想サーバの負荷を収集して、各負荷を採取した時間に対応づけて、負荷情報として負荷情報テーブルに格納し、類似負荷情報選択部は、管理対象の負荷がスケールアウト閾値またはスケールイン閾値から外れたときに、現在時刻の負荷に類似する過去の負荷情報を負荷情報テーブルから選択し、スケールアウト判断部またはスケールイン判断部は、選択された負荷情報に従って管理対象の負荷が変化すると仮定して、管理対象の負荷が、その後も、いずれかの閾値から外れると予測したときには、スケールアウトまたはスケールインを実行する。」ことが記載されている。

特開２０１７−２１９９７２号公報 特開２０１１−１１８５２５号公報

特許文献１の記載の技術では、負荷の増大を契機に処理ノードが追加されているため、サービスへの影響が顕在化する前にスケールアウト等の対処（サービスに対するリソースの割当量の変更）ができない。特許文献２に記載の技術では、過去の負荷に関する履歴に基づいて負荷を予測しているため、突発的な負荷の増大等、履歴に存在しない負荷変動に対応できない。

本発明では、様々な状況下において、サービスへの影響が顕在化する前に、サービスに対するリソースの割当量を変更するための技術を提供する。

本願において開示される発明の代表的な一例を示せば以下の通りである。すなわち、演算装置、前記演算装置に接続される記憶装置、及び前記演算装置に接続され、外部装置に接続するための接続装置を有する、複数の計算機を備える計算機システムであって、少なくとも一つの前記計算機を含み、リクエストに対応する機能を提供する複数のサービスが稼働する業務システムを含み、前記サービスに対する前記業務システムのリソースの割当量を変更するためのスケジュールを生成する制御部と、前記スケジュールに基づいて、前記サービスに対する前記リソースの割当量を変更する割当変更部と、を備え、前記制御部は、処理を開始するためのリクエストの受付を検知した場合、前記検知されたリクエストの受付数を算出し、前記検知されたリクエストの受付を契機に実行される関連サービスを特定し、前記検知されたリクエストの受付数に基づいて、前記関連サービスの負荷を示す指標の予測値を算出し、前記関連サービスの前記指標の予測値に基づいて、前記リソースの割当量を変更する必要がある前記関連サービスを決定し、前記決定された関連サービスの前記スケジュールを生成する。

本発明によれば、様々な状況下において、サービスへの影響が顕在化する前に、サービスに対するリソースの割当量を変更できる。上記した以外の課題、構成及び効果は、以下の実施例の説明により明らかにされる。

実施例１の計算機システムの構成例を示す図である。 実施例１のサーバのハードウェア構成の一例を示す図である。 実施例１の管理サーバのハードウェア構成の一例を示す図である。 実施例１のサービス構成管理情報のデータ構造の一例を示す図である。 実施例１のリクエスト経路管理情報のデータ構造の一例を示す図である。 実施例１のリクエスト負荷特徴情報のデータ構造の一例を示す図である。 実施例１のサービス負荷特徴情報のデータ構造の一例を示す図である。 実施例１の閾値管理情報のデータ構造の一例を示す図である。 実施例１の処理ノード性能情報のデータ構造の一例を示す図である。 実施例１のサーバ性能情報のデータ構造の一例を示す図である。 実施例１の検知リクエスト情報のデータ構造の一例を示す図である。 実施例１のサービス実行情報のデータ構造の一例を示す図である。 実施例１の管理サーバが実行する処理の概要を説明するフローチャートである。 実施例１の管理サーバによって生成されるターゲットリクエスト一覧のデータ構造の一例を示す図である。 実施例１の負荷予測部が実行するスケジュール生成処理の一例を説明するフローチャートである。 実施例１の負荷予測部が実行する負荷予測処理の一例を説明するフローチャートである。 実施例１の負荷予測部によって生成される予測値情報のデータ構造の一例を示す図である。 実施例１の負荷予測部が実行する最大使用量算出処理の一例を説明するフローチャートである。 実施例１の負荷予測部が実行する対処判定処理の一例を説明するフローチャートである。 実施例１の負荷予測部が実行するスケールアウトスケジュール生成処理の一例を説明するフローチャートである。 実施例１の負荷予測部によって生成されるスケールアウトスケジュール情報のデータ構造の一例を示す図である。 実施例１の負荷予測部が実行するスケールインスケジュール生成処理の一例を説明するフローチャートである。 実施例１の負荷予測部によって生成されるスケールインスケジュール情報のデータ構造の一例を示す図である。 実施例１の割当変更部が実行するリソース割当変更処理の一例を説明するフローチャートである。 実施例１の割当変更部が実行するスケールアウトの一例を説明するフローチャートである。 実施例１の割当変更部が実行するスケールインの一例を説明するフローチャートである。 実施例１の管理サーバ制御部が実行するリクエスト経路管理情報の更新処理の一例を説明するフローチャートである。 実施例１の管理サーバ制御部によって生成されるリクエスト関連マップのデータ構造の一例を示す図である。 実施例１の管理サーバ制御部が実行するサービス負荷特徴情報の更新処理の一例を説明するフローチャートである。 実施例１の管理サーバ制御部によって生成される負荷解析情報のデータ構造の一例を示す図である。

以下、本発明の実施例を、図面を用いて説明する。ただし、本発明は以下に示す実施例の記載内容に限定して解釈されるものではない。本発明の思想ないし趣旨から逸脱しない範囲で、その具体的構成を変更し得ることは当業者であれば容易に理解される。

以下に説明する発明の構成において、同一又は類似する構成又は機能には同一の符号を付し、重複する説明は省略する。

本明細書等における「第１」、「第２」、「第３」等の表記は、構成要素を識別するために付するものであり、必ずしも、数又は順序を限定するものではない。

図面等において示す各構成の位置、大きさ、形状、及び範囲等は、発明の理解を容易にするため、実際の位置、大きさ、形状、及び範囲等を表していない場合がある。したがって、本発明では、図面等に開示された位置、大きさ、形状、及び範囲等に限定されない。

図１は、実施例１の計算機システムの構成例を示す図である。図２Ａは、実施例１のサーバ１０３のハードウェア構成の一例を示す図である。図２Ｂは、実施例１の管理サーバ１００のハードウェア構成の一例を示す図である。

計算機システムは、管理サーバ１００、管理クライアント１０１、及び業務システム１０２を含む。管理サーバ１００、管理クライアント１０１、及び業務システム１０２は、ネットワーク１０４を介して互いに接続される。ネットワーク１０４は、ＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）及びＷＡＮ（Ｗｉｄｅ Ａｒｅａ Ｎｅｔｗｏｒｋ）等であり、接続方式は有線又は無線のいずれでもよい。

業務システム１０２は、リクエストに対応する任意の機能を提供するサービス群を実現するためのリソースを提供する基盤である。業務システム１０２は、複数のサーバ１０３を含む。なお、業務システム１０２は、ストレージシステム及びネットワークスイッチ等、図示しない装置を含んでもよい。

サーバ１０３は、任意のサービスを実行する処理ノード１４０を実現するためのリソースを提供する計算機である。処理ノード１４０は、例えば、コンテナ及び仮想計算機である。一つのサービスに対して一つ以上の処理ノード１４０が存在する。なお、複数のサーバ１０３に、同一のサービスを実行する処理ノード１４０が存在してもよい。

サーバ１０３は、プロセッサ２００、メモリ２０１、ネットワークインタフェース２０２、及びストレージ装置２０３を有する。各ハードウェアはバスを介して互いに接続される。

プロセッサ２００は、メモリ２０１に格納されるプログラムを実行する。プロセッサ２００がプログラムにしたがって処理を実行することによって、特定の機能を実現するモジュールとして動作する。以下の説明では、モジュールを主語に処理を説明する場合、プロセッサ２００が当該モジュールを実現するプログラムを実行していることを示す。

メモリ２０１は、プロセッサ２００が実行するプログラム及びプログラムが使用する情報を格納する。また、メモリ２０１はプログラムが一時的に使用するワークエリアを含む。

本実施例のメモリ２０１は情報収集部１４１を実現するプログラムを格納する。情報収集部１４１は、サーバ１０３及び処理ノード１４０の性能に関する情報、並びに、処理ノード１４０の処理状態等、各種情報を収集する。メモリ２０１には、ＯＳ及び処理ノード１４０を管理する仮想化部等を実現するプログラムも格納されるが省略している。

ストレージ装置２０３は、ＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）及びＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）等の記憶装置であり、データを永続的に保存する。

なお、メモリ２０１に格納されるプログラム及び情報は、ストレージ装置２０３に格納されてもよい。この場合、プロセッサ２００が、ストレージ装置２０３からプログラム及び情報を読み出し、メモリ２０１にロードする。

ネットワークインタフェース２０２は、外部の装置と通信するためのインタフェースである。

管理サーバ１００は、業務システム１０２を管理する計算機である。なお、複数の計算機を用いて管理サーバ１００が有する機能を実現してもよい。

管理サーバ１００は、プロセッサ２１０、メモリ２１１、ネットワークインタフェース２１２、入力デバイス２１３、及び出力デバイス２１４を有する。各ハードウェアはバスを介して互いに接続される。なお、管理サーバ１００は、ストレージ装置を有してもよい。

プロセッサ２１０、メモリ２１１、及びネットワークインタフェース２１２は、プロセッサ２００、メモリ２０１、及びネットワークインタフェース２０２と同一のものである。入力デバイス２１３は、キーボード、マウス、及びタッチパネル等、データを入力するための装置である。出力デバイス２１４は、ディスプレイ及びプリンタ等、データを出力するための装置である。

メモリ２１１は、管理サーバ制御部１１０、性能情報管理部１１１、リクエスト監視部１１２、負荷予測部１１３、及び割当変更部１１４を実現するプログラムを格納する。また、メモリ２１１は、管理情報群１２０及びログ情報群１２１を格納する。

管理情報群１２０は、後述する制御に必要な各種管理情報である。ログ情報群１２１は、業務システム１０２から取得された各種ログの情報である。

管理サーバ制御部１１０は、管理サーバ１００全体を制御する。性能情報管理部１１１は、サーバ１０３及び処理ノード１４０の性能に関する情報を管理する。

リクエスト監視部１１２は、業務システム１０２を用いて提供される、任意の機能を実現するサービス群の実行契機となるリクエストの受付を監視する。

負荷予測部１１３は、連続したリクエストの呼出しの起点となるリクエストの受付を契機に実行されるサービス群の負荷を予測し、任意のサービスに対するリソースの割当量を変更するためのスケジュールを生成する。本明細書では、連続したリクエストの呼出しの起点となるリクエストを起点リクエストと記載し、起点リクエストの受付を契機に実行されるサービスを関連サービスと記載する。

割当変更部１１４は、スケジュールに基づいて、任意のサービスに対するリソースの割当量を変更する。

なお、管理サーバ１００が有する各モジュールについては、複数のモジュールを一つのモジュールにまとめてもよいし、一つのモジュールを機能毎に複数のモジュールに分けてもよい。例えば、管理サーバ制御部１１０、性能情報管理部１１１、リクエスト監視部１１２、及び負荷予測部１１３をまとめて、制御部としてもよい。

管理クライアント１０１は、業務システム１０２を利用して、複数のサービスから構成される機能を実現するシステム（マイクロサービス）の運用及び管理を行う端末である。管理クライアント１０１のハードウェア構成は管理サーバ１００と同一であるため説明を省略する。

管理クライアント１０１のメモリには、Ｗｅｂブラウザ１３０及び管理クライアント制御部１３１を実現するプログラムが格納される。

次に、図３から図７を用いて管理情報群１２０に含まれる情報について説明する。

図３は、実施例１のサービス構成管理情報３００のデータ構造の一例を示す図である。

サービス構成管理情報３００は、一つのリクエストに対応する機能を提供するサービスの構成を管理するための情報である。サービス構成管理情報３００は、リクエストＩＤ３０１、サービスＩＤ３０２、処理ノードＩＤ３０３、及びサーバＩＤ３０４を含むエントリを格納する。一つの処理ノード１４０に対して一つのエントリが存在する。

リクエストＩＤ３０１は、リクエストの識別情報を格納するフィールドである。サービスＩＤ３０２は、リクエストに対応する機能を提供するサービスの識別情報を格納するフィールドである。

処理ノードＩＤ３０３は、サービスを実行する処理ノード１４０の識別情報を格納するフィールドである。サーバＩＤ３０４は、処理ノード１４０を実現するためのリソースを提供するサーバ１０３の識別情報を格納するフィールドである。

図４は、実施例１のリクエスト経路管理情報４００のデータ構造の一例を示す図である。

リクエスト経路管理情報４００は、リクエストの呼出関係を管理するための情報である。リクエスト経路管理情報４００は、リクエストＩＤ４０１及びリクエスト経路４０２を含むエントリを格納する。一つの経路に対して一つのエントリが存在する。

リクエストＩＤ４０１は、起点リクエストの識別情報を格納するフィールドである。リクエスト経路４０２は、起点リクエストの後に呼び出されるリクエストの順番（経路）を示す情報を格納するフィールドである。

本明細書では、起点リクエストの後に呼び出されるリクエストを関連リクエストと記載する。

図５は、実施例１のリクエスト負荷特徴情報５００のデータ構造の一例を示す図である。

リクエスト負荷特徴情報５００は、起点リクエストの受付数から、関連リクエストの受付数を算出する場合に使用される情報である。リクエスト負荷特徴情報５００は、リクエストＩＤ５０１、関連リクエストＩＤ５０２、データ量５０３、及び関連データ量５０４を含むエントリを格納する。起点リクエスト、関連リクエスト、及び起点リクエストの受付数の組合せに対して一つのエントリが存在する。

リクエストＩＤ５０１は、起点リクエストの識別情報を格納するフィールドである。関連リクエストＩＤ５０２は、関連リクエストの識別情報を格納するフィールドである。

データ量５０３は、起点リクエストの受付数を格納するフィールドである。関連データ量５０４は、起点リクエストの受付数に対する関連リクエストの受付数を格納するフィールドである。

図６は、実施例１のサービス負荷特徴情報６００のデータ構造の一例を示す図である。

サービス負荷特徴情報６００は、サービスの負荷を算出する場合に使用される情報である。サービス負荷特徴情報６００は、リクエストＩＤ６０１、サービスＩＤ６０２、データ量６０３、メモリ最大使用量６０４、及び上昇率６０５を含むエントリを格納する。起点リクエスト、サービス、及び起点リクエストの受付数の組合せに対して一つのエントリが存在する。

リクエストＩＤ６０１は、リクエストの識別情報を格納するフィールドである。サービスＩＤ６０２は、リクエストに対応する機能を提供するサービスの識別情報を格納するフィールドである。

データ量６０３は、リクエストの受付数を格納するフィールドである。メモリ最大使用量６０４は、サービスの実行によって使用されるメモリ２０１の使用量を格納するフィールドである。本実施例では、説明の簡単のために、メモリ最大使用量６０４のみを含むエントリを記載しているが、エントリには、メモリ使用量以外のメトリックの最大使用量を格納するフィールドが含まれる。

上昇率６０５は、サービスの負荷の増大に伴うメトリックの値の単位時間あたりの増加量を示す上昇率を格納するフィールドである。

図７は、実施例１の閾値管理情報７００のデータ構造の一例を示す図である。

閾値管理情報７００は、判定処理に使用する各種閾値を管理するための情報である。閾値管理情報７００は、サービスＩＤ７０１、メトリック種別７０２、Ｗａｒｎｉｎｇ上限閾値７０３、Ｃｒｉｔｉｃａｌ上限閾値７０４、及び下限値７０５を含むエントリを格納する。サービス及びメトリックの組合せに対して一つのエントリが存在する。

サービスＩＤ７０１は、サービスの識別情報を格納するフィールドである。メトリック種別７０２は、メトリックの識別情報を格納するフィールドである。

Ｗａｒｎｉｎｇ上限閾値７０３は、スケールアウトの終了目標時点を規定するメトリックの値を格納するフィールドである。本実施例では、メトリックの値がＷａｒｎｉｎｇ上限閾値７０３より大きくなる前にスケールアウトが完了するようにスケジューリングが行われる。

Ｃｒｉｔｉｃａｌ上限閾値７０４は、スケールアウトを実行するか否かを判定するための閾値を格納するフィールドである。下限値７０５は、スケールインを実行するか否かを判定するための閾値を格納するフィールドである。

次に、図８から図１１を用いてログ情報群１２１に含まれる情報について説明する。

図８は、実施例１の処理ノード性能情報８００のデータ構造の一例を示す図である。

処理ノード性能情報８００は、サービスの実行時の処理ノード１４０の性能値の履歴を管理するための情報である。処理ノード性能情報８００は、時刻８０１、サービスＩＤ８０２、処理ノードＩＤ８０３、メトリック種別８０４、及び性能値８０５を含むエントリを格納する。時刻、サービス、処理ノード１４０、及びメトリックの組合せに対して一つのエントリが存在する。

時刻８０１は、性能値が計測された時刻を格納するフィールドである。サービスＩＤ８０２は、処理ノード１４０が実行するサービスの識別情報を格納するフィールドである。処理ノードＩＤ８０３は、処理ノード１４０の識別情報を格納するフィールドである。

メトリック種別８０４は、メトリックの識別情報を格納するフィールドである。性能値８０５は、計測された、処理ノード１４０のメトリックの性能値を格納するフィールドである。

図９は、実施例１のサーバ性能情報９００のデータ構造の一例を示す図である。

サーバ性能情報９００は、サーバ１０３の性能値の履歴を管理するための情報である。サーバ性能情報９００は、時刻９０１、サーバＩＤ９０２、ネットワークポート９０３、記憶装置ＩＤ９０４、メトリック種別９０５、及び性能値９０６を含むエントリを格納する。時刻、サーバ１０３、及びメトリックの性能値の組合せに対して一つのエントリが存在する。

時刻９０１は、性能値が計測された時刻を格納するフィールドである。サーバＩＤ９０２は、サーバ１０３の識別情報を格納するフィールドである。ネットワークポート９０３は、通信に用いるポートの番号を格納するフィールドである。記憶装置ＩＤ９０４、サーバ１０３が使用する記憶装置の識別情報を格納するフィールドである。

メトリック種別９０５は、メトリックの識別情報を格納するフィールドである。性能値９０６は、サーバ１０３のメトリックの計測値を格納するフィールドである。

図１０は、実施例１の検知リクエスト情報１０００のデータ構造の一例を示す図である。

検知リクエスト情報１０００は、受けつけたリクエストの履歴を管理するための情報である。検知リクエスト情報１０００は、時刻１００１及びリクエストＩＤ１００２を含むエントリを格納する。一つの検知結果に対して一つのエントリが存在する。

時刻１００１は、リクエストの受付が検知された時刻を格納するフィールドである。リクエストＩＤ１００２は、検知したリクエストの識別情報を格納するフィールドである。

図１１は、実施例１のサービス実行情報１１００のデータ構造の一例を示す図である。

サービス実行情報１１００は、リクエストを受けつけた場合に実行されたサービスの履歴を管理するための情報である。サービス実行情報１１００は、時刻１１０１、リクエストＩＤ１１０２、サービスＩＤ１１０３、及び処理ノードＩＤ１１０４を含むエントリを格納する。一つのサービスの実行結果に対して一つのエントリが存在する。

時刻１１０１は、サービスの実行が検知された時刻を格納するフィールドである。リクエストＩＤ１１０２は、リクエストの識別情報を格納するフィールドである。サービスＩＤ１１０３は、サービスの識別情報を格納するフィールドである。処理ノードＩＤ１１０４は、サービスを実行した処理ノード１４０の識別情報を格納するフィールドである。

なお、処理ノード性能情報８００及びサーバ性能情報９００は、情報収集部１４１から送信された情報に基づいて性能情報管理部１１１によって生成される。検知リクエスト情報１０００及びサービス実行情報１１００は、情報収集部１４１から送信された情報に基づいてリクエスト監視部１１２によって生成される。

次に、管理サーバ１００が実行する処理について説明する。

図１２は、実施例１の管理サーバ１００が実行する処理の概要を説明するフローチャートである。図１３は、実施例１の管理サーバ１００によって生成されるターゲットリクエスト一覧１３００のデータ構造の一例を示す図である。

リクエスト監視部１１２は、情報収集部１４１から受信した情報に基づいて、リクエストの受付を検知した場合（ステップＳ１０１）、管理サーバ制御部１１０に通知する。

なお、リクエスト監視部１１２は、ある機能を提供するサービス群の最初のサービスの実行を検知した場合、当該機能を呼び出すリクエストのエントリを検知リクエスト情報１０００に追加し、また、サービスの実行を検知した場合、当該サービスのエントリをサービス実行情報１１００に追加する。

次に、管理サーバ制御部１１０は、リクエスト経路管理情報４００を参照して、ターゲットリクエスト一覧１３００を生成する（ステップＳ１０２）。具体的には、以下のような処理が実行される。

管理サーバ制御部１１０は、リクエストＩＤ４０１に検知したリクエストの識別情報が格納されるエントリを検索する。管理サーバ制御部１１０は、検索されたエントリのリクエスト経路４０２に基づいて関連リクエストを特定する。

管理サーバ制御部１１０は、検知したリクエスト（起点リクエスト）及び関連リクエストをターゲットリクエストとしてターゲットリクエスト一覧１３００に登録する。なお、リクエストの呼出順にエントリが登録される。ターゲットリクエスト一覧１３００はリクエストＩＤ１３０１を含むエントリを格納する。

なお、リクエスト経路管理情報４００に該当するエントリが存在しない場合、管理サーバ制御部１１０は、ステップＳ１０３以降の処理を実行せずに、処理を終了する。これは、受けつけたリクエストが関連リクエストであり、すでに、スケジュールが生成されているためである。以上がステップＳ１０２の処理の説明である。

次に、管理サーバ制御部１１０は、ターゲットリクエストのループ処理を開始する（ステップＳ１０３）。

具体的には、管理サーバ制御部１１０は、ターゲットリクエスト一覧１３００からターゲットリクエストを一つ選択する。

次に、管理サーバ制御部１１０は、負荷予測部１１３にスケジュール生成処理の実行を指示する（ステップＳ１０４）。スケジュール生成処理の詳細は図１４を用いて説明する。

管理サーバ制御部１１０は、スケジュール生成処理の完了を検知した後、割当変更部１１４にリソース割当変更処理の実行を指示する（ステップＳ１０５）。リソース割当変更処理の詳細は図２３を用いて説明する。

リソース割当変更処理の完了を検知した後、管理サーバ制御部１１０は、ターゲットリクエスト一覧１３００の全てのターゲットリクエストについて処理が完了したか否かを判定する（ステップＳ１０６）。

ターゲットリクエスト一覧１３００の全てのターゲットリクエストについて処理が完了していない場合、管理サーバ制御部１１０は、ステップＳ１０３に戻り、同様の処理を実行する。

ターゲットリクエスト一覧１３００の全てのターゲットリクエストについて処理が完了した場合、管理サーバ制御部１１０は処理を終了する。

図１４は、実施例１の負荷予測部１１３が実行するスケジュール生成処理の一例を説明するフローチャートである。

まず、負荷予測部１１３は、ターゲットリクエストの受付数を算出する（ステップＳ２０１）。具体的には、以下のような処理が実行される。

負荷予測部１１３は、ターゲットリクエストが起点リクエストであるか否かを判定する。

ターゲットリクエストが起点リクエストである場合、負荷予測部１１３は、検知リクエスト情報１０００に基づいて、起点リクエストを検知してから一定時間において受けつけた起点リクエストの数を算出する。

ターゲットリクエストが関連リクエストである場合、負荷予測部１１３は、リクエスト負荷特徴情報５００を参照し、リクエストＩＤ５０１に起点リクエストの識別情報が格納され、かつ、関連リクエストＩＤ５０２にターゲットリクエストの識別情報が格納されるエントリを検索する。負荷予測部１１３は、起点リクエストの受付数及び検索されたエントリのデータ量５０３に基づいて、ターゲットリクエストの受付数を算出する。例えば、負荷予測部１１３は、起点リクエストの受付数をデータ量５０３で除算した値を、関連データ量５０４に乗算する。以上がステップＳ２０１の処理の説明である。

次に、負荷予測部１１３は、サービス構成管理情報３００を参照して、ターゲットリクエストに対応する機能を提供するサービス（関連サービス）を特定する（ステップＳ２０２）。

具体的には、負荷予測部１１３は、リクエストＩＤ３０１にターゲットリクエストの識別情報が格納されるエントリを検索する。負荷予測部１１３は、検索されたエントリを用いて関連サービス一覧を生成する。なお、ターゲットリクエストに対応する機能を提供するサービスは、起点リクエストの受付を契機に実行されるサービス、すなわち、関連サービスである。

次に、負荷予測部１１３は、関連サービスのループ処理を開始する（ステップＳ２０３）。

具体的には、負荷予測部１１３は、関連サービス一覧から関連サービスを一つ選択する。

次に、負荷予測部１１３は、関連サービスの負荷を予測するための負荷予測処理を実行する（ステップＳ２０４）。負荷予測処理の詳細は図１５を用いて説明する。

次に、負荷予測部１１３は、負荷予測処理の結果を用いて対処判定処理を実行する（ステップＳ２０５）。対処判定処理の詳細は図１８を用いて説明する。

次に、負荷予測部１１３は、関連サービス一覧の全ての関連サービスについて処理が完了したか否かを判定する（ステップＳ２０６）。

関連サービス一覧の全ての関連サービスについて処理が完了していない場合、負荷予測部１１３は、ステップＳ２０３に戻り、同様の処理を実行する。

関連サービス一覧の全ての関連サービスについて処理が完了した場合、負荷予測部１１３は、管理サーバ制御部１１０にスケジュール生成処理の完了を通知し、その後、スケジュール生成処理を終了する。

図１５は、実施例１の負荷予測部１１３が実行する負荷予測処理の一例を説明するフローチャートである。図１６は、実施例１の負荷予測部１１３によって生成される予測値情報１６００のデータ構造の一例を示す図である。

負荷予測部１１３は、ターゲットリクエストの受付数に基づいて、ステップＳ２０２において選択された関連サービスを実行する処理ノード１４０が処理するデータ量を算出する（ステップＳ３０１）。

具体的には、負荷予測部１１３は、サービス構成管理情報３００を参照し、リクエストＩＤ３０１にターゲットリクエストの識別情報が格納され、かつ、サービスＩＤ３０２に関連サービスの識別情報が格納されるエントリを検索する。すなわち、関連サービスを実行する処理ノード１４０のエントリが検索される。負荷予測部１１３は、ターゲットリクエストの受付数をエントリの数（処理ノード１４０の数）で除算した値を、一つの処理ノード１４０が処理するデータ量として算出する。

本実施例では、同一のサービスを実行する処理ノード１４０は負荷が均等になるように分散処理を実行しているものとする。

次に、負荷予測部１１３は、処理ノード性能情報８００を参照し、関連サービスを実行する処理ノード１４０の現在の各メトリックの性能値を取得する（ステップＳ３０２）。このとき、負荷予測部１１３はメトリック一覧を生成する。

なお、同一の関連サービスを実行する処理ノード１４０が複数存在する場合、各処理ノード１４０のメトリックの性能値の中で最も大きい性能値が取得される。

次に、負荷予測部１１３は、各メトリックの使用量の予測最大値を算出するために、最大使用量算出処理を実行する（ステップＳ３０３）。最大使用量算出処理の詳細は図１７を用いて説明する。最大使用量算出処理では、各メトリックの最大使用量及び上昇率が算出される。

次に、負荷予測部１１３は、メトリックのループ処理を開始する（ステップＳ３０４）。

具体的には、負荷予測部１１３は、メトリック一覧から一つのメトリックを選択する。

次に、負荷予測部１１３は、選択されたメトリックの最大使用量と、現在の選択されたメトリックの性能値とを用いて、選択されたメトリックの予測性能値を算出する（ステップＳ３０５）。

具体的には、負荷予測部１１３は、選択されたメトリックの最大使用量と、現在の選択されたメトリックの性能値との合計値を、選択されたメトリックの予測性能値として算出する。

次に、負荷予測部１１３は、一連の処理結果を予測値情報１６００に登録する（ステップＳ３０６）。

ここで、予測値情報１６００は、サービスＩＤ１６０１、メトリック種別１６０２、予測性能値１６０３、及び上昇率１６０４を含むエントリを格納する。サービス及びメトリックの組合せに対して一つのエントリが存在する。

負荷予測部１１３は、予測値情報１６００にエントリを追加し、追加されたエントリのサービスＩＤ１６０１及びメトリック種別１６０２に、選択された関連サービスの識別情報及び選択されたメトリックの種別を設定する。また、負荷予測部１１３は、追加されたエントリの予測性能値１６０３に算出された予測性能値を格納し、上昇率１６０４に算出された上昇率を格納する。

次に、負荷予測部１１３は、メトリック一覧の全てのメトリックについて処理が完了したか否かを判定する（ステップＳ３０７）。

メトリック一覧の全てのメトリックについて処理が完了していない場合、負荷予測部１１３は、ステップＳ３０４に戻り、同様の処理を実行する。

メトリック一覧の全てのメトリックについて処理が完了した場合、負荷予測部１１３は負荷予測処理を終了する。

図１７は、実施例１の負荷予測部１１３が実行する最大使用量算出処理の一例を説明するフローチャートである。

負荷予測部１１３は、サービス負荷特徴情報６００を参照して、ターゲットリクエスト、関連サービス、及びターゲットリクエストの受付数の組合せに一致するエントリを検索する（ステップＳ４０１）。

負荷予測部１１３は、検索結果に基づいて、前述の条件を満たすエントリが存在するか否かを判定する（ステップＳ４０２）。

前述の条件を満たすエントリが存在する場合、負荷予測部１１３は、当該エントリのメモリ最大使用量６０４及び上昇率６０５から値を取得する（ステップＳ４０３）。

次に、負荷予測部１１３は、サービス負荷特徴情報６００から取得した値を最大使用量及び上昇率として出力する（ステップＳ４０４）。その後、負荷予測部１１３は最大使用量算出処理を終了する。

ステップＳ４０２において、前述の条件を満たすエントリが存在しない場合、負荷予測部１１３は、サービス負荷特徴情報６００を参照して、ターゲットリクエスト及び関連サービスの組合せに一致するエントリを検索し、検索されたエントリのデータ量６０３、メモリ最大使用量６０４、及び上昇率６０５の値を取得する（ステップＳ４０５）。

次に、負荷予測部１１３は、取得された値を用いて、最大使用量のリクエストの受付数（リクエスト数）への回帰式、及び上昇率のリクエストの受付数（リクエスト数）への回帰式を算出する（ステップＳ４０６）。すなわち、リクエストの受付数から最大使用量及び上昇率を算出するためのモデルが生成される。

次に、負荷予測部１１３は、各回帰式に、関連サービスを実行する処理ノード１４０が処理するデータ量を入力することによって、予測最大使用量及び予測上昇率を算出する（ステップＳ４０７）。

次に、負荷予測部１１３は、予測最大使用量及び予測上昇率を、最大使用量及び上昇率として出力する（ステップＳ４０８）。その後、負荷予測部１１３は最大使用量算出処理を終了する。

図１８は、実施例１の負荷予測部１１３が実行する対処判定処理の一例を説明するフローチャートである。

負荷予測部１１３は、負荷予測処理の結果を用いて、スケールアウトスケジュール生成処理及びスケールインスケジュール生成処理を実行する（ステップＳ５０１、ステップＳ５０２）。スケールアウトスケジュール生成処理の詳細は図１９を用いて説明し、スケールインスケジュール生成処理の詳細は図２１を用いて説明する。

次に、負荷予測部１１３は、スケールアウトスケジュール情報２０００（図２０を参照）及びスケールインスケジュール情報２２００（図２２を参照）をワークエリアに出力する（ステップＳ５０３）。その後、負荷予測部１１３は対処判定処理を終了する。

図１９は、実施例１の負荷予測部１１３が実行するスケールアウトスケジュール生成処理の一例を説明するフローチャートである。図２０は、実施例１の負荷予測部１１３によって生成されるスケールアウトスケジュール情報２０００のデータ構造の一例を示す図である。

負荷予測部１１３は、処理ノード性能情報８００を参照して、関連サービスを実行する処理ノード１４０のメトリックの一覧を生成する（ステップＳ６０１）。

次に、負荷予測部１１３は、メトリックのループ処理を開始する（ステップＳ６０２）。

具体的には、負荷予測部１１３は、メトリック一覧から一つのメトリックを選択する。

次に、負荷予測部１１３は、閾値管理情報７００からＣｒｉｔｉｃａｌ上限閾値及びＷａｒｎｉｎｇ上限閾値を取得する（ステップＳ６０３）。

具体的には、負荷予測部１１３は、サービスＩＤ７０１に関連サービスの識別情報が格納され、かつ、メトリック種別７０２に選択されたメトリックの識別情報が格納されるエントリを検索し、検索されたエントリのＷａｒｎｉｎｇ上限閾値７０３及びＣｒｉｔｉｃａｌ上限閾値７０４の値を取得する。また、負荷予測部１１３は、予測値情報１６００から関連サービスのメトリックの予測性能値及び上昇率を取得する。

次に、負荷予測部１１３は、負荷予測処理によって算出されたメトリックの予測性能値がＣｒｉｔｉｃａｌ上限閾値より大きいか否かを判定する（ステップＳ６０４）。

メトリックの予測性能値がＣｒｉｔｉｃａｌ上限閾値以下の場合、負荷予測部１１３はステップＳ６１０に進む。

メトリックの予測性能値がＣｒｉｔｉｃａｌ上限閾値より大きい場合、負荷予測部１１３は、関連サービスのスケールアウトの猶予時間を算出する（ステップＳ６０５）。

具体的には、負荷予測部１１３は、Ｗａｒｎｉｎｇ上限閾値から予測性能値を減算する。負荷予測部１１３は、算出された値を上昇率で除算することによって猶予時間を算出する。

次に、負荷予測部１１３は、スケールアウトスケジュール情報２０００に関連サービスのスケールアウトスケジュールが登録されているか否かを判定する（ステップＳ６０５）。

ここで、スケールアウトスケジュール情報２０００は、リクエストＩＤ２００１、サービスＩＤ２００２、及び猶予時間２００３を含むエントリを格納する。スケールアウト対象となるサービスに対して一つのエントリが存在する。一つのエントリをスケールアウトスケジュールとも記載する。

ステップＳ６０５では、負荷予測部１１３は、リクエストＩＤ２００１にターゲットリクエストの識別情報が格納され、かつ、サービスＩＤ２００２に関連サービスの識別情報が格納されるエントリが存在するか否かを判定する。

スケールアウトスケジュール情報２０００に関連サービスのスケールアウトスケジュールが登録されていない場合、負荷予測部１１３は、スケールアウトスケジュール情報２０００に関連サービスのスケールアウトスケジュールを登録する（ステップＳ６０６）。その後、負荷予測部１１３はステップＳ６１０に進む。

具体的には、負荷予測部１１３は、スケールアウトスケジュール情報２０００にエントリを追加し、追加されたエントリのリクエストＩＤ２００１にターゲットリクエストの識別情報を設定し、サービスＩＤ２００２に関連サービスの識別情報を設定し、猶予時間２００３に算出された猶予時間を設定する。

スケールアウトスケジュール情報２０００に関連サービスのスケールアウトスケジュールが登録されている場合、負荷予測部１１３は、登録されているスケールアウトスケジュールの猶予時間の更新が必要であるか否かを判定する（ステップＳ６０６）。

具体的には、負荷予測部１１３は、当該スケールアウトスケジュールの猶予時間２００３が算出された猶予時間より大きいか否かを判定する。猶予時間２００３が算出された猶予時間より大きい場合、負荷予測部１１３は、登録されているスケールアウトスケジュールの猶予時間の更新が必要であると判定する。

登録されているスケールアウトスケジュールの猶予時間の更新が必要ない場合、負荷予測部１１３はステップＳ６１０に進む。

登録されているスケールアウトスケジュールの猶予時間の更新が必要ある場合、負荷予測部１１３は、登録されたいるスケジュールの猶予時間２００３に算出された猶予時間を設定する（ステップＳ６０９）。その後、負荷予測部１１３はステップＳ６１０に進む。

ステップＳ６１０では、負荷予測部１１３は、メトリック一覧の全てのメトリックについて処理が完了したか否かを判定する（ステップＳ６１０）。

メトリック一覧の全てのメトリックについて処理が完了していない場合、負荷予測部１１３は、ステップＳ６０２に戻り、同様の処理を実行する。

メトリック一覧の全てのメトリックについて処理が完了した場合、負荷予測部１１３はスケールアウトスケジュール生成処理を終了する。

スケールアウトスケジュール生成処理では、負荷予測部１１３は、予測性能値がＣｒｉｔｉｃａｌ上限閾値より大きいメトリックを少なくとも一つ含む関連サービスをスケールアウト対象に決定する。

図２１は、実施例１の負荷予測部１１３が実行するスケールインスケジュール生成処理の一例を説明するフローチャートである。図２２は、実施例１の負荷予測部１１３によって生成されるスケールインスケジュール情報２２００のデータ構造の一例を示す図である。

負荷予測部１１３は、処理ノード性能情報８００を参照して、関連サービスを実行する処理ノード１４０のメトリックの一覧を生成する（ステップＳ７０１）。

次に、負荷予測部１１３は、メトリックのループ処理を開始する（ステップＳ７０２）。

具体的には、負荷予測部１１３は、メトリック一覧から一つのメトリックを選択する。

次に、負荷予測部１１３は、閾値管理情報７００から下限値を取得する（ステップＳ７０３）。

具体的には、負荷予測部１１３は、サービスＩＤ７０１に関連サービスの識別情報が格納され、かつ、メトリック種別７０２に選択されたメトリックの識別情報が格納されるエントリを検索し、検索されたエントリの下限値７０５の値を取得する。また、負荷予測部１１３は、予測値情報１６００から関連サービスのメトリックの予測性能値を取得する。

次に、負荷予測部１１３は、負荷予測処理によって算出されたメトリックの予測性能値が下限値より小さいか否かを判定する（ステップＳ７０４）。

メトリックの予測性能値が下限値以上である場合、負荷予測部１１３は、フラグにＦＡＬＳＥを設定してループ処理を終了し（ステップＳ７０５）、ステップＳ７０８に進む。

メトリックの予測性能値が下限値より小さい場合、負荷予測部１１３は、フラグにＴＲＵＥを設定する（ステップＳ７０６）。

次に、負荷予測部１１３は、メトリック一覧の全てのメトリックについて処理が完了したか否かを判定する（ステップＳ７０７）。

メトリック一覧の全てのメトリックについて処理が完了していない場合、負荷予測部１１３は、ステップＳ７０２に戻り、同様の処理を実行する。

メトリック一覧の全てのメトリックについて処理が完了した場合、負荷予測部１１３はステップＳ７０８に進む。

ステップＳ７０８では、負荷予測部１１３は、フラグがＴＲＵＥであるか否かを判定する（ステップＳ７０８）。

フラグがＦＡＬＳＥである場合、負荷予測部１１３はスケールインスケジュール生成処理を終了する。

フラグがＴＲＵＥである場合、負荷予測部１１３は、スケールインスケジュール情報２２００に関連サービスのスケールインスケジュールを登録する（ステップＳ７０９）。その後、負荷予測部１１３はスケールインスケジュール生成処理を終了する。

ここで、スケールインスケジュール情報２２００は、リクエストＩＤ２２０１及びサービスＩＤ２２０２を含むエントリを格納する。スケールイン対象となるサービスに対して一つのエントリが存在する。一つのエントリをスケールインスケジュールとも記載する。

スケールインスケジュール生成処理では、負荷予測部１１３は、全てのメトリックの予測性能値が下限値より小さい関連サービスをスケールイン対象に決定する。

図２３は、実施例１の割当変更部１１４が実行するリソース割当変更処理の一例を説明するフローチャートである。

割当変更部１１４は、スケールアウト対象のサービスのループ処理を開始する（ステップＳ８０１）。

具体的には、割当変更部１１４は、スケールアウトスケジュール情報２０００から一つのサービス（エントリ）を選択する。

次に、割当変更部１１４は、選択されたサービスを実行する処理ノード１４０が存在するサーバ１０３を特定する（ステップＳ８０２）。

具体的には、割当変更部１１４は、サービス構成管理情報３００を参照して、サービスＩＤ３０２が選択されたサービスの識別情報に一致するエントリを検索する。割当変更部１１４は、検索されたエントリのサーバＩＤ３０４の値を取得する。

次に、割当変更部１１４は、特定されたサーバ１０３の空きリソース量を算出する（ステップＳ８０３）。

具体的には、割当変更部１１４は、サーバ性能情報９００を参照して、サーバＩＤ９０２が特定されたサーバ１０３の識別情報に一致するエントリを検索する。割当変更部１１４は、検索されたエントリの性能値９０６を用いて各メトリックについての空きリソース量を算出する。

次に、割当変更部１１４は、スケールアウトによるリソース量の予測値（増加量）を算出する（ステップＳ８０４）。

スケールアウトによるリソース量の予測は公知の技術を用いればよい。例えば、以下のような方法が考えられる。

割当変更部１１４は、処理ノード性能情報８００を参照して、サービスＩＤ８０２に選択されたサービスの識別情報が格納されるエントリを検索する。割当変更部１１４は、検索されたエントリを用いて各メトリックの性能値の平均値を算出する。さらに、割当変更部１１４は、現在のサーバ１０３の性能値に前述の平均値を加算した値を、スケールアウト後のサーバ１０３のリソース量の予測値として算出する。なお、前述した算出方法は一例であってこれに限定されない。

次に、割当変更部１１４は、スケールアウトスケジュール情報２０００の全てのサービスについて処理が完了したか否かを判定する（ステップＳ８０５）。

スケールアウトスケジュール情報２０００の全てのサービスについて処理が完了していない場合、割当変更部１１４は、ステップＳ８０１に戻り、同様の処理を実行する。

スケールアウトスケジュール情報２０００の全てのサービスについて処理が完了した場合、割当変更部１１４は、スケールアウト対象のサービスの空きリソース量及び増加量に基づいて、リソース不足が生じるサービスが存在するか否かを判定する（ステップＳ８０６）。

リソース不足が生じるサービスが存在する場合、割当変更部１１４は、スケールインを実行した後（ステップＳ８０７）、スケールアウトを実行する（ステップＳ８０８）。その後、割当変更部１１４はリソース割当変更処理を終了する。リソース不足が生じるサービスが存在する場合には、スケールアウトに必要なリソース量を確保するためにスケールインが先に実行される。

リソース不足が生じるサービスが存在しない場合、割当変更部１１４は、スケールアウトを実行した後（ステップＳ８０９）、スケールインを実行する（ステップＳ８１０）。その後、割当変更部１１４はリソース割当変更処理を終了する。サービスの負荷の低減に迅速に対応するためにスケールアウトが先に実行される。

なお、ステップＳ８０８及びステップＳ８０９のスケールアウトは同一の処理である。スケールアウトの詳細は図２４を用いて説明する。ステップＳ８０７及びステップＳ８１０のスケールインは同一の処理である。スケールインの詳細は図２５を用いて説明する。

図２４は、実施例１の割当変更部１１４が実行するスケールアウトの一例を説明するフローチャートである。

割当変更部１１４は、猶予時間の大きさに基づいて、スケールアウトスケジュール情報２０００のエントリをソートする（ステップＳ９０１）。

具体的には、割当変更部１１４は、猶予時間２００３の値の昇順にエントリをソートする。

次に、割当変更部１１４は、スケールアウト対象のサービスのループ処理を開始する（ステップＳ９０２）。

具体的には、割当変更部１１４は、スケールアウトスケジュール情報２０００から一つのサービス（エントリ）を選択する。なお、上から順にエントリは選択されるものとする。これは、メトリックの値がＷａｒｎｉｎｇ上限閾値に達するまでの時間が短いサービスのスケールアウトを優先的に実行するためである。

次に、割当変更部１１４は、選択されたサービスのスケールアウトを実行する（ステップＳ９０３）。

処理ノード１４０がコンテナの場合、割当変更部１１４は、サービスに対応する処理ノード１４０が存在するサーバ１０３又は他のサーバ１０３に、コンテナのイメージをデプロイする。処理ノード１４０が仮想計算機の場合、割当変更部１１４は、サービスに対応する処理ノード１４０が存在するサーバ１０３又は他のサーバ１０３に、仮想計算機の生成を指示する。なお、スケールアウトの方法は公知の技術であるため詳細な説明は省略する。

次に、割当変更部１１４は、サービス構成管理情報３００を更新する（ステップＳ９０４）。

具体的には、割当変更部１１４は、サービス構成管理情報３００にエントリを追加し、追加されたエントリのリクエストＩＤ３０１及びサービスＩＤ３０２に、リクエストＩＤ２００１及びサービスＩＤ２００２の値を設定する。また、割当変更部１１４は、スケールアウトの結果に基づいて、追加されたエントリの処理ノードＩＤ３０３及びサーバＩＤ３０４に値を設定する。

次に、割当変更部１１４は、全てのスケールアウト対象のサービスについて処理が完了したか否かを判定する（ステップＳ９０５）。すなわち、スケールアウトスケジュール情報２０００の全てのエントリの処理が完了したか否かが判定される。

全てのスケールアウト対象のサービスについて処理が完了していない場合、割当変更部１１４は、ステップＳ９０２に戻り、同様の処理を実行する。

全てのスケールアウト対象のサービスについて処理が完了した場合、割当変更部１１４はスケールアウトを終了する。

図２５は、実施例１の割当変更部１１４が実行するスケールインの一例を説明するフローチャートである。

割当変更部１１４は、スケールイン対象のサービスのループ処理を開始する（ステップＳ１００１）。

具体的には、割当変更部１１４は、スケールインスケジュール情報２２００から一つのサービス（エントリ）を選択する。

次に、割当変更部１１４は、選択されたサービスのスケールインを実行する（ステップＳ１００２）。スケールインの方法は公知の技術であるため詳細な説明は省略する。

次に、割当変更部１１４は、サービス構成管理情報３００を更新する（ステップＳ１００３）。

具体的には、割当変更部１１４は、スケールインの結果に基づいて、サービス構成管理情報３００のエントリを削除する。

次に、割当変更部１１４は、全てのスケールイン対象のサービスについて処理が完了したか否かを判定する（ステップＳ１００４）。すなわち、スケールインスケジュール情報２２００の全てのエントリの処理が完了したか否かが判定される。

全てのスケールイン対象のサービスについて処理が完了していない場合、割当変更部１１４は、ステップＳ１００１に戻り、同様の処理を実行する。

全てのスケールイン対象のサービスについて処理が完了した場合、割当変更部１１４はスケールインを終了する。

次に、リクエスト経路管理情報４００及びサービス負荷特徴情報６００の更新方法について説明する。

図２６は、実施例１の管理サーバ制御部１１０が実行するリクエスト経路管理情報４００の更新処理の一例を説明するフローチャートである。図２７は、実施例１の管理サーバ制御部１１０によって生成されるリクエスト関連マップ２７００のデータ構造の一例を示す図である。

管理サーバ制御部１１０は、周期的に又は実行指示を受けつけた場合、以下の更新処理を実行する。

まず、管理サーバ制御部１１０は、リクエスト関連マップ２７００を初期化する（ステップＳ１１０１）。

具体的には、管理サーバ制御部１１０は、検知リクエスト情報１０００を参照し、検知されたリクエストの種別を行及び列の成分とする行列形式のリクエスト関連マップ２７００を生成する。各セルには、行に対応するリクエストの時刻と列に対応するリクエストの時刻との差（時間）が格納される。

次に、管理サーバ制御部１１０は、検知リクエスト情報１０００を参照して、リクエスト関連マップ２７００のセルに値を設定する（ステップＳ１１０２）。

次に、管理サーバ制御部１１０は、リクエスト関連マップ２７００に基づいて、連続して呼び出されるリクエストのグループを生成する（ステップＳ１１０３）。

具体的には、管理サーバ制御部１１０は、セルの値（実行時刻の差）が閾値より小さいリクエストのペアを生成し、共通するリクエストを含むペアをまとめることによってリクエストのグループを生成する。閾値は任意に設定できる。なお、セルの値が０のペアは生成されない。

次に、管理サーバ制御部１１０は、各リクエストのグループのリクエストを実行順にソートすることによって候補リクエスト経路を生成する（ステップＳ１１０４）。

次に、管理サーバ制御部１１０は、候補リクエスト経路のループ処理を開始する（ステップＳ１１０５）。

具体的には、管理サーバ制御部１１０は、ステップＳ１１０４において生成された候補リクエスト経路の中から一つの候補リクエスト経路を選択する。

次に、管理サーバ制御部１１０は、候補リクエスト経路が新規のリクエスト経路であるか否かを判定する（ステップＳ１１０６）。

具体的には、管理サーバ制御部１１０は、リクエスト経路管理情報４００を参照して、リクエスト経路４０２が候補リクエスト経路と一致するエントリが存在するか否かを判定する。前述のエントリが存在しない場合、管理サーバ制御部１１０は候補リクエスト経路が新規のリクエスト経路であると判定する。

候補リクエスト経路が新規のリクエスト経路ではない場合、管理サーバ制御部１１０はステップＳ１１０８に進む。

候補リクエスト経路が新規のリクエスト経路である場合、管理サーバ制御部１１０は、リクエスト経路管理情報４００に候補リクエスト経路を登録し（ステップＳ１１０７）、その後、ステップＳ１１０８に進む。

具体的には、管理サーバ制御部１１０は、リクエスト経路管理情報４００にエントリを追加し、追加されたエントリのリクエストＩＤ４０１に候補リクエスト経路の最初のリクエストの識別情報を設定する。また、管理サーバ制御部１１０は、追加されたエントリのリクエスト経路４０２に候補リクエスト経路を設定する。

ステップＳ１１０８では、管理サーバ制御部１１０は、全ての候補リクエスト経路について処理が完了したか否かを判定する（ステップＳ１１０８）。

全ての候補リクエスト経路について処理が完了していない場合、管理サーバ制御部１１０は、ステップＳ１１０５に戻り、同様の処理を実行する。

全ての候補リクエスト経路について処理が完了した場合、管理サーバ制御部１１０はリクエスト経路管理情報４００の更新処理を終了する。

図２８は、実施例１の管理サーバ制御部１１０が実行するサービス負荷特徴情報６００の更新処理の一例を説明するフローチャートである。図２９は、実施例１の管理サーバ制御部１１０によって生成される負荷解析情報２９００のデータ構造の一例を示す図である。

管理サーバ制御部１１０は、周期的に又は実行指示を受けつけた場合、以下の更新処理を実行する。

まず、管理サーバ制御部１１０は、負荷解析情報２９００を初期化する（ステップＳ１２０１）。

ここで、負荷解析情報２９００は、リクエストＩＤ２９０１、サービスＩＤ２９０２、データ量２９０３、メモリ最大使用量２９０４、及び上昇率２９０５を含むエントリを格納する。

管理サーバ制御部１１０は、リクエスト及びサービスの組合せの数だけエントリを生成する。

次に、管理サーバ制御部１１０は、リクエスト及びサービスの組合せのループ処理を開始する（ステップＳ１２０２）。

具体的には、管理サーバ制御部１１０は、負荷解析情報２９００のエントリを一つ選択する。

次に、管理サーバ制御部１１０は、処理ノード性能情報８００及びサービス実行情報１１００等を解析し、リクエストの受付数及び各メトリックの最大値を算出する（ステップＳ１２０３）具体的には、以下のような処理が実行される。

管理サーバ制御部１１０は、サービス実行情報１１００に基づいて一定時間内に受けつけたリクエストの数を算出し、データ量２９０３に設定する。

管理サーバ制御部１１０は、処理ノード性能情報８００及びサービス実行情報１１００に基づいて、あるリクエストに対応する機能を提供するサービスの各メトリックの時系列データを生成する。管理サーバ制御部１１０は、時系列データに基づいてメトリックの最大使用量を算出し、負荷解析情報２９００を更新する。例えば、メモリ最大使用量２９０４に値が設定される。

次に、管理サーバ制御部１１０は、処理ノード性能情報８００及びサービス実行情報１１００等を解析し、上昇率を算出する（ステップＳ１２０４）。

具体的には、管理サーバ制御部１１０は、メトリックの値の時系列データに基づいて、メトリックの値の変動が開始してからＷａｒｎｉｎｇ上限閾値７０３に至るまでの時間と、変動開始のメトリックの値及びＷａｒｎｉｎｇ上限閾値７０３の差とに基づいて、上昇率を算出する。管理サーバ制御部１１０は、上昇率２９０５に算出された上昇率を設定する。

次に、管理サーバ制御部１１０は、サービス負荷特徴情報６００を更新する（ステップＳ１２０５）。具体的には以下のような処理が実行される。

管理サーバ制御部１１０は、サービス負荷特徴情報６００を参照し、リクエストＩＤ６０１、サービスＩＤ６０２、及びデータ量６０３の組合せが、選択されたエントリのリクエストＩＤ２９０１、サービスＩＤ２９０２、及びデータ量２９０３の組合せに一致するエントリを検索する。

前述のエントリが存在する場合、管理サーバ制御部１１０は、選択されたエントリのメモリ最大使用量２９０４及び検索されたエントリのメモリ最大使用量６０４の平均値を算出し、検索されたエントリのメモリ最大使用量６０４に設定する。また、管理サーバ制御部１１０は、選択されたエントリの上昇率６０５及び検索されたエントリの上昇率２９０５の平均値を算出し、検索されたエントリの上昇率６０５に設定する。

前述のエントリが存在しない場合、管理サーバ制御部１１０は、サービス負荷特徴情報６００にエントリを追加し、選択されたエントリの値を、追加されたエントリの各フィールドに設定する。以上がステップＳ１２０５の処理の説明である。

次に、管理サーバ制御部１１０は、負荷解析情報２９００の全てのエントリについて処理が完了したか否かを判定する（ステップＳ１２０６）。

負荷解析情報２９００の全てのエントリについて処理が完了していない場合、管理サーバ制御部１１０は、ステップＳ１２０２に戻り、同様の処理を実行する。

負荷解析情報２９００の全てのエントリについて処理が完了した場合、管理サーバ制御部１１０はサービス負荷特徴情報６００の更新処理を終了する。

以上で説明したように、管理サーバ１００は、業務システム１０２においてリクエストの受付が検知された場合、リクエストの受付を契機に実行されるサービスの負荷を見積もって、リソースの割当量を変更するためのスケジューリングを行う。管理サーバ１００は、スケジュールにしたがって、サービスへの影響が顕在化する前にサービスに対するリソースの割当量を変更できる。管理サーバ１００は、リクエストの受付数に基づいてサービスの負荷を見積もっているため、突発的な負荷にも対応できる。

管理サーバ１００は、リクエストの呼出関係及び各リクエストに対応する機能を提供するサービスの構成に基づいて関連サービスを特定する。これによって、効率的にリソースの割当量を変更し、また、リソースの割当量の変更に伴う業務全体の影響を最小化できる。

なお、管理サーバ１００は、各種判定に使用するメトリックの指定を受けつけるインタフェースを提供してもよい。本実施例では、リクエスト間のサービスは重複しないものとしているが、リクエスト間のサービスが重複する場合でも同様の処理を適用できる。

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

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

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

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

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

１００ 管理サーバ
１０１ 管理クライアント
１０２ 業務システム
１０３ サーバ
１０４ ネットワーク
１１０ 管理サーバ制御部
１１１ 性能情報管理部
１１２ リクエスト監視部
１１３ 負荷予測部
１１４ 割当変更部
１２０ 管理情報群
１２１ ログ情報群
１３０ Ｗｅｂブラウザ
１３１ 管理クライアント制御部
１４０ 処理ノード
１４１ 情報収集部
２００、２１０ プロセッサ
２０１、２１１ メモリ
２０２、２１２ ネットワークインタフェース
２０３ ストレージ装置
２１３ 入力デバイス
２１４ 出力デバイス
３００ サービス構成管理情報
４００ リクエスト経路管理情報
５００ リクエスト負荷特徴情報
６００ サービス負荷特徴情報
７００ 閾値管理情報
８００ 処理ノード性能情報
９００ サーバ性能情報
１０００ 検知リクエスト情報
１１００ サービス実行情報
１３００ ターゲットリクエスト一覧
１６００ 予測値情報
２０００ スケールアウトスケジュール情報
２２００ スケールインスケジュール情報
２７００ リクエスト関連マップ
２９００ 負荷解析情報

Claims (14)

1. 演算装置、前記演算装置に接続される記憶装置、及び前記演算装置に接続され、外部装置に接続するための接続装置を有する、複数の計算機を備える計算機システムであって、
   少なくとも一つの前記計算機を含み、リクエストに対応する機能を提供する複数のサービスが稼働する業務システムを含み、
   前記サービスに対する前記業務システムのリソースの割当量を変更するためのスケジュールを生成する制御部と、前記スケジュールに基づいて、前記サービスに対する前記リソースの割当量を変更する割当変更部と、を備え、
   前記制御部は、
   処理を開始するためのリクエストの受付を検知した場合、前記検知されたリクエストの受付数を算出し、
   前記検知されたリクエストの受付を契機に実行される関連サービスを特定し、
   前記検知されたリクエストの受付数に基づいて、前記関連サービスの負荷を示す指標の予測値を算出し、
   前記関連サービスの前記指標の予測値に基づいて、前記リソースの割当量を変更する必要がある前記関連サービスを決定し、
   前記決定された関連サービスの前記スケジュールを生成することを特徴とする計算機システム。
2. 請求項１に記載の計算機システムであって、
   前記制御部は、
   前記検知されたリクエストの後に発行される関連リクエストを特定し、前記検知されたリクエスト及び前記関連リクエストをターゲットリクエストとしてリストに登録し、
   前記リストから一つの前記ターゲットリクエストを選択し、
   前記選択されたターゲットリクエストの受付数を算出し、
   前記選択されたターゲットリクエストに対応する機能を提供する前記サービスを、前記関連サービスとして特定し、
   前記選択されたターゲットリクエストの受付数に基づいて、前記関連サービスの前記指標の予測値を算出し、
   前記関連サービスの前記指標の予測値に基づいて、前記リソースの割当量を変更する必要がある前記関連サービスを決定し、
   前記決定された関連サービスに対する前記リソースの割当量を変更するためのスケジュールを生成することを特徴とする計算機システム。
3. 請求項２に記載の計算機システムであって、
   前記リクエストの呼出関係を管理するための第１管理情報と、前記リクエストに対応する機能を提供する前記サービスの構成を管理するための第２管理情報を保持し、
   前記制御部は、
   前記第１管理情報に基づいて、前記関連リクエストを特定し、
   前記第２管理情報に基づいて、前記選択されたターゲットリクエストに対応する機能を提供する前記サービスを特定することを特徴とする計算機システム。
4. 請求項３に記載の計算機システムであって、
   前記サービスへの前記リソースの割当量を追加するか否かを判定するための第１閾値及び前記サービスへの前記リソースの割当量を削減するか否かを判定するための第２閾値を含む第３管理情報を保持し、
   前記制御部は、
   前記関連サービスの前記指標の予測値が前記第１閾値より大きいと判定された場合、前記関連サービスに対する前記リソースの割当量を追加するためのリソース追加スケジュールを生成し、
   前記関連サービスの前記指標の予測値が前記第２閾値より小さいと判定された場合、前記関連サービスに対する前記リソースの割当量を削減するためのリソース削減スケジュールを生成することを特徴とする計算機システム。
5. 請求項４に記載の計算機システムであって、
   前記リクエストの受付数と、前記サービスの前記指標との関係を管理するための第４管理情報を保持し、
   前記第４管理情報は、前記リクエストの受付に伴って実行される前記サービスが使用するリソース量の上昇率を含み、
   前記制御部は、
   前記選択されたターゲットリクエストの受付数及び前記第４管理情報に基づいて、前記関連サービスの前記指標の予測値を算出し、
   前記関連サービスの前記指標の予測値が前記関連サービスの前記第１閾値より大きいと判定された場合、当該関連サービスの現在の前記指標の値、前記指標の予測値、及び前記関連サービスが使用するリソース量の上昇率に基づいて、前記関連サービスへの前記リソースの割当量の追加を完了する目安となる時間を示す猶予時間を算出し、
   前記猶予時間を含む前記リソース追加スケジュールを生成し、
   前記割当変更部は、前記猶予時間に基づいて、前記リソース追加スケジュールの実行順を決定することを特徴とする計算機システム。
6. 請求項４に記載の計算機システムであって、
   前記割当変更部は、前記業務システムにおけるリソースの空き容量に応じて、前記リソース追加スケジュール及び前記リソース削減スケジュールの実行順番を決定することを特徴とする計算機システム。
7. 請求項４に記載の計算機システムであって、
   前記リソースは、前記サービスを実行する処理ノードであり、
   前記リソース追加スケジュールは、前記決定された関連サービスを実行する前記処理ノードの数を追加するためのスケジュールであり、
   前記リソース削減スケジュールは、前記決定された関連サービスを実行する前記処理ノードの数を削減するためのスケジュールであることを特徴とする計算機システム。
8. 演算装置、前記演算装置に接続される記憶装置、及び前記演算装置に接続され、外部装置に接続するための接続装置を有する、複数の計算機を含む計算機システムが実行するリソース管理方法であって、
   前記計算機システムは、
   少なくとも一つの前記計算機を含み、リクエストに対応する機能を提供する複数のサービスが稼働する業務システムを含み、
   前記サービスに対する前記業務システムのリソースの割当量を変更するためのスケジュールを生成する制御部と、前記スケジュールに基づいて、前記サービスに対する前記リソースの割当量を変更する割当変更部と、を有し、
   前記リソース管理方法は、
   前記制御部が、処理を開始するためのリクエストの受付を検知した場合、前記検知されたリクエストの受付数を算出する第１のステップと、
   前記制御部が、前記検知されたリクエストの受付を契機に実行される関連サービスを特定する第２のステップと、
   前記制御部が、前記検知されたリクエストの受付数に基づいて、前記関連サービスの負荷を示す指標の予測値を算出する第３のステップと、
   前記制御部が、前記関連サービスの前記指標の予測値に基づいて、前記リソースの割当量を変更する必要がある前記関連サービスを決定する第４のステップと、
   前記制御部が、前記決定された関連サービスの前記スケジュールを生成する第５のステップと、を含むことを特徴とするリソース管理方法。
9. 請求項８に記載のリソース管理方法であって、
   前記第１のステップは、
   前記制御部が、前記検知されたリクエストの後に発行される関連リクエストを特定し、前記検知されたリクエスト及び前記関連リクエストをターゲットリクエストとしてリストに登録するステップと、
   前記制御部が、前記リストから一つの前記ターゲットリクエストを選択するステップと、
   前記制御部が、前記選択されたターゲットリクエストの受付数を算出するステップと、を含み、
   前記第２のステップは、前記制御部が、前記選択されたターゲットリクエストに対応する機能を提供する前記サービスを、前記関連サービスとして特定するステップを含み、
   前記第３のステップは、前記制御部が、前記選択されたターゲットリクエストの受付数に基づいて、前記関連サービスの前記指標の予測値を算出するステップを含み、
   前記第４のステップは、前記制御部が、前記関連サービスの前記指標の予測値に基づいて、前記リソースの割当量を変更する必要がある前記関連サービスを決定するステップを含み、
   前記第５のステップは、前記制御部が、前記決定された関連サービスに対する前記リソースの割当量を変更するためのスケジュールを生成するステップを含むことを特徴とするリソース管理方法。
10. 請求項９に記載のリソース管理方法であって、
    前記計算機システムは、前記リクエストの呼出関係を管理するための第１管理情報と、前記リクエストに対応する機能を提供する前記サービスの構成を管理するための第２管理情報を保持し、
    前記第１のステップは、前記制御部が、前記第１管理情報に基づいて、前記関連リクエストを特定するステップを含み、
    前記第２のステップは、前記制御部が、前記第２管理情報に基づいて、前記選択されたターゲットリクエストに対応する機能を提供する前記サービスを特定するステップを含むことを特徴とするリソース管理方法。
11. 請求項１０に記載のリソース管理方法であって、
    前記計算機システムは、前記サービスへの前記リソースの割当量を追加するか否かを判定するための第１閾値及び前記サービスへの前記リソースの割当量を削減するか否かを判定するための第２閾値を含む第３管理情報を保持し、
    前記第５のステップは、
    前記制御部が、前記関連サービスの前記指標の予測値が前記第１閾値より大きいと判定された場合、前記関連サービスに対する前記リソースの割当量を追加するためのリソース追加スケジュールを生成するステップと、
    前記制御部が、前記関連サービスの前記指標の予測値が前記第２閾値より小さいと判定された場合、前記関連サービスに対する前記リソースの割当量を削減するためのリソース削減スケジュールを生成するステップと、を含むことを特徴とするリソース管理方法。
12. 請求項１１に記載のリソース管理方法であって、
    前記計算機システムは、前記リクエストの受付数と、前記サービスの前記指標との関係を管理するための第４管理情報を保持し、
    前記第４管理情報は、前記リクエストの受付に伴って実行される前記サービスが使用するリソース量の上昇率を含み、
    前記第３のステップは、前記制御部が、前記選択されたターゲットリクエストの受付数及び前記第４管理情報に基づいて、前記関連サービスの前記指標の予測値を算出するステップを含み、
    前記第５のステップは、
    前記制御部が、前記関連サービスの前記指標の予測値が前記関連サービスの前記第１閾値より大きいと判定された場合、当該関連サービスの現在の前記指標の値、前記指標の予測値、及び前記関連サービスが使用するリソース量の上昇率に基づいて、前記関連サービスへの前記リソースの割当量の追加を完了する目安となる時間を示す猶予時間を算出するステップと、
    前記制御部が、前記猶予時間を含む前記リソース追加スケジュールを生成するステップと、を含み
    前記リソース管理方法は、前記割当変更部が、前記猶予時間に基づいて、前記リソース追加スケジュールの実行順を決定するステップを含むことを特徴とするリソース管理方法。
13. 請求項１１に記載のリソース管理方法であって、
    前記割当変更部が、前記業務システムにおけるリソースの空き容量に応じて、前記リソース追加スケジュール及び前記リソース削減スケジュールの実行順番を決定するステップを含むことを特徴とするリソース管理方法。
14. 請求項１１に記載のリソース管理方法であって、
    前記リソースは、前記サービスを実行する処理ノードであり、
    前記リソース追加スケジュールは、前記決定された関連サービスを実行する前記処理ノードの数を追加するためのスケジュールであり、
    前記リソース削減スケジュールは、前記決定された関連サービスを実行する前記処理ノードの数を削減するためのスケジュールであることを特徴とするリソース管理方法。

Images