特表 2024-527103 クラウドプラットフォーム管理アーキテクチャ、管理方法、管理機器、及び記憶媒体

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

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

(11)【公表番号】

(43)【公表日】2024-07-19

(54)【発明の名称】クラウドプラットフォーム管理アーキテクチャ、管理方法、管理機器、及び記憶媒体

(51)【国際特許分類】

   G06F 8/76 20180101AFI20240711BHJP

【ＦＩ】

G06F8/76

【審査請求】有

【予備審査請求】未請求

(21)【出願番号】P 2024505368

(86)(22)【出願日】2022-05-07

(85)【翻訳文提出日】2024-01-29

(86)【国際出願番号】 CN2022091530

(87)【国際公開番号】W WO2023015988

(87)【国際公開日】2023-02-16

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

(32)【優先日】2021-08-10

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

(81)【指定国・地域】

(71)【出願人】

【識別番号】511151662

【氏名又は名称】中興通訊股▲ふん▼有限公司

【氏名又は名称原語表記】ＺＴＥ ＣＯＲＰＯＲＡＴＩＯＮ

【住所又は居所原語表記】ＺＴＥ Ｐｌａｚａ，Ｋｅｊｉ Ｒｏａｄ Ｓｏｕｔｈ，Ｈｉ－Ｔｅｃｈ Ｉｎｄｕｓｔｒｉａｌ Ｐａｒｋ，Ｎａｎｓｈａｎ Ｓｈｅｎｚｈｅｎ，Ｇｕａｎｇｄｏｎｇ ５１８０５７ Ｃｈｉｎａ

(74)【代理人】

【識別番号】110001195

【氏名又は名称】弁理士法人深見特許事務所

(72)【発明者】

【氏名】全 鋭

(72)【発明者】

【氏名】陳 皓

(72)【発明者】

【氏名】劉 学 生

(72)【発明者】

【氏名】徐 代 剛

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

5B376

【Ｆターム（参考）】

5B376BC25

5B376BC38

(57)【要約】

クラウドプラットフォーム管理アーキテクチャ、管理方法、管理機器、及びコンピュータ読み取り可能な記憶媒体を提供する。クラウドプラットフォーム管理アーキテクチャ（１００）は、オープンアプリケーションモデルに基づいて、少なくとも１つのアプリケーション能力を定義するように構成された第１管理装置（２００）であって、アプリケーション能力それぞれは、１つのクラウドプラットフラォームによってサポートされる負荷又は負荷に作用する運用保守特性を表すためのである第１管理装置（２００）と、第１管理装置（２００）に接続され、第１管理装置（２００）からのアプリケーション能力によって、アプリケーション能力に対応する、能力境界を決定するように構成された第２管理装置（３００）であって、能力境界は、アプリケーション能力をサポートする各候補クラウドプラットフォームを表すためのである第２管理装置（３００）と、第１管理装置（２００）に接続され、能力境界によって、各候補クラウドプラットフォームに対するアプリケーションオーケストレーション・インスタンス化ポリシーを決定するように構成されたアプリケーションオーケストレーション・インスタンス化装置と、を含む。

【特許請求の範囲】

【請求項1】

オープンアプリケーションモデルに基づいて、少なくとも１つのアプリケーション能力を定義するように構成された第１管理装置であって、前記アプリケーション能力それぞれは、１つのクラウドプラットフォームによってサポートされる負荷又は前記負荷に作用する運用保守特性を表すためのものである前記第１管理装置と、
前記第１管理装置に接続され、前記第１管理装置からの前記アプリケーション能力によって、前記アプリケーション能力に対応する能力境界を決定するように構成された第２管理装置であって、前記能力境界は、前記アプリケーション能力をサポートする各候補クラウドプラットフォームを表すためのものである前記第２管理装置と、
前記第１管理装置に接続され、前記能力境界によって、各前記候補クラウドプラットフォームに対するアプリケーションオーケストレーション・インスタンス化ポリシーを決定するように構成されたアプリケーションオーケストレーション・インスタンス化装置と、を含む、クラウドプラットフォーム管理アーキテクチャ。

【請求項2】

前記アプリケーションオーケストレーション・インスタンス化装置は、前記能力境界によって、各前記候補クラウドプラットフォームから、アプリケーションオーケストレーション・インスタンス化を実行するためのターゲットクラウドプラットフォームを決定するように構成される、請求項１に記載のクラウドプラットフォーム管理アーキテクチャ。

【請求項3】

前記第１管理装置はさらに、前記ターゲットクラウドプラットフォーム及び前記アプリケーション能力によって、前記ターゲットクラウドプラットフォームによってサポートされるターゲットアプリケーション能力を決定するように構成される、請求項２に記載のクラウドプラットフォーム管理アーキテクチャ。

【請求項4】

前記第１管理装置はさらに、前記ターゲットアプリケーション能力に対応するターゲット能力定義パケットを前記ターゲットクラウドプラットフォームに送信するように構成される、請求項３に記載のクラウドプラットフォーム管理アーキテクチャ。

【請求項5】

