JP2020518073A - モノリシックレガシーアプリケーションに基づくマイクロサービスのコンテナ化展開 - Google Patents

Abstract

本開示は、非一過性媒体に記憶されたコンピュータ命令において実装されるスケーラブルコンテナベースのシステムを提供する。本開示はさらに、スケーラブルコンテナベースのシステムを作成し、動作させる方法を提供する。一実施形態において、方法は、レガシーコンピューティング環境において実行可能なモノリシックレガシーアプリケーションを解析し、そのプログラムファイルを区分し、モノリシックレガシーアプリケーションによって実施可能な複数のトランザクションに対応する複数のトランザクション定義ベクトルを作成し、各トランザクションのために、そのトランザクションによって呼び出される全てのプログラムを識別することを含む。

Description

本発明は、コンテナ化、スケーラブル、かつフレキシブルな動作環境において実行されるマイクロサービスとしての展開のためにモノリシックレガシーアプリケーションを区分するための技法およびシステムに関する。

レガシーメインフレームコンピューティング環境では、数千、さらには数万の個々のプログラムを含むモノリシックアプリケーションを見出すことが、一般的であり、個々のプログラムの全てが、単一の動作環境内で非常にモノリシックな構造において一緒に実行される。プログラムのこのモノリシック構造は、それらの基礎コードの開発における時間および資源の相当な投資（最大数千人年）を表し得、ソフトウェアプログラムの相互依存性質は、１つのコンピュータ環境からのコードの変換または移行を非常に困難にする。

レガシープログラムファイルは、多くの場合、レガシーシステムまたはレガシープラットフォームの一部と称される特定のアーキテクチャのプロセッサおよび命令セットにおいてのみ実行するようにコンパイルされ、アセンブルされ、制約とリンクされ得る。

図１Ａは、ハイパーバイザ仮想化を使用するレガシープラットフォーム（１００）の要素を描写する。システムハードウェア（１０）は、例えば、多くの場合、仮想マシンモニタ（ｚ／ＶＭ）としてハイパーバイザ（３０）を実行するメインフレームコンピュータを含み得、ハイパーバイザ（３０）は、完全に分離された仮想マシンの組（７０）を提供し、仮想マシンの組（７０）の各々は、それ自身のゲストオペレーティングシステム（ＯＳ）を有し、プログラムは、典型的に、ゲストオペレーティングシステムにおいて実行される。ハイパーバイザ（３０）は、ホストマシンのリソースを仮想またはゲストマシン（７０）の組に区分する管理プラットフォームを提供し、ゲストマシン（７０）は、レガシーシステム内で独立して動作可能である。１つのゲストオペレーティングシステム（４０）または複数のゲストオペレーティングシステム（４０）が、仮想マシン内にインストールされる。バイナリおよびライブラリプログラムの組（５０）と１つ以上のアプリケーション（６０）とが、次いで、所与の仮想マシン上で実行される。物理マシンのように、仮想マシンは、関連付けられた状態情報を有し、バックアップまたは復元されることができ、専用システムリソースを割り当てられ得る。ハイパーバイザシステムにおける仮想マシンの起動および破棄は、相当なオーバーヘッドを要求し、この理由から、確立されると、仮想マシンは、典型的には、相当な実行時間にわたって持続する。

図１Ｂは、コンテナ管理システム（１１０）の例を描写する。コンテナシステムのハードウェア（１５）は、例えば、Ｘ８６ベースのコンピュータであり得る物理サーバまたは物理サーバのクラスタであり得る。Ｌｉｎｕｘ（登録商標）等のシステムのホストオペレーティングシステムカーネル（２５）は、プラットフォームによって共有され、コンテナ（７５）の組が、Ｄｏｃｋｅｒ等のコンテナ管理システム（３５）を通してイネーブルにされる。特に、Ｌｉｎｕｘ（登録商標）カーネルの名前空間およびｃｇｒｏｕｐ機能性は、コンテナ化のために使用され得る。コンテナ管理システムは、カーネル機能性の周囲のラッパとして提供され、展開等のコンテナ管理を可能にし得る。

Ａｍａｚｏｎ ＡＣＳ、Ａｚｕｒｅ Ｃｏｎｔａｉｎｅｒ Ｓｅｒｖｉｃｅ、Ｃｌｏｕｄ Ｆｏｕｎｄｒｙ Ｄｉｅｇｏ、ＣｏｒｅＯＳ Ｆｌｅｅｔ、 Ｄｏｃｋｅｒ Ｓｗａｒｍ、Ｇｏｏｇｌｅ Ｃｏｎｔａｉｎｅｒ Ｅｎｇｉｎｅ、もしくはＭｅｓｏｓｐｈｅｒｅ Ｍａｒａｔｈｏｎコンテナ管理システム、または他のコンテナ管理および編成システム等の他のコンテナ管理システムも、使用されることができる。コンテナ管理システム（３５）および共有オペレーティングシステムライブラリ（８５）の組は、コンテナ（７５）の組が実行し得るプラットフォームを提供する。例えば、基本ファイル入力／出力（Ｉ／Ｏ）機能のために使用されるそれら等のいくつかの低レベルオペレーティングシステムライブラリ（３５）は、個々のコンテナ内に常駐するのではなく、オペレーティングシステムカーネルまたはコンテナ管理システムを通して全てのコンテナによって共有され得る。

仮想マシンの場合のように、バイナリおよびライブラリプログラム（５５）の組および１つ以上のアプリケーション（６５）が、コンテナ（７５）の組内で実行される。例として、ｈｔｔｐプロトコル等のウェブアクセスサービスを提供するライブラリは、いくつかのアプリケーションでのみ必要とされ、その他では必要とされないこともあり、したがって、特定のアプリケーションサービスのために要求されるとき、ライブラリプログラム（５５）内に含まれるが、ウェブアクセスサービスを決して使用しないアプリケーションのみを伴うコンテナのライブラリプログラム（５５）から省略されるであろう。

仮想マシンと比較して、コンテナは、比較的に軽量の構造であり、それ自身の完全オペレーティングシステムのオーバーヘッドおよび物理または仮想マシンに関連付けられる状態情報の全てを負わせられない。結果として、コンテナの起動および破棄は、オーバーヘッドを殆ど要求せず、それは、コンテナの展開および終了をアプリケーションアップグレード、動的負荷分散、およびクラスタ内のリソース分配のための効果的な技法にする。

特に、仮想マシンは、それら自身のオペレーティングシステム、ファイルシステム、プロセッサ、ネットワークアダプタ、および関連付けられる記憶ボリュームを有する。それらがハイパーバイザを経由してゲストオペレーティングシステムを実行するという事実は、互いに重なる２つのオペレーティングシステム（ハイパーバイザ＋ゲストオペレーティングシステム）を実行するオーバーヘッドを伴う仮想マシンを鈍重なプロセスにし、鈍重なプロセスは、アプリケーションサービスの変化する要求に適応するために容易に起動および終了されることができない。一方、コンテナは、カーネルダイレクトアクセスおよび記憶ボリュームを含む他の物理リソースを通してコアオペレーティングシステム機能を共有する。記憶ボリュームは、典型的には、固定ディスクドライブ上に常駐するが、フラッシュドライブ、テープ、または他の固定もしくは取り外し可能な記憶媒体を含む他の大容量記憶装置内にも常駐し得る。異なるコンテナの挙動は、それらの特定のコンテナの中にロードされたイメージに組み込まれるバイナリおよびライブラリプログラムに基づいて異なり得るが、共有オペレーティングシステムサービスの使用は、コンテナの各個々のインスタンスに関連付けられるオーバーヘッドを有意に低減させる。この理由から、コンテナは、仮想マシンに対して軽量であり、それは、アプリケーション要求に応答するコンテナのインスタンス化および終了をより適したものにする。実際に、例えば、Ｄｏｃｋｅｒを実行するＫｕｂｅｒｎｅｔｅｓコンテナ管理システムの場合、コンテナは、数分の１秒で起動されることができる。その理由から、大規模な展開は、毎秒数千のそれらのコンテナを起動および終了し得る。

コンテナ管理システムは、ポッドも含み得る。ポッドは、コンテナシステムにおける展開単位であり、同じホストまたはクラスタ上で一緒に展開される１つ以上のコンテナを含む。Ｋｕｂｅｒｎｅｔｅｓ等のいくつかのコンテナ管理システムでは、ポッド内のコンテナは、同じネットワーク名前空間およびポート空間を共有する。加えて、ポッドに取り付けられる記憶装置の共有ボリュームが、ポッドのコンテナのうちの１つ以上のものの中に搭載され得る。

標準的Ｌｉｎｕｘ（登録商標）ディストリビューションは、数万（さらには数十万）の個々のファイルを含み、そのようなシステムが使用されるアプリケーションに応じて、プラットフォームに機能性を追加する数千の追加のシステムパッケージと組み合わせられ得る。そのようなパッケージの例は、Ａｐａｃｈｅウェブサーバ、Ｊａｖａ（登録商標）仮想マシン、ＰｏｓｔｇｒｅＳＱＬ、またはデータベースもしくは言語サポート等を提供するための他のパッケージを含む。これらのパッケージは、パッケージおよびパッケージと他のライブラリとの間の依存性を記述するプログラムコードおよびメタデータを含む。共有ライブラリは、膨大な機能性を提供するために動的にリンクされたパッケージによって使用されることができるが、Ｌｉｎｕｘ（登録商標）イメージのフットプリントおよびシステム管理の複雑性を大幅に増加させ得る。ごく少数のパッケージを組み込むＬｉｎｕｘ（登録商標）の最小インスタンスは、メモリの数メガバイトののみを占有し得る。一方、例えば、高度なデータベースサービスを伴う大規模アプリケーションウェブサーバをサポートするために使用される多くのパッケージを伴う大規模なインストールは、記憶装置の数百メガバイト以上を占有し得る。Ｌｉｎｕｘ（登録商標）ベースのプラットフォームの管理は、多くの場合、パッケージとライブラリとの間の依存性と、それらのライブラリおよびパッケージの定期的なアップグレードとを管理するために、パッケージマネージャソフトウェアの使用を含む。一度に複数の標的を供給する大きいイメージは、単純のものより管理が複雑である。

マイクロサービスは、典型的には、アプリケーションの機能性を提供するために一緒に緊密に連携し得る小規模な自律的サービスである。マイクロサービスの自律的性質は、それらがネットワーク呼び出しを通して他のサービスと通信し得る分離されたサービスとして互いに独立して展開されることを可能にする。密接に関連するマイクロサービスの組、または、それらの動作時、共通ボリュームへのアクセスを共有するマイクロサービスは、同じポッド内で展開され得る。マイクロサービスアーキテクチャは、クラスタ化システム上での管理性、利用可能性、スケーラビリティ、および展開性の重量な利点を提供する。しかしながら、多くのレガシーアプリケーションのモノリシック性質は、そのようなモノリシックアプリケーションを最小限に相互依存性のマイクロサービスの組に変換することを困難にし、手作業の多いタスクにする。問題をさらに複雑にするものとして、Ｃｏｂｏｌで書き込まれ、それらの専用ＡＰＩを伴うＭＶＳまたはｚ／ＯＳ等のレガシーアーキテクチャ上で実行するようにコンパイルされたレガシーモノリシックアプリケーションは、概して、命令セットおよびＡＰＩの差異に起因して、特に、ｘ８６サーバに基づくとき、レガシーアーキテクチャからエクスポートされず、Ｌｉｎｕｘ（登録商標）または他のオペレーティングシステムもしくはクラスタ上に実行されることができない。

より一般的には、エミュレーション、クロスコンパイル、トランスコーディング、またはハイブリッドアプローチのどれを通すかにかかわらず、アプリケーションコードを１つの動作環境から別のものに変換するシステムが、コンパイルされたレガシープログラムの実行が、異なる基礎アーキテクチャを使用するゲストオペレーティングシステム上で実行されることを可能にするように開発されることができる。しかしながら、そのようなシステムは、それ自体が容易に拡張しない大規模プログラムである傾向があり、それは、大量のトランザクションボリュームを実施するアプリケーションを実行する場合、特に問題となる。加えて、エミュレーションまたはトランスコーディングシステムは、モノリシックアプリケーションに適している。何故なら、有用であるために、エミュレータまたはトランスコーダが、ゲスト環境内でレガシー環境の可能な命令の未知のサブセットを実行することが可能でなければならないからである。

本発明は、非一過性媒体に記憶されたコンピュータ命令において実装されるスケーラブルコンテナベースのシステムを提供する。本発明は、複数のトランザクションを実施するためのレガシーコンピューティング環境において実行可能な複数のプログラムを含むモノリシックレガシーアプリケーションのソースコードを含むソースコードリポジトリを含む。システムは、ソースコードを解析し、複数のトランザクションにおける各トランザクションのために、トランザクション中に潜在的に呼び出される各プログラムを識別するトランザクション定義ベクトルを識別し、複数のトランザクション定義ベクトルを作成するように動作可能であるソースコードアナライザも含む。システムは、複数のトランザクション定義ベクトルを記憶するように動作可能であるトランザクション状態定義リポジトリも含む。システムは、複数のトランザクションの少なくとも一部において実施するときにモノリシックレガシーアプリケーションによって実際に使用されるプログラムを識別する動的定義リポジトリを作成するように動作可能であるアクティビティログアナライザも含む。システムは、複数のトランザクション定義ベクトルを動的定義リポジトリと比較し、使用されないプログラムをトランザクション定義ベクトルから除去し、複数のマイクロサービスを定義する複数のマイクロサービス定義ベクトルを作成するように動作可能であるマイクロサービス定義オプティマイザも含む。システムは、複数のマイクロサービス定義ベクトルの各マイクロサービス定義ベクトルのために、マイクロサービス定義ベクトルによって識別された各プログラムのために、レガシーコンピューティング環境において実行するようにコンパイルされたコンパイル済みソースコードバイナリを見つけ、マイクロサービス定義ベクトルに対応する複数のマイクロサービスイメージを形成するように動作可能であるマイクロサービスイメージビルダも含む。システムは、複数のマイクロサービスイメージを記憶するように動作可能であるマイクロサービスイメージリポジトリも含む。システムは、レガシーエミュレータのエミュレータ要素のバイナリイメージの組を記憶するように動作可能である相補的コンポーネントリポジトリであって、バイナリイメージの組は、合わせて、完全なレガシーエミュレータより小さく、イメージは、レガシーコンピューティング環境の複数の機能または機能の組に対応し、イメージは、レガシー環境の命令セットと異なる命令セットによって特徴付けられる異なるコンピュータ環境において実行可能である、相補的コンポーネントリポジトリも含む。システムはまた、コンテナビルダであって、コンテナビルダは、複数のマイクロサービスにおける各マイクロサービスまたはマイクロサービスの組のためのコンテナイメージを形成するように動作可能であり、複数のコンテナイメージを作成するために、コンテナビルダは、マイクロサービスイメージリポジトリからの対応するマイクロサービスイメージまたは複数のイメージを使用することと、レガシーエミュレータのエミュレータ要素のためのイメージファイルを相補的コンポーネントリポジトリから使用することとを行い、レガシーエミュレータのエミュレータ要素は、実行されるときにマイクロサービスまたはマイクロサービスの組によって採用される機能または機能の組に対応し、採用される機能または機能は、マイクロサービスまたはマイクロサービスの組におけるバイナリ内の呼び出しのシグネチャによって識別される、コンテナビルダも含む。システムは、異なるコンピューティング環境において実行可能な複数のコンテナイメージを記憶するように動作可能であるコンテナイメージリポジトリも含む。システムは、異なるコンピューティング環境における実行のための少なくとも１つのコンテナを作成し、少なくとも１つのコンテナにおけるコンテナイメージリポジトリに記憶された少なくとも１つのマイクロサービスを実行するように動作可能であるコンテナ管理システムも含む。

