特許7086065 | 知財ポータル「IP Force」

知財求人 - 知財ポータルサイト「IP Force」

▶ アリババ・グループ・ホールディング・リミテッドの特許一覧

特許7086065アプリケーションリンク拡張方法、装置、及びシステム

書誌要約請求の範囲詳細な説明課題実施例実施するための形態図面の説明

目に優しい文字サイズ小中大 PDF Top

< >

1
2
3
4
5

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

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

(11)【特許番号】

(24)【登録日】2022-06-09

(45)【発行日】2022-06-17

(54)【発明の名称】アプリケーションリンク拡張方法、装置、及びシステム

(51)【国際特許分類】

G06F 11/34 20060101AFI20220610BHJP

G06F 9/50 20060101ALI20220610BHJP

【ＦＩ】

G06F11/34 142

G06F11/34 133

G06F9/50 120A

【請求項の数】 12

(21)【出願番号】P 2019522310

(86)(22)【出願日】2017-10-20

(65)【公表番号】

(43)【公表日】2019-11-14

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

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

(87)【国際公開日】2018-05-11

【審査請求日】2020-09-29

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

(32)【優先日】2016-11-01

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

(73)【特許権者】

【識別番号】510330264

【氏名又は名称】アリババ・グループ・ホールディング・リミテッド

【氏名又は名称原語表記】ＡＬＩＢＡＢＡＧＲＯＵＰＨＯＬＤＩＮＧＬＩＭＩＴＥＤ

(74)【代理人】

【識別番号】110001243

【氏名又は名称】特許業務法人谷・阿部特許事務所

(72)【発明者】

【氏名】ユーチエンリー

(72)【発明者】

【氏名】ホワシュー

(72)【発明者】

【氏名】ユーディン

(72)【発明者】

【氏名】シンフェイヤン

(72)【発明者】

【氏名】タオホアン

【審査官】川▲崎▼ 博章

(56)【参考文献】

【文献】特開２０１０－２７２０９０（ＪＰ，Ａ）

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

【文献】特開２０１５－１１５０５９（ＪＰ，Ａ）

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

Ｇ０６Ｆ１１／３４

Ｇ０６Ｆ９／５０

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

【請求項1】

アプリケーションリンク拡張システムであって、
１つ以上のプロセッサと、
メモリと、
１つ以上のモジュールと
を備え、前記１つ以上のモジュールは、前記メモリに格納され、前記１つ以上のプロセッサによって実行されるように構成され、前記１つ以上のモジュールは、
サービスシナリオに関連付けられた少なくとも２つのアプリケーションによって形成される経路であるアプリケーションリンクを取得し、
前記アプリケーションリンク内の前記関連付けられた少なくとも２つのアプリケーションのための容量拡張に必要なターゲットリソースの情報を決定し、前記決定することは、
前記アプリケーションリンクに設定されているターゲットフロー情報を取得することと、
前記ターゲットフロー情報に基づいて、前記アプリケーションリンク内の前記関連付けられた少なくとも２つのアプリケーションの前記容量拡張に必要な前記ターゲットリソースの前記情報を計算することであって、
事前設定されたターゲットフローを処理するために前記アプリケーションリンク内の前記関連付けられた少なくとも２つのアプリケーションによって必要とされる総リソース情報を推定することと、
前記アプリケーションリンク内の前記関連付けられた少なくとも２つのアプリケーションの前記容量拡張に必要な前記ターゲットリソースの前記情報を取得するために、前記総リソース情報から占有リソース情報を減算することと
を含む、ことと
を含み、
前記ターゲットリソースの前記情報に従ってそれぞれのリソースを前記関連付けられた少なくとも２つのアプリケーションに割り当て、
前記それぞれのリソースに従って、前記関連付けられた少なくとも２つのアプリケーションのインスタンスを生成する
機能を有する、アプリケーションリンク拡張システム。

【請求項2】

