JP2018136681A - 性能管理プログラム、性能管理方法、および管理装置 - Google Patents

Abstract

【課題】性能悪化要因の処理を特定できるようにする。【解決手段】管理装置１０は、複数の処理を連携させることで提供されるサービス１の性能を示す性能情報が、サービス１に求められる性能を示す性能要件を満たしているか否かを判断する。性能情報が性能要件を満たしていない場合、管理装置１０は、直近の所定期間における複数の処理それぞれの動作状態を示す第１状態情報を取得する。さらに管理装置１０は、サービス１の性能が性能要件を満たしているときの複数の処理それぞれの動作状態を示す第２状態情報１１ａと、第１状態情報とに基づいて、性能要件が満たされているときと満たされてないときとの動作状態の差を、複数の処理それぞれについて計算する。そして管理装置１０は、複数の処理それぞれの動作状態の差に基づいて、サービス１の性能悪化要因となっている処理を判定する。【選択図】図１

Description

本発明は、性能管理プログラム、性能管理方法、および管理装置に関する。

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

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

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

リソース利用の効率化に関する技術としては、例えば状況変化に対応して、リソースの利用効率を高めることができるリソース管理システムがある。またコンポーネントの管理に関する技術としては、例えばアプリケーションプログラムのコンポーネントの生産性を損なうことなく当該コンポーネントの監視および監視結果にもとづいた処理を行なう技術がある。

国際公開第２０１５／０４９７８９号 特開２００９−１１６６１８号公報

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

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

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

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

１つの案では、コンピュータに以下の処理を実行させる性能管理プログラムが提供される。
性能管理プログラムに基づいて、コンピュータは、複数の処理を連携させることで提供されるサービスの性能を示す性能情報を取得する。次にコンピュータは、性能情報が、サービスに求められる性能を示す性能要件を満たしているか否かを判断する。次にコンピュータは、性能情報が性能要件を満たしていない場合、直近の所定期間における複数の処理それぞれの動作状態を示す第１状態情報を取得する。次にコンピュータは、サービスの性能が性能要件を満たしているときの複数の処理それぞれの動作状態を示す第２状態情報と、第１状態情報とに基づいて、性能要件が満たされているときと満たされてないときとの動作状態の差を、複数の処理それぞれについて計算する。そしてコンピュータは、複数の処理それぞれの動作状態の差に基づいて、サービスの性能悪化要因となっている処理を判定する。

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

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

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

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

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

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

ここで、サービス１の性能悪化要因となる処理を特定することの困難性について説明する。図１に示すように、複数の処理を連携させることで提供されるサービス１の場合、サービス１の性能が悪化したというだけでは、どのコンポーネントに性能悪化の要因があるのかが分からない。

そこでコンポーネントごとに性能要件を定めることが考えられる。しかしながら、各コンポーネントにどのような性能要件を定めれば、サービスの性能要件を満たすことが可能なのかを、的確に判断するのは困難である。例えばサービスのレイテンシを１００ミリ秒以内にするために，コンポーネントごとのＣＰＵ（Central Processing Unit）使用率、メモリ使用率、ディスクＩ／Ｏレートなどの値がいくつであれば適当なのかを、正確に決定することは困難である。しかも、サービスの利用者が作成したコンポーネントの場合、管理者は、コンポーネントの具体的な処理内容を知ることができない。コンポーネントの処理内容を知らずに、そのコンポーネントの性能要件を定めるのは困難である。

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

記憶部１１は、複数の処理を連携させることで提供されるサービス１の性能が、サービス１に求められる性能を示す性能要件を満たしているときの、複数の処理それぞれの動作状態を示す第２状態情報１１ａを記憶する。第２状態情報１１ａは、例えば、各処理のＣＰＵ使用率、各処理実行時のメモリＩ／Ｏレートなどの複数種の情報である。このような動作状態を示す情報は、メトリックと呼ばれる。なお、記憶部１１は、各種メトリックの統計処理を施した結果の値を、第２状態情報１１ａとして記憶していてもよい。例えば処理ごとのＣＰＵ使用率のパーセンタイル値を、第２状態情報１１ａとすることもできる。

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

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

処理部１２は、性能情報が性能要件を満たしていない場合、サーバ２〜４から、直近の所定期間における複数の処理それぞれの動作状態を示す第１状態情報を取得する。例えば処理部１２は、各処理のＣＰＵ使用率、各処理実行時のメモリＩ／Ｏレートなどのメトリックの値を取得する。

