JPWO2015146081A1 - リスク管理装置、リスク管理プログラムを記録する記録媒体、及びリスク管理方法 - Google Patents

Abstract

本発明のリスク管理装置は、情報処理システムに接続する複数の機器のそれぞれについて、機器を除去した場合の可用性の改善度を、機器の故障率又は復旧率を基に算出する比較手段と、改善度を機器に関連づけて出力する決定手段とを含む。

Description

本発明は、情報処理システムにおけるリスクを、効率的に除去するリスク管理技術に、関する。

クラウドデータセンタなどの情報処理システムの稼働率、障害復旧時間を分析することは、情報処理システムの可用性（Availability）を高めるために、極めて重要である。「可用性」とは、ある一定期間のうち、利用者がサービスを利用できる割合である。可用性の数値として表現は、稼働率（Operating ratio）とも呼ばれる。例えば、１日のうち平均的に１分だけ利用できない時間帯がある場合、その稼働率（可用性）は、「１−１÷（２４×６０）＝９９．９３％」となる。一般に、稼働率（可用性）は、障害が発生する時間間隔である平均故障間隔（ＭＴＢＦ：Mean Time Between Failure）と、障害が復旧するまでの時間である平均修理時間（ＭＴＴＲ：Mean Time To Repair）とを基に、算出される。なお、平均修理時間は、平均修復時間（ＭＴＴＲ：Mean Time To Recovery）とも呼ばれる。例えば、稼働率は、「稼働率＝ＭＴＢＦ／（ＭＴＢＦ＋ＭＴＴＲ）」として求めることができる。

可用性を分析するためのツールとして、可用性予測モデルが、注目されている。可用性予測モデルは、可用性を算出、検証、及び分析するための数学的なモデル、モデルを表す計算式、並びに、計算式のパラメータを含む。また、可用性予測モデルは、対象とする情報処理システムの構成及び挙動に関連する情報を含む。ここで、可用性予測モデルにおける基本となる機能は、情報処理システム全体の稼働率を予測する機能である。

情報処理システムのハードウェアの可用性予測に関する方法として、ハードウェアを構成する部品の特性を基に、情報処理システム全体の故障の可能性を分析する方法が、広く知られている。この方法は、フォルトツリー（Fault Tree）などの数学的なモデルを用いて、故障の可能性を分析する。
一方、ソフトウェアの可用性予測に関する方法としては、シミュレーションを用いて遷移を再現して、可用性を分析する方法が知られている。この方法では、状態の遷移が、確率的ペトリネット（Stochastic petri net）又は確率的報酬ネット（Stochastic reward net）などの数学的なモデルを用いて記述される。

確率的ペトリネット又は確率的報酬ネット等の技術を用いた可用性予測モデルを用いて、可用性の算出又は検証を行う一例を、図１Ａないし図１Ｃに示す。図１Ａないし１Ｃは、可用性予測モデルを基に可用性の算出又は検証を行うための、状態遷移図の一例である。角丸長方形（以降、プレース（place）と呼ぶ）は、情報処理システムの取り得る状態を表す。例えば、各丸長方形は、物理サーバが正常に稼働している状態、又は、障害等の理由で停止している状態を表す。プレースとプレースとの間の矢印（以降、アーク（arc）と呼ぶ）は、アークの元のプレースが表す状態から、アークの先のプレースが表す状態への遷移が生じ得ることを示す。アークには、遷移する確率の値が、付される。稼働中を表すプレースから、停止中を表すプレースへのアークには、遷移確率として、故障率が、付される。また、停止中を表すプレースから、稼働中を表すプレースへのアークには、遷移確率として、復旧率が、付される。アークの方向に対して垂直に付された太い線（以降、ガード・ファンクション（guard function）と呼ぶ）は、アークが表す状態遷移が起こるための前提条件である。ガード・ファンクションに付された記述が、具体的な前提条件の詳細である。

例えば、仮想サーバが、稼働している状態から停止している状態への遷移するためには、仮想サーバが動作している物理サーバが、稼働中の状態であることが必要である。この場合の前提条件は、「物理サーバが、稼働中の状態にあること」となる。

ここで、説明の前提として、例えば、次のような情報処理システムを、想定する。
情報処理システムにおいて、アプリケーションが仮想サーバ上で稼働し、仮想サーバが物理サーバ上で稼働している。ここで、仮想サーバは、仮想マシン（ＶＭ：Virtual Machine）とも呼ばれる。そのため、仮想サーバの略語として、"ＶＭ"が用いられる。物理サーバが正常に運転している状態は、「物理サーバ稼働中」と定義された状態である。仮想サーバが正常に運転している状態は、「仮想サーバ稼働中」と定義された状態である。アプリケーションが正常に実行されている状態は、「アプリケーション稼働中」と定義された状態である。物理サーバ、仮想サーバ、又は、アプリケーションに何らかの障害が発生している状態は、この順番に、「物理サーバ停止中」、「仮想サーバ停止中」、又は、「アプリケーション停止中」と定義された状態である。

なお、ここで用いている仮想サーバは、データセンタ管理者がアクセスできる仮想サーバの制御プログラムを指すハイパーバイザ（hypervisor：仮想マシンを実現するための制御プログラム）ではない。仮想サーバは、利用者に割り当てられ、その利用者がアクセスできる一般的な仮想サーバである。すなわち、仮想サーバは、利用者が用いる仮想サーバ（以下、ユーザＶＭとも呼ぶ）である。

