JP7841819B2 - コンピュータ実装方法、コンピュータシステムおよびコンピュータプログラム（共有ライブラリをアンロードする際にランタイムリソースをクリーンアップするためにコンテナを使用すること） - Google Patents

Description

本発明は、一般に、プログラマブルコンピュータシステムに関するものである。より具体的には、本発明は、共有ライブラリをアンロードする際にランタイムリソースをクリーンアップするためにコンテナを利用し、それによってセグメンテーションエラーを回避するコンピュータシステム、コンピュータ実装方法、およびコンピュータプログラム製品に関する。

マイクロサービスとは、ソフトウェアアーキテクチャの一種で、ソフトウェアアプリケーションの機能をより小さなフラグメントに分割し、アプリケーションの耐障害性と拡張性を高めるものである。より小さなフラグメントは、「サービス」と呼ばれる。各サービスは、アプリケーションの単一機能のみに焦点を当て、他のサービスから分離され、それぞれが独立しているという点で、モジュール化されている。モジュール化により、開発チームはチーム間の複雑な設計関連のオーケストレーションを必要とせず、異なるサービスに別々に取り組むことができる。

異なるマイクロサービスは、ＡＰＩまたはウェブサービスを通じて互いに通信し、アプリケーションの全体的な機能を実行することができる。例えば、マイクロサービスは、リモートプロシージャコール（ＲＰＣ）プロトコルを使用して、互いに通信し、他のソフトウェアアプリケーションと通信することができる。ＲＰＣは、あるプログラムが、ネットワークの詳細を理解することなく、ネットワーク上の別のコンピュータにあるプログラムからサービスを要求するために使用できるプロトコルである。ＲＰＣプロトコルは、クライアントサーバモデルを使用している。要求するプログラムはクライアントであり、サービスを提供するプログラムはサーバである。

アプリケーションプログラムは、ライブラリを利用することで、開発と実行の両面で効率化を図っている。ライブラリとは、コンピュータプログラムによって使用される不揮発性リソースの集合体である。ライブラリは、ソフトウェア開発によく利用される。ライブラリには、設定データ、ドキュメント、ヘルプデータ、メッセージテンプレート、あらかじめ書かれたコード、あらかじめ書かれたサブルーチンなどを含めることができる。より高度なプログラムを書きたいプログラマは、システムコールを何度も実装する代わりに、ライブラリを使ってシステムコールを作ることができる。ライブラリのコードは、互いに関係のない複数のプログラムから利用できるように構成されているが、あるプログラムの一部であるコードは、その１つのプログラムの中でのみ利用できるように構成されている。ライブラリは、独立したプログラムやサブプログラムで再利用できるように構成されており、ユーザはライブラリの内部の詳細を知る必要はなく、インタフェースだけを知っていればよい。ライブラリは、標準化されたプログラム要素の再利用を可能にする。プログラムがライブラリを呼び出すと、そのライブラリに実装されている動作を、自分自身で実装することなく得ることができる。ライブラリは、モジュール方式でのコードの共有を促進し、コードの配布を容易にする。

ライブラリによって実装される動作は、異なるプログラムのライフサイクルの段階で呼び出し、プログラムに接続することができる。ライブラリのコードが、呼び出しプログラムの構築中にアクセスされる場合、そのライブラリは静的ライブラリと呼ばれる。一方、呼び出しプログラムの実行ファイルを構築し、それをライブラリの実装とは別に配布する方法もある。ライブラリの動作は、実行ファイルが呼び出されて実行された後、実行を開始するプロセスの一部として、あるいは実行の途中で接続される。この場合、ライブラリはダイナミックライブラリ（ランタイムでロードされる）と呼ばれる。ダイナミックライブラリは、リンカによるプログラムの実行準備の際にロードしてリンクすることができる。また、実行の途中で、アプリケーションは明示的にモジュールのロードを要求することができる。

共有ライブラリをアンロードする際にランタイムリソースをクリーンアップするためにコンテナを使用するコンピュータ実装方法、コンピュータシステムおよびコンピュータプログラム製品を提供する。

本発明の実施形態は、プロセッサを使用して、ローダライブラリにアクセスすることと、プロセッサを使用して、ローダライブラリのモックバージョンを含むモックライブラリを生成することと、プロセッサを使用して、ローダライブラリをコンテナ化することと、プロセッサを使用して、ローダライブラリをアンロードすることと、を含むコンピュータ実装方法を含む。

本発明の実施形態は、上述したコンピュータ実装方法と実質的に同じ特徴を有するためのコンピュータシステムおよびコンピュータプログラム製品も提供する。

追加の特徴および利点は、本発明の技術によって実現される。本発明の他の実施形態および態様は、本明細書で詳細に説明され、請求された発明の一部とみなされる。利点および特徴を有する本発明のより良い理解のために、本明細書および図面を参照されたい。

本発明の態様を具現化したシステムを示すブロック図である。 本発明の態様を具現化したシステムを示すブロック図である。 本発明の態様を具現化したシステムを示すブロック図である。 本発明の態様を具現化したシステムを示すブロック図である。 本発明の態様を実施することができる例示的なコンピューティングシステムの詳細を示す図である。 本発明の実施形態によるクラウドコンピューティング環境を示す図である。 本発明の実施形態による抽象化モデルレイヤを示す図である。

本発明とみなされる主題は、本明細書の末尾にある特許請求の範囲に特に指摘され、明確に請求されている。本発明の上記および他の特徴、および利点は、添付の図面と組み合わせて取られる以下の詳細な説明から明らかである。

簡潔さのために、本発明の態様の製造および使用に関連する従来技術は、本明細書において詳細に説明されてもよいし、されなくてもよい。特に、本明細書に記載された様々な技術的特徴を実装するためのコンピューティングシステムおよび特定のコンピュータプログラムの様々な態様は既知である。したがって、簡潔さのために、多くの従来の実装の詳細は、本明細書で簡単に言及されるだけであるか、または周知のシステムもしくはプロセスの詳細またはその両方を提供することなく完全に省略される。

本明細書で説明するシステムの機能ユニットの多くは、モジュールと示されている。本発明の実施形態は、多種多様なモジュール実装に適用される。例えば、モジュールは、カスタムＶＬＳＩ回路またはゲートアレイ、論理チップ、トランジスタ、または他のディスクリートコンポーネントなどの市販の半導体を含むハードウェア回路として実装することができる。また、モジュールは、フィールドプログラマブルゲートアレイ、プログラマブルアレイロジック、プログラマブルロジックデバイスなどのプログラマブルハードウェアデバイスに実装することができる。また、モジュールは、様々な種類のプロセッサによる実行のためにソフトウェアで実装することができる。実行可能コードの特定されたモジュールは、例えば、オブジェクト、手順、または関数として編成することができるコンピュータ命令の１つまたは複数の物理的または論理的ブロックを含むことができる。しかし、特定されたモジュールの実行可能コードは、物理的に一緒に配置される必要はなく、異なる場所に格納された異種の命令を含むことができ、それらが論理的に結合されると、モジュールとして機能し、モジュールのための述べられた目的を達成する。

本明細書に図示されたシステムの様々な構成要素、モジュール、サブ機能などは、図示及び説明を容易にするために別々に描かれている。本発明の実施形態において、様々な構成要素、モジュール、サブ機能などによって実行される動作は、特に断らない限り、本明細書で説明する本発明の様々な実施形態の範囲から逸脱することなく、図示とは異なる分布にすることができる。

便宜上、本明細書で説明する技術的な機能もしくは動作またはその両方の一部は、非公式な表現を用いて伝達される。例えば、キャッシュメモリに格納されたデータを有するプロセッサは、プロセッサがそのデータを「知っている」と表現することができる。同様に、ユーザがプロセッサにロードデータコマンドを送信することは、ユーザがプロセッサにデータをロードするように「伝える」ことと表現することができる。この詳細な説明におけるそのような非公式な表現は、その非公式な表現に対応するより正式で技術的な説明を網羅するように読まれるべきであり、関連する技術の当業者は、その非公式な表現が網羅するように理解することが理解される。

