JP6186817B2 - 情報処理装置、情報処理プログラム及び情報処理方法 - Google Patents

Description

本発明は、仮想システムにおけるリソースの割り当て技術に関する。

ある文献には、管理ポリシーで定めるアプリケーションの優先度に従って、仮想システムにおけるリソースの割り当てを行う技術が開示されている。このように、予め管理ポリシーにおいて優先的に動作させるべきアプリケーションを設定しておくことにより、仮想システムにおいてリソースが不足する状況に陥っても、重要なアプリケーションへのリソースの割り当てを優先させ、不具合を回避することができる。

しかし、仮想システムのリソースが不足する状況は様々であり、アプリケーションの重要性が普遍であるとは限らない。従って、常に同じアプリケーションへのリソースの割り当てを優先させるだけでは、適正なリソースの運用を図れない場合もある。

国際公開第２００８／１３２９２４号パンフレット

本発明の目的は、一側面では、特定事象に応じて全体として適正なリソースの運用を図ることを目的とする。

一態様に係る情報処理装置は、仮想システムにおいて、特定事象に関わるサービスを実現するプログラムの稼動状況が、当該特定事象の予兆を示すパターンに合致するか否かを判定する判定部と、稼動状況がパターンに合致すると判定した場合に、特定事象に応じたルールに従って、仮想システムにおいて稼動している上記プログラム及び他のプログラムに対する仮想システムにおけるリソースの割り当てを変更する変更部とを有する。

一側面としては、特定事象に応じて全体として適正なリソースの運用を図ることができる。

図１は、データセンターのネットワーク構成例を示す図である。 図２は、クラウドユーザの例を示す図である。 図３は、基準データテーブルの例を示す図である。 図４は、通常モードにおける割り当てルールテーブルの例を示す図である。 図５は、通常モードにおけるクラウドシステムの稼動イメージの例を示す図である。 図６は、突発事象の例を示す図である。 図７は、「金融機関のトラブル」発生時における割り当てルールテーブルの例を示す図である。 図８は、「金融機関のトラブル」発生時におけるクラウドシステムの稼動イメージの例を示す図である。 図９は、「金融界の信用不安」発生時における割り当てルールテーブルの例を示す図である。 図１０は、「金融界の信用不安」発生時におけるクラウドシステムの稼動イメージの例を示す図である。 図１１は、「Ｘ地域の交通麻痺」発生時における割り当てルールテーブルの例を示す図である。 図１２は、「Ｘ地域の交通麻痺」発生時におけるクラウドシステムの稼動イメージの例を示す図である。 図１３は、「Ｙ地域の交通麻痺」発生時における割り当てルールテーブルの例を示す図である。 図１４は、「Ｙ地域の交通麻痺」発生時におけるクラウドシステムの稼動イメージの例を示す図である。 図１５は、管理システムのモジュール構成例を示す図である。 図１６は、パターンテーブルの例を示す図である。 図１７は、管理システムによる全体処理フローの例を示す図である。 図１８は、判定処理（Ａ）のフロー例を示す図である。 図１９は、変更処理（Ａ）のフロー例を示す図である。 図２０は、変更処理（Ａ）のフロー例を示す図である。 図２１は、品質保証用の割り当てデータテーブルの例を示す図である。 図２２は、ベストエフォート用の割り当てデータテーブルの例を示す図である。 図２３は、実施の形態２における割り当てルールテーブルの例を示す図である。 図２４は、実施の形態２におけるパターンテーブルの例を示す図である。 図２５は、判定処理（Ｂ）のフロー例を示す図である。 図２６は、実施の形態２における基準データテーブルの例を示す図である。 図２７は、実施の形態２におけるクラウドシステムの稼動イメージの例を示す図である。 図２８は、変更処理（Ｂ）のフロー例を示す図である。 図２９は、変更処理（Ｂ）のフロー例を示す図である。 図３０は、コンピュータの機能ブロック図である。

［実施の形態１］
図１に、データセンターのネットワーク構成例を示す。データセンターは、クラウドサービスを提供する。データセンターでは、複数の物理サーバ１０１がＬＡＮ（Local Area Network）に接続されている。各物理サーバ１０１は、ＦＷ（Firewall）兼ルーター１０３を介してインターネットと通信を行う。

物理サーバ１０１は、ＣＰＵ（Central Processing Unit）及びメモリなどの物理的資源を有している。物理サーバ１０１では、ハイパーバイザの管理の下、仮想サーバ（仮想マシンとも呼ぶ）が動作する。また、仮想サーバ上では、クラウドユーザが利用するアプリケーションプログラムが実行される。

図２に、クラウドユーザの例を示す。この例では、金融業者（以下、金融機関という。）である「Ａ銀行」、「Ｂ銀行」、「Ｃ金庫」及び「Ｄ金庫」と、交通業者である「Ｅ鉄道」、「Ｆ鉄道」、「Ｇバス」及び「Ｈバス」と、流通業者である「Ｉデパート」、「Ｊデパート」、「Ｋストア」及び「Ｌストア」の各ユーザは、各ユーザの端末からデータセンターにアクセスし、各ユーザ向けアプリケーションを利用する。

「Ａ銀行」が利用するサービスを提供するアプリケーションを「Ａ銀行向けアプリケーション」という。以下同様に、「Ｂ銀行」が利用するサービスを提供するアプリケーションを「Ｂ銀行向けアプリケーション」という。「Ｃ金庫」が利用するサービスを提供するアプリケーションを「Ｃ金庫向けアプリケーション」という。「Ｄ金庫」が利用するサービスを提供するアプリケーションを「Ｄ金庫向けアプリケーション」という。「Ｅ鉄道」が利用するサービスを提供するアプリケーションを「Ｅ鉄道向けアプリケーション」という。「Ｆ鉄道」が利用するサービスを提供するアプリケーションを「Ｆ鉄道向けアプリケーション」という。「Ｇバス」が利用するサービスを提供するアプリケーションを「Ｇバス向けアプリケーション」という。「Ｈバス」が利用するサービスを提供するアプリケーションを「Ｈバス向けアプリケーション」という。「Ｉデパート」が利用するサービスを提供するアプリケーションを「Ｉデパート向けアプリケーション」という。「Ｊデパート」が利用するサービスを提供するアプリケーションを「Ｊデパート向けアプリケーション」という。「Ｋストア」が利用するサービスを提供するアプリケーションを「Ｋストア向けアプリケーション」という。「Ｌストア」が利用するサービスを提供するアプリケーションを「Ｌストア向けアプリケーション」という。

例えば、「Ａ銀行向けアプリケーション」、「Ｂ銀行向けアプリケーション」、「Ｃ金庫向けアプリケーション」及び「Ｄ金庫向けアプリケーション」には、「金融取引」のサービスが含まれる。「金融取引」への需要の増加は、金融機関のトラブルや金融界の信用不安などの予兆を示すことがある。

例えば、「Ｅ鉄道向けアプリケーション」、「Ｆ鉄道向けアプリケーション」、「Ｇバス向けアプリケーション」及び「Ｈバス向けアプリケーション」には、特定地域の「運行案内」のサービスが含まれる。特定地域の「運行案内」への需要の増加は、その地域の交通麻痺などの予兆を示すことがある。

この例で、「Ａ銀行」、「Ｃ金庫」、「Ｅ鉄道」、「Ｇバス」、「Ｉデパート」及び「Ｋストア」は、「Ｘ地域」に存在する。また、「Ｂ銀行」、「Ｄ金庫」、「Ｆ鉄道」、「Ｈバス」、「Ｊデパート」及び「Ｌストア」は、「Ｙ地域」に存在する。

次に、各ユーザ向けアプリケーションについての基準データについて説明する。図３に、基準データテーブルの例を示す。基準データは、リソース量の基準及び稼動状況の基準となるデータである。基準データテーブルは、アプリケーションについてのレコードを有している。レコードは、アプリケーション名、ＣＰＵ時間、メモリ使用量、トランザクション量及びネットワーク通信量のフィールドを有している。アプリケーション名のフィールドには、アプリケーションの名前が設定される。ＣＰＵ時間のフィールドには、アプリケーションプログラムにおけるＣＰＵ時間の基準が設定される。メモリ使用量のフィールドには、アプリケーションプログラムにおけるメモリ使用量の基準が設定される。トランザクション量のフィールドには、アプリケーションプログラムにおけるトランザクション量の基準が設定される。ネットワーク通信量のフィールドには、アプリケーションプログラムにおけるネットワーク通信量の基準が設定される。

尚、この例では、演算量に関するパラメータとしてＣＰＵ時間を用いているが、ＣＰＵ時間に代えて、ＣＰＵ数あるいはコア数を用いるようにしてもよい。

基準データは、例えば運用開始時までに設定される。また、基準データは、運用結果に基づいて自動的に学習して最適化されるようにしてもよい。基準データは、ユーザとクラウド事業者との契約に基づいて設定されるようにしてもよい。

第１レコードは、「Ａ銀行向けアプリケーション」についての基準を定めている。図示するように、「Ａ銀行向けアプリケーション」の基準となるＣＰＵ時間は、「Ｓａ（Ｃ）」である。同じく「Ａ銀行向けアプリケーション」の基準となるメモリ使用量は、「Ｓａ（Ｍ）」である。同じく「Ａ銀行向けアプリケーション」の基準となるトランザクション量は、「Ｓａ（Ｔ）」である。同じく「Ａ銀行向けアプリケーション」の基準となるネットワーク通信量は、「Ｓａ（Ｎ）」である。

第２レコードは、「Ｂ銀行向けアプリケーション」についての基準を定めている。図示するように、「Ｂ銀行向けアプリケーション」の基準となるＣＰＵ時間は、「Ｓｂ（Ｃ）」である。同じく「Ｂ銀行向けアプリケーション」の基準となるメモリ使用量は、「Ｓｂ（Ｍ）」である。同じく「Ｂ金庫向けアプリケーション」の基準となるトランザクション量は、「Ｓｂ（Ｔ）」である。同じく「Ｂ銀行向けアプリケーション」の基準となるネットワーク通信量は、「Ｓｂ（Ｎ）」である。

第３レコードは、「Ｃ金庫向けアプリケーション」についての基準を定めている。図示するように、「Ｃ金庫向けアプリケーション」の基準となるＣＰＵ時間は、「Ｓｃ（Ｃ）」である。同じく「Ｃ金庫向けアプリケーション」の基準となるメモリ使用量は、「Ｓｃ（Ｍ）」である。同じく「Ｃ金庫向けアプリケーション」の基準となるトランザクション量は、「Ｓｃ（Ｔ）」である。同じく「Ｃ金庫向けアプリケーション」の基準となるネットワーク通信量は、「Ｓｃ（Ｎ）」である。

第４レコードは、「Ｄ金庫向けアプリケーション」についての基準を定めている。図示するように、「Ｄ金庫向けアプリケーション」の基準となるＣＰＵ時間は、「Ｓｄ（Ｃ）」である。同じく「Ｄ金庫向けアプリケーション」の基準となるメモリ使用量は、「Ｓｄ（Ｍ）」である。同じく「Ｄ金庫向けアプリケーション」の基準となるトランザクション量は、「Ｓｄ（Ｔ）」である。同じく「Ｄ金庫向けアプリケーション」の基準となるネットワーク通信量は、「Ｓｄ（Ｎ）」である。

第５レコードは、「Ｅ鉄道向けアプリケーション」についての基準を定めている。図示するように、「Ｅ鉄道向けアプリケーション」の基準となるＣＰＵ時間は、「Ｓｅ（Ｃ）」である。同じく「Ｅ鉄道向けアプリケーション」の基準となるメモリ使用量は、「Ｓｅ（Ｍ）」である。同じく「Ｅ鉄道向けアプリケーション」の基準となるトランザクション量は、「Ｓｅ（Ｔ）」である。同じく「Ｅ鉄道向けアプリケーション」の基準となるネットワーク通信量は、「Ｓｅ（Ｎ）」である。

第６レコードは、「Ｆ鉄道向けアプリケーション」についての基準を定めている。図示するように、「Ｆ鉄道向けアプリケーション」の基準となるＣＰＵ時間は、「Ｓｆ（Ｃ）」である。同じく「Ｆ鉄道向けアプリケーション」の基準となるメモリ使用量は、「Ｓｆ（Ｍ）」である。同じく「Ｆ鉄道向けアプリケーション」の基準となるトランザクション量は、「Ｓｆ（Ｔ）」である。同じく「Ｆ鉄道向けアプリケーション」の基準となるネットワーク通信量は、「Ｓｆ（Ｎ）」である。

第７レコードは、「Ｇバス向けアプリケーション」についての基準を定めている。図示するように、「Ｇバス向けアプリケーション」の基準となるＣＰＵ時間は、「Ｓｇ（Ｃ）」である。同じく「Ｇバス向けアプリケーション」の基準となるメモリ使用量は、「Ｓｇ（Ｍ）」である。同じく「Ｇバス向けアプリケーション」の基準となるトランザクション量は、「Ｓｇ（Ｔ）」である。同じく「Ｇバス向けアプリケーション」の基準となるネットワーク通信量は、「Ｓｇ（Ｎ）」である。

第８レコードは、「Ｈバス向けアプリケーション」についての基準を定めている。図示するように、「Ｈバス向けアプリケーション」の基準となるＣＰＵ時間は、「Ｓｈ（Ｃ）」である。同じく「Ｈバス向けアプリケーション」の基準となるメモリ使用量は、「Ｓｈ（Ｍ）」である。同じく「Ｈバス向けアプリケーション」の基準となるトランザクション量は、「Ｓｈ（Ｔ）」である。同じく「Ｈバス向けアプリケーション」の基準となるネットワーク通信量は、「Ｓｈ（Ｎ）」である。

第９レコードは、「Ｉデパート向けアプリケーション」についての基準を定めている。図示するように、「Ｉデパート向けアプリケーション」の基準となるＣＰＵ時間は、「Ｓｉ（Ｃ）」である。同じく「Ｉデパート向けアプリケーション」の基準となるメモリ使用量は、「Ｓｉ（Ｍ）」である。同じく「Ｉデパート向けアプリケーション」の基準となるトランザクション量は、「Ｓｉ（Ｔ）」である。同じく「Ｉデパート向けアプリケーション」の基準となるネットワーク通信量は、「Ｓｉ（Ｎ）」である。

