図面 (/)

技術 性能調整プログラム、および性能調整方法

出願人 富士通株式会社
発明者 尾上浩一
出願日 2018年2月5日 (2年5ヶ月経過) 出願番号 2018-018214
公開日 2019年8月15日 (10ヶ月経過) 公開番号 2019-135597
状態 未査定
技術分野 マルチプログラミング
主要キーワード 追加予定 性能調整 配置変換 コンテナ配置 配置サーバ 余剰量 コンテナ数 スケールアウト
関連する未来課題
重要な関連分野

この項目の情報は公開日時点(2019年8月15日)のものです。
また、この項目は機械的に抽出しているため、正しく解析できていない場合があります

図面 (20)

課題

性能悪化要因の処理を特定できるようにする。

解決手段

管理装置10は、所定の処理性能による調整対象処理の実行機能である1または複数の単位機能5a,5bそれぞれを、1または複数のサーバのいずれかで実現させることで、調整対象処理を1または複数のサーバに実行させる。次に管理装置10は、調整対象処理を利用して提供されるサービス8の性能を示す性能情報を取得する。次に管理装置10は、性能情報が、サービスに求められる性能を示す性能要件を満たしているか否かを判断する。そして管理装置10は、性能情報が性能要件を満たしていない場合、性能情報と現在の単位機能5a,5bの数とに基づいて、1または複数のサーバのいずれかで実現させる単位機能5a,5bの増加数を決定する。

概要

背景

クラウドコンピューティング技術により、ユーザが望む量のコンピュータリソースネットワーク経由でユーザに提供することが容易となっている。クラウドコンピューティングのなかには、例えばアプリケーションソフトウェア(以下、アプリケーションと呼ぶ)を稼働させるためのプラットフォーム利用環境を、ネットワークを介してユーザに提供するPaaS(Platform as a Service)がある。

PaaSを利用したサービスは、例えばマイクロサビスアーキテクチャと呼ばれる技術思想に基づいて構築することができる。マイクロサービスアーキテクチャでは、1つのサービスを提供するソフトウェアが、コンポーネントと呼ばれる複数の小さなアプリケーションに分割して作成される。複数のコンポーネントを組み合わせて1つのサービスを提供することによって、処理能力の増強を、コンポーネント単位で実施することができる。これにより、あるコンポーネントの処理負荷が過大となった場合、そのコンポーネントについて処理能力の増強を行えばよく、他のコンポーネントは変更せずにすむ。

コンポーネントの実行単位コンテナと呼ばれる。コンポーネントの処理能力を増強する場合、管理者は、例えば増強対象のコンポーネント用のコンテナ数を増加(スケールアウト)させる。コンテナ数の増減でサービスの性能調整ができることにより、システムリソースを効率的に利用することができる。このようなコンテナを利用したPaaSシステムは、Container-based PaaS Platformと呼ばれる。

リソース利用の効率化に関する技術としては、例えば仮想環境における余剰リソースの抑制を図り、効率的なシステム運用を可能とする仮想化環境管理システムがある。

概要

性能悪化要因の処理を特定できるようにする。管理装置10は、所定の処理性能による調整対象処理の実行機能である1または複数の単位機能5a,5bそれぞれを、1または複数のサーバのいずれかで実現させることで、調整対象処理を1または複数のサーバに実行させる。次に管理装置10は、調整対象処理を利用して提供されるサービス8の性能を示す性能情報を取得する。次に管理装置10は、性能情報が、サービスに求められる性能を示す性能要件を満たしているか否かを判断する。そして管理装置10は、性能情報が性能要件を満たしていない場合、性能情報と現在の単位機能5a,5bの数とに基づいて、1または複数のサーバのいずれかで実現させる単位機能5a,5bの増加数を決定する。

目的

クラウドコンピューティング技術により、ユーザが望む量のコンピュータリソースをネットワーク経由でユーザに提供する

効果

実績

技術文献被引用数
0件
牽制数
0件

この技術が所属する分野

(分野番号表示ON)※整理標準化データをもとに当社作成

ライセンス契約や譲渡などの可能性がある特許掲載中! 開放特許随時追加・更新中 詳しくはこちら

請求項1

コンピュータに、所定の処理性能による調整対象処理の実行機能である1または複数の単位機能それぞれを、1または複数のサーバのいずれかで実現させることで、前記調整対象処理を前記1または複数のサーバに実行させ、前記調整対象処理を利用して提供されるサービスの性能を示す性能情報を取得し、前記性能情報が、前記サービスに求められる性能を示す性能要件を満たしているか否かを判断し、前記性能情報が前記性能要件を満たしていない場合、前記性能情報と現在の前記単位機能の数とに基づいて、前記1または複数のサーバのいずれかで実現させる前記単位機能の増加数を決定する、処理を実行させる性能調整プログラム

請求項2

前記増加数の決定では、前記性能情報から算出された性能値を現在の前記単位機能の数で除算することで、1単位機能当たりの前記性能値への寄与度を算出し、現在の前記単位機能の数に整数加算した加算値と前記寄与度との乗算結果が、前記性能要件として示される閾値以上となる、最小の前記整数を、前記増加数に決定する、請求項1記載の性能調整プログラム。

請求項3

前記コンピュータに、さらに、前記1または複数のサーバの中から、決定された前記増加数分の追加単位機能それぞれを実現させるサーバを決定し、実現させるサーバの決定に従って、前記追加単位機能それぞれを前記1または複数のサーバのいずれかが実現するように、前記1または複数のサーバを制御する、請求項1または2に記載の性能調整プログラム。

請求項4

前記追加単位機能それぞれを実現させるサーバの決定では、前記追加単位機能それぞれを前記1または複数のサーバのいずれかで実現させた場合に、リソース余剰量が最も多いサーバを、前記追加単位機能を実現させるサーバに決定する、請求項3記載の性能調整プログラム。

請求項5

前記追加単位機能それぞれを実現させるサーバの決定では、現在の前記単位機能それぞれによるサーバのリソース使用量を示す数値の合計を、現在の前記単位機能の数に前記増加数を加算した加算値によって除算し、除算結果を1単位機能当たりのリソース使用量とし、前記1単位機能当たりのリソース使用量に基づいて、前記追加単位機能それぞれを、前記1または複数のサーバのいずれかで実現させた場合の、前記1または複数のサーバの前記余剰リソースを計算する、請求項4記載の性能調整プログラム。

請求項6

前記コンピュータに、さらに、前記サービスは複数の処理を連係させることで提供されており、前記性能情報が前記性能要件を満たしていない場合、直近の所定期間における前記複数の処理それぞれの動作状態を示す第1状態情報を取得し、前記サービスの性能が前記性能要件を満たしているときの前記複数の処理それぞれの動作状態を示す第2状態情報と、前記第1状態情報とに基づいて、前記性能要件が満たされているときと満たされていないときとの動作状態の差を、前記複数の処理それぞれについて計算し、前記複数の処理それぞれの動作状態の差に基づいて、前記サービスの性能悪化要因となっている処理を判定し、前記性能悪化要因となっている処理を、前記調整対象処理に決定する、処理を実行させる請求項1ないし5のいずれかに記載の性能調整プログラム。

請求項7

コンピュータが、所定の処理性能による調整対象処理の実行機能である1または複数の単位機能それぞれを、1または複数のサーバのいずれかで実現させることで、前記調整対象処理を前記1または複数のサーバに実行させ、前記調整対象処理を利用して提供されるサービスの性能を示す性能情報を取得し、前記性能情報が、前記サービスに求められる性能を示す性能要件を満たしているか否かを判断し、前記性能情報が前記性能要件を満たしていない場合、前記性能情報と現在の前記単位機能の数とに基づいて、前記1または複数のサーバのいずれかで実現させる前記単位機能の増加数を決定する、性能調整方法

技術分野

0001

本発明は、性能調整プログラム、および性能調整方法に関する。

背景技術

0002

クラウドコンピューティング技術により、ユーザが望む量のコンピュータリソースネットワーク経由でユーザに提供することが容易となっている。クラウドコンピューティングのなかには、例えばアプリケーションソフトウェア(以下、アプリケーションと呼ぶ)を稼働させるためのプラットフォーム利用環境を、ネットワークを介してユーザに提供するPaaS(Platform as a Service)がある。

0003

PaaSを利用したサービスは、例えばマイクロサビスアーキテクチャと呼ばれる技術思想に基づいて構築することができる。マイクロサービスアーキテクチャでは、1つのサービスを提供するソフトウェアが、コンポーネントと呼ばれる複数の小さなアプリケーションに分割して作成される。複数のコンポーネントを組み合わせて1つのサービスを提供することによって、処理能力の増強を、コンポーネント単位で実施することができる。これにより、あるコンポーネントの処理負荷が過大となった場合、そのコンポーネントについて処理能力の増強を行えばよく、他のコンポーネントは変更せずにすむ。

0004

コンポーネントの実行単位コンテナと呼ばれる。コンポーネントの処理能力を増強する場合、管理者は、例えば増強対象のコンポーネント用のコンテナ数を増加(スケールアウト)させる。コンテナ数の増減でサービスの性能調整ができることにより、システムリソースを効率的に利用することができる。このようなコンテナを利用したPaaSシステムは、Container-based PaaS Platformと呼ばれる。

0005

リソース利用の効率化に関する技術としては、例えば仮想環境における余剰リソースの抑制を図り、効率的なシステム運用を可能とする仮想化環境管理システムがある。

先行技術

0006

特開2017−138895号公報

発明が解決しようとする課題

0007

クラウドコンピューティングシステムの管理者は、サービスの品質が保てるように、サービスを実現するコンポーネントの性能を適宜調整する。例えば管理者は、性能要件として、サービスを提供する際のレイテンシ最大値を定め、サービスのレイテンシが最大値を超えた場合、そのサービスの提供に利用しているコンポーネントを実行する処理能力を増強する。性能要件を満たさなくなったサービスで利用している複数のコンポーネントのうち、どのコンポーネントに性能悪化要因があるのかが判明している場合、管理者は、性能悪化の要因となっているコンポーネント用のコンテナ数を増加させればよい。

0008

しかし、従来技術では、処理能力の増強のために、どれだけの数のコンテナを増加させるのが適切なのかを明確に知ることができない。増加させるコンテナ数が少なすぎれば、性能要件を満たすことができず、増加させるコンテナ数が多すぎれば、システムの資源が過剰に消費され、システムの運用効率が低下する。

0009

なお、どの程度の処理能力を増強するのが適切なのかの判断が難しいという問題は、マイクロサービスアーキテクチャに準じて作成されたサービスに限らず、一定の性能要件が要求されるサービス一般に同様に生じる問題である。

0010

1つの側面では、本件は、処理能力の適切な増強量を判断できるようにすることを目的とする。

課題を解決するための手段

0011

