JPWO2018131556A1

JPWO2018131556A1 - リソース設定制御装置、リソース設定制御システム、リソース設定制御方法、および、リソース設定制御プログラム

Info

Publication number: JPWO2018131556A1
Application number: JP2018561355A
Authority: JP
Inventors: 巧藤原
Original assignee: NEC Corp
Current assignee: NEC Corp
Priority date: 2017-01-12
Filing date: 2018-01-09
Publication date: 2019-11-07
Anticipated expiration: 2038-01-09
Also published as: JP6798564B2; US10891164B2; WO2018131556A1; US20190340028A1

Abstract

サービスのバージョン間の移行過程で複数バージョンのサービスを並行して提供するシステムにおいて、バージョン間のリソース分配を適切に行う。ａ）複数バージョンの内の何れかのサービスを要求するサービス要求の、グループ、要求されたバージョン、およびサービス実行中のリソース使用量の情報を含む要求履歴と、ｂ）サービス要求の負荷の基準パターンを格納する稼働情報記憶手段内の要求履歴から、所定期間内のサービス要求の負荷パターンを抽出し、基準パターンとの所定範囲以上の変化を検出すると基準パターンを更新するリソース設定変更判断手段と、負荷パターンの変化検出時に、バージョン毎に、所定期間内のリソース使用量のピーク値とバージョンを提供するサーバ装置数とに基づいてリソース要求量を決定して出力するリソース設定変更手段と、を備えるリソース設定制御装置。

Description

本発明は、リソース設定制御装置、リソース設定制御システム、リソース設定制御方法、および、コンピュータ読み取り可能記録媒体、特に、システム内に複数バージョンのサービスが混在する状況における、リソース配分を行うリソース設定制御に関する。

近年、クラウドの環境の整備や仮想化技術・コンテナ技術の発達に伴い、ＲＥＳＴ(Representational State Transfer)やＳＯＡＰ(Simple Object Access Protocol)などのＷｅｂサービスの活用が進んでいる。Ｗｅｂサービスでは、新たなバージョンのサービスがリリースされた後も、既存のバージョンのサービスがすぐに廃止されるわけではなく、複数のバージョンのサービスが同一マシン上に混在する状況が発生する。一般に、利用者が既存のバージョンのサービスから、新しいバージョンに移行するには、ある程度の時間が必要だからである。

それぞれのバージョンのサービスは疎結合であるが、提供する基本機能はほぼ同じである。そのため、サービスへのリクエストの待ち受けスレッドやＤＢ（Data Base）コネクションなどのリソースのプール管理機能がある場合、バージョン毎のサービスでリソースの確保が必要となる。

このとき、全てのバージョンが一律同じリソース量を必要とするわけではなく、メインで動くバージョンのサービスが有る一方、下位互換のために残ってはいるがほぼ使われないバージョンのサービスなども有る。バージョン毎にリソースを消費する量が異なるため、バージョン毎に適切なリソース割り当てを行うことが重要である。

リソースの配分に関連して、下記のような技術が開示されている。

特許文献１は、サーバ装置の仮想化環境の利便性を向上させる仮想化実行装置を開示する。この装置は、システム構成情報を決定するさい、同じサービスの利用履歴が或るユーザに対しては、過去と同じシステム構成情報を推奨する。また、この装置は、サービス実行時にリソースが不足した場合、仮想計算機やコンテナを追加して、リソース量を拡張する。

特許文献２は、準最適なグリッド環境内でアプリケーションの動作を維持するシステムを開示する。このシステムにおいては、サービス可用性管理エージェントが、リソースノードのパフォーマンス状態を監視する。パフォーマンス状態が規定された動作要件を満たさないとき、サービス可用性管理エージェントはアプリケーションのリソースノードの使用を調整する。

特開２０１６-１１０２４８号公報特表２００７-５１８１６９号公報

複数のバージョンのサービスが同一マシン上に混在する状況において、それぞれのサービスがどの程度のリソース量を必要とするのかは、稼働しているバージョン数、それぞれのサービスを利用するクライアント装置数など、利用者のバージョン移行の進み具合により変化する。このため、システム全体の状況から最適な設定を算出することは難しい。

マシン台数、サービスバージョン数、または、クライアント数が増えた場合、最適な設定値の算出には膨大な処理コストがかかるため、人間がリアルタイムで必要リソース量を算出するのは難しい。

また、クライアントアプリが利用するＷｅｂサービスの新バージョンが追加されと、サービス提供を行うサーバ全体の負荷状況が変わるため、これらの契機に合わせて、サーバ全体のリソースの設定が最適化されるように見直しを行うべきである。しかし、クライアント/サーバ間は疎結合であり、クライアントが呼び出すＷｅｂサービスはクライアントの実装に依存するため、サーバ側でＷｅｂサービスの各バージョンの利用クライアント数を把握することは難しく、設定変更の適切な契機が把握できない。

前述の特許文献１および特許文献２に開示された技術は、いずれも、使用されるサービスのバージョン間の負荷の変化、すなわち、利用者のバージョン移行の進行を契機としてリソースの再配分を行うものではなく、上記課題を解決しない。