処理部１２は、取得した第１状態情報と第２状態情報１１ａとに基づいて、性能要件が満たされているときと満たされてないときとの動作状態の差を、複数の処理それぞれについて計算する。例えば処理部１２は、取得した第１状態情報に基づいて、直近の所定期間のメトリックの値の代表値（例えばパーセンタイル値）を計算する。そして処理部１２は、第１状態情報から算出した代表値を第２状態情報１１ａから算出した代表値との差を計算する。

そして処理部１２は、複数の処理それぞれの動作状態の差に基づいて、サービス１の性能悪化要因となっている処理を判定する。例えば、処理部１２は、動作状態の差が最も大きな処理を、性能悪化要因の処理と判定する。

処理部１２は、さらに性能悪化要因と判定された要因処理の動作状態の差に基づいて、性能悪化に対する対処方法を決定し、決定した対処方法による対処を実施する。例えば処理部１２は、要因処理のスケールアウトを行う。

このようにして、サービス１の提供に使用する処理のうち、その処理が性能悪化要因となっているのかを、判定することができる。その結果、サービス１の性能悪化に対して、迅速に対処することができる。また、各処理について、メトリックごとの性能要件を設定するといった手間が不要となり、システムの管理負担が軽減される。

なお、処理部１２は、第２状態情報１１ａを、適宜更新することで、第２状態情報１１ａの精度を向上させることもできる。例えば処理部１２は、サービス１の性能情報が性能要件を満たしている場合、直近の所定期間における複数の処理それぞれの動作状態を示す第３状態情報を取得する。そして処理部１２は、取得した第３状態情報に基づいて、第２状態情報１１ａを更新する。例えば処理部１２は、複数の期間の第３状態情報に基づき、現在に近い期間の第３状態情報に示される動作状態ほど、更新後の第２状態情報１１ａに強く反映させる。このように、最新の性能情報によって第２状態情報１１ａを更新すると共に、新しい更新情報の重みを重くして第２状態情報１１ａを更新することで、システムの最近の運用状況を反映させた精度の高い第２状態情報１１ａを生成することができる。

記憶部１１は、第２状態情報１１ａとして、例えばサービス１の性能が性能要件を満たしているときに複数の処理それぞれが使用しているリソースの稼働状況の時系列変化を示す第２リソース情報の所定の代表値である第２代表値を記憶してもよい。この場合、処理部１２は、第１状態情報として、直近の所定期間に複数の処理それぞれが使用しているリソースの稼働状況の時系列変化を示す第１リソース情報を取得し、第１リソース情報の所定の代表値を、第１代表値として算出する。そして処理部１２は、複数の処理それぞれについて、第１代表値と第２代表値との差を計算し、差が最も大きい処理を、性能悪化の要因である要因処理であると判定する。このようにリソースの稼働状況を代表値で表すことで、動作状態の差を容易に数値化することができる。その結果、リソース１の性能悪化の前後で動作状態が大きく変化した処理を、容易に特定することができる。

なお、第１状態情報および第２状態情報１１ａとして、複数種メトリック（ＣＰＵ使用率、メモリＩ／Ｏレートなど）の値を取得している場合、処理部１２は、メトリック種別ごとに代表値の差を計算する。また処理部１２は、１種のメトリックについて複数種の代表値（例えば５０パーセンタイル、９０パーセンタイル、９９パーセンタイルなど）を算出することもできる。この場合、処理部１２は、各処理について、第１状態情報と第２状態情報１１ａとの同種のメトリックの同種の代表値間の差を計算する。そして処理部１２は、各処理のメトリック種別（例えばＣＰＵ使用率）ごとに、代表値間の差（例えば絶対値）を合計し、対応する処理の該当メトリック種別に関する動作状態の差とする。また処理部１２は、性能悪化時に値が増加した代表値の差（第２の実施の形態では「正の要因度」と呼ぶ）と、性能悪化時に値が減少した代表値の差（第２の実施の形態では「負の要因度」と呼ぶ）とを個別に算出してもよい。