アプリケーションリンク拡張方法であって、
サービスシナリオに関連付けられた少なくとも２つのアプリケーションによって形成される経路であるアプリケーションリンクを取得することと、
前記アプリケーションリンク内の前記関連付けられた少なくとも２つのアプリケーションのための容量拡張に必要なターゲットリソース情報を決定することであって、
前記アプリケーションリンクに設定されているターゲットフロー情報を取得することと、
前記ターゲットフロー情報に基づいて、前記アプリケーションリンク内の前記関連付けられた少なくとも２つのアプリケーションの前記容量拡張に必要な前記ターゲットリソース情報を計算することであって、
事前設定されたターゲットフローを処理するために前記アプリケーションリンク内の前記関連付けられた少なくとも２つのアプリケーションによって必要とされる総リソース情報を推定することと、
前記アプリケーションリンク内の前記関連付けられた少なくとも２つのアプリケーションの前記容量拡張に必要な前記ターゲットリソース情報を取得するために、前記総リソース情報から占有リソース情報を減算することと
を含む、ことと
を含むことと、
前記ターゲットリソース情報に従ってそれぞれのリソースを前記関連付けられた少なくとも２つのアプリケーションに割り当てることと、
前記それぞれのリソースに従って、前記関連付けられた少なくとも２つのアプリケーションのインスタンスを生成することと
を備える、方法。

【請求項3】

関連付けられた少なくとも２つのアプリケーションが前記アプリケーションリンク内で順序付けされ、先順序のアプリケーションが、その後の順序とされたアプリケーションによって提供されるサービスを呼び出して、前記先順序の前記アプリケーションによって提供されるサービスを実行する、請求項２に記載の方法。

【請求項4】

前記ターゲットフロー情報に基づいて、前記アプリケーションリンク内の前記関連付けられた少なくとも２つのアプリケーションの前記容量拡張に必要な前記ターゲットリソース情報を計算することは、
前記関連付けられた少なくとも２つのアプリケーションが複数のアプリケーションリンクを伴う場合、前記複数のアプリケーションリンク内のアプリケーションの容量拡張に必要なターゲットリソース情報の複数の部分を組み合わせることによって、前記関連付けられた少なくとも２つのアプリケーションの前記容量拡張に必要な前記ターゲットリソース情報を決定することを含む、請求項２に記載の方法。

【請求項5】

前記アプリケーションリンクのストレステストを実行することと、
前記ストレステストの結果に従って、前記関連付けられた少なくとも２つのアプリケーションに割り当てられた前記それぞれのリソースを修正することと
をさらに含む、請求項２ないし４のいずれか一項に記載の方法。

【請求項6】

前記アプリケーションリンクの前記ストレステストを実行することは、
特定のアプリケーションが複数のアプリケーションリンクを伴う場合に、ターゲットリソースを前記特定のアプリケーションにロックすることであって、前記ターゲットリソースは、前記ストレステストを受けるべきアプリケーションリンクの容量拡張に必要なリソース以外のリソースである、ことと、
ロックが成功した場合、前記ストレステストを受ける前記アプリケーションリンクの前記ストレステストを実行することと
を含む、請求項５に記載の方法。

【請求項7】

前記ストレステストの前記結果は、前記アプリケーションリンク内の前記関連付けられた少なくとも２つのアプリケーションの負荷情報及びフローを含み、
前記ストレステストの前記結果に従って、前記関連付けられた少なくとも２つのアプリケーションに割り当てられた前記それぞれのリソースを修正することは、
前記アプリケーションリンク内の前記関連付けられた少なくとも２つのアプリケーションの前記負荷情報は事前設定されたターゲット負荷情報に達せず、前記関連付けられた少なくとも２つのアプリケーションの前記フローは事前設定されたターゲットフローに達したときに、前記関連付けられた少なくとも２つのアプリケーションのリソース冗長性を確認することと、
前記関連付けられた少なくとも２つのアプリケーションの前記負荷情報及び前記フローに従って、前記アプリケーションリンクの下の前記関連付けられた少なくとも２つのアプリケーションに隔離及び容量削減処理を行うことと
を含む、請求項５に記載の方法。

【請求項8】

前記ストレステストの前記結果は、前記アプリケーションリンク内の前記関連付けられた少なくとも２つのアプリケーションの負荷情報及びフローを含み、
前記ストレステストの前記結果に従って、前記関連付けられた少なくとも２つのアプリケーションに割り当てられた前記それぞれのリソースを修正することは、
前記アプリケーションリンク内の前記関連付けられた少なくとも２つのアプリケーションの前記負荷情報が事前に設定されたターゲット負荷情報を超えた場合、前記関連付けられた少なくとも２つのアプリケーションの前記フローが事前に設定されたターゲットフローに達していても達していなくても、前記関連付けられた少なくとも２つのアプリケーションの前記リソースが不足していることを確認することと、
前記関連付けられた少なくとも２つのアプリケーションの前記負荷情報及び前記フローに従って、前記関連付けられた少なくとも２つのアプリケーションの容量拡張を行うことと
を含む、請求項５に記載の方法。

