JP2020087007A - クラウドサービスの設定装置、システムおよび設定方法 - Google Patents

Abstract

【課題】将来にわたる一定期間のクラウドサービスの無駄な支出を抑制するクラウドサービスの設定装置、システム及び設定方法を提供する。【解決手段】本発明の設定装置は、ユーザ要求に基づいて複数のクラウドサービスから適切なクラウドサービスを選択し、選択されたクラウドサービスの設定を行う。複数のクラウドサービスの機能及びサービスに対するコストと、複数のクラウドサービスを設定するコマンドをクラウドアセット情報として格納する記憶装置と、記憶装置に格納されたクラウドアセット情報とユーザの要求とに基づいて、将来発生するコストを予測し、予測されたコストに基づいて、複数のクラウドサービスから一つのクラウドサービスの選択を、選択されるべき時間情報と、選択されたクラウドサービスの設定コマンドを含む設定情報を生成し、設定情報を時間情報に従って、設定対象となる中継装置に送信する処理部を有する。【選択図】図１４

Description

本発明は、クラウドサービスを利用するための各種設定を行う設定装置、システムおよび設定方法に関する。

クラウドサービスは、使いたいときに使いたいリソースを配置することが可能である。またクラウドサービスでは、リソースを使わない場合は、経費が掛からない従量課金制度を導入している。複数ある他社商材のクラウドサービスを用いる場合、各クラウドサービスは課金形態が非常に複雑で、またクラウドサービスを使用するに当たっても、CPU性能、ストレージ容量等設定項目が多数あり非常に手間である。

特に、従量課金を用いているため、使用頻度やデータ量、VM数等によってコスト（支出）が変わる。また、各クラウドサービスで料金体系が違うため、各クラウドサービスの支出を比較することも非常に手間である。特に顧客の要望に従いシステム構築を行うSI(System Integration)ビジネスにおいて、顧客からの要望は様々であり、料金体系が違う複数クラウドサービス中からベストプラクティスなクラウドサービスを選択して、迅速にシステム構築を行うことが求められてきている。

クラウドシステムを構築する技術として、特許文献１がある。特許文献１には、オンプレミスやクラウドのアプリケーションの利用状況（CPU使用率、メモリ使用率、ストレージ使用率、稼働時期等）を収集し、収集した利用状況を基にアプリケーションの特性を統計処理し、統計処理した結果を基にクラウドのリソースに変化がある場合、買い付けパターンを変化させるクラウドリソース選択装置の記載がされている。

特開２０１７−１４２６７３号公報

特許文献１では、クラウドリソース選択装置がオンプレミスやクラウドのアプリケーションの利用状況を収集、統計処理し、統計処理した結果を基にクラウドのリソースに変化がある場合、買い付けパターンを変化させる。つまり、リアルタイムに統計処理及び計算を行い、買い付けパターンを変化させて、クラウドサービスの設定変更を行う。クラウドサービスの設定変更が必要な場合、システム内に予めに設定変更に対応する必要な機能を事前に準備していないため、設定変更に手間がかかり、そのためクラウドサービスが一時的に停止してしまう可能性がある。

また、特許文献１の技術では、複数クラウドサービスを切り替えるシステムへと適用した場合、無駄な支出を防止するため、複数クラウドサービスの料金体系の変化を複数年に渡って考慮することについて、言及されていない。

また、切換のタイミングについても考慮されていないため、クラウドサービスの切換時にクラウドサービスが一時的に停止し、顧客満足度を下げてしまう可能性がある。

そこで、本発明の目的は、将来にわたる一定期間のクラウドサービスの無駄な支出を抑制し、ベストなクラウドサービスへの設定切換を、シームレスに行うことができるクラウドサービス設定装置、システムおよび設定方法を提供することにある。

上記課題を解決するための、クラウドサービス設定装置の一態様は、ユーザ要求に基づいて複数のクラウドサービスから適切なクラウドサービスを選択し、選択されたクラウドサービスの設定を行う設定装置において、設定装置は、複数のクラウドサービスの機能及びサービスに対するコストと、複数のクラウドサービスを設定するコマンドをクラウドアセット情報として格納する記憶装置と、記憶装置に格納されたクラウドアセット情報とユーザの要求とに基づいて、将来発生するコストを予測し、予測されたコストに基づいて、複数のクラウドサービスから一つのクラウドサービスの選択を、選択されるべき時間情報と、選択されたクラウドサービスの設定コマンドを含む設定情報を生成し、設定情報を、時間情報に従って、設定対象となる中継装置に送信する、処理部と、を有する。

本発明によれば、予め必要となる設定を複数保持することで、将来に渡って複数クラウドサービスから最適なクラウドサービスを選択して利用することができる。

また、クラウドサービスの設定変更を、システムの利用状況を勘案して実行するので、サービスが停止することなく、シームレスにクラウドサービスを利用することができる。

システム構成図である。 キッティング装置の動作を説明する図である。 クラウドアダプタの動作を説明する図である。 クラウドアダプタ内部のブロック図である。 クラウドアダプタ及びキッティング装置内部のブロック図である。 キッティング装置が必要とする各種パラメータを入力するGUIを説明する図である。 過去のユーザ要求（データ量、ＶＭ数、蓄積量など）を説明する図である。 クラウドアセットDBを説明する図である。 履歴データDBを説明する図である。 過去のユーザ要求（データ量、ＶＭ数、蓄積量など）から求めた予測結果を説明する図である。 過去のユーザ要求（データ量、ＶＭ数、蓄積量など）から求めた予測結果より算出した将来支出を説明する図である。 過去のユーザ要求（データ量、ＶＭ数、蓄積量など）から求めた予測結果より算出した将来支出の推移を説明する図である。 設定情報部の一機能を説明する図である。 キッティング装置の一連の動作を示すフローチャート図である。 複数クラウドアダプタにキッティング装置が行う制御を説明する図である。 OT-ハブから送信されるデータ量の推移を説明する図である。 キッティング制御部の一連の動作を示すフローチャート図である。 キッティング装置のGUIを説明する図である。 キッティング装置のハードウェア構成図である。

以下、図面を参照して本発明を実施するための形態（以下、「実施形態」という）について説明を行う。

以下、図面に基づいて、本発明の実施例を説明する。添付図面では、同じ要素を同じ番号で表示する場合がある。

さらに、本発明の実施例においては、後述するように、汎用コンピュータ上で稼動するソフトウェアで実装しても良いし、専用ハードウェアで実装してもよいし、又はソフトウェアとハードウェアの組み合わせで実装してもよい。

以下では「プログラム」を主語（動作主体）として本発明の実施形態における各処理について説明を行う場合がある。メモリに格納されたプログラムは、プロセッサによって実行されることで定められた処理を行うため、実際の処理主体はプロセッサであるが、説明のためにプログラムを主語として説明する場合がある。プログラムの一部又は全ては専用ハードウェアで実現してもよく、また、モジュール化されていてもよい。各種プログラムはプログラム配布サーバや記憶メディアによって各計算機にインストールされてもよい。

