JP2020173650A - プログラム運用システム、プログラム運用方法 - Google Patents

Abstract

【課題】１または複数のプログラムを実行して提供されるサービスにおいて、変更されたプログラムの影響を評価する。【解決手段】１または複数のマイクロサービスを実行して提供されるサービスにおいて、更新前のマイクロサービスを含む更新前サービスフローと、更新後のマイクロサービスを含む更新後サービスフローとを実行し、更新前サービスフローの実行結果と更新後サービスフローの実行結果とを出力するマイクロサービス管理部と、更新前サービスフローの実行結果と更新後サービスフローの実行結果とを評価し、当該評価の結果が所定の関係を満たすサービスフローとして、更新前サービスフローまたは更新後サービスフローのいずれかを選択するサービス更新分析処理部と、を備える。【選択図】図７

Description

本発明は、プログラム運用システム、プログラム運用方法に関する。

近年、ＳａａＳ（Software as a Service）技術の発達により、機械/深層学習による新サービス/ソフトウェアがＷｅｂサービスとして提供されつつある。特に、Ｗｅｂサービスを、第三者の提供するマイクロサービス(プログラム)のマッシュアップにより構築している場合、個別のマイクロサービスが新たな機能追加や修正によりバージョンアップする際には、マイクロサービスの追加、修正される機能のテストと、その機能のＷｅｂサービスに与える影響の評価を行う必要がある。

プログラムのバージョンアップの際のテストに関する従来技術として、特許文献１が存在する。特許文献１では、複数のモジュールから構成される業務システムのバージョンアップの効率的な手法を提供することを目的としている。この目的を達成するために、特許文献１には、更新される機能毎に関連する各モジュールの変更有無を管理し、更新機能と変更モジュールを対応付けて記憶することで、変更があった有効なモジュールを特定している。

特開2013−228970号公報

マイクロサービスのマッシュアップで構築されたＷｅｂサービスにおいては、マイクロサービスがバージョンアップされ、機能が追加ないし変更される場合がある。このような場合、バージョンアップされたマイクロサービスが、Ｗｅｂサービス全体に与える不具合や影響をテスト検証する必要がある。また、Ｗｅｂサービスは複数種類提供され、それぞれ異なる評価軸（ＫＰＩ：Key Performance Indicator）を有するため、マイクロサービスのバージョンアップの是非が、Ｗｅｂサービスによって異なる可能性がある。

特許文献１においては、更新される機能に関連するモジュールを特定し、モジュールの変更を管理するが、変更されたモジュールの影響を評価することは考慮されておらず、これを如何に行うかは開示されていない。また、モジュールが複数の機能に関連する場合についても考慮されていない。

本発明は、１または複数のプログラムを実行して提供されるサービスにおいて、変更されたプログラムの影響を評価することが可能なプログラム運用システム、プログラム運用方法を提供することを目的とする。

本発明の一態様にかかるプログラム運用システムは、１または複数のマイクロサービスを実行して提供されるサービスにおいて、更新前のマイクロサービスを含む更新前サービスフローと、更新後のマイクロサービスを含む更新後サービスフローとを実行し、前記更新前サービスフローの実行結果と前記更新後サービスフローの実行結果とを出力するマイクロサービス管理部と、前記更新前サービスフローの実行結果と前記更新後サービスフローの実行結果とを評価し、当該評価の結果が所定の関係を満たすサービスフローとして、前記更新前サービスフローまたは前記更新後サービスフローのいずれかを選択するサービス更新分析処理部と、を備えることを特徴とするプログラム運用システムとして構成される。

本発明の一態様によれば、１または複数のプログラムを実行して提供されるサービスにおいて、変更されたプログラムの影響を評価することができる。

本実施形態のシステム構成を示す図 本実施形態の対象の処理概要を示す図 本実施形態のマイクロサービス管理テーブル 本実施形態のサービスフロー評価処理管理テーブル 本実施形態のサービスフロー管理テーブル 本実施形態のＷｅｂサービス管理テーブル 本実施形態のフローチャート 本実施形態の更新後のサービスフロー管理テーブル 本実施形態の更新後のＷｅｂサービス管理テーブル 本実施形態の更新後のマイクロサービス管理テーブル

