特許 6984087 サービス開発システム、リソース予測方法及びサービス開発プログラム

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

(12)【公報種別】特許公報(B2)

(11)【特許番号】6984087

(24)【登録日】2021年11月29日

(45)【発行日】2021年12月17日

(54)【発明の名称】サービス開発システム、リソース予測方法及びサービス開発プログラム

(51)【国際特許分類】

   G06F 9/50 20060101AFI20211206BHJP

   G06F 8/00 20180101ALI20211206BHJP

【ＦＩ】

   G06F9/50 120Z

   G06F9/50 150B

   G06F8/00

【請求項の数】7

【全頁数】12

(21)【出願番号】特願2017-197622(P2017-197622)

(22)【出願日】2017年10月11日

(65)【公開番号】特開2019-71004(P2019-71004A)

(43)【公開日】2019年5月9日

【審査請求日】2019年12月19日

(73)【特許権者】

【識別番号】000004226

【氏名又は名称】日本電信電話株式会社

(74)【代理人】

【識別番号】100119677

【弁理士】

【氏名又は名称】岡田 賢治

(74)【代理人】

【識別番号】100115794

【弁理士】

【氏名又は名称】今下 勝博

(72)【発明者】

【氏名】谷口 篤

(72)【発明者】

【氏名】南 勇貴

(72)【発明者】

【氏名】川幡 太一

(72)【発明者】

【氏名】坂井田 規夫

【審査官】 井上 宏一

(56)【参考文献】

【文献】 再公表特許第２０１１／０９６３１４（ＪＰ，Ａ１）

【文献】 特表２００９−５４０４６９（ＪＰ，Ａ）

【文献】 再公表特許第２０１０／１３１７７８（ＪＰ，Ａ１）

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｇ０６Ｆ ９／４５５−９／５４

Ｇ０６Ｆ ８／００

(57)【特許請求の範囲】

【請求項1】

２つ以上のサービス要素を組み合わせてサービス構成を形成して１つ以上のアプリケーションを作成するサービス開発システムであって、
入力された、ネットワーク機能を含む前記アプリケーションに求められる動作及び前記動作の適用条件並びに前記動作及び前記適用条件が課される前記サービス要素が記載された１以上のサービス要件をサービス要件テーブルに記載するサービス要件投入部と、
前記サービス要件テーブルに記載されたそれぞれの前記サービス要件に記載された前記サービス要素を接続して前記サービス構成を組み立てるとともに、前記サービス要件毎に、前記サービス要件を前記サービス構成の要素として表す設定テンプレートを生成し、生成された前記設定テンプレートを、前記設定テンプレートに記載されたサービス要素に紐づけて、組み立てた前記サービス構成に追加するサービス要件適用部と、
前記サービス構成を仮想的に動作させ、それぞれのサービス要件を満たす計算資源とネットワーク機能のリソース量を予測するリソース予測部と、
を備え、
前記リソース予測部で予測したリソース量を使った前記サービス構成を組み立てることを特徴とするサービス開発システム。

【請求項2】

前記動作は、リソース２倍までのリソースを使って冗長化すること、又はサービス要素以外からの通信を遮断することであることを特徴とする請求項１に記載のサービス開発システム。

【請求項3】

前記サービス要件に含まれるネットワーク機能は、計算資源を用いて実行可能な仮想のネットワーク機能であり、
前記サービス要件適用部は、前記サービス要件を、前記サービス要件に記載されたサービス要素毎に集約して前記サービス構成を組み立てる
ことを特徴とする請求項１または２に記載のサービス開発システム。

【請求項4】