ここで、本発明の態様により具体的に関連する技術の概要に目を向けると、本明細書で既に述べたように、マイクロサービスは、ソフトウェアアプリケーションの機能をより小さなフラグメントに分割して、アプリケーションの耐障害性と拡張性を高めるソフトウェアアーキテクチャの一種である。より小さなフラグメントは、「サービス」と呼ばれる。各サービスは、アプリケーションの単一機能のみに焦点を当て、他のサービスから分離され、それぞれが独立しているという点で、モジュール化されている。モジュール化によって、開発チームはチーム間の複雑な設計関連のオーケストレーションを必要とすることなく、異なるサービスに別々に取り組むことができる。

異なるマイクロサービスは、ＡＰＩまたはウェブサービスを通じて互いに通信し、アプリケーションの全体的な機能を実行することができる。例えば、マイクロサービスは、リモートプロシージャコール（ＲＰＣ）プロトコルを使用して、互いに通信し、他のソフトウェアアプリケーションと通信することができる。ＲＰＣは、あるプログラムが、ネットワークの詳細を理解することなく、ネットワーク上の別のコンピュータにあるプログラムからサービスを要求するために使用できるプロトコルである。ＲＰＣプロトコルは、クライアントサーバモデルを使用している。要求するプログラムはクライアントであり、サービスを提供するプログラムはサーバである。

アプリケーションプログラムは、ライブラリを利用することで、開発と実行の両面で効率化を図っている。ライブラリとは、コンピュータプログラムによって使用される不揮発性リソースの集合体である。ライブラリは、ソフトウェア開発によく利用される。ライブラリには、設定データ、ドキュメント、ヘルプデータ、メッセージテンプレート、あらかじめ書かれたコード、あらかじめ書かれたサブルーチンなどを含めることができる。より高度なプログラムを書きたいプログラマは、システムコールを何度も実装する代わりに、ライブラリを使ってシステムコールを作ることができる。ライブラリのコードは、互いに関係のない複数のプログラムから利用できるように構成されているが、あるプログラムの一部であるコードは、その１つのプログラムの中でのみ利用できるように構成されている。ライブラリは、独立したプログラムやサブプログラムで再利用できるように構成されており、ユーザはライブラリの内部の詳細を知る必要はなく、インタフェースだけを知っていればよい。ライブラリは、標準化されたプログラム要素の再利用を可能にする。プログラムがライブラリを呼び出すと、そのライブラリに実装されている動作を、自分自身で実装することなく得ることができる。ライブラリは、モジュール方式でのコードの共有を促進し、コードの配布を容易にする。

ライブラリによって実装される動作は、異なるプログラムのライフサイクルの段階で呼び出しプログラムに接続することができる。ライブラリのコードが、呼び出しプログラムの構築中にアクセスされる場合、そのライブラリは静的ライブラリと呼ばれる。一方、呼び出しプログラムの実行ファイルを構築し、それをライブラリの実装とは別に配布する方法もある。ライブラリの動作は、実行ファイルが呼び出されて実行された後、実行を開始するプロセスの一部として、あるいは実行の途中で接続される。この場合、ライブラリはダイナミックライブラリ（ランタイムでロードされる）と呼ばれる。ダイナミックライブラリは、リンカによるプログラムの実行準備の際にロードしてリンクすることができる。また、実行の途中で、アプリケーションは明示的にモジュールのロードを要求することができる。

ダイナミックローディングとは、コンピュータプログラムが実行時にライブラリ（または他のバイナリ）をメモリにロードし、ライブラリに含まれる関数や変数のアドレスを取得し、それらの関数を実行、または変数にアクセスし、ライブラリをメモリからアンロードできるメカニズムである。ｇＲＰＣ（グーグル（登録商標）リモートプロシージャコール)は最新のオープンソース高性能ＲＰＣフレームワークであり、あらゆる環境で実行することができる。いくつかのＲＰＣフレームワーク（例えばｇＲＰＣ）は「クロスプロセス呼び出し」をサポートしておらず、それに応じてｇＲＰＣライブラリをアンロードすることができない。より具体的には、そのようなＲＰＣフレームワークでは、共有オブジェクトをアンロードする際にセグメンテーション違反が発生する。

ここで、本発明の態様の概要に目を向けると、本発明の実施形態は、既知のＲＰＣフレームワークが共有ライブラリをアンロードする際に、コンテナを利用してランタイムリソースをクリーンアップすることによって、共有ライブラリをアンロードしようとする際に発生するセグメンテーション違反を回避するコンピュータシステム、コンピュータ実装方法、及びコンピュータプログラム製品を提供する。本発明の実施形態に従った革新的なコンピュータ実装方法は、共有ライブラリをアンロードし、実行環境を安全にクリーンアップするために提供される。本発明の実施形態は、コンテナ化されたlibld.so（すなわち、コンテナ化されたダイナミックリンカ／ローダ）とターゲット共有ライブラリ（すなわち、アンロードされる共有ライブラリ）を使用して、ターゲット共有ライブラリをアンロードする際に安全に破壊できるような言語環境にする。共有ライブラリの接尾辞は常に「.so」である。プログラム命令/関数「libtarget_go.so」と「libld.so」は、共有ライブラリである。ただし、「libld.so」（またはld.so）はダイナミックリンカ／ローダであり、他の共有ライブラリをロード／アンロードするためのdlopen()/dlsym()/dlcose()を提供するという点で「libld.so」は特殊な共有ライブラリである。

ダイナミックリンク（ＤＬ）インターセプターモジュールは、コンテナの作成／破壊、ホストからコンテナへのデータおよび関数の要求の配信など、コンテナのライフサイクルを管理する。また、セッションのライフサイクルも管理する。セッションは、ｄｌ関数が来たときにコンテナと対話するために使用される。スタック処理モジュールは、スタックとプロトコルバッファの間の変換を行う。プロトコルバッファは、構造化されたデータをシリアライズするための、言語やプラットフォームに依存しない拡張可能なメカニズムである。ユーザがデータの構造化を一度定義すれば、専用に生成されたソースコードを使用して、様々な言語を用い様々なデータストリームとの間で構造化データの書き込みや読み出しを容易に行うことができる。ＤＬインターセプターモジュールとマッピングスタブモジュールは、この関数を用いて、互いにデータの変換をし、配信する。マッピングスタブモジュールは、ＬＤインターセプターモジュールが作成したコンテナ内のlibdl.soを利用して、ターゲット共有ライブラリをメモリアドレス空間にロードし、セッションＩＤとハンドラ間のマップを記録する。そして、ｄｌ関数が来たときに、そのデータがターゲットライブラリにルーティングされる。ｄｌｃｌｏｓｅ要求が来たら、ＤＬインターセプターモジュールはコンテナを破壊し、セッションＩＤを無効化する。したがって、本発明の実施形態では、共有ライブラリをコンテナ化することにより、セグメンテーション違反を発生させることなく共有ライブラリをアンロードすることができる。セグメンテーションはコンテナ内部で起こるかもしれないが、本発明の実施形態によれば、アンロードする際にコンテナ全体が破壊される。したがって、本発明の態様を用いると、コンテナの外側のエンドユーザは、「セグメンテーション違反」の障害を見ることがない。

ここで、本発明の側面のより詳細な説明に移ると、図１は本発明の実施形態における、システム１００を示している。システム１００を説明する前に、本発明の態様に関連するいくつかのオープンソースの概念について説明する。プログラム「libld.so」および「ld-linux.so」は、プログラムが必要とする共有オブジェクト（共有ライブラリ）を見つけてロードし、プログラムの実行を準備し、その後、プログラムを実行する。したがって、「libld.so」はダイナミックリンカ/ローダである。他の共有ライブラリをロード/アンロードするためのdlopen()/dlsym()/dlcose()を提供する。また、プロトコルバッファは、構造化データをシリアライズするための言語やプラットフォームに依存しない拡張可能なメカニズムである。ユーザがデータの構造化を一度定義すれば、専用に生成されたソースコードを使用して、様々な言語を用いて、様々なデータストリームとの間で構造化データの書き込みや読み出しを容易に行うことができる。

