KR20190143248A - 컨테이너 기반 가상화 환경에서 gpu 메모리 자원 관리 및 스케줄링 방법 및 시스템 - Google Patents

Abstract

컨테이너 기반 가상화 환경에서 GPU 메모리 자원 관리 및 스케줄링 방법 및 시스템이 제시된다. 본 발명에서 제안하는 컨테이너 기반 가상화 환경에서 GPU 메모리 자원 관리 및 스케줄링 방법은 사용자 정의된 nvidia-도커(docker)에 명령이 전송되면, NVIDIA GPU 사용 옵션을 갖는 오리지널 도커에 명령이 리디렉션되는 단계, ConVGPU가 상기 NVIDIA GPU 와 통신 및 제어하여 CUDA 래퍼(wrapper) API 모듈을 컨테이너에 삽입하는 단계, 컨테이너 런타임 중에 CUDA 래퍼 API 모듈이 일부 API를 캡처하여 GPU 메모리 스케줄러로 전송하는 단계 및 GPU 메모리 스케줄러가 컨테이너와 GPU 메모리 사용을 스케줄링하는 단계를 포함한다.

Description

컨테이너 기반 가상화 환경에서 GPU 메모리 자원 관리 및 스케줄링 방법 및 시스템{Method and System to manage and schedule GPU memory resource in Container-based virtualized environment}

본 발명은 컨테이너 기반 가상화 환경에서 GPU 메모리 자원을 관리하고 스케줄하는 방법 및 시스템에 관한 것이다.

현재 클라우드 컴퓨팅 시스템을 지원하는 데 가장 중요한 것은 VM(Virtual Machine)의 존재이다. VM은 운영 체제(Operating System; OS)의 장치를 가상으로 시뮬레이션하는 데 널리 사용되었다. VM은 단일 컴퓨터를 가상화 환경으로 가상화하므로 여러 사용자를 지원해야 하는 클라우드 컴퓨팅 서비스 공급자에게 필수적이다. 그러나 컨테이너 기반 가상화는 가볍고 사용하기 쉽기 때문에 VM을 대체하기 위한 새로운 기술로 부상하였다. 컨테이너는 VM에 비해 빌드 시간과 실행 시간이 빠르다는 이점을 가진다. 컨테이너의 빠른 처리 속도는 VM에 비해 더 작은 컨테이너의 크기에 의한 것이다. 전체 OS의 가상화가 요구되는 VM과 달리, 컨테이너는 OS의 일부만 가상화한다. 컨테이너의 경량 특성으로 인해, 컨테이너 기반 가상화 솔루션을 사용하는 머신은 리소스 양을 줄여 가상화된 환경의 수를 늘릴 수 있다.

GPU는 원래 더 빠른 그래픽 렌더링을 위한 구성 요소로 설계되었기 때문에, 각 픽셀에 동일한 알고리즘을 적용하는 병렬 컴퓨팅을 위한 고유한 아키텍처를 갖추고 있다. 최근, 그래픽 렌더링 뿐만 아니라 GPU의 강력한 병렬 컴퓨팅 기능이 산업 및 연구 분야에서 범용 고성능 컴퓨팅으로 사용되기 시작하였다. CUDA(Compute Unified Device Architecture) 및 OpenCL(Open Computing Language) 와 같은 여러 플랫폼이 범용 GPU 사용을 위해 출시되었다. 예를 들어, CUDA는 NVIDIA GPU용 프로그래밍 모델 및 API(Application Programming Interface)가 포함된 병렬 컴퓨팅 플랫폼이다. GPU는 기계 학습과 같은 다양한 분야에 적용되며 성능 향상을 위해 클라우드 환경에서 자주 사용된다. 따라서 가상화 환경에서 보다 효율적으로 GPU를 사용하려는 노력이 있어 왔다.

가상화 시스템은 호스트의 하드웨어 컴퓨팅 리소스를 제어하여 여러 가상화 환경에 제공한다. 가상화 시스템은 가상화 환경에 요구되는 다양한 하드웨어 구성 요소를 제공한다. 예를 들어, 컨테이너 기반 가상화 솔루션 중 하나인 도커(Docker)는 Linux 커널이 제공하는 cgroup을 사용하여 CPU 시간, 메모리 및 네트워크 대역폭을 제어한다. 또한, 도커는 UnionFS(Union File System)를 사용하여 디스크 저장소를 관리한다. 그러나 GPU는 다른 자원과 다르게 오랜 기간동안 가상화 시스템에서 사용할 수 없었다.

가상화 환경에서 가상화 GPU(vGPU)를 제공하기 위한 GViM, gVirtuS 및 vCUDA과 같은 여러 시도가 있었다. 이러한 시도들은 CUDA API 사본을 만들어 GPU를 가상화하고 이를 가상 머신에 제공한다. 원격으로 위치한 GPU를 사용하기 위한 솔루션인 rCUDA 도 이와 비슷한 방법을 사용하므로 가상화 시스템에서 GPU를 사용하는 데 응용할 수 있었다. 이러한 시도에도 불구하고, 전술된 방법들은 GPU 자체를 가상화하는 과정에서 GPU의 성능을 저하시킨다는 단점을 가진다. 또한, CUDA가 공개적으로 문서화되지 않았기 때문에, 전술된 방법들은 오리지널 CUDA API의 서브 세트 사본으로 남아있다. 하드웨어 수준에서 GPU를 가상화하는 NVIDIA GRID 와 같은 다른 시도가 있었다. 그러나 이 방법은 특정 장치만을 사용해야 하며 컨테이너 기반 가상화 환경은 지원하지 않는다. 컨테이너 기반 가상화 개념과 달리, 컨테이너에 완전히 가상화된 GPU를 제공하는 방법은 오랫동안 성공하지 못하였다.

최근, NVIDIA 코퍼레이션(Corporation)은 도커 환경을 위한 NVIDIA 도커를 제안하였다. NVIDIA 도커는 앞서 소개된 접근 방식들과 완전히 다른 접근 방식이다. NVIDIA 도커는 전체 GPU를 단일 컨테이너에 할당하기만 하면 된다. 이 방법은 위에 논의된 대부분의 문제를 해결할 수 있다. 도커 컨테이너는 할당된 GPU를 자유롭게 사용 가능하며, 성능 저하가 거의 존재하지 않는다. 그러나 여러 컨테이너에서 동일한 GPU를 동시에 사용하려고 하면 치명적인 문제가 발생한다. NVIDIA 도커는 GPU를 할당하기만 하고 컨테이너 내부의 사용자 프로그램이 GPU를 사용하는 방식에는 관여하지 않는다. 이 경우, GPU 메모리에 대한 메모리 할당을 포함하는 동시 액세스는 여러 컨테이너에서 발생할 수 있다. 그러나 GPU 메모리의 총 양은 제한되어 있으며 GPU 메모리 스와핑은 현재 지원되지 않는다. 따라서 다수의 컨테이너에서 동일한 GPU에 동시에 액세스하면 프로그램 실패를 초래할 수 있으며, 최악의 경우 교착(deadlock) 상태가 발생할 수 있다.

컨테이너 기반 가상화 환경 간의 보다 나은 리소스 공유를 위한 다른 시도가 존재한다. Monsalve 등은 캐시 액세스를 최적화하기 위해 컨테이너에 CPU 리소스를 할당하는 솔루션을 제공한다. McDaniel 등은 입/출력 QoS(Quality of Service)의 로드 밸런싱을 위한 솔루션을 제안하였다. Dusia 등은 QoS에서 컨테이너에 대한 네트워크 우선 순위를 구성하는 확장을 제시한다. 그러나 여러 컨테이너간에 GPU 리소스를 공유하기 위한 사전 연구는 존재하지 않는다.

