特開 2023-167974 システム構築装置

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】公開特許公報(A)

(11)【公開番号】P2023167974

(43)【公開日】2023-11-24

(54)【発明の名称】システム構築装置

(51)【国際特許分類】

   G06F 8/30 20180101AFI20231116BHJP

   G06F 8/60 20180101ALI20231116BHJP

【ＦＩ】

G06F8/30

G06F8/60

【審査請求】未請求

【請求項の数】6

【出願形態】ＯＬ

(21)【出願番号】P 2022079548

(22)【出願日】2022-05-13

(71)【出願人】

【識別番号】509186579

【氏名又は名称】日立Ａｓｔｅｍｏ株式会社

(74)【代理人】

【識別番号】110002572

【氏名又は名称】弁理士法人平木国際特許事務所

(72)【発明者】

【氏名】伊藤 大生

【テーマコード（参考）】

5B376

【Ｆターム（参考）】

5B376AA07

5B376AA10

5B376AA17

5B376BC24

5B376BC31

5B376BC38

5B376BC43

5B376EA17

(57)【要約】      （修正有）

【課題】ユーザが構築情報を変更せずシステムの構成を変更した場合にユーザの書き方に合わせた形で構築情報とシステムの構成の差異を修正する。
【解決手段】所定の実行環境上にインフラストラクチャーリソース及びインフラストラクチャーリソースの設定値を含むシステムを構築するシステム構築装置であって、所望の要件を入力する入力部（ポータル画面表示部）、所望の要件を満たすシステムを定義する第一ソースコードを作成するシステムソースコード作成部、実行環境上に、システムをデプロイするデプロイ部、実行環境上に構築されたシステムが変更された場合に、変更されたシステムを定義する第二ソースコードと第一ソースコードとの差分を検出する設定変更検出部及び検出した差分を第一ソースコードに反映させる設定変更反映部とを備える。設定変更反映部は、第一ソースコードに適用されたコーディングルールに基づいて差分を第一ソースコードに反映させる。
【選択図】図２

【特許請求の範囲】

【請求項1】

所定の実行環境上にインフラストラクチャーリソース及び該インフラストラクチャーリソースの設定値を含むシステムを構築するシステム構築装置であって、
所望の要件を満たすシステム構築の要求を入力する入力部と、
前記所望の要件を満たすシステムを定義する第一ソースコードを作成するシステムソースコード作成部と、
前記実行環境上に、前記システムを前記要求に基づいてデプロイして構築するデプロイ部と、
前記実行環境上に構築された前記システムが変更された場合に、変更された該システムを定義する第二ソースコードと前記第一ソースコードとの差分を検出する設定変更検出部と、
前記設定変更検出部により検出された前記差分を前記第一ソースコードに反映させる設定変更反映部と、を備え、
前記設定変更反映部は、前記第一ソースコードに適用されたコーディングルールに基づいて前記差分を前記第一ソースコードに反映させる、
ことを特徴とするシステム構築装置。

【請求項2】

請求項１に記載のシステム構築装置であって、
前記差分に前記設定値の変更が含まれる場合に、前記設定変更反映部は、前記第二ソースコードの設定値を前記コーディングルールに基づいて修正し、前記第一ソースコードを修正する
ことを特徴とするシステム構築装置。

【請求項3】

請求項１に記載のシステム構築装置であって、
前記差分に前記インフラストラクチャーリソースの追加が含まれる場合に、前記設定変更反映部は、追加された前記インフラストラクチャーリソースのソースコードを取得し、該ソースコードを前記コーディングルールに基づいて修正し、前記第一ソースコードを修正する
ことを特徴とするシステム構築装置。

【請求項4】

請求項３に記載のシステム構築装置であって、
前記設定変更検出部は、前記システムを特定するメタデータに基づいて、
追加された前記インフラストラクチャーリソースが新規のインフラストラクチャーリソースであるか否か判定する
ことを特徴とするシステム構築装置。

【請求項5】

請求項１に記載のシステム構築装置であって、
前記入力部はポータル画面表示部を含み、前記要件は機能要件と非機能要件とを含み、
前記ポータル画面表示部は、入力された前記機能要件または前記非機能要件を満たすシステムの候補を利用者に提示する
ことを特徴とするシステム構築装置。

【請求項6】

請求項５に記載のシステム構築装置であって、
前記デプロイ部は、前記提示されたシステムの候補に対する前記利用者の選択に基づいて、前記利用者が選択したシステムを構築するための構築情報を作成し、前記システムを前記実行環境上に構築する
ことを特徴とするシステム構築装置。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、所定の実行環境上にシステムを構築するシステム構築装置に関する。

【背景技術】

【0002】

近年、クラウドコンピューティング技術の発展に伴い、ＩＴ（Ｉｎｆｏｒｍａｔｉｏｎ Ｔｅｃｈｎｏｌｏｇｙ）リソースの仮想化が進んでいる。こうした技術の発達により、仮想サーバやコンテナなどの仮想化技術とソースコードや設定ファイルなどに基づいてシステムをデプロイするＩａＣ（Ｉｎｆｒａｓｔｒｕｃｔｕｒｅ ａｓ Ｃｏｄｅ）とを活用したシステムの自動構築技術が注目されている。

【0003】

特許文献１の技術によれば、システム要件が記載されたオーダーシートに基づいて、オーダーシートをソースコードに変換しリソースのデプロイを自動化する技術が開示されている。

【先行技術文献】

【特許文献】

【0004】

【特許文献1】特開第２０２１－１５７６１２号公報

【特許文献2】特開第２０２１－１４０３７２号公報

【発明の概要】

【発明が解決しようとする課題】

【0005】

特許文献１に記載の技術を用いることで、ユーザがコーディング知識を持ち合わせていない場合においても、システム要件に合わせてシステムを自動構築することが可能となる。一方で、ユーザがソースコードを変更せずに、デプロイされたシステムの構成を変更した場合に、対象システムのソースコードと、対象システムの構成が異なるという課題がある。

【0006】

この課題に関して、特許文献２は、システムの設定変更の有無を検出し、検出された設定変更をソースコードに反映する技術を記載している。