再び図１を参照すると、システム１００は、図示のように構成され配置されたスタック処理モジュール１３４を介してコンテナ化プラットフォーム１５０と通信している外部エンティティ１１０を含む。エンティティ１１０は、ソフトウェア命令（またはコンピュータコード）１１２のセットと、ダイナミックリンク（ＤＬ）インターセプターモジュール１１４を含む。ソフトウェア命令１１２は、dlclose( )命令を使用するように構成されている。より具体的には、ソフトウェア命令１１２は、プログラム／アプリケーションであり、共有ライブラリをロードする。プログラム「libtarget_go.so」は、共有ライブラリの名称の一例である。任意の共有ライブラリであってもよい。コンピュータコード１１２のプログラム命令dlopen()/dlsym()/dlclose()は、共有ライブラリをロードするためにlibld.soが提供する３つの関数である。コンピュータコード１１２は、モック化されたダイナミックリンカ／ローダ（すなわち、libld.so）によって提供されるモックされたdlopen()/dlsym()/dlclose()を利用して共有ライブラリlibtarget_go.soをロード／アンロードする処理を示している。

本発明の態様の利益がなければ、コンピュータコード１１２は「libld.so」に対話したり、呼び出したりするだろう。しかし、「libld.so」は、共有ライブラリをアンロードする際に、環境全体をクリーンアップすることができない。時々、「libld.so」はアンロード中にエラー、例えば、「セグメンテーション違反」エラーを起こし、コンピュータコード１１２に影響を与える。本発明の態様に従って、ＤＬインターセプターモジュール１１４は、コンピュータコード１１２が本物の「libld.so」の代わりにモック化されたlibld.so１１６に対話する（または呼び出す）ことができるように、新しいモック化されたlibld.so１１６を導入する。ＤＬインターセプターモジュール１１４は、コンテナライフサイクルを管理し、また、コンピュータコード１１２からコンテナ化プラットフォーム１５０にデータおよび関数要求を配信するように構成される。また、ＤＬインターセプターモジュール１１４は、セッションライフサイクルを管理する。それは、内部に共有ライブラリを有するコンテナを破壊することによって、共有ライブラリをアンロードする。したがって、コンテナ内部の予期せぬエラーは、ホストにあるアプリケーション／プログラムには影響がない。モック化されたlibld.so１１６は、モック化された「libld.so」である。モック化されたlibld.so１１６は、コンピュータコード１１２から要求を受け取り、本物の「libld.so」に処理され、配信されることになる。エンドユーザがｄｌ関数（すなわち、dlopen/dlsym/dlclose）を呼び出すとき、実際にはモック化されたlibdl.so１１６内のモック化されたｄｌ関数を呼び出すことになる。

ＤＬインターセプターモジュール１１４はまた、図示のように構成され配置されたセッションライフサイクル管理モジュール１１８とコンテナ処理モジュール１２０を含む。セッションライフサイクル管理モジュール１１８は、１つのプログラム／アプリケーションが一意のセッション構造に対応するセッション構造を作成する。セッション構造は「セッションＩＤ」を含み、これは「ターゲット共有ライブラリ名」である。カスタマイズされたコンテナが起動すると、コンテナ内のダイナミックリンカ／ローダ（libld.so）により「ターゲット共有ライブラリ名」がロードされることになる。コンテナ処理モジュール１２０では、ＤＬは「ダイナミックリンク」を意味し、「ダイナミックリンクライブラリ」は「共有ライブラリ」と同じ意味である。従って、「ＤＬ名」は、共有ライブラリ名であるダイナミックリンクライブラリ名である。このように、コンテナ処理モジュール１２０は、コンテナを管理するための機能を提供する。例えば、このモジュール１２０は、Init()関数とDestroy()関数を提供する。Init（セッションＩＤ、ＤＬ名）は、コンテナを作成し、ダイナミックリンカ／ローダ（libld.so）がどの共有ライブラリをコンテナ内にロードする必要があるかを知るために、ＤＬ名（共有ライブラリ名）をコンテナに渡す。Destroy( )は、作成されたコンテナを破壊する。

スタッキング処理モジュール１３２は、解析と遷移モジュール１３４を含み、モジュール１３２は、コールスタック１３６とプロトコル（proto）バッファ１３８に通信可能に結合される。一般に、コールスタックは、コンピュータプログラムのアクティブなサブルーチンに関する情報を格納するスタックデータ構造である。コールスタックのメンテナンスは、ほとんどのソフトウェアが適切に機能するために重要であるが、詳細は通常、高レベルのプログラミング言語では隠され、自動化されている。多くのコンピュータ命令セットは、スタックを操作するための特別な命令を提供する。コールスタックは、いくつかの関連した目的で使用されるが、１つを持つ主な理由は、各アクティブサブルーチンが実行を終了するときに制御を返すべきポイントを追跡することである。アクティブサブルーチンとは、呼び出されたが、まだ実行が完了していないサブルーチンのことで、その後、制御は呼び出し元のポイントに戻されるべきものである。このようなサブルーチンの起動は、任意のレベルまでネスト化することができ（特殊なケースとして再帰的）、そのためスタック構造である。

モジュール１３２の解析と遷移モジュール１３４は、スタック処理モジュール１３２の主な作業の性能を受け持つ。「スタック」形式のコンピュータコードのパラメータは転送が困難であるが、プロトコルバッファ形式のパラメータは転送が容易である。従って、解析と遷移モジュール１３４は、変換を行うために、Pack( )とUnPack( )という２つのパラメータ操作メソッドを提供する。スタック処理モジュール１３２は、実行中のコンピュータコードのコールスタック１３６からパラメータを読み出し、そのパラメータをプロトコルバッファ形式（プロトコルバッファ１３８）に変換する。また、プロトコルバッファ形式からパラメータを変換し、その後、コンピュータコードのコールスタック１３６にパラメータを書き戻すこともできる。前述のように、解析と遷移モジュール１３４を通じて、スタック処理モジュール１３２は、２つのパラメータ操作メソッド、すなわちPack( )及びUnPack( )を提供する。Pack( )メソッドは、実行中のコンピュータコードのコールスタック１３６からパラメータを読み出し、そのパラメータをプロトンバッファ形式（プロトコルバッファ１３８）に変換する。UnPack( )メソッドは、プロトコルバッファ形式からパラメータを変換し、その後、コンピュータコードのコールスタック１３６にパラメータを書き込む。

コンテナ化プラットフォーム１５０は、マッピングスタブモジュール１５２と、コマンド／関数のlibld.soセットと、コマンド／関数のlibtarget_go.soセットとを含む。一般に、コンテナ化プラットフォーム１５０は、コンテナ化アプリケーションの構築、デプロイ、および管理のために構成および配置されたオープンソースのコンテナ化プラットフォームであり得る。オープンソースのコンテナ化プラットフォームは、開発者がアプリケーションをコンテナ、すなわちアプリケーションのソースコードと、そのコードを任意の環境で実行するために必要なオペレーティングシステム（ＯＳ）ライブラリおよび依存関係を組み合わせた標準化実行可能コンポーネントに、パッケージ化することを可能にする。コンテナは、分散アプリケーションの配信を簡素化し、企業がクラウドネイティブ開発やハイブリッドマルチクラウド環境へ移行するにつれて、人気が増加している。オープンソースのコンテナ化プラットフォームは、基本的に開発者がシンプルなコマンドを使用してコンテナを構築、デプロイ、実行、更新、停止し、単一のＡＰＩを通じて省力化を自動化できるようにするツールキットである。コンテナは、Ｌｉｎｕｘカーネルに組み込まれたプロセス分離と仮想化機能によって実現されている。これらの機能、すなわちプロセス間でリソースを割り当てるための制御グループ（Ｃｇｒｏｕｐｓ）や、システムの他のリソースや領域への処理のアクセスや可視性を制限するための名前空間などは、ハイパーバイザーによって複数の仮想マシン（ＶＭ）が単一のハードウェアサーバのＣＰＵ、メモリ、その他のリソースを共有できるのとほぼ同様に、複数のアプリケーションコンポーネントで単一のホストオペレーティングシステムのインスタンスのリソースを共有することを可能にするものである。その結果、コンテナ技術は、アプリケーションの分離、費用対効果の高いスケーラビリティ、ディスポーザビリティを含む、ＶＭのすべての機能と利点を提供する。

