JP2019533256A - アプリケーションリンク拡張方法、装置、及びシステム - Google Patents

Abstract

本出願の実施形態ではアプリケーションリンク拡張、装置及びシステムが提供される。方法は、サービスシナリオに関連付けられた少なくとも２つのアプリケーションによって形成される経路であるアプリケーションリンクを取得することと、アプリケーションリンク内のすべてのアプリケーションのための容量拡張に必要なターゲットリソースの情報を決定することと、ターゲットリソースの情報に従ってそれぞれのリソースをアプリケーションに割り当てることと、それぞれのリソースに従ってアプリケーションのインスタンスを生成することと、を含む。サービスの観点からは、本出願の実施形態では、リンク内の関連アプリケーションの容量を全体として評価、リンク全体の容量拡張を行うことにより、リソースを完全利用し、アプリケーションが他のアプリケーションから呼び出されリソース不足に陥ることが防止される。これにより、アプリケーションがシステムの脆弱性となることが確実に防止され、システムの安定性を確保し、アプリケーションへの過剰なリソース割り当てを回避して、リソースの浪費を削減する。

Description

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

本出願の実施形態によるアプリケーションリンク拡張方法のフローチャートである。 本出願の実施形態によるアプリケーションのリンクを拡張するための別のアプリケーションリンク拡張方法のフローチャートである。 本出願の実施形態によるアプリケーションリンク拡張の一例を示す図である。 本出願の実施形態のアプリケーションリンク拡張装置の構成ブロック図である。 本出願のサーバ実施形態の概略構造図である。

本出願の上記の目的、特徴及び利点をより明白かつ容易に理解できるようにするために、添付の図面及び特定の実施形態に関連して本出願を以下にさらに詳細に説明する。

図１を参照すると、本出願のアプリケーションリンク拡張方法の一実施形態のフローチャートが示されており、それは具体的には以下のステップを含むことができる。

ステップ１０１：アプリケーションリンクを取得する。

本出願の実施形態は、クラウドコンピューティングベースのプラットフォームに適用することができる。クラウドコンピューティングベースのプラットフォームは巨視的な概念であり、サービスの属性やサービスの形態により関連している。そのようなプラットフォームは複数のアプリケーションから構築される。

クラウドコンピューティングベースのプラットフォームでは、アプリケーションは複数のインスタンスを生成でき、これらのインスタンスはアプリケーションクラスタを形成できる。

これらのアプリケーションは、ウェブ（ウェブページ）アプリケーションを含み得る。このようなウェブアプリケーションは、必ずしもウェブに限定されるものではなく、無線ＡＰＰ（アプリケーション）などのアプリケーションであってもよい。例えば、クラウドコンピューティングプラットフォームが電子商取引プラットフォームである場合、そのようなプラットフォームの特定のアプリケーションは製品データを照会する機能を実装でき、その特定のアプリケーションは、会員情報を取得し、配送先住所を受け取る機能などを実装することができる。

Ｗｅｂアプリケーションは、分散システムなどのクラウドコンピューティングベースのコンピュータクラスタに展開することができる。具体的には、ユーザー（開発者）から提示されたＷｅｂアプリケーションプログラムは対応するＷｅｂコンテナに配置され、ロードバランサ、データベース、ストレージサービスなどの対応するサポートコンポーネントが構成され、最終的にＷｅｂアプリケーションは正確かつ完璧に動作する。

クラウドベースコンピューティングとは、Ｗｅｂアプリケーションの展開と拡張のアーキテクチャ、プロセス、及びモデルをクラウドコンピューティングの基本環境に適合させることをいい、クラウドコンピューティングの一般的なＩａａｓ（Ｉｎｆｒａｓｔｒｕｃｔｕｒｅ ａｓ ａ Ｓｅｒｖｉｃｅ）を使用した迅速な展開と動的な容量拡張を可能とし、ＰａａＳ（サービスとしてのプラットフォーム）を提供する。

Ｗｅｂアプリケーションの拡張は、Ｗｅｂアプリケーションの負荷が頻繁かつ急激に変化することを狙いとしている。負荷の変化に適応するようにウェブアプリケーションの動作中のサービス容量を動的に増減してさせることによって、サービス品質を保証しつつサービスリソースの利用率が改善される。

本出願の実施形態では、容量を拡張する必要があるサービスオブジェクトのアプリケーションリンクは、事前に収集することができ、アプリケーションリンクは、サービスシナリオに関して少なくとも２つの関連付けられたアプリケーションによって形成される経路である。

実際のアプリケーションでは、サービスの属性に従って、これらのアプリケーションサービスは多数のオブジェクトと関連関係を持つことができる。あるサービスシナリオのリンク指向のサービス経路だけが関係する場合、それはリンク指向の関係として抽象化することができる。

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

電子商取引の購入者のリンクが、アプリケーションリンクの例として使用される。購入者のリンクには以下が含まれる。

製品データの照会→会員情報、配送先住所を取得→製品在庫を確認→未払いの注文数を確認→注文を分割、最適化情報を確認→物理的情報、郵便料金、送料、及び購入制限を確認→付加価値サービスを確認→注文を生成→支払いを実行→評価、アフターセールスなど

