特許 7532325 情報処理システム、情報処理装置、情報処理方法及びプログラム

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

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

(11)【特許番号】

(24)【登録日】2024-08-02

(45)【発行日】2024-08-13

(54)【発明の名称】情報処理システム、情報処理装置、情報処理方法及びプログラム

(51)【国際特許分類】

   H04L 67/60 20220101AFI20240805BHJP

   G06F 8/65 20180101ALI20240805BHJP

【ＦＩ】

H04L67/60

G06F8/65

【請求項の数】 11

(21)【出願番号】P 2021151134

(22)【出願日】2021-09-16

(65)【公開番号】P2023043472

(43)【公開日】2023-03-29

【審査請求日】2023-03-10

(73)【特許権者】

【識別番号】000003078

【氏名又は名称】株式会社東芝

(74)【代理人】

【識別番号】110002147

【氏名又は名称】弁理士法人酒井国際特許事務所

(72)【発明者】

【氏名】寺島 芳樹

(72)【発明者】

【氏名】金子 雄

(72)【発明者】

【氏名】寺本 圭一

【審査官】岩田 玲彦

(56)【参考文献】

【文献】特開２００５－２２２５２４（ＪＰ，Ａ）

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

Ｈ０４Ｌ ６７／６０

Ｇ０６Ｆ ８／６５

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

【請求項1】

複数のサービスを通信により連携させることによって構成される情報処理システムであって、
前記複数のサービスのそれぞれは、
自身のバージョン情報と、通信先サービスのバージョン情報とを提供する提供部と、
アクセスルールに基づいて、前記通信先サービスへのアクセスを制御する制御部と、
アクセス要求に応じて任意の処理を実行するアプリケーション部と、を備え、
前記アクセスルールは、前記自身のバージョン情報と、前記通信先サービスのバージョン情報とに基づいて、前記通信先サービスへのアクセスを許可するか否かを制御する情報を含み、
前記バージョン情報は、前記アプリケーション部のバージョンを示し、
前記提供部は、前記アプリケーション部が前記バージョン情報を有さない場合、前記アプリケーション部の更新により変更される所定のデータのハッシュ値を算出し、前記ハッシュ値が、前回取得されたハッシュ値と同じである場合、前回提供されたバージョン情報と同じバージョン情報を提供し、前記ハッシュ値が、前回取得されたハッシュ値と異なる場合、前回提供されたバージョン情報と異なるバージョン情報を提供する、
情報処理システム。

【請求項2】

複数のサービスを通信により連携させることによって構成される情報処理システムであって、
前記複数のサービスのそれぞれは、
自身のバージョン情報と、通信先サービスのバージョン情報とを提供する提供部と、
アクセスルールに基づいて、前記通信先サービスへのアクセスを制御する制御部と、
アクセス要求に応じて任意の処理を実行するアプリケーション部と、を備え、
前記アクセスルールは、前記自身のバージョン情報と、前記通信先サービスのバージョン情報とに基づいて、前記通信先サービスへのアクセスを許可するか否かを制御する情報を含み、
前記バージョン情報は、前記アプリケーション部のバージョンを示し、
前記提供部は、前記アプリケーション部が前記バージョン情報を有さない場合、所定のテストデータを前記アプリケーション部に実行させた結果が、前回の実行結果と同じである場合、前回提供されたバージョン情報と同じバージョン情報を提供し、所定のテストデータを前記アプリケーション部に実行させた結果が、前回の実行結果と異なる場合、前回提供されたバージョン情報と異なるバージョン情報を提供する、
情報処理システム。

【請求項3】

他のサービスから受信されたアクセス要求をフックし、前記アクセス要求が、バージョン情報取得要求である場合、前記バージョン情報取得要求を前記提供部に振り分け、前記アクセス要求が、前記バージョン情報取得要求でない場合、前記アクセス要求を前記アプリケーション部に振り分ける振り分け部を更に備え、
前記提供部は、前記バージョン情報取得要求を受信すると、前記自身のバージョン情報を提供する、
請求項１又は２に記載の情報処理システム。

【請求項4】

前記制御部は、前記アプリケーション部から前記通信先サービスへのアクセス要求をフックし、前記アクセスルールに基づいて前記通信先サービスへのアクセスを許可するか否か否かを判定し、前記通信先サービスへのアクセスを許可する場合、前記アクセス要求を前記通信先サービスへ送信する、
請求項１乃至３のいずれか１項に記載の情報処理システム。

【請求項5】

前記提供部は、前記アプリケーション部が前記バージョン情報を有する場合、前記アプリケーション部から取得されたバージョン情報を提供する、
請求項１乃至４のいずれか１項に記載の情報処理システム。

【請求項6】

