特開 2023-101234 クラウドアプリケーションデプロイ装置およびクラウドアプリケーションデプロイ方法

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】公開特許公報(A)

(11)【公開番号】P2023101234

(43)【公開日】2023-07-20

(54)【発明の名称】クラウドアプリケーションデプロイ装置およびクラウドアプリケーションデプロイ方法

(51)【国際特許分類】

   G06F 9/50 20060101AFI20230712BHJP

   G06F 11/34 20060101ALI20230712BHJP

   G06F 8/60 20180101ALI20230712BHJP

【ＦＩ】

G06F9/50 150Z

G06F11/34 147

G06F8/60

【審査請求】未請求

【請求項の数】10

【出願形態】ＯＬ

(21)【出願番号】P 2022001731

(22)【出願日】2022-01-07

(71)【出願人】

【識別番号】000005108

【氏名又は名称】株式会社日立製作所

(74)【代理人】

【識別番号】110001689

【氏名又は名称】青稜弁理士法人

(72)【発明者】

【氏名】佐伯 裕治

【テーマコード（参考）】

5B042

5B376

【Ｆターム（参考）】

5B042GA22

5B042MA08

5B042MA11

5B042MA14

5B042MC22

5B376AA07

5B376AA32

5B376AB01

5B376AB12

(57)【要約】

【課題】クラウドのコンテナ上に新規にアプリケーションをデプロイするときに、クラウドの資源の使用効率を向上させて、最適なアプリケーションのデプロイを行う。
【解決手段】クラウドアプリケーションデプロイ装置のフェーズ分類モデルは、アプリケーションの実行時における時刻期間ごとの資源使用量データから時刻期間ごとの特徴量ベクトルを算出して、時刻期間ごとの特徴量ベクトルをクラスタリングし、クラスタリングの結果を検証して、あるフェーズに属するかを判定する。新規アプリケーションの特徴量ベクトルに対して、既知のフェーズのクラスタに属する特徴量ベクトルとｖａｌｉｄａｔｉｏｎを行い、その度合いによって、各々の時刻期間が既知フェーズに属するか、未知フェーズに属するかを判定し、そのフェーズごとに計算機ノードにおける資源使用量を推論し、それによりアプリケーションデプロイを行う。
【選択図】 図２

【特許請求の範囲】

【請求項1】

アプリケーションソフトウェアの実行時の資源使用量に基づいて、クラウド環境に対するアプリケーションソフトウェアのデプロイを実行するクラウドアプリケーションデプロイ装置であって、
前記クラウド環境の計算機ノードに対する前記アプリケーションソフトウェアの実行時における時刻期間ごとの資源使用量データを保持し、
前記アプリケーションソフトウェアの実行時における時刻期間ごとの資源使用量データから前記時刻期間ごとの特徴量ベクトルを算出し、
前記時刻期間ごとの特徴量ベクトルをクラスタリングしてクラスタを作成し、
前記特徴量ベクトルを含むクラスタの特徴量ベクトルに対応する時刻期間の時系列を前記アプリケーションソフトウェアのフェーズとし、
前記アプリケーションソフトウェアの実行時における時刻期間ごとの資源使用量データから前記時刻期間ごとの特徴量ベクトルを算出して、時刻期間ごとの特徴量ベクトルをクラスタリングしてクラスタを作成し、前記クラスタリングの結果を検証して、あるフェーズに属するかを判定するフェーズ分類モデルを有し、
新規アプリケーションソフトウェアに対して、前記新規アプリケーションソフトウェアの実行時における時刻期間ごとの資源使用量データを収集し、
前記新規アプリケーションソフトウェアの実行の前記時刻期間ごとの特徴量ベクトルに対して、既にフェーズ分類モデルが得られた既知のフェーズのフェーズ分類モデルにより作成されたクラスタに属する特徴量ベクトルとｖａｌｉｄａｔｉｏｎを行い、ｖａｌｉｄａｔｉｏｎの度合いによって、各々の前記時刻期間が既知フェーズに属するか、既知フェーズに属さないかを未知フェーズに属するかを判定し、
前記アプリケーションソフトウェアのフェーズごとに計算機ノードにおける資源使用量を推論し、
前記アプリケーションソフトウェアのフェーズごとに計算機ノードにおける資源使用量に基づいて、前記計算機ノードにおけるクラウド環境のコンテナ資源使用制限を算出し、前記コンテナ資源使用制限により、前記アプリケーションソフトウェアアプリケーションソフトウェアのデプロイを実行するクラウドアプリケーションデプロイ装置。

【請求項2】

前記新規アプリケーションソフトウェアの前記未知フェーズに属するとされた前記時刻期間ごとの特徴量ベクトルは、一つ以上の前記既知フェーズの特徴量ベクトルにそれぞれの重み付け係数をかけた特徴量ベクトルの直積として合成されることを特徴とする請求項１記載のクラウドアプリケーションデプロイ装置。

【請求項3】

前記重み付け係数は、前記資源使用量データから前記時刻期間ごとの特徴量ベクトル作成する際に、高次元の時系列データから低次元の特徴量ベクトルにｅｎｃｏｄｅするニューラルネットワークを用いて、前記資源使用量データにｄｅｃｏｄｅするニューラルネットワークを同時に学習させたときの損失関数から評価されるｄｅｃｏｄｅ精度から求められることを特徴とする請求項２記載のクラウドアプリケーションデプロイ装置。

【請求項4】

前記未知のフェーズに対して、新規アプリケーションソフトウェアの実行により蓄積された資源使用量データにより前記フェーズ分類モデルによる学習を行うことを特徴とする請求項１記載のクラウドアプリケーションデプロイ装置。

【請求項5】

前記アプリケーションソフトウェアのフェーズごとに計算機ノードにおける性能を推論する性能推論式を作成し、前記性能推論式に基づいて、前記計算機ノードにおけるクラウド環境のコンテナ資源使用制限を算出し、前記コンテナ資源使用制限により、前記アプリケーションソフトウェアアプリケーションソフトウェアのデプロイを実行する請求項１記載のクラウドアプリケーションデプロイ装置。

【請求項6】

前記性能推論式は、資源使用量の種別ごとに前記資源使用量につれて前記計算機ノードの性能が低下するスローダウン関数により算出することを特徴とする請求項５記載のクラウドアプリケーションデプロイ装置。

【請求項7】

時刻期間ごとに前記ｖａｌｉｄａｔｉｏｎの度合いを表示することを特徴とする請求項１記載のクラウドアプリケーションデプロイ装置。

【請求項8】

アプリケーションソフトウェアの実行時の資源使用量に基づいて、クラウド環境に対するアプリケーションソフトウェアのデプロイを実行するクラウドアプリケーションデプロイ装置によるクラウドアプリケーションデプロイ方法であって、
前記クラウドアプリケーションデプロイ装置は、前記クラウド環境の計算機ノードに対する前記アプリケーションソフトウェアの実行時における時刻期間ごとの資源使用量データを保持し、
前記特徴量ベクトルを含むクラスタの特徴量ベクトルに対応する時刻期間の時系列を前記アプリケーションソフトウェアのフェーズとし、
前記クラウドアプリケーションデプロイ装置は、前記アプリケーションソフトウェアの実行時における時刻期間ごとの資源使用量データから前記時刻期間ごとの特徴量ベクトルを算出して、時刻期間ごとの特徴量ベクトルをクラスタリングしてクラスタを作成し、前記クラスタリングの結果を検証して、あるフェーズに属するかを判定するフェーズ分類モデルを有し、
前記クラウドアプリケーションデプロイ装置が、前記アプリケーションソフトウェアの実行時における時刻期間ごとの資源使用量データから前記時刻期間ごとの特徴量ベクトルを算出するステップと、
前記クラウドアプリケーションデプロイ装置が、前記時刻期間ごとの特徴量ベクトルをクラスタリングしてクラスタを作成するステップと、
前記クラウドアプリケーションデプロイ装置が、新規アプリケーションソフトウェアに対して、前記新規アプリケーションソフトウェアの実行時における時刻期間ごとの資源使用量データを収集するステップと、
前記新規アプリケーションソフトウェアの実行の前記時刻期間ごとの特徴量ベクトルに対して、既にフェーズ分類モデルが得られた既知のフェーズのフェーズ分類モデルにより作成されたクラスタに属する特徴量ベクトルとｖａｌｉｄａｔｉｏｎを行い、ｖａｌｉｄａｔｉｏｎの度合いによって、各々の前記時刻期間が既知フェーズに属するか、既知フェーズに属さないかを未知フェーズに属するかを判定するステップと、
前記アプリケーションソフトウェアのフェーズごとに計算機ノードにおける資源使用量を推論するステップと、
前記アプリケーションソフトウェアのフェーズごとに計算機ノードにおける資源使用量に基づいて、前記計算機ノードにおけるクラウド環境のコンテナ資源使用制限を算出するステップと、
前記コンテナ資源使用制限により、前記アプリケーションソフトウェアアプリケーションソフトウェアのデプロイを実行するステップとを有することを特徴とするクラウドアプリケーションデプロイ方法。