第１０レコードは、「Ｊデパート向けアプリケーション」についての基準を定めている。図示するように、「Ｊデパート向けアプリケーション」の基準となるＣＰＵ時間は、「Ｓｊ（Ｃ）」である。同じく「Ｊデパート向けアプリケーション」の基準となるメモリ使用量は、「Ｓｊ（Ｍ）」である。同じく「Ｊデパート向けアプリケーション」の基準となるトランザクション量は、「Ｓｊ（Ｔ）」である。同じく「Ｊデパート向けアプリケーション」の基準となるネットワーク通信量は、「Ｓｊ（Ｎ）」である。

第１１レコードは、「Ｋストア向けアプリケーション」についての基準を定めている。図示するように、「Ｋストア向けアプリケーション」の基準となるＣＰＵ時間は、「Ｓｋ（Ｃ）」である。同じく「Ｋストア向けアプリケーション」の基準となるメモリ使用量は、「Ｓｋ（Ｍ）」である。同じく「Ｋストア向けアプリケーション」の基準となるトランザクション量は、「Ｓｋ（Ｔ）」である。同じく「Ｋストア向けアプリケーション」の基準となるネットワーク通信量は、「Ｓｋ（Ｎ）」である。

第１２レコードは、「Ｌストア向けアプリケーション」についての基準を定めている。図示するように、「Ｌストア向けアプリケーション」の基準となるＣＰＵ時間は、「Ｓｌ（Ｃ）」である。同じく「Ｌストア向けアプリケーション」の基準となるメモリ使用量は、「Ｓｌ（Ｍ）」である。同じく「Ｌストア向けアプリケーション」の基準となるトランザクション量は、「Ｓｌ（Ｔ）」である。同じく「Ｌストア向けアプリケーション」の基準となるネットワーク通信量は、「Ｓｌ（Ｎ）」である。以上で、基準データについての説明を終える。

本実施の形態では、突発事象を予測して、突発事象に応じて全体として適正なリソースの運用を図る。まず、突発事象が生じていない通常モードにおけるリソースの割り当てについて説明する。

図４に、通常モードにおける割り当てルールテーブルの例を示す。割り当てルールテーブルは、ユーザ向けアプリケーションについてのレコードを有している。レコードは、アプリケーション名、保証方式、ＣＰＵ時間及びメモリ使用量のフィールドを有している。アプリケーション名のフィールドには、ユーザ向けアプリケーションの名前が設定される。保証方式のフィールドには、品質保証型とベストエフォート型とのいずれかが設定される。品質保証型では、アプリケーションプログラムに対して所定のリソースを保証する。ベストエフォート型では、アプリケーションプログラムに対して所定のリソースを保証しない。但し、ベストエフォート型で、良好な状態を前提としてリソースを保証するようにしてもよい。割り当てルールテーブルは、ユーザとクラウド事業者との契約に基づいて設定されるようにしてもよい。

ＣＰＵ時間のフィールドには、アプリケーションプログラムに対して保証されるＣＰＵ時間が、基準となるＣＰＵ時間の倍数で設定される。メモリ使用量のフィールドには、アプリケーションプログラムに対して保証されるメモリ使用量が、基準となるメモリ使用量の倍数で設定される。

第１レコードは、「Ａ銀行向けアプリケーション」に対して、ＣＰＵ時間を基準の２倍まで、更にメモリ使用量も基準の２倍まで保証することを示している。

更に、第２レコードに示した「Ｂ銀行向けアプリケーション」、第３レコードに示した「Ｃ金庫向けアプリケーション」、第４レコードに示した「Ｄ金庫向けアプリケーション」、第５レコードに示した「Ｅ鉄道向けアプリケーション」及び第６レコードに示した「Ｆ鉄道向けアプリケーション」も、同様に、ＣＰＵ時間を基準の２倍まで、更にメモリ使用量も基準の２倍まで保証される。

第７レコードは、「Ｇバス向けアプリケーション」が、ベストエフォート型で運用されることを示している。この例で、ベストエフォート型で運用される場合には、ＣＰＵ時間の保証範囲とメモリ使用量の保証範囲を定めていない。ただし、ベストエフォート型で運用される場合にも、良好な状態を前提として、ＣＰＵ時間の保証範囲とメモリ使用量の保証範囲を定めるようにしてもよい。

更に、第８レコードに示した「Ｈバス向けアプリケーション」、第９レコードに示した「Ｉデパート向けアプリケーション」、第１０レコードに示した「Ｊデパート向けアプリケーション」、第１１レコードに示した「Ｋストア向けアプリケーション」及び第１２レコードに示した「Ｌストア向けアプリケーション」も、同様に、ベストエフォート型で運用される。

図５に、通常モードにおけるクラウドシステムの稼動イメージの例を示す。矩形５０１は、物理リソースを模式的に示している。物理リソースは、データセンターが供給するハードウエア（例えば、物理サーバ１０１が保持するＣＰＵあるいはメモリなど）の機能及び能力に相当する。矩形５０１の横幅が、物理リソースの量に相当する。

矩形５０３は、全体リソースプールを模式的に示している。全体リソースプールは、物理リソースのうち、仮想サーバに割り当てられるリソースを一元的に管理する。矩形５０３の横幅が、リソースプールが保持するリソースの量に相当する。

矩形５０５は、管理システムを模式的に示している。管理システムは、仮想サーバ群を管理する装置である。この例では、管理システムも仮想マシン上で実現される。従って、管理システムも物理リソースの一部を利用している。矩形５０５の横幅が、管理システムが利用するリソースの量に相当する。

矩形５０７は、休止リソースを模式的に示している。休止リソースは、物理リソースのうち、リソースプールにも管理システムにも割り当てられていないリソースである。矩形５０７の横幅が、休止リソースの量に相当する。

本実施の形態では、全体リソースプールを、品質保証用リソースプールとベストエフォート用リソースプールとに分けて運用する。品質保証用リソースプールから提供されるリソースと、ベストエフォート用リソースプールから提供されるリソースとは重複しない。つまり、品質保証用リソースプールを介して、ベストエフォート用リソースプールが管理するリソースが提供されることはない。また、ベストエフォート用リソースプールを介して、品質保証用リソースプールが管理するリソースが提供されることはない。

矩形５０９は、品質保証用リソースプールを模式的に示している。品質保証用リソースプールは、品質保証用仮想サーバにリソースを提供する。品質保証用仮想サーバは、品質保証型のアプリケーションプログラムを動作させるための仮想サーバである。品質保証用仮想サーバ上で、ベストエフォート型のアプリケーションプログラムが動作することはない。

品質保証型のアプリケーションプログラムに対して保証されるリソースは、品質保証用リソースプールで確保される。例えば、品質保証型のアプリケーションプログラムは、当該アプリケーションプログラムに対して保証されるリソースを占有する品質保証用仮想サーバ上で実行される。

矩形５２１は、「Ａ銀行向けアプリケーション」が用いるリソース量の基準を模式的に示している。矩形５２１の横幅が、「Ａ銀行向けアプリケーション」が用いるリソース量の基準Ｓａに相当する。この図において、リソースの種類は特定していない。基準Ｓａは、例えば図３に示したＣＰＵ時間の基準Ｓａ（Ｃ）及びメモリ使用量の基準Ｓａ（Ｍ）を包括するイメージである。

破線の範囲５２３は、「Ａ銀行向けアプリケーション」に対して保証されるリソース量の基準を模式的に示している。破線の範囲５２３の横幅が、「Ａ銀行向けアプリケーション」に対して保証されるリソース量に相当する。この例では、基準Ｓａの２倍のリソース量が保証されている。保証されるリソース量は、図４に示した通常モードにおける「Ａ銀行向けアプリケーション」の割り当てルールに基づいて求められる。

保証されるリソース量は、「Ａ銀行向けアプリケーション」で占有されるようにする。例えば、「Ａ銀行向けアプリケーション」のために、基準Ｓａ（Ｃ）の２倍に相当するＣＰＵ時間が確保され、基準Ｓａ（Ｍ）の２倍に相当するメモリ使用量が確保される。

矩形５２５は、「Ｂ銀行向けアプリケーション」が用いるリソース量の基準を模式的に示している。矩形５２５の横幅が、「Ｂ銀行向けアプリケーション」が用いるリソース量の基準Ｓｂに相当する。前述と同様に、リソースの種類は特定していない。基準Ｓｂは、例えば図３に示したＣＰＵ時間の基準Ｓｂ（Ｃ）及びメモリ使用量の基準Ｓｂ（Ｍ）を包括するイメージである。

破線の範囲５２７は、「Ｂ銀行向けアプリケーション」に対して保証されるリソース量の基準を模式的に示している。破線の範囲５２７の横幅が、「Ｂ銀行向けアプリケーション」に対して保証されるリソース量に相当する。この例では、基準Ｓｂの２倍のリソース量が保証されている。保証されるリソース量は、図４に示した通常モードにおける「Ｂ銀行向けアプリケーション」の割り当てルールに基づいて求められる。

保証されるリソース量は、「Ｂ銀行向けアプリケーション」で占有されるようにする。例えば、「Ｂ銀行向けアプリケーション」のために、基準Ｓｂ（Ｃ）の２倍に相当するＣＰＵ時間が確保され、基準Ｓｂ（Ｍ）の２倍に相当するメモリ使用量が確保される。

矩形５２９は、「Ｃ金庫向けアプリケーション」が用いるリソース量の基準を模式的に示している。矩形５２９の横幅が、「Ｃ金庫向けアプリケーション」が用いるリソース量の基準Ｓｃに相当する。前述と同様に、リソースの種類は特定していない。基準Ｓｃは、例えば図３に示したＣＰＵ時間の基準Ｓｃ（Ｃ）及びメモリ使用量の基準Ｓｃ（Ｍ）を包括するイメージである。

破線の範囲５３１は、「Ｃ金庫向けアプリケーション」に対して保証されるリソース量の基準を模式的に示している。破線の範囲５３１の横幅が、「Ｃ金庫向けアプリケーション」に対して保証されるリソース量に相当する。この例では、基準Ｓｃの２倍のリソース量が保証されている。保証されるリソース量は、図４に示した通常モードにおける「Ｃ金庫向けアプリケーション」の割り当てルールに基づいて求められる。

保証されるリソース量は、「Ｃ金庫向けアプリケーション」で占有されるようにする。例えば、「Ｃ金庫向けアプリケーション」のために、基準Ｓｃ（Ｃ）の２倍に相当するＣＰＵ時間が確保され、基準Ｓｃ（Ｍ）の２倍に相当するメモリ使用量が確保される。

矩形５３３は、「Ｄ金庫向けアプリケーション」が用いるリソース量の基準を模式的に示している。矩形５３３の横幅が、「Ｄ金庫向けアプリケーション」が用いるリソース量の基準Ｓｄに相当する。前述と同様に、リソースの種類は特定していない。基準Ｓｄは、例えば図３に示したＣＰＵ時間の基準Ｓｄ（Ｃ）及びメモリ使用量の基準Ｓｄ（Ｍ）を包括するイメージである。

破線の範囲５３５は、「Ｄ金庫向けアプリケーション」に対して保証されるリソース量の基準を模式的に示している。破線の範囲５３５の横幅が、「Ｄ金庫向けアプリケーション」に対して保証されるリソース量に相当する。この例では、基準Ｓｄの２倍のリソース量が保証されている。保証されるリソース量は、図４に示した通常モードにおける「Ｄ金庫向けアプリケーション」の割り当てルールに基づいて求められる。

保証されるリソース量は、「Ｄ金庫向けアプリケーション」で占有されるようにする。例えば、「Ｄ金庫向けアプリケーション」のために、基準Ｓｄ（Ｃ）の２倍に相当するＣＰＵ時間が確保され、基準Ｓｄ（Ｍ）の２倍に相当するメモリ使用量が確保される。

矩形５３７は、「Ｅ鉄道向けアプリケーション」が用いるリソース量の基準を模式的に示している。矩形５３７の横幅が、「Ｅ鉄道向けアプリケーション」が用いるリソース量の基準Ｓｅに相当する。前述と同様に、リソースの種類は特定していない。基準Ｓｅは、例えば図３に示したＣＰＵ時間の基準Ｓｅ（Ｃ）及びメモリ使用量の基準Ｓｅ（Ｍ）を包括するイメージである。

破線の範囲５３９は、「Ｅ鉄道向けアプリケーション」に対して保証されるリソース量の基準を模式的に示している。破線の範囲５３９の横幅が、「Ｅ鉄道向けアプリケーション」に対して保証されるリソース量に相当する。この例では、基準Ｓｅの２倍のリソース量が保証されている。保証されるリソース量は、図４に示した通常モードにおける「Ｅ鉄道向けアプリケーション」の割り当てルールに基づいて求められる。

保証されるリソース量は、「Ｅ鉄道向けアプリケーション」で占有されるようにする。例えば、「Ｅ鉄道向けアプリケーション」のために、基準Ｓｅ（Ｃ）の２倍に相当するＣＰＵ時間が確保され、基準Ｓｅ（Ｍ）の２倍に相当するメモリ使用量が確保される。

矩形５４１は、「Ｆ鉄道向けアプリケーション」が用いるリソース量の基準を模式的に示している。矩形５４１の横幅が、「Ｆ鉄道向けアプリケーション」が用いるリソース量の基準Ｓｆに相当する。前述と同様に、リソースの種類は特定していない。基準Ｓｆは、例えば図３に示したＣＰＵ時間の基準Ｓｆ（Ｃ）及びメモリ使用量の基準Ｓｆ（Ｍ）を包括するイメージである。

破線の範囲５４３は、「Ｆ鉄道向けアプリケーション」に対して保証されるリソース量の基準を模式的に示している。破線の範囲５４３の横幅が、「Ｆ鉄道向けアプリケーション」に対して保証されるリソース量に相当する。この例では、基準Ｓｆの２倍のリソース量が保証されている。保証されるリソース量は、図４に示した通常モードにおける「Ｆ鉄道向けアプリケーション」の割り当てルールに基づいて求められる。