自身のバージョン情報と、通信先サービスのバージョン情報とを提供する提供部と、
アクセスルールに基づいて、前記通信先サービスへのアクセスを制御する制御部と、
アクセス要求に応じて任意の処理を実行するアプリケーション部と、を備え、
前記アクセスルールは、前記自身のバージョン情報と、前記通信先サービスのバージョン情報とに基づいて、前記通信先サービスへのアクセスを許可するか否かを制御する情報を含み、
前記バージョン情報は、前記アプリケーション部のバージョンを示し、
前記提供部は、前記アプリケーション部が前記バージョン情報を有さない場合、前記アプリケーション部の更新により変更される所定のデータのハッシュ値を算出し、前記ハッシュ値が、前回取得されたハッシュ値と同じである場合、前回提供されたバージョン情報と同じバージョン情報を提供し、前記ハッシュ値が、前回取得されたハッシュ値と異なる場合、前回提供されたバージョン情報と異なるバージョン情報を提供する、
情報処理装置。

【請求項7】

自身のバージョン情報と、通信先サービスのバージョン情報とを提供する提供部と、
アクセスルールに基づいて、前記通信先サービスへのアクセスを制御する制御部と、
アクセス要求に応じて任意の処理を実行するアプリケーション部と、を備え、
前記アクセスルールは、前記自身のバージョン情報と、前記通信先サービスのバージョン情報とに基づいて、前記通信先サービスへのアクセスを許可するか否かを制御する情報を含み、
前記バージョン情報は、前記アプリケーション部のバージョンを示し、
前記提供部は、前記アプリケーション部が前記バージョン情報を有さない場合、所定のテストデータを前記アプリケーション部に実行させた結果が、前回の実行結果と同じである場合、前回提供されたバージョン情報と同じバージョン情報を提供し、所定のテストデータを前記アプリケーション部に実行させた結果が、前回の実行結果と異なる場合、前回提供されたバージョン情報と異なるバージョン情報を提供する、
情報処理装置。

【請求項8】

情報処理装置が、自身のバージョン情報と、通信先サービスのバージョン情報とを提供し、
前記情報処理装置が、アクセスルールに基づいて、前記通信先サービスへのアクセスを制御し、
前記情報処理装置のアプリケーション部が、アクセス要求に応じて任意の処理を実行し、
前記アクセスルールは、前記自身のバージョン情報と、前記通信先サービスのバージョン情報とに基づいて、前記通信先サービスへのアクセスを許可するか否かを制御する情報を含み、
前記バージョン情報は、前記アプリケーション部のバージョンを示し、
前記情報処理装置が、前記アプリケーション部が前記バージョン情報を有さない場合、前記アプリケーション部の更新により変更される所定のデータのハッシュ値を算出し、前記ハッシュ値が、前回取得されたハッシュ値と同じである場合、前回提供されたバージョン情報と同じバージョン情報を提供し、前記ハッシュ値が、前回取得されたハッシュ値と異なる場合、前回提供されたバージョン情報と異なるバージョン情報を提供する、
情報処理方法。

【請求項9】

情報処理装置が、自身のバージョン情報と、通信先サービスのバージョン情報とを提供し、
前記情報処理装置が、アクセスルールに基づいて、前記通信先サービスへのアクセスを制御し、
前記情報処理装置のアプリケーション部が、アクセス要求に応じて任意の処理を実行し、
前記アクセスルールは、前記自身のバージョン情報と、前記通信先サービスのバージョン情報とに基づいて、前記通信先サービスへのアクセスを許可するか否かを制御する情報を含み、
前記バージョン情報は、前記アプリケーション部のバージョンを示し、
前記情報処理装置が、前記アプリケーション部が前記バージョン情報を有さない場合、所定のテストデータを前記アプリケーション部に実行させた結果が、前回の実行結果と同じである場合、前回提供されたバージョン情報と同じバージョン情報を提供し、所定のテストデータを前記アプリケーション部に実行させた結果が、前回の実行結果と異なる場合、前回提供されたバージョン情報と異なるバージョン情報を提供する、
情報処理方法。

【請求項10】

コンピュータに、
自身のバージョン情報と、通信先サービスのバージョン情報とを提供させ、
アクセスルールに基づいて、前記通信先サービスへのアクセスを制御させ、
前記コンピュータのアプリケーション部に、アクセス要求に応じて任意の処理を実行させ、
前記アクセスルールは、前記自身のバージョン情報と、前記通信先サービスのバージョン情報とに基づいて、前記通信先サービスへのアクセスを許可するか否かを制御する情報を含み、
前記バージョン情報は、前記アプリケーション部のバージョンを示し、
前記アプリケーション部が前記バージョン情報を有さない場合、前記アプリケーション部の更新により変更される所定のデータのハッシュ値を算出させ、前記ハッシュ値が、前回取得されたハッシュ値と同じである場合、前回提供されたバージョン情報と同じバージョン情報を提供させ、前記ハッシュ値が、前回取得されたハッシュ値と異なる場合、前回提供されたバージョン情報と異なるバージョン情報を提供させる、
プログラム。

【請求項11】