明確に互いに排他的ではない限り、その全てが上記システムと互いに、および上記システムと任意の組み合わせで組み合わせられ得る、さらなる実施形態によると、本発明は、以下も提供する。
ｉ）アクティビティログアナライザは、複数のトランザクション定義ベクトルの少なくとも一部に対応する複数の動的トランザクション定義ベクトルを作成するように動作可能であり、マイクロサービス定義オプティマイザは、各動的トランザクション定義ベクトルを各対応するトランザクション定義ベクトルと比較し、複数のマイクロサービス定義ベクトルを作成する。
ｉｉ）アクティビティログアナライザは、レガシーコンピューティング環境においてモノリシックレガシーアプリケーションを実行することによって生成されるモノリシックレガシーアプリケーションのレガシーアクティビティログを使用する。
ｉｉｉ）アクティビティログアナライザは、エミュレータを使用し、モノリシックレガシーアプリケーションを実行し、ログファイルを生成し、トランザクションの実行中にモノリシックレガシーアプリケーションによって使用されるプログラムを決定する。
ｉｖ）ソースコードアナライザは、アクティビティログアナライザからの情報を使用し、トランザクション定義ベクトルを識別するように動作可能である。
ｖ）ソースコードアナライザは、複数の変換テーブルを作成するようにさらに動作可能である。
ｖｉ）マイクロサービス定義オプティマイザは、マイクロサービス定義ベクトルをさらに最適化するように動作可能である。
ｖｉｉ）マイクロサービス定義オプティマイザは、複数のトランザクションにおける２つ以上のトランザクションによって共有されるプログラムを含む追加のマイクロサービス定義ベクトルを作成することによって、マイクロサービス定義ベクトルをさらに最適化するように動作可能である。
ｖｉｉｉ）レガシーコンピューティング環境において実行するようにコンパイルされたバイナリを含むコンパイル済みソースコードを記憶するように動作可能なバイナリリポジトリをさらに含む。
ｉｘ）バイナリリポジトリ内のコンパイル済みソースコードは、ソースコードリポジトリ内のソースコードからバイナリファイルにコンパイルされる。
ｘ）レガシーコンピューティング環境は、多重仮想記憶（ＭＶＳ）またはｚ／ＯＳコンピュータシステムを含む。
ｘｉ）相補的コンポーネントリポジトリは、レガシーエミュレータによって使用されるオペレーティングシステムソフトウェアパッケージの複数のイメージを記憶するようにさらに動作可能であり、コンテナビルダも、レガシーエミュレータの特定の要素によって使用される任意のソフトウェアパッケージのイメージをレガシーエミュレータの特定の要素を含む特定のコンテナイメージに設置する。
ｘｉｉ）コンテナビルダは、マイクロサービスまたはマイクロサービスの組におけるバイナリ内の呼び出しのシグネチャをレガシーエミュレータにおいて動作可能な呼び出しのための命令と置換するようにさらに動作可能である。
ｘｉｉｉ）コンテナ管理システムは、複数のコンテナを作成するように動作可能である。
ｘｉｖ）相補的イメージの組が、共通ポッド内の別個のコンテナの中でインスタンス化される。
ｘｖ）少なくとも１つのコンテナイメージの２つ以上のコピーが、２つ以上の別個のコンテナの中でアクティブにされる。
ｘｖｉ）コンテナ管理システムは、複数のコンテナにおけるコンテナの数を変動させるように動作可能である。
ｘｖｉｉ）コンテナ管理システムは、様々なリソースを別個のコンテナに分配するように動作可能である。
ｘｖｉｉｉ）コンテナ管理システムは、アクティビティログアナライザからの情報を使用し、２つ以上の別個のコンテナの中に設置すべき少なくとも１つのコンテナイメージのコピーの数を決定すること、複数のコンテナにおけるコンテナの数を決定すること、および／または、別個のコンテナに分配すべきリソースを決定することを行うように動作可能である。
ｘｉｘ）コンテナ管理システムは、スケーラブルコンテナベースのシステムの使用からの情報を使用し、２つ以上の別個のコンテナの中に設置すべき少なくとも１つのコンテナイメージのコピーの数を決定すること、複数のコンテナにおけるコンテナの数を決定すること、および／または、別個のコンテナに分配すべきリソースを決定することを行うように動作可能である。
ｘｘ）ソースコードアナライザは、モノリシックレガシーアプリケーションのデータベースから１つ以上のサブデータベースまたはサブデータベースのクラスタを作成するようにさらに動作可能である。
ｘｘｉ）コンテナビルダは、１つ以上のサブデータベースまたはサブデータベースのクラスタを１つ以上のコンテナの中に設置するように動作可能である。
ｘｘｉｉ）ソースコードが変更されると、ソースコード変更に基づいて更新されたバイナリを含むために、コンテナベースのシステムは、少なくとも１つのマイクロサービスイメージ、少なくとも１つのコンテナイメージ、および少なくとも１つのコンテナを自動的に更新するように動作可能である。

本発明はさらに、スケーラブルコンテナベースのシステムを作成し、動作させる方法を提供する。方法は、レガシーコンピューティング環境において実行可能なモノリシックレガシーアプリケーションを解析し、そのプログラムファイルを区分し、モノリシックレガシーアプリケーションによって実施可能な複数のトランザクションに対応する複数のトランザクション定義ベクトルを作成し、各トランザクションのために、そのトランザクションによって呼び出される全てのプログラムを識別することを含む。方法は、トランザクション状態リポジトリに複数のトランザクション定義ベクトルを記憶することをさらに含む。方法は、複数のトランザクションの少なくとも一部のために、トランザクションがモノリシックレガシーアプリケーションによって実施されるときに実際に使用されるプログラムを決定することによって、動的定義リポジトリを作成することをさらに含む。方法は、複数のトランザクション定義ベクトルを動的定義リポジトリと比較し、その対応するトランザクション定義ベクトルからトランザクションにおいて使用されないプログラムを除去し、複数のマイクロサービス定義ベクトルを作成することをさらに含む。方法は、複数のマイクロサービスベクトルの各マイクロサービス定義ベクトルのために、レガシーコンピューティング環境において実行するようにコンパイルされたバイナリを含む対応するコンパイル済みソースコードを見つけ、対応するコンパイル済みソースコードを含むマイクロサービスイメージを作成し、複数のマイクロサービスイメージを形成することをさらに含む。方法は、マイクロサービスイメージリポジトリに複数のマイクロサービスイメージを記憶することをさらに含む。方法は、相補的コンポーネントリポジトリにおいて、レガシーコンピューティング環境と異なるコンピューティング環境においてプログラムを実行するように動作可能なレガシーエミュレータの複数の要素のイメージを記憶することであって、レガシーエミュレータの要素は、モノリシックレガシーアプリケーションの複数の機能または機能の組に対応する、ことをさらに含む。方法は、複数のマイクロサービスにおける各マイクロサービスまたはマイクロサービスの組のためのコンテナイメージを形成することであって、複数のコンテナイメージを作成するために、マイクロサービスイメージリポジトリからの対応するマイクロサービスイメージまたは複数のイメージを使用することと、レガシーエミュレータの要素のためのイメージファイルを相補的コンポーネントリポジトリから使用することとを行い、レガシーエミュレータの要素は、実行されるときにマイクロサービスまたはマイクロサービスの組によって採用される機能または機能の組に対応し、採用される機能または機能の組は、マイクロサービスまたはマイクロサービスの組におけるバイナリ内の呼び出しのシグネチャによって識別される、ことをさらに含む。方法は、コンテナイメージリポジトリにコンテナイメージを記憶することをさらに含む。方法は、コンテナ管理システムを使用して異なるコンピューティング環境内に少なくとも１つのコンテナを作成し、異なるコンピューティング環境において実行可能な形態においてコンテナの中に少なくとも１つのコンテナイメージを記憶することをさらに含む。

方法は、コンテナにおけるマイクロサービスまたはマイクロサービスの組を実行することをさらに含む。

明確に互いに排他的ではない限り、その全てが上記方法と互いに、および上記方法と任意の組み合わせで組み合わせられ得る、さらなる実施形態によると、本発明は、
ｉ）アクティビティログアナライザを使用して、複数のトランザクション定義ベクトルの少なくとも一部に対応する複数の動的トランザクション定義ベクトルを作成することと、マイクロサービス定義オプティマイザを使用して、各動的トランザクション定義ベクトルを各対応するトランザクション定義ベクトルと比較し、複数のマイクロサービス定義ベクトルを作成することと、
ｉｉ）アクティビティログアナライザが、レガシーコンピューティング環境においてモノリシックレガシーアプリケーションを実行することによって生成されるモノリシックレガシーアプリケーションのレガシーアクティビティログを使用することと、
ｉｉｉ）アクティビティログアナライザが、エミュレータを使用し、モノリシックレガシーアプリケーションを実行し、ログファイルを生成し、トランザクションの実行中にモノリシックレガシーアプリケーションによって使用されるプログラムを決定することと、
ｉｖ）ソースコードアナライザが、アクティビティログアナライザからの情報を使用し、トランザクション定義ベクトルを識別することと、
ｖ）ソースコードアナライザを使用して、複数の変換テーブルを作成することと、
ｖｉ）マイクロサービス定義オプティマイザを使用して、マイクロサービス定義ベクトルをさらに最適化することと、
ｖｉｉ）マイクロサービス定義オプティマイザを使用して、複数のトランザクションにおける２つ以上のトランザクションによって共有されるプログラムを含む追加のマイクロサービス定義ベクトルを作成することによって、マイクロサービス定義ベクトルをさらに最適化することと、
ｖｉｉｉ）レガシーコンピューティング環境において実行するようにコンパイルされたバイナリを含むコンパイル済みソースコードをバイナリリポジトリに記憶することと、
ｉｘ）バイナリリポジトリ内のソースコードをソースコードリポジトリ内のソースコードからバイナリファイルにコンパイルすることと、
ｘ）レガシーコンピューティング環境が、多重仮想記憶（ＭＶＳ）またはｚ／ＯＳコンピュータシステムを含むことと、
ｘｉ）相補的コンポーネントリポジトリが、レガシーエミュレータによって使用されるオペレーティングシステムソフトウェアパッケージの複数のイメージを記憶することと、コンテナビルダも、レガシーエミュレータの特定の要素によって使用される任意のソフトウェアパッケージのイメージをレガシーエミュレータの特定の要素を含む特定のコンテナイメージに設置することと、
ｘｉｉ）コンテナビルダが、マイクロサービスまたはマイクロサービスの組におけるバイナリ内の呼び出しのシグネチャをレガシーエミュレータにおいて動作可能な呼び出しのための命令と置換することと、
ｘｉｉｉ）コンテナ管理システムを使用して、複数のコンテナを作成することと、
ｉｘ）相補的イメージの組を共通ポッド内の別個のコンテナの中でインスタンス化することと、
ｘ）少なくとも１つのコンテナイメージの２つ以上のコピーを２つ以上の別個のコンテナの中でアクティブにすることと、
ｘｉ）コンテナ管理システムが、複数のコンテナにおけるコンテナの数を変動させることと、
ｘｉｉ）コンテナ管理システムが、様々なリソースを別個のコンテナに分配することと、
ｘｉｉｉ）コンテナ管理システムが、アクティビティログアナライザからの情報を使用し、２つ以上の別個のコンテナの中に設置すべき少なくとも１つのコンテナイメージのコピーの数を決定すること、複数のコンテナにおけるコンテナの数を決定すること、および／または、別個のコンテナに分配すべきリソースを決定することを行うことと、
ｘｉｖ）コンテナ管理システムが、スケーラブルコンテナベースのシステムの使用からの情報を使用し、２つ以上の別個のコンテナの中に設置すべき少なくとも１つのコンテナイメージのコピーの数を決定すること、複数のコンテナにおけるコンテナの数を決定すること、および／または、別個のコンテナに分配すべきリソースを決定することを行うことと、
ｘｖ）ソースコードアナライザが、モノリシックレガシーアプリケーションのデータベースから１つ以上のサブデータベースまたはサブデータベースのクラスタを作成することと、
ｘｖｉ）コンテナビルダが、１つ以上のサブデータベースまたはサブデータベースのクラスタを１つ以上のコンテナの中に設置することと、
ｘｖｉｉ）ソースコードが変更されると、ソースコード変更に基づいて更新されたバイナリを含むために、少なくとも１つのマイクロサービスイメージ、少なくとも１つのコンテナイメージ、および少なくとも１つのコンテナを自動的に更新することと
も含む方法を提供する。

本発明の種々の実施形態ならびにその特徴および利点のより完全な理解のために、ここで、付随の図面と併せて検討される、以下の説明が参照される。

図１Ａは、従来技術のハイパーバイザベースの仮想マシン環境の概略図である。 図１Ｂは、修正され、本発明と併せて使用され得るコンテナベースの仮想化環境の概略図である。 図２Ａは、アプリケーションのトランザクションに対応するプログラムベクトルの組の概略図である。 図２Ｂは、アプリケーションのトランザクションに対応する最適化されたプログラムベクトルの組の概略図である。 図３は、モノリシックレガシーアプリケーションのマイクロサービスへの区分化のためのスケーラブルコンテナベースのシステムのコンポーネントの描写である。 図４は、モノリシックレガシーアプリケーションにおける２つのトランザクションに関する呼び出しツリーのコンポーネントの描写である。 図５は、スケーラブルコンテナベースの環境内でマイクロサービスとして実装される図４の同一の２つのトランザクションに関する呼び出しツリーの描写である。 図６は、スケーラブルコンテナベースの環境内でマイクロサービスを展開するために、モノリシックレガシーアプリケーションを解析する方法のステップを描写する、フローチャートである。

本発明の一側面によると、モノリシックレガシーアプリケーションをマイクロサービスの組に自動的に区分し、そのようなマイクロサービスをレガシーエミュレータの適切な要素とともにコンテナにおいて展開可能なスケーラブルコンテナベースのシステムが、提案される。