本発明は、上記課題を解決し、サービスの移行などに伴い並行して使用されるサービスのバージョン間の負荷の変化を契機としてリソースの配分を見直す、リソース設定制御装置等を提供することを目的とする。

本発明の１実施の形態のリソース設定制御装置は、ａ）複数バージョンの内の何れかのサービスを要求するサービス要求の、グループ、要求された前記バージョン、および前記サービス実行中のリソース使用量の情報を含む要求履歴と、ｂ）前記サービス要求の負荷の基準パターンを格納する稼働情報記憶手段内の前記要求履歴から、所定期間内の前記サービス要求の負荷パターンを抽出し、前記基準パターンとの所定範囲以上の変化を検出すると前記基準パターンを更新するリソース設定変更判断手段と、前記負荷パターンの変化検出時に、前記バージョン毎に、前記所定期間内の前記リソース使用量のピーク値と前記バージョンを提供するサーバ装置数とに基づいてリソース要求量を決定して出力するリソース設定変更手段と、を備える。

本発明の１実施の形態のリソース設定制御方法は、ａ）複数バージョンの内の何れかのサービスを要求するサービス要求の、グループ、要求された前記バージョン、および前記サービス実行中のリソース使用量の情報を含む要求履歴と、ｂ）前記サービス要求の負荷の基準パターンを記憶し、前記要求履歴から、所定期間内の前記サービス要求の負荷パターンを抽出し、前記基準パターンとの所定範囲以上の変化を検出すると前記基準パターンを更新し、前記負荷パターンの変化検出時に、前記バージョン毎に、前記所定期間内の前記リソース使用量のピーク値と前記バージョンを提供するサーバ装置数とに基づいてリソース要求量を決定して出力する。

本発明の１実施の形態のコンピュータ読み取り可能記録媒体は、ａ）複数バージョンの内の何れかのサービスを要求するサービス要求の、グループ、要求された前記バージョン、および前記サービス実行中のリソース使用量の情報を含む要求履歴と、ｂ）前記サービス要求の負荷の基準パターンを格納する稼働情報記憶手段内の前記要求履歴から、所定期間内の前記サービス要求の負荷パターンを抽出し、前記基準パターンとの所定範囲以上の変化を検出すると前記基準パターンを更新するリソース設定変更判断処理と、前記負荷パターンの変化検出時に、前記バージョン毎に、前記所定期間内の前記リソース使用量のピーク値と前記バージョンを提供するサーバ装置数とに基づいてリソース要求量を決定して出力するリソース設定変更処理と、をコンピュータに実行させるリソース設定制御プログラムを非一時的に格納する。

本発明にかかるリソース設定制御装置は、サービスのバージョン間の移行過程で複数バージョンのサービスを並行して提供するシステムにおいて、バージョン間のリソース分配を適切に行うことが出来る。

図１は、第１の実施の形態にかかるリソース設定制御システム４００の構成を示す図である。図２は、バージョン特定ルール記憶部３０１に格納されるバージョン特定ルールの例を示す図である。図３は、グルーピングルール記憶部３０２に格納されるグルーピングルールの例を示す図である。図４は、稼働情報記憶部２０６に格納されるワークロード情報の例を示す図である。図５は、構成情報記憶部２０７に格納されるバージョン毎のサービス稼働状況情報の例を示す図である。図６は、コンピュータ装置６００の構成を示す図である。図７は、ＲＥＳＴサーバ装置１００がリクエストを受信してサービスを実行し、リクエストの履歴がリソース設定制御装置２００の稼働情報記憶部２０６に蓄積されるまでの動作を示すフローチャートである。図８は、リクエスト解析部１０１が行うリクエスト解析の詳細を示すフローチャートである。図９は、リソース設定変更判断部２０５による設定変更判断処理のフローチャートである。図１０は、リソース設定変更部２０４による各バージョンのリソース設定値の計算処理のフローチャートである。図１１は、第２の実施の形態にかかるリソース設定制御システム４００の構成を示す図である。図１２は、第３の実施の形態にかかるリソース設定制御装置２００の構成を示す図である。

＜第１の実施の形態＞
＜構成＞
図１は、第１の実施の形態にかかるリソース設定制御システム４００の構成を示す図である。リソース設定制御システム４００は、通信ネットワークで相互に接続されたＲＥＳＴサーバ装置１００とリソース設定制御装置２００、並びに、ＲＥＳＴサーバ装置１００に接続されたサービスクライアント装置３００を包含する。ＲＥＳＴサーバ装置１００とサービスクライアント装置３００は、複数台存在しても良い。

ＲＥＳＴサーバ装置１００は、複数バージョンのサービスをサービスクライアント装置３００に対して提供する。リソース設定制御装置２００は、バージョン間のリソース配分を決定する。ここで、リソースは、例えば、プール管理されている、サービスへのリクエストの待ち受けスレッドやＤＢコネクション、メモリ領域、通信パスである。

