特許 7546724 クラウドリソース割り当てシステム、装置、及び方法

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

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2024-08-29

(45)【発行日】2024-09-06

(54)【発明の名称】クラウドリソース割り当てシステム、装置、及び方法

(51)【国際特許分類】

   G06F 9/50 20060101AFI20240830BHJP

【ＦＩ】

G06F9/50 150C

G06F9/50 150D

【請求項の数】 25

【外国語出願】

(21)【出願番号】P 2023078773

(22)【出願日】2023-05-11

(65)【公開番号】P2024083208

(43)【公開日】2024-06-20

【審査請求日】2023-05-11

(31)【優先権主張番号】111147322

(32)【優先日】2022-12-09

(33)【優先権主張国・地域又は機関】TW

(73)【特許権者】

【識別番号】390023582

【氏名又は名称】財團法人工業技術研究院

【氏名又は名称原語表記】ＩＮＤＵＳＴＲＩＡＬ ＴＥＣＨＮＯＬＯＧＹ ＲＥＳＥＡＲＣＨ ＩＮＳＴＩＴＵＴＥ

【住所又は居所原語表記】Ｎｏ．１９５，Ｓｅｃ．４，ＣｈｕｎｇＨｓｉｎｇＲｄ．，Ｃｈｕｔｕｎｇ，Ｈｓｉｎｃｈｕ，Ｔａｉｗａｎ ３１０４０

(74)【代理人】

【識別番号】100081961

【弁理士】

【氏名又は名称】木内 光春

(74)【代理人】

【識別番号】100112564

【弁理士】

【氏名又は名称】大熊 考一

(74)【代理人】

【識別番号】100163500

【弁理士】

【氏名又は名称】片桐 貞典

(74)【代理人】

【識別番号】230115598

【弁護士】

【氏名又は名称】木内 加奈子

(72)【発明者】

【氏名】▲フアン▼ 俊傑

(72)【発明者】

【氏名】王 子嘉

(72)【発明者】

【氏名】李 建宏

(72)【発明者】

【氏名】▲ウー▼ 奕霖

(72)【発明者】

【氏名】▲ラァィ▼ 國弘

(72)【発明者】

【氏名】▲ウー▼ 藺剛

【審査官】坂東 博司

(56)【参考文献】

【文献】米国特許出願公開第２０２２／０２６１２５４（ＵＳ，Ａ１）

【文献】特表２０１５－５３０６５６（ＪＰ，Ａ）

【文献】特開２００８－２３４６３２（ＪＰ，Ａ）

【文献】国際公開第２０１２／１４１５７３（ＷＯ，Ａ１）

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｇ０６Ｆ ９／５０

(57)【特許請求の範囲】

【請求項1】

複数のワーカノード及びマスターノードを含むクラウドリソース割り当てシステムであって、
前記マスターノードは、
リソースマネージャを介して、前記複数のワーカノードによってそれぞれ報告された複数のノードリソース情報を取得し、前記ノードリソース情報は、作業負荷をチェックした作業負荷モニタリングデータと、電力消費をチェックした電力消費モニタリングデータを含み、前記電力消費モニタリングデータは、電力消費の統計とエネルギー効率、ワーカノードレベル、ジョブグループレベル、ジョブスケジュールレベルを含むマルチレベルのパフォーマンスと電力消費の統計と分析情報、及び可能なパフォーマンスと電力消費の調整戦略の提案を含み、
ジョブスケジューラを介して、待機キューから取得したジョブリクエストのジョブプロファイルを解析し、前記複数のノードリソース情報及び前記ジョブプロファイルに基づいて、前記ジョブリクエストで要求された処理対象ジョブに対して直接リソース割り当て又は間接リソース割り当てを実行するかを決定するように構成される
オーケストレータ、を備え、
前記オーケストレータは、前記ノードリソース情報及び前記ジョブプロファイルに基づいて、前記ワーカノードの利用可能なリソースが前記ジョブリクエストのリソース要件を満足するかどうかを判断し、
前記ワーカノードのうちの少なくとも１つの前記利用可能なリソースが、前記ジョブリクエストの前記リソース要件を満足する場合、前記処理対象ジョブに対して前記直接リソース割り当てが実行されることが決定され、
いずれの前記ワーカノードの前記利用可能なリソースも、前記ジョブリクエストの前記リソース要件を満足しない場合、及び１つ又は複数の低優先度ジョブが使用するリソースをプリエンプションした後、前記ジョブリクエストの前記リソース要件を満足する場合、前記処理対象ジョブに対して前記間接リソース割り当てが実行されることが決定されるように構成され、
前記直接リソース割り当てを実行する決定に応答して、前記オーケストレータは、
前記ジョブスケジューラを介して、前記複数のワーカノードの中から、前記ジョブプロファイルに一致する前記利用可能なリソースを有する第１のワーカノードを見つけ、
前記リソースマネージャを介して、前記処理対象ジョブを前記第１のワーカノードにディスパッチし、
前記ジョブスケジューラを介して、前記処理対象ジョブを実行キューに入れるように構成され、
前記間接リソース割り当てを実行する決定に応答して、前記オーケストレータは、
前記ジョブスケジューラを介して、前記複数のワーカノードの中から前記低優先度ジョブを有する第２のワーカノードを見つけ、前記第２のワーカノードが前記低優先度ジョブの運用状態をバックアップするように前記第２のワーカノードに通知し、前記第２のワーカノードによって前記低優先度ジョブの前記運用状態をバックアップした後、前記低優先度ジョブが使用しているリソースを解放し、
前記リソースマネージャを介した前記第２のワーカノードからリソース解放通知を受信したことに応答して、前記ジョブスケジューラを介して、前記低優先度ジョブに対応する別のジョブリクエストを前記待機キューに入れ、
前記リソースマネージャを介して、前記処理対象ジョブを前記第２のワーカノードにディスパッチし、
前記ジョブスケジューラを介して、前記処理対象ジョブを前記実行キューに入れるように構成される、
クラウドリソース割り当てシステム。

【請求項2】

前記オーケストレータによって前記直接リソース割り当てを実行する決定に応答して、前記ジョブスケジューラを介して、ジョブ目標を満足する前記第１のワーカノードが見つけられ、ここで、前記ジョブ目標は、最小電力消費コスト、最高のパフォーマンス、又は総合的な測定目標である、
請求項１に記載のクラウドリソース割り当てシステム。

【請求項3】

前記オーケストレータによって前記間接リソース割り当ての実行に応答して、前記ジョブスケジューラを介して、前記低優先度ジョブを有する前記第２のワーカノードを見つけることと、
前記第２のワーカノードが前記低優先度ジョブによって使用されているリソースを解放した後に調整された利用可能なリソースが前記ジョブリクエストの前記リソース要件をまだ満足しないことに応答して、前記調整された利用可能なリソースが前記ジョブリクエストの前記リソース要件を満足するまで、前記ジョブスケジューラを介して、別の低優先度ジョブによって使用されているリソースを継続的に解放するように、前記第２のワーカノードに通知することと、を含む、
請求項１に記載のクラウドリソース割り当てシステム。

【請求項4】

前記マスターノードにおいて、前記オーケストレータは、
前記複数のワーカノードの前記利用可能なリソースのいずれも前記ジョブリクエストの前記リソース要件を満足しないと判断した後、前記複数のワーカノードのいずれも前記間接リソース割り当てを実行するのに適格ではないと判断したことに応答して、前記ジョブプロファイル内の複数のアプリケーショングループメンバのそれぞれに対して、前記直接リソース割り当てを実行し、
前記直接リソース割り当ての実行には、
前記ジョブスケジューラを介して、前記複数のワーカノードの中から、前記アプリケーショングループメンバのリソース要件を満足する複数の第３のワーカノードを見つけることと、
前記リソースマネージャを介して、各前記アプリケーショングループメンバを対応する第３のワーカノードにディスパッチすることと、
前記ジョブスケジューラを介して、前記処理対象ジョブを前記実行キューに入れることと、を含む、
請求項１に記載のクラウドリソース割り当てシステム。

【請求項5】

前記マスターノードは、
前記複数のワーカノードによってそれぞれ報告された前記複数のノードリソース情報を収集するように構成されるリソースモニターと、
をさらに含み、
前記ジョブスケジューラを介して、前記処理対象ジョブを前記実行キューに入れた後、前記オーケストレータは、
前記リソースマネージャを介して、前記処理対象ジョブが終了したことを示す通知を受信したことに応答して、前記ジョブスケジューラを介して、前記実行キューから前記処理対象ジョブを削除するように構成される、
請求項１に記載のクラウドリソース割り当てシステム。

【請求項6】

各前記ワーカノードが、ローカルマネージャと、を備え、
前記ローカルマネージャは、
システムインスペクタを介して、システムリソースの使用量を確認し、
パフォーマンスデータインスペクタを介して、各コンテナの作業負荷によって実際に使用されるコンテナリソースの使用量を確認し、前記システムリソースの使用量及び前記コンテナリソースの使用量に基づいて、作業負荷モニタリングデータを取得し、
電力消費インスペクターを介して、電力消費モニタリングデータを取得する、
ように構成され、
各前記ワーカノードに対応するノードリソース情報は、前記作業負荷モニタリングデータ及び前記電力消費モニタリングデータを含む、
請求項１に記載のクラウドリソース割り当てシステム。

【請求項7】

各前記ワーカノードにおいて、前記ローカルマネージャはさらに、
前記パフォーマンスデータインスペクタを介して、前記作業負荷モニタリングデータが所定作業負荷上限を超えているかどうかを判断し、前記作業負荷モニタリングデータが前記所定作業負荷上限を超えているとの判断に応答して、前記作業負荷モニタリングデータに警告ラベルをマークする、ように構成される、
請求項６に記載のクラウドリソース割り当てシステム。

【請求項8】

前記マスターノードは、さらに、
パフォーマンスデータコレクタを介して、各前記ワーカノードによって報告された前記作業負荷モニタリングデータを収集し、前記作業負荷モニタリングデータに前記警告ラベルがマークされたことに応答して、予め設定された時間に基づいて、履歴データを前記作業負荷モニタリングデータに追加するように構成されるリソースモニターと、
作業負荷アナライザを介して、前記パフォーマンスデータコレクタから前記作業負荷モニタリングデータを受信し、前記作業負荷モニタリングデータを分析することにより、各前記ワーカノードにリソース異常があるかどうかを判断するように構成される作業負荷マネージャと、を備える、
請求項７に記載のクラウドリソース割り当てシステム。