異なるアーキテクチャを有するプロセッサは、異なるバイナリ表現を有する異なる命令セットをサポートし、その結果、ある命令セット（多くの場合、「バイナリ」または「バイナリイメージ」と称される）のマシン命令を含む実行可能プログラムは、概して、異なるアーキテクチャおよび異なる対応する命令セットを有する異なるプロセッサ上で実行しないであろう。故に、レガシープロセッサを含むレガシーメインフレームコンピューティング環境等のレガシーコンピューティング環境における特定のマシン命令セットを使用して、特定のアーキテクチャを伴うレガシープロセッサ上で実行されるように設計されるモノリシックレガシーアプリケーションは、異なるコンピューティング環境における異なるタイプのプロセッサ上で容易に実行可能ではない。特に、本明細書に説明されるスケーラブルコンテナベースのシステムは、モノリシックレガシーアプリケーションが実行するように設計されたレガシーコンピューティング環境と異なるプロセッサ、異なる命令セット、および異なるコンピューティング環境を使用して動作する。したがって、モノリシックレガシーアプリケーションは、本明細書に説明されるそれら等のモノリシックレガシーアプリケーションおよび／または異なるコンピューティング環境の修正なしに、スケーラブルコンテナベースのシステムの異なるコンピューティング環境において実行しないであろう。

典型的には、異なるプロセッサを含む異なるコンピューティング環境においてモノリシックレガシーアプリケーションを実行するために、モノリシックレガシーアプリケーションは、異なるアーキテクチャのために設計されたコンパイラを使用して再コンパイルされ、その命令は、異なるアーキテクチャ上で実行されるようにトランスコーディングされるか、または、レガシーアーキテクチャトランスレータ（以降では、レガシーアプリケーションエミュレータ）上で実行され、レガシーアーキテクチャトランスレータは、モノリシックレガシーアプリケーションは、レガシーコンピューティング環境のためにコンパイルされるような実行可能プログラムを異なるアーキテクチャを有する異なるコンピューティング環境における実行することが可能である。これは、レガシーソースコードを異なるコンピューティング環境にコンパイルし得る好適なコンパイラが存在するときのみ、または、好適なトランスコーダもしくはレガシーエミュレータが存在するときのみ可能である。

故に、本開示のスケーラブルコンテナベースのシステムは、少なくとも１つのレガシーエミュレータ要素を含む。しかしながら、スケーラブルコンテナベースのシステムは、モノリシックレガシーアプリケーションによって実施可能な全てのタスクを遂行するために、全てのコンテナ内の完全レガシーエミュレータのイメージを要求するのではなく、マイクロサービスがそれらの要素を使用するときのみコンテナ内にレガシーエミュレータの機能性コンポーネントのバイナリイメージ等のエミュレータ要素を設置することによって、レガシーエミュレータ使用を最適化する。別個のエミュレータ要素は、モノリシックレガシーアプリケーション機能の異なるサブセットをサポートする。

レガシーエミュレータは、典型的には、入力／出力機能性等のオペレーティングシステムによって提供される種々の機能性も使用する。全てのコンテナ内にオペレーティングシステム全体のイメージを設置するのではなく、スケーラブルコンテナベースのシステムはまた、それらのＯＳ要素を効果的に使用するマイクロサービスおよびエミュレータ要素をとともに、オペレーティングシステムの機能性コンポーネントのバイナリイメージ等のＯＳ要素をコンテナ内に設置することによっても、オペレーティングシステム使用を最適化する。別個のＯＳ要素は、レガシーエミュレータ機能および関連するモノリシックレガシーアプリケーション機能の異なるサブセットをサポートする。

スケーラブルコンテナベースのシステムは、記録の作成、注文、クエリの実施等のモノリシックレガシーアプリケーションを使用して実施され得る個々のトランザクションを識別し得る。スケーラブルコンテナベースのシステムは、次いで、各個々のトランザクション内に含まれるプログラムを識別する。最後に、スケーラブルコンテナベースのシステムは、モノリシックレガシーアプリケーションの外側で同一のトランザクションを実施するために使用されるか、または組み合わせられ得るマイクロサービスを作成する。いくつかの事例では、モノリシックレガシーアプリケーションからのトランザクションを構成する個々のプログラムは、異なるマイクロサービス内に位置し得る。他の事例では、マイクロサービスは、モノリシックレガシーアプリケーションからの２つ以上のプログラムを含み得る。加えて、マイクロサービスは、モノリシックレガシーアプリケーションからのトランザクションを効率的に遂行するための任意の様式でプログラムをグループ化し得るので、モノリシックレガシーアプリケーションからのいずれか１つのプログラムは、スケーラブルコンテナベースのシステムの１つのみのマイクロサービス内に位置し得るか、または、それは、スケーラブルコンテナベースのシステムの複数の異なるマイクロサービス内に位置し得る。

単一のコンテナイメージにおけるマイクロサービスは、スケーラブルコンテナベースのシステムを通して、典型的には、別個のコンテナにおける複数の並列インスタンスにおいて展開され得る。コンテナは、２つ以上のマイクロサービスのみならず、マイクロサービスが実行および機能することを可能にするために必要とされるような他の情報も含み得る。マイクロサービスは、好ましくは、最小限に相互依存性であるように、および／またはプログラムが更新されるとき、変更を要求するマイクロサービスの数を最小化するように構築され得る。マイクロサービスコンテナイメージは、アプリケーションバイナリに限定され、次いで、ポッドを形成するために汎用ユーティリティ（エラーロギング、アクティビティジャーナリング、セキュリティ等）コンテナに関連付けられ得る。

スケーラブルコンテナベースのシステムは、高度にフレキシブルであり、他の因子の中でもとりわけ、トランザクション、プログラム、他の情報、またはトランザクションもしくはマイクロサービスの使用の変更に基づいて、マイクロサービス自体の変更のみならず、コンテナのタイプおよび数、特定のコンテナ内にグループ化されるマイクロサービス、および、コンテナ内に含まれるサポートプログラム（エミュレータ要素およびＯＳ要素、および特定のコンテナまたはポッドに当てられるリソース等）の変更も可能にする。

加えて、モノリシックレガシーアプリケーションまたはその一部から作成されるマイクロサービスの合計数は、モノリシックレガシーアプリケーションまたはその一部における個々のトランザクションの合計数より大きいこともある。

図３は、スケーラブルコンテナベースのシステム（３００）を図示する。スケーラブルコンテナベースのシステムは、モノリシックレガシーアプリケーションのソースコードを記憶するソースコードリポジトリ（３０５）を含み得る。モノリシックレガシーアプリケーションのソースコードは、例えば、数百の異なるトランザクションＴ_１，Ｔ_２，・・・・Ｔ_ｘを個々に、またはグループで実施するように設計された数十、数百、またはさらには数万もの個々のプログラムを含み得るモノリシックＣＯＢＯＬアプリケーションであり得る。そのようなトランザクションの例は、例えば、Ｄａｔａｂａｓｅ ２（「ＤＢ２」）リレーショナルデータベーストランザクションまたはデータ言語インターフェース（「ＤＬ／Ｉ」）階層化データベーストランザクションを実施するために、顧客情報管理システム（「ＣＩＣＳ」）または情報管理システム（「ＩＭＳ」）を使用し得る顧客記録の作成、更新、移動、または削除を含み得る。コンパイラ（３１０）が、ソースコードをバイナリリポジトリ（３１５）内に記憶される１つ以上のバイナリの組にコンパイルする。

ある実施形態によると、ソースコードアナライザ（３２０）が、典型的には、依存性アナライザコンポーネントを介して、ソースコードリポジトリ（３０５）内に記憶されるようなモノリシックレガシーアプリケーションにおけるソースコードおよび関連付けられるファイルを解析し、ソースコード内の相互依存性（呼び出し元＜＞呼び出し先）を識別するコードツリーを生成する。好ましくは、ソースコードアナライザ（３２０）は、ＣＩＣＳ、ＩＭＳ等のトランザクションシステムの構成パラメータにおいて定義されるように、モノリシックレガシーアプリケーションの各トランザクションを反復する。一例では、ソースコードアナライザ（３２０）は、ソースコードリポジトリ（３０５）からの入力として、モノリシックレガシーアプリケーションとのそれらの相互作用においてユーザによって起動され得る利用可能なＣＩＣＳトランザクション定義を識別するファイルを受信する。好ましくは、このファイルは、各トランザクションおよびそのルートまたはトランザクションを実施するときに起動される最初のプログラムを識別する。これは、トランザクションの多くにおいて使用されるようなＥＸＥＣ ＣＩＣＳ ＬＩＮＫの呼び出し先としてのルートプログラムを含み得る。この例では、ルートプログラムは、インターフェースを取り扱う（例えば、インターフェースが３２７０であるとき、ＳＥＮＤ／ＲＥＣＥＩＶＥ ＭＡＰを行うが、インターフェースが異なるとき、他の同等のＡＰＩを行う）プログラムによって呼び出される最初のプログラムを指す。トランザクションを識別する、またはそれらのサービスに寄与する他のファイルもしくはフォーマットも、使用され得、例えば、追加のビルドファイルは、メッセージ待ち行列およびデータソース等のトランザクションによって使用されるリソースのための定義ファイルを含み得る。

加えて、ソースコードアナライザ（３２０）は、モノリシックレガシーアプリケーションに関連付けられるプログラムファイルの全てを解析し、モノリシックレガシーアプリケーションのトランザクションの全てに対するプログラムファイル間の相互依存関係（プログラムの呼び出し元＜＞呼び出し元またはコピーブックのようなリソースの包含）を検出し得る。ソースコードアナライザ（３２０）内の依存性アナライザが、トランザクションによって使用されるプログラム間の呼び出し元−呼び出し先または包含関係を識別する。静的アナライザは、ベクトルもしくはベクトルの組またはグラフの形態における呼び出しまたは包含ツリーを生成し得、それは、特定のトランザクションのためのソースコードが起動または含み得るプログラムもしくはモジュールを識別する。

モノリシックレガシーアプリケーションの区分化が、例えば、ＳＯＡＰまたはＲＥＳＴ（ＪＳＯＮまたは他のデータフォーマットを伴う）を介してアクセス可能な最小限に相互依存性のトランザクションの組にアプリケーションを分割するために所望される。最小限に相互依存性のトランザクションの各々は、レガシーエミュレータ（３２５）の独立したインスタンスにおいて実行されることが可能であり得る。ソースコードアナライザ（３２０）の出力は、プログラム呼び出しまたは包含ツリーもしくはグラフであり得、それは、各トランザクションのために、各トランザクションを実施するために起動または使用され得るプログラムの完全セット、およびプログラム間の呼び出し元−呼び出し先または包含関係を識別する。図４は、第１のトランザクションＴ１がルートプログラムＡから開始され、それが、次いで、プログラムＦまたはプログラムＤを呼び出し得るそのような呼び出しツリーの例である。さらに、トランザクションＴ１において、プログラムＤは、次いで、プログラムＥを呼び出し得る。第２のトランザクションＴ２は、ルートプログラムＢから開始され、それは、次いで、プログラムＣを呼び出すか、または、ルートプログラムＢも、同じプログラムＤを呼び出し得、それは、次いで、プログラムＥを呼び出す。

呼び出しツリーは、ベクトルの組（各トランザクションのために１つのベクトル）、または、モノリシックレガシーアプリケーションの可能なトランザクションの定義されたサブセットに変換され、トランザクションを実行するときに起動され得るプログラムを識別し得る。図２Ａは、トランザクション定義ベクトルＴａ（２１０）、Ｔｂ（２２０）、・・・Ｔｃ（２３０）の組（２００）の例を描写する。この例では、Ｔａ（２１０）等の第１のベクトルは、第１のトランザクションを実行するときに潜在的に呼び出されるプログラムの組＜Ｐ１，Ｐ２，・・・Ｐｘ＞を含む。図４の例を使用して、トランザクションは、Ｔ１であり得、プログラムの組は、プログラムＡ、Ｆ、Ｄ、およびＥを含むであろう。第２のトランザクションおよび第３のトランザクションに対応する、プログラム＜Ｐ２，Ｐ３，・・・Ｐｙ＞を含む第２の例証的ベクトルＴｂ（２２０）およびプログラム＜Ｐ１，Ｐ６，・・・・Ｐｚ＞を含む第３の例証的ベクトルＴｃ（２３０）も、示される。プログラムの異なる数および組み合わせが、モノリシックレガシーアプリケーションの異なるトランザクションを指定し得る。

ソースコードアナライザ（３２０）は、ルートプログラムのインターフェース定義に基づいて、データタイプ、メッセージ、メッセージフォーマット／紐付け、ならびにメッセージ入力および出力の組を抽出または生成せることと、各トランザクションのアドレスおよびエンドポイントを定義することと、メッセージが、例えば、マイクロサービスイメージの一部として、コンテナビルダ（３３０）および／またはコンテナ管理システム（３３５）に提供されるとき、トランザクションへのインターフェースを構築および定義することにおいて使用するためのメッセージ構造にこの情報を変換することとも行い得る。加えて、ソースコードアナライザ（３２０）は、ＳＯＡＰプロトコルが使用される場合、ＷＳＤＬメッセージインターフェースも生成し得る。ＷＳＤＬメッセージインターフェースは、定義されたデータタイプ、メッセージ、ポートタイプ、紐付け、ポート、およびサービス定義情報を記憶するための構造を含むＷ３Ｃ規格において定義されるフォーマット化ドキュメントであり得る。ソースコードアナライザ（３２０）は、他のプロトコル（ＲＥＳＴ等）および表現（ＪＳＯＮ）が所与の状況のために好ましい場合、インターフェースメッセージの他の表現を生成することもできる。ソースコードアナライザは、双方向性データエンコーディング変換テーブルまたはプロシージャを生成し、ＵＴＦ文字を８ビットＥＢＣＤＩＣ文字に（逆もまた同様である）（またはＡＳＣＩＩを含む異なる文字セット間で）変換するようにもさらに構成され得、この変換は、トランザクションに基づいて、要求側に向かうそれらのインターフェースにおいて、マイクロサービスとともに使用されるべきスクリプト／プログラムを生成することによって実装され得る。

トランザクション定義ベクトルの組（２００）、通信インターフェース定義（ＷＳＤＬ、ＲＥＳＴ）、およびスクリプトを通した変換指示文は、トランザクション状態定義リポジトリ（３４０）内に記憶され得る。

ソースコードアナライザ（３２０）は、スケーラブルコンテナベースのシステムの中へのトランスコードされたプログラムの使用のためのトランスコーダ経路を提示するために、トランスコーディングアプリケーションの一部も含み得る。このように、ソースコードアナライザはまた、Ｃｏｂｏｌ等のその元々の言語からＪａｖａ（登録商標）等の異なる言語へのソースコードの移行をサポートするためにも使用され得る。他のソースコード変換も、実施され得る。さらに、ソースコードアナライザ（３２０）は、トランスコーディングアプリケーションの一部ではないスタンドアロンプログラムの形態においても使用され得る。

