特許 6958726 アプリケーション実行装置、アプリケーション実行方法、およびプログラム

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

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

(11)【特許番号】6958726

(24)【登録日】2021年10月11日

(45)【発行日】2021年11月2日

(54)【発明の名称】アプリケーション実行装置、アプリケーション実行方法、およびプログラム

(51)【国際特許分類】

   G06F 8/65 20180101AFI20211021BHJP

   G06F 9/455 20060101ALI20211021BHJP

【ＦＩ】

   G06F8/65

   G06F9/455 150

【請求項の数】7

【全頁数】15

(21)【出願番号】特願2020-507792(P2020-507792)

(86)(22)【出願日】2019年3月18日

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

(87)【国際公開番号】WO2019181860

(87)【国際公開日】20190926

【審査請求日】2020年7月10日

(31)【優先権主張番号】特願2018-55456(P2018-55456)

(32)【優先日】2018年3月23日

(33)【優先権主張国】JP

(73)【特許権者】

【識別番号】000004237

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

(74)【代理人】

【識別番号】100109313

【弁理士】

【氏名又は名称】机 昌彦

(74)【代理人】

【識別番号】100124154

【弁理士】

【氏名又は名称】下坂 直樹

(72)【発明者】

【氏名】岡田 好大

【審査官】 石川 亮

(56)【参考文献】

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

【文献】 内田 誠悟，ビルド環境の構築とＤｏｃｋｅｒイメージのビルド 本番運用を見据えたイメージの作り方，ＷＥＢ＋ＤＢ ＰＲＥＳＳ，日本，技術評論社，2015年05月25日，第86巻，pp.99-105.

【文献】 村井 和夫，Ｃ＆Ｃ＋＋コンパイラ／リンカ／アセンブラ／デバッガ… 全部タダでＭｙパソコンに！ ＡＲＭ用ＬＬＶＭ＆ＧＣＣ開発環境の構築，Ｉｎｔｅｒｆａｃｅ，日本，ＣＱ出版株式会社，2015年03月01日，第41巻,第3号，pp.57-64.

【文献】 中村 憲一，組み込みＬｉｎｕｘ活用技法入門：３ クロス環境での構築手法を中心とした組み込みＬｉｎｕｘカーネル構築の実際，Ｉｎｔｅｒｆａｃｅ，日本，ＣＱ出版株式会社，2002年03月01日，第28巻,第3号，pp.29-38.

【文献】 安田 幸弘，一度は作ってみたい！ 俺流Ｌｉｎｕｘ［前編］，Ｌｉｎｕｘ ＷＯＲＬＤ，日本，（株）ＩＤＧジャパン，2006年09月01日，第5巻,第9号，pp.63-94.

【文献】 菊間 一宏 他，大規模通信ソフト開発環境へのＯＳＳツール適用の評価，電子情報通信学会技術研究報告，日本，一般社団法人電子情報通信学会，2016年11月17日，第116巻,第322号，pp.61-66.

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

Ｇ０６Ｆ ８／６５

Ｇ０６Ｆ ９／４５５

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

【請求項1】

コンテナ型仮想化技術を用いて構築される業務システムに含まれるアプリケーション実行装置であって、
コンテナ上で動作するアプリケーションを定義するコンテナ定義ファイルの更新を検出する更新検出手段と、
更新が検出された場合、前記コンテナ定義ファイルをビルドすることにより生成されるコンテナイメージのデータ量を軽減させるために、前記コンテナ定義ファイルおよび前記コンテナイメージの各内容を変更する内容変更手段と
を備え、
前記内容変更手段は、更新が検知された前記コンテナ定義ファイルを解析してビルド命令を特定し、更新が検知された前記コンテナ定義ファイルに、特定された前記ビルド命令が実行された後に、実行に使用されたソースファイルを削除する削除命令を書き加え、前記削除命令が書き加えられた前記コンテナ定義ファイルのビルドを実行し、
前記コンテナ定義ファイルが更新されてから更新についてのデプロイが完了するまでの全体時間を算出し、前記全体時間が、予め決定された上限時間を超えるか否かを判定し、前記全体時間が前記上限時間を超える場合、前記コンテナイメージに含まれるレイヤの構造を再構築する
ことを特徴とするアプリケーション実行装置。