また、確率的ペトリネットを用いたシミュレーションを基に、遷移が、再現される。そして、この遷移を基に可用性を分析することが、可能となる。

データセンタの管理者は、確率的ペトリネットに記述される状態及び遷移を、サーバを取り巻く環境（一般に「サーバインフラ」とも呼ばれる）の特性と、そのサーバインフラに係るデータセンタ運用手順とを加味して、作成する。すなわち、運用手順に応じて、様々な可用性予測モデルが、作成される場合がある。

しかし、単に可用性を分析するだけでは、情報処理システムの可用性を高めることは、できない。情報処理システムの可用性を現実的に高めるためには、ユーザに対する改善策の提示が、必要である。改善策には、一例として、情報処理システムに冗長構成を適用すること、がある。また、他の例として、信頼性の低い機器を信頼性の高い機器にリプレースすること（除去案）がある。これらの改善策を基に、共有リスク要因を除去することが可能となる。なお、除去案が複数ある場合には、可用性を改善するという観点で、最も効果的な除去案を、選択可能であることが望ましい。

特許文献１は、情報処理システム全体の稼働率を予測する方法を開示している。稼働率の予測は、一例として、情報処理システムを構成する個々のコンピュータで障害が発生する割合と、その障害の修復に掛かる時間とを基に実行される。このような、障害が発生する割合及び障害の修復に掛かる時間に係る特性は、稼働中の情報処理システムの監視情報に基づいて、得ることができる。

特許文献２は、故障率が基準値を満たしているか否かを分析する方法を開示している。故障率は、ソフトウェア及び／又はハードウェアに係る情報処理システムの構成情報を基に、故障の判定を行うためのフォルトツリー（Fault Tree）を合成し、合成したフォルトツリーを基に算出される。

特許文献３は、可用性を初めとする各種データを、アプリケーションプログラム及びアプリケーションサービスのインストールに際して、メタデータとして登録することを、開示している。ここで、各種データは、機能、構成、セキュリティ、及び性能に関するデータを含む。また、特許文献３は、これらのメタデータを、構成管理、障害検出、診断、及び復旧などの分析に用いる方法を開示している。

特許文献４は、故障が起こるたびに、その故障が継続した時間と、故障に基づいてサービスを利用できなかった利用者数とを記憶することを開示している。また、特許文献４は、蓄積されたこれらのデータを利用して、故障時間の割合、利用者一人当たりの故障を受けた割合、及び稼働率などを推定する方法を、開示している。

特表２００８−５３２１７０号公報 特開２００６−１２７４６４号公報 特表２００７−５０９４０４号公報 特開２００５−０８０１０４号公報

特許文献１は、稼働率を予測する技術を開示しているが、情報処理システムを構成する機器に対する改善策を提示することに関しては、言及がない。

特許文献２は、故障率を分析する技術を開示しているが、情報処理システムを構成する機器に対する改善策を提示することに関しては言及がない。

特許文献３は、可用性のメタデータを登録し、これを情報処理システムの構成管理に用いることを開示しているが、特定の機器の除去及び交換などの改善策を提示するものではない。

特許文献４は、利用者一人当たりの故障を受けた割合及び稼働率を推定する方法を開示しているが、改善策を提示するものではない。

本発明の主たる目的は、複数の情報処理システム改善策の中から、最適な改善策を、効率良く、選択できるようにすることである。

本発明の一形態におけるリスク管理装置は、情報処理システムに接続する複数の機器のそれぞれについて、前記機器を除去した場合の可用性の改善度を、前記機器の故障率又は復旧率を基に算出する比較手段と、前記改善度を前記機器に関連づけて出力する決定手段とを含む。

本発明の一形態における記録媒体は、情報処理システムに接続する複数の機器のそれぞれについて、前記機器を除去した場合の可用性の改善度を、前記機器の故障率又は復旧率を基に算出する比較処理と、前記改善度を前記機器に関連づけて出力する決定処理とをコンピュータに実行させるリスク管理プログラムを格納する。

本発明の一形態におけるリクス管理方法は、情報処理システムに接続する複数の機器のそれぞれについて、前記機器を除去した場合の可用性の改善度を、前記機器の故障率又は復旧率を基に算出し、前記改善度を前記機器に関連づけて出力する。

更に、本発明は、上記構成を有するリスク管理装置を、コンピュータを用いて実現可能なプログラム、又は、そのようなプログラムが格納されたコンピュータが読み取り可能な記憶媒体も含む。

また、同目的は、上記構成を有するリスク管理装置及びリスク管理方法を、コンピュータを用いて実現するコンピュータプログラム、及び、そのコンピュータプログラムが格納されているコンピュータ読み取り可能な記憶媒体を用いても達成される。

本発明によれば、複数の情報処理システム改善策の中から、最適な改善策を、効率良く、選択できるとの効果を奏する。

