情報技術サービス・マネジメント (ITSM) は、サービス・デリバリーの基礎をなすコンピューティング・インフラストラクチャーを含む既存の IT インフラストラクチャーの管理とガバナンスにおける現行のベスト・プラクティスを体系化してサポートします。現行のベスト・プラクティスを ITSM ツールで特定して体系化すれば、自己管理リソース (SMR) の導入を通してこれらのプラクティスの簡素化が可能になり、その結果、ITSM の簡素化が可能になります。SMR と関連テクノロジーによって、既存の ITSM タスクの人からオートノミック・マネージャーへの委任を増やしたり、プロセス変更とタスクの置換や廃止を通して ITSM アクティビティーを再構築することができます。特に、SMR と仮想化を使用すれば、現代のファイル・システムによって、かつては熟練の管理者を必要としたファイル・レイアウト・タスクがオペレーティング・システムで透過的に処理されるタスクに変換されたのと同様に、複数の計画タスク、検証タスク、承認タスクが必要な多くのアクティビティーをタスク・フローがより単純なルーチン・アクティビティーに変換することができます。本稿では、SMR の一般原則について簡単に説明し、このテクノロジーの ITSM プロセスに対する潜在的な影響力を検証し、特定の ITSM フローをどのように変換できるかを分析することによってこれらのアイデアを解説します。
情報技術 (IT) システムのマネージャーは、規模や複雑さが増え続けるシステムを管理する中で困難な課題に直面しています。大規模 IT 組織の多くが、この複雑さを抑制するためにさまざまな「ベスト・プラクティス」方法を導入しています。ここでは、この方法を、実行中のアプリケーション・プログラムからあらゆる種類のワークフローまでを意味する包括的な用語の IT プロセスと区別するために正式なプロセスと呼びます。ITIL** (IT インフラストラクチャー・ライブラリー**)1、ETOM** (Enhanced Telecom Operations Map)**2、IBM サービス・マネジメント3 などの正式なプロセスによって、IT システム管理に順序と規律が導入されるため、システム管理アクティビティーに起因するシステム障害の可能性が低減され、その深刻度が緩和されます。
正式なプロセスの必要性は、主に、今日の IT システムと特にエンタープライズ・ソフトウェア・システムが、概して脆弱で、わかりにくく、容易に変更できないという事実によって促進されます。ほとんどの管理タスクにはリスクが伴うため、管理タスクが適切に行われるようにするには正式なプロセスが必要です。もちろん、正式なプロセスの価値にはコストがかかります。つまり、正式なプロセスそのものも複雑になる傾向があるため、それらを実行するシステム管理者にかなりの、また時には大きな負担になることがあります。
理想的なコンピューター・システムは管理の大部分を自動的に処理する
正式なプロセスによってシステム管理者に課される負担を軽減するための 1 つのアプローチは、プロセスの実行を支援する自動管理サポート・インフラストラクチャーの実装です。また、より長期的なアプローチは、プロセスの採用が最初に必要になった原因をできるだけ特定して取り除くことです。この両方のアプローチを推し進める必要があります。管理サポート・インフラストラクチャーがなければ、正式なプロセスによるガバナンスが必要な管理タスクが、非常に遅く、高価で、人的エラーを起こしやすいものになります。さらに、脆弱性などの根本原因が管理対象システムから取り除かれない限り、管理サポート・システムによってもたらされる時間と工数の節約分が、インフラストラクチャーによってサポートされる正式なプロセスに組み込まれた人の意思決定、合意、および承認の削減できないコストによって相殺されます。
本稿では、この 2 つのアプローチの後者を取り上げ、IT システムのアーキテクチャーの何らかの変更によって、適用する正式なプロセスの根本的な簡素化がどのように可能になるかという問いを中心に説明します。以降の 2 つのセクションでは、管理者にとって理想的なシステム像を示し、それに対して、現行のプラクティスで発生した重大なトラブル・スポットのいくつかを示します。次に、自己管理リソースの基本概念を紹介してから、自己管理リソースが IT システムを管理するための正式なプロセスをどのように簡素化し変えることができるかについて説明します。
理想的なシステム像
管理の容易さや柔軟性の観点から、理想的なコンピューター・システムとはどのようなものでしょうか。少なくとも、管理の大部分を自動的に処理して管理者の負担を軽減し、自らの成長と進化に対応できるように拡張可能である必要があります。ここからは、不信感を抱くのを一時的にやめていただいて、スケーラブルな真の自己管理 IT システムとはどのようなものかについて考えていきたいと思います。
お客様の視点から見た場合のスケーラブルな自己管理 IT システムは、いくつかのほとんど同一のボックスで構成されます。「ボックス」(マシン) 間で迅速にやりとりできることを求めるお客様は、ボックスの間にケーブルをはわせたり、ボックスをスイッチに接続したり、ラック・マウント・バージョンを購入することができます。それ以外のお客様は、単純にすべてのマシンを同じ部屋に設置して、無線通信を利用することができます。
システムは、Web インターフェース (使いやすさが厳格にテストされたもの) を通して管理されます。ほとんどのお客様は、1 本以上のネットワーク・ケーブルをイントラネットから 1 つ以上のマシンに接続します。それを望まないお客様でも、システムとは無線で通信することができます。Web インターフェースは、主に、システムの自己管理方法に関するいくつかの高水準ポリシーを設定するために使用されます (デフォルトのポリシーでは不十分な場合)。
システムの最も重要な機能の 1 つは、システムの使用状況とパフォーマンスに関する情報をお客様に提供して、拡張が必要な時期を示すことです。それを受けて、お客様は、メーカーに連絡して必要なすべてのものまたは現行の予算で購入可能なものを注文するか、適切なポリシーが設定されていれば、必要に応じて、システムが自動的に発注することができます。
新しいマシンが届いたら、他のマシンと同じ部屋に設置する必要があります (または、ラック・マウント・バージョンを使用している場合は、空きラック・スロットに挿入する必要があります)。その後は、システムが自動的にそのマシンを適切に構成してプロビジョニングします。
新しいアプリケーションをシステムに展開するために、お客様は、機能、ユーザー・インターフェース、性能などのアプリケーションに必要な特性を文書化します。すると、システムが自動的に互換性のあるアプリケーションの供給業者の Web サイトにアクセスして、該当するアプリケーションを参照し、そのアプリケーションに関するデータをお客様に返します。また、システムは、お客様に、新しいアプリケーションが既存のキャパシティーと互換性があるかどうか、互換性がない場合はあと何台のマシンが必要か、アプリケーションをシステムに追加した場合のその他の影響について報告します。お客様がその結果に満足すれば、サイトでクレジット・カード番号または顧客番号を入力して「展開」を押します。適当な時間をおいて、アプリケーションがローカル・システムにインストールされます。そのアプリケーションに対して設定されていない新しいポリシーを決定する必要がある場合は、システムからお客様にそれらの決定 (またはデフォルトの承認) が要求されます。
時間の経過とともに、パッチの適用やソフトウェア・コンポーネントのアップグレードなどのシステムに対する変更が必要になってきます。我々の理想的なシナリオでは、このような変更は、上述した新しいアプリケーションの展開方法と同様に、システムによって自動的に処理されます。定期的に、供給業者の Web サイトに対してパッチやアップグレードのチェックが行われます。パッチやアップグレードには、重要度を示す注釈 (「重大なセキュリティー・パッチ」など) とシステム運用に与える影響度を示す注釈 (「メモリーの消費率は 20% 増えるが、15% 高速化する」など) が付けられます。重要度が高く、影響度の少ない変更などの場合は、システムが自動的にアップグレードをダウンロードして適用します。それ以外の場合は、保留中のアップグレード、その影響、そのコスト (ボックスやメモリーの追加分など) がお客様に通知され、そのアップグレードを適用するかどうかが決定されます。すべての場合において、「取り消し」機能が有効になっているため、お客様の判断によってアップグレードを元に戻すことができます。
いずれかのボックスで障害が発生する場合があります。これによって、外部から見える (HTTP 接続の切断などの障害を超える) 障害は発生しません。通常は、システムが自動的に、異常終了したアプリケーションを再起動するか、応答しないボックスをリブートすることによって、障害を解決します。コンポーネントが実際に破損する場合があります。この場合は、システムがその使用を停止して、障害ランプを点灯させます。月に一度、お客様が、障害ランプの点灯したボックスを回収して、メーカーに返却し、払い戻しを請求します。
前のシナリオには、お客様のシステム管理と拡張に必要なすべてが記載されています。この理想的なシステムでは、管理タスクが、非常に単純で、安価で、信頼性が高く、中断しません。残念なことに、このようなシステムが近い将来使用可能になるわけではありません。これはサイエンス・フィクションですが、この「思考実験」では、我々が完全な自己管理システムの目標に到達するまで時間をかけて実現できる可能性のある ITSM の将来の望ましい方向性の一部を明らかにしています。
上述した理想的なシステムには、次の 2 つの重要な特徴があります。
- 変更が安全 - 変更が安全で取り消しが容易なため、変更を実施する前の高価なレビュー、承認、リハーサルのプロセスを構築する必要がありません。変更を実施する前に、変更により生じる可能性の高い影響についてシステムに問い合わせることができます。
- 処理はポリシーによって実行される - システムの処理ごとに人の計画や介在を必要としない自己管理コンポーネントで構成されたシステムは、前もって指定することが可能で、システムが変更に応じて実施する自動処理を制御するより高水準のポリシーによって実行されます。
ここで、焦点を現実世界に戻し、現行のシステムから、変更が安全でシステム管理が容易なポリシー駆動型自己管理システムへの移行を検証する前に、今日使用されている IT システムのトラブル・スポットのいくつかについて検証します。
システム管理のトラブル・スポット
今日の IT システム管理における最大の問題は、おそらく何がインストールされているか、どこにインストールされているか、どのように構成されているかなどの IT リソースそのものに関する包括的な情報の不足です。一般的に、IT リソースに関する情報は、仮に保存されるとしてもリソースから切り離して保存されます。システム・コンポーネントに関する情報の集中データベースは、まとまりの悪いまたはまとまりのない情報よりはましですが、さまざまな問題を抱えています。よく見られる問題の1 つには、リソースが変更されると、必然的にデータベースとリソースの実際の状態が不整合になるということです。
この状態の発生頻度の最小化、発生するタイミングの検出、および検出時の対処には数多くの高価なプロセスが必要です。
特定のリソースに関する情報の不足も 1 つの問題ですが、さまざまなリソースが相互に関係する方法や理由に関する情報の不足はさらに深刻で困難な問題です。問題判別と故障分析がより困難になり、リソースに対して提案された変更の影響の予測はほとんど不可能です。関係に関する情報がリソースから全く見えない場合がありますが、通常は、システム構造に暗に示されていたり、サード・パーティーだけが知っていたりします。
おそらく、今日の IT システム管理における最大の問題は IT リソースそのものに関する包括的な情報が不足していることである
関係情報、特に、特定のサービスレベル・アグリーメント (SLA) の履行に関する、または、それに必要な関係パラメーターに関する情報が不足していることが原因でキャパシティー計画が困難になります。実際のシステムのサービス品質 (QoS) に対する期待が文書化されていなかったり、不完全なことが多くあるだけでなく、このような期待を満たすために不可欠なシステムの特定の構造や構成が専門家の記憶にしかないことが多くあります。この理由から、システムに対するさまざまな変更には、何時間、何日、または何週間ものレビューとリハーサルが必要になります。
これらの要因によって、システムの動作が予期せず変化した場合の根本原因の特定と必要な変更の安全性または影響の特定の両方が困難になっています。そのため、問題判別と変更管理のための、複雑で高価になりがちな、正式なプロセスを構築する必要があります。
自己管理リソース
たいていの場合、前述したトラブル・スポットは、サービス指向アーキテクチャーで運用する自己管理リソース (SMR) を使用することによって解決することができます4。SMR の詳細については、参考文献 5 などの資料を参照してください。それらの資料ではオートノミック要素と呼ばれています。SMR は、IT リソース、つまり IT システムのコンポーネントであり、SMR では従来、リソースの管理として見なされていた部分の多くがリソースそのものによって実施されます。また、SMR は、ソフトウェア・エージェントの多くの特徴、特に、比較的自律的に動作し、他の SMR とメッセージの送受信を行う機能を持つアクティブなエンティティーです。この SMR は、IT システム全体の動作を共同で管理するための所定の方法 (後述) で相互作用します。このすべては、SMR にするリソースの最低水準の機能性、つまり、単一の SMR の最小サイズと複雑さが決まっていることを意味します。したがって、たとえば、ファイル・システム内の個々のファイルまたはデータベース・テーブル内の行を SMR にするのは実用的ではありません。むしろ、ファイル・システムまたはデータベースそのものを SMR にする方が実用的です。
リソース・レベルの自己管理は、完全にまたはほぼ完全に導入しなければその恩恵を享受できない絶対的な命題ではありません。それどころか、完全な自己管理へ向けたすべての段階的な進歩によって、IT システムの管理作業の脆弱性と複雑さが大幅に軽減されます。
SMR の詳細については、参考文献 5 を参照してください。ここでは、その最も重要な特徴について簡単に説明するだけにします。
- 自己記述 - SMR は、クエリーに応答して、現在の動作パラメーターとステータス、提供可能なサービスと利用しなければならないサービス、他の SMR との現在の関係などの SMR そのものに関する詳細情報を提供します。
- 自己登録 - SMR は、1 つ以上のレジストリー・サービスを使用して、自らの存在と自己記述情報の要約を登録します。
- ポリシー - SMR は、宣言型ポリシーに従って動作を決定します。ポリシーは適切な状況で他のパーティーから提供される場合があります。SMR は、許可されたソースからのポリシー更新だけを受け入れ、それらを使用する前にすべての整合性をチェックします。整合性チェックは、その更新を組み込む場合の SMR のポリシーと契約の全体に対する影響を判断するために行われます。
- 契約を通した関係の明示的管理 - SMR は、他の SMR と契約を締結してそれに従うことによって共同の行動を調整します。契約は、SMR がそれに基づいて行動を決定するという点でポリシーに似ていますが、ポリシーと違って、契約はそれを締結した SMR の明示的な管理下にあります。
- やりとりの整合性 - SMR は、低水準インターフェースを通した内部状態へのアクセスを許可しません。つまり、SMR とのすべてのやりとりは、SMR 独自のポリシーと契約が履行される方法、たとえば、クエリーやコマンドに対する応答を形式化する方法で実現されます。これは、SMR が常に独自のポリシーを順守し、締結した契約によって強制される制約に従うという要件をサポートするために必要です。
- 影響分析 - SMR は、特定の変更が実施されたり、特定の前提条件が満たされた場合に起きる現象に関する情報を提供することができます。この情報は、詳細である必要はなく、単に、提案された変更によって SMR がポリシーや契約に違反するかどうかを示す情報で構成することができます。実施される変更がポリシー更新の場合に必要なロジックは、更新の整合性をチェックするときに使用されるロジックと同じです。
これらの機能のそれぞれが SMR の実装にとって重要ですが、これらの機能のサブセットの段階的導入がシステム管理にとって有効です。すべてのリソースを自己記述リソースと自己登録リソースにするだけで、今日の典型的な状況を打開する重要な進歩になります。
機能している IT システムへの SMR 集合の組み込みを支援するには、複数のインフラストラクチャー・サービスが必要です。これらは、SMR 間のやりとりを促進するサービス (もちろん、SMR によって提供される) です。これらのサービスは、マルチ・エージェント・システムでよく見られる「中間エージェント」によって提供されるサービスに酷似しています6。これらのサービスの一部は、現在の IT システムと類似性がありますが、その他のサービスは、SMR で構成されたシステム以外では必要とされません。サービスの完全なリストについては、参考文献 6 を参照してください。ここでは、その 4 つだけについて説明します。
- レジストリー - レジストリー・サービスは、システム内の SMR に関する情報のネットワーク・アクセス可能なリポジトリーとして機能します。前述したように、SMR はレジストリー・サービスを使って自らを登録します。また、利用しなければならないサービスを提供可能な他の SMR を見つけるためにもレジストリー・サービスを使用します。
- ポリシー・リポジトリー - ポリシー・リポジトリーは、SMR にポリシーを提供するネットワーク・アクセス可能なサービスです。SMR は、リポジトリーから更新が入手可能な時期が通知されると、それに合わせて、更新を入手するための処置を実施します。このポリシー更新の「プル」モデルは、自己管理するための SMR の要件から自然に派生した結果です。
- リソース・ファクトリー - 複数種類の SMR を、システム全体のニーズ (変わりやすいワークロードの対処など) に応じて動的にインスタンス化することができます。この場合は、SMR の作成作業が「ファクトリー」で実行されます。SMR は、起動されて初期のデフォルト構成情報 (基本ポリシーなど) が提供されると、自己管理責任を引き受けます。
- センチネル - センチネルは、任意の数の SMR の「正常性」またはライフ・サイクル状態を監視し、それらの状態の変化を (申し込んでいる SMR に) 報告することができます。これによって、システム管理ソフトウェアは、SMR の障害を自動的に発見して、その SMR を再起動したり、交換したり、その他の是正処置を実施することができます。すべての状況でセンチネルが必要なわけではありません。多くの場合、ある SMR に伴う問題は、それがサービスを提供している (または、提供していた) 他の SMR によって検出されます。ただし、特定の SMR の正常性を、それが提供しているサービス内の障害とは無関係に、積極的に監視することが必要または望ましい場合は、センチネルが有効に機能することができます。
SMR、あるいは今日使用されているリソースよりも自己管理機能がいくらか優れたリソースでさえも、IT サービス・マネジメントを根本的に簡素化する可能性があります。コンピューター・システムに SMR を組み込むことによって、IT システム管理の高水準タスクの多くを容易に自動化可能な大幅に簡素化された新しいフローが実現されます。全く異なるアルゴリズムを使用したコンピューター・チェス・プログラムが人間の対局者と同じ目標を達成するのと同様に、SMR はコンピューターの能力を活用して大量のデータを追跡し、繰り返し作業を実行する IT 管理フローを可能にします。ただし、自動機能で対処できない状況が発生した場合は人間に委ねます。このように人の介在が必要な場合は、SMR の組み込みによってコンピューター・リソースの情報収集能力と自己管理能力が活用できるため、システム管理者の仕事がらくになります。
IT システム管理の正式なプロセスの調査では、労働集約的傾向が強いことが示されています。これは、主に、今日のシステムでは、管理者しかシステム内の事象に関する情報 (データベース A とアプリケーション B はどのように関係しているか、サーバー C のキャパシティーはどのくらいかなど) にアクセスできないことが原因です。この情報は、システム・コンポーネントに情報を利用できる能力がある場合にでも、システム・コンポーネントにはほとんど提供されません。したがって、管理者だけが、一部の意図された管理タスクの結果を特定できる立場にあります。タスクの実行が自動化された場合 (システム管理フレームワークなどによって) でも、タスクを実行すべきコンテキストとその望ましい状態を支配している条件の大部分にシステム管理ソフトウェアからアクセスできません。
SMR で形成される世界では、各リソースがこの情報の多くを「理解」します。リソース独自のプロパティー、パラメーター、および実行時状態の理解は、自己記述能力と自己管理能力の必要に応じて、リソース内にコード化されます。リソースのシステム全体に対する関係 (動作するコンテキストなど) の理解は、リソースが当事者になる契約に含まれます。
有害な管理コマンド (コマンドの実行が SMR の契約違反につながる可能性がある場合など) から自らを保護するための SMR の組み込み能力によって、このようなコマンドの送信に伴うリスクが大幅に軽減されます。コマンドを受け取った SMR は、「契約 X に違反する可能性があるため要求に応じることができない」という内容のメッセージでコマンドに応答します。正式なプロセス・フローで規定された複数の管理者または利害関係者によるチェックと承認の大部分を不要にできます。正式なプロセスは、この動作を無効にして契約に反してそのコマンドに従うように SMR に強制する場合にのみ必要とされます。
たとえば、未熟な管理者が、ビジネスに不可欠なアプリケーションでデータベースが使用中であることを知らずに、日常保守でデータベース・サーバーをシャットダウンしようとした場合です(別のデータベース・サーバーの障害により、問題のデータベース・サーバーへの予定外の切り替えが必要になったものとみなします)。そのデータベースが SMR の場合は、シャットダウン・コマンドに対して「ビジネスに不可欠なアプリケーションとの契約に違反する可能性があるため今はシャットダウンできない」という内容のメッセージで応答するため、起こり得る高価なエラーが回避されます。
このこと自体が、システム管理ソフトウェアのオペレーションの根本的な簡素化を可能にします。多くの ITSM フローに、(たとえば) 特定の変更要求が事前承認済みとして分類される「高速パス」分岐が存在します。特定の種類の変更が事前承認されていれば、フロー全体の複雑さの大部分を回避できます。IT システムへの SMR の導入は、高速パスの利用頻度を高める効果があり、エラーのないタスクの割合が増えることによってコストと時間が大幅に節約されることを意味します。
SMR で実現可能な簡素化はこれだけではありません。SMR は、管理者のエラーから自らを保護することができる (したがって、SMR が属するシステムも保護することができる) のと同様に、一般のユーザーはもちろん、他の SMR による有害なアクションから自らを保護することもできます。これによって、IT システムとその管理を担当しているプロセスの関係を抜本的に再編成することができます。システム管理サポート・フレームワークと相互作用する (変更要求の提出など) 代わりに、ユーザーと管理者は、現在行っているファイルの作成やパスワードの変更などの日常作業と同様に、やるべきことのほとんどでシステムのコンポーネントと直接やりとりすることができます。コマンドを受け取った SMR が要求を実行 (ポリシーと契約で規定されているように) しても安全であると判断した場合は、そのまま、その要求を実行します。それ以外の場合は、その要求を拒否します。たとえば、ユーザーは、実行できない場合の動作が事前にわかっていれば、迷わず、変更要求を提出する代わりに、必要な変更を実行しようとします。要求を受け取る SMR のポリシーによって、要求とそれに続く動作が記録されるかどうかまたはどのように記録されるかが決定されるため、変更を選択的に追跡することができます。
SMR で可能になる 3 つ目の簡素化では、契約の締結および変更能力を利用します。これによって、高度な適応アルゴリズムが SMR 自体に組み込まれるため、提供しているサービスに対する要求の変更に応じて独自の動作 (利用しているサービスを含む) を修正することができます。したがって、たとえば、SMR によって、ユーザーがアプリケーション・コードをデータ・センターの展開リポジトリーに配置してアプリケーションに自己展開を指示する、新しい J2EE** (Java** 2 Enterprise Edition) アプリケーションの簡素化された展開プロセスが可能になります。これを実現するには、アプリケーション (それ自体 SMR) でメッセージを受信して自己展開タスクを実行可能な期間に、アプリケーションを起動する必要があります。この動作は、リポジトリーを展開することによって自動的に実行されます。起動されたアプリケーションは、データ・センターで適切なホスティング・コンテナー (WebSphere* Application Servers など) を探して、これらの潜在的ホストと必要な条件 (パフォーマンスなど) を交渉し、最終的に、その最良のホストと正式な契約を締結します。このホスティング・コンテナーは、すでに締結していた契約を再交渉しなければならない場合 (データベース内のストレージ・キャパシティーを増やす必要がある場合など) があります。
究極は、ほとんどのサービス管理プロセスが完全に自動化されたデータ・センターを想定しています。もちろん、この自動化は、管理者が設定したポリシーによって制御されます。自動 SMR で処理できない状況が発生した場合、または、指針となるポリシーが存在しない場合は、タスクが管理者にエスカレートされて処理されます。その場合でも、管理者の多くが、比較的簡単な方法でシステム・コンポーネントと相互作用することができます。ごくわずかなケースに限って、管理者が、タスクが安全に実行されることを保証するための正式なプロセスを定めなければならない場合があります。たとえば、複数の SMR の動作に影響を与えるシステム・レベルのポリシーを変更または上書きするためには正式なプロセスが必要になる可能性が高くなります。この場合は、不適切なポリシーを適用することによってシステムの動作を著しく不安定にさせる可能性があります。
ITSM プロセスの簡素化における SMR の価値を確認するために、管理対象システムが異種仮想サーバーの集合である非常に狭い範囲のシナリオを検証し、SMR によってサーバーを追加または削除して潜在的にソフトウェアを展開するプロセスをどのように簡素化できるかを示します。このシナリオでは、各仮想サーバーが SMR であり、物理ハードウェアと仮想サーバー間の仮想化レイヤーを提供する「ハイパーバイザー」として機能します。(前述したインフラストラクチャー・サービスの観点では、ハイパーバイザーはリソース・ファクトリーです)。各物理マシン上で動作しているハイパーバイザーは、そのマシン上で動作している仮想サーバーのセンチネルでもあります。各仮想サーバーは、ハイパーバイザーによってそのサーバーに割り当てられた基本リソース (CPU、ディスク、メモリーなど) のレベルだけでなく、契約そのものの有効期限が記載されたハイパーバイザーとの明確な契約の下に動作します。
自己管理リソースが IT サービス・マネジメントを根本的に簡素化する可能性がある
この例では、あるシステムのユーザーが、開発した新しいソフトウェアをテストするための新しい仮想サーバーの割り当てを希望しています。このユーザーは、必要な基本リソース・レベルと契約の有効期限を含む、新しいサーバーに関する要求をハイパーバイザーに送信します。ハイパーバイザーは、現在施行されている既存の仮想サーバーとの契約を調査し、その契約の条件に違反せずに必要なプロパティーが設定された新しい仮想サーバーを作成できるかどうか、たとえば、既存の契約に対してはコミットされていないが、新しい要求に対してはコミット可能な十分なリソース (CPU、メモリー、ストレージなど) が存在するかどうかを判断します。作成できる場合は、ハイパーバイザーが、新しい仮想サーバーを割り当て、要求しているユーザーに管理者権限を付与する初期ポリシーをそのサーバーに設定し、新しいマシンに関して必要な情報をユーザーに送信します。また、要求者 (ユーザー) と新しく作成された仮想サーバー間に、サーバーが要求された基本リソース・レベルをユーザーに提供することに合意していることを示す契約が設定されます。
ここでの関連 ITSM プロセスは、図 1 に示されている変更管理です。除去可能なアクティビティーが赤色の斜線付きの円で示されています。ハイパーバイザーとサーバー間の契約の存在と、現在施行されている契約に従うための SMR 固有の目標が、このようなアクティビティーを不要にする SMR の本質的特徴です。
図 1. 変更管理の概要
拡大図
新しい仮想マシンに対応するための空きローカル・ディスク・スペースが物理マシンに不足している、何らかのポリシーが原因でローカル・ディスク・スペースではなく、外部ストレージ・エリア・ネットワーク (SAN) ストレージを使用する必要があるなどの前提によってシナリオを変更することができます。この場合は、新しいサーバーに対する要求が到着した段階で、ハイパーバイザーが SMR でもある SAN からストレージを割り当てる必要があります。ハイパーバイザーは、ストレージ割り当ての増加を要求するために、施行されている SAN との既存の契約を再交渉しようとします。SAN が新しい契約の条件に合意すれば、ハイパーバイザーの物理マシンにストレージが割り当てられ、ハイパーバイザーはユーザーの要求を満たすことができます。SAN が新しい条件に合意しないまたは合意できない場合、ハイパーバイザーは、ストレージの提供に合意しそうな別の SAN コントローラーを求めてレジストリーを検索することができます。この試みが失敗した場合、ハイパーバイザーはユーザーの要求を拒否する必要があります。
最後に、ユーザーがテスト中のソフトウェアが、SMR (何らかのアプリケーションなど) として開発された場合のシナリオを検証します。この場合は、アプリケーションが独自の要件 (つまり、一定量のメモリー、CPU、およびストレージを備えた仮想サーバー) を理解して、自動展開することができます。ユーザーのテスト環境で動作中のアプリケーションが、新しいサーバーに関する要求をハイパーバイザーに送信します。ハイパーバイザーの視点からは、今回のシナリオと、要求がユーザーから出される前回のシナリオの区別がつきません。仮想サーバーが構築されると、要求者 (この場合はアプリケーション) と新しく作成された仮想サーバー間に、サーバーが要求された基本リソース・レベルをアプリケーションに提供することに合意していることを示す契約が設定されます。ミドルウェア SMR を新しいサーバーにインストールする必要がある場合は、アプリケーションが、レジストリーを使って適切なリソース・ファクトリーを検索し、見つかったリソース・ファクトリーとこの実現について交渉します。この時点で、アプリケーションは自らを新しい仮想サーバーにインストールしてそこで動作を開始することができます。
今日の管理者に依存した IT システム管理から自己管理 IT インフラストラクチャーに移行するための一般的なアプローチについて説明しました。この移行を実現するには、IT インフラストラクチャーの個々のリソースを SMR にする必要があります。SMR は、独自の機能を「理解」し、他のパーティーとの正式な契約を締結して指定されたサービス・レベルでこれらの機能を提供できる必要があります。また、合意されたサービス・レベルでこれらの機能を提供するために必要な下位リソースを理解する必要もあります。追加のクライアントにサービスを提供するための契約を締結するように要求された場合は、SMR が既存の契約に悪影響を与えずにこれが実現できるかどうかと (もしあれば) どの下位リソースを追加する必要があるかを決定する必要があります。
SMR と関連テクノロジーによって、既存の ITSM タスクの人から SMR そのものへの委任を増やしたり、プロセス変更とタスクの置換や削除を通して ITSM アクティビティーを再構築することができます。特に、SMR の使用によって、複数の計画タスク、検証タスク、および承認タスクを必要とする多くの現行アクティビティーが、より簡単なタスク・フローを使って定期的に実行可能な安全なアクティビティーに変換されます。
もちろん、この変換は、仮に実現可能な場合でも非常に困難な目標です。実行可能な SMR を生成するために必要な専門知識のエンコードには多くの課題があります。仮想サーバーなどの比較的低水準のリソースの場合は、それらのサービス契約が CPU 共有、メモリー専有、ストレージ割り当てなどの理解しやすい具体的な用語で表現されるため、比較的簡単に SMR として作り直すことができます。ただし、リレーショナル・データベース管理システム (DBMS) などの高度なミドルウェアの場合は、適切なサービス要件の表現方法や、SMR として機能する DBMS がこれらの要件を CPU、メモリー、および I/O 帯域幅に関する独自のニーズに変換する方法がまだ決まっていません。毎分約 150 SQL (構造化照会言語) 要求のサービス・レベルをクライアントに提供することに合意するように要求しても、DBMS に十分な情報が伝わりません。DBMS でこの契約が受け入れられるかどうかは、データベースのサイズ、そのスキーマ、および SQL 要求の特性 (主キーか 4 方向結合かの選択など) に依存します。このような場合は、要求に相当するワークロードを明らかにしたり、まだ開発されていない適応型システム・モデルを導入したり、複雑なシステムの実行時動作を自動的に予測および把握するための我々の方法を別のやり方で進展させるために、ベンチマークを実施する必要がある場合があります。SMR を効果的に動作させるために有効なまたは必要なベンチマーク、モデリング、およびその他のテクニックの種類を決定するためには多くの調査が必要です。これらは、真の自己管理システムの構築を目指している研究課題から外れています。その他の研究課題については、参考文献 7 を参照してください。
ここで提案した方法で動作する SMR によって、本当に、IT システムを管理し、前述した理想的なシステムに近い ITSM のバージョンを実現する方法を根本的に変えることができるでしょうか。現在の試作と研究の取り組みは、大きな進歩と向上が可能であり、これには非常に困難な (かつ非常に興味深い) 問題の解決が必要であることを示唆しています。
*IBM Corporation の米国およびその他の国における商標または登録商標です。
**United Kingdom Office of Government Commerce、Telemanagement Forum Corporation、または Sun Microsystems, Inc. の米国およびその他の国における商標または登録商標です。
- 「IT Infrastructure Library (ITIL)」、Office of Government Commerce
- 「eTOM Overview」、TeleManagement Forum
- 「IBM Service Management」、IBM Corporation
- H. He 著「What is Service-Oriented Architecture?」、O’Reilly Media, Inc. (2003 年)
- S. R. White、J. E. Hanson、I. Whalley、D. M. Chess、J. O. Kephart 共著、「An Architectural Approach to Autonomic Computing」、Proceedings of the First International Conference on Autonomic Computing (ICAC ’04), IEEE Computer Society Press, Washington, DC (2004 年), pp. 2–9
- K. Decker、K. Sycara、M. Williamson 共著、「Middle-Agents for the Internet」、Proceedings of the 15th International Joint Conference on Artificial Intelligence (IJCAI-97), Morgan Kaufmann, San Francisco, CA (1997 年), pp.578–583
- J. O. Kephart 著、「Research Challenges of Autonomic Computing」、Proceedings of the 27th international Conference on Software Engineering (ICSE ’05), ACM Press, New York (2005 年), pp. 15–22
2007 年 2 月 14 日に発表許可
2007 年 6 月 28 日にオンライン公開
David M. Chess
IBM Thomas J. Watson Research Center, 19 Skyline Drive, Hawthorne, NY 10532。Chess 氏は、Watson Research Center にある Internet Infrastructure and Computing Utilities 部門の研究員です。1981 年に Princeton University で哲学の学士号を取得し、Pace University でコンピューター・サイエンスの修士号を取得しました。1981 年に IBM Research に入社以来、コンピューターを利用した共同作業、コンピューター・セキュリティーとウィルス防御、オートノミック・コンピューティング、およびスケーラブルなシステム管理を研究してきました。
James E. Hanson
IBM Thomas J. Watson Research Center, 19 Skyline Drive, Hawthorne, NY 10532。Hanson 博士は、Watson Research Center にある Internet Infrastructure and Computing Utilities 部門の研究員です。University of California at Berkeley で物理学の博士号を取得しました。1995 年に IBM Research に入社以来、ネットワーク・システム、ソフトウェア・エージェント・システムとマルチ・エージェント・システム、およびオートノミック・コンピューティングにおける新しい現象について研究してきました。
John A. Pershing, Jr.
IBM Thomas J. Watson Research Center, 19 Skyline Drive, Hawthorne, NY 10532。Pershing 氏は、Watson Research Center にある Distributed Infrastructures 部門の研究員です。Massachusetts Institute of Technology でコンピューター・サイエンスの学士号と修士号を取得しました。主に、コンピューター・ネットワーキング、大規模クラスタリング、可用性、およびシステム管理の分野に関するコンピューター・システムの研究に 30 年以上携わっています。
Steve R. White
IBM Thomas J. Watson Research Center, 19 Skyline Drive, Hawthorne, NY 10532。White 博士は、Watson Research Center にある Internet Infrastructure and Computing Utilities 部門の研究員です。現在は、オートノミック・コンピューティングを研究しながら、何十億ものコンポーネントで構成されながらも自己管理可能なコンピューター・システムの構築方法を模索しています。物性物理学、焼き鈍し法による最適化、ソフトウェア保護、コンピューター・セキュリティー、コンピューター・ウィルス、情報経済、およびオートノミック・コンピューティングの分野で本を出版しており、関連分野で 24 を超える特許を取得しています。IBM Academy のメンバーであり、彼の業績に対して IBM で最高の技術賞が送られています。1982 年に University of California at San Diego で理論物理学の博士号を取得しました。研究員になる前は、IBM Research で博士研究員を務めていました。
目次へ戻る
| 