処理部１２は、サービス１の性能悪化に対する対処方法としては、例えば要因処理のスケールアウトを行うことができる。また処理部１２は、要因処理を現在実行しているサーバにおける、要因処理以外の処理の影響でサービス１の性能が悪化している場合、要因処理を実行するサーバを変更することもできる。例えば処理部１２は、要因処理の第２状態情報１１ａ（性能悪化時の状態情報）の方が、要因処理の第１状態情報（正常時の状態情報）よりも負荷が大きい動作状態を表している場合、要因処理のスケールアウトを行う。また処理部１２は、要因処理の第１状態情報の方が、要因処理の第２状態情報１１ａよりも負荷が大きい動作状態を表している場合、要因処理を実行するサーバを変更する。これにより、無駄なスケールアウトの実行を抑止することができる。

さらに処理部１２は、要因処理の変更とスケールアウトとを同時の行った後、スケールアウトが余分であることを確認できたとき、スケールインを実施してもよい。例えば処理部１２は、まず、要因処理を現在実行している第１サーバでの要因処理の実行を停止し、第１サーバとは異なる複数の第２サーバそれぞれで要因処理を実行させる。そして処理部１２は、対処実施後の複数の第２サーバが要因処理を実行するための処理負荷が、所定値以下の場合、複数の第２サーバの一部における要因処理の実行を停止させる。これにより、サービス１の性能悪化状態を迅速に解消し、かつ無駄なリソースの消費を抑制することができる。

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

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

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

図３は、本実施の形態に用いる管理サーバのハードウェアの一構成例を示す図である。管理サーバ１００は、プロセッサ１０１によって装置全体が制御されている。プロセッサ１０１には、バス１０９を介してメモリ１０２と複数の周辺機器が接続されている。プロセッサ１０１は、マルチプロセッサであってもよい。プロセッサ１０１は、例えばＣＰＵ、ＭＰＵ（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」と表している。添字の「ｘ」は、そのコンテナを含むコンポーネントの識別番号（コンポーネント番号）である。添字の「ｙ」は、そのコンテナを含むコンポーネント内でのコンテナの識別番号（コンテナ番号）である。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

［ステップＳ１１１］コンテナ配置制御部１５６は、ステップＳ１０９において抽出した要因度の符号（コンテナ要因度符号）が正か否かを判断する。コンテナ配置制御部１５６は、正の要因度であれば、処理をステップＳ１１２に進める。またコンテナ配置制御部１５６は、負の要因度であれば、処理をステップＳ１１３に進める。

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

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

［ステップＳ１１４］コンテナ配置制御部１５６は、コンテナの配置変更を行う。すなわちコンテナ配置制御部１５６は、ステップＳ１０９で抽出した要因度の計算元となったコンテナの配置先を、現在のサーバから別のサーバに変更する。

［ステップＳ１１５］性能調整エンジン１５０は、繰り返し回数を示す変数Ｒの値を１だけカウントアップし、処理をステップＳ１０２に進める。
このようにして、性能要件を満たさないサービスにおいて、どのコンポーネントがボトルネックになっているのかを適切に判断し、そのコンポーネントの処理能力が向上するように性能調整をすることができる。これにより、コンポーネントごとの性能要件を定めなくても、コンポーネントの性能が不足した場合、コンポーネントの機能が自動で拡張される。その結果、例えばシステムの運用管理コストが削減される。またコンポーネントの性能調整が自動で行われることにより、コンポーネントの開発時にそのコンポーネントの発揮性能を意識せずにすみ、開発コストが削減される。

また第２の実施の形態では、コンテナの正常時と異常時との振る舞いの差に基づいて、レイテンシ悪化の要因となっているコンポーネントを判断している。これにより、レイテンシ悪化の要因のコンポーネントを適切に判断することができる。

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

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

また第２の実施の形態では、性能調整エンジン１５０は、性能劣化の要因であるコンテナの要因度の符号（コンテナ要因度符号）が正であれば、そのコンテナに対応するコンポーネントのスケールアウトを行うが、コンテナ要因度符号が負であれば配置変更を行う。コンテナ要因度符号が負の場合、性能劣化の要因であるコンテナは、そのコンテナ自身の問題ではなく、コンテナが実装されたサーバの問題（例えば別のソフトウェアの実行による過負荷）によって、性能が劣化している可能性がある。そこで性能調整エンジン１５０は、コンテナの配置変更により、コンテナを何らかの問題を抱えたサーバから別のサーバに移動させ、コンテナが正しく性能を発揮できるようにしている。これにより、無駄なスケールアウトによるリソースの過大消費が抑止される。