본 발명이 이루고자 하는 기술적 과제는 NVIDIA 도커를 이용한 컨테이너 기반 가상화 환경에 GPU를 구현하는 가장 실질적인 방법 및 시스템을 제공하는데 있다. 또한, 여러 컨테이너간에 GPU 공유를 고려하여 프로그램 실패 또는 교착 상태를 막기 위한 방법 및 시스템을 제안한다.

일 측면에 있어서, 본 발명에서 제안하는 컨테이너 기반 가상화 환경에서 GPU 메모리 자원 관리 및 스케줄링 방법은 사용자 정의된 nvidia-도커(docker)에 명령이 전송되면, NVIDIA GPU 사용 옵션을 갖는 오리지널 도커에 명령이 리디렉션되는 단계, ConVGPU가 상기 NVIDIA GPU 와 통신 및 제어하여 CUDA 래퍼(wrapper) API 모듈을 컨테이너에 삽입하는 단계, 컨테이너 런타임 중에 CUDA 래퍼 API 모듈이 일부 API를 캡처하여 GPU 메모리 스케줄러로 전송하는 단계 및 GPU 메모리 스케줄러가 컨테이너와 GPU 메모리 사용을 스케줄링하는 단계를 포함한다.

상기 사용자 정의된 nvidia-도커(docker)에 명령이 전송되면, NVIDIA GPU 사용 옵션을 갖는 오리지널 도커에 명령이 리디렉션되는 단계는 컨테이너가 사용할 수 있는 최대의 GPU 메모리를 설정하기 위해 nvidia-도커에 사용자가 정의한 대로, 컨테이너 내부의 호스트와 프로그램간 통신을 위해 ConVGPU에 UNIX 소켓을 적용하고, 공유 메모리 및 일반 파일 공유를 위한 옵션들을 제공한다.

상기 ConVGPU가 상기 NVIDIA GPU 와 통신하고 제어하여 CUDA 래퍼(wrapper) API 모듈을 컨테이너에 삽입하는 단계는 ConVGPU를 사용할 때 각 사용자 프로그램이 완전히 격리되도록 하고, 컨테이너의 정지 상태를 감지하기 위해, nvidia-도커를 사용하여 nvidia-도커-플러그인에 연결된 컨테이너에 더미 볼륨을 추가한다.

컨테이너의 실행이 종료되는 경우, 도커는 볼륨을 마운트 해제하여, nvidia-도커-플러그인이 컨테이너가 종료되었음을 확인하고, nvidia-도커-플러그인은 해당 컨테이너에 대한 스케줄러로 종료 신호를 전송한다.

컨테이너 런타임 중에 CUDA 래퍼 API 모듈이 일부 API를 캡처하여 GPU 메모리 스케줄러로 전송하는 단계는 CUDA 래퍼 API 모듈은 요청된 메모리 크기가 사용 가능한 경우에만 오리지널 CUDA API를 사용하여 메모리를 할당하고, 할당 후 CUDA 래퍼 API 모듈은 할당된 메모리 주소, 현재 pid 및 크기 정보를 GPU 메모리 스케줄러로 전송하여 GPU 메모리 사용을 추적한다.

상기 GPU 메모리 스케줄러가 컨테이너와 GPU 메모리 사용을 스케줄링하는 단계는 GPU 메모리 스케줄러는 컨테이너로부터 모든 GPU 메모리 할당을 수락, 일시 중지 또는 거부하도록 결정하고, 각 컨테이너에 UNIX 소켓을 생성하고 컨테이너에 삽입된 CUDA 래퍼 API 모듈과 통신한다.

사용자에 의해 컨테이너가 실행되기 전에, nvidia-도커는 해당 컨테이너의 고유 디렉토리 경로를 스케줄러에 요청하고, 스케줄러는 컨테이너와 볼륨을 공유하기 위한 디렉토리를 생성하여, 디렉토리 내에 UNIX 소켓을 구축하고, CUDA 래퍼 API 모듈을 디렉토리에 복사한다.

사용자 프로그램이 메모리 할당 API를 호출하면, CUDA 래퍼 API 모듈은 컨테이너에 준비된 UNIX 소켓을 통해 메모리 크기 정보를 GPU 메모리 스케줄러로 전송하고, GPU 메모리 스케줄러는 컨테이너에서 모든 메모리 할당 호출을 추적한다.

실행중인 컨테이너에서 GPU 메모리 크기가 충분하지 않은 경우, 요구되는 메모리 크기를 사용할 수 있을 때까지 GPU 메모리 스케줄러의 응답이 일시 중단되고, 해당 컨테이너에서 요청된 모든 메모리 할당은 스케줄러가 컨테이너에 GPU 메모리를 더 할당할 때까지 일시 중단되며, 일부 컨테이너의 실행이 완료되면 GPU 메모리 스케줄러가 점유된 GPU 메모리를 다른 컨테이너에 할당한다.

또 다른 컨테이너 기반 가상화 환경에서 GPU 메모리 자원 관리 및 스케줄링 시스템은 명령이 전송되면, NVIDIA GPU 사용 옵션을 갖는 오리지널 도커에 명령을 리디렉션하는 사용자 정의된 nvidia-도커(docker), 상기 NVIDIA GPU 와 통신 및 제어하여 CUDA 래퍼(wrapper) API 모듈을 컨테이너에 삽입하는 ConVGPU, 컨테이너 런타임 중에 일부 API를 캡처하여 GPU 메모리 스케줄러로 전송하는 CUDA 래퍼 API 모듈 및 컨테이너와 GPU 메모리 사용을 스케줄링하는 GPU 메모리 스케줄러를 포함한다.

본 발명의 실시예들에 따르면 여러 컨테이너에서 GPU를 공유하는 솔루션인 ConVGPU를 사용하여, 컨테이너가 실행해야 하는 GPU 메모리를 시스템에서 보장할 수 있고, 이를 달성하기 위해 컨테이너에서 수행될 GPU 메모리를 관리하는 네 가지 스케줄링 알고리즘을 소개한다. 이 알고리즘들은 실행 중에 시스템이 컨테이너 간의 교착 상태에 빠지는 것을 방지할 수 있다.

도 1은 본 발명의 일 실시예에 따른 컨테이너 기반 가상화 환경에서 GPU 메모리 자원 관리 및 스케줄링 과정을 설명하기 위한 개략도이다.
도 2는 본 발명의 일 실시예에 따른 컨테이너 기반 가상화 환경에서 GPU 메모리 자원 관리 및 스케줄링 방법을 설명하기 위한 흐름도이다.
도 3은 본 발명의 일 실시예에 따른 컨테이너 기반 가상화 환경에서 GPU 메모리 자원 관리 및 스케줄링 시스템의 구성을 나타내는 도면이다.
도 4는 본 발명의 일 실시예에 따른 ConVGPU 내에서 동일한 GPU를 사용하는 여러 컨테이너를 사용하는 시나리오를 설명하기 위한 도면이다.