製品データ照会などのオペレーションは、アプリケーションによって実行される機能であり、「→」はアプリケーション間の呼び出し関係を表す。

ステップ１０２：アプリケーションリンク内のすべてのアプリケーションの容量拡張に必要なターゲットリソース情報を決定する。

具体的な実装では、アプリケーションリンク内のアプリケーションは一般に依存関係を有するので、アプリケーションリンク内のすべてのアプリケーションの容量拡張に必要なターゲットリソース情報は、全体として事前に推定することができる。

本出願の実施形態では、ステップ１０２は、以下のサブステップを含み得る。

サブステップＳ１１：アプリケーションリンクに対して構成されているターゲットフロー情報を取得する。

サブステップＳ１２：ターゲットフロー情報に基づいて、アプリケーションリンク内のすべてのアプリケーションの容量拡張に必要なターゲットリソース情報を計算する。

具体的な実装形態では、サービスシナリオの特徴に従って、アプリケーションリンク全体のエントリ開始要求のピークフロー又は提供されることが予想されるフローデータが、ターゲットフロー情報として事前に推定され得る。このターゲットフロー情報に従ってアプリケーションリンクのリソース割り当てが行われる。

例えば、電子商取引のプロモーションなどのような状況では、意思決定レベルにおいて全体的な指標がリソース準備段階で策定される。１２ｗ／ｓの取引注文が出された場合、１２ｗ／ｓの注文が作成され、８ｗ／ｓの支払いが行われ、過剰な部分はアプリケーションによって自動的に制限される。このフロー制限を前提として、対応するトランザクション制限１２ｗ／ｓが設定されている。

対応する購入者のリンクにはキーノードが含まれる：照会した製品情報→会員情報、配送先住所を取得→製品在庫を確認→未払いの注文数を確認→注文を分割、最適化情報を確認→物理的情報、郵便料金、送料、及び購入制限を確認→付加価値サービスを確認→注文を生成→支払いを実行→評価、アフターセールスなど。

アプリケーション「製品データ照会アプリケーション」のフローは、１２ｗ／ｓよりはるかに大きい。アプリケーション「注文を生成」のフローのピーク値は１２ｗ／ｓである。「支払いを実行」アプリケーションのフローのピーク値は８ｗ／ｓである。

アプリケーションリンクに対するエントリ開始要求のピークフローは、容量の準備段階における決定に由来する。この決定は、過去のシステム維持能力、新しいリソースの準備、及びシステム最適化能力に基づくものであり、その後、最大処理容量が総合的に評価される。過剰な部分はフロー制限によって放棄され、システムを保護し、対象の高可用性を確保する。

リンク関係及びリンク履歴アプリケーションフロー情報などのデータが取得され、リンク上のアプリケーションノードの直接フロー比が形成される。事前設定されたターゲットフローを処理するためにアプリケーションリンク内のすべてのアプリケーションに必要とされる総リソースに関する情報が推定される。

リンク履歴アプリケーションフロー情報について、「製品データ照会」アプリケーションのフローが１２０ｗの場合、「会員情報、配送先住所取得」アプリケーションのフローは５０ｗ、「製品在庫確認」アプリケーションのフローは歴史的に１０ｗであり、購入者のリンク上のこれら３つのアプリケーションのフロー情報の比率は１２０：５０：１０である。

これらの比率は、アプリケーションリンク内のアプリケーションの容量が拡張されたときに要件が基本的に満たされるよう、リソースを初期化するための基礎として使用できる。

総リソースに関する情報から占有リソースに関する情報を減算することにより、アプリケーションリンク内のすべてのアプリケーションの容量拡張に必要なターゲットリソースに関する情報が取得される。

例えば、フローピーク値１２ｗ／ｓは、購入者のリンクのアプリケーション「製品データ照会」のリソース割り当てに対応する。サービス能力のこの部分は、Ｎ＊１２ｗのサービス能力としてモデル化され、ここでＮは倍数、すなわち１２ｗのサービス能力の数倍である。１２ｗの場合、２ ＊ Ｎのリソースが必要である。１４ｗのとき、１４／１２ ＊ ２ ＊ Ｎ ＝ ７／３Ｎのリソースが必要である。２Ｎのリソースを準備する場合、１／３Ｎのリソースを準備する必要がある。

このような詳細な分割により、アプリケーションリンク上の各アプリケーションのターゲットリソース情報が取得され、リソースが追加又は解放される。

本出願の実施形態では、アプリケーションが複数のアプリケーションリンクを伴う場合、複数のアプリケーションリンクにおけるアプリケーションの容量拡張に必要なターゲットリソースのそれぞれの情報を組み合わせることによって、アプリケーションの容量拡張に必要なターゲットリソースの情報が決定される。

例えば、購買者のリンクに対応するアプリケーション「製品データ照会」の次のアプリケーション「会員情報、配送先住所」は会員リンクに関連しており、購買者のリンクのエントリへのフローに対して線形ではない。

必要なリソースは、メンバーリンクのユーザーの増加傾向、同時にオンライン接続するユーザー数などの情報を使用して評価する必要がある。

