JP2014532247A - 容易にクラウド化可能なアプリケーションの発見型の識別および移行 - Google Patents

Abstract

エンティティの複数の既存のアプリケーションのインフラストラクチャが分析され、それら複数の既存のアプリケーションのインフラストラクチャのうち、既存のレプリケーション・メカニズムを介して個別パーツの複製が可能な既存のサブ構造体を含む、少なくとも一つのインフラストラクチャが識別される。その少なくとも一つのインフラストラクチャが、クラウドへの移行のため選択される。クラウドは、サービス型インフラストラクチャ・クラウドおよびサービス型プラットフォーム・クラウドのうちの少なくとも一つを含む。該少なくとも一つのインフラストラクチャの既存のサブ構造体が、アプリケーションレベルの変化なしにクラウドに移行される。ビジネス・アジリティ・コンポーネントが構築され、該少なくとも一つのインフラストラクチャに充てられるクラウドのリソースの拡大および縮小を制御するように構成される。ビジネス・アジリティ・コンポーネントを用いて、該少なくとも一つのインフラストラクチャに充てられるクラウドのリソースが、拡大、縮小される。

Description

本発明は電気、電子、およびコンピュータ技術に関し、さらに具体的には、クラウド・コンピューティングおよび同類のものに関する。

クラウドは、今日、産業界において関心のある話題である。現在注目されている領域は、新しいアプリケーション・プログラミング・モデルを設計、実装し、それらのモデルによって新規のアプリケーションを構築することである。その例に、Ｇｏｏｇｌｅのマップ・リデュース・モデル（米国カリフォルニア州、マウンテンビューのＧｏｏｇｌｅ Ｉｎｃ．から入手可能）およびＳａｌｅｓｆｏｒｃｅ＿ｄｏｔ＿ｃｏｍ（米国カリフォルニア州、サンフランシスコのＳａｌｅｓｆｏｒｃｅ＿ｄｏｔ＿ｃｏｍ， Ｉｎｃ．（“＿ｄｏｔ＿”はブラウザ実行のコードの含有を避けるための“．”の代替））のウェブ・ベースの標準化カタログ型アプリケーションのモデルがある。

大方の大企業は、膨大な数の既存のＩＴサポートのビジネス・アプリケーションを有する。これらのアプリケーションは、個別の企業がそのビジネスの所与の特定の部分をどのように実施するかについて多くの具体的やり方をエンコードしている。また、これらは、通常、ビジネス・アプリケーションに固有のフォーマットによる相当な量のデータを伴っている。さらに、これらはコードの数百万のラインを包含し得る。

本発明の原理は、容易にクラウド化可能なアプリケーションの発見型の識別および移行のための技法を提供する。

一つの態様において、ある例示的な方法は、エンティティの複数の既存のアプリケーションのインフラストラクチャを分析して、それら複数の既存のアプリケーションのインフラストラクチャのうち、既存のレプリケーション・メカニズムを介して個別パーツの複製が可能な既存のサブ構造体を含む少なくとも一つのインフラストラクチャを識別するステップと、クラウドへの移行のために該少なくとも一つのインフラストラクチャを選択するステップとを含む。このクラウドは、サービス型インフラストラクチャ・クラウドとしておよびサービス型プラットフォーム・クラウドのうちの少なくとも一つを含む。さらなるステップには、アプリケーションレベルでの変化なしに、該少なくとも一つのインフラストラクチャの既存のサブ構造体をクラウドに移行するステップと、該少なくとも一つのインフラストラクチャに充てられたクラウドのリソースの拡大および縮小を制御するよう構成されたビジネス・アジリティ・コンポーネントを構築するステップと、ビジネス・アジリティ・コンポーネントを用いて、該少なくとも一つのインフラストラクチャに充てられたクラウドのリソースを拡大および縮小するステップとが含まれる。

別の態様において、別の例示的な方法は、クラウドへの移行対象であるエンティティの複数の既存のアプリケーションの複数のインフラストラクチャのうちの少なくとも一つのインフラストラクチャの仕様を得るステップを含む。この少なくとも一つのインフラストラクチャは、既存のレプリケーション・メカニズムを介して個別パーツの複製が可能な既存のサブ構造体を含む。追加のステップには、アプリケーション・リソース・マネージャのテンプレート・ストアにおいて、該少なくとも一つのインフラストラクチャに充てられたクラウドのリソースの拡大および縮小のうちの少なくとも一つを遂行するための命令を含む少なくとも一つの一般的テンプレートを識別するステップが含まれる。さらなるステップには、その少なくとも一つの一般的テンプレートに、該少なくとも一つのインフラストラクチャに関連する特定のデータを追加することによって、少なくとも一つの一般的テンプレートの特定のインスタンスをインスタンス生成するステップと、少なくともその特定のインスタンスから、該少なくとも一つのインフラストラクチャに充てられたクラウドのリソースの拡大および縮小のうちの一つを制御するよう構成されたビジネス・アジリティ・コンポーネントを構築するステップとが含まれる。

本明細書で用いる、あるアクションを「推進する」とは、そのアクションを実施すること、アクションを容易化すること、アクションの遂行を助力すること、またはアクションが実施されるようにすることを含む。しかして、限定でなく例として、一つのプロセッサ上で実行される命令が、実施対象のアクションを起こさせるまたは助力するための適切なデータまたはコマンドを送信することにより、遠隔のプロセッサ上で実行される命令によって遂行されるアクションを推進することが可能であろう。誤解を避けるために言えば、動作体（ａｃｔｏｒ）が、アクションを実施すること以外でアクションを推進している場合、そのことにかかわらず、当該アクションは何らかのエンティティまたはエンティティの組み合わせによって実施されている。

本発明またはそのエレメントの一つ以上の実施形態は、示された方法ステップを実施するためのコンピュータ可用プログラム・コードを備えたコンピュータ可読ストレージ媒体を含む、コンピュータ製品の形態に実装することができる。さらに、本発明またはそのエレメントの一つ以上の実施形態は、メモリ、およびメモリに連結され、典型的な方法ステップを実施するよう作動する少なくとも一つのプロセッサを含むシステム（または装置）の形態に実装することも可能である。さらにまた、別の態様において、本発明またはそのエレメントの一つ以上の実施形態は、本明細書に記載の方法ステップの一つ以上を遂行するための手段の形態に実装することができ、この手段には、（ｉ）ハードウェア・モジュール（群）、（ｉｉ）ソフトウェア・モジュール（群）、または（ｉｉｉ）ハードウェア・モジュールとソフトウェア・モジュールとの組み合わせを含めることができ、（ｉ）〜（ｉｉｉ）のいずれも本明細書で述べる特定の手法を実装し、ソフトウェア・モジュールは、コンピュータ可読ストレージ媒体（または複数のかかる媒体）に格納される。

本発明の技法は、多大に有益な技術的効果を提供することができる。例えば、一つ以上の実施形態は、以下の利点の一つ以上を提供することができる。
・ より効率的な管理
・ アプリケーションおよびその根底にあるＩＴインフラストラクチャに対する要件が変更された際の、セットアップ時間のさらなる短縮
・ より高い信頼性
・ リソースの量の増加もしくは低減またはその両方が容易にできるので、十分に活用されていないプロセッサに使用される電力浪費を回避する
・ 前述の利点のより迅速な達成
・ どこにアプリケーション・マネージャをコードすれば無駄がないかの選択の自動化

本発明のこれらのおよび他の特徴および利点は、以下の本発明の例示的な実施形態の詳細な説明を、添付の図面と併せ読めば明らかとなろう。

本発明のある実施形態による、クラウド・コンピューティング・ノードを表す。 本発明のある実施形態による、クラウド・コンピューティング環境を表す。 本発明のある実施形態による、抽象化モデル層を表す。 本発明のある態様による、概観システム・ブロック図である。 本発明のある態様による、詳細システム・ブロック図である。 本発明のある態様による、アプリケーション・リソース・マネージャの例示的なコンポーネントを示す。 本発明のある態様による、例示的なフローチャートを示す。 本発明のある態様による、例示的なアプリケーション「クラウド化」のシナリオを示す。 本発明のある態様による、例示的なソフトウェア・アーキテクチャ図である。

クラウド・コンピューティングは、最小の管理労力またはサービスのプロバイダの介入で、迅速にプロビジョニングしてリリースすることができる、構成可能なコンピューティング・リソース（例えば、ネットワーク、ネットワーク・バンド幅、サーバ、プロセシング、メモリ、ストレージ、アプリケーション、仮想マシン、およびサービス）の共用プールへの、便利且つオンデマンドのネットワーク・アクセスを可能にする、サービス配信のモデルである。このクラウド・モデルには、少なくとも５つの特徴、少なくとも三つのサービス・モデル、および少なくとも４つの展開モデルを含めることができる。

特徴は次のとおりである。

オンデマンド・セルフサービス：クラウド消費者は、必要に応じ、サービスのプロバイダとの間で人間による介入を必要とせず、必要に応じ自動的に、サーバ時間およびネットワーク・ストレージなどのコンピューティング・ケイパビリティを一方的にプロビジョニングすることができる。

広範囲のネットワーク・アクセス：諸ケイパビリティは、ネットワークを通して利用可能で、（例えば、携帯電話、ラップトップ、およびＰＤＡなどの）異機種のシンまたはシック・クライアント・プラットフォームによる使用を推進する標準的なメカニズムを介してアクセスされる。

リソース・プーリング：プロバイダのコンピューティング・リソースはプールされ、マルチテナント型モデルを用い、各種の物理および仮想のリソースを、デマンドに応じて動的に割り当ておよび再割り当てをしながら、複数の消費者にサービスする。消費者は、通常、提供されるリソースの正確な場所に対する制御も知識も有しないが、抽象化のより高レベルでの場所（例えば、国、州、またはデータセンタ）を特定することができるという点で一種の場所非依存性感がある。

迅速な弾力性：諸ケイパビリティは、迅速且つ弾力的に、場合によっては自動的に、プロビジョニングして素早くスケール・アウトし、迅速に解除して素早くスケール・インすることができる。消費者にとって、プロビジョニングに利用可能なこれらのケイパビリティは、多くの場合無制限のように見え、任意のときに任意の量を購買することができる。

サービスの測定：クラウド・システムは、サービスの種類（例えば、ストレージ、プロセシング、バンド幅、およびアクティブなユーザ・アカウントなど）に適切な抽象化の所与のレベルで、計量ケイパビリティを活用し、リソースの使用を自動的に制御し最適化する。リソースの使用量はモニタされ、制御され、報告されて、プロバイダおよび消費者の両方に対し、使用されたサービスの透明性が提供される。

サービス・モデルは次のとおりである。

サービス型ソフトウェア（ＳａａＳ：Ｓｏｆｔｗａｒｅ ａｓ ａ Ｓｅｒｖｉｃｅ）：消費者に提供されるケイパビリティは、クラウド・インフラストラクチャ上で実行されるプロバイダのアプリケーションの使用である。これらのアプリケーションには、さまざまなクライアント・デバイスから、ウェブ・ブラウザ（例えばウェブ・ベースのｅメール）などのシン・クライアント・インターフェースを介してアクセスすることが可能である。消費者は、限られたユーザ固有のアプリケーション構成設定のあり得る例外を除き、ネットワーク、サーバ、オペレーティング・システム、ストレージ、または個別のアプリケーション・ケイパビリティをも含めて、根底にあるクラウド・インフラストラクチャを管理または制御することはない。

サービス型プラットフォーム（ＰａａＳ：Ｐｌａｔｆｏｒｍ ａｓ ａ Ｓｅｒｖｉｃｅ）：消費者に提供されるケイパビリティは、プロバイダがサポートするプログラミング言語およびツールを用いて生成された、消費者生成または取得のアプリケーションのクラウド・インフラストラクチャ上での展開である。消費者は、ネットワーク、サーバ、オペレーティング・システム、またはストレージ含めて、根底にあるクラウド・インフラストラクチャを管理または制御することはないが、展開されるアプリケーション、および場合によっては、環境構成をホストするアプリケーションに対する制御は有する。

サービス型インフラストラクチャ（ＩａａＳ：Ｉｎｆｒａｓｔｒｕｃｔｕｒｅ ａｓ ａ Ｓｅｒｖｉｃｅ）：消費者に提供されるケイパビリティは、消費者が、オペレーティング・システムおよびアプリケーションを含み得る任意のソフトウェアを展開、実行できる、プロセシング、ストレージ、ネットワーク、および他の基本的なコンピューティング・リソースのプロビジョニングである。消費者は、根底にあるクラウド・インフラストラクチャを管理または制御することはないが、オペレーティング・システム、ストレージ、展開されるアプリケーションに対する制御、および場合によっては、ネットワーク形成コンポーネント（例えば、ホストのファイアーウォール）の選択に対する限定された制御を有する。

展開モデルは次のとおりである。

プライベート・クラウド：このクラウド・インフラストラクチャは、ある組織のためだけに運用される。これは、当該組織または第三者によって管理することができ、構内または構外に置くことができる。

コミュニティ・クラウド：このクラウド・インフラストラクチャは、いくつかの組織によって共用され、共通の関心事項（例えば、目標、セキュリティ要件、ポリシー、およびコンプライアンス留意事項）を有する特定のコミュニティをサポートする。これは、これらの組織または第三者によって管理することができ、構内または構外に置くことができる。

パブリック・クラウド：このクラウド・インフラストラクチャは、一般公衆または大きな産業グループが利用できるようにされ、クラウド・サービスを販売する組織によって所有される。

ハイブリッド・クラウド：このクラウド・インフラストラクチャは、二つ以上のクラウド（プライベート、コミュニティ、またはパブリック）の合成体であり、これらは個別のエンティティに留まるが、データおよびアプリケーションの移植性（例えば、クラウド間の負荷バランスのためのクラウド拡張）を可能にする標準的または専有の技術によって一緒に結び付けられている。