前記第２管理装置は、前記第１管理装置からの前記アプリケーション能力の動作状況をチェックし、前記アプリケーション能力の前記動作状況に応じて前記アプリケーション能力を調整するように構成されるとともに、調整された前記アプリケーション能力によって、調整された前記アプリケーション能力に対応する前記能力境界を決定するように構成される、請求項１～４のいずれか１項に記載のクラウドプラットフォーム管理アーキテクチャ。

【請求項6】

少なくとも１つの前記アプリケーション能力に対応する少なくとも１つの能力テンプレートを記憶する能力データベースをさらに含み、前記能力データベースは、前記第１管理装置を介して前記アプリケーションオーケストレーション・インスタンス化装置に接続される、請求項１に記載のクラウドプラットフォーム管理アーキテクチャ。

【請求項7】

前記アプリケーションオーケストレーション・インスタンス化装置はさらに、前記オープンアプリケーションモデルに基づいて、前記能力テンプレートに対応するプログラム可能なアプリケーション能力オーケストレーション要素を生成するように構成される、請求項６に記載のクラウドプラットフォーム管理アーキテクチャ。

【請求項8】

クラウドプラットフォーム管理アーキテクチャに適用される、クラウドプラットフォーム管理方法であって、前記クラウドプラットフォーム管理アーキテクチャは、第１管理装置と、第１管理装置に接続された第２管理装置と、を含み、
前記クラウドプラットフォーム管理方法は、
前記第１管理装置がオープンアプリケーションモデルに基づいて、少なくとも１つのアプリケーション能力を定義するように前記第１管理装置を制御するステップであって、前記アプリケーション能力それぞれは、１つのクラウドプラットフォームによってサポートされる負荷又は前記負荷に作用する運用保守特性を表すためのものであるステップと、
前記第２管理装置が前記第１管理装置からの前記アプリケーション能力によって、前記アプリケーション能力に対応する能力境界を決定するように前記第２管理装置を制御するステップであって、前記能力境界は、前記アプリケーション能力をサポートする各候補クラウドプラットフォームを表すためのものであるステップと、
前記能力境界によって、各前記候補クラウドプラットフォームに対するアプリケーションオーケストレーション・インスタンス化ポリシーを決定するステップと、を含む、クラウドプラットフォーム管理方法。

【請求項9】

前記能力境界によって、各前記候補クラウドプラットフォームに対するアプリケーションオーケストレーション・インスタンス化ポリシーを決定する前記ステップは、
前記能力境界によって各前記候補クラウドプラットフォームからアプリケーションオーケストレーション・インスタンス化を実行するためのターゲットクラウドプラットフォームを決定するステップを含む、請求項８に記載のクラウドプラットフォーム管理方法。

【請求項10】

前記能力境界によって、各前記候補クラウドプラットフォームに対するアプリケーションオーケストレーション・インスタンス化ポリシーを決定する前記ステップの後、
前記第１管理装置が前記ターゲットクラウドプラットフォーム及び前記アプリケーション能力によって、前記ターゲットクラウドプラットフォームによってサポートされるターゲットアプリケーション能力を決定するように前記第１管理装置を制御するステップをさらに含む、請求項９に記載のクラウドプラットフォーム管理方法。

【請求項11】

前記第１管理装置が前記ターゲットクラウドプラットフォーム及び前記アプリケーション能力によって、前記ターゲットクラウドプラットフォームによってサポートされるターゲットアプリケーション能力を決定するように前記第１管理装置を制御する前記ステップの後、
前記第１管理装置が前記ターゲットアプリケーション能力に対応するターゲット能力定義パケットを前記ターゲットクラウドプラットフォームに送信するように前記第１管理装置を制御するステップをさらに含む、請求項１０に記載のクラウドプラットフォーム管理方法。

【請求項12】

前記第２管理装置が前記第１管理装置からの前記アプリケーション能力によって、前記アプリケーション能力に対応する能力境界を決定するように前記第２管理装置を制御する前記ステップは、
前記第２管理装置が前記第１管理装置からの前記アプリケーション能力の動作状況をチェックし、前記第２管理装置が前記アプリケーション能力の前記動作状況に応じて前記アプリケーション能力を調整し、前記第２管理装置が調整された前記アプリケーション能力によって、調整された前記アプリケーション能力に対応する前記能力境界を決定するように前記第２管理装置を制御するステップをさらに含む、請求項８～１１のいずれか１項に記載のクラウドプラットフォーム管理方法。

【請求項13】

前記クラウドプラットフォーム管理アーキテクチャは、少なくとも１つの前記アプリケーション能力に対応する少なくとも１つの能力テンプレートを記憶するように構成された能力データベースをさらに含み、前記能力データベースは、前記第１管理装置を介して前記アプリケーションオーケストレーション・インスタンス化装置に接続され、
前記クラウドプラットフォーム管理方法は、
前記オープンアプリケーションモデルに基づいて、前記能力テンプレートに対応するプログラム可能なアプリケーション能力オーケストレーション要素を生成するステップをさらに含む、請求項８に記載のクラウドプラットフォーム管理方法。

【請求項14】