トランザクション状態定義リポジトリ（３４０）内の各トランザクション定義ベクトル（２１０）、（２２０）、（２３０）は、モノリシックレガシーアプリケーションを使用して一連の実際のトランザクションを実施することにおいて実際に起動されるプログラムのスーパーセットを含む。しばしば、トランザクションアプリケーションは、決して起動されない多くのプログラムを含む。これは、トランザクションアプリケーションの初期設計、設計変更、ユースケース変更、トランザクションアプリケーションの異なる部分におけるプログラムおよびその呼び出し先の共有、またはトランザクションアプリケーションの他の発展に起因して生じ得る。コード内のこれらの使用されないプログラムの包含は、永久記憶装置上で動き回るために要求されるオーバーヘッド、起動されない中央コンピュータメモリプログラムへのロードおよびアンロード、ならびにトランザクションコンテナへのネットワーク更新を経由するコンパイル、ビルド、または移送のときの追加の遅延を含むいくつかの理由からコンテナ化アプリケーションの低減させられた効率をもたらす。マイクロサービスアプリケーションイメージからこれらの使用されないプログラムを排除するために、マイクロサービス定義オプティマイザ（３４５）は、トランザクション状態定義リポジトリ（３４０）からトランザクション定義ベクトル、インターフェース定義、および変換テーブルを抽出し、動的定義リポジトリ（３５０）内に記憶される動的定義ベクトルを適用し、図２Ｂに示されるように、マイクロサービスのさらなる精緻化および定義を保留するマイクロサービス定義オプティマイザ（３４５）によって中間状態において記憶されるか、またはマイクロサービスイメージリポジトリ（３５５）内に記憶されるマイクロサービスイメージを作成するようにマイクロサービスイメージビルダ（３５０）によって処理され得る、対応するマイクロサービス定義ベクトル（２６０）、（２７０）、（２８０）に到達するようにトランザクション状態定義リポジトリ（３４０）のトランザクション定義ベクトル（２１０）、（２２０）、（２３０）内に含まれる使用されないプログラムを排除する。大規模モノリシックシステムレガシーアプリケーションでは、典型的には、この方式で排除され得る使用されないプログラムが存在するであろう。しかしながら、静的トランザクション状態分析によって識別されるプログラムの全てを使用するトランザクションに対して、マイクロサービス定義ベクトルは、初期トランザクション定義ベクトルと同一であろう。これは、図２Ａのトランザクション定義ベクトル（２２０）および図２Ｂの対応するマイクロサービス定義ベクトル（２７０）によって図示される。

動的定義ベクトルは、典型的には、異なるシステム上で実行されるか、またはレガシーアクティビティログを使用する動的定義プロセスによってトランザクション状態定義ベクトルとは別個に開発される。動的定義ベクトルは、以前から存在していることもあるか、または、それは、トランザクション定義ベクトルと並行して開発され得る。

動的定義プロセスでは、モノリシックレガシーアプリケーションは、実行され、各トランザクションは、実際に呼び出されるプログラムとそうではないプログラムとを決定するために分析される。システムが十分な期間（例えば、アプリケーションの性質に応じて、週、月、四半期、年）にわたって実行されるとき、または全ての実際のユースケースを起動するデータの組を使用しているとき、動的定義ベクトルは、トランザクションを実施するときに実際に呼び出されるプログラムをより精密に識別するであろう。

代替として、動的定義ベクトルは、静的トランザクション状態定義ベクトルから開始することによっても生成され得、静的トランザクション状態定義ベクトルは、プログラムを過剰に含み得、次いで、実際に起動されるそれらのプログラムのみを選択する。したがって、動的定義ベクトルは、プログラムが識別されるときに構築され得るか、または、それは、トランザクション状態定義ベクトルから必要とされないプログラムを排除することによって作成され得る。

いくつかのシステムでは、そのレガシーコンピューティング環境において実行されるモノリシックレガシーアプリケーションの既存のレガシーアクティビティログ（３６０）が、実世界トランザクションの実行によって実際に起動されるプログラムを識別し、それによって、各トランザクションのために使用されるプログラムを示すプログラムベクトルを生成するために、アクティビティログアナライザ（３６５）によって使用される。

あるシステムでは、モノリシックレガシーアプリケーションは、レガシーエミュレータ（３２５）上で実行され、エミュレータによって生成されるアクティビティログデータが、各トランザクションのために使用されるプログラムを示すプログラムベクトルを生成するためにアクティビティログアナライザ（３６５）によって分析される。いくつかの実施形態では、レガシーエミュレータ（３２５）は、トランザクション毎のユースケースの全ての実際の変形に遭遇したという信頼を達成するために十分な期間にわたって各トランザクションを実行する。代替として、各実際のユースケースを実行するように設計された試験トランザクションの定義された組が、実行され、アクティビティログアナライザ（３６５）が、モノリシックレガシーアプリケーションにおけるトランザクションによって実際に使用されるプログラムを同様に決定することを可能にし得る。

いくつかのシステムでは、アクティビティログアナライザ（３６５）は、モノリシックレガシーアプリケーションにおけるトランザクションによって実際に使用されるプログラムを決定するために、レガシーアクティビティログ（３６０）およびレガシーエミュレータ（３２５）の両方からの情報を使用し得る。例えば、レガシーアクティビティログ（３６０）が、所与のトランザクションにおいて使用されているプログラムのいかなる例も含まない場合、レガシーエミュレータ（３２５）からのログが、プログラムがそのトランザクションによって使用されていないと結論を下すことに先立って参照され得、逆も同様である。別の例では、十分なレガシーデータが存在するトランザクションは、レガシーエミュレータ（３２５）によるさらなるエミュレーションを伴わずに、レガシーアクティビティログ（３６０）のみを使用して評価され得る。さらに別の例では、レガシーログデータは、マイクロサービスの定義への最初の手がかりとして使用され得る。

アクティビティログアナライザの出力は、動的定義リポジトリ（３７０）内に記憶され、動的定義リポジトリ（３７０）は、各トランザクションのために、実際に使用されるプログラムに対応するベクトルを記憶する。

ロードモジュールは、典型的には、メインフレームレガシーコンピューティング環境の文脈において実行可能なプログラムの全てまたは一部を指す。レガシーエミュレータ（３２５）は、Ｌｉｎｕｘ（登録商標）オペレーティングシステムを伴うｘ８６プラットフォーム等の異なるコンピューティング環境において実行するためのｚ／ＯＳまたは他のレガシーコンピューティング環境からのコンパイル済みレガシーアプリケーションまたはロードモジュールの実行を可能にするように開発されたエミュレータであり得る。レガシーエミュレータは、元々の実行可能プログラムの各ネイティブ命令またネイティブオペレーティングシステムサービス呼び出しを異なるコンピューティング環境の同等の命令およびシステム呼び出しに変換し得る。レガシーエミュレータ（３２５）は、個々のレガシー命令またはシステムサービス呼び出しのエミュレーションを可能にするために、ネイティブＡＰＩの組を実装し得る。レガシーエミュレータ（３２５）は、エミュレータ全体の単一のイメージであり得る、またはこれは、本明細書にさらに議論されるような区分化イメージを含み得る。レガシーエミュレータ（３２５）は、レガシーエミュレータによって実際に使用されるオペレーティングシステムまたはそのコンポーネントへの動作可能なアクセスをさらに含むか、または有し得る。

マイクロサービス定義オプティマイザ（３４５）は、マイクロサービスイメージを作成するためにマイクロサービスイメージビルダ（３５０）によって使用され得るマイクロサービス定義ベクトルに到達するために、動的定義リポジトリ（３７０）内に記憶される動的トランザクションベクトルをトランザクション状態定義リポジトリ（３４０）内に記憶されるトランザクション定義ベクトルに適用する。これらのイメージは、次いで、マイクロサービスイメージリポジトリ（３５５）内に記憶される。

図２Ｂは、マイクロサービス定義ベクトルＭＳａ（２６０）、ＭＳｂ（２７０）、・・・ＭＳｃ（２８０）の組（２５０）の例を描写する。この例では、第１のマイクロサービス定義ベクトルＭｓａ（２６０）は、第１のトランザクションＴａを実行するときに呼び出されるプログラムの組＜Ｐ１ｂ，・・・Ｐｘ−ｑｂ＞から作製される最適化されたベクトルを含む。この例では、プログラムＰ２は、トランザクションＴａにおいて実際に使用されず、したがって、マイクロサービス定義ベクトルから排除される。第２の例証的マイクロサービス定義ベクトルＭＳｂ（２７０）は、プログラム＜Ｐ２，Ｐ３，・・・Ｐｙ＞を含む。この例では、トランザクション定義ベクトルを構成する全てのプログラムが、使用され、したがって、それらは、マイクロサービス定義ベクトル内に保存される。第３の例証的マイクロサービス定義ベクトルＭＳｃ（２８０）は、プログラム＜Ｐ１，Ｐ６，・・・・Ｐｚ−ｙ＞を含む。結果として生じるアーキテクチャは、各々が最小数のプログラムによって定義されるＴｘトランザクションの組を含む。モノリシックレガシーアプリケーションのＴｘトランザクションのうちのいずれかが、以前のモノリシックレガシーアプリケーションの変換された動作および定義されたマイクロサービスＭＳｘを起動し得る拡張または修正されたアプリケーションの両方において、独立して呼び出し可能なマイクロサービスＭＳｘとして定義されることができる。

Ｔｘトランザクションのうちの任意のものも、独立して呼び出し可能なマイクロサービスの組として定義されることができる。モノリシックレガシーアプリケーションからのＴｘトランザクションの合計組に対して、いくつかのサブセットが１回のトランザクションあたり１つのマイクロサービスによって定義され得る一方、別のサブセットは、１回のトランザクションあたりマイクロサービスの組によって定義され得る。例えば、図５に図示されるように、トランザクションＴ１およびＴ２が共通のプログラムＤおよびＥを使用する場合、これらのトランザクションがマイクロサービス定義オプティマイザ（３４５）によってマイクロサービスに変換されると、それらの共通プログラムは、独立したマイクロサービスＭＳ３としてグループ化され得、ＭＳ３は、Ｔ１の他のプログラムを含むＭＳ１によって呼び出され得るか、またはＴ２の他のプログラムを含むＭＳ２によって呼び出され得る。

マイクロサービス定義オプティマイザ（３４５）は、マイクロサービスイメージベクトルまたは中間マイクロサービスイメージベクトルを記憶し得、マイクロサービス定義オプティマイザ（３４５）は、次いで、それらをさらに変更または最適化する。例えば、マイクロサービス定義オプティマイザ（３４５）は、図４のトランザクションのためのトランザクション定義ベクトルを提示されると、最初に、中間マイクロサービス定義ベクトルＭＳ１およびＭＳ２を作成し得、その両方は、トランザクション定義ベクトル内に同様に位置するプログラムを含む。マイクロサービス定義オプティマイザ（３４５）は、図４の要素ＤおよびＥによって示されるように、これらのマイクロサービス定義ベクトルＭＳ１およびＭＳ２の共通コンポーネントを認識し、最初の２つのマイクロサービス定義ベクトルから共通コンポーネントを抽出し得る。図５に描写されるように、第１および第２のマイクロサービスＭＳ１およびＭＳ２に加えて、共通要素ＤおよびＥは、これらの共通コンポーネントを含み、ＭＳ１またはＭＳ２によって呼び出され得る第３のマイクロサービス定義ベクトルＭＳ３を作成するために使用される。これらの最適化されたマイクロサービス定義ベクトルＭＳ１、ＭＳ２、およびＭＳ３は、次いで、マイクロサービスイメージビルダ（３５０）に提供される。

代替として、中間マイクロサービス定義ベクトルは、中間リポジトリ（図示せず）内等のマイクロサービス定義オプティマイザ（（３４５）内以外の場所に記憶され得る。ある実施形態では、中間マイクロサービス定義ベクトルは、マイクロサービスイメージビルダ（３５０）内に、またはマイクロサービスイメージリポジトリ（３５５）内に中間イメージとして記憶され、次いで、その後、最適化されたマイクロサービス定義ベクトルまたはマイクロサービスイメージによってアクセスされ、および／またはそれと置換され得る。

コンパイラ（３１０）が、ソースコードリポジトリ（３０５）内のソースコードをコンパイルし、バイナリリポジトリ（３１５）内にバイナリを生産する。コンパイラ（３１０）は、システム３９０またはｚ／ＯＳメインフレーム等のレガシーコンピューティング環境のためのバイナリを生成する。このように、本明細書に説明されるスケーラブルコンテナベースのシステム内にマイクロサービスイメージを構築するために使用されるバイナリは、レガシーコンピューティング環境において実行されるバイナリと同一であり、レガシーコンピューティング環境からスケーラブルコンテナベースのシステムへのモノリシックレガシーアプリケーションの相互運用性および漸進的な移行を促進し得る。

マイクロサービスイメージビルダ（３５０）は、適宜、マイクロサービス定義ベクトルまたは最適化されたマイクロサービス定義ベクトル内で識別されるプログラムに対応するバイナリリポジトリ（３１５）からのコンパイル済みバイナリを読み出し、バイナリを組み合わせ、マイクロサービス定義ベクトルにおける各プログラムのためにバイナリイメージを含む各マイクロサービスのためのイメージを生成する。マイクロサービスイメージは、マイクロサービスイメージビルダ（３５０）によって読み出される、共有リソース定義等の関連付けられるアーチファクトおよび情報も含み得る。これらのマイクロサービスイメージは、マイクロサービスイメージリポジトリ（３５５）内に記憶される。

コンテナビルダ（３７５）は、マイクロサービスイメージリポジトリ（３５５）内に記憶される特定のマイクロサービスに関連付けられるバイナリイメージを相補的コンポーネントリポジトリ（３８０）内に記憶されるバイナリイメージと組み合わせることによって、コンテナイメージを構築する。相補的コンポーネントリポジトリ（３８０）は、典型的には、スケーラブルコンテナベースのシステムによって別様に使用されるレガシーエミュレータ（３２５）と同一である、レガシーエミュレータを一緒に作り上げるエミュレータ要素のイメージファイルの組を記憶し得る。

レガシーエミュレータは、レガシー要素を形成するために、機能または機能のサブセットに従って区分され得、それは、本明細書に説明されるコンテナベースのシステム内のレガシーエミュレータの展開のための利点を提供する。例えば、レガシーエミュレータによってサポートされるインターフェース上の命令のサブセットのためのサポートは、分離され得る。加えて、バッチ動作、ＣＩＣＳトランザクションサービス、ＤＢ２、または他のリレーショナルデータベースサービス、ＩＭＳサービス、セキュリティ、ロギング、もしくは他の能力のためのレガシーエミュレータのサポートは、区分され得る。このように、コンテナ内のマイクロサービスによって使用される個々のレガシー要素またはレガシーエミュレータの要素の組のみが、所与のコンテナの内側で実行し得る。加えて、ポッド内のコンテナによって使用されるあるレガシー要素は、別個のコンテナ内に記憶され、次いで、ポッド内の他のコンテナ内のマイクロサービスによってアクセスされ得る。好適なレガシー要素は、エミュレータの実行時間環境の追跡およびロギング機能を含む。そのような設定は、性能および／またはセキュリティを改良し得る。

