JP6785810B2 - シミュレーター、シミュレーション装置、および、シミュレーション方法 - Google Patents

Description

本発明は、概して、設計されたシステムのシミュレーションに関する。

設計されたシステムのシミュレーションに関する技術として、特許文献１に開示の技術が知られている。特許文献１に開示のシミュレーターは、設計したシステムに、入力負荷と、システムを構成するハードウェア故障といった外乱とを与えた時の、システムの挙動を出力する。

特開2005-196601号公報

以下、「システム開発」は、システムの設計と構築を含む。すなわち、システム開発では、システムの設計、設計されたシステムの構築、および、構築されたシステムの検証といったプロセスを経て、システムの開発が完成する。

近年、クラウドコンピューティングの普及によって、マイクロサービスアーキテクチャに基づくシステム開発が一般化している。マイクロサービスアーキテクチャに基づくシステム開発では、サービスシステムが、開発者が開発したサービスと、他のベンダーが開発したサービスと、クラウドコンピューティングの提供元が提供するサービスといった複数のサービスを組み合わせて構築されることが多い。これらのサービスは、分散環境（例えば、複数の計算機（例えば汎用計算機）から構成された分散型の計算機システム）上で分散的にデプロイされることが多い。そして、個々のサービスにはＡＰＩ（Application Programming Interface）が用意されており、サービス同士が互いにネットワークを経由して処理のリクエストを送信し合い、サービスシステムの処理（例えば、１又は複数の業務）が実現される。このようなシステム開発によって、サービスの再利用性による迅速なシステムの構築や、迅速なリソースの確保によるスケーリング性能の向上が可能となり、開発と運用の両面からメリットが期待されている。

しかし、マイクロサービスアーキテクチャに基づくシステム開発の欠点は、サービスシステムのレスポンスタイムが変動する場合の原因究明や、サービスの障害への対応を設計することが困難なことである。

モノリシックのシステム開発、すなわち、単一のサーバ上に展開されるサービスシステムのシステム開発では、サービスシステムのレスポンスタイムが変動する場合の原因究明は比較的容易である。なぜなら、サービスシステム内の処理の流れがたどりやすく、さらに実行時のリソース消費量などを監視することが、単一のサーバで完結するためである。そのため、あらかじめ障害となりうる箇所も推測しやすく、対応も設計に組み入れるのが比較的容易である。

これに対し、マイクロサービスアーキテクチャでは、小規模の独立した処理が分散環境としての計算機システムで実行され、サービスシステムに対する一つのリクエストに関する処理が、計算機システムを構成する複数のサービスが分散されたサーバ間にまたがるため、開発時および実行時に処理の流れを捉えることが難しくなる。また、一つのリクエストに対する処理が、多数の箇所（サーバ）で処理が実行されるため、サーバ間で多数の通信が発生する。そのため、処理のボトルネックが、今まで存在しにくかったネットワークやメッセージキューに存在する可能性がある。さらに、同一のサービスシステムのうちの少なくとも一部のサービスが異なる開発組織によって開発されたサービスであることもあるため、サービスシステム内で利用される全サービスの処理内容や特徴を把握できる者（例えば開発者または設計者）は少ない。

一般的なシステム開発では、設計したシステムの可用性の検証のために、設計したシステムを試験的に構築した後で（つまり、本番環境と同等の試験環境としての試験用のシステムを構築した後で）、負荷試験やレスポンスタイムの測定を行いその試験結果を基に設計を見直すといったことを繰り返すことが行われる。ただし、この方法は、試験のための試験環境が必要であり、時間的コストが大きい。

そこで、特許文献１のようなシミュレーション技術の利用をして、サービスシステムの構築の前に当該サービスシステムの可用性を推定することが考えられる。

しかしながら、特許文献１におけるシミュレーション対象のシステムは、サービスシステムとは異なり、複数のサーバから構成されたシステム（例えば３階層Ｗｅｂシステム）である。つまり、特許文献１では、シミュレーション対象のシステムの構成要素は、サーバであり、いわゆるオートスケールによりシステムが維持される。

一方、サービスシステム（典型的には、マイクロサービスアーキテクチャに基づくシステム開発において設計されたサービスシステム）がデプロイされる計算機システム（複数のサーバ）は、一般に、システム開発側（例えば、サービスシステムを提供する企業）の管理下に無い計算機システム（例えば、クラウドコンピューティングを提供する企業の管理下の計算機システム）である。

従って、システム開発側で、サービスシステムの可用性を維持するために計算機システムにおけるオートスケールの仕方を制御するといった手法を取ることはできない。つまり、サービスシステムの可用性の検証のためのシミュレーションに、特許文献１に開示の技術を適用することはできない。

いずれのサービスに不具合が生じても（例えば、一部のサービスで障害やレスポンスタイムの変動といった不具合が生じても）、サービスシステム全体として期待する動作（例えば、エンドユーザーに対して何らかのレスポンスを返すこと）を保証することができるようにするために、不具合が生じたサービスに依存するサービスの処理内容およびリクエスト送信先の少なくとも１つが変更される。例えば、あるサービスから当該あるサービスの依存先のサービスにリクエストが送信されたが一定時間経っても依存先のサービスから当該あるサービスにレスポンスが返ってない場合に、当該あるサービスが、下記のうちのいずれかを実行することが考えられる。
・当該あるサービスが、エラー通知を生成し、当該サービスの依存元（またはエンドユーザ）にエラー通知を返す（当該あるサービスの処理内容の変更の一例）。
・当該あるサービスが、リクエスト送信先を、依存先のサービスから、アラート通知用のサービスや、代替サービスに変更する（当該あるサービスのリクエスト送信先の変更の一例）。
・当該あるサービスが、一定頻度で送信されるリクエストの大部分のリクエストを変更後のリクエスト送信先に送信するが、一部のリクエストを、依存先のサービスの不具合が解消しているかもしれないために依存先のサービスに送信する（当該あるサービスの処理内容およびリクエスト送信先の変更の一例）。

このようにサービスシステム内で処理内容およびリクエスト送信先の少なくとも１つを変更することをシミュレーションにおいて実現（再現）するために、下記の（ａ１）ないし（ａ３）の情報が、シミュレーターに入力される。
（ａ１）複数のサービスで構成されサービス間でリクエストが送受信されることで当該複数のサービスが連携してエンドユーザーからのリクエストに従う処理を実行するサービスシステムにおける各サービス間の依存関係を記述したシステム構成。
（ａ２）前記複数のサービスのうちの１以上のサービスの各々について下記を記述した他サービスリクエスト送信ポリシー。
・当該サービスの依存先であるが故にリクエスト送信先となるサービスにおける障害有無と処理速度とのうちの少なくとも１つである処理状況に関する条件。
・当該条件が満たされたとした場合の当該サービスの変更後の処理内容と変更後のリクエスト送信先との少なくとも１つである処理変更。
（ａ３）サービスシステムにエンドユーザーとして送信するリクエストの内容と当該リクエストの送信レートとを記述したリクエスト生成ポリシー。

シミュレーターは、リクエスト生成ポリシーに基づくリクエストが当該リクエスト生成ポリシーに基づく送信レートで到着したとした場合のサービスシステムの挙動であるシステム挙動のシミュレーションを、システム構成および他サービスリクエスト送信ポリシーに基づき実行し、当該シミュレーションの実行結果としてのシステム挙動を表す情報であるシミュレーション結果情報を、出力する。

複数のサービスで構成されたサービスシステム、特に、マイクロサービスアーキテクチャに基づき設計され分散環境にデプロイされるようなサービスシステムにおいて、リクエスト送信先および処理内容の少なくとも１つを変更することを、シミュレーションにおいて実現（再現）することができ、当該変更が行われた場合のシステム挙動をシミュレートして出力することができる。このため、サービスシステムの可用性を推定することができる。

本明細書において開示される主題の、少なくとも一つの実施例の詳細は、添付されている図面と以下の記述の中で述べられる。開示される主題のその他の特徴、態様、効果は、以下の開示、図面、請求項により明らかにされる。

マイクロサービスシミュレーターの入出力を例示する図。 マイクロサービスシミュレーターの利用フローを例示する図。 シミュレーション入力データ作成ツールおよびマイクロサービスシミュレーターの実行に用いられる装置の内部構成を示す図。 シミュレーション入力データ作成ツールにより表示されるシステム構成作成支援画面を例示する図。 他サービスリクエスト送信ポリシーの一例を示す図。 リクエスト生成ポリシーの一例を示す図。 マイクロサービスシミュレーターのシステム構成を例示する図。 シミュレーション環境構築時の処理シーケンスを例示する図。 シミュレーション中のポリシー変更の処理シーケンスを例示する図。 システムへのリクエストに対する処理シーケンスを例示する図。 マイクロサービスシミュレーターへの外乱設定時の処理シーケンスを例示する図。 外乱発生シナリオの一例を示す図。

以下の説明では、「インターフェースデバイス部」は、１以上のインターフェースデバイスでよい。当該１以上のインターフェースデバイスは、下記のうちのいずれでもよい。
・Ｉ／Ｏ（Input/Output）デバイスと遠隔の表示用計算機とのうちの少なくとも１つに対するＩ／Ｏインターフェースデバイス。表示用計算機に対するＩ／Ｏインターフェースデバイスは、通信インターフェースデバイスでよい。少なくとも１つのＩ／Ｏデバイスは、ユーザインターフェースデバイス、例えば、キーボード及びポインティングデバイスのような入力デバイスと、表示デバイスのような出力デバイスとのうちのいずれでもよい。
・１以上の通信インターフェースデバイス。１以上の通信インターフェースデバイスは、１以上の同種の通信インターフェースデバイス（例えば１以上のＮＩＣ（Network Interface Card））であってもよいし２以上の異種の通信インターフェースデバイス（例えばＮＩＣとＨＢＡ（Host Bus Adapter））であってもよい。

また、以下の説明では、「メモリ部」は、１以上のメモリであり、典型的には主記憶デバイスでよい。メモリ部における少なくとも１つのメモリは、揮発性メモリであってもよいし不揮発性メモリであってもよい。

また、以下の説明では、「ＰＤＥＶ部」は、１以上のＰＤＥＶであり、典型的には補助記憶デバイスでよい。「ＰＤＥＶ」は、物理的な記憶デバイス（Physical storage DEVice）を意味し、典型的には、不揮発性の記憶デバイス、例えばＨＤＤ（Hard Disk Drive）またはＳＳＤ（Solid State Drive）である。

また、以下の説明では、「記憶部」は、メモリ部およびＰＤＥＶ部のうちの少なくとも１つ（典型的には少なくともメモリ部）である。

また、以下の説明では、「プロセッサ部」は、１以上のプロセッサである。少なくとも１つのプロセッサは、典型的には、ＣＰＵ（Central Processing Unit）のようなマイクロプロセッサであるが、ＧＰＵ（Graphics Processing Unit）のような他種のプロセッサでもよい。少なくとも１つのプロセッサは、シングルコアでもよいしマルチコアでもよい。少なくとも１つのプロセッサは、処理の一部または全部を行うハードウェア回路（例えばＦＰＧＡ（Field-Programmable Gate Array）またはＡＳＩＣ（Application Specific Integrated Circuit））といった広義のプロセッサでもよい。

