JP2023078639A - 情報処理装置及び情報処理方法 - Google Patents

Abstract

【課題】マイクロサービスアーキテクチャで構築されたアプリケーションのサービス品質の目標に応じて、使用するリソースの量を最適化可能な技術を提供する。【解決手段】本開示の一側面に係る情報処理装置は、訓練データ及び正解ラベルの組み合わせによりそれぞれ構成される複数のデータセットを取得し、取得された複数のデータセットを使用して、推定モデルの機械学習を実施する。訓練データは、マイクロサービスアーキテクチャで構築されたアプリケーションに対するワークロード情報、及び各コンポーネントに使用されるリソースについてのリソース使用情報を含む。正解ラベルは、アプリケーションのサービス品質の真値を示す。機械学習は、各データセットについて、訓練データに基づき算出されるサービス品質の推定値が正解ラベルにより示される真値に適合するように推定モデルを訓練することにより構成される。【選択図】図１Ａ

Description

本開示は、マイクロサービスアーキテクチャで構築されたアプリケーションに使用するリソースの量を最適化する技術に関する。

近年、アプリケーションシステムの開発及び運用において、マイクロサービスアーキテクチャを採用する例が増えてきている。マイクロサービスアーキテクチャは、サービスを構成する各要素をマイクロサービスと呼ばれる独立したコンポーネントとして実装する手法である。非特許文献１では、個々のコンポーネントによるリソースの使用状況（例えば、プロセッサ／メモリの使用率）に目標値を設けて、その目標値に使用状況が近付くようにリソースの量（具体的には、コンテナを展開するポッドの数）を調整する方法が提案されている。

"Horizontal Pod Autoscaler｜Kubernetes"、［online］、［令和３年１１月５日検索］、インターネット＜URL: https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/＞

本開示の目的は、マイクロサービスアーキテクチャで構築されたアプリケーションのサービス品質の目標に応じて、使用するリソースの量を最適化可能な技術を提供することである。

本開示の第１の態様に係る情報処理装置は、訓練データ及び正解ラベルの組み合わせによりそれぞれ構成される複数のデータセットを取得することと、取得された複数のデータセットを使用して、推定モデルの機械学習を実施することと、を実行するように構成された制御部を備える。前記訓練データは、学習対象の環境における、マイクロサービスアーキテクチャで構築されたアプリケーションに対するワークロード情報、及び前記アプリケーションに含まれる各コンポーネントに使用されるリソースについてのリソース使用情報を含む。前記正解ラベルは、前記アプリケーションのサービス品質の真値を示すように構成される。前記機械学習は、前記各データセットについて、前記推定モデルにより前記訓練データに基づき算出される前記サービス品質の推定値が前記正解ラベルにより示される真値に適合するように前記推定モデルを訓練することにより構成される。

本開示の第２の態様に係る情報処理装置は、推定対象の環境における、マイクロサービスアーキテクチャで構築されたアプリケーションに対するワークロード情報、及び前記アプリケーションに含まれる各コンポーネントに使用されるリソースについてのリソース使用情報を含む対象データを取得することと、訓練済みの推定モデルを使用することで、取得された前記対象データに基づき、前記アプリケーションのサービス品質の推定値を算出することと、算出された前記サービス品質の推定値が適正に目標を満たさない場合に、所定の最適化手法により、前記訓練済みの推定モデルにより算出される前記サービス品質の推定値に基づき前記目標に対して前記リソースの量を最適化することと、前記最適化の結果に従って、前記各コンポーネントに使用される前記リソースの量を調整することと、を実行するように構成された制御部を備える。

本開示の第３の態様に係る情報処理方法は、コンピュータによって実行される情報処理方法であって、推定対象の環境における、マイクロサービスアーキテクチャで構築されたアプリケーションに対するワークロード情報、及び前記アプリケーションに含まれる各コンポーネントに使用されるリソースについてのリソース使用情報を含む対象データを取得することと、訓練済みの推定モデルを使用することで、取得された前記対象データに基づき、前記アプリケーションのサービス品質の推定値を算出することと、算出された前記サービス品質の推定値が適正に目標を満たさない場合に、所定の最適化手法により、前記訓練済みの推定モデルにより算出される前記サービス品質の推定値に基づき前記目標に対して前記リソースの量を最適化することと、前記最適化の結果に従って、前記各コンポーネントに使用される前記リソースの量を調整することと、を含む。

本開示によれば、マイクロサービスアーキテクチャで構築されたアプリケーションのサービス品質の目標に応じて、使用するリソースの量を最適化することができる。

図１Ａは、本開示が適用される場面の一例を模式的に示す。 図１Ｂは、マイクロサービスアーキテクチャで構築されるアプリケーションの一例を模式的に示す。 図２は、実施の形態に係るサーバ装置のハードウェア構成の一例を模式的に示す。 図３は、実施の形態に係るサーバ装置のソフトウェア構成の一例を模式的に示す。 図４は、実施の形態に係るサーバ装置による機械学習の処理過程の一例を模式的に示す。 図５は、実施の形態に係るサーバ装置によるリソース量の最適化の処理過程の一例を模式的に示す。 図６は、実施の形態に係るサーバ装置による機械学習の処理手順の一例を示すフローチャートである。 図７は、実施の形態に係るサーバ装置によるリソース量を最適化する処理手順の一例を示すフローチャートである。 図８は、実施例及び比較例によりリソース量を最適化したマイクロサービスアーキテクチャのアプリケーションの第１サンプルを示す。 図９は、実施例及び比較例によりリソース量を最適化したマイクロサービスアーキテクチャのアプリケーションの第２サンプルを示す。

非特許文献１で提案される方法によれば、コンポーネント（マイクロサービス）毎に使用されるリソースの量を目標値に近付くように調整することで、アプリケーション全体のサービス品質（Quality of Service）を担保することができる。例えば、個々のコンポーネントに使用されるポッド数を増やすことで、アプリケーション全体のサービス品質の向上を図ることができる。

しかしながら、コンポーネントの数が増え、アプリケーションの構成が複雑になればなるほど、各コンポーネントがアプリケーション全体のサービス品質に与える影響が不明となる。また、各コンポーネントは、アプリケーションのサービス品質に関して異なる特徴曲線を持ち得る。すなわち、少量のリソースの割り当てでサービス品質を改善可能なコンポーネントも存在すれば、多くのリソースを割り当てないとサービス品質を改善できないコンポーネントも存在し得る。

したがって、アプリケーション全体のサービス品質が適正に目標を満たすように、コンポーネント毎に目標値を最適に設定するのは困難である。また、目標値を一律に決定してしまうと、コンポーネントによっては、無駄なリソースの配備が生まれてしまう。つまり、従来の方法では、マイクロサービスアーキテクチャで構築されたアプリケーション全体のサービス品質の目標に応じて、各コンポーネントに使用するリソースの量を最適化することは困難である。

これに対して、本開示の第１の態様に係る情報処理装置は、訓練データ及び正解ラベルの組み合わせによりそれぞれ構成される複数のデータセットを取得することと、取得された複数のデータセットを使用して、推定モデルの機械学習を実施することと、を実行するように構成された制御部を備える。訓練データは、学習対象の環境における、マイクロサービスアーキテクチャで構築されたアプリケーションに対するワークロード情報、及び当該アプリケーションに含まれる各コンポーネントに使用されるリソースについてのリソース使用情報を含む。正解ラベルは、アプリケーションのサービス品質の真値を示すように構成される。機械学習は、各データセットについて、推定モデルにより訓練データに基づき算出されるサービス品質の推定値が正解ラベルにより示される真値に適合するように推定モデルを訓練することにより構成される。

本開示の第２の態様に係る情報処理装置は制御部を備える。制御部は、推定対象の環境における、マイクロサービスアーキテクチャで構築されたアプリケーションに対するワークロード情報、及びアプリケーションに含まれる各コンポーネントに使用されるリソースについてのリソース使用情報を含む対象データを取得することと、訓練済みの推定モデルを使用することで、取得された対象データに基づき、アプリケーションのサービス品質の推定値を算出することと、算出されたサービス品質の推定値が適正に目標を満たさない場合に、所定の最適化手法により、前記訓練済みの推定モデルにより算出される前記サービス品質の推定値に基づき前記目標に対して前記リソースの量を最適化することと、最適化の結果に従って、各コンポーネントに使用されるリソースの量を調整することと、を実行するように構成される。

本開示の第１の態様に係る情報処理装置によれば、ワークロード情報及びリソースについてのリソース使用情報からアプリケーションのサービス品質を推定する能力を獲得した訓練済みの推定モデルを生成することができる。この訓練済みの推定モデルによれば、ワークロードの状態及び各コンポーネントへのリソースの配備が与えられると、その条件におけるアプリケーション全体のサービス品質を推定することができる。つまり、この訓練済みの推定モデルを使用すれば、ワークロードの状態に応じて、各コンポーネントへのリソースの配備とアプリケーションのサービス品質との間の対応関係を推測することができる。したがって、サービス品質の目標を与えることで、任意の最適化手法により、その目標に応じた各コンポーネントに対するリソースの最適な量を導出することができる。

よって、本開示の第２の態様に係る情報処理装置によれば、この訓練済みの推定モデルを使用することで、マイクロサービスアーキテクチャで構築されたアプリケーションのサービス品質の目標に応じて、各コンポーネントに使用するリソースの量を最適化することができる。その結果、アプリケーションのサービス品質の維持にかかるコスト（例えば、消費電力等）の低減を図ることができる。本開示の第１の態様に係る情報処理装置によれば、そのようなリソースの割り当ての最適化に使用可能な訓練済みの推定モデルを生成することができる。

