7587184 マイクロサービス管理装置、マイクロサービス管理方法、及びプログラム

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

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

(11)【特許番号】

(24)【登録日】2024-11-12

(45)【発行日】2024-11-20

(54)【発明の名称】マイクロサービス管理装置、マイクロサービス管理方法、及びプログラム

(51)【国際特許分類】

   H04L 67/61 20220101AFI20241113BHJP

【ＦＩ】

H04L67/61

【請求項の数】 7

(21)【出願番号】P 2023504951

(86)(22)【出願日】2021-03-10

(86)【国際出願番号】 JP2021009495

(87)【国際公開番号】W WO2022190246

(87)【国際公開日】2022-09-15

【審査請求日】2023-08-09

(73)【特許権者】

【識別番号】000004226

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

(74)【代理人】

【識別番号】100083806

【弁理士】

【氏名又は名称】三好 秀和

(74)【代理人】

【識別番号】100129230

【弁理士】

【氏名又は名称】工藤 理恵

(72)【発明者】

【氏名】白井 嵩士

(72)【発明者】

【氏名】斎藤 清隆

【審査官】木村 雅也

(56)【参考文献】

【文献】特開２０１８－０２８７５６（ＪＰ，Ａ）

【文献】特開２０１７－０１６４０８（ＪＰ，Ａ）

【文献】白井 嵩士，サービスリソースの消費量を効率化する流量制御方法の一検討，電子情報通信学会技術研究報告 Ｖｏｌ．１２０ Ｎｏ．１０９ ［ｏｎｌｉｎｅ］，日本，一般社団法人電子情報通信学会，2020年07月09日，第31頁-第36頁

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

Ｈ０４Ｌ ６７／６１

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

【請求項1】

マイクロサービスを組み合わせたサービスを要求するリクエストを受信し、前記サービスを提供する複数のマイクロサービス提供装置の動作を管理するマイクロサービス管理装置であって、
前記マイクロサービス提供装置が輻輳中である場合に、該マイクロサービス提供装置が提供するマイクロサービスを実行させるマイクロサービス要求を保留する目的で蓄積する個別バッファと、
前記個別バッファのそれぞれに対応し、前記マイクロサービスを優先的に実行させる目的で前記個別バッファに蓄積された前記マイクロサービス要求を、前記個別バッファから移動させて蓄積する優先バッファと、
前記マイクロサービス要求が蓄積されてからの経過時間を表す保留時間を計測し、該保留時間が閾値を越えた場合に、前記リクエストに含まれる前記マイクロサービスの実行がないと前記リクエストを破棄し、又は前記リクエストに含まれる前記マイクロサービスの実行があると前記優先バッファに前記マイクロサービス要求を蓄積させる管理部と
を備えるマイクロサービス管理装置。

【請求項2】

受信した前記リクエストに含まれる前記マイクロサービス要求に対応する前記マイクロサービス提供装置の何れかが輻輳している場合に前記リクエストを蓄積する共通バッファ
を備える請求項１に記載のマイクロサービス管理装置。

【請求項3】

前記共通バッファは、
前記リクエストを蓄積した時間を表す前記保留時間を計時する保留時間計測部
を備える請求項２に記載のマイクロサービス管理装置。

【請求項4】

前記管理部は、
前記保留時間が閾値を越え、且つ前記リクエストに含まれる一部の前記マイクロサービスが実行済みである場合に、前記保留されている前記マイクロサービス要求を優先して処理する目的で前記優先バッファに移行させるマイクロサービス優先設定部と、
前記リクエストを構成する複数の前記マイクロサービス要求のそれぞれの処理時間に基づいて前記リクエストに対応する前記閾値を計算する保留時間閾値計算部と
を備える請求項１乃至３の何れかに記載のマイクロサービス管理装置。

【請求項5】

前記保留時間閾値計算部は、
前記閾値を、所定の固定時間から、前記リクエストを処理する処理見込み時間と所定の時間とを減じて求める
請求項４に記載のマイクロサービス管理装置。

【請求項6】

マイクロサービス管理装置が行うマイクロサービス管理方法であって、
マイクロサービスを組み合わせたサービスを要求するリクエストを受信し、前記サービスを提供する何れかのマイクロサービス提供装置が輻輳中である場合に、該マイクロサービス提供装置が提供する前記マイクロサービスを要求するマイクロサービス要求を個別バッファに蓄積し、
前記個別バッファのそれぞれに対応し、前記マイクロサービスを優先的に実行させる目的で前記個別バッファに蓄積された前記マイクロサービス要求を、前記個別バッファから移動させて優先バッファに蓄積し、
管理部は、前記マイクロサービス要求の処理が保留された場合に該保留された保留時間を計測し、該保留時間が閾値を越えた場合に、前記リクエストに含まれる前記マイクロサービスの実行がないと前記リクエストを破棄し、又は前記リクエストに含まれる前記マイクロサービスの実行があると前記優先バッファに前記マイクロサービス要求を蓄積させる
マイクロサービス管理方法。