【0007】

特許文献２においては、構築対象システムが備える機器を監視対象としており、システムに新規機器を追加するような変更に対してソースコードに反映することができないという課題がある。また、ソースコードの書き方であるコーディングルールはユーザによって異なることが多いため、ソースコードへの反映方法によっては、修正されたソースコードのコーディングルールが一貫性に欠けてしまうおそれがある。したがって、ソースコードの管理やユーザの理解を容易にする目的で、反映したのちにソースコードが一貫性を有するように修正する必要がある。

【0008】

本発明は、以上のような課題に鑑みてなされたものであり、ユーザがソースコードを変更せず、システムの構成を変更した場合に、システムへの新規リソース追加も含めて、ユーザの書き方に合わせた形で、ソースコードとシステムの構成の差異を修正することを目的とする。

【課題を解決するための手段】

【0009】

本発明に係るシステム構築装置は、所定の実行環境上にインフラストラクチャーリソース及び該インフラストラクチャーリソースの設定値を含むシステムを構築するシステム構築装置であって、所望の要件を満たすシステム構築の要求を入力する入力部と、所望の要件を満たすシステムを定義する第一ソースコードを作成するシステムソースコード作成部と、実行環境上に、システムを要求に基づいてデプロイして構築するデプロイ部と、実行環境上に構築されたシステムが変更された場合に、変更された該システムを定義する第二ソースコードと第一ソースコードとの差分を検出する設定変更検出部と、設定変更検出部により検出された差分を第一ソースコードに反映させる設定変更反映部と、を備え、設定変更反映部は、第一ソースコードに適用されたコーディングルールに基づいて差分を第一ソースコードに反映させる。

【発明の効果】

【0010】

本発明に係るシステム構築装置によれば、ユーザがシステムの構築情報を変更せずにシステムの構成を変更した場合に、コーディングルールを統一した形で、当初のシステムの構築情報と変更されたシステムの構成との差異を修正することができる。

【図面の簡単な説明】

【0011】

【図1】実施例１に係るシステム構築装置１００のハードウェア構成図。

【図2】実施例１に係るシステム構築装置１００の機能ブロック構成図。

【図3】実施例１に係るシステム構築装置１００が実行する処理のフローチャート。

【図4】図３のフローチャート中のステップＳ１０１の具体例を説明する図。

【図5A】図３のフローチャート中のステップＳ１０２の具体例を説明する図。

【図5B】図３のフローチャート中のステップＳ１０３の具体例を説明する図。

【図5C】図３のフローチャート中のステップＳ１０３の具体例を説明する図。

【図6】図３のステップＳ１０４とステップＳ１０５のデプロイ処理に係るシステムソースコードの一例を示す図。

【図7】図３のフローチャート中のステップＳ１０６とＳ１０７の具体例を説明するフローチャート。

【図8】図７のフローチャート中のステップＳ２０２において参照される、既存の設定値２８２の判断方法について具体例を説明する図。

【図9】図７のフローチャート中のステップＳ２０９の具体例を説明するフローチャート。

【図10】実施例２に係るシステム構築装置１００が実行する処理のフローチャート。

【発明を実施するための形態】

【0012】

＜実施例１＞
図１は、本実施例に係るシステム構築装置１００のハードウェア構成の一例を示している。システム構築装置１００は、図１に示すように、演算装置１１０と、記憶装置１２０と、入出力Ｉ／Ｆ（Ｉｎｔｅｒｆａｃｅ）１３０と、通信Ｉ／Ｆ（Ｉｎｔｅｒｆａｃｅ）１４０等のハードウェアを備える。

【0013】

演算装置１１０は例えばＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）であり、ＣＰＵによる処理によって後述する種々の機能を発揮する。

【0014】

記憶装置１２０は、例えばＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）及びＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）を含み、演算装置１１０が用いるデータを格納する。

【0015】

入出力Ｉ／Ｆ１３０は、例えばタッチパネル機能を有するディスプレイであり、演算装置１１０による処理結果や後述するポータル画面２１０のユーザインターフェースを画面上に表示する。

【0016】

通信Ｉ／Ｆ１４０は、例えば通信チップ又はＮＩＣ（Ｎｅｔｗｏｒｋ Ｉｎｔｅｒｆａｃｅ Ｃａｒｄ）であり、後述する実行環境２８０や利用者２０１との間の通信に用いる。

【0017】

システム構築装置１００の各部がデータを受け付ける場合、入出力Ｉ／Ｆ１３０を介してデータを受け付けても良く、また、通信Ｉ／Ｆ１４０を介してデータを受け付けても良い。

【0018】

図２は、システム構築装置１００が有する各機能部の構成の一例を示す機能ブロック図である。システム構築装置１００は、ポータル画面２１０と、リポジトリ２２０と、システムソースコード作成部２３０と、デプロイ部２４０と、設定変更検出部２５０と、設定変更反映部２６０と、コーディングルール保存部２７０と、を含んで構成される。

【0019】

本実施例では、あらかじめデプロイ用のテンプレート２２１やモジュール２２２のソースコードが指定されたリポジトリ２２０に登録されている。リポジトリ２２０の例としては、クラウドサービスでは、ＧｉｔＨｕｂ（ｈｔｔｐｓ：／／ｇｉｔｈｕｂ．ｃｏｍ／）、ＯＳＳでは、ＧｉｔＬａｂといったものである。ソースコードの例については、図６を用いて後述する。

【0020】

なお、図２では、複数のテンプレート２２１とモジュール２２２を、１つのリポジトリ２２０で管理する例を示しているが、複数のプロジェクトのそれぞれに対応するソースコードごとにリポジトリ２２０が分かれている構成であってもよい。

【0021】

ここで、ソースコードとは、特定のシステム２８１を構築するために活用されるものである。例えば、１つのシステム２８１が１つのテンプレート２２１に対応する構成だけでなく、システム２８１の一部を構成するひとまとまりの機能であるモジュール２２２もソースコードに含まれる。その際は、複数のモジュール２２２を組み合わせて１つのシステム２８１のシステムソースコードを作成する。なお、本装置１００で管理したり表示したりするための各種の情報には、システム２８１を構築するためのソースコードであるテンプレート２２１やモジュール２２２、システムソースコードの実体または参照等が含まれる。