以下、本開示の一側面に係る実施の形態（以下、「本実施形態」とも表記する）を、図面に基づいて説明する。ただし、以下で説明する本実施形態は、あらゆる点において本開
示の例示に過ぎない。本開示の範囲を逸脱することなく種々の改良又は変形が行われてよい。本開示の実施にあたって、実施形態に応じた具体的構成が適宜採用されてもよい。なお、本実施形態において登場するデータを自然言語により説明しているが、より具体的には、コンピュータが認識可能な疑似言語、コマンド、パラメータ、マシン語等で指定される。

［１ 適用例］
図１Ａは、本開示を適用した場面の一例を模式的に例示する。図１Ｂは、マイクロサービスアーキテクチャで構築されるアプリケーションＡＰの一例を模式的に示す。

本実施形態に係るサーバ装置１は、アプリケーションＡＰを実行すると共に、推定モデル５の機械学習を実施し、生成された訓練済みの推定モデル５を使用して、リソース配備の最適化を遂行するように構成される１台以上のコンピュータである。サーバ装置１は、上記第１の態様及び第２の態様の情報処理装置の一例である。

アプリケーションＡＰは、マイクロサービスアーキテクチャで構築され、複数のコンポーネントＡＳを含む。各コンポーネントＡＳは、アプリケーションプロセスを個別に実行するように構成される。これにより、各コンポーネントＡＳは、マイクロサービスを個別に提供する。各コンポーネントＡＳは、アプリケーションＡＰにより提供する情報処理、サービス設計、仕様等に応じて、フロントエンドからバックエンドにかけて接続関係を適宜有してよい。フロントエンドからバックエンドまでの経路をサービスチェインと称してよい。各コンポーネントＡＳ間では、データの受け渡しが適宜行われてよい。

各コンポーネントＡＳはコンテナ化されてよい。すなわち、各コンポーネントＡＳは、コンテナ上で実行されてよい。コンテナは、１つ以上のコンポーネントを含むように構成されてよい。マイクロサービスアーキテクチャで構築されたアプリケーションＡＰの運用には任意のソフトウェアが用いられてよい。一例として、Kubernetes等の公知のソフトウェアが用いられてよい。

運用の一例として、サーバ装置１では、１つ以上のクラスタＫが構築されてよい。クラスタＫは、マスタＫＭ及び１つ以上のノードＫＮを備え、アプリケーションＡＰを実行するように構成される。マスタＫＭは、オペレータ等により設定された内容を維持するようにノードＫＮに指示を与えることで、クラスタＫの管理を行うように構成される。ノードＫＮは、各コンポーネントＡＳのアプリケーションプロセスの実行環境を提供する。ノードＫＮは、１つ以上のポッドを実行するように構成されてよく、ポッドは、１つ以上のコンテナＫＣを展開するように構成されてよい。マスタＫＭ及びノードＫＮは、物理マシン又は仮想マシンにより構成されてよい。

図１Ｂに示されるとおり、アプリケーションＡＰを構成する各コンポーネントＡＳは、任意のノードＫＮ及び任意のコンテナＫＣ上で実行されてよい。各コンポーネントＡＳを実行するコンテナＫＣの数はコンポーネントＡＳ毎に決定されてよい。また、１つのノードＫＮ上で展開されるコンテナＫＣの数は適宜決定されてよく、１つのコンテナＫＣ上で実行されるコンポーネントＡＳの数も適宜決定されてよい。

アプリケーションＡＰは、マイクロサービスアーキテクチャで構築されていればよく、その内容は、特に限定されなくてよい。アプリケーションＡＰにより実行される情報処理及び提供されるサービスは、特に限定されなくてよく、実施の形態に応じて適宜選択されてよい。サーバ装置１の名称は、アプリケーションＡＰにより実行される情報処理の内容に応じて適宜変更されてよい。

図１Ａの例では、アプリケーションＡＰは、ネットワークを介して１つ以上の端末Ｔに対して情報処理を提供する。一例では、端末Ｔは、車両に搭載される車載装置であってよい。車載装置は、専用に設計されたコンピュータであってもよいし、或いはスマートフォン等の可搬性を有する汎用のコンピュータであってもよい。アプリケーションＡＰは、車載装置から得られるデータを解析して交通状況を解析する、自動運転の指示を決定する等の車両の運行に関する情報処理を実行するように構成されてよい。他の一例では、端末Ｔは、スマートフォン、その他携帯端末、タブレットＰＣ（personal computer）、汎用の
ＰＣ等であってよい。アプリケーションＡＰは、例えば、ソーシャルネットワーキングサービス、ＥＣ（electronic commerce）サイト、コンテンツ（例えば、音楽、動画、ゲー
ム等）の配信サービス等を提供するウェブアプリケーションであってよい。

（学習段階）
学習段階において、本実施形態に係るサーバ装置１は、複数のデータセット３を取得する。そして、サーバ装置１は、取得された複数のデータセット３を使用して、推定モデル５の機械学習を実施する。

各データセット３は、訓練データ３１及び正解ラベル３３の組み合わせにより構成される。訓練データ３１は、ワークロード情報３１１、リソース使用情報３１３及びサービスチェイン情報３１５を含むように構成される。ワークロード情報３１１は、学習対象の環境における、マイクロサービスアーキテクチャで構築されたアプリケーションに対するワークロードの状態を示すように構成される。リソース使用情報３１３は、当該アプリケーションに含まれる各コンポーネントに対するリソースの使用状況（各コンポーネントに使用されるリソースの量）を示すように構成される。サービスチェイン情報３１５は、当該アプリケーションに含まれる各コンポーネントの接続関係（例えば、図１Ｂ）を示すように構成される。正解ラベル３３は、対応する訓練データ３１により示される状況（その時点又は未来の時点）におけるアプリケーションのサービス品質の真値を示すように構成される。

なお、この機械学習に使用されるデータセット３を収集する対象となるアプリケーションを「学習対象アプリケーション」とも称する。本実施形態に係るアプリケーションＡＰは、学習対象アプリケーションの一例である。各データセット３は、クラスタＫによるアプリケーションＡＰの実行実績から収集されてよい。

機械学習は、各データセット３について、推定モデル５により訓練データ３１に基づき算出されるサービス品質の推定値が正解ラベル３３により示される真値に適合するように推定モデル５を訓練することにより構成される。この機械学習の処理により、アプリケーションに対するワークロード情報、リソースについてのリソース使用情報、及びサービスチェイン情報から当該アプリケーションのサービス品質を推定する能力を獲得した訓練済みの推定モデル５を生成することができる。生成された訓練済みの推定モデル５は、推論段階で使用される。なお、推定することは、回帰すること又は識別することにより構成されてよい。推定値は、連続値又は離散値により構成されてよい。推定することは、予測することを含んでよい。この機械学習の処理は、クラスタＫ上で運用されるアプリケーションＡＰに対してオフラインで実行されてよい。

（推論段階）
推論段階において、本実施形態に係るサーバ装置１は、ワークロード情報４１、リソース使用情報４３、及びサービスチェイン情報４５を含む対象データ４を取得する。ワークロード情報４１は、推定対象の環境における、マイクロサービスアーキテクチャで構築されたアプリケーションに対するワークロードの状態を示すように構成される。リソース使用情報４３は、当該アプリケーションに含まれる各コンポーネントに対するリソースの使
用状況（各コンポーネントに使用されるリソースの量）を示すように構成される。サービスチェイン情報４５は、当該アプリケーションに含まれる各コンポーネントの接続関係を示すように構成される。

サーバ装置１は、訓練済みの推定モデル５を使用することで、取得された対象データ４に基づき、当該アプリケーションのサービス品質の推定値を算出する。サーバ装置１は、算出されたサービス品質の推定値が目標（Target QoS）を満たすか否かを判定する。目標は、任意の方法（例えば、オペレータによる指示）で予め設定されてよい。算出されたサービス品質の推定値が適正に目標を満たさない場合、サーバ装置１は、所定の最適化手法によって、訓練済みの推定モデル５により算出されるサービス品質の推定値に基づき目標に対して各コンポーネントに使用されるリソースの量を最適化する。そして、サーバ装置１は、最適化の結果に従って、各コンポーネントに使用されるリソースの量を調整する。

なお、この訓練済みの推定モデル５を使用してサービス品質を推定し、推定結果に基づいてリソースの量を最適化する対象となるアプリケーションを「推定対象アプリケーション」とも称する。本実施形態に係るアプリケーションＡＰは、推定対象アプリケーションの一例でもある。サーバ装置１は、クラスタＫによりアプリケーションＡＰを運用しながら、上記リソースの量を最適化する処理をオンラインで実行してよい。これにより、アプリケーションＡＰの実行に使用されるクラスタＫのリソース（ノードＫＮ、コンテナＫＣ）の量を調整してよい。リソースは、例えば、プロセッサ・リソース、メモリ・リソース等の情報処理に使用される資源である。プロセッサは、実プロセッサ又は仮想プロセッサであってよい。メモリは、実メモリ又は仮想メモリであってよい。リソース量の調整は、例えば、ノードＫＮ単位、ポッド単位、コンテナＫＣ単位等の任意の単位で行われてよい。