コンピュータに、
自身のバージョン情報と、通信先サービスのバージョン情報とを提供させ、
アクセスルールに基づいて、前記通信先サービスへのアクセスを制御させ、
前記コンピュータのアプリケーション部に、アクセス要求に応じて任意の処理を実行させ、
前記アクセスルールは、前記自身のバージョン情報と、前記通信先サービスのバージョン情報とに基づいて、前記通信先サービスへのアクセスを許可するか否かを制御する情報を含み、
前記バージョン情報は、前記アプリケーション部のバージョンを示し、
前記アプリケーション部が前記バージョン情報を有さない場合、所定のテストデータを前記アプリケーション部に実行させた結果が、前回の実行結果と同じである場合、前回提供されたバージョン情報と同じバージョン情報を提供させ、所定のテストデータを前記アプリケーション部に実行させた結果が、前回の実行結果と異なる場合、前回提供されたバージョン情報と異なるバージョン情報を提供させる、
プログラム。

【発明の詳細な説明】

【技術分野】

【0001】

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

【背景技術】

【0002】

複数の独立した小さなサービス（マイクロサービス）を通信で連携させ、一つの大きなサービスを提供するというシステム構築手法が、主にクラウド上でのシステムにおいて広く採用されている。このシステム構築手法は、マイクロサービスアーキテクチャと呼ばれる。マイクロサービスアーキテクチャは、各マイクロサービスを独立して個別に開発し、更新可能というメリットがある。一方、あるマイクロサービスが更新され、そのマイクロサービスの入出力仕様や動作が変わった場合に、システム全体が正常に動かなくなる可能性がある。

【先行技術文献】

【特許文献】

【0003】

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

【発明の概要】

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

【0004】

従来の技術では、個別に開発された複数のサービスにより提供されるシステムの動作の安定性をより向上させることが難しかった。

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

【0005】

実施形態の情報処理システムは複数のサービスを通信により連携させることによって構成される情報処理システムである。前記複数のサービスのそれぞれは、提供部と制御部とアプリケーション部とを備える。提供部は、自身のバージョン情報と、通信先サービスのバージョン情報とを提供する。制御部は、アクセスルールに基づいて、前記通信先サービスへのアクセスを制御する。アプリケーション部は、アクセス要求に応じて任意の処理を実行する。前記アクセスルールは、前記自身のバージョン情報と、前記通信先サービスのバージョン情報とに基づいて、前記通信先サービスへのアクセスを許可するか否かを制御する情報を含む。前記バージョン情報は、前記アプリケーション部のバージョンを示す。
前記提供部は、前記アプリケーション部が前記バージョン情報を有さない場合、前記アプリケーション部の更新により変更される所定のデータのハッシュ値を算出し、前記ハッシュ値が、前回取得されたハッシュ値と同じである場合、前回提供されたバージョン情報と同じバージョン情報を提供し、前記ハッシュ値が、前回取得されたハッシュ値と異なる場合、前回提供されたバージョン情報と異なるバージョン情報を提供する。

【図面の簡単な説明】

【0006】

【図1】第１実施形態の情報処理システムの構成の例を示す図。

【図2】第１実施形態のマイクロサービスの機能構成の例を示す図。

【図3】第１実施形態のアクセス要求の受信制御方法の例を示すフローチャート。

【図4】第１実施形態のアクセス要求の送信制御方法の例を示すフローチャート。

【図5】第２実施形態の情報処理システムの構成の例を示す図。

【図6】第２実施形態の仮想外部サービスの機能構成の例を示す図。

【図7】第２実施形態の仮想外部サービスの動作例を示すフローチャート。

【図8】第１及び第２実施形態の情報処理装置のハードウェア構成の例を示す図。

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

【0007】

以下に添付図面を参照して、情報処理システム、情報処理装置、情報処理方法及びプログラムの実施形態を詳細に説明する。

【0008】

（第１実施形態）
はじめに、第１実施形態の情報処理システムの構成の例について説明する。

【0009】

図１は第１実施形態の情報処理システム１００の構成の例を示す図である。第１実施形態の情報処理システム１００は、例えばマイクロサービスアーキテクチャで構成されるクラウドシステムである。

【0010】

マイクロサービスアーキテクチャでは、複数のマイクロサービス（図１の例では、マイクロサービスＡ～Ｄ）が通信することによって連携し、入出力データを受け渡していくことで、１つのサービスが実現される。各マイクロサービスは、例えば１又は複数の情報処理装置（サーバ装置）によって実現される。

【0011】

なお、自システム内のマイクロサービスに限らず、外部のサービスと連携することによって、１つのサービスが実現されてもよい。外部のサービスと連携する場合の例については第２実施形態で説明する。

【0012】

マイクロサービスは、サービス提供要求者あるいは他マイクロサービス（第１のマイクロサービス）から、任意の入力データを受け取ると、当該入力データに任意の処理をし、任意の出力データを返す。任意の処理は、例えば他マイクロサービス（第２のマイクロサービス）へのアクセスや、入力データの解析などである。

【0013】

図１の例では、情報処理システム１００へサービスの提供要求があった場合、サービスの提供要求→マイクロサービスＡ→Ｂ→Ｃ→Ｂ→Ａ→Ｄ→Ａ→サービス応答、の順で、各マイクロサービス内での任意の処理とマイクロサービス間のデータ受け渡しとが行われる。

