JP2019135598A - 性能評価プログラム、および性能評価方法 - Google Patents

Abstract

【課題】性能悪化要因の処理を特定できるようにする。【解決手段】コンピュータは、サービス１の性能を示す性能情報が性能要件を満たしていない場合、複数の処理それぞれについての、直近の所定期間における、データ受信負荷を示す第１負荷直近値、データ送信負荷を示す第２負荷直近値、および受信したデータに応じた処理負荷を示す第３負荷直近値を取得する。またコンピュータは、複数の処理それぞれについての、サービス１の性能が性能要件を満たしているときの、データ受信負荷を示す第１負荷正常値、データ送信負荷を示す第２負荷正常値、および受信したデータに応じた処理負荷を示す第３負荷正常値を取得する。そしてコンピュータは、第１負荷直近値が第１負荷正常値より大きく、第２負荷直近値が第２負荷正常値より小さく、第３負荷直近値が第３負荷正常値より大きいという要件に合致する要件合致処理の処理名を出力する。【選択図】図１

Description

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

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

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

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

クラウドコンピューティングシステムの管理者は、サービスの品質が保てるように、サービスを実現するコンポーネントの性能を適宜調整する。例えば管理者は、性能要件として、サービスを提供する際のレイテンシの最大値を定め、サービスのレイテンシが最大値を超えた場合、そのサービスの提供に利用しているコンポーネントを実行する処理能力を増強することとなる。

システムの管理技術としては、例えば複数の情報処理装置を有する情報処理システムの中から異常の生じた情報処理装置を効率的に検出する技術がある。

特開２００８−０２７０６１号公報

マイクロサービスアーキテクチャにおいて、サービスのレイテンシが最大値を超えたというだけでは、性能要件を満たさなくなったサービスで利用している複数のコンポーネントのうち、どのコンポーネントに性能悪化の要因があるのかが分からない。特にＰａａＳでは、ＰａａＳの利用者がコンポーネントを作成しており、システムの管理者は、コンポーネントの具体的な処理内容を知ることができない。そのためシステムの管理者が、性能悪化の要因となっているコンポーネントを適確に特定するのは困難である。

なお、性能悪化の要因となっている処理の特定が難しいという問題は、マイクロサービスアーキテクチャに準じて作成されたサービスに限らず、複数の処理を連係させることで提供されるサービスの性能を調整する場合に同様に生じる問題である。

１つの側面では、本件は、性能悪化要因の処理を特定できるようにすることを目的とする。

１つの案では、コンピュータに以下の処理を実行させる性能評価プログラムが提供される。
性能評価プログラムに基づいて、コンピュータは、複数の処理を連係させることで提供されるサービスの性能を示す性能情報を取得する。次にコンピュータは、性能情報が、サービスに求められる性能を示す性能要件を満たしているか否かを判断する。次にコンピュータは、性能情報が性能要件を満たしていない場合、複数の処理それぞれについての、直近の所定期間における、データ受信負荷を示す第１負荷直近値、データ送信負荷を示す第２負荷直近値、および受信したデータに応じた処理負荷を示す第３負荷直近値を取得する。次にコンピュータは、複数の処理それぞれについての、サービスの性能が性能要件を満たしているときの、データ受信負荷を示す第１負荷正常値、データ送信負荷を示す第２負荷正常値、および受信したデータに応じた処理負荷を示す第３負荷正常値を、メモリから取得する。そしてコンピュータは、第１負荷直近値が第１負荷正常値より大きく、第２負荷直近値が第２負荷正常値より小さく、第３負荷直近値が第３負荷正常値より大きいという要件に合致する要件合致処理の処理名を、サービスの性能悪化要因として出力する。

１態様によれば、性能悪化要因の処理を特定できる。

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

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

図１は、第１の実施の形態に係るシステムの構成例を示す図である。複数の処理（「処理ａ」、「処理ｂ」、「処理ｃ」）を連係して動作させることで提供されるサービス１が、複数のサーバ２〜４に実装されている。例えばサーバ２では「処理ａ」が実行され、サーバ３では「処理ｃ」が実行され、サーバ４では「処理ｂ」が実行されている。

例えば端末装置５からのサービス１のリクエストがサーバ２に入力される。するとサーバ２が「処理ａ」を実行する。サーバ２は、「処理ａ」の実行過程で、サーバ４に対して「処理ｂ」の処理要求を送信する。するとサーバ４が「処理ｂ」を実行する。サーバ４は、「処理ｂ」の実行過程で、サーバ３に対して「処理ｃ」の処理要求を送信する。するとサーバ３が「処理ｃ」を実行する。サーバ３は、「処理ｃ」の処理結果をサーバ４に送信する。サーバ４は、「処理ｃ」の処理結果を用いて「処理ｂ」の処理を実行し、「処理ｂ」の処理結果をサーバ２に送信する。サーバ２は、「処理ｂ」の処理結果を用いて「処理ａ」の処理を実行し、「処理ａ」の処理結果を、端末装置５からのリクエストに対するレスポンスとして端末装置５に送信する。

管理装置１０は、サーバ２〜４で提供されているサービス１を管理する。例えば管理装置１０は、サービス１の性能調整を行う。具体的には、管理装置１０は、サービス１の性能が悪化した場合、サービス１の性能悪化要因となる処理を特定する。そして管理装置１０は、性能悪化が解消するように、サーバ２〜４に実行させる処理を制御する。

ここで、サービス１の性能悪化要因となる処理を特定することの困難性について説明する。
まず、性能悪化要因の第１の特定方法として、サービス１の提供に使用されている処理のうち、性能低下が発生したとき（異常時）の負荷が、性能低下が発生していないとき（正常時）の負荷に比べ、最も増加している処理を、性能悪化要因とみなす方法が考えられる。処理の負荷の値としては、例えばその処理を実行する際のＣＰＵ（Central Processing Unit）使用率などの、リソースの動作状況を示す測定値を用いることができる。

この方法の場合、サービス１に利用される処理を実行しているサーバにおける他の処理の影響で、サービス１に利用される処理の速度が低下し、サービス１の性能が低下した場合に、性能低下要因を特定することができない。すなわち、同じサーバで実行されている他の処理の処理量が過大となり、サーバの処理能力が限界に達すると、サービス１の提供に使用されている処理は、その処理によるＣＰＵ使用率が低下し、処理効率が低下する。その結果、サービス１の性能が劣化する。しかし、サービス１の提供に使用されている処理のＣＰＵ使用率が、正常時より高くなっているわけではないため、上記の第１の特定方法では、サービス１の性能劣化要因となっている処理を正しく特定することができない。