保証されるリソース量は、「Ｆ鉄道向けアプリケーション」で占有されるようにする。例えば、「Ｆ鉄道向けアプリケーション」のために、基準Ｓｆ（Ｃ）の２倍に相当するＣＰＵ時間が確保され、基準Ｓｆ（Ｍ）の２倍に相当するメモリ使用量が確保される。

以上のように、品質保証用リソースプールは、破線の範囲５２３で示した「Ａ銀行向けアプリケーション」に対して保証されるリソース量、破線の範囲５２７で示した「Ｂ銀行向けアプリケーション」に対して保証されるリソース量、破線の範囲５３１で示した「Ｃ金庫向けアプリケーション」に対して保証されるリソース量、破線の範囲５３５で示した「Ｄ金庫向けアプリケーション」に対して保証されるリソース量、破線の範囲５３９で示した「Ｅ鉄道向けアプリケーション」に対して保証されるリソース量及び破線の範囲５４３で示した「Ｆ鉄道向けアプリケーション」に対して保証されるリソース量の合計に相当するリソースを確保している。

一方、矩形５１１は、ベストエフォート用リソースプールを模式的に示している。ベストエフォート用リソースプールは、ベストエフォート用仮想サーバにリソースを提供する。ベストエフォート用仮想サーバは、ベストエフォート型のアプリケーションプログラムを動作させるための仮想サーバである。但し、仮に品質保証型のアプリケーションプログラムのためのリソースが不足する場合には、ベストエフォート用リソースプールのリソースが品質保証型のアプリケーションプログラムに割り当てられることがある。例えば、品質保証型のアプリケーションプログラムの一部を、ベストエフォート用仮想サーバ上で動作させることもある。

矩形５５１は、「Ｇバス向けアプリケーション」が用いるリソース量の基準を模式的に示している。矩形５５１の横幅が、「Ｇバス向けアプリケーション」が用いるリソース量の基準Ｓｇに相当する。前述と同様に、リソースの種類は特定していない。基準Ｓｇは、例えば図３に示したＣＰＵ時間の基準Ｓｇ（Ｃ）及びメモリ使用量の基準Ｓｇ（Ｍ）を包括するイメージである。

「Ｇバス向けアプリケーション」は、ベストエフォート型であるので、保証に対応するリソース量を確保していない。但し、「Ｇバス向けアプリケーション」に対して所定のリソース量を予備的に確保するようにしてもよい。

矩形５５３は、「Ｈバス向けアプリケーション」が用いるリソース量の基準を模式的に示している。矩形５５３の横幅が、「Ｈバス向けアプリケーション」が用いるリソース量の基準Ｓｈに相当する。前述と同様に、リソースの種類は特定していない。基準Ｓｈは、例えば図３に示したＣＰＵ時間の基準Ｓｈ（Ｃ）及びメモリ使用量の基準Ｓｈ（Ｍ）を包括するイメージである。

「Ｈバス向けアプリケーション」は、ベストエフォート型であるので、保証に対応するリソース量を確保していない。前述と同様に、「Ｈバス向けアプリケーション」に対して所定のリソース量を予備的に確保するようにしてもよい。

矩形５５５は、「Ｉデパート向けアプリケーション」が用いるリソース量の基準を模式的に示している。矩形５５５の横幅が、「Ｉデパート向けアプリケーション」が用いるリソース量の基準Ｓｉに相当する。前述と同様に、リソースの種類は特定していない。基準Ｓｉは、例えば図３に示したＣＰＵ時間の基準Ｓｉ（Ｃ）及びメモリ使用量の基準Ｓｉ（Ｍ）を包括するイメージである。

「Ｉデパート向けアプリケーション」は、ベストエフォート型であるので、保証に対応するリソース量を確保していない。前述と同様に、「Ｉデパート向けアプリケーション」に対して所定のリソース量を予備的に確保するようにしてもよい。

矩形５５７は、「Ｊデパート向けアプリケーション」が用いるリソース量の基準を模式的に示している。矩形５５７の横幅が、「Ｊデパート向けアプリケーション」が用いるリソース量の基準Ｓｊに相当する。前述と同様に、リソースの種類は特定していない。基準Ｓｊは、例えば図３に示したＣＰＵ時間の基準Ｓｊ（Ｃ）及びメモリ使用量の基準Ｓｊ（Ｍ）を包括するイメージである。

「Ｊデパート向けアプリケーション」は、ベストエフォート型であるので、保証に対応するリソース量を確保していない。前述と同様に、「Ｊデパート向けアプリケーション」に対して所定のリソース量を予備的に確保するようにしてもよい。

矩形５５９は、「Ｋストア向けアプリケーション」が用いるリソース量の基準を模式的に示している。矩形５５９の横幅が、「Ｋストア向けアプリケーション」が用いるリソース量の基準Ｓｋに相当する。前述と同様に、リソースの種類は特定していない。基準Ｓｋは、例えば図３に示したＣＰＵ時間の基準Ｓｋ（Ｃ）及びメモリ使用量の基準Ｓｋ（Ｍ）を包括するイメージである。

「Ｋストア向けアプリケーション」は、ベストエフォート型であるので、保証に対応するリソース量を確保していない。前述と同様に、「Ｋストア向けアプリケーション」に対して所定のリソース量を予備的に確保するようにしてもよい。

矩形５６１は、「Ｌストア向けアプリケーション」が用いるリソース量の基準を模式的に示している。矩形５６１の横幅が、「Ｌストア向けアプリケーション」が用いるリソース量の基準Ｓｌに相当する。前述と同様に、リソースの種類は特定していない。基準Ｓｌは、例えば図３に示したＣＰＵ時間の基準Ｓｌ（Ｃ）及びメモリ使用量の基準Ｓｌ（Ｍ）を包括するイメージである。

「Ｌストア向けアプリケーション」は、ベストエフォート型であるので、保証に対応するリソース量を確保していない。前述と同様に、「Ｌストア向けアプリケーション」に対して所定のリソース量を予備的に確保するようにしてもよい。

以上のように、品質保証用リソースプールは、矩形５５１で示した「Ｇバス向けアプリケーション」の基準相当のリソース量、矩形５５３で示した「Ｈバス向けアプリケーション」の基準相当のリソース量、矩形５５５で示した「Ｉデパート向けアプリケーション」の基準相当のリソース量、矩形５５７で示した「Ｊデパート向けアプリケーション」の基準相当のリソース量、矩形５５９で示した「Ｋストア向けアプリケーション」の基準相当のリソース量及び矩形５６１で示した「Ｌストア向けアプリケーション」の基準相当のリソース量の合計と予備に相当するリソースとを確保している。以上で、通常モードについての説明を終える。

続いて、突発事象の例について説明する。図６に、突発事象の例を示す。この例では、「金融機関のトラブル」、「金融界の信用不安」、「Ｘ地域の交通麻痺」及び「Ｙ地域の交通麻痺」の４つの突発事象を想定する。

この例で、「金融機関のトラブル」は、特定の金融機関における一部機能（例えば、ＡＴＭ機能）の障害が発生している状態を指している。この例によれば、「Ａ銀行のトラブル」、「Ｂ銀行のトラブル」、「Ｃ金庫のトラブル」及び「Ｄ金庫のトラブル」の４つの態様が起こり得る。但し、「金融機関のトラブル」は、他の金融機関及び他の事業者（例えば、交通業者や流通業者）の活動への影響は限定的である。

この例で、「金融界の信用不安」は、経済状況の悪化などにより、広く金融機関への信用度が低下している状態を指す。「金融界の信用不安」は、金融機関の全般に影響を及ぼし、預金の引き出しなど多くの取引を生じさせる。この例で「金融界の信用不安」となった場合には、「Ａ銀行」、「Ｂ銀行」、「Ｃ金庫」及び「Ｄ金庫」における取引の増加が予想される。但し、他の事業者（例えば、交通業者や流通業者）の活動への影響は限定的である。

この例で、「Ｘ地域の交通麻痺」は、「Ｘ地域」の悪天候や事故などにより、「Ｘ地域」における交通の一部が停止している状態を指す。「Ｘ地域の交通麻痺」は、「Ｘ地域」の交通業者である「Ｅ鉄道」と「Ｇバス」の活動に大きな影響を及ぼす。但し、「Ｘ地域の交通麻痺」は、「Ｘ地域」の他の事業者（「Ａ銀行」、「Ｃ金庫」、「Ｉデパート」及び「Ｋストア」）の活動への影響は限定的である。

この例で、「Ｙ地域の交通麻痺」は、「Ｙ地域」の悪天候や事故などにより、「Ｙ地域」における交通の一部が停止している状態を指す。「Ｙ地域の交通麻痺」は、「Ｙ地域」の交通業者である「Ｆ鉄道」と「Ｈバス」の活動に大きな影響を及ぼす。但し、「Ｙ地域の交通麻痺」は、「Ｙ地域」の他の事業者（「Ｂ銀行」、「Ｄ金庫」、「Ｊデパート」及び「Ｌストア」）の活動への影響は限定的である。

図６の矢印で示したように、「通常モード」から「金融機関のトラブル」のモードに遷移することが想定される。更に、「通常モード」から「金融界の信用不安」のモードに遷移することも想定される。「通常モード」から「Ｘ地域の交通麻痺」のモードに遷移することも想定される。更に、「通常モード」から「Ｙ地域の交通麻痺」のモードに遷移することも想定される。

以下、各突発事象に応じたリソースの運用について説明する。まず、「金融機関のトラブル」に応じたリソースの運用について説明する。図７に、「金融機関のトラブル」発生時における割り当てルールテーブルの例を示す。図７は、図４と同様に、テーブル形式で割り当てルールを示す。テーブルの構成は、図４と同様である。突発事象に対応する割り当てルールテーブルは、ユーザとクラウド事業者との契約に基づいて設定されるようにしてもよい。

第１レコードは、「Ａ銀行向けアプリケーション」に対して、ＣＰＵ時間を基準の４倍まで、更にメモリ使用量も基準の４倍まで保証されることを示している。この保証範囲は、通常モードにおける保証範囲の２倍に相当する。

第２レコードに示した「Ｂ銀行向けアプリケーション」、第３レコードに示した「Ｃ金庫向けアプリケーション」、第４レコードに示した「Ｄ金庫向けアプリケーション」、第５レコードに示した「Ｅ鉄道向けアプリケーション」及び第６レコードに示した「Ｆ鉄道向けアプリケーション」も、図４に示した通常モードと同様に、ＣＰＵ時間を基準の２倍まで、更にメモリ使用量も基準の２倍まで保証される。

第７レコードに示した「Ｇバス向けアプリケーション」、第８レコードに示した「Ｈバス向けアプリケーション」、第９レコードに示した「Ｉデパート向けアプリケーション」、第１０レコードに示した「Ｊデパート向けアプリケーション」、第１１レコードに示した「Ｋストア向けアプリケーション」及び第１２レコードに示した「Ｌストア向けアプリケーション」も、通常モードと同様に、ベストエフォート型で運用される。

図８に、「金融機関のトラブル」発生時におけるクラウドシステムの稼動イメージの例を示す。矩形５０１に示した物理リソース及び矩形５０５に示した管理システムについては、図５と同様である。

図５に示した通常モードにおけるクラウドシステムの稼動イメージと比較すると、破線の範囲８２５に示した「Ａ銀行向けアプリケーション」に対して保証されるリソース量が２倍に増えている。矢印８２３は、予兆に相当するリソース量の増加のイメージを示している。

破線の範囲８２９に示した「Ｂ銀行向けアプリケーション」に対して保証されるリソース量は、図５における破線の範囲５２７に示した通常モードにおけるリソース量と同等である。以下同様に、破線の範囲８３３に示した「Ｃ金庫向けアプリケーション」に対して保証されるリソース量は、図５における破線の範囲５３１に示した通常モードにおけるリソース量と同等である。破線の範囲８３７に示した「Ｄ金庫向けアプリケーション」に対して保証されるリソース量は、図５における破線の範囲５３５に示した通常モードにおけるリソース量と同等である。破線の範囲８４１に示した「Ｅ鉄道向けアプリケーション」に対して保証されるリソース量は、図５における破線の範囲５３９に示した通常モードにおけるリソース量と同等である。更に、破線の範囲８４５に示した「Ｆ鉄道向けアプリケーション」に対して保証されるリソース量は、図５における破線の範囲５４３に示した通常モードにおけるリソース量と同等である。

尚、矩形８２１に示した「Ａ銀行向けアプリケーション」が用いるリソース量は、基準Ｓａに相当するので、図５における矩形５２１に示した通常モードにおけるリソース量と変わらない。以下同様に、矩形８２７に示した「Ｂ銀行向けアプリケーション」が用いるリソース量は、基準Ｓｂに相当するので、図５における矩形５２５に示した通常モードにおけるリソース量と変わらない。矩形８３１に示した「Ｃ金庫向けアプリケーション」が用いるリソース量は、基準Ｓｃに相当するので、図５における矩形５２９に示した通常モードにおけるリソース量と変わらない。矩形８３５に示した「Ｄ金庫向けアプリケーション」が用いるリソース量は、基準Ｓｄに相当するので、図５における矩形５３３に示した通常モードにおけるリソース量と変わらない。矩形８３９に示した「Ｅ鉄道向けアプリケーション」が用いるリソース量は、基準Ｓｅに相当するので、図５における矩形５３７に示した通常モードにおけるリソース量と変わらない。更に、矩形８４３に示した「Ｆ鉄道向けアプリケーション」が用いるリソース量は、基準Ｓｆに相当するので、図５における矩形５４１に示した通常モードにおけるリソース量と変わらない。

破線の範囲８２５に示した「Ａ銀行向けアプリケーション」に対して保証されるリソース量が増えた分、矩形８０９に示した品質保証用リソースプールにおけるリソースの量が増えている。