【請求項9】

前記作業負荷マネージャは、さらに、
前記作業負荷アナライザを介して、前記リソース異常がワークロード過負荷又はシステムリソース損失であると判断したことに応答して、前記リソースマネージャに通知し、前記リソースマネージャが状態移行コマンドを状態移行ハンドラに送信し、
前記状態移行ハンドラを介して、前記リソース異常が発生したワーカノードごとに、前記リソース異常が前記ワークロード過負荷であると判断した場合は、ジョブグループレベルの状態移行提案を生成し、前記リソース異常が前記システムリソース損失であると判断した場合は、ノードレベルの状態移行提案を生成するように構成される、
請求項８に記載のクラウドリソース割り当てシステム。

【請求項10】

前記マスターノードは、さらに、
電力消費コレクタを介して、各前記ワーカノードによって報告された前記電力消費モニタリングデータを収集するように構成されるリソースモニタと、
パワーマネージャと、を備え、
前記パワーマネージャは、
パワーアナライザを介して、前記電力消費コレクタから前記電力消費モニタリングデータを受信し、前記電力消費モニタリングデータを分析することによって電力消費分析結果を取得し、前記電力消費分析結果に基づいて、電力消費調整戦略を生成し、
パワープレーナを介して、前記電力消費調整戦略に基づいて、電力調整提案を生成するように構成される、
請求項６に記載のクラウドリソース割り当てシステム。

【請求項11】

前記マスターノードにおいて、
前記オーケストレータは、前記リソースマネージャを介して、前記ジョブリクエストを取得した後、前記複数のノードリソース情報に基づいて前記複数のワーカノードが完全にロードされているかどうかを判断するように構成され、
パワーマネージャを介して、前記複数のワーカノードが完全にロードされたことに応答して、スリープモード又はパワーオフモードの各前記ワーカノードに対してパワーオンコマンドを発行し、
前記リソースマネージャを介して、前記スリープモード又は前記パワーオフモードの各前記ワーカノードが動作状態に移行することに応答して、前記複数のワーカノードによってそれぞれ報告された前記複数のノードリソース情報を再取得する、
請求項１に記載のクラウドリソース割り当てシステム。

【請求項12】

各前記ワーカノードが、ローカルマネージャを備え、
前記ローカルマネージャは
ジョブハンドラを介して、前記マスターノードからリソース管理コマンドの受信に応答して、コンテナライフタイムサイクル管理を実行することであって、前記コンテナライフタイムサイクル管理は、コンテナ作成、コンテナ削除、及び状態移行のうちの１つを含み、
パワーモジュールハンドラを介して、前記マスターノードから電力調整提案を受信することに応答して、システムパワー状態を調整することであって、前記システムパワー状態は、パワーオフモード、スリープモード、及び特定電力消費モードのうちの１つを含む、
ように構成される、
請求項１に記載のクラウドリソース割り当てシステム。

【請求項13】

オーケストレータを格納し、待機キュー及び実行キューを提供するストレージであって、前記オーケストレータがリソースマネージャ及びジョブスケジューラを備えるストレージと、
前記ストレージに結合されたプロセッサと、を備え
前記プロセッサは、
前記リソースマネージャを介して、複数のワーカノードによってそれぞれ報告された複数のノードリソース情報を取得し、前記ノードリソース情報は、作業負荷をチェックした作業負荷モニタリングデータと、電力消費をチェックした電力消費モニタリングデータを含み、前記電力消費モニタリングデータは、電力消費の統計とエネルギー効率、ワーカノードレベル、ジョブグループレベル、ジョブスケジュールレベルを含むマルチレベルのパフォーマンスと電力消費の統計と分析情報、及び可能なパフォーマンスと電力消費の調整戦略の提案を含むことと、
前記ジョブスケジューラを介して、前記待機キューから取得したジョブリクエストのジョブプロファイルを解析し、前記複数のノードリソース情報及び前記ジョブプロファイルに基づいて、前記ジョブリクエストで要求された処理対象ジョブに対して直接リソース割り当て又は間接リソース割り当てを実行するかを決定するように構成され、
前記オーケストレータは、前記ノードリソース情報及び前記ジョブプロファイルに基づいて、前記ワーカノードの利用可能なリソースが前記ジョブリクエストのリソース要件を満足するかどうかを判断し、
前記ワーカノードのうちの少なくとも１つの前記利用可能なリソースが、前記ジョブリクエストの前記リソース要件を満足する場合、前記処理対象ジョブに対して前記直接リソース割り当てが実行されることが決定され、
いずれの前記ワーカノードの前記利用可能なリソースも、前記ジョブリクエストの前記リソース要件を満足しない場合、及び１つ又は複数の低優先度ジョブが使用するリソースをプリエンプションした後、前記ジョブリクエストの前記リソース要件を満足する場合、前記処理対象ジョブに対して前記間接リソース割り当てが実行されることが決定されるように構成され、
前記直接リソース割り当てを実行する決定に応答して、前記プロセッサは、
前記ジョブスケジューラを介して、前記複数のワーカノードの中から、前記ジョブプロファイルに一致する前記利用可能なリソースを有する第１のワーカノードを見つけ、
前記リソースマネージャを介して、前記処理対象ジョブを前記第１のワーカノードにディスパッチし、
前記ジョブスケジューラを介して、前記処理対象ジョブを前記実行キューに入れるように構成され、
前記間接リソース割り当てを実行する決定に応答して、前記プロセッサは、
前記ジョブスケジューラを介して、前記複数のワーカノードの中から前記低優先度ジョブを有する第２のワーカノードを見つけ、前記第２のワーカノードが前記低優先度ジョブの運用状態をバックアップするように前記第２のワーカノードに通知し、前記第２のワーカノードによって前記低優先度ジョブの前記運用状態をバックアップした後、前記低優先度ジョブが使用しているリソースを解放し、
前記リソースマネージャを介した前記第２のワーカノードからリソース解放通知の受信に応答して、前記ジョブスケジューラを介して、前記低優先度ジョブに対応する別のジョブリクエストを前記待機キューに入れ、
前記リソースマネージャを介して、前記処理対象ジョブを前記第２のワーカノードにディスパッチし、
前記ジョブスケジューラを介して、前記処理対象ジョブを前記実行キューに入れるように構成される、
クラウドリソース割り当て装置。

【請求項14】

クラウドリソース割り当て装置を介して、
複数のワーカノードによってそれぞれ報告された複数のノードリソース情報を取得し、前記ノードリソース情報は、作業負荷をチェックした作業負荷モニタリングデータと、電力消費をチェックした電力消費モニタリングデータを含み、前記電力消費モニタリングデータは、電力消費の統計とエネルギー効率、ワーカノードレベル、ジョブグループレベル、ジョブスケジュールレベルを含むマルチレベルのパフォーマンスと電力消費の統計と分析情報、及び可能なパフォーマンスと電力消費の調整戦略の提案を含むことと、
待機キューから取得したジョブリクエストのジョブプロファイルを解析し、前記複数のノードリソース情報及び前記ジョブプロファイルに基づいて、前記ジョブリクエストで要求された処理対象ジョブに対して直接リソース割り当て又は間接リソース割り当てを実行するかを決定することと、
を実行し、
前記オーケストレータは、前記ノードリソース情報及び前記ジョブプロファイルに基づいて、前記ワーカノードの利用可能なリソースが前記ジョブリクエストのリソース要件を満足するかどうかを判断し、
前記ワーカノードのうちの少なくとも１つの前記利用可能なリソースが、前記ジョブリクエストの前記リソース要件を満足する場合、前記処理対象ジョブに対して前記直接リソース割り当てが実行されることが決定され、
いずれの前記ワーカノードの前記利用可能なリソースも、前記ジョブリクエストの前記リソース要件を満足しない場合、及び１つ又は複数の低優先度ジョブが使用するリソースをプリエンプションした後、前記ジョブリクエストの前記リソース要件を満足する場合、前記処理対象ジョブに対して前記間接リソース割り当てが実行されることが決定されるように構成され、
前記直接リソース割り当てを実行することを決定することは、
前記複数のワーカノードの中から、前記ジョブプロファイルに一致する前記利用可能なリソースを有する第１のワーカノードを見つけることと、
前記処理対象ジョブを前記第１のワーカノードにディスパッチすることと、
前記処理対象ジョブを実行キューに入れることと、を含み、
前記間接リソース割り当てを実行することは、
前記複数のワーカノードの中から前記低優先度ジョブを有する第２のワーカノードを見つけ、前記第２のワーカノードが前記低優先度ジョブの運用状態をバックアップするように前記第２のワーカノードに通知し、前記第２のワーカノードによって前記低優先度ジョブの前記運用状態をバックアップした後、前記低優先度ジョブが使用しているリソースを解放することと、
前記第２のワーカノードからリソース解放通知を受信したことに応答して、前記低優先度ジョブに対応する別のジョブリクエストを前記待機キューに入れ、
前記処理対象ジョブを前記第２のワーカノードにディスパッチすることと、
前記処理対象ジョブを前記実行キューに入れることと、を含む、
クラウドリソース割り当て方法。

【請求項15】

前記処理対象ジョブに対して前記直接リソース割り当てを実行することを決定するステップは、
ジョブ目標を満足する前記第１のワーカノードを見つけることを含み、前記ジョブ目標は、最小の電力消費コスト、最高のパフォーマンス、又は総合的な測定目標である
請求項１４に記載のクラウドリソース割り当て方法。

【請求項16】

前記処理対象ジョブに対して前記間接リソース割り当てを実行することを決定するステップは、
前記低優先度ジョブを有する前記第２のワーカノードを見つけることと、
前記第２のワーカノードが前記低優先度ジョブによって使用されているリソースを解放した後に調整された利用可能なリソースが前記ジョブリクエストの前記リソース要件をまだ満足しないことに応答して、前記調整された利用可能なリソースが前記ジョブリクエストの前記リソース要件を満足するまで、別の低優先度ジョブによって使用されているリソースを継続的に解放するように、前記第２のワーカノードに通知することと、を含む、
請求項１５に記載のクラウドリソース割り当て方法。