【請求項9】

前記新規アプリケーションソフトウェアの前記未知フェーズに属するとされた前記時刻期間ごとの特徴量ベクトルは、一つ以上の前記既知フェーズの特徴量ベクトルにそれぞれの重み付け係数をかけた特徴量ベクトルの直積として合成されることを特徴とする請求項８記載のクラウドアプリケーションデプロイ方法。

【請求項10】

前記重み付け係数は、前記資源使用量データから前記時刻期間ごとの特徴量ベクトル作成する際に、高次元の時系列データから低次元の特徴量ベクトルにｅｎｃｏｄｅするニューラルネットワークを用いて、前記資源使用量データにｄｅｃｏｄｅするニューラルネットワークを同時に学習させたときの損失関数から評価されるｄｅｃｏｄｅ精度から求められることを特徴とする請求項９記載のクラウドアプリケーションデプロイ方法。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、クラウドアプリケーションデプロイ装置およびクラウドアプリケーションデプロイ方法に係り、特に、クラウドコンピューティングにおいて、クラウドの資源の使用効率を向上させて、最適なアプリケーションのクラウドへのデプロイを行うのに好適なクラウドアプリケーションデプロイ装置およびクラウドアプリケーションデプロイ方法に関する。

【背景技術】

【0002】

クラウドコンピューティング環境において、データ分析や機械学習等のアプリケーションソフトウェア（以下、単に、「アプリケーション」ともいう）をコンテナ化して大規模に実行する場合に、クラウドのコンピュータ資源（ハードウェア資源・ソフトウェア資源）を効率的に使用し、メモリ不足等によるプロセスの異常終了を予防するために、コンテナのＣＰＵ、メモリ等の資源使用量制限を、アプリケーションが実際に使用する資源量に合わせて設定する必要がある。

【0003】

ここで、コンテナとは、ホストＯＳ上でコマンドやライブラリなど、アプリケーションを実行するために必要な環境をまとめた概念であり、このコンテナにより、一つのサーバ上で従来のＶＭ（Virtual Machine）と比較し、軽量な実行環境を複数構築することが可能になる。

【0004】

クラウドを利用してコンテナ化されたアプリケーションを大規模に実行するユーザは、実行時間をできるだけ短縮するとともにメモリ不足などによる異常終了を回避するために、実用上は、アプリケーションが実際に使用するＣＰＵ、メモリ等の計算資源量よりも大きめに見積り、コンテナの資源使用制限の値を設定する必要がある。このような前提で資源の使用量を大きく見積って、アプリケーションをデプロイ（deploy）すると、クラウドの資源利用効率が低下するとともに、ユーザは過大なコストを支払うことになる。ここで、アプリケーションのデプロイとは、アプリケーションを動作可能なように、クラウド上に配置して設定し、動作可能な状態にすることを意味する。一般には、クラウド上でアプリケーションの正確なサイジング（資源のサイズの見積もり）を行うためには、事前にユーザ要件に合わせたテストを実行して測定した資源使用量に基づいて、コンテナの資源使用量制限を設定してクラウドにデプロイする必要がある。

【0005】

デプロイ前のサイジング作業を行うことなく、コンテナのサイズを自動調整（Auto Scaling）する方法として、過去に実行されたアプリケーションの資源使用量データを蓄積して分析することによって、コンテナの資源使用量制限を算出する方法がある。

【0006】

例えば、非特許文献１には、多次元時系列データとしての資源使用量データから抽出した低次元の特徴量ベクトルをクラスタリングすることによって、アプリケーションの動作を少数の実行フェーズに分類する方法が用いられている。一般には、このように資源使用パターンが類似するフェーズごとに資源使用量制限を算出する方が、資源の無駄使いや制限越えが発生する頻度が小さくなることが知られている。

【0007】

非特許文献１では、フェーズ分類に関して、深層学習（Deep Learning）の一手法であるＣＲＢＭ（Conditional Restricted Boltzmann Machine）の手法が用いられている。

【0008】

また、これに関連して、学習済のニューラルネットワークをベースに、別の問題に対して機械学習を行う転移学習に関して、特許文献１には、新規データに対する、既存のニューラルネットワーク学習データの類似度に基づいて、新規モデルを学習するか否かを決定するとともに、新規モデルの学習データを既存のニューラルネットワーク同士の類似度に基づいて作成する技術が開示されている。

【先行技術文献】

【特許文献】

【0009】

【特許文献1】米国特許出願公開第２０２０／０３２０３７９号

【非特許文献】

【0010】

【非特許文献1】J. L. Berral, et. al., “AI4DL: Mining Behaviors of Deep Learning Workloads for Resource Management”, [online], USENIX THE ADVANCED COMPUTING ASSOCIATION, in 12th USENIX Workshop HotCloud, [令和３年１１月４日検索], インターネット<URL: https://www.usenix.org/system/files/hotcloud20_paper_berral.pdf”

【発明の概要】

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

【0011】

非特許文献１では、フェーズ分類に関して、深層学習（Deep Learning）の一手法であるＣＲＢＭの手法を用いて、多次元時系列データとしての資源使用量データから抽出した低次元の特徴量ベクトルをクラスタリングして、グラフとツリーによってクラスタにおける資源使用量を評価している。この非特許文献１によれば、ＣＰＵ負荷やメモリ使用量だけでない多くのメトリックを考慮したフェーズ分類を行うことができる一方で、低次元の特徴量ベクトル抽出にニューラルネットワークの一種であるＣＲＢＭを用いるため、ＣＲＢＭの学習に大量の資源使用量データが必要となる。また、機械学習およびクラスタリングを精度よく行うためには、結果として分類されるフェーズが少数である方が望ましく、従ってアプリケーションごとに蓄積したデータを学習して分類モデルを作成するのが基本的な用法となる。しかしながら、計算目的を機械学習に限定するなど、同種のアプリケーションが大規模に実行される専用のクラウドに適用する場合には有効だが、多様な目的で使用される汎用的なクラウドに対して適用して資源評価の精度を上げるのは難しい。

【0012】

また、非特許文献１の例では、コンテナ資源制限が大きい場合の資源使用量データを分析して、アプリケーションが実際に使用する使用量を推論してコンテナ資源使用制限を自動調整することを想定しており、コンテナ資源制限が小さい場合に、ユーザが要求するサービスレベル、すなわち、アプリケーション実行性能の要件をみたすことができるか否かを推論することはできない。

【0013】

一方、アプリケーション実行性能の推論は、クラウドの計算資源が十分でない場合や、ユーザがコスト重視で資源割り当てを行いたい場合にも行う必要があり、一般には、コンテナ資源制限が小さい場合のアプリケーション実行性能を推論するため、アプリケーションをデプロイする前に、コンテナ資源制限およびアプリケーションの入力データ量などのパラメータを網羅的に変えてテスト実行を行い、測定した性能をもとにユーザの要件をみたす資源制限値を推論する回帰式を作成する方法がある。

【0014】

しかしながら、クラウドで実行されるアプリケーションは、オープンソースを含む様々なマイクロサービス化されたソフトウェアを組み合わせて構成されるため、実際上、システム実装者に対して、アプリケーションのデプロイ前に全てのコンテナについて網羅的なテストを実行することを必要条件とするのは難しい。

【0015】

また、特許文献１に記載されている転移学習方法を、クラウドで実行される新規アプリケーションの資源使用量データに適用し、新規フェーズ分類モデルの転移学習を行うには、既存のフェーズ分類モデルの学習データと、新規アプリケーションの資源使用量データとの類似度に基づいて、転移学習用の学習データを作成する必要がある。しかしながら、新規アプリケーションの資源使用パターンには、複数の既存アプリケーションの実行フェーズが任意の組合せで出現しうるため、既存の学習データとの類似度に基づいて新規モデルの学習データを作成するのは困難である。