また、矩形８５１に示した「Ｇバス向けアプリケーション」が用いるリソース量は、基準Ｓｇに相当するので、図５における矩形５５１に示した通常モードにおけるリソース量と変わらない。以下同様に、矩形８５３に示した「Ｈバス向けアプリケーション」が用いるリソース量は、基準Ｓｈに相当するので、図５における矩形５５３に示した通常モードにおけるリソース量と変わらない。矩形８５５に示した「Ｉデパート向けアプリケーション」が用いるリソース量は、基準Ｓｉに相当するので、図５における矩形５５５に示した通常モードにおけるリソース量と変わらない。矩形８５７に示した「Ｊデパート向けアプリケーション」が用いるリソース量は、基準Ｓｊに相当するので、図５における矩形５５７に示した通常モードにおけるリソース量と変わらない。矩形８５９に示した「Ｋストア向けアプリケーション」が用いるリソース量は、基準Ｓｋに相当するので、図５における矩形５５９に示した通常モードにおけるリソース量と変わらない。更に、矩形８６１に示した「Ｌストア向けアプリケーション」が用いるリソース量は、基準Ｓｌに相当するので、図５における矩形５６１に示した通常モードにおけるリソース量と変わらない。

従って、矩形８１１に示したベストエフォート用リソースプールにおけるリソースの量は、図５における矩形５１１に示した通常モードにおけるリソース量と変わらない。

矩形８０３に示した全体リソースプールにおけるリソースの量は、破線の範囲８２５に示した「Ａ銀行向けアプリケーション」に対して保証されるリソース量が増えた分だけ増えている。また、矩形８０７に示した休止リソースは、同じ分だけ減っている。

このように、「金融機関のトラブル」発生時には、いずれのアプリケーションプログラムも除外されることなく、実行状態を継続させる。以上で、「金融機関のトラブル」に応じたリソースの運用についての説明を終える。

続いて、「金融界の信用不安」に応じたリソースの運用について説明する。図９に、「金融界の信用不安」発生時における割り当てルールテーブルの例を示す。テーブルの構成は、図４及び図７と同様である。

第１レコードは、図７に示した「金融機関のトラブル」の場合と同様に「Ａ銀行向けアプリケーション」に対して、ＣＰＵ時間が基準の４倍まで、更にメモリ使用量も基準の４倍まで保証されることを示している。この保証範囲は、通常モードにおける保証範囲の２倍に相当する。

「金融界の信用不安」の場合は、他の金融機関における保証範囲も拡大する。第２レコードは、「Ｂ銀行向けアプリケーション」に対して、ＣＰＵ時間が基準の４倍まで、更にメモリ使用量も基準の４倍まで保証されることを示している。この保証範囲は、通常モードにおける保証範囲の２倍に相当する。以下同様に、第３レコードは、「Ｃ金庫向けアプリケーション」に対して、ＣＰＵ時間が基準の４倍まで、更にメモリ使用量も基準の４倍まで保証されることを示している。この保証範囲は、通常モードにおける保証範囲の２倍に相当する。第４レコードは、「Ｄ金庫向けアプリケーション」に対して、ＣＰＵ時間が基準の４倍まで、更にメモリ使用量も基準の４倍まで保証されることを示している。この保証範囲は、通常モードにおける保証範囲の２倍に相当する。

この例で、「Ｅ鉄道」及び「Ｆ鉄道」は、「金融界の信用不安」に応じて自身のアプリケーションプログラムをベストエフォートに切り替えることに同意している。そのため、第５レコードに示した「Ｅ鉄道向けアプリケーション」及び、第６レコードに示した「Ｆ鉄道向けアプリケーション」は、ベストエフォート型で運用される。

第７レコードに示した「Ｇバス向けアプリケーション」、第８レコードに示した「Ｈバス向けアプリケーション」、第９レコードに示した「Ｉデパート向けアプリケーション」、第１０レコードに示した「Ｊデパート向けアプリケーション」、第１１レコードに示した「Ｋストア向けアプリケーション」及び第１２レコードに示した「Ｌストア向けアプリケーション」も、通常モードと同様に、ベストエフォート型で運用される。

図１０に、「金融界の信用不安」発生時におけるクラウドシステムの稼動イメージの例を示す。矩形５０１に示した物理リソース及び矩形５０５に示した管理システムについては、図５及び図８と同様である。

図５に示した通常モードにおけるクラウドシステムの稼動イメージと比較すると、破線の範囲１０２５に示した「Ａ銀行向けアプリケーション」に対して保証されるリソース量が２倍に増えている。矢印１０２３は、予兆に相当するリソース量の増加のイメージを示している。以下同様に、破線の範囲１０３１に示した「Ｂ銀行向けアプリケーション」に対して保証されるリソース量が２倍に増えている。矢印１０２９は、予兆に相当するリソース量の増加のイメージを示している。破線の範囲１０３７に示した「Ｃ金庫向けアプリケーション」に対して保証されるリソース量が２倍に増えている。矢印１０３５は、予兆に相当するリソース量の増加のイメージを示している。破線の範囲１０４３に示した「Ｄ金庫向けアプリケーション」に対して保証されるリソース量が２倍に増えている。矢印１０３９は、予兆に相当しないリソース量の増加のイメージを示している。この時点で「Ｄ金庫向けアプリケーション」には、予兆が現れていない。但し、判定対象のアプリケーションのうち所定の割合で予兆が現れている場合には、「金融界の信用不安」が生じる恐れがあると判断され、予兆が現れていないアプリケーションに対するリソースも拡充される。

図８と同様に、矩形１０２１に示した「Ａ銀行向けアプリケーション」が用いるリソースは、図５における矩形５２１に示した通常モードにおけるリソース量と変わらない。以下同様に、矩形１０２７に示した「Ｂ銀行向けアプリケーション」が用いるリソース量は、図５における矩形５２５に示した通常モードにおけるリソース量と変わらない。矩形１０３３に示した「Ｃ金庫向けアプリケーション」が用いるリソース量は、図５における矩形５２９に示した通常モードにおけるリソース量と変わらない。更に、矩形１０３９に示した「Ｄ金庫向けアプリケーション」が用いるリソース量は、図５における矩形５３３に示した通常モードにおけるリソース量と変わらない。

「Ｅ鉄道向けアプリケーション」は、品質保証用リソースプールからベストエフォート用リソースプールへ移っている。矩形１０５１に示した「Ｅ鉄道向けアプリケーション」が用いるリソース量は、基準Ｓｅに相当する。矩形１０５３に示した「Ｆ鉄道向けアプリケーション」が用いるリソース量は、基準Ｓｆに相当する。

矩形１０５５に示した「Ｇバス向けアプリケーション」が用いるリソース量は、基準Ｓｇに相当するので、図５における矩形５５１に示した通常モードにおけるリソース量と変わらない。以下同様に、矩形１０５７に示した「Ｈバス向けアプリケーション」が用いるリソース量は、基準Ｓｈに相当するので、図５における矩形５５３に示した通常モードにおけるリソース量と変わらない。矩形１０５９に示した「Ｉデパート向けアプリケーション」が用いるリソース量は、基準Ｓｉに相当するので、図５における矩形５５５に示した通常モードにおけるリソース量と変わらない。矩形１０６１に示した「Ｊデパート向けアプリケーション」が用いるリソース量は、基準Ｓｊに相当するので、図５における矩形５５７に示した通常モードにおけるリソース量と変わらない。

ベストエフォート用リソースプールには、矩形１０５１に示した「Ｅ鉄道向けアプリケーション」、矩形１０５３に示した「Ｆ鉄道向けアプリケーション」、矩形１０５５に示した「Ｇバス向けアプリケーション」、矩形１０５７に示した「Ｈバス向けアプリケーション」、矩形１０５９に示した「Ｉデパート向けアプリケーション」及び矩形１０６１に示した「Ｊデパート向けアプリケーション」に提供するリソース以外に残余のリソースがないので、「Ｋストア向けアプリケーション」及び「Ｌストア向けアプリケーション」は、除外されている。尚、「Ｋストア向けアプリケーション」及び「Ｌストア向けアプリケーション」は、一旦保留され、リソースに余裕が生じた時点で、ベストエフォート用リソースプールのリソースを用いて復帰する。以上で、「金融界の信用不安」に応じたリソースの運用についての説明を終える。

続いて、「Ｘ地域の交通麻痺」に応じたリソースの運用について説明する。図１１に、「Ｘ地域の交通麻痺」発生時における割り当てルールテーブルの例を示す。テーブルの構成は、図４、図７及び図９と同様である。

第１レコードに示した「Ａ銀行向けアプリケーション」、第２レコードに示した「Ｂ銀行向けアプリケーション」、第３レコードに示した「Ｃ金庫向けアプリケーション」及び第４レコードに示した「Ｄ金庫向けアプリケーション」に対して、図４に示した通常モードと同様に、ＣＰＵ時間が基準の２倍まで、更にメモリ使用量も基準の２倍まで保証される。

第５レコードと第７レコードとは、「Ｘ地域」の交通業サービスである「Ｅ鉄道向けアプリケーション」及び「Ｇバス向けアプリケーション」に対して、ＣＰＵ時間が基準の６倍まで、更にメモリ使用量も基準の６倍まで保証されることを示している。

第６レコードと第８レコードとに示したように、「Ｘ地域」以外の交通業サービスである「Ｆ鉄道向けアプリケーション」及び「Ｈバス向けアプリケーション」は、ベストエフォート型で運用される。

第９レコードに示した「Ｉデパート向けアプリケーション」、第１０レコードに示した「Ｊデパート向けアプリケーション」、第１１レコードに示した「Ｋストア向けアプリケーション」及び第１２レコードに示した「Ｌストア向けアプリケーション」も、通常モードと同様に、ベストエフォート型で運用される。

図１２に、「Ｘ地域の交通麻痺」発生時におけるクラウドシステムの稼動イメージの例を示す。矩形５０１に示した物理リソース及び矩形５０５に示した管理システムについては、図５、図８及び図１０と同様である。

矩形１２２１及び破線の範囲１２２３に示した「Ａ銀行向けアプリケーション」についてのリソース量については、図５の矩形５２１及び破線の範囲５２３に示した通常モードにおける「Ａ銀行向けアプリケーション」のリソース量と同様である。以下同様に、矩形１２２５及び破線の範囲１２２７に示した「Ｂ銀行向けアプリケーション」についてのリソース量については、図５の矩形５２５及び破線の範囲５２７に示した通常モードにおける「Ｂ銀行向けアプリケーション」のリソース量と同様である。矩形１２２９及び破線の範囲１２３１に示した「Ｃ金庫向けアプリケーション」についてのリソース量については、図５の矩形５２９及び破線の範囲５３１に示した通常モードにおける「Ｃ金庫向けアプリケーション」のリソース量と同様である。矩形１２３３及び破線の範囲１２３５に示した「Ｄ金庫向けアプリケーション」についてのリソース量については、図５の矩形５３３及び破線の範囲５３５に示した通常モードにおける「Ｄ金庫向けアプリケーション」のリソース量と同様である。

破線の範囲１２４１に示した「Ｅ鉄道向けアプリケーション」に対して保証されるリソース量が３倍に増えている。矢印１２３９は、予兆に相当するリソース量の増加のイメージを示している。更に、破線の範囲１２４７に示した「Ｇバス向けアプリケーション」に対して保証されるリソース量が３倍に増えている。矢印１２４５は、予兆に相当しないリソース量の増加のイメージを示している。この時点で「Ｇバス向けアプリケーション」には、予兆が現れていない。但し、判定対象のアプリケーションのうち所定の割合で予兆が現れている場合には、「Ｘ地域の交通麻痺」が生じる恐れがあると判断され、予兆が現れていないアプリケーションに対するリソースも拡充される。

矩形１２０９に示した品質保証用リソースプールは、破線の範囲１２４１に示した「Ｅ鉄道向けアプリケーション」に対して保証されるリソース量が増えた分、リソースの量が増えている。また、同じく品質保証用リソースプールは、図５の矩形５４１と破線の範囲５４３に示した「Ｆ鉄道向けアプリケーション」に対して保証されるリソース量が減った分、リソースの量が減っている。更に、同じく品質保証用リソースプールは、矩形１２４３と破線の範囲１２４７に示した「Ｇバス向けアプリケーション」に対して保証されるリソース量が増えた分、リソースの量が増えている。

矩形１２５１に示した「Ｆ鉄道向けアプリケーション」が用いるリソース量は、基準Ｓｆに相当する。矩形１２５３に示した「Ｈバス向けアプリケーション」が用いるリソース量は、基準Ｓｈに相当するので、図５における矩形５５３に示した通常モードにおけるリソース量と変わらない。

図５の矩形５０７に示した休止リソースも全体リソースプールに組み込んでいるが、矩形１２０９に示した品質保証用リソースプールが大幅に増えているので、破線の範囲１２１１に示したベストエフォート用リソースプールが適用するリソースは少ない。そのため、「Ｉデパート向けアプリケーション」、「Ｊデパート向けアプリケーション」、「Ｋストア向けアプリケーション」及び「Ｌストア向けアプリケーション」は、除外されている。尚、「Ｉデパート向けアプリケーション」、「Ｊデパート向けアプリケーション」、「Ｋストア向けアプリケーション」及び「Ｌストア向けアプリケーション」は、一旦保留され、リソースに余裕が生じた時点で、ベストエフォート用リソースプールのリソースを用いて復帰する。以上で、「Ｘ地域の交通麻痺」に応じたリソースの運用についての説明を終える。

続いて、「Ｙ地域の交通麻痺」に応じたリソースの運用について説明する。図１３に、「Ｙ地域の交通麻痺」発生時における割り当てルールテーブルの例を示す。テーブルの構成は、図４、図７、図９及び図１１と同様である。

第１レコードに示した「Ａ銀行向けアプリケーション」、第２レコードに示した「Ｂ銀行向けアプリケーション」、第３レコードに示した「Ｃ金庫向けアプリケーション」及び第４レコードに示した「Ｄ金庫向けアプリケーション」に対して、図４に示した通常モードと同様に、ＣＰＵ時間が基準の２倍まで、更にメモリ使用量も基準の２倍まで保証される。

第６レコードと第８レコードとは、「Ｙ地域」の交通業サービスである「Ｆ鉄道向けアプリケーション」及び「Ｈバス向けアプリケーション」に対して、ＣＰＵ時間が基準の６倍まで、更にメモリ使用量も基準の６倍まで保証されることを示している。

第５レコードと第７レコードとに示したように、「Ｙ地域」以外の交通業サービスである「Ｅ鉄道向けアプリケーション」及び「Ｇバス向けアプリケーション」は、ベストエフォート型で運用される。