以後の説明では、各種情報をテーブル形式で説明するが、管理用の情報は必ずしもテーブルによるデータ構造で表現されていなくてもよい。

本実施形態に記載されたラウドサービス設定装置、システムおよび設定方法は、複数あるクラウドサービスの料金体系を予め保持もしくはリアルタイムに取得し、システムのデータ量やVM数等の変化に基づいて複数のサービスで比較し、料金を将来にわたって予測して最適なクラウドサービスを選択し、予め必要となる設定を複数保持することで、将来に渡って複数クラウドサービスから最適なクラウドサービスを選択する技術に関する。

また、本実施形態に記載されたラウドサービス設定装置、システムおよび設定方法は、クラウドサービスの設定変更を、システムの利用状況を勘案して実行するので、サービスが停止することなく、シームレスにクラウドサービスを利用することができる技術に関する。

本実施形態におけるシステム構成図を図１に示す。図１は、複数センサから送信されるデータをOT(Operational Technology)-ハブ108及びクラウドアダプタ106を経由して、複数クラウドへと転送するシステム100を示した図である。

システム100は、複数のセンサ109、OT-ハブ108、Kitting Concierge（キッティング装置）107、クラウドアダプタ106、ネットワーク105およびAzure（登録商標）101、AWS（登録商標）102、GCP（登録商標）103、Bluemix（登録商標）104を含み、複数のセンサのセンサデータを、OT-ハブ108、クラウドアダプタ106およびネットワーク105を経由して、Azure101、AWS102、GCP103、Bluemix104等の、各クラウドサービスへとデータを転送する。このシステムにおいて、種々現場の状況をモニタリングするためにOT-ハブ108は複数のセンサ109を管理し、センサは、無線、有線の通信手段を用いてOT-ハブ108へとデータを送信する。OT-ハブ108は、センサ109からのデータをクラウドアダプタ106へと転送する。クラウドアダプタ106はネットワークを経由して各クラウドサービスへとデータを転送する。

これらのデータは、Azure101、AWS102等のパブリッククラウドを通して、顧客に提供される。OT-ハブ108とクラウドアダプタ106は、システムにおいて、データをクラウドサービスへと転送する中継装置( Gate Way：GW)と見なすことができる。

図２は、本実施形態のキッティング装置107の動作を説明する図である。キッティングとは、一般にパソコンやモバイル端末などの導入時に行う設定作業のことであり、ここでは、Azure101、AWS102等の各パブリッククラウドに対する中継装置、パブリッククラウドの設定作業を意味する。そのため、キッティング装置は、中継装置、パブリッククラウドの設定装置と呼ぶことができる。

クラウドアダプタ106は機能として、モニタリング207とクラウドハブ206という２つのメイン機能を備えている。クラウドハブ機能206は、クラウドアダプタ106が受信したデータを各クラウドサービスへと切り替えて転送する。キッティング装置107は、各クラウドサービス101、102、103、104を利用するため、センサ109からのセンサデータを、中継装置(OT-ハブ108、クラウドアダプタ106)を介して各クラウドサービス101、102、103、104に送信するための各種設定を行う。各種設定には、各クラウドサービス101、102、103、104への設定、クラウドアダプタ106に対して各クラウドサービスに対応するアダプタの配置（インストール）や設定コマンドによる各種パラメータの設定が含まれる。モニタリング207は、OT-ハブ108から転送されるデータ（例えば、センサデータ）のモニタリングを行い、クラウドハブ206はOT-ハブ108から送信されるデータをルーティングテーブルに基づき各クラウドサービスへと転送する。

クラウドサービスは複数あるが、代表例としてAzure101を挙げる。Azureでは、機能・サービスに対する各種設定を別の遠隔のサーバから制御するには、種々の設定パラメータをJson形式(Javascript Object Notation)に変換して、Json形式に変換された設定パラメータを、Rest(Representational State Transfer)でAzureへ送信する。

例えば、設定するパラメータとしては、resourceName、resrouceGroupName、subscriptionId等がある。Azureを用いる場合は、Microsoft社とサブスクリプション契約（無償評価版、従量課金プラン等）を行う必要がある。契約後、subscriptionIdが割り振られ、Azureを利用する際に、認証keyの一つとして確認を求められる。

Azure内の機能として、IoTHub機能を備えているが、もしIoTHub機能を用いたいのであれば、パラメータとしてiotHubDescriptionのパラメータを定義して、Azureに対してパラメータを送信する必要がある。

AzureのIoTHub機能は、何十億台ものIoTデバイスと双方向通信を確立することが可能であり、接続するデバイスのセキュリティは十分に確保し、デバイスの状態を把握し、コードを記述することなく他のAzureサービス、例えばStream Analytics等へ転送することができる。

また、各デバイスにコマンドや通知を信頼性の高い方法で送信することができる。その後、Stream AnaylyticsからAzureのPowerBIを用いれば、グラフィカルにデータの推移をリアルタイムに表示することが可能であり、Azureに接続できる環境があれば、どの場所においてもPowerBIを用いてデータを閲覧することが可能である。

またキッティング装置107は、クラウドアダプタ106に対して、各クラウドサービスに対するアダプタをクラウドアダプタ内へと配置する。各アダプタは、クラウドアダプタ106で受信したデータを各クラウドサービスへと転送する。OT-ハブ108はクラウドアダプタ106へとデータを送信する。

以上の通り、キッティング装置107は、どのパブリッククラウドを利用するか、言い換えると、OT-ハブ108が受信するセンサ109からのセンサデータをどのパブリッククラウドに転送するか、に応じて、クラウドアダプタ106と各パブリッククラウドの設定を行う。

図３は、本実施形態のクラウドアダプタ106の動作を説明する図である。クラウドアダプタ106はクラウドハブ206及びモニタリング207の機能を持ち、モニタリング機能は、OT-ハブ108から転送されるデータ（例えば、センサデータ）のモニタリングを行い、クラウドハブ206はOT-ハブ108から送信されるデータをルーティングテーブルに基づき各クラウドサービス101、102、103、104へと転送する。

ルーティングテーブルには、どのセンサの情報が、どのクラウドサービスに転送されるかが定義されている。また、ルーティングテーブルの内容は、キッティング装置107からダイナミックに変更することが可能である。ルーティングテーブルを制御することによりクラウドサービスの切り替えを制御し、データを転送するクラウドサービスを決定する。

モニタリング207は、クラウドアダプタが受信したデータのモニタリングを行い、解析を行う。また、解析した結果やアラートをキッティング装置107へと送信する。キッティング装置107は受信したアラートや解析パラメートを基に、クラウドアダプタ106と各パブリッククラウドの設定（キッティング制御）、特に設定のタイミングを制御する。