요즘 GPU는 범용 고성능 컴퓨팅에 필수적이다. 병렬 컴퓨팅에서의 탁월한 성능이 CPU의 성능과 비교되기 때문이다. 가상화 환경에서 GPU 사용에 대한 많은 성공적인 시도가 있어 왔다. 특히, NVIDIA 도커는 컨테이너 기반 가상화 환경에 GPU를 구현하는 가장 실질적인 방법을 얻는다. 그러나 이러한 시도들의 대부분은 여러 컨테이너간에 GPU 공유를 고려하지 않는다. 위의 사항을 고려하지 않으면, 시스템은 최악의 경우 프로그램 실패 또는 교착 상태를 경험하게 된다. 본 발명에서는 여러 컨테이너에서 GPU를 공유하는 솔루션인 ConVGPU를 제안한다. ConVGPU를 사용하면, 컨테이너가 실행해야 하는 GPU 메모리를 시스템에서 보장할 수 있게 된다. 이를 달성하기 위해, 컨테이너에서 수행될 GPU 메모리를 관리하는 네 가지 스케줄링 알고리즘을 소개한다. 이러한 알고리즘들은 실행 중에 시스템이 컨테이너 간의 교착 상태에 빠지는 것을 방지할 수 있다. 이하, 본 발명의 실시 예를 첨부된 도면을 참조하여 상세하게 설명한다.

도 1은 본 발명의 일 실시예에 따른 컨테이너 기반 가상화 환경에서 GPU 메모리 자원 관리 및 스케줄링 과정을 설명하기 위한 개략도이다.

본 발명에서는 컨테이너 기반의 가상 환경에서 컨테이너(120)와 GPU를 공유하는 솔루션인 ConVGPU를 제안한다. ConVGPU는 여러 컨테이너(120)에 대한 GPU 리소스를 컨테이너화하고 제한할 수 있다. ConVGPU의 개념은 각 컨테이너의 GPU 리소스 할당/할당 해제 데이터를 파악하고 이러한 정보를 사용하여 컨테이너(120)를 관리한다. ConVGPU는 기존 CUDA API와 완벽하게 호환되므로 사용자(110)가 신경 쓸 필요가 없다. 위에서 설명한 NVIDIA 도커에서 이 솔루션을 구현한다. 또한, ConVGPU는 GPU 리소스를 공정하게 사용하는 방식으로 컨테이너(120)를 스케줄링하므로 자신의 용량보다 더 많은 GPU 종속 컨테이너(120)를 머신에서 실행할 수 있다. 실험을 통해 ConVGPU는 무시할 수 있을 정도의 성능 저하만을 가진다는 것을 확인하였다. 성능을 비교하기 위해 네 가지 기본 스케줄링 알고리즘을 구현한다. 실험은 Best-Fit 알고리즘이 모든 주어진 컨테이너(120)에 대한 전체 실행 시간에서 가장 빠른 알고리즘이라는 것을 보여준다. 전반적인 시스템 아키텍처는 도 1에 나타나 있다.

GPU는 빠른 그래픽 렌더링을 위한 컴퓨팅 장치 구성 요소이다. 렌더링은 모든 픽셀에 대해 동일한 독립적인 알고리즘을 계산해야 하므로, GPU는 병렬 실행에 최적화되어 있다. 요즘, GPU는 자체 특성 때문에 범용 컴퓨팅에도 사용된다. GPU가 소비하는 데이터는 CPU에서 복사해야 하기 때문에, 많은 조직에서는 GPU를 범용으로 쉽게 사용할 수 있는 여러 컴퓨팅 플랫폼을 도입한다.

2007년 2월에 CUDA가 출시된 이래로, CUDA는 범용 GPU(GPGPU)에서 가장 널리 사용되는 플랫폼 중 하나가 되었다. CUDA는 ANSI C 언어를 확장하고 사용하기 쉬운 API를 제공한다. CUDA API는 드라이버 API와 런타임 API의 두 가지 프로그래밍 인터페이스를 제공한다. 런타임 API는 하위 수준의 드라이버 API를 기반으로 구현되는 상위 수준의 API이다. 런타임 API는 암시적 초기화 및 관리를 제공하므로 Driver API보다 사용하기가 쉽다. 그러나 드라이버 API는 세분화된 컨텍스트 제어 및 모듈 로딩을 수행할 수 있다. GPU를 사용하는 사용자 프로그램 중 일부는 GPU에서 실행되도록 작성되었다. 이 프로그램의 일부는 커널이라고 불리며 GPU로 전송된 후 GPU에서 실행된다. CUDA를 사용하는 모든 프로그램은 nvcc로 컴파일되어야 하는데, nvcc는 CUDA 플랫폼의 일부인 컴파일러이다.

GPU 가상화 환경에서 GPU를 사용할 수 있도록 하기 위해 많은 프레임 워크가 도입되었다. 이러한 프레임 워크들은 가상 환경에서 가상화된 GPU를 제공하기 위해 원격-API 기술을 사용한다. 원격 API 기술의 개념은 가상화 환경에서 API 호출을 캡처하여 호스트(130) 시스템으로 리디렉션(redirecting)하는 것이다. 따라서 GPU를 사용하기 위한 API 호출은 GPU가 가상화 환경에 존재하지 않더라도 실행될 수 있다. 결과적으로, 가상화 환경과 호스트(130)간에 통신하는 방법이 중요하다. 표 1은 프레임 워크를 설명하고 비교한다. 이러한 방법들의 주요 단점은 API를 캡처하는 것이 어렵다는 점이다. API에 변경 사항이 있는 경우, 새로운 버전에 대한 후속 조치가 수행되어야 한다.

GPU를 가상화하는 또 다른 방법은 PCI pass-through 기술이다. 이 기술은 GPU를 가상화된 환경에 직접 할당한다. 기존 VM에서, 이 기술은 CPU에서 IOMMU 지원을 필요로 한다. 그러나 컨테이너 기반 가상화 환경에서는 장치 마운트를 컨테이너(120)에 연결하여 쉽게 얻을 수 있다. 오픈스택(OpenStack)은 GPU의 장치 ID를 Nova 구성 파일에 기록하여 이 방법을 지원한다. NVIDIA 도커는 도커 컨테이너(120)가 --device 옵션을 사용하여 GPU를 사용하도록 한다. PCI pass-through 기술의 장점은 가상화 환경의 사용자 프로그램이 GPU에 직접 액세스 할 수 있다는 것이다. 이로 인해 성능이 저하되지 않는다. 그러나 컨트롤러나 솔루션이 존재하지 않기 때문에 가상화 환경에 연결된 GPU는 다른 사람들과 공유될 수 없다.

위에서 언급된 기술들과 비교하여 NVIDIA GRID 는 하드웨어 수준에서 GPU를 가상화한다. NVIDIA GRID는 vGPU를 생성하고 각 VM에 직접 할당한다. 예를 들어, NVIDIA GRID K1은 최대 4개의 동시 VM을 제공할 수 있다. 그러나 NVIDIA GRID는 NVIDIA GRID K1 및 K2와 같은 특정 유형의 GPU를 필요로 한다. 또한, GRID는 Citrix XenApp(일부 다른 Xen 시리즈 포함) 및 VMware Horizon만 지원한다. GRID는 모든 컨테이너 기반 가상화 솔루션과 호환되지 않는다.

도 2는 본 발명의 일 실시예에 따른 컨테이너 기반 가상화 환경에서 GPU 메모리 자원 관리 및 스케줄링 방법을 설명하기 위한 흐름도이다.

제안하는 컨테이너 기반 가상화 환경에서 GPU 메모리 자원 관리 및 스케줄링 방법은 사용자 정의된 nvidia-도커(docker)에 명령이 전송되면, NVIDIA GPU 사용 옵션을 갖는 오리지널 도커에 명령이 리디렉션되는 단계(210), ConVGPU가 상기 NVIDIA GPU 와 통신 및 제어하여 CUDA 래퍼(wrapper) API 모듈을 컨테이너에 삽입하는 단계(220), 컨테이너 런타임 중에 CUDA 래퍼 API 모듈이 일부 API를 캡처하여 GPU 메모리 스케줄러로 전송하는 단계(230) 및 GPU 메모리 스케줄러가 컨테이너와 GPU 메모리 사용을 스케줄링하는 단계(240)를 포함한다.