コンテナ化プラットフォームでは、実行可能なアプリケーションのソースコードと、アプリケーションコードがコンテナとして動作するために必要なすべてのツール、ライブラリ、および依存関係を含む、いわゆる「イメージ」を使用する。イメージが実行されると、そのイメージはコンテナの１つのインスタンス（または複数のインスタンス）になる。ゼロからイメージを構築することも可能であるが、ほとんどの開発者は一般的なリポジトリからイメージを取得する。１つのベースイメージから複数のイメージを作成することができ、それらのイメージはスタックの共通性を共有することになる。イメージはレイヤで構成されており、各レイヤはイメージのバージョンに対応している。開発者がイメージに変更を加えるたびに、新しいトップレイヤが作成され、このトップレイヤが以前のトップレイヤを現在のバージョンのイメージとして置き換える。以前のレイヤは、ロールバックや他のプロジェクトで再利用するために保存される。イメージからコンテナを作成するたびに、コンテナレイヤと呼ばれる別の新しいレイヤが作成される。コンテナに加えられた変更、すなわちファイルの追加や削除などは、コンテナレイヤにのみ保存され、コンテナの実行中にのみ存在する。このようにイメージを繰り返し作成する処理によって、１つのベースイメージから複数のライブコンテナインスタンスを実行でき、その際、共通のスタックを活用できるため、全体的な効率が向上する。コンテナとは、イメージのライブ実行インスタンスである。イメージは読み取り専用のファイルであるが、コンテナはライブで、一時的な、実行可能なコンテンツである。ユーザはコンテナと対話し、管理者はｄｏｃｋｅｒコマンドを使用してコンテナの設定や状態を調整することができる。

より具体的にコンテナ化プラットフォーム１５０を参照すると、プラットフォーム１５０は、マッピングスタブモジュール１５２、ダイナミックリンカ／ローダ（すなわち、libdl.so）、およびlibtarget_go.soなどの他の共有ライブラリを含むコンテナである。システム１００上のコンピュータコードによってdlclose( )が呼び出されると、dlclose( )はＤＬインターセプターモジュール１１４を利用して、コンテナ全体を破壊する。したがって、コンテナ内のすべてのものが破壊される。コンテナ内部で発生した障害（例えば、セグメンテーション違反）は、システム１００の言語環境に影響を与えない。

マッピングスタブモジュール１５２は、コンテナ化プラットフォーム１５０のメモリアドレス空間へ、本物のlibld.soをロードする。そして、libld.soは、コンテナ化プラットフォーム１５０のメモリアドレス空間に、libtarget_go.soをロードする。そして、セッションＩＤとハンドラの間のマップを記録する。ｄｌ関数が来たときに、データとdlsym()要求をターゲットライブラリにルーティングする。「libld.so関数適用」モジュールは、ホストからプロトコルバッファデータを受信する。マッピングスタブモジュール１５２は、dlsym()要求が来たときに、ルーティングすべきターゲット先がわかるように、セッションＩＤとハンドラのマップを保持している。

「libtarget.go.so」は、「func1（ ）」、「func2（ ）」、「func3（ ）」といった関数のシリアルを含む共有ライブラリである。図１は、「func1」要求がシステム１００でどのように処理されるかを示している。コンピュータコード１１２が「libtarget_go.so」内の「func1( )」を呼び出したいとき、ＤＬインターセプターモジュール１１４内のモック化されたdlopen( )を利用して、コンテナ化プラットフォーム１５０を作成する。モック化されたdlsym(p, "func1")を利用して、コンテナ化プラットフォーム１５０にリクエストを送信する。モック化されたdlclose( )を利用して、コンテナ化プラットフォーム１５０を破壊する。

システム１００の動作は、図２、３、および４に示されており、各図２、３、および４に示される様々な動作ステップを参照して説明されることになる。図２および３は、図１に示したシステム１００の構成要素の一部の追加的な詳細を提供するので、図２、３、および４に示した方法論を説明する前に、これらの追加的な詳細を紹介する。図２に示すように、モック化されたlibld.so１１６の内部には、「モック化されたｄｌｓｙｍ」、「モック化されたｄｌｃｌｏｓｅ」、および「モック化されたｄｌｏｐｅｎ」が含まれる。既存の「libld.so」には、「dlsym( )」、「dlclose( )」、「dlopen( )」が含まれる。図２～４に描かれた方法論を用いることにより、コンピュータコード１１２が「dlsym( )」、「dlclose( )」、「dlopen( )」を呼び出すとき、実際には、モック化されたlibld.so１１６の「モック化されたｄｌｓｙｍ」、「モック化されたｄｌｃｌｏｓｅ」、「モック化されたｄｌｏｐｅｎ」が呼び出されることになる。モック化されたlibld.so１１６は、コンテナ化プラットフォーム１５０内の本物のlibld.soに関数要求をルーティングする。

図２に示すように、セッションライフサイクル管理１１８の内部には、「セッション」、「ＩＤ」、「ＤＬ名」、「コンテナオプション」、「パラメータオプション」などがある。コンピュータコードがｄｌｏｐｅｎ関数を呼び出すとき、実際にはlibdl.so共有ライブラリ内のモック化されたｄｌｏｐｅｎを呼び出している。モック化されたｄｌｏｐｅｎは、セッションライフサイクル管理モジュール１１８と対話する。セッションライフサイクル管理モジュール１１８は、セッション構造を作成する。各コンピュータコード１１２は、一意のセッション構造を作成し、このセッション構造は、一意のセッションＩＤを含む。「セッションＩＤ」は、セッションアイデンティティである。「ＤＬ名」は、ダイナミックリンクライブラリ名であり、共有ライブラリ名である。「コンテナオプション」は、Init( )Destroy( )およびInvoke( )関数に対する動作を含む。Init( )はコンテナを初期化する。Destroy( )はコンテナを破壊する。Invoke( )はコンテナ内でlibtarget_go.soの実関数（関数１、２、３）を呼び出す。「パラメータオプション」は、Pack( )およびUnPack( )メソッドを指す。Pack( )メソッドは、実行中のコンピュータコード１１２のコールスタック１３６からパラメータを読み出し、そのパラメータを「プロトコルバッファ」の形式に変換する。Unpack( )メソッドは、パラメータを「プロトコルバッファ」の形式から変換した後、コンピュータコード１１２のコールスタック１３６にパラメータを書き込む。

図２に示すように、コンテナ処理モジュール１２０の内部には、「コンテナ動作」、「Init」、「Destroy」、及び「Invoke shared library」がある。コンテナ処理モジュール１２０は、コンテナ化プラットフォーム１５０の初期化、コンテナ化プラットフォーム１５０の破壊、及びコンテナ化プラットフォーム１５０へのdlsym( )要求の配信を行うために、これらの動作を提供する。

図２に示すように、解析と遷移１３４と書かれたボックスの中には、「パラメータ動作」、 「Pack ( )」、「UnPack( )」がある。「パラメータオプション」は、Pack( )およびUnPack( )メソッドを指す。これは、変換のためにデータをパックし、データが到着したらアンパックすることを目的としている。