【請求項7】

請求項１乃至５の何れかに記載のマイクロサービス管理装置としてコンピュータを機能させるためのプログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、複数のマイクロサービスを組み合わせてサービスを提供する技術に関する。

【背景技術】

【0002】

近年、ＷｅｂＡＰＩ（Application Programming Interface）などを介して複数のマイクロサービスを組み合わせてサービスを提供するマッシュアップサービスが普及している。マッシュアップサービスでは、途中のマイクロサービスに輻輳が発生しリクエストが実施できない場合、リクエストは途中で破棄されるため、破棄する前に消費したサービスリソースが無駄になってしまう。

【0003】

そこで、サービスリソースの無駄が生じることを防止する目的で、トークンパケットアルゴリズムによるスロットリングを行いパケットバッファに入りきらないリクエストを破棄する技術が例えば非特許文献１に開示されている。また、リクエストを破棄する際に消費リソースの少ないものから破棄する技術が例えば特許文献１に開示されている。また、非特許文献２には、リクエストのバッファが溢れそうになった場合に共通バッファにリクエストを格納する技術が開示されている。

【先行技術文献】

【特許文献】

【0004】

【文献】特開２０１８－２８７５６号公報

【非特許文献】

【0005】

【文献】S.Floyd et al., “Adaptive RED: An Algorithm for Increasing the Robustness of RED’s Active Queue Management,” AT&T Center for Internet Research at ICSI, Aug 2001.https://www.icir.org/floyd/papers/adaptiveRed.pdf

【文献】白井他, “サービスリソースの消費量を効率化する流量制御方法の一検討,” 信学技報, vol.120, no.109, ICM2020-13, pp.31-36, 2020年7月.

【発明の概要】

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

【0006】

しかしながら、上記の従来技術はタイムアウトを考慮していない。したがって、タイムアウトによりリクエストが廃棄された場合にリソースの無駄が発生するという課題がある。

【0007】

本発明は、この課題に鑑みてなされたものであり、タイムアウトによって生じるリソースの無駄を低減させることができるマイクロサービス管理装置、その方法、及びプログラムを提供することを目的とする。

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

【0008】

本発明の一態様に係るマイクロサービス管理装置は、マイクロサービスを組み合わせたサービスを要求するリクエストを受信し、前記サービスを提供する複数のマイクロサービス提供装置の動作を管理するマイクロサービス管理装置であって、前記マイクロサービス提供装置が輻輳中である場合に、該マイクロサービス提供装置が提供するマイクロサービスを実行させるマイクロサービス要求を保留する目的で蓄積する個別バッファと、前記個別バッファのそれぞれに対応し、前記マイクロサービスを優先的に実行させる目的で前記個別バッファに蓄積された前記マイクロサービス要求を、前記個別バッファから移動させて蓄積する優先バッファと、前記マイクロサービス要求が蓄積されてからの経過時間を表す保留時間を計測し、該保留時間が閾値を越えた場合に、前記リクエストに含まれる前記マイクロサービスの実行がないと前記リクエストを破棄し、又は前記リクエストに含まれる前記マイクロサービスの実行があると前記優先バッファに前記マイクロサービス要求を蓄積させる管理部とを備えることを要旨とする。

【0009】

また、本発明の一態様に係る管理方法は、上記のマイクロサービス管理装置が行うマイクロサービス管理方法であって、マイクロサービスを組み合わせたサービスを要求するリクエストを受信し、前記サービスを提供する何れかのマイクロサービス提供装置が輻輳中である場合に、該マイクロサービス提供装置が提供する前記マイクロサービスを要求するマイクロサービス要求を個別バッファに蓄積し、前記個別バッファのそれぞれに対応し、前記マイクロサービスを優先的に実行させる目的で前記個別バッファに蓄積された前記マイクロサービス要求を、前記個別バッファから移動させて優先バッファに蓄積し、管理部は、前記マイクロサービス要求の処理が保留された場合に該保留された保留時間を計測し、該保留時間が閾値を越えた場合に、前記リクエストに含まれる前記マイクロサービスの実行がないと前記リクエストを破棄し、又は前記リクエストに含まれる前記マイクロサービスの実行があると前記優先バッファに前記マイクロサービス要求を蓄積させる
ことを要旨とする。

【0010】

また、本発明の一態様に係るプログラムは、上記のマイクロサービス管理装置としてコンピュータを機能させるためのプログラムであることを要旨とする。

【発明の効果】

【0011】

本発明によれば、タイムアウトによって生じるリソースの無駄を低減させることができる。

【図面の簡単な説明】

【0012】

【図1】本発明の実施形態に係るマイクロサービス管理装置の機能構成例を示すブロック図である。

【図2】図１に示す管理部の機能構成例を示すブロック図である。

【図3】図２に示すサービス状態データベースに格納される情報（レコード）の例を模式的に示す図である。

