シンプトン（症状）の深層を探る、第1回: オートノミック・コンピューティングのシンプトン・フォーマット

ページオプション JavaScript を要するドキュメントオプションは表示されません 原文はこちら

レベル: 中級

Marcelo Perazolo (mperazol@us.ibm.com), Autonomic Computing Architecture, IBM

2005年 10月 18日

シリーズ記事の第1回として、この記事では、オートノミック・コンピューティングのシンプトン（症状）フォーマットという、未知の世界の奥深くに潜入します。ここではオートノミック・コンピューティングにおけるシンプトンのアーキテクチャーとフォーマットを紹介し、詳細に説明します、そして、シンプトンの表現方法や識別方法、標準的なシンプトン表現を使う利点、また、システム管理戦略の一部に採用する方法について説明します。

はじめに

この記事では、オートノミック・コンピューティングにおける、新しいシンプトン・フォーマットについて説明します。このフォーマットは、現在のシンプトン・フォーマットであるバージョン1.0を進化させたものです。（バージョン1.0は、オートノミック・コンピューティング・ツールキットのLTA（Log and Trace Analyzer）コンポーネントとして、手軽に入手することができます）。この記事では、次のような点に関して簡単に説明します。

• オートノミック・コンピューティング・コンテキストの中のナレッジを、どのように定義するか
• シンプトンは、どのような意味でナレッジの一形式なのか（参考文献をご覧ください）
• シンプトンの中にある、様々なコンポーネント
• オートノミック・コンピューティング・アーキテクチャーにおけるシンプトンの役割

シリーズを進める中で、正規シンプトンの具体的な例を学びます。また、様々な環境の中で再利用可能な、一般的なシンプトン分類の中で、そうした例がどこに当てはまるかを学んで行きます。

上に戻る

シンプトンとは何か

『シンプトン（症状）』というのはナレッジの一形式であり、管理対象となる環境の中で起こりうる問題や状況を意味します。基本的にシンプトンというのは、何か別のものが存在することを示すものです。医学の例で例えてみましょう。高熱の症状、というものを、華氏100度を超える体温として定義しておきます。もし患者が体温を測った時に体温計が101度を指していたら、高熱とみなします。この例では、症状は『華氏100度を超える体温』という表現で定義され、『高熱』として記述されます。こうした症状は、監視対象のデータ（体温計の読み値）が症状定義と一致した時に認識されます。症状が認識された場合には、「症状の『オカレンス（occurrence）』が存在する」と言います。

オートノミック・コンピューティングでは、制御ループのモニター・コンポーネントの中でシンプトン(症状)が認識され、問題やゴールに対するオートノミック分析のためのベースとして使用されます。シンプトンは、事前定義された要素（定義と記述）に基づいており、監視インフラが管理対象リソースから収集するデータ（イベントなど）と共に、オートノミック・マネージャーに提供されます。シンプトン定義は、モニター・コンポーネントがシンプトンの存在を認識するための条件を表現します。またシンプトンの記述は、認識される特定なシンプトンに固有な特徴を規定します。

大部分の場合、シンプトンは、オートノミック・コンピューティングでの自己修復機能と密接に関連しています。これは、シンプトンの主な目的が問題を示すことにあり、これが自己修復の領域に関わるためです。しかしシンプトンはまた、他の種類の問題（自己防御や自己最適化、自己構成など、）へのトリガーとして使用することもできます。問題や予測は、ほとんどすべての場合、シンプトンのオカレンスによって開始されるのです。

上に戻る

シンプトンの成果物と、その関係

オートノミック・コンピューティングでのシンプトン・アーキテクチャーでは、幾つかの成果物を定義しています。これらの成果物は、シンプトンが認識され、オカレンスが作成されるように、協調動作する必要があります。こうした協調動作に関わる主な成果物としては、下記のようなものがあります。

シンプトンの要素（Symptom element）

新しいシンプトン・オカレンスを作成するために必要な全情報を含んでいます。シンプトンの要素は、シンプトン・オカレンス作成時にシンプトンを定義するためのアトミック単位です。

シンプトンのオカレンス（Symptom occurrence）

ある特定なシンプトン要素インスタンスに関連したランタイム情報を含んでいます。基本的に各オカレンスは、シンプトン要素の中で定義されたものと同じシンプトンを表しますが、シンプトンを適用する対象となるコンテキストは異なる可能性があります。

相関エンジン（Correlation engine）