1つの案では、コンピュータに以下の処理を実行させる性能調整プログラムが提供される。
性能調整プログラムに基づいて、コンピュータは、所定の処理性能による調整対象処理の実行機能である1または複数の単位機能それぞれを、1または複数のサーバのいずれかで実現させることで、調整対象処理を1または複数のサーバに実行させる。次にコンピュータは、調整対象処理を利用して提供されるサービスの性能を示す性能情報を取得する。次にコンピュータは、性能情報が、サービスに求められる性能を示す性能要件を満たしているか否かを判断する。そしてコンピュータは、性能情報が性能要件を満たしていない場合、性能情報と現在の単位機能の数とに基づいて、1または複数のサーバのいずれかで実現させる単位機能の増加数を決定する。

発明の効果

0012

1態様によれば、処理能力の適切な増強量の判断が可能となる。

図面の簡単な説明

0013

第1の実施の形態による処理の一例を示す図である。
第2の実施の形態のシステムの構成例を示す図である。
管理サーバハードウェアの構成例を示す図である。
マイクロサービスアーキテクチャの概念を示す図である。
性能調整のためにゲートウェイと管理サーバが有する機能を示すブロック図である。
レイテンシ記憶部が記憶する情報の一例を示す図である。
サービス情報記憶部が記憶する情報の一例を示す図である。
メトリック情報記憶部が記憶する情報の一例を示す図である。
正常時振る舞い記憶部が記憶する情報の一例を示す図である。
リソース情報記憶部が記憶する情報の一例を示す図である。
性能調整エンジンの機能を示すブロック図である。
性能要件の判定処理の一例を示す図である。
コンテナの振る舞いの計算例を示す図である。
サーバの振る舞いの計算例を示す図である。
パーセンタイル値への重み付けの例を示す図である。
要因度の計算例を示す図である。
要因コンポーネントの推定例を示す図である。
サーバ要因度符号の判定例を示す図である。
増加させるコンテナ数の決定処理の一例を示す図である。
1コンテナ当たりのメトリックの増加量の計算例を示す図である。
サーバに配置されたコンテナのメトリック値の合計と余剰リソースとの関係を示す図である。
コンテナの配置先の決定例を示す図である。
性能調整結果の一例を示す図である。
性能調整処理の手順の一例を示すフローチャートである。
スケールアウト処理の手順の一例を示すフローチャートである。
増加コンテナ数決定処理の手順の一例を示すフローチャートである。
配置先サーバ決定処理の手順の一例を示すフローチャートである。
余剰リソース最大サーバ探索処理の手順の一例を示すフローチャートである。

実施例

0014

以下、本実施の形態について図面を参照して説明する。なお各実施の形態は、矛盾のない範囲で複数の実施の形態を組み合わせて実施することができる。
〔第1の実施の形態〕
まず、第1の実施の形態について説明する。

0015

図1は、第1の実施の形態による処理の一例を示す図である。管理装置10は、複数のサーバ1〜3に、例えばネットワークを介して接続されている。複数のサーバ1〜3は、連係動作によって、端末装置7に対するサービス8を提供するコンピュータである。サービス8は、例えば複数の処理(「処理a」、「処理b」、「処理c」)を連係して動作させることで提供される。各処理は、所定の処理性能による処理の実行機能である1または複数の単位機能4a,4b,5a,5b,6a,6bによって実行される。

0016

複数の単位機能4a,4b,5a,5b,6a,6bそれぞれは、複数のサーバ1〜3のいずれかで実現される。1つのサーバで、同じ処理の単位機能が複数実現されている場合もある。例えば1つのサーバに、所定の処理性能の2倍の処理性能で処理を実行させる場合、そのサーバには、2つの単位機能が実装される。なおサーバ1〜3は、例えば、複数の単位機能4a,4b,5a,5b,6a,6bそれぞれを、1つのプロセスで実行する。またサーバ1〜3は、複数の単位機能4a,4b,5a,5b,6a,6bそれぞれを、1つの仮想マシンで実行してもよい。

0017

管理装置10は、サーバ1〜3を管理するコンピュータである。管理装置10は、サーバ1〜3を管理するために、記憶部11と処理部12とを有する。記憶部11は、例えば管理装置10が有するメモリまたはストレージ装置である。処理部12は、例えば管理装置10が有するプロセッサまたは演算回路である。

0018

記憶部11は、各処理の単位機能数を記憶する。図1の例では、3つの「処理a」、「処理b」、「処理c」それぞれの単位機能数は、いずれも「2」である。
処理部12は、サーバ1〜3を制御して、サービス8の提供に使用する処理を、サーバ1〜3のうちの1または複数のサーバに実行させる。さらに処理部12は、サーバ1〜3により提供されているサービス8の品質が劣化した場合、サービス8の提供に使用する処理を実行する処理機能を調整する。

0019

具体的には、処理部12は、サービス8を実施するための機能をサーバ1〜3に実装する。例えば処理部12は、サービス8の提供に使用する各処理について、所定の処理性能による処理の実行機能である1または複数の単位機能4a,4b,5a,5b,6a,6bそれぞれを、複数のサーバ1〜3のいずれかで実現させる。そして処理部12は、複数のサーバ1〜3それぞれに、単位機能4a,4b,5a,5b,6a,6bにより処理を実行させる。

0020

その後、処理部12は、各処理を利用して提供されるサービス8の性能を示す性能情報を取得する。性能情報は、例えば端末装置7がリクエストを送信し、そのリクエストに対するレスポンスを受信するまでのレイテンシである。処理部12は、例えば複数のリクエストに対するレイテンシに基づいて、Apdexなどの性能の指標値を算出する。Apdexについては後述する。

0021

処理部12は、取得した性能情報が、性能要件を満たしているか否か(性能要件適合性)を判断する。例えば性能要件として、Apdexが0.8以上であることが指定されているものとする。この場合、処理部12は、取得した性能情報に基づいて算出したApdex値が、0.8以上か否かを判断する。

0022

処理部12は、性能情報が性能要件を満たしていない場合、直近の所定期間における複数の処理それぞれの動作状態を示す第1状態情報を取得する。さらに処理部12は、サービス8の性能が性能要件を満たしているときの複数の処理それぞれの動作状態を示す第2状態情報を取得する。そして処理部12は、第1状態情報と第2状態情報とに基づいて、性能要件が満たされているときと満たされていないときとの動作状態の差を、複数の処理それぞれについて計算する。

0023

処理部12は、複数の処理それぞれの動作状態の差に基づいて、サービス8の性能悪化要因となっている処理を判定する。例えば処理部12は、サービス8の性能が性能要件を満たしているときと満たしていないときとでの状態情報の差が最も大きい処理を、サービス8の性能悪化要因となっている処理と判定する。処理部12は、性能悪化要因となっている処理を、調整対象処理に決定する。

0024

処理部12は、性能情報が性能要件を満たしていない場合、サービス8の性能情報と、調整対象処理の現在の単位機能の数とに基づいて、複数のサーバ1〜3のいずれかで実現させる、調整対象処理の単位機能の増加数を決定する。例えば処理部12は、性能情報から算出された性能値(例えばApdex値)を、調整対象処理の現在の単位機能の数で除算することで、1単位機能当たりの性能値への寄与度を算出する。そして処理部12は、現在の単位機能の数に整数加算した加算値と寄与度との乗算結果が、性能要件として示される閾値以上となる、最小の整数を、増加数に決定する。

0025

増加数が決定すると、処理部12は、複数のサーバ1〜3の中から、決定された増加数分の単位機能それぞれを実現させるサーバを決定する。例えば処理部12は、増加数分の単位機能それぞれについて、単位機能を複数のサーバ1〜3のいずれかで実現させた場合に、リソースの余剰量である余剰リソースが最小となるサーバを、その単位機能を実現させるサーバに決定する。例えば処理部12は、現在の単位機能それぞれによるサーバのリソース使用量を示す数値の合計を、現在の単位機能の数に増加数を加算した加算値によって除算する。処理部12は、除算結果を1単位機能当たりのリソース使用量とする。次に処理部12は、1単位機能当たりのリソース使用量に基づいて、増加数分の単位機能それぞれを、複数のサーバ1〜3のいずれかで実現させた場合の、複数のサーバ1〜3の余剰リソースを計算する。

0026

例えば処理部12は、複数のサーバ1〜3それぞれの調整対象処理について、1単位機能を追加後にサーバ上で実現される単位機能の総数に、1単位機能当たりのリソース使用量を乗算する。次に処理部12は、乗算結果を、調整対象処理の単位機能以外の処理によるサーバのリソース使用量に加算し、加算結果を、単位機能追加後のリソース使用量とする。そして処理部12は、サーバの単位機能追加後のリソース使用量から、単位機能追加後のリソース使用量を減算することで、余剰リソースを得る。処理部12は、余剰リソースが最大となるサーバに単位機能を実現させることを決定する。これにより、余剰リソースが最も少なくなるサーバにおける余剰リソース量の最大化が図れる。なお処理部12は、リソース量の単位が正規化されている場合、単位機能追加後のリソース使用量が最も少なくなるサーバを、余剰リソースが最大となるサーバと判断してもよい。

0027

追加する単位機能を実現させるサーバが決定すると、処理部12は、その決定に従って、増加数分の単位機能それぞれを複数のサーバ1〜3のいずれかが実現するように複数のサーバ1〜3を制御する。例えば処理部12は、サーバ1〜3に、調整対象処理を実行するためのプログラムの起動を指示する。

0028

このように第1の実施の形態によれば、サービス8が性能要件を満たさなくなったとき、性能要件を満たすように処理能力を向上させるための単位機能の増加数(処理能力の適切な増強量)を算出することができる。そして、適切な数の単位機能をサーバ1〜3に一度に追加実装することで、迅速に処理能力の増強を図り、性能要件が満たされない状態を短時間で解消させることが可能となる。

0029

しかも、単位機能を追加実現させた際に余剰リソースが最大となるサーバに、単位機能を実現させる。これにより、複数のサーバ1〜3の負荷を均等に分散させ、余剰リソースが最も少ないサーバのその余剰サーバを、できるだけ多くすることができる。

0030

なお処理部12は、サービス8の性能情報が性能要件を満たしていないとき、性能悪化要因となっている処理を判定しているが、性能悪化要因となっている処理が明らかな場合、この判定処理は行わなくてもよい。例えば過去の運用経験上、ボトルネックとなる処理が分かっていれば、その処理を調整対象処置として、処理部12に予め設定しておいてもよい。この場合、処理部12は、サービス8の性能情報が性能要件を満たしていないとき、性能悪化要因の判定を行わずに、調整対象処置についての単位機能の追加実装処理を行う。

0031

〔第2の実施の形態〕
次に第2の実施の形態について説明する。第2の実施の形態は、マイクロサービスアーキテクチャに基づいて構築されたPaaSの運用管理を行うコンピュータシステムである。第2の実施の形態のコンピュータシステムは、サービスのレイテンシが最大値を超えたとき、負荷が過大となったコンポーネントのコンテナの増加数を的確に判断する。

0032

図2は、第2の実施の形態のシステムの構成例を示す図である。クラウドコンピューティングシステム40には、ネットワーク20を介して複数の端末装置31,32,・・・が接続されている。クラウドコンピューティングシステム40は、複数の端末装置31,32,・・・に対して、PaaSによるサービスを提供する。

