JP2005516302A - 汎用適応制御のためのオブジェクト指向フレームワーク - Google Patents

Abstract

【課題】 コンピュータ・システムおよびアプリケーションの自動化チューニングのための汎用ソフトウェア・エージェントを構築しインプリメントするためのシステムおよび方法を提供することである。
【解決手段】 このフレームワークは、エージェントをモジュール方式で作成できるようにするモジュールおよびインターフェースを定義する。ターゲット・システム（２６０）の詳細は、ターゲット・システム（２６０）への均一インターフェースを提供するアダプタ（２３０）によって収集される。エージェント内のデータはメトリック・マネージャ（２４０）によって管理され、コントローラ・モジュールは所望の制御アルゴリズムをインプリメントする。このモジュール構造および共通インターフェースは、広く様々なターゲット・システムに適用可能な汎用エージェントの構築を可能にし、広く様々な制御アルゴリズムを使用することができる。

Description

本発明は一般に、コンピュータ・システムのパフォーマンスに関し、特に、汎用的かつアプリケーション独立的にコンピュータ・システムおよびアプリケーションの自動化パフォーマンス・チューニングのためのシステムおよび方法に関する。

この数年の間、分散およびネットワーク化システムの複雑さは著しく増大してきた。これは主にクライアント／サーバ・アーキテクチャおよび他の分散コンピューティング・パラダイムの活用によるものである可能性がある。このようなコンピュータ・システムおよびソフトウェア（オペレーティング・システム、ミドルウェア、およびアプリケーション）は、最適パフォーマンスのためにそれらを構成することが困難になるほど非常に複雑なものになっている。

データベース（たとえば、ＯＲＡＣＬＥ、ＤＢ２）、メッセージ待ち行列化システム（たとえば、ＭＱＳＥＲＩＥＳ）、アプリケーション・サーバ（たとえば、ＷＥＢＳＰＨＥＲＥ、ＤＯＭＩＮＯ）などの複雑なアプリケーションは、その構成、挙動、およびパフォーマンスを制御する、文字通り、数十および数百のパラメータを有する（ＤＯＭＩＮＯ／ＤＢ２ ａｄｍｉｎガイド）。また、このような複雑なシステムの挙動は、システム・ユーザによってシステムに課せられる動的負荷にも支配される。個々のパラメータを設定することは相当な専門知識を要し、パラメータと、結果的にシステムの挙動およびパフォーマンスに及ぼす影響との相互作用を理解することはさらに困難なことである。これらのシステムを管理することの困難さを増すもう１つの要因は、このようなシステムが非常に動的なものである可能性があり、したがって、たとえば、時間の経過につれて作業負荷が変化する場合に、そのパラメータの常時モニターおよび調整を必要とする可能性があることである。

したがって、特定のシステムの総所有コスト（ＴＣＯ）は、エキスパートの援助を雇うコストだけでなく、システムが適切に構成されていない場合に潜在的に失われる歳入のために増加する可能性がある。ＴＣＯおよびシステム管理者の負担を低減するために、多くのソフトウェア・ベンダは、現在、このような複雑なシステムを管理する複雑さを管理しやすくするためにソフトウェア・エージェントにたよっている。

ソフトウェア・エージェントは、このようなシステムを制御するというタスクに非常に適している。従来のエキスパート知識は一度だけエージェントに取り込むことができ、それにより、専門知識に対するエンドユーザの要求が低減された。加えて、ソフトウェア・エージェントは、より密接にシステムに結びつけることができ、人間の力で可能なものより密接なモニターおよび更新を実行することができる。制御理論、最適化、オペレーションズ・リサーチ、人工知能の分野における最近の進歩は、多くのエキスパート知識がなくても複雑なシステムの挙動を動的にチューニングするための豊富なアルゴリズムおよび技法をもたらすものである。

様々なターゲット固有または「カスタマイズ自動化チューニング・システム」（ＣＡＴＳ）が開発されている。例えば、通信サブシステム内のタスク優先順位を使用してマルチメディアの送達に関するサービス品質を制御したり、応答時間およびスループットの目標を達成するためにＭＶＳ（多重仮想記憶）固有のメカニズムを使用してＭＶＳシステムで達成するための応答時間およびスループットの目標を管理者が指定するための手段を提供する。