【0016】

本発明の目的は、クラウドのコンテナ上に新規にアプリケーションをデプロイするときに、クラウドの資源の使用効率を向上させて、最適なアプリケーションのデプロイを行うことのできるクラウドアプリケーションデプロイ装置およびクラウドアプリケーションデプロイ方法を提供することにある。

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

【0017】

本発明のクラウドアプリケーションデプロイ装置は、好ましくは、アプリケーションソフトウェアの実行時の資源使用量に基づいてクラウド環境に対して、アプリケーションソフトウェアのデプロイを実行するクラウドアプリケーションデプロイ装置であって、計算機ノードに対するアプリケーションソフトウェアの実行時における時刻期間ごとの資源使用量データを保持し、アプリケーションソフトウェアの実行時における時刻期間ごとの資源使用量データから時刻期間ごとの特徴量ベクトルを算出し、時刻期間ごとの特徴量ベクトルをクラスタリングしてクラスタを作成し、特徴量ベクトルを含むクラスタの特徴量ベクトルに対応する時刻期間の時系列をアプリケーションソフトウェアのフェーズとし、アプリケーションソフトウェアの実行時における時刻期間ごとの資源使用量データから時刻期間ごとの特徴量ベクトルを算出して、時刻期間ごとの特徴量ベクトルをクラスタリングしてクラスタを作成し、クラスタリングの結果を検証して、あるフェーズに属するかを判定するフェーズ分類モデルを有し、新規アプリケーションソフトウェアに対して、新規アプリケーションソフトウェアの実行時における時刻期間ごとの資源使用量データを収集し、新規アプリケーションソフトウェアの実行の時刻期間ごとの特徴量ベクトルに対して、既にフェーズ分類モデルが得られた既知のフェーズのフェーズ分類モデルにより作成されたクラスタに属する特徴量ベクトルとｖａｌｉｄａｔｉｏｎを行い、ｖａｌｉｄａｔｉｏｎの度合いによって、各々の時刻期間が既知フェーズに属するか、既知フェーズに属さないかを未知フェーズに属するかを判定し、アプリケーションソフトウェアのフェーズごとに計算機ノードにおける資源使用量を推論し、アプリケーションソフトウェアのフェーズごとに計算機ノードにおける資源使用量に基づいて、計算機ノードにおけるクラウド環境のコンテナ資源使用制限を算出し、コンテナ資源使用制限により、アプリケーションソフトウェアアプリケーションソフトウェアのデプロイを実行するようにしたものである。

【発明の効果】

【0018】

本発明によれば、クラウドのコンテナ上に新規にアプリケーションをデプロイするときに、クラウドの資源の使用効率を向上させて、最適なアプリケーションのデプロイを行うことのできるクラウドアプリケーションデプロイ装置およびクラウドアプリケーションデプロイ方法を提供することができる。

【図面の簡単な説明】

【0019】

【図1】クラウドアプリケーション配置装置が用いられるクラウドシステムの機能構成図である。

【図2】クラウドアプリケーション配置装置の機能構成図である。

【図3】クラウドアプリケーション配置装置のハードウェア・ソフトウェア構成図である。

【図4】資源使用量テーブルの一例を示す図である。

【図5】特徴量ベクトル情報テーブルの一例を示す図である。

【図6】資源使用量推論テーブルの一例を示す図である。

【図7】アプリケーションのフェーズ、特徴量ベクトル、クラスタの概念とそれらの関係を示す図である。

【図8A】コンテナ使用制限算出と未知フェーズに対する学習の処理を示すフローチャートである（その一）。

【図8B】コンテナ使用制限算出と未知フェーズに対する学習の処理を示すフローチャートである（その二）。

【図9】クラウド設計者がアプリケーションデプロイを行うまでの処理を示すフローチャートである。

【図10】スローダウン性能推論関数の一例を示す図である。

【図11】コンテナ資源使用制限値解析画面の一例を示す図である。

【図12】クラウドアプリケーションデプロイ装置を有するクラウドシステムの構成図である。

【発明を実施するための形態】

【0020】

以下、本発明に係る各実施形態を、図１ないし図１２を用いて説明する。

【0021】

〔実施形態１〕
以下、本発明に係る実施形態１を、図１ないし図１１を用いて説明する。

【0022】

先ず、本発明のクラウドアプリケーション配置装置に関する資源使用量の算出の概要について説明する。
本発明のクラウドでのアプリケーションのデプロイでは、コンテナ化されたアプリケーションが実行されるクラウドコンピューティング環境において、蓄積した資源使用量データの多次元時系列データ分析をもとに、コンテナの資源使用量制限を自動で算出するシステムを対象とする。当該クラウド上で実行される主要なアプリケーションについては、過去の実行における資源使用量データを蓄積し、非特許文献１のようなモデルが既に学習されており、実行フェーズへの分類が行われ、各フェーズにおける資源使用量プロファイルに基づいて、資源のむだ使いと制限越えによる異常終了の発生頻度が小さくなるようなコンテナ資源使用制限の設定が可能であるものとする。

【0023】

こうしたクラウドの運用において、過去にあまり実行された実績がないアプリケーションに対しても、同様に最適なコンテナ使用制限の設定を可能とするために、既存のフェーズ分類モデルを新規アプリケーションに対しても適用することを試みる。

【0024】

例えば、非特許文献１に記載されている手法である資源使用量データから特徴量ベクトルを抽出するＣＲＢＭでは、特徴量ベクトルが元の資源使用量データを特徴付けているかを調べるｖａｌｉｄａｔｉｏｎを行うことができ、ｖａｌｉｄａｔｉｏｎの度合いによって新規アプリケーションの資源使用量データのどの部分が既存のモデルでフェーズ分類可能な時刻区間かを検出することができる。このようにして、既存モデルで分類できる既知のフェーズと、残りの未知のフェーズに資源使用量データを分割して、未知フェーズのデータを新たな分類モデルの機械学習に使用する。結果として、新規アプリケーション実行における既知のフェーズが増加していけば、新規アプリケーションに対しても、より正確な資源使用量の推論が可能となる。

【0025】

高次元の時系列データである資源使用量データを低次元の特徴量ベクトルにｅｎｃｏｄｅするニューラルネットワークとして、もとの資源使用量データにｄｅｃｏｄｅするニューラルネットワークを同時に学習させ、損失関数により評価されるｄｅｃｏｄｅ精度を用いる方法（auto encoder）がある。この場合ｖａｌｉｄａｔｉｏｎの方法として、特徴量ベクトルをもとの資源使用量データにｄｅｃｏｄｅする精度を評価する手法を用いることができる。すなわち、主要アプリケーションに対応するフェーズ分類モデルは、特定のアプリケーション実行パターンに特化して学習したモデルであり、新規アプリケーション実行パターンに対する当該モデルのｖａｌｉｄａｔｉｏｎの結果が、主要アプリケーションと新規アプリケーションの実行パターンの違いを示すことを意味すると考えられる。そこで、実行パターンの違いに応じて特徴量ベクトルを重み付けし、複数のアプリケーションにまたがって実行パターンを示す特徴量ベクトルを合成する。この異なるアプリケーションにまたがって実行パターンを示す特徴量ベクトルをクラスタリングし、クラスタごとにＣＰＵ、メモリ使用量を統計処理することにより資源使用制限を算出する。

【0026】

また、既存のアプリケーションに対してサイジングのためのテスト実行を行うことにより、コンテナ資源制限が小さい場合に実行時間がスローダウンする割合を推論するモデルが既に作成されている場合、既知のフェーズに分類された新規アプリケーションについても、同じ推論モデルを適用することができると考えられる。このようにして、全てのアプリケーションに対してサイジングのためのテスト実行を行うことなく、実行時間の推論が可能な部分を増やすことができる。

【0027】

次に、図１ないし図３を用いてクラウドアプリケーション配置装置が用いられるクラウドシステムの構成を説明する。

【0028】

クラウドシステムは、図１に示されるように、クライアント１と、クラウド環境１０と、クラウドアプリケーションデプロイ装置１００がネットワーク５により接続された形態である。ネットワーク５は、通常は、インターネットのようなグローバルネットワークであるが、ＬＡＮ（Local Area Network）の接続形態でもよい。