また、以下の説明では、「ｋｋｋ部」（インターフェースデバイス部、記憶部およびプロセッサ部を除く）の表現にて機能を説明することがあるが、機能は、１以上のコンピュータープログラムがプロセッサ部によって実行されることで実現されてもよいし、１以上のハードウェア回路によって実現されてもよい。プログラムがプロセッサ部によって実行されることで機能が実現される場合、定められた処理が、適宜に記憶部および／または通信インターフェースデバイス部等を用いながら行われるため、機能はプロセッサ部の少なくとも一部とされてもよい。機能を主語として説明された処理は、プロセッサ部あるいはそのプロセッサ部を有する装置が行う処理としてもよい。プログラムは、プログラムソースからインストールされてもよい。プログラムソースは、例えば、プログラム配布計算機または計算機が読み取り可能な記録媒体（例えば非一時的な記録媒体）であってもよい。各機能の説明は一例であり、複数の機能が１つの機能にまとめられたり、１つの機能が複数の機能に分割されたりしてもよい。

また、以下の説明では、「データセット」とは、プログラムから見た１つの論理的な電子データの塊であり、例えば、レコード、ファイル、キーバリューペア及びタプルのうちのいずれでもよい。

また、以下の説明では、「ｘｘｘデータセット」といった表現にて、入力に対して出力が得られるデータセット（情報）を説明することがあるが、データセットは、どのような構造のデータでもよいし、入力に対する出力を発生するニューラルネットワークのような学習モデルでもよい。以下の説明において、各データセットの構成は一例であり、１つのデータセットは、２以上のデータセットに分割されてもよいし、２以上のデータセットの全部または一部が１つのデータセットであってもよい。

また、以下の説明では、装置が「表示用情報を表示する」ことは、装置が有する表示デバイスに表示用情報を表示することであってもよいし、装置が表示用計算機に表示用情報を送信することであってもよい（後者の場合は表示用計算機によって表示用情報が表示される）。表示用情報の一例が、システム挙動を表す情報であるシミュレーション結果情報である。

以下、本発明の好適な一実施例について、図面を用いて説明する。

本実施例に係るシミュレーターは、マイクロサービスアーキテクチャに基づき設計されたサービスシステムの可用性を推定するためのシミュレーターに係る。そこで、以下、本シミュレーターを、「マイクロサービスシミュレーター」と呼ぶ。また、マイクロサービスシミュレーター内で構築した後述の仮想システム（仮想的なサービスシステム）内の仮想サービス（サービスに対応した仮想的なサービス）に対して意図的に発生させる、過負荷状態やレスポンスタイムの長時間化などを、「外乱」と呼ぶ。

図１は、マイクロサービスシミュレーターの入出力の例を示す。

マイクロサービスシミュレーター０１１２の入力は、システム構成０１０６と、リクエスト生成ポリシー０１０８と、他サービスリクエスト送信ポリシー０１０７である。これらの入力データは、入力データストレージ０１０５に保存される。

システム構成０１０６は、サービスシステムを構成するサービスと、サービス間の依存関係を示したデータセットである。システム構成０１０６の詳細は、図４を基に説明は後述する。

他サービスリクエスト送信ポリシー０１０７は、複数のサービスのうちの１以上のサービスの各々について、（１）当該サービスの依存先であるが故にリクエスト送信先となるサービスにおける障害有無と処理速度とのうちの少なくとも１つである処理状況に関する条件、および、（２）当該条件が満たされたとした場合の当該サービスの変更後の処理内容と変更後のリクエスト送信先との少なくとも１つである処理変更、を記述したデータセットである。他サービスリクエスト送信ポリシー０１０７は、例えば、各サービスが、依存する別のサービスへリクエストを送る際のポリシーを示すデータセットである。他サービスリクエスト送信ポリシー０１０７の中で、依存先のサービスの状態によって、リクエストの送信先を変更することを記述できるものとする。また、自身のサービスの処理内容を変更することも記述できるものとする。例えば、あるサービスが、依存先のサービスでレスポンスタイムがある閾値を超えた場合に、その依存先のサービスへリクエストを送信せず、自身のサービスへリクエストを送信したリクエスト元のサービスにエラーメッセージを送ることが記述できる。

リクエスト生成ポリシー０１０８は、シミュレーション中に、マイクロサービスシミュレーター０１１２内に構築した仮想システムへ疑似的に送信されるメッセージを作成する際に用いられるポリシーである。リクエスト生成ポリシー０１０８では、生成されるメッセージの内容と、送信先のサービスと、一定時間内の送信レートが指定可能である。また送信に用いられるプロトコルを指定することも可能とする。プロトコルが指定できることで、プロトコル特有の送信速度や、再送制御や、同期通信または非同期通信などの特性をシミュレーション内で再現することができる。また、リクエスト生成ポリシー０１０８では、生成するリクエスト数を指定することもできる。リクエスト数は、無限を指定することで、シミュレーションを永続的に稼動させることが可能である。この場合、シミュレーションは、マイクロサービスシミュレーター０１１２のユーザー（例えばシステム設計者）が、マイクロサービスシミュレーター０１１２に対してシミュレーション終了を命令することで終了する。

以降では、システム構成０１０６と、リクエスト生成ポリシー０１０８と、他サービスリクエスト送信ポリシー０１０７を総称して、「入力データ」と呼ぶ。また、これ以降に記載するユーザーは、全て、マイクロサービスシミュレーター０１１２のユーザーを指すものとする。なお、「エンドユーザー」は、サービスシステムのユーザーを指すものとし、例えば、サービスシステムに対するリクエストの発行元である。

マイクロサービスシミュレーター０１１２の外部には、シミュレーション入力データ作成ツール０１０３、外乱入力コンソール０１１０およびポリシー入力コンソール０１１３が存在する。これらの要素０１０３、０１１０および０１１３のいずれも、コンピュータープログラムであってもよいし物理的な装置であってもよい。例えば、クラウド基盤（複数の計算リソースを有する計算機システム）において、マイクロサービスシミュレーター０１１２、シミュレーション入力データ作成ツール０１０３、外乱入力コンソール０１１０およびポリシー入力コンソール０１１３のうちの少なくとも１つが実行されてよい。

入力データは、ユーザーが、シミュレーション入力データ作成ツール０１０３を用いて作成することができる。シミュレーション入力データ作成ツール０１０３は、システム構成０１０６、他サービスリクエスト送信ポリシー０１０７、および、リクエスト生成ポリシー０１０８のうちの少なくとも１つに含める情報要素の入力を受け付ける１以上のＵＩ（User Interface）を表示する。当該１以上のＵＩは、１又は複数のＧＵＩ（Graphical User Interface）に含まれていてよい。当該１以上のＵＩ経由で入力された情報要素が、システム構成０１０６、他サービスリクエスト送信ポリシー０１０７、および、リクエスト生成ポリシー０１０８のうちの少なくとも１つに含まれる。シミュレーション入力データ作成ツール０１０３が提供する１以上のＵＩを利用して効率的に入力データを用意することが期待される。例えば、シミュレーション入力データ作成ツール０１０３は、シミュレーション中に仮想システムに投入するリクエストメッセージのテンプレートを格納するＤＢ（データベース）であるリクエストテンプレートＤＢ０１０１から、メッセージのテンプレートをインポート可能である。また、サービスシステムを構成するサービスのテンプレートを格納するサービステンプレートＤＢ０１０２から、サービスのテンプレートをインポート可能である。さらに、作成した入力ファイルを入力データリポジトリ０１０４に保存し、次回作成する際にインポートすることが可能である。なお、入力データは、ユーザーが、任意のエディタで作成することは可能なものとする。

マイクロサービスシミュレーター０１１２は、システム挙動の情報の出力の一例として、各サービスのリクエスト処理時間であるレスポンスタイムの推移や、ある時刻に各サービスが消費するリソース量を表す情報を出力（表示）することができる。これらの情報の出力の一例は、システム挙動を表示するＵＩの一例であるシステム挙動出力画面（例えばＧＵＩ）０１１１の出力である。システム挙動出力画面０１１１によって、出力結果をグラフ化して出力することが可能である。すなわち、マイクロサービスシミュレーター０１１２は、マイクロサービスアーキテクチャに基づき設計されたサービスシステム（ＩＴシステムと呼ばれてもよい）に所望の可用性があることを確認するために、システム開発側において設計されたサービスシステムに対して想定されるリクエストが入力された際のシステム挙動（例えば、各サービスのレスポンスタイムや利用リソース量の推移）を推定し、当該システム挙動を可視化することができる。また、シミュレーションログＤＢ０１１３にログとして保存することが可能である。

サービスシステムの可用性を測るためには、シミュレーションの途中で、特定のサービスに意図的に外乱を発生させ、外乱発生時の可用性を確認することが望ましい。そこで、ユーザーは、外乱入力コンソール０１１０を用いて、シミュレーションの実行中に、特定のサービスに対して、外乱（例えば、障害、または、過負荷によるレスポンスタイムの長時間化）を、意図的に発生させることができる。また、ユーザーが外乱入力コンソール０１１０で入力した外乱は、入力データストレージ０１０５内に、外乱発生シナリオ０１０９として保存することができるものとする。外乱発生シナリオ０１０９は、サービスシステムに含まれる少なくとも１つのサービスのＩＤと、当該少なくとも１つのサービスについて指定時点での外乱（意図的な処理停止、処理速度向上または処理速度低下）とを記述したデータセットである。外乱発生シナリオ０１０９は、シミュレーション開始前に（または、シミュレーションの実行中に）、マイクロサービスシミュレーター０１１２に入力され、シミュレーション開始後にマイクロサービスシミュレーター０１１２が外乱発生シナリオ０１０９に沿って仮想システム内の仮想サービスに外乱を発生させることができる。

サービスシステムの可用性を測るためには、シミュレーションの途中で（例えば、システム挙動出力画面０１１１が表示するレスポンスタイムや消費リソース量の推移を基に）、エンドユーザーとして発行するリクエストの内容または送信レートや、少なくとも１つのサービスの処理内容またはリクエスト送信先を変更することが望ましい。そこで、ユーザーは、ポリシー入力コンソール０１１３を用いて、シミュレーションの実行中に、他サービスリクエスト送信ポリシー０１０７およびリクエスト生成ポリシー０１０８の少なくとも１つを変更し、マイクロサービスシミュレーター０１１２は、変更後のポリシーをシミュレーション実行中に受け付け、変更後のポリシーを、シミュレーションを停止させることなく反映し、当該反映後のポリシーに従い、当該シミュレーションを継続する。これにより、推定されたシステム挙動の出力と当該出力に基づくポリシー変更との繰り返しを、シミュレーションを止めずに行うといった、効率的な処理が期待できる。なお、ユーザーがポリシー入力コンソール０１１３で入力したポリシーは、入力データストレージ０１０５内に、他サービスリクエスト送信ポリシー０１０７およびリクエスト生成ポリシー０１０８のいずれかとして保存することができるものとする。