相補的コンポーネントリポジトリ（３８０）は、レガシーエミュレータが使用し得るオペレーティングシステムからのソフトウェアパッケージも記憶し得、それらは、ＯＳ要素と称され得る。例えば、個々のシステムＡＰＩコンポーネントも、別個のイメージとして個々に記憶され得る。いくつかの例では、個々のパッケージおよびライブラリファイルは、Ｌｉｎｕｘ（登録商標）または別のオペレーティングシステムによって提供される機能性を増加させるために実行時間において組み合わせられることができ、バイナリは、相補的コンポーネントリポジトリ（３８０）内に記憶され得る。

コンテナビルダ（３７５）は、マイクロサービスまたはマイクロサービスの組に関連付けられる機能性を提供するためのエミュレータ要素および／またはＯＳ要素をそのマイクロサービスまたはマイクロサービスの組を含むコンテナイメージの中に選択的に組み込むことができる。このように、各コンテナに対する全体的イメージサイズは、完全レガシーエミュレータイメージまたは完全ＯＳイメージが各コンテナ内に含まれる場合より小さくあり得る。

レガシーエミュレータのイメージは、いくつかの事例では、数百メガバイトであり得る。一方、特定のバッチプロセスまたは特定のデータベーストランザクション等の特定の機能を実施するエミュレータ要素は、わずか数十メガバイトであり得る。同様に、完全オペレーティングシステムのイメージは、エミュレータ要素によって使用される実際のコンポーネントのイメージよりも数倍大きくあり得る。

故に、エミュレータ要素へのレガシーエミュレータの区分化と、コンテナまたはポッド内のコンテナにおける全より少ないそのような要素の包含は、完全レガシーエミュレータまたはコンテナもしくはポッド内のマイクロサービスによって使用されないエミュレータ要素のイメージを含むそうでなければ同じコンテナまたはポッドと比較して、コンテナまたはポッドを格納するために使用されるメモリを５〜７倍低減させ得る。

コンテナまたはポッド内のコンテナにおける全より少ないＯＳ要素の包含は、完全ＯＳのイメージ、または、コンテナまたはポッド内のマイクロサービスおよび／またはエミュレータ要素によって使用されないＯＳ要素のイメージを含むそうでなければ同じコンテナもしくはポッドと比較して、コンテナまたはポッドを格納するために使用されるメモリを５〜７倍同様に低減させ得る。

コンテナ内またはポッド内のコンテナ内の全てより少ないエミュレータ要素および全てより少ないＯＳ要素の両方を含むことによって、コンテナまたはポッドを格納するために使用されるメモリも、全レガシーエミュレータまたはコンテナもしくはポッド内のマイクロサービスによって使用されないエミュレータ要素のイメージを含み、かつ、完全ＯＳのイメージ、または、コンテナまたはポッド内のマイクロサービスおよび／またはエミュレータ要素によって使用されないＯＳ要素のイメージを含むそうでなければ同じコンテナもしくはポッドと比較して、５〜７倍低減させられ得る。この事例では、２つの組み合わせを格納するために使用されるメモリの低減に対するレガシーエミュレータサイズおよびオペレーティングシステムサイズの低減の相対的寄与は、レガシーエミュレータおよびオペレーティングシステムの相対的全体的サイズと両方の区分化の程度とに依存し得る。例えば、約１０個の要素に区分される２００ＭＢレガシーエミュレータと約５０個の要素に区分される５０ＭＢオペレーティングシステムとの場合、エミュレータ要素を除去する寄与は、典型的には、オペレーティングシステム要素を除去する寄与を上回るであろう。

レガシーエミュレータは、マイクロサービスのあり得る必要性と対応するエミュレータ要素に区分され得る。例えば、管理コンソールおよびユーザインターフェース機能性等のある機能性は、マイクロサービスによって必要とされない可能性が高いか、または、それらは、このアーキテクチャ（３８５）により好適な形態においてコンテナ管理システムによってネイティブに提供されることができ、したがって、他のエミュレータ要素から分離され得、相補的コンポーネントリポジトリ（３８０）から省略されることさえあり得る。セキュリティ要素等の他のエミュレータ要素も、特に区分され得、したがって、それらは、他のエミュレータ要素およびマイクロサービスから別個のコンテナ内に設置されることができ、または、新しいシステムによって提供される類似するサービスと置換されることさえできる。

レガシーエミュレータは、レガシーエミュレータの他のコンポーネントによって依拠されるコア機能性をコアエミュレータ要素の中に設置するためにも区分され得る。そのような要素は、全てではないが、殆どのコンテナまたはポッド内に含まれ得る。多くの場合、このコアエミュレータ要素は、合計レガシーエミュレータサイズの他のエミュレータ要素より大きい割合であろう。例えば、コアエミュレータ要素は、合計レガシーエミュレータのサイズの３０％〜４０％であり得る。

レガシーエミュレータは、セキュリティ機能性等、全てのコンテナではないが、ポッド内の１つまたはいくつかのコンテナ内で概して使用される可能性が高い機能性をセキュリティエミュレータ要素等の別個の要素内に設置するためにさらに区分され得る。

例としてトランザクションエミュレータを使用すると、好適なエミュレータ要素は、オンライン／通信エミュレータ要素（トランザクションサービスのためのＣＩＣＳおよびＩＭＳ−ＴＭのためのサブプロダクトを含むもの等）、リレーショナルエミュレータ要素（ＤＢ２に関するもの等）、階層化データベースエミュレータ要素（ＩＭＳ−ＤＢのためのもの等）、データセット／日付管理エミュレータ要素（ＶＳＡＭファイルおよびシーケンシャルファイルのためのもの等）、バッチサービスエミュレータ要素、および／または言語エミュレータ要素（ＣｏｂｏｌおよびＰＬ／１のためのサブプロダクトを伴うもの等）、セキュリティエミュレータ要素、ならびにユーザインターフェース／管理コンソールエミュレータ要素も含み得る。

サブプロダクトは、コンテナの中に実際に組み込まれるエミュレータ要素イメージから除外可能であり得る。例えば、オンライン／通信エミュレータ要素は、ＣＩＣＳのためのバイナリイメージのみを含み、ＩＭＳ−ＴＭのためのものを含まないこともある。

エミュレータ要素は、合計レガシーエミュレータと比較してサイズが変動し得るが、典型的には、非コアエミュレータ要素の各々は、合計レガシーエミュレータサイズの１％〜２０％、より具体的には、３％〜１５％であり得る。合計レガシーエミュレータと比較したエミュレータ要素のサイズは、一緒の使用の可能性等の他の因子とともに、異なるエミュレータ要素に分離される機能性を決定することにおいて使用され得る。

ＯＳ要素は、ＰｏｓｔｇｒｅｓＳＱＬ、ＬＬＶＭ、ｎｏｄｅ．ｊｓ等のような種々のＬｉｎｕｘ（登録商標）パッケージ等の利用可能なパッケージの形態であり得る。

エミュレータ要素に付随するＯＳ要素のサイズも、異なるエミュレータ要素に分離されるレガシーエミュレータ機能性を決定することにおいて使用され得る。

いくつかのスケーラブルコンテナベースのシステムでは、コンテナビルダ（３７５）は、ロードモジュールコンパイラを含み、ロードモジュールコンパイラは、入力として、マイクロサービスイメージリポジトリ（３５５）内に記憶されるＳｙｓｔｅｍ ３９０またはｚ／ＯＳ実行可能イメージファイル等のバイナリを受信する。ロードモジュールコンパイラは、一式のアセンブラ命令等、モノリシックレガシーアプリケーションによるレガシーコンピューティング環境のプログラム、サービス、または機能への呼び出しのバイナリにおける全てのシグネチャを検出する。ロードモジュールコンパイラは、この情報を使用し、マイクロサービスまたはマイクロサービスの組によって使用されるレガシーエミュレータ機能を決定し得る。コンテナビルダ（３７５）は、次いで、相補的コンポーネントリポジトリ（３８０）内のエミュレータ要素の中でこれらの機能を実施することが可能なエミュレータ要素を見つけ、マイクロサービスイメージまたはマイクロサービスイメージの組を伴う相補的コンポーネントリポジトリ（３８０）からの任意の関連付けられるＯＳ要素とともに、コンテナイメージの中にエミュレータ要素を設置し得る。代替として、コンテナビルダ（３７５）は、両方のコンテナイメージがポッド内に設置されるであろうように、マイクロサービスイメージまたはイメージの組のコンテナイメージに関連付けられるコンテナイメージ内にエミュレータ要素およびＯＳ要素のイメージを設置するであろう。

加えて、ロードモジュールコンパイラは、代わりに、バイナリ内のシグネチャまたは複数のシグネチャをレガシーエミュレータ内のレガシーコンピューティング環境において呼び出される同一の機能または複数の機能を呼び出すための命令と置換し、それによって、コンテナイメージ内に記憶され得るレガシーエミュレータ最適化マイクロサービスイメージを形成し得る。モノリシックレガシーアプリケーションまたはレガシーコンピューティング環境およびスケーラブルコンテナベースのシステムのレガシーエミュレータまたは異なるコンピューティング環境のために作成される既存のデータベースを使用して、シグネチャが、識別され、置換命令が、見つけられ得る。加えて、コンテナビルダ（３７５）は、識別されたレガシー機能呼び出しをレガシーエミュレータのネイティブＡＰＩへの呼び出しと置換し、修正されたイメージまたは複数のイメージを構築し得る。

本明細書に説明されるようなマイクロサービスイメージまたはコンテナイメージの任意の最適化もしくは修正中、またはその後、コンテナビルダ（３７５）は、次いで、コンテナイメージリポジトリ（３９０）内にそれを記憶する。その後、コンテナイメージリポジトリ（３９０）内のコンテナイメージは、コンテナ管理システム（３８５）によって管理されるコンテナ（３９５）内で実行される。

ある実施形態によると、コンテナイメージリポジトリ（３９０）は、構造において公共Ｄｏｃｋｅｒ Ｈｕｂと類似するＤｏｃｋｅｒリポジトリであり得る。コンテナ管理システム（３８５）は、次いで、好ましくは、Ｄｏｃｋｅｒコンテナをサポートし、それらの最適化された実行を可能にする。

コンテナ管理システム（３８５）は、コンテナのインスタンス化をスケジューリングする機能、コンテナを実行する機能、それらに制御された量のコンピューティング／記憶／ネットワーク化リソースを分配する機能、それらをアップグレードする機能を組み合わせ得、および／または、システムの健全性を追跡し、管理するために追加のロギングおよび管理機能を実施し得る。ある実施形態によると、コンテナ管理システム（３８５）は、ＤｏｃｋｅｒコンテナのためのＫｕｂｅｒｎｅｔｅｓコンテナ管理システムであり得る。しかし、Ａｍａｚｏｎ ＡＣＳ、Ａｚｕｒｅ Ｃｏｎｔａｉｎｅｒ Ｓｅｒｖｉｃｅ、Ｃｌｏｕｄ Ｆｏｕｎｄｒｙ Ｄｉｅｇｏ、ＣｏｒｅＯＳ Ｆｌｅｅｔ、Ｄｏｃｋｅｒ Ｓｗａｒｍ、Ｇｏｏｇｌｅ Ｃｏｎｔａｉｎｅｒ Ｅｎｇｉｎｅ、もしくはＭｅｓｏｓｐｈｅｒｅ Ｍａｒａｔｈｏｎコンテナ管理システム、または他のコンテナ編成システム等の他のコンテナ管理システムも、使用され得る。コンテナ管理システム（３８５）は、本明細書に説明されるような修正および追加を伴って、図１Ｂに説明されるものと類似し得る。コンテナ管理システム（３８５）によるリソースの選択的分配は、コンテナがＤｏｃｋｅｒに基づくとき、ｃｇｒｏｕｐの使用によって行われ得る。

コンテナ管理システム（３８５）のフロントの知的プロキシ（図示せず）は、エンドユーザのターミナルエミュレータまたは恒久的接続を要求する任意の他のクライアントインターフェースとの恒久的ＴＣＰ接続を維持することができる。このプロキシは、次いで、恒久的接続上で要求をスキャンし、それらを適切なサービス要求に変換し、それは、次いで、Ｋｕｂｅｒｎｅｔｅｓによって適切なマイクロサービスに向かってルーティングされる。知的プロキシ内およびマイクロサービス内のアドホックラッパは、マイクロサービス要求および応答への３２７０トラフィックまたは任意の他の特定のトラフィックのカプセル化を可能にする。

コンテナ（３９５）およびコンテナ管理システム（３８５）は、サブシステム（４００）内に常駐し得る。サブシステム（４００）は、残りのスケーラブルコンテナベースのシステム（３００）とは物理的に別個であり得、スケーラブルコンテナベースのシステム（３００）を使用するときに利用可能な同じ利益を達成することが可能であるスタンドアロンシステムにおいて動作し得る。例えば、サブシステム（４００）は、本明細書に説明されるようなリソース分配およびコンテナ管理機能を実施し得る。特に、サブシステム（４００）がコンテナイメージリポジトリ（３９０）も含む場合、コンテナ管理システム（３８５）は、コンテナイメージを使用して追加のまたは複製コンテナも作成し得る。サブシステム（４００）は、依然として、マイクロサービスへのモノリシックレガシーアプリケーションの区分化から、およびコンテナイメージ内の必要とされるエミュレータ要素およびＯＳ要素のみの包含から利益を享受し得る。しかしながら、サブシステム（４００）は、マイクロサービス定義ベクトルおよびコンテナイメージを作成することに当てられるスケーラブルコンテナベースのシステム（３００）の要素を欠くので、そのコンテナイメージおよびコンテナを自動的に更新することは、可能ではない。代わりに、それは、コンテナ管理システム（３８５）がコンテナ（３９５）に適用する、または存在する場合、コンテナイメージリポジトリ（３９０）内に記憶される更新されたコンテナイメージを受信し得る。

図示されないが、別のサブシステムは、コンテナ（３９５）と、コンテナ管理システム（３８５）と、コンテナイメージリポジトリ（３９０）と、コンテナビルダ（３７５）と、相補的コンポーネントリポジトリ（３８０）とを含み得る。そのようなサブシステムは、残りのスケーラブルコンテナベースのシステム（３００）とは物理的に別個であり得、システム（３００）と関連して説明される利益の多くを達成し得る。そのようなサブシステムは、新しいマイクロサービスイメージを提供されると、コンテナイメージを更新する能力を有する。そのようなサブシステムは、マイクロサービスイメージリポジトリ（３５５）および／またはレガシーアプリケーションエミュレータ（３２５）をさらに含むが、最初に、またはモノリシックソースコードが更新されるとき、新しいマイクロサービス定義ベクトルおよび／またはマイクロサービスイメージを開発することに関与するコンポーネントを欠き得る。そのようなサブシステムは、レガシーアプリケーションエミュレータ（３２５）も含み得る。