ＲＥＳＴサーバ装置１００は、サービス実行部１０３、リクエスト解析部１０１、および、リソース使用量採取部１０２を備えている。ＲＥＳＴサーバ装置１００は、バージョン特定ルール記憶部３０１とグルーピングルール記憶部３０２を備えている、または、他の装置と共有している。

サービス実行部１０３は、サービスクライアント装置３００から、サービスリクエスト（以降、リクエストと略記する）を受信して、指定されたバージョンのサービスを実行する。ＲＥＳＴサーバ装置１００が複数存在するとき、各サービスクライアント装置３００のリクエストは、例えば、図示しないロードバランサにより、適宜、何れかのＲＥＳＴサーバ装置１００に振り分けられる。

リクエスト解析部１０１は、サービスへのリクエストを解析し、利用サービスのバージョン特定および、リクエストのグルーピングを行う。この時、リクエスト解析部１０１は、バージョン特定ルール記憶部３０１とグルーピングルール記憶部３０２を参照する。

リソース使用量採取部１０２は、サービスの実行時のリソース使用量をバージョン単位でグループを識別できるように採取して、リソース設定制御装置２００に送信する。

リソース設定制御装置２００は、ワークロード情報採取部２０１、ノイズ判定部２０２、サービス構成管理部２０３、リソース設定変更部２０４、および、リソース設定変更判断部２０５を備えている。リソース設定制御装置２００は、さらに、稼働情報記憶部２０６と構成情報記憶部２０７を備えている。

ワークロード情報採取部２０１は、各々のＲＥＳＴサーバ装置１００のリソース使用量採取部１０２からサービスの実行時のリソース使用量を受信して、稼働情報記憶部２０６に格納し、リソース設定制御システム４００の統合された記録として蓄積する。

サービス構成管理部２０３は、構成情報記憶部２０７を利用して、リソース設定制御システム４００全体でバージョン毎のサービス稼働状況を把握する。

リソース設定変更判断部２０５は、稼働情報記憶部２０６に蓄積された情報を基に、分散環境で発生して処理されたリクエストの負荷パターンを抽出し、その状況に基づいて、バージョン間のリソースの配分変更の要否をチェックする。このとき、ノイズ判定部２０２は、負荷パターンのノイズ的な情報から、長期的な負荷パターンの変化の有無をチェックする。

リソース設定変更部２０４は、リソース設定制御システム４００全体でのバージョン毎のサービス稼働状況とリクエストのグループのリソース使用状況から、バージョン毎のリソースの適切な設定値を算出する。そして、リソース設定変更部２０４は、算出値に基づくリソース配分変更指示を、ＲＥＳＴサーバ装置１００に送信する。

図２は、バージョン特定ルール記憶部３０１に格納されるバージョン特定ルールの例を示す図である。リクエスト解析部１０１は、バージョン特定ルール記憶部３０１に格納されているバージョン特定ルールに従って、リクエストの情報から要求されているサービスのバージョンを特定する。バージョン特定ルールは、リクエストのどの情報のどの部分からバージョン情報を抽出するかを指定する。

図２のａ）は、ＵＲＬ（Uniform Resource locator）でバージョン判定する設定例である。このルールは、リクエストのＵＲＬパスの”version”で示された、”rest/”に続く部分からバージョン情報を抽出することを指定している。

図２のｂ）は、ポート番号でバージョン判定する設定例である。このルールは、リクエストのポート番号の”version”で示された、”//<host>/”に続く部分からバージョン情報を抽出することを指定している。

図２のｃ）は、同様に、クエリパラメータでバージョン判定する設定例である。このルールは、”version=“に続く部分からバージョン情報を抽出することを指定している。

図３は、グルーピングルール記憶部３０２に格納されるグルーピングルールの例を示す図である。リクエスト解析部１０１は、グルーピングルール記憶部３０２に格納されているグルーピングルールに従って、リクエストが属するグループ識別子を特定する。グルーピングルールは、リクエストのどの情報のどの部分からグループ識別子を抽出するかを指定する。

図３のａ）は、認証Ｉｄ（Identification）でグルーピングする設定例である。このルールは、リクエストのＨＴＴＰ（Hyper Text Transfer Protocol）ヘッダキーのＡＵＴＨ＿ＩＤフィールドからグループ識別子を抽出することを指定している。

図３のｂ）は、認証Ｉｄの一部でグルーピングする設定例である。このルールは、リクエストのＨＴＴＰヘッダキーのＡＵＴＨ＿ＩＤフィールドの０乃至５バイト目からグループ識別子を抽出することを指定している。なお、substringは、値の切り取りを指定する関数である。

図３のｃ）は、クライアントアプリのTypeでグルーピングする設定例である。このルールは、リクエストのパラメータキーCLIENT_TYPEからグループ識別子を抽出することを指定している。

図４は、稼働情報記憶部２０６に格納されるワークロード情報の例を示す図である。ワークロード情報は、各ＲＥＳＴサーバ装置１００が受信して処理したリクエストの履歴である。このリクエスト履歴情報は、各ＲＥＳＴサーバ装置１００のリクエスト解析部１０１と、リソース使用量採取部１０２が収集した情報である。履歴内の各リクエストレコードは、例えば、処理完了時刻、要求されたサービスのバージョン特定情報、グループ識別子、および、当該リクエストの処理に要したリソースの種類と使用量である。