２つ以上のサービス要素を組み合わせてサービス構成を形成して１つ以上のアプリケーションを作成する際に要求されるリソース量を予測するサービス開発システムが実行するリソース予測方法であって、
前記サービス開発システムが、
入力された、ネットワーク機能を含む前記アプリケーションに求められる動作及び前記動作の適用条件並びに前記動作及び前記適用条件が課される前記サービス要素が記載された１以上のサービス要件をサービス要件テーブルに記載するサービス要件投入手順と、
前記サービス要件テーブルに記載されたそれぞれのサービス要件に記載された前記サービス要素を接続して前記サービス構成を組み立てるとともに、前記サービス要件毎に、前記サービス要件を前記サービス構成の要素として表す設定テンプレートを生成し、生成された前記設定テンプレートを、前記設定テンプレートに記載されたサービス要素に紐づけて、組み立てた前記サービス構成に追加するサービス要件適用手順と、
前記サービス構成を仮想的に動作させ、それぞれのサービス要件を満たす計算資源とネットワーク機能のリソース量を予測するリソース予測手順と、
を行い、
前記リソース予測手順で予測したリソース量を使った前記サービス構成を組み立てることを特徴とするリソース予測方法。

【請求項5】

前記動作は、リソース２倍までのリソースを使って冗長化すること、又はサービス要素以外からの通信を遮断することであることを特徴とする請求項４に記載のリソース予測方法。

【請求項6】

前記サービス要件に含まれるネットワーク機能は、計算資源を用いて実行可能な仮想のネットワーク機能であり、
前記サービス要件適用手順では、前記サービス要件を、前記サービス要件に記載されたサービス要素毎に集約して前記サービス構成を組み立てる
ことを特徴とする請求項４または５に記載のリソース予測方法。

【請求項7】

コンピュータを、請求項１から３のいずれかに記載のサービス開発システムとして機能させるためのサービス開発プログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本開示は、仮想または物理サーバ上でサービスを開発するサービス開発システムにおいて、サービス要素または、ネットワーク機能が満たす必要なリソース量を予測し、サービス要素または、ネットワーク機能にリソースを割り当てる技術に関する。

【背景技術】

【0002】

サーバ仮想化技術等により、従来は物理的な装置を持たなければ開発できなかったネットワークサービスをクラウド上で簡単に構築できるＮＦＶ（Ｎｅｔｗｏｒｋ Ｆｕｎｃｔｉｏｎｓ Ｖｉｒｔｕａｌｉｓａｔｉｏｎ）等の技術が開発・標準化されている。

【0003】

また、ソフトウェアの開発手法としてマイクロサービスアーキテクチャが提唱されている（例えば、非特許文献１を参照。）。図１にマイクロサービスアーキテクチャを示す。マイクロサービスアーキテクチャは、単一のアプリケーションを小さな独立したサービス要素の組みわせとして構築するソフトウェア設計手法であり、モノリシックなアプリケーションと比べてサービスの責任分界点が明確化し、またスケーラビリティが向上する。近年ではマイクロサービスを簡単に作るツールとしてＮｏｄｅ ｒｅｄのように、すでにサービス要素が作られており、それを組み合わせることで簡易にサービスを作るソフトも提案されている（例えば、非特許文献２を参照。）。

【0004】

図２は、従来のＮｏｄｅ Ｒｅｄのような部品組み合わせ型のサービス開発システム３００を説明する構成図である。サービス開発システム３００は、開発者がアプリケーションを開発する時にサービス要素リスト１１から必要なサービス要素をインターフェイス１２を用いて接続して組み合わせ、一つのアプリケーションを作る。そして、開発者は、リソース割当部２１を用いて各サービス要素に基づいてネットワーク機能や計算資源のリソースを割り当てる。

【0005】

図４は、サービス開発システム３００を用いてアプリケーションのサービス構成を生成する作業を説明する図である。サービス開発システム３００ではあらかじめ選択可能なサービス要素がシステムのサービスリストに登録されており、開発者は前記サービスリストから必要なサービス要素を選択し、サービス要素間を線（インターフェイス）で繋ぐことで所望のサービスの構成を作り出し（ステップＳ０１）、そのサービス構成に対してリソースを割り当てることでサービス（アプリケーション）を生成する（ステップＳ０２）。

