レベル: 初級 Jason Bell (jaseb@jaseb.net), Technical Architect
2004年 2月 17日 オートノミック・コンピューティングのリファレンス・アーキテクチャは、実際のオートノミック・システムを構築する上で、フレームワークの役割を果たします。このリファレンス・アーキテクチャでは、中心的なテーマとして、「制御ループ」を定義しています。制御ループは、オートノミック・システムでイベントをハンドリングします。この制御ループは、オートノミック・マネージャーの中に実装されます。この記事では、動作時のオートノミック・マネージャーの基本的なシナリオを提示すると共に、オートノミック機能を持つ IBM ソフトウェア・アプリケーションと、Emerging Technologies Toolkitに含まれる簡単なサーモスタット・アプリケーションを使ったより詳細な例を解説します。
オートノミック・コンピューティングの概要
オートノミック・コンピューティングという用語は、自分自身をモニターし、ビジネスの要件によって変化する要求に対して、自身を適応させていけるシステムに適用されます。オートノミック・コンピューティング・システムには、以下の4つの機能があります。
オートノミック・コンピューティング・システムは人間の身体と比較することができます。（"Autonomic Manifesto"を参照してください）人間の身体には自律神経系が備わっているため、意識的に努力すること無く、また外部からの調整無しに、眼球を通る光の量を調整したり、体温を一定に保つために汗を出したりすることができます。
オートノミック・コンピューティング・システムも、究極的には、最小限の人間の介入のみで自分自身を動かし続けなければなりません
オートノミック・マネージャーはオートノミック・コンピューティング・システムのどこにあてはまるか？
すべてのオートノミック・コンピューティング・システムの内部には、１つかそれ以上のオートノミック・マネージャーが存在します。これらのマネージャーは継続的にシステムをモニターしており、アクションが必要なイベントを取り扱います。すべてのマネージャーは４つに分けられた機能を持ちます。まず、それは「センサー」によって環境をモニター(Monitor)し、モニター結果を分析(Analyse)します。オートノミック・マネージャーはそれから必要なアクションを計画(Plan)し、それを実行(Execute)します。もし、計画フェーズで特に必要なアクションが無い場合には、オートノミック・マネージャーはモニター・ステージに戻ります。アクションは「エフェクター」を通して実行されます。センサーは管理されるリソースの現在の状態を監視し、エフェクターはその現在の状態を変える能力を持ちます。
これらの機能は、一緒にまとめられ、以下の部分を持つ制御ループとして定義されます。
- モニター(Monitor)
- 分析(Analyse)
- 計画(Plan)
- 実行(Execute)
この4つの機能は「知識」を消費したり、生産したりします。この知識ベースは、まず当該システムに関する既知の情報によって構築され、オートノミック・マネージャーが管理対象のリソースについてより多くを学ぶにつれ、成長していきます。この知識は4つの機能によって常に共有され、より良い意思決定のために役立てられます。図1はこの制御ループの一般的な像を示しています。
図1. 動作中の制御ループ
オートノミック・マネージャーの基本シナリオ
以下のセクションでは、オートノミック・コンピューティング・システムに適用されるオートノミック・マネージャーの基本シナリオを詳述します。このシナリオでは、Webサーバー・システムの中に制御ループがあるものと仮定します。このシナリオの主たる目的は、CPU使用率が90%を超えないことを保障することです。もし90%を超えた場合には、システムは何らかのアクションを取る必要があります。
モニターと分析
モニター・プロセスの任務は、必要なソースからデータを集め、まとめることです。知識ベースの大きな部分は、モニターされた情報によって構成されます。今日のソフトウェア・システムが出力するレポートやログの量を考慮すると、実際に制御ループで使用されるデータのみをモニターするということが重要です。もし、例えば、大量のログデータをそのまま格納するとなると、実際にはシステムの動作に関係しないデータを継続的にモニターしなければならないため、システムの性能は大幅に劣化してしまうでしょう。
この例での最初のステップは、CPU使用率をモニターすることです。これには読み取り操作が必要であり、もしUnixシステムを使っているならば、"top"コマンドを走らせることになります。"top"コマンドからの出力例は以下のようになります。
リスト1．"top"コマンドの出力例
PID User PRI NICE SIZE RES STATE TIME WCPU CPU Command
57687 www 18 0 17428K 6048K lockf 2:48 0.00% 0.00% httpd
|
オートノミック・マネージャーはCPU使用率をシステムに問い合わせ、次にそのデータを「分析」フェーズに渡します。「分析」フェーズはそのデータを読み、何かしなければいけないかどうかを判断します。今の場合、上記の出力を見てお分かりの通り、サーバーは正常に動作しており、すべきことは何もありません。
オートノミック・マネージャーは動き続け、データをモニターし続けます。CPU使用率の変化は「分析」フェーズに、問題解決のための「計画」オブジェクトを呼び出させるトリガーになります。
リスト2．CPU使用率の変化
PID User PRI NICE SIZE RES STATE TIME WCPU CPU Command
57687 www 18 0 17428K 6048K lockf 2:48 0.00% 91.43% httpd
|
さて、ここで（理論的には）何が起こるかを見るため、制御ループの「計画」と「実行」フェーズを見てみましょう。
計画と実行
制御ループはポリシーに基づいています。つまり、ある条件が成立すると、あるアクションが実行されなければならないというわけです。これは、高水準言語にあるif/else 文に似ています。
以前の例にあるとおり、CPU使用率が変化したので、その対応方法を計画し、実行しなければなりません。
この例では、オートノミック・マネージャーの計画ステージは、サーバーをリスタートし、問題が直るかどうかを見るためのアクションをスケジュールしなければなりません。（ほかにもこの状況を修復する方法はありますが、この例ではこの方法を取ります。）
知識
既に簡単に述べたように、知識の大きな部分は、制御ループの最初のステップ、つまりモニタリングから得られます。必要な知識データのタイプはどのようなものかを考慮することが大切です。Webサーバーが生成するトランザクションを全部記録することは簡単なことですが、そのデータを入れるためのプロセス時間は、確実にループのパフォーマンスを損ねるでしょう。
オートノミック・コンピューティング・システムの全体を考慮して、記録されるべき知識や、どのような定常状態を保持するのか、どのような情報を探すべきかを計画しなければなりません。上記の基本的な例では、出力データをタイムスタンプと共にデータベースに格納しました。制御ループがレポートしているものを見つけるのと同じように、さらに何かエフェクターに実行させる必要のあるデータの傾向を見つけ出すのも、簡単でなければなりません。
必ずしもすべての知識がモニタリングからもたらされるわけではありません。専門家のチームが、いくつかのシナリオを設計し、知識ベースに追加することも十分にあり得ます。モニター対象が呈する症状と、その是正方法に関するデータベースを持つことも可能です。例えば、"データベースがダウンした"という症状を検索すると、手っ取り早い解決方法として、"サーバーをリブートする"という是正措置が見つかるかもしれません。
Arthur Hays Sulzberger は「人の判断は、その判断の元となった情報を上回ることはない。」と述べています。このことはオートノミック・コンピューティング・システムについても言えます。システムがエフェクターを実行するか否かの判断をするためには、情報が適切な形式で整っていなければなりません。
ツール: Emerging Technologies Toolkit から引用したサーモスタットの例
オートノミック・マネージャーの制御ループがどのように動作するのかを学ぶ一つの方法は、それが実際に動いているところを観察することです。実際に動いているシステムで、各パーツがどのように協力しあって動いているのかを見ることは、たいへん役に立ちます。こうした例を観察することにより、将来あなたが自分でイベント・ハンドラーを実装する時の参考にすることができます。ここでの例は、Emerging Technologies Toolkit に収録されているサーモスタット・プログラムを使います。（参考文献を参照）
注意:Emerging Technologies Toolkitインストール用のドキュメントを読むことをお勧めします。このサンプルはIBM WebSphereか、Jakarta Tomcatの上で動作します。
Toolkitをインストールしたら、サーバーを起動します。
リスト3．サーバーの起動
C:\ettk\actk\bin>startserver.bat
|
次に、クライアントを起動します。クライアントはサーモスタットの状態を表示します。これは小さなJavaアプリケーションであり、サーバーに接続します。
リスト4．クライアントの起動
C:\ettk\actk\services\grid\thermostat\client>runThermostat3.bat
|
クライアントを起動すると、温度計が希望の温度に達するまでなだらかに上昇していくのが見えます。（起動時には70°に設定されています。）
サーモスタット・デモの図１にあるように、このサーモスタットは69°から71°の間で振れています。これは、制御ループが常に温度をモニターしているからです。リスト5は、何が起こっているかを擬似コードで表したものです。
リスト5．温度のモニタリング
if temperature is less than the required temperature
then turn the heater on
if temperature is more than the required temperature
then turn the heater off
|
サーバー側で何が起こっているかは、コンソール・ウィンドウに表示されています。
リスト6．サーバーの状態
Get heater status = off
Set heater status = on
Get heater status = on
Set heater status = off
Get heater status = off
Set heater status = on
Get heater status = on
Set heater status = off
|
Iユーザーがスライダー・バーで設定温度を変えると、制御ループは（上記の擬似コードのように）ポリシーが満たされるまで働き続けます。もし設定温度を100°にしたら、クライアント・コンソールにはそのリクエストに応じたメッセージが表示されます。（Sending 100° to thermostat as new goal)
エフェクターがヒーターを"On"に設定するため、サーモスタットの温度は上昇し始めます。
このサーモスタットの例では、制御ループがどのように使われるかが示されています。Emerging Technologies Toolkitの中には、あなたが自分のアプリケーションに制御ループを実装するのに役立つコードが他にも含まれています。
オートノミック・マネージャーのより進んだ例
私がここで紹介した簡単なサーモスタットの例の他にも、オートノミック・コンピューティング・ツールキットにはオートノミック・マネージャーのより進んだ例が含まれています。そこでは、あなたが自分自身のオートノミック・マネージャーを開発するために必要なドキュメントとツールが提供されています。（参考文献を参照）
オートノミック・マネージャーの実世界での例
現状では、オートノミック・コンピューティングはまだ新しく、絶えず進化している技術ですが、既にいくつかのツールや製品では、オートノミック・マネージャーの機能が実装されています。例えば、DB2®の評価版をダウンロードして、今すぐにオートノミック機能を試してみることができます。
まとめ
オートノミック・コンピューティング・システムが成熟していくにつれ、そのツールも進化していきます。Emerging Technologies Toolkitとオートノミック・コンピューティング・ツールキットはあなたのアプリケーションにオートノミック機能を実装するためのツールとテクノロジーを提供しています。これらのツールキットには、オートノミック・コンピューティング・システムを組み上げていくのに役立つサンプル・コードやドキュメント、実際に動かして見ることができる多くの例が含まれています。
この記事では、オートノミック・マネージャーを紹介し、それがいかにオートノミック・コンピューティングのレファレンス・アーキテクチャーに適合するかを説明しました。オートノミック・マネージャーの実例を示し、かつ、もう実際に使われているツールの紹介もしました。
参考文献
著者について  | | | Jason BellはStudio B の執筆者であり、英国のテクニカル・アーキテクト、APIドキュメント執筆者でもあります。彼はJava Developer Jopurnal の中心的な編集者であり、RSSLibJを含む多くのオープンソース・プロジェクトに関わっています。RSSLibJはWebサイトのリッチな要約ニュースを作り、読み込むためのJavaのAPIです。彼のメール・アドレスは:jaseb@jaseb.netです。
|
記事の評価
| 