シンプトン要素を作成するために使用されるロジックを含んでいます。相関エンジンは、入力として外部からの刺激を受信し、その応答としてシンプトン・オカレンスを作成すべきか否かをチェックします。

オートノミック・マネージャーは、これらの成果物を全体的に組み合わせることによってイベントを処理し、それらを相関させて、（シンプトン要素をテンプレートとして使って）シンプトン・オカレンスを作成します。

シンプトン要素そのものは副成果物の集まりであり、シンプトンの様々な側面を表すものです。次のような副成果物を組み合わせると、シンプトン要素を構成することができます。

シンプトン・メタデータ　（Symptom metadata）

シンプトンを構成している情報の、汎用部分。これは、あらゆる種類のナレッジに存在しています。これはシンプトン要素ですが、ナレッジを汎用的に取り扱う必要のある場合に使われます。これは「どんなシンプトン」の「どんな」の部分に当たります。

シンプトン・スキーマ (Symptom schema)

シンプトンを構成する、具体的な情報部分。これはテンプレートとして、シンプトン・オカレンスを作成する時に使われます。シンプトンは、専用の属性（シンプトンの記述や優先度、関連付けられた例、可能性など）を、特定なスキーマで定義します。スキーマも、（メタデータと共に）「どんなシンプトン」の「どんな」の部分に当たります。

シンプトンの定義 (Symptom definition)

シンプトンを認識するために使用される、汎用的なロジック片。ご想像の通り、このロジックは、それぞれに対応する相関エンジン（シンプトンの処理に使用されます）と互換性を持つ必要があります。これは、「シンプトンをどのように」の「どのように」に当たる部分です。

シンプトン・メタデータとシンプトン・スキーマは共に、シンプトン・オカレンスに関連した情報の集合を保持し、そうしたオカレンスを、データという面から完全に記述します。また各シンプトン要素には、1つ以上のシンプトン定義を関連付けることもできます。このシンプトン定義によって、シンプトンが認識されるための、そしてシンプトン・オカレンスが作成されるためのイベント配置が定義されます。この先の、シンプトンと、その内容では、これに関して説明します。

図1は、こうした成果物からどのようにシンプトン要素を構成し、シンプトン・オカレンスを作成するかを示しています。

上で説明したような、中核的なシンプトンの副成果物の他に、シンプトン効果要素（symptom effect element）もあります。

シンプトンの効果 (Symptom effect)

シンプトン・モデルでは、シンプトン・オカレンスに対してどんな反応をすべきかを記述することに責任を持つ、追加要素も定義しています。この要素は、アクションや推奨に関する記述、その他の要素によって拡張することができます。しかしオートノミック・コンピューティング・アーキテクチャーでは、分析によって問題の存在が判明した場合に実行すべきリクエストや計画、オペレーションなどに関して、ずっと信頼性の高いモデルを定義しています。このモデルは、変更要求や変更計画など、追加のナレッジ・タイプに依存しています。シンプトン効果は、この、より信頼性の高いモデルへのショートカットとして使用することができます。あるいは、追加分析が不要なほど単純な状況に対してシンプトン効果を使用することもできます。シンプトン効果は、定義と合わせて、「シンプトンをどのように」の「どのように」に当たる部分を構成します。

図2は、すべてのシンプトン要素と、それらの構成に関する概念的なモデルを表しています。この図では要素の内容は示しておらず、要素間の関係だけを示しています。

先に示したように、シンプトンの要素は、シンプトンに関連した全情報を保持する主要要素です。シンプトン・オカレンスはシンプトン要素を補完するものであり、あるシンプトン・インスタンスの特定なコンテキストに関連した追加情報を保持するためのランタイム要素です。

シンプトン・モデルでは、他の要素にも役割があります。例えば、相関エンジンやシンプトン・リポジトリー（ナレッジ・ソースやシンプトン・コンテナーとしても知られています）などです。

他に重要な関係としては、次のようなものがあります。

SymptomElement.parent

あるシンプトンが、別の、親シンプトンから情報を継承することを表します。シンプトン・プロパティーあるいはシンプトン属性が定義されていない場合には、この情報を、親シンプトンの中で参照します。

SymptomElement.child

このシンプトンの中で定義されている情報に依存する、他の子シンプトンすべてを表します。シンプトン情報の中で変更が行われると、その変更は潜在的に、すべての子シンプトンに影響する可能性があります。

SymptomElement.correlatedOccurrence