クラウド・コンピューティング環境は、無国籍、弱い結合、モジュール性、および意味論的相互運用性に重点を置く、サービス指向型である。クラウド・コンピューティングの中心には、相互接続されたノードのネットワークを含むインフラストラクチャがある。

ここで図１を参照すると、クラウド・コンピューティング・ノードの一例の概略図が示されている。クラウド・コンピューティング・ノード１０は、適切なクラウド・コンピューティング・ノードの単なる一例であって、本明細書に記載する発明の実施形態の使用または機能の範囲に関するいかなる限定をも示唆することは意図されていない。とにかく、クラウド・コンピューティング・ノード１０は、本明細書で述べる一切の機能を実装もしくは実行またはその両方を行うことができる。

クラウド・コンピューティング・ノード１０中には、コンピュータ・システム／サーバ１２があり、これは、数多くの他の汎用または特定用途コンピューティング・システム環境または構成とともに操作可能である。コンピュータ・システム／サーバ１２とともに使用するのに適し得る、周知のコンピューティング・システム、環境、もしくは構成またはこれらの組み合わせの例には、以下に限らないが、パーソナル・コンピュータ・システム、サーバ・コンピュータ・システム、シン・クライアント、シック・クライアント、ハンドヘルドまたはラップトップ・デバイス、マルチプロセッサ・システム、マイクロプロセッサ・ベースのシステム、セット・トップ・ボックス、プログラム可能消費者電子機器、ネットワークＰＣ、ミニコンピュータ・システム、メインフレーム・コンピュータ・システム、および上記のシステムまたはデバイスあるいは同類の任意のものを含む分散型クラウド・コンピューティング環境が含まれる。

コンピュータ・システム／サーバ１２は、コンピュータ・システムによって実行されるプログラム・モジュールなど、コンピュータ・システム実行可能命令との一般的関連で説明することができる。一般に、プログラム・モジュールは、特定のタスクを実行する、または特定の抽象データ型を実装する、ルーチン、プログラム、オブジェクト、コンポーネント、ロジック、データ構造体などを含み得る。コンピュータ・システム／サーバ１２は、分散型クラウド・コンピューティング環境で実施することができ、この環境において、タスクは、通信ネットワークを介してリンクされた遠隔の処理デバイスによって実行される。分散型クラウド・コンピューティング環境において、プログラム・モジュールは、メモリ・ストレージ・デバイスを含む、ローカルおよび遠隔両方のコンピュータ・システムのストレージ媒体中に配置することができる。

図１に示されるように、クラウド・コンピューティング・ノード１０中のコンピュータ・システム／サーバ１２は、汎用コンピューティング・デバイスの形で示されている。コンピュータ・システム／サーバ１２のコンポーネントには、以下に限らないが、一つ以上のプロセッサまたは処理ユニット１６、システム・メモリ２８、およびプロセッサ１６とシステム・メモリ２８との連結を含め、さまざまなシステム・コンポーネントを連結するバス１８を含めることができる。

バス１８は、メモリ・バスまたはメモリ・コントローラ、周辺機器用バス、アクセラレイティッド・グラフィックス・ポート、および各種バス・アーキテクチャの任意のものを用いたプロセッサまたはローカル・バスを含め、いくつかの型のバス構造体の任意の一つ以上を表す。かかるアーキテクチャには、限定ではなく例として、業界標準アーキテクチャ（ＩＳＡ）バス、マイクロ・チャネル・アーキテクチャ（ＭＣＡ）バス、拡張ＩＳＡ（ＥＩＳＡ）バス、ビデオ・エレクトロニクス・スタンダーズ・アソシエーション（ＶＥＳＡ）ローカル・バス、およびペリフェラル・コンポーネント・インターコネクト（ＰＣＩ）バスが含まれる。

コンピュータ・システム／サーバ１２は、一般に、さまざまなコンピュータ・システム可読媒体を含む。かかる媒体は、コンピュータ・システム／サーバ１２がアクセス可能な任意の利用可能な媒体とすることができ、揮発性および不揮発性媒体両方の媒体でリムーバブルおよび非リムーバル媒体を含む。

システム・メモリ２８には、ランダム・アクセス・メモリ（ＲＡＭ）３０もしくはキャッシュ・メモリ３２またはその両方など、揮発性メモリの形で、コンピュータ・システム可読媒体を含めることができる。コンピュータ・システム／サーバ１２には、他のリムーバブル／非リムーバブル、揮発性／不揮発性のコンピュータ・システム・ストレージ媒体をさらに含めることが可能である。単なる例として、非リムーバブル、不揮発性の磁気媒体（図示せず、通常「ハード・ドライブ」と呼ばれる）からの読み取りおよびこれへの書き込みのためストレージ・システム３４を設けることができる。図示はされていないが、リムーバブルで不揮発性の磁気ディスク（例えば「フレキシブル・ディスク」）からの読み取りおよびこれへの書き込みのための磁気ディスク・ドライブ、および、ＣＤ−ＲＯＭ、ＤＶＤ−ＲＯＭまたは他の光媒体など、リムーバブルで不揮発性の光ディスクからの読み取りおよびこれへの書き込みのための光ディスク・ドライブを設けることも可能である。かかる例において、その各々は、一つ以上のデータ媒体インターフェースによってバス１８に接続することが可能である。以下にさらに示し、説明するように、メモリ２８には、本発明の実施形態の機能を遂行するよう構成されたプログラム・モジュールの（例えば、少なくとも一つの）セットを有する少なくとも一つのプログラム製品含めることができる。

限定でなく例として、プログラム・モジュール４２の（少なくとも一つの）セットを有するプログラム／ユーティリティ４０、並びに、オペレーティング・システム、一つ以上のアプリケーション・プログラム、他のプログラム・モジュール、およびプログラム・データをメモリ２８の中に格納することができる。オペレーティング・システム、一つ以上のアプリケーション・プログラム、他のプログラム・モジュール、およびプログラム・データ、の各々またはこれらの何らかの組み合わせには、ネットワーク形成環境の実装を含めることが可能である。プログラム・モジュール４２は、一般に、本明細書で説明する本発明の実施形態の機能もしくは方法またはその両方を遂行する。

また、コンピュータ・システム／サーバ１２は、キーボード、ポインティング・デバイス、ディスプレイ２４など一つ以上の外部デバイス１４、ユーザがコンピュータ・システム／サーバ１２とやり取りできるようにする一つ以上のデバイス、もしくは、コンピュータ・システム／サーバ１２が一つ以上の他のコンピューティング・デバイスと通信できるようにする（例えば、ネットワーク・カード、モデムなど）任意のデバイス、またはこれらの組み合わせと交信することが可能である。かかる交信は、入力／出力（Ｉ／Ｏ）インターフェース２２を介して行うことができる。さらになお、コンピュータ・システム／サーバ１２は、ネットワーク・アダプタ２０を介し、ローカル・エリア・ネットワーク（ＬＡＮ）、一般広域ネットワーク（ＷＡＮ）、もしくは パブリック・ネットワーク（例えば、インターネット）またはこれらの組み合わせなど、一つ以上のネットワークと通信することが可能である。図示のように、ネットワーク・アダプタ２０は、バス１８を介し、コンピュータ・システム／サーバ１２の他のコンポーネントと通信する。なお、図示はされていないが、コンピュータ・システム／サーバ１２と併せ、他のハードウェアもしくはソフトウェアまたはその両方を用いることができよう。上記の例には、以下に限らないが、マイクロコード、デバイス・ドライバ、冗長処理ユニット、外部ディスク・ドライブ・アレイ、ＲＡＩＤシステム、テープ・ドライブ、およびデータ記録保管ストレージ・システムなどが含まれる。

次いで、図２を参照すると、例示的なクラウド・コンピューティング環境５０が示されている。図示のように、クラウド・コンピューティング環境５０は、例えば、携帯情報端末（ＰＤＡ）または携帯電話５４Ａ、デスクトップ・コンピュータ５４Ｂ、ラップトップ・コンピュータ５４Ｃ、もしくは車載コンピュータ・システム５４Ｎまたはこれらの組み合わせなど、クラウド消費者が用いるローカル・コンピューティング・デバイスが通信可能な、一つ以上のクラウド・コンピューティング・ノード１０を含む。ノード１０は相互に通信することが可能である。これらは、前述のプライベート、コミュニティ、パブリック、またはハイブリッド・クラウドあるいはこれらの組み合わせなど、一つ以上のネットワークに、物理的にまたは仮想的にグループ化する（図示せず）ことができる。これは、クラウド・コンピューティング環境５０が、クラウド消費者がローカルのコンピューティング・デバイス上にリソースを維持する必要のない、インフラストラクチャ、プラットフォーム、もしくはソフトウェアまたはこれらの組み合わせをサービスとして提供することを可能にする。当然ながら、図２に示したコンピューティング・デバイス５４Ａ〜Ｎの種類は例示だけを意図したものであり、コンピューティング・ノード１０およびクラウド・コンピューティング環境５０は、任意の種類のネットワークもしくはネットワーク・アドレス可能接続またはその両方を介して、（例えば、ウェブ・ブラウザを使って）任意の種類のコンピュータ化デバイスを用いて通信することが可能である。

次いで、図３を参照すると、（図２の）クラウド・コンピューティング環境５０によって提供される機能的抽象化層のあるセットが示されている。なお、前もって言うが、図３に示されたコンポーネント、層、および機能は、例示のためだけのものであり、本発明の実施形態はこれらに限定されない。図示のように、以下に記載する層および対応する機能が提供される。

ハードウェアおよびソフトウェア層６０は、ハードウェアおよびソフトウェア・コンポーネントを含む。ハードウェア・コンポーネントの例には、一例としてＩＢＭ（登録商標）ｚＳｅｒｉｅｓシステム、一例としてＩＢＭ（登録商標）ｐＳｅｒｉｅｓシステムなどのＲＩＳＣ（Ｒｅｄｕｃｅｄ Ｉｎｓｔｒｕｃｔｉｏｎ Ｓｅｔ Ｃｏｍｐｕｔｅｒ（縮小命令セット・コンピュータ））アーキテクチャ・ベースのサーバ、ＩＢＭ（登録商標）ｘＳｅｒｉｅｓ（登録商標）システム、ＩＢＭ（登録商標）ＢｌａｄｅＣｅｎｔｅｒ（登録商標）システム、ストレージ・デバイス、ネットワークおよびネットワーク形成コンポーネントが含まれる。ソフトウェア・コンポーネントの例には、一例としてＩＢＭ（登録商標）ＷｅｂＳｐｈｅｒｅ（登録商標）アプリケーション・サーバ・ソフトウェアなどのネットワーク・アプリケーション・サーバ・ソフトウェア、および一例としてＩＢＭ（登録商標）ＤＢ２（登録商標）データベース・ソフトウェアなどのデータベース・ソフトウェアが含まれる。（ＩＢＭ、ｚＳｅｒｉｅｓ、ｐＳｅｒｉｅｓ、ｘＳｅｒｉｅｓ、ＢｌａｄｅＣｅｎｔｅｒ、ＷｅｂＳｐｈｅｒｅおよびＤＢ２は、世界中の多くの司法管轄区域で登録されているＩｎｔｅｒｎａｔｉｏｎａｌ Ｂｕｓｉｎｅｓｓ Ｍａｃｈｉｎｅｓ Ｃｏｒｐｏｒａｔｉｏｎの商標である）。

仮想化層６２は、例えば、仮想サーバ、仮想ストレージ、仮想プライベート・ネットワークを含む仮想ネットワーク、仮想アプリケーションおよびオペレーティング・システム、並びに仮想クライアントなどの仮想エンティティを設けることが可能な抽象化層を提供する。

一例において、管理層６４は、下記の機能を提供する。リソース・プロビジョニングは、クラウド・コンピューティング環境内のタスクを実施するのに用いられる、コンピューティング・リソースおよび他のリソースの動的調達を提供する。計量および課金は、リソースがクラウド・コンピューティング環境内で用いられる際のコストの追跡、およびそれらリソースの消費に対する請求書または使用明細書の作成を提供する。一例において、これらのリソースは、アプリケーション・ソフトウェアのライセンスを含み得る。セキュリティは、クラウド消費者およびタスクに対する本人確認、並びにデータおよび他のリソースに対する保護を提供する。ユーザ・ポータルは、消費者およびシステム管理者に対し、クラウド・コンピューティング環境へのアクセスを提供する。サービス品質管理は、要求されるサービス品質が満たされるようにするための、クラウド・コンピューティング・リソースの割り当ておよび管理を提供する。サービス品質保証制度（ＳＬＡ：Ｓｅｒｖｉｃｅ Ｌｅｖｅｌ Ａｇｒｅｅｍｅｎｔ）計画および達成は、ＳＬＡにより今後の必要性が予期されるクラウド・コンピューティング・リソースに対する事前手配および調達を提供する。

作業負荷層６６は、クラウド・コンピューティング環境を使用することが可能な機能の例を提供する。この層から提供され得る作業負荷および機能の例には、マッピングおよびナビゲーション、ソフトウェア開発およびライフサイクル管理、仮想クラスルーム教育配信、データ分析処理、トランザクション処理、モバイル・デスクトップが含まれる。

一つ以上の実施形態は、例えば、ＩａａＳまたはＰａａＳクラウドなどのクラウドにアプリケーション・リソース・マネージャを有利に実装する。

