レベル: 初級 developerWorks staff (dwinfo@us.ibm.com), Editorial Staff, IBM
2004年 11月 16日 今回のインタビューに登場するのは、IBMにおけるオートノミック・コンピューティングのディレクターであるRic Telfordです。オートノミック・コンピューティングの現状と次世代オートノミック・システム開発に関する課題について、developerWorksがRicにインタビューします。
IBMにおけるオートノミック・コンピューティングのディレクターであるRic Telfordは、オンデマンド・コンピューティングやユーティリティー・コンピューティング、それにセキュリティーなどを含めて、新興ビジネス開発や新技術の展開に関して長年の経験を持っています。
developerWorks： あなたの肩書きは「Director of Architecture and Technology for Autonomic Computing」となっていますが、具体的にはどんな領域を対象にしているのですか？
Ric Telford： そうですね・・・。3年ほど前にPaul Hornが言ったように、オートノミック・コンピューティングというのは業界に対して、「武装せよ」という呼びかけなのです。今日のシステムでは、維持や稼働、管理などのコストがコンポーネント自体の実際のコストを大幅に上回っており、しかもその傾向は今後も長期間変わることはないでしょう。ですから私達はコンポーネントやITシステムを、より自己管理できるものにして行く必要があります。
私達にはそれを推進するための組織があり、その中での私の担当範囲はアーキテクチャーと技術、そして標準です。アーキテクチャーは正に、どうすれば私達自身の製品をオートノミックにできるかに関して、IBM内部での展開と仕様策定を進めるためのものです。私達は一連のアーキテクチャーを取り上げ、その中で異機種混在の複数ベンダー環境で基本となっている部分を調べて、標準として提案します。次にオートノミック・コンピューティングの標準を業界全体に渡って普及させるために、業界レベルで活動するのです。
また私はアーキテクチャーや標準化に関する作業をサポートする一環として、私達が提案したものの実装が実際に構築され、開発されるようにする責任も持っています。私達は常に技術を前進させているのですが、これを幾つかの方向から行っています。その一つとして、この技術の多くは研究部門が提供する基礎研究の成果に大きく依存しているので、IBM Researchとの共同プログラムを行っています。大学や学術界全般との共同プログラムもあり、また政府機関とのプログラムもあります。これらの機関や組織が行っている自己管理システムに関する研究の一部に焦点を当てることによって、こうした機関や組織は皆、オートノミック・コンピューティングを業界全体に普及させるという目標に進む上での助けになります。私達にはまた、小さな技術チームもあり、ここでは概念の確認やプロトタイプを行ったり、オートノミック・コンピューティング技術を使うことによる価値や、どのように実際のビジネス上の問題に応用するかを見せるためのデモを行ったりしています。ですから、オートノミック・コンピューティングに向けた使命の中で、私は技術面に対して責任を持っているわけです。
dW： 今、この動きは3年ほど前に始まったと言われましたが、そのきっかけとなるような出来事が何かあったのですか？ 例えば、あるところで複雑さが急激に増したとか、あるいは最近のコンピューター時代の40年、50年という間に少しずつ累積されてきたのですか？ それとも何か、それ以外のものがあったのでしょうか？
RT： 簡潔に答えれば「イエス」です。重要な出来事がありました。それがインターネットの到来です。一方明らかなことですが、ITシステムは過去40年から50年の間に複雑さが増しています。一つの部屋にメインフレームがあって全計算作業はそこで行われ、分散処理されたのは「緑色の画面」（ターミナル）に情報を表示することだけ、という時代があり、これは次の波であるクライアント・サーバー型に比べると非常に単純でした。（クライアント・サーバー型では）まず分散されたサーバーがあり、次にスマート・クライアントがあり、計算機能は企業全体に渡って広がっています。これはつまり、より多くのCPUを管理し、監視し、維持管理その他をする必要がある、ということです。
それでもまだそれらは、サイロ化されたアプリケーションでした。ある種のクライアントを、ある種のサーバーに接続しておく必要があったのです。これを指数関数的に悪化させたのがインターネットです。どんなアプリケーションにも入り込める共通の道ができ、複数ソースから集めたデータのアプリケーションを作ることができる、という期待が生まれたのです。ですから今、例えばオンライン・バンキング・システムに入ると、何が見えるでしょう？ 実は私は、プロファイル・ページを埋めるだけも22種類の異なるデータ・ソースがあるという、ある大きな銀行を知っています（その銀行のホーム・ページではなく、ログインした時に見えるプロファイル・ページ、またはその人のためにカスタム化したホーム・ページのことです。）22種類もの異なるデータ・ソースです！ その一部は昔のバック・エンドにあった独自のバンキング・システムからのもので、一部はIMSデータベースであり、一部はCICSトランザクションを開始し、リレーショナル・ストアーがあり、Oracleのデータがあります。これらを全てまとめ、これほど多くのシステムをつなぎ合わせるという複雑さに対応して、ようやく一つの統一したビューを提供するのです。しかも、この連鎖の中に一カ所でも欠けたところがあれば、アプリケーション全体が実行できなくなってしまうのです。
dW： 特に銀行の件を挙げられたのは面白いですね。私は銀行に行ったり、クレジットカード会社と電話で話したりすると、システムがダウンしていると言われてしまうことが非常に多いのです。
RT： そう、私が好きな例は正に銀行なのです。私が見てきた中で、アプリケーションに対して最も大量にデータが集まるのは銀行だからです。以前のことですが、私の銀行に問題があったことがあります。この銀行はIBMの顧客でもあります。ですから私は彼らの顧客であり、彼らは私の顧客であり、私は彼らと良い関係を持っていました。それを彼らに言うと、彼らはこう言うのです。
「問題が何だったか分かりますか？ 私達は小さなデータベースを持っています。このデータベースがしていることというのは、皆さんのプレファレンス、つまり皆さんのホーム・ページのカスタム化した設定、の保存だけなのですが、そのデータベースが故障したのです。それだけのために、Webサイト全体が全く出なくなってしまいました。データを取りに行ったもののデータを得ることが出来ず、そうしたらアプリケーション全体がクラッシュしたのです。」
正にこうしたことです。あらゆる点に故障の可能性があり、しかもその全てが、問題なく確実に動くようにしなければならないのです。
dW： 問題は分かりました。ではオートノミック・コンピューティングは、どのようにその問題を解決できるのでしょう？
RT： オートノミック・コンピューティングのビジョンは自己管理のシステムです。問題を検出し、防止し、そして自己回復するように、より多くの知性をコンポーネントやシステム管理、アプリケーション自体に取り入れるのです。これは様々な技術の組み合わせです。しかし、つまるところ全ては故障が起きないように、またはシステムが最適でないモードに入り込まないように、またある場合には、本質的に問題の根本原因となりうることが途中で起きないように、確実に適切な設定が行われるようにすることなのです。あるいはもし問題が起きても、アプリケーション全体がダウンしないように、問題を緩和することです。ですから、これ一つで全て解決、という技術はありません。私達が取り組んでいるのは、技術の組み合わせなのです。
自己管理を4つの領域に分けて話しましょう。これは私達の顧客が、自分たちのITシステムを維持したり管理したりするために考える時の領域分けと非常に良く似ています。
自己構成は巨大な問題、つまりシステムが最適化動作するように協調が必要な、ITインフラのあらゆる要素の調整や構成設定を扱います。言い換えると、単にWebサイトが出てこない、ということではなく、応答を返すこと、しかも妥当な応答時間で返すことです。
自己修復は問題をより的確に特定し、オートノミックに根本問題の解析を行い、そして最終的には自己修復を行います。
自己最適化は変化する作業負荷に対応します。今日のシステムで発生する問題の原因の一つは、突発的な作業負荷、つまり作業量の急激な変化です。一つのデータベース内であれ、多数のデータベースにまたがる場合であれ、あるいはWebアプリケーション全体に渡る場合であれ、作業負荷に基づく最適量のリソースを適用したいと誰でも思うものです。作業負荷がどうあったとしても、確実に充分なリソースがあるようにする必要があります。ところが同時に、リソースを無駄にしないようにもする必要があります。今日では、こうして最適化が行われています。多くの人は過剰供給（overprovisioning）と呼ばれることをします。ほとんどの場合は2台のサーバーで充分なのですが、場合によると10台のサーバーが必要になるため、常に10台のサーバーをオンラインにしておくのです。基本的に、ほとんどの時間は8台のサーバーが無駄になります。ですから自己最適化とは、必要とする以上のものを持たず、適正な量のリソースを持つことに尽きます。ですから「最適（optimal）」と言うのです（笑い）。
自己防御システムはインフラを外部の脅威から防ぎ、またウィルスやサービス不能攻撃、不正アクセスなどの潜在的な危険性を検出するために、より良い方法を提供するためのものです。
dW： 自己防御に関してですが、ファイアーウォールやTCPラッパー、tripwireなどはオートノミック要素と言うことができるのですか？ どういう場合に、「これこそ他のIT分野でも使えるものだ」と言えるのでしょう？ それとも、ファイアーウォールなどはオートノミック・コンピューティングの範疇には入らないものなのですか？
RT： その質問は、「今日のセキュリティー機構は、自己防御と同じ意味か」という問題だと思います。
dW： 今日のセキュリティー機構は、今日既に私達が持っている他のものよりは正しい道筋をたどっているのでしょうか？ 例えば、少なくともファイアーウォールはいくらかオートノミックなのですか？
RT： いや、私はそんな風に考えたことはありませんが、ファイアーウォールなどがオートノミックだとは言えないと思います。自己管理の例はあります。今日でも、数多くの様々な技術を挙げることができます。そのそれぞれにおいて、孤立した例ですが、他のコンポーネントや他のアプリケーションに渡って、もっと一般的にしたいような振る舞いの良い例があります。
dW： 私が挙げるような例よりも、そうした例についてお話ししてもらった方が良さそうですね。
 |