図３に示すように、コンテナ化プラットフォーム１５０の内部には、「libtarget_golang.so」がある。「libtarget_go.so」は、共有ライブラリの名称の一例である。任意の名称とすることができる。本発明の実施形態は、元の言語環境を一切汚染することなく、共有ライブラリ「libtarget_go.so」を完全にアンロードすることに着目したものである。

ここで、図２～４に示す方法論を参照すると、図２において、ｄｌｏｐｅｎについては、Ｓ１において、エンドユーザがｄｌｏｐｅｎ関数を呼び出すと、実際にはlibdl.so共有ライブラリ内の「モック化された」ｄｌｏｐｅｎが呼び出される。Ｓ２では、モック化されたｄｌｏｐｅｎは、セッションライフサイクル管理モジュール１１８と対話する。セッションライフサイクル管理モジュール１１８は、セッションＩＤとしての新しいＵＵＩＤ、新しいＤＬ名、ロードするターゲット共有ライブラリ、コンテナ処理モジュール１２０が提供する登録コンテナ動作、およびスタック処理モジュール１３２が提供する登録パラメータ動作を含むセッション構造を作成する。Ｓ３では、モック化されたｄｌｏｐｅｎは、init( )メソッドを利用して、新しいコンテナを作成する。

ｄｌｃｌｏｓｅについては、Ｓ４では、エンドユーザがｄｌｃｌｏｓｅ関数を呼び出すと、実際にはlibdl.so共有ライブラリ内のモック化されたｄｌｃｌｏｓｅが呼び出される。Ｓ５では、モック化されたｄｌｃｌｏｓｅは、セッション構造のセッションＩＤを無効化する。Ｓ６では、destroy( )メソッドを利用してコンテナを破壊し、セッション構造を解放する。

ｄｌｓｙｍについては、Ｓ７では、エンドユーザがｄｌｓｙｍ関数を呼び出すと、実際にはlibdl.so共有ライブラリ内のモック化されたｄｌｓｙｍが呼び出される。Ｓ８では、モック化されたｄｌｓｙｍは、セッションライフサイクル管理モジュール１１８と対話する。Ｓ９では、セッションライフサイクル管理モジュール１１８は、Ｓ２でスタック処理モジュール１３２が登録したpack( )メソッドを利用し、スタック１３６からプロトコルバッファ１３８にパラメータを変換する。Ｓ１０では、モック化されたｄｌｓｙｍは、Ｓ２においてコンテナ処理モジュール１２０により登録されたinvoke( )メソッドを利用して、前のステップのプロトコルバッファ１３８との呼び出しを行う。Ｓ１１では、モック化されたｄｌｓｙｍは、結果とパラメータを取得した後、unpack( )メソッドを利用して、プロトコルバッファ１３８からスタック１３６へ変換を行う。

図３および図４は、追加の動作Ｓ１～Ｓ８を示す図である。なお、図３および図４におけるＳ１～Ｓ８の呼称は便宜上用いたものであり、図３および図４に示すＳ１～Ｓ８は、図２に示すＳ１～Ｓ８と異なることに留意されたい。図３に示すように、Ｓ１では、init( )メソッドがコンテナを作成し、ベースイメージとしてホストイメージを使用する。システムディレクトリ、特に、ライブラリディレクトリをコンテナに対してホスト上にマッピングし、マッピングスタブモジュール１５２を初期化する。マッピングスタブモジュール１５２は、libld.soをアドレス空間へロードする。Ｓ２では、セッションＩＤ、ターゲットライブラリ名、関数名を含むプロトコルバッファデータがコンテナに渡される。libld.soでは、アドレス空間へのターゲットライブラリのロードにDlopen( )を使用する。Dlopen( )はハンドラを返し、そのハンドラはdlsym( )とdlclose( )で使用される。Ｓ４では、セッションＩＤを前のステップで生成したハンドラにマッピングされる。Ｓ５では、destroy( )メソッドにより、Ｓ１で作成したコンテナを破壊する。

図４に示すように、Ｓ６において、invoke( )メソッドは、セッションＩＤ、関数名、関数パラメータを含むプロトコルバッファデータをマッピングスタブモジュール１５２に渡す。Ｓ７において、マッピングスタブモジュール１５２は、セッションＩＤによりハンドラを取得する。Ｓ８では、マッピングスタブモジュール１５２は、ハンドラ、関数名、および関数パラメータと共にlibld.soを利用することにより、ターゲット関数を呼び出す。Ｓ９では、libld.soが実関数を呼び出す。

従って、本発明の実施形態は、技術的な利点と効果を提供することが分かる。本発明の実施形態は、共有ライブラリをアンロードする際に、共有ライブラリの全てのリソースをクリーンアップすることができる。この変更はエンドユーザにとって透過的であり、コード変更はエンドユーザによって行われる必要がある。本発明の実施形態は、共有ライブラリまたはプログラミング言語の制限を有しない。モック化されたライブラリ（モック化されたlibld.so）コンテナは、コンテナの外側にある。libld.soはコンテナ内にあり、モック化されたlibld.soはコンテナ内のlibld.soに要求を配信する。libld.soはローダライブラリであり、モック化されたlibld.soはモック化されたローダライブラリである。

したがって、本発明の実施形態は、ＤＬインターセプター、スタック処理、及びコンテナ化されたターゲット共有ライブラリを用いて、共有ライブラリをアンロードし、言語環境を安全にクリーンアップするように構成された新規のコンピュータ実装方法を提供する。ＤＬインターセプターモジュールは、共有ライブラリのセッションライフサイクルおよびコンテナライフサイクルを管理し、ｄｌｏｐｅｎ要求が来たときにコンテナを作成し、ｄｌｃｌｏｓｅ要求が来たときにコンテナを破壊する。ｄｌｓｙｍが来ると、ホストからコンテナへデータと関数の要求が転送される。ハンドラに関連付けられたセッションが生成され、破壊される。スタック処理モジュールは、スタックとプロトコルバッファ間の変換を行う。ＤＬインターセプターモジュールとマッピングスタブモジュールは、この関数を利用して、相互にデータを変換し、配信する。マッピングスタブモジュールは、libdl.soを利用してターゲット共有ライブラリをメモリアドレス空間にロードし、セッションＩＤとハンドラ間のマップを記録する。ＤＬ関数が来たときに、データとｄｌｓｙｍ要求をターゲットライブラリにルーティングする。

図５は、本明細書で説明する本発明の様々な実施形態のコンピュータベースの構成要素のいずれかを実装するために使用することができるコンピュータシステム５００の例を示している。コンピュータシステム５００は、本発明の態様に従って本明細書に記載されるコンテンツベースのセマンティックモニタリング動作の様々な態様を実行するように構成された例示的なコンピューティング装置（「コンピュータ」）５０２を含む。コンピュータ５０２に加えて、例示的なコンピュータシステム５００は、コンピュータ５０２を追加のシステム（不図示）に接続するネットワーク５１４を含み、インターネット、イントラネット、もしくは無線通信ネットワークまたはこれらの組み合わせなどの１つまたは複数の広域ネットワーク（ＷＡＮ）もしくはローカルエリアネットワーク（ＬＡＮ）またはその両方を含むことが可能である。コンピュータ５０２及び追加のシステムは、例えば、それらの間でデータを通信するために、ネットワーク５１４を介して通信している。

例示的なコンピュータ５０２は、プロセッサコア５０４、メインメモリ（「メモリ」）５１０、および入力／出力コンポーネント５１２を含み、これらはバス５０３を介して通信可能である。プロセッサコア５０４は、キャッシュメモリ（「キャッシュ」）５０６および制御部５０８を含み、これらは、以下でより詳細に説明する分岐予測構造および関連する検索、ヒット、検出および更新ロジックを含む。キャッシュ５０６は、プロセッサ５０４からオンチップまたはオフチップである複数のキャッシュレベル（不図示）を含むことができる。メモリ５１０は、そこに格納された様々なデータ、例えば、命令、ソフトウェア、ルーチンなどを含むことができ、これらは、例えば、プロセッサ５０４による実行のために、制御部５０８によってキャッシュ５０６に転送または、キャッシュ５０６から転送されることができる。入力／出力コンポーネント５１２は、ディスプレイ、キーボード、モデム、ネットワークアダプタなど、コンピュータ５０２への、またはコンピュータ５０２からローカルもしくはリモートまたはその両方の入力／出力操作を容易にする１つまたは複数の構成要素（不図示）を含むことができる。