【0022】

システム構築装置１００は、システム構築装置１００の利用者２０１に対してポータル画面２１０を不図示の表示装置上に表示する。ポータル画面２１０の例については、図４と図５を用いて後述する。また。ポータル画面２１０には不図示のＣＰＵが搭載されており、リポジトリ２２０内のテンプレート２２１及びモジュール２２２から、後述するように利用者の選択に従ってシステムの候補を提示する。

【0023】

利用者２０１は、ポータル画面２１０を用いて今回、構築したいシステム２８１を選択する。例えば、利用者２０１がクラウドサービスの機能要件及び非機能要件を入力し、事前に用意されたテンプレート２２１を提示する。テンプレート２２１は、過去の実績に基づき各要件を満たすパブリッククラウドサービス、プライベートクラウドサービスなどが組み合わされたサービスである。

【0024】

非機能要件は、ネットワークに関する要件を含んでよい。ネットワークに関する要件として、パブリックＩＰの利用の有無、ファイアウォール利用の有無、暗号化機能の利用の有無、等が例として挙げられるが、これらに限らず、ネットワークに関する様々な要件を含んでよい。

【0025】

機能要件は、利用する実行環境２８０が、複数種類のクラウドのうちのいずれかであるかを示す情報を含んでもよい。機能要件は、上述した要件の他、システム２８１の目的、インフラに関連する様々な要件を含んでよい。

【0026】

その後、提示されたテンプレート２２１の各インフラストラクチャーリソース２８３を同様の機能を実現可能な別インフラストラクチャーリソース２８３に変更したり、インフラストラクチャーリソース２８３の追加や削除を行い、カスタマイズする。そして、カスタマイズ後に、各インフラストラクチャーリソース２８３がデプロイするために必要とする設定値２８２をパラメタシートなどから入力することで、構築したいシステム２８１が選択される。

【0027】

利用者２０１が構築したいシステム２８１を選択すると、システムソースコード作成部２３０が、リポジトリ２２０から選択されたシステム２８１のテンプレート２２１やモジュール２２２を用いてシステムソースコードを作成する。

【0028】

システムソースコードを作成後、デプロイ部２４０は実行環境２８０上にデプロイ処理を実施する。実行環境２８０は、システム２８１を動作させるための環境である。実行環境２８０は、例えば、パブリッククラウドサービス、プライベートクラウドサービス、ＯｐｅｎＳｔａｃｋ、Ｋｕｂｅｒｎｅｔｅｓ等のオーケストレーションツールで管理されるＩＴリソースのクラスタ等である。また、利用者２０１が選択したシステム２８１を動作させる実行環境２８０については、利用者２０１が指定する形式であってもよい。このとき実行環境２８０は、利用者２０１毎に異なる実行環境であってもよいし、１つの実行環境を共用する形であってもよい。

【0029】

デプロイ部２４０によるデプロイ処理が行われた結果、実行環境２８０には、システムソースコードに基づいてインフラストラクチャーリソース２８３、インフラストラクチャーリソース２８３の設定値２８２等を含む、システム２８１が構築される。ここで、インフラストラクチャーリソース２８３は、システムソースコードの記述に応じて、１または複数であってよい。

【0030】

そして、利用者２０１は、実行環境２８０上で、構築されたシステム２８１に必要な変更を加え、利用者２０１の用途にあった開発（システム２８１に対する変更）を行う。

【0031】

設定変更検出部２５０は、構築対象のシステム２８１の設定変更の有無を検出する。設定変更検出部２５０は、システム２８１の設定変更が有る場合に、システムソースコード作成部２３０が作成したシステムソースコードによって定義されるシステム２８１の構成と実行環境上における現在のシステム２８１との差分として設定変更内容を検出・抽出する。

【0032】

設定変更反映部２６０は、コーディングルール保存部２７０に保存されたコーディングルールに基づいて、設定変更検出部２５０が検出した差分をシステムソースコード作成部２３０が作成したシステムソースコードに反映させる。ここで、コーディングルールは例えば、変数名の定義として各ベンダーが提示する標準的な変数名から派生したものであることや、ＩＤなどの変数がハードコーディングされていないことなどが挙げられる。

【0033】

なお、以降の図および説明では、実行環境２８０としては、パブリッククラウドサービスのＩａａＳ（Ｉｎｆｒａｓｔｒｕｃｔｕｒｅ ａｓ ａ Ｓｅｒｖｉｃｅ）パブリッククラウド、デプロイ処理としては、Ｔｅｒｒａｆｒｏｍ、テンプレート２２１やモジュール２２２としては、Ｔｅｒｒａｆｏｒｍが規定するＨＣＬ（ＨａｓｈｉＣｏｒｐ Ｃｏｎｆｉｇｕｒａｔｉｏｎ Ｌａｎｇｕａｇｅ）で記述されたソースコードを例に挙げて説明する。しかしながら、本実施例は、上述の構成に限られるものではない。例えば、実行環境２８０としては、Ｋｕｂｅｒｎｅｔｅｓ、実行環境２８０に構築する対象としては、コンテナ、デプロイ処理としては、Ｈｅｌｍといった組合せを採用してもよい。

【0034】

図３は、本発明の実施例１に係るシステム構築装置１００が実行する処理の一例を示すフローチャートである。以下図３の各ステップについて説明する。また、以下では図３に示す各ステップの概要を説明し、その詳細については後述する。

【0035】

利用者１０１は、ポータル画面２１０から所望の要件（機能要件及び非機能要件）を入力する（ステップＳ１０１）。

【0036】

ポータル画面２１０上には、入力された機能要件および非機能要件を実現するシステム２８１の候補が提示される（ステップ１０２）。

【0037】