他のナレッジ成果物の集合を指します。こうした成果物としては、他のシンプトンや、コモン・ベース・イベントあるいは特定の専用データなどがあり、これらが組み合わさって、このシンプトンが認識されるようになります。シンプトン定義がルールやパターンである場合、例えば、他のコモン・ベース・イベントの3つのインスタンスを組み合わせてシンプトンをトリガーし、認識する場合であれば、これら3つのコモン・ベース・イベントのインスタンスはすべて、この関係のままでシンプトンにリンクされます。

SymptomElement.rootCause

これが存在している理由は、問題の根本原因が必ずしもシンプトンとは限らないためです。分析は続行される可能性があり、ある特定な問題に対する、より適切な記述として、より適切なシンプトンが認識されるかも知れません。これが起こる場合には、汎用的な原因ではなく、より具体的なシンプトンが指摘されます。この関係によって、汎用的なシンプトンが、より具体的なシンプトンにリンクされ、リンク要素のツリーが構成されます。この場合、ツリーのルートが、分析の結果得られる最終的な根本原因ということになります。任意のポイントから根本原因のシンプトンまでの間にある、すべてのrootCause関係は、シンプトンの『相関トレール（correlation trail）』です。この関係は、シンプトンによって根本原因の分析を行う場合の基礎となります。

タイプ関係（Type relationships）

メインのシンプトン要素の中には、複数の「タイプ」関係があります。こうした関係はエクステンション・ポイントを意味し、ここから、そのシンプトンに関してさらに多くの情報を含むように、モデルを拡張することができます。通常、こうしたエクステンション・ポイントは、コアとなるシンプトンモデルに対して定義されたXMLスキーマ文書とは異なるXMLスキーマ文書によって記述されます。

上に戻る

オートノミック・マネージャー内部におけるシンプトン

オートノミック・マネージャーは、開発ツールが作成したシンプトン要素をロードし、それらをオートノミック・マネージャー内部のナレッジ・コンテナーの中に維持します。こうした情報は、後でオートノミック・コンピューティング制御ループのモニター部分が、『センサー・インターフェース』からオートノミック・マネージャーに入ってくるイベントへの応答として、新しいシンプトン・オカレンスを作成するために使用します。

シンプトンは、オートノミック・マネージャーのナレッジ・コンテナーの中に入った後、個別にアクティブ化され、その後、次々に入ってくるイベントを処理するために使用できるようになります。これは、オートノミック・マネージャー内部に実装されている『相関エンジン』によって行われます。相関エンジンは、ナレッジ・コンテナーの中で定義されている通りにシンプトン定義を処理できる必要があり、また、オートノミック・マネージャーが取得したフォーマットに従ってイベントを処理できる必要があります。新しいイベントが取得されると、そのイベントは相関エンジンに転送されます。そうすると相関エンジンは、すべてのアクティブなシンプトン定義を処理し、それらの定義と、処理中の新しいイベントとの一致比較を行います。このプロセスは『イベント相関』と呼ばれます。

オートノミック・マネージャーが行うオートノミック機能は、それが自己修復であれ自己防御であれ、自己構成であれ自己最適化であれ、ナレッジの集合として定義され、また、このナレッジの処理方法として定義されます。オートノミック機能は通常、オートノミック制御ループのモニター部分で開始され、シンプトン認識に基づいて、実行中の機能に関連した変更をトリガーします。こうした概念の集まりが、オートノミック・コンピューティングの基盤となっています。

図3は、オートノミック・マネージャーの内部動作を示しています。新しいシンプトン・オカレンスを生成するために、相関エンジンを使ってイベントとシンプトン定義の一致比較を行っています。

この図は、オートノミック制御ループのモニター部分を展開したものです。シンプトンが相関エンジンによって認識され、新しいシンプトン・オカレンスが作成されています。同時に、オートノミック制御ループのモニター部分から分析部分へと流れる情報として示されています。

上に戻る

シンプトンと、その内容

これから先のセクションでは、シンプトン概念モデルの主な要素に関連した、要素内容を説明します。シンプトンを作成する際には、これらの情報をすべて組み合わせることによって、完全に記述します。また、作成者は、これらの情報を注意深く計画する必要があります。

シンプトン・メタデータ

先に説明した通り、シンプトン・メタデータは、あらゆるシンプトンの中に存在するだけではなく、他のあらゆるナレッジの中にも存在する、一般的な情報です。これは、オートノミック・マネージャーだけが使用するだけではなく、ナレッジ操作を行う他の成果物も必ず使用する、一般的な情報です。表1は、シンプトン・メタデータを構成するプロパティーを示しています。