上述のように、サービス型インフラストラクチャ（ＩａａＳ）クラウドおよびサービス型プラットフォーム（ＰａａＳ）クラウドは、イメージの迅速な展開（プロビジョニング）、イメージが使われていない間のそれらの退避、およびイメージに割り当てられたリソースの潜在的にライブまたは準ライブの変更、に対する基本的なケイパビリティを提供する。但し、これは、アプリケーション層（本明細書では作業負荷層６６と互換的に呼称する）に直接に適用はされない。すなわち、アプリケーション層６６では、利用状況を監視し、あるアプリケーションに対するインフラストラクチャをいつどのように拡張または縮小することが可能かを判断するのにまだ人手が必要である。例外は、開発および試験アプリケーションのような、比較的に短時間だけ展開され、その後完全に除去されるアプリケーションである。実際には、これらはＩａａＳおよびＰａａＳクラウド上での実行が現在検討されている最も一般的なアプリケーションである。

ＩａａＳおよびＰａａＳクラウド中の仮想化層６２および管理層６４は、ハードウェアと、場合により基本的ソフトウェアとだけを管理し、作業負荷は管理しないことに留意する。したがって、これまでアプリケーション層の管理は、別個に、通常は人間の介入を伴って行われてきた。

上述のように、サービス型ソフトウェア（ＳａａＳ）クラウドは、アプリケーション層に働きかけるが、これらのクラウドは、ＩＢＭ（登録商標）ＬｏｔｕｓＬｉｖｅ（商標）ソリューション、または米国カリフォルニア州、サンフランシスコのＳａｌｅｓｆｏｒｃｅ＿ｄｏｔ＿ｃｏｍ，Ｉｎｃ．（“＿ｄｏｔ＿”はブラウザ実行のコードの含有を避けるための“．”の代替））から入手可能なものなど、特定のアプリケーションの種類に非常に特化して構築される。

同じく上述のように、Ａｍａｚｏｎ（登録商標） Ｗｅｂ Ｓｅｒｖｉｃｅｓ、ＭｉｃｒｏｓｏｆｔのＡｚｕｒｅ（米国ワシントン州レッドモンドのＭｉｃｒｏｓｏｆｔ Ｃｏｒｐｏｒａｔｉｏｎの商標）、およびＨａｄｏｏｐ（Ａｐａｃｈｅ Ｓｏｆｔｗａｒｅ Ｆｏｕｎｄａｔｉｏｎから入手可能）など、特定の新規なプログラミング・モデルおよび言語でコードしたアプリケーションを必要とするハイレベルのクラウドもある。

一つ以上の実施形態は、変動するまたは単に増加するリソース需要を伴う、標準的で概して変化しないアプリケーションが、ＩａａＳまたはＰａａＳプラットフォーム・ケイパビリティを容易に使用することを有利に可能にする。

グリッドとの関連で、動的インフラストラクチャに対し事前作業がされていることを考慮する必要があるが、グリッドは、イメージをプロビジョニングし管理するためにＩａａＳおよびＰａａＳクラウドが有するのと同じ種類のインターフェースを有せず、したがい、グリッドに対するアプリケーション管理の問題はクラウドに対するものとは異なる。同様に、ＩＢＭのオセアノ・コンピューティング・ユーティリティ・パワープラント・プロジェクトなど、旧タイプの大型の分散型インフラストラクチャ・プロジェクトは、クラウド中にあるような根底となる別個の層６０、６２，６４を用いる作業はしていなかった。

次いで、図４の簡単なシステム概観を参照すると、一つ以上の実施形態は、ＩａａＳまたはＰａａＳクラウドの標準的システム１０およびアプリケーション・コンポーネント４０３に追加された、アプリケーション・リソース・マネージャ・コンポーネント４０１を用いている。このアプリケーション・リソース・マネージャは、アプリケーションの必要に応じてクラウドのリソースを拡大および縮小する。

これらのタスクを遂行するために、アプリケーション・リソース・マネージャは、根底のＩａａＳまたはＰａａＳクラウドの管理インターフェース、すなわち、管理層６４の上部インターフェースと相互交信し、一方、アプリケーションは、クラウドに提供されたイメージおよび他のリソースを使用する。ここで、用語「イメージ」は、ＩａａＳクラウドが提供する純粋なオペレーティング・システムのイメージ、およびＰａａＳクラウドが提供するミドルウェアを含むイメージの両方に対して使われる。図３に関し、ＩａａＳイメージは仮想サーバであり、通常、利用可能且つプロビジョニングが容易なイメージのカタログと、このカタログに対応するイメージのファイルと、プロビジョニングされて実行されている実際のインスタンス・イメージが存在する。管理層６４のリソース・プロビジョニング・コンポーネントは、層６６で潜在的な作業負荷に対するカタログを提供し、イメージのファイルを包含し、仮想化層６２中にインスタンス・イメージ（仮想サーバ）の形成をもたらす。以降、このプロセスの理解を所与として、単に「イメージ」と称することにする。アプリケーションに対しプロビジョニングされたイメージに加えて、標準的なアプリケーション・コンポーネントのコード、データ、機器構成などがある。言い換えれば、クラウドの管理層を介してプロビジョニングされなかった作業負荷の部分（群）がこのアプリケーション・コンポーネントを構成している。

アプリケーション・リソース・マネージャが使用する管理インターフェースには、ＯＳＳの態様（オペレーション・サポート・システム、例えばリソース・プロビジョニング・コンポーネントに対する直接インターフェース）およびＢＳＳの態様（ビジネス・サポート・サービス、例えば、追加のプロビジョニングの際に追加支払いの合意が必要な場合の、コンポーネントの課金のためのインターフェース）を含めることができる。これら全てはユーザ・ポータルを通して取捨選択することは可能であるが、本明細書では、管理インターフェースが、作業負荷層６６からの自動化プログラムが使用するためのＡＰＩ（アプリケーション・プログラミング・インターフェース）、ウェブ・サービス・インターフェースなども包含しているか、もしくは、リソース・プロビジョニングなどの個別コンポーネントに対するインターフェースが作業負荷層６６のプログラムに直接アクセス可能であるか、のいずれかを前提とする。

アプリケーション・リソース・マネージャ４０１は、アプリケーション所有者５１３（アプリケーション要求を予測する権限を持つ人間に対し、その役割を標準ユーザ５１５から区別するため本明細書で用いる名称、図５を参照）からの来るべき需要を知ることができ、あるいは、クラウド管理より得られたレポートから、およびアプリケーションの観察によって、現在の利用状況および傾向を導き出すことが可能である。また、アプリケーション・リソース・マネージャ４０１は、インフラストラクチャの不具合について知り、特定の利用度ターゲットに達するためそれらに対処することもできる。

少なくともいくつかの実施形態において、少なくとも需要が変化した場合、アプリケーション・リソース・マネージャは、イメージをプロビジョニングまたは退避し、あるいは、仮想ストレージまたは仮想ネットワークのバンド幅など、それらのリソース帰属先を変更する。随意的に、該マネージャは、プロビジョニングする際新規のイメージ上に、アプリケーションレベルのソフトウェアもしくはデータまたはその両方をプロビジョニングする。

しかして、一つ以上の実施形態は、クラウド１０、少なくとも一つのアプリケーション・コンポーネント４０３、およびアプリケーション・リソース・マネージャ４０１を含むシステムを提供し、アプリケーション・リソース・マネージャはアプリケーション・リソースの必要性を満たすため、アプリケーション・コンポーネントに対するクラウド・リソースを拡大もしくは縮小またはその両方を行う。

一つ以上の実施形態において、アプリケーション・リソース・マネージャは、ＩａａＳまたはＰａａＳクラウドのサービスを使用する。これらのコンポーネントおよびその相互作用についてのさらなる詳細が図５に示されており、この図はさらに詳細なシステム概観を提示している。

なお、アプリケーション・リソース・マネージャ４０１自体は、クラウド１０上で実行してもしなくてもよい。アプリケーション・ボックス５１１は仮想であり、このことは、アプリケーション・リソース・マネージャが、特定のアプリケーションに属しており、そのアプリケーションの構造を存知しているべきことを示す。

引き続き図５を参照すると、アプリケーション所有者５１３は、アプリケーション管理インターフェース（図３では、これは、作業負荷層６６の上部インターフェース、すなわち、アプリケーション／作業負荷がそれらのユーザとやり取りするインターフェースである）を介してアプリケーション・リソース・マネージャ４０１とやり取りする。アプリケーション・リソース・マネージャ４０１は、アプリケーション５１１に関連付けられ、標準的アプリケーション・ユーザ５１５が使用するアプリケーション・ソフトウェア５１７のセットアップと、アプリケーション・ソフトウェア５１７および対応するイメージ５１９の監視とを遂行する。これらのイメージは、クラウド・ランタイム環境５２１の一部となる。ブロック５２１は、基本的には図３の仮想化層６２（または層６０および６２を併せたもの）と相似であり、一方、クラウド管理プラットフォーム５２３は層６４と相似である。クラウド管理プラットフォーム５２３は、クラウド・ランタイム環境５２１を管理し、該環境は、適切なプロビジョニング・インターフェース（すなわち、直接の、あるいはＢＳＳインターフェースもしくはユーザ・ポータルまたはその両方の介在を経た、リソース・プロビジョニング・コンポーネントへのインターフェース）を介してアプリケーション・リソース・マネージャ４０１と相互作用する。また、クラウド管理プラットフォーム５２３は、アプリケーション・リソース・マネージャ４０１に利用度および不具合のレポートを提供する（これらは、例えば、図３の計量コンポーネントまたはサービス品質管理コンポーネントから来ることになろう）。

一つ以上の実施形態において、４０１などのアプリケーション・リソース・マネージャは、図６に示すように構築することが可能で、これらのコンポーネントは、以下の例示的な機能を提供する。

ポリシー６３１は、長期の目標を設定する。例えば、アプリケーションのサービスレベル目標（これらはクラウドの目標とは異なる、すなわち、これらは層６６に対する目標であり、層６４についてはこの層のサービス品質管理コンポーネントおよびＳＬＡ計画コンポーネントが履行するので、層６４に対するものではない）として与えられることがあるパフォーマンスおよび利用度目標である。パフォーマンス向上の必要性に対する短期予測に関する目標など、アプリケーション所有者からのより短期の目標もポリシーとして表現することもできる。

管理コンポーネント６３３は、ポリシーと、アプリケーションおよびクラウドから知得したことを考慮してアクションを決定する。具体的には、これらのアクションには、クラウドに対する、プロビジョニング、退避、またはプロビジョニング解除の要求、および、例えば、イメージ・リソースの拡大および縮小、異なるサーバへのライブでの移行、またはクラウドからのより高いサービス品質の選択（これには、例えばより良いパフォーマンス保証およびより高い可用性または信頼性の保証を含めることができる）などクラウド管理プラットフォームが可能であればどのような他のアクションも含まれる。

制御コンポーネント６３５は、管理コンポーネントからの抽象要求を、例えば、アプリケーション・プログラミング・インターフェース（ＡＰＩ）またはウェブ・サービス・インターフェースなどを介して、クラウド管理プラットフォームとの具体的な相互作用に変換する。かかる相互作用はマルチステップのシーケンスとすることができ、これには、イメージのサイズを選択し、支払い方法または既存のアカウント番号を選定するなど、ＯＳＳおよびＢＳＳレベルのステップを含めることも可能であろう。

解釈コンポーネント６３７は、制御コンポーネントとは逆に、アプリケーション自体のイメージと、他の仮想リソースおよび全体的クラウドとの両方についての利用状況情報、または不具合レポートなど、クラウドからのレポートを解釈する。

制御コンポーネントおよび解釈コンポーネントを管理コンポーネントから分離する利点は、アプリケーション・リソース・マネージャがいろいろなクラウドに適応するのが容易になることである。図６の例において、アプリケーション・リソース・マネージャは、アプリケーション・コンポーネントと直接相互作用を行うことができるが、但し、これは該マネージャがそのアプリケーションに固有のものだからである。

以下に、このアプリケーション・マネージャ（アプリケーション・リソース・マネージャ）のいくつかの可能な機能について、さらなる非限定の例示的な詳細を提示する。

監視に関し、場合によっては、アプリケーション・マネージャは、当該アプリケーションのユーザ・インタフェースでの監視（この場合、例えば、アプリケーション・サービス品質保証制度（ＳＬＡ）を適用することが可能である）および（５１７，５１９などの）個別のコンポーネント、特に相異なるイメージに展開されているものに対する監視、のいずれかまたは両方によって、アプリケーション・コンポーネント４０３およびそれらの利用状況を監視することができる。また、アプリケーション・マネージャは、クラウド・インターフェースを介して（すなわち、５２３から）そのクラウド・イメージの現在の使用量についての情報を得ることができ、もしくは、クラウド・インターフェースを介してクラウドの現在の全体的使用量についての情報を得ることができ、またはこの両方を行うことができる。このことは、リソースが共用されている場合、より多くのリソースを取得する効果を予測する上で注目されてよい。

さらにまた、監視に関し、場合によっては、アプリケーション・マネージャは、それ自体のイメージの不具合についての情報（５２３から）およびクラウドの全般的信頼性についての情報を得ることが可能で、利用状況に基づいて予測（例えば、月ごとのピークの予測、または需要の全体的なゆっくりした上昇の予測）を用い、今後の需要を見積もること、もしくは、随時に、発見ツール（これについては本明細書の他の部分でさらに説明し、「再発見」と互換的に呼称する）によってアプリケーション構造の妥当性を再確認すること、が可能であり、これらの両方を行うこともできる。アプリケーションのユーザ５１５も変更を加えるためのある程度の権利を有し得るので、これらは、アプリケーションのイメージ５１９およびアプリケーション・ソフトウェア５１７に適用されることになろう。また、発見ツールは、現在のデータベースのサイズなど、アプリケーションレベルのパフォーマンス・パラメータを見出すための助力にもなり得る。

