KR20180059528A - 컴퓨트 용량을 위한 주기적인 요청들의 관리 - Google Patents

Abstract

착신 코드 실행 요청들 모니터링 및 대응하는 코드 실행들 스케줄링을 위한 시스템이 제공된다. 시스템은 복수의 가상 기계 인스턴스들을 유지하도록 구성될 수 있다. 시스템은 착신 코드 실행 요청들의 적어도 일부가 주기성을 보이는지 여부를 결정하도록 추가로 구성되고, 축소된 양의 유휴상태 컴퓨트 용량이 가상 컴퓨트 시스템상에 유지되도록 한다. 시스템은 추가로 코드 실행 요청들이 수신될 것으로 예상되기 바로 전에 추가 컴퓨트 용량이 추가되도록 구성될 수 있다.

Description

컴퓨트 용량을 위한 주기적인 요청들의 관리

본 출원의 출원인은 2014년 9월 30일에 다음 U.S. 특허 출원을 앞서 출원하였다:

출원 번호 제목

14/502,714 저 레이턴시 컴퓨터 용량의 자동 관리

상기 언급된 출원의 개시는 그 전체가 참조로서 본 출원에 통합된다.

전반적으로 설명된, 컴퓨팅 디바이스들은 데이터를 교환하기 위해 통신 네트워크, 또는 일련의 통신 네트워크들을 사용한다. 회사들 및 단체들은 제 3 당사자들에 서비스들을 제공하거나 또는 동작들을 지원하기 위해 많은 컴퓨팅 디바이스들을 상호연결하는 컴퓨터 네트워크들을 동작시킨다. 컴퓨팅 시스템들은 단일 지리적 위치에 위치될 수 있거나 또는 다수의, 별개의 지리적 위치들에 위치될 수 있다 (예를 들어, 개인 또는 공공 통신 네트워크들을 통하여 상호 연결된). 구체적으로, 본 출원에서 일반적으로 “데이터센터(data center)”로 지칭되는 데이터센터들 또는 데이터 프로세싱 센터들은 컴퓨팅 자원들을 데이터센터의 유저들에 제공하기 위해 많은 상호 연결된 컴퓨팅 시스템들을 포함할 수 있다. 데이터센터들은 일반 공공의 이익을 위하여, 또는 일반 공중을 위하여 동작되는 단체 또는 공공 데이터센터들을 대신하여 동작되는 개인 데이터센터들일 수 있다.

데이터센터 자원들의 증가된 활용을 가능하게 하기 위해, 가상화 기술(virtualization technology)들이 데이터 센터의 유저들에게 독립적인 컴퓨팅 디바이스들로서 보이고 동작하는 하나 이상의 가상 기계 인스턴스들을 단일의 물리적 컴퓨팅 기계가 호스트하는 것을 허용할 수 있다. 가상화로, 단일의 물리적 컴퓨팅 디바이스는 동적 방식으로 가상 기계들을 생성, 유지, 삭제 또는 다른 방식으로 관리할 수 있다. 차례로, 유저들은 단일 컴퓨팅 디바이스들 또는 네트워크화된 컴퓨팅 디바이스들의 구성을 포함하는 데이터 센터로부터 컴퓨터 자원들을 요청할 수 있고, 가변하는 가상 기계 자원들의 수가 제공될 수 있다.

일부 시나리오들에서, 가상 기계 인스턴스들은 특정 기능을 제공하기 위해 많은 가상 기계 인스턴스 유형들 에 따라 구성될 수 있다. 예를 들어, 다양한 컴퓨팅 디바이스들은 컴퓨팅 디바이스가 상이한 희망하는 기능들을 제공하거나, 또는 보다 효율적으로 유사한 기능들을 제공하는 것을 가능하게 하기 위해 운영 체계들 또는 운영 체계 구성들, 가상화된 하드웨어 자원들 및 소프트웨어 애플리케이션들의 상이한 조합들과 관련될 수 있다. 이들 가상 기계 인스턴스 유형 구성들은 종종 일단 시작된 후에 가상 기계가 운영할 소프트웨어 (예를 들어, 그것들의 구성 및 데이터 파일, 등과 함께 OS 및 애플리케이션들)을 함유하는 정적 데이터를 포함하는 디바이스 이미지내에 함유된다. 디바이스 이미지는 전형적으로 인스턴스를 생성하거나 또는 초기화하기 위해 사용되는 디스크상에 저장된다. 따라서, 컴퓨팅 디바이스는 희망하는 소프트웨어 구성을 구현하기 위해서 디바이스 이미지를 프로세스할 수 있다.

본 개시의 앞에서의 측면들 및 수반하는 장점들은 첨부한 도면들과 함께 취해질 때 이하의 상세한 설명에 대한 참조에 의해 더 잘 이해될 것이기 때문에 본 개시의 앞에서의 측면들 및 수반하는 장점들이 더 쉽게 이해될 것이다:
도 1은 예제 측면에 따른 저 레이턴시 컴퓨트 용량을 제공하기 위한 예시적인 환경을 도시한 블럭 다이어그램이다;
도 2 는 예제 측면에 따른 워밍 풀(warming pool)의 예시적인 구성을 도시한 블럭 다이어그램이다;
도 3 은 예제 측면에 따른 활성 풀(active pool)의 예시적이 구성을 도시하는 블럭 다이어그램이다;
도 4는 예제 측면에 따른 코드 실행 요청들 모니터링 및 스케줄링을 위한 스케줄링 관리기를 제공하는 컴퓨팅 디바이스의 전체적인 아키텍처를 도시한다;
도 5 는 예제 측면에 따른 스케줄링 관리기에 의해 구현되는 주기적인 작업 관리 루틴(job management routine)을 예시하는 흐름도이다;
도 6 은 예제 측면에 따른 스케줄링 관리기에 의해 구현되는 작업 스케줄링 루틴을 예시하는 흐름도이다; 및
도 7 은 예제 측면에 따른 스케줄링 관리기에 의해 구현되는 다른 작업 스케줄링 루틴을 예시하는 흐름도이다.

회사들 및 단체들은 컴퓨팅 동작들 (예를 들어, 스레드들, 프로그램들, 기능들, 소프트웨어, 루틴들, 서브루틴들, 프로세스들, 등을 포함하는 코드를 실행시키는)을 수행하기 위해서 그것들의 자체의 데이터센터들을 획득하고 관리하는 것을 더 이상 필요로 하지 않는다. 클라우드 컴퓨팅의 출현으로, 전통적으로 하드웨어 컴퓨팅 디바이스들에 의해 제공되는 스토리지 스페이스 및 컴퓨트 파워가 이제 인터넷상에서 수 분내에 획득될 수 있고 구성될 수 있다. 따라서, 개발자들은 물리적 기계들을 획득하는 것에 대한 걱정을 할 필요가 없이 희망하는 컴퓨팅 자원들의 양을 빠르게 구매할 수 있다. 이런 컴퓨팅 자원들은 전형적으로 가상 컴퓨팅 자원들, 또는 가상 기계 인스턴스들의 형태로 구매된다. 이들 가상 기계들의 인스턴스들은 물리적 기계들 (예를 들어, 컴퓨터들)의 소프트웨어 구현예들이고, 이들은 물리적 컴퓨팅 디바이스들상에 호스트되고 전통적으로 물리적 기계들상에 제공되는 운영 체계들 및 애플리케이션들을 함유할 수 있다. 이들 가상 기계 인스턴스들은 가상 기계 인스턴스들상에서 운용하는 애플리케이션들이 요청할 수 있고 물리적 컴퓨터들과 동일한 방식으로 사용될 수 있는 컴퓨팅 자원들의 세트 (예를 들어, 메모리, CPU, 디스크, 네트워크, 등)로 구성될 수 있다.

그러나, 설사 가상 컴퓨팅 자원들이 구매된 때라도, 개발자들은 또한 얼마나 많은 그리고 어떤 유형의 가상 기계 인스턴스들을 구매할 지, 그리고 얼마나 오래 그것들을 유지할 지를 결정해야 한다. 예를 들어, 가상 기계 인스턴스들 사용의 경비(cost)들은 그것들이 임대된 유형 및 시간의 수에 의존하여 변화할 수 있다. 추가하여, 가상 기계가 임대될 수 있는 최소 시간은 전형적으로 시간의 크기(order of hours)에 의한다. 더구나, 개발자들은 가상 기계들상에 인스톨할 하드웨어 및 소프트웨어 자원들 (예를 들어, 운영 체계들의 유형 및 언어 런타임(runtime)들, 등)을 지정해야만 한다. 그들이 가질 수 있는 다른 관심사항들은 오버-이용(over-utilization) (예를 들어, 너무 적은 컴퓨팅 자원들을 획득하여 성능 이슈들을 겪는 것), 언더-이용(under-utilization)(예를 들어, 코드들을 운용하기 위해 필요한 것 보다 더 많은 컴퓨팅 자원들을 획득하여서, 초과 지불한 것(overpaying)), 트래픽 변화의 예측 (예를 들어, 그들이 스케일 업 또는 다운할 때를 알기 위해), 및 설사 유저들이 초 또는 심지어 밀리세컨드의 크기에 컴퓨팅 용량을 희망할지라도 3-10 분, 또는 더 오래 걸릴 수 있는 인스턴스 및 언어 런타임 스타트업 지연(startup delay)을 포함한다.

일부 경우들에서, 각 요청 베이시스에 기초하여 이런 가상 컴퓨팅 자원들을 획득 및 관리하고 유저들에게 컴퓨트 용량을 제공하는 가상 컴퓨트 시스템들이 있을 수 있다. 그러나, 이런 유저들의 요구들에 의존하여, 워크로드 가상 컴퓨트 시스템들에 의해 수신된 워크로드의 양 및 타이밍은 예측할 수 없을 수 있다. 예측 불가능성은 단지 최악의 경우 시나리오들 (예를 들어, 한번에 유입되는 요청들의 큰 양)을 핸들링할 수 있도록 결코 완전히 사용되지 않는 큰 양의 컴퓨트 용량(값비쌀 수 있는)을 유지하기 위한 가상 컴퓨트 시스템들을 필요로 할 수 있다. 만약 가상 컴퓨트 시스템들이 큰 수의 동시 요청들을 핸들링할 수 있도록 구할 수 있는 충분한 용량을 유지하지 못하면, 유저들은 증가된 지연들, 증가된 에러율들, 또는 다른 성능-관련 이슈들을 경험할 수 있다. 따라서, 유지될 것이 요구되는 유휴상태 용량(idle capacity)의 양을 줄이는 개선된 방법이 원해진다.

본 발명의 측면에 따라, 유저 요청이 수신되자 마자 사용을 위해 준비되는 사전-초기화된 가상 기계 인스턴스들의 풀을 유지하고, 착신 요청들에 서비스하기 위해 풀(pool)내 이용 가능한 용량의 양을 자동을 관리함으로써, 유저 코드 (예를 들어, 인스턴스 및 언어 런타임 스타트업(startup) 시간) 실행과 연관된 지연 (때때로 레이턴시(latency)로 지칭된다)는 상당히 축소되고, 활용은 개선될 수 있다.

전반적으로 설명된, 본 발명의 측면들은 가상 기계 인스턴스들의 관리 및 그 내부에 생성된 컨테이너(container)들에 관한 것이다. 구체적으로, 가상 컴퓨트 시스템내 가상 기계 인스턴스들의 관리를 용이하게 하는 시스템들 및 방법들이 개시된다. 가상 컴퓨트 시스템은 그 위에 로딩된 하나 이상의 소프트웨어 컴포넌트들 (예를 들어, 운영 체계들, 언어 런타임들, 라이브러리들, 등) 을 갖는 가상 기계 인스턴스들의 풀을 유지한다. 가상 기계 인스턴스들의 풀을 유지하는 것은 새로운 인스턴스를 생성하는 단계, 외부 인스턴스 프로비저닝 서비스로부터 새로운 인스턴스를 획득하는 단계, 인스턴스를 파기하는 단계(destroying), 인스턴스를 유저에게 할당하는 단계/재할당하는 단계, 인스턴스를 수정하는 단계 (예를 들어, 그 내부에 자원들 또는 컨테이너들), 등을 포함할 수 있다. 풀 내 가상 기계 인스턴스들은 프로그램 코드들을 실행시키기 위해 유저 요청들을 서비스하도록 지정될 수 있다. 본 발명에서, 어구들 “프로그램 코드,” “유저 코드,” 및 “클라우드 기능”은 때때로 호환하여 사용될 수 있다. 프로그램 코드들은 가상 기계 인스턴스들상에 생성된 격리된(isolated) 컨테이너들에서 실행될 수 있다. 풀내 가상 기계 인스턴스들은 요청들이 수신된 시간까지 특정 운영 체계들 및 언어 런타임들로 이미 부팅되고 로딩되어졌기 때문에, 요청들을 취급할 수 있는 (예를 들어, 가상 기계 인스턴스들상에 생성된 하나 이상의 컨테이너들에 유저 코드를 실행함으로써) 컴퓨트 용량을 찾는 것과 관련된 지연이 상당히 축소된다.

다른 측면에서, 가상 컴퓨트 시스템은 가상 컴퓨트 시스템상에서 유저 코드를 실행시키기 위해 착신 요청(incoming request)들을 모니터링할 수 있고, 요청들내 트렌드(trend) (예를 들어, 요청들의 타이밍, 요청들의 볼륨, 요청들의 주기, 등)를 식별할 수 있다. 식별된 트렌드의 면에서, 가상 컴퓨트 시스템은 특정 코드 실행 요청들을 예측할 수 있다. 또한, 가상 컴퓨트 시스템은 유저들 그들이 그들의 코드를 운용하기를 원하는 보다 가요적인 시간 프레임을 지정하는 것을 허용할 수 있어서, 가상 컴퓨트 시스템은 코드 실행들을 분산시킬 수 있고 가상 컴퓨트 시스템이 핸들링 할 수 있을 것으로 예상되는 버스트 용량(burst capacity)의 양을 축소할 수 있다. 가상 컴퓨트 시스템에 의해 유지되는 컴퓨트 용량은 가상 기계 인스턴스들 위에 로딩된 하나 이상의 소프트웨어 컴포넌트들을 갖고 착신 요청을 핸들링하기 사용되는 것을 대기하는 가상 기계 인스턴스들의 워밍 풀(warming pool), 및 현재 하나 이상의 요청들을 핸들링하기 위해 사용되는 가상 기계 인스턴스들의 활성 풀(active pool)을 포함할 수 있다.

새로운 코드 실행 요청들이 수신될 때를 아는 (또는 예측하는), 가상 컴퓨트 시스템은 워밍 풀을 바이패스(bypass)할 수 있거나 또는 워밍 풀내 유휴상태 용량을 축소할 수 있다. 추가하여, 가상 컴퓨트 시스템은 유저 기능을 실행할 요청이 수신된 때 (또는 바로 그 전에) 유저 기능을 실행할 준비가 되고, 실행하도록 미리-구성된 가상 기계 인스턴스를 가짐으로써 유저의 인지 레이턴시를 낮출 수 있다. 더구나, 가상 컴퓨트 시스템은 가상 기계 인스턴스들 및/또는 컨테이너들의 수/사이즈 및 그것들이 사용되고/요구될 지속기간(duration)의 지식을 가짐으로써 로드 분산 및 개선된 군-레벨(fleet-level) 관리를 달성할 수 있다.

본 개시의 특정 실시예들 및 예제 애플리케이션들이 도면들을 참조하여 이제 설명될 것이다. 이들 실시예들 및 예 애플리케이션들은 본 발명을 제한하는 것이 아니라 예시하는 것으로 의도된다.

가상 컴퓨트 시스템을 포함하는 예시적인 환경

도 1를 참고로 하여, 가상 환경 (100)의 실시예를 예시하는 블럭 다이어그램이 설명될 것이다. 도 1 에 도시된 예제는 유저 컴퓨팅 디바이스들 (102)의 유저들 (예를 들어, 개발자들, 등)이 가상 컴퓨트 시스템 (110)에 의해 제공된 가상 컴퓨팅 자원들을 이용하여 다양한 프로그램 코드들을 운용할 수 있는 가상 환경 (100)을 포함한다.

예시의 방식으로, 데스크탑 컴퓨터, 랩탑, 및 이동 전화를 포함하여 가상 컴퓨트 시스템 (110)과 통신하는 다양한 예제 유저 컴퓨팅 디바이스들 (102)이 도시된다. 일반적으로, 유저 컴퓨팅 디바이스들 (102)은 임의의 컴퓨팅 디바이스 예컨대 데스크탑, 랩탑, 이동 전화 (또는 스마트폰), 태블릿, 키오스크(kiosk), 무선 디바이스, 및 다른 전자 디바이스들일 수 있다. 추가하여, 유저 컴퓨팅 디바이스들 (102)은 예를 들어, 상이한 웹 서비스들이 본 출원에서 설명된 하나 이상의 기술들을 수행하기 위해 서로 프로그램에 따라서(programmatically) 통신할 수 있는 동일하거나 상이한 데이터센터들상에서 운용하는 웹 서비스들을 포함할 수 있다. 더구나, 유저 컴퓨팅 디바이스들 (102)은 사물 인터넷 (IoT) 디바이스들 예컨대 인터넷 기기들 및 연결된 디바이스들을 포함할 수 있다. 가상 컴퓨트 시스템 (110)은 유저 코드들 생성 및 업로딩, 유저 코드들을 호출 (예를 들어, 가상 컴퓨트 시스템 (110)상에서 유저 코드들을 실행시키기 위한 요청을 제출), 이벤트기반의 작업들 또는 시간이 정해진(timed) 작업들 스케줄링, 유저 코드들 추적, 및/또는 그들의 요청들 및/또는 유저 코드들에 관련된 다른 로깅 또는 모니터링 정보를 보기 위한 한 명 이상의 유저 인터페이스들, CLI(command-line interfaces), API(application programming interfaces), 및/또는 다른 프로그램마틱 인터페이스들을 유저 컴퓨팅 디바이스들 (102)에 제공할 수 있다. 비록 하나 이상의 실시예들이 유저 인터페이스를 이용하여 본 출원에서 설명될 수 있지만, 이런 실시예들은 추가적으로 또는 대안적으로, 임의의 CLI들, API들, 또는 다른 프로그램마틱 인터페이스들을 사용할 수 있는 것이 이해되어야 한다.

유저 컴퓨팅 디바이스들 (102)은 네트워크 (104)를 통하여 가상 컴퓨트 시스템 (110)을 액세스한다. 네트워크 (104)는 임의의 유선 네트워크, 무선 네트워크, 또는 그것의 조합일 수 있다. 추가하여, 네트워크 (104)는 퍼스널 영역 네트워크, 로컬 영역 네트워크, 와이드 영역 네트워크, 오버-디-에어(over-the-air) 브로드캐스트 네트워크 (예를 들어, 라디오 또는 텔레비전을 위한), 케이블 네트워크, 위성 네트워크, 셀룰러 전화기 네트워크, 또는 그것의 조합일 수 있다. 예를 들어, 네트워크 (104)는 어쩌면 다양한 별개의 당사자들에 의해 운용되는 링크된 네트워크들의 공공이 액세스 가능한 네트워크, 예컨대 인터넷일 수 있다. 일부 실시예들에서, 네트워크 (104)는 개인 또는 세미-개인(semi-private) 네트워크, 예컨대 회사 또는 대학 인트라넷일 수 있다. 네트워크 (104)는 하나 이상의 무선 네트워크들, 예컨대 모바일 통신을 위한 글로벌 시스템들 (GSM : Global System for Mobile Communications) 네트워크, 코드 분할 다중 액세스 (CDMA : Code Division Multiple Access) 네트워크, 롱 텀 애벌류션 (LTE : Long Term Evolution) 네트워크, 또는 임의의 다른 유형의 무선 네트워크를 포함할 수 있다. 네트워크 (104)는 인터넷 또는 다른 앞서 언급한 유형들의 네트워크들 중 임의의 것을 통하여 통신하기 위한 프로토콜들 및 컴포넌트들을 사용할 수 있다. 예를 들어, 네트워크 (104)에 의해 사용되는 프로토콜들은 하이퍼텍스트 전송 프로토콜 (HTTP : Hypertext Transfer Protocol), HTTP 보안 (HTTPS : HTTP Secure), MQTT(Message Queue Telemetry Transport), CoAP(Constrained Application Protocol), 및 유사한 것을 포함할 수 있다. 인터넷 또는 임의의 다른 앞서 언급한 유형들의 통신 네트워크들의 임의의 것을 통하여 통신하기 위한 프로토콜들 및 컴포넌트들은 당해 기술분야의 통상의 기술자들에 잘 알려져 있어서, 본 출원에서 보다 상세하게 설명하지 않는다.

