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

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

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

(11)【特許番号】

(24)【登録日】2024-09-30

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

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

(51)【国際特許分類】

   G06F 11/36 20060101AFI20241001BHJP

【ＦＩ】

G06F11/36 184

G06F11/36 188

【請求項の数】 7

(21)【出願番号】P 2020152583

(22)【出願日】2020-09-11

(65)【公開番号】P2022046934

(43)【公開日】2022-03-24

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

(73)【特許権者】

【識別番号】000004237

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

(74)【代理人】

【識別番号】100149548

【弁理士】

【氏名又は名称】松沼 泰史

(74)【代理人】

【識別番号】100181135

【弁理士】

【氏名又は名称】橋本 隆史

(72)【発明者】

【氏名】後藤 忍

【審査官】久々宇 篤志

(56)【参考文献】

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

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

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

【文献】米国特許出願公開第２０１４／０２８２４２２（ＵＳ，Ａ１）

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

Ｇ０６Ｆ １１／３６

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

【請求項1】

ロードバランサと、
テスト前のアプリケーションの中に配置され、本番環境で前記アプリケーションをテストする第１のコンテナと、
を備え、
前記アプリケーションは、前記本番環境にリリースされ、
前記第１のコンテナは、前記本番環境において、前記ロードバランサからのリクエストと、前記リクエストに対するレスポンスと、に基づいて前記テストを実施する、
情報処理システム。

【請求項2】

前記アプリケーションの中に配置されるテスト用のフロントエンドである第２のコンテナをさらに備え、
前記第１のコンテナは、前記本番環境において、前記ロードバランサからのリクエストを受信すると前記リクエストを前記第２のコンテナに転送し、前記第２のコンテナからのレスポンスを受信すると、前記リクエストと前記レスポンスとに基づいて前記テストを実施する、
請求項１に記載の情報処理システム。

【請求項3】

前記第１のコンテナは、前記テストとして前記リクエストに対する前記レスポンスの妥当性を確認する、
請求項１又は請求項２に記載の情報処理システム。

【請求項4】

前記テストは、前記リクエストに対して期待通りの前記レスポンスが返信されているか、又は、前記レスポンスが一定の時間内に返信されているか、を確認することである、
請求項３に記載の情報処理システム。

【請求項5】

第１のコンテナは、前記テストの結果、問題がない場合には前記アプリケーションのリリースを判断するための一定の基準をクリアしたか否かを判定し、前記基準をクリアした場合には、前記アプリケーションをロールアウトする、
請求項１から４のいずれか一項に記載の情報処理システム。

【請求項6】

テスト前のアプリケーションの中にテスト用のコンテナが配置されており、情報処理システムが本番環境に前記アプリケーションをリリースし、前記本番環境において前記情報処理システムの前記コンテナがロードバランサからのリクエストと前記リクエストに対するレスポンスとに基づいて前記アプリケーションのテストを実施する、
情報処理方法。

【請求項7】

コンピュータに、
テスト前のアプリケーションを本番環境にリリースさせ、前記アプリケーションの中に配置されたテスト用のコンテナに前記本番環境においてロードバランサからのリクエストと、前記リクエストに対するレスポンスと、に基づいて前記アプリケーションのテストをさせる処理、
を実行させるプログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、情報処理システム、情報処理方法及びプログラムに関する。

【背景技術】

【0002】

一般に、コンテナなどのＷｅｂＡＰＩで結合されるシステムのアプリケーション（ＡＰ）を開発する際は、まず開発環境でＡＰを開発・テストし、その後で本番環境にリリースするという運用をとる。

【0003】

また、リリースする際には、カナリアリリース等の技術を用いて、ロードバランサでトラフィックを段階的に新バージョンのＡＰに切り替える、または問題発生時にロールバックする、といった手段をとることが多い。このようなロードバランサを用いたリリース機能は、Ｋｕｂｅｒｎｅｔｅｓのような業界標準のコンテナ基盤ソフトウェアに組み込まれているため、一般的に利用できる。また、ＫａｙｅｎｔａといったＯＳＳのように、メトリックスを収集、分析することでカナリアリリースにおける本番リリースを自動化するための技術もある。

【先行技術文献】

【特許文献】

【0004】

【文献】特開２０１６－１４９０４３号公報

【発明の概要】

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

【0005】