本開示は、クラウドコンピューティングに関する詳細な説明を含むが、本明細書に記載された教示の実装は、クラウドコンピューティング環境に限定されないことを理解されたい。むしろ、本発明の実施形態は、現在知られている又は後に開発される任意の他のタイプのコンピューティング環境と組み合わせて実施することが可能である。

クラウドコンピューティングは、設定可能なコンピューティングリソースの共有プール（例えばネットワーク、ネットワーク帯域幅、サーバ、処理、メモリ、記憶装置、アプリケーション、仮想マシンおよびサービス）へ、簡便かつオンデマンドのネットワークアクセスを可能にするためのサービス提供のモデルであり、最小限の管理労力または最小限のサービスプロバイダとのやり取りによって速やかに準備（provision）およびリリースできるものである。このクラウドモデルは、少なくとも５つの特性、少なくとも３つのサービスモデル、および少なくとも４つの展開モデルを含むことがある。

特性は以下の通りである。

オンデマンド・セルフサービス：クラウドの消費者は、サービスプロバイダとの人的な対話を必要することなく、必要に応じて自動的に、サーバ時間やネットワークストレージなどのコンピューティング能力を一方的に準備することができる。

ブロード・ネットワークアクセス：コンピューティング能力はネットワーク経由で利用可能であり、また、標準的なメカニズムを介してアクセスできる。それにより、異種のシンまたはシッククライアントプラットフォーム（例えば、携帯電話、ラップトップ、ＰＤＡ）による利用が促進される。

リソースプーリング：プロバイダのコンピューティングリソースはプールされ、マルチテナントモデルを利用して複数の消費者に提供される。様々な物理リソースおよび仮想リソースが、需要に応じて動的に割り当ておよび再割り当てされる。一般に消費者は、提供されたリソースの正確な位置を管理または把握していないため、位置非依存（location independence）の感覚がある。ただし消費者は、より高い抽象レベル（例えば、国、州、データセンタ）では場所を特定可能な場合がある。

迅速な柔軟性（elasticity）：コンピューティング能力は、迅速かつ柔軟に準備することができるため、場合によっては自動的に、直ちにスケールアウトし、また、速やかにリリースされて直ちにスケールインすることができる。消費者にとって、準備に利用可能なコンピューティング能力は無制限に見える場合が多く、任意の時間に任意の数量で購入することができる。

測定されるサービス：クラウドシステムは、サービスの種類（例えば、ストレージ、処理、帯域幅、アクティブユーザアカウント）に適したある程度の抽象化レベルでの測定機能を活用して、リソースの使用を自動的に制御し最適化する。リソース使用量を監視、制御、および報告して、利用されるサービスのプロバイダおよび消費者の両方に透明性を提供することができる。

サービスモデルは以下の通りである。

サービスとしてのソフトウェア（ＳａａＳ）：消費者に提供される機能は、クラウドインフラストラクチャ上で動作するプロバイダのアプリケーションを利用できることである。当該そのアプリケーションは、ウェブブラウザ（例えばウェブメール）などのシンクライアントインタフェースを介して、各種のクライアント装置からアクセスできる。消費者は、ネットワーク、サーバ、オペレーティングシステム、ストレージや、個別のアプリケーション機能さえも含めて、基礎となるクラウドインフラストラクチャの管理や制御は行わない。ただし、ユーザ固有の限られたアプリケーション構成の設定はその限りではない。

サービスとしてのプラットフォーム（ＰａａＳ）：消費者に提供される機能は、プロバイダによってサポートされるプログラム言語およびツールを用いて、消費者が作成または取得したアプリケーションを、クラウドインフラストラクチャに展開（deploy）することである。消費者は、ネットワーク、サーバ、オペレーティングシステム、ストレージを含む、基礎となるクラウドインフラストラクチャの管理や制御は行わないが、展開されたアプリケーションを制御でき、かつ場合によってはそのホスティング環境の構成も制御できる。

サービスとしてのインフラストラクチャ（ＩａａＳ）：消費者に提供される機能は、オペレーティングシステムやアプリケーションを含む任意のソフトウェアを消費者が展開および実行可能な、プロセッサ、ストレージ、ネットワーク、および他の基本的なコンピューティングリソースを準備することである。消費者は、基礎となるクラウドインフラストラクチャの管理や制御は行わないが、オペレーティングシステム、ストレージ、および展開されたアプリケーションを制御でき、かつ場合によっては一部のネットワークコンポーネント（例えばホストファイアウォール）を部分的に制御できる。

展開モデルは以下の通りである。

プライベートクラウド：このクラウドインフラストラクチャは、特定の組織専用で運用される。このクラウドインフラストラクチャは、当該組織または第三者によって管理することができ、オンプレミスまたはオフプレミスで存在することができる。

コミュニティクラウド：このクラウドインフラストラクチャは、複数の組織によって共有され、共通の関心事（例えば、ミッション、セキュリティ要件、ポリシー、およびコンプライアンス）を持つ特定のコミュニティをサポートする。このクラウドインフラストラクチャは、当該組織または第三者によって管理することができ、オンプレミスまたはオフプレミスで存在することができる。

パブリッククラウド：このクラウドインフラストラクチャは、不特定多数の人々や大規模な業界団体に提供され、クラウドサービスを販売する組織によって所有される。

ハイブリッドクラウド：このクラウドインフラストラクチャは、２つ以上のクラウドモデル（プライベート、コミュニティまたはパブリック）を組み合わせたものとなる。それぞれのモデル固有の実体は保持するが、標準または個別の技術によってバインドされ、データとアプリケーションの可搬性（例えば、クラウド間の負荷分散のためのクラウドバースティング）を実現する。

クラウドコンピューティング環境は、ステートレス性（statelessness）、低結合性（low coupling）、モジュール性（modularity）および意味論的相互運用性（semantic interoperability）に重点を置いたサービス指向型環境である。クラウドコンピューティングの中核にあるのは、相互接続されたノードのネットワークを含むインフラストラクチャである。

ここで、図６に例示的なクラウドコンピューティング環境５０を示す。図示するように、クラウドコンピューティング環境５０は１つ以上のクラウドコンピューティングノード１０を含む。これらに対して、クラウド消費者が使用するローカルコンピュータ装置（例えば、ＰＤＡもしくは携帯電話５４Ａ、デスクトップコンピュータ５４Ｂ、ラップトップコンピュータ５４Ｃ、もしくは自動車コンピュータシステム５４Ｎまたはこれらの組み合わせなど）は通信を行うことができる。ノード１０は互いに通信することができる。ノード１０は、例えば、上述のプライベート、コミュニティ、パブリックもしくはハイブリッドクラウドまたはこれらの組み合わせなど、１つ以上のネットワークにおいて、物理的または仮想的にグループ化（不図示）することができる。これにより、クラウドコンピューティング環境５０は、サービスとしてのインフラストラクチャ、プラットフォームもしくはソフトウェアまたはこれらの組み合わせを提供することができ、クラウド消費者はこれらについて、ローカルコンピュータ装置上にリソースを維持する必要がない。なお、図６に示すコンピュータ装置５４Ａ～Ｎの種類は例示に過ぎず、コンピューティングノード１０およびクラウドコンピューティング環境５０は、任意の種類のネットワークもしくはネットワークアドレス指定可能接続（例えば、ウェブブラウザの使用）またはその両方を介して、任意の種類の電子装置と通信可能であることを理解されたい。

ここで、クラウドコンピューティング環境５０（図６）によって提供される機能的抽象化レイヤのセットを図７に示す。なお、図７に示すコンポーネント、レイヤおよび機能は例示に過ぎず、本発明の実施形態はこれらに限定されないことをあらかじめ理解されたい。図示するように、以下のレイヤおよび対応する機能が提供される。