目標に関し、場合によっては、アプリケーション・マネージャは、短期的目標を、絶対値もしくは現在パフォーマンスとの相対値で、アプリケーション所有者から得ることができる。これらの目標は、通常、個別のイメージ上の個別のアプリケーション・ソフトウェア・コンポーネントのパフォーマンスに言及するよりも、むしろ（例えば、トランザクション・スループットまたはエンドユーザへの応答時間など）アプリケーション全体に対して言及する。さらに、アプリケーション・マネージャは、アプリケーション所有者から、例えば、常にある特定のＳＬＡを提供する、または突然の変化に備え常にある所定量の空き高を有するなど、ハイレベルの目標（長期ポリシー）を得ることができ、もしくは、例えば、常に最安価なリソースの全体セットを選択して所望のＳＬＡを提供する、あるいはある特定のコスト限度までだけにおいて常に可能最善のパフォーマンスを提供するなど、コスト目標または限度を得ることができ、または上記の両方を得ることができる。

起こり得る決定に関し、場合によっては、アプリケーション・マネージャは、アプリケーションに割り当てられた個別のクラウド・イメージに割り振られたリソースを拡大もしくは縮小またはその両方を行う決定をすることができる。クラウドに応じ、これは、現在のイメージにおいてまたは対応するアプリケーション・コンポーネント５１７をより大きなイメージ５１９に移行することによって行うことができよう。さらに、アプリケーション・マネージャは、アプリケーションの使用のためのクラウド・イメージ全体をプロビジョニング、削除、または退避する決定をすることができる。また、この場合、該マネージャは、これらの上に適切なアプリケーション・ソフトウェアを展開する必要がある。これに関し、アプリケーション・マネージャは、この目的のため一つ以上のゴールド・イメージ、すなわち、アプリケーションの全ての繰り返し可能な部分を既に包含する休止状態のイメージを保持しておくことができ、もしくは、移行ツールを用いて、現在の全体的アプリケーションの状態に対応するソフトウェア構成を展開することも可能であり、またはその両方を行うこともできる。

さらにまた、起こり得る決定に関し、一部の例では、アプリケーション・マネージャは、クラウドが別途に選択を提供している場合は、追加のストレージもしくはネットワーク・リソースまたはその両方を求める決定をすることができ、その現在のポリシーまたは要求を満たすことができない場合は、ユーザの警告する決定をすること、もしくは、定期ベースまたは要求を受けてアプリケーションレベルの状況をユーザに連絡すること、またはその両方を行うことができる。

判断過程に関し、場合によっては、アプリケーション・マネージャは、最適化解法ツールを用いて判断を下すことができ、あるいは該マネージャが、判断過程コードを直接包含していることも可能である。クラウドが（例えば、ウィークエンドのコスト割引などの）動的課金スキーマを有する場合、該マネージャは、動的クラウド・コストに基づいて判断を下すことができる。動的クラウド・コストを用いるのは、アプリケーションが、タイム・クリティカルでなく、より廉価なリソースで実施可能な側面を包含する場合に特に有用である。

なお、少なくとも一部の例において、ポリシーは、根底のコーディング、すなわち許容可能値または値の範囲を規定するデータ構造体を変える必要なくして、許容可能値および他の変数を規定することができるデータファイルなどの中の、パラメータによって実装することができる。

ポリシー・ブロック６３１に関し、一つ以上の例において、同ポリシー・ブロックは、目標または要求事項、あるいは場合によって、特定の状況でなすべきことを定める。具体的には、該ポリシーには、例えば、アプリケーションレベルのトランザクションに対しどの位の待ち時間が受容可能か、どの位多くの未達成の長時間実行ジョブを抱えてどの位最終期限に近づいてよいのか、あるいは、例えば月末にどのくらいの負荷を予期すべきかなど、アプリケーションレベルに対するポリシー（すなわち、正式の目標または要求事項）を包含させることができる。また、場合によって、該ポリシーには、例えば、どのくらいの空きストレージの量が常に利用可能であるべきか、ある仮想マシン（ＶＭ：ｖｉｒｔｕａｌ ｍａｃｈｉｎｅ）がある持続時間の間、どの位のレベルの使用量を許されるべきか、などといったインフラストラクチャレベルのポリシーを包含させることも可能である。

管理ブロック６３３は、ポリシー６３１から値を読み取り、システム中で生じていることについてのデータ入力を（例えば、アプリケーションレベルでプローブまたは同類のものおよび解釈ブロック６３７から、クラウド・レポートまたはイメージレベルの監視から）得て、ポリシー６３１をアクションに移す。これらの例には、ＶＭを割り当てるべきか、退避すべきか、他のＶＭ上でサービスを開始すべきかどうかの決定、ＶＭのメモリ割り当てもしくはＣＰＵ割り当てまたはその両方を増加すべきかどうかの決定、ストレージを増加もしくは削減またはその両方を行うべきかどうかの決定などが含まれる。

制御ブロック６３５は、各種のアーキテクチャにインターフェースを提供し、例えば、仮にクラウドがｖｍｗａｒｅだけであるとすれば、該制御ブロックはｖｍｒｕｎインターフェースと相互作用してＶＭを制御することになろう。すなわち、制御モジュール６３５は、管理モジュール６３３からの命令を、それらが、クラウド・リソースを管理しているリソース・プロビジョニング・モジュール（図３中の層６４を参照）または同種のモジュールに理解できるように翻訳する。

解釈ブロック６３７に関し、同ブロックは、各種のクラウド・アーキテクチャにインターフェースを提供し、例えば、仮にクラウドがｖｍｗａｒｅだけであるとすれば、ｖｍｗａｒｅインターフェースからのパフォーマンス・レポート、もしくはＶＭ内で実行可能なプローブへの抽象化またはその両方を解釈することになろう。一部の例では、クラウドは、イメージのＣＰＵ利用状況を提示することができる（例えば、図３の層６４中の計量および課金を参照）。管理ブロック６３３は、解釈ブロック６３７に、自分が全てのイメージのＣＰＵ利用状況を必要とすることを通知することができ、ブロック６３７はこれを翻訳して、必要なコマンドを計量および課金ブロックに与え、クラウド固有の結果を共通のフォーマットに翻訳する。場合によっては、ＡＲＭ（アプリケーション・リソース・マネージャ）４０１は、例えば、アプリケーションレベルの待ち時間（すなわち、標準的アプリケーション・ユーザ５１５がどれほど長く結果を待たなければならないか）を監視するため、または長時間実行のアプリケーションの状態について知るために、クラウド・インターフェースに加えて、またはその代わりに、自分の層の上で自分が管理しているイメージへの関連付けを行う。かかる場合、アプリケーション・ソフトウェア５１７が、管理のためのＩＰリスニング・サービスまたはウェブ・インターフェースを提供することが可能で、アプリケーション・マネージャは対応する接続を構築し、対応する管理上のクエリを送信する。

場合によっては、ＡＲＭ４０１は標準的なイメージ上にアカウントを有し、それを使って該標準的なイメージにログインし、適切なコマンドを実行してそのイメージから直接にＣＰＵ利用状況を読み出すことが可能である。一部の例では、アプリケーションは、例えば、直近の１０分間にどれほど多くのトランザクションが実行されたか、といった適切なクエリに応答するようにプログラムすることができる。

誤解を避けるために付言すれば、本文脈で「アプリケーション」とは、例として、ＷＥＢＳＰＨＥＲＥ（登録商標）ソフトウェア内のＪＡＶＡ（登録商標）コード、またはＤＢ２（登録商標）ソフトウェア内の特定のデータベース・スキーマ、あるいは、例えば、ショッピング・カート・アプリケーションまたは旅行報告アプリケーションを提供するのに必要な全コード片など、典型的には前述のコードの種類の組み合わせなどの、最終的な所望の（且つ、クラウドによって提供されていない）機能を遂行するコードをいう。ここでのプローブとは、サーモカップルのような物理的プローブの対語であり、所望の値を得るため他のソフトウェアと通信するソフトウェアの構成片である。

詳細だが非限定の例として、（通常複数の）ウェブ・サーバ、アプリケーション・サーバ、およびデータベースを備えた、３段階のアーキテクチャを考えてみよう。エンドユーザの要求に対する平均待ち時間をある特定の閾値以下に保つことが望まれている。待ち時間は、過負荷されているエレメントのいずれによっても生じ得る。（アプリケーション固有の、例えば、ｈｔｔｐサーバが要求に応答するのにどの位の時間がかかるかなどの）要求に応答するための待ち時間を測定することが望ましい。

この例において、ポリシー・ブロック６３１は、入来する要求に応答するためにどのような待ち時間が利用可能か、およびできれば、システムの定常状態はどうあるべきかを定義する。解釈ブロック６３７は、個別のコンポーネントについての情報を提供するプローブとインターフェース接続する。管理ブロック６３３は、ポリシー・ブロック６３１と、解釈ブロック６３７からのデータと、アプリケーション・ソフトウェアとの直接交信を用いて、待ち時間が長すぎる場合には、場合によって、３階層のどれがボトルネックであり増強を必要としているかを判断して、待ち時間を短縮するために、入来する要求を取り扱うＶＭの数を増やすなどの決定を行う。管理ブロック６３３は、制御ブロック６３５とインターフェース接続し、クラウドに対し、既存のマスタ・テンプレートＶＭをコピーしてそれをオンラインに加えるよう命令し、次いで、その上に適切なデータを配置し、それをアプリケーション中にバインドして負荷を分担できるようにする役割を果たす。

逆に、待ち時間が限度よりはるかに短く、（ポリシー６３１による）標準定常状態の数より多いＶＭがある場合、管理６３３は、制御６３５に対し、ＶＭを徐々にシャットダウンするように命令することができ、例えば、アプリケーションレベルの負荷バランサ・ポリシーを修正することによって、残ったＶＭにより全作業負荷が取り扱われるようにアプリケーションをリセットする役割を果たす。

この非限定の例のさらなる詳細として、ポリシー６３１は、入来する要求に応答するために、どのような待ち時間が利用可能であるべきか、および、システムの定常状態はどうあるべきかを次のように定義する：
ａｖｅｒａｇｅ＿ｌａｔｅｎｃｙ ｛
ｐｅｒｉｏｄ ＝ １ｍｉｎ
ｍａｘ＿ｌａｔｅｎｃｙ ＝ ５００ｍｓ
｝。

これにより、平均待ち時間が１分を超える期間は、５００ｍｓを上回ってはならないというポリシーが設定される。通常、仮に上回るような事態が起こり始めれば、もっと多くのマシンが割り当てられることになる。前述のように、管理モジュール６３３中のロジックは、プローブからデータを得て、ポリシー６３１を調べ、何らかのポリシーが破られている場合には適切なアクションをとる。同じ効果をもたらす命令が、制御ブロック６３５に送信され、そこで命令はこれも前述したように翻訳される。

また、管理ブロック６３３は、各個別アプリケーション・ソフトウェア・コンポーネント５１７に対し、マイクロテストを実行することができる。

このとき、管理ブロック６３３はロジックを随意的に実行し、どの層が待ち時間の原因となっているのか判定しようと試みる。管理ブロックは、各層上でマイクロベンチマークを実行する能力を有し、これは他のどの層にも影響を与えない。例えば、管理ブロックは、ウェブ・サーバから静的ウェブページをフェッチして、そのウェブ・サーバの待ち時間だけを測定することができる。管理ブロックは、データベースをヒットしないアプリケーション・サーバに対し、簡単なクエリおよび簡単なデータベース・クエリを行うことができる。解釈ブロック６３７によって提供されるＶＭレベルの測定値と併せ、これらのクエリによって、管理ブロックは、どのコンポーネントが過負荷になっており、しかしてどのコンポーネントのサイズを増大するか、を正確に把握することが可能になる。なお、この点に関し、測定値だけを用いることもでき、マイクロベンチマークだけを用いることもでき、両方を併せ用いることもできる。さらに、マイクロベンチマークは、例えば、望ましい値を知るためうまく実行されているシステム上で行われた、予備テストに基づいたものとすることが可能である。

例えば、管理ブロック６３３が、ウェブ・サーバのフロント・エンドが過負荷状態にあり、最善の決定はより多くのフロント・エンドを追加することである、と判定した場合、管理ブロックは、制御ブロック６３５に対し、新規のＶＭを割り当てるよう命令し、次いで、そのＶＭに必要な一切の追加ソフトウェアおよびアプリケーション・データを配置し、該ＶＭを当該アプリケーションに組み込むことになる。

仮にクラウドがｖｍｗａｒｅだけであれば、制御ブロック６３５は、ウェブ・サーバのフロント・エンドのゴールド・マスタＶＭを新規のＶＭにコピーすることになろう。次いで制御ブロックは、ｖｍｗａｒｅＡＰＩのＲｅｇｉｓｔｅｒＶｍ（）機能を使って、そのＶＭをＶＭインフラストラクチャに加えることになる。加えたならば、制御ブロック６３５は、ＡＰＩを用いて新規ＶＭに接続し、そのＳｔａｒｔ（）法を使って該マシンを立ち上げることになる。次いで、管理ブロック６３３は、それをフロント・エンド・デューティを担当するマシンのクラスタに加えることになる。簡単な例では、マシンのサイズを増大することができよう。

別の非限定の例において、ストレージの使用量の監視を考えてみよう。ポリシー６３１は、どの位の空きストレージ量が利用可能であるべきか、多すぎる空きストレージはどの位かを定義する。解釈ブロック６３７は、標準的なインターフェース（ｄｕ、ｄｆ、ｑｕｏｔａ、．．．）とインターフェース接続し、空きスペースの量を算定する。管理ブロック６３３はこれらの情報の両方を用いて、十分な空きスペースが利用可能でないか（または過剰なスペースがあるか）どうかを判定する。管理ブロック６３３は、制御ブロック６３５に対し、ポリシーに従ってもっと多くの空きスペースを割り当てる（または減らす）よう命令する。適切なコマンドは、次の形となろう：
“ｉｎｃｒｅａｓｅ−ｄｉｓｋ ＜ｉｍａｇｅ ｉｄ＞ ＜ｄｉｓｋ ｉｄ＞ ＜ｓｉｚｅ＞”。