【0006】

このような技術により、一からソフトウェアを作るのではなく、サービスを要素化して開発し、それを選択し組み合わせることで多様なサービス要件を満たすサービスを構築することができる。

【先行技術文献】

【非特許文献】

【0007】

【非特許文献1】“Ｍｉｃｒｏｓｅｒｖｉｃｅｓ”，ｈｔｔｐｓ：／／ｍａｒｔｉｎｆｏｗｌｅｒ．ｃｏｍ／ａｒｔｉｃｌｅｓ／ｍｉｃｒｏｓｅｒｖｉｃｅｓ．ｈｔｍｌ（２０１７年９月１３日検索）

【非特許文献2】“Ｎｏｄｅ−ｒｅｄ”，ｈｔｔｐｓ：／／ｎｏｄｅｒｅｄ．ｏｒｇ／（２０１７年９月１３日検索）

【発明の概要】

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

【0008】

アプリケーション開発者がサービスのスケーラビリティ（拡張性）等も考慮してネットワーク機能を組み合わせてアプリケーションに最適なサービスを設計するためにはネットワークの詳細な知識が求められるという課題がある。

【0009】

また、サービス要素は独立したサービスであるため、異なる計算機資源（ここで定義する計算機資源はベアメタル、仮想マシン、コンテナ等を含む）に構築することが一般的であり、ＶＮＦ（Ｖｉｒｔｕａｌｉｓｅｄ ｎｅｔｗｏｒｋ ｆｕｎｃｔｉｏｎ）等のネットワーク機能はＶＮＦそれぞれにリソース量（ＣＰＵ、メモリ、ＨＤＤ）を割り当てる必要があり、どのくらいのリソースをどのＶＮＦに割り当てる必要があるのかが判断することが困難という課題もある。

【0010】

そこで、前記課題を解決するために、本発明は、ネットワークの詳細な知識が無くともアプリケーションを作成する際に要求される計算資源量とネットワーク機能のリソース量を予測できるサービス開発システム、リソース予測方法及びサービス開発プログラムを提供することを目的とする。

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

【0011】

上記目的を達成するために、本発明に係るサービス開発システムおよびリソース予測方法は、マイクロサービスアーキテクチャを用いて、複数のサービス要素を組み合わせてサービス構成を形成して１つのアプリケーションを作成する際に要求される計算資源量とネットワーク機能のリソース量を、アプリケーションに求められるサービス要件をテーブルに記載し、それらを適用するサービス構成にマッピングし、仮想的にアプリケーションを動作させて、把握することとした。

【0012】

具体的には、本発明に係るサービス開発システムは、
２つ以上のサービス要素を組み合わせてサービス構成を形成して１つ以上のアプリケーションを作成するサービス開発システムであって、
入力された、前記アプリケーションに求められる１以上のサービス要件をサービス要件テーブルに記載するサービス要件投入部と、
前記サービステーブルに記載されたそれぞれのサービス要件をネットワークの設定情報に変換し前記サービス構成にマッピングするサービス要件適用部と、
サービス要件がマッピングされた前記サービス構成を仮想的に動作させ、それぞれのサービス要件を満たす計算資源とネットワーク機能のリソース量を予測するリソース予測部と、
を備える。

【0013】

また、本発明に係るリソース予測方法は、２つ以上のサービス要素を組み合わせてサービス構成を形成して１つ以上のアプリケーションを作成する際に要求されるリソース量を予測するリソース予測方法であって、
入力された、前記アプリケーションに求められる１以上のサービス要件をサービス要件テーブルに記載するサービス要件投入手順と、
前記サービステーブルに記載されたそれぞれのサービス要件をネットワークの設定情報に変換し前記サービス構成にマッピングするサービス要件適用手順と、
サービス要件がマッピングされた前記サービス構成を動作させたデータを基に、それぞれのサービス要件を満たす計算資源とネットワーク機能のリソース量を予測するリソース予測手順と、
を行うことを特徴とする。