図１Ａは、状態遷移図の一例である。 図１Ｂは、状態遷移図の一例である。 図１Ｃは、状態遷移図の一例である。 図２は、本発明の第１の実施形態の構成を示すブロック図である。 図３は、本発明の第１の実施形態の共有リスク管理表の一例である。 図４は、本発明の第１の実施形態の機器特性管理表の一例である。 図５は、本発明の第１の実施形態のサービス特性管理表の一例である。 図６は、本発明の第１の実施形態の除去案管理表の一例である。 図７は、本発明の第１の実施形態の影響度管理表の一例である。 図８は、本発明の第１の実施形態の適用後影響度管理表の一例である。 図９は、本発明の第１の実施形態の改善度管理表の一例である。 図１０は、本発明の第１の実施形態の動作を示すフローチャートである。 図１１は、本発明の第２の実施形態の機器の接続を表すブロック図である。 図１２は、本発明の第４の実施形態の構成を示すブロック図である。 図１３は、本発明の第１乃至第４の実施形態をコンピュータプログラムで実行することが可能な情報処理装置の構成を例示するブロック図である。

以下、図面を参照して、本発明における実施形態を説明する。
（第１の実施形態）
本実施形態は、本発明におけるリスク管理装置１００を、情報処理システムに適用した実施形態である。図２〜図９を用いて、本実施形態を詳細に説明する。図２は、本実施形態に係る機能を表すブロック図である。本実施形態は、リスク管理装置１００と、影響度算出部１、表示部１２、監視部１３とを含む。リスク管理装置１００は、比較部２と決定部３とを含む。

影響度算出部１は、入力された共有リスク管理表４、機器特性管理表５、及びサービス特性管理表６を用いて、障害を起こした装置が及ぼすサービス影響度ベクトルを算出する。また、影響度算出部１は、サービス影響度ベクトル管理表を出力する。サービス影響度ベクトル管理表は、影響度管理表７とも呼ばれる。サービス影響度ベクトルとは、サービスごとに算出したサービス影響度を、並べてベクトルの形式で、表記したものである。例えば、影響度管理表７において、サービス影響度ベクトルとは、３つの要素を持つベクトル（サービスＳＶ_１への影響度、サービスＳＶ_２への影響度、及びサービスＳＶ_３への影響度）のことである。

比較部２は、入力された共有リスク管理表４と、機器特性管理表５と、サービス特性管理表６と、除去案管理表８とを用いて、除去案適用後サービス影響度ベクトルを算出する。そして、比較部２は、算出した結果を用いて構成された除去案適用後サービス影響度ベクトル管理表を出力する。除去案適用後サービス影響度ベクトル管理表は、適用後影響度管理表９とも呼ばれる。

決定部３は、入力された影響度管理表７と適用後影響度管理表９とを基に、改善度管理表１０を作成する。決定部３は、改善度管理表１０の中から、後述する改善度の高さ、又は、単位費用当たりの改善度の高さ、という観点で選択した除去案を、表示部１２に出力する。除去するための費用に上限が設定されている場合は、この上限値（この上限値を除去費用上限１１と呼ぶこととする）が、選択した除去案に加味されてもよい。

共有リスク管理表４と、機器特性管理表５と、サービス特性管理表６と、除去案管理表８とに記載される内容、及び、除去費用の上限値は、通信ネットワークを経由して管理者が設定した情報を読み込んだデータであってもよい。又は、この上限値は、管理者が操作する装置又は機器（例えば、キーボード）から入力として受信したデータでもよい。

決定部３は、選択した除去案を、表示部１２に出力する。表示部１２は、各種ディスプレイ装置である。

監視部１３は、監視対象の情報処理装置（監視対象装置１４）の運用状況を監視し、接続されている機器の種類、故障率、又は復旧率に関する最新のデータを、共有リスク管理表４、機器特性管理表５、及びサービス特性管理表６に送信する。

図３に示すように、共有リスク管理表４には、「共有リスク要因となる機器の識別子」ごとに、「共有リスクが影響を与える対象の機器の識別子」が、格納されている。共有リスク管理表４は、関係データベース（Relational database）に、テーブルとして、保持されてもよいし、テキスト形式のファイルとして保持されてもよい。情報処理システムの構成が更新された際は、共有リスク管理表４に、新しい共有リスク要因となる機器を表す識別子が、追記される。既に記載されている共有リスク要因となる機器が除去された場合は、その機器を表す識別子が、削除される。共有リスク要因となる機器が交換された場合は、その機器を表す識別子が、交換された機器を表す識別子に修正される。

共有リスクの要因となる機器の識別子の項目には、リスク要因と成り得る故障を引き起こす機器を表す識別子が、記載される。共有リスク要因が影響を与える機器を表す識別子としては、物理サーバだけでなく、仮想サーバ、又は、ネットワークルータの識別子が、記載される。

さらに、アプリケーションプログラムを機器の一種と把握した場合、機器を示す識別子として、アプリケーションプログラムが、挙げられてもよい。アプリケーションプログラムを挙げる場合には、記載される識別子に、「仮想サーバの識別子」、「ネットワークルータの識別子」、又は「アプリケーションプログラムの識別子」等の、機器を特定できるリソース識別子が、使用される。

図４に示すように、機器特性管理表５には、機器の識別子毎に、その機器の故障率λと復旧率μとが、格納されている。新しい機器が導入された際は、機器特性管理表５に、新しい機器を表す識別子が、追記される。また、既に記載されている機器を除去する場合は、機器の項目が、削除される。また、機器が交換される場合は、機器の識別子が、交換後の機器の識別子に修正される。

機器の「故障率λ」は、その機器が単独で稼動している時の故障の確率を表わす。機器「復旧率μ」は、その機器が故障した場合に、その後、復旧する確率を表わす。これらは、０から１までの連続な実数値の範囲における、いずれかの値を取る。これらの値は、共有リスク要因の影響を受けて、変化することはない。すなわち、これらの値は、その機器単独の特性を表す。機器特性管理表５に格納される機器の識別子は、物理サーバの識別子だけではない。機器特性管理表５に格納される機器の識別子は、仮想サーバの識別子、ネットワークルータの識別子、又はアプリケーションプログラムの識別子であってもよい。