【0029】

クライアント１は、クラウド環境１０に対してクラウドサービスを要求し、クラウド環境１０から要求した計算結果や検索の受信などのサービスを受ける情報処理装置である。

【0030】

クラウド環境１０は、機能的に管理ノード２０と計算機ノード３０（図では、３０ａ、３０ｂ、…と表記）からなる。

【0031】

管理ノード２０は、各計算機ノード３０におけるアプリケーション３２の実行と資源使用量を監視するノードであり、アプリケーション実行管理部２１と資源使用量監視部２２からなる。ここで、クラウド環境における資源とは、ＣＰＵ、メモリ、入出力装置、ネットワークなどのハードウェア資源である。

【0032】

計算機ノード３０は、計算機としての機能を実現するノードであり、アプリケーション３２とその他のアプリ実行のためのコマンドやライブラリ（図示せず）をパッケージングしたコンテナ３１と、そのコンテナ３１の挙動を監視するコンテナ監視部３３からなる。

【0033】

コンテナ監視部３３がモニターしたアプリケーション３２実行時のＣＰＵ、メモリ、入出力、通信等の資源使用量データは、管理ノード２０で動作する資源使用量監視部２２が収集し、ネットワーク５を介して、クラウドアプリケーションデプロイ装置１００の資源使用量ＤＢ（後述）２００に蓄積される。

【0034】

クラウドアプリケーションデプロイ装置１００は、クラウド環境１０で実行されるアプリケーションの資源使用量を推定し、アプリケーションが異常終了を起こすことなく本来の性能が発揮できるように最適なアプリケーションのデプロイを行う装置である。

【0035】

次に、図２を用いてクラウドアプリケーション配置装置の機能構成について説明する。
クラウドアプリケーションデプロイ装置１００は、図２に示されるように、機能構成として、データ前処理部１０１、フェーズ分類モデル部１１０（図では、１１０ａ、１１０ｂ、…と図示）、未知フェーズ分類部１２０、資源使用量推論部１３０、性能推論部１３１、デプロイ先探索部１４０、アプリケーションデプロイ部１４１、記憶部１５０からなる。

【0036】

データ前処理部１０１は、蓄積された資源使用量データを、フェーズ分類モデル部の学習データとして使用するための加工を行う機能部である。

【0037】

フェーズ分類モデル部１１０は、本実施形態の機械学習におけるフェーズ分類モデルを実現する機能部である。フェーズ分類モデルは、当該クラウド環境１０において長時間実行されて、資源使用量ＤＢ２００にモデル学習に十分な量のデータが蓄積されているアプリケーションごとに作成される。

【0038】

フェーズ分類モデル部１１０は、特徴量抽出部１１１、特徴量検証部１１２、特徴量ベクトルクラスタリング部１１３、クラスタリング検証部１１４からなる。

【0039】

特徴量抽出部１１１は、資源使用量ＤＢ２００のデータを前処理した多次元時系列データから低次元の特徴量ベクトルを抽出する機能部である。

【0040】

特徴量検証部１１２は、特徴量ベクトルが元の資源使用パターンを表現していることを検証する機能部である。特徴量ベクトルクラスタリング部１１３は、抽出された特徴に基づく特徴量ベクトルをクラスタリングする機能部である。クラスタリング検証部１１４は、特徴量ベクトルクラスタリング部１１３によりクラスタリングされた結果を検証する機能部である。

【0041】

未知フェーズ分類部１２０は、アプリケーションの実行フェーズを既知であるか未知であるかを分類する機能部である。

【0042】

未知フェーズ分類部１２０は、新規アプリケーション既知フェーズ分類部１２１、未知フェーズ分類モデル部１２２、未知フェーズ特徴量ベクトル算出部１２３、未知フェーズ特徴量ベクトルクラスタリング部１２４からなる。

【0043】

新規アプリケーション既知フェーズ分類部１２１は、新規のアプリケーションに対して既知のフェーズか未知のフェーズかを分類する機能部である。ここで、「既知のフェーズ」とは、アプリケーションの実行フェーズの資源使用量の特徴により既存のフェーズ分類モデルによって分類できるフェーズであり、未知のフェーズとは、「既知のフェーズ」ではない実行フェーズ、すなわち、既存のフェーズ分類モデルによって分類できないフェーズである。未知フェーズ分類モデル部１２２は、未知フェーズと分類されたフェーズの資源使用量データに対して、フェーズ分類モデルの機械学習を行う機能部である。未知フェーズ分類モデル部１２２は、構造的、機能的には、既に説明したフェーズ分類モデル部１１０と同様である。未知フェーズ特徴量ベクトル算出部１２３は、複数のアプリケーションを実行パターンの違いに応じて重みづけ係数より特徴量ベクトルを重み付けし、それぞれにまたがる特徴量ベクトルを合成して、未知フェーズ特徴量ベクトルを算出する（詳細は後述）機能部である。重みづけ係数の算出は、既に説明したように、ｄｅｃｏｄｅ精度を用いることができる。

【0044】

未知フェーズ特徴量ベクトルクラスタリング部１２４は、未知フェーズ特徴量ベクトル算出部１２３により算出された未知フェーズの時刻区間の特徴量ベクトルに対してクラスタリングを行う機能部である。

【0045】

資源使用量推論部１３０は、アプリケーションの実行フェーズについて資源使用量を推論する機能部である。資源使用量推論部１３０は、アプリケーションの既知フェーズについては、例えば、過去の長時間実行における既存の学習データをもとに作成された資源使用量推論関数を用いて、資源使用量を推論することができる。

【0046】

性能推論部１３１は、コンテナ上でアプリケーションをテスト実行させた結果から、コンテナ上でアプリケーションを実行させた性能を推論する機能部である。性能推論は、資源の各々の使用量に対して計算機上での性能の低下を示すスローダウン推論関数が定義されている場合、それにより行うことができる。

【0047】

デプロイ先探索部１４０は、コンテナ資源とアプリケーションの実行の際の資源使用量に基づいて、アプリケーションのデプロイ先を探索する機能部である。

【0048】

アプリケーションデプロイ部１４１は、デプロイ先探索部１４０により探索されたプリケーションのデプロイ先を出力し、管理ノード２０のアプリケーション実行管理部２１に指示を与える機能部である。

【0049】

記憶部１５０は、クラウドアプリケーションデプロイ装置１００により使用されるデータを保持する機能部である。記憶部１５０には、例えば、資源使用量ＤＢ（Data Base）２００、デプロイ決定ＤＢ２０１が保持される。資源使用量ＤＢ２００には、例えば、アプリケーションを実行する計算機ノード３０ごとの時系列の一定の時刻期間ごと、資源種類ごとに資源の使用量を示したテーブルが格納されている。デプロイ決定ＤＢ２０１は、クラウドアプリケーションデプロイ装置１００がアプリケーションをデプロイするために用いられるテーブル、例えば、アプリケーションを実行するクラウド環境における計算機ノード３０ごとのある時刻期間ごとの特徴量ベクトルの情報を保持するテーブルが格納されている。

【0050】

次に、図３を用いてクラウドアプリケーションデプロイ装置１００のハードウェア・ソフトウェア構成を説明する。
クラウドアプリケーションデプロイ装置１００のハードウェア構成としては、例えば、図３に示されるパーソナルコンピュータのような一般的な情報処理装置で実現される。

【0051】

クラウドアプリケーションデプロイ装置１００は、ＣＰＵ（Central Processing Unit）３０２、主記憶装置３０４、ネットワークＩ／Ｆ（InterFace）３０６、表示Ｉ／Ｆ３０８、入出力Ｉ／Ｆ３１０、補助記憶Ｉ／Ｆ３１２が、バスにより結合された形態になっている。

【0052】

ＣＰＵ３０２は、クラウドアプリケーションデプロイ装置１００の各部を制御し、主記憶装置３０４に必要なプログラムをロードして実行する。

【0053】

主記憶装置３０４は、通常、ＲＡＭなどの揮発メモリで構成され、ＣＰＵ３０２が実行するプログラム、参照するデータが記憶される。

【0054】

ネットワークＩ／Ｆ３０６は、ネットワーク５と接続するためのインタフェースである。

【0055】