ステップ１０３：ターゲットリソース情報に従ってアプリケーションにリソースを割り当てる。

コンピュータクラスタでは、アイドル状態のリソースを有するサーバを、アプリケーション実行機能、アプリケーション安定性機能、及び隣接アプリケーション機能などのデータに基づいて選択することができ、リソースがアプリケーションに割り当てられる。

例えば、特定のアプリケーションが比較的大量のＣＰＵ／帯域幅（アプリケーション実行機能）を占有する場合は、比較的少量のＣＰＵ／帯域幅を占有するアプリケーション（隣接アプリケーション機能）が展開されているターゲットサーバーが選択される。例えば、注文アプリケーション（注文が失われた場合、ショッピングサイトは支払いを返金する必要がある）など、特定のアプリケーション（アプリケーション実行機能）がリソースの損失を伴う場合、リソースの損失を伴うアプリケーション（隣接アプリケーション機能）の展開がより少ないターゲットサーバーが選択される。

別の例では、あるアプリケーションが調整ノード（アプリケーション安定性機能）である場合、その展開は、同じサーバ上に集中して展開されることを回避するためにできるだけ分散される。アプリケーションのインスタンスはできるだけ分散され（アプリケーション安定性機能）、例えば、同じサーバへの集中的な展開は避けられる。

仮想マシンは、サーバに基づいて「仮想化」されているリソースである。仮想マシンをサーバに適用することは、アプリケーションの容量拡張に必要なインスタンスのリソースをサーバに適用することと同じである。

ステップ１０４：リソースを使用してアプリケーション用のインスタンスを生成する。

アプリケーションが成功した後、予め設定されたコンテナミラーリングセンター内のアプリケーションのイメージファイルがアプリケーションの名前に従って取得され、サーバにダウンロードされる。ターゲットサーバー上のエージェント（ａｇｅｎｔ）がミラーリング展開タスクを実行するために実行される。

仮想マシンがＸＥＮ、ＬＶＭ、ＣＬＯＣＫＥＲ、ＬＸＣなど、様々であるため、ミラーリング展開タスクも異なる。

仮想化タスクが完了した後、インスタンス、すなわち実行アプリケーションを起動することができる。

例えば、仮想マシンがＣＬＯＣＫＥＲの場合、仮想化時にコンテナが使用される。コマンドｃｌｏｃｋｅｒ ｐｕｌｌ ＜ｉｍａｇｅ＿ｎａｍｅ＞及びｃｌｏｃｋｅｒ ｒｕｎ＜ｉｍａｇｅ＿ｎａｍｅ＞を入力後、仮想マシンが展開されコンテナが起動される。Ｉｍａｇｅ＿ｎａｍｅはイメージの名前である。

別の例では、仮想マシンがＶＭの場合、エージェントがＶＭにインストールされる。アプリケーションの命令が開始されると、ＶＭに展開されるアプリケーションを開始するために、開始コマンドをＶＭエージェントに送信する必要がある。

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

図２を参照すると、他のアプリケーションリンク拡張方法の一実施形態のフローチャートが示されている。具体的には、この方法は以下のステップを含み得る。

ステップ２０１：アプリケーションリンクを取得する。

アプリケーションリンクは、サービスシナリオのために少なくとも関連付けられたアプリケーションによって形成される経路である。

ステップ２０２：アプリケーションリンク内のすべてのアプリケーションの容量拡張に必要なターゲットリソース情報を決定する。

ステップ２０３：ターゲットリソース情報に従ってアプリケーションにリソースを割り当てる。

ステップ２０４：リソースを使用してアプリケーション用のインスタンスを生成する。

ステップ２０５：アプリケーションリンク上でストレステストを実行する。

アプリケーションリンク用のリソースを最初に準備した後、リンクストレス測定ツールを使用してリンク指向のパフォーマンステストを実行できる。

特定の実施形態では、シミュレーション要求データを構築することができ、ストレス測定ツールはシミュレーション要求データを読み取り、同時要求をシミュレートする。要求はアプリケーションリンクのアプリケーション間で送信される。

アプリケーションは、同時に複数のアプリケーションリンクを伴うことがある。実際のシナリオでは複数のアプリケーションリンクが同時に開始されるので、アプリケーションクロスリンク要求の数及びアプリケーションクロスリンク要求の時点を各シミュレーションに対して完全に一致させることは困難である。従って、これらすべてをリソースに対して部分的に修正する必要がある。

この場合、最初に単一のアプリケーションリンクのリソースが十分であることを保証することができ、次いですべてのアプリケーションリンクに対するストレステストが同時に実行されることによりリソース修正が行われる。

特定のアプリケーションが複数のアプリケーションリンクを伴うとき、ターゲットリソースはそのアプリケーションにロックされることに留意されたい。ターゲットリソースは、ストレステストを受ける対象となるアプリケーションリンクの容量拡張に必要なリソース以外のリソースである。

ロックが成功すると、ストレステストが行われる予定のアプリケーションリンクに対してストレステストが実行される。