【請求項2】

前記再構築は、古い前記構造を一旦取り払うとともにメタデータを排除することにより複数の前記レイヤを１つの前記レイヤに統合する処理であることを特徴とする請求項１に記載のアプリケーション実行装置。

【請求項3】

前記内容変更手段は、
前記削除命令が書き加えられた前記コンテナ定義ファイルのビルドを実行する際、前記ビルドの時間であるビルド時間を計測し、
コンテナの起動時間を計測し、前記起動時間と前記ビルド時間とを用いて前記全体時間を算出する
ことを特徴とする請求項１または２に記載のアプリケーション実行装置。

【請求項4】

前記上限時間は、前記業務システムに要求される性能に基づいて決定されることを特徴とする請求項１から３のいずれか１項に記載のアプリケーション実行装置。

【請求項5】

マスタとして動作するマスタ側アプリケーション実行装置と、
前記マスタ側アプリケーション実行装置と接続され、スレーブとして動作するスレーブ側アプリケーション実行装置と、を備え、
前記マスタ側アプリケーション実行装置および前記スレーブ側アプリケーション実行装置は、請求項１から４のいずれか１項に記載される前記アプリケーション実行装置である
ことを特徴とする業務システム。

【請求項6】

コンテナ型仮想化技術を用いて構築される業務システムに含まれるアプリケーション実行装置におけるアプリケーション実行方法であって、
コンテナ上で動作するアプリケーションを定義するコンテナ定義ファイルの更新を検出し、
更新が検出された場合、前記コンテナ定義ファイルをビルドすることにより生成されるコンテナイメージのデータ量を軽減させるために、前記コンテナ定義ファイルおよび前記コンテナイメージの各内容を変更し、
各内容の変更が、更新が検知された前記コンテナ定義ファイルを解析してビルド命令を特定し、更新が検知された前記コンテナ定義ファイルに、特定された前記ビルド命令が実行された後に、実行に使用されたソースファイルを削除する削除命令を書き加え、前記削除命令が書き加えられた前記コンテナ定義ファイルのビルドを実行し、
前記コンテナ定義ファイルが更新されてから更新についてのデプロイが完了するまでの全体時間を算出し、前記全体時間が、予め決定された上限時間を超えるか否かを判定し、前記全体時間が前記上限時間を超える場合、前記コンテナイメージに含まれるレイヤの構造を再構築する
ことを特徴とするアプリケーション実行方法。

【請求項7】

コンテナ型仮想化技術を用いて構築される業務システムに含まれるアプリケーション実行装置のコンピュータに、
コンテナ上で動作するアプリケーションを定義するコンテナ定義ファイルの更新を検出する更新検出処理と、
更新が検出された場合、前記コンテナ定義ファイルをビルドすることにより生成されるコンテナイメージのデータ量を軽減させるために、前記コンテナ定義ファイルおよび前記コンテナイメージの各内容を変更する内容変更処理と
を実行させるためのプログラムであって、
前記内容変更処理は、更新が検知された前記コンテナ定義ファイルを解析してビルド命令を特定し、更新が検知された前記コンテナ定義ファイルに、特定された前記ビルド命令が実行された後に、実行に使用されたソースファイルを削除する削除命令を書き加え、前記削除命令が書き加えられた前記コンテナ定義ファイルのビルドを実行する処理と、
前記コンテナ定義ファイルが更新されてから更新についてのデプロイが完了するまでの全体時間を算出し、前記全体時間が、予め決定された上限時間を超えるか否かを判定し、前記全体時間が前記上限時間を超える場合、前記コンテナイメージに含まれるレイヤの構造を再構築する処理と
であるプログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、アプリケーション実行装置、アプリケーション実行方法、およびプログラムに関する。

【背景技術】

【0002】