【請求項17】

前記クラウドリソース割り当て装置を介して、
前記複数のワーカノードの前記利用可能なリソースのいずれも前記ジョブリクエストの前記リソース要件を満足しないと判断した後、前記複数のワーカノードのいずれも前記間接リソース割り当てを実行するのに適格ではないと判断したことに応答して、前記ジョブプロファイル内の複数のアプリケーショングループメンバのそれぞれに対して、前記直接リソース割り当てを実行することと、
を実行することをさらに含み、
前記直接リソース割り当ての実行には、
前記複数のワーカノードの中から、前記アプリケーショングループメンバのリソース要件を満足する複数の第３のワーカノードを見つけることと、
各前記アプリケーショングループメンバを対応する第３のワーカノードにディスパッチすることと、
前記処理対象ジョブを前記実行キューに入れることと、を含む、
請求項１５に記載のクラウドリソース割り当て方法。

【請求項18】

前記クラウドリソース割り当て装置を介して、
前記複数のワーカノードによってそれぞれ報告された前記複数のノードリソース情報を収集し、
前記処理対象ジョブを前記実行キューに入れた後、前記処理対象ジョブが終了したことを示す通知を受信したことに応答して、前記実行キューから前記処理対象ジョブを削除すること、
を実行することをさらに含む、
請求項１４に記載のクラウドリソース割り当て方法。

【請求項19】

各前記ワーカノードを介して、
システムリソースの使用量を確認し、
各コンテナの作業負荷によって実際に使用されるコンテナリソースの使用量を確認し、前記システムリソースの使用量及び前記コンテナリソースの使用量に基づいて、作業負荷モニタリングデータを取得し、
電力消費モニタリングデータを取得すること、
を実行することをさらに含み、
各前記ワーカノードに対応するノードリソース情報は、前記作業負荷モニタリングデータ及び前記電力消費モニタリングデータを含む、
請求項１４に記載のクラウドリソース割り当て方法。

【請求項20】

各前記ワーカノードを介して、
前記作業負荷モニタリングデータが所定作業負荷上限を超えているかどうかを判断し、前記作業負荷モニタリングデータが前記所定作業負荷上限を超えていると判断したことに応答して、前記作業負荷モニタリングデータに警告ラベルをマークすること、
を実行することをさらに含む、
請求項１９に記載のクラウドリソース割り当て方法。

【請求項21】

前記クラウドリソース割り当て装置を介して、
各前記ワーカノードによって報告された前記作業負荷モニタリングデータを収集し、前記作業負荷モニタリングデータに前記警告ラベルがマークされたことに応答して、予め設定された時間に基づいて、履歴データを前記作業負荷モニタリングデータに追加し、
前記作業負荷モニタリングデータを分析することにより、各前記ワーカノードにリソース異常があるかどうかを判断すること、
を実行することをさらに含む、
請求項２０に記載のクラウドリソース割り当て方法。

【請求項22】

各前記ワーカノードが前記リソース異常を有するかどうかを判断した後、さらに、
前記リソース異常がワークロード過負荷であると判断した場合は、ジョブグループレベルの状態移行提案を生成し、前記リソース異常がシステムリソース損失であると判断した場合は、ノードレベルの状態移行提案を生成することと、を含む、
請求項２１に記載のクラウドリソース割り当て方法。

【請求項23】

前記クラウドリソース割り当て装置を介して、
各前記ワーカノードによって報告された前記電力消費モニタリングデータを収集し、
前記電力消費モニタリングデータを分析することによって、電力消費分析結果を取得し、前記電力消費分析結果に基づいて、電力消費調整戦略を生成し、
前記電力消費調整戦略に基づいて、電力調整提案を生成すること、
を実行することをさらに含む、
請求項１９に記載のクラウドリソース割り当て方法。

【請求項24】

前記クラウドリソース割り当て装置を介して、
前記ジョブリクエストを取得した後、前記複数のノードリソース情報に基づいて、前記複数のワーカノードが完全にロードされているかどうかを判断し、
前記複数のワーカノードが完全にロードされたことに応答して、スリープモード又はパワーオフモードの各前記ワーカノードに対してパワーオンコマンドを発行し、
前記スリープモード又は前記パワーオフモードの各前記ワーカノードが動作状態に移行することに応答して、前記複数のワーカノードによってそれぞれ報告された前記複数のノードリソース情報を再取得すること、
を実行することをさらに含む、
請求項１４に記載のクラウドリソース割り当て方法。

【請求項25】

各前記ワーカノードを介して、
前記クラウドリソース割り当て装置からリソース管理コマンドの受信に応答して、コンテナライフタイムサイクル管理を実行することであって、前記コンテナライフタイムサイクル管理は、コンテナ作成、コンテナ削除、及び状態移行のうちの１つを含み、
前記クラウドリソース割り当て装置から電力調整提案を受信することに応答して、システムパワー状態を調整することであって、前記システムパワー状態は、パワーオフモード、スリープモード、及び特定電力消費モードのうちの１つを含むこと、
を実行することをさらに含む、
請求項１４に記載のクラウドリソース割り当て方法。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、クラウドリソース割り当てシステム、装置、及び方法に関する。

【背景技術】

【0002】

クラウドコンピューティングとエッジコンピューティングのグローバル市場では、さまざまな新しいテクノロジーとアプリケーションの人気により、クラウドコンピューティングとエッジコンピューティングの世界市場規模が拡大し続けている。さまざまな業界でＩｏＴテクノロジーの人気が高まっていることで、グローバルなエッジコンピューティング市場の成長が促進されている。

【0003】

クラウドコンピューティングは、リアルタイムのアプリケーションサービスをサポートする軽量のコンテナサービスを提供する。クラウドアプリケーション（メタバース、クラウドゲーム、人工知能モニタリングなど）は、マルチサービスと即時応答の特性を備えている。現在、コンテナオーケストレーションテクノロジーにはプリエンプティブなリソース管理が装備されており、複数のサービスに優先順位が設定されて、サービス品質（Ｑｕａｌｉｔｙ ｏｆ Ｓｅｒｖｉｃｅ，ＱｏＳ）が保証されたコンテナプロビジョニングが提供される。コンテナは、ソフトウェアサービスの実行に必要なランタイム固有バージョンのプログラミング言語、環境構成ファイル、ライブラリなどの依存要素を含む、アプリケーション内の軽量コードパッケージである。

【0004】

コールドスタート（Ｃｏｌｄ Ｓｔａｒｔ）にかかる時間は、数百ミリ秒から数秒の範囲であり、コンテナと低レイテンシアプリケーションサービスの即時プロビジョニングを効果的にサポートすることができない。現在、コンテナの事前起動（Ｐｒｅ－Ｌａｕｎｃｈ）を伴う設計が提案されており、これは作業負荷予測メカニズムによって補完され、低レイテンシアプリケーションのリアルタイムのプロビジョニングと操作の要件を満足することができる。ただし、この設計では、作業負荷管理が電力効率に与える影響は考慮されていない。

【0005】

クラウドコンピューティングは、ＱｏＳに敏感なさまざまなアプリケーションサービスをサポートし、優先スケジューリングメカニズムにより、優先度の高いサービスのリソース使用効率が保証される。クラウドオーケストレーションは、アプリケーションサービスの機能特性とリソース要件に応じて、「アプリケーションサービスの自動構成」と「リソースの最適化」を実行するため、リソースオーケストレーションのメカニズム（クラウドオーケストレーション）は非常に重要である。したがって、さまざまなアプリケーションもグローバルなクラウドオーケストレーション市場の成長を後押ししている。

【発明の概要】

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

【0006】

そこで、クラウドリソースオーケストレーションの分野では、どのようにして「ジョブパフォーマンス」と「省エネ・消費削減」のバランスをとるかが、現在の課題の一つとなっている。

【発明を解決するための手段】

【0007】

本発明は、ジョブパフォーマンスとジョブパフォーマンスを考慮したクラウドリソース割り当てシステム、装置、及び方法を提供する。

【0008】

本発明のクラウドリソース割り当てシステムは、複数のワーカノード及びマスターノードを含む。マスターノードは、リソースマネージャを介して複数のワーカノードによってそれぞれ報告された複数のノードリソース情報を取得し、ジョブスケジューラを介して待機キューから取得したジョブリクエストのジョブプロファイルを解析し、複数のノードリソース情報とジョブプロファイルに基づいて、ジョブリクエストで要求された処理対象ジョブに対して直接リソース割り当て又は間接リソース割り当ての実行を決定するように構成される、オーケストレータを含む。直接リソース割り当てを実行する決定に応答して、オーケストレータは、ジョブスケジューラを介して、複数のワーカノードの中からジョブプロファイルに一致する利用可能なリソースを有する第１のワーカノードを見つけ、リソースマネージャを介して、処理対象ジョブを第１のワーカノードにディスパッチし、処理対象ジョブを、ジョブスケジューラを介して実行キューに入れるように構成される。間接リソース割り当ての実行に応答して、オーケストレータは、ジョブスケジューラを介して、複数のワーカノードの中から低優先度ジョブを有する第２のワーカノードを見つけ、第２のワーカノードが低優先度ジョブの運用状態をバックアップするように第２のワーカノードに通知し、低優先度ジョブが使用しているリソースを解放し、リソースマネージャを介した第２のワーカノードからリソース解放通知の受信に応答して、ジョブスケジューラを介して、低優先度ジョブに対応する別のジョブリクエストを待機キューに入れ、リソースマネージャを介して、処理対象ジョブを第２のワーカノードにディスパッチし、処理対象ジョブを、ジョブスケジューラを介して実行キューに入れるように構成される。

【0009】

本発明のクラウドリソース割り当て装置は、リソースマネージャ及びジョブスケジューラを含むオーケストレータを格納し、待機キュー及び実行キューを提供するストレージと、ストレージに結合されたプロセッサと、を備える。プロセッサは、リソースマネージャを介して複数のワーカノードによってそれぞれ報告された複数のノードリソース情報を取得することと、ジョブスケジューラを介して待機キューから取得したジョブリクエストのジョブプロファイルを解析し、複数のノードリソース情報及びジョブプロファイルに基づいて、ジョブリクエストで要求された処理対象ジョブに対して直接リソース割り当て又は間接リソース割り当てを実行するかを決定するように構成される。