ただし、既存のリリース機能では、開発環境でテストを行うことが前提であるため、テストが終わるまで本番環境にリリースできず、またテストデータを入力とするため有効なテストが難しいといった課題がある。

【0006】

そこでこの発明は、上述の課題を解決する情報処理システム、情報処理方法及びプログラムを提供することを目的としている。

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

【0007】

本実施形態の第一の態様によれば、情報処理システムは、ロードバランサと、テスト前のアプリケーションの中に配置され、本番環境で前記アプリケーションをテストする第１のコンテナと、を備え、前記アプリケーションは、前記本番環境にリリースされ、前記第１のコンテナは、前記本番環境において、前記ロードバランサからのリクエストと、前記リクエストに対するレスポンスと、に基づいて前記テストを実施する。

【0008】

本実施形態の第二の態様によれば、情報処理方法は、テスト前のアプリケーションの中にテスト用のコンテナが配置されており、本番環境に前記アプリケーションをリリースし、前記本番環境において前記コンテナがロードバランサからのリクエストと前記リクエストに対するレスポンスとに基づいて前記アプリケーションのテストを実施する。

【0009】

本実施形態の第三の態様によれば、プログラムは、コンピュータに、テスト前のアプリケーションを本番環境にリリースさせ、前記アプリケーションの中に配置されたテスト用のコンテナが前記本番環境においてロードバランサからのリクエストと、前記リクエストに対するレスポンスと、に基づいて前記アプリケーションのテストさせる処理、を実行させる。

【発明の効果】

【0010】

本発明によれば、テスト前のアプリケーションを本番環境でテストすることができる。

【図面の簡単な説明】

【0011】

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

【図2】第１の実施形態に係る情報処理システムの処理フローを示す図である。

【図3】第２の実施形態に係る情報処理システムの構成の一例を示す図である。

【図4】情報処理装置の最小構成の一例を示す図である。

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

【0012】

（第１の実施形態）
以下、第１の実施形態の情報処理システムを、図面を参照して説明する。

【0013】

図１は、第１の実施形態に係る情報処理システム１００の構成の一例を示す図である。

【0014】

情報処理システム１００は、コンテナの動作環境を提供するコンテナ基盤システムである。ここで、コンテナとは、アプリケーションを動作させるために必要なライブラリやアプリケーションを一つにまとめたものである。情報処理システム１００は、Kubernetesなどのコンテナオーケストレーションツールであって、コンテナを統合管理する。

【0015】

また、情報処理システム１００は、コンテナなどのＷｅｂＡＰＩで結合されるシステムの新バージョンのアプリケーション（ＡＰ）が開発される場合において、そのＡＰのテストを実行する。その際、情報処理システム１００は、そのＡＰを開発環境でテストを実行するのではなく、ＡＰを本番環境にリリースしてその本番環境においてＡＰのテストを実行する。情報処理システム１００は、本番環境のトラフィックの中で、ＷｅｂＡＰＩのリクエストとレスポンスをキャプチャしながら妥当性をテストし、一定の基準を満たした時点で正式リリースする。図１に示す情報処理システム１００の構成は、本番環境において、新バージョンのＡＰのテストを実施するための構成である。

【0016】

情報処理システム１００は、１以上のコンピュータ（情報処理装置）によって構成される。情報処理システム１００は、コンテナ基盤管理機能部１１０、ロードバランサ１２０、旧ＡＰ１３０、開発ＡＰ１４０、及び新ＡＰ１５０を備える。

【0017】

コンテナ基盤管理機能部１１０は、情報処理システム１００の全体を管理する。

【0018】

ロードバランサ１２０は、リリース機能を実現するための機能である。

【0019】

旧ＡＰ１３０は、情報処理システム１００にデプロイされている。旧ＡＰ１３０は、フロントエンド１３１とよぶ単一のコンテナで構成されるアプリケーション（ＡＰ）である。フロントエンド１３１は、ＷｅｂＡＰＩ（Application Programming Interface）を介してクライアント２００にサービスを提供する。

【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】

１００ 情報処理システム
１１０ コンテナ基盤管理機能部
１２０ ロードバランサ
１３０ 旧ＡＰ
１４０ 開発ＡＰ
１４１ フロントエンド
１４２ バリデータ
１５０ 新ＡＰ

【図1】

【図2】

【図3】

【図4】