メモリと、プロセッサと、前記メモリに記憶され、前記プロセッサで動作可能なコンピュータプログラムとを含み、前記プロセッサは、前記コンピュータプログラムを実行すると、請求項８～１３のいずれか１項に記載のクラウドプラットフォーム管理方法を実現する、クラウドプラットフォーム管理装置。

【請求項15】

請求項８～１３のいずれか１項に記載のクラウドプラットフォーム管理方法を実行するためのコンピュータ実行可能命令を記憶したコンピュータ読み取り可能な記憶媒体。

【発明の詳細な説明】

【技術分野】

【0001】

本願は、出願番号２０２１１０９１５０１４．６、出願日２０２１年０８月１０日の中国特許出願に基づいて提出され、当該中国特許出願の優先権を主張しており、当該中国特許出願の全ての内容はここで参考として本願に組み入れられている。

【0002】

本願の実施例は、クラウドネイティブシーンアプリケーションの分野に関するが、これに限定されるものではなく、特に、クラウドプラットフォーム管理アーキテクチャ、管理方法、管理機器、及びコンピュータ読み取り可能な記憶媒体に関する。

【背景技術】

【0003】

現在、クラウドプラットフォームのアプリケーションオーケストレーションは、ほとんどクラウドプラットフォームに結合して行っており、クラウドネイティブアプリケーションはクラウドプラットフォームが提供するネイティブリソースを利用してオーケストレーションを行っている。当該リソースの種類が限られているため、オーケストレーションシステムがクラウドプラットフォームの様々なリソースタイプをハードコーディングする場合、クラウドネイティブ生態が提供するさまざまなリソースを最大限に活用することができず、さまざまなクラウドプラットフォーム間の移植性がない。言い換えれば、アプリケーション開発者にとって、クラウドプラットフォームは能力のジレンマに陥っている。ほとんどのプラットフォームとしてのサービス（ＰａａＳ：Ｐｌａｔｆｏｒｍ ａｓ ａ Ｓｅｒｖｉｃｅ）システムは、サポートするアプリケーションのタイプやサポートする機能を制限している。これは、独自のプラグインシステムを拡張、作成できなく、独自のコミュニティによって維持できないことなどにより反映される。一方、このプラグインメカニズムは、ＰａａＳシステム専用の閉じた小規模な生態能力にしか適用できず、大規模に確実に使用することはできない。さらに、実際には、アプリケーションの設計がマルチクラウド管理システムに対して行われ、ここで、センタールームは異なるクラウドプラットフォームを集中管理しており、異なるクラウドプラットフォームの間には一定の違いがある。そのため、オーケストレーションの際に、利用可能なオーケストレーション要素は通常、一部の簡単な汎用リソースしかカプセル化することができず、特定のクラウドプラットフォームの異なるプラグインの能力を設計することはできない。その結果、オーケストレーション能力は完全に簡単なリソースカプセル化に依存し、どのようなフィールドを露出するかは完全に開発者のアプリケーションに対する理解にかかっている。後でフィールドを更新する必要がある場合、コードを修正したり、バージョンをやり直したりするなどの手段で解决するしかないので、非常に柔軟ではない。また、クラウドネイティブ生態で大量の運用保守関連プラグインを使用することができず、複雑なアプリケーション特徴をオーケストレーションすることができず、全体的なオーケストレーション効果の低下を招く。

【発明の概要】

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

【0004】

以下は本明細書で詳細に説明されている主題の概要を示す。本概要は、特許請求の範囲の保護範囲を限定するものではない。

【0005】

本願の実施例は、クラウドプラットフォーム管理アーキテクチャ、管理方法、管理機器、及びコンピュータ読み取り可能な記憶媒体を提供する。

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

【0006】

第１態様では、本願の実施例は、クラウドプラットフォーム管理アーキテクチャを提供する。前記クラウドプラットフォーム管理アーキテクチャは、
オープンアプリケーションモデルに基づいて、少なくとも１つのアプリケーション能力を定義するように構成された第１管理装置であって、前記アプリケーション能力それぞれは、１つのクラウドプラットフォームによってサポートされる負荷又は前記負荷に作用する運用保守特性を表すためのものである前記第１管理装置と、
前記第１管理装置に接続され、前記第１管理装置からの前記アプリケーション能力によって、前記アプリケーション能力に対応する能力境界を決定するように構成された第２管理装置であって、前記能力境界は、前記アプリケーション能力をサポートする各候補クラウドプラットフォームを表すためのものである前記第２管理装置と、
前記第１管理装置に接続され、前記能力境界によって各前記候補クラウドプラットフォームに対するアプリケーションオーケストレーション・インスタンス化ポリシーを決定するように構成されたアプリケーションオーケストレーション・インスタンス化装置と、を含む。

【0007】