リレーショナルデータベースに基づく多くのレガシーアプリケーションが、その記事「Ａ Ｒｅｌａｔｉｏｎａｌ Ｍｏｄｅｌ ｏｆ Ｄａｔａ ｆｏｒ Ｌａｒｇｅ Ｓｈａｒｅｄ Ｄａｔａ Ｂａｎｋｓ」（ＣＡＣＭ １３，Ｎｏ．６，Ｊｕｎｅ １９７０）において最初に公開されたＴｅｄｄ Ｃｏｄｄのリレーショナル理論に従って構築される。それらのレガシーデータベースは、最小限の冗長性を念頭に設計されており、それらの構造は、通常、可能な限り正規化されている。第５正規形（５ＮＦ）が、実生活がこの理想的形態を長年にわたって改変したとしても、殆どの人のための初期設計目標であった。高度な正規化の結果は、モノリシックレガシーアプリケーションによって使用されるデータの種々の区分にわたる高い相互依存性である。

この錯綜したデータアーキテクチャは、直接的（同一のテーブルにアクセスするｓｑｌ要求）または間接的（プログラムＹによって更新されたテーブル上の参照一貫性の制約によって修正されたプログラムＸによってアクセスするテーブル）のいずれかで同一のデータを共有するモノリシックレガシーアプリケーションにおけるプログラムのクラスタにわたる間接的相互依存性を生じる。

しかし、殆どの場合、典型的な大規模モノリシックレガシーアプリケーションは、依然として、数千のテーブルから成るその大規模データベース内に独立したデータのクラスタを有する。スケーラブルコンテナベースのシステムでは、これらのクラスタは、種々のシステム能力を改良するために、各々がマイクロサービスの独立した組によって使用される独立したサブデータベースに分離されるべきである。これらのサブデータベースは、次いで、例えば、別個のデータベースサーバ内で分離されることができ、互いに独立して管理されることができる。これは、ローカルデータ構造変更が包括的なものよりも動作的観点から実行することが単純であるので、システム全体のフレキシビリティおよび敏捷性を増加させる。サブデータベースへのデータベースのこの分離は、１つのサブデータベースまたはその保守に関する問題が、他のデータベースおよびそれらを使用するマイクロサービスに影響を及ぼさないので、スケーラブルコンテナベースのシステムの包括的利用可能性も増加させる。

プログラム依存性の識別と同様に、データは、対応するトランザクションまたはトランザクションの組におけるそれらの使用を通してデータクラスタを識別する依存性ツリーを作成することによって、マイクロサービスアーキテクチャに従って区分され得る。この識別は、ソースコードアナライザ（３２０）、特に、その依存性アナライザによって行われ得る。何故なら、依存性アナライザが、上で説明される利益のうちの少なくともいくつかを達成するために互いに分離可能である、典型的には、ベクトルまたはテーブルの形態におけるサブデータベースおよびサブデータベースクラスタを生産するためにモノリシックレガシーアプリケーションを解析するからである。

種々のマイクロサービスイメージは、同一のサブデータベースへの類似するアクセスを共有し得る。特に、リレーショナルデータベースサービストランザクションは、例えば、処理サービスおよびデータベースサービスが、最終的に、別個のマイクロサービスにおいて定義されるように、レガシーエミュレータの他の機能性のためのトランザクションとは別個にパッケージ化され得る。

完全データベースまたはサブデータベースは、いくつかのマイクロサービスにわたって共有され得る。完全データベースまたはサブデータベースは、短命処理コンテナによって遠隔でアクセスされる、別個の長期持続データベースコンテナ内に位置し得る。典型的には、処理マイクロサービスを伴うコンテナは、処理マイクロサービスによって使用されるリレーショナルデータベースサービスおよびサブデータベースを格納する１つ以上のコンテナを伴うポッド内にあり得る。

類似するタイプの構造では、モノリシックレガシーアプリケーションにおけるトランザクションにわたって共有されるオブジェクトのためのサポートは、ソースコードアナライザを使用して共有オブジェクトを検出し、次いで、ソースコードアナライザによって通知されるようにコンテナビルダを使用して専門リソースコンテナ内にサポートオブジェクトを収集することによって実装され得る。例えば、いくつかのマイクロサービス内に存在するプログラム間で共有されるＣＩＣＳ ＴＳ待ち行列は、それらをホストする長命リソースコンテナ内に常駐し得る。これらの共有オブジェクト（例えば、メモリセッション、メッセージ待ち行列、共有データオブジェクト）は、レガシーコンピューティング環境の遠隔アクセス機能を複製する目的のために最初に開発されるレガシーエミュレータの遠隔アクセス機能を通して、遠隔であるが、透過的にアクセスされ得る。ＣＩＣＳレガシー環境の場合、それらの機能は、ＭＲＯ、ＩＰＩＣ等のようなレガシー機能のエミュレートされたバージョンである。共有メモリゾーン（ｚ／ＯＳシステムの場合ではＣＳＡ、ＣＩＣＳ ＣＷＡ、ＣＩＣＳ ＴＣＴＵＡ等）が、検出され、分散共有キャッシュに設置され、種々のマイクロサービスにわたって共有されるとき、特定のリソースコンテナ上の同じ遠隔アクセス機能によって遠隔でアクセスされることができる。

別の類似するタイプの構造では、データ分離を最大化するために、Ｋｕｂｅｒｎｅｔｅｓへの初期サービス要求後に、カスケードにおいて同期的に互いを呼び出すいくつかのマイクロサービスにわたっておよぶトランザクションが、構築され得る。この実施形態は、分散２フェーズコミットの関連する問題を伴うデータベース接続共有と分散トランザクションとの追加の複雑性を導入する。

本明細書に説明されるコンテナベースのシステムは、生産環境にフレキシブルに結合される適応統合ビルドプロセスを提供することによって、ビルドの観点から変化した景観を提示する。ソースコードリポジトリ（３０５）内に記憶されるソースコードの修正が行われ、コンパイラ（３１０）によってコンパイルされ、バイナリリポジトリ（３１５）内に記憶されると、ソースコードアナライザ（３２０）、トランザクション状態定義リポジトリ（３４０）、マイクロサービス定義オプティマイザ（３４５）、およびマイクロサービスイメージビルダ（３５０）は、変更によって影響を受けるそれらのトランザクションにのみ対応するマイクロサービスまたは複数のマイクロサービスに関する更新されたマイクロサービスイメージまたはマイクロサービスイメージの組を構築するために使用されることができる。コンテナビルダ（３７５）は、次いで、コンテナビルダによって以前に抽出されたマイクロサービス定義ベクトルに基づいて自動的かつ最適に定義および設定される構築プロシージャをトリガし、更新されたマイクロサービスのためのコンテナイメージをトリガすることができ、それは、次いで、コンテナ管理システム（３８５）によって展開されることができる。コンテナイメージは、単純に、マイクロサービスまたはマイクロサービスの組のための更新されたイメージを含み得るが、それらは、必要に応じて、相補的コンポーネントリポジトリ（３８０）からのイメージの変更も含み得る。ソースコードのより極端な、または複数の変更の場合、マイクロサービス定義ベクトルは、異なるマイクロサービスまたはマイクロサービスの組が作成されるように、変更され得る。例えば、ソースコードが、プログラムの共通セットを使用する多数のトランザクションを提供するために変更される場合、そのプログラムの共通セットは、図５のＭＳ３と同様に、別個のマイクロサービス内に新しく設置され得、他のマイクロサービスのための既存および新しいマイクロサービス定義ベクトルが、それに応じて修正または作成される。

更新プロセス全体が、好ましくは、自動化されるが、更新されたマイクロサービスの展開も、運営管理コンソール（図示せず）の制御下で設置され得る。同様に、データ（例えば、コピーブック、ｓｑｌファイル等）等の他の情報の変更が存在する場合、変更の依存性が、識別され、ビルドプロシージャを自動的に適応させるように伝搬され得る。

例証するために、更新プロセスの自動的ステップは、以下を含み得る：（１）ソースコードリポジトリ（３１０）の中に設置されるソースコード構造、（２）Ｊｅｎｋｉｎｓ（または他のＤｅｖＯｐｓビルドシステム）ビルドジョブ定義、（３）メインフレームバイナリの適切なクラスタリングを通したＤｏｃｋｅｒイメージ構築、および（４）Ｋｕｂｅｒｎｅｔｅｓ管理パラメータ。

スケーラブルコンテナベースのシステムのマイクロサービス構造は、更新するために必要とされる変更の数およびそのように行うことにおいて費やされる時間の観点からも利点を提供する。例えば、図５に図示されるように、プログラムＤまたはＥの変更は、トランザクションＴ１およびＴ２のために、２つの別個のマイクロサービスビルドＭＳ１およびＭＳ２においてではなく、マイクロサービスＭＳ３のビルドにおいてのみ行われる必要がある。多数の独立したマイクロサービスによって提示される高レベルの粒度は、完全自動化を可能にし、好ましくは、その下で動作する。

そのようなマイクロサービスの形成は、サブツリーを変更するアプリケーションコードのアップグレードまたは変更が、それを起動する全てのマイクロサービスではなく、内部マイクロサービスのための対応するコンテナのアップグレードのみを引き起こす必要があるので、全体的システム管理性を改良することができる。

コンテナが構築され得る容易さと、それがより小さい場合にコンテナの中にコンテナイメージをロードするための短縮された時間とを所与として、多くのスケーラブルコンテナベースのシステムにおけるマイクロサービス定義オプティマイザ（３４５）は、特に、図４および図５に図示されるように、トランザクションが別個のマイクロサービス内に設置されることに適している共通プログラムまたはプログラムの組を使用する場合、トランザクション定義ベクトルあたり複数のマイクロサービス定義ベクトルを作成するための命令を実装し得る。例えば、Ｔ個のトランザクションは、Ｐ個のマイクロサービスに容易になることができ、Ｐは、プログラムの数であり、Ｔは、エントリポイントの必要性が、もはや各既存のトランザクションのルートプログラムではなく、アプリケーション内の任意の（例えば、ＣＩＣＳ下でＬＩＮＫを介して）呼び出し可能なプログラムである場合、モノリシックレガシーアプリケーションによってサポートされるトランザクションのためのエントリポイントの数であった。

所与のスケーラブルコンテナベースのシステムがポッドを使用して実装されるであろうか、コンテナのみを使用して実装されるであろうかは、マイクロサービスが作成および定義される方法をさらに通知し得る。例えば、マイクロサービスへのトランザクションのさらなる解析およびより最小限のマイクロサービス定義ベクトルが、そのように設計されていないものよりもポッドを使用するように設計されたスケーラブルコンテナベースのシステムにおいて可能であり得る。

いくつかの事例では、定義される別個のマイクロサービスの数に関する唯一の限定は、モノリシックレガシーアプリケーション内の別個のプログラムの数および／またはマイクロサービスイメージリポジトリ（３５５）および／またはコンテナ（３９５）を格納するためのスケーラブルコンテナベースのシステムにおいて利用可能なメモリであり得る。

加えて、所与のコンテナイメージが、任意の数のアクティブコンテナ内に設置され得るので、スケーラブルコンテナベースのシステムは、更新のチェックおよび漸進的実装を可能にし、いくつかのコンテナは、古いバージョンのマイクロサービスまたはマイクロサービスの組を実行し、より新しいコンテナは、更新されたマイクロサービスまたはマイクロサービスの組を実行する。これは、更新が失敗に対してチェックおよび試験されることを可能にする一方、必要に応じて、古いバージョンのマイクロサービスまたはマイクロサービスの組を使用してトランザクションを実施する能力を維持する。古いバージョンのマイクロサービスを実行するコンテナは、更新が十分に検証されると、自動的に破棄される（またはユーザ命令に基づいて除去される）ことができる。

加えて、コンテナが容易に構築および破棄されることができるので、トランザクションがいくつかのコンテナ内で実行されている場合、更新を伴う新しいコンテナは、そのトランザクションのための新しい要求を実施するように構築されることができる一方、そのトランザクションは、更新を欠く既存のコンテナ内で終了し、それは、次いで、それらが直ちに実行しているトランザクションを完了すると、自動的に破棄されることができる。したがって、例えば、１０個のコンテナＣ１−Ｃ１０がトランザクションＴ１を実行している場合、ＭＳ１に対応する更新が起こると、コンテナ管理システム（３８５）は、トランザクションのための新しい要求が受信されると、新しいコンテナＣ１１を自動的に作成し得る。コンテナＣ１１は、更新されたマイクロサービスＭＳ１’のイメージを含む。コンテナＣ１が、それが実行しているトランザクションを完了すると、いかなる新しいトランザクションも、コンテナＣ１に割り当てられず、それは、破棄される。コンテナを作成および管理するためにコンテナ管理システム（３８５）によって適用されるパラメータに応じて、更新されたマイクロサービスＭＳ１’を伴う新しいコンテナが、Ｃ１に取って代わるように直ちにビルドされ得るか、または、それは、トランザクションＴ１に関する新しい要求が到着するときにビルドされ得る。

ＤｏｃｋｅｒおよびＫｕｂｅｒｎｅｔｅｓのような技術は、ウェブスケールにおいて機能し、その結果、より多くの要求が到着するとき、より多くの追加されたｘ８６マシン上で拡散され得るワークロードの非常に迅速な発展を可能にするように設計されている。それは、まさに、Ｋｕｂｅｒｎｅｔｅｓのようなオーケストレータを目的としている。オンライン顧客トランザクションが、トランザクションを完了する前にますます多くの数のクエリに回答することをますます要求しているので、オンラインコマースの要求は、オンライン市場へのレガシーコンピューティング環境の拡張にスケーラビリティの問題を導入している。本明細書に説明されるようなコンテナベースのシステムのスケーラビリティは、これらの顧客集約的クエリアプリケーション専用のコンテナの拡散を可能にすることによって、そのようなレガシーコンピューティング環境のスケーラビリティを増加させることにおいて特に有利である。さらに、各コンテナイメージ、またはいくつかの事例では、各ポッドが、いくつかのＯＳ要素およびいくつかのエミュレータ要素を含むので、それは、Ｌｉｎｕｘ（登録商標）オペレーティングシステムの使用等の異なるコンピューティング環境が保存される限り、ハードウェアの一部から別のものに容易に複製または移動させられることができる。

分離されたコンテナによって提供される分離は、サービスレベル管理においてはるかに洗練されたアプローチも提供する。各コンテナは、その他よりも良好にいくつかのマイクロサービス（特定のレガシートランザクションに対応するか、またはそれによって使用される）を提供するために、異なる量のリソースを分配されることができる。本明細書に説明されるようなスケーラブルコンテナベースのシステムは、コンテナによるリソース使用を自動的に検出および追跡し、使用に基づいてより多いまたはより少ないリソースを当てることができる。加えて、または代替として、コンテナ管理システムは、使用に基づいて、特定のマイクロサービスまたはマイクロサービスの組に当てられるコンテナの数をスケール変更し得る。ユーザ定義優先順位も、トランザクションまたはマイクロサービスに対応するリソース分配もしくはコンテナの数に関する計算において含まれ得る。所与のトランザクションに利用可能なリソースのこのユーザ定義調節は、モノリシックレガシーアプリケーションにおいて可能ではない。

