(58)【調査した分野】(Int.Cl.,DB名)
前記設定情報を特定する処理において、前記第1のシステム情報に含まれる前記第1の構成要素群と類似する第2の構成要素群に対応する前記第2のシステムが見つからない場合、前記第1のシステムの設定情報を監視要の設定情報と特定する、請求項1に記載の設定支援プログラム。
【発明を実施するための形態】
【0015】
図1、
図2は、クラウドサービスにおける顧客環境とクラウド事業者環境における運用監視テストを説明する図である。
図1、2において、サーバセンタには、クラウドサービスを提供するクラウド事業者環境20と、クラウドサービスを受ける顧客X社環境10とが配備されている。顧客X社環境10には、物理マシン、ストレージ、ネットワークなどのハードウエアのリソースプール14が配備され、例えば、業務システム1(SYS1)や業務システム2(SYS2)を複数の仮想マシンVMにより生成し、それらの業務システムが所望のサービスを提供する。
【0016】
一方、クラウド事業者環境20にも、物理マシン、ストレージ、ネットワークなどのハードウエアのリソースプール24が配備され、顧客X社環境10内の業務システムの生成を管理する管理サーバ21や、業務システムの運用を監視する監視サーバ22が、物理マシンや物理マシンに生成した仮想マシンなどにより構築される。
【0017】
顧客X社端末15は、顧客X社環境10の外側または内側に配備され、管理サーバ21が提供するクラウドサービスサイトにアクセスし、業務システムを構成する仮想マシンを顧客X社環境内に配備することや削除することを、管理サーバ21に要求する。管理サーバ21は、その要求に応じて、顧客X社が要求する業務システムの仮想マシンの配備や削除を実行する。具体的には、管理サーバ21は、顧客X社環境内のリソースプール14の物理マシンの仮想化ソフトウエア(ハイパーバイザ)に仮想マシンの生成と削除を要求するコマンドを送信して、仮想マシンの配備や削除を実行する。
【0018】
監視サーバ22は、複数のインフラ監視定義パターン25から選択されたパターンで業務システム1(SYS1)、2(SYS2)のインフラレベルの監視を行う。また、監視サーバ22は、カスタマイズされたアプリ監視定義26に基づいてアプリケーションレベルの監視が必要と判断された業務システムを、アプリ簡易監視またはアプリ詳細監視を行う。
【0019】
顧客X社環境10では、顧客X社の新たな業務システム3を配備する場合、顧客Xは、端末15から管理サーバ21に業務システム3のアプリ開発及びテスト環境11の配備を依頼し、配備されたアプリ開発及びテスト環境11の仮想マシンによるシステムで、アプリケーションの開発と単体でのテストを行う。そして、アプリ開発とテストが終了すると、顧客Xは、端末15から監理サーバ21に業務システム3の実行環境12の配備を依頼し、配備された実行環境12での最終テストを行う。この業務システムの実行環境12の配備の段階を、本明細書ではアプリケーションのリリースと称する。
【0020】
このリリースの段階以降で、業務システム3が本格稼働する前に、クラウド事業者は、顧客Xから新業務システム3のアプリ詳細監視を要求される場合がある。その場合、クラウド事業者は、短時間で、実行環境12の業務システム3のアプリ監視定義を設計し評価することが求められる。そのため、クラウド事業者は、管理サーバ21を介して、業務システム3の実行環境12の仮想マシンVMを複写して業務システム3のテスト環境13を配備し、監視サーバ22が、テスト環境13のシミュレーションシステムに対して、予め設計したアプリ監視定義に基づく監視をシミュレーションする。そして、クラウド事業者は、監視結果に基づいてアプリ監視定義の妥当性を評価する。開発されたアプリケーションが属する業務システム3の構成は、構成情報取得コマンドにより管理サーバ21が取得可能であり、取得した構成情報に基づいて、監理サーバはシミュレーションシステム13を配備可能である。または、管理サーバ21が、業務システム3の本番環境12のイメージファイルを取得できる場合は、そのイメージファイルの複写の仮想マシンを起動してシミュレーションシステム13を配備可能である。
【0021】
シミュレーションシステム13は、
図1のように顧客X社環境10内のリソースプール14を使用して配備される場合もあれば、
図2のようにクラウド事業者環境20内のリソースプール24を使用して配備される場合もある。
【0022】
そして、リリース後の業務システム3の実行環境12での最終テストが完了し、シミュレーションシステム13でのアプリ監視定義の評価結果がパスすると、業務システム3は実行環境12で本番稼働に移る。本番稼働では、監視サーバ22が、インフラ監視パターン25の所定の組み合わせのパターンでインフラレベルの監視を行うとともに、カスタマイズしたアプリ監視定義26によるアプリ監視を行う。
【0023】
一般に、顧客は、業務システムの運用監視ポリシーを本番稼働の直前に決定する。したがって、顧客は、アプリケーションをリリースした段階では業務システムに対してアプリ詳細監視を行うか否かを未だ決定していないことが多い。一方、業務システムの本番環境12での最終テストが終了してから本番稼働までの期間はできるだけ短くする必要がある。
【0024】
したがって、運用監視を行うクラウド事業者は、アプリケーションがリリースされた段階で、業務システムの本番環境12の仮想マシンを複写してシミュレーションシステム13を配備することで、顧客からアプリケーションレイヤに対する監視リクエストを受けたら、即座にアプリ監視定義をシミュレーションシステム13で設計しテストし評価することができ、短期間で高品質なアプリ監視定義の作成を完了することができる。
【0025】
しかしながら、IaaS(Infrastructure as a Service)やPaaS(Platform as a Service)などのクラウドサービス環境では、様々な顧客の様々な業務システムでアプリケーションのリリースが頻繁に行われるので、多くのシミュレーションシステムを配備し保持する必要がある。その結果、監視サービスのために潤沢なハードウエアリソースが必要となり、コストの高いサービスとなる。
【0026】
アプリケーションレイヤまで監視するケースは、業務システムの重要度が高いケースが一般的である。そこで、業務システムのリソース消費量のような単一の指標で業務システムの重要度を判定し、重要度が高いと判定された業務システムについてのみアプリケーションのリリース段階でシミュレーションシステムを配備することで、監視サービスのためのリソース使用量を大幅に節約できる。
【0027】
しかし、クラウドサービス環境では、様々の顧客の様々の業務システムが稼働しており、業務システムの重要度の評価指標は千差万別であり、リソース消費量の単一指標による業務システムのアプリ詳細監視の要否判定は精度が低い。その結果、アプリ詳細監視が不要な業務システムだがリソース消費量が大きいためシミュレーションシステムを配備して無駄なリソースを消費したり、逆に、アプリ詳細監視が必要な業務システムだがリソース消費量が小さいためシミュレーションシステムを配備せず、アプリ監視定義の策定に長い時間を要するケースが頻発する。
【0028】
[第1の実施の形態]
図3は、本実施の形態におけるクラウドサービス環境のハードウエアリソースの一例を示す図である。
図3は、ハードウエアリソースのうち物理マシン上に構築された仮想マシン環境と物理マシン環境とを示す。物理マシンを構成する実ハードウエアR_HWは、CPU(Central processing unit)、メインメモリMEM、ネットワークインタフェースNICと、HDDやSDDなどの大容量の補助記憶装置34を有する。
【0029】
補助記憶装置34には、ホストOSや仮想化ソフトウエアであるハイパーバイザHPVなどが記憶され、メインメモリMEMに展開されてCPUにより実行される。物理マシン環境32では、ホストOS(H_OS)とアプリケーションAPL_3がCPUにより実行される。一方、仮想マシン環境30では、ハイパーバイザHPVがCPUにより実行されて、図示しない仮想マシン構成情報に基づいて実ハードウエアR_HWを仮想化し、仮想ハードウエアV_HW_1、V_HW_2を各仮想マシンVM_1、VM_2に割り当てる。そして、仮想マシンVM_1では、仮想ハードウエアV_HW_1上でゲストOS(G_OS_1)とアプリケーションAPL_1が実行され、仮想マシンVM_2では、仮想ハードウエアV_HW_2上でゲストOS(G_OS_2)とアプリケーションAPL_2が実行される。
【0030】
ハイパーバイザHPVが仮想マシンVM_1を最初に起動した際にゲストOS(G_OS_1)とアプリケーションAPL_1を初期化すると、補助記憶装置34内に仮想マシンVM_1のイメージファイルVM_1_IMGが生成される。仮想マシンVM_2を最初に起動した場合も同様に補助記憶装置34内に仮想マシンVM_2のイメージファイルVM_2_IMGが生成される。
【0031】
図1、2で示した顧客X社環境10内の業務システムSYS1,SYS2,12、アプリ開発及びテスト環境11、シミュレーションシステム13を構成する仮想マシンVMは、
図3で示した仮想マシンVM_1, VM_2などに対応する。同様に、クラウド事業者環境20内の管理サーバ21や監視サーバ22も、
図3の仮想マシンVM_1,VM_2などにより構成される。
【0032】
したがって、業務システムのアプリケーションプログラムや、開発中のアプリケーションまたシミュレーションシステムのアプリケーションは、仮想マシンVM_1,VM_2内のアプリケーションAPL_1,APL_2に対応する。また、管理サーバ21の管理用アプリケーションや監視サーバ22の監視用アプリケーションも、仮想マシンVM_1,VM_2内のアプリケーションAPL_1,APL_2に対応する。
【0033】
図4は、本実施の形態における監視サーバが実行するプログラム群を示す図である。
図4では、シミュレーションシステム13、23が顧客X社環境10またはクラウド事業者環境20内のハードウエアのソースプールにより構築される。
【0034】
クラウド事業者環境20内に配備されている監視サーバ22は、既存の業務システムの内アプリ詳細監視が必要と判断された業務システムについて、予め定めたアプリ監視定義に基づいてアプリ監視を行うアプリケーション監視プログラムPRG1を実行する。さらに、監視サーバ22は、リリース検知プログラムPRG2を実行して、顧客X社が新たな業務システム3の開発中または改良中のアプリケーションのリリースを検出する。
【0035】
リリースの通知に応答して、監視サーバ22は、シミュレーションシステム配備プログラムPRG3を実行して、リリースされた新業務システム3のアプリ詳細監視が要求されるか否かを判定する。この判定方法については後で詳述するが、概略を述べると、既存業務システムの所定の構成要素の有無と、CPUやメモリなど構成要素の性能因子とを含む構成要素群と、同じく既存業務システムのアプリ詳細監視要否との対応付けに基づいて、新業務システムの構成要素群と類似する構成要素群を有する既存業務システムのアプリ詳細監視要否を特定し、特定したアプリ詳細監視要否を新業務システムのアプリ詳細監視要否として利用する。
【0036】
そして、シミュレーションシステム配備プログラムPRG3は、アプリ詳細監視要と判定した場合、リソースプールのハードウエアを使用してリリースしたアプリケーションの新業務システム3を複写したシミュレーションシステム13、23を配備する。このシミュレーションシステムの配備は、業務システム3のイメージファイルを取得できる場合はイメージファイルを複写して起動することにより行うことができる。または、業務システム3の仮想マシンの構成情報(CPUのクロック数、メモリ容量、HDD容量、通信帯域、ゲストOS、アプリケーションなどの情報)を取得できる場合は、その構成情報に基づいてシミュレーションシステムを起動、生成することができる。
【0037】
クラウド事業者は、開発したアプリケーションをシミュレーションシステムで実行しながら、設計したアプリ監視定義に基づいてアプリ監視をアプリケーション監視プログラムPRG1により実行する。アプリ監視定義は、例えば、監視する稼働時間帯、ウエブアクセスに割り当てるプロセス数の上限値及び下限値、CPU使用率の上限値及び下限値、仮想メモリ容量の上限値及び下限値などである。これらの監視定義に基づいて、例えば設定した監視時間帯で、プロセス数、CPU使用率、仮想メモリの容量が上限値と下限値を超えて想定範囲外になった時に警告を出力するなどのアプリ詳細監視が行われる。アプリ監視定義の作成ツールPRG4は、例えば、アプリケーション監視プログラムPRG1に属するツールの一つである。
【0038】
そして、アプリ監視定義の検証結果が良好の場合は、アプリケーション監視プログラムでのアプリ監視定義の作成終了となるので、監視サーバ22は、シミュレーション完了検知プログラムPRG5を実行して、アプリ監視定義が確定したことを検知する。
【0039】
次に、本実施の形態について、クラウドサービスにおける新業務システムの配備工程全体を説明し、シミュレーションシステムの配備プログラムの処理と、アプリ監視定義について説明する。
【0040】
[新業務システムの配備工程]
図5は、クラウドサービスにおける新業務システムの配備工程全体を示すフローチャート図である。
図1、2で説明した通り、クラウドシステムの顧客は、顧客環境10内の開発環境11でアプリケーションを開発し、アプリケーション単体の動作テストを行う(S10)。アプリケーションの開発と単体動作テストが完了すると、顧客は、顧客環境10内に新業務システム3の本番環境12を配備する(S11)。この新業務システム3には、開発した新アプリケーションが仮想マシンにより実行される。これにより、アプリケーションはリリースされ(S12)、本番環境12の新業務システムの最終テストに入る(S13)。
【0041】
本実施の形態では、監視サーバ22が、リリース検知プログラムPRG2を実行して上記のアプリケーションのリリースを検出し、アプリリリースの通知に応答して、シミュレーションシステム配備プログラムPRG3を実行して、新業務システムの新アプリケーションについてアプリ詳細監視要否を自動判定する(S14)。アプリ詳細監視要否の自動判別により、アプリ詳細監視が必要と判別すると(S15のYES)、監視サーバ22が、シミュレーションシステム配備プログラムPRG3を実行して、新業務システム3のシミュレーションシステム13、23を配備する(S16)。
【0042】
上記の通り、監視サーバが上記のアプリ詳細監視要否の自動判定工程S14を行い、高精度にアプリ詳細監視が必要か否かを予測し、アプリ詳細監視要と判定された新業務システムについて、顧客環境10またはクラウド事業者環境20内のリソースプールを利用してシミュレーションシステムを配備する。これらの工程S14,S15,S16については、後述するシミュレーションシステムの配備プログラムの処理で詳述する。
【0043】
アプリリリース後の新業務システムの最終テスト中または終了時に、新業務システムの顧客からアプリ詳細監視の指示があると(S17のYES)、クラウド事業者は、あらかじめ配備済みのシミュレーションシステムでアプリ監視定義を作成し、監視サーバ22のアプリケーション監視プログラムを実行して、作成したアプリ監視定義に基づきアプリ詳細監視テストを行う(S18)。具体的にはシミュレーションシステムが新アプリケーションを実行し、監視サーバがアプリ監視定義に基づいてアプリ詳細監視を行う。そして、監視結果を新業務システムの顧客と共に評価し、作成した監視定義の妥当性を確認する(S19)。監視結果が妥当でない場合、アプリ監視定義を再作成し、上記のアプリ詳細監視テストS18と監視定義の妥当性の確認S19とを繰り返す。
【0044】
監視定義が承認されると(S19のYES)、監視サーバのアプリケーション監視プログラムPRG1の設定画面でクラウド事業者によるアプリ監視定義設定操作がなされ、シミュレーション完了検知プログラムPRG5がシミュレーション完了を検知する(S20)。その結果、承認されたアプリ監視定義が新業務システムのアプリ監視定義として監視サーバ22に設定され、監視サーバ22によるアプリ詳細監視が開始される(S21)。
【0045】
上記のアプリ監視定義の作成と承認工程S18,S19については、後で詳述する。
【0046】
アプリリリース(S12)後に、またはアプリ監視を開始するときに、監視サーバ22に自動でまたは人手で選択されたインフラ監視定義が設定され、監視サーバ22はそのインフラ監視定義に基づくインフラ監視を開始する(S22)。また、監視サーバによる監視開始(S21,S22)と同時に、新業務システム3の本番稼働が開始され業務が開始される(S23)。そして、シミュレーションシステム配備プログラムが、シミュレーションシステムを削除する(S24)。
【0047】
[シミュレーションシステムの配備プログラムの処理]
図6は、シミュレーションシステムの配備プログラムの処理を示すフローチャート図である。シミュレーションシステム配備プログラムPRG3は、
図6の工程S14,S15,S16の処理を実行する。
【0048】
監視サーバ22は、シミュレーションシステム配備プログラムPRG3を実行して、以下の処理を実行する。まず、監視サーバ22は、予め、既存業務システムのアプリ詳細監視要否指標パターンを自動抽出する(S30)。アプリ詳細監視要否指標パターンは、業務システムの所定の構成要素群(構成要素及び構成要素の機能因子)の組み合わせである。
【0049】
上記のアプリ詳細監視要否指標パターンの抽出は、(1)各既存業務システムがアプリ詳細監視要否指標パターンの各指標(構成要素)に該当するか否かを判定し、(2)各既存業務システムがアプリ詳細監視をしているか否かを、運用管理の内部データベースから抽出し、(3)各既存業務システムの該当する指標パターン(構成要素群)とアプリ詳細監視の要否とを関連付けたアプリ詳細監視要否指標パターンを生成し、監視サーバ22を構成する物理マシンのメモリMEM内に記憶する、ことで行われる。
【0050】
図8は、アプリ詳細監視要否指標パターンの各指標(構成要素)とその概要を示す図表である。
図8には、指標(構成要素)a〜kの合計11個の例が示される。但し、これらの指標(構成要素)は一例であり、これらに限定されることなく、各顧客毎に異なる組み合わせであっても良い。
【0051】
まず指標(構成要素)a〜eは、指標の構成的因子であり、所定の構成要素の有無を示す。構成要素aは、業務システムのウエブサーバのフロント位置に負荷分散装置を有する構成である。すなわち、クラウドサービスを利用する業務システムは、一般に、業務システムにアクセスするためにインターネットやイントラネットなどのネットワークを介してアクセスの要求を受け付ける複数のウエブサーバを有する。そして、ウエブサーバは、外部から受信した要求を、業務サービスを構成する仮想サーバに依頼する。ウエブサーバのレスポンス性能を上げるために、ウエブサーバの前段に設けたSLB(サーバレベルバランサー)が複数のウエブサーバに受信要求を適切に分配する。したがって、構成要素aは、ウエブサーバのフロントに設けられる負荷分散装置である。
【0052】
構成要素bは、ウエブサーバのフロントにファイアウオールを有する構成である。前述のとおりウエブサーバは、外部から受信した要求を業務サービスシステムを構成する仮想サーバに依頼する。そして、業務サービスの仮想サーバを外部からのアクセスから保護するために、ファイアウオールサーバが配置される。したがって、構成要素bは、ウエブサーバのフロントに設けられるファイアウオールである。
【0053】
構成要素cは、業務サービスシステムに設けられるデータベースサーバに対して読み出しと書き込みの両方が行われる構成である。データベースサーバは、業務システムが基幹業務の場合、読み出しと書き込みが頻繁に行われる。一方、基幹業務でない場合、例えば月次処理で情報収集のためにデータの参照だけが行われ、データベースサーバはもっぱら読み出しだけが行われ書き込み頻度が低い。
【0054】
構成要素dは、災害対策オプションの構成である。たとえば、業務システムが、災害発生時には別の環境で業務サービスを継続する機能を有する場合、災害対策オプションの構成を有する。したがって、構成要素dは、災害発生時に業務サービスの継続が可能な機能を有することである。
【0055】
構成要素eは、業務システムがクラスタ構成により二重化されていることである。業務システムを構成する仮想サーバ群がクラスタ構成により二重化されている場合、一方のクラスタによる業務システムが停止しても、もう一方のクラスタによる業務システムが業務を継続できる。したがって、構成要素eは、業務システムが二重化され何らかのエラー発生時に業務継続が可能な機能を有することである。
【0056】
次に、指標(構成要素)f〜kは、指標の性能的因子であり、構成要素の通常状態での性能を示す。構成要素fは、CPU使用率(例えば単位時間あたりの使用クロック数)がその顧客のアプリ詳細監視している業務システムの最低値より高い構成である。
【0057】
構成要素gは、総メモリ量であり、業務システムに割り当てているメモリ量(容量)が、その顧客のアプリ詳細監視している業務システムの最低値より高い構成である。
【0058】
構成要素hは、通信回線の帯域サイズであり、通信回線の帯域サイズが、その顧客のアプリ詳細監視している業務システムの最低値より高いという構成である。
【0059】
構成要素iは、ストレージの使用量、使用率であり、ストレージの使用量(容量)、使用率(単位時間当たりの総アクセス時間の比率)が、その顧客のアプリ詳細監視している業務システムの最低値より高いという構成である。
【0060】
構成要素jは、ネットワークインタフェース数であり、業務システムに設定されているネットワークインタフェース、例えば仮想NIC(Network Interface Card)の個数が、その顧客のアプリ詳細監視している業務システムの最低値より大きいという構成である。
【0061】
最後に、構成要素kは、ウエブサーバの要求を受け付けるプロセス数であり、稼働中に要求を受け付けたプロセス数が想定範囲外に変動するという構成上の指標である。
【0062】
図9は、指標(構成要素)を取得する方法例を示す図表である。監視サーバ22は、シミュレーションシステム配備プログラムを実行して、
図8に示したアプリ詳細監視要否指標パターンの各指標(構成要素)を何らかの方法で取得し、既存の業務システムがそれぞれの指標(構成要素)に該当するか否かを判定する。
図9は、その取得方法例を示す。
【0063】
構成要素aの負荷分散装置、構成要素bのファイアウオールは、顧客の稼働中の業務システムにおいて、インベントリ情報収集コマンド(例えば、snmpwalkコマンド)により業務システムの構成情報(MIB)を取得することができる。構成要素cのデータベースサーバへの読み出しと書き込みの実行の有無や頻度については、読み出しと書き込みのログから取得することができる。
【0064】
また、構成要素dの災害対策オプションと、構成要素eの業務システムの二重化の有無については、クラウドサービスのAPI(Application Program Interface)で取得できる顧客の環境設定プロパティを取得し、その環境設定プロパティからオプション情報を取得することができる。
【0065】
次に、性能的因子である構成要素f(CPU使用率)、g(総メモリ量)、h(通信回線の帯域)は、業務システムの仮想マシンのゲストOSから取得することができる。また、構成要素i(ストレージの使用率、使用量)は、ストレージから取得できる。そして、構成要素j(ネットワークインタフェース数)は、インベントリ情報収集コマンド(snmpwalkコマンド)で取得できる。さらに、構成要素k(ウエブサーバの要求受付用プロセス数の変動大)については、プロセス数収集コマンドでプロセス数の変動を取得可能である。
【0066】
監視サーバ22は、シミュレーションシステム配備プログラムを実行し、前述のとおり各業務システムがアプリ詳細監視要否指標パターンの各指標(構成要素)に該当するか否かを判定し、さらに、各業務システムがアプリ詳細監視をしているか否かを運用管理の内部データベースから抽出する。そして、各業務システムの該当する指標パターン(構成要素群)とアプリ詳細監視の要否とを関連付けたアプリ詳細監視要否指標パターンを生成し、監視サーバの物理マシンのメモリ内に記憶する。
【0067】
図10は、既存業務システムのアプリ詳細監視要否指標パターンの一覧の例を示す図である。
図10の一覧50には、6つの既存業務システムについて指標(構成要素)パターン(図中○が記載された構成要素)と、各業務システムのアプリ詳細監視要否が関連付けられている。したがって、ある顧客の既存業務システムについてのアプリ詳細監視要否指標パターンと監視要否の一覧(集合)50は、顧客固有のアプリ詳細監視要否判定基準に関する構成要素の特徴を有している。
【0068】
図10のアプリ詳細監視要否指標パターンの一覧の顧客は、構成要素a,e,k(ウエブサーバの負荷分散装置、業務システムの二重化、ウエブサーバの要求受付用プロセス数の変動大)に該当する業務システム2,3,4全てについてアプリ詳細監視要に設定している。
【0069】
この顧客の業務システム2,3,4は、構成要素aに該当するので、ウエブサーバの負荷分散を行ってレスポンスを重視し、業務システムをクラスタによる二重化によりトラブル発生時の堅牢性を高くし、しかし、プロセス数の変動が激しいという構成上の特徴を有する。また、業務システム2,3,4は、構成要素f、g、h、iに該当しないのでハードウエアリソースの消費量が少ないという特徴を有する。
【0070】
したがって、この顧客は、業務システム2,3,4において、ハードウエアリソースの消費量が少ないにもかかわらず、レスポンス重視、堅牢性重視であり、アクセス受付プロセス数の変動が大きいため、アプリ詳細監視を希望している、とみなすことができる。
【0071】
一方、構成要素b、c(ファイアウオール、データベースサーバへの読み出し/書き込みの両方あり)に該当する業務システム1,5について、業務システム1はアプリ詳細監視要に設定しているが、業務システム5は不要に設定している。そして、構成要素g、h(総メモリ量、通信回線の帯域サイズ)だけに該当する業務システム6にはアプリ詳細監視不要に設定している。
【0072】
図6に戻り、監視サーバ22は、シミュレーションシステム配備プログラムを実行して、新業務システムのアプリケーションのリリース通知を受信すると(S31(S12))、アプリ監視要否の自動判定(S14_1,S14_2)を行う。アプリ監視要否の自動判定は、リリースされた新業務システムの指標(構成要素)パターンを抽出する工程(S14_1)と、新業務システムの指標パターンと顧客固有の既存業務システムのアプリ詳細監視要否指標パターンとを比較し、新業務システムの指標パターンと一致する指標パターンの監視要否を抽出する工程(S14_2)とを有する。工程S14_1では、工程S31で説明したのと同じ方法で、新業務システムが各指標(構成要素)に該当するか否かを判定する。一方、工程S14_2については、後で詳述する。
【0073】
そして、監視サーバは、一致する指標パターンが監視要の場合、新業務システムはアプリ詳細監視要に設定される蓋然性が高いと予測し(S15のYES)、新業務システムのシミュレーションシステムを配備する(S32(S16))。この予測は、顧客固有のアプリ詳細監視要の指標パターンと一致することに基づいて行われるので、その予測精度は高い。
【0074】
また、新業務システムのシミュレーションシステムの配備工程は、監視サーバ22が管理サーバ21に新業務システムのクローンの仮想マシン群を配備する要求を行うことにより行われる。たとえば、管理サーバ21は、新業務システムの構成情報ファイルを取得し、それに基づいて新業務システムのクローンの仮想マシン群VMを配備することができる。または、管理サーバ21は、新業務システムのイメージファイルをコピーし、コピーのイメージファイルの仮想マシン群を起動することで、新業務システムのクローンの仮想マシン群を配備する。
【0075】
シミュレーションシステムが配備されると、クラウド事業者は、シミュレーションシステムのアプリ監視定義を作成し、監視サーバ22がアプリ詳細監視を実行し、監視結果を顧客と共に検証する。そして、アプリ監視定義の検証結果が良好の場合、アプリ監視定義の作成工程が終了し、監視サーバ22は、シミュレーション完了検知プログラムPRG5からシミュレーション完了通知を受信する(S33のYES)。
【0076】
これに応答して、監視サーバ22は、シミュレーションシステム配備プログラムの実行により、作成したアプリ監視定義を新業務システムのアプリ監視プログラムに設定する(S34)。この設定により、監視サーバ22は、新業務システムの本番稼働において、アプリ監視プログラムを実行することで、設定したアプリ監視定義に基づくアプリ詳細監視を実行することができる。
【0077】
監視サーバ22は、新業務システムの本番稼働が開始されると(S35のYES)、シミュレーションシステムを削除する(S36(S24))。
【0078】
図7は、シミュレーションシステム配備プログラムにおける工程S14_2,S32,S36の詳細処理を示すフローチャート図である。まず、
図6の工程S14_2は、
図7の工程S14_2〜S14_5で構成される。すなわち、監視サーバ22は、
図7において、新業務システムの指標パターンと顧客固有の既存業務システムのアプリ詳細監視要否指標パターンとを比較し、一致するか否かの判定を行い(S14_2)、一致する指標パターンがある場合(S14_3のYES)、アプリ詳細監視要のパターンとのみ一致するか(S14_4)、アプリ詳細監視不要のパターンとのみ一致するか(S14_5)を判定する。
【0079】
図11は、新業務システムの指標パターンの3つの例を示す図である。
図11に示した業務システム名、業務システム101は、構成要素aとeが該当する指標パターン51を有する。この指標パターン51は、
図10の既存業務システムのアプリ詳細監視要否指標パターンの業務システム2,3,4と一致し、それらの業務システム2,3,4は全て監視要に設定されている。したがって、新業務システム101は、
図7における新業務システムの指標パターンがアプリ詳細監視要のパターンとのみ一致する場合(S14_4のYES)に該当する。
【0080】
そこで、
図7に示されるとおり、監視サーバ22は、アプリ詳細監視要否指標パターン(
図10)に、新業務システム101の指標パターンを監視要で仮登録する(S32_1)。すなわち、
図11の業務システム101の監視要否は監視要に仮登録される。そして、監視サーバ22は、業務システム101のクローンのシミュレーションシステムの仮想マシンを優先度「高」で配備するよう、管理サーバ21に要求する(S32_2)。この優先度は、限りのあるシミュレーション用のリソースプールを有効に活用するための指標であり、優先度が高い業務システムのクローンは、優先度が低い業務システムのクローンより優先してリソースプール内に保持される。
【0081】
次に、
図11に示した業務システム名、業務システム102は、構成要素bとcが該当する指標パターン52を有する。この指標パターン52は、
図10の既存業務システムのアプリ詳細監視要否指標パターンの業務システム1,5と一致し、それらの業務システム1,5は一部監視要に、一部監視不要に設定されている。したがって、新業務システム102は、
図7における新業務システムの指標パターンがアプリ詳細監視要のパターンとのみ一致する場合でもなく(S14_4のNO)、アプリ詳細監視不要のパターンとのみ一致する場合でもない(S14_5のNO)。そこで、
図7に示されるとおり、監視サーバ22は、アプリ詳細監視要否指標パターン(
図10)に、新業務システム102の指標パターンを監視要で仮登録する(S32_4)。そして、監視サーバ22は、業務システム102のクローンのシミュレーションシステムの仮想マシンを優先度「低」で配備するよう、管理サーバ21に要求する(S32_5)。
【0082】
さらに、
図11に示した業務システム名、業務システム103は、構成要素gとhが該当する指標パターン53を有する。この指標パターン53は、
図10の既存業務システムのアプリ詳細監視要否指標パターンの業務6と一致し、業務6は監視不要に設定されている。したがって、新業務システム103は、
図7におけるアプリ詳細監視不要のパターンとのみ一致する場合である(S14_5のYES)。そこで、
図7に示されるとおり、監視サーバ22は、アプリ詳細監視要否指標パターン(
図10)に、新業務システム103の指標パターンを監視不要で仮登録する(S32_3)。そして,監視サーバ22は、新業務システム103のクローンのシミュレーションシステムの仮想マシンを配備することは行わない。
【0083】
また、
図7に示されるとおり、新業務システムの指標パターンが、既存業務システムのアプリ詳細監視指標パターンのいずれとも一致しない場合(S14_3のNO)、監視サーバは、アプリ詳細監視要否指標パターン(
図10)に、新業務システム102の指標パターンを監視要で仮登録する(S32_4)。そして、監視サーバ22は、業務102のクローンのシミュレーションシステムの仮想マシンを優先度「低」で配備するよう、管理サーバ21に要求する(S32_5)。既存業務システムの指標パターンのいずれとも一致しない場合、過去におけるアプリ詳細監視の要否判定を利用することができない。そこで、監視要に仮登録し、優先度「低」でクローンを配備する。
【0084】
上記の監視要否の仮登録は、現時点では顧客からアプリ詳細監視の要否が確定していないためである。本番稼働までにはアプリ詳細監視の要否が確定するので、その時点で、予測が正しければそのままアプリ詳細監視の要否が本登録され、予測が誤りであれば仮登録のアプリ詳細監視の要否は変更される。
【0085】
次に、
図7において、監視サーバ22は、シミュレーションシステム配備プログラムを実行して、シミュレーションシステムを配備するリソースプールの限りある容量を有効利用するために、リソースプールが一杯の場合(S32_6のYES)、配備済みのシミュレーションシステムを優先度と配備した日時とに基づいて、削除する(S32_7)。
【0086】
例えば、シミュレーションシステムを配備するリソースプール内に優先度高の新業務システムと優先度低の新業務システムのクローンが配備されている場合、監視サーバ22は、優先度低の新業務システムのクローンのうち配備日時が古い順に削除してリソースプールに空きを作成する。リソースプール内に優先度高の新業務システムのクローンだけが配備されている場合、監視サーバ22は、配備日時が古い順に削除する。
【0087】
図12は、シミュレーションシステム配備プログラムが管理するシミュレーションシステム配備管理テーブル例を示す図である。監視サーバ22は、
図12に示した配備管理テーブルを維持して、シミュレーションシステムの配備を管理する。
図12のシミュレーションシステム配備管理テーブルには、シミュレーションシステムの仮想マシンID(シミュレーション用VM ID)と、本番稼働する業務システムの仮想マシンID(本番VM ID)と、業務システム名と、リリース日時と、配備の優先度とが示されている。そして、前述の業務システム101,102が優先度高、優先度低でそれぞれ配備管理テーブルに登録され、配備されている。さらに、
図12には、業務システム106が新たに優先度高で登録追加されることが示される。
【0088】
監視サーバ22は、前述の優先度と配備日時に基づいて配備済みシミュレーションシステムの仮想マシンを削除する場合、この配備管理テーブルから削除し、管理サーバ21に削除を依頼する。
【0089】
図7の工程S32_6,S32_7は、工程S14_2の前の段階で行うようにしても良い。
【0090】
[アプリ監視定義]
次に、
図5におけるアプリ監視定義の作成工程S18,S19について具体例を示して説明する。
図13は、アプリ監視定義の作成工程のフローチャート図である。
図14、
図15は、監視サーバ22でのアプリ監視定義の設定画面例を示す図である。
【0091】
監視サーバ22が、アプリ監視定義作成プログラムPRG4(
図4参照)を実行し、クラウド事業者がアプリ監視定義画面でアプリ監視定義を設計する(S180)。
【0092】
図14の画面例には、アプリケーションの詳細監視の稼働時間帯を設定する画面40が示される。この画面40によれば、アプリ詳細監視の稼働時間帯が開始時刻と停止時刻で設定される。開始時刻と停止時刻のペアを複数設定して、例えば昼間の稼働時間帯と夜間の稼働時間帯を個別の設定するようにしてもよい。
【0093】
図14の画面例には、アプリ監視の詳細設定の画面42も示される。この画面42によれば、プロセス数の監視における上限値の設定と下限値の設定を行うことができる。
【0094】
図15の画面例には、CPU使用率とメモリ容量の監視用の閾値を設定する画面44が示される。この画面44によれば、CPU使用率のタブを選択した状態で、異常を出力する場合の上限値と下限値の設定及び、警告を出力する場合の上限値と下限値の設定を行うことができる。メモリ容量のタブを選択すると、CPU使用率と同様のメモリ容量の異常または警告を出力する場合の上限値と下限値の設定画面が表示される。
【0095】
図13に戻り、監視サーバ22は、管理サーバ21にシミュレーションシステムを起動させアプリを実行させるよう要求し、設定したアプリ監視定義でシミュレーションシステムについてアプリ詳細監視を実行する(S181)。このアプリ詳細監視では、アプリ監視定義で設定した警告メッセージや異常メッセージなどが出力される。
【0096】
このようなアプリ詳細監視による監視結果(メッセージなど)について、顧客と共有して監視結果が良好か否か判定される。この判定は、例えばクラウド事業者と新業務システムの顧客とが共同して行う。そして、監視結果が良好と判定されると(S182のYES)、クラウド事業者はアプリ監視定義画面上でアプリ監視定義終了操作を行う(S184)。この終了操作により、シミュレーション完了検知プログラムPRG5(
図4参照)は、シミュレーションが完了したことを検知する。
【0097】
監視結果が良好と判定されない場合(S182のNO)、クラウド事業者は、顧客と協議して、アプリ監視定義画面上で監視定義の設定を変更する(S183)。そして、監視サーバ22は、変更されたアプリ監視定義に基づくアプリ詳細監視テストを再度行う(S181)。
【0098】
以上のとおり、アプリ監視定義画面上で監視定義の設定を変更しながら、アプリ詳細監視のテストを繰り返すことで、適切なアプリ監視定義を作成することができる。
【0099】
[第2の実施の形態]
第2の実施の形態では、監視サーバ22は、
図6のシミュレーションシステム配備プログラムの実行中、既存業務システムのアプリ詳細監視要否指標パターンを抽出する工程S30にて、抽出した指標パターンの監視要否判定に所定の補正を加える。
【0100】
既存業務システムのアプリ詳細監視要否指標パターンの補正は、既存業務システムが例外的な理由でアプリ詳細監視要に設定されている場合は、監視不要に変更し、例外的な理由でアプリ詳細監視不要に設定されている場合は、監視要に変更する。このように補正することで、新業務システムのアプリ詳細監視要否指標パターンの監視要否を、例外的な理由を問うことなく、既存業務システムの監視要否に基づいて判定することができる。
【0101】
図16は、工程S30におけるアプリ詳細監視要否の補正工程での処理を示すフローチャート図である。既存業務システムについてアプリ詳細監視要と設定されている場合(S301のYES)、アプリケーションの異常終了が頻繁に発生しているか、アプリケーションのリリース回数が多いなどの例外的な理由がある場合(S302のYES)、アプリ詳細監視不要に変更する(S303)。
【0102】
このような例外的な理由は、アプリケーションの品質が悪く、異常終了が頻繁に発生したり、デバックとリリースを繰り返したりしていることである。このような理由がある場合、業務自体の重要度が低い場合でも、アプリケーションの停止を早期に検知し、再起動操作などが必要になるので、アプリ詳細監視要に設定されていると考えられる。したがって、補正工程でアプリ詳細監視不要に変更する。
【0103】
また、既存業務システムについてアプリ詳細監視不要と設定されている場合(S304のYES)、アプリの異常終了時に自動復旧(再起動)が行われているなどの例外的な理由がある場合(S305のYES)、アプリ詳細監視要に変更する(S306)。
【0104】
このような例外的な理由は、業務自体が重要などの理由で本来ならアプリ詳細監視が必要であるが、アプリケーションが異常終了すると自動復旧機能により業務システムが自動的に復旧するので、アプリ詳細監視不要に設定されていると考えられる。したがって、補正工程でアプリ詳細監視要に変更する。
【0105】
上記のような補正工程を加えることにより、既存業務システムのアプリ詳細監視要と不要の設定が例外的な理由により本来の要否と逆に設定されている場合、本来の要否に修正することができ、その後の新規業務システムのアプリ詳細監視要否判定を適切に行うことができる。
【0106】
以上の通り、本実施の形態によれば、顧客固有のアプリ詳細監視要否の判定基準に基づいて、新規業務システムのアプリ詳細監視要否の判定を行うことで、判定精度を高くすることができる。したがって、新規業務システムのアプリケーションがリリースされて最終段階のテストに入る際に、新規業務システムのクローンのシミュレーションシステムを予め配備しておき、最終段階のテスト中または本番稼働直前に顧客からアプリ詳細監視の要求がされた場合、短期間で監視定義を作成することができる。また、監視要否の判定精度が高いので、限られたリソースプールを効率的にシミュレーションシステムの配備に利用することができる。
【0107】
以上の実施の形態をまとめると,次の付記のとおりである。
【0108】
(付記1)
第1のシステムの第1の構成要素群を含む第1のシステム情報の入力を受け付け、
第2のシステムの第2の構成要素群と前記第2のシステムの監視に関する設定情報とを複数の第2のシステムについて記憶する記憶部を参照して、前記第1のシステム情報に含まれる前記第1の構成要素群と所定の類似関係を有する第2の構成要素群に対応する前記第2のシステムの監視に関する設定情報を特定し、
特定した前記設定情報を前記第1のシステムの設定情報として出力する、
処理をコンピュータに実行させるシステムの監視に関する設定支援プログラム。
【0109】
(付記2)
前記監視に関する設定情報は、システムが実行するアプリケーションの監視要否を含む、付記1に記載の設定支援プログラム。
【0110】
(付記3)
さらに、前記処理は、
前記所定の類似関係を有する第2のシステムの監視に関する設定情報が監視要の場合、前記第1のシステムに対応するシミュレーションシステムを構成する仮想マシンを配備する、付記2に記載の設定支援プログラム。
【0111】
(付記4)
さらに、前記処理は、
作成した監視定義に基づいて、前記シミュレーションシステムのアプリケーションの動作を監視する、付記3に記載の設定支援プログラム。
【0112】
(付記5)
前記配備する処理において、
前記所定の類似関係を有する複数の第2のシステムの監視に関する設定情報がすべて監視要の場合、前記第1のシステムに対応するシミュレーションシステムを構成する仮想マシンを、第1の優先度で配備し、
前記所定の類似関係を有する複数の第2のシステムの監視に関する設定情報の一部が監視要の場合、前記仮想マシンを、前記第1の優先度より低い第2の優先度で配備し、
前記配備した仮想マシンを、前記優先度と配備した日時とに基づいて、削除する、付記3に記載の設定支援プログラム。
【0113】
(付記6)
前記削除する処理において、前記優先度が低く配備した日時が古い仮想マシンから削除する、付記5に記載の設定支援プログラム。
【0114】
(付記7)
前記設定情報を特定する処理において、前記第1のシステム情報に含まれる前記第1の構成要素群と所定の類似関係を有する第2の構成要素群に対応する前記第2のシステムが見つからない場合、前記第1のシステムの設定情報を監視要の設定情報と特定する、付記2に記載の設定支援プログラム。
【0115】
(付記8)
さらに、前記処理は、
第2のシステムの第2の構成要素群と前記第2のシステムの監視に関する設定情報とを複数の第2のシステムについて抽出する処理を有する、付記1に記載の設定支援プログラム。
【0116】
(付記9)
前記第2のシステムが所定の条件を満たす場合、前記抽出した設定情報を変更する処理を有する、付記8に記載の設定支援プログラム。
【0117】
(付記10)
第1のシステムの第1の構成要素群を含む第1のシステム情報の入力を受け付け、
第2のシステムの第2の構成要素群と前記第2のシステムの監視に関する設定情報とを複数の第2のシステムについて記憶する記憶部を参照して、前記第1のシステム情報に含まれる前記第1の構成要素群と所定の類似関係を有する第2の構成要素群に対応する前記第2のシステムの監視に関する設定情報を特定し、
特定した前記設定情報を前記第1のシステムの設定情報として出力する、
処理を有する設定支援方法。
【0118】
(付記11)
プロセッサと、
記憶部とを有し、
前記プロセッサは、
第1のシステムの第1の構成要素群を含む第1のシステム情報の入力を受け付け、
第2のシステムの第2の構成要素群と前記第2のシステムの監視に関する設定情報とを複数の第2のシステムについて記憶する記憶部を参照して、前記第1のシステム情報に含まれる前記第1の構成要素群と所定の類似関係を有する第2の構成要素群に対応する前記第2のシステムの監視に関する設定情報を特定し、
特定した前記設定情報を前記第1のシステムの設定情報として出力する、
処理を実行するシステムの監視に関する設定支援装置。