JP7134937B2

JP7134937B2 - 情報処理装置、プログラムおよび情報処理システム

Info

Publication number: JP7134937B2
Application number: JP2019197533A
Authority: JP
Inventors: 智則前川; 弓子坂井
Original assignee: Toshiba Corp
Current assignee: Toshiba Corp
Priority date: 2019-10-30
Filing date: 2019-10-30
Publication date: 2022-09-12
Anticipated expiration: 2039-10-30
Also published as: US20210132977A1; US11635982B2; JP2021071872A

Description

本発明の実施形態は、情報処理装置、プログラムおよび情報処理システムに関する。

蓄電池、太陽電池などの分散電源を使い、地域のグリッドを構築する取り組みが進められている。また、電気自動車の台数も増えてきている。これらの新技術を使ったインフラを運用するためには、インフラの監視、分析、制御を行うＩｏＴ（ＩｎｔｅｒｎｅｔｏｆＴｈｉｎｇｓ）サービスの開発が必要である。

ＩｏＴサービスは、例えば、数万台～数百万台以上のＩｏＴデバイスに関連した処理を実行することが求められる。ただし、ＩｏＴサービスの開発段階および検証段階において、充分な数のＩｏＴデバイスを確保できるとは限らない。対象のＩｏＴデバイスが市場で入手可能となる前から、ＩｏＴサービスの開発または検証を進めなくてはならない場合もありうる。

特開２０１９‐１０９８５２号公報

ＡＷＳＤｅｖｉｃｅＦａｒｍ，Ｗｅｂ，ＵＲＬ：ｈｔｔｐｓ：／／ａｗｓ.ａｍａｚｏｎ.ｃｏｍ／ｊｐ／ｄｅｖｉｃｅ－ｆａｒｍ／

本発明の実施形態は、ＩｏＴサービスの開発および検証を支援する情報処理装置、プログラムおよび情報処理システムを提供する。

本発明の実施形態としての情報処理装置は、試験シナリオで規定されている通信モデルに基づきエミュレータにデータを送信させ、サービスに前記データを受信させるテストを計算機プラットフォーム上で実行するために必要となる計算資源量を計算し、前記計算機プラットフォーム内の計算機における前記エミュレータの割り当てを決定するリソース計算部と、前記計算機プラットフォームにアクセスし、前記計算資源量を確保する第１制御部と、前記計算機に割り当てられた前記エミュレータの設定を行う第２制御部とを備える。

テストサーバの構成の例を概略的に示したブロック図。計算機プラットフォームの例を概略的に示したブロック図。通信モデルデータの例を示したテーブル。試験シナリオの例を示したテーブル。テストサーバによるテスト開始時までの処理の例を示したフローチャート。クラウドサービスの利用コストを最適化する設定を求める処理の例を示したフローチャート。グラウド利用プランと実行可能なエミュレータ数の例を示すテーブル。変形例によるテストサーバの構成を概略的に示したブロック図。変形例によるテストサーバが実行する処理の例を示したフローチャート。

以下、図面を参照しながら、本発明の実施形態について説明する。また、図面において同一の構成要素は、同じ番号を付し、説明は、適宜省略する。

はじめに、本実施形態に関連した用語について説明する。

ＩｏＴデバイスとは、通信網を介して、他の装置にセンサの計測値または装置の設定値などのデータを送信する機能を備えた装置のことをいう。ＩｏＴデバイスの例としては、蓄電池、スマートメーター、太陽電池、発電設備、送配電設備、流量計、電気自動車、エレベータ、鉄道車両、建設機械、各種の車載機器、ドローン、工場の設備、医療機器、空調機器、スマートフォン、各種のウェアラブルデバイス、ゲーム機などが挙げられる。ただし、通信網を介して、データを送信する機能を備えているのであれば、ＩｏＴデバイスはどのような種類の装置であってもよい。通信網で使われる通信媒体は、無線、有線またはこれらの組み合わせであってもよい。また、通信網でどのような種類の通信プロトコルを使ってもよい。

ＩｏＴサービスとは、通信網を介して複数のＩｏＴデバイスとの間でデータ通信を行い、通信されたデータに基づき、ユーザにサービスを提供するソフトウェアのことをいう。例えば、ＩｏＴサービスは、通信網に接続されたサーバ上で実行される。ＩｏＴサービスが実行する処理の内容およびＩｏＴサービスがユーザに提供するサービスの内容については、特に問わない。例えば、複数のＩｏＴデバイスから収集したデータを分析し、ユーザにＩｏＴデバイスの稼働状況またはＩｏＴデバイスに関する予測結果を提供するＩｏＴサービスを構築することができる。また、ＩｏＴサービスは、複数のＩｏＴデバイスまたは複数のＩｏＴデバイスを含むシステムの制御または管理を行うものであってもよい。

また、コンピュータネットワークを介し、ユーザに複数の計算機上の実行環境を提供するサービスをクラウドサービスと呼ぶものとする。計算機は、物理計算機に限らず、仮想計算機（ＶＭ）または、コンテナであってもよい。また、必要に応じて、クラウドサービスが構築されている情報処理システムを、計算機プラットフォームと呼ぶものとする。クラウドサービス内では、計算機間のデータ通信を実現するコンピュータネットワークが提供されている。コンピュータネットワークは、物理ネットワークを使うものであってもよいし、仮想的なもの（仮想ネットワーク）であってもよい。

本実施形態に係る情報処理装置、プログラムおよび情報処理システムは、複数のＩｏＴデバイスをクラウドサービス上でエミュレートし、ＩｏＴサービスの開発および評価を支援する。特に、クラウドサービス上で構築されるＩｏＴサービスのテスト環境を制御する情報処理装置を、テストサーバと呼ぶ。

図１のブロック図は、本実施形態によるテストサーバの構成を概略的に示している。図１のテストサーバ１（情報処理装置）は、通信回路３と、記憶部１０と、処理回路２０とを備えている。処理回路２０、記憶部１０、通信回路３は、バス２を介して互いに電気的に接続されている。処理回路２０は、演算処理を実行し、テストサーバの各構成要素を制御する。処理回路２０は、例えば、命令またはプログラムを実行することが可能なＣＰＵ（中央処理装置）である。なお、処理回路２０は、ＧＰＵ（ＧｒａｐｈｉｃａｌＰｒｏｃｅｓｓｉｎｇＵｎｉｔ）、ＡＳＩＣ（ＡｐｐｌｉｃａｔｉｏｎＳｐｅｃｉｆｉｃＩｎｔｅｇｒａｔｅｄＣｉｒｃｕｉｔ）、ＦＰＧＡ（ＦｉｅｌｄＰｒｏｇｒａｍｍａｂｌｅＧａｔｅＡｒｒａｙ）などのハードウェア回路を含んでいてもよい。処理回路２０は、内部の構成要素として、リソース計算部２１と、第１制御部２２と、第２制御部２３とを含む。これらの構成要素の詳細については、後述する。