「チューニング」の概念は、既存のリソース割振りを調整することによりサービス・レベルを改善しようとするものである。上記のことを達成するには、メトリックスと、リソース割振りを決定するコントロールへのアクセスが必要である。一般に、（１）たとえば、回線速度、プロセッサ処理速度、およびメモリ・サイズなどのチューニング・コントロール（tuning control）を調整することによって変更されないターゲットのパフォーマンス関連機能を記述する「構成メトリックス」と、（２）たとえば、到着比率およびサービス時間などのターゲット上の負荷を特徴付ける「作業負荷メトリックス」と、（３）たとえば、応答時間、待ち行列長、およびスループットなどの送達されるパフォーマンスを特徴付ける「サービス・レベル・メトリックス」という３通りのクラスのメトリックスが存在する。

「チューニング・コントロール」は、ターゲット・リソース割振りを調整するパラメータであり、このため、ターゲットのパフォーマンス特性を変更するものである。電子メール・システムおよびアプリケーション・フレームワークであるＬＯＴＵＳ ＮＯＴＥＳは、大規模な１組のコントロールを有する。これらの中には、メモリを管理するためのＮＳＦ＿ＢｕｆｆｅｒＰｏｏｌＳｉｚｅ、サーバへのアドミッションを制御するためのＳｅｒｖｅｒ＿ＭａｘＳｅｓｓｉｏｎｓ、およびアイドル・ユーザの数を規制するためのＳｅｒｖｅｒ＿ＳｅｓｓｉｏｎＴｉｍｅｏｕｔがある。差異化サービスをサポートするＷｅｂベースのアプリケーションには、サービス・クラスおよびサーバ・タイプによって経路指定部分を決定するチューニング・コントロールが存在する。分散システムにおける信頼できるトランスポート・メカニズムであるＭＱ ＳＥＲＩＥＳは、ストレージ割振りと優先順位割当てのためのコントロールを有する。データベース製品（たとえば、ＩＢＭのＤＢ／２）では、ソート・インデックスおよびバッファ・プール・サイズ割振りのためのコントロールを公表している。

ＣＡＴＳでは、その解釈および調整のためのメカニズムを自動化チューニング・システムに取り込むことができるように、メトリックスおよびチューニング・コントロールをあらかじめ識別しなければならない。したがって、依然としてＣＡＴＳの構築およびメンテナンスは相当な専門知識を必要とする。インターネットの出現により、ソフトウェア・システムおよびそのコンポーネントは、それらが処理する作業負荷のように急速に進化している。したがって、チューニングが行われる速度に近い速度で自動化チューニング・システムを更新しなければならないのはもっともである。このような事情では、自動化チューニングの価値は著しく減少する。

自動化チューニングに関連する従来技術は主として、非常に緊密にターゲット・システム（すなわち、制御されるシステム）に結合された特定のアルゴリズムおよびアーキテクチャを開発することに焦点を合わせていた。このようなケースでは、そのアルゴリズムが他のシステムに容易に再適用することができず、提案されたアーキテクチャに他の制御方式を挿入することもできない。

ターゲット独立自動化チューニングに関する既存の従来技術では、メトリックスおよびコントロールにアクセスするためのアーキテクチャ上のサポートを考慮していない。汎用自動化チューニングを実現するには、汎用自動化チューニング・システムがターゲットから要求されたデータにアクセスできるように、十分に定義されたインターフェースを必要とする。以前の研究ではこれらの考慮事項を無視している。

チューニング・コントロールの適切な設定を探すサーチは、メトリックスのセマンティクスおよびチューニング・コントロールの操作に関する情報を公表することによって容易になる。特に、構成、作業負荷、およびサービス・レベルというカテゴリにメトリックスを入れることがターゲットにとって有用である。このような指定は、汎用システム・モデルの構築を助成することができる。さらに、このような知識を備えることによってチューニング・コントロールの適切な設定を探すサーチの複雑さが低減されるので、チューニング・コントロール調整の指向性の効果を表現する方法が存在しなければならない。過去の研究はこのような事柄に焦点を合わせていない。

従来技術の上記の諸問題ならびにその他の関連問題は、汎用適応制御のためのオブジェクト指向フレームワークである本発明によって解決される。本発明は、たとえば、ネットワーク内の１つまたは複数のコンピュータ・システムなどの１つまたは複数のターゲット・システムに適用することができる。