단계(210)에서, 사용자 정의된 nvidia-도커(docker)에 명령이 전송되면, NVIDIA GPU 사용 옵션을 갖는 오리지널 도커에 명령이 리디렉션된다. 컨테이너가 사용할 수 있는 최대의 GPU 메모리를 설정하기 위해 nvidia-도커를 사용자 정의하고, 컨테이너 내부의 호스트와 프로그램간 통신을 위해 ConVGPU에 UNIX 소켓을 적용하고, 공유 메모리 및 일반 파일 공유를 위한 옵션들을 제공한다.

단계(220)에서, ConVGPU가 상기 NVIDIA GPU 와 통신 및 제어하여 CUDA 래퍼(wrapper) API 모듈을 컨테이너에 삽입한다. ConVGPU를 사용할 때 각 사용자 프로그램이 완전히 격리되도록 하고, 컨테이너의 정지 상태를 감지하기 위해, nvidia-도커를 사용하여 nvidia-도커-플러그인에 연결된 컨테이너에 더미 볼륨을 추가한다. 컨테이너의 실행이 종료되는 경우, 도커는 볼륨을 마운트 해제하여, nvidia-도커-플러그인이 컨테이너가 종료되었음을 확인하고, nvidia-도커-플러그인은 해당 컨테이너에 대한 스케줄러로 종료 신호를 전송한다.

단계(230)에서, 컨테이너 런타임 중에 CUDA 래퍼 API 모듈이 일부 API를 캡처하여 GPU 메모리 스케줄러로 전송한다. CUDA 래퍼 API 모듈은 요청된 메모리 크기가 사용 가능한 경우에만 오리지널 CUDA API를 사용하여 메모리를 할당하고, 할당 후 CUDA 래퍼 API 모듈은 할당된 메모리 주소, 현재 pid 및 크기 정보를 GPU 메모리 스케줄러로 전송하여 GPU 메모리 사용을 추적한다.

단계(240)에서, GPU 메모리 스케줄러가 컨테이너와 GPU 메모리 사용을 스케줄링한다. GPU 메모리 스케줄러는 컨테이너로부터 모든 GPU 메모리 할당을 수락, 일시 중지 또는 거부하도록 결정하고, 각 컨테이너에 UNIX 소켓을 생성하고 컨테이너에 삽입된 CUDA 래퍼 API 모듈과 통신한다.

사용자에 의해 컨테이너가 실행되기 전에, nvidia-도커는 해당 컨테이너의 고유 디렉토리 경로를 스케줄러에 요청하고, 스케줄러는 컨테이너와 볼륨을 공유하기 위한 디렉토리를 생성하여, 디렉토리 내에 UNIX 소켓을 구축하고, CUDA 래퍼 API 모듈을 디렉토리에 복사한다.

사용자 프로그램이 메모리 할당 API를 호출하면, CUDA 래퍼 API 모듈은 컨테이너에 준비된 UNIX 소켓을 통해 메모리 크기 정보를 GPU 메모리 스케줄러로 전송하고, GPU 메모리 스케줄러는 컨테이너에서 모든 메모리 할당 호출을 추적한다.

실행중인 컨테이너에서 GPU 메모리 크기가 충분하지 않은 경우, 요구되는 메모리 크기를 사용할 수 있을 때까지 GPU 메모리 스케줄러의 응답이 일시 중단되고, 해당 컨테이너에서 요청된 모든 메모리 할당은 스케줄러가 컨테이너에 GPU 메모리를 더 할당할 때까지 일시 중단되며, 일부 컨테이너의 실행이 완료되면 GPU 메모리 스케줄러가 점유된 GPU 메모리를 다른 컨테이너에 할당한다.

도 3은 본 발명의 일 실시예에 따른 컨테이너 기반 가상화 환경에서 GPU 메모리 자원 관리 및 스케줄링 시스템의 구성을 나타내는 도면이다.

도커는 컨테이너 기반 가상화를 제공하는 오픈 소스 어플리케이션 컨테이너 엔진이다. 2013년 출시된 이래, 도커는 가장 널리 사용되는 컨테이너 기반 가상화 시스템이 되었다. 현재 도커는 Linux, FreeBSD 및 Windows x64를 지원한다. 본 발명의 실시예에서는 도커가 주로 사용되는 Linux 환경만 고려하였다.

도커는 프로세스 샌드박싱(sandboxing)을 위해 리브컨테이너(libcontainer)를 사용한다. 도커는 이전에 사용 가능한 다양한 커널 기술을 토대로 제작되었다. 제어그룹을 사용하여 각 컨테이너에 속한 프로세스를 분리하고 서브 시스템을 사용하여 CPU 시간 또는 메모리 제한을 처리한다. 또한, Linux 네임 스페이스를 사용하여 별도의 프로세스 ID(pid), 마운트 포인트(mnt), 호스트 이름 및 도메인 이름을 갖는다. 이러한 커널 기능을 사용하여, docker는 호스트 시스템에서 특정 프로세스를 효과적으로 격리할 수 있다. 그러나 본 발명에서 다루는 GPU 리소스를 관리하는 계획은 존재하지 않는다.

NVIDIA 도커는 도커 컨테이너 내부에서 NVIDIA GPU를 쉽게 사용할 수 있도록 하는 유틸리티 세트이다. NVIDIA 도커에는 nvidia-도커 및 nvidia-도커-플러그인의 두 가지 실행 프로그램이 포함된다.

nvidia-도커는 사용자가 원래의 도커 명령 대신 nvidia-도커 명령을 사용할 수 있도록 사용자로부터 명령을 캡처하는 도커의 위에 존재하는 씬 랩퍼(thin wrapper)이다. nvidia-도커는 사용자 입력에 몇 가지 옵션만 추가하기 때문에, 도커와 호환된다. 그 역할은 사용자 명령을 해석하고 편집하여 도커 명령 인터페이스로 전송하는 것이다. nvidia-도커는 런(run) 및 생성(create) 명령만 캡처하고 다른 도커 명령은 도커로 전달된다. 이미지가 CUDA API를 사용하는지 여부는 필요한 CUDA 버전을 나타내는 com.nvidia.volumes.needed 및 com.nvidia.cuda.version 도커 레이블을 사용하여 확인할 수 있다. nvidia-도커는 이 레이블 정보를 사용하여 설치된 GPU 장치의 수와 위치를 감지하고, 이를 --device 옵션과 연결한다. 또한, nvidia-도커-플러그인에 직접 연결된 --volume 옵션을 사용하여 적절한 버전의 GPU 드라이버를 연결한다. 제안된 솔루션은 nvidia-도커를 사용자 정의하여 GPU 메모리를 제어하는 기능을 추가한다.

nvidia-도커-플러그인은 도커의 볼륨 플러그인 중 하나로서 도커의 기능성을 확장한다. nvidia-도커-플러그인의 의도는 NVIDIA GPU 및 CUDA API의 존재를 확인하고 적절한 버전의 바이너리 및 라이브러리 파일을 컨테이너에 제공하는 것이다. nvidia-도커가 검사하는 CUDA API 버전은 도커 볼륨 이름을 사용하여 nvidia-도커-플러그인으로 전달된다. 컨테이너가 실행을 중지하면, 컨테이너에 마운트된 볼륨이 마운트 해제된다.

ConVGPU는 GPU 리소스, 특히 GPU 메모리를 가상화하여 여러 컨테이너간에 GPU 리소스를 공유하도록 설계되었다. ConVGPU는 GPU 메모리 스케줄러 및 CUDA 래퍼 API 모듈의 두 가지 주요 구성 요소로 이루어져 있다.