そこで性能悪化要因の第２の特定方法として、正常時と異常時との負荷の差が最も大きな処理を、サービス１の性能を悪化させた要因とみなす方法が考えられる。この方法であれば、サービス１の提供に使用されている処理と同じサーバで実行されている他の処理の影響で、サービス１の提供に利用される処理のＣＰＵ使用率が大幅に低下した場合、その処理がサービス１の悪化要因であると特定できる。この場合、サービス１の性能悪化時には、サービス１に利用される処理を実行しているサーバの負荷が正常時よりも増加しているという条件を加えることで、より正確な性能悪化要因の特定が可能となる。

しかし、第２の特定方法であっても、性能悪化要因の処理を、正しく特定できない場合がある。例えば、呼び出し元の処理の性能が不足した結果、呼び出し先の処理へ処理対象のデータを送信できず、呼び出し先の処理の負荷が低下する場合がある。このような場合には、呼び出し先の処理によるＣＰＵ使用率は正常時に比べて低下するが、この処理自身は、サービス１の性能低下の要因ではない。このように、サービス１の性能悪化要因となる処理を特定するのは容易ではない。

そこで管理装置１０により、各サーバ２〜４での処理の動作状態に基づいて、性能悪化要因となる処理を適確に特定する性能管理方法を実現する。そのために、管理装置１０は、以下のような記憶部１１と処理部１２とを有する。記憶部１１は、例えば管理装置１０が有するメモリまたはストレージ装置である。処理部１２は、例えば管理装置１０が有する１または複数のプロセッサである。処理部１２が実行する処理は、例えばその処理の手順が記述された性能評価プログラムをプロセッサに実行させることで実現できる。

記憶部１１は、複数の処理それぞれについての、サービス１の性能が所定の性能要件を満たしているときの動作状況を示す情報（負荷平常値）を記憶する。処理の動作状況を示す情報は、具体的には、データ受信負荷を示す第１負荷正常値、データ送信負荷を示す第２負荷正常値、および受信したデータに応じた処理負荷を示す第３負荷正常値である。第１負荷平常値は、例えば平常時の単位時間当たりのデータ受信量である。第２負荷平常値は、例えば平常時の単位時間当たりのデータ送信量である。第３負荷平常値は、例えばＣＰＵ使用率、平常時のメモリ使用率などの、データ処理量に応じて値が変動する計測値の平常時の値である。なお記憶部１１は、第３負荷平常値として、複数の計測値を記憶していてもよい。

処理部１２は、複数の処理を連係させることで提供されるサービス１の性能を示す性能情報を取得する。例えば処理部１２は、端末装置５とサーバ２との間の通信を監視し、リクエストからレスポンスまでの時間（レイテンシ）を取得する。処理部１２は、例えば複数のリクエストに対するレイテンシに基づいて、Ａｐｄｅｘ（Application performance index）などの性能の指標値を算出する。Ａｐｄｅｘについては後述する。

処理部１２は、取得した性能情報が、性能要件を満たしているか否かを判断する。例えば性能要件として、Ａｐｄｅｘが０．８以上であることが指定されているものとする。この場合、処理部１２は、取得した性能情報に基づいて算出したＡｐｄｅｘ値が、０．８以上か否かを判断する。

性能情報が性能要件を満たしていない場合、処理部１２は、複数の処理それぞれについての、直近の所定期間におけるサーバ２〜４での各処理の動作状況を示す情報（負荷直近値）を、サーバ２〜４から取得する。動作状況を示す情報は、具体的には、データ受信負荷を示す第１負荷直近値、データ送信負荷を示す第２負荷直近値、および受信したデータに応じた処理負荷を示す第３負荷直近値である。第１負荷直近値は、例えば直近の単位時間当たりのデータ受信量である。第２負荷直近値は、例えば直近の単位時間当たりのデータ送信量である。第３負荷直近値は、例えばＣＰＵ使用率、メモリ使用率などの、データ処理量に応じて値が変動する計測値の直近の値である。なお処理部１２は、第３負荷直近値として、複数の計測値を取得してもよい。

次に処理部１２は、複数の処理それぞれについての、負荷平常値（第１負荷平常値、第２負荷平常値、第３負荷平常値）を、記憶部１１から取得する。
次に処理部１２は、第１負荷直近値が第１負荷正常値より大きく、第２負荷直近値が第２負荷正常値より小さく、第３負荷直近値が第３負荷正常値より大きいという要件に合致する要件合致処理の処理名を、サービス１の性能悪化要因として出力する。なお第３負荷直近値と第３負荷正常値とを、それぞれ複数取得している場合、処理部１２は、同種のリソースに関する第３負荷直近値と第３負荷正常値とを比較する。そして処理部１２は、ある処理の少なくとも１つのリソースに関し、第３負荷直近値の方が第３負荷正常値よりも大きければ、その処理について、第３負荷直近値が第３負荷正常値より大きいと判断してもよい。

なお処理部１２は、複数の処理のうち、直近の処理負荷と正常時の処理負荷との差が最も大きい負荷差最大処理を判断し、負荷差最大処理の正常時の処理負荷の方が直近の処理負荷より大きい場合に限り、要件合致処理の処理名を出力するようにしてもよい。また処理部１２は、負荷差最大処理の直近の処理負荷の方が正常時の処理負荷より大きい場合、負荷差最大処理の処理名を、サービス１の性能悪化要因として出力してもよい。

なお、サービス１の性能悪化要因となっている処理が特定できない場合もある。この場合、処理部１２は、例えば、負荷差最大処理の正常時の処理負荷の方が直近の処理負荷より大きく、要件合致処理が存在しない場合、負荷差最大処理を実行しているサーバについて、サービス１の性能が性能要件を満たしていないときの負荷が、サービス１の性能が性能要件を満たしているときの負荷よりも大きい場合、サーバのサーバ名を、サービス１の性能悪化要因として出力する。

このようにして管理装置１０は、サービス１の提供に使用されている処理のうち、どの処理が性能悪化要因となっているのかを、適確に判定することができる。すなわち管理装置１０は、処理するデータ量が増加し、データを処理しきれなくなった処理を、サービス１の性能悪化要因として適確に特定し、その処理の処理名を出力することができる。その結果、例えば出力された処理名を管理者が確認し、管理者が、性能悪化要因の処理のスケールアウトの操作を行うことで、サービス１の性能悪化に対して、迅速に対処することができる。また管理装置１０がサーバ２〜４を制御し、出力した処理名の処理のスケールアウトを自動で行ってもよい。

なお性能悪化要因としてサーバ名が出力された場合、管理者は、サービス１の提供に使用されている処理を、性能悪化要因のサーバとは別のサーバで実行させるように、処理に機能移動指示を行う。

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