有利なことに、本発明は、汎用自動化チューニング・エージェント（ＧＡＴＡ）を作成するためのフレキシブルなソフトウェア・アーキテクチャを提供し、そのエージェントは、１つまたは複数のコントローラ・モジュール（以下「オートチューン・コントローラ（Autotune Controller）」ともいう）と、１つまたは複数のターゲット・システム（アプリケーション）アダプタ（以下「オートチューン・アダプタ（AutotuneAdaptor）」ともいう）とで構成されるソフトウェア・エージェントである。その上、本発明により、ユーザは、プラグ・アンド・プレイ方式で他のコンポーネントを代用できるように、エージェントのコンポーネント（コントローラおよびアダプタ）同士の間のインターフェースを指定することができる。また、本発明は、計算可能な制御戦略のインプリメンテーション（および構成）を可能にし、任意に複雑なやり方でコントローラ同士が相互接続できるようにするインターフェースも提供する。さらに、本発明は、フレームワーク内で作成されたエージェント同士が相互接続し、互いに通信して、複数ソフトウェア・エージェントからなる潜在的に複雑なネットワークおよび／または階層を形成できるようにするためのメカニズムを提供する。追加として、本発明は、必要な場合に任意選択かつフレキシブルな手動モニターおよび介入を可能にするカスタマイザ・インターフェースを提供する。

このアーキテクチャは、汎用フレームワークにおける多くの制御戦略のインプリメンテーションを可能にする。その上、これは、必ずしもターゲット・システムに結びつけられないように、制御戦略をモジュール方式でインプリメントできるようにする。このモジュール性によりさらに、同じ制御戦略を容易に種々のターゲット・システムに適用することができる。このアーキテクチャは、複数のコントローラを必要とする戦略をインプリメントするのに十分なほどフレキシブルである。加えて、これは、（追加のコーディングを必要とせずに）既存のインフラストラクチャを強化するエージェント間通信を可能にする。このため、複雑な分散システムを制御するための複雑なエージェント・ネットワークを構築することができる。

本発明の一態様によれば、１つまたは複数のターゲット・システムを自動的にチューニングするためのチューニング・システムが提供される。メトリック・マネージャは、１つまたは複数のターゲット・システムに対応する少なくとも１組のメトリックスを管理する。１つまたは複数のコントローラは、少なくとも１組のメトリックスに基づいて１つまたは複数の制御戦略をインプリメントする。この１つまたは複数の制御戦略は、１つまたは複数のターゲット・システムのうちのいずれかの特定のアーキテクチャとは無関係である。１つまたは複数のアダプタは、１つまたは複数の制御戦略に関して１つまたは複数のターゲット・システムとのインターフェースを取る。この１つまたは複数のアダプタのうちの少なくとも１つは、１つまたは複数のターゲット・システムのうちの対応する１つに固有のものである。

本発明の他の態様によれば、このチューニング・システムはさらに、メトリック・マネージャと、１つまたは複数のコントローラと、１つまたは複数のアダプタとのうちの少なくとも１つをカスタマイズするためのユーザ入力を受け取るための少なくとも１つのカスタマイザを有する。この少なくとも１つのカスタマイザはグラフィカル・ユーザ・インターフェースである。

本発明のさらに他の態様によれば、この１つまたは複数のコントローラは、１つまたは複数の制御戦略間の矛盾を解決するためのマスタ・コントローラを有する。

本発明のさらに他の態様によれば、このチューニング・システムは、他のチューニング・システムを呼び出して、１つまたは複数のターゲット・システムに関して階層チューニング・システムを形成する能力を有する。

本発明の他の態様によれば、このチューニング・システムおよび他のチューニング・システムは１つまたは複数の制御戦略をインプリメントするために協力して動作する。

本発明のさらに他の態様によれば、１つまたは複数のコントローラのうちの少なくともいくつかはモジュール方式のものであり、チューニング・システムからの削除、変更、または置換が行われる能力を有する。

本発明のさらに他の態様によれば、１つまたは複数のアダプタのうちの少なくともいくつかはモジュール方式のものであり、チューニング・システムからの削除、変更、または置換が行われる能力を有する。