本実施例によれば、マイクロサービスシミュレーター０１１２は、上述したシステム構成０１０６、他サービスリクエスト生成ポリシー０１０７、および、リクエスト生成ポリシー０１０８を入力し、リクエスト生成ポリシー０１０８に基づくリクエストが当該ポリシー０１０８に基づく送信レートで到着したとした場合のシステム挙動のシミュレーションを、システム構成０１０６および他サービスリクエスト送信ポリシー０１０７に基づき実行し、当該システム挙動を表す情報を表示する。これにより、マイクロサービスアーキテクチャに基づき設計され分散環境にデプロイされるようなサービスシステムにおいて、リクエスト送信先および処理内容の少なくとも１つを変更することを、シミュレーションにおいて実現（再現）することができ、当該変更が行われた場合のシステム挙動をシミュレートして出力することができる。このため、サービスシステムの可用性を推定することができる。

具体的には、例えば、マイクロサービスシミュレーター０１１２は、シミュレーションの実行中に、サービスシステムに含まれる１以上のサービスの各々について、他サービスリクエスト送信ポリシー０１０７に基づき、当該サービスの依存先のサービスの処理状況を変更し、それに伴い、当該サービスの処理内容およびリクエスト送信先の少なくとも１つを変更し、当該変更後のシステム挙動をシミュレートする。マイクロサービスシミュレーター０１１２は、当該１以上のサービスの各々についての依存先のサービスの処理状況の変更前後のシステム挙動を表す情報を含んだ情報を表示する。これにより、ユーザーは、依存先サービスの処理状況の変更（依存元サービスの処理内容およびリクエスト送信先の少なとも１つの変更）の前後でのシステム挙動を比較することができる。

なお、入力データストレージ０１０５、リクエストテンプレートＤＢ０１０１、サービステンプレートＤＢ０１０２、入力データリポジトリ０１０４、および、シミュレーションログＤＢ０１１３のうちの少なくとも１つは、１以上の計算機が有する記憶部により実現される。

図２は、マイクロサービスシミュレーター０１１２をユーザーが利用する際の利用フロー図を示す。

ユーザーの利用が開始されると（０２０１）、まず、ユーザーは、シミュレーション入力データ作成ツール０１０３を用いて、入力データを作成する（０２０２）。入力データは、リクエストテンプレートＤＢ０１０１やサービステンプレートＤＢ０１０２に格納されたテンプレートを用いて作成しても、入力データリポジトリ０１０４から過去の入力データをインポートして、それを修正して、または修正せずに、作成してよい。その後、ユーザーは、作成した入力データを入力データストレージ０１０５に保存する（０２０３）。

次に、ユーザーは、マイクロサービスシミュレーター０１１２に対して、入力データストレージ０１０５に保存されている入力データを読み込むように命令する（０２０４）。読み込みが完了したら、ユーザーは、マイクロサービスシミュレーター０１１２に対し、シミュレーションの開始を命令する（０２０５）。

シミュレーションが開始後、ユーザーは外乱入力コンソール０１１０を用いて、一つ以上のサービスへの外乱の模擬発生を指示することができる（０２０６）。外乱の影響をシミュレーションで確認する必要がない場合は、このステップは行わなくてもよい。

また、ユーザーは、シミュレーションの実行中に、他サービスリクエスト送信ポリシー０１０７を変更することができる（０２０７）。他サービスリクエスト送信ポリシーをシミュレーション中に変更するためには、例えば、まずユーザーが変更後の他サービスリクエスト送信ポリシー０１０７を入力データストレージ０１０５内に用意し、マイクロサービスシミュレーター０１１２に、変更後の他サービスリクエスト送信ポリシー０１０７をインポートするように命令する。もし、シミュレーション中に、他サービスリクエスト送信ポリシー０１０７を修正する必要がない場合は、このステップは行わなくてもよい。

また、ユーザーは、シミュレーションの実行中に、リクエスト生成ポリシー０１０８を変更することができる（０２０８）。リクエスト生成ポリシー０１０８を変更する場合は、例えば、他サービスリクエスト送信ポリシー０１０７の変更と同様に、ユーザーがまず入力データストレージ０１０５に変更後のリクエスト生成ポリシー０１０８を用意し、マイクロサービスシミュレーター０１１２に変更後のリクエスト生成ポリシー０１０８をインポートするように命令する。もし、シミュレーション中に、リクエスト生成ポリシー０１０８を修正する必要がない場合は、このステップは行わなくてもよい。

シミュレーションの終了条件は、任意の条件でよい。例えば、終了条件は、仮想システムへのリクエストが、リクエスト生成ポリシー０１０８に記載されたメッセージ生成回数分、仮想システムに投入されて、リクエストに応じた処理が実行し終わるか、もしくは、シミュレーション中にユーザーがマイクロサービスシミュレーター０１１２へ、シミュレーション終了命令を送ることである。前述のどちらかの条件に適合した場合は、シミュレーションが終了し（０２０９）、ユーザーの利用は終了となる（０２１０）。

図３は、シミュレーション入力データ作成ツール０１０３およびマイクロサービスシミュレーター０１１２の実行に用いられる装置の内部構成を示す。当該装置は、シミュレーション装置の一例であり、計算機でよい。以下、図３に例示の装置を、便宜上、「シミュレーション装置」と呼ぶ。なお、本実施例では、シミュレーション入力データ作成ツール０１０３およびマイクロサービスシミュレーター０１１２が同装置で実行されるが、シミュレーション入力データ作成ツール０１０３およびマイクロサービスシミュレーター０１１２は、異なる２以上の計算機で実行されてもよい。

シミュレーション装置０３０１は、プロセッサ部０３０２とＩ／Ｏインターフェースデバイス部０３０３と記憶部０３０４と通信インターフェースデバイス部０３０５で構成され、それらは内部のバスで互いに接続されている。Ｉ／Ｏインターフェースデバイス部０３０３と通信インターフェースデバイス部０３０５は、インターフェースデバイス部である。Ｉ／Ｏインターフェースデバイス部０３０３に、キーボードのような入力デバイスや液晶ディスプレイのような出力デバイスといった１以上のユーザインターフェースデバイスが接続される。通信インターフェースデバイス部０３０５に、１以上の外部装置０３０６が、例えばインターネットのようなネットワーク経由で接続される。ただし、記憶部０３０４に格納されるデータは装置ごとに異なっており、それぞれの装置の記憶部０３０４には、その装置の機能を実現するためのプログラムと、イベントログやイベントログに対する処理を行った後のデータを格納する記憶領域が存在してよい。シミュレーション入力データ作成ツール０１０３およびマイクロサービスシミュレーター０１１２は、記憶部０３０４からロードされプロセッサ部０３０２によって実行される。

図４は、シミュレーション入力データ作成ツール０１０３により表示されるシステム構成作成支援画面を示す。

システム構成作成支援画面０４０１は、複数のＵＩとして、サービステンプレート画面０４０４（第１のＵＩの一例）、システム構成設計画面０４０５（第２のＵＩの一例）、および、サービス詳細画面０４０６（第３のＵＩの一例）を有する。システム構成０１０６が含む１以上の情報要素は、システム構成作成支援画面０４０１経由で入力された情報要素である。

サービステンプレート画面０４０４は、サービステンプレートＤＢ０１０２に格納されている１又は複数のサービステンプレートのうちの所望の１以上のサービステンプレートの選択をユーザーから受け付けるＵＩである。当該画面０４０４には、例えば、４つのサービステンプレートにそれぞれ対応した４つのテンプレートオブジェクト０４０７〜０４１０が表示されている。

システム構成設計画面０４０５は、サービステンプレート画面０４０４から選択された１以上のサービステンプレート（テンプレートオブジェクト）にそれぞれ対応した１以上のサービスオブジェクトを表示し、当該１以上のサービスオブジェクトの依存関係の指定をユーザーから受け付けるＵＩである。図４の例では、５つのサービスにそれぞれ対応した５つのサービスオブジェクト０４１１〜０４１５が表示されている。少なくとも１つのサービスオブジェクトが、サービステンプレート画面０４０４から選択されたサービステンプレートに対応したサービスオブジェクトでよい。また、サービステンプレート画面０４０４には、いずれのサービステンプレートを使用すること無しに作成されたサービスに対応するサービスオブジェクトが表示されてもよい。システム構成設計画面０４０５において、サービス間の依存関係は、サービスオブジェクト（ノード）間の矢印（エッジ）で表現可能であるが、他種の表現が採用されてもよい。矢印で結ばれた２つのサービスオブジェクトにおいて、矢印の始点（元）にあるサービスオブジェクトは、依存元のサービスに対応したオブジェクトであり、矢印の終点（先）にあるサービスオブジェクトは、依存先のサービスに対応したオブジェクトである。

サービス詳細画面０４０６は、システム構成設計画面０４０５に展開（表示）された１以上のサービスオブジェクトのうちの選択されたサービスオブジェクト（例えばサービスＣのオブジェクト０４１３）に対応したサービステンプレートに対する１以上の値の入力を受け付けるＵＩである。

サービスシステムを構成する複数のサービスの少なくとも１つは、サービス詳細画面０４０６を介して入力された１以上の値が設定されたサービステンプレートに基づくサービスである。サービステンプレートを利用することにより、サービスシステムの設計を効率的に行うことができる。少なくとも１つのサービステンプレートは、過去に作成されたサービスそれ自体でもよい。

図４に例示のシステム構成作成支援画面０４０１を利用して、ユーザーは、例えば次のようにして、サービスシステムを設計することができる。なお、当該画面０４０１に対するユーザー操作に応答した表示は、シミュレーション入力データ作成ツール０１０３により制御される。

ユーザーは、システム構成設計画面０４０５で、システム構成０１０６を記述する。システム構成０１０６には、システム内で利用するサービスの全てと、サービス間の依存関係が表現される。サービス間をつなぐ矢印は、あるサービスが別のサービスにリクエストを送信することを意味している。例えば、サービスＡの依存先はサービスＢおよびサービスであるが故に、サービスＡは、サービスＢとサービスＣにリクエストを送信することになる。

ユーザーが、システム構成設計画面０４０５内のサービスを選択すると、選択したサービスの詳細が、サービス詳細画面０４０６に表示される。サービスの詳細の例として、サービスがリクエストごとの処理で消費するリソース量が表示される。消費するリソースの量を設定する項目に対応したＵＩとして、ＣＰＵの数の入力用ＵＩ０４１６と、メモリ量の入力用ＵＩ０４１７と、同時に多数のリクエストが到着した時にリソース量を動的に増加させるオートスケールへの対応有無の設定用のＵＩ０４１８、が表示される。これらの値は、マイクロサービスシミュレーター０１１２の入力データとして、ユーザーが設定できるものとする。オートスケールに対応しない場合は、各サービスに割り当てられるリソース量も設定できるものとする。サービス詳細画面０４０６のレスポンスタイム変動項目のＵＩ０４１９では、ユーザーがサービスのレスポンスタイムを設定できる。サービス詳細画面０４０６の、処理同期性項目のＵＩ０４２０では、そのサービスがリクエストを受けた際に、リクエスト元をレスポンス待ちの状態で待たせるか、待たせずに非同期的に処理を行うかを、ユーザーが設定できる。