第９レコードに示した「Ｉデパート向けアプリケーション」、第１０レコードに示した「Ｊデパート向けアプリケーション」、第１１レコードに示した「Ｋストア向けアプリケーション」及び第１２レコードに示した「Ｌストア向けアプリケーション」も、通常モードと同様に、ベストエフォート型で運用される。

図１４に、「Ｙ地域の交通麻痺」発生時におけるクラウドシステムの稼動イメージの例を示す。矩形５０１に示した物理リソース及び矩形５０５に示した管理システムについては、図５、図８、図１０及び図１２と同様である。

矩形１４２１及び破線の範囲１４２３に示した「Ａ銀行向けアプリケーション」についてのリソース量については、図５の矩形５２１及び破線の範囲５２３に示した通常モードにおける「Ａ銀行向けアプリケーション」のリソース量と同様である。以下同様に、矩形１４２５及び破線の範囲１４２７に示した「Ｂ銀行向けアプリケーション」についてのリソース量については、図５の矩形５２５及び破線の範囲５２７に示した通常モードにおける「Ｂ銀行向けアプリケーション」のリソース量と同様である。矩形１４２９及び破線の範囲１４３１に示した「Ｃ金庫向けアプリケーション」についてのリソース量については、図５の矩形５２９及び破線の範囲５３１に示した通常モードにおける「Ｃ金庫向けアプリケーション」のリソース量と同様である。矩形１４３３及び破線の範囲１４３５に示した「Ｄ金庫向けアプリケーション」についてのリソース量については、図５の矩形５３３及び破線の範囲５３５に示した通常モードにおける「Ｄ金庫向けアプリケーション」のリソース量と同様である。

破線の範囲１４４１に示した「Ｆ鉄道向けアプリケーション」に対して保証されるリソース量が３倍に増えている。矢印１４３９は、予兆に相当しないリソース量の増加のイメージを示している。この時点で「Ｆ鉄道向けアプリケーション」には、予兆が現れていない。更に、破線の範囲１４４７に示した「Ｈバス向けアプリケーション」に対して保証されるリソース量が３倍に増えている。矢印１４４５は、予兆に相当するリソース量の増加のイメージを示している。判定対象のアプリケーションのうち所定の割合で予兆が現れている場合には、「Ｙ地域の交通麻痺」が生じる恐れがあると判断され、予兆が現れていないアプリケーションに対するリソースも拡充される。

矩形１４０９に示した品質保証用リソースプールは、破線の範囲１４４１に示した「Ｆ鉄道向けアプリケーション」に対して保証されるリソース量が増えた分、リソースの量が増えている。また、同じく品質保証用リソースプールは、図５の矩形５３７と破線の範囲５３９に示した「Ｅ鉄道向けアプリケーション」に対して保証されるリソース量が減った分、リソースの量が減っている。更に、同じく品質保証用リソースプールは、矩形１４４３と破線の範囲１４４７に示した「Ｈバス向けアプリケーション」に対して保証されるリソース量が増えた分、リソースの量が増えている。

矩形１４５１に示した「Ｅ鉄道向けアプリケーション」が用いるリソース量は、基準Ｓｅに相当する。また、矩形１４５３に示した「Ｇバス向けアプリケーション」が用いるリソース量は、基準Ｓｇに相当するので、図５における矩形５５１に示した通常モードにおけるリソース量と変わらない。

図５の矩形５０７に示した休止リソースを全体リソースプールに組み込んでいるが、矩形１４０９に示した品質保証用リソースプールが大幅に増えているので、破線の範囲１４１１に示したベストエフォート用リソースプールが適用するリソースは少ない。そのため、「Ｉデパート向けアプリケーション」、「Ｊデパート向けアプリケーション」、「Ｋストア向けアプリケーション」及び「Ｌストア向けアプリケーション」は、除外されている。尚、「Ｉデパート向けアプリケーション」、「Ｊデパート向けアプリケーション」、「Ｋストア向けアプリケーション」及び「Ｌストア向けアプリケーション」は、一旦保留され、リソースに余裕が生じた時点で、ベストエフォート用リソースプールのリソースを用いて復帰する。以上で、各突発事象のモードに遷移した場合についての説明を終える。

続いて、管理システムについて説明する。図１５に、管理システムのモジュール構成例を示す。管理システムは、受信部１５０１、収集部１５０３、状態ＤＢ１５０５、判定部１５０７、パターンテーブル格納部１５０９、基準データ格納部１５１１、変更部１５１３、割り当てルール格納部１５１５、割り当てデータ記憶部１５１７、指示部１５１９及び送信部１５２１を有する。受信部１５０１、収集部１５０３、状態ＤＢ１５０５、判定部１５０７、パターンテーブル格納部１５０９、基準データ格納部１５１１、変更部１５１３、割り当てルール格納部１５１５、割り当てデータ記憶部１５１７、指示部１５１９及び送信部１５２１は、例えば図３０に示すハードウエア資源によって実現される。また、受信部１５０１、収集部１５０３、判定部１５０７、変更部１５１３、割り当てルール格納部１５１５、指示部１５１９及び送信部１５２１は、当該モジュールの処理の一部又は全部を、メモリ２５０１（図３０）にロードされたプログラムをＣＰＵ２５０３（図３０）で順次実行することにより実現するようにしてもよい。

受信部１５０１は、物理サーバ１０１のハイパーバイザから稼動状態データを受信する。収集部１５０３は、受信部１５０１を介して、各物理サーバ１０１のハイパーバイザで管理する稼動状態データを収集する。状態ＤＢ１５０５は、収集した稼動状態データを蓄積する。判定部１５０７は、突発事象に関わるアプリケーションプログラムの稼動状況が、突発事象の予兆を示すパターンに適合するか否かを判定する。パターンテーブル格納部１５０９は、突発事象の予兆を示すパターンのテーブルを格納する。

図１６に、パターンテーブルの例を示す。パターンテーブルは、突発事象についてのレコードを有している。レコードは、突発事象、事業分野、対象地域、稼動条件及び適合割合の条件のフィールドを有している。事業分野のフィールドには、突発事象に関連する事業分野が設定される。対象地域のフィールドには、各ユーザ向けアプリケーションによるサービスの対象地域を示す。稼動条件のフィールドには、突発事象の予兆に相当する稼動状況を判定するための条件が設定される。この例で、稼動条件は、メモリ使用量、トランザクション量及びネットワーク通信量についての条件を設けている。適合割合の条件のフィールドには、突発事象の予兆に相当する稼動状況に適合するアプリケーションプログラムの割合についての条件が設定される。パターンテーブルは、ユーザとクラウド事業者との契約に基づいて設定されるようにしてもよい。

第１レコードは、「金融界の信用不安」について、「金融業」に属し、「全国」を対象とするサービスを提供するアプリケーションプログラムを判定の対象とすることを示している。更に、第１レコードは、そのアプリケーションプログラムのメモリ使用量が、そのアプリケーションプログラムの基準となるメモリ使用量の１．５倍以上であり、且つそのアプリケーションプログラムのトランザクション量が、そのアプリケーションプログラムの基準となるトランザクション量の１．５倍以上であり、且つそのアプリケーションプログラムのネットワーク通信量が、状態ＤＢ１５０５に蓄積されているそのアプリケーションプログラムにおけるネットワーク通信量の平均に標準偏差の３倍を加えた値以上であることが、稼動条件であることを示している。また、第１レコードは、「７０％以上」が、適合するアプリケーションプログラムの割合の条件であることを示している。

第２レコードは、「金融機関のトラブル」について、「金融業」に属するサービスを提供するアプリケーションプログラムを個別に判定の対象とすることを示している。更に、第２レコードは、そのアプリケーションプログラムのメモリ使用量が、そのアプリケーションプログラムの基準となるメモリ使用量の１．５倍以上であり、且つそのアプリケーションプログラムのトランザクション量が、そのアプリケーションプログラムの基準となるトランザクション量の１．５倍以上であり、且つそのアプリケーションプログラムのネットワーク通信量が、状態ＤＢ１５０５に蓄積されているそのアプリケーションプログラムにおけるネットワーク通信量の平均に標準偏差の３倍を加えた値以上であることが、稼動条件であることを示している。また、第２レコードは、「１００％」が、適合するアプリケーションプログラムの割合の条件となっているが、個別のアプリケーションプログラムが適合する場合に、その適合により突発事象の予兆であると判定されることを意味している。

第３レコードは、「Ｘ地域の交通麻痺」について、「交通業」に属し、「Ｘ地域」を対象とするサービスを提供するアプリケーションプログラムを判定の対象とすることを示している。更に、第３レコードは、そのアプリケーションプログラムのメモリ使用量が、そのアプリケーションプログラムの基準となるメモリ使用量の１．５倍以上であり、且つそのアプリケーションプログラムのトランザクション量が、そのアプリケーションプログラムの基準となるトランザクション量の１．５倍以上であり、且つそのアプリケーションプログラムのネットワーク通信量が、状態ＤＢ１５０５に蓄積されているそのアプリケーションプログラムにおけるネットワーク通信量の平均に標準偏差の３倍を加えた値以上であることが、稼動条件であることを示している。また、第３レコードは、「３０％以上」が、適合するアプリケーションプログラムの割合の条件であることを示している。

第４レコードは、「Ｙ地域の交通麻痺」について、「交通業」に属し、「Ｙ地域」を対象とするサービスを提供するアプリケーションプログラムを判定の対象とすることを示している。更に、第４レコードは、そのアプリケーションプログラムのメモリ使用量が、そのアプリケーションプログラムの基準となるメモリ使用量の１．５倍以上であり、且つそのアプリケーションプログラムのトランザクション量が、そのアプリケーションプログラムの基準となるトランザクション量の１．５倍以上であり、且つそのアプリケーションプログラムのネットワーク通信量が、状態ＤＢ１５０５に蓄積されているそのアプリケーションプログラムにおけるネットワーク通信量の平均に標準偏差の３倍を加えた値以上であることが、稼動条件であることを示している。また、第４レコードは、「３０％以上」が、適合するアプリケーションプログラムの割合の条件であることを示している。

この例では、各レコードで同じ稼動条件を設定しているが、各レコードで稼動条件の一部又は全部を異なるように設定してもよい。あるいは、稼動条件の一部を省略するようにしてもよい。また、異なるパラメータによる稼動条件を設定するようにしてもよい。

図１５に示した管理システムのモジュール構成例の説明に戻って、基準データ格納部１５１１は、図３に例示した基準データテーブルを格納する。変更部１５１３は、突発事象に応じたルールに従って、アプリケーションプログラム群に対するリソースの割り当てを変更する。割り当てルール格納部１５１５は、図４、図７、図９及び図１３に例示した割り当てルールテーブルを格納する。割り当てデータ記憶部１５１７は、リソースの割り当てデータテーブルを格納する。指示部１５１９は、リソースの割り当てデータテーブルに従って、物理サーバ１０１のハイパーバイザにリソースの割り当ての更新を指示する。送信部１５２１は、リソースの割り当ての更新指示を物理サーバ１０１のハイパーバイザに送信する。以上で、管理システムのモジュール構成例についての説明を終える。

続いて、管理システムによる処理について説明する。図１７に、管理システムによる全体処理フローの例を示す。収集部１５０３は、収集処理を行う（Ｓ１７０１）。具体的には、収集部１５０３は、受信部１５０１を介して、各物理サーバ１０１のハイパーバイザで管理する稼動状態データを収集する。収集部１５０３は、収集した稼動状態データを状態ＤＢ１５０５に格納する。

判定部１５０７は、判定処理を実行する（Ｓ１７０３）。ここでは、判定処理（Ａ）を実行する。尚、判定処理（Ｂ）については、実施の形態２において説明する。

図１８に、判定処理（Ａ）のフロー例を示す。判定部１５０７は、パターンテーブルで未判定の突発事象に係るレコードを１つ特定する（Ｓ１８０１）。このとき、判定部１５０７は、例えばパターンテーブルのレコードを順次特定する。

そして、判定部１５０７は、対象アプリケーションプログラムを１つ選択する（Ｓ１８０３）。判定部１５０７は、アプリケーションプログラムが適用するサービスが事業分野に属し、当該サービスの対象地域が一致する場合に、対象アプリケーションプログラムに該当すると判定する。

この例で、図１６に示したパターンテーブルの第１レコードの場合には、「Ａ銀行向けアプリケーション」、「Ｂ銀行向けアプリケーション」、「Ｃ金庫向けアプリケーション」及び「Ｄ金庫向けアプリケーション」を順次選択する。

図１６に示したパターンテーブルの第２レコードの場合には、「Ａ銀行向けアプリケーション」、「Ｂ銀行向けアプリケーション」、「Ｃ金庫向けアプリケーション」あるいは「Ｄ金庫向けアプリケーション」を単独で選択する。

図１６に示したパターンテーブルの第３レコードの場合には、「Ｅ鉄道向けアプリケーション」と「Ｇバス向けアプリケーション」とを順次選択する。

図１６に示したパターンテーブルの第４レコードの場合には、「Ｆ鉄道向けアプリケーション」と「Ｈバス向けアプリケーション」とを順次選択する。

判定部１５０７は、選択したアプリケーションプログラムの稼動状態が、当該レコードで特定される稼動条件に適合するか否かを判定する（Ｓ１８０５）。このとき、判定部１５０７は、現在の稼動状態データを状態ＤＢ１５０５から取得する。この例では、図１６に示したように、メモリ使用量、トランザクション量及びネットワーク通信量の条件について判定し、それぞれの条件を満たす場合に適合すると判定する。

この例では、ＡＮＤ条件によって判定するが、ＯＲ条件によって判定するようにしてもよい。また、メモリ使用量、トランザクション量及びネットワーク通信量のうち、１又は２の条件について判定するようにしてもよい。また、メモリ使用量、トランザクション量及びネットワーク通信量以外のパラメータについて判定するようにしてもよい。

選択したアプリケーションプログラムの稼動状態が、当該レコードで特定される稼動条件に適合すると判定した場合には、判定部１５０７は、適合数をインクリメントする（Ｓ１８０７）。選択したアプリケーションプログラムの稼動状態が、当該レコードで特定される稼動条件に適合しないと判定した場合には、判定部１５０７は、適合数をインクリメントしない。