例えば、あるアプリケーションはアプリケーションリンクＡとアプリケーションリンクＢとを伴う。アプリケーションがアプリケーションリンクＡ上の容量拡張のために５０個のリソースとアプリケーションリンクＢ上の容量拡張のために９０個のリソースを必要とする場合、リソースの準備の間１４０個のリソースが準備され得る。ただし、アプリケーションリンクＡでストレステストが実行されると、５０個のリソースがアプリケーションに割り当てられ、残りの９０個のリソースはロックされる。アプリケーションリンクＢでストレステストが実行されると、９０個のリソースがアプリケーションに割り当てられ、残りの５０個のリソースはロックされる。ストレステストがアプリケーションリンクＡとアプリケーションリンクＢに同時に適用されると、１４０個のリソースがアプリケーションに割り当てられる。

ステップ２０６：ストレステストの結果に従ってアプリケーションに割り当てられたリソースを調整する。

ストレステスト中、ストレステストの結果には、アプリケーションリンク内のアプリケーションの負荷情報とフローが含まれる。

ある場合には、アプリケーションリンク内のアプリケーションの負荷情報が予め設定されたターゲット負荷情報に達しておらず、予め設定されたターゲットフローに達したときに、アプリケーションのリソースの冗長性が確認される。

削減するリソース量は負荷情報とアプリケーションのフローに基づいて計算され、現在のアプリケーションリンクのアプリケーションに対して隔離と削減の処理が実行される。

分離及び削減処理は、実際には容量の削減ではない。冗長インスタンスはまだ存在するが、現在のアプリケーションリンクのストレステストには関与しない。他のアプリケーションリンクはより多くのインスタンスを必要とし得る。この場合、この冗長部分を直接使用できる。

各アプリケーションリンクの冗長性を最初に記録できる。ストレステストがすべてのアプリケーションリンクに対して実行された後、容量の実際の削減が実行される。

例えば、アプリケーションＡがアプリケーションリンク１上に冗長性を有する場合、アプリケーションリンク２上に冗長性が存在しない可能性がある。冗長リソースはアプリケーションリンク１内で分離され、アプリケーションリンク１のストレステストに含まれない。ストレステストがアプリケーションリンク２で実行される際に、冗長リソースが再び追加される。アプリケーションリンク２のリソースが不足する場合は、リソースを直接追加することができる。

容量削減には２つのアプローチがある。１つのアプローチは、アプリケーションをオフラインにしてリソースを解放することである。もう１つのアプローチは、アプリケーションをオフラインにし、リソースを他のアプリケーションによる使用のために予約することである。すなわち、他のアプリケーションがこれらのリソースを使用する場合、完全なリソース適用は行なわずアプリケーション情報の更新のみが必要である。

あるいは、アプリケーションリンク内のアプリケーションの負荷情報が予め設定されたターゲット負荷情報を超えている場合、フローが予め設定されたターゲットフローに達していてもいなくても、アプリケーションのリソース不足が確認される。

拡張すべきリソース量が、負荷情報とアプリケーションのフローに基づいて計算され、アプリケーションに対する容量拡張が行われる。

本出願の実施形態は、アプリケーションリンク上でストレステストを実行し、ストレステストの結果に従ってアプリケーションに割り当てられたリソースを調整する。ストレステストと調整を複数回実行することで、リソースの使用率をさらに向上させ、リソースの可用性を確保し、システムを安定させつつリソースの浪費を最小限に抑えることができる。

当業者が本出願の実施形態をよりよく理解することを可能にするために、本出願の実施形態によるアプリケーションの容量を拡張するための方法が、図３に示されるような特定の例を使用して以下に説明される。

ステップ１：リンク拡張要求ページでリンク拡張要求を開始し、拡張情報を送信する。

ステップ２：リンク拡張制御システムは、リンク拡張要求を受信した後、リンク関係情報システムからリンク情報を取得する。

リンク関係情報システムは、リンク情報をリンク拡張制御システムに送信する。

ステップ３：リンク拡張制御システムは、リンク容量評価を実行するために、リンク関係及び容量要件をリンク容量評価システムに転送する。

リンク容量評価システムは、容量評価結果をリンク拡張制御システムに返す。

ステップ４：リンク拡張制御システムは、フロー分割のためにリンクノードフロー分割システムにリンク容量を送信する。

ステップ５：リンクノードのフローを分割した後、リンクノードフロー分割システムはリンクノード拡張システムを呼び出してリンク指向ノード容量拡張を実行する。

ステップ６：リンクノード拡張システムは初期容量拡張を完了し、結果をリンク拡張制御システムに返し、リンク拡張制御システムはリンクストレステストシステムにリンクストレステストを実行するように要求する。

ステップ７：リンクストレステストシステムは、リンクに対してストレステストを実行し、リンク容量調整要求を開始する。

ステップ８：リンクノード拡張システムは、ノードの容量拡張及び縮小要求を受信し、リンクノードの容量拡張の調整をリンク拡張調整システムに対して実行し、リンクノード拡張システムを呼び出してノードの容量拡張又は縮小を実行する。ノードの容量拡張又は縮小が完了した後、実行結果がリンク拡張制御システムに返される。

ステップ９：リンク拡張制御システムはリンクのストレステストを再度開始し、リンクストレステストシステムにリンクのストレステストを実行するように要求する。