記憶部１０は、プログラムおよび各種のデータを保存可能な記憶領域を提供する。記憶部１０は、例えば、ＤＲＡＭなどの揮発性メモリ、ＮＡＮＤフラッシュメモリなどの不揮発性メモリ、ハードディスクまたはＳＳＤ（ＳｏｌｉｄＳｔａｔｅＤｒｉｖｅ）などのストレージ、またはこれらの組み合わせのいずれであってもよい。記憶部１０には、試験データ１１および通信モデルデータ１２が保存されている。なお、記憶部１０には、ＯＳ（ＯｐｅｒａｔｉｎｇＳｙｓｔｅｍ）ならびに、リソース計算部２１、第２制御部２３、第１制御部２２のそれぞれの機能を実現するプログラムが保存されていてもよい。この場合、処理回路２０上でプログラムを実行することによって、テストサーバ１は、各構成要素の機能を提供することができる。

テストサーバ１は、通信回路３を介して、ネットワーク４に接続されている。通信回路３は、例えば、ＴＣＰ／ＩＰ、ＵＤＰなどのプロトコルによる通信を行うＮＩＣ（ＮｅｔｗｏｒｋＩｎｔｅｒｆａｃｅＣａｒｄ）である。テストサーバ１は、通信回路３を介して、ネットワーク４に接続された他の装置とデータ通信を行うことができる。

ネットワーク４には、情報端末５が接続されている。情報端末５は、例えば、ノートパソコン、デスクトップコンピュータ、スマートフォン、タブレットなどのＣＰＵと、データ通信回路とを備えた装置である。ユーザは、情報端末５を介して、テストサーバ１を操作し、テストサーバの提供する各種の機能を利用することができる。例えば、ユーザは、テストサーバ１が提供するＷｅｂインタフェースまたは、ＡＰＩ（ＡｐｐｌｉｃａｔｉｏｎＰｒｏｇｒａｍｍｉｎｇＩｎｔｅｒｆａｃｅ）を使ってテストサーバ１を操作することができる。

なお、テストサーバ１は、物理計算機に限らない。例えば、テストサーバ１は、仮想計算機（ＶＭ：ＶｉｒｔｕａｌＭａｃｈｉｎｅ）またはコンテナであってもよい。テストサーバ１が仮想計算機である場合、テストサーバ１の処理回路２０内のそれぞれの構成要素の機能は、仮想ＣＰＵによって実現される。また、記憶部１０として、仮想ストレージが使われ、通信回路３として、仮想ＮＩＣが使われる。仮想ＮＩＣは、仮想ネットワークを介して、（仮想計算機またはコンテナなど仮想的なインスタンスを含む）その他の計算機とデータ通信を行う。仮想計算機またはコンテナが使われていても、テストサーバ１は、物理計算機と同等の機能を提供することができる。仮想計算機またはコンテナを実行するための計算機プラットフォームの例については、下記で説明する。

図２のブロック図は、計算機プラットフォームの例を概略的に示している。図２では、複数の物理計算機２０１と、複数の物理ストレージ２０２と、物理ネットワーク２０３とを含む情報処理システム上に計算機プラットフォーム１００が構築されている。なお、複数の物理計算機２０１は、物理ネットワーク２０３を介して互いに接続されているものとする。また、複数の物理ストレージ２０２は、例えば、ＮＡＳ（ＮｅｔｗｏｒｋＡｒｅａＳｔｏｒａｇｅ）または、ＳＡＮ（ＳｔｏｒａｇｅＡｒｅａＮｅｔｗｏｒｋ）として使用可能なストレージ装置である。それぞれの物理計算機２０１は、物理ストレージ２０２上の記憶領域にアクセスすることができる。

なお、図２に示した情報処理システムの構成は、一例にしかすぎない。例えば、最小構成として、１台の物理計算機２０１を使って構築された計算機プラットフォーム１００がありうる。すなわち、計算機プラットフォーム１００に含まれる物理計算機２０１の台数については、問わない。また、物理計算機２０１の内部ストレージを使う場合、物理ストレージ２０２を省略することができる。図２には、ひとつの物理ネットワーク２０３が示されているが、ストレージネットワークなど、用途別に複数の物理ネットワークが構築されていてもよい。

計算機プラットフォーム１００は、ユーザに仮想計算機（ＶＭ：ＶｉｒｔｕａｌＭａｃｈｉｎｅ）、コンテナ、仮想的なネットワーク、仮想的なストレージなどを含む仮想的な計算資源を提供する。計算機プラットフォーム１００は、例えば、商用またはオープンソースのハイパバイザを複数の物理計算機２０１にインストールすることによって構築することができる。ハイパバイザの種類としては、ホスト型のパイパバイザ、ベアメタル型のハイパバイザなどがあるが、どのような種類のハイパバイザを使ってもよい。また、物理計算機２０１または仮想計算機にコンテナ型仮想化ソフトウェアをインストールすれば、計算機プラットフォーム１００でコンテナを提供することが可能となる。

また、ハイパバイザに加えて、クラウドコンピューティングソフトウェアをインストールすることによって、ＩａａＳ（ＩｎｆｒａｓｔｒｕｃｔｕｒｅａｓａＳｅｒｖｉｃｅ）型または、ＰａａＳ（ＰｌａｔｆｏｒｍａｓａＳｅｒｖｉｃｅ）型のサービスを提供してもよい。商用またはオープンソースなど各種のクラウドコンピューティングソフトウェアを使うことが可能である。計算機プラットフォーム１００は、パブリッククラウドとして構築／運用されているものであってもよい。また、計算機プラットフォーム１００は、プライベートクラウドとして構築／運用されているものであってもよい。このように、計算機プラットフォーム１００を構築／運用する主体については、問わない。

計算機プラットフォーム１００は、管理サーバ１０１と、仮想計算機１０２と、仮想ネットワーク１０４と、仮想計算機１０５とを含む。管理サーバ１０１は、ユーザが計算機プラットフォーム１００を利用するためのインタフェースを提供する。管理サーバ１０１は、例えば、いずれかの物理計算機２０１で実行されるサーバアプリケーションである。管理サーバ１０１は、例えば、複数の物理計算機２０１で動作するハイパバイザの管理を行う管理サーバである。また、クラウドコンピューティングソフトウェアによる計算機プラットフォーム１００の構築が行われている場合、管理サーバ１０１は、ユーザがクラウドサービスの利用時にアクセスするウェブサイトまたはＡＰＩを提供するサーバであってもよい。管理サーバ１０１は、各種のＡＰＩ、ＣＬＩ、ＨＴＭＬ、ＫＶＭ（ＫｅｙＢｏａｒｄＶｉｄｅｏＭｏｕｓｅ）などのインタフェースを介して、ユーザが計算資源に係る操作または仮想計算機上で動作するＯＳおよびアプリケーションの操作を行う機能を提供してもよい。なお、提供されるインタフェースの種類に応じて、複数の管理サーバ１０１が設けられていてもよい。また、管理サーバの少なくとも一部の機能が仮想計算機上で動作していてもよい。