そして、判定部１５０７は、未選択の対象アプリケーションプログラムがあるか否かを判定し（Ｓ１８０９）、未選択の対象アプリケーションプログラムがあると判定した場合には、Ｓ１８０３に戻って上述の処理を繰り返す。

未選択の対象アプリケーションプログラムがないと判定した場合には、判定部１５０７は、適合割合を算出する（Ｓ１８１１）。判定部１５０７は、具体的には適合数を対象アプリケーションプログラムの数で割ることによって、適合割合を求める。

判定部１５０７は、算出した適合割合が、適合割合の条件を越えているか否かを判定する（Ｓ１８１３）。適合割合の条件を越えていると判定した場合には、Ｓ１８０１で特定したレコードのパターンに合致するので、判定部１５０７は、Ｓ１８０１で特定したレコードの突発事象を特定する（Ｓ１８１５）。つまり、突発事象の予兆がみられたと判断される。

適合割合の条件を越えていないと判定した場合には、Ｓ１８０１で特定したレコードのパターンに合致しないので、判定部１５０７は、突発事象を特定しない。つまり、突発事象の予兆がみられないと判断される。

判定部１５０７は、未判定の突発事象レコードがあるか否かを判定し（Ｓ１８１７）、未判定の突発事象レコードがあると判定した場合には、Ｓ１８０１に戻って上述の処理を繰り返す。

図１７に示した全体処理の説明に戻る。判定部１５０７が突発事象を特定したか否かによって、処理の流れは分岐する（Ｓ１７０５）。

判定部１５０７が突発事象を特定しなかった場合には、管理システムは全体処理を終える。

判定部１５０７が突発事象を特定した場合には、変更部１５１３は、変更処理を実行する（Ｓ１７０７）。ここでは、変更処理（Ａ）を実行する。変更処理（Ｂ）については、実施の形態２において説明する。

図１９に、変更処理（Ａ）のフロー例を示す。変更部１５１３は、当該突発事象に対応する割り当てルールテーブルを特定する（Ｓ１９０１）。そして、変更部１５１３は、まず品質保証型のアプリケーションプログラムについての割り当てを行う。

変更部１５１３は、品質保証型のアプリケーションプログラムを１つ選択する（Ｓ１９０３）。変更部１５１３は、例えば、品質保証型のアプリケーションプログラムを順次特定する。

変更部１５１３は、当該アプリケーションプログラムに対して保証するリソース量を算出する（Ｓ１９０５）。この例では、変更部１５１３は、当該アプリケーションプログラムの基準となるＣＰＵ時間に、割り当てルールにより特定される倍数を乗じて、保証するＣＰＵ時間を算出する。更に、変更部１５１３は、当該アプリケーションプログラムの基準となるメモリ使用量に、割り当てルールにより特定される倍数を乗じて、保証するメモリ使用量を算出する。

変更部１５１３は、上述の保証するリソース量を品質保証用の合計リソース量に加算する（Ｓ１９０７）。品質保証用の合計リソース量は、変更処理内で用いられる内部パラメータである。具体的には、合計ＣＰＵ時間と合計メモリ使用量とを算出する。このとき、変更部１５１３は、Ｓ１９０５で算出したＣＰＵ時間を合計ＣＰＵ時間に加え、更に、Ｓ１９０５で算出したメモリ使用量を合計メモリ使用量に加える。

また、変更部１５１３は、Ｓ１９０５で算出したリソース量のデータを、割り当てデータテーブルに加える（Ｓ１９０９）。

品質保証用の割り当てデータテーブルの例について、図２１を用いて説明する。品質保証用の割り当てデータテーブルは、品質保証型のアプリケーションプログラムについてのレコードを有している。レコードは、アプリケーション名、ＣＰＵ時間及びメモリ使用量のフィールドを有している。アプリケーション名のフィールドには、品質保証型のアプリケーションの名前が設定される。ＣＰＵ時間のフィールドには、当該アプリケーションプログラムに割り当てられるＣＰＵ時間が設定される。メモリ使用量のフィールドには、当該アプリケーションプログラムに割り当てられるメモリ使用量が設定される。

この図は、上述の「金融機関のトラブル」に応じた割り当ての例を示している。第１レコードは、「Ａ銀行向けアプリケーション」に対して、その基準の４倍のＣＰＵ時間と、その基準の４倍のメモリ使用量とが割り当てられることを示している。第２レコードは、「Ｂ銀行向けアプリケーション」に対して、その基準の２倍のＣＰＵ時間と、その基準の２倍のメモリ使用量とが割り当てられることを示している。第３レコードは、「Ｃ金庫向けアプリケーション」に対して、その基準の２倍のＣＰＵ時間と、その基準の２倍のメモリ使用量とが割り当てられることを示している。第４レコードは、「Ｄ金庫向けアプリケーション」に対して、その基準の２倍のＣＰＵ時間と、その基準の２倍のメモリ使用量とが割り当てられることを示している。第５レコードは、「Ｅ鉄道向けアプリケーション」に対して、その基準の２倍のＣＰＵ時間と、その基準の２倍のメモリ使用量とが割り当てられることを示している。第６レコードは、「Ｆ鉄道向けアプリケーション」に対して、その基準の２倍のＣＰＵ時間と、その基準の２倍のメモリ使用量とが割り当てられることを示している。尚、品質保証用の割り当てデータテーブルに、品質保証用の合計リソース量を含めるようにしてもよい。

図１９に示したＳ１９０９の処理では、変更部１５１３は、図２１に示した品質保証用の割り当てデータテーブルの１つのレコードに相当するデータを加える。

変更部１５１３は、未選択の品質保証型のアプリケーションプログラムがあるか否かを判定する（Ｓ１９１１）。未選択の品質保証型のアプリケーションプログラムがあると判定した場合には、Ｓ１９０３に戻って、上述の処理を繰り返す。

未選択の品質保証型のアプリケーションプログラムがないと判定した場合には、変更部１５１３は、空きリソース量を算出する（Ｓ１９１３）。具体的には、変更部１５１３は、全体リソースプールのリソース量から品質保証用の合計リソース量を差し引いて、残余のリソース量を算出する。この例では、残余のＣＰＵ時間と残余のメモリ使用量とが算出される。以上で、品質保証型のアプリケーションプログラムに対するリソースの割り当てを終える。そして、端子Ａを介して、図２０に示したＳ２００１の処理に移る。

以下では、ベストエフォート型のアプリケーションプログラムに対するリソースの割り当てを行う。変更部１５１３は、ベストエフォート型のアプリケーションプログラムを１つ選択する（Ｓ２００１）。変更部１５１３は、例えば、ベストエフォート型のアプリケーションプログラムを順次特定する。

変更部１５１３は、当該アプリケーションプログラムを稼動させるためのリソース量を特定する（Ｓ２００３）。この例では、変更部１５１３は、当該アプリケーションプログラムの基準となるＣＰＵ時間と、当該アプリケーションプログラムの基準となるメモリ使用量とを特定する。

変更部１５１３は、リソース量が足りるか否かを判定する（Ｓ２００５）。空きリソース量が上述の稼動させるためのリソース量を越えている場合に、変更部１５１３は、リソース量が足りると判定する。ＣＰＵ時間又はメモリ使用量の一方でも不足する場合には、変更部１５１３は、リソース量が足りないと判定する。

リソース量が足りないと判定した場合には、変更部１５１３は、変更処理（Ａ）を終え、図１７のＳ１７０９の処理に移る。

リソース量が足りると判定した場合には、変更部１５１３は、上述の稼動させるためのリソース量をベストエフォート用の合計リソース量に加算する（Ｓ２００７）。ベストエフォート用の合計リソース量は、変更処理内で用いられる内部パラメータである。具体的には、合計ＣＰＵ時間と合計メモリ使用量とを算出する。このとき、変更部１５１３は、Ｓ２００３で特定したＣＰＵ時間を合計ＣＰＵ時間に加え、更に、Ｓ２００３で特定したメモリ使用量を合計メモリ使用量に加える。

また、変更部１５１３は、Ｓ２００３で特定したリソース量のデータを、割り当てデータテーブルに加える（Ｓ２００９）。

ベストエフォート用の割り当てデータテーブルの例について、図２２を用いて説明する。ベストエフォート用の割り当てデータテーブルは、ベストエフォート型のアプリケーションプログラムについてのレコードを有している。レコードは、アプリケーション名、ＣＰＵ時間及びメモリ使用量のフィールドを有している。アプリケーション名のフィールドには、ベストエフォート型のアプリケーションの名前が設定される。ＣＰＵ時間のフィールドには、当該アプリケーションプログラムに割り当てられるＣＰＵ時間が設定される。メモリ使用量のフィールドには、当該アプリケーションプログラムに割り当てられるメモリ使用量が設定される。尚、ベストエフォート用の割り当てデータテーブルに、ベストエフォートの合計リソース量を含めるようにしてもよい。

この図は、上述の「金融機関のトラブル」に応じた割り当ての例を示している。第１レコードは、「Ｇバス向けアプリケーション」に対して、その基準のＣＰＵ時間と、その基準のメモリ使用量とが割り当てられることを示している。以下、同様に、第２レコードは、「Ｈバス向けアプリケーション」に対して、その基準のＣＰＵ時間と、その基準のメモリ使用量とが割り当てられることを示している。第３レコードは、「Ｉデパート向けアプリケーション」に対して、その基準のＣＰＵ時間と、その基準のメモリ使用量とが割り当てられることを示している。第４レコードは、「Ｊデパート向けアプリケーション」に対して、その基準のＣＰＵ時間と、その基準のメモリ使用量とが割り当てられることを示している。第５レコードは、「Ｋストア向けアプリケーション」に対して、その基準のＣＰＵ時間と、その基準のメモリ使用量とが割り当てられることを示している。第６レコードは、「Ｌストア向けアプリケーション」に対して、その基準のＣＰＵ時間と、その基準のメモリ使用量とが割り当てられることを示している。

図２０に示したＳ２００９の処理では、変更部１５１３は、図２２に示したベストエフォート用の割り当てデータテーブルの１つのレコードに相当するデータを加える。

変更部１５１３は、空きリソース量を更新する（Ｓ２０１１）。具体的には、変更部１５１３は、空きリソース量からベストエフォート用の合計リソース量を差し引いて、残余のリソース量を算出する。この例では、残余のＣＰＵ時間と残余のメモリ使用量とが算出される。

変更部１５１３は、未選択のベストエフォート型のアプリケーションプログラムがあるか否かを判定する（Ｓ２０１３）。未選択のベストエフォート型のアプリケーションプログラムがあると判定した場合には、Ｓ２００１に戻って、上述の処理を繰り返す。

未選択のベストエフォート型のアプリケーションプログラムがないと判定した場合には、変更部１５１３は、変更処理（Ａ）を終え、図１７のＳ１７０９の処理に移る。

図１７に示した処理の説明に戻って、指示部１５１９は、指示処理を実行する（Ｓ１７０９）。具体的には、指示部１５１９は、リソースの割り当てデータテーブルに従って、リソースの割り当ての更新を物理サーバ１０１のハイパーバイザに指示する。このとき、送信部１５２１は、リソースの割り当ての更新指示を物理サーバ１０１のハイパーバイザに送信する。

物理サーバ１０１のハイパーバイザは、指示に従って、例えば仮想サーバに割り当てられるリソースを変更し、仮想サーバで動作させるアプリケーションプログラムに割り当てられるリソースを変更する。仮想サーバ間で、アプリケーションプログラムを移動させるようにしてもよい。以上で、管理システムによる処理についての説明を終える。

本実施の形態によれば、突発事象に関わるアプリケーションの需要の変化を端緒として突発事象を予測し、アプリケーションプログラム間のリソースの割り当てを変更するので、突発事象に応じて全体として適正なリソースの運用を図ることができる。

また、ある事業に関するアプリケーションへの需要の変化を端緒として、その事業に関連する突発事象を予測することができる。例えば、金融業に関するサービスである「金融取引」への需要の増大を端緒として、「金融界の信用不安」という特定事象を予測することができる。

また、地域向けアプリケーションへの需要の変化を端緒として、その地域に関する特定事象を予測することができる。例えば、地域向けサービスである「ある地域の交通案内」への需要の増大を端緒として、「ある地域の交通麻痺」という特定事象を予測することができる。

また、ベストエフォート用リソースプールと品質保証用リソースプールとを分けることによって、ベストエフォート型のアプリケーションプログラムが品質保証型のアプリケーションプログラムのためのリソースを侵食することを防げる。

［実施の形態２］
上述の実施の形態では、アプリケーションの単位で稼動状態を判定し、更に、アプリケーションの単位でリソースを割り当てる例を示したが、本実施の形態では、アプリケーションに含まれる機能の単位で稼動状態を判定し、同じく機能の単位でリソースを割り当てる例について説明する。

本実施の形態では、アプリケーションに複数の機能が含まれていることを前提とする。以下、「Ｅ鉄道向けアプリケーション」及び「Ｇバス向けアプリケーション」に夫々「運行案内」の機能と「勤怠管理」の機能が含まれている例について説明する。これらの機能は、アプリケーションプログラムの一部である機能モジュールプログラムを、仮想サーバで実行することによって実現される。

図２３に、実施の形態２における割り当てルールテーブルの例を示す。本実施の形態の場合、レコードは、機能名のフィールドも有している。

省略しているレコードを除く第１レコードは、「Ｅ鉄道向けアプリケーション」の「運行案内」の機能に対して、ＣＰＵ時間を基準の６倍まで、更にメモリ使用量も基準の６倍まで保証することを示している。

同じく省略しているレコードを除く第２レコードは、「Ｅ鉄道向けアプリケーション」の「勤怠管理」の機能は、ベストエフォート型で運用されることを示している。

同じく省略しているレコードを除く第３レコードは、「Ｇバス向けアプリケーション」の「運行案内」の機能に対して、ＣＰＵ時間を基準の６倍まで、更にメモリ使用量も基準の６倍まで保証することを示している。

同じく省略しているレコードを除く第４レコードは、「Ｇバス向けアプリケーション」の「勤怠管理」の機能は、ベストエフォート型で運用されることを示している。

続いて、図２４に、実施の形態２におけるパターンテーブルの例を示す。本実施の形態の場合、レコードは、機能名のフィールドも有している。機能名のフィールドには、判定対象となる機能が設定される。