【0014】

マイクロサービスＡ～Ｄを動かす基盤は、マイクロサービス基盤管理者により管理されている。ただし、個々のマイクロサービス自体は、マイクロサービス開発者等によって、マイクロサービス基盤管理者とは無関係に変更や更新がなされる。なお、外部サービス（第２実施形態参照）は、マイクロサービス基盤管理者によって管理されている基盤とは異なる基盤で動作し、変更や更新も任意になされる。

【0015】

［機能構成の例］
図２は第１実施形態のマイクロサービスＢの機能構成の例を示す図である。第１実施形態のマイクロサービスＢは、アプリケーション部１、振り分け部２、提供部３及び制御部４を備える。なお、マイクロサービスＡ、Ｃ及びＤも、マイクロサービスＢの機能構成と同様である。

【0016】

アプリケーション部１は、従来のアプリケーションと同様に、アクセス要求に応じて任意の処理を実行する。任意の処理は、例えば、マイクロサービスＡおよびＣへのデータ受け渡し処理、及び、データの解析処理などを含む。

【0017】

振り分け部２は、マイクロサービスＡからのアクセス要求を受け付ける。振り分け部２は、アクセス要求がバージョン情報取得要求である場合、当該バージョン情報取得要求を提供部３に振り分ける。振り分け部２は、アクセス要求がバージョン情報取得要求でない場合、当該アクセス要求をアプリケーション部１に振り分ける。

【0018】

提供部３は、所定の方法（後述の図３参照）によって、バージョン情報をアプリケーション部１から取得し、取得されたバージョン情報を返す。バージョン情報は、例えばアプリケーション部１のバージョンを示す。

【0019】

例えば、提供部３は、アプリケーション部１がバージョン情報を有する場合、アプリケーション部１から取得されたバージョン情報を提供する。

【0020】

また例えば、提供部３は、アプリケーション部１がバージョン情報を有さない場合、アプリケーション部１の更新により変更される所定のデータ（例えばプログラム実行ファイル等）のハッシュ値を算出する。そして、提供部３は、ハッシュ値が、前回取得されたハッシュ値と同じである場合、前回提供されたバージョン情報と同じバージョン情報を提供し、ハッシュ値が、前回取得されたハッシュ値と異なる場合、前回提供されたバージョン情報と異なるバージョン情報を提供する。

【0021】

制御部４は、マイクロサービスＢのバージョン情報と、マイクロサービスＣから得たバージョン情報とを元に、マイクロサービスＣにアクセスするか否かを判定することによって、アクセス制御を行う。

【0022】

次に、図２乃至図４を用いて、第１実施形態のマイクロサービスＢの動作例について説明する。

【0023】

［受信制御の例］
図３は第１実施形態のアクセス要求の受信制御方法の例を示すフローチャートである。はじめに、振り分け部２は、マイクロサービスＡからアクセス要求を受信したか否かを判定する（ステップＳ１）。具体的には、振り分け部２は、マイクロサービスＡからマイクロサービスＢ内のアプリケーション部１へのアクセス要求をフック（横取り）することによって、アクセス要求を受信したか否かを判定する。なお、従来の構成では、マイクロサービスＡからのアクセス要求は、マイクロサービスＢ内のアプリケーション部１に直接届く。

【0024】

マイクロサービスＡからアクセス要求を受信した場合（ステップＳ１，Ｙｅｓ）、振り分け部２は、アクセス要求がバージョン情報取得要求であるか否かを判定する（ステップＳ２）。例えばマイクロサービスＢがＷｅｂＡＰＩとして実現されていた場合、バージョン情報取得要求であるか否かは、ＵＲＬのパス名で判定される。具体的には、振り分け部２は、ＵＲＬのパス名が、例えばｈｔｔｐｓ：／／｛マイクロサービスＢのＩＰアドレスやホスト名｝／ｖｅｒｓｉｏｎであれば、アクセス要求がバージョン情報取得要求であると判定する。

【0025】

アクセス要求がバージョン情報取得要求でない場合（ステップＳ２，Ｎｏ）、振り分け部２は、当該アクセス要求をアプリケーション部１に振り分け、アプリケーション部１が、当該アクセス要求に基づく任意の処理を行う（ステップＳ３）。

【0026】

アクセス要求がバージョン情報取得要求である場合（ステップＳ２，Ｙｅｓ）、振り分け部２は、当該アクセス要求を提供部３に振り分け、提供部３が、アプリケーション部１にバージョン情報があるか否かを判定する（ステップＳ４）。具体的には、提供部３は、例えば、アプリケーション部１にバージョン情報を直接表すファイルが存在するか否かを判定する。

【0027】

アプリケーション部１にバージョン情報がある場合（ステップＳ４，Ｙｅｓ）、提供部３は、そのバージョン情報を、バージョン情報取得要求に対する応答として、マイクロサービスＡに返す（ステップＳ５）。

【0028】

アプリケーション部１にバージョン情報がない場合（ステップＳ４，Ｎｏ）、提供部３は、アプリケーション部１のプログラム実行ファイルなど、所定のデータのハッシュ値を取得する（ステップＳ６）。