GPU 메모리 스케줄러는 각 컨테이너의 GPU 메모리 한계를 확인한다. 컨테이너가 한계에 도달할 때까지 GPU 메모리를 사용하면, 스케줄러는 할당 호출을 거부하거나 필요한 경우 실행을 일시 중지한다. CUDA wrapper API 모듈은 컨테이너가 생성될 때 컨테이너에 삽입된다. 이 모듈은 컨테이너 내부의 사용자 프로그램에서 오리지널 CUDA API 호출을 캡처한다. 이러한 구성 요소들(NVIDIA Docker 포함)은 JSON(JavaScript Object Notation) 형식의 UNIX 도메인 소켓(UNIX 소켓)을 사용하여 연결되고 통신된다. 이 섹션의 나머지 부분에서는 각 구성 요소에 대해 자세히 설명하고 스케줄링 예를 보여준다.

전체 시스템 설계는 도 3에 나타나 있다. 사용자가 사용자 정의된 nvidia-docker(320)에 사용자 코맨드(310)를 전송하면, NVIDIA GPU 사용 옵션을 가지는 오리지널 도커(330)에 명령이 리디렉션된다. 도커(330)는 도커 컨테이너를 생성 및 러닝(331)하고, 도커 컨테이너(340)는 앱으로부터 메모리 관련 호출(341)을 하여 ConVGPU(350)에 전달한다. 동시에, ConVGPU(350)는 CUDA wrapper API 모듈(351)을 컨테이너에 삽입한다. 컨테이너 런타임 중에 CUDA wrapper API 모듈(351)은 일부 API를 캡처하여 GPU 메모리 스케줄러(352)로 전송한다. GPU 메모리 스케줄러(352)는 컨테이너와 GPU 메모리 사용을 스케줄링한다. 다시 말해, CUDA wrapper API 모듈(351)은 GPU 메모리 스케줄러(532)에 메모리 한계를 할당하고, 사용정보를 전송(353)한다.

nvidia-도커-플러그인(360)은 볼륨을 할당(361)하고, 드라이브 및 볼륨을 링크(332)한다.

본 발명의 실시예에 따르면, ConVGPU(350)에서 다음과 같은 요소들을 고려하였다.

격리: 기존의 GPU 가상화 솔루션은 컨테이너 개념에 반대되는 전체 GPU를 가상화하려고 했기 때문에 컨테이너화된 환경에 적합하지 않다. 이를 대신하여, 본 발명에서는 GPU를 사용할 때 각 사용자 프로그램이 완전히 격리되도록 설계하였다.

일관성: 적절한 GPU 메모리 관리 시스템이 없으면 GPU를 사용하는 컨테이너가 충돌하거나 오작동할 수 있다. ConVGPU는 이 문제를 방지하기 위해 GPU 메모리를 관리함으로써 한 컨테이너에서의 실패가 다른 컨테이너에 영향을 미치지 않도록 해야 한다. 또한 컨테이너는 GPU 메모리 용량 이상으로 생성된 경우에도 잘 작동되어야 한다.

공유성: CUDA API에는 공개되지 않은 기능이 포함되어 있으므로 가능한 한 호스트와 함께 원래의 CUDA API를 채택하였다. 또한 기존 API와의 호환성이 보장되면, ConVGPU는 별도의 노력없이 사용되어야 한다.

도커는 호스트와 컨테이너화된 환경 사이의 프로세스 간 통신(IPC)을 본질적으로 차단하므로, 컨테이너 내부의 호스트와 프로그램간 통신을 위해 ConVGPU에 UNIX 소켓을 채택하였다. 공유 메모리 및 일반 파일 공유와 같이 통신을 위해 고려된 다른 옵션들이 존재한다. 그러나 다른 옵션들은 UNIX 소켓을 사용하는 것보다 안전하지 않다. 다른 옵션들을 사용할 때 제3자가 정보를 가로챌 수 있기 때문이다. 또한 기존의 TCP/IP 소켓을 고려했지만, UNIX 소켓에 비해 복잡성이 낮고 성능이 낮기 때문에 선택하지 않았다.

대부분의 경우, 컨테이너는 한 번에 전체 GPU 메모리를 사용하지 않는다. GPU 메모리는 각 컨테이너가 일부 제한 내에서 사용하는 경우 공유될 수 있다. 컨테이너가 사용할 수 있는 최대의 GPU 메모리를 설정하기 위해 NVIDIA 도커를 사용자 정의하였다. 이를 처리하기 위해, --nvndia-memory=<size> 사용자 옵션을 nvidia-docker에 포함시켰다. 옵션 입력이 없을 때 도커 이미지에서 com.nvidia.memory.limit:<size> 라벨을 사용하거나 옵션과 라벨이 모두 없는 경우 1GiB를 기본값으로 설정하도록 시스템을 설계하였다. 이 제한 사항은 컨테이너가 작성되기 전에 UNIX 소켓을 통해 스케줄러로 보내진다. 다음으로, nvidia-도커를 사용자 정의하여 스케줄러로부터 디렉토리 경로를 가져왔다. nvidia-도커는 CUDA wrapper API 모듈 및 UNIX 소켓이 들어있는 디렉토리와 컨테이너를 연결하는 데, UNIX 소켓은 --volume 옵션을 사용하여 컨테이너에 준비된다. 또한, CUDA wrapper API 모듈을 컨테이너에서 작동하도록 만들기 위해, --env 옵션을 삽입하여 nvidia-도커 내부에 LD_PRELOAD Linux 환경 변수를 설정하였다. 이 환경 변수는 다른 라이브러리보다 동적 링커에 의해 로드되는 라이브러리 목록을 포함한다. 제안하는 시스템은 이 환경 변수를 설정하여 CUDA API 모듈 전에 CUDA wrapper API 모듈을 로드한다. 컨테이너의 정지 상태를 감지하기 위해, nvidia 도커를 사용하여 nvidia-도커-플러그인에 연결된 컨테이너에 더미(dummy) 볼륨을 추가하였다. 어떤 이유로든지 컨테이너의 실행이 종료되면, 도커는 볼륨을 마운트 해제한다. 따라서 nvidia-도커-플러그인은 컨테이너가 종료되었음을 확인할 수 있다. 이어서, nvidia-도커-플러그인은 해당 컨테이너에 대한 스케줄러로 종료(close) 신호를 전송할 수 있다.

사용자 프로그램은 NVIDIA 드라이버(370)를 통해 CUDA API를 사용하여 NVIDIA GPU(380)와 통신하고 제어한다. 이후, 사용자 정의된 nvidia-도커(320)에 GPU를 할당(381)한다. 이러한 API는 커널 프로그램 실행 및 CPU에서 GPU로의 데이터 복사 등 여러 작업을 수행한다. 컨테이너와 GPU 메모리의 사용을 관리하고 스케줄링하려면, API 캡처 모듈이 필요하다. 리눅스 공유 라이브러리인 CUDA wrapper API 모듈(wrapper 모듈)을 만들었다. 파일 이름이 libgpushare.so인 API 래퍼 모듈은 주로 메모리 할당 또는 할당 취소 API를 포함하는 오리지널 API의 서브-파트를 커버한다. LD PRELOAD Linux 환경 변수에서 이 공유 라이브러리에 경로를 추가함으로써, 오리지널 CUDA API를 오버라이드하고 API 호출을 인터셉트할 수 있다. 이전 연구들과 비교할 때, API 래퍼 모듈은 일부 CUDA API의 기능 심볼 이름을 오버라이드하기 때문에, CUDA API의 전체 복사본을 구현하지 않았으며 다른 CUDA API도 사용할 수 있다. LD PRELOAD를 사용하는 것은 내부 CUDA API를 사용할 수 있는 이점을 가진다. 또한, wrapper 모듈은 rCUDA와 같은 다른 사용자 맞춤형 CUDA API에서도 사용될 수 있다. 기존 API를 아무런 추가 구현 없이 사용할 수 있기 때문이다. 제안하는 래퍼 모듈은 CUDA 드라이버 API와 런타임 API를 모두 지원할 수 있다. nvcc 컴파일러는 CUDA 런타임 API를 기본적으로 사용자 프로그램 내부에 정적으로 연결한다. 이 경우, 공유 라이브러리가 이미 사용자 프로그램에 삽입되어 있으므로, LD PRELOAD를 사용하여 기능 심볼 이름을 오버라이딩하는 것은 작동하지 않는다. 래퍼 모듈이 런타임 API 호출을 인터셉트하지 못하게 하려면, 사용자 프로그램이 -cudart=shared 옵션을 사용하여 컴파일되어야 한다.