0033

クラウドコンピューティングシステム40には、ゲートウェイ41、管理サーバ100、および複数のサーバ42〜44が含まれる。ゲートウェイ41は、ネットワーク20に接続されており、複数の端末装置31,32,・・・からの要求を受け付ける。管理サーバ100は、ゲートウェイ41と複数のサーバ42〜44とに接続されており、複数のサーバ42〜44を管理する。複数のサーバ42〜44は、複数の端末装置31,32,・・・からの要求に応じて、情報処理のサービスを提供する。

0034

図3は、管理サーバのハードウェアの構成例を示す図である。管理サーバ100は、プロセッサ101によって装置全体が制御されている。プロセッサ101には、バス109を介してメモリ102と複数の周辺機器が接続されている。プロセッサ101は、マルチプロセッサであってもよい。プロセッサ101は、例えばCPU(Central Processing Unit)、MPU(Micro Processing Unit)、またはDSP(Digital Signal Processor)である。プロセッサ101がプログラムを実行することで実現する機能の少なくとも一部を、ASIC(Application Specific IntegratedCircuit)、PLD(Programmable Logic Device)などの電子回路で実現してもよい。

0035

メモリ102は、管理サーバ100の主記憶装置として使用される。メモリ102には、プロセッサ101に実行させるOS(Operating System)のプログラムやアプリケーションプログラムの少なくとも一部が一時的に格納される。また、メモリ102には、プロセッサ101による処理に必要な各種データが格納される。メモリ102としては、例えばRAM(Random Access Memory)などの揮発性半導体記憶装置が使用される。

0036

バス109に接続されている周辺機器としては、ストレージ装置103、グラフィック処理装置104、入力インタフェース105、光学ドライブ装置106、機器接続インタフェース107およびネットワークインタフェース108がある。

0037

ストレージ装置103は、内蔵した記録媒体に対して、電気的または磁気的にデータの書き込みおよび読み出しを行う。ストレージ装置103は、コンピュータの補助記憶装置として使用される。ストレージ装置103には、OSのプログラム、アプリケーションプログラム、および各種データが格納される。なお、ストレージ装置103としては、例えばHDD(Hard Disk Drive)やSSD(Solid State Drive)を使用することができる。

0038

グラフィック処理装置104には、モニタ21が接続されている。グラフィック処理装置104は、プロセッサ101からの命令に従って、画像をモニタ21の画面に表示させる。モニタ21としては、液晶表示装置有機EL(Electro Luminescence)表示装置などがある。

0039

入力インタフェース105には、キーボード22とマウス23とが接続されている。入力インタフェース105は、キーボード22やマウス23から送られてくる信号をプロセッサ101に送信する。なお、マウス23は、ポインティングデバイスの一例であり、他のポインティングデバイスを使用することもできる。他のポインティングデバイスとしては、タッチパネルタブレットタッチパッドトラックボールなどがある。

0040

光学ドライブ装置106は、レーザ光などを利用して、光ディスク24に記録されたデータの読み取りを行う。光ディスク24は、光の反射によって読み取り可能なようにデータが記録された可搬型の記録媒体である。光ディスク24には、DVD(Digital Versatile Disc)、DVD−RAM、CD−ROM(Compact Disc Read Only Memory)、CD−R(Recordable)/RW(ReWritable)などがある。

0041

機器接続インタフェース107は、管理サーバ100に周辺機器を接続するための通信インタフェースである。例えば機器接続インタフェース107には、メモリ装置25やメモリリーダライタ26を接続することができる。メモリ装置25は、機器接続インタフェース107との通信機能を搭載した記録媒体である。メモリリーダライタ26は、メモリカード27へのデータの書き込み、またはメモリカード27からのデータの読み出しを行う装置である。メモリカード27は、カード型の記録媒体である。

0042

ネットワークインタフェース108は、ネットワーク20に接続されている。ネットワークインタフェース108は、ネットワーク20を介して、他のコンピュータまたは通信機器との間でデータの送受信を行う。

0043

以上のようなハードウェア構成によって、第2の実施の形態における管理サーバ100の処理機能を実現することができる。なお、端末装置31,32,・・・、ゲートウェイ41、およびサーバ42〜44も、管理サーバ100と同様のハードウェアによって実現できる。また、第1の実施の形態に示した管理装置10も、図3に示した管理サーバ100と同様のハードウェアにより実現することができる。

0044

管理サーバ100は、例えばコンピュータ読み取り可能な記録媒体に記録されたプログラムを実行することにより、第2の実施の形態の処理機能を実現する。管理サーバ100に実行させる処理内容記述したプログラムは、様々な記録媒体に記録しておくことができる。例えば、管理サーバ100に実行させるプログラムをストレージ装置103に格納しておくことができる。プロセッサ101は、ストレージ装置103内のプログラムの少なくとも一部をメモリ102にロードし、プログラムを実行する。また管理サーバ100に実行させるプログラムを、光ディスク24、メモリ装置25、メモリカード27などの可搬型記録媒体に記録しておくこともできる。可搬型記録媒体に格納されたプログラムは、例えばプロセッサ101からの制御により、ストレージ装置103にインストールされた後、実行可能となる。またプロセッサ101が、可搬型記録媒体から直接プログラムを読み出して実行することもできる。

0045

なお、第2の実施の形態では、マイクロサービスアーキテクチャに基づいて、サービスを提供するソフトウェアがサーバ42〜44に実装される。
図4は、マイクロサービスアーキテクチャの概念を示す図である。ユーザに提供するサービス50は、複数のコンポーネント51〜53を用いて実現される。例えばコンポーネント51はプレゼンテーション層の処理を実行するソフトウェアであり、コンポーネント52はロジック層の処理を実行するソフトウェアであり、コンポーネント53はデータ層の処理を実行するソフトウェアである。

0046

コンポーネント51〜53は、複数のサーバ42〜44のいずれか1以上で実行される。コンポーネント51〜53を実行することでサーバ42〜44上に構築される処理機能がコンテナである。第2の実施の形態では、コンテナを「Cxy」と表している。添字の「x」は、そのコンテナを含むコンポーネントの識別番号(コンポーネント番号)である。添字の「y」は、そのコンテナを含むコンポーネント内でのコンテナの識別番号(コンテナ番号)である。

0047

このように、マイクロサービスアーキテクチャでは、一つのサービス50を提供するためのソフトウェアが、複数の小さなコンポーネント51〜53に分割して作成される。各コンポーネント51〜53は疎に結合している。結合が疎であるとは、コンポーネント51〜53同士の結びつきが比較的緩やかであり、独立性が強い状態にあることである。コンポーネント51〜53の結合が疎であることにより、新たなコンポーネントの追加や一部のコンポーネントの拡張による他のコンポーネントの変更が少なくてすむという利点がある。

0048

マイクロサービスアーキテクチャに準じて作成されたサービスのコンポーネント51〜53は、1以上のコンテナによって実行される。すなわち、コンポーネント51〜53とコンテナは、1対1または1対多の関係にある。

0049

ユーザに提供するサービス50に求められる性能要件は、例えばレイテンシを用いて表すことができる。従って、システムの管理者は、サービス50に求められるレイテンシが得られるような処理能力のコンポーネント51〜53を用意することになる。コンポーネント51〜53の処理能力は、コンポーネント51〜53を実行するコンテナを増やしたり、減らしたりすることで調整することができる。

0050

ここで、サービス50に求められる性能要件を管理者が規定することは容易である。それに対して、サービス50に求められるレイテンシを満たすように、各コンポーネントにどの程度のリソースを割り当てればよいのかを、管理者が判断するのは困難である。そこで第2の実施の形態では、管理サーバ100が、性能が不足しているコンポーネントを検出し、そのコンポーネントを実行するコンテナを追加することで、サービス50に対する性能要件を満たすようなコンポーネントへのリソースの割り当てを実現する。

0051

図5は、性能調整のためにゲートウェイと管理サーバが有する機能を示すブロック図である。ゲートウェイ41は、レイテンシ計測部41aとレイテンシ記憶部41bとを有する。レイテンシ計測部41aは、端末装置31,32,・・・から要求を受信してから、その要求に対応する応答を端末装置31,32,・・・に送信するまでの時間を計測する。レイテンシ計測部41aは、計測した時間を、その要求に応じたサービスについてのレイテンシとして、レイテンシ記憶部41bに格納する。レイテンシ記憶部41bは、レイテンシ計測部41aが計測したレイテンシを記憶する。

0052

管理サーバ100は、サービス情報記憶部110、メトリック情報記憶部120、正常時振る舞い記憶部130、リソース情報記憶部140、および性能調整エンジン150を有する。サービス情報記憶部110は、提供するサービスに関する情報を記憶する。メトリック情報記憶部120は、サーバ42〜44やコンテナによるリソースの稼働状況に関する情報(メトリック)を記憶する。正常時振る舞い記憶部130は、複数のコンテナそれぞれと複数のサーバそれぞれとの正常動作時の振る舞いを示す情報を記憶する。リソース情報記憶部140は、サーバ42〜44の使用リソースに関する情報を記憶する。性能調整エンジン150は、サービス情報記憶部110、メトリック情報記憶部120、正常時振る舞い記憶部130、およびリソース情報記憶部140に記憶された情報を用いて、コンポーネント単位での性能調整を行う。

0053

なお、以下の説明において、コンポーネントの処理を実行するコンテナをサーバに実装することを、コンテナの配置と呼ぶ。コンテナの配置は、具体的には、コンポーネントを実行するためのプログラムをサーバにインストールし、そのプログラムに基づいてコンポーネントの処理を実行するプロセスを起動する処理である。また、コンテナがサーバに実装されているとき、そのコンテナがそのサーバに配置されていると呼ぶ。

0054

図5の例では、各サーバ42〜44には、異なるコンポーネントの複数のコンテナが配置されている。例えばサーバ42には、コンテナC11,C22,C31が配置されている。
以下、図6図10を参照して、サービス情報記憶部110、メトリック情報記憶部120、正常時振る舞い記憶部130、およびリソース情報記憶部140が記憶する情報について、詳細に説明する。

0055

図6は、レイテンシ記憶部が記憶する情報の一例を示す図である。レイテンシ記憶部41bは、例えばレイテンシ管理テーブル41cを記憶している。レイテンシ管理テーブル41cは、タイムスタンプ、リクエストID、サービス名、およびレイテンシの欄を有している。

0056

タイムスタンプの欄には、レイテンシを計測した日時が設定される。リクエストIDの欄には、レイテンシを計測した要求の識別情報(リクエストID)が設定される。サービス名の欄には、レイテンシを計測した要求に対応するサービスの名称(サービス名)が設定される。レイテンシの欄には、計測したレイテンシが設定される。

0057