【0014】

本発明は、アプリケーションに必要なネットワーク機能をサービス要件としてテーブルに入力することでリソースを共通化する時にサービス要件を集約でき、当該アプリケーションを仮想的に動作させることで必要なリソース量を予測することができる。従って、本発明は、ネットワークの詳細な知識が無くともアプリケーションを作成する際に要求される計算資源量とネットワーク機能のリソース量を予測できるサービス開発システムおよびリソース予測方法を提供することができる。

【0015】

本発明に係るサービス開発システム及びリソース予測方法は、他のアプリケーションとの共有が可能なサービス要件の有無を確認し、共有可能なサービス要件があり、且つ同一のサービス要件である場合、前記他のアプリケーションにネットワーク機能を収容させることを特徴とする。他のアプリケーションも考慮してリソース量を予測することができる。

【0016】

本発明に係るサービス開発システム及びリソース予測方法は、リソース予測時に、サービス要素間、またはサービス要素とネットワーク機能間での相互作用の有無を確認し、相互作用がある場合、前記相互作用によるリソース量を、予測するリソース量に反映することを特徴とする。計算資源が仮想化されていない場合にも対応することができる。

【0017】

本発明に係るサービス開発プログラムは、コンピュータを、前記サービス開発システムとして機能させるためのプログラムである。本発明のサービス開発システムは、コンピュータとプログラムによっても実現でき、プログラムを記録媒体に記録することも、ネットワークを通して提供することも可能である。

【発明の効果】

【0018】

本発明は、ネットワークの詳細な知識が無くともアプリケーションを作成する際に要求される計算資源量とネットワーク機能のリソース量を予測できるサービス開発システム、リソース予測方法及びサービス開発プログラムを提供することができる。

【図面の簡単な説明】

【0019】

【図1】マイクロサービスアーキテクチャを説明する図である。

【図2】Ｎｏｄｅ Ｒｅｄのような部品組み合わせ型のサービス開発システムを説明する構成図である。

【図3】本発明に係るサービス開発システムを説明する構成図である。

【図4】サービス開発システムを用いてアプリケーションのサービス構成を生成する作業を説明する図である。

【図5】本発明に係るサービス開発システムを用いてアプリケーションのサービス構成を生成する作業を説明する図である。

【図6】サービス要件テーブを説明する図である。

【図7】サービス要件の設定順序を記したイベントリストの例である。

【図8】本発明に係るサービス開発システムのサービス要件適用部の動作を説明するフローチャートである。

【図9】本発明に係るサービス開発システムのサービス要件適用部による効果を説明する図である。

【図10】本発明に係るサービス開発システムのリソース予測部がリソース量を推測する動作を説明するフローチャートである。

【図11】本発明に係るサービス開発システムのリソース予測部が計算資源が仮想化されていない場合にリソース量を推測する動作を説明するフローチャートである。

【図12】本発明に係るサービス開発システムのリソース予測部がリソース量を変更する場合の動作を説明するフローチャートである。

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

【0020】

添付の図面を参照して本発明の実施形態を説明する。以下に説明する実施形態は本発明の実施例であり、本発明は、以下の実施形態に制限されるものではない。なお、本明細書及び図面において符号が同じ構成要素は、相互に同一のものを示すものとする。

【0021】

図３は、本実施形態のサービス開発システム３０１を説明する構成図である。サービス開発システム３０１は、２つ以上のサービス要素を組み合わせてサービス構成を形成して１つ以上のアプリケーションを作成するマイクロサービスアーキテクチャを用いるサービス開発システムであって、
サービス要素リスト１１及びインターフェイス１２の他に、
入力された、前記アプリケーションに求められる１以上のサービス要件をサービス要件テーブルに記載するサービス要件投入部１３と、
前記サービステーブルに記載されたそれぞれのサービス要件をネットワークの設定情報に変換し前記サービス構成にマッピングするサービス要件適用部１４と、
サービス要件がマッピングされた前記サービス構成を仮想的に動作させ、それぞれのサービス要件を満たす計算資源とネットワーク機能のリソース量を予測するリソース予測部１５と、
を備える。