래퍼 모듈에 의해 캡처된 CUDA API는 할당 API와 할당 해제 API의 두 가지 유형으로 크게 분류될 수 있다. 할당 API는 사용자 프로그램이 GPU 메모리를 할당하려고 할 때 사용된다. 사용자 프로그램이 할당을 시도하는 순간, wrapper 모듈은 요청된 메모리 크기만을 알고 있다. 이 메모리 크기 정보는 스케줄러로 보내지고 크기가 사용 가능한지 여부를 검사 받는다. 스케줄러는 필요한 메모리 크기를 사용할 수 있을 때 긍정 응답을 반환하고 메모리가 이미 초과된 경우 거부한다. 래퍼 모듈은 요청된 메모리 크기가 사용 가능한 경우에만 오리지널 CUDA API를 사용하여 메모리를 할당한다. 실제 할당 후, 래퍼 모듈은 할당된 메모리 주소, 현재 pid 및 크기 정보를 스케줄러로 전송하여 메모리 사용을 추적한다. cudaMallocArray와 같은 텍스처 메모리로 사용되는 일부 할당 API는 GPGPU에서 사용되지 않기 때문에 캡처되지 않는다.

일부 메모리 할당 API는 다른 사용자 프로그램의 첫 번째 메모리 요청인 증가된 크기의 메모리를 할당할 수 있다. 예를 들어, cudaMallocPitch API는 여러 개의 GPU 스레드를 이용하여 액세스 속도를 높이기 위해 피치(pitched) 메모리를 할당한다. 이 피치 크기는 GPU 모델에 따라 다양하다. 따라서 래퍼 모듈은 첫 번째 호출에서 cudaGetDeviceProperties API를 사용하여 현재 GPU의 피치 크기를 검색한다. 또한, cudaMallocManaged API는 매핑된 메모리를 사용하기 때문에 128MiB의 배수인 메모리 크기를 할당한다. 이러한 경우, 래퍼 모듈은 사용 가능한 메모리 크기를 확인하기 전에 조정된 할당 크기를 계산한다.

사용자 프로그램이 GPU 메모리 할당을 해제하려고 하는 경우, 래퍼 모듈은 메모리의 주소를 알고 있다. 이 경우, 래퍼 모듈은 오리지널 CUDA API를 사용하여 메모리를 할당 해제하고, GPU 메모리 스케줄러로 주소를 전송한다. 사용자 프로그램은 래퍼 모듈로부터 할당 해제의 결과를 얻게 될 것이다. 또한, 사용자 프로그램이 완료되면, __cudaUnregisterFatBinary CUDA API가 호출된다. 이 API는 종료할 때 GPU에서 CUDA fat 바이너리 등록을 취소한다. 래퍼 모듈은 이 API를 캡처하고 GPU 메모리 스케줄러로 정보를 전송하여 현재 프로세스에서 사용되는 GPU 메모리를 할당 해제한다. 할당 API 및 할당 해제 API 목록은 표 2에 요약되어 있다.

컨테이너는 자체의 최대 사용 가능한 GPU 메모리를 기반으로 스케줄링되어야 한다. GPU 메모리 스케줄러는 Go 프로그래밍 언어로 작성된 독립 실행형 프로그램이다. 이 스케줄러는 nvidia-도커-플러그인과 비슷하게 호스트 시스템에서 실행된다. GPU 메모리 스케줄러는 컨테이너로부터 모든 GPU 메모리 할당을 수락, 일시 중지 또는 거부하도록 결정한다. 각 컨테이너에 UNIX 소켓을 생성하고 컨테이너에 삽입된 래퍼 모듈과 통신한다. 사용자에 의해 컨테이너가 실행되기 전에, nvidia-도커는 이 컨테이너의 고유한 디렉토리 경로를 스케줄러에 요청한다. 스케줄러는 컨테이너와 볼륨을 공유하기 위한 디렉토리를 생성하고, 디렉토리 내에 UNIX 소켓을 구축하며, 래퍼 모듈을 디렉토리에 복사한다.

사용자 프로그램이 메모리 할당 API를 호출하면, 래퍼 모듈은 컨테이너에 준비된 UNIX 소켓을 통해 메모리 크기 정보를 스케줄러로 전송한다. 스케줄러는 컨테이너에서 모든 메모리 할당 호출을 추적한다. 따라서 스케줄러는 해당 컨테이너에 얼마나 많은 여유 메모리가 허용되는지 실시간으로 파악할 수 있다. 메모리 크기가 할당하기에 충분하면, 스케줄러는 래퍼 모듈로 메시지를 전송한다. 실제 할당이 래퍼 모듈에 의해 CUDA API를 호출한 후, 할당된 주소를 메모리 크기와 함께 스케줄러로 전송한다. 스케줄러는 해시 구조를 사용하여 이 정보를 추적하고 총 메모리 사용량을 계산한다. 레이스 컨디션(race condition)을 방지하기 위해 각 단계는 mutex lock으로 보호된다.

사용자 프로그램이 처음으로 CUDA API를 사용하여 메모리를 할당할 때, CUDA는 현재 프로세스와 관련된 데이터를 저장하기 위해 64MiB의 메모리를 사용하고 CUDA 컨텍스트를 저장하기 위해 2MiB를 사용한다. 이러한 메모리 할당에 대한 자세한 정보는 공개되지 않지만, GPU 드라이버 버전이나 GPU 장치 유형에 따라 크기가 다양하다. 스케줄러는 호출자 pid를 이용하여 할당 정보를 추적한다. 따라서 스케줄러는 주어진 pid로부터 첫 번째 할당인지 여부를 확인하고 전체 사용량의 GPU 메모리 66MiB를 추가로 계산한다.

래퍼 모듈이 사용자 프로그램의 실행이 완료된 것을 감지하면, 해당 정보를 스케줄러로 전송한다. 그런 다음, 스케줄러는 pid에서 메모리 할당 정보를 제거한다. 일부 프로그램들은 할당된 GPU 메모리를 명시적으로 해제하지 않기 때문에 이 기능이 요구된다. 마찬가지로, nvidia-도커-플러그인에 의해 컨테이너가 중지했음을 감지했을 시, 스케줄러는 컨테이너에서 해당 컨테이너의 정보를 제거한다.