リンクストレステストシステムはリンクのストレステストを実行し、リンク容量調整要求を開始する。

リンクノード拡張システムは、ノードの容量拡張及び縮小要求を受けてリンク拡張調整システムに対してリンクノードの容量増設の調整を行い、リンクノード拡張システムを呼び出してノードの容量増減を行う。ノードの容量拡張又は縮小が完了した後、実行結果がリンク拡張制御システムに返される。

ステップ１０：ステップ７〜９が繰り返され、最終的に期待される効果を満たす容量が、ストレステスト・調整・ストレステスト・調整によって達成される。

ステップ１１：容量拡張が終了すると、容量の実行結果をリンク拡張要求システムに返し、処理情報を記録する。

方法の実施形態はすべて、説明のために一連の動作の組み合わせとして表現されていることに留意されたい。しかしながら、当業者は、特定のステップが本出願の実施形態に従って他の順序で又は並行して実行され得るので、本出願の実施形態が記載された動作順序によって限定されないことを理解されたい。さらに、当業者はまた、本明細書に記載されている実施形態はすべて好ましい実施形態であり、それらに含まれる動作は本出願の実施形態において必ずしも必要ではない場合があることを理解されたい。

図４を参照すると、本出願のアプリケーションリンク拡張装置の一実施形態の構造ブロック図が示されており、それは特に以下のモジュールを含むことができる。

アプリケーションリンク取得モジュール４０１は、アプリケーションリンクを取得するように構成されており、アプリケーションリンクは、サービスシナリオに関連付けられた少なくとも２つのアプリケーションによって形成される経路である。

ターゲットリソース情報決定モジュール４０２は、アプリケーションリンク内のすべてのアプリケーションのための容量拡張に必要なターゲットリソースの情報を決定するように構成される。

リソース割り当てモジュール４０３は、ターゲットリソースの情報に従ってそれぞれのリソースをアプリケーションに割り当てるように構成される。

インスタンス生成モジュール４０４は、それぞれのリソースに従ってアプリケーションのインスタンスを生成するように構成されている。

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

本出願の実施形態では、ターゲットリソース情報決定モジュール４０２は、以下のサブモジュールを含むことができる。

アプリケーションリンク用に構成されたターゲットフロー情報を取得するように構成されたターゲットフロー情報取得サブモジュール、及び、ターゲットフロー情報に基づいてアプリケーションリンク内のすべてのアプリケーションの容量拡張に必要なターゲットリソース情報を計算するように構成されたターゲットリソース情報計算サブモジュール。

本出願の実施形態では、ターゲットリソース情報計算サブモジュールは、以下のユニットを含むことができる。

アプリケーションリンク内のすべてのアプリケーションが予め設定されたターゲットフローを処理するのに必要な総リソースの情報を推定するように構成された総リソース情報推定ユニット、及び、総リソース情報から占有リソース情報を減算してアプリケーションリンク内のアプリケーションの容量拡張に必要なターゲットリソースの情報を取得するように構成されたリソース情報減算ユニット。

本出願の実施形態において、ターゲットリソース情報計算サブモジュールは、以下のユニットを含むことができる。

アプリケーションが複数のアプリケーションリンクを伴う場合、複数のアプリケーションリンク内のアプリケーションの容量拡張に必要なターゲットリソース情報の複数のリソースを組み合わせることによってアプリケーションの容量拡張に必要なターゲットリソースの情報を決定するように構成されたマルチリソース情報結合ユニット。

本出願の実施形態では、装置はさらに以下のモジュールを含むことができる。
アプリケーションリンク上でストレステストを実行するように構成されたストレステストモジュール、及び、ストレステストの結果に従ってアプリケーションに割り当てられたリソースを修正するように構成されたリソース調整モジュール。

本出願の実施形態では、ストレステストモジュールは、以下のサブモジュールを含むことができる。

ターゲットリソースがストレステストを受ける対象となるアプリケーションリンク（複数可）の容量拡張に必要なリソース以外のリソースであって、アプリケーションが複数のアプリケーションリンクを伴う場合、ターゲットリソースを特定のアプリケーションにロックするように構成されたターゲットリソースロックサブモジュール、及び、ロックが成功したときにストレステストを受ける対象となるアプリケーションリンク（複数可）に対してストレステストを実行するように構成されたターゲットテストサブモジュール。

本出願の実施形態では、ストレステストの結果は、アプリケーションリンク内のアプリケーションの負荷情報及びフローを含み、リソース調整モジュールは、以下のサブモジュールを含むことができる。

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

本出願の実施形態では、ストレステストの結果は、アプリケーションリンク内のアプリケーションの負荷情報及びフローを含み、リソース調整モジュールは、以下のサブモジュールを含むことができる。

アプリケーションリンク内のアプリケーションの負荷情報が事前設定されたターゲット負荷情報を超えた場合、フローが事前に設定されたターゲットフローに達していても達していなくても、アプリケーションのリソースが不十分であることを確認するように構成されたリソース不足確認サブモジュール、及び、負荷情報及びアプリケーションのフローに従ってアプリケーションの容量拡張処理を行うように構成された容量拡張処理サブモジュール。