가상 컴퓨트 시스템 (110)은 하나 이상의 컴퓨터 네트워크들을 이용하여 상호 연결된 몇몇의 컴퓨터 시스템들을 포함하는 분산 컴퓨팅 환경에서 동작하는 것으로 도 1에 도시된다. 가상 컴퓨트 시스템 (110)은 도 1에 예시된 것보다 더 적거나 또는 더 많은 수의 디바이스들을 갖는 컴퓨팅 환경내에서 또한 동작할 수 있다. 따라서, 도 1의 가상 컴퓨트 시스템 (110)의 도시는 본 발명을 제한하는 것이 아니라 예시적인 것으로 받아들여져야 한다. 예를 들어, 가상 컴퓨트 시스템 (110)은 또는 그것의 다양한 구성들은 본 출원에서 설명된 적어도 일부의 프로세스들을 구현하기 위한 다양한 웹 서비스들 컴포넌트들, 호스트되는 또는 “클라우드(cloud)” 컴퓨팅 환경들, 및/또는 피어 투 피어 네트워크 구성들을 구현할 수 있다.

더구나, 가상 컴퓨트 시스템 (110)은 하드웨어 및/또는 소프트웨어로 구현될 수 있고 예를 들어, 본 출원에서 설명될 다양한 특징들을 수행하기 위한 컴퓨터 실행 가능한 지시들을 실행하도록 구성된 물리적 컴퓨터 하드웨어상에 구현된 하나 이상의 물리적 또는 가상 서버들을 포함할 수 있다. 하나 이상의 서버들은 지리적으로 분산될 수 있거나 또는 지리적으로 같은 장소에 예를 들어, 하나 이상의 데이터센터들에 배치될 수 있다.