図５は、構成情報記憶部２０７に格納されるバージョン毎のサービス稼働状況情報の例を示す図である。サービス稼働状況情報は、例えば、ＲＥＳＴサーバ装置１００の識別子（マシンＡ、マシンＢ等）と、当該ＲＥＳＴサーバ装置１００上で提供されているサービスのバージョン番号を関連付けて格納している。図５の例は、Ｖ１で示されるバージョン１は、マシンＡとＢの２台のＲＥＳＴサーバ装置１００上でサービスされていることを示している。

ここで、ＲＥＳＴサーバ装置１００のサービス実行部１０３、リクエスト解析部１０１、および、リソース使用量採取部１０２は、論理回路で構成される。バージョン特定ルール記憶部３０１とグルーピングルール記憶部３０２は、ディスク等の不揮発性の記憶装置に記憶される。

ＲＥＳＴサーバ装置１００は、コンピュータ装置６００により実現されても良い。図６は、コンピュータ装置６００の構成を示す図である。コンピュータ装置６００は、バス６４０で相互に接続された、プロセッサ６１０、主記憶部６３０、および、外部記憶装置６２０を備える。プロセッサ６１０は、バス６４０を経由して、主記憶部６３０、および、外部記憶装置６２０に対してデータの読み書きを行う。また、プロセッサ６１０は、主記憶部６３０に格納されているプログラム６５０を実行する。なお、プログラム６５０は、当初外部記憶装置６２０に格納されており、コンピュータ装置６００の初期設定時に、プロセッサ６１０が外部記憶装置６２０から主記憶部６３０にロードしても良い。

ここで、主記憶部６３０は半導体メモリ装置である。外部記憶装置６２０はディスク装置、または、半導体記憶装置等の記憶装置である。

プロセッサ６１０は、プログラム６５０を実行することにより、サービス実行部１０３、リクエスト解析部１０１、および、リソース使用量採取部１０２として機能する。すなわち、プロセッサ６１０は、プログラム６５０を実行することにより、サービス実行部１０３、リクエスト解析部１０１、および、リソース使用量採取部１０２が行う処理を実行する。

外部記憶装置６２０は、バージョン特定ルール記憶部３０１とグルーピングルール記憶部３０２として使用されても良い。

さらに、リソース設定制御装置２００のワークロード情報採取部２０１、ノイズ判定部２０２、サービス構成管理部２０３、リソース設定変更部２０４、および、リソース設定変更判断部２０５は、論理回路で構成される。稼働情報記憶部２０６と構成情報記憶部２０７は、ディスク等の不揮発性の記憶装置に記憶される。

リソース設定制御装置２００は、図６に示されるコンピュータ装置６００により実現されても良い。

プロセッサ６１０は、プログラム６５０を実行することにより、ワークロード情報採取部２０１、ノイズ判定部２０２、サービス構成管理部２０３、リソース設定変更部２０４、および、リソース設定変更判断部２０５として機能する。すなわち、プロセッサ６１０は、プログラム６５０を実行することにより、ワークロード情報採取部２０１、ノイズ判定部２０２、サービス構成管理部２０３、リソース設定変更部２０４、および、リソース設定変更判断部２０５が行う処理を実行する。

外部記憶装置６２０は、稼働情報記憶部２０６や構成情報記憶部２０７として使用されても良い。

＜動作＞
図７は、ＲＥＳＴサーバ装置１００がリクエストを受信してサービスを実行し、リクエストの履歴がリソース設定制御装置２００の稼働情報記憶部２０６に蓄積されるまでの動作を示すフローチャートである。

まず、サービスクライアント装置３００は、サービス（ＲＥＳＴＡＰＩ）を実行するため、クライアントの認証を行う（Ｓ１）。ＲＥＳＴサーバ装置１００は、クライアントを認証し、認証済のトークンをサービスクライアント装置３００に払い出す。以降のサービスクライアント装置３００からのリクエストは、認証済のトークンを付与されて、ＲＥＳＴサーバ装置１００へ送付される。

ＲＥＳＴサーバ装置１００のサービス実行部１０３は、リクエストを受け取るとサービスを実行する（Ｓ２）。サービス実行に際し、リクエスト解析部１０１は、リクエストを解析して、リクエストから、呼び出しているサービスのバージョンの特定、および、グルーピングを行うためのグループ識別子抽出を行い、リソース設定制御装置２００に送信する（Ｓ３）。

図８は、図７ｂのＳ３において、リクエスト解析部１０１が行うリクエスト解析の詳細を示すフローチャートである。

リクエスト解析部１０１は、先ず、バージョン特定ルール記憶部３０１に保存されたバージョン特定ルールを用いて（Ｓ１１）、送信されたリクエストの情報から、そのリクエストがどのバージョンのサービス要求であるかを特定し、リソース設定制御装置２００に送信する（Ｓ１２）。