以下、図面を参照して本発明の実施形態を説明する。以下の記載および図面は、本発明を説明するための例示であって、説明の明確化のため、適宜、省略および簡略化がなされている。本発明は、他の種々の形態でも実施する事が可能である。特に限定しない限り、各構成要素は単数でも複数でも構わない。

図面において示す各構成要素の位置、大きさ、形状、範囲などは、発明の理解を容易にするため、実際の位置、大きさ、形状、範囲などを表していない場合がある。このため、本発明は、必ずしも、図面に開示された位置、大きさ、形状、範囲などに限定されない。

以下の説明では、「テーブル」、「リスト」等の表現にて各種情報を説明することがあるが、各種情報は、これら以外のデータ構造で表現されていてもよい。データ構造に依存しないことを示すために「ＸＸテーブル」、「ＸＸリスト」等を「ＸＸ情報」と呼ぶことがある。識別情報について説明する際に、「識別情報」、「識別子」、「名」、「ＩＤ」、「番号」等の表現を用いるが、これらについてはお互いに置換が可能である。

同一あるいは同様な機能を有する構成要素が複数ある場合には、同一の符号に異なる添字を付して説明する場合がある。ただし、これらの複数の構成要素を区別する必要がない場合には、添字を省略して説明する場合がある。

また、以下の説明では、プログラムを実行して行う処理を説明する場合があるが、プログラムは、プロセッサ（例えばＣＰＵ、ＧＰＵ）によって実行されることで、定められた処理を、適宜に記憶資源（例えばメモリ）および／またはインターフェースデバイス（例えば通信ポート）等を用いながら行うため、処理の主体がプロセッサとされてもよい。同様に、プログラムを実行して行う処理の主体が、プロセッサを有するコントローラ、装置、システム、計算機、ノードであってもよい。プログラムを実行して行う処理の主体は、演算部であれば良く、特定の処理を行う専用回路（例えばＦＰＧＡやＡＳＩＣ）を含んでいてもよい。

プログラムは、プログラムソースから計算機のような装置にインストールされてもよい。プログラムソースは、例えば、プログラム配布サーバまたは計算機が読み取り可能な記憶メディアであってもよい。プログラムソースがプログラム配布サーバの場合、プログラム配布サーバはプロセッサと配布対象のプログラムを記憶する記憶資源を含み、プログラム配布サーバのプロセッサが配布対象のプログラムを他の計算機に配布してもよい。また、以下の説明において、２以上のプログラムが１つのプログラムとして実現されてもよいし、１つのプログラムが２以上のプログラムとして実現されてもよい。

図１は、本実施形態のプログラム運用システムの構成を示す図である。図１に示すように、プログラム運用システム１０００は、マイクロサービス管理サーバ１０と、サービスフロー管理サーバ１１と、Ｗｅｂサービス稼働サーバ１２と、マイクロサービス稼働サーバ１３とを備え、それぞれがネットワークＮを介して接続される。アプリＡ１４１、アプリＢ１４２、アプリＣ１４３は、Ｗｅｂサービス実行部１２０で実行されるＷｅｂサービスを利用するユーザのコンピュータにインストールされたアプリケーションである。

本システムが有するサーバやコンピュータは、ハードウェアとしては、ＨＤＤ（Hard Disk Drive）やＳＳＤ（Solid State Drive）等の記憶装置や、ＣＰＵ（Central Processing Unit）やＲＡＭ（Random Access Memory）、ＲＯＭ（Read Only Memory）を有した演算装置を有した、一般的な情報処理装置が有する構成を備えている。また、各サーバが有する機能部の機能は、プログラムの実行により実現される。例えば、ＣＰＵが、ＲＯＭからプログラムを読み出して実行することにより、各部の機能が実現される。上記プログラムは、ＵＳＢ(Universal Serial Bus)メモリ等の記憶媒体から読み出されたり、ネットワークを介した他のコンピュータからダウンロードする等して、各サーバに提供されてもよい。