ビッグデータなどの大規模なデータを扱う業務システムを構築する際、コンテナ型仮想化技術が採用されるケースが増えてきている。コンテナ型仮想化は、仮想化の一種であり、１つのＯＳ（Operating System）に、コンテナといわれる「独立したサーバと同様の振る舞いをする区画」を複数作り、それを個別のユーザ／サービスに割り当てるものである。コンテナには個別にＣＰＵ（Central Processing Unit）／メモリ／ストレージなどを割り当てる必要がない。従って、コンテナ型仮想化を用いた業務システムの場合、システムリソースのオーバーヘッドは少なくて済む。

【0003】

一方で、近年、ＤｅｖＯｐｓが注目されており、上記業務システムもこのＤｅｖＯｐｓを満足することが求められている。ＤｅｖＯｐｓとは、開発（Development）と運用（Operations）とが協力し、ビジネス要求に対して、より柔軟に、スピーディに対応できるシステムを作り上げるための取り組みのことを指す。なお、現時点においては、ＤｅｖＯｐｓについての厳密な定義はない。

【0004】

上記に関連して、例えば、特許文献１には、アップデート命令を受信したコンテナ管理部が、現在のコンテナを削除（停止）し、コンテナテンプレートの更新を行うことが記載されている。ここで、コンテナテンプレートの更新とは、新コンテナテンプレートをダウンロードすることであってもよいし、コンテナ収容装置に予め格納されている新コンテナテンプレートを読み出すことであってもよいとの記載がある。

【先行技術文献】

【特許文献】

【0005】

【特許文献1】特開２０１７−１１１７６１号公報

【発明の概要】

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

【0006】

コンテナ型仮想化を用いた業務システムにおいてアプリケーションを最新の状態で動作させるためには、アプリケーションの更新が必要である。その場合、更新内容をコンテナイメージに反映し、更新されたコンテナイメージを実行環境にデプロイする必要がある。上記において、コンテナイメージとは、アプリケーションをコンテナ上で動作させるために必要なファイルを一纏めにしたイメージファイルのことである。また、デプロイは、ソフトウェアシステムを利用可能にする活動全般のことを指す。

【0007】

しかしながら、コンテナイメージの作成には手間が掛かり、かつそのビルド（たとえば、コンパイル／リンク）には時間が掛かる場合がある。

【0008】

また、コンテナイメージでは、アプリケーションの更新に伴う実行環境へのデプロイの度に、これまでのファイルシステムの差分情報（ソースファイルの差分ファイル）がレイヤとして蓄積されている。従って、アプリケーションの更新を繰り返す度に、デプロイ完了までの時間が次第に増大していく虞がある。時間の増大を回避するため、業務システムの運用者自身による定期的なメンテナンス作業（コンテナイメージの整理）が実施されているが、これは運用者にとってかなりの手間となる。

【0009】

すなわち、コンテナ型仮想化技術を用いて構築される業務システムの開発において、一般的なオンプレミス環境（自社運用環境）での業務システムの開発に比べ、アプリケーションの開発および運用（ＤｅｖＯｐｓ）を効率的に実施するための仕組みがあまり提案されていないのが実情である。

【0010】

本発明は、上記課題を解決するためになされたものであり、コンテナ型仮想化技術を用いて構築される業務システムにおけるアプリケーションの開発および運用を効率化させることが可能な技術を提供することを目的とする。

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

【0011】

本発明のアプリケーション実行装置は、コンテナ型仮想化技術を用いて構築される業務システムに含まれるアプリケーション実行装置であって、コンテナ上で動作するアプリケーションを定義するコンテナ定義ファイルの更新を検出する更新検出手段と、更新が検出された場合、前記コンテナ定義ファイルをビルドすることにより生成されるコンテナイメージのデータ量を軽減させるために、前記コンテナ定義ファイルおよび前記コンテナイメージの各内容を変更する内容変更手段と、を備える。

【0012】

本発明のアプリケーション実行方法は、コンテナ型仮想化技術を用いて構築される業務システムに含まれるアプリケーション実行装置におけるアプリケーション実行方法であって、コンテナ上で動作するアプリケーションを定義するコンテナ定義ファイルの更新を検出し、更新が検出された場合、前記コンテナ定義ファイルをビルドすることにより生成されるコンテナイメージのデータ量を軽減させるために、前記コンテナ定義ファイルおよび前記コンテナイメージの各内容を変更することを特徴とする。