計算資源に係る操作の例としては、仮想計算機の作成、仮想計算機の起動、仮想計算機のシャットダウン、仮想計算機の構成変更、仮想計算機のスナップショットの作成、スナップショットの複製、特定のスナップショットへの復元、仮想計算機の物理計算機間の移動（マイグレーション）、仮想ネットワークの作成、仮想ネットワークの構成変更、仮想ストレージの作成、仮想ストレージの構成変更、クラウドサービスの利用プランの指定などが挙げられる。例えば、ＣＰＵ数、メモリサイズ、ストレージサイズ、仮想ＮＩＣなどの計算資源を指定した上で、仮想計算機の作成を行うことが可能である。

なお、ユーザは、管理サーバ１０１を介さずに、直接、仮想計算機１０２および１０５にアクセスしてもよい。この場合、ユーザは、一般の物理計算機にアクセスする場合と同様、ＳＳＨ（ＳｅｃｕｒｅＳｈｅｌｌ）などのプロトコル、ＫＶＭ，ウェブインタフェースによって仮想計算機１０２および１０５で動作するＯＳおよびアプリケーションを操作することができる。

仮想計算機１０２では、ＩｏＴデバイスのデータ通信時の挙動をエミュレートするエミュレータ１０３が動作する。図２に示したように、ひとつの仮想計算機１０２上で複数のエミュレータ１０３を動作させてもよい。エミュレータ１０３は、ＯＳ上で動作するアプリケーションとして実装されていてもよいし、ＯＳ自体を仮想化したコンテナ内のアプリケーションであってもよい。例えば、仮想計算機１０２のＯＳに、コンテナ型仮想化ソフトウェアをインストールすると、仮想計算機１０２上に、複数のコンテナを動作させることができる。図２のように、複数の仮想計算機１０２を作成し、計算機プラットフォーム１００上で動作させることが可能である。仮想計算機１０２の数を増やすと、より多くの台数のＩｏＴデバイスをエミュレートすることができるようになる。

仮想計算機１０５上では、サービスアプリ１０６が動作する。サービスアプリ１０６は、ＳＵＴ（ＳｅｒｖｉｃｅＵｎｄｅｒＴｅｓｔ）に相当するＩｏＴサービスを提供するアプリケーションである。サービスアプリ１０６がＯＳ自体を仮想化したコンテナ内のアプリケーションであってもよい点は、上述のエミュレータ１０３と同様である。

サービスアプリ１０６は、単一のアプリケーションではなく、複数のアプリケーションのグループであってもよい。例えば、ＩｏＴサービスの機能ごとに別個のアプリケーションが用意されていてもよい。また、実運用時のスケールアウトまたは分散されたシステム構成を想定し、同一の機能を実行するアプリケーションを複数個用意してもよい。図２に示したように、同一の仮想計算機１０５上で、複数のサービスアプリ１０６が動作していてもよい。また、複数の仮想計算機１０５を用意し、それぞれの仮想計算機１０５上でサービスアプリ１０６を動作させてもよい。

図２では、サービスアプリ１０６が仮想計算機上で動作しているが、サービスアプリ１０６は、必ず仮想計算機上で動作するものでなくてもよい。例えば、実運用時にサービスアプリ１０６が物理計算機上で動作することが想定される場合には、サービスアプリ１０６を直接いずれかの物理計算機２０１上で動作させることも可能である。

図２では、ハイパバイザ上に複数の仮想計算機（ＶＭ）が実行される計算機プラットフォームを例示した。ただし、計算機プラットフォームでは、代わりに、複数の物理計算機２０１にコンテナ型仮想化ソフトウェアをインストールし、複数のコンテナをユーザに提供してもよい。また、計算機プラットフォームは、ＶＭとコンテナの両方をユーザに提供してもよい。この場合、ＶＭ上で動作するエミュレータ１０３と、コンテナ上で動作するエミュレータ１０３が混在していてもよい。

複数の仮想計算機１０２および仮想計算機１０５は、仮想ネットワーク１０４を介して、互いにデータ通信を行うことができる。したがって、エミュレータ１０３は、仮想ネットワーク１０４を介して、サービスアプリ１０６とデータ通信を行う。また、管理サーバ１０１も、仮想ネットワーク１０４を介して、それぞれの仮想計算機の制御を行ってもよい。仮想ネットワーク１０４は、仮想ブリッジを備えていてもよい。仮想ブリッジは、仮想ネットワーク１０４とネットワーク４とをまたがるデータ通信を実現するものであってもよい。また、仮想ブリッジは、仮想ネットワーク１０４と物理ネットワーク２０３とをまたがる通信を実現するものであってもよい。

なお、仮想ネットワーク１０４は、さらにデータ通信の帯域、伝送遅延、伝送揺らぎ、伝送エラー率の少なくともいずれかを含む通信品質を調整する機能を備えていてもよい。この場合、ユーザは、管理サーバ１０１を介して、仮想ネットワーク１０４における通信品質を制御することができる。なお、通信品質の調整をエミュレータ１０３側（通信モデル側）で行えるようにしてもよい。

次に、図１および図２を参照しながら、テストサーバ１の詳細について説明する。

通信モデルデータ１２は、エミュレータ１０３がエミュレートするＩｏＴデバイスのデータ通信時の挙動（通信モデル）を定義するデータと、当該ＩｏＴデバイスのエミュレーションに必要な計算資源に関する情報とを含む。図３のテーブルＴ１は、通信モデルデータ１２の例を示している。通信モデルデータ１２は、例えば、センサの計測値に相当するデータサンプルのサイズ、データサンプルがとる値、データサンプルの計算式、データサンプルがサービスアプリ１０６に送信されるタイミング、またはこれらの組み合わせを含むことができる。

通信モデルは、数理モデルに基づいて定義されていてもよい。例えば、アーラン分布に基づいて作成される待ち行列モデルを使い、通信モデルを定義することができる。通信モデルは、エミュレータ１０３に、動的にデータサンプルを生成させたり、データサンプルの送信タイミングを決定させたりするものであってもよい。また、エミュレータ１０３が送信するデータは、あらかじめ定義されたものであってもよい。例えば、通信モデルは、ＩｏＴデバイスの実測データまたは実測データを加工したデータを含んでいてもよい。

また、通信モデルデータ１２は、異常系通信モデルを含んでいてもよい。異常系通信モデルは、例えば、ＩｏＴデバイスでの異常発生をエミュレートする。また、異常系通信モデルは、ＩｏＴデバイスとＩｏＴサービスを提供するサーバ間の通信網における異常発生をエミュレートするものであってもよい。エミュレータ１０３は、ＩｏＴデバイスおよびＩｏＴサービスが正常に動作しているときにおける、正常系通信モデルと、異常系通信モデルを切り替えながら使用してもよい。例えば、エミュレータ１０３は、ランダムな確率で異常系通信モデルに基づくデータ通信を行うことができる。また、通信モデルデータ１２は、ＩｏＴサービスのリアルタイム性能をテストするための通信モデルを含んでいてもよい。