【0022】

アプリケーション開発者は、サービス開発システム３０１を用いて、サービス要件をサービス要件テーブルに入力し、そのサービス要件テーブルを基にネットワーク機能の割当及び集約等も考慮し必要なリソース量を予測してリソースを割り当てる。サービス開発システム３０１を用いることでネットワーク機能及びサービス要素に効率的なリソース割当を可能にする。

【0023】

図５は、サービス開発システム３０１を用いてアプリケーションのサービス構成を生成する作業を説明する図である。サービス開発システム３０１では、図４で説明した作業に次のステップが追加される。
ステップＳ１１：開発者は、サービス要件投入部１３を介してサービス要件を抽象化したサービス要件をサービス要件テーブルに投入する。
ステップＳ１２：サービス要件がサービス要件テーブルに投入されると、サービス要件適用部１４は、サービス要素のネットワーク構造を生成し、サービス要件の適用場所毎にサービス要件を集約する。更に、開発者が提供する他のサービスまたは、他の開発者が提供するサービス等とサービス要件を集約可能かを判別する。
ステップＳ１３：サービス要件適用部１４のサービス要件の適用先に従い、リソース予測部１５は計算資源及びネットワーク機能の割当を行う。リソース予測部１５は計算資源やネットワーク構造を仮のシステム上で構築して動作をさせ、計算資源の単位時間辺りの使用量を測定を行う。リソース予測部１５はその測定結果からサービス要件適用における各サービス要素の資源予測を行い、必要な計算資源量を計算して各サービス要素にリソースを割当てる。

【0024】

サービス開発システム３０１の各構成部を具体的に説明する。

【0025】

（１）サービス要件投入部
サービス要件投入部１３はサービス要件を抽象化したサービス要件をサービス要件テーブルに入力する。図６はサービス要件テーブルの入力例である。従来、サービス要件はサービス要素毎に個別にパラメータとして入力したり、ネットワーク機能を選択する等をしていた。サービス要件投入部１３はサービス要件をテーブル形式で入力することにより、後述するポリシの集約等が容易となる。本例では、サービス要件のフィールドとしてポリシ名（要件名）、適用場所、適用条件、及び動作を示すが、これらに限定されるものではない。

【0026】

サービス要件のサービス要件テーブルへの入力は、サービス要素を提供するサービス要素提供者が事前に入力してもよいし、サービス要素を組み合わせてアプリケーションを作るサービス事業者が入力してもよい。また、サービス要素提供者、及びサービス事業者は一つの適用場所に複数のサービス要件を適用してもよい。

【0027】

要件名は適用させるサービス要件を表す（例：Ｓｃａｌｉｎｇ ｒｕｌｅ， ｓｅｃｕｒｉｔｙ ｒｕｌｅ）。
適用場所はサービス要素の組み合わせの中でのそのサービス要件を適用する場所（例：サービス要素１：入力１）を表す。
適用条件はそのサービス要件を反映する条件（例：ユーザ数が１００を超えた場合や、サービス開始時）を表す。
動作はそのサービス要件での動作（例：リソース２倍までのリソースを使って冗長化）等を表している。

【0028】

なお、サービス要件が一つのリソースに集約される場合、設定順序の依存関係があるため設定順序を記したテーブルをシステムが持つ必要がある。図７はその設定順序を記したイベントリストの例である。
イベント名はサービス要件及び運用する上で必要なコマンド（例：ｉｎｓｔａｎｔｉａｔｅ， ｓｃａｌｅｏｕｔ ａｄｄ）を表す。
実行優先度は設定の設定順序を表している。同じ実行優先度のものは順序が逆転しても問題ないものを示している。