第１レコードは、「Ｘ地域の交通麻痺」について、「交通業」に属し、「Ｘ地域」を対象とするサービスを提供するアプリケーションプログラムのうち、「運行案内」の機能を判定の対象とすることを示している。他のフィールドについては、図１６に示した第３レコードと同様である。

第２レコードは、「Ｙ地域の交通麻痺」について、「交通業」に属し、「Ｙ地域」を対象とするサービスを提供するアプリケーションプログラムのうち、「運行案内」の機能を判定の対象とすることを示している。他のフィールドについては、図１６に示した第４レコードと同様である。

次に、本実施の形態における判定処理について説明する。図１７に示したＳ１７０３では、判定部１５０７が判定処理（Ｂ）を実行する。

図２５に、判定処理（Ｂ）のフロー例を示す。判定部１５０７は、図１８に示したＳ１８０１と同様に、パターンテーブルで未判定の突発事象に係るレコードを１つ特定する（Ｓ２５０１）。

そして、判定部１５０７は、対象機能を１つ選択する（Ｓ２５０３）。例えば、判定部１５０７は、対象機能を順次特定する。

判定部１５０７は、選択した機能の稼動状態が、当該レコードで特定される稼動条件に適合するか否かを判定する（Ｓ２５０５）。このとき、判定部１５０７は、機能の稼動状態データを状態ＤＢ１５０５から取得する。

選択した機能の稼動状態が、当該レコードで特定される稼動条件に適合すると判定した場合には、判定部１５０７は、適合数をインクリメントする（Ｓ２５０７）。選択した機能の稼動状態が、当該レコードで特定される稼動条件に適合しないと判定した場合には、判定部１５０７は、適合数をインクリメントしない。

そして、判定部１５０７は、未選択の対象機能があるか否かを判定し（Ｓ２５０９）、未選択の対象機能があると判定した場合には、Ｓ２５０３に戻って上述の処理を繰り返す。

未選択の対象機能がないと判定した場合には、判定部１５０７は、適合割合を算出する（Ｓ２５１１）。具体的には、適合数を対象機能の数で割ることによって、適合割合を求める。

判定部１５０７は、算出した適合割合が、適合割合の条件を越えているか否かを判定する（Ｓ２５１３）。適合割合の条件を越えていると判定した場合には、Ｓ２５０１で特定したレコードのパターンに合致するので、判定部１５０７は、Ｓ２５０１で特定したレコードの突発事象を特定する（Ｓ２５１５）。つまり、突発事象の予兆がみられたと判断される。

適合割合の条件を越えていないと判定した場合には、Ｓ２５０１で特定したレコードのパターンに合致しないので、判定部１５０７は、突発事象を特定しない。つまり、突発事象の予兆がみられないと判断される。

判定部１５０７は、未判定の突発事象レコードがあるか否かを判定し（Ｓ２５１７）、未判定の突発事象レコードがあると判定した場合には、Ｓ２５０１に戻って上述の処理を繰り返す。以上で、本実施の形態における判定処理についての説明を終える。

図２６に、実施の形態２における基準データテーブルの例を示す。本実施の形態の場合、レコードは、機能名のフィールドを有する。機能名のフィールドには、アプリケーションプログラムに含まれる機能の名前が設定される。ＣＰＵ時間のフィールドには、当該機能におけるＣＰＵ時間の基準が設定される。メモリ使用量のフィールドには、当該機能におけるメモリ使用量の基準が設定される。トランザクション量のフィールドには、当該機能におけるトランザクション量の基準が設定される。ネットワーク通信量のフィールドには、当該機能におけるネットワーク通信量の基準が設定される。

省略しているレコードを除く第１レコードは、「Ｅ鉄道向けアプリケーション」に含まれる「運行案内」についての基準を定めている。図示するように、「Ｅ鉄道向けアプリケーション」に含まれる「運行案内」の基準となるＣＰＵ時間は、「Ｓｅ１（Ｃ）」である。同じく「Ｅ鉄道向けアプリケーション」に含まれる「運行案内」の基準となるメモリ使用量は、「Ｓｅ１（Ｍ）」である。同じく「Ｅ鉄道向けアプリケーション」に含まれる「運行案内」の基準となるトランザクション量は、「Ｓｅ１（Ｔ）」である。同じく「Ｅ鉄道向けアプリケーション」のに含まれる「運行案内」基準となるネットワーク通信量は、「Ｓｅ１（Ｎ）」である。

省略しているレコードを除く第２レコードは、「Ｅ鉄道向けアプリケーション」に含まれる「勤怠管理」についての基準を定めている。図示するように、「Ｅ鉄道向けアプリケーション」に含まれる「勤怠管理」の基準となるＣＰＵ時間は、「Ｓｅ２（Ｃ）」である。同じく「Ｅ鉄道向けアプリケーション」に含まれる「勤怠管理」の基準となるメモリ使用量は、「Ｓｅ２（Ｍ）」である。同じく「Ｅ鉄道向けアプリケーション」に含まれる「勤怠管理」の基準となるトランザクション量は、「Ｓｅ２（Ｔ）」である。同じく「Ｅ鉄道向けアプリケーション」のに含まれる「勤怠管理」基準となるネットワーク通信量は、「Ｓｅ２（Ｎ）」である。

省略しているレコードを除く第３レコードは、「Ｇバス向けアプリケーション」に含まれる「運行案内」についての基準を定めている。図示するように、「Ｇバス向けアプリケーション」に含まれる「運行案内」の基準となるＣＰＵ時間は、「Ｓｇ１（Ｃ）」である。同じく「Ｇバス向けアプリケーション」に含まれる「運行案内」の基準となるメモリ使用量は、「Ｓｇ１（Ｍ）」である。同じく「Ｇバス向けアプリケーション」に含まれる「運行案内」の基準となるトランザクション量は、「Ｓｇ１（Ｔ）」である。同じく「Ｇバス向けアプリケーション」のに含まれる「運行案内」基準となるネットワーク通信量は、「Ｓｇ１（Ｎ）」である。

省略しているレコードを除く第４レコードは、「Ｇバス向けアプリケーション」に含まれる「勤怠管理」についての基準を定めている。図示するように、「Ｇバス向けアプリケーション」に含まれる「勤怠管理」の基準となるＣＰＵ時間は、「Ｓｇ２（Ｃ）」である。同じく「Ｇバス向けアプリケーション」に含まれる「勤怠管理」の基準となるメモリ使用量は、「Ｓｇ２（Ｍ）」である。同じく「Ｇバス向けアプリケーション」に含まれる「勤怠管理」の基準となるトランザクション量は、「Ｓｇ２（Ｔ）」である。同じく「Ｇバス向けアプリケーション」のに含まれる「勤怠管理」基準となるネットワーク通信量は、「Ｓｇ２（Ｎ）」である。

図２７に、実施の形態２におけるクラウドシステムの稼動イメージの例を示す。この図は、「Ｘ地域の交通麻痺」発生時における稼動イメージを示している。矩形５０１に示した物理リソース及び矩形５０５に示した管理システムについては、図５、図８、図１０、図１２及び図１４と同様である。

矩形２７２１は、「Ｅ鉄道向けアプリケーション」に含まれる「運行案内」が用いるリソース量の基準を模式的に示している。矩形２７２１の横幅が、「Ｅ鉄道向けアプリケーション」に含まれる「運行案内」が用いるリソース量の基準Ｓｅ１に相当する。前述と同様に、リソースの種類は特定していない。基準Ｓｅ１は、例えば図２６に示したＣＰＵ時間の基準Ｓｅ１（Ｃ）及びメモリ使用量の基準Ｓｅ１（Ｍ）を包括するイメージである。

破線の範囲２７２５は、「Ｅ鉄道向けアプリケーション」に含まれる「運行案内」に対して保証されるリソース量の基準を模式的に示している。破線の範囲２７２５の横幅が、「Ｅ鉄道向けアプリケーション」に含まれる「運行案内」に対して保証されるリソース量に相当する。この例では、基準Ｓｅ１の６倍のリソース量が保証されている。保証されるリソース量は、図２３に示した「Ｅ鉄道向けアプリケーション」に含まれる「運行案内」の割り当てルールに基づいて求められる。矢印２７２３は、予兆に相当するリソース量の増加のイメージを示している。

保証されるリソース量は、「Ｅ鉄道向けアプリケーション」に含まれる「運行案内」で占有されるようにする。例えば、「Ｅ鉄道向けアプリケーション」に含まれる「運行案内」のために、基準Ｓｅ１（Ｃ）の６倍に相当するＣＰＵ時間が確保され、基準Ｓｅ１（Ｍ）の６倍に相当するメモリ使用量が確保される。

矩形２７２７は、「Ｇバス向けアプリケーション」に含まれる「運行案内」が用いるリソース量の基準を模式的に示している。矩形２７２７の横幅が、「Ｇバス向けアプリケーション」に含まれる「運行案内」が用いるリソース量の基準Ｓｇ１に相当する。前述と同様に、リソースの種類は特定していない。基準Ｓｇ１は、例えば図２６に示したＣＰＵ時間の基準Ｓｇ１（Ｃ）及びメモリ使用量の基準Ｓｇ１（Ｍ）を包括するイメージである。

破線の範囲２７３１は、「Ｇバス向けアプリケーション」に含まれる「運行案内」に対して保証されるリソース量の基準を模式的に示している。破線の範囲２７３１の横幅が、「Ｇバス向けアプリケーション」に含まれる「運行案内」に対して保証されるリソース量に相当する。この例では、基準Ｓｇ１の６倍のリソース量が保証されている。保証されるリソース量は、図２３に示した「Ｇバス向けアプリケーション」に含まれる「運行案内」の割り当てルールに基づいて求められる。矢印２７２９は、予兆に相当しないリソース量の増加のイメージを示している。この時点で「Ｇバス向けアプリケーション」には、予兆が現れていない。

保証されるリソース量は、「Ｇバス向けアプリケーション」に含まれる「運行案内」で占有されるようにする。例えば、「Ｇバス向けアプリケーション」に含まれる「運行案内」のために、基準Ｓｇ１（Ｃ）の６倍に相当するＣＰＵ時間が確保され、基準Ｓｇ１（Ｍ）の６倍に相当するメモリ使用量が確保される。

矩形２７５１は、「Ｅ鉄道向けアプリケーション」に含まれる「勤怠管理」が用いるリソース量の基準を模式的に示している。矩形２７５１の横幅が、「Ｅ鉄道向けアプリケーション」に含まれる「勤怠管理」が用いるリソース量の基準Ｓｅ２に相当する。前述と同様に、リソースの種類は特定していない。基準Ｓｅ２は、例えば図２６に示したＣＰＵ時間の基準Ｓｅ２（Ｃ）及びメモリ使用量の基準Ｓｅ２（Ｍ）を包括するイメージである。

「Ｅ鉄道向けアプリケーション」に含まれる「勤怠管理」は、ベストエフォート型であるので、保証に対応するリソース量を確保していない。但し、「Ｅ鉄道向けアプリケーション」に含まれる「勤怠管理」に対して所定のリソース量を予備的に確保するようにしてもよい。

矩形２７５３は、「Ｇバス向けアプリケーション」に含まれる「勤怠管理」が用いるリソース量の基準を模式的に示している。矩形２７５３の横幅が、「Ｇバス向けアプリケーション」に含まれる「勤怠管理」が用いるリソース量の基準Ｓｇ２に相当する。前述と同様に、リソースの種類は特定していない。基準Ｓｇ２は、例えば図２６に示したＣＰＵ時間の基準Ｓｇ２（Ｃ）及びメモリ使用量の基準Ｓｇ２（Ｍ）を包括するイメージである。

「Ｇバス向けアプリケーション」に含まれる「勤怠管理」は、ベストエフォート型であるので、保証に対応するリソース量を確保していない。但し、「Ｇバス向けアプリケーション」に含まれる「勤怠管理」に対して所定のリソース量を予備的に確保するようにしてもよい。

このように、同じアプリケーションプログラムで利用するリソースが、機能毎に品質保証用リソースプールとベストエフォート用リソースプールとに分かれることもある。この例では、「Ｘ地域の交通麻痺」の影響を受ける「運行案内」に係るリソースが保証され、「Ｘ地域の交通麻痺」の影響を受けない「勤怠管理」に係るリソースは保証されないようになる。

上述のイメージを実現するための判定処理について説明する。図１７に示したＳ１７０７では、変更部１５１３が変更処理（Ｂ）を実行する。

図２８に、変更処理（Ｂ）のフロー例を示す。変更部１５１３は、判定処理（Ｂ）で特定した突発事象に対応する割り当てルールテーブルを特定する（Ｓ２８０１）。そして、変更部１５１３は、まず品質保証型の機能に対するリソースの割り当てを行う。

変更部１５１３は、品質保証型の機能を１つ選択する（Ｓ２８０３）。変更部１５１３は、例えば、品質保証型の機能を順次特定する。

変更部１５１３は、当該機能に対して保証するリソース量を算出する（Ｓ２８０５）。この例では、変更部１５１３は、当該機能の基準となるＣＰＵ時間に、割り当てルールにより特定される倍数を乗じて、保証するＣＰＵ時間を算出する。更に、変更部１５１３は、当該機能の基準となるメモリ使用量に、割り当てルールにより特定される倍数を乗じて、保証するメモリ使用量を算出する。

変更部１５１３は、上述の保証するリソース量を品質保証用の合計リソース量に加算する（Ｓ２８０７）。品質保証用の合計リソース量は、変更処理内で用いられる内部パラメータである。具体的には、合計ＣＰＵ時間と合計メモリ使用量とを算出する。このとき、変更部１５１３は、Ｓ２８０５で算出したＣＰＵ時間を合計ＣＰＵ時間に加え、更に、Ｓ２８０５で算出したメモリ使用量を合計メモリ使用量に加える。

また、変更部１５１３は、Ｓ２８０５で算出したリソース量のデータを、割り当てデータテーブルに加える（Ｓ２８０９）。変更部１５１３は、品質保証用の割り当てデータテーブルの１つのレコードに相当するデータを加える。本実施の形態における割り当てデータテーブルは、機能についてレコードを設け、機能に対するリソース量が設定される。