【請求項9】

アプリケーションリンク拡張装置であって、
アプリケーションリンクを取得するように構成されたアプリケーションリンク取得モジュールであって、前記アプリケーションリンクは、サービスシナリオに関して少なくとも２つの関連付けられたアプリケーションによって形成される経路である、アプリケーションリンク取得モジュールと、
前記アプリケーションリンク内の前記関連付けられた少なくとも２つのアプリケーションのための容量拡張に必要なターゲットリソースの情報を決定するように構成されたターゲットリソース情報決定モジュールであって、
前記アプリケーションリンクに設定されているターゲットフロー情報を取得することと、
前記ターゲットフロー情報に基づいて、前記アプリケーションリンク内の前記関連付けられた少なくとも２つの前記アプリケーションの前記容量拡張に必要な前記ターゲットリソースの前記情報を計算することであって、
事前設定されたターゲットフローを処理するために前記アプリケーションリンク内の前記関連付けられた少なくとも２つのアプリケーションによって必要とされる総リソース情報を推定することと、
前記アプリケーションリンク内の前記関連付けられた少なくとも２つのアプリケーションの前記容量拡張に必要な前記ターゲットリソースの前記情報を取得するために、前記総リソース情報から占有リソース情報を減算することと
を含む、ことと
を行うようにさらに構成された、ターゲットリソース情報決定モジュールと、
前記ターゲットリソースの前記情報に従ってそれぞれのリソースを前記関連付けられた少なくとも２つのアプリケーションに割り当てるように構成されたリソース割り当てモジュールと、
前記それぞれのリソースに従って、前記関連付けられた少なくとも２つのアプリケーションのインスタンスを生成するように構成されたインスタンス生成モジュールと
を備えた、アプリケーションリンク拡張装置。

【請求項10】

アプリケーションリンク拡張方法であって、
サービスシナリオに関連付けられた少なくとも２つのアプリケーションによって形成される経路であるアプリケーションリンクを取得することと、
前記アプリケーションリンク内の前記関連付けられた少なくとも２つのアプリケーションのための容量拡張に必要なターゲットリソース情報を決定することと、
前記ターゲットリソース情報に従ってそれぞれのリソースを前記関連付けられた少なくとも２つのアプリケーションに割り当てることと、
前記アプリケーションリンクのストレステストを実行することと、
前記ストレステストの結果に従って、前記関連付けられた少なくとも２つのアプリケーションに割り当てられた前記それぞれのリソースを修正することと、
前記それぞれのリソースに従って前記アプリケーションのインスタンスを生成することと
を備える、方法。

【請求項11】

１つまたは複数のプロセッサと、
前記１つまたは複数のプロセッサによって実行されると、前記１つまたは複数のプロセッサに、請求項１０に記載の方法を行わせる実行可能命令を格納するメモリと
を備えたシステム。

【請求項12】

１つまたは複数のプロセッサによって実行されると、前記１つまたは複数のプロセッサに、請求項１０に記載の方法を行わせる実行可能命令を格納するコンピュータ読取り可能記録媒体。

【発明の詳細な説明】

【技術分野】

【0001】

本出願は、２０１６年１１月１日に出願された中国特許出願第２０１６１０９５１５４８．３号「アプリケーションリンク拡張方法、装置及びシステム」の優先権を主張し、その全体が参照により本明細書に組み入れられる。

【0002】

本出願は、コンピュータ処理の技術分野に関し、特にアプリケーションリンク拡張方法、装置、及びシステムに関する。

【背景技術】

【0003】

クラウドコンピューティングは、インターネット上で動的にスケーラブルな仮想リソースをサービスの形で提供するコンピューティングモデルである。このアプローチを通じて、共有ハードウェア及びソフトウェアリソース並びに情報をオンデマンドでコンピュータ及び他の装置に提供することができる。

【0004】

クラウドコンピューティングの基本的な環境は仮想化である。

【0005】

アプリケーションは仮想マシン（ＶＭ、ＶｉｒｔｕａｌＭａｃｈｉｎｅｓ）又はＤｏｃｋｅｒコンテナを介して展開され、クラウドコンピューティングのリソースを共有する。

【0006】