図7は、サービス情報記憶部が記憶する情報の一例を示す図である。サービス情報記憶部110は、例えばサービス管理テーブル111を記憶している。サービス管理テーブル111は、サービス名、Apdex(Application performance index)、Satisfied Time、およびコンポーネント名の欄が設けられている。サービス名の欄には、提供しているサービスの名称(サービス名)が設定される。Apdexの欄には、対応するサービスに求められる性能要件が、Apdexによって設定される。Apdexは、レイテンシについてのユーザの満足度を示す指標である。Satisfied Timeの欄には、対応するサービスを利用するユーザが満足すると思われる最大のレイテンシの値(T)が設定される。コンポーネント名の欄には、サービスの提供に用いられるコンポーネントの名称が設定される。

0058

ここで、Apdexについて詳細に説明する。Apdexは、「The Alliance」によって標準化された指標であり、以下の式によって計算される。
・Apdex=((satisfied counts)+(tolerating counts)/2)/(total counts)
「satisfied counts」は、レイテンシがT以下のリクエスト回数である。すなわち「satisfied counts」は、ユーザが満足できるレイテンシが得られたリクエストの回数である。

0059

「tolerating counts」は、レイテンシがT以上、かつ4×T以下のリクエスト回数である。すなわち「tolerating counts」は、ユーザが満足できるレイテンシではないものの、許容できるレイテンシが得られたリクエストの回数である。

0060

なお、レイテンシが4×Tより大きなリクエスト回数は、「frustrated」と呼ばれる。この「frustrated」は、ユーザが不満感じるレイテンシとなったリクエストの回数である。

0061

第2の実施の形態では、サービスのレイテンシに基づいて計算したApdexの値が、性能要件として設定されたApdex値以上であれば、性能要件を満たしていると判断される。逆にサービスのレイテンシに基づいて計算したApdexの値が、性能要件として設定されたApdex値未満であれば、性能要件を満たしていないと判断される。

0062

図8は、メトリック情報記憶部が記憶する情報の一例を示す図である。メトリック情報記憶部120は、例えばメトリック管理テーブル121を記憶している。メトリック管理テーブル121は、タイムスタンプ、サーバ/コンテナ名、メトリック種別、および値の欄を有している。タイムスタンプの欄には、メトリックの値を計測した日時が設定される。サーバ/コンテナ名の欄には、メトリックの値を計測したサーバまたはコンテナの名称が設定される。メトリック種別の欄には、計測したメトリックの種別(メトリック種別)が設定される。値の欄には、計測したメトリックの値が設定される。

0063

図9は、正常時振る舞い記憶部が記憶する情報の一例を示す図である。正常時振る舞い記憶部130は、例えば振る舞い測定周期ごとの複数のコンテナ振る舞い管理テーブル131a,131b,・・・と、振る舞い測定周期ごとの複数のサーバ振る舞い管理テーブル132a,132b,・・・とを記憶している。

0064

複数のコンテナ振る舞い管理テーブル131a,131b,・・・は、それぞれコンテナの振る舞いの測定周期に対応付けて設けられている。複数のコンテナ振る舞い管理テーブル131a,131b,・・・は、コンテナ、メトリック種別、パーセンタイル種別、パーセンタイル値、および重み付きパーセンタイル値の欄を有している。コンテナの欄には、振る舞いの測定対象であるコンテナの名称(コンテナ名)が設定される。メトリック種別の欄には、振る舞いを測定したメトリックの種別が設定される。パーセンタイル種別の欄には、メトリックの値について求めるパーセンタイルの種別が設定される。例えば50パーセンタイル、90パーセンタイル、99パーセンタイルなどが、パーセンタイルの種別として設定される。パーセンタイル値の欄には、対応するメトリックについてのパーセンタイルの種別で示されるパーセンタイルの値が設定される。重み付きパーセンタイル値の欄には、過去数周期分のメトリック値に基づく、コンテナのメトリックごとの重み付きパーセンタイル値が設定される。重み付きパーセンタイル値の詳細は、後述する(図15参照)。

0065

複数のサーバ振る舞い管理テーブル132a,132b,・・・は、それぞれサーバの振る舞いの測定周期に対応付けて設けられている。複数のサーバ振る舞い管理テーブル132a,132b,・・・は、サーバ、メトリック種別、パーセンタイル種別、パーセンタイル値、および重み付きパーセンタイル値の欄を有している。サーバの欄には、振る舞いの測定対象であるサーバの名称(サーバ名)が設定される。メトリック種別の欄には、振る舞いを測定したメトリックの種別が設定される。パーセンタイル種別の欄には、メトリックの値について求めるパーセンタイルの種別が設定される。例えば50パーセンタイル、90パーセンタイル、99パーセンタイルなどが、パーセンタイルの種別として設定される。パーセンタイル値の欄には、対応するサーバについてのパーセンタイルの種別で示されるパーセンタイルの値が設定される。重み付きパーセンタイル値の欄には、過去数周期分のメトリック値に基づく、サーバのメトリックごとの重み付きパーセンタイル値が設定される。

0066

なお、パーセンタイルは、統計の代表値一種である。複数のデータを大きさの順に並べたとき、値x(xは実数)より小さなデータの割合がp%以下(pは0以上100以下の実数)、それより大きなデータの割合が「100−p」%となる値xが、pパーセンタイルである。pパーセンタイルは、第p百分位数とも呼ばれる。

0067

図10は、リソース情報記憶部が記憶する情報の一例を示す図である。リソース情報記憶部140は、例えばコンテナ配置管理テーブル141、サーバリソース管理テーブル142、およびコンテナリソース管理テーブル143を記憶している。

0068

コンテナ配置管理テーブル141は、サーバ42〜44へのコンテナの配置状況を管理するデータテーブルである。コンテナ配置管理テーブル141は、サーバ名とコンテナ名との欄を有している。サーバ名の欄には、コンテナが実装されているサーバの名称(サーバ名)が設定される。コンテナ名の欄には、対応するサーバに実装されているコンテナの名称(コンテナ名)が設定される。

0069

サーバリソース管理テーブル142は、サーバ42〜44のリソースの量を管理するデータテーブルである。サーバリソース管理テーブル142は、サーバ名とリソース量との欄を有している。サーバ名の欄には、サービスの提供に使用しているサーバの名称(サーバ名)が設定される。リソース量の欄には、対応するサーバが有するリソース量が、リソースの種別ごとに設定される。図10の例では、CPU、メモリ、ネットワークのリソース量が設定されている。

0070

コンテナリソース管理テーブル143は、各コンポーネントのコンテナが使用するリソースの量を管理するデータテーブルである。コンテナリソース管理テーブル143は、コンポーネントとコンテナ使用リソース量との欄を有している。コンポーネントの欄には、サービスの提供に使用されるコンポーネントの名称(コンポーネント名)が設定される。コンテナ使用リソース量の欄には、対応するコンポーネントのコンテナが使用するリソースの量が、リソースの種別ごとに設定される。図10の例では、CPU、メモリ、ネットワークについてのコンテナの使用リソース量が設定されている。

0071

次に、性能調整エンジン150について詳細に説明する。
図11は、性能調整エンジンの機能を示すブロック図である。性能調整エンジン150は、サービス管理部151、メトリック情報収集部152、レイテンシ検査部153、振る舞い計算部154、異常要因推定部155、配置先サーバ決定部156、およびコンテナ配置制御部157を有する。

0072

サービス管理部151は、サービスの構成や性能要件を管理する。メトリック情報収集部152は、サーバ42〜44からメトリックの値を定期的に収集し、メトリック情報記憶部120に格納する。レイテンシ検査部153は、サービスのレイテンシが性能要件を満たしているか検査する。振る舞い計算部154は、コンテナとサーバとの正常時および異常時の振る舞いを計算する。振る舞い計算部154は、正常時の振る舞いを、正常時振る舞い記憶部130に格納する。異常要因推定部155は、レイテンシが性能要件を満たしていないサービスの異常要因となっているコンポーネント(要因コンポーネント)を推定する。配置先サーバ決定部156は、要因コンポーネントに追加するコンテナ数と、追加するコンテナの配置先とするサーバを決定する。コンテナ配置制御部157は、要因コンポーネントのスケールアウト、または要因コンポーネントを実行するコンテナの配置変更を行う。

0073

なお、図11に示した各要素間を接続する線は通信経路の一部を示すものであり、図示した通信経路以外の通信経路も設定可能である。また、図11に示した各要素の機能は、例えば、その要素に対応するプログラムモジュールをコンピュータに実行させることで実現することができる。

0074

次に、性能調整エンジン150における、各サービスが性能要件を満たしているか否かの判定処理について説明する。
図12は、性能要件の判定処理の一例を示す図である。サービス管理部151は、管理者の入力に従って、サービス50の性能要件として、Apdex値をサービス情報記憶部110に登録する。例えばサービス管理部151は、管理者からのApdex値とSatisfied Time(T)との入力を受け付ける。そしてサービス管理部151は、入力されたApdex値とSatisfied Time(T)とを、サービス管理テーブル111に、サービス50のサービス名に対応付けて格納する。

0075

レイテンシ検査部153は、ゲートウェイ41から定期的に、直近の所定期間内のサービス50へのリクエストに関するレイテンシを収集する。サービスのレイテンシは、端末装置31から発行されたリクエストのゲートウェイ41での受信時刻と、端末装置31へのゲートウェイ41からの応答の送信時刻との差である。レイテンシ検査部153は、取得したレイテンシに基づいて、所定期間におけるApdex値を計算する。そしてレイテンシ検査部153は、計算したApdex値が、性能要件として指定されたApdex値以上であれば、性能要件を満たしていると判断する。またレイテンシ検査部153は、計算したApdex値が、性能要件として指定されたApdex値未満であれば、性能要件を満たしていないと判断する。

0076

次にメトリック情報収集部152によって、コンテナとサーバとのメトリック情報が収集され、メトリック情報記憶部120に格納される。収集されるメトリック情報には、例えばCPUの使用率、メモリのI/Oレートやページフォルト数、ディスクファイルシステム)のI/Oレート、ネットワークの送受信レートなどが含まれる。収集されたメトリック情報に基づいて、振る舞い計算部154によって、直近の所定期間におけるコンテナとサーバとの振る舞いが計算される。

0077

図13は、コンテナの振る舞いの計算例を示す図である。図13の例では、コンテナC11の振る舞いを計算するものとする。振る舞い計算部154は、メトリック情報記憶部120から、コンテナ名が「C11」であるレコードを抽出する。次に振る舞い計算部154は、抽出したレコードをメトリック種別で分類する。次に振る舞い計算部154は、同じメトリック種別のレコードに設定されている値(メトリック値)が0〜100となるように正規化し、度数分布を生成する。例えば振る舞い計算部154は、各メトリック値の理論上の最大値が「100」となるように正規化する。そして振る舞い計算部154は、度数分布に基づいて、メトリック種別ごとに、50パーセンタイル値、90パーセンタイル値、および99パーセンタイル値を計算する。

0078

振る舞い計算部154は、サービス50のコンポーネントを実行するすべてのコンテナの振る舞いを計算する。そして、レイテンシ検査部153によってサービス50の性能要件が満たされていると判断されている場合、振る舞い計算部154は、直近の周期のコンテナ振る舞い管理テーブル131aを作成し、そのコンテナ振る舞い管理テーブル131aを正常時振る舞い記憶部130に格納する。

0079