（効果）
以上のとおり、本実施形態の推論段階におけるサーバ装置１の処理によれば、訓練済みの推定モデル５を使用することで、マイクロサービスアーキテクチャで構築されたアプリケーションＡＰのサービス品質の目標に応じて、各コンポーネントＡＳに使用するリソースの量を最適化することができる。その結果、アプリケーションＡＰのサービス品質の維持にかかるコストの低減を図ることができる。本実施形態の学習段階におけるサーバ装置１の処理によれば、そのようなリソース配備の最適化に使用可能な訓練済みの推定モデル５を生成することができる。

（その他）
サービスチェイン情報（３１５、４５）は、各コンポーネントＡＳの接続関係をグラフ形式で表現するように構成されてよい。グラフは、エッジ及びノードによりデータを表現する。各コンポーネントＡＳは、エッジにより表現されてよく、各コンポーネントＡＳ間の接続関係はノードで表現されてよい。グラフのデータ形式には、例えば、行列等の公知のデータ形式が用いられてよい。これに応じて、推定モデル５は、グラフニューラルネットワークを含むように構成されてよい。グラフニューラルネットワークの構造には、例えば、参考文献（Scarselli, Franco, et al、"The graph neural network model"、 IEEE transactions on neural networks 20.1 (2008): 61-80、［online］、［令和３年１１月５日検索］、インターネット＜URL: https://ieeexplore.ieee.org/abstract/document/4700287＞）等で提案される公知の構造が用いられてよい。これにより、サービスチェイン情報により示される各コンポーネントＡＳの接続関係をサービス品質の推定処理に適切に反映することができ、その結果、推定精度の向上を図ることができる。

サービス品質は、アプリケーションＡＰの遅延時間、実行時間、及び正常に処理された程度の少なくともいずれかに基づいて算定されてよい。遅延時間は、データ転送等の要求
からそれに対する返送までにかかる時間（レイテンシ）であってよい。一例として、遅延時間は、自動運転の指示等のリアルタイム処理におけるレイテンシであってよい。実行時間は、アプリケーションＡＰ全体又は一部の処理にかかる時間であってよい。一例として、実行時間は、マップ系、リデュース系等のバッチ処理にかかる時間であってよい。正常に処理された程度は、アプリケーションＡＰの処理が正常に実行された程度を示すように適宜構成されてよい。正常に処理された程度は、エラーの発生した（正常に処理されなかった）程度により表現されてもよい。程度は、例えば、回数、比率等で表現されてよい。一例として、アプリケーションＡＰがＨＴＴＰアプリケーションである場合、正常に処理された程度は、ユーザ（端末Ｔ）からのＨＴＴＰリクエストを単位時間当たりに正常に処理して返信した比率により表現されてよい。これらによれば、サービス品質を適切に評価することができ、その結果、リソース量の最適化を適切に遂行することができる。

ワークロード情報（３１１、４１）は、アプリケーションＡＰに対するトランザクション量、ユーザからのメッセージ量、及びデータの転送量の少なくともいずれかを含むように構成されてよい。トランザクション量は、例えば、端末Ｔから受信するデータの量、端末Ｔからの要求される処理の量等により算定されてよい。メッセージ量は、例えば、端末Ｔからの要求の数等により算定されてよい。一例として、アプリケーションＡＰがＨＴＴＰアプリケーションである場合、メッセージ量は、ＨＴＴＰリクエストの量であってよい。メッセージ量は、メッセージの総量で算定されてもよいし、ＡＰＩ（Application Programming Interface）毎に算定されてもよい。データの転送量は、例えば、画像ファイル
等のデータを送受信する量により算定されてよい。これらによれば、ワークロードの状態を適切に表現することができ、その結果、リソース量の最適化を適切に遂行することができる。

リソース使用情報（３１３、４３）は、アプリケーションＡＰに含まれる各コンポーネントＡＳに割り当てられたプロセッサの使用量、メモリの使用量、及びネットワーク帯域の使用量の少なくともいずれかを含むように構成されてよい。プロセッサは、実プロセッサ又は仮想プロセッサであってよい。実プロセッサは、例えば、ＣＰＵ（Central Processing Unit）、マイクロプロセッサ、ＦＰＧＡ（field-programmable gate array）、ＧＰＵ（Graphics Processing Unit）等を含んでよい。メモリは、実メモリ又は仮想メモリであってよい。実メモリは、例えば、ストレージ（ハードディスクドライブ、ソリッドステートドライブ等）、ＲＡＭ（Random Access Memory）、キャッシュメモリ（例えば、Last
Level Cache）等を含んでよい。一例として、メモリの使用量は、ストレージ／ＲＡＭに対する入出力量、キャッシュメモリの帯域幅、キャッシュメモリのキャパシティ量等により計測されてよい。ネットワーク帯域の使用量は、ネットワークを介したデータの入出力量により計測されてよい。各使用量は、任意の単位で表現されてよい。これらによれば、リソースの使用状況を適切に表現することができ、その結果、リソース量の最適化を適切に遂行することができる。

なお、本実施形態では、学習対象アプリケーション及び推定対象アプリケーションは、アプリケーションＡＰで共通である。一例では、アプリケーションＡＰの構成が学習段階と推論段階とで一致していることで、学習対象アプリケーション及び推定対象アプリケーションは、互いに同一であってよい。しかしながら、学習対象アプリケーション及び推定対象アプリケーションは、必ずしも互いに同一でなければならない訳ではない。他の一例では、学習対象アプリケーション及び推定対象アプリケーションは互いに異なっていてもよい。例えば、学習段階及び推論段階でアプリケーションＡＰのコンポーネントＡＳの構成が変更されることで、学習対象アプリケーション及び推定対象アプリケーションは互いに異なっていてもよい。或いは、学習対象アプリケーションと推定対象アプリケーションとは互いに別々のアプリケーション（例えば、互いに異なるサーバ装置で運用される別のアプリケーション）であってよい。この場合、学習対象アプリケーションのコンポーネン
ト構成と推定対象アプリケーションのコンポーネント構成は、互いに一致していてもよいし、或いは互いに異なっていてもよい。

また、本実施形態では、アプリケーションＡＰ、推定モデル５の機械学習（訓練済みの推定モデル５の生成）、及び訓練済みの推定モデル５を使用したリソース配備の最適化の全ての処理をサーバ装置１が実行する。しかしながら、各処理は、必ずしも同一の装置で実行されなければならない訳ではない。各処理の少なくともいずれか又は少なくとも一部は、サーバ装置１以外のコンピュータで実行されてよい。一例として、アプリケーションＡＰ、推定モデル５の機械学習、及び訓練済みの推定モデル５を使用したリソース配備の最適化の各処理は互いに異なる装置で実行されてよい。他の一例として、推定モデル５の機械学習及び訓練済みの推定モデル５を使用したリソース配備の最適化の処理は同一のサーバ装置で実行されてよく、アプリケーションＡＰは別のサーバ装置で実行されてよい。この場合、各サーバ装置は、１台以上のコンピュータにより構成されてよい。

また、本実施形態では、サーバ装置１は、複数のコンピュータで構成されてよい。この場合、アプリケーションＡＰ、推定モデル５の機械学習、及び訓練済みの推定モデル５を使用したリソース配備の最適化の各処理は、少なくとも部分的に同一のコンピュータにより実行されてもよいし、或いは互いに異なるコンピュータで実行されてもよい。各処理を実行するコンピュータは適宜選択されてよい。

［２ 構成例］
［ハードウェア構成例］
図２は、本実施形態に係るサーバ装置１のハードウェア構成の一例を模式的に示す。図２に示されるとおり、本実施形態に係るサーバ装置１は、制御部１１、記憶部１２、通信インタフェース１３、入力装置１４、出力装置１５、及びドライブ１６が電気的に接続されたコンピュータである。

制御部１１は、ハードウェアプロセッサであるＣＰＵ、ＲＡＭ、ＲＯＭ（Read Only Memory）、キャッシュメモリ等を含み、プログラム及び各種データに基づいて情報処理を実行するように構成される。制御部１１（ＣＰＵ）は、プロセッサ・リソースの一例である。記憶部１２は、例えば、ハードディスクドライブ、ソリッドステートドライブ等で構成される。記憶部１２は、メモリ・リソースの一例である。本実施形態では、記憶部１２は、オペレーティングシステム８０、プログラム８１、学習結果データ１２５等の各種情報を記憶する。

オペレーティングシステム８０は、サーバ装置１のハードウェアを制御するための基本的な機能を提供する。オペレーティングシステム８０の種類は、特に限定されなくてよく、実施の形態に応じて適宜選択されてよい。プログラム８１は、推定モデル５の機械学習の情報処理（後述の図６）及び訓練済みの推定モデル５を使用したリソース配備の最適化の情報処理（後述の図７）をサーバ装置１に実行させるためのプログラムである。プログラム８１は、当該情報処理の一連の命令を含む。推定モデル５の機械学習の情報処理に関する命令部分及びリソース配備の最適化の情報処理に関する命令部分はそれぞれ別々のプログラムとして保持されてもよい。学習結果データ１２５は、機械学習により生成された訓練済みの推定モデル５に関する情報を示す。

通信インタフェース１３は、例えば、有線ＬＡＮ（Local Area Network）モジュール、無線ＬＡＮモジュール等であり、ネットワークを介した有線又は無線通信を行うためのインタフェースである。サーバ装置１は、通信インタフェース１３を介して、他のコンピュータとの間でデータ通信を行ってよい。