【0010】

本発明のクラウドリソース割り当て方法は、クラウドリソース割り当て装置によって以下を実行することを含む。複数のワーカノードによってそれぞれ報告された複数のノードリソース情報を取得し、待機キューから取得したジョブリクエストのジョブプロファイルを解析し、複数のノードリソース情報及びジョブプロファイルに基づいて、ジョブリクエストで要求された処理対象ジョブに対して直接リソース割り当て又は間接リソース割り当てを実行するかを決定する。

【発明の効果】

【0011】

以上により、本発明は、パフォーマンス及び電力消費の動的管理を備えたオーケストレーションアーキテクチャと、このアーキテクチャに基づくアプリケーショングループジョブプリエンプションメカニズムを提供する。複数のジョブでサポートされるアプリケーションを考慮し、アプリケーションの優先度に基づいてジョブ管理を柔軟に行い、コンテナサービスの動作パフォーマンスをサポートしながらノードコンピューティングリソースの電力使用効率を考慮し、それによって、保守及び動作コストを削減する。

【図面の簡単な説明】

【0012】

【図1】本発明の一実施形態によるクラウドリソース割り当てシステムのブロック図である。

【図2】本発明の一実施形態によるクラウドリソース割り当て方法のフローチャートである。

【図3】本発明の一実施形態によるクラウドリソース割り当て装置のアーキテクチャの概略図である。

【図4】本発明の一実施形態によるワーカノードのアーキテクチャの概略図である。

【図5】本発明の一実施形態による統合モードノードのブロック図である。

【図6】図６は、本発明の一実施形態によるワーカノードのパフォーマンス／電力消費モニタリングの概略図である。

【図7】本発明の一実施形態によるワーカノードのパフォーマンス／電力消費モニタリングのフローチャートである。

【図8】本発明の一実施形態によるコンテナリソース要求及びリソースオーケストレーションの概略図である。

【図9】本発明の一実施形態による電力消費調整の概略図である。

【図10】本発明の一実施形態によるパフォーマンス調整の概略図である。

【図11A】本発明の一実施形態によるジョブリクエストのジョブプロファイルの概略図である。

【図11B】本発明の一実施形態によるジョブリクエストのジョブプロファイルの概略図である。

【図11C】本発明の一実施形態によるジョブリクエストのジョブプロファイルの概略図である。

【図12A】本発明の一実施形態によるジョブリクエストの分配の概略図である。

【図12B】本発明の一実施形態によるジョブリクエストの分配の概略図である。

【図12C】本発明の一実施形態によるジョブリクエストの分配の概略図である。

【図12D】本発明の一実施形態によるジョブリクエストの分配の概略図である。

【図12E】本発明の一実施形態によるジョブリクエストの分配の概略図である。

【図13】本発明の一実施形態によるジョブ依存性及びリソースチェックの概略図である。

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

【0013】

図１は、本発明の一実施形態によるクラウドリソース割り当てシステムのブロック図である。図１を参照すると、クラウドリソース割り当てシステム１００は、機能別に分けて、マスターノード（クラウドリソース割り当て装置１００Ａ）とワーカノード１００Ｂ－１～１００Ｂ－Ｎ（まとめてワーカノード１００Ｂと呼ぶ）の２種類のノードを含む。クラウドリソース割り当て装置１００Ａは、コンテナコンピューティングリソースを管理及びスケジューリングするように構成される。ワーカノード１００Ｂは、コンテナコンピューティングリソースを提供する。

【0014】

クラウドリソース割り当てシステム１００の動作アーキテクチャは、以下の通り複数の種類のモードを有していても良い。たとえば、基本モード、高可用性モード、統合モード、高可用性統合モード、分散統合モードなどがある。基本モードは、少なくとも１つのマスターノード（クラウドリソース割り当て装置１００Ａ）と少なくとも２つのワーカノード１００Ｂを有する。高可用性モードは、少なくとも３つのマスターノード（クラウドリソース割り当て装置１００Ａ）及び少なくとも２つのワーカノード１００Ｂを有する。統合モードには、マスターノード及びワーカノードを形成する要素を配置し、統合モードを実行する（少なくとも２つの）ノードを有する。高可用性統合モードは、統合モードを実行する少なくとも３つのノードを有する。分散統合モードは、統合モードを実行する少なくとも２つのノードを有し、機能グループを配置せず、ポイントツーポイントコミュニケーションを使用してグローバル情報を収集し、分散リソースオーケストレーションの目的を達成する。

【0015】

クラウドリソース割り当て装置１００Ａは、コンピューティング機能及びネットワーク機能を有する電子機器を用いて実現され、そのハードウェアアーキテクチャは、少なくともプロセッサ１１０及びストレージ１２０を含む。ワーカノード１００Ｂも、コンピューティング機能及びネットワーキング機能を有する電子機器を用いて実現される。そのハードウェア構成はクラウドリソース割り当て装置１００Ａと同様である。

【0016】

プロセッサ１１０は、例えば、中央処理装置（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ，ＣＰＵ）、物理演算処理装置（Ｐｈｙｓｉｃｓ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ，ＰＰＵ）、プログラム可能なマイクロプロセッサ、組み込み制御チップ、デジタル信号プロセッサ（Ｄｉｇｉｔａｌ Ｓｉｇｎａｌ Ｐｒｏｃｅｓｓｏｒ，ＤＳＰ）、特定用途向け集積回路（Ａｐｐｌｉｃａｔｉｏｎ Ｓｐｅｃｉｆｉｃ Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔ，ＡＳＩＣ）、又は他の同様の装置である。

【0017】

ストレージ１２０は、例えば、任意の種類の修復又はリムーバブルランダムアクセスメモリ（ＲＡＭ）、読み取り専用メモリ（ＲＯＭ）、フラッシュメモリ、ハードディスク、又は他の同様の装置、又はこれらの装置の組み合わせである。ストレージ１２０は、オーケストレータ１２０Ａ及びリソースモニタ１２０Ｂを含む。オーケストレータ１２０Ａ及びリソースモニタ１２０Ｂは、１つ又は複数のコードフラグメントによって形成される。上記のコードフラグメントは、インストール後にプロセッサ１１０によって実行される。他の実施形態では、オーケストレータ１２０Ａ及びリソースモニタ１２０Ｂも、独立したチップ、回路、コントローラ、ＣＰＵ、及び他のハードウェアによって実施される。

【0018】

オーケストレータ１２０Ａは、ジョブリクエストを管理し、コンテナリソースをスケジュールする。リソースモニタ１２０Ｂは、ワーカノード１００Ｂから能動的に報告されるノードリソース情報を受信する。例えば、ノードリソース情報は、作業負荷をチェックした作業負荷モニタリングデータと、電力消費をチェックした電力消費モニタリングデータを含む。

【0019】

オーケストレータ１２０Ａは、ワーカノード１００Ｂのリソーススケジューリング能力を制御し、それによって、アプリケーションのサービス品質の要件を満足する。サービス品質の要件は、ＣＰＵリソース、メモリリソース、ハードディスクリソースなどのジョブリソースの使用量を含む。サービス品質の要件は、例えば、重要度や期限に基づく優先度レベルのスケジューリング要件をさらに含む。リソースオーケストレーションは、優先度の高いジョブで最初に実行される。

【0020】

リソースモニタ１２０Ｂは、ワーカノード１００Ｂのノードリソース情報を全体として収集し、全ての構成可能なコンテナコンピューティングリソースと、コンピューティングリソースを提供するためのワーカノード１００Ｂの利用可能なリソース種類及び容量をマスターするように構成される。

【0021】

図２は、本発明の一実施形態によるクラウドリソース割り当て方法のフローチャートである。図１及び図２を参照すると、ステップＳ２０５において、クラウドリソース割り当て装置１００Ａは、リソースモニタ１２０Ｂを介してワーカノード１００Ｂ－１～１００Ｂ－Ｎからそれぞれ報告された複数のノードリソース情報を取得する。

【0022】

次に、ステップＳ２１０において、オーケストレータ１２０Ａは、待機キューから取得したジョブリクエストのジョブプロファイルを解析し、ジョブリクエストが要求する処理対象ジョブに対して直接リソース割り当て又は間接リソース割り当てを実行するかを決定する。具体的には、ジョブプロファイルは、アプリケーショングループに基づく複数のジョブ、優先度、実行中に各ジョブ（アプリケーショングループメンバ）が必要とするリソース要件（リソース種類や需要など）、複数のアプリケーショングループメンバ（ジョブコンテナ）をサポートする起動順序及びシャットダウン順序などを含む。

【0023】

ステップＳ２１５で、オーケストレータ１２０Ａは、ノードリソース情報及びジョブプロファイルに基づいて、ワーカノード１００Ｂ－１～１００Ｂ－Ｎの利用可能なリソースがジョブリクエストのリソース要件を満足するかどうかを判断する。ワーカノード１００Ｂのうちの少なくとも１つの利用可能なリソースが、ジョブリクエストのリソース要件を満足する場合、処理対象ジョブに対して直接リソース割り当てが実行されることが決定される。いずれのワーカノード１００Ｂの利用可能なリソースも、ジョブリクエストのリソース要件を満足しない場合、及び１つ又は複数の低優先度ジョブ（すなわち、低優先度の１つ又は複数の実行中のジョブ）が使用するリソースをプリエンプションした後、ジョブリクエストのリソース要件を満足する（リソースプリエンプション条件を満足する）ことができるとと評価された場合、処理対象ジョブに対して間接リソース割り当てが実行されることが決定される。

【0024】

オーケストレータ１２０Ａは、直接リソース割り当てを実行する決定に応答して、ステップＳ２２０～Ｓ２３０を実行する。ステップＳ２２０では、ワーカノード１００Ｂの中から、ジョブプロファイルに一致する利用可能なリソースを有する第１のワーカノードが見つけられる。次に、ステップＳ２２５において、処理対象ジョブが第１のワーカノードにディスパッチされる。その後、ステップＳ２３０で、処理対象ジョブを実行キューに入れる。

【0025】