本発明の上記その他の態様、特徴、および利点は、添付図面に関連して読むべき以下に示す好ましい実施形態の詳細な説明から明らかになるだろう。

図１は、本発明の例示的な一実施形態により、本発明によるソフトウェア・エージェントが適用可能な典型的な稼働環境を示すブロック図である。エージェント１１０は、所望のサービス・レベル要件ならびにコントローラの動作に影響する様々なパラメータに関して人間（またはソフトウェア）の管理者エンティティ１２０から情報を受け取る。本明細書で前述する構成メトリックス、作業負荷メトリックス、およびサービス・レベル・メトリックスに関してエージェント１１０への他の入力は、ターゲット・アプリケーション１３０自体から受け取る。このような入力を使用して、エージェント１１０は、ターゲット・システムまたはシステム１３０に関する制御設定を計算する。これらの制御設定はその後、ターゲット・システム１３０に伝えられる。したがって、エージェント１１０がターゲット・システム１３０に関して閉ループで動作することが分かる。また、図１は、ユーザ１４０によってそれに課せられる作業負荷によってターゲット・システム１３０の挙動が支配されることも示している。図１の最終態様は、管理者１２０がコントローラ・パラメータを提供することに加え、コントローラの動作に関連するメトリックスにアクセスできることである。これを使用すると、自動化エージェント１１０をモニターし、それが適切に動作することを保証し、その動作の効率を測定することができる。

このようなエージェントの内部コンポーネントは図２に概略が示されている。特に、図２は、本発明の例示的な一実施形態により、ソフトウェア・エージェントとそれに対応する相互接続とを有するコンポーネントを示すブロック図である。このエージェント・アーキテクチャはオートチューン・エージェント（Autotune Agent）と呼ぶ。

図２のソフトウェア・エージェントは、マスタ・オートチューン・コントローラ２１０と、１つまたは複数のスレーブ・オートチューン・コントローラ（以下「スレーブ・オートチューン・コントローラ」）２２０と、１つまたは複数のオートチューン・アダプタ（以下「オートチューン・アダプタ」）２３０と、リポジトリ２５０と、メトリック・マネージャ２４０と、管理者アプリケーション・プログラミング・インターフェース（ＡＰＩ）２６５と、カスタマイザ２７０、２８０、２９０とを含む。図２のソフトウェア・エージェントは、１つまたは複数のターゲット・システムおよび／または１つまたは複数の他のオートチューン・エージェント（本発明によるソフトウェア・エージェントが他のエージェントならびに他のエージェントではないターゲット・システムと対話可能であることを示すために、以下、区別なく「ターゲット・システム」または「他のオートチューン・エージェント」という）２６０と対話する。上記の説明は、オートチューン・エージェント自体が他のオートチューン・エージェントのターゲット・システムになりうることを示している。

オートチューン・エージェントは、１つまたは複数のオートチューン・コントローラと１つまたは複数のオートチューン・アダプタから構成することができる。そのエージェント内に複数のオートチューン・コントローラが存在する場合、そのうちの１つはマスタ・コントローラ２１０と指定され、最終制御アクションの生成を担当する。マスタ・コントローラ２１０は、制御アルゴリズムに応じて、所望の制御アクションの決定を助けるためにサブルーチンとして他の（スレーブ）コントローラ２２０のうちのいずれかを使用することができる。

図３は、本発明の例示的な一実施形態により、メトリックスのタイプ階層を示すツリーである。メトリックス３９０は、読取り専用メトリックス３７０と読取り／書込みメトリックス３８０に分割されている。本明細書に記載する本発明の例示的な実施形態では、構成メトリックス３１０と、作業負荷メトリックス３２０と、サービス・レベル・メトリックス３３０は読取り専用であり、チューニング・コントロール・メトリックス３４０は読取り／書込みメトリックスと見なされている。当然のことながら、本発明の精神および範囲を維持しながら、他の構成を使用することもできる。