サービス詳細画面０４０６におけるリクエストの処理負荷と、レスポンスタイム変動と、処理同期性の項目は、サービスが処理するリクエストの内容ごとに個別に記載することも可能なものとする。

サービステンプレート画面０４０４では、システム構成設計画面０４０５内に含めるサービスのサービステンプレートが全てまたは部分的に一覧表示される。ユーザーが、サービステンプレートを、システム構成設計画面０４０５に張り付けると、張り付けられたサービステンプレートはサービスとして認識される。サービステンプレートから作られたサービスは、サービス詳細画面０４０６に値が設定されており、ユーザーは必要であればいずれかの項目の値を修正する。これにより、ユーザーがシステム構成０１０６を作成する時間が短縮される。

システム構成の設計が完了した場合、ユーザーが保存ボタン０４０３をクリックまたはタップすることで、設計されたシステム構成を表すシステム構成０１０６が、入力データリポジトリ０１０４と入力データストレージ０１０５に保存される。なお、インポートボタン０４０２をクリックすることで、入力データリポジトリ０１０４に保存されたシステム構成０１０６を、システム構成設計画面０４０５にインポートすることができる。

図４に例示の通り、ユーザーが、サービスの選択（作成）とサービス間の依存関係の構築とを繰り返すことで、サービスシステムを設計することができる。設計されたサービスシステムのうちの少なくとも１つのサービスは、ユーザー側（システム開発側）とは異なる組織が開発したサービスであり得る。ユーザーは、各サービス間で依存関係を持った複数のサービスの連携により１または複数の業務を実現するサービスシステムを設計する。

なお、シミュレーション入力データ作成ツール０１０３で、各サービスの他サービスリクエスト送信ポリシー０１０７と、システムへのリクエスト生成ポリシー０１０８を、ユーザーが設定する画面があってよいこととする。

図５は、他サービスリクエスト送信ポリシー０１０７の一例を示す。図５の他サービスリクエスト送信ポリシー０１０７は、ＪＳＯＮ（JavaScript（登録商標） Object Notation）フォーマットに従っているが、フォーマットはＪＳＯＮである必要はない。

０５０３行目の記述は、０５０２行目から０５２８行目で記述されているポリシーの適用対象であるサービスを指定している。０５０４行目の記述は、０５０３行目で指定されたサービスが、リクエストを待ち受けるサービスの識別子である。“{”と“}”で囲まれた箇所は、変数を表している。ユーザーは、変数の値ごとに、サービスに届いたリクエストの処理と転送先を記述することができる。０５０５行目の記述は、ポート番号を示す。０５０７行目の記述は、サービスへのリクエストのメソッドを示す。例えば、HTTPによるリクエストを待ち受ける場合は、GET、PUT 、PUSH、DELETEのいずれかが指定される。０５０９行目と０５１０行目の記述は、０５０４行目の文字列の変数として指定されていた箇所の値を指定している。ここでのアスタリスクは、任意の文字列を示す。特にアスタリスクである必要はなく、エンドポイントの記述として有効ではない文字または文字列であれば良い。０５１１行目から０５２６行目の記述は、エンドポイントが０５０４行目と０５０９行目と０５１０行目の記述の組み合わせで指定されたリクエストに対する処理と転送先を示している。

０５１２行目から０５２４行目の記述は、リクエストの送信先サービスと、送信先サービスにレスポンスが長時間返ってこないなどの障害が発生した場合の処理を示している。０５１３行目の記述は、リクエストの送信先サービスを示している。０５１４行目は、リクエストのメソッドを示す。０５１５行目の記述は、リクエスト送信先のエンドポイントを示す。０５１７行目と０５２４行目の記述は、送信先のサービスに障害が発生したとみなす指標と基準を示す。図５の例では、サービスＣがサービスＤに障害が発生したとみなす基準として、サービスＤのレスポンスタイムが５０ms以上であることと設定されている。この他の障害判定基準として、サービスＣがサービスＤに送ってまだレスポンスが返っていないリクエスト数が、一定数を超えた場合に障害とみなす、といった障害の判定基準も指定できるものとする。０５１８行目の記述は、リクエスト送信先のサービスに障害が発生したとみなした場合の処理を指定している。図５の例では、サービスＤで障害が発生したとみなすと、次にサービスＤへ送信すべきリクエストは、サービスＤへ送信せず、サービスＣへリクエストを送信したサービスに、エラーを示すレスポンスを返す。その操作は、システム全体のレスポンスタイムが、サービスＤの障害によって長時間化することを防ぐ。

ユーザーは、０５１７行目から０５２３行目に相当する箇所に、リクエスト送信先で障害が発生した際にリクエストを送る先のサービスを指定できる。例えば、システムを監視するサービスにアラートメッセージを送信する場合には、ユーザーはシステムを監視するサービスを指定する。

０５２２行目の記述は、リクエスト送信先のサービスが障害から回復したとみなす基準を示している。図５の例では、時間としており、０５２３行目の記述により、時間が１秒経過したら、サービスＤが障害から復旧したとみなすことを意図している。

０５０３行目で指定したサービスが、複数のサービスにリクエストを送る場合、ユーザーは０５１２行目から０５２５行目の記述を、配列形式で列挙する。また、０５０３行目で指定したサービスが、複数のリクエストメソッドを受け付ける場合、ユーザーは０５０７行目から０５２８行目の記述を、メソッドをキーとした連想配列で列挙する。また、ユーザーは０５０２行目から０５３０行目の記述を、システム構成０１０６に含まれる全サービスごとに、配列形式で列挙する。

図５の例によれば、他サービスリクエスト送信ポリシー０１０７は、１以上のサービスの各々について、１つのサービスを例に取ると（図５の説明において「対象サービス」）、下記のうちの少なくとも１つ、
・対象サービスのＩＤ、
・対象サービスの依存先のサービス（例えば、対象サービスがリクエストを待ち受けるサービス）のＩＤ、
・対象サービスに届いたリクエストの通常時での処理内容（「通常時」とは、依頼先サービスの不具合時以外の時）、
・依頼先サービスに不具合があるとする条件（例えば、レスポンスタイム閾値）、
・当該条件が満たされた場合である不具合時での処理内容およびリクエスト送信先の少なくとも１つ、
を含む。

図６は、リクエスト生成ポリシー０１０８の一例を示す。図６のリクエスト生成ポリシー０１０８は、ＪＳＯＮ（JavaScript（登録商標） Object Notation）フォーマットに従っているが、フォーマットはＪＳＯＮである必要はない。

リクエスト生成ポリシー０１０８は、シミュレーション中にシステムへのリクエストを生成する際のポリシーである。０６０３行目の記述は、リクエストのプロトコルを示している。０６０４行目の記述は、システムへのリクエスト送信先であるエンドポイントを示している。０６０５行目の記述は、エンドポイントのポート番号を示している。０６０６行目の記述は、シミュレーション中にシステムに送信されるリクエストの数を示している。０６１７行目のように、リクエスト数の項目に数値以外の文字を入力した場合は、リクエストがシステムに永久的に送り続けられる。０６０７行目から０６１１行目の記述は、システムへのリクエストの送信レートを示している。図６の０６０７行目から０６１１行目の例では、単位時間に、平均１００リクエストであり、分散が１０の正規分布に従う確率でリクエストが送信される。

システムに複数の種類のリクエストを送る場合や、複数のサービスにリクエストを送信する場合、０６０２行目から０６１２行目の記述と同等の記述を、複数記載する。図６の例では、シミュレーション中に、サービスＡの８０番ポートに、HTTPプロトコルで、単位時間あたり平均１００個かつ分散が１０の正規分布に従う送信レートでリクエストが到着し、さらに、サービスＢの１８１８１番ポートに、Thriftプロトコルで、単位時間あたり１００個のリクエストが固定レートで到着する。

図７は、マイクロサービスシミュレーター０１１２のシステム構成を示す。

マイクロサービスシミュレーター０１１２は、シミュレーション制御部０７０６と、入力ファイルロード部０７０３と、仮想システム構築部０７０４と、リクエスト生成部０７０７といった複数のモジュール（機能）を有する。

シミュレーション制御部０７０６は、ユーザーからの命令に応じて、シミュレーション環境の構築、シミュレーションの開始、シミュレーションの一時停止、シミュレーションの終了、特定のサービスへの外乱の入力を行う。なお、ユーザーからの命令は、外乱入力コンソール０１１０、ポリシー入力コンソール０１１３、および、その他の図示しない入力コンソールのうちの少なくとも１つの入力コンソール経由で受信することができる。

入力ファイルロード部０７０３は、シミュレーション制御部０７０６からの指示に応じて、入力データストレージ０１０５内に存在する入力ファイル（入力データセットの一例）を読み取り、仮想システム構築部０７０４に転送する。

仮想システム構築部０７０４は、入力ファイルロード部０７０３から受け取った入力ファイルを基に、シミュレーション対象であるサービスシステムをマイクロサービスシミュレーター０１１２内で仮想的に構築する。その際、仮想システム構築部０７０４は、システム構成に基づき、サービスシステムに含まれる各サービスのインスタンスを生成する。すなわち、仮想システム構築部０７０４が、複数のサービスにそれぞれ対応した複数の仮想サービス０７０８で構成された仮想的なサービスシステムである仮想システム０７００を構築する。従って、仮想システム０７００において、各仮想サービス間の依存関係は、サービスシステムにおける各サービス間の依存関係と同じである。各仮想サービス０７０８は、対応するサービスが仮想化されたサービスであり、具体的には、例えば、対応するサービスのインスタンスに相当する。

シミュレーション制御部０７０６は、ユーザーからのシミュレーションの制御を受け付ける。シミュレーション制御部０７０６が受け付ける制御は、シミュレーション内での仮想システム０７００の構築と、シミュレーションの開始と、シミュレーションの一時停止と、シミュレーションの終了と、特定のサービスへの意図的な外乱発生、のいずれかである。

リクエスト生成部０７０７は、シミュレーション中に、仮想システム０７００に入力するリクエストを生成する。仮想システム構築部０７０４によって生成された仮想サービス０７０８は、サービス制御受信部０７０９と、サービス処理部０７１０と、他サービスリクエスト部０７１１を含む。以下、１つの仮想サービス０７０８を例に取る（図７の説明において「対象仮想サービス０７０８」）。