도 1에 예시된 환경에서, 가상 환경 (100)은 프론트엔드(frontend) (120), 워밍 풀 관리기(warming pool manager) (130), 워커 관리기(worker manager) (140), 및 스케줄링 관리기(scheduling manager) (150)을 포함하는 가상 컴퓨트 시스템 (110)을 포함한다. 도시된 예제에서, 가상 기계 인스턴스들 (“인스턴스(들”) (152,154)은 워밍 풀 관리기 (130)에 의해 관리되는 워밍 풀 (130A)에 도시되고, 인스턴스들 (156,157,158,159)은 워커 관리기 (140)에 의해 관리되는 활성 풀 (140A)에 도시된다. 가상 컴퓨트 시스템 (110)내에 다양한 컴포넌트들의 예시는 현실적으로 로직상에 있고 하나 이상의 컴포넌트들은 단일 컴퓨팅 디바이스 또는 다수의 컴퓨팅 디바이스들에 의해 구현될 수 있다. 예를 들어, 인스턴스들 (152,154,156,157,158,159)은 상이한 다양한 지리적 영역들에 하나 이상의 물리적 컴퓨팅 디바이스들상에 구현될 수 있다. 유사하게, 각각의 프론트엔드 (120), 워밍 풀 관리기 (130), 워커 관리기 (140), 및 스케줄링 관리기 (150)는 다수의 물리적 컴퓨팅 디바이스들에 걸쳐 구현될 수 있다. 대안적으로, 프론트엔드 (120), 워밍 풀 관리기 (130), 워커 관리기 (140), 및 스케줄링 관리기 (150) 중 하나 이상은 단일 물리적 컴퓨팅 디바이스상에 구현될 수 있다. 일부 실시예들에서, 가상 컴퓨트 시스템 (110)은 다수의 프론트엔드들, 다수의 워밍 풀 관리기들, 다수의 워커 관리기들, 및/또는 다수의 용량 관리기들을 포함할 수 있다. 비록 여섯개의 가상 기계 인스턴스들이 도 1의 예제에 도시되었지만, 본 출원에서 설명된 실시예들은 이와 같이 제한되지 않고, 당해 기술의 통상의 기술자은 가상 컴퓨트 시스템 (110)이 임의 개수의 물리적 컴퓨팅 디바이스들을 이용하여 구현된 임의 개수의 가상 기계 인스턴스들을 포함할 수 있다는 것을 인식할 것이다. 유사하게, 비록 단일 워밍 풀 및 단일 활성 풀이 도 1의 예제에 도시되었지만, 본 출원에서 설명된 실시예들은 이와 같이 제한되지 않고, 당해 기술의 통상의 기술자은 가상 컴퓨트 시스템 (110)이 임의 개수의 워밍 풀들 및 활성 풀들을 포함할 수 있다는 것을 인식할 것이다.

도 1의 예제에서, 가상 컴퓨트 시스템 (110)은 네트워크 (104)에 연결된 것으로 예시된다. 일부 실시예들에서, 가상 컴퓨트 시스템 (110)내에 임의의 컴포넌트들은 네트워크 (104)를 통하여 가상 환경 (100)의 다른 컴포넌트들 (예를 들어, 유저 컴퓨팅 디바이스들 (102) 및 모니터링/로깅(logging)/과금(billing) 서비스들 (107), 스토리지 서비스 (108), 인스턴스 프로비저닝 서비스 (109), 및/또는 가상 컴퓨트 시스템 (110)과 통신할 수 있는 다른 서비스들을 포함할 수 있는 보조 서비스들 (106))와 통신할 수 있다. 다른 실시예들에서, 가상 컴퓨트 시스템 (110)의 모든 컴포넌트들이 가상 환경 (100)의 다른 컴포넌트들과 통신하는 것이 가능하지는 않다. 일 예에서, 단지 프론트엔드 (120)만이 네트워크 (104)에 연결될 수 있고, 가상 컴퓨트 시스템 (110)의 다른 컴포넌트들은 프론트엔드 (120)를 통하여 가상 환경 (100)의 다른 컴포넌트들과 통신할 수 있다.

유저들은 그 위에 유저 코드를 실행시키기 위해 가상 컴퓨트 시스템 (110)을 사용할 수 있다. 예를 들어, 유저는 유저가 개발한 웹 또는 모바일 애플리케이션와 관련한 코드 부분을 운용하는 것을 원할 수 있다. 코드를 운용하는 한가지 방법은 서비스로서 인프라스트럭처를 제공하는 서비스 제공자들로부터 가상 기계 인스턴스들을 획득하고, 유저의 요구들에 맞도록 가상 기계 인스턴스들을 구성하고, 및 코드를 운용하기 위해 구성된 가상 기계 인스턴스들을 사용하는 것일 것이다. 대안적으로, 유저는 가상 컴퓨트 시스템 (110)에 코드 실행 요청을 발송할 수 있다. 가상 컴퓨트 시스템 (110)은 컴퓨트 용량 코드 실행 요청에 기초하여 컴퓨트 용량(예를 들어, 컨테이너들, 인스턴스들, 등, 이들은 이하에서 더 상세하게 설명된다)의 취득 및 구성을 핸들링할 수 있고, 컴퓨트 용량을 이용하여 코드를 실행할 수 있다. 가상 컴퓨트 시스템 (110)은 볼륨에 기초하여 자동으로 스케일 업 및 다운할 수 있고, 그렇게 함으로써 유저가 오버-이용 (예를 들어, 너무 적은 컴퓨팅 자원들을 획득하여 성능 이슈들을 겪는 것) 또는 언더-이용 (예를 들어, 코드들을 운용하기 위해 필요한 것보다 더 많은 컴퓨팅 자원들을 획득하여서 초과 지불한 것)에 대한 걱정을 해야 하는 부담을 덜어준다.

프론트엔드 (Frontend)

프론트엔드 (120)는 가상 컴퓨트 시스템 (110)상에서 유저 코드를 실행시키기 위해 모든 요청들을 프로세스한다. 일 실시예에서, 프론트엔드 (120)는 가상 컴퓨트 시스템 (110)에 의해 제공되는 모든 다른 서비스들에 대한 프론트 도어(front door)로서 역할을 한다. 프론트엔드 (120)는 요청들을 프로세스하고 요청들이 적절하게 허가되는 것을 확실하게 한다. 예를 들어, 프론트엔드 (120)는 요청과 관련된 유저가 요청에 지정된 유저 코드를 액세스하는 것이 허가되었는지 여부를 결정할 수 있다.

본 출원에서 사용되는 유저 코드는 특정 프로그램 언어로 기록된 임의의 프로그램 코드 (예를 들어, 프로그램, 루틴, 서브루틴, 스레드(thread), 등)을 지칭할 수 있다. 본 발명에서, 용어들 “코드,” “유저 코드,” 및 “프로그램 코드”는 호환하여 사용될 수 있다. 이런 유저 코드는 예를 들어, 유저에 의해 개발된 특정 웹 애플리케이션 또는 모바일 애플리케이션과 관련하여 특정 태스크를 달성하기 위해 실행될 수 있다. 예를 들어, 유저 코드들은 자바스크립트 (node.js), 자바, 파이손, 및/또는 루비로 기록될 수 있다. 요청은 유저 코드를 실행시키기 위해 사용되는 유저 코드 (또는 그것의 위치) 및 하나 이상의 독립 변수(argument)들을 포함할 수 있다. 예를 들어, 유저는 유저 코드를 실행시키기 위한 요청과 함께 유저 코드를 제공할 수 있다. 다른 예에서, 요청은 앞에서 업로딩된 프로그램 코드 (예를 들어, 코드를 업로딩하기 위한 API를 이용하여)을 그것의 이름 또는 그것의 고유 ID에 의해 식별할 수 있다. 또 다른 예에서, 코드는 요청에 포함될 수 있을 뿐만 아니라 요청이 가상 컴퓨트 시스템 (110)에 의해 수신되기 전에 별개의 위치 (예를 들어, 스토리지 서비스 (108) 또는 가상 컴퓨트 시스템 (110)에 내부의 스토리지 시스템)에 업로딩될 수 있다. 가상 컴퓨트 시스템 (110)은 요청이 프로세스된 시간에 코드가 어디에서 이용가능하게 되는지에 기초하여 그것의 코드 실행 전략을 변화시킬 수 있다.

프론트엔드 (120)는 유저로부터의 HTTPS(Hypertext Transfer Protocol Secure) 요청들에 응답하여 이런 유저 코드들을 실행시키기 위한 요청을 수신할 수 있다. 또한, HTTPS 요청에 포함된 임의의 정보 (예를 들어, 헤더들 및 파라미터들)가 또한 프로세스될 수 있고 유저 코드를 실행시킬 때 사용될 수 있다. 상기에서 논의된 바와 같이, 예를 들어, HTTP, MQTT, 및 CoAP을 포함하는 임의의 다른 프로토콜들이 코드 실행 요청을 함유하는 메시지를 프론트엔드 (120)로 전송하기 위해 사용될 수 있다. 프론트엔드 (120)는 이벤트가 감지된 때, 예컨대 유저가 자동 요청 생성을 트리거하도록 등록된 이벤트시에 이런 유저 코드들을 실행시키기 위한 요청을 또한 수신할 수 있다. 예를 들어, 유저는 보조 서비스 (106)에 유저 코드를 등록할 수 있고 특정 이벤트가 발생할 때마다(예를 들어, 새로운 파일이 업로딩된다) 지정될 수 있고, 유저 코드를 실행시키기 위한 요청이 프론트엔드 (120)에 발송된다. 대안적으로, 유저는 시간이 정해진 작업(job)을 등록할 수 있다(예를 들어, 매 24 시간 유저 코드를 실행). 이런 예에서, 시간이 정해진 작업에 대하여 스케줄된 시간이 다다른 때, 유저 코드를 실행시키기 위한 요청이 프론트엔드 (120)에 발송될 수 있다. 또 다른 예에서, 프론트엔드 (120)는 착신(incoming) 코드 실행 요청들의 큐를 가질 수 있고, 유저의 배치 작업(batch job)이 가상 컴퓨트 시스템의 워크 큐로부터 제거된 때, 프론트엔드 (120)는 유저 요청을 프로세스할 수 있다. 또 다른 예에서, 요청은 가상 컴퓨트 시스템 (110)내 다른 컴포넌트로부터 또는 도 1에 예시되지 않은 다른 서버들 또는 서비스들로부터 발원할 수 있다.

유저 요청은 유저 코드와 함께 사용될 하나 이상의 제 3-당사자 라이브러리들 (고유 라이브러리들을 포함하는)을 지정할 수 있다. 일 실시예에서, 유저 요청은 유저 코드 및 임의의 라이브러리들 (및/또는 그것의 스토리지 위치들의 식별들)을 함유하는 ZIP 파일이다. 일부 실시예들에서, 유저 요청(user request)은 실행될 프로그램 코드를 표시하는 메타데이터, 프로그램 코드가 기록된 언어, 요청과 관련된 유저, 및/또는 프로그램 코드를 실행하기 위해 리저브드(reserved)된 컴퓨팅 자원들 (예를 들어, 메모리, 등)을 포함한다. 예를 들어, 프로그램 코드는 유저에 의해 미리 업로딩된, 가상 컴퓨트 시스템 (110)에 의해 제공된(예를 들어, 표준 루틴들), 및/또는 제 3 당사자들에 의해 제공된 요청과 함께 제공될 수 있다. 일부 실시예들에서, 이런 자원-레벨 제약(resource-level constraint)들 (예를 들어, 얼마나 많은 메모리가 특정 유저 코드를 실행시키기 위해 할당되어야 하는지)이 특정 유저 코드에 대하여 지정되고, 유저 코드의 각각의 실행에 대하여 변화하지 않을 수 있다. 이런 경우들에서, 가상 컴퓨트 시스템 (110)은 각각의 개별 요청이 수신되기 전에 이런 자원-레벨 제약들에 대한 액세스를 가질 수 있고, 개별 요청들은 이런 자원-레벨 제약들을 지정하지 않을 수 있다. 일부 실시예들에서, 유저 요청은 요청이 유저 코드를 실행시키기 위해 갖는 어떤 종류의 허가들을 표시하는 다른 제약들 예컨대 허가 데이터를 지정할 수 있다. 이런 허가 데이터는 개인 자원들 (예를 들어, 개인 네트워크상에서)을 액세스하기 위해 가상 컴퓨트 시스템 (110)에 의해 사용될 수 있다.

일부 실시예들에서, 유저 요청은 유저 요청을 취급하기 위해 채택되어야 하는 행위(behavior)를 지정할 수 있다. 이런 실시예들에서, 유저 요청은 유저 요청과 관련된 유저 코드가 실행될 하나 이상의 실행 모드들을 인에이블하기 위한 표시자(indicator)를 포함할 수 있다. 예를 들어, 요청은 유저 코드의 실행과 관련하여 생성될 수 있는 디버깅 및/또는 로깅 출력이 유저에게 다시 제공될 수 있는 (예를 들어, 콘솔 유저 인터페이스를 통하여) 디버깅 모드에서 유저 코드가 실행되어야 하는지 여부를 나타내는 플래그(flag) 또는 헤더(header)를 포함할 수 있다. 이런 예에서, 가상 컴퓨트 시스템 (110)은 요청을 검사하고 플래그 또는 헤더를 검색할 수 있고, 만약 그것이 존재하면, 가상 컴퓨트 시스템 (110)은 유저 코드가 실행되는 컨테이너의 행위(예를 들어, 설비들 로깅)을 수정할 수 있고, 출력 데이터가 유저에게 다시 제공되도록 할 수 있다. 일부 실시예들에서, 행위/모드 표시자들은 가상 컴퓨트 시스템 (110)에 의해 유저에게 제공되는 유저 인터페이스에 의해 해당 요청에 추가된다. 다른 특징들 예컨대 소스 코드 프로파일링(profiling), 원격 디버깅, 등은 요청에 제공된 표시에 기초하여 또한 인에이블(enable)되거나 또는 디스에이블(disable)될 수 있다.

일부 실시예들에서, 가상 컴퓨트 시스템 (110)은 다수의 프론트엔드들 (120)을 포함할 수 있다. 이런 실시예들에서, 로드 분산기(load balancer)가 예를 들어, 라운드-로빈(round-robin) 방식으로 다수의 프론트엔드들 (120)에 착신 요청들을 분배하기 위해 제공될 수 있다. 일부 실시예들에서, 로드 분산기가 착신 요청들을 다수의 프론트엔드들 (120)에 분배하는 방식은 워밍 풀 (130A) 및/또는 활성 풀 (140A)의 상태에 기반될 수 있다. 예를 들어, 만약 워밍 풀 (130A)에 용량이 충분한 것으로 생가되면, 요청들은 프론트엔드들 (120) (예를 들어, 하나 이상의 로드 분산 제한들에 기초하여)의 개별 용량에 기초하여 다수의 프론트엔드들 (120)에 분배될 수 있다. 반면에, 만약 워밍 풀 (130A)에 용량이 임계량보다 작으면, 워밍 풀 (130A)로부터 취해진 가상 기계 인스턴스들의 수를 축소하거나 또는 최소화하는 방식으로 요청들이 다수의 프론트엔드들 (120)에 분배될 수 있도록 하나 이상의 이런 로드 분산 제한들이 제거될 수 있다. 예를 들어, 심지어 만약, 로드 분산 제한에 따라, 요청은 프론트엔드 A로 라우팅될 것이고, 만약 프론트엔드 A는 요청을 서비스하기 위해 워밍 풀 (130A)로부터 인스턴스를 취할 필요가 있지만 그러나 프론트엔드 B가 동일한 요청을 서비스하기 위해 그것의 활성 풀(active pool)에 인스턴스들 중 하나를 사용할 수 있다면, 요청은 프론트엔드 B로 라우팅될 수 있다.

워밍 풀 관리기(Warming Pool Manager)

워밍 풀 관리기 (130)는 가상 컴퓨트 시스템 (110)이 가상 컴퓨트 시스템 (110)상에서 유저 코드를 실행시키기 위해 요청을 수신한 때 가상 기계 인스턴스들이 워커 관리기 (140)에 의해 사용될 준비가 된 것을 보장한다. 도 1에 예시된 예에서, 워밍 풀 관리기 (130)는 워밍 풀 (130A)를 관리하고, 이는 착신 유저 코드 실행 요청들에 서비스하기 위해 사용될 수 있는 미리-초기화되고 미리-구성된 가상 기계 인스턴스들의 그룹(때때로 풀(pool)로 지칭된다)이다. 일부 실시예들에서, 워밍 풀 관리기 (130)는 가상 기계 인스턴스들이 가상 컴퓨트 시스템 (110)내 하나 이상의 물리적 컴퓨팅 기계들상에 부트 업(boot up)되고 워밍 풀 (130A)에 추가되게 한다. 다른 실시예들에서, 워밍 풀 관리기 (130)는 새로운 인스턴스들을 워밍 풀 (130A)에 생성하고 추가하기 위해 보조 가상 기계 인스턴스 서비스 (예를 들어, 도 1의 인스턴스 프로비저닝 서비스 (109))와 통신한다. 일부 실시예들에서, 워밍 풀 관리기 (130)는 프론트엔드 (120)에 의해 수신된 코드 실행 요청들을 서비스하기 위해 사용될 수 있는 컴퓨트 용량을 취득하고 유지하기 위해 가상 컴퓨트 시스템 (110)내 물리적 컴퓨팅 디바이스들 및 하나 이상의 가상 기계 인스턴스 서비스들 둘 모두를 사용할 수 있다. 일부 실시예들에서, 가상 컴퓨트 시스템 (110)은 워밍 풀 (130A)에 이용 가능한 용량을 제어하기 위한 (예를 들어, 증가시키거나 또는 감소시키는) 하나 이상의 로직 노브(knob)들 또는 스위치들을 포함할 수 있다. 예를 들어, 시스템 관리자는 피크 시간들동안에 워밍 풀 (130A)에 이용 가능한 용량(capacity)(예를 들어, 미리-부팅된 인스턴스들의 수)을 증가시키기 위해 이런 노브 또는 스위치를 사용할 수 있다. 일부 실시예들에서, 워밍 풀 (130A)에 가상 기계 인스턴스들은 유저의 코드를 실행시키기 위해 특정 유저 요청과 무관한 미리 결정된 구성들의 세트에 기초하여 구성될 수 있다. 미리 결정된 구성들의 세트는 유저 코드들을 실행시키기 위한 다양한 유형들의 가상 기계 인스턴스들에 해당할 수 있다. 워밍 풀 관리기 (130)는 현재 또는 이전 유저 코드 실행들에 관련된 하나 이상의 메트릭들에 기초하여 워밍 풀 (130)에 가상 기계 인스턴스들의 유형들 및 수들을 최적화할 수 있다.

도 1에 도시된 바와 같이, 인스턴스들은 운영 체계들 (OS) 및/또는 동작시스템들상에 로딩된 언어 런타임(language runtime)들을 가질 수 있다. 예를 들어, 워밍 풀 관리기 (130)에 의해 관리되는 워밍 풀 (130A)은 인스턴스들 (152,154)을 포함한다. 인스턴스 (152)는 OS (152A) 및 런타임 (152B)를 포함한다. 인스턴스 (154)는 OS (154A)를 포함한다. 일부 실시예들에서, 워밍 풀 (130A)에 인스턴스들은 이하에서 더 상세하게 설명되는 컨테이너(container)들 (추가로 운영 체계들, 런타임들, 유저 코드들, 등의 복사본들을 함유할 수 있다)을 또한 포함할 수 있다. 비록 단일 런타임을 포함하는 인스턴스 (152)가 도 1 에 도시되지만, 다른 실시예들에서, 도 1에 도시된 인스턴스들은 두개 이상의 런타임들을 포함할 수 있고, 각각은 상이한 유저 코드를 운용하기 위해 사용될 수 있다. 일부 실시예들에서, 워밍 풀 관리기 (130)는 워밍 풀 (130A)에 인스턴스들의 리스트를 유지할 수 있다. 인스턴스들의 리스트는 해당 인스턴스들의 구성 (예를 들어, OS, 런타임, 컨테이너, 등)을 추가로 지정할 수 있다.

일부 실시예들에서, 워밍 풀 (130A)에 가상 기계 인스턴스들은 임의의 유저 요청에 서비스를 제공하기 위해 사용될 수 있다. 일 실시예에서, 워밍 풀 (130A)에 모든 가상 기계 인스턴스들은 동일하거나 또는 실질적으로 유사한 방식으로 구성된다. 다른 실시예에서, 워밍 풀 (130A)내 가상 기계 인스턴스들은 상이한 유저들의 요구들에 맞추기 위해서 상이하게 구성될 수 있다. 예를 들어, 가상 기계 인스턴스들은 상이한 운영 체계들, 운영 체계들상에 로딩된 상이한 언어 런타임들, 및/또는 상이한 라이브러리들을 가질 수 있다. 또 다른 실시예들에서, 워밍 풀 (130A) 내 가상 기계 인스턴스들은 동일하거나 또는 실질적으로 유사한 방식 (예를 들어, 동일한 OS, 언어 런타임들, 및/또는 라이브러리들로)으로 구성될 수 있지만, 그러나 그것들의 인스턴스들의 일부는 상이한 컨테이너 구성들을 가질 수 있다. 예를 들어, 두개의 인스턴스들은 Python 및 Ruby 둘모두를 위한 런타임들을 가질 수 있지만, 그러나 하나의 인스턴스는 Python 코드를 운용하도록 구성된 컨테이너를 가질 수 있고, 다른 인스턴스는 Ruby 코드를 운용하도록 구성된 컨테이너를 가질 수 있다. 일부 실시예들에서, 다수의 워밍 풀들 (130A), 동일하게-구성된 가상 기계 인스턴스들을 갖는 각각의 워밍 풀이 제공된다.

워밍 풀 관리기 (130)는 워밍 풀 (130A)에 가상 기계 인스턴스들을 미리 구성할 수 있어서, 각각의 가상 기계 인스턴스는 가상 컴퓨트 시스템 (110)상에서 프로그램 코드를 실행시키기 위해 유저 요청에 의해 요청될 수 있거나 또는 지정될 수 있는 적어도 하나의 동작 상태들을 충족시키도록 구성된다. 일 실시예에서, 동작 상태(operating condition)들은 잠재적인 유저 코드들이 기록될 수 있는 프로그램 언어들을 포함할 수 있다. 예를 들어, 이런 언어들 Java, JavaScript, Python, Ruby, 및 유사한 것을 포함할 수 있다. 일부 실시예들에서, 유저 코드들이 기록될 수 있는 언어들의 세트는 유저 코드들을 실행시키기 위한 요청들을 충족시킬 수 있는 가상 기계 인스턴스들의 사전-초기화를 가능하게 하기 위해 미리 결정된 세트 (예를 들어, 4 언어들의 세트, 비록 일부 실시예들에서 네개의 언어들 많거나 또는 더 적은 세트들이 제공된다)으로 제한될 수 있다. 예를 들어, 유저가 가상 컴퓨트 시스템 (110)에 의해 제공된 유저 인터페이스를 통하여 요청을 구성하고 있을 때, 유저 인터페이스는 유저 코드를 실행시키기 위한 미리 결정된 동작 상태들 중 하나를 지정하기 위해 유저에게 프롬프트할 수 있다. 다른 예에서, 가상 컴퓨트 시스템 (110)에 의해 제공된 서비스들에 사용하기 위한 SLA(service-level agreement)는 유저 요청들이 충족되어야 하는 일련의 상태들 (예를 들어, 프로그래밍 언어들, 컴퓨팅 자원들, 등.)을 지정할 수 있고, 가상 컴퓨트 시스템 (110)은 요청들은 요청들 취급시에 상태들의 세트를 충족시킨다고 가정할 수 있다. 다른 예에서, 요청에 지정된 동작 조건들은 이하를 포함할 수 있다: 요청 프로세싱을 위해 사용될 컴퓨트 파워의 양; 요청의 유형 (예를 들어, HTTP vs. 트리거링된 이벤트); 요청에 대한 타임아웃 (예를 들어, 요청이 해당 시간 후에 종료될 수 있는 임계 시간); 보안 정책들 (예를 들어, 워밍 풀 (130A)내 어떤 인스턴스들이 어떤 유저에 의해 사용 가능한지를 제어할 수 있다); 스케줄링 정보 (예를 들어, 가상 컴퓨트 시스템이 해당 시간까지 프로그램 코드를 실행하도록 요청된 시간, 가상 컴퓨트 시스템이 그 후에 프로그램 코드를 실행하도록 요청된 시간가상 컴퓨트 시스템이 해당 시간내에 프로그램 코드를 실행하도록 요청된 시간 윈도우(time window), 등), 등.

워커 관리기(Worker Manager)

워커 관리기 (140)는 착신 코드 실행 요청들을 서비스하기 위해 사용되는 인스턴스들을 관리한다. 도 1에 예시된 예제에서, 워커 관리기 (140)는 활성 풀 (140A)를 관리하고, 이는 현재 하나 이상의 유저들에 할당된 가상 기계 인스턴스들의 그룹(때때로 풀(pool)로 지칭된다)이다. 비록 가상 기계 인스턴스들은 특정 유저에 할당되는 것으로 본 출원에서 설명되지만, 일부 실시예들에서, 인스턴스들은 유저들의 그룹에 할당될 수 있어서, 인스턴스는 유저들의 그룹으로 묶여지고 그룹의 임의의 멤버가 인스턴스상에 자원들을 사용할 수 있다. 예를 들어, 동일한 그룹에 유저들은 동일한 보안 그룹 (예를 들어, 그것들의 보안 자격들에 기초하여)에 속할 수 있어서 다른 멤버의 코드가 동일한 인스턴스상에서의 다른 컨테이너에서 실행되어진 후에 특정한 인스턴스상의 컨테이너내의 하나의 멤버의 코드를 실행하는 것은 보안 위험들을 제기하지 않는다. 유사하게, 워커 관리기 (140)는 어떤 요청들 어떤 컨테이너들에서 실행될 수 있는지 및 어떤 인스턴스들이 어떤 유저들에 할당될 수 있는지를 지시하는 하나 이상의 정책들에 따라 인스턴스들 및 컨테이너들을 할당할 수 있다. 예제 정책은 인스턴스들이 동일한 계정을 공유하는 유저들의 집단들에 할당되도록 지정할 수 있다 (예를 들어, 가상 컴퓨트 시스템 (110)에 의해 제공된 서비스들을 액세스하기 위한 계정). 일부 실시예들에서, 동일한 유저 그룹과 관련된 요청들은 동일한 컨테이너들 (예를 들어, 만약 그것과 관련된 유저 코드들이 같으면)을 공유할 수 있다. 일부 실시예들에서, 요청은 그룹의 상이한 유저들간을 구별하지 않고 단순하게 요청들과 관련된 유저들이 속하는 그룹을 표시한다.

도 1에 예시된 예제에서, 유저 코드들은 컨테이너들로 지칭된 격리된 컴퓨트 시스템들에서 실행된다. 컨테이너들은 해당 인스턴스상에서 이용 가능한 자원들을 이용하여 가상 기계 인스턴스내에 생성된 로직 유닛(logical unit)들이다. 예를 들어, 워커 관리기 (140)는 유저 코드를 실행시키기 위해 요청에 지정된 정보에 기초하여, 새로운 컨테이너를 생성할 수 있거나 또는 활성 풀 (140A)에 인스턴스들 중 하나에 현존하는 컨테이너를 위치시키고 그리고 요청과 관련된 유저 코드의 실행을 핸들링하기 위해 컨테이너를 요청에 할당할 수 있다. 일 실시예에서, 이런 컨테이너들은 리눅스 컨테이너(Linux contrainter)들로 구현된다. 활성 풀 (140A)에 가상 기계 인스턴스들은 그 위에 생성된 하나 이상의 컨테이너들을 가질 수 있고 그 위에 (예를 들어, 컨테이너들 중 하나에서 또는 인스턴스의 로컬 캐시에서) 로딩된 유저와 관련된 하나 이상의 프로그램 코드들을 가질 수 있다.

도 1에 도시된 바와 같이, 인스턴스들은 운영 체계들 (OS), 언어 런타임들, 및 컨테이너들을 가질 수 있다. 컨테이너들은 OS 및 언어 런타임들 및 그 위에 로딩된 유저 코드들의 개별 복사본들을 가질 수 있다. 도 1의 예에서, 워커 관리기 (140)에 의해 관리되는 활성 풀 (140A)은 인스턴스들 (156,157,158,159)를 포함한다. 인스턴스 (156)는 컨테이너들 (156A, 156B)을 갖는다. 컨테이너 (156A)는 그 내부에 로딩된 OS (156A-1), 런타임 (156A-2), 및 코드 (156A-3)를 갖는다. 도시된 예제에서, 컨테이너 (156A)는 그 내부에 로딩된 그것 자체의 OS, 런타임, 및 코드를 갖는다. 일 실시예에서, OS (156A-1) (예를 들어, 그것의 커널), 런타임 (156A-2), 및/또는 코드 (156A-3)는 컨테이너들 (156A, 156B) (및 도 1에 예시되지 않은 임의의 다른 컨테이너들)간에 공유된다. 다른 실시예에서, OS (156A-1) (예를 들어, 커널 바깥쪽에서 운용하는 임의의 코드), 런타임 (156A-2), 및/또는 코드 (156A-3)는 컨테이너 (156A)에 대하여 생성된 독립적인 복사본들이고 인스턴스 (156)상에 다른 컨테이너들과 공유되지 않는다. 또 다른 실시예들에서, OS (156A-1), 런타임 (156A-2), 및/또는 코드 (156A-3)의 일부 부분들은 인스턴스 (156)상에 컨테이너들간에 공유되고, 그것의 다른 부분들은 컨테이너 (156A)에 특정된 독립적인 복사본들이다. 인스턴스 (157)는 컨테이너들 (157A, 157B, 157C)를 포함한다. 인스턴스 (158)는 컨테이너들 (158A, 158B)를 포함한다. 인스턴스 (159)는 컨테이너 (159A)를 포함한다.

도 1의 예에서, 도 1에 도시된 컨테이너들의 사이즈들은 컨테이너들의 실제 사이즈에 비례할 수 있다. 예를 들어, 컨테이너 (156A)는 인스턴스 (156)상에서 컨테이너 (156B)보다 더 많은 스페이스를 차지한다. 유사하게, 컨테이너들 (157A, 157B, 157C)는 동등하게 사이즈될 수 있고, 컨테이너들 (158A, 158B, 159A)은 동등하게 사이즈될 수 있다. 인스턴스들 (158, 159)에 도시된 “C”로 라벨링된 점선의 박스들은 새로운 인스턴스들을 생성하기 위해 사용될 수 있는 인스턴스들상에 남아있는 스페이스를 표시한단. 일부 실시예들에서, 컨테이너들의 사이즈들은 64MB 또는 그것의 배수들일 수 있다. 다른 실시예들에서, 컨테이너들의 사이즈들은 컨테이너들이 생성되는 인스턴스들의 사이즈에 같거나 또는 그것보다 적은 임의의 부정의(arbitrary) 사이즈일 수 있다. 일부 실시예들에서, 컨테이너들의 사이즈들은 컨테이너들이 생성되는 인스턴스들의 사이즈에 같거나, 그것보다 적거나 또는 그것보다 더 큰 임의의 부정의(arbitrary) 사이즈일 수 있다. 컨테이너들의 사이즈들이 인스턴스의 사이즈를 얼마만큼 초과할 수 있는지는 인스턴스에 의해 제공된 용량을 초과하여 해당 컨테이너들이 얼마나 사용될 수 있을 것 같은지에 기반하여 결정될 수 있다.

비록 컨테이너들 (156B, 157A, 157B, 157C, 158A, 158B, 159A) 내부에 컴포넌트들은 도 1의 예제에 예시되지 않았지만, 각각의 이들 컨테이너들은 다양한 운영 체계들, 언어 런타임들, 라이브러리들, 및/또는 유저 코드를 가질 수 있다. 일부 실시예들에서, 인스턴스들은 그 위에 (예를 들어, 인스턴스-레벨 캐시에) 로딩된 유저 코드들을 가질 수 있고, 해당 인스턴스들내에 컨테이너들은 그 내부에 로딩된 유저 코드들을 또한 가질 수 있다. 일부 실시예들에서, 워커관리기 (140)는 활성 풀 (140A)에 인스턴스들의 리스트를 유지할 수 있다. 인스턴스들의 리스트는 해당 인스턴스들의 구성 (예를 들어, OS, 런타임, 컨테이너, 등)을 추가로 지정할 수 있다. 일부 실시예들에서, 워커 관리기 (140)는 워밍 풀 (130A)내 인스턴스들의 리스트에 대한 액세스를 가질 수 있다 (예를 들어, 인스턴스들의 수 및 유형을 포함). 다른 실시예들에서, 워커 관리기 (140)는 워밍 풀 (130A)내 가상 기계 인스턴스들의 지식을 가지지 않고 워밍 풀 관리기 (130)로부터 컴퓨트 용량을 요청한다.

요청이 성공적으로 프론트엔드 (120)에 의해 프로세스된 후에, 워커 관리기 (140)는 가상 컴퓨트 시스템 (110)상에서 유저 코드를 실행시키기 위한 요청을 서비스를 하기 위한 용량을 찾는다. 예를 들어, 만약 그 내부에 (예를 들어, 컨테이너 (156A)에 도시된 코드 (156A-3)) 로딩된 동일한 유저 코드를 갖는 컨테이너를 갖는 활성 풀 (140A)에 특정 가상 기계 인스턴스가 존재하면, 워커 관리기 (140)는 컨테이너를 요청에 할당할 수 있고 유저 코드가 컨테이너에서 실행되게 할 수 있다. 대안적으로, 만약 유저 코드가 가상 기계 인스턴스들 중 하나의 로컬 캐시에서 이용 가능하면 (예를 들어, 인스턴스 (158)상에 저장되지만 그러나 임의의 개별 컨테이너들에 속하지 않는), 워커 관리기 (140)는 이런 인스턴스상에 새로운 컨테이너를 생성할 수 있고, 컨테이너를 요청에 할당할 수 있고, 유저 코드가 컨테이너에 로딩되고 실행될 수 있게 할 수 있다.

만약 워커 관리기 (140)가 요청과 연관된 유저 코드가 활성 풀 (140A)내 임의의 인스턴스들 (예를 들어, 인스턴스의 컨테이너 또는 로컬 캐시에서) 상에서 발견되지 않는다고 결정하면, 워커 관리기 (140)는 활성 풀 (140A)내 임의의 인스턴스들이 요청과 연관된 유저에게 현재 할당된지 그리고 현재 요청을 핸들링하기 위한 컴퓨트 용량을 가지는지 여부를 결정할 수 있다. 만약 이런 인스턴스가 있다면, 워커 관리기 (140)는 인스턴스상에 새로운 컨테이너를 생성할 수 있고 컨테이너를 요청에 할당할 수 있다. 대안적으로, 워커 관리기 (140)는 추가로 유저에 할당된 인스턴스상에 현존하는 컨테이너를 구성할 수 있고, 컨테이너를 요청에 할당할 수 있다. 예를 들어, 워커 관리기 (140)는 만약 현재 유저 요청에 의해 요구된 특정 라이브러리가 그 위에 로딩되었다면 현존하는 컨테이너가 유저 코드를 실행시키기 위해 사용될 수 있다고 결정할 수 있다. 이런 경우에, 워커 관리기 (140)는 컨테이너상에 특정 라이브러리 및 유저 코드를 로드할 수 있고 유저 코드를 실행시키기 위해 컨테이너를 사용할 수 있다.

만약 활성 풀 (140A)이 현재 유저에 할당된 임의의 인스턴스들을 함유하지 않는다면, 워커 관리기 (140)는 워밍 풀 (130A)로부터 새로운 가상 기계 인스턴스를 끌어당기고(pull), 인스턴스를 요청과 연관된 유저에 할당하고, 인스턴스상에 새로운 컨테이너를 생성하고, 컨테이너를 요청에 할당하고, 유저 코드가 컨테이너상에 다운로드되고 실행되게 한다.

일부 실시예들에서, 가상 컴퓨트 시스템 (110)은 유저 코드가 수신된 (예를 들어, 프론트엔드 (120)에 의해) 후에 곧 유저 코드의 실행이 시작되도록 적응된다. 시간 기간은 유저 코드의 실행을 개시하는 것 (예를 들어, 유저와 관련된 가상 기계 인스턴스상의 컨테이너에서)과 유저 코드를 실행시키기 위한 요청을 수신하는 것 (예를 들어, 프론트엔드에 의해 수신된) 사이의 시간 차이로서 결정될 수 있다. 가상 컴퓨트 시스템 (110)은 미리 결정된 지속기간 보다 작은 시간 기간내에서 유저 코드의 실행을 시작하도록 적응된다. 일 실시예에서, 미리 결정된 지속기간은 500 ms이다. 다른 실시예에서, 미리 결정된 지속기간은 300 ms이다. 다른 실시예에서, 미리 결정된 지속기간은 100 ms이다. 다른 실시예에서, 미리 결정된 지속기간은 50 ms이다. 다른 실시예에서, 미리 결정된 지속기간은 10 ms이다. 다른 실시예에서, 미리 결정된 지속기간은 10 ms 내지 500 ms의 범위에서 선택된 임의의 값일 수 있다. 일부 실시예들에서, 가상 컴퓨트 시스템 (110)은 만약 하나 이상의 상태들이 충족되면 미리 결정된 지속기간 보다 작은 시간 기간내에서 유저 코드의 실행을 시작하도록 적응된다. 예를 들어, 하나 이상의 상태들은 : (1) 유저 코드가 요청이 수신된 시간에 활성 풀 (140A)에 컨테이너상에 로딩된다; (2) 유저 코드가 요청이 수신된 시간에 활성 풀 (140A)에 인스턴스의 코드 캐시에 저장된다; (3) 활성 풀 (140A)은 요청이 수신된 시간에 요청와 관련된 유저에 할당된 인스턴스를 함유한다; 또는 (4) 워밍 풀 (130A)은 요청이 수신된 시간에 요청을 핸들링하기 위한 용량을 가진다 중 임의의 하나를 포함할 수 있다. 일부 실시예들에서, 코드 실행 요청이 수신되지마자 요청된 코드 실행을 개시하는 대신에, 가상 컴퓨트 시스템 (110)은 요청에 의해 제공된 스케줄링 정보에 따른 코드 실행을 스케줄링할 수 있다. 예를 들어, 요청은 가상 컴퓨트 시스템 (110)이 코드 실행을 수행하도록 요청된 시간 윈도우 (예를 들어, 다음주 월요일 3:00 AM와 4:00 AM 사이)를 지정할 수 있고, 가상 컴퓨트 시스템 (110)은 어떤 성능 고려사항들 (예를 들어, 워크로드, 레이턴시, 등)에 기초하여 코드 실행을 스케줄링할 수 있다. 스케줄링 프로세스는 도면들 6 및 7에 대하여 이하에서 더 상세하게 설명된다.

유저 코드는 보조 서비스 (106) 예컨대 도 1의 스토리지 서비스 (108)로부터 다운로드될 수 있다. 도 1에 예시된 데이터 (108A)는 한명 이상의 유저들에 의해 업로딩된 유저 코드들, 이런 유저 코드들과 관련된 메타데이터, 또는 본 출원에서 설명된 하나 이상의 기술들을 수행하기 위해 가상 컴퓨트 시스템 (110)에 의해 사용되는 임의의 다른 데이터를 포함할 수 있다. 비록 단지 스토리지 서비스 (108)만이 도 1의 예에 예시되지만, 가상 환경 (100)은 유저 코드가 다운로드될 수있는 다른 레벨들의 스토리지 시스템들을 포함할 수 있다. 예를 들어, 각각의 인스턴스는 컨테이너가 생성된 인스턴스와 관련된 물리적인 (예를 들어, 인스턴스가 운용하고 있는 물리적 컴퓨팅 시스템상에 상주하는 로컬 스토리지) 또는 논리적인 (예를 들어, 가상 컴퓨트 시스템 (110)의 안쪽에 또는 바깥쪽에 제공되고 그리고 인스턴스와 네트워크 통신상태에 있는 네트워크-부착된 스토리지 시스템) 하나 이상의 스토리지 시스템들을 가질 수 있다. 대안적으로, 코드는 스토리지 서비스 (108)에 의해 제공된 웹 기반 데이터 저장소로부터 다운로드될 수 있다.

일단 워커 관리기 (140)가 유저 코드 실행 요청을 서비스하기 위해 사용될 수 있는 워밍 풀 (130A)에 가상 기계 인스턴스들 중 하나를 위치시킨 후에, 워밍 풀 관리기 (130) 또는 워커 관리기 (140)는 워밍 풀 (130A)로부터 인스턴스를 취하고 그것을 요청과 관련된 유저에 할당한다. 할당된 가상 기계 인스턴스는 워밍 풀 (130A)로부터 취해지고 활성 풀 (140A)에 배치된다. 일부 실시예들에서, 일단 가상 기계 인스턴스가 특정 유저에 할당된 후에, 동일한 가상 기계 인스턴스는 임의의 다른 유저의 요청들을 서비스하기 위해 사용될 수 없다. 이것은 가능한 유저 자원들의 공동 혼입(co-mingling)을 방지함으로써 유저들에게 보안 장점들을 제공한다. 대안적으로, 일부 실시예들에서, 상이한 유저들 (또는 상이한 유저들과 관련된 요청들에 할당된)에 속하는 다수의 컨테이너들은 단일 가상 기계 인스턴스상에 공존할 수 있다. 이런 접근법은 이용 가능한 컴퓨트 용량의 활용을 개선시킬 수 있다. 일부 실시예들에서, 가상 컴퓨트 시스템 (110)은 유저 코드들이 저장되는 별개의 캐시를 유지할 수 있어서 가상 기계 인스턴스들의 로컬 캐시와 웹 기반 네트워크 스토리지 (예를 들어, 네트워크 (104)를 통해 가능한 액세스) 사이의 캐싱 시스템의 중간 레벨로서 역할을 한다.

유저 코드가 실행된 후에, 워커 관리기 (140)는 유저 코드를 실행시키기 위해 사용된 컨테이너를 분해하여 인스턴스내 다른 컨테이너들에 대하여 사용되기 위해 그것이 차지하고 있는 자원들을 자유롭게 한다. 대안적으로, 워커 관리기 (140)는 그것을 사용하기 위해 운용하는 컨테이너를 동일한 유저로부터의 추가 요청들을 서비스하도록 유지할 수 있다. 예를 들어, 만약 컨테이너에 이미 로딩되어진 동일한 유저 코드와 관련된 다른 요청이 수신되면, 해당 요청이 동일한 컨테이너에 할당될 수 있으면, 그렇게 함으로써 새로운 컨테이너를 생성하고 유저 코드를 컨테이너에 로딩하는 것과 관련된 지연을 배제한다. 일부 실시예들에서, 워커 관리기 (140)는 유저 코드를 실행시키기 위해 사용된 컨테이너가 생성되었던 인스턴스를 분해(tear down)할 수 있다. 대안적으로, 워커 관리기 (140)는 그것을 사용하기 위해 운용하는 인스턴스를 동일한 유저로부터의 추가 요청들을 서비스하도록 유지할 수 있다. 유저 코드가 실행된 후에 컨테이너 및/또는 인스턴스 운용하는 것을 유지할지 말지의 결정은 임계 시간, 유저의 유형, 유저의 평균 요청 볼륨, 주기성 정보 (예를 들어, 그 위에서서 현재 유저 코드를 실행하고 있지 않는 활성 풀 (140A)에 컨테이너들/인스턴스들은 (i) 만약 주기성 정보가 추가 요청들이 곧 도달될 것으로 예상된다고 표시하면 계속 존속시킬 수 있거나 또는 (ii) 만약 주기성 정보가 추가 요청들이 컨테이너들/인스턴스들을 계속 존속시키는 것을 정당화할 만큼 충분히 곧 도달하지 않을 것을 표시하면 종료될 수 있다), 및/또는 다른 동작 상태들에 기반될 수 있다. 예를 들어, 임의의 활동 (예를 들어, 코드의 운용) 없이 임계값 시간이 경과된 후에(예를 들어, 5 분, 30 분, 1 시간, 24 시간, 30 일, 등), 컨테이너 및/또는 가상 기계 인스턴스는 셧다운되고 (예를 들어, 삭제되고, 종료(terminated)되고, 등), 할당된 자원들은 릴리즈(release)된다. 일부 실시예들에서, 컨테이너가 분해되기 전에 경과된 임계값 시간은 인스턴스가 분해되기 전에 경과된 임계값 시간보다 더 짧다.

일부 실시예들에서, 가상 컴퓨트 시스템 (110)은 보조 서비스들이 착신 코드 실행 요청들을 서비스할 때 보조 서비스들 (106) 중 하나 이상에 데이터를 제공할 수 있다. 예를 들어, 가상 컴퓨트 시스템 (110)은 모니터링/로깅/과금 서비스들 (107)과 통신할 수 있다. 모니터링/로깅/과금 서비스들 (107)은 : 가상 컴퓨팅 시스템 (110)상에 컨테이너들 및 인스턴스들의 상태들과 같은 가상 컴퓨트 시스템 (110)로부터 수신된 모니터링 정보를 관리하기 위한 모니터링 서비스; 가상 컴퓨트 시스템 (110)상에 컨테이너들 및 인스턴스들에 의해 수행된 활동들과 같은 가상 컴퓨트 시스템 (110)로부터 수신된 로깅 정보를 관리하기 위한 로깅 서비스; 및 가상 컴퓨트 시스템 (110)상에서 유저 코드를 실행하는 것과 관련된 과금 정보를 생성하기 위한 과금 서비스 (예를 들어, 모니터링 서비스 및 로깅 서비스에 의해 관리된 모니터링 정보 및/또는 로깅 정보에 기초하여)를 포함할 수 있다. 상기에서 설명된 모니터링/로깅/과금 서비스들 (107) (예를 들어, 가상 컴퓨트 시스템 (110)을 대신하여)에 의해 수행될 수 있는 시스템-레벨 활동들에 추가하여, 모니터링/로깅/과금 서비스들 (107)은 가상 컴퓨트 시스템 (110)상에서 실행되는 유저 코드를 대신하여 애플리케이션-레벨 서비스들을 제공할 수 있다. 예를 들어, 모니터링/로깅/과금 서비스들 (107)은 가상 컴퓨트 시스템 (110)상에서 실행되고 있는 유저 코드를 대신하여 다양한 입력들, 출력들, 또는 다른 데이터 및 파라미터들을 모니터링할 수 있고 및/또는 로깅할 수 있다. 비록 단일 블럭으로 도시되었지만, 모니터링, 로깅, 및 과금 서비스들 (107)은 별개의 서비스들로서 제공될 수 있다.

일부 실시예들에서, 워커 관리기 (140)는 워커 관리기 (140)에 의해 관리되는 인스턴스들 및 컨테이너들(예를 들어, 활성 풀 (140A)에 있는 것들) 상에 헬스 체크(health check)들을 수행할 수 있다. 예를 들어, 워커 관리기 (140)에 의해 수행되는 헬스 체크들은 워커 관리기 (140)에 의해 관리되는 인스턴스들 및 컨테이너들이 임의의 이슈들의 (1) 잘못구성된(misconfigured) 네트워킹 및/또는 스타트업 구성, (2) 고갈된(exhausted) 메모리, (3) 붕괴된(corrupted) 파일 시스템, (4) 호환 불가능한 커널, 및/또는 인스턴스들 및 컨테이너들의 성능을 악화시킬 수 있는 임의의 다른 문제들을 가지고 있는지 여부를 결정하는 단계를 포함할 수 있다. 일 실시예에서, 워커 관리기 (140)는 주기적으로 (예를 들어, 매 5 분, 매 30 분, 매 시간, 매 24 시간, 등) 헬스 체크들을 수행한다. 일부 실시예들에서, 헬스 체크들의 빈도는 헬스 체크들의 결과에 기초하여 자동으로 조절될 수 있다. 다른 실시예들에서, 헬스 체크들의 빈도는 유저 요청들에 기초하여 조절될 수 있다. 일부 실시예들에서, 워커 관리기 (140)는 워밍 풀 (130A)내 인스턴스들 및/또는 컨테이너들상에서 유사한 헬스 체크들을 수행할 수 있다. 워밍 풀 (130A)내 인스턴스들 및/또는 컨테이너들은 활성 풀 (140A)에 해당 인스턴스들 및 컨테이너들과 함께 또는 별개로 관리될 수 있다. 일부 실시예들에서, 워밍 풀 (130A)내 인스턴스들 및/또는 컨테이너들의 헬스가 활성 풀 (140A)과 별개로 관리되는 경우에, 워커 관리기 (140) 대신 워밍 풀 관리기 (130)가 워밍 풀 (130A)내 인스턴스들 및/또는 컨테이너들상에서 상기에서 설명된 헬스 체크들을 수행할 수 있다.

스케줄링 관리기(Scheduling Manager)

스케줄링 관리기 (150)는 가상 컴퓨트 시스템 (110) (예를 들어, 프론트엔드 (120)를 통하여)에 의해 수신된 코드 실행 요청들을 모니터링하고 대응하는 코드 실행들을 스케줄링한다. 예를 들어, 스케줄링 관리기 (150)는 작업들(예를 들어, 가상 컴퓨트 시스템 (110)상에서의 유저 코드의 실행)을 스케줄링하고 및/또는 워밍 풀 (130A) 및/또는 활성 풀 (140A)내 컴퓨트 용량을 관리하기 위해서 프론트엔드 (120), 워밍 풀 관리기 (130), 및/또는 워커 관리기 (140)과 통신할 수 있다. 비록 스케줄링 관리기 (150)는 가상 컴퓨트 시스템 (110)내에 별개의 컴포넌트로서 예시되었지만, 스케줄링 관리기 (150)의 일부 또는 모든 기능들은 프론트엔드 (120), 워밍 풀 관리기 (130), 및/또는 워커 관리기 (140)에 의해 수행될 수 있다. 예를 들어, 스케줄링 관리기 (150)는 가상 컴퓨트 시스템 (110)의 다른 컴포넌트들 중 하나내에 전체가 또는 가상 컴퓨트 시스템 (110)의 다른 컴포넌트들에 걸쳐서 분배된 방식으로 구현될 수 있다. 도 1의 예에서, 스케줄링 관리기 (150)는 스케줄링 관리 데이터 (150A)를 포함한다. 스케줄링 관리 데이터 (150A)는 가상 컴퓨트 시스템상에서 수행될 요청된 작업들을 예견, 스케줄링, 및 재-스케줄링하고 따라서 가상 컴퓨트 시스템 (110)에 의해 사용되고 관리되는 용량을 조정하고 및/또는 최적화하기 위해 스케줄링 관리기 (150)에 의해 사용될 수 있는 착신 요청들의 이력, 워밍 풀 (130A)내 용량, 활성 풀 (140A)내 용량, 특정 프로그램 코드들 및/또는 유저 계정들과 연관된 주기성, 및 임의의 다른 메트릭(metric)에 관한 데이터를 포함할 수 있다. 스케줄링 관리 데이터 (150A)는 가상 컴퓨트 시스템 (110)에 의해 수신된 착신 요청들을 스케줄링하고 관리하기 위해 스케줄링 관리기 (150)에 의해 결정되거나 또는 유저들에 의해 지정된 임의의 관리 정책들 (예를 들어, 소정의 유저와 관련된 작업들을 스케줄링하기 위해 스케줄링 관리기 (150)에 제공되는 가요성(flexibility)의 양)을 또한 포함할 수 있다. 스케줄링 관리 데이터 (150A)는 가상 컴퓨트 시스템 (110)에 내부 스토리지 디바이스에 저장될 수 있거나, 또는 외부 스토리지 디바이스 (예를 들어, 스토리지 서비스 (108))에 저장될 수 있고 주기적으로 백업(back up)될 수 있다.

스케줄링 관리기 (150)는 가상 컴퓨트 시스템 (110)에 의해 수신된 코드 실행 요청들을 모니터링하고 착신 코드 실행 요청들에 의해 보여진 임의의 주기성을 식별한다. 예를 들어, 스케줄링 관리기 (150)는 특정 유저 계정 또는 유저 기능과 관련된 코드 실행 요청들이 수신된 특정 시간들에 패턴을 찾을 수 있다. 예를 들어, 스케줄링 관리기 (150)는 특정 유저 계정과 연관된 요청들은 3:00 AM과 3:15 AM 사이에만 수신된다는 것을 결정할 수 있다 (예를 들어, 이런 요청들은 매일 유지보수 동작(maintenance operation)들을 포함할 수 있다). 다른 예에서, 스케줄링 관리기 (150)는 특정 프로그램 코드와 연관된 요청들이 단지 일요일에만 수신된다는 것을 결정할 수 있다 (예를 들어, 이런 요청들은 매주 백업 동작들을 포함할 수 있다). 다른 예에서, 스케줄링 관리기 (150)은 시스템-와이드(system-wide) 트래픽이 일반적으로 7:00 PM와 9:00 PM 사이에 가장 높다는 것을 결정할 수 있다. 일부 경우들에서, 어떤 유저 계정들 또는 유저 기능들과 연관된 착신 코드 실행 요청들은 하루내내 또는 임의의 식별가능한 주기성을 나타내지 않고서 수신될 수 있다.

일부 실시예들에서, 스케줄링 관리기 (150)는 착신 트래픽 패턴들의 회귀 모델(regression model)들을 이용하여 주기성을 검출한다. 다른 실시예들에서, 스케줄링 관리기 (150)는 착신 코드 실행 요청들과 연관된 파라미터들에 기초하여 (예를 들어, 수신시간, 관련된 유저 계정, 관련된 유저 기능, 최대 지속기간, 할당될 자원들의 양, 등) 스케줄링 관리기 (150)에 의해 생성된 로그 데이터(log data) (예를 들어, 스케줄링 관리 데이터 (150A))로부터 주기성을 역으로 처리할 수 있다. 예를 들어, 스케줄링 관리기 (150)는 착신 코드 실행 요청들에 의해 보이는 주기성을 식별하기 위해 스케줄링 관리 데이터 (150A)를 주기적으로 (예를 들어, 매일, 매주, 매월, 매년, 등) 분석할 수 있다. 일부 실시예들에서, 인간 운영자는 착신 코드 실행 요청들에 주기성을 인지할 수 있고 가상 컴퓨트 시스템 (110)으로 어떤 주기성 파라미터들을 (예를 들어, 예상되는 수신 시간, 관련된 유저 계정, 관련된 유저 기능, 등) 입력할 수 있다. 식별된 주기성에 기초하여, 스케줄링 관리기 (150)는 가상 컴퓨트 시스템 (110)상에서 유지되는 용량을 조정할 수 있다. 주기성 식별 및 가상 컴퓨트 시스템 (110)상에서 유지되는 용량을 조정하는 프로그세스가 도 5를 참고로 하여 이하에서 더 상세하게 설명된다.

스케줄링 관리기 (150)는 또한 가상 컴퓨트 시스템 (110)상에서 코드 실행을 스케줄링 및 관리할 수 있다. 만약 코드 실행들의 배치(batch)가 동시에 또는 시간의 짧은 스팬(span)내에 수행되도록 요청되면, 스케줄링 관리기 (150)는 유저 코드를 실행하기 위해 지정된 시간프레임에 의해 제공된 가요성(flexibility)의 정도에 의존하여 코드 실행들의 일부를 리스케줄링할 수 있다. 실행의 타이밍에서 가요성을 획득하는 한가지 방법은 해당 요청으로 범위를 건조하는 것이어서 지정된 시간에 실행될 클라우드 기능을 스케줄링하기 위한 임의의 요청은 실제로 클라우드 기능이 지정된 시간전에 및 그 후에 시간 기간내에 실행될 것이라는 것을 의미한다. 예를 들어, 만약 프로그램 코드가 3:00 PM에 실행되도록 요청되면, 가상 컴퓨트 시스템 (110)은 자동으로, 2:50 PM과 3:10 PM 사이의 임의의 시간에 코드를 실행하는 가요성을 가질 수 있다. 가상 컴퓨트 시스템 (110)의 유저들은 이 범위에 대하여 인지할 수 있다. 범위는 구현예에 의존하여 변화할 수 있다.

일부 실시예들에서, 가상 컴퓨트 시스템 (110)상에서 유저 기능들 실행과 관련된 경비(cost)는 요청에 의해 지정된 시간적인 가요성의 정도에 의존하여 변화할 수 있다. 예를 들어, 만약 유저가 프로그램 코드가 11:00 PM과 1:00 AM 사이에 운용될 것을 요청받으면, 경비는 매 실행 마다 0.01 cents일 수 있다. 예를 들어, 만약 유저가 프로그램 코드가 11:55 PM과 1:05 AM 사이에 운용될 것을 요청받으면, 경비는 매 실행 마다 0.02 cents일 수 있다. 만약 유저가 프로그램 코드가 12:00 AM에 운용될 것을 요청받으면, 경비는 매 실행 마다 0.05 cents일 수 있다. 가상 컴퓨트 시스템 (110)에 많은 가요성을 제공하는 다른 예제는 유저들이 요청 도달 비율들, 프로세스되는 동시 작업들 수, 또는 다른 메커니즘들 (윈도우를 지정하는 것보다 덜 값비쌀 수 있는)에 의해 결정되는 트래픽이 낮을 때마다 유저 기능들이 운용될 수 있는 것을 지정하는 것을 허용하는 것이다.

컴퓨트 시스템 (110)은 코드 실행 요청들에 대하여 지정될 수 있는 다양한 범위들과 연관된 경비를 유저에게 제공할 수 있다(예를 들어, 유저 스케줄 코드 실행들을 허용하는 그래픽 유저 인터페이스를 통하여). 시작 시간들에서 가용성은 착신 트래픽이 낮을 때 코드 실행들을 스케줄링하는 능력을 가상 컴퓨트 시스템 (110)에 제공하고, 그렇게 함으로써 가상 컴퓨트 시스템 (110)이 제공할 필요가 있는 버스트 용량의 양을 줄인다.

일부 실시예들에서, 가요성을 획득하기 위해 범위를 이용하는 것보다, 유저는 가상 컴퓨트 시스템 (110)이 프로그램을 운용하도록 요청되기 전에 또는 그 후에 시간에 지점을 지정할 수 있다. 예를 들어, 요청은 가상 컴퓨트 시스템 (110)이 10월 10일 후에 머지 않아 (예를 들어, 지정된 날짜에 또는 그 후에) 프로그램 코드를 운용하여야 한다고 지정할 수 있다. 다른 예에서, 요청은 가상 컴퓨트 시스템 (110)이 10월 8일 전에 머지 않아 (예를 들어, 10월 8일에 또는 그 전에 프로그램 코드 실행 마치기) 프로그램 코드 운용을 마쳐야 한다고 지정할 수 있다. 이런 예에서, 가상 컴퓨트 시스템 (110)은 코드 실행이 지정된 데드라인전에 적어도 최대 지속기간에 동등한 시간의 양이 개시된다는 것을 보장할 수 있다. 또 다른 예에서, 요청은 가상 컴퓨트 시스템 (110)이 10월 8일 전에 머지 않아 (예를 들어, 10월 8일에 또는 그 전에 프로그램 코드 실행 개시, 그러나 10월 8일에 또는 그 전에 마칠 필요는 없다) 프로그램 코드 운용을 시작하여야 한다고 지정할 수 있다. 일부 실시예들에서, 각각의 코드 실행 요청은 프로그램 코드의 실행이 그 후에 타임 아웃되는 것을 고려하여야 하는 최대 지속기간(maximum duration)을 지정한다. 이런 실시예들에서, 가상 컴퓨트 시스템 (110)은 가상 컴퓨트 시스템 (110)이 임의의 주어진 시간 지점에서 오버로딩(overload)되지 않도록 워크로드(workload)를 분산시키기 위해 지정된 최대 지속기간을 활용할 수 있다. 가요적 방식으로 코드 실행들을 스케줄링하는 프로세스는 도 6를 참고로 하여 이하에서 더 상세하게 설명된다.

스케줄링 관리기 (150)은 가상 컴퓨트 시스템 (110)에 의해 수신된 요청들을 모니터링하기 위한 요청 및 용량 모니터링 유닛, 및 가상 컴퓨트 시스템 (110)상에서의 코드 실행 및 용량을 스케줄링 및 관리하기 위한 스케줄링 및 용량 조절 유닛을 포함할 수 있다. 스케줄링 관리기(150)의 예시 구성이 도 4를 참고로 하여 이하에서 더 상세하게 설명된다.

주기적인 작업들을 프로세싱하는 예시적인 예제

도 2를 참고로 하여, 스케줄링 관리기 (150)를 갖거나(오른쪽) 및 스케줄링 관리기를 갖지 않는(왼쪽) 가상 컴퓨트 시스템 (110)내 워밍 풀 관리기 (130)가 설명될 것이다. 도 2의 예제에서, 주기적인 요청들 (210)이 가상 컴퓨트 시스템 (110)에 의해 수신된다.

도 2의 좌측에 예제는 주기적인 요청들 (210)의 주기성을 인식할 수 없는 시스템을 예시한다. 도 2의 예제에서, 주기적인 요청들 (210)의 다섯개의 화살표는 지정된 시간에 수신된 코드 실행 요청을 각각 나타낼 수 있다 (예를 들어, X + T, X + 2T, X + 3T, X + 4T, 및 X + 5T, 여기서 T는 주기(period)이다). 이 예에서, 가상 컴퓨트 시스템 (110)은 가상 기계 인스턴스들 (220,230,240, 및 250)(각각은 그 위에 로딩된 적절한 OS 및 런타임을 갖는)을 포함하는 워밍 풀 (130A)을 포함한다. 코드 실행 요청들이 수신될 때를 알지 못하는, 가상 컴퓨트 시스템 (110)은 예를 들어, 병렬로 이들 작업들의 전부를 운용하기 위해 차지함으로써 임의의 버스트 트래픽을 수용하기 위해 그것의 워밍 풀 (130A)내 큰 양의 컴퓨트 용량을 유지하는 것이 필요로 할 수 있다.

도 2의 우측에 예제는 주기적인 요청들 (210)의 주기성을 식별하는 시스템을 예시한다. 이 예에서, 가상 컴퓨트 시스템 (110)은 가상 기계 인스턴스 (220)( 그 위에 로딩된 OS(220A) 및 런타임(220B)을 갖는)를 포함하는 워밍 풀 (130A)을 포함한다. 주기적인 요청들 (210)이 수신될 때를 아는, 가상 컴퓨트 시스템 (110)은 그것의 워밍 풀 (130A)에 축소된 양의 용량을 유지할 수 있고, 그것들이 수신되기 바로 전에 주기적인 요청들 (210)을 프로세스하기 요구되는 컴퓨트 용량을 획득할 수 있다. 예를 들어, 5 작업들이 주기적이고 따라서 중첩되지 않는 것을 아는 것은 80%만큼 초과 용량(excess capacity)의 양을 축소할 있다(병렬로 5 작업들을 수행하기에 충분한 용량을 유지하는 것에 비교하여). 다른 예에서, 만약 가상 컴퓨트 시스템 (110)이 평균하여 매일 10 요청(request)들을 수신하면, 그것들의 5의 주기성을 아는 것은(예를 들어, 이들 요청들은 개별적으로 매일 1:00 PM, 2:00 PM, 3:00 PM, 4:00 PM, 및 5:00 PM에 수신된다) 얼마나 많은 용량을 워밍 풀 (130A)내 유지할 지를 결정하는 목적을 위해서 가상 컴퓨트 시스템 (110)이 이들 요청들을 무시하는 것을 허용할 수 있고 (왜냐하면 그것들이 도달할 때를 알기 때문에, 용량은 그것들의 도달 예상 시간 바로 전에 추가될 수 있다), 반 만큼 워밍 풀 용량을 줄일 것이다. 따라서, 착신 코드 실행 요청들에 주기성의 추적을 식별 및 유지함으로써, 가상 컴퓨트 시스템 (110)은 그것이 그것의 워밍 풀 (130A)에 유지해야만 하는 가상 기계 인스턴스들의 수에어서의 감소와 관련된 경비 절감을 실현할 수 있다.

작업들 스케줄링하는 예시적인 예제

도 3을 참고로 하여, 스케줄링 관리기 (150)가 작업들을 스케줄링(또는 재-스케줄링) 하기 전에(오른쪽) 및 그 후에(왼쪽) 가상 컴퓨트 시스템 (110)내 워커 관리기 (140)가 설명될 것이다. 도 3의 예제에서, 작업들 (301-304)은 가상 컴퓨트 시스템 (110)의 유저들에 의해 요청되고 예를 들어, 가상 컴퓨트 시스템 (110)의 스케줄링 관리기 (150) 스케줄링된다.

도 3의 좌측의 예제는 모든 작업들 (301-304)이 12:00 AM에 시작하도록 스케줄링되는 것을 예시한다. 작업들 (301-304)의 전부를 운용하기 위해서, 활성 풀 (140A)은 4 가상 기계 인스턴스들 (예를 들어, 인스턴스들 (310,320,330), 및 340), 각각이 적절한 OS, 런타임, 및 코드로 로딩된) 또는 컨테이너들이 운용될 것을 필요로 할 수 있다. 스케줄링 작업들 (301-304)에서의 가요성이 없는, 가상 컴퓨트 시스템 (110)은 큰 양의 가상 기계 인스턴스들을 동시에 운용하는 것을 필요로 할 수 있고, 결과적으로, 증가된 레이턴시 및/또는 임의의 다른 이슈들을 경험할 수 있다.