マイクロサービスアーキテクチャによるサービスの性能が低下している状況において、平常時より大きく負荷が低下しているコンポーネントがある場合、性能低下の原因は、そのコンポーネントとは別のコンポーネントである可能性が高い。例えば、負荷が低下しているコンポーネントに対して処理要求を送信するコンポーネントにおいて、処理量が過大となって、処理が停滞している場合が考えられる。

このとき、サービスの提供に使用されるコンポーネント間の呼び出し順序が分かれば、その負荷が極端に低下したコンポーネントの呼び出し元を辿ることで、サービスの性能低下の要因となるコンポーネントを見つけ出せる可能性がある。しかし、ＰａａＳでは、サービスの提供に使用されるコンポーネント間の呼び出し順序は、管理者には簡単には分からない。

例えば、呼び出しを追跡できるようにコンポーネントのソースコードを修正すれば、コンポーネント間の呼び出し関係を管理者が把握することも可能となる。しかし、ＰａａＳでは、コンポーネントのソースプログラムは、ＰａａＳ利用者の管理下にあり、ＰａａＳの管理者が書き換えることはできない。

またコンテナが接続されている仮想スイッチで通信を捕捉・解析して、コンポーネント間の呼び出し関係を把握することも可能である。しかし、システム内にこのような捕捉・解析機能を導入すると、コンポーネントの性能が大きく低下してしまう。

このように、ＰａａＳの管理者がサービスの提供に使用されるコンポーネント間の呼び出し順序を常に把握できるようにすることは、現実的には難しい。
そこで第２の実施の形態では、管理サーバにより、サービスの性能が性能要件を満たしているときの各コンポーネントの動作状態と、サービスの性能が性能要件を満たしていないときの各コンポーネントの動作状態とを比較して、解析する。そして管理サーバは、解析結果に基づいて、サービスの性能が低下した要因であるコンポーネントを、適切に判断する。例えば管理サーバは、コンポーネント内で処理量が増加し、処理しきれなくなってしまっているコンポーネントを、サービスの性能が低下した要因と判断する。

図２は、第２の実施の形態のシステム構成例を示す図である。クラウドコンピューティングシステム４０には、ネットワーク２０を介して複数の端末装置３１，３２，・・・が接続されている。クラウドコンピューティングシステム４０は、複数の端末装置３１，３２，・・・に対して、ＰａａＳによるサービスを提供する。

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

図３は、管理サーバのハードウェアの一構成例を示す図である。管理サーバ１００は、プロセッサ１０１によって装置全体が制御されている。プロセッサ１０１には、バス１０９を介してメモリ１０２と複数の周辺機器が接続されている。プロセッサ１０１は、マルチプロセッサであってもよい。プロセッサ１０１は、例えばＣＰＵ、ＭＰＵ（Micro Processing Unit）、またはＤＳＰ（Digital Signal Processor）である。プロセッサ１０１がプログラムを実行することで実現する機能の少なくとも一部を、ＡＳＩＣ（Application Specific Integrated Circuit）、ＰＬＤ（Programmable Logic Device）などの電子回路で実現してもよい。

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

バス１０９に接続されている周辺機器としては、ストレージ装置１０３、グラフィック処理装置１０４、入力インタフェース１０５、光学ドライブ装置１０６、機器接続インタフェース１０７およびネットワークインタフェース１０８がある。

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

グラフィック処理装置１０４には、モニタ２１が接続されている。グラフィック処理装置１０４は、プロセッサ１０１からの命令に従って、画像をモニタ２１の画面に表示させる。モニタ２１としては、ＣＲＴ（Cathode Ray Tube）を用いた表示装置や液晶表示装置などがある。

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

光学ドライブ装置１０６は、レーザ光などを利用して、光ディスク２４に記録されたデータの読み取りを行う。光ディスク２４は、光の反射によって読み取り可能なようにデータが記録された可搬型の記録媒体である。光ディスク２４には、ＤＶＤ（Digital Versatile Disc）、ＤＶＤ−ＲＡＭ、ＣＤ−ＲＯＭ（Compact Disc Read Only Memory）、ＣＤ−Ｒ（Recordable）／ＲＷ（ReWritable）などがある。

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

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

以上のようなハードウェア構成によって、第２の実施の形態における管理サーバ１００の処理機能を実現することができる。なお、端末装置３１，３２，・・・、ゲートウェイ４１、およびサーバ４２〜４４も、管理サーバ１００と同様のハードウェアによって実現できる。また、第１の実施の形態に示した管理装置１０も、図３に示した管理サーバ１００と同様のハードウェアにより実現することができる。

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

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

コンポーネント５１〜５３は、複数のサーバ４２〜４４のいずれか１以上で実行される。コンポーネント５１〜５３を実行することでサーバ４２〜４４上に構築される処理機能がコンテナである。第２の実施の形態では、コンテナを「Ｃ_xy」と表している。添字の「ｘ」は、そのコンテナを含むコンポーネントの識別番号（コンポーネント番号）である。添字の「ｙ」は、そのコンテナを含むコンポーネント内でのコンテナの識別番号（コンテナ番号）である。

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

マイクロサービスアーキテクチャに準じて作成されたサービスのコンポーネント５１〜５３は、コンテナによって実行される。コンポーネント５１〜５３とコンテナは１対多の関係にある。

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

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

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

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

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

図５の例では、各サーバ４２〜４４には、異なるコンポーネントの複数のコンテナが配置されている。例えばサーバ４２には、コンテナＣ₁₁，Ｃ₂₂，Ｃ₃₁が配置されている。
以下、図６〜図１０を参照して、サービス情報記憶部１１０、メトリック情報記憶部１２０、正常時振る舞い記憶部１３０、およびリソース情報記憶部１４０が記憶する情報について、詳細に説明する。

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

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

図７は、サービス情報記憶部が記憶する情報の一例を示す図である。サービス情報記憶部１１０は、例えばサービス管理テーブル１１１を記憶している。サービス管理テーブル１１１は、サービス名、Ａｐｄｅｘ、Ｓａｔｉｓｆｉｅｄ Ｔｉｍｅ、およびコンポーネント名の欄が設けられている。サービス名の欄には、提供しているサービスの名称（サービス名）が設定される。Ａｐｄｅｘの欄には、対応するサービスに求められる性能要件が、Ａｐｄｅｘによって設定される。Ａｐｄｅｘは、レイテンシについてのユーザの満足度を示す指標である。Ｓａｔｉｓｆｉｅｄ Ｔｉｍｅの欄には、対応するサービスを利用するユーザが満足すると思われる最大のレイテンシの値（Ｔ）が設定される。コンポーネント名の欄には、サービスの提供に用いられるコンポーネントの名称が設定される。