装置の実施形態の説明は、方法の実施形態と基本的に類似しているため、比較的単純であり、関連する部分は方法の実施形態のそれぞれの部分の説明を参照することができる。

本発明の実施形態では、さらに、アプリケーションリンク拡張システムが提供される。システムは以下を含む。

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

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

任意選択で、１つ以上のモジュールは以下の機能を有することができる。
アプリケーションリンクに対して構成されているターゲットフロー情報を取得すること。そして、ターゲットフロー情報に基づいて、アプリケーションリンク内の全アプリケーションの容量拡張に必要なターゲットリソース情報を計算すること。

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

アプリケーションリンク内のすべてのアプリケーションが予め設定されたターゲットフローを処理するのに必要な総リソースの情報を推定すること。そして、アプリケーションリンク内のアプリケーションの容量拡張に必要なターゲットリソースの情報を取得するために、総リソース情報から占有リソース情報を減算すること。

任意選択で、１つ以上のモジュールは以下の機能を有することができる。
アプリケーションが複数のアプリケーションリンクを伴う場合、複数のアプリケーションリンク内のアプリケーションの容量拡張に必要なターゲットリソース情報の複数の部分を組み合わせることによって、アプリケーションの容量拡張に必要なターゲットリソース情報を決定すること。

任意選択で、１つ以上のモジュールは以下の機能を有することができる。
アプリケーションリンクのストレステストを実行すること。そして、ストレステストの結果に従ってアプリケーションに割り当てられたリソースを修正すること。

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

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

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

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

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

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

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

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

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

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

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

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

アプリケーションリンク用に構成されたターゲットフロー情報を取得すること。そして、ターゲットフロー情報に基づいて、アプリケーションリンク内の全アプリケーションの容量拡張に必要なターゲットリソース情報を計算すること。

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

事前設定されたターゲットフローを処理するためにアプリケーションリンク内のすべてのアプリケーションによって必要とされる総リソース情報を推定すること。そして、アプリケーションリンク内のアプリケーションの容量拡張に必要なターゲットリソース情報を取得するために、総リソース情報から占有リソース情報を減算すること。

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

アプリケーションが複数のアプリケーションリンクを伴う場合、複数のアプリケーションリンク内のアプリケーションの容量拡張に必要なターゲットリソース情報の複数の部分を組み合わせることによって、アプリケーションの容量拡張に必要なターゲットリソース情報を決定すること。

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

アプリケーションリンク上のストレステストを実行すること。そして、ストレステストの結果に従ってアプリケーションに割り当てられたリソースを修正すること。

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

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

任意選択で、ストレステストの結果はアプリケーションリンク内のアプリケーションの負荷情報及びフローを含み、中央処理５２２はサーバ５００上で次の動作の命令を実行することもできる。

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

任意選択で、ストレステストの結果は、アプリケーションリンクにおける負荷情報及びアプリケーションのフローを含み、中央処理５２２は、サーバ５００上で以下の動作の命令を実行することもできる。

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

本明細書における様々な実施形態は漸進的に記載されており、各実施形態は他の実施形態のものとは異なる態様に焦点を合わせている。様々な実施形態間の同一又は類似の部分は互いに参照することができる。当業者は、本出願の実施形態の実装が方法、装置、又はコンピュータプログラム製品の提供としてなされ得ることを理解されたい。したがって、本出願の実施形態は、完全にハードウェアとしての実装、完全にソフトウェアとしての実装、又はソフトウェアとハードウェアの組み合わせとしての実装の形態を取り得る。さらに、本願の実施形態は、コンピュータ使用可能プログラムコードを含む１つ以上のコンピュータ使用可能記憶媒体（ディスクストレージ、ＣＤ−ＲＯＭ、光学式ストレージなどを含むがこれらに限定されない）上に具現化されたコンピュータプログラム製品の形を取ることができる。

典型的な設定では、コンピュータデバイスは、１つ以上のプロセッサ（ＣＰＵ）、入出力インターフェース、ネットワークインターフェース、及びメモリを含む。メモリは、揮発性メモリ、ランダムアクセスメモリ（ＲＡＭ）、及び／または、例えば、読み取り専用メモリ（ＲＯＭ）またはフラッシュＲＡＭの不揮発性メモリなどのコンピュータ可読媒体である。メモリはコンピュータ可読媒体の一例である。コンピュータ可読媒体は、揮発性又は不揮発性の種類、取り外し可能又は固定の媒体を含むことができ、それらは任意の方法又は技術を使用して情報の記憶を達成することができる。情報は、コンピュータ可読命令、データ構造、プログラムモジュール、又は他のデータを含み得る。コンピュータ記憶媒体の例としては、相変化メモリ（ＰＲＡＭ）、スタティックランダムアクセスメモリ（ＳＲＡＭ）、ダイナミックランダムアクセスメモリ（ＤＲＡＭ）、他のタイプのランダムアクセスメモリ（ＲＡＭ）、読み取り専用メモリ（ＲＯＭ）、電子的に消去可能なプログラマブル読み取り専用メモリ（ＥＥＰＲＯＭ）、クイックフラッシュメモリ又は他の内部記憶技術、コンパクトディスク読み取り専用メモリ（ＣＤ−ＲＯＭ）、デジタル多用途ディスク（ＤＶＤ）又は他の光学記憶装置、磁気カセットテープ、磁気ディスク記憶装置もしくは他の磁気記憶デバイス、又は任意の他の非伝送媒体が挙げられ、コンピュータデバイスによってアクセスされ得る情報を格納するために使用され得るが、これらに限定されない。本明細書の定義において、コンピュータ可読媒体は、変調データ信号及び搬送波などの一時的媒体を含まない。

