レベル: 初級 Nicholas Chase (nicholas@nicholaschase.com), President, Chase and Chase, Inc.
2004年 2月 17日 オートノミック・コンピューティングを、コンピューターが生命・感覚を持つ生物のように振る舞わせるための過程であるとするなら、開発者としてのあなたは、製品やシステムが適切・確実に稼働するように面倒を見る医者と言えるでしょう。懸念領域があればそれを診断し、必要な処置をとって適切に機能するようにしなければなりません。この記事ではオートノミック・コンピューティングを皆さんの製品に統合するまでのロードマップを説明します。
オートノミック・コンピューティング：簡単な復習
つまるところ管理者は、システムが自分で処理できるような繰り返し作業のために、時間を使いすぎているのです。例えば、会計部のミッシェルという女性が新しい会計ソフトのクライアントをインストールする場合を考えると、ミッシェルがオペレーティング・システムや実行環境について知ったり、ドライブやRAMの空き等についてチェックしたりする必要はないはずなのです。インストーラーが彼女に代わってチェックを行えるはずであり、さらに望ましくは、問題がある時には続行前に解決してしまえるはずなのです。
さらに、データベースのログファイルでドライブが一杯になりそうならば、管理者が目を光らせて手動でドライブを用意したりしなくても、システムが新しいドライブを用意できるはずです。国際ハッカー協議会があなたのサーバーを攻撃対象にした際にも、そのサーバーは、完全にシャットダウンしたりせずとも自身を守れるはずです。
オートノミック・コンピューティングの領域は当然ながらまだ幼児期にありますが、上のような例の多くでは、アプリケーションをより自律的（autonomic）にするためのツールは既に世の中に存在し、使えるようになっています。この記事ではアプリケーションやシステムをより自己完結的にするために、現在どんなものが使えるのかを説明します。
熱狂をかき分けて
新しい技術が到来する時にはいつもそうですが、記事や論文を書くための対象として考える人は山のようにいても、実際にその技術をどう使うかについては誰も知らない、という期間があるものです。そしてその技術が興奮すべきものであればあるほど、それについて語る人も多くなります。オートノミック・コンピューティング環境は非常に興奮に満ちたものです。システム管理者が行う日々の作業の大部分を肩代わりしてくれるシステムという宣伝文句から、話だけは活発に行われています。ただ、みんなが知っているのは究極的な目標だけ、と思うとちょっと怖くなります。
幸い、複雑すぎるから、あるいは強力すぎるからといって、尻込みする必要もないのです。これは感覚を持って世界征服をたくらむシステムを構築するようなものではないのです。まあ、近い将来にはない、という意味ですが。
いや実はここでは、システムがその機能を遂行し、（ビジネス上の目的に沿って）その機能だけを遂行する世界への、最初の幼い一歩についてお話ししようとしているのです。これはオートノミック・コンピューティング環境に関する重要な側面なので、改めて言いましょう。ビジネス・ルールを変えるのではなく、単にビジネスがルールを実行する方法を変えようというのです。
 |