バージョンは、ＵＲＬパスによって指定されることがある。この場合、ＲＥＳＴサーバ装置１００は、例えば、バージョン１のＡＰＩを「http://host/api/v1/service」のようなパスで、バージョン２のＡＰＩを「http://host/api/v2/service」のようなパスで、公開する。そして、リクエスト解析部１０１は、http://host/api/v1/はバージョン１のＡＰＩ、http://host/api/v2/はバージョン２のＡＰＩと、パス内に含まれた情報を用いてバージョンを認識する。

この場合、バージョン特定ルールは、バージョンの識別に「ＵＲＬパス」を利用することと、ＵＲＬパスの文字列の中でバージョンを示す場所を記載する（図２のａ）参照）。

次に、リクエスト解析部１０１は、グルーピングルール記憶部３０２に保存されたグルーピングルールを用いて（Ｓ１３）、送信されたリクエストの情報から、そのリクエストが属するグループの識別子を抽出し、リソース設定制御装置２００に送信する（Ｓ１４）。

リクエストは、意味のある単位でグルーピングされる。例えば、同一Ｉｄのユーザからきたリクエストを１つのグループとして利用する場合、リクエスト解析部１０１は、リクエスト内からユーザＩｄをグループ識別子として抽出する。別の例として、ユーザが属する会社毎にリクエストを束ねる場合は、リクエスト解析部１０１は、Ｉｄ内に含まれる会社コードを抽出する。

リソース設定制御システム４００の管理者は、先ず、バージョン間のリソース配分決定の為に、リグエストをどのようにグルーピングするかを決定する。次に、管理者は、そのグループの識別情報をリクエストのどこから抽出すべきかを、グルーピングルールとして予めグルーピングルール記憶部３０２内に格納しておくのである（図３参照）。

リクエスト解析（図７のＳ３）が終了すると、リソース使用量採取部１０２は、リクエストの実行に使用したリソース使用量を、例えば、サービス実行部１０３から取得し、リソース設定制御装置２００に送信する（Ｓ４）。具体的には、サービス実行部１０３が、リクエスト実行中にリソース使用量を監視してリクエストに記録し、リソース使用量採取部１０２が、その記録を参照すれば良い。

リソース設定制御装置２００では、ワークロード情報採取部２０１が、リクエスト解析部１０１とリソース使用量採取部１０２から送られてきた情報を受信して（Ｓ５）、稼働情報記憶部２０６にリクエスト履歴として蓄積していく（Ｓ６、図４参照）。このとき、ワークロード情報採取部２０１は、ログインからログアウトを１つのワークロードと見なし、リクエストを時間帯別にグループ毎に記録していく。

図９は、リソース設定変更判断部２０５による設定変更判断処理のフローチャートである。リソース設定変更判断部２０５は、所定の期間毎に起動され、稼働情報記憶部２０６のリクエスト履歴から負荷パターンを抽出する（Ｓ２１）。定常化された運用の多くの場合、ある一定の周期でリクエスト送信をパターン化することができる。リソース設定変更判断部２０５は、リクエストの履歴から、所定の期間ごとにこのパターンを抽出するのである。

この所定期間は、１日、１週間、１か月など、リクエストをある時系列の固まりで意味づけしたときに、リクエストの送信タイミングに傾向が出てくる単位期間であり、例えば、以下のような期間である。
・１日の中で特定の時間のみ負荷が高く／低くなるときは、所定期間は日単位とし、リソース設定変更判断部２０５は、時間ごとの負荷のパターンを抽出する。
・１週間の中で特定の曜日のみ負荷が高く／低くなるときは、所定期間は１週間単位とし、リソース設定変更判断部２０５は、曜日ごとの負荷のパターンを抽出する。
・１ヶ月の中で、月初めや月終わりの週や日で負荷が高く／低くなるときは、所定期間は1か月単位とし、リソース設定変更判断部２０５は、週や日ごとの負荷のパターンを抽出する。
・四半期（３ヶ月）の中で、期の初めや終わりの月、週や日で負荷が高く／低くなるときは、所定期間は四半期単位とし、リソース設定変更判断部２０５は、月や週や日ごとの負荷のパターンを抽出する。
・半年や年の中で、特定の月や週や日で負荷が高く／低くなるときは、所定期間は、半年や年単位とし、月や週や日ごとの負荷のパターンを抽出する。

リソース設定変更判断部２０５は、Ｓ２１で、最新周期のリクエスト履歴から負荷パターンを抽出した後に、このパターンを基準パターンと比較し、有意差が有れば（Ｓ２２で”Ｙｅｓ”）、基準パターンを更新して（Ｓ２３）、リソース設定変更部２０４を起動する（Ｓ２４）。無ければ（Ｓ２２で”Ｎｏ”）、リソース設定変更判断部２０５は、ノイズ判定部２０２を起動する（Ｓ２６）。

上記説明から明らかなように、基準パターンは、過去の周期で確立された最新の負荷パターンであり、最新周期のリクエスト履歴から抽出される負荷パターンの変化を判定する為の基準となるものである。基準パターンは、例えば、稼働情報記憶部２０６に格納されており、初期値は管理者により与えられる。