本出願の実施形態は、本出願の実施形態による方法、端末装置（システム）、及びコンピュータプログラム製品のフローチャート及び／又はブロック図を参照して説明される。フローチャート及び／又はブロック図における各フロー及び／又はブロック、並びにフローチャート及び／又はブロック図におけるフロー及び／又はブロックの組み合わせは、コンピュータプログラム命令によって実施され得ることを理解されたい。コンピュータプログラム命令は、汎用コンピュータ、特殊用途コンピュータ、組み込みプロセッサ、又は他のプログラム可能なデータ処理端末装置のプロセッサに提供されて機械を産み出し、それによりコンピュータ又は他のプログラム可能データ処理端末装置のプロセッサによる命令の実行を通じて、フローチャートの１つ以上のフロー及び／又はブロック図の１つ以上のブロックで指定された機能を実施するための装置が創出される。

これらのコンピュータプログラム命令はまた、コンピュータ又は他のプログラム可能データ処理端末装置に特定の方法で動作するように指示することができるコンピュータ可読記憶装置に記憶することができ、それにより、コンピュータ可読記憶装置に格納された命令は、命令装置を含む製品を生成する。命令装置は、フローチャートの１つ以上のフロー及び／又はブロック図の１つ以上のブロックで指定された機能を実施する。

これらのコンピュータプログラム命令はまた、コンピュータ実施プロセスを生成するためにコンピュータ又は他のプログラム可能端末装置上で一連の動作ステップが実行されるように、コンピュータ又は他のプログラム可能データ処理端末装置上にロードされ得る。コンピュータ又は他のプログラム可能な端末装置で実行される命令は、フローチャートの１つ以上のフロー及び／又はブロック図の１つ以上のブロックで指定された機能を実施するためのステップを提供する。

本出願の実施形態の好ましい実施形態が説明されたが、基本的な発明の概念が学習されれば、当業者はこれらの実施形態に対してさらなる変更及び修正を加えることができる。したがって、添付の特許請求の範囲は、好ましい実施形態、並びに本出願の実施形態の範囲内に含まれるすべての変更及び修正を含むと解釈されることを意図している。

最後に、第１及び第２のような関係を示す用語は、本明細書中の１つの実体又は動作を別の実体又は動作と区別するために使用されているだけであり、必ずしもこれらの操作又は実体間のそのような関係又は順序の存在を必要とせず暗示もしない。さらに、用語「含む（ｉｎｃｌｕｄｅ）」、「包含する（ｃｏｎｔａｉｎ）」又はそれらの任意の他の変形は非排他的な包含を意味することを意図しており、一連の要素を含むプロセス、方法、物品、又は端末装置にはこれらの要素だけでなく明示的に列挙されていない他の要素も含むこと、又はそのようなプロセス、方法、物品、もしくは端末装置に本来備わっている要素も含む。何らのさらなる限定がない場合、「〜を含む」という文によって定義される要素は、その要素を含むプロセス、方法、物品、又は端末装置を、別の同一の要素をさらに含むことから除外するものではない。

本出願で提供されるアプリケーションリンク拡張方法、アプリケーションリンク拡張装置、及びアプリケーションリンク拡張システムは、上記に詳細に説明されている。本明細書は、本出願の原理及び実装について説明するために特定の例を使用する。上記の実施形態の説明は、本出願の方法及び中核となる概念の理解を容易にするために使用されているに過ぎない。同時に、当業者にとっては、本出願の思想に基づいて特定の実施態様及び適用範囲に変更を加えることができる。要約すると、本明細書の内容は本出願に対する限定として解釈されるべきではない。

Claims (11)

1. アプリケーションリンク拡張システムであって、前記システムは、
   １つ以上のプロセッサと、
   メモリと、
   １つ以上のモジュールと、を備え、
   前記１つ以上のモジュールは、前記メモリに格納され、前記１つ以上のプロセッサによって実行されるように構成され、前記１つ以上のモジュールは、
   サービスシナリオに関連付けられた少なくとも２つのアプリケーションによって形成される経路であるアプリケーションリンクを取得し、
   前記アプリケーションリンク内のすべてのアプリケーションのための容量拡張に必要なターゲットリソースの情報を決定し、
   前記ターゲットリソースの前記情報に従ってそれぞれのリソースを前記アプリケーションに割り当て、
   前記それぞれのリソースに従って前記アプリケーションのインスタンスを生成する、機能を有する
   前記システム。