これにより、クラウドサービスの設定変更を、システムの利用状況を勘案して実行するので、サービスが停止することなく、シームレスにクラウドサービスを利用することができる。

図４は、本実施形態におけるクラウドアダプタ106内部の構成ブロック図である。クラウドアダプタ106は、図３で説明した通り、クラウドハブ206及びモニタリング207の機能を持っている。これら機能を遠隔のサーバからプログラミングするためにNode-RED Runtime417を備えている。複数のNode-REDを管理するMasterのNode-RED(図示せず)で動作を記述し定義することが可能である。

Node-REDは、グラフィカルなプログラミングツールであり、抽象的なブロックを画面上に配置して結線することによってプログラミングを行うことが可能である。Node-RED Runtime417からプログラミングを行うために、Node-REDに対してアダプタを備える必要があり、クラウドアダプタ106はNode-RED Adapter410を機能として備えている。

Node-RED Adapter410内で、クラウドハブ206及びモニタリング207の２つの機能をプログラミングにより定義する。クラウドアダプタ106内のクラウドハブ206は、ルーティング制御部416及び各クラウドサービスに対応するAzure Edge Adapter413、AWS Edge Adapter415等のデータを転送するための機能を備えたアダプタを持つ。これらのアダプタは、クラウドサービス毎に対応するもので、他のクラウドサービスでは、GCP Edge AdapterやBluemix Edge Adapterとして機能する。

またモニタリング207は、OT-ハブ108から転送されるデータのモニタリングをリアルタイムに行い、モニタリング結果に基づいてアラートや解析した情報をキッティング装置107へと送信する。例えば、センサデータの送信が多い場合やバースト的に発生している場合にアラートを送信する。クラウドサービスの設定変更を、システムの利用状況を勘案して実行するので、サービスが停止することなく、シームレスにクラウドサービスを切り替えるためである。

キッティング装置107は、SSH(Secure Shell)やDocker等の通信手法を用いて、クラウドハブ206内に、各クラウドサービスに対応するAzure Edge Adapter413、AWS Edge Adapter415をダウンロードする。つまり、OT-ハブ108から転送されるデータを、Azure101やAWS102内に転送できるように、Azure Edge Adapter413やAWS Edge Adapter415はキッティング装置107内でカスタマイズされる。

クラウドハブ206は、キッティング装置107からダウロードしたAzure Edge Adapter413やAWS Edge Adapter415の更新を行う。キッティング装置107は、ルーティング制御部416に対して、ルーティングテーブルを作成するためにRestまたはTCP（Transmition Control Protocol）通信等を用いて設定パラメータを送信する。

ルーティング制御部416は、受信した設定パラメータを元にデータをルーティング(AWSのS3に送信する等)するためルーティングテーブルを作成し、受信したデータをクラウドサービス毎に対応する各アダプタへと転送する。

また、キッティング装置107はAzure101、AWS102に対してRestで設定パラメータを送信する。AzureやAWS等の各クラウドサービスは、Rest処理部(406、409)でキッティング装置107から送信されるRestを受信して設定パラメータを解析し、機能管理部404、407へと設定パラメータを送信する。機能管理部は受信した設定パラメータを用いて、IOT-ハブ405やAWS IoT408等のAzureやAWSの機能を、AzureやAWS内に配置する。また、機能管理部はDockerを用いてAzure EdgeやAWS Edge等をクラウドハブ206内にダウンロードする。

このように、キッティング装置107は、ルーティング制御部416にルーティングテーブルを作成するためのパラメータの送信、クラウドハブ206に各クラウドサービスを利用するために必要となるアダプタの送信、各クラウドサービスに対し、クラウドハブ206から送信されるデータを受信するための機能を設定するパラメータを送信する。

図５は、本実施形態におけるクラウドアダプタ106及びキッティング装置107内部の詳細な構成ブロック図である。クラウドアダプタ106のモニタリング207は、データ収集部506、データ解析部507、アラート生成部508を含む。

データ収集部506では、クラウドアダプタ106で受信するセンサデータ等のデータをリアルタイムに収集する。データ解析部507では、データ収集部506により収集されたデータの解析を行う。解析としては、例えば、センサデータの種類やパラメータ等、どのデータが送信されているか、どのぐらいのデータ量が送信されているか、標準偏差はどのぐらいか等の統計的解析を行う。

統計的な解析を行うことで、受信するデータの特徴を評価する。例えば標準偏差がほぼ０に近いのであれば、データ量の急激な変化(必ずしも正しい評価ではない場合もあるが)が発生していないと評価することができる。つまり、簡単な評価としてバーストがほぼ発生しないと評価することができる。

データ平均量と標準偏差の比からバーストの程度も推測できる。例えばデータの平均量が80MBで標準偏差が10MBであれば、平均の1/8程度のバーストが発生している予測できる。もし平均量が40MBで標準偏差が10MBであれば、平均の1/4程度のバーストが発生していると予測でき、平均80MBと40MBでは標準偏差が同じでも全体の揺らぎとしては平均40MBのほうが2倍大きいと簡単に評価できる。

揺らぎが大きいシステム程不安定である可能性が高いため、比が大きいシステム程、クラウドサービスの切換、即ち、キッティング制御を後回しにすることが考えられる。つまり、揺らぎが大きいタイミングでは、各パブリッククラウドに対する中継装置であるクラウドアダプタの設定変更を行わないようにすることができる。そのため、解析結果に基づいてアラート生成部508で、解析結果を含んだアラートを生成し、キッティング装置107へと送信する。

キッティング装置107もNode-RED Runtime516を備え、遠隔からプログラミングが可能である。複数のNode-REDを管理するMasterのNode-REDで動作を定義することが可能である。Node-RED Runtimeからプログラミングを行うために、Node-REDに対してアダプタを備える必要があり、キッティング装置はNode-RED Adapterを機能として備えている。Node-RED Adapter内で、キッティング装置107の機能をプログラミンにより定義している。

キッティング装置107では、パラメータ取得部517でNode-REDから種々の設定パラメータを取得し、取得したパラメータを記憶装置に履歴データDB523として保存する。パラメータ取得部517がNode-REDから取得する種々の設定パラメータは、ユーザがクラウドサービスに要求する仕様、例えば、実際に格納されるデータ量、作成するＶＭ数、記憶装置として定義されるストレージ容量などに関する情報も含まれる。履歴データDBは、ユーザ要求の履歴情報を保持している。またキッティング装置107の記憶装置は、クラウドアセットDB524を備える。クラウドアセットDB524内には、各クラウドサービスで用いることができる機能・サービス(アセット)やそれらの機能・サービスに対するコスト及び、設定するに当たり必要なコマンドが、クラウドアセット情報として格納されている。