起動されると、ノイズ判定部２０２は、抽出した負荷パターンと基準パターンと差異をノイズとして記録し（Ｓ２６）、過去の数周期分の差異との比較を行い、差異が定常的であれば（Ｓ２７で”Ｙｅｓ”）、リソース設定変更判断部２０５に通知する。リソース設定変更判断部２０５はその通知を受けて、基準パターンを更新して（Ｓ２３）、リソース設定変更部２０４を起動する（Ｓ２４）。差異が定常的でなければ（Ｓ２７で”Ｎｏ”）、リソース設定変更判断部２０５およびノイズ判定部２０２は、この周期の動作を終了する。

なお、リソース設定変更判断部２０５は、バージョン毎にパターンの抽出、有意判定、および、基準パターン変更を、バージョン毎に実行しても良いし、全バージョン横断的に実行しても良い。バージョン毎に実行した場合、リソース設定変更判断部２０５は、何れかのバージョンの負荷パターンに有意差が有れば（Ｓ２２で”Ｙｅｓ”）、当該バージョンの基準パターンを更新して（Ｓ２３）、リソース設定変更部２０４を起動する（Ｓ２４）。

なお、ここで、リソース設定変更判断部２０５が、ａ）リクエスト履歴から抽出する負荷パターン、ｂ）有意差の判定に使用する閾値、ノイズ判定部２０２が、ｃ）記録する基準パターンとの差異は、例えば以下の通りである。

例１：
ａ）各グループの最頻度要求バージョン、ｂ）各グループの新最頻度要求バージョンの要求出現率の基準パターンとの差異（例えば、新たに最頻度要求バージョンとなったもの出現率が２０％以上増加していたら有意差とする）、ｃ）今周期の各グループの最頻度要求バージョン
例２：
ａ）ピークリソース使用量の出現タイミング（時間、曜日、日付、月）、ｂ）出現タイミングの変化量（例えば、２日以上タイミングが変化したら有意差とする）、ｃ）今周期のピークリソース使用量の出現タイミング
例３：
ａ）所定期間内の各タイミングにおけるリソース使用量分布、ｂ）各タイミングでのリソース使用量差異の絶対値の総和（例えば、各曜日のスレッド使用量の差の総和が５０以上なら有意差とする）、ｃ）今周期のリソース使用量分布
例４：
ａ）出現グループ、ｂ）およびｃ）無（グループの消滅、新規登場は、無条件に有意差と判定する）
ノイズ判定部２０２は、記録する基準パターンとの差異が、所定数の周期の間、全く変化が無ければ、Ｓ２７で差異は定常的と判断しても良いし、或る範囲の変動を許容して定常的と判断しても良い。ノイズ判定部２０２は、基準パターンとの差異を、例えば、稼働情報記憶部２０６に記録する。

Ｓ２４で起動されたリソース設定変更部２０４は、バージョン毎のピーク値(例えば、ピ時間帯と使用量)を、時系列データを用いて算出し、それらのリソース消費量から全バージョン累計のシステム全体のリソース使用状況を時系列データとして算出する。

図１０は、リソース設定変更部２０４による各バージョンのリソース設定値の計算処理のフローチャートである。

リソース設定変更部２０４は、サービス構成管理部２０３からリソース設定制御システム４００において、各バージョンのサービスを提供しているＲＥＳＴサーバ装置１００の台数を取得する（Ｓ３１）。

次に、リソース設定変更部２０４は、稼働情報記憶部２０６のリクエスト履歴からバージョン毎のピーク時のリソース使用量を算出し、バージョン毎に稼働しているＲＥＳＴサーバ装置１００の台数で割って数値(ａ)を算出する（Ｓ３２）。また、リソース設定変更部２０４は、バージョン毎にピーク時に最もリソースを消費しているグループのリソース消費量（ｂ）を算出する（Ｓ３３）。

リソース設定変更部２０４は、バージョンごとに、（ａ）の情報と（ｂ）の情報を比較し、（ａ）が大きい場合は（ａ）をリソース設定値とする。リソース設定変更部２０４は（ｂ）のほうが大きい場合、（ｂ）の値をリソースの設定値とする（Ｓ３４乃至Ｓ３６）。これは、（ｂ）の値が大きなときは、特定のマシンに高負荷がかかることが考えられ、均等に割り振ったリソース設定では、処理がさばききれなくなる恐れが有るからである。

最後に、リソース設定変更判断部２０５は、上記の方法で算出したリソース設定値を各ＲＥＳＴサーバ装置１００にリソース要求量として配信する（図９のＳ２５）。

各ＲＥＳＴサーバ装置１００では、例えば、サービス実行部１０３がこのリソース要求量を受信して、指定されたバージョンのリソースプールのリソース量を変更する。

＜効果＞
本実施の形態にかかるリソース設定制御装置２００は、サービスのバージョン間の移行過程で複数バージョンのサービスを並行して提供するリソース設定制御システム４００において、バージョン間のリソース分配を適切に行うことが出来る。

その理由は、リソース設定変更判断部２０５が、リクエスト履歴に基づいて負荷パターンの変化（移行の進展）を検知し、リソース設定変更部２０４が、バージョン毎のリソース使用量に基づいて、各バージョンに割当てられるリソース量を決定するからである。