利用者２０１は、ポータル画面２１０に提示されたシステム２８１をデプロイするために必要な情報を入力する（ステップＳ１０３）。必要な情報は、例えば、システム２８１に含まれる各インフラストラクチャーリソース２８３の設定値２８２である。設定値２８２としては例えば、各インフラストラクチャーリソース２８３の名前やインフラストラクチャーリソース２８３の採用・運用により発生する料金の請求先などが含まれる。また各インフラストラクチャーリソース２８３の提供者により規定されている設定値２８２であってもよい。さらに、利用者２０１は各インフラストラクチャーリソース２８３を別のインフラストラクチャーリソース２８３へ変更してもよい。

【0038】

システムソースコード作成部２３０は、ポータル画面２１０に提示されたシステム２８１に含まれるインフラストラクチャーリソース２８３の情報とそのシステム２８１をデプロイするために必要な情報を入力として、システムソースコードを生成する（ステップＳ１０４）。

【0039】

デプロイ部２４０は、システムソースコード作成部２３０が生成したシステムソースコードを用いて、システム２８１を実行環境２８０上に構築する。

【0040】

設定変更検出部２５０は、利用者２０１がシステム２８１を直接変更したか否かを監視・検出する。そして、設定変更が検出された場合、設定変更検出部２５０は、変更内容を検出・抽出する（ステップＳ１０６）。設定変更検出部２５０は、どのような手法により変更された内容を検出しても良い。設定変更検出部２５０は、差分のみを抽出しても良い。

【0041】

設定変更反映部２６０は、コーディングルール保存部２７０に保存された、システムソースコード作成部２３０が採用したコーディングルールを参照し、設定変更検出部２５０が抽出した差分をシステムソースコードに反映させる。以上の工程により処理は終了する。

【0042】

図４は、図３のステップＳ１０１においてポータル画面２１０上に表示される画面の具体例を説明する図である。図４に示すように、ポータル画面２１０上には要件入力画面３００が表示される。利用者２０１はポータル画面２１０上で、システム２８１で実現したい目的や、システム２８１に求める可用性とシステムの性能、システムを運用するネットワーク条件を要件入力画面３００上で選択する。

【0043】

図４においては、システム２８１によって実現したい目的として、サービス類型３０１という項目で開発型や分析型、連携型の選択肢を表示する例を示した。利用者２０１がシステム２８１で実現したい目的を変更すると、ポータル画面２１０上で表示されるシステム２８１のインフラストラクチャーリソース２８３の種類がその目的にしたがって変化する。具体例としては、分析型が選択された場合に、システム２８１がデータを収集し分析を行うように設計される。このような自動化により利用者２０１は、通常システム２８１の設計でかかる工数を低減することができる。選択肢は一例であり、その他の選択肢であってもよい。

【0044】

図４においては、可用性として、可用性３０２という項目で本番向けやＰｏＣ（Ｐｒｏｏｆ ｏｆ Ｃｏｎｃｅｐｔ）向けの選択肢を表示する例を示した。なお、ＰｏＣとは、新しい概念や理論、原理、アイディアの実証を目的とした、試作開発の前段階における検証やデモンストレーションのことをいう。利用者２０１が可用性を変更すると、ポータル画面２１０上で表示されるシステム２８１のインフラストラクチャーリソース２８３の構成や設定値２８２が選択された可用性にしたがって変化する。具体例としては、本番向けが選択された場合に、システム２８１が複数のリージョン（例えば東京と大阪）に分散してデプロイされ、あるリージョンで災害が起きた際にもシステム２８１が動作し続けるように設計される。すなわち冗長性が担保される。選択肢は１例であり、その他の選択肢であってもよい。

【0045】

図４においては、性能として、性能３０３の項目でレベル１やレベル２、レベル３の選択肢を表示する例を示した。利用者２０１が性能を変更すると、ポータル画面２１０上で表示されるシステム２８１のインフラストラクチャーリソース２８３の設定値２８２がその性能にしたがって変化する。具体例としては、レベル３が選択された場合に、システム２８１のインフラストラクチャーリソース２８３の型番が最も高価な型番に設定される。選択肢は一例であり、その他の選択肢であってもよい。

【0046】

図４においては、ネットワークの条件として、外部接続３０４という項目で外部接続ありや外部接続なしを表示する例を示した。利用者２０１がネットワークの条件を変更すると、ポータル画面２１０上で表示されるシステム２８１のネットワーク接続に関するインフラストラクチャーリソース２８３と設定値２８２がそのネットワークの条件にしたがって変化する。具体例としては、外部接続ありが選択された場合に、外部接続を前提として、ネットワーク接続インフラストラクチャーリソースとしてファイアウォールがデプロイされる。選択肢は一例であり、その他の選択肢であってもよい。

【0047】

図４に表示される要件は、一例であり、その他の要件であってもよい。さらには、図４においては、システム２８１で実現したい目的の代わりに、過去のシステム２８１を選択肢として表示をしてもよい。その場合、過去のシステム２８１をデプロイした際の要件が入力される。

【0048】

図５Ａは、図３におけるステップＳ１０２において行われる処理の具体例を説明する図である。システム構築装置１００は、ステップＳ１０１で入力された機能要件および非機能要件を実現するシステム２８１案をポータル画面２１０上に提示する。利用者２０１は、ポータル画面２１０に提示されたシステム２８１をデプロイするために必要な情報を入力する（図５Ｂ参照）。さらには、利用者２０１は各インフラストラクチャーリソース２８３を別のインフラストラクチャーリソース２８３へ変更してもよい。

【0049】

図５Ｂは、図３におけるステップＳ１０３においてポータル画面２１０に提示されたシステム２８１をデプロイするために必要な情報を入力する方法の一例である。図５Ａにおいて「パラメタ入力」を選択すると、図５Ｂに示す画面３０１が表示される。そして、本実施例においては、図５Ａで選択されているインフラストラクチャーリソースをデプロイするために必要な各種パラメタが記載されたエクセルシートをパラメタシートとしてアップロードし、各インフラストラクチャーリソース２８３が必要とする設定値２８２を入力する例を示した。

【0050】

図５Ｃは、図３におけるステップＳ１０３において各サービスを別のサービスへ変更する際の例である。図５Ａの画面３００上で「カスタマイズ」を選択すると、図５Ｃの画面３２０が表示される。本実施例においては、データを格納するリソースを変更する例を示した。ユーザが別のリソースを選択すると、ユーザが選択したリソースに変更される。

