レベル: 初級 Brent Miller (bamiller@us.ibm.com), Senior Technical Staff Member, IBM
2005年 6月 14日 オートノミック・コンピューティング・アーキテクチャーは、自己管理のITシステムを構築するための基礎を提供します。自己管理のオートノミック・システムは、自己構成（self-configuring）、自己修復（self-healing）、自己最適化（self-optimizing）、自己防御（self-protecting）という特性を示します。これらの特性は、その頭文字を合わせて、よくCHOPと呼ばれます。この記事では、このセルフCHOP属性に関して議論します。特に、CHOPのそれぞれが独立ではないこと、また自己管理のオートノミック・システムが、CHOP機能をどのように統合することで実現されているのかを重点に解説して行きます。
はじめに
これまでの『オートノミック・コンピューテイィングの最新動向』では、日本や標準化団体、学術界など、様々な領域でのオートノミック・コンピューティングの採用の動きについて取り上げました。このコラムは、オートノミック・コンピューティング・アーキテクチャーの様々な側面、つまりアーキテクチャー的な構成ブロック（オートノミック・マネージャーやタッチポイント、ナレッジ、など）や、アーキテクチャー的な考慮事項などを検証するシリーズの第1回です。いつもと同様、『オートノミック・コンピューテイィングの最新動向』は、オートノミック・コンピューティングの世界で起きていることの最新情報を、事実と意見とを取り混ぜて紹介します。
今月は、オートノミック・コンピューティング・アーキテクチャー・シリーズの最初として、self-CHOPを議論するところから始めます。self-CHOPの各属性は、自己管理のシステムを適切に記述するものですが、各属性は相互排他的ではありません。
ここではまず、self-CHOPの概念と、CHOPの各機能が、完全に独立したものではないことを説明します。その後で、CHOPの概念が、統合されたものであることを示す例を挙げたいと思います。
「self-CHOP」とは何か
CHOPという表現は、構成（Configure）、修復（Heal）、最適化（Optimize）、保護（Protect）の頭文字を合わせたものですが、これはオートノミック・コンピューティング技術の基本的な側面を表しています。オートノミック・システムは、これらの側面の、1つ、あるいはそれ以上に対応するように作られています。図1は、こうした概念を説明したものです。
図1. self-CHOP
『オートノミック・コンピューティングのアーキテクチャーに関するブループリント』（参考文献）では、self-CHOPの属性を次のように説明しています。
オートノミックの制御ループは、同じ基本パーツから構成されますが、それらパーツの機能は、広く考えて、4つの埋め込み制御ループ・カテゴリーに分けられます。これらのカテゴリーは、システム・コンポーネントの属性と考えることができ、次のように定義されます。
- 自己構成は、変化する環境に動的に適応することができます。自己構成コンポーネントは、ITプロフェッショナルが提供するポリシーを使って、環境中の変化に動的に適応します。こうした変化の中には、新しいコンポーネントのデプロイや既存コンポーネントの削除、システム特性の動的変化などが含まれます。動的な適応によって、ITインフラの強さや生産性が継続されることが保証され、ビジネスの成長や柔軟性につながります。
- 自己修復は、障害を発見、診断し、それに対して応答します。自己修復コンポーネントは、IT環境を中断することなく、システムの動作不良を検出し、ポリシーに基づく修正動作を起動します。修正動作には、製品が自分自身の状態を変更することや、環境中の他のコンポーネントに変化を起こさせることなどが含まれます。日々のオペレーションにおいて失敗が発生しにくくなるため、ITシステム全体としての耐性が向上します。
- 自己最適化は、リソースを監視し、自動的に調整します。自己最適化コンポーネントは、エンドユーザーやビジネス要求に合うように、自分で自分を調整します。調整動作には、動的に変化する負荷に対応して全体的な利用率を改善するためのリソース再割り当てや、ある特定なビジネス・トランザクションがタイムリーに完了するように保証することなどがあります。自己最適化によって、システムのエンドユーザーとビジネスの顧客の両者に対して、高水準のサービスを提供できるようになります。
自己最適化機能が無いと、割り当てられたコンピューティング・リソースの全てをアプリケーション利用していない場合に、サーバー機能の余裕を優先度の低い作業に振り向けることができません。この場合には、顧客は各アプリケーションの最大要求に合わせて、各アプリケーション用に別々のインフラを購入し、維持管理しなければなりません。
- 自己防御は、いかなるところからの脅威であっても、それを予測し、検出、特定し、それに対する防御を行います。自己防御コンポーネントは、悪意の振る舞いが発生した場合にそれを検出し、自分自身の脆弱性を改善するための修正動作を行います。悪意の振る舞いには、無許可アクセスや無許可使用、ウィルスへの感染や他への感染拡大、サービス不能攻撃などが含まれます。自己防御機能によって、ビジネスは一貫したセキュリティー・ポリシーやプライバシー・ポリシーを強制できるようになります。
システム・コンポーネントがこうした属性を持つようになると、現在ではITプロフェッショナルが行っている、ITインフラを構成、修正、最適化、防御するためのタスクを、自動化できるようになります。
自己管理のオートノミック・システムを、こうしたself-CHOP属性の面から考えることは重要です。このように考えることによって、様々なself-CHOP機能を果たすオートノミック・マネージャーを構築できるのです。ただし、self-CHOPの各機能は、必ずしも図1のように明確な境界を持っているとは限りません。これから説明するように、それぞれの機能が重複する場合もあるのです。
CHOPの相互依存関係
先に触れたように、自己修復オートノミック・マネージャーは、システム中の障害を検出し、問題を軽減するための修復動作を行うことができます。こうした修復動作は、オートノミック・マネージャーが管理しているリソースを再構成するための一連のオペレーション、という形を取る場合もあります。例えば、オートノミック・マネージャーは、誤ったメモリー利用によって起きた問題を修正するために、リソースの最大スタック・サイズを変えるかも知れません。こうした点から見ると、自己修復のオートノミック・マネージャーは、望むべき修復動作を達成するためにリソースを再構成することによって、自己構成機能を行っている、と考えることもできます。
また、これも先に書いた通り、自己最適化オートノミック・マネージャーは、変化する負荷に対してリソース利用を改善するために、リソースを再割り当てするかも知れません。こうした、自己最適化のための変更も、オートノミック・マネージャーが管理するリソースを再構成することで実現されるかも知れません。例えば自己最適化オートノミック・マネージャーは、クラスターに対してサーバーの追加削除を行うことによって、サーバー・クラスターを再構成することもあるのです。
このように、自己修復管理や自己最適化管理には、自己構成機能（そして自己防御も）が含まれる場合もあることが分かります。実際、ITリソースの修復や最適化、防御に関連したアクションが、構成オペレーションによって行われる、ということも頻繁にあるものです。自己構成自体は非常に幅広い概念であり、（例えばシステム・コンポーネントの追加削除を行うなど）変化する環境に対して動的に適応することですが、多くのself-CHOP機能を実現する上で、自己構成は非常に基本的なものでもあるのです。
self-CHOP機能のそれぞれは、他の面からも相互に関連しています。次のような例を考えてください（皆さんも、他の例を考えられるはずです）。
- 自己防御のオートノミック・マネージャーは、セキュリティーの漏れを検出し、その漏れを無くすための動作を行います。これは、システム中の問題を修正するための形式の1つと考えることもできます。従って、自己防御の動作であると同時に、自己修復の動作であるとも考えられます。
- 自己修復と自己最適化を組み合わせることによって、全体的なビジネス耐性を向上することができます。システム障害を修正するオペレーションと、負荷平衡のためのオペレーションとを融合させることによって、より可用性の高いシステムにすることができます。
CHOPの自己管理機能が、統合されたものであることを示すシナリオを、さらに説明してみましょう。
統合された、self-CHOPシナリオ
『オートノミック・コンピューティングのアーキテクチャーに関するブループリント』に書かれている通り、また図2でも分かる通り、オートノミック・マネージャーは、監視（monitor）、分析（analyze）、計画（plan）、実行（execute）という機能を持っています。
図2.オートノミック・マネージャーの詳細
図2は、オートノミック・マネージャーが、4つの制御ループ機能のうち、一部しか持っていない場合もあることを示しています。そうした、部分的なオートノミック・マネージャーの例を考えてみましょう。図3は、監視と分析機能だけを行う部分的な自己修復オートノミック・マネージャーと、計画と実行機能のみを行う部分的な自己構成オートノミック・マネージャー、という2つの例を示しています。
図3. 自己修復と自己構成のオートノミック管理機能を統合する
最初のオートノミック・マネージャーは、管理対象リソースからのデータを監視し、そのデータを相関させて症状を生成再現します。次に、この症状は分析され、オートノミック・マネージャーは、管理対象リソースに対して何らかの変更が必要だと判断します。この変更要求は、『変更リクエスト』ナレッジという形で捉えられます。この変更リクエストは、計画機能を行う部分的自己構成オートノミック・マネージャーに渡され、そこで変更計画が作られます。この計画は次に、このオートノミック・マネージャーの実行機能によって実行に移されます。このシナリオが、先に紹介した、オートノミック管理機能の自己修復、自己構成の統合の詳細なのです。
同じようなシナリオが、自己防御と自己構成の統合についても成り立ちます。図3で、最初のオートノミック・マネージャーが、自己修復のオートノミック・マネージャーではなく、自己防御のオートノミック・マネージャーであったと考えてみてください。こうしたオートノミック・マネージャーは、監視機能と分析機能を使って、セキュリティーの漏れがあること、そして漏れを無くすためのパッチがあることを判断します。自己防御のオートノミック・マネージャーは、セキュリティー・パッチのインストールを指示する変更リクエストを生成し、このリクエストが、今度は自己構成のオートノミック・マネージャー（一例としてIBMには、Solution Installation for Autonomic Computingという技術があります。参考文献）に渡されます。すると次にこのマネージャーが、必要なセキュリティー・パッチをインストールするための変更計画を生成し、実行するのです。
IBMのCommon Base Eventフォーマット（WSDM（Web Services Distributed Management）のイベント・フォーマットの基礎となっており、OASIS WSDM 1.0仕様の中に取り入れられています。参考文献の項を見てください。）を利用すると、管理対象リソースが遭遇する状況を共通フォーマットで表現できます。この、状況情報は、イベントとしてオートノミック・マネージャーに送られ、これらのイベントは、オートノミック・マネージャーの監視機能の中で受信され、相互関係を調べられます。
Common Base Eventによって表現される状況の1つが、接続状況（成功したか不成功だったかの状況を含むもの）です。例えば、管理対象リソースが、高速で連続的にCONNECT_UNSUCCESSFULイベントを生成したと考えてください。自己修復のオートノミック・マネージャーにとっては、これはリソース（例えばデータベースなど）への接続に問題があるための症状と考えられ、従ってリソースが利用できないため再起動が必要なのかも知れません。ところが自己防御のオートノミック・マネージャーにとっては、そのような連続イベントは、（例えばサービス不能攻撃の開始など）大量の無許可アクセス試行だと考えられるかも知れません。もちろん、本当の状況は、どちらか、あるいはどちらでもないかも知れません。他に利用可能な情報をイベント状況情報と関連させ、（例えば、自己修復と自己防御のオートノミック・マネージャーを協調させるようなオーケストレーティング・オートノミック・マネージャーによって）実際に何が起きているか、どんなアクションが必要なのかを判定する必要があるかも知れません。しかし、ここでの要点は、監視されたデータが、自己管理のオートノミック・システムでのself-CHOPの、複数の面に利用されるという点なのです。
まとめ
self-CHOPは、自己管理のオートノミック・システムの、重要な属性を記述するものです。self-CHOPは、オートノミック・コンピューティングの様々な側面を特徴付けるために便利なものですが、その4つの側面を独立したものと考えるべきではありません。この記事で取り上げたように、4つの面を統合して考えた方が、自己管理のオートノミック・システムを全体的に捉えることができるのです。
今後の記事では、こうしたself-CHOPの概念の上に構築されたオートノミック・コンピューティング・アーキテクチャーの、他の側面を取り上げて行く予定です。
謝辞
IBMのオートノミック・コンピューティング製品計画チームのマネージャーであり、私の同僚でもある、Jim Crosskeyに感謝します。また、この記事を書く上でのアイデアや助言を与えてくれたIBMの同僚、Christine DraperとThomas Studwell、そしてJim Whitmoreにも、特に感謝します。しかし何よりも感謝すべきことは、彼らが素晴らしいアーキテクチャーを開発してくれたからこそ、こうした有益な記事が書けた、という点でしょう。3人は、それぞれ自己構成、自己最適化、自己防御を設計した中心的アーキテクトであり、私は自己修復を担当しています。CHOPの概念をまとめられたのは、4人の協力の成果と言うことができます。
参考文献
著者について  | 
| | Brent A. MillerはIBMのオートノミック・コンピューティング・アーキテクチャー・チームの一員であり、自己修復アーキテクチャー開発のリーダーです。IBMでの勤務は21年にわたり、プリンター開発、モバイル・クライアント、モバイル・ソフトウェア、パーベイシブ・コンピューティングなどに従事してきています。 |
記事の評価
| 