図５に示すように、サービス特性管理表６には、ユーザサービスごとに、そのユーザサービスの動作に必要な「アプリケーションプログラムの識別子」が、格納される。情報処理システムに新しいユーザサービスを導入する際には、この表に、新しいユーザサービスを、追記することができる。既に記載されているユーザサービスを中止する場合は、そのユーザサービスの識別子が、削除される。ユーザサービスが別のユーザサービスに変更される場合は、ユーザサービスの識別子とアプリケーションの識別子とが、修正される。

図６に示すように、除去案管理表８は、除去案１２１の識別子ごとに、その除去案１２１に基づいて除去される「共有リスク要因となる機器の識別子」と、除去に要する費用である「除去費用」と、「除去作業の内容」とを、関連づけて、格納する。「除去費用」としては、リスク要因を取り除く作業に要する費用（金額とも呼ぶ）が、格納される。リスク要因を取り除く作業としては、冗長構成の適用又は信頼性の高い別の機器へのリプレースなどが、ある。また、「除去費用」には、その作業に掛かる時間又は作業に従事する技術者の人数が、格納されてもよい。

信頼性の高い機器が購入できるようになった状況では、新しい除去案１２１を導入する必要が生まれることがある。その場合には、除去案管理表８に、新しい除去案１２１が、追加で格納される。また、適用済みの除去案１２１又は新しい除去案１２１で代替される古い除去案１２１を消去するために、既に記載されている除去案１２１は、削除できる。また、除去案１２１を別な除去案１２１に変更することができる。

図７に示すように、影響度管理表７は、「共有リスク要因となる機器の識別子」ごとに、各ユーザサービスに与えられる「影響度」を格納する。ユーザサービスへの「影響度」は、ゼロ又は正の実数値で表される。「影響度」は、その値が大きいほど、機器の故障に基づくユーザサービスに与える影響が大きいことを示す。すなわち、「影響度」は、可用性の指標となる値である。

図８に示すように、適用後影響度管理表９は、「共有リスク要因となる機器の識別子」と、ユーザサービスごとのそのユーザサービスに与えられる「影響度」とを、除去案管理表８に記載された除去案１２１の識別子と関連づけて、格納する。

図９に示すように、改善度管理表１０は、「共有リスク要因となる機器の識別子」と、「改善度」と、除去に要する費用に関する「単位費用あたりの改善度」とを、除去案１２１の識別子と関連づけて、格納する。「改善度」は、除去案１２１の適用に基づいて、ユーザサービスの可用性が改善される度合いを表す。「単位費用あたりの改善度」は、改善度を除去費用で割った値である。この値が大きいことは、少ない費用で多くの効果を得られることを意味している。
[動作の説明]
図１０のフローチャートを参照して、本実施形態の全体の動作について、詳細に説明する。

影響度算出部１は、共有リスク管理表４と、機器特性管理表５と、サービス特性管理表６とに格納されたデータの入力を受ける（ステップＳ−１）。影響度算出部１は、共有リスク管理表４に格納された共有リスク要因となる機器の識別子を、一つずつ読み出す（ステップＳ−２）。影響度算出部１は、その識別子を持つ機器がユーザに提供するサービス（以降ユーザサービス、又は、単に、サービスと呼ばれる）に与える影響度（サービス影響度）を、各ユーザサービスについて、算出する（ステップＳ−３）。影響度の算出方法については、後述する。すべての、共有リスク要因となる機器の識別子の読み込みが完了していない場合（ステップＳ−４にてＮＯ）、影響度算出部１は、共有リスク管理表４に格納されている、機器の識別子のうち、読み込まれていない識別子の読み込みを繰り返す。すべての機器の識別子の読み込みが完了している場合（ステップＳ−４にてＹＥＳ）、影響度算出部１は、算出したすべての機器のサービスへの影響度をまとめて、「サービス影響度ベクトル」として、影響度管理表７に格納する。後述するように、「サービス影響度ベクトル」間の距離が、影響度の改善の度合いに相当する。影響度算出部１は、各サービスについて、影響を受ける機器のすべての識別子を、その機器の除去費用又は除去作業内容に関連づけて、図６に示す除去案管理表８に格納する（ステップＳ−５）。除去案管理表８における各機器と除去費用等との組合せは、除去案と呼ばれる。各除去案は、管理のため、それぞれ異なる識別子を付される。

比較部２は、共有リスク管理表４、機器特性管理表５、サービス特性管理表６、及び除去案管理表８に格納されたデータの入力を受ける（ステップＳ−６）。比較部２は、除去案管理表８に格納されているすべての除去案識別子を、一つずつ読み出す（ステップＳ−７）。比較部２は、読み出した除去案識別子に対応する機器に対して、除去案の指定する対応を施した後の、ユーザサービスに与える影響度を、ユーザサービスごとに、算出する。比較部２は、算出した除去案適用後の影響度を、適用後影響度管理表９に格納する（ステップＳ−８）。