オーケストレータ１２０Ａは、間接リソース割り当てを実行する決定に応答して、ステップＳ２３５～Ｓ２５０を実行する。ステップＳ２３５では、ワーカノード１００Ｂの中から低優先度ジョブを有する第２のワーカノードが見つけられ、第２のワーカノードが低優先度ジョブの運用状態をバックアップするように第２のワーカノードに通知され、第２のワーカノードが使用するリソースが解放される。次に、ステップＳ２４０において、第２のワーカノードからリソース解放通知の受信に応答して、低優先度ジョブに対応する別のジョブリクエストが待機キューに入れられる。そして、ステップＳ２４５で、処理対象ジョブを第２ワーカノードにディスパッチする。その後、ステップＳ２５０で、処理対象ジョブを実行キューに入れる。低優先度のジョブが使用するリソースを解放した後、調整された利用可能なリソースがジョブ要求のリソース要件をまだ満足しないことに応答して、調整された利用可能なリソースがジョブリクエストのリソース要件を満足するまで、別の低優先度ジョブによって使用されているリソースを継続的に解放するように、第２のワーカノードは通知される。

【0026】

図３は、本発明の一実施形態によるクラウドリソース割り当て装置のアーキテクチャの概略図である。図３を参照すると、クラウドリソース割り当て装置１００Ａは、オーケストレータ１２０Ａと、リソースモニタ１２０Ｂと、作業負荷マネージャ１２０Ｃと、パワーマネージャ１２０Ｄと、を含む。

【0027】

オーケストレータ１２０Ａは、ジョブスケジューラ３０１及びリソースマネージャ３０３を含む。ジョブスケジューラ３０１は、ジョブリクエストのジョブプロファイルを解析し、解析されたジョブプロファイルに従って、直接的又は間接的（プリエンプティブ）な方法でリソース割り当て（それぞれ、直接リソース割り当て及び間接リソース割り当てという）を実行することを決定するように構成される。ジョブスケジューラ３０１はさらに、運用状態を管理するように構成される。また、ジョブスケジューラ３０１は、待機キューと実行キューをさらに提供する。待機キューは、保留中のジョブリクエスト（新しいジョブリクエスト、プリエンプションされたジョブリクエスト）に対応するように構成され、高優先度のジョブリクエストがジョブスケジューリングに優先される。実行キューは、実行中のジョブに対応するように構成される。リソースがプリエンプションされる低優先度ジョブに対して、最初に運用状態のバックアップ動作を実行される。リソースが解放された後、コンテナリソースを取得するための待機キューに入ると、未完了ジョブは前の運用状態から継続される。

【0028】

ジョブスケジューラ３０１が処理対象ジョブを実行キューに入れた後、リソースマネージャ３０３を介して、処理対象ジョブが終了したことを示す通知を受けると、ジョブスケジューラ３０１を介して、処理対象ジョブが実行キューから削除される。

【0029】

ジョブスケジューラ３０１は、異なるジョブ目標のスケジューリング結果をサポートする。ジョブ目標は、例えば、最小の電力消費コスト、最高のパフォーマンス、又は総合的な測定目標である。最小電力消費コストについては、各ワーカノード１００Ｂのシステムの基本電力消費と、現在の負荷状態に対応する電力消費情報とを確認し、電力消費コストが最も低いワーカノード１００Ｂが見つけられ、ジョブリクエストのリソース要件と履歴データに基づいて、ジョブリクエストを実行する各ワーカノード１００Ｂの電力消費コストを算出する。最高のパフォーマンスについては、各ワーカノード１００Ｂのリソースのカテゴリ、レベル、及び利用可能な容量を確認することにより、ジョブリクエストのリソース要件を満足することを前提として、最も高いリソースレベルを構成できるワーカノード１００Ｂを選択する。総合的な測定目標については、例えば、パフォーマンスと電力消費の特定の比率を有するワーカノードが考慮される。さらに、ジョブスケジューラ３０１は、最小電力消費コスト、最高のパフォーマンス、及び総合的な測定目標に基づいて、対応するワーカノードリストを提供することもできる。

【0030】

リソースマネージャ３０３は、リソースを管理し、各ワーカノードの作業負荷モニタリングデータ及び電力消費モニタリングデータを含む、全てのワーカノード１００Ｂから能動的に報告されるノードリソース情報を制御するように構成される。作業負荷モニタリングデータは、ワーカノードの合計負荷と利用可能なリソースを含む。電力消費のモニタリングデータは、電力消費の統計とエネルギー効率、マルチレベル（ワーカノードレベル、ジョブグループレベル、ジョブスケジュールレベル）のパフォーマンスと電力消費の統計と分析情報、及び可能なパフォーマンスと電力消費の調整戦略の提案を含む。リソースマネージャ３０３は、パフォーマンス及び電力消費に関する統計情報をジョブスケジューラ３０１に提供して、ジョブスケジューリングの意思決定を完了するために統計情報をサポートすることができる。リソースマネージャ３０３は、ジョブスケジューラ３０１のスケジューリング結果に従って実行するために、ジョブリクエストによって要求された処理対象ジョブを指定されたワーカノード１００Ｂにディスパッチする。リソースマネージャ３０３はまた、アクティブパフォーマンス調整及び／又は電力消費調整を実行することができる。

【0031】

リソースモニタ１２０Ｂは、パフォーマンスデータコレクタ３３１及び電力消費コレクタ３３３を含む。パフォーマンスデータコレクタ３３１は、各ワーカノード１００Ｂによって報告された作業負荷モニタリングデータを収集及び保存し、作業負荷モニタリングデータが警告ラベルでマークされたことに応答して、予め設定された時間に基づいて、履歴データを作業負荷モニタリングデータに追加するように構成される。例えば、ワーカノード１００Ｂの作業負荷が所定作業負荷上限を超えた場合、パフォーマンスデータコレクタ３３１は、予め設定された時間に従ってその後の分析のために作業負荷の履歴データを追加する。

【0032】

電力消費コレクタ３３３は、各ワーカノード１００Ｂから報告された電力消費モニタリングデータを収集して保存するように構成されている。ワーカノード１００Ｂ上でコンテナライフサイクルイベント（例えば、作成、プリエンプション、終了）が発生した場合、プロセス識別子（ＰＩＤ）の変更が生成され、ＰＩＤ に関連する電力消費履歴データが予め設定された時間に従って後続の分析のために追加される。

【0033】

作業負荷マネージャ１２０Ｃは、作業負荷モニタリングデータに従ってパフォーマンス管理を実行するように構成され、モニタリングデータは、オーケストレータによってリソースをスケジューリングするための基礎として最終的に使用される。作業負荷マネージャ１２０Ｃは、状態移行ハンドラ３１１及び作業負荷アナライザ３１３を含む。

【0034】

状態移行ハンドラ３１１は、リソースマネージャ３０３の指示に従って、ワーカノード１００Ｂ間の状態移行を処理する。

【0035】

作業負荷アナライザ３１３は、主に、パフォーマンスデータコレクタ３３１から作業負荷モニタリングデータを受信し、作業負荷モニタリングデータを分析することにより、ワーカノード１００Ｂにリソース異常が発生しているか否かを判断する。作業負荷アナライザ３１３は、リソース異常がワークロード過負荷（各ワーカノード１００Ｂの作業負荷が所定作業負荷上限を超える）又はシステムリソース損失（システムリソース損失によるシステムリソースの不足は、主に、コンピュータプログラムが終了したときに、占有されているリソースをコンピュータプログラムが正常に解放しないことに応答して発生し、その結果として、正常に解放されなかったリソースがジョブリクエストに割り当てられず、リソースの枯渇、パフォーマンスの低下、システムのクラッシュなどを招く）であると判断すると、リソースマネージャ３０３に通知し、リソースマネージャ３０３は、状態移行コマンドを状態移行ハンドラ３１１に送信する。

【0036】

作業負荷アナライザ３１３は、リソース異常が発生したワーカノード１００Ｂに対して対応する状態移行提案を生成するように構成される。作業負荷アナライザ３１３は、リソースの異常がワークロード過負荷であるという判断に応答して、ジョブグループレベルの状態移行提案を生成する。作業負荷アナライザ３１３は、リソース異常がシステムリソース損失（例えば、メモリリーク）であるとの判断に応答して、ノードレベルの状態移行提案を生成する。

【0037】

パワーマネージャ１２０Ｄは、パワープレーナ３２１及びパワーアナライザ３２３を含む。パワープレーナ３２１は、（リソースマネージャ３０３によって示される）電力消費調整戦略に基づいて、電力調整提案（ワーカノードの電力消費調整）を生成し、ワーカノード１００Ｂに電力調整提案を送信する。

【0038】

パワーアナライザ３２３は、電力消費コレクタ３３３から電力消費モニタリングデータを受信し、電力消費モニタリングデータを分析して電力消費分析結果を取得し、電力消費分析結果に基づいて電力消費調整戦略を生成する。一実施形態では、パワーアナライザ３２３は、ワーカノード上のコンテナのライフサイクル管理イベント（例えば、作成、削除、状態移行）に基づいて電力消費分析を実行し、リソースマネージャ３０３に適切な電力消費調整戦略を提供する。パワープレーナ３２１は、電力消費調整戦略に基づいて適切な電力調整提案を計画する。

【0039】

例えば、ワーカノード１００Ｂ上でジョブスケジュールの電力消費がない場合、ワーカノードがスリープモードに入ることが電力調整提案で提案される。ワーカノード１００Ｂの電力消費構成が高すぎて、現在の作業負荷よりも大幅に高い場合、ワーカノードが動的電圧及び周波数スケーリング（ＤＶＦＳ）を実行することが電力調整提案で提案される。例えば、「performance」（サポートされている最高の周波数でＣＰＵがジョブを修復する）は、「powersave」（サポートされている最低の周波数でＣＰＵがジョブを修復する）に調整される。

【0040】

さらに、実行中の全てのワーカノード１００Ｂが完全にロードされている場合、パワープレーナ３２１は、ワーカノード１００Ｂ－ｉなどのスリープモード又はパワーオフモードのワーカノードにパワーオンコマンドを発行する。そして、スリープモード又はパワーオフモードのワーカノード１００Ｂ－ｉが動作状態に移行した後、ワーカノード１００Ｂ－ｉ及び他のワーカノード１００Ｂからそれぞれ報告されたノードリソース情報を再度取得する。