ここで、Ａｐｄｅｘについて詳細に説明する。Ａｐｄｅｘは、「Ｔｈｅ Ａｌｌｉａｎｃｅ」によって標準化された指標であり、以下の式によって計算される。
・Ａｐｄｅｘ＝（（ｓａｔｉｓｆｉｅｄ ｃｏｕｎｔｓ）＋（ｔｏｌｅｒａｔｉｎｇ ｃｏｕｎｔｓ）／２）／（ｔｏｔａｌ ｃｏｕｎｔｓ）
「ｓａｔｉｓｆｉｅｄ ｃｏｕｎｔｓ」は、レイテンシがＴ以下のリクエスト回数である。すなわち「ｓａｔｉｓｆｉｅｄ ｃｏｕｎｔｓ」は、ユーザが満足できるレイテンシが得られたリクエストの回数である。

「ｔｏｌｅｒａｔｉｎｇ ｃｏｕｎｔｓ」は、レイテンシがＴ以上、かつ４×Ｔ以下のリクエスト回数である。すなわち「ｔｏｌｅｒａｔｉｎｇ ｃｏｕｎｔｓ」は、ユーザが満足できるレイテンシではないものの、許容できるレイテンシが得られたリクエストの回数である。

なお、レイテンシが４×Ｔより大きなリクエスト回数は、「ｆｒｕｓｔｒａｔｅｄ」と呼ばれる。この「ｆｒｕｓｔｒａｔｅｄ」は、ユーザが不満に感じるレイテンシとなったリクエストの回数である。

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

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

図９は、正常時振る舞い記憶部が記憶する情報の一例を示す図である。正常時振る舞い記憶部１３０は、例えば振る舞い測定周期ごとの複数のコンテナ振る舞い管理テーブル１３１ａ，１３１ｂ，・・・と、振る舞い測定周期ごとの複数のサーバ振る舞い管理テーブル１３２ａ，１３２ｂ，・・・とを記憶している。

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

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

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

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

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

サーバリソース管理テーブル１４２は、サーバ４２〜４４のリソースの空き量を管理するデータテーブルである。サーバリソース管理テーブル１４２は、サーバ名と残余リソース量との欄を有している。サーバ名の欄には、サービスの提供に使用しているサーバの名称（サーバ名）が設定される。残余リソース量の欄には、対応するサーバのリソースの空き量（残余リソース量）が、リソースの種別ごとに設定される。図１０の例では、ＣＰＵ、メモリ、ネットワークの残余リソース量が設定されている。

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

次に、性能調整エンジン１５０について詳細に説明する。
図１１は、性能調整エンジンの機能を示すブロック図である。性能調整エンジン１５０は、サービス管理部１５１、メトリック情報収集部１５２、レイテンシ検査部１５３、振る舞い計算部１５４、異常要因推定部１５５、およびコンテナ配置制御部１５６を有する。

サービス管理部１５１は、サービスの構成や性能要件を管理する。メトリック情報収集部１５２は、サーバ４２〜４４からメトリックの値を定期的に収集し、メトリック情報記憶部１２０に格納する。レイテンシ検査部１５３は、サービスのレイテンシが性能要件を満たしているか検査する。振る舞い計算部１５４は、コンテナとサーバとの正常時および異常時の振る舞いを計算する。振る舞い計算部１５４は、正常時の振る舞いを、正常時振る舞い記憶部１３０に格納する。異常要因推定部１５５は、レイテンシが性能要件を満たしていないサービスの異常要因となっているコンポーネント（要因コンポーネント）を推定する。コンテナ配置制御部１５６は、要因コンポーネントのスケールアウト、または要因コンポーネントを実行するコンテナの配置変更を行う。

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

次に、性能調整エンジン１５０における、各サービスが性能要件を満たしているか否かの判定処理について説明する。
図１２は、性能要件の判定処理の一例を示す図である。サービス管理部１５１は、管理者の入力に従って、サービス５０の性能要件として、Ａｐｄｅｘ値をサービス情報記憶部１１０に登録する。例えばサービス管理部１５１は、管理者からのＡｐｄｅｘ値とＳａｔｉｓｆｉｅｄ Ｔｉｍｅ（Ｔ）との入力を受け付ける。そしてサービス管理部１５１は、入力されたＡｐｄｅｘ値とＳａｔｉｓｆｉｅｄ Ｔｉｍｅ（Ｔ）とを、サービス管理テーブル１１１に、サービス５０のサービス名に対応付けて格納する。

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

次にメトリック情報収集部１５２によって、コンテナとサーバとのメトリック情報が収集され、メトリック情報記憶部１２０に格納される。収集されるメトリック情報には、例えばＣＰＵの使用率、メモリのＩ／Ｏレートやページフォルト数、ディスク（ファイルシステム）のＩ／Ｏレート、ネットワーク受信レート、ネットワーク送信レートなどが含まれる。収集されたメトリック情報に基づいて、振る舞い計算部１５４によって、直近の所定期間におけるコンテナとサーバとの振る舞いが計算される。

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

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

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

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

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

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

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

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

正常時のパーセンタイル値として、以下のデータが得られたものとする。Ｓ１は最新の周期のデータの集合である。Ｓ２は、Ｓ１の１つ前の周期のデータ集合である。Ｓ３は、Ｓ２の１つ前の周期のデータ集合である。
Ｓ１：｛１，２｝
Ｓ２：｛３，４｝
Ｓ３：｛５，６｝
この例では、重み付けの処理を分かりやすくするため、データの値を単純化している。Ｓ１，Ｓ２，Ｓ３に対する重み付きパーセンタイル値を求めるとき、重みの分だけ、各正常データの数を増やす。例えば、集合Ｓ１，Ｓ２，Ｓ３それぞれに対する重みを、「３」、「２」、「１」とする。この場合、集合Ｓ１，Ｓ２，Ｓ３は、以下の集合に置き換えられる。
Ｓ１’＝Ｓ１×３：｛１，１，１，２，２，２｝
Ｓ２’＝Ｓ２×２：｛３，３，４，４｝
Ｓ３’＝Ｓ３×１：｛５，６｝
集合Ｓ１’は、集合Ｓ１を３倍したものである。すなわち集合Ｓ１と同じ３つの集合を１つに纏めたものが、集合Ｓ１’である。集合Ｓ２’は、集合Ｓ２を２倍したものである。すなわち集合Ｓ２と同じ２つの集合を１つに纏めたものが、集合Ｓ２’である。集合Ｓ３’は、集合Ｓ３と同じである。異常要因推定部１５５は、これらの集合Ｓ１’，Ｓ２’Ｓ３’を１つの集合に纏め、データを昇順ソートする。すなわち異常要因推定部１５５は、周期ごとの各集合について、その集合と同じ集合を重みの数だけ生成し、生成した集合を１つに纏めて、データを昇順にソートする。ソートの結果、以下の集合Ｓが得られる。
Ｓ＝：｛１，１，１，２，２，２，３，３，４，４，５，６｝
異常要因推定部１５５は、この集合Ｓに基づいて得られたパーセンタイル値を、重み付きパーセンタイル値とする。すると、５０パーセンタイル値は「２」となる。また９０パーセンタイル値は「４」となる。

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