〔第３の実施の形態〕
次に第３の実施の形態について説明する。第３の実施の形態は、スケールアウト後に、スケールインが可能であれば、スケールインを実施するものである。

すなわち、性能要件を満たすようにすることが主目的であるが、できるだけ少ないリソースでこれを実現させることも重要である。単純にスケールアウトすると、リソースの消費量が増加し、本来は不要なリソースが使用される可能性がある。そこで、第３の実施の形態では、不要なリソース使用量の増加を抑制するため、性能調整エンジン１５０は、可能であればスケールアウト後にスケールインを実施する。

具体的には、性能調整エンジン１５０は、要因コンポーネントのコンテナが稼働しているサーバよりも負荷の小さいサーバが２つある場合には、現在稼動中のコンテナを削除して、負荷の小さい２つのサーバでコンテナを稼働させる。このスケールアウト（２増１減のスケールアウト）後のコンポーネントの総負荷（コンテナの負荷の合計）が正常時の総負荷よりも小さい場合、性能調整エンジン１５０は、コンテナが稼働しているサーバの中で最小の負荷であるサーバを選択し、選択したサーバ上のコンテナを削除する。これにより、コンテナ数を増加させることなく性能要件を満たすように性能が調整される。

以下、図２２〜図２４を参照して、第３の実施の形態における性能調整処理の手順について詳細に説明する。
図２２は、第３の実施の形態における性能調整処理の手順の一例を示すフローチャートの前半である。図２２に示す処理のうち、ステップＳ２０１〜Ｓ２０４、ステップＳ２０６〜Ｓ２１０は、それぞれ図２１に示した第２の実施の形態におけるステップＳ１０１〜Ｓ１０９の処理と同じである。異なるステップＳ２０５の処理は、以下の通りである。

［ステップＳ２０５］ステップＳ２０４において性能要件を満たしていると判断した場合、コンテナ配置制御部１５６はスケールイン処理を行う。コンテナ配置制御部１５６は、スケールイン処理が終了すると、処理をステップＳ２０６に進める。

図２３は、スケールイン処理の手順の一例を示すフローチャートである。以下、図２３に示す処理をステップ番号に沿って説明する。
［ステップＳ２２１］コンテナ配置制御部１５６は、２増１減のスケールアウトを実施済みであることを示すフラグ「ＳＣＡＬＥ＿ＦＬＡＧ」の値が「ｔｒｕｅ」か否かを判断する。フラグ「ＳＣＡＬＥ＿ＦＬＡＧ」は初期値が「ｆａｌｓｅ」であり、２増１減のスケールアウトの実施後に「ｔｒｕｅ」に更新される。コンテナ配置制御部１５６は、フラグ「ＳＣＡＬＥ＿ＦＬＡＧ」の値が「ｔｒｕｅ」であれば、処理をステップＳ２２２に進める。またコンテナ配置制御部１５６は、フラグ「ＳＣＡＬＥ＿ＦＬＡＧ」の値が「ｔｒｕｅ」でなければ、スケールイン処理を終了する。

［ステップＳ２２２］コンテナ配置制御部１５６は、２増１減のスケールアウトを実施時の要因コンポーネントの総負荷が、正常時の総負荷以下か否かを判断する。要因コンポーネントの総負荷は、例えばそのコンポーネントを実行しているコンテナの、スケールアウト時に最大の要因度となったメトリック種別の最新のメトリック値の合計である。正常時の総負荷は、例えば要因コンポーネントを実行しているコンテナの、スケールアウト時に最大の要因度となったメトリック種別の、過去の平常動作時のメトリック値の合計である。コンテナ配置制御部１５６は、要因コンポーネントの総負荷が正常時の総負荷以下であれば、処理をステップＳ２２３に進める。またコンテナ配置制御部１５６は、要因コンポーネントの総負荷が正常時の総負荷より大きければ、処理をステップＳ２２４に進める。

［ステップＳ２２３］コンテナ配置制御部１５６は、要因コンポーネントのスケールインを実施する。すなわちコンテナ配置制御部１５６は、要因コンポーネントを実行するコンテナのうちの１つをサーバから削除する。その後、スケールイン処理が終了する。

［ステップＳ２２４］コンテナ配置制御部１５６は、フラグ「ＳＣＡＬＥ＿ＦＬＡＧ」を「ｆａｌｓｅ」に設定する。その後、スケールイン処理が終了する。
このようにして、スケールイン処理が行われる。