コスト予測部518は、履歴データDB523から取得した設定パラメータを基にして、履歴データDB523やクラウドアセットDB524内にある種々パラメータを用いて将来に渡る課金状況を多項式近似により予測する。

クラウドサービス選択部519では、コスト予測部518にて予測した結果に基づいて将来に渡り選択するクラウドサービスを決定する。

キッティング処理選択部520では、将来に渡って選択した複数クラウドサービスに対するコマンドを、クラウドアセットDBを用いて生成する。例えば、AzureのIoTハブを将来使用するとした場合、iotハブ_CreateorUpdateコマンドのフォーマットをクラウドアセットDBから取得し、フォーマット内に定義してあるパラメータを顧客の要望に従って設定し、コマンドを生成する。

他のクラウドサービスの機能に関しても、同様にクラウドアセットDBからコマンドフォーマットを取得し、パラメータを設定し、コマンドを生成する。その後、生成したコマンドをキッティング情報保持部521へと送信し、キッティング情報保持部521では、生成されたコマンドをキュー内に格納して、適切なタイミングにてコマンドをキッティング制御部522に送信する。

キッティング制御部522では受信したコマンドを、クラウドアダプタ106から送信されるアラートに基づいて、各クラウドサービス、クラウドハブ206、ルーティング制御部416にコマンドを送信する。

これにより、クラウドサービスの設定変更を、システムの利用状況を勘案して実行するので、サービスが停止することなく、シームレスにクラウドサービスを利用することができる。

図１９に、キッティング装置107のハードウェア構成図を示す。キッティング装置107は、パブリッククラウドであるAzure101等、中継装置であるクラウドアダプタ106にネットワーク105を介して接続するインタフェース1902を有する。ハードディスクやSSD等で構成される記憶装置1904は、クラウドアセットDB524、履歴データDB523、各種プログラムを格納する。各種プログラムは、Node-RED Runtime516、パラメータ取得部517、コスト予測部518、クラウドサービス選択部519、キッティング処理選択部520、キッティング情報保持部521、キッティング制御部522であり、各プログラムの動作説明は、図５で説明したとおりである。これらプログラムは、メモリ1903に読み出され、処理部であるCPU1901によって実行されることで、各機能を実現する。記憶装置1904、インタフェース1902、CPU1901、メモリ1903は、例えば、バスによって相互にデータ送受信可能に接続されている。

図６は、本実施形態におけるキッティング装置107が必要とする各種パラメータを入力するGUI(Graphical User Interface 以下GUI)601を説明する図である。今回入力するパラメータとして、センサ種類6011、使用するVMの数6012、センサの数6013、クラウドサービスに確保するストレージの容量6014、過去のユーザ要求（データ量、ＶＭ数など）が保存されたファイルの場所を示しているファイルパス6015を例にあげる。

キッティングを最適に行うに当たり、必要なパラメータは多数あり、顧客の要望に準じて追加する必要がある。例えば今回挙げた例以外には、CPU使用率、メモリ使用率、レイテンシ等のパラメータがある。顧客が持っているシステム又は要望するシステムでは、用いている又は用いたいセンサの種類としてTemperature(温度)、Thirsty(湿度)がある場合は、センサ種類に温度、湿度を記載する。

これらの情報から、キッティング装置107では、情報重要度、コスト、情報量を考慮して、AzureのBlobに保存すべきなのか、AWSのS3に保存すべきなのか、各クラウドサービスにおいてあらかじめ定義した条件に従い最も適切なクラウドサービスを選択決定する。

AzureのBlobは、AWSのS3が保証しているイレブンナイン程の耐久性は備えていないが、エクサバイト単位の容量と極めて高いスケーラビリティを持ち、必要なデータアクセス頻度に応じてホットレベル、クールレベル、またはアーカイブレベルに、数百個から数十億個のオブジェクトを保管でき、画像、ビデオ、音声、ドキュメント等、非構造化データを簡単かつ高いコスト効率で保存することがすることが可能である。

一方、AWSのS3は、ウェブサイトやモバイルアプリケーション、社内アプリケーション、IoTセンサやデバイスからのデータ等、どこからの、どのような量のデータでも保存と取得が可能なオブジェクト型ストレージで、イレブンナインと呼ばれる耐久性を提供し、何百万ものアプリケーションのデータを保管できるように設計されている。

そのため、条件の例として、温度情報は重要度が低いため、AzureのBlobに保存し、CPUイベントの履歴等はシステムのデバックを行う上で非常に重要なためAWSのS3に保存する等が挙げられる。

また、使用するVMの数では、どれぐらいの数のVMを使用する予定かをあらかじめ知っておくことで、キッティング装置107ではコストを考慮して、AzureのVMまたはGoogle PlatformのVMなのか、あらかじめ定義した条件（例：最安値）に従い各クラウドサービスにおいて最も適切なクラウドサービスを選択決定する。

センサの数の情報からも、キッティング107装置では、コスト、情報量を考慮して、各クラウドサービスにおいて最も適切なクラウドサービスを選択決定する。また顧客が要望するストレージ容量または必要なストレージ容量の情報から、コストを考慮して適切なクラウドサービスを選択決定する。

またキッティング装置107では、過去のユーザ要求またはシステムが必要としたリソースの履歴から、将来を推測してコストを計算して、将来に渡って支出が少ないクラウドサービスを選択決定する。

図７は、本実施形態において、クラウドサービスに対するユーザ要求（少なくともデータ量、ＶＭ数、ストレージ容量など）を説明する図である。図７では、例として、date(日付)7011、日付に対して、クラウドサービスに対して要求したデータ量7012、もしくはシステムとして必要となったデータ量7012、クラウドサービスに要求または使用したVM数7013、クラウドサービスに要求または使用したストレージの容量7014を示している。

ここでは、現在を2018年の場合、Past Data(過去のデータ)701として、2017年のデータを示している。過去のデータは多ければ、回帰等の手法により、正確な将来予測が可能である。このようなデータをcsvファイルとして保存しておき、キッティング装置107の持つ履歴データDB523に格納する。

キッティング装置107ではデータベースに格納されたデータを基にして、将来予測を行いキッティングの制御を行う。クラウドサービスを活用するに当たり必要なシステムのデータ(パラメータ)は、ここで定義した以外に、例えば、CPU使用率、メモリ使用率、レイテンシ、ネットワーク通信量、プロセッサのアイドル時間、バッファキャシュ量、swap量、異常Logメッセージ数、サーバアクセス数等のデータがある。但し、これら全てのデータがシステムを構築するに当たり、必ず必要であるわけではなく、システムに要求される性能に応じて用いればよい。