いくつかの変形例では、マイクロサービスまたはマイクロサービスの組を含むコンテナイメージのコンテナもしくはポッドの中への初期展開は、少なくとも部分的に、モノリシックレガシーアプリケーションがレガシーコンピューティング環境において実行されるときのトランザクションアクティビティ、またはそのエミュレーションに基づき得る。そのような情報は、図３に図示されるようなレガシーエミュレータ（３２５）等のレガシーエミュレータから導出され得る。そのような情報は、レガシーアクティビティログ（３６０）等のレガシーアクティビティログまたはアクティビティログアナライザ（３６５）（図３に図示せず）等のアクティビティログアナライザからも導出され得る。

例えば、モノリシックレガシーアプリケーションを使用するときの所与のトランザクションのためのリソース消費量が、多くの場合、精密に監視される。リソース番号が、抽出され得、スケーラブルコンテナベースのシステム、特に、コンテナ管理システム（３８５）の展開定義パラメータのための基礎として、スケーラブルコンテナベースのシステムの異なるコンピューティング環境における類似するリソース番号への転置後、使用されることができる。

さらに、別々のコンテナ内のセキュリティおよび個々のＡＰＩまたはトランザクションサービスサポート特徴を実行することによって、スケーラブルコンテナベースのシステムは、必要に応じて、保護されたデータおよびリソースへのアクセスを限定することによって、セキュリティを増進する。加えて、初期レガシーアプリケーションのセキュリティ特徴は、利用可能なマイクロサービスの組の中に移植され、マイクロサービス定義オプティマイザ（３４５）によって特に識別され、マイクロサービスとともに含まれ得る。

図１Ｂに描写される一般的タイプのもの等のスケーラブルコンテナベースのシステム内のコンテナは、ハイパーバイザを伴わずに動作し、スケーラブルコンテナベースのシステムが、ハイパーバイザまたは複数のＯＳコピー等の追加のコンポーネントも動作しなければならない図１Ａに描写されるタイプ等の仮想マシン等のシステムよりも効率的に動作することを可能にし得る。

上記説明によるシステムは、サーバまたはサーバクラスタもしくはサーバクラスタの組内のコンピュータ記憶媒体等の非一過性媒体に記憶されたコンピュータ命令において実装され得る。コンピュータ命令は、そのようなシステム上でのインストールのために、不揮発性固定または取り外し可能な記憶媒体上に記憶され得る。一実施形態では、ソースコードリポジトリ（３１０）、トランザクション状態定義リポジトリ（３４０）、および動的定義リポジトリ（４４０）は、共通リポジトリシステム内に記憶される一方、バイナリリポジトリ（３３０）、トランザクションイメージリポジトリ（３６０）、相補的コンポーネントリポジトリ（４５０）、およびコンテナイメージリポジトリ（３７０）は、共通バイナリイメージリポジトリシステム上に記憶される。別の実施形態では、コンテナイメージリポジトリ（３７０）は、別個のプラットフォーム内でインスタンス化される。システムのスケールおよび必要性に応じて、異なる数のリポジトリシステムが、使用され得、ソースおよびバイナリリポジトリは、共有される、または異なるリポジトリシステムに分離され得る。

命令および／またはデータは、別様に典型的な様式で記憶され得る。例えば、バイナリイメージは、標準ファイルシステムの通常の階層化構造内のディスク上に記憶されることができる。アプリケーションデータは、通常のファイル内および／または構造化（リレーショナル、階層化等）データベース内のいずれかに記憶されることができる。

本発明の別の側面によると、モノリシックレガシーアプリケーションの動作を実施するスケーラブルコンテナベースのシステムを生産および／または保守する方法が、提供される。図６は、そのような方法のあるステップのフローチャートである。しかしながら、スケーラブルコンテナベースのシステムと関連して上で説明される任意の機能も、方法に含まれ得る。加えて、方法は、任意の特定のシステムとの使用に限定されないが、それは、上で説明されるスケーラブルコンテナベースのシステム上に実装され得る。

方法６００は、モノリシックレガシーアプリケーションが解析され、プログラムファイルが自動的に区分されるステップ６０５を含む。ステップ６１０において、トランザクションルートプログラムが、識別される。ステップ６１０の前または後に起こり得るステップ６１５において、プログラム相互依存性が、識別される。ステップ６１０および６１５は、複数のトランザクションにおける異なるトランザクションのために同時に起こり得る。

次に、ステップ６２０において、複数のトランザクション呼び出しツリーが、識別される。好ましくは、この複数のトランザクション呼び出しツリーは、モノリシックレガシーアプリケーションにおいて可能な全てのトランザクションまたはモノリシックレガシーアプリケーションの定義されたサブパーツにおいて可能な全てのトランザクションを表す。

ステップ６２５において、複数のトランザクション呼び出しツリーは、例えば、トランザクション状態定義リポジトリ内に記憶される複数のトランザクション定義ベクトルを作成するために使用される。

ステップ６５０において、アクティビティログアナライザが、モノリシックレガシーアプリケーションにおいて可能な全てのトランザクションまたはモノリシックレガシーアプリケーションの定義されたサブパーツにおいて可能な全てのトランザクションにおいて実際に使用されるプログラムを決定する。モノリシックレガシーアプリケーションの定義されたサブパーツのみが使用される場合、それは、典型的には、ステップ６２５のサブパーツと同一であるか、その全体を含むか、または少なくとも部分的にそれと重複するであろう。アクティビティログアナライザは、トランザクションにおいて実際に使用されるプログラムを決定するために、その元々の環境において実行されるようなモノリシックレガシーアプリケーションのレガシーアクティビティログを使用し得る。アクティビティログアナライザは、代替として、トランザクションにおいて実際に使用されるプログラムを決定するために、モノリシックレガシーアプリケーションを実行するためのエミュレータを使用し得る。いくつかの方法では、同一または異なるアクティビティログアナライザが、トランザクションにおいて実際に使用されるプログラムを決定するために、レガシーアクティビティログおよびエミュレータの両方を使用し得る。結果に基づいて、動的定義リポジトリが、作成される。動的定義リポジトリは、複数のトランザクションにおける各トランザクションのために使用されるプログラムのログを含む。いくつかの実施形態では、このログは、複数の動的定義ベクトルを含み得る。動的定義リポジトリは、トランザクション状態定義リポジトリに関して定義され得るか、または、それは、独立して作成され得る。

ステップ６３０において、ステップ６２５からの複数のトランザクション定義ベクトルは、マイクロサービス定義オプティマイザによってステップ６５０からの動的定義リポジトリと比較され、トランザクションにおいて実際に使用されないプログラムが、各トランザクション定義ベクトルから除去され、複数のトランザクションに対応する複数のマイクロサービス定義ベクトルを作成する。

ステップ６３５において、マイクロサービス定義オプティマイザは、さらなる最適化が起こるであろうかどうかを決定する。さらなる最適化が起こるであろう場合、ステップ６４０において、複数のマイクロサービス定義ベクトルのうちの少なくとも１つが、さらに最適化され、次いで、ステップ６４５において、それは、マイクロサービスイメージビルダに提供される。さらなる最適化が複数のマイクロサービス定義ベクトルのうちのいずれかに関して起こらないであろう場合、ステップ６４５において、マイクロサービス定義ベクトルは、マイクロサービスイメージビルダに提供される。最適化がマイクロサービス定義ベクトルのうちのいずれかに関して起こるかどうかにかかわらず、複数のトランザクションベクトルから導出される複数のマイクロサービス定義ベクトルは、ステップ６４５において、マイクロサービスイメージビルダに提供される。

ステップ６５５において、マイクロサービスイメージビルダは、複数のマイクロサービス定義ベクトルの各マイクロサービス定義ベクトルを取得し、バイナリリポジトリからレガシーコンピューティング環境において実行するようにコンパイルされた対応するコンパイル済みソースコードを見つけ、マイクロサービスイメージリポジトリ内にマイクロサービスイメージを形成する。マイクロサービスイメージは、それが含むプログラムによって使用されるさらなる情報およびアーチファクトも含み得る。ステップ６５５が完了された後、マイクロサービスイメージリポジトリは、好ましくは、モノリシックレガシーアプリケーションまたはその定義されたサブパーツにおいて可能な複数のトランザクションの各々に対応する複数のマイクロサービスイメージを含む。

ステップ６６０において、相補的コンポーネントリポジトリが、レガシーエミュレータの要素の別個のイメージから作成される。別個の要素は、レガシーエミュレータの異なる機能に対応する。レガシーエミュレータに関連付けられるＯＳ要素のイメージも、相補的コンポーネントリポジトリ内に記憶され得る。

ステップ６６５において、コンテナビルダが、マイクロサービスまたは複数のマイクロサービスを実行するために使用されるレガシーエミュレータのエミュレータ要素の相補的コンポーネントリポジトリからのイメージとともに、マイクロサービスイメージリポジトリからのイメージを使用して、各マイクロサービスまたはマイクロサービスの組のためのコンテナイメージを形成する。レガシーエミュレータの要素に関連付けられるＯＳ要素のイメージ等の相補的コンポーネントリポジトリからの他のイメージも、コンテナイメージに設置され得る。エミュレータ要素は、マイクロサービスイメージのバイナリ内の機能またはプログラムへの呼び出しのシグネチャを識別し、呼び出された機能を実施すること、または呼び出されたプログラムとともに動作することが可能なエミュレータ要素を含むことによって選択され得る。ある実施形態では、各コンテナイメージ内の少なくとも１つのマイクロサービスイメージ内の少なくとも１つのバイナリは、レガシーエミュレータ最適化マイクロサービスイメージを形成するために改変され得、マイクロサービスバイナリイメージ内の呼び出しのシグネチャは、レガシーエミュレータ内の同一の機能または複数の機能を呼び出すための命令と置換される。

ステップ６７０において、複数のコンテナイメージは、コンテナイメージリポジトリに記憶される。

ステップ６７５において、コンテナイメージリポジトリ内の少なくとも１つのコンテナイメージが、コンテナ管理システムによってコンテナ内に記憶される。アクティビティログアナライザからの情報のみならず、マイクロサービスイメージ自体も、コンテナ管理システムによって使用され得る。好ましくは、各コンテナイメージは、少なくとも１つのコンテナ内でアクティブにされる。各コンテナイメージは、それが含まれるコンテナまたは複数のコンテナに分配されるリソースに反映されるリソース分配を割り当てられ得る。

ステップ６８０において、少なくとも１つのマイクロサービスが、コンテナ管理システム内のコンテナ内で実行される。

多くの例が、本明細書に提供される。これらの例は、本発明の精神から逸脱することなく修正され得る。例えば、種々の例および実施形態のうちのいずれかが、それらが明確に互いに排他的ではない限り、互いに組み合わせられ得る。本明細書に説明される例および実施形態は、例として提供され、他のコンポーネント、ルーチン、またはモジュールも、使用され得る。

Claims (46)

1. 非一過性媒体に記憶されたコンピュータ命令において実装されるスケーラブルコンテナベースのシステムであって、前記システムは、
   モノリシックレガシーアプリケーションのソースコードを含むソースコードリポジトリであって、前記ソースコードリポジトリは、複数のトランザクションを実施するためのレガシーコンピューティング環境において実行可能な複数のプログラムを含む、ソースコードリポジトリと、
   前記ソースコードを解析し、前記複数のトランザクションにおける各トランザクションのために、トランザクション定義ベクトルを識別し、複数のトランザクション定義ベクトルを作成するように動作可能であるソースコードアナライザであって、前記トランザクション定義ベクトルは、前記トランザクション中に潜在的に呼び出される各プログラムを識別する、ソースコードアナライザと、
   前記複数のトランザクション定義ベクトルを記憶するように動作可能であるトランザクション状態定義リポジトリと、
   動的定義リポジトリを作成するように動作可能であるアクティビティログアナライザであって、前記動的定義リポジトリは、前記複数のトランザクションの少なくとも一部において実施するときに前記モノリシックレガシーアプリケーションによって実際に使用されるプログラムを識別する、アクティビティログアナライザと、
   前記複数のトランザクション定義ベクトルを前記動的定義リポジトリと比較し、使用されないプログラムを前記トランザクション定義ベクトルから除去し、複数のマイクロサービスを定義する複数のマイクロサービス定義ベクトルを作成するように動作可能であるマイクロサービス定義オプティマイザと、
   前記複数のマイクロサービス定義ベクトルの各マイクロサービス定義ベクトルのために、前記マイクロサービス定義ベクトルによって識別された各プログラムのために、前記レガシーコンピューティング環境において実行するようにコンパイルされたコンパイル済みソースコードバイナリを見つけ、前記マイクロサービス定義ベクトルに対応する複数のマイクロサービスイメージを形成するように動作可能であるマイクロサービスイメージビルダと、
   前記複数のマイクロサービスイメージを記憶するように動作可能であるマイクロサービスイメージリポジトリと、
   レガシーエミュレータのエミュレータ要素のバイナリイメージの組を記憶するように動作可能である相補的コンポーネントリポジトリであって、前記バイナリイメージの組は、合わせて、完全なレガシーエミュレータより小さく、前記イメージは、前記レガシーコンピューティング環境の複数の機能または機能の組に対応し、前記イメージは、前記レガシー環境の命令セットと異なる命令セットによって特徴付けられる異なるコンピュータ環境において実行可能である、相補的コンポーネントリポジトリと、
   コンテナビルダであって、前記コンテナビルダは、前記複数のマイクロサービスにおける各マイクロサービスまたはマイクロサービスの組のためのコンテナイメージを形成するように動作可能であり、複数のコンテナイメージを作成するために、前記コンテナビルダは、前記マイクロサービスイメージリポジトリからの前記対応するマイクロサービスイメージまたは複数のイメージを使用することと、前記レガシーエミュレータのエミュレータ要素のためのイメージファイルを前記相補的コンポーネントリポジトリから使用することとを行い、前記レガシーエミュレータの前記エミュレータ要素は、実行されるときに前記マイクロサービスまたはマイクロサービスの組によって採用される機能または機能の組に対応し、前記採用される機能または機能は、前記マイクロサービスまたはマイクロサービスの組における前記バイナリ内の呼び出しのシグネチャによって識別される、コンテナビルダと、
   前記異なるコンピューティング環境において実行可能な前記複数のコンテナイメージを記憶するように動作可能であるコンテナイメージリポジトリと、
   コンテナ管理システムと
   を含み、
   前記コンテナ管理システムは、前記異なるコンピューティング環境における実行のための少なくとも１つのコンテナを作成し、前記少なくとも１つのコンテナにおけるコンテナイメージリポジトリに記憶された少なくとも１つのマイクロサービスを実行するように動作可能である、システム。