【0029】

次に、提供部３は、ステップＳ６で取得されたハッシュ値が、前回取得されたハッシュ値と同じであるか否かを判定する（ステップＳ７）。

【0030】

前回取得されたハッシュ値と同じである場合（ステップＳ７，Ｙｅｓ）、提供部３は、前回と同じバージョン情報を、マイクロサービスＡに返す（ステップＳ８）。前回取得されたハッシュ値と同じでない場合（ステップＳ７，Ｎｏ）、提供部３は、前回とは異なるバージョン情報を、マイクロサービスＡに返す（ステップＳ９）。

【0031】

なお、提供部３は、バージョン情報の取得を初めて行った場合には、任意に定められたバージョン情報を、マイクロサービスＡに返す。

【0032】

また、バージョン情報を直接表すファイルの存在有無や、どのファイルが、バージョン情報の参照対象になるのかといった設定は、アプリケーション開発者とマイクロサービス基盤管理者との間で事前に定めておいてもよい。例えば、参照対象になるファイルが事前に分かっている場合は、図３のフローチャートにおいて、常にステップＳ５の処理を実行するようにしてもよい。

【0033】

また、もしアプリケーション部１がその内部にバージョン情報提供機能を直接搭載していることが事前に分かっているのであれば、マイクロサービスＢに振り分け部２及び提供部３を搭載しなくてもよい。

【0034】

また、バージョン情報を直接表すファイルが存在しない場合に、アプリケーション部１内のどのファイルのハッシュ値を参照するかについては、アプリケーション開発者とマイクロサービス基盤管理者との間で事前に定めておいてもよい。

【0035】

また、バージョン情報としてどのような値を返すかは、後述のアクセスルールと合わせてマイクロサービス基盤管理者が任意に定めてよい。例えば、提供部３は、初めてハッシュ値を取得した場合はバージョン１を返し、前回のハッシュ値と異なる場合は、前回のバージョンに＋１をした値をバージョン情報として返してもよい。

【0036】

［送信制御の例］
次に、図４は第１実施形態のアクセス要求の送信制御方法の例を示すフローチャートである。はじめに、制御部４が、マイクロサービスＣへのアクセス要求であるか否かを判定する（ステップＳ１）。具体的には、制御部４は、マイクロサービスＢ内のアプリケーション部１からマイクロサービスＣに届くアクセスをフック（横取り）することによって、一旦保留する。なお、従来の構成では、アプリケーション部１からのアクセス要求は、マイクロサービスＣに直接届く。

【0037】

マイクロサービスＣへのアクセス要求である場合（ステップＳ２１，Ｙｅｓ）、制御部４は、提供部３から、マイクロサービスＢのバージョン情報Ｘを取得する（ステップＳ２２）。

【0038】

次に、制御部４は、マイクロサービスＣのバージョン情報Ｙを取得する（ステップＳ２３）。具体的には、制御部４は、例えばｈｔｔｐｓ：／／｛マイクロサービスＣのＩＰアドレスやホスト名｝／ｖｅｒｓｉｏｎへのアクセスなどにより、マイクロサービスＣのバージョン情報Ｙを取得する。

【0039】

次に、制御部４は、所定のアクセスルールに基づいて、アクセスを許可するか否かを判定する（ステップＳ２４）。例えば、アクセスルールに、「マイクロサービスＢのバージョンＸからのマイクロサービスＣのバージョンＹへのアクセスは許可」と設定されている場合、制御部４は、アクセスを許可する。

【0040】

アクセスを許可する場合（ステップＳ２４，Ｙｅｓ）、制御部４は、アクセス要求をマイクロサービスＣへ送信することによって、マイクロサービスＣにアクセスし、マイクロサービスＣからの応答をアプリケーション部１に返す（ステップＳ２５）。

【0041】

アクセスを許可しない場合（ステップＳ２４，Ｎｏ）、制御部４は、不許可を示す応答を生成し、当該応答をアプリケーション部１に返す（ステップＳ２６）。

【0042】

なお、アクセスルールは、例えばマイクロサービス基盤管理者によって設定される。アクセスルールは、上記の例のように具体的なマイクロサービス名やバージョン値が指定された設定でもよいが、条件による設定がされていてもよい。

【0043】

具体的には、条件による設定は、例えば「アクセス元のバージョンと、アクセス先のバージョンが同じバージョンであれば許可」である。

【0044】

また例えば、条件による設定は、「マイナーバージョンが異なっていてもメジャーバージョンが同一ならば許可」である。この条件の場合、アクセス元のバージョンが６．１であり、アクセス先のバージョンが６．２の場合、メジャーバージョン６が同一のため、アクセスが許可される。

【0045】

また、図４の例では、マイクロサービスＢからマイクロサービスＣへのアクセス要求があった場合に、制御部４が、マイクロサービスＣのバージョン情報を取得したが、制御部４が、事前にマイクロサービスＣのバージョン情報を取得しキャッシュしておいてもよい。

【0046】

