(57)【特許請求の範囲】
【請求項１】
コンテナに基づくＧＰＵ（ｇｒａｐｈｉｃｓ  ｐｒｏｃｅｓｓｉｎｇ  ｕｎｉｔ）仮想化方法において、
コンテナが生成されると、ノードコントローラがＧＰＵ資源制約情報を含む設定ファイルとＡＰＩ（ａｐｐｌｉｃａｔｉｏｎ  ｐｒｏｇｒａｍｍｉｎｇ  ｉｎｔｅｒｆａｃｅ）設定ファイルを前記コンテナに送信する段階と、
前記コンテナが実行されると、前記コンテナに設けられるライブラリコントローラがライブラリ呼出しを横取りしてＧＰＵ資源使用可能量因子を変更し、システムコールコントローラがシステムコール呼出しを横取りして因子及び返還値を変更して仮想ＧＰＵを具現する段階と、を含み、
前記ノードコントローラは、
ＧＰＵ資源の使用可能量を確認し、ノードコントローラの資源情報を初期化し、管理部に資源の使用可能量を報告し、前記管理部から割り当てられた作業を受信するが、前記ノードコントローラの資源使用可能量情報を要請した量だけ差し引いて更新し、
前記ＧＰＵ資源の使用可能量は、実数で表される割合でＧＰＵ資源を部分的に使用可能な量である
ことを特徴とするコンテナに基づくＧＰＵ仮想化方法。
【請求項２】
前記ノードコントローラは、
コンテナが生成されると、資源制約情報を含む設定ファイルをコンテナに保存し、コンテナの実行後、終了が感知されると、ノードコントローラの資源使用可能量情報を要請した量だけ回収して更新する
請求項１に記載のコンテナに基づくＧＰＵ仮想化方法。
【請求項３】
前記ライブラリコントローラは、
ユーザプログラムのライブラリ関数呼出しイベントを受信すると、ＧＰＵ資源問合せ及び割当関連ＡＰＩ呼出しであるかを判断し、ＧＰＵ資源使用可能量因子、構造体フィールド、返還値の少なくとも一つを変更し、元のライブラリ関数を呼び出す
請求項１に記載のコンテナに基づくＧＰＵ仮想化方法。
【請求項４】
前記システムコールコントローラは、
ユーザプログラムのシステムコール呼出しイベントを受信すると、予め定義されたＡＰＩプログラムにより許容、遮断、変更の少なくとも一つのシステムコール呼出しであるかを判断し、ＡＰＩ設定ファイル規則により許容、遮断、または元のシステムコールの呼出し前後因子及び返還値を変更する
請求項１に記載のコンテナに基づくＧＰＵ仮想化方法。
【請求項５】
コンテナに基づくＧＰＵ仮想化システムにおいて、
資源制約情報を含む設定ファイルとシステムコール／ＡＰＩ設定ファイルをコンテナに伝達してコンテナ内に伝達するノードコントローラを含む運営体制と、
ユーザプログラムのライブラリ関数呼出しイベントを受信すると、ＧＰＵ資源問合せ及び割当関連ＡＰＩ呼出しであるかを判断し、ＧＰＵ資源使用可能量因子、構造体フィールド、返還値の少なくとも一つを変更し、元のライブラリ関数を呼び出すライブラリコントローラと、ユーザプログラムのシステムコール呼出しイベントを受信すると、予め定義されたＡＰＩ設定ファイルにより許容、遮断、変更の少なくとも一つのシステムコール呼出しであるかを判断し、ＡＰＩ設定ファイル規則により許容、遮断、または元のシステムコールの呼出し前後因子及び返還値を変更するシステムコールコントローラとを含むコンテナと、で構成され、
前記ノードコントローラは、
ＧＰＵ資源の使用可能量を確認し、ノードコントローラの資源情報を初期化し、管理部に資源の使用可能量を報告し、前記管理部から割り当てられた作業を受信するが、前記ノードコントローラの資源使用可能量情報を要請した量だけ差し引いて更新し、
前記ＧＰＵ資源の使用可能量は、実数で表される割合でＧＰＵ資源を部分的に使用可能な量である
ことを特徴とするコンテナに基づくＧＰＵ仮想化システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、コンテナに基づくＧＰＵ（ｇｒａｐｈｉｃｓ  ｐｒｏｃｅｓｓｉｎｇ  ｕｎｉｔ）仮想化方法及びシステムに係り、特に、コンテナ内のライブラリコントローラ及びシステムコールコントローラにより、ＧＰＵ資源と関連した因子値等を変更してＧＰＵ仮想化を具現するコンテナに基づくＧＰＵ仮想化方法及びシステムに関する。
【背景技術】
【０００２】
最近、マルチユーザのための大規模コンピューティングの効率性、保安性、及び互換性の向上のために、仮想化技術が多く用いられている。代表的に、仮想マシン（Ｖｉｒｔｕａｌ  Ｍａｃｈｉｎｅ）があり、アプリケーション、サーバ、ストレージ、及びネットワーク等の多様な分野に適用されている。しかし、仮想マシンは、ＣＰＵ（ｃｅｎｔｒａｌ  ｐｒｏｃｅｓｓｉｎｇ  ｕｎｉｔ）からディスク、ネットワーク、Ｉ／Ｏ（ｉｎｐｕｔ／ｏｕｔｐｕｔ）まで物理的なハードウェア要素を全て仮想化するので、互換性と隔離レベルは最も高いが、コンピューティング資源の追加消耗量（オーバーヘッド）が大きいという短所をあった。
【０００３】
一方、コンテナは、仮想化ではなく、運営体制レベルの隔離技術を用いて、仮想マシンの短所を克服する仮想化技術として浮上している。コンテナは、カーネルレベルの実行環境はホストの運営体制カーネルを共有するが、ユーザレベルの実行環境は完全に隔離されたファイルシステムと、カーネルが提供する資源要素の仮想化した名前空間を用いる方式で具現される。隔離されたファイルシステムの内容は、アプリケーションとそれを駆動するために必要な全ての従属物、ライブラリ、その他のバイナリと構成ファイル等を一つのパッケージにまとめて構成される。仮想化した名前空間に区分され、コンテナに提供されるカーネルの資源要素には、プロセスＩＤ、ネットワークソケット、ユーザアカウント、プロセス間通信（ＩＰＣ、ｉｎｔｅｒｐｒｏｃｅｓｓ ｃｏｍｍｕｎｉｃａｔｉｏｎ）のための共有メモリ等がある。その他のハードウェアアクセスは、コンテナでない場合と同様に処理されるので、ホストハードウェアの性能をオーバーヘッド無しに完全に活用することができる。ここで、運営体制は、コンテナ別に最大使用可能なハードウェア資源の量を制限できるオプションを提供する。
【０００４】
最近、深層学習技術の発達と大規模な演算需要の増加につれて、コンピューティング資源を最適に共有して管理する技術が要請されている。性能向上のために、深層学習の演算特性に最適化した演算加速ハードウェアが登場しており、ＧＰＵも、その一つである。しかし、既存の運営体制において提供するコンテナに基づく仮想化技術は、コンテナ別にＣＰＵ、メモリ、ディスク、及びファイルシステムに対する資源共有及び制限のみを支援しており、ＧＰＵのような演算加速ハードウェアについては、多くのコンテナが同時に共有できる技術が提供されていない。このため、ＧＰＵを効率的に共有及び管理し難いという問題が発生した。
【発明の概要】
【発明が解決しようとする課題】
【０００５】
本発明は、上記問題点に鑑みなされたものであり、コンテナを用いて、物理的仮想化ではなく、運営体制レベルの仮想化により、ＧＰＵ資源を動的に割当及び共有可能なコンテナに基づくＧＰＵ仮想化方法及びシステムを提供することを目的とする。
【課題を解決するための手段】
【０００６】
本発明の一実施例に係るコンテナに基づくＧＰＵ仮想化方法は、コンテナが生成されると、ノードコントローラがＧＰＵ資源制約情報を含む設定ファイルとＡＰＩ（ａｐｐｌｉｃａｔｉｏｎ  ｐｒｏｇｒａｍｍｉｎｇ  ｉｎｔｅｒｆａｃｅ）プロファイルを前記コンテナに送信する段階と、前記コンテナが実行されると、前記コンテナに設けられるライブラリコントローラがライブラリ呼出しを横取りしてＧＰＵ資源量と関連した因子を変更し、システムコールコントローラがシステムコール呼出しを横取りして因子及び返還値を変更して仮想ＧＰＵを具現する段階と、を含む。
【０００７】
本発明の一実施例に係るコンテナに基づくＧＰＵ仮想化システムは、資源制約情報を含む設定ファイルとシステムコール／ＡＰＩプロファイルをコンテナに伝達してコンテナ内に伝達するノードコントローラを含む運営体制と、ユーザプログラムのライブラリ関数呼出しイベントを受信すると、ＧＰＵ資源問合せ及び割当関連ＡＰＩ呼出しであるかを判断し、ＧＰＵ資源量と関連した因子、構造体フィールド、返還値の少なくとも一つを変更し、元のライブラリ関数を呼び出すライブラリコントローラと、ユーザプログラムのシステムコール呼出しイベントを受信すると、予め定義されたＡＰＩプロファイルにより許容、遮断、変更の少なくとも一つのシステムコール呼出しであるかを判断し、ＡＰＩプロファイル規則により許容、遮断、または元のシステムコールの呼出し前後因子及び返還値を変更するシステムコールコントローラとを含むコンテナと、で構成される。
【発明の効果】
【０００８】
本発明によれば、コンテナ仮想化技術を拡張することにより、シングルコンテナにシングルＧＰＵを割り当て、またはシングルコンテナにマルチＧＰＵを割り当て、またはシングルＧＰＵをマルチコンテナが共有し、またはマルチＧＰＵをマルチコンテナが共有するＧＰＵコンピューティンシステムの具現が可能である。
【０００９】
また、コンテナを用いて具現することにより、仮想マシンに比べて、システム資源をさらに効率的に用いることができ、アプリケーション移動が可能であり、スケーリングが簡単であり、アップデートが容易であるという効果がある。
【図面の簡単な説明】
【００１０】
【図１】本発明の一実施例に係るコンテナに基づくＧＰＵ仮想化システムのソフトウェア構造の説明図
【図２】本発明の一実施例に係るコンテナに基づくＧＰＵ仮想化方法のフローチャート
【図３】本発明の一実施例に係るノードコントローラの動作方法のフローチャート
【図４】本発明の一実施例に係るライブラリコントローラの動作方法のフローチャート
【図５】本発明の一実施例に係るシステムコールコントローラの動作方法のフローチャート
【発明を実施するための形態】
【００１１】
本明細書に開示されている本発明の概念による実施例についての特定の構造的または機能的説明は、単に本発明の概念による実施例を説明するための目的で例示されたものであり、本発明の概念による実施例は、様々な形態で実施されてもよく、本明細書に説明された実施例に限定されない。
【００１２】
本発明の概念による実施例は、様々な変更が加えられてもよく、様々な形態を有し得るので、実施例を図面に例示し、本明細書において詳述する。しかし、これらは、本発明の概念による実施例を特定の開示形態に限定するものではなく、本発明の思想及び技術範囲に含まれる全ての変更、均等物、または代替物を含む。
【００１３】
本明細書において用いられた用語は、単に特定の実施例を説明するために用いられたものであって、本発明を限定するものではない。単数の表現は、文脈上明らかに異なる意味を有さない限り、複数の表現を含む。本明細書において、「含む」または「有する」との用語は、本明細書に記載された特徴、数字、段階、動作、構成要素、部分品、またはそれらの組合せが存在することを指定するものであり、一つまたはそれ以上の他の特徴や数字、段階、動作、構成要素、部分品、またはそれらの組合せの存在または付加可能性を予め排除するものではない。
【００１４】
以下、添付された図面を参照して、本発明の好適な実施例について詳述する。
図１は、本発明の一実施例に係るコンテナに基づくＧＰＵ仮想化システムのソフトウェア構造を説明するための図である。
【００１５】
図１を参照すると、ＧＰＵ仮想化システム１００のソフトウェア構造は、物理的ＧＰＵ（ＰＨＹＳＩＣＡＬ ＧＰＵ）１１０、運営体制１２０、多数個のコンテナ１３０で構成される。
【００１６】
運営体制１２０は、ノードコントローラ１２１、コンテナエンジン１２３、運営体制カーネル１２５で構成される。運営体制１２０は、運営体制カーネル１２５内にインストールされたＧＰＵドライバ１２７を介して物理的ＧＰＵ１１０と通信する。
【００１７】
ノードコントローラ１２１は、資源制約情報を含む設定ファイルとシステムコール／ＡＰＩプロファイルをコンテナ１３０に伝達してコンテナ内に保存する。ノードコントローラ１２１は、ＧＰＵ資源の使用可能量を確認し、ノードコントローラの資源情報を初期化する。前記ＧＰＵ資源は、ＧＰＵプロセッシングユニットとＧＰＵメモリであってもよいが、これに限定するものではない。ノードコントローラ１２１は、管理部（Ｍａｎａｇｅｒ）に確認された資源の使用可能量を報告し、前記管理部から割り当てられた作業を受信する。ノードコントローラ１２１は、ＧＰＵ資源の使用可能量情報を更新し、このとき、要請した量だけ差し引く。ノードコントローラ１２１は、コンテナが生成されると、資源制約情報を含む設定ファイルをコンテナに伝達し、コンテナの実行後、終了が感知されると、ノードコントローラの資源使用可能量情報を要請した量だけ回収して更新する。ノードコントローラ１２１は、ユーザのコード実行要請をコンテナ内で実行する。
【００１８】
コンテナエンジン１２３は、コンテナ１３０を生成して配布し、各コンテナ１３０が該当する応用プログラムを実行するようにＧＰＵ資源を割り当てる役割を行う。コンテナエンジン１２３は、コンテナを実行して終了する。
【００１９】
コンテナ１３０は、ユーザプログラムを駆動するために必要な、各種のプログラム、ソースコードと、ライブラリをまとめたイメージを含む空間である。ユーザプログラムの駆動は、運営体制１２０で実質的に行われる。すなわち、運営体制１２０は、コンテナエンジン１２３を介してそれぞれのコンテナ１３０にアクセスし、該当するユーザプログラムを実行して処理する。
【００２０】
コンテナ１３０は、ユーザプログラム１３１、ＧＰＵライブラリ１３３、ＧＰＵランタイム１３５、ライブラリコントローラ１３７、システムコールコントローラ１３９で構成される。
ユーザプログラム１３１は、ノードコントローラのユーザのコード実行要請をコンテナ内で実行するように動作する。
【００２１】
ＧＰＵライブラリ１３３は、深層学習フレームワークが動作するようにライブラリを含み、例えば、テンソルフロー（ＴｅｎｓｏｒＦｌｏｗ）、Ｃａｆｆｅ、Ｐｙｔｏｒｃｈ、ＣＮＴＫ（Ｍｉｃｒｏｓｏｆｔ  Ｃｏｇｎｉｔｉｖｅ  Ｔｏｏｌｋｉｔ）、Ｃｈａｉｎｅｒのような深層学習フレームワークの少なくとも一つが動作してもよい。
【００２２】
ＧＰＵランタイム１３５は、ＧＰＵで行う並列処理アルゴリズムであるＣＵＤＡ（Ｃｏｍｐｕｔｅ  Ｕｎｉｆｉｅｄ  Ｄｅｖｉｃｅ  Ａｒｃｈｉｔｅｃｔｕｒｅ）、ＯｐｅｎＣＬ（Ｏｐｅｎ  Ｃｏｍｐｕｔｉｎｇ  Ｌａｎｇｕａｇｅ）、ＲＯＣｍ（Ｒａｄｅｏｎ  Ｏｐｅｎ  Ｃｏｍｐｕｔｅ）がインストールされて使用されてもよい。前記ＣＵＤＡは、マシンランニング分野で活用されるＧＰＵミドルウェアとしてＧＰＵランタイムで動作する。前記ＯｐｅｎＣＬは、マシンランニング分野と高性能コンピューティン（ＨＰＣ、Ｈｉｇｈ  Ｐｅｒｆｏｒｍａｎｃｅ  Ｃｏｍｐｕｔｉｎｇ）において活用する並列コンピューティングとクロスプラットフォームにより動作する。
【００２３】
ライブラリコントローラ１３７は、ユーザプログラムのライブラリ関数呼出しイベントを受信すると、ＧＰＵ資源問合せ及び割当関連ＡＰＩ呼出しであるかを判断し、ＧＰＵ資源量と関連した因子、構造体フィールド、返還値の少なくとも一つを変更して元のライブラリ関数を呼び出す。ＧＰＵ資源問合せ及び割当関連ＡＰＩ呼出しでなければ、元のライブラリ関数を因子変更無しに呼び出し、返還値をそのままリターンする。
【００２４】
システムコールコントローラ１３９は、ユーザプログラムのシステムコール呼出しイベントを受信すると、予め定義されたＡＰＩプログラムにより許容、遮断、変更の少なくとも一つのシステムコール呼出しであるかを判断し、ＡＰＩプロファイル規則により許容、遮断、または元のシステムコールの呼出し前後因子及び返還値を変更する。予め定義されたＡＰＩプロファイルによる許容、遮断、変更の少なくとも一つのシステムコール呼出しでなければ、元のシステムコールを因子変更無しに呼び出し、返還値をそのままリターンする。
【００２５】
すなわち、コンテナ内のライブラリコントローラ１３７がライブラリ呼出しを横取りしてＧＰＵ資源量と関連した因子を変更し、システムコールコントローラ１３９がシステムコール呼出しを横取りして因子及び返還値を変更することにより仮想ＧＰＵを具現する。
【００２６】
図２は、本発明の一実施例に係るコンテナに基づくＧＰＵ仮想化方法を説明する順序図である。
【００２７】
図２を参照すると、コンテナが生成されると（Ｓ２０１）、ノードコントローラ１２１がＧＰＵ資源制約情報を含む設定ファイルとシステムコール／ＡＰＩプロファイルを前記コンテナに送信する（Ｓ２０３）。コンテナ内のライブラリコントローラとシステムコールコントローラが資源制約情報を含む設定ファイルを受信して保存する。
【００２８】
コンテナが実行されると、前記コンテナに設けられるライブラリコントローラ１３７がライブラリ呼出しを横取りしてＧＰＵ資源量と関連した因子を変更し、システムコールコントローラ１３９がシステムコール呼出しを横取りして因子及び返還値を変更して仮想ＧＰＵを具現する（Ｓ２０５）。このとき、ライブラリコントローラ１３７は、ＧＰＵ資源量と関連した因子のみならず、構造体フィールド、返還値を変更して元のライブラリ関数を呼び出す。
【００２９】
図３は、本発明の一実施例に係るノードコントローラの動作方法を説明する順序図である。
【００３０】
図３を参照すると、ノードコントローラは、先ずＧＰＵの資源使用可能量を確認する（Ｓ３０１）。また、ノードコントローラは、資源情報を初期化する（Ｓ３０３）。
【００３１】
サーバ実行ループにより、以下のプロセスが繰り返して進行される（Ｓ３０５）。確認されたＧＰＵ資源使用可能量を管理部に報告し（Ｓ３０７）、前記管理部から割り当てられた作業（ｊｏｂ  ｓｐｅｃ）を受信する（Ｓ３０９）。ノードコントローラ１２１は、資源使用可能量情報を更新する（Ｓ３１１）。このとき、要請した量だけ差し引かれる。以降、コンテナが生成され（Ｓ３１３）、ライブラリコントローラとシステムコールコントローラが読み出す資源制約情報を含む設定ファイルをコンテナに送信して保存する（Ｓ３１５）。以降、コンテナが実行され（Ｓ３１７）、コンテナの終了が感知されると、ノードコントローラの資源使用可能量情報を更新する（Ｓ３１９）。このとき、要請した量を回収する。
【００３２】
図４は、本発明の一実施例に係るライブラリコントローラの動作方法を説明する順序図である。
【００３３】
図４を参照すると、ユーザプログラムのライブラリ関数呼出しイベントを受信する（Ｓ４０１）。以降、ＧＰＵ資源問合せ及び割当関連ＡＰＩコールであるかを判断する（Ｓ４０３）。
【００３４】
判断結果により、ＧＰＵ資源問合せ及び割当関連ＡＰＩコールである場合は、ＧＰＵ資源量と関連した因子、構造体フィールド、返還値の少なくとも一つを変更する（Ｓ４０５）。このとき、内蔵されたＡＰＩプロファイル及びコンテナ設定ファイルに基づいて変更される。
以降、変更後、元のライブラリ関数を呼び出す（Ｓ４０７）。
【００３５】
判断結果により、ＧＰＵ資源問合せ及び割当関連ＡＰＩコールでなければ、元のライブラリ関数を因子変更無しに呼び出し、返還値をそのままリターンする（Ｓ４０９）。
【００３６】
図５は、本発明の一実施例に係るシステムコールコントローラの動作方法を説明する順序図である。
【００３７】
図５を参照すると、ユーザプログラムのシステムコール呼出しイベントを受信する（Ｓ５０１）。予め定義されたＡＰＩプロファイルに変更が必要なシステムコールであるかを判断する（Ｓ５０３）。このとき、変更のみならず、許容、遮断すべき場合であるかを判断する。判断結果により、許容、遮断、及び変更が必要なシステムコールであれば、ＡＰＩプロファイル規則により許容、遮断、または元のシステムコールの呼出し前後因子及び返還値を変更する（Ｓ４０５）。
【００３８】
判断結果により、許容、遮断、及び変更が必要ではないシステムコールであれば、元のライブラリ関数を因子変更無しに呼び出し、返還値をそのままリターンする（Ｓ４０７）。
【００３９】
本発明は、図示された実施例を参考として説明されたが、これは、例示的なものに過ぎず、本技術分野における通常の知識を有する者であれば、これに基づいて様々な変形及び均等な他の実施例が可能である。したがって、本発明の真正の技術的保護範囲は、添付された登録請求の範囲の技術的思想により定められなければならない。
【図１】
0006943954.tif 000002
【図２】
0006943954.tif 000003
【図３】
0006943954.tif 000004
【図４】
0006943954.tif 000005
【図５】
0006943954.tif 000006