【図4】図１に示すマイクロサービス管理装置の動作状況の一例を模式的に示す図である。

【図5】図１に示すマイクロサービス管理装置の動作状況の他の一例を模式的に示す図である。

【図6】図１に示す共通バッファに蓄積された情報（レコード）の例を模式的に示す図である。

【図7】図１に示すマイクロサービス管理装置の動作状況の他の一例を模式的に示す図である。

【図8】図１に示す個別バッファに蓄積された情報（レコード）の例を模式的に示す図である。

【図9】ある仮定した状態における個別バッファの動作を模式的に示す図である。

【図10】マイクロサービス要求を優先バッファに蓄積する動作を模式的に示す図である。

【図11】あるマイクロサービス要求が優先して処理される動作を模式的に示す図である。

【図12A】図１に示す管理部の処理ステップを示すフローチャートである。

【図12B】図１に示す管理部の処理ステップを示すフローチャートである。

【図13】汎用的なコンピュータシステムの構成例を示すブロック図である。

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

【0013】

以下、本発明の実施形態について図面を用いて説明する。複数の図面中同一のものには同じ参照符号を付し、説明は繰り返さない。

【0014】

図１は、本発明の実施形態に係るマイクロサービス管理装置の機能構成例を示すブロック図である。図１に示すマイクロサービス管理装置１００は、マイクロサービス利用装置８０からマイクロサービスを組み合わせたサービスを要求するリクエストを受信し、マイクロサービス提供装置９０を組み合わせてマッシュアップサービスを提供する処理を管理する装置である。

【0015】

マイクロサービス利用装置８０は、マイクロコンピュータ、タブレット等の情報処理装置である。図１は、簡単にするためにマイクロサービス利用装置８０を1台しか表記していないが、マイクロサービス利用装置８０は複数台あっても構わない。マイクロサービス管理装置１００は、各マイクロサービス利用装置８０からリクエストを受信する。リクエストは、例えば、配送管理サービス、販売管理サービス、在庫管理サービス、その他各種サービスである。

【0016】

マイクロサービスは、個々に開発された複数のマイクロサービスを連携させて管理、運営を行うソフトウェアのアーキテクチャである。複数のマイクロサービス提供装置９０Ａ，９０Ｂ，…のそれぞれは、マイクロサービス要求に対応させて、例えば、認証サービス、検索サービス、ダウンロードサービス等のマイクロサービスを提供する。

【0017】

認証サービスのマイクロサービスＡは、マイクロサービス提供装置９０Ａが提供する。また、検索サービスのマイクロサービスＢは、マイクロサービス提供装置９０Ｂが提供する。その他のマイクロサービスＣ，…，Ｉ，Ｊも、それぞれに対応するマイクロサービス提供装置９０Ｃ，９０Ｉ，９０Ｊが提供する。

【0018】

マイクロサービス管理装置１００は、リクエスト受信部１０、管理部２０、個別バッファ３０、リクエスト送信部４０、レスポンス受信部５０、共通バッファ６０、及びレスポンス送信部７０を備える。個別バッファ３０、リクエスト送信部４０、及びレスポンス受信部５０は、それぞれはマイクロサービス提供装置９０Ａ，９０Ｂ，…に対応して設けられる。以降においてマイクロサービスを特定する必要がない場合はＡ，Ｂ，…を省略してマイクロサービス提供装置９０と表記する。他の機能構成部も同様である。

【0019】

リクエスト受信部１０は、マイクロサービス利用装置８０からリクエストを受信する。リクエストは利用者が受けたいサービスによって異なる。例えばリクエスト（１）は、マイクロサービス要求Ａ，Ｂ，Ｉ，Ｊを組み合わせたリクエストである。

【0020】

管理部２０は、リクエスト受信部１０で受信したリクエストに輻輳中のマイクロサービス要求が含まれるか否かを判定し、各マイクロサービス提供装置９０の動作を管理する。マイクロサービス要求が含まれるかは、該当するかと表現を変えることも可能である。

【0021】

マイクロサービス提供装置９０が輻輳中であるか否かは、個別バッファ３０にマイクロサービス要求が蓄積されているか否かで判定する。例えば、マイクロサービス提供装置９０ＡがマイクロサービスＡの処理を実行中にマイクロサービス要求Ａが生じた場合、そのマイクロサービス要求は個別バッファ３０Ａに蓄積される。個別バッファ３０に蓄積されたマイクロサービス要求は、マイクロサービス提供装置９０Ａが処理を終了すれば順次実行される。よって、個別バッファ３０に蓄積されたマイクロサービス要求が存在する場合、その個別バッファ３０に対応するマイクロサービス提供装置９０は輻輳中であると判定できる。

【0022】

個別バッファ３０は、図１に示すように各マイクロサービス提供装置９０に対応させて設けられる。個別バッファ３０は、マイクロサービス提供装置９０が輻輳中である場合に、該マイクロサービス提供装置９０が提供するマイクロサービスを実行させるマイクロサービス要求を保留する目的で蓄積する。