バージョン情報をキャッシュする場合、タイミングによってはキャッシュしたバージョン情報と実際のバージョン情報とに齟齬ができるリスクが生じるが、サービス実行時のバージョン情報確認を省ける分、サービス実行時の応答が早くなるというメリットが生じる。リスクの低減のために、キャッシュの有効期限を手動または自動で動的に調整できるとしてもよい。

【0047】

キャッシュの有効期限が自動で調整される場合、例えば、通信先のマイクロサービスの直近の一定期間の更新頻度が高ければ、今後もしばらく高頻度で当該マイクロサービスの更新が続くとみなし、キャッシュの有効期限を短くしてもよい。逆に、通信先のマイクロサービスの直近の一定期間の更新頻度が低ければ、キャッシュの有効期限を長くしてもよい。

【0048】

また、図４の例では、マイクロサービスＣのバージョンに問題がある場合、情報処理システム１００へのサービス要求→マイクロサービスＡ→Ｂ→Ｃ（バージョンに問題あることが判明）→Ｂ→Ａ→サービス提供不可の応答、の順でアクセスが行われるが、例えば下記条件（１）～（３）を満たすことによって応答時間を短縮できる。
＜条件＞
（１）マイクロサービスＢが、事前にマイクロサービスＣのバージョン情報を取得する。
（２）マイクロサービスＢが、マイクロサービスＡに、マイクロサービスＣのバージョン情報を事前に伝達する。
（３）マイクロサービスＢのアクセスルールを、マイクロサービスＡでも保持する。

【0049】

例えば上記条件（１）～（３）を満たす場合、情報処理システム１００へのサービス要求→Ａ（この先のマイクロサービスＣのバージョンに問題あることが既に判明）→サービス提供不可の応答、と即座に応答を返すことができる。

【0050】

以上、説明したように、第１実施形態の情報処理システム１００では、提供部３が、自身のバージョン情報と、通信先サービスのバージョン情報とを提供する。そして、制御部４が、アクセスルールに基づいて、通信先サービスへのアクセスを制御する。アクセスルールは、自身のバージョン情報と、通信先サービスのバージョン情報とに基づいて、通信先サービスへのアクセスを許可するか否かを制御する情報を含む。

【0051】

第１実施形態によれば、各マイクロサービスが、他のマイクロサービスへバージョン情報を提供できるので、バージョン情報に応じた各マイクロサービス間のアクセス制御ができる。これにより、意図しないバージョンのマイクロサービスの実行を防止することが可能となるので、個別に開発された複数のサービス（図１の例では、マイクロサービスＡ～Ｄ）により提供されるシステム（図１の例では、情報処理システム１００）の動作の安定性をより向上させることができる。

【0052】

例えば、マイクロサービスＣが突然更新された場合でも、マイクロサービスＢが、マイクロサービスＣに仕様外のデータを送ってしまうといった問題を防止できる。また例えば、マイクロサービスＣが突然更新された場合でも、マイクロサービスＢが、マイクロサービスＣから仕様外のデータを受け取ってしまうといった問題を防止できる。

【0053】

（第２実施形態）
次に第２実施形態について説明する。第２実施形態の説明では、第１実施形態と同様の説明については省略し、第１実施形態と異なる箇所について説明する。第２実施形態では、図１で示したマイクロサービスＤが外部サービスにアクセスしている場合について説明する。

【0054】

外部サービスにバージョン情報提供機能が直接備わっているのであれば、外部サービスにアクセスしているマイクロサービスＤは、そのバージョン情報を用いて、第１実施形態と同じアクセス制御を行えばよい。しかし、外部サービスにバージョン情報提供機能が直接備わっていない場合、外部サービスはマイクロサービス基盤管理者の管理下にないため、第１実施形態で示したような提供部３を外部サービス側に仕込むことはできない。

【0055】

以下、第２実施形態として、このような外部サービス（例えば、マイクロサービス基盤管理者の管理下にないアプリケーション等）へのアクセスも管理する形態について説明する。

【0056】

図５は第２実施形態の情報処理システム１００－２の構成の例を示す図である。従来の構成では、マイクロサービスＤは外部サービス２００に直接アクセスするが、第２実施形態では、マイクロサービスＤと外部サービス２００との間に、仮想外部サービス１０と呼ぶマイクロサービスが１つ挟まれている。

【0057】

［機能構成の例］
図６は第２実施形態の仮想外部サービス１０の機能構成の例を示す図である。第２実施形態の仮想外部サービス１０は、振り分け部２、提供部３及び記憶部５を備える。

【0058】

振り分け部２は、マイクロサービスＤから受信されたアクセス要求がバージョン情報取得要求だった場合、当該アクセス要求を提供部３に振り分ける。

【0059】

提供部３は、記憶部５にあらかじめ記憶されたバージョン確認用入出力データに従い、外部サービス２００にアクセスする。そして、提供部３は、外部サービス２００から受信された応答に基づいてバージョン情報を、マイクロサービスＤに返す。バージョン確認用入出力データは、例えば所定のテストデータ、及び、当該テストデータの応答として想定されるデータの組である。