ハードウェアおよびソフトウェアレイヤ６０は、ハードウェアコンポーネントおよびソフトウェアコンポーネントを含む。ハードウェアコンポーネントの例には、メインフレーム６１、縮小命令セットコンピュータ（ＲＩＳＣ）アーキテクチャベースのサーバ６２、サーバ６３、ブレードサーバ６４、記憶装置６５、ならびにネットワークおよびネットワークコンポーネント６６が含まれる。いくつかの実施形態において、ソフトウェアコンポーネントは、ネットワークアプリケーションサーバソフトウェア６７およびデータベースソフトウェア６８を含む。

仮想化レイヤ７０は、抽象化レイヤを提供する。当該レイヤから、例えば以下の仮想エンティティを提供することができる：仮想サーバ７１、仮想ストレージ７２、仮想プライベートネットワークを含む仮想ネットワーク７３、仮想アプリケーションおよびオペレーティングシステム７４、ならびに仮想クライアント７５。

一例として、管理レイヤ８０は以下の機能を提供することができる。リソース準備８１は、クラウドコンピューティング環境内でタスクを実行するために利用されるコンピューティングリソースおよび他のリソースの動的な調達を可能にする。計量および価格設定８２は、クラウドコンピューティング環境内でリソースが利用される際のコスト追跡、およびこれらのリソースの消費に対する請求またはインボイス送付を可能にする。一例として、これらのリソースはアプリケーションソフトウェアのライセンスを含んでよい。セキュリティは、データおよび他のリソースに対する保護のみならず、クラウド消費者およびタスクの識別確認を可能にする。ユーザポータル８３は、消費者およびシステム管理者にクラウドコンピューティング環境へのアクセスを提供する。サービスレベル管理８４は、要求されたサービスレベルが満たされるように、クラウドコンピューティングリソースの割り当ておよび管理を可能にする。サービス品質保証（ＳＬＡ）の計画および履行８５は、ＳＬＡに従って将来必要になると予想されるクラウドコンピューティングリソースの事前手配および調達を可能にする。

ワークロードレイヤ９０は、クラウドコンピューティング環境が利用可能な機能の例を提供する。このレイヤから提供可能なワークロードおよび機能の例には、マッピングおよびナビゲーション９１、ソフトウェア開発およびライフサイクル管理９２、仮想教室教育の配信９３、データ分析処理９４、取引処理９５、および共有ライブラリをアンロードする際に、ランタイムリソースをクリーンアップするコンテナを利用することによる、セグメンテーションエラーの自動回避９６が含まれる。

本発明は、任意の可能な技術詳細レベルで統合されたシステム、方法もしくはコンピュータプログラム製品またはそれらの組み合せとすることができる。コンピュータプログラム製品は、プロセッサに本発明の態様を実行させるためのコンピュータ可読プログラム命令を記憶したコンピュータ可読記憶媒体を含んでよい。

コンピュータ可読記憶媒体は、命令実行装置によって使用される命令を保持し、記憶することができる有形の装置とすることができる。コンピュータ可読記憶媒体は、一例として、電子記憶装置、磁気記憶装置、光学記憶装置、電磁記憶装置、半導体記憶装置またはこれらの適切な組み合わせであってよい。コンピュータ可読記憶媒体のより具体的な一例としては、ポータブルコンピュータディスケット、ハードディスク、ＲＡＭ、ＲＯＭ、ＥＰＲＯＭ（またはフラッシュメモリ）、ＳＲＡＭ、ＣＤ－ＲＯＭ、ＤＶＤ、メモリスティック、フロッピーディスク、パンチカードまたは溝内の隆起構造などに命令を記録した機械的に符号化された装置、およびこれらの適切な組み合せが挙げられる。本明細書で使用されるコンピュータ可読記憶装置は、電波もしくは他の自由に伝播する電磁波、導波管もしくは他の伝送媒体を介して伝播する電磁波（例えば、光ファイバケーブルを通過する光パルス）、またはワイヤを介して送信される電気信号のような、一過性の信号それ自体として解釈されるべきではない。

本明細書に記載のコンピュータ可読プログラム命令は、コンピュータ可読記憶媒体からそれぞれのコンピュータ装置／処理装置へダウンロード可能である。あるいは、ネットワーク（例えばインターネット、ＬＡＮ、ＷＡＮもしくはワイヤレスネットワークまたはこれらの組み合わせ）を介して、外部コンピュータまたは外部記憶装置へダウンロード可能である。ネットワークは、銅製伝送ケーブル、光伝送ファイバ、ワイヤレス伝送、ルータ、ファイアウォール、スイッチ、ゲートウェイコンピュータもしくはエッジサーバまたはこれらの組み合わせを備えることができる。各コンピュータ装置／処理装置内のネットワークアダプタカードまたはネットワークインタフェースは、ネットワークからコンピュータ可読プログラム命令を受信し、当該コンピュータ可読プログラム命令を、各々のコンピュータ装置／処理装置におけるコンピュータ可読記憶媒体に記憶するために転送する。

本発明の動作を実施するためのコンピュータ可読プログラム命令は、アセンブラ命令、命令セットアーキテクチャ（ＩＳＡ）命令、機械命令、機械依存命令、マイクロコード、ファームウェア命令、状態設定データ、集積回路用構成データ、または、スモールトークやＣ＋＋などのオブジェクト指向プログラミング言語、および「Ｃ」プログラミング言語や類似のプログラミング言語などの手続き型プログラミング言語を含む、１つ以上のプログラミング言語の任意の組み合わせで記述されたソースコードもしくはオブジェクトコードのいずれかとすることができる。コンピュータ可読プログラム命令は、スタンドアロン型ソフトウェアパッケージとして完全にユーザのコンピュータ上で、または部分的にユーザのコンピュータ上で実行可能である。あるいは、部分的にユーザのコンピュータ上でかつ部分的にリモートコンピュータ上で、または、完全にリモートコンピュータもしくはサーバ上で実行可能である。後者の場合、リモートコンピュータは、ＬＡＮやＷＡＮを含む任意の種類のネットワークを介してユーザのコンピュータに接続してもよいし、外部コンピュータに（例えば、インターネットサービスプロバイダを使用してインターネットを介して）接続してもよい。いくつかの実施形態において、例えばプログラマブル論理回路、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、プログラマブル論理アレイ（ＰＬＡ）を含む電子回路は、本発明の態様を実行する目的で当該電子回路をカスタマイズするために、コンピュータ可読プログラム命令の状態情報を利用することによって、コンピュータ可読プログラム命令を実行することができる。

本発明の実施形態は、本明細書において、本発明の実施形態に係る方法、装置（システム）、およびコンピュータプログラム製品のフローチャートもしくはブロック図またはその両方を参照して説明されている。フローチャートもしくはブロック図またはその両方における各ブロック、および、フローチャートもしくはブロック図またはその両方における複数のブロックの組み合わせは、コンピュータ可読プログラム命令によって実行可能である。

上記のコンピュータ可読プログラム命令は、機械を生産するために、汎用コンピュータ、専用コンピュータ、または他のプログラマブルデータ処理装置のプロセッサに提供してよい。これにより、かかるコンピュータまたは他のプログラマブルデータ処理装置のプロセッサを介して実行されるこれらの命令が、フローチャートもしくはブロック図またはその両方における１つ以上のブロックにて特定される機能／動作を実行するための手段を創出する。上記のコンピュータ可読プログラム命令はさらに、コンピュータ、プログラマブルデータ処理装置もしくは他の装置またはこれらの組み合わせに対して特定の態様で機能するよう命令可能なコンピュータ可読記憶媒体に記憶してよい。これにより、命令が記憶された当該コンピュータ可読記憶媒体は、フローチャートもしくはブロック図またはその両方における１つ以上のブロックにて特定される機能／動作の態様を実行するための命令を含む製品を構成する。