【0051】

図６は、図３のステップＳ１０４とステップＳ１０５のデプロイ処理に係るシステムソースコードの一例を示す図である。本実施例においては、デプロイ処理としては、Ｔｅｒｒａｆｒｏｍを用いる場合について説明する。Ｔｅｒｒａｆｏｒｍとは、ＨａｓｈｉＣｏｒｐ社により開発されているオープンソースのインフラ自動構築ツールである。

【0052】

テンプレート２２１は、一般に、どのようなインフラストラクチャーリソース２８３をデプロイするのかを定義するｍａｉｎ．Ｔｆ（４００）のようなソースコードと、各インフラストラクチャーリソース２８３に与える変数および当該変数のデフォルト値が定義されたｖａｒｉａｂｌｅｓ．Ｔｆ（４１０）のような形式である変数ファイルと、各インフラストラクチャーリソース２８３に与える変数の設定値２８２が定義されたａｕｔｏ．ｉｎｐｕｔ．ｔｆｖａｒｓ（４２０）のような形式である変数入力ファイルとを含む。

【0053】

例えば、記述４０１（「ｒｅｓｏｕｒｃｅ “ａｗｓ＿ｓ３＿ｂｕｃｋｅｔ”“ｓ３＿ｂｕｃｋｅｔ”」）は、リソースとして「ａｗｓ＿ｓ３＿ｂｕｃｋｅｔ」をデプロイすることを意味している。また、記述４０１（「ｂｕｃｋｅｔ ＝ “＄｛ｖａｒ．ｆｏｏ｝”」）は、ｖａｒｉａｂｌｅｓ．Ｔｆ（４１０）に定義された記述４１１（「ｖａｒｉａｂｌｅ “ｆｏｏ”｛｝」）を読み込むことを意味している。

【0054】

そして、デプロイ処理時に、変数ｋｅｙ「ｆｏｏ」の変数に値を指定しなければ、デフォルト値である「ｆｏｏ：１」が用いられる。なお、デプロイ処理時に、別の値、例えば、変数ｋｅｙ「ｆｏｏ」の変数に、ａｕｔｏ．ｉｎｐｕｔ．ｔｆｖａｒｓ（４２０）内で値「ｆｏｏ ＝ “ｄｅｖ－ｖａｒ”」を指定すれば、記述４１１は、「ｆｏｏ：“ｄｅｖ－ｖａｒ”」のように生成される。

【0055】

さらに、テンプレートファイルには、プログラム的な要素、例えば、ｉｆ文を含んでいてもよい。Ｔｅｒｒａｆｏｒｍでは、使用可能なプログラム的な要素が定義されており、ｃｏｕｎｔという変数によって、リソースを何個構築するかを制御できる。ａｕｔｏ．ｉｎｐｕｔ．ｔｆｖａｒｓ（４２０）内で値「Ｓ３＿ｃｏｕｎｔ ＝ １」を指定すれば、「ｒｅｓｏｕｒｃｅ “ａｗｓ＿ｓ３＿ｂｕｃｋｅｔ” “ｓ３＿ｂｕｃｋｅｔ”」は一つ生成される。これにより、図５Ｂで入力された情報に基づいてカウントを制御することにより、リソースをカスタマイズすることができる。

【0056】

以上、ステップＳ１０４で生成されたシステムソースコードに基づいてデプロイ部２４０はデプロイツールを用いて実行環境２８０上にインフラストラクチャーリソース２８３をデプロイさせる。

【0057】

図７は、図３におけるステップＳ１０６とステップＳ１０７における具体的な処理手順の一例を示すフローチャートである。以下図７の各ステップについて説明する。

【0058】

設定変更検出部２５０は、利用者２０１がシステム２８１を実行環境２８０上で直接変更したことを検出する（ステップＳ２０１）。具体例としては、図３のステップＳ１０５にてシステム２８１が構築された際に、クラウドベンダーが用意しているシステム２８１を各クラウドベンダーのソースコードとしてエクスポートする機能を用いて基準となるソースコードを取得した後に、逐次エクスポート機能により取得したソースコードと基準となるソースコードとの差分を取得してもよい。

【0059】

差分の取得方法としては、上述のように各システム２８１が構築されている環境からエクスポートして取得することが望ましい。各クラウドベンダーが同じシステム２８１であることを示すメタデータを標準で用意しており、それによってシステム２８１への新規機器の追加の検知も可能になるからである。また、図２のステップＳ１０５にてシステム２８１を構築する際に、同じシステムであることを示すメタデータを付与することによっても可能である。

【0060】

続いて、設定変更検出部２５０は、設定変更が検出されたかどうかを確認する（ステップＳ２０２）。設定変更が検出された場合は、ステップＳ２０３に進み、設定変更が検出されなかった場合は、処理を終了する。

【0061】

設定変更があった場合（ステップＳ２０２で“Ｙｅｓ”）、設定変更検出部２５０は、設定変更の種類を確認する（ステップＳ２０３）。設定変更の種類には、インフラストラクチャーリソース２８３に関する設定変更とインフラストラクチャーリソース２８３の設定値２８２に関する設定変更の２種類が存在する。インフラストラクチャーリソース２８３に関する設定変更としては、新規にインフラストラクチャーリソース２８３を追加、削除する場合があり、インフラストラクチャーリソース２８３の設定値２８２に関する設定変更は、インフラストラクチャーリソース２８３の設定値２８２を変更した場合である。インフラストラクチャーリソース２８３に関する設定変更が検出された場合は、ステップＳ２０７に進み、インフラストラクチャーリソース２８３の設定値２８２に関する設定変更が検出された場合は、ステップＳ２０４に進む。なお、ここでいう設定値２８２とは、図５Ｂに示したパラメタシートに記載されたパラメタである。

【0062】