도 3의 우측에 예제는 스케줄링 관리기 (150)가 스케줄링된 작업들 (301-304)을 분산시켜서 단지 단일 작업만이 임의의 주어진 시간에 수행되는 시스템을 예시한다. 스케줄링 작업들 스케줄링에서 가용성을 갖고 가요성에 기반하여 워크로드를 분산시킴으로써, 가상 컴퓨트 시스템 (110)은 더 적은 수의 가상 기계 인스턴스들을 이용하여 동작할 수 있고 큰 양의 동시 작업들을 프로세스해야 함으로써 과중부담(overburden)되는 것을 방지할 수 있거나 또는 경비를 절감할 수 있다.

스케줄링 관리기의 전반적인 아키텍처

도 4는 가상 컴퓨트 시스템 (110)에 가상 기계 인스턴스들을 관리하는 컴퓨팅 시스템 (스케줄링 관리기 (150)로서 언급된)의 전반적인 아키텍처를 도시한다. 도 4에 도시된 스케줄링 관리기 (150)의 전반적인 아키텍처는 본 발명의 측면들을 구현하기 위해 사용될 수 있는 컴퓨터 하드웨어 및 소프트웨어 모듈들의 배열을 포함한다. 스케줄링 관리기 (150)는 도 4 에 도시된 것들보다 더 많은 (또는 더 적은) 엘리먼트들을 포함할 수 있다. 그러나, 인에이블링 개시를 제공하기 위해 이들 전체적인 통상의 엘리먼트들의 전부가 도시되는 것을 필요하지 않다. 예시된 바와 같이, 스케줄링 관리기 (150)는 프로세싱 유닛 (190), 네트워크 인터페이스 (192), 컴퓨터 판독가능한 매체 드라이브 (194), 입력/출력 디바이스 인터페이스 (196)를 포함하고, 이들 전부는 통신 버스의 방식으로 서로와 통신할 수 있다. 네트워크 인터페이스 (192)는 하나 이상의 네트워크들 또는 컴퓨팅 시스템들에 대한 연결을 제공할 수 있다. 프로세싱 유닛 (190)은 따라서 네트워크 (104)를 통하여 다른 컴퓨팅 시스템들 또는 서비스들로부터 정보 및 지시들을 수신할 수 있다. 프로세싱 유닛 (190)은 또한 메모리 (180)로부터 그리고 메모리에 통신할 수 있고 그리고 입력/출력 디바이스 인터페이스 (196)를 통하여 옵션의 디스플레이 (미도시)에 대하여 출력 정보를 추가로 제공할 수 있다. 입력/출력 디바이스 인터페이스 (196)는 또한 옵션의 입력 디바이스 (미도시)로부터 입력을 수용할 수 있다.