変更部１５１３は、未選択の品質保証型の機能があるか否かを判定する（Ｓ２８１１）。未選択の品質保証型の機能があると判定した場合には、Ｓ２８０３に戻って、上述の処理を繰り返す。

未選択の品質保証型の機能がないと判定した場合には、変更部１５１３は、空きリソース量を算出する（Ｓ２８１３）。具体的には、変更部１５１３は、全体リソースプールのリソース量から品質保証用の合計リソース量を差し引いて、残余のリソース量を算出する。この例では、残余のＣＰＵ時間と残余のメモリ使用量とが算出される。以上で、品質保証型の機能に対するリソースの割り当てを終える。そして、端子Ｂを介して、図２９に示したＳ２９０１の処理に移る。

以下では、ベストエフォート型の機能に対するリソースの割り当てを行う。変更部１５１３は、ベストエフォート型の機能を１つ選択する（Ｓ２９０１）。変更部１５１３は、例えば、ベストエフォート型の機能を順次特定する。

変更部１５１３は、当該機能を稼動させるためのリソース量を特定する（Ｓ２９０３）。この例では、変更部１５１３は、当該機能の基準となるＣＰＵ時間と、当該機能の基準となるメモリ使用量とを特定する。

変更部１５１３は、リソース量が足りるか否かを判定する（Ｓ２９０５）。空きリソース量が上述の稼動させるためのリソース量を越えている場合に、変更部１５１３は、リソース量が足りると判定する。ＣＰＵ時間又はメモリ使用量の一方でも不足する場合には、変更部１５１３は、リソース量が足りないと判定する。

リソース量が足りないと判定した場合には、変更部１５１３は、変更処理（Ｂ）を終え、図１７のＳ１７０９の処理に移る。

リソース量が足りると判定した場合には、変更部１５１３は、上述の稼動させるためのリソース量をベストエフォート用の合計リソース量に加算する（Ｓ２９０７）。ベストエフォート用の合計リソース量は、変更処理内で用いられる内部パラメータである。具体的には、合計ＣＰＵ時間と合計メモリ使用量とを算出する。このとき、変更部１５１３は、Ｓ２９０３で特定したＣＰＵ時間を合計ＣＰＵ時間に加え、更に、Ｓ２９０３で特定したメモリ使用量を合計メモリ使用量に加える。

また、変更部１５１３は、Ｓ２９０３で特定したリソース量のデータを、割り当てデータテーブルに加える（Ｓ２００９）。

変更部１５１３は、空きリソース量を更新する（Ｓ２９１１）。具体的には、変更部１５１３は、空きリソース量からベストエフォート用の合計リソース量を差し引いて、残余のリソース量を算出する。この例では、残余のＣＰＵ時間と残余のメモリ使用量とが算出される。

変更部１５１３は、未選択のベストエフォート型の機能があるか否かを判定する（Ｓ２９１３）。未選択のベストエフォート型の機能があると判定した場合には、Ｓ２９０１に戻って、上述の処理を繰り返す。

未選択のベストエフォート型の機能がないと判定した場合には、変更部１５１３は、変更処理（Ｂ）を終え、図１７のＳ１７０９の処理に移る。

実施の形態１に係るアプリケーションプログラム単位の処理と、実施の形態２に係るアプリケーションプログラムに含まれる機能単位の処理を組み合わせるようにしてもよい。

本実施の形態によれば、突発事象に関わるアプリケーションに含まれる機能の需要の変化を端緒として突発事象を予測し、アプリケーションプログラムに含まれる機能間のリソースの割り当てを変更するので、突発事象に応じて詳細なリソースの運用を図ることができる。

以上本技術の一実施の形態を説明したが、本技術はこれに限定されるものではない。例えば、上述の機能ブロック構成は実際のプログラムモジュール構成に一致しない場合もある。

また、上で説明した各記憶領域の構成は一例であって、上記のような構成でなければならないわけではない。さらに、処理フローにおいても、処理結果が変わらなければ処理の順番を入れ替えることも可能である。さらに、並列に実行させるようにしても良い。

なお、上で述べた物理サーバ１０１は、コンピュータ装置であって、図３０に示すように、メモリ２５０１とＣＰＵ（Central Processing Unit）２５０３とハードディスク・ドライブ（ＨＤＤ：Hard Disk Drive）２５０５と表示装置２５０９に接続される表示制御部２５０７とリムーバブル・ディスク２５１１用のドライブ装置２５１３と入力装置２５１５とネットワークに接続するための通信制御部２５１７とがバス２５１９で接続されている。オペレーティング・システム（ＯＳ：Operating System）及び本実施例における処理を実施するためのアプリケーション・プログラムは、ＨＤＤ２５０５に格納されており、ＣＰＵ２５０３により実行される際にはＨＤＤ２５０５からメモリ２５０１に読み出される。ＣＰＵ２５０３は、アプリケーション・プログラムの処理内容に応じて表示制御部２５０７、通信制御部２５１７、ドライブ装置２５１３を制御して、所定の動作を行わせる。また、処理途中のデータについては、主としてメモリ２５０１に格納されるが、ＨＤＤ２５０５に格納されるようにしてもよい。本技術の実施例では、上で述べた処理を実施するためのアプリケーション・プログラムはコンピュータ読み取り可能なリムーバブル・ディスク２５１１に格納されて頒布され、ドライブ装置２５１３からＨＤＤ２５０５にインストールされる。インターネットなどのネットワーク及び通信制御部２５１７を経由して、ＨＤＤ２５０５にインストールされる場合もある。このようなコンピュータ装置は、上で述べたＣＰＵ２５０３、メモリ２５０１などのハードウエアとＯＳ及びアプリケーション・プログラムなどのプログラムとが有機的に協働することにより、上で述べたような各種機能を実現する。

以上述べた本発明の実施の形態をまとめると、以下のようになる。

本実施の形態に係る情報処理装置は、仮想システムにおいて、特定事象に関わるサービスを実現するプログラムの稼動状況が、当該特定事象の予兆を示すパターンに合致するか否かを判定する判定部と、稼動状況がパターンに合致すると判定した場合に、特定事象に応じたルールに従って、仮想システムにおいて稼動している上記プログラム及び他のプログラムに対する仮想システムにおけるリソースの割り当てを変更する変更部とを有する。

このようにすれば、特定事象に関わるサービスの需要の変化を端緒として特定事象を予測し、プログラム間のリソースの割り当てを変更するので、特定事象に応じて全体として適正なリソースの運用を図ることができる。

また、パターンは、特定事象に関連する事業分野と、稼動条件とを定めるようにしてもよい。更に上記判定部は、事業分野に基づいて上記プログラムを特定し、上記プログラムの稼動状況が稼動条件を満たすか否かを判定するようにしてもよい。

このようにすれば、ある事業に関するサービスへの需要の変化を端緒として、その事業に関連する特定事象を予測することができる。例えば、金融業に関するサービスである「金融取引」への需要の増大を端緒として、「金融界の信用不安」という特定事象を予測することができる。

また、パターンは、サービスの対象地域を定めるようにしてもよい。更に、上記判定部は、対象地域に基づいて、上記プログラムを特定するようにしてもよい。

このようにすれば、地域向けサービスへの需要の変化を端緒として、その地域に関する特定事象を予測することができる。例えば、地域向けサービスである「ある地域の交通案内」への需要の増大を端緒として、「ある地域の交通麻痺」という特定事象を予測することができる。

ルールは、上記プログラム及び他のプログラムに対する保証レベルを定めるようにしてもよい。更に、上記変更部は、保証レベルに基づいて、上記プログラム及び他のプログラムが各々利用するリソースプールを選択するようにしてもよい。

このようにすれば、保証レベルの低いプログラムが利用するリソースプールと、保証レベルの高いプログラムが利用するリソースプールとを分けることによって、保証レベルの低いプログラムが保証レベルの高いプログラムのためのリソースを侵食することを防げる。

なお、上記方法による処理をコンピュータに行わせるためのプログラムを作成することができ、当該プログラムは、例えばフレキシブルディスク、ＣＤ−ＲＯＭ、光磁気ディスク、半導体メモリ、ハードディスク等のコンピュータ読み取り可能な記憶媒体又は記憶装置に格納されるようにしてもよい。尚、中間的な処理結果は、一般的にメインメモリ等の記憶装置に一時保管される。

以上の実施例を含む実施形態に関し、さらに以下の付記を開示する。

（付記１）
仮想システムにおいて、特定事象に関わるサービスを実現するプログラムの稼動状況が、当該特定事象の予兆を示すパターンに合致するか否かを判定する判定部と、
前記稼動状況が前記パターンに合致すると判定した場合に、前記特定事象に応じたルールに従って、前記仮想システムにおいて稼動している前記プログラム及び他のプログラムに対する前記仮想システムにおけるリソースの割り当てを変更する変更部と
を有する情報処理装置。

（付記２）
前記パターンは、前記特定事象に関連する事業分野と、前記稼動条件とを定め、
前記判定部は、前記事業分野に基づいて前記プログラムを特定し、前記プログラムの稼動状況が前記稼動条件を満たすか否かを判定する
付記１記載の情報処理装置。

（付記３）
前記パターンは、前記サービスの対象地域を定め、
前記判定部は、前記対象地域に基づいて、前記プログラムを特定する
付記２記載の情報処理装置。

（付記４）
前記ルールは、前記プログラム及び前記他のプログラムに対する保証レベルを定め、
前記変更部は、前記保証レベルに基づいて、前記プログラム及び前記他のプログラムが各々利用するリソースプールを選択する
付記１乃至３いずれか１つ記載の情報処理装置。

（付記５）
仮想システムにおいて、特定事象に関わるサービスを実現するプログラムの稼動状況が、当該特定事象の予兆を示すパターンに合致するか否かを判定する処理と、
前記稼動状況が前記パターンに合致すると判定した場合に、前記特定事象に応じたルールに従って、前記仮想システムにおいて稼動している前記プログラム及び他のプログラムに対する前記仮想システムにおけるリソースの割り当てを変更する処理と
をコンピュータに実行させるためのプログラム。

（付記６）
仮想システムにおいて、特定事象に関わるサービスを実現するプログラムの稼動状況が、当該特定事象の予兆を示すパターンに合致するか否かを判定する処理と、
前記稼動状況が前記パターンに合致すると判定した場合に、前記特定事象に応じたルールに従って、前記仮想システムにおいて稼動している前記プログラム及び他のプログラムに対する前記仮想システムにおけるリソースの割り当てを変更する処理と
を含む情報処理方法。

１０１ 物理サーバ １０３ ＦＷ兼ルーター
１５０１ 受信部 １５０３ 収集部
１５０５ 状態ＤＢ １５０７ 判定部
１５０９ パターンテーブル格納部 １５１１ 基準データ格納部
１５１３ 変更部 １５１５ 割り当てルール格納部
１５１７ 割り当てデータ記憶部 １５１９ 指示部
１５２１ 送信部

Claims (4)

1. 仮想システムにおいて、特定事象に関わるサービスを実現するプログラムの稼動状況が、当該特定事象の予兆を示すパターンに合致するか否かを判定する判定部と、
   前記稼動状況が前記パターンに合致すると判定した場合に、前記特定事象に応じてリソースの割り当ての変更が許可されたリソースプールにおいて、前記特定事象に応じたルールに従って、前記仮想システムにおいて稼動している前記プログラム及び他のプログラムに対する前記仮想システムにおけるリソースの割り当てを変更する変更部と
   を備え、
   前記ルールは、プログラムに応じて設定されたリソースの割り当ての保証範囲を定めたルールであり、
   前記パターンは、前記特定事象に関連する事業分野と、前記サービスの対象地域と、前記稼動状況の条件とを含み、
   前記判定部は、前記事業分野及び前記対象地域に基づいて、前記プログラムを特定し、前記プログラムの稼動状況が前記条件を満たすか否かを判定する
   ことを特徴とする情報処理装置。
2. 前記ルールは、前記プログラム及び前記他のプログラムに対する保証レベルを定め、
   前記変更部は、前記保証レベルに基づいて、前記プログラム及び前記他のプログラムが各々利用するリソースプールを選択する
   請求項１記載の情報処理装置。
3. 仮想システムにおいて、特定事象に関わるサービスを実現するプログラムの稼動状況が、当該特定事象の予兆を示すパターンに合致するか否かを判定する判定処理と、
   前記稼動状況が前記パターンに合致すると判定した場合に、前記特定事象に応じてリソースの割り当ての変更が許可されたリソースプールにおいて、前記特定事象に応じたルールに従って、前記仮想システムにおいて稼動している前記プログラム及び他のプログラムに対する前記仮想システムにおけるリソースの割り当てを変更する処理と
   をコンピュータに実行させるための情報処理プログラムであって、
   前記ルールは、プログラムに応じて設定されたリソースの割り当ての保証範囲を定めたルールであり、
   前記パターンは、前記特定事象に関連する事業分野と、前記サービスの対象地域と、前記稼動状況の条件とを含み、
   前記判定処理において、前記事業分野及び前記対象地域に基づいて、前記プログラムを特定し、前記プログラムの稼動状況が前記条件を満たすか否かを判定する
   ことを特徴とする情報処理プログラム。
4. 仮想システムにおいて、特定事象に関わるサービスを実現するプログラムの稼動状況が、当該特定事象の予兆を示すパターンに合致するか否かを判定する判定処理と、
   前記稼動状況が前記パターンに合致すると判定した場合に、前記特定事象に応じてリソースの割り当ての変更が許可されたリソースプールにおいて、前記特定事象に応じたルールに従って、前記仮想システムにおいて稼動している前記プログラム及び他のプログラムに対する前記仮想システムにおけるリソースの割り当てを変更する処理と
   を含み、コンピュータにより実行される情報処理方法であって、
   前記ルールは、プログラムに応じて設定されたリソースの割り当ての保証範囲を定めたルールであり、
   前記パターンは、前記特定事象に関連する事業分野と、前記サービスの対象地域と、前記稼動状況の条件とを含み、
   前記判定処理において、前記事業分野及び前記対象地域に基づいて、前記プログラムを特定し、前記プログラムの稼動状況が前記条件を満たすか否かを判定する
   ことを特徴とする情報処理方法。

Images