실행중인 컨테이너에 유효한 GPU 메모리 크기가 요구되지만 시스템의 메모리 크기가 충분하지 않은 경우, 요구되는 메모리 크기를 사용할 수 있을 때까지 스케줄러의 응답이 일시 중단된다. 일시 중지된 컨테이너가 여러 개 존재할 수 있으며, 이러한 컨테이너에서 요청된 모든 메모리 할당은 스케줄러가 컨테이너에 GPU 메모리를 더 할당할 때까지 일시 중단된다. 일부 컨테이너의 실행이 완료되면, 스케줄러는 점유된 GPU 메모리를 다른 컨테이너에 할당할 수 있다. 본 발명에서는 어떤 컨테이너가 추가 메모리를 확보해야 하는지를 결정하기 위해 네 가지 스케줄링 알고리즘을 배치하였다. 이러한 알고리즘들은 다음과 같이 소개되며, 이 알고리즘들의 성능 평가는 섹션 IV에 제시되어 있다.

FIFO(First-in, first-out): 알고리즘은 일시 중지된 컨테이너 중에서 가장 오래된 컨테이너를 선택한다. 그런 다음, 할당된 메모리가 선택된 컨테이너가 생성시 요청한 필수 메모리 크기에 도달할 때까지 컨테이너에 사용 가능한 메모리를 할당한다.

Best-Fit(BF): 알고리즘은 메모리가 부족하지만 남은 메모리를 초과하지 않는 컨테이너를 선택한다. 이러한 컨테이너가 존재하지 않는 경우에는 메모리가 가장 적게 부족한 컨테이너를 선택한다.

최근 사용(Recent use; RU): 알고리즘은 가장 최근에 일시 중단된 컨테이너를 선택한다. 그런 다음, 할당된 메모리가 선택한 컨테이너 생성시 요청한 필수 메모리 크기에 도달할 때까지 컨테이너에 사용 가능한 메모리를 할당한다.

Random(Rand): 알고리즘은 일시 중지된 컨테이너 중에서 무작위로 선택한다. 그런 다음, 할당된 메모리가 선택한 컨테이너 생성시 요청한 필수 메모리 크기에 도달할 때까지 컨테이너에 사용 가능한 메모리를 할당한다.

도 4는 본 발명의 일 실시예에 따른 ConVGPU 내에서 동일한 GPU를 사용하는 여러 컨테이너를 사용하는 시나리오를 설명하기 위한 도면이다.

본 발명의 실시예에 따른, ConVGPU 내에서 동일한 GPU를 사용하는 여러 컨테이너를 사용하는 자세한 시나리오를 제공한다. 도 4a에서 표현된 바와 같이, 단일 GPU에서 이미 실행중인 두 개의 컨테이너, 컨테이너 A(411a) 및 컨테이너 B(412a)가 있다고 가정한다. 그리고 막대의 길이로서 컨테이너에 할당된 메모리(420a)를 나타내었다.

도 4b를 참조하면, 컨테이너 A(411b) 및 컨테이너 B(412b)가 이미 있다고 가정하고, 컨테이너 C(413b)가 실행되면, GPU 메모리는 생성시 요청된 컨테이너 C(413b)에 부분적으로 할당(430b)된다. 그러나 컨테이너 C는 할당된 메모리 내에서 GPU 메모리를 사용하기 때문에 일시 중지되지 않는다.

도 4c에 표현된 바와 같이, 컨테이너 A(411c) 및 컨테이너 B(412c)가 있고, 컨테이너 C(413c)는 물리적으로 할당된 것보다 더 많은 GPU 메모리를 할당하려고 시도할 때 일시 중단된다. 컨테이너 생성 시간에서 요청된 메모리 크기 내에 존재하기 때문에 여전히 유효한 요청이다. 그러나 컨테이너 C(413c)는 필요한 만큼 물리적인 메모리를 할당받지 못했기 때문에 일시 중단된다. 또한, 컨테이너 D(414c)는 자신에게 할당된 GPU 메모리가 없기 때문에 즉시 일시 중지된다. 컨테이너 C(413c)와 컨테이너 D(414c)는 할당을 연기(430c)한다.

도 4d를 참조하면, 컨테이너 B(412c)가 종료되고 자신의 GPU 메모리를 반환하면, 스케줄러는 컨테이너 C(413c)를 선택하고 컨테이너가 처음 요청한 모든 GPU 물리 메모리를 보장한다. 이제 컨테이너 C(413c)는 실행을 다시 시작할 수 있다. 스케줄러가 컨테이너 C(413c)에 할당한 후에 GPU 메모리가 남아 있기 때문에, 스케줄러는 컨테이너 D(414c)에 남아있는 메모리를 할당한다. 그러나 컨테이너 D(414c)에 대해서는 충분하지 않기 때문에, 일시 중단된 상태로 남아 있게 된다.

이상에서 설명된 장치는 하드웨어 구성요소, 소프트웨어 구성요소, 및/또는 하드웨어 구성요소 및 소프트웨어 구성요소의 조합으로 구현될 수 있다. 예를 들어, 실시예들에서 설명된 장치 및 구성요소는, 예를 들어, 프로세서, 콘트롤러, ALU(arithmetic logic unit), 디지털 신호 프로세서(digital signal processor), 마이크로컴퓨터, FPA(field programmable array), PLU(programmable logic unit), 마이크로프로세서, 또는 명령(instruction)을 실행하고 응답할 수 있는 다른 어떠한 장치와 같이, 하나 이상의 범용 컴퓨터 또는 특수 목적 컴퓨터를 이용하여 구현될 수 있다. 처리 장치는 운영 체제(OS) 및 상기 운영 체제 상에서 수행되는 하나 이상의 소프트웨어 애플리케이션을 수행할 수 있다.　 또한, 처리 장치는 소프트웨어의 실행에 응답하여, 데이터를 접근, 저장, 조작, 처리 및 생성할 수도 있다.　 이해의 편의를 위하여, 처리 장치는 하나가 사용되는 것으로 설명된 경우도 있지만, 해당 기술분야에서 통상의 지식을 가진 자는, 처리 장치가 복수 개의 처리 요소(processing element) 및/또는 복수 유형의 처리 요소를 포함할 수 있음을 알 수 있다.　 예를 들어, 처리 장치는 복수 개의 프로세서 또는 하나의 프로세서 및 하나의 콘트롤러를 포함할 수 있다.　 또한, 병렬 프로세서(parallel processor)와 같은, 다른 처리 구성(processing configuration)도 가능하다.

소프트웨어는 컴퓨터 프로그램(computer program), 코드(code), 명령(instruction), 또는 이들 중 하나 이상의 조합을 포함할 수 있으며, 원하는 대로 동작하도록 처리 장치를 구성하거나 독립적으로 또는 결합적으로(collectively) 처리 장치를 명령할 수 있다.　 소프트웨어 및/또는 데이터는, 처리 장치에 의하여 해석되거나 처리 장치에 명령 또는 데이터를 제공하기 위하여, 어떤 유형의 기계, 구성요소(component), 물리적 장치, 가상 장치(virtual equipment), 컴퓨터 저장 매체 또는 장치에 구체화(embody)될 수 있다.　 소프트웨어는 네트워크로 연결된 컴퓨터 시스템 상에 분산되어서, 분산된 방법으로 저장되거나 실행될 수도 있다. 소프트웨어 및 데이터는 하나 이상의 컴퓨터 판독 가능 기록 매체에 저장될 수 있다.