【0029】

（２）サービス要件適用部
サービス要件適用部１４はサービス要素の組合せとサービス要件を基にリソースを適用する。図８は、サービス要件適用部１４の動作を説明するフローである。図９は、サービス要件適用部１４による効果を説明する図である。

【0030】

ステップＳ２１：サービス要件テーブルにサービス要件が投入されていることを確認する。
ステップＳ２２：サービス構成にサービス要件をマッピングし、適用場所で並び替えを行い、同一の適用場所に設定されているサービス要件を探索する。
ステップＳ２３：同一適用場所に複数のサービス要件がある場合は複数のサービス要件の集合を満たす条件となる。例えばｓｃａｌｉｎｇ ｒｕｌｅとｓｅｃｕｒｉｔｙ ｒｕｌｅの両方がサービス要素１：入力１になった場合は、ｓｃａｌｉｎｇ ｒｕｌｅを満たす集合をＮ｛ｓｃａｌｉｎｇ ｒｕｌｅ｝、ｓｅｃｕｒｉｔｙ ｒｕｌｅを満たす集合をＮ｛ｓｅｃｕｒｉｔｙ ｒｕｌｅ｝とすると、両方を満たす集合となるためＮ｛ｓｅｃｕｒｉｔｙ ｒｕｌｅ｝∪ Ｎ｛ｓｅｃｕｒｉｔｙ ｒｕｌｅ｝となる。
ステップＳ２４：他のアプリケーション（同一サービス事業者の他のアプリケーションでもよいし、他のサービス事業者でもよい）とサービス要件を共有できる設定になっているかどうかを確認する。
ステップＳ２５：他のアプリケーションと共有できない設定になっている場合、サービス構成上にサービス要件を配置する設定テンプレートを生成する（図９（ｂ）参照）。
ステップＳ２９：他のアプリケーションと共有できる設定の場合、他のアプリケーションで同一のサービス要件があり、かつ、収容可能かどうかを判断する。不可能であれば自身のサービス構成に適用する設定テンプレートを生成する（ステップＳ２５）。
ステップＳ３０：可能であれば他のアプリケーションにおいてリソース量の予測を行う。ステップＳ３１：リソースの増設も含めて設定テンプレートを生成し、他のアプリケーションにネットワーク機能を収容する。
ステップＳ２６：サービス要素をインターフェイスで接続してサービス構成を組み立てるとともに、サービス構成の所定の適用場所にサービス要件の設定テンプレートを追加する（図９（ｃ）参照）。
ステップＳ２７：サービス要件でサービス構成を分割し、例えばスケールアウト等の場合はサービス要素の複製が必要なのでサービス要件の必要に応じてサービス要素を複製する（図９（ｄ）参照）。
ステップＳ２８：図９（ｄ）のように形成されたサービス構成に基づいてリソース割当部２１がリソース量の割当を行う。ここで、リソース割当部２１はサービス要件毎にリソース量が決められている場合、それを利用して割り当てを行う。一方、サービス要件毎にリソース量が決まっていない場合、リソース予測部１５がリソース量を推測し、推測されたリソース量に基づいてリソース割当部２１がリソース割り当てを行う。

【0031】