サービス制御受信部０７０９は、シミュレーション制御部０７０６から対象仮想サービス０７０８への制御を受け付ける。例えば、ユーザーがシミュレーションを一時停止させる場合は、ユーザーがシミュレーション制御部０７０６に対して一時停止を命令し、シミュレーション制御部０７０６が各仮想サービス０７０８のサービス制御受信部０７０９に、一時停止命令を送信する。サービス処理部０７１０は、対象仮想サービス０７０８が処理を行っている間、対象仮想サービス０７０８の処理に必要なリソース量を消費し続ける。対象仮想サービス０７０８の処理時間と処理中に消費するリソース量は、システム構成０１０６内で指定された値に基づく。他サービスリクエスト部０７１１は、サービス処理部０７１０で処理が終わった後に、他の仮想サービス０７０８にリクエストを送信する。リクエスト送信先は、他サービスリクエスト送信ポリシー０１０７で指定されたルールに従う。すなわち、リクエスト送信先は、原則、対象仮想サービス０７０８の依存先の仮想サービス０７０８であるが、依存先の仮想サービス０７０８に不具合が生じた場合には、依存先の仮想サービス０７０８とは別の仮想サービス０７０８とされ得る。言い換えれば、対象仮想サービス０７０８にとって、通常のリクエスト送信先は、サービス構成０１０６が示す依存関係に従う依存先の仮想サービス０７０８であるが、依存先の仮想サービス０７０８に不具合が生じた場合のリクエスト送信先は、他サービスリクエスト送信ポリシー０１０７に従う仮想サービス０７０８となる。

各サービスは、典型的にはアプリケーションであり、リクエストを受け付ける入力インターフェースの一例としてのＡＰＩ（Application Programming Interface）や、別のサービスの入力ＡＰＩに対するリクエストを送信する出力インターフェースの一例としてのＡＰＩを有する。対象仮想サービス０７０８において、サービス処理部０７１０は、対象仮想サービス０７０８に対応したサービスの入力ＡＰＩに対応した部分であり、サービス構成０１０６に基づく値が設定されることで実現された部分である。対象仮想サービス０７０８において、他サービスリクエスト部０７１１は、対象仮想サービス０７０８に対応したサービスの出力ＡＰＩに対応した部分であり、他サービスリクエスト送信ポリシー０１０７に基づく値が設定されることで実現された部分である。

以上のように、各仮想サービス０７０８は、当該仮想サービス０７０８が有する出力インターフェースは、他サービスリクエスト送信ポリシー０１０７に基づく設定がされた出力インターフェースとしてのモジュールである他サービスリクエスト部０７１１である。これにより、依存先のサービスで不具合が生じた場合にリクエスト送信先を別のサービスに切り替えることをシミュレーションにおいて実行することができる。なお、依存先の仮想サービス０７０８が存在しない仮想サービス０７０８には、他サービスリクエスト部０７１１が設けられないでよい。

また、各仮想サービス０７０８は、入力インターフェースとしてリクエストを受け付け当該リクエストに従う処理を実行するサービス処理部０７１０に加えて、当該仮想サービス０７０８におけるサービス処理部０７１０（及び他サービスリクエスト部０７１１）を制御するサービス制御受信部０７０９を有する。これにより、サービス処理部０７１０（及び他サービスリクエスト部０７１１）それ自体に特段の設定をすること無しに、サービス処理部０７１０（及び他サービスリクエスト部０７１１）を制御することができる。具体的には、例えば、シミュレーションの実行中であって、仮想システム０７００の構築後に、仮想システム０７００の外にあるシミュレーション制御部０７０６が、他サービスリクエスト送信ポリシー０１０７の変更後のポリシー０１０７を受け付けたとする（本実施例において、ユーザーは、シミュレーション中に表示されるシステム挙動を見て、適宜、他サービスリクエスト送信ポリシー０１０７およびリクエスト生成ポリシー０１０８の少なくとも１つを変更可能）。この場合、当該変更後のポリシー０１０７に従う変更対象の他サービスリクエスト部０７１１を有する仮想サービス０７０８（例えば、変更後のポリシー０１０７で指定されたサービスに対応する仮想サービス０７０８）におけるサービス制御受信部０７０９に、当該変更後のポリシー０１０７に従う設定の指示を送信する。当該指示を受けたサービス制御受信部０７０９は、当該サービス制御受信部０７０９を有する仮想サービス０７０８内のサービス処理部０７１０を一時停止させ、当該一時停止中に、当該仮想サービス０７０８内の他サービスリクエスト部０７１１に対し、当該指示に従う設定を行う。このようにして、シミュレーションを止めること無しに、変更後のポリシー０１０７を反映することができる。

また、本実施例では、サービス処理部０７１０が、能動的に規定された処理を実行し適宜リクエスト送信を他サービスリクエスト部０７１１に指示するのではなく、リクエストを外部から受信したことに応答して処理を実行するようになっている。具体的には、仮想システム０７００の外部に、エンドユーザーとしてリクエストを送信するリクエスト生成部０７０７が設けられている。リクエスト生成部０７０７は、リクエスト生成ポリシー０１０８に従う内容のリクエストを、当該ポリシー０１０８に従う送信レートでエンドユーザーとして仮想システム０７００に送信するようになっている。シミュレーションの実行中であって、仮想システム０７００の構築後に、仮想システム０７００の外にあるリクエスト生成部０７０７が、シミュレーション制御部０７０６経由で、リクエスト生成ポリシー０１０８の変更後のポリシー０１０８を受け付けたとする。この場合、リクエスト生成部０７０７が、当該変更後のポリシー０１０８に従う内容のリクエストを、当該変更後のポリシー０１０８に従う送信レートでエンドユーザーとして仮想システム０７００に送信する。

図８は、シミュレーション環境構築の処理シーケンスを示す。

シミュレーション環境の構築は、シミュレーション開始前に実行される。ユーザーが、シミュレーション制御部０７０６に、シミュレーション環境の構築を命令すると（０８０１）、シミュレーション制御部０７０６は、入力ファイルロード部０７０３に、入力ファイルのロード命令を送信する（０８０２）。入力ファイルロード部０７０３は、当該命令に応答して、入力データストレージ０１０５を参照し（０８０３）、入力ファイル（入力データ）を取得（０８０４）して受け取る（０８０５）。

その後、入力ファイルロード部０７０３は、仮想システム構築部０７０４に、システム構成０１０６と他サービスリクエスト送信ポリシー０１０７を転送する（０８０６）。仮想システム構築部０７０４は、システム構成０１０６と他サービスリクエスト送信ポリシー０１０７に従い、仮想システム０７００を構築する、例えば、システム構成０１０６に含まれるサービスのインスタンスをシミュレーション環境内に生成する（０８０７）。また、入力ファイルロード部０７０３は、リクエスト生成部０７０７にリクエスト生成ポリシー０１０８を送信する（０８０８）。リクエスト生成部０７０７は、リクエスト生成ポリシー０１０８に従い、サービスシステム（仮想システム０７００）へ入力するリクエストの内容と、リクエストの送信先であるサービス（当該サービスに対応した仮想サービス０７０８）と、リクエスト送信レートを設定する（０８０９）。

リクエスト生成ポリシー０１０８と、他サービスリクエスト送信ポリシー０１０７は、上述したように、シミュレーション中であっても、シミュレーションを停止させることなく変更することが可能である。

図９は、シミュレーション中のポリシー変更の処理シーケンスを示す。

シミュレーションが開始（０９０１）された後、ユーザーが新しいリクエスト生成ポリシー０１０８、または他サービスリクエスト送信ポリシー０１０７を、入力データストレージ０１０５に用意する。

ユーザーが、シミュレーション制御部０７０６に、リクエスト生成ポリシー０１０８の再読み込みを命令すると（０９０２）、シミュレーション制御部０７０６は、入力ファイルロード部０７０３に、新しいリクエスト生成ポリシー０１０８の取得を命令する（０９０３）。その後、入力ファイルロード部０７０３は、入力データストレージ０１０５にリクエスト生成ポリシー０１０８を参照する（０９０４）。入力データストレージ０１０５は、該当するリクエスト生成ポリシー０１０８を取得し（０９０５）、入力ファイルロード部０７０３に当該ポリシー０１０８を送信する（０９０６）。入力ファイルロード部０７０３は、リクエスト生成部０７０７にリクエスト生成ポリシー０１０８を転送する（０９０７）。リクエスト生成部０７０７は、取得した新しいリクエスト生成ポリシーを反映し（０９０８）、新しいリクエスト生成ポリシー０１０８に基づいて、サービスシステム（仮想システム０７００）にリクエストを送信する。

また、ユーザーが、他サービスリクエスト送信ポリシー０１０７の再読み込みをシミュレーション制御部０７０６に命令すると（０９０９）、シミュレーション制御部０７０６は、入力ファイルロード部０７０３に、新しい他サービスリクエスト送信ポリシー０１０７の取得を命令する（０９１０）。その後、入力ファイルロード部０７０３は、入力データストレージ０１０５に他サービスリクエスト送信ポリシー０１０７を参照する（０９１１）。入力データストレージ０１０５は、該当する他サービスリクエスト送信ポリシー０１０７を取得し（０９１２）、入力ファイルロード部０７０３に当該ポリシー０１０７を送信する（０９１３）。入力ファイルロード部０７０３は、他サービスリクエスト送信ポリシー０１０７に従う修正が必要な仮想サービス０７０８のサービス制御受信部０７０９に、新しい他サービスリクエスト送信ポリシー０１０７（またはそのうちの外部部分）を送信する（０９１４）。サービス制御受信部０７０９は、自身のサービス内の他サービスリクエスト部０７１１に、新しい他サービスリクエスト送信ポリシー０１０７を転送する（０９１５）。その後、他サービスリクエスト部０７１１は、受け取った他サービスリクエスト送信ポリシー０１０７を、自身のリクエスト送信のポリシーとして反映する（０９１６）。なお、０９１４のステップにおいて、新しい他サービスリクエスト送信ポリシー０１０７の送信先を、他サービスリクエスト部０７１１とし、サービス制御受信部０７０９が他サービスリクエスト送信ポリシーを中継しなくてもよいものとする。

図１０は、シミュレーション実行中における、システムへのリクエストに対する処理シーケンスを示す。

ユーザーが、シミュレーション制御部０７０６にシミュレーションの開始を命令すると（１００１）、シミュレーション制御部０７０６は、リクエスト生成部０７０７に対しリクエストの生成を指示する（１００２）。リクエスト生成部０７０７は、リクエスト生成ポリシー０１０８に従ってリクエストを生成し（１００３）、仮想サービス０７０８内のサービス処理部０７１０に当該リクエストを転送する（１００４）。

サービス処理部０７１０にリクエストが到着すると、サービス処理部０７１０は、サービスが消費するリソース量を、一回のリクエストに対するサービスの処理に必要なリソース量分増加させ（１００５）、処理に要する時間だけ処理を待機する（１００６）。なお、「一回のリクエストに対するサービスの処理に必要なリソース量」および「処理に要する時間」は、サービス構成０１０６（またはその他の入力データセット）に定義されており、サービス処理部０７１０に設定されているものとする。処理に要する時間が経過すると、サービス処理部０７１０は、一回のリクエストに対するサービスの処理に必要なリソース量分減少させる（１００７）。仮想サービス０７０８が他の仮想サービス０７０８にリクエストを送る場合は、サービス処理部０７１０が、他サービスリクエスト部０７１１にリクエストを送信する（１００８）。他サービスリクエスト部０７１１は、他の仮想サービス０７０８（典型的には依存先の仮想サービス０７０８）が規定された不具合条件に適合するか否かに応じて（例えば、レスポンスタイム、障害状況、または、レスポンスが返っていない送信済みリクエスト数といった状況が、他サービスリクエスト送信ポリシー０１０７に規定された条件を満たすか否かに応じて）、リクエスト送信先の仮想サービス０７０８を決定する（１００９）。つまり、リクエスト送信先が、依存先の仮想サービス０７０８のままでよいか、あるいは異なる仮想サービス０７０８とされるかが決定される。そして、他サービスリクエスト部０７１１は、決定したリクエスト送信先仮想サービス０７０８のサービス処理部０７１０に、リクエストを送信する（１０１０）。