第２態様では、本願の実施例はまた、クラウドプラットフォーム管理アーキテクチャに適用されるクラウドプラットフォーム管理方法を提供する。前記クラウドプラットフォーム管理アーキテクチャは、第１管理装置と、第１管理装置に接続された第２管理装置と、を含む。
前記クラウドプラットフォーム管理方法は、
前記第１管理装置がオープンアプリケーションモデルに基づいて、少なくとも１つのアプリケーション能力を定義するように前記第１管理装置を制御するステップであって、前記アプリケーション能力それぞれは、１つのクラウドプラットフォームによってサポートされる負荷又は負荷に作用する運用保守特性を表すためのものであるステップと、
前記第２管理装置が前記第１管理装置からの前記アプリケーション能力に応じて、前記アプリケーション能力に対応する能力境界を決定するように前記第２管理装置を制御するステップであって、前記能力境界は、前記アプリケーション能力をサポートする各候補クラウドプラットフォームを表すためのものであるステップと、
前記能力境界によって各前記候補クラウドプラットフォームに対するアプリケーションオーケストレーション・インスタンス化ポリシーを決定するステップと、を含む。

【0008】

第３態様では、本願の実施例はまた、クラウドプラットフォーム管理装置を提供する。前記クラウドプラットフォーム管理装置は、メモリと、プロセッサと、前記メモリに記憶され、前記プロセッサで動作可能なコンピュータプログラムとを含み、前記プロセッサは、前記コンピュータプログラムを実行すると、前記第２態様に記載のクラウドプラットフォーム管理方法を実現する。

【0009】

第４態様では、本願の実施例はまた、上記の第２態様のクラウドプラットフォーム管理方法を実行するためのコンピュータ実行可能命令を記憶したコンピュータ読み取り可能な記憶媒体を提供する。

【0010】

本願の他の特徴及び利点は、後の明細書で説明され、本明細書から部分的に明らかになるか、又は本願を実施することによって理解される。本願の目的及び他の利点は、明細書、特許請求の範囲、及び添付図面において特に指摘された構造によって達成され得る。

【0011】

図面は、本願の技術的解決手段の更なる理解を提供するために使用され、明細書の一部を構成し、本願の実施例と共に本願の技術的解決手段を説明するために使用され、本願の技術的解決手段を限定するものではない。

【図面の簡単な説明】

【0012】

【図1】本願の一実施例によるクラウドプラットフォーム管理アーキテクチャの概略図である。

【図2】本願の一具体例によるクラウドプラットフォーム管理アーキテクチャの概略図である。

【図3】本願の一実施例による能力境界の概略図である。

【図4】本願の一実施例によるブループリントデザイナーのインターフェースの概略図である。

【図5】本願の一実施例によるクラウドプラットフォーム管理方法のフローチャートである。

【図6】本願の一実施例によるクラウドプラットフォーム管理方法においてターゲットクラウドプラットフォームを決定するフローチャートである。

【図7】本願の他の実施例によるクラウドプラットフォーム管理方法のフローチャートである。

【図8】本願の他の実施例によるクラウドプラットフォーム管理方法のフローチャートである。

【図9】本願の一実施例によるクラウドプラットフォーム管理方法において能力境界を決定するフローチャートである。

【図10】本願の実施例に係るクラウドプラットフォーム管理アーキテクチャがクラウドプラットフォームにアクセスする具体的なフローチャートである。

【図11】本願の実施例に係るクラウドプラットフォーム管理アーキテクチャが下位クラウドプラットフォームに能力定義を配信する具体的なフローチャートである。

【図12】本願の実施例に係るクラウドプラットフォーム管理アーキテクチャがアプリケーションインスタンス化を実行する具体的なフローチャートである。

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

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

なお、アプリケーション定義に必要な能力定義パッケージとその依存するプラグインパッケージが本装置にすでに存在していれば、アプリケーションインスタンス化の際に、必要に応じて能力定義パッケージを対応するクラウドプラットフォームシステムに配信してローディングしてもよい。

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

例４
図１０を参照すると、図１０は、本願の実施例に係るクラウドプラットフォーム管理アーキテクチャがクラウドプラットフォームにアクセスする具体的なフローチャートである。

【0118】

図１０の例では、本願の実施例に係るクラウドプラットフォーム管理アーキテクチャがクラウドプラットフォームにアクセスする具体的なプロセスは、以下のステップを含む。
ステップＳ５００：クラウドプラットフォームインスタンスへのアクセス操作を開始させる。
ステップＳ５１０：Ｈｅｌｍクライアントを介して能力オペレータを配信し、能力オペレータをターゲットクラウドプラットフォームにローディングする。
ステップＳ５２０：能力オペレータのローディングに成功したか否かを判定し、そうであれば、ステップＳ５３０に進み、そうでなければ、ステップＳ５２１を実行する。
ステップＳ５２１：クラウドプラットフォームへのアクセスに失敗したことを通知する。
ステップＳ５３０：Ｈｅｌｍクライアントを介してプレハブ能力テンプレートＣｈａｒｔのローディングを配信するとともに、プレハブ能力テンプレートに必要な各種プラグインをローディングする。
ステップＳ５４０：プレハブ能力のローディングが成功したか否かを判定し、そうであれば、ステップＳ５５０に進み、そうでなければ、ステップＳ５４１を実行する。
ステップＳ５４１：能力オペレータをアンインストールし、クラウドプラットフォームへのアクセスに失敗したことを通知する。
ステップＳ５５０：能力発見により、この新しくアクセスされるクラウドプラットフォームによってサポートされている能力を発見する。
ステップＳ５６０：このクラウドプラットフォームによってサポートされている能力集合データを能力定義データベースに構築する。
ステップＳ５７０：能力管理境界を更新する。

