知財求人 - 知財ポータルサイト「IP Force」
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公開特許公報(A)
(11)【公開番号】P2024155168
(43)【公開日】2024-10-31
(54)【発明の名称】設計支援システム及び設計支援方法
(51)【国際特許分類】
G06F 8/61 20180101AFI20241024BHJP
【ＦＩ】
G06F8/61
【審査請求】未請求
【請求項の数】14
【出願形態】ＯＬ
(21)【出願番号】P 2023069628
(22)【出願日】2023-04-20
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．ＪＡＶＡＳＣＲＩＰＴ
(71)【出願人】
【識別番号】000005108
【氏名又は名称】株式会社日立製作所
(74)【代理人】
【識別番号】110002365
【氏名又は名称】弁理士法人サンネクスト国際特許事務所
(72)【発明者】
【氏名】久恒 泰地
(72)【発明者】
【氏名】齊藤 信一郎
【テーマコード（参考）】
5B376
【Ｆターム（参考）】
5B376AB04
5B376AB12
5B376AD19
5B376AD23
(57)【要約】
【課題】クラウドデプロイシステムのアーキテクチャ設計に関し、非機能要件の充足性が高いシステムアーキテクチャの候補の発見を効果的に行う。
【解決手段】クラウドデプロイシステムのアーキテクチャの設計支援を行う設計支援システムは、新規にクラウド上にデプロイする新規システムとクラウド上で稼働中の稼働システムとがリソースを共有した場合のアーキテクチャ候補と、共有しない場合のアーキテクチャ候補を作成する。リソースを共有した場合とリソースを共有しない場合の両方のケースのアーキテクチャ候補に対して、稼働システムの非機能要件と、新規システムの非機能要件とを充足するアーキテクチャ候補を、クラウド上にデプロイするアーキテクチャと決定する。
【選択図】図１９
【解決手段】クラウドデプロイシステムのアーキテクチャの設計支援を行う設計支援システムは、新規にクラウド上にデプロイする新規システムとクラウド上で稼働中の稼働システムとがリソースを共有した場合のアーキテクチャ候補と、共有しない場合のアーキテクチャ候補を作成する。リソースを共有した場合とリソースを共有しない場合の両方のケースのアーキテクチャ候補に対して、稼働システムの非機能要件と、新規システムの非機能要件とを充足するアーキテクチャ候補を、クラウド上にデプロイするアーキテクチャと決定する。
【選択図】図１９
【特許請求の範囲】
【請求項1】
多段のノードで構成される処理フローを有する新規システムをクラウド上にデプロイする際のアーキテクチャの設計を支援する設計支援システムであって、
前記設計支援システムは、
記憶部と、メモリと、前記メモリと協働するプロセッサと、を有し、
前記記憶部は、
前記クラウド上で稼働中の稼働システムが使用する前記クラウドのリソースを示す稼働システム構成情報と、
前記稼働システムが充足すべき非機能要件を示す稼働システム非機能要件情報と、
前記リソースの性能に関する制約を示す制約情報と、を格納し、
前記プロセッサは、
前記新規システムが前記クラウド上にデプロイされて稼働する際に使用する前記リソースの組合せを示す第一アーキテクチャ候補と、前記新規システムのアーキテクチャが充足すべき非機能要件を示す新規非機能要件と、の入力を受け付け、
前記第一アーキテクチャ候補が前記稼働システムと共有できる可能性がある前記リソースを含むか否かを判定し、
前記第一アーキテクチャ候補に含まれる前記稼働システムと共有できる可能性がある前記リソースを前記新規システムと前記稼働システムとが共有した場合に、該リソースに係る前記制約が充足されるか否かを判定し、
前記制約が充足される場合に、前記新規システムと前記稼働システムとが共有できる前記リソースの特定情報を含めた前記第一アーキテクチャ候補を第二アーキテクチャ候補に追加し、
前記新規システムと前記稼働システムとが前記リソースを共有しない場合の前記第一アーキテクチャ候補を前記第二アーキテクチャ候補に追加し、
前記第二アーキテクチャ候補が前記非機能要件と前記新規非機能要件とを充足するか否かを評価し、
前記非機能要件と前記新規非機能要件とを充足する前記第二アーキテクチャ候補を前記クラウド上にデプロイする前記新規システムのアーキテクチャと決定する
ことを特徴とする設計支援システム。
前記設計支援システムは、
記憶部と、メモリと、前記メモリと協働するプロセッサと、を有し、
前記記憶部は、
前記クラウド上で稼働中の稼働システムが使用する前記クラウドのリソースを示す稼働システム構成情報と、
前記稼働システムが充足すべき非機能要件を示す稼働システム非機能要件情報と、
前記リソースの性能に関する制約を示す制約情報と、を格納し、
前記プロセッサは、
前記新規システムが前記クラウド上にデプロイされて稼働する際に使用する前記リソースの組合せを示す第一アーキテクチャ候補と、前記新規システムのアーキテクチャが充足すべき非機能要件を示す新規非機能要件と、の入力を受け付け、
前記第一アーキテクチャ候補が前記稼働システムと共有できる可能性がある前記リソースを含むか否かを判定し、
前記第一アーキテクチャ候補に含まれる前記稼働システムと共有できる可能性がある前記リソースを前記新規システムと前記稼働システムとが共有した場合に、該リソースに係る前記制約が充足されるか否かを判定し、
前記制約が充足される場合に、前記新規システムと前記稼働システムとが共有できる前記リソースの特定情報を含めた前記第一アーキテクチャ候補を第二アーキテクチャ候補に追加し、
前記新規システムと前記稼働システムとが前記リソースを共有しない場合の前記第一アーキテクチャ候補を前記第二アーキテクチャ候補に追加し、
前記第二アーキテクチャ候補が前記非機能要件と前記新規非機能要件とを充足するか否かを評価し、
前記非機能要件と前記新規非機能要件とを充足する前記第二アーキテクチャ候補を前記クラウド上にデプロイする前記新規システムのアーキテクチャと決定する
ことを特徴とする設計支援システム。
【請求項2】
請求項１に記載の設計支援システムであって、
前記制約情報は、前記リソースの性能を向上させる際の閾値を含み、
前記プロセッサは、
前記第一アーキテクチャ候補が前記稼働システムと共有される前記リソースを含む際に該リソースに係る前記制約が充足されない場合、前記閾値の範囲内で該リソースの性能を向上させたときに該リソースに係る前記制約が充足されるか否かを判定し、
前記性能を向上させた前記リソースを共有可能である前記第一アーキテクチャ候補を前記第二アーキテクチャ候補に追加する
ことを特徴とする設計支援システム。
前記制約情報は、前記リソースの性能を向上させる際の閾値を含み、
前記プロセッサは、
前記第一アーキテクチャ候補が前記稼働システムと共有される前記リソースを含む際に該リソースに係る前記制約が充足されない場合、前記閾値の範囲内で該リソースの性能を向上させたときに該リソースに係る前記制約が充足されるか否かを判定し、
前記性能を向上させた前記リソースを共有可能である前記第一アーキテクチャ候補を前記第二アーキテクチャ候補に追加する
ことを特徴とする設計支援システム。
【請求項3】
請求項１に記載の設計支援システムであって、
前記記憶部は、
前記新規システムを構成するシステム要素に対して該システム要素の性能値を含む特徴を対応付けた特徴情報を格納し、
前記プロセッサは、
前記処理フローの入力を受け付け、
前記処理フローを、複数の前記ノードへ分割し、
複数の前記ノードに対して前記新規非機能要件を充足することができる各前記システム要素と各前記システム要素の性能値を決定し、
複数の前記システム要素の組合せを前記第一アーキテクチャ候補として生成する
ことを特徴とする設計支援システム。
前記記憶部は、
前記新規システムを構成するシステム要素に対して該システム要素の性能値を含む特徴を対応付けた特徴情報を格納し、
前記プロセッサは、
前記処理フローの入力を受け付け、
前記処理フローを、複数の前記ノードへ分割し、
複数の前記ノードに対して前記新規非機能要件を充足することができる各前記システム要素と各前記システム要素の性能値を決定し、
複数の前記システム要素の組合せを前記第一アーキテクチャ候補として生成する
ことを特徴とする設計支援システム。
【請求項4】
請求項１に記載の設計支援システムであって、
前記処理フローは、入力ノードと加工・出力ノードとを含んで構成される
ことを特徴とする設計支援システム。
前記処理フローは、入力ノードと加工・出力ノードとを含んで構成される
ことを特徴とする設計支援システム。
【請求項5】
請求項４に記載の設計支援システムであって、
前記記憶部は、
キューに対して該キューの性能値を含む特徴を対応付けたキュー特徴情報と、
処理システムに対して該処理システムの性能値を含む特徴を対応付けた処理システム特徴情報と、
前記加工・出力ノードの処理負荷を該加工・出力ノードを構成する関数の処理に係る負荷を合計して算出する際の該関数に該負荷を対応付けたノード負荷情報と、
前記処理負荷に対して前記処理システムが該処理負荷の処理に必要とする性能値を対応付けた負荷・性能対応情報と、を格納し、
前記プロセッサは、
前記処理フローの入力を受け付け、
前記処理フローを、入力ノードと加工・出力ノードへ分割し、
前記キュー特徴情報に基づいて、前記入力ノードに対して前記新規非機能要件を充足することができる前記キューと前記キューの性能値を決定し、
前記処理システム特徴情報、前記ノード負荷情報、及び前記負荷・性能対応情報に基づいて、前記加工・出力ノードに対して前記新規非機能要件を充足することができる前記処理システムと該処理システムの前記性能値を決定し、
前記キューと前記処理システムの組合せを前記第一アーキテクチャ候補として生成する
ことを特徴とする設計支援システム。
前記記憶部は、
キューに対して該キューの性能値を含む特徴を対応付けたキュー特徴情報と、
処理システムに対して該処理システムの性能値を含む特徴を対応付けた処理システム特徴情報と、
前記加工・出力ノードの処理負荷を該加工・出力ノードを構成する関数の処理に係る負荷を合計して算出する際の該関数に該負荷を対応付けたノード負荷情報と、
前記処理負荷に対して前記処理システムが該処理負荷の処理に必要とする性能値を対応付けた負荷・性能対応情報と、を格納し、
前記プロセッサは、
前記処理フローの入力を受け付け、
前記処理フローを、入力ノードと加工・出力ノードへ分割し、
前記キュー特徴情報に基づいて、前記入力ノードに対して前記新規非機能要件を充足することができる前記キューと前記キューの性能値を決定し、
前記処理システム特徴情報、前記ノード負荷情報、及び前記負荷・性能対応情報に基づいて、前記加工・出力ノードに対して前記新規非機能要件を充足することができる前記処理システムと該処理システムの前記性能値を決定し、
前記キューと前記処理システムの組合せを前記第一アーキテクチャ候補として生成する
ことを特徴とする設計支援システム。
【請求項6】
請求項１に記載の設計支援システムであって、
前記プロセッサは、
前記新規非機能要件の中で優先する非機能要件を示す優先要件の入力を受け付け、
前記非機能要件と前記新規非機能要件とを充足する前記第二アーキテクチャ候補が複数存在する場合に、前記優先要件に基づいて、前記クラウドにデプロイする前記新規システムのアーキテクチャを決定する
ことを特徴とする設計支援システム。
前記プロセッサは、
前記新規非機能要件の中で優先する非機能要件を示す優先要件の入力を受け付け、
前記非機能要件と前記新規非機能要件とを充足する前記第二アーキテクチャ候補が複数存在する場合に、前記優先要件に基づいて、前記クラウドにデプロイする前記新規システムのアーキテクチャを決定する
ことを特徴とする設計支援システム。
【請求項7】
請求項１に記載の設計支援システムであって、
前記プロセッサは、
前記クラウドにデプロイすると決定した前記第二アーキテクチャ候補を前記クラウド上にデプロイし、
前記新規非機能要件を前記稼働システム非機能要件情報に追加する
ことを特徴とする設計支援システム。
前記プロセッサは、
前記クラウドにデプロイすると決定した前記第二アーキテクチャ候補を前記クラウド上にデプロイし、
前記新規非機能要件を前記稼働システム非機能要件情報に追加する
ことを特徴とする設計支援システム。
【請求項8】
多段のノードで構成される処理フローを有する新規システムをクラウド上にデプロイする際のアーキテクチャの設計を支援する設計支援システムが行う設計支援方法であって、
前記設計支援システムは、
記憶部と、メモリと、前記メモリと協働するプロセッサと、を有し、
前記記憶部は、
前記クラウド上で稼働中の稼働システムが使用する前記クラウドのリソースを示す稼働システム構成情報と、
前記稼働システムが充足すべき非機能要件を示す稼働システム非機能要件情報と、
前記リソースの性能に関する制約を示す制約情報と、を格納し、
前記プロセッサが、
前記新規システムが前記クラウド上にデプロイされて稼働する際に使用する前記リソースの組合せを示す第一アーキテクチャ候補と、前記新規システムのアーキテクチャが充足すべき非機能要件を示す新規非機能要件と、の入力を受け付け、
前記第一アーキテクチャ候補が前記稼働システムと共有できる可能性がある前記リソースを含むか否かを判定し、
前記第一アーキテクチャ候補に含まれる前記稼働システムと共有できる可能性がある前記リソースを前記新規システムと前記稼働システムとが共有した場合に、該リソースに係る前記制約が充足されるか否かを判定し、
前記制約が充足される場合に、前記新規システムと前記稼働システムとが共有できる前記リソースの特定情報を含めた前記第一アーキテクチャ候補を第二アーキテクチャ候補に追加し、
前記新規システムと前記稼働システムとが前記リソースを共有しない場合の前記第一アーキテクチャ候補を前記第二アーキテクチャ候補に追加し、
前記第二アーキテクチャ候補が前記非機能要件と前記新規非機能要件とを充足するか否かを評価し、
前記非機能要件と前記新規非機能要件とを充足する前記第二アーキテクチャ候補を前記クラウド上にデプロイする前記新規システムのアーキテクチャと決定する
各処理を有することを特徴とする設計支援方法。
前記設計支援システムは、
記憶部と、メモリと、前記メモリと協働するプロセッサと、を有し、
前記記憶部は、
前記クラウド上で稼働中の稼働システムが使用する前記クラウドのリソースを示す稼働システム構成情報と、
前記稼働システムが充足すべき非機能要件を示す稼働システム非機能要件情報と、
前記リソースの性能に関する制約を示す制約情報と、を格納し、
前記プロセッサが、
前記新規システムが前記クラウド上にデプロイされて稼働する際に使用する前記リソースの組合せを示す第一アーキテクチャ候補と、前記新規システムのアーキテクチャが充足すべき非機能要件を示す新規非機能要件と、の入力を受け付け、
前記第一アーキテクチャ候補が前記稼働システムと共有できる可能性がある前記リソースを含むか否かを判定し、
前記第一アーキテクチャ候補に含まれる前記稼働システムと共有できる可能性がある前記リソースを前記新規システムと前記稼働システムとが共有した場合に、該リソースに係る前記制約が充足されるか否かを判定し、
前記制約が充足される場合に、前記新規システムと前記稼働システムとが共有できる前記リソースの特定情報を含めた前記第一アーキテクチャ候補を第二アーキテクチャ候補に追加し、
前記新規システムと前記稼働システムとが前記リソースを共有しない場合の前記第一アーキテクチャ候補を前記第二アーキテクチャ候補に追加し、
前記第二アーキテクチャ候補が前記非機能要件と前記新規非機能要件とを充足するか否かを評価し、
前記非機能要件と前記新規非機能要件とを充足する前記第二アーキテクチャ候補を前記クラウド上にデプロイする前記新規システムのアーキテクチャと決定する
各処理を有することを特徴とする設計支援方法。
【請求項9】
請求項８に記載の設計支援方法であって、
前記制約情報は、前記リソースの性能を向上させる際の閾値を含み、
前記プロセッサが、
前記第一アーキテクチャ候補が前記稼働システムと共有される前記リソースを含む際に該リソースに係る前記制約が充足されない場合、前記閾値の範囲内で該リソースの性能を向上させたときに該リソースに係る前記制約が充足されるか否かを判定し、
前記性能を向上させた前記リソースを共有可能である前記第一アーキテクチャ候補を前記第二アーキテクチャ候補に追加する
各処理を有することを特徴とする設計支援方法。
前記制約情報は、前記リソースの性能を向上させる際の閾値を含み、
前記プロセッサが、
前記第一アーキテクチャ候補が前記稼働システムと共有される前記リソースを含む際に該リソースに係る前記制約が充足されない場合、前記閾値の範囲内で該リソースの性能を向上させたときに該リソースに係る前記制約が充足されるか否かを判定し、
前記性能を向上させた前記リソースを共有可能である前記第一アーキテクチャ候補を前記第二アーキテクチャ候補に追加する
各処理を有することを特徴とする設計支援方法。
【請求項10】
請求項８に記載の設計支援方法であって、
前記記憶部は、
前記新規システムを構成するシステム要素に対して該システム要素の性能値を含む特徴を対応付けた特徴情報を格納し、
前記プロセッサが、
前記処理フローの入力を受け付け、
前記処理フローを、複数の前記ノードへ分割し、
複数の前記ノードに対して前記新規非機能要件を充足することができる各前記システム要素と各前記システム要素の性能値を決定し、
複数の前記システム要素の組合せを前記第一アーキテクチャ候補として生成する
各処理を有することを特徴とする設計支援方法。
前記記憶部は、
前記新規システムを構成するシステム要素に対して該システム要素の性能値を含む特徴を対応付けた特徴情報を格納し、
前記プロセッサが、
前記処理フローの入力を受け付け、
前記処理フローを、複数の前記ノードへ分割し、
複数の前記ノードに対して前記新規非機能要件を充足することができる各前記システム要素と各前記システム要素の性能値を決定し、
複数の前記システム要素の組合せを前記第一アーキテクチャ候補として生成する
各処理を有することを特徴とする設計支援方法。
【請求項11】
請求項８に記載の設計支援方法であって、
前記処理フローは、入力ノードと加工・出力ノードとを含んで構成される
ことを特徴とする設計支援方法。
前記処理フローは、入力ノードと加工・出力ノードとを含んで構成される
ことを特徴とする設計支援方法。
【請求項12】
請求項１１に記載の設計支援方法であって、
前記記憶部は、
キューに対して該キューの性能値を含む特徴を対応付けたキュー特徴情報と、
処理システムに対して該処理システムの性能値を含む特徴を対応付けた処理システム特徴情報と、
前記加工・出力ノードの処理負荷を該加工・出力ノードを構成する関数の処理に係る負荷を合計して算出する際の該関数に該負荷を対応付けたノード負荷情報と、
前記処理負荷に対して前記処理システムが該処理負荷の処理に必要とする性能値を対応付けた負荷・性能対応情報と、を格納し、
前記プロセッサが、
前記処理フローの入力を受け付け、
前記処理フローを、入力ノードと加工・出力ノードへ分割し、
前記キュー特徴情報に基づいて、前記入力ノードに対して前記新規非機能要件を充足することができる前記キューと前記キューの性能値を決定し、
前記処理システム特徴情報、前記ノード負荷情報、及び前記負荷・性能対応情報に基づいて、前記加工・出力ノードに対して前記新規非機能要件を充足することができる前記処理システムと該処理システムの前記性能値を決定し、
前記キューと前記処理システムの組合せを前記第一アーキテクチャ候補として生成する
各処理を有することを特徴とする設計支援方法。
前記記憶部は、
キューに対して該キューの性能値を含む特徴を対応付けたキュー特徴情報と、
処理システムに対して該処理システムの性能値を含む特徴を対応付けた処理システム特徴情報と、
前記加工・出力ノードの処理負荷を該加工・出力ノードを構成する関数の処理に係る負荷を合計して算出する際の該関数に該負荷を対応付けたノード負荷情報と、
前記処理負荷に対して前記処理システムが該処理負荷の処理に必要とする性能値を対応付けた負荷・性能対応情報と、を格納し、
前記プロセッサが、
前記処理フローの入力を受け付け、
前記処理フローを、入力ノードと加工・出力ノードへ分割し、
前記キュー特徴情報に基づいて、前記入力ノードに対して前記新規非機能要件を充足することができる前記キューと前記キューの性能値を決定し、
前記処理システム特徴情報、前記ノード負荷情報、及び前記負荷・性能対応情報に基づいて、前記加工・出力ノードに対して前記新規非機能要件を充足することができる前記処理システムと該処理システムの前記性能値を決定し、
前記キューと前記処理システムの組合せを前記第一アーキテクチャ候補として生成する
各処理を有することを特徴とする設計支援方法。
【請求項13】
請求項８に記載の設計支援方法であって、
前記プロセッサが、
前記新規非機能要件の中で優先する非機能要件を示す優先要件の入力を受け付け、
前記非機能要件と前記新規非機能要件とを充足する前記第二アーキテクチャ候補が複数存在する場合に、前記優先要件に基づいて、前記クラウドにデプロイする前記新規システムのアーキテクチャを決定する
ことを特徴とする設計支援方法。
前記プロセッサが、
前記新規非機能要件の中で優先する非機能要件を示す優先要件の入力を受け付け、
前記非機能要件と前記新規非機能要件とを充足する前記第二アーキテクチャ候補が複数存在する場合に、前記優先要件に基づいて、前記クラウドにデプロイする前記新規システムのアーキテクチャを決定する
ことを特徴とする設計支援方法。
【請求項14】
請求項８に記載の設計支援方法であって、
前記プロセッサが、
前記クラウドにデプロイすると決定した前記第二アーキテクチャ候補を前記クラウド上にデプロイし、
前記新規非機能要件を前記稼働システム非機能要件情報に追加する
各処理を有することを特徴とする設計支援方法。
前記プロセッサが、
前記クラウドにデプロイすると決定した前記第二アーキテクチャ候補を前記クラウド上にデプロイし、
前記新規非機能要件を前記稼働システム非機能要件情報に追加する
各処理を有することを特徴とする設計支援方法。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、クラウドデプロイシステムの設計支援システム及び設計支援方法に関する。
【背景技術】
【0002】
近年クラウドコンピューティング技術の発展によって、データの収集・加工・蓄積・可視化など様々な処理機能がSoftware as a Service（ＳａａＳ）としてクラウドベンダから提供されている。これらクラウドサービス及びその組合せからなるシステムは、ハードウェアのリソース制約に縛られずに柔軟に性能を変更することが可能である。ＩＴシステムのアーキテクチャ設計者は、従来では限られたハードウェアリソースの下で要件に応じて処理システムを構築する手法から、クラウド上のＳａａＳから要件に応じて各処理機能サービスを選択し、それらの性能と組合せを設計する手法へと、開発手法を変化させてきている。
【0003】
一方でコストやマネージメント性など求められている非機能要件を満たしたアーキテクチャを設計するためには、複数のアーキテクチャ候補の中から最適なものを選択する必要がある。特にクラウドサービスの多くは従量課金性であるため、処理機能サービスの性能向上や全体のリソース量の増加は、使用料金の増加を招く。
【0004】
例えば特許文献１には、クラウドにおける非機能要件を満たしたアーキテクチャの設計手法として、「過去設計されたシステムの設計情報と当該設計情報が実現する要件とを対応付けて格納した第１のテーブルと、前記第１のテーブルが含む設計情報同士を組合せ利用する適性について、該当組合せ利用の実績に基づき順位付けして管理する第２のテーブルと、を記憶する記憶装置と、新規設計対象のシステムに関する複数の要件それぞれを実現する設計情報を、前記記憶装置の前記第１のテーブルで特定し、当該特定の結果、いずれかの要件について複数の設計情報を特定した場合、前記複数の設計情報それぞれと、前記複数の要件のうち他要件に関して特定された設計情報との組合せ利用の適性順位を、前記記憶装置の前記第２のテーブルで参照して、前記適性順位がより高い組合せとなる設計情報を前記複数の設計情報から特定し、前記複数の要件それぞれについて特定した設計情報を所定装置に出力する演算装置とを備えることを特徴とするシステム設計支援装置。」が開示されている。
【先行技術文献】
【特許文献】
【0005】
【特許文献1】特開２０１６－１１０３２５号公報
【発明の概要】
【発明が解決しようとする課題】
【0006】
しかし、上述の従来技術では、既にクラウドへ他のシステムがデプロイされ稼働している状況を想定していない。既存システムがデプロイされているクラウドに新規システムをさらにデプロイする場合、既存システムとキューやデータベース、処理ユニットなどリソースを既存システムと新規システムとで共有することで、クラウド全体のコストの削減や、安定性の向上、運用容易化ができるケースが存在する。
【0007】
よって非機能要件評価では、リソースを共有した場合の候補とリソースを共有しない場合の候補を含めた評価が必要であるが、従来技術では、リソースを共有する場合の候補を含めた評価が困難であった。このため、非機能要件の充足性が高いシステムアーキテクチャの候補の発見を効果的に行うことが困難であるという問題があった。
【0008】
本発明は、上記を考慮してなされたものであり、クラウドデプロイシステムのアーキテクチャ設計に関し、非機能要件の充足性が高いシステムアーキテクチャの候補の発見を効果的に行うことを目的とする。
【課題を解決するための手段】
【0009】
上記課題を解決する一態様として、多段のノードで構成される処理フローを有する新規システムをクラウド上にデプロイする際のアーキテクチャの設計を支援する設計支援システムであって、前記設計支援システムは、記憶部と、メモリと、前記メモリと協働するプロセッサと、を有し、前記記憶部は、前記クラウド上で稼働中の稼働システムが使用する前記クラウドのリソースを示す稼働システム構成情報と、前記稼働システムが充足すべき非機能要件を示す稼働システム非機能要件情報と、前記リソースの性能に関する制約を示す制約情報と、を格納し、前記プロセッサは、前記新規システムが前記クラウド上にデプロイされて稼働する際に使用する前記リソースの組合せを示す第一アーキテクチャ候補と、前記新規システムのアーキテクチャが充足すべき非機能要件を示す新規非機能要件と、の入力を受け付け、前記第一アーキテクチャ候補が前記稼働システムと共有できる可能性がある前記リソースを含むか否かを判定し、前記第一アーキテクチャ候補に含まれる前記稼働システムと共有できる可能性がある前記リソースを前記新規システムと前記稼働システムとが共有した場合に、該リソースに係る前記制約が充足されるか否かを判定し、前記制約が充足される場合に、前記新規システムと前記稼働システムとが共有できる前記リソースの特定情報を含めた前記第一アーキテクチャ候補を第二アーキテクチャ候補に追加し、前記新規システムと前記稼働システムとが前記リソースを共有しない場合の前記第一アーキテクチャ候補を前記第二アーキテクチャ候補に追加し、前記第二アーキテクチャ候補が前記非機能要件と前記新規非機能要件とを充足するか否かを評価し、前記非機能要件と前記新規非機能要件とを充足する前記第二アーキテクチャ候補を前記クラウド上にデプロイする前記新規システムのアーキテクチャと決定することを特徴とする。
【発明の効果】
【0010】
本発明によれば、リソースを共有した場合の候補を非機能要件の評価対象へ含めることにより、リソースを共有しない場合の候補のみを評価した場合と比較して、非機能要件の充足性が高いシステムアーキテクチャの候補の発見を効果的に行うことがきる。
【図面の簡単な説明】
【0011】
【図1】実施形態１に係る設計支援システムと設計支援画面及び関連するクラウドシステムとの関係を示す図。
【図2】実施形態１に係る設計支援システムを構成するハードウェアの一例を示す図。
【図3】実施形態１に係る設計支援画面の一例を示す図。
【図4】実施形態１に係る設計支援画面で設計者が入力する処理フローの一例を示す図。
【図5】実施形態１に係る第一アーキテクチャ候補生成処理の一例を示すフローチャート。
【図6】実施形態１に係る性能決定ＤＢが有するキュー特徴表の一例を示す図。
【図7】実施形態１に係る設計支援画面で設計者が入力する非機能要件の一例を示す図。
【図8】実施形態１に係るアーキテクチャ候補生成部においてデプロイするキューの性能の候補を示すキュー性能候補リストの一例を示す図。
【図9】実施形態１に係る性能決定ＤＢが有する処理システム特徴表の一例を示す図。
【図10】実施形態１に係るアーキテクチャ候補生成部において処理負荷を判断するために加工・出力ノードを処理記述へ変換した一例を示す図。
【図11】実施形態１に係る性能決定ＤＢが有するノード負荷表の一例を示す図。
【図12】実施例１に係る性能決定ＤＢが持つ負荷・性能対応表の一例を示す図。
【図13】実施形態１に係るアーキテクチャ候補生成部においてデプロイする処理システムの性能を候補として列挙した処理システム性能候補リストの一例を示す図。
【図14】実施形態１に係るアーキテクチャ候補生成部においてデプロイするアーキテクチャを第一アーキテクチャ候補リストとして列挙した一例を示す図。
【図15】実施形態１に係るリソース共有候補生成処理の一例を示すフローチャート。
【図16】実施形態１に係る評価デプロイ部が評価する際に用いる稼働システム構成表の一例を示す図。
【図17】実施形態１に係る性能決定ＤＢが有する制約表の一例を示す図。
【図18】実施形態１に係るリソース共有候補生成部がリソース共有を考慮したアーキテクチャ候補を第二アーキテクチャ候補リストとして列挙した一例を示す図。
【図19】実施形態１に係る評価・デプロイ処理の一例を示すフローチャート。
【図20】実施形態１に係る性能決定ＤＢが有する稼働システム非機能要件表の一例を示す図。
【図21】実施形態１に係る評価・デプロイ部において設計者の入力した非機能要件に基づいてアーキテクチャを評価した結果を示すアーキテクチャ評価表を示す図。
【図22】実施形態１に係る設計支援システムがアーキテクチャをデプロイした結果を示すアーキテクチャデプロイ表である。
【図23】実施形態２に係る設計支援システムと設計支援画面及び関連するクラウドシステムとの関係を示す図である。
【発明を実施するための形態】
【0012】
以下、図面を参照して本願開示に係る一実施形態を説明する。実施形態は、図面も含めて本願を説明するための例示である。実施形態では、説明の明確化のため、適宜、省略及び簡略化がされている。特に限定しない限り、実施形態の構成要素は単数でも複数でもよい。また、ある実施形態と他の実施形態を組み合わせた形態も、本願開示に係る実施形態に含まれる。
【0013】
以下の説明では、同一又は類似の構成要素には、同一の符号を付与し、後出の実施形態及び実施例では、説明を省略する、又は差分を中心とした説明のみを行う場合がある。また、同一又は類似の構成要素が複数ある場合には、同一の符号に異なる添字を付して説明する場合がある。また、これらの複数の構成要素を区別する必要がない場合には、添字を省略して説明する場合がある。各構成要素の数は、特に断りがない限り単数でも複数でもよい。
【0014】
以下の説明では、表（テーブル）の形式で各種情報を説明するが、各種情報は表以外のデータ構造で表現されていてもよい。「ＸＸ表」は、データ構造に依存しないため、「ＸＸ情報」と呼ぶことができる。各種情報のレコードを識別する情報として「番号」の表現を用いるが、「番号」「識別情報」「識別子」「名」「ＩＤ」等は互換可能である。
【0015】
以下の説明では、プログラムが行う処理について説明する場合がある。コンピュータは、プロセッサ（例えばＣＰＵ（Central Processing Unit）、ＧＰＵ（Graphics Processing Unit））により、主記憶装置のメモリ等を用いながら、プログラムで定められた処理を行う。そのため、プログラムを実行して行う処理の主体を、プロセッサとしてもよい。プロセッサがプログラムを実行することで、処理を行う機能部が実現される。
【0016】
同様に、プログラムを実行して行う処理の主体が、プロセッサを有するコントローラ、装置、システム、計算機、ノードであってもよい。プログラムを実行して行う処理の主体は、演算部であればよく、特定の処理を行う専用回路を含んでいてもよい。専用回路は、例えばＦＰＧＡ（Field Programmable Gate Array）やＡＳＩＣ（Application Specific Integrated Circuit）等である。
【0017】
以下の説明では、プログラムは、プログラムソースから計算機にインストールされてもよい。プログラムソースは、例えば、プログラム配布サーバ又は計算機が読取り可能な非一時的な記憶メディアであってもよい。プログラムソースがプログラム配布サーバの場合、プログラム配布サーバはプロセッサと配布対象のプログラムを記憶する記憶資源（ストレージ）を含み、プログラム配布サーバのプロセッサが配布対象のプログラムを他の計算機に配布してもよい。また、実施形態において、２以上のプログラムが１つのプログラムとして実現されてもよいし、１つのプログラムが２以上のプログラムとして実現されてもよい。
【0018】
なお以下で説明する実施形態及び図面で示すAWS、Azure、Java、JavaScript、Kinesis、S3、MSK、Kafka、Event Hubs、Lambda、Glue、EC2、Logstashは、登録商標である。
【0019】
［実施形態１］
実施形態１は、リアルタイムに生成されるセンサや環境情報などのＩｏＴ（Internet of Things）データを入力とし、ストリーム処理をするシステムのクラウド上へのデプロイを想定した形態である。そのために本実施形態では、システムが有する処理フローを、処理システムとキューの各システム要素へ分けてアーキテクチャ候補を生成している。しかし本発明にかかる解決手法は、ストリーム処理のシステムに限らず、多段のノードで構成される処理フローを有するシステムに対して広く適用可能である。
実施形態１は、リアルタイムに生成されるセンサや環境情報などのＩｏＴ（Internet of Things）データを入力とし、ストリーム処理をするシステムのクラウド上へのデプロイを想定した形態である。そのために本実施形態では、システムが有する処理フローを、処理システムとキューの各システム要素へ分けてアーキテクチャ候補を生成している。しかし本発明にかかる解決手法は、ストリーム処理のシステムに限らず、多段のノードで構成される処理フローを有するシステムに対して広く適用可能である。
【0020】
＜システム構成＞
（実施形態１に係る設計支援システム１０１）
図１は、実施形態１に係る設計支援システム１０１と設計支援画面１００及び関連するクラウド環境（クラウドシステム）１０２との関係を示す図である。本実施形態に係る設計支援システム１０１は、設計支援画面１００から入力された情報に基づいて、クラウド環境１０２にデプロイする際のシステムのアーキテクチャを設計し、設計したシステムのアーキテクチャをクラウド環境１０２にデプロイする。
（実施形態１に係る設計支援システム１０１）
図１は、実施形態１に係る設計支援システム１０１と設計支援画面１００及び関連するクラウド環境（クラウドシステム）１０２との関係を示す図である。本実施形態に係る設計支援システム１０１は、設計支援画面１００から入力された情報に基づいて、クラウド環境１０２にデプロイする際のシステムのアーキテクチャを設計し、設計したシステムのアーキテクチャをクラウド環境１０２にデプロイする。
【0021】
設計支援画面１００は、設計支援システム１０１に接続される端末に表示され、設計者２００による新規システムの設計を支援する。設計支援画面１００を通じて設計されたシステムは、処理フロー１０３、非機能要件１０４、及び優先要件１０５として出力される。
【0022】
設計支援システム１０１は、性能決定ＤＢ１０９と、アーキテクチャ候補生成部１０６、リソース共有候補生成部１０７、及び評価・デプロイ部１０８を有する。また設計支援システム１０１は、処理の中間生成リストとして、キュー性能候補リスト１１６、処理システム性能候補リスト１１７、稼働システム構成表１１８、第一アーキテクチャ候補リスト１１９、及び第二アーキテクチャ候補リスト１２０を有する。
【0023】
性能決定ＤＢ１０９は、各処理部が処理で用いる表を格納するＤＢ（Data Base）である。アーキテクチャ候補生成部１０６は、キュー特徴表１１０、処理システム特徴表１１１、ノード負荷表１１３、及び負荷・性能対応表１１４を用いる。リソース共有候補生成部は、制約表１１２を用いる。評価・デプロイ部１０８は、稼働システム非機能要件表１１５を用いる。評価・デプロイ部１０８は、非機能要件を満たすアーキテクチャを選択し、クラウド環境１０２へデプロイする機能を持つ。
【0024】
クラウド環境１０２は、ネットワークを介して設計支援システム１０１と接続されたクラウド上に存在し、内部では稼働システム１２２が動作しているものとする。クラウド環境１０２は、複数存在することも可能であり、同一のベンダが提供するクラウド環境であっても、異なるベンダが提供するクラウド環境であってもよい。各クラウド環境１０２には、サービスマネージャ１２１が存在し、設計支援システム１０１から送信される状態確認コマンド等を受け付け、現在の稼働システム１２２の状況を応答できる機能を持つ。
【0025】
（実施形態１に係る設計支援システム１０１のハードウェア）
図２は、実施形態１に係る設計支援システム１０１を構成するハードウェアの一例を示す図である。設計支援画面１００及び設計支援システム１０１は、計算装置２０００上で動作する。計算装置２０００は、プロセッサ２００３、メモリ２００４、及びストレージ装置２００５を有する計算機である。計算装置２０００は、入力装置２００６としてマウスやキーボード等を接続することができる。計算装置２０００は、出力装置２００７としてディスプレイ等を接続することができる。設計者２００は、入力装置２００６及び出力装置２００７を用いて設計支援画面１００を操作することができる。
図２は、実施形態１に係る設計支援システム１０１を構成するハードウェアの一例を示す図である。設計支援画面１００及び設計支援システム１０１は、計算装置２０００上で動作する。計算装置２０００は、プロセッサ２００３、メモリ２００４、及びストレージ装置２００５を有する計算機である。計算装置２０００は、入力装置２００６としてマウスやキーボード等を接続することができる。計算装置２０００は、出力装置２００７としてディスプレイ等を接続することができる。設計者２００は、入力装置２００６及び出力装置２００７を用いて設計支援画面１００を操作することができる。
【0026】
計算装置２０００は、ネットワークＩＦ（Inert Face）２００１を介してインターネット２００２を介してクラウド環境２００８へ接続することができる。クラウド環境２００８上には、仮想計算装置２００９が複数配置される。稼働システム１２２は、仮想計算装置２００９上で、プロセッサ２０１１及びストレージ装置２０１０を用いて動作する。この時、稼働システム１２２は、複数の仮想計算装置２００９が連携して動作する形であっても良い。
【0027】
＜アーキテクチャの設計及びクラウドデプロイ処理＞
以下に設計者２００が設計支援画面１００へ情報を入力してからアーキテクチャがデプロイされるまでの処理手順を示す。
以下に設計者２００が設計支援画面１００へ情報を入力してからアーキテクチャがデプロイされるまでの処理手順を示す。
【0028】
（実施形態１に係る設計支援画面１００）
図３は、実施形態１に係る設計支援画面１００の一例を示す図である。図４は、実施形態１に係る設計支援画面１００で設計者２００が入力する処理フロー１０３の一例を示す図である。
図３は、実施形態１に係る設計支援画面１００の一例を示す図である。図４は、実施形態１に係る設計支援画面１００で設計者２００が入力する処理フロー１０３の一例を示す図である。
【0029】
設計支援画面１００は、設計者が処理フロー１０３、非機能要件１０４、優先要件１０５を設計する画面である。設計支援画面１００は、フローベースプログラミング環境にて提供されている。フローベースプログラミングでは、ノード１９２と呼ばれる処理モジュールをエッジによって接続することでノーコードに処理システムを設計することができるプログラミング環境である。設計者２００は、表示領域１９１に用意されたノード群から実装したい処理を実行するノード１９２を選択し配置することで、処理フロー１０３を設計することができる。
【0030】
本実施形態では、図４に示すように、ストリーム処理を実現する多段のノード１９２には、入力ノード４０１、加工ノード４０２、出力ノード４０３のカテゴリがある。入力ノード４０１、加工ノード４０２、出力ノード４０３の順でノードを接続することが制約となっている。なお、加工ノード４０２と出力ノード４０３をまとめて、加工・出力ノードという。
【0031】
入力ノード４０１では、レコードが入力されるポート番号やフォーマット等を指定する。加工ノード４０２では、ストリーム処理としてレコードを加工する処理を指定する。出力ノード４０３では、加工したレコードを出力するＤＢ情報等の出力先を指定する。
【0032】
非機能要件１９４は、処理フローに加えて設計者２００が非機能要件を入力できる入力欄である。非機能要件１９４には、処理フローを実装する際のクラウドの利用料や運用方法、スケーラビリティ性等を指定することができる。例えば図３に示す非機能要件１９４の入力例では、コストが月額３００＄以下であり、フルマネージドな運用サービスを利用し、秒間１００レコードの受付を可能とし、負荷に応じたスケーリングができるアーキテクチャである事が要件として指定されている。
【0033】
設計者２００は、加えて、優先要件１９５として非機能要件１０４のうち優先したい項目を指定することができる。設計支援システム１０１が複数の候補を選出した時、本優先要件１９５に最も適したアーキテクチャが採用される。上述した処理フロー、非機能要件１９４、及び優先要件１９５は、設計者２００がdeployボタン１９３を押下すると、設計支援システム１０１へ出力される。
【0034】
尚、本実施形態にかかる要件の入力手法は、フローベースプログラミング環境に限らず、コード記述やその他のノーコードな入力であってもよい。
【0035】
＜実施形態１に係る第一アーキテクチャ候補生成処理＞
図５は、実施形態１に係る第一アーキテクチャ候補生成処理の一例を示すフローチャートである。実施形態１に係る第一アーキテクチャ候補生成処理は、設計支援システム１０１のアーキテクチャ候補生成部１０６によって実行される。
図５は、実施形態１に係る第一アーキテクチャ候補生成処理の一例を示すフローチャートである。実施形態１に係る第一アーキテクチャ候補生成処理は、設計支援システム１０１のアーキテクチャ候補生成部１０６によって実行される。
【0036】
（ステップＳ１０１）
アーキテクチャ候補生成部１０６は、設計支援画面１００よりＪＳＯＮ（JavaScript Object Notation）等のフォーマットで記述された処理フロー及び非機能要件を受け取る。
アーキテクチャ候補生成部１０６は、設計支援画面１００よりＪＳＯＮ（JavaScript Object Notation）等のフォーマットで記述された処理フロー及び非機能要件を受け取る。
【0037】
（ステップＳ１０２）
アーキテクチャ候補生成部１０６は、ステップＳ１０１で受け取った処理フローデータに対して、内部のノード情報を入力ノードと加工・出力ノードへ分割する。これは、ストリーム処理のデプロイにおいて、入力ノードはキューシステムの性能決定に活用し、加工・出力ノードは処理システムの性能決定に活用するためである。なお処理フローが与えられると、各ノードには入力、処理、又は出力のパラメータが与えられているので、一意に処理フローを入力ノードと、処理・出力ノードに分割される。
アーキテクチャ候補生成部１０６は、ステップＳ１０１で受け取った処理フローデータに対して、内部のノード情報を入力ノードと加工・出力ノードへ分割する。これは、ストリーム処理のデプロイにおいて、入力ノードはキューシステムの性能決定に活用し、加工・出力ノードは処理システムの性能決定に活用するためである。なお処理フローが与えられると、各ノードには入力、処理、又は出力のパラメータが与えられているので、一意に処理フローを入力ノードと、処理・出力ノードに分割される。
【0038】
（ステップＳ１０３）
アーキテクチャ候補生成部１０６は、性能決定ＤＢ１０９より、キュー特徴表１１０、処理システム特徴表１１１、ノード負荷表１１３、負荷・性能対応表１１４を読み込む。
アーキテクチャ候補生成部１０６は、性能決定ＤＢ１０９より、キュー特徴表１１０、処理システム特徴表１１１、ノード負荷表１１３、負荷・性能対応表１１４を読み込む。
【0039】
（ステップＳ１０４）
アーキテクチャ候補生成部１０６は、ステップＳ１０２で分割した入力ノードの情報と、設計支援画面１００より受け取った非機能要件１０４に基づいて、キューの性能をキュー特徴表１１０から決定し、キュー性能候補リスト１１６へ出力する。非機能要件１０４は、新規にクラウド環境１０２にデプロイするシステムのアーキテクチャが充足すべき非機能要件を示す。
アーキテクチャ候補生成部１０６は、ステップＳ１０２で分割した入力ノードの情報と、設計支援画面１００より受け取った非機能要件１０４に基づいて、キューの性能をキュー特徴表１１０から決定し、キュー性能候補リスト１１６へ出力する。非機能要件１０４は、新規にクラウド環境１０２にデプロイするシステムのアーキテクチャが充足すべき非機能要件を示す。
【0040】
ここでキュー特徴表１１０を説明する。図６は、実施形態１に係る性能決定ＤＢ１０９が有するキュー特徴表１１０の一例を示す図である。キュー特徴表１１０には、クラウドサービスやＯＳＳ（Open Source Software）として提供されるキューシステムとその特徴が列挙されている。キュー特徴表１１０では、キューに対してキューの性能値を含む特徴が対応付けられて格納されている。
【0041】
行２０１に示す通り、キュー特徴表１１０は、各サービスの運用方法、分散性やスループット、サービス活用に関する制約、コストやベンダについて記録する。ここで、スループット等性能によって変わる数値では変数を用いた記録がされる。例えば列２０３のシャードあたりの秒間受付列では、キューシステムの持つシャード数によってその値が異なる。キューシステムの決定において設計者が変更可能な変数は列２０４に示す性能値にて指定することができる。その他クラウド環境やデプロイするシステムの制約に応じて非機能要件項目を追加してもよいものとする。
【0042】
図７は、実施形態１に係る設計支援画面１００で設計者２００が入力する非機能要件の一例を示す図である。非機能要件１０４では、入力スループットが３ＭＢ／ｓ以上であること、運用がフルマネージドであること、スケーラビリティがありで負荷に応じてオンデマンドにシステムがスケールすること、が要件として示されている。さらに非機能要件１０４では、クラウドはＡＷＳであること、価格は候補中で最も低いものであること、が要件として示されている。
【0043】
例えば非機能要件１０４の非機能要件に基づき、キュー特徴表１１０から利用可能なキューを判断すると、マネージドの列が○となっている行２０１のKinesis及び行２０２のＳ３がキューとして選択候補となる。また行２０１のKinesisの場合、列２０４の性能値としてShardの指定が可能であり、入力された非機能要件では入力スループット３ＭＢ／ｓが求められる。また行２０１のKinesisの場合、列２０３より(Shard)*１ＭＢの秒間スループットを実現できることから、Shard数は３となる。候補として上がったキューシステム及びその性能値は、図８に示すキュー性能候補リスト１１６へ出力される。図８は、実施形態１に係るアーキテクチャ候補生成部においてデプロイするキューの性能の候補を示すキュー性能候補リスト１１６の一例を示す図である。
【0044】
（ステップＳ１０５)
アーキテクチャ候補生成部１０６は、ステップＳ１０１で分割した加工・出力ノードの情報と非機能要件に基づいて、処理システム特徴表１１１、ノード負荷表１１３、負荷・性能対応表１１４から、処理システムと処理システムの性能を決定する。
アーキテクチャ候補生成部１０６は、ステップＳ１０１で分割した加工・出力ノードの情報と非機能要件に基づいて、処理システム特徴表１１１、ノード負荷表１１３、負荷・性能対応表１１４から、処理システムと処理システムの性能を決定する。
【0045】
図９は、実施形態１に係る性能決定ＤＢ１０９が有する処理システム特徴表１１１の一例を示す図である。処理システム特徴表１１１では、各行にストリーム処理においてデータ加工を担う処理システム候補が列挙されている。各列では、スケーラビリティやメモリ、vCPUの性能、スケール数、適用先のクラウド環境についての特徴を記録する。その他クラウド環境やデプロイするシステムの制約に応じて項目を追加してもよいものとする。なお、処理システム特徴表１１１では、処理システムに対して処理システムの性能値を含む特徴が対応付けられて格納されている。
【0046】
アーキテクチャ候補生成部１０６は、入力された非機能要件に基づいて、適合する処理システム候補を処理システム特徴表１１１から選出する。例えば非機能要件としてスケーラビリティが必要であり、クラウド環境としてＡＷＳが指定された場合、処理システム特徴表中の行３０１と行３０２が候補となる。またキュー特徴表１１０と同様に候補における性能値の決定処理も加工・出力ノードの情報、ノード負荷表１１３、負荷・性能対応表１１４を用いて行う。処理システム特徴表１１１では、各処理システムの性能値はメモリや処理ユニットとなるため、加工・出力ノードの処理負荷より決定される。
【0047】
図１０は、実施形態１に係るアーキテクチャ候補生成部において処理負荷を判断するために加工・出力ノードを処理記述へ変換した一例を示す図である。
【0048】
コード９００は、JavaScript言語にて記述されており、object変数へinput関数、base64関数、dataFilter関数を適用後にoutput関数が実行されている。object変数は、ストリーム処理において入力されるレコード情報を示し、base64関数、dataFilter関数によって加工されている。これらの関数は設計者によって設計支援画面１００中で、ノードで指定される。
【0049】
図１１は、実施形態１に係る性能決定ＤＢ１０９Ｂが有するノード負荷表１１３の一例を示す図である。図１２は、実施例１に係る性能決定ＤＢが持つ負荷・性能対応表１１４の一例を示す図である。図１３は、実施形態１に係るアーキテクチャ候補生成部１０６においてデプロイする処理システムの性能を候補として列挙した処理システム性能候補リスト１１７の一例を示す図である。
【0050】
ノード負荷表１１３は、加工・出力ノードを構成する各関数の処理負荷に基づいて加工・出力ノード全体の処理負荷を計算するための情報である。言い換えると、ノード負荷表１１３には、加工・出力ノードの処理負荷を加工・出力ノードを構成する関数の処理に係る負荷を合計して算出する際の関数に負荷が対応付けられて格納されている。
【0051】
例えばbase64関数は負荷３であり、フィールド操作系の関数であるdataFilter関数は負荷１となる。ノード負荷表１１３より加工処理コード中の関数全ての負荷を合計し、合計値を図１２に示す負荷・性能対応表１１４と照らし合わせる。
【0052】
負荷・性能対応表１１４は、負荷の合計値に対して各処理システムがどれだけの性能値を必要としているかを対応付けた表である。負荷・性能対応表１１４は、処理負荷に対して処理システムが処理負荷の処理に必要とする性能値が対応付けられて格納されている。例えば負荷が５である時は列５０１より負荷１０の行を参照し、処理システムがLambdaの時は性能値が５１２ＭＢ、Ｇｌｕｅの時は性能値が１となる。ここで決定された処理システム候補及びその性能値は、図１３に示す処理システム性能候補リスト１１７へ出力される。
【0053】
（ステップＳ１０６)
アーキテクチャ候補生成部１０６は、ステップＳ１０４、ステップＳ１０５にて出力したキュー性能候補リスト１１６及び処理システム性能候補リスト１１７を組み合わせ、図１５に示す第一アーキテクチャ候補リスト１１９とする。図１４は、実施形態１に係るアーキテクチャ候補生成部１０６においてデプロイするアーキテクチャを第一アーキテクチャ候補リスト１１９として列挙した一例を示す図である。本実施形態では、ストリーム処理を例としているため、各リスト中のキューシステム候補と処理システム候補を一つずつ選択した組合せを、１つのアーキテクチャ候補とする。第一アーキテクチャ候補リスト１１１９は、新規にデプロイするシステムがクラウド環境１０２上にデプロイされて稼働する際に使用するリソースの組合せを示す。
アーキテクチャ候補生成部１０６は、ステップＳ１０４、ステップＳ１０５にて出力したキュー性能候補リスト１１６及び処理システム性能候補リスト１１７を組み合わせ、図１５に示す第一アーキテクチャ候補リスト１１９とする。図１４は、実施形態１に係るアーキテクチャ候補生成部１０６においてデプロイするアーキテクチャを第一アーキテクチャ候補リスト１１９として列挙した一例を示す図である。本実施形態では、ストリーム処理を例としているため、各リスト中のキューシステム候補と処理システム候補を一つずつ選択した組合せを、１つのアーキテクチャ候補とする。第一アーキテクチャ候補リスト１１１９は、新規にデプロイするシステムがクラウド環境１０２上にデプロイされて稼働する際に使用するリソースの組合せを示す。
【0054】
（実施形態１に係るリソース共有候補生成処理）
図１５は、実施形態１に係るリソース共有候補生成処理の一例を示すフローチャートである。リソース共有候補生成部１０７は、第一アーキテクチャ候補リスト１１９、稼働システム構成表１１８、及び制約表１１２を入力とする。そしてリソース共有候補生成部１０７は、新規システムと既存システムとがリソース共有する場合を含んだアーキテクチャ候補を第二アーキテクチャ候補リスト１２０として出力する。
図１５は、実施形態１に係るリソース共有候補生成処理の一例を示すフローチャートである。リソース共有候補生成部１０７は、第一アーキテクチャ候補リスト１１９、稼働システム構成表１１８、及び制約表１１２を入力とする。そしてリソース共有候補生成部１０７は、新規システムと既存システムとがリソース共有する場合を含んだアーキテクチャ候補を第二アーキテクチャ候補リスト１２０として出力する。
【0055】
（ステップＳ１１１）
リソース共有候補生成部１０７は、アーキテクチャ候補生成部１０６から出力された第一アーキテクチャ候補リスト１１９を読み込む。
リソース共有候補生成部１０７は、アーキテクチャ候補生成部１０６から出力された第一アーキテクチャ候補リスト１１９を読み込む。
【0056】
（ステップＳ１１２）
リソース共有候補生成部１０７は、設計支援システム１０１が接続しているクラウド環境１０２上で既にデプロイされ稼働している稼働システム１２２の情報を取得する。この時に取得する稼働システム１２２は、設計支援システム１０１からアクセスの可能な稼働システムであればよく、本実施形態の設計支援システム１０１によってデプロイされたものである必要はない。稼働システム１２２の情報は、クラウド上のサービスマネージャ１２１に出力するコマンド等によって取得する。取得した稼働システム１２２の情報は、稼働システム構成表１１８として出力される。
リソース共有候補生成部１０７は、設計支援システム１０１が接続しているクラウド環境１０２上で既にデプロイされ稼働している稼働システム１２２の情報を取得する。この時に取得する稼働システム１２２は、設計支援システム１０１からアクセスの可能な稼働システムであればよく、本実施形態の設計支援システム１０１によってデプロイされたものである必要はない。稼働システム１２２の情報は、クラウド上のサービスマネージャ１２１に出力するコマンド等によって取得する。取得した稼働システム１２２の情報は、稼働システム構成表１１８として出力される。
【0057】
図１６は、実施形態１に係る評価・デプロイ部１０８が評価する際に用いる稼働システム構成表１１８の一例を示す図である。稼働システム構成表１１８は、各稼働システム１２２として構成される内部のシステム及びシステムの性能を列挙する。言い換えると、稼働システム構成表１１８は、稼働システム１２２を構成する内部のシステムが使用するリソース及びリソースの性能を一覧する。本実施形態は、ストリーム処理の設計支援であり、稼働システムもキューシステムと処理システムから構成されている。
【0058】
（ステップＳ１１３）
リソース共有候補生成部１０７は、性能決定ＤＢ１０９の制約表１１２を読み込む。図１７は、実施形態１に係る性能決定ＤＢ１０９が有する制約表１１２の一例を示す図である。制約表１１２は、以降のステップにおいてリソースの共有判断を実行する際に、各システムの制約上達成する必要のある条件を記録する。制約表１１２は、稼働システム１２２を構成する内部のシステムが使用するリソースの性能に関する制約を示す。また、各システムの制約として性能向上閾値を設定してもよい。性能向上閾値は、ステップＳ１１７において、例えば該当のリソースの性能を向上させる際の限度を示す閾値であり、クラウド環境１０２や各リソースの性能に応じて決まる設計事項である。
リソース共有候補生成部１０７は、性能決定ＤＢ１０９の制約表１１２を読み込む。図１７は、実施形態１に係る性能決定ＤＢ１０９が有する制約表１１２の一例を示す図である。制約表１１２は、以降のステップにおいてリソースの共有判断を実行する際に、各システムの制約上達成する必要のある条件を記録する。制約表１１２は、稼働システム１２２を構成する内部のシステムが使用するリソースの性能に関する制約を示す。また、各システムの制約として性能向上閾値を設定してもよい。性能向上閾値は、ステップＳ１１７において、例えば該当のリソースの性能を向上させる際の限度を示す閾値であり、クラウド環境１０２や各リソースの性能に応じて決まる設計事項である。
【0059】
（ステップＳ１１４）
リソース共有候補生成部１０７は、第一アーキテクチャ候補リスト１１９中の候補のキュー性能と、稼働システム構成表１１８中のキューの性能を順に比較する。
リソース共有候補生成部１０７は、第一アーキテクチャ候補リスト１１９中の候補のキュー性能と、稼働システム構成表１１８中のキューの性能を順に比較する。
【0060】
リソース共有候補生成部１０７は、各候補（以下アーキテクチャ候補と記述）全てに対してステップＳ１１５からステップＳ１２０を実行する。
【0061】
（ステップＳ１１５）
リソース共有候補生成部１０７は、アーキテクチャ候補のキューシステムと、稼働システム１２２のキューシステムが一致しているかどうか判断する。そしてリソース共有候補生成部１０７は、一致している場合、稼働システム１２２のキューの性能がアーキテクチャ候補のキューの性能以上であるかどうか判断する。これは、稼働システム１２２のキューの性能が、アーキテクチャ候補のキューの性能よりも優れていた場合、稼働システム１２２のキューの余剰性能をアーキテクチャ候補のキューとして活用できる可能性があるためである。リソース共有候補生成部１０７は、条件に対して適合した場合（ステップＳ１１５ＹＥＳ）はステップＳ１１６へ、不適合の場合（ステップＳ１１５ＮＯ）はステップＳ１２０へ移行する。
リソース共有候補生成部１０７は、アーキテクチャ候補のキューシステムと、稼働システム１２２のキューシステムが一致しているかどうか判断する。そしてリソース共有候補生成部１０７は、一致している場合、稼働システム１２２のキューの性能がアーキテクチャ候補のキューの性能以上であるかどうか判断する。これは、稼働システム１２２のキューの性能が、アーキテクチャ候補のキューの性能よりも優れていた場合、稼働システム１２２のキューの余剰性能をアーキテクチャ候補のキューとして活用できる可能性があるためである。リソース共有候補生成部１０７は、条件に対して適合した場合（ステップＳ１１５ＹＥＳ）はステップＳ１１６へ、不適合の場合（ステップＳ１１５ＮＯ）はステップＳ１２０へ移行する。
【0062】
なおステップＳ１１５では、言い換えると、第一アーキテクチャ候補が稼働システム１２２と共有できる可能性があるリソースを含むか否かを判定している。
【0063】
（ステップＳ１１６）
リソース共有候補生成部１０７は、ステップＳ１１３で読み込んだ制約表１１２に基づいて、アーキテクチャ候補と稼働システム１２２がリソース共有できるか判断する。例えば図１７に示す制約表１１２の１行目に示すキューKinesisでは処理システム数＜Shard*5を制約としている。すなわち稼働システムのキューがKinesisでありShard数が３である時、当該キューに対して接続されている処理システムの数は１５未満である必要がある。アーキテクチャ候補と稼働システム１２２のキューを共有した場合、アーキテクチャ候補の処理システムは当該キューに対して接続されるが、この時総接続数が１５未満であるならばリソースの共有が可能であると判断される。その他制約としては、スループット量やデータの種類が挙げられる。リソース共有候補生成部１０７は、各制約条件に適合した場合（ステップＳ１１６ＹＥＳ）はステップＳ１１９へ、不適合である場合（ステップＳ１１６ＮＯ）はステップＳ１１７へ移行する。
リソース共有候補生成部１０７は、ステップＳ１１３で読み込んだ制約表１１２に基づいて、アーキテクチャ候補と稼働システム１２２がリソース共有できるか判断する。例えば図１７に示す制約表１１２の１行目に示すキューKinesisでは処理システム数＜Shard*5を制約としている。すなわち稼働システムのキューがKinesisでありShard数が３である時、当該キューに対して接続されている処理システムの数は１５未満である必要がある。アーキテクチャ候補と稼働システム１２２のキューを共有した場合、アーキテクチャ候補の処理システムは当該キューに対して接続されるが、この時総接続数が１５未満であるならばリソースの共有が可能であると判断される。その他制約としては、スループット量やデータの種類が挙げられる。リソース共有候補生成部１０７は、各制約条件に適合した場合（ステップＳ１１６ＹＥＳ）はステップＳ１１９へ、不適合である場合（ステップＳ１１６ＮＯ）はステップＳ１１７へ移行する。
【0064】
（ステップＳ１１７）
リソース共有候補生成部１０７は、ステップＳ１１６の処理において制約表１１２中の対象のキューに性能向上閾値が設定されている場合、稼働システムのキューの性能値を性能向上閾値分向上させるとアーキテクチャ候補とリソース共有可能かを判断する。例えば、稼働システム構成表１１８中の行７０１で示す稼働システム１２２があり、キューに対して１４の処理システムが既に接続されている場合、アーキテクチャ候補は制約表１１２の１行目の処理システム数＜Shard*5である。よって、現状ではリソース共有ができない。
リソース共有候補生成部１０７は、ステップＳ１１６の処理において制約表１１２中の対象のキューに性能向上閾値が設定されている場合、稼働システムのキューの性能値を性能向上閾値分向上させるとアーキテクチャ候補とリソース共有可能かを判断する。例えば、稼働システム構成表１１８中の行７０１で示す稼働システム１２２があり、キューに対して１４の処理システムが既に接続されている場合、アーキテクチャ候補は制約表１１２の１行目の処理システム数＜Shard*5である。よって、現状ではリソース共有ができない。
【0065】
ここで性能向上閾値が１であるため、行７０１の稼働システムのキューの性能を３から４へ変更すると接続可能な処理システム数が２０未満となり、アーキテクチャ候補とリソース共有が可能となる。リソース共有候補生成部１０７は、性能向上閾値以内で性能を向上させるとしてリソースの共有が可能であると判断された場合（ステップＳ１１７ＹＥＳ）はステップＳ１１８へ移行する。またリソース共有候補生成部１０７は、性能向上閾値以内の性能向上であっても制約表中の制約に適合できなかった場合（ステップＳ１１７ＮＯ）はステップＳ１２０へ移行する。
【0066】
（ステップＳ１１８）
リソース共有候補生成部１０７は、稼働システム１２２のキューの性能を向上させ、アーキテクチャ候補とリソースを共有したケースを第二アーキテクチャ候補へ追加する。リソース共有候補生成部１０７は、ステップＳ１１８が終了すると、ステップＳ１２０へ処理を移す。
リソース共有候補生成部１０７は、稼働システム１２２のキューの性能を向上させ、アーキテクチャ候補とリソースを共有したケースを第二アーキテクチャ候補へ追加する。リソース共有候補生成部１０７は、ステップＳ１１８が終了すると、ステップＳ１２０へ処理を移す。
【0067】
（ステップＳ１１９）
リソース共有候補生成部１０７は、稼働システム１２２のキューに対してそのままアーキテクチャ候補とリソースの共有が可能であるケースを第二アーキテクチャ候補へ追加する。リソース共有候補生成部１０７は、ステップＳ１１９が終了すると、ステップＳ１２０へ処理を移す。
リソース共有候補生成部１０７は、稼働システム１２２のキューに対してそのままアーキテクチャ候補とリソースの共有が可能であるケースを第二アーキテクチャ候補へ追加する。リソース共有候補生成部１０７は、ステップＳ１１９が終了すると、ステップＳ１２０へ処理を移す。
【0068】
（ステップＳ１２０）
リソース共有候補生成部１０７は、稼働システム１２２とアーキテクチャ候補のリソースを共有しなかった場合を第二アーキテクチャ候補へ追加する。
リソース共有候補生成部１０７は、稼働システム１２２とアーキテクチャ候補のリソースを共有しなかった場合を第二アーキテクチャ候補へ追加する。
【0069】
（ステップＳ１２１）
リソース共有候補生成部１０７は、第二アーキテクチャ候補として追加された各候補をまとめて第二アーキテクチャ候補リスト１２０として出力する。図１８は、実施形態１に係るリソース共有候補生成部１０７がリソース共有を考慮したアーキテクチャ候補を第二アーキテクチャ候補リスト１２０として列挙した一例を示す図である。図１８では、ステップＳ１２０で追加した、稼働システム１２２とアーキテクチャ候補のリソースを共有しなかった場合のアーキテクチャ候補の図示を省略している。
リソース共有候補生成部１０７は、第二アーキテクチャ候補として追加された各候補をまとめて第二アーキテクチャ候補リスト１２０として出力する。図１８は、実施形態１に係るリソース共有候補生成部１０７がリソース共有を考慮したアーキテクチャ候補を第二アーキテクチャ候補リスト１２０として列挙した一例を示す図である。図１８では、ステップＳ１２０で追加した、稼働システム１２２とアーキテクチャ候補のリソースを共有しなかった場合のアーキテクチャ候補の図示を省略している。
【0070】
なお本実施形態は、ストリーム処理であるため、キューの共有可否を判断したが、ストリーム処理以外の処理システムをデプロイする場合、共有可能なデータベースやメモリリソース、計算処理リソースの性能比較を行ってもよい。
【0071】
（実施形態１に係る評価・デプロイ処理）
図１９は、実施形態１に係る評価・デプロイ処理の一例を示すフローチャートである。評価・デプロイ部１０８は、第二アーキテクチャ候補リスト１２０、及び稼働システム非機能要件表１１５を入力として、設計者の指定した非機能要件に適したアーキテクチャを候補として提案し、クラウドにデプロイする。
図１９は、実施形態１に係る評価・デプロイ処理の一例を示すフローチャートである。評価・デプロイ部１０８は、第二アーキテクチャ候補リスト１２０、及び稼働システム非機能要件表１１５を入力として、設計者の指定した非機能要件に適したアーキテクチャを候補として提案し、クラウドにデプロイする。
【0072】
（ステップＳ１３１）
評価・デプロイ部１０８は、リソース共有候補生成部１０７より出力された第二アーキテクチャ候補リスト１２０を読み込む。
評価・デプロイ部１０８は、リソース共有候補生成部１０７より出力された第二アーキテクチャ候補リスト１２０を読み込む。
【0073】
（ステップＳ１３２）
評価・デプロイ部１０８は、性能決定ＤＢ１０９より稼働システム非機能要件表１１５を読み込む。
評価・デプロイ部１０８は、性能決定ＤＢ１０９より稼働システム非機能要件表１１５を読み込む。
【0074】
図２０は、実施形態１に係る性能決定ＤＢ１０９が有する稼働システム非機能要件表１１５の一例を示す図である。稼働システム非機能要件表１１５は、稼働システム１２２をデプロイした際に指定した非機能要件情報を格納している。稼働システム非機能要件表１１５は、稼働システム１２２が充足すべき非機能要件を示す。稼働システム非機能要件表１１５は、本実施形態に係る設計支援システム１０１によってデプロイされたシステムである場合、設計者の入力した非機能要件をそのまま保持する。稼働システム非機能要件表１１５は、他システムによってデプロイされた稼働システムである場合は設計者が新規に記載することも可能である。
【0075】
加えて図２０の行６０１に示すように、クラウド環境上の稼働システムから得られる情報として自明である項目は、クラウド環境のサービスマネージャへの状態確認コマンドの送信結果に基づいて記録することも可能である。
【0076】
（ステップＳ１３４）
評価・デプロイ部１０８は、第二アーキテクチャ候補リスト１２０中の各候補（以下アーキテクチャ候補）に対してステップＳ１３４からステップＳ１３８までの非機能要件の評価を行う。
評価・デプロイ部１０８は、第二アーキテクチャ候補リスト１２０中の各候補（以下アーキテクチャ候補）に対してステップＳ１３４からステップＳ１３８までの非機能要件の評価を行う。
【0077】
図１８に示す第二アーキテクチャ候補リスト１２０には、各アーキテクチャ候補のキュー及び処理システムの性能と、共有フロー番号と性能向上値が記録されている。第二アーキテクチャ候補リスト１２０における共有フロー番号１５０１は、図１６の稼働システム構成表１１８に記載されているフロー番号の稼働システム１２２とリソースの共有があることを示す。すなわち共有フロー番号１５０１は、共有可能なリソースを特定するための特定情報となる。性能向上値１５０２は、リソース共有時に向上させたリソースの性能値を示す。
【0078】
評価・デプロイ部１０８は、アーキテクチャ候補が稼働システム１２２とリソースを共有する場合（ステップＳ１３４ＹＥＳ）にステップＳ１３５へ、共有しない場合（ステップＳ１３４ＮＯ）にステップＳ１３７へ移行する。
【0079】
（ステップＳ１３５）
評価・デプロイ部１０８は、アーキテクチャ候補がリソースを共有する稼働システム１２２に対し、稼働システム非機能要件表１１５中の対象の稼働システム１２２の非機能要件の評価を行う。本ステップでは、リソースを共有し性能を向上させた結果、当該稼働システム１２２が非機能要件を満たさなくなる場合を防ぐ効果がある。評価・デプロイ部１０８は、非機能要件の評価の際、各非機能要件項目を満たすか満たさないかによって判定を行い、全て満たす場合のみ非機能要件を満たすと判断する。
評価・デプロイ部１０８は、アーキテクチャ候補がリソースを共有する稼働システム１２２に対し、稼働システム非機能要件表１１５中の対象の稼働システム１２２の非機能要件の評価を行う。本ステップでは、リソースを共有し性能を向上させた結果、当該稼働システム１２２が非機能要件を満たさなくなる場合を防ぐ効果がある。評価・デプロイ部１０８は、非機能要件の評価の際、各非機能要件項目を満たすか満たさないかによって判定を行い、全て満たす場合のみ非機能要件を満たすと判断する。
【0080】
評価・デプロイ部１０８は、リソースを共有した場合においても当該稼働システムが非機能要件を満たす場合（ステップＳ１３６ＹＥＳ）は、ステップＳ１３７へ移行する。一方評価・デプロイ部１０８は、非機能要件を満たさない場合（ステップＳ１３６ＮＯ）は、次のアーキテクチャ候補の評価を行うためステップＳ１３４へ戻る。
【0081】
（ステップＳ１３７）
評価・デプロイ部１０８は、アーキテクチャ候補を、設計者の入力した非機能要件で評価する。
評価・デプロイ部１０８は、アーキテクチャ候補を、設計者の入力した非機能要件で評価する。
【0082】
図２１は、実施形態１に係る評価・デプロイ部１０８において設計者の入力した非機能要件に基づいてアーキテクチャを評価した結果を示すアーキテクチャ評価表２１００を示す図である。アーキテクチャ評価表２１００では、キュー２１０１から性能向上値２１０２までがアーキテクチャ候補の持つ情報を示す列である。またアーキテクチャ評価表２１００では、スループット２１０３から価格帯２１０４までが非機能要件を評価する列である。評価においては、先ず非機能要件の項目に対して各アーキテクチャ候補が満たしているかどうかの可否が判断される。価格やスループット等具体的な値が導出できる項目はその値を導出した上で記録する。リソースを共有する場合、価格の算出の際に共有したリソースが使用する料金を計上しない。これによって、リソースを共有するケースではリソースの共有分の料金削減を評価へ組み込むことができる。アーキテクチャ候補が全ての非機能要件を満たす場合総合評価の列に満たす旨（総合評価２１０５）を記載する。
【0083】
（ステップＳ１３８）
評価・デプロイ部１０８は、全てのアーキテクチャ候補の評価を完了した場合（ステップＳ１３８ＹＥＳ）、ステップＳ１３９へ移行する。
評価・デプロイ部１０８は、全てのアーキテクチャ候補の評価を完了した場合（ステップＳ１３８ＹＥＳ）、ステップＳ１３９へ移行する。
【0084】
（ステップＳ１３９）
評価・デプロイ部１０８は、図２１に示すアーキテクチャ評価表２１００の総合評価２１０５より、複数のアーキテクチャ候補が非機能要件を満たす場合、設計者の入力した優先要件に基づいてデプロイアーキテクチャを決定する。例えば図２１に示すアーキテクチャ評価表２１００において、価格（コスト）が優先要件１０５（図３）として指定されていた場合、行２１０６で示す構成が５００＄と最も低価格であるため選出される。
評価・デプロイ部１０８は、図２１に示すアーキテクチャ評価表２１００の総合評価２１０５より、複数のアーキテクチャ候補が非機能要件を満たす場合、設計者の入力した優先要件に基づいてデプロイアーキテクチャを決定する。例えば図２１に示すアーキテクチャ評価表２１００において、価格（コスト）が優先要件１０５（図３）として指定されていた場合、行２１０６で示す構成が５００＄と最も低価格であるため選出される。
【0085】
（ステップＳ１４０）
評価・デプロイ部１０８は、ステップＳ１３９で選出されたアーキテクチャ候補をデプロイするためのデプロイコードをYAML等の記述として生成する。評価・デプロイ部１０８は、コード形式で記述されたリソースを読み込む。なおクラウド上へデプロイするシステムは、各クラウドベンダより提供されている。
評価・デプロイ部１０８は、ステップＳ１３９で選出されたアーキテクチャ候補をデプロイするためのデプロイコードをYAML等の記述として生成する。評価・デプロイ部１０８は、コード形式で記述されたリソースを読み込む。なおクラウド上へデプロイするシステムは、各クラウドベンダより提供されている。
【0086】
（ステップＳ１４１）
評価・デプロイ部１０８は、ステップＳ１３９で選出されたアーキテクチャ候補が稼働システム１２２の性能を向上させる場合、稼働システム１２２のキュー性能を向上させるデプロイコードを新たに生成する。当該稼働システム１２２が本実施形態の設計支援システム１０１によりデプロイされた稼働システム１２２ではない場合、評価・デプロイ部１０８は、クラウド環境１０２上のサービスマネージャ１２１に対してキューの性能を変更するコマンドを送信する。サービスマネージャ１２１は、コマンド受信に応じて、該当のキューの性能を変更して稼働システム１２２を修正する。
評価・デプロイ部１０８は、ステップＳ１３９で選出されたアーキテクチャ候補が稼働システム１２２の性能を向上させる場合、稼働システム１２２のキュー性能を向上させるデプロイコードを新たに生成する。当該稼働システム１２２が本実施形態の設計支援システム１０１によりデプロイされた稼働システム１２２ではない場合、評価・デプロイ部１０８は、クラウド環境１０２上のサービスマネージャ１２１に対してキューの性能を変更するコマンドを送信する。サービスマネージャ１２１は、コマンド受信に応じて、該当のキューの性能を変更して稼働システム１２２を修正する。
【0087】
（ステップＳ１４２）
評価・デプロイ部１０８は、ステップＳ１４０及びステップＳ１４１で生成したデプロイコードに基づいて、アーキテクチャ候補及び修正した稼働システム１２２をクラウド環境上へデプロイする。
評価・デプロイ部１０８は、ステップＳ１４０及びステップＳ１４１で生成したデプロイコードに基づいて、アーキテクチャ候補及び修正した稼働システム１２２をクラウド環境上へデプロイする。
【0088】
（ステップＳ１４３）
評価・デプロイ部１０８は、性能決定ＤＢ１０９が有する稼働システム非機能要件表１１５に対し、デプロイしたアーキテクチャ候補の非機能要件を追加する。
評価・デプロイ部１０８は、性能決定ＤＢ１０９が有する稼働システム非機能要件表１１５に対し、デプロイしたアーキテクチャ候補の非機能要件を追加する。
【0089】
（ステップＳ１４４）
評価・デプロイ部１０８は、デプロイした結果を設計支援画面１００上に表示する。図２２は、実施形態１に係る設計支援システム１０１がアーキテクチャをデプロイした結果を示すアーキテクチャデプロイ表２２００である。アーキテクチャデプロイ表２２００において、キューＩＤ２２０１は、各稼働システム１２２が有するキューの固有ＩＤを表示している。当該固有ＩＤが同一である時、各稼働システム１２２のキューが共有されていることを示す。
評価・デプロイ部１０８は、デプロイした結果を設計支援画面１００上に表示する。図２２は、実施形態１に係る設計支援システム１０１がアーキテクチャをデプロイした結果を示すアーキテクチャデプロイ表２２００である。アーキテクチャデプロイ表２２００において、キューＩＤ２２０１は、各稼働システム１２２が有するキューの固有ＩＤを表示している。当該固有ＩＤが同一である時、各稼働システム１２２のキューが共有されていることを示す。
【0090】
上記フローチャートによって、設計者２００が入力した処理フロー１０３及び非機能要件１０４からアーキテクチャ候補を生成する。そして、アーキテクチャ候補が稼働システムとリソースを共有した場合及び稼働システムのリソースの性能を向上した上でリソースを共有した場合を含めて非機能要件を評価する。これにより、リソースの共有を考慮しない場合と比較してより非機能要件を満たすアーキテクチャを選出することができる。
【0091】
なおステップＳ１３９からステップＳ１４３までの各ステップは、評価によって選出したアーキテクチャ候補をそのままデプロイする場合のステップである。ステップＳ１３８で全評価を完了した後に設計者に対して評価結果を表示し、設計者が最終的にデプロイするアーキテクチャを選出してもよい。この場合、図２１に示すアーキテクチャ評価表２１００を設計支援画面１００上に表示する。
【0092】
（実施形態１の効果）
上述の実施形態１では、クラウド環境にデプロイする多段に構成された新規システムと、クラウド環境で稼働中の稼働システムとが、キューや処理システム等のリソースを共有する場合としない場合の両方のアーキテクチャ候補を非機能要件の評価対象に含める。そして第二アーキテクチャ候補のうちで新規システムの非機能要件と稼働システムの非機能要件を充足するアーキテクチャをクラウド環境１２０にデプロイする新規システムのアーキテクチャと決定する。
上述の実施形態１では、クラウド環境にデプロイする多段に構成された新規システムと、クラウド環境で稼働中の稼働システムとが、キューや処理システム等のリソースを共有する場合としない場合の両方のアーキテクチャ候補を非機能要件の評価対象に含める。そして第二アーキテクチャ候補のうちで新規システムの非機能要件と稼働システムの非機能要件を充足するアーキテクチャをクラウド環境１２０にデプロイする新規システムのアーキテクチャと決定する。
【0093】
よって実施形態１によれば、リソースを共有した場合としない場合の両方のアーキテクチャ候補を非機能要件の評価対象へ含めることで、非機能要件を充足する適切な新規システムのアーキテクチャ候補を効率的に発見できる。
【0094】
また上述の実施形態１では、リソースの性能を向上させた上でリソースを共有するアーキテクチャ候補を非機能要件の評価対象へ含めることで、柔軟にアーキテクチャを設計できる。
【0095】
また上述の実施形態１では、複数のキューシステムと処理システムの組合せを第一アーキテクチャ候補として生成する。よって、より多くのアーキテクチャ候補から、非機能要件を充足する新規のリアルタイムのデータ処理システムのアーキテクチャ候補を効率的に発見できる。
【0096】
また上述の実施形態１では、設計者によって入力された処理フローから、新規システムの非機能要件を充足することができるキューシステムと処理システムを決定し、キューシステムと処理システムの組合せを第一アーキテクチャ候補として生成する。よって処理フローを基にして、非機能要件を充足する適切なアーキテクチャ候補を効率的に発見できる。
【0097】
また上述の実施形態１では、非機能要件と新規非機能要件とを充足する第二アーキテクチャ候補が複数存在する場合に、優先要件が最良値を示すアーキテクチャ候補を、クラウド環境１２０にデプロイする新規システムのアーキテクチャを決定する。よって要件に沿った最適なアーキテクチャを発見できる。
【0098】
また上述の実施形態１では、クラウド環境に新規システムのアーキテクチャをデプロイし、新規システムの非機能要件を、稼動中のシステムの非機能要件を保存する稼働システム非機能要件情報に追加する。よって、設計支援システムでアーキテクチャを設計したシステムに関する非機能要件やリソースの情報を、以後のシステムのアーキテクチャ設計の際に再利用することができる。
【0099】
（実施形態１の変形例）
実施形態１では、システムが有する処理フローを、処理システムとキューの各システム要素へ分けてアーキテクチャ候補を生成している。しかしストリーム処理のシステムに限らず、多段のノードで構成される処理フローを有するシステムに対して広く適用可能である。
実施形態１では、システムが有する処理フローを、処理システムとキューの各システム要素へ分けてアーキテクチャ候補を生成している。しかしストリーム処理のシステムに限らず、多段のノードで構成される処理フローを有するシステムに対して広く適用可能である。
【0100】
実施形態１の変形例では、性能決定ＤＢ１０９は、アーキテクチャの設計対象の新規システムを構成するシステム要素に対してシステム要素の性能値を含む特徴を対応付けた特徴情報を格納する。システム要素とは、例えばキューシステムや処理システムといった処理単位である。特徴情報は、例えばキュー特徴表１１０や処理システム特徴表１１１といったシステム要素の特徴と性能値を含む。
【0101】
そしてアーキテクチャ候補生成部１０６は、処理フローの入力を受け付け、処理フローを、ｎ個（ｎ≧２）のノードへ分割し、ｎ個のノードのそれぞれに対して所定の非機能要件を充足することができるシステム要素とシステム要素の性能値を決定する。アーキテクチャ候補生成部１０６は、決定したシステム要素をｎ個のノードについて組合せて第一アーキテクチャ候補を生成する。そして実施形態１の変形例では、リソース共有１０７候補生成部及び評価・デプロイ部１０８は、生成した第一アーキテクチャ候補を、実施形態１と同様に処理する。
【0102】
上述の実施形態１の変形例では、複数のシステム要素の組合せを第一アーキテクチャ候補として生成することで、より多くのアーキテクチャ候補から、非機能要件を充足する適切な新規システムのアーキテクチャ候補を効率的に発見できる。
【0103】
［実施形態２］
図２３は、実施形態２に係る設計支援システム１０１Ｂと設計支援画面１００Ｂ及び関連するクラウド環境１０２との関係を示す図である。本実施形態では、設計者２００は、設計支援画面１００上で処理フロー１０３、非機能要件１０４、優先要件１０５、及びアーキテクチャデプロイ表２３００を設計する。この時のアーキテクチャデプロイ表２３００は、実施形態１の第一アーキテクチャ候補リスト１１９の持つ設計情報と同等の粒度の設計情報であるとする。設計された処理フロー１０３、非機能要件１０４、優先要件１０５、及びアーキテクチャデプロイ表２３００は、設計支援システム１０１Ｂへ入力される。
図２３は、実施形態２に係る設計支援システム１０１Ｂと設計支援画面１００Ｂ及び関連するクラウド環境１０２との関係を示す図である。本実施形態では、設計者２００は、設計支援画面１００上で処理フロー１０３、非機能要件１０４、優先要件１０５、及びアーキテクチャデプロイ表２３００を設計する。この時のアーキテクチャデプロイ表２３００は、実施形態１の第一アーキテクチャ候補リスト１１９の持つ設計情報と同等の粒度の設計情報であるとする。設計された処理フロー１０３、非機能要件１０４、優先要件１０５、及びアーキテクチャデプロイ表２３００は、設計支援システム１０１Ｂへ入力される。
【0104】
設計支援システム１０１Ｂは、リソース共有候補生成部１０７、評価・デプロイ部１０８、稼働システム構成表１１８、第二アーキテクチャ候補リスト１２０、性能決定ＤＢ１０９Ｂを含んで構成される。実施形態１と同様に、設計支援システム１０１Ｂは、クラウド環境１０２と接続される。
【0105】
設計支援画面１００Ｂよりアーキテクチャデプロイ表２３００が入力されると、リソース共有候補生成部１０７は、読み込み処理を実行する。この時の処理は、アーキテクチャデプロイ表２３００が第一アーキテクチャ候補リスト１１９の１つとして入力される形式と同様である。第一アーキテクチャ候補リスト１１９に記載されるアーキテクチャ候補が稼働システム１２２とリソース共有ができるか判断され、第二アーキテクチャ候補リスト１２０へ出力される。
【0106】
評価・デプロイ部１０８の、実施形態１と同様である。評価・デプロイ部１０８は、第二アーキテクチャ候補リスト１２０を読み込み、非機能要件を満たす最も優先要件１０５に適合したアーキテクチャを、クラウド環境１０２にデプロイする。
【0107】
（実施形態２の効果）
本実施形態によって、設計者がアーキテクチャを直接設計した場合においても本願開示の技術が適用され、稼働システム１２２とリソース共有した場合を含めた非機能要件の評価が可能となる。
本実施形態によって、設計者がアーキテクチャを直接設計した場合においても本願開示の技術が適用され、稼働システム１２２とリソース共有した場合を含めた非機能要件の評価が可能となる。
【0108】
以上、本願開示に係る一実施形態について詳述したが、本願開示は上述の実施形態に限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能である。例えば、上述の実施形態は本発明を分かりやすく説明するために詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。また上述の実施形態の構成の一部について、他の構成の追加・削除・置換をすることが可能である。
【0109】
また上述の各構成、機能部、処理部、処理手段、スレッド等は、それらの一部又は全部を、例えば、集積回路で設計する等によりハードウェアで実現してもよい。また上述の各構成、機能等は、プロセッサがそれぞれの機能を実現するプログラムを解釈し、実行することによりソフトウェアで実現してもよい。各機能を実現するプログラム、テーブル、ファイル等の情報は、メモリやハードディスク、ＳＳＤ（Solid State Drive）等の記録装置、ＩＣカード、ＳＤカード、ＤＶＤ等の記録媒体に置くことができる。
【0110】
また上述の各図において、制御線や情報線は説明上必要と考えられるものを示しており、必ずしも実装上の全ての制御線や情報線を示しているとは限らない。例えば、実際には殆ど全ての構成が相互に接続されていると考えてもよい。
【0111】
また上述した設計支援システム１０１，１０１Ｂ、設計支援画面１００，１００Ｂ、及びクラウド環境１０２の各機能及びデータの配置形態は一例に過ぎない。各機能及びデータの配置形態は、ハードウェアやソフトウェアの性能、処理効率、通信効率等の観点から最適な配置形態に変更し得る。
【符号の説明】
【0112】
１０１，１０１Ｂ：設計支援システム、１０２：クラウド環境、１０３：処理フロー、１０４：非機能要件、１０５：優先要件、１０９：性能決定ＤＢ、１１０：キュー特徴表、１１１：処理システム特徴表、１１２：制約表、１１３：ノード負荷表、１１４：負荷・性能対応表、１１５：稼働システム非機能要件表、１１８：稼働システム構成表、１１９：第一アーキテクチャ候補リスト、１２０：第二アーキテクチャ候補リスト、２００３：プロセッサ、２００４：メモリ、２００５：ストレージ装置。
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】
【図15】
【図16】
【図17】
【図18】
【図19】
【図20】
【図21】
【図22】
【図23】