例えば、ＶＭの負荷の如何によっては、一部のＶＭは一つ以上のサービスを実行することが可能かもしれない。場合によっては、このとき（ＶＭインフラストラクチャからの）ＶＭの負荷を監視すること、および各ＶＭ中にプローブを置いて個別のサービスのリソース（ＣＰＵ、Ｉ／Ｏ）使用量を監視して、各個別サービスがどれほど使用しているかを知ることが可能である。

ポリシー６３１は、ＶＭがどの位の持続的負荷の下で作動可能であるべきか、および、ＶＭ上で実行されている個別のサービスに対してどの位の持続的負荷が許されるべきか、を決定することができる。解釈ブロック６３７は、ＶＭインフラストラクチャ負荷監視機能（全体的なＶＭ負荷）および（各個別サービスに対するＯＳレベルの負荷測定値を監視するため）ＶＭの内部のプローブとインターフェース接続する。管理ブロック６３３は、ある個別ＶＭ上の負荷が高すぎる場合、個々のサービスが別個のＶＭで実行できるようにＶＭを分割する、あるいは負荷が減少した場合、分割されたＶＭを再び一緒に組み合わせる決定を行うことができる。管理ブロックは、制御ブロック６３５とインターフェース接続し、必要に応じ、新規ＶＭを立ち上げまたは既存のＶＭをシャットダウンし、同様に、個別のＶＭ上で実行されているサービスをシャットダウンまたはスタートする。

さらに別の非限定の例において、ＶＭのメモリおよびＣＰＵの使用量を増やすことを考えてみよう。ポリシー６３１は、単一のマシン上で、どの位の持続したメモリおよびＣＰＵ負荷が許されるかを決定する。解釈ブロック６３７は、ＣＰＵ使用量および空きメモリのレポートを取得し、これを管理ブロック６３３に入力する。管理ブロック６３３は、各個のＶＭのＣＰＵおよびメモリ割り当てを増加（または削減）する決定をすることができる。管理ブロックは、制御ブロック６３５にその実施を命令する。制御ブロック６３５は、ＶＭ（必要な場合、一部のＶＭはホットプラグのＣＰＵをサポートしている）をシャットダウンし、それを再構成してＣＰＵおよび割り当てメモリの数を増やし、ＶＭアーキテクチャのインターフェースを用いてそれを再スタートさせることができる（例えば、ｖｍｗａｒｅ上でｖｍｒｕｎを実行し、ＶＭの構成ファイルを手入力またはＡＰＩを介して編集する）。

まださらなる非限定の例において、月当たりの許容ダウンタイムが規定されている場合について考えてみよう。アプリケーション・マネージャは、当該月度の現時点までの合計ダウンタイムを記録することができ、許容限度に近くなったことが判明した場合、該マネージャは制御コンポーネント６３５を用いて、追加のリソースを命じることになる。

以下は、サーバをプロビジョニングしストレージを増加するための、非限定の例示的な実際のコマンドである：
ｐｒｏｖｉｓｉｏｎ ＜ｔｅｍｐｌａｔｅ／ｂａｓｅ ｉｄ ｎａｍｅ＞ ＜ｎｅｗ ｉｄ ｎａｍｅ＞＞
ｉｎｃｒｅａｓｅ−ｄｉｓｋ ＜ｉｄ ｎａｍｅ＞ ＜ｓｉｚｅ＞。

別の態様において、一つ以上の実施形態は、既存のビジネス・アプリケーションを、クラウドスタイル・モデルに、すなわち、ビジネスの必要性に応じてビジネス・アプリケーションを容易に拡大または縮小することが可能なＩＴインフラストラクチャに、移行することに取り組む。この容易性はビジネス・アジリティとも呼ばれ、ビジネス・アプリケーションが実際に使ったリソースに比例するだけのコストまたは料金徴収に関連付けられている。

しかして、一つ以上の実施形態は、容易にクラウド化可能なアプリケーションの発見型の識別および移行を提供する。上述したように、クラウドは、今日、産業界において関心のある話題である。現在の焦点領域は、新しいアプリケーション・プログラミング・モデルを設計、実装し、それらのモデルによって新規のアプリケーションを構築することである。その例に、Ｇｏｏｇｌｅのマップ・リデュース・モデル（米国カリフォルニア州、マウンテンビューのＧｏｏｇｌｅ Ｉｎｃ．から入手可能）およびＳａｌｅｓｆｏｒｃｅ＿ｄｏｔ＿ｃｏｍ（米国カリフォルニア州、サンフランシスコのＳａｌｅｓｆｏｒｃｅ＿ｄｏｔ＿ｃｏｍ， Ｉｎｃ．（“＿ｄｏｔ＿”はブラウザ実行のコードの含有を避けるための“．”の代替））の標準化ウェブ・ベース・カタログ型アプリケーションのモデルがある。

これらの取り組みは新規アプリケーションの範囲には適しているが、大方の大企業は、膨大な数の既存のＩＴサポートのビジネス・アプリケーションを有する。これらのアプリケーションは、特定の企業がそのビジネスの所与の特定部分を実施する多くの具体的やり方をコードしている。また、これらは、通常、ビジネス・アプリケーションに固有のフォーマットによる相当な量のデータを伴っている。さらに、これらはコードの数百万のラインを包含し得る。このため、企業に、かかるアプリケーションを新規のプログラミング・モデルで完全に書き換える余裕があることは非常に稀有である。アプリケーションを、ウェブ・サービスを介して相互作用するモジュールに分解したり、またはデータ・フォーマットを再実装したりするなどの、より控えめな変更でさえも非常にコストがかかり、多くの場合リスクがあるので、大方の企業は自社のアプリケーションのほとんどに対しそれすらやりたがらない。

前述の新規アプリケーション・プログラミング・モデルは、大量の既存のコードがある場合には実用性が限られ得る。有利には、本発明の一つ以上の実施形態は、こういった場合に対処し、たとえ大量の既存コードがある場合にあってもクラウド化を可能にする。

実際には、諸企業は、クラウドの有望性、特にそのビジネス・アジリティを活用することを望んでいる。一つの理由はビジネス・レベルにある。期待外の分野での迅速なビジネス成長は、この機敏性があってこそ可能である。別の理由はコスト削減である。将来の需要が予測または推測できたとしても、インフラストラクチャが相対的に固定的であれば、十分に前もってインフラストラクチャを拡大しなければならず、ピークの後、おそらくはそれを再び削減することにはならないであろう。これは資源の浪費である。

現在または近い将来の一つのオプションは、Ａｍａｚｏｎ Ｅｌａｓｔｉｃ Ｃｏｍｐｕｔｅ Ｃｌｏｕｄ（Ａｍａｚｏｎ ＥＣ２）（Ｒ）ウェブ・サービス、または米国ニューヨーク州アーモンクのＩｎｔｅｒｎａｔｉｏｎａｌ Ｂｕｓｉｎｅｓｓ Ｍａｃｈｉｎｅｓ Ｃｏｒｐｏｒａｔｉｏｎから利用可能なＩＢＭ ＳｍａｒｔＣｌｏｕｄ（登録商標）Ｅｎｔｅｒｐｒｉｓｅなどの、サービス型インフラストラクチャ（ＩａａＳ）クラウドに移行することである。ＩａａＳクラウドは、オペレーティング・システム・イメージの迅速なプロビジョニングを可能にする。これは良好な基盤である。しかしながら、これはまだビジネス・アジリティがない。というのは、これらの空のオペレーティング・システム・イメージを具体的なビジネス・アプリケーションに対し役立つようにするためには、未だに多くの追加作業が必要だからである。いかなる既存のアプリケーションに対しても、これを系統的に行ういかなる現行の方法もないと考えられている。

図７を参照すると、一つ以上の実施形態が、下記のように既存のアプリケーションを処理している。ステップ７０２で、一般的に、後続のステップに対する十分な情報を得るために、インフラストラクチャ発見ツールが実行される。望ましくは、このツールは、例えばＩＢＭ ＲｅｓｅａｒｃｈのＧａｌａｐａｇｏｓツールのように、ビジネス・アプリケーションを追跡することができるべきである（例えば、Ｋ．Ｍａｇｏｕｔｉｓ、Ｍ．Ｄｅｖａｒａｋｏｎｄａ、Ｎ．Ｊｏｕｋｏｖ、およびＮ．Ｇ．Ｖｏｇｌの「Ｇａｌａｐａｇｏｓ：Ｍｏｄｅｌ ｄｒｉｖｅｎ ｄｉｓｃｏｖｅｒｙ ｏｆ ｅｎｄ−ｔｏ−ｅｎｄ ａｐｐｌｉｃａｔｉｏｎ−ｓｔｏｒａｇｅ ｒｅｌａｔｉｏｎｓｈｉｐｓ ｉｎ ｄｉｓｔｒｉｂｕｔｅｄ ｓｙｓｔｅｍｓ」ＩＢＭ ＲＥＳ．＆ＤＥＶ．５２巻ＮＯ．４／５、２００８年７月／９月、３６７−３７７を参照）。

以下の共同譲渡された米国特許公報は、発見もしくは移行またはその両方に関して当業者には興味深いであろう。参照することにより、これらはあらゆる目的に対し全体として全て明示で本明細書に組み込まれる。

20110196984 DISTRIBUTEDPARALLEL DISCOVERY
20110196959 MIDDLEWARE-DRIVENSERVER DISCOVERY
20110191454 DISCOVERINGPHYSICAL SERVER LOCATION BY CORRELATING EXTERNAL AND INTERNAL SERVERINFORMATION
20110107327 ASSISTINGSERVER MIGRATION
20110055816 METHODTO DERIVE SOFTWARE USE AND SOFTWARE DATA OBJECT USE CHARACTERISTICS BY ANALYZINGATTRIBUTES OF RELATED FILES
20110055806 METHODAND SYSTEM TO DISCOVER POSSIBLE PROGRAM VARIABLE VALUES BY CONNECTING PROGRAMVALUE EXTRACTION WITH EXTERNAL DATA SOURCES
20110029946 EFFICIENTEXTRACTION OF SOFTWARE DEPENDENCIES FROM PROGRAM CODE
20100319060 PROCESSAND SYSTEM FOR COMPREHENSIVE IT DISCOVERY WITHOUT CREDENTIALS
20090307743 METHODTO AUTOMATICALLY MAP BUSINESS FUNCTION LEVEL POLICIES TO IT MANAGEMENT POLICIES
20090307174 CONNECTIONOF VALUE NETWORKS WITH INFORMATION TECHNOLOGY INFRASTRUCTURE AND DATA VIA APPLICATIONSAND SUPPORT PERSONNEL
20090150472 METHODFOR NON-DISRUPTIVELY ASSOCIATING APPLICATIONS AND MIDDLEWARE COMPONENTS WITHINFORMATION TECHNOLOGY INFRASTRUCTURE
20110213883 SYSTEMAND METHOD FOR OBJECT MIGRATION USING WAVES

さらなるステップは、ステップ７０４に示すように、個別パーツの複製が可能な既存のサブ構造体に関して各ビジネス・アプリケーションに属するインフラストラクチャを分析し、この型の一つ以上のビジネス・アプリケーションを選択するステップを含む。ステップ７０６で、そのアプリケーションの個別のサブ構造体を、アプリケーションレベルの変化なしに、ＩａａＳクラウドに移行する。ステップ７０８で、下記のタスクの一つ以上、望ましくはその全てを実行できるビジネス・アジリティ・コンポーネントを構築する：
・ ビジネス必要性の変化を理解するために、該コンポーネントは、ビジネス・レベルの需要拡大または縮小についてのインプットを得るか、もしくは、現在のビジネス・パフォーマンスがある特定の上側限度または下側限度に近付いているかどうかを分析する。
・ 上記に応じて、該コンポーネントはサブ構造体を増大または縮小する。このアスペクトを遂行するため、該コンポーネントは、
・ 識別された、サブ構造体を拡大または縮小するための既存のレプリケーション・メカニズム、および
・ 必要なオペレーティング・システム・イメージをプロビジョニング、プロビジョニング解除、または退避／復元するためのＩａａＳクラウド・インフラストラクチャ、
を使用する。

ステップ７１０で、ビジネス・アジリティ・コンポーネントは、ステップ７０８でそのために構築された対象のタスクを実際に遂行する。

一つの適切なビジネス・アジリティ・コンポーネントとして、前述のアプリケーション・リソース・マネージャがある。２０１１年７月１２日出願の、Ｍｕｒｔｈｙ Ｖ．Ｄｅｖａｒａｋｏｎｄａらの共同譲渡された同時係属の米国特許出願第１３／１８０，８５８号、名称「Ａｐｐｌｉｃａｔｉｏｎ Ｒｅｓｏｕｒｃｅ Ｍａｎａｇｅｒ ｏｖｅｒ ａ Ｃｌｏｕｄ」を参照するものとし、当該特許出願は、参照することにより、あらゆる目的に対し全体として、明示で本明細書に組み込まれる。

なお、一つ以上の実施形態は、必ずしも全てのアプリケーションに対処するものではない。未知で複雑な構造の任意のアプリケーションを取り上げ、それに対しビジネス・アジリティを適度な労力で実装することは、現在では実用化できていないと考えられている。代わりに、一つ以上の実施形態は、ビジネス・アジリティの導入が適度なオーバーヘッドですぐにできるビジネス・アプリケーションを識別し、それらのビジネス・アプリケーションの実際の移行を可能にする。このことは、それらが無ければできなかったであろう、近い将来のビジネス・アジリティの向上およびコスト削減をもたらす。