【0023】

リクエスト送信部４０は、個別バッファ３０と同様に各マイクロサービス提供装置９０に対応させて設けられる。リクエスト送信部４０は、対応するマイクロサービス提供装置９０が輻輳していなければリクエストに含まれるマイクロサービス要求をそのマイクロサービス提供装置９０に送信する。

【0024】

レスポンス受信部５０は、リクエスト送信部４０と同様に各マイクロサービス提供装置９０に対応させて設けられる。レスポンス受信部５０は、対応するマイクロサービス提供装置９０からレスポンスを受信する。レスポンスは、マイクロサービス提供装置９０で処理されたマイクロサービス要求の結果とマイクロサービス提供装置９０が発信する情報を含む。その情報には、マイクロサービスを処理するのに要する処理時間等が含まれる。処理時間について詳しくは後述する。

【0025】

共通バッファ６０は、マイクロサービス利用装置８０から受信したリクエストに含まれるマイクロサービス要求に対応するマイクロサービス提供装置９０の何れかが輻輳している場合にリクエストを蓄積する。また、共通バッファ６０は、リクエストを蓄積した時間を表す保留時間を計測する保留時間計測部６１を備える。

【0026】

レスポンス送信部７０は、複数のマイクロサービス提供装置９０で処理されたマイクロサービスの結果とマイクロサービス提供装置９０が発信する情報をマイクロサービス利用装置８０に送信する。

【0027】

個別バッファ３０のそれぞれは、優先バッファ３２を備える。優先バッファ３２は、個別バッファ３０のそれぞれに対応し、マイクロサービスを優先的に実行させる目的で個別バッファ３０に蓄積されたマイクロサービス要求を、個別バッファ３０から移動させて蓄積する。また、個別バッファ３０は、マイクロサービス要求が保留された場合に該保留された保留時間を計測する保留時間計測部３１を備える。

【0028】

また、管理部２０は、マイクロサービス要求が蓄積されてからの経過時間を表す保留時間を計測し、該保留時間が閾値を越えた場合に、リクエストに含まれるマイクロサービスの実行がないとリクエストを破棄し、又はリクエストに含まれるマイクロサービスの実行があると優先バッファ３２にマイクロサービス要求を蓄積させる。

【0029】

以上説明したように本実施形態に係るマイクロサービス管理装置１００は、マイクロサービスを組み合わせたサービスを要求するリクエストを受信し、サービスを提供する複数のマイクロサービス提供装置９０の動作を管理するマイクロサービス管理装置であって、マイクロサービス提供装置９０が輻輳中である場合に、該マイクロサービス提供装置９０が提供するマイクロサービスを実行させるマイクロサービス要求を保留する目的で蓄積する個別バッファ３０と、個別バッファ３０のそれぞれに対応し、マイクロサービスを優先的に実行させる目的で個別バッファ３０に蓄積されたマイクロサービス要求を、個別バッファ３０から移動させて蓄積する優先バッファ３２と、マイクロサービス要求が蓄積されてからの経過時間を表す保留時間を計測し、該保留時間が閾値を越えた場合に、リクエストに含まれるマイクロサービスの実行がないとリクエストを破棄し、又はリクエストに含まれるマイクロサービスの実行があると優先バッファ３２にマイクロサービス要求を蓄積させる管理部２０とを備える。これにより、サービス途中で廃棄されるリクエストを低減させることができる。

【0030】

つまり、保留時間が閾値を越え且つリクエストに含まれるマイクロサービスが実行されていない場合（サービスリソースが消費される前）にそのリクエストが破棄されるので、サービスリソースを無駄にしないで済む。

【0031】

以降、図面を参照して本実施形態の動作を更に詳しく説明する。次に管理部２０について説明する。

【0032】

（管理部）
図２は、管理部２０の機能構成例を示すブロック図である。管理部２０は、サービス状態データベース（以降、サービス状態ＤＢ）２１、バッファ制御部２２、及びリクエスト処理部２３を備える。

【0033】

サービス状態ＤＢ２１は、マイクロサービスの提供状態及び輻輳状態を格納する。マイクロサービスの提供状態は、例えば、各マイクロサービス提供装置９０の処理時間の最大値、処理時間の最小値、処理時間の平均値、輻輳の有無（輻輳フラグ）、個別バッファの空き、及び待ちキューの最大待機時間等である。これらの情報は、マイクロサービス要求に対する各マイクロサービス提供装置９０のレスポンスから得られる。

【0034】

マイクロサービス提供装置９０によっては、処理時間等の情報をレスポンスに含めて通知して来ない場合もある。よって、マイクロサービス管理装置１００は、これらの情報をマイクロサービス提供装置９０から取得するようにしてもよい。例えば処理時間は、マイクロサービス提供装置９０に対してマイクロサービス要求を行った時間と、マイクロサービス提供装置９０からレスポンスを得た時間との差分から得ることができる。