例えば、CPU使用率から推測できる情報としては、システムとして高い計算量が必要とされているのであればCPU使用率が常時高い推移にあるため、システムとしてCPU性能が高いVMを選択する必要がある。メモリ使用率でも同様に、メモリ使用量が高いのであれば、メモリ容量が高いVMを選択する必要がある。クラウドサービスを活用する場合、サーバは遠方に配置されていることが多く、遠方のサーバに接続するに当たり、レイテンシは重要なパラメータである。クラウドサービスにおいてレイテンシが大きい場合は、そのサービスを活用したシステムの応答性が悪くリアルタイム性には欠けてしまう。

図８は、本実施形態においてクラウドアセットDB524を説明する図である。キッティング装置107は、クラウドアセットDB524をデータベースとして備え、予め、クラウドアセットDB内には、各クラウドサービス801で用いることができる機能・サービス(Assets)802やそれらの機能・サービスに対するコスト803及び、設定するに当たり必要なコマンド804がJson形式等で格納されている。後に外部入力によって、新たな機能・サービスは追加することが可能である。

例えば、図８からAzureは、アセット、つまり機能・サービスとして、IOT-ハブやStream Analytics、Blobを持ち、それら価格（コスト）、$3000、$100、$1000を示している。これらの情報はあくまで例であり実際の価格とは異なる。また、それらの機能をAzureに設定するに当たって必要なコマンドは、iothub_CreateorUpdate、StreamAnalytics_Create、Blob_Createがあり、これらのコマンドを用いてAzureに対して機能・サービスを設定する。

AWSは、AWS IoT、S3、EC2等の機能・サービスがあり、Google クラウド Platformは、Compute Engine、クラウド Storage、クラウド Machine Learning Engine、Bluemixは、IBM Watson、Compute、Storage等の機能・サービスがある。

AWSにおいてEC2(Amazon Elastic Compute クラウド)は、安全でサイズ変更可能なコンピューティング性能をクラウド内で提供するWebサービスである。またIBM Watsonは、質問応答の高精度なAIである。これらのサービスは一部であり、各サービス・機能は相当数ある。また、データを高速で取り出す可能性がある。そのため、用いるデータベースのトランザクションはあまり確保されていないが、NoSQLデータベースが望ましい。

図９は、本実施形態において履歴データDB523を説明する図である。キッティング装置107では、履歴データDB523を備え、これらに図７で説明した過去のユーザ要求等（データ量、ＶＭ数、ストレージ容量など）を格納している。

これ以外に、システムを構築するに当たり必要なデータとしては、CPU使用率、メモリ使用率、レイテンシ、ネットワーク通信量、プロセッサのアイドル時間、バッファキャシュ量、swap量、異常Logメッセージ数、サーバアクセス数等のデータがある。これら全てのデータがシステムを構築するに当たり、必ず必要であるわけではなく、システムに要求される性能に応じて用いればよい。これらの過去履歴をデータベース内に格納し、保存格納したデータを基にして、コスト予測部518で、これらの過去履歴から多項式近似により将来のコストを予測し、将来に渡って最安値の条件に従った適切なクラウドサービスをクラウドサービス選択部519により選択する。また、この履歴データDBも、大量のデータを高速で取り出す可能性があるため、用いるデータベースは、NoSQLデータベースが望ましい。

図１０は、本実施形態において過去のユーザ要求（データ量1001、ＶＭ数1002、蓄積量(ストレージ容量)1003など）から求めた予測結果を説明する図である。図９に示した履歴データDBに格納されている過去のデータ履歴から、将来を予測する。将来予測を行うに当たって今回例として、データの多項式近似を行い、近似式から将来値を予測する手法をとる。このような分析は、Microsoft Excel、SAS、Stata、SPSS等様々なツールで容易に実行が可能であり将来値を容易に計算することができる。例えば図９に示したデータ量からXを日数、Yをデータ量として多項式近似を行うと、図１０から以下の数式で表すことができる。

これらの式から、将来値を算出することが可能である。

例として、図９では、2017年１〜10月までのデータのみであったが、図１０では2019年11月までの将来値を過去の履歴から算出し、予測している。図１０から、2019年11月には、データ量は、約70GBまで上昇すると予測することができる。このような予測は、データ量1001のみならず、VM数1002、蓄積量1003にも同様に適用することが可能であり、これらも過去の履歴から将来値を予測することができる。

図１１は、本実施形態において、クラウドサービスに対するユーザ要求（データ量、ＶＭ数、蓄積量など）から求めた予測結果より算出した将来支出を説明する図である。図１０で、データ量、VM数、蓄積量を多項式近似で2019年11月まで求めた結果から、2018年〜2019年11月までの支出を予測することができる。

例として、図１０から2018年１月は、データ量1001は約8GB程度、それらを処理するVM数1002は50程度となる。この要件に対する価格は、AWSの価格表（図示せず）により、例えば月額のコストが約$500程度となる。一方、2019年３月(1102)では、図１０からデータ量は約40GBで、それらを処理するVM数は、150程度に増加するため、AWSの価格表により、例えば月額のコストが約$620程度に上昇することを予測計算することができる。

同様にマイクロソフトの価格表（図示せず）によれば、Azureでは2018年１月は、例えば、月額のコストが約$300程度であり、2019年３月では、例えば、月額のコストが約$410程度になる。この表から読み取るに当たって、AWSはAzureに比べ初期投資は安いが、月額のコストはAzureに比べ高い。よって総支出は2018年１月ではAWSのほうが安いが、2019年３月では、Azureのほうが安くなる。これらの値は例であり実際の価格帯に沿って確実に計算することが必要である。

図１１に示した価格は、一例であって、パブリッククラウドサービスの提供事業者によって、常に更新される性質のものである。本実施例では、クラウトアセットDB524に最新の価格情報を格納するよう構成されている。

図１２は、本実施形態において、クラウドサービスに対するユーザ要求（データ量、ＶＭ数、蓄積量(ストレージ容量)など）から求めた予測結果より算出した将来支出の推移を説明する図である。前述の表からAWSはAzureに比べ初期投資は安いが、月額のコストはAzureに比べ高い。これらの料金の予測結果から図１２に示すような料金グラフ(1201)を描くことができる。

このグラフからも分かるように、将来総支出が2019年３月ではAWSのほうが高くなる。その後、AWSの支出がAzureに比べ、過度に高くなっていくことが分かる。このことから、総支出が高くなる2019年３月でAzureに転換することが将来に渡って支出を抑えることができる。これらの予測結果に基づいて(1202)、2019年３月にAzureに転換するようにキッティングコマンドを生成する。

これは例であり、初期投資を考慮し厳密な転換月を計算することが望ましい。例えば、現在のクラウドサービスと切り替え先のクラウドサービスとの初期投資額に$3000の差があった場合は、切り替える場合にも$3000多く投資額が発生する。そのため、$3000を考慮しても、今後は使用しているクラウドサービスを別のクラウドサービスへ切り替えた方が得であると判断できる場合のみに切り替える判断をすることが望ましい。