メトリックスはメトリック・マネージャ２４０によって管理される。このエンティティは、そのエージェントにとって既知の１組のメトリックスを追加し、削除し、リストするためのインターフェース（図２のｇｅｔＭｅｔｒｉｃ（））を提供する。メトリック・マネージャ２４０により、管理者はカスタマイザ２８０または管理者ＡＰＩ２６５を介して、ロギングのために使用可能なリポジトリ２５０にロギングすべき既知のメトリックスのサブセットを選択することができる。メトリック・マネージャ２４０は、ロギングの宛先の選択およびロギング機能の使用可能／使用不可などの１組の各種機能を提供する。

オートチューン・アダプタ２３０は、ターゲット・アプリケーション（複数も可）２６０に対するエージェントのインターフェースである。各オートチューン・アダプタ２３０は、それが把握している１組のメトリックスを定義する。この１組は、オートチューン・アダプタ２３０に照会することによって入手することができる（図２のｇｅｔＭｅｔｒｉｃｓ（））。読取り専用メトリックスの場合、オートチューン・アダプタ２３０は、ターゲット・システム２６０からこれらのメトリックスの最新値を獲得する手段を提供する（図２のｐｒｏｃｅｓｓ（））。チューニング・コントロール・メトリックスの場合、オートチューン・アダプタ２３０は、ターゲット・システム２６０上のそのチューニング・コントロールの値を設定するための手段を提供する（図２のｓｅｔＣｏｎｔｒｏｌ（））。オートチューン・アダプタ２３０はターゲット固有のものであり、制御アルゴリズム自体が特定のターゲット・システムに直接結びつけられる必要がないように抽象化を提供する。同じ制御アルゴリズムを他のターゲット・システムに適用するためには、そのターゲット・システムの代用としてオートチューン・アダプタを使用するだけでよい。ターゲット・システム２６０は、たとえば、他のオートチューン・エージェントを含む、任意の外部エンティティにすることができることに留意されたい。この特性により、複数エージェントのチェーンを構築することができ、そのチェーンはエージェント階層を構築するために後で使用される。

オートチューン・コントローラ２１０、２２０は制御戦略をインプリメントする。オートチューン・コントローラ２１０、２２０は、メトリック・マネージャから関心のあるすべてのメトリックスを入手する（ｇｅｔＭｅｔｒｉｃ（）を使用する）。オートチューン・コントローラ２１０、２２０は、エラー（所望のサービス・レベルからの偏差）を計算し、新しい制御値を計算し、その制御値を設定するためのメカニズムを提供する（ｓｅｔＣｏｎｔｒｏｌ（）を介して対応するオートチューン・アダプタ２３０のコンポーネントを呼び出すことによる）。

典型的な制御ループは以下の通りである。

１． If (同期モード), then:
同期アダプタを呼び出す
２． 所望のサービス・レベルからのエラーを計算する
３． 新しい制御値を計算する（これは制御アルゴリズムをインプリメントする）
４． If (現行コントローラがマスタ・オートチューン・コントローラ２１０である), then:
その制御値を設定する
５． 繰り返す

直前のステップ２（エラーを計算する）は任意選択ステップであることを理解されたい。たいていの制御アルゴリズムはエラーに対して作用するが、エラーに対して作用しないものもある。当然のことながら、他の変形例は可能であり、関連技術の当業者によって容易に企図されるものである。

オートチューン・アダプタ２３０は、同期または非同期方式で動作することができる。「同期」とは、新しい制御値を計算する直前にオートチューン・アダプタ２３０が呼び出されることを意味する。非同期モードでは、オートチューン・アダプタ２３０は、最新のメトリック値を入手するために他の何らかの（ユーザ定義）周波数で独力で呼び出されるものと想定されている。この特徴により、制御周波数が感知周波数と同じではない場合にオートチューン・コントローラをインプリメントすることができる。

所望のサービス・レベルからのエラーを計算する際に、オートチューン・コントローラは、必要に応じてメトリック・マネージャ２４０にとって既知のメトリックスのうちのいずれかにアクセスすることができる。