前記Ｗｅｂサービスは、サービスフロー管理部１１０で管理されるサービスフローに従って動作するサービスである。例えば、Ｎｏｄｅ−ＲＥＤなどに代表されるビジュアルプログラミングツールによって、いわゆるプログラム処理を表すノードの接続によって定義されるプログラムの処理フローに相当する。処理フローは、Ｎｏｄｅ−ＲＥＤであれば、Ｆｌｏｗ．ｊｓｏｎといった所定のフォーマットで記述されたファイル形式で定義されており、このファイルを参照し、解析、加工することで、下記に示す処理が実現可能である。また、Ｎｏｄｅ−ＲＥＤで定義したプログラムの処理フローは、Ｎｏｄｅ−ＲＥＤ上でデプロイされることにより、実際に動作するＷｅｂサービスとして利用可能となる。また、マイクロサービスは、例えば仮想化環境であるＤｏｃｋｅｒ（登録商標）のコンテナとして実現される。

したがって、例えば前記マイクロサービス管理サーバ１０は、前記Ｄｏｃｋｅｒコンテナを管理する機能を提供するサーバである。前記サービスフロー管理サーバ１１は、前記処理フローを管理する機能を提供するサーバである。前記Ｗｅｂサービス稼働サーバ１２は、Ｎｏｄｅ−ＲＥＤが稼働するサーバである。前記マイクロサービス稼働サーバ１４は、Ｄｏｃｋｅｒが稼働するサーバとして実装することが可能である。

本実施形態におけるサービスフローは、一つ以上のマイクロサービスの処理を含み、前記マイクロサービスは、たとえばマイクロサービス実行部１５０で稼働するサービスをフロー中で呼び出すものである。

前記マイクロサービスは、マイクロサービス管理サーバ１０のマイクロサービス管理部１００で管理されている。そして、マイクロサービス管理部１００は、マイクロサービスのバージョンアップなど更新が発生した場合に、更新を反映したサービスフロー(更新サービスフロー)を一時的に生成し、更新前のサービスフローと同じ入力で並列動作させるフローを生成する。さらに、マイクロサービス管理部１００は、更新サービスフローの出力と、更新前のサービスフローの出力を比較評価するフローを追加したＷｅｂサービスをデプロイする。

そして、アプリから前記Ｗｅｂサービスが利用されるたびに、更新サービスフローと更新前のサービスフローが評価可能となる。評価の結果、更新サービスフローか、更新前フローのいずれか良いサービスフローが選択される。選択されたサービフローが新たにＷｅｂサービスとしてデプロイされ、サービスフロー管理テーブル４００、マイクロサービス管理テーブル２００が更新される。マクロサービス管理テーブル２００の更新の結果、旧バージョンのマイクロサービスであって、関連サービスが一つも無いマイクロサービスは削除される。

以下、この処理の詳細を、図面を用いて説明する。図２は、対象の処理の概要を示す図である。マイクロサービス実行部１５０で動作するサービスは、マイクロサービス管理部１００のマクロサービス管理テーブル２００で管理される。具体的には後述するが、本システムでは、マイクロサービス管理部１００が、１または複数のマイクロサービス（プログラム）を実行して提供されるサービスにおいて、更新前のマイクロサービスを含む更新前サービスフローと、更新後のマイクロサービスを含む更新後サービスフローとを実行し、更新前サービスフローの実行結果と更新後サービスフローの実行結果とを出力し、サービス評価更新処理部１３０のサービス更新分析処理部１３１が、更新前サービスフローの実行結果と更新後サービスフローの実行結果とを評価し、当該評価の結果が所定の関係を満たすサービスフローとして、更新前サービスフローまたは更新後サービスフローのいずれかを選択し、新たなサービスフローとして登録している。これにより、１または複数のプログラムを実行して提供されるサービスにおいて、変更されたプログラムの影響を評価することができ、例えば、プログラムに変更が生じた場合であっても、プログラムの変更前後のどちらのサービスが提供するサービスとして適しているのかを自動的に評価することができる。