設定変更が設定値２８２の変更であった場合、設定変更反映部２６０は、既存の設定値２８２に関する設定変更かどうかを確認する（ステップＳ２０４）。既存の設定値２８２とは、システムソースコードの中ですでに定義されている設定値２８２のことを示す。一例としては、ＶＭ（Ｖｉｒｔｕａｌ Ｍａｃｈｉｎｅ）をインフラストラクチャーリソース２８３として設定していた場合を想定する。なお、ＶＭとは物理ハードウェアシステム上に作成され (場所はオフプレミスまたはオンプレミス)、固有の ＣＰＵ、メモリー、ネットワーク・インタフェース、ストレージを持ち、仮想コンピュータシステムとして機能する仮想環境のことである。

【0063】

そして、ＶＭをシステムソースコードとして定義している部分で、ＶＭのサイズをｓｍａｌｌと設定していたとする。その後、利用者２０１によって手動でＶＭのサイズがｍｅｄｉｕｍに変更された場合、ＶＭのサイズはシステムソースコードとしてすでに定義されている設定値２８２であるため、既存の設定値２８２であると判断される。また、システムソースコードとして定義されていない設定値、例えばＶＭのタグを追加した場合は、システムソースコードとして定義されていない設定値２８２であるため、既存の設定値２８２ではないと判断される。既存の設定値２８２に関する設定変更の場合は、ステップＳ２０５に進み、そうではない場合は、ステップＳ２０６に進む。

【0064】

図８は、ステップＳ２０２において参照される、既存の設定値２８２の判断方法について具体例を説明する図である。システム構築装置１００は、システムソースコードとしてどのインフラストラクチャーリソース２８３がどの変数を定義しているかという情報を持つ。例えば、インフラストラクチャーリソース２８３がＶＭである場合、ある変数がシステムソースコードの「．／ｔｅｍｐＡ，」というパスの１－９行目に定義されており、また、システムソースコードの「．／ｍｏｄｕｌｅ」というパスの１０－２０行目で呼び出されていることがわかる。これを用いることで、差分として検出されたインフラストラクチャーリソース２８３名とその変数名を入力として、既存の設定値２８２として存在するかどうかを検索し、判断する。

【0065】

既存の設定値２８２の設定変更が検出された場合、設定変更反映部２６０は、システムソースコードとしてどのインフラストラクチャーリソース２８３がどの変数を定義しているかという情報を用いて、該当設定値２８２の現在値を差分の設定値に変更する。これにより、元々のコーディングルールに基づいて設定変更を修正することが可能である。

【0066】

既存のパラメタの設定変更が検出されない場合、設定変更反映部２６０は、システムソースコードとしてどのインフラストラクチャーリソース２８３がどの変数を定義しているかという情報を用いて、該当設定値２８２を新規設定値としてシステムソースコードに追加する（ステップＳ２０６）。その後、ステップＳ２０５に進み、現在の設定値２８２に設定する。これにより、元々のコーディングルールに基づいて設定変更を修正することが可能である。

【0067】

設定変更がインフラストラクチャーリソース２８３の変更であった場合、設定変更反映部２６０は、既存のインフラストラクチャーリソース２８３に関する設定変更かどうかを確認する（ステップＳ２０７）。既存のインフラストラクチャーリソース２８３とは、システムソースコードの中ですでに定義されているインフラストラクチャーリソース２８３のことを示す。一例としては、ＶＭのインフラストラクチャーリソース２８３をシステムソースコードとして定義していた場合、利用者２０１が手動で別のＶＭを追加した場合、既存のインフラストラクチャーリソース２８３であると判断される。また、インフラストラクチャーリソース２８３として定義されていない新たなＶＭを追加した場合は、既存のインフラストラクチャーリソース２８３ではないと判断される。さらに、追加されたＶＭが現状のシステムソースコードに含まれていない場合であっても、ＶＭのインフラストラクチャーリソース２８３のソースコードをリポジトリ２２０内にとして持っている場合には、既存のインフラストラクチャーリソース２８３であると判断される。既存のリソースに関する設定変更の場合は、ステップＳ２０８に進み、そうではない場合は、ステップＳ２０９に進む。

【0068】

既存のリソースの設定変更が検出された場合（ステップＳ２０７で“Ｙｅｓ”）、設定変更反映部２６０は、システムソースコードに既存のインフラストラクチャーリソース２８３の追加を行う（ステップＳ２０８）。具体例としては、差分として得られた追加されたインフラストラクチャーリソース２８３の名前を用いて、あらかじめリポジトリ２２０に登録された各インフラストラクチャーリソース２８３のソースコードプログラムを検索する。その後、特定されたインフラストラクチャーリソース２８３のソースコードプログラムをシステムソースコードに追加する。なお、ここでは既存リソースの追加について説明したが、設定変更がリソースの削除である場合もあり、その場合にはソースコードプログラム内の該当するリソースを定義する部分を削除すればよい。

【0069】

上述の通り、システムソースコードのソースコードプログラムには、使用するインフラストラクチャーリソース２８３を定義する部分と、インフラストラクチャーリソース２８３の設定値２８２を定義、設定する部分が存在する。すなわち、システムソースコードに変更があった場合には、システムソースコード内の、使用するインフラストラクチャーリソース２８３を定義する部分に、登録されたソースコードプログラムのインフラストラクチャーリソース２８３を定義する部分を追加する。また、システムソースコード内の、インフラストラクチャーリソース２８３で使用する変数を定義する部分に、登録されたソースコードプログラムの使用する変数を定義する部分を追加する。そして、システムソースコード内の、インフラストラクチャーリソース２８３で使用する設定値２８２を設定する部分に、登録されたソースコードプログラムの使用する設定値２８２を設定する部分を、それぞれ追加する。

【0070】

ここで、使用する設定値２８２を設定する部分に関しては、差分情報の変数名とソースコードプログラムでの変数名の対応付けを行う必要がある。対応付けの方法は従来いくつか提案されている。例えば、差分情報で出力される変数名とソースコードプログラムの変数名の対応付けを予め人手により行う方法、差分情報で出力される変数名とソースコードプログラムの変数名の類似度を計算し対応付けを行う方法などである。これにより、元々のコーディングルールに基づいて設定変更を修正することが可能である。

【0071】