それぞれのコンポーネント（メトリック・マネージャ２４０、オートチューン・アダプタ２３０、オートチューン・コントローラ２１０、２２０）用のユーザインターフェースはカスタマイザ２７０、２８０、２９０により提供される。カスタマイザは、各コンポーネントの低レベル詳細に対するＧＵＩを提供するエンティティである。本明細書に記載する例示的な実施形態では、エージェントの一部である各エレメントごとに１つのカスタマイザが存在する。当然のことながら、エージェントの一部である各タイプのエレメント（たとえば、オートチューン・コントローラ、アダプタなど）ごとに１つのカスタマイザを含むがこれに限定されない他の構成も可能である。たとえば、メトリック・マネージャ２４０の場合、カスタマイザにより、ユーザは、どのメトリックスをロギングすべきか、ならびにログ・ファイルの位置などを指定することができる。オートチューン・コントローラの場合、それにより、制御周波数の設定、マスタ・オートチューン・コントローラの選択などを行うことができる。オートチューン・アダプタ２３０の場合、同期／非同期という動作モードを選択し、チューニング・コントロールを手動で（自動化エージェントに動作させたくない場合）設定することもできる。また、カスタマイザ２７０、２８０、２９０は、使用可能なメトリックスをユーザに公表するための方法も提供し、したがって、リアルタイム・モニターを実行することができる。

次に、広く様々なコンピュータ・システムを制御するためのソフトウェア・エージェントを容易に作成するためにこのフレームワークをどのように使用できるかという具体的な例を示す。特定のエージェントをインスタンス化するためには、各ターゲット・システムごとに複数のオートチューン・アダプタと、１つ（または複数）の制御アルゴリズムというコンポーネントを必要とする。

図４は、本発明の例示的な一実施形態により、単一制御方法を使用して単一アプリケーションを制御するための単純なエージェントを示すブロック図である。図４のソフトウェア・エージェントは、単一オートチューン・コントローラ４１０と、オートチューン・アダプタ４６０と、リポジトリ４５０と、メトリック・マネージャ４４０と、管理者ＡＰＩ４６５と、カスタマイザ４７０、４８０、４９０とを含む。図４のソフトウェア・エージェントは、ターゲット・システムまたは他のオートチューン・エージェント（以下、区別なく「ターゲット・システム」または「他のオートチューン・エージェント」という）４６０と対話する。

単一ターゲット・システムと単一制御アルゴリズムを備えたシナリオ（図４の通り）に関する基本的なエージェント作成プロセスについては、以下の図８に関して示されている。

同じ制御戦略を使用する同じエージェントは、現行アダプタ・コンポーネントを新しいターゲット・システム用のコンポーネントで置換することにより、異なるシステムのターゲットにすることができる。これにより、既存の知識の再利用が可能になる。同様に、コントロール・モジュールを置換することにより、制御アルゴリズムを容易に変更することができる。

図５は、本発明の例示的な一実施形態により、複数の制御戦略を単一エージェントにどのように含めることができるかを示すブロック図である。

図５のソフトウェア・エージェントは、マスタ・オートチューン・コントローラ５１０と、１つまたは複数のスレーブ・オートチューン・コントローラ（以下「スレーブ・オートチューン・コントローラ」）５２０と、オートチューン・アダプタ５６０と、リポジトリ５５０と、メトリック・マネージャ５４０と、管理者ＡＰＩ５６５と、カスタマイザ５７０、２８０、２９０とを含む。図５のソフトウェア・エージェントは、ターゲット・システムまたは他のオートチューン・エージェント（以下、区別なく「ターゲット・システム」または「他のオートチューン・エージェント」という）５６０と対話する。この場合、マスタ・オートチューン・コントローラ５１０は、複数の低レベル制御戦略を使用して制御値を計算する最上位レベルの制御戦略をインプリメントする。このエージェントは、以下の図８に関して記載する通りに作成することができる。

図６は、本発明の例示的な一実施形態により、階層制御構成を示すブロック図である。この場合、次に「米国オートチューン・エージェント」６１０は「イースト・コース」６２０および「ウェスト・コースト」６３０というオートチューン・エージェントを呼び出し、次にこれらはその従属物６４０、６５０、６６０、６７０を呼び出す。この従属物６４０、６５０、６６０、６７０はそれぞれ、ａｐｐ１ ６８１、ａｐｐ２ ６８２、ａｐｐ３ ６８３、ａｐｐ４ ６８４を制御／マッピングする。この階層は、その階層の各レベルにあるコントローラによってインプリメントすることができる。