表示Ｉ／Ｆ３０８は、ＬＣＤ（Liquid Crystal Display）などの表示装置３２０を接続するためのインタフェースである。

【0056】

入出力Ｉ／Ｆ３１０は、入出力装置を接続するためのインタフェースである。図３の例では、キーボード３３０とポインティングデバイスのマウス３３２が接続されている。

【0057】

補助記憶Ｉ／Ｆ３１２は、ＨＤＤ（Hard Disk Drive）３５０やＳＳＤ（Solid State Drive）などの補助記憶装置を接続するためのインタフェースである。

【0058】

ＨＤＤ３５０は、大容量の記憶容量を有しており、本実施形態を実行するためのプログラムが格納されている。クラウドアプリケーションデプロイ装置１００には、データ前処理プログラム４０１、フェーズ分類モデルプログラム４１０、未知フェーズ分類プログラム４２０、資源使用量推論プログラム４３０、性能推論プログラム４３１、デプロイ先探索プログラム４４０、アプリケーションデプロイプログラム４４１がインストールされている。

【0059】

データ前処理プログラム４０１、フェーズ分類モデルプログラム４１０、未知フェーズ分類プログラム４２０、資源使用量推論プログラム４３０、性能推論プログラム４３１、デプロイ先探索プログラム４４０、アプリケーションデプロイプログラム４４１は、それぞれデータ前処理部１０１、フェーズ分類モデル部１１０、未知フェーズ分類部１２０、資源使用量推論部１３０、性能推論部１３１、デプロイ先探索部１４０、アプリケーションデプロイ部１４１の機能を実現するプログラムである。

【0060】

また、ＨＤＤ３５０は、資源使用量ＤＢ）２００、デプロイ決定ＤＢ２０１が格納されている。

【0061】

次に、図４ないし図６を用いてクラウドアプリケーションデプロイ装置で用いられるデータ構造について説明する
資源使用量テーブル２０１は、アプリケーションを実行する計算機ノード３０ごと、時刻期間ごとの資源使用量を保持するテーブルであり、資源使用量ＤＢ２００に格納される。

【0062】

資源使用量テーブル２０１は、図４に示されるように、計算機ノードＩＤ２０１ａ、アプリケーションＩＤ２０１ｂ、時刻期間ＩＤ２０１ｃ、計測時刻２０１ｄ、ＣＰＵ２０１ｅ、仮想メモリ容量２０１ｆ、ストレージ容量２０１ｇ、ネットワーク帯域２０１ｈの各フィールドからなる。

【0063】

計算機ノードＩＤ２０１ａには、アプリケーションを実行する計算機ノードを一意に識別する識別子が格納される。詳細には、示さなかったがクラウドアプリケーションデプロイ装置は、計算機ノード３０のハードウェアを示す諸元（ＣＰＵモデルＮＯ、コア数、ＣＰＵ動作周波数、ＣＰＵベンチマーク、主メモリ容量、ストレージ容量、ネットワーク帯域、ＩＯ接続形態など）を保持する。アプリケーションＩＤ２０１ｂには、実行するアプリケーションソフトウェアを一意に識別する識別子が格納される。時刻期間ＩＤ２０１ｃには、資源使用量を分析するため時刻を切出した期間を一意に識別する識別子が格納される。時刻期間ＩＤ２０１ｃは、システムで一意的な主キーであり、計算機ノードＩＤ、アプリケーションが変わっても、一意的な値をとるようにしておく。計測時刻２０１ｄには、時刻期間の最初の時刻が、例えば、ｙｙｙｙｍｍｄｄｈｈｍｍｓｓの形式で格納される。時刻期間は、例えば、図４に示すように、１０秒単位で格納される。ＣＰＵ２０１ｅには、時刻期間におけるＣＰＵの使用割合が、例えば、パーセント表示で格納される。仮想メモリ容量２０１ｆには、アプリケーションの使用する仮想メモリの使用容量が、例えば、ＭＢ単位で格納される。ストレージ容量２０１ｇには、アプリケーションの使用するストレージ（ＳＳＤ、ＨＤＤなどの補助記憶装置）の使用容量が、例えば、ＭＢ単位で格納される。ネットワーク帯域２０１ｈには、アプリケーションの使用帯域が格納される。なお、この例では、資源使用量として、ＣＰＵ、仮想メモリ、ストレージ容量、ネットワーク帯域のみ示したがその他の、例えば、ＩＯ使用帯域、ＧＰＵの使用率などの資源使用量を保持してもよい。

【0064】

次に、図５を用いて特徴量ベクトル情報テーブルの一例について説明する。
特徴量ベクトル情報テーブル２１１は、アプリケーション実行の際の時刻期間ごとに作成される特徴量ベクトルに関する情報を保持するテーブルであり、デプロイ決定ＤＢ２１１に格納される。
特徴量ベクトル情報テーブル２１１は、図５に示されるように、時刻期間ＩＤ２１１ａ、特徴量ベクトル２１１ｂ、クラスタＩＤ２１１ｃの各フィールドからなる。

【0065】

時刻期間ＩＤ２１１ａには、資源使用量テーブル２０１の時刻期間ＩＤ２０１ｃと同様、資源使用量を分析するため時刻を切出した期間を一意に識別する識別子が格納される。特徴量ベクトル２１１ｂは、時刻期間ＩＤ２１１ａの示す時刻期間ＩＤに対して特徴量ベクトル抽出部１１１により算出された特徴量ベクトルの値が、例えば、要素数分のリスト形式で格納される。クラスタＩＤ２１１ｃは、特徴量ベクトルクラスタリング部１１１により判定された特徴量ベクトル２１１ｂの示す特徴量ベクトルがどのクラスタに属するかを示すクラスタＩＤが格納される。クラスタＩＤは、システムで一意的にとるものとする。

【0066】

資源使用量推論テーブル２１２は、特徴量ベクトルのクラスタに対して推論された資源使用量を資源の種別ごとに保持するテーブルであり、図６に示されるように、クラスタＩＤ２１２ａ、ＣＰＵ２１２ｂ、仮想メモリ容量２１２ｃ、ストレージ容量２１２ｅ、ネットワーク帯域２１２ｆの各フィールドからなる。

【0067】

クラスタＩＤ２１２ａには、特徴量ベクトル情報テーブル２１１のクラスタＩＤ２１１ｃと同様、特徴量ベクトルがどのクラスタに属するかを示すクラスタＩＤが格納される。ＣＰＵ２１２ｂ、仮想メモリ容量２１２ｃ、ストレージ容量２１２ｅ、ネットワーク帯域２１２ｆは、資源使用量推論部１３０により推論されたそれぞれ資源使用量テーブル２０１のＣＰＵ２０１ｅ、仮想メモリ容量２０１ｆ、ストレージ容量２０１ｇ、ネットワーク帯域２０１ｈの資源の種類に対応する推論された値が格納される。

【0068】

次に、図７を用いてアプリケーションのフェーズ、特徴量ベクトル、クラスタと資源算出の概要とそれらの関係について説明する。
図７では、ある計算機ノード３０で、あるアプリケーションを実行したときの資源の使用パターンとして、ＣＰＵ、仮想メモリ容量、ストレージ容量、ネットワーク帯域が示されている。

【0069】

クラウドアプリケーションデプロイ装置１００の特徴量抽出部１１１は、このような資源の使用パターンを多次元時系列データとみなして、それぞれの時刻期間ごとに特徴量ベクトルｖ_１１、ｖ_１２、ｖ_２１、ｖ_２２、…を算出する。この多次元時系列データから特徴量ベクトルを算出するのは、既存の機械学習の手法として知られている既にあげたＣＲＢＭや、ＬＳＴＭ（Long Short Term Memory） ＡｕｔｏＥｎｃｏｄｅｒ、Ｔｉｍｅ Ｄｅｌａｙ Ｅｍｂｅｄｄｉｎｇの手法を用いることができる。

【0070】