他サービスリクエスト部０７１１は、他の仮想サービス０７０８からレスポンスを受信すると（１０１１）、当該他の仮想サービス０７０８のレスポンスタイムを記憶する（１０１２）。記憶した、他の仮想サービス０７０８のレスポンスタイムは、サービス処理部０７１０からも参照できるものとする。他の仮想サービス０７０８のレスポンスタイムを記憶することで、サービス処理部０７１０は、リクエスト送信先の仮想サービス０７０８のレスポンスタイムに応じて仮想サービス０７０８の処理内容を変更することができる。さらに、他サービスリクエスト部０７１１は、出力されたログに応じて、送信先の仮想サービス０７０８を変更することができる。レスポンスを自身の仮想サービス０７０８のサービス処理部０７１０に返す（１０１３）。その後、サービス処理部０７１０は、他の仮想サービス０７０８へのリクエストにおけるレスポンスタイムをログとして出力する（１０１４）。その後、サービス処理部０７１０は、リクエスト生成部０７０７にレスポンスを返す（１０１５）。

図１１は、シミュレーション中に、ユーザーがマイクロサービスシミュレーター０１１２へ外乱を入力する際の処理シーケンスを示す。シミュレーションにおいて、依存先の仮想サービス０７０８の不具合は、他サービスリクエスト送信ポリシー０１０７と外乱発生シナリオ０１０９とのうちの少なくとも１つに従い発生することになる。

ユーザーが、シミュレーション中に、外乱入力コンソール０１１０を用いて、外乱（外乱発生シナリオ０１０９）を入力する（１１０１）。１１０１のステップにおいて、ユーザーは、外乱を発生させるサービスと、外乱の内容を指定する。外乱の内容の例として、サービスの停止または、サービスのレスポンスタイムの増大を指定できるものとする。外乱入力コンソール０１１０は、シミュレーション制御部０７０６に、ユーザーが入力した外乱をシミュレーション内で発生させるように指示を送る（１１０２）。シミュレーション制御部０７０６は、ユーザーに指定されたサービスに対応する仮想サービス０７０８がシミュレーション中で稼動中であることを確認し、当該仮想サービス０７０８のサービス制御受信部０７０９に外乱の発生指示を送信する（１１０３）。サービス制御受信部０７０９が外乱発生の指示を受けると、当該サービス制御受信部０７０９は、サービス処理部０７１０に、ユーザーに指定された外乱の内容に応じた、処理の変更を指示する（１１０４）。例えば、ユーザーがサービスの停止を指定した場合は、サービス処理部０７１０は、他のサービスからのリクエストを受け付けず、さらに実行中の処理は、処理のリクエスト元にはレスポンスを返さずに、処理を終了する。また、ユーザーがサービスのレスポンスタイムの増加を指定した場合は、サービス処理部０７１０は、サービス処理部０７１０内で設定されているレスポンスタイムを、ユーザーの指定量分増加させる。

図１２は、外乱発生シナリオ０１０９の一例を示す。

１２０２行目から１２０９行目までの記述は、単一のサービスに対する単一の外乱事象を示している。複数の外乱を設定する場合は、１２１０行目から１２１８行目のように、配列形式で全ての外乱を列挙する。

１２０３行目の記述は、シミュレーション開始後から外乱が発生するまでの時間または時刻を表す。１２０４行目の記述は、外乱の事象が終了する時刻、または外乱の継続時間を表す。１２０５行目の記述は、外乱が発生するサービスを示している。１２０６行目の記述は、外乱の内容を示している。図１２の１２０６行目は、例として、サービスが停止したことを表しており、１２１４行目は、サービスのレスポンスタイムが長時間化したことを示している。１２０７行目から１２０８行目までの記述は、発生する外乱の補足情報を示す。例として、１２１５行目から１２１７行目では、レスポンスタイムが通常の３倍になることを表している。

外乱発生シナリオ０１０９は、シミュレーション開始前に、マイクロサービスシミュレーター０１１２に入力され、シミュレーション開始後にマイクロサービスシミュレーター０１１２が外乱発生シナリオ０１０９に沿ってシステム内のサービスに外乱を発生させることができる。ユーザーは、外乱入力コンソール、またはシミュレーション入力データ作成ツール、または任意のテキストエディタを用いて、外乱発生シナリオを作成できるものとする。

以上、本発明の一実施例を説明したが、これらは本発明の説明のための例示であって、本発明の範囲をこの実施例にのみ限定する趣旨ではない。本発明は、他の種々の形態でも実行することが可能である。

０１１２：マイクロサービスシミュレーター、０１０５：入力データストレージ、０１０６：システム構成、０１０７：他サービスリクエスト送信ポリシー、０１０８：リクエスト生成ポリシー、０１０９：外乱発生シナリオ、０１０３：シミュレーション入力データ作成ツール、０１１０：外乱入力コンソール、０７０６：シミュレーション制御部、０７０３：入力ファイルロード部、０１１３：ポリシー入力コンソール

Claims (14)

1. （Ａ）下記の（ａ１）ないし（ａ３）の情報を入力し、
   （ａ１）複数のサービスで構成されサービス間でリクエストが送受信されることで当該複数のサービスが連携してエンドユーザーからのリクエストに従う処理を実行するサービスシステムにおける各サービス間の依存関係を記述したシステム構成、
   （ａ２）前記複数のサービスのうちの１以上のサービスの各々について下記の（ａ２１）および（ａ２２）を記述した他サービスリクエスト送信ポリシー、
   （ａ２１）当該サービスの依存先であるが故にリクエスト送信先となるサービスにおける障害有無と処理速度とのうちの少なくとも１つである処理状況に関する条件、
   （ａ２２）当該条件が満たされたとした場合の当該サービスの変更後の処理内容と変更後のリクエスト送信先との少なくとも１つである処理変更、
   （ａ３）前記サービスシステムに前記エンドユーザーとして送信するリクエストの内容と当該リクエストの送信レートとを記述したリクエスト生成ポリシー、
   （Ｂ）前記リクエスト生成ポリシーに基づくリクエストが前記リクエスト生成ポリシーに基づく送信レートで到着したとした場合の前記サービスシステムの挙動であるシステム挙動のシミュレーションを、前記システム構成および前記他サービスリクエスト送信ポリシーに基づき実行し、
   （Ｃ）当該シミュレーションの実行結果としての前記システム挙動を表す情報であるシミュレーション結果情報を、出力する、
   ことをコンピューターに実行させ、
   （Ｂ）のシミュレーションの実行中に、
   前記他サービスリクエスト送信ポリシー及び前記リクエスト生成ポリシーのうちの少なくとも１つの変更後のポリシーを受け付け、
   当該変更後のポリシーを、前記シミュレーションを停止させることなく反映し、
   当該反映後のポリシーに従い、当該シミュレーションを継続する、
   ことを前記コンピューターに実行させることを特徴とするシミュレーター。
2. （Ａ）下記の（ａ１）ないし（ａ３）の情報を入力し、
   （ａ１）複数のサービスで構成されサービス間でリクエストが送受信されることで当該複数のサービスが連携してエンドユーザーからのリクエストに従う処理を実行するサービスシステムにおける各サービス間の依存関係を記述したシステム構成、
   （ａ２）前記複数のサービスのうちの１以上のサービスの各々について下記の（ａ２１）および（ａ２２）を記述した他サービスリクエスト送信ポリシー、
   （ａ２１）当該サービスの依存先であるが故にリクエスト送信先となるサービスにおける障害有無と処理速度とのうちの少なくとも１つである処理状況に関する条件、
   （ａ２２）当該条件が満たされたとした場合の当該サービスの変更後の処理内容と変更後のリクエスト送信先との少なくとも１つである処理変更、
   （ａ３）前記サービスシステムに前記エンドユーザーとして送信するリクエストの内容と当該リクエストの送信レートとを記述したリクエスト生成ポリシー、
   （Ｂ）前記リクエスト生成ポリシーに基づくリクエストが前記リクエスト生成ポリシーに基づく送信レートで到着したとした場合の前記サービスシステムの挙動であるシステム挙動のシミュレーションを、前記システム構成および前記他サービスリクエスト送信ポリシーに基づき実行し、
   （Ｃ）当該シミュレーションの実行結果としての前記システム挙動を表す情報であるシミュレーション結果情報を、出力する、
   ことをコンピューターに実行させ、
   （Ｂ）のシミュレーションは、前記システム構成および前記他サービスリクエスト送信ポリシーに基づき、前記サービスシステムが仮想化されたシステムである仮想システムを構築することを含み、
   前記仮想システムは、前記複数のサービスが仮想化された複数のサービスである複数の仮想サービスで構成され、
   前記１以上のサービスの各々は、出力インターフェースを有し、
   前記複数の仮想サービスのうち、前記１以上のサービスにそれぞれ対応する１以上の仮想サービスの各々について、当該仮想サービスが有する出力インターフェースは、前記他サービスリクエスト送信ポリシーに基づく設定がされた出力インターフェースとしてのモジュールである他サービスリクエスト部である、
   ことを特徴とするシミュレーター。
3. 請求項２に記載のシミュレーターであって、
   前記１以上のサービスの各々は、入力インターフェースを有し、
   前記１以上のサービスにそれぞれ対応した１以上の仮想サービスの各々は、更に、
   入力インターフェースとしてリクエストを受け付け当該リクエストに従う処理を実行するモジュールであるサービス処理部と、
   当該仮想サービスにおける前記サービス処理部及び前記他サービスリクエスト部を制御するモジュールであるサービス制御受信部と
   を有する、
   ことを特徴とするシミュレーター。
4. 請求項３に記載のシミュレーターであって、
   （Ｂ）のシミュレーションの実行中であって、前記仮想システムの構築後に、
   前記他サービスリクエスト送信ポリシーの変更後のポリシーを受け付け、
   当該変更後のポリシーに従う変更対象の他サービスリクエスト部を有する仮想サービスにおけるサービス制御受信部に、当該変更後のポリシーに従う設定の指示を送信する、
   ことを前記コンピューターに実行させ、
   当該指示を受けたサービス制御受信部は、
   当該サービス制御受信部を有する仮想サービス内のサービス処理部を一時停止させ、
   当該一時停止中に、当該仮想サービス内の他サービスリクエスト部に対し、当該指示に従う設定を行う、
   ことを特徴とするシミュレーター。