試験データ１１は、計算機プラットフォーム１００によって実行される試験シナリオを定義するデータである。試験データ１１は、例えば、サービスアプリ１０６に対して実行されるテスト内容およびテストの実行手順を含む。試験シナリオは、正常系のテストだけでなく、異常系のテストや、サービスアプリ１０６のリアルタイム性能を確認するためのテストを含んでいてもよい。図４のテーブルＴ２は、試験データ１１の例を示している。試験データ１１は、試験シナリオにおいて使用される少なくともひとつの通信モデルを指定してもよい。例えば、試験データ１１内に、いずれかの通信モデルデータ１２に相当するファイル名または、ポインタが含まれていてもよい。

第１制御部２２は、管理サーバ１０１にアクセスし、テストで使用する計算資源を制御する。第２制御部２３は、複数のエミュレータ１０３を制御する。リソース計算部２１は、テストに必要な計算資源を計算し、エミュレータ１０３が実行される条件を決定する。なお、計算資源は、例えば、ＣＰＵ数、メモリサイズ、ストレージサイズ、仮想ＮＩＣの設定などを含むものとする。なお、第２制御部２３、第１制御部２２およびリソース計算部２１によって実行される処理の詳細については、後述する。

例えば、本実施形態に係る情報処理装置（テストサーバ）は、リソース計算部と、第１制御部と、第２制御部とを備えている。リソース計算部は、試験シナリオで規定されている通信モデルに基づきエミュレータにデータを送信させ、サービスにデータを受信させるテストを計算機プラットフォーム上で実行するために必要となる計算資源量を計算し、計算機プラットフォーム内の計算機におけるエミュレータの割り当てを決定する。第１制御部は、計算機プラットフォームにアクセスし、当該計算資源量を確保する。第２制御部は、計算機に割り当てられたエミュレータの設定を行う。

また、情報処理装置（テストサーバ）で実行されるプログラムは、試験シナリオで規定されている通信モデルに基づきエミュレータにデータを送信させ、サービスにデータを受信させるテストを計算機プラットフォーム上で実行するために必要となる計算資源量を計算するステップと、計算機プラットフォーム内の計算機におけるエミュレータの割り当てを決定するステップと、計算機プラットフォームにアクセスし、計算資源量を確保するステップと、計算機に割り当てられたエミュレータの設定を行うステップとを含んでいてもよい。

また、本実施形態による情報処理システムは、第１計算機と、第２計算機と、管理サーバと、テストサーバとを備えていてもよい。第１計算機は、試験シナリオで規定されている通信モデルに基づきデータを送信するエミュレータを実行する。第２計算機は、データを受信するサービスを実行する。管理サーバは、第１計算機への計算資源の割り当てを制御する。テストサーバは、試験シナリオに基づくテストを実行させるために必要となる計算資源量を計算し、第１計算機におけるエミュレータの割り当てを決定し、管理サーバに計算資源量の計算資源を確保させ、エミュレータの設定を行う。図２の仮想計算機１０２は、第１計算機の一例である。また、図２の仮想計算機１０５は、第２計算機の一例である。

ここで、計算資源量は、ＣＰＵ数、ＣＰＵ時間、プロセス数、メモリサイズ、ストレージサイズ、ネットワークの設定、ネットワーク帯域の少なくともいずれかを含んでいてもよい。また、少なくともいずれかの前記通信モデルは、待ち行列モデルに基づくものであってもよい。また、通信モデルは、エミュレータが送信するデータの通信品質を規定するものであってもよい。この場合、通信品質は、データ通信の帯域、伝送遅延、伝送揺らぎ、伝送エラー率の少なくともいずれかを含むことができる。

エミュレータは、例えば、ＩｏＴデバイスのデータ通信時における挙動をエミュレートする。サービスは、例えば、ＩｏＴデバイスに関連した処理を実行するＩｏＴサービスである。例えば、プログラムをＣＰＵ上で実行することによって、エミュレータおよびサービスの機能を実現することができる。なお、計算機プラットフォーム内の少なくともいずれかの計算機は、仮想計算機またはコンテナであってもよい。

また、計算機プラットフォームは、仮想計算機またはコンテナによるデータ通信を実現する仮想ネットワークを含んでいてもよい。この場合、第１制御部は、通信モデルに基づき、仮想ネットワークのデータ通信の帯域、伝送遅延、伝送揺らぎ、伝送エラー率の少なくともいずれかを制御してもよい。

図５のフローチャートは、テストサーバ１によるテスト開始時までの処理の例を示している。以下では、図５のフローチャートを参照しながら、処理を説明する。

はじめに、第１制御部２２は、管理サーバ１０１より計算資源に係る情報を取得する（ステップＳ１０１）。例えば、第１制御部２２は、ステップＳ１０１でサービスアプリ１０６が実行される仮想計算機１０５に割り当てられた計算資源、エミュレータ１０３が実行される仮想計算機１０２に割り当てられた計算資源、仮想ネットワーク１０４の構成などの情報を取得することができる。

次に、第２制御部２３は、サービスアプリ１０６の情報を取得する（ステップＳ１０２）。例えば、第２制御部２３は、テスト対象であるサービスアプリ１０６を特定する情報、サービスアプリ１０６で利用可能となっているＡＰＩの種類、ＡＰＩの仕様、ＡＰＩを使うために必要なネットワーク設定などを取得することができる。ネットワーク設定の例としては、使用する通信プロトコル、使用するポート番号などが挙げられる。第２制御部２３がサービスアプリ１０６の情報を取得する方法については、問わない。例えば、サービスアプリ１０６が動作する仮想計算機１０５よりファイルをダウンロードしてもよいし、サービスアプリ１０６が提供するＡＰＩを介して情報を取得してもよい。

そして、ユーザは、実行する試験シナリオを選択する（ステップＳ１０３）。ユーザは、試験データ１１に含まれている複数の試験シナリオより実行する試験シナリオを選択することができる。例えば、ユーザは、情報端末５を介して、テストサーバ１にアクセスし、実行する試験シナリオを指定してもよい。また、ステップＳ１０３で、テストサーバ１が自動的に実行する試験シナリオを決定してもよい。例えば、複数のテストが所定の順序で実行される場合、ステップＳ１０３では、自動的に実行される試験シナリオが決定される。試験シナリオは、例えば、テスト中にサービスアプリ１０６とデータ通信を行うエミュレータ１０３の情報や、使用される通信モデルデータ１２などの情報を含んでいる。試験シナリオは、例えば、テーブルＴ２（図４）のシナリオＩＤおよびテーブルＴ１（図３）のモデルＩＤの組み合わせによって特定される。

次に、リソース計算部２１は、選択された試験シナリオの実行に必要な計算機プラットフォーム１００の計算資源量を計算し、仮想計算機１０２におけるエミュレータ１０３の割り当てを決定する（ステップＳ１０４）。計算資源量の例としては、エミュレータ１０３を実行する仮想計算機１０２の数、仮想計算機１０２に割り当てられるＣＰＵ数、メモリサイズまたはストレージサイズ、仮想計算機１０２と仮想計算機１０５との間のデータ通信を実現する仮想ネットワーク１０４の構成などが挙げられる。ここでは、エミュレータ１０３が、仮想計算機１０２上のコンテナである場合を例にステップＳ１０４の処理を説明するが、エミュレータ１０３は、仮想計算機１０２上のアプリケーションなど、異なる形で実行されていてもよい。