메모리 (180)는 본 발명의 하나 이상의 측면들을 구현하기 위해 프로세싱 유닛 (190)이 실행하는 컴퓨터 프로그램 지시들 (일부 실시예들에서 모듈들로서 그룹화된)을 함유할 수 있다. 메모리 (180)는 일반적으로 RAM, ROM 및/또는 다른 영구, 보조 또는 비-일시적 컴퓨터 판독가능한 매체들을 포함한다. 메모리 (180)는 스케줄링 관리기 (150)의 동작 및 전체적인 관리에서 프로세싱 유닛 (190)에 의한 사용을 위한 컴퓨터 프로그램 지시들을 제공하는 운영 체계 (184)을 저장할 수 있다. 메모리 (180)는 본 발명의 측면들을 구현하기 위한 컴퓨터 프로그램 지시들 및 다른 정보를 더 포함할 수 있다. 예를 들어, 일 실시예에서, 메모리 (180)는 예를 들어, 컴퓨팅 디바이스상에 인스톨된 브라우저 또는 애플리케이션과 같은 네비게이션 및/또는 브라우징 인터페이스를 통하여 컴퓨팅 디바이스상에 디스플레이를 위해서 유저 인터페이스들 (및/또는 그것을 위한 지시들)을 생성하는 유저 인터페이스 유닛 (182)을 포함한다. 추가하여, 메모리 (180)는 예를 들어, 유저 프로그램 코드들 및/또는 라이브러리들을 액세스하기 위한 하나 이상의 데이터 저장소들(미도시)을 포함할 수 있고 및/또는 저장소들과 통신할 수 있다.

유저 인터페이스 유닛 (182)에 추가하여 및/또는 그것과 조합하여, 메모리 (180)는 프로세싱 유닛 (190)에 의해 실행될 수 있는 요청 및 용량 모니터링 유닛 (186) 및 스케줄링 및 용량 조절 유닛 (188)을 포함할 수 있다. 일 실시예에서, 유저 인터페이스 유닛 (182), 요청 및 용량 모니터링 유닛 (186), 및 스케줄링 및 용량 조절 유닛 (188)은 본 발명의 다양한 측면들, 예를 들어, 이하에서 추가 설명될 착신 코드 실행 요청들 모니터링, 착신 코드 실행 요청들이 임의의 주기성을 나타내는지 여부 결정, 축소된 양의 유휴상태 용량이 워밍 풀 (130A)에서 유지되도록 하기, 이런 착신 코드 실행 요청들이 수신되기 바로 전에 착신 코드 실행 요청들을 핸들링 하기 위한 컴퓨트 용량 획득(예를 들어, 그것들의 주기성에 기초하여), 다수의 작업들이 서로 중첩하지 않도록 그것들을 스케줄링, 등을 개별적으로 또는 총괄하여 구현한다.

요청 및 용량 모니터링 유닛 (186)은 착신 코드 실행 요청들을 모니터링한다. 예를 들어, 요청 및 용량 모니터링 유닛 (186)은 착신 코드 실행 요청들을 모니터링하고 가상 컴퓨트 시스템 (110)상에서의 용량을 더 잘 관리하기 위해 (예를 들어, 워밍 풀 (130A)에 유지되는 용량의 수를 축소) 사용될 수 있는 착신 코드 실행 요청들의 전부 또는 일부에 의해 나타내어진 임의의 주기성을 식별한다. 요청 및 용량 모니터링 유닛 (186)은 각각의 착신 코드 실행 요청들이 수신된 시간 및 요청된 실제 지속기간과 함께 이런 요청들과 연관된 유저 계정들 및/또는 유저 기능들 또는 다른 자원 소모, 예컨대 메모리의 추적을 계속 유지할 수 있다.

스케줄링 및 용량 조절 유닛 (188)은 작업들을 스케줄링하고 워밍 풀 (130A) 및/또는 활성 풀 (140A)내 용량을 조정한다. 예를 들어, 요청 및 용량 모니터링 유닛 (186)에 의해 식별된 주기성에 기초하여, 스케줄링 및 용량 조절 유닛 (188)은 워밍 풀 (130A)에 유지되는 용량의 양이 축소되도록 할 수 있다. 더구나, 스케줄링 용량 조절 유닛 (188)은 주기적인 것으로 식별된 코드 실행 요청들이 가상 컴퓨트 시스템 (110)에 의해 수신될 것으로 예상되는 시간 바로 전에 추가 용량이 활성 풀 (140A)에 추가되도록 할 수 있거나 또는 주기성 분석/예측들에 기초하여 예상된 장래 요청을 서비스하기 위해서 활성 풀(140A)내 용량이 평상시보다 더 길게 보유되도록 할 수 있다.

요청 및 용량 모니터링 유닛 (186) 및 스케줄링 및 용량 조절 유닛 (188)은 스케줄링 관리기 (150)의 일부로서 도 4에 도시되지만, 다른 실시예들에서, 요청 및 용량 모니터링 유닛 (186) 및 스케줄링 및 용량 조절 유닛 (188)의 전부 또는 일부는 가상 컴퓨팅 시스템 (110) 및/또는 다른 컴퓨팅 디바이스의 다른 컴포넌트들에 의해 구현될 수 있다. 예를 들어, 본 발명의 임의 실시예들에서, 가상 컴퓨트 시스템 (110)와 통신하는 다른 컴퓨팅 디바이스는 스케줄링 관리기 (150)의 부분으로서 예시된 모듈들 및 컴포넌트들에 유사하게 동작하는 몇몇의 모듈들 또는 컴포넌트들을 포함할 수 있다.

스케줄 코드 실행 요청들 관리하기 위한 예제 루틴

이제 도 5로 가서, 가상 컴퓨트 시스템 (110) (예를 들어, 스케줄링 관리기 (150))의 하나 이상의 컴포넌트들에 의해 구현된 루틴 (500)이 설명될 것이다. 비록 루틴 (500)은 스케줄링 관리기 (150)에 의한 구현예에 관해서 설명되지만, 관련 기술분야에 숙련된 기술자는 대안적인 컴포넌트들이 루틴 (500)을 구현할 수 있거나 또는 하나 이상의 블럭들이 상이한 컴포넌트에 의해 또는 분배된 방식으로 구현될 수 있다는 것을 인식할 것이다.

예시적인 루틴 (500)의 블럭 (502)에서, 스케줄링 관리기 (150)는 예를 들어, 착신 요청들에 의해 나타내어진는 임의의 주기성을 식별하기 위해 (예를 들어, 적어도 일부의 착신 요청들이 현실적으로 주기적이다는 임의의 표시) 가상 컴퓨트 시스템 (110)에 의해 수신된 착신 코드 실행 요청들을 모니터링한다. 스케줄링 관리기 (150)는 러닝 타임(running time) (지속기간), 메모리 사용량, 인가된 스로틀(throttle), 보안 테스트 통과 또는 실패를 포함하는 실제 자원소모와 함께 각각의 요청이 프로그램 코드 요청와 관련된 프로그램 코드의 아이덴티티와 함께 데이터베이스에 가상 컴퓨트 시스템 (110)에 의해 수신된 시간(예를 들어, 스케줄링 관리 데이터 (150A)), 요청과 관련된 유저 계정, 요청과 관련된 최대 지속기간, 및/또는 요청과 관련된 임의의 다른 파라미터들, 등을 레코딩할 수 있다.

다음으로, 블럭 (504)에서, 스케줄링 관리기 (150)는 임의의 주기성이 가상 컴퓨트 시스템 (110)에 의해 수신된 적어도 일부의 착신 코드 실행 요청들에 의해 보여지는지 여부를 결정한다. 예를 들어, 스케줄링 관리기 (150)는 특정 유저 계정과 연관된 요청들은 3:00 AM과 3:15 AM 사이에만 수신된다는 것을 결정할 수 있다 (예를 들어, 이런 요청들은 매일 유지보수 동작(maintenance operation)들을 포함할 수 있다). 다른 예에서, 스케줄링 관리기 (150)는 특정 프로그램 코드와 연관된 요청들이 단지 일요일에만 수신된다는 것을 결정할 수 있다 (예를 들어, 이런 요청들은 매주 백업 동작들을 포함할 수 있다). 다른 예에서, 스케줄링 관리기 (150)은 시스템-와이드(system-wide) 트래픽이 일반적으로 7:00 PM와 9:00 PM 사이에 가장 높다는 것을 결정할 수 있다. 일부 경우들에서, 어떤 유저 계정들 또는 유저 기능들과 연관된 착신 코드 실행 요청들은 하루내내 또는 임의의 식별가능한 주기성을 나타내지 않고서 수신될 수 있다. 심지어 이런 경우들에서, 식별가능한 주기성을 보이는 적어도 일부 코드 실행 요청들을 식별함으로써, 가상 컴퓨트 시스템 (110)은 스케줄링된 요청들로서 이런 코드 실행 요청들을 처리할 수 있다. 이런 주기적인 또는 스케줄링된 요청들은 요청들이 수신될 때를 만약 가상 컴퓨트 시스템 (110) 때문에 가상 컴퓨트 시스템 (110)에 대한 경비 절감으로 귀결되고, 가상 컴퓨트 시스템 (110)은 단지 예측할 수 없는 버스트 트래픽을 핸들링할 수 있도록 유휴상태 컴퓨트 용량 (비용이 많이 들수 있는)을 유지할 필요가 없고; 그것은 요청들이 가상 컴퓨트 시스템 (110)에 도달할 때 (또는 바로 전에) 컴퓨트 용량을 간단하게 획득할 수 있다. 일부 실시예들에서, 스케줄링 관리기 (150)는 임의의 주기성이 임의의 이런 코드 실행 요청들에 보여지는지 여부를 결정하기 위해서 착신 코드 실행 요청들에 기초하여 가상 컴퓨트 시스템 (110)에 의해 생성된 로그들 및/또는 메트릭들을 프로세스할 수 있다.