図１６は、要因度の計算例を示す図である。図１６の例では、正常時の振る舞いを示す重み付きパーセンタイル値では、５０パーセンタイル値が「１５」、９０パーセンタイル値が「７１」、９９パーセンタイル値が「９０」である。また異常時の振る舞いを示す最新のパーセンタイル値では、５０パーセンタイル値が「６」、９０パーセンタイル値が「９２」、９９パーセンタイル値が「９８」である。

ここで、正の要因度と負の要因度とを、以下のように定める。
・正の要因度Ｆ₊＝Σ（値が増加するＰパーセンタイルのＰの増分）×（パーセンタイル値の差）
・負の要因度Ｆ_-＝Σ（値が減少するＰパーセンタイルのＰの増分）×（パーセンタイル値の差）
Ｐはパーセンタイル種別を示す数値であり、５０パーセンタイル値の場合Ｐ＝５０である。値が増加するＰパーセンタイルとは、正常時のパーセンタイル値より異常時のパーセンタイル値の方が大きいパーセンタイル種別である。値が減少するＰパーセンタイルとは、異常時のパーセンタイル値より正常時のパーセンタイル値の方が大きいパーセンタイル種別である。

ＰパーセンタイルのＰの増分とは、パーセンタイル種別をＰの値が小さい順に並べたときの、各パーセンタイル種別についての、直前のパーセンタイル種別からのＰの値の増加量である。図１６の例では、５０パーセンタイル、９０パーセンタイル、９９パーセンタイルがある。その場合、５０パーセンタイルについてのＰの増分は、「５０」である。９０パーセンタイルについてのＰの増分は、「４０」（９０−５０）である。９９パーセンタイルについてのＰの増分は、「９」（９９−９０）である。

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

図１６に示した例では、要因度は以下の通りとなる。
・正の要因度Ｆ₊＝（９０−５０）×（９２−７１）＋（９９−９０）×（９８−９０）＝９１２
・負の要因度Ｆ_-＝５０×（１５−６）＝４５０
異常要因推定部１５５は、このような要因度の計算を、メトリック種別ごとに行う。そして異常要因推定部１５５は、最大の要因度の算出元のコンテナが実行しているコンポーネントを、要因度最大コンポーネントとして特定する。

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

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

ここで、コンテナ要因度符号が正であれば、要因度最大コンポーネントが、サービスのレイテンシ悪化要因であると推定できる。すなわち、コンポーネントの処理を実行するコンテナの処理負荷が過大となると、通常時よりも、各パーセンタイル値が上昇する。その結果、コンテナ要因度符号は正となる。

それに対して、コンテナ要因度符号が負の場合、要因度最大コンポーネント以外のコンポーネントが、サービスのレイテンシ悪化要因であると考えられる。そこで、異常要因推定部１５５は、コンテナ要因度符号が負の場合、ネットワーク受信のメトリック値が通常時よりも増加しているにも関わらず、ネットワーク送信のメトリック値が通常時よりも減少しているコンポーネントを、要因コンポーネントと推定する。

コンテナ要因度符号が負の場合の要因コンポーネントを推定する際には、異常要因推定部１５５は、コンテナの場合と同様に、コンポーネントについての要因度を計算する。例えば異常要因推定部１５５は、コンポーネントの要因度として、正の要因度と負の要因度とを求める。

異常要因推定部１５５は、コンポーネントの処理を実行する各コンテナのメトリック値に基づいて、図１６と同様に、メトリック種別ごとに重み付きパーセンタイル値を求める。すなわち異常要因推定部１５５は、コンテナの要因度は、そのコンテナのメトリック値に基づいて計算するのに対して、コンポーネントの要因度は、コンポーネントの処理を実行する各コンテナのメトリック値に基づいて計算する。

図１８は、コンテナ要因度符号が負の場合の要因コンポーネント推定例を示す図である。図１８の例では、サービスが、「コンポーネントＡ」、「コンポーネントＢ」、および「コンポーネントＣ」の連係動作によって提供されている。「コンポーネントＡ」のコンテナが「コンポーネントＢ」のコンテナを呼び出し、「コンポーネントＢ」のコンテナが「コンポーネントＣ」のコンテナを呼び出す。ただし、管理サーバ１００からは、コンポーネント間の呼び出し関係は不明である。

ここで、サービスへのリクエストが急激に増加し、例えば「コンポーネントＡ」のコンテナのＣＰＵ使用率が、通常は平均で「８０％」であるところ、平均「９０％」に上昇したものとする。ＣＰＵ使用率が過大になると、処理効率が低下し、単位時間当たりに処理できるリクエスト数が減少する場合がある。この場合、「コンポーネントＡ」のコンテナから「コンポーネントＢ」のコンテナへのリクエストが減少する。その結果、「コンポーネントＢ」および「コンポーネントＣ」のコンテナのＣＰＵ使用率は低下する。

例えば「コンポーネントＣ」のコンテナのＣＰＵ使用率が、通常は平均で「５０％」のところ、平均「１０％」に低下したものとする。なお、「コンポーネントＢ」のコンテナは、通常時から性能に余裕をもって、低負荷で処理を実行しており、リクエスト数が減少しても要因度の変化が少ないものとする。このような場合、「コンポーネントＡ」のコンテナのＣＰＵ使用率の上昇度合いよりも、「コンポーネントＣ」のコンテナのＣＰＵ使用率の下降度合いの方が著しいため、要因度の変化も「コンポーネントＣ」の方が大きくなる。その結果、「コンポーネントＣ」が要因度最大コンポーネントとなる。この例では、レスポンスの悪化要因は、「コンポーネントＡ」のリソース不足（コンテナ不足）にあり、「コンポーネントＣ」は、要因度最大コンポーネントではあるものの、レスポンスの悪化要因ではない。

そこで異常要因推定部１５５は、コンテナ要因度符号が負の場合には、要因度最大コンポーネント以外のコンポーネントの中から、要因コンポーネントを探索する。すなわち異常要因推定部１５５は、コンポーネントへのリクエストが増加し、リクエストを処理しきれなくなってしまっているコンポーネントを探索する。