【0041】

図４は、本発明の一実施形態によるワーカノードのアーキテクチャの概略図である。図４を参照すると、ワーカノード１００Ｂは、ローカルマネージャ４００Ａ及びコンテナエンジン４００Ｂを含む。ローカルマネージャ４００Ａは、ワーカノード１００Ｂの作業負荷や実行電力消費を定期的にチェックし、リソースモニタリング結果（すなわち、ノードリソース情報）をクラウドリソース割り当て装置１００Ａのリソースモニタ１２０Ｂに能動的に報告する。コンテナエンジン４００Ｂは、コンテナサービスのコアであり、ワーカノード１００Ｂ上でのジョブ実行に必要なコンピューティングリソースを提供する。

【0042】

ローカルマネージャ４００Ａは、電力消費インスペクタ４０１、パワーモジュールハンドラ４０３、ジョブハンドラ４０５、パフォーマンスデータインスペクタ４０７、及びシステムインスペクタ４０９を含む。

【0043】

電力消費インスペクタ４０１は、パワーモニタリングと専用ソフトウェアにより電力消費モニタリングデータを取得する。例えば、電力消費インスペクタ４０１は、インテリジェントプラットフォーム管理インターフェース（Ｉｎｔｅｌｌｉｇｅｎｔ Ｐｌａｔｆｏｒｍ Ｍａｎａｇｅｍｅｎｔ Ｉｎｔｅｒｆａｃｅ，ＩＰＭＩ）又はレッドフィッシュ基準（Ｒｅｄｆｉｓｈ ｓｔａｎｄａｒｄ）を使用するインターフェースを介してホスト電力消費情報を取得し、Ｓｃａｐｈａｎｄｒｅツールを介して各スケジュールの電力消費を分析し、標準性能評価法人（Ｓｔａｎｄａｒｄ Ｐｅｒｆｏｒｍａｎｃｅ Ｅｖａｌｕａｔｉｏｎ Ｃｏｒｐｏｒａｔｉｏｎ，ＳＰＥＣ）によって開発されたＳＰＥＣｐｏｗｅｒ及びＳＥＲＴツールを使用して負荷電力消費を取得し、ＣＰＵＦｒｅｑ又はＤＶＦＳを介してパワーガバナー（Ｐｏｗｅｒ Ｇｏｖｅｒｎｏｒｓ）の構成を取得することができる。

【0044】

パワーモジュールハンドラ４０３は、クラウドリソース割り当て装置１００Ａから受信した電力調整提案（システムレベルの電力消費調整）に応答して、パワーオフモード、スリープモード、特定電力消費モードのうちの１つなどのシステムパワー状態を調整する。パワーモジュールハンドラ４０３は、パワープレーナ３２１の指示に基づいて、ワーカノード１００Ｂのパワーモジュールを調整する。例えば、パワーモジュールは、最大のエネルギー節約及びシステム修復を達成するためにパワーオフモードに調整される。パワーモジュールはスリープモードに調整され、最大のエネルギー節約を実現し、次のシステム起動までのジョブ時間が短縮される。パワーモジュールの電圧と周波数は、負荷の最適な電圧と電力消費を実現するために調整される。

【0045】

ジョブハンドラ４０５は、クラウドリソース割り当て装置１００Ａのリソースマネージャ３０３からリソース管理コマンドを受信すると、コンテナライフタイムサイクル管理を実行する。コンテナライフタイムサイクル管理は、コンテナ作成、コンテナ削除、及び状態移行のいずれかを含む。ジョブハンドラ４０５は、リソースマネージャ３０３が送信するリソース管理コマンドにより、コンテナのプロビジョニング、削除、状態移行を現在実行中のプロセス識別子（ＰＩＤ）がどのアプリケーショングループのジョブに属するかを把握する。このようにして、電力消費インスペクタ４０１は、ジョブスケジュールに対してより正確な電力消費調査を実行するように支援され、パフォーマンスデータインスペクタ４０７は、ジョブスケジュールに対してより正確なパフォーマンス調査を実行するように支援される

【0046】

システムインスペクタ４０９は、ｔｏｐ、ｐｓ、ｔｕｒｂｏｓｔａｔ、ｓａｒ、ｐｑｏｓ、ｆｒｅｅ、ｖｍｓｔａｔ、ｉｏｓｔａｔ、ｎｅｔｓｔａｔなどのシステムリソースモニタリングツール、又はメモリリークなどのリソースの問題をチェックする他の補助ツールを介して、システムリソースの使用量を確認する。

【0047】

パフォーマンスデータインスペクタ４０７は、コンテナの各作業負荷が実際に使用するコンテナリソースの使用量を確認する。例えば、Ｋｕｂｅｒｎｅｔｅｓのメトリックサーバー、ｃＡｄｖｉｓｏｒ、及びその他のリソース検査ツールを使用して、作業負荷によって実際に使用されるコンテナリソースの使用量を確認する。パフォーマンスデータインスペクタ４０７はさらに、システムリソースの使用量及びコンテナリソースの使用量に基づいて作業負荷モニタリングデータを取得する。

【0048】

図５は、本発明の一実施形態による統合モードノードのブロック図である。本実施形態では、統合モードノード５００は、マスタノード（クラウドリソース割り当て装置１００Ａ）とワーカノード１００Ｂの要素を組み合わせたものである。統合モードノード５００は、オーケストレータ１２０Ａ、リソースモニタ１２０Ｂ、作業負荷マネージャ１２０Ｃ、パワーマネージャ１２０Ｄ、ローカルマネージャ４００Ａ、及びコンテナエンジン４００Ｂを含む。各要素の機能は、図３及び図４を参照することができ、ここでは繰り返さない。

【0049】

図６は、本発明の一実施形態によるワーカノードのパフォーマンス／電力消費モニタリングの概略図である。図７は、本発明の一実施形態によるワーカノードのパフォーマンス／電力消費モニタリングのフローチャートである。

【0050】

図６及び図７を参照すると、まず、パフォーマンスモニタリングの過程について説明するが、パフォーマンスモニタリングのデータの流れは、図６のルートＲ６０１、Ｒ６０３、Ｒ６０５、Ｒ６０７に示す通りである。

【0051】

ワーカノード１００Ｂでは、ステップＳ７０１において、システムインスペクタ４０９がシステムリソースの使用量を確認する。次に、ステップＳ７０３において、パフォーマンスデータインスペクタ４０７は、各コンテナの作業負荷によって実際に使用されるコンテナリソースの使用量を確認し、システムリソースの使用量及びコンテナリソースの使用量を含む作業負荷モニタリングデータをパフォーマンスデータコレクタ３３１に返す。

【0052】

次に、クラウドリソース割り当て装置１００Ａでは、ステップＳ７０５において、パフォーマンスデータコレクタ３３１が作業負荷モニタリングデータを保存する。さらに、ステップＳ７０７において、パフォーマンスデータコレクタ３３１は、作業負荷モニタリングデータが所定作業負荷上限を超えるかどうかを判断する。作業負荷上限を超える場合、ステップＳ７０９において、パフォーマンスデータコレクタ３３１は、予め設定された時間の履歴データを抽出して作業負荷モニタリングデータに入れ、ステップＳ７１１を実行する。

【0053】

具体的には、各ワーカノード１００Ｂには負荷上限が設定されているが、これは、主にワーカノード１００Ｂの作業負荷が作業負荷上限を超えて電力消費が急激に上昇する現象を回避するためである。例えば、オフライン環境における異なる作業負荷に対応する電力消費情報が最初に測定され、電力消費を大幅に増加させる作業負荷の臨界値が発見され得る。ここで、正式な動作環境（オンライン）で作業負荷上限をワーカノード１００Ｂに設定することができる。あるいは、リソースマネージャ３０３は、任意の公表された又は自己設計された電力消費モデル及び計算メカニズムを介して、ワーカノード１００Ｂ上の負荷の種類及び量に従って、各ワーカノード１００Ｂの許容可能な作業負荷上限を動的に調整することができる。

【0054】

ワーカノード１００Ｂでは、パフォーマンスデータインスペクタ４０７は、作業負荷モニタリングデータが所定作業負荷上限を超えているかどうかを判断し、作業負荷モニタリングデータが作業負荷上限を超えていると判断したことに応答して、作業負荷モニタリングデータに警告ラベルをマークする。これにより、クラウドリソース割り当て装置１００Ａのパフォーマンスデータコレクタ３３１は、受信した作業負荷モニタリングデータに警告ラベルが付されたことを検出したことに応答して、予め設定された時間に基づいて作業負荷モニタリングデータに履歴データを追加することができる。

【0055】

次に、ステップＳ７１１において、作業負荷アナライザ３１３は、作業負荷モニタリングデータを受信する。さらに、ステップＳ７１３において、作業負荷アナライザ３１３は、作業負荷モニタリングデータ（状態移行リマインダーデータを伴っても良い）をリソースマネージャ３０３に送信する。作業負荷モニタリングデータが所定作業負荷上限を超えることに応答して、作業負荷アナライザ３１３は、状態移行リマインダデータ（ソースワーカノード）を生成し、状態移行リマインダデータとともに作業負荷モニタリングデータをリソースマネージャ３０３に送信する。作業負荷モニタリングデータが所定作業負荷上限を超えない場合、作業負荷アナライザ３１３は、状態移行リマインダーデータを生成する必要はなく、作業負荷モニタリングデータをリソースマネージャ３０３に直接送信する。

【0056】

さらに、クラウドリソース割り当て装置１００Ａにおいて、リソースマネージャ３０３は、ソースワーカノード（ワーカノード１００Ｂ－１であると仮定する）がシステムリソース損失と判断された場合、ノードレベルの状態移行をトリガし、ワーカノード１００Ｂ－１がワークロード過負荷と判断された場合、ジョブグループレベルの状態移行をトリガし、ワーカノード１００Ｂ－１の電力消費調整構成が高すぎると判断された場合、システムレベルの電力消費調整をトリガするように構成されることがさらに説明される。

【0057】