【0035】

図３は、サービス状態ＤＢ２１に格納される情報（レコード）の例を模式的に示す図である。図３の左から1列目はマイクロサービスの提供状態を表す項目であり、上から３行目から順に、例えば、処理時間最大値、処理時間最小値、処理時間平均値、…、輻輳フラグ、個別バッファ空き、及び待ちキューの最大待機時間等である。２列目以降は、各マイクロサービスＡ,Ｂ,Ｃ,…の各マイクロサービスの提供状態の具体例を示す。

【0036】

図３に示すように、マイクロサービスＩを提供するマイクロサービス提供装置９０Ｉは、輻輳しており個別バッファ３０Ｉの空きは０である。また、マイクロサービスＪを提供するマイクロサービス提供装置９０Ｊも輻輳しており個別バッファＩの空きは０である。

【0037】

マイクロサービスＡ，Ｂ，Ｃを提供するマイクロサービス提供装置９０Ａ，９０Ｂ，９０Ｃは輻輳していない。このようにサービス状態ＤＢ２１を監視（参照）することで、各個別バッファ３０の状態を把握することができる。

【0038】

バッファ制御部２２は、サービス状態ＤＢ２１を監視し、個別バッファ３０に蓄積するマイクロサービス要求、及び共通バッファに蓄積するリクエストの選択を行う。バッファ制御部２２は、リクエストに含まれるマイクロサービス要求に対応するマイクロサービス提供装置９０の何れかが輻輳中であり、個別バッファに空きが無い場合にそのリクエストを共通バッファ６０に蓄積する。また、個別バッファ３０に空きのあるマイクロサービス要求を、個別バッファ３０に蓄積する。

【0039】

リクエスト処理部２３は、リクエスト受信部１０がマイクロサービス利用装置８０から受信したリクエストを、当該リクエストの内容ごとにマイクロサービスを連携させると共に、マイクロサービス要求を個別バッファ３０に、リクエストを共通バッファ６０に蓄積する。マイクロサービスの連携は、リクエストの内容ごとに、どのマイクロサービスをどの順序で用いるかが規定されているシナリオ（図示せず）に基づいて行う。

【0040】

リクエスト処理部２３は、リクエストが配送管理サービスであれば、例えば、認証サービスＡ、検索サービスＢ、ダウンロードサービスＩ、課金サービスＪの各マイクロサービスを連携させる。よって、リクエスト処理部２３は、マイクロサービスＡとマイクロサービスＢとマイクロサービスＩとマイクロサービスＪを連携（Ａ→Ｂ→Ｉ→Ｊ）させる。なお、各マイクロサービスの処理順はアルファベット順に限られない。

【0041】

リクエスト処理部２３は、マイクロサービス優先設定部２４と保留時間閾値計算部２５を備える。

【0042】

マイクロサービス優先設定部２４は、マイクロサービス要求が保留されてからの保留時間を計測する保留時間計測部３１で計測した保留時間が閾値を越え、且つリクエストに含まれる一部のマイクロサービスが実行済みである場合に、保留されているマイクロサービス要求を優先して処理する目的で優先バッファ３２に移行させる。

【0043】

保留時間閾値計算部２５は、リクエストを構成する複数のマイクロサービス要求のそれぞれの処理時間に基づいてリクエストに対応する閾値を計算する。閾値は、例えば、所定の固定時間から、マイクロサービスの処理見込み時間を減算して求める。閾値について詳しくは後述する。

【0044】

（リクエストの実行例）
図４は、マイクロサービス管理装置１００が、マイクロサービスＡ→Ｂ→Ｉ→Ｊというマッシュアップサービスを実行させる動作を模式的に示す図である。

【0045】

リクエスト受信部１０は、マイクロサービス利用装置８０からマイクロサービスＡ→Ｂ→Ｉ→Ｊを組み合わせたサービスを要求するリクエストを受信する。管理部２０は、リクエストを受信するとサービス状態ＤＢ２１を参照する。管理部２０は、マイクロサービス提供装置９０Ａ，９０Ｂ，９０Ｉ，９０Ｊに輻輳が無い場合、シナリオに基づいてマイクロサービスＡ→Ｂ→Ｉ→Ｊを、図５に一点鎖線で示すように順に実行させる。

【0046】

レスポンス送信部７０は、マイクロサービス提供装置９０で処理されたマイクロサービスの結果とマイクロサービス提供装置９０が発信する情報をマイクロサービス利用装置８０に送信する。

【0047】

図５は、図４と同じマイクロサービスＡ→Ｂ→Ｉ→Ｊを組み合わせたリクエストにおいて、マイクロサービスＩ，Ｊが輻輳している場合の動作を模式的に示す図である。

【0048】

この場合、図５に示すようにリクエストは、マイクロサービスＡ，Ｂも実行せずに共通バッファ６０に蓄積される。

【0049】