さらに、本実施の形態にかかるリソース設定制御装置２００は、クライアントが有る程度の数でサービス移行した時は、早いタイミングで、バージョン間のリソース設定の再配分を実施できる。

その理由は、負荷パターンが所定閾値以上変動した場合は、リソース設定変更判断部２０５が、所定周期ごとに変動を検知するからである。

さらに、本実施の形態にかかるリソース設定制御装置２００は、クライアントが少しずつサービス移行した場合でも、バージョン間のリソース設定の再配分を、適切に実施できる。

その理由は、負荷パターンが所定閾値以内で変動した場合は、ノイズ判定部２０２が、複数の所定周期ごとに変動を検知するからである。

＜第２の実施形態＞
図１１は、第２の実施の形態にかかるリソース設定制御システム４００の構成を示す図である。第１の実施の形態にかかるリソース設定制御システム４００は、リソース設定制御装置２００とＲＥＳＴサーバ装置１００を別に設けているが、本実施の形態では両者を統合する。例えば、第１の実施の形態におけるリソース設定制御装置２００内の構成要素を全て各ＲＥＳＴサーバ装置１００上に配置する。配置の変更は、逆でも良い。

ログインからログアウトまでの処理をまとめて稼働情報記憶部２０６に記録するため、ＲＥＳＴサーバ装置１００は、相互に協調して、記録前の稼働情報を共有する。協調動作はワークロード情報共有部２０８によって実現され、各ＲＥＳＴサーバ装置１００で稼働情報記憶部２０６を共有する。

情報の共有は、リクエストを受けたバージョンと同じバージョンのサービスが動作しているＲＥＳＴサーバ装置１００のみでなされれば良い。このため、ワークロード情報共有部２０８は、サービス構成管理部２０３から構成情報を得て共有範囲を決定する。

＜第３の実施形態＞
図１２は、第３の実施の形態にかかるリソース設定制御装置２００の構成を示す図である。リソース設定制御装置２００は、リソース設定変更判断部２０５、リソース設定変更部２０４、および、稼働情報記憶部２０６を備える。リソース設定制御装置２００は、稼働情報記憶部２０６を備える代わりに、通信網を経由して、例えば遠隔地の稼働情報記憶部２０６に接続されていても良い。

稼働情報記憶部２０６は、複数バージョンの内の何れかのサービスを要求するサービス要求の、グループ、要求されたバージョン、およびサービス実行中のリソース使用量の情報を含む要求履歴を格納している。これらの情報は、当該サービスを提供するサーバ装置からリアルタイムに、あるいは、定期的に一括して送信されてくる。リソース設定変更判断部２０５の処理周期が長い時は、可換媒体による人手によるデータ移動でも良い。さらに、稼働情報記憶部２０６は、サービス要求の負荷の基準パターンを格納する。

リソース設定変更判断部２０５は、稼働情報記憶部２０６内の要求履歴から、所定期間内のサービス要求の負荷パターンを抽出し、基準パターンとの所定範囲以上の変化を検出すると基準パターンを更新する。

負荷パターンの変化が検出された時に、リソース設定変更部２０４は、バージョン毎に、所定期間内のリソース使用量のピーク値とバージョンを提供するサーバ装置数とに基づいてリソース要求量を決定して出力する。

出力されたリソース要求量は、例えば、サーバ装置がこのリソース要求量を受信して、指定されたバージョンのリソース量を変更する。

本実施の形態にかかるリソース設定制御装置２００は、サービスのバージョン間の移行過程で複数バージョンのサービスを並行して提供するリソース設定制御システム４００において、バージョン間のリソース分配を適切に行うことが出来る。

以上、実施形態を参照して本願発明を説明したが、本願発明は上記実施形態に限定されるものではない。本願発明の構成や詳細には、本願発明のスコープ内で当業者が理解し得る様々な変更をすることができる。

この出願は、２０１７年１月１２日に出願された日本出願特願２０１７−３０８３を基礎とする優先権を主張し、その開示の全てをここに取り込む。

１００ＲＥＳＴサーバ装置
１０１リクエスト解析部
１０２リソース使用量採取部
１０３サービス実行部
２００リソース設定制御装置
２０１ワークロード情報採取部
２０２ノイズ判定部
２０３サービス構成管理部
２０４リソース設定変更部
２０５リソース設定変更判断部
２０６稼働情報記憶部
２０７構成情報記憶部
２０８ワークロード情報共有部
３００サービスクライアント装置
３０１バージョン特定ルール記憶部
３０２グルーピングルール記憶部
４００リソース設定制御システム
６００コンピュータ装置
６１０プロセッサ
６２０外部記憶装置
６３０主記憶部
６４０バス
６５０プログラム

Claims