（３）リソース予測部
リソース予測部１５はリソース量の予測を行う。図１０は、リソース予測部１５がリソース量を推測するフローの１例を説明する図である。
ステップＳ４１：計算資源をホストに割り当てる。例えばホップ数が最小になるようにネットワーク構造に基づいてリソース量を割り当てる。本例ではホップ数が最小としたが、他の条件でもよい。
ステップＳ４２：リソース量を予測する。予測方法としてはいくつかの方法があるが一例を以下に示す。
サービスを構築前にシミュレーション用のホストで、計算資源、サービスに関係する計算資源、または、同じホストで立ち上がる計算資源を起動し（計算資源の仮想化を行い）、計算資源の起動、動作、停止等の一連の動作を行う。そして、計算資源の単位時間のリソース量（メモリ、ネットワーク、ディスクＩＯ、サービス要素の処理時間、処理速度等）を測定する。同時に計算資源の中で単位時間のリソース量の増加が大きいプロセスを抽出する。ここで、リソース量の変化量から一定時間後（一日、一週間、一か月等）の全体のリソース量を予測する。また、リソース量の増加が大きいプロセスについてもリソース量の変化量から一定時間後のリソース量を予測する。
推測したリソース量が満たすべき閾値をリソース量が上回った場合は計算資源の資源増設及び、資源の再割り当てを行う。閾値は例えば次のように決定する。サービス要件としてサービスの応答速度が１ｓ以内等の条件があるとする。サービス要素の接続数、または処理時間を測定した結果から、そのサービス要素が満たさなければならない処理時間を求める。そこからサービス要素のリソースの閾値が変わった場合の処理時間を経験則及び、過去の履歴から求めることでサービス要素が満たさなければならない閾値を求める。事前に上記のデータを取得しておき、サービスを開始する時は実際に割り当てるのではなく上記のデータを基にリソース量を予測するでもよい。予測方法はこの方式に限らず他の方法を用いてもよい。

【0032】

ステップＳ４３：計算資源の割当では、まずは自身のホストに割当可能か判断し、割当られない場合は他のホストに割り当てる。割当の判断では、ホストに割り当てられているリソース量が自身の計算資源が使うリソース量を満たすかどうか、またはホストに割り当てられている他のサービス要素が増えた時に自身の計算資源が使うリソースを満たすかどうかを判断する。この時、ＣＰＵ、メモリは仮想資源として完全に計算資源ごとに分離できるがネットワークＩＯやディスクＩＯは完全に分離できないため、割り当てた場合の影響を判断する。
計算資源への割当は均等に割りあててもよいし、サービス要素の処理内容によってリソース量の割当比率を変えて割り当ててもよい。例えばハートビートのような監視に対しては信頼性が求められるためネットワークＩＯを優先的に割当てること等が考えられる。この時この割当比率を計算資源をホストに割り当てた時にサービス要件を満たせるかどうかを判断し、サービス要件を満たせる場合はサービス要件を満たすホストに対して計算資源の割当を行う。なお、上記サービス要件とは例えば信頼性や応答時間等である。ネットワークの系全体での信頼性を計算し、条件を満たすことができるホストを探し出したり、遅延が条件を満たすことができるようなホストを探索する。
例えば、α、βをモジュールの信頼度とした時、系全体の信頼性は下記の式で得られる。
直列接続 Ｒ１＝α×β
並列接続 Ｒ２＝１−（１−α）×（１−β）
この時モジュールを組み合わせた系全体の信頼性はＲ＝（γＲ１、δＲ２）で与えられる。（γ、δは任意）
この時の信頼性Ｒはサービス要求レベルをＣとした時に下記として与える。
Ｒ＝εＣ（εは任意）
上記のようにして系全体の信頼性を計算し、最適なホストを探し出してリソースを割り当てる（ステップＳ４４）。

【0033】

ステップＳ４５：サービス要件を満たせない場合はサービス要件を満たすホスト（例えば、信頼性が９０％、応答速度が１ｓ以下等）を探索し計算資源を割当て直す。例えば、再度、ホップ数が最小になるように計算資源をホストに割当を行う。これにより、計算資源をホストに割当が可能となる。この方法は一例であり、他の方式を用いてもよい。ホストを割当の後に計算資源を割り当てたホストに経路を切り替える。

【0034】