【0119】

例５
図１１を参照すると、図１１は、本願の実施例に係るクラウドプラットフォーム管理アーキテクチャが下位クラウドプラットフォームに能力定義を配信する具体的なフローチャートである。

【0120】

図１１の例では、本願の実施例に係るクラウドプラットフォーム管理アーキテクチャが下位クラウドプラットフォームに能力定義を配信する具体的なプロセスは、以下のステップを含む。

【0121】

ステップＳ６００：能力マネージャは、能力定義配信操作を開始させる。
ステップＳ６０１：ターゲットクラウドプラットフォームに現在の能力定義が存在するか否かを判定し、そうであれば、ステップＳ６１０に進み、そうでなければ、次のステップに進む。
ステップＳ６０２：自装置に現在の能力定義パッケージが存在するか否かを判定し、そうであれば、能力定義パッケージをターゲットプラットフォームに配信し、次のステップに進み、そうでなければ、ステップＳ６０９に進む。
ステップＳ６０３：ターゲットクラウドプラットフォームの能力オペレータは、能力定義テンプレートをチェックし、チェックに合格したか否かを判定し、そうであれば、次のステップに進み、そうでなければ、ステップＳ６０９に進む。
ステップＳ６０４：ターゲットクラウドプラットフォームの能力オペレータは、能力定義テンプレートを解析し、初期化アクションｉｎｉｔＡｃｔｉｏｎ定義が存在するか否かを判定し、そうであれば、次のステップに進み、そうでなければ、ステップＳ６０９に進む。
ステップＳ６０５：ターゲットクラウドプラットフォームの能力オペレータは、能力定義内のｉｎｉｔＡｃｔｉｏｎ記述に従って、能力が依存するプラグインをクラウドプラットフォームにローディングする。
ステップＳ６０６：ターゲットクラウドプラットフォームは、能力定義をサンドボックスにローディングするとともに、能力サンドボックステストを実行する。
ステップＳ６０７：能力定義がサンドボックステストに合格したか否かを判定し、そうであれば、次のステップに進み、そうでなければ、ステップＳ６０９に進む。
ステップＳ６０８：ターゲットプラットフォームは、能力の配信に成功したことをフィードバックしながら、能力定義をローディングする。
ステップＳ６０９：能力定義のローディングに失敗したことを通知し、その理由をフィードバックする。
ステップＳ６１０：配信能力が成功したことを通知する。

【0122】

例６
図１２に示すように、図１２は、本願の実施例に係るクラウドプラットフォーム管理アーキテクチャがアプレケーションインスタンス化を行う具体的なフローチャートである。

【0123】

図１２の例では、本願の実施例に係るクラウドプラットフォーム管理アーキテクチャがアプレケーションインスタンス化を行う具体的なプロセスは、以下のステップを含む。

【0124】

ステップＳ７００：アプリケーションインスタンス化操作を実行する。
ステップＳ７０１：アプリケーションパッケージをオーケストレーションする際にクラウドプラットフォームインスタンスが選択されているか否かを判定し、そうであれば、ステップＳ７１０に進み、そうでなければ、次のステップに進む。
ステップＳ７０２：該アプリケーションパッケージ内のアプリケーション定義が使用する能力定義要素を全て解析し、能力境界によってこのアプリケーションをサポートするクラウドプラットフォームインスタンスを得る。
ステップＳ７０３：クラウドプラットフォームインスタンスに基づいて、このアプリケーションを展開可能なクラウドプラットフォームがあるか否かを判定し、そうであれば、ステップＳ７１０に進み、そうでなければ、次のステップに進む。
ステップＳ７０４：このアプリケーションパッケージをさらに展開するために、「Ａｄｖａｎｃｅｄ」能力が選択されたか否かを判定し、そうであれば、次のステップに進み、そうでなければ、ステップＳ７１１に進む。
ステップＳ７０５：アクセスされたクラウドプラットフォームのすべてのインスタンスを表示する。
ステップＳ７０６：このアプリケーションパッケージを展開するクラウドプラットフォームのインスタンスを特定する。
ステップＳ７０７：能力境界によって、ターゲットクラウドプラットフォームがこのアプリケーションを展開するために不足している能力集合を算出し、不足している能力集合に対応する能力インストールパッケージが存在するか否かを判定し、そうであれば、次のステップに進み、そうでなければ、ステップＳ７１１に進む。
ステップＳ７０８：対応する能力インストールパッケージをターゲットクラウドプラットフォームに配信して能力インストールを実行し、インストールが成功したか否かを判定し、そうであれば、次のステップに進み、そうでなければ、ステップＳ７１１に進む。
ステップＳ７０９：ターゲットクラウドプラットフォームでアプリケーションインスタンス化アクションを実行し、インスタンス化が成功したか否かを判定し、インスタンス化に失敗した場合、ステップＳ７１１に進むように提示する。
ステップＳ７１０：アプリケーションがサポートするクラウドプラットフォームのリストをユーザーに提示して選択させる。
ステップＳ７１１：アプリケーションインスタンス化に失敗したことを提示する。