図７は、本発明の例示的な一実施形態により、図６の階層制御構成の一部であるエージェントのブロック図である。特に、この階層の内部ノードにあるコントローラ（マスタ・オートチューン階層コントローラ７１０）は図７に示されている。この実施形態では、高レベル・エージェントの場合、ターゲット・システムが低レベル・エージェントのうちの１つになることは留意すべき興味深いことである。この再帰は、他のオートチューン・エージェント７６０に対する標準的なアダプタ・インターフェースを提供するオートチューン・エージェント・アダプタ７３０によって可能になる。この例は、このフレームワークの完全な普遍性を示しており、同じフレームワークを使用して複数エージェントおよびコントローラの複雑なチェーンを容易に構築できることを示している。マスタ・オートチューン階層コントローラ７１０と、オートチューン・エージェント・アダプタ７３０と、他のオートチューン・エージェント７６０とに加え、図７の実施形態は、１つまたは複数のスレーブ・オートチューン・コントローラ（以下「スレーブ・オートチューン・コントローラ」）７２０と、リポジトリ７５０と、メトリック・マネージャ７４０と、管理者ＡＰＩ７６５と、カスタマイザ７７０、７８０、７９０とをさらに含む。

図８は、本発明の例示的な一実施形態により、オートチューン・エージェントを作成するための方法を示す流れ図である。図８の方法の諸ステップの一部はオートチューン・エージェントの所与のエレメントに関して「指定／作成」を示していることを理解されたい。これにより、ユーザは、ユーザの要求およびターゲット・システム上で実行すべきチューニングに応じて、そのエレメントを作成するかまたは現在既存のエレメントを使用することができる。

１つまたは複数のオートチューン・アダプタが指定／作成される（ステップ８２０）。次に、そのエージェントが２つ以上の制御戦略または制御アルゴリズムを使用するかどうかが判定される（ステップ８３０）。使用する場合、１〜Ｎ個（Ｎ＞２）のオートチューン・コントローラが指定／作成され（ステップ８４０）、この方法はステップ８６０に進む。使用しない場合、単一オートチューン・コントローラが指定／作成され（ステップ８５０）、この方法はステップ８７０に進む。

ステップ８６０および８７０では、１つまたは複数のカスタマイザを介して制御パラメータが選択／生成される。ステップ８６０および８７０のいずれも、たとえば、コントローラ周波数、同期／非同期モード、ロギング・メトリックスなどのパラメータを選択することを含むことができる。しかし、ステップ８６０は、１〜Ｎ個のオートチューン・コントローラからマスタ・オートチューン・コントローラを選択することを含まなければならない。

本発明は汎用自動化チューニング・システムを提供することを理解されたい。有利なことに、本発明は、ターゲット・システムの詳細な知識をチューニング・システムに取り込むためにエキスパートを必要とせず、むしろ、本発明はターゲットのパフォーマンス特性を学習することができる。これは、ターゲット・システムに関する従来の知識が使用可能であり、信頼でき、耐久性のあるものであるときに、本発明による汎用自動化チューニング・システムにこのような知識を活用させることを含むことができる。

添付図面に関連して例示的な実施形態について本明細書に記載してきたが、本システムおよび方法はこれらの正確な実施形態に限定されず、他の様々な変更および修正は本発明の範囲または精神を逸脱せずに当業者による影響を受ける可能性があることを理解されたい。このような変更および修正はいずれも、特許請求の範囲によって定義される本発明の範囲内に含まれるものとする。

本発明の例示的な一実施形態により、本発明によるソフトウェア・エージェントが適用可能な典型的な稼働環境を示すブロック図である。 本発明の例示的な一実施形態により、ソフトウェア・エージェントとそれに対応する相互接続とを有するコンポーネントを示すブロック図である。 本発明の例示的な一実施形態により、メトリックス・タイプ階層を示すツリーである。 本発明の例示的な一実施形態により、単一制御方法を使用して単一アプリケーションを制御するための単純なエージェントを示すブロック図である。 本発明の例示的な一実施形態により、複数の制御戦略を単一エージェントにどのように含めることができるかを示すブロック図である。 本発明の例示的な一実施形態により、階層制御構成を示すブロック図である。 本発明の例示的な一実施形態により、図６の階層制御構成の一部であるエージェントのブロック図である。 本発明の例示的な一実施形態により、オートチューン・ソフトウェア・エージェントを作成するための方法を示す流れ図である。

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