JP2023046312A - コンピュータ実装方法、コンピュータシステムおよびコンピュータプログラム製品(共有ライブラリをアンロードする際にランタイムリソースをクリーンアップするためにコンテナを使用すること) - Google Patents
コンピュータ実装方法、コンピュータシステムおよびコンピュータプログラム製品(共有ライブラリをアンロードする際にランタイムリソースをクリーンアップするためにコンテナを使用すること) Download PDFInfo
- Publication number
- JP2023046312A JP2023046312A JP2022150019A JP2022150019A JP2023046312A JP 2023046312 A JP2023046312 A JP 2023046312A JP 2022150019 A JP2022150019 A JP 2022150019A JP 2022150019 A JP2022150019 A JP 2022150019A JP 2023046312 A JP2023046312 A JP 2023046312A
- Authority
- JP
- Japan
- Prior art keywords
- library
- computer
- processor
- module
- loader
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/30—Creation or generation of source code
- G06F8/36—Software reuse
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/445—Program loading or initiating
- G06F9/44521—Dynamic linking or loading; Link editing at or after load time, e.g. Java class loading
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/445—Program loading or initiating
- G06F9/44557—Code layout in executable memory
- G06F9/44563—Sharing
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
- G06F9/45533—Hypervisors; Virtual machine monitors
- G06F9/45558—Hypervisor-specific management and integration aspects
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- General Engineering & Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Stored Programmes (AREA)
Abstract
【課題】共有ライブラリをアンロードする際にランタイムリソースをクリーンアップするためにコンテナを使用するコンピュータ実装方法、コンピュータシステムおよびコンピュータプログラム製品を提供する。【解決手段】本発明の実施形態は、プロセッサを使用して、ローダライブラリにアクセスすることと、プロセッサを使用して、ローダライブラリのモックバージョンを含むモックライブラリを生成することと、プロセッサを使用して、ローダライブラリをコンテナ化することと、プロセッサを使用して、ローダライブラリをアンロードすることと、を含むコンピュータ実装方法を含む。【選択図】図1
Description
本発明は、一般に、プログラマブルコンピュータシステムに関するものである。より具体的には、本発明は、共有ライブラリをアンロードする際にランタイムリソースをクリーンアップするためにコンテナを利用し、それによってセグメンテーションエラーを回避するコンピュータシステム、コンピュータ実装方法、およびコンピュータプログラム製品に関する。
マイクロサービスとは、ソフトウェアアーキテクチャの一種で、ソフトウェアアプリケーションの機能をより小さなフラグメントに分割し、アプリケーションの耐障害性と拡張性を高めるものである。より小さなフラグメントは、「サービス」と呼ばれる。各サービスは、アプリケーションの単一機能のみに焦点を当て、他のサービスから分離され、それぞれが独立しているという点で、モジュール化されている。モジュール化により、開発チームはチーム間の複雑な設計関連のオーケストレーションを必要とせず、異なるサービスに別々に取り組むことができる。
異なるマイクロサービスは、APIまたはウェブサービスを通じて互いに通信し、アプリケーションの全体的な機能を実行することができる。例えば、マイクロサービスは、リモートプロシージャコール(RPC)プロトコルを使用して、互いに通信し、他のソフトウェアアプリケーションと通信することができる。RPCは、あるプログラムが、ネットワークの詳細を理解することなく、ネットワーク上の別のコンピュータにあるプログラムからサービスを要求するために使用できるプロトコルである。RPCプロトコルは、クライアントサーバモデルを使用している。要求するプログラムはクライアントであり、サービスを提供するプログラムはサーバである。
アプリケーションプログラムは、ライブラリを利用することで、開発と実行の両面で効率化を図っている。ライブラリとは、コンピュータプログラムによって使用される不揮発性リソースの集合体である。ライブラリは、ソフトウェア開発によく利用される。ライブラリには、設定データ、ドキュメント、ヘルプデータ、メッセージテンプレート、あらかじめ書かれたコード、あらかじめ書かれたサブルーチンなどを含めることができる。より高度なプログラムを書きたいプログラマは、システムコールを何度も実装する代わりに、ライブラリを使ってシステムコールを作ることができる。ライブラリのコードは、互いに関係のない複数のプログラムから利用できるように構成されているが、あるプログラムの一部であるコードは、その1つのプログラムの中でのみ利用できるように構成されている。ライブラリは、独立したプログラムやサブプログラムで再利用できるように構成されており、ユーザはライブラリの内部の詳細を知る必要はなく、インタフェースだけを知っていればよい。ライブラリは、標準化されたプログラム要素の再利用を可能にする。プログラムがライブラリを呼び出すと、そのライブラリに実装されている動作を、自分自身で実装することなく得ることができる。ライブラリは、モジュール方式でのコードの共有を促進し、コードの配布を容易にする。
ライブラリによって実装される動作は、異なるプログラムのライフサイクルの段階で呼び出し、プログラムに接続することができる。ライブラリのコードが、呼び出しプログラムの構築中にアクセスされる場合、そのライブラリは静的ライブラリと呼ばれる。一方、呼び出しプログラムの実行ファイルを構築し、それをライブラリの実装とは別に配布する方法もある。ライブラリの動作は、実行ファイルが呼び出されて実行された後、実行を開始するプロセスの一部として、あるいは実行の途中で接続される。この場合、ライブラリはダイナミックライブラリ(ランタイムでロードされる)と呼ばれる。ダイナミックライブラリは、リンカによるプログラムの実行準備の際にロードしてリンクすることができる。また、実行の途中で、アプリケーションは明示的にモジュールのロードを要求することができる。
共有ライブラリをアンロードする際にランタイムリソースをクリーンアップするためにコンテナを使用するコンピュータ実装方法、コンピュータシステムおよびコンピュータプログラム製品を提供する。
本発明の実施形態は、プロセッサを使用して、ローダライブラリにアクセスすることと、プロセッサを使用して、ローダライブラリのモックバージョンを含むモックライブラリを生成することと、プロセッサを使用して、ローダライブラリをコンテナ化することと、プロセッサを使用して、ローダライブラリをアンロードすることと、を含むコンピュータ実装方法を含む。
本発明の実施形態は、上述したコンピュータ実装方法と実質的に同じ特徴を有するためのコンピュータシステムおよびコンピュータプログラム製品も提供する。
追加の特徴および利点は、本発明の技術によって実現される。本発明の他の実施形態および態様は、本明細書で詳細に説明され、請求された発明の一部とみなされる。利点および特徴を有する本発明のより良い理解のために、本明細書および図面を参照されたい。
本発明とみなされる主題は、本明細書の末尾にある特許請求の範囲に特に指摘され、明確に請求されている。本発明の上記および他の特徴、および利点は、添付の図面と組み合わせて取られる以下の詳細な説明から明らかである。
簡潔さのために、本発明の態様の製造および使用に関連する従来技術は、本明細書において詳細に説明されてもよいし、されなくてもよい。特に、本明細書に記載された様々な技術的特徴を実装するためのコンピューティングシステムおよび特定のコンピュータプログラムの様々な態様は既知である。したがって、簡潔さのために、多くの従来の実装の詳細は、本明細書で簡単に言及されるだけであるか、または周知のシステムもしくはプロセスの詳細またはその両方を提供することなく完全に省略される。
本明細書で説明するシステムの機能ユニットの多くは、モジュールと示されている。本発明の実施形態は、多種多様なモジュール実装に適用される。例えば、モジュールは、カスタムVLSI回路またはゲートアレイ、論理チップ、トランジスタ、または他のディスクリートコンポーネントなどの市販の半導体を含むハードウェア回路として実装することができる。また、モジュールは、フィールドプログラマブルゲートアレイ、プログラマブルアレイロジック、プログラマブルロジックデバイスなどのプログラマブルハードウェアデバイスに実装することができる。また、モジュールは、様々な種類のプロセッサによる実行のためにソフトウェアで実装することができる。実行可能コードの特定されたモジュールは、例えば、オブジェクト、手順、または関数として編成することができるコンピュータ命令の1つまたは複数の物理的または論理的ブロックを含むことができる。しかし、特定されたモジュールの実行可能コードは、物理的に一緒に配置される必要はなく、異なる場所に格納された異種の命令を含むことができ、それらが論理的に結合されると、モジュールとして機能し、モジュールのための述べられた目的を達成する。
本明細書に図示されたシステムの様々な構成要素、モジュール、サブ機能などは、図示及び説明を容易にするために別々に描かれている。本発明の実施形態において、様々な構成要素、モジュール、サブ機能などによって実行される動作は、特に断らない限り、本明細書で説明する本発明の様々な実施形態の範囲から逸脱することなく、図示とは異なる分布にすることができる。
便宜上、本明細書で説明する技術的な機能もしくは動作またはその両方の一部は、非公式な表現を用いて伝達される。例えば、キャッシュメモリに格納されたデータを有するプロセッサは、プロセッサがそのデータを「知っている」と表現することができる。同様に、ユーザがプロセッサにロードデータコマンドを送信することは、ユーザがプロセッサにデータをロードするように「伝える」ことと表現することができる。この詳細な説明におけるそのような非公式な表現は、その非公式な表現に対応するより正式で技術的な説明を網羅するように読まれるべきであり、関連する技術の当業者は、その非公式な表現が網羅するように理解することが理解される。
ここで、本発明の態様により具体的に関連する技術の概要に目を向けると、本明細書で既に述べたように、マイクロサービスは、ソフトウェアアプリケーションの機能をより小さなフラグメントに分割して、アプリケーションの耐障害性と拡張性を高めるソフトウェアアーキテクチャの一種である。より小さなフラグメントは、「サービス」と呼ばれる。各サービスは、アプリケーションの単一機能のみに焦点を当て、他のサービスから分離され、それぞれが独立しているという点で、モジュール化されている。モジュール化によって、開発チームはチーム間の複雑な設計関連のオーケストレーションを必要とすることなく、異なるサービスに別々に取り組むことができる。
異なるマイクロサービスは、APIまたはウェブサービスを通じて互いに通信し、アプリケーションの全体的な機能を実行することができる。例えば、マイクロサービスは、リモートプロシージャコール(RPC)プロトコルを使用して、互いに通信し、他のソフトウェアアプリケーションと通信することができる。RPCは、あるプログラムが、ネットワークの詳細を理解することなく、ネットワーク上の別のコンピュータにあるプログラムからサービスを要求するために使用できるプロトコルである。RPCプロトコルは、クライアントサーバモデルを使用している。要求するプログラムはクライアントであり、サービスを提供するプログラムはサーバである。
アプリケーションプログラムは、ライブラリを利用することで、開発と実行の両面で効率化を図っている。ライブラリとは、コンピュータプログラムによって使用される不揮発性リソースの集合体である。ライブラリは、ソフトウェア開発によく利用される。ライブラリには、設定データ、ドキュメント、ヘルプデータ、メッセージテンプレート、あらかじめ書かれたコード、あらかじめ書かれたサブルーチンなどを含めることができる。より高度なプログラムを書きたいプログラマは、システムコールを何度も実装する代わりに、ライブラリを使ってシステムコールを作ることができる。ライブラリのコードは、互いに関係のない複数のプログラムから利用できるように構成されているが、あるプログラムの一部であるコードは、その1つのプログラムの中でのみ利用できるように構成されている。ライブラリは、独立したプログラムやサブプログラムで再利用できるように構成されており、ユーザはライブラリの内部の詳細を知る必要はなく、インタフェースだけを知っていればよい。ライブラリは、標準化されたプログラム要素の再利用を可能にする。プログラムがライブラリを呼び出すと、そのライブラリに実装されている動作を、自分自身で実装することなく得ることができる。ライブラリは、モジュール方式でのコードの共有を促進し、コードの配布を容易にする。
ライブラリによって実装される動作は、異なるプログラムのライフサイクルの段階で呼び出しプログラムに接続することができる。ライブラリのコードが、呼び出しプログラムの構築中にアクセスされる場合、そのライブラリは静的ライブラリと呼ばれる。一方、呼び出しプログラムの実行ファイルを構築し、それをライブラリの実装とは別に配布する方法もある。ライブラリの動作は、実行ファイルが呼び出されて実行された後、実行を開始するプロセスの一部として、あるいは実行の途中で接続される。この場合、ライブラリはダイナミックライブラリ(ランタイムでロードされる)と呼ばれる。ダイナミックライブラリは、リンカによるプログラムの実行準備の際にロードしてリンクすることができる。また、実行の途中で、アプリケーションは明示的にモジュールのロードを要求することができる。
ダイナミックローディングとは、コンピュータプログラムが実行時にライブラリ(または他のバイナリ)をメモリにロードし、ライブラリに含まれる関数や変数のアドレスを取得し、それらの関数を実行、または変数にアクセスし、ライブラリをメモリからアンロードできるメカニズムである。gRPC(グーグル(登録商標)リモートプロシージャコール)は最新のオープンソース高性能RPCフレームワークであり、あらゆる環境で実行することができる。いくつかのRPCフレームワーク(例えばgRPC)は「クロスプロセス呼び出し」をサポートしておらず、それに応じてgRPCライブラリをアンロードすることができない。より具体的には、そのようなRPCフレームワークでは、共有オブジェクトをアンロードする際にセグメンテーション違反が発生する。
ここで、本発明の態様の概要に目を向けると、本発明の実施形態は、既知のRPCフレームワークが共有ライブラリをアンロードする際に、コンテナを利用してランタイムリソースをクリーンアップすることによって、共有ライブラリをアンロードしようとする際に発生するセグメンテーション違反を回避するコンピュータシステム、コンピュータ実装方法、及びコンピュータプログラム製品を提供する。本発明の実施形態に従った革新的なコンピュータ実装方法は、共有ライブラリをアンロードし、実行環境を安全にクリーンアップするために提供される。本発明の実施形態は、コンテナ化されたlibld.so(すなわち、コンテナ化されたダイナミックリンカ/ローダ)とターゲット共有ライブラリ(すなわち、アンロードされる共有ライブラリ)を使用して、ターゲット共有ライブラリをアンロードする際に安全に破壊できるような言語環境にする。共有ライブラリの接尾辞は常に「.so」である。プログラム命令/関数「libtarget_go.so」と「libld.so」は、共有ライブラリである。ただし、「libld.so」(またはld.so)はダイナミックリンカ/ローダであり、他の共有ライブラリをロード/アンロードするためのdlopen()/dlsym()/dlcose()を提供するという点で「libld.so」は特殊な共有ライブラリである。
ダイナミックリンク(DL)インターセプターモジュールは、コンテナの作成/破壊、ホストからコンテナへのデータおよび関数の要求の配信など、コンテナのライフサイクルを管理する。また、セッションのライフサイクルも管理する。セッションは、dl関数が来たときにコンテナと対話するために使用される。スタック処理モジュールは、スタックとプロトコルバッファの間の変換を行う。プロトコルバッファは、構造化されたデータをシリアライズするための、言語やプラットフォームに依存しない拡張可能なメカニズムである。ユーザがデータの構造化を一度定義すれば、専用に生成されたソースコードを使用して、様々な言語を用い様々なデータストリームとの間で構造化データの書き込みや読み出しを容易に行うことができる。DLインターセプターモジュールとマッピングスタブモジュールは、この関数を用いて、互いにデータの変換をし、配信する。マッピングスタブモジュールは、LDインターセプターモジュールが作成したコンテナ内のlibdl.soを利用して、ターゲット共有ライブラリをメモリアドレス空間にロードし、セッションIDとハンドラ間のマップを記録する。そして、dl関数が来たときに、そのデータがターゲットライブラリにルーティングされる。dlclose要求が来たら、DLインターセプターモジュールはコンテナを破壊し、セッションIDを無効化する。したがって、本発明の実施形態では、共有ライブラリをコンテナ化することにより、セグメンテーション違反を発生させることなく共有ライブラリをアンロードすることができる。セグメンテーションはコンテナ内部で起こるかもしれないが、本発明の実施形態によれば、アンロードする際にコンテナ全体が破壊される。したがって、本発明の態様を用いると、コンテナの外側のエンドユーザは、「セグメンテーション違反」の障害を見ることがない。
ここで、本発明の側面のより詳細な説明に移ると、図1は本発明の実施形態における、システム100を示している。システム100を説明する前に、本発明の態様に関連するいくつかのオープンソースの概念について説明する。プログラム「libld.so」および「ld-linux.so」は、プログラムが必要とする共有オブジェクト(共有ライブラリ)を見つけてロードし、プログラムの実行を準備し、その後、プログラムを実行する。したがって、「libld.so」はダイナミックリンカ/ローダである。他の共有ライブラリをロード/アンロードするためのdlopen()/dlsym()/dlcose()を提供する。また、プロトコルバッファは、構造化データをシリアライズするための言語やプラットフォームに依存しない拡張可能なメカニズムである。ユーザがデータの構造化を一度定義すれば、専用に生成されたソースコードを使用して、様々な言語を用いて、様々なデータストリームとの間で構造化データの書き込みや読み出しを容易に行うことができる。
再び図1を参照すると、システム100は、図示のように構成され配置されたスタック処理モジュール134を介してコンテナ化プラットフォーム150と通信している外部エンティティ110を含む。エンティティ110は、ソフトウェア命令(またはコンピュータコード)112のセットと、ダイナミックリンク(DL)インターセプターモジュール114を含む。ソフトウェア命令112は、dlclose( )命令を使用するように構成されている。より具体的には、ソフトウェア命令112は、プログラム/アプリケーションであり、共有ライブラリをロードする。プログラム「libtarget_go.so」は、共有ライブラリの名称の一例である。任意の共有ライブラリであってもよい。コンピュータコード112のプログラム命令dlopen()/dlsym()/dlclose()は、共有ライブラリをロードするためにlibld.soが提供する3つの関数である。コンピュータコード112は、モック化されたダイナミックリンカ/ローダ(すなわち、libld.so)によって提供されるモックされたdlopen()/dlsym()/dlclose()を利用して共有ライブラリlibtarget_go.soをロード/アンロードする処理を示している。
本発明の態様の利益がなければ、コンピュータコード112は「libld.so」に対話したり、呼び出したりするだろう。しかし、「libld.so」は、共有ライブラリをアンロードする際に、環境全体をクリーンアップすることができない。時々、「libld.so」はアンロード中にエラー、例えば、「セグメンテーション違反」エラーを起こし、コンピュータコード112に影響を与える。本発明の態様に従って、DLインターセプターモジュール114は、コンピュータコード112が本物の「libld.so」の代わりにモック化されたlibld.so116に対話する(または呼び出す)ことができるように、新しいモック化されたlibld.so116を導入する。DLインターセプターモジュール114は、コンテナライフサイクルを管理し、また、コンピュータコード112からコンテナ化プラットフォーム150にデータおよび関数要求を配信するように構成される。また、DLインターセプターモジュール114は、セッションライフサイクルを管理する。それは、内部に共有ライブラリを有するコンテナを破壊することによって、共有ライブラリをアンロードする。したがって、コンテナ内部の予期せぬエラーは、ホストにあるアプリケーション/プログラムには影響がない。モック化されたlibld.so116は、モック化された「libld.so」である。モック化されたlibld.so116は、コンピュータコード112から要求を受け取り、本物の「libld.so」に処理され、配信されることになる。エンドユーザがdl関数(すなわち、dlopen/dlsym/dlclose)を呼び出すとき、実際にはモック化されたlibdl.so116内のモック化されたdl関数を呼び出すことになる。
DLインターセプターモジュール114はまた、図示のように構成され配置されたセッションライフサイクル管理モジュール118とコンテナ処理モジュール120を含む。セッションライフサイクル管理モジュール118は、1つのプログラム/アプリケーションが一意のセッション構造に対応するセッション構造を作成する。セッション構造は「セッションID」を含み、これは「ターゲット共有ライブラリ名」である。カスタマイズされたコンテナが起動すると、コンテナ内のダイナミックリンカ/ローダ(libld.so)により「ターゲット共有ライブラリ名」がロードされることになる。コンテナ処理モジュール120では、DLは「ダイナミックリンク」を意味し、「ダイナミックリンクライブラリ」は「共有ライブラリ」と同じ意味である。従って、「DL名」は、共有ライブラリ名であるダイナミックリンクライブラリ名である。このように、コンテナ処理モジュール120は、コンテナを管理するための機能を提供する。例えば、このモジュール120は、Init()関数とDestroy()関数を提供する。Init(セッションID、DL名)は、コンテナを作成し、ダイナミックリンカ/ローダ(libld.so)がどの共有ライブラリをコンテナ内にロードする必要があるかを知るために、DL名(共有ライブラリ名)をコンテナに渡す。Destroy( )は、作成されたコンテナを破壊する。
スタッキング処理モジュール132は、解析と遷移モジュール134を含み、モジュール132は、コールスタック136とプロトコル(proto)バッファ138に通信可能に結合される。一般に、コールスタックは、コンピュータプログラムのアクティブなサブルーチンに関する情報を格納するスタックデータ構造である。コールスタックのメンテナンスは、ほとんどのソフトウェアが適切に機能するために重要であるが、詳細は通常、高レベルのプログラミング言語では隠され、自動化されている。多くのコンピュータ命令セットは、スタックを操作するための特別な命令を提供する。コールスタックは、いくつかの関連した目的で使用されるが、1つを持つ主な理由は、各アクティブサブルーチンが実行を終了するときに制御を返すべきポイントを追跡することである。アクティブサブルーチンとは、呼び出されたが、まだ実行が完了していないサブルーチンのことで、その後、制御は呼び出し元のポイントに戻されるべきものである。このようなサブルーチンの起動は、任意のレベルまでネスト化することができ(特殊なケースとして再帰的)、そのためスタック構造である。
モジュール132の解析と遷移モジュール134は、スタック処理モジュール132の主な作業の性能を受け持つ。「スタック」形式のコンピュータコードのパラメータは転送が困難であるが、プロトコルバッファ形式のパラメータは転送が容易である。従って、解析と遷移モジュール134は、変換を行うために、Pack( )とUnPack( )という2つのパラメータ操作メソッドを提供する。スタック処理モジュール132は、実行中のコンピュータコードのコールスタック136からパラメータを読み出し、そのパラメータをプロトコルバッファ形式(プロトコルバッファ138)に変換する。また、プロトコルバッファ形式からパラメータを変換し、その後、コンピュータコードのコールスタック136にパラメータを書き戻すこともできる。前述のように、解析と遷移モジュール134を通じて、スタック処理モジュール132は、2つのパラメータ操作メソッド、すなわちPack( )及びUnPack( )を提供する。Pack( )メソッドは、実行中のコンピュータコードのコールスタック136からパラメータを読み出し、そのパラメータをプロトンバッファ形式(プロトコルバッファ138)に変換する。UnPack( )メソッドは、プロトコルバッファ形式からパラメータを変換し、その後、コンピュータコードのコールスタック136にパラメータを書き込む。
コンテナ化プラットフォーム150は、マッピングスタブモジュール152と、コマンド/関数のlibld.soセットと、コマンド/関数のlibtarget_go.soセットとを含む。一般に、コンテナ化プラットフォーム150は、コンテナ化アプリケーションの構築、デプロイ、および管理のために構成および配置されたオープンソースのコンテナ化プラットフォームであり得る。オープンソースのコンテナ化プラットフォームは、開発者がアプリケーションをコンテナ、すなわちアプリケーションのソースコードと、そのコードを任意の環境で実行するために必要なオペレーティングシステム(OS)ライブラリおよび依存関係を組み合わせた標準化実行可能コンポーネントに、パッケージ化することを可能にする。コンテナは、分散アプリケーションの配信を簡素化し、企業がクラウドネイティブ開発やハイブリッドマルチクラウド環境へ移行するにつれて、人気が増加している。オープンソースのコンテナ化プラットフォームは、基本的に開発者がシンプルなコマンドを使用してコンテナを構築、デプロイ、実行、更新、停止し、単一のAPIを通じて省力化を自動化できるようにするツールキットである。コンテナは、Linuxカーネルに組み込まれたプロセス分離と仮想化機能によって実現されている。これらの機能、すなわちプロセス間でリソースを割り当てるための制御グループ(Cgroups)や、システムの他のリソースや領域への処理のアクセスや可視性を制限するための名前空間などは、ハイパーバイザーによって複数の仮想マシン(VM)が単一のハードウェアサーバのCPU、メモリ、その他のリソースを共有できるのとほぼ同様に、複数のアプリケーションコンポーネントで単一のホストオペレーティングシステムのインスタンスのリソースを共有することを可能にするものである。その結果、コンテナ技術は、アプリケーションの分離、費用対効果の高いスケーラビリティ、ディスポーザビリティを含む、VMのすべての機能と利点を提供する。
コンテナ化プラットフォームでは、実行可能なアプリケーションのソースコードと、アプリケーションコードがコンテナとして動作するために必要なすべてのツール、ライブラリ、および依存関係を含む、いわゆる「イメージ」を使用する。イメージが実行されると、そのイメージはコンテナの1つのインスタンス(または複数のインスタンス)になる。ゼロからイメージを構築することも可能であるが、ほとんどの開発者は一般的なリポジトリからイメージを取得する。1つのベースイメージから複数のイメージを作成することができ、それらのイメージはスタックの共通性を共有することになる。イメージはレイヤで構成されており、各レイヤはイメージのバージョンに対応している。開発者がイメージに変更を加えるたびに、新しいトップレイヤが作成され、このトップレイヤが以前のトップレイヤを現在のバージョンのイメージとして置き換える。以前のレイヤは、ロールバックや他のプロジェクトで再利用するために保存される。イメージからコンテナを作成するたびに、コンテナレイヤと呼ばれる別の新しいレイヤが作成される。コンテナに加えられた変更、すなわちファイルの追加や削除などは、コンテナレイヤにのみ保存され、コンテナの実行中にのみ存在する。このようにイメージを繰り返し作成する処理によって、1つのベースイメージから複数のライブコンテナインスタンスを実行でき、その際、共通のスタックを活用できるため、全体的な効率が向上する。コンテナとは、イメージのライブ実行インスタンスである。イメージは読み取り専用のファイルであるが、コンテナはライブで、一時的な、実行可能なコンテンツである。ユーザはコンテナと対話し、管理者はdockerコマンドを使用してコンテナの設定や状態を調整することができる。
より具体的にコンテナ化プラットフォーム150を参照すると、プラットフォーム150は、マッピングスタブモジュール152、ダイナミックリンカ/ローダ(すなわち、libdl.so)、およびlibtarget_go.soなどの他の共有ライブラリを含むコンテナである。システム100上のコンピュータコードによってdlclose( )が呼び出されると、dlclose( )はDLインターセプターモジュール114を利用して、コンテナ全体を破壊する。したがって、コンテナ内のすべてのものが破壊される。コンテナ内部で発生した障害(例えば、セグメンテーション違反)は、システム100の言語環境に影響を与えない。
マッピングスタブモジュール152は、コンテナ化プラットフォーム150のメモリアドレス空間へ、本物のlibld.soをロードする。そして、libld.soは、コンテナ化プラットフォーム150のメモリアドレス空間に、libtarget_go.soをロードする。そして、セッションIDとハンドラの間のマップを記録する。dl関数が来たときに、データとdlsym()要求をターゲットライブラリにルーティングする。「libld.so関数適用」モジュールは、ホストからプロトコルバッファデータを受信する。マッピングスタブモジュール152は、dlsym()要求が来たときに、ルーティングすべきターゲット先がわかるように、セッションIDとハンドラのマップを保持している。
「libtarget.go.so」は、「func1( )」、「func2( )」、「func3( )」といった関数のシリアルを含む共有ライブラリである。図1は、「func1」要求がシステム100でどのように処理されるかを示している。コンピュータコード112が「libtarget_go.so」内の「func1( )」を呼び出したいとき、DLインターセプターモジュール114内のモック化されたdlopen( )を利用して、コンテナ化プラットフォーム150を作成する。モック化されたdlsym(p, "func1")を利用して、コンテナ化プラットフォーム150にリクエストを送信する。モック化されたdlclose( )を利用して、コンテナ化プラットフォーム150を破壊する。
システム100の動作は、図2、3、および4に示されており、各図2、3、および4に示される様々な動作ステップを参照して説明されることになる。図2および3は、図1に示したシステム100の構成要素の一部の追加的な詳細を提供するので、図2、3、および4に示した方法論を説明する前に、これらの追加的な詳細を紹介する。図2に示すように、モック化されたlibld.so116の内部には、「モック化されたdlsym」、「モック化されたdlclose」、および「モック化されたdlopen」が含まれる。既存の「libld.so」には、「dlsym( )」、「dlclose( )」、「dlopen( )」が含まれる。図2~4に描かれた方法論を用いることにより、コンピュータコード112が「dlsym( )」、「dlclose( )」、「dlopen( )」を呼び出すとき、実際には、モック化されたlibld.so116の「モック化されたdlsym」、「モック化されたdlclose」、「モック化されたdlopen」が呼び出されることになる。モック化されたlibld.so116は、コンテナ化プラットフォーム150内の本物のlibld.soに関数要求をルーティングする。
図2に示すように、セッションライフサイクル管理118の内部には、「セッション」、「ID」、「DL名」、「コンテナオプション」、「パラメータオプション」などがある。コンピュータコードがdlopen関数を呼び出すとき、実際にはlibdl.so共有ライブラリ内のモック化されたdlopenを呼び出している。モック化されたdlopenは、セッションライフサイクル管理モジュール118と対話する。セッションライフサイクル管理モジュール118は、セッション構造を作成する。各コンピュータコード112は、一意のセッション構造を作成し、このセッション構造は、一意のセッションIDを含む。「セッションID」は、セッションアイデンティティである。「DL名」は、ダイナミックリンクライブラリ名であり、共有ライブラリ名である。「コンテナオプション」は、Init( )Destroy( )およびInvoke( )関数に対する動作を含む。Init( )はコンテナを初期化する。Destroy( )はコンテナを破壊する。Invoke( )はコンテナ内でlibtarget_go.soの実関数(関数1、2、3)を呼び出す。「パラメータオプション」は、Pack( )およびUnPack( )メソッドを指す。Pack( )メソッドは、実行中のコンピュータコード112のコールスタック136からパラメータを読み出し、そのパラメータを「プロトコルバッファ」の形式に変換する。Unpack( )メソッドは、パラメータを「プロトコルバッファ」の形式から変換した後、コンピュータコード112のコールスタック136にパラメータを書き込む。
図2に示すように、コンテナ処理モジュール120の内部には、「コンテナ動作」、「Init」、「Destroy」、及び「Invoke shared library」がある。コンテナ処理モジュール120は、コンテナ化プラットフォーム150の初期化、コンテナ化プラットフォーム150の破壊、及びコンテナ化プラットフォーム150へのdlsym( )要求の配信を行うために、これらの動作を提供する。
図2に示すように、解析と遷移134と書かれたボックスの中には、「パラメータ動作」、 「Pack ( )」、「UnPack( )」がある。「パラメータオプション」は、Pack( )およびUnPack( )メソッドを指す。これは、変換のためにデータをパックし、データが到着したらアンパックすることを目的としている。
図3に示すように、コンテナ化プラットフォーム150の内部には、「libtarget_golang.so」がある。「libtarget_go.so」は、共有ライブラリの名称の一例である。任意の名称とすることができる。本発明の実施形態は、元の言語環境を一切汚染することなく、共有ライブラリ「libtarget_go.so」を完全にアンロードすることに着目したものである。
ここで、図2~4に示す方法論を参照すると、図2において、dlopenについては、S1において、エンドユーザがdlopen関数を呼び出すと、実際にはlibdl.so共有ライブラリ内の「モック化された」dlopenが呼び出される。S2では、モック化されたdlopenは、セッションライフサイクル管理モジュール118と対話する。セッションライフサイクル管理モジュール118は、セッションIDとしての新しいUUID、新しいDL名、ロードするターゲット共有ライブラリ、コンテナ処理モジュール120が提供する登録コンテナ動作、およびスタック処理モジュール132が提供する登録パラメータ動作を含むセッション構造を作成する。S3では、モック化されたdlopenは、init( )メソッドを利用して、新しいコンテナを作成する。
dlcloseについては、S4では、エンドユーザがdlclose関数を呼び出すと、実際にはlibdl.so共有ライブラリ内のモック化されたdlcloseが呼び出される。S5では、モック化されたdlcloseは、セッション構造のセッションIDを無効化する。S6では、destroy( )メソッドを利用してコンテナを破壊し、セッション構造を解放する。
dlsymについては、S7では、エンドユーザがdlsym関数を呼び出すと、実際にはlibdl.so共有ライブラリ内のモック化されたdlsymが呼び出される。S8では、モック化されたdlsymは、セッションライフサイクル管理モジュール118と対話する。S9では、セッションライフサイクル管理モジュール118は、S2でスタック処理モジュール132が登録したpack( )メソッドを利用し、スタック136からプロトコルバッファ138にパラメータを変換する。S10では、モック化されたdlsymは、S2においてコンテナ処理モジュール120により登録されたinvoke( )メソッドを利用して、前のステップのプロトコルバッファ138との呼び出しを行う。S11では、モック化されたdlsymは、結果とパラメータを取得した後、unpack( )メソッドを利用して、プロトコルバッファ138からスタック136へ変換を行う。
図3および図4は、追加の動作S1~S8を示す図である。なお、図3および図4におけるS1~S8の呼称は便宜上用いたものであり、図3および図4に示すS1~S8は、図2に示すS1~S8と異なることに留意されたい。図3に示すように、S1では、init( )メソッドがコンテナを作成し、ベースイメージとしてホストイメージを使用する。システムディレクトリ、特に、ライブラリディレクトリをコンテナに対してホスト上にマッピングし、マッピングスタブモジュール152を初期化する。マッピングスタブモジュール152は、libld.soをアドレス空間へロードする。S2では、セッションID、ターゲットライブラリ名、関数名を含むプロトコルバッファデータがコンテナに渡される。libld.soでは、アドレス空間へのターゲットライブラリのロードにDlopen( )を使用する。Dlopen( )はハンドラを返し、そのハンドラはdlsym( )とdlclose( )で使用される。S4では、セッションIDを前のステップで生成したハンドラにマッピングされる。S5では、destroy( )メソッドにより、S1で作成したコンテナを破壊する。
図4に示すように、S6において、invoke( )メソッドは、セッションID、関数名、関数パラメータを含むプロトコルバッファデータをマッピングスタブモジュール152に渡す。S7において、マッピングスタブモジュール152は、セッションIDによりハンドラを取得する。S8では、マッピングスタブモジュール152は、ハンドラ、関数名、および関数パラメータと共にlibld.soを利用することにより、ターゲット関数を呼び出す。S9では、libld.soが実関数を呼び出す。
従って、本発明の実施形態は、技術的な利点と効果を提供することが分かる。本発明の実施形態は、共有ライブラリをアンロードする際に、共有ライブラリの全てのリソースをクリーンアップすることができる。この変更はエンドユーザにとって透過的であり、コード変更はエンドユーザによって行われる必要がある。本発明の実施形態は、共有ライブラリまたはプログラミング言語の制限を有しない。モック化されたライブラリ(モック化されたlibld.so)コンテナは、コンテナの外側にある。libld.soはコンテナ内にあり、モック化されたlibld.soはコンテナ内のlibld.soに要求を配信する。libld.soはローダライブラリであり、モック化されたlibld.soはモック化されたローダライブラリである。
したがって、本発明の実施形態は、DLインターセプター、スタック処理、及びコンテナ化されたターゲット共有ライブラリを用いて、共有ライブラリをアンロードし、言語環境を安全にクリーンアップするように構成された新規のコンピュータ実装方法を提供する。DLインターセプターモジュールは、共有ライブラリのセッションライフサイクルおよびコンテナライフサイクルを管理し、dlopen要求が来たときにコンテナを作成し、dlclose要求が来たときにコンテナを破壊する。dlsymが来ると、ホストからコンテナへデータと関数の要求が転送される。ハンドラに関連付けられたセッションが生成され、破壊される。スタック処理モジュールは、スタックとプロトコルバッファ間の変換を行う。DLインターセプターモジュールとマッピングスタブモジュールは、この関数を利用して、相互にデータを変換し、配信する。マッピングスタブモジュールは、libdl.soを利用してターゲット共有ライブラリをメモリアドレス空間にロードし、セッションIDとハンドラ間のマップを記録する。DL関数が来たときに、データとdlsym要求をターゲットライブラリにルーティングする。
図5は、本明細書で説明する本発明の様々な実施形態のコンピュータベースの構成要素のいずれかを実装するために使用することができるコンピュータシステム500の例を示している。コンピュータシステム500は、本発明の態様に従って本明細書に記載されるコンテンツベースのセマンティックモニタリング動作の様々な態様を実行するように構成された例示的なコンピューティング装置(「コンピュータ」)502を含む。コンピュータ502に加えて、例示的なコンピュータシステム500は、コンピュータ502を追加のシステム(不図示)に接続するネットワーク514を含み、インターネット、イントラネット、もしくは無線通信ネットワークまたはこれらの組み合わせなどの1つまたは複数の広域ネットワーク(WAN)もしくはローカルエリアネットワーク(LAN)またはその両方を含むことが可能である。コンピュータ502及び追加のシステムは、例えば、それらの間でデータを通信するために、ネットワーク514を介して通信している。
例示的なコンピュータ502は、プロセッサコア504、メインメモリ(「メモリ」)510、および入力/出力コンポーネント512を含み、これらはバス503を介して通信可能である。プロセッサコア504は、キャッシュメモリ(「キャッシュ」)506および制御部508を含み、これらは、以下でより詳細に説明する分岐予測構造および関連する検索、ヒット、検出および更新ロジックを含む。キャッシュ506は、プロセッサ504からオンチップまたはオフチップである複数のキャッシュレベル(不図示)を含むことができる。メモリ510は、そこに格納された様々なデータ、例えば、命令、ソフトウェア、ルーチンなどを含むことができ、これらは、例えば、プロセッサ504による実行のために、制御部508によってキャッシュ506に転送または、キャッシュ506から転送されることができる。入力/出力コンポーネント512は、ディスプレイ、キーボード、モデム、ネットワークアダプタなど、コンピュータ502への、またはコンピュータ502からローカルもしくはリモートまたはその両方の入力/出力操作を容易にする1つまたは複数の構成要素(不図示)を含むことができる。
本開示は、クラウドコンピューティングに関する詳細な説明を含むが、本明細書に記載された教示の実装は、クラウドコンピューティング環境に限定されないことを理解されたい。むしろ、本発明の実施形態は、現在知られている又は後に開発される任意の他のタイプのコンピューティング環境と組み合わせて実施することが可能である。
クラウドコンピューティングは、設定可能なコンピューティングリソースの共有プール(例えばネットワーク、ネットワーク帯域幅、サーバ、処理、メモリ、記憶装置、アプリケーション、仮想マシンおよびサービス)へ、簡便かつオンデマンドのネットワークアクセスを可能にするためのサービス提供のモデルであり、最小限の管理労力または最小限のサービスプロバイダとのやり取りによって速やかに準備(provision)およびリリースできるものである。このクラウドモデルは、少なくとも5つの特性、少なくとも3つのサービスモデル、および少なくとも4つの展開モデルを含むことがある。
特性は以下の通りである。
オンデマンド・セルフサービス:クラウドの消費者は、サービスプロバイダとの人的な対話を必要することなく、必要に応じて自動的に、サーバ時間やネットワークストレージなどのコンピューティング能力を一方的に準備することができる。
ブロード・ネットワークアクセス:コンピューティング能力はネットワーク経由で利用可能であり、また、標準的なメカニズムを介してアクセスできる。それにより、異種のシンまたはシッククライアントプラットフォーム(例えば、携帯電話、ラップトップ、PDA)による利用が促進される。
リソースプーリング:プロバイダのコンピューティングリソースはプールされ、マルチテナントモデルを利用して複数の消費者に提供される。様々な物理リソースおよび仮想リソースが、需要に応じて動的に割り当ておよび再割り当てされる。一般に消費者は、提供されたリソースの正確な位置を管理または把握していないため、位置非依存(location independence)の感覚がある。ただし消費者は、より高い抽象レベル(例えば、国、州、データセンタ)では場所を特定可能な場合がある。
迅速な柔軟性(elasticity):コンピューティング能力は、迅速かつ柔軟に準備することができるため、場合によっては自動的に、直ちにスケールアウトし、また、速やかにリリースされて直ちにスケールインすることができる。消費者にとって、準備に利用可能なコンピューティング能力は無制限に見える場合が多く、任意の時間に任意の数量で購入することができる。
測定されるサービス:クラウドシステムは、サービスの種類(例えば、ストレージ、処理、帯域幅、アクティブユーザアカウント)に適したある程度の抽象化レベルでの測定機能を活用して、リソースの使用を自動的に制御し最適化する。リソース使用量を監視、制御、および報告して、利用されるサービスのプロバイダおよび消費者の両方に透明性を提供することができる。
サービスモデルは以下の通りである。
サービスとしてのソフトウェア(SaaS):消費者に提供される機能は、クラウドインフラストラクチャ上で動作するプロバイダのアプリケーションを利用できることである。当該そのアプリケーションは、ウェブブラウザ(例えばウェブメール)などのシンクライアントインタフェースを介して、各種のクライアント装置からアクセスできる。消費者は、ネットワーク、サーバ、オペレーティングシステム、ストレージや、個別のアプリケーション機能さえも含めて、基礎となるクラウドインフラストラクチャの管理や制御は行わない。ただし、ユーザ固有の限られたアプリケーション構成の設定はその限りではない。
サービスとしてのプラットフォーム(PaaS):消費者に提供される機能は、プロバイダによってサポートされるプログラム言語およびツールを用いて、消費者が作成または取得したアプリケーションを、クラウドインフラストラクチャに展開(deploy)することである。消費者は、ネットワーク、サーバ、オペレーティングシステム、ストレージを含む、基礎となるクラウドインフラストラクチャの管理や制御は行わないが、展開されたアプリケーションを制御でき、かつ場合によってはそのホスティング環境の構成も制御できる。
サービスとしてのインフラストラクチャ(IaaS):消費者に提供される機能は、オペレーティングシステムやアプリケーションを含む任意のソフトウェアを消費者が展開および実行可能な、プロセッサ、ストレージ、ネットワーク、および他の基本的なコンピューティングリソースを準備することである。消費者は、基礎となるクラウドインフラストラクチャの管理や制御は行わないが、オペレーティングシステム、ストレージ、および展開されたアプリケーションを制御でき、かつ場合によっては一部のネットワークコンポーネント(例えばホストファイアウォール)を部分的に制御できる。
展開モデルは以下の通りである。
プライベートクラウド:このクラウドインフラストラクチャは、特定の組織専用で運用される。このクラウドインフラストラクチャは、当該組織または第三者によって管理することができ、オンプレミスまたはオフプレミスで存在することができる。
コミュニティクラウド:このクラウドインフラストラクチャは、複数の組織によって共有され、共通の関心事(例えば、ミッション、セキュリティ要件、ポリシー、およびコンプライアンス)を持つ特定のコミュニティをサポートする。このクラウドインフラストラクチャは、当該組織または第三者によって管理することができ、オンプレミスまたはオフプレミスで存在することができる。
パブリッククラウド:このクラウドインフラストラクチャは、不特定多数の人々や大規模な業界団体に提供され、クラウドサービスを販売する組織によって所有される。
ハイブリッドクラウド:このクラウドインフラストラクチャは、2つ以上のクラウドモデル(プライベート、コミュニティまたはパブリック)を組み合わせたものとなる。それぞれのモデル固有の実体は保持するが、標準または個別の技術によってバインドされ、データとアプリケーションの可搬性(例えば、クラウド間の負荷分散のためのクラウドバースティング)を実現する。
クラウドコンピューティング環境は、ステートレス性(statelessness)、低結合性(low coupling)、モジュール性(modularity)および意味論的相互運用性(semantic interoperability)に重点を置いたサービス指向型環境である。クラウドコンピューティングの中核にあるのは、相互接続されたノードのネットワークを含むインフラストラクチャである。
ここで、図6に例示的なクラウドコンピューティング環境50を示す。図示するように、クラウドコンピューティング環境50は1つ以上のクラウドコンピューティングノード10を含む。これらに対して、クラウド消費者が使用するローカルコンピュータ装置(例えば、PDAもしくは携帯電話54A、デスクトップコンピュータ54B、ラップトップコンピュータ54C、もしくは自動車コンピュータシステム54Nまたはこれらの組み合わせなど)は通信を行うことができる。ノード10は互いに通信することができる。ノード10は、例えば、上述のプライベート、コミュニティ、パブリックもしくはハイブリッドクラウドまたはこれらの組み合わせなど、1つ以上のネットワークにおいて、物理的または仮想的にグループ化(不図示)することができる。これにより、クラウドコンピューティング環境50は、サービスとしてのインフラストラクチャ、プラットフォームもしくはソフトウェアまたはこれらの組み合わせを提供することができ、クラウド消費者はこれらについて、ローカルコンピュータ装置上にリソースを維持する必要がない。なお、図6に示すコンピュータ装置54A~Nの種類は例示に過ぎず、コンピューティングノード10およびクラウドコンピューティング環境50は、任意の種類のネットワークもしくはネットワークアドレス指定可能接続(例えば、ウェブブラウザの使用)またはその両方を介して、任意の種類の電子装置と通信可能であることを理解されたい。
ここで、クラウドコンピューティング環境50(図6)によって提供される機能的抽象化レイヤのセットを図7に示す。なお、図7に示すコンポーネント、レイヤおよび機能は例示に過ぎず、本発明の実施形態はこれらに限定されないことをあらかじめ理解されたい。図示するように、以下のレイヤおよび対応する機能が提供される。
ハードウェアおよびソフトウェアレイヤ60は、ハードウェアコンポーネントおよびソフトウェアコンポーネントを含む。ハードウェアコンポーネントの例には、メインフレーム61、縮小命令セットコンピュータ(RISC)アーキテクチャベースのサーバ62、サーバ63、ブレードサーバ64、記憶装置65、ならびにネットワークおよびネットワークコンポーネント66が含まれる。いくつかの実施形態において、ソフトウェアコンポーネントは、ネットワークアプリケーションサーバソフトウェア67およびデータベースソフトウェア68を含む。
仮想化レイヤ70は、抽象化レイヤを提供する。当該レイヤから、例えば以下の仮想エンティティを提供することができる:仮想サーバ71、仮想ストレージ72、仮想プライベートネットワークを含む仮想ネットワーク73、仮想アプリケーションおよびオペレーティングシステム74、ならびに仮想クライアント75。
一例として、管理レイヤ80は以下の機能を提供することができる。リソース準備81は、クラウドコンピューティング環境内でタスクを実行するために利用されるコンピューティングリソースおよび他のリソースの動的な調達を可能にする。計量および価格設定82は、クラウドコンピューティング環境内でリソースが利用される際のコスト追跡、およびこれらのリソースの消費に対する請求またはインボイス送付を可能にする。一例として、これらのリソースはアプリケーションソフトウェアのライセンスを含んでよい。セキュリティは、データおよび他のリソースに対する保護のみならず、クラウド消費者およびタスクの識別確認を可能にする。ユーザポータル83は、消費者およびシステム管理者にクラウドコンピューティング環境へのアクセスを提供する。サービスレベル管理84は、要求されたサービスレベルが満たされるように、クラウドコンピューティングリソースの割り当ておよび管理を可能にする。サービス品質保証(SLA)の計画および履行85は、SLAに従って将来必要になると予想されるクラウドコンピューティングリソースの事前手配および調達を可能にする。
ワークロードレイヤ90は、クラウドコンピューティング環境が利用可能な機能の例を提供する。このレイヤから提供可能なワークロードおよび機能の例には、マッピングおよびナビゲーション91、ソフトウェア開発およびライフサイクル管理92、仮想教室教育の配信93、データ分析処理94、取引処理95、および共有ライブラリをアンロードする際に、ランタイムリソースをクリーンアップするコンテナを利用することによる、セグメンテーションエラーの自動回避96が含まれる。
本発明は、任意の可能な技術詳細レベルで統合されたシステム、方法もしくはコンピュータプログラム製品またはそれらの組み合せとすることができる。コンピュータプログラム製品は、プロセッサに本発明の態様を実行させるためのコンピュータ可読プログラム命令を記憶したコンピュータ可読記憶媒体を含んでよい。
コンピュータ可読記憶媒体は、命令実行装置によって使用される命令を保持し、記憶することができる有形の装置とすることができる。コンピュータ可読記憶媒体は、一例として、電子記憶装置、磁気記憶装置、光学記憶装置、電磁記憶装置、半導体記憶装置またはこれらの適切な組み合わせであってよい。コンピュータ可読記憶媒体のより具体的な一例としては、ポータブルコンピュータディスケット、ハードディスク、RAM、ROM、EPROM(またはフラッシュメモリ)、SRAM、CD-ROM、DVD、メモリスティック、フロッピーディスク、パンチカードまたは溝内の隆起構造などに命令を記録した機械的に符号化された装置、およびこれらの適切な組み合せが挙げられる。本明細書で使用されるコンピュータ可読記憶装置は、電波もしくは他の自由に伝播する電磁波、導波管もしくは他の伝送媒体を介して伝播する電磁波(例えば、光ファイバケーブルを通過する光パルス)、またはワイヤを介して送信される電気信号のような、一過性の信号それ自体として解釈されるべきではない。
本明細書に記載のコンピュータ可読プログラム命令は、コンピュータ可読記憶媒体からそれぞれのコンピュータ装置/処理装置へダウンロード可能である。あるいは、ネットワーク(例えばインターネット、LAN、WANもしくはワイヤレスネットワークまたはこれらの組み合わせ)を介して、外部コンピュータまたは外部記憶装置へダウンロード可能である。ネットワークは、銅製伝送ケーブル、光伝送ファイバ、ワイヤレス伝送、ルータ、ファイアウォール、スイッチ、ゲートウェイコンピュータもしくはエッジサーバまたはこれらの組み合わせを備えることができる。各コンピュータ装置/処理装置内のネットワークアダプタカードまたはネットワークインタフェースは、ネットワークからコンピュータ可読プログラム命令を受信し、当該コンピュータ可読プログラム命令を、各々のコンピュータ装置/処理装置におけるコンピュータ可読記憶媒体に記憶するために転送する。
本発明の動作を実施するためのコンピュータ可読プログラム命令は、アセンブラ命令、命令セットアーキテクチャ(ISA)命令、機械命令、機械依存命令、マイクロコード、ファームウェア命令、状態設定データ、集積回路用構成データ、または、スモールトークやC++などのオブジェクト指向プログラミング言語、および「C」プログラミング言語や類似のプログラミング言語などの手続き型プログラミング言語を含む、1つ以上のプログラミング言語の任意の組み合わせで記述されたソースコードもしくはオブジェクトコードのいずれかとすることができる。コンピュータ可読プログラム命令は、スタンドアロン型ソフトウェアパッケージとして完全にユーザのコンピュータ上で、または部分的にユーザのコンピュータ上で実行可能である。あるいは、部分的にユーザのコンピュータ上でかつ部分的にリモートコンピュータ上で、または、完全にリモートコンピュータもしくはサーバ上で実行可能である。後者の場合、リモートコンピュータは、LANやWANを含む任意の種類のネットワークを介してユーザのコンピュータに接続してもよいし、外部コンピュータに(例えば、インターネットサービスプロバイダを使用してインターネットを介して)接続してもよい。いくつかの実施形態において、例えばプログラマブル論理回路、フィールドプログラマブルゲートアレイ(FPGA)、プログラマブル論理アレイ(PLA)を含む電子回路は、本発明の態様を実行する目的で当該電子回路をカスタマイズするために、コンピュータ可読プログラム命令の状態情報を利用することによって、コンピュータ可読プログラム命令を実行することができる。
本発明の実施形態は、本明細書において、本発明の実施形態に係る方法、装置(システム)、およびコンピュータプログラム製品のフローチャートもしくはブロック図またはその両方を参照して説明されている。フローチャートもしくはブロック図またはその両方における各ブロック、および、フローチャートもしくはブロック図またはその両方における複数のブロックの組み合わせは、コンピュータ可読プログラム命令によって実行可能である。
上記のコンピュータ可読プログラム命令は、機械を生産するために、汎用コンピュータ、専用コンピュータ、または他のプログラマブルデータ処理装置のプロセッサに提供してよい。これにより、かかるコンピュータまたは他のプログラマブルデータ処理装置のプロセッサを介して実行されるこれらの命令が、フローチャートもしくはブロック図またはその両方における1つ以上のブロックにて特定される機能/動作を実行するための手段を創出する。上記のコンピュータ可読プログラム命令はさらに、コンピュータ、プログラマブルデータ処理装置もしくは他の装置またはこれらの組み合わせに対して特定の態様で機能するよう命令可能なコンピュータ可読記憶媒体に記憶してよい。これにより、命令が記憶された当該コンピュータ可読記憶媒体は、フローチャートもしくはブロック図またはその両方における1つ以上のブロックにて特定される機能/動作の態様を実行するための命令を含む製品を構成する。
また、コンピュータ可読プログラム命令を、コンピュータ、他のプログラマブル装置、または他の装置にロードし、一連の動作ステップを当該コンピュータ、他のプログラマブル装置、または他の装置上で実行させることにより、コンピュータ実行プロセスを生成してもよい。これにより、当該コンピュータ、他のプログラマブル装置、または他の装置上で実行される命令が、フローチャートもしくはブロック図またはその両方における1つ以上のブロックにて特定される機能/動作を実行する。
本開示の図面におけるフローチャートおよびブロック図は、本発明の種々の実施形態に係るシステム、方法およびコンピュータプログラム製品の可能な実装形態のアーキテクチャ、機能性、および動作を示している。この点に関して、フローチャートまたはブロック図における各ブロックは、特定の論理機能を実行するための1つ以上の実行可能な命令を含む、命令のモジュール、セグメント、または部分を表すことができる。他の一部の実装形態において、ブロック内に示した機能は、各図に示す順序とは異なる順序で実行してもよい。例えば、連続して示される2つのブロックは、実際には、関係する機能に応じて、略同時に実行してもよいし、場合により逆順で実行してもよい。なお、ブロック図もしくはフローチャートまたはその両方における各ブロック、および、ブロック図もしくはフローチャートまたはその両方における複数のブロックの組み合わせは、特定の機能または動作を行う、または専用ハードウェアとコンピュータ命令との組み合わせを実行する専用ハードウェアベースのシステムによって、実行可能である。
本明細書で使用される用語は、特定の実施形態を説明することのみを目的としており、限定することを意図するものではない。本明細書で使用される場合、単数形「a」、「an」および「the」は、文脈が明確に他のことを示さない限り、複数形も含むことを意図している。本明細書で使用される場合、「含む(comprises)」という用語もしくは「含む(comprising)」という用語またはその両方は、記載された特徴、整数、ステップ、操作、要素、もしくは構成要素またはその組み合わせの存在を指定するが、1つ以上の他の特徴、整数、ステップ、操作、要素、構成要素、もしくはそれらのグループまたはその組み合わせの存在または追加を排除するものではない。
さらに、「例示的」という用語は、本明細書では「例、実例、または例示として機能すること」を意味するために使用される。本明細書で「例示的」として説明される任意の実施形態または設計は、必ずしも他の実施形態または設計よりも好ましいまたは有利であると解釈されるべきではない。「少なくとも1つ」および「1つまたは複数」という用語は、1以上、すなわち1、2、3、4などの任意の整数を含むと理解される。「複数」という用語は、2以上、つまり2、3、4、5などの任意の整数を含むと理解される。「接続」という用語には、間接的な「接続」と直接的な「接続」の両方を含めることができる。
「約」、「実質的に」という用語、およびそれらと同等の単語は、出願時に利用可能な機器に基づく特定の量の測定に関連する誤差の程度を含むことを意図している。例えば、「約」、「実質的に」およびそれらと同等の単語は、特定の値の±8%、5%、または2%の範囲を含めることができる。
本発明は、限られた数の実施形態にのみ関連して詳細に説明されてきたが、本発明は、そのような開示された実施形態に限定されないことを容易に理解されたい。むしろ、本発明は、これまでに説明されていないが、本発明の精神および範囲に見合う任意の数の変形、変更、置換または同等の配置を組み込むように修正することができる。さらに、本発明の様々な実施形態が説明されてきたが、本発明の態様は、説明された実施形態の一部のみを含むことができることが理解されるであろう。したがって、本発明は、前述の説明によって限定されるとは見なされず、添付の請求の範囲によってのみ限定される。
Claims (20)
- プロセッサを使用して、ローダライブラリにアクセスすることと、
前記プロセッサを使用して、前記ローダライブラリのモックバージョンを含むモックライブラリを生成することと、
前記プロセッサを使用して、前記ローダライブラリをコンテナ化することと、
前記プロセッサを使用して、前記ローダライブラリをアンロードすることと、を含む、コンピュータ実装方法。 - 前記ローダライブラリにアンロード信号を送信することをさらに含む、請求項1に記載のコンピュータ実装方法。
- 前記プロセッサは、ダイナミックリンク(dl)インターセプターモジュールを含む、請求項1に記載のコンピュータ実装方法。
- 前記プロセッサは、前記dlインターセプターモジュールに通信可能に結合されたスタック処理モジュールをさらに含む、請求項3に記載のコンピュータ実装方法。
- 前記プロセッサは、前記スタック処理モジュールに通信可能に結合されたマッピングスタブモジュールをさらに含む、請求項4に記載のコンピュータ実装方法。
- 前記マッピングスタブモジュールは、コンテナ化プラットフォームの一部であり、
前記モックライブラリは前記dlインターセプターモジュールに格納される、請求項5に記載のコンピュータ実装方法。 - dlclose命令は、前記ローダライブラリをアンロードするように前記プロセッサに指示するために使用される、請求項1に記載のコンピュータ実装方法。
- プロセッサに通信可能に結合されたメモリを含むコンピュータシステムであって、前記プロセッサは、
ローダライブラリにアクセスすることと、
前記ローダライブラリのモックバージョンを含むモックライブラリを生成することと、
前記ローダライブラリをコンテナ化することと、
前記ローダライブラリをアンロードすることと、を含むプロセッサ動作を実行するように構成される、コンピュータシステム。 - 前記プロセッサ動作は、前記ローダライブラリにアンロード信号を送信することをさらに含む、請求項8に記載のコンピュータシステム。
- 前記プロセッサは、ダイナミックリンク(dl)インターセプターモジュールを含む、請求項8に記載のコンピュータシステム。
- 前記プロセッサは、前記dlインターセプターモジュールに通信可能に結合されたスタック処理モジュールをさらに含む、請求項10に記載のコンピュータシステム。
- 前記プロセッサは、前記スタック処理モジュールに通信可能に結合されたマッピングスタブモジュールをさらに含む、請求項11に記載のコンピュータシステム。
- 前記マッピングスタブモジュールは、コンテナ化プラットフォームの一部であり、
前記モックライブラリは前記dlインターセプターモジュールに格納される、請求項12に記載のコンピュータシステム。 - 前記プロセッサ動作は、前記ローダライブラリをアンロードするように前記プロセッサに指示するdlclose命令を使用することを含む、請求項8に記載のコンピュータシステム。
- ライブラリをアンロードするためのコンピュータプログラム製品であって、前記コンピュータプログラム製品は、コンピュータ可読記憶媒体に格納されたコンピュータ可読プログラムを含み、前記コンピュータ可読プログラムは、プロセッサ上で実行されると、前記プロセッサに、
ローダライブラリにアクセスすることと、
前記ローダライブラリのモックバージョンを含むモックライブラリを生成することと、
前記ローダライブラリをコンテナ化することと、
前記ローダライブラリをアンロードすることと、を含むプロセッサ方法を実行させる、コンピュータプログラム製品。 - 前記ローダライブラリにアンロード信号を送信することをさらに含む、請求項15に記載のコンピュータプログラム製品。
- 前記プロセッサは、ダイナミックリンク(dl)インターセプターモジュールを含む、請求項15に記載のコンピュータプログラム製品。
- 前記プロセッサは、前記dlインターセプターモジュールに通信可能に結合されたスタック処理モジュールをさらに含む、請求項17に記載のコンピュータプログラム製品。
- 前記プロセッサは、前記スタック処理モジュールに通信可能に結合されたマッピングスタブモジュールをさらに含み、
前記モックライブラリは前記dlインターセプターモジュールに格納される、請求項18に記載のコンピュータプログラム製品。 - dlclose命令は、前記ローダライブラリをアンロードするように前記プロセッサに指示するために使用される、請求項15に記載のコンピュータプログラム製品。
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US17/481,580 US12020043B2 (en) | 2021-09-22 | 2021-09-22 | Using containers to clean runtime resources when unloading a shared library |
US17/481,580 | 2021-09-22 |
Publications (1)
Publication Number | Publication Date |
---|---|
JP2023046312A true JP2023046312A (ja) | 2023-04-03 |
Family
ID=85572744
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2022150019A Pending JP2023046312A (ja) | 2021-09-22 | 2022-09-21 | コンピュータ実装方法、コンピュータシステムおよびコンピュータプログラム製品(共有ライブラリをアンロードする際にランタイムリソースをクリーンアップするためにコンテナを使用すること) |
Country Status (3)
Country | Link |
---|---|
US (1) | US12020043B2 (ja) |
JP (1) | JP2023046312A (ja) |
CN (1) | CN115904528A (ja) |
Family Cites Families (10)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7739312B2 (en) * | 2007-04-27 | 2010-06-15 | Network Appliance, Inc. | Data containerization for reducing unused space in a file system |
KR20120014673A (ko) * | 2010-08-10 | 2012-02-20 | 주식회사 잉카인터넷 | 위장 동적연결라이브러리 삽입에 의한 프로세스 변조 검출방법 |
US8763018B2 (en) * | 2011-08-22 | 2014-06-24 | Solarflare Communications, Inc. | Modifying application behaviour |
US9582623B2 (en) | 2014-02-12 | 2017-02-28 | Synopsys, Inc. | Dynamically loaded system-level simulation |
US20160364222A1 (en) * | 2015-06-15 | 2016-12-15 | Unisys Corporation | Methods and systems for running modern applications in legacy software environments |
US10445112B2 (en) | 2017-01-27 | 2019-10-15 | Software Ag | Inline dispatching function interface (IDFI), and associated system and/or method |
US10416990B2 (en) | 2018-02-05 | 2019-09-17 | Infosys Limited | System and method for seamlessly patching shared libraries in server environment |
CN108762825B (zh) | 2018-04-20 | 2021-04-27 | 烽火通信科技股份有限公司 | 动态库重载的实现方法及系统 |
US11307911B2 (en) * | 2020-05-29 | 2022-04-19 | Microsoft Technology Licensing, Llc | File upload modifications for client side applications |
US20230035594A1 (en) * | 2021-08-02 | 2023-02-02 | Dell Products L.P. | Managing peripherals in a containerized environment |
-
2021
- 2021-09-22 US US17/481,580 patent/US12020043B2/en active Active
-
2022
- 2022-09-21 JP JP2022150019A patent/JP2023046312A/ja active Pending
- 2022-09-22 CN CN202211156019.6A patent/CN115904528A/zh active Pending
Also Published As
Publication number | Publication date |
---|---|
US12020043B2 (en) | 2024-06-25 |
CN115904528A (zh) | 2023-04-04 |
US20230092747A1 (en) | 2023-03-23 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US11625281B2 (en) | Serverless platform request routing | |
US9405529B2 (en) | Designing and cross-configuring software | |
US20190018715A1 (en) | Facilitating event-driven processing using unikernels | |
US20130262923A1 (en) | Efficient application management in a cloud with failures | |
US10838745B2 (en) | Loading dependency library files from a shared library repository in an application runtime environment | |
US11200041B1 (en) | Remote installation, customization and deployment of mainframe components | |
Hardikar et al. | Containerization: cloud computing based inspiration Technology for Adoption through Docker and Kubernetes | |
US20230409417A1 (en) | Automated generation of application programming interfaces for microservices | |
US11119810B2 (en) | Off-the-shelf software component reuse in a cloud computing environment | |
US11010149B2 (en) | Shared middleware layer containers | |
US11200070B2 (en) | Dynamic-link library usage based on memory size | |
US10656975B2 (en) | Hybrid cloud with dynamic bridging between systems of record and systems of engagement | |
US11704165B2 (en) | Persistently available container services through resurrection of user jobs in new compute container instances designated as lead instances | |
US10642580B1 (en) | Simplifying and reusing visual programming graphs | |
US10761914B2 (en) | Replacing generated procedure calls with generated inter-process communication | |
US12020043B2 (en) | Using containers to clean runtime resources when unloading a shared library | |
WO2022043852A1 (en) | Performing application snapshot using process virtual machine resources | |
US10296331B2 (en) | Log-based software porting | |
US11630804B1 (en) | Classifying and storing multiple layers of a file system | |
US11943115B2 (en) | Locally debugging remote deployment of microservices | |
US11829741B2 (en) | Instantiated deployment of microservices | |
US20230315502A1 (en) | Image management for container runtimes | |
US20230409716A1 (en) | Shared library customization | |
US20230367869A1 (en) | Providing system services | |
US20230086195A1 (en) | Efficient and extensive function groups with multi-instance function support for cloud based processing |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
RD16 | Notification of change of power of sub attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7436 Effective date: 20221222 |