5. （Ａ）下記の（ａ１）ないし（ａ３）の情報を入力し、
   （ａ１）複数のサービスで構成されサービス間でリクエストが送受信されることで当該複数のサービスが連携してエンドユーザーからのリクエストに従う処理を実行するサービスシステムにおける各サービス間の依存関係を記述したシステム構成、
   （ａ２）前記複数のサービスのうちの１以上のサービスの各々について下記の（ａ２１）および（ａ２２）を記述した他サービスリクエスト送信ポリシー、
   （ａ２１）当該サービスの依存先であるが故にリクエスト送信先となるサービスにおける障害有無と処理速度とのうちの少なくとも１つである処理状況に関する条件、
   （ａ２２）当該条件が満たされたとした場合の当該サービスの変更後の処理内容と変更後のリクエスト送信先との少なくとも１つである処理変更、
   （ａ３）前記サービスシステムに前記エンドユーザーとして送信するリクエストの内容と当該リクエストの送信レートとを記述したリクエスト生成ポリシー、
   （Ｂ）前記リクエスト生成ポリシーに基づくリクエストが前記リクエスト生成ポリシーに基づく送信レートで到着したとした場合の前記サービスシステムの挙動であるシステム挙動のシミュレーションを、前記システム構成および前記他サービスリクエスト送信ポリシーに基づき実行し、
   （Ｃ）当該シミュレーションの実行結果としての前記システム挙動を表す情報であるシミュレーション結果情報を、出力する、
   ことをコンピューターに実行させ、
   （Ｂ）のシミュレーションにおいて、
   前記システム構成および前記他サービスリクエスト送信ポリシーに基づき、前記サービスシステムが仮想化されたシステムである仮想システムを構築し、
   前記リクエスト生成ポリシーに従う内容のリクエストを、前記リクエスト生成ポリシーに従う送信レートで前記エンドユーザーとして前記仮想システムに送信し、
   （Ｂ）のシミュレーションの実行中であって、前記仮想システムの構築後に、
   前記リクエスト生成ポリシーの変更後のポリシーを受け付け、
   当該変更後のポリシーに従う内容のリクエストを、当該変更後のポリシーに従う送信レートで前記エンドユーザーとして前記仮想システムに送信する、
   ことを前記コンピューターに実行させることを特徴とするシミュレーター。
6. （Ａ）下記の（ａ１）ないし（ａ３）の情報を入力し、
   （ａ１）複数のサービスで構成されサービス間でリクエストが送受信されることで当該複数のサービスが連携してエンドユーザーからのリクエストに従う処理を実行するサービスシステムにおける各サービス間の依存関係を記述したシステム構成、
   （ａ２）前記複数のサービスのうちの１以上のサービスの各々について下記の（ａ２１）および（ａ２２）を記述した他サービスリクエスト送信ポリシー、
   （ａ２１）当該サービスの依存先であるが故にリクエスト送信先となるサービスにおける障害有無と処理速度とのうちの少なくとも１つである処理状況に関する条件、
   （ａ２２）当該条件が満たされたとした場合の当該サービスの変更後の処理内容と変更後のリクエスト送信先との少なくとも１つである処理変更、
   （ａ３）前記サービスシステムに前記エンドユーザーとして送信するリクエストの内容と当該リクエストの送信レートとを記述したリクエスト生成ポリシー、
   （Ｂ）前記リクエスト生成ポリシーに基づくリクエストが前記リクエスト生成ポリシーに基づく送信レートで到着したとした場合の前記サービスシステムの挙動であるシステム挙動のシミュレーションを、前記システム構成および前記他サービスリクエスト送信ポリシーに基づき実行し、
   （Ｃ）当該シミュレーションの実行結果としての前記システム挙動を表す情報であるシミュレーション結果情報を、出力する、
   ことをコンピューターに実行させ、
   前記システム構成が含む１以上の情報要素は、前記システム構成に含める情報要素の入力を受け付ける１以上のＵＩ（User Interface）経由で入力された情報要素であり、
   前記１以上のＵＩは、
   １又は複数のサービステンプレートから１以上のサービステンプレートの選択を受け付ける第１のＵＩと、
   前記第１のＵＩから選択された１以上のサービステンプレートにそれぞれ対応した１以上のオブジェクトを表示し当該１以上のオブジェクトの依存関係の指定を受け付ける第２のＵＩと、
   当該１以上のオブジェクトのうちの選択されたオブジェクトに対応したサービステンプレートに対する１以上の値の入力を受け付ける第３のＵＩと
   を含み、
   前記複数のサービスの少なくとも１つは、前記第３のＵＩを介して入力された１以上の値が設定されたサービステンプレートに基づくサービスである、
   ことを特徴とするシミュレーター。
7. 下記の（ａ１）ないし（ａ３）の情報、
   （ａ１）複数のサービスで構成されサービス間でリクエストが送受信されることで当該複数のサービスが連携してエンドユーザーからのリクエストに従う処理を実行するサービスシステムにおける各サービス間の依存関係を記述したシステム構成、
   （ａ２）前記複数のサービスのうちの１以上のサービスの各々について下記の（ａ２１）および（ａ２２）を記述した他サービスリクエスト送信ポリシー、
   （ａ２１）当該サービスの依存先であるが故にリクエスト送信先となるサービスにおける障害有無と処理速度とのうちの少なくとも１つである処理状況に関する条件、
   （ａ２２）当該条件が満たされたとした場合の当該サービスの変更後の処理内容と変更後のリクエスト送信先との少なくとも１つである処理変更、
   （ａ３）前記サービスシステムに前記エンドユーザーとして送信するリクエストの内容と当該リクエストの送信レートとを記述したリクエスト生成ポリシー、
   を格納した記憶部と、
   下記の処理、
   （Ａ）前記システム構成、前記他サービスリクエスト送信ポリシー、および、前記リクエスト生成ポリシーを入力し、
   （Ｂ）前記リクエスト生成ポリシーに基づくリクエストが前記リクエスト生成ポリシーに基づく送信レートで到着したとした場合の前記サービスシステムの挙動であるシステム挙動のシミュレーションを、前記システム構成および前記他サービスリクエスト送信ポリシーに基づき実行し、
   （Ｃ）当該シミュレーションの実行結果としての前記システム挙動を表す情報であるシミュレーション結果情報を、出力する、
   を実行するシミュレーション部と
   を備え、
   前記シミュレーション部が、（Ｂ）のシミュレーションの実行中に、
   前記他サービスリクエスト送信ポリシー及び前記リクエスト生成ポリシーのうちの少なくとも１つの変更後のポリシーを受け付け、
   当該変更後のポリシーを、前記シミュレーションを停止させることなく反映し、
   当該反映後のポリシーに従い、当該シミュレーションを継続する、
   シミュレーション装置。
8. 下記の（ａ１）ないし（ａ３）の情報、
   （ａ１）複数のサービスで構成されサービス間でリクエストが送受信されることで当該複数のサービスが連携してエンドユーザーからのリクエストに従う処理を実行するサービスシステムにおける各サービス間の依存関係を記述したシステム構成、
   （ａ２）前記複数のサービスのうちの１以上のサービスの各々について下記の（ａ２１）および（ａ２２）を記述した他サービスリクエスト送信ポリシー、
   （ａ２１）当該サービスの依存先であるが故にリクエスト送信先となるサービスにおける障害有無と処理速度とのうちの少なくとも１つである処理状況に関する条件、
   （ａ２２）当該条件が満たされたとした場合の当該サービスの変更後の処理内容と変更後のリクエスト送信先との少なくとも１つである処理変更、
   （ａ３）前記サービスシステムに前記エンドユーザーとして送信するリクエストの内容と当該リクエストの送信レートとを記述したリクエスト生成ポリシー、
   を格納した記憶部と、
   下記の処理、
   （Ａ）前記システム構成、前記他サービスリクエスト送信ポリシー、および、前記リクエスト生成ポリシーを入力し、
   （Ｂ）前記リクエスト生成ポリシーに基づくリクエストが前記リクエスト生成ポリシーに基づく送信レートで到着したとした場合の前記サービスシステムの挙動であるシステム挙動のシミュレーションを、前記システム構成および前記他サービスリクエスト送信ポリシーに基づき実行し、
   （Ｃ）当該シミュレーションの実行結果としての前記システム挙動を表す情報であるシミュレーション結果情報を、出力する、
   を実行するシミュレーション部と
   を備え、
   （Ｂ）のシミュレーションは、前記システム構成および前記他サービスリクエスト送信ポリシーに基づき、前記サービスシステムが仮想化されたシステムである仮想システムを構築することを含み、
   前記仮想システムは、前記複数のサービスが仮想化された複数のサービスである複数の仮想サービスで構成され、
   前記１以上のサービスの各々は、出力インターフェースを有し、
   前記複数の仮想サービスのうち、前記１以上のサービスにそれぞれ対応する１以上の仮想サービスの各々について、当該仮想サービスが有する出力インターフェースは、前記他サービスリクエスト送信ポリシーに基づく設定がされた出力インターフェースとしてのモジュールである他サービスリクエスト部である、
   シミュレーション装置。
9. 下記の（ａ１）ないし（ａ３）の情報、
   （ａ１）複数のサービスで構成されサービス間でリクエストが送受信されることで当該複数のサービスが連携してエンドユーザーからのリクエストに従う処理を実行するサービスシステムにおける各サービス間の依存関係を記述したシステム構成、
   （ａ２）前記複数のサービスのうちの１以上のサービスの各々について下記の（ａ２１）および（ａ２２）を記述した他サービスリクエスト送信ポリシー、
   （ａ２１）当該サービスの依存先であるが故にリクエスト送信先となるサービスにおける障害有無と処理速度とのうちの少なくとも１つである処理状況に関する条件、
   （ａ２２）当該条件が満たされたとした場合の当該サービスの変更後の処理内容と変更後のリクエスト送信先との少なくとも１つである処理変更、
   （ａ３）前記サービスシステムに前記エンドユーザーとして送信するリクエストの内容と当該リクエストの送信レートとを記述したリクエスト生成ポリシー、
   を格納した記憶部と、
   下記の処理、
   （Ａ）前記システム構成、前記他サービスリクエスト送信ポリシー、および、前記リクエスト生成ポリシーを入力し、
   （Ｂ）前記リクエスト生成ポリシーに基づくリクエストが前記リクエスト生成ポリシーに基づく送信レートで到着したとした場合の前記サービスシステムの挙動であるシステム挙動のシミュレーションを、前記システム構成および前記他サービスリクエスト送信ポリシーに基づき実行し、
   （Ｃ）当該シミュレーションの実行結果としての前記システム挙動を表す情報であるシミュレーション結果情報を、出力する、
   を実行するシミュレーション部と
   を備え、
   前記シミュレーション部は、（Ｂ）のシミュレーションにおいて、
   前記システム構成および前記他サービスリクエスト送信ポリシーに基づき、前記サービスシステムが仮想化されたシステムである仮想システムを構築し、
   前記リクエスト生成ポリシーに従う内容のリクエストを、前記リクエスト生成ポリシーに従う送信レートで前記エンドユーザーとして前記仮想システムに送信し、
   （Ｂ）のシミュレーションの実行中であって、前記仮想システムの構築後に、
   前記リクエスト生成ポリシーの変更後のポリシーを受け付け、
   当該変更後のポリシーに従う内容のリクエストを、当該変更後のポリシーに従う送信レートで前記エンドユーザーとして前記仮想システムに送信する、
   シミュレーション装置。