2. 前記アクティビティログアナライザは、前記複数のトランザクション定義ベクトルの少なくとも一部に対応する複数の動的トランザクション定義ベクトルを作成するように動作可能であり、前記マイクロサービス定義オプティマイザは、各動的トランザクション定義ベクトルを各対応するトランザクション定義ベクトルと比較し、前記複数のマイクロサービス定義ベクトルを作成する、請求項１に記載のスケーラブルコンテナベースのシステム。
3. 前記アクティビティログアナライザは、前記レガシーコンピューティング環境において前記モノリシックレガシーアプリケーションを実行することによって生成される前記モノリシックレガシーアプリケーションのレガシーアクティビティログを使用する、請求項１または請求項２に記載のスケーラブルコンテナベースのシステム。
4. 前記アクティビティログアナライザは、エミュレータを使用し、前記モノリシックレガシーアプリケーションを実行し、ログファイルを生成し、トランザクションの実行中に前記モノリシックレガシーアプリケーションによって使用されるプログラムを決定する、請求項１−３のいずれか１項に記載のスケーラブルコンテナベースのシステム。
5. 前記ソースコードアナライザは、前記アクティビティログアナライザからの情報を使用し、前記トランザクション定義ベクトルを識別するように動作可能である、請求項１−４のいずれか１項に記載のスケーラブルコンテナベースのシステム。
6. 前記ソースコードアナライザは、複数の変換テーブルを作成するようにさらに動作可能である、請求項１−５のいずれか１項に記載のスケーラブルコンテナベースのシステム。
7. 前記マイクロサービス定義オプティマイザは、前記マイクロサービス定義ベクトルをさらに最適化するように動作可能である、請求項１−６のいずれか１項に記載のスケーラブルコンテナベースのシステム。
8. 前記マイクロサービス定義オプティマイザは、前記複数のトランザクションにおける２つ以上のトランザクションによって共有されるプログラムを含む追加のマイクロサービス定義ベクトルを作成することによって、前記マイクロサービス定義ベクトルをさらに最適化するように動作可能である、請求項７に記載のスケーラブルコンテナベースのシステム。
9. 前記レガシーコンピューティング環境において実行するようにコンパイルされたバイナリを含む前記コンパイル済みソースコードを記憶するように動作可能なバイナリリポジトリをさらに含む、請求項１−８のいずれか１項に記載のスケーラブルコンテナベースのシステム。
10. 前記バイナリリポジトリ内の前記コンパイル済みソースコードは、前記ソースコードリポジトリ内の前記ソースコードからバイナリファイルにコンパイルされる、請求項９に記載のスケーラブルコンテナベースのシステム。
11. 前記レガシーコンピューティング環境は、多重仮想記憶（ＭＶＳ）またはｚ／ＯＳコンピュータシステムを含む、請求項１−１０のいずれか１項に記載のスケーラブルコンテナベースのシステム。
12. 前記相補的コンポーネントリポジトリは、前記レガシーエミュレータによって使用されるオペレーティングシステムソフトウェアパッケージの複数のイメージを記憶するようにさらに動作可能であり、前記コンテナビルダも、前記レガシーエミュレータの特定の要素によって使用される任意のソフトウェアパッケージのイメージを前記レガシーエミュレータの前記特定の要素を含む特定のコンテナイメージに設置する、請求項１−１１のいずれか１項に記載のスケーラブルコンテナベースのシステム。
13. 前記コンテナビルダは、前記マイクロサービスまたはマイクロサービスの組における前記バイナリ内の前記呼び出しのシグネチャを前記レガシーエミュレータにおいて動作可能な呼び出しのための命令と置換するようにさらに動作可能である、請求項１−１２のいずれか１項に記載のスケーラブルコンテナベースのシステム。
14. 前記コンテナ管理システムは、複数のコンテナを作成するように動作可能である、請求項１−１３のいずれか１項に記載のスケーラブルコンテナベースのシステム。
15. 相補的イメージの組が、共通ポッド内の別個のコンテナの中でインスタンス化される、請求項１４に記載のスケーラブルコンテナベースのシステム。
16. 少なくとも１つのコンテナイメージの２つ以上のコピーが、２つ以上の別個のコンテナの中でアクティブにされる、請求項１４および１５のいずれかに記載のスケーラブルコンテナベースのシステム。
17. 前記コンテナ管理システムは、前記複数のコンテナにおけるコンテナの数を変動させるように動作可能である、請求項１４−１６のいずれか１項に記載のスケーラブルコンテナベースのシステム。
18. 前記コンテナ管理システムは、様々なリソースを別個のコンテナに分配するように動作可能である、請求項１４−１７のいずれか１項に記載のスケーラブルコンテナベースのシステム。
19. 前記コンテナ管理システムは、前記アクティビティログアナライザからの情報を使用し、２つ以上の別個のコンテナの中に設置すべき少なくとも１つのコンテナイメージのコピーの数を決定すること、前記複数のコンテナにおけるコンテナの数を決定すること、および／または、別個のコンテナに分配すべきリソースを決定することを行うように動作可能である、請求項１４−１８のいずれかに記載のスケーラブルコンテナベースのシステム。
20. 前記コンテナ管理システムは、前記スケーラブルコンテナベースのシステムの使用からの情報を使用し、２つ以上の別個のコンテナの中に設置すべき少なくとも１つのコンテナイメージのコピーの数を決定すること、前記複数のコンテナにおけるコンテナの数を決定すること、および／または、別個のコンテナに分配すべきリソースを決定することを行うように動作可能である、請求項１４−１９のいずれかに記載のスケーラブルコンテナベースのシステム。
21. 前記ソースコードアナライザは、前記モノリシックレガシーアプリケーションのデータベースから１つ以上のサブデータベースまたはサブデータベースのクラスタを作成するようにさらに動作可能である、請求項１−２０のいずれか１項に記載のスケーラブルコンテナベースのシステム。
22. 前記コンテナビルダは、前記１つ以上のサブデータベースまたはサブデータベースのクラスタを１つ以上のコンテナの中に設置するように動作可能である、請求項１−２１のいずれか１項に記載のスケーラブルコンテナベースのシステム。
23. 前記ソースコードが変更されると、前記ソースコード変更に基づいて更新されたバイナリを含むために、前記コンテナベースのシステムは、少なくとも１つのマイクロサービスイメージ、少なくとも１つのコンテナイメージ、および少なくとも１つのコンテナを自動的に更新するように動作可能である、請求項１−２２のいずれか１項に記載のスケーラブルコンテナベースのシステム。
24. スケーラブルコンテナベースのシステムを作成し、動作させる方法であって、前記方法は、
    レガシーコンピューティング環境において実行可能なモノリシックレガシーアプリケーションを解析し、そのプログラムファイルを区分し、前記モノリシックレガシーアプリケーションによって実施可能な複数のトランザクションに対応する複数のトランザクション定義ベクトルを作成し、各トランザクションのために、そのトランザクションによって呼び出される全てのプログラムを識別することと、
    トランザクション状態リポジトリに前記複数のトランザクション定義ベクトルを記憶することと、
    前記複数のトランザクションの少なくとも一部のために、前記トランザクションが前記モノリシックレガシーアプリケーションによって実施されるときに実際に使用されるプログラムを決定することによって、動的定義リポジトリを作成することと、
    前記複数のトランザクション定義ベクトルを前記動的定義リポジトリと比較し、その対応するトランザクション定義ベクトルからトランザクションにおいて使用されないプログラムを除去し、複数のマイクロサービス定義ベクトルを作成することと、
    前記複数のマイクロサービスベクトルの各マイクロサービス定義ベクトルのために、前記レガシーコンピューティング環境において実行するようにコンパイルされたバイナリを含む対応するコンパイル済みソースコードを見つけ、前記対応するコンパイル済みソースコードを含むマイクロサービスイメージを作成し、複数のマイクロサービスイメージを形成することと、
    マイクロサービスイメージリポジトリに前記複数のマイクロサービスイメージを記憶することと、
    相補的コンポーネントリポジトリにおいて、前記レガシーコンピューティング環境と異なるコンピューティング環境においてプログラムを実行するように動作可能なレガシーエミュレータの複数の要素のイメージを記憶することであって、前記レガシーエミュレータの前記要素は、前記モノリシックレガシーアプリケーションの複数の機能または機能の組に対応する、ことと、
    前記複数のマイクロサービスにおける各マイクロサービスまたはマイクロサービスの組のためのコンテナイメージを形成することであって、複数のコンテナイメージを作成するために、前記マイクロサービスイメージリポジトリからの前記対応するマイクロサービスイメージまたは複数のイメージを使用することと、前記レガシーエミュレータの要素のためのイメージファイルを前記相補的コンポーネントリポジトリから使用することとを行い、前記レガシーエミュレータの前記要素は、実行されるときに前記マイクロサービスまたはマイクロサービスの組によって採用される機能または機能の組に対応し、前記採用される機能または機能の組は、前記マイクロサービスまたはマイクロサービスの組における前記バイナリ内の呼び出しのシグネチャによって識別される、ことと、
    コンテナイメージリポジトリに前記コンテナイメージを記憶することと、
    コンテナ管理システムを使用して、前記異なるコンピューティング環境内に少なくとも１つのコンテナを作成し、前記異なるコンピューティング環境において実行可能な形態で前記コンテナの中に少なくとも１つのコンテナイメージを記憶することと、
    前記コンテナにおける前記マイクロサービスまたはマイクロサービスの組を実行することと
    を含む、方法。
25. 前記アクティビティログアナライザを使用して、前記複数のトランザクション定義ベクトルの少なくとも一部に対応する複数の動的トランザクション定義ベクトルを作成することと、
    前記マイクロサービス定義オプティマイザを使用して、各動的トランザクション定義ベクトルを各対応するトランザクション定義ベクトルと比較し、前記複数のマイクロサービス定義ベクトルを作成することと
    を含む、請求項２４に記載の方法。
26. 前記アクティビティログアナライザが、前記レガシーコンピューティング環境において前記モノリシックレガシーアプリケーションを実行することによって生成される前記モノリシックレガシーアプリケーションのレガシーアクティビティログを使用することを含む、請求項２４または請求項２５に記載の方法。
27. 前記アクティビティログアナライザが、エミュレータを使用し、前記モノリシックレガシーアプリケーションを実行し、ログファイルを生成し、トランザクションの実行中に前記モノリシックレガシーアプリケーションによって使用されるプログラムを決定することを含む、請求項２４−２６のいずれか１項に記載の方法。
28. 前記ソースコードアナライザが、前記アクティビティログアナライザからの情報を使用し、前記トランザクション定義ベクトルを識別することを含む、請求項２４−２７のいずれか１項に記載の方法。
29. 前記ソースコードアナライザを使用して、複数の変換テーブルを作成することを含む、請求項２４−２８のいずれか１項に記載の方法。
30. 前記マイクロサービス定義オプティマイザを使用して、前記マイクロサービス定義ベクトルをさらに最適化することを含む、請求項２４−２９のいずれか１項に記載の方法。
31. 前記マイクロサービス定義オプティマイザを使用して、前記複数のトランザクションにおける２つ以上のトランザクションによって共有されるプログラムを含む追加のマイクロサービス定義ベクトルを作成することによって、前記マイクロサービス定義ベクトルをさらに最適化することを含む、請求項３０に記載の方法。
32. 前記レガシーコンピューティング環境において実行するようにコンパイルされたバイナリを含む前記コンパイル済みソースコードをバイナリリポジトリに記憶することをさらに含む、請求項２４−３１のいずれか１項に記載の方法。
33. 前記バイナリリポジトリにおける前記ソースコードを前記ソースコードリポジトリにおける前記ソースコードからバイナリファイルにコンパイルすることを含む、請求項３２に記載の方法。
34. 前記レガシーコンピューティング環境は、多重仮想記憶（ＭＶＳ）またはｚ／ＯＳコンピュータシステムを含む、請求項２４−３３のいずれか１項に記載の方法。
35. 前記相補的コンポーネントリポジトリが、前記レガシーエミュレータによって使用されるオペレーティングシステムソフトウェアパッケージの複数のイメージを記憶することと、前記コンテナビルダも、前記レガシーエミュレータの特定の要素によって使用される任意のソフトウェアパッケージのイメージを前記レガシーエミュレータの前記特定の要素を含む特定のコンテナイメージに設置することとを含む、請求項２４−３４のいずれか１項に記載の方法。
36. 前記コンテナビルダが、前記マイクロサービスまたはマイクロサービスの組における前記バイナリ内の前記呼び出しのシグネチャを前記レガシーエミュレータにおいて動作可能な呼び出しのための命令と置換することを含む、請求項２４−３５のいずれか１項に記載の方法。
37. 前記コンテナ管理システムを使用して、複数のコンテナを作成することを含む、請求項２４−３６のいずれか１項に記載の方法。
38. 相補的イメージの組を共通ポッド内の別個のコンテナの中でインスタンス化することを含む、請求項３７に記載の方法。
39. 少なくとも１つのコンテナイメージの２つ以上のコピーを２つ以上の別個のコンテナの中でアクティブにすることを含む、請求項３７および３８のいずれかに記載の方法。
40. 前記コンテナ管理システムが、前記複数のコンテナにおけるコンテナの数を変動させることを含む、請求項３７−３９のいずれか１項に記載の方法。
41. 前記コンテナ管理システムが、様々なリソースを別個のコンテナに分配することを含む、請求項３７−４０のいずれか１項に記載の方法。
42. 前記コンテナ管理システムが、前記アクティビティログアナライザからの情報を使用し、２つ以上の別個のコンテナの中に設置すべき少なくとも１つのコンテナイメージのコピーの数を決定すること、前記複数のコンテナにおけるコンテナの数を決定すること、および／または、別個のコンテナに分配すべきリソースを決定することを行うことを含む、請求項３７−４１のいずれかに記載の方法。
43. 前記コンテナ管理システムが、前記スケーラブルコンテナベースのシステムの使用からの情報を使用し、２つ以上の別個のコンテナの中に設置すべき少なくとも１つのコンテナイメージのコピーの数を決定すること、前記複数のコンテナにおけるコンテナの数を決定すること、および／または、別個のコンテナに分配すべきリソースを決定することを行うことを含む、請求項３７−４２のいずれかに記載の方法。
44. 前記ソースコードアナライザが、前記モノリシックレガシーアプリケーションのデータベースから１つ以上のサブデータベースまたはサブデータベースのクラスタを作成することを含む、請求項２４−４３のいずれか１項に記載の方法。
45. 前記コンテナビルダが、前記１つ以上のサブデータベースまたはサブデータベースのクラスタを１つ以上のコンテナの中に設置することを含む、請求項２４−４４のいずれか１項に記載の方法。
46. 前記ソースコードが変更されると、前記ソースコード変更に基づいて更新されたバイナリを含むために、少なくとも１つのマイクロサービスイメージ、少なくとも１つのコンテナイメージ、および少なくとも１つのコンテナを自動的に更新することを含む、請求項２４−４５のいずれか１項に記載の方法。