電子商取引のプロモーションなどの場合、システムが引き受けるプレッシャーは、通常の期間中のそれとは数桁異なる。電子商取引のプロモーションのような比較的高い負荷条件下でアプリケーションが正常に動作できることを保証するために、通常、アプリケーションの容量のアップスケーリングが行われる。

【0007】

電子商取引のプロモーションなどのような状況では、多数のアプリケーション（１０００にもなる可能性がある）が関係している。これらのアプリケーションには、リソースの再評価が必要なものと必要ないものとがある。

【0008】

拡張が必要なアプリケーションの場合、従来のアプローチは、単一のアプリケーションが負担する必要がある負荷圧力と既存のリソースサービス能力を事前評価し、それによって拡張が必要なリソースの量を計算することである。次に、リソース割り当てシステムが呼び出されて、対応するリソースを適用し割り当てる。

【0009】

このタイプのソリューションは、単一のアプリケーションの観点からのみ出発している。アプリケーションが他のアプリケーションによって呼び出されると、これらのリソースが不足し、アプリケーションがシステムの脆弱性となり、電子商取引のプロモーションなどの場合に、システムの不安定さを容易に招く可能性がある。より多くのリソースがそのアプリケーションに割り当てられた場合、リソースの浪費を生じる可能性がある。

【発明の概要】

【0010】

上記問題に鑑み、本発明の実施形態は、上記問題を解決するか又は上記問題を少なくとも部分的に解決するアプリケーションリンク拡張方法、対応するアプリケーションリンク拡張装置、及びアプリケーションリンク拡張システムを提供するために提案される。

【0011】

一態様では、本出願の実施形態は、アプリケーションリンク拡張システムを開示する。このシステムは、１つ以上のプロセッサと、メモリと、１つ以上のモジュールと、を備え、前記１つ以上のモジュールは、前記メモリに格納され前記１つ以上のプロセッサによって実行されるように構成され、前記１つ以上のモジュールは、アプリケーションリンクであって、１つのサービスシナリオに関連付けられた少なくとも２つのアプリケーションによって形成される経路である前記アプリケーションリンクを取得し、前記アプリケーションリンク内のすべてのアプリケーションのための容量拡張に必要なターゲットリソースの情報を決定し、前記ターゲットリソースの情報に従ってそれぞれのリソースを前記アプリケーションに割り当て、前記それぞれのリソースに従って前記アプリケーションのインスタンスを生成する、機能を有する。

【0012】

別の態様では、本出願の実施形態は、アプリケーションリンク拡張方法を開示する。１つのサービスシナリオに関連付けられた少なくとも２つのアプリケーションによって形成される経路である前記アプリケーションリンクを取得することと、前記アプリケーションリンク内のすべてのアプリケーションのための容量拡張に必要なターゲットリソースの情報を決定することと、前記ターゲットリソースの情報に従ってそれぞれのリソースを前記アプリケーションに割り当てることと、前記それぞれのリソースに従って前記アプリケーションのインスタンスを生成することとが含まれる。

【0013】

さらに別の態様では、本出願の実施形態は、アプリケーションリンク拡張装置を開示する。アプリケーションリンクを取得するように構成されたアプリケーションリンク取得モジュールであって、前記アプリケーションリンクは、１つのサービスシナリオに関して少なくとも２つの関連付けられたアプリケーションによって形成される経路である前記アプリケーションリンク取得モジュールと、前記アプリケーションリンク内のすべてのアプリケーションのための容量拡張に必要なターゲットリソースの情報を決定するように構成されたターゲットリソース情報決定モジュールと、それぞれのリソースを前記ターゲットリソースの前記情報に従って前記アプリケーションに割り当てるように構成されたリソース割り当てモジュールと、前記アプリケーションのためのインスタンスを上記それぞれのリソースに従って生成するように構成されたインスタンス生成モジュールとが含まれる。

【0014】

本出願の実施形態は、以下の利点を含む。

【0015】

本出願の実施形態では、アプリケーションリンク内のアプリケーションについて容量拡張に必要なターゲットリソースの情報が決定され、そのターゲットリソース情報に従ってリソースがアプリケーションに割り当てられる。アプリケーションのインスタンスがリソースを使用して生成される。サービスの観点からは、リンク内の関連アプリケーションの容量が全体として評価され、リンク全体の容量拡張がなされることによりリソースが完全利用され、アプリケーションが他のアプリケーションから呼び出されリソース不足に陥ることが防止される。これにより、アプリケーションがシステムの脆弱性となることが確実に防止され、さらにシステムの安定性が確保される。また、アプリケーションへの過剰なリソース割り当てが回避され、リソースの浪費が削減される。