次に、クラウドアプリケーションデプロイ装置１００の特徴量ベクトルクラスタリング部１１３は、例えば、教師データなし学習の一種であるｋ－ｍｅａｎｓ法を利用して、クラスタリングによる分類を行う。ｋ－ｍｅａｎｓ法は、学習データから抽出した特徴量ベクトルから算出した一定数のクラスタ重心からの距離をもとに、資源使用量データから抽出した特徴量ベクトルのクラスタリングする手法である。また、クラウドアプリケーションデプロイ装置１００のクラスタリング検証部１１４は、特徴量ベクトルのクラスタ重心からの距離が、学習データから抽出した特徴量ベクトルの分布から外れている度合いによって、クラスタリング結果を検証することができる。図７では、ｖ_１１、ｖ_１２、…が、クラスタＣ_１、ｖ_２１、ｖ_２２、…が、クラスタＣ_２に属するものとしている。

【0071】

本実施形態では、この特徴量ベクトルの一つのクラスタが一つのフェーズを表すものと考える。

【0072】

次に、新規のアプリケーションに対して実行フェーズが既知フェーズか未知フェーズかを分類する仕方について説明する。

【0073】

アプリケーションを実行した際の時刻期間が既知フェーズと未知フェーズに属するかの分類は、上記の資源の使用パターンを多次元時系列データとみなして、それぞれの時刻期間ごとに特徴量ベクトルに基づいて算出する。

【0074】

既に説明したように、例えば、資源使用量データから特徴量ベクトルを抽出するＣＲＢＭでは、特徴量ベクトルが元の資源使用量データを特徴付けているかを調べるｖａｌｉｄａｔｉｏｎを行うことができ、ｖａｌｉｄａｔｉｏｎの度合いによって新規アプリケーションの資源使用量データのどの部分が既存のモデルでフェーズ分類可能な時刻区間かを検出することができる。すなわち、既知フェーズの特徴量ベクトルが得られている場合、新規のアプリケーションに対して実行フェーズに対する特徴量ベクトルのｖａｌｉｄａｔｉｏｎの度合いを比較することにより、アプリケーションを実行した際の時刻期間が既知フェーズと未知フェーズに属するかの分類することができる。

【0075】

例えば、既知フェーズのクラスタに属する特徴量ベクトルと、新規のアプリケーションに対して実行フェーズに対する特徴量ベクトルのｖａｌｉｄａｔｉｏｎの度合いを取って、クラスタの特徴量ベクトルについて計算されるｖａｌｉｄａｔｉｏｎの度合いの平均を取り、ｖａｌｉｄａｔｉｏｎの度合いが大きいほど特徴量ベクトルが類似すると定義したときに、規定の値以下のときには、その新規のアプリケーションに対して実行フェーズに対する特徴量ベクトルがその既知フェーズに属すると判定する。

【0076】

また、既に説明したように、ｖａｌｉｄａｔｉｏｎの方法としては、高次元の時系列データである資源使用量データを低次元の特徴量ベクトルにｅｎｃｏｄｅするニューラルネットワークとして、もとの資源使用量データにｄｅｃｏｄｅするニューラルネットワークを同時に学習させ、損失関数により評価されるｄｅｃｏｄｅ精度を用いる方法（auto encoder）があり、この場合ｖａｌｉｄａｔｉｏｎの方法として、特徴量ベクトルをもとの資源使用量データにｄｅｃｏｄｅする精度を評価する手法を用いることができる。

【0077】

次に、既知のフェーズから未知のフェーズに属する特徴量ベクトルを算出する方法について説明する。

【0078】

既知のフェーズとは、既存のフェーズ分類モデルにより特徴量ベクトルのクラスタが得られるアプリケーションの実行フェーズのことであった。

【0079】

ここで、既知のフェーズのクラスタに属する特徴量ベクトルを、ｖ_１、ｖ_２、…、ｖ_ｉ、…とする。

【0080】

ここで、新規のアプリケーションの実行フェーズは、未知のフェーズを含むと想定される。ここで、ある未知フェーズの特徴量ベクトルを、既知のフェーズのクラスタに属する特徴量ベクトルを、ｖ_１、ｖ_２、…、ｖ_ｉ、…から合成して再定義することを考える。既知のフェーズは、複数のアプリケーションにまたがっていてもよい。

【0081】

ある未知フェーズの時刻期間に対する特徴量ベクトルｕを、以下の既知フェーズの時刻期間に対する特徴量ベクトルを用いて（式１）により合成する。

【0082】

【数1】

【0083】

ここで、ｗ_ｉは、重み付け係数であり、例えば、未知フェーズの時刻区間を、特徴量ベクトルｖ_ｉにより検証した際のｖａｌｉｄａｔｉｏｎの度合いにより計算される０～１の値をとるスカラー値であり、各々の特徴量ベクトルが０に近いほど、特徴が離れており、１に近いほど特徴が類似するものと定義する。

【0084】

既に説明したように、ｗ_ｉは、高次元の時系列データである資源使用量データを低次元の特徴量ベクトルにｅｎｃｏｄｅするニューラルネットワークと、もとの資源使用量データにｄｅｃｏｄｅするニューラルネットワークを同時に学習させた場合における損失関数から評価されるｄｅｃｏｄｅ精度から定義することができる。

【0085】

Πは、インデックスの特徴量ベクトルの直積をとることを意味する。例えば、ｎ次元の特徴ベクトルｖ_１＝（ａ_１１，ａ_１２，…，ａ_１ｎ）、ｖ_２＝（ａ_２１，ａ_２２，…，ａ_２ｎ）の合成ベクトルは、以下の（式２）に示されるような２ｎ次元のベクトルになる。

【0086】

【数2】

【0087】

次に、クラスタＣに属する特徴量ベクトルの時刻期間における資源使用量データをパラメータとして、以下の（式３）に示される資源使用量推論関数ＲｅｓＵｓｅから、（ＣＰＵ、仮想メモリ容量、ストレージ容量、ネットワーク帯域）のそれぞれの資源使用量が推論される。

【0088】

【数3】

【0089】

そして、この資源使用量から一定の余裕の資源量を足してコンテナ資源使用制限値を計算することができる。クラスタに属する特徴量ベクトルの時刻期間における資源使用量データを統計処理することにより得ることができる。例えば、極端な外れ値を除外し、それぞれの特徴量ベクトルｖに対する資源使用量資源使用量データの（ＣＰＵ、仮想メモリ容量、ストレージ容量、ネットワーク帯域）の各々に対して、相加平均をとるなどである。

【0090】

次に、図８Ａないし図１０を用いてクラウドアプリケーションデプロイ装置の実行する処理について説明する。

【0091】

先ず、図８Ａおよび図８Ｂを用いてコンテナ使用制限算出と未知フェーズに対する学習の処理について説明する。

【0092】

クラウドアプリケーションデプロイ装置１００は、資源使用量ＤＢ２００の資源使用量テーブル２０１から取得したデータを取得する（Ｓ１０１）。

【0093】

次に、クラウドアプリケーションデプロイ装置１００のデータ前処理部１０１は、資源使用量ＤＢ２００の資源使用量テーブル２０１から取得した過去にハードウェアの計算機ノード３０により実行された場合の資源使用量データに対する前処理を行う（Ｓ１０２）。

【0094】

データの前処理は、例えば、資源使用量データ採取の時間間隔が異なる場合には、データの内挿を行うなどして、一定間隔の時系列データに加工する、また、複数の計算ノードで並列実行されたアプリケーションの場合には、資源使用量データに対して計算ノードあたりの平均値をとるなどに統計処理を行う処理である。

【0095】

次に、クラウドアプリケーションデプロイ装置１００は、モデリング対象のアプリケーションに対して、フェーズ分類モデルが作成済みか否かを判定し（Ｓ１０３）、そのアプリケーションに対するフェーズ分類モデルが未作成のときには（Ｓ１０３：ＮＯ）、Ｓ１０４に行き、フェーズ分類モデルが作成されているときには（Ｓ１０３：ＹＥＳ）、Ｓ１２０に行く。フェーズ分類モデルが未作成のときとは、アプリケーションの実行頻度が小さい場合であり、フェーズ分類モデルが作成されているときとは、そのアプリケーションの実行に対する過去の資源使用量データにより学習して、学習済のフェーズ分類モデルが作成されている場合である。

【0096】

そのアプリケーションに対するフェーズ分類モデルが作成されているときには、クラウドアプリケーションデプロイ装置１００の特徴量抽出部１１１は、特徴量ベクトルの抽出を行い（Ｓ１２０）、特徴量ベクトルクラスタリング部１１３は、特徴量ベクトルのクラスタリングを行い（１２１）、Ｓ１１０に行く。

【0097】