10. 下記の（ａ１）ないし（ａ３）の情報、
    （ａ１）複数のサービスで構成されサービス間でリクエストが送受信されることで当該複数のサービスが連携してエンドユーザーからのリクエストに従う処理を実行するサービスシステムにおける各サービス間の依存関係を記述したシステム構成、
    （ａ２）前記複数のサービスのうちの１以上のサービスの各々について下記の（ａ２１）および（ａ２２）を記述した他サービスリクエスト送信ポリシー、
    （ａ２１）当該サービスの依存先であるが故にリクエスト送信先となるサービスにおける障害有無と処理速度とのうちの少なくとも１つである処理状況に関する条件、
    （ａ２２）当該条件が満たされたとした場合の当該サービスの変更後の処理内容と変更後のリクエスト送信先との少なくとも１つである処理変更、
    （ａ３）前記サービスシステムに前記エンドユーザーとして送信するリクエストの内容と当該リクエストの送信レートとを記述したリクエスト生成ポリシー、
    を格納した記憶部と、
    下記の処理、
    （Ａ）前記システム構成、前記他サービスリクエスト送信ポリシー、および、前記リクエスト生成ポリシーを入力し、
    （Ｂ）前記リクエスト生成ポリシーに基づくリクエストが前記リクエスト生成ポリシーに基づく送信レートで到着したとした場合の前記サービスシステムの挙動であるシステム挙動のシミュレーションを、前記システム構成および前記他サービスリクエスト送信ポリシーに基づき実行し、
    （Ｃ）当該シミュレーションの実行結果としての前記システム挙動を表す情報であるシミュレーション結果情報を、出力する、
    を実行するシミュレーション部と
    を備え、
    前記システム構成が含む１以上の情報要素は、前記システム構成に含める情報要素の入力を受け付ける１以上のＵＩ（User Interface）経由で入力された情報要素であり、
    前記１以上のＵＩは、
    １又は複数のサービステンプレートから１以上のサービステンプレートの選択を受け付ける第１のＵＩと、
    前記第１のＵＩから選択された１以上のサービステンプレートにそれぞれ対応した１以上のオブジェクトを表示し当該１以上のオブジェクトの依存関係の指定を受け付ける第２のＵＩと、
    当該１以上のオブジェクトのうちの選択されたオブジェクトに対応したサービステンプレートに対する１以上の値の入力を受け付ける第３のＵＩと
    を含み、
    前記複数のサービスの少なくとも１つは、前記第３のＵＩを介して入力された１以上の値が設定されたサービステンプレートに基づくサービスである、
    シミュレーション装置。
11. （Ａ）下記の（ａ１）ないし（ａ３）の情報を入力し、
    （ａ１）複数のサービスで構成されサービス間でリクエストが送受信されることで当該複数のサービスが連携してエンドユーザーからのリクエストに従う処理を実行するサービスシステムにおける各サービス間の依存関係を記述したシステム構成、
    （ａ２）前記複数のサービスのうちの１以上のサービスの各々について下記の（ａ２１）および（ａ２２）を記述した他サービスリクエスト送信ポリシー、
    （ａ２１）当該サービスの依存先であるが故にリクエスト送信先となるサービスにおける障害有無と処理速度とのうちの少なくとも１つである処理状況に関する条件、
    （ａ２２）当該条件が満たされたとした場合の当該サービスの変更後の処理内容と変更後のリクエスト送信先との少なくとも１つである処理変更、
    （ａ３）前記サービスシステムに前記エンドユーザーとして送信するリクエストの内容と当該リクエストの送信レートとを記述したリクエスト生成ポリシー、
    （Ｂ）前記リクエスト生成ポリシーに基づくリクエストが前記リクエスト生成ポリシーに基づく送信レートで到着したとした場合の前記サービスシステムの挙動であるシステム挙動のシミュレーションを、前記システム構成および前記他サービスリクエスト送信ポリシーに基づき実行し、
    （Ｃ）当該シミュレーションの実行結果としての前記システム挙動を表す情報であるシミュレーション結果情報を、出力し、
    （Ｂ）のシミュレーションの実行中に、
    前記他サービスリクエスト送信ポリシー及び前記リクエスト生成ポリシーのうちの少なくとも１つの変更後のポリシーを受け付け、
    当該変更後のポリシーを、前記シミュレーションを停止させることなく反映し、
    当該反映後のポリシーに従い、当該シミュレーションを継続する、
    シミュレーション方法。
12. （Ａ）下記の（ａ１）ないし（ａ３）の情報を入力し、
    （ａ１）複数のサービスで構成されサービス間でリクエストが送受信されることで当該複数のサービスが連携してエンドユーザーからのリクエストに従う処理を実行するサービスシステムにおける各サービス間の依存関係を記述したシステム構成、
    （ａ２）前記複数のサービスのうちの１以上のサービスの各々について下記の（ａ２１）および（ａ２２）を記述した他サービスリクエスト送信ポリシー、
    （ａ２１）当該サービスの依存先であるが故にリクエスト送信先となるサービスにおける障害有無と処理速度とのうちの少なくとも１つである処理状況に関する条件、
    （ａ２２）当該条件が満たされたとした場合の当該サービスの変更後の処理内容と変更後のリクエスト送信先との少なくとも１つである処理変更、
    （ａ３）前記サービスシステムに前記エンドユーザーとして送信するリクエストの内容と当該リクエストの送信レートとを記述したリクエスト生成ポリシー、
    （Ｂ）前記リクエスト生成ポリシーに基づくリクエストが前記リクエスト生成ポリシーに基づく送信レートで到着したとした場合の前記サービスシステムの挙動であるシステム挙動のシミュレーションを、前記システム構成および前記他サービスリクエスト送信ポリシーに基づき実行し、
    （Ｃ）当該シミュレーションの実行結果としての前記システム挙動を表す情報であるシミュレーション結果情報を、出力し、
    （Ｂ）のシミュレーションは、前記システム構成および前記他サービスリクエスト送信ポリシーに基づき、前記サービスシステムが仮想化されたシステムである仮想システムを構築することを含み、
    前記仮想システムは、前記複数のサービスが仮想化された複数のサービスである複数の仮想サービスで構成され、
    前記１以上のサービスの各々は、出力インターフェースを有し、
    前記複数の仮想サービスのうち、前記１以上のサービスにそれぞれ対応する１以上の仮想サービスの各々について、当該仮想サービスが有する出力インターフェースは、前記他サービスリクエスト送信ポリシーに基づく設定がされた出力インターフェースとしてのモジュールである他サービスリクエスト部である、
    シミュレーション方法。
13. （Ａ）下記の（ａ１）ないし（ａ３）の情報を入力し、
    （ａ１）複数のサービスで構成されサービス間でリクエストが送受信されることで当該複数のサービスが連携してエンドユーザーからのリクエストに従う処理を実行するサービスシステムにおける各サービス間の依存関係を記述したシステム構成、
    （ａ２）前記複数のサービスのうちの１以上のサービスの各々について下記の（ａ２１）および（ａ２２）を記述した他サービスリクエスト送信ポリシー、
    （ａ２１）当該サービスの依存先であるが故にリクエスト送信先となるサービスにおける障害有無と処理速度とのうちの少なくとも１つである処理状況に関する条件、
    （ａ２２）当該条件が満たされたとした場合の当該サービスの変更後の処理内容と変更後のリクエスト送信先との少なくとも１つである処理変更、
    （ａ３）前記サービスシステムに前記エンドユーザーとして送信するリクエストの内容と当該リクエストの送信レートとを記述したリクエスト生成ポリシー、
    （Ｂ）前記リクエスト生成ポリシーに基づくリクエストが前記リクエスト生成ポリシーに基づく送信レートで到着したとした場合の前記サービスシステムの挙動であるシステム挙動のシミュレーションを、前記システム構成および前記他サービスリクエスト送信ポリシーに基づき実行し、
    （Ｃ）当該シミュレーションの実行結果としての前記システム挙動を表す情報であるシミュレーション結果情報を、出力し、
    （Ｂ）のシミュレーションにおいて、
    前記システム構成および前記他サービスリクエスト送信ポリシーに基づき、前記サービスシステムが仮想化されたシステムである仮想システムを構築し、
    前記リクエスト生成ポリシーに従う内容のリクエストを、前記リクエスト生成ポリシーに従う送信レートで前記エンドユーザーとして前記仮想システムに送信し、
    （Ｂ）のシミュレーションの実行中であって、前記仮想システムの構築後に、
    前記リクエスト生成ポリシーの変更後のポリシーを受け付け、
    当該変更後のポリシーに従う内容のリクエストを、当該変更後のポリシーに従う送信レートで前記エンドユーザーとして前記仮想システムに送信する、
    シミュレーション方法。
14. （Ａ）下記の（ａ１）ないし（ａ３）の情報を入力し、
    （ａ１）複数のサービスで構成されサービス間でリクエストが送受信されることで当該複数のサービスが連携してエンドユーザーからのリクエストに従う処理を実行するサービスシステムにおける各サービス間の依存関係を記述したシステム構成、
    （ａ２）前記複数のサービスのうちの１以上のサービスの各々について下記の（ａ２１）および（ａ２２）を記述した他サービスリクエスト送信ポリシー、
    （ａ２１）当該サービスの依存先であるが故にリクエスト送信先となるサービスにおける障害有無と処理速度とのうちの少なくとも１つである処理状況に関する条件、
    （ａ２２）当該条件が満たされたとした場合の当該サービスの変更後の処理内容と変更後のリクエスト送信先との少なくとも１つである処理変更、
    （ａ３）前記サービスシステムに前記エンドユーザーとして送信するリクエストの内容と当該リクエストの送信レートとを記述したリクエスト生成ポリシー、
    （Ｂ）前記リクエスト生成ポリシーに基づくリクエストが前記リクエスト生成ポリシーに基づく送信レートで到着したとした場合の前記サービスシステムの挙動であるシステム挙動のシミュレーションを、前記システム構成および前記他サービスリクエスト送信ポリシーに基づき実行し、
    （Ｃ）当該シミュレーションの実行結果としての前記システム挙動を表す情報であるシミュレーション結果情報を、出力し、
    前記システム構成が含む１以上の情報要素は、前記システム構成に含める情報要素の入力を受け付ける１以上のＵＩ（User Interface）経由で入力された情報要素であり、
    前記１以上のＵＩは、
    １又は複数のサービステンプレートから１以上のサービステンプレートの選択を受け付ける第１のＵＩと、
    前記第１のＵＩから選択された１以上のサービステンプレートにそれぞれ対応した１以上のオブジェクトを表示し当該１以上のオブジェクトの依存関係の指定を受け付ける第２のＵＩと、
    当該１以上のオブジェクトのうちの選択されたオブジェクトに対応したサービステンプレートに対する１以上の値の入力を受け付ける第３のＵＩと
    を含み、
    前記複数のサービスの少なくとも１つは、前記第３のＵＩを介して入力された１以上の値が設定されたサービステンプレートに基づくサービスである、
    シミュレーション方法。

Images