入力装置１４は、例えば、マウス、キーボード等の入力を行うための装置である。出力装置１５は、例えば、ディスプレイ、スピーカ等の出力を行うための装置である。オペレータは、入力装置１４及び出力装置１５を利用することで、サーバ装置１を操作することができる。入力装置１４及び出力装置１５は、例えば、タッチパネルディスプレイ等により一体的に構成されてもよい。

ドライブ１６は、記憶媒体９１に記憶されたプログラム等の各種情報を読み込むための装置である。上記プログラム８１は、記憶媒体９１に記憶されていてもよい。記憶媒体９１は、コンピュータその他装置、機械等が、記憶されたプログラム等の各種情報を読み取り可能なように、当該プログラム等の情報を、電気的、磁気的、光学的、機械的又は化学的作用によって蓄積する媒体である。サーバ装置１は、プログラム８１を記憶媒体９１から取得してよい。

ここで、図２では、記憶媒体９１の一例として、ＣＤ、ＤＶＤ等のディスク型の記憶媒体を例示している。しかしながら、記憶媒体９１の種類は、ディスク型に限定される訳ではなく、ディスク型以外であってもよい。ディスク型以外の記憶媒体として、例えば、フラッシュメモリ等の半導体メモリを挙げることができる。ドライブ１６の種類は、記憶媒体９１の種類に応じて適宜選択されてよい。

なお、サーバ装置１の具体的なハードウェア構成に関して、実施形態に応じて、適宜、構成要素の省略、置換及び追加が可能である。例えば、制御部１１は、複数のハードウェアプロセッサを含んでもよい。ハードウェアプロセッサは、マイクロプロセッサ、ＦＰＧＡ、ＧＰＵ等で構成されてよい。記憶部１２は、制御部１１に含まれるＲＡＭ及びＲＯＭにより構成されてもよい。入力装置１４、出力装置１５及びドライブ１６の少なくともいずれかは省略されてもよい。サーバ装置１は、複数台のコンピュータにより構成されてよい。この場合、各コンピュータのハードウェア構成は、一致していてもよいし、或いは一致していなくてもよい。サーバ装置１は、提供されるサービス専用に設計された情報処理装置の他、汎用の情報処理装置等であってよい。

［ソフトウェア構成例］
図３は、本実施形態に係るサーバ装置１のソフトウェア構成の一例を模式的に示す。サーバ装置１の制御部１１は、記憶部１２に記憶されたプログラム８１をＲＡＭに展開する。そして、制御部１１は、ＲＡＭに展開されたプログラム８１に含まれる命令をＣＰＵにより実行する。これにより、図３に示されるとおり、本実施形態に係るサーバ装置１は、オペレーティングシステム８０上でアプリケーションＡＰを実行すると共に、機械学習部６１及び最適化実行部６３をソフトウェアモジュールとして備えるコンピュータとして動作する。すなわち、本実施形態では、サーバ装置１の各ソフトウェアモジュールは、制御部１１（ＣＰＵ）により実現される。なお、図３の例では、機械学習部６１及び最適化実行部６３は、アプリケーションＡＰに含まれる１つのコンポーネントＡＳとして実装される。

＜機械学習部＞
機械学習部６１は、推定モデル５の機械学習に関する情報処理を実行するように構成される。本実施形態では、機械学習部６１は、設定受付部６１１、データ取得部６１２、学習処理部６１３、保存処理部６１４及び通信部６１５を備える。設定受付部６１１は、推定モデル５の機械学習の条件（例えば、推定モデル５の構成、パラメータの初期値、反復回数等）に関する設定を受け付けるように構成される。データ取得部６１２は、訓練データ３１及び正解ラベル３３の組み合わせによりそれぞれ構成される複数のデータセット３を取得するように構成される。学習処理部６１３は、取得された複数のデータセット３を使用して、推定モデル５の機械学習を実施するように構成される。保存処理部６１４は、
機械学習により生成された訓練済みの推定モデル５に関する情報を学習結果データ１２５として生成し、生成された学習結果データ１２５を任意の記憶領域に保存するように構成される。学習結果データ１２５は、訓練済みの推定モデル５を再生するための情報を含むように適宜構成される。通信部６１５は、マスタＫＭ、他のコンポーネントＡＳ等とデータの受け渡しを行うように構成される。

（機械学習方法の一例）
図４は、機械学習部６１による推定モデル５の機械学習の処理過程の一例を模式的に示す。推定モデル５は、推定処理を実行するための１つ以上の演算パラメータであって、機械学習により値が調整される１つ以上の演算パラメータを有する機械学習モデルにより構成される。サービス品質の推定値を算出する演算処理を実行可能であれば、推定モデル５に採用する機械学習モデルの種類、構成、及び構造は、特に限定されなくてよく、実施の形態に応じて適宜決定されてよい。

一例として、推定モデル５は、ニューラルネットワークにより構成されてよい。この場合、各ノード（ニューロン）間の結合の重み、各ノードの閾値等が、演算パラメータの一例である。ニューラルネットワークの種類及び構造（例えば、各層の種類、層の数、各層のノードの数、ノードの接続関係等）は、実施の形態に応じて適宜決定されてよい。推定モデル５は、例えば、全結合型ニューラルネットワーク、畳み込みニューラルネットワーク、再帰型ニューラルネットワーク等により構成されてよい。本実施形態では、サービスチェイン情報（３１５、４５）は、各コンポーネントＡＳの接続関係をグラフ形式で表現するように構成されてよい。これに応じて、推定モデル５は、入力されるデータのうち少なくともサービスチェイン情報（３１５、４５）を処理する構成要素としてグラフニューラルネットワークを含むように構成されてよい。

機械学習に使用される各データセット３は、クラスタＫによるアプリケーションＡＰの実行実績から収集されてよい。一例では、各データセット３は、データ取得部６１２により収集されてよい。他の一例では、各データセット３は、他のコンポーネント又はサーバ装置１以外の他のコンピュータにより収集されてよい。この場合、データ取得部６１２は、他のコンポーネント又は他のコンピュータにより収集された各データセット３を任意の方法で取得してよい。各データセット３は、コンピュータの動作により自動的に生成されてもよいし、或いは少なくとも部分的にオペレータの操作を含むことで主導的に生成されてもよい。

各データセット３は、訓練データ３１及び正解ラベル３３の組み合わせにより構成される。本実施形態では、訓練データ３１は、ワークロード情報３１１、リソース使用情報３１３、及びサービスチェイン情報３１５を含むように構成される。正解ラベル３３は、関連付けられる訓練データ３１の各情報（３１１、３１３、３１５）により示される状況におけるアプリケーションＡＰのサービス品質の真値を示すように構成される。正解ラベル３３により示される真値は、アプリケーションＡＰ全体のサービス品質に関するものであってよい。サービス品質は、遅延時間、実行時間、及び正常に処理された程度の少なくともいずれかに基づいて算定されてよい。真値は、各情報（３１１、３１３、３１５）に対応して、上記少なくともいずれかの指標に基づいてアプリケーションＡＰのサービス品質を測定することで得られてよい。

学習処理部６１３は、機械学習の処理として、各データセット３について、訓練データ３１を与えることで推定モデル５から得られる出力（サービス品質の推定値）が正解ラベル３３に適合するように推定モデル５を訓練する。すなわち、学習処理部６１３は、各データセット３の訓練データ３１を入力データとして使用し、正解ラベル３３を教師信号として使用して、推定モデル５の機械学習を実施する。推定モデル５を訓練することは、訓
練データ３１に対して得られる出力（サービス品質の推定値）が正解ラベル３３に適合するように推定モデル５の演算パラメータの値を調整（最適化）することにより構成される。演算パラメータの調整方法（最適化問題を解く方法）は、推定モデル５に採用した機械学習の種類、構成、構造等に応じて適宜決定されてよい。

調整方法の一例として、推定モデル５がニューラルネットワークにより構成される場合、学習処理部６１３は、各データセット３の訓練データ３１を推定モデル５に入力し、推定モデル５の順伝播の演算処理を実行する。この演算処理の結果、学習処理部６１３は、訓練データ３１に含まれる各情報（３１１、３１３、３１５）に基づいてアプリケーションＡＰのサービス品質を推定した結果（サービス品質の推定値）を推定モデル５から取得する。学習処理部６１３は、得られた推定値と対応する正解ラベル３３により示される真値との間の誤差を算出し、算出された誤差の勾配を更に算出する。学習処理部６１３は、誤差逆伝播法により、算出された誤差の勾配を逆伝播することで、推定モデル５の演算パラメータの値の誤差を算出する。学習処理部６１３は、算出された誤差に基づいて、演算パラメータの値を更新する。

学習処理部６１３は、この一連の更新処理により、訓練データ３１を与えることで得られる推定値と正解ラベル３３により示される真値との間の誤差の和が小さくなるように、推定モデル５の演算パラメータの値を調整する。この演算パラメータの値の調整は、例えば、設定された反復回数の調整を実行する、算出される誤差の和が閾値以下になる等の所定の条件を満たすまで繰り返されてよい。また、例えば、損失関数、学習率等の機械学習の条件は、実施の形態に応じて適宜設定されてよい。この機械学習の処理により、訓練済みの推定モデル５を生成することができる。