실시예에 따른 방법은 다양한 컴퓨터 수단을 통하여 수행될 수 있는 프로그램 명령 형태로 구현되어 컴퓨터 판독 가능 매체에 기록될 수 있다.　 상기 컴퓨터 판독 가능 매체는 프로그램 명령, 데이터 파일, 데이터 구조 등을 단독으로 또는 조합하여 포함할 수 있다.　 상기 매체에 기록되는 프로그램 명령은 실시예를 위하여 특별히 설계되고 구성된 것들이거나 컴퓨터 소프트웨어 당업자에게 공지되어 사용 가능한 것일 수도 있다.　 컴퓨터 판독 가능 기록 매체의 예에는 하드 디스크, 플로피 디스크 및 자기 테이프와 같은 자기 매체(magnetic media), CD-ROM, DVD와 같은 광기록 매체(optical media), 플롭티컬 디스크(floptical disk)와 같은 자기-광 매체(magneto-optical media), 및 롬(ROM), 램(RAM), 플래시 메모리 등과 같은 프로그램 명령을 저장하고 수행하도록 특별히 구성된 하드웨어 장치가 포함된다.　 프로그램 명령의 예에는 컴파일러에 의해 만들어지는 것과 같은 기계어 코드뿐만 아니라 인터프리터 등을 사용해서 컴퓨터에 의해서 실행될 수 있는 고급 언어 코드를 포함한다.

이상과 같이 실시예들이 비록 한정된 실시예와 도면에 의해 설명되었으나, 해당 기술분야에서 통상의 지식을 가진 자라면 상기의 기재로부터 다양한 수정 및 변형이 가능하다.　 예를 들어, 설명된 기술들이 설명된 방법과 다른 순서로 수행되거나, 및/또는 설명된 시스템, 구조, 장치, 회로 등의 구성요소들이 설명된 방법과 다른 형태로 결합 또는 조합되거나, 다른 구성요소 또는 균등물에 의하여 대치되거나 치환되더라도 적절한 결과가 달성될 수 있다.

그러므로, 다른 구현들, 다른 실시예들 및 특허청구범위와 균등한 것들도 후술하는 특허청구범위의 범위에 속한다.

Claims (10)

1. 사용자 정의된 nvidia-도커(docker)에 명령이 전송되면, NVIDIA GPU 사용 옵션을 갖는 오리지널 도커에 명령이 리디렉션되는 단계;
   ConVGPU가 상기 NVIDIA GPU 와 통신 및 제어하여 CUDA 래퍼(wrapper) API 모듈을 컨테이너에 삽입하는 단계;
   컨테이너 런타임 중에 CUDA 래퍼 API 모듈이 일부 API를 캡처하여 GPU 메모리 스케줄러로 전송하는 단계; 및
   GPU 메모리 스케줄러가 컨테이너와 GPU 메모리 사용을 스케줄링하는 단계
   를 포함하는 GPU 메모리 자원 관리 및 스케줄링 방법.
2. 제1항에 있어서,
   상기 사용자 정의된 nvidia-도커(docker)에 명령이 전송되면, NVIDIA GPU 사용 옵션을 갖는 오리지널 도커에 명령이 리디렉션되는 단계는,
   컨테이너가 사용할 수 있는 최대의 GPU 메모리를 설정하기 위해 nvidia-도커를 사용자 정의하고, 컨테이너 내부의 호스트와 프로그램간 통신을 위해 ConVGPU에 UNIX 소켓을 적용하고, 공유 메모리 및 일반 파일 공유를 위한 옵션들을 제공하는
   GPU 메모리 자원 관리 및 스케줄링 방법.
3. 제1항에 있어서,
   상기 ConVGPU가 상기 NVIDIA GPU 와 통신하고 제어하여 CUDA 래퍼(wrapper) API 모듈을 컨테이너에 삽입하는 단계는,
   ConVGPU를 사용할 때 각 사용자 프로그램이 완전히 격리되도록 하고, 컨테이너의 정지 상태를 감지하기 위해, nvidia-도커를 사용하여 nvidia-도커-플러그인에 연결된 컨테이너에 더미 볼륨을 추가하는
   GPU 메모리 자원 관리 및 스케줄링 방법.
4. 제3항에 있어서,
   컨테이너의 실행이 종료되는 경우, 도커는 볼륨을 마운트 해제하여, nvidia-도커-플러그인이 컨테이너가 종료되었음을 확인하고, nvidia-도커-플러그인은 해당 컨테이너에 대한 스케줄러로 종료 신호를 전송하는
   GPU 메모리 자원 관리 및 스케줄링 방법.
5. 제1항에 있어서,
   컨테이너 런타임 중에 CUDA 래퍼 API 모듈이 일부 API를 캡처하여 GPU 메모리 스케줄러로 전송하는 단계는,
   CUDA 래퍼 API 모듈은 요청된 메모리 크기가 사용 가능한 경우에만 오리지널 CUDA API를 사용하여 메모리를 할당하고, 할당 후 CUDA 래퍼 API 모듈은 할당된 메모리 주소, 현재 pid 및 크기 정보를 GPU 메모리 스케줄러로 전송하여 GPU 메모리 사용을 추적하는
   GPU 메모리 자원 관리 및 스케줄링 방법.
6. 제1항에 있어서,
   상기 GPU 메모리 스케줄러가 컨테이너와 GPU 메모리 사용을 스케줄링하는 단계는,
   GPU 메모리 스케줄러는 컨테이너로부터 모든 GPU 메모리 할당을 수락, 일시 중지 또는 거부하도록 결정하고, 각 컨테이너에 UNIX 소켓을 생성하고 컨테이너에 삽입된 CUDA 래퍼 API 모듈과 통신하는
   GPU 메모리 자원 관리 및 스케줄링 방법.
7. 제6항에 있어서,
   사용자에 의해 컨테이너가 실행되기 전에, nvidia-도커는 해당 컨테이너의 고유 디렉토리 경로를 스케줄러에 요청하고, 스케줄러는 컨테이너와 볼륨을 공유하기 위한 디렉토리를 생성하여, 디렉토리 내에 UNIX 소켓을 구축하고, CUDA 래퍼 API 모듈을 디렉토리에 복사하는
   GPU 메모리 자원 관리 및 스케줄링 방법.
8. 제6항에 있어서,
   사용자 프로그램이 메모리 할당 API를 호출하면, CUDA 래퍼 API 모듈은 컨테이너에 준비된 UNIX 소켓을 통해 메모리 크기 정보를 GPU 메모리 스케줄러로 전송하고, GPU 메모리 스케줄러는 컨테이너에서 모든 메모리 할당 호출을 추적하는
   GPU 메모리 자원 관리 및 스케줄링 방법.
9. 제6항에 있어서,
   실행중인 컨테이너에서 GPU 메모리 크기가 충분하지 않은 경우, 요구되는 메모리 크기를 사용할 수 있을 때까지 GPU 메모리 스케줄러의 응답이 일시 중단되고, 해당 컨테이너에서 요청된 모든 메모리 할당은 스케줄러가 컨테이너에 GPU 메모리를 더 할당할 때까지 일시 중단되며, 일부 컨테이너의 실행이 완료되면 GPU 메모리 스케줄러가 점유된 GPU 메모리를 다른 컨테이너에 할당하는
   GPU 메모리 자원 관리 및 스케줄링 방법.
10. 명령이 전송되면, NVIDIA GPU 사용 옵션을 갖는 오리지널 도커에 명령을 리디렉션하는 사용자 정의된 nvidia-도커(docker);
    상기 NVIDIA GPU 와 통신 및 제어하여 CUDA 래퍼(wrapper) API 모듈을 컨테이너에 삽입하는 ConVGPU;
    컨테이너 런타임 중에 일부 API를 캡처하여 GPU 메모리 스케줄러로 전송하는 CUDA 래퍼 API 모듈; 및
    컨테이너와 GPU 메모리 사용을 스케줄링하는 GPU 메모리 스케줄러
    를 포함하는 GPU 메모리 자원 관리 및 스케줄링 시스템.

Images