既存のリソースの設定変更が検出されない場合、すなわち、新規のインフラストラクチャーリソース２８３の追加が検出された場合には、設定変更反映部２６０は、新規のインフラストラクチャーリソース２８３のソースコードプログラムの取得を行い、コードディングルールに基づいて修正を行い、追加を行う（ステップＳ２０９）。この処理について図９を用いて詳述する。図９は、ステップＳ２０９における具体的な処理手順の一例を示すフローチャートである。以下図９の各ステップについて説明する。

【0072】

設定変更反映部２６０は、差分情報が含むインフラストラクチャーリソース２８３の名前から該当インフラストラクチャーリソース２８３のソースコードプログラムを検索する（ステップＳ３０１）。これは、具体例としては、Ｔｅｒｒａｆｏｒｍでは検索のためのＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅ）が公開されており、特定のＵＲＬに検索用のパラメタを追加して、検索結果を取得することができる。一例としては、「ｈｔｔｐｓ：／／ｒｅｇｉｓｔｒｙ．ｔｅｒｒａｆｏｒｍ．ｉｏ／ｖ１／ｍｏｄｕｌｅｓ／ｓｅａｒｃｈ？ｑ＝ｎｅｔｗｏｒｋ」に対し、ＧＥＴメソッドを行うことにより、「ｎｅｔｗｏｒｋ」という名前のリソースを検索することができる。また、利用者２０１が所属する団体で管理する共有リポジトリを設定してもよい。さらに、該当インフラストラクチャーリソース２８３の公式ページに記載されている該当インフラストラクチャーリソースを説明するページからソースコードプログラムの例をウェブスクレイピングにより取得してもよい。

【0073】

設定変更反映部２６０は、取得されたインフラストラクチャーリソース２８３のソースコードプログラムの精査を行う（ステップＳ３０２）。具体例としては、ステップＳ３０１で取得されたリソースのソースコードプログラムの候補が複数ある場合に、候補の中には、該当のインフラストラクチャーリソースを含まないソースコードプログラムが存在する可能性がある。そのため、複数候補のソースコードプログラムの解析を行い、該当インフラストラクチャーリソースの文字を含んでいるかを確認する。そのあと、その文字を含んでいないソースコードプログラムを候補から削除する。また、ソースコードプログラムが持つメタデータを用いて候補を精査してもよい。具体例としては、ソースコードプログラムの人気度を示すスターの数が多いものを選択してもよい。これにより、複数の取得されたソースコードプログラムから一つのソースコードプログラムを選択する。

【0074】

そして、設定変更反映部２６０は、ステップＳ３０２で行った精査により候補が存在するかどうかを確認する（ステップＳ３０３）。候補数が１の場合は、ステップＳ３０４に進み、候補数が０の場合は、処理を終了する。

【0075】

候補数が１であった場合（ステップＳ３０３で“Ｙｅｓ”）、設定変更反映部２６０は、ステップＳ３０２で精査を行い一つ選択されたソースコードプログラムの修正を行う（ステップＳ３０４）。ここで、ソースコードプログラムの修正とは、利用者２０１が指定したコーディングルールに基づいて、取得したソースコードプログラムを書き換えることを指す。コーディングルールの具体例としては、ソースコードプログラムの変数名を利用者２０１が指定する命名規則に従って変換する方法がある。これは、構築ツールでリソースに対して設定項目名は定義されているが、その設定項目名に対しての変数名は開発者が命名を行うため、その命名規則が統一されているとは限らないためである。

【0076】

該当の変数名について、ソースコードプログラムのコード解析を行う。コード解析の手法は、従来いくつか提案されている。例えば、ソースコードプログラムをプログラミング言語の文法に基づいて字句解析を行い、トークン列に変換する。変換したトークン列から木構造に変換する。変換結果の木構造を基づいて、変数名を確認し、命名規則に則って変換を行う。具体例としては、設定項目名にリソース名を前に追加しアンダーバーでつなげることや、すべて大文字にすることなどである。

【0077】

また、コーディングルールの他の例としては、ディレクトリ構成をもとのソースコードプログラムに合わせるというものがある。例えば、ソースコードプログラムとして、各リソースを別のソースコードプログラムファイルとして切り出して、それぞれをモジュールとして呼び出しを行う方式が存在する。その場合、ディレクトリ構成をモジュールとして呼び出しを行う方式と、一つのソースコードプログラムでディレクトリ構成を実現する方式でディレクトリ構成は異なる。モジュールとして呼び出しを行う方式の場合は、取得したソースコードプログラムをモジュールディレクトリ上に配置を行い、取得したソースコードプログラムを呼び出す部分を元々のソースコードプログラムに追加する。

【0078】

以上、設定変更反映部２６０が自動でソースコードプログラムの追加を行う説明を行ったが、方法は必ずしも自動追加に限るものではなく、その他利用者２０１に通知を行い、利用者２０１に新規リソースのソースコードプログラムを作成するように促し、作成されたソースコードプログラムを取得する形でもよい。

【0079】

本実施例に係るシステム構築装置１００は、システム２８１の設定変更を検出し、その設定変更をコーディングルールに基づいてシステムソースコードへ反映する。コーディングルールに基づいて設定変更を修正することにより、システム２８１の設定変更の反映について利用者２０１が想定したソースコードプログラムとして管理できる。したがってシステム構築装置１００は、利用者２０１が手動で設定変更を行った場合の構築情報への反映を自動で行うために余分な工数をかけることなく、また、自動の設定変更に対して自らのコーディングルールに基づいて修正する必要がないので、設定変更の反映作業の工数を抑制することができる。

【0080】

また、本実施例に係るシステム構築装置１００においては、利用者２０１がポータル画面２１０上でシステム２８１の機能要件と非機能要件を入力し、要件を満たすシステム２８１を提示し、利用者２０１がカスタマイズし、システム２８１の構築を自動で行う。これにより、利用者２０１はシステム２８１の設計やシステム２８１の自動構築技術の知識がない場合でも、要件にあったシステム２８１を作成することができる。

【0081】

