KR102092458B1 - 서버리스 컴퓨팅 환경에서 가상화된 gpu 자원 지원 방법 및 시스템 - Google Patents

서버리스 컴퓨팅 환경에서 가상화된 gpu 자원 지원 방법 및 시스템 Download PDF

Info

Publication number
KR102092458B1
KR102092458B1 KR1020180070015A KR20180070015A KR102092458B1 KR 102092458 B1 KR102092458 B1 KR 102092458B1 KR 1020180070015 A KR1020180070015 A KR 1020180070015A KR 20180070015 A KR20180070015 A KR 20180070015A KR 102092458 B1 KR102092458 B1 KR 102092458B1
Authority
KR
South Korea
Prior art keywords
ironfunctions
client
server
docker
docker image
Prior art date
Application number
KR1020180070015A
Other languages
English (en)
Other versions
KR20190142837A (ko
Inventor
김대영
김재욱
전태준
강대연
김도현
Original Assignee
한국과학기술원
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by 한국과학기술원 filed Critical 한국과학기술원
Priority to KR1020180070015A priority Critical patent/KR102092458B1/ko
Publication of KR20190142837A publication Critical patent/KR20190142837A/ko
Application granted granted Critical
Publication of KR102092458B1 publication Critical patent/KR102092458B1/ko

Links

Images

Classifications

    • 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/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
    • G06F9/5011—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resources being hardware resources other than CPUs, Servers and Terminals
    • 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/44505—Configuring for program initiating, e.g. using registry, configuration files

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Stored Programmes (AREA)

Abstract

서버리스 컴퓨팅 환경에서 가상화된 GPU 자원 지원 방법 및 시스템이 제시된다. 본 발명에서 제안하는 서버리스 컴퓨팅 환경에서 가상화된 GPU 자원 지원 방법은 클라이언트로부터 IronFunctions 서버로 함수 파일 및 함수 정보를 전송하기 위해, 클라이언트에서 도커 이미지를 원격으로 전송하기 위한 API(Application Programming Interface)를 생성하는 단계, 클라이언트에서 도커 이미지 생성 요청에 의해 생성된 도커 이미지를 실행하는 단계 및 IronFunctions 서버의 요청을 처리하기 위한 API와 명령을 구현하고, 클라이언트에서 CLI(Common Language Infrastructure)를 통해 API를 호출하는 명령을 구현하는 단계를 포함한다.

Description

서버리스 컴퓨팅 환경에서 가상화된 GPU 자원 지원 방법 및 시스템{Method and System for supporting virtualized GPU resource in Serverless computing environment}
본 발명은 서버리스 컴퓨팅 환경에서 가상화된 GPU 자원 지원 방법 및 장치에 관한 것이다.
클라우드 컴퓨팅 환경에서, MSA(Micro Service Architecture)는 가상화를 위해 컨테이너를 사용하는 Docker의 출현으로 인해 점점 더 인기를 얻고 있다. 모놀리식(monolithic) 구조 대신 MSA로 환경을 배포하면 서비스 독립성, 격리 및 서비스 배포의 높은 가용성이 향상된다. 또한, 서버리스 컴퓨팅의 등장으로, 클라우드 환경의 MSA 서비스는 새로운 기능적 단위로 배포된다. 서비스가 기능적 단위로 구성된 경우, 가상 컴퓨터(VMs) 또는 컨테이너로 구성된 단위보다 작은 단위로 서비스를 구성할 수 있다. 서비스 배포 단위의 주된 이유는 전체 서비스의 크기가 증가하고 처리할 데이터의 양이 새로운 구조를 필요로 하여 구조가 모놀리식에서 마이크로 서비스로 변경되었기 때문이다.
한편, 처리할 데이터의 양이 증가함에 따라 GPU의 주된 목적이 변경되었다. 초기에, GPU는 고성능 그래픽 작업을 위해 개발되었다. 2000년 이래, GPU의 목적은 그래픽뿐만 아니라 일반적인 목적을 위해 변경되었다. 고성능 데이터 처리를 위해, 클라우드 컴퓨팅에서 GPU 활용을 다루는 몇 가지 연구가 존재한다. 예를 들어, rCUDA 및 vCUDA는 고성능 컴퓨팅(HPC)을 위한 GPU 가상화 프레임워크이다. 이러한 프레임워크들은 로컬 컴퓨팅 환경에서 GPU 리소스를 가상화하고 원격 컴퓨팅 환경에서 다수의 가상화된 리소스를 사용하여 분산 프로세싱을 가능하게 한다. 결과적으로, 이러한 프레임워크들은 다수의 가상화된 원격 GPU를 사용하는 분산 프로세싱을 통해 많은 작업에 대한 속도를 높이는 데 사용된다. 그러나 이러한 프레임워크들은 실제로 사용하기가 불편하다. 많은 구성 프로세스와 복잡한 빌드 프로세스가 존재하기 때문이다. 이러한 환경을 지역적으로 사용하기 위해, 로컬 환경의 사용자는 원격 CUDA API를 호출하고 요청을 원격으로 전송 및 수신하는 복잡한 네트워크를 구성하는 CUDA 런타임 wrapper 라이브러리를 설치해야 한다. 또한, 이러한 프레임워크들은 런타임 wrapper 라이브러리를 사용하기 때문에 CUDA의 최신 버전으로 제한된다. 로컬 환경 사용자가 rCUDA에서 최신 CUDA 버전 API를 사용하려는 경우, 이 사용자는 해당 버전에 대한 새로운 CUDA 런타임 wrapper 라이브러리를 사용하여 이를 재구성해야 한다. 로컬 환경에 가상화된 GPU 리소스를 제공하는 원격 환경은 유사하게 복잡한 프로세스를 거쳐야 한다. 로컬 및 원격 환경 모두에서 GPU 사용을 위해 통신하는 프로세스는 복잡하며 많은 오버헤드를 포함한다.
현재, 클라우드 환경에서 GPU를 사용하여 서비스를 개발하고 배포하려는 사용자는 일반적인 방법으로 클라우드 컴퓨팅 서비스 공급자(Amazon AWS, Microsoft Azure 등)으로부터 GPU 인스턴스를 구매하고 있다. 또한, 인스턴스를 구입한 후에는 GPU 지원을 위해 VM에 드라이버, 라이브러리를 설치해야 하는데, 이는 쉬운 과정이 아니다. 서버리스 컴퓨팅 환경에서는 개발 및 배포 구성 프로세스가 거의 존재하지 않으며, 주어진 환경에서 서비스 개발 및 배포가 용이하다. 따라서 서버리스 컴퓨팅 환경에서 GPU를 활성화(지원)하는 방법을 제안한다. 이 방법을 사용하면, 사용자는 클라우드 환경에서 GPU를 사용하는 서비스를 쉽게 개발하고 배포할 수 있다. 현재, 다양한 서버리스 프레임워크가 존재한다. AWS Lambda는 서버리스 컴퓨팅에서 가장 널리 사용되는 프레임워크이다. Amazon은 마이크로소프트의 Azure Function의 업워드(upward)인 AWS Lambda를 출시하고 서비스하였으며, 구글은 구글 클라우드 Function을 출시하였다. 오픈 소스 측면에는 IBM의 오픈 위스크(OpenWhisk)와 iron.io의 IronFunctions가 존재한다. 그러나 이러한 프레임워크들은 GPU 프로그래밍을 지원하지 않는다. 서버리스 컴퓨팅에서 GPU를 구현하는 핵심적인 방법은 NVIDIA-도커를 사용하여 컨테이너 기반 서비스를 구현하는 것이다. NVIDIA-도커는 GPU 지원 도커 컨테이너를 실행하기 위해 개발되었다. NVIDIA-도커 전에 GPU 지원 컨테이너를 실행하는 것은 어려우며 불안정하다. NVIDIA-도커는 도커의 미들웨어이다. NVIDIA-도커가 컨테이너를 생성할 때. NVIDIA-도커는 로컬 환경에서 CUDA 장치, 볼륨 및 라이브러리의 정보를 검색하고, 이러한 정보를 가지는 컨테이너를 생성한다. 이렇게 하면 컨테이너가 GPU를 인식할 수 있다. GPU 지원 컨테이너를 이용하면, 서버리스 컴퓨팅 환경에서 GPGPU를 이용하여 고성능 마이크로 서비스를 배포할 수 있다. 이 서비스가 GPU를 사용하여 사용자 요청을 처리하는 경우, 처리 속도가 기존 처리 방법인 CPU에 의해 처리하는 방법에 비해 빠르기 때문에 사용자에게 고성능 서비스를 제공할 수 있다.
본 발명이 이루고자 하는 기술적 과제는 IronFunctions(아이론 펑션)과 NVIDIA-도커(Docker)를 연결하기 위한 아이론 기능의 새로운 시스템 구조를 설계하였으며, 프레임워크 사용자가 GPU를 두 가지 목적으로 사용할 수 있도록 하는 API와 명령을 구현하였다. 첫 번째 목적은 PyCuDA를 사용하여 파이선(Python) 기반 고성능 서비스를 배포하는 것이다. 두 번째 목적은 로컬 GPU가 존재하지 않는 머신에서 원격 시스템 GPU를 사용하여 심층 학습 코드를 실행하는 것이다.
일 측면에 있어서, 본 발명에서 제안하는 서버리스 컴퓨팅 환경에서 가상화된 GPU 자원 지원 방법은 클라이언트로부터 IronFunctions 서버로 함수 파일 및 함수 정보를 전송하기 위해, 클라이언트에서 도커 이미지를 원격으로 전송하기 위한 API(Application Programming Interface)를 생성하는 단계, 클라이언트에서 도커 이미지 생성 요청에 의해 생성된 도커 이미지를 실행하는 단계 및 IronFunctions 서버의 요청을 처리하기 위한 API와 명령을 구현하고, 클라이언트에서 CLI(Common Language Infrastructure)를 통해 API를 호출하는 명령을 구현하는 단계를 포함한다.
상기 클라이언트로부터 IronFunctions 서버로 함수 파일 및 함수 정보를 전송하기 위해, 클라이언트에서 도커 이미지를 원격으로 전송하기 위한 API를 생성하는 단계는 도커 이미지를 가져오기 위해 도커 허브에 로그인을 필요로 하지 않고, 도커 이미지를 출력하는 데 시간이 소요되지 않는다.
상기 클라이언트에서 도커 이미지 생성 요청에 의해 생성된 도커 이미지를 실행하는 단계는 도커 허브로부터 도커 이미지를 출력하는 과정을 필요로 하지 않고, IronFunctions 서버가 함수 호출을 수신하는 즉시 상기 클라이언트에서 도커 이미지 생성 요청에 의해 생성된 도커 이미지를 실행한다.
상기 IronFunctions 서버의 요청을 처리하기 위한 API와 명령을 구현하고, 클라이언트에서 CLI를 통해 API를 호출하는 명령을 구현하는 단계는 데이터 세트가 클라이언트 PC에 존재하는 경우 트레이닝 및 데이터 세트를 사용하여 심층 학습 코드를 실행하기 위해 데이터 세트를 IronFunctions 서버로 전송하고, 미리 정의된 명령을 이용하여 FTP(File Transfer Protocol) 프로토콜을 실행하여 파일을 IronFunctions 서버로 전송한다.
IronFunctions 서버의 IronFunctions은 컨테이너 구조를 갖고, 영구적으로 작동하는 컨테이너는 존재하지 않으며 IronFunctions 서버가 이벤트를 수신할 때 컨테이너를 즉시 생성하고, IronFunctions의 실행이 종료되면 컨테이너가 종료되어 컨테이너에는 데이터 세트가 존재하지 않는다.
또 다른 일 측면에 있어서, 본 발명에서 제안하는 서버리스 컴퓨팅 환경에서 가상화된 GPU 자원 지원 시스템은 클라이언트로부터 IronFunctions 서버로 함수 파일 및 함수 정보를 전송하기 위해, 클라이언트에서 도커 이미지를 원격으로 전송하기 위한 API를 생성하고, 클라이언트에서 도커 이미지 생성 요청에 의해 생성된 도커 이미지를 실행하는 IronFunctions 서버 및 IronFunctions 서버의 요청을 처리하기 위한 API와 명령을 구현하고, 클라이언트에서 CLI를 통해 API를 호출하는 명령을 구현하는 클라이언트를 포함한다.
본 발명의 실시예들에 따르면 rCUDA 및 vCUDA와 같은 가상화를 가지는 원격 GPU를 사용하는 대신, 원격 GPU는 사용자로부터 수신된 요청을 실행하고 그 실행 결과를 반환하므로, GPU 리소스는 복잡한 설치 및 설정 절차 없이 원격 사용자에게 제공될 수 있다. 이러한 구조와 명령을 참조하면, IronFunctions 이외의 컨테이너를 기반으로 기능을 배포하는 다른 서버리스 컴퓨팅 프레임워크에서 GPU를 사용하도록 프레임워크를 조정할 수 있다.
도 1은 본 발명의 일 실시예에 따른 IronFunctions의 전체 다이어그램이다.
도 2는 본 발명의 일 실시예에 따른 전체 시스템 설계를 나타내는 도면이다.
도 3은 본 발명의 일 실시예에 따른 IronFunctions 및 NVIDIA-도커가 도커 서버와 독립적으로 연결되는 과정을 설명하기 위한 도면이다.
도 4는 본 발명의 일 실시예에 따른 IronFunctions의 구조를 나타내는 도면이다.
도 5는 본 발명의 일 실시예에 따른 서버리스 컴퓨팅 환경에서 가상화된 GPU 자원 지원 방법을 설명하기 위한 흐름도이다.
도 6은 본 발명의 일 실시예에 따른 IronFunctions 배포 과정을 설명하기 위한 도면이다.
도 7은 본 발명의 일 실시예에 따른 이이론 펑션 호출 과정을 설명하기 위한 도면이다.
도 8은 본 발명의 일 실시예에 따른 IronFunctions의 컨테이너 구조를 나타내는 도면이다.
새로운 형태의 클라우드 컴퓨팅인 서버리스 컴퓨팅은 마이크로 서비스 구조를 설계하는 새로운 방법으로 주목 받고 있다. 서버리스 컴퓨팅 환경에서 서비스는 서비스 기능 단위로 개발된다. 현재 모든 서버리스 컴퓨팅 프레임워크의 기능 개발 환경은 CPU 기반이다. 본 발명에서는 CPU를 사용하는 기존의 서버리스 컴퓨팅 프레임워크보다 빠른 서비스 배치가 가능한 GPU 지원 서버리스 컴퓨팅 프레임워크를 제안한다. 핵심적인 방법은 오픈 소스 서버리스 컴퓨팅 프레임워크를 NVIDIA-도커(Docker)와 통합하고 GPU 지원 컨테이너를 기반으로 서비스를 배포하는 것이다. 본 발명에서는 오픈 소스 프레임워크를 NVIDIA-도커에 연결하는 API(Application Programming Interface)와 GPU(Graphics Processing Unit) 프로그래밍을 가능하게 하는 명령을 개발하였다. 실험을 통해 다양한 환경에서 이 프레임워크의 성능을 측정하였다. 결과적으로 프레임워크를 통해 서비스를 개발하려는 개발자는 고성능 마이크로 서비스를 배포 할 수 있으며, GPU 환경 없이 심층 학습 프로그램을 실행하려는 개발자는 성능 저하가 거의 없는 원격 GPU에서 코드를 실행할 수 있게 된다. 이하, 본 발명의 실시 예를 첨부된 도면을 참조하여 상세하게 설명한다.
본 발명의 실시예에 따르면, 다양한 오픈 소스 서버리스 컴퓨팅 프레임워크를 조사하여 'IronFunctions' 프레임워크를 선택한다. 이러한 결정에는 몇 가지 이유가 존재한다. 첫째, 이 프레임워크는 컨테이너를 기반으로 사용자가 생성한 함수를 배포한다. 따라서 NVIDIA 도커를 GPU 사용 방법으로 사용하는 본 발명에서 제안하는 방법을 적용하기 용이하다. 둘째, 오픈 스택(Open Stack)의 공식 프로젝트 중 하나인 오픈 스택 피카소(Open Stack Picasso)는 IronFunctions을 기반으로 개발되었다. 따라서 이 방법을 오픈 스택으로 확장하는 것이 용이하다.
본 발명에서는 IronFunctions 개선을 통한 GPU 지원 서버리스 프레임워크를 제안한다. 여기서 IronFunctions과 NVIDIA-도커를 연결하기 위한 IronFunctions의 새로운 시스템 구조를 설계하였으며, 프레임워크 사용자가 GPU를 두 가지 목적으로 사용할 수 있도록 하는 API와 명령을 구현한다. 첫 번째 목적은 PyCuDA를 사용하여 파이선(Python) 기반 고성능 서비스를 배포하는 것이다. 두 번째 목적은 로컬 GPU가 존재하지 않는 머신에서 원격 시스템 GPU를 사용하여 심층 학습 코드를 실행하는 것이다. rCUDA 및 vCUDA와 같은 가상화를 가지는 원격 GPU를 사용하는 대신, 원격 GPU는 사용자로부터 수신된 요청을 실행하고 그 실행 결과를 반환한다. 따라서 GPU 리소스는 복잡한 설치 및 설정 절차 없이 원격 사용자에게 제공될 수 있다. 이러한 구조와 명령을 참조하면, IronFunctions 이외의 컨테이너를 기반으로 기능을 배포하는 다른 서버리스 컴퓨팅 프레임워크에서 GPU를 사용하도록 프레임워크를 조정할 수 있다. 이 연구에서 제안된 프레임워크의 성능은 세 가지 실험에 의해 평가된다. 첫 번째 실험은 서버리스 컴퓨팅 환경에서 CPU와 GPU 기반 서비스의 실행 시간을 비교하는 것이다. 두 번째 실험은 로컬 PC에 GPU가 갖춰지지 않은 환경에서 서버리스 컴퓨팅 프레임워크를 통해 원격 GPU를 사용하는 서비스의 실행 시간과 GPU가 갖춰진 로컬 PC에서 서비스의 실행 시간을 비교하는 것이다. 세 번째 실험은 1G-BPS와 10G-BPS의 두 네트워크 환경에서 프레임워크의 실행 시간을 비교하는 것이다. 이러한 실험은 고성능을 위해 서버리스 환경에서 GPU를 사용하는 방법의 우월성을 보여준다.
도 1은 본 발명의 일 실시예에 따른 IronFunctions의 전체 다이어그램이다.
서버리스 컴퓨팅은 클라우드의 이벤트 중심 응용 프로그램 설계 및 배포 패러다임이다. 서버리스 컴퓨팅은 기능별로 서비스를 설계, 개발 및 배치하기 때문에 "서비스로서의 기능(FaaS; functions as a Service)"이라고도 불리 운다. '서버리스'라는 용어의 의미는 개발자 및 운영자가 서버 상태 또는 서버 환경을 관리하거나 우려 할 서버가 존재하지 않는다는 것이다. 서버리스 컴퓨팅을 서비스의 클라우드 구조에 적용하는 구조를 서버리스 구조라고 한다. 서버리스 컴퓨팅은 클라우드 컴퓨팅에서 엄청난 주목을 받고 있다. 또한 2017년 Gartner의 10가지 기술 동향에서도 소개되었다. 전통적인 서비스 설계 프로세스에서 OS, VM 사양 선택 및 개발 환경 구성을 선택하여 클라우드 컴퓨팅의 개발 및 배포가 시작된다.
본 발명의 실시예에 따르면 서비스의 코드를 구현한 후, 이를 배포한다. 배포 후, 서비스 운영자는 VM 상태 및 네트워크 상태를 모니터링하고 관리해야 한다. 그러나 서버리스 컴퓨팅 환경에서, 서비스 개발자는 구성 및 설치없이 서버리스 컴퓨팅 프레임워크에 서비스 코드를 작성한다. 코드를 작성한 후에는, VM의 모든 것에 대해 구성할 필요가 없으므로 서비스 개발자는 복잡하지 않은 서비스를 배치한다. 서비스 개발자들은 단지 Rest API를 만들고 작성된 코드와 연결한다. 연결 후, 서비스 사용자는 Rest API를 통해 제안하는 서비스에 액세스한다. 지불 정책에 관해서, 서버리스 컴퓨팅 환경에서는 아이들(idle) 시간과 다운 타임에 대한 비용이 들지 않는다. 서버리스 컴퓨팅 환경은 서비스 사용률에 비례한 지불 정책을 가진다. 따라서 서버리스 컴퓨팅의 탄력적인 비용 정책으로 인해 비용을 절약할 수 있다. McGrath 등은 보다 세분화된 수준(예를 들어, 함수 당 HTTP 요청)으로 마이크로 서비스를 배포하기 위해 독점적으로 설계된 AWS Lambda와 같은 새로운 클라우드 서비스를 사용하여 기업이 인프라 비용을 최대 77.08%까지 줄일 수 있음을 보여준다.
IronFunctions은 오픈 소스 서버리스 컴퓨팅 프레임워크이다. 이것은 'iron.io'에 의해 만들어졌으며, 클라이언트와 서버 양 측면에서 오픈 소스에 해당한다(예를 들어, Apache 2.0 라이센스). 이것은 액티브(active) 오픈 소스 프로젝트이다.
도 1은 IronFunctions의 전체 다이어그램을 보여준다. 여기서 IronFunctions 클라우드 서버(IronFunctions Cloud Server)(110)를 '서버'로 간략히 지칭한다. 서버가 이벤트 및 트리거(120)를 HTTP REST API(121)로부터 이벤트 요청을 받거나 오픈스택(OpenStack)(122)로부터 알람 트리거를 받으면, 도커 허브(130)에서 이미지를 가져와 도커 이미지로 도커 컨테이너(140)를 실행한다. 서비스 개발자가 배치 기능을 원하는 경우, 서비스 개발자는 코드 파일을 도커 이미지에 패키지화하여 도커 서브에 푸시한다. 따라서 도커와 도커 허브는 IronFunctions의 중요한 구성 요소이다. IronFunctions은 Go 언어로 개발되었으며 IronFunctions에서 지원하는 개발 언어인 Python2, Node.js, DotNet, GO, Ruby, Rust 및 Lambda Node를 런타임 언어(150)로 지원한다. 서비스 개발자는 해당 언어로 기능을 구현하고 배포할 수 있다. 또한, IronFunctions은 비동기 호출(asynchronous call) 및 로드 밸런싱(load balancing)을 지원한다. IronFunctions은 설치하기 쉽고 IBM 오픈 위스크와 같은 다른 오픈 소스 서버리스 컴퓨팅 프레임워크와 달리 간단한 시스템 구조를 가지고 있다. 또한, 중요한 기능은 오픈 스택(OpenStack) API를 지원한다는 것이다. 오픈 스택은 API를 사용하여 IronFunctions에 알람 트리거를 발생시킨다. 예를 들어, VM이 오픈 스택 CPU 임계 값의 특정 퍼센트 이상인 경우, IronFunctions에 이벤트를 호출한다. IronFunctions은 오픈 스택 Picasso의 주요 구성 요소이다. 따라서 IronFunctions을 개선하여 Picasso 프로젝트를 개선시킬 수 있다. 결과적으로, 오픈 스택 환경에서 GPU 지원 서버리스 구조를 설계할 수 있다.
도 2는 본 발명의 일 실시예에 따른 전체 시스템 설계를 나타내는 도면이다.
본 발명의 일 실시예에 따른 프레임워크는 클라이언트-서버 분산 구조로 구성되었다.
서버리스 컴퓨팅 환경에서 가상화된 GPU 자원 지원 시스템은 클라이언트로부터 IronFunctions 서버로 함수 코드 파일 및 함수 정보를 전송하기 위해, 클라이언트에서 도커 이미지를 원격으로 전송하기 위한 API를 생성하고, 클라이언트에서 도커 이미지 생성 요청에 의해 생성된 도커 이미지를 실행하는 IronFunctions 서버(230) 및 IronFunctions 서버의 요청을 처리하기 위한 API와 명령을 구현하고, 클라이언트에서 CLI를 통해 API를 호출하는 명령을 구현하는 클라이언트(210)를 포함한다.
상기 IronFunctions 서버(230)는 도커 이미지를 가져오기 위해 도커 허브에 로그인을 필요로 하지 않고, 도커 이미지를 출력하는 데 시간이 소요되지 않는다.
IronFunctions 서버(230)는 도커 허브로부터 도커 이미지를 출력하는 과정을 필요로 하지 않고, IronFunctions 서버가 함수 호출을 수신하는 즉시 상기 클라이언트에서 도커 이미지 생성 요청에 의해 생성된 도커 이미지를 실행한다.
상기 클라이언트(210)는 데이터 세트가 클라이언트 PC에 존재하는 경우 트레이닝 및 데이터 세트를 사용하여 심층 학습 코드를 실행하기 위해 데이터 세트를 IronFunctions 서버로 전송하고, 미리 정의된 명령을 이용하여 FTP 프로토콜을 실행하여 파일을 IronFunctions 서버로 전송한다.
IronFunctions 서버(230)의 IronFunctions은 컨테이너 구조를 갖고, 영구적으로 작동하는 컨테이너는 존재하지 않으며 IronFunctions 서버가 이벤트를 수신할 때 컨테이너를 즉시 생성하고, IronFunctions의 실행이 종료되면 컨테이너가 종료되어 컨테이너에는 데이터 세트가 존재하지 않는다.
도 2는 제안하는 프레임워크의 개요이다. 함수 생성 및 배포의 경우 IronFunctions 클라이언트(210) 및 IronFunctions 서버(230)를 사용한다. 서버(230)의 모든 요청은 HTTP REST API(220)에 의해 처리된다. 서버리스 환경에서 GPU(241, 242)를 사용하는 두 가지 경우에 대한 프레임워크를 설계하였다.
하나는 GPU가 고성능 마이크로 서비스를 배포하는 데 사용하는 것이다. 이 프레임워크에서, 마이크로 서비스는 CUDA를 사용하여 CPU 대신 GPU를 기반으로 서비스를 배치함으로써 서비스의 성능을 향상시키는 서비스로 정의된다.
다른 하나는 원격 GPU를 사용하여 심층 학습 코드를 실행하는 것이다. 개발자(250)는 IronFunctions 클라이언트(210)에 코맨드를 입력(271)할 수 있다. 개발자(250)는 심층 학습 코드를 서버에 전송하고, 다시 말해 함수 호출(Function Call)(272)을 전송하고, 그 수행 결과를 서비스 사용자(260)에게 반환(273)한다. 이러한 모든 경우, 개발자는 원격 GPU를 사용하여 코드의 실행 결과를 신속하게 가져올 수 있다.
도 3은 본 발명의 일 실시예에 따른 IronFunctions 및 NVIDIA-도커가 도커 서버와 독립적으로 연결되는 과정을 설명하기 위한 도면이다.
본 발명의 일 실시예에 따른 프레임워크는 NVIDIA-도커(310)와 결합된 IronFunctions(320)을 사용하여 개발되었다. IronFunctions의 주요 구성 요소는 'Fn'(321), 'Functions'(322), 'Runner'(323) 및 'go dockerclient'(324)이다. Fn 구성 요소는 IronFunctions의 클라이언트(325)인데, IronFunctions 요청 기능이며 CRUD(생성, 읽기, 업데이트, 삭제)를 서버(326)에 라우팅한다. 이 기능은 서비스로 배포하려는 개발자를 위한 소스 코드이다. 라우트는 생성된 함수를 소켓(socket) REST API, 다시 말해 HTTP REST API(351)로 실행하기 위한 API이다. Functions(322) 구성 요소는 클라이언트(325)로부터 이러한 요청을 수신하여 처리한다. go-dockerclient(324) 구성 요소는 도커 원격 API 용 클라이언트를 제공한다. 또한, go-dockerclient(324) 구성 요소는 Swarm API의 확장 기능을 지원하므로 IronFunctions이 도커 Swarm을 쉽게 사용할 수 있다. Runner(323) 구성 요소는 접속 기능과 go-dockerclient(324)를 연결하는 인터페이스 모음이다. NVIDIA-도커(310)에는 '볼륨(Volume)'(311) 및 '드라이버(Driver)'(312) 구성 요소가 존재한다. 이 구성 요소들은 로컬 컴퓨팅 환경에서 CUDA 드라이버 및 라이브러리(330)를 로드한다. 그런 다음, CUDA 정보를 도커 클라이언트(340)로 전송한다. 이후, 도커 클라이언트(340)가 도커 서버(350)의 GPU에 연결할 수 있는 컨테이너를 생성하도록 요청한다. 도 3은 IronFunctions, NVIDIA-도커가 어떻게 도커 서버와 독립적으로 연결되는지를 보여준다. 이이론 펑션은 go-dockerclient를 사용하는 반면, NVIDIA-도커는 표준 도커 클라이언트를 사용한다. 따라서 도커 클라이언트를 위해 go-dockerclient와 표준 도커 클라이언트 중 하나를 선택해야 한다. IronFunctions을 수정하는 것은 NVIDIA-도커를 수정하는 것보다 복잡하므로, 제안하는 프레임워크에는 godockerclient를 사용한다.
도 4는 본 발명의 일 실시예에 따른 IronFunctions의 구조를 나타내는 도면이다.
도 4는 본 발명의 또 다른 실시예에 따른 IronFunctions의 구조를 보여준다. IronFunctions의 주요 구성 요소는 'Fn'(411), 'Functions'(412), 'Runner'(413) 및 'go dockerclient'(414)이다. Fn 구성 요소는 IronFunctions의 클라이언트(415)인데, IronFunctions 요청 기능이며 CRUD(생성, 읽기, 업데이트, 삭제)를 서버(416)에 라우팅한다. 이 기능은 서비스로 배포하려는 개발자를 위한 소스 코드이다. 라우트는 생성된 함수를 소켓(socket) REST API, 다시 말해 HTTP REST API(441)로 실행하기 위한 API이다. Functions(412) 구성 요소는 클라이언트(415)로부터 이러한 요청을 수신하여 처리한다. go-dockerclient(414) 구성 요소는 도커 원격 API 용 클라이언트를 제공한다. 또한, go-dockerclient(414) 구성 요소는 Swarm API의 확장 기능을 지원하므로 IronFunctions이 도커 Swarm을 쉽게 사용할 수 있다. Runner(413) 구성 요소는 접속 기능과 go-dockerclient(414)를 연결하는 인터페이스 모음이다.
NVIDIA-도커(420)와 연결하기 위해 IronFunctions의 함수 구성 요소에 '볼륨(Volumes)'(421), 드라이버(422) 및 'Devices' API를 구현하였다. 예를 들어, 소켓(Socket) REST API(441)를 통해, IronFunctions이 go-dockerclient(414) 구성 요소를 호출하여 도커 서버(440)의 도커 컨테이너를 생성하면, 서버 머신의 CUDA 드라이버와 라이브러리(430)를 함께 호출하여 GPU 지원 도커 컨테이너를 생성한다. 마지막으로, 표준 도커 클라이언트 IronFunctions(Docker Client IronFunctions)이 없으면 GPU 지원 도커 컨테이너를 생성할 수 있다.
도 5는 본 발명의 일 실시예에 따른 서버리스 컴퓨팅 환경에서 가상화된 GPU 자원 지원 방법을 설명하기 위한 흐름도이다.
제안하는 서버리스 컴퓨팅 환경에서 가상화된 GPU 자원 지원 방법은 클라이언트로부터 IronFunctions 서버로 함수 파일 및 함수 정보를 전송하기 위해, 클라이언트에서 도커 이미지를 원격으로 전송하기 위한 API(Application Programming Interface)를 생성하는 단계(510), 클라이언트에서 도커 이미지 생성 요청에 의해 생성된 도커 이미지를 실행하는 단계(520) 및 IronFunctions 서버의 요청을 처리하기 위한 API와 명령을 구현하고, 클라이언트에서 CLI(Common Language Infrastructure)를 통해 API를 호출하는 명령을 구현하는 단계(530)를 포함한다.
단계(510)에서 도커 이미지를 가져오기 위해 도커 허브에 로그인을 필요로 하지 않고, 도커 이미지를 출력하는 데 시간이 소요되지 않는다.
단계(520)에서 도커 허브로부터 도커 이미지를 출력하는 과정을 필요로 하지 않고, IronFunctions 서버가 함수 호출을 수신하는 즉시 상기 클라이언트에서 도커 이미지 생성 요청에 의해 생성된 도커 이미지를 실행한다.
단계(530)에서 데이터 세트가 클라이언트 PC에 존재하는 경우 트레이닝 및 데이터 세트를 사용하여 심층 학습 코드를 실행하기 위해 데이터 세트를 IronFunctions 서버로 전송하고, 미리 정의된 명령을 이용하여 FTP(File Transfer Protocol) 프로토콜을 실행하여 파일을 IronFunctions 서버로 전송한다.
IronFunctions 서버의 IronFunctions은 컨테이너 구조를 갖고, 영구적으로 작동하는 컨테이너는 존재하지 않으며 IronFunctions 서버가 이벤트를 수신할 때 컨테이너를 즉시 생성하고, IronFunctions의 실행이 종료되면 컨테이너가 종료되어 컨테이너에는 데이터 세트가 존재하지 않는다.
도 6은 본 발명의 일 실시예에 따른 IronFunctions 배포 과정을 설명하기 위한 도면이다.
IronFunctions은 도커 이미지를 사용하여 기능을 배포한다. IronFunctions은 도커 허브를 사용하여 호스트 환경 도커 이미지를 원격 환경으로 전송한다. 도 6은 기능 배포의 순서를 설명한다.
도 6a는 표준 IronFunctions 배포 프로세스이다. 표준 IronFunctions 배포 프로세스는 도커 허브에 로그인하는 단계(610a), 함수 파일을 생성하는 단계(620a), yaml 파일을 생성하는 단계(630a), 도커 이미지를 생성하는 단계(640a), 도커 허브에 이미지를 입력하는 단계(650a) 및 앱 및 API 종료 지점을 생성하는 단계(660a)를 포함한다.
이 프로세스에서, 가장 많은 시간이 소요되는 단계는 '도커 허브에 이미지를 입력하는 단계(650a)'이다. 따라서 해당 단계(650a) 프로세스를 제외할 것을 제안한다. 이 단계에서, 도커 허브는 클라이언트에서 서버로 도커 이미지만을 전송하므로 서버가 이미지를 생성하기 위해 클라이언트로부터 필요한 정보를 수신하는 경우 도커 허브를 필요로 하지 않는다.
도 6b는 표준 프로세스와 비교하여 수정된 세 가지 프로세스 단계를 나타낸다. 수정된 프로세스는 함수 파일을 생성하는 단계(610b), yaml 파일을 생성하는 단계(620b), 도커 이미지 원격 생성 단계(630b) 및 앱 및 API 종료 지점을 생성하는 단계(640b)를 포함한다.
수정된 프로세스에서 도커 허브를 제외하였으므로, 허브에 로그인하여 허브에 이미지를 가져올 필요가 없다. 도커 허브를 거치지 않고 클라이언트로부터 서버로 기능 파일 및 기능 정보를 전송하기 위해, 서버에서 도커 이미지를 생성하기 위한 API를 직접 구현한다. 결과적으로, 이러한 구현은 도커 허브에 로그인 할 필요가 없어지고 도커 이미지를 출력하는 데 많은 시간이 소요되지 않는다. 함수를 배포하는 데 소요되는 시간을 측정하는 실험에서, 표준 IronFunctions 프로세스(도 6a)에서 측정 시간은 약 5분 32초이다. 그러나 수정된 프로세스(도 6b)에서의 측정 시간은 1.3초이다. 이 실험에서, 출력하는 데 소용되는 시간은 5분 31초로 기록되었다. 따라서 '도커 허브에 이미지를 입력하는 단계'를 생략하여 성능을 향상시킬 수 있다. 이 실험은 약 3.5GB의 이미지 크기를 갖는 텐서플로우 도커(TensorFlow Docker) 이미지를 사용하여 수행되었다.
도 7은 본 발명의 일 실시예에 따른 이이론 펑션 호출 과정을 설명하기 위한 도면이다.
도커 허브는 기능 호출에도 사용된다. 도 7a는 표준 IronFunctions 호출 프로세스이다. 표준 IronFunctions 호출 프로세스는 함수 호출 요청 수신 단계(710a), 도커 허브로부터 도커 이미지 출력 단계(720a), 도커 이미지 실행(730a), 수행 결과 반환 단계(740a)를 포함한다.
IronFunctions 서버 측에서 이벤트 또는 트리거를 수신할 때 서버에 적용 가능한 이벤트 또는 트리거인 도커 이미지가 존재하지 않는 경우, IronFunctions 서버는 도커 허브로부터 도커 이미지를 가져올 것이다. 그러나 이미지 크기가 커지면 이미지를 가져오는 데 오랜 시간이 소요된다.
도 7b는 수정된 함수 호출 프로세스를 보여준다. 수정된 함수 호출 프로세스는 함수 콜 요청 수신 단계(710b), 도커 이미지 실행(720b), 수행 결과 반환 단계(730b)를 포함한다.
이 프로세스에서는 클라이언트에서 도커 이미지를 생성하라는 요청에 의해 생성된 도커 이미지가 있기 때문에 도커 허브로부터 이미지를 출력하는 단계(720a)가 필요하지 않다. 따라서 서버가 함수 호출을 수신하면, 즉시 도커 이미지를 실행한다. 결과적으로, 함수 호출 성능이 향상된다.
마지막으로 명령 구현 단계에서는, IronFunctions은 서비스 배포 프로세스에서 도커 허브를 제외하고 GPU를 사용하여 서비스를 배포하기 위해 새로운 API 및 명령을 필요로 한다. 따라서 서버의 요청을 처리하기 위한 API와 명령을 구현하였으며 프레임워크의 클라이언트에서 CLI를 통해 API를 호출하는 명령을 구현하였다.
fn 명령은 IronFunctions 클라이언트 CLI이다. 표준에서 IronFunctions은 fn build 명령을 가진다. 이는 서버에 배포하기 위한 기능 파일이 포함된 도커 이미지를 생성하는 것을 의미한다. fn build 및 fn build --remote 명령은 각각 도 6a, 도 6b에 해당한다. 개발자가 fn build를 사용하면, 로컬 환경에 도커 이미지를 생성한다. 따라서 개발자는 이미지를 도커 허브에 푸시하여 이미지를 서버로 전송한다. 그러나 fn build --remote는 로컬이 아닌 서버에서 직접 이미지를 생성하는 데 사용된다. 클라이언트는 멀티파트(Multipart)를 갖는 HTTP POST API를 통해 클라이언트의 기능 파일을 서버로 전송하고, 서버는 이 파일을 포함하는 도커 이미지를 생성한다.
fn create 명령은 기능 정보가 포함된 파일을 생성한다. 표준 IronFunctions에는 파일에 포함된 기능 정보를 생성하는 fn init 명령이 존재한다. 이 명령을 사용하면, 파일에 GPU를 사용하는 목적이 포함되지 않는다. 파일에 GPU 사용 목적이 포함되도록 하기 위해, fn create 명령을 구현한다. 이 명령에는 gpgpu 옵션이 존재한다. 이 옵션에는 네 가지 옵션이 존재한다. 하나는 pycuda 라이브러리를 Python 언어의 cuda 프로그래밍에 사용하는 pycuda이고, 다른 하나는 심층 학습 프레임워크를 선택하는 옵션이다. Theano, TensorFlow 및 Torch의 세 가지 프레임워크가 존재한다. Theano 및 TensorFlow는 Python 기반 프레임워크이며, IronFunctions은 기본적으로 Python을 런타임 언어로 지원한다. 그러나 Torch는 Lua 언어를 기반으로 하는 프레임워크이며, IronFunctions은 Lua를 런타임 언어로 지원하지 않는다. 따라서 Lua를 런타임으로 지원하기 위한 추가 구현을 구현하였다.
도 8은 본 발명의 일 실시예에 따른 IronFunctions의 컨테이너 구조를 나타내는 도면이다.
본 발명의 실시예에 따르면, 서버로 파일을 업로드하기 위해 fn fileupload 명령을 구현하였다. 심층 학습을 위해, 트레이닝 및 테스트 데이터 세트를 사용하는 경우가 많이 존재한다. 데이터 세트가 클라이언트 PC에 존재하는 경우, 이러한 데이터 세트를 사용하여 심층 학습 코드를 실행하려면 이러한 데이터 세트를 서버로 전송해야 한다. fileupload 명령은 FTP 프로토콜을 실행하여 파일을 서버로 전송한다. 또한, 컨테이너의 구조를 재설계하였다. 도 8은 새로운 컨테이너 구조를 보여준다. 기본적으로, IronFunctions은 간단한 컨테이너 구조를 가진다. 영구적으로 작동하는 컨테이너는 존재하지 않는다. 서버가 이벤트를 수신하면 컨테이너를 즉시 생성한다. 기능의 실행이 끝나면 컨테이너가 종료된다. 이 경우, 컨테이너는 이벤트가 수신되는 즉시 생성되기 때문에, 컨테이너에는 데이터 세트가 존재할 수 없다. 물론, 개발자는 데이터 세트 파일을 사용하여 이벤트를 요청할 수 있다. 그러나 데이터 세트의 용량이 클 경우 시간이 오래 소요된다. 또한, 개발자가 이전 데이터 세트를 사용하여 코드를 실행하면, 데이터 재사용은 성능을 크게 향상시킬 것이다. 이러한 이유로, 도커 볼륨 컨테이너를 사용한다. 개발자가 fn fileupload 명령을 사용하여 데이터 세트를 업로드하면, 데이터 세트가 볼륨 컨테이너에 업로드된다. 새로운 이벤트 처리가 서버에 의해 요청되고 도커 컨테이너가 생성되면, 볼륨 컨테이너에 링크 될 수 있다. 그런 다음, 컨테이너는 볼륨 컨테이너 디렉토리에 액세스 할 수 있다. 따라서 IronFunctions의 'go-dockerclient' 구성 요소에서 도커 컨테이너 생성 API를 수정하여 볼륨 컨테이너에 연결하였다.
이상에서 설명된 장치는 하드웨어 구성요소, 소프트웨어 구성요소, 및/또는 하드웨어 구성요소 및 소프트웨어 구성요소의 조합으로 구현될 수 있다. 예를 들어, 실시예들에서 설명된 장치 및 구성요소는, 예를 들어, 프로세서, 컨트롤러, 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. 클라이언트로부터 IronFunctions 서버로 함수 파일 및 함수 정보를 전송하기 위해, 클라이언트에서 도커 이미지를 원격으로 전송하기 위한 API(Application Programming Interface)를 생성하는 단계;
    클라이언트에서 도커 이미지 생성 요청에 의해 생성된 도커 이미지를 실행하는 단계; 및
    IronFunctions 서버의 요청을 처리하기 위한 API와 명령을 구현하고, 클라이언트에서 CLI(Common Language Infrastructure)를 통해 API를 호출하는 명령을 구현하는 단계
    를 포함하고,
    상기 IronFunctions 서버의 요청을 처리하기 위한 API와 명령을 구현하고, 클라이언트에서 CLI를 통해 API를 호출하는 명령을 구현하는 단계는,
    데이터 세트가 클라이언트 PC에 존재하는 경우 트레이닝 및 데이터 세트를 사용하여 심층 학습 코드를 실행하기 위해 데이터 세트를 IronFunctions 서버로 전송하고, 미리 정의된 명령을 이용하여 FTP(File Transfer Protocol) 프로토콜을 실행하여 파일을 IronFunctions 서버로 전송하는
    서버리스 컴퓨팅 환경에서 가상화된 GPU 자원 지원 방법.
  2. 제1항에 있어서,
    상기 클라이언트로부터 IronFunctions 서버로 함수 파일 및 함수 정보를 전송하기 위해, 클라이언트에서 도커 이미지를 원격으로 전송하기 위한 API를 생성하는 단계는,
    도커 이미지를 가져오기 위해 도커 허브에 로그인을 필요로 하지 않고, 도커 이미지를 출력하는 데 시간이 소요되지 않는
    서버리스 컴퓨팅 환경에서 가상화된 GPU 자원 지원 방법.
  3. 제1항에 있어서,
    상기 클라이언트에서 도커 이미지 생성 요청에 의해 생성된 도커 이미지를 실행하는 단계는,
    도커 허브로부터 도커 이미지를 출력하는 과정을 필요로 하지 않고, IronFunctions 서버가 함수 호출을 수신하는 즉시 상기 클라이언트에서 도커 이미지 생성 요청에 의해 생성된 도커 이미지를 실행하는
    서버리스 컴퓨팅 환경에서 가상화된 GPU 자원 지원 방법.
  4. 삭제
  5. 제1항에 있어서,
    IronFunctions 서버의 IronFunctions은 컨테이너 구조를 갖고, 영구적으로 작동하는 컨테이너는 존재하지 않으며 IronFunctions 서버가 이벤트를 수신할 때 컨테이너를 즉시 생성하고, IronFunctions의 실행이 종료되면 컨테이너가 종료되어 컨테이너에는 데이터 세트가 존재하지 않는
    서버리스 컴퓨팅 환경에서 가상화된 GPU 자원 지원 방법.
  6. 클라이언트로부터 IronFunctions 서버로 함수 파일 및 함수 정보를 전송하기 위해, 클라이언트에서 도커 이미지를 원격으로 전송하기 위한 API를 생성하고, 클라이언트에서 도커 이미지 생성 요청에 의해 생성된 도커 이미지를 실행하는 IronFunctions 서버; 및
    IronFunctions 서버의 요청을 처리하기 위한 API와 명령을 구현하고, 클라이언트에서 CLI를 통해 API를 호출하는 명령을 구현하는 클라이언트
    를 포함하고,
    상기 클라이언트는,
    데이터 세트가 클라이언트 PC에 존재하는 경우 트레이닝 및 데이터 세트를 사용하여 심층 학습 코드를 실행하기 위해 데이터 세트를 IronFunctions 서버로 전송하고, 미리 정의된 명령을 이용하여 FTP 프로토콜을 실행하여 파일을 IronFunctions 서버로 전송하는
    서버리스 컴퓨팅 환경에서 가상화된 GPU 자원 지원 시스템.
  7. 제6항에 있어서,
    상기 IronFunctions 서버는,
    도커 이미지를 가져오기 위해 도커 허브에 로그인을 필요로 하지 않고, 도커 이미지를 출력하는 데 시간이 소요되지 않는
    서버리스 컴퓨팅 환경에서 가상화된 GPU 자원 지원 시스템.
  8. 제6항에 있어서,
    상기 IronFunctions 서버는,
    도커 허브로부터 도커 이미지를 출력하는 과정을 필요로 하지 않고, IronFunctions 서버가 함수 호출을 수신하는 즉시 상기 클라이언트에서 도커 이미지 생성 요청에 의해 생성된 도커 이미지를 실행하는
    서버리스 컴퓨팅 환경에서 가상화된 GPU 자원 지원 시스템.
  9. 삭제
  10. 제6항에 있어서,
    IronFunctions 서버의 IronFunctions은 컨테이너 구조를 갖고, 영구적으로 작동하는 컨테이너는 존재하지 않으며 IronFunctions 서버가 이벤트를 수신할 때 컨테이너를 즉시 생성하고, IronFunctions의 실행이 종료되면 컨테이너가 종료되어 컨테이너에는 데이터 세트가 존재하지 않는
    서버리스 컴퓨팅 환경에서 가상화된 GPU 자원 지원 시스템.
KR1020180070015A 2018-06-19 2018-06-19 서버리스 컴퓨팅 환경에서 가상화된 gpu 자원 지원 방법 및 시스템 KR102092458B1 (ko)

Priority Applications (1)

Application Number Priority Date Filing Date Title
KR1020180070015A KR102092458B1 (ko) 2018-06-19 2018-06-19 서버리스 컴퓨팅 환경에서 가상화된 gpu 자원 지원 방법 및 시스템

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
KR1020180070015A KR102092458B1 (ko) 2018-06-19 2018-06-19 서버리스 컴퓨팅 환경에서 가상화된 gpu 자원 지원 방법 및 시스템

Publications (2)

Publication Number Publication Date
KR20190142837A KR20190142837A (ko) 2019-12-30
KR102092458B1 true KR102092458B1 (ko) 2020-03-23

Family

ID=69102967

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020180070015A KR102092458B1 (ko) 2018-06-19 2018-06-19 서버리스 컴퓨팅 환경에서 가상화된 gpu 자원 지원 방법 및 시스템

Country Status (1)

Country Link
KR (1) KR102092458B1 (ko)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US12026493B2 (en) 2021-09-17 2024-07-02 Electronics And Telecommunications Research Institute Docker image creation apparatus and method

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11240045B2 (en) * 2019-10-30 2022-02-01 Red Hat, Inc. Detection and prevention of unauthorized execution of severless functions
KR102553440B1 (ko) * 2020-11-27 2023-07-11 한국전력공사 서버리스 개발 지원 플랫폼
CN115114022B (zh) * 2022-06-24 2024-10-15 苏州浪潮智能科技有限公司 对gpu资源进行使用的方法、系统、设备及介质
CN117149360B (zh) * 2023-10-30 2024-01-12 天津市天河计算机技术有限公司 远程实训方法、设备和存储介质

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20060242235A1 (en) * 2005-04-22 2006-10-26 Microsoft Corporation Presence monitoring in a serverless peer-to-peer system
US9256467B1 (en) * 2014-11-11 2016-02-09 Amazon Technologies, Inc. System for managing and scheduling containers

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
김대호 외 3명. '서버리스 컴퓨팅 환경의 애플리케이션 구축을 지원하기 위한 마이크로서비스 명세 모델'. 한국정보과학회 2017 한국소프트웨어종합학술대회 논문집, 2017.12., pp.574-576.
김재욱 외 4명. '오픈소스 서버리스 클라우드 컴퓨팅 프레임워크 비교 분석'. 한국정보과학회 2017년 한국컴퓨터종합학술대회 논문집, 2017.06., pp.1448-1450.*
웹사이트, 'Open Source Serverless Computing', 출처: https://web.archive.org/web/20180605013946/http://open.iron.io/ (2018.06.05.)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US12026493B2 (en) 2021-09-17 2024-07-02 Electronics And Telecommunications Research Institute Docker image creation apparatus and method

Also Published As

Publication number Publication date
KR20190142837A (ko) 2019-12-30

Similar Documents

Publication Publication Date Title
KR102092458B1 (ko) 서버리스 컴퓨팅 환경에서 가상화된 gpu 자원 지원 방법 및 시스템
Chard et al. Funcx: A federated function serving fabric for science
Castain et al. Pmix: process management for exascale environments
US11086661B2 (en) Container chaining for automated process completion
US11429442B2 (en) Parallel and distributed computing using multiple virtual machines
US9571332B2 (en) Methods and apparatuses for remote application provisioning automation over virtualized IT infrastructure
Crago et al. Heterogeneous cloud computing
Kim et al. Gpu enabled serverless computing framework
US8595328B2 (en) Self-updating node controller for an endpoint in a cloud computing environment
Chard et al. Serverless supercomputing: High performance function as a service for science
US20200250010A1 (en) Methods and apparatus for limiting data transferred over the network by interpreting part of the data as a metaproperty
Chieu et al. Solution-based deployment of complex application services on a cloud
US10977007B2 (en) Apparatus and method for executing function
US20180107498A1 (en) Ascertaining configuration of a virtual adapter in a computing environment
Montella et al. Enabling android-based devices to high-end gpgpus
JP2020529066A (ja) クラウドサービスブローカーシステムにおいてオファーの機能を自動的に検証する技術
CN114968477A (zh) 容器热迁移方法及容器热迁移装置
US20160357581A1 (en) Locale aware platform
US10338892B2 (en) Dynamic provisioning of a set of tools based on project specifications
KR102194513B1 (ko) Ｇｐｇｐｕ 기반 태스크 큐를 활용한 웹 서비스 제공 시스템 및 방법
US20150378689A1 (en) Application instance staging
KR20200084646A (ko) 머신 러닝 서비스 ui를 제공하기 위한 장치
KR102199208B1 (ko) 태커를 위한 vnfd 생성 방법 및 장치
EP4361858A1 (en) Securing function as a service cloud computing environments
Crutcher et al. Cloud Computing

Legal Events

Date Code Title Description
A201 Request for examination
E902 Notification of reason for refusal
E701 Decision to grant or registration of patent right
GRNT Written decision to grant