また、サービス更新分析処理部１３１は、評価の結果が高いサービスフローを、上記評価の結果が所定の関係を満たすサービスフローとして選択するので、評価（例えば、ＫＰＩの値）が高いサービスフローを実行することにより、更新前のサービスよりも満足度が高いサービスを提供することができる。以下では、ＫＰＩの値が高いサービスフローを所定の関係を満たすサービスフローの例として記載しているが、ＫＰＩの値が低い場合や、ＫＧＩ（Key Goal Indicator）等の他の指標の値の高さにより、更新前後のサービスフローが所定の関係を満たすか否かを判定してもよい。

図３に、マイクロサービス管理テーブル２００の構成図を示す。図３に示すように、マクロサービス管理テーブル２００は、マイクロサービス名２０１、プログラムのバージョンを示すプログラムバージョン２０２、プログラムの学習データやパラメータセットなどを示すモデルバージョン２０３、当該マイクロサービスを利用しているサービスフローを示す関連サービス２０４から構成される。例えば、図中のマイクロサービスＭＣ＿Ａは、プログラムバージョン１．０、モデルバージョン無し、関連サービスがサービスＡ、サービスＢ、サービスＡ１であることを示す。

サービスフロー管理部１１０では、前記マイクロサービスを組み合わせて構築されたサービスフローをサービスフロー管理テーブル４００で管理する。

図５に、サービスフロー管理テーブル４００の構成図を示す。図に示すように、サービスフロー名４０１、サービスフローバージョン４０２、フロー情報４０３から構成される。例えば、サービスＳＶ＿Ａ（サービスＡ）は、バージョン１．０であり、フローはマイクロサービスＭＣ＿Ａ、ＭＣ＿Ｂ、ＭＣ＿Ｃの順番に動作する構成になっている。

サービスフロー管理部１１０で管理されたサービスフローは、Ｗｅｂサービス実行部１２０にデプロイされることで、アプリから利用可能なＷｅｂサービスとして動作可能となる。

各サービスフローは、その処理結果の評価をする処理が定義されており、その処理がサービス評価更新処理部１３０のサービスフロー評価処理管理テーブル３００に管理されている。

図４に、サービスフロー評価処理管理テーブル３００の構成図を示す。図に示すように、サービスフロー名３０１、評価処理指標であるＫＰＩ３０２、評価処理名３０３から構成される。例えば、サービスＳＶ＿Ａは、検知率で評価する処理であり、評価処理ＥＶ＿Ａ１で評価することを示している。サービスフローには複数の評価処理を用意することも可能であり、Ｗｅｂサービスとしてデプロイされる際に評価処理を選択する。
デプロイされたＷｅｂサービスは、Ｗｅｂサービス管理テーブル５００によって管理される。

図６に、Ｗｅｂサービス管理テーブル５００の構成図を示す。図に示すように、Ｗｅｂサービス管理テーブル５００は、Ｗｅｂサービス名５０１と、サービスフロー名４０１と、サービスフローバージョン４０２と、評価処理３０３から構成される。たとえば、ＷｅｂサービスのサービスＡは、バージョン１．０のサービスフローＳＶ_Ａをデプロイしたものであり、評価処理はＥＶ＿Ａ１が実行される。

図２の、マイクロサービス実行部１５０では、ＭＣ＿Ａ、ＭＣ＿Ｂ、ＭＣ＿Ｃ、ＭＣ＿Ｄが稼働中であり、新たにＭＣ＿Ｂのマイクロサービスの更新版ＭＣ＿Ｂ１が提供された状況を示している。

以下、さらに図７のフローチャートを用いて、本実施例形態の処理の詳細を説明する。
図７では、更新されたマイクロサービスを含む全てのサービスについて実行するものとする。

マイクロサービス管理部１００は、マイクロサービスＭＣ＿Ｂの更新バージョンであるマイクロサービスＭＣ＿Ｂ１の実行を検知する。検知手法としては、例えば、マイクロサービス開発者が更新した更新マイクロサービスを、マイクロサービス管理部１００が、マイクロサービス管理テーブル２００に登録する方法や、Ｇｉｔなどのバージョン管理システムと連携して更新を検知する方法などがある（Ｓｔｅｐ１）。