例えば、異常要因推定部１５５は、各コンポーネントについて、メトリック種別ごとの正の要因度と負の要因度とを計算する。異常要因推定部１５５は、負の要因度よりも正の要因度の方が値が大きいメトリックについての要因度符号を「正」とする。また異常要因推定部１５５は、正の要因度よりも負の要因度の方が値が大きいメトリックについての要因度符号を「負」とする。そして異常要因推定部１５５は、要因度最大コンポーネント以外のコンポーネントの中から、ネットワーク受信レートの要因度符号が「正」、ネットワーク受信レートの要因度符号が「負」、かつネットワーク以外のメトリックの要因度符号が「正」のコンポーネントを探索する。

すなわち以下の要因コンポーネント判定条件を満たすコンポーネントが探索される。
・Ｆ_-［ＮｅｔＴｘ］かつＦ₊［ＮｅｔＲｘ］かつ∃ｒ．Ｆ_-［ｒ］
Ｆ_-［ＮｅｔＴｘ］は、コンポーネントのネットワーク送信レートの要因度符号が「負」であることを示している。Ｆ₊［ＮｅｔＲｘ］は、コンポーネントのネットワーク受信レートの要因度符号が「正」であることを示している。∃ｒ．Ｆ_-［ｒ］は、コンポーネントのネットワーク受信レート、ネットワーク送信レート以外のコンポーネントのメトリックのなかに、要因度符号が「正」のメトリックが少なくとも１つ存在することを示している。

異常要因推定部１５５は、上記の要因コンポーネント判定条件を満たすメトリックを、要因メトリックと推定する。図１８の例では、「コンポーネントＡ」が要因コンポーネント判定条件を満たしており、「コンポーネントＡ」が要因コンポーネントと推定される。

要因コンポーネント判定条件を満たすコンポーネントが見つからない場合、異常要因推定部１５５は、サーバについても、メトリック種別ごとの要因度を計算する。そして異常要因推定部１５５は、サーバのメトリック種別それぞれについて、正の要因度と負の要因度とを比較する。異常要因推定部１５５は、正の要因度が負の要因度以上であれば、そのメトリック種別の要因度符号を「正」とする。異常要因推定部１５５は、正の要因度が負の要因度未満であれば、そのメトリック種別の要因度符号を「負」とする。

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

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

異常要因推定部１５５が、要因コンポーネント、要因メトリック、最大要因符号、およびサーバ要因度符号を決定すると、コンテナ配置制御部１５６が、レイテンシを改善するようにコンテナの追加、またはコンテナの配置先の変更などの性能改善処理を行う。

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

なお、コンポーネントのコンテナが使用するリソース量が規定されている場合がある。この場合、コンテナ配置制御部１５６は、コンポーネントのスケールアウトまたは配置変換のとき、コンテナを収容できるサーバを配置先候補とする。配置先候補となるサーバが複数ある場合、コンテナ配置制御部１５６は、コンテナが各配置先候補に配備されたと仮定したとき、サーバの最小残余リソース量が最大となる配置先候補を、配置先に決定する。

図２０は、コンテナの配置例を示す図である。図２０の例では、要因コンポーネントが「コンポーネント１」であり、コンテナ要因度符号が「正」である。この場合、コンテナ配置制御部１５６は、「コンポーネント１」のスケールアウトを行う。

このときコンテナ配置制御部１５６は、サーバリソース管理テーブル１４２を参照し、各サーバの残余リソース量を確認する。図２０の例では、「サーバ１」の残余リソース量は、ＣＰＵ「５０」、メモリ「３０」、ネットワーク「４０」である。「サーバ２」の残余リソース量は、ＣＰＵ「３０」、メモリ「５０」、ネットワーク「６０」である。

またコンテナ配置制御部１５６は、コンテナリソース管理テーブル１４３を参照し、要因コンポーネントのコンテナ１つ当たりに使用するリソース量を確認する。図２０の例では、要因コンポーネントである「コンポーネント１」のコンテナの使用リソースは、ＣＰＵ「１０」、メモリ「２０」、ネットワーク「１０」である。

ここで「コンポーネント１」のコンテナを配置できるだけの残余リソース量を有しているサーバが、サーバ名「サーバ１」のサーバ４２と、サーバ名「サーバ２」のサーバ４３のみであるものとする。この場合、サーバ４２とサーバ４３とが、配置先候補となる。

サーバ名「サーバ１」のサーバ４２にコンテナを配置した場合の残余リソース量は、ＣＰＵ「４０」、メモリ「１０」、ネットワーク「３０」である。サーバ名「サーバ２」のサーバ４３にコンテナを配置した場合の残余リソース量は、ＣＰＵ「２０」、メモリ「３０」、ネットワーク「５０」である。この場合、サーバ名「サーバ１」のサーバ４２の最小残余リソース量は、メモリの「１０」である。それに対して、サーバ名「サーバ２」のサーバ４３の最小残余リソース量は、ＣＰＵ「２０」である。

コンテナ配置制御部１５６は、最小残余リソース量が最大となる、サーバ名「サーバ２」のサーバ４３を配置先として選択する。そしてコンテナ配置制御部１５６は、サーバ４３に、スケールアウト処理として、「コンポーネント１」を実行するためのコンテナＣ₁₃を配置する。

コンテナ配置制御部１５６は、Ａｐｄｅｘ値が目標値に達するまで、性能調整を継続する。そして、コンテナ配置制御部１５６は、Ａｐｄｅｘ値が目標値に達すると、性能調整を終了する。

図２１は、性能調整結果の一例を示す図である。図２１の例では、Ａｐｄｅｘ値の目標値は０．８以上である。性能調整前はＡｐｄｅｘ値が「０．７５」であったのが、性能調整を行うことで、Ａｐｄｅｘ値が「０．８３」まで向上している。

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

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

［ステップＳ１０２］レイテンシ検査部１５３は、性能調整対象のサービスについてのサービス情報と、そのサービスのレイテンシとを取得する。例えばレイテンシ検査部１５３は、サービス情報記憶部１１０からサービス情報を取得する。取得するサービス情報には、性能要件として指定されているＡｐｄｅｘの値、Ａｐｄｅｘの算出に用いるＳａｔｉｓｆｉｅｄ Ｔｉｍｅ（Ｔ）が含まれる。またレイテンシ検査部１５３は、ゲートウェイ４１のレイテンシ記憶部４１ｂから、直近の所定期間内に計測された、性能調整対象のサービスに対するリクエストのレイテンシを取得する。