オートノミック・コンピューティング・ツールキットをダウンロードしてください
本物のオートノミック・コンピューティング・ツールやその技術、サンプル、デモなどに触れるためにオートノミック・コンピューティング・ツールキットをダウンロードしてください。このキットに用意されたツールを使うことで、システム全体をより自己修復性を持ったものにするための一歩として、既存アプリケーションの中でオートノミック・コンピューティング機能の実装を始めることができます。オートノミック・コンピューティング・ツールキットのツールや技術は問題の特定方法を改善する他、ソフトウェア維持管理を単純にし、システム管理を共通化します。またこうしたツールや技術を使うことで、システム設計にオートノミック・コンピューティングの原則を適用できるようにもなります。
|
|
オートノミック・コンピューティング・ツールキット（参考文献）に用意されているツールは、（システム・コンポーネントが単に思考するのにとどまらず）より良い思考のためにお互い会話するようなアーキテクチャーに向かっての最初のステップです。
オートノミック・コンピューティング・アーキテクチャーはいくつかの核となる機能から成り立っています。
- ソリューション・インストールと展開のための技術
- 共通システム管理
- 問題判別
- オートノミック・マネージメント
- プロビジョニングとオーケストレーション
- 高度な分析
- ポリシー・ベースの管理
- 異機種間ワークロード管理
ではこれから目標のそれぞれについて説明し、そうした目標に向かうためにはどうすれば良いかを示すことにします。
ソリューション・インストールと展開技術
あなたが最後に大がかりなソフトウェア・パッケージをインストールしたのはいつのことでしょう？ ハードウェア要求を満たしていると判定するまでどのくらいかかりましたか？ 前提アプリケーションに関してはどうでしょう？ 追加のパッケージをダウンロードしてインストールする必要がありましたか？ そのインストレーションで、既にインストールされているソフトウェアを壊しましたか？ ゴタゴタを片づけるのにどのくらい長くかかったでしょうか？
インストール作業がただインストールするだけで良く、そのソフトウェアをどこにインストールすべきか、前提としてインストールしておくべきソフトウェアはどんなものか、また既存のインストール済みソフトを壊さないためにはどうすべきか等々をインストーラーの判別に任せれば良いとしたら素晴らしいと思いませんか？
こうした考え方が、オートノミック・コンピューティングの目指すソリューション・インストールと展開の概念の背景なのです。
一般的にこれは次のように行われます。あなたはソフトウェア・パッケージをインストールすることにします。このソフトウェアは実際のコードまたはソフトウェアの成果物と、内容物やインストール前に満たすべき前提条件は何かを記述したディスクリプター・ファイルから構成されています。この、ディスクリプター/成果物パッケージは導入ユニット（Installable Unit）と呼ばれ、ソリューション・モジュールの中でグループ化されます（図1）。
図1.ソリューション・モジュール
この場合では、全体としてのソリューション・モジュールは第２のソリューション・モジュールと、独立した導入ユニットを含んでいます。
ソフトウェアをインストールする前に、インストーラーはディスクリプターを読み取り、それまでにインストールされたソフトウェアとハードウェアをチェックして、全ての前提条件が満たされているかどうかを判定します。満たされている場合にはソフトウェアはインストールされ、その情報はデータベースに追加されます。満たされていない場合には自律性の程度に応じて、インストーラーは管理者に警告を発したり、あるいは必要なソフトウェアをダウンロード、インストールしたり、追加ハードウェアをあてがったり、代替サーバーを選んだりすることで問題を解決します。
このための最初の一歩は、オートノミック・コンピューティング・ツールキットにあるソリューション導入と展開技術のツールを使うことで実現できます。オートノミック・コンピューティング・ツールキット はAPIと、こうした概念を製品の中に統合するためのツールを提供するものです。オートノミック・コンピューティング・ツールキットにはまた、InstallShield for MultiPlatformsやZeroGのInstallAnywhere等のインストーラー型製品が、こうしたツールをどのように使ってソフトウェアのインストール・プロセスを改善しているかを説明する、実際的なシナリオも入っています。
共通システム管理
ソフトウェアがインストールされたら、そのソフトウェアを管理する必要があります。理想的なオートノミック・コンピューティング・システムでは、全てのアプリケーションは単一の監視点で管理されますが、これには２つの利点があります。一つは管理者が様々なツールに関して知っている必要がなくなることであり、もう一つは全ての情報が単一の環境内にあるので、究極的には単一のシステムで管理できるという点です。後ほど、これによってポリシー・ベースの管理ができるようになることを説明します。
オートノミック・コンピューティング・ツールキットは既に共通システム管理のための環境を持っています。Integrated Solutions Consoleはブラウザ・ベースの環境であり、これを使うことで管理者が全ての管理を一カ所から操作できるようになります。Integrated Solutions ConsoleはPortal Toolkit for WebSphere® Studioに基づいているので、管理機能はポートレット（portlets）、すなわちコンポーネントを通して単一システム内で操作できます。管理者が新しいソフトウェアをインストールすると、その管理機能が（ヘルプ・ファイルなども）共通管理システムに追加されます。
問題判別
さて、オートノミック・コンピューティング・アーキテクチャーの概念そのものは、自己構成、自己修復、自己最適化、自己防御といった機能を持つシステムを作ることにあります。そのためにはシステムは問題を認識し、原因を特定し、またその問題解決のために適切な動作を行える必要があります。そのために最も合理的な方法としてはログを利用するものでしょう。
アプリケーション開発者であれば、ログを通常何に使うかを知っていると思います。ログは、ユーザーが問題を見つけた時にその問題の場所を追跡するために使うのです。ログはたいていの場合、一般的に使われることは考えられていません。実際、大部分の場合には、アプリケーション・ログはただ一人の人、アプリケーション開発者しか対象にしていません。アプリケーション開発者であれば、システムが予期せずシャットダウンしてしまった場合には「unexpected termination」と言っているイベントを探すのだということを知っていますし、あるいはシャットダウンが「unexpected quit」によるものなのか、さらには「助けて！ 猿が尖った棒を持って逃げた！」ことによるものなのかが分かるのです。
つまり、自動化したシステムがログファイルを使って問題を特定するためには、ログは共通フォーマットを持っている必要がある、ということです。
そのフォーマットがCommon Base Eventsフォーマットであり、これはXMLベースのボキャブラリです。Common Base Event V1.0.1では次の11種類のシチュエーション・カテゴリーを定義しています。その11種類とはStartSituation、StopSituation、ConnectSituation、ConfigureSituation、RequestSituation、FeatureSituation、DependencySituation、CreateSituation、DestroySituation、ReportSituation、AvailableSituationですが、さらに製品固有の要求をサポートするためにOtherSituationカテゴリーも用意されています。アプリケーションがこのフォーマットでイベントを出力すると、オートノミック・コンピューティング・システムはその情報を使うことによって、問題があったのかどうか、またいつ問題があったのかを特定することができ、イベントをシチュエーションに相関させることで、どう対応するかを決めることができるのです。
リスト1. 単純化した例
Application server can't connect to the database
+ Application server can ping database server machine
= Database is down
|
そうするとシステムは症状データベースを調べ、データベースがダウンしている場合にはリスタートを試み、管理者に問題が起きたことを知らせます。（症状データベースもイベントをシチュエーションに相関させる役割を果たします。）
では既にアプリケーションがあり、イベントをCommon Base Eventsのフォーマットで出力しない場合にはどうでしょう。そのアプリケーションはオートノミック・コンピューティング・システムに統合できないということになるのでしょうか。この場合には２つの選択肢があります。アプリケーションを変更するか、あるいはレガシー形式のイベントをCommon Base Eventsのフォーマットに変換するGeneric Log Adapterを使うのです。オートノミック・コンピューティング・ツールキットの一部であるAdapter Rule Builder ToolはWebSphere Studio Application DeveloperやEclipseプラットフォームと統合するものですが、これを使うことによって、オートノミック・コンピューティング・システムで理解できる形式へのログ変換のためにGeneric Log Adapterが使うルールが生成できるようになります。
オートノミック・コンピューティング・ツールキットにはLog and Trace Analyzerという、もう一つ別のEclipseベースのツールがあります。このツールには、色々なアプリケーションのログからのイベントを見るためのグラフィカル・インターフェースが用意されています。イベントがCommon Base Eventsフォーマットの場合にはイベントの相関ビューを見ることもでき、こうしたイベントの発生シーケンスを特定することもできるのです。システム開発者やサポート・スタッフには歓迎すべき改善点と言えるでしょう。
オートノミック・マネージメント
オートノミック・コンピューティング・システムがイベントやシチュエーションを発見、制御するためには、処理すべきイベントを探して常時システムを監視している制御ループを使います。この制御ループは図2にあるようなオートノミック・コンピューティングの参照アーキテクチャーで定義されます。
図2.制御ループ
制御ループはイベントを検出し、処理するシステムです。このプロセスには4つのステップがあります。
-
監視: 最初にシステムは、（ログファイルであれ、メモリ内プロセスであれ）何らかのセンサーが検出するイベントを探します。システムはナレッジ・ベースを使って、何を見ているのかを理解します。
-
分析: イベントが起きると、ナレッジ・ベースはそれに対してどうすべきかの判定に役立つ情報を取り込みます。
-
計画: イベントが検出、解析されると、システムはナレッジ・ベースを使ってそのイベントをどうすべきかを判定する必要があります。症状データベースに情報があるかも知れず、中央ポリシー・サーバーが、行うべき動作を決めるかも知れません。
-
実行: 計画が策定できると、既存のナレッジ・ベースで規定されている通り、実際に動作を実行するのはエフェクターです。
制御ループは単一の概念的プロセスですが、単一の製品で実行する必要があるというわけではありません。例えばIBM® Director製品と東芝のClusterPerfect製品とが制御ループを共用し、Directorが監視と分析プロセスを実行し、ClusterPerfectが計画と実行ステップを実行する、というようなことができます。
オートノミック・コンピューティング・ツールキットにはAutonomic Management Engine (AME）があり、こうしたステップをすべて実行してくれます。当然ながら、AMEはその製品と通信ができる必要がありますが、これは思ったほど複雑なものではありません。適切なリソース・モデルがありさえすれば、AMEはどんな製品とも通信することができます。リソース・モデルは、自分が何を探しているのか、例えばログのエントリーを探しているのか、特定なプロセスの状態を探しているのか、といったことをAMEに対して伝えるのです。
オートノミック・コンピューティング・ツールキットのResource Model Builder Toolを使って自分独自のリソース・モデルを作ることもでき、それをWebSphere Studio Application DeveloperやEclipse IDEに統合することもできます
プロビジョニングとオーケストレーション
オートノミック・コンピューティング・アーキテクチャーは今のところまだ開発の初期段階ですが、その応用領域として最も効果的なものがプロビジョニング（provisioning）、つまり古いドライブが死んだことによる新しいドライブの置き換えであれ、従業員に大量のマシンを用意する場合であれ、プロビジョニングの領域だと言えるでしょう。完全にオートノミックなコンピューター・システムでは、新しい容量を準備すべきなのはいつか（あるいは逆に割り当て解除すべきなのはいつか）を予測し、自動的にそれを行います。
実際にはこれは全く別の２つの問題なのです。一つ目はプロビジョニングという概念そのものです。今現在では、既に使われているマシンを使って容量を追加するにはどうすべきかは、管理者が決める必要があります。そして管理者が新しいドライブをマップしたり、ひどい場合には物理的にハードウェアをいじったりするのです。場合によってはサーバーを別の場所に移動する必要もあるかも知れません。物理的には大したことのない作業、例えばオペレーティング・システムやソフトウェアをインストールするような作業であっても、システムが複雑になってくると人為的なミスが発生しやすくなります。
自動プロビジョニングツール（例えばIBM TivoliR Provisioning Manager）を使えば、管理者はそうしたプロセスを自動化することができます。これは、管理者の知識を反映して明確に定義した繰り返し可能操作を、必要に応じてツールが操作できるようにすることで可能になります。
ではさらに自動化するにはどうすべきでしょう。行うべき操作を管理者が単純に定義するだけで、人の介在無しにシステムが必要に応じて確実に動作してくれるものとしたらどうでしょう。この場合にはオーケストレーション（orchestration）をしてくれる製品が必要になってきます。基本的に、オーケストレーション製品（例えばIBM Tivoli Intelligent ThinkDynamic Orchestrator）はシステム全体を監視し、オートノミック・コンピューティングの概念を使って、いつ必要な動作を行うべきかを判断します。その上で管理者、またはビジネス・ポリシーで定められた定義に基づいた、適切な動作を行います。
高度な分析
ここまでで気が付いたかも知れませんが、こうしたプロセスにはかなり複雑な論理が絡んでいます。（オートノミック・コンピューティング・ツールキットに付属している）Java技術での実装の場合であれば、人工知能的な機能を持っているJavaBeansコンポーネントを使うことになるでしょう。
まだ初期段階ではありますが、オートノミック・コンピューティング・ツールキットは究極的にこうした機能を持つものになるでしょう。最終的にこれがどう動くのかの感覚をつかむには、現在IBMのalphaWorks（参考文献）で使用できる新興の技術ツールである、Agent Building and Learning Environment (ABLE) 2.0を見てみるのがよいでしょう。ABLEには各種のソースとの間でデータを読み書きするData BeansのようなAbleBeansや、決定木（decision trees）やBayesian推論のような推論を実装するLearning Beans、前向き推論(forward chaining)やファジー論理beansのようなRules Beansなどが用意されています。AbleBeansはルールを使ってAbleAgentsに組み込むことができます。例えばABLE 2.0にはいくつかのエージェントが付属しています。例えばバック・プロパゲーションを使ってデータを分類するニューラル分類子や、init、process、timer等を動作定義するルール・ブロックを持った一連のルールを含む、ルール・エージェントなどです。
ポリシー・ベースの管理
これだけさまざまな推論が絡んでいると、とても手に負えなくなるように思えるかも知れませんが、全く逆なのです。すべての決定は設定されたポリシーに基づくものであり、完全にオートノミックなシステムでは、こうしたポリシーはシステム全体に渡って調整されるのです。例えばリソースへのアクセスにTivoli Access Managerを使うことを考えてみてください。このナレッジ・ベースを使ってアクセスに関する全ての決定を行うのであれば、単一の場所からビジネス・ルールを設定することができるのです。
さらに、そのビジネス・ルールが一カ所で検証できるのです。容易な管理はシステム管理上で有利なだけではなく、株主や監査機関のためにポリシーを承認する必要のあるCEOのような利害関係者にとっても有利なものになります。
異機種間ワークロード管理
さて、ここまでやって来ました。導入ユニットを使ってアプリケーションをインストールし、Integrated Solutions Consoleから管理し、Autonomic Management Engineを使って問題を監視、解決しているわけです。これで終わりなのでしょうか。
いえ、実はそれだけではないのです。オートノミック・コンピューティング・システムの究極的な目標は、全てが最初から最後まで追跡されるシステムであり、単に問題の解決にとどまらず、パフォーマンス向上のために常に最適化されているシステムなのです。簡単に言えば、ビジネス・ワークロード管理だということです。
この領域もまたオートノミック・コンピューティング・ツールキットが将来成長すると思われる分野です。こうした機能をどのようにアプリケーションに組み込むべきかは現在のところ、IBM alphaWorks（参考文献）で使用可能なBusiness Workload Manager (BWLM) Prototypeを使って評価することができます。この管理システムではApplication Response Management (ARM) APIを利用することができます。ARMを使うとソフトウェア・コンポーネントにタイミング機能を組み込むことができるので、BWLMはシステムがどのくらい速く実行しているかを判断することができ、必要があれば変更を推奨してくるのです。
今後のステップ
システムが自己構成、自己修復、自己最適化、自己防御といった機能を持つようにする技術は、既にいつでも使えるようになっています。IBMのオートノミック・コンピューティング・ツールキットをダウンロードして、オートノミック・コンピューティングの核機能を使うアプリケーションの作成作業を開始してみてください。ソリューション・インストール、共通システム管理、問題判別、オートノミック・マネージメントなどの機能はオートノミック・コンピューティング・ツールキット自体の一部分です。その他、例えば高度な分析、ポリシー・ベースの管理、異機種間ワークロード管理などには別途ソフトウェアが必要になります。
ただ、どう見るにせよ、またどのように構成するにせよ、オートノミック・コンピューティングはもはや単なる一時的な熱狂の段階ではなくなっているのです。
参考文献
著者について | | | Nicholas ChaseはStudio Bの作者であり、Lucent TechnologiesやSun Microsystems、Oracleそれにthe Tampa Bay Buccaneers等の会社でWebサイト開発に従事してきました。彼は高校の物理の教師として、また低レベル放射性廃棄物施設の管理者として、オンラインSF雑誌の編集者、マルチメディアのエンジニア、Oracleのインストラクターとしても働いてきています。最近ではフロリダ州クリアウォーターにある、インタラクティブ・コミュニケーション関係の会社の最高技術責任者でもありました。XML Primer Plus (Sams刊）を含めて5冊の著書があります。読者からの意見を歓迎しています。連絡先はnicholas@nicholaschase.comです。 |
記事の評価
| 