図６は、共通バッファ６０に蓄積された情報（レコード）の例を模式的に示す図である。図６の左から1列目はバッファ番号、２列目はリクエストｉｄ、３列目は今後の処理予定４列目はリクエストを保留（蓄積）してからの保留時間、５列目は保留時間の閾値を示す。マイクロサービスＡ→Ｂ→Ｉ→Ｊを組み合わせたリクエストは、リクエストｉｄ：000168で蓄積されている。

【0050】

リクエストの保留時間は、保留時間計測部６１で計測される。図６に示す保留時間は、バッファ番号の小さい上から順に保留時間が長い例を示す。

【0051】

保留時間の閾値は、リクエストを更に保留するか又は廃棄するかを判定する閾値である。閾値は、例えば、タイムアウトを検知する時間から、マイクロサービスの処理見込み時間と、所定の時間（α）とを減じた値にする。

【0052】

【数1】

【0053】

ここで、タイムアウトを検知する時間は、例えば６０秒といった固定値である。処理見込み時間は、リクエストが利用するマイクロサービスの処理時間である。又は、リクエストが利用するマイクロサービスの待ちキューサイズから算出する。所定の時間（α）は、例えば、判断に要する時間であり、マイクロサービス提供装置９０の処理に要する時間等を考慮した余分である。

【0054】

所定の時間（α）を減ずることで、リクエストの処理を開始した後に処理の途中でタイムアウトになることを防止できる。つまり、所定時間（α）は、更に保留するか又は廃棄するかの判定を安全に行うための余分である。

【0055】

リクエストｉｄ：000168の保留時間の閾値は、保留時間閾値計算部２５で計算される。保留時間閾値計算部２５は、サービス状態ＤＢ２１（図３）を参照してマイクロサービスＡ，Ｂ，Ｉ，Ｊのそれぞれの処理時間最大値と待ちキューの最大待機時間とから、例えば６０（固定値）－（２＋３＋２＋３＋４＋５）－１０（α）＝３１秒の閾値を計算する。

【0056】

図６（ｂ）は、図６（ａ）の３秒後の共通バッファ６０に蓄積された情報の例を示す。図６（ｂ）に示すように、リクエストｉｄ：000168と000182のそれぞれの保留時間が、保留時間の閾値に一致している。

【0057】

保留時間が閾値に一致すると、リクエストが処理可能か判定する。この例の場合は、マイクロサービスＩ，Ｊの個別バッファ３０Ｉ，３０Ｊに空きがある（図３）ので、リクエストｉｄ：000168の処理を開始する。

【0058】

一方、保留時間が閾値に一致したリクエストｉｄ：00182のリクエストは、リクエストｉｄ：000168の処理が開始されたことにより、個別バッファ９０Ｉに空きが無くなったため処理されずに破棄される。破棄してもリクエストを構成するマイクロサービスの何れも実行されていない。したがって、リソースを無駄に消費しないでリクエストを破棄することができる。

【0059】

以上説明したように、リクエストに含まれるマイクロサービス要求に対応するマイクロサービス提供装置９０の何れかが輻輳している場合に受信したリクエスト（共通バッファ６０に蓄積されたリクエスト）は、リソースを無駄にしないで破棄される。

【0060】

なお、共通バッファ６０は必須の構成ではない。共通バッファ６０を備えない構成でもタイムアウトによって生じるリソースの無駄を低減させることができる。次に共通バッファ６０を備えない構成のマイクロサービス管理装置１００の動作について説明する。

【0061】

図７は、マイクロサービスＡ→Ｂ→Ｉ→Ｊを組み合わせたリクエストにおいて、マイクロサービスＡ，Ｂ，Ｉ，Ｊが輻輳している場合の動作を模式的に示す図である。

【0062】

管理部２０は、輻輳状況からリクエストの処理の可否を判定する。輻輳状況の判定は、上記の説明と同様にサービス状態ＤＢ２１（図３）を参照することで行う。

【0063】

図７に示す例では、そのリクエストに含まれるマイクロサービス要求を個別バッファ３０Ａに蓄積する。蓄積されたマイクロサービス要求は順次処理される。その間に、保留時間計測部３１Ａの計測時間が保留時間の閾値と一致すると、個別バッファ３０Ａに蓄積されたマイクロサービス要求とリクエストは破棄される。破棄されてもリソースは消費されていないのでリソースの無駄は生じない。

【0064】

図８は、個別バッファ３０Ａに蓄積された情報（レコード）の例を模式的に示す図である。図８の行と列の関係は図６（共通バッファ６０）と同じである。保留時間の閾値の求め方も同じである。

【0065】

図８に示すバッファ番号３の行（リクエストｉｄ：000168）は、図７に示した状態からマイクロサービスＡが処理中である状態を示す。マイクロサービスＡの処理中に、時間が経過し、マイクロサービスＡの処理後に保留時間が保留時間の閾値２７秒に到達したと仮定する。