すべての除去案識別子の読み込みを完了した場合（ステップＳ−９にてＹＥＳ）、決定部３は、影響度管理表７と適用後影響度管理表９とを基に、除去案１２１ごとに改善度を算出する。決定部３は、各除去案を適用した場合の改善度を、その除去案の除去案識別子に関連づけて改善度管理表１０に格納する（ステップＳ−１０）。改善度の算出方法については、後述する。

決定部３は、改善度管理表１０と、除去費用上限１１とに格納されたデータの入力を受ける。決定部３は、改善度管理表１０に格納された除去案識別子のうち、その除去案識別子に対応する除去費用が除去費用上限１１以下のものを選択する。決定部３は、選択した除去案識別子を、その除去案識別子に対応する改善度が大きい順に、表示部１２に出力する（ステップＳ−１１）。
[影響度の算出方法の一例]
比較部２は、影響度を、一例として、以下のように算出する。

図１Ａ、図１Ｂ及び図１Ｃに示すように、停止中の物理サーバＰＳ_１が復旧する確率（復旧率とも呼ぶ）をμ_ＰＳ１、停止中の仮想サーバＶＭ_１が復旧する確率μ_ＶＭ１、停止中のアプリケーションサーバＡＰ_１が復旧する確率をμ_ＡＰ１とする。ここでは、アプリケーションサーバＡＰ_ｋが実行するアプリケーションプログラムをアプリケーションプログラムＡＰ_ｋとする。
例えば、μ_ＰＳｉ、μ_ＶＭj、μ_ＡＰkには、機器特性管理表５に格納された値が用いられる。

物理サーバＰＳ_ｉがアプリケーションプログラムＡＰ_ｋに与える影響度を、アプリケーション影響度（ＰＳ_ｉ→ＡＰ_ｋ）とすると、アプリケーション影響度（ＰＳ_ｉ→ＡＰ_ｋ）は、以下の数式（１）で表すことができる。
アプリケーション影響度（ＰＳ_ｉ→ＡＰ_ｋ）=１／μ_ＰＳｉ＋１／μ_ＶＭｊ+１／μ_ＡＰ ・・・（１）
ここで、ｉ、ｊ、及びｋは、1以上の自然数である。ｉ、ｊ、及びｋのそれぞれの最大値は、物理サーバ、仮想サーバ、及びアプリケーションプログラムの個数に相当する。物理サーバＰＳ_ｉが与えるアプリケーション影響度は、物理サーバＰＳ_ｉが影響を与えるすべての仮想サーバＶＭ_ｊからの影響を受けるすべてのアプリケーションプログラムＡＰ_ｋについて、算出することができる。アプリケーションプログラムがこの物理サーバから影響を受けない場合には、アプリケーション影響度は、０とされる。

仮想サーバＶＭｉがアプリケーションサーバＡＰ_ｋに与える影響度を、アプリケーション影響度（ＶＭ_ｊ→ＡＰ_ｋ）とすると、アプリケーション影響度（ＶＭ_ｊ→ＡＰ_ｋ）は、以下の数式（２）で表すことができる。
アプリケーション影響度（ＶＭ_ｊ→ＡＰ_ｋ）＝１／μ_ＶＭｊ+１／μ_ＡＰｋ ・・・（２）
なお、比較部２は、上記の数式（１）と数式（２）との計算式において、復旧率の逆数を用いている。しかし、比較部２は、復旧率の逆数の代わりに、故障率、又は、稼働率（故障率の逆数）と復旧率の調和平均の逆数を用いて計算することもできる。また、機器特性管理表５に、これまでの実績から計算した平均故障間隔時間、平均復旧時間、発生した障害の回数、又は発生した障害において復旧できた回数などを記載しておき、比較部２は、これらの値を、稼働率の逆数の代わりに、用いることもできる。

物理サーバＰＳ_iがサービスＳＶ_ｌに与える影響度は、ＳＶ_ｌに係るすべてのアプリケーションに基づく影響度を足し合わせたものである。数式（１）において、「ｉ」は、サービスＳＶの数を最大値とする、１以上の自然数である。アプリケーションプログラムがこの仮想サーバから影響を受けない場合には、アプリケーション影響度は、０とされる。

物理サーバＰＳ_iがサービスＳＶ_ｌに与える影響度をサービス影響度（ＰＳ_ｉ→ＳＶ_ｌ）とすると、サービス影響度（ＰＳ_ｉ→ＳＶ_ｌ）は、以下の数式（３）で表すことができる。物理サーバＰＳ_ｉに対応するサービスＳＶ_ｌの識別子は、共有リ0スク管理表４、及びサービス特性管理表６に格納された値が用いられる。

・・・（３）

除去案識別子_ｍに対応する機器の識別子が物理サーバＰＳ_ｉの場合には、比較部２は、数式（４）で、除去案識別子_ｍの除去案を適用した後にアプリケーションプログラムが受ける影響度を、計算する。
アプリケーション影響度（ＰＳ_ｉ→ＡＰ_ｋ）^ｍ＝１／μ_ＶＭｊ+１／μ_ＡＰｋ ・・・（４）
除去案識別子_ｍに対応する機器の識別子が仮想サーバＶＭ_ｊの場合には、比較部２は、数式（５）で、除去案識別子_ｍの除去案を適用した後にアプリケーションプログラムが受ける影響度を、計算する。
アプリケーション影響度（ＶＭ_ｉ→ＡＰ_ｋ）^ｍ＝１／μ_ＡＰｋ ・・・（５）
比較部２は、サービス特性管理表６と、数式（４）及び数式（５）で算出したアプリケーション影響度とを用いて、すべての除去案識別子について、サービスごとに、アプリケーション影響度を積算する。比較部２は、数式（６）に示すように、サービス影響度を、計算する。