【図面の簡単な説明】

【0016】

【図1】本出願の実施形態によるアプリケーションリンク拡張方法のフローチャートである。

【図2】本出願の実施形態によるアプリケーションのリンクを拡張するための別のアプリケーションリンク拡張方法のフローチャートである。

【図3】本出願の実施形態によるアプリケーションリンク拡張の一例を示す図である。

【図4】本出願の実施形態のアプリケーションリンク拡張装置の構成ブロック図である。

【図5】本出願のサーバ実施形態の概略構造図である。

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

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

任意選択で、１つ以上のモジュールは以下の機能を有することができる。

【0134】

アプリケーションが複数のアプリケーションリンクを伴い、ターゲットリソースが、ストレステストを受けるべきアプリケーションリンク（複数可）の容量拡張に必要なリソース以外のリソースである場合に、ターゲットリソースを特定のアプリケーションのためにロックすることと、ロックが成功した場合、ストレステストを受けるアプリケーションリンク（複数可）のストレステストを実行すること。

【0135】

任意選択で、ストレステストの結果は、アプリケーションリンク内のアプリケーションの負荷情報及びフローを含み、１つ以上のモジュールは、以下の機能を有することができる。

【0136】

アプリケーションリンク内のアプリケーションの負荷情報が事前設定されたターゲット負荷情報に達せず、フローが事前設定されたターゲットフローに達したときに、アプリケーションのリソース冗長性を確認することと、負荷情報とアプリケーションのフローに従って、アプリケーションリンク配下のアプリケーションの隔離及び容量削減処理を行うこと。

【0137】

【0138】

アプリケーションリンク内のアプリケーションの負荷の情報が事前に設定されたターゲット負荷情報を超えた場合、フローが事前に設定されたターゲットフローに達していても達していなくても、アプリケーションのリソースが不足していることを確認し、負荷情報とアプリケーションのフローに従って、アプリケーションの容量拡張処理を行うこと。

【0139】

図５は本出願の実施形態によって提供されるサーバの概略構造図である。サーバ５００は、構成又は性能に従ってかなり変動する可能性があり、１つ以上の中央処理装置（ＣＰＵ）５２２（例えば１つ以上のプロセッサ）、メモリ５３２、及びアプリケーションプログラム５４２又はデータ５４４を記憶する１つ以上の記憶媒体５３０（例えば１つ以上の大容量記憶装置）を含むことができる。メモリ５３２及び記憶媒体５３０は、一時記憶装置又は永続記憶装置とすることができる。記憶媒体５３０に記憶されたプログラムは、１つ以上のモジュール（図示せず）を含むことができ、各モジュールはサーバ内の一連の命令動作を含むことができる。さらに、中央処理装置５２２は、記憶媒体５３０と通信し、サーバ５００上の記憶媒体５３０内で一連の命令動作を実行するように構成することができる。

【0140】

サーバ５００は、１つ以上の電源５２６、１つ以上の有線又は無線ネットワークインターフェース５５０、１つ以上の入出力インターフェース５５８、１つ以上のキーボード５５６、及び／又はＷｉｎｄｏｗｓＳｅｒｖｅｒ（登録商標）、ＭａｃＯＳＸ（登録商標）、Ｕｎｉｘ（登録商標）、Ｌｉｎｕｘ（登録商標）、ＦｒｅｅＢＳＤ（登録商標）などの１つ以上のオペレーティングシステム５４１も含み得る。

【0141】

中央処理装置５２２は、サーバ５００上で以下の動作の命令を実行することができる。

【0142】

１つのサービスシナリオに関して少なくとも２つの関連付けられたアプリケーションによって形成される経路であるアプリケーションリンクを取得すること、アプリケーションリンク内のすべてのアプリケーションのための容量拡張に必要なターゲットリソースの情報を決定すること、ターゲットリソースの情報に従ってそれぞれのリソースをアプリケーションに割り当てること、及びそれぞれのリソースに従ってアプリケーションのためのインスタンスを生成すること。

【0143】

任意選択で、少なくとも２つのアプリケーションがアプリケーションリンク内で順序付けされ、先順序のアプリケーションが、その後の順序とされたアプリケーションによって提供されるサービスを呼び出すことにより、先順序のアプリケーションによって提供されるサービスを実行する。

【0144】