【0013】

本発明のプログラムは、コンテナ型仮想化技術を用いて構築される業務システムに含まれるアプリケーション実行装置のコンピュータに、コンテナ上で動作するアプリケーションを定義するコンテナ定義ファイルの更新を検出する更新検出処理と、更新が検出された場合、前記コンテナ定義ファイルをビルドすることにより生成されるコンテナイメージのデータ量を軽減させるために、前記コンテナ定義ファイルおよび前記コンテナイメージの各内容を変更する内容変更処理と、を実行させる。

【発明の効果】

【0014】

本発明によれば、コンテナ型仮想化技術を用いて構築される業務システムにおけるアプリケーションの開発および運用を効率化させることができる。

【図面の簡単な説明】

【0015】

【図1】本発明の第１の実施形態に係るアプリケーション実行装置の構成例を示すブロック図である。

【図2】図１に示すアプリケーション実行装置の動作例（アプリケーション実行方法）を説明するためのフローチャートである。

【図3】本発明の第２の実施形態に係る業務システムの構成例を示すブロック図である。

【図4】図３に示されるコンテナイメージ生成部の構成例を示すブロック図である。

【図5】図３に示されるコンテナ管理部の構成例を示すブロック図である。

【図6】図３に示されるアプリケーション実行装置の第１の動作例（アプリケーション実行方法）を説明するためのフローチャートである。

【図7】中間ファイル（ソースファイル）を削除するためにビルド実行ステップを書き換える処理を説明するための図である。

【図8】中間ファイル（ソースファイル）の削除によりコンテナイメージが軽量化される様子を示す図である。

【図9】図３に示されるアプリケーション実行装置の第２の動作例（アプリケーション実行方法）を説明するためのフローチャートである。

【図10】レイヤ統合によるコンテナイメージ更新処理を説明する図である。

【図11】本発明の第３の実施形態に係るアプリケーション実行システムの構成例を示すブロック図である。

【図12】本発明の第４の実施形態に係るアプリケーション実行装置の構成例を示すブロック図である。

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

【0016】

［第１の実施形態］
図１は、本発明の第１の実施形態に係るアプリケーション実行装置５００の構成例を示すブロック図である。

【0017】

アプリケーション実行装置５００は、コンテナ型仮想化技術を用いて構築される業務システム（図１において不図示）に含まれる。コンテナおよびコンテナ型仮想化技術については、［背景技術］にて説明済みである。

【0018】

アプリケーション実行装置５００は、更新検出部５０１（更新検出手段および更新検出処理の一例）と、内容変更部５０２（内容変更手段および内容変更処理の一例）と、を備える。

【0019】

更新検出部５０１は、コンテナ上で動作するアプリケーションを定義するコンテナ定義ファイルの更新を検出する。内容変更部５０２は、更新が検出された場合、コンテナ定義ファイルをビルドすることにより生成されるコンテナイメージのデータ量を軽減させるために、コンテナ定義ファイルおよびコンテナイメージの各内容を変更する。

【0020】

アプリケーション実行装置５００は、例えば、ＩＣ（Integrated Circuit）やＦＰＧＡ（Field Programmable Gate Array）等の電子回路で構成されてもよい。あるいは、アプリケーション実行装置５００は、コンピュータ（たとえば、ＣＰＵ（Central Processing Unit））がメモリに記憶されたプログラムを実行する構成であってもよい。もちろん、アプリケーション実行装置５００は、電子回路とコンピュータの組み合わせにて構成されてもよい。

【0021】

図２は、図１に示すアプリケーション実行装置５００の動作例（アプリケーション実行方法）を説明するためのフローチャートである。

【0022】

更新検出部５０１は、コンテナ上で動作するアプリケーションを定義するコンテナ定義ファイルの更新を検出する（ステップＳ１００）。

【0023】

更新が検出された場合、内容変更部５０２は、コンテナイメージのデータ量を軽減させるために、コンテナ定義ファイルおよびコンテナイメージの各内容を変更する（ステップＳ１０１）。

【0024】