【0125】

なお、本実施例におけるクラウドプラットフォーム管理方法は、上記実施例におけるクラウドプラットフォーム管理アーキテクチャと同一の発明思想に属するため、本実施例におけるクラウドプラットフォーム管理方法の具体的な実施形態は、上記実施例におけるクラウドプラットフォーム管理アーキテクチャの具体的な実施例を参照することができ、上記実施例におけるクラウドプラットフォーム管理アーキテクチャの全ての改良を有するが、ここでは説明しない。

【0126】

本願の一実施例はまた、クラウドプラットフォーム管理装置を提供する。この管理装置は、図１に示す実施例におけるクラウドプラットフォーム管理アーキテクチャ、又は図２に示す実施例におけるクラウドプラットフォーム管理アーキテクチャを含む。

【0127】

ここで、上記実施例のクラウドプラットフォーム管理方法を実現するために必要な非一時的なソフトウェアプログラム及び命令は、メモリに記憶されており、プロセッサにより実行されると、上記実施例のクラウドプラットフォーム管理方法、例えば、上記の図５の方法ステップＳ１００～ステップＳ３００、図６の方法ステップＳ３１０、図７の方法ステップＳ４００、図８の方法ステップＳ４１０、図９の方法ステップＳ２１０、図１０の方法ステップＳ５００～ステップＳ５７０、図１１の方法ステップＳ６００～ステップＳ６１０、図１２の方法ステップＳ７００～ステップＳ７１１、又は方法ステップＳ４２０を実行する。

【0128】

なお、本実施例に係るクラウドプラットフォーム管理装置は、図１に示す実施例のクラウドプラットフォーム管理アーキテクチャや図２に示す実施例のクラウドプラットフォーム管理アーキテクチャにも適用可能である。これらの実施例はいずれも同一の発明思想に属するものであるので、これらの実施例は同一の実現原理及び技術的効果を有し、ここでは詳述しない。

【0129】

上記の装置の実施例は単なる一例であり、分離された構成要素として説明されたユニットは、物理的に分離されていてもよいし、そうでなくてもよい。すなわち、１つの場所に配置されていてもよいし、複数のネットワークユニットに分散されていてもよい。これらのモジュールの一部又は全部は、実際の必要に応じて、本実施例の目的を達成するために選択されてもよい。

【0130】

さらに、本願の一実施例はまた、コンピュータ読み取り可能な記憶媒体を提供する。このコンピュータ読み取り可能な記憶媒体は、コンピュータ実行可能命令を記憶している。このコンピュータ実行可能命令は、プロセッサやコントローラ、例えば上記機器の実施例におけるプロセッサによって実行されると、上記実施例におけるクラウドプラットフォーム管理方法、例えば、上記図５の方法ステップＳ１００～ステップＳ３００、図６の方法ステップＳ３１０、図７の方法ステップＳ４００、図８の方法ステップＳ４１０、図９のステップＳ２１０、図１０の方法ステップＳ５００～ステップＳ５７０、図１１の方法ステップＳ６００～ステップＳ６１０、図１２の方法ステップＳ７００～ステップＳ７１１、又は方法ステップＳ４２０を上記プロセッサに実行させることができる。

【0131】

本願の実施例は、クラウドプラットフォーム管理アーキテクチャを含む。クラウドプラットフォーム管理アーキテクチャは、オープンアプリケーションモデルに基づいて、少なくとも１つのアプリケーション能力を定義するように構成された第１管理装置であって、アプリケーション能力それぞれは、１つのクラウドプラットフォームによってサポートされる負荷又は負荷に作用する運用保守特性を表すためのものである前記第１管理装置と、第１管理装置に接続され、第１管理装置からのアプリケーション能力によって、アプリケーション能力に対応する能力境界を決定するように構成された第２管理装置であって、能力境界は、アプリケーション能力をサポートする各候補クラウドプラットフォームを表すためのものである前記第２管理装置と、第１管理装置に接続され、能力境界によって、各候補クラウドプラットフォームに対するアプリケーションオーケストレーション・インスタンス化ポリシーを決定するように構成されたアプリケーションオーケストレーション・インスタンス化装置と、を含む。本願の実施例による形態によれば、オープンアプリケーションモデルの具体的なシーンにおいて、第１管理装置により、複数のアプリケーション能力を定義するので、クラウドネイティブアプリケーションの能力抽象化を実現することができる。それによって、各クラウドプラットフォームの差別化シーンを整合的に表すことができ、各クラウドプラットフォーム間でのクラウドネイティブアプリケーションの移植性を向上させることができる。また、第２管理装置により、定義されたアプリケーション能力をサポートする候補クラウドプラットフォームを表すための能力境界を決定し、アプリケーションオーケストレーション・インスタンス化装置が、能力境界によって、各候補クラウドプラットフォームに対するアプリケーションオーケストレーション・インスタンス化ポリシーを決定することを支援する。それによって、複数のクラウドプラットフォームの差別化シーンを管理し、アプリケーションオーケストレーション・インスタンス化を最適化する効果を得ることができる。