図１１は、リソース予測部１５がリソース量を推測するフローの他の例を説明する図である。本例は、計算資源が仮想化されていない場合の例である。
ステップＳ５１：サービス要素毎の特性からどのくらいのリソース量が必要かを取得する。これは事前に測定したデータに基づいてもよいし、ステップＳ４２のように実際に測定を行ってもよい。
ステップＳ５２：同一リソースに複数のサービス要素の組み合わせがあり、かつそれぞれのサービス要素が相互作用する可能性があるかを判断する。完全に論理的に分離していればほとんど影響はないが、例えば相互で通信する場合や同じリソースを取りに行くために待ちが発生する場合は相互作用が発生する。
ステップＳ５３：サービス要素間で相互作用する場合は過去のデータ等から相互作用で発生する必要なリソース量を取得する。例えば、サービス要素間の通信が発生するプロセス、その時の通信量、共有するリソースとその影響度を事前データとしてもっておき、サービス要素が実行された時にそのデータを基に相互作用で必要なリソース量を予測する。
ステップＳ５４：同一リソースにサービス要素とネットワーク機能の組み合わせがあり、かつそれぞれのサービス要素が相互作用する可能性があるかを判断する。ステップＳ５２と同様である。
ステップＳ５５：サービス要素とネットワーク機能とで相互作用する場合は過去のデータ等から相互作用で発生する必要なリソース量を取得する。ステップＳ５３と同様である。
ステップＳ５５：サービス要素とネットワーク機能とで相互作用する場合は過去のデータ等から相互作用で発生する必要なリソース量を取得する。

【0035】

図１２は、リソース予測部１５がリソース量を変更するフローを説明する図である。
ステップＳ６１：リソース予測部１５は計算資源またはネットワーク機能のリソース量を取得する。この取得には計算資源の単位時間のリソース量（メモリ、ネットワーク、ディスクＩＯ、サービス要素の処理時間、処理速度等）を定期的に測定する。
ステップＳ６２：計算資源またはネットワーク機能のリソース量を予測する。予測にはサービス要件に基づいてその条件を満たすようにリソース量を予測する。例えば図１０のステップＳ４２の方法の例の場合は実際に計算資源で実行されているサービス要素のプロセスの時系列データを取得し、そのプロセスの実行頻度から一定時間後に使われるリソース量を予測する。
ステップＳ６３：サービス要件を考慮してリソース量が不足していないかを判断する。
不足してない場合はサービスを継続する。
ステップＳ６４：リソースが不足している場合はリソース量を変化させた時にサービスに影響があるかどうかを調べる。例えばスケールアップ、ダウンであればサービスに与える影響は少ない。ホストが切り替わる場合はサービスに影響が発生する。
ステップＳ６５：サービスの影響がない場合はリソース量を予測しそのリソース量にリソースを変化させる。
ステップＳ６６：サービスの影響がある場合はサービス要素を別のホストのリソースに生成し、状態を引き継ぐ。ステップＳ６７：サービスへの影響が少ないタイミングでそのサービス要素に繋がる回線を切り替えることで瞬時に切替を行う。
ステップＳ６８：正常にサービスが移行できた場合は元のサービス要素を削除する。
ステップＳ６９：サービスを継続する。これを繰り返す。

【0036】

［付記］
上記本発明の課題を解決するための、本実施形態（図３）と従来技術（図２）との相違点は次の通りである。
・サービス要件テーブルを備えたこと
・サービス構成にサービス要素とサービス要件を適用したこと
・リソース量の予測
上記相違点による効果は次の通りである。
・ネットワーク機能を一つの計算資源に集約することができる
・従来はネットワーク機能を一つ一つ設定しており、ネットワーク機能を一つの計算資源に集約することができなかった
本発明で上記効果を得られる理由は次の通りである。
・ネットワーク機能をサービス要件として入力することでサービス要件を集約することが可能となり、更に必要なリソース量を予測することで割当リソースを判断できるため一つの計算資源に集約可能となる。

【符号の説明】

【0037】

１１：サービス要素リスト
１２：インターフェイス
１３：サービス要件投入部
１４：サービス要件適用部
１５：リソース予測部
２１：リソース割当部
３００、３０１：サービス開発システム

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】