2. アプリケーションリンク拡張方法であって、
   サービスシナリオに関連付けられた少なくとも２つのアプリケーションによって形成される経路であるアプリケーションリンクを取得することと、
   前記アプリケーションリンク内のすべてのアプリケーションのための容量拡張に必要なターゲットリソース情報を決定することと、
   前記ターゲットリソース情報に従ってそれぞれのリソースを前記アプリケーションに割り当てることと、
   前記それぞれのリソースに従って前記アプリケーションのインスタンスを生成することと、を含む方法。
3. 少なくとも２つのアプリケーションが前記アプリケーションリンク内で順序付けされ、先順序のアプリケーションが、その後の順序とされたアプリケーションによって提供されるサービスを呼び出して、前記先順序の前記アプリケーションによって提供されるサービスを実行する、請求項２に記載の方法。
4. 前記アプリケーションリンク内のすべてのアプリケーションのための容量拡張に必要なターゲットリソースの情報を決定することは、
   前記アプリケーションリンクに設定されているターゲットフロー情報を取得することと、
   前記ターゲットフロー情報に基づいて、前記アプリケーションリンク内のすべての前記アプリケーションの前記容量拡張に必要な前記ターゲットリソース情報を計算することと、
   を含む、請求項２又は３に記載の方法。
5. 前記ターゲットフロー情報に基づいて、前記アプリケーションリンク内のすべての前記アプリケーションの前記容量拡張に必要な前記ターゲットリソース情報を計算することは、
   事前設定されたターゲットフローを処理するために前記アプリケーションリンク内のすべての前記アプリケーションによって必要とされる総リソース情報を推定することと、
   前記アプリケーションリンク内の前記アプリケーションの前記容量拡張に必要な前記ターゲットリソース情報を取得するために、前記総リソース情報から占有リソース情報を減算すること、
   とを含む、請求項４に記載の方法。
6. 前記ターゲットフロー情報に基づいて、前記アプリケーションリンク内のすべての前記アプリケーションの前記容量拡張に必要な前記ターゲットリソース情報を計算することは、
   前記アプリケーションが複数の前記アプリケーションリンクを伴う場合、前記複数のアプリケーションリンク内の前記アプリケーションの容量拡張に必要なターゲットリソース情報の複数の部分を組み合わせることによって、前記アプリケーションの前記容量拡張に必要な前記ターゲットリソース情報を決定することを含む、請求項４に記載の方法。
7. 前記アプリケーションリンクのストレステストを実行することと、
   前記ストレステストの結果に従って、前記アプリケーションに割り当てられた前記リソースの修正を行うことと、
   をさらに含む、請求項２〜６のいずれか一項に記載の方法。
8. 前記アプリケーションリンクの前記ストレステストを実行することは、
   前記アプリケーションが複数のアプリケーションリンクを伴い、ターゲットリソースが、ストレステストを受けるべきアプリケーションリンクの容量拡張に必要なリソース以外のリソースである場合に、前記ターゲットリソースを特定のアプリケーションにロックすることと、
   ロックが成功した場合、前記ストレステストを受ける前記アプリケーションリンクの前記ストレステストを実行することと、
   を含む、請求項７に記載の方法。
9. 前記ストレステストの前記結果は、前記アプリケーションリンク内の前記アプリケーションの負荷情報及びフローを含み、
   前記アプリケーションに割り当てられた前記リソースを前記ストレステストの結果に従って修正することは、
   前記アプリケーションリンク内の前記アプリケーションの前記負荷情報は事前設定されたターゲット負荷情報に達せず、前記フローは事前設定されたターゲットフローに達したときに、前記アプリケーションのリソース冗長性を確認することと、
   前記アプリケーションの前記負荷情報と前記フローに従って、前記アプリケーションリンク配下の前記アプリケーションの隔離及び容量削減処理を行うことと、
   を含む、請求項７に記載の方法。
10. 前記ストレステストの前記結果は、前記アプリケーションリンク内の前記アプリケーションの負荷情報及びフローを含み、
    前記アプリケーションに割り当てられた前記リソースを前記ストレステストの前記結果に従って修正することは、
    前記アプリケーションリンク内の前記アプリケーションの前記負荷の情報が事前に設定されたターゲット負荷情報を超えた場合、前記フローが事前に設定されたターゲットフローに達していても達していなくても、前記アプリケーションの前記リソースが不足していることを確認することと、
    前記アプリケーションの前記負荷情報と前記フローに従って、前記アプリケーションの容量拡張処理を行うことと、
    を含む、請求項７に記載の方法。
11. アプリケーションリンク拡張装置であって、
    アプリケーションリンクを取得するように構成されたアプリケーションリンク取得モジュールであって、前記アプリケーションリンクは、サービスシナリオに関して少なくとも２つの関連付けられたアプリケーションによって形成される経路である前記アプリケーションリンク取得モジュールと、
    前記アプリケーションリンク内のすべてのアプリケーションのための容量拡張に必要なターゲットリソースの情報を決定するように構成されたターゲットリソース情報決定モジュールと、
    それぞれのリソースを前記ターゲットリソースの前記情報に従って前記アプリケーションに割り当てるように構成されたリソース割り当てモジュールと、
    前記アプリケーションのためのインスタンスを前記それぞれのリソースに従って生成するように構成されたインスタンス生成モジュールと、
    を含む装置。