保存処理部６１４は、上記機械学習により生成された訓練済みの推定モデル５を再生するための学習結果データ１２５を生成する。訓練済みの推定モデル５を再生可能であれば、学習結果データ１２５の構成は、特に限定されなくてよく、実施の形態に応じて適宜決定されてよい。一例として、学習結果データ１２５は、上記機械学習の調整により得られた推定モデル５の各演算パラメータの値を示す情報を含んでよい。場合によって、学習結果データ１２５は、推定モデル５の構造を示す情報を更に含んでもよい。構造は、例えば、入力層から出力層までの層の数、各層の種類、各層に含まれるニューロンの数、隣接する層のニューロン同士の結合関係等により特定されてよい。保存処理部６１４は、生成された学習結果データ１２５を所定の記憶領域に保存する。

＜最適化実行部＞
図３に戻り、最適化実行部６３は、学習結果データ１２５を保持することで、訓練済みの推定モデル５を備える。最適化実行部６３は、訓練済みの推定モデル５を使用したリソース配備の最適化に関する情報処理を実行するように構成される。本実施形態では、最適化実行部６３は、設定受付部６３１、データ取得部６３２、推定部６３３、最適量計算部６３４、リソース調整部６３５、及び通信部６３６を備える。

図５は、最適化実行部６３によるアプリケーションＡＰの各コンポーネントＡＳに使用されるリソース量の最適化の処理過程の一例を模式的に示す。設定受付部６３１は、最適化の条件（例えば、サービス品質の目標、使用する最適化手法等）に関する設定を受け付けるように構成される。データ取得部６３２は、対象データ４を取得するように構成される。本実施形態では、対象データ４は、ワークロード情報４１、リソース使用情報４３及びサービスチェイン情報４５を含むように構成される。一例では、データ取得部６３２は、アプリケーションＡＰを運用するクラスタＫから直接的に対象データ４を取得してよい。他の一例では、対象データ４は他のコンポーネント又は他のコンピュータにより生成されてよく、データ取得部６３２は、他のコンポーネント又は他のコンピュータから直接的
又は間接的に対象データ４を取得してよい。

推定部６３３は、訓練済みの推定モデル５を使用することで、取得された対象データ４に基づき、アプリケーションＡＰのサービス品質の推定値を算出するように構成される。算出される推定値は、アプリケーションＡＰ全体のサービス品質に関するものであってよい。最適量計算部６３４は、算出されたサービス品質の推定値が適正に目標を満たすか否かを判定するように構成される。加えて、最適量計算部６３４は、算出されたサービス品質の推定値が適正に目標を満たさない場合に、所定の最適化手法によって、訓練済みの推定モデル５により算出されるサービス品質の推定値に基づき目標に対してリソースの量を最適化するように構成される。リソース調整部６３５は、最適化の結果に従って、各コンポーネントＡＳに使用されるリソースの量（例えば、ノードＫＮの数、コンテナＫＣの数）を調整するように構成される。通信部６３６は、マスタＫＭ、他のコンポーネントＡＳ等とデータの受け渡しを行うように構成される。

＜その他＞
本実施形態では、サーバ装置１の各ソフトウェアモジュールがいずれも汎用のＣＰＵによって実現される例について説明している。しかしながら、上記ソフトウェアモジュールの一部又は全部が、１又は複数の専用のプロセッサにより実現されてもよい。上記各モジュールは、ハードウェアモジュールとして実現されてもよい。サーバ装置１のソフトウェア構成に関して、実施形態に応じて、適宜、モジュールの省略、置換及び追加が行われてもよい。

本実施形態では、機械学習部６１及び最適化実行部６３がそれぞれ１つのコンポーネントＡＳとして実装されている。しかしながら、各ソフトウェアモジュールの実装形式は、このような例に限定されなくてよい。機械学習部６１及び最適化実行部６３の少なくとも一方は、複数のコンポーネントＡＳにより実装されてよい。機械学習部６１及び最適化実行部６３はそれぞれ、１つ以上のコンテナＫＣ上で実行されてよい。機械学習部６１及び最適化実行部６３を構成するコンポーネントＡＳのうち少なくとも一部は同一のコンテナＫＣ上で実行されてもよいし、或いは各コンポーネントＡＳは別々のコンテナＫＣ上実行されてよい。機械学習部６１及び最適化実行部６３の少なくとも一方は、アプリケーションＡＰとは別個のアプリケーションプロセスとして実行されてよい。

［３ 動作例］
［推定モデルの機械学習］
図６は、本実施形態に係るサーバ装置１（機械学習部６１）による推定モデル５の機械学習の処理手順の一例を示すフローチャートである。以下の処理手順は、モデル生成の情報処理方法の一例である。ただし、以下のモデル生成の処理手順は、一例に過ぎず、各ステップは可能な限り変更されてよい。また、以下のモデル生成の処理手順について、実施の形態に応じて、適宜、ステップの省略、置換、及び追加が可能である。

（ステップＳ１０１）
ステップＳ１０１では、制御部１１は、設定受付部６１１として動作し、推定モデル５の機械学習の条件に関する設定を受け付ける。

設定を受け付ける諸条件は、実施の形態に応じて適宜決定されてよい。一例として、制御部１１は、機械学習における反復回数の設定を受け付けてもよい。この場合、反復回数は、オペレータの入力装置１４を介した入力により指定されてよい。その他、制御部１１は、推定モデル５を構成する機械学習モデルの初期設定を受け付けてもよい。機械学習モデルの構造及び演算パラメータの初期値は、テンプレートにより与えられてもよいし、或いはオペレータの入力により決定されてもよい。制御部１１は、推定モデル５に与える入
力データ（ワークロード情報、リソース使用情報、サービスチェイン情報）を取得し、取得された入力データに基づいて、機械学習モデルのパラメータの数を決定してもよい。追加学習又は再学習を行う場合、制御部１１は、過去の機械学習により得られた学習結果データに基づいて、推定モデル５の初期設定を行ってよい。

設定の受付が完了すると、制御部１１は、次のステップＳ１０２に処理を進める。なお、ステップＳ１０１の処理を実行するタイミングは、この例に限定されなくてよい。ステップＳ１０１の処理は、後述するステップＳ１０３の処理を実行するまでの任意のタイミングで実行されてよい。ステップＳ１０１の処理は、このフローチャートの処理手順とは独立に実行されてよい。また、ステップＳ１０１の処理は省略されてもよい。この場合、各条件は、任意の方法で予め決定されてよい。

（ステップＳ１０２）
ステップＳ１０２では、制御部１１は、データ取得部６１２として動作し、複数のデータセット３を取得する。各データセット３は任意の経路で取得されてよい。一例では、制御部１１は、クラスタＫから直接的に各データセット３を取得してよい。他の一例では、制御部１１は、例えば、ネットワーク、記憶媒体９１、他のコンピュータ、外部記憶装置等を介して、各データセット３を取得してよい。制御部１１は、複数の取得先から各データセット３を取得してよい。取得するデータセット３の件数は、特に限定されなくてよく、機械学習を実施可能なように適宜決定されてよい。複数のデータセット３を取得すると、制御部１１は、次のステップＳ１０３に処理を進める。

（ステップＳ１０３）
ステップＳ１０３では、制御部１１は、学習処理部６１３として動作し、取得された複数のデータセット３を使用して、推定モデル５の機械学習を実施する。機械学習の処理として、制御部１１は、各データセット３について、訓練データ３１に対して得られる出力が正解ラベル３３に適合するように推定モデル５の演算パラメータの値を調整する。

調整方法の一例として、制御部１１は、各データセット３の訓練データ３１を推定モデル５に入力し、推定モデル５の順伝播の演算処理を実行する。この演算処理の結果、制御部１１は、訓練データ３１に含まれる各情報（３１１、３１３、３１５）に基づいて算出されるアプリケーションＡＰのサービス品質の推定値を推定モデル５から取得する。制御部１１は、得られた推定値と対応する正解ラベル３３により示される真値との間の誤差を算出する。制御部１１は、誤差逆伝播法により、算出される誤差の和が小さくなるように、推定モデル５の演算パラメータの値を調整する。この演算パラメータの値の調整は、所定の条件を満たすまで繰り返されてよい。一例として、ステップＳ１０１の処理により、反復回数を設定した場合、制御部１１は、反復回数が設定回数に到達するまで、推定モデル５の演算パラメータの値の調整を繰り返してよい。この機械学習の処理を実行した結果として、訓練済みの推定モデル５を生成することができる。機械学習の処理が完了すると、制御部１１は、次のステップＳ１０４に処理を進める。

（ステップＳ１０４）
ステップＳ１０４では、制御部１１は、保存処理部６１４として動作し、機械学習により生成された訓練済みの推定モデル５に関する情報を学習結果データ１２５として生成する。そして、制御部１１は、生成された学習結果データ１２５を記憶領域に保存する。

記憶領域は、例えば、制御部１１内のＲＡＭ、記憶部１２、外部記憶装置、記憶メディア又はこれらの組み合わせであってよい。記憶メディアは、例えば、ＣＤ、ＤＶＤ等の記憶媒体９１であってよく、制御部１１は、ドライブ１６を介して記憶メディアに学習結果データ１２５を格納してもよい。外部記憶装置は、例えば、ＮＡＳ（Network Attached S
torage）等のデータサーバであってよい。この場合、制御部１１は、通信インタフェース１３を利用して、ネットワークを介してデータサーバに学習結果データ１２５を格納してもよい。また、外部記憶装置は、例えば、サーバ装置１に接続された外付けの記憶装置であってもよい。