フェーズ分類モデルが未作成のときには、以下のＳ１０５、Ｓ１０６の処理を試行していない既存のフェーズ分類モデルをとり（Ｓ１０４）、クラウドアプリケーションデプロイ装置１００の特徴量抽出部１１１は、その既存のフェーズ分類モデルによる特徴量ベクトルの抽出を行い、特徴量検証部１１２は、特徴量ベクトルの検証を行う（Ｓ１０５）。

【0098】

次に、クラウドアプリケーションデプロイ装置１００の特徴量ベクトルクラスタリング部１１３は、その既存のフェーズ分類モデルによる特徴量ベクトルのクラスタリングを行い、クラスタリング検証部１１４は、クラスタリングの結果の検証を行う（Ｓ１０６）。

【0099】

次に、クラウドアプリケーションデプロイ装置１００は、Ｓ１０５、Ｓ１０６の処理を試行していない既存のフェーズ分類モデルがあるか否かを判定し（Ｓ１０７）、処理を試行していない既存のフェーズ分類モデルがあるときには（Ｓ１０７：ＹＥＳ）、Ｓ１０４に戻り、既存のフェーズ分類モデルがないときには（Ｓ１０７：ＮＯ）、Ｓ１０８に行く。

【0100】

次に、クラウドアプリケーションデプロイ装置１００の新規アプリケーション既知フェーズ分類部１２１は、各々の既存のフェーズ分類モデルによるクラスタリングの検証の結果として、いずれかの既存アプリケーションについてのフェーズ分類モデルによって既知のフェーズに分類可能であることが判明した時刻区間と、残りの未知フェーズの時刻区間とに分類を行う（Ｓ１０８）。

【0101】

未知フェーズに属する時刻区間については、クラウドアプリケーションデプロイ装置１００の既存のフェーズ分類モデルによって抽出された特徴量ベクトルを検証結果で重み付けした、異なるアプリケーションにまたがる特徴量ベクトルを合成し（（式１））、未知フェーズに属する時刻区間の特徴量ベクトルを算出し（Ｓ１０９）、未知フェーズ特徴量ベクトルクラスタリング部１２４は、未知フェーズ特徴量ベクトル算出部１２３により算出された未知フェーズの時刻区間の特徴量ベクトルに対してクラスタリングを行う（Ｓ１１０）。

【0102】

次に、クラウドアプリケーションデプロイ装置１００の資源使用量推論部１３０は、資源使用量データをパラメータとする資源使用量の推論を行い（Ｓ１１１、（式３）、（式４））、推論により得られた資源使用量に基づいて、アプリケーションのデプロイの対象となるコンテナの資源使用制限値を設定する（Ｓ１１２）。

【0103】

さらに、クラウドアプリケーションデプロイ装置１００は、未知フェーズの時刻区間に属する資源使用量データを蓄積し（図８Ｂ：Ｓ１１３）、未知フェーズ分類モデル学習部１２２は、未知フェーズの資源使用量データが蓄積された段階で機械学習を行い、未知フェーズを対象とするフェーズ分類モデルを作成する（Ｓ１１４）。

【0104】

次に、図９を用いてクラウド設計者が新規のアプリケーションに対するアプリケーションデプロイを行うまでの処理について説明する。
この方法は、コンテナ資源制限およびアプリケーションの入力データ量などのパラメータを網羅的に変えてテスト実行を行っているため、コンテナ資源制限が小さい場合のアプリケーションのデプロイを行うのに有効な方法である。

【0105】

先ず、クラウド設計者がアプリケーションのテストによる性能推論を行うか否かを判定し（Ｓ２０１）、テストによる性能推論を行う場合には（Ｓ２０１：ＹＥＳ）、Ｓ２０２に行き、テストによる性能推論を行わない場合には（Ｓ２０１：ＮＯ）、Ｓ２２０に行く。

【0106】

テストによる性能推論を行う場合には、例えば、サイズを変えたテスト用の入力データの作成などのテストの実行準備を行う（Ｓ２０２）。

【0107】

次に、クラウドアプリケーションデプロイ装置１００は、新規のアプリケーションの入力データサイズおよびパラメータを取得し（Ｓ２０３）、テスト実行を行い（Ｓ２０４）、アプリケーションの実行時間、資源使用量等を測定し、資源使用量データを蓄積する（Ｓ２０５）。

【0108】

そして、Ｓ２０３～Ｓ２０５の処理により、クラウド設計者が網羅的なテストを行った判定するか、または、予め設定された条件により、クラウドアプリケーションデプロイ装置による網羅的なテストを行った判定し（Ｓ２０６）、網羅的なテストが行った判定されたときには（Ｓ２０６：ＹＥＳ）、Ｓ２０７に行き、網羅的なテストが行っていないと判定されたときには（Ｓ２０６：ＮＯ）、Ｓ２０３に戻り、テストを継続する。

【0109】

網羅的なテストが行ったときには、クラウド設計者は、アプリケーションのタイプを分類し（Ｓ２０７）、測定結果に基づいて、そのタイプによる性能推論式を選択する（Ｓ２０８）。アプリケーションのタイプとは、例えば、通信アプリケーション、ＡＩアプリケーション、データ分析アプリケーションなどである。このようにアプリケーションのタイプを分類するのは、アプリケーションのタイプによって、どの説明変数に性能の依存性が大きいかが異なるため、先ず、予め作成された性能推論のための回帰式のタイプを選択するものである。性能推論式の作成は、測定結果に基づいて、コンテナ資源使用制限値と入力データサイズおよびパラメータを説明変数として適用したときのアプリケーションの実行性能を推論する回帰式を作成することによりおこなうことができる。また、このときに、回帰式の中の未知パラメータは、測定結果に対する最小二乗法などを用いて決定することができる。

【0110】

次に、クラウドアプリケーションデプロイ装置１００の性能推論部１３１は、性能推論式に適用するためのパラメータフィッテイングを行い（Ｓ２０９）、選択した性能推論式によってコンテナ使用制限に対する性能推論を行う（Ｓ２１０）。

【0111】

次に、クラウドアプリケーションデプロイ装置１００のデプロイ先探索部１４０は、アプリケーションのデプロイ先の探索を行い（Ｓ２１１）、アプリケーションデプロイ部１４１は、クラウドに対するアプリケーションデプロイを行う（Ｓ２１２）。

【0112】

一方、クラウド設計者がテストによる性能推論を行わない場合も想定される。クラウドで実行されるアプリケーションは、オープンソースを含む既存のマイクロサービスを組み合わせて開発される場合が多い。こうした場合には、構成要素それぞれのコンテナ資源使用制限を網羅的に変えてのテスト実行を行うことなく、アプリケーション実行性能の推論ができることが望ましい。このように運用開始前に推論式の作成を行わない場合には、アプリケーションが余裕を持って動作する資源量を初期設定として割り当て、アプリケーションデプロイを行おうとするものである。

【0113】

テストによる性能推論を行わない場合には、クラウド設計者は、コンテナ用制限を設定し（Ｓ２２０）、クラウドアプリケーションデプロイ装置１００のアプリケーションデプロイ部１４１は、クラウドに対するアプリケーションデプロイを行う（Ｓ２２１）。

【0114】

次に、アプリケーションをコンテナで運用した場合の資源使用量データを採取する（Ｓ２２２）。

【0115】

次に、クラウドアプリケーションデプロイ装置１００の既存のフェーズ分類モデルの特徴量抽出部１１１と、特徴量検証部１１２は、採取した資源使用量データに対して、既知フェーズのフェーズ分類モデルを適用して、特徴量ベクトルの抽出と検証を行う（Ｓ２２３）。

【0116】

次に、クラウドアプリケーションデプロイ装置１００の既存のフェーズ分類モデルの特徴量ベクトルクラスタリング部１１３、クラスタリング検証部１１４は、特徴量ベクトルのクラスタリングとクラスタリングの結果の検証を行う（Ｓ２２４）。

【0117】

そして、採取した資源使用量データに対して、Ｓ２２３、Ｓ２２４の処理をくり返し行い、適用していない既存のフェーズ分類モデルがなくなったときには（Ｓ２２５：ＮＯ）、Ｓ２２７に行く。

【0118】

次に、クラウドアプリケーションデプロイ装置１００の新規アプリケーション既知フェーズ分類部１２１は、新規のアプリケーションの実行された時刻区間を、それぞれのクラスタリングの検証の結果に従い、既知のフェーズか未知のフェーズかに分類する（Ｓ２２７）。