ノードレベルの状態移行の暗黙の目的は次のとおりである。修復が必要なシステムリソースの問題がワーカノードにある場合、ノードにシステム再起動コマンドを発行する前に、まず全てのジョブの状態移行を完了する必要がある。ワーカノードには十分に利用可能なリソースがあるため、作業負荷が一部のワーカノードに集中する可能性があり、ジョブを実行していないワーカノードはスリープモードに移行して省電力を実現する。

【0058】

ジョブグループレベルの状態移行の暗黙の目的は次の通りである。複数のワーカノード間で作業負荷のバランスを取り、所定作業負荷上限を超えないようにする。作業負荷を一部のワーカノードに集中させて、残りのワーカノードがノードレベルのシャットダウンや休止状態を実行する必要のないスタンバイノードになるようにする。

【0059】

システムレベルの電力消費調整の暗黙の目的は次の通りである。ワーカノードのシャットダウン、休止状態、及び電力消費構成を調整する。

【0060】

ノードレベル及びジョブグループレベルの状態移行のトリガに応答して、リソースマネージャ３０３は、ジョブグループ（例えば、アプリケーショングループ）を最小単位として、ジョブグループ移行前にリソース確認を実行する。例えば、高優先度のジョブグループが最初に処理される。リソースマネージャ３０３は、ワーカノード１００Ｂ－１以外のワーカノード１００Ｂの利用可能なリソースが、ジョブグループのリソース要件を満足するかどうかを判断する。

【0061】

他のワーカノード１００Ｂの利用可能なリソースがジョブグループのリソース要件を満足する場合、リソースマネージャ３０３は、ジョブグループのリソース要件を直接満足し、かつ最高のパフォーマンス／最小の電力消費増加を有するターゲットワーカノード（ワーカノード１００Ｂ－２と仮定する）を他のワーカノードから選択する。

【0062】

他のワーカノード１００Ｂのいずれの利用可能なリソースもジョブグループのリソース要件を満足しないが、リソースプリエンプション条件を満足する場合、リソースマネージャ３０３は、他のワーカノード１００Ｂで実行中の複数のジョブのうち、低優先度ものから高優先度ものへの順序に従って、単一の低優先度ジョブ又は複数の低優先度ジョブに対応する１つ又は複数のターゲットワーカノード（ワーカノード１００Ｂ－３と仮定する）を選択する。

【0063】

その後、リソースマネージャ３０３は、ジョブスケジューラ３０１に、現在状態移行を行おうとしているジョブグループ情報、ソースワーカノード、プリエンプションされたリソースのジョブグループ情報、ターゲットワーカノードなどを通知する。ジョブスケジューラ３０１は、待機キューと実行キューの内容を更新する。その後、ソースワーカノードとターゲットワーカノード間の状態移行は、ジョブプロファイルによって定義されたジョブグループの起動順序及び／又はシャットダウン順序に従って実行される。

【0064】

次に、ソースワーカノード及びターゲットワーカノードのそれぞれのジョブハンドラ４０５は、リソースマネージャ３０３の指示に従って、それぞれのコンテナエンジン４００Ｂを介して、対応するコンテナサービスを順次アクティブ化又は非アクティブ化する。例えば、ジョブグループの起動順序の依存関係に従って、対応するコンテナサービスがターゲットワーカノードのコンテナエンジン４００Ｂを介して事前にアクティブ化される。ジョブグループのシャットダウン順序の依存関係に従って、ソースワーカノードのコンテナエンジン４００Ｂによって運用状態が凍結され、転送される。ジョブグループの起動順序の依存関係に従って、ソースワーカノードとターゲットワーカノードのそれぞれのコンテナエンジン４００Ｂを介して状態移行が行われる。ジョブグループのシャットダウン順序の依存関係に従って、ソースワーカノードのコンテナエンジン４００Ｂを介してコンテナサービスを１つずつ停止し、コンテナサービスの占有リソースが解放される。

【0065】

ノードレベルの状態移行を実行し、システムリソースの問題を修復することを決定したことに応答して、リソースマネージャ３０３は、エネルギーを最大限節約するためにシャットダウンを実行するようソースワーカノードのパワーモジュールハンドラ４０３に通知するか、あるいは、シャットダウン後に通常の起動過程を継続して、システムリソースの問題を修復する。

【0066】

システムリソースの問題を修復するために使用されないと判断されたノードレベルの状態移行の実行に応答して、リソースマネージャ３０３は、ソースワーカノードのパワーモジュールハンドラ４０３に、スリープモードに入りシステム状態をハードディスクに格納するように通知する。これにより、エネルギーを最大限に節約でき、ソースワーカノードが後で再びオンラインになるまでの時間を大幅に短縮できる。

【0067】

クラウドリソース割り当て装置１００Ａでは、作業負荷アナライザ３１３が、受信したワーカノード１００Ｂ－１の作業負荷モニタリングデータを分析し、ワーカノード１００Ｂ－１の作業負荷モニタリングデータが所定作業負荷上限を超えていること（ワークロード過負荷）を検出する。このとき、作業負荷アナライザ３１３は、ジョブグループレベルの状態移行リマインダーデータ（状態移行要件を備えたソースワーカノード）を生成し、状態移行リマインダーデータをリソースマネージャ３０３に送信する。その後、リソースマネージャ３０３は、状態移行コマンド（ソースワーカノード、ソースワーカノード上で状態移行を実行するジョブグループ、及び最高のパフォーマンス／最小電力消費増加を伴うターゲットワーカノードを含む）を生成して、状態移行リマインダーデータ（状態移行を必要とするソースワーカノード）に従って、状態移行ハンドラー３１１ に送信する。

【0068】

次に、電力消費モニタリングの過程について、図６及び図７を参照して説明する。また、電力消費モニタリングのデータの流れは、図６のルートＲ６１１、Ｒ６１３、Ｒ６１５に示す通りである。

【0069】

ワーカノード１００Ｂでは、ステップＳ７２１において、電力消費インスペクタ４０１が電力消費モニタリングデータを取得し、電力消費コレクタ３３３に報告する。

【0070】

次に、クラウドリソース割り当て装置１００Ａでは、ステップＳ７２３において、電力消費コレクタ３３３が、電力消費モニタリングデータを保存する。ステップＳ７２５において、電力消費コレクタ３３３は、ライフサイクルイベントが発生したかを判断する。ライフサイクルイベントが発生した場合、ステップＳ７０９において、電力消費コレクタ３３３は、元のデータベースＤＢから予め設定された時間の履歴データ（電力消費に関するもの）を抽出して、電力消費モニタリングデータに入れる。その後、ステップＳ７２７を実行する。

【0071】

具体的には、ワーカノード１００Ｂでコンテナのライフサイクルイベント（例えば、作成、プリエンプション、終了など）が発生した場合、ＰＩＤの変更が発生し、コンテナのプロビジョニング、削除、及び状態移行を実行するように構成されるジョブハンドラ４０５が、電力消費インスペクタ４０１にＰＩＤ情報（アプリケーショングループのジョブ情報を含む）を通知して、ＰＩＤ情報を電力消費モニタリングデータに入れるように電力消費量インスペクタ４０１に指示する。したがって、電力消費コレクタ３３３は、電力消費モニタリングデータ内のＰＩＤが変化するか否かを検出することにより、ライフサイクルイベントが発生したか否かを判断することができる。

【0072】

次に、ステップＳ７２７において、パワーアナライザ３２３は、電力消費モニタリングデータを受信する。さらに、ステップＳ７２９において、パワーアナライザ３２３は、電力消費モニタリングデータ（電力消費調整コマンドを伴っても良い）をリソースマネージャ３０３に送信する。ライフサイクルイベントが発生したことに応答して、パワーアナライザ３２３は、電力消費調整リマインダーデータを生成して、電力消費モニタリングデータを電力消費調整コマンドと共にリソースマネージャ３０３に送信する。ライフサイクルイベントが発生しない場合、パワーアナライザ３２３は、電力消費調整リマインダーデータを生成する必要はなく、電力消費モニタリングデータをリソースマネージャ３０３に直接送信する。

【0073】

パフォーマンス及び電力消費のモニタリングの過程で、モニタリングデータの保存に加えて、作業負荷が作業負荷上限を超えていることが判明した場合、及び／又はライフサイクルの状態が変化したことが判明した場合に限り、パフォーマンス／電力消費分析の実行がトリガーされる。

【0074】

作業負荷アナライザ３１３又はパワーアナライザ３２３が、作業負荷モニタリングデータ又は電力消費モニタリングデータの解析中に（過去に実行されたことを示す）履歴データを見つけた場合、アプリケーションによって実行されるジョブの平均パフォーマンス及び平均電力消費が取得され、要件を満足するワーカノードの中から、最高のパフォーマンス及び／又は電力消費増加が最も少ないターゲットワーカノードが選択される。したがって、直接リソース割り当てとコンテナのプロビジョニングの過程では、高パフォーマンスと省エネルギーの両方が考慮される。

【0075】

図８は、本発明の一実施形態によるコンテナリソース要求及びリソースオーケストレーションの概略図である。図８に示される矢印を参照すると、ジョブリクエストを受信した後、ジョブスケジューラ３０１は、リソースマネージャ３０３から通知されたノードリソース情報に従ってスケジューリングを行う。その後、リソースマネージャ３０３は、スケジューリング結果に従って、ターゲットワーカノードであるワーカノード１００Ｂをジョブハンドラ４０５に通知する。ジョブハンドラ４０５は、コンテナエンジン４００Ｂを介して、処理対象ジョブのためのコンテナプロビジョニングを実行する。

【0076】

具体的には、ジョブスケジューラ３０１は、ジョブリクエストを受信した後、ジョブリクエストを待機キューに入れ、ジョブリクエストを解析して、ジョブプロファイルを取得し、このジョブリクエストによって要求されたアプリケーションの優先度、及びそれに含まれる１つ又は複数のジョブコンテナ（同じアプリケーショングループに属する）間の起動順序及びシャットダウン順序、アプリケーショングループ内の各ジョブコンテナに対応する処理対象ジョブとリソース要件（後述の図１１Ａ～図１１Ｃに示す）を把握する。

【0077】