リソース計算部２１がステップＳ１０４で決定するエミュレータ１０３の割り当ての例としては、それぞれの仮想計算機１０２で実行されるエミュレータ１０３の数、それぞれの仮想計算機１０２で実行されるエミュレータ１０３の組み合わせ、仮想計算機１０２内の計算リソースの使用量などが挙げられる。

また、リソース計算部２１は、ステップＳ１０４であわせてエミュレータ１０３で使用するネットワーク設定を決定してもよい。ネットワーク設定は、例えば、サービスアプリ１０６とのデータ通信時における通信品質、エミュレータ１０３が送信するデータのサイズ、エミュレータ１０３が送信するデータの値およびエミュレータ１０３がデータを送信するタイミングを含んでいてもよい。通信品質は、データ通信の帯域、伝送遅延、伝送揺らぎ、伝送エラー率の少なくともいずれかを含むことができる。例えば、リソース計算部２１は、通信モデルのオプション、パラメータなどを調整してもよい。なお、ステップＳ１０３において、使用される通信モデルが特定されている場合には、ステップＳ１０４で当該処理をスキップしてもよい。

ステップＳ１０４が実行された後、第１制御部２２は、計算機プラットフォーム１００における計算資源の設定を行う（ステップＳ１０５）。例えば、第１制御部２２は、管理サーバ１０１にアクセスし、エミュレータ１０３が実行される仮想計算機１０２に割り当てられる計算資源、サービスアプリ１０６が実行される仮想計算機１０５に割り当てられる計算資源、仮想ネットワーク１０４の設定の少なくともいずれかを変更することができる。なお、計算資源の割り当ての変更が不要である場合、ステップＳ１０５の少なくとも一部の処理をスキップしてもよい。例えば、テストモデルに対応付けられた通信モデルに調整を行わず、デフォルトの設定の通信モデルを使ってもよい。

次に、第２制御部２３は、ステップＳ１０４の結果に基づきエミュレータ１０３の設定を行う（ステップＳ１０６）。エミュレータ１０３がコンテナ内のアプリケーションである場合、第２制御部２３は、ひとつの仮想計算機１０２上で実行されるコンテナの数と、コンテナが使うことができる仮想計算機１０２内の計算資源を設定することができる。第２制御部２３は、例えば、コンテナが生成することができるファイルサイズの上限、コンテナが生成することができるプロセス数の上限、コンテナが使用することができるメモリサイズの上限、コンテナが使用することができるＣＰＵ時間の上限、コンテナが使用することができるＣＰＵ数の上限などを設定することができる。また、第２制御部２３は、ステップＳ１０６でエミュレータ１０３が使用する通信モデルの設定を行ってもよい。例えば、第２制御部２３は、仮想計算機１０２のコンテナからアクセス可能なストレージ領域に、通信モデルデータ１２を配置する。そして、コンテナ内のエミュレータ１０３は、通信モデルデータ１２を取得することができる。

そして、第２制御部２３は、エミュレータ１０３を実行し、サービスアプリ１０６のテストを開始する（ステップＳ１０７）。試験シナリオによって、テストの実行期間や使われる仮想計算機の数は、大きく異なる。図５のフローチャートに係る説明は、以上である。

ユーザは、ステップＳ１０４で求められる、試験シナリオの実行のために割り当てられる計算機プラットフォーム１００の計算資源およびエミュレータ１０３の実行条件に基づいて、テストを実行するために必要なクラウドサービスの利用プランを決めることができる。一般に、エミュレートするシステムの規模（ＩｏＴデバイスの台数）が大きくなったり、要求されるテストの精度が高くなったりすると、必要な計算資源量が増大する。ユーザは、クラウドサービスにおいて、より高額な利用プランを選択すれば、利用することができる計算資源量を増やすことができる。ただし、ＩｏＴサービスがデータ通信を行うＩｏＴデバイスの台数が数万台～数百万台以上に増えることが予想される場合、計算資源を効率的に利用し、クラウドサービスの利用にかかるコストを最小限にすることが望ましい。

そこで、以下では、テストサーバを使って、クラウドサービスの利用にかかるコストを最小化させる構成を求める場合を例に、説明をする。以下で説明する例は、クラウドサービスの利用にかかるコストを目的関数とした最適化問題の解を求める処理に等価であるといえる。コストは、クラウドサービスを提供する事業者に対して支払う対価であってもよいし、クラウドサービスの構築および運用に要するコストであってもよい。

なお、テストサーバ１は、これとは異なる最適化問題を解いてもよい。例えば、所定の量の計算資源を利用し、並列的に複数の試験シナリオを実行する場合、全試験シナリオの実行に要する時間を最小化させる構成を求めることができる。この場合、目的関数は、全試験シナリオの実行に要する時間となる。また、所定の量の計算資源を利用した場合に、テスト内容の精度が最も高くなる構成を求めることも可能である。

エミュレータ１０３に割り当てる計算資源量を最適化することによって、クラウドサービスの利用コストを最小化させることができる。例えば、ユーザは、エミュレータ１０３がエミュレートする製品（ＩｏＴデバイス）のデータ通信機能、データ通信設定および当該製品のデータ通信時の挙動をエミュレートするのに必要な計算資源との関係を含む通信モデルを作成し、あらかじめエミュレータ１０３が必要とする計算資源量を求めることができる。

図６のフローチャートは、クラウドサービスの利用コストを最小化する設定を求める処理の例を示している。以下では、図６のフローチャートを参照しながら、処理を説明する。なお、図６のフローチャートは、図５のフローチャートにおけるステップＳ１０４の処理を具体化したものに相当している。

はじめに、リソース計算部２１は、記憶部１０内の試験データ１１を参照し、試験シナリオにおけるエミュレータ１０３の構成に関する情報を取得する（ステップＳ２０１）。試験シナリオにおけるエミュレータ１０３の構成に関する情報は、当該試験シナリオで使われるエミュレータ１０３の数Ｎｓｅを含んでいてもよい。

例えば、試験シナリオでＩｏＴデバイスＤ１、Ｄ２およびＤ３の挙動がエミュレートされるものとする。この場合、試験シナリオにおけるエミュレータ１０３の構成に関する情報は、例えば、ＩｏＴデバイスＤ１の正常系のデータ通信を模擬するエミュレータＥ１を１００個、ＩｏＴデバイスＤ２の正常系のデータ通信を模擬するエミュレータＥ２を１００個、ＩｏＴデバイスＤ３の正常系のデータ通信を模擬するエミュレータＥ３を１００個のような、計算機プラットフォーム１００内で割り当てられるべきエミュレータ１０３の情報を含むことができる。なお、リソース計算部２１は、さらに並列的に実行されるエミュレータ１０３に関する情報や、エミュレータ１０３の実行順序に関する情報を取得してもよい。