【0060】

具体的には、例えば提供部３は、所定のテストデータを外部サービス２００に実行させた結果が、前回の実行結果と同じである場合、前回提供されたバージョン情報と同じバージョン情報を提供し、所定のテストデータを外部サービス２００に実行させた結果が、前回の実行結果と異なる場合、前回提供されたバージョン情報と異なるバージョン情報を提供する。

【0061】

次に、図６および図７を用いて、第２実施形態の仮想外部サービス１０の動作例について説明する。

【0062】

［仮想外部サービスの動作例］
図７は第２実施形態の仮想外部サービス１０の動作例を示すフローチャートである。はじめに、振り分け部２は、マイクロサービスＤからアクセス要求を受信したか否かを判定する（ステップＳ３１）。具体的には、振り分け部２は、マイクロサービスＤから外部サービス２００に送信されるアクセス要求をフック（横取り）することによって、アクセス要求を受信したか否かを判定する。

【0063】

マイクロサービスＤからアクセス要求を受信した場合（ステップＳ３１，Ｙｅｓ）、振り分け部２は、アクセス要求がバージョン情報取得要求であるか否かを判定する（ステップＳ３２）。

【0064】

アクセス要求がバージョン情報取得要求でない場合（ステップＳ３２，Ｎｏ）、振り分け部２は、当該アクセス要求を外部サービス２００に転送後、外部サービス２００からの応答をそのままマイクロサービスＤに返す（ステップＳ３３）。

【0065】

アクセス要求がバージョン情報取得要求である場合（ステップＳ３２，Ｙｅｓ）、振り分け部２は、当該アクセス要求を提供部３に振り分け、提供部３が、所定の入力データを用いて外部サービス２００にアクセスする（ステップＳ３４）。

【0066】

所定の入力データは、例えばマイクロサービス基盤管理者によってあらかじめ設定されたバージョン確認用入力データである。なお、複数のバージョン確認用入力データが、所定の順序で外部サービス２００へ送信されてもよい。

【0067】

次に、提供部３が、外部サービス２００からの応答が所定の出力データと等しいか否かを判定する（ステップＳ３５）。所定の出力データは、例えばバージョン確認用入力データに応じたバージョン確認用出力データである。具体的には、バージョン確認用出力データは、複数のバージョン確認用入力データを、外部サービス２００に与えた時に得られる複数の応答を列挙したデータである。

【0068】

外部サービス２００からの応答が所定の出力データと等しい場合（ステップＳ３５，Ｙｅｓ）、提供部３は、外部サービス２００に変更は生じていないとみなし、前回と同じバージョン情報をマイクロサービスＤへ返す（ステップＳ３６）。

【0069】

外部サービス２００からの応答が所定の出力データと異なる場合（ステップＳ３５，Ｎｏ）、提供部３は、外部サービス２００に変更が生じているとみなし、前回と異なるバージョン情報をマイクロサービスＤへ返す（ステップＳ３７）。この場合、提供部３は、バージョン確認用出力データを、今回得られた応答データで上書きする。

【0070】

なお、バージョン確認用出力データを更新せず、あくまでマイクロサービス基盤管理者があらかじめ設定したバージョン確認用出力データと応答とが一致するかのみを判定してもよい。具体的には、提供部３は、例えばマイクロサービス基盤管理者が期待する応答であればバージョンＸを返し、期待する応答と異なるのであればバージョンＹを返してもよい。

【0071】

また、上述のステップＳ３５において、複数回のアクセスによる応答がすべて期待通りであるという条件以外に、応答までの時間などの性能の条件を更に判定してもよい。すなわち、提供部３は、応答がすべて期待通りであっても、所定の入力データの送信から応答までの時間が前回の時間または想定した時間とは異なる場合、前回と異なるバージョン情報をマイクロサービスＤへ返してもよい。所定の入力データの送信から応答までの時間が前回の時間または想定した時間とは異なるかどうかは、例えば、前回の応答時間または応答時間の想定値との差分が閾値より大きいか否かによって判定される。

【0072】

以上、説明したように、第２実施形態により、マイクロサービスＤは、仮想外部サービス１０経由で、外部サービス２００からバージョン情報を得ることができるようになる。このため、第１実施形態と同様に、マイクロサービスＤが外部サービス２００へのバージョン情報に応じたアクセス可否を判断できるようになる。

【0073】

従来は、マイクロサービスを更新するか否かを管理できている前提であり、一部のマイクロサービスが突然、更新されるといった状況は考慮されていなかった。具体的には、例えば、マイクロサービス群が自システム内のマイクロサービスだけでなく外部サービス（図６の例では、外部サービス２００）をも参照している場合、その外部サービスが突然更新されたといった状況は考慮されていなかった。

【0074】

また、サービス全体に対する入出力データは考慮されていても、当該サービスに含まれる個別のマイクロサービス間の入出力データは考慮されていなかった。このため、サービス全体に対する入出力データを確認する過程で、一部のマイクロサービスに仕様外の入力データが届き、意図しない処理が実行されてしまう問題があった。

