JP7011162B2 - 性能調整プログラム、および性能調整方法 - Google Patents

性能調整プログラム、および性能調整方法 Download PDF

Info

Publication number
JP7011162B2
JP7011162B2 JP2018018214A JP2018018214A JP7011162B2 JP 7011162 B2 JP7011162 B2 JP 7011162B2 JP 2018018214 A JP2018018214 A JP 2018018214A JP 2018018214 A JP2018018214 A JP 2018018214A JP 7011162 B2 JP7011162 B2 JP 7011162B2
Authority
JP
Japan
Prior art keywords
performance
server
unit
container
servers
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
JP2018018214A
Other languages
English (en)
Other versions
JP2019135597A (ja
Inventor
浩一 尾上
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Fujitsu Ltd
Original Assignee
Fujitsu Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Fujitsu Ltd filed Critical Fujitsu Ltd
Priority to JP2018018214A priority Critical patent/JP7011162B2/ja
Priority to US16/223,171 priority patent/US10887199B2/en
Publication of JP2019135597A publication Critical patent/JP2019135597A/ja
Application granted granted Critical
Publication of JP7011162B2 publication Critical patent/JP7011162B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/50—Network service management, e.g. ensuring proper service fulfilment according to agreements
    • H04L41/5003—Managing SLA; Interaction between SLA and QoS
    • H04L41/5019—Ensuring fulfilment of SLA
    • H04L41/5025—Ensuring fulfilment of SLA by proactively reacting to service quality change, e.g. by reconfiguration after service quality degradation or upgrade
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • H04L43/091—Measuring contribution of individual network components to actual service level
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
    • H04L67/1004—Server selection for load balancing
    • H04L67/101—Server selection for load balancing based on network conditions
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
    • H04L67/1004—Server selection for load balancing
    • H04L67/1012—Server selection for load balancing based on compliance of requirements or conditions with available server resources

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Quality & Reliability (AREA)
  • Environmental & Geological Engineering (AREA)
  • Debugging And Monitoring (AREA)

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）を使用することができる。
グラフィック処理装置１０４には、モニタ２１が接続されている。グラフィック処理装置１０４は、プロセッサ１０１からの命令に従って、画像をモニタ２１の画面に表示させる。モニタ２１としては、液晶表示装置や有機ＥＬ（Electro Luminescence）表示装置などがある。
入力インタフェース１０５には、キーボード２２とマウス２３とが接続されている。入力インタフェース１０５は、キーボード２２やマウス２３から送られてくる信号をプロセッサ１０１に送信する。なお、マウス２３は、ポインティングデバイスの一例であり、他のポインティングデバイスを使用することもできる。他のポインティングデバイスとしては、タッチパネル、タブレット、タッチパッド、トラックボールなどがある。
光学ドライブ装置１０６は、レーザ光などを利用して、光ディスク２４に記録されたデータの読み取りを行う。光ディスク２４は、光の反射によって読み取り可能なようにデータが記録された可搬型の記録媒体である。光ディスク２４には、ＤＶＤ（Digital Versatile Disc）、ＤＶＤ－ＲＡＭ、ＣＤ－ＲＯＭ（Compact Disc Read Only Memory）、ＣＤ－Ｒ（Recordable）／ＲＷ（ReWritable）などがある。
機器接続インタフェース１０７は、管理サーバ１００に周辺機器を接続するための通信インタフェースである。例えば機器接続インタフェース１０７には、メモリ装置２５やメモリリーダライタ２６を接続することができる。メモリ装置２５は、機器接続インタフェース１０７との通信機能を搭載した記録媒体である。メモリリーダライタ２６は、メモリカード２７へのデータの書き込み、またはメモリカード２７からのデータの読み出しを行う装置である。メモリカード２７は、カード型の記録媒体である。
ネットワークインタフェース１０８は、ネットワーク２０に接続されている。ネットワークインタフェース１０８は、ネットワーク２０を介して、他のコンピュータまたは通信機器との間でデータの送受信を行う。
以上のようなハードウェア構成によって、第２の実施の形態における管理サーバ１００の処理機能を実現することができる。なお、端末装置３１，３２，・・・、ゲートウェイ４１、およびサーバ４２～４４も、管理サーバ１００と同様のハードウェアによって実現できる。また、第１の実施の形態に示した管理装置１０も、図３に示した管理サーバ１００と同様のハードウェアにより実現することができる。
管理サーバ１００は、例えばコンピュータ読み取り可能な記録媒体に記録されたプログラムを実行することにより、第２の実施の形態の処理機能を実現する。管理サーバ１００に実行させる処理内容を記述したプログラムは、様々な記録媒体に記録しておくことができる。例えば、管理サーバ１００に実行させるプログラムをストレージ装置１０３に格納しておくことができる。プロセッサ１０１は、ストレージ装置１０３内のプログラムの少なくとも一部をメモリ１０２にロードし、プログラムを実行する。また管理サーバ１００に実行させるプログラムを、光ディスク２４、メモリ装置２５、メモリカード２７などの可搬型記録媒体に記録しておくこともできる。可搬型記録媒体に格納されたプログラムは、例えばプロセッサ１０１からの制御により、ストレージ装置１０３にインストールされた後、実行可能となる。またプロセッサ１０１が、可搬型記録媒体から直接プログラムを読み出して実行することもできる。
なお、第２の実施の形態では、マイクロサービスアーキテクチャに基づいて、サービスを提供するソフトウェアがサーバ４２～４４に実装される。
図４は、マイクロサービスアーキテクチャの概念を示す図である。ユーザに提供するサービス５０は、複数のコンポーネント５１～５３を用いて実現される。例えばコンポーネント５１はプレゼンテーション層の処理を実行するソフトウェアであり、コンポーネント５２はロジック層の処理を実行するソフトウェアであり、コンポーネント５３はデータ層の処理を実行するソフトウェアである。
コンポーネント５１～５３は、複数のサーバ４２～４４のいずれか１以上で実行される。コンポーネント５１～５３を実行することでサーバ４２～４４上に構築される処理機能がコンテナである。第２の実施の形態では、コンテナを「Ｃxy」と表している。添字の「ｘ」は、そのコンテナを含むコンポーネントの識別番号（コンポーネント番号）である。添字の「ｙ」は、そのコンテナを含むコンポーネント内でのコンテナの識別番号（コンテナ番号）である。
このように、マイクロサービスアーキテクチャでは、一つのサービス５０を提供するためのソフトウェアが、複数の小さなコンポーネント５１～５３に分割して作成される。各コンポーネント５１～５３は疎に結合している。結合が疎であるとは、コンポーネント５１～５３同士の結びつきが比較的緩やかであり、独立性が強い状態にあることである。コンポーネント５１～５３の結合が疎であることにより、新たなコンポーネントの追加や一部のコンポーネントの拡張による他のコンポーネントの変更が少なくてすむという利点がある。
マイクロサービスアーキテクチャに準じて作成されたサービスのコンポーネント５１～５３は、１以上のコンテナによって実行される。すなわち、コンポーネント５１～５３とコンテナは、１対１または１対多の関係にある。
ユーザに提供するサービス５０に求められる性能要件は、例えばレイテンシを用いて表すことができる。従って、システムの管理者は、サービス５０に求められるレイテンシが得られるような処理能力のコンポーネント５１～５３を用意することになる。コンポーネント５１～５３の処理能力は、コンポーネント５１～５３を実行するコンテナを増やしたり、減らしたりすることで調整することができる。
ここで、サービス５０に求められる性能要件を管理者が規定することは容易である。それに対して、サービス５０に求められるレイテンシを満たすように、各コンポーネントにどの程度のリソースを割り当てればよいのかを、管理者が判断するのは困難である。そこで第２の実施の形態では、管理サーバ１００が、性能が不足しているコンポーネントを検出し、そのコンポーネントを実行するコンテナを追加することで、サービス５０に対する性能要件を満たすようなコンポーネントへのリソースの割り当てを実現する。
図５は、性能調整のためにゲートウェイと管理サーバが有する機能を示すブロック図である。ゲートウェイ４１は、レイテンシ計測部４１ａとレイテンシ記憶部４１ｂとを有する。レイテンシ計測部４１ａは、端末装置３１，３２，・・・から要求を受信してから、その要求に対応する応答を端末装置３１，３２，・・・に送信するまでの時間を計測する。レイテンシ計測部４１ａは、計測した時間を、その要求に応じたサービスについてのレイテンシとして、レイテンシ記憶部４１ｂに格納する。レイテンシ記憶部４１ｂは、レイテンシ計測部４１ａが計測したレイテンシを記憶する。
管理サーバ１００は、サービス情報記憶部１１０、メトリック情報記憶部１２０、正常時振る舞い記憶部１３０、リソース情報記憶部１４０、および性能調整エンジン１５０を有する。サービス情報記憶部１１０は、提供するサービスに関する情報を記憶する。メトリック情報記憶部１２０は、サーバ４２～４４やコンテナによるリソースの稼働状況に関する情報（メトリック）を記憶する。正常時振る舞い記憶部１３０は、複数のコンテナそれぞれと複数のサーバそれぞれとの正常動作時の振る舞いを示す情報を記憶する。リソース情報記憶部１４０は、サーバ４２～４４の使用リソースに関する情報を記憶する。性能調整エンジン１５０は、サービス情報記憶部１１０、メトリック情報記憶部１２０、正常時振る舞い記憶部１３０、およびリソース情報記憶部１４０に記憶された情報を用いて、コンポーネント単位での性能調整を行う。
なお、以下の説明において、コンポーネントの処理を実行するコンテナをサーバに実装することを、コンテナの配置と呼ぶ。コンテナの配置は、具体的には、コンポーネントを実行するためのプログラムをサーバにインストールし、そのプログラムに基づいてコンポーネントの処理を実行するプロセスを起動する処理である。また、コンテナがサーバに実装されているとき、そのコンテナがそのサーバに配置されていると呼ぶ。
図５の例では、各サーバ４２～４４には、異なるコンポーネントの複数のコンテナが配置されている。例えばサーバ４２には、コンテナＣ11，Ｃ22，Ｃ31が配置されている。
以下、図６～図１０を参照して、サービス情報記憶部１１０、メトリック情報記憶部１２０、正常時振る舞い記憶部１３０、およびリソース情報記憶部１４０が記憶する情報について、詳細に説明する。
図６は、レイテンシ記憶部が記憶する情報の一例を示す図である。レイテンシ記憶部４１ｂは、例えばレイテンシ管理テーブル４１ｃを記憶している。レイテンシ管理テーブル４１ｃは、タイムスタンプ、リクエストＩＤ、サービス名、およびレイテンシの欄を有している。
タイムスタンプの欄には、レイテンシを計測した日時が設定される。リクエストＩＤの欄には、レイテンシを計測した要求の識別情報（リクエストＩＤ）が設定される。サービス名の欄には、レイテンシを計測した要求に対応するサービスの名称（サービス名）が設定される。レイテンシの欄には、計測したレイテンシが設定される。
図７は、サービス情報記憶部が記憶する情報の一例を示す図である。サービス情報記憶部１１０は、例えばサービス管理テーブル１１１を記憶している。サービス管理テーブル１１１は、サービス名、Ａｐｄｅｘ（Application performance index）、Ｓａｔｉｓｆｉｅｄ Ｔｉｍｅ、およびコンポーネント名の欄が設けられている。サービス名の欄には、提供しているサービスの名称（サービス名）が設定される。Ａｐｄｅｘの欄には、対応するサービスに求められる性能要件が、Ａｐｄｅｘによって設定される。Ａｐｄｅｘは、レイテンシについてのユーザの満足度を示す指標である。Ｓａｔｉｓｆｉｅｄ Ｔｉｍｅの欄には、対応するサービスを利用するユーザが満足すると思われる最大のレイテンシの値（Ｔ）が設定される。コンポーネント名の欄には、サービスの提供に用いられるコンポーネントの名称が設定される。
ここで、Ａｐｄｅｘについて詳細に説明する。Ａｐｄｅｘは、「Ｔｈｅ Ａｌｌｉａｎｃｅ」によって標準化された指標であり、以下の式によって計算される。
・Ａｐｄｅｘ＝（（ｓａｔｉｓｆｉｅｄ ｃｏｕｎｔｓ）＋（ｔｏｌｅｒａｔｉｎｇ ｃｏｕｎｔｓ）／２）／（ｔｏｔａｌ ｃｏｕｎｔｓ）
「ｓａｔｉｓｆｉｅｄ ｃｏｕｎｔｓ」は、レイテンシがＴ以下のリクエスト回数である。すなわち「ｓａｔｉｓｆｉｅｄ ｃｏｕｎｔｓ」は、ユーザが満足できるレイテンシが得られたリクエストの回数である。
「ｔｏｌｅｒａｔｉｎｇ ｃｏｕｎｔｓ」は、レイテンシがＴ以上、かつ４×Ｔ以下のリクエスト回数である。すなわち「ｔｏｌｅｒａｔｉｎｇ ｃｏｕｎｔｓ」は、ユーザが満足できるレイテンシではないものの、許容できるレイテンシが得られたリクエストの回数である。
なお、レイテンシが４×Ｔより大きなリクエスト回数は、「ｆｒｕｓｔｒａｔｅｄ」と呼ばれる。この「ｆｒｕｓｔｒａｔｅｄ」は、ユーザが不満に感じるレイテンシとなったリクエストの回数である。
第２の実施の形態では、サービスのレイテンシに基づいて計算したＡｐｄｅｘの値が、性能要件として設定されたＡｐｄｅｘ値以上であれば、性能要件を満たしていると判断される。逆にサービスのレイテンシに基づいて計算したＡｐｄｅｘの値が、性能要件として設定されたＡｐｄｅｘ値未満であれば、性能要件を満たしていないと判断される。
図８は、メトリック情報記憶部が記憶する情報の一例を示す図である。メトリック情報記憶部１２０は、例えばメトリック管理テーブル１２１を記憶している。メトリック管理テーブル１２１は、タイムスタンプ、サーバ／コンテナ名、メトリック種別、および値の欄を有している。タイムスタンプの欄には、メトリックの値を計測した日時が設定される。サーバ／コンテナ名の欄には、メトリックの値を計測したサーバまたはコンテナの名称が設定される。メトリック種別の欄には、計測したメトリックの種別（メトリック種別）が設定される。値の欄には、計測したメトリックの値が設定される。
図９は、正常時振る舞い記憶部が記憶する情報の一例を示す図である。正常時振る舞い記憶部１３０は、例えば振る舞い測定周期ごとの複数のコンテナ振る舞い管理テーブル１３１ａ，１３１ｂ，・・・と、振る舞い測定周期ごとの複数のサーバ振る舞い管理テーブル１３２ａ，１３２ｂ，・・・とを記憶している。
複数のコンテナ振る舞い管理テーブル１３１ａ，１３１ｂ，・・・は、それぞれコンテナの振る舞いの測定周期に対応付けて設けられている。複数のコンテナ振る舞い管理テーブル１３１ａ，１３１ｂ，・・・は、コンテナ、メトリック種別、パーセンタイル種別、パーセンタイル値、および重み付きパーセンタイル値の欄を有している。コンテナの欄には、振る舞いの測定対象であるコンテナの名称（コンテナ名）が設定される。メトリック種別の欄には、振る舞いを測定したメトリックの種別が設定される。パーセンタイル種別の欄には、メトリックの値について求めるパーセンタイルの種別が設定される。例えば５０パーセンタイル、９０パーセンタイル、９９パーセンタイルなどが、パーセンタイルの種別として設定される。パーセンタイル値の欄には、対応するメトリックについてのパーセンタイルの種別で示されるパーセンタイルの値が設定される。重み付きパーセンタイル値の欄には、過去数周期分のメトリック値に基づく、コンテナのメトリックごとの重み付きパーセンタイル値が設定される。重み付きパーセンタイル値の詳細は、後述する（図１５参照）。
複数のサーバ振る舞い管理テーブル１３２ａ，１３２ｂ，・・・は、それぞれサーバの振る舞いの測定周期に対応付けて設けられている。複数のサーバ振る舞い管理テーブル１３２ａ，１３２ｂ，・・・は、サーバ、メトリック種別、パーセンタイル種別、パーセンタイル値、および重み付きパーセンタイル値の欄を有している。サーバの欄には、振る舞いの測定対象であるサーバの名称（サーバ名）が設定される。メトリック種別の欄には、振る舞いを測定したメトリックの種別が設定される。パーセンタイル種別の欄には、メトリックの値について求めるパーセンタイルの種別が設定される。例えば５０パーセンタイル、９０パーセンタイル、９９パーセンタイルなどが、パーセンタイルの種別として設定される。パーセンタイル値の欄には、対応するサーバについてのパーセンタイルの種別で示されるパーセンタイルの値が設定される。重み付きパーセンタイル値の欄には、過去数周期分のメトリック値に基づく、サーバのメトリックごとの重み付きパーセンタイル値が設定される。
なお、パーセンタイルは、統計の代表値の一種である。複数のデータを大きさの順に並べたとき、値ｘ（ｘは実数）より小さなデータの割合がｐ％以下（ｐは０以上１００以下の実数）、それより大きなデータの割合が「１００－ｐ」％となる値ｘが、ｐパーセンタイルである。ｐパーセンタイルは、第ｐ百分位数とも呼ばれる。
図１０は、リソース情報記憶部が記憶する情報の一例を示す図である。リソース情報記憶部１４０は、例えばコンテナ配置管理テーブル１４１、サーバリソース管理テーブル１４２、およびコンテナリソース管理テーブル１４３を記憶している。
コンテナ配置管理テーブル１４１は、サーバ４２～４４へのコンテナの配置状況を管理するデータテーブルである。コンテナ配置管理テーブル１４１は、サーバ名とコンテナ名との欄を有している。サーバ名の欄には、コンテナが実装されているサーバの名称（サーバ名）が設定される。コンテナ名の欄には、対応するサーバに実装されているコンテナの名称（コンテナ名）が設定される。
サーバリソース管理テーブル１４２は、サーバ４２～４４のリソースの量を管理するデータテーブルである。サーバリソース管理テーブル１４２は、サーバ名とリソース量との欄を有している。サーバ名の欄には、サービスの提供に使用しているサーバの名称（サーバ名）が設定される。リソース量の欄には、対応するサーバが有するリソース量が、リソースの種別ごとに設定される。図１０の例では、ＣＰＵ、メモリ、ネットワークのリソース量が設定されている。
コンテナリソース管理テーブル１４３は、各コンポーネントのコンテナが使用するリソースの量を管理するデータテーブルである。コンテナリソース管理テーブル１４３は、コンポーネントとコンテナ使用リソース量との欄を有している。コンポーネントの欄には、サービスの提供に使用されるコンポーネントの名称（コンポーネント名）が設定される。コンテナ使用リソース量の欄には、対応するコンポーネントのコンテナが使用するリソースの量が、リソースの種別ごとに設定される。図１０の例では、ＣＰＵ、メモリ、ネットワークについてのコンテナの使用リソース量が設定されている。
次に、性能調整エンジン１５０について詳細に説明する。
図１１は、性能調整エンジンの機能を示すブロック図である。性能調整エンジン１５０は、サービス管理部１５１、メトリック情報収集部１５２、レイテンシ検査部１５３、振る舞い計算部１５４、異常要因推定部１５５、配置先サーバ決定部１５６、およびコンテナ配置制御部１５７を有する。
サービス管理部１５１は、サービスの構成や性能要件を管理する。メトリック情報収集部１５２は、サーバ４２～４４からメトリックの値を定期的に収集し、メトリック情報記憶部１２０に格納する。レイテンシ検査部１５３は、サービスのレイテンシが性能要件を満たしているか検査する。振る舞い計算部１５４は、コンテナとサーバとの正常時および異常時の振る舞いを計算する。振る舞い計算部１５４は、正常時の振る舞いを、正常時振る舞い記憶部１３０に格納する。異常要因推定部１５５は、レイテンシが性能要件を満たしていないサービスの異常要因となっているコンポーネント（要因コンポーネント）を推定する。配置先サーバ決定部１５６は、要因コンポーネントに追加するコンテナ数と、追加するコンテナの配置先とするサーバを決定する。コンテナ配置制御部１５７は、要因コンポーネントのスケールアウト、または要因コンポーネントを実行するコンテナの配置変更を行う。
なお、図１１に示した各要素間を接続する線は通信経路の一部を示すものであり、図示した通信経路以外の通信経路も設定可能である。また、図１１に示した各要素の機能は、例えば、その要素に対応するプログラムモジュールをコンピュータに実行させることで実現することができる。
次に、性能調整エンジン１５０における、各サービスが性能要件を満たしているか否かの判定処理について説明する。
図１２は、性能要件の判定処理の一例を示す図である。サービス管理部１５１は、管理者の入力に従って、サービス５０の性能要件として、Ａｐｄｅｘ値をサービス情報記憶部１１０に登録する。例えばサービス管理部１５１は、管理者からのＡｐｄｅｘ値とＳａｔｉｓｆｉｅｄ Ｔｉｍｅ（Ｔ）との入力を受け付ける。そしてサービス管理部１５１は、入力されたＡｐｄｅｘ値とＳａｔｉｓｆｉｅｄ Ｔｉｍｅ（Ｔ）とを、サービス管理テーブル１１１に、サービス５０のサービス名に対応付けて格納する。
レイテンシ検査部１５３は、ゲートウェイ４１から定期的に、直近の所定期間内のサービス５０へのリクエストに関するレイテンシを収集する。サービスのレイテンシは、端末装置３１から発行されたリクエストのゲートウェイ４１での受信時刻と、端末装置３１へのゲートウェイ４１からの応答の送信時刻との差である。レイテンシ検査部１５３は、取得したレイテンシに基づいて、所定期間におけるＡｐｄｅｘ値を計算する。そしてレイテンシ検査部１５３は、計算したＡｐｄｅｘ値が、性能要件として指定されたＡｐｄｅｘ値以上であれば、性能要件を満たしていると判断する。またレイテンシ検査部１５３は、計算したＡｐｄｅｘ値が、性能要件として指定されたＡｐｄｅｘ値未満であれば、性能要件を満たしていないと判断する。
次にメトリック情報収集部１５２によって、コンテナとサーバとのメトリック情報が収集され、メトリック情報記憶部１２０に格納される。収集されるメトリック情報には、例えばＣＰＵの使用率、メモリのＩ／Ｏレートやページフォルト数、ディスク（ファイルシステム）のＩ／Ｏレート、ネットワークの送受信レートなどが含まれる。収集されたメトリック情報に基づいて、振る舞い計算部１５４によって、直近の所定期間におけるコンテナとサーバとの振る舞いが計算される。
図１３は、コンテナの振る舞いの計算例を示す図である。図１３の例では、コンテナＣ11の振る舞いを計算するものとする。振る舞い計算部１５４は、メトリック情報記憶部１２０から、コンテナ名が「Ｃ11」であるレコードを抽出する。次に振る舞い計算部１５４は、抽出したレコードをメトリック種別で分類する。次に振る舞い計算部１５４は、同じメトリック種別のレコードに設定されている値（メトリック値）が０～１００となるように正規化し、度数分布を生成する。例えば振る舞い計算部１５４は、各メトリック値の理論上の最大値が「１００」となるように正規化する。そして振る舞い計算部１５４は、度数分布に基づいて、メトリック種別ごとに、５０パーセンタイル値、９０パーセンタイル値、および９９パーセンタイル値を計算する。
振る舞い計算部１５４は、サービス５０のコンポーネントを実行するすべてのコンテナの振る舞いを計算する。そして、レイテンシ検査部１５３によってサービス５０の性能要件が満たされていると判断されている場合、振る舞い計算部１５４は、直近の周期のコンテナ振る舞い管理テーブル１３１ａを作成し、そのコンテナ振る舞い管理テーブル１３１ａを正常時振る舞い記憶部１３０に格納する。
図１４は、サーバの振る舞いの計算例を示す図である。図１４の例では、サーバ名「サーバ１」のサーバ４２の振る舞いを計算するものとする。振る舞い計算部１５４は、メトリック情報記憶部１２０から、サーバ名が「サーバ１」であるレコードを抽出する。次に振る舞い計算部１５４は、抽出したレコードをメトリック種別で分類する。次に振る舞い計算部１５４は、同じメトリック種別のレコードに設定されている値（メトリック値）が０～１００となるように正規化し、度数分布を生成する。そして振る舞い計算部１５４は、度数分布に基づいて、メトリック種別ごとに、５０パーセンタイル値、９０パーセンタイル値、および９９パーセンタイル値を計算する。
振る舞い計算部１５４は、すべてのサーバ４２～４４の振る舞いを計算する。そして、レイテンシ検査部１５３によってサービス５０の性能要件が満たされていると判断されている場合、振る舞い計算部１５４は、直近の周期のサーバ振る舞い管理テーブル１３２ａを作成し、そのサーバ振る舞い管理テーブル１３２ａを正常時振る舞い記憶部１３０に格納する。
レイテンシ検査部１５３によってサービス５０の性能要件が満たされていないと判断された場合、振る舞い計算部１５４は、計算したコンテナとサーバとのパーセンタイル値を、異常時の振る舞いを示す情報として、異常要因推定部１５５に送信する。すると異常要因推定部１５５は、異常時の振る舞いと正常時の振る舞いとを比較して、サービスのレイテンシ低下の要因となっているコンポーネントを推定する。
例えば異常要因推定部１５５は、正常時振る舞い記憶部１３０から、新しい方からｎ周期分（ｎは１以上の整数）のコンテナのメトリックごとのパーセンタイル値を取得する。そして異常要因推定部１５５は、取得したパーセンタイル値に基づいて、各メトリックの正常時の振る舞いを決定する。このとき異常要因推定部１５５は、現在に近い周期の振る舞いほど今後の振る舞いに近いとみなすようにするため、パーセンタイル値の取得元の周期の古さに応じて、パーセンタイル値に重み付けを行う。
図１５は、パーセンタイル値への重み付けの例を示す図である。図１５に示した例では、周期ｔ～ｔ＋２周期の３周期分の正常時のパーセンタイル値を取得したものとする。このとき異常要因推定部１５５は、最新の周期ｔ＋２のパーセンタイル値の重みを「３」とする。また異常要因推定部１５５は、１つ前の周期ｔ＋１のパーセンタイル値の重みを「２」とする。さらに異常要因推定部１５５は、２つ前の周期ｔのパーセンタイル値の重みを「１」とする。
このように異常要因推定部１５５は、現在に近い周期のパーセンタイル値ほど重みを大きくして、ｎ周期分の期間のパーセンタイル値（重み付きパーセンタイル値）をメトリックごとに算出する。例えば、以下のようにして、重み付きパーセンタイル値を算出する。
正常時のパーセンタイル値として、以下のデータが得られたものとする。Ｓ１は最新の周期のデータの集合である。Ｓ２は、Ｓ１の１つ前の周期のデータ集合である。Ｓ３は、Ｓ２の１つ前の周期のデータ集合である。
Ｓ１：｛１，２｝
Ｓ２：｛３，４｝
Ｓ３：｛５，６｝
この例では、重み付けの処理を分かりやすくするため、データの値を単純化している。Ｓ１，Ｓ２，Ｓ３に対する重み付きパーセンタイル値を求めるとき、重みの分だけ、各正常データの数を増やす。例えば、集合Ｓ１，Ｓ２，Ｓ３それぞれに対する重みを、「３」、「２」、「１」とする。この場合、集合Ｓ１，Ｓ２，Ｓ３は、以下の集合に置き換えられる。
Ｓ１’＝Ｓ１×３：｛１，１，１，２，２，２｝
Ｓ２’＝Ｓ２×２：｛３，３，４，４｝
Ｓ３’＝Ｓ３×１：｛５，６｝
集合Ｓ１’は、集合Ｓ１を３倍したものである。すなわち集合Ｓ１と同じ３つの集合を１つに纏めたものが、集合Ｓ１’である。集合Ｓ２’は、集合Ｓ２を２倍したものである。すなわち集合Ｓ２と同じ２つの集合を１つに纏めたものが、集合Ｓ２’である。集合Ｓ３’は、集合Ｓ３と同じである。異常要因推定部１５５は、これらの集合Ｓ１’，Ｓ２’Ｓ３’を１つの集合に纏め、データを昇順ソートする。すなわち異常要因推定部１５５は、周期ごとの各集合について、その集合と同じ集合を重みの数だけ生成し、生成した集合を１つに纏めて、データを昇順にソートする。ソートの結果、以下の集合Ｓが得られる。
Ｓ＝：｛１，１，１，２，２，２，３，３，４，４，５，６｝
異常要因推定部１５５は、この集合Ｓに基づいて得られたパーセンタイル値を、重み付きパーセンタイル値とする。すると、５０パーセンタイル値は「２」となる。また９０パーセンタイル値は「４」となる。
異常要因推定部１５５は、正常時の重み付きパーセンタイル値と、異常時の振る舞いを示す最新のパーセンタイル値とを、メトリック種別ごとに比較し、そのメトリック種別に関する要因度を求める。異常要因推定部１５５は、例えば要因度として、正の要因度と負の要因度とを求める。
図１６は、要因度の計算例を示す図である。図１６の例では、正常時の振る舞いを示す重み付きパーセンタイル値では、５０パーセンタイル値が「１５」、９０パーセンタイル値が「７１」、９９パーセンタイル値が「９０」である。また異常時の振る舞いを示す最新のパーセンタイル値では、５０パーセンタイル値が「６」、９０パーセンタイル値が「９２」、９９パーセンタイル値が「９８」である。
ここで、正の要因度と負の要因度とを、以下のように定める。
・正の要因度Ｆ+＝Σ（値が増加するＰパーセンタイルのＰの増分）×（パーセンタイル値の差）
・負の要因度Ｆ-＝Σ（値が減少するＰパーセンタイルのＰの増分）×（パーセンタイル値の差）
Ｐはパーセンタイル種別を示す数値であり、５０パーセンタイルの場合Ｐ＝５０である。値が増加するＰパーセンタイルとは、正常時のパーセンタイル値より異常時のパーセンタイル値の方が大きいパーセンタイル種別である。値が減少するＰパーセンタイルとは、異常時のパーセンタイル値より正常時のパーセンタイル値の方が大きいパーセンタイル種別である。
ＰパーセンタイルのＰの増分とは、パーセンタイル種別をＰの値が小さい順に並べたときの、各パーセンタイル種別についての、直前のパーセンタイル種別からのＰの値の増加量である。図１６の例では、５０パーセンタイル、９０パーセンタイル、９９パーセンタイルがある。その場合、５０パーセンタイルについてのＰの増分は、「５０」である。９０パーセンタイルについてのＰの増分は、「４０」（９０－５０）である。９９パーセンタイルについてのＰの増分は、「９」（９９－９０）である。
サービスのレイテンシが性能要件を満たしていないとき、コンテナやサーバの負荷が平常時より増加していれば、メトリック値が高い値に集中し、正の要因度が高くなる。またサービスのレイテンシが性能要件を満たしていないとき、コンテナやサーバの負荷が平常時より低下していれば、メトリック値が低い値に集中し、負の要因度が高くなる。サービスのレイテンシが性能要件を満たしているのに、コンテナまたはサーバの正の要因度よりも負の要因度の方が高い場合、そのコンテナまたはサーバとは別の要因で性能が劣化していると判断できる。
図１６に示した例では、要因度は以下の通りとなる。
・正の要因度Ｆ+＝（９０－５０）×（９２－７１）＋（９９－９０）×（９８－９０）＝９１２
・負の要因度Ｆ-＝５０×（１５－６）＝４５０
異常要因推定部１５５は、このような要因度の計算を、メトリック種別ごとに行う。そして異常要因推定部１５５は、最大の要因度の算出元のコンテナが実行しているコンポーネントを、異常の要因である要因コンポーネントとして推定する。
図１７は、要因コンポーネントの推定例を示す図である。図１７に示すように、すべてのコンテナについて、メトリック種別ごとに、正の要因度と負の要因度とが算出される。異常要因推定部１５５は、算出された要因度の中から、最大の要因度を抽出する。図１７の例では、コンテナＣ11のＣＰＵ使用率についての正の要因度の値が最大となっている。異常要因推定部１５５は、抽出した要因度の算出元となっているコンテナＣ11で実行しているコンポーネント（コンポーネント名「コンポーネント１」）を、要因コンポーネントとして推定する。このとき異常要因推定部１５５は、最大の要因度に対応するメトリック種別「ＣＰＵ使用率」を、要因メトリックとする。また異常要因推定部１５５は、最大の要因度が正の要因度なのか負の要因度なのかを示すコンテナ要因度符号を、正とする。
さらに異常要因推定部１５５は、コンテナ配置管理テーブル１４１から、最大の要因度の算出元となったコンテナが実装されているサーバのサーバ名を取得する。そして異常要因推定部１５５は、取得したサーバ名を、コンテナ稼働サーバのサーバ名とする。図１７の例では、コンテナ稼働サーバは「サーバ１」である。
また異常要因推定部１５５は、サーバについても、メトリック種別ごとの要因度を計算する。そして異常要因推定部１５５は、サーバのメトリック種別それぞれについて、正の要因度と負の要因度とを比較する。異常要因推定部１５５は、正の要因度が負の要因度以上であれば、そのメトリック種別の要因度符号を「正」とする。異常要因推定部１５５は、正の要因度が負の要因度未満であれば、そのメトリック種別の要因度符号を「負」とする。
そして、異常要因推定部１５５は、コンテナ稼働サーバの要因メトリックの要因度符号を、サーバ要因度符号とする。
図１８は、サーバ要因度符号の判定例を示す図である。図１８の例では、コンテナ稼働サーバ「サーバ１」の要因メトリック「ＣＰＵ使用率」の要因度符号は「正」であるため、サーバ要因度符号は「正」となる。
なおサーバの要因度についても、コンテナと同じ手順で計算することができるが、サーバについては、各メトリック種別の要因度符号が判明すればよい。そこで例えば、正の要因度と負の要因度とを分けずに、メトリック種別の要因度を以下の式で計算してもよい。
・要因度Ｆ＝Σ（ＰパーセンタイルのＰの増分）×（パーセンタイル値の差）
このときのパーセンタイル値の差は、正常値のパーセンタイル値から異常時のパーセンタイル値を減算した値である。このようにして計算した要因度Ｆが０以上の値であれば、要因度符号は「正」である。要因度Ｆが負の値であれば、要因度符号は「負」である。
異常要因推定部１５５が決定したコンテナ要因度符号が正の場合、配置先サーバ決定部１５６は、要因コンポーネントのリソースが不足していると判断し、要因コンポーネントに増加させるコンテナ数を決定する。さらに配置先サーバ決定部１５６は、増加させるコンテナを配置するサーバを決定する。
図１９は、増加させるコンテナ数の決定処理の一例を示す図である。配置先サーバ決定部１５６は、要因コンポーネントのリソースが不足している場合、計測したレイテンシに基づく統計値と現在のコンテナ数をもとに、コンテナの増加数を決定する。
例えば配置先サーバ決定部１５６は、異常要因推定部１５５から異常要因の推定結果を取得する。推定結果に示されるコンテナ要因度符号が「正」である場合、配置先サーバ決定部１５６は、要因コンポーネントに対して増加させるコンテナ数を決定する。その場合、配置先サーバ決定部１５６は、レイテンシ検査部１５３から要因コンポーネントを含むサービス（性能要件を満たしていないサービス）のレイテンシに基づく統計値を取得する。レイテンシに基づく統計値は、具体的には、「ｓａｔｉｓｆｉｅｄ ｃｏｕｎｔｓ」、「ｔｏｌｅｒａｔｉｎｇ ｃｏｕｎｔｓ」、および「ｔｏｔａｌ ｃｏｕｎｔｓ」である。これらの統計値は、レイテンシ検査部１５３によるＡｐｄｅｘ値の算出に用いられた値である。
また配置先サーバ決定部１５６は、コンテナ配置管理テーブル１４１を参照し、要因コンポーネントのコンテナ数を計数する。配置先サーバ決定部１５６は、計数したコンテナ数を、＃currentとする。
配置先サーバ決定部１５６は、取得した統計値と＃currentとに基づいて、Ａｐｄｅｘの目標値を満たすための最小のコンテナ増加数を計算する。例えば配置先サーバ決定部１５６は、１コンテナ当たりの「ｓａｔｉｓｆｉｅｄ ｃｏｕｎｔｓ」（ＳＣper1C）と、１コンテナ当たりの「ｔｏｌｅｒａｔｉｎｇ ｃｏｕｎｔｓ」（ＴＣper1C）とを算出する。「ＳＣper1C」と「ＴＣper1C」とは、１つのコンテナによるＡｐｄｅｘへの寄与度に相当する。
ＳＣper1CとＴＣper1Cとの計算式は以下の通りである。
・ＳＣper1C＝（計測されたｓａｔｉｓｆｉｅｄ ｃｏｕｎｔｓ）／＃current
・ＴＣper1C＝（計測されたｔｏｌｅｒａｔｉｎｇ ｃｏｕｎｔｓ）／＃current
配置先サーバ決定部１５６は、以下の式を満たす最小の＃incrementを計算する。
・（Ａｐｄｅｘの目標値）≦（（ＳＣper1C×（＃current＋＃increment））＋（ＴＣper1C×（＃current＋＃increment））／２）／（ｔｏｔａｌ ｃｏｕｎｔｓ）
算出された＃incrementが、増加させるコンテナ数である。増加させるコンテナ数が決定すると、配置先サーバ決定部１５６は、増加させるコンテナの配置先サーバを決定する。このとき配置先サーバ決定部１５６は、コンテナの追加配置によるサーバのリソース容量を考慮して、配置先のサーバの余剰リソースができるだけ多くなるように増加数分のコンテナそれぞれの配置先を決定する。
コンテナを配置した後のサーバの余剰リソースを正確に計算するために、配置先サーバ決定部１５６は、まず、１コンテナ当たりのメトリック値の増加量を計算する。
図２０は、１コンテナ当たりのメトリックの増加量の計算例を示す図である。図２０の例では、要因コンポーネントのコンテナが、３台のサーバそれぞれに１台ずつ配置されている。各コンテナのメトリック値の平均が、そのメトリックについての、現在の１コンテナ当たりのメトリック値（cDataset）となる。図２０の例では、現在の１コンテナ当たりのメトリック値は「０．４」である。
ここで、要因コンポーネントのコンテナを１台だけ増加させる場合を考える。コンテナ数が増加しても、１コンテナ当たりのメトリック値の合計は変わらず、コンテナ３台での分散処理からコンテナ４台での分散処理になる。そのため、増加後の１コンテナ当たりのメトリック値（Δ）は、増加前よりも小さくなる。具体的には、「現在の１コンテナ当たりのメトリック値×増加前のコンテナ数／増加後のコンテナ数」で、コンテナ増加後の１コンテナ当たりのメトリック値（Δ）を計算できる。図２０の例では、コンテナ増加後の１コンテナ当たりのメトリック値（Δ）は「０．３」（０．４×３／４）である。
図２０の例は、コンテナを１台だけ増加させる場合であるが、増加させるコンテナ数が２台以上の場合もある。その場合、コンテナ増加後の１コンテナ当たりのメトリック値（Δ）はさらに小さくなる。
配置先サーバ決定部１５６は、コンテナの配置先を決定する場合、コンテナ増加後の１コンテナ当たりのメトリック値（Δ）に基づいて、増加後の配置先のサーバにおける余剰リソースを判断する。余剰リソースの量は、サーバの特定のリソースについての最大のメトリック値（正規化後は「１」）から、そのサーバに配置された各コンテナのメトリック値の合計を減算することで判断できる。メトリック値が、最大１に正規化されていれば、配置先サーバ決定部１５６は、複数のサーバそれぞれについての、そのサーバに配置されたコンテナのメトリック値の合計を比較することで、余剰リソースが最大となるサーバを特定できる。
図２１は、サーバに配置されたコンテナのメトリック値の合計と余剰リソースとの関係を示す図である。図２１の例では、「サーバ１」に、コンポーネント番号「１」のコンポーネントのコンテナＣ11と、コンポーネント番号「２」のコンポーネントのコンテナＣ21とが配置されている。ここで、コンポーネント番号「１」のコンポーネントが要因コンポーネントの場合に、「サーバ１」に要因コンポーネントのコンテナを追加していく場合を想定する。
現状では、「サーバ１」のリソースは、コンテナＣ11とコンテナＣ21とが使用している。リソースの現状の使用量を示すメトリック値は、コンテナＣ11のメトリック値とコンテナＣ21のメトリック値との合計である。リソースの現状の使用量を示すメトリック値を、「SrvData.ServerDataInfo［サーバ１］」とする。また、コンテナＣ11のメトリック値を「cDataset」とする。「サーバ１」の最大のメトリック値から、「SrvData.ServerDataInfo［サーバ１］」を減算した値が、現状の「サーバ１」の余剰リソースである。コンテナＣ21のリソース使用量は、「SrvData.ServerDataInfo［サーバ１］－cDataset」で表される。
ここで配置先サーバ決定部１５６が、「サーバ１」に、要因コンポーネントのコンテナを１台追加した場合の余剰リソースを計算するものとする。この場合、要因コンポーネントとは異なるコンポーネントのコンテナＣ21のリソース使用量は変わらない。それに対して、要因コンポーネントのコンテナＣ11のリソースの使用量は、コンテナ増加後の１コンテナ当たりのメトリック値（Δ）で表される。ここで「サーバ１」に配置されている要因コンポーネントのコンテナ数（図２１の例では「１」）を「CntData.Counts［サーバ１］」とする。このとき、既に配置されている要因コンポーネントのコンテナによるリソースのコンテナ追加後の総使用量は、「Δ×CntData.Counts［サーバ１］」で計算できる。配置先サーバ決定部１５６は、コンテナＣ21のリソース使用量に、「Δ×CntData.Counts［サーバ１］」と追加予定のコンテナが使用する分のリソース量を示す「Δ」とを加算する。加算結果が、「サーバ１」にコンテナを１台追加した場合のリソースの使用量を示すメトリック値「tmpDataset」となる。
配置先サーバ決定部１５６は、このような「tmpDataset」の計算を「サーバ１」以外のサーバに関しても行い、「tmpDataset」が最小となるサーバを、コンテナの配置先に決定する。ここで、配置先サーバ決定部１５６が、「サーバ１」に要因コンポーネントのコンテナを１台追加することを決定したものとする。「サーバ１」に追加することが決定したコンテナの数を「Destinations［サーバ１］」とすると、追加することが決定したコンテナが使用するリソース量は、「Δ×Destinations［サーバ１］」となる。
「サーバ１」にコンテナをさらに１台追加する場合（合計２台の追加）の余剰リソースは、「Δ×Destinations［サーバ１］」を考慮にいれて計算することになる。例えば配置先サーバ決定部１５６は、コンテナＣ21のリソース使用量に、「Δ×CntData.Counts［サーバ１］」と「Δ×Destinations［サーバ１］」、さらに追加する予定のコンテナが使用する分のリソース量を示す「Δ」とを加算する。加算結果が、「サーバ１」にコンテナを２台追加した場合のリソースの使用量を示すメトリック値「tmpDataset」となる。
このように、コンテナの配置先に決定されたサーバは、「tmpDataset」の値が増加する。そのため、最初の１台のコンテナの配置先を決定する際には「tmpDataset」が最小となったサーバであっても、２台目のコンテナの配置先を決定する際には「tmpDataset」が最小とはならない可能性がある。
図２２は、コンテナの配置先の決定例を示す図である。図２２の例では、コンポーネント番号「１」のコンポーネントのコンテナを３台増加させる場合に、「サーバ１」と「サーバ２」との中から、配置先サーバを決定する例である。
現状は、「サーバ１」の方が余剰リソースが多い（「tmpDataset」が小さい）。そのため、配置先サーバ決定部１５６は、１台目のコンテナの配置先を、「サーバ１」に決定する。「サーバ１」に１台のコンテナの配置が決定したことで「サーバ１」の余剰リソースが減り、「サーバ１」よりも「サーバ２」の方が余剰リソースが多くなっている。そこで配置先サーバ決定部１５６は、２台目のコンテナの配置先を、「サーバ２」に決定する。「サーバ２」に２台のコンテナの配置が決定したことで「サーバ２」の余剰リソースが減り、「サーバ２」よりも「サーバ１」の方が余剰リソースが多くなっている。そこで配置先サーバ決定部１５６は、３台目のコンテナの配置先を、「サーバ３」に決定する。
このように、配置先サーバ決定部１５６は、コンテナ要因度符号が正の場合、要因コンポーネントのリソースが不足していると判断し、増加させるコンテナ数と、コンテナの配置先とを決定する。そしてコンテナ配置制御部１５７は、決定されたコンテナの配置先に基づいて、要因コンポーネントのスケールアウトを行う。またコンテナ配置制御部１５７は、要因コンポーネントの要因度が負の場合であり、かつサーバ要因度符号が「正」の場合、要因コンポーネント以外のコンポーネントによるリソースの負荷が大きい影響で、要因コンポーネントの性能が低下していると判断する。この場合、コンテナ配置制御部１５７は、コンテナの配置変換を行う。コンテナの配置変換は、コンテナを稼働させるサーバを、別のサーバに変更する処理である。
要因コンポーネントのリソースが不足している場合、増加させるコンテナ数として決定された数のコンテナを要因コンポーネントに追加するスケールアウトを実施することによって、サービスのＡｐｄｅｘ値が目標値より大きくなる。
図２３は、性能調整結果の一例を示す図である。図２３の例では、Ａｐｄｅｘ値の目標値は０．８以上である。性能調整前はＡｐｄｅｘ値が「０．７５」であったのが、性能調整を行うことで、Ａｐｄｅｘ値が「０．８３」まで向上している。
なお、コンテナを一度に大量に追加するようなスケールアウト処理を実施すると、システム全体の処理負荷が一時的に過大となる可能性がある。そこで配置先サーバ決定部１５６は、一度にスケールアウトできるコンテナ数の上限値を設け、算出した増加コンテナ数が上限値を超える場合には、上限値を、増加コンテナ数とする。そして配置先サーバ決定部１５６とコンテナ配置制御部１５７とは、連係して、上限値分のコンテナをサーバに配置した後、Apdex値が目標値以上となるまで、要因コンポーネントのスケールアウトを繰り返す。
次に性能調整処理の手順について詳細に説明する。
図２４は、性能調整処理の手順の一例を示すフローチャートである。なお図２４に示す処理は、１つのサービスについて性能調整を行う場合の処理である。複数のサービスについて性能調整を行う場合、図２４に示す処理が、複数のサービスそれぞれについて実行される。以下、図２４に示す処理をステップ番号に沿って説明する。
［ステップＳ１０１］性能調整エンジン１５０は、例えば管理者により、サービスの性能調整処理の開始指示の入力が行われると、繰り返し回数を示す変数Ｒの値を「０」に初期化する。
［ステップＳ１０２］レイテンシ検査部１５３は、性能調整対象のサービスについてのサービス情報と、そのサービスのレイテンシとを取得する。例えばレイテンシ検査部１５３は、サービス情報記憶部１１０からサービス情報を取得する。取得するサービス情報には、性能要件として指定されているＡｐｄｅｘの値、Ａｐｄｅｘの算出に用いるＳａｔｉｓｆｉｅｄ Ｔｉｍｅ（Ｔ）が含まれる。またレイテンシ検査部１５３は、ゲートウェイ４１のレイテンシ記憶部４１ｂから、直近の所定期間内に計測された、性能調整対象のサービスに対するリクエストのレイテンシを取得する。
［ステップＳ１０３］レイテンシ検査部１５３は、複数のリクエストのレイテンシに基づいて、サービスのＡｐｄｅｘを計算する。
［ステップＳ１０４］レイテンシ検査部１５３は、ステップＳ１０３で計算したＡｐｄｅｘの値が、性能要件を満たしているか否かを判断する。例えばレイテンシ検査部１５３は、算出したＡｐｄｅｘ値が性能要件として指定されたＡｐｄｅｘ値以上であれば、性能要件を満たしていると判断する。レイテンシ検査部１５３は、性能要件を満たしている場合、処理をステップＳ１０５に進める。またレイテンシ検査部１５３は、性能要件を満たしていない場合、処理をステップＳ１０７に進める。
［ステップＳ１０５］振る舞い計算部１５４は、コンテナとサーバとの正常時の振る舞いを計算して、正常時振る舞い記憶部１３０に保存する。例えば振る舞い計算部１５４は、メトリック情報記憶部１２０から、コンテナとサーバとの直近の所定期間分のメトリックの値を取得し、複数のパーセンタイル種別についてのパーセンタイル値を計算する。そして振る舞い計算部１５４は、コンテナのパーセンタイル値を設定したコンテナ振る舞い管理テーブルを、そのコンテナの正常時の振る舞いを示す情報として、正常時振る舞い記憶部１３０に格納する。また振る舞い計算部１５４は、サーバのパーセンタイル値を設定したサーバ振る舞い管理テーブルを、そのサーバの正常時の振る舞いを示す情報として、正常時振る舞い記憶部１３０に格納する。
［ステップＳ１０６］性能調整エンジン１５０は、繰り返し回数を示す変数Ｒを「０」にリセットする。その後、性能調整エンジン１５０は、処理をステップＳ１０２に進める。
［ステップＳ１０７］振る舞い計算部１５４は、コンテナとサーバとの異常時の振る舞いを計算する。例えば振る舞い計算部１５４は、メトリック情報記憶部１２０から、コンテナとサーバとの直近の所定期間分のメトリックの値を取得し、複数のパーセンタイル種別についてのパーセンタイル値を計算する。複数のコンテナそれぞれについて算出したパーセンタイル値が、対応するコンテナの異常時の振る舞いを示す情報である。また複数のサーバそれぞれについて算出したパーセンタイル値が、対応するサーバの異常時の振る舞いを示す情報である。
［ステップＳ１０８］異常要因推定部１５５は、性能調整対象のサービスの提供に使用されるコンポーネントを実行するコンテナの正常時と異常時との振る舞いの差を、メトリック種別ごとに計算する。例えば異常要因推定部１５５は、正常時振る舞い記憶部１３０から重み付きパーセンタイル値を取得する。次に異常要因推定部１５５は、正常時の振る舞いを示す重み付きパーセンタイル値と、ステップＳ１０７で計算した異常時の振る舞いを示すパーセンタイル値とを比較して、メトリック種別ごとに正の要因度と負の要因度を計算する。
［ステップＳ１０９］異常要因推定部１５５は、ステップＳ１０８における計算結果に基づいて、要因コンポーネントを推定する。例えば異常要因推定部１５５は、メトリック種別ごとの正の要因度と負の要因度との中から、最も大きな値の要因度を抽出する。そして異常要因推定部１５５は、抽出した要因度を算出元となったコンテナで実行されているコンポーネントを、要因コンポーネントとして推定する。
［ステップＳ１１０］性能調整エンジン１５０は、繰り返し回数を示す変数Ｒの値が、閾値Ｘ（Ｘは、１以上の整数）に達したか否かを判断する。性能調整エンジン１５０は、繰り返し回数が閾値Ｘに達した場合、性能調整を断念し、処理を終了する。またコンテナ配置制御部１５７は、繰り返し回数が閾値Ｘに達していなければ、処理をステップＳ１１１に進める。
［ステップＳ１１１］コンテナ配置制御部１５７は、ステップＳ１０９において抽出した要因度の符号（コンテナ要因度符号）が正か否かを判断する。コンテナ配置制御部１５７は、正の要因度であれば、処理をステップＳ１１２に進める。またコンテナ配置制御部１５７は、負の要因度であれば、処理をステップＳ１１３に進める。
［ステップＳ１１２］配置先サーバ決定部１５６とコンテナ配置制御部１５７は、連係して、要因コンポーネントのスケールアウト処理を実施する。すなわち配置先サーバ決定部１５６が、要因コンポーネントに増加させるコンテナ数と、増加させるコンテナの配置先のサーバとを決定する。そしてコンテナ配置制御部１５７は、要因コンポーネントを実行するコンテナを、決定されたサーバに追加で配置する。スケールアウト処理の詳細は後述する（図２５参照）。その後、コンテナ配置制御部１５７は、処理をステップＳ１１５に進める。
［ステップＳ１１３］コンテナ配置制御部１５７は、サーバ要因度符号が正か否かを判断する。コンテナ配置制御部１５７は、サーバ要因度符号が正の場合、処理をステップＳ１１４に進める。またコンテナ配置制御部１５７は、サーバ要因度符号が負の場合、性能調整を断念し、処理を終了する。
［ステップＳ１１４］コンテナ配置制御部１５７は、コンテナの配置変更を行う。すなわちコンテナ配置制御部１５７は、ステップＳ１０９で抽出した要因度の計算元となったコンテナの配置先を、現在のサーバから別のサーバに変更する。
［ステップＳ１１５］性能調整エンジン１５０は、繰り返し回数を示す変数Ｒの値を１だけカウントアップし、処理をステップＳ１０２に進める。
このようにして、スケールアウトまたは配置変更により、サービスが性能要件を満たすように、コンポーネントの処理能力が調整される。
次に、スケールアウト処理について詳細に説明する。
図２５は、スケールアウト処理の手順の一例を示すフローチャートである。以下、図２５に示す処理をステップ番号に沿って説明する。
［ステップＳ１２１］配置先サーバ決定部１５６は、増加コンテナ数決定処理を行う。増加コンテナ数決定処理により、要因コンポーネントに追加するコンテナ数が決定される。増加コンテナ数決定処理の詳細は後述する（図２６参照）。
［ステップＳ１２２］配置先サーバ決定部１５６は、配置先サーバ決定処理を行う。配置先サーバ決定処理により、増加コンテナ数分の各コンテナについて、そのコンテナの配置先のサーバが決定される。配置サーバ決定処理の詳細は後述する（図２７参照）。
［ステップＳ１２３］配置先サーバ決定部１５６は、増加コンテナ数分の配置先サーバが決定できたか否かを判断する。配置先サーバ決定部１５６は、増加コンテナ数分の配置先サーバが決定できた場合、処理をステップＳ１２４に進める。また配置先サーバ決定部１５６は、増加コンテナ数分の配置先サーバが決定できなかった場合、コンテナの配置不可を判断して、スケールアウト処理を終了する。
［ステップＳ１２４］コンテナ配置制御部１５７は、決定された配置先のサーバに、要因コンポーネントのコンテナを追加配置する。
このようにして、適切な数のコンテナを一度に配置することができる。
次に、増加コンテナ数決定処理の手順について詳細に説明する。
図２６は、増加コンテナ数決定処理の手順の一例を示すフローチャートである。以下、図２６に示す処理をステップ番号に沿って説明する。
［ステップＳ１３１］配置先サーバ決定部１５６は、性能要件を満たしていないサービスの「ｓａｔｉｓｆｉｅｄ ｃｏｕｎｔｓ」、「ｔｏｌｅｒａｔｉｎｇ ｃｏｕｎｔｓ」、および「ｔｏｔａｌ ｃｏｕｎｔｓ」を、レイテンシ検査部１５３から取得する。また配置先サーバ決定部１５６は、コンテナ配置管理テーブル１４１に基づいて、要因コンポーネントの現在のコンテナ数（＃current）を計数する。
［ステップＳ１３２］配置先サーバ決定部１５６は、１つのコンテナ当たりの「ｓａｔｉｓｆｉｅｄ ｃｏｕｎｔｓ」（ＳＣper1C）と、１つのコンテナ当たりの「ｔｏｌｅｒａｔｉｎｇ ｃｏｕｎｔｓ」（ＴＣper1C）とを計算する。また配置先サーバ決定部１５６は、「＃increment」に初期値「１」を設定する。
［ステップＳ１３３］配置先サーバ決定部１５６は、＃incrementが所定の上限値に達したか否かを判断する。上限値は、システム全体の処理能力に応じて、管理者が予め設定した値である。配置先サーバ決定部１５６は、＃incrementが上限値に達した場合、処理をステップＳ１３７に進める。また配置先サーバ決定部１５６は、＃incrementが上限値に達していなければ、処理をステップＳ１３４に進める。
［ステップＳ１３４］配置先サーバ決定部１５６は、Ａ＝（（ＳＣper1C×（＃current＋＃increment））＋（ＴＣper1C×（＃current＋＃increment））／２）／（ｔｏｔａｌ ｃｏｕｎｔｓ）を計算する。
［ステップＳ１３５］配置先サーバ決定部１５６は、ＡがApdexの目標値以上か否かを判断する。配置先サーバ決定部１５６は、ＡがApdexの目標値以上であれば、処理をステップＳ１３７に進める。また配置先サーバ決定部１５６は、ＡがApdexの目標値未満であれば、処理をステップＳ１３６に進める。
［ステップＳ１３６］配置先サーバ決定部１５６は、「＃increment」の値に「１」を加算して、処理をステップＳ１３３に進める。
［ステップＳ１３７］配置先サーバ決定部１５６は、現在の「＃increment」の値を増加コンテナ数に決定する。
増加コンテナ数を決定すると、次に配置先サーバ決定部１５６は、増加コンテナ数分のコンテナの配置先のサーバを決定する。
図２７は、配置先サーバ決定処理の手順の一例を示すフローチャートである。以下、図２７に示す処理をステップ番号に沿って説明する。
［ステップＳ１４１］配置先サーバ決定部１５６は、配置先のサーバが決定されたコンテナ数を示す「inc」に、初期値「０」を設定する。
［ステップＳ１４２］配置先サーバ決定部１５６は、「inc」の値が、増加コンテナ数を示す「＃increment」の値と等しいか否かを判断する。配置先サーバ決定部１５６は、値が等しければ、処理をステップＳ１４８に進める。また配置先サーバ決定部１５６は、値が等しくなければ、処理をステップＳ１４３に進める。
［ステップＳ１４３］配置先サーバ決定部１５６は、余剰リソース最大サーバ探索処理を行う。余剰リソース最大サーバ探索処理の結果として、余剰リソースが最大となるサーバの識別子を示す「dest」が得られる。なお、コンテナを追加可能なサーバが存在しない場合、「dest」の値は「nil」となる。余剰リソース最大サーバ探索処理の詳細は後述する（図２８参照）。
［ステップＳ１４４］配置先サーバ決定部１５６は、「dest」の値が「nil」か否かを判断する。配置先サーバ決定部１５６は、値が「nil」であれば、処理をステップＳ１４５に進める。また配置先サーバ決定部１５６は、値が「nil」でなければ、処理をステップＳ１４６に進める。
［ステップＳ１４５］配置先サーバ決定部１５６は、増加コンテナ数分のコンテナのサーバへの配置が不可である旨の決定をして、配置先サーバ決定処理を終了する。
［ステップＳ１４６］配置先サーバ決定部１５６は、配置先のサーバの識別子の配列である「Destinations」に、「dest」の値を追加する。
［ステップＳ１４７］配置先サーバ決定部１５６は、「inc」の値に１を加算し、処理をステップＳ１４２に進める。
［ステップＳ１４８］配置先サーバ決定部１５６は、「Destinations」を、配置先サーバのリストとして出力する。
このようにして、増加コンテナ数分のコンテナの配置先のサーバが決定される。次に、余剰リソース最大サーバ探索処理について説明する。
図２８は、余剰リソース最大サーバ探索処理の手順の一例を示すフローチャートである。以下、図２８に示す処理をステップ番号に沿って説明する。
［ステップＳ１５１］配置先サーバ決定部１５６は、メトリック情報記憶部１２０から、コンテナおよびサーバの各メトリックの計測値を取得し、リソース情報記憶部１４０から、要因コンポーネントのコンテナの現在の配置先サーバの情報を取得する。そして、配置先サーバ決定部１５６は、取得した情報に基づいて、メトリックごとの計測データを、以下のような変数または配列に設定する。
・メトリックごとの計測データ：｛メトリック名：（CntData，SrvData）｝
「CntData」は、要因メトリックに関する各コンテナの計測データである。例えば要因メトリックが「ＣＰＵ使用率」であれば、各コンテナのＣＰＵ使用率の計測値である。「CntData」は、（Counts，cDataset）で表される。「Counts」は、スケーリング前の各サーバの要因コンテナ（要因コンポーネントのコンテナ）の数であり、｛サーバ名：＃container｝で表される。「cDataset」は、収集周期で計測された要因コンテナのメトリック値であり、［０．２，０．４，０．１，．．．］というような数値の配列である。「cDataset」内のメトリック値を示す各要素は、計測された要因コンテナの収集周期内での平均値であり、最大が「１」となるように正規化されている。
「SrvData」は、要因メトリックに関するサーバに関するデータである。「SrvData」には、（ServerDataInfo，MaxValue）で表される。「ServerDataInfo」は、サーバのメトリックの計測値であり、｛サーバ名：sDataset｝で表される。「sDataset」は、収集周期で計測されたサーバに関するメトリック値であり、［０．８，０．５，０．２，．．．］というような数値の配列である。「sDataset」内のメトリック値を示す各要素は、計測された要因コンテナの収集周期内での平均値であり、最大が「１」となるように正規化されている。「MaxValue」は、コンテナ追加後に許容される、リソースごとのメトリックの上限値である。メトリックの上限値は、メトリックの値の最大が「１」となるように正規化された値である。例えばコンテナを追加しても、サーバのＣＰＵ使用率を８０％以下に抑える場合、ＣＰＵ使用率の上限値は「０．８」に設定される。
［ステップＳ１５２］配置先サーバ決定部１５６は、「dest」の値を「nil」に初期化する。また配置先サーバ決定部１５６は、「minDataset」に、要因メトリックの上限値を示す値の複数の要素［SrvData.MaxValue，SrvData.MaxValue，．．．］を設定する。要因メトリックの「SrvData.MaxValue」は、計測データ「SrvData」に示されるサーバで許容される、該当メトリックの上限値「MaxValue」を示している。例えば要因メトリックがＣＰＵ使用率であり、ＣＰＵ使用率の上限値が８０％（正規化後は「０．８」）であれば、ＣＰＵ使用率の「minDataset」は、［０．８，０．８，．．．］となる。「minDataset」に設定される要素数は、「sDataset」および「cDataset」それぞれの要素数と同じである。
［ステップＳ１５３］配置先サーバ決定部１５６は、すべてのサーバについてステップＳ１５４～Ｓ１５７の処理が済んでいるか否かを判断する。配置先サーバ決定部１５６は、すべてのサーバについての処理が済んでいる場合、余剰リソース最大サーバ探索処理を終了する。また配置先サーバ決定部１５６は、未処理のサーバがある場合、処理をステップＳ１５４に進める。
［ステップＳ１５４］配置先サーバ決定部１５６は、未処理のサーバを１つ選択する。
［ステップＳ１５５］配置先サーバ決定部１５６は、選択したサーバに要因コンテナを１台追加配置した場合の、そのサーバのリソースの使用量を示す値「tmpDataset」を、リソースごとに算出する。「tmpDataset」は、以下の式で算出できる。
・tmpDataset＝SrvData.ServerDataInfo［サーバ名］＋Δ×（１＋CntData.Counts［サーバ名］＋Destinations［サーバ名］）－CntData.cDataset×CntData.Counts［サーバ名］
「SrvData.ServerDataInfo［サーバ名］」は、［サーバ名］で示されるサーバのメトリックの計測値を示している。「CntData.Counts［サーバ名］」は、［サーバ名］で示されるサーバ内の要因コンテナの数を示している。「Destinations［サーバ名］」は、［サーバ名］で示されるサーバへ追加配置が決定されたコンテナの数を示している。「CntData.cDataset」は、要因コンポーネントの現状における１コンテナ当たりのメトリック値である。「CntData.Counts［サーバ名］」は、［サーバ名］で示されるサーバに現在配置されている要因コンテナの数である。
なお「SrvData.ServerDataInfo［サーバ名］」などの各項には、複数の要素（例えば収集周期ごとに計測された複数のメトリック値）が含まれている。配置先サーバ決定部１５６は、「tmpDataset」を計算する場合、配列内の同じ順番の要素同士で計算を行う。従って、「tmpDataset」には、選択したサーバのリソースの、メトリック値の収集周期ごとの使用量が示される。
配置先サーバ決定部１５６は、例えば、選択したサーバの「tmpDataset」を、メトリックごとに計算する。
［ステップＳ１５６］配置先サーバ決定部１５６は、「tmpDataset」内の収集周期ごとの要素それぞれについて、「SrvData.MaxValue」に示される該当要素のメトリックの上限値より大きいか否かを判断する。この判断は、複数のリソースそれぞれについて行われる。配置先サーバ決定部１５６は、いずれか少なくとも１つのリソースについて、「tmpDataset」内に「SrvData.MaxValue」に示される上限値より大きい値の要素が少なくとも１つ含まれている場合、ステップＳ１５６の判断において「ＹＥＳ」と判断する。また、配置先サーバ決定部１５６は、すべてのリソースについて、「tmpDataset」内のすべての要素の値が「SrvData.MaxValue」に示される上限値以下の場合、ステップＳ１５６の判断において「ＮＯ」と判断する。
配置先サーバ決定部１５６は、ステップＳ１５６で「ＹＥＳ」と判断した場合、処理をステップＳ１５３に進める。また配置先サーバ決定部１５６は、ステップＳ１５６で「ＮＯ」と判断した場合、処理をステップＳ１５７に進める。
ステップＳ１５６の処理によって、コンテナを追加することにより、いずれかのリソースの使用量が上限値を超える可能性のあるサーバは、コンテナの配置先から除外される。
［ステップＳ１５７］配置先サーバ決定部１５６は、選択したサーバの要因メトリックの「tmpDataset」と「minDataset」とを比較し、「tmpDataset」の方が小さいか否かを判断する。例えば「tmpDataset」内の各要素の値の平均値が、「minDataset」内の各要素の値の平均値より小さければ、「tmpDataset」の方が小さいと判断する。配置先サーバ決定部１５６は、「tmpDataset」の方が小さい場合、処理をステップＳ１５８に進める。また配置先サーバ決定部１５６は、「tmpDataset」が「minDataset」以上の場合、処理をステップＳ１５３に進める。
［ステップＳ１５８］配置先サーバ決定部１５６は、「dest」に、選択したサーバのサーバ名を設定する。また配置先サーバ決定部１５６は、「minDataset」に、選択したサーバの要因メトリックの「tmpDataset」の各要素の値を設定する。その後、配置先サーバ決定部１５６は、処理をステップＳ１５３に進める。
このようにして、余剰リソースが最大となるサーバが探索される。そして余剰リソースが最大となるサーバのサーバ名が、「dest」に設定される。なお、ステップＳ１５６で「ＮＯ」、ステップＳ１５７で「ＹＥＳ」となるサーバが検出できなかった場合、「dest」の値は「nil」のままとなっている。「dest」に設定されたサーバ名は、図２７のステップＳ１４６において「Destinations」に設定される。増加コンテナ数分のサーバが、配置先サーバとして特定できた場合、「Destinations」には、増加コンテナ数分のサーバ名が設定される。なお、１つのサーバに２台以上のコンテナを追加配置する場合、そのサーバのサーバ名が「Destinations」内に複数設定される。
以上説明したように、第２の実施の形態によれば、要因コンポーネントのコンテナのスケールアウトを行う際、サービスの性能要件を満たすための最小限の増加コンテナ数が算出され、その増加コンテナ数分のコンテナが自動で配置される。これにより、１台ずつコンテナのスケールアウトを行い、その都度、性能要件が満たされるかどうかを確認する場合に比べて、スケールアウトの処理が効率的となる。その結果、サービスが性能要件を満たすことができなくなった時点から、早期に性能要件を満たすようにスケールアウトを実施することができ、サービスの性能劣化期間を最小限に抑えることができる。例えば、スケールアウト実施周期が１時間で、性能要件を満たすための増加コンテナ数が３つの場合、１台ずつスケールアウトを行うと、性能要件を満していない期間が最大で３時間となる。それに対して、第２の実施の形態では、性能要件を満していない期間が最大でも１時間ですむ。
しかも管理サーバ１００は、余剰リソースができるだけ多くなるように、コンテナの配置先のサーバを決定している。これにより、複数のサーバの負荷を平均化し、システム全体の処理効率を向上させることができる。
さらに、図２０に示したように、管理サーバ１００は、コンテナを追加すると、既に配置されているコンテナによるサーバの負荷が低下することを考慮にいれて余剰リソースを求めている。これにより、正確な余剰リソースを算出できる。その結果、余剰リソースが最も多くなるサーバを、正しく判断することができる。
〔その他の実施の形態〕
第２の実施の形態では、サービスが性能要件を満たすか否かの判定基準として、Ａｐｄｅｘ値を用いているが、他の指標を判定基準としてもよい。例えば、所定のレイテンシを超えた処理の割合を、判定基準としてもよい。
また第２の実施の形態では、サービスの性能が性能要件を満たしているときと満たしていないときとの動作状態の差が最も大きいメトリックを、要因メトリックとしているが、他の方法で要因メトリックを判定してもよい。さらには、要因メトリックを自動判定せずに、要因メトリックを管理者が判断し、管理サーバに入力するようにしてもよい。
以上、実施の形態を例示したが、実施の形態で示した各部の構成は同様の機能を有する他のものに置換することができる。また、他の任意の構成物や工程が付加されてもよい。さらに、前述した実施の形態のうちの任意の２以上の構成（特徴）を組み合わせたものであってもよい。
１～３ サーバ
４ａ，４ｂ，５ａ，５ｂ，６ａ，６ｂ 単位機能
７ 端末装置
８ サービス
１０ 管理装置
１１ 記憶部
１２ 処理部

Claims (5)

  1. コンピュータに、
    所定の処理性能による調整対象処理の実行機能である１または複数の単位機能それぞれを、１または複数のサーバのいずれかで実現させることで、前記調整対象処理を前記１または複数のサーバに実行させ、
    前記調整対象処理を利用して提供されるサービスの性能を示す性能情報を取得し、
    前記性能情報が、前記サービスに求められる性能を示す性能要件を満たしているか否かを判断し、
    前記性能情報が前記性能要件を満たしていない場合、前記性能情報と現在の前記単位機能の数とに基づいて、前記１または複数のサーバのいずれかで実現させる前記単位機能の増加数を決定し、
    現在の前記単位機能それぞれによるサーバのリソース使用量を示す数値の合計を、現在の前記単位機能の数に前記増加数を加算した加算値によって除算し、除算結果を１単位機能当たりのリソース使用量とし、前記１単位機能当たりのリソース使用量に基づいて、決定された前記増加数分の追加単位機能それぞれを、前記１または複数のサーバのいずれかで実現させた場合の、前記１または複数のサーバのリソースの余剰量を計算し、
    前記追加単位機能それぞれを前記１または複数のサーバのいずれかで実現させた場合に、リソースの前記余剰量が最も多いサーバを、前記追加単位機能を実現させるサーバに決定する、
    処理を実行させる性能調整プログラム。
  2. 前記増加数の決定では、前記性能情報から算出された性能値を現在の前記単位機能の数で除算することで、１単位機能当たりの前記性能値への寄与度を算出し、現在の前記単位機能の数に整数を加算した加算値と前記寄与度との乗算結果が、前記性能要件として示される閾値以上となる、最小の前記整数を、前記増加数に決定する、
    請求項１記載の性能調整プログラム。
  3. 前記コンピュータに、さらに、
    実現させるサーバの決定に従って、前記追加単位機能それぞれを前記１または複数のサーバのいずれかが実現するように、前記１または複数のサーバを制御する、
    請求項１または２に記載の性能調整プログラム。
  4. コンピュータに、
    複数の処理を連係させることで提供されるサービスにおける前記複数の処理の実行機能である１または複数の単位機能それぞれを、１または複数のサーバのいずれかで実現させることで、前記複数の処理を前記１または複数のサーバに実行させ、
    前記サービスの性能を示す性能情報を取得し、
    前記性能情報が、前記サービスに求められる性能を示す性能要件を満たしているか否かを判断し、
    前記性能情報が前記性能要件を満たしていない場合、直近の所定期間における前記複数の処理それぞれの動作状態を示す第１状態情報を取得し、
    前記サービスの性能が前記性能要件を満たしているときの前記複数の処理それぞれの動作状態を示す第２状態情報と、前記第１状態情報とに基づいて、前記性能要件が満たされているときと満たされていないときとの動作状態の差を、前記複数の処理それぞれについて計算し、
    前記複数の処理それぞれの動作状態の差に基づいて、前記サービスの性能悪化要因となっている調整対象処理を判定し、
    前記性能情報と前記調整対象処理の実行機能である対象単位機能の現在の数とに基づいて、前記１または複数のサーバのいずれかで実現させる前記対象単位機能の増加数を決定する、
    処理を実行させる性能調整プログラム。
  5. コンピュータが、
    所定の処理性能による調整対象処理の実行機能である１または複数の単位機能それぞれを、１または複数のサーバのいずれかで実現させることで、前記調整対象処理を前記１または複数のサーバに実行させ、
    前記調整対象処理を利用して提供されるサービスの性能を示す性能情報を取得し、
    前記性能情報が、前記サービスに求められる性能を示す性能要件を満たしているか否かを判断し、
    前記性能情報が前記性能要件を満たしていない場合、前記性能情報と現在の前記単位機能の数とに基づいて、前記１または複数のサーバのいずれかで実現させる前記単位機能の増加数を決定し、
    現在の前記単位機能それぞれによるサーバのリソース使用量を示す数値の合計を、現在の前記単位機能の数に前記増加数を加算した加算値によって除算し、除算結果を１単位機能当たりのリソース使用量とし、前記１単位機能当たりのリソース使用量に基づいて、決定された前記増加数分の追加単位機能それぞれを、前記１または複数のサーバのいずれかで実現させた場合の、前記１または複数のサーバのリソースの余剰量を計算し、
    前記追加単位機能それぞれを前記１または複数のサーバのいずれかで実現させた場合に、リソースの前記余剰量が最も多いサーバを、前記追加単位機能を実現させるサーバに決定する、
    性能調整方法。
JP2018018214A 2018-02-05 2018-02-05 性能調整プログラム、および性能調整方法 Active JP7011162B2 (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
JP2018018214A JP7011162B2 (ja) 2018-02-05 2018-02-05 性能調整プログラム、および性能調整方法
US16/223,171 US10887199B2 (en) 2018-02-05 2018-12-18 Performance adjustment method, apparatus for performance adjustment, and non-transitory computer-readable storage medium for storing program

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2018018214A JP7011162B2 (ja) 2018-02-05 2018-02-05 性能調整プログラム、および性能調整方法

Publications (2)

Publication Number Publication Date
JP2019135597A JP2019135597A (ja) 2019-08-15
JP7011162B2 true JP7011162B2 (ja) 2022-01-26

Family

ID=67475809

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2018018214A Active JP7011162B2 (ja) 2018-02-05 2018-02-05 性能調整プログラム、および性能調整方法

Country Status (2)

Country Link
US (1) US10887199B2 (ja)
JP (1) JP7011162B2 (ja)

Families Citing this family (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20210096259A (ko) * 2018-12-07 2021-08-04 헤이디언 슈퍼컴퓨팅 엘티디 컴퓨팅 리소스 할당
CN113590017B (zh) * 2020-04-30 2023-11-17 伊姆西Ip控股有限责任公司 用于处理数据的方法、电子设备和计算机程序产品
JP7420252B2 (ja) 2020-07-10 2024-01-23 日本電信電話株式会社 スケーリング実行装置、スケーリング実行方法及びプログラム
JP7469655B2 (ja) 2020-07-14 2024-04-17 富士通株式会社 コンテナ配置先決定プログラム、及びコンテナ配置先決定方法
JP2022017686A (ja) * 2020-07-14 2022-01-26 富士通株式会社 コンテナ配備先クラスタ決定方法、コンテナ配備先クラスタ決定装置及びコンテナ配備先クラスタ決定システム
CN114064254A (zh) * 2020-07-31 2022-02-18 华为技术有限公司 一种通信方法及设备
JP2023030899A (ja) * 2021-08-24 2023-03-08 富士通株式会社 管理プログラム、管理装置及び管理方法
WO2023084777A1 (ja) * 2021-11-15 2023-05-19 日本電信電話株式会社 スケーリング管理装置、スケーリング管理方法、および、プログラム

Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2012198843A (ja) 2011-03-23 2012-10-18 Fuji Xerox Co Ltd 仮想サーバ調整システム、仮想サーバ制御装置及びプログラム
JP2012208781A (ja) 2011-03-30 2012-10-25 Internatl Business Mach Corp <Ibm> 情報処理システム、情報処理装置、スケーリング方法、プログラムおよび記録媒体
JP2014191378A (ja) 2013-03-26 2014-10-06 Hitachi Systems Ltd サーバ数調整システムおよび方法ならびにプログラム
JP2015194958A (ja) 2014-03-31 2015-11-05 富士通株式会社 情報処理装置、スケール管理方法およびプログラム
JP2016139237A (ja) 2015-01-27 2016-08-04 株式会社日立製作所 計算機システム及び計算機システムの性能障害の対処方法
JP2017126144A (ja) 2016-01-13 2017-07-20 富士通株式会社 オートスケール方法、オートスケールプログラム、情報処理装置及び情処理システム
WO2018003031A1 (ja) 2016-06-29 2018-01-04 富士通株式会社 仮想化管理プログラム、仮想化管理装置および仮想化管理方法

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP4151985B2 (ja) 2006-07-19 2008-09-17 インターナショナル・ビジネス・マシーンズ・コーポレーション 異常の生じた情報処理装置を検出する技術
US8381208B2 (en) * 2009-06-11 2013-02-19 International Business Machines Corporation Tracking application installation among a plurality of client devices
US8978035B2 (en) 2012-09-06 2015-03-10 Red Hat, Inc. Scaling of application resources in a multi-tenant platform-as-a-service environment in a cloud computing system
US10594562B1 (en) * 2015-08-25 2020-03-17 Vmware, Inc. Intelligent autoscale of services
US10158726B2 (en) 2015-12-02 2018-12-18 International Business Machines Corporation Supporting high availability for orchestrated services
JP2017138895A (ja) 2016-02-05 2017-08-10 株式会社日立製作所 仮想化環境管理システムおよび仮想化環境管理方法
JP2017219972A (ja) 2016-06-06 2017-12-14 富士通株式会社 コンピュータプログラム、情報処理方法、管理ノードおよび情報処理システム
US10382291B2 (en) 2017-04-26 2019-08-13 Oracle International Corporation Provisioning framework for binding related cloud services
US10523507B2 (en) 2017-05-11 2019-12-31 Nirmata, Inc. Method and system for tuning performance of microservices-based applications

Patent Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2012198843A (ja) 2011-03-23 2012-10-18 Fuji Xerox Co Ltd 仮想サーバ調整システム、仮想サーバ制御装置及びプログラム
JP2012208781A (ja) 2011-03-30 2012-10-25 Internatl Business Mach Corp <Ibm> 情報処理システム、情報処理装置、スケーリング方法、プログラムおよび記録媒体
JP2014191378A (ja) 2013-03-26 2014-10-06 Hitachi Systems Ltd サーバ数調整システムおよび方法ならびにプログラム
JP2015194958A (ja) 2014-03-31 2015-11-05 富士通株式会社 情報処理装置、スケール管理方法およびプログラム
JP2016139237A (ja) 2015-01-27 2016-08-04 株式会社日立製作所 計算機システム及び計算機システムの性能障害の対処方法
JP2017126144A (ja) 2016-01-13 2017-07-20 富士通株式会社 オートスケール方法、オートスケールプログラム、情報処理装置及び情処理システム
WO2018003031A1 (ja) 2016-06-29 2018-01-04 富士通株式会社 仮想化管理プログラム、仮想化管理装置および仮想化管理方法

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
山崎謙太、寺村 健、平島陽子、森村知弘，オートスケール時のＳＬＡ保証改善に向けた仮想マシンＣＰＵキャッピング機能の活用に関する検討，電子情報通信学会技術研究報告，日本，一般社団法人電子情報通信学会，2015年03月12日，Ｖｏｌ．１１４，Ｎｏ．５２３，ｐｐ．７－１２（ICM2014-55），ISSN 0913-5685

Also Published As

Publication number Publication date
JP2019135597A (ja) 2019-08-15
US10887199B2 (en) 2021-01-05
US20190245756A1 (en) 2019-08-08

Similar Documents

Publication Publication Date Title
JP7011162B2 (ja) 性能調整プログラム、および性能調整方法
JP7004902B2 (ja) 性能評価プログラム、および性能評価方法
US10896055B2 (en) Capacity risk management for virtual machines
JP5218390B2 (ja) 自律制御サーバ、仮想サーバの制御方法及びプログラム
EP3232338A1 (en) Cloud platform application-oriented service recommendation method, device and system
TWI433035B (zh) 按比例調整指令間隔以識別用於代表性指令追蹤的收集點
US9448906B2 (en) Service quality evaluator having adaptive evaluation criteria
CN103383655A (zh) 用于在qos感知云中管理合并的工作负载的性能干扰模型
US10942763B2 (en) Operation management apparatus, migration destination recommendation method, and storage medium
US11190581B1 (en) Job allocation support system and method
US20160117199A1 (en) Computing system with thermal mechanism and method of operation thereof
US20200081740A1 (en) Resource allocation optimization support system and resource allocation optimization support method
US9501321B1 (en) Weighted service requests throttling
KR20070070062A (ko) 서비스 평가 방법, 시스템 및 컴퓨터 프로그램 제품
CN113168398A (zh) 基于遥测数据的设备的升级确定
US11385700B2 (en) Estimation of power consumption for a job based on adjusted calculation of similarities between jobs
US10089151B2 (en) Apparatus, method, and program medium for parallel-processing parameter determination
US9305068B1 (en) Methods and apparatus for database virtualization
JP2018136681A (ja) 性能管理プログラム、性能管理方法、および管理装置
CN113656046A (zh) 一种应用部署方法和装置
US20210398176A1 (en) Apparatus, method, and storage medium for burstable instance recommendation
US20230136244A1 (en) Virtual machine connection control device, virtual machine connection control system, virtual machine connection control method, and program
CN118195708A (zh) 一种基于云计算的工程造价数据处理方法及装置
KR20220062700A (ko) 여성의 생리학적 특성을 기반으로 하는 필요 영양 성분 시계열 수요 예측 시스템 및 그 방법

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20201110

RD02 Notification of acceptance of power of attorney

Free format text: JAPANESE INTERMEDIATE CODE: A7422

Effective date: 20201126

RD04 Notification of resignation of power of attorney

Free format text: JAPANESE INTERMEDIATE CODE: A7424

Effective date: 20201126

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20210921

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20211005

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20211201

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20211214

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20211227

R150 Certificate of patent or registration of utility model

Ref document number: 7011162

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150