なお、アプリケーション実行装置５００の詳細な構成および動作については、第２の実施形態にて説明する。

【0025】

以上説明した第１の実施形態によれば、コンテナへのアプリケーションの反映に必要なコンテナ定義ファイルの作成や更新の度に発生する、ビルドからコンテナへのデプロイまでの作業のすべてはアプリケーション実行装置５００にて自動的に実行される。従って、更新に費やされる時間の増大を回避するために、業務システムの運用者自身によって定期的に実行されるメンテナンス作業を不要とすることができる。

【0026】

さらに、第１の実施形態では、コンテナイメージを軽量化させるための処理がアプリケーション実行装置５００によって自動的に実行されるので、コンテナに対するアプリケーションの更新に費やされる時間を短縮することができる。

【0027】

すなわち、以上説明した第１の実施形態によれば、コンテナ型仮想化技術を用いて構築される業務システムにおけるアプリケーションの開発および運用を効率化させることができる。
［第２の実施形態］
（構成の説明）
図３は、本発明の第２の実施形態に係る業務システム１００の構成例を示すブロック図である。業務システム１００は、アプリケーション実行装置１と、データストレージ２００と、を備える。

【0028】

アプリケーション実行装置１は、図１に示すアプリケーション実行装置５００を基本とする構成を含み、少なくとも１つのアプリケーションを、コンテナ型仮想化技術を用いて実行する。アプリケーションで実行される業務は、例えば、商品需要予測、販売価格予測、会計管理業務、顧客管理業務、商品管理業務、生産管理業務、または給与管理業務である。もちろん、アプリケーションが実行する業務は、上記に限定されない。また、アプリケーション実行装置１は、物理マシンおよび仮想マシンのどちらであってもよい。

【0029】

アプリケーション実行装置１は、更新検出部１０と、コンテナイメージ生成部２０と、コンテナイメージ管理部３０と、コンテナ管理部４０と、記憶部５０と、少なくとも１つのコンテナ６０と、を備える。更新検出部１０は、図１の更新検出部５０１の構成を含む。また、コンテナイメージ生成部２０とコンテナイメージ管理部３０とコンテナ管理部４０とをまとめたものは、図１の内容変更部５０２の具体例に対応する。

【0030】

更新検出部１０は、コンテナ６０上で動作するアプリケーションを定義するコンテナ定義ファイルの更新を検出する。コンテナ定義ファイルの更新が検出された場合、更新検出部１０は、コンテナイメージ生成部２０に対して、更新されたコンテナ定義ファイルを用いてコンテナイメージを更新するよう指示する。

【0031】

コンテナイメージ生成部２０およびコンテナ管理部４０の詳細については後述する。

【0032】

コンテナイメージ管理部３０は、コンテナイメージをリポジトリ形式で管理するとともに、コンテナイメージの更新を通知する。

【0033】

記憶部５０は、アプリケーション実行装置１内で動作する各処理部が出力したファイルやイメージを保存する。

【0034】

コンテナ６０は、少なくとも１つ設けられ、割り当てられた所定のアプリケーションを実行する。

【0035】

データストレージ２００は、アプリケーションが使用する各種のファイルやデータを格納する。たとえば、データストレージ２００は、コンテナ定義ファイルを格納する。

【0036】

図４は、図３に示されるコンテナイメージ生成部２０の構成例を示すブロック図である。コンテナイメージ生成部２０は、図４に示されるように、ビルド実行部２１と、ビルド時間計測部２２と、コンテナ定義ファイル解析部２３と、コンテナ定義ファイル書替部２４と、コンテナイメージ書替部２５と、を備える。

【0037】

ビルド実行部２１は、コンテナ定義ファイルをビルドする。ビルド時間計測部２２は、ビルドに費やされた処理時間を計測する。コンテナ定義ファイル解析部２３は、更新が検知されたコンテナ定義ファイルの内容を解析する。コンテナ定義ファイル書替部２４は、更新されたコンテナ定義ファイルの内容を変更する。コンテナイメージ書替部２５は、ビルドを実行するときにコンテナイメージの構成（たとえば、レイヤ構造）を再構築する。

【0038】