また、コンピュータ可読プログラム命令を、コンピュータ、他のプログラマブル装置、または他の装置にロードし、一連の動作ステップを当該コンピュータ、他のプログラマブル装置、または他の装置上で実行させることにより、コンピュータ実行プロセスを生成してもよい。これにより、当該コンピュータ、他のプログラマブル装置、または他の装置上で実行される命令が、フローチャートもしくはブロック図またはその両方における１つ以上のブロックにて特定される機能／動作を実行する。

本開示の図面におけるフローチャートおよびブロック図は、本発明の種々の実施形態に係るシステム、方法およびコンピュータプログラム製品の可能な実装形態のアーキテクチャ、機能性、および動作を示している。この点に関して、フローチャートまたはブロック図における各ブロックは、特定の論理機能を実行するための１つ以上の実行可能な命令を含む、命令のモジュール、セグメント、または部分を表すことができる。他の一部の実装形態において、ブロック内に示した機能は、各図に示す順序とは異なる順序で実行してもよい。例えば、連続して示される２つのブロックは、実際には、関係する機能に応じて、略同時に実行してもよいし、場合により逆順で実行してもよい。なお、ブロック図もしくはフローチャートまたはその両方における各ブロック、および、ブロック図もしくはフローチャートまたはその両方における複数のブロックの組み合わせは、特定の機能または動作を行う、または専用ハードウェアとコンピュータ命令との組み合わせを実行する専用ハードウェアベースのシステムによって、実行可能である。

本明細書で使用される用語は、特定の実施形態を説明することのみを目的としており、限定することを意図するものではない。本明細書で使用される場合、単数形「ａ」、「ａｎ」および「ｔｈｅ」は、文脈が明確に他のことを示さない限り、複数形も含むことを意図している。本明細書で使用される場合、「含む（comprises）」という用語もしくは「含む（comprising）」という用語またはその両方は、記載された特徴、整数、ステップ、操作、要素、もしくは構成要素またはその組み合わせの存在を指定するが、１つ以上の他の特徴、整数、ステップ、操作、要素、構成要素、もしくはそれらのグループまたはその組み合わせの存在または追加を排除するものではない。

さらに、「例示的」という用語は、本明細書では「例、実例、または例示として機能すること」を意味するために使用される。本明細書で「例示的」として説明される任意の実施形態または設計は、必ずしも他の実施形態または設計よりも好ましいまたは有利であると解釈されるべきではない。「少なくとも１つ」および「１つまたは複数」という用語は、１以上、すなわち１、２、３、４などの任意の整数を含むと理解される。「複数」という用語は、２以上、つまり２、３、４、５などの任意の整数を含むと理解される。「接続」という用語には、間接的な「接続」と直接的な「接続」の両方を含めることができる。

「約」、「実質的に」という用語、およびそれらと同等の単語は、出願時に利用可能な機器に基づく特定の量の測定に関連する誤差の程度を含むことを意図している。例えば、「約」、「実質的に」およびそれらと同等の単語は、特定の値の±８％、５％、または２％の範囲を含めることができる。

本発明は、限られた数の実施形態にのみ関連して詳細に説明されてきたが、本発明は、そのような開示された実施形態に限定されないことを容易に理解されたい。むしろ、本発明は、これまでに説明されていないが、本発明の精神および範囲に見合う任意の数の変形、変更、置換または同等の配置を組み込むように修正することができる。さらに、本発明の様々な実施形態が説明されてきたが、本発明の態様は、説明された実施形態の一部のみを含むことができることが理解されるであろう。したがって、本発明は、前述の説明によって限定されるとは見なされず、添付の請求の範囲によってのみ限定される。

Claims (20)

1. プロセッサを使用して、ローダライブラリにアクセスすることと、
   前記プロセッサを使用して、前記ローダライブラリのモックバージョンを含むモックライブラリを生成することと、
   前記プロセッサを使用して、前記ローダライブラリをコンテナ化することと、
   前記プロセッサを使用して、前記ローダライブラリをアンロードすることと、を含む、コンピュータ実装方法。
2. 前記ローダライブラリにアンロード信号を送信することをさらに含む、請求項１に記載のコンピュータ実装方法。
3. 前記プロセッサは、ダイナミックリンク（ｄｌ）インターセプターモジュールを含む、請求項１に記載のコンピュータ実装方法。
4. 前記プロセッサは、前記ｄｌインターセプターモジュールに通信可能に結合されたスタック処理モジュールをさらに含む、請求項３に記載のコンピュータ実装方法。
5. 前記プロセッサは、前記スタック処理モジュールに通信可能に結合されたマッピングスタブモジュールをさらに含む、請求項４に記載のコンピュータ実装方法。
6. 前記マッピングスタブモジュールは、コンテナ化プラットフォームの一部であり、
   前記モックライブラリは前記ｄｌインターセプターモジュールに格納される、請求項５に記載のコンピュータ実装方法。
7. ｄｌｃｌｏｓｅ命令は、前記ローダライブラリをアンロードするように前記プロセッサに指示するために使用される、請求項１に記載のコンピュータ実装方法。
8. プロセッサに通信可能に結合されたメモリを含むコンピュータシステムであって、前記プロセッサは、
   ローダライブラリにアクセスすることと、
   前記ローダライブラリのモックバージョンを含むモックライブラリを生成することと、
   前記ローダライブラリをコンテナ化することと、
   前記ローダライブラリをアンロードすることと、を含むプロセッサ動作を実行するように構成される、コンピュータシステム。
9. 前記プロセッサ動作は、前記ローダライブラリにアンロード信号を送信することをさらに含む、請求項８に記載のコンピュータシステム。
10. 前記プロセッサは、ダイナミックリンク（ｄｌ）インターセプターモジュールを含む、請求項８に記載のコンピュータシステム。
11. 前記プロセッサは、前記ｄｌインターセプターモジュールに通信可能に結合されたスタック処理モジュールをさらに含む、請求項１０に記載のコンピュータシステム。
12. 前記プロセッサは、前記スタック処理モジュールに通信可能に結合されたマッピングスタブモジュールをさらに含む、請求項１１に記載のコンピュータシステム。
13. 前記マッピングスタブモジュールは、コンテナ化プラットフォームの一部であり、
    前記モックライブラリは前記ｄｌインターセプターモジュールに格納される、請求項１２に記載のコンピュータシステム。
14. 前記プロセッサ動作は、前記ローダライブラリをアンロードするように前記プロセッサに指示するｄｌｃｌｏｓｅ命令を使用することを含む、請求項８に記載のコンピュータシステム。
15. ライブラリをアンロードするためのコンピュータプログラムであって、前記コンピュータプログラムは、プロセッサ上で実行されると、前記プロセッサに、
    ローダライブラリにアクセスすることと、
    前記ローダライブラリのモックバージョンを含むモックライブラリを生成することと、
    前記ローダライブラリをコンテナ化することと、
    前記ローダライブラリをアンロードすることと、を実行させる、コンピュータプログラム。
16. 前記プロセッサに、前記ローダライブラリにアンロード信号を送信することをさらに実行させる、請求項１５に記載のコンピュータプログラム。
17. 前記プロセッサは、ダイナミックリンク（ｄｌ）インターセプターモジュールを含む、請求項１５に記載のコンピュータプログラム。
18. 前記プロセッサは、前記ｄｌインターセプターモジュールに通信可能に結合されたスタック処理モジュールをさらに含む、請求項１７に記載のコンピュータプログラム。
19. 前記プロセッサは、前記スタック処理モジュールに通信可能に結合されたマッピングスタブモジュールをさらに含み、
    前記モックライブラリは前記ｄｌインターセプターモジュールに格納される、請求項１８に記載のコンピュータプログラム。
20. ｄｌｃｌｏｓｅ命令は、前記ローダライブラリをアンロードするように前記プロセッサに指示するために使用される、請求項１５に記載のコンピュータプログラム。