図14は、サーバの振る舞いの計算例を示す図である。図14の例では、サーバ名「サーバ1」のサーバ42の振る舞いを計算するものとする。振る舞い計算部154は、メトリック情報記憶部120から、サーバ名が「サーバ1」であるレコードを抽出する。次に振る舞い計算部154は、抽出したレコードをメトリック種別で分類する。次に振る舞い計算部154は、同じメトリック種別のレコードに設定されている値(メトリック値)が0〜100となるように正規化し、度数分布を生成する。そして振る舞い計算部154は、度数分布に基づいて、メトリック種別ごとに、50パーセンタイル値、90パーセンタイル値、および99パーセンタイル値を計算する。

0080

振る舞い計算部154は、すべてのサーバ42〜44の振る舞いを計算する。そして、レイテンシ検査部153によってサービス50の性能要件が満たされていると判断されている場合、振る舞い計算部154は、直近の周期のサーバ振る舞い管理テーブル132aを作成し、そのサーバ振る舞い管理テーブル132aを正常時振る舞い記憶部130に格納する。

0081

レイテンシ検査部153によってサービス50の性能要件が満たされていないと判断された場合、振る舞い計算部154は、計算したコンテナとサーバとのパーセンタイル値を、異常時の振る舞いを示す情報として、異常要因推定部155に送信する。すると異常要因推定部155は、異常時の振る舞いと正常時の振る舞いとを比較して、サービスのレイテンシ低下の要因となっているコンポーネントを推定する。

0082

例えば異常要因推定部155は、正常時振る舞い記憶部130から、新しい方からn周期分(nは1以上の整数)のコンテナのメトリックごとのパーセンタイル値を取得する。そして異常要因推定部155は、取得したパーセンタイル値に基づいて、各メトリックの正常時の振る舞いを決定する。このとき異常要因推定部155は、現在に近い周期の振る舞いほど今後の振る舞いに近いとみなすようにするため、パーセンタイル値の取得元の周期の古さに応じて、パーセンタイル値に重み付けを行う。

0083

図15は、パーセンタイル値への重み付けの例を示す図である。図15に示した例では、周期t〜t+2周期の3周期分の正常時のパーセンタイル値を取得したものとする。このとき異常要因推定部155は、最新の周期t+2のパーセンタイル値の重みを「3」とする。また異常要因推定部155は、1つ前の周期t+1のパーセンタイル値の重みを「2」とする。さらに異常要因推定部155は、2つ前の周期tのパーセンタイル値の重みを「1」とする。

0084

このように異常要因推定部155は、現在に近い周期のパーセンタイル値ほど重みを大きくして、n周期分の期間のパーセンタイル値(重み付きパーセンタイル値)をメトリックごとに算出する。例えば、以下のようにして、重み付きパーセンタイル値を算出する。

0085

正常時のパーセンタイル値として、以下のデータが得られたものとする。S1は最新の周期のデータの集合である。S2は、S1の1つ前の周期のデータ集合である。S3は、S2の1つ前の周期のデータ集合である。
S1:{1,2}
S2:{3,4}
S3:{5,6}
この例では、重み付けの処理を分かりやすくするため、データの値を単純化している。S1,S2,S3に対する重み付きパーセンタイル値を求めるとき、重みの分だけ、各正常データの数を増やす。例えば、集合S1,S2,S3それぞれに対する重みを、「3」、「2」、「1」とする。この場合、集合S1,S2,S3は、以下の集合に置き換えられる。
S1’=S1×3:{1,1,1,2,2,2}
S2’=S2×2:{3,3,4,4}
S3’=S3×1:{5,6}
集合S1’は、集合S1を3倍したものである。すなわち集合S1と同じ3つの集合を1つに纏めたものが、集合S1’である。集合S2’は、集合S2を2倍したものである。すなわち集合S2と同じ2つの集合を1つに纏めたものが、集合S2’である。集合S3’は、集合S3と同じである。異常要因推定部155は、これらの集合S1’,S2’S3’を1つの集合に纏め、データを昇順ソートする。すなわち異常要因推定部155は、周期ごとの各集合について、その集合と同じ集合を重みの数だけ生成し、生成した集合を1つに纏めて、データを昇順にソートする。ソートの結果、以下の集合Sが得られる。
S=:{1,1,1,2,2,2,3,3,4,4,5,6}
異常要因推定部155は、この集合Sに基づいて得られたパーセンタイル値を、重み付きパーセンタイル値とする。すると、50パーセンタイル値は「2」となる。また90パーセンタイル値は「4」となる。

0086

異常要因推定部155は、正常時の重み付きパーセンタイル値と、異常時の振る舞いを示す最新のパーセンタイル値とを、メトリック種別ごとに比較し、そのメトリック種別に関する要因度を求める。異常要因推定部155は、例えば要因度として、正の要因度と負の要因度とを求める。

0087

図16は、要因度の計算例を示す図である。図16の例では、正常時の振る舞いを示す重み付きパーセンタイル値では、50パーセンタイル値が「15」、90パーセンタイル値が「71」、99パーセンタイル値が「90」である。また異常時の振る舞いを示す最新のパーセンタイル値では、50パーセンタイル値が「6」、90パーセンタイル値が「92」、99パーセンタイル値が「98」である。

0088

ここで、正の要因度と負の要因度とを、以下のように定める。
・正の要因度F+=Σ(値が増加するPパーセンタイルのPの増分)×(パーセンタイル値の差)
・負の要因度F-=Σ(値が減少するPパーセンタイルのPの増分)×(パーセンタイル値の差)
Pはパーセンタイル種別を示す数値であり、50パーセンタイルの場合P=50である。値が増加するPパーセンタイルとは、正常時のパーセンタイル値より異常時のパーセンタイル値の方が大きいパーセンタイル種別である。値が減少するPパーセンタイルとは、異常時のパーセンタイル値より正常時のパーセンタイル値の方が大きいパーセンタイル種別である。

0089

PパーセンタイルのPの増分とは、パーセンタイル種別をPの値が小さい順に並べたときの、各パーセンタイル種別についての、直前のパーセンタイル種別からのPの値の増加量である。図16の例では、50パーセンタイル、90パーセンタイル、99パーセンタイルがある。その場合、50パーセンタイルについてのPの増分は、「50」である。90パーセンタイルについてのPの増分は、「40」(90−50)である。99パーセンタイルについてのPの増分は、「9」(99−90)である。

0090

サービスのレイテンシが性能要件を満たしていないとき、コンテナやサーバの負荷が平常時より増加していれば、メトリック値が高い値に集中し、正の要因度が高くなる。またサービスのレイテンシが性能要件を満たしていないとき、コンテナやサーバの負荷が平常時より低下していれば、メトリック値が低い値に集中し、負の要因度が高くなる。サービスのレイテンシが性能要件を満たしているのに、コンテナまたはサーバの正の要因度よりも負の要因度の方が高い場合、そのコンテナまたはサーバとは別の要因で性能が劣化していると判断できる。

0091

図16に示した例では、要因度は以下の通りとなる。
・正の要因度F+=(90−50)×(92−71)+(99−90)×(98−90)=912
・負の要因度F-=50×(15−6)=450
異常要因推定部155は、このような要因度の計算を、メトリック種別ごとに行う。そして異常要因推定部155は、最大の要因度の算出元のコンテナが実行しているコンポーネントを、異常の要因である要因コンポーネントとして推定する。

0092

図17は、要因コンポーネントの推定例を示す図である。図17に示すように、すべてのコンテナについて、メトリック種別ごとに、正の要因度と負の要因度とが算出される。異常要因推定部155は、算出された要因度の中から、最大の要因度を抽出する。図17の例では、コンテナC11のCPU使用率についての正の要因度の値が最大となっている。異常要因推定部155は、抽出した要因度の算出元となっているコンテナC11で実行しているコンポーネント(コンポーネント名「コンポーネント1」)を、要因コンポーネントとして推定する。このとき異常要因推定部155は、最大の要因度に対応するメトリック種別「CPU使用率」を、要因メトリックとする。また異常要因推定部155は、最大の要因度が正の要因度なのか負の要因度なのかを示すコンテナ要因度符号を、正とする。

0093

さらに異常要因推定部155は、コンテナ配置管理テーブル141から、最大の要因度の算出元となったコンテナが実装されているサーバのサーバ名を取得する。そして異常要因推定部155は、取得したサーバ名を、コンテナ稼働サーバのサーバ名とする。図17の例では、コンテナ稼働サーバは「サーバ1」である。

0094

また異常要因推定部155は、サーバについても、メトリック種別ごとの要因度を計算する。そして異常要因推定部155は、サーバのメトリック種別それぞれについて、正の要因度と負の要因度とを比較する。異常要因推定部155は、正の要因度が負の要因度以上であれば、そのメトリック種別の要因度符号を「正」とする。異常要因推定部155は、正の要因度が負の要因度未満であれば、そのメトリック種別の要因度符号を「負」とする。

0095

そして、異常要因推定部155は、コンテナ稼働サーバの要因メトリックの要因度符号を、サーバ要因度符号とする。
図18は、サーバ要因度符号の判定例を示す図である。図18の例では、コンテナ稼働サーバ「サーバ1」の要因メトリック「CPU使用率」の要因度符号は「正」であるため、サーバ要因度符号は「正」となる。

0096

なおサーバの要因度についても、コンテナと同じ手順で計算することができるが、サーバについては、各メトリック種別の要因度符号が判明すればよい。そこで例えば、正の要因度と負の要因度とを分けずに、メトリック種別の要因度を以下の式で計算してもよい。
・要因度F=Σ(PパーセンタイルのPの増分)×(パーセンタイル値の差)
このときのパーセンタイル値の差は、正常値のパーセンタイル値から異常時のパーセンタイル値を減算した値である。このようにして計算した要因度Fが0以上の値であれば、要因度符号は「正」である。要因度Fが負の値であれば、要因度符号は「負」である。

0097

異常要因推定部155が決定したコンテナ要因度符号が正の場合、配置先サーバ決定部156は、要因コンポーネントのリソースが不足していると判断し、要因コンポーネントに増加させるコンテナ数を決定する。さらに配置先サーバ決定部156は、増加させるコンテナを配置するサーバを決定する。

0098

図19は、増加させるコンテナ数の決定処理の一例を示す図である。配置先サーバ決定部156は、要因コンポーネントのリソースが不足している場合、計測したレイテンシに基づく統計値と現在のコンテナ数をもとに、コンテナの増加数を決定する。

0099

例えば配置先サーバ決定部156は、異常要因推定部155から異常要因の推定結果を取得する。推定結果に示されるコンテナ要因度符号が「正」である場合、配置先サーバ決定部156は、要因コンポーネントに対して増加させるコンテナ数を決定する。その場合、配置先サーバ決定部156は、レイテンシ検査部153から要因コンポーネントを含むサービス(性能要件を満たしていないサービス)のレイテンシに基づく統計値を取得する。レイテンシに基づく統計値は、具体的には、「satisfied counts」、「tolerating counts」、および「total counts」である。これらの統計値は、レイテンシ検査部153によるApdex値の算出に用いられた値である。