만약 스케줄링 관리기 (150)가 가상 컴퓨트 시스템 (110)에 의해 수신된 적어도 일부의 코드 실행 요청들이 어느 정도의 주기성을 보인다고 결정하면, 루틴 (500)은 블럭 (506)으로 진행하고, 여기서 스케줄링 관리기 (150)는 축소된 양의 유휴상태 컴퓨트 용량 (또는 특정 유저 계정에 배정되지 않거나 또는 작업들 사이에 있는 할당되지 않은 컴퓨트 용량)이 유지되도록(예를 들어, 워밍 풀 (130A)에) 한다. 예를 들어, 축소된 양은 주기적인 것으로 식별된 코드 실행 요청들의 수에 비례할 수 있다. 만약 어떤 코드 실행 요청들도 주기적인 것으로 식별되지 않으면, 워밍 풀 (130A)에 유지되는 유휴상태 컴퓨트 용량(idle compute capacity)는 전혀 축소되지 않을 수 있다. 반면에, 만약 모든 코드 실행 요청들이 주기적인 것으로 식별되면, 워밍 풀 (130A)에 유지되는 전체 유휴상태 컴퓨트 용량이 제거될 수 있다. 유사하게, 만약 코드 실행 요청들의 절반이 주기적인 것으로 식별되면, 워밍 풀 (130A)에 유지되는 유휴상태 컴퓨트 용량의 양은 워밍 풀(130A)에 정상적으로 유지도는 양의 절반까지 축소될 수 있다. 만약 스케줄링 관리기 (150)가 어떠한 코드 실행 요청들도 임의의 주기성을 보이지 않는다고 결정하면, 루틴 (500)은 블럭 (502)로 진행하고, 스케줄링 관리기 (150)는 착신 코드 실행 요청들을 계속 모니터링할 수 있다. 일부 실시예들에서, 스케줄링 관리기 (150) (또는 가상 컴퓨트 시스템 (110)의 다른 컴포넌트들 예컨대 워밍 풀 관리기 (130))는 워밍 풀 (130A)에 가상 기계 인스턴스들의 수가 축소된 양에 대응하는 수에 도달할 때까지 추가 가상 기계 인스턴스들을 워밍 풀 (130A)에 추가하는 것을 삼가함으로써 축소된 양의 유휴상태 컴퓨트 용량이 유지되도록 한다. 예를 들어, 만약 스케줄링 관리기 (150)가 워밍 풀 (130A)에 유지되는 유휴상태 용량이 착신 코드 실행 요청들에 보여진 주기성에 기초하여 절반까지 축소되어야 한다고 결정하면, 스케줄링 관리기 (150)는 워밍 풀 (130A)에 용량의 양이 워밍 풀 (130A)에 미리 유지되었던 양의 절반이 될 때까지 추가의 용량을 워밍 풀 (130A)에 추가하는 것을 삼가할 수 있다. 일부 경우들에서, 스케줄링 관리기 (150)는 축소된 수에 도달하기 위해서 워밍 풀 (130A)에 가상 기계 인스턴스들의 일부를 능동적으로 셧 다운할 수 있다. 다른 경우들에서, 스케줄링 관리기 (150)는 인스턴스들이 워밍 풀 (130A)로부터 활성 풀 (140A)로 보다 자유롭게(또는 공격적으로(aggressively)) 이동되도록 할 수 있다. 일부 실시예들에서, 유휴상태 컴퓨트 용량의 양에서의 감소는 활성 풀 (140A)로부터 기인할 수 있다. 예를 들어, 활성 풀 (140A)에 배치되지만 그러나 그렇지 않으면, (예를 들어, 주기성 정보없이) 활성 풀 (140A)에 유휴상태로 계속 존속될 그 위에 유저 코드를 현재 실행하지 않는 가상 기계 인스턴스들은 블럭 (504)에서 감지된 주기성에 기초하여 (예를 들어, 활성 풀 (140A)에 현재 유휴상태 인스턴스를 사용할 어떠한 요청도 머지 않은 임의 시간에 도달할 것으로 예상되는 않는다는 결정) 스핀 다운(spin down)될 수 있다.

블럭 (508)에서, 스케줄링 관리기 (150)는 예상했던 수신의 시간에 주기적인 것으로 식별된 착신 코드 실행 요청들 (또는 어느 정도의 주기성을 보이도록 결정된 착신 코드 실행 요청들과 동일한 주기성을 보이는 다음 요청)을 핸들링하기 위해 추가 컴퓨트 용량이 획득되도록 한다. 예를 들어, 만약, 식별된 주기성에 기초하여, 가상 컴퓨트 시스템 (110)이 3:00 PM에 코드 실행 요청들의 배치를 수신하도록 예상되면, 스케줄링 관리기 (150)는 요청들의 배치가 도달할 것으로 예상되는 시간의 얼마 전에 (예를 들어, 2:59 PM, 또는 가상 컴퓨트 시스템 (110)이 3:00 PM까지 요청들의 배치를 핸들링하도록 컴퓨트 용량을 구성하는 것을 허용할 시간) 코드 실행 요청들의 배치(batch)를 핸들링 하기에 충분한 추가 컴퓨트 용량 (예를 들어, 하나 이상의 가상 기계 인스턴스들)이 획득되도록 한다(예를 들어, 인스턴스 프로비저닝 서비스 (109)에 요청을 발송함으로써 또는 가상 컴퓨트 시스템 (110)의 다른 컴포넌트가 그렇게 하도록 지시함으로써). 예를 들어, 추가 컴퓨트 용량이 획득되고 미리-초기화되기 전 임계 시간의 양은 프로그램 코드, 유저 계정, 또는 요청에 기초하여 변화할 수 있다. 일부 경우들에서, 획득된 컴퓨트 용량은 활성 풀 (140A)에 직접 추가될 수 있다. 예를 들어, 만약 코드 실행 요청들의 배치가 실행 설정들이 알려진 유저와 관련되면, 요청들이 도달하자 마자 컴퓨트 용량이 사용될 수 있도록 획득된 컴퓨트 용량은 미리-초기화될 수 있고 활성 풀 (140)에 배치될 수 있다. 일부 실시예들에서, 추가 컴퓨트 용량은 활성 풀 (140A)에 배치되지만 그러나 그렇지 않으면, (예를 들어, 주기성 정보없이) 주기적인 것으로 식별된 코드 실행 요청들의 예상하에 활성 풀 (140A)에 유휴상태에서 종료될 그 위에 유저 코드를 현재 실행하지 않는 하나 이상의 가상 기계 인스턴스들을 계속 존속시킴으로써 추가될 수 있다. 다른 경우들에서, 획득된 컴퓨트 용량은 워밍 풀 (130A)에 추가될 수 있다. 예를 들어, 만약 스케줄링 관리기 (150)가 착신 코드 실행 요청들에 시스템-와이드 증가가 10 분안에 예상된다고 결정하면, 스케줄링 관리기 (150)는 추가 용량을 획득할 수 있고 이런 용량을 워밍 풀 (130A)에 추가하여서 추가된 용량이 보다 다양한 그룹의 요청들을 핸들링하기 위해 사용될 수 있다. 일부 실시예들에서, 스케줄링 관리기 (150) (또는 가상 컴퓨트 시스템 (110)의 다른 컴포넌트들 예컨대 워커 관리기 (140))는 요청들의 배치와 관련된 유저 기능들을 실행시키기 위해 획득된 가상 기계 인스턴스(들)상에 하나 이상의 컨테이너들을 생성할 수 있고, 요청들의 배치가 가상 컴퓨트 시스템 (110)에 의해 수신되기 전에 컨테이너(들)상에 유저 기능들을 로딩할 수 있다. 그렇게 함으로써, 스케줄링 관리기 (150)는 가상 기계 인스턴스들을 먼저 획득하고, 하나 이상의 컨테이너들을 그 위에 생성하고, 하나 이상의 유저 기능들을 컨테이너들 위로 로딩할 필요 없이, 요청들의 배치가 수신되자 마자 유저 기능들이 실행되는 것을 허용 함으로써 가상 컴퓨트 시스템 (110)상에서 유저 기능들을 실행하는 것과 관련된 지연을 줄인다.

도 5의 루틴 (500)은 블럭들 (502)-(508)를 참고로 하여 상기에서 설명되었지만, 본 출원에서 설명된 실시예들은 이에 제한되지 않고, 본 발명의 취지에 벗어나지 않고서 하나 이상의 블럭들이 생략되거나, 변형되거나, 또는 스위치될 수 있다.

시간 기준(temporal criteria)에 기초하여 코드 실행 요청들을 스케줄링하기 위한 예제 루틴

이제 도 6으로 가서, 가상 컴퓨트 시스템 (110) (예를 들어, 스케줄링 관리기 (150))의 하나 이상의 컴포넌트들에 의해 구현된 루틴 (600)이 설명될 것이다. 비록 루틴 (600)은 스케줄링 관리기 (150)에 의한 구현예에 관해서 설명되지만, 관련 기술분야에 숙련된 기술자는 대안적인 컴포넌트들이 루틴 (600)을 구현할 수 있거나 또는 하나 이상의 블럭들이 상이한 컴포넌트에 의해 또는 분배된 방식으로 구현될 수 있다는 것을 인식할 것이다.

