(57)【要約】【課題】  変化する作業負荷を既存の方式よりも効率的および効果的に処理する、コンピューティング・システムまたはネットワークに関連付けられたコンピューティング・デプロイメントを管理するための自動化技法または自律型技法を提供すること。【解決手段】  変化する作業負荷レベルに基づいてコンピューティング環境において１つまたは複数のリソースのデプロイメントを管理するための自動化技法または自律的な技法。自動化技法は、コンピューティング環境に関連付けられたデータに基づいて将来の作業負荷レベルを予測する。その後、将来の作業負荷レベルを満たすには現在のリソース・デプロイメントが不十分、十分、または過度のいずれであるかを判定するために、推定が実行される。その後、将来の作業負荷レベルを満たすには現在のリソース・デプロイメントが不十分または過度であると推定された場合、１つまたは複数のアクションが実行される。アクションは、リソース・プロビジョニング、リソース・チューニング、およびアドミッション制御の少なくとも１つとすることができる。
2006520027.tif 000002
【特許請求の範囲】
【請求項１】
変化する作業負荷レベルに基づいてコンピューティング環境において１つまたは複数のリソースのデプロイメントを管理する自動化方法であって、
コンピューティング環境に関連付けられたデータに基づいて将来の作業負荷レベルを予測するステップと、
将来の作業負荷レベルを満たすには現在のリソース・デプロイメントが不十分、十分、および過度のうちの１つであるかどうかを推定するステップと、
将来の作業負荷レベルを満たすには現在のリソース・デプロイメントが不十分および過度のうちの１つであると推定された場合に、１つまたは複数のアクションを実行させるステップと、
を有する、方法。
【請求項２】
１つまたは複数のリソースをモニタリングすることによって、将来の作業負荷レベルを予測するステップによって使用される、コンピューティング環境に関連付けられたデータを取得するステップをさらに有する、請求項１に記載の方法。
【請求項３】
アクションを実行させるステップが、現在のリソース・デプロイメントが不十分であると推定された場合に、将来の作業負荷レベルに対処するように１つまたは複数のリソースを追加させるステップをさらに有する、請求項１に記載の方法。
【請求項４】
アクションを実行させるステップが、現在のリソース・デプロイメントが過度であると推定された場合に、将来の作業負荷レベルに対処するように１つまたは複数のリソースを除去させるステップをさらに有する、請求項１に記載の方法。
【請求項５】
アクションを実行させるステップが、リソースに関連付けられた１つまたは複数の構成パラメータをチューニングさせるステップをさらに有する、請求項１に記載の方法。
【請求項６】
アクションを実行させるステップが、リソース上でアドミッション・キューを操作させるステップをさらに有する、請求項１に記載の方法。
【請求項７】
推定するステップが、１つまたは複数のサービス目標に基づいて、現在のリソース・デプロイメントが不十分、十分、および過度のうちの１つであるかどうかを推定するステップをさらに有する、請求項１に記載の方法。
【請求項８】
将来の作業負荷レベルを予測するステップが、特定の予測範囲に基づいて予測するステップを有する、請求項１に記載の方法。
【請求項９】
変化する作業負荷レベルに基づいてコンピューティング環境において１つまたは複数のリソースのデプロイメントを管理するための装置であって、
メモリと、
メモリに結合され、（ｉ）コンピューティング環境に関連付けられたデータに基づいて将来の作業負荷レベルを予測するように、（ｉｉ）将来の作業負荷レベルを満たすには現在のリソース・デプロイメントが不十分、十分、および過度のうちの１つであるかどうかを推定するように、および（ｉｉｉ）将来の作業負荷レベルを満たすには現在のリソース・デプロイメントが不十分および過度のうちの１つであると推定された場合に、１つまたは複数のアクションを実行させるように、動作可能な少なくとも１つのプロセッサと、
を有する、装置。
【請求項１０】
さらに少なくとも１つのプロセッサが、１つまたは複数のリソースのモニタリングによって、将来の作業負荷レベルを予測するステップによって使用される、コンピューティング環境に関連付けられたデータを取得するように動作可能である、請求項９に記載の装置。
【請求項１１】
アクションを実行させる動作が、現在のリソース・デプロイメントが不十分であると推定された場合に、将来の作業負荷レベルに対処するように１つまたは複数のリソースを追加させることをさらに有する、請求項９に記載の装置。
【請求項１２】
アクションを実行させる動作が、現在のリソース・デプロイメントが過度であると推定された場合に、将来の作業負荷レベルに対処するように１つまたは複数のリソースを除去させることをさらに有する、請求項９に記載の装置。
【請求項１３】
アクションを実行させる動作が、リソースに関連付けられた１つまたは複数の構成パラメータをチューニングさせることをさらに有する、請求項９に記載の装置。
【請求項１４】
アクションを実行させる動作が、リソース上でアドミッション・キューを操作させることをさらに有する、請求項９に記載の装置。
【請求項１５】
推定する動作が、１つまたは複数のサービス目標に基づいて、現在のリソース・デプロイメントが不十分、十分、および過度のうちの１つであるかどうかを推定することをさらに有する、請求項９に記載の装置。
【請求項１６】
前記将来の作業負荷レベルを推定する動作が、特定の予測期間に基づいて予測することを有する、請求項９に記載の装置。
【請求項１７】
変化する作業負荷レベルに基づいてコンピューティング環境において１つまたは複数のリソースのデプロイメントを管理するための製品であって、１つまたは複数のプログラムを含む機械可読媒体を有し、プログラムは実行された場合に、
コンピューティング環境に関連付けられたデータに基づいて将来の作業負荷レベルを予測するステップと、
将来の作業負荷レベルを満たすには現在のリソース・デプロイメントが不十分、十分、および過度のうちの１つであるかどうかを推定するステップと、
将来の作業負荷レベルを満たすには現在のリソース・デプロイメントが不十分および過度のうちの１つであると推定された場合に、１つまたは複数のアクションを実行させるステップと、
をインプリメントする、製品。
【請求項１８】
１つまたは複数のリソースのモニタリングによって、将来の作業負荷レベルを予測するステップによって使用される、コンピューティング環境に関連付けられたデータを取得するステップをさらに有する、請求項１７に記載の製品。
【請求項１９】
アクションを実行させるステップが、現在のリソース・デプロイメントが不十分であると推定された場合に、将来の作業負荷レベルに対処するように１つまたは複数のリソースを追加させるステップをさらに有する、請求項１７に記載の製品。
【請求項２０】
アクションを実行させるステップが、現在のリソース・デプロイメントが過度であると推定された場合に、将来の作業負荷レベルに対処するように１つまたは複数のリソースを除去させるステップをさらに有する、請求項１７に記載の製品。
【請求項２１】
アクションを実行させるステップが、リソースに関連付けられた１つまたは複数の構成パラメータをチューニングさせるステップをさらに有する、請求項１７に記載の製品。
【請求項２２】
アクションを実行させるステップが、リソース上でアドミッション・キューを操作させるステップをさらに有する、請求項１７に記載の製品。
【請求項２３】
推定するステップが、１つまたは複数のサービス目標に基づいて、現在のリソース・デプロイメントが不十分、十分、および過度のうちの１つであるかどうかを推定するステップをさらに有する、請求項１７に記載の製品。
【請求項２４】
将来の作業負荷レベルを予測するステップが、特定の予測範囲に基づいて予測するステップを有する、請求項１７に記載の製品。
【請求項２５】
変化する作業負荷レベルに基づいてコンピューティング環境において１つまたは複数のリソースのデプロイメントを管理するための自動化システムであって、
（ｉ）コンピューティング環境に関連付けられたデータに基づいて将来の作業負荷レベルを予測するように、（ｉｉ）将来の作業負荷レベルを満たすには現在のリソース・デプロイメントが不十分、十分、および過度のうちの１つであるかどうかを推定するように、動作可能なソリューション・マネージャと、
ソリューション・マネージャに結合され、（ｉ）コンピューティング環境に関連付けられたデータをソリューション・マネージャに提供するように、および（ｉｉ）ソリューション・マネージャによって、将来の作業負荷レベルを満たすには現在のリソース・デプロイメントが不十分および過度のうちの１つであると推定された場合に、ソリューション・マネージャに応答して１つまたは複数のアクションを実行するように、動作可能なデプロイメント・マネージャと、
を有する、システム。
【請求項２６】
１つまたは複数のリソースがアプリケーションの実行をインプリメントするようにデプロイ可能である、請求項２５に記載のシステム。
【請求項２７】
ソリューション・マネージャおよびデプロイメント・マネージャのうちの少なくとも１つが自律的に動作する、請求項２５に記載のシステム。
【請求項２８】
１つまたは複数のアクションが、リソース・プロビジョニング、リソース・チューニング、およびアドミッション管理のうちの少なくとも１つを有する、請求項２５に記載のシステム。
【請求項２９】
ソリューション・マネージャが、１つまたは複数のサービス目標に基づいて、現在のリソース・デプロイメントが不十分、十分、および過度のうちの１つであるかどうかを推定する、請求項２５に記載のシステム。
【請求項３０】
アプリケーションの実行に関連付けられた１つまたは複数のサービス目標を満たすことを保証するように試みる方法であって、
１つまたは複数のサービス目標に従ってアプリケーションをホストするようにサービス・プロバイダと契約するステップと、
変化する作業負荷レベルに基づいて、アプリケーションを実行するために使用されるコンピューティング環境において１つまたは複数のリソースのデプロイメントを管理するための自動化システムをインプリメントするようにサービス・プロバイダと契約するステップと、
を有し、自動化システムが、（ｉ）コンピューティング環境に関連付けられたデータに基づいて将来の作業負荷レベルを予測するように、（ｉｉ）将来の作業負荷レベルを満たすには現在のリソース・デプロイメントが不十分、十分、および過度のうちの１つであるかどうかを、１つまたは複数のサービス目標に基づいて推定するように、および（ｉｉｉ）将来の作業負荷レベルを満たすには現在のリソース・デプロイメントが不十分および過度のうちの１つであると推定された場合に、１つまたは複数のアクションを実行させるように、動作可能である、方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、一般にコンピューティング・システムまたはネットワークの管理に関し、とりわけ、作業負荷が変化する場合にこうしたシステムまたはネットワークに関連付けられたコンピューティング・デプロイメント（ｄｅｐｌｏｙｍｅｎｔ）を管理するための技法に関する。
【背景技術】
【０００２】
関連出願の相互参照
本出願は、同時出願の整理番号ＹＯＲ９２００３００５０ＵＳ１で特定される「適応的およびロバストな予測を実行するための方法および装置（Method and Apparatus forPerforming Adaptive and Robust Prediction）」と題する米国特許出願に関連し、その開示が参照により本明細書に組み込まれている。
【０００３】
コンピューティング・システムまたはネットワークにおいてコンピューティング・リソースのデプロイメントを管理する際の重要な課題は、変化するトラフィックに対処することである。たとえば、ワールド・ワイド・ウェブまたはインターネットに関連付けられたコンピューティング・システムまたはネットワークでは、ウェブ・サイトに関連して実行される１つまたは複数のアプリケーションの利用に関してウェブ・サイトにたとえ大きな負荷がかかった場合であっても、（応答時間が遅いことにより）エンドユーザの体験に障害が生じないことを保証するために、ウェブ・サイトをサポートしている十分なコンピューティング・リソース（たとえばウェブ・サーバ、アプリケーション・サーバ、トランザクション／データベース・サーバ）を有することが重要である。周知のように、一般にアプリケーションとは、たとえばサプライ・チェーン・マネージメントのように、１つまたは複数の特定の機能を実行するように設計された１つまたは複数のコンピュータ・プログラムのことである。
【０００４】
特定のアプリケーションをサポートしているデプロイメントをサイズ変更するための方法の１つが、予想される作業負荷トラフィック・パターンを推定し、キャパシティ・プランニング手法を使用してピーク時の予想負荷に対処するのに十分なリソースを使用することである。ほとんどの作業負荷トラフィックが毎日、毎週といった明白なパターンで大きく変化するため、この静的な配置構成では結果としてかなりのリソースを十分に活用していない可能性がある。
【０００５】
上記手法のさらなる改良は、予想されるトラフィックの長期予測（たとえば１日から数日の予測）に基づいて、スケジュールまたは計画されたソースの再割り振りを実行することである。この手法は、長期予測の正確さ（たとえば販売促進の成功を少なく見積もり過ぎるかもしれない）に依拠しているためにしばしば不適切であり、さらに予期せぬ出来事（たとえば２００１年９月１１日にＣＮＮのウェブ・サイトで経験したような、ニュース・ウェブ・サイトへのトラフィック・サージ）に見舞われる場合もある。
【０００６】
既存のコンピューティング・デプロイメント手法の他の主要な欠点は、一般に、リソースの不均衡を調整するために、たとえば熟練オペレータによる何らかの形の手操作の介入が必要なことである。
【発明の開示】
【発明が解決しようとする課題】
【０００７】
したがって、変化する作業負荷を既存の方式よりも効率的および効果的に処理する、コンピューティング・システムまたはネットワークに関連付けられたコンピューティング・デプロイメントを管理するための自動化技法または自律型技法を有することが望ましい。
【課題を解決するための手段】
【０００８】
本発明は、変化する作業負荷を既存の方式よりも効率的および効果的に処理する、コンピューティング・システムまたはネットワークに関連付けられたコンピューティング・デプロイメントを管理するための自動化技法または自律型技法を提供する。
【０００９】
本発明の一態様では、変化する作業負荷レベルに基づいて、コンピューティング環境内の１つまたは複数のリソースを管理するための技法が提供される。この技法は、コンピューティング環境に関連付けられたデータに基づいた将来の作業負荷レベルの予測を含むことができる。その後、現在のリソース・デプロイメントが将来の作業負荷レベルを満たすのに不十分、十分、または過度のいずれであるかを判定するための推定が実行される。その後、現在のリソース・デプロイメントが将来の作業負荷レベルを満たすのに不十分または過度であると推定された場合、１つまたは複数のアクションが実行されることになる。アクションは、リソース・プロビジョニング、リソース・チューニング、およびアドミッション制御の少なくとも１つを含むことができる。
【００１０】
有利なことに、本発明は、作業負荷が変化するにもかかわらずコンピューティング・デプロイメントに対して応答時間などのサービス・レベル目標を事前に維持することができる。とりわけ本発明が採用する技法は、自動的または自律的にコンピューティング・デプロイメントを変更することによって、予測のつかない作業負荷に対処する際に効果的である。
【００１１】
さらに有利なことに、本発明は、サービス・プロバイダがホストするアプリケーションの実行に関連付けられた１つまたは複数のサービス目標を、アプリケーション所有者が確実に満たすように試みるための方法も提供する。これは、アプリケーション所有者が、アプリケーションをホストすることおよび本明細書に記載されているようなコンピューティング・デプロイメント管理システムを実装することを、サービス・プロバイダと契約することによって達成可能である。
【００１２】
本発明のこれらおよび他の目的、特徴、および利点は、それらの例示的実施形態についての以下の詳細な説明を添付の図面と共に読むことによって明らかとなろう。
【発明を実施するための最良の形態】
【００１３】
以下では、本発明について、例示的なウェブベースのコンピューティング・ネットワーク環境との関連において説明する。すなわち、管理されるコンピューティング・リソース（たとえばアプリケーション・サーバ、データベース接続、入出力パスなど）が、１つまたは複数のウェブ・サイトに関連付けられる。しかしながら、本発明はこうした特定の環境に限定されるものでないことを理解されよう。むしろ本発明はより一般的に、作業負荷が変化するにもかかわらずリソース・デプロイメントを自動的または自律的に管理および算出することが望ましい、任意のコンピューティング環境に適用可能である。
【００１４】
周知のように、「オートノミック」コンピューティングとは、一般に最低限の人間の介入でコンピューティング・システムを自己管理させる包括的および全体的な手法のことであり、たとえばその開示が参照により本明細書に組み込まれた、Ｐ．Ｈｏｒｎ著「オートノミック・コンピューティング：情報技術の情勢に関するＩＢＭの展望（Autonomic Computing:IBM’s Perspective on the State of Information Technology）」２００１年１０月、ＩＢＭ  Ｒｅｓｅａｒｃｈを参照されたい。この用語は、意識の覚醒または関与なしに重要な機能を制御する身体の自律神経系から派生したものである。とりわけ、オートノミック・コンピューティングの目標の１つは、典型的には熟練したオペレータまたは管理者が実施するタスクの一部またはすべてを自動化することである。したがって本明細書に提示された発明の原理からわかるように、本発明のコンピューティング・デプロイメント技法は自動的または自律的に動作することができる。
【００１５】
初めに図１を参照すると、本発明の一実施形態に従ったコンピューティング・デプロイメント管理システムおよびこうしたシステムが動作可能な全体的環境を示すブロック図である。図に示されるように、環境１００はコンピューティング・デプロイメント管理システム１１０を有する。コンピューティング・デプロイメント管理システム１１０は、ソリューション・マネージャ１２０およびデプロイメント・マネージャ１３０を有する。ソリューション・マネージャ１２０は、制御論理エンジン１２２、予測モジュール１２４、パフォーマンス推定モジュール１２６、アドミッション制御モジュール１２８、およびチューニング・モジュール１２９を有する。デプロイメント・マネージャ１３０は、モニタリング・モジュール１３２、プロビジョニング・モジュール１３４、チューニング・インターフェース・モジュール１３６、およびスロットリング・インターフェース・モジュール１３８を有する。
【００１６】
さらに図に示されるように、環境１００はアプリケーション・レベル１４０を有する。アプリケーション・レベルは、リソース・プール１４２（たとえばアプリケーション・サーバを有するリソース・プールＡ）、リソース・プール１４４（たとえばデータベース接続を有するリソース・プールＢ）、およびリソース・プール１４６（たとえば入出力パスを有するリソース・プールＣ）を有する。
【００１７】
したがって、図１に示されるアーキテクチャは、（ａ）アプリケーションがデプロイ可能なアプリケーション・レベル（１４０として表示）および関連リソース、（ｂ）リソースの接続および制御を提供するデプロイ管理レベル（１３０として表示）、ならびに（ｃ）サービス・レベル目標の維持に必要なアクションを開始するために必要なリアルタイムの分析およびプランニングを実行するソリューション管理レベル（１２０として表示）という、３つのレベルに編成される。これら３つのレベルについて、以下でより詳細に論じる。
【００１８】
アプリケーション・デプロイメントは、通常、たとえばＨＴＴＰ（ハイパーテキスト転送プロトコル）サーバ、アプリケーション・サーバ、データベース・サーバ、ストレージ、接続、Ｉ／Ｏパスなどの、様々なタイプのリソースが混在していることが必要である。典型的なコンピューティング・デプロイメント（たとえばデータ・センタ）では、これらのリソースは管理下プールから入手することができる。図１には、３つのこうした管理下リソース・プール１４２、１４４、および１４６が示されている。アプリケーションに応じて、予想される作業負荷を満たすのに十分な所定数の各リソースが、管理下リソース・プールで使用するために入手可能であることを理解されよう。さらに、図１および上記ではある一定のリソースについて言及しているが、本発明がいかなる特定のリソースにも限定されるものでないことも理解されよう。むしろ本発明は、ハードウェア・コンポーネント、ソフトウェア・コンポーネント、およびそれらの組合せを含むがこれらに限定されることのない、任意およびすべてのタイプのリソースを管理することができる。リソースは、アプリケーションそれ自体またはその一部とすることも可能であることを理解されよう。
【００１９】
デプロイメント・マネージャ１３０は、（たとえば、応答時間プローブなどのリソース依存型センサ、Ｕｎｉｘなどのオペレーティング・システムからのｖｍｓｔａｔデータ、ＩＢＭコーポレーションのＤＢ２などのデータベースからのスナップショット・データ、またはＣｏｍｍｏｎ  Ｉｎｆｏｒｍａｔｉｏｎ  Ｍｏｄｅｌを使用してインプリメントされるカスタム・インターフェースまたは標準インターフェースを介して）測定／構成データをモニタリングするため、および（たとえば、ＩＢＭコーポレーションのＷｅｂＳｐｈｅｒｅ  Ａｐｐｌｉｃａｔｉｏｎ  Ｓｅｒｖｅｒなどのアプリケーション・サーバ上のノード・エージェントなどのリソース依存型エフェクチュエータ、ＩＢＭコーポレーションのＤＢ２などのデータベースで構成パラメータを変更するためのアプリケーション・プログラミング・インターフェースを介して）リソースを制御するために、アプリケーション・レベル１４０の関連リソースとインターフェースする。したがってデプロイメント・マネージャは、例を挙げると、１台のハードウェアに対して、（ｉ）たとえばＷｉｎｄｏｗｓまたはＬｉｎｕｘのインストールが可能なｘ８６システムなどの、オペレーティング・システムがインストールされていないコンピュータ上にオペレーティング・システムをデプロイすること、またはコンピュータ上の既存のオペレーティング・システムを新しいオペレーティング・システムに置き換えること、（ｉｉ）オペレーティング・システムの上に適切なミドルウェアをデプロイすること、（ｉｉｉ）関連するデータを使用してアプリケーションをデプロイすること、および（ｉｖ）追加されたリソースがアプリケーションをサポートできるようにするために関連するクラスタ管理／フェデレーション（連合）を実行すること、が可能なリソース・プロビジョニングを、（プロビジョニング・モジュール１３４を介して）実行することができる。このプロビジョニング機能の有利な特徴には、たとえば予期せぬ作業負荷のサージに応じて必要となる場合に、迅速かつ自動的にリソースを追加することだけでなく、もはや必要でない場合にはリソースを除去することも含まれるため、リソースの追加によるコストの増加が最小限に抑えられる。
【００２０】
加えて、デプロイメント・マネージャ１３０は、リソース構成パラメータ（たとえば、データベース用のバッファ・プールなどのメモリ・プール・サイズ、アプリケーション・サーバのＯＲＢ（オブジェクト・リクエスト・ブローカ）スレッド・プール・サイズ）を（チューニング・インターフェース・モジュール１３６を介して）リセットするが、これはリソース・チューニングにとって重要である。リソース・チューニングとは一般に、応答時間を最小にするかまたはスループットを最大にするなどの目標を達成するのに役立つように、リソースに関連付けられた１つまたは複数の構成パラメータを変更する技法のことである。デプロイメント・マネージャ１３０は、（たとえばアドミッション制御／要求スロットリングのために）リソース上で（スロットリング・インターフェース・モジュール１３８を介して）アドミッション・キューも操作する。スロットリングとは一般に、要求のタイプ（たとえば、ユニフォーム・リソース・ロケータによって識別可能な電子商取引サイトでの購入対閲覧）、発信元（優先顧客）などの、サービス・クラスを識別するいくつかのポリシーに基づいて、着信要求を拒否することである。こうした要求を拒否することによって、コンピューティング・デプロイメントに対する着信負荷を管理可能なレベルまで減少させることができる。デプロイメント・マネージャは、（モニタリング・モジュール１３２を介した）作業負荷データ（たとえばスループット、応答時間など）へのアクセスも提供する。
【００２１】
ソリューション・マネージャ１２０は、特定のアプリケーション・デプロイメントに関するサービス目標を維持する責務を負う。「サービス目標」とは、サービス・レベル・アグリーメント（ＳＬＡ）に従って指定される要件や設定とすることができる。すなわち例を挙げると、こうしたサービス目標は、エンド・クライアントの一定レベルの満足を保証しながらサービス・アプリケーションが第三者のインフラストラクチャでどのようにホストされるかに対処することができる。周知のように、一般に「サービス・プロバイダ」と呼ばれる第三者によって提供されるインフラストラクチャ（たとえばサーバ、ネットワーク接続）を使用して、自社のアプリケーションを実行する企業がますます多くなってきている。ＩＢＭ  Ｇｌｏｂａｌ  Ｓｅｒｖｉｃｅｓなどの多くの会社がウェブ・サイトをホストしたり、他のコンピュータ・ホスティング・サービスを提供したりしている。ＳＬＡは、サービス・プロバイダの予測を顧客と交渉できる手段を提供する。アプリケーション所有者とサービス・プロバイダとの間のＳＬＡは、このホスティング・サービスに関する条件を定義するものである。たとえばＳＬＡは、予想される応答時間、ネットワークやサーバにおける帯域幅スループット、ディスク・スペースの使用率、可用性すなわち、ネットワークおよびサーバ・リソースの稼働時間ならびに障害時の回復時間、および様々なレベルのサービスに対する価格設定などを含むことができる。しかしながらサービス目標は、一般に法的な性格を持ったＳＬＡに由来しなければならないものではない。サービス・レベル目標はしばしば企業内で、たとえば情報技術（ＩＴ）部門とオンライン発注システムをデプロイすることが可能な購買部門との間で交渉することができる。電子商取引サイトまたはＧｏｏｇｌｅなどの場所でさえも、ユーザ・エクスペリエンスが良くなるように応答時間などに関して良好なサービス・レベルを維持することを望む場合がある。
【００２２】
したがって特定のサービス目標を十分に維持することに関して、ソリューション・マネージャ１２０は制御論理エンジン１２２に従い、（ｉ）いつアクションを実行するか、および（ｉｉ）何のアクションを実行するかを決定する。以下で説明するように、制御論理エンジン１２２はこれらのタスクを、予測モジュール１２４、パフォーマンス推定モジュール１２６、アドミッション制御モジュール１２８、およびチューニング・モジュール１２９に従って実施する。すなわち制御論理エンジン（ＣＬＥ）１２２は、ソリューション・マネージャ１２０内の他のモジュールによって提供される機能のコントローラとして働くことを理解されよう。しかしながら、ブロック１２０に示されている機能配置構成は本来例示的なものであるため、ソリューション・マネージャによって提供される機能をコントロールするための他の配置構成が本発明の原理の範囲内で採用可能であることを理解されよう。
【００２３】
ソリューション・マネージャの有利な特徴の１つは、サービス目標を事前に管理し、したがって起こり得る違反を最小限にする／回避する機能である。これは、サービス・レベル違反が予期されるかどうかをチェックするために、（デプロイメント・マネージャ内のモニタリング・コンポーネントから取得した）作業負荷に関する（予測モジュール１２４による）予測と、（パフォーマンス推定モジュール１２６による）パフォーマンス推定とを組み合わせることによって実施される。好ましい実施形態では、本質的に制御論理コンポーネント１２２は、予測およびパフォーマンス推定の結果に基づいてどのアクションを実行するかを決定する、ルール・ベースのコンポーネントである。実行可能なアクションの例には、プロビジョニング（リソースの追加／除去）、アドミッション制御、およびリソース・チューニングが含まれる。
【００２４】
リソース・チューニングは、作業負荷が変化する場合に効果的であろう。たとえば電子商取引サイトでは相対的な購買対閲覧の混合が変化する可能性があり、これらのトランザクションは、たとえば異なるバッファ・プールを使用する、またはより多くのソートを必要とするなど、データベース内のある程度異なるリソースを要求する可能性があるため、相対的なバッファ・プール・サイズまたはソート・ヒープなどのデータベース構成パラメータを変更することによって、全体的なシステム応答性が向上する場合がある。これは、チューニング・インターフェース１３６を介してチューニング・モジュール１２９によって決定および実施される。
【００２５】
アドミッション制御は、たとえば好ましい顧客のみ、または購入トランザクションのみを許可するなど、システムが過負荷にならないように何らかのポリシーに基づいて着信要求のうちのいくつかを実際に拒否する。この種のアクションは、プロビジョニングまたはリソース・チューニングなどの他のアクションが所望の結果を達成できない場合に実行することができる。
【００２６】
いずれにしても、パフォーマンス推定機能を使用してアクションの程度（たとえばいくつのサーバを追加するか、構成パラメータをどの程度変更するか）が決定される。これらのアクションは、別々にまたは組み合わせて実行することができる。
【００２７】
以下に、本発明に従ったコンピューティング・デプロイメント管理システムの機能オペレーションについて例示的に説明する。この例では、アクティブ・クラスタへのサーバの追加／アクティブ・クラスタからのサーバの除去によって実施される１つのタイプの制御アクション、すなわちアプリケーション・プロビジョニングについて考察する。
【００２８】
図２を参照すると、本発明の一実施形態に従ったコンピューティング・デプロイメント管理方法２００を示す流れ図が示されている。
【００２９】
ソリューション・マネージャ１２０は、制御論理エンジン（ＣＬＥ）１２２がデプロイメント・マネージャ１３０内のモニタリング・モジュール１３２から取得する、作業負荷（トランザクション速度）、サービス目標（応答時間）、および構成（アクティブ、アイドル、および移行状態にあるリソース）を追跡する（ステップ２０２）。
【００３０】
トランザクション速度履歴などのモニタリングされたデータに基づいて、ソリューション・マネージャ１２０は予測モジュール１２４を使用して将来予想される作業負荷を算定する（ステップ２０４）。予測は長期（たとえば時／日）または短期（たとえば秒／分）とすることができる。作業負荷の変動における予期せぬ変化（たとえば通常の毎日／毎週など以外の）に対処するために、予測は好ましくは適応的であり最近の履歴から迅速に学習する。予測範囲は長期である必要はなく、たとえば、およそリソース・アクション（この状況ではアプリケーション・プロビジョニング）が効力を発するために必要な時間とすることができる。
【００３１】
好ましい実施形態では、予測モジュール１２４は、その開示が参照により本明細書に組み込まれている、同時出願の整理番号ＹＯＲ９２００３００５０ＵＳ１で特定される「適応的およびロバストな予測を実行するための方法および装置」と題する米国特許出願に記載された技法を使用してインプリメント可能である。しかしながら予測モジュール１２４は、たとえばその開示が参照により本明細書に組み込まれているＧ．Ｅ．Ｐ．Ｂｏｘ外による「時系列解析：予測および制御」（改訂版）に記載されている技法、またはＨｙｐｅｒｉｏｎから入手可能なＨｙｐｅｒｉｏｎ  Ｆｏｒｅｃａｓｔｉｎｇ  Ｓｕｉｔｅで採用されている技法などの、他の予測技法を採用することも可能であることを理解されよう。
【００３２】
次にソリューション・マネージャ１２０は、パフォーマンス推定モジュール１２６を使用して、最近および予測の作業負荷トラフィックに基づいてサービス目標しきい値（たとえば応答時間）を維持するために現在のリソース・デプロイメントが不十分、十分（すなわち適切）、または過度（すなわち過剰）のいずれであるかをチェックする（ステップ２０６）。本発明はいずれかの特定のパフォーマンス推定技法に限定されるものではないが、採用可能なこうした技法の例には、Ｂｒｉａｎ  Ｌ  Ｗｏｎｇによる「Ｓｏｌａｒｉｓサーバのための構成およびキャパシティ・プランニング（Configuration and Capacity Planning for Solaris Servers）」およびＤａｎｉｅｌ  Ａ．Ｍｅｎａｓｃｅ外による「ウェブ・サービスのためのキャパシティ・プランニング：メトリクス、モデル、およびメソッド（Capacity Planning for Web Services: Metrics, Models, and Methods）」に記載された技法、あるいはＢＭＣ  ＳｏｆｔｗａｒｅからのＰＡＴＲＯＬ  ＰｅｒｆｏｍおよびＰＡＴＲＯＬ  Ｐｒｅｄｉｃｔ、およびＩＢＭコーポレーションからのＨｉｇｈ  Ｖｏｌｕｍｅ  Ｗｅｂ  Ｓｉｔｅ  Ｐｅｒｆｏｒｍａｎｃｅ  Ｓｉｍｕｌａｔｏｒ  ｆｏｒ  Ｗｅｂｓｐｈｅｒｅと呼ばれる技法などが含まれる。パフォーマンス推定モジュールの推奨ならびに関連するリソース・プール内のサーバの状態および数に関する知識に基づいて、ソリューション・マネージャ１２０は、必要であれば適切な数のサーバを追加／除去する旨の要求をデプロイメント・マネージャ１３０内のアプリケーション・プロビジョナ１３４に送信する（ステップ２０８）。すなわち、現在のリソースが十分であるとＣＬＥ１２２が判定した場合、その時点でのプロビジョンングは必要ないことになる。
【００３３】
プロビジョニングが必要な場合（ステップ２１０）、プロビジョナ１３４は、アプリケーションを実行しているアクティブ・クラスタにアイドル状態からサーバを追加するように迅速に動作する。追加されるサーバ・インスタンスへの保存されたアプリケーション・イメージのロード、サーバの始動、およびクラスタ・マネージャからサーバへの要求送信の許可を組み合わせることによって、迅速な追加（たとえば約数分から約１分未満まで）が達成可能である。サーバにアプリケーション・イメージが事前にロードされている場合、リソース追加の速度を上げることが可能であることに留意されたい。したがって、事前ロードされたサーバは、クラスタ内で始動および活動化することが必要なだけである。アクティブ・クラスタからサーバを除去する場合、プロビジョナ１３４は、既存の作業は続行しながらクラスタ・マネージャからサーバへの新しい要求の着信を禁止する。これによってそのサーバでは作業が自然に静止し、その後サーバは停止する。
【００３４】
本明細書では、コンピューティング・リソースに関して「不十分」および「過度」（また同様に「不適切」および「過剰」）という句を使用することにより、十分なリソースがデプロイされていない（不十分）、または多すぎるリソースがデプロイされている（過度）ということを意味するだけでなく、１つまたは複数のリソースが（たとえば作業負荷混合の変更などにより）予期される作業負荷に合致するには不適当に構成されていること、または許可されるべきでないあるアドミッション要求が許可されていることも意味するものであることを理解されよう。したがって本発明によれば、リソース・デプロイメントは、リソースを追加または除去することだけでなく、１つまたは複数のリソースをチューニングすること、またはあるアドミッション要求をスロットリングすることによっても、「十分」（または同様に「適切」）にすることができる。
【００３５】
以下では、本明細書に記載された管理システムの例示的インプリメントからのいくつかの結果について説明する。考慮の対象となる例示的デプロイメントでは、アプリケーションはサプライ・チェーン・マネージメントである。アプリケーションは、バックエンドにデータ・サーバを備えたウェブ・アプリケーション・サーバのクラスタ上で動作する。この例では、システムは、２秒の応答時間サービス目標よりも下の状態を維持しようとしながらも、着信するトランザクション要求の大規模な予期せぬサージ（通常の負荷の約２０倍まで毎分倍増する）に直面する。プロビジョナの高速アプリケーション・デプロイメント機能は約３０〜４０秒であるため、短期予測の予測範囲は１分である。
【００３６】
システムのパフォーマンスが図３に示されている。トランザクション速度の予測（図３の一番上のパネル、ライン３０２）は、初期には実際のトランザクション速度（図３の一番上のパネル、ライン３０４）におけるサージよりも遅れているが、即座に追いついて予期されるトランザクション速度についての有用な指示を与えることができる。次にこれを使用して、パフォーマンス推定モジュール（図１の１２６）を使用して必要なアプリケーション・サーバの数を計算し、それらのサーバはアプリケーション・プロビジョナ（図１の１３４）の高速プロビジョニング機能により、すぐにアクティブな動作状態になる（図３の真ん中のパネル、ライン３０６）。サーバがアイドルからアクティブへ移る間の過渡的始動状態にある時間（図３の真ん中のパネル、ライン３０８）は約３０秒に過ぎない。ソリューション・マネージャにおける予測およびパフォーマンス推定と、デプロイメント・マネージャの高速アプリケーション・プロビジョニング機能とを組み合わせることによって、システムは極度に集中的なサージにもかかわらず２秒の応答時間ターゲットより下の状態を維持することができる（図３の一番下のパネル、ライン３１０）。サージが終わると、サーバはプールに戻される。
【００３７】
次に図４を参照すると、本発明に従ってコンピューティング・デプロイメント管理システムをインプリメントするのに好適なコンピュータ・システムの汎用ハードウェア・アーキテクチャを示すブロック図が示されている。たとえば、ソリューション・マネージャ１２０およびデプロイメント・マネージャ１３０に関して図１に示された機能コンポーネントを、図４に示されたタイプの１つまたは複数のコンピュータ・システム上でインプリメントすることができる。もちろん、独立した機能コンポーネントをそれら専用のコンピュータ・システム上でインプリメントすることもできる。しかしながら本発明のコンピューティング・デプロイメント管理システムは、いかなる特定のコンピュータ・プラットフォーム、配置構成、またはインプリメンテーションにも限定されるものでないことを理解されよう。
【００３８】
この例示的なインプリメンテーション４００では、本明細書に記載された本発明の管理方法および機能をインプリメントするためのプロセッサ４０２は、バス４０８または代替の接続配置構成を介してメモリ４０４および入出力（Ｉ／Ｏ）デバイス４０６に動作可能なように結合される。本明細書で使用される「プロセッサ」という用語は、たとえば中央処理ユニット（ＣＰＵ）または他の処理回路（たとえばデジタル信号プロセッサ（ＤＳＰ）、マイクロプロセッサなど）を含むなどの任意の処理デバイスを含むものと意図されることを理解されよう。加えて、「プロセッサ」という用語は、複数の処理デバイスを指すことが可能であること、およびある処理デバイスに関連付けられた様々な要素を他の処理デバイスと共有可能であることも理解されよう。
【００３９】
本明細書で使用される「メモリ」という用語は、たとえばランダム・アクセス・メモリ（ＲＡＭ）、読み取り専用メモリ（ＲＯＭ）、固定ストレージ・メディア（たとえばハード・ドライブ）、取り外し可能ストレージ・メディア（たとえばディスケット）、フラッシュ・メモリなどの、プロセッサまたはＣＰＵに関連付けられたメモリおよび他のコンピュータ可読媒体を含むことを意図する。好ましくは、メモリは本発明に関連付けられたデータおよびコンピュータ・プログラムを格納するために使用することができる。
【００４０】
加えて、本明細書で使用される「Ｉ／Ｏデバイス」という用語は、データを処理ユニットに入力するための１つまたは複数の入力デバイス（たとえばキーボード、マウス）、および処理ユニットに関連付けられた結果を提供するための１つまたは複数の出力デバイス（たとえばＣＲＴディスプレイ）を含むことを意図する。
【００４１】
本発明の方法は、コンピュータ可読媒体の形でインプリメント可能であることを理解されよう。本明細書で使用される「コンピュータ可読媒体」という用語は、フレキシブル・ディスク、ハード・ディスク・ドライブ、ＲＡＭ、コンパクト・ディスク（ＣＤ）ＲＯＭなどの書き込み可能タイプ媒体、ならびに伝送タイプ媒体を含むことを意図する。
【００４２】
したがって本明細書で説明するように、本発明の方法を実行するための命令またはコードを含む１つまたは複数のコンピュータ・プログラムまたはそのソフトウェア・コンポーネントは、１つまたは複数の関連するストレージ媒体（たとえばＲＯＭ、固定または取り外し可能ストレージ）に格納することが可能であり、使用準備が整った場合には、全体または一部を（たとえばＲＡＭに）ロードし、プロセッサ４０２によって実行することができる。
【００４３】
いずれにしても、本明細書で説明し添付の図面に示された本発明の技法は、たとえば、関連付けられたメモリ、特定インプリメンテーション向け集積回路、機能回路などを備えた、１つまたは複数の動作可能なようにプログラミングされた汎用デジタル・コンピュータなど、様々な形のハードウェア、ソフトウェア、またはそれらの組合せでインプリメント可能であることを理解されよう。本明細書に記載された本発明の技法が与えられた当業者であれば、本発明の技法の他のインプリメンテーションを企図することができるであろう。
【００４４】
したがって本明細書で詳細に説明したように、本発明は、変化する作業負荷または予期せぬ作業負荷の変動にかかわらず、システムの自動的な事前管理を可能にするアーキテクチャを提供する。すなわち、予測、パフォーマンス・モデリング、制御、および再構成のためのコンポーネントを有することが可能な、予期せぬ需要の変動を経験するコンピュータ・アプリケーションの事前管理のためのシステムが提供される。予測は将来の作業負荷を予想するために使用され、予想された作業負荷に対処するだけの十分な速さでアクションが実行される一方で、サービス・レベル目標への潜在的な違反にさらされることは少なくなる。アクションは、リソースが十分に活用されないことを最小限にしながら、リソースの構成変更すなわち変動が過度に繰り返されるのを回避する、費用対効果の高い方法で実行される。実行されるアクションは、予期される作業負荷およびサービス目標の考察と共に、使用可能なリソースに基づいたパフォーマンスのモデル／推定に基づくものである。アクションは、リソースのプロビジョニング、リソースのチューニングおよびアドミッション制御の少なくとも１つを含むことができる。
【００４５】
本発明のアーキテクチャは、（ａ）管理されるアプリケーション、（ｂ）感知および実行制御のためにそのシステムへの汎用インターフェースを提供するデプロイメント・マネージャ、および（ｃ）モニタリングへのこの汎用インターフェースに基づいてアクションが実行されるタイミングを決定し、汎用制御インターフェースを介して必要なアクションを要求する、ソリューション・マネージャに構築することができる。デプロイメント・マネージャは複数の構成を管理することが可能であるため、（ａ）特定のリソース・ノード、特定の構成、または特定の機能に特有のアクションを実行すること、および（ｂ）アプリケーションに適切なデータベース・パスおよびパラメータを自動的に設定すること、が可能になる結果として、リソースの迅速なデプロイメントまたは再デプロイメントが可能になる。
【００４６】
さらに明らかなように、本発明は、（ａ）作業負荷およびサービス・レベル・メトリクスが収集され、（ｂ）作業負荷測定の将来の値が予測され、（ｃ）これらの予測された値および所望のサービス・レベル目標を使用して、適切なサービス・レベルを保証するのに必要なアクションが決定され、そして（ｄ）変動を最小限にしながらも迅速に応答するようにアクション自体が開始される、適応システムを動作する技法をさらに提供する。
【００４７】
以上、本明細書において本発明の例示的な実施形態について添付の図面を参照しながら説明してきたが、本発明はこれらの実施形態自体に限定されるものでないこと、ならびに、当業者であれば本発明の範囲および趣旨を逸脱することなく様々な他の変更および修正が可能であることを理解されよう。
【図面の簡単な説明】
【００４８】
【図１】本発明の一実施形態に従ったコンピューティング・デプロイメント管理システムおよびこうしたシステムが動作可能な全体的な環境を示すブロック図である。
【図２】本発明の一実施形態に従ったコンピューティング・デプロイメント管理方法を示す流れ図である。
【図３】本発明の原理に従ったコンピューティング・システムまたはネットワークのパフォーマンスを示すグラフである。
【図４】本発明に従ったコンピューティング・デプロイメント管理システムを実施するのに好適なコンピュータ・システムの汎用ハードウェア・アーキテクチャを示すブロック図である。
【図１】
2006520027.tif 000003
【図２】
2006520027.tif 000004
【図３】
2006520027.tif 000005
【図４】
2006520027.tif 000006
【国際調査報告】
2006520027.tif 000007
2006520027.tif 000008
2006520027.tif 000009