次に、リソース計算部２１は、記憶部１０内の試験データ１１および通信モデルデータ１２を参照し、試験シナリオで使用する通信モデルの情報を取得する（ステップＳ２０２）。図３のテーブルＴ１に示したように、通信モデルは、ひとつのエミュレータ１０３を実行するために必要な計算資源量（例えば、ＣＰＵ数、メモリサイズ、ストレージサイズ、ネットワーク帯域）の情報を含んでいてもよい。

そして、リソース計算部２１は、第１制御部２２に複数の利用プランの情報を取得させる（ステップＳ２０３）。利用プランの情報は、仮想計算機１０２に割り当てられる計算資源と当該仮想計算機１０２の利用コストに関する情報を含む。利用プランの情報は、例えば、「ＣＰＵ数：１、メモリサイズ：１ＧＢ、ＮＩＣの帯域：１ＧｐｂｓのＶＭを１時間利用すると、２セントがかかる」といった内容を含むことができる。なお、ここで示した利用プランの情報は、一例にしかすぎない。例えば、事業者によっては、計算機プラットフォーム１００の利用料を年額で請求する場合もある。また、ユーザがある期間において計算資源の使用量を一定の範囲内に抑制すると、利用料を割り引く事業者もある。したがって、利用プランの情報は、これより複雑な条件を含んだものであってもよい。

ここでは、第１制御部２２が管理サーバ１０１より利用プランの情報を取得している場合を例に説明をしている。ただし、これとは異なる方法によって、利用プランの情報を取得してもよい。例えば、リソース計算部２１は、クラウド事業者が提供するウェブサーバから、利用プランの見積もり情報などをダウンロードしてもよい。

次に、リソース計算部２１は、それぞれの利用プランについて、ひとつの仮想計算機１０２で実行可能なエミュレータ１０３の数を計算する（ステップＳ２０４）。図７のテーブルＴ３は、ステップＳ２０４における計算結果の例を示している。例えば、それぞれの利用プランで使うことができる計算資源量ＣＲｐを、ステップＳ２０２で取得した、ひとつのエミュレータ１０３を実行するために必要な計算資源量ＣＲｅで除算することにより、それぞれの利用プランで実行することが可能なエミュレータ１０３の数を求めることができる。なお、時刻または条件によって、計算資源量ＣＲｅが増減する場合には、計算資源量ＣＲｅの最大値を使って上述の計算が行えばよい。

例えば、テーブルＴ３の利用プランＣＰ１において、図３のテーブルＴ１のモデルＩＤ２００１の通信モデルを使うエミュレータ１０３が実行される場合を想定する。利用プランＣＰ１では、仮想計算機１０２のメモリサイズが、実行可能なエミュレータ１０３の数の上限を定める。利用プランＣＰ１では、ひとつの仮想計算機１０２で０．５ＧＢ＝５１２ＭＢのメモリを使うことができる。一方、モデルＩＤ２００１の通信モデルを使うエミュレータ１０３は、ひとつ当たり５０ＭＢのメモリを必要としている。したがって、５１２ＭＢ／５０ＭＢを計算すると、利用プランＣＰ１で実行することができるエミュレータ１０３の数は、１０個になる。

また、テーブルＴ３の利用プランＣＰ５において、図３のテーブルＴ１のモデルＩＤ２００１の通信モデルを使うエミュレータ１０３が実行される場合を想定する。利用プランＣＰ５では、仮想計算機１０２で使用することができるネットワーク帯域が、実行可能なエミュレータ１０３の数の上限を定める。利用プランＣＰ５では、ひとつの仮想計算機１０２で１Ｇｂｐｓ＝１０２４Ｍｂｐｓのネットワーク帯域を使うことができる。一方、モデルＩＤ２００１の通信モデルを使うエミュレータ１０３は、ひとつ当たり１０Ｍｂｐｓのネットワーク帯域を必要としている。したがって、１０２４Ｍｂｐｓ／１０ＭＭｂｐｓを計算すると、クラウドプランＣＰ５で実行することができるエミュレータ１０３の数は、１００個になる。

モデルＩＤ２００２またはモデルＩＤ２００３の通信モデルでは、モデルＩＤ２００１の通信モデルと、必要な計算資源量が異なっている。このため、エミュレータ１０３が使う通信モデルによって、異なる結果が得られる。

ここでは、単純化のために、ひとつの仮想計算機１０２で実行される複数のエミュレータ１０３が同じ通信モデルを使っていると想定し、説明を行った。ただし、同一の仮想計算機１０２上で、異なる通信モデルを使うエミュレータ１０３を実行してもよい。この場合、それぞれの種類の通信モデルを実行するエミュレータ１０３が必要とする計算資源量と、複数のエミュレータ１０３において実行される通信モデルの種類の割合に基づき、それぞれの利用プランの仮想計算機で実行することが可能なエミュレータの数を計算することができる。

そして、リソース計算部２１は、試験シナリオを実行した場合におけるそれぞれの利用プランのコストを計算する（ステップＳ２０５）。例えば、試験シナリオで使われるエミュレータ１０３の数をＮｓｅ、利用プランｉで実行可能なエミュレータ１０３の数をＮｐ_ｉとする。下記の式（１）は、利用プランｉを選択した場合に、試験シナリオの実行に必要な仮想計算機１０２の数Ｍｖ_ｉを求める式の例である。

ここで、ｃｅｉｌｉｎｇ（ｘ）は、ｘ以上の最小の整数を与える関数である。例えば、ｘ＝２．５であるとき、ｃｅｉｌｉｎｇ（ｘ）＝３となる。

利用プランにおいて、時間課金が行われる場合を例に、コストの計算方法を説明する。利用プランｉの時間当たりの単価をｃｔ_ｉ、試験シナリオの実行時間をｔｓとすると、試験シナリオを実行した場合における利用プランｉのコストＣ_ｉは、例えば、下記の式（２）によって求めることが可能である。

ステップＳ２０５で、複数の利用プランについて、試験シナリオを実行した場合におけるコストが計算されたら、リソース計算部２１は、コストが最小の利用プランを選択する（ステップＳ２０６）。次に、リソース計算部２１は、各仮想計算機１０２に割り当てるエミュレータ１０３の組み合わせを決定する（ステップＳ２０７）。例えば、ステップＳ２０７では、各仮想計算機１０２に割り付けられる、上述のエミュレータＥ１～Ｅ３の個数を決めることができる。また、試験シナリオで使われるエミュレータ１０３の数Ｎｓｅを試験シナリオの実行に必要な仮想計算機１０２の数Ｍｖｉで除算し、各仮想計算機１０２が実行するエミュレータ１０３の数を決めてもよい。また、ステップＳ２０７で、リソース計算部２１は、通信モデルデータ１２を参照し、それぞれのエミュレータに相当するＩｏＴデバイスのデータ通信機能または通信設定に関する情報を取得してもよい。