MVS：
Multiple virtual storageの略で、メインフレームのオペレーティング・システム。
|
|
RT： 分かりました。オートノミック・コンピューティングで覚えておくべきことは、一方で、決して新しいものではない、ということです。他方、古いことを新しい方法で行います。ですから全て、皆さんがそれをどう見るか、によるのです。皆さんがPoughkeepsie（IBMのExecutive Briefing Centerがある、アメリカのニューヨーク州にある町）に行ってオートノミック・コンピューティングについて語り、そこの人達に対してIT環境に望ましい振る舞いの例を挙げれば、「私達は30年前にMVS™でそれを発明しましたよ」という答えが返ってくるでしょう。その通りなのです。z/OS® がイベントのロギング用に持っていた共通モデルなどが、私達が目指している振る舞いの一部なのです。z/OSの上で実行している場合には、何をログする必要があるか、システムで起きているイベントをどのようにログするか、など、従うべきルールがあります。これによって、アプリケーション・スタックの様々なコンポーネントに渡る様々なイベントを相関させたり、根本原因の解析を行ったりすることが非常に容易になります。zでは問題を特定する機能の一部が不完全ですが、他には無いような、数多くの機能があるのです。
こうした、いわばベスト・プラクティスを生かし、z/OSのような同機種構成で単一ベンダーの環境だけではなく、異機種混合の複数ベンダー環境でも動作するようにしたいと思っています。それこそが正にオートノミック・コンピューティングであり、だからこそ標準が重要なのです。
私達はCommon Base Eventと呼ばれる標準を提出しました。これは概念としては非常に単純なのですが、機能は実に強力なのです。これの基本的な考え方としては、それぞれのインフラの上で行われているイベントがどんなものであれ、つまりSAPアプリケーションであれOracleデータベースであれ、SunのサーバーであれCiscoのルーターであれ、誰もが共通な方法でロギング・イベントを開始すべきだ、というものです。もしこれを全て共通な方法で行うことができれば、私達が定義した共通状況モデルを使うことによって、問題を特定したり、根本原因の解析をしたり、自己修復システムにしたりすることが非常に容易になります。（共通状況モデルは単なる方策ではなく、やはり共通な方法を使ってイベント内で記述する、ある種の意味体系、または意味を持っています。）この一つを決めるだけで、何が起きているかを、誰もが共通な方法で記録できるようになるのです。
ですから、こうした技術の多くは既にポケットに入っているものなのです。自己防御技術のポケットもあります。ファイアーウォールが、開いていないポートに対して入ってくるヒットをログしたら素晴らしいでしょう。こうしてログされたイベントが、私達がオートノミック・マネージャーと呼ぶものに注ぎ込まれたら、さらに素晴らしいでしょう。そうすれば、特定なサービス不能攻撃があったり、インフラへの探索が行われたりしていることと相互関連させることができるかも知れません。ですから、実はこうした技術の組み合わせによって、オートノミック・コンピューティングが可能になるのです。イベントを収集し、次に相互関連させ、そして解析できるという機能は、オートノミック・コンピューティングの背景にある重要な概念の一つです。
dW： この領域での標準化プロセスの進み方には満足していますか？
RT： 満足しています。標準化の世界はオートノミック・コンピューティングにとって非常に重要ですが、この世界で作業する時には、自分の思う標準化の具体化としてアーキテクチャーを動かすスピードと、標準化団体のスピードの釣り合いを取る必要があります。私達は、今後変更する必要があるかも知れない、ということを知った上で、その釣り合いを取ろうとしています。ですから恐らく私達は、まだ標準になっていない一部の機能をログ・トレース・アナライザーに実装したことになるでしょう。そしてCommon Base Eventに関して標準が公開され、もしそれが私達が既に実装したものと異なっている場合には、私達が今日サポートしているものは継続してサポートしますが、同時に100%標準に準拠するようにします。ですから非常に注意して進む必要がありますが、大きな問題ではありません。
dW： IBMは、CiscoやHPなど、業界の他社ともこれを進めていますよね。（オートノミック・コンピューティングが正式な動きとして開始されてから）過去3年間の進歩には満足していますか？
RT： 非常に満足しています。面白いのは、パートナー会社との間にあまりにも様々なことが行われ、皆それぞれ非常に忙しいので、一番困難な問題というのは、実は時間を見つけることであって、関心の無さではありません。業界の人達からの関心は非常に高く、すべきことは非常に多くあります。ですから、一番の問題は、協力しつつ進めるためにどれだけの人と時間をかけられるか、という点なのです。つまりオートノミック・コンピューティングの考え方を進めることに対して、IT業界の他社から関心と期待が高まることはあっても薄れることは全くありません。この技術はエンド・ユーザーにとって有利なだけではなく、ITベンダー自身の助けになるものです。例えば自己修復システムでは、オートノミック・コンピューティングの利点の一つとして、CiscoやIBM、HPなどのカスタマー・サポートへの問い合わせが必要となるような問題の数が減少することになります。ですから、その分の費用が節約できるわけです。
オートノミック・コンピューティングは開発者にとって何を意味するのか
developerWorks： 例えば私が（小規模あるいは中規模の）開発者だとして、私の持っている既存のプログラムにオートノミック・コンピューティングを採り入れたいとしたら、どうすれば良いでしょう？
Ric Telford： ということは例えば、あなたが小さな会社であって、ちょっとしたソフトウェア持っており、それが、例えばWebSphere®やDB2® 、あるいはOracleの上で実行する、金融関係のプログラムである場合、というようなことですね？
dW： そうです。
RT： 一つは、アプリケーションの中で作るイベント、例えばログやトレース情報などのイベントで、Common Base Event （CBE）仕様を強化するようにすることです。そうすると、CBEフォーマットに関係して進化する全てのツール、全てのオートノミック・マネージャー、全てのイベント・コリレーター（event correlators）が、即座に恩恵を提供してくれるようになるからです。
例えばRational®には、Common Base Eventをサポートするログ・トレース・アナライザーを含むツールがあります。そうすると、あなたの製品を購入する顧客がRationalツールを使っていれば、あなたの金融アプリケーションで起きているイベントと、DB2やWebsphereで起きているイベントとを関連付けることができるようになります。また別の例として、中小のソフトウェア会社が提供する多くのアプリケーションには、その前提条件となるようなミドルウェアのスタックがあります。アプリケーションの開発者は誰でも、自分たち独自のデータベースや独自のトランザクション・システム、独自のWebミドルウェアを書くような仕事はやめ、自分たちが最高の力を発揮できるアプリケーションに集中したい、と望んでいるものです。ところが現実には相変わらず、OracleやDB2、WebSphere、Webアプリケーション・サーバーなどをインストールすることを前提とせざるを得ないのです。私達が取り組んでいるものの一つとして最近業界に紹介したのは、オートノミック・コンピューティングのSolution Installationです。これは、私達がインストーラブル・ユニットと呼ぶ標準に基づいて特定なアプリケーションを記述し、また他のインストーラブル・ユニットと合わせて、インストールされているソリューションに関して、顧客が見るビューが一つになるようにするため仕様です。
顧客にとってみると、単にあなたの製品をインストールするだけです。しかしそこに組み込まれた機構がインストールを行い、スタック全体を設定するのです。こうすることで、一連の製品を別々にインストールする場合よりも、より統一されたソリューション・ビューとなります。私達はこの仕様を、私達のパートナーであるInstallShieldとZeroGと共にリリースしました。ですからプログラマーはこの領域も意識して、今後アプリケーションをどのように進化させ、インストーラブル・ユニットとして記述するためにどうすべきかを考えるべきでしょう。
dW： そう聞くと、既存のコードを大量に書き直す必要があるように思いますが？
RT： 良いご指摘です。私達の進め方は、私達が「はぎ取って交換（rip and replace）」と呼ぶやり方で進める一部ベンダーとは一線を画すものです。私達は革命が不可避となる状況を作ることよりも、オートノミック・コンピューティングの進化に対して大いに焦点を当てて来ました。データ・センターをオートノミック・コンピューティングに向かって進化させるために、開発者として、あるいはより一般的に会社または消費者として取るべきステップを記述したものを、私達は持っています。これは開発者にも当てはまるものです。
例を挙げましょう。あなたが今日実際に製品を持っていて、その製品がイベントやログ、トレースなどの情報を特定なフォーマットで書くとしましょう。私達はオートノミック・コンピューティング・ツールキットの一部として、Generic Log Adapterと呼ぶものを用意しています。あなたはCommon Base Eventのフォーマットに合うようにログを書き直す必要はなく、Generic Log Adapterを使って、既存フォーマットをCommon Base Eventフォーマットに変換することができるのです。このアダプターはツールです。既存フォーマットをCommon Base Eventフォーマットにマップして変換するためのルールを定義すると、こうしたイベントを集めて相互の関連付けをしたい人は、誰でもそれができるようになります。変換は、どのようなログ・ファイルに対しても必要に応じて即時（on the fly）処理されます。ですから、全てをすぐに書き直したりする必要はありません。
dW： 最初から適切な振る舞いをするアプリケーションであれば、ということですね？
RT： その通りです。現在、適切な方法でイベントをログしているならば、と言う前提です。私はこれまでのところ、変換ができないような例は、実はまだ見たことがありません。他よりは難しい、という例はありますが、マップできない、という例は見たことがありません。
ソリューションのインストールの領域では、より複雑ですが、ここでも同じことです。最初のステップとして、既存のインストールのラップを行うだけで、書き直しをする必要はありません。しかもSolution Install技術による依存性チェックのような恩恵は、やはり享受できるのです。ですから全ての場合において、オートノミック・コンピューティングの採用を進めるにあたっては、私達が「這い、歩き、走る（crawl-walk-run）」と呼ぶ進み方をするように非常に注意しています。私達はこの技術をちょっと試してみたい、と思う人達のために、這い歩きのステップも用意しているのです。
dW： 例えば、私がオートノミック・コンピューティング・ツールキットを試そうと思ってダウンロードするとします。ダウンロードしたら何をすべきなのでしょう？
RT： 繰り返しますが、どういう人に対して答えるかによって、答えも変わります。先ほどと同じ例を使うと、あなたは開発者であり、大きな会社で使われる製品を抱えており、その会社のバンキング・アプリケーションを開発している・・・ということですか？
dW： それでも良いのですが、まだ使われていない新しい製品を開発している人とか、社内用の製品を開発している人にとって、ということです。
RT： 分かりました。でも、取り上げる例は一つだけにして下さい。それぞれ皆違うのですから（笑い）。
例えば、私が大きな銀行内の開発者であり、その銀行のWebバンキング用にコードを書くとしましょう。顧客がオンラインで支払いをする時に見る画面が私のプログラムで、私はそのプログラムに責任があるとします。そうすると私は、私の会社のIT部門で採用が必要となる、ある標準があるのだ、とそこの人に言うわけです。
独自のアプリケーション・プログラマーを抱えているような大企業、あるいはWebから見えるアプリケーションを開発しているような大企業、その他どんな企業に対しても、内部の標準としてはCommon Base Eventという標準を採用する必要がある、と私達は進言しています。解析が必要なログ・イベントの大部分はミドルウェアではなく、（そしてDB2でもCiscoのルーターでもなく）彼らがコードを書いている、彼ら自身のアプリケーションなのです。一般的によく起きるのは、Javaアプリケーションを書いている人はその人独自のログ・フォーマットを使っており、データベースへのアクセス・コードを書いている人はまたその人独自のログ・フォーマットを使っており、組織内での標準すら無い、と言う状況です。ですからこのツールキットには、標準の定義や汎用のログ・アダプター、そしてログ・アナライザーが入っています。つまり企業内で共通なイベント・フォーマットを標準化し、やがてそれを社内標準として共通のログ、共通のログ解析に基づいた活動ができるようにするための、全てのコンポーネントが入っているのです。
私達が取り組んでいる、ある大きなビジネス情報の会社では、ログを一晩でセキュアな場所に移動するプロセスを実装しようとしています。そうすることで、ログを相互に関連付ける必要が出てきた場合には、物理的に一つの場所に持ってこられるようにするのです。プログラマー・ガイドラインの開発のきっかけとなるのは、こうした動き、つまり共通的なログやトレースの仕方に関する内部的な方針からだと思います。自己修復機能や自己最適化機能が動作するようにするためには、私達が基本的衛生（basic hygiene）と呼ぶものを徹底することが非常に重要だからです。そもそもの問題がどこにあるのかの判定が容易であれば、自己修復を行うこともずっと容易になります。ですから共通的なイベントに対して基本的衛生を適用する、ということが、社内ITグループの開発者として集中すべきことの一つ、と言えるでしょう。
そしてさらに関連して、ツールキットの中にある、他の領域の開発もあります。ソリューション・インストールの領域では、私は様々なグループを対象に標準をとりまとめ、定義し、またインストーラブル・ユニットを作るためのプログラマー・ガイドラインをとりまとめています。
また、ご存じかも知れませんが、Integrated Solutions Consoleというものもあります。これは私達がヒューマン・コンピューター・インタラクション・コンポーネントと呼ぶ領域を作るための共通な方法です。この領域で管理者が管理者のコンソールから、エンドユーザーのインターフェースでコンピューターと出会うのです。これも全てツールキットの中に入っています。これをアプリケーションのどの部分からでも、つまりエンドユーザーのインターフェースからでも、管理者に表示されているインターフェースからでも、始めることがでるのです。
dW： その全てが既にツールキットに入っているのですか？
RT： 全てツールキットに入っています。
dW： でもそこにはツールキット以上のものがあるのですよね？
RT： 開発者がオートノミック・コンピューティングについて考える場合には、様々なものが組み合わさってきます。まず開発者は、自分たちが書いているアプリケーションやプログラムのことを考え、そして、初めから自己管理機能を組み込んでおくためにどうするかを考えます。場合によると、それは私達がツールで提供しているものとは独立で、単にアプリケーションを開発するための方法論にすぎないこともあります。DB2のようなIBMアプリケーションやプログラムと共に出荷されているオートノミック機能の多くは、オートノミック・グループからのコア技術や配布物を必要としたわけではなく、ただ単にDB2内の一群のプログラマーが、「どうすればこのシステムを自己管理にできるだろうか」と考えたのです。そのプログラマー達は、データベースの世界に特有な幾つかの機能を実装し、その結果DB2に必要な管理コストがそれまでの何分の一かになりました。彼らがDB2に関して行ったことは、どんなプログラマーのアプリケーションにも当てはめることができます。つまり今日、人の介在を要するものを考え、「その介在は私のアプリケーションに絶対に必要なものなのか？」と自問するのです。そこがプログラマーが考えるべき点の一つ、ということです。
2番目に考えるべきことは標準です。ツールキットや、自己管理の標準に向けてのその他の動きを見れば分かる通り、どうしたら標準に向けて進むことができるかどうかを、開発者としては考える必要があります。
3番目として、もちろんのことですが、私達がツールキットで配布しているものを検討することです。つまり開発者は自分たちのアプリケーションの中で、イベント・ロギングやInstall Solutionsを利用することができるのです。開発者としては、まずこの3つを考えるべきでしょう。
dW： MAPEループに関してお話しして頂けませんか？ これは全く新しい概念ですよね？ これはオートノミック・コンピューティングのために作られたもので、以前からベスト・プラクティスとして存在したものではありませんよね？
|
MAPE：
monitor, analyze, plan, and execute
|
|
RT： 確かにこれは新しいものです。これも開発者に密接に関係のあるものです。MAPEループというのは昔からあった概念を、「（一般的に）オートノミック・マネージャーで自己管理の決定を下すために取るべきステップは、こうしたステップである」と表現するような、首尾一貫した、高位アーキテクチャーとして固めたものです。そしてこのモデルは、どんな領域のアプリケーションにも適用できます。このモデルは、自己管理のコンポーネント同士が、どのようにやり取りするかに関する共通のビューを提供するのです。MAPEループ構成体は本質的に、データ・センター内にはアプリケーションから一片のミドルウェア、サーバー、ルーターに至るまで、一連の管理されたリソースがある、と表現するのです。
図1. MAPE制御ループ
dW： ということはハードウェアを含むのですか？
RT： もちろん含みます。データ・センターにあるものは全て、ディスクリートな要素は全て、管理可能リソース（manageable resource）と見なされます。意外に思われるかも知れませんが、私はソフトウェア関係の人と同じくらい、ハードウェア関係の人とも時間をかけています。ストレージ・エリア・ネットワークやUNIXサーバーのクラスター、BladeCenters™などは全て管理可能ユニット（manageable units）なので、どれもフェールする部分があり、どれにも最適化する方法があり、修復するための方法があり、等々ということです。そしてどれも、監視が必要なイベントを吐き出すわけですよね？
ですからこれはハードウェアであり、ミドルウェアであり、アプリケーションであり、どれも監視を必要とする、ディスクリートな管理可能リソースなわけです。それらを管理したり、作業したりするためにいくら人に対して費用をかけているかを考えてみてください。それがITセンターに非常にコストがかかる原因なのです。管理対象リソース（managed resources）に何が起きているのかを常に監視し、調整し、設定し、等々をするために多くの人を抱え、何事も問題が起きないように努力しているわけです。ですからそうした機能、つまり今日では人が行っているようなことの全てを、データ・センターの管理インフラの中に埋め込みたければ、オートノミック・マネージャーが必要になってきます。これは本質的に、そうした機能を取り出してソフトウェアとしてコーディングすることを意味します。オートノミック・マネージャーは本質的に次のようなものを提供します。
- 管理対象リソースの一部で起きていることを、絶え間なく監視する閉じたループ
- 入ってくるデータを解析する
- 何かを変更する必要がある場合には、変更の計画を立て、その変更を実行する
これには、監視対象のデータだけではなく、一連の知識、言ってみれば背景知識（MAPEループのナレッジ・コンポーネント）、つまり「どんなポリシーなのか？ どんな決定を下すべきかをどうやって知るのか？ 既知の症状はどんなものか？」といったような知識にも依存してきます。言い換えると、ある一連のイベントを見る時に、それが重要なものかどうかをどうやって知るのか、ということです。
これは症状情報（symptom information）と呼ばれるもので、オートノミック・コンピューティングのアーキテクチャーのために私達が作ろうとしている、ナレッジ保存形式の一つです。私が影響を与えるのは、管理対象リソースのどんなプロパティーや機能なのだろうか？ 私達はこれをエフェクターと呼んでいます。
そしてこれは本質的に、監視の対象として与えられたリソースの取っ手であり、ダイヤルであり、これをオートノミック・マネージャーが変更できるのです。ですからこれがモデルであり、そのモデルを、いくつもの製品の中で具体化するわけです。Tivoli®にはRisk Managerと呼ばれる製品があり、セキュリティー・イベントを常に監視しています。私達はまた、Autonomic Monitoring Engineと呼ばれるものにも取り組んでいます。これは管理対象リソースに起こりうる、既知の問題を探し、その問題が起こる前にアクションを起こすものです。例えばディスクが一杯に近づくと、一杯になる前にさらにスペースを割り当てるか、あるいは管理者に対してディスクが一杯になりそうだと警告するか、あるいはその両方を行います。
dW： オートノミック・コンピューティングのフレームワークもツールキットのコンポーネントも使っていない場合であっても、今言われたような機構を私のプログラミングに採り入れる意味はありますか？
RT： はい、あります。私達はアーキテクチャーとサンプル実装とを分離しています。これは他の場所でも起きています。例えば、一部の大学のプログラムでは、アーキテクチャーの観点で見るとオートノミック・マネージャーに準拠したものを書いている人達がいます。そうしたオートノミック・マネージャーは私が先ほどお話ししたモードで動作し、他のオートノミック・マネージャーとやり取りすることはできますが、彼らが書いたオートノミック・マネージャーは、ツールキットにサンプルとして添付しているコードは全く使っていません。あるいは、私達が事前構築したコードを選び出し、皆さんが自分のソリューションを構築する時にそれをコンポーネントとして含める、というようなこともできます。ですからこれは、標準を巡って業界で行われている様々なことと同じなのです。つまり皆さんはアーキテクチャーや標準を独自に実装するコードを書くこともあれば、誰か他の人が書いた実装を利用することもある、ということです。皆さんが必要としていること次第で、どちらも有効なのです。
dW： インタビューに応じてくださって、ありがとうございました。
参考文献
著者について
記事の評価
| 