・・・（６）

この結果から、除去案識別子ごとにサービス影響度ベクトルを出力したものが、図８の適用後影響度管理表９である。
[改善度の算出方法の一例]
決定部３は、基本的に、除去案適用前後のサービス影響度ベクトル間の距離を算出し、この距離を、改善度として、出力する。具体的には、決定部３は、影響度管理表７が格納する所定の除去案識別子に対応する所定のサービスへの影響度の値と、適用後影響度管理表９におけるこの影響度との距離を計算する。この距離が、改善度として出力される値である。
決定部３は、除去案識別子ごとに、対応するサービスに対する除去案適用前の影響度と、除去案適用後の左記のサービスに対する影響度との差異を計算し、この値を改善度とする。
除去案適用前の影響度には、影響度管理表７に記載された、該当する機器の識別子に関係づけられた対応するサービスの影響度の値が、用いられる。
除去案適用後の影響度には、適用後影響度管理表９に記載された、該当する除去案の識別子に関係づけられた対応するサービスの影響度の値が、用いられる。

ここでは、決定部３は、影響度を、ユークリッド空間内のベクトルとみなして、距離を計算している。しかし、決定部３は、座標の差の総和を２点間の距離とするマンハッタン距離を用いて、影響度を計算してもよい。また、決定部３は、統計学で用いられる一般化したマハラノビス距離を用いて、影響度を計算してもよい。

本実施形態の影響度算出部１、比較部２、及び決定部３は、論理回路などのハードウェアで実現されてもよいし、図示されていないメモリに格納されているプログラムを実行することで実現されてもよい。

本実施形態においては、共有リスク管理表４、機器特性管理表５、及びサービス特性管理表６には、あらかじめデータが、格納されている。しかし、本実施形態は、データを、随時、自動的に、更新させてもよい。
この場合、監視部１３が、監視対象の情報処理装置の運用状況を監視し、接続されている機器の種類、故障率、及び復旧率に関する最新のデータを、共有リスク管理表４、機器特性管理表５、及びサービス特性管理表６に、送信する。

本実施形態に基づけば、複数の除去案が、改善度の順に提示される。そのため、ユーザは、効率よく、最善の除去案を選択することができる。
すなわち、本実施形態は、情報処理システム改善策の中から、最適な改善策を効率よく選択できるとの効果を奏することができる。その理由は、比較部２が、情報処理システムに含まれる機器の故障率又は復旧率を基に、機器を除去した場合の可用性の改善度を算出し、決定部３が、算出された改善度を出力するためである。
（第２の実施形態）
図１１の図面を参照して、第２の実施形態について、詳細に説明する。図１１は、仮想サーバを含む情報処理システムの一例を示す。以下の説明では、各装置を、その識別子で呼ぶこととする。

情報処理システム２００は、物理サーバＰＳ_１と、物理サーバＰＳ_２とを含む。

物理サーバＰＳ_１は、仮想サーバＶＭ_１と、仮想サーバＶＭ_２とを含む。仮想サーバＶＭ_１は、アプリケーションプログラムＡＰ_１を含む。仮想サーバＶＭ_２は、アプリケーションプログラムＡＰ_２と、アプリケーションプログラムＡＰ_３とを含む。

物理サーバＰＳ_２は、仮想サーバＶＭ_３と、仮想サーバＶＭ_４とを含む。仮想サーバＶＭ_３は、アプリケーションプログラムＡＰ_４を含む。仮想サーバＶＭ_４は、アプリケーションプログラムＡＰ_５と、アプリケーションプログラムＡＰ_６とを含む。

本実施形態において、共有リスク管理表４、機器特性管理表５、及びサービス特性管理表６は、第１の実施形態で説明したそれぞれの表と同じである。

物理サーバＰＳ_１の除去コストは、除去案管理表８（図６）に示されるように、１０である。物理サーバＰＳ_１は、共有リスク管理表４（図３）に示されるように、含んでいる仮想サーバＶＭ_１と、仮想サーバＶＭ_２とに影響を与える。機器特性管理表５（図４）に示されるように、物理サーバＰＳ_１の故障率は、「λ＝０．０１」である。また、物理サーバＰＳ_１の復旧率は、「μ＝０．９５」である。

影響度管理表７（図７）には、数式（１）、数式（２）、及び数式（３）を用いて算出された共有リスク要因となる機器ごとの影響度が、記載されている。物理サーバＰＳ_１のサービスＳＶ_１への影響度は、「１８３（小数点以下第一位を四捨五入するとする）」である。また、物理サーバＰＳ_１のサービスＳＶ_２への影響度は、「５３３」である。また、物理サーバＰＳ_１のサービスＳＶ_３への影響度は、「０」である。

除去案管理表８（図６）には、物理サーバＰＳ_１、物理サーバＰＳ_２、及び仮想サーバＶＭ_１を、それぞれ、共有リスクの要因とし、これらのいずれかを除去することを提案する３つの除去案が、格納されている。各除去案を採用した場合は、情報処理システム２００は、対応する機器をより信頼性の高い機器に交換すること、又は、対応する機器の数を増加させて冗長度を高めることを用いて、サービスに及ぼされる影響を、低減する。適用後影響度管理表９(図８)には、数式（４）と、数式（５）と、数式（６）とを用いて算出した除去案適用後の各サービスへの影響度が、格納されている。