つぎに、マイクロサービス管理部１００は、マイクロサービス管理テーブル２００に更新検知されたマイクロサービスを登録する。図３の例では、マイクロサービス管理部１００がＭＣ＿Ｂの更新を検知し、更新版のＭＣ＿Ｂ１を登録した状態であり、更新版のプログラムバージョン、モデルバージョンがセットされる（Ｓｔｅｐ２）。

次に、マイクロサービス管理部１００は、マイクロサービス管理テーブル２００より、更新検知されたマイクロサービスＭＣ＿Ｂの関連Ｗｅｂサービスの有無や構成をチェックする。図３の例では、マイクロサービス管理部１００は、ＭＣ＿Ｂの関連Webサービスとして、サービスＡ、サービスＢ、サービスＣが存在することを確認する（Ｓｔｅｐ３）。

マイクロサービス管理部１００は、それぞれのＷｅｂサービスのサービスフローとバージョンに相当するサービスフロー情報について、処理を行う。未処理の関連Ｗｅｂサービスがある場合（Ｓｔｅｐ４；Ｙｅｓ）は、Ｓｔｅｐ５に進み、未処理の関連Ｗｅｂサービスが無い場合（Ｓｔｅｐ４；Ｎｏ）は、処理を終了する（Ｓｔｅｐ４）。

以下、未処理の関連ＷｅｂサービスがサービスＡのケースを例に説明する。マイクロサービス管理部１００は、図６に示したＷｅｂサービス管理テーブル５００を参照し、サービスＡのサービスフローとしてＳＶ＿Ａ、Ｖｅｒ．として１．０を読み出す。マイクロサービス管理部１００は、サービスフロー管理テーブル４００を参照し、ＭＣ＿ＢをＭＣ＿Ｂ１に変更した更新版サービスフローを生成し、当該更新版サービスフローをサービスフロー管理テーブル４００に登録する。図５では、マイクロサービス管理部１００は、サービスフローＳＶ＿Ａ１をＳＶ＿Ａが更新されたフローとして登録する。更新されたフロー情報は、ＭＣ＿Ａ→ＭＣ＿Ｂ１→ＭＣ＿Ｃとなる（Ｓｔｅｐ５）。

つぎに、マイクロサービス管理部１００は、Ｓｔｅｐ５で生成したサービスフローのＷｅｂサービスを生成し、当該ＷｅｂサービスをＷｅｂサービス管理テーブル５００に登録する。ＳＶ_Ａ１のケースでは、マイクロサービス管理部１００は、図６のＷｅｂサービス管理テーブル５００のサービスＡ１を、更新されたＷｅｂサービスとして登録する。マイクロサービス管理部１００は、評価処理としては、更新前のサービスＡと同じＥＶ＿Ａ１を登録し、サービスフローとしてＳＶ＿Ａ１を登録する。また、マイクロサービス管理部１００は、Ｗｅｂサービスが生成された場合は、マイクロサービス管理テーブル２００の関連Ｗｅｂサービスリストも更新する。図３では、マイクロサービス管理部１００は、マイクロサービスＭＣ＿Ａ、ＭＣ＿Ｂ１、ＭＣ＿Ｃに、上記更新されたＷｅｂサービスであるサービスＡ１を追記する（Ｓｔｅｐ６）。

つぎに、マイクロサービス管理部１００は、Ｓｔｅｐ６で生成した更新Ｗｅｂサービスと、もとのＷｅｂサービスを比較評価する処理を追加する。比較評価の対象となるサービスがサービスＡ１とサービスＡの場合、マイクロサービス管理部１００は、それぞれのサービスの結果を評価処理ＥＶ＿Ａ１に入力する。評価処理は、サービス結果を所定のＫＰＩで評価する処理と、それぞれのサービスの評価結果を比較分析する処理と、分析結果をログに記録する処理を有する（Ｓｔｅｐ７）。