図4は、シンプトン・メタデータの中にあるプロパティーだけではなく、シンプトン成果物それぞれの中に含まれるプロパティーも示しています。

シンプトン・モデルには、明示的にメタデータと呼ばれる1つの成果物しかありません。しかしシンプトンに関する汎用的なナレッジ情報を構成するのは、すべての成果物に関連付けられた全プロパティー・セットであり、それらを拡張メタデータ内容と考えることができます。

シンプトン・スキーマ

シンプトン・スキーマは、シンプトンの中にだけ存在する特定な情報であり、他の形式のナレッジとは何ら関係を持ちません。表2は、シンプトン・スキーマを構成する情報を示しています。

この情報は、オートノミック・コンピューティングでのシンプトンの仕様に関する将来のバージョンでは変更される可能性があります。

シンプトン定義の成果物

シンプトン定義は、シンプトン・オカレンスを認識するために使用される成果物です。シンプトン定義は、そのシンプトン定義を処理するオートノミック・マネージャーが実装する相関エンジンと互換性を持っている必要があります。つまり、もしオートノミック・マネージャーがタイプAのシンプトン定義を含むシンプトンをロードする場合には、そのオートノミック・マネージャーは、Aを処理できる相関エンジンも実装する必要があります。オートノミック・コンピューティング・アーキテクチャーでは、シンプトン定義のタイプに基づいて、シンプトンをバッチでロードするためのフィルターを定義します。

シンプトン定義は、どんなものでも構いません。一例としては、次のようなものがあります。

• XPATH表現
• 正規表現
• 決定木
• 依存関係グラフ
• Prolog述部
• ACTパターン
• TECルール
• ニューラル・ネットワーク

これらの形式についての情報は、参考文献を見てください。

これらの表現やルール、パターン、その他の構成体は、どれでも同じように動作することは重要ですので注意してください。これらはどれも、正規化形式のイベント（IBM コモン・ベース・イベント、あるいは、WSDM（Web Services Distributed Management）イベント・フォーマット（WEF））を使っています。そのようにしている意図、また最終的な結果としては、規定された表現やルール、パターン、その他の構成体にイベントが一致した場合に、新しいシンプトンが作成されるようになっています。

シンプトン効果・・・追加の成果物

ここまでは、それまでに定義されたシンプトン成果物によって、一般的で柔軟な方法でシンプトンを認識、作成することができました。ここで相変わらず欠けているのは、シンプトンに反応するための機能です。反応機能があれば、シンプトン・オカレンスが作成された後、その効果を知ることができます。これがシンプトン・効果成果物の役割です。

オートノミック・コンピューティングのアーキテクチャーでは、オートノミック・コンピューティング制御ループの他の部分も問題に対応し、最終的にその部分が、シンプトン・オカレンスが作成される際に期待される反応を定義します。つまり制御ループの分析部分、計画部分、実行部分でも問題対応を行い、変更要求と変更計画はそれをサポートしていました。しかし、分析や計画が全く行われない単純な状況では、シンプトン認識後に期待される反応を定義するためにもシンプトンが使われます。これは、オートノミック制御ループの分析部分や計画部分を持たないオートノミック・マネージャーにとって、あるいは、持っていても、認識された特定なシンプトンが何ら変更要求をトリガーしない場合には、特に便利です。また、変更要求の作成にオンザフライ戦略を実装しているオートノミック・マネージャーでも、シンプトンを使うことができます（変更要求は、シンプトン効果を開始点として使うことで生成されます。）。

シンプトン効果成果物は、幾つかのものに拡張することができます。例えば、管理可能リソースで実行すべきアクションや、人が読み取れる形式の推奨に関する記述、あるいはもっと単純に、スクリプトの実行やコード片ということもあり得ます。現在のシンプトンの仕様では、下記の2つの効果のみを定義しています。

推奨に関する記述

ある特定のシンプトンに関連付けられた問題を修正するために、オペレーターがすべき事を記述するテキスト表現。基本的に、オートノミック・マネージャーと手動マネージャーとの間の対話動作を対象にしています。

アクション

ある特定のシンプトンに関連付けられた問題を修正するために使用されるタスクや手順を定義するコード片。基本的に自動化されており、シンプトンのスコープ・プロパティーによって定義される管理可能リソースを対象にしています。

先に触れた通り、こうした形式のシンプトン効果は、ある特定のオートノミック・マネージャーが必要とするもの次第で、補強、あるいは拡張される場合があります。

上に戻る

まとめ