学習結果データ１２５の保存が完了すると、制御部１１は、推定モデル５の機械学習に関する処理手順を終了する。

なお、生成された学習結果データ１２５は、任意のタイミングで通信部（６１５、６３６）を介して、機械学習部６１から最適化実行部６３に直接的又は間接的に提供されてよい。また、制御部１１は、上記処理手順のうちの少なくともステップＳ１０２～ステップＳ１０４の処理を繰り返し実行することで、学習結果データ１２５を更新又は新たに作成してもよい。この繰り返しの際に、機械学習に使用する複数のデータセット３の少なくとも一部の変更、修正、追加、削除等が適宜実行されてよい。そして、制御部１１は、更新した又は新たに生成した学習結果データ１２５を機械学習部６１から最適化実行部６３に提供することで、最適化実行部６３の保持する学習結果データ１２５を更新してもよい。

［リソース配備の最適化］
図７は、本実施形態に係るサーバ装置１（最適化実行部６３）によるアプリケーションＡＰに使用するリソース量を最適化する処理手順の一例を示すフローチャートである。以下の処理手順は、最適化の情報処理方法の一例である。ただし、以下の最適化の処理手順は、一例に過ぎず、各ステップは可能な限り変更されてよい。また、以下の最適化の処理手順について、実施の形態に応じて、適宜、ステップの省略、置換、及び追加が可能である。

（ステップＳ３０１）
ステップＳ３０１では、制御部１１は、設定受付部６３１として動作し、最適化の条件に関する設定を受け付ける。

設定を受け付ける諸条件は、実施の形態に応じて適宜決定されてよい。一例として、制御部１１は、サービス品質の目標の設定を受け付けてよい。目標は、数値（目標値とも称する）により設定されてよい。一例として、目標値は、任意の期間に計測されるサービス品質の値に対応して設定されてよい。遅延時間及び実行時間の少なくとも一方によりサービス品質が算定される場合、目標値は、平均値、パーセンタイル値（例えば、９０パーセンタイル値、９５パーセンタイル値、９９パーセンタイル値、９９．９パーセンタイル値等）、中央値、最小値、最大値等の統計量により指定されてよい。目標値は、オペレータの入力により指定されてよい。

また、制御部１１は、後述するステップＳ３０５の処理における所定の最適化手法の設定を受け付けてよい。所定の最適化手法は、任意の方法で決定されてよい。一例として、所定の最適化手法は、最急降下法及びベイズ最適化から選択されてよい。選択は、オペレータの入力装置１４を介した操作により行われてよい。最急降下法によれば、短い時間でサービス品質の目標に対してリソース量を最適化することができる。そのため、ワークロードの変動が激しい時間帯においてリソース量を最適化するのに最急降下法を選択するのが好ましい。一方、ベイズ最適化によれば、最急降下法よりも最適化に時間がかかるが、サービス品質の目標に対してより最適なリソース量を算出することができる。そのため、ワークロードの変動が少ない又は周期的に変動する時間帯においてリソース量を最適化するのにベイズ最適化を選択するのが好ましい。このように、特徴の異なる複数の最適化手法の中から選択するようにすることで、後述するステップＳ３０５では、ワークロードの状態に適した最適化を遂行することができる。

設定の受付が完了すると、制御部１１は、次のステップＳ３０２に処理を進める。なお、ステップＳ３０１の処理を実行するタイミングは、この例に限定されなくてよい。例えば、サービス品質の目標の設定は、後述するステップＳ３０４の処理を実行するまでの任意のタイミングで実行されてよい。最適化手法の設定は、後述するステップＳ３０５の処理を実行するまでの任意のタイミングで実行されてよい。ステップＳ３０１の処理は、このフローチャートの処理手順とは独立に実行されてよい。また、ステップＳ３０１の処理は省略されてもよい。この場合、各条件は、任意の方法で予め決定されてよい。

（ステップＳ３０２）
ステップＳ３０２では、制御部１１は、データ取得部６３２として動作し、対象データ４を取得する。対象データ４は、任意の経路で取得されてよい。一例として、オンラインでリソース量の最適化を実施する場合、制御部１１は、対象データ４を構成する各情報（４１、４３、４５）をクラスタＫから取得してよい。対象データ４を取得すると、制御部１１は、次のステップＳ３０３に処理を進める。

（ステップＳ３０３）
ステップＳ３０３では、制御部１１は、推定部６３３として動作し、学習結果データ１２５を参照することで、訓練済みの推定モデル５の設定を行う。学習結果データ１２５は、ステップＳ３０３の処理を実行するまでの任意のタイミングで取得されてよい。そして、制御部１１は、訓練済みの推定モデル５を使用して、取得された対象データ４に基づき、アプリケーションＡＰのサービス品質の推定値を算出する。訓練済みの推定モデル５の演算処理は、推定モデル５に採用する機械学習モデルに応じて適宜実行されてよい。一例として、推定モデル５がニューラルネットワークにより構成される場合、制御部１１は、取得された対象データ４を訓練済みの推定モデル５に入力し、訓練済みの推定モデル５の順伝播の演算処理を実行する。この演算処理の結果、制御部１１は、サービス品質を推定した結果（推定値）を訓練済みの推定モデル５から取得することができる。サービス品質の推定値を取得すると、制御部１１は、次のステップＳ３０４に処理を進める。

（ステップＳ３０４）
ステップＳ３０４では、制御部１１は、最適量計算部６３４として動作し、算出されたサービス品質の推定値が設定された目標を適正に満たすか否かを判定する。

一例では、目標を適正に満たすことは、目標を適正な値で満たすことで構成されてよい。具体例として、遅延時間の目標値がサービス品質の目標として設定されており、ステップＳ３０３の処理によりサービス品質の推定値として遅延時間の推定値を算出した場合、制御部１１は、算出された遅延時間の推定値と目標値とを比較してよい。そして、遅延時間の推定値が目標値未満であるとき、制御部１１は、サービス品質の推定値が目標を満たすと判定し、遅延時間の推定値が目標値を超えているとき、サービス品質の推定値が目標を満たさないと判定してよい。遅延時間の推定値と目標値とが等しい場合、制御部１１は、いずれに判定してもよい。

実行時間の目標値がサービス品質の目標として設定されており、ステップＳ３０３の処理により実行時間の推定値を算出した場合、制御部１１は、算出された実行時間の推定値と目標値とを比較してよい。そして、実行時間の推定値が目標値未満であるとき、制御部１１は、サービス品質の推定値が目標を満たすと判定し、実行時間の推定値が目標値を超えているとき、サービス品質の推定値が目標を満たさないと判定してよい。実行時間の推定値と目標値とが等しい場合、制御部１１は、いずれに判定してもよい。

正常に処理された程度の目標値がサービス品質の目標として設定されており、ステップ
Ｓ３０３の処理によりアプリケーションＡＰが正常に処理された程度の推定値を算出した場合、制御部１１は、算出された正常に処理された程度の推定値と目標値とを比較してよい。そして、正常に処理された程度の推定値が目標値を超えている（エラーの程度が目標値未満である）とき、制御部１１は、サービス品質の推定値が目標を満たすと判定し、正常に処理された程度の推定値が目標値未満である（エラーの程度が目標値を超えている）とき、サービス品質の推定値が目標を満たさないと判定してよい。正常に処理された程度の推定値と目標値とが等しい場合、制御部１１は、いずれに判定してもよい。

他の一例では、目標を満たすことは、目標を適正な範囲で満たすことにより構成されてよい。この場合、制御部１１は、算出されたサービス品質の推定値が設定された目標の範囲に入るか否かに応じて、目標を適正に満たすか否かを判定してよい。すなわち、上記サービス品質の推定値が目標値を満たさない場合に加えて、制御部１１は、サービス品質の目標に対してリソースが過剰に使用されている場合にも、目標を適正に満たさないと判定してもよい。なお、目標の範囲は、任意の方法で設定されてよい。例えば、目標の範囲として目標値の上限値及び下限値がオペレータの指定等により設定されてよい。その他、目標値並びに目標値に対する上限及び下限の少なくとも一方の範囲を規定する閾値がオペレータの指定等により設定されてよい。また、目標の範囲の上限値又は下限値と推定値とが等しい場合、制御部１１は、いずれに判定してもよい。

算出されたサービス品質の推定値が目標を満たすと判定した場合、制御部１１は、リソース量の最適化に関する処理手順を終了する。他方、算出されたサービス品質の推定値が目標を満たさないと判定した場合、制御部１１は、次のステップＳ３０５に処理を進める。なお、平均値等の統計量により目標値が指定される場合、制御部１１は、ステップＳ３０２及びステップＳ３０３の処理を繰り返し実行して、目標値の統計量に応じた推定値を算出してよい。

（ステップＳ３０５～ステップＳ３０７）
ステップＳ３０５では、制御部１１は、最適量計算部６３４として動作し、所定の最適化手法によって、訓練済みの推定モデル５により算出されるサービス品質の推定値に基づき目標に対してリソースの量を最適化する。制御部１１は、訓練済みの推定モデル５により算出されるサービス品質の推定値が適正に目標を満たすものとなるように、所定の最適化手法によって、目標に対してリソースの最適な量を計算する。一例では、適正に目標を満たす最適なリソース量は、目標を満たす最小のリソース量であってよい。