0100

また配置先サーバ決定部156は、コンテナ配置管理テーブル141を参照し、要因コンポーネントのコンテナ数を計数する。配置先サーバ決定部156は、計数したコンテナ数を、#currentとする。

0101

配置先サーバ決定部156は、取得した統計値と#currentとに基づいて、Apdexの目標値を満たすための最小のコンテナ増加数を計算する。例えば配置先サーバ決定部156は、1コンテナ当たりの「satisfied counts」(SCper1C)と、1コンテナ当たりの「tolerating counts」(TCper1C)とを算出する。「SCper1C」と「TCper1C」とは、1つのコンテナによるApdexへの寄与度に相当する。

0102

SCper1CとTCper1Cとの計算式は以下の通りである。
・SCper1C=(計測されたsatisfied counts)/#current
・TCper1C=(計測されたtolerating counts)/#current
配置先サーバ決定部156は、以下の式を満たす最小の#incrementを計算する。
・(Apdexの目標値)≦((SCper1C×(#current+#increment))+(TCper1C×(#current+#increment))/2)/(total counts)
算出された#incrementが、増加させるコンテナ数である。増加させるコンテナ数が決定すると、配置先サーバ決定部156は、増加させるコンテナの配置先サーバを決定する。このとき配置先サーバ決定部156は、コンテナの追加配置によるサーバのリソース容量を考慮して、配置先のサーバの余剰リソースができるだけ多くなるように増加数分のコンテナそれぞれの配置先を決定する。

0103

コンテナを配置した後のサーバの余剰リソースを正確に計算するために、配置先サーバ決定部156は、まず、1コンテナ当たりのメトリック値の増加量を計算する。
図20は、1コンテナ当たりのメトリックの増加量の計算例を示す図である。図20の例では、要因コンポーネントのコンテナが、3台のサーバそれぞれに1台ずつ配置されている。各コンテナのメトリック値の平均が、そのメトリックについての、現在の1コンテナ当たりのメトリック値(cDataset)となる。図20の例では、現在の1コンテナ当たりのメトリック値は「0.4」である。

0104

ここで、要因コンポーネントのコンテナを1台だけ増加させる場合を考える。コンテナ数が増加しても、1コンテナ当たりのメトリック値の合計は変わらず、コンテナ3台での分散処理からコンテナ4台での分散処理になる。そのため、増加後の1コンテナ当たりのメトリック値(Δ)は、増加前よりも小さくなる。具体的には、「現在の1コンテナ当たりのメトリック値×増加前のコンテナ数/増加後のコンテナ数」で、コンテナ増加後の1コンテナ当たりのメトリック値(Δ)を計算できる。図20の例では、コンテナ増加後の1コンテナ当たりのメトリック値(Δ)は「0.3」(0.4×3/4)である。

0105

図20の例は、コンテナを1台だけ増加させる場合であるが、増加させるコンテナ数が2台以上の場合もある。その場合、コンテナ増加後の1コンテナ当たりのメトリック値(Δ)はさらに小さくなる。

0106

配置先サーバ決定部156は、コンテナの配置先を決定する場合、コンテナ増加後の1コンテナ当たりのメトリック値(Δ)に基づいて、増加後の配置先のサーバにおける余剰リソースを判断する。余剰リソースの量は、サーバの特定のリソースについての最大のメトリック値(正規化後は「1」)から、そのサーバに配置された各コンテナのメトリック値の合計を減算することで判断できる。メトリック値が、最大1に正規化されていれば、配置先サーバ決定部156は、複数のサーバそれぞれについての、そのサーバに配置されたコンテナのメトリック値の合計を比較することで、余剰リソースが最大となるサーバを特定できる。

0107

図21は、サーバに配置されたコンテナのメトリック値の合計と余剰リソースとの関係を示す図である。図21の例では、「サーバ1」に、コンポーネント番号「1」のコンポーネントのコンテナC11と、コンポーネント番号「2」のコンポーネントのコンテナC21とが配置されている。ここで、コンポーネント番号「1」のコンポーネントが要因コンポーネントの場合に、「サーバ1」に要因コンポーネントのコンテナを追加していく場合を想定する。

0108

現状では、「サーバ1」のリソースは、コンテナC11とコンテナC21とが使用している。リソースの現状の使用量を示すメトリック値は、コンテナC11のメトリック値とコンテナC21のメトリック値との合計である。リソースの現状の使用量を示すメトリック値を、「SrvData.ServerDataInfo[サーバ1]」とする。また、コンテナC11のメトリック値を「cDataset」とする。「サーバ1」の最大のメトリック値から、「SrvData.ServerDataInfo[サーバ1]」を減算した値が、現状の「サーバ1」の余剰リソースである。コンテナC21のリソース使用量は、「SrvData.ServerDataInfo[サーバ1]−cDataset」で表される。

0109

ここで配置先サーバ決定部156が、「サーバ1」に、要因コンポーネントのコンテナを1台追加した場合の余剰リソースを計算するものとする。この場合、要因コンポーネントとは異なるコンポーネントのコンテナC21のリソース使用量は変わらない。それに対して、要因コンポーネントのコンテナC11のリソースの使用量は、コンテナ増加後の1コンテナ当たりのメトリック値(Δ)で表される。ここで「サーバ1」に配置されている要因コンポーネントのコンテナ数(図21の例では「1」)を「CntData.Counts[サーバ1]」とする。このとき、既に配置されている要因コンポーネントのコンテナによるリソースのコンテナ追加後の総使用量は、「Δ×CntData.Counts[サーバ1]」で計算できる。配置先サーバ決定部156は、コンテナC21のリソース使用量に、「Δ×CntData.Counts[サーバ1]」と追加予定のコンテナが使用する分のリソース量を示す「Δ」とを加算する。加算結果が、「サーバ1」にコンテナを1台追加した場合のリソースの使用量を示すメトリック値「tmpDataset」となる。

0110

配置先サーバ決定部156は、このような「tmpDataset」の計算を「サーバ1」以外のサーバに関しても行い、「tmpDataset」が最小となるサーバを、コンテナの配置先に決定する。ここで、配置先サーバ決定部156が、「サーバ1」に要因コンポーネントのコンテナを1台追加することを決定したものとする。「サーバ1」に追加することが決定したコンテナの数を「Destinations[サーバ1]」とすると、追加することが決定したコンテナが使用するリソース量は、「Δ×Destinations[サーバ1]」となる。

0111

「サーバ1」にコンテナをさらに1台追加する場合(合計2台の追加)の余剰リソースは、「Δ×Destinations[サーバ1]」を考慮にいれて計算することになる。例えば配置先サーバ決定部156は、コンテナC21のリソース使用量に、「Δ×CntData.Counts[サーバ1]」と「Δ×Destinations[サーバ1]」、さらに追加する予定のコンテナが使用する分のリソース量を示す「Δ」とを加算する。加算結果が、「サーバ1」にコンテナを2台追加した場合のリソースの使用量を示すメトリック値「tmpDataset」となる。

0112

このように、コンテナの配置先に決定されたサーバは、「tmpDataset」の値が増加する。そのため、最初の1台のコンテナの配置先を決定する際には「tmpDataset」が最小となったサーバであっても、2台目のコンテナの配置先を決定する際には「tmpDataset」が最小とはならない可能性がある。

0113

図22は、コンテナの配置先の決定例を示す図である。図22の例では、コンポーネント番号「1」のコンポーネントのコンテナを3台増加させる場合に、「サーバ1」と「サーバ2」との中から、配置先サーバを決定する例である。

0114

現状は、「サーバ1」の方が余剰リソースが多い(「tmpDataset」が小さい)。そのため、配置先サーバ決定部156は、1台目のコンテナの配置先を、「サーバ1」に決定する。「サーバ1」に1台のコンテナの配置が決定したことで「サーバ1」の余剰リソースが減り、「サーバ1」よりも「サーバ2」の方が余剰リソースが多くなっている。そこで配置先サーバ決定部156は、2台目のコンテナの配置先を、「サーバ2」に決定する。「サーバ2」に2台のコンテナの配置が決定したことで「サーバ2」の余剰リソースが減り、「サーバ2」よりも「サーバ1」の方が余剰リソースが多くなっている。そこで配置先サーバ決定部156は、3台目のコンテナの配置先を、「サーバ3」に決定する。

0115

このように、配置先サーバ決定部156は、コンテナ要因度符号が正の場合、要因コンポーネントのリソースが不足していると判断し、増加させるコンテナ数と、コンテナの配置先とを決定する。そしてコンテナ配置制御部157は、決定されたコンテナの配置先に基づいて、要因コンポーネントのスケールアウトを行う。またコンテナ配置制御部157は、要因コンポーネントの要因度が負の場合であり、かつサーバ要因度符号が「正」の場合、要因コンポーネント以外のコンポーネントによるリソースの負荷が大きい影響で、要因コンポーネントの性能が低下していると判断する。この場合、コンテナ配置制御部157は、コンテナの配置変換を行う。コンテナの配置変換は、コンテナを稼働させるサーバを、別のサーバに変更する処理である。

0116

要因コンポーネントのリソースが不足している場合、増加させるコンテナ数として決定された数のコンテナを要因コンポーネントに追加するスケールアウトを実施することによって、サービスのApdex値が目標値より大きくなる。

0117

図23は、性能調整結果の一例を示す図である。図23の例では、Apdex値の目標値は0.8以上である。性能調整前はApdex値が「0.75」であったのが、性能調整を行うことで、Apdex値が「0.83」まで向上している。

0118

なお、コンテナを一度に大量に追加するようなスケールアウト処理を実施すると、システム全体の処理負荷が一時的に過大となる可能性がある。そこで配置先サーバ決定部156は、一度にスケールアウトできるコンテナ数の上限値を設け、算出した増加コンテナ数が上限値を超える場合には、上限値を、増加コンテナ数とする。そして配置先サーバ決定部156とコンテナ配置制御部157とは、連係して、上限値分のコンテナをサーバに配置した後、Apdex値が目標値以上となるまで、要因コンポーネントのスケールアウトを繰り返す。

0119

次に性能調整処理の手順について詳細に説明する。
図24は、性能調整処理の手順の一例を示すフローチャートである。なお図24に示す処理は、1つのサービスについて性能調整を行う場合の処理である。複数のサービスについて性能調整を行う場合、図24に示す処理が、複数のサービスそれぞれについて実行される。以下、図24に示す処理をステップ番号に沿って説明する。

0120

[ステップS101]性能調整エンジン150は、例えば管理者により、サービスの性能調整処理の開始指示の入力が行われると、繰り返し回数を示す変数Rの値を「0」に初期化する。

0121

[ステップS102]レイテンシ検査部153は、性能調整対象のサービスについてのサービス情報と、そのサービスのレイテンシとを取得する。例えばレイテンシ検査部153は、サービス情報記憶部110からサービス情報を取得する。取得するサービス情報には、性能要件として指定されているApdexの値、Apdexの算出に用いるSatisfied Time(T)が含まれる。またレイテンシ検査部153は、ゲートウェイ41のレイテンシ記憶部41bから、直近の所定期間内に計測された、性能調整対象のサービスに対するリクエストのレイテンシを取得する。

0122

[ステップS103]レイテンシ検査部153は、複数のリクエストのレイテンシに基づいて、サービスのApdexを計算する。
[ステップS104]レイテンシ検査部153は、ステップS103で計算したApdexの値が、性能要件を満たしているか否かを判断する。例えばレイテンシ検査部153は、算出したApdex値が性能要件として指定されたApdex値以上であれば、性能要件を満たしていると判断する。レイテンシ検査部153は、性能要件を満たしている場合、処理をステップS105に進める。またレイテンシ検査部153は、性能要件を満たしていない場合、処理をステップS107に進める。

0123

[ステップS105]振る舞い計算部154は、コンテナとサーバとの正常時の振る舞いを計算して、正常時振る舞い記憶部130に保存する。例えば振る舞い計算部154は、メトリック情報記憶部120から、コンテナとサーバとの直近の所定期間分のメトリックの値を取得し、複数のパーセンタイル種別についてのパーセンタイル値を計算する。そして振る舞い計算部154は、コンテナのパーセンタイル値を設定したコンテナ振る舞い管理テーブルを、そのコンテナの正常時の振る舞いを示す情報として、正常時振る舞い記憶部130に格納する。また振る舞い計算部154は、サーバのパーセンタイル値を設定したサーバ振る舞い管理テーブルを、そのサーバの正常時の振る舞いを示す情報として、正常時振る舞い記憶部130に格納する。

0124

[ステップS106]性能調整エンジン150は、繰り返し回数を示す変数Rを「0」にリセットする。その後、性能調整エンジン150は、処理をステップS102に進める。

0125

[ステップS107]振る舞い計算部154は、コンテナとサーバとの異常時の振る舞いを計算する。例えば振る舞い計算部154は、メトリック情報記憶部120から、コンテナとサーバとの直近の所定期間分のメトリックの値を取得し、複数のパーセンタイル種別についてのパーセンタイル値を計算する。複数のコンテナそれぞれについて算出したパーセンタイル値が、対応するコンテナの異常時の振る舞いを示す情報である。また複数のサーバそれぞれについて算出したパーセンタイル値が、対応するサーバの異常時の振る舞いを示す情報である。

0126

[ステップS108]異常要因推定部155は、性能調整対象のサービスの提供に使用されるコンポーネントを実行するコンテナの正常時と異常時との振る舞いの差を、メトリック種別ごとに計算する。例えば異常要因推定部155は、正常時振る舞い記憶部130から重み付きパーセンタイル値を取得する。次に異常要因推定部155は、正常時の振る舞いを示す重み付きパーセンタイル値と、ステップS107で計算した異常時の振る舞いを示すパーセンタイル値とを比較して、メトリック種別ごとに正の要因度と負の要因度を計算する。

0127

[ステップS109]異常要因推定部155は、ステップS108における計算結果に基づいて、要因コンポーネントを推定する。例えば異常要因推定部155は、メトリック種別ごとの正の要因度と負の要因度との中から、最も大きな値の要因度を抽出する。そして異常要因推定部155は、抽出した要因度を算出元となったコンテナで実行されているコンポーネントを、要因コンポーネントとして推定する。

0128

[ステップS110]性能調整エンジン150は、繰り返し回数を示す変数Rの値が、閾値X(Xは、1以上の整数)に達したか否かを判断する。性能調整エンジン150は、繰り返し回数が閾値Xに達した場合、性能調整を断念し、処理を終了する。またコンテナ配置制御部157は、繰り返し回数が閾値Xに達していなければ、処理をステップS111に進める。

0129

[ステップS111]コンテナ配置制御部157は、ステップS109において抽出した要因度の符号(コンテナ要因度符号)が正か否かを判断する。コンテナ配置制御部157は、正の要因度であれば、処理をステップS112に進める。またコンテナ配置制御部157は、負の要因度であれば、処理をステップS113に進める。

0130

[ステップS112]配置先サーバ決定部156とコンテナ配置制御部157は、連係して、要因コンポーネントのスケールアウト処理を実施する。すなわち配置先サーバ決定部156が、要因コンポーネントに増加させるコンテナ数と、増加させるコンテナの配置先のサーバとを決定する。そしてコンテナ配置制御部157は、要因コンポーネントを実行するコンテナを、決定されたサーバに追加で配置する。スケールアウト処理の詳細は後述する(図25参照)。その後、コンテナ配置制御部157は、処理をステップS115に進める。

0131

[ステップS113]コンテナ配置制御部157は、サーバ要因度符号が正か否かを判断する。コンテナ配置制御部157は、サーバ要因度符号が正の場合、処理をステップS114に進める。またコンテナ配置制御部157は、サーバ要因度符号が負の場合、性能調整を断念し、処理を終了する。

0132

[ステップS114]コンテナ配置制御部157は、コンテナの配置変更を行う。すなわちコンテナ配置制御部157は、ステップS109で抽出した要因度の計算元となったコンテナの配置先を、現在のサーバから別のサーバに変更する。

0133

[ステップS115]性能調整エンジン150は、繰り返し回数を示す変数Rの値を1だけカウントアップし、処理をステップS102に進める。
このようにして、スケールアウトまたは配置変更により、サービスが性能要件を満たすように、コンポーネントの処理能力が調整される。

0134

次に、スケールアウト処理について詳細に説明する。
図25は、スケールアウト処理の手順の一例を示すフローチャートである。以下、図25に示す処理をステップ番号に沿って説明する。

0135

[ステップS121]配置先サーバ決定部156は、増加コンテナ数決定処理を行う。増加コンテナ数決定処理により、要因コンポーネントに追加するコンテナ数が決定される。増加コンテナ数決定処理の詳細は後述する(図26参照)。

0136

[ステップS122]配置先サーバ決定部156は、配置先サーバ決定処理を行う。配置先サーバ決定処理により、増加コンテナ数分の各コンテナについて、そのコンテナの配置先のサーバが決定される。配置サーバ決定処理の詳細は後述する(図27参照)。

0137

[ステップS123]配置先サーバ決定部156は、増加コンテナ数分の配置先サーバが決定できたか否かを判断する。配置先サーバ決定部156は、増加コンテナ数分の配置先サーバが決定できた場合、処理をステップS124に進める。また配置先サーバ決定部156は、増加コンテナ数分の配置先サーバが決定できなかった場合、コンテナの配置不可を判断して、スケールアウト処理を終了する。

0138

[ステップS124]コンテナ配置制御部157は、決定された配置先のサーバに、要因コンポーネントのコンテナを追加配置する。
このようにして、適切な数のコンテナを一度に配置することができる。

0139

次に、増加コンテナ数決定処理の手順について詳細に説明する。
図26は、増加コンテナ数決定処理の手順の一例を示すフローチャートである。以下、図26に示す処理をステップ番号に沿って説明する。

0140

[ステップS131]配置先サーバ決定部156は、性能要件を満たしていないサービスの「satisfied counts」、「tolerating counts」、および「total counts」を、レイテンシ検査部153から取得する。また配置先サーバ決定部156は、コンテナ配置管理テーブル141に基づいて、要因コンポーネントの現在のコンテナ数(#current)を計数する。

0141

[ステップS132]配置先サーバ決定部156は、1つのコンテナ当たりの「satisfied counts」(SCper1C)と、1つのコンテナ当たりの「tolerating counts」(TCper1C)とを計算する。また配置先サーバ決定部156は、「#increment」に初期値「1」を設定する。

0142

[ステップS133]配置先サーバ決定部156は、#incrementが所定の上限値に達したか否かを判断する。上限値は、システム全体の処理能力に応じて、管理者が予め設定した値である。配置先サーバ決定部156は、#incrementが上限値に達した場合、処理をステップS137に進める。また配置先サーバ決定部156は、#incrementが上限値に達していなければ、処理をステップS134に進める。

0143

[ステップS134]配置先サーバ決定部156は、A=((SCper1C×(#current+#increment))+(TCper1C×(#current+#increment))/2)/(total counts)を計算する。

0144

[ステップS135]配置先サーバ決定部156は、AがApdexの目標値以上か否かを判断する。配置先サーバ決定部156は、AがApdexの目標値以上であれば、処理をステップS137に進める。また配置先サーバ決定部156は、AがApdexの目標値未満であれば、処理をステップS136に進める。

0145

[ステップS136]配置先サーバ決定部156は、「#increment」の値に「1」を加算して、処理をステップS133に進める。
[ステップS137]配置先サーバ決定部156は、現在の「#increment」の値を増加コンテナ数に決定する。

0146

増加コンテナ数を決定すると、次に配置先サーバ決定部156は、増加コンテナ数分のコンテナの配置先のサーバを決定する。
図27は、配置先サーバ決定処理の手順の一例を示すフローチャートである。以下、図27に示す処理をステップ番号に沿って説明する。

0147

[ステップS141]配置先サーバ決定部156は、配置先のサーバが決定されたコンテナ数を示す「inc」に、初期値「0」を設定する。
[ステップS142]配置先サーバ決定部156は、「inc」の値が、増加コンテナ数を示す「#increment」の値と等しいか否かを判断する。配置先サーバ決定部156は、値が等しければ、処理をステップS148に進める。また配置先サーバ決定部156は、値が等しくなければ、処理をステップS143に進める。

0148

[ステップS143]配置先サーバ決定部156は、余剰リソース最大サーバ探索処理を行う。余剰リソース最大サーバ探索処理の結果として、余剰リソースが最大となるサーバの識別子を示す「dest」が得られる。なお、コンテナを追加可能なサーバが存在しない場合、「dest」の値は「nil」となる。余剰リソース最大サーバ探索処理の詳細は後述する(図28参照)。

0149

[ステップS144]配置先サーバ決定部156は、「dest」の値が「nil」か否かを判断する。配置先サーバ決定部156は、値が「nil」であれば、処理をステップS145に進める。また配置先サーバ決定部156は、値が「nil」でなければ、処理をステップS146に進める。

0150

[ステップS145]配置先サーバ決定部156は、増加コンテナ数分のコンテナのサーバへの配置が不可である旨の決定をして、配置先サーバ決定処理を終了する。
[ステップS146]配置先サーバ決定部156は、配置先のサーバの識別子の配列である「Destinations」に、「dest」の値を追加する。

0151

[ステップS147]配置先サーバ決定部156は、「inc」の値に1を加算し、処理をステップS142に進める。
[ステップS148]配置先サーバ決定部156は、「Destinations」を、配置先サーバのリストとして出力する。

0152

このようにして、増加コンテナ数分のコンテナの配置先のサーバが決定される。次に、余剰リソース最大サーバ探索処理について説明する。
図28は、余剰リソース最大サーバ探索処理の手順の一例を示すフローチャートである。以下、図28に示す処理をステップ番号に沿って説明する。

0153

[ステップS151]配置先サーバ決定部156は、メトリック情報記憶部120から、コンテナおよびサーバの各メトリックの計測値を取得し、リソース情報記憶部140から、要因コンポーネントのコンテナの現在の配置先サーバの情報を取得する。そして、配置先サーバ決定部156は、取得した情報に基づいて、メトリックごとの計測データを、以下のような変数または配列に設定する。
・メトリックごとの計測データ:{メトリック名:(CntData,SrvData)}
「CntData」は、要因メトリックに関する各コンテナの計測データである。例えば要因メトリックが「CPU使用率」であれば、各コンテナのCPU使用率の計測値である。「CntData」は、(Counts,cDataset)で表される。「Counts」は、スケーリング前の各サーバの要因コンテナ(要因コンポーネントのコンテナ)の数であり、{サーバ名:#container}で表される。「cDataset」は、収集周期で計測された要因コンテナのメトリック値であり、[0.2,0.4,0.1,...]というような数値の配列である。「cDataset」内のメトリック値を示す各要素は、計測された要因コンテナの収集周期内での平均値であり、最大が「1」となるように正規化されている。

0154

「SrvData」は、要因メトリックに関するサーバに関するデータである。「SrvData」には、(ServerDataInfo,MaxValue)で表される。「ServerDataInfo」は、サーバのメトリックの計測値であり、{サーバ名:sDataset}で表される。「sDataset」は、収集周期で計測されたサーバに関するメトリック値であり、[0.8,0.5,0.2,...]というような数値の配列である。「sDataset」内のメトリック値を示す各要素は、計測された要因コンテナの収集周期内での平均値であり、最大が「1」となるように正規化されている。「MaxValue」は、コンテナ追加後に許容される、リソースごとのメトリックの上限値である。メトリックの上限値は、メトリックの値の最大が「1」となるように正規化された値である。例えばコンテナを追加しても、サーバのCPU使用率を80%以下に抑える場合、CPU使用率の上限値は「0.8」に設定される。

0155

[ステップS152]配置先サーバ決定部156は、「dest」の値を「nil」に初期化する。また配置先サーバ決定部156は、「minDataset」に、要因メトリックの上限値を示す値の複数の要素[SrvData.MaxValue,SrvData.MaxValue,...]を設定する。要因メトリックの「SrvData.MaxValue」は、計測データ「SrvData」に示されるサーバで許容される、該当メトリックの上限値「MaxValue」を示している。例えば要因メトリックがCPU使用率であり、CPU使用率の上限値が80%(正規化後は「0.8」)であれば、CPU使用率の「minDataset」は、[0.8,0.8,...]となる。「minDataset」に設定される要素数は、「sDataset」および「cDataset」それぞれの要素数と同じである。

0156

[ステップS153]配置先サーバ決定部156は、すべてのサーバについてステップS154〜S157の処理が済んでいるか否かを判断する。配置先サーバ決定部156は、すべてのサーバについての処理が済んでいる場合、余剰リソース最大サーバ探索処理を終了する。また配置先サーバ決定部156は、未処理のサーバがある場合、処理をステップS154に進める。

0157

[ステップS154]配置先サーバ決定部156は、未処理のサーバを1つ選択する。
[ステップS155]配置先サーバ決定部156は、選択したサーバに要因コンテナを1台追加配置した場合の、そのサーバのリソースの使用量を示す値「tmpDataset」を、リソースごとに算出する。「tmpDataset」は、以下の式で算出できる。
・tmpDataset=SrvData.ServerDataInfo[サーバ名]+Δ×(1+CntData.Counts[サーバ名]+Destinations[サーバ名])−CntData.cDataset×CntData.Counts[サーバ名]
「SrvData.ServerDataInfo[サーバ名]」は、[サーバ名]で示されるサーバのメトリックの計測値を示している。「CntData.Counts[サーバ名]」は、[サーバ名]で示されるサーバ内の要因コンテナの数を示している。「Destinations[サーバ名]」は、[サーバ名]で示されるサーバへ追加配置が決定されたコンテナの数を示している。「CntData.cDataset」は、要因コンポーネントの現状における1コンテナ当たりのメトリック値である。「CntData.Counts[サーバ名]」は、[サーバ名]で示されるサーバに現在配置されている要因コンテナの数である。

0158

なお「SrvData.ServerDataInfo[サーバ名]」などの各項には、複数の要素(例えば収集周期ごとに計測された複数のメトリック値)が含まれている。配置先サーバ決定部156は、「tmpDataset」を計算する場合、配列内の同じ順番の要素同士で計算を行う。従って、「tmpDataset」には、選択したサーバのリソースの、メトリック値の収集周期ごとの使用量が示される。

0159

配置先サーバ決定部156は、例えば、選択したサーバの「tmpDataset」を、メトリックごとに計算する。
[ステップS156]配置先サーバ決定部156は、「tmpDataset」内の収集周期ごとの要素それぞれについて、「SrvData.MaxValue」に示される該当要素のメトリックの上限値より大きいか否かを判断する。この判断は、複数のリソースそれぞれについて行われる。配置先サーバ決定部156は、いずれか少なくとも1つのリソースについて、「tmpDataset」内に「SrvData.MaxValue」に示される上限値より大きい値の要素が少なくとも1つ含まれている場合、ステップS156の判断において「YES」と判断する。また、配置先サーバ決定部156は、すべてのリソースについて、「tmpDataset」内のすべての要素の値が「SrvData.MaxValue」に示される上限値以下の場合、ステップS156の判断において「NO」と判断する。

0160

配置先サーバ決定部156は、ステップS156で「YES」と判断した場合、処理をステップS153に進める。また配置先サーバ決定部156は、ステップS156で「NO」と判断した場合、処理をステップS157に進める。

0161

ステップS156の処理によって、コンテナを追加することにより、いずれかのリソースの使用量が上限値を超える可能性のあるサーバは、コンテナの配置先から除外される。
[ステップS157]配置先サーバ決定部156は、選択したサーバの要因メトリックの「tmpDataset」と「minDataset」とを比較し、「tmpDataset」の方が小さいか否かを判断する。例えば「tmpDataset」内の各要素の値の平均値が、「minDataset」内の各要素の値の平均値より小さければ、「tmpDataset」の方が小さいと判断する。配置先サーバ決定部156は、「tmpDataset」の方が小さい場合、処理をステップS158に進める。また配置先サーバ決定部156は、「tmpDataset」が「minDataset」以上の場合、処理をステップS153に進める。

0162

[ステップS158]配置先サーバ決定部156は、「dest」に、選択したサーバのサーバ名を設定する。また配置先サーバ決定部156は、「minDataset」に、選択したサーバの要因メトリックの「tmpDataset」の各要素の値を設定する。その後、配置先サーバ決定部156は、処理をステップS153に進める。

0163

このようにして、余剰リソースが最大となるサーバが探索される。そして余剰リソースが最大となるサーバのサーバ名が、「dest」に設定される。なお、ステップS156で「NO」、ステップS157で「YES」となるサーバが検出できなかった場合、「dest」の値は「nil」のままとなっている。「dest」に設定されたサーバ名は、図27のステップS146において「Destinations」に設定される。増加コンテナ数分のサーバが、配置先サーバとして特定できた場合、「Destinations」には、増加コンテナ数分のサーバ名が設定される。なお、1つのサーバに2台以上のコンテナを追加配置する場合、そのサーバのサーバ名が「Destinations」内に複数設定される。

0164

以上説明したように、第2の実施の形態によれば、要因コンポーネントのコンテナのスケールアウトを行う際、サービスの性能要件を満たすための最小限の増加コンテナ数が算出され、その増加コンテナ数分のコンテナが自動で配置される。これにより、1台ずつコンテナのスケールアウトを行い、その都度、性能要件が満たされるかどうかを確認する場合に比べて、スケールアウトの処理が効率的となる。その結果、サービスが性能要件を満たすことができなくなった時点から、早期に性能要件を満たすようにスケールアウトを実施することができ、サービスの性能劣化期間を最小限に抑えることができる。例えば、スケールアウト実施周期が1時間で、性能要件を満たすための増加コンテナ数が3つの場合、1台ずつスケールアウトを行うと、性能要件を満していない期間が最大で3時間となる。それに対して、第2の実施の形態では、性能要件を満していない期間が最大でも1時間ですむ。

0165

しかも管理サーバ100は、余剰リソースができるだけ多くなるように、コンテナの配置先のサーバを決定している。これにより、複数のサーバの負荷を平均化し、システム全体の処理効率を向上させることができる。

0166

さらに、図20に示したように、管理サーバ100は、コンテナを追加すると、既に配置されているコンテナによるサーバの負荷が低下することを考慮にいれて余剰リソースを求めている。これにより、正確な余剰リソースを算出できる。その結果、余剰リソースが最も多くなるサーバを、正しく判断することができる。

0167

〔その他の実施の形態〕
第2の実施の形態では、サービスが性能要件を満たすか否かの判定基準として、Apdex値を用いているが、他の指標を判定基準としてもよい。例えば、所定のレイテンシを超えた処理の割合を、判定基準としてもよい。

0168

また第2の実施の形態では、サービスの性能が性能要件を満たしているときと満たしていないときとの動作状態の差が最も大きいメトリックを、要因メトリックとしているが、他の方法で要因メトリックを判定してもよい。さらには、要因メトリックを自動判定せずに、要因メトリックを管理者が判断し、管理サーバに入力するようにしてもよい。

0169

以上、実施の形態を例示したが、実施の形態で示した各部の構成は同様の機能を有する他のものに置換することができる。また、他の任意の構成物や工程が付加されてもよい。さらに、前述した実施の形態のうちの任意の2以上の構成(特徴)を組み合わせたものであってもよい。

0170

1〜3サーバ
4a,4b,5a,5b,6a,6b単位機能
7端末装置
8サービス
10管理装置
11 記憶部
12 処理部

ページトップへ

この技術を出願した法人

この技術を発明した人物

ページトップへ

関連する挑戦したい社会課題

該当するデータがありません

関連する公募課題

該当するデータがありません

ページトップへ

技術視点だけで見ていませんか?

この技術の活用可能性がある分野

分野別動向を把握したい方- 事業化視点で見る -

(分野番号表示ON)※整理標準化データをもとに当社作成

ページトップへ

おススメ サービス

おススメ astavisionコンテンツ

新着 最近 公開された関連が強い技術

この 技術と関連性が強い技術

関連性が強い 技術一覧

この 技術と関連性が強い人物

関連性が強い人物一覧

この 技術と関連する社会課題

該当するデータがありません

この 技術と関連する公募課題

該当するデータがありません

astavision 新着記事

サイト情報について

本サービスは、国が公開している情報(公開特許公報、特許整理標準化データ等)を元に構成されています。出典元のデータには一部間違いやノイズがあり、情報の正確さについては保証致しかねます。また一時的に、各データの収録範囲や更新周期によって、一部の情報が正しく表示されないことがございます。当サイトの情報を元にした諸問題、不利益等について当方は何ら責任を負いかねることを予めご承知おきのほど宜しくお願い申し上げます。

主たる情報の出典

特許情報…特許整理標準化データ(XML編)、公開特許公報、特許公報、審決公報、Patent Map Guidance System データ