【0132】

上記で開示された方法におけるステップの全部又は一部、システムは、ソフトウェア、ファームウェア、ハードウェア、及びそれらの適切な組み合わせとして実装されてもよい。物理的構成要素の一部又はすべては、中央処理装置、デジタル信号処理装置、マイクロプロセッサなどのプロセッサによって実行されるソフトウェアとして、又はハードウェアとして、又は特定用途向け集積回路などの集積回路として実装されてもよい。このようなソフトウェアは、コンピュータ記憶媒体（又は非一時的媒体）及び通信媒体（又は一時的媒体）を含んでもよいコンピュータ読み取り可能な媒体上に配布されてもよい。コンピュータ記憶媒体は、情報（例えば、コンピュータ読み取り可能な命令、データ構造、プログラムモジュール、又は他のデータ）を記憶するための任意の方法又は技術において実施される、揮発性及び不揮発性の、取り外し可能な、及び取り外し不可能な媒体を含む。コンピュータ記憶媒体は、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリもしくは他のメモリ技術、ＣＤ－ＲＯＭ、デジタル多用途ディスク（ＤＶＤ）もしくは他の光ディスク記憶装置、磁気カートリッジ、磁気テープ、磁気ディスク記憶装置もしくは他の磁気記憶装置、又は所望の情報を記憶するために使用することができ、コンピュータによってアクセスすることができる他の任意の媒体を含むが、これらに限定されるものではない。さらに、通信媒体は、通常、コンピュータ読み取り可能な命令、データ構造、プログラムモジュール、又は搬送波又は他の送信機構のような変調データ信号中の他のデータを含み、任意の情報配信媒体を含み得る。

【0133】

以上は、本願のいくつかの実施形態の具体的な説明であるが、本願は上記の実施形態に限定されるものではなく、当業者は、本願の精神に反することなく、様々な均等な変形又は置換を行うことができ、これらの均等な変形又は置換は、本願の特許請求の範囲によって限定される範囲内に含まれるものとする。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【手続補正書】

【提出日】2024-01-29

【手続補正1】

【補正対象書類名】特許請求の範囲

【補正対象項目名】全文

【補正方法】変更

【補正の内容】

【特許請求の範囲】

【請求項1】

オープンアプリケーションモデルに基づいて、少なくとも１つのアプリケーション能力を定義するように構成された第１管理装置であって、前記アプリケーション能力それぞれは、１つのクラウドプラットフォームによってサポートされる負荷又は前記負荷に作用する運用保守特性を表すためのものである前記第１管理装置と、
前記第１管理装置に接続され、前記第１管理装置からの前記アプリケーション能力によって、前記アプリケーション能力に対応する能力境界を決定するように構成された第２管理装置であって、前記能力境界は、前記アプリケーション能力をサポートする各候補クラウドプラットフォームを表すためのものである前記第２管理装置と、
前記第１管理装置に接続され、前記能力境界によって、各前記候補クラウドプラットフォームに対するアプリケーションオーケストレーション・インスタンス化ポリシーを決定するように構成されたアプリケーションオーケストレーション・インスタンス化装置と、を含む、クラウドプラットフォーム管理アーキテクチャ。

【請求項2】

前記アプリケーションオーケストレーション・インスタンス化装置は、前記能力境界によって、各前記候補クラウドプラットフォームから、アプリケーションオーケストレーション・インスタンス化を実行するためのターゲットクラウドプラットフォームを決定するように構成される、請求項１に記載のクラウドプラットフォーム管理アーキテクチャ。

【請求項3】

前記第１管理装置はさらに、前記ターゲットクラウドプラットフォーム及び前記アプリケーション能力によって、前記ターゲットクラウドプラットフォームによってサポートされるターゲットアプリケーション能力を決定するように構成される、請求項２に記載のクラウドプラットフォーム管理アーキテクチャ。

【請求項4】

前記第１管理装置はさらに、前記ターゲットアプリケーション能力に対応するターゲット能力定義パケットを前記ターゲットクラウドプラットフォームに送信するように構成される、請求項３に記載のクラウドプラットフォーム管理アーキテクチャ。

【請求項5】

前記第２管理装置は、前記第１管理装置からの前記アプリケーション能力の動作状況をチェックし、前記アプリケーション能力の前記動作状況に応じて前記アプリケーション能力を調整するように構成されるとともに、調整された前記アプリケーション能力によって、調整された前記アプリケーション能力に対応する前記能力境界を決定するように構成される、請求項１～４のいずれか１項に記載のクラウドプラットフォーム管理アーキテクチャ。

【請求項6】

少なくとも１つの前記アプリケーション能力に対応する少なくとも１つの能力テンプレートを記憶する能力データベースをさらに含み、前記能力データベースは、前記第１管理装置を介して前記アプリケーションオーケストレーション・インスタンス化装置に接続される、請求項１に記載のクラウドプラットフォーム管理アーキテクチャ。

【請求項7】