図６のステップＳ２０１～Ｓ２０７の処理が実行されると、試験シナリオの実行に使われる仮想計算機１０２が特定され、仮想計算機１０２に割り当てられるエミュレータの組み合わせおよび個数が決定される。ステップＳ２０１～Ｓ２０７の処理で決定した内容に基づいて、計算機プラットフォーム１００における計算資源の設定（ステップＳ１０５）および各仮想計算機１０２におけるエミュレータの設定（ステップＳ１０６）が行われる。

このように、試験シナリオは、テストの実行時に動作するエミュレータ１０３の数と、テストの実行時に動作するエミュレータ１０３で使用される通信モデルの種類とを含んでいてもよい。通信モデルの種類は、例えば、テーブルＴ１（図３）のモデルＩＤなどの識別子によって特定される。リソース計算部２１は、計算機プラットフォーム１００の利用プランごとに規定されている計算機の計算資源量およびいずれかの種類の通信モデルをエミュレータ１０３で使った場合に必要となる計算資源量に基づき、計算機で実行することができるエミュレータ１０３の数を計算してもよい。

リソース計算部２１は、テストの実行時に動作するエミュレータ１０３の数および計算機で実行することができるエミュレータ１０３の数に基づき、テストを実行するために必要な計算機の数を計算してもよい。また、リソース計算部２１は、テストを実行するために必要な計算機の数に基づき、コストが最小となる利用プランを選択してもよい。この場合、第１制御部は２２、計算機プラットフォーム１００にアクセスし、選択された利用プランの計算資源量を確保することができる。

本実施形態に係るテストサーバ、プログラムおよび情報処理システムは、該当のＩｏＴデバイスが入手可能となる前から、クラウドサービスでＩｏＴサービスの開発および検証を進めることを可能にする。このため、充分な数のＩｏＴデバイスが用意できていない場合に、高価なＩｏＴデバイスを購入したり、製造したりする必要がなくなる。したがって、ＩｏＴデバイスに関連した処理を実行するＩｏＴサービスの開発および検証に要するコストを抑えることができる。また、通信モデルの選択および設定によって、正常系でなく異常系の評価、ＩｏＴサービスのリアルタイム性能の評価を行うことも容易である。

特に、仮想計算機上でＩｏＴデバイスをエミュレートする場合、仮想計算機のスナップショット機能、スナップショットの複製機能、スナップショットの復元機能、仮想計算機のマイグレーション機能などを活用し、短期間で容易にテスト環境の構築およびテストの実行を行うことができる。コンテナについても、仮想計算機と同様に、スナップショットおよびマイグレーション機能を利用することが可能である。また、スクリプトを使って、上述の各処理を自動的に実行するテストサーバおよび情報処理システムを構築することも容易である。このため、本実施形態に係るテストサーバ、プログラムおよび情報処理システムを使うことにより、ＩｏＴサービスの開発および検証を効率的に進めることができるようになる。

図８のブロック図は、変形例によるテストサーバの構成を概略的に示している。図８のネットワーク４には、図２と同様に、計算機プラットフォーム１００（図示せず）が接続されているものとする。図８のテストサーバ１Ａは、図１のテストサーバ１の構成要素に加えて、開発連携部２４を備えている。また、ネットワーク４には、開発サーバ６が接続されている。開発サーバ６は、ＳＵＴに相当するＩｏＴサービスに係るソフトウェア（サービスアプリ１０６）の開発およびリリースを行うために使われているサーバである。開発サーバ６は、最新のソースコードをビルドした後、仮想計算機１０５上のサービスアプリ１０６を更新する機能を備えていてもよい。例えば、開発サーバ６は、管理サーバ１０１にアクセスし、仮想計算機１０５のイメージを更新してもよい。また、開発サーバ６は、対象の仮想計算機１０５に直接アクセスし、サービスアプリ１０６のプログラムを最新版のビルドに置き換えてもよい。

開発連携部２４は、ネットワーク４を介して開発サーバ６にアクセスし、開発サーバ６よりサービス設定情報を取得する。サービス設定情報は、例えば、サービスアプリ１０６（ＩｏＴサービス）で利用することができるＡＰＩの情報、サービスアプリ１０６のＡＰＩを利用するためのネットワーク設定の情報を含む。また、開発連携部２４は、開発サーバ６からテストの開始要求を受け付ける。開発連携部２４は、テストの開始要求を受理したら、第２制御部２３、第１制御部２２およびリソース計算部２１は、計算機プラットフォーム１００におけるサービスアプリ１０６のテストの準備を開始する。なお、開発サーバ６が送信するテストの開始要求は、テスト対象とするサービスアプリ１０６を特定したり、特定の試験シナリオを指定したりするものであってもよい。

開発連携部２４は、処理回路２０の内部の構成要素である。例えば、処理回路２０は、記憶部１０に保存されたプログラムを実行することによって、ユーザに開発連携部２４の機能を提供することができる。

図９のフローチャートは、テストサーバ１Ａによって実行される処理の例を示している。以下では、図９のフローチャートを参照しながら、処理を説明する。

はじめに、第１制御部２２は、管理サーバ１０１より計算機プラットフォーム１００における計算資源に係る情報を取得する（ステップＳ３０１）。例えば、第１制御部２２は、ステップＳ３０１でサービスアプリ１０６が実行される仮想計算機１０５およびエミュレータ１０３が実行される仮想計算機１０２に割り当てられた計算資源、仮想ネットワーク１０４の構成などの情報を取得することができる。

次に、開発連携部２４は、開発サーバ６よりテスト対象のサービスアプリ１０６および試験シナリオを特定する情報（サービス設定情報）を取得する（ステップＳ３０２）。ステップＳ３０２で、テストサーバ１Ａは、サービスアプリ１０６で利用することができるＡＰＩの情報、サービスアプリ１０６のＡＰＩを利用するためのネットワーク設定の情報を得ることができる。

開発連携部２４は、サービスアプリ１０６で利用することができるＡＰＩに基づき、選択するテーブルＴ２の試験シナリオＩＤを特定することができる。また、開発連携部２４は、サービスアプリ１０６で利用できる状態となっているＡＰＩに合わせ、既存の試験シナリオを修正する必要があるか否かを判定することができる。開発連携部２４は、既存の試験シナリオの修正が必要であると判定した場合、試験シナリオの修正または、新しい試験シナリオを作成することができる。

また、開発連携部２４は、サービスアプリ１０６のＡＰＩを利用するためのネットワーク設定の情報に応じて、エミュレータ１０３で使用する通信モデルのモデルＩＤを特定することができる。また、開発連携部２４は、通信モデルのパラメータ設定、オプション設定または、修正の必要性を判定することができる。すなわち、開発連携部２４は、ステップＳ３０２で取得したサービス設定情報に応じて、試験データ１１または通信モデルデータ１２を変更してもよい。

そして、リソース計算部２１は、テストの実行に必要な計算資源量を計算し、仮想計算機１０２におけるエミュレータ１０３の割り当てを決定する（ステップＳ３０３）。ステップＳ３０３では、図５のステップＳ１０４と同様の処理が実行される。また、ステップＳ３０３では、図６のフローチャート（ステップＳ２０１～ステップＳ２０７）の処理が実行されてもよい。