図５は、図３に示されるコンテナ管理部４０の構成例を説明するブロック図である。コンテナ管理部４０は、リソース制御部４１と、上限時間超過判定部４２と、を備える。

【0039】

リソース制御部４１は、コンテナの起動に必要なリソースを制御する。上限時間超過判定部４２は、全体の処理時間（後述）が、予め決定された上限時間（後述）を超えるか否かを判定する。

【0040】

なお、図３および図４における各部の接続はあくまで一例である。
（動作の説明）
以下、本実施形態の業務システム１００におけるデプロイ環境の更新動作について説明する。

【0041】

なお、以下の説明において、コンテナ型仮想化の一例である、例えば、Ｄｏｃｋｅｒ（登録商標）が使用される場合を想定している。また、デプロイ対象のシステム構成は、ＲＰＭ（Red Hat package managerまたはRPM Package Manager）などの一般的なパッケージで構成されるものとして説明する。さらに、以下の動作が実行される前に、業務システム１００の運用者により、予め、デプロイ環境が更新されるまでの上限時間が設定されているものとする。上限時間は、例えば、業務システム１００に要求される性能に基づいて決定される。上限時間は、例えば、記憶部５０に記憶される。

【0042】

図６は、図３に示されるアプリケーション実行装置１の第１の動作例（アプリケーション実行方法）を説明するための図であり、詳細には、実行環境が構築されるまでの動作を説明するフローチャートである。

【0043】

更新検出部１０は、データストレージ２００に格納されているいずれかのコンテナ定義ファイルが更新されたか否かを検出する（ステップＳ１）。更新が検出されない場合（ステップＳ１にてＮｏ）、ステップＳ１の処理が再度実行される。

【0044】

更新が検知された場合（ステップＳ１のＹｅｓ）、更新検出部１０は、コンテナイメージ生成部２０に対して、ビルド（更新が検知されたコンテナ定義ファイルを用いてコンテナイメージを更新する処理）の実行を指示する。

【0045】

コンテナイメージ生成部２０のコンテナ定義ファイル解析部２３は、更新検出部１０からの指示に応じて、更新が検知されたコンテナ定義ファイルを解析し、ビルド命令（たとえば、ｍａｋｅ、またはｒｐｍｂｕｉｌｄ）を特定する（ステップＳ２）。

【0046】

コンテナイメージ生成部２０のコンテナ定義ファイル書替部２４は、データストレージ２００内の、更新されたコンテナ定義ファイルの内容を変更する（ステップＳ３）。ここで、ステップＳ２で特定されたビルド命令に記述されたソースファイルは、デプロイ環境の更新によって実行環境が構築されるまで（すなわち、ビルド命令によりビルドが完了するまで）のいわば中間ファイルであり、実行環境の構築後は不要となるファイルである。そこで、ステップＳ３において、コンテナ定義ファイル書替部２４は、当該ビルド命令の実行時に使用されるソースファイルをビルド命令の実行完了後に削除するための削除命令を、更新が検知されたコンテナ定義ファイルに書き加える。

【0047】

コンテナイメージ生成部２０のビルド実行部２１は、このように削除命令の追加によって書き替えられたコンテナ定義ファイルのビルドを、ステップＳ２で特定されたビルド命令に従って実行する（ステップＳ４）。すなわち、ビルド実行部２１は、コンテナイメージ書替部２５に指示し、コンテナイメージ書替部２５は、データストレージ２００に格納されたコンテナイメージの構成、たとえば、レイヤ構造を再構築（または、更新とも言う）する。

【0048】

コンテナ定義ファイルのビルドを実行する際、コンテナイメージ生成部２０のビルド時間計測部２２は、上記ビルドの処理時間であるビルド時間を計測する（ステップＳ５）。計測されたビルド時間は、例えば、記憶部５０に格納される。更新検出部１０は、ビルドの実行により更新されたコンテナイメージをコンテナイメージ管理部３０に格納する。コンテナイメージ管理部３０は、コンテナ管理部４０に対して、コンテナイメージが更新された旨の更新通知を送信する（ステップＳ６）。

【0049】