［ステップＳ１０３］レイテンシ検査部１５３は、複数のリクエストのレイテンシに基づいて、サービスのＡｐｄｅｘを計算する。
［ステップＳ１０４］レイテンシ検査部１５３は、ステップＳ１０３で計算したＡｐｄｅｘの値が、性能要件を満たしているか否かを判断する。例えばレイテンシ検査部１５３は、算出したＡｐｄｅｘ値が性能要件として指定されたＡｐｄｅｘ値以上であれば、性能要件を満たしていると判断する。レイテンシ検査部１５３は、性能要件を満たしている場合、処理をステップＳ１０５に進める。またレイテンシ検査部１５３は、性能要件を満たしていない場合、処理をステップＳ１０７に進める。

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

［ステップＳ１０６］性能調整エンジン１５０は、繰り返し回数を示す変数Ｒを「０」にリセットする。その後、性能調整エンジン１５０は、処理をステップＳ１０２に進める。

［ステップＳ１０７］性能調整エンジン１５０は、繰り返し回数を示す変数Ｒの値が、閾値Ｘ（Ｘは、１以上の整数）に達したか否かを判断する。性能調整エンジン１５０は、繰り返し回数が閾値Ｘに達した場合、性能調整を断念し、処理を終了する。またコンテナ配置制御部１５６は、繰り返し回数が閾値Ｘに達していなければ、処理をステップＳ１０８に進める。

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

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

［ステップＳ１１０］異常要因推定部１５５は、ステップＳ１０９における計算結果に基づいて、要因コンポーネント推定処理を行う。要因コンポーネント推定処理の詳細は後述する（図２３参照）。

［ステップＳ１１１］異常要因推定部１５５は、要因コンポーネントが推定できたか否かを判断する。異常要因推定部１５５は、要因コンポーネントが推定できた場合、処理をステップＳ１１２に進める。また異常要因推定部１５５は、要因コンポーネントが推定できなかった場合、処理をステップＳ１１３に進める。

［ステップＳ１１２］コンテナ配置制御部１５６は、要因コンポーネントのスケールアウトを実施する。すなわちコンテナ配置制御部１５６は、要因コンポーネントを実行するコンテナを、いずれかのサーバに追加で配置する。例えばコンテナ配置制御部１５６は、コンテナを配置可能なサーバのうち、配置後の空きリソース量が最も多いサーバに、コンテナを配置する。その後、コンテナ配置制御部１５６は、処理をステップＳ１１５に進める。

［ステップＳ１１３］コンテナ配置制御部１５６は、要因度最大コンポーネントのサーバ要因度符号が「正」か否かを判断する。コンテナ配置制御部１５６は、サーバ要因度符号が「正」の場合、処理をステップＳ１１４に進める。またコンテナ配置制御部１５６は、サーバ要因度符号が負の場合、性能調整を断念し、処理を終了する。

［ステップＳ１１４］コンテナ配置制御部１５６は、コンテナの配置変更を行う。すなわちコンテナ配置制御部１５６は、要因度が最大のコンテナの配置先を、現在のサーバから別のサーバに変更する。

［ステップＳ１１５］性能調整エンジン１５０は、繰り返し回数を示す変数Ｒの値を１だけカウントアップし、処理をステップＳ１０２に進める。
次に、要因コンポーネント推定処理について詳細に説明する。

図２３は、要因コンポーネント推定処理の手順の一例を示すフローチャートである。以下、図２３に示す処理をステップ番号に沿って説明する。
［ステップＳ１２１］異常要因推定部１５５は、要因度最大コンポーネントを特定する。例えば異常要因推定部１５５は、値が最大となる正または負の要因度の算出元のコンテナを特定する。そして異常要因推定部１５５は、特定したコンテナによって処理が実行されているコンポーネントを、要因最大コンポーネントとして特定する。

［ステップＳ１２２］異常要因推定部１５５は、コンテナ要因度符号が「正」か否かを判断する。異常要因推定部１５５は、コンテナ要因度符号が「正」であれば、処理をステップＳ１２３に進める。また異常要因推定部１５５は、コンテナ要因度符号が「負」であれば、処理をステップＳ１２４に進める。

［ステップＳ１２３］異常要因推定部１５５は、要因度最大コンポーネントを要因コンポーネントと推定し、要因コンポーネント推定処理を終了する。
［ステップＳ１２４］異常要因推定部１５５は、要因度最大コンポーネント以外のコンポーネントのうち、未選択のコンポーネントを１つ選択する。

［ステップＳ１２５］異常要因推定部１５５は、選択したコンポーネントの受信メトリック（ネットワーク受信レート）の要因度符号が「正」か否かを判断する。例えば異常要因推定部１５５は、選択したコンポーネントの各コンテナのネットワーク受信レートの負の要因度の合計よりも正の要因度の合計の方が大きければ、受信メトリックの要因度が「正」であると判断する。異常要因推定部１５５は、受信メトリックの要因度符号が「正」の場合、処理をステップＳ１２６に進める。また異常要因推定部１５５は、受信メトリックの要因度符号が「正」ではない場合、処理をステップＳ１２９に進める。

［ステップＳ１２６］異常要因推定部１５５は、選択したコンポーネントの送信メトリック（ネットワーク送信レート）の要因度符号が「負」か否かを判断する。例えば異常要因推定部１５５は、選択したコンポーネントの各コンテナのネットワーク送信レートの正の要因度の合計よりも負の要因度の合計の方が大きければ、送信メトリックの要因度符号が「負」であると判断する。異常要因推定部１５５は、送信メトリックの要因度符号が「負」の場合、処理をステップＳ１２７に進める。また異常要因推定部１５５は、送信メトリックの要因度符号が「負」ではない場合、処理をステップＳ１２９に進める。

［ステップＳ１２７］異常要因推定部１５５は、選択したコンポーネントの送信メトリックおよび受信メトリック以外のメトリックの中に、要因度符号が「正」のメトリックが少なくとも１つ存在するか否かを判断する。例えば異常要因推定部１５５は、選択したコンポーネントの各コンテナの正の要因度と負の要因度とを、メトリックの種別ごとに合計する。そして異常要因推定部１５５は、正の要因度の合計値の方が、負の要因度の合計値よりも大きいメトリックについて、そのメトリックの要因度符号が「正」であると判定する。異常要因推定部１５５は、要因度符号が「正」のメトリックが少なくとも１つ存在する場合、処理をステップＳ１２８に進める。また異常要因推定部１５５は、要因度符号が「正」のメトリックが存在しない場合、処理をステップＳ１２９に進める。

［ステップＳ１２８］異常要因推定部１５５は、選択したコンポーネントを要因コンポーネントと推定し、その後、要因コンポーネント推定処理を終了する。
［ステップＳ１２９］異常要因推定部１５５は、未選択のコンポーネントがあるか否かを判断する。異常要因推定部１５５は、未選択のコンポーネントがある場合、処理をステップＳ１２４に進める。また異常要因推定部１５５は、すべてのコンポーネントが選択済みであれば、要因コンポーネントを推定できないと判断して、要因コンポーネント推定処理を終了する。