図７の方法を表す一例が図８に示されている。本例において、当初の発見で（ステップ７０２）、ウェブ・サーバ・クラスタ８５３（複数のＩＢＭ（登録商標）ＨＴＴＰ Ｓｅｒｖｅｒ、ＩＨＳとして表されている）、アプリケーション・サーバ・クラスタ８５５（複数のＩＢＭ（登録商標） ＷｅｂＳｐｈｅｒｅ（登録商標）Ａｐｐｌｉｃａｔｉｏｎ Ｓｅｒｖｅｒ、ＷＡＳとして表されている）、およびデータベース・クラスタ８５７（複数のＤＢ２（登録商標）データベースとして表されている）を含む、「ＥｖｅｎｔＸ」と呼ばれるビジネス・アプリケーション８５１が見出された。「クラウド化」に適さない他のアプリケーションは８５０にある。ウェブ・サーバ、アプリケーション・サーバ、およびデータベース、並びにこれらの特定の例は、例示であって限定ではない。

しかして、このビジネス・アプリケーションは、個別パーツの複製が可能なサブ構造体を含むので、ステップ７０４での選定にパスすることになる。これら三つのクラスタの各々は、かかるサブ構造体であり、ＩＨＳ、ＷＡＳ、およびＤＢ２（登録商標）はそのパーツである。

変換の矢印８５９は、ステップ７０２、７０４、７０６、７０８に対応し、主としてステップ７０６、７０８に対応する。一方で、ビジネス・アプリケーション「ＥｖｅｎｔＸ」の既存のサブ構造体は、基本的に変化なく、すなわち、それらのコードおよびミドルウェアレベルの設定は以前のままで、クラウド１０に移行される。（クラウド移行の過程で、他の理由で、バージョン・アップグレードなどの軽微な変更が行われることがあるが、本方法には影響しない。）他方で、ビジネス・アジリティ・コンポーネント８６１が導入される。

ビジネス・アジリティの矢印８６３はステップ７１０に対応する。その後のある時点で、このビジネス・アプリケーションを拡大または縮小する必要がある。図中の例のビジネス・ユーザ８６５は、ＥｖｅｎｔＸの使用が次の月曜日には１０パーセント増加するであろうと（ビジネス・レベルで）予測する。この例において、ビジネス・アジリティ・コンポーネント８６１が、ウェブ・サーバ・クラスタに一つの新しいＩＨＳサーバ８６７を、データベース・クラスタに一つの新しいＤＢ２（登録商標）８６９を追加する決定をしたことが分かる。ビジネス・アジリティ・コンポーネントがこれらの決定のために用いた正確なメカニズムは、いろいろな実施形態に応じて変わり得、何らか追加の手入力での指示さえあり得る。これも上述のように、好適な、だが非限定のアプローチにおいて、前述のアプリケーション・リソース・マネージャ４０１が、ビジネス・アジリティ・コンポーネントとして用いられる。

一つ以上の実施形態において、根底のＩａａＳクラウド１０上に、新規イメージが在ることになるだけでなく、さらにはＩＨＳ８５３およびＤＢ２（登録商標）８５７を伴った新規イメージ８６７、８６９が在ることになるだけでなく、さらになお、ステップ７１０の終わりには、これらのミドルウェア・パーツがそれぞれのクラスタに完全に組み込まれ、増大したビジネス必要性の成就に参加できる状態になっている。

ビジネス・ユーザがかかる使用量の増加を予測することが可能であり得る、ビジネス・アプリケーションＥｖｅｎｔＸの一例には、月曜から開始予定のスポーツ・イベントがある。別の例には、新規マーケティング・キャンペーン、あるいは季節変化により、使用が増加すると予測される販売アプリケーションがある。

本方法は、下層構造体がクラスタに限定されるものでなく、サブ構造体の個別パーツを複製する他の任意の既存の方法を用いることができる。

場合によっては、必要なものだけを増大または縮小するために、任意の時点における個別サブ構造体の実施状況を監視することによって、すなわち、それをビジネス・アジリティ・コンポーネント８６１が追跡するか、または検知できる場合、ステップ７１０を改良することが可能である。また、測定値が無い場合には、例えば、設計フェーズまたはより早期の調整フェーズから、サブ構造体のパフォーマンスをアプリケーションの全体的パフォーマンスにリンクするパフォーマンス予測をすることも可能である。例えば、図８において、ビジネス・アジリティ・コンポーネントは、これらの情報源の一つから、システムの現在状態を所与としてビジネス・レベルのパフォーマンスを１０％増大するためには、一つのＩＨＳおよび一つのＤＢ２（登録商標）の追加が必要だがＷＡＳの追加は必要がないことを知る。

一つ以上の実施形態は、ＩａａＳクラウドの代わりにサービス型プラットフォーム（ＰａａＳ）クラウド上で、小さな変更によって実現することが可能である。例えば、ＰａａＳクラウドは、事前構成されたＩＨＳ、ＷＡＳ、およびＤＢ２（登録商標）コンポーネントを提供することができる。その場合、上記の例は、今度は、ＩａａＳインターフェースを用いて最初に空のＯＳをインストールし、次いでそれらの上にクラスタ・コンポーネントを構成することによって新規イメージを構築するのでなく、むしろ、既にベース・ソフトウェアを含むイメージをプロビジョニングすることによって構築するということを除けば、前述と全く似たように進めることが可能である。ビジネス・アジリティ・コンポーネントは、それでも、これらのイメージ上にウェブページ、コード、またはデータなどのビジネス・アプリケーション固有のエレメントを複製し、それらをビジネス・アプリケーション・フローおよびサブ構造体のあり得る管理ソフトウェアにリンクしなければならない。

しかして、一つ以上の実施形態は、移行によって、ビジネス・レベルでのアジャイル・アプリケーションを構築する。一つ以上の実施形態は、例えば拡張発見ツールを用いて、作業負荷を詳細に分析し、例えば、特定のＩＨＳ−ＷＡＳ−ＤＢ２（登録商標）または類似の作業負荷中で、標準的クラスタ化階層構造を有するものを識別する。一つ以上の実施形態は、追加クラスタ・エレメントの迅速な展開によって、ビジネス・レベルの拡大・収縮性を有利に実現する。場合によっては、ボトルネックを調べ、需要が増えた際にどのクラスタがどの位の拡大を要するかを識別するのに、利用状況データが助力となり得る。

現在、ビジネス・レベルの拡大要求によって、イメージ上にクラスタ・ソフトウェア（例えば、追加のＩＨＳまたはＤＢ２（登録商標）など）を備え、そのクラスタの内部にアプリケーション・ソフトウェア（例えば、ＥｖｅｎｔＸウェブ・サービングなど）を備えた新規イメージがクラウド中に立ち上げられ、さらに、それらイメージがクラスタ・マネージャにリンクされその全てが即時に実行されるべきである、と考えられている。

図９は、本発明のある態様による、例示的なソフトウェア・アーキテクチャ図である。図示のように、拡張発見ツール９０４は、レガシー・システム（ソース環境としても知られる）９０２上で探索を行い、容易にクラウド化可能な少なくとも一つのアプリケーションを識別する。移行ツール９１４は、レガシー・システム９０２および拡張発見ツール９０４からのインプットを取り込み、容易にクラウド化可能なアプリケーションのターゲット環境（クラウド）９１０への移行を遂行する。移行ツール９１４は、随意的にイメージ・ストア９１６を用いる。一方、ビジネス・アジリティ・コンポーネント（ＢＡＣ：ｂｕｓｉｎｅｓｓ ａｇｉｌｉｔｙ ｃｏｍｐｏｎｅｎｔ）コンストラクタ・モジュール９０６（自動コード生成モジュールとしても知られる）は、容易にクラウド化可能なアプリケーションがターゲット環境９１０に移行された後それを管理するための、カスタマイズＢＡＣ９０８を生成する。ＢＡＣコンストラクタ・モジュール９０６は、例えば、ＢＡＣテンプレート９１２を備えるデータ・ストアを利用する。例示的なＡＲＭ４０１（これはＢＡＣの好適であるが非限定の一つの形態である）の説明につき、図４〜６およびそれらの説明文も参照されたい。

ここまでの説明を踏まえ、大まかに言えば、本発明の態様による例示的な方法が、あるエンティティの既存の複数のアプリケーションのインフラストラクチャを分析して、該既存の複数のアプリケーションのインフラストラクチャのうち、既存のレプリケーション・メカニズムを介して個別パーツの複製が可能な既存のサブ構造体を含む少なくとも一つのインフラストラクチャを識別するステップ７０２を含むことは、よく理解できよう。さらなるステップ７０４は、識別されたインフラストラクチャ（群）をクラウドへの移行のために選定するステップを含む。該クラウドは、サービス型インフラストラクチャ・クラウドもしくはサービス型プラットフォーム・クラウドまたはその両方である。まださらなるステップ７０６は、アプリケーションレベルでの変化なしに、識別されたインフラストラクチャ（群）の既存のサブ構造体をクラウドに移行するステップを含む。さらなるステップ７０８は、識別されたインフラストラクチャ（群）に充てられたクラウドの当該リソースの拡大、縮小を制御するよう構成されたビジネス・アジリティ・コンポーネントを構築するステップを含む。ステップ７１０は、ビジネス・アジリティ・コンポーネントを使って、識別されたインフラストラクチャ（群）に充てられたクラウドのリソースを拡大、縮小するステップを含む。上述のように、ビジネス・アジリティ・コンポーネント８６１の一例が、アプリケーション・リソース・マネージャ４０１である。

他の箇所で述べたように、場合によっては、追加のステップは、分析ステップのための情報を得るため、ＩＢＭ Ｒｅｓｅａｒｃｈ ＧＡＬＡＰＡＧＯＳツールなどのインフラストラクチャ発見ツールを実行するステップを含む。

これも他の箇所で述べたように、クラスタは、サブ構造体の非限定の一例である。同様に、ウェブ・サーバ・クラスタ、アプリケーション・サーバ・クラスタおよびデータベース・クラスタも、クラスタの非限定の例である。

場合によっては、構築するステップにおいて構築されたビジネス・アジリティ・コンポーネントは、識別されたインフラストラクチャ（群）に充てられたクラウドの当該リソースの拡大および縮小を駆動することになる、必要性の変化を評価するようさらに構成される。かかる場合の追加ステップには、例えば、需要拡大および需要縮小のうちの少なくとも一つに関するインプットを受け取るか、もしくは需要が上側限度および下側限度のうちの少なくとも一つに近付いているかどうかを分析するか、またはその両方を行うことによって必要性の変化を評価するステップを含めることができる。

上述のように、一部の例では、このクラウドはサービス型インフラストラクチャ・クラウドである。かかる例において、リソースの拡大および縮小は、既存のレプリケーション・メカニズムを使いながら、サービス型インフラストラクチャ・クラウドのインフラストラクチャを用いて、対応するオペレーティング・システムのイメージのプロビジョニング、プロビジョニング解除、退避、もしくは復元またはこれらの組み合わせを遂行して拡大および縮小するステップを含む。

上述のように、一部の例では、このクラウドはサービス型プラットフォーム・クラウドである。かかる例において、リソースの拡大および縮小は、サービス型プラットフォーム・クラウド上に、サブ構造体に関連付けられた基本ソフトウェアを含むイメージをプロビジョニングすることによって拡大するステップを少なくとも含む（基本ソフトウェアは、例えば、ＩＨＳ８５３のクラスタ中のＩＨＳ８５３、ＷＡＳ８５５、およびＤＢ２（登録商標）８５７などである）。ＰａａＳクラウドには、既にＩＨＳを包含するイメージが存在することになるので、拡大には、既にＩＨＳをその中に備えた新規仮想マシンをＡＲＭが要求することが含まれる。ＩａａＳクラウドの場合には、拡大には、ＡＲＭが新規の仮想マシンを要求することが含まれ、ＡＲＭは新規の仮想マシン上にＩＨＳを配置する。

一つ以上の実施形態において、識別されたインフラストラクチャ（群）に充てられたクラウドのこれらリソースの、ビジネス・アジリティ・コンポーネントを使った拡大および縮小は、サブ構造体のレベルで遂行される。一部の例では、サブ構造体のレベルでの拡大および縮小の遂行は、サブ構造体のパフォーマンスの監視に基づいて行われる。すなわち、上述のように、一部の例では、ビジネス・アジリティ・コンポーネント８６１は、任意の時点における個別サブ構造体の実施状況を追跡するか、または検知でき、必要なものだけを増大または縮小できる。

一部の例では、サブ構造体のレベルでの拡大および縮小の遂行は、サブ構造体に対するパフォーマンスの予測に基づいて行われる。すなわち、上述のように、測定値が無い場合、例えば、設計フェーズまたはより早期の調整フェーズから、サブ構造体のパフォーマンスをアプリケーションの全体的パフォーマンスにリンクするパフォーマンス予測をすることも可能である。例えば、図８において、ビジネス・アジリティ・コンポーネントは、これらの情報源の一つから、ビジネス・レベルのパフォーマンスを１０％増大するためには、一つのＩＨＳおよび一つのＤＢ２（登録商標）の追加が必要だがＷＡＳの追加は必要がないことを知る。