図７は、ソースファイルを削除するためにコンテナ定義ファイル中のビルドの実行ステップを書き換える処理（ステップＳ３の処理）を説明するための図である。図７に示すように、ステップＳ３で変更後の命令行には、ソースファイル（/xxx/yyy/src）を削除するための「ｒｍ」コマンドが追加される。ｒｍコマンドを追加することで、ソースファイルがコンテナイメージに追加されるのが禁止される。

【0050】

図８は、ソースファイルの削除によりコンテナイメージが軽量化される様子を示す図である。図８から諒解されるように、図６に示すフローの実行により、Ｌａｙｅｒ３において、ソースファイル（差分ファイル）はコンテナイメージ管理部３０に格納されず、実行環境へのデプロイに必要なファイル（aaa.rpm）のみが格納されるようになる。

【0051】

図９は、図３に示されるアプリケーション実行装置１の第２の動作例（アプリケーション実行方法）を説明するための図であり、詳細には、コンテナ起動時の動作を説明するフローチャートである。図９のフローチャートに示される処理は、通常、図６のフローチャートに示される処理が完了した後に実行される。

【0052】

図５に示すコンテナ管理部４０のリソース制御部４１は、コンテナイメージ管理部３０からの更新通知を受信する（ステップＳ１０）。リソース制御部４１は、稼働中のコンテナを順次停止させ、更新された新しいコンテナイメージをコンテナイメージ管理部３０から取得してコンテナ６０を起動する（ステップＳ１１）。

【0053】

コンテナ管理部４０の上限時間超過判定部４２は、コンテナの起動時間を計測する（ステップＳ１２）。計測した起動時間は、例えば、記憶部５０に格納される。上限時間超過判定部４２は、起動時間と計測済みのビルド時間（図４のステップＳ５参照）とを用いて、コンテナ定義ファイルが更新されてからその更新についてのデプロイが完了するまでの全体時間を算出する（ステップＳ１３）。

【0054】

上限時間超過判定部４２は、全体の処理時間が、予め決定された上限時間を超えるか否かを判定する（ステップＳ１４）。全体の処理時間が上限時間を超えない場合（ステップＳ１４のＮｏ）、本フローは終了する。

【0055】

上限時間を超える場合（ステップＳ１４のＹｅｓ）、コンテナイメージ書替部２５は、コンテナイメージ管理部３０に格納されるコンテナイメージに含まれるレイヤ構造を再構築する（ステップＳ１５）。具体的には、図１０に示されるように、コンテナイメージ書替部２５は、古いレイヤ構造（図１０のＬａｙｅｒ１〜３）を一旦取り払うとともにメタデータを排除することにより、複数のレイヤ（Ｌａｙｅｒ１〜３）を１つのレイヤ（Ｌａｙｅｒ１）に統合する。メタデータとは、あるデータそのものではなく、そのデータを表す属性や関連する情報を記述したデータのことである。図１０には、メタデータが排除されることにより軽量化し、且つ１つに纏められたＬａｙｅｒ１が示されている。
（効果の説明）
以上説明した第２の実施形態によれば、コンテナへのアプリケーションの反映に必要なコンテナ定義ファイルの作成や更新の度に発生する、ビルドからコンテナへのデプロイまでの作業のすべてはアプリケーション実行装置１にて自動的に実行される。従って、更新に費やされる時間の増大を回避するために、業務システムの運用者自身によって定期的に実行されるメンテナンス作業を不要とすることができる。

【0056】

さらに、第２の実施形態では、コンテナイメージを軽量化させるための様々な処理が、アプリケーション実行装置１によって自動的に実行されるので、コンテナに対するアプリケーションの更新に費やされる時間を短縮することができる。様々な処理とは、例えば、中間ファイルであるソースファイルを削除するための削除命令を追加する処理や、メタデータを排除しレイヤを１つに統合する処理である。

【0057】

すなわち、以上説明した第２の実施形態によれば、コンテナ型仮想化技術を用いて構築される業務システム１００におけるアプリケーションの開発および運用を効率化させることができる。
［第３の実施形態］
図１１は、本発明の第３の実施形態に係る業務システム５５０の構成例を示すブロック図である。業務システム５５０は、マスタとして動作するマスタ側アプリケーション実行装置５６０と、スレーブとして動作するスレーブ側アプリケーション実行装置５７０と、を備える。