Ｓｔｅｐ６で更新ＷｅｂサービスともとのＷｅｂサービスの比較評価処理がデプロイされた状況でもアプリはもとのＷｅｂサービスを引き続き利用可能であるが、Ｗｅｂサービス実行部１２０は、更新前のＷｅｂサービス（例えば、サービスＡ）と更新後のＷｅｂサービス（例えば、サービスＡ１）を並列して処理を実行し、両者の実行結果および両者の比較結果をログに蓄積する。サービス更新分析処理部１３１は、所定の利用回数や、所定期間経過後にログを分析していずれのサービスが優れているかを評価し、その結果、Ｗｅｂサービスを更新してよいか否かを判定する（Ｓｔｅｐ８）。

上記ログの分析においては、マイクロサービス管理部１００が更新前サービスフローと更新後サービスフローとを所定の回数実行し、以下の処理において、サービス更新分析処理部１３１が、所定の回数の実行により得られた更新前サービスフローの実行結果の評価の統計値と更新後サービスフローの実行結果の評価の統計値とを用いて、評価の結果が高いサービスフローを選択し、新たなサービスフローとして登録することとしてもよい。上記統計値としては、平均値や中央値をはじめ様々な統計値を用いることができる。

サービス更新分析処理部１３１は、評価の結果、もとのＷｅｂサービスが優れており、Ｗｅｂサービスを更新してよいと判定しなかった場合は（Ｓｔｅｐ９；Ｎｏ）、更新キャンセル処理（Ｓｔｅｐ１０）を実行する。一方、サービス更新分析処理部１３１は、もとのＷｅｂサービスが優れておらず、Ｗｅｂサービスを更新してよいと判定した場合は（Ｓｔｅｐ９；Ｙｅｓ）、更新処理（Ｓｔｅｐ１１）に進む（Ｓｔｅｐ９）。

更新キャンセル処理では、サービス更新分析処理部１３１は、更新版Ｗｅｂサービスと比較評価処理を削除する。あわせてＷｅｂサービス管理テーブル５００の該当Ｗｅｂサービス、サービスフロー管理テーブル４００の該当サービスフローの項目を削除する。また、サービス更新分析処理部１３１は、マイクロサービス管理テーブル２００の関連Ｗｅｂサービスリストから該当Ｗｅｂサービスを削除する。図３では、サービス更新分析処理部１３１は、ＭＣ＿Ａ、ＭＣ＿Ｂ１、ＭＣ＿Ｃの関連ＷｅｂサービスリストからサービスＡ１を削除する（Ｓｔｅｐ１０）。

更新処理では、サービス更新分析処理部１３１は、もとのＷｅｂサービスと比較評価処理を削除する。また、サービス更新分析処理部１３１は、更新版ＷｅｂサービスのサービスＡ１も一旦削除し、Ｗｅｂサービス管理テーブル５００のサービスＡを削除し、サービスＡ１をサービスＡに変更する。さらに、サービス更新分析処理部１３１は、サービスフロー管理テーブル４００のＳＶ＿Ａ１をＳＶ＿Ａに変更、バージョンをもとのサービスフローのバージョンをインクリメントしたバージョンで登録後、サービスフローＳＶ＿Ａのバージョン１．１をＷｅｂサービスＡとしてデプロイする。

図８に更新処理後のサービスフロー管理テーブルを示す。図９に更新処理後のＷｅｂサービス管理テーブルを示す。図８では、サービス更新分析処理部１３１は、更新後のサービスフローＳＶ＿Ａ１がＳＶ＿Ａのバージョン１．１として登録していることがわかる。また、図９では、サービス更新分析処理部１３１は、更新後のＷｅｂサービスＡ１が削除され、ＷｅｂサービスＡがバージョン１．１として登録していることがわかる。さらに、サービス更新分析処理部１３１は、マイクロサービス管理テーブル２００の関連ＷｅｂサービスリストのサービスＡを削除し、サービスＡ１をサービスＡに変更する。図１０に更新処理後のマイクロサービス管理テーブルを示す。図１０では、サービスＡが削除されてサービスＡ１がサービスＡに変更された結果、例えば、マイクロサービスＭＣ＿Ｃの関連ＷｅｂサービスリストにはサービスＡ、サービスＣのみが登録されることとなったことがわかる（Ｓｔｅｐ１１）。