このようにして、第２の実施の形態では、コンテナの正常時と異常時との振る舞いの差に基づいて、レイテンシ悪化の要因となっているコンポーネントを判断している。これにより、レイテンシ悪化の要因のコンポーネントを適切に判断することができる。例えば、あるコンテナのメトリック値が通常時よりも極端に低下した場合、そのコンテナで処理が実行されるコンポーネントとは別のコンポーネントにおいて、処理が停滞している可能性がある。このような場合であっても、管理サーバ１００は、過負荷により処理を停滞させているコンポーネントを見つけ出すことで、性能低下の真の要因となっているコンポーネントを正しく判断することができる。

しかも第２の実施の形態によれば、コンポーネントごとの性能要件を定めなくても、コンポーネントの性能が不足した場合、コンポーネントの機能が自動で拡張される。その結果、例えばシステムの運用管理コストが削減される。またコンポーネントの性能調整が自動で行われることにより、コンポーネントの開発時にそのコンポーネントの発揮性能を意識せずにすみ、開発コストが削減される。

なお、第２の実施の形態では、メトリックの度数分布からパーセンタイル値を求めることで、メトリックの度数分布で示される状態が、比較容易な数値に置き換えられている。これにより、正常時と異常時との振る舞いの差を数値化でき、複数のコンテナの中から、振る舞いの差が最も大きいコンテナを容易に特定可能となっている。

さらに第２の実施の形態では、重み付きパーセンタイル値を用いることで、正常時の状態に対して、最近の状態を強く反映させている。これにより、正常時の振る舞いを正しく計算することができる。すなわち、クラウドコンピューティングシステムでは、サーバの追加やソフトウェアの追加などのシステム構成の変更が頻繁に行われる。そのため、コンテナやサーバの遠い過去の正常時の振る舞いは、最近の正常時の振る舞いと大きく異なる可能性がある。また、最近の短い期間の振る舞いを正常時の振る舞いとしてしまうと、ある一時期に発生した特殊要因（例えばサーバ故障）などが振る舞いに反映されてしまい、正常時の振る舞いとしての正確性に欠ける。そこで性能調整エンジン１５０は、最近の正常時の振る舞いを強く反映させて、ある程度長い期間の振る舞いに基づいて正常時の振る舞いを計算している。その結果、正常時の振る舞いの正確性が向上する。

なお、性能劣化の要因となっているコンポーネントを推定できない場合もある。この場合、性能調整エンジン１５０は、コンテナの配置変更により、コンテナを何らかの問題を抱えたサーバから別のサーバに移動させ、コンテナが正しく性能を発揮できるようにしている。これにより、無駄なスケールアウトによるリソースの過大消費が抑止される。

〔その他の実施の形態〕
第２の実施の形態では、リソースのメトリック情報の代表値としてパーセンタイル値を用いているが、平均値、中央値などの他の代表値を用いてもよい。

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

１ サービス
２〜４ サーバ
５ 端末装置
１０ 管理装置
１１ 記憶部
１２ 処理部

Claims (5)

1. コンピュータに、
   複数の処理を連係させることで提供されるサービスの性能を示す性能情報を取得し、
   前記性能情報が、前記サービスに求められる性能を示す性能要件を満たしているか否かを判断し、
   前記性能情報が前記性能要件を満たしていない場合、前記複数の処理それぞれについての、直近の所定期間における、データ受信負荷を示す第１負荷直近値、データ送信負荷を示す第２負荷直近値、および受信したデータに応じた処理負荷を示す第３負荷直近値を取得し、
   前記複数の処理それぞれについての、前記サービスの性能が前記性能要件を満たしているときの、データ受信負荷を示す第１負荷正常値、データ送信負荷を示す第２負荷正常値、および受信したデータに応じた処理負荷を示す第３負荷正常値を、メモリから取得し、
   前記第１負荷直近値が前記第１負荷正常値より大きく、前記第２負荷直近値が前記第２負荷正常値より小さく、前記第３負荷直近値が前記第３負荷正常値より大きいという要件に合致する要件合致処理の処理名を、前記サービスの性能悪化要因として出力する、
   処理を実行させる性能評価プログラム。
2. 前記要件合致処理の処理名の出力では、前記複数の処理のうち、直近の処理負荷と正常時の処理負荷との差が最も大きい負荷差最大処理を判断し、前記負荷差最大処理の正常時の処理負荷の方が直近の処理負荷より大きい場合に、前記要件合致処理の処理名を、前記サービスの性能悪化要因となっている要件合致処理として出力する、
   請求項１記載の性能評価プログラム。
3. 前記要件合致処理の処理名の出力では、前記負荷差最大処理の直近の処理負荷の方が正常時の処理負荷より大きい場合、前記負荷差最大処理の処理名を、前記サービスの性能悪化要因として出力する、
   請求項２記載の性能評価プログラム。
4. 前記コンピュータに、さらに、
   前記負荷差最大処理の正常時の処理負荷の方が直近の処理負荷より大きく、前記要件合致処理が存在しない場合、前記負荷差最大処理を実行しているサーバについて、前記サービスの性能が前記性能要件を満たしていないときの負荷が、前記サービスの性能が前記性能要件を満たしているときの負荷よりも大きい場合、前記サーバのサーバ名を、前記サービスの性能悪化要因として出力する、
   請求項２または３記載の性能評価プログラム。
5. コンピュータが、
   複数の処理を連係させることで提供されるサービスの性能を示す性能情報を取得し、
   前記性能情報が、前記サービスに求められる性能を示す性能要件を満たしているか否かを判断し、
   前記性能情報が前記性能要件を満たしていない場合、前記複数の処理それぞれについての、直近の所定期間におけるデータ受信負荷を示す第１負荷直近値、前記所定期間におけるデータ送信負荷を示す第２負荷直近値、および前記所定期間における受信したデータに応じた処理負荷を示す第３負荷直近値を取得し、
   前記複数の処理それぞれについての、前記サービスの性能が前記性能要件を満たしているときの、データ受信負荷を示す第１負荷正常値、データ送信負荷を示す第２負荷正常値、および受信したデータに応じた処理負荷を示す第３負荷正常値を、メモリから取得し、
   前記第１負荷直近値が前記第１負荷正常値より大きく、前記第２負荷直近値が前記第２負荷正常値より小さく、前記第３負荷直近値が前記第３負荷正常値より大きいという要件に合致する要件合致処理の処理名を、前記サービスの性能悪化要因として出力する、
   性能評価方法。

Images