次に、第１制御部２２は、ステップＳ３０３の計算結果に基づき、計算機プラットフォーム１００における計算資源の設定を行う（ステップＳ３０４）。ステップＳ３０４では、図５のステップＳ１０５と同様の処理が実行される。そして、第２制御部２３は、ステップＳ３０３の結果に基づき、エミュレータ１０３の設定をする（ステップＳ３０５）。ステップＳ３０５では、図５のステップＳ１０６と同様の処理が実行される。次に、第２制御部２３は、エミュレータ１０３を実行し、サービスアプリ１０６のテストを開始する（ステップＳ３０６）。ステップＳ３０６では、図５のステップＳ１０７と同様の処理が実行される。

このように、本実施形態による情報処理装置（テストサーバ）は、サービスのソースコードのビルドが行われているサーバ（例えば、上述の開発サーバ６）よりテストの対象となるサービスおよび試験シナリオを指定する情報を取得する開発連携部２４をさらに備えていてもよい。

テストサーバ１Ａを使うことにより、ユーザは、上述のテストサーバ１を使った場合と同様のメリットを享受することができる。また、テストサーバ１Ａは、ＩｏＴサービス（サービスアプリ１０６）の開発環境を提供する開発サーバ６と連携しているため、ＩｏＴサービスの開発状況に応じたテスト内容の選択、テストの準備およびテストの実行を行うことができる。また、スクリプトなどを使い、最新のソースコードによるソフトウェアのビルドと、当該ビルドを使った試験シナリオ（テスト）の実行を自動化することができる。これにより、継続的インテグレーション、ＤｅｖＯｐｓ、アジャイルソフトウェア開発などの手法を使って、ＩｏＴサービスの開発を効率的に進めることが可能となる。

なお、本発明は上記実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記実施形態に開示されている複数の構成要素の適宜な組み合わせにより、種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。さらに、異なる実施形態にわたる構成要素を適宜組み合わせてもよい。

１テストサーバ
２バス
３通信回路
４ネットワーク
５情報端末
６開発サーバ
１０記憶部
１１試験データ
１２通信モデルデータ
２０処理回路
２１リソース計算部
２２第１制御部
２３第２制御部
２４開発連携部
１００計算機プラットフォーム
１０１管理サーバ
１０２、１０５仮想計算機
１０３エミュレータ
１０６サービスアプリ
２０１物理計算機
２０２物理ストレージ
２０３物理ネットワーク

Claims

試験シナリオで規定されている通信モデルに基づきエミュレータにデータを送信させ、サービスに前記データを受信させるテストを計算機プラットフォーム上で実行するために必要となる計算資源量を計算し、前記計算機プラットフォーム内の計算機における前記エミュレータの割り当てを決定するリソース計算部と、
前記計算機プラットフォームにアクセスし、前記計算資源量を確保する第１制御部と、
前記計算機に割り当てられた前記エミュレータの設定を行う第２制御部とを備える、
情報処理装置。
前記試験シナリオは、前記テストの実行時に動作する前記エミュレータの数と、前記テストの実行時に動作する前記エミュレータで使用される前記通信モデルの種類とを含む、
請求項１に記載の情報処理装置。
前記リソース計算部は、前記計算機プラットフォームの利用プランごとに規定されている前記計算機の計算資源量およびいずれかの前記種類の前記通信モデルを前記エミュレータで使った場合に必要となる計算資源量に基づき、前記計算機で実行することができる前記エミュレータの数を計算する、
請求項２に記載の情報処理装置。
前記リソース計算部は、前記テストの実行時に動作する前記エミュレータの数および前記計算機で実行することができる前記エミュレータの数に基づき、前記テストを実行するために必要な前記計算機の数を計算する、
請求項３に記載の情報処理装置。
前記リソース計算部は、前記テストを実行するために必要な前記計算機の数に基づき、コストが最小となる前記利用プランを選択し、
前記第１制御部は、選択された前記利用プランの前記計算資源量を確保する、
請求項４に記載の情報処理装置。
前記サービスのソースコードのビルドが行われているサーバより前記テストの対象となる前記サービスおよび前記試験シナリオを指定する情報を取得する開発連携部をさらに備える、
請求項１ないし５のいずれか一項に記載の情報処理装置。
前記通信モデルは、前記エミュレータが送信する前記データの通信品質を規定する、
請求項１ないし６のいずれか一項に記載の情報処理装置。
前記通信品質は、データ通信の帯域、伝送遅延、伝送揺らぎ、伝送エラー率の少なくともいずれかを含む、
請求項７に記載の情報処理装置。
前記計算機プラットフォーム内の少なくともいずれかの前記計算機は、仮想計算機またはコンテナである、
請求項１ないし８のいずれか一項に記載の情報処理装置。
前記エミュレータは、前記仮想計算機上のコンテナ内のアプリケーションである、
請求項９に記載の情報処理装置。
前記計算機プラットフォームは、前記仮想計算機または前記コンテナによるデータ通信を実現する仮想ネットワークを含む、
請求項９または１０に記載の情報処理装置。
前記第１制御部は、前記通信モデルに基づき、前記仮想ネットワークのデータ通信の帯域、伝送遅延、伝送揺らぎ、伝送エラー率の少なくともいずれかを制御する、
請求項１１に記載の情報処理装置。
前記計算資源量は、ＣＰＵ数、ＣＰＵ時間、プロセス数、メモリサイズ、ストレージサイズ、ネットワークの設定、ネットワーク帯域の少なくともいずれかを含む、
請求項１ないし１２のいずれか一項に記載の情報処理装置。
少なくともいずれかの前記通信モデルは、待ち行列モデルに基づいている、
請求項１ないし１３のいずれか一項に記載の情報処理装置。
前記エミュレータは、ＩｏＴデバイスのデータ通信時における挙動をエミュレートし、
前記サービスは、前記ＩｏＴデバイスに関連した処理を実行するＩｏＴサービスである、
請求項１ないし１４のいずれか一項に記載の情報処理装置。
試験シナリオで規定されている通信モデルに基づきエミュレータにデータを送信させ、サービスに前記データを受信させるテストを計算機プラットフォーム上で実行するために必要となる計算資源量を計算するステップと、
前記計算機プラットフォーム内の計算機における前記エミュレータの割り当てを決定するステップと、
前記計算機プラットフォームにアクセスし、前記計算資源量を確保するステップと、
前記計算機に割り当てられた前記エミュレータの設定を行うステップとを含む、
プログラム。
試験シナリオで規定されている通信モデルに基づきデータを送信するエミュレータを実行する第１計算機と、
前記データを受信するサービスを実行する第２計算機と、
前記第１計算機への計算資源の割り当てを制御する管理サーバと、
試験シナリオに基づくテストを実行させるために必要となる計算資源量を計算し、前記第１計算機における前記エミュレータの割り当てを決定し、前記管理サーバに前記計算資源量の計算資源を確保させ、前記エミュレータの設定を行うテストサーバとを備える、
情報処理システム。