レベル: 初級 Brent Miller (bamiller@us.ibm.com), Senior Technical Staff Member, IBM
2005年 9月 13日 ナレッジ（知識）は、単にデータや事実を集めたものではありません。オートノミックコンピューティングシステムでは、ナレッジはオートノミックマネージャーが使用する情報として扱われます。このシリーズの記事では、オートノミックコンピューティングアーキテクチャーに焦点を当てていますが、今回は、アーキテクチャーのどこにナレッジが当てはまるのかを調べましょう。自己管理のITシステムを構築するための基礎となる、このアーキテクチャーでは、5つの構成ブロックを定義しています。つまりオートノミックマネージャー、マニュアルマネージャー、タッチポイント、ナレッジソース、そしてESB（enterprise service bus）用のオートノミックコンピューティング使用パターン、という5つです。このコラムではナレッジソースと、そしてナレッジ一般に関して、少し詳しく説明します。
はじめに
『オートノミックコンピューティングの最新動向』の前回の記事は、オートノミックコンピューティングのアーキテクチャーに焦点を当てたシリーズの第2回目でした。その記事では、タッチポイントと呼ばれるアーキテクチャー構成ブロックについて説明しました。今回の記事では、オートノミックコンピューティングのアーキテクチャーに関するシリーズの続きとして、自己管理のオートノミックシステムにおける『ナレッジ』の役割を、『ナレッジソース』と呼ばれるアーキテクチャー構成ブロックを含めて説明します。
ここで説明する内容としては、オートノミックコンピューティングのアーキテクチャーにおいてナレッジとは何を意味するのか、自己管理のオートノミックシステムにおいて、どのようなタイプのナレッジが鍵となるのか、人やシステムがどのようにナレッジを作成するのか、オートノミックマネージャーはどのようにナレッジを使用するのか、そして、ナレッジソースは、これらをどのように実現しているか、などです。では、ナレッジを探ってみることにしましょう。
ナレッジとは何か
私が好きなオンライン辞書（参考文献にリンクがあります）には、ナレッジに関して幾つかの項目があります。その中から、次の2つを挙げましょう。
- 知っているという状態、あるいは知っているという事実
- 知覚された、発見された、あるいは学習されたものの集積あるいは範囲
オートノミックコンピューティングシステムでのナレッジは、これら両方の形を取ります。つまりナレッジは、既知の（恐らく人にとって既知の）何かをキャプチャーし、それをオートノミックマネージャーが使用できるように、ある標準の形式で表現します。そうすると、新しいナレッジはインスタンス化（あるいは「認識」）されます。そして、高度なシステムにおいて新しいナレッジが発見され、学習されるようになるのです。この記事では、この後者の場合を探って行きます。
まず、自己管理のオートノミックシステムにおけるナレッジと、他のコンピューター科学の領域で知られているナレッジ（特に人工知能）とを区別する必要があります。Dictionary.comでは、特にこの面から見たナレッジの説明を挙げています。
『artificial intelligence, information science（人工知能、情報科学）』 ある関心領域において存在すると想定されているオブジェクト、概念、あるいは関係。何らかのナレッジ表現言語を使って表現されたナレッジの集合は、ナレッジベースとして知られており、また、ナレッジベースを拡張する、そして/あるいは照会するプログラムは、ナレッジベースシステムである。
ナレッジは、新しいナレッジが既存のナレッジから論理インターフェースを使って作られるという点で、データや情報とは異なる。情報をデータ＋意味だとすれば、ナレッジは、情報＋処理である。
例えばナレッジの一般的な形式であるPrologプログラムは、ある主題に関する事実とルールの集合である。
オートノミックコンピューティングアーキテクチャーでのナレッジに関する定義は、これと同じではありませんが、一部似ているところもあります。一般的に、自己管理のオートノミックシステムでのナレッジは、プロセス、特に自動化が可能なプロセスを実行するために使用される構造化データまたは構造化情報であれば、ほとんどどんなものでも可能です。このようにナレッジに関するスコープは広いため、ナレッジに含まれるものとしては、ログファイルに保存されるデータ、タッチポイントやプロセスに関する状態データ、システムに変更を加えられる時期に関するスケジュールデータまであります。
しかし、オートノミックコンピューティングのアーキテクチャーでは、従ってこの記事では、もっと狭い範囲のナレッジに、つまりオートノミックマネージャーが使用するような、構築された形式のナレッジに焦点を当てます。そしてオートノミックアーキテクチャーでは、さらに1ステップ進めて、オートノミックマネージャーができることを表現、拡張するために使われるような種類のナレッジに焦点を当てるのです。
これは一体、何を意味するのでしょう。その質問に答えるために、オートノミックマネージャーを見ることにしましょう。図1は、オートノミックマネージャーの主な部分と機能を示しています。
図1. オートノミックマネージャー
Autonomic Computing Architectural Blueprint（参考文献にリンクがあります）では、オートノミックマネージャーを次のように表現しています。
管理インターフェースによって定義される振る舞いに従って、ある管理機能を自動化し、この機能を外部化する実装。オートノミックマネージャーは、制御ループを実装するコンポーネントです。システムコンポーネントが自己管理であるためには、自分に必要な詳細をシステムから収集し、その詳細を分析して何かを変更する必要があるかどうかを判断し、必要な変更を規定する計画またはアクションシーケンスを作成し、そしてこれらのアクションを実行するための、自動化した方法を持っている必要があります。こうした機能が自動化されると、インテリジェントな制御ループが形成されます。
この定義は、オートノミックマネージャーが持つ、監視－分析－計画－実行（Monitor-Analyze-Plan-Execute）という機能合成を表現しています。こうした、鍵となる機能はよく知られており、頭文字を取ってMAPEループと呼ばれることがあります。しかし図1ではMAPE機能に加えて、オートノミックマネージャーが、『ナレッジ』ブロックも含んでいることを示しています。このナレッジブロックは、MAPE機能ブロックの4つすべてに接続されていることに注意してください。このように接続されていることから、典型的なオートノミックマネージャーでは、その全体にナレッジが使われていることが分かります。ですから、自己管理のオートノミックシステムにおけるナレッジの重要性を軽く考えるべきではありません。次のセクションでは、この点に関して、もう少し明確に説明することにします。
ナレッジのタイプ
Autonomic Computing Architectural Blueprintでは、幅広いタイプのナレッジとして、次の3つを引用しています。
- ソリューショントポロジーナレッジ（例えば、『インストール可能ユニット記述子（installable unit descriptor）』など）
- ポリシーナレッジ
- 問題判別ナレッジ（例えば監視対象のデータや症状）
オートノミックマネージャーが使用する、特定な構築されたタイプのナレッジを図1に追加すると、図2のようになります。
図2. オートノミックマネージャーとナレッジ
図2は、先のブループリントで説明されているポリシーナレッジと、トポロジーナレッジを示しています。（トポロジーナレッジは『インストール可能ユニットデプロイメント記述子（Installable Unit Deployment Descriptor）』で表現される場合があります。）また図2は、オートノミックマネージャーのMAPE機能間で論理的に渡される、次のようなナレッジも示しています。
- 症状（Symptom）は、監視機能がCommon Base Eventなど監視対象のデータを相関させることによって作ります。症状は、1つ以上の管理対象リソースに関する、何らかの条件を表します。
- 変更リクエスト（Change Request）は、分析機能が症状その他のデータを詳細に調べることによって作ります。変更リクエストは、1つ以上の管理対象リソースに対して加えようとする、何らかの変更を表します。
- 変更計画（Change Plan）は、変更リクエストを実行するために使用する、ある一連のステップまたはプロセスを、計画機能がコード化することによって作ります。変更計画は、1つ以上の管理対象リソースに対して、ある変更を実現するための方法を示します。
上記のブループリントの説明によると、症状や変更リクエスト、変更計画などのナレッジは問題判別ナレッジと考えられるかも知れませんが、これらのナレッジタイプは、問題判別のみに使用すべきものとして限定されているわけではありません。症状や変更リクエスト、変更計画などは、例えば自己防御や自己構成のシナリオで使われる場合もあります。この背景に関しては、前回の記事、「オートノミックコンピューティングのCHOPを理解する」の中で、ここで説明しているようなナレッジタイプが様々に使われることを取り上げていますので、それを見てください。
ここで取り上げているナレッジタイプは、オートノミックコンピューティングに関係するナレッジタイプの膨大なリストではなく、オートノミックマネージャーが使用するものだけに焦点を当てています。以下のセクションでは、このナレッジがどのように作られ、共有され、そしてオートノミックマネージャーによって使用されるかを、詳しく説明します。
ナレッジソース
上記のブループリントを引用すると、「『ナレッジソース』は、アーキテクチャーが規定するインターフェースに従ってナレッジへのアクセスを提供する、レジストリーや辞書、データベースその他のリポジトリーなどの実装です。」
ナレッジの共有が必要な場合には、そのナレッジをナレッジソースに入れます。ナレッジソースは、システムナレッジ（ポリシーや症状など）を保存する場所です。ここに置くことによって、オートノミックマネージャーやマニュアルマネージャーの間でナレッジが共有できるようになります。これを図3に示します。これはブループリントから引用したものです。
図3. 自己管理のオートノミックシステムでのナレッジソース
ナレッジソースは、人や自動化されたプロセスが作成したナレッジを保持します。オートノミックマネージャーやマニュアルマネージャーは、そのナレッジを検索し、それを使用して、症状を認識する、ポリシーを強制するなど、彼らが実行すべき機能を実行します。オートノミックマネージャーがナレッジをどのように使用するかに関しては、後で詳しく説明します。まず、ナレッジがどのようにしてナレッジソースの中に入るかを調べてみましょう。
ナレッジのオーサリングとデプロイ
今日では、システム管理に有用なナレッジは、多くの場所に存在しています。多くの場合、ナレッジの大部分は開発者や管理者、あるいはその他の、ITインフラのコンポーネントに関連した人の頭の中にあります。そうしたナレッジを標準的な形式でキャプチャーすることによって、一部のシステム管理タスクを自動化することができます。
タッチポイントの開発者（タッチポイントに関する背景については、前回の記事、「タッチポイントに触れる」を見てください）は、タッチポイントに関するナレッジをキャプチャーし、利用できるようにすることによって、そのタッチポイントの管理機能を高めることができます。そうしたナレッジの例として、症状と、インストール可能ユニットデプロイメント記述子（IUDD: installable unit deployment descriptor）の2つがあります。
タッチポイントの開発者は、ある特定なシーケンス、あるいは特定な時間間隔での一連のイベントが、リソースにおける、ある条件の症状であること、そしてそれが問題を示している可能性があることを知っているものです（問題には、実行時にメモリーが不十分、コンフィギュレーションの値が不適切、あるいは通信リンクの途切れ、などがあります）。これらの条件は、症状が発生するからには存在しているはずなので、それを表現するための標準的な方法を使って、症状自体と共に症状ナレッジとしてコード化することができます（どのような条件を表現しているか、どのようなリソースが関係しているか、など）。
またタッチポイントの開発者は、タッチポイントをインストールする際に考慮すべき、リソースに関連した特定な事項も知っている場合があります（例えば、要求される前提条件や、インストール時に一緒に必要なコンポーネント、必要なハードウェア能力など）。こうした依存関係は、タッチポイントをインストールする際に考慮すべき依存関係やチェック事項を表現するための標準的な方法を使って、ソリューショントポロジーナレッジとしてIUDDの中にコード化することができます。
タッチポイントの開発者（と、その他の人達）によって標準形式でキャプチャーされ、コード化された、こうしたナレッジは、オートノミックな自己管理に使用できるように、ナレッジソースの中にデプロイされます。いったんナレッジソースの中にナレッジがデプロイされれば、後でタッチポイントを管理するために、オートノミックマネージャーやマニュアルマネージャーがそれを使うことができます。一例を挙げると、IUDDナレッジはタッチポイントのインストールに使うことができ、症状ナレッジは、タッチポイントの稼働中に発生する症状を認識するために（そして認識された症状に応じて適切な変更を行うために）使うことができます。
オートノミックマネージャーでのナレッジの使用
では、オートノミックマネージャーは、どのようにナレッジを使用するのでしょうか。図4は、前の例で説明した症状ナレッジに関して、このプロセスを示しています。
図4. オートノミックマネージャーがナレッジを使用する
タッチポイントを作る人は、まず症状ナレッジをオーサリングし、それをナレッジソースにデプロイします。次に、その後のある時点で、このタッチポイントを管理する役割を負わされたオートノミックマネージャーが、この症状ナレッジをナレッジソースからロードします。通常、オートノミックマネージャーは、ロードしたナレッジを自動的に使い始めることはせず、そのオートノミックマネージャーのマネージャー（図4では、ステップ3に対するマニュアルマネージャーとして示されています）が、オートノミックマネージャーの中にあるナレッジをアクティブにする必要があります。このようにして、このナレッジに関連した管理アクティビティーが、人によるアクティビティーから、オートノミックマネージャーでの自動化アクティビティーにと『委任』されるのです。そして最後に、アクティビティーが委任された後、オートノミックマネージャーは対象となるナレッジを使い始めることができます。この例で言うと、これはつまりオートノミックマネージャーが、これらの症状に関連した条件が発生し、監視されると、症状を認識し始めることを意味します（図4では、監視機能の中の相関エンジンを使う、ステップ4として示されています）。これらの症状は、最初はステップ1でタッチポイントの作成者によってコード化されたものです。
これらのことから、オートノミックマネージャーがナレッジをどのように使用するか、そしてオートノミックマネージャーにとってナレッジがいかに重要かについて、基本的な次の2つを導くことができます。
- オートノミックマネージャーは、自分にできることを、ナレッジで『表現』します。この記事での例では、オートノミックマネージャーは症状を認識できることを示しているだけではなく、症状ナレッジとしてコード化された、特定な条件に関する特定な症状を認識できることも示しています。
- オートノミックマネージャーは、標準形式の新しいナレッジをナレッジソースからロードすることによって、自分の機能を『拡張』します。この記事の例では、タッチポイント作成者などが標準形式で生成した他の症状も、オートノミックマネージャーはナレッジソースからロードすることができます。これら他の条件に関する追加的症状のナレッジがアクティブになると、オートノミックマネージャーは、リソースの稼働中に発生する、そうした症状を認識できるようになります。
まとめ
オートノミックコンピューティングアーキテクチャーでは、オートノミックマネージャーが使用するような、あるタイプのナレッジに注目します。このナレッジは、オートノミックマネージャーに何ができるのかを表現し、またオートノミックマネージャーができることを拡張します。このモデルに当てはまるタイプの、よく知られたナレッジとして、症状や、変更リクエスト、変更計画などのナレッジがあります。
ナレッジは、標準形式でキャプチャーされ、ナレッジソースにデプロイされます。そうするとナレッジソースの中のナレッジは、オートノミックマネージャーやマニュアルマネージャーが、オートノミックな自己管理機能を行うために使えるようになります。これはすべて、オートノミックマネージャーができることをナレッジによって表現、拡張できる、という考え方に関係しています。
『オートノミックコンピューティングの最新動向』の今後の記事では、他のアーキテクチャー構成ブロックを調べ、それらを組み合わせることによって自己管理のオートノミックシステムが構成できることを解説して行く予定です。
参考文献
著者について  | 
| | Brent A. MillerはIBMのオートノミック・コンピューティング・アーキテクチャー・チームの一員であり、自己修復アーキテクチャー開発のリーダーです。IBMでの勤務は21年にわたり、プリンター開発、モバイル・クライアント、モバイル・ソフトウェア、パーベイシブ・コンピューティングなどに従事してきています。 |
記事の評価
| 