【0119】

ここで、アプリケーションの既知のフェーズに対しては、既に性能推論式が得られているものとする。

【0120】

次に、クラウドアプリケーションデプロイ装置１００は、未知のフェーズに対して性能推論式が作成可能か否かを判定し（Ｓ２２８）、未知のフェーズに対して性能推論式が作成可能なときには（Ｓ２２８：ＹＥＳ）、未知のフェーズに対して性能推論式を作成し（Ｓ２２９）、Ｓ２０７に行き、Ｓ２０８、Ｓ２０９のステップを経過して既知のフェーズの性能推論式と未知のフェーズ性能推論式によりコンテナ使用制限に対する性能推論を行う（Ｓ２１０）。

【0121】

未知のフェーズに対して性能推論式が作成可能なときとは、当該アプリケーションの推論式を作成可能な過去の実行条件と結果データが十分に蓄積されている場合である。

【0122】

未知のフェーズに対して性能推論式が作成不可能なときには（Ｓ２２８：ＮＯ）、Ｓ２２２に戻る。

【0123】

Ｓ２０８、Ｓ２２９における性能推論式は、図１０に示されるスローダウン関数で表現されるものであってもよい。スローダウン関数は、資源の使用量ごとの計算機ノード３０の実行性能低下（スローダウン）を示す関数であり、パラメータとしては、例えば、ＣＰＵ、仮想メモリ容量、ストレージ容量、ネットワーク帯域の使用量であり、値域としては、性能がないときを０％、性能低下が許容値を越えるときを１００％として０～１００％の値をとるアプリケーションの性能低下の割合である。

【0124】

このように、長時間実行の実績があるアプリケーションについてサイジングのためのテスト実行によって、コンテナ資源使用制限が小さい場合にアプリケーション実行時間がスローダウンする割合をスローダウン関数が既に作成されている場合には、既知のフェーズに分類された時刻区間を含む新規アプリケーションについても、同じ推論関数を適用することができる。このようにして、必ずしも全てのアプリケーションに対してサイジングのためのテスト実行を行う必要はなく、実行時間の推論が可能な部分を増やすことができる。

【0125】

次に、図１１を用いてクラウドアプリケーションデプロイ装置のユーザインタフェースについて説明する。
仮に、クラウド設計者がコンテナ資源使用制限値の設定を誤るとメモリ不足等によるアプリケーション異常終了が発生することになるため、性能推論部が算出した推奨値を、ユーザがコンテナをデプロイする前に確認するのが望ましい。したがって、図１１に示したコンテナ資源使用制限値解析画面４００では、推奨値の算出根拠として、アプリケーションの資源使用量の変動パターンを異なるアプリケーションの実行時に現れる既知のフェーズに分類して、当該フェーズの資源使用量データに基づいてコンテナ資源使用制限推奨値を示すことになる。コンテナ資源使用制限値出力画面４００では、新規アプリケーションの資源使用量データの振舞いを、既存のアプリケーションの既知のフェーズと未知のフェーズに分類するとともに、各フェーズへの分類に対する検証の度合い（ｖａｌｉｄａｔｉｏｎ）を示すことによって、新規アプリケーションの資源使用制限の設定値をクラウド設計者が選択する方法をとる。

【0126】

この例では、既存のアプリケーションとして、ａ＿０～ａ＿２があり、未知のアプリケーションとして、ａ＿３、既知フェーズとして、ｐ＿ｃ、ｐ＿ｐ、ｐ＿ｇがあるものとする。

【0127】

コンテナ資源使用制限値解析画面４００は、推奨コンテナサイズ欄４０１、新規アプリケーション資源使用量データパターン表示欄４１０、実行フェーズ表示バー４２１、コンテナ資源使用制限解析表４３１からなる。

【0128】

推奨コンテナサイズ欄４０１には、新規のアプリケーションに対するクラウド設計者がコンテナ資源使用制限解析表４３１から選択したコンテナ資源使用制限値が資源ごとに表示される。図１１では、ＣＰＵの使用制限値として、ｐ＿ｇから選択した「８８」と、仮想メモリの使用制限値として、ｐ＿ｐから選択した「８５」が表示される。

【0129】

新規アプリケーション資源使用量データパターン表示欄４１０は、時刻ごとの新規アプリケーション資源使用量データパターンの推移を表す欄であり、図１１の例では、ＣＰＵ負荷パターン４１１、仮想メモリの使用パターン４１２が表示されている。

【0130】

実行フェーズ表示バー４２１は、新規アプリケーションに対して時刻の推移に連れてのフェーズ分け結果が、例えば、色分けして表示される。

【0131】

コンテナ資源使用制限解析表４３１は、アプリケーション表示行４３１ａ、フェーズ表示行４３１ｂ、ＣＰＵ使用制限値行４３１ｃ、仮想メモリ使用制限値行４３１ｄ、ｖａｌｉｄａｔｉｏｎ行からなり、各々の項目が対応して表示される。

【0132】

アプリケーション表示行４３１ａには、アプリケーションのＩＤまたは名称が表示される。フェーズ表示行４３１ｂには、フェーズのＩＤまたは名称が表示される。ＣＰＵ使用制限値行４３１ｃには、クラウドアプリケーションデプロイ装置１００が算出したＣＰＵの使用制限値が表示される。仮想メモリ使用制限値行４３１ｄには、クラウドアプリケーションデプロイ装置１００が算出した仮想メモリの使用制限値が表示される。ｖａｌｉｄａｔｉｏｎ行は、各フェーズへの分類に対する検証の度合いが表示される。

【0133】

本実施形態によれば、新規アプリケーションに対しても、資源使用量データから得られる特徴量ベクトルを検証することにより、既知のフェーズと未知のフェーズに分類することができ、機械学習を経た既知のフェーズの特徴量ベクトルを合成して精度よく、未知のフェーズの特徴量ベクトルを生成することができる。

【0134】

これにより、効率的に未知のフェーズの特徴量ベクトルを得ることができ、これにより、資源使用量の推定の精度を向上させることができる。

【0135】

〔実施形態２〕
以下、本発明に係る実施形態２を、図１２を用いて説明する。
本実施形態のクラウドシステムは、複数のユーザ組織１０００（図１２では、１０００α、１０００β、１０００γ、…と表記）において、それぞれが複数のクラウド環境１１００（図１２では、１１００αＡ、１１００αＢ、…と表記）を有しており、それぞれのユーザ組織１０００が実施形態１のクラウドアプリケーションデプロイ装置１００を有する構成である。

【0136】

そして、それぞれのクラウド環境１１００は、アプリケーション１１３２を実行するためのコンテナ１１３１と記憶部１１４０を有している。記憶部１１４０には、そのクラウドにおける資源使用利用ＤＢ１１４１が格納されている。

【0137】

このシステムによれば、コンテナの最適配置を行うクラウドアプリケーションデプロイ装置１００は、ユーザが属する組織ごとに設けられ、当該組織のユーザが複数のクラウドで実行したそれぞれのアプリケーションの資源使用量ＤＢの格納されている資源使用量データを収集して、実施形態１で示したように、フェーズ分類モデルと資源使用量およびアプリケーション性能の推論式の作成を行う。このような構成をとることによって、ユーザ組織ごと大規模なデータ分析を行う組織における各クラウドのコンテナの最適な配置を実現することができる。

【符号の説明】

【0138】

１…クライアント、５…ネットワーク、１０…クラウド環境、１００…クラウドアプリケーションデプロイ装置、２０…管理ノード、２１…アプリケーション実行管理部、２２…資源使用量監視部、３０…計算機ノード、３１…コンテナ、３２…アプリケーション、３３…コンテナ監視部、
１０１…データ前処理部、１１０…フェーズ分類モデル部、１２０…未知フェーズ分類部、１２１…新規アプリケーション既知フェーズ分類部、１２２…未知フェーズ分類モデル部、１２３…未知フェーズ特徴量ベクトル算出部、１２４…未知フェーズ特徴量ベクトルクラスタリング部、１３０…資源使用量推論部、１３１…性能推論部、１４０…デプロイ先探索部、１４１…アプリケーションデプロイ部、１５０…記憶部

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8A】

【図8B】

【図9】

【図10】

【図11】

【図12】