前記アプリケーションオーケストレーション・インスタンス化装置はさらに、前記オープンアプリケーションモデルに基づいて、前記能力テンプレートに対応するプログラム可能なアプリケーション能力オーケストレーション要素を生成するように構成される、請求項６に記載のクラウドプラットフォーム管理アーキテクチャ。

【請求項8】

クラウドプラットフォーム管理アーキテクチャに適用される、クラウドプラットフォーム管理方法であって、前記クラウドプラットフォーム管理アーキテクチャは、第１管理装置と、第１管理装置に接続された第２管理装置と、を含み、
前記クラウドプラットフォーム管理方法は、
前記第１管理装置がオープンアプリケーションモデルに基づいて、少なくとも１つのアプリケーション能力を定義するように前記第１管理装置を制御するステップであって、前記アプリケーション能力それぞれは、１つのクラウドプラットフォームによってサポートされる負荷又は前記負荷に作用する運用保守特性を表すためのものであるステップと、
前記第２管理装置が前記第１管理装置からの前記アプリケーション能力によって、前記アプリケーション能力に対応する能力境界を決定するように前記第２管理装置を制御するステップであって、前記能力境界は、前記アプリケーション能力をサポートする各候補クラウドプラットフォームを表すためのものであるステップと、
前記能力境界によって、各前記候補クラウドプラットフォームに対するアプリケーションオーケストレーション・インスタンス化ポリシーを決定するステップと、を含む、クラウドプラットフォーム管理方法。

【請求項9】

前記能力境界によって、各前記候補クラウドプラットフォームに対するアプリケーションオーケストレーション・インスタンス化ポリシーを決定する前記ステップは、
前記能力境界によって各前記候補クラウドプラットフォームからアプリケーションオーケストレーション・インスタンス化を実行するためのターゲットクラウドプラットフォームを決定するステップを含む、請求項８に記載のクラウドプラットフォーム管理方法。

【請求項10】

前記能力境界によって、各前記候補クラウドプラットフォームに対するアプリケーションオーケストレーション・インスタンス化ポリシーを決定する前記ステップの後、
前記第１管理装置が前記ターゲットクラウドプラットフォーム及び前記アプリケーション能力によって、前記ターゲットクラウドプラットフォームによってサポートされるターゲットアプリケーション能力を決定するように前記第１管理装置を制御するステップをさらに含む、請求項９に記載のクラウドプラットフォーム管理方法。

【請求項11】

前記第１管理装置が前記ターゲットクラウドプラットフォーム及び前記アプリケーション能力によって、前記ターゲットクラウドプラットフォームによってサポートされるターゲットアプリケーション能力を決定するように前記第１管理装置を制御する前記ステップの後、
前記第１管理装置が前記ターゲットアプリケーション能力に対応するターゲット能力定義パケットを前記ターゲットクラウドプラットフォームに送信するように前記第１管理装置を制御するステップをさらに含む、請求項１０に記載のクラウドプラットフォーム管理方法。

【請求項12】

前記第２管理装置が前記第１管理装置からの前記アプリケーション能力によって、前記アプリケーション能力に対応する能力境界を決定するように前記第２管理装置を制御する前記ステップは、
前記第２管理装置が前記第１管理装置からの前記アプリケーション能力の動作状況をチェックし、前記第２管理装置が前記アプリケーション能力の前記動作状況に応じて前記アプリケーション能力を調整し、前記第２管理装置が調整された前記アプリケーション能力によって、調整された前記アプリケーション能力に対応する前記能力境界を決定するように前記第２管理装置を制御するステップをさらに含む、請求項８に記載のクラウドプラットフォーム管理方法。

【請求項13】

前記クラウドプラットフォーム管理アーキテクチャは、少なくとも１つの前記アプリケーション能力に対応する少なくとも１つの能力テンプレートを記憶するように構成された能力データベースをさらに含み、前記能力データベースは、前記第１管理装置を介して前記アプリケーションオーケストレーション・インスタンス化装置に接続され、
前記クラウドプラットフォーム管理方法は、
前記オープンアプリケーションモデルに基づいて、前記能力テンプレートに対応するプログラム可能なアプリケーション能力オーケストレーション要素を生成するステップをさらに含む、請求項８に記載のクラウドプラットフォーム管理方法。

【請求項14】

メモリと、プロセッサと、前記メモリに記憶され、前記プロセッサで動作可能なコンピュータプログラムとを含み、前記プロセッサは、前記コンピュータプログラムを実行すると、請求項８～１３のいずれか１項に記載のクラウドプラットフォーム管理方法を実現する、クラウドプラットフォーム管理装置。

【請求項15】

プロセッサによって実行すると、請求項８～１３のいずれか１項に記載のクラウドプラットフォーム管理方法を実現するためのコンピュータ実行可能命令を記憶したコンピュータ読み取り可能な記憶媒体。

【手続補正2】

【補正対象書類名】明細書

【補正対象項目名】０００９

【補正方法】変更

【補正の内容】

【0009】

第４態様では、本願の実施例はまた、プロセッサによって実行すると、上記の第２態様のクラウドプラットフォーム管理方法を実現するためのコンピュータ実行可能命令を記憶したコンピュータ読み取り可能な記憶媒体を提供する。

【国際調査報告】