物理サーバＰＳ_１を共有リスクとし、物理サーバＰＳ_１を除去した後のサービスＳＶ_１への影響度は、「８３」である。同様に、サービスＳＶ_２への影響度は、「２３３」であり、サービスＳＶ_３への影響度は、「０」である。したがって、適用後のサービス影響度ベクトルは、（８３、２３３、０）となる。

これに対して、適用前のサービス影響度ベクトルは、影響度管理表７（図７）から明らかなように、（１８３、５３３、０）である。

決定部３は、適用前のサービス影響ベクトル及び適用後のサービス影響ベクトル間の距離を計算する。距離は、改善度である。つまり、決定部３は、距離の計算を用いて、改善度「３１６（≒（（８３−１８３）^２＋（２３３−５３３）^２＋（０−０）^２）^１／２＝３１６．２２）」を得る。

物理サーバＰＳ_１の除去費用は、除去案管理表８（図６）に示されるように「１０」なので、単位費用当たりの改善度は、「３２」となる。決定部３は、改善度管理表１０（図９）に、改善度と、単位費用当たりの改善度とを、除去案識別子と共有リスク要因とみなした機器の識別子に関連付けて、格納する。決定部３は、同様の計算を、物理サーバＰＳ_２についても行う。この計算に基づき、決定部３は、改善度として「４１２」を、単位費用当たりの改善度として「２７（除去案管理表８より除去費用が１５のため）」を得る。また、決定部３は、仮想サーバＶＭ_１について、改善度として「７１」、単位費用当たりの改善度として「３５（除去案管理表８より除去費用が２のため）」を得る。なお、上記の単位費用当たりの改善度は、小数点以下を四捨五入している。

決定部３は、改善度の大きい順に、表示部１２に除去案を表示する。すなわち、決定部３は、物理サーバＰＳ_２の共有リスクを除去する除去案識別子_２、物理サーバＰＳ_１の共有リスクを除去する除去案識別子_１、及び仮想サーバＶＭ_１の共有リスクを除去する除去案識別子_３の順に、除去案を表示部１２に表示する。

決定部３が、ひとつの除去案を選択するよう設定されている場合には、決定部３は、一例として、もっとも改善度の大きい物理サーバＰＳ_２の共有リスクを除去する案を選択する。

決定部３が、除去費用上限１１の値に基づくよう設定されている場合には、除去費用の上限の値に基づいて、選択される除去案の識別子、及び除去案の個数が、変化する。例えば、除去費用上限１１が、「２５」に設定されている場合、物理サーバＰＳ_２の共有リスクを除去する除去案識別子_２と物理サーバＰＳ_１の共有リスクを除去する除去案識別子_１とが、選択される。また、除去費用上限１１が、「３０」に設定されている場合、すべての除去案が、選択される。

本実施形態に基づけば、効率の観点や、経済的観点に基づいた、除去案が出力される。そのため、ユーザは、ユーザの置かれた立場に相応しい情報処理システム改善案を、効率良く、選択できる。
すなわち、本実施形態は、第１の実施形態と同様の効果を奏することができる。その理由は、本実施形態に比較部２及び決定部３は、第１の実施形態と同様に動作するためである。
（第３の実施形態）
第２の実施形態では、決定部３は、改善度管理表１０（図９）に基づいて、除去案を、改善度の大きい順に選択した。第３の実施形態では、決定部３は、単位費用当たりの改善度が大きい順に、除去案を選択する。単位費用当たりの改善度の大きい順に除去案を並べると、除去案の順番は、次のようなる。すなわち、除去案は、仮想サーバＶＭ_１の共有リスクを除去する除去案識別子_３、物理サーバＰＳ_１の共有リスクを除去する除去案識別子_１、物理サーバＰＳ_２の共有リスクを除去する除去案識別子_２、という順番になる。決定部３は、この順に表示部１２に除去案を表示する。

決定部３がひとつの除去案を選択する場合には、決定部３は、仮想サーバＶＭ_１の共有リスクを除去する除去案識別子_３を選択する。第２の実施形態と同様に、除去費用上限１１が「１５」に設定されている場合、決定部３は、除去案識別子_３と物理サーバＰＳ_１の共有リスクを除去する除去案識別子_１とを選択する。除去費用上限１１が２７に設定されている場合、決定部３は、すべての除去案を選択する。

本実施形態に基づけば、高いコストパフォーマンスを得る観点で除去案が出力される。そのため、ユーザは、投資額に見合った情報処理システム改善案を、効率よく、選択できる。
すなわち、本実施形態は、第１の実施形態と同様の効果を奏することができる。その理由は、本実施形態に比較部２及び決定部３は、第１の実施形態と同様に動作するためである。

（第４の実施形態）
本発明の第４の実施形態を、図１２を参照して説明する。本発明の第４の実施形態は、図１２に示すリスク管理装置１００である。リスク管理装置１００は、比較部２と決定部３とを含む。比較部２は、情報処理システムに接続する複数の機器のそれぞれについて、これを除去した場合の可用性の改善度を、これら複数の機器の故障率又は復旧率を基に算出する。決定部３は、改善度をそれぞれの機器に関連づけて出力する。
すなわち、本実施形態は、第１の実施形態と同様の効果を奏することができる。その理由は、本実施形態に比較部２及び決定部３は、第１の実施形態と同様に動作するためである。