Ｓｔｅｐ１０もしくはＳｔｅｐ１１終了後、マイクロサービス管理部１００は、マイクロサービス管理テーブル２００を更新する。マイクロサービス管理部１００は、マクロサービス管理テーブル２００において、旧バージョンのマイクロサービスで、関連Ｗｅｂサービスリストが空欄である、すなわち利用しているＷｅｂサービスが存在しない場合は、前記マイクロサービスのレコードを削除する（Ｓｔｅｐ１２）。

このように、サービス更新分析処理部１３１は、選択されたサービスフロー（例えば、ＳＶ＿Ａ）に含まれるマイクロサービス（例えば、ＭＣ＿Ｂ）を含む複数のサービスのうち、評価を行ったサービス（例えば、ＳＶ＿Ａ）以外の他のサービス（例えば、ＳＶ＿Ｂ）についての評価を行って、変更されたマイクロサービス（例えば、ＭＣ＿Ｂ）が他のサービス（例えば、ＳＶ＿Ｂ等のＭＣ＿Ｂを含むサービスフロー）からすべて選択されなくなった（すなわち、変更前のＭＣ＿Ｂが高い評価を得られなくなった）場合に、更新前サービスフローまたは更新後サービスフローのうちの選択がされなかったサービスフロー（例えば、ＫＰＩの値が低いと評価されたサービスフロー）を、プログラム運用システム１０００から削除する。したがって、あるサービスに含まれるマイクロサービスを変更する場合に、他のサービスにおいて使用されている上記変更されたマイクロサービスや当該マイクロサービスを含むサービスを誤って削除することを排除することができる。

以上述べたように、Ｓｔｅｐ５からＳｔｅｐ１２の処理によって一つのＷｅｂサービスについての処理が完了した。次に、再度Ｓｔｅｐ４の処理に移行して未処理のＷｅｂサービスがなくなるまで処理を繰り返す。

このように、本実施例では、マイクロサービス管理部１００が、マイクロサービスのバージョン毎に、関連するＷｅｂサービスの有無を、Ｗｅｂサービスの構成情報を分析して判断し、その結果をテーブルとして記録することで管理し、サービスフロー管理部１１０が、Ｗｅｂサービスを構成するマイクロサービスの処理の流れを示すサービスフローの情報を表すサービスフロー構成情報を管理し、Ｗｅｂサービス実行部１２０が、サービスフロー構成情報に基づいてサービスデプロイして実行可能とするシステムにおいて、マイクロサービスのバージョン更新が生じた場合、そのマイクロサービスのすべての別バージョンに関連する実行中のＷｅｂサービスに対して、バージョン更新したマイクロサービスに入れ替えた更新サービスフローを構成し、デプロイする。本システムでは、さらに当該Ｗｅｂサービスを評価するＫＰＩを算出し、もとのＷｅｂサービスと更新Ｗｅｂサービスを比較する処理をデプロイする。そして、ユーザから、Ｗｅｂサービスを介してサービスリクエストを受け付けた場合に、本システムは、当該リクエストに対して、もとのＷｅｂサービスと、更新Ｗｅｂサービスの両方の処理を実行し、両サービスの結果からＫＰＩを算出し、比較結果をログに記録する。

そして、所定の回数サービスリクエストが実行された後、蓄積されたログを分析して、ＫＰＩが悪化していない場合は、もとのＷｅｂサービスと更新Ｗｅｂサービスを入れ替え、Ｗｅｂサービス構成情報テーブルと、サービスフロー構成情報を更新する。一方、ＫＰＩが悪化している場合は、更新Ｗｅｂサービスを削除する。これにより、例えば、Ｗｅｂサービスとして提供される業務サービスが、複数のサブプログラム、いわゆるマイクロサービスのマッシュアップで構築される際のサービスの更新する場合において、マイクロサービスのバージョン更新が生じた際に、そのマイクロサービスを活用しているＷｅｂサービスの品質を低下させずに管理することが可能になる。

１００…マイクロサービス管理部、２００…マイクロサービス管理テーブル、１１０…サービスフロー管理部、１２０…Ｗｅｂサービス実行部、１３０…サービス評価更新処理部、１４１〜１４３…アプリケーション、１５０…マイクロサービス実行部、３００…サービス評価処理管理テーブル、４００…サービスフロー管理テーブル、５００…Ｗｅｂサービス管理テーブル