＜実施例２＞
次に、本発明の実施例２に係るシステム構築装置について説明する。実施例１においては、利用者２０１がポータル画面２１０上でシステム２８１の機能要件と非機能要件を入力し、要件を満たすシステム２８１を提示し、利用者２０１がカスタマイズする例を説明した。実施例２では、ポータル画面２１０上での要件入力画面の表示を行わず、利用者２０１が記述したシステムソースコードに基づいてシステム構築を行う。これにより、利用者２０１がシステム２８１の自動構築技術に精通しているなど、利用者２０１が自らシステムソースコードを作成する場合においても、システムソースコードに基づいてシステム２８１を作成、管理することができる。

【0082】

図１０は、本実施形態２においてシステム構築装置１００がシステムを構築し管理する手順を説明するフローチャートである。以下図１０の各ステップについて説明する。

【0083】

システム構築装置１００は、利用者２０１からシステムソースコードを受け付ける（ステップＳ４０１）。受け付け方法の具体例としては、ポータル画面２１０上に図５Ｂと同様の画面を表示して、システムソースコードをアップロード可能にしてもよい。また、ポータル画面２１０にシステムソースコードを記述可能なテキストエディタを表示し、利用者２０１が直接システムソースコードを記述してもよい。

【0084】

デプロイ部２４０は、ステップＳ４０１で受け付けたシステムソースコードに基づいてデプロイ処理を行う（ステップＳ４０２）。この処理は図３のステップＳ１０４と同様である。本実施例においては、デプロイ処理をユーザが行ってもよい。その場合、Ｔｅｒｒａｆｒｏｍを用いる例としては、ユーザの環境でＴｅｒｒａｆｒｏｍの構築コマンドを用いてシステムの構築を行う。

【0085】

ステップＳ４０３及びＳ４０４は、図３のステップＳ１０６及びＳ１０７と同様である。本実施例において、デプロイ処理を利用者２０１が行った場合、設定変更を検出する対象のシステム２８１とシステムソースコードによる構築情報に関する情報をユーザが入力を行い、設定変更の検出と反映を行う。

【0086】

以上説明したように、本発明の実施例２では、利用者２０１が記述したシステムソースコードに基づいてシステム構築を行う。これにより、利用者２０１がシステムの自動構築技術に精通しているなど、利用者２０１が自らシステムソースコードを作成したい場合においても、システムソースコードに基づいてシステムを作成、管理することができる。

【0087】

以上で説明した本発明の実施例によれば、以下の作用効果を奏する。
（１）本発明に係るシステム構築装置は、所定の実行環境上にインフラストラクチャーリソース及び該インフラストラクチャーリソースの設定値を含むシステムを構築するシステム構築装置であって、所望の要件を満たすシステム構築の要求を入力する入力部と、所望の要件を満たすシステムを定義する第一ソースコードを作成するシステムソースコード作成部と、実行環境上に、システムを要求に基づいてデプロイして構築するデプロイ部と、実行環境上に構築されたシステムが変更された場合に、変更された該システムを定義する第二ソースコードと第一ソースコードとの差分を検出する設定変更検出部と、設定変更検出部により検出された差分を第一ソースコードに反映させる設定変更反映部と、を備え、設定変更反映部は、第一ソースコードに適用されたコーディングルールに基づいて差分を第一ソースコードに反映させる。

【0088】

上記構成により、ユーザがシステムの構築情報を変更せずにシステムの構成を変更した場合に、コーディングルールを統一した形で、当初のシステムの構築情報と変更されたシステムの構築情報との差異を修正することができる。

【0089】

（２）差分に設定値の変更が含まれる場合に、設定変更反映部は、第二ソースコードの設定値をコーディングルールに基づいて修正し、第一ソースコードを修正する。また、差分にインフラストラクチャーリソースの追加が含まれる場合に、設定変更反映部は、追加されたインフラストラクチャーリソースのソースコードを取得し、該ソースコードをコーディングルールに基づいて修正し、第一ソースコードを修正する。これにより、システムのソースコードに加えられる変更がどのような種類であっても、適切に修正を反映させることができる。

【0090】

（３）設定変更検出部は、システムを特定するメタデータに基づいて、追加されたインフラストラクチャーリソースが新規のインフラストラクチャーリソースであるか否か判定する。これにより、従来技術において想定されていなかった新規リソースの追加が行われていた場合にも、適切にソースコードを修正することが可能になる。

【0091】

（４）入力部はポータル画面表示部を含み、要件は機能要件と非機能要件とを含み、ポータル画面表示部は、入力された機能要件または非機能要件を満たすシステムの候補を利用者に提示する。これにより、利用者が機能要件と非機能要件とを切り分けて候補を選択することが可能になり、利用者にとって利便性が向上する。さらに、システムの候補が自動的に選択・提示されることにより、利用者に対して所望の要件を追加。修正するための気づきを与えることが可能になる。

【0092】

（５）デプロイ部は、提示されたシステムの候補に対する利用者の選択に基づいて、利用者が選択したシステムを構築するための構築情報を作成し、システムを実行環境上に構築する。これにより、システム構築装置のリポジトリ内に保存された情報を活用して、迅速なシステム構築を実現できる。

【0093】

本発明は、前述した実施形態に限定されるものではなく、様々な変形例が含まれる。例えば、上記した実施形態は本発明を分かりやすく説明するために詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。また、ある実施形態の構成の一部を他の実施形態の構成に置き換えることが可能であり、また、ある実施形態の構成に他の実施形態の構成を加えることも可能である。また、各実施形態の構成の一部について、他の構成の追加・削除・置換をすることが可能である。

【符号の説明】

【0094】

１００：システム構築装置、２１０：ポータル画面（入力部・ポータル画面表示部）、２２０：リポジトリ、２３０：システムソースコード作成部、２４０：デプロイ部、２５０：設定変更検出部、２６０：設定変更反映部、２７０：コーディングルール保存部、２８０：実行環境、２８１：システム、２８２：設定値、２８３：インフラストラクチャーリソース

【図1】

【図2】

【図3】

【図4】

【図5A】

【図5B】

【図5C】

【図6】

【図7】

【図8】

【図9】

【図10】