一例として、所定の最適化手法に最急降下法が選択されている場合、制御部１１は、以下の式１及び式２に従って、目標に対してリソースの最適な量を計算（推定）してよい。

・・・（式１）

・・・（式２）
なお、ｒは、リソースの使用状況（使用量）を示し、ｗは、ワークロードの状態を示す。リソースの使用状況及びワークロードの状態はベクトルで表現されてよい。Target_Qosは、設定されたサービス品質の目標値を示す。Ｌ（ｗ，ｒ）は、訓練済みの推定モデル５により算出されるサービス品質の推定値を示す。ρは、ペナルティコストであり、適宜与えられてよい。

その他の一例として、所定の最適化手法にベイズ最適化が選択されている場合、制御部１１は、以下の式３及び式４に従って、目標に対してリソースの最適な量を計算してよい。

・・・（式３）

・・・（式４）

ステップＳ３０６では、制御部１１は、最適量計算部６３４として動作し、所定の最適化手法により算出されたリソース量が最適であるか否か（すなわち、最適化手法により暫定的に得られるリソース量が最小のリソース量に到達したか否か）を判定する。算出されたリソース量が最適である場合、制御部１１は、次のステップＳ３０７に処理を進める。一方、算出されたリソース量が最適でない場合、制御部１１は、ステップＳ３０５に処理を戻し、所定の最適化手法によるリソース量の計算を再度実行する。なお、このステップＳ３０５の処理を繰り返し実行する際、制御部１１は、最初の訓練済みの推定モデル５の演算により得られた推定値を繰り返し利用して、最適なリソース量の特定を行ってよい。或いは、制御部１１は、ステップＳ３０５の処理により算出された暫定的なリソース量の情報を新たなリソース使用情報として使用して、訓練済みの推定モデル５の演算処理を再度実行することで、最適なリソース量の特定に利用するサービス品質の推定値を更新してもよい。この推定値の更新は、ステップＳ３０５の処理を任意回数繰り返す度（例えば、毎回）に行われてよい。

ステップＳ３０７では、制御部１１は、リソース調整部６３５として動作し、アプリケーションＡＰを運用するコンピュータに対して最適化の結果を出力する。これにより、制御部１１は、最適化の結果に従って、各コンポーネントＡＳに使用されるリソースの量を調整（設定）する。一例として、サーバ装置１上でアプリケーションＡＰが運用される場合、制御部１１は、計算されたリソースの最適な量で各コンポーネントＡＳを実行するように、リソースの量を調整してよい。他の一例として、アプリケーションＡＰが他の装置で運用される場合、制御部１１は、最適化の結果を他の装置に送信することで、リソース量の調整を当該他の装置に対して指示してもよい。

リソース量の調整は、実施の形態に応じて適宜実行されてよい。例えば、リソース量の調整は、各コンポーネントＡＳ（ノードＫＮ、コンテナＫＣ）に対する、スケールアウト、スケールイン、スケールアップ及びスケールダウンの少なくともいずれかにより構成されてよい。一例として、アプリケーションＡＰに含まれる各コンポーネントＡＳがコンテナＫＣ上で実行される場合に、ステップＳ３０５～ステップＳ３０６の処理におけるリソース量を最適化することは、リソースの最適な量を計算すること、及び計算されたリソースの最適な量から各コンポーネントＡＳを実行するコンテナＫＣの最適な数を算出することにより構成されてよい。これに応じて、ステップＳ３０７の処理におけるリソースの量を調整することは、各コンポーネントＡＳを実行するコンテナＫＣの数が算出された最適な数になるように各コンポーネントＡＳを実行するコンテナＫＣの数を調整することにより構成されてよい。この方法によれば、それぞれコンテナ化された複数のコンポーネントＡＳにより構成されるアプリケーションＡＰに使用されるリソース量の調整を容易に行うことができる。

なお、ステップＳ３０５～ステップＳ３０６において、制御部１１は、リソースの最適な量について複数の候補を算出してもよい。これに応じて、ステップＳ３０７において、制御部１１は、算出された複数の候補の中から一つの候補を選択し、選択された最適化の候補に従って、各コンポーネントＡＳに使用されるリソースの量を調整してもよい。選択は、オペレータの入力により行われてもよいし、或いは所定の基準（例えば、使用するリソース量の最も少ないものを選択する）に基づいて行われてもよい。

リソース量の調整が完了すると、制御部１１は、リソース量の最適化に関する処理手順を終了する。なお、制御部１１は、上記処理手順のうちの少なくともステップＳ３０２～ステップＳ３０７の処理を任意のタイミングで繰り返し実行してもよい。これにより、制御部１１は、訓練済みの推定モデル５を使用して、アプリケーションＡＰに使用されるリソースの量を継続的に最適化してよい。

［特徴］
本実施形態では、上記ステップＳ１０２及びステップＳ１０３の処理により、ワークロード情報及びリソースについてのリソース使用情報からアプリケーションのサービス品質を推定する能力を獲得した訓練済みの推定モデル５を生成することができる。この訓練済みの推定モデル５によれば、ワークロードの状態及び各コンポーネントＡＳへのリソースの配備の状況からアプリケーションＡＰのサービス品質を推定することができる。つまり、ワークロードの状態に応じて、各コンポーネントＡＳへのリソースの配備とアプリケーションＡＰのサービス品質との間の対応関係を推測することができる。これを利用することにより、上記ステップＳ３０２～ステップＳ３０７の処理によれば、訓練済みの推定モデル５を使用して、マイクロサービスアーキテクチャで構築されたアプリケーションＡＰのサービス品質の目標に応じて、各コンポーネントＡＳに使用するリソースの量を最適化することができる。その結果、アプリケーションＡＰのサービス品質の維持にかかるコストの低減を図ることができる。

また、本実施形態では、推定モデル５に対する入力データにサービスチェイン情報が更に含まれている。これにより、アプリケーションＡＰのコンポーネント構成が変更されても、推定モデル５は、入力されるサービスチェイン情報に基づいてアプリケーションＡＰのコンポーネント構成を特定することができ、その結果、サービス品質の推定精度を維持することができる。よって、本実施形態によれば、アプリケーションＡＰのコンポーネント構成が変更されても、リソース量の最適化を高精度に遂行することができる。

［４ 変形例］
以上、本開示の実施の形態を詳細に説明してきたが、前述までの説明はあらゆる点において本開示の例示に過ぎない。本開示の範囲を逸脱することなく種々の改良又は変形を行うことができることは言うまでもない。例えば、以下のような変更が可能である。以下の変形例は適宜組み合わせ可能である。

上記実施形態において、ステップＳ１０２の処理により取得される各データセット３の訓練データ３１からサービスチェイン情報３１５は省略されてもよい。これに応じて、ステップＳ３０２の処理により取得される対象データ４からサービスチェイン情報４５が省略されてよい。

また、上記実施形態において、推定モデル５は、ワークロード情報、リソース使用情報及びサービスチェイン情報以外の他の情報の入力を更に受け付けるように構成されてよい。推定モデル５は、サービス品質の推定値以外の情報を更に出力するように構成されてよい。推定モデル５には、ニューラルネットワーク以外の機械学習モデルが採用されてよい
。

［５ 実施例］
本開示の有効性を検証するために、以下の実施例及び比較例に係る情報処理装置を構成した。ただし、本開示は、以下の実施例に限定されるものではない。

図８は、マイクロサービスアーキテクチャで構築されたアプリケーションの第１サンプルを示す。図９は、マイクロサービスアーキテクチャで構築されたアプリケーションの第２サンプルを示す。第１サンプルに対するワークロードは、５００ＴＰＳ（Transactions
Per Second）に設定し、サービス品質（遅延時間）の目標は、３０ミリ秒に設定した。
一方、第２サンプルに対するワークロードは、５００ＴＰＳに設定し、サービス品質（遅延時間）の目標は、１５０ミリ秒に設定した。

実施例に係る情報処理装置では、上記実施形態と同様の方法により、訓練済みの推定モデルをアプリケーションのサンプル毎に生成した。推定モデルには、ニューラルネットワークを採用した。ワークロード情報をトランザクション量により構成し、リソース使用情報を各コンポーネントに対するプロセッサ（ＣＰＵ）の使用量により構成した。サービスチェイン情報を、グラフ形式により各コンポーネントの接続関係を示すように構成した。機械学習に使用したデータセットの件数はそれぞれ、約５０，０００件であった。エポック数を７０，０００、バッチサイズを２５６、学習率を２．０×１０^－４にそれぞれ設定した。実施例に係る情報処理装置により、上記実施形態と同様の方法により、生成された訓練済みの推定モデルを使用して、各サンプルに使用されるリソース（ＣＰＵの割り当て）の量を最適化した。所定の最適化手法には、最急降下法を使用した。

一方、比較例に係る情報処理装置では、KubernetesのHorizontal Pod Autoscaler（非
特許文献１）により、各サンプルに使用されるリソース（ＣＰＵの割り当て）の量を調整した。

上記表１は、実施例及び比較例により、各サンプルのアプリケーションに使用されるリソースの量を調整した結果を示す（単位は、ミリコア）。上記結果に示すとおり、実施例では、比較例に比べて、少ないリソース量（ＣＰＵの割り当て量）でサービス品質の目標を達成することができた。この結果から、本開示によれば、設定したサービス品質の目標に応じて、使用するリソース量の最適化が可能であることが分かった。