Claims (8)

1. １または複数のマイクロサービスを実行して提供されるサービスにおいて、更新前のマイクロサービスを含む更新前サービスフローと、更新後のマイクロサービスを含む更新後サービスフローとを実行し、前記更新前サービスフローの実行結果と前記更新後サービスフローの実行結果とを出力するマイクロサービス管理部と、
   前記更新前サービスフローの実行結果と前記更新後サービスフローの実行結果とを評価し、当該評価の結果が所定の関係を満たすサービスフローとして、前記更新前サービスフローまたは前記更新後サービスフローのいずれかを選択するサービス更新分析処理部と、
   を備えることを特徴とするプログラム運用システム。
2. 請求項１に記載のプログラム運用システムであって、
   前記サービス更新分析処理部は、前記評価の結果が高いサービスフローを、前記評価の結果が所定の関係を満たすサービスフローとして選択する、
   ことを特徴とするプログラム運用システム。
3. 請求項２に記載のプログラム運用システムであって、
   前記マイクロサービス管理部は、前記更新前サービスフローと前記更新後サービスフローとを所定の回数実行し、
   前記サービス更新分析処理部は、前記所定の回数の実行により得られた前記更新前サービスフローの実行結果の評価の統計値と前記更新後サービスフローの実行結果の評価の統計値とを用いて、前記評価の結果が高いサービスフローを選択する、
   ことを特徴とするプログラム運用システム。
4. 請求項１に記載のプログラム運用システムであって、
   前記サービス更新分析処理部は、前記選択されたサービスフローに含まれるマイクロサービスを含む複数のサービスのうち、前記評価を行ったサービス以外の他のサービスについての評価を行って、前記マイクロサービスが前記他のサービスから選択されなくなった場合に、前記更新前サービスフローまたは前記更新後サービスフローのうちの選択がされなかったサービスフローを、前記プログラム運用システムから削除する、
   ことを特徴とするプログラム運用システム。
5. マイクロサービス管理部が、１または複数のマイクロサービスを実行して提供されるサービスにおいて、更新前のマイクロサービスを含む更新前サービスフローと、更新後のマイクロサービスを含む更新後サービスフローとを実行し、
   前記マイクロサービス管理部が、前記更新前サービスフローの実行結果と前記更新後サービスフローの実行結果とを出力し、
   サービス更新分析処理部が、前記更新前サービスフローの実行結果と前記更新後サービスフローの実行結果とを評価し、
   前記サービス更新分析処理部が、当該評価の結果が所定の関係を満たすサービスフローとして、前記更新前サービスフローまたは前記更新後サービスフローのいずれかを選択する、
   ことを特徴とするプログラム運用方法。
6. 請求項５に記載のプログラム運用方法であって、
   前記サービス更新分析処理部は、前記評価の結果が高いサービスフローを、前記評価の結果が所定の関係を満たすサービスフローとして選択する、
   ことを特徴とするプログラム運用方法。
7. 請求項６に記載のプログラム運用方法であって、
   前記マイクロサービス管理部は、前記更新前サービスフローと前記更新後サービスフローとを所定の回数実行し、
   前記サービス更新分析処理部は、前記所定の回数の実行により得られた前記更新前サービスフローの実行結果の評価の統計値と前記更新後サービスフローの実行結果の評価の統計値とを用いて、前記評価の結果が高いサービスフローを選択する、
   ことを特徴とするプログラム運用方法。
8. 請求項５に記載のプログラム運用方法であって、
   前記サービス更新分析処理部は、前記選択されたサービスフローに含まれるマイクロサービスを含む複数のサービスのうち、前記評価を行ったサービス以外の他のサービスについての評価を行って、前記マイクロサービスが前記他のサービスから選択されなくなった場合に、前記更新前サービスフローまたは前記更新後サービスフローのうちの選択がされなかったサービスフローを、前記プログラム運用システムから削除する、
   ことを特徴とするプログラム運用方法。

Images