【0058】

マスタ側アプリケーション実行装置５６０とスレーブ側アプリケーション実行装置５７０とは、インターネット等のネットワーク５８０を介して接続される。

【0059】

マスタ側アプリケーション実行装置５６０およびスレーブ側アプリケーション実行装置５７０は、例えば、第１の実施形態および第２の実施形態のいずれか一方のアプリケーション実行装置とすることができる。

【0060】

以上説明した第３の実施形態のように、アプリケーション実行装置を分散配置することにより、アプリケーションの開発および運用をより一層効率的に実施することが可能となる。
［第４の実施形態］
図１２は、本発明の第４の実施形態に係るアプリケーション実行装置６００の構成例を示すブロック図であり、詳細には、図１に示すアプリケーション実行装置５００、または図３に示すアプリケーション実行装置１を、コンピュータによって実現したアプリケーション実行装置６００のブロック図である。

【0061】

アプリケーション実行装置６００は、記憶装置６０２と、プロセッサ等を含む演算装置６０４（コンピュータ）と、を備える。記憶装置６０２は、コンピュータ読み取り可能な記録媒体であり、コンピュータプログラム６５０を記憶する。コンピュータプログラム６５０は、例えば、第１の実施形態で説明した動作や第２の実施形態で説明した動作を演算装置６０４に実行させるためのプログラムである。

【0062】

なお、演算装置６０４の例としては、例えば、プログラムを読み取り実行する、１つまたはそれ以上のＣＰＵと、ＣＰＵが実行する命令を記憶するメモリを挙げることができる。また、コンピュータ読み取り可能な記録媒体は、例えば、非一時的な記憶装置である。非一時的な記憶装置の例としては、例えば、光ディスク、磁気ディスク、ＲＯＭ（Read Only Memory）、不揮発性半導体メモリ等の可搬媒体、コンピュータシステムに内蔵されるハードディスクを挙げることができる。また、コンピュータ読み取り可能な記録媒体は、一時的な記憶装置であってもよい。一時的な記憶装置の例としては、例えば、インターネット等のネットワークや電話回線等の通信回線を介してプログラムを送信する場合の信号線、あるいは、コンピュータシステム内部の揮発性メモリを挙げることができる。

【0063】

以上説明した第４の実施形態によれば、第１および第２の実施形態と同様に、コンテナ型仮想化技術を用いて構築される業務システムにおけるアプリケーションの開発および運用を効率化させることができる。

【0064】

以上、各実施形態を用いて本発明を説明したが、本発明の技術的範囲は、上記各実施形態の記載に限定されない。上記各実施形態に多様な変更又は改良を加えることが可能であることは当業者にとって自明である。従って、そのような変更又は改良を加えた形態もまた本発明の技術的範囲に含まれることは説明するまでもない。また、以上説明した各実施形態において使用される、数値や各構成の名称等は例示的なものであり適宜変更可能である。

【0065】

この出願は、２０１８年 ３月２３日に出願された日本出願特願２０１８−０５５４５６を基礎とする優先権を主張し、その開示の全てをここに取り込む。

【符号の説明】

【0066】

１ アプリケーション実行装置
１０ 更新検出部
２０ コンテナイメージ生成部
２１ ビルド実行部
２２ ビルド時間計測部
２３ コンテナ定義ファイル解析部
２４ コンテナ定義ファイル書替部
２５ コンテナイメージ書替部
３０ コンテナイメージ管理部
４０ コンテナ管理部
４１ リソース制御部
４２ 上限時間超過判定部
５０ 記憶部
６０ コンテナ
５００ アプリケーション実行装置
５０１ 更新検出部
５０２ 内容変更部
５５０ 業務システム
５６０ マスタ側アプリケーション実行装置
５７０ スレーブ側アプリケーション実行装置
５８０ ネットワーク
６００ アプリケーション実行装置
６０２ 記憶装置
６０４ 演算装置
６５０ コンピュータプログラム

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】