図１３は、本実施形態においてキッティング情報保持部(図５、521)の一機能を説明する図である。キッティング情報保持部521には、Wait Time Queue(ウェイトタイムキュー1302)とOn Demand Queue(オンデマンドキュー1306)といった２つのキューを備えている。ウェイトタイムキューは、選択されるべき時間情報と共に選択されたクラウドサービスの設定情報を時間情報と共に保持する。

キッティング処理選択部520は、クラウドアセットDB524を参照し、クラウドサービスを切り替えるためのキッティングコマンドを生成し、キッティング情報保持部521に送信する。つまり、キッティング処理選択部520は、コスト予測部518で予測されたコストに基づいて、クラウドサービス選択部519で選択された複数のクラウドサービスから一つのクラウドサービスを、選択されるべき時間情報と共に選択されたクラウドサービスの設定情報を生成する。

キッティング情報保持部521は、２つのキューを用いて、キッティングコマンドの振り分け制御を行う。初期は最安値のAWSを用いるためウェイトタイムキューにはAWSのキッティングコマンド(1305)が格納されている。前述のとおり、2019年３月にAzureにクラウドサービスを転換するため、Azureに設定変更を行うコマンド(1304)をウェイトタイムキューに格納する。

また、その後、GCPに移行するためGCPのキッティングコマンド(1303)も格納されている。ウェイトタイムキューでは、時間とコマンドを設定することにより、その時間になったらキューからコマンドが排出され、キッティング制御部へとコマンドが送信される。