ジョブスケジューラ３０１は、リソースマネージャ３０３と通信して、全てのワーカノード１００Ｂの作業負荷モニタリングデータと電力消費モニタリングデータを把握し、作業負荷モニタリングデータと電力消費モニタリングデータに基づいて、ジョブリクエストを受け入れるための各ワーカノード１００Ｂのパフォーマンス及び電力消費コストを推定する。ワーカノード１００Ｂの利用可能なリソースがジョブリクエストのリソース要件を満足する場合、ジョブスケジューラ３０１は、さらにエネルギー効率が最も高い（高パフォーマンス／低電力消費）ワーカノードをジョブリクエストを引き継ぐためのノードとして使用することができる。そして、リソースマネージャ３０３は、引き継ぎ対象のワーカノード１００Ｂ上のジョブハンドラ４０５に通知し、ジョブハンドラ４０５は、アプリケーショングループメンバ（ジョブコンテナ）の依存関係に従って、コンテナエンジン４００Ｂを介してコンテナプロビジョニングを行う。

【0078】

さらに、ジョブスケジューラ３０１は、ワーカノード１００Ｂの利用可能なリソースのいずれもがジョブリクエストのリソース要件を満足しないという判断に応答して、低優先度ジョブをプリエンプションする可能性をさらに評価する。低優先度ジョブをプリエンプションする必要がある場合、リソースマネージャ３０３を介して低優先度ジョブに対応するワーカノード１００Ｂのジョブハンドラ４０５にリソース管理コマンドを発行し、ジョブハンドラ４０５がリソース管理コマンドに基づき低優先度ジョブの運用状態をバックアップし、コンテナライフタイムサイクル管理（ここではコンテナの終了）を実行する。運用状態のバックアップ完了後、低優先度ジョブが占有していたリソースが解放される。その後、ジョブハンドラ４０５は、アプリケーショングループメンバ（ジョブコンテナ）の依存関係に従って、コンテナエンジン４００Ｂを介してコンテナプロビジョニングを実行する。

【0079】

図９は、本発明の一実施形態による電力消費調整の概略図である。図１０は、本発明の一実施形態によるパフォーマンス調整の概略図である。以下の実施形態は、図６を参照して説明される。パフォーマンス／電力消費モニタリングのデータが図６に示される。リソースマネージャ３０３は、稼働中の全てのワーカノード１００Ｂのパフォーマンス及び電力消費モニタリングデータ（作業負荷モニタリングデータ及び電力消費モニタリングデータ）とパフォーマンス及び電力消費分析提案（状態移行提案及び電力調整提案）との合流点であり、リソースエクスプローラとして、能動的にパフォーマンス及び電力消費調整の判断を下すことができる。リソースマネージャ３０３は、作業負荷アナライザ３１３及びパワーアナライザ３２３からの報告に従って、状態移行コマンドを状態移行ハンドラ３１１に送信するか、電力消費調整戦略をパワープレーナ３２１に送信するかを決定する。

【0080】

図９において、パワーアナライザ３２３が、ワーカノード１００Ｂから報告された電力消費モニタリングデータを分析し、ジョブリクエストにより要求されたアプリケーションが完了した後、ジョブスケジュールによるワーカノード１００Ｂの電力消費がないと判断したと仮定すると、パワーアナライザ３２３は、リソースマネージャ３０３に電力消費調整戦略を提供する。リソースマネージャ３０３は、電力消費調整戦略をパワープレーナ３２１に送信し、パワープレーナ３２１は、電力消費調整戦略に従ってワーカノード１００Ｂにスリープモードへの移行を指示するコマンドを含む電力調整提案を計画する。その後、パワープレーナー３２１は、電力調整提案をワーカノード１００Ｂのパワーモジュールハンドラー４０３に送信し、パワーモジュールハンドラー４０３がワーカノード１００Ｂのシステムパワー状態をスリープモードに調整する。

【0081】

ワーカノード１００Ｂにおいて、電力消費インスペクタ４０１は、コンテナ作成、コンテナの終了、及びコンテナのプリエンプションなどのライフサイクル管理イベントが実行されているかどうかを判断する。実行されている場合、電力消費インスペクタ４０１は、電力消費モニタリングデータ内のライフサイクル管理イベントに対応するラベルをマークする。クラウドリソース割り当て装置１００Ａでは、パワーアナライザ３２３によって検出された電力消費モニタリングデータ内のライフサイクル管理イベントに対応するラベルは、パワープレーナ３２１が電力調整提案を計画するための基礎として使用することができる。

【0082】

例えば、パワーアナライザ３２３が電力消費モニタリングデータに基づいてワーカノード１００Ｂにジョブスケジュールに関連する電力消費がないことを検出すると、ノードレベルの電力調整提案がパワープレーナ３２１を介して生成される。例えば、ワーカノード１００Ｂをシャットダウン、スリープ等させる。

【0083】

例えば、パワーアナライザ３２３が電力消費モニタリングデータ（履歴を含む）に基づいてワーカノード１００Ｂの電力消費調整の構成が高すぎることを検出すると、システムレベルの電力調整提案がパワープレーナ３２１を介して生成され、これにより、ワーカノード１００ＢはＤＶＦＳを介してＣＰＵ動作周波数又は他の電力消費調整を調整できる。

【0084】

図１０は、ワーカノード１００Ｂ－１の作業負荷が所定作業負荷上限を超えていることを示している。したがって、ワーカノード１００Ｂ－１上のジョブＸ、ジョブＹ、ジョブＺがワーカノード１００Ｂ－２に転送される。ワーカノード１００Ｂ－１の作業負荷が所定作業負荷上限を超えたことに応答して、状態移行がトリガされる。図１０において、ワーカノード１００Ｂ－１及びワーカノード１００Ｂ－２のアーキテクチャは、図４に示したワーカノード１００Ｂを参照することができ、ジョブハンドラ４０５－１及び４０５－２の機能は、前述のジョブハンドラ４０５の説明を参照することができ、コンテナエンジン４００Ｂ－１及び４００Ｂ－２の機能は、前述のコンテナエンジン４００Ｂの説明を参照することができる。

【0085】

具体的には、リソースマネージャ３０３は、全てのワーカノード１００Ｂから能動的に報告されるノードリソース情報を制御する。リソースマネージャ３０３は、ワーカノード１００Ｂ－１の作業負荷が所定作業負荷上限を超えることを検出すると、ワーカノード１００Ｂ内のジョブＸ、ジョブＹ、及びジョブＺを満足する利用可能なリソースを有するワーカノード１００Ｂ－２を見つけ、ジョブＸ、ジョブＹ、ジョブＺをワーカノード１００Ｂ－２に割り当てる。

【0086】

以下は、本発明の実施形態による例である。

【0087】

図１１Ａ～図１１Ｃは、本発明の一実施形態によるジョブリクエストのジョブプロファイルの概略図である。図１２Ａ～ 図１２Ｅは、本発明の一実施形態によるジョブリクエストの分配の概略図である。

【0088】

図１１Ａは、優先度１００のアプリケーション１「ＶＲライブ放送（ＶＲ ｌｉｖｅ ｂｒｏａｄｃａｓｔ）」のジョブリクエストに対応するジョブプロファイル１を示しており、ビデオストリーミング（ｖｉｄｅｏ ｓｔｒｅａｍｉｎｇ，ＶＳ）、リアルタイムビデオエンコード／デコード（ｒｅａｌ－ｔｉｍｅ ｖｉｄｅｏ ｅｎｃｏｄｉｎｇ／ｄｅｃｏｄｉｎｇ，ＲＶＥＤ）、及びライブ配信管理サービス（ｌｉｖｅ ｂｒｏａｄｃａｓｔ ｍａｎａｇｅｍｅｎｔ ｓｅｒｖｉｃｅ，ＬＢＭＳ）を含む３つのジョブのアプリケーショングループを含む。アプリケーション１の３つのアプリケーショングループメンバ（３つのジョブコンテナ）の起動順序は、「リアルタイムビデオエンコード／デコード→ビデオストリーミング→ライブ配信管理サービス」であり、シャットダウン順序は「ライブ配信管理サービス→ビデオストリーミング→リアルタイムビデオエンコード／デコード」である。アプリケーション１が必要とする全てのリソース要件は、ＣＰＵが１４、メモリが５６ＧＢ、ハードディスクが２１２ＧＢであり、「（ＣＰＵ、メモリ、ハードディスク）＝（１４，５６，２１２）」として記録される。

【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】

１００： クラウドリソース割り当てシステム
１００Ａ： クラウドリソース割り当て装置（マスターノード）
１００Ｂ，１００Ｂ－１～１００Ｂ－Ｎ，Ｗ１，Ｗ２： ワーカノード
１１０： プロセッサ
１２０： ストレージ
１２０Ａ： オーケストレータ
１２０Ｂ： リソースモニター
１２０Ｃ： 作業負荷マネージャ
１２０Ｄ： パワーマネージャ
３０１： ジョブスケジューラ
３０３： リソースマネージャ
３１１： 状態移行ハンドラ
３１３： 作業負荷アナライザ
３２１： パワープレーナ
３２３： パワーアナライザ
３３１： パフォーマンスデータコントローラ
３３３： 電力消費コレクタ
４００Ａ：ローカルマネージャ
４００Ｂ，４００Ｂ－１，４００Ｂ－２： コンテナエンジン
４０１： 電力消費インスペクタ
４０３： パワーモジュールハンドラ
４０５，４０５－１，４０５－２： ジョブハンドラ
４０７： パフォーマンスデータインスペクタ
４０９： システムインスペクタ
５００： 統合モード ノード
ＡＰＰ＿Ａ～ＡＰＰ＿Ｅ，ＡＰＰ＿１～ＡＰＰ＿３： アプリケーション
ＡＰＰ＿３１，ＡＰＰ＿３２，ＡＰＰ＿３３： アプリケーショングループメンバ
Ｒ６０１～Ｒ６０７，Ｒ６１１～Ｒ６１５： ルート
ＲＱ： 実行キュー
ＷＱ： 待機キュー
Ｓ２０５～Ｓ２５０：クラウドリソース割り当ての工程
Ｓ７０１～Ｓ７２９：ワーカノードのパフォーマンス／電力消費モニタリングの工程

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11A】

【図11B】

【図11C】

【図12A】

【図12B】

【図12C】

【図12D】

【図12E】

【図13】