예시적인 루틴 (600)의 블럭(602)에서, 스케줄링 관리기 (150)는 제 1 프로그램 코드를 실행시키기 위해 제 1 시간 프레임(time frame)을 갖는 제 1 작업 요청(job request)를 수신한다. 예를 들어, 제 1 작업 요청은 백업 루틴(backup routine)이 내일 3:00 AM 에 실행될것을 요청할 수 있다. 일부 실시예들에서, 요청에 의해 지정된 시간 프레임은 (i) 가상 컴퓨트 시스템이 해당 시간까지 제 1 프로그램 코드를 실행하도록 요청된 시간 (예를 들어, “3:00 AM까지 백업 루틴을 실행하지만 당신은 그 전 임의의 시간에 시작하게 할 수 있다”, (ii) 가상 컴퓨트 시스템이 해당 시간 후에 제 1 프로그램 코드를 실행하도록 요청된 시간(예를 들어, “3:00 AM 이후에 백업 루틴을 실행하지만 그러나 당신이 백업 루틴 개시하기 전에 당신은 훨씬 더 많이 시간이 걸릴 수 있다”), 또는 (iii) 가상 컴퓨트 시스템이 해당 시간내에 제 1 프로그램 코드를 실행하도록 요청된 시간 윈도우 (예를 들어, “2:30 AM와 3:30 AM 사이에 백업 루틴을 실행” 또는 “3:00 AM 플러스 또는 마이너스 30 분에 백업 루틴을 실행”) 중 하나일 수 있다. 일부 실시예들에서, 시간 프레임은 요청 그 자체에 제공될 수 있다. 다른 실시예들에서, 스케줄링 관리기 (150)는 요청과 관련된 유저 계정 또는 요청과 관련된 프로그램 코드를 이용하여 시간 프레임을 룩업(look up) 함으로써, 또는 시스템-와이드(system-wide) 설정들 또는 공개된 시스템-와이드, 매-계정(per-account), 또는 매-기능(per-function) SLA들을 이용함으로써 요청과 관련된 시간 프레임을 결정할 수 있다. 일부 실시예들에서, 스케줄링 관리기 (150)는 유저 인터페이스를 통하여, 다양한 정도의 시간 가요성 (예를 들어, 상기에 열거된 옵션들 (i)-(iii)) 중에서 선택한 옵션을 제공하도록 구성된다. 일부 실시예들에서, 시간 가요성의 정도 변화는 가상 컴퓨트 시스템 (110)상에서 유저 기능들 실행과 관련된 변화하는 경비의 양과 관련될 수 있다. 예를 들어, 만약 유저가 요청된 유저 기능이 그 시간안에 실행되는 2-시간(hour) 범위를 지정하면 매 실행마다 0.01 cents 유저에게 경비가 들게할 수 있지만, 그러나 만약 유저가 요청된 유저 기능이 해당 시간에 실행될 정확한 시간 지점을 특정하면 매 실행마다 0.1 cents 유저에게 경비가 들게할 수 있다.

블럭(604)에서, 스케줄링 관리기 (150)는 제 2 프로그램 코드를 실행시키기 위해 제 2 시간 프레임을 갖는 제 2 작업 요청을 수신한다. 예를 들어, 제 2 작업 요청은 파일 압축 루틴(file compression routine)이 내일 3:00 AM 에 실행될것을 요청할 수 있다. 상기에서 논의된 바와 같이, 요청에 의해 지정된 시간 프레임은 (i) 가상 컴퓨트 시스템이 해당 시간까지 제 1 프로그램 코드를 실행하도록 요청된 시간 (예를 들어, “3:00 AM까지 파일 압축 루틴을 실행하지만 당신은 그 전 임의의 시간에 시작하게 할 수 있다”, (ii) 가상 컴퓨트 시스템이 해당 시간 후에 제 1 프로그램 코드를 실행하도록 요청된 시간(예를 들어, “3:00 AM 이후에 파일 압축 루틴을 실행하지만 그러나 당신이 파일 압축을 개시하기 전에 당신은 훨씬 더 많이 시간이 걸릴 수 있다”), 또는 (iii) 가상 컴퓨트 시스템이 해당 시간내에 제 1 프로그램 코드를 실행하도록 요청된 시간 윈도우 (예를 들어, “2:30 AM와 3:30 AM 사이에 파일 압축 루틴을 실행” 또는 “3:00 AM 플러스 또는 마이너스 30 분에 파일 압축 루틴을 실행”) 중 하나일 수 있다. 비록 백업 루틴 및 파일 압축 루틴은 본 출원에서 예들로서 사용되지만, 임의의 다른 프로그램 코드, 유저 기능, 등이 사용될 수 있다. 일부 실시예들에서, 요청들은 대응하는 코드 실행이 해당 최대 지속기간 이후에 타임 아웃되는 것을 고려하여야 하는 최대 지속기간(maximum duration)을 또한 지정할 수 있다. 예를 들어, 이런 최대 지속기간은 유저 기능의 실행이 개시된 시간 이후에 최대 지속기간과 동등한 시간 기간이 경과된 후에 유저 기능이 계속해서 운용되지 않는 보증을 스케줄링 관리기 (150)에 제공할 수 있다.

블럭 (606)에서, 스케줄링 관리기 (150)는 제 1 및 제 2 작업들을 스케줄링하여 제 1 및 제 2 작업들이 서로 중첩하지 않게 한다. 상기의 예제에서, 설사 각각의 제 1 및 제 2 작업 요청들에 대하여 지정된 시간 프레임이 3:00 AM를 나타낸다 할지라도, 스케줄링 작업들에서 일부 가용성이 있을 수 있다. 만약 작업 요청들의 둘 모두가 대응하는 루틴들이 3:00 AM에 또는 해당 시간 후에 머지 않아 실행되어야 하는 것을 지정하면, 스케줄링 관리기 (150)는 백업 루틴이 3:00 AM에 실행되도록 그리고 파일 압축 루틴이 3:10 AM에 실행되도록 스케줄링할 수 있다. 만약 작업 요청들의 둘 모두가 대응하는 루틴들이 3:00 AM까지 또는 해당 시간전에 머지 않아 마쳐져야 하는 것을 지정하면, 스케줄링 관리기 (150)는 백업 루틴이 2:40 AM에 실행되도록 그리고 파일 압축 루틴이 2:50 AM에 실행되도록 스케줄링할 수 있다. 만약 작업 요청들의 둘 모두가 대응하는 루틴들이 2:30AM과 3:00 AM 사이에 실행되어야 하는 것을 지정하면, 스케줄링 관리기 (150)는 백업 루틴이 2:50 AM에 실행되도록 그리고 파일 압축 루틴이 3:00 AM에 실행되도록 스케줄링할 수 있다. 일부 실시예들에서, 만약 작업 요청들의 둘 모두가 대응하는 루틴들이 3:00 AM 전에 실행을 마쳐야 한다는 것을 지정하면, 어떠한 작업도 그 후에 스케줄링 될 수 없다(3:00 AM - (개별 작업의 최대 지속기간)).

도 6의 루틴 (600)은 블럭들 (602)-(606)를 참고로 하여 상기에서 설명되었지만, 본 출원에서 설명된 실시예들은 이에 제한되지 않고, 본 발명의 취지에 벗어나지 않고서 하나 이상의 블럭들이 생략되거나, 변형되거나, 또는 스위치될 수 있다.

실행 요건들(Execution Requirements)에 기초하여 작업들을 스케줄링하기 위한 예제 루틴

이제 도 7로 가서, 가상 컴퓨트 시스템 (110) (예를 들어, 스케줄링 관리기 (150))의 하나 이상의 컴포넌트들에 의해 구현된 루틴 (700)이 설명될 것이다. 비록 루틴 (700)은 스케줄링 관리기 (150)에 의한 구현예에 관해서 설명되지만, 관련 기술분야에 숙련된 기술자는 대안적인 컴포넌트들이 루틴 (700)을 구현할 수 있거나 또는 하나 이상의 블럭들이 상이한 컴포넌트에 의해 또는 분배된 방식으로 구현될 수 있다는 것을 인식할 것이다.

예시적인 루틴 (700)의 블럭(702)에서, 스케줄링 관리기 (150)는 제 1 세트의 실행 요건들을 갖는 제 1 작업을 실행하기 위한 요청을 수신한다. 예를 들어, 제 1 세트의 실행 요건들은 제 1 작업을 실행시키기 위해 사용되는 컴퓨팅 자원들의 양을(예를 들어, 메모리, CPU, 네트워크, 등) 포함할 수 있다. 다른 예에서, 제 1 세트의 실행 요건들은 시간적인 또는 공간적인 자원 예컨대 얼마나 많은 시간이 제 1 작업을 실행시키기 위해 요구되는지, 및 얼마나 많은 컴퓨트 용량이 제 1 작업을 실행시키기 위해 요구되는지, 등을 포함할 수 있다. 예를 들어, 제 1 작업은 128 MB의 메모리를 사용하는 파일 압축 루틴일 수 있다.

블럭(704)에서, 스케줄링 관리기 (150) 스케줄링 관리기 (150)는 제 2 세트의 실행 요건들을 갖는 제 2 작업을 실행하기 위한 요청을 수신한다. 예를 들어, 제 2 세트의 실행 요건들은 제 2 작업을 실행시키기 위해 사용되는 컴퓨팅 자원들의 양을(예를 들어, 메모리, CPU, 네트워크, 등) 포함할 수 있다. 다른 예에서, 제 2 세트의 실행 요건들은 시간적인 또는 공간적인 자원 예컨대 얼마나 많은 시간이 제 2 작업을 실행시키기 위해 요구되는지, 및 얼마나 많은 컴퓨트 용량이 제 2 작업을 실행시키기 위해 요구되는지, 등을 포함할 수 있다. 예를 들어, 제 2 작업은 512 MB의 메모리를 사용하는 이미지 프로세싱 루틴일 수 있다.

블럭 (706)에서, 스케줄링 관리기 (150)는 제 1 및 제 2 세트들의 실행 요건들에 기반된 하나 이상의 스케줄링 기준을 결정한다. 예를 들어, 제 1 작업이 128 MB의 메모리를 사용하고 제 2 작업이 512 MB의 메모리를 사용한다고 결정한 스케줄링 관리기 (150)는, 제 1 및 제 2 작업들이 동시에 실행되기 위해서(또는 작업들이 일시적으로 중첩하여 실행되는), 적어도 640 MB의 메모리가 요구된다는 것을 추가로 결정할 수 있다. 다시 말해서, 스케줄링 기준은 (i) 제 1 작업은 가상 컴퓨트 시스템 (110)이 적어도 128 MB의 빈(free) 메모리를 갖자 마자 실행되도록 스케줄링될 수 있고, (ii) 제 2 작업은 가상 컴퓨트 시스템 (110)이 적어도 512 MB의 빈 메모리를 갖자 마자 실행되도록 스케줄링될 수 있고, 및 (iii) 제 1 및 제 2 작업들은 가상 컴퓨트 시스템 (110)이 적어도 640 MB의 빈 메모리를 갖자 마자 일시적으로 중첩 방식으로 실행되도록 스케줄링될 수 있다는 것일 수 있다.

블럭 (708)에서, 스케줄링 관리기 (150)는 스케줄링 기준이 충족되도록 제 1 및 제 2 작업들을 스케줄링한다. 상기에서 논의된 예제에서, 스케줄링 관리기 (150)는 만약 가상 컴퓨트 시스템이 제 1 및 제 2 작업들이 실행될 시간에 1 GB의 메모리를 가지면 제 1 및 제 2 작업들이 동시에 실행되도록 스케줄링할 수 있다. 만약 가상 컴퓨트 시스템 (110)이 단지 600 MB의 이용 가능한 메모리를 가지면, 스케줄링 관리기 (150)는 실행들이 중첩하지 않도록 제 1 및 제 2 작업들을 스케줄링할 수 있다. 비록 메모리가 제 1 및 제 2 작업들간에 자원 경쟁(resource contention)을 예시하기 위해서 사용되지만, 기술들은 제 1 및 제 2 작업들 둘 모두에 의해 이용될 수 있는 임의의 다른 자원들까지 연장될 수 있다.

도 7의 루틴 (700)은 블럭들 (702)-(708)를 참고로 하여 상기에서 설명되었지만, 본 출원에서 설명된 실시예들은 이에 제한되지 않고, 본 발명의 취지에 벗어나지 않고서 하나 이상의 블럭들이 생략되거나, 변형되거나, 또는 스위치될 수 있다.

다른 고려사항들

본 개시에 설명된 기능들의 전부가 개시된 컴포넌트들 및 모바일 통신 디바이스들의 하나 이상의 물리적 프로세서들에 의해 실행되는 소프트웨어로 구체화될 수 있다는 것이 당해 기술분야의 통상의 기술자들 및 다른사람들에 의해 인식될 것이다. 소프트웨어는 임의의 유형의 비-휘발성 스토리지에 영구적으로 저장될 수 있다.

조건부의 언어, 예컨대, 그 중에서도, “할 수 있다(can),” “할 수 있다(could),” “일지 모른다(might),” 또는 “일지 모른다(may)”는 구체적으로 다른식으로 언급되지 않는한 또는 그렇지 않으면, 사용된 문맥하에서 다른 식으로 이해되지 않는 한, 일반적으로 어떤 특징부들, 엘리먼트들 및/또는 단계들을 임의의 실시예들은 포함하지만 다른 실시예들은 포함하지 않는 것을 전달하도록 의도된다. 따라서, 이런 조건부 언어는 일반적으로 특징부들, 엘리먼트들 및/또는 단계들이 하나 이상의 실시예들에 대해 임의의 방식으로 요구되거나 또는 하나 이상의 실시예들은 이들 특징부들, 엘리먼트들 및/또는 단계들이 임의의 특정 실시예에서 포함되거나 또는 수행될 지 여부를 유저 입력 또는 프롬프트로 또는 그것들 없이 결정하기 위한 로직을 반드시 포함한다는 것을 의미하도록 의도되지 않는다.

앞에서의 것들은 이하의 항목들을 고려하여 더 잘 이해될 수 있다:

1. 가상 컴퓨트 군(virtual compute fleet)으로부터 저-레이턴시(low-latency) 컴퓨터 용량을 제공하기 위한 시스템에 있어서, 상기 시스템은:

적어도 유저의 프로그램 코드를 저장하도록 구성된 전자 데이터 저장소; 및

특정 컴퓨터-실행 가능한 지시들을 실행시키는 하나 이상의 하드웨어 컴퓨팅 디바이스들을 포함하는 가상 컴퓨트 시스템을 포함하되, 상기 가상 컴퓨트 시스템은 상기 데이터 저장소와 통신하고, 그리고 적어도:

하나 이상의 물리적 컴퓨팅 디바이스들상에 복수개의 가상 기계 인스턴스들을 유지하고, 상기 복수의 가상 기계 인스턴스들은;

가상 기계 인스턴스들 위에 로딩된 하나 이상의 소프트웨어 컴포넌트들을 갖는 상기 가상 기계 인스턴스들을 포함하는 워밍 풀(warming pool)로서, 유저에 할당될 것을 대기하는, 상기 워밍 풀; 및

현재 하나 이상의 유저들에 할당된 가상 기계 인스턴스들을 포함하는 활성 풀(active pool);를 포함하되,

상기 가상 컴퓨트 시스템상에서 프로그램 코드들을 실행시키기 위한 착신 코드 실행 요청들을 모니터링하고, 상기 착신 코드 실행 요청들 중 적어도 일부는 어느 정도의 주기성을 보이고;

상기 착신 코드 실행 요청들의 적어도 일부와 관련된 상기 주기성의 정도를 결정하고, 결정된 상기 주기성의 정도는 상기 착신 코드 실행 요청들의 적어도 일부가 상기 가상 컴퓨트 시스템에 의해 수신될 것이 예상되는 시간 기간을 나타내고;

상기 착신 코드 실행 요청들의 적어도 일부와 관련된 상기 주기성의 정도를 결정한 것에 응답하여, 축소된 수의 가상 기계 인스턴스들이 상기 워밍 풀에 유지되도록 하고, 상기 축소된 수는 상기 착신 코드 실행 요청들의 적어도 일부의 수 및 상기 결정된 주기성의 정도에 기초하여 결정되고;

적어도 하나의 가상 기계 인스턴스가 상기 시간 기간 전에 상기 활성 풀에 추가되도록 하고, 상기 착신 코드 실행 요청들의 적어도 일부와 관련된 프로그램 코드가 상기 적어도 하나의 가상 기계 인스턴스상에 로딩되도록 하고; 및

상기 착신 코드 실행 요청들의 적어도 일부와 관련된 요청을 수신한 것에 응답하여, 상기 적어도 하나의 가상 기계상에 로딩된 상기 프로그램 코드가 실행되도록 구성된다.

2. 항목 1의 시스템에 있어서, 상기 가상 컴퓨트 시스템은

제 1 시간 기간에 제 1 프로그램 코드를 실행하는 제 1 요청을 수신하고;

제 2 시간 기간에 제 2 프로그램 코드를 실행하는 제 2 요청을 수신하고, 상기 제 2 시간 기간은 적어도 부분적으로 상기 제 1 시간 기간에 중첩하고; 및

상기 제 1 프로그램 코드의 제 1 실행 및 상기 제 2 프로그램 코드의 제 2 실행을 스케줄링하여 상기 제 1 및 제 2 실행들이 중첩하지 않도록 더 구성된다.

3. 항목 2의 시스템에 있어서, 상기 제 1 시간 기간은 (i) 상기 가상 컴퓨트 시스템이 해당 시간까지 상기 제 1 프로그램 코드를 실행하도록 요청된 시간, (ii) 상기 가상 컴퓨트 시스템이 해당 시간 후에 상기 제 1 프로그램 코드를 실행하도록 요청된 시간, 또는 (iii) 상기 가상 컴퓨트 시스템이 해당 시간 윈도우내에 상기 제 1 프로그램 코드를 실행하도록 요청된 시간 윈도우 중 하나를 포함한다.

4. 시스템으로서,

특정 컴퓨터-실행 가능한 지시들을 실행시키는 하나 이상의 하드웨어 컴퓨팅 디바이스들을 포함하는 가상 컴퓨트 시스템을 포함하되, 적어도:

하나 이상의 물리적 컴퓨팅 디바이스들상에 복수의 가상 기계 인스턴스들을 유지하고;

상기 가상 컴퓨트 시스템상에서 프로그램 코드들을 실행시키기 위한 착신 코드 실행 요청들을 모니터링하고;

상기 착신 코드 실행 요청들의 적어도 일부가 주기성을 보이는지 여부를 결정하고, 상기 착신 코드 실행 요청들의 적어도 일부는 하나 이상의 실행 파라미터들과 연관되고;

상기 착신 코드 실행 요청들의 적어도 일부가 주기성을 보인다는 결정에 응답하여, 축소된 양의 유휴상태(idle) 컴퓨트 용량이 상기 가상 컴퓨트 시스템상에 유지되도록 하고, 상기 축소된 양은 상기 주기성에 기초하여 결정되고; 및

상기 착신 코드 실행 요청들의 적어도 일부가 상기 가상 컴퓨트 시스템에 의해 수신되는 것과 동일한 주기성을 추가 주기적인 요청이 보이기 전에 추가 가상 기계 인스턴스가 하나 이상의 실행 파라미터들에 기초하여 미리-초기화되도록 구성된다.

5. 항목 4의 시스템에 있어서, 상기 복수의 가상 기계 인스턴스들은 가상 기계 인스턴스들의 활성 풀을 포함하고, 상기 가상 컴퓨트 시스템은 프로그램 코드를 실행하기 위해 앞에 사용되었지만 그러나 현재는 프로그램 코드를 실행하지 않는 인스턴스를 상기 활성 풀로부터 제거함으로써 상기 축소된 양의 유휴상태 컴퓨트 용량이 되도록 구성된다.

6. 항목 4의 시스템에 있어서, 상기 복수의 가상 기계 인스턴스들은 가상 기계 인스턴스들의 활성 풀을 포함하고, 상기 가상 컴퓨트 시스템은:

상기 가상 컴퓨트 시스템과 네트워크화된 통신에 인스턴스 프로비저닝(provisioning) 서비스로부터 상기 추가 가상 기계 인스턴스를 요청하고;

상기 추가 가상 기계 인스턴스가 상기 활성 풀에 추가되도록 하고; 및

상기 추가 가상 기계상에 컨테이너(container)를 생성하고 상기 추가 주기적인 요청과 관련된 프로그램 코드가 상기 컨테이너에 로딩되도록 함으로써 추가 가상 기계 인스턴스가 상기 하나 이상의 실행 파라미터들에 기초하여 미리-초기화되도록 구성된다.

7. 항목 4의 시스템에 있어서, 상기 복수의 가상 기계 인스턴스들은 가상 기계 인스턴스들의 워밍 풀을 포함하고, 상기 가상 컴퓨트 시스템은:

상기 가상 컴퓨트 시스템과 네트워크화된 통신에 인스턴스 프로비저닝(provisioning) 서비스로부터 상기 추가 가상 기계 인스턴스를 요청하고;

상기 추가 가상 기계 인스턴스가 상기 워밍 풀에 추가되도록 하고; 및

상기 추가 가상 기계상에 컨테이너(container)를 생성하고 상기 추가 주기적인 요청과 관련된 프로그램 코드가 상기 컨테이너에 로딩되도록 함으로써 추가 가상 기계 인스턴스가 상기 하나 이상의 실행 파라미터들에 기초하여 미리-초기화되도록 구성된다.

8. 항목 4의 시스템에 있어서, 상기 복수의 가상 기계 인스턴스들은 가상 기계 인스턴스들의 활성 풀을 포함하고, 상기 가상 컴퓨트 시스템은:

상기 활성 풀에 채워지지 않은(unfilled) 가상 기계 인스턴스를 위치시키고, 상기 채워지지 않은 가상 기계 인스턴스는 완전히 사용되지 않고; 및

상기 채워지지 않은 가상 기계 인스턴스상에 컨테이너(container)를 생성하고 상기 추가 주기적인 요청과 관련된 프로그램 코드가 상기 컨테이너에 로딩되도록 함으로써 추가 가상 기계 인스턴스가 하나 이상의 실행 파라미터들에 기초하여 미리-초기화되도록 구성된다.

9. 항목 4의 시스템에 있어서, 상기 복수의 가상 기계 인스턴스들은 그 위에 로딩된 하나 이상의 소프트웨어 컴포넌트들을 갖고 유저에게 할당될 것을 대기하는 가상 기계 인스턴스들의 워밍 풀을 포함하되, 상기 가상 컴퓨트 시스템은 가상 기계 인스턴스들의 수가 상기 축소된 양에 대응하는 수에 도달할 때까지 상기 워밍 풀에 추가 가상 기계 인스턴스들을 추가하는 것을 삼가함으로써 축소된 양의 유휴상태 컴퓨트 용량이 상기 가상 컴퓨트 시스템상에 유지되되도록 구성된다.

10. 항목 4의 시스템에 있어서, 상기 가상 컴퓨트 시스템은 추가 주기적인 요청을 수신한 것에 응답하여, 상기 추가 주기적인 요청과 관련된 프로그램 코드가 상기 추가 가상 기계 인스턴스상에 생성된 컨테이너에서 실행되도록 더 구성되고, 상기 프로그램 코드는 상기 추가 주기적인 요청이 상기 가상 컴퓨트 시스템에 의해 수신되기 전에 상기 컨테이너에 로딩된다.

11. 항목 4의 시스템에 있어서, 상기 가상 컴퓨트 시스템은

제 1 프로그램 코드, 상기 제 1 프로그램 코드를 실행시키기 위한 제 1 최대 지속기간, 및 상기 제 1 프로그램 코드를 실행시키기 위한 제 1 시간 프레임(time frame)과 연관된 제 1 작업 요청을 수신하고;

제 2 프로그램 코드 및 상기 제 2 프로그램 코드를 실행시키기 위한 제 2 시간 프레임과 연관된 제 2 작업 요청을 수신하고, 상기 제 2 시간 프레임은 적어도 부분적으로 상기 제 1 시간 프레임에 중첩하고; 및

상기 제 1 프로그램 코드가 실행될 제 1 실행 시간 및 상기 제 2 프로그램 코드가 실행될 제 2 실행 시간을 상기 제 1 실행 시간이 적어도 상기 제 1 최대 지속기간에 의해 상기 제 2 실행 시간을 선행하도록 결정하도록 더 구성된다.

12. 항목 11의 시스템에 있어서, 상기 가상 컴퓨트 시스템은 유저 인터페이스를 통하여, 제 1 경비와 연관된 제 1 정도의 시간 가요성 및 제 2 경비와 연관되고 상기 제 1 정도보다 더 큰 제 2 정도의 시간 가요성 사이에서 선택하는 옵션을 제공하도록 더 구성되되, 상기 제 1 경비는 상기 제 2 경비보다 더 크다.

13. 항목 4의 시스템에 있어서, 상기 가상 컴퓨트 시스템은 상기 착신 코드 실행 요청들에 기초하여 생성된 로그 데이터(log data)를 주기적으로 분석함으로써 상기 착신 코드 실행 요청들의 적어도 일부가 주기성을 보이는지 여부를 결정하도록 구성된다.

14. 컴퓨터-구현 방법에 있어서:

특정 실행 가능한 지시들로 구성된 하나 이상의 컴퓨팅 디바이스들에 의해 구현되는 것으로,

하나 이상의 물리적 컴퓨팅 디바이스들상에 복수의 가상 기계 인스턴스들을 유지하는 단계;

상기 가상 컴퓨트 시스템상에서 프로그램 코드들을 실행시키기 위한 착신 코드 실행 요청들을 모니터링하는 단계;

상기 착신 코드 실행 요청들의 적어도 일부가 주기성을 보이는지 여부를 결정하는 단계로서, 상기 착신 코드 실행 요청들의 적어도 일부는 하나 이상의 실행 파라미터들과 연관되는, 상기 결정하는 단계;

상기 착신 코드 실행 요청들의 적어도 일부가 주기성을 보인다는 결정에 응답하여, 축소된 양의 유휴상태(idle) 컴퓨트 용량이 상기 가상 컴퓨트 시스템상에 유지되도록 하는 단계로서, 상기 축소된 양은 상기 주기성에 기초하여 결정되는, 상기 유지되도록 하는 단계; 및

상기 착신 코드 실행 요청들의 적어도 일부가 임계 시간 양내에 수신될 것이 예상되는지를 결정하는 단계; 및

상기 착신 코드 실행 요청들의 적어도 일부가 상기 가상 컴퓨트 시스템에 의해 수신되는 것과 동일한 주기성을 추가 주기적인 요청이 보이기 전에 추가 가상 기계 인스턴스가 하나 이상의 실행 파라미터들에 기초하여 구성되도록 하는 단계를 포함한다.

15. 항목 14의 컴퓨터-구현 방법에 있어서, 상기 복수의 가상 기계 인스턴스들은 가상 기계 인스턴스들의 활성 풀을 포함하고, 추가 가상 기계 인스턴스가 하나 이상의 실행 파라미터들에 기초하여 구성되도록 하는 단계는 :

상기 가상 컴퓨트 시스템과 네트워크화된 통신에 인스턴스 프로비저닝(provisioning) 서비스로부터 상기 추가 가상 기계 인스턴스를 요청하는 단계;

상기 추가 가상 기계 인스턴스가 상기 활성 풀에 추가되도록 하는 단계; 및

상기 추가 가상 기계상에 컨테이너(container)를 생성하고 상기 착신 코드 실행 요청들의 적어도 일부와 관련된 프로그램 코드가 상기 컨테이너에 로딩되도록 하는 단계를 포함한다.

16. 항목 14의 컴퓨터-구현 방법에 있어서, 상기 복수의 가상 기계 인스턴스들은 가상 기계 인스턴스들의 워밍 풀을 포함하고, 추가 가상 기계 인스턴스가 하나 이상의 실행 파라미터들에 기초하여 구성되도록 하는 단계는 :

상기 가상 컴퓨트 시스템과 네트워크화된 통신에 인스턴스 프로비저닝(provisioning) 서비스로부터 상기 추가 가상 기계 인스턴스를 요청하는 단계;

상기 추가 가상 기계 인스턴스가 상기 워밍 풀에 추가되도록 하는 단계; 및

상기 추가 가상 기계상에 컨테이너(container)를 생성하고 상기 추가 주기적인 요청과 관련된 프로그램 코드가 상기 컨테이너에 로딩되도록 하는 단계를 포함한다.

17. 항목 14의 방법에 있어서,

제 1 세트의 실행 요건들과 관련된 제 1 작업(job)을 실행시키기 위한 요청을 수신하는 단계;

제 2 세트의 실행 요건들과 관련된 제 2 작업을 실행시키기 위한 요청을 수신하는 단계;

제 1 및 제 2 세트들의 실행 요건들에 기반된 하나 이상의 스케줄링 기준을 결정하는 단계; 및

상기 하나 이상의 스케줄링 기준이 만족되도록 상기 제 1 작업을 실행시키기 위한 제 1 실행 시간 및 상기 제 2 작업을 실행시키기 위한 제 2 실행 시간을 결정하는 단계를 더 포함한다.

18. 프로그램 지시들을 저장한 비-일시적 컴퓨터-판독 가능한 저장 매체에 있어서, 상기 프로그램 지시들은 하나 이상의 프로세서들에 의해 실행될 때 하나이상의 컴퓨팅 디바이스들로 하여금:

하나 이상의 물리적 컴퓨팅 디바이스들상에 복수의 가상 기계 인스턴스들을 유지하고;

상기 가상 컴퓨트 시스템상에서 프로그램 코드들을 실행시키기 위한 착신 코드 실행 요청들을 모니터링하고;

상기 착신 코드 실행 요청들의 적어도 일부가 주기성을 보이는지 여부를 결정하고, 상기 착신 코드 실행 요청들의 적어도 일부는 하나 이상의 실행 파라미터들과 연관되고;

상기 착신 코드 실행 요청들의 적어도 일부가 주기성을 보인다는 결정에 응답하여, 축소된 양의 유휴상태(idle) 컴퓨트 용량이 상기 가상 컴퓨트 시스템상에 유지되도록 하고, 상기 축소된 양은 상기 주기성에 기초하여 결정되고; 및

상기 착신 코드 실행 요청들의 적어도 일부가 임계 시간 양내에 수신될 것이 예상되는지를 결정하고; 및

상기 착신 코드 실행 요청들의 적어도 일부가 상기 가상 컴퓨트 시스템에 의해 수신되는 것과 동일한 주기성을 추가 주기적인 요청이 보이기 전에 추가 가상 기계 인스턴스가 하나 이상의 실행 파라미터들에 기초하여 구성되도록 구성된다.

19. 항목 18의 비-일시적 물리적 컴퓨터 스토리지에 있어서, 상기 복수의 가상 기계 인스턴스들은 가상 기계 인스턴스들의 활성 풀을 포함하고, 추가 가상 기계 인스턴스가 하나 이상의 실행 파라미터들에 기초하여 구성되도록 하는 것은 :

상기 가상 컴퓨트 시스템과 네트워크화된 통신에 인스턴스 프로비저닝(provisioning) 서비스로부터 상기 추가 가상 기계 인스턴스를 요청하고;

상기 추가 가상 기계 인스턴스가 상기 활성 풀에 추가되도록 하고; 및

상기 추가 가상 기계상에 컨테이너(container)를 생성하고 추가 주기적인 요청과 관련된 프로그램 코드가 상기 착신 코드 실행 요청들의 적어도 일부과 관련된 프로그램 코드가 상기 컨테이너에 로딩되는 것과 동일한 주기성을 보이게 하는 하는 단계 것을 포함한다.

20. 항목 18의 비-일시적 물리적 컴퓨터 스토리지에 있어서, 상기 복수의 가상 기계 인스턴스들은 가상 기계 인스턴스들의 활성 풀을 포함하고, 추가 가상 기계 인스턴스가 하나 이상의 실행 파라미터들에 기초하여 구성되도록 하는 것은 :

상기 활성 풀에 채워지지 않은(unfilled) 가상 기계 인스턴스를 위치시키고, 상기 채워지지 않은 가상 기계 인스턴스는 완전히 사용되지 않고; 및

상기 채워지지 않은 가상 기계 인스턴스상에 컨테이너(container)를 생성하고 상기 추가 주기적인 요청과 관련된 프로그램 코드가 상기 컨테이너에 로딩되도록 하는 것을 포함한다.

21. 항목 18의 비-일시적, 컴퓨터-판독가능한 스토리지 매체에 있어서, 상기 프로그램 지시들은 상기 하나 이상의 컴퓨팅 디바이스들로 하여금 추가로:

제 1 세트의 실행 요건들과 관련된 제 1 작업(job)을 실행시키기 위한 요청을 수신하고;

제 2 세트의 실행 요건들과 관련된 제 2 작업을 실행시키기 위한 요청을 수신하고;

제 1 및 제 2 세트들의 실행 요건들에 기반된 하나 이상의 스케줄링 기준을 결정하고; 및

상기 하나 이상의 스케줄링 기준이 만족되도록 상기 제 1 작업을 실행시키기 위한 제 1 실행 시간 및 상기 제 2 작업을 실행시키기 위한 제 2 실행 시간을 결정하도록 구성된다.

본 출원에서 설명된 및/또는 첨부된 도면들에 도시된 임의의 프로세스 설명들, 엘리먼트들, 또는 흐름도에 블럭들은 프로세스에 특정 로직상의 기능들 또는 단계들을 구현하기 위한 하나 이상의 실행 가능한 지시들을 포함하는 모듈들, 세그먼트들, 또는 코드의 부분들을 잠재적으로 나타내는 것으로 이해되어야 한다. 엘리먼트들 또는 기능들이 삭제될 수 있고, 당해 기술분야의 통상의 기술자들에 이해될 포함된 기능에 의존하여 실질적으로 동시에 또는 반대 순서로 도시되거나 또는 논의된 것과 순서가 다르게 실행될 수 있는 대안적인 구현예들은 본 출원에서 설명된 실시예들의 범위내에 포함된다. 추가로 상기에서 설명된 데이터 및/또는 컴포넌트들은 컴퓨터 실행 가능한 컴포넌트들을 저장하는 컴퓨터 판독가능한 스토리지 매체 예컨대 CD-ROM, DVD-ROM, 또는 네트워크 인터페이스와 관련된 구동 메커니즘을 이용하여 컴퓨팅 디바이스의 메모리에 로딩될 수 있고 컴퓨터 판독가능 매체상에 저장될 수 있다는 것이 인식될 것이다. 더구나, 컴포넌트 및/또는 데이터는 단일 디바이스에 포함될 수 있거나 또는 임의의 방식으로 분포될 수 있다. 따라서, 범용 컴퓨팅 디바이스들은 상기에서 설명된 다양한 데이터 및/또는 컴포넌트들의 프로세싱 및/또는 실행과 함께 본 발명의 프로세스들, 알고리즘들, 및 방법론을 구현하도록 구성될 수 있다.

많은 변형들 및 수정예들이 상기-설명된 실시예들에 수행될 수 있고, 이의 엘리먼트들은 다른 수락할만한 예들 중에 있는 것으로 이해되어야 하는 것이 강조되어야 한다. 모든 이런 수정예들 및 변형예들은 이하의 청구항들에 의해 보호되고 본 개시의 범위내 본 출원에 포함되도록 의도된다.

Claims (15)

1. 가상 컴퓨트 군(virtual compute fleet)으로부터 저-레이턴시(low-latency) 컴퓨터 용량을 제공하기 위한 시스템에 있어서, 상기 시스템은:
   적어도 유저의 프로그램 코드를 저장하도록 구성된 전자 데이터 저장소; 및
   특정 컴퓨터-실행 가능한 지시들을 실행시키는 하나 이상의 하드웨어 컴퓨팅 디바이스들을 포함하는 가상 컴퓨트 시스템을 포함하되, 상기 가상 컴퓨트 시스템은 상기 데이터 저장소와 통신하고, 그리고 적어도:
   하나 이상의 물리적 컴퓨팅 디바이스들상에 복수개의 가상 기계 인스턴스들을 유지하고, 상기 복수의 가상 기계 인스턴스들은;
   가상 기계 인스턴스들 위에 로딩된 하나 이상의 소프트웨어 컴포넌트들을 갖는 상기 가상 기계 인스턴스들을 포함하는 워밍 풀(warming pool)로서, 유저에 할당될 것을 대기하는, 상기 워밍 풀; 및
   현재 하나 이상의 유저들에 할당된 가상 기계 인스턴스들을 포함하는 활성 풀(active pool);을 포함하되,
   상기 가상 컴퓨트 시스템상에서 프로그램 코드들을 실행시키기 위한 착신 코드 실행 요청들을 모니터링하고, 상기 착신 코드 실행 요청들 중 적어도 일부는 어느 정도의 주기성(periodicity)을 보이고;
   상기 착신 코드 실행 요청들의 적어도 일부와 관련된 상기 주기성의 정도를 결정하고, 결정된 상기 주기성의 정도는 상기 착신 코드 실행 요청들의 적어도 일부가 상기 가상 컴퓨트 시스템에 의해 수신될 것이 예상되는 시간 기간을 나타내고;
   상기 착신 코드 실행 요청들의 적어도 일부와 관련된 상기 주기성의 정도를 결정한 것에 응답하여, 축소된 수의 가상 기계 인스턴스들이 상기 워밍 풀에 유지되도록 하고, 상기 축소된 수는 상기 착신 코드 실행 요청들의 적어도 일부의 수 및 상기 결정된 주기성의 정도에 기초하여 결정되고;
   적어도 하나의 가상 기계 인스턴스가 상기 시간 기간 전에 상기 활성 풀에 추가되도록 하고, 상기 착신 코드 실행 요청들의 적어도 일부와 관련된 프로그램 코드가 상기 적어도 하나의 가상 기계 인스턴스상에 로딩되도록 하고; 및
   상기 착신 코드 실행 요청들의 적어도 일부와 관련된 요청을 수신한 것에 응답하여, 상기 적어도 하나의 가상 기계상에 로딩된 상기 프로그램 코드가 실행되도록 구성된, 시스템.
2. 청구항 1에 있어서, 상기 가상 컴퓨트 시스템은
   제 1 시간 기간에 제 1 프로그램 코드를 실행하는 제 1 요청을 수신하고;
   제 2 시간 기간에 제 2 프로그램 코드를 실행하는 제 2 요청을 수신하고, 상기 제 2 시간 기간은 적어도 부분적으로 상기 제 1 시간 기간에 중첩하고; 및
   상기 제 1 프로그램 코드의 제 1 실행 및 상기 제 2 프로그램 코드의 제 2 실행을 스케줄링하여 상기 제 1 및 제 2 실행들이 중첩하지 않도록 더 구성되는, 시스템.
3. 청구항 2에 있어서, 상기 제 1 시간 기간은 (i) 상기 가상 컴퓨트 시스템이 해당 시간까지 상기 제 1 프로그램 코드를 실행하도록 요청된 시간, (ii) 상기 가상 컴퓨트 시스템이 해당 시간 후에 상기 제 1 프로그램 코드를 실행하도록 요청된 시간, 또는 (iii) 상기 가상 컴퓨트 시스템이 해당 시간 윈도우(time window)내에 상기 제 1 프로그램 코드를 실행하도록 요청된 시간 윈도우 중 하나를 포함하는, 시스템.
4. 시스템으로서,
   특정 컴퓨터-실행 가능한 지시들을 실행시키는 하나 이상의 하드웨어 컴퓨팅 디바이스들을 포함하는 가상 컴퓨트 시스템을 포함하되, 적어도:
   하나 이상의 물리적 컴퓨팅 디바이스들상에 복수의 가상 기계 인스턴스들을 유지하고;
   상기 가상 컴퓨트 시스템상에서 프로그램 코드들을 실행시키기 위한 착신 코드 실행 요청들을 모니터링하고;
   상기 착신 코드 실행 요청들의 적어도 일부가 주기성을 보이는지 여부를 결정하고, 상기 착신 코드 실행 요청들의 적어도 일부는 하나 이상의 실행 파라미터들과 연관되고;
   상기 착신 코드 실행 요청들의 적어도 일부가 주기성을 보인다는 결정에 응답하여, 축소된 양의 유휴상태(idle) 컴퓨트 용량이 상기 가상 컴퓨트 시스템상에 유지되도록 하고, 상기 축소된 양은 상기 주기성에 기초하여 결정되고; 및
   상기 착신 코드 실행 요청들의 적어도 일부가 상기 가상 컴퓨트 시스템에 의해 수신되는 것과 동일한 주기성을 추가 주기적인 요청이 보이기 전에 추가 가상 기계 인스턴스가 하나 이상의 실행 파라미터들에 기초하여 미리-초기화되도록 구성되는, 시스템.
5. 청구항 4에 있어서, 상기 복수의 가상 기계 인스턴스들은 가상 기계 인스턴스들의 활성 풀을 포함하고, 상기 가상 컴퓨트 시스템은:
   상기 가상 컴퓨트 시스템과 네트워크화된 통신에 인스턴스 프로비저닝(provisioning) 서비스로부터 상기 추가 가상 기계 인스턴스를 요청하고;
   상기 추가 가상 기계 인스턴스가 상기 활성 풀에 추가되도록 하고; 및
   상기 추가 가상 기계상에 컨테이너(container)를 생성하고 상기 추가 주기적인 요청과 관련된 프로그램 코드가 상기 컨테이너에 로딩되도록 함으로써 추가 가상 기계 인스턴스가 상기 하나 이상의 실행 파라미터들에 기초하여 미리-초기화되도록 구성되는, 시스템.
6. 청구항 4에 있어서, 상기 복수의 가상 기계 인스턴스들은 가상 기계 인스턴스들의 워밍 풀을 포함하고, 상기 가상 컴퓨트 시스템은:
   상기 가상 컴퓨트 시스템과 네트워크화된 통신에 인스턴스 프로비저닝(provisioning) 서비스로부터 상기 추가 가상 기계 인스턴스를 요청하고;
   상기 추가 가상 기계 인스턴스가 상기 워밍 풀에 추가되도록 하고; 및
   상기 가상 계상에 컨테이너(container)를 생성하고 상기 추가 주기적인 요청과 관련된 프로그램 코드가 상기 컨테이너에 로딩되도록 함으로써 추가 가상 기계 인스턴스가 상기 하나 이상의 실행 파라미터들에 기초하여 미리-초기화되도록 함으로써 추가 가상 기계 인스턴스가 상기 하나 이상의 실행 파라미터들에 기초하여 미리-초기화되도록 구성되는, 시스템.
7. 청구항 4에 있어서, 상기 복수의 가상 기계 인스턴스들은 가상 기계 인스턴스들의 활성 풀을 포함하고, 상기 가상 컴퓨트 시스템은:
   상기 활성 풀에 채워지지 않은(unfilled) 가상 기계 인스턴스를 위치시키고, 상기 채워지지 않은 가상 기계 인스턴스는 완전히 사용되지 않고; 및
   상기 채워지지 않은 가상 기계 인스턴스상에 컨테이너(container)를 생성하고 상기 추가 주기적인 요청과 관련된 프로그램 코드가 상기 컨테이너에 로딩되도록 함으로써 추가 가상 기계 인스턴스가 하나 이상의 실행 파라미터들에 기초하여 미리-초기화되도록 구성되는, 시스템.
8. 청구항 4에 있어서, 상기 복수의 가상 기계 인스턴스들은 그 위에 로딩된 하나 이상의 소프트웨어 컴포넌트들을 갖고 유저에게 할당될 것을 대기하는 가상 기계 인스턴스들의 워밍 풀을 포함하되, 상기 가상 컴퓨트 시스템은 가상 기계 인스턴스들의 수가 상기 축소된 양에 대응하는 수에 도달할 때까지 상기 워밍 풀에 추가 가상 기계 인스턴스들을 추가하는 것을 삼가함으로써 축소된 양의 유휴상태 컴퓨트 용량이 상기 가상 컴퓨트 시스템상에 유지되도록 구성되는, 시스템.
9. 청구항 4에 있어서, 상기 가상 컴퓨트 시스템은 추가 주기적인 요청을 수신한 것에 응답하여, 상기 추가 주기적인 요청과 관련된 프로그램 코드가 상기 추가 가상 기계 인스턴스상에 생성된 컨테이너에서 실행되도록 더 구성되고, 상기 프로그램 코드는 상기 추가 주기적인 요청이 상기 가상 컴퓨트 시스템에 의해 수신되기 전에 상기 컨테이너에 로딩되는, 시스템.
10. 청구항 4에 있어서, 상기 가상 컴퓨트 시스템은:
    제 1 프로그램 코드, 상기 제 1 프로그램 코드를 실행시키기 위한 제 1 최대 지속기간, 및 상기 제 1 프로그램 코드를 실행시키기 위한 제 1 시간 프레임(time frame)과 연관된 제 1 작업 요청을 수신하고;
    제 2 프로그램 코드 및 상기 제 2 프로그램 코드를 실행시키기 위한 제 2 시간 프레임과 연관된 제 2 작업 요청을 수신하고, 상기 제 2 시간 프레임은 적어도 부분적으로 상기 제 1 시간 프레임에 중첩하고; 및
    상기 제 1 프로그램 코드가 실행될 제 1 실행 시간 및 상기 제 2 프로그램 코드가 실행될 제 2 실행 시간을 상기 제 1 실행 시간이 적어도 상기 제 1 최대 지속기간에 의해 상기 제 2 실행 시간을 선행하도록 결정하도록 더 구성되는, 시스템.
11. 청구항 10에 있어서, 상기 가상 컴퓨트 시스템은 유저 인터페이스를 통하여, 제 1 경비와 연관된 제 1 정도의 시간 가요성(temporal flexibility) 및 제 2 경비와 연관되고 상기 제 1 정도보다 더 큰 제 2 정도의 시간 가요성 사이에서 선택하는 옵션을 제공하도록 더 구성되되, 상기 제 1 경비는 상기 제 2 경비보다 더 큰, 시스템.
12. 컴퓨터-구현 방법에 있어서:
    특정 실행 가능한 지시들로 구성된 하나 이상의 컴퓨팅 디바이스들에 의해 구현되는 것으로,
    하나 이상의 물리적 컴퓨팅 디바이스들상에 복수의 가상 기계 인스턴스들을 유지하는 단계;
    상기 가상 컴퓨트 시스템상에서 프로그램 코드들을 실행시키기 위한 착신 코드 실행 요청들을 모니터링하는 단계;
    상기 착신 코드 실행 요청들의 적어도 일부가 주기성을 보이는지 여부를 결정하는 단계로서, 상기 착신 코드 실행 요청들의 적어도 일부는 하나 이상의 실행 파라미터들과 연관되는, 상기 결정하는 단계;
    상기 착신 코드 실행 요청들의 적어도 일부가 주기성을 보인다는 결정에 응답하여, 축소된 양의 유휴상태(idle) 컴퓨트 용량이 상기 가상 컴퓨트 시스템상에 유지되도록 하는 단계로서, 상기 축소된 양은 상기 주기성에 기초하여 결정되는, 상기 유지되도록 하는 단계; 및
    상기 착신 코드 실행 요청들의 적어도 일부가 임계 시간 양내에 수신될 것이 예상되는지를 결정하는 단계; 및
    상기 착신 코드 실행 요청들의 적어도 일부가 상기 가상 컴퓨트 시스템에 의해 수신되는 것과 동일한 주기성을 추가 주기적인 요청이 보이기 전에 추가 가상 기계 인스턴스가 하나 이상의 실행 파라미터들에 기초하여 구성되도록 하는 단계를 포함하는, 방법.
13. 청구항 12에 있어서, 상기 복수의 가상 기계 인스턴스들은 가상 기계 인스턴스들의 활성 풀을 포함하고, 추가 가상 기계 인스턴스가 하나 이상의 실행 파라미터들에 기초하여 구성되도록 하는 단계는 :
    상기 가상 컴퓨트 시스템과 네트워크화된 통신에 인스턴스 프로비저닝(provisioning) 서비스로부터 상기 추가 가상 기계 인스턴스를 요청하는 단계;
    상기 추가 가상 기계 인스턴스가 상기 활성 풀에 추가되도록 하는 단계; 및
    상기 추가 가상 기계상에 컨테이너(container)를 생성하고 상기 착신 코드 실행 요청들의 적어도 일부와 관련된 프로그램 코드가 상기 컨테이너에 로딩되도록 하는 단계를 포함하는, 방법.
14. 청구항 12에 있어서, 상기 복수의 가상 기계 인스턴스들은 가상 기계 인스턴스들의 워밍 풀을 포함하고, 추가 가상 기계 인스턴스가 하나 이상의 실행 파라미터들에 기초하여 구성되도록 하는 단계는 :
    상기 가상 컴퓨트 시스템과 네트워크화된 통신에 인스턴스 프로비저닝(provisioning) 서비스로부터 상기 추가 가상 기계 인스턴스를 요청하는 단계;
    상기 추가 가상 기계 인스턴스가 상기 워밍 풀에 추가되도록 하는 단계; 및
    상기 추가 가상 기계상에 컨테이너(container)를 생성하고 상기 추가 주기적인 요청과 관련된 프로그램 코드가 상기 컨테이너에 로딩되도록 하는 단계를 포함하는, 방법.
15. 청구항 12에 있어서,
    제 1 세트의 실행 요건들과 관련된 제 1 작업(job)을 실행시키기 위한 요청을 수신하는 단계;
    제 2 세트의 실행 요건들과 관련된 제 2 작업을 실행시키기 위한 요청을 수신하는 단계;
    제 1 및 제 2 세트들의 실행 요건들에 기반된 하나 이상의 스케줄링 기준을 결정하는 단계; 및
    상기 하나 이상의 스케줄링 기준이 만족되도록 상기 제 1 작업을 실행시키기 위한 제 1 실행 시간 및 상기 제 2 작업을 실행시키기 위한 제 2 실행 시간을 결정하는 단계를 더 포함하는, 방법.

Images