【0066】

図９は、その仮定した状態の個別バッファ３０Ｂの動作を模式的に示す図である。図９に示すように、この仮定では、マイクロサービスＡが処理済みである。よって、ここでリクエスト（リクエストｉｄ：000168）に含まれるマイクロサービスＢを実行させるマイクロサービス要求を破棄すると、リソースが無駄になる。

【0067】

そこで、本実施形態では、マイクロサービスＢを実行させるマイクロサービス要求を優先バッファ３２Ｃに蓄積する。図１０は、マイクロサービス要求を優先バッファ３２Ｃに蓄積する動作を模式的に示す。

【0068】

以降、マイクロサービスＩ，Ｊを実行させるマイクロサービス要求は、優先バッファ３２Ｉ，３２Ｊに蓄積され、優先して処理される。

【0069】

図１１は、マイクロサービスＩが優先して処理される動作を模式的に示す。このように、保持時間が保持時間の閾値を超過した場合であって、且つ一部のマイクロサービスが処理済みである場合は処理の優先度を上げてマイクロサービス要求が処理される。

【0070】

以上説明したように本実施形態に係るマイクロサービス管理装置１００によれば、マイクロサービス提供装置９０の保留時間を計測し、マイクロサービス要求毎の保持時間の閾値を計算する。そして、保留時間が閾値を超過した場合、マイクロサービス要求を処理するか、破棄するかを判定し、マイクロサービスの処理を開始しても処理の途中でタイムアウトする可能性があり、且つ破棄してもリソースの無駄が生じないと判定された場合はマイクロサービス要求を破棄する。また、マイクロサービス要求を処理する場合、リソースの無駄が生じると判定されると、マイクロサービス要求の処理の優先度を上げる。

【0071】

以上の動作によって、タイムアウトによって生じるリソースの無駄を低減させることができる。

【0072】

（マイクロサービス管理方法）
図１２は、管理部２０の処理ステップを示すフローチャートである。図１２Ａと図１２Ｂを参照して本実施形態に係るマイクロサービス管理装置１００が行うマイクロサービス管理方法について説明する。なお、マイクロサービス管理装置１００は、共通バッファ６０を備える例で説明する。

【0073】

マイクロサービス管理装置１００が動作を開始すると、リクエスト受信部１０はマイクロサービス利用装置８０からマイクロサービスを組み合わせたサービスを要求するリクエストを受信する。

【0074】

受信したリクエストに含まれるマイクロサービス要求に対応するマイクロサービス提供装置９０に輻輳が生じているか否かによって、管理部２０は、リクエストを共通バッファ６０に格納するか、個別バッファ３０に格納するかを判定する（ステップＳ１）。リクエストを受信した時点で輻輳が生じている場合は、共通バッファ３０にリクエストを格納（蓄積）する（ステップＳ１の共通バッファ）。

【0075】

管理部２０は、マイクロサービス提供装置９０の輻輳状況からリクエストの処理の可否を判定する（ステップＳ２）。輻輳が無くなり処理できると判定する（ステップＳ３のＹＥＳ）と、リクエストに含まれるマイクロサービス要求を順次実行させる。上記の図４に示したマッシュアップサービスを実行する（ステップＳ４）。

【0076】

輻輳があり、処理できないと判定する（ステップＳ３のＮＯ）と、管理部２０の保持時間閾値計算部２５は、式（１）に示した保持時間の閾値の計算を行う（ステップＳ５）。そして、保持時間計測部６１で計測した保持時間が、計算した閾値を超過したか否かをチェックする（ステップＳ６）。

【0077】

ステップＳ５とＳ６の処理は、リクエスト毎に実行され、保持時間が閾値を超過するリクエストがあれば（ステップＳ７のＹＥＳ）そのリクエストを破棄する（ステップＳ８）。

【0078】

ステップＳ２～Ｓ８の処理を繰り返すことで、共通バッファ３０に格納されたリクエストは、順次処理され、保持時間が閾値を超過したリクエストは順次破棄される。このように動作することで、リソースの無駄を生じさせない。

【0079】

リクエストの受信時に、そのリクエストに含まれるマイクロサービス要求に対応するマイクロサービス提供装置９０に輻輳が生じていない場合、管理部２０は、そのリクエストを個別バッファ３０に格納する（ステップＳ１の個別バッファ）。

【0080】

管理部２０は、マイクロサービス提供装置９０の輻輳状況からリクエストの処理の可否を判定する（ステップＳ９）。輻輳が無く処理できると判定する（ステップＳ１０のＹＥＳ）と、リクエストに含まれるマイクロサービス要求を順次実行させる（ステップＳ１１）。

【0081】

輻輳があり、処理できないと判定する（ステップＳ１０のＮＯ）と、管理部２０の保持時間閾値計算部２５は、式（１）に示した保持時間の閾値の計算を行う（ステップＳ１２）。そして、保持時間計測部３１で計測した保持時間が、計算した閾値を超過したか否かをチェックする（図１３、ステップＳ１２）。