オートノミック・コンピューティングのシンプトン・フォーマットは、表現力豊かで柔軟な基礎を提供するものであり、幾つかの既存製品やソリューション（Tivoli® MonitoringやTivoli Enterprise Consoleなど）に適用することができます。シンプトン・フォーマットのおかげで、製品やソリューションを完全なオートノミック環境に変換するための明確なロードマップを作ることができます。共通シンプトン・フォーマットも一貫性を保つために役立っており、これによってオートノミック・マネージャーの間で必要な対話動作が行えるようになっています。こうした対話動作は、オートノミック・マネージャーの間での協調動作、あるいは、問題判別や予測、その他オートノミック・コンピューティングのゴールに関連したソリューションにおける他の管理アプリケーションとの間での協調動作にとって、非常に重要です。

シンプトン要素は、オートノミック・マネージャーを構成するために使われます。そしてオートノミック・マネージャーはイベントを受信すると、こうした要素を使い、またシンプトン定義を処理することによって、イベント相関機能を実行します。一致が検出されると、シンプトン・メタデータとスキーマがテンプレートして処理され、シンプトン・オカレンスが作られます。オートノミック・マネージャーは、シンプトン・オカレンスに関連付けられたシンプトン効果を実行することによって、シンプトンオカレンスに反応します。こうした動作によって、既存の製品やソリューションの上で、完全なオートノミック機能が実現できるのです。

上に戻る

次回は

次回は、既存の製品やソリューションから抽出した、実際の例の中に入り込みます。どのようにシンプトンを識別するか、その環境にどのような影響を与えるか、シンプトンに対応するために、どんなアクションを自動的に呼び出すのか、などについて説明します。また、簡単な正規のシンプトンリストを示します。これを利用すると、様々な製品やソリューションの中で問題判別機能を再利用できるようになるのです。

参考文献

• 「An architectural blueprint for autonomic computing」は、オートノミック・コンピューティング・アーキテクチャーの概要に関するIBMのホワイトペーパーであり、ナレッジや、その他のアーキテクチャー・ブロックに関する情報が含まれています。
  
  
• オートノミック・コンピューティングに関するホットな話題を知るために、「オートノミック・コンピューティングの最新動向: オートノミックシステムでのナレッジの役割」（developerWorks, 2005年）など、このシリーズの記事を読んでください。
  
  
• WEF（WSDM Event Format）に関する情報については、標準文書、Management Using Web Services (MUWS), Part 1 and Part 2を参照してください。
  
  
• このオンライン資料、XML Path Language, version 1.0を読んで、XPATH表現の構築方法を学んでください。
  
  
• 「オートノミック・コンピューティングの最新動向: オートノミック・コンピューティングのCHOPを理解する」（developerWorks, 2005年6月）の中の「統合された、self-CHOPシナリオ」は、シンプトンに関するセクションです。
  
  
• 現在のシンプトン・フォーマット1.0とLTA（Log and Trace Analyzer）コンポーネントについての情報は、オートノミック・コンピューティング・ツールキットをご覧ください。
  
  

• developerWorks blogsに参加して、developerWorksのコミュニティーに加わってください。
  
  
• IBMのVPであるDave Bartlettが、毎週このblogsの中で、業界におけるオートノミック・コンピューティングの現状を伝えています。

著者について

		Marcelo Perazolo は、IBM のオートノミック・コンピューティング・アーキテクチャー・チームのメンバーです。シンプトンや、その他のナレッジ・フォーマットに関するアーキテクトであり、オートノミック・コンピューティングに関連した管理統合分類法 (Management Integration Taxonomies) を定義しています。1990 年から IBM で働いており、ネットワーク管理やシステム管理に関する様々な業務を行ってきました。1994 年に電子工学で修士を取得しています。関心を持っている領域としては、問題の判別や予測、プロセス最適化手法、セキュリティー、相関技術、ナレッジ表現などがあります。

記事の評価

サイト改善のため、ご意見をお寄せください。こちらのフォームからお願いいたします。 この情報はお客様が目的を達成するうえで役に立ちましたか？ はい いいえ わからない   お気軽にご意見・ご感想をお寄せください。   この記事は役に立ちましたか？ 1 2 3 4 5 不充分・不完全である 大変素晴らしい

この記事を共有する はてなブックマーク livedoorクリップ del.icio.us Buzzurl（バザール） Choix！ Saafブックマーク FC2ブックマーク MM/memo ニフティクリップ Yahoo!ブックマーク CZブックマーク newsing

上に戻る