キッティング処理選択部520によって生成されるキッティングコマンドは、複数のクラウドサービスから選択された一つのクラウドサービスの設定情報である。設定情報には、ヘッダー情報と設定コマンドを含み、ヘッダー情報には、ウェイトタイムキューかオンデマンドキューかのコマンド種別、ウェイトタイムキューの実行時間、クラウドサービスを特定する情報を含む。ウェイトタイムキューの実行時間は、複数のクラウドサービスから一つのクラウドサービスの選択されるべき時間情報である。また、設定コマンドには、ユーザ要求（データ量、VM数、蓄積量(ストレージ容量））等のクラウドサービスを特定するパラメータ等の設定情報、例えば、AWSでは、インスタンスのタイプを特定する情報が含まれる。

このように、ウェイトタイムキューには、選択されるべき時間情報と共に選択されたクラウドサービスの設定コマンドを時間情報と共に保持する。

コマンド生成のためのパラメータは、ユーザが入力するならばWebブラウザ上からパラメータを入力するか、種々パラメータが決まった複数インスタンスをあらかじめ用意しておき、そのインスタンスをユーザが選択したら自動に設定コマンドを生成することもできる。

キッティング制御部522は、キッティングコマンドに基づいて、各クラウドサービスに対してキッティングを行い、クラウドアダプタのクラウドハブに各クラウドサービスに対してのアダプタのインストールを行う。

また、オンデマンドキューも備えているため、ユーザ要求の過去の履歴がなくクラウドサービスに対して即時設定する場合においても、オンデマンドキューに、設定情報として設定コマンドを格納すれば、即時にキッティング制御部へとコマンドを送信し、クラウドサービスの選択や性能変更等の各種設定変更を即時に実行する。オンデマンドキューに格納される設定情報は、ウェイトタイムキューに含まれる実行時間がないか、設定情報作成時の時間情報が含まれる。

もし、即時にAzureに転換したいのであればオンデマンドキューにAzureの設定コマンドであるキッティングコマンド1308を格納すれば即時にAzureの設定を実行し、Azureに即時に転換する。GCP1307や他のクラウドサービスに対しても即時に転換が可能である。

以上の通り、本実施の形態では、将来予測に基づくクラウドの切換の設定には、ウェイトタイムキューでキッティングコマンドを、クラウドサービス切換のタイミングと共に複数準備しておくことができる。また、オンデマンドキューを用いれば、パブリッククラウド事業者による突然の価格設定の変更や、パブリッククラウドを利用してセンサデータの解析等を行うユーザの要望、例えば、多量のデータ解析を短時間で行いたいとか、多量のデータを安く格納したいといった要望、の変化に即応することができる。

パブリッククラウドに対するユーザの要望により、オンデマンドキューに新たにキッティングコマンドを設定した場合、オンデマンドキューより後に実行されるように設定されたウェイトタイムキューのコマンドについては、オンデマンドキューの設定時に、パブリッククラウドに対するユーザの要望に応じて、クラウドサービス選択部519により無効とするか有効のままとするか選択され、無効とされる場合には、キッティング処理選択部520により、キューからコマンドが解放される。

以上の通り、本実施形態では、複数のクラウド設定を、設定タイミングと共に格納するウェイトタイムキューと、パブリッククラウドの料金、性能等のアセットの変化や、パブリッククラウドのユーザのシステムに対する要求性能の変化に対応するオンデマンドキューの2種類のキューを用いて、キッティングを行うことで、ユーザに対し、ベストな構成のクラウドサービスを提供することができる。

図１４は、本実施形態において、キッティング装置107の一連の動作を示すフローチャート図である。キッティング装置107は、GUIの画面上からパラメータを入力後、実行ボタンを押すことによって動作が始まる(S1401)。

次に、GUI上に入力されたパラメータから、センサ種類、使用するVMの数、センサの数、クラウドサービスに確保するストレージ容量、過去のユーザ要求（データ量、ＶＭ数、ストレージ容量など）等の各種パラメータをNode-RED Runtimeを経由して、パラメータ取得部517にて取得する。この際、履歴データDBもRAMに読み込む(S1402)。

次に、コスト予測部518にて、履歴データDBから過去のユーザ要求を呼び出し、それらデータの近似式を求め、近似式から将来値を予測する(S1403)。

次に、将来値をクラウドサービス選択部519へと送信する。クラウドサービス選択部519は、予め、各クラウドサービスで用いることができる機能・サービス(Assets)やそれらの機能・サービスに対するコスト及び、設定するに当たり必要なコマンドがJson形式等で格納されているクラウドアセットDB524から、クラウドサービス毎の機能・サービス及びそれらに対応するコストを呼び出し、先程求めたリソースの将来値から、将来に渡ってコストの計算を行なう。その結果から、複数年に渡って支出が最も少なくなるクラウドサービスを選択する(S1404)。

選択するクラウドサービスの結果をキッティング処理選択部520へと送信する。キッティング処理選択部520は、選択したクラウドサービスの機能・サービスの設定を行うため、クラウドアセットDBから各機能・サービスに対応するコマンドを呼び出し、キッティングコマンドを形成する(S1405)。

形成したキッティングコマンドをキッティング情報保持部521では、即時設定が必要なオンデマンドキュー1306か一定時間経過後に設定を実行するウェイトタイムキュー1302に振り分け、それぞれのキューに格納する(S1406)。

その後、各Queueは設定時間または即時にコマンドをキッティング制御部522へと送信する。キッティング制御部522はクラウドアダプタ106の自動設定やクラウドの自動設定を行う(S1407)。これら一連の動作をキッティング装置107は実行し、複数のクラウドサービスを複数年に渡って切り替え、サービス停止を避けシームレスに接続を行う。

図１５は、キッティング装置107が複数クラウドアダプタにキッティング制御を行う説明図である。複数のクラウドサービス(101、102、103、104)は、複数のセンサがデータを送信している複数のGW(1507、1508、1509)からセンサデータ等のデータが転送されている。各GWがサービス停止を極力避けシームレスに複数のクラウドサービスに接続するためには、キッティング装置107が、クラウドアダプタ106に対して設定を行う時に、各GW（OT-ハブ、クラウドアダプタ）が処理するデータ量、即ち各GWに送信されるデータ量をリアルタイムにモニタリングする必要がある。

モニタリングを行わずに設定変更を強制的に実行した場合は、データ量等を把握することができずサービス停止を引き起こす可能性が非常に高い。これは管理するGWの数が多ければ多い程、サービス停止を引き起こす可能性は高くなる。よって不必要なサービス停止を避けるために、各GWの受信するデータ量を考慮して、データ量に従ってキッティング処理（クラウドアダプタの設定等）の優先制御を行う。キッティング装置107は、クラウドアダプタ106の中継装置から受信する中継装置のセンサデータの受信状況に基づいて、中継装置と選択されたクラウドサービスの設定変更のタイミングを制御する。

例えば、データ量が少ない順から先に設定を実行していく。またデータ量がある閾値を超えたGWに関しては設定変更を行わない。GWの受信データ量が過多の場合において設定変更を行うと、サービスの停止を引き起こす可能性があるため、データ量が過多の場合はなるべく設定変更は行わず、不必要なサービス停止を避ける。

また、送られているデータの重要度に従って制御してもよい。例えば、送信されている情報が非常に重要なかつ緊急を要するデータ（例として、自然災害が発生した地域の状況をリアルタイムでモニタリングしている場合）であれば設定変更を行わない等の制御も行うことができる。

図１６は、本実施形態においてOT-ハブから送信されるデータ量の推移を説明する図(1601)である。クラウドアダプタはモニタリング機能を備えているために、受信するデータ量をリアルタイムに計測している。この場合において、閾値を定義し、その閾値をデータの量が超えた場合に危険アラートをキッティング装置内のキッティング制御部に送信する。

またデータ量が安全領域に推移した場合も、安全アラートをキッティング装置に送信する。クラウドアダプタ106のモニタリング207は、これらデータの平均量や標準偏差を計算する統計解析を行い、平均データ量や標準偏差のデータもキッティング装置107へと送信する。また、閾値を超えた回数もカウントし、そのカウント数もデータとして保存しておく。これ以外にもデータ量のグラフの傾きを求め、閾値を定義し、閾値を超えたならばその回数をカウントすることも考えられる。また統計的に変化を検知するために、マハラノビスの距離を求める方法や、平均データ量からのユークリッド距離を求める手法等様々な手法は存在する。

キッティング設定装置107は、クラウドアダプタ106から受信するアラートと、平均データ量と標準偏差に基づいて、クラウドアダプタ106と選択されたクラウドサービスの設定変更のタイミングを制御する。

図１７は、本実施形態においてキッティング装置107の一機能であるキッティング制御部522の一連の動作を示すフローチャート図である。キッティング制御部522では、クラウドアダプタ106内のモニタリング207から送られるアラートに基づいて制御を行う。

まず、キッティング情報保持部521から、キッティング制御部522にキッティングコマンドが転送されてくる(S1701)。
Ktting制御部522では、転送されてくるキッティングコマンドを、クラウドアダプタ106やクラウド101に対して送信する(S1702)。この際、初めにクラウドアダプタ106のモニタリング207から送信されるアラートを受信しているか確認を行う(S1703)。

もしアラートを受信していたならば、そのアラートが閾値を超えて送信される危険アラートかの確認を行う(S1705)。もし危険アラートであれば、キッティング制御部522は、クラウドアダプタ106やクラウド101に対してキッティングコマンドの送信は行わない（S1706）。或いは、キッティングコマンドの送信を行っても、クラウドアダプタ106やクラウド101は、切り替えるための準備は行うが、ルーティング制御部416の設定は変更せず、流れてくるデータのルート変更は行わない(S1706)。モニタリング207が危険アラートのみを送信する場合、ステップS1702は省略することができる。

その後、キッティング制御部522は、一定時間後にアラートの確認を再び行い、安全なデータ量であることが確認できるアラートの受信を確認できた場合、アラート内に含まれているデータの平均量に従って優先制御を行う(S1704)。

また、標準偏差を併用して制御も可能であり、標準偏差が大であればバーストが発生する確率が高いので、標準偏差が少ないデータが流れているクラウドアダプタから優先的に設定制御を行うこともできる。これは、標準偏差だけでなく、ある閾値を超えた回数、つまりバーストした回数を標準偏差の代わりに用いることも可能である。閾値は、過去の平均データ量から求めることができる。

図１８は、本実施形態においてキッティング装置のGUI(1801)を説明する図である。キッティング装置107は、顧客要望に即時、柔軟に対応するために、GUIを備え、GUI上から、各種項目を設定することが可能である。設定するパラメータとしては、クラウドサービスを切り替える切り替え日、切り替えるクラウドサービス、使用するクラウドアセット等がある。

またGUI上から、今迄の総支出や、現在リアルタイムに送信されているデータ量の変化等を画面上から確認することができる。また利用するクラウドサービスの機能・サービスをGUI上から変更することができる。このようなユーザインターフェースはGUIでなくWeb APIでも転用は可能である。またこのGUIでは複数のシステムの設定が可能である。各システムの設定パラメータは、GUI上にあるタブを切り替えることによって表示設定することが可能である。

以上、本実施の形態によれば、複数あるクラウドサービスの料金体系を予め保持し、システムが扱うデータ量やVM数、システムが必要とするストレージ容量の変化に基づいて複数のサービスで比較することができる。

例えば、複数のサービスで、料金を将来にわたって予測し、より料金を抑えたクラウドサービスを選択し、選択されたクラウドサービスに切り替えるため、予め必要となるコマンドやプログラムのインストール等の設定を、切換時期と共に記憶するので、ユーザの要望に合ったクラウドサービスへの切換を、タイミングよく行うことができる。

また、パブリッククラウド事業者による突然の価格設定の変更や、パブリッククラウドのユーザの突然の要求しよう変更に対して、即応できる。

複数のクラウド設定を設定タイミングと共に格納するウェイトタイムキューと、パブリッククラウドの料金、性能等のアセットの変化や、パブリッククラウドのユーザのシステムに対する要求性能の変化に対応するオンデマンドキューの2種類のキューを有するので、ユーザに対し、ベストな構成のクラウドシステムを提供することができる。

また、クラウドサービスの切換のタイミングを中継装置が扱うデータに応じて、制御することでサービス停止を防止することができる。

101：Azure、 102：AWS、103：Google Platform、104：Bluemix、105：ネットワーク、106： クラウドアダプタ、107：キッティング装置、108：OT-ハブ、109：センサ、404：機能管理部、405：IOT-ハブ、406：Rest処理部、407：機能管理部、408：AWS IoT、409：Rest処理部、410：Node-red Adapter、412：Azure Edge、413：Azure Edge Adapter、414：AWS Edge、415：AWS Edge Adapter、416：ルーティング制御部、516：Node-red Runtime、504 Node-red Adapter、506：データ収集部、507：データ解析部、508：アラート生成部、516：Node-red Runtime、517：パラメータ取得部、518：コスト予測部、519：クラウドサービス選択部、520：キッティング処理選択部、521：キッティング情報保持部、522：キッティング制御部、523：リレキデータDB、524：クラウドアセットDB。

Claims (10)

1. ユーザ要求に基づいて複数のクラウドサービスから適切なクラウドサービスを選択し、選択されたクラウドサービスの設定を行う設定装置において、
   前記設定装置は、
   前記複数のクラウドサービスの機能及びサービスに対するコストと、前記複数のクラウドサービスを設定するコマンドをクラウドアセット情報として格納する記憶装置と、
   前記記憶装置に格納されたクラウドアセット情報とユーザの要求とに基づいて、将来発生するコストを予測し、
   予測されたコストに基づいて、前記複数のクラウドサービスから一つのクラウドサービスの選択を、選択されるべき時間情報と、選択されたクラウドサービスの設定コマンドを含む設定情報を生成し、
   前記設定情報を、前記時間情報に従って、設定対象となる中継装置に送信する、
   処理部と、
   を有することを特徴とする設定装置。
2. 前記設定装置は、さらに、
   前記選択されたクラウドサービスの設定情報を複数保持する第1の保持手段と、
   即時にクラウドサービスの設定変更を行う設定情報を保持する第２の保持手段と、を有することを特徴とする請求項１に記載の設定装置。
3. 前記処理部は、前記ユーザの要求として、クラウドサービスに要求するデータ量、ＶＭ数、およびストレージ容量に基づいて、将来発生するコストを予測することを特徴とする請求項１に記載の設定装置。
4. 前記処理部は、前記ユーザの要求として、データ量、ＶＭ数、およびストレージ容量に加え、クラウドサービスに要求するCPU使用率、メモリ使用率、レイテンシ、ネットワーク通信量、プロセッサのアイドル時間、バッファキャシュ量、swap量、異常Logメッセージ数、サーバアクセス数の少なくとも一つに基づいて、将来発生するコストを予測することを特徴とする請求項１に記載の設定装置。
5. 複数のセンサと、前記複数のセンサに接続される中継装置と、前記中継装置に接続される複数のクラウドサービスと、前記中継装置と前記複数のクラウドサービスの接続を設定する設定装置とを有するシステムにおいて、
   前記中継装置は、
   前記複数のクラウドサービスの機能及びサービスに対するコストと、前記複数のクラウドサービスを設定するコマンドをクラウドアセット情報として格納する記憶装置と、
   前記記憶装置に格納されたクラウドアセット情報とユーザの要求とに基づいて、将来発生するコストを予測し、
   予測されたコストに基づいて、前記複数のクラウドサービスから一つのクラウドサービスの選択を、選択されるべき時間情報と選択されたクラウドサービスの設定コマンドを含む設定情報を生成し、
   前記設定情報を、前記時間情報に従って、設定対象となる中継装置に送信する、
   処理部を有し、
   前記中継装置は、前記複数のセンサから受信しているセンサデータのデータ量が閾値を超えた場合、前記設定装置にアラートを送信し、
   前記設定装置は、前記中継装置から受信するアラートに基づいて、前記中継装置と前記選択されたクラウドサービスの設定変更のタイミングを制御することを特徴とするシステム。
6. 前記中継装置は、複数配置され、
   前記中継装置のそれぞれは、前記複数のセンサから受信しているセンサデータのデータ量が閾値を超えた場合に送信するアラートと、前記複数のセンサから受信しているセンサデータの平均データ量を、前記設定装置に送信し、
   前記設定装置は、前記アラートと前記平均データ量に基づいて、前記中継装置と前記選択されたクラウドサービスの設定変更のタイミングを制御することを特徴とする請求項５に記載のシステム。
7. 前記中継装置は、複数配置され、
   前記設定装置は、
   前記中継装置のそれぞれは、前記複数のセンサから受信しているセンサデータのデータ量と標準偏差を、前記設定装置に送信し、
   前記標準偏差に基づいて、前記複数の中継装置の設定変更のタイミングを制御することを特徴とする請求項５に記載のシステム。
8. 前記中継装置は、複数配置され、
   前記設定装置は、
   前記中継装置が受信しているセンサデータのデータ量が閾値を超えた場合に送信するアラートと、データ量が閾値を超えた回数に基づいて、前記中継装置と前記選択されたクラウドサービスの設定変更のタイミングを制御することを特徴とする請求項５に記載のシステム。
9. 前記中継装置は、複数配置され、
   前記中継装置のそれぞれは、前記複数のセンサから受信しているセンサデータのデータ量が閾値を超えた場合に送信するアラートと、前記複数のセンサから受信しているセンサデータの平均データ量と、前記複数のセンサから受信しているセンサデータの平均データ量と、前記複数のセンサから受信しているセンサデータのデータ量と標準偏差とを、前記設定装置に送信し、
   前記設定装置は、
   前記中継装置から受信するアラートと、平均データ量と標準偏差に基づいて、前記中継装置と前記選択されたクラウドサービスの設定変更のタイミングを制御することを特徴とする請求項５に記載のシステム。
10. ユーザ要求に基づいて複数のクラウドサービスから適切なクラウドサービスを選択し、選択されたクラウドサービスの設定を行う設定方法において、
    設定装置は、
    前記複数のクラウドサービスの機能及びサービスに対するコストと、前記複数のクラウドサービスを設定するコマンドをクラウドアセット情報として、記憶装置に格納し、
    前記記憶装置に格納されたクラウドアセット情報とユーザの要求とに基づいて、将来発生するコストを予測し、
    予測されたコストに基づいて、前記複数のクラウドサービスから一つのクラウドサービスの選択を、選択されるべき時間情報と共に選択されたクラウドサービスの設定情報を、複数生成し、
    前記複数の設定情報を保持し、
    前記時間情報に従って、前記複数の設定情報の内の一つを、設定対象となる中継装置に送信する、
    ことを有することを特徴とする設定方法。

Images