［６ 補足］
本開示において説明した処理及び手段は、技術的な矛盾が生じない限りにおいて、自由に組み合わせて実施することができる。

また、１つの装置が行うものとして説明した処理が、複数の装置によって分担して実行されてもよい。或いは、異なる装置が行うものとして説明した処理が、１つの装置によって実行されても構わない。コンピュータシステムにおいて、各機能をどのようなハードウ
ェア構成（サーバ構成）によって実現するかは柔軟に変更可能である。

本開示は、上記の実施形態で説明した機能を実装したコンピュータプログラムをコンピュータに供給し、当該コンピュータが有する１つ以上のプロセッサがプログラムを読み出して実行することによっても実現可能である。このようなコンピュータプログラムは、コンピュータのシステムバスに接続可能な非一時的なコンピュータ可読記憶媒体によってコンピュータに提供されてもよいし、ネットワークを介してコンピュータに提供されてもよい。非一時的なコンピュータ可読記憶媒体は、例えば、磁気ディスク（フロッピー（登録商標）ディスク、ハードディスクドライブ（ＨＤＤ）等）、光ディスク（ＣＤ－ＲＯＭ、ＤＶＤディスク、ブルーレイディスク等）など任意のタイプのディスク、読み込み専用メモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、ＥＰＲＯＭ、ＥＥＰＲＯＭ、磁気カード、フラッシュメモリ、光学式カード、電子的命令を格納するために適した任意のタイプの媒体を含む。

１…サーバ装置、
１１…制御部、１２…記憶部、１３…通信インタフェース、
１４…入力装置、１５…出力装置、１６…ドライブ、
８０…オペレーティングシステム、
８１…プログラム、９１…記憶媒体、
１２５…学習結果データ、
３…データセット、
３１…訓練データ、
３１１…ワークロード情報、３１３…リソース使用情報、
３１５…サービスチェイン情報、
３３…正解ラベル、
４…対象データ、
４１…ワークロード情報、４３…リソース使用情報、
４５…サービスチェイン情報、
５…推定モデル、
６１…機械学習部、
６１１…設定受付部、６１２…データ取得部、
６１３…学習処理部、６１４…保存処理部、
６１５…通信部、
６３…最適化実行部、
６３１…設定受付部、６３２…データ取得部、
６３３…推定部、６３４…最適量計算部、
６３５…リソース調整部、６３６…通信部、
ＡＰ…アプリケーション、ＡＳ…コンポーネント、
Ｋ…クラスタ、ＫＭ…マスタ、ＫＮ…ノード、
ＫＣ…コンテナ、Ｔ…端末

Claims (20)

1. 訓練データ及び正解ラベルの組み合わせによりそれぞれ構成される複数のデータセットを取得することと、
   取得された複数のデータセットを使用して、推定モデルの機械学習を実施することと、を実行するように構成された制御部を備える情報処理装置であって、
   前記訓練データは、学習対象の環境における、マイクロサービスアーキテクチャで構築されたアプリケーションに対するワークロード情報、及び前記アプリケーションに含まれる各コンポーネントに使用されるリソースについてのリソース使用情報を含み、
   前記正解ラベルは、前記アプリケーションのサービス品質の真値を示すように構成され、
   前記機械学習は、前記各データセットについて、前記推定モデルにより前記訓練データに基づき算出される前記サービス品質の推定値が前記正解ラベルにより示される真値に適合するように前記推定モデルを訓練することにより構成される、
   情報処理装置。
2. 前記訓練データは、前記アプリケーションに含まれる前記各コンポーネントの接続関係を示すサービスチェイン情報を更に含む、
   請求項１に記載の情報処理装置。
3. 前記サービスチェイン情報は、前記各コンポーネントの接続関係をグラフ形式で表現するように構成され、
   前記推定モデルは、グラフニューラルネットワークを含むように構成される、
   請求項２に記載の情報処理装置。
4. 前記サービス品質は、前記アプリケーションの遅延時間、実行時間、及び正常に処理された程度の少なくともいずれかに基づいて算定される、
   請求項１から３のいずれか１項に記載の情報処理装置。
5. 前記ワークロード情報は、前記アプリケーションに対するトランザクション量、ユーザからのメッセージ量、及びデータの転送量の少なくともいずれかを含むように構成される、
   請求項１から４のいずれか１項に記載の情報処理装置。
6. 前記リソース使用情報は、前記アプリケーションに含まれる各コンポーネントに割り当てられたプロセッサの使用量、メモリの使用量、及びネットワーク帯域の使用量の少なくともいずれかを含むように構成される、
   請求項１から５のいずれか１項に記載の情報処理装置。
7. 推定対象の環境における、マイクロサービスアーキテクチャで構築されたアプリケーションに対するワークロード情報、及び前記アプリケーションに含まれる各コンポーネントに使用されるリソースについてのリソース使用情報を含む対象データを取得することと、
   訓練済みの推定モデルを使用することで、取得された前記対象データに基づき、前記アプリケーションのサービス品質の推定値を算出することと、
   算出された前記サービス品質の推定値が適正に目標を満たさない場合に、所定の最適化手法により、前記訓練済みの推定モデルにより算出される前記サービス品質の推定値に基づき前記目標に対して前記リソースの量を最適化することと、
   前記最適化の結果に従って、前記各コンポーネントに使用される前記リソースの量を調整することと、
   を実行するように構成された制御部を備える、
   情報処理装置。
8. 前記対象データは、前記アプリケーションに含まれる前記各コンポーネントの接続関係を示すサービスチェイン情報を更に含む、
   請求項７に記載の情報処理装置。
9. 前記サービスチェイン情報は、前記各コンポーネントの接続関係をグラフ形式で表現するように構成され、
   前記訓練済みの推定モデルは、グラフニューラルネットワークを含むように構成される、
   請求項８に記載の情報処理装置。
10. 前記サービス品質は、前記アプリケーションの遅延時間、実行時間、及び正常に処理された程度の少なくともいずれかに基づいて算定される、
    請求項７から９のいずれか１項に記載の情報処理装置。
11. 前記ワークロード情報は、前記アプリケーションに対するトランザクション量、ユーザからのメッセージ量、及びデータの転送量の少なくともいずれかを含むように構成される、
    請求項７から１０のいずれか１項に記載の情報処理装置。
12. 前記リソース使用情報は、前記アプリケーションに含まれる各コンポーネントに割り当てられたプロセッサの使用量、メモリの使用量、及びネットワーク帯域の使用量の少なくともいずれかを含むように構成される、
    請求項７から１１のいずれか１項に記載の情報処理装置。
13. 前記所定の最適化手法は、最急降下法及びベイズ最適化から選択される、
    請求項７から１２のいずれか１項に記載の情報処理装置。
14. 前記アプリケーションに含まれる前記各コンポーネントはコンテナ上で実行され、
    前記リソースの量を最適化することは、
    前記リソースの最適な量を計算すること、及び
    計算された前記リソースの最適な量から前記各コンポーネントを実行するコンテナの最適な数を算出すること、
    により構成され、
    前記リソースの量を調整することは、前記各コンポーネントを実行する前記コンテナの数が算出された前記最適な数になるように前記コンテナの数を調整することにより構成される、
    請求項７から１３のいずれか１項に記載の情報処理装置。
15. コンピュータによって実行される情報処理方法であって、
    推定対象の環境における、マイクロサービスアーキテクチャで構築されたアプリケーションに対するワークロード情報、及び前記アプリケーションに含まれる各コンポーネントに使用されるリソースについてのリソース使用情報を含む対象データを取得することと、
    訓練済みの推定モデルを使用することで、取得された前記対象データに基づき、前記アプリケーションのサービス品質の推定値を算出することと、
    算出された前記サービス品質の推定値が適正に目標を満たさない場合に、所定の最適化手法により、前記訓練済みの推定モデルにより算出される前記サービス品質の推定値に基づき前記目標に対して前記リソースの量を最適化することと、
    前記最適化の結果に従って、前記各コンポーネントに使用される前記リソースの量を調
    整することと、
    を含む、
    情報処理方法。
16. 前記対象データは、前記アプリケーションに含まれる前記各コンポーネントの接続関係を示すサービスチェイン情報を更に含む、
    請求項１５に記載の情報処理方法。
17. 前記サービスチェイン情報は、前記各コンポーネントの接続関係をグラフ形式で表現するように構成され、
    前記訓練済みの推定モデルは、グラフニューラルネットワークを含むように構成される、
    請求項１６に記載の情報処理方法。
18. 前記サービス品質は、前記アプリケーションの遅延時間、実行時間、及び正常に処理された程度の少なくともいずれかに基づいて算定される、
    請求項１５から１７のいずれか１項に記載の情報処理方法。
19. 前記所定の最適化手法は、最急降下法及びベイズ最適化から選択される、
    請求項１５から１８のいずれか１項に記載の情報処理方法。
20. 前記アプリケーションに含まれる前記各コンポーネントはコンテナ上で実行され、
    前記リソースの量を最適化することは、
    前記リソースの最適な量を計算すること、及び
    計算された前記リソースの最適な量から前記各コンポーネントを実行するコンテナの最適な数を算出すること、
    により構成され、
    前記リソースの量を調整することは、前記各コンポーネントを実行する前記コンテナの数が算出された前記最適な数になるように前記コンテナの数を調整することにより構成される、
    請求項１５から１９のいずれか１項に記載の情報処理方法。

Images