（変形例）
上述した第１ないし第４の実施形態を例に説明した本発明は、各実施形態の説明において参照した図１０のフローチャートの機能、又は、図２に示したブロック図に示した各部を実現する構成に制限はない。例えば、各実施形態は、図１３に示す情報処理装置１０００を用いて構成されてもよい。情報処理装置１０００は、ＣＰＵ（Central Processing Unit）１１００と、一時記憶メモリ１２００と、記憶装置１３００とを含む。ＣＰＵ１１００は、一般的な情報処理装置である。一時記憶メモリ１２００は、例えば、Ｄ−ＲＡＭ（Dynamic-Random Access Memory）である。記憶装置１３００は、例えば、ハードディスク装置のような不揮発性に情報を保存する装置である。情報処理装置１０００は、上記の機能又は構成を実現可能なプログラムを、一時記憶メモリ１２００又は記憶装置１３００に格納する。そして、ＣＰＵ１１００が、格納されたプログラムを用いて、各実施形態の機能及び構成を実現すればよい。あるいは、情報処理装置１０００は、図示しないコンピュータで読み取り可能な記憶媒体に保存されているプログラムを、図示しない読み取り装置を用いて一時記憶メモリ１２００又は記憶装置１３００に格納し、格納されたプログラム基に動作してもよい。

本変形例に基づき、ユーザは、複数の情報処理システム改善策の中から、最適な改善策を効率よく選択することが可能となる。
すなわち、本変形例は、第１の実施形態と同様の効果を奏することができる。その理由は、本実施形態のＣＰＵ１１００は、プログラムを基に、第１ないし第４の実施形態と同様に動作できるためである。
以上、実施形態を参照して本願発明を説明したが、本願発明は上記実施形態に限定されるものではない。本願発明の構成や詳細には、本願発明のスコープ内で当業者が理解し得る様々な変更をすることができる。
この出願は、２０１４年 ３月２８日に出願された日本出願特願２０１４−０６７３５７を基礎とする優先権を主張し、その開示の全てをここに取り込む。

本発明は、データセンタにおける、情報処理システムの共有リスク要因を低減するための管理に適用することができる。

１ 影響度算出部
２ 比較部
３ 決定部
４ 共有リスク管理表
５ 機器特性管理表
６ サービス特性管理表
７ 影響度管理表
８ 除去案管理表
９ 適用後影響度管理表
１０ 改善度管理表
１１ 除去費用上限
１２ 表示部
１２１ 除去案
１３ 監視部
１４ 監視対象装置
１００ リスク管理装置
２００ 情報処理システム
１０００ 情報処理装置
１１００ ＣＰＵ
１２００ 一時記憶メモリ
１３００ 記憶装置
ＳＶ サービス
ＡＰ アプリケーション
ＶＭ 仮想サーバ
ＰＳ 物理サーバ

Claims (11)

1. 情報処理システムに接続する複数の機器のそれぞれについて、前記機器を除去した場合の可用性の改善度を、前記機器の故障率又は復旧率を基に算出する比較手段と、
   前記改善度を前記機器に関連づけて出力する決定手段と
   を含むリスク管理装置。
2. 前記決定手段は、前記改善度を、大きさ順に出力する
   請求項１に記載のリスク管理装置。
3. 前記比較手段は、前記機器を除去する費用を算出し、
   前記決定手段は、前記改善度を前記費用に関連づけて出力する
   請求項１又は２に記載のリスク管理装置。
4. 前記比較手段は、前記改善度を前記費用で割った単位費用当たりの改善度を算出し、
   前記決定手段は、前記単位費用当たりの改善度を、前記改善度に関連づけて出力する
   請求項３に記載のリスク管理装置。
5. 情報処理システムに接続する複数の機器のそれぞれについて、前記機器を除去した場合の可用性の改善度を、前記機器の故障率又は復旧率を基に算出する比較処理と、
   前記改善度を前記機器に関連づけて出力する決定処理と
   をコンピュータに実行させるリスク管理プログラムを記録する記録媒体。
6. 前記決定処理が、
   前記改善度を大きさ順に出力する
   請求項５に記載のリスク管理プログラムを記録する記録媒体。
7. 前記比較処理が、前記機器を除去する費用を算出しと、
   前記決定処理が、前記改善度を前記費用に関連づけて出力する
   請求項５又は６に記載のリスク管理プログラムを記録する記録媒体。
8. 前記比較処理が、前記改善度を前記費用で割った単位費用当たりの改善度を算出し、
   前記決定処理が、前記費用当たりの改善度を前記改善度に関連づけて出力する
   請求項７に記載のリスク管理プログラムを記録する記録媒体。
9. 情報処理システムに接続する複数の機器のそれぞれについて、前記機器を除去した場合の可用性の改善度を、前記機器の故障率又は復旧率を基に算出し、
   前記改善度を前記機器に関連づけて出力する
   リスク管理方法。
10. 前記改善度を、大きさの順に出力する
    請求項９に記載のリスク管理方法。
11. ユーザが操作する装置から共有リスク要因の除去に関する複数の案の入力を受け付け、当該除去の案をそれぞれ適用した場合の、サービスに与える影響の改善度を比較する比較手段と、
    前記比較の結果に基づき選択された除去案を選択し、出力する決定手段と、
    を含むリスク管理装置。

Images