知財求人 - 知財ポータルサイト「IP Force」
特開2023-127631消費電力推定装置、消費電力推定システム及び消費電力推定方法
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公開特許公報(A)
(11)【公開番号】P2023127631
(43)【公開日】2023-09-14
(54)【発明の名称】消費電力推定装置、消費電力推定システム及び消費電力推定方法
(51)【国際特許分類】
G06F 11/34 20060101AFI20230907BHJP
G06F 9/50 20060101ALI20230907BHJP
G06F 11/30 20060101ALI20230907BHJP
G06F 1/28 20060101ALI20230907BHJP
【ＦＩ】
G06F11/34 152
G06F9/50 150C
G06F11/30 162
G06F11/30 140A
G06F1/28
【審査請求】未請求
【請求項の数】11
【出願形態】ＯＬ
(21)【出願番号】P 2022031431
(22)【出願日】2022-03-02
(71)【出願人】
【識別番号】000005108
【氏名又は名称】株式会社日立製作所
(74)【代理人】
【識別番号】110000062
【氏名又は名称】弁理士法人第一国際特許事務所
(72)【発明者】
【氏名】チャウダリ プリタム ジャイワント
(72)【発明者】
【氏名】金子 聡
(72)【発明者】
【氏名】小澤 洋司
【テーマコード（参考）】
5B011
5B042
【Ｆターム（参考）】
5B011EA02
5B011FF04
5B042MA08
5B042MA14
5B042MC12
5B042MC22
(57)【要約】
【課題】多様なアプリケーションの消費電力を正確に推定することが可能な消費電力推定手段を提供すること。
【解決手段】消費電力推定装置は、過去アプリケーションに関する過去アプリケーションメタデータを格納するメタデータＤＢと、過去アプリケーションの消費電力を示す消費電力情報を含む消費電力ＤＢと、推定対象のアプリケーションの消費電力を推定する消費電力推定部とを含み、消費電力推定部は、推定対象のアプリケーションに関するアプリケーションマニフェストから、対象アプリケーションメタデータを抽出し、対象アプリケーションメタデータの過去アプリケーションメタデータに対する類似度を計算し、類似度が所定の類似度基準を満たす類似アプリケーションに対応する第１の消費電力情報を消費電力ＤＢから抽出し、第１の消費電力情報を第１の消費電力推定結果として出力する。
【選択図】図２
【解決手段】消費電力推定装置は、過去アプリケーションに関する過去アプリケーションメタデータを格納するメタデータＤＢと、過去アプリケーションの消費電力を示す消費電力情報を含む消費電力ＤＢと、推定対象のアプリケーションの消費電力を推定する消費電力推定部とを含み、消費電力推定部は、推定対象のアプリケーションに関するアプリケーションマニフェストから、対象アプリケーションメタデータを抽出し、対象アプリケーションメタデータの過去アプリケーションメタデータに対する類似度を計算し、類似度が所定の類似度基準を満たす類似アプリケーションに対応する第１の消費電力情報を消費電力ＤＢから抽出し、第１の消費電力情報を第１の消費電力推定結果として出力する。
【選択図】図２
【特許請求の範囲】
【請求項1】
複数のノードから構成されるノードクラスターに配置される推定対象のアプリケーションの消費電力を推定する消費電力推定装置であって、
前記ノードクラスターにおいて過去に実行された過去アプリケーションに関する過去アプリケーションメタデータを格納するメタデータデータベースと、
前記過去アプリケーションの消費電力を示す消費電力情報を含む消費電力データベースと、
推定対象のアプリケーションの消費電力を推定する消費電力推定部とを含み、
前記消費電力推定部は、
前記推定対象のアプリケーションの情報を含むアプリケーションマニフェストを取得し、
前記アプリケーションマニフェストから、前記推定対象のアプリケーションに関するメタデータである対象アプリケーションメタデータを抽出し、
前記対象アプリケーションメタデータの、前記メタデータデータベースに格納されている前記過去アプリケーションメタデータに対する類似度を計算し、
前記過去アプリケーションの内、計算した前記類似度が所定の類似度基準を満たす類似アプリケーションが存在する場合、前記類似アプリケーションに対応する第１の消費電力情報を前記消費電力データベースから抽出し、
前記第１の消費電力情報を、前記推定対象のアプリケーションの消費電力の推定を示す第１の消費電力推定結果として出力する、
ことを特徴とする消費電力推定装置。
前記ノードクラスターにおいて過去に実行された過去アプリケーションに関する過去アプリケーションメタデータを格納するメタデータデータベースと、
前記過去アプリケーションの消費電力を示す消費電力情報を含む消費電力データベースと、
推定対象のアプリケーションの消費電力を推定する消費電力推定部とを含み、
前記消費電力推定部は、
前記推定対象のアプリケーションの情報を含むアプリケーションマニフェストを取得し、
前記アプリケーションマニフェストから、前記推定対象のアプリケーションに関するメタデータである対象アプリケーションメタデータを抽出し、
前記対象アプリケーションメタデータの、前記メタデータデータベースに格納されている前記過去アプリケーションメタデータに対する類似度を計算し、
前記過去アプリケーションの内、計算した前記類似度が所定の類似度基準を満たす類似アプリケーションが存在する場合、前記類似アプリケーションに対応する第１の消費電力情報を前記消費電力データベースから抽出し、
前記第１の消費電力情報を、前記推定対象のアプリケーションの消費電力の推定を示す第１の消費電力推定結果として出力する、
ことを特徴とする消費電力推定装置。
【請求項2】
前記消費電力推定部は、
前記過去アプリケーションの内、計算した前記類似度が前記対象アプリケーションメタデータとの前記所定の類似度基準を満たす類似アプリケーションが存在しない場合、前記消費電力データベースに格納されている前記過去アプリケーションのそれぞれの消費電力の平均値を前記第１の消費電力推定結果として出力する、
ことを特徴とする、請求項１に記載の消費電力推定装置。
前記過去アプリケーションの内、計算した前記類似度が前記対象アプリケーションメタデータとの前記所定の類似度基準を満たす類似アプリケーションが存在しない場合、前記消費電力データベースに格納されている前記過去アプリケーションのそれぞれの消費電力の平均値を前記第１の消費電力推定結果として出力する、
ことを特徴とする、請求項１に記載の消費電力推定装置。
【請求項3】
前記消費電力推定装置は、
前記過去アプリケーションの実行中に使用されるリソース使用量の情報を示すアプリケーションプロフィールを格納するアプリケーションプロフィールデータベースと、
前記アプリケーションプロフィールに基づいて構築され、前記過去アプリケーションの実行による消費電力を推定する電力モデルを格納する電力モデルデータベースと、
を更に含む、
ことを特徴とする、請求項１に記載の消費電力推定装置。
前記過去アプリケーションの実行中に使用されるリソース使用量の情報を示すアプリケーションプロフィールを格納するアプリケーションプロフィールデータベースと、
前記アプリケーションプロフィールに基づいて構築され、前記過去アプリケーションの実行による消費電力を推定する電力モデルを格納する電力モデルデータベースと、
を更に含む、
ことを特徴とする、請求項１に記載の消費電力推定装置。
【請求項4】
前記消費電力推定装置は、
前記第１の消費電力推定結果に基づいて、前記推定対象のアプリケーションの配置先となる配置先ノードを前記ノードクラスターの中から判定し、
前記推定対象のアプリケーションを前記配置先ノードに配置する実行管理部を更に含む、
ことを特徴とする、請求項３に記載の消費電力推定装置。
前記第１の消費電力推定結果に基づいて、前記推定対象のアプリケーションの配置先となる配置先ノードを前記ノードクラスターの中から判定し、
前記推定対象のアプリケーションを前記配置先ノードに配置する実行管理部を更に含む、
ことを特徴とする、請求項３に記載の消費電力推定装置。
【請求項5】
前記実行管理部は、
前記推定対象のアプリケーションを前記配置先ノードに配置した後、
前記過去アプリケーションの内、計算した前記類似度が前記対象アプリケーションメタデータとの前記所定の類似度基準を満たす類似アプリケーションが存在する場合、
前記類似アプリケーションの第１のアプリケーションプロフィールに対応する第１の電力モデルを前記電力モデルデータベースから特定し、
特定した前記第１の電力モデルを用いて、前記推定対象のアプリケーションの消費電力の推定を示す第２の消費電力推定結果を生成し、
前記推定対象のアプリケーションを前記配置先ノード上で実行した場合の実際の消費電力を示す消費電力計測値と、前記推定対象のアプリケーションを前記配置先ノード上で実行した場合の実際のリソース使用量を示すリソース使用量計測値を収集し、
前記消費電力計測値と前記第２の消費電力推定結果との乖離度が所定の乖離度基準を満たす場合、前記類似アプリケーションの第１のアプリケーションプロフィールを前記リソース使用量計測値に基づいて更新し、前記第１の電力モデルを、更新した前記第１のアプリケーションプロフィールと、前記消費電力計測値とに基づいて更新する、
ことを特徴とする、請求項４に記載の消費電力推定装置。
前記推定対象のアプリケーションを前記配置先ノードに配置した後、
前記過去アプリケーションの内、計算した前記類似度が前記対象アプリケーションメタデータとの前記所定の類似度基準を満たす類似アプリケーションが存在する場合、
前記類似アプリケーションの第１のアプリケーションプロフィールに対応する第１の電力モデルを前記電力モデルデータベースから特定し、
特定した前記第１の電力モデルを用いて、前記推定対象のアプリケーションの消費電力の推定を示す第２の消費電力推定結果を生成し、
前記推定対象のアプリケーションを前記配置先ノード上で実行した場合の実際の消費電力を示す消費電力計測値と、前記推定対象のアプリケーションを前記配置先ノード上で実行した場合の実際のリソース使用量を示すリソース使用量計測値を収集し、
前記消費電力計測値と前記第２の消費電力推定結果との乖離度が所定の乖離度基準を満たす場合、前記類似アプリケーションの第１のアプリケーションプロフィールを前記リソース使用量計測値に基づいて更新し、前記第１の電力モデルを、更新した前記第１のアプリケーションプロフィールと、前記消費電力計測値とに基づいて更新する、
ことを特徴とする、請求項４に記載の消費電力推定装置。
【請求項6】
前記実行管理部は、
前記推定対象のアプリケーションを前記配置先ノードに配置した後、
前記過去アプリケーションの内、計算した前記類似度が前記対象アプリケーションメタデータとの前記所定の類似度基準を満たす類似アプリケーションが存在しない場合、
前記推定対象のアプリケーションを前記配置先ノード上で実行した場合の実際の消費電力を示す消費電力計測値と、前記推定対象のアプリケーションを前記配置先ノード上で実行した場合の実際のリソース使用量を示すリソース使用量計測値を収集し、
前記リソース使用量計測値に基づいて前記推定対象のアプリケーションに対応する第２のアプリケーションプロフィールを前記アプリケーションプロフィールデータベースにおいて作成し、
作成した前記第２のアプリケーションプロフィールと、前記消費電力計測値とに基づいて、前記リソース使用量計測値を独立変数とし、前記消費電力計測値を従属変数とした回帰モデルを、前記推定対象のアプリケーションに対応する第２の電力モデルとして構築し、前記電力モデルデータベースに格納する、
ことを特徴とする、請求項４に記載の消費電力推定装置。
前記推定対象のアプリケーションを前記配置先ノードに配置した後、
前記過去アプリケーションの内、計算した前記類似度が前記対象アプリケーションメタデータとの前記所定の類似度基準を満たす類似アプリケーションが存在しない場合、
前記推定対象のアプリケーションを前記配置先ノード上で実行した場合の実際の消費電力を示す消費電力計測値と、前記推定対象のアプリケーションを前記配置先ノード上で実行した場合の実際のリソース使用量を示すリソース使用量計測値を収集し、
前記リソース使用量計測値に基づいて前記推定対象のアプリケーションに対応する第２のアプリケーションプロフィールを前記アプリケーションプロフィールデータベースにおいて作成し、
作成した前記第２のアプリケーションプロフィールと、前記消費電力計測値とに基づいて、前記リソース使用量計測値を独立変数とし、前記消費電力計測値を従属変数とした回帰モデルを、前記推定対象のアプリケーションに対応する第２の電力モデルとして構築し、前記電力モデルデータベースに格納する、
ことを特徴とする、請求項４に記載の消費電力推定装置。
【請求項7】
前記対象アプリケーションメタデータは、
テキストで構成されるテキストメタデータと、数値で構成される数値メタデータとを含み、
前記テキストメタデータは、
所定の固定テキスト値を含むキーワードメタデータと、自由に入力可能なテキスト値を含む非構造化テキストメタデータとを含み、
前記消費電力推定装置は、
前記キーワードメタデータをベクトル形式に変換するためのキーワードメタデータ変換テーブルと、前記非構造化テキストメタデータをベクトル形式に変換するための非構造化テキストメタデータ変換テーブルとを格納するメタデータ変換テーブルテータベースを更に含む、
ことを特徴とする、請求項１に記載の消費電力推定装置。
テキストで構成されるテキストメタデータと、数値で構成される数値メタデータとを含み、
前記テキストメタデータは、
所定の固定テキスト値を含むキーワードメタデータと、自由に入力可能なテキスト値を含む非構造化テキストメタデータとを含み、
前記消費電力推定装置は、
前記キーワードメタデータをベクトル形式に変換するためのキーワードメタデータ変換テーブルと、前記非構造化テキストメタデータをベクトル形式に変換するための非構造化テキストメタデータ変換テーブルとを格納するメタデータ変換テーブルテータベースを更に含む、
ことを特徴とする、請求項１に記載の消費電力推定装置。
【請求項8】
前記消費電力推定部は、
前記数値メタデータを第１のメタデータベクトルに変換し、
前記キーワードメタデータ変換テーブルを用いて前記キーワードメタデータを第２のメタデータベクトルに変換し、
訓練済みのニューラルネットワークによる分類手段を用いて、前記非構造化テキストメタデータを所定のメタデータカテゴリーに分類し、
前記メタデータカテゴリーと、前記非構造化テキストメタデータ変換テーブルとを用いて前記非構造化テキストメタデータを第３のベクトルに変換し、
前記第１のメタデータベクトル、前記第２のメタデータベクトル及び第３のメタデータベクトルのそれぞれを、前記過去アプリケーションメタデータをベクトル形式で格納する前記メタデータデータベースに比較することで、前記対象アプリケーションメタデータの、前記メタデータデータベースに格納されている前記過去アプリケーションメタデータに対する前記類似度をユークリッド距離として計算する、
ことを特徴とする、請求項７に記載の消費電力推定装置。
前記数値メタデータを第１のメタデータベクトルに変換し、
前記キーワードメタデータ変換テーブルを用いて前記キーワードメタデータを第２のメタデータベクトルに変換し、
訓練済みのニューラルネットワークによる分類手段を用いて、前記非構造化テキストメタデータを所定のメタデータカテゴリーに分類し、
前記メタデータカテゴリーと、前記非構造化テキストメタデータ変換テーブルとを用いて前記非構造化テキストメタデータを第３のベクトルに変換し、
前記第１のメタデータベクトル、前記第２のメタデータベクトル及び第３のメタデータベクトルのそれぞれを、前記過去アプリケーションメタデータをベクトル形式で格納する前記メタデータデータベースに比較することで、前記対象アプリケーションメタデータの、前記メタデータデータベースに格納されている前記過去アプリケーションメタデータに対する前記類似度をユークリッド距離として計算する、
ことを特徴とする、請求項７に記載の消費電力推定装置。
【請求項9】
前記消費電力推定部は、
前記第１のメタデータベクトル、前記第２のメタデータベクトル及び第３のメタデータベクトルのいずれかに対して重みを割り当てることで、当該メタデータベクトルの前記類似度への影響力を調整する、
ことを特徴とする、請求項８に記載の消費電力推定装置。
前記第１のメタデータベクトル、前記第２のメタデータベクトル及び第３のメタデータベクトルのいずれかに対して重みを割り当てることで、当該メタデータベクトルの前記類似度への影響力を調整する、
ことを特徴とする、請求項８に記載の消費電力推定装置。
【請求項10】
複数のノードから構成されるノードクラスターと、
前記ノードクラスターを管理するクラスター管理装置と、
前記ノードクラスターに実行させるアプリケーションを依頼するクライアント端末とが通信ネットワークを介して接続される消費電力推定システムであって、
前記クラスター管理装置は、
前記ノードクラスターにおいて実行された過去アプリケーションに関する過去アプリケーションメタデータを格納するメタデータデータベースと、
前記過去アプリケーションの消費電力を示す消費電力情報を含む消費電力データベースと、
推定対象のアプリケーションの消費電力を推定する消費電力推定部と、
前記ノードクラスターに配置するアプリケーションを管理する実行管理部とを備える消費電力推定装置を含み、
前記消費電力推定部は、
前記推定対象のアプリケーションの情報を含むアプリケーションマニフェストを前記クライアント端末から取得し、
前記アプリケーションマニフェストから、前記推定対象のアプリケーションに関するメタデータである対象アプリケーションメタデータを抽出し、
前記対象アプリケーションメタデータの、前記メタデータデータベースに格納されている前記過去アプリケーションメタデータに対する類似度を計算し、
前記過去アプリケーションの内、計算した前記類似度が所定の類似度基準を満たす類似アプリケーションが存在する場合、前記類似アプリケーションに対応する第１の消費電力情報を前記消費電力データベースから抽出し、
前記第１の消費電力情報を、前記推定対象のアプリケーションの消費電力の推定を示す第１の消費電力推定結果として生成し、
前記実行管理部は、
前記第１の消費電力推定結果に基づいて、前記推定対象のアプリケーションの配置先となる配置先ノードを前記ノードクラスターの中から判定し、
前記推定対象のアプリケーションを前記配置先ノードに配置する、
ことを特徴とする消費電力推定システム。
前記ノードクラスターを管理するクラスター管理装置と、
前記ノードクラスターに実行させるアプリケーションを依頼するクライアント端末とが通信ネットワークを介して接続される消費電力推定システムであって、
前記クラスター管理装置は、
前記ノードクラスターにおいて実行された過去アプリケーションに関する過去アプリケーションメタデータを格納するメタデータデータベースと、
前記過去アプリケーションの消費電力を示す消費電力情報を含む消費電力データベースと、
推定対象のアプリケーションの消費電力を推定する消費電力推定部と、
前記ノードクラスターに配置するアプリケーションを管理する実行管理部とを備える消費電力推定装置を含み、
前記消費電力推定部は、
前記推定対象のアプリケーションの情報を含むアプリケーションマニフェストを前記クライアント端末から取得し、
前記アプリケーションマニフェストから、前記推定対象のアプリケーションに関するメタデータである対象アプリケーションメタデータを抽出し、
前記対象アプリケーションメタデータの、前記メタデータデータベースに格納されている前記過去アプリケーションメタデータに対する類似度を計算し、
前記過去アプリケーションの内、計算した前記類似度が所定の類似度基準を満たす類似アプリケーションが存在する場合、前記類似アプリケーションに対応する第１の消費電力情報を前記消費電力データベースから抽出し、
前記第１の消費電力情報を、前記推定対象のアプリケーションの消費電力の推定を示す第１の消費電力推定結果として生成し、
前記実行管理部は、
前記第１の消費電力推定結果に基づいて、前記推定対象のアプリケーションの配置先となる配置先ノードを前記ノードクラスターの中から判定し、
前記推定対象のアプリケーションを前記配置先ノードに配置する、
ことを特徴とする消費電力推定システム。
【請求項11】
複数のノードから構成されるノードクラスターに配置される推定対象のアプリケーションの消費電力を推定する消費電力推定方法であって、
前記推定対象のアプリケーションの情報を含むアプリケーションマニフェストを取得する工程と、
前記アプリケーションマニフェストから、前記推定対象のアプリケーションに関するメタデータである対象アプリケーションメタデータを抽出する工程と、
ワン・ホット・エンコーディング手段を用いて前記対象アプリケーションメタデータをベクトル形式のメタデータベクトルに変換する工程と、
前記メタデータベクトルの、前記ノードクラスターにおいて実行された過去アプリケーションに関する過去アプリケーションメタデータに対する類似度を計算する工程と、
前記過去アプリケーションの内、計算した前記類似度が所定の類似度基準を満たす類似アプリケーションが存在する場合、前記類似アプリケーションに対応する第１の消費電力情報を特定する工程と、
前記第１の消費電力情報を、前記推定対象のアプリケーションの消費電力の推定を示す第１の消費電力推定結果として生成する工程と、
前記第１の消費電力推定結果に基づいて、前記推定対象のアプリケーションの配置先となる配置先ノードを前記ノードクラスターの中から判定する工程と、
前記推定対象のアプリケーションを前記配置先ノードに配置する工程と、
を含む消費電力推定方法。
前記推定対象のアプリケーションの情報を含むアプリケーションマニフェストを取得する工程と、
前記アプリケーションマニフェストから、前記推定対象のアプリケーションに関するメタデータである対象アプリケーションメタデータを抽出する工程と、
ワン・ホット・エンコーディング手段を用いて前記対象アプリケーションメタデータをベクトル形式のメタデータベクトルに変換する工程と、
前記メタデータベクトルの、前記ノードクラスターにおいて実行された過去アプリケーションに関する過去アプリケーションメタデータに対する類似度を計算する工程と、
前記過去アプリケーションの内、計算した前記類似度が所定の類似度基準を満たす類似アプリケーションが存在する場合、前記類似アプリケーションに対応する第１の消費電力情報を特定する工程と、
前記第１の消費電力情報を、前記推定対象のアプリケーションの消費電力の推定を示す第１の消費電力推定結果として生成する工程と、
前記第１の消費電力推定結果に基づいて、前記推定対象のアプリケーションの配置先となる配置先ノードを前記ノードクラスターの中から判定する工程と、
前記推定対象のアプリケーションを前記配置先ノードに配置する工程と、
を含む消費電力推定方法。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、消費電力推定装置、消費電力推定システム及び消費電力推定方法に関する。
【背景技術】
【0002】
互いに接続されている多数のサーバ（以下、「ノード」という）からなる分散コンピューティング環境においては、特定のアプリケーションのワークロードを実行するための最適なノードを効率良く選択することが重要である。特定のワークロードを実行するための最適なノードの選択には、ノードのプロセッサの数、メモリ及びストレージの容量、消費電力の効率等、様々な基準が用いられている。
【0003】
特に近年では、情報通信技術の地球環境への影響の配慮が求められるグリーンＩＴ等の導入に伴い、ワークロードによる電力消費がアプリケーションの配置の重要な検討事項となっており、消費電力を抑制したり、再生可能エネルギーの使用率を向上したりするなど、消費電力を意識したワークロード配置が求められている。
【0004】
消費電力を意識したワークロード配置を実現するためには、アプリケーションの配置先となるノードを決定する前に、当該アプリケーションのワークロードの消費電力を推定する手段が用いられている。
例えば、ワークロードの消費電力を推定する手段の一つとして、特許文献１には、「複数のノードを備えるデータ処理システムを動作させる方法であって、第一のジョブについてモードの指示を受信することと、前記モードに基づいて前記第一のジョブのための利用可能な電力を決定することと、前記利用可能な電力に基づいて前記第一のジョブを実行する前記複数のノードの第一の周波数を調整することであって、前記第一の周波数は前記第一のジョブを実行する前記複数のノードに共通である、ことと、前記第一の周波数に基づいて前記複数のノードで実行される前記第一のジョブのための第一の電力を割り当てることと、前記第一の周波数が所定の周波数より大きいかどうかを判定することと、前記第一の周波数が所定の周波数より大きい場合、第二のジョブのための利用可能な電力を決定することと、を含む方法」が開示されている。
例えば、ワークロードの消費電力を推定する手段の一つとして、特許文献１には、「複数のノードを備えるデータ処理システムを動作させる方法であって、第一のジョブについてモードの指示を受信することと、前記モードに基づいて前記第一のジョブのための利用可能な電力を決定することと、前記利用可能な電力に基づいて前記第一のジョブを実行する前記複数のノードの第一の周波数を調整することであって、前記第一の周波数は前記第一のジョブを実行する前記複数のノードに共通である、ことと、前記第一の周波数に基づいて前記複数のノードで実行される前記第一のジョブのための第一の電力を割り当てることと、前記第一の周波数が所定の周波数より大きいかどうかを判定することと、前記第一の周波数が所定の周波数より大きい場合、第二のジョブのための利用可能な電力を決定することと、を含む方法」が開示されている。
【0005】
また、特許文献２には、「クラウドサーバーなどのサーバーシステムで実行するように構成されたアプリケーションコンテナの消費電力と効率を推定するためのデバイスと手法が提供される。一例では、本方法は、ベンチマークアプリケーションコンテナを作成すること、ホストサーバー上のベンチマークアプリケーションコンテナを命名すること、ホストサーバーの電力消費情報を収集すること、人工ワークロードを使用したベンチマークアプリケーションコンテナのリソース使用量情報を収集すること、消費電力情報とリソース使用量情報を使用して統計モデルを構築すること、ホストサーバーの第１の電力モデルを生成することを含む」技術が開示されている。
【先行技術文献】
【特許文献】
【0006】
【特許文献1】米国特許第９５７５５３６号
【特許文献2】米国特許第１０４３２４９１号
【発明の概要】
【発明が解決しようとする課題】
【0007】
上記の特許文献１には、特定のアプリケーションのワークロードを特定のノードで実行した場合の最大電力や平均電力の情報を参照することで、同種のアプリケーションのワークロードの消費電力を推定する手段が開示されている。
【0008】
また、特許文献２には、所定のノード上でベンチマークアプリケーションを実行し、当該ベンチマークアプリケーションのワークロードによるプロセッサ使用量、メモリ使用量、I/O使用量等のリソース使用量の情報を計測し、回帰モデリングを用いて計測したリソース使用量の情報を処理することで、消費電力を推定する電力モデルを作成する手段が開示されている。
【0009】
しかし、実際には、分散コンピューティング環境における１つのノードは、ビジネス分析、メディアストリーミング、ウェブサービス等の様々なアプリケーションをホストすることが求められており、アプリケーションによってワークロードの消費電力が変化する。このように、アプリケーションによってワークロードの消費電力が変化するため、１つのノードについて単一の電力モデルだけでは、ノードがホストする可能性がある様々なアプリケーションについて正確な消費電力を推定できず、アプリケーション毎に電力モデルを構築する必要がある。しかし、アプリケーションは多岐にわたり、ノードがホストし得る全てのアプリケーションについて電力モデルを予め構築しておくことが現実的ではない。
【0010】
しかし、上述したアプリケーションの多様性が消費電力の推定に与える影響は、特許文献１及び特許文献２のいずれにも考慮されていない。より具体的には、特許文献１及び特許文献２には、対象のアプリケーションのワークロードの消費電力を推定するためには、当該対象のアプリケーションの特性に類似しているベンチマークアプリケーションが用いられているが、対象のアプリケーションに類似しているベンチマークアプリケーションが必ずしも利用可能であるとは限らない。
特許文献１には、対象のアプリケーションに類似しているベンチマークアプリケーションがない場合、ノードの消費電力の最大値のみに基づいた電力推定が提案されているが、最大の消費電力のみでは、特定のアプリケーションについて正確な消費電力推定が得られない。また、特許文献２には、対象のアプリケーションに類似しているベンチマークアプリケーションがない場合、既に構築済みの電力モデルの係数を調整する手段が提案されているが、アプリケーションの多様性を考慮すると、電力モデルの修正が大きな負担となり得る。
特許文献１には、対象のアプリケーションに類似しているベンチマークアプリケーションがない場合、ノードの消費電力の最大値のみに基づいた電力推定が提案されているが、最大の消費電力のみでは、特定のアプリケーションについて正確な消費電力推定が得られない。また、特許文献２には、対象のアプリケーションに類似しているベンチマークアプリケーションがない場合、既に構築済みの電力モデルの係数を調整する手段が提案されているが、アプリケーションの多様性を考慮すると、電力モデルの修正が大きな負担となり得る。
【0011】
そこで、本開示は、上記の課題に鑑みてなされたものであり、分散コンピューティング環境のノードに配置する対象のアプリケーションと、過去に当該ノードで実行されたアプリケーションとの類似度をそれぞれのアプリケーションのメタデータに基づいて計算し、所定の類似度基準を満たす過去のアプリケーションについて計測した消費電力の情報を用いることで、多様なアプリケーションの消費電力を正確に推定することが可能な消費電力推定手段を提供することを目的とする。
【課題を解決するための手段】
【0012】
上記の課題を解決するために、代表的な本発明の消費電力推定装置の一つは、複数のノードから構成されるノードクラスターに配置される推定対象のアプリケーションの消費電力を推定する消費電力推定装置であって、前記ノードクラスターにおいて過去に実行された過去アプリケーションに関する過去アプリケーションメタデータを格納するメタデータデータベースと、前記過去アプリケーションの消費電力を示す消費電力情報を含む消費電力データベースと、推定対象のアプリケーションの消費電力を推定する消費電力推定部とを含み、前記消費電力推定部は、前記推定対象のアプリケーションの情報を含むアプリケーションマニフェストを取得し、前記アプリケーションマニフェストから、前記推定対象のアプリケーションに関するメタデータである対象アプリケーションメタデータを抽出し、前記対象アプリケーションメタデータの、前記メタデータデータベースに格納されている前記過去アプリケーションメタデータに対する類似度を計算し、前記過去アプリケーションの内、計算した前記類似度が所定の類似度基準を満たす類似アプリケーションが存在する場合、前記類似アプリケーションに対応する第１の消費電力情報を前記消費電力データベースから抽出し、前記第１の消費電力情報を、前記推定対象のアプリケーションの消費電力の推定を示す第１の消費電力推定結果として出力する。
【発明の効果】
【0013】
本開示によれば、分散コンピューティング環境のノードに配置する対象のアプリケーションと、過去に当該ノードで実行されたアプリケーションとの類似度をそれぞれのアプリケーションのメタデータに基づいて計算し、所定の類似度基準を満たす過去のアプリケーションについて計測した消費電力の情報を用いることで、多様なアプリケーションの消費電力を正確に推定することが可能な消費電力推定手段を提供することができる。
上記以外の課題、構成及び効果は、以下の発明を実施するための形態における説明により明らかにされる。
上記以外の課題、構成及び効果は、以下の発明を実施するための形態における説明により明らかにされる。
【図面の簡単な説明】
【0014】
【発明を実施するための形態】
【0015】
以下、図面を参照して、本発明の実施形態について説明する。なお、この実施形態により本発明が限定されるものではない。また、図面の記載において、同一部分には同一の符号を付して示している。
（本開示の概要）
（本開示の概要）
【0016】
まず、本開示の実施形態について説明する前に、本開示の概要について説明する。
【0017】
上述したように、アプリケーションは多岐にわたっており、アプリケーションによってはワークロードの消費電力が変化するため、多様なアプリケーションのホスト及び実行が求められるノードクラスターにおいて、正確な消費電力を推定することが困難という課題がある。
そこで、本開示では、分散コンピューティング環境のノードクラスターに配置する対象のアプリケーション（以下、「推定対象のアプリケーション」という）と、過去に当該ノードで実行されたアプリケーション（以下、「過去アプリケーション」という）との類似度をそれぞれのアプリケーションのメタデータに基づいて計算し、所定の類似度基準を満たす過去のアプリケーションについて計測した消費電力の情報を用いることで、多様なアプリケーションの消費電力を正確に推定することが可能となる。
そこで、本開示では、分散コンピューティング環境のノードクラスターに配置する対象のアプリケーション（以下、「推定対象のアプリケーション」という）と、過去に当該ノードで実行されたアプリケーション（以下、「過去アプリケーション」という）との類似度をそれぞれのアプリケーションのメタデータに基づいて計算し、所定の類似度基準を満たす過去のアプリケーションについて計測した消費電力の情報を用いることで、多様なアプリケーションの消費電力を正確に推定することが可能となる。
【0018】
このように生成したアプリケーションの消費電力推定に基づいて、当該アプリケーションを適切なノードクラスターに配置することができる。また、アプリケーションを適切なノードクラスターに配置した後、アプリケーションの実際の消費電力を計測し分析することで、アプリケーションのリソース使用量を考慮した消費電力を推定する電力モデルの精度を評価することができる。評価の結果、電力モデルの精度が所定の基準を満たさない場合（つまり、電力モデルの推定が実際に計測した値から乖離している場合）、アプリケーションの実際の消費電力の情報に基づいて電力モデルを更新することで、電力モデルの精度を向上させることができる。
【0019】
一方、推定対象のアプリケーションと所定の類似度基準を満たす過去アプリケーションがない場合、推定対象のアプリケーションの消費電力推定は、当該ノードクラスターにおいて実行された過去アプリケーションの消費電力の平均値に基づいて生成される。その後、推定対象のアプリケーションは、この消費電力推定に基づいて適切なノードクラスターに配置される。また、配置したアプリケーションの実際の消費電力を計測し分析することで、当該アプリケーションに対応する新たな電力モデルを構築することができる。
【0020】
このように、時間が経過するにつれて、ノードクラスターは様々なアプリケーションをホストし、ホストした各アプリケーションについて既存の電力モデルを更新したり、新たな電力モデルを作成したりすることにより、多様なアプリケーションに対応する電力モデルのレパートリーが構築されるため、多様なアプリケーションについて消費電力を正確に推定することが可能となる。
【0021】
次に、図１を参照して、本開示の実施例を実施するためのコンピュータシステム１００について説明する。本明細書で開示される様々な実施例の機構及び装置は、任意の適切なコンピューティングシステムに適用されてもよい。コンピュータシステム１００の主要コンポーネントは、１つ以上のプロセッサ１０２、メモリ１０４、端末インターフェース１１２、ストレージインタフェース１１３、Ｉ／Ｏ（入出力）デバイスインタフェース１１４、及びネットワークインターフェース１１５を含む。これらのコンポーネントは、メモリバス１０６、Ｉ／Ｏバス１０８、バスインターフェースユニット１０９、及びＩ／Ｏバスインターフェースユニット１１０を介して、相互的に接続されてもよい。
【0022】
コンピュータシステム１００は、プロセッサ１０２と総称される１つ又は複数の汎用プログラマブル中央処理装置（ＣＰＵ）１０２Ａ及び１０２Ｂを含んでもよい。ある実施例では、コンピュータシステム１００は複数のプロセッサを備えてもよく、また別の実施例では、コンピュータシステム１００は単一のＣＰＵシステムであってもよい。各プロセッサ１０２は、メモリ１０４に格納された命令を実行し、オンボードキャッシュを含んでもよい。
【0023】
ある実施例では、メモリ１０４は、データ及びプログラムを記憶するためのランダムアクセス半導体メモリ、記憶装置、又は記憶媒体（揮発性又は不揮発性のいずれか）を含んでもよい。メモリ１０４は、本明細書で説明する機能を実施するプログラム、モジュール、及びデータ構造のすべて又は一部を格納してもよい。例えば、メモリ１０４は、消費電力推定アプリケーション１５０を格納していてもよい。ある実施例では、消費電力推定アプリケーション１５０は、後述する機能をプロセッサ１０２上で実行する命令又は記述を含んでもよい。
【0024】
ある実施例では、消費電力推定アプリケーション１５０は、プロセッサベースのシステムの代わりに、またはプロセッサベースのシステムに加えて、半導体デバイス、チップ、論理ゲート、回路、回路カード、および/または他の物理ハードウェアデバイスを介してハードウェアで実施されてもよい。ある実施例では、消費電力推定アプリケーション１５０は、命令又は記述以外のデータを含んでもよい。ある実施例では、カメラ、センサ、または他のデータ入力デバイス（図示せず）が、バスインターフェースユニット１０９、プロセッサ１０２、またはコンピュータシステム１００の他のハードウェアと直接通信するように提供されてもよい。
【0025】
コンピュータシステム１００は、プロセッサ１０２、メモリ１０４、表示システム１２４、及びＩ／Ｏバスインターフェースユニット１１０間の通信を行うバスインターフェースユニット１０９を含んでもよい。Ｉ／Ｏバスインターフェースユニット１１０は、様々なＩ／Ｏユニットとの間でデータを転送するためのＩ／Ｏバス１０８と連結していてもよい。Ｉ／Ｏバスインターフェースユニット１１０は、Ｉ／Ｏバス１０８を介して、Ｉ／Ｏプロセッサ（ＩＯＰ）又はＩ／Ｏアダプタ（ＩＯＡ）としても知られる複数のＩ／Ｏインタフェースユニット１１２，１１３，１１４、及び１１５と通信してもよい。
【0026】
表示システム１２４は、表示コントローラ、表示メモリ、又はその両方を含んでもよい。表示コントローラは、ビデオ、オーディオ、又はその両方のデータを表示装置１２６に提供することができる。また、コンピュータシステム１００は、データを収集し、プロセッサ１０２に当該データを提供するように構成された1つまたは複数のセンサ等のデバイスを含んでもよい。
【0027】
例えば、コンピュータシステム１００は、心拍数データやストレスレベルデータ等を収集するバイオメトリックセンサ、湿度データ、温度データ、圧力データ等を収集する環境センサ、及び加速度データ、運動データ等を収集するモーションセンサ等を含んでもよい。これ以外のタイプのセンサも使用可能である。表示システム１２４は、単独のディスプレイ画面、テレビ、タブレット、又は携帯型デバイスなどの表示装置１２６に接続されてもよい。
【0028】
Ｉ／Ｏインタフェースユニットは、様々なストレージ又はＩ／Ｏデバイスと通信する機能を備える。例えば、端末インタフェースユニット１１２は、ビデオ表示装置、スピーカテレビ等のユーザ出力デバイスや、キーボード、マウス、キーパッド、タッチパッド、トラックボール、ボタン、ライトペン、又は他のポインティングデバイス等のユーザ入力デバイスのようなユーザＩ／Ｏデバイス１１６の取り付けが可能である。ユーザは、ユーザインターフェースを使用して、ユーザ入力デバイスを操作することで、ユーザＩ／Ｏデバイス１１６及びコンピュータシステム１００に対して入力データや指示を入力し、コンピュータシステム１００からの出力データを受け取ってもよい。ユーザインターフェースは例えば、ユーザＩ／Ｏデバイス１１６を介して、表示装置に表示されたり、スピーカによって再生されたり、プリンタを介して印刷されたりしてもよい。
【0029】
ストレージインタフェース１１３は、１つ又は複数のディスクドライブや直接アクセスストレージ装置１１７（通常は磁気ディスクドライブストレージ装置であるが、単一のディスクドライブとして見えるように構成されたディスクドライブのアレイ又は他のストレージ装置であってもよい）の取り付けが可能である。ある実施例では、ストレージ装置１１７は、任意の二次記憶装置として実装されてもよい。メモリ１０４の内容は、ストレージ装置１１７に記憶され、必要に応じてストレージ装置１１７から読み出されてもよい。Ｉ／Ｏデバイスインタフェース１１４は、プリンタ、ファックスマシン等の他のＩ／Ｏデバイスに対するインターフェースを提供してもよい。ネットワークインターフェース１１５は、コンピュータシステム１００と他のデバイスが相互的に通信できるように、通信経路を提供してもよい。この通信経路は、例えば、ネットワーク１３０であってもよい。
【0030】
ある実施例では、コンピュータシステム１００は、マルチユーザメインフレームコンピュータシステム、シングルユーザシステム、又はサーバコンピュータ等の、直接的ユーザインターフェースを有しない、他のコンピュータシステム（クライアント）からの要求を受信するデバイスであってもよい。他の実施例では、コンピュータシステム１００は、デスクトップコンピュータ、携帯型コンピューター、ノートパソコン、タブレットコンピュータ、ポケットコンピュータ、電話、スマートフォン、又は任意の他の適切な電子機器であってもよい。
【0031】
次に、図２を参照して、本開示の実施形態に係る消費電力推定システムの構成について説明する。
【0032】
図２は、本開示の実施形態に係る消費電力推定システム１６０の構成の一例を示す図である。図２に示すように、本開示の実施形態に係る消費電力推定システム１６０は、主にクラスター管理装置１０００、通信ネットワーク２０００、ノードクラスター３０１０、３０２０．．．３０Ｎ０及びクライアント端末４０００からなる。図２に示すように、消費電力推定システム１６０は、クラスター管理装置１０００、ノードクラスター３０１０、３０２０．．．３０Ｎ０及びクライアント端末４０００は、通信ネットワーク２０００を介して互いに通信可能に接続される。
【0033】
通信ネットワーク２０００は、例えばローカルエリアネットワーク（ＬＡＮ）、ワイドエリアネットワーク（ＷＡＮ）、衛星ネットワーク、ケーブルネットワーク、ＷｉＦｉネットワーク、またはそれらの任意の組み合わせを含むものであってもよい。
【0034】
クライアント端末４０００は、所定のアプリケーションの実行や管理をクラスター管理装置１０００に依頼する依頼主に利用される端末装置である。ここでのアプリケーションは、例えばビジネス分析のアプリケーション、メディアストリーミングのアプリケーション、ウェブサービスのアプリケーション等を含んでもよく、ここでは特に限定されない。クライアント端末４０００は、通信ネットワーク２０００を介してクラスター管理装置１０００と通信を行う。クライアント端末４０００は、依頼したアプリケーションの情報を有するアプリケーションマニフェストを含む実行要求を、通信ネットワーク２０００を介してクラスター管理装置１０００に送信してもよい。
【0035】
ノードクラスター３０１０、３０２０．．．３０Ｎ０は、いわゆる分散コンピューティング環境を構成するノードのグループであり、後述するクラスター管理装置１０００によって配置されるアプリケーションを実行するように構成されている。ここでは、ノードクラスター３０１０、３０２０．．．３０Ｎ０における各ノードを同種のノード（つまり、同一のサーバ構成を有するノード）とする。
【0036】
図２に示すように、ノードクラスター３０１０は、一つのマスターノード３０１１と、複数のスレーブノード３０１２、３０１３、３０１Ｎとを含む。マスターノード３０１１は、通信ネットワーク２０００を介してクラスター管理装置１０００と通信を行う。
【0037】
マスターノード３０１１は、スレーブノード３０１２、３０１３、３０１Ｎ上のアプリケーションの実行を管理するためのノードであり、後述するクラスター管理装置１０００からの指示に従って所定のアプリケーションのワークロードを適切なスレーブノードに割り当てた後、実行させる。また、マスターノード３０１１は、スレーブノード３０１２、３０１３、３０１Ｎのそれぞれの消費電力の情報や、スレーブノード３０１２、３０１３、３０１Ｎ上で実行されているアプリケーションのワークロードのリソース使用量の情報（プロセッサ使用量、メモリ使用量、Ｉ／Ｏ使用量等）を計測し、クラスター管理装置１０００に送信する。
【0038】
クラスター管理装置１０００は、クライアント端末４０００から受信した実行要求で依頼されたアプリケーションを、ノードクラスター３０１０、３０２０．．．３０Ｎ０のいずれかに配置するためのサーバ装置である。図２に示すように、クラスター管理装置１０００は、消費電力推定装置１０１０、入出力装置１０２０、プロセッサ１０３０、メモリ１０４０及びネットワークインターフェース１０５０を含む。
クラスター管理装置１０００は、例えば図１に示すコンピュータシステム１００によって構成されてもよい。
クラスター管理装置１０００は、例えば図１に示すコンピュータシステム１００によって構成されてもよい。
【0039】
ネットワークインターフェース１０５０は、通信ネットワーク２０００を介して、クラスター管理装置１０００と外部（ノードクラスター３０１０、３０２０．．．３０Ｎ０及びクライアント端末４０００）との通信を行う機能部である。
入出力装置１０２０は、クラスター管理装置１０００に対して情報を入力したり、クラスター管理装置１０００から出力される情報を確認したりするためのインターフェースを提供する機能部である。
プロセッサ１０３０は、後述するメモリ１０４０によって取得されるプログラム命令（例えば、消費電力推定装置１０１０における各機能部の機能）を実行する。
メモリ１０４０は、後述する消費電力推定装置１０１０に格納される機能部の機能を実現するためのプログラム命令を取得し、プロセッサ１０３０に提供する。
入出力装置１０２０は、クラスター管理装置１０００に対して情報を入力したり、クラスター管理装置１０００から出力される情報を確認したりするためのインターフェースを提供する機能部である。
プロセッサ１０３０は、後述するメモリ１０４０によって取得されるプログラム命令（例えば、消費電力推定装置１０１０における各機能部の機能）を実行する。
メモリ１０４０は、後述する消費電力推定装置１０１０に格納される機能部の機能を実現するためのプログラム命令を取得し、プロセッサ１０３０に提供する。
【0040】
消費電力推定装置１０１０は、本開示の実施形態に係る消費電力推定手段を実施するための装置である。図２に示すように、消費電力推定装置１０１０は、消費電力推定部１０１１、実行管理部１０１３、メタデータデータベース１０１４、メタデータ変換テーブルデータベース１０１５、アプリケーション消費電力データベース１０１６、アプリケーションプロフィールデータベース１０１７及び電力モデルデータベース１０１８を含む。
消費電力推定装置１０１０の各機能部（消費電力推定部１０１１や実行管理部１０１３）は、例えば、図１に示す消費電力推定アプリケーション１５０におけるソフトウェアモジュールとして構成されてもよく、専用のハードウェアデバイスとして構成されてもよいが、本開示では、説明の便宜上、各機能部をソフトウェアモジュールとして構成した場合を一例として説明する。
消費電力推定装置１０１０の各機能部（消費電力推定部１０１１や実行管理部１０１３）は、例えば、図１に示す消費電力推定アプリケーション１５０におけるソフトウェアモジュールとして構成されてもよく、専用のハードウェアデバイスとして構成されてもよいが、本開示では、説明の便宜上、各機能部をソフトウェアモジュールとして構成した場合を一例として説明する。
【0041】
消費電力推定部１０１１は、ノードクラスター３０１０、３０２０．．．３０Ｎ０に配置する対象のアプリケーション（以下、「推定対象のアプリケーション」という）のワークロードに消費される電力を推定する消費電力推定結果（第１の消費電力推定結果）を生成するための機能部である。ここで、「アプリケーションのワークロード」とは、あるアプリケーションの機能を実現するにあたって実行される処理タスクを意味する。アプリケーションのワークロードは、分割され、ノードクラスターにおける異なるノードに分けて割り当てられてもよい。
なお、消費電力推定部１０１１の機能の詳細については後述するため、ここではその説明を省略する。
なお、消費電力推定部１０１１の機能の詳細については後述するため、ここではその説明を省略する。
【0042】
実行管理部１０１３は、例えば消費電力推定部１０１１によって生成される、推定対象のアプリケーションの消費電力推定結果（第１の消費電力推定結果）に基づいて、推定対象のアプリケーションを適切なノードクラスター３０１０、３０２０．．．３０Ｎ０に配置するための機能部である。
【0043】
メタデータデータベース１０１４は、ノードクラスター３０１０、３０２０．．．３０Ｎ０によって実行されるアプリケーション（例えば、過去にノードクラスターに配置されたアプリケーション）に関するメタデータを格納するデータベースである。
【0044】
メタデータ変換テーブルデータベース１０１５は、ノードクラスター３０１０、３０２０．．．３０Ｎ０によって実行されるアプリケーションのメタデータをテキスト形式からベクトル形式に変換するためのテーブルである。
【0045】
アプリケーション消費電力データベース１０１６は、ノードクラスター３０１０、３０２０．．．３０Ｎ０によって実行されるアプリケーションの消費電力の情報、当該アプリケーションのリソース使用量を示すアプリケーションプロフィールの保存先の情報及び当該アプリケーションのリソース使用量を考慮した消費電力を推定するための電力モデルの保存先の情報を格納するデータベースである。
【0046】
アプリケーションプロフィールデータベース１０１７は、アプリケーションのリソース使用量を示すアプリケーションプロフィールの情報を格納するデータベースである。
【0047】
電力モデルデータベース１０１８は、ノードクラスター３０１０、３０２０．．．３０Ｎ０によって実行されるアプリケーションのリソース使用量を考慮した消費電力を推定する（つまり、第２の費電力推定結果を生成する）ための電力モデルを格納するデータベースである。ここでの電力モデルは、例えばｐｉｃｋｌｅファイルで保存される、学習されたモデル係数を指定するＰｙｔｈｏｎオブジェクトであってもよい。
上述した消費電力推定部１０１１によって生成される、推定対象のアプリケーションの配置先となるノードの判定に用いられる第１の消費電力推定結果は、類似アプリケーションの消費電力の平均値及び消費電力の最大値等の情報を含むのに対して、電力モデルデータベース１０１８に格納される電力モデルに基づいて生成される第２の消費電力推定結果は、推定対象のアプリケーションによって使用されるリソース使用量を考慮した消費電力の予測であるため、第１の消費電力推定結果より細かな推定を示すことができる。
上述した消費電力推定部１０１１によって生成される、推定対象のアプリケーションの配置先となるノードの判定に用いられる第１の消費電力推定結果は、類似アプリケーションの消費電力の平均値及び消費電力の最大値等の情報を含むのに対して、電力モデルデータベース１０１８に格納される電力モデルに基づいて生成される第２の消費電力推定結果は、推定対象のアプリケーションによって使用されるリソース使用量を考慮した消費電力の予測であるため、第１の消費電力推定結果より細かな推定を示すことができる。
【0048】
以上説明した消費電力推定システム１６０によれば、多様なアプリケーションの消費電力を正確に推定することが可能な消費電力推定手段を提供することができる。
【0049】
次に、図３を参照して、本開示の実施形態に係る消費電力推定方法の流れの一例について説明する。
【0050】
図３は、本開示の実施形態に係る消費電力推定方法３００の流れの一例を示すフローチャートである。図３に示す消費電力推定方法３００は、分散コンピューティング環境のノードクラスターに配置する対象のアプリケーション（以下、「推定対象のアプリケーション」という）と、過去に当該ノードで実行されたアプリケーション（以下、「過去アプリケーション」という）との類似度をそれぞれのアプリケーションのメタデータに基づいて計算し、所定の類似度基準を満たす過去のアプリケーションについて計測した消費電力の情報を用いることで、多様なアプリケーションの消費電力を正確に推定する方法である。消費電力推定方法３００は、例えば上述した消費電力推定装置１０１０における消費電力推定部１０１１によって実施される。
【0051】
まず、ステップＳ３０１では、消費電力推定部１０１１は、例えば上述した通信ネットワーク２０００を介して、推定対象のアプリケーションのアプリケーションマニフェストをクライアント端末４０００から受信する。このアプリケーションマニフェストは、例えば、推定対象のアプリケーションをノードクラスター３０１０、３０２０．．．３０Ｎ０のいずれかに配置するための実行要求に含まれてもよい。
このアプリケーションマニフェストとは、ノードクラスター３０１０、３０２０．．．３０Ｎ０に配置される対象のアプリケーションを構成するコンポーネントの記述であり、例えばアプリケーションに提供されるサービス（マイクロサービスともいう）の記述、当該サービスを構成するコンテナの記述、アプリケーションを構成するジョブ（処理タスク）の記述等を含んでもよい。これらのサービス、コンテナ、ジョブの記述等は、「アプリケーションリソース」と総称する。
このアプリケーションマニフェストとは、ノードクラスター３０１０、３０２０．．．３０Ｎ０に配置される対象のアプリケーションを構成するコンポーネントの記述であり、例えばアプリケーションに提供されるサービス（マイクロサービスともいう）の記述、当該サービスを構成するコンテナの記述、アプリケーションを構成するジョブ（処理タスク）の記述等を含んでもよい。これらのサービス、コンテナ、ジョブの記述等は、「アプリケーションリソース」と総称する。
【0052】
次に、ステップＳ３０２では、消費電力推定部１０１１は、ステップＳ３０１で受信したアプリケーションマニフェストから、推定対象のアプリケーションに関するアプリケーションメタデータ（以下、「対象アプリケーションメタデータ」という）を抽出する。推定対象のアプリケーションに関する対象アプリケーションメタデータとは、上述したそれぞれのアプリケーションリソースの仕様を指定する情報である。例えば、対象アプリケーションメタデータは、サービスの種類、サービスのコンテナの数、コンテナを実装するためのイメージ、サービスに用いられるネットワークプロトコル、コンテナのプロセッサ及びメモリの要件、ジョブの実行優先順位、コンテナ実行のためのノード優先順位、サービスに関連付けられたラベル、コンテナに関連付けられたラベル、ジョブに関連付けられたラベル等を含んでもよい。この対象アプリケーションメタデータを抽出するために、消費電力推定部１０１１は、既存の情報抽出手法を用いてもよく、ここでは特に限定されない。
【0053】
次に、ステップＳ３０３では、消費電力推定部１０１１は、ステップＳ３０２で抽出した推定対象のアプリケーションに関する対象アプリケーションメタデータをベクトル形式に変換する。ここでは、消費電力推定部１０１１は、上述したメタデータ変換テーブルに基づいていわゆるワン・ホット・エンコーディングを行うことで対象アプリケーションメタデータをベクトル形式に変換してもよい。
なお、推定対象のアプリケーションに関する対象アプリケーションメタデータをベクトル形式に変換する処理の詳細については後述するため、ここではその説明を省略する。
なお、推定対象のアプリケーションに関する対象アプリケーションメタデータをベクトル形式に変換する処理の詳細については後述するため、ここではその説明を省略する。
【0054】
次に、ステップＳ３０４では、消費電力推定部１０１１は、各ノードクラスター３０１０、３０２０．．．３０Ｎ０上で実行された各過去アプリケーション毎に、推定対象のアプリケーションと過去アプリケーションとの類似度を、それぞれのアプリケーションメタデータに基づいて計算する。ここでの過去アプリケーションとは、過去にノードクラスター３０１０、３０２０．．．３０Ｎ０のいずれかに実行されたことのあるアプリケーションを意味する。
より具体的には、消費電力推定部１０１１は、各ノードクラスター３０１０、３０２０．．．３０Ｎ０について、当該ノードクラスター上で実行された各過去アプリケーションのメタデータである過去アプリケーションメタデータを上述したメタデータデータベース１０１４から取得する。
より具体的には、消費電力推定部１０１１は、各ノードクラスター３０１０、３０２０．．．３０Ｎ０について、当該ノードクラスター上で実行された各過去アプリケーションのメタデータである過去アプリケーションメタデータを上述したメタデータデータベース１０１４から取得する。
【0055】
その後、消費電力推定部１０１１は、ステップＳ３０２で抽出され、ステップＳ３０３でベクトル形式に変換された推定対象のアプリケーションの対象アプリケーションメタデータの、メタデータデータベース１０１４から取得した各過去アプリケーションの過去アプリケーションメタデータに対する類似度を計算する。ここでの類似度の尺度として、例えば対象アプリケーションメタデータと過去アプリケーションメタデータとの距離を用いてもよい。この場合、対象アプリケーションメタデータと過去アプリケーションメタデータとの距離が低い程、対象アプリケーションメタデータと過去アプリケーションメタデータは類似度が高いと言える。
【0056】
一例として、推定対象のアプリケーションの対象アプリケーションメタデータは、Ａ、Ｂ、Ｃの要素（プロセッサ要件、メモリ要件、コンテナ数等）からなるメタデータベクトルＸで表現されているとする。同様に、過去アプリケーションの過去アプリケーションメタデータは、ａ、ｂ、ｃの要素（プロセッサ要件、メモリ要件、コンテナ数等）からなるメタデータベクトルｘで表現されているとする。
この場合、対象アプリケーションメタデータＸと過去アプリケーションメタデータｘとの数値メタデータ距離Ｄｎは、ミンコフスキー距離やユークリッド距離等で計算されてもよい。対象アプリケーションメタデータＸと過去アプリケーションメタデータｘとの距離Ｄｎをユークリッド距離で計算する数式を数１で示す。
この場合、対象アプリケーションメタデータＸと過去アプリケーションメタデータｘとの数値メタデータ距離Ｄｎは、ミンコフスキー距離やユークリッド距離等で計算されてもよい。対象アプリケーションメタデータＸと過去アプリケーションメタデータｘとの距離Ｄｎをユークリッド距離で計算する数式を数１で示す。
【数1】
【0057】
以上では、アプリケーションメタデータが全て数値で表現されている場合について説明したが、アプリケーションメタデータの中には、コンテナイメージ名、サービスタイプラベル等のテキストで表現されているメタデータが存在する場合がある。この場合、これらのテキスト形式のメタデータは、後述するメタデータ変換テーブルデータベース１０１５を用いて、ワン・ホット・エンコーディング手法を行うことにより、ベクトル形式に変換することができる。ここで、ワン・ホット・エンコーディング手法によりベクトル形式に変換した対象アプリケーションメタデータをＵ、Ｖとし、ワン・ホット・エンコーディングングィング手法によりベクトル形式に変換した過去アプリケーションメタデータをｕ、ｖとする。
この場合、ワン・ホット・エンコーディング手法によりベクトル形式に変換した対象アプリケーションメタデータＵ、Ｖとワン・ホットエンコーディング手法によりベクトル形式に変換した過去アプリケーションメタデータｕ、ｖとのテキストメタデータ距離Ｄｔは、以下の数式２で求められる。
この場合、ワン・ホット・エンコーディング手法によりベクトル形式に変換した対象アプリケーションメタデータＵ、Ｖとワン・ホットエンコーディング手法によりベクトル形式に変換した過去アプリケーションメタデータｕ、ｖとのテキストメタデータ距離Ｄｔは、以下の数式２で求められる。
【数2】
【0058】
ここで、[[Ｕ.ｕ]]は、Ｕ.とｕとの内積の大きさを意味する。
上述した数値メタデータ距離Ｄｎ及びテキストメタデータ距離Ｄｔの両方を含む全体距離ＤAは、以下の数式３で求められる。
上述した数値メタデータ距離Ｄｎ及びテキストメタデータ距離Ｄｔの両方を含む全体距離ＤAは、以下の数式３で求められる。
【数3】
【0059】
また、アプリケーションメタデータの距離の別の計算方法では、アプリケーションメタデータ（例えば、特定のメタデータベクトル）に対して重みを割り当て、特定のアプリケーションメタデータの、全体距離への影響力を調整する（つまり、重みを強調する）ことが可能である。一例として、特定のアプリケーションが使用するコンテナイメージが「Ｗｅｂ Ｓｅｒｖｅｒ Ｂ」と記述するアプリケーションメタデータは、特定のアプリケーションのアプリケーションサービスが「バックエンド」と記述するアプリケーションメタデータよりも正確にアプリケーションを識別するため、「Ｗｅｂ Ｓｅｒｖｅｒ Ｂ」とのアプリケーションメタデータのメタデータベクトルに対してより高い重みを設定することで、識別力がより高いメタデータの、全体距離への影響力を強調することができる。
【0060】
次に、ステップＳ３０５では、消費電力推定部１０１１は、ステップＳ３０４で計算した、推定対象のアプリケーションの、各過去アプリケーションに対する類似度が所定の類似度基準を満たすか否かを判定する。ここでの所定の類似度基準は、例えば消費電力推定システム１６０の管理者によって設定されてもよく、既存の統計的手法によって定められてもよい。一例として、類似度の尺度が上述したユークリッド距離の場合、ここでの所定の類似度基準は、距離の上限を指定してもよい。従って、この距離の上限を下回る値は、類似度基準を満たすとみなされ、この距離の上限を超える値は、類似度基準を満たさないとみなされる。
ステップＳ３０４で計算した類似度が所定の類似度基準を満たす場合、本処理はステップＳ３０６へ進み、ステップＳ３０４で計算した類似度が所定の類似度基準を満たさない場合、本処理はステップＳ３０７へ進む。
ステップＳ３０４で計算した類似度が所定の類似度基準を満たす場合、本処理はステップＳ３０６へ進み、ステップＳ３０４で計算した類似度が所定の類似度基準を満たさない場合、本処理はステップＳ３０７へ進む。
【0061】
次に、ステップＳ３０６では、消費電力推定部１０１１は、所定の類似度基準を満たした過去アプリケーションのタイプを一意に識別するアプリケーションタイプ識別子を所定のメモリ領域に保存する。所定の類似度基準を満たした過去アプリケーションが複数あった場合、消費電力推定部１０１１は、それぞれの過去アプリケーションのアプリケーションタイプ識別子及び計算した類似度を保存する。以下では、推定対象のアプリケーションとの類似度基準を満たした過去アプリケーションを「類似アプリケーション」という。
【0062】
次に、ステップＳ３０７では、推定対象のアプリケーションの、過去アプリケーションに対する類似度の計算が全ての過去アプリケーションについて完了した後、消費電力推定部１０１１は、所定の類似度基準を満たす過去アプリケーション（つまり、推定対象のアプリケーションとの類似アプリケーション）が１つ以上あったか否かを判定する。類似アプリケーションが存在すると判定した場合、本処理はステップＳ３０８へ進み、類似アプリケーションが存在しないと判定した場合、本処理はステップＳ３０９へ進む。
【0063】
ステップＳ３０８では、類似アプリケーションが存在する場合、消費電力推定部１０１１は、ステップＳ３０６でアプリケーションタイプ識別子及び類似度を保存した類似アプリケーションの中から、類似度が最も高い類似アプリケーションを選択する。その後、消費電力推定部１０１１は、上述したアプリケーション消費電力データベース１０１６を参照し、選択した類似アプリケーションの消費電力の情報を上述したアプリケーション消費電力データベース１０１６から取得し、取得した類似アプリケーションの消費電力の情報を、推定対象のアプリケーションの第１の消費電力推定結果として実行管理部１０１３へ出力する。ここでの第１の消費電力推定結果は、例えば、推定対象のアプリケーションの消費電力の平均値の推定や、推定対象のアプリケーションの消費電力の最大値等の情報を含んでもよい。
【0064】
ステップＳ３０９では、類似アプリケーションが存在しない場合、消費電力推定部１０１１は、アプリケーション消費電力データベース１０１６に格納されている全ての過去アプリケーションの消費電力の平均値を計算し、計算した消費電力の平均値を第１の消費電力推定結果として実行管理部１０１３へ出力する。
【0065】
このように、推定対象のアプリケーションと所定の類似度基準を満たす過去アプリケーションの消費電力の情報を用いることで、推定対象のアプリケーションの消費電力を正確に推定する第１の消費電力推定結果を生成することができる。また、その後、上述した実行管理部１０１３は、この第１の消費電力推定結果に基づいて、推定対象のアプリケーションの適切な配置先となるノードクラスターをノードクラスター３０１０、３０２０．．．３０Ｎ０の中から判定することができる。配置先を判定した後、実行管理部１０１３は、推定対象のアプリケーションの配置を要求する配置指示を、判定したノードクラスターのマスターノードに送信し、推定対象のアプリケーションを当該ノードクラスターに配置する。
【0066】
次に、図４を参照して、本開示の実施形態に係る過去アプリケーションメタデータデータベースの構成について説明する。
【0067】
図４は、本開示の実施形態に係るメタデータデータベース１０１４の構成例を示す図である。上述したように、メタデータデータベース１０１４は、ノードクラスター３０１０、３０２０．．．３０Ｎ０によって実行されるアプリケーション（例えば、過去にノードクラスターに配置された過去アプリケーション）に関するメタデータを有するメタデータテーブルを格納するデータベースである。メタデータデータベース１０１４において、ノードクラスター３０１０、３０２０．．．３０Ｎ０毎に、専用のメタデータテーブル４１０、４２０、４Ｎ０が存在する。例えば、ノードクラスター３０１０に対応するメタデータテーブル４１０が存在し、ノードクラスター３０２０に対応するメタデータテーブル４２０が存在し、ノードクラスター３０Ｎ０に対応するメタデータテーブル４Ｎ０が存在する。
【0068】
一例として、メタデータテーブル４１０は、ノードクラスター３０１０上で実行されたことのある過去アプリケーションのアプリケーションメタデータを格納する。
図４に示すように、メタデータテーブル４１０は、「app1」や「app2」等の特定の過去アプリケーションのタイプを一意に識別するためのアプリケーションタイプ識別子４１１と、「フロントエンド」や「バックエンド」等のアプリケーションのティア４１２と、「ClusterIP」や「NodePort」等のサービスタイプ４１３と、コンテナの数を示すレプリカ数４１４と、「Ｗｅｂ Ｓｅｒｖｅｒ Ａ」や「Ｗｅｂ Ｓｅｒｖｅｒ Ｂ」」等のコンテナのイメージ名４１５とを格納してもよい。
図４に示すように、メタデータテーブル４１０は、「app1」や「app2」等の特定の過去アプリケーションのタイプを一意に識別するためのアプリケーションタイプ識別子４１１と、「フロントエンド」や「バックエンド」等のアプリケーションのティア４１２と、「ClusterIP」や「NodePort」等のサービスタイプ４１３と、コンテナの数を示すレプリカ数４１４と、「Ｗｅｂ Ｓｅｒｖｅｒ Ａ」や「Ｗｅｂ Ｓｅｒｖｅｒ Ｂ」」等のコンテナのイメージ名４１５とを格納してもよい。
【0069】
ここで、ティア４１２、サービスタイプ４１３及びイメージ名４１５等のテキスト形式の情報は、後述するワン・ホット・エンコーディングで得られるベクトル形式で格納される。より具体的には、メタデータテーブル４１０において、アプリケーションタイプ識別子が「app1」のアプリケーションについて、「フロントエンド」の値がベクトル形式では「1,0,...」と表現され、「NodePort」の値がベクトル形式では「1,0,0」と表現され、「Ｗｅｂ Ｓｅｒｖｅｒ Ａ」の値が「1,0,...」と表現される。
【0070】
初期の段階では、各メタデータテーブル４１０、４２０、４Ｎ０は、ノードクラスター３０１０、３０２０．．．３０Ｎ０で実行されたベンチマークアプリケーションのメタデータを格納してもよい。
その後、新たなアプリケーション（つまり、クライアント端末４０００に依頼された推定対象のアプリケーション）が特定のノードクラスター上で実行されるとき、当該新たなアプリケーションと類似している（つまり、所定の類似度基準を満たす）過去アプリケーションが同じノードクラスター上で実行され、アプリケーションメタデータがメタデータデータベース１０１４において既に保存されている場合、新たなアプリケーションのメタデータはメタデータデータベース１０１４において保存されない（つまり、重複しているメタデータの記録を防ぐため）。一方、推定対象のアプリケーションと類似している（つまり、所定の類似度基準を満たす）過去アプリケーションが同じノードクラスター上で実行されていない場合、当該推定対象のアプリケーションのアプリケーションメタデータがメタデータデータベース１０１４において保存され、メタデータデータベース１０１４が更新される。ここでの類似度は、上述した類似度の計算法（ユークリッド距離等）によって求められてもよい。
その後、新たなアプリケーション（つまり、クライアント端末４０００に依頼された推定対象のアプリケーション）が特定のノードクラスター上で実行されるとき、当該新たなアプリケーションと類似している（つまり、所定の類似度基準を満たす）過去アプリケーションが同じノードクラスター上で実行され、アプリケーションメタデータがメタデータデータベース１０１４において既に保存されている場合、新たなアプリケーションのメタデータはメタデータデータベース１０１４において保存されない（つまり、重複しているメタデータの記録を防ぐため）。一方、推定対象のアプリケーションと類似している（つまり、所定の類似度基準を満たす）過去アプリケーションが同じノードクラスター上で実行されていない場合、当該推定対象のアプリケーションのアプリケーションメタデータがメタデータデータベース１０１４において保存され、メタデータデータベース１０１４が更新される。ここでの類似度は、上述した類似度の計算法（ユークリッド距離等）によって求められてもよい。
【0071】
以上、説明の便宜上、メタデータテーブル４１０の構成について説明したが、メタデータテーブル４２０及びメタデータテーブル４Ｎ０も同様である。
【0072】
【0073】
図５は、本開示の実施形態に係るアプリケーション消費電力データベース１０１６の構成例を示す図である。上述したように、アプリケーション消費電力データベース１０１６は、ノードクラスター３０１０、３０２０．．．３０Ｎ０によって実行されるアプリケーションの消費電力の情報、当該アプリケーションのリソース使用量を示すアプリケーションプロフィールの保存先の情報及び当該アプリケーションの消費電力を推定するための電力モデルの保存先の情報を格納するデータベースである。
アプリケーション消費電力データベース１０１６において、ノードクラスター３０１０、３０２０．．．３０Ｎ０毎に、専用のアプリケーション消費電力テーブル５１０、５２０、５Ｎ０が存在する。例えば、ノードクラスター３０１０に対応するアプリケーション消費電力テーブル５１０が存在し、ノードクラスター３０２０に対応するアプリケーション消費電力テーブル５２０が存在し、ノードクラスター３０Ｎ０に対応するアプリケーション消費電力テーブル５Ｎ０が存在する。
アプリケーション消費電力データベース１０１６において、ノードクラスター３０１０、３０２０．．．３０Ｎ０毎に、専用のアプリケーション消費電力テーブル５１０、５２０、５Ｎ０が存在する。例えば、ノードクラスター３０１０に対応するアプリケーション消費電力テーブル５１０が存在し、ノードクラスター３０２０に対応するアプリケーション消費電力テーブル５２０が存在し、ノードクラスター３０Ｎ０に対応するアプリケーション消費電力テーブル５Ｎ０が存在する。
【0074】
アプリケーション消費電力テーブル５１０は、ノードクラスター３０１０上で実行されたことのある過去アプリケーションの消費電力の情報、アプリケーションプロフィールの保存先の情報及び電力モデルの保存先の情報を格納する。
【0075】
図５に示すように、アプリケーション消費電力テーブル５１０は、「app1」や「app2」等の特定の過去アプリケーションのタイプを一意に識別するためのアプリケーションタイプ識別子５１１と、特定のアプリケーションの消費電力の平均値及び最大値を示す消費電力情報５１２と、特定のアプリケーションのアプリケーションプロフィールの保存先５１３と、特定のアプリケーションのアプリケーションプロフィールに基づいて構築された電力モデルの保存先５１４とを格納してもよい。
【0076】
一例として、図５に示すように、アプリケーション消費電力テーブル５１０において、アプリケーションタイプ識別子が「app1」のアプリケーションについて、「２０Ｗ」の消費電力の平均値、「６０Ｗ」の消費電力の最大値、「Wl1.csv」のアプリケーションプロフィールの保存先、及び「model1.pk」の電力モデルが格納されている。
【0077】
初期の段階では、アプリケーション消費電力テーブル５１０、５２０、５Ｎ０は、ノードクラスター３０１０、３０２０．．．３０Ｎ０で実行されたベンチマークアプリケーションの消費電力の情報を格納してもよい。
その後、新たなアプリケーション（つまり、クライアント端末４０００に依頼された推定対象のアプリケーション）が特定のノードクラスター上で実行されるとき、当該推定対象のアプリケーションと類似している（つまり、所定の類似度基準を満たす）過去アプリケーション（以下、類似アプリケーション）が同じノードクラスター上で実行され、電力モデルの保存先がアプリケーション消費電力データベース１０１６において既に保存されている場合、実行管理部１０１３は、当該類似アプリケーションのアプリケーションプロフィール（例えば、第１のアプリケーションプロフィール）に対応する電力モデル（例えば第１の電力モデル）を電力モデルデータベース１０１８から特定する。
その後、新たなアプリケーション（つまり、クライアント端末４０００に依頼された推定対象のアプリケーション）が特定のノードクラスター上で実行されるとき、当該推定対象のアプリケーションと類似している（つまり、所定の類似度基準を満たす）過去アプリケーション（以下、類似アプリケーション）が同じノードクラスター上で実行され、電力モデルの保存先がアプリケーション消費電力データベース１０１６において既に保存されている場合、実行管理部１０１３は、当該類似アプリケーションのアプリケーションプロフィール（例えば、第１のアプリケーションプロフィール）に対応する電力モデル（例えば第１の電力モデル）を電力モデルデータベース１０１８から特定する。
【0078】
次に、実行管理部１０１３は、特定した電力モデルを用いて、推定対象の消費電力の推定を示す第２の消費電力推定結果を生成する。次に、実行管理部１０１３は、推定対象のアプリケーションを配置先ノード上で実行した場合の実際の消費電力を示す消費電力計測値と、推定対象のアプリケーションを配置先ノード上で実行した場合の実際のリソース使用量を示すリソース使用量計測値（プロセッサ使用量、メモリ使用量、ストレージ使用量、ネットワーク使用量等のリソース使用量を計測した値）を収集する。次に、消費電力計測値と第２の消費電力推定結果との乖離度が所定の乖離度基準を満たす場合、実行管理部１０１３は、類似アプリケーションのアプリケーションプロフィールを収集したリソース使用量計測値に基づいて更新し、第１の電力モデルを、更新した第１のアプリケーションプロフィールと、消費電力計測値とに基づいて更新する。
これにより、過去アプリケーションの電力モデルに基づいて推定される消費電力が、推定対象のアプリケーションを配置先ノード上で実行した場合の実際の消費電力に合わない場合、当該過去アプリケーションのアプリケーションプロフィールや電力モデルを実際に計測した情報に基づいて更新することで、電力モデルの精度を向上させることができる。
これにより、過去アプリケーションの電力モデルに基づいて推定される消費電力が、推定対象のアプリケーションを配置先ノード上で実行した場合の実際の消費電力に合わない場合、当該過去アプリケーションのアプリケーションプロフィールや電力モデルを実際に計測した情報に基づいて更新することで、電力モデルの精度を向上させることができる。
【0079】
ここでの「乖離度」とは、実際に計算した値（例えば、消費電力計測値）と、電力モデルで推定した値（例えば、第２の消費電力推定結果）との差分を意味する。また、所定の乖離度基準は、管理者に予め設定される閾値であってもよく、統計的手段によって自動的に定められた閾値であってもよい。
【0080】
なお、上述した消費電力推定方法３００によって生成され、推定対象のアプリケーションの配置先となるノードの判定に用いられる第１の消費電力推定結果は、類似アプリケーションの消費電力の平均値及び消費電力の最大値等の情報を含むのに対して、電力モデルに基づいて生成される第２の消費電力推定結果は、推定対象のアプリケーションによって使用されるリソース使用量を考慮した消費電力の予測であるため、第１の消費電力推定結果より細かな推定を示すことができる。
【0081】
一方、推定対象のアプリケーションと類似している過去アプリケーション（以下、類似アプリケーション）が同じノードクラスター上で実行されたことがない場合、実行管理部１０１３は、推定対象のアプリケーションを配置先ノード上で実行した場合の実際の消費電力を示す消費電力計測値と、推定対象のアプリケーションを配置先ノード上で実行した場合の実際のリソース使用量を示すリソース使用量計測値を収集し、リソース使用量計測値に基づいて推定対象のアプリケーションに対応する新たなアプリケーションプロフィール（例えば、第２のアプリケーションプロフィール）をアプリケーションプロフィールデータベース１０１７において作成する。推定対象のアプリケーションの第２のアプリケーションプロフィールは、推定対象のアプリケーションを実行した場合のプロセッサ使用量、メモリ使用量、ストレージ使用量、ネットワーク使用量を計測することで作成される。推定対象のアプリケーションの消費電力の情報は、実際に測定したノードクラスターの消費電力から、推定対象のアプリケーション以外に当該ノードクラスター上で実行されている他のアプリケーションの消費電力を引くことで得られ、当該ノードクラスターに対応するアプリケーション消費電力テーブルに格納される。
【0082】
次に、実行管理部１０１３は、作成した第２のアプリケーションプロフィールと、消費電力計測値とに基づいて、推定対象のアプリケーションに対応する新たな電力モデル（第２の電力モデル）を構築し、アプリケーション消費電力データベース１０１６に格納する。より具体的には、実行管理部１０１３は、プロセッサ使用量、メモリ使用量、ストレージ使用量、及びネットワーク使用量等のリソース使用量計測値を独立変数とし、消費電力計測値を従属変数とした回帰モデルを、推定対象のアプリケーションに対応する第２の電力モデルとして構築してもよい。
これにより、推定対象のアプリケーションと類似している過去アプリケーションがない場合、当該推定対象のアプリケーションに対応する新たなアプリケーションプロフィール及び電力モデルを作成することができる。このように作成したアプリケーションプロフィール及び電力モデルを用いることで、推定対象のアプリケーションのリソース使用量を考慮した消費電力を正確に推定することができる。
これにより、推定対象のアプリケーションと類似している過去アプリケーションがない場合、当該推定対象のアプリケーションに対応する新たなアプリケーションプロフィール及び電力モデルを作成することができる。このように作成したアプリケーションプロフィール及び電力モデルを用いることで、推定対象のアプリケーションのリソース使用量を考慮した消費電力を正確に推定することができる。
【0083】
以上、説明の便宜上、アプリケーション消費電力テーブル５１０の構成について説明したが、アプリケーション消費電力テーブル５２０及びアプリケーション消費電力テーブル５Ｎ０も同様である。
【0084】
図６は、本開示の実施形態に係るアプリケーションプロフィールデータベース１０１７の構成例を示す図である。上述したように、アプリケーションプロフィールデータベース１０１７は、アプリケーションのリソース使用量を示すアプリケーションプロフィールの情報を格納するデータベースである。アプリケーションプロフィールデータベース１０１７において、過去アプリケーション毎に、専用のアプリケーションプロフィール６１０、６２０、６Ｎ０が存在する。これらのアプリケーションプロフィール６１０、６２０、６Ｎ０は、例えばＣＳＶ（ｃｏｍｍａ ｓｅｐａｒａｔｅｄ ｖａｒｉａｂｌｅ）ファイルであってもよい。
【0085】
図６に示すように、アプリケーションプロフィール６１０は、例えば「wl1」等の特定のアプリケーションプロフィール識別子について、特定のリソース使用量の測定が行われた時刻６１１、アプリケーションによるＣＰＵ使用量６１２（ｍｉｌｌｉｃｐｕ（ｍ））、アプリケーションによるメモリ使用量６１３（メビバイト（Ｍｉ））、アプリケーションによるストレージ使用量６１４（キロバイト（ｋＢ））、アプリケーションによるネットワーク使用量６１５（キロバイト（ｋＢ））、及び消費電力６１６（ワット（Ｗ））を格納してもよい。対象のアプリケーションがノード上で単独で実行されている場合、この消費電力６１６は、ノード全体の消費電力値として測定されてもよく、同一のノード上で複数のアプリケーションが実行されている場合、消費電力６１６は、電力モデルに基づいて推定される消費電力値としてもよい。
【0086】
一例として、アプリケーションプロフィール６１０において、特定のアプリケーションについて、「２０ｍ」のＣＰＵ使用量、「１０Ｍｉのメモリ使用量、「１２ｋＢ」のストレージ使用量、「０ｋＢ」のネットワーク使用量、及び「５Ｗ」の消費電力が時刻「１２３００５」で測定されたことを示す。
【0087】
以上、説明の便宜上、アプリケーションプロフィール６１０の構成について説明したが、アプリケーションプロフィール６２０及びアプリケーションプロフィール６Ｎ０も同様である。
【0088】
次に、図７を参照して、本開示の実施形態に係るメタデータ変換の一例について説明する。
【0089】
本開示の実施形態に係るメタデータ変換７００の一例を示すフローチャートである。上述したように、アプリケーションメタデータの中には、アプリケーションリソースを数値で表現する数値メタデータに加えて、コンテナイメージ名、サービスタイプラベル等のアプリケーションリソースをテキストで表現するテキストメタデータが存在する場合がある。この場合、推定対象のアプリケーションと過去アプリケーションとのメタデータの比較をより容易に行うためには、テキスト形式のメタデータを、本開示の実施形態に係るメタデータ変換７００により、ベクトル形式に変換することが望ましい。
図７は、本開示の実施形態に係るメタデータ変換７００の流れを示す図である。
図７は、本開示の実施形態に係るメタデータ変換７００の流れを示す図である。
【0090】
上述したように、消費電力推定部１０１１がクライアント端末４０００から受信するアプリケーションマニフェスト７０５は、例えばアプリケーションリソースの仕様を指定するＹＡＭＬファイルであってもよい。上述したように、このアプリケーションリソースの仕様は、当該アプリケーションのアプリケーションメタデータである。また、アプリケーションメタデータは、数値から構成される数値メタデータ７１０と、テキストから構成されるテキストメタデータ７２０との２種類を含んでもよい。
【0091】
数値メタデータ７１０は、アプリケーションリソースの仕様を数値で示すメタデータである。例えば、図７に示すように、数値メタデータ７１０は、アプリケーションのレプリカ数が「４」、プロセッサ使用量が「０．２５％」、メモリの使用量が「６４Ｍｉ」、優先順位が「１０００」であることを示してもよい。この数値メタデータ７１０は、既に数値で表現されているため、これらの数値から構成した数値メタデータベクトル７１２（４，０．２５,６４,１０００）として表現し、メタデータデータベース１０１４に格納することができる。
【0092】
テキストメタデータ７２０は、アプリケーションリソースの仕様をテキストで示すメタデータである。また、テキストメタデータ７２０は、アプリケーションリソースの仕様を所定の固定テキスト値（つまり、キーワード）で示すキーワードメタデータ７３０と、アプリケーションリソースの仕様を自由に入力可能なテキストで示す非構造化テキストメタデータ７２１との２種類を含んでもよい。
【0093】
キーワードメタデータ７３０は、メタデータ変換テーブルデータベース１０１５におけるキーワードメタデータ変換テーブル８００を参照し、ワン・ホット・エンコーディングを行うことで、ベクトル形式に変換することができる。ワン・ホット・エンコーディングを行うことで得られたベクトルは、１つを除く全ての要素が「０」に設定されたベクトルである。「０」でない要素は「１」に設定される。値が「１」のベクトル内の位置は、テキスト値に対して一意であり、ベクトルのサイズは、一意のテキスト値の数に等しい。一例として、図７に示すキーワードメタデータ７３０における「ＣｌｕｓｔｅｒＩＰ」のサービスタイプは、ベクトル形式では、「0,1,0」と表現され、「Ｗｅｂ Ｓｅｒｖｅｒ Ｂ」のイメージは、ベクトル形式では、「0,1,...」と表現される。
【0094】
一方、非構造化テキストメタデータ７２１におけるテキストデータは、例えばユーザに自由に入力されるテキスト情報であるため、同じ意味を有していても、表記や呼び名の相違によるばらつきが生じることがある。例えば、「ＦＥ」、「フロントエンド」及び「ユーザ向け」との値は全て、表記が異なるが、当該アプリケーションがフロントエンドサービスであることを意味する情報である。同様に、「ｄｅｖ」及び「ｄｅｖｅｌｏｐｍｅｎｔ」の値は全て、当該アプリケーションが開発中であることを意味する情報である。そこで、このようなばらつきが存在する非構造化テキストメタデータを、一貫してベクトル形式に変換するためには、訓練済みのニューラルネットワークによる分類手法７２２を用いることが望ましい。非構造化テキストメタデータ７２１を、分類手法７２２によって処理することにより、同じ概念を意味するテキスト情報が全て同じカテゴリーに分類した、分類済み非構造化テキストメタデータ７２３を得ることができる。
その後、このように得られた分類済み非構造化テキストメタデータ７２３は、メタデータ変換テーブルデータベース１０１５における非構造化テキストメタデータ変換テーブル９００を参照し、ワン・ホット・エンコーディングを行うことで、ベクトル形式に変換することができる。一例として、図８に示す分類済み非構造化テキストメタデータ７２３におけるティアの値は、ベクトル形式では「1,0,0,...」と表現され、ネームスペースの値は、ベクトル形式では「0,1,0,...」と表現される。
その後、このように得られた分類済み非構造化テキストメタデータ７２３は、メタデータ変換テーブルデータベース１０１５における非構造化テキストメタデータ変換テーブル９００を参照し、ワン・ホット・エンコーディングを行うことで、ベクトル形式に変換することができる。一例として、図８に示す分類済み非構造化テキストメタデータ７２３におけるティアの値は、ベクトル形式では「1,0,0,...」と表現され、ネームスペースの値は、ベクトル形式では「0,1,0,...」と表現される。
【0095】
以上説明したメタデータ変換７００によれば、アプリケーションメタデータをベクトル形式に変換し、上述したメタデータデータベース１０１４に格納することができる。また、これにより、全てのメタデータをベクトル形式で表現することができるため、推定対象のアプリケーションと過去アプリケーションとのメタデータの比較をメタデータベクトル同士で行うことが可能となり、推定対象のアプリケーションと過去アプリケーションとの類似度を容易に計算することができる。
【0096】
上述したメタデータ変換７００において、テキスト形式のメタデータをベクトル形式に変換するためにはメタデータ変換テーブルデータベースに格納されるメタデータ変換テーブルが用いられる。したがって、次に、図８及び図９を参照して、本開示の実施形態に係るメタデータ変換テーブルデータベースについて説明する。
【0097】
図８は、本開示の実施形態に係るメタデータ変換テーブルデータベース１０１５におけるキーワードメタデータ変換テーブル８００の一例を示す図である。キーワードメタデータ変換テーブル８００は、テキストメタデータにおける特定のキーワードを所定のベクトルに対応付けることで、キーワードメタデータをベクトル形式に変換するためのテーブルである。
【0098】
図８に示すように、キーワードメタデータ変換テーブル８００は、「サービスタイプ」や「イメージ名」等のアプリケーションリソースの名称を示すキー８１１、「Ｎｏｄｅｐｏｒｔ」や「Ｗｅｂ Ｓｅｒｖｅｒ Ａ」等のアプリケーションリソースの可能な値８１２、及びこれらの値８１２に対応するベクトル形式８１３の情報を格納する。
キーワードメタデータ変換テーブル８００を用いることで、アプリケーションメタデータにおける特定のキーワードをベクトル形式に変換することができる。一例として、「サービスタイプ」とのアプリケーションリソースの値が「Ｎｏｄｅｐｏｒｔ」の場合、キーワードメタデータ変換テーブル８００を用いることで、「Ｎｏｄｅｐｏｒｔ」との値を[1,0,0]のベクトル形式に変換することができる。
キーワードメタデータ変換テーブル８００を用いることで、アプリケーションメタデータにおける特定のキーワードをベクトル形式に変換することができる。一例として、「サービスタイプ」とのアプリケーションリソースの値が「Ｎｏｄｅｐｏｒｔ」の場合、キーワードメタデータ変換テーブル８００を用いることで、「Ｎｏｄｅｐｏｒｔ」との値を[1,0,0]のベクトル形式に変換することができる。
【0099】
図９は、本開示の実施形態に係るメタデータ変換テーブルデータベース１０１５における非構造化テキストメタデータ変換テーブル９００の一例を示す図である。非構造化テキストメタデータ変換テーブル９００は、例えばユーザに自由に入力された非構造化テキスト情報を所定のベクトルに対応付けることで、非構造化テキストメタデータをベクトル形式に変換するためのテーブルである。
【0100】
図９に示すように、非構造化テキストメタデータ変換テーブル９００は、「ティア」や「ネームスペース」等のアプリケーションリソースの名称を示すキー９１１、「ｆｒｏｎｔｅｎｄ」や「ｄｅｖｅｌｏｐｍｅｎｔ」等のアプリケーションリソースの可能な値９１２、これらの値９１２が上述したニューラルネットワークベースの分類手法によって分類される推定カテゴリー９１３及びこれらの値９１２に対応するベクトル形式９１４の情報を格納する。
非構造化テキストメタデータ変換テーブル９００を用いることで、アプリケーションメタデータにおける、非構造化テキストメタデータをベクトル形式に変換することができる。一例として、「ティア」とのアプリケーションリソースの値が「ｂａｃｋｅｎｄ」の場合、非構造化テキストメタデータ変換テーブル９００を用いることで、「ｂａｃｋｅｎｄ」との値を[0,1,0,...]のベクトル形式に変換することができる。
なお、ここでは、ベクトル形式に変換する前に、アプリケーションメタデータにおける非構造化テキストメタデータは、既にニューラルネットワークベースの分類手法によって特定のカテゴリーに分類されたことを前提とする。
非構造化テキストメタデータ変換テーブル９００を用いることで、アプリケーションメタデータにおける、非構造化テキストメタデータをベクトル形式に変換することができる。一例として、「ティア」とのアプリケーションリソースの値が「ｂａｃｋｅｎｄ」の場合、非構造化テキストメタデータ変換テーブル９００を用いることで、「ｂａｃｋｅｎｄ」との値を[0,1,0,...]のベクトル形式に変換することができる。
なお、ここでは、ベクトル形式に変換する前に、アプリケーションメタデータにおける非構造化テキストメタデータは、既にニューラルネットワークベースの分類手法によって特定のカテゴリーに分類されたことを前提とする。
【0101】
初期段階では、上述したメタデータ変換テーブルデータベース１０１５におけるキーワードメタデータ変換テーブル８００及び非構造化テキストメタデータ変換テーブル９００は、ベンチマークアプリケーションに関するアプリケーションメタデータに基づいて構成される。
その後、新たなアプリケーション（例えば、依頼されたアプリケーション）が特定のノードクラスター上で実行されるとき、キーワードメタデータ変換テーブル８００及び非構造化テキストメタデータ変換テーブル９００は、当該新たなアプリケーションのアプリケーションマニフェストから抽出されたアプリケーションメタデータに基づいて更新される。
その後、新たなアプリケーション（例えば、依頼されたアプリケーション）が特定のノードクラスター上で実行されるとき、キーワードメタデータ変換テーブル８００及び非構造化テキストメタデータ変換テーブル９００は、当該新たなアプリケーションのアプリケーションマニフェストから抽出されたアプリケーションメタデータに基づいて更新される。
【0102】
以上説明した消費電力推定手段によれば、分散コンピューティング環境のノードに配置する対象のアプリケーションと、過去に当該ノードで実行されたアプリケーションとの類似度をそれぞれのアプリケーションのメタデータに基づいて計算し、所定の類似度基準を満たす過去のアプリケーションについて計測した消費電力の情報を用いることで、多様なアプリケーションの消費電力を正確に推定することが可能となる。
【0103】
このように生成したアプリケーションの消費電力推定に基づいて、当該アプリケーションを適切なノードクラスターに配置することができる。また、アプリケーションを適切なノードクラスターに配置した後、アプリケーションの実際の消費電力を計測し分析することで、アプリケーションのリソース使用量を考慮した消費電力を推定する電力モデルの精度を評価することができる。評価の結果、電力モデルの精度が所定の基準を満たさない場合（つまり、電力モデルの推定が実際に計測した値から乖離している場合）、アプリケーションの実際の消費電力の情報に基づいて電力モデルを更新することで、電力モデルの精度を向上させることができる。
【0104】
一方、推定対象のアプリケーションと所定の類似度基準を満たす過去アプリケーションがない場合、推定対象のアプリケーションの消費電力推定は、当該ノードクラスターにおいて実行された過去アプリケーションの消費電力の平均値に基づいて生成される。その後、推定対象のアプリケーションは、この消費電力推定に基づいて適切なノードクラスターに配置される。また、配置したアプリケーションの実際の消費電力を計測し分析することで、当該アプリケーションに対応する新たな電力モデルを構築することができる。
【0105】
このように、時間が経過するにつれて、ノードクラスターは様々なアプリケーションをホストし、ホストした各アプリケーションについて既存の電力モデルを更新したり、新たな電力モデルを作成したりすることにより、多様なアプリケーションに対応する電力モデルのレパートリーが構築されるため、多様なアプリケーションについて消費電力を正確に推定することが可能となる。
【0106】
以上、本発明の実施の形態について説明したが、本発明は、上述した実施の形態に限定されるものではなく、本発明の要旨を逸脱しない範囲において種々の変更が可能である。
【符号の説明】
【0107】
１６０ 消費電力推定システム
１０００ クラスター管理装置
１０１０ 消費電力推定装置
１０１１ 消費電力推定部
１０１３ 実行管理部
１０１４ メタデータデータベース
１０１５ メタデータ変換テーブルデータベース
１０１６ アプリケーション消費電力データベース
１０１７ アプリケーションプロフィールデータベース
１０１８ 電力モデルデータベース
１０２０ 入出力装置
１０３０ プロセッサ
１０４０ メモリ
１０５０ ネットワークインターフェース
２０００ 通信ネットワーク
３０１０、３０２０．．．３０Ｎ０ ノードクラスター
３０１１ マスターノード
３０１２、３０１３、３０１Ｎ スレーブノード
４０００ クライアント端末
１０００ クラスター管理装置
１０１０ 消費電力推定装置
１０１１ 消費電力推定部
１０１３ 実行管理部
１０１４ メタデータデータベース
１０１５ メタデータ変換テーブルデータベース
１０１６ アプリケーション消費電力データベース
１０１７ アプリケーションプロフィールデータベース
１０１８ 電力モデルデータベース
１０２０ 入出力装置
１０３０ プロセッサ
１０４０ メモリ
１０５０ ネットワークインターフェース
２０００ 通信ネットワーク
３０１０、３０２０．．．３０Ｎ０ ノードクラスター
３０１１ マスターノード
３０１２、３０１３、３０１Ｎ スレーブノード
４０００ クライアント端末
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】