(57)【要約】【課題】宣言的モデルで構築されるシステムの非機能要件に沿った監視定義を容易に生成できる監視定義生成装置を提供する。【解決手段】監視定義生成装置１０は、宣言的モデルと宣言的モデルと関係する非機能要件の基本情報と宣言的モデルおよび非機能要件の基本情報と関係する監視定義の基本情報とを含むテンプレートと所定の非機能要件を示す要件情報とを入力とし、要件情報と非機能要件の基本情報との差異を監視定義の基本情報に反映することによって宣言的モデルで使用される監視定義を生成する生成部１１を備える。【選択図】図１
2018147338.tif 000002
【特許請求の範囲】
【請求項１】
宣言的モデルと前記宣言的モデルと関係する非機能要件の基本情報と前記宣言的モデルおよび前記非機能要件の基本情報と関係する監視定義の基本情報とを含むテンプレートと所定の非機能要件を示す要件情報とを入力とし、前記要件情報と前記非機能要件の基本情報との差異を前記監視定義の基本情報に反映することによって前記宣言的モデルで使用される監視定義を生成する生成部を備える
ことを特徴とする監視定義生成装置。
【請求項２】
生成された監視定義が使用される宣言的モデルに基づいて構築されるシステムを前記監視定義を用いて監視する監視部を備える
請求項１記載の監視定義生成装置。
【請求項３】
生成された監視定義が使用される宣言的モデルに基づいてシステムを構築する構築部を備える
請求項１または請求項２記載の監視定義生成装置。
【請求項４】
非機能要件は、サービスレベルアグリメントで定義された要件である
請求項１から請求項３のうちのいずれか１項に記載の監視定義生成装置。
【請求項５】
宣言的モデルと前記宣言的モデルと関係する非機能要件の基本情報と前記宣言的モデルおよび前記非機能要件の基本情報と関係する監視定義の基本情報とを含むテンプレートと所定の非機能要件を示す要件情報とを入力とし、前記要件情報と前記非機能要件の基本情報との差異を前記監視定義の基本情報に反映することによって前記宣言的モデルで使用される監視定義を生成する
ことを特徴とする監視定義生成方法。
【請求項６】
生成された監視定義が使用される宣言的モデルに基づいて構築されるシステムを前記監視定義を用いて監視する
請求項５記載の監視定義生成方法。
【請求項７】
生成された監視定義が使用される宣言的モデルに基づいてシステムを構築する
請求項５または請求項６記載の監視定義生成装置。
【請求項８】
コンピュータに、
宣言的モデルと前記宣言的モデルと関係する非機能要件の基本情報と前記宣言的モデルおよび前記非機能要件の基本情報と関係する監視定義の基本情報とを含むテンプレートと所定の非機能要件を示す要件情報とを入力とし、前記要件情報と前記非機能要件の基本情報との差異を前記監視定義の基本情報に反映することによって前記宣言的モデルで使用される監視定義を生成する生成処理
を実行させるための監視定義生成プログラム。
【請求項９】
コンピュータに、
生成された監視定義が使用される宣言的モデルに基づいて構築されるシステムを前記監視定義を用いて監視する監視処理を実行させる
請求項８記載の監視定義生成プログラム。
【請求項１０】
コンピュータに、
生成された監視定義が使用される宣言的モデルに基づいてシステムを構築する構築処理を実行させる
請求項８または請求項９記載の監視定義生成プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、監視定義生成装置、監視定義生成方法および監視定義生成プログラムに関する。
【背景技術】
【０００２】
クラウドコンピューティング（以下、クラウドと呼ぶ。）基盤や仮想化基盤が利用されることに伴い、Infrastructure as Code(IaC)と呼ばれるソースコードでシステムを定義し、オーケストレータと呼ばれるツールでシステムを自動構築する方法が実現されている。
【０００３】
IaCの定義方法の例である宣言的モデルは、OpenStack（登録商標） HeatコンポーネントではHeat Orchestration Template(HOT)という書式で存在する。また、宣言的モデルは、AWS Cloudformation（登録商標）サービスではCloudFormation Template(CFN)という書式、Google Cloud Platform(GCP)（登録商標） Cloud Deployment Managerではテンプレート(template)という書式でそれぞれ存在する。
【０００４】
オーケストレータに対する宣言的モデルの定義は、変換ツール等が使用されることによって再利用される。しかし、宣言的モデルの定義は、そのままでは利用されない。なお、AWS（登録商標） CFNの記述は、OpenStack Hotと互換性がある。
【０００５】
上記の問題に対応するため、例えば、クラウドで稼働する業務システムのシステム構成を定義するための標準仕様であるOASIS(Organization for the Advancement of Structured Information Standards)（登録商標） TOSCA(Topology and Orchestration Specification for Cloud Applications)は、標準的な定義を策定することによって、システム構成の定義に移植性を持たせている。
【０００６】
宣言的モデルが使用される場合、通常テンプレートと呼ばれる宣言的モデルの汎用的な定義をシステム部門等が提供する。システム構築者は、提供されたテンプレートにパラメータを投入し、システムを構築する。
【０００７】
宣言的モデルのテンプレートの精度を向上させる技術として、特許文献１には宣言的モデルのチューニングをシステムの実行基盤に対して実行し、システムの構築結果を解析することによってテンプレートを改良する方法が記載されている。すなわち、特許文献１には、宣言的モデルを精製したり修正したりする宣言的モデルのチューニング方法が記載されている。
【先行技術文献】
【特許文献】
【０００８】
【特許文献１】特許第５２１６８５３号公報
【特許文献２】特開２０１６−１６７１７９号公報
【特許文献３】特許第４６６１７２２号公報
【発明の概要】
【発明が解決しようとする課題】
【０００９】
システム部門に所属する高度な技術を有する担当者が作成する汎用的なテンプレートには、一般的な監視設定の内容は組み込まれている。すなわち、宣言的モデルに一般的な監視設定は定義されている。
【００１０】
しかし、システム構築者が求める非機能要件に沿った監視設定の内容まではテンプレートに組み込まれていないことが多い。システム構築に使用される宣言的モデルには、構築されるシステムの非機能要件の情報も反映されていることが求められる。なお、システムの非機能要件は、例えばSLA(Service Level Agreement)で定義される。
【００１１】
すなわち、システム構築者には、実行環境や実行状況を総合的に考慮した上で宣言的モデルをチューニングすることが求められる。また、監視設定の定義は、宣言的モデルに定義されているシステム構成に依存している。よって、監視設定の定義は、システムの個々のリソースが考慮された上で作成されることが求められる。
【００１２】
図８は、宣言的モデルとSLAと監視設定との関係の例を示す説明図である。図８に示す宣言的モデルを用いて、ロードバランサ(LB)と、Webサーバ(Web)と、アプリケーションサーバ(AP)と、データベースサーバ(DB)とを含むシステムが構築される。図８に示すように、LB、Web、AP、およびDBの各通信ネットワーク機器に対して監視設定が求められる。
【００１３】
また、図８に示すように、LBとWebに関してオートスケーリングの監視設定、LBとAPに関して多重処理制御の監視設定、DBに関してクラスタリングの監視設定がそれぞれ求められる。また、システム全体に関してレスポンスタイムの監視設定が求められる。
【００１４】
また、図８に示すように、Webを構成するAP、ミドルウェア(MW)、パッチ(Patch)、およびOS(Operating System)に対して監視設定がそれぞれ求められる。すなわち、図８に示すように、SLAを監視するために様々な個所への多様な監視設定が求められる。
【００１５】
特許文献１に記載されているチューニング方法では、監視設定を定義することは想定されていない。すなわち、特許文献１に記載されているチューニング方法を使用するシステム構築者には、手動で監視設定を定義することが求められる。かつ、特許文献１に記載されているチューニング方法が、システムの初回の構築時までに精度が高い宣言的モデルの定義を生成することは困難である。
【００１６】
また、特許文献２には、監視設定の不足部分を自動補完するプロビジョニング支援装置が記載されている。しかし、特許文献２に記載されているプロビジョニング支援装置は、SLAが考慮された監視設定の内容を生成する装置ではなく、プロビジョニングを実行した後に監視設定の不足部分を補う装置である。すなわち、特許文献２に記載されているプロビジョニング支援装置も、システムの初回の構築時までに精度が高い宣言的モデルの定義を生成することは困難である。
【００１７】
また、特許文献３には、設定知識に基づいて監視設定の内容を自動生成する運用管理システムが記載されている。しかし、特許文献３に記載されている運用管理システムは、注目された１つの監視設定の内容を自動生成するシステムである。すなわち、特許文献３に記載されている運用管理システムが、宣言的モデルで定義されているシステム全体が考慮された監視設定の内容を自動生成することは困難である。
【００１８】
［発明の目的］
そこで、本発明は、上述した課題を解決する、宣言的モデルで構築されるシステムの非機能要件に沿った監視定義を容易に生成できる監視定義生成装置、監視定義生成方法および監視定義生成プログラムを提供することを目的とする。
【課題を解決するための手段】
【００１９】
本発明による監視定義生成装置は、宣言的モデルと宣言的モデルと関係する非機能要件の基本情報と宣言的モデルおよび非機能要件の基本情報と関係する監視定義の基本情報とを含むテンプレートと所定の非機能要件を示す要件情報とを入力とし、要件情報と非機能要件の基本情報との差異を監視定義の基本情報に反映することによって宣言的モデルで使用される監視定義を生成する生成部を備えることを特徴とする。
【００２０】
本発明による監視定義生成方法は、宣言的モデルと宣言的モデルと関係する非機能要件の基本情報と宣言的モデルおよび非機能要件の基本情報と関係する監視定義の基本情報とを含むテンプレートと所定の非機能要件を示す要件情報とを入力とし、要件情報と非機能要件の基本情報との差異を監視定義の基本情報に反映することによって宣言的モデルで使用される監視定義を生成することを特徴とする。
【００２１】
本発明による監視定義生成プログラムは、コンピュータに、宣言的モデルと宣言的モデルと関係する非機能要件の基本情報と宣言的モデルおよび非機能要件の基本情報と関係する監視定義の基本情報とを含むテンプレートと所定の非機能要件を示す要件情報とを入力とし、要件情報と非機能要件の基本情報との差異を監視定義の基本情報に反映することによって宣言的モデルで使用される監視定義を生成する生成処理を実行させることを特徴とする。
【発明の効果】
【００２２】
本発明によれば、宣言的モデルで構築されるシステムの非機能要件に沿った監視定義を容易に生成できる。
【図面の簡単な説明】
【００２３】
【図１】本発明による監視定義生成装置の第１の実施形態の構成例を示すブロック図である。
【図２】第１の実施形態の監視定義生成装置１０による生成処理の動作を示すフローチャートである。
【図３】本発明による構築システムの第２の実施形態の構成例を示すブロック図である。
【図４】改善前のデータモデルと改善後のデータモデルの例を示す説明図である。
【図５】改善後のデータモデルを基に生成されたデフォルトテンプレートの使用例を示す説明図である。
【図６】第２の実施形態の構築システム１００によるシステム構築処理の全体動作を示すアクティビティ図である。
【図７】第２の実施形態の監視定義生成コンポーネント１３１による監視定義生成処理の動作を示すアクティビティ図である。
【図８】宣言的モデルとSLAと監視設定との関係の例を示す説明図である。
【発明を実施するための形態】
【００２４】
実施形態１．
以下、本発明の実施形態を、図面を参照して説明する。図１は、本発明による監視定義生成装置の第１の実施形態の構成例を示すブロック図である。本発明による監視定義生成装置１０は、宣言的モデルと宣言的モデルと関係する非機能要件の基本情報と宣言的モデルおよび非機能要件の基本情報と関係する監視定義の基本情報とを含むテンプレートと所定の非機能要件を示す要件情報とを入力とし、要件情報と非機能要件の基本情報との差異を監視定義の基本情報に反映することによって宣言的モデルで使用される監視定義を生成する生成部１１（例えば、監視定義生成コンポーネント１３１）を備える。
【００２５】
以下、監視定義生成装置１０による生成処理を説明する。図２は、第１の実施形態の監視定義生成装置１０による生成処理の動作を示すフローチャートである。
【００２６】
生成部１１に、宣言的モデルと宣言的モデルと関係する非機能要件の基本情報と宣言的モデルおよび非機能要件の基本情報と関係する監視定義の基本情報とを含むテンプレートが入力される（ステップS11）。
【００２７】
次いで、生成部１１に、所定の非機能要件を示す要件情報が入力される（ステップS12）。
【００２８】
次いで、生成部１１は、要件情報と非機能要件の基本情報との差異を監視定義の基本情報に反映することによって宣言的モデルで使用される監視定義を生成する（ステップS13）。生成した後、監視定義生成装置１０は、生成処理を終了する。
【００２９】
そのような構成により、監視定義生成装置は、宣言的モデルで構築されるシステムの非機能要件に沿った監視定義を容易に生成できる。
【００３０】
また、監視定義生成装置１０は、生成された監視定義が使用される宣言的モデルに基づいて構築されるシステムを監視定義を用いて監視する監視部（例えば、監視設定コンポーネント１４１および監視コンポーネント１６０）を備えてもよい。
【００３１】
そのような構成により、監視定義生成装置は、利用者が要求する非機能要件を構築されたシステムが満たしているか否か監視できる。
【００３２】
また、監視定義生成装置１０は、生成された監視定義が使用される宣言的モデルに基づいてシステムを構築する構築部（例えば、宣言的モデル実行コンポーネント１４０）を備えてもよい。
【００３３】
そのような構成により、監視定義生成装置は、監視対象のシステムを構築できる。
【００３４】
また、非機能要件は、サービスレベルアグリメントで定義された要件でもよい。
【００３５】
そのような構成により、監視定義生成装置は、利用者が要求するSLAを構築されたシステムが満たしているか否か監視できる。
【００３６】
実施形態２．
［構成の説明］
次に、本発明の第２の実施形態を、図面を参照して説明する。図３は、本発明による構築システムの第２の実施形態の構成例を示すブロック図である。
【００３７】
図３に示す構築システム１００は、宣言的モデル、監視設定の定義、およびSLAが組み合わせられたデフォルトテンプレートを用いる。また、構築システム１００には、システム構築時に利用者が投入するシステムパラメータ、および構築されるシステムに要求されるSLAを示す情報が入力される。
【００３８】
図３に示す構築システム１００は、デフォルトテンプレートと入力された情報とを用いて、宣言的モデルを基にシステムを構築する時に求められる監視設定の定義を自動的に生成する機能を有する。
【００３９】
図３に示すように、構築システム１００は、宣言的モデル編集コンポーネント１１０と、リポジトリ１２０と、宣言的モデルオーケストレータ１３０と、宣言的モデル実行コンポーネント１４０と、実行環境１５０と、監視コンポーネント１６０と、サービスレベル管理コンポーネント１７０とを含む。
【００４０】
宣言的モデル編集コンポーネント１１０は、宣言的モデルを編集する機能を有する。宣言的モデル編集コンポーネント１１０は、編集された宣言的モデルをJSON(JavaScript（登録商標） Object Notation)やYAML(YAML Ain't Markup Language)等のソースコード形式で出力する。宣言的モデル編集コンポーネント１１０は、例えばGUI(Graphical User Interface)を有するエディタ等のツールである。
【００４１】
リポジトリ１２０は、宣言的モデル編集コンポーネント１１０が出力する編集された宣言的モデルが格納されるデータベースである。リポジトリ１２０は、例えばSubversion（登録商標）やGitで実現される。
【００４２】
宣言的モデルオーケストレータ１３０は、宣言的モデルを解釈する機能を有する。宣言的モデルを解釈した後、宣言的モデルオーケストレータ１３０は、構築処理が行われるように宣言的モデルのソースコードを内部インタプリタにデータ変換する。宣言的モデルオーケストレータ１３０は、例えばTOSCAのリファレンス実装やOpenStackのHeat実装で実現される。
【００４３】
本実施形態の宣言的モデルオーケストレータ１３０には、利用者がシステム構築時に投入するパラメータである利用者投入パラメータが入力される。また、宣言的モデルオーケストレータ１３０には、リポジトリ１２０から汎用的に利用可能な宣言的モデルの定義、すなわち宣言的モデル（テンプレート）が入力される。
【００４４】
また、図３に示すように、宣言的モデルオーケストレータ１３０は、監視定義生成コンポーネント１３１を有する。監視定義生成コンポーネント１３１は、宣言的モデルオーケストレータ１３０に入力された宣言的モデル（テンプレート）、利用者投入パラメータ、およびSLAを示す情報に基づいて、宣言的モデルに関連付けられる抽象的な監視定義を生成する機能を有する。
【００４５】
なお、本実施形態の監視定義生成コンポーネント１３１は宣言的モデルオーケストレータ１３０に含まれているが、TOSCAのリファレンス実装やOpenStackのHeat実装等で実現されないコンポーネントである。すなわち、監視定義生成コンポーネント１３１は、本実施形態の構築システム１００が有する特徴的なコンポーネントである。
【００４６】
宣言的モデルオーケストレータ１３０は、システム構築に利用されるようにテンプレートが変換された宣言的モデルの定義を出力する。また、宣言的モデルオーケストレータ１３０は、監視設定に利用される実装内容に依存しない監視定義を出力する。出力される監視定義は、出力される宣言的モデルに関連付けられる抽象的な監視定義である。
【００４７】
宣言的モデル実行コンポーネント１４０は、システムが構築される実行環境に応じて構築処理を行う機能を有する。具体的には、宣言的モデル実行コンポーネント１４０は、宣言的モデルオーケストレータ１３０が解釈および変換した宣言的モデルが示す指示に従ってシステムの構築処理を行う。
【００４８】
様々な実行環境に対応するために、宣言的モデル実行コンポーネント１４０は、一般的に実行環境に対応したデータ変換やAPI呼び出し等を行うプラグインパターンで実現される。プラグインにより宣言的モデル実行コンポーネント１４０に実装される機能は、抽象的な監視定義を対応する監視コンポーネント１６０が解釈できる定義に変換する機能である。
【００４９】
また、図３に示すように、宣言的モデル実行コンポーネント１４０は、監視設定コンポーネント１４１を有する。監視設定コンポーネント１４１は、抽象的な監視定義を基に監視コンポーネント１６０に対応する具体的な監視設定パラメータを生成する機能を有する。
【００５０】
監視設定コンポーネント１４１は、生成された監視設定パラメータを監視コンポーネント１６０に入力する。すなわち、監視設定コンポーネント１４１が監視コンポーネント１６０に入力する監視設定パラメータは、実装内容に依存したパラメータである。
【００５１】
実行環境１５０は、構築されたシステムが稼働する環境である。実行環境１５０は、例えばクラウド環境である。
【００５２】
監視コンポーネント１６０は、実行環境１５０で稼働するシステムを監視する機能を有する。監視コンポーネント１６０は、監視設定コンポーネント１４１から入力された監視設定パラメータを監視処理に使用する。
【００５３】
サービスレベル管理コンポーネント１７０は、構築されるシステムのサービスレベルを管理する機能を有する。サービスレベル管理コンポーネント１７０は、構築されるシステムに求められるSLAを示す情報を監視定義生成コンポーネント１３１に入力する。
【００５４】
図４は、改善前のデータモデルと改善後のデータモデルの例を示す説明図である。なお、図４には、データモデルの定義情報を示すUML(Unified Modeling Language)のクラス図が含まれている。
【００５５】
図４（ａ）は、改善前のデータモデルを示す。図４（ａ）に示す「所定の実装内容に即した宣言的モデル」は、「実装内容に依存した監視定義（デフォルト）」との間にコンポジションの関係を有する。また、「所定の実装内容に即した宣言的モデル」は、「SLA」との間に何ら関係を有しない。
【００５６】
すなわち、図４（ａ）に示すように改善前のデータモデルにおける宣言的モデルは、実装内容に依存した監視定義を内包する形式で保持している。しかし、改善前のデータモデルにおける宣言的モデルは、SLAの定義との関係性を保持していない。
【００５７】
図４（ｂ）は、改善後のデータモデルを示す。図４（ｂ）に示す「宣言的モデル」は、「実行部」および「変数部」との間に集約の関係を有する。また、「宣言的モデル」は、「SLA定義のベース」に関連している。また、「変数部」は、「監視定義のベース」に依存している。また、「監視定義のベース」は、「宣言的モデル」と「SLA定義のベース」の関係に関連している。
【００５８】
すなわち、図４（ｂ）に示す改善後のデータモデルでは、宣言的モデルの実行部と変数部が明確に記述されている。また、SLAとの関係性が、監視定義のベースを介して保持されている。
【００５９】
なお、図４（ｃ）は、上述した改善前のデータモデルの特徴と改善後のデータモデルの特徴との比較結果を示す。
【００６０】
図５は、改善後のデータモデルを基に生成されたデフォルトテンプレートの使用例を示す説明図である。なお、図５に示すデフォルトテンプレートは、図３に示すリポジトリ１２０から宣言的モデルオーケストレータ１３０に入力される宣言的モデル（テンプレート）に相当する。
【００６１】
図５には、改善後のデータモデルが使用されたデフォルトテンプレートとシステム構築時に利用者が入力する情報とに基づいて出力される抽象的な監視定義が示されている。
【００６２】
デフォルトテンプレートの作成者は、宣言的モデルが一般的に備えている処理方法が記載される部分である処理定義部（図５に示す実行部）と、変数が定義される部分である変数定義部（図５に示す変数部）が分けて定義される点に注目する。
【００６３】
すなわち、デフォルトテンプレートの作成者は、処理定義部を汎用的に再利用可能にする。また、作成者は、構築されるシステムの特徴が入力される事項を全てパラメータ化（変数化）し、宣言的モデルの再利用可能性を高めつつ、各システム要件に則してシステムが構築されるようにデフォルトテンプレートを作成する。
【００６４】
デフォルトテンプレートの作成者は、例えばシステム部門でシステムを長期間運用した経験を有する運用者や開発部門の責任者である。上述したように、デフォルトテンプレートには、作成者の知見が反映されている。
【００６５】
以下、図５に示すデフォルトテンプレートの構成要素、システム構築時に投入されるパラメータ、および生成される監視設定の各具体例を説明する。
【００６６】
「SLA定義のベース」は、デフォルトテンプレートで定義される宣言的モデルを用いて構築されるシステムに求められると想定されるSLAの定義である。SLAは、例えば、「トランザクション処理件数：１００件／秒」、「レスポンスタイム：５秒」と定義される。
【００６７】
「宣言的モデル」内の「変数部」には、デフォルトテンプレートで定義される宣言的モデルを用いて構築されるシステムで構築時に利用されるパラメータのデフォルト値が定義される。
【００６８】
「監視定義のベース」は、デフォルトテンプレートで定義される宣言的モデルを用いて構築されるシステムへの抽象的な監視設定の定義である。
【００６９】
「SLA」は、構築されるシステムに要求されるSLAの定義である。すなわち、デフォルトテンプレートが使用されて構築されるシステムに要求されるSLAの定義である。
【００７０】
「構築用パラメータ」は、デフォルトテンプレートが使用されて構築されるシステムの構築用パラメータの定義である。構築用パラメータは、例えば、マシンの仕様情報、オートスケール時の最小台数および最大台数、OSやミドルウェア等の各種設定項目である。
【００７１】
「監視設定」は、本実施形態の監視定義生成コンポーネント１３１で生成される抽象的な監視設定の定義である。
【００７２】
上述したように、デフォルトテンプレートの値には、例えばシステム部門の高度な技術を有する担当者の知見が反映されている。また、システム構築時に投入された値には、例えばシステムを構築する担当者の要求が反映されている。
【００７３】
システムに要求される複数のSLAには、システム構築や監視において相反する２つ以上のSLAが含まれている場合がある。例えば、可用性と性能は、同時に満たされることが困難なサービスである。
【００７４】
上記のようなSLAが含まれている場合、監視定義生成コンポーネント１３１は、デフォルトテンプレートに定義されている関係の方が正しい関係であると判断する。かつ、監視定義生成コンポーネント１３１は、システム構築者の要求ができるだけ反映されるように、デフォルトテンプレートの各値と各パラメータとの間で相関分析や主成分分析を行った上で監視用の設定データを生成する。
【００７５】
また、例えばオンプレミスクラウドとパブリッククラウドのように異なる実行環境で汎用性の高い同一のデフォルトテンプレートが使用されてシステムが構築される場合、SLAに対する要求として、システム構築者の要求が優先される方がよい場合もある。監視定義生成コンポーネント１３１は、状況に応じて生成される監視用の設定データを変更してもよい。
【００７６】
以上のように、本実施形態の構築システム１００は、宣言的モデルに対応した監視定義を自動的に生成し、生成された監視定義に基づいた監視設定パラメータを監視コンポーネント１６０に設定できるシステムである。
【００７７】
［動作の説明］
以下、本実施形態の構築システム１００の動作を図６〜図７を参照して説明する。
【００７８】
最初に、本実施形態の構築システム１００の全体動作を図６を参照して説明する。図６は、第２の実施形態の構築システム１００によるシステム構築処理の全体動作を示すアクティビティ図である。
【００７９】
利用者は、宣言的モデルのデフォルトテンプレートを用いてシステムを構築する。具体的には、利用者は、利用者が指定するパラメータおよび構築されるシステムに要求されるSLAを示す情報を宣言的モデルオーケストレータ１３０に入力し、宣言的モデルオーケストレータ１３０にシステム構築を指示する（ステップS110）。
【００８０】
なお、利用者は、SLAを示す情報を、サービスレベル管理コンポーネント１７０を介して宣言的モデルオーケストレータ１３０に入力する。
【００８１】
次いで、宣言的モデルオーケストレータ１３０は、システムが構築される実行環境１５０に応じた処理情報を、入力されたデフォルトテンプレート内の宣言的モデルを基に生成する（ステップS120）。宣言的モデルオーケストレータ１３０は、生成された処理情報を宣言的モデル実行コンポーネント１４０に入力する。
【００８２】
ステップS120で生成される処理情報は、例えば構築順序の制御に使用されるソースコードである。なお、処理情報の具体的な生成方法として、例えばOpenStackでの実装例における生成方法がある。
【００８３】
次いで、宣言的モデル実行コンポーネント１４０は、生成された処理情報を用いて実行環境１５０に応じた構築処理を実行することによって、実行環境１５０にシステムを構築する（ステップS130）。宣言的モデル実行コンポーネント１４０は、例えば実行環境１５０の外部インタフェースを使用してシステムを構築する。
【００８４】
ステップS120〜ステップS130の処理と並列して、宣言的モデルオーケストレータ１３０は、入力されたデフォルトテンプレートとパラメータ等を用いて、構築されるシステムに適切な監視定義を生成する（ステップS140）。ステップS140で生成される監視定義は、抽象的な監視定義である。
【００８５】
ステップS130の処理およびステップS140の処理が終了した後、監視設定コンポーネント１４１は、生成された抽象的な監視定義を監視対象のコンポーネント用の監視定義に変換する。次いで、監視設定コンポーネント１４１は、変換された監視定義を監視コンポーネント１６０に設定する（ステップS150）。
【００８６】
具体的には、監視設定コンポーネント１４１は、抽象的な監視定義を基に監視設定パラメータを生成する。また、監視設定コンポーネント１４１は、生成された監視設定パラメータを監視コンポーネント１６０に入力する。
【００８７】
監視設定コンポーネント１４１は、例えば監視設定コンポーネント１４１の外部インタフェースを使用して監視定義を設定する。設定した後、構築システム１００は、システム構築処理を終了する。
【００８８】
次に、ステップS140の宣言的モデルオーケストレータ１３０の監視定義を生成する動作を図７を参照して説明する。図７は、第２の実施形態の監視定義生成コンポーネント１３１による監視定義生成処理の動作を示すアクティビティ図である。
【００８９】
最初に、監視定義生成コンポーネント１３１は、デフォルトテンプレートに定義されている監視設定の内容（すなわち、監視定義のベース）を解析する（ステップS141）。図７に示すように、デフォルトテンプレートに定義されている監視設定は、例えば、稼働監視、性能監視、またはログ・イベント監視である。
【００９０】
また、監視定義生成コンポーネント１３１は、デフォルトテンプレートに定義されているSLA（すなわち、SLA定義のベース）とシステム構築時に投入されたSLAとの差異を解析する（ステップS142）。例えば、監視定義生成コンポーネント１３１は、両者の間に過不足がないか否かを確認する。
【００９１】
また、監視定義生成コンポーネント１３１は、デフォルトテンプレートに定義されている宣言的モデルおよびシステム構築時に投入されたパラメータを解析する（ステップS143）。
【００９２】
次いで、監視定義生成コンポーネント１３１は、ステップS141〜ステップS143における各解析結果を入力として、システムが構築された後に実行される監視用の設定データを生成する（ステップS144）。
【００９３】
生成する際、監視定義生成コンポーネント１３１は、例えばデフォルトテンプレートに定義されている値とシステム構築時に投入された値との関係性を基に監視用の設定データを生成する。
【００９４】
次いで、監視定義生成コンポーネント１３１は、生成された監視用の設定データが宣言的モデルで使用されるように、宣言的モデルの定義に合わせて監視用の設定データを基に抽象的な監視定義を生成する（ステップS145）。抽象的な監視定義を生成した後、監視定義生成コンポーネント１３１は、監視定義生成処理を終了する。
【００９５】
［効果の説明］
本実施形態の構築システムは、システム構築者が要求した非機能要件に沿った監視設定の定義を監視ツールや動作基盤に依存せずに自動的に生成できる。その理由は、監視定義生成コンポーネント１３１がデフォルトテンプレートを用いて監視設定の定義を作成するためである。
【００９６】
例えば、システムのSLAが変更される場合を考える。宣言的モデルで構築されたシステムに投入されるトランザクションの件数が１００（件／秒）から５０（件／秒）に変更される場合、SLAの変更に応じた監視設定を定義することが求められる。
【００９７】
上記のようにSLAが変更される場合には、例えば災害発生時等において、処理性能が低下しても業務の継続性を重視するという方針の下で遠隔地のデータセンタに本番環境のシステムと同様なシステム（災対環境のシステム）が再構築される場合が該当する。
【００９８】
災対環境のシステムに対する監視設定は、図８に示す様々な個所への平常時の監視設定にSLAに沿った変更が加えられた設定になる。例えば、DBのレスポンスの閾値を低くするような変更が加えられる。
【００９９】
本実施形態の構築システムは、宣言的モデルで構築されるシステムの非機能要件(SLA)に沿った監視設定を、利用者がシステム構築のために投入するパラメータのみを用いて調整できる。よって、上記のように災対環境のシステムに対する監視設定の定義の作成が求められる場合に、本実施形態の構築システムは好適に使用される。
【０１００】
本実施形態の構築システムは、クラウド管理の分野、クラウド運用の分野、およびクラウドに対応したシステム開発の分野で好適に利用されることが期待される。
【０１０１】
なお、本実施形態の構築システムは、システムが構築された後の監視結果を解析することによってデフォルトテンプレートの精度を向上させる特許文献１に記載されている宣言的モデルのチューニング方法と組み合わされて使用されてもよい。特許文献１に記載されている技術が適用された本実施形態の構築システムは、改善ループを実行することによってより適切な監視定義を生成できる。
【０１０２】
なお、各実施形態の監視定義生成装置１０、および構築システム１００は、例えば、非一時的な記憶媒体に格納されているプログラムに従って処理を実行するCPU(Central Processing Unit)によって実現されてもよい。すなわち、生成部１１、宣言的モデル編集コンポーネント１１０、宣言的モデルオーケストレータ１３０、宣言的モデル実行コンポーネント１４０、監視コンポーネント１６０、およびサービスレベル管理コンポーネント１７０は、例えば、プログラム制御に従って処理を実行するCPUによって実現されてもよい。
【０１０３】
また、リポジトリ１２０は、例えばRAM(Random Access Memory)で実現されてもよい。
【０１０４】
また、各実施形態の監視定義生成装置１０、および構築システム１００における各部は、ハードウェア回路によって実現されてもよい。一例として、生成部１１、宣言的モデル編集コンポーネント１１０、宣言的モデルオーケストレータ１３０、宣言的モデル実行コンポーネント１４０、監視コンポーネント１６０、およびサービスレベル管理コンポーネント１７０が、それぞれLSI(Large Scale Integration)で実現される。また、それらが１つのLSIで実現されていてもよい。
【符号の説明】
【０１０５】
１０  監視定義生成装置
１１  生成部
１００  構築システム
１１０  宣言的モデル編集コンポーネント
１２０  リポジトリ
１３０  宣言的モデルオーケストレータ
１３１  監視定義生成コンポーネント
１４０  宣言的モデル実行コンポーネント
１４１  監視設定コンポーネント
１５０  実行環境
１６０  監視コンポーネント
１７０  サービスレベル管理コンポーネント
【図１】
2018147338.tif 000003
【図２】
2018147338.tif 000004
【図３】
2018147338.tif 000005
【図４】
2018147338.tif 000006
【図５】
2018147338.tif 000007
【図６】
2018147338.tif 000008
【図７】
2018147338.tif 000009
【図８】
2018147338.tif 000010