【0075】

また、サービスを構成する各マイクロサービスの更新（変更）有無のチェックをする過程で、各マイクロサービスを動作させると、サービス要求者に対し意図しない出力を返してしまう可能性があった。

【0076】

一方、第２実施形態によれば、例えば、外部サービス２００が突然更新された場合でも、マイクロサービスＤが、外部サービス２００に仕様外のデータを送ってしまう問題を防止できる。また例えば、第２実施形態によれば、外部サービス２００が突然更新された場合でも、マイクロサービスＤが、外部サービス２００から仕様外のデータを受け取ってしまう問題を防止できる。

【0077】

最後に、第１及び第２実施形態のマイクロサービスＡ～Ｄ、仮想外部サービス１０及び外部サービス２００を実現する情報処理装置（サーバ装置）のハードウェア構成の例について説明する。

【0078】

［ハードウェア構成の例］
図８は第１及び第２実施形態の情報処理装置のハードウェア構成の例を示す図である。第１及び第２実施形態のマイクロサービスＡ～Ｄ、仮想外部サービス１０及び外部サービス２００は、例えば制御装置２０１、主記憶装置２０２、補助記憶装置２０３、表示装置２０４、入力装置２０５及び通信装置２０６を備える１又は複数の情報処理装置（サーバ装置）によって実現される。

【0079】

制御装置２０１、主記憶装置２０２、補助記憶装置２０３、表示装置２０４、入力装置２０５及び通信装置２０６は、バス２１０を介して接続されている。

【0080】

制御装置２０１は、補助記憶装置２０３から主記憶装置２０２に読み出されたプログラムを実行する。主記憶装置２０２は、ＲＯＭ及びＲＡＭ等のメモリである。補助記憶装置２０３は、ＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）及びメモリカード等である。

【0081】

表示装置２０４は、例えば液晶ディスプレイ等である。入力装置２０５は、情報処理装置を操作するためのインタフェースである。入力装置２０５は、例えばキーボード及びマウス等である。なお、表示装置２０４及び入力装置２０５は、表示機能と入力機能とを有するタッチパネル等により実現されていてもよい。

【0082】

通信装置２０６は、情報処理装置が他の装置と通信するためのインタフェースである。

【0083】

情報処理装置で実行されるプログラムは、インストール可能な形式又は実行可能な形式のファイルでＣＤ－ＲＯＭ、メモリカード、ＣＤ－Ｒ及びＤＶＤ等のコンピュータで読み取り可能な記憶媒体に記録されてコンピュータ・プログラム・プロダクトとして提供される。

【0084】

また情報処理装置で実行されるプログラムを、インターネット等のネットワークに接続されたコンピュータ上に格納し、ネットワーク経由でダウンロードさせることにより提供するように構成してもよい。また情報処理装置で実行されるプログラムをダウンロードさせずにインターネット等のネットワーク経由で提供するように構成してもよい。

【0085】

また情報処理装置のプログラムを、ＲＯＭ等に予め組み込んで提供するように構成してもよい。

【0086】

情報処理装置で実行されるプログラムは、上述した図２及び６の機能構成のうち、プログラムによっても実現可能な機能を含むモジュール構成となっている。当該各機能は、実際のハードウェアとしては、制御装置２０１が記憶媒体からプログラムを読み出して実行することにより、上記各機能ブロックが主記憶装置２０２上にロードされる。すなわち上記各機能ブロックは主記憶装置３０２上に生成される。

【0087】

なお上述した図２及び６の各機能の一部又は全部をソフトウェアにより実現せずに、ＩＣ等のハードウェアにより実現してもよい。

【0088】

また複数のプロセッサを用いて各機能を実現する場合、各プロセッサは、各機能のうち１つを実現してもよいし、各機能のうち２以上を実現してもよい。

【0089】

本発明のいくつかの実施形態を説明したが、これらの実施形態は、例として提示したものであり、発明の範囲を限定することは意図していない。これら新規な実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。これら実施形態やその変形は、発明の範囲や要旨に含まれるとともに、特許請求の範囲に記載された発明とその均等の範囲に含まれる。

【0090】

例えば、第１及び第２実施形態の動作を組み合わせてもよい。具体的には、例えば提供部３が、アプリケーション部１がバージョン情報を有さない場合、所定のテストデータをアプリケーション部１に実行させた結果が、前回の実行結果と同じである場合、前回提供されたバージョン情報と同じバージョン情報を提供し、所定のテストデータをアプリケーション部１に実行させた結果が、前回の実行結果と異なる場合、前回提供されたバージョン情報と異なるバージョン情報を提供してもよい。

【符号の説明】

【0091】

Ａ～Ｄ マイクロサービス
１ アプリケーション部
２ 振り分け部
３ 提供部
４ 制御部
５ 記憶部
１００ 情報処理システム
２００ 外部サービス
２０１ 制御装置
２０２ 主記憶装置
２０３ 補助記憶装置
２０４ 表示装置
２０５ 入力装置
２０６ 通信装置
２１０ バス

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】