〔実施の形態1〕
本実施の形態に係るワークスペースコンピュータ101および/またはランタイムコンピュータ102は、不完全性と不確実性が潜在的に存在するオープン環境において、対象システムのディペンダビリティの維持を支援するものである。そのため、後述するように、本実施の形態に係るワークスペースコンピュータ101および/またはランタイムコンピュータ102は、対象システムのディペンダビリティに関する仕様を記述したディペンダビリティ記述データ(時間軸上でモデルの変化を可能にした上で対象システムの構造を計算可能なモデルとして表現することを可能にする差分構造モデルで記述されるデータであってもよい。)に基づいて、対象システムのディペンダビリティの価値を定量的に示すD値を求める。
以下、図1から図41に基づいて、本発明の一実施の形態について詳細に説明する。
〔1.ハードウェア構成〕
図1は、本実施の形態に係るディペンダビリティ維持システム100の構成の概略を示す機能ブロック図である。
図1に示すように、ディペンダビリティ維持システム100は、ディペンダビリティ維持装置としてのワークスペース(Workspace)コンピュータ(ディペンダビリティ維持装置、ワークスペース装置)101およびランタイム(Runtime)コンピュータ(ディペンダビリティ維持装置、ランタイム装置)102を含んで構成され、それらはネットワーク103で接続される。ワークスペースコンピュータ101で処理されたソフトウェアSWは、ランタイムコンピュータ102に展開されて処理される。また、対象システム、あるいはアプリケーションシステムとその実行に必要なライブラリ、ミドルウェア、システムサービス等のサポートシステムはランタイムコンピュータ102に含まれる。ソフトウェアSWは、バイナリ実行部110(110W、110R;ワークスペースコンピュータ101のバイナリ実行部110Wとランタイムコンピュータ102のバイナリ実行部110Rを区別する場合は、W,Rを付して記す。)で処理可能な表現形式を有している。ソフトウェアSWは対象システムで稼働するアプリケーションとその実行に必要なライブラリ、ミドルウェア、システムサービス等の実行環境を含む。
ワークスペースコンピュータ101は、検証ツール部101−01、編集ツール部101−02、解析ツール部101−03、開発ツール部101−04、合意形成支援ツール部101−05、バイナリ実行部110Wを備えて構成される。なお、機能ブロックは必ずしもこれらに限定されるものではないが、これら代表的な機能について簡単に説明する。
検証ツール部101−01は、ソフトウェアSWを検証する。編集ツール部101−02は、ソフトウェアSWを編集する。解析ツール部101−03は、ソフトウェアSWを解析する。その際、ランタイムコンピュータ102からの情報を用いても良い。開発ツール部101−04は、ソフトウェアSWを開発するために利用される。
また、ランタイムコンピュータ102は、更新部102−01、記録部102−02、モニタリング部102−03、再構成部(再構成手段)102−04、隔離部102−05、スクリプト処理部(スクリプト処理手段)102−07、バイナリ実行部110Rを備えて構成される。なお、機能ブロックは必ずしもこれらに限定されるものではないが、これら代表的な機能について簡単に説明する。
更新部102−01は、ランタイムコンピュータ102で処理されているソフトウェアSWを更新する。記録部102−02は、ランタイムコンピュータ102の内部の状態を記録する。記録に当たっては、ソフトウェアSWの指示に従っても良いし、あらかじめ決められた所定の設定に従って記録しても良い。モニタリング部102−03は、ランタイムコンピュータ102の内部の状態を取り出すと同時に、後述するD値を算出する。状態の取得は、ソフトウェアSWの指示に従っても良いし、あらかじめ決められた所定の設定に従って取得しても良い。再構成部102−04は、ランタイムコンピュータ102の内部の構成を変更する。構成の変更に当たっては、ソフトウェアSWの指示に従っても良いし、あらかじめ決められた所定の設定に従って変更しても良いし、スクリプトの指示に従っても良い。隔離部102−05は、ランタイムコンピュータ102の内部の一部の構成を切り離して独立させる。スクリプト処理部102−07は、後述のディペンダビリティ記述データから導出されるスクリプトを実行する。
ここで、ディペンダビリティ維持システム100は、図1に示すように、別個の二台のコンピュータで構成されるシステムであっても良いし、1台のコンピュータで構成されるシステムであっても良いし、各々が2台あるいはそれ以上の台数のコンピュータから構成されるシステムであっても良い。2台あるいはそれ以上で構成されるときには、各コンピュータはネットワーク103で接続されていればよい。
図2に、ワークスペースコンピュータ101およびランタイムコンピュータ102のハードウェア構成を示す。もっとも基本的な構成としては、ワークスペースコンピュータ101およびランタイムコンピュータ102は、命令バスとデータバスで接続された演算装置151と、制御装置152と、メモリ装置153と、入出力装置154とを備えた電子計算機である。入出力装置154から入力されたビットデータの情報に基づき、演算装置151において、算術演算、論理演算、比較演算、シフト演算、等が実行される。実行されたデータは必要に応じて、メモリ装置153に記憶され、入出力装置154から出力される。これら一連の処理は、メモリ装置153に記憶されたソフトウェアプログラムに従って、制御装置152によって制御される。本実施の形態におけるワークスペースコンピュータ101およびランタイムコンピュータ102は、上記のコンピュータとしての基本機能を備えたハードウェアであり、オペレーティングシステムやデバイスドライバ、ミドルウェア、アプリケーションソフトウェアといったプログラム群によって制御されている。
図3に本実施の形態に係わるソフトウェアSWの構成例を示す。版管理情報104−01は、当該ソフトウェアSWに関する版管理に関する情報であり、タイムスタンプを含んでいても良い。ディペンダビリティ記述データ104−02は、当該ソフトウェアSWに関する後述のディペンダビリティ記述データに関する情報である。バイナリ・コード104−03は、当該ソフトウェアSWの処理をバイナリ実行部110が解釈実行可能な表現形式で記述した情報である。外部参照情報104−04は、当該ソフトウェアSWが必要とする、あるいは依存している外部のソフトウェアに関しての情報である。
〔2.ディペンダビリティ記述データ〕
図4は、一例としてのアプリケーションを示す説明図である。ここでは、WEBアプリケーションを例に説明する。
図4(a)は、当該アプリケーションが3層構造モデルを成していることを示している。プレゼンテーション層(Presentation)200−01は、当該アプリケーションの表示(及び入力)を担当する。データアクセス層(Data access)200−03は、当該アプリケーションが実行を進めるに当たって必要となるデータを格納し管理する。アプリケーションロジック層(Application logic)200−02は、ユーザからの入力の基づき当該アプリケーションとしての必要な計算処理を実行し、結果をデータアクセス層200−02に渡す。あるいは、当該アプリケーションが必要なデータをデータアクセス層200−02から入手し、処理をしてからプレゼンテーション層200−01に渡して利用者に提示する。
図4(b)は、上記3層構造モデルを実装する際の一構成例を示している。WEB Server201−02が、上記プレゼンテーション層200−01に相当する。Client201−01は、当該アプリケーションの利用者であり、ネットワーク201−05経由で、WEB Server201−02を利用する。Client201−01、ネットワーク201−05、及びWEB Server201−02を含めてプレゼンテーション層200−01に相当すると考えても良い。App Logic201−03は、上記アプリケーションロジック層200−02に相当する。App Logic201−03は、WEB Server201−02とは通信路201−06を介して情報の交換を行い、DBS201−04とは通信路201−07を介して情報の交換を行う。DBS201−04は、データベースであり、App Logic201−03の処理した、又は処理に必要なデータの格納、獲得、等の管理を行う。WEB Server201−02、App Logic201−03、及びDBS201−04は、ランタイムコンピュータ102で実行されるが、それらが1台のコンピュータ上で実行されても、それぞれ1台ずつのコンピュータ上で実行されても良い。
図5は、上記アプリケーションのディペンダビリティ記述データの一例であり、サービス継続の観点からディペンダビリティ記述データを記述している。ディペンダビリティ記述データとは、アプリケーションのディペンダビリティに関するステークホルダ間の合意された要求を記述したモデルである。
以下に、図5に記載の一例の内容を説明する。「WEBサービスの継続」(202−01)は上記アプリケーションのディペンダビリティに関するゴールであり、WEBサービスが継続できることを意味している。このゴール(202−01)を実現するためには、当該ディペンダビリティ記述データでは、「Clientの動作継続」(202−02)、「WEB Serverの動作継続」(202−03)、「App Logicの動作継続」(202−04)、「DBSの動作継続」(202−05)の4つの特性が満足される必要がある。それぞれ、図4(b)のclient201−001、WEB Server201−02、App Logic201−03、及びDBS201−04に対応している。
これら4つの特性は、さらにブレークダウンされ次のように記述される。「Clientの動作継続」(202−02)のためには、「デバイスの適切な動作」(202−06)と「WEB Serverの適切な反応」(202−10)という2つの特性の充足が必要である。「WEB Serverの動作継続」(202−03)のためには、「リクエストの適切な送受信」(202−07)と「App Logicの適切な反応」(202−11)の2つの特性の充足が必要である。「App Logicの動作継続」(202−04)のためには、「正常な業務処理」(202−08)と「DBSの適切な反応」(202−12)の2つの特性の充足が必要である。「DBSの動作継続」(202−05)のためには、「DBの一貫性」(202−09)と「データの有効性」(202−13)の2つの特性の充足が必要である。
上記複数の特性の充足は、図5では、楕円形ノードに示された各種の検証を始めとする、実行時のモニタリング結果によって、把握、判断することができる。例えば、「デバイスの適切な動作」(202−06)は包括的なテストによる「デバイス検査の合否」(202−20)によって当該特性が充足されていると判断できる。「WEB Serverの適切な反応」(202−10)や「リクエストの適切な送受信」(202−07)は当該サーバへのアクセスベンチマークを始めとする、実行時のログ検証による「反応検査の合否」(202−21)や「遅延検査の合否」(202−22)によって当該特性が充足されていると判断できる。「App Logicの適切な反応」(202−11)や「正常な業務処理」(202−08)も同様に包括的なテストによる「テストケース合否」(202−23と202−24)によって当該特性が充足されていると判断できる。「DBSの適切な反応」(202−12)、「DBの一貫性」(202−09)、及び「データの有効性」(202−13)の特性もベンチマーク、ストレステスト(過負荷試験)、アノマリーテスト(耐異常試験)による、あるいは実行時のデータベースアクセスログの検証による各々「ベンチマーク合否」(202−25)、「ストレステスト合否」(202−26)、「アノマリーテスト合否」(202−27)によって当該特性が充足されていると判断できる。本実施の形態では、これら楕円形ノードに記述された検証を、対応ノードの特性が充足していることを示す根拠(エビデンス)として扱う。なお、これらのエビデンスは、後述するモニタノードによる計測値も利用される。
図6は、図5がシステムの正常系に関してのディペンダビリティ記述データであったのに対し、リスクを考慮したシナリオベースのディペンダビリティ記述データの例である。すなわち、「・・・が発生したら、・・・の対応が取れるか?」というシナリオを考えることで、ディペンダビリティ記述データを記述している。例えば、図6の例では、ノードのトップは「DBのHDDの容量が限界(データベースシステムを構成するハードディスク容量に空きがなくなったらどのような対応が取れるか?)」(203−01)という、リスクが記述されている。このリスクが実際に発現しないための、4つの対策を次レベルのノードに記述している。「HDD容量の拡張」(203−02)はハードディスクの追加やより容量の大きなディスクドライブへの置き換え等の手段によって容量が拡張可能であることを記述している。「バックアップDBSによる継続」(203−03)はデータベースシステムにバックアップ系が用意されており、それを用いてデータベース機能が継続可能であることを記述している。「キャッシュによるApp Logicの継続」(203−04)はデータベースが利用できない状況でも一部キャッシュされたデータを用いてアプリケーションが継続可能であることを記述している。「丁寧なエラーを利用者に返す」(203−05)はアプリケーションの実行を続けられなくなっても何らかの説明を利用者に通知可能であることを記述している。
それらのノード(203−02〜203−05)は、その可能性を裏付ける機能をそれらのサブノードで記述している。例えば、「HDD容量の拡張」(203−02)は「HDDデバイス活線挿抜(ホットスワップ、すなわち停止させることなくディスクドライブを交換できること)」(203−06)機能、あるいは「論理ボリュームのOSサポート(ボリューム容量はディスクドライブの容量に制限されないシステム機能)」(203−07)機能によって実現可能になる。「バックアップDBSによる継続」(203−03)は「スタンバイ機再起動(データベースシステムを複数用意しておき1つの系統が停止したときに待機していたシステムを起動させて機能を引き継ぐ)」(203−08)機能、あるいは「2重系の片方のみでの継続(2系統のデータベースシステムで実現した機能をその1系統が停止しても継続できる)」(203−09)機能によって実現可能になる。「キャッシュによるApp Logicの継続」(203−04)は「DBへの変更の遅延書き込み(データベースへのアクセスをそれが復旧するまで遅らせる)」(203−10)機能、あるいは「データのタイムスタンプ(タイムスタンプを参照することで古いデータでもApp Logicを継続できる)」(203−11)機能によって実現可能になる。最後の「丁寧なエラーを利用者に返す」(203−05)は「ネットワークが到達可能(利用者までのネットワーク通信が可能)」(203−12)によって実現可能になる。
なお、これらエッジノード(203−06〜203−12)は、図5における楕円形ノード(エビデンス)によってそれらの特性の充足が記述されるが、図6では省略している。
上記図5に記載のディペンダビリティ記述データと図6に記載のディペンダビリティ記載データは、どちらかをステークホルダ間で合意されたディペンダビリティ記述データとして用いても良い。また、より上位のスコープのディペンダビリティ記述データの一部として、図5は正常系、図6はリスク系として、共にステークホルダ間で合意されたディペンダビリティ記述データとして用いても良い。
図7は、ステークホルダ要求変更に伴って変化したディペンダビリティ記述データと、図6に示したディペンダビリティ記述データとの差分を示すディペンダビリティ記述データの記述例を示す説明図である。
図6では、「HDD容量の拡張」(203−02)の可能性が当該アプリケーションの継続には重要であった。これに対して、図7では、何らかの環境の変化、例えば、ビジネスの好転によって、ステークホルダがデータベースシステムへの投資額を増やし強化する決定をした場合における、図6とは異なった時刻におけるディペンダビリティ記述データを記述している。すなわち、図6の「バックアップDBSによる継続」(203−03)の代わりに、「多重系によるDBSの無停止」(204−01)機能を採用することを決定した場合を記述している。データベースが無停止であることによって、図6の「キャッシュによるApp Logicの継続」(203−04)は不要になっている。その結果、図7の網かけされたノードが図6との差分となる。
図5から図7に示したディペンダビリティ記述データは、Safety Case表現(非特許文献2)を用いて記述しても良いし、図8、図9に示すように、D-Case表現を用いて記述しても良い。
ここで、図8を用いて、D-Case表現の基本構造を説明する。対象システムのディペンダビリティに関するステークホルダ群からの要求をトップゴール210−01として記述する。トップゴールとは、対象システムに対してステークホルダ間で合意すべき命題を表す。例えば、「対象システムは機能安全規格IEC61508で定義されているSafety Integrity Level 3を満たす」などである。当該トップゴールが満たされていることを木構造により詳細化していき、詳細化されたサブゴール210−05に対しても同様に木構造により詳細化していく。サブゴールとは、トップゴールを示すために、示すべき事を分割した命題を表す。サブゴールは、さらに小さなサブゴールに分割される。本実施の形態では、トップゴール及びサブゴールを総称してゴールと呼ぶ。当該詳細化の過程は「議論の構造」210−02と呼ばれる。
当該ゴールをサブゴールに分割する際に、当該分割の補助説明(理由・理屈)を示すストラテジを記述しても良い。例えば、図5に記載のディペンダビリティ記述データの一部をD-Case記述で表現すると図9になる。ゴールが「WEBサービスの継続」(202−01)であり、当該ゴールにリンクしている4項目である「Clientの動作継続」(202−02)、「WEB Serverの動作継続」(202−03)、「App Logicの動作継続」(202−04)、「DBSの動作継続」(202−05)は各々サブゴールであり、それら4項目をサブゴールとする理由がストラテジ「サブシステムの継続性の観点で分割」(211−01)である。
また、ゴールあるいはストラテジにはコンテキストがリンクしても良い。コンテキストはゴールやストラテジの内容を補足する情報である。例えば、図9では、ゴール202−01に対してコンテキストとして当該ゴール「WEBサービスの継続」において「継続」に関しての補足説明である「サービスが停止する場合でも1分以内で回復すること」が付与されている。
ゴールには、それが妥当であることを表明しているエビデンス210−03、210−04が存在する。エビデンスは分割され詳細化されたゴールを最終的に保証する。エビデンスの妥当性はステークホルダ間の合意に基づく。エビデンスの存在してないゴールは何らかの問題を内在している。
また、図5から図9では、ディペンダビリティ記述データを木構造で表現した。しかし、ノード間の依存関係を表現し一般的なグラフ構造で表現しても良いし、あるいは表形式で表現しても良い。以下、本実施の形態では、ディペンダビリティ記述データとして前記D-Case表現を用いて説明する。
本実施の形態では、ディペンダビリティ記述データから計算されるD値を用いてディペンダビリティの価値を計測、評価する。D値の計算は、ワークスペースコンピュータ101においては、検証ツール部101−01のD値計算部(ディペンダビリティ値決定手段)101−05が、ランタイムコンピュータ102においては、モニタリング部102−03のD値計算部(ディペンダビリティ値決定手段)102−06が行う。D値は、ワークスペースコンピュータ101においては、例えば、ディペンダビリティ記述データの検証のために用いられ、ディペンダビリティ記述データが変更される度に計算される。また、ランタイムコンピュータ102においては、例えば、ディペンダビリティ記述データに従って動作する対象システムの監視のために用いられ、対象システムの動作中はリアルタイムに計算される。
図10にディペンダビリティ記述データが表現するシステムのディペンダビリティの価値を計測、評価する手法を示す。ディペンダビリティ維持システム100にはディペンダビリティ記述データが複数存在する。トップノードは特定の特性に対するディペンダビリティの価値と定義できる。例えば、図5の「WEBサービスの継続」(202−01)は失われると困るものであり資産(asset)と考えられるので、本実施の形態では「ディペンダビリティの価値」と定義し、「D値(評価値)」と呼ぶことにする。
トップノードは複数のサブノードに分解されるので、各エッジ(リンク)を要素とする多次元ベクトルが構成できる(図10(a))。その際に、エッジに重みを付けても良い。図5を例にするなら、例えば、ノード202−05をノード202−04よりも重要である場合、202−01と202−05のエッジの重みを、202−01と202−04のエッジより大きくしても良い。また、あるノードのサブノードの数を重みとしても良い。サブノードが多いと言うことは十分に対策が検討されていることにもなるからである。このように重み付けされたエッジの多次元ベクトル値をD値とすることができる。次元数が多くなると多次元ベクトルは扱いにくいので、主成分分析法やフィッシャー判別分析法等を用いて次元削減を行っても良い。また、設計時におけるエビデンスを教師データとして学習し、後述のモニタノードによる変化を、例えばマハラノビス距離計算によって外れ値として検出することで異常の発生検知に用いても良い。
こうすることで、グラフ構造にエッジの重要性を加味した評価値が得られる。ここで得られるD値は多次元ベクトル値であるが、目的に応じた任意の変換手法によりスカラー値に変換できることはいうまでもない。
また、図10(b)は、当該特性において、有効エビデンス/総エビデンスをD値とした例である。図5では総エビデンス数は8であるが、例えば、その中で有効数が4であるときにはD値は4/8=0.5となる。
また、図10(c)は、モニタノード群におけるモニタノードでの監視点が取得したデータが変動許容範囲内であるノードと当該変動許容範囲外のノードとを色分けし、当該グラフ構造そのものをD値とする例である。なお、詳細については後述する。
こうすることで、エビデンスの状態に応じた評価値が得られる。エビデンスは要求変更に応じて変化するため、ここで得られるD値も要求変更に応じて変化する。すなわち、D値を確認することで、要求変更がディペンダビリティに与える影響を評価することができる。
また、非特許文献5の手法を用いても良い。当該文献ではD-Case記述を図11に記載の項目で再構成している。図11に示すように、「フェーズ」、「目的」、「ターゲット」、「異常」の種類の4層にD-Caseノードを再配置することで、エッジの重みを各層で一貫性のある値として扱うことが可能になり、D値を各層で比較することも可能になる。
ここで、システムに求められるディペンダビリティ要件は、そのシステムの目的により異なる。また、システムのライフサイクルの各フェーズで、ステークホルダ間の合意のための作業を円滑化する必要があるが、そのためには、ディペンダビリティ要件やその実現度合いを定量的に表現する必要がある。そこで、上記のように、D値としてディペンダビリティを定量的に表現することにより、議論するための指標(ディペンダビリティメトリクス)が実現できる。
上記のように、D値を用いることで、システム開発者は、そのシステムにおける特定のディペンダビリティ支援に関する重みを考慮して、要求そのもの、あるいは要求の実現度合いを定量化できる。また、システムの運用時には、そのシステムに不具合が発生した場合、その時点で満足し得るディペンダビリティをリアルタイムに定量化することができる。すなわち、ベンチマークや検証により得られるエビデンスとD値とを組み合わせて、ディペンダビリティ記述データを評価することが可能となる。また、動作中システムからリアルタイムにD値を得て、システムの状況を判断することが可能となる。
ここで、図12を用いて、ランタイムコンピュータ102における、モニタリング部102−03のD値計算部102−06の一実施例を説明する。D値を当該ランタイムコンピュータ102においてステークホルダ合意に基づいて実行時に計算するために、図8に記載のD-Caseに対象システム内部のどの機能を、いつ、どのように監視するかをステークホルダ間での合意の上で記述するD-Caseモニタノードを導入する(図12)。D-Case記述におけるゴールを表現するノードには、当該ゴールが満足しているエビデンスを表明するノードを関連付けることができる。この際のエビデンスに相当するノードに対象システム内部の監視点からのデータを収集し、当該データが変動許容範囲にあるかどうかを判断させるように構成できる。
変動許容範囲とは、監視点から得られたデータが基準値であるか、基準値に準じているかの範囲を示している。例えば、ネットワーク帯域の場合には、1Mbps〜2Mbpsの範囲にあれば通常の動作であると見なすことができる範囲と定義できる。アプリケーションのメモリ消費であれば、100MB以内の消費であれば通常の動作であると見なすことができる範囲と定義できる。なお、当該変動許容範囲はステークホルダ合意に基づいて設定されている。
図12において、ゴール220−01に対してはモニタノード220−03が、ゴール220−02に対してはモニタノード220−04が、それぞれリンクしている。モニタノード220−04は実行環境220−07における監視点1(220−05)からのデータを取得し、当該データが変動許容範囲にあるときにはゴール220−02を満足していることを意味している。また、モニタノード220−03は実行環境220−07における監視点2(220−06)からのデータを取得し、当該データが変動許容範囲にあるときにはゴール220−03が満足していることを意味している。
ここで、監視点1(220−05)の取得するデータはアプリケーション220−10内部の監視対象センサ220−08からデータを取得している。当該センサには、例えば、当該アプリケーションの消費しているメモリ量であったり、当該アプリケーションが外部と通信している遅延や帯域幅であったりする。一方、監視点2(220−06)の取得するデータはアプリケーション220−10内部の開始対象ログ220−09から取得している。一般に、ログから対象システムの監視対象が変動許容範囲内にあることを判断するには、ログ内部を精査する必要がある。そこで、本実施例では一例として、スクリプトを導入し、ログを精査して監視点対象が変動許容範囲にあることを判断するように構成する。なお、当該スクリプトもステークホルダ合意に基づいている。
本発明の一実施例として、ステークホルダによる当該合意を電子署名によって表現し、実行時に確認するように構成しても良い。図13にその一例を示す。図12におけるD-Case記述の概略は図13のように描けるが、ここでは3つの電子署名の有効範囲を示している。範囲211−01は全体に対する電子署名であり、範囲221−02は1組のゴールとモニタノードに対する電子署名であり、範囲221−03は1組のゴールとモニタノードとスクリプトに対する電子署名である。
前記電子署名は、その有効期限を定めるように構成可能である。例えば、開発時にのみ有効な電子署名をD-Case記述に付与したり、状況に依存した期間で有効な電子署名をD-Case記述に付与しても良い。これにより、モニタノードによるデータ取得の信頼性を高め、エビデンスとしての利用をより確実にできる。
また、電子署名のあるD-Case記述と電子署名のないD-Case記述とが混在する環境においては、電子署名のないD-Case記述を処理する場合にはデフォルトの動作を決めておくように構成できる。一般的にデフォルトの動作は、電子署名が無効である場合と同様の拒絶の処理をすべきである。しかし、状況によってはオペレータやユーザに確認を求めるように構成しても良い。
前記D-Caseモニタノードにて取得されるデータをD値計算に用いても良い。図10(c)に一例を示す。本実施例ではD-Case記述はモジュール毎に存在するように構成できる。当該D-Case記述そのものは木構造であり、その一部であるD-Caseモニタノードも木構造を構成するが、対象システム全体のD-Caseモニタノードの構造は図10(c)のような一般化されたグラフ構造を用いて構成できる。ここでは、ノード間の距離を評価するように構成しても良い。ノード群同士の直接リンクをノード間に複数のリンクがある構造よりも評価値を大きくできる。また、当該モニタノード群におけるモニタノードでの監視点が取得したデータが変動許容範囲内であるノードと当該変動許容範囲外のノードとを色分けし、当該グラフ構造そのものをD値として構成しても良い。当該色分けに際して、変動許容範囲に深刻度(Sevirity)を定義しても良い。例えば、ハードディスクの残容量に関する変動許容範囲の場合には、残容量50%と残容量10%とは異なった深刻度を与えた方が望ましい。当該グラフ構造にはモジュール間の依存関係を反映しているので、グラフ構造をD値とすることは、当該依存関係を考慮したD値をディペンダビリティの価値として扱うことができる。
さらに、図14示すように、エッジのゴール群(220−04乃至222−07)以外に、途中のゴール群(222−01乃至222−03)に前記モニタノードをリンクしても良い(223−01乃至223−03)。あるゴールにリンクされたモニターノードと当該ゴールのサブノード群にリンクされたモニタノード群との関係は、対応する監視点群の関係に相当する。例えば、ゴール2(222−02)が「商品購入サイトのサービス継続」である場合、そのサブゴールを2個に分割し、ゴール4(222−04)が「電子決済システムの継続」であり、ゴール5(222−05)が「商品DBの継続」であるように構成できる。当該ゴール群に対して、各々次のモニタノードをリンクする。モニタノード2(223−02)はゴール2(222−02)にリンクされ、例えば、スクリプトによって包括的なサービス継続シナリオを実行することで、当該ゴール2が満足していることを確認する。モニタノード4(223−04)はゴール4(222−04)にリンクされ、例えば、スクリプトによって電子決済システムに異常が無いことを確認し当該ゴール4が満足していることを確認する。モニタノード5(223−05)はゴール5(222−05)にリンクされ、例えば、商品DBに具備された死活センサからデータを受領することで当該ゴール5が満足していることを確認する。
また、次のように構成しても良い。例えば、ゴール3(222−03)が「商品候補表示システムの継続」である場合、そのサブゴールを2個に分割し、ゴール5(222−05)が「規定値アクセス数以下での正常動作」であり、ゴール6(222−06)が「規定値遅延以内での正常動作」であるように構成しても良い。当該ゴール群に対して、各々次のモニタノードをリンクする。モニタノード6(223−06)はゴール6(222−06)にリンクされ、例えば、スクリプトによって規定値アクセス数以下で正常に動作していることを確認することで、当該ゴール6が満足していることを確認する。モニタノード7(223−07)はゴール7(222−07)にリンクされ、例えば、対象システムのWEBサーバに組み込まれたセンサのデータを取得して規定値以下の遅延で正常に動作していることを確認することでゴール7が満足していることを確認する。この場合には、ゴール3(222−03)にリンクされたモニタノード3(223−03)は、サブゴールである当該ゴール6と当該ゴール7が共に満足していることを確認することで、当該ゴール3が満足されていることを確認したこととするように構成できる。以上のように、モニタノード群をグラフ構造によって構成することで、上記D値をグラフ構造を計算することで取得し、システムの状況を判断することができる。
なお、本発明は以下のように構成してもよい。
本発明のディペンダビリティ維持装置(ディペンダビリティ維持システム100、ワークスペースコンピュータ101、ランタイムコンピュータ102)は、不完全性と不確実性が潜在的に存在するオープン環境におけるシステム開発及びシステム運用、さらにシステムが提供するサービスにおけるディペンダビリティを持続的に維持する目的で、かつ、ステークホルダ間における要求の誤解、環境の変化に対する対応不能、障害対応の失敗という3つの問題に対応する目的で、ディペンダビリティに関して時間軸上で変化可能なある時刻におけるディペンダビリティ記述データ(データ構造としては、例えば、木構造モデル)を備えるシステムにおいて、当該ディペンダビリティ記述データを計算することができ、それによって当該ディペンダビリティ記述データが表現するシステムのディペンダビリティの価値を計測、評価するものであってもよい。
このように、前記ディペンダビリティ維持装置は、ディペンダビリティに関して時間軸上で変化可能なある時刻におけるディペンダビリティ記述データを備えるシステムにおいて、ディペンダビリティの価値を計測、評価することができる。したがって、ステークホルダ間における要求の誤解、環境の変化に対する対応不能、障害対応の失敗という3つの問題に対処することでディペンダビリティを維持することが可能となるという効果を奏する。
また、本発明は以下のように構成してもよい。
本発明のディペンダビリティ維持装置(ディペンダビリティ維持システム100、ワークスペースコンピュータ101、ランタイムコンピュータ102)は、対象システムのディペンダビリティを維持するためのディペンダビリティ維持装置であって、対象システムのディペンダビリティに関する仕様を記述したディペンダビリティ記述データを取得する記述データ取得手段(ディペンダビリティ記述データ入力部901−01、ソフトウェア入力部902−01)と、上記記述データ取得手段が取得したディペンダビリティ記述データに基づいて、上記対象システムのディペンダビリティの価値を定量的に示す評価値(D値)を求めるディペンダビリティ値決定手段(D値計算部101−05、D値計算部102−06)と、を備えて構成されても良い。
これにより、対象システムのディペンダビリティの価値が定量的に表現できる。したがって、例えば、要求変更に伴ってディペンダビリティ記述データを変更するときや、対象システムの運用時に対象システムの状態を確認するときに、対象システムのディペンダビリティの価値を分かりやすく客観的に提示することができる。よって、対象システムのディペンダビリティの維持を円滑に行うことが可能となる。
さらに、本発明のディペンダビリティ維持装置(ディペンダビリティ維持システム100、ワークスペースコンピュータ101、ランタイムコンピュータ102)は、上記ディペンダビリティ記述データがノード間のエッジに重み付けが可能な木構造あるいはグラフ構造を有するデータであり、上記ディペンダビリティ値決定手段(D値計算部101−05、D値計算部102−06)は、上記エッジに重み付けされた重みを要素とする多次元ベクトル値を上記評価値(D値)とするように構成されても良い。
これにより、木構造あるいはグラフ構造に、エッジの重要性を加味した評価値が得られる。よって、評価値を確認することで、エッジに重み付けの変更がディペンダビリティに与える影響を評価することができる。なお、ここで得られる評価値は多次元ベクトル値であるが、目的に応じた任意の変換手法によりスカラー値に変換できることはいうまでもない。
さらに、本発明のディペンダビリティ維持装置(ディペンダビリティ維持システム100、ワークスペースコンピュータ101、ランタイムコンピュータ102)は、上記ディペンダビリティ値決定手段(D値計算部101−05、D値計算部102−06)は、上記ディペンダビリティ記述データに含まれるエビデンスの総数である総エビデンス数に対する、上記対象システムをモニタして取得されたモニタ値が変動許容範囲に対して良好であったエビデンスの数である有効エビデンス数の割合を上記評価値(D値)として計算するように構成されても良い。
これにより、エビデンスの状態に応じた評価値が得られる。エビデンスは要求変更に応じて変化するため、ここで得られる評価値も要求変更に応じて変化する。すなわち、評価値を確認することで、要求変更がディペンダビリティに与える影響を評価することができる。
さらに、本発明のディペンダビリティ維持装置(ディペンダビリティ維持システム100、ワークスペースコンピュータ101、ランタイムコンピュータ102)は、上記ディペンダビリティ記述データをグラフ構造として評価し、上記ディペンダビリティ値決定手段(D値計算部101−05、D値計算部102−06)は、当該グラフ構造を計算して、例えばノード間距離や深刻度を計算式に組み込み評価値(D値)を算出しても良い。
これにより、モニタノード群により得られるデータに応じた評価値が得られる。モニタノード群は対象システムの実行時の状況に応じて変化するため、ここで得られる評価値も当該実行状況に応じて変化する。すなわち、当該評価値を確認することで、実行状況がディペンダビリティに与える影響を評価することができる。
また、本発明のディペンダビリティ維持システム100は、対象システムのディペンダビリティを維持するためのディペンダビリティ維持システムであって、上記対象システムの開発時あるいは更新時に、上記ディペンダビリティ記述データを仕様の変更に合わせて変更する変化対応サイクルP300を実行するワークスペース装置(ワークスペースコンピュータ101)と、上記対象システムの運用時に、障害発生または障害予兆を検知したとき、上記ディペンダビリティ記述データに基づいて、上記対象システムの停止を回避する障害対応サイクルP301を実行するランタイム装置(ランタイムコンピュータ102)とを含み、上記ワークスペース装置および上記ランタイム装置の少なくともいずれか一方が、上記ディペンダビリティ記述データに基づいて、上記対象システムのディペンダビリティの価値を定量的に示す評価値(D値)を求めるように構成されても良い。
さらに、本発明のディペンダビリティ維持システム100は、他のディペンダビリティ維持システム100とネットワークを介して接続されていても良い。すなわち、本発明のディペンダビリティ維持システム100は、複数、ネットワークを介して接続されていても良い。
〔3.二つのプロセス〕
図15を用いて、ディペンダビリティ維持システム100が有する反復的プロセスに関して、また、図16を用いて、当該反復的プロセスを実現するためのアーキテクチャに関して説明する。
オープンシステムディペンダビリティ、すなわち、機能、構造、システム境界が時間とともに変化し続けるシステムに対するディペンダビリティの実現の為には、反復的プロセスとしてのアプローチが必須である。当該反復的プロセスは、目的(Objectives)や環境の変化に対してシステムを継続的に変更していくためのサイクル(変化対応サイクルP300)と、障害に対して迅速に対応するためのサイクル(障害対応サイクルP301)を備えている必要がある。当該反復的プロセスは、構成要素として要求マネジメントプロセス250−01、開発プロセス250−02、通常運用プロセスS302、障害対応サイクル250−04、説明責任遂行プロセス250−05等を含む「プロセスのプロセス(Process of Processes)」である。当該構成要素プロセスは相互に有機的に結びつけられる必要がある。本実施の形態では当該反復プロセスをDEOSプロセスと呼ぶ。
対象システムのディペンダビリティに関する利害関係者をDEOSプロセスにおいては「ステークホルダ」と呼ぶ。ステークホルダとしては、以下を想定している。1)サービス・製品の利用者(顧客、社会的インフラの場合は社会全体)、2)サービス・製品の提供者(事業主)、3)システム提供者(設計開発者、保守運用者、ハードウェア供給者)、4)サービス・製品認可者(規制監督官庁)。
ステークホルダは時間の経過や環境の変化によってそれぞれの目的を変化させ、機能やサービスに対する要求を変化させる可能性がある。これらの変化をここでは「目的・環境変化」と呼ぶこととする。これらの変化に対し、当該ステークホルダは熟慮し、相互に合意したうえで、適切な時期にシステムの変更を要求する。DEOSプロセスはこのような要求に対するサイクルとして、「変化対応サイクル」(P300)を備える。
対象システムは不完全さと不確実さに起因する障害を完全に回避することがきわめて困難である。障害の予兆を検出した場合には障害を未然に回避し、不幸にも障害が発生してしまった場合には迅速に対応して被害を最小化し、原因を究明し、説明責任を遂行する必要がある。DEOSプロセスではそのような状況に対応するために「障害対応サイクル」(P301)を備える。
新規にシステムを開発し、また、目的・環境の変化に対応してシステムの変更を行う場合、その理由やステークホルダ間で行われた議論の過程、合意内容などを詳細に記録するための合意記述データベース250−06を備えていることが効果的な前記反復的プロセスを実現し、説明責任を遂行するために必須である。当該データベースにはディペンダビリティを達成するための議論や根拠を記述した前記D-Case、障害に対してサービスを継続するためのシナリオを基に障害予兆の検出や障害発生に迅速に対応するための実行手続きを記述したスクリプト(詳しくは後述するが図中ではD-Scriptとして記載)が含まれている。そして、これらの合意記述を基に開発プロセス250−02、障害対応サイクル250−04、通常運用プロセスS302が実行され、また、説明責任遂行プロセス50−05を支援することができる。合意記述データベース250−06は前記構成要素プロセスを有機的に繋ぐ重要な役割を果たす。
前記DEOSプロセスの特徴をまとめる。1)「通常運用」(S302)から開始される「変化対応サイクル(P300)」と「障害対応サイクル(P301)」の2つのサイクルから成り立っていること。2)システム変更要求のための「ステークホルダ合意」(250−07)と、システム変更や障害対応の「説明責任遂行」(250−05)の2つのフェーズが組み入れられていること。3)ステークホルダ間で利害関係を調整し、ディペンダビリティを達成するために議論した過程、論拠、結果等を記述した前記「D-Case」と障害に迅速に対応するための実行手続きを記述した「スクリプト」を含む合意記述データベース250−06を備え、構成要素プロセスを有機的に結合すること。
図15において通常運用S302はディペンダビリティ維持システム100が通常運用状態にあることを示している。当該通常運用S302はシステムがステークホルダ間で合意されたサービスレベル変動許容範囲(In-Operation Range)から大幅な逸脱がなく、ユーザに対してサービス提供を継続している状態である。変化対応サイクルP300は通常運用と並行して実行され、サービスの提供を継続しつつシステムの変更が行われることが望ましい。同様に、障害対応サイクルP301も通常運用を継続しながら実行されることが望ましい。実際、システムが異常の予兆を検知しても、当該スクリプトに記されたサービス・機能レベル変動許容範囲内で自動的に回避処理が働いてサービスが継続される場合がある。あるいは一部の機能を縮退してサービスを継続している場合もある。しかしながらサービスの提供が完全に停止されてしまう場合もある。
通常運用状態S302において実行されるプロセスには、日常的な動作記録の点検、プロセスの定期的な見直し・改善、要員の訓練・しつけ・教育など、継続的なディペンダビリティ向上活動が含まれる。システムの稼働状況を記録し、日々点検する事により保守担当者や運用担当者が、何かの兆候をそこから見出す事ができる可能性がある。また、システムのメモリー資源を常にクリーンな状態にすることも、非常に有効な日常保守・改善活動である。あるいは、積極的に予行を行うことも有効である。障害はある時間が経過してある状態に達した時発生する。であれば、時間を先に経過させると障害の発生を事前に知ることができる。いわゆるリハーサルである。情報システムの提供するサービスの運用時において、どの程度適切なリハーサルができるのかはその時の状況による。
障害対応サイクルP301に関して概説する。障害対応サイクルP301は障害に対して迅速に対応して障害による被害を最小化するためのサイクルである。DEOSプロセスでは「障害」をステークホルダ間で合意されたサービス・機能レベル変動許容範囲から逸脱する事象と定義する。障害対応サイクルにおける主要なフェーズは、「未然回避」(250−10)、「迅速対応」(250−09)、「原因究明」(250−08)であり、障害が発生した場合は「説明責任遂行」が必須である。当該3フェーズはそれぞれ別個に、かつ順番に行われるとは限らない。多くの場合、これらはお互いが関連しあい、渾然一体となった事象・活動となる。
未然回避フェーズ250−10は、システムの運用中に障害が発生する前に障害発生を予知したり、あるいは障害が起きる可能性の増大を検出すると、障害を回避するように対応・動作するフェーズである。障害の予知が障害の発生予想時刻の充分に前であれば効果的な対策が打てる。例えばシステムの資源を制限してスループットを下げてシステムダウンを回避したりシステムダウンまでの時間を稼いだりすることが行われる。直前に予知した場合には障害の影響の最小化に努力することになる。また、原因解析に有効な、障害に至るまでのシステムの内部情報を記録することができる。予知のための具体的な方法としては、過去の障害パターンから類似の障害を判別することなどがある。未然回避シナリオはスクリプトとして事前に記述され、オペレータやシステム管理者と協調して未然回避動作が実行される。
迅速対応フェーズ250−09は、障害が起きた時にその影響を最小化するためのフェーズである。障害に対する迅速対応のシナリオはスクリプトとして事前に記述されており、自動的に行われるのが望ましい。しかしながら、想定しない障害に対応しなければならない場面もある。対応分野や領域ごとの目的に応じたサービス継続のための緊急対応計画(責任者や対応組織、手順、エスカレーションパスなどが記されている)を事前に立てて、ステークホルダ間で合意しておくことが求められる。当該計画の指示に基づきオペレータやシステム管理者と協調して迅速に障害による影響を最小化することになる。すなわち、障害を分離して影響の局所化を行い、サービス全体のダウンを回避する。そのために障害が発生したアプリケーションやシステムの一部分のオペレーションを中断し、リセットし、その後にオペレータやシステム管理者による復帰活動が行われる。
原因究明フェーズ250−08は、障害対応サイクルP301と変化対応サイクルP300に関連したフェーズである。サイクルにより深さの違う判断がなされる。障害対応サイクルP301では、どのような迅速対応が可能であるかを見極めることを目的とした原因究明がおこなわれる。その結果によっては変化対応サイクルP300が開始される。
説明責任遂行フェーズ250−05では、サービス提供者、特に社会インフラサービス提供者や社会に広く使われる製品提供者が、障害発生時にサービス利用者、製品使用者、社会に対し、障害状況、迅速対応、今後の見通しなど説明する。これは利用者や社会からの信頼を維持し、インフラサービス提供上のコンセンサスを醸成し、ひいてはサービス提供者のビジネス遂行上の便益を守るという大変重要な役目を持つ。合意記述データベース特にD-Case記述と、システム監視記録が説明責任遂行に大いに役立つ。
変化対応サイクルP300に関して概説する。変化対応サイクルP300はステークホルダの目的の変化や、各種外部環境の変化に対応するためのサイクルである。このサイクルにおける主要なフェーズは、システム変更のための「要求抽出・リスク分析」(250−11)、「ステークホルダ合意」(250−07)、「設計・実装・検証・テスト」(250−02)である。大きな変化に対応する場合は「説明責任遂行」(250−05)が必須となる。障害対応サイクルP301における原因究明フェーズ250−08の実行の結果、システムの根本的な改良の要求が発生した場合も、変化対応サイクルP300が開始される。
要求抽出・リスク分析フェーズ250−11は目的や環境の変化によりステークホルダからの要求が変化(新規の要求も含む)した場合、あるいは障害発生に迅速に対応した後、原因究明を行った結果、システムを変更する必要がある場合が始まる。いずれの場合も、事業主のサービス目的をベースにユーザの要求、システム環境、関連する法律や国際標準を勘案し、システムの機能要件を抽出する。また同時に、サービス目的からシステムのサービス継続シナリオを作成してリスク分析を行い、ディペンダビリティ要件を含む非機能要件を抽出する。
ステークホルダ合意フェーズ250−07では、何をどのように変更するのかを、すべてのステークホルダに分かりやすく、誤解のないように記述し、ステークホルダ間の議論を経て、合意をD-Caseとして記述する。またサービス継続シナリオを作成し、その実行手続きであるスクリプトを作成する。要求抽出・リスク分析フェーズ250−11と当該ステークホルダ合意フェーズ250−07が「要求マネジメントプロセス」(250−01)を構成する。
設計・実証・検証・テストフェーズ250−02は、いわゆる設計開発のプロセスである。ここでは、これまで多くの研究がなされ、多くの手法やツールが出されている。
説明責任遂行フェーズ250−05では、目的や環境変化によるステークホルダの要求変化を満たすためにシステムを変更した場合、その経緯と、いつからどのようにサービスや機能がよくなるのか(変化するのか)を説明する。また、日常のサービス遂行状況や設計開発・保守運用プロセスに関する説明が必要なときもこれに対応する。これは利用者や社会からの信頼を維持し、インフラサービス提供上のコンセンサスを醸成し、ひいてはサービス提供者のビジネス遂行上の便益を守るという大変重要な役目を持つ。合意記述データベース250−06に記録されている特にD-Case記述が説明責任遂行に大いに役立つ。
〔4.DEOSアーキテクチャ〕
前記DEOSプロセスは広範なオープンシステムに対するディペンダビリティを実現するための反復的プロセスを提供している。このプロセスをより具体的に対象とするシステムに適用した場合、対象のカテゴリー毎にプロセス実行のためのアーキテクチャを考える必要がある。本実施例では、組込みシステムを含む現代の大規模かつ複雑なソフトウェアシステムへの適応を念頭に考案されたアーキテクチャ(DEOSアーキテクチャと呼ぶ)について述べる。前記DEOSプロセスと当該DEOSアーキテクチャを並べて眺めるとDEOSプロセスが実際のシステムでどのように実行されるかが理解できる。
図16を用いて、当該DEOSアーキテクチャに関して説明する。当該アーキテクチャは次の構成要素から構成される。1)要求抽出・リスク分析フェーズを支援するツール群260−01(101−05)、2)ステークホルダ合意フェーズを支援する合意形成支援ツール群260−02(101−05)、3)合意の記述であるD-Caseとサービス継続シナリオの実行手続きであるスクリプト(図中ではD-Scriptとして記載)を含む合意記述データベース250−06、4)DEOS実行環境260−03、5)プログラム検証ツールとベンチマーキングならびにフォールトインジェクションテストのためのツール群を含むDEOS開発支援ツール260−04。
要求抽出・リスク分析フェーズ250−11は事業主のサービス目的260−05を基にユーザの要求、システム環境、関連する法律や国際標準を勘案し、システムの機能要件を抽出し、想定される障害に対するサービス継続シナリオを作成してリスク分析を行い、ディペンダビリティ要件を含む非機能要件を抽出する。
ステークホルダ合意フェーズ250−07は合意を形成するための方法と合意記述の記法に基づいて合意内容をD-Caseとして記述する。そのためのツールがD-Case Editor(260−06)ならびにD-Case Viewer(260−07)である。また、サービス継続シナリオに基づいた実行手続きスクリプト260−08も作成される。当該スクリプトはDEOSアーキテクチャにおいてD-Case記述とアプリケーションプログラムの実行を動的に結合する役割を果たしている。当該スクリプトには後述のスクリプトエンジン(図中ではD-Script Engineとして記載)が実行するシナリオが書かれている。そのシナリオはDEOS実行環境260−03に対して、1)いつ、どのようなログ情報を収集するかを指示し、また、2)障害発生時においては障害に対してどのように対処するかを指示している。この時、エスカレーションルールに従ってオペレータの介入を指示する場合もある。このように、当該スクリプトは動的かつ双方向に情報を交換することによりアプリケーションプログラムの実行を柔軟に制御し、オープンシステムディペンダビリティの達成に寄与している。
DEOS実行環境260−03はステークホルダ合意に基づくディペンダビリティを実現するサービスを提供するための実行環境であり、次のサブシステムから構成される。D-Visorは対象システムの再構成のため、システムの構成要素の各々の独立性を担保する仕組み(System Container)を提供する。あるSystem Container内における異常や障害が他のSystem Containerに波及することを抑える働きを担っている。D-Application Managerは複数のアプリケーションの独立性を担保する仕組み(Application Container)を提供し、各アプリケーションのライフサイクル(生成、起動、更新、停止、削除)を管理し制御する。D-Application Monitorはアプリケーションの動作監視機能を提供し、D-Caseモニタノードの記載に従ってエビデンスを収集し、D-Boxに蓄積する。D-System Monitorはシステム(オペレーティングシステムやランタイムサポートを含む)の動作監視機能を提供する。D-Application Monitor同様にD-Caseモニタノードの記載に従ってエビデンスを収集し、D-Boxに蓄積する。D-Boxはエビデンスを始め、OSD実現に有益な情報を安全・確実に記録する。D-Script EngineはD-Scriptを安全・確実に実行する役割を担い、D-Application Manager、D-Application Monitor、D-System Monitorを制御する。
DEOS開発支援ツール260−04は事業目的や事業継続シナリオに基づいて決められた機能仕様、テスト仕様、ベンチマーキングシナリオ、さらにはログ仕様に基づいてプログラムを設計し、開発し、検証し、ベンチマーキングを行い、テストを行うための開発支援ツール群である。例えば、型理論ならびにモデル検証に基づいたソフトウェア検証ツール、ベンチマーキング並びにフォルトインジェクション機能を備えたディペンダビリティテスト支援ツール等がある。
前記DEOSプロセスを適用することにより享受できる最大の利点は、ステークホルダ間で要求の変化に対する合意議論を充分に行うことができ、合意結果や、その結論に至った理由や、議論の経緯をD-Caseに記録することができる点である。システム開発時にD-Case記述を用いることにより、前記DEOSアーキテクチャと連携して、障害時に適切かつ迅速な対応を取ることが可能なシステムを設計することができる。またD-Case記述があることにより、障害の原因究明や説明責任を果たすことがより容易になる。
前記DEOSプロセスのもう一つの利点は、要求が適切に抽出されリスクが充分検討されたのちに、システムの変更が実行される点である。それぞれのステークホルダはシステムの状態をどんな時点でも、それぞれの観点で知ることができる。これによりシステムを簡潔かつ強力に管理運用することができる。一方、要求の数は膨大である。D-Case Editor(260−06)やD-Case Viewer(260−07)などのツールが要求マネジメントにおける作業を軽減する。
前記DEOSアーキテクチャを具現化したDEOS実行環境260−03は、モニタリング機能を備え、D-Caseを基に、解析に必要なシステムやアプリケーションの実行状態の監視と記録を実行する。 当該実行環境はこの監視記録とスクリプトに従って障害時の迅速対応を実行する。またD-Case記述や監視記録から得られた情報をエビデンスとして原因分析や説明責任を遂行する。スクリプトとスクリプトエンジンはD-Caseと当該実行環境の橋渡しを果たしており、この仕組みにより、システムの自動的、あるいは必要であればオペレ―タを介した(D-Case記述に基づく)柔軟な対応を可能にする。
また前記DEOS-アーキテクチャは、あるモジュールにおける障害が他のモジュールに伝搬することを隔離する機能を提供する。同様にシステムのセキュリティを守るために外部からの侵入を検知する機能も提供する。またディペンダビリティ達成のための、実行前にプログラムを検証するツール、パフォーマンスを測定するツール、フォルトを埋め込んで異常時の振舞いをテストする開発ツール等も提供する。
上記の仕組みや機能を利用することにより、前記DEOSプロセスと前記DEOSアーキテクチャは、継続的な障害回避のための能力を備え、障害時には適切かつ迅速な対応をして、その影響を最小限とする。またサービスを継続し、説明責任を遂行することができる。前記DEOSプロセスと前記DEOSアーキテクチャはオープンシステムディペンダビリティを達成するための初めての取り組みである。
〔5.実行(ランタイム)環境〕
図17を用いて本発明における一実施例に係る前記DEOSプロセスを構成する変化対応サイクルP300と障害対応サイクルP301の一連の手順を説明する。当該両サイクル共に通常は通常運用S302の状態にある。
変化対応サイクルP300において、ビジネス環境の変化等の環境の変化によるステークホルダ要求の変更、開発途中における要求の変更、及び/又はシステム運用時における要求の変更が起こると、変化対応サイクルP300は環境変化S300−01の状態に遷移する。
まず、要求の変更S300−02をワークスペースコンピュータ101(図1参照)の解析ツール部101−03を用いて行う。ここではステークホルダ群からの要求を抽出後に、当該要求の変更がランタイムコンピュータ102に与える影響を分析したり、具体的な変更手段を分析したり、変更箇所を分析したりする。
次に、ディペンダビリティ記述データの変更S300−03を編集ツール部101−02及び/又は開発ツール部101−04を用いて、要求の変更S300−02での分析結果を基にして行う。ここでは、ソフトウェアSWにその結果が反映される。
次に、変更が要求通りであることを、エビデンス計測S300−04にて、検証ツール部101−01を用いて確認する。
最後に、ソフトウェアSWをデプロイメントS300−05にてランタイムコンピュータ102に導入する。その後、変化対応サイクルP300は通常運用S302になる。
また、障害対応サイクルP301において、ランタイムコンピュータ102(図1参照)に障害が発生した場合には、障害発生S301−01の状態に遷移する。まず、対応策抽出S301−03においてランタイムコンピュータ102を停止させることなく、当該障害に対応する対応策を抽出する。
次に、緊急対応S301−04にて当該対応策を実行することで、ランタイムコンピュータ102におけるモデルに基づく処理を継続させる。
次に、記録S301−05では当該緊急対応を記録部102−02により記録する。ここでは当該障害に関連する情報も記録部102−02により記録される。ランタイムコンピュータ102はこの時点で継続されていることが望ましいが、障害によっては当該対応策でも継続が不可能な場合がある。継続・不継続のいずれの場合でも原因究明S301−06を行う。これにより、当該障害の原因、および、ランタイムコンピュータ102がモデルに基づく処理が不継続の場合にはその原因が究明される。その結果次第では、要求の変更をともない、変化対応サイクルP300を環境変化S300−01の状態に遷移させる。
一方、障害対応サイクルP301において、故障(あるいは故障の予兆)が見つかった場合、あるいは障害の予兆が見つかった場合には、障害予兆S301−02の状態に遷移する。故障(あるいは故障の予兆)の発見はランタイムコンピュータ102のモニタリング部102−03によりなされる。障害の予兆の発見も当該モニタリング部102−03によってなされる。具体的には、ランタイムコンピュータ102のバイナリ実行部110における各種の計算資源の消費履歴を調べることによって可能である。例えば、メモリ残量が一定時間内で減少を続けている場合には近い将来メモリ不足で計算が停止することがわかる。
まず、対応策抽出S301−03においてランタイムコンピュータ102における処理を停止させることなく、前記故障(あるいは故障の予兆)の発生、あるいは障害の予兆に対応する対応策を抽出する。
次に、緊急対応S301−04にて当該対応策を実行することで、ランタイムコンピュータ102を継続する。
次に、記録S301−05では当該緊急対応を記録部102−02により記録する。ここでは当該障害に関連する情報も記録部102−02により記録される。ランタイムコンピュータ102におけるモデルに基づく処理はこの時点で継続されていることが望ましいが、障害によっては当該対応策でも継続が不可能な場合がある。継続・不継続のいずれの場合でも原因究明S301−06を行う。これにより、前記障害の原因、および、ランタイムコンピュータ102におけるモデルに基づく処理が不継続の場合にはその原因が究明される。その結果次第では、要求の変更をともない、変化対応サイクルP300を環境変化S300−01の状態に遷移させる。
なお、上述のように、前記変化対応サイクルP300と障害対応サイクルP301は同時に存在する。
なお、本発明は以下のように構成してもよい。
本発明のディペンダビリティ維持装置(ディペンダビリティ維持システム100)は、前記ディペンダビリティ記述データを備えるシステムにおいて、環境の変化に起因するステークホルダの要求の変更、システム開発途中における要求の変更、及び/又はシステム運用時における要求の変更に対処するためのプロセスと、システム運用時におけるシステムが提供するサービスを障害発生に際しても継続するように対処し、及び/又はシステム運用時におけるシステムが提供するサービスを停止させないように障害の予兆を検知し障害の発生を未然に回避するプロセスという2つの手段を同時に備えていてもよい。
このように、前記ディペンダビリティ維持装置は、不完全性と不確実性とを潜在的に有するオープン環境において、環境の変化に起因するステークホルダの要求の変更、システム開発途中における要求の変更、及び/又はシステム運用時における要求の変更に対処するためのプロセスと、システム運用時におけるシステムが提供するサービスを障害発生に際しても継続するように対処し、及び/又はシステム運用時におけるシステムが提供するサービスを停止させないように障害の予兆を検知し障害の発生を未然に回避するプロセスという2つの手段を備えることにより、従来の開発フェーズと運用フェーズの垣根を無くし、ステークホルダのアカウンタビリティ達成を可能にすると共に、ディペンダビリティを維持することが可能となる効果を奏する。
また、本発明は以下のように構成してもよい。
本発明のディペンダビリティ維持装置(ディペンダビリティ維持システム100、ワークスペースコンピュータ101、ランタイムコンピュータ102)は、上記対象システムの開発時あるいは更新時に、上記ディペンダビリティ記述データを仕様の変更に合わせて変更する変化対応サイクルP300、および、上記対象システムの運用時に、障害発生または障害予兆を検知したとき、上記ディペンダビリティ記述データに基づいて、上記対象システムの停止を回避する障害対応サイクルP301の少なくとも何れか一方を実行するように構成されても良い。
障害対応サイクルP301において、障害発生S300−01の状態に遷移することによる一連のステップは制御工学におけるフィードバック処理に相当し、障害予兆S300−02の状態に遷移することによる一連のステップは制御工学におけるフィードフォワード処理に相当する。従って、当該フィードバック処理の結果を学習することで、対応モデルを構築し、当該フィードフォワード処理に役立てるように構成することもできる。また、その際の当該モデルがディペンダビリティ記述データへの変更として記録することができるように構成しても良い。また、当該フィードフォワード処理においては、他のシステムにおける対応モデルを上記ディペンダビリティ記述データに記述することで、ステークホルダ群が合意した状態で当該モデルに対応する障害予兆に対してプロアクティブな回避処理を行うように構成することもできる。
オープン環境において対象システムのディペンダビリティを継続的に維持するためには、要求変化や環境変化に対応して十分に検討して対処する変化対応サイクルP300と、運用中の障害発生に迅速に対応する障害対応サイクルP301との両方が必要である。
そこで、上記のように構成することにより、変化対応サイクルP300および障害対応サイクルP301の少なくともいずれか一方において、対象システムのディペンダビリティの価値を示す評価値を求めることができる。したがって、例えば、変化対応サイクルP300において、要求変更に伴ってディペンダビリティ記述データを変更するときに、評価値に基づいて、ディペンダビリティ記述データの変更案の適否を判断することが可能となる。また、例えば、障害対応サイクルP301において、対象システムの運用時に対象システムの状態を、評価値に基づいて判断することが可能となる。よって、対象システムのディペンダビリティの維持を円滑に行うことが可能となる。
〔6.変化対応サイクル〕
図18は、図17に示したワークスペースコンピュータ101で作業される変化対応サイクルP300における、ステークホルダ間での合意形成処理S400、要求変更の実装処理S401、アカウンタビリティ処理S402の3つのステップを図示している。
ステークホルダ間での合意形成処理S400は要求の変更S300−02とディペンダビリティ記述データの変更S300−03と関係している。ステークホルダ間での合意形成処理S400は、要求変更の内容を理解するステップ(要求変更の理解S400−01)から始まる。それには、例えば、“IEEE Std 830-1998 IEEE Recommended Practice for Software Requirements Specification”に準拠したSRS(ソフトウェア内部仕様書)を分析する。
次に、影響分析S400−02で既存のディペンダビリティ記述データに対する変更点を列挙する。
最後に、当該変更点をディペンダビリティ記述データの変更S400−03において当該ディペンダビリティ記述データの変更として反映させる。
これらのステップはステークホルダ間で合意S400−04されるまで繰り返される。
また、要求変更の実装処理S401はディペンダビリティ記述データの変更S300−03とエビデンス計測S300−04と関係している。要求変更の実装処理S401は、設計S401−01のステップから始まる。設計S401−01では開発ツール部101−04を利用して要求変更を実際のコードに変換するためのソフトウェア設計が、例えば能力成熟度モデル統合(Capability Maturity Model Integration, CMMI)に従って行われる。
次に、実装S401−02では、設計S401−01での設計を開発ツール部101−04を利用してソフトウェアSWに変換する。
次に、テストS401−03では、全ステップでのソフトウェアSWを検証ツール部101−01を用いてテスト、検証する。
これらのステップはテストS401−03での検証が全てOKとなるまで繰り返される。検証が全てOKとなると、導入S401−04で当該ソフトウェアSWをランタイムコンピュータ102に導入する。
また、アカウンタビリティ処理S402はエビデンス計測S300−04とデプロイメントS300−05と関係している。アカウンタビリティS402は、ベンチマーク等収集S402−01のステップから始まる。ベンチマークはランタイムコンピュータ102で実行され計測されても良いし、ランタイムコンピュータ102をシミュレーションする環境上で実行され計測されても良い。
次に、収集されたベンチマークデータが要求を満足しているか検証される(エビデンス検証S402−02)。
最後に、ステークホルダは当該検証されたデータをエビデンスとして必要に応じて情報開示する(情報開示S402−03)。なお、情報開示S402−03により、ステークホルダがアカウンタビリティを達成(S402−04)することができる。
なお、本発明は以下のように構成してもよい。
本発明のディペンダビリティ維持装置(ワークスペースコンピュータ101)は、上記環境の変化に起因するステークホルダの要求の変更、システム開発途中における要求の変更、及び/又はシステム運用時における要求の変更に対応するためのプロセスにおいて、それら要求を入力として、当該要求の変更の発生を起点とした一連のステップから構成されるループを形成する当該プロセスにおいて、当該要求の変更を確実に実装しシステム運用しサービスを提供できるようにステークホルダ間で要求の変更の合意を形成するステップと、当該要求の変更を実装し検証しシステム運用するステップと、当該要求の変更によるシステム運用とサービス提供によりステークホルダがアカウンタビリティを達成するステップという3つのステップを実行しても良い。
〔7.障害対応サイクル(迅速対応)〕
図19は、障害対応サイクルP301のうち、障害発生検出時の2つの処理を示すフローチャートである。なお、図19における障害対応サイクルP301は図17の再掲である。
障害発生S301−01はモニタリング部(障害発生検出手段)102−03によって障害の発生が検出されると当該状態に遷移する。モニタリング部102−03は、例えば、D値が所定の変動許容範囲より悪化したとき、障害発生を検出する。障害発生検出時の障害対応サイクルP301には2つの機能が関係している。システム再構成処理S502とアカウンタビリティ処理S503である。
システム再構成処理S502は対応策抽出S301−03と緊急対応S301−04に関係している。システム再構成処理S502はサービス継続判断S502−01から始まる。ここでは、障害に該当する部分のディペンダビリティ記述データを抽出する。当該ディペンダビリティ記述データからシステム再構成シナリオが抽出可能である場合には(S502−01でYES)、次のステップに進む。なお、ディペンダビリティ記述データからシステム再構成シナリオが抽出不可能である場合には(S502−01でNO)、継続不可能と判断して、ディペンダビリティ記述データの変更抽出処理S800(図27)を実行する。
システム再構成シナリオはシステム設計時点であらかじめ典型的なケースに関しては組み込んでおいても良い。例えば、後述のアプリケーション・コンテナあるいいはシステム・コンテナを再起動するシナリオはその一例である。また、当該再構成シナリオを後述同様にディペンダビリティ記述データにおけるノードに実行可能なプログラムを関連つけても良い。いずれの手法においても、当該再構成シナリオが抽出できない場合には、ディペンダビリティ記述データを変更するために、変化対応サイクルP300を実行する準備をする。また、当該再構成シナリオを後述のスクリプトとして記述し、ディペンダビリティ記述データに関連つけても良い。
次に、障害部位隔離S502−02では当該抽出されたシナリオに従って障害部位を隔離し、ディペンダビリティ記述データの違いをランタイムコンピュータ102に反映させ、次ステップに進む。
次に、サービス継続S502−03では当該シナリオに従って隔離された部位の代替機能が当該シナリオによって起動され、サービスが継続される(S502−04)。
一方、アカウンタビリティ処理S503は記録S301−05と原因究明S301−06に関係している。アカウンタビリティ処理S503は障害に関係するログを記録する(S503−01)ことから始まる。
次に、前記シナリオに従って再構成されたランタイムコンピュータ102のエビデンスを収集する(S503−02)。ここでのエビデンスとはシステム再構成によってランタイムコンピュータ102がディペンダビリティ記述データに従って適切に動作していることの記録である。
次に、障害原因検出S503−03に進む。ここでは、障害に関係する前記ログ(S503−01)、前記エビデンス(S503−02)、及び前記障害に関係したディペンダビリティ記述データをまとめたものである。本実施の形態では、当該まとめをステークホルダによるアカウンタビリティの達成とする。なお。これらのステップ(S503−01及びS503−02)は並列に処理されても良い。
図20にモニタリング部102−03による障害発生検出処理の一例を示す。
図20(a)はディペンダビリティ記述データの一部(510)を示す。ディペンダビリティ記述データを作成する際に、実行時に状況が変化するデータは、モニタノードによって実行時にモニタリングが必要であることを明示しておく。
ノード(510−01)は「正常なDBSのHDDアクセス」に関する。当該ノードは2個に分岐され、すなわち、データベースシステムがHDD装置に対して正常にアクセスしている状態を2個のノードにブレークダウンして、その条件を記述している。具体的には、ノード(510−02)は「HDDの残容量」に関する。また、ノード(510−03)は「HDDの転送量」に関する。
ここで、本例では、これら2ノードのエビデンスとして前記モニタノードを導入する。図20(a)では、ノード(510−04)とノード(510−05)がモニタノードである。ノード(510−04)はHDDの残容量をモニタする。ノード(510−05)はHDD転送速度をモニタする。
ディペンダビリティ記述データにおけるモニタノードは、対象のシステムを外部からモニタリング可能な場合にはモニタリング部102−03が備える監視モジュール群(後述)を利用して対象のシステムをモニタリングする。一方、対象のシステムを外部からモニタリング不可能な場合には、対象のシステムに後述のプログラムを導入する手順に従って監視モジュールを送り込むことでモニタリングを行う。
そして、実行時のモニタリング結果をディペンダビリティ記述データの記述と比較することにより、変動許容範囲を超える差分の場合には、設計時の基準と異なる振る舞いとして異常として特定する。また、ディペンダビリティ記述データの上位ノードを参照することで、複合的な異常により上位ノードのディペンダビリティが満たされない状況を把握できる。さらに、個々のシステム内や複数のシステム間の障害箇所を突き合わせることにより、障害発生箇所を絞り込むことができる。
図20(b)にモニタノードを用いて障害検出するためのディペンダビリティ維持システム100の構成例を示す。モニタノードはパターンによって分類することができる。例えば、図20(a)の2個のモニタノード(510−04、510−05)は『HDD「$1」の「$2」が「$3」であることをモニタリングする』という形式を取ることができる。このモニタノードのパターンに対応するように監視モジュール群を予め用意し、モニタノードのパターンと監視モジュールの対応関係をテーブル化しておくことにより、実行時の状態をモニタリングできる。
例えば、図20(a)の2個のモニタノード(510−04、510−05)に関しては、図21のように対応関係を示すことができる。ここで、図21は、『HDD「$1」の「$2」が「$3」であることをモニタリングする』というパターンのモニタノードの場合に、$2が「ディスク容量」であれば、監視モジュールとしてHDD監視モジュールを利用し、引数として$1(=HDD識別番号)と$3(=変動許容範囲)を指定すれば良いことを示している。
ワークスペースコンピュータ101の編集ツール部101−02はディペンダビリティ記述データM1を記述し、さらに、ランタイムコンピュータ102における内部表現であるディペンダビリティ記述データ内部表現M2に変換する。詳細には、ワークスペースコンピュータ101の編集ツール部101−02において、ディペンダビリティ記述データ記述・表示ツール511−01がディペンダビリティ記述データM1を記述した後、それを、ディペンダビリティ記述データ変換部511−03によってディペンダビリティ記述データ内部表現M2に変換する。
ランタイムコンピュータ102では、ワークスペースコンピュータ101から取得したディペンダビリティ記述データ内部表現M2を更新部102−01がディペンダビリティ記述データ記録部(ディペンダビリティ記述データ格納部)511−05に記録する。また、更新部102−01は、ディペンダビリティ記述データ内部表現M2に基づいて、モニタノードとモニタリング部102−03における各種監視モジュール(監視モジュール群511−m)との対応関係をモニタノード/モジュール対応テーブル511−06に記録する。なお、図20(b)には監視モジュール群511−mの各監視モジュールとして、CPU監視モジュール511−08、HDD監視モジュール511−09、プロセス監視モジュール511−10、が記載されているが、他の監視モジュール511−11があっても良い。
モニタリング部102−03における前記監視モジュールによって得られたデータ(モニタ値)は収集部510−13によって集められ、実行状況検証部510−12によって、モニタノード/モジュール対応テーブル511−06に基づき、前記ディペンダビリティ記述データにおけるモニタノードの値として記録される。例えば、ディペンダビリティ記述データの各モニタノードに前記モニタ値の変動許容範囲を対応付けて記載しておき、モニタ値がその変動許容範囲から外れたノードを障害発生ノードとして検出する。また、前記監視モジュール群511−mからのモニタ値はD値計算部102−06においてノードに対するD値の計算に利用される。よって、例えば図20(a)のディペンダビリティ記述データの一部510では、2個のモニタノード(510−04、510−05)から取得されたモニタ値が変動許容範囲と比較されるとともに、これに基づいてD値が算出される。
また、CPU利用率、メモリ使用量、プロセス死活等は、のOS機能としてあらかじめ備わっており、外部からモニタリング可能なものもあるが、「システムA内のある処理Xが正常終了した」というような、外部からのモニタリングが難しいものもある。これらは、主に、アプリケーション固有の情報であり、ランタイムコンピュータ102に監視モジュール511−14として組み込む。すなわち、モニタリング対象をモニタリングする監視モジュールが内部にない場合、監視モジュール511−14のように、外部に監視モジュールを設けることができる。この組み込みはシステム構築時であっても良いし、ランタイムコンピュータ102の実行時であっても良い。これにより、実行時のモニタリング結果が変動許容範囲を超えた場合に、ディペンダビリティ記述データのノード単位で異常を特定できる。
また、実行時に各々の監視モジュールからモニタリング結果を集める(510−04、510−05)ことにより、ディペンダビリティ記述データ上のどのモニタノードで変動許容範囲を超えているかを判断できる。つまり、ディペンダビリティの観点から問題の発生を把握できる。すなわち、ディペンダビリティ記述データを当該モニタノードから上位側へ検討することで、どの範囲でディペンダビリティが維持できなくなったかを判断できる。例えば、ノード(510−04)及びノード(510−05)のモニタ値が共に変動許容範囲を超えているような状況では、ディペンダビリティを維持できなくなった原因がHDD以外にあるとして、ディペンダビリティ記述データのより上位を探索する。さらに、複数のシステムが相互作用している状況では各々のシステムに関するディペンダビリティ記述データだけではなく、相互作用に関するディペンダビリティ記述データも記述されていれば、適切なモニタノードによってシステム相互間で変動許容範囲を超える振る舞いの部位を絞り込むこと、あるいは特定することができる。
前記監視モジュール群511−mはシステムにあらかじめ組み込まれた監視モジュール群であるが、運用中に新たな監視モジュールを組み込む場合、あるいは変動許容範囲の判断が複数のセンサからのデータを考慮しなければ行けなかったり、ログからのデータを解析しなければ行けなかったりする場合には、スクリプトで構成することができる。
図22を用いて、スクリプトの構成概要を説明する。スクリプトは1以上の基本動作550−01(図ではD-Taskとして記載)と1以上の制御動作550−02(図ではD-Controlとして記載)から構成される。制御動作550−02は変動許容範囲を深刻度で分けて該当する深刻度の基本動作(D-Task)を実行する。例えば、ハードディスクの残容量の場合には、50%の残容量の深刻度を「低」、75%の残容量の深刻度を「中」、90%の残容量の深刻度を「高」として設定して、制御動作550−02(D-Control)を構成できる。この場合、深刻度「高」の場合にはD-Task 1(550−03)を実行し、深刻度「中」の場合にはD-Task 2(550−04)を実行し、深刻度「低」の場合にはD-Task 3(550−05)を実行する。
なお、本発明は以下のように構成してもよい。
本発明のディペンダビリティ維持装置(ランタイムコンピュータ102)は、上記システム運用時における前記ディペンダビリティ記述データを備えるシステムが提供するサービスを障害発生に際しても継続するように対処するプロセスにおいて、障害の発生を検出する手段(モニタリング機能)と、障害の発生した部分を隔離する手段(隔離機能)と、隔離された残りの部分でサービスを継続する手段と、障害の原因を検出する手段(原因追及機能)と、上記システム運用時におけるシステムが提供するサービスの継続性を判断する手段(継続性判断機能)とを備えるプロセスにおいて、当該障害の発生を起点とした一連のステップから構成されるループを形成する当該プロセスにおいて、当該障害の発生に際してサービスの停止期間を最小限にするように前記ディペンダビリティ記述データを備える対象システムを再構成するステップと、当該再構成によるシステム運用とサービス提供によりステークホルダがアカウンタビリティを達成することができるステップという2つの処理を実行しても良い。
また、本発明は以下のように構成してもよい。
本発明のディペンダビリティ維持装置(ランタイムコンピュータ102)は、上記対象システムの開発時あるいは更新時に、上記ディペンダビリティ記述データを仕様の変更に合わせて変更する変化対応サイクルP300、および、上記対象システムの運用時に、障害発生または障害予兆を検知したとき、上記ディペンダビリティ記述データに基づいて、上記対象システムの停止を回避する障害対応サイクルP301のうち、少なくとも上記障害対応サイクルP301を実行するとともに、上記障害発生を検知したとき、上記ディペンダビリティ記述データに基づいて、当該対象システムを再構成する再構成手段(再構成部102−04)を備えて構成されても良い。
これにより、障害対応サイクルP301を実行するランタイムコンピュータ102において、対象システムの障害発生を検知したとき、ディペンダビリティ記述データに基づいて、当該対象システムを再構成して、対象システムの運用を継続させることができる。
そして、ランタイムコンピュータ102は、対象システムの障害発生を、D値に基づいて検知してもよい。例えば、D値が所定の変動許容範囲より悪化したとき、障害発生を検出するようにしても良い。
〔8.障害対応サイクル(障害未然回避)〕
図23は、障害対応サイクルP301のうち、障害予兆検出時の2つの処理を示すフローチャートである。なお、図23における障害対応サイクルP301は図17の再掲である。
障害予兆S301−02はモニタリング部(障害予兆検出手段)102−03によって障害の予兆、あるいは故障(あるいは故障の予兆)が検出されると当該状態に遷移する。なお、障害の予兆に関しては各種の手法を組み合わせて実現可能である。例えば、ハードディスクドライブ装置はS.M.A.R.T.の仕組みを使うことで障害の予兆を検出できる。また、モニタリング部102−03は、例えば、D値の時間変化の傾向が所定の基準より悪化したとき、障害予兆を検出する。また、当該モニタリング部102−03は、前記モニタノードでモニタリングされているデータの時間変化の傾向が変動許容範囲を超えている場合に障害予兆として検出する。障害予兆検出時の障害対応サイクルP301には2つの機能が関係している。システム再構成処理S602とアカウンタビリティ処理S603である。
システム再構成処理S602は対応策抽出S301−03と緊急対応S301−04に関係している。システム再構成処理S602は障害部位とその影響範囲の同定S602−01から始まる。ここでは、障害の予兆と障害そのものの検出を説明の都合上同一視して障害として扱う。まず、ディペンダビリティ記述データのどの部位が障害かを同定する。そして当該ディペンダビリティ記述データからその影響範囲を同定する。影響範囲はディペンダビリティ記述データのノードを探索することにより同定する。例えば、障害部位に対応するノードが複数ある場合には、それらの共通ノードまでを影響範囲として特定できる。また、ノードにノード間の依存関係が記録されている場合には、当該依存関係を利用しても良い。
次に、サービス継続判断S602−02では、当該ディペンダビリティ記述データから抽出される対応シナリオが当該影響範囲を十分にカバーしてサービスが継続できるか、判断される。継続可能の場合には(S602−02でYES)、障害部位隔離S602−03に進む。なお、ディペンダビリティ記述データから対応シナリオが抽出できない場合には(S602−02でNO)、継続不可能と判断して、ディペンダビリティ記述データの変更抽出処理S800(図27)を実行する。当該変更抽出処理S800は、サービス継続判断S602−02にて継続可能の場合であっても、当該障害予兆の内容によっては実行された方が良い状況もあるので、一実施例として当該変更抽出処理を実行するように構成しても良い。
次に、障害部位隔離S602−03では、抽出された対応シナリオに従って障害部位を隔離する。
次に、サービス継続S602−04に進み、システム再構成処理S602を終了する。この時点でランタイムコンピュータ102によるサービスは継続されている(S602−05)。
一方、アカウンタビリティ処理S603は記録S301−05と原因究明S301−06に関係している。アカウンタビリティ処理S603は内部状態の記録S603から始まる。ここでは、前記障害に関連したディペンダビリティ記述データ、及び当該ディペンダビリティ記述データに関連したランタイムコンピュータ102の内部の状態を記録する。
次に、システム再構成処理S602後のエビデンスを収集する(S603−02)。ここでのエビデンスとはシステム再構成によってランタイムコンピュータ102がディペンダビリティ記述データに従って適切に動作していることの記録である。なお、本実施の形態では、当該エビデンスの収集をもってステークホルダによるアカウンタビリティの達成とする(S603−03)。
前記緊急対応S301−04は上記スクリプト(D-Script)を用いて処理しても良い。図24に一例を示す。当該スクリプト(D-Script)は図4(b)記載のWEBサービスの再起動のシナリオ例であり、6個の基本動作(D-Task)から構成されている。当該シナリオは上記DEOSプロセスにおける要求抽出・リスク分析フェーズ250−11におけるサービス継続シナリオから導出される。ステークホルダは当該シナリオに関して合意している。当該サービス継続シナリオは要求抽出・リスク分析フェーズを支援するツール群260−01を用いて記述され、図24の形式で記述され、スクリプトに変換され、ステークホルダ合意によって電子署名される。
スクリプトがラインタイムコンピュータ102内部の後述のスクリプトエンジン部710(102−07)において実行される際には、当該スクリプトに附随された電子署名が検証される。電子署名が有効でない場合にはスクリプトは実行されない。さらに、スクリプトの実行に際しては、その権限を確認するように構成しても良い。すなわち、誰がどのスクリプトの操作を実行可能かを確認するように構成可能である。その場合には権限を有しない状況では当該スクリプトは実行されない。さらに、スクリプト自体を暗号化してランタイムコンピュータ102内部に格納するように構成しても良い。これらのセキュリティに関する施策により、当該スクリプトが原因となるセキュリティ違反を防止することができる。
図25を用いてランタイムコンピュータ102に関するソフトウェアの階層構造の一例を説明する。
図25では3個のCPUコア701(701−01〜701−03)を有するマルチコア構成例を示している。なお、図25では周辺デバイスは省略している。CPUコアの上位層にはシステム・コンテナ提供部702がある。これは、隔離部102−05(図1)の一部であり、上位層に対して複数のOSカーネル711を動作可能にする、隔離されたコンテナを提供する。また、図25では各々のCPUコア701に対してそれぞれ1つのシステム・コンテナ716、718、及び720が割り当てられているが、複数のシステム・コンテナを1つのCPUコア701に割り当てても良いし、1つのシステム・コンテナに対して複数のCPUコア701…を割り当てても良い。
CPUコア701−01にはシステム・コンテナ716を割り当て、そこではOSカーネル711上に、システムモニタ部704、再構成部102−04、システム記録部706、ディペンダビリティ記述データ処理部707が配置される。
システム・コンテナ716はランタイムコンピュータ102に1つ存在する。システムモニタ部704はモニタリング部102−03(図1)の一部でありランタイムコンピュータ102におけるシステム機能をモニタする。特に他のシステム・コンテナ(図25ではシステム・コンテナ718と720)のOSカーネル711をモニタする。また、当該システムモニタ部704に学習機能を持たせるように構成しても良い。例えば、対象システムにおけるシステム機能をモニタする際に、そのデータ構造に対する整合性をモニタするように構成する場合に、当該システム機能に対応した仕様書やソースコードから整合性のための条件を自動生成するように構成することができる。実行時に当該条件を学習することで、当該データ構造の全てをモニタしないでも、または、当該データ構造が変更されても当該モニタの仕組みを変えないでモニタ機能を継続することができる。
再構成部102−04は、他のシステム・コンテナの再構成を行う。具体的には、既に存在するシステム・コンテナを停止させ、破壊し、新しい構成でシステム・コンテナを作り出し、当該構成に従ってOSカーネルを始めとする機能を配置し起動する。システム・コンテナが破壊されるときには、当該システム・コンテナの内部状態を、システム記録部706を用いて記録しても良い。システム記録部706は記録部102−02(図1)の一部であり、ランタイムコンピュータ102の内部状態を記録する。
ディペンダビリティ記述データ処理部707は更新部102−01(図1)の一部であり、ワークスペースコンピュータ101で生成されたソフトウェアSWの内部にあるディペンダビリティ記述データをランタイムコンピュータ102全体のディペンダビリティ記述データに取り込み、ディペンダビリティ記述データを処理するためのシナリオを抽出しランタイムコンピュータ102を、再構成部102−04を利用して再構成する。
一方、CPUコア701−02にはシステム・コンテナ718を割り当て、そこではOSカーネル711上に、アプリケーションモニタ部708、アプリケーション記録部709、スクリプトエンジン部710、アプリケーション・コンテナ提供部712、アプリケーション管理部713乃至714、そしてアプリケーション群を配置している。
ここで、アプリケーション・コンテナとは、前記システム・コンテナ1個に対して1個以上存在し、1個以上のアプリケーションをグループ化し、アドレス空間の独立、名前空間の独立、及びCPUスケジューリングの独立を実現し、アプリケーション・コンテナ提供部712により提供される。図25ではシステム・コンテナ718にアプリケーション・コンテナ717及び719の2個を配置している。
アプリケーションモニタ部708はモニタリング部102−03(図1)の一部であり、アプリケーション・コンテナ内部をモニタする。アプリケーション記録部709は記録部102−02(図1)の一部であり、アプリケーション・コンテナの内部状態を記録している。
アプリケーション・コンテナ717にはアプリケーション管理部713を配置し、1個以上のアプリケーションが利用する。同様にアプリケーション・コンテナ719内部にはアプリケーション管理部714を配置し、1個以上のアプリケーションが利用する。
システム・コンテナ720の内部構成はシステム・コンテナ718と同様である。そのため、説明および図25中の表示を省略する。
図26にランタイムコンピュータ102の隔離部102−05(図1)が実現する各隔離項目に関しての機能要件の一例をまとめる。これらの隔離項目は一部を選択して必要な機能要件のみを実現しても良い。例えば、前記システム・コンテナは、これら項目の全部が実現されているし、アプリケーション・コンテナはアドレス空間、名前空間、及びCPUスケジューリングの3項目が実現されている。
なお、本発明は以下のように構成してもよい。
本発明のディペンダビリティ維持装置(ランタイムコンピュータ102)は、上記システム運用時における前記ディペンダビリティ記述データを備えるシステムが提供するサービスを停止させないように障害の予兆を検知し障害の発生を未然に回避するプロセスにおいて、前記ディペンダビリティ記述データを備えるシステムの内部状態を記録する手段(ロギング)と、当該記録された内部状態から前記ディペンダビリティ記述データを備えるシステムの障害の予兆を検出する手段と、前記ディペンダビリティ記述データを備えるシステムの当該検出された障害に対応する部分を同定する手段と、当該検出された障害が上記システム運用時におけるシステムが提供するサービスの継続性を判断する手段とを備えるプロセスにおいて、当該障害の発生の検出を起点とした一連のステップから構成されるループを形成する当該プロセスにおいて、当該検出された障害発生、あるいは障害の予兆によるサービスの停止を回避する目的で前記ディペンダビリティ記述データを備えるシステムを再構成するステップと、当該再構成によるシステム運用とサービス提供によりステークホルダがアカウンタビリティを達成することができるステップという2つの処理を実行しても良い。
また、本発明は以下のように構成してもよい。
本発明のディペンダビリティ維持装置(ランタイムコンピュータ102)は、上記対象システムの開発時あるいは更新時に、上記ディペンダビリティ記述データを仕様の変更に合わせて変更する変化対応サイクルP300、および、上記対象システムの運用時に、障害発生または障害予兆を検知したとき、上記ディペンダビリティ記述データに基づいて、上記対象システムの停止を回避する障害対応サイクルP301のうち、少なくとも上記障害対応サイクルP301を実行するとともに、上記障害予兆を検知したとき、上記ディペンダビリティ記述データに基づいて、当該対象システムを再構成する再構成手段(再構成部102−04)を備えて構成されても良い。
これにより、障害対応サイクルP301を実行するランタイムコンピュータ102において、対象システムの障害予兆を検知したとき、ディペンダビリティ記述データに基づいて、当該対象システムを再構成して、対象システムの運用を継続させることができる。
そして、ランタイムコンピュータ102は、対象システムの障害予兆を、D値に基づいて検知してもよい。例えば、D値の時間変化の傾向が所定の基準より悪化したとき、障害予兆を検出するようにしても良い。
さらに、ランタイムコンピュータ102は、対象システムの障害予兆を、前記モニタノードでのモニタリングデータに基づいて検知してもよい。例えば、当該モニタリングデータの時間変化の傾向が所定の基準より悪化し変動許容範囲を超えたとき、障害予兆を検出するようにしても良い。
〔9.障害対応サイクルからの変化対応サイクルの起動〕
図27は、ディペンダビリティ維持システム100におけるディペンダビリティ記述データの変更抽出処理の手順を示すフローチャートである。
上述したサービス継続判断S502−01(図19)、あるいは、サービス継続判断602−02(図23)において、サービス継続判断が「NO」すなわち継続不可能と判断されたときには、ディペンダビリティ記述データの変更抽出処理S800を実行する。
まず、障害部位に関するディペンダビリティ記述データを抽出する(S800−01)。次に、そのディペンダビリティ記述データにおけるリーフノードでテストと関連のあるノード全てにおいて、S800−03〜S800−05の処理を実行する(S800−02)。
例えば、図5においては、ノード群(202−06〜202−13)が該当する。そこで、当該ノード群(202−06〜202−13)に対応するテストを実行し計測する(S800−03)。既にエビデンスとしての結果は存在しているので、ここでの計測結果と比較することでエビデンスからの差異が変動許容範囲内か否かが判断される(S800−04)。変動許容範囲外の場合には(NO)、異常状態であるとして当該ノードの識別情報(例えば、ノード番号)を記録する(S800−05)。
全ノードに対して前記処理を終えると、前記識別情報が記録されたノードを変更する指示をワークスペースコンピュータ101に送り(S800−06)、処理を終了する(S800−07)。
なお、本発明は以下のように構成してもよい。
本発明のディペンダビリティ維持装置(ランタイムコンピュータ102)は、前記障害対応サイクルP301において、上記システム運用時における前記ディペンダビリティ記述データを備えるシステムが提供するサービスの継続が不可能と判断された場合、前記変化対応サイクルP300において前記ディペンダビリティ記述データを備えるシステムが提供するサービスを継続させる目的で、前記障害対応サイクルP301において記録又は検出された情報から前記ディペンダビリティ記述データを備えるシステムのディペンダビリティ記述データの変更を前記障害対応サイクルP301へ要求として入力するステップを実行しても良い。
また、本発明は以下のように構成してもよい。
本発明のディペンダビリティ維持装置(ディペンダビリティ維持システム100、ランタイムコンピュータ102)は、上記障害発生または障害予兆を検知し、上記対象システムの停止が不回避であるとき、上記変化対応サイクルP300を実行する装置(ワークスペースコンピュータ101)に、上記ディペンダビリティ記述データの変更の要求を送信する変更要求送信手段(変更送出部902−02)を備えて構成されても良い。
本発明のディペンダビリティ維持装置(ディペンダビリティ維持システム100、ワークスペースコンピュータ101)は、上記対象システムの開発時あるいは更新時に、上記ディペンダビリティ記述データを仕様の変更に合わせて変更する変化対応サイクルP300、および、上記対象システムの運用時に、障害発生または障害予兆を検知したとき、上記ディペンダビリティ記述データに基づいて、上記対象システムの停止を回避する障害対応サイクルP301のうち、少なくとも上記変化対応サイクルP300を実行するとともに、上記障害対応サイクルP301を実行する装置(ランタイムコンピュータ102)から、上記ディペンダビリティ記述データの変更の要求を受信したとき、上記ディペンダビリティ記述データを変更するように構成されても良い。
これにより、障害対応サイクルP301を実行するランタイムコンピュータ102において、対象システムの障害発生または障害予兆を検知し、対象システムの停止が不回避であると判断したとき、変化対応サイクルP300を実行するワークスペースコンピュータ101に、ディペンダビリティ記述データの変更の要求を送信することができる。なお、ランタイムコンピュータ102は、障害発生または障害予兆により、対象システムの停止が不回避であるか否かを、D値に基づいて判断しても良い。
そして、ワークスペースコンピュータ101は、ランタイムコンピュータ102からディペンダビリティ記述データの変更の要求を受信したとき、当該要求に応じて、上記ディペンダビリティ記述データを変更する。
したがって、ランタイムコンピュータ102とワークスペースコンピュータ101とが連携して、対象システムの障害発生または障害予兆を検知し、対象システムの停止が不回避であれば、ディペンダビリティ記述データを変更するというプロセスを円滑に実行することができる。よって、オープン環境において、対象システムのディペンダビリティを継続的に維持することが可能となる。
なお、前記記載の構成において、対象システムの停止が回避可能である場合においても、障害予兆の内容によっては前記記載のディペンダビリティ記述データの変更手順を実行するように構成しても良い。
〔10.障害対応サイクルと変化対応サイクルとの連携〕
図28は、ワークスペースコンピュータ101とランタイムコンピュータ102とのディペンダビリティ記述データを介した情報交換を示す機能ブロック図である。
ワークスペースコンピュータ101における編集ツール部101−01は、主に3個の構成要素を持つ。ディペンダビリティ記述データ編集部900−01は、ディペンダビリティ記述データを記述し、編集し、記録する。当該ディペンダビリティ記述データ編集部900−01は、図16に記載のD-Case Editor(260−06)として構成しても良い。なお、ディペンダビリティ記述データ編集部900−01として、特願2010-263681に記載のツールを用いても良い。当該特願2010-263681では、要求ベースにディペンダビリティ記述データを記述する際に、常に着目ノードが表示の中心になるようにディペンダビリティ記述データを表示することで詳細化の流れを簡素にしている。
ディペンダビリティ記述データ組込部900−02は、ディペンダビリティ記述データ編集部900−01にて作成されたディペンダビリティ記述データM1を内部表現に変換して、ディペンダビリティ記述データM2(正確には、ディペンダビリティ記述データ内部表現M2;図3のディペンダビリティ記述データ104−02に相当)を生成する。そして、ディペンダビリティ記述データ組込部900−02は、ソフトウェアSWに、当該ソフトウェアSWに対応した(あるいは関する)前記ディペンダビリティ記述データM2を組み込む。デプロイメント部900−03は当該ソフトウェアSWをランタイムコンピュータ102に導入する。
ここで、ディペンダビリティ記述データM2には、ディペンダビリティ記述データ編集部900−01によって、各エビデンスノードについて、モニタされるモニタ値に対する変動許容範囲が記録される。これにより、ランタイムコンピュータ102のモニタリング部102−03では、モニタ値の状態を確認できる。一方、ディペンダビリティ記述データM3には、記録部102−02によって、各エビデンスノードについて、モニタされたモニタ値のすべてあるいは一部が記録される。これにより、ワークスペースコンピュータ101の解析部901−03では、システムに生じた異常の原因を検討することができる。
また、ワークスペースコンピュータ101における解析ツール部101−03は、主に3個の構成要素を持つ。ディペンダビリティ記述データ入力部(記述データ取得手段)901−01はランタイムコンピュータ102からのディペンダビリティ記述データM3を入力とする。データベースアクセス部901−02はランタイムコンピュータ102に導入されているソフトウェア全体に関する複数のディペンダビリティ記述データにアクセスする。データベースは、ワークスペースコンピュータ101に設けられても良いし、ランタイムコンピュータ102に設けられても良いし、ワークスペースコンピュータ101と通信可能な他の装置に設けられても良い。ここでは、入力されたディペンダビリティ記述データM3に関連したディペンダビリティ記述データM4を、当該データベースから抽出する。ディペンダビリティ記述データM4はオリジナルのモデルであり、ディペンダビリティ記述データM3は変更が記載されたモデルである。当該データベースから抽出されるディペンダビリティ記述データM4はディペンダビリティ記述データM3をキーに検索されるが、より広範囲のディペンダビリティ記述データを抽出しても良く、解析部901−03での処理を容易にする。解析部901−03は当該入力されたディペンダビリティ記述データM3とベータベースアクセス部901−02経由で得られるディペンダビリティ記述データM4を解析して、障害原因等を分析し、必要に応じて環境変化S300−01(図17、図18)の状態に遷移させて、変化対応サイクルP300を実行する。
一方、ランタイムコンピュータ102において更新部102−01は、6個の構成要素を持つ。ソフトウェア入力部(記述データ取得手段)902−01はワークスペースコンピュータ101におけるデプロイメント部900−03からのソフトウェアSWを入力とする。当該ソフトウェアSWは更新部102−01によってランタイムコンピュータ102にインストールされ稼働される。ディペンダビリティ記述データ抽出部902−03はソフトウェアSWに含まれているディペンダビリティ記述データM2(正確には、ディペンダビリティ記述データ内部表現M2;図3のディペンダビリティ記述データ104−02に相当)を取り出す。構造検証部902−04は、当該取り出されたディペンダビリティ記述データM2の計算機表現としての妥当性を検証する。さらに、必要な機能(ライブラリ等)がランタイムコンピュータ102に備わっているかを確認する。実行管理部902−05は当該ソフトウェアSWをランタイムコンピュータ102に導入する際に必要な準備を行う。例えば、当該ソフトウェアSWが新しいサービスアプリケーションである場合には、必要な計算資源を見積もり割り当て、アプリケーション・コンテナ(図25のアプリケーション・コンテナ717等)を生成し、アプリケーションイメージを当該アプリケーション・コンテナ内に構成する。
また、変更送出部(変更要求送信手段)902−02はランタイムコンピュータ102にインストールされたディペンダビリティ記述データM2における変更部分(ディペンダビリティ記述データM3)をワークスペースコンピュータ101のディペンダビリティ記述データ入力部901−01に送り出す。このとき、変更送出部902−02は、上記変更部分と共に、ディペンダビリティ記述データの変更要求を送出しても良い。変更管理部902−06はランタイムコンピュータ102において、図27に示したディペンダビリティ記述データの変更を管理する。
前記において、ワークスペースコンピュータ101とランタイムコンピュータ102は、ディペンダビリティ記述データという計算機表現を介して情報交換する。前者から後者に対してはディペンダビリティ記述データM2を手段とし、後者から前者に対してはディペンダビリティ記述データM3を手段とする。ディペンダビリティ記述データM2はステークホルダ合意に対応したモデルであり、ディペンダビリティ記述データM3は当該ステークホルダ合意がランタイムコンピュータ102において満足されなくなり、その差分を表現したものであり、ステークホルダに対する通知である。
なお、本発明は以下のように構成してもよい。
本発明のディペンダビリティ維持装置(ディペンダビリティ維持システム100、ワークスペースコンピュータ101、ランタイムコンピュータ102)は、前記ディペンダビリティ記述データを備えるシステムが提供するサービスを継続させる目的で、前記変化対応サイクルP300と前記障害対応サイクルP301との間での情報交換の手段を有していても良い。
〔11.ディペンダビリティ記述データとの連携〕
図29は、図5に示したディペンダビリティ記述データを、計算機表現の一例としてXMLで記述したリストの一部である。なお、図28におけるソフトウェアSWに組込まれたディペンダビリティ記述データM2、あるいはディペンダビリティ記述データM3は当該XML表記により記述することができる。
図30は、ディペンダビリティ維持システム100の構成例であって、ディペンダビリティ記述データデータベースと、ワークスペースコンピュータおよびランタイムコンピュータとの関係を示す説明図である。
図30に示すように、ソフトウェアSWに組み込まれているディペンダビリティ記述データM2は、ワークスペースコンピュータ101およびランタイムコンピュータ102とは別体のディペンダビリティ記述データデータベース1000に格納され、ワークスペースコンピュータ101およびランタイムコンピュータ102から利用されても良い。当該データベースは図15に記載の合意記述データベース250−06として構成しても良い。
なお、本発明は以下のように構成してもよい。
本発明のディペンダビリティ維持装置(ディペンダビリティ維持システム100、ワークスペースコンピュータ101、ランタイムコンピュータ102)は、前記ディペンダビリティ記述データから変換されたコンピュータで処理可能な形式のデータを、当該ディペンダビリティ記述データを備えるシステムが管理する手段を有することで、前記変化対応サイクルP300におけるステークホルダによる変更の要求の合意のステップによる結果を、確実に当該ディペンダビリティ記述データを備えるシステムに実施する手段を有していてもよい。
〔12.ランタイムコンピュータでのコマンド処理〕
図31に、ランタイムコンピュータ102におけるコマンド実行の処理手順を示す。本実施の形態におけるコマンドとは、あらかじめランタイムコンピュータ102に組み込まれた、当該ランタイムコンピュータ102で実行可能な一連の処理であっても良いし、後述のディペンダビリティ記述データのノードに関連付けられた当該ランタイムコンピュータ102で実行可能なプログラムであっても良い。
まず、コマンド実行処理S1100の開始にあたって、処理が開始された旨が記録される(S1100−01)。次に、処理を1個以上のコマンド列に分解し、それをチェインとして構成する(S1100−02)。つづいて、コマンドチェイン中の全コマンドに対して(S1100−03)、以下のS1100−04、S1100−05の処理が実行される。
すなわち、チェイン中のコマンドを1つ実行し(S1100−04)、正常終了か、異常終了かを判断する(S1100−05)。そして、全部のコマンドが正常終了の場合には(S1100−05でYES)、終了が記録され(S1100−07)、当該処理は終了する(S1100−14)。
一方、コマンドチェイン中のコマンドが異常終了した場合(S1100−06でNO)、実行されたコマンドの効果を取り消すためのリカバリチェインが構築される(S1100−08)。その後、リカバリチェイン中の全コマンドに対して(S1100−09)、リカバリコマンドを実行し(S1100−10)、正常終了か、異常終了かを判断する(S1100−11)。全リカバリコマンドが正常終了の場合(S1100−11でYES)には、その旨を記録して(S1100−07)、当該処理は終了する(S1100−14)。
一方、リカバリコマンドの実行が異常終了の場合には(S1100−11でNO)、必要な隔離処理(S1100−13)を実行し、当該処理を含むコンテナ(アプリケーション・コンテナあるいはシステム・コンテナ)を隔離し、その旨を記録して(S1100−07)、当該処理は終了する(S1100−14)。その後、前記再構成処理を実行する。
前記記載の手順は、図24に記載の基本動作をコマンドチェインとするように構成しても良い。これにより、前記スクリプトをアトミック操作として確実に実行できるようになる。
なお、本発明は以下のように構成してもよい。
本発明のディペンダビリティ維持装置(ディペンダビリティ維持システム100、ワークスペースコンピュータ101、ランタイムコンピュータ102)は、前記ディペンダビリティ記述データを備えるシステムが提供するサービスを継続させる目的で、下記の〔A〕〔B〕〔C〕に記載の手段群を、当該手段群が前記ディペンダビリティ記述データを備えるシステムにおいて確実に実行されることを保証する手段を有していても良い。〔A〕障害対応サイクルP301において、上記システム運用時における前記ディペンダビリティ記述データを備えるシステムが提供するサービスの継続が不可能と判断された場合、変化対応サイクルP300において前記ディペンダビリティ記述データを備えるシステムが提供するサービスを継続させる目的で、前記障害対応サイクルP301において記録又は検出された情報から前記ディペンダビリティ記述データを備えるシステムのディペンダビリティ記述データの変更を前記変化対応サイクルP300に対する要求として当該変化対応サイクルP300に入力する手段。〔B〕前記ディペンダビリティ記述データを備えるシステムが提供するサービスを継続させる目的で、変化対応サイクルP300と障害対応サイクルP301との間での情報交換する手段。〔C〕ディペンダビリティ記述データから変換されたコンピュータで処理可能な形式のデータを、当該ディペンダビリティ記述データを備えるシステムが管理する手段を有することで、変化対応サイクルP300におけるステークホルダによる変更の要求の合意による結果を、確実に当該ディペンダビリティ記述データを備えるシステムに実施する手段。
〔13.ノードへの実行可能プログラムの関連付け〕
図32は、ディペンダビリティ記述データに関連付けられたプログラムの処理内容の一例を示すフローチャートである。
図32に示すノード(203−04)は図6に示したものと同じノードである。当該ノードは「キャッシュによるApp Logicの継続」に関する。本実施の形態では、ディペンダビリティ記述データをランタイムコンピュータ102への組み込み手順に従って導入する。このとき、ディペンダビリティ記述データの各ノードには、ランタイムコンピュータ102のバイナリ実行部110Rで実行可能なプログラムを関連付けてもよい。また、モニタノードにも実行可能なプログラムが関連付けられて、ランタイムコンピュータ102に導入される。なお、ノードへのプログラムを関連付けは、外部参照情報104−04に記述できる。また、これらの処理について図32では当該プログラムの処理内容をフローチャートで表現したが、スクリプト言語を用いても良いし、バイナリ実行部110Rで直接実行可能なプログラムコードを用いても良い。
プログラム1200には導入処理S1200−01と廃止処理S1200−11の2個の処理の手順が定義されている。
導入処理S1200−01は実行権限の確認(S1200−02)後に、アプリケーション・コンテナ提供部712(図25)の機能を利用してアプリケーション・コンテナを生成(S1200−03)する。次に、App Logic201−03(図4(b))に対応するアプリケーションを読み込み、アプリケーション管理部714(図25)に当該プログラムコードを登録する。
一方、廃止処理S1200−11は実行権限の確認(S1200−12)後に、App Logic201−03に対応するアプリケーションを停止(S1200−13)し、アプリケーション管理部714から当該プログラムコードの登録を削除し、アプリケーション・コンテナ提供部712の機能を利用して当該アプリケーション・コンテナを削除する。
図33は、ディペンダビリティ記述データに関連付けられたプログラムの処理内容の他の例を示すフローチャートである。
図33に示すノード(203−01)は図7に示したものと同じノードである。当該ノードは「多重型によるDBSの無停止」に関する。すなわち、バックアップ系を有するデータベースシステムを、複数台を同時に稼働させる多重系のデータベースに関するディペンダビリティ記述データの一部であった。
プログラム1201には更新処理S1201−01、導入処理S1201−11、廃止処理S1201−21の3個の処理の手順が定義されている。ディペンダビリティ記述データにおけるノードが置き換えられるとき、当該ノードにプログラムが関連つけられている場合には、そこに定義された更新処理を実行する。
具体的には、図33では、ノード(203−04)をノード(204−01)で置き換えるので、ノードの更新処理が実行される。更新処理S1201−01の手順は、実行権限の確認(S1201−01)後に、置き換えられるノード(図33の場合には図32のノード(203−04))に関連つけられた廃止処理S1200−11の手順を実行する。当該手順の実行に当たっては、図31のコマンド実行処理S1100のフローチャートに従い結果が記録(S1201−04)される。
次に、導入処理S1201−11の手順は実行権限の確認(S1201−12)後に、システム・コンテナ提供部702(図25)の機能を利用してシステム・コンテナを作成する。次に、無停止DBSをインストール(S1201−14)し、アプリケーション管理部714(図25)に当該DBSを登録する。
一方、廃止処理S1201−21の手順は実行権限の確認(1201−21)後に、無停止DBSを停止(S1201−23)し、アプリケーション管理部714から当該DBSの登録を削除(S1201−24)し、当該DBSのシステム・コンテナをシステム・コンテナ提供部702の機能を利用して削除(S1201−25)する。
なお、本発明は以下のように構成してもよい。
本発明のディペンダビリティ維持装置(ランタイムコンピュータ102)は、前記ディペンダビリティ記述データを備えるシステムが障害発生検出時および障害予兆検出時の障害対応サイクルP301を確実に実行するために、下記の手段群〔A〕〔B〕をコンピュータで処理するための表現手段を有していても良い。〔A〕上記システム運用時における前記ディペンダビリティ記述データを備えるシステムが提供するサービスを障害発生に際しても継続するように対処するプロセスにおいて、障害の発生を検出する手段(モニタリング機能)と、障害の発生した部分を隔離する手段(隔離機能)と、隔離された残りの部分でサービスを継続する手段と、障害の原因を検出する手段(原因追及機能)と、上記システム運用時におけるシステムが提供するサービスの継続性を判断する手段(継続性判断機能)。〔B〕上記システム運用時における前記ディペンダビリティ記述データを備えるシステムが提供するサービスを停止させないように障害の予兆を検知し障害の発生を未然に回避するプロセスにおいて、前記ディペンダビリティ記述データを備えるシステムの内部状態を記録する手段(ロギング)と、当該記録された内部状態から前記ディペンダビリティ記述データを備えるシステムの障害の予兆を検出する手段と、前記ディペンダビリティ記述データを備えるシステムの当該検出された障害に対応する部分を同定する手段と、当該検出された障害が上記システム運用時におけるシステムが提供するサービスの継続性を判断する手段。
また、本発明は以下のように構成してもよい。
本発明のディペンダビリティ維持装置(ランタイムコンピュータ102)は、上記ディペンダビリティ記述データには上記再構成の手順が記載されており、上記再構成手段(再構成部102−04)は、上記ディペンダビリティ記述データに記載されている再構成の上記手順に従って、当該対象システムを再構成するように構成されても良い。
これにより、ランタイムコンピュータ102は、ディペンダビリティ記述データに記載されている再構成の手順に従って、当該対象システムを再構成することができる。よって、再構成の手順をディペンダビリティ記述データの設計段階において、当該ディペンダビリティ記述データに記述しておくことができるため、再構成時に手順を作成する必要がない。
〔14.合意形成ツールとの連携〕
図34に、ディペンダビリティ記述データM1と、ソフトウェアSWに含まれるXML形式ディペンダビリティ記述データM2(正確には、ディペンダビリティ記述データ内部表現M2であるが、ここでは、XML形式による内部表現を選択した場合について説明するので、「XML形式ディペンダビリティ記述データM2」と記す。)と、ワークスペースコンピュータ101が備えるツール群の各機能との関係を示す。
編集機能1300−01(図1の編集ツール部101−02が備える機能)は、ディペンダビリティ記述データM1を入力・修正・記録する。検証機能1300−02(図1の検証ツール部101−01が備える機能)は、当該ディペンダビリティ記述データM1の妥当性を検証する。ベンチマーク機能1300−03(図1の検証ツール部101−01が備える機能)は、当該ディペンダビリティ記述データM1におけるエビデンスを確認する。変換機能1300−04(図1の編集ツール部101−02および開発ツール部101−04が備える機能)は、差分検証モデルM1をソフトウェアSWへの組込形式である、XML形式ディペンダビリティ記述データM2に変換する。当該変換の際には、ディペンダビリティ記述データからモニタノード部分を抜き出し、その構造を維持しながら変換するように本実施例を構成しても良い。計測機能1300−05(図1の検証ツール部101−01が備える機能)は、当該XML形式ディペンダビリティ記述データM2のモニタノードにアクセスしてデータを計測・抽出する。
また、図35にベンチマーク機能(図中ではDS-Benchとして記載)と図16に記載のD-Case Editorとの連携を示す。D-Case Editor上ではモニタノードに実行すべきベンチマークを指定できるように構成している。当該D-Case Editorからのベンチマーク実行指示に基づいて実際のベンチマークが実行され、その実行結果を反映することでエビデンスとして記録する。当該ベンチマーク結果はD値の算出に用いることができる。また、D値に影響のあるベンチマークを用意することも可能であり、その場合、D値への影響が大きいほどベンチマークの有効性も高いことになる。
当該ベンチマークには、システムの性能に関する特性以外の、障害の原因になるような特性を検証するベンチマークが含まれていてもよい。このようなベンチマークの例としては、CPU負荷を変動させたときのシステムの振る舞いに関するベンチマーク、ネットワークの帯域幅を変動させたとき、または遅延を変動させたときのシステムの振る舞いに関するベンチマーク、余剰メモリを変動させたときのシステムの振る舞いに関するベンチマーク、過剰なアクセスをシミュレートすることでシステムに総合的に負荷をかけたときのシステムの振る舞いに関するベンチマーク、システムの構成コンポーネントを意図的に異常終了した際のシステムの振る舞いに関するベンチマーク、等が挙げられる。
さらに、ディペンダビリティ記述データは、例えば図8に記載のD-Case記述を用いた場合、当該記述の整合性や網羅性等の検証のために、Agda定理証明器(http://wiki.portal.chalmers.se/agda/pmwiki.php)を用いるように構成しても良い。これにより、当該D-Case記述の記述エラーを自動的に取り除くことが可能になる。
なお、本発明は以下のように構成してもよい。
本発明のディペンダビリティ維持装置(ディペンダビリティ維持システム100、ワークスペースコンピュータ101)は、前記ディペンダビリティ記述データを備えるシステムが提供するサービスを継続させる目的で、前記変化対応サイクルP300におけるステークホルダ間での合意を形成するステップにおいて、ステークホルダからの要求の変更をコンピュータで処理可能な表現形式で記述する手段を有し、当該表現形式の論理的検証手段を有していても良い。
〔15.ディペンダビリティ維持システム間の連携〕
本実施の形態に係るディペンダビリティ維持システム100は、ワークスペースコンピュータ101、ディペンダビリティ記述データM1、ランタイムコンピュータ102から構成されると言える。そして、当該ディペンダビリティ維持システム100の計算可能なディペンダビリティは、当該ディペンダビリティ記述データM1が表現している。
ここで、図36は、ディペンダビリティ維持システム100を2つ接続した構成例を示すブロック図である。
図36に示すように、利用者のディペンダビリティ維持システム100Uに対してディペンダビリティ記述データに基づく機能を提供する提供者のディペンダビリティ維持システム100Sと、利用者の前記ディペンダビリティ維持システム100Uとを、ネットワーク1400−03で接続した複合システムが構成できる。
ここで、図37は、図36に示した2つのディペンダビリティ維持システム100U,100Sを接続した構成における、独立した2つのディペンダビリティ維持システム100U,100S間での連携の一例を示す説明図である。
提供者のディペンダビリティ維持システム100から、利用者のディペンダビリティ維持システム100Uに対して、SLA(Service Level Agreement)を含むSLAディペンダビリティ記述データM2−SLAが提示される。SLAディペンダビリティ記述データM2−SLAは、SLAの情報を含む以外は、ディペンダビリティ記述データ内部表現M2と同じである。
SLAディペンダビリティ記述データM2−SLAに含まれるSLAには、ディペンダビリティ維持システム100Sにて公開されるインターフェースのディペンダビリティに関してのみ記述される。これは提供者が提示する情報であり、当該インターフェースに対しての提供者のディペンダビリティに関してのコミットメントとして捉えることができる。また、当該ディペンダビリティ記述データはD値を計算可能であり、利用者はD値を計算して提供者の公開インターフェースに関してのディペンダビリティが利用者の基準に合致するかを確認できる。
本発明のディペンダビリティ維持装置(ディペンダビリティ維持システム100、ワークスペースコンピュータ101)は、前記ディペンダビリティ記述データを備えるシステムが提供するサービスを継続させる目的で、2台以上の当該システムがネットワークによって相互接続された環境において、相互接続されていない環境において備えることが可能な上述した各手段を有していてもよい。
〔16.サプライチェーン〕
図38は、図1に示したディペンダビリティ維持システム100を2つ、本体側および部品側として統合した構成例を示すブロック図である。
図38に示すように、機能の本体を実行する本体側のディペンダビリティ維持システム100Bに対して、前記機能の一部を部品側のディペンダビリティ維持システム100Pが部品として提供することが可能である。図38では、ディペンダビリティ記述データM−Bにおけるノードの1個(1500−03)が部品としての提供されている例を示す。部品側のディペンダビリティ維持システム100Pに示すディペンダビリティ記述データM−Pが、部品であるノード(1500−03)のディペンダビリティ記述データである。
図39は、2つのディペンダビリティ維持システム100B,100Pを本体側および部品側として統合した構成における、独立した2つのディペンダビリティ維持システム100B,100P間での連携の一例を示す説明図である。
本体側のディペンダビリティ維持システム100Bにおけるワークスペースコンピュータ101では、部品1500−03のディペンダビリティ記述データM−Pを検証する(S1502−01)。当該部品1500−03のディペンダビリティ記述データM−Pが妥当である場合には、本体側のディペンダビリティ維持システム100Bにおけるランタイムコンピュータ102で、当該部品1500−03のベンチマークを計測する(S1502−02)。その結果のエビデンスが十分であれば、本体側のディペンダビリティ維持システム100Bにおけるワークスペースコンピュータ101は当該部品1500−03を本体のディペンダビリティ記述データM−Bに統合する(S1502−05)。
図40に、部品を統合する処理手順の詳細を示す。まず、当該部品1500−03のディペンダビリティ記述データM−Pを検証する(S1502−01)。次に、ベンチマークを実行してエビデンスを計測し(S1502−02)、さらに、D値を計算する(S1502−03)。その結果、D値が良好である場合には、統合可能であり(S1502−04でYES)、統合のための再構成を実行する(S1502−05)。一方、D値が満足できない場合には(S1502−04でNO)、部品提供者に対して部品(すなわち、そのディペンダビリティ記述データM−P)のアップデートを求める(S1502−06)。以降、同様の手順を繰り返す。
本発明のディペンダビリティ維持装置(ディペンダビリティ維持システム100、ワークスペースコンピュータ101)は、前記ディペンダビリティ記述データを備えるシステムが提供するサービスを継続させる目的で、当該システムが第3者の1又は複数のハードウェア又はソフトウェア部品で構成される場合において、各々の部品が前記ディペンダビリティ記述データを備え、当該システムのディペンダビリティ記述データとの互換性の検証手段を有していても良い。
〔17.ディペンダビリティ記述データの表示〕
図41を用いてランタイムコンピュータ102に格納されたディペンダビリティ記述データにおけるゴール群の一部が満足されなかった状況下で、ワークスペースコンピュータ101上の図16に記載のD-Case Viewer(260−07)が当該状況を表示する例を示す。ここでは、満足されなくなったゴールがフラッシュ(1600−01)されており、必要に応じてオペレータにアテンションを求める(1600−02)。なお、図41はD-Case記述例であるが、記載内容は本説明では重要ではなく、その構造のみを示す。
最後に、ディペンダビリティ維持システム100の各ブロック、特にワークスペースコンピュータ101およびランタイムコンピュータ102の各ブロックは、ハードウェアロジックによって構成してもよいし、次のようにCPUを用いてソフトウェアによって実現してもよい。
後者の場合、ディペンダビリティ維持システム100、あるいはワークスペースコンピュータ101およびランタイムコンピュータ102は、各機能を実現するプログラムの命令を実行するCPU(central processing unit)、上記プログラムを格納したROM(read only memory)、上記プログラムを展開するRAM(random access memory)、上記プログラムおよび各種データを格納するメモリ等の記憶装置(記録媒体)などを備えている。そして、本発明の目的は、上述した機能を実現するソフトウェアであるディペンダビリティ維持システム100、あるいはワークスペースコンピュータ101およびランタイムコンピュータ102の制御プログラムのプログラムコード(実行形式プログラム、中間コードプログラム、ソースプログラム)をコンピュータで読み取り可能に記録した記録媒体を、上記のディペンダビリティ維持システム100、あるいはワークスペースコンピュータ101およびランタイムコンピュータ102に供給し、そのコンピュータ(またはCPUやMPU)が記録媒体に記録されているプログラムコードを読み出し実行することによっても、達成可能である。
上記記録媒体としては、例えば、磁気テープやカセットテープ等のテープ系、フロッピー(登録商標)ディスク/ハードディスク等の磁気ディスクやCD−ROM/MO/MD/DVD/CD−R等の光ディスクを含むディスク系、ICカード(メモリカードを含む)/光カード等のカード系、あるいはマスクROM/EPROM/EEPROM/フラッシュROM等の半導体メモリ系などを用いることができる。
また、上記のディペンダビリティ維持システム100、あるいはワークスペースコンピュータ101およびランタイムコンピュータ102を通信ネットワークと接続可能に構成し、上記プログラムコードを通信ネットワークを介して供給してもよい。この通信ネットワークとしては、特に限定されず、例えば、インターネット、イントラネット、エキストラネット、LAN、ISDN、VAN、CATV通信網、仮想専用網(virtual private network)、電話回線網、移動体通信網、衛星通信網等が利用可能である。また、通信ネットワークを構成する伝送媒体としては、特に限定されず、例えば、IEEE1394、USB、電力線搬送、ケーブルTV回線、電話線、ADSL回線等の有線でも、IrDAやリモコンのような赤外線、Bluetooth(登録商標)、802.11無線、HDR、携帯電話網、衛星回線、地上波デジタル網等の無線でも利用可能である。なお、本発明は、上記プログラムコードが電子的な伝送で具現化された、搬送波に埋め込まれたコンピュータデータ信号の形態でも実現され得る。
(1)本発明に係るディペンダビリティ維持装置は、対象システムのディペンダビリティを維持するためのディペンダビリティ維持装置であって、対象システムのディペンダビリティに関する(ステークホルダ群によって合意された)要求・仕様を記述したディペンダビリティ記述データを取得する記述データ取得手段と、上記記述データ取得手段が取得したディペンダビリティ記述データに基づいて、上記対象システムのディペンダビリティの価値を定量的に示す評価値を求めるディペンダビリティ値決定手段と、を備えることを特徴としている。
(12)また、本発明に係るディペンダビリティ維持装置の制御方法は、対象システムのディペンダビリティを維持するためのディペンダビリティ維持装置の制御方法であって、対象システムのディペンダビリティに関する(ステークホルダ群によって合意された)要求・仕様を記述したディペンダビリティ記述データを取得する記述データ取得ステップと、上記記述データ取得ステップにて取得したディペンダビリティ記述データに基づいて、上記対象システムのディペンダビリティの価値を定量的に示す評価値を求めるディペンダビリティ値決定ステップと、を含むことを特徴としている。
上記の構成によれば、対象システムのディペンダビリティに関する(ステークホルダ群によって合意された)要求・仕様を記述したディペンダビリティ記述データに基づいて、対象システムのディペンダビリティの価値を定量的に示す評価値を求めることができる。
それゆえ、対象システムのディペンダビリティの価値を定量的に表現できる。したがって、例えば、要求変更に伴ってディペンダビリティ記述データを変更するときや、対象システムの運用時に対象システムの状態を確認するときに、対象システムのディペンダビリティの価値を分かりやすく客観的に提示することができる。
よって、対象システムのディペンダビリティの維持を円滑に行うことが可能となるという効果を奏する。すなわち、不完全性と不確実性が潜在的に存在するオープン環境において、対象システムのディペンダビリティの維持を支援することが可能となるという効果を奏する。
(2)さらに、本発明に係るディペンダビリティ維持装置は、上記(1)に記載の構成において、上記対象システムの開発時あるいは更新時に、上記ディペンダビリティ記述データを(ステークホルダ群によって合意された)要求・仕様の変更に合わせて変更する変化対応サイクル、および、上記対象システムの運用時に、障害発生または障害予兆を検知したとき、上記ディペンダビリティ記述データに基づいて、上記対象システムの停止を回避する障害対応サイクルの少なくとも何れか一方を実行することを特徴としている。
上記の構成によれば、さらに、変化対応サイクルおよび障害対応サイクルの少なくともいずれか一方において、対象システムのディペンダビリティの価値を示す評価値を求めることができる。したがって、例えば、変化対応サイクルにおいて、要求変更に伴ってディペンダビリティ記述データを変更するときに、評価値に基づいて、ディペンダビリティ記述データの変更案の適否を判断することが可能となる。また、例えば、障害対応サイクルにおいて、対象システムの運用時に対象システムの状態を、評価値に基づいて判断することが可能となる。よって、対象システムのディペンダビリティの維持を円滑に行うことが可能となるという効果を奏する。
(3)さらに、本発明に係るディペンダビリティ維持装置は、上記(1)に記載の構成において、上記対象システムの開発時あるいは更新時に、上記ディペンダビリティ記述データを(ステークホルダ群によって合意された)要求・仕様の変更に合わせて変更する変化対応サイクル、および、上記対象システムの運用時に、障害発生または障害予兆を検知したとき、上記ディペンダビリティ記述データに基づいて、上記対象システムの停止を回避する障害対応サイクルのうち、少なくとも上記障害対応サイクルを実行するとともに、上記障害発生または障害予兆を検知したとき、上記ディペンダビリティ記述データに基づいて、当該対象システムを再構成する再構成手段を備えることを特徴としている。
上記の構成によれば、さらに、障害対応サイクルを実行するディペンダビリティ維持装置において、対象システムの障害発生あるいは障害予兆を検知したとき、ディペンダビリティ記述データに基づいて、当該対象システムを再構成して、対象システムの運用を継続させることができるという効果を奏する。なお、対象システムの障害発生または障害予兆を上記評価値に基づいて検知してもよい。例えば、上記評価値が所定の変動許容範囲より悪化したとき、あるいは、上記評価値の時間変化の傾向が所定の基準より悪化したとき、障害発生を検出するようにしても良い。
(4)さらに、本発明に係るディペンダビリティ維持装置は、上記(3)に記載の構成において、上記ディペンダビリティ記述データには上記再構成の手順が記載されており、上記再構成手段は、上記ディペンダビリティ記述データに記載されている再構成の上記手順に従って、当該対象システムを再構成することを特徴としている。
上記の構成によれば、さらに、ディペンダビリティ維持装置は、ディペンダビリティ記述データに記載されている再構成の手順に従って、当該対象システムを再構成することができる。よって、再構成の手順をディペンダビリティ記述データの設計段階において、当該ディペンダビリティ記述データに記述しておくことができるため、再構成時に手順を作成する必要がないという効果を奏する。
(5)さらに、本発明に係るディペンダビリティ維持装置は、上記(3)または(4)に記載の構成において、上記障害発生または障害予兆を検知し、上記対象システムの停止が不回避であるとき、上記変化対応サイクルを実行する装置に、上記ディペンダビリティ記述データの変更の要求を送信する変更要求送信手段を備えることを特徴としている。
上記の構成によれば、さらに、障害対応サイクルを実行するディペンダビリティ維持装置において、対象システムの障害発生または障害予兆を検知し、対象システムの停止が不回避であると判断したとき、変化対応サイクルを実行する装置に、ディペンダビリティ記述データの変更の要求を送信することができる。なお、障害発生または障害予兆により、対象システムの停止が不回避であるか否かを、上記評価値に基づいて判断しても良い。
一方、変化対応サイクルを実行する装置は、上記ディペンダビリティ維持装置が送信したディペンダビリティ記述データの変更の要求を受信したとき、当該要求に応じて、上記ディペンダビリティ記述データを変更する。
したがって、障害対応サイクルを実行するディペンダビリティ維持装置と、変化対応サイクルを実行する装置とが連携して、障害対応サイクルにおいて、対象システムの障害発生または障害予兆を検知し、対象システムの停止が不回避であれば、変化対応サイクルにおいて、ディペンダビリティ記述データを変更するという、一連のプロセスを円滑に実行することができる。よって、オープン環境において、対象システムのディペンダビリティを継続的に維持することが可能となるという効果を奏する。
(6)さらに、本発明に係るディペンダビリティ維持装置は、上記(1)に記載の構成において、上記対象システムの開発時あるいは更新時に、上記ディペンダビリティ記述データを(ステークホルダ群によって合意された)要求・仕様の変更に合わせて変更する変化対応サイクル、および、上記対象システムの運用時に、障害発生または障害予兆を検知したとき、上記ディペンダビリティ記述データに基づいて、上記対象システムの停止を回避する障害対応サイクルのうち、少なくとも上記変化対応サイクルを実行するとともに、上記障害対応サイクルを実行する装置から、上記ディペンダビリティ記述データの変更の要求を受信したとき、上記ディペンダビリティ記述データを変更することを特徴としている。
上記の構成によれば、さらに、変化対応サイクルを実行するディペンダビリティ維持装置において、障害対応サイクルを実行する装置から、ディペンダビリティ記述データの変更の要求を受信したとき、当該要求に応じて、上記ディペンダビリティ記述データを変更することができる。
したがって、障害対応サイクルを実行する装置と、変化対応サイクルを実行するディペンダビリティ維持装置とが連携して、障害対応サイクルにおいて、対象システムの障害発生または障害予兆を検知し、対象システムの停止が不回避であれば、変化対応サイクルにおいて、ディペンダビリティ記述データを変更するという、一連のプロセスを円滑に実行することができる。よって、オープン環境において、対象システムのディペンダビリティを継続的に維持することが可能となるという効果を奏する。
(7)さらに、本発明に係るディペンダビリティ維持装置は、上記(1)から(6)のいずれかに記載の構成において、上記ディペンダビリティ記述データは、互いに関連づけられたゴールノードとモニタノードとの組を規定するデータであり、上記ゴールノードは、(ステークホルダ群によって合意された)要求・仕様がゴール形式にて記述されたノードであり、上記モニタノードは、上記ゴールノードに記述されたゴールが充足されていることを表明するエビデンスであるとともに、上記対象システムの監視点に対応付けられており、上記ディペンダビリティ値決定手段は、対応付けられた上記監視点から取得されたデータが変動許容範囲に対して良好であるモニタノードに基づいて、上記評価値を計算することを特徴としている。
上記の構成によれば、さらに、互いに関連づけられたゴールノードとモニタノードとの組を規定するデータ、例えば、木構造あるいはグラフ構造のデータから、多次元ベクトル値として評価値を求めることができる。
また、本発明に係るディペンダビリティ維持装置は、上記(1)から(6)のいずれかに記載の構成において、
・上記ディペンダビリティ記述データは、ゴールノードとモニタノードとを組にすることが可能であるとともに、当該組を1以上有する木構造あるいはグラフ構造を有するデータであって、
・上記ゴールノードは、(ステークホルダ群によって合意された)要求・仕様がゴール形式にて記述することが可能なノードであり、
・上記モニタノードは、上記ゴールノードに記載のゴールが満たされていることを表明するエビデンスであり、
さらに、上記モニタノードは、上記対象システム内部の対応した監視点からのデータ取得を可能にした上で、当該監視点データが変動許容範囲に対して良好であることを判断する手段を備えており、
上記ディペンダビリティ値決定手段は、上記エビデンスが良好であるモニタノードを上記木構造あるいはグラフ構造において計算することで上記評価値とすることを特徴としている。
また、上記ディペンダビリティ維持装置は、上記ディペンダビリティ記述データがノード間のエッジに重み付けが可能な木構造あるいはグラフ構造を有するデータであり、上記ディペンダビリティ値決定手段は、上記エッジに重み付けされた重みを要素とする多次元ベクトル値を上記評価値としてもよい。
上記の構成によれば、さらに、木構造あるいはグラフ構造のエッジに重み付けされた重みを要素とする多次元ベクトル値を評価値として求めることができる。
それゆえ、木構造あるいはグラフ構造に、エッジの重要性を加味した評価値が得られる。よって、評価値を確認することで、エッジに重み付けの変更がディペンダビリティに与える影響を評価することができるという効果を奏する。なお、ここで得られる評価値は多次元ベクトル値であるが、目的に応じた任意の変換手法によりスカラー値に変換できることはいうまでもない。
(8)さらに、本発明に係るディペンダビリティ維持装置は、上記(1)から(6)のいずれかに記載の構成において、上記ディペンダビリティ値決定手段は、上記対象システムをモニタして取得されたモニタ値が変動許容範囲に対して良好であったエビデンスに基づいて、上記評価値を計算することを特徴としている。
上記の構成によれば、さらに、対象システムをモニタして取得されたモニタ値が変動許容範囲(基準値)に対して良好であったエビデンスに基づいて、評価値を計算することができる。その計算方法としては、例えば、ディペンダビリティ記述データに含まれるエビデンスの総数(総エビデンス数)に対する、モニタ値が変動許容範囲(基準値)に対して良好なエビデンスの数(有効エビデンス数)の割合を評価値として計算することができる。
それゆえ、エビデンスの状態に応じた評価値が得られる。エビデンスは要求変更に応じて変化するため、ここで得られる評価値も要求変更に応じて変化する。すなわち、評価値を確認することで、要求変更がディペンダビリティに与える影響を評価することができるという効果を奏する。
(9)さらに、本発明に係るディペンダビリティ維持装置は、上記(1)に記載の構成において、上記対象システムの開発時あるいは更新時に、上記ディペンダビリティ記述データを(ステークホルダ群によって合意された)要求・仕様の変更に合わせて変更する変化対応サイクル、および、上記対象システムの運用時に、障害発生または障害予兆を検知したとき、上記ディペンダビリティ記述データに基づいて、上記対象システムの停止を回避する障害対応サイクルのうち、少なくとも上記障害対応サイクルを実行するとともに、上記障害発生または障害予兆を検知したとき、上記ディペンダビリティ記述データに含まれるスクリプトを実行するスクリプト処理手段を備え、上記スクリプトは上記対象システムを変動許容範囲の状態に回復させるシナリオを含むことを特徴としている。
上記の構成によれば、さらに、障害発生または障害予兆を検知したとき、ディペンダビリティ記述データに含まれるスクリプトを実行することによって、対象システムを変動許容範囲の状態に回復させることができる。
なお、上記スクリプトは、ステークホルダによって合意されていることが好ましい。また、上記スクリプトは、対象システムに組み込まれたスクリプトエンジンによって実行される。また、上記スクリプトは、対象システム内部で取得されているログから、対象システムの状態が変動許容範囲にあるかを判断してもよい。また、対象システムを変動許容範囲の状態に回復させるシナリオを実行する際、当該シナリオは、GUIを介してオペレータから操作を受け付けてもよい。
(10)また、本発明に係るディペンダビリティ維持システムは、対象システムのディペンダビリティを維持するためのディペンダビリティ維持システムであって、上記対象システムの開発時あるいは更新時に、上記ディペンダビリティ記述データを(ステークホルダ群によって合意された)要求・仕様の変更に合わせて変更する変化対応サイクルを実行するワークスペース装置と、上記対象システムの運用時に、障害発生または障害予兆を検知したとき、上記ディペンダビリティ記述データに基づいて、上記対象システムの停止を回避する障害対応サイクルを実行するランタイム装置とを含み、上記ワークスペース装置および上記ランタイム装置の少なくともいずれか一方が、上記ディペンダビリティ記述データに基づいて、上記対象システムのディペンダビリティの価値を定量的に示す評価値を求めることを特徴としている。
(11)さらに、本発明に係るディペンダビリティ維持システムは、上記(10)に記載の構成において、他のディペンダビリティ維持システムとネットワークを介して接続されていることを特徴としている。
なお、上記のディペンダビリティ維持装置は、コンピュータによって実現してもよく、この場合には、コンピュータを上記の各手段として動作させることにより上記ディペンダビリティ維持装置をコンピュータにて実現させるディペンダビリティ維持装置のプログラム、およびそれを記録したコンピュータ読み取り可能な記録媒体も、本発明の範疇に入る。
〔実施の形態2〕
本実施の形態に係るディペンダビリティ維持装置20は、要求・仕様書およびシステムの更新の間の無矛盾性を維持することを容易にするものである。そのため、後述するように、本実施の形態に係るディペンダビリティ維持装置20は、監視制御対象システム2のディペンダビリティに関する仕様を記述したD-CaseをD-Case格納部10から読み出し、監視制御対象システム2の状態を監視し、必要な場合に対策を実行する障害監視制御部30の動作を制御する監視制御データを、上記読み出したD-Caseから生成し、障害監視制御部30に供給するD-Case変換部21を備える。
以下、図42から図56、および図8に基づいて、本発明の一実施の形態について詳細に説明する。
図42は、本実施の形態に係る障害対応システム1の構成の概略を示す機能ブロック図である。
本実施の形態に係る障害対応システム1は、監視制御対象システム2の動作を監視し、障害を発生した場合に、必要な対応措置を行うものである。なお、監視制御対象システム2としては、任意のコンピュータシステムに適用可能であるが、特に、単一のシステムではなく、複数のステークホルダが存在する、高度で複雑なディペンダビリティが必要とされているシステムに好適である。具体的には、社会インフラシステムの基盤であるようなコンピュータシステム、例えば、監視システム、電子決済システム、交通・航空管制システム、さらには、それらを包含するクラウドシステムに好適である。
そして、特に、本実施の形態に係る障害対応システム1は、監視制御対象システム2の各ステークホルダの合意の記述を容易にするとともに、監視制御対象システム2の一部更新があった場合に、合意の記述と監視制御のための実装モジュールの間が無矛盾に更新されるように維持することを特徴とするものである。すなわち、障害対応システム1は、ディペンダビリティ記述データで表現された監視制御対象システム2のディペンダビリティに関わる仕様と、監視制御対象システム2を監視制御するためのモニタモジュールやアクションモジュールの制御との間を、無矛盾に開発・更新することを可能とする。
そのために、障害対応システム1は、ディペンダビリティ記述データとして、各ステークホルダの合意の記述を容易に行うことができるという特徴を持つD-Caseを用いて、監視制御対象システム2のディペンダビリティを記述する。また、障害対応システム1は、D-Caseのパターン(D-Caseパターン)と監視制御対象システム2を監視制御するためのモニタモジュールおよびアクションモジュールとの対応を管理する。これにより、監視制御対象システム2の変更等に応じて、モニタモジュールやアクションモジュールが追加・変更されても、ディペンダビリティ記述とモニタモジュールおよびアクションモジュールとの対応を維持することができる。
(D-Case)
図8は、D-Caseの基本構造を示す説明図である。また、図43は、D-Caseの具体例を示す説明図である。なお、図43は、顔認識を用いた監視システムを監視制御対象システム2とした場合のD-Caseである。
上記の通り、本実施の形態では、監視制御対象システム2のディペンダビリティに関する仕様を記述するディペンダビリティ記述データとして、D-Caseを使用する。
D-Caseとは、Safety Caseという、主にイギリスで用いられている、システムの安全性を保証するために用いられる構造化されたドキュメントを元にしている。本明細書では、Safety Caseを元にしたディペンダビリティ記述データを「D-Case」と称するものとする。D-Caseによれば、可用性などの一般的なディペンダビリティ属性は、図43のようなシステムレベルの議論に詳細化される。
D-Caseは、監視制御対象システム2に関わる各ステークホルダが合意するための構造化されたドキュメントである。詳細には、図8に示すように、D-Caseは、システムのディペンダビリティをトップゴールとして、それが満たされていることを木構造により詳細化していき、詳細化されたゴールに対してエビデンスを置いた木構造を有する。D-Caseは、後述するようにXML(Extensible Markup Language)によって記述することができる。
ここで、図43中、“G”を付したブロックがトップゴールである。トップゴールとは、対象システムに対して、ステークホルダ間で合意すべき命題を表す。例えば「対象システムは、安全性規格Xで定義されているSafety Integrity Level 3を満たす」などである。
“SG”を付したブロックがサブゴールである。サブゴールとは、トップゴールを示すために、示すべきことを分割した命題を表す。例えば、トップゴールが「Aである、かつ、Bである」であるとき、サブゴール「Aである」、「Bである」に分割する。サブゴールは、さらに小さなサブゴールに分割されうる。トップゴール、サブゴールを総称して、ゴールと呼ぶ。
“St”を付したブロックがストラテジである。ストラテジとは、ゴールが成り立つことを、そのサブゴール群によってどのように議論されるのかの補助説明を示す。例えば、ゴールが「システムは考えられる障害すべてに対応する」であるとき、ストラテジとして、「考えられる障害ごとに議論する」をあげる。この場合、サブゴールは、「システムは考えられる障害1に対応する」、…、「システムは考えられる障害Nに対応する」となる。
“E”を付したブロックがエビデンスである。エビデンスとは、分割され、詳細化されたゴールを、最終的に保証するリーフノードである。例えば、サブゴールSG「システムXのサブコンポーネントYは、障害Zに対処できる」というゴールに対して、「FTA解析結果」というエビデンスをサブゴールSGの直下におく。サブゴールSGをさらにサブゴールに分割することも考えられるが、無限にゴールを分割することはできない。分割されたサブゴールを最終的に保証するものとして、エビデンスがおかれる。エビデンスの妥当性は,ステークホルダ間の合意に基づく。
また、図47に示されるように、“C”を付したブロックがコンテキストである。コンテキストは、ゴールやストラテジの内容を補足する情報を示す。例えば、ストラテジ「考えられる障害ごとに議論する」である場合、コンテキストとして「考えられる障害のリスト」がそのストラテジに付けられうる。ストラテジやコンテキストは、D-Caseを読むステークホルダが、ゴールの分割を追いながら読むときの助けとなる補助情報を示す。
なお、ストラテジ、コンテキストは、木構造化するときには読みやすさのために記入するが、ランタイム時にはコメント扱いである。
また、図50に示される、“Monitor:M_1”等のブロックがモニタである。モニタとは、システムが障害対応を行う際に必要になるランタイム時のシステムの情報を表す。例えば、ランタイム時の「プロセスXのCPU使用率のモニタリング」などがモニタノードとなる。モニタはエビデンスのサブクラスである。障害対応システム1のモニタ管理部40により得られる情報をエビデンスとして用いる場合に、そのエビデンスをモニタノードとして表す。
つづいて、図42および図44を参照しながら、上記障害対応システム1の構成および処理フローについて詳細に説明する。
図42に示すように、障害対応システム1は、D-Case格納部(ディペンダビリティ記述格納部)10、ディペンダビリティ維持装置20、障害監視制御部30、モニタ管理部40、モニタモジュール群50、アクション管理部60、アクションモジュール群70を備えて構成されている。
上記D-Case格納部10は、監視制御対象システム2についての、ステークホルダ間のディペンダビリティに関する合意を記述したディペンダビリティ記述データであるD-Caseを格納する。なお、障害対応システム1では、各ステークホルダが合意したD-Caseが入力となる。
上記ディペンダビリティ維持装置20は、監視制御対象システム2を監視制御するための実装モジュール(モニタモジュール、アクションモジュール)の制御とD-Caseパターンとの対応を示すD-Caseパターン<=>モジュール対応テーブル(後述する)を使用して、D-Caseから監視制御データ(障害対応スクリプト)を生成する。そのために、ディペンダビリティ維持装置20は、D-Case変換部(ディペンダビリティ記述変換部)21、対応テーブル格納部22を備えて構成されている。
上記D-Case変換部21は、障害監視制御部30の動作を制御する監視制御データ(障害監視制御用データ)を、D-Case格納部10に格納されているD-Caseから生成する。
ここで、D-Caseは、その一部分がパターン化されている。そして、上記対応テーブル格納部22は、D-Caseパターンと監視制御データとの対応を表わすテーブル(D-Caseパターン<=>モジュール対応テーブル)を格納している。
D-Case変換部21は、対応テーブル格納部22に格納されているD-Caseパターン<=>モジュール対応テーブルを参照して、D-Caseから監視制御データを生成する。
つぎに、上記障害監視制御部30は、監視制御対象システム2の状態を監視(モニタ)し、必要な場合に対策(アクション)を実行する。具体的には、障害監視制御部30は、ディペンダビリティ維持装置20においてD-Case変換部21が生成した監視制御データに従って、モニタ管理部40とアクション管理部60を制御する。監視制御データは、モニタ管理部40によるモニタモジュール(モニタモジュール群50)の選択および動作の制御、並びに、アクション管理部60によるアクションモジュール(アクションモジュール群70)の選択および制御を規定している。
上記モニタ管理部40は、監視制御データに従って、1以上のモニタモジュール(モニタモジュール群50)を管理する。本実施の形態では、モニタモジュールの例として、CPU監視モジュール51、メモリ監視モジュール52を挙げるが、本発明はこれに限定されない。
上記アクション管理部60は、監視制御データに従って、1以上のアクションモジュール(アクションモジュール群70)を管理する。本実施の形態では、アクションモジュールの例として、CPU制限モジュール71、メモリ制限モジュール72、プロセス死活モジュール73を挙げるが、本発明はこれに限定されない。
図44は、障害対応システム1の処理を示すフローチャートである。
まず、D-Case管理者が、ステークホルダ間の合意のもとで作成、変更されたD-Caseを、D-Case格納部10に格納する(S1;D-Case格納ステップ)。
次に、D-Case変換部21が、D-Case格納部10からD-Caseを読み出し(S2;D-Case読み出しステップ)、読み出したD-Caseから、対応テーブル格納部22に格納されているD-Caseパターン<=>モジュール対応テーブルを参照して、障害監視制御部30の動作を制御する監視制御データを生成する(S3;D-Case変換ステップ)。
なお、D-Caseの変更に伴って監視制御データを生成する場合には、D-Case変換部21は、変更されたD-Caseの差分のみに対応する監視制御データを作成してもよい。
次に、障害監視制御部30が、作成された監視制御データに従って、監視制御対象システム2の状態を監視(モニタ)し、必要な場合に対策(アクション)を実行する(S4;障害監視実行ステップ)。
ここで、上記障害監視実行ステップ(S4)について説明する。
まず、モニタ管理部40には、管理すべきモニタモジュールがあらかじめ制御可能に登録されている。また同様に、アクション管理部60には、管理すべきアクションモジュールがあらかじめ制御可能に登録されている。
そして、障害監視実行ステップ(S4)では、障害監視制御部30が、監視制御データに従ってモニタ管理部40に適切なモニタモジュールを起動するよう指示する。そして、障害監視制御部30は、モニタ管理部40から通知されたモニタモジュールの実行結果が条件を満たす場合、さらに、アクション管理部60に適切なアクションモジュールを起動して障害に対処するように指示する。このとき、モニタ管理部40およびアクション管理部60は、それぞれ、障害監視制御部30からの指示に従ってモジュールを起動し、適切な引数を渡す。
(D-Case変換)
つぎに、図45〜図49を参照しながら、D-Caseから監視制御データへの変換処理について詳細に説明する。
障害対応システム1では、D-Caseから、監視制御対象システム2を監視制御するためのモニタモジュールおよびアクションモジュールの動作を制御する監視制御データへの変換に、D-Caseパターン<=>モジュール対応テーブルを用いる。
ここで、D-Caseパターンとは、監視制御対象システム2のD-Caseの一部であり、可用性などが、システムレベルでどのように維持されるかを示すものである。すなわち、システムの可用性とは、システムが障害などでサービスを行えない状態になったとき(システムダウン状態)、できるだけ早急に復旧し、利用者がサービスを用いたい時にいつでも用いられるようにできるシステムの性質である。障害が発生した場合、保守管理者などの人員により迅速に行うこと、およびシステム自体が自動的に障害復旧機能により復旧を行う。一般にシステムは、OSレベルにおいては、CPU資源、メモリ資源、ネットワーク資源などを用いて、サービスを提供する。したがって、CPU資源などが不足した場合、サービスの遅延などが発生し、可用性が減じる可能性がある。よって、あるサービスに用いるCPU資源が減じた場合、他の重要度の低いサービスで用いられているCPU資源を転用するなどの対応をシステムはOSレベルで自動的に行う。監視制御対象システム2のD-Caseは、上記観点から、システムレベルでの可用性について議論している。
(D-Caseパターン)
図45は、D-Caseパターンを含むD-Caseの具体例を示す説明図である。
D-Caseパターンとは、D-Caseの部分木であり、可変な部分を含むものである。図45はパターンの一例であり、プロセスの属性が適切に保たれることを表現する場合に使用される。サブゴールSG22とエビデンスE25、E26の「」の部分が可変(変数)であり、他は固定されたD-Caseパターンである。図45は、「」内に既に「画像処理」、「CPU使用率」、「50%以下」を代入した状態を示している。このD-CaseパターンがD-Caseの一部として使用される場合に、「」部分にはステークホルダ間の合意に基づく値が代入され、その代入される値により、モニタモジュールやアクションモジュールと適切に関連づけることが可能となる。また、他は固定されたD-Caseである。D-Caseパターン、すなわちD-Caseの「」部分には、ステークホルダ間の合意に基づく値が代入される。また、D-Caseの「」部分に値が代入されることにより、モニタモジュールやアクションモジュールと適切に関連づけることが可能となる。
図46は、D-Caseパターン<=>モジュール対応テーブルの一例であって、(a)はモニタモジュールについての対応テーブルを示し、(b)はアクションモジュールについての対応テーブルを示す。
図46(a)は、≪プロセス「$1」の「$2」が「$3」であることをモニタする≫というD-Caseを、D-Case変換部21が変換するときに参照するテーブルである。このD-Caseでは、$1、$2、$3が変数である。
例えば、図45のD-Caseを処理する際、D-Case変換部21は、エビデンスE25の記述≪プロセス「画像処理」の「CPU仕様率」が「50%以下」であることをモニタする≫に当てはめることができるテーブル(図46(a))を対応テーブル格納部22から読み出す。そして、エビデンスE25の記述から抽出した変数$1、$2、$3の値を用いて、D-Caseパターンとモジュールとの対応関係を特定し、監視制御データを作成する。具体的には、変数$2が“CPU仕様率”であることから、モジュール名“CPU監視”および引数“$1、$3”を特定し、≪「CPU監視」モジュールを呼び出し、「画像処理」「50%以下」を引数として渡す≫という内容の監視制御データを作成する。
同様に、D-Case変換部21は、エビデンスE26の記述≪プロセス「画像処理」の「CPU仕様率」を「50%以下」に制限する≫に当てはめることができるテーブル(図46(b))を対応テーブル格納部22から読み出す。そして、変数$2が“CPU仕様率”であることから、モジュール名“CPU制限”および引数“$1、$3”を特定し、≪「CPU制限」モジュールを呼び出し、「画像処理」「50%以下」を引数として渡す≫という内容の監視制御データを作成する。
上記のように、エビデンスの記述のうち、固定されたD-Caseの文字列(記述の固定部分)に応じて、D-Caseパターン<=>モジュール対応テーブルが選択される。そして、一部の変数(上記の例では、変数$2)の値に応じて、対応するモジュールが選択される。
このように、本実施の形態では、エビデンスの記述を一部に変数が設定された表現形式とし、そのエビデンスに則した値を変数に設定して、エビデンスを記述する。
つぎに、図47、図48を参照して、図45のD-Caseが変更された場合の処理について説明する。
図47は、D-Caseパターンを含むD-Caseの具体例を示す説明図である。
図47では、図45に対して、コンテキストC31が追加されるとともに、エビデンスE26がエビデンスE32に変更されている。これは、≪C31:他のプロセス「顔認識」を制限してでも「画像処理」にCPUを十分与えたい≫ため、≪E32:プロセス「顔認識」を「kill」する≫ことで、各ステークホルダが合意したことを示している。
図48は、このときのD-Caseパターン<=>モジュール対応テーブルの一例である。図48(a)はモニタモジュールについての対応テーブルを示し、図48(b)はアクションモジュールについての対応テーブルを示す。図48(a)は、図46(a)と同じである。
そして、図47のD-Caseを処理する際、D-Case変換部21は、エビデンスE32の記述≪プロセス「顔認識」を「kill」する≫に当てはめることができるテーブル(図48(b))を対応テーブル格納部22から読み出す。そして、エビデンスE32の記述から抽出した変数$1、$2の値を用いて、D-Caseパターンとモジュールとの対応関係を特定し、監視制御データを作成する。具体的には、変数$2が“Kill”であることから、モジュール名“プロセス死活”および引数“$1”を特定し、≪「プロセス死活」モジュールを呼び出し、「Kill」「顔認識」を引数として渡す≫という内容の監視制御データを作成する。
このように、D-Caseパターン<=>モジュール対応テーブルには、引数として、変数だけでなく、定数値を設定しておくこともできる。すなわち、図48(b)では、変数$2の値が“Kill”であれば、プロセス死活モジュール73へ渡す1番目の引数は“Kill”となり、変数$2の値が“Restart”であれば、渡す引数は“Restart”となる。また、変数$2の値が“Migration”であれば、プロセス死活モジュール73ではなく、Migrationモジュール(図示せず)がアクションとして実行されることになる。
つぎに、図49を参照して、新たにモニタモジュールやアクションモジュールを追加した場合の処理について説明する。
新たにモニタモジュールやアクションモジュールを追加した場合には、モニタ管理部40やアクション管理部60に登録する前に、D-Case管理者が、D-Caseパターン<=>モジュール対応テーブルに対応関係を規定するデータ(変換規則)を追加する。
図49は、D-Caseパターン<=>モジュール対応テーブルの一例であって、モニタモジュールについての対応テーブルを示す。例えば、ネットワーク転送量を監視するモジュールを新たに追加した場合、図49のように、図46(a)に1行追加される。
(まとめ)
以上のように、上記障害対応システム1では、モニタ管理部40によるモニタモジュールの選択および動作の制御、並びに、アクション管理部60によるアクションモジュールの選択および制御と、D-Caseパターンとの対応を示すD-Caseパターン<=>モジュール対応テーブルを使用して、D-Caseから監視制御データを生成する。すなわち、D-Case格納部10に格納されたD-Caseは、D-Caseパターン<=>モジュール対応テーブルを参照しながら、障害監視制御部30の監視制御データに変換される。このように、障害監視制御部30が用いる監視制御データが、D-Case部10に格納されたD-Caseから、D-Case変換部21によって生成されることにより、D-Caseと障害監視制御部30の動作との間が常に無矛盾になるように維持される。
また、D-Case格納部10に格納されているD-Caseを変更した場合、その変更はD-Case変換部21によって監視制御データの変更として障害監視制御部30に通知される。なお、D-Caseの変更をディペンダビリティ維持装置20あるいはD-Case変換部21が検知し、変更後の監視制御データを障害監視制御部30に自動的に通知するようにしてもよい。
また、D-Case管理者は、D-Caseに新たにD-Caseパターンを追加した場合、D-Caseパターン<=>モジュール対応テーブルに対応関係を規定するデータ(変換規則)を追加する。
また、モニタモジュールやアクションモジュールを修正・追加した場合、障害対応システム1はD-Case管理者に通知する。D-Case管理者は、修正・追加されたモニタモジュールやアクションモジュールに対応するD-Caseパターン<=>モジュール対応テーブルも合わせて修正する。なお、修正・追加されたモニタモジュールやアクションモジュールに対応するD-Caseパターン<=>モジュール対応テーブルが修正されない場合、モニタモジュールあるいはアクションモジュールがD-Caseと対応できてないので、監視制御データが使用できない。修正されたD-Caseパターン<=>モジュール対応テーブルを使用して監視制御データを修正することによって、D-Caseと障害監視との間の無矛盾性が維持される。
また、D-Caseパターン<=>モジュール対応テーブルは、データベースに蓄積しておき、D-Caseを変更する際、適切なD-Caseパターン<=>モジュール対応テーブルを参照するように、データベースから抽出して利用するようにしてもよい。これにより、D-Caseの変更の度にD-Caseパターン<=>モジュール対応テーブルを作成する必要がなくなり、低コストでD-Caseの変更に対応することが可能となる。
つづいて、図50〜図56を参照しながら、他の具体例について説明する。
図50および図51は、D-Caseの他の具体例を示す説明図である。図50と図51は連結部Aで連結されて、一つの木構造となる。また、図52〜図55は、図50、図51に示したD-CaseをXML形式で記述した例を示す説明図である。なお、図52〜図55には、図50、図51に示したD-Caseから一部を抜粋して示している。図56は、図50、図51、および図52〜図55に示したD-Caseから変換した監視制御データ(障害対応スクリプト)の例を示す説明図である。
図52〜図55に示すように、本具体例では、D-CaseのXMLファイルに障害監視制御部30を制御する障害対応スクリプトが埋めこまれている。そして、図56が、D-CaseのXMLファイル(図52〜図55)の「Monitor:M_1」〜「Monitor:M_5」からそれぞれ抽出されたスクリプトである。なお、図50および図51は、図52〜図55をグラフィカルに表示したものであり、データには障害対応スクリプトも含まれている。
このように、D-Caseに障害対応スクリプトが埋め込まれている点が、図45〜図49を参照しながら説明した、D-Caseパターン<=>モジュール対応テーブル具体例とは異なっている。しかしながら、ステークホルダの合意を示すD-Caseと、監視制御対象システムの障害対応スクリプトとの間を無矛盾に更新することができる点では同じである。
本発明は以下のように構成してもよい。
本発明のディペンダビリティ維持装置20は、監視制御対象システム2の状態を監視し、必要な場合に対策を実行する障害監視制御部30の動作を制御する障害監視制御用データ(監視制御データ)を生成し、上記障害監視制御部30に供給するディペンダビリティ維持装置20であって、上記監視制御対象システム2のディペンダビリティに関する仕様を記述したディペンダビリティ記述データ(D-Case)をディペンダビリティ記述格納部(D-Case格納部10)から読み出し、読み出したディペンダビリティ記述データから上記障害監視制御用データを生成するディペンダビリティ記述変換部(D-Case変換部21)を備えて構成されていてもよい。
また、本発明のディペンダビリティ維持装置20の制御方法は、監視制御対象システム2の状態を監視し、必要な場合に対策を実行する障害監視制御部30の動作を制御する障害監視制御用データを生成し、上記障害監視制御部30に供給するディペンダビリティ維持装置20の制御方法であって、上記監視制御対象システム2のディペンダビリティに関する仕様を記述したディペンダビリティ記述データ(D-Case)をディペンダビリティ記述格納部(D-Case格納部10)から読み出す読み出しステップ(S2)と、読み出したディペンダビリティ記述データから上記障害監視制御用データを生成する変換ステップ(S3)とを含む方法であってもよい。
さらに、上記ディペンダビリティ維持装置20は、上記障害監視制御部30は、上記監視制御対象システム2の状態を監視し、必要な場合に対策を実行するために使用するモジュールを、複数のモジュール(モニタモジュール群50、アクションモジュール群70)から選択して制御可能であり、上記ディペンダビリティ記述データは、1つの記述(エビデンス)が、上記モジュールを特定するためのモジュール特定情報(変数$2;パターン)を値として設定可能な変数を少なくとも含む形式であり、上記ディペンダビリティ記述変換部は、あらかじめ設定された、上記モジュール特定情報と上記障害監視制御用データとの対応関係を示す情報(D-Caseパターン<=>モジュール対応テーブル)に基づいて、上記ディペンダビリティ記述データに含まれる変換対象の記述を、該記述に含まれるモジュール特定情報に対応する障害監視制御用データに変換するように構成されていてもよい。
さらに、上記ディペンダビリティ維持装置20は、上記ディペンダビリティ記述データの1つの記述から変数部分を除いた固定部分に対応して、上記対応関係が設定されており、上記ディペンダビリティ記述変換部は、上記ディペンダビリティ記述データの記述に含まれる上記固定部分に対応する上記対応関係を参照して、該記述を対応する障害監視制御用データに変換するように構成されていてもよい。
また、本発明の障害対応システム1は、上記のディペンダビリティ維持装置20と、上記ディペンダビリティ記述格納部(D-Case格納部10)と、上記障害監視制御部30とを含み、上記ディペンダビリティ維持装置20が上記ディペンダビリティ記述格納部から読み出したディペンダビリティ記述データから生成した障害監視制御用データに従って、上記障害監視制御部30が動作することにより、上記監視制御対象システム2の状態を監視し、必要な場合に対策を実行するように構成されていてもよい。
さらに、上記障害対応システム1は、上記監視制御対象システム2の状態を監視する1以上のモニタモジュール(モニタモジュール群50)と、必要な場合に上記監視制御対象システム2に対して対策を実行する1以上のアクションモジュール(アクションモジュール群70)と、上記障害監視制御部30の制御により、上記モニタモジュールの選択および動作の制御を行うモニタ管理部40と、上記障害監視制御部30の制御により、上記アクションモジュールの選択および動作の制御を行うアクション管理部60と、を含んで構成されていてもよい。
また、本発明は以下のように構成してもよい。
本発明に係るコンピュータシステム(障害対応システム1)は、ステークホルダ間のディペンダビリティに関する合意を記述したディペンダビリティ記述データ(D-Case)を格納するディペンダビリティ記述格納部(D-Case格納部10)と、対象システム(監視制御対象システム2)内の状態を監視(モニタ)し必要な場合に対策(アクション)を実行する障害監視制御部(障害監視制御部30)と、障害監視制御部の動作を制御する障害監視制御用データ(監視制御データ)をディペンダビリティ記述データから生成するディペンダビリティ記述変換部(D-Case変換部21)とを持ち、障害監視制御用データが常にディペンダビリティ記述格納部に格納されたディペンダビリティ記述データからディペンダビリティ記述変換部によって生成されることによりディペンダビリティ記述と障害監視制御部の動作とが無矛盾に維持されるように構成されていてもよい。
さらに、上記コンピュータシステムは、ディペンダビリティ記述はその一部分がパターン化されており、ディペンダビリティ記述のパターンと障害監視制御用データの対応を表わすテーブル(D-Caseパターン<=>モジュール対応テーブル)を使用して障害監視制御用データをディペンダビリティ記述から生成するように構成されていてもよい。
さらに、上記コンピュータシステムは、障害監視制御部はモニタ管理部(モニタ管理部40)とアクション管理部(アクション管理部60)を持ち、モニタ管理部は1以上のモニタモジュール(モニタモジュール群50)を管理し、アクション管理部は1以上のアクションモジュール(アクションモジュール群70)を管理し、モニタ管理部によるモニタモジュールの選択および動作の制御、並びに、アクション管理部によるアクションモジュールの選択および制御と、ディペンダビリティ記述のパターンとの対応を示すテーブルを使用して障害監視制御用データをディペンダビリティ記述から生成するように構成されていてもよい。
さらに、上記コンピュータシステムの制御方法は、ステークホルダ間のディペンダビリティに関する合意を記述したディペンダビリティ記述データを格納するディペンダビリティ記述格納ステップ(D-Case格納ステップS1)と、障害監視制御部が対象システム内の状態を監視し必要な場合に対策を実行する障害監視制御ステップ(障害監視実行ステップS3)と、障害監視制御ステップの動作を制御する障害監視制御用データをディペンダビリティ記述から生成するディペンダビリティ記述変換ステップ(D-Case読み出しステップS2、D-Case変換ステップS3)とを持ち、障害監視制御用データが常にディペンダビリティ記述格納ステップによって格納されたディペンダビリティ記述データからディペンダビリティ記述変換ステップによって生成されることによりディペンダビリティ記述と障害監視制御部の動作とが無矛盾に維持されるように構成されていてもよい。
また、障害対応システム1の各ブロック、特にディペンダビリティ維持装置20のD-Case変換部21は、ハードウェアロジックによって構成してもよいし、次のようにCPUを用いてソフトウェアによって実現してもよい。
後者の場合、障害対応システム1は、各機能を実現するプログラムの命令を実行するCPU(central processing unit)、上記プログラムを格納したROM(read only memory)、上記プログラムを展開するRAM(random access memory)、上記プログラムおよび各種データを格納するメモリ等の記憶装置(記録媒体)などを備えている。そして、本発明の目的は、上述した機能を実現するソフトウェアである障害対応システム1あるいはディペンダビリティ維持装置20の制御プログラムのプログラムコード(実行形式プログラム、中間コードプログラム、ソースプログラム)をコンピュータで読み取り可能に記録した記録媒体を、上記の障害対応システム1あるいはディペンダビリティ維持装置20に供給し、そのコンピュータ(またはCPUやMPU)が記録媒体に記録されているプログラムコードを読み出し実行することによっても、達成可能である。
上記記録媒体としては、例えば、磁気テープやカセットテープ等のテープ系、フロッピー(登録商標)ディスク/ハードディスク等の磁気ディスクやCD−ROM/MO/MD/DVD/CD−R等の光ディスクを含むディスク系、ICカード(メモリカードを含む)/光カード等のカード系、あるいはマスクROM/EPROM/EEPROM/フラッシュROM等の半導体メモリ系などを用いることができる。
また、上記の障害対応システム1あるいはディペンダビリティ維持装置20を通信ネットワークと接続可能に構成し、上記プログラムコードを通信ネットワークを介して供給してもよい。この通信ネットワークとしては、特に限定されず、例えば、インターネット、イントラネット、エキストラネット、LAN、ISDN、VAN、CATV通信網、仮想専用網(virtual private network)、電話回線網、移動体通信網、衛星通信網等が利用可能である。また、通信ネットワークを構成する伝送媒体としては、特に限定されず、例えば、IEEE1394、USB、電力線搬送、ケーブルTV回線、電話線、ADSL回線等の有線でも、IrDAやリモコンのような赤外線、Bluetooth(登録商標)、802.11無線、HDR、携帯電話網、衛星回線、地上波デジタル網等の無線でも利用可能である。なお、本発明は、上記プログラムコードが電子的な伝送で具現化された、搬送波に埋め込まれたコンピュータデータ信号の形態でも実現され得る。
上記説明では、機能ブロックおよび手順を図示し参照したが、機能の分離併合または手順の移動は上記機能を満たす限り可能であり、上記説明が本発明を限定するものではない。
(1)本発明に係るディペンダビリティ維持装置は、監視制御対象システムの状態を監視し、必要な場合に対策を実行する障害監視制御部の動作を制御する障害監視制御用データを生成し、上記障害監視制御部に供給するディペンダビリティ維持装置であって、上記監視制御対象システムのディペンダビリティに関する(ステークホルダ群によって合意された)要求・仕様を記述したディペンダビリティ記述データをディペンダビリティ記述格納部から読み出し、読み出したディペンダビリティ記述データから上記障害監視制御用データを生成するディペンダビリティ記述変換部を備えたことを特徴としている。
(6)また、本発明に係るディペンダビリティ維持装置の制御方法は、監視制御対象システムの状態を監視し、必要な場合に対策を実行する障害監視制御部の動作を制御する障害監視制御用データを生成し、上記障害監視制御部に供給するディペンダビリティ維持装置の制御方法であって、上記監視制御対象システムのディペンダビリティに関する(ステークホルダ群によって合意された)要求・仕様を記述したディペンダビリティ記述データをディペンダビリティ記述格納部から読み出す読み出しステップと、読み出したディペンダビリティ記述データから上記障害監視制御用データを生成する変換ステップとを含むことを特徴としている。
上記の構成によれば、ディペンダビリティ維持装置がディペンダビリティ記述格納部から読み出したディペンダビリティ記述データから障害監視制御用データを生成する。そして、これに従って障害監視制御部が動作することにより、障害監視制御部が監視制御対象システムの状態を監視し、必要な場合に対策を実行することができる。
ここで、ペンダビリティ記述データは、監視制御対象システムのディペンダビリティに関わる仕様を記述したものである。そして、監視制御対象システムの各ステークホルダが監視制御対象システムのディペンダビリティに関して合意した際、その結果がペンダビリティ記述データとして記述され、ディペンダビリティ記述格納部に格納されたものであることが望ましい。
このように、障害監視制御部が用いる障害監視制御用データが、ディペンダビリティ記述格納部に格納されたディペンダビリティ記述データから、ディペンダビリティ維持装置によって生成されることにより、ディペンダビリティ記述データと障害監視制御部の動作とが常に無矛盾になるように維持することが可能となる。
(2)さらに、本発明に係るディペンダビリティ維持装置は、上記(1)に記載の構成において、上記障害監視制御部は、上記監視制御対象システムの状態を監視し、必要な場合に対策を実行するために使用するモジュールを、複数のモジュールから選択して制御可能であり、上記ディペンダビリティ記述データは、1つの記述が、上記モジュールを特定するためのモジュール特定情報を値として設定可能な変数を少なくとも含む形式であり、上記ディペンダビリティ記述変換部は、あらかじめ設定された、上記モジュール特定情報と上記障害監視制御用データとの対応関係を示す情報に基づいて、上記ディペンダビリティ記述データに含まれる変換対象の記述を、該記述に含まれるモジュール特定情報に対応する障害監視制御用データに変換することを特徴としている。
上記の構成によれば、さらに、ディペンダビリティ記述データに含まれる変換対象の記述を障害監視制御用データに変換する際、該記述に含まれるモジュール特定情報によって特定されるモジュールを障害監視制御部に選択させ、制御させる障害監視制御用データを生成する。
これにより、障害監視制御部が制御可能なモジュールが複数ある場合であっても、ディペンダビリティ記述データの記述から適切なモジュールを制御対象とした障害監視制御用データを生成することが可能となる。
(3)さらに、本発明に係るディペンダビリティ維持装置は、上記(2)に記載の構成において、上記ディペンダビリティ記述データの1つの記述から変数部分を除いた固定部分に対応して、上記対応関係が設定されており、上記ディペンダビリティ記述変換部は、上記ディペンダビリティ記述データの記述に含まれる上記固定部分に対応する上記対応関係を参照して、該記述を対応する障害監視制御用データに変換することを特徴としている。
上記の構成によれば、さらに、ディペンダビリティ記述データに含まれる変換対象の記述を障害監視制御用データに変換する際、該記述からに含まれる変数部分を除いた固定部分に対応した対応関係を参照して、該記述を対応する障害監視制御用データに変換する。
これにより、ディペンダビリティ記述データに含まれる記述の固定部分毎に、異なる対応関係を対応付けておくことが可能となる。よって、モジュール特定情報等の変数が同じであっても、固定部分が異なれば、異なる対応関係を用いて、ディペンダビリティ記述データに含まれる記述を障害監視制御用データに変換することができる。それゆえ、多様な変換を簡易な規則によって実現することができる。
(4)また、本発明に係る障害対応システムは、上記(1)から(3)のいずれかに記載のディペンダビリティ維持装置と、上記ディペンダビリティ記述格納部と、上記障害監視制御部とを含み、上記ディペンダビリティ維持装置が上記ディペンダビリティ記述格納部から読み出したディペンダビリティ記述データから生成した障害監視制御用データに従って、上記障害監視制御部が動作することにより、上記監視制御対象システムの状態を監視し、必要な場合に対策を実行するように構成してもよい。
(5)さらに、本発明に係る障害対応システムは、上記(4)に記載の構成において、上記監視制御対象システムの状態を監視する1以上のモニタモジュールと、必要な場合に上記監視制御対象システムに対して対策を実行する1以上のアクションモジュールと、上記障害監視制御部の制御により、上記モニタモジュールの選択および動作の制御を行うモニタ管理部と、上記障害監視制御部の制御により、上記アクションモジュールの選択および動作の制御を行うアクション管理部と、を含むように構成してもよい。
なお、上記のディペンダビリティ維持装置および障害対応システムは、コンピュータによって実現してもよく、この場合には、コンピュータを上記ディペンダビリティ記述変換部として動作させることにより上記ディペンダビリティ維持装置をコンピュータにて実現させるディペンダビリティ維持装置のプログラム、およびそれを記録したコンピュータ読み取り可能な記録媒体も、本発明の範疇に入る。
上記説明では、機能ブロックおよび手順を図示し参照したが、機能の分離併合または手順の移動は上記機能を満たす限り可能であり、上記説明が本発明を限定するものではない。
発明の詳細な説明の項においてなされた具体的な実施態様または実施例は、あくまでも、本発明の技術内容を明らかにするものであって、そのような具体例にのみ限定して狭義に解釈されるべきものではなく、本発明の精神と次に記載する特許請求事項との範囲内で、いろいろと変更して実施することができるものである。