別の態様において、別の例示的な方法は、クラウドへの移行対象であるエンティティの複数の既存のアプリケーションの複数のインフラストラクチャのうちの少なくとも一つのインフラストラクチャの仕様を（例えば、おそらくは専門家からのインプットの下で、ツール９０４からモジュール９０６によって）得るステップを含む。この少なくとも一つのインフラストラクチャは、既存のレプリケーション・メカニズムを介して個別パーツの複製が可能な、既存のサブ構造体を含む。さらなるステップには、該少なくとも一つのインフラストラクチャに充てられるクラウドのリソースの拡大および縮小のうちの少なくとも一つを遂行するための命令を含む少なくとも一つの汎用テンプレートをＢＡＣテンプレート・ストア９１２内で（例えばモジュール９０６によって）識別するステップが含まれる。さらなるステップは、少なくとも一つの汎用テンプレートに該少なくとも一つのインフラストラクチャに関連する特定のデータを追加することによって、その少なくとも一つの汎用テンプレートの特定のインスタンスを（例えばモジュール９０６によって）インスタンス生成するステップと、少なくとも特定のインスタンスから、該少なくとも一つのインフラストラクチャに充てられたクラウドのリソースの拡大および縮小のうちの一つを制御するよう構成されたビジネス・アジリティ・コンポーネント９０８（例えば、カスタマイズＡＲＭなどのカスタマイズＢＡＣ）を（例えばモジュール９０６によって）構築するステップと、を含む。

ここに記載した方法を、前述した方法と組み合わせることが可能で、前述の方法において、この構築ステップが、該少なくとも一つのインフラストラクチャに充てられることになるクラウドのリソースの拡大および縮小のうちの少なくとも一つを遂行するための命令を含む、少なくとも一つの汎用テンプレートを、ビジネス・アジリティ・コンポーネントのテンプレート・ストア内で識別するステップと、その少なくとも一つの汎用テンプレートに、該少なくとも一つのインフラストラクチャに関する特定のデータを追加することによって、該少なくとも一つの汎用テンプレートの特定のインスタンスをインスタンス生成するステップと、少なくともその特定のインスタンスからビジネス・アジリティ・コンポーネントを構築するステップと、を含むようにすることができる。

拡張発見ツールに関して、アプリケーション・サーバの非限定の例（例えば、ＷＡＳ８５５）を考えてみよう。一部の例では、市販の発見ツールが、他のＷＡＳノードとは異なる構成を持つ専用の管理ノード（例えば、サーバ）を認識し見付けるように、拡張される。この場合、拡張された発見ツールは、あるサーバにＷＡＳが存在すると判断し、そのサーバの構成を分析することによって、その特定のサーバが管理ノードであると判定する。特定のサーバが管理ノードであると判定されたならば、構成のさらなる分析によって、その管理ノードがクラスタ化構成内の他のサーバを管理しているのを知ることができる。かかるＷＡＳ管理ノードおよびそれが管理するサーバ群は、クラウド化の好適な対象である。

また、ＯＲＡＣＬＥ（登録商標）（または他の）データベース・ソフトウェアの非限定の例を考えてみよう（ＯＲＡＣＬＥは、米国９４０６５カリフォルニア州レッドウッド市のＯｒａｃｌｅ Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｃｏｒｐｏｒａｔｉｏｎの登録商標である）。例えば、ＯＲＡＣＬＥ（登録商標）ソフトウェアを用いるＷＡＳアプリケーション・サーバ８５５があるとする。このＷＡＳサーバはＯＲＡＣＬＥ（登録商標）クラスタと相互作用することになろう。ここで、このＷＡＳサーバは特に管理ノードでなくてもよいが、データベースのクラスタにデータベース接続をとることになり、このクラスタは該サーバの構成ファイルの中に記載されている。このクラスタ設定もまたクラウド化の好適な対象である。

しかして、一つ以上の実施形態において、先の二つの例のように、前述のＧＡＬＡＰＡＧＯＳツールなど既存の発見ツールが、クラスタ設定を識別するため強化される。本明細書の教示を考慮して、当業者は、既存の発見ツールに変更を加え、例えば構成ファイルなどを調べてクラスタ設定および同類のものを識別し、クラウド化の好適な対象を見付けることができよう。

管理ノードを備えるアプリケーション・サーバのクラスタの非限定の例において、二つのサーバと一つの管理ノードが発見されて移行されたと仮定しよう。この例で、現在、第三のサーバを加えてアプリケーション・サーバ・クラスタを増大することが望まれている（ＡＲＭによってこれが判定されたと仮定する）。ＡＲＭは、二つの既存のサーバと同様な第三サーバを得るために、現在のアプリケーション・サーバをコピーする必要があることになる。また管理ノードは、今や二つに代えて三つのサーバがあるという事実を存知するように更新されなければならない。このコピー作業は固定的アクティビティである（ウェブ・サーバはステートレスであると仮定する）。管理ノードは、例えば、ＡＰＩ（アプリケーション・プログラミング・インタフェース）を介して更新可能であろうし、コマンドを送信して第三ウェブ・サーバをそのクラスタに組み込むことができよう。これに代えて、その中で発見が行われた構成ファイルを直接更新することも可能であろう。例えば、該構成ファイルをコピーし、その中に第三ウェブ・サーバの名称をコピーし、それを三つのウェブ・サーバに対する構成ファイルとして書き換え、次いで書き換えられたファイルを管理ノードにライト・バックする。

データベース・アプリケーションに関し、これらデータベースが相互にそのコンテンツを複製し合っていることを、それら自体が知っている必要があり、しかして、相互に複製を行うための、データベースの何らかの構成が存在する。さらに、ＷＡＳノードまたは同類のものはクラスタについて知ることになり、しかして、アプリケーション・サーバも更新される必要があることになる。すなわち、当初は、二つのデータベースの一つが使用可能なことが知られており、今や三つのデータベースの一つが使用できることを示すための更新が必要である。

さきほど説明したようなオペレーション（ＡＰＩの使用もしくは構成ファイルの変更またはその両方）は、自動コード・ジェネレータ（ＢＡＣコンストラクタ９０６）が記述され、変更を生成（すなわち、カスタマイズＡＲＭなどのカスタマイズＢＡＣを生成）できるように、基本的には前もって定められている。例えば、拡張発見ツール９０４は、容易にクラウド化が可能なアプリケーションとして識別される、ＷＡＳクラスタおよびＯＲＡＣＬＥ（登録商標）クラスタを見出すことができる。次いでＣＡＳＥモジュール９０６がＷＡＳクラスタおよびＯＲＡＣＬＥ（登録商標）クラスタに対するＡＲＭ９０８を生成する。ＡＲＭテンプレート９１２は、各カスタマイズＡＲＭに対して必要なさまざまなオペレーションのための汎用コード、例えばＷＡＳクラスタのサイズを増大するための汎用コードのラインなどを含むことになる。これらの汎用コードのラインには、所与のケースで対象となる実際の具体的ＷＡＳクラスタ、ノード（群）などを規定するための、空白、ダミー値（“Ｘ”）などが含まれており、これらには、ＢＡＣコンストラクタ・モジュール９０６によって、正しい値が記入される。しかして、ＢＡＣテンプレート・ストア９１２は、例えば、ＷＡＳクラスタ、ＯＲＡＣＬＥ（登録商標）クラスタなど、対象のアプリケーション（群）のためのリソースの量を増加または削減するための汎用（空白の）テンプレートを含むことになる。ＢＡＣコンストラクタ・モジュール９０６は、しかして、対象の移行のための具体的なマシン、アドレスなど含む、汎用テンプレート９１２の特定のインスタンスをインスタンス生成する。例えば、ＷＡＳ管理ノードがＷＡＳＮＤ１であり、“Ｘ”がＷＡＳ管理ノードを表す、テンプレート中のダミー値である場合、ＢＡＣコンストラクタ・モジュールは、“Ｘ”を“ＷＡＳＮＤ１”に置き換えて、ＷＡＳクラスタのリソース増加コードのインスタンスをインスタンス生成することになる。

一つ以上の実施形態において、エンティティの既存の複数のアプリケーションのインフラストラクチャを分析して、該既存の複数のアプリケーションのインフラストラクチャのうち、既存のレプリケーション・メカニズムを介して個別パーツの複製が可能な既存のサブ構造体を含む少なくとも一つのインフラストラクチャを識別するステップは、レプリケーション管理ノードの構成ファイルからレプリケーション管理ノードを識別することによってサブ構造体を識別するステップ、複製されたサーバの構成を識別するステップ、もしくは複製されたサーバに接続している他のサーバの構成を識別するステップ、またはこれらの組み合わせを含む。

例示的なシステムおよび製造品の詳細
当業者には当然のことながら、本発明の態様は、システム、方法、またはコンピュータ・プログラム製品として具現化することができる。したがって、本発明の態様は、全体がハードウェアの実施形態、全体がソフトウェアの実施形態（ファームウェア、常駐ソフトウェア、マイクロコードなどを含む）、あるいは、ソフトウェア態様およびハードウェア態様を組み合わせた実施形態の形を取ることができ、これらは一般に本明細書では全て「回路」、「モジュール」、または「システム」と称することがある。さらに、本発明の態様は、コンピュータ可読プログラム・コードが中に具現化されている一つ以上のコンピュータ可読媒体（群）中に具現化されたコンピュータ・プログラム製品の形を取ることも可能である。

本発明の一つ以上の実施形態またはそのエレメントは、メモリおよび該メモリに連結されたプロセッサを含み、例示的な方法ステップを実行するよう作動する装置の形態に実装することができる。

一つ以上の実施形態は、汎用コンピュータまたはワークステーションで実行されるソフトウェアを使用することができる。図１を参照すると、かかる実装には、例えば、プロセッサ１６と、メモリ２８と、ディスプレイ２４およびキーボード、ポインティング・デバイスなど外部デバイス（群）１４に対する入力／出力インターフェース２２とを用いることが可能であろう。本明細書で使われる用語「プロセッサ」は、例えば、ＣＰＵ（中央処理装置）もしくは他の形態の処理回路構成またはその両方を含むものなど、任意の処理デバイスを含むように意図されている。さらに用語「プロセッサ」は複数の個別プロセッサを称し得る。用語「メモリ」は、例えば、ＲＡＭ（ランダム・アクセス・メモリ）３０、ＲＯＭ （読み取り専用メモリ）、固定メモリ・デバイス（例えばハード・ドライブ３４）、リムーバブル・メモリ・デバイス（例えばディスケット）、フラッシュ・メモリおよび同類のものなど、プロセッサまたはＣＰＵに関連付けられるメモリを含むように意図されている。さらに、本明細書で使われる語句「入力／出力インターフェース」は、例えば、データを処理ユニットに入力するための一つ以上のメカニズム（例えばマウス）および処理ユニットに関連する結果を提示するための一つ以上のメカニズム（例えばプリンタ）へのインターフェースを意味するように意図されている。プロセッサ１６、メモリ２８、および入力／出力インターフェース２２は、例えばバス１８を介し、データ処理ユニット１２の一部として相互接続することができる。また、コンピュータ・ネットワークとインターフェース接続するため設置が可能な、ネットワーク・カードなどのネットワーク・インターフェース２０、および適切な媒体とインターフェース接続するため設置が可能な、ディスケットまたはＣＤ−ＲＯＭドライブなどの媒体インターフェースへの適切な相互接続を例えばバス１８を介して設けることが可能である。

したがって、本明細書で説明した本発明の手法を実行するための命令またはコードを含むコンピュータ・ソフトウェアは、関連するメモリ・デバイス（例えば、ＲＯＭ、固定またはリムーバブル・メモリ）の一つ以上に格納し、使用の準備が整ったとき、一部または全部を（例えば、ＲＡＭ中に）ロードしてＣＰＵにより実行することができる。かかるソフトウェアは、以下に限らないが、ファームウェア、常駐ソフトウェア、マイクロコードなどを含み得る。

プログラム・コードの格納もしくは実行またはその両方を行うのに適したデータ処理システムには、システム・バス１８を介してメモリ・エレメント２８に直接的または間接的に連結された少なくとも一つのプロセッサ１６が含まれることになる。メモリ・エレメントは、例えば、プログラム・コードの実際の実行の過程で用いられるローカル・メモリと、大容量ストレージと、実行の過程で大容量ストレージからコードを読み出さなければならない回数を低減するために、少なくとも一部のプログラム・コードの一時的ストレージを提供するキャッシュ・メモリ３２とを含み得る。

入力／出力またはＩ／Ｏデバイス（以下に限らないが、キーボード、ディスプレイ、ポインティング・デバイス、および同類のものを含む）は、直接にまたは介在するＩ／Ｏコントローラを通してシステムに連結することができる。

また、ネットワーク・アダプタ２０をシステムに連結して、データ処理システムが、介在するプライベート・ネットワークまたはパブリック・ネットワークを通して、他のデータ処理システムあるいは遠隔のプリンタまたはストレージ・デバイスに連結できるようにすることも可能である。モデム、ケーブル・モデム、およびイーサネット（Ｒ）カードは、現在利用可能な種類のネットワーク・アダプタのほんの数例である。

請求項を含め、本明細書で使用する「サーバ」は、サーバ・プログラムを実行する物理的データ処理システム（例えば、図１に示されたシステム１２）を含む。当然ながら、かかる物理サーバは、ディスプレイおよびキーボードを含むこともあり含まないこともある。