ａ）複数バージョンの内の何れかのサービスを要求するサービス要求の、グループ、要求された前記バージョン、および前記サービス実行中のリソース使用量の情報を含む要求履歴と、ｂ）前記サービス要求の負荷の基準パターンを格納する稼働情報記憶手段内の前記要求履歴から、所定期間内の前記サービス要求の負荷パターンを抽出し、前記基準パターンとの所定範囲以上の変化を検出すると前記基準パターンを更新するリソース設定変更判断手段と、
前記負荷パターンの変化検出時に、前記バージョン毎に、前記所定期間内の前記リソース使用量のピーク値と前記バージョンを提供するサーバ装置数とに基づいてリソース要求量を決定して出力するリソース設定変更手段と、を備えるリソース設定制御装置。
前記グループは、前記サービス要求の送信元に基づいて構成されており、
前記リソース設定変更判断手段は、前記グループと、要求する前記バージョンの対応関係を前記負荷パターンとして抽出する、請求項１のリソース設定制御装置。
前記所定期間は、日であり、前記リソース設定変更判断手段は、所定の時刻における前記サービス要求の負荷を前記負荷パターンとして抽出する、
前記所定期間は、週であり、前記リソース設定変更判断手段は、所定の曜日における前記サービス要求の負荷を前記負荷パターンとして抽出する、
前記所定期間は、月であり、前記リソース設定変更判断手段は、前記所定期間における所定の順番の日、若しくは週における前記サービス要求の負荷を前記負荷パターンとして抽出する、または、
前記所定期間は、複数の月であり、前記リソース設定変更判断手段は、前記所定期間における所定の順番の日、週、若しくは月における前記サービス要求の負荷を前記負荷パターンとして抽出する、請求項１乃至請求項２のいずれか１項のリソース設定制御装置。
前記負荷パターンと前記基準パターンとの差異をノイズとして記録し、複数の前記所定期間の前記ノイズに基づいて、前記基準パターンの更新要否を判定するノイズ判定手段を、さらに備える、請求項１乃至請求項３のいずれか１項のリソース設定制御装置。
前記リソース設定変更手段は、前記バージョンごとに、ａ）前記所定期間内の前記リソース使用量のピーク値を前記バージョンの前記サービスを提供する前記サーバ装置数で除した値と、ｂ）前記バージョンを要求する前記グループの中の最大の前記リソース使用量との大きな方の値を前記リソース要求量に決定する、請求項１乃至請求項４のいずれか１項のリソース設定制御装置。
前記サービス要求から要求された前記バージョンの前記サービスを実行するサービス実行手段と、
前記サービス要求から、前記グループと前記バージョンの情報を抽出して送信するリクエスト解析手段と、
前記サービス要求が前記サービスの実行中に使用した前記リソース使用量を採取して送信するリソース使用量採取手段と、を備える複数の前記サーバ装置、並びに、
前記稼働情報記憶手段と、
前記グループと前記バージョンの情報、および、前記使用リソース量を受信して前記稼働情報記憶手段に追記するワークロード情報採取手段を備える、請求項１乃至請求項５のいずれか１項のリソース設定制御装置と、を包含するリソース設定制御システム。
前記リクエスト解析手段は、ａ）前記サービス要求から要求された前記サービスの前記バージョンの情報を抽出する第１のルールを格納するバージョン特定ルール記憶手段から前記第１のルールを、ｂ）前記サービス要求から前記グループの情報を抽出する第２のルールを格納するグルーピングルール記憶手段から前記第２のルールを、取得し、前記第１のルールと前記第２のルールを適用して、前記サービス要求から、前記グループと前記バージョンの情報を抽出する、請求項６のリソース設定制御システム。
ａ）複数バージョンの内の何れかのサービスを要求するサービス要求の、グループ、要求された前記バージョン、および前記サービス実行中のリソース使用量の情報を含む要求履歴と、ｂ）前記サービス要求の負荷の基準パターンを記憶し、
前記要求履歴から、所定期間内の前記サービス要求の負荷パターンを抽出し、前記基準パターンとの所定範囲以上の変化を検出すると前記基準パターンを更新し、
前記負荷パターンの変化検出時に、前記バージョン毎に、前記所定期間内の前記リソース使用量のピーク値と前記バージョンを提供するサーバ装置数とに基づいてリソース要求量を決定して出力する、リソース設定制御方法。
前記グループは、前記サービス要求の送信元に基づいて構成されており、
前記グループと、要求する前記バージョンの対応関係を前記負荷パターンとして抽出する、請求項８のリソース設定制御方法。
ａ）複数バージョンの内の何れかのサービスを要求するサービス要求の、グループ、要求された前記バージョン、および前記サービス実行中のリソース使用量の情報を含む要求履歴と、ｂ）前記サービス要求の負荷の基準パターンを格納する稼働情報記憶手段内の前記要求履歴から、所定期間内の前記サービス要求の負荷パターンを抽出し、前記基準パターンとの所定範囲以上の変化を検出すると前記基準パターンを更新するリソース設定変更判断処理と、
前記負荷パターンの変化検出時に、前記バージョン毎に、前記所定期間内の前記リソース使用量のピーク値と前記バージョンを提供するサーバ装置数とに基づいてリソース要求量を決定して出力するリソース設定変更処理と、をコンピュータに実行させるリソース設定制御プログラムを格納するコンピュータ読み取り可能記録媒体。