【0082】

マイクロサービス提供装置９０に対応する個別バッファ３０の保持時間計測部３１が計測した保持時間が、閾値を越えない場合（ステップＳ１４のＮＯ）、ステップＳ９～Ｓ１４の処理を繰り返し、処理できるマイクロサービス要求を順次処理する。

【0083】

保持時間が閾値を越えた場合（ステップＳ１４のＹＥＳ）、管理部２０は、利用予定のマイクロサービス要求に対応するマイクロサービス提供装置９０の輻輳状況を確認する（ステップＳ１５）。

【0084】

そして、リクエストに含まれるマイクロサービス要求の何れかが処理されているか否かを判定する（ステップＳ１６）。処理されていない場合（ステップＳ１６のＮＯ）、そのリクエストを破棄する（ステップＳ１７）。

【0085】

リクエストに含まれるマイクロサービス要求の何れかが処理済みである場合（ステップＳ１６のＹＥＳ）は、次に、利用予定のマイクロサービスを提供するマイクロサービス提供装置９０に輻輳が生じているか否かをチェックする（ステップＳ１８）。

【0086】

利用予定のマイクロサービス提供装置９０に輻輳が生じている場合（ステップＳ１８のＹＥＳ）、利用予定のマイクロサービス要求を、対応する優先バッファ３２に格納する（ステップＳ１９）。優先バッファ３２に格納されたマイクロサービス要求は優先的に処理される。

【0087】

利用予定のマイクロサービス提供装置９０に輻輳が生じていない場合（ステップＳ１８のＮＯ）は、利用予定のマイクロサービスの処理を開始させる（ステップＳ２０）。

【0088】

以上説明したように、本実施形態に係るマイクロサービス管理装置１００が行うマイクロサービス管理方法であって、マイクロサービスを組み合わせたサービスを要求するリクエストを受信し、サービスを提供する何れかのマイクロサービス提供装置９０が輻輳中である場合に、該マイクロサービス提供装置９０が提供するマイクロサービスを要求するマイクロサービス要求を個別バッファ３０に蓄積し、個別バッファ３０のそれぞれに対応し、マイクロサービスを優先的に実行させる目的で個別バッファ３０に蓄積されたマイクロサービス要求を、個別バッファ３０から移動させて優先バッファ３２に蓄積し、管理部２０は、マイクロサービス要求の処理が保留された場合に該保留された保留時間を計測し、該保留時間が閾値を越えた場合に、リクエストに含まれるマイクロサービスの実行がないとリクエストを破棄し、又はリクエストに含まれるマイクロサービスの実行があると優先バッファ３２にマイクロサービス要求を蓄積させる。これにより、タイムアウトによって生じるリソースの無駄を低減させることができる。

【0089】

マイクロサービス管理装置１００は、図１３に示す汎用的なコンピュータシステムで実現することができる。例えば、ＣＰＵ９０、メモリ９１、ストレージ９２、通信部９３、入力部９４、及び出力部９５を備える汎用的なコンピュータシテムにおいて、ＣＰＵ９０がメモリ９１上にロードされた所定のプログラムを実行することにより、マイクロサービス管理装置１００の各機能が実現される。所定のプログラムは、HDD、SSD、USBメモリ、CD-ROM、DVD-ROM、MOなどのコンピュータ読取り可能な記録媒体に記録することも、ネットワークを介して配信することもできる。

【0090】

本発明は、上記の実施形態に限定されるものではなく、その要旨の範囲内で変形が可能である。例えば、保留時間を判定する閾値を、保留時間閾値計算部２５で計算して求める例を示したが、本発明はこの例に限定されない。閾値は固定値にしてもよい。また、計算方法も上記の例に限定されない。直近の平均値を用いてもよいし、最繁時の平均値を用いてもよい。

【0091】

また、共通バッファ６０及び個別バッファ３０は、それぞれのバッファに蓄積した順番で処理の可否を判定する例で説明したが、保留時間が長いリクエスト又は短いリクエストを優先して処理するようにしてもよい。

【0092】

また、複数のマイクロサービスを連携させる処理は、リクエスト処理部のシナリオを参照して行う例を示したが、本発明はこの例に限定されない。リクエストにマイクロサービス要求が陽として含まれていればシナリオは不要である。

【0093】

このように、本発明はここでは記載していない様々な実施形態等を含むことは勿論である。したがって、本発明の技術的範囲は上記の説明から妥当な特許請求の範囲に係る発明特定事項によってのみ定められるものである。

【符号の説明】

【0094】

１０：リクエスト受信部
２０：管理部
３０：個別バッファ
４０：リクエスト送信部
５０：レスポンス受信部
６０：共通バッファ
７０：レスポンス送信部
８０：マイクロサービス利用装置
９０：マイクロサービス提供装置
１００：マイクロサービス管理装置

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12A】

【図12B】

【図13】