図２４は、第３の実施の形態における性能調整処理の手順の一例を示すフローチャートの後半である。以下、図２４に示す処理をステップ番号に沿って説明する。
［ステップＳ２３１］コンテナ配置制御部１５６は、フラグ「ＳＣＡＬＥ＿ＦＬＡＧ」の値が「ｔｒｕｅ」か否かを判断する。コンテナ配置制御部１５６は、フラグ「ＳＣＡＬＥ＿ＦＬＡＧ」の値が「ｔｒｕｅ」であれば、処理をステップＳ２３２に進める。またコンテナ配置制御部１５６は、フラグ「ＳＣＡＬＥ＿ＦＬＡＧ」の値が「ｔｒｕｅ」でなければ、処理をステップＳ２３３に進める。

［ステップＳ２３２］コンテナ配置制御部１５６は、要因コンポーネントを実行するコンテナを１つ増加させるスケールアウトを実施する。その後、コンテナ配置制御部１５６は、処理をステップＳ２４１に進める。

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

［ステップＳ２３４］コンテナ配置制御部１５６は、ステップＳ２１０において抽出した要因度の符号（コンテナ要因度符号）が正か否かを判断する。コンテナ配置制御部１５６は、正の要因度であれば、処理をステップＳ２３７に進める。またコンテナ配置制御部１５６は、負の要因度であれば、処理をステップＳ２３５に進める。

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

［ステップＳ２３６］コンテナ配置制御部１５６は、コンテナの配置変更を行う。すなわちコンテナ配置制御部１５６は、ステップＳ２１０で抽出した要因度の計算元となったコンテナの配置先を、現在のサーバから別のサーバに変更する。

［ステップＳ２３７］コンテナ配置制御部１５６は、サーバ要因度符号が正か否かを判断する。コンテナ配置制御部１５６は、サーバ要因度符号が正の場合、処理をステップＳ２３８に進める。またコンテナ配置制御部１５６は、サーバ要因度符号が負の場合、処理をステップＳ２４０に進める。

［ステップＳ２３８］コンテナ配置制御部１５６は、２増１減のスケールアウト処理を行う。
［ステップＳ２３９］コンテナ配置制御部１５６は、フラグ「ＳＣＡＬＥ＿ＦＬＡＧ」を「ｔｒｕｅ」に設定する。その後、コンテナ配置制御部１５６は、処理をステップＳ２４１に進める。

［ステップＳ２４０］コンテナ配置制御部１５６は、１増のスケールアウト処理を行う。
［ステップＳ２４１］性能調整エンジン１５０は、繰り返し回数を示す変数Ｒの値を１だけカウントアップし、処理をステップＳ２０２（図２２参照）に進める。

このようにして、２増１減のスケールアップをした場合、スケールインが可能であれば、スケールインを行うことができる。その結果、無駄にリソースを消費せずにすみ、リソースの有効利用が図れる。

〔その他の実施の形態〕
第２および第３の実施の形態では、コンテナごとに正の要因度と負の要因度とを計算しているが、例えば正の要因度と負の要因度との合計を、そのコンテナの要因度としてもよい。

また第２および第３の実施の形態では、リソースのメトリック情報の代表値としてパーセンタイル値を用いているが、平均値、中央値などの他の代表値を用いてもよい。
以上、実施の形態を例示したが、実施の形態で示した各部の構成は同様の機能を有する他のものに置換することができる。また、他の任意の構成物や工程が付加されてもよい。さらに、前述した実施の形態のうちの任意の２以上の構成（特徴）を組み合わせたものであってもよい。

１ サービス
２〜４ サーバ
５ 端末装置
１０ 管理装置
１１ 記憶部
１１ａ 第２状態情報
１２ 処理部

Claims (9)

1. コンピュータに、
   複数の処理を連携させることで提供されるサービスの性能を示す性能情報を取得し、
   前記性能情報が、前記サービスに求められる性能を示す性能要件を満たしているか否かを判断し、
   前記性能情報が前記性能要件を満たしていない場合、直近の所定期間における前記複数の処理それぞれの動作状態を示す第１状態情報を取得し、
   前記サービスの性能が前記性能要件を満たしているときの前記複数の処理それぞれの動作状態を示す第２状態情報と、前記第１状態情報とに基づいて、前記性能要件が満たされているときと満たされてないときとの動作状態の差を、前記複数の処理それぞれについて計算し、
   前記複数の処理それぞれの動作状態の差に基づいて、前記サービスの性能悪化要因となっている処理を判定する、
   処理を実行させる性能管理プログラム。