上述のように、本発明の態様は、媒体に具体化されたコンピュータ可読プログラム・コードを有する一つ以上のコンピュータ可読媒体（群）中に具現化されたコンピュータ・プログラム製品の形を取ることもできる。一つ以上のコンピュータ可読媒体（群）の任意の組み合わせを用いることができる。コンピュータ可読媒体は、コンピュータ可読信号媒体、またはコンピュータ可読ストレージ媒体とすることができる。コンピュータ可読ストレージ媒体は、例えば、以下に限らないが、電子的、磁気的、光学的、電磁気的、赤外的、または半導体の、システム、装置、もしくはデバイス、またはこれらの任意の適切な組み合わせであり得る。コンピュータ可読ストレージ媒体のさらに具体的な例（非包括的リスト）には、一つ以上の配線を有する電気接続、携帯型コンピュータ・ディスケット、ハード・ディスク、ランダム・アクセス・メモリ（ＲＡＭ）、読み取り専用メモリ（ＲＯＭ）、消去可能プログラム可能読み取り専用メモリ（ＥＰＲＯＭまたはフラッシュ・メモリ）、光ファイバ、携帯型コンパクト・ディスク読み取り専用メモリ（ＣＤ−ＲＯＭ）、光ストレージ・デバイス、磁気ストレージ・デバイス、または前述の任意の適切な組み合わせが含まれよう。本文書の文脈において、コンピュータ可読ストレージ媒体は、命令実行システム、装置、またはデバイスによって、あるいはこれらに関連させて使用するためのプログラムを、包含または格納できる任意の有形媒体であり得る。

コンピュータ可読信号媒体には、例えばベースバンド中にまたは搬送波の一部として具現化されたコンピュータ可読プログラム・コードを有する、伝播データ信号を含めることができる。かかる伝播信号は、以下に限らないが、電磁気的、光学的、またはこれらの任意の適切な組み合わせを含め、さまざまな形態の任意の形を取ることが可能である。コンピュータ可読信号媒体は、コンピュータ可読ストレージ媒体ではないが、命令実行システム、装置、もしくはデバイスによってまたはこれらに関連させて使用するためのプログラムを通信、伝播、または伝送が可能な任意のコンピュータ可読媒体であり得る。

コンピュータ可読媒体上に具現化されたプログラム・コードは、以下に限らないが、無線、有線、光ファイバ・ケーブル、ＲＦなど、または前述の任意の適した組み合わせを含め、任意の適切な媒体を用いて送信することができる。

本発明の態様のオペレーションを実行するためのコンピュータ・プログラム・コードは、Ｊａｖａ（登録商標）、Ｓｍａｌｌｔａｌｋ（登録商標）、Ｃ＋＋などのオブジェクト指向プログラミング言語、および、“Ｃ”プログラミング言語または類似のプログラミング言語などの従来式手続き型プログラミング言語、あるいはＰｅｒｌなどのスクリプト言語を含め、一つ以上のプログラミング言語の任意の組み合わせで記述することができる。場合によっては、例えばＩＬＯＧ（登録商標） ＣＰＬＥＸ（登録商標）（米国ニューヨーク州アーモンクのＩｎｔｅｒｎａｔｉｏｎａｌ Ｂｕｓｉｎｅｓｓ Ｍａｃｈｉｎｅｓ Ｃｏｒｐｏｒａｔｉｏｎから入手可能な、線形計画法、混合整数計画法、および二次計画法のための高性能な数理計画ソルバ）など、最適化解法をサブコンポーネントとして用いること可能である。一般論として、本プログラム・コードは、スタンドアロン・ソフトウェア・パッケージとしてユーザのコンピュータで専ら実行することも、ユーザのコンピュータで部分的に実行することもでき、一部をユーザのコンピュータで一部を遠隔コンピュータで実行することもでき、あるいは遠隔のコンピュータまたはサーバで専ら実行することもできる。後者の場合は、ローカル・エリア・ネットワーク（ＬＡＮ）または広域ネットワーク（ＷＡＮ）を含む任意の種類のネットワークを介して、遠隔コンピュータをユーザのコンピュータに接続することもでき、あるいは（例えばインターネット・サービス・プロバイダを使いインターネットを介し）外部のコンピュータへの接続を行うこともできる。一つ以上の実施形態において、コードのかなりの部分は、アプリケーション・リソース・マネージャに関連するものであって、これはクラウド中でもまたはその外部でも実行することができる。少なくとも一部の例において、エンドユーザのマシン上にあるよりも（あるとすれば、アプリケーション所有者のエンドユーザ・マシン）、サーバ上にある可能性が高いが、アプリケーション所有者が、これをラップトップなどから実行するのは不可能ではない。拡張発見ツール９０４に関し、その少なくとも一部（例えば、スクリプトまたはエージェント）が主としてレガシー・システム９０２上で実行され、他の部分は専用のサーバ上で実行される。但し、拡張発見ツール全体を、レガシー・システムへの単数または複数の接続を有する専用サーバ上で実行することもできよう。場合によっては、拡張発見ツール全体をレガシー・システム上で実行することも可能であろう。ＢＡＣコンストラクタ・モジュールに関し、同モジュールは、通常、専用のサーバ上で実行される。但し、これを、クラウド中に配置したり、さらにはレガシー・システム上に配置したりことも可能であろう（後者は、外部コンサルタントがＢＡＣコンストラクタ・モジュールを自社の専用サーバで実行したがる可能性が高いので、企業の社内ＩＴ部門が全手順を遂行する場合に、より適切であると考えられる）。

本発明の実施形態による方法、装置（システム）およびコンピュータ・プログラム製品のフローチャート図もしくはブロック図またはその両方を参照しながら、本発明の態様を本明細書で説明してきた。当然のことながら、フローチャート図もしくはブロック図またはその両方の各ブロック、および、フローチャート図もしくはブロック図またはその両方中のブロックの組み合わせは、コンピュータ・プログラム命令によって実装することが可能である。これらのコンピュータ・プログラム命令を、汎用コンピュータ、特殊用途コンピュータ、またはマシンを形成する他のプログラム可能データ処理装置のプロセッサに提供し、そのコンピュータまたは他のプログラム可能データ処理装置のプロセッサを介して実行されるこれらの命令が、フローチャートもしくはブロック図またはその両方のブロックまたはブロック群中に特定されている機能群／動作群を実装するための手段を生成するようにすることができる。

また、これらのコンピュータ・プログラム命令を、コンピュータ、他のプログラム可能データ処理装置、または他のデバイスに対し特定の形で機能するよう命令することができるコンピュータ可読媒体に格納し、そのコンピュータ可読媒体に格納された命令が、フローチャートもしくはブロック図またはその両方のブロックまたはブロック群中に特定されている機能／動作を実装する命令群を包含する製造品を作り出せるようにすることができる。

さらに、コンピュータ・プログラム命令を、コンピュータ、他のプログラム可能データ処理装置、または他のデバイスにロードし、そのコンピュータ上、他のプログラム可能装置上、または他のデバイス上で一連のオペレーション・ステップを実行させて、コンピュータ実装されるプロセスを作り出し、当該コンピュータ上または他のプログラム可能装置上で実行される命令が、フローチャートもしくはブロック図またはその両方のブロックまたはブロック群中に特定されている機能群／動作群を実装するためのプロセスを提供するようにすることも可能である。

図面のフローチャートおよびブロック図は、本発明のさまざまな実施形態によるシステム、方法、およびコンピュータ・プログラム製品から可能となる実装のアーキテクチャ、機能、およびオペレーションを例示している。この点に関し、フローチャートまたはブロック図中の各ブロックは、特定の論理機能（群）を実装するための一つ以上の実行可能命令を含む、モジュール、セグメント、またはコードの部分を表し得る。また、一部の別の実装においては、ブロック中に記載された機能が、図面に記載された順序を外れて行われ得ることに留意すべきである。例えば、連続して示された二つのブロックが、関与する機能によっては、実際にはほぼ同時に実行されることがあり、時にはこれらのブロックが逆の順序で実行されることもあり得る。さらに、ブロック図もしくはフローチャート図またはその両方の各ブロック、およびブロック図もしくはフローチャート図またはその両方中のブロック群の組み合わせは、特定の機能または動作を実施する特殊用途ハードウェア・ベースのシステム、または特殊用途ハードウェアとコンピュータ命令との組み合わせによって実装可能なことにも留意すべきである。

なお、本明細書で説明した方法のいずれにも、コンピュータ可読ストレージ媒体上に具現された個別ソフトウェア・モジュールを包含するシステムを設ける追加ステップを含めることができ、これらのモジュールは、例えば、限定ではなく例として、図６に示したような、ポリシー・サブモジュール、管理サブモジュール、制御サブモジュール、および解釈モジュールなど一つ以上のサブモジュールを有するアプリケーション・リソース・マネージャ・モジュールなど、ブロック図に示しもしくは本明細書で説明したまたはその両方のエレメントのいずれかまたは全てを含み得る。別の態様において、適切な（拡張）発見ツール・モジュール９０４、移行ツール・モジュール９１４、ＢＡＣコンストラクタ・モジュール９０６、およびビジネス・アジリティ・コンポーネント・モジュール（例えば、カスタマイズＡＲＭなどのカスタマイズＢＡＣ９０８）を、図９に示された他のコンポーネント（群）と併せ用いることができよう。次いで、前述したように、プロセッサ１６など一つ以上のハードウェア・プロセッサ上で実行されるシステムの個別ソフトウェア・モジュールもしくはサブモジュールまたはその両方を使い、本方法ステップを遂行または別途に推進することができる。例えば、分析するステップ７０２は、少なくとも一つのハードウェア・プロセッサ上で実行される発見ツール・モジュールによって遂行することができよう。選択ステップ７０４は、少なくとも一つのハードウェア・プロセッサ上で実行される発見ツール・モジュールによって（例えば、専門家または人である他のユーザを助けることによって）推進することが可能であろう。移行ステップ７０６は、少なくとも一つのハードウェア・プロセッサ上で実行される移行ツール・モジュールによって遂行することができよう。構築ステップ７０８は、少なくとも一つのハードウェア・プロセッサ上で実行されるＢＡＣコンストラクタ・モジュールによって遂行することが可能であろう。次いで、少なくとも一つのハードウェア・プロセッサ上で実行されるビジネス・アジリティ・コンポーネント・モジュールの形のビジネス・アジリティ・コンポーネントによって、ステップ７１０が遂行される。ある好適なアプローチにおいて、この少なくとも一つのプロセッサは、少なくとも二つのプロセッサを含み、７１０より前のステップは第一プロセッサによって実行され、次いで、ステップ７１０は、移行プロセスの部分ではなく、新しい環境で実行される実際の移行されたアプリケーションなので、第二プロセッサ上で実行されるビジネス・アジリティ・コンポーネント・モジュールの形のビジネス・アジリティ・コンポーネントによって、ステップ７１０が遂行される。第一もしくは第二プロセッサまたはその両方は、場合によって各々を複数のプロセッサとすることも可能であろう。さらに、コンピュータ・プログラム製品には、個別のソフトウェア・モジュールを有するシステムのプロビジョニングを含め、本明細書で説明した一つ以上の方法ステップを遂行するために実装されるようになされたコードを備えた、コンピュータ可読ストレージ媒体を含めることができる。

なお、いずれの場合においても、本明細書で説明した諸コンポーネントは、例えば、特定用途向け集積回路群（ＡＳＩＣＳ）、機能回路、関連メモリを有する適切にプログラムされた一つ以上の汎用デジタル・コンピュータなど、ハードウェア、ソフトウェア、またはそれらを組み合わせたさまざまな形態に実装することが可能である。本明細書に提示された本発明の教示を考慮して、当業者は、本発明のコンポーネントの他の実装を構想することができよう。

本明細書で使用する用語は、単に特定の実施形態を説明する目的のためのものであり、本発明を限定することは意図されていない。本明細書で用いられる、単数形「ある（“ａ”、“ａｎ”）」、および「該（“ｔｈｅ”）」は、文脈上明確に別途に示されていなければ、複数形も同じように含むことが意図されている。さらに、当然のことながら本明細書で用いられる「含む（“ｃｏｍｐｒｉｓｅ”）」もしくは「含んでいる（“ｃｏｍｐｒｉｓｉｎｇ”）」またはその両方は、述べられた機能、数、ステップ、オペレーション、エレメント、もしくはコンポーネント、またはこれらの組み合わせの存在を特定するが、一つ以上の他の機能、数、ステップ、オペレーション、エレメント、コンポーネント、もしくはこれらの群、または上記の組み合わせの存在または追加を排除するものではない。

添付の請求項中のミーンズ・プラス・ファンクションまたはステップ・プラス・ファンクションの要素全ての、対応する構造、材料、動作および均等物は、具体的に請求された他の請求された要素と組み合わせてその機能を遂行するための、一切の構造、材料または動作を包含することが意図されている。本発明の記述は、例示および説明の目的で提示されたもので、網羅的であることも、または開示した形態に本発明を限定することも意図されていない。当業者には、本発明の範囲および趣旨から逸脱することのない多くの変更および変形が明白であろう。本実施形態は、本発明の原理および実際的な応用を最善に説明し、他の当業者が、意図する特定の用途に適したさまざまな変更を加えたさまざまな実施形態に関して、本発明を理解できるように選択し説明されたものである。

Claims (25)

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. 前記方法は、システムを設けるステップをさらに含み、前記システムは個別ソフトウェア・モジュールを含み、前記個別ソフトウェア・モジュールの各々はコンピュータ可読ストレージ媒体上に具現化され、前記個別ソフトウェア・モジュールが、ビジネス・アジリティ・コンポーネント・コンストラクタ・モジュールおよびアプリケーション・リソース・マネージャ・テンプレート・モジュールを含み、
    前記得るステップ、前記インスタンス生成するステップ、および前記構築するステップは、少なくとも一つのハードウェア・プロセッサ上で実行される前記ビジネス・アジリティ・コンポーネント・コンストラクタ・モジュールによって遂行され、
    前記識別するステップは、前記少なくとも一つのハードウェア・プロセッサ上で実行される前記ビジネス・アジリティ・コンポーネント・コンストラクタ・モジュールが、前記ビジネス・アジリティ・コンポーネント・テンプレート・モジュールにアクセスすることによって遂行される、請求項２４に記載の方法。

Images