2. 前記コンピュータに、さらに、
   前記性能情報が前記性能要件を満たしている場合、直近の所定期間における前記複数の処理それぞれの動作状態を示す第３状態情報を取得し、前記第３状態情報に基づいて、前記第２状態情報を更新する、
   処理を実行させる請求項１記載の性能管理プログラム。
3. 前記第２状態情報の更新では、複数の期間の前記第３状態情報に基づき、現在に近い期間の前記第３状態情報に示される動作状態ほど、更新後の前記第２状態情報に強く反映させる、
   請求項２記載の性能管理プログラム。
4. 前記第２状態情報は、前記サービスの性能が前記性能要件を満たしているときに前記複数の処理それぞれが使用しているリソースの稼働状況の時系列変化を示す第２リソース情報の所定の代表値である第２代表値であり、
   前記第１状態情報の取得では、直近の前記所定期間に前記複数の処理それぞれが使用している前記リソースの稼働状況の時系列変化を示す第１リソース情報の所定の代表値を、第１代表値として算出し、
   動作状態の差の計算では、前記複数の処理それぞれについて、前記第１代表値と前記第２代表値との差を計算する、
   請求項１ないし３のいずれかに記載の性能管理プログラム。
5. 前記コンピュータに、さらに、
   前記性能悪化要因と判定された要因処理の動作状態の差に基づいて、性能悪化に対する対処方法を決定し、
   決定した前記対処方法による対処を実施する、
   処理を実行させる請求項１ないし４のいずれかに記載の性能管理プログラム。
6. 前記対処方法の決定では、前記要因処理の前記第２状態情報の方が、前記要因処理の前記第１状態情報よりも負荷が大きい動作状態を表している場合、前記対処方法として、前記要因処理のスケールアウトを決定し、前記要因処理の前記第１状態情報の方が、前記要因処理の前記第２状態情報よりも負荷が大きい動作状態を表している場合、前記対処方法として、前記要因処理を実行するサーバを変更することを決定する、
   請求項５記載の性能管理プログラム。
7. 前記対処方法の決定では、前記要因処理を現在実行している第１サーバでの前記要因処理の実行を停止し、前記第１サーバとは異なる複数の第２サーバそれぞれで前記要因処理を実行させることを決定し、
   前記コンピュータに、さらに、
   決定した前記対処方法による対処を実施後の、前記複数の第２サーバが前記要因処理を実行するための処理負荷が、所定値以下の場合、前記複数の第２サーバの一部における前記要因処理の実行を停止させる、
   処理を実行させる請求項５記載の性能管理プログラム。
8. コンピュータが、
   複数の処理を連携させることで提供されるサービスの性能を示す性能情報を取得し、
   前記性能情報が、前記サービスに求められる性能を示す性能要件を満たしているか否かを判断し、
   前記性能情報が前記性能要件を満たしていない場合、直近の所定期間における前記複数の処理それぞれの動作状態を示す第１状態情報を取得し、
   前記サービスの性能が前記性能要件を満たしているときの前記複数の処理それぞれの動作状態を示す第２状態情報と、前記第１状態情報とに基づいて、前記性能要件が満たされているときと満たされてないときとの動作状態の差を、前記複数の処理それぞれについて計算し、
   前記複数の処理それぞれの動作状態の差に基づいて、前記サービスの性能悪化要因となっている処理を判定する、
   性能管理方法。
9. 複数の処理を連携させることで提供されるサービスの性能が、前記サービスに求められる性能を示す性能要件を満たしているときの、前記複数の処理それぞれの動作状態を示す第２状態情報を記憶する記憶部と、
   前記サービスの性能を示す性能情報を取得し、前記性能情報が前記性能要件を満たしているか否かを判断し、前記性能情報が前記性能要件を満たしていない場合、直近の所定期間における前記複数の処理それぞれの動作状態を示す第１状態情報を取得し、前記第１状態情報と前記第２状態情報とに基づいて、前記性能要件が満たされているときと満たされてないときとの動作状態の差を、前記複数の処理それぞれについて計算し、前記複数の処理それぞれの動作状態の差に基づいて、前記サービスの性能悪化要因となっている処理を判定する処理部と、
   を有する管理装置。

Images