KR101700313B1 - 인스턴스 호스트 구성 - Google Patents

Abstract

인스턴스 호스트 구성을 위한 방법 및 장치가 개시된다. 시스템은 네트워크-액세스가능한 서비스의 자원 인스턴스에 대해 구성가능한 복수의 인스턴스 호스트, 및 인스턴스 호스트의 원격 구성을 관리할 제어 서버를 포함한다. 클라이언트로부터의 인스턴스 구성 요청에 응답하여, 선택된 제어 서버는 하나 이상의 커맨드의 시퀀스를, 선택된 인스턴스 호스트에, 송신한다. 선택된 인스턴스 호스트는 원격 커맨드 실행기를 실체화한다. 원격 커맨드 실행기는 커맨드 시퀀스에 대응하는 구성 작업을 개시하고, 그리고 종료한다. 선택된 제어 서버는, 실행기에 의해 개시된 작업의 결과에 적어도 부분적으로 기반하여, 인스턴스 구성 요청에 대한 응답을 제공한다.

Description

인스턴스 호스트 구성{INSTANCE HOST CONFIGURATION}

많은 회사 및 다른 조직은, (예를 들어, 로컬 네트워크의 일부분으로서) 병설되거나 또는 대신에 (예를 들어, 하나 이상의 사설 또는 공중 중간 네트워크를 통하여 접속되는) 다수의 구별되는 지리적 위치에 위치하는 컴퓨팅 시스템과와 같이, 그들 작업을 지원하도록 수많은 컴퓨팅 시스템을 상호접속하는 컴퓨터 네트워크를 운용한다. 예를 들어, 상당한 수의 상호접속된 컴퓨팅 시스템을 수용하는 데이터 센터는, 단일 조직에 의해 그리고 그를 대신하여 운용되는 사설 데이터 센터, 및 컴퓨팅 자원을 고객에게 제공하도록 비즈니스로서 엔티티에 의해 운용되는 공중 데이터 센터와 같이, 다반사가 되었다. 일부 공중 데이터 센터 운용자는 다양한 고객에 의해 소유된 하드웨어에 대해 네트워크 액세스, 전력 및 보안 설치 시설을 제공하는 한편, 다른 공중 데이터 센터 운용자는 그들 고객에 의한 사용을 위해 이용가능하게 되는 하드웨어 자원도 포함하는 "전 서비스" 시설을 제공한다. 그렇지만, 전형적 데이터 센터의 규모 및 범위가 증가함에 따라, 물리적 컴퓨팅 자원을 프로비저닝하고, 집행하고, 관리하는 태스크가 점점 복잡하게 되었다.

상품 하드웨어에 대한 가상화 기술의 출현은 다양한 요구를 갖는 많은 고객을 위해 대규모 컴퓨팅 자원을 관리하는 것에 관하여 이점을 제공하여, 다양한 컴퓨팅 자원이 다수의 고객에 의해 효율적으로 보안 공유 가능하게 하였다. 예를 들어, 가상화 기술은 각각의 사용자에게 단일 물리적 컴퓨팅 기계에 의해 호스팅되는 하나 이상의 가상 기계를 제공함으로써 단일 물리적 컴퓨팅 기계가 다수의 사용자 간에 공유 가능하게 할 수 있으며, 각각의 그러한 가상 기계는 사용자에게 그들이 소정 하드웨어 컴퓨팅 자원의 유일한 운용자 및 관리책임자라는 착각을 제공하는 한편, 다양한 가상 기계 간 애플리케이션 격리 및 보안도 제공하는 구별되는 논리적 컴퓨팅 시스템으로서 역할하는 소프트웨어 시뮬레이션이다. 더욱, 일부 가상화 기술은, 다수의 구별되는 물리적 컴퓨팅 시스템에 걸치는 다수의 가상 프로세서를 갖는 단일 가상 기계와 같이, 2개 이상의 물리적 자원에 걸치는 가상 자원을 제공할 수 있다.

가상화된 컴퓨팅, 저장 및 네트워킹 자원의 제공자에 의해 지원되는 기능성 및 특징이 성장함에 따라, 그리고 대규모 제공자에 의해 사용되는 하드웨어 플랫폼의 플리트가 성장함에 따라, 플랫폼에 대한 구성 변경과 같은 집행 제어 작업을 구현하는 태스크는 그 자체로 자원 집약적으로 될 수 있다. 제어 및 구성 작업의 오버헤드는 일부 경우에 있어서 사용자에 의해 인지되는 바와 같은 가상화된 자원의 응답성에 충격을 주기 시작할 수도 있다.

도 1은, 적어도 일부 실시예에 따른, 일례의 시스템 환경의 예시도;
도 2는, 적어도 일부 실시예에 따른, 인스턴스 호스트 플랫폼의 원격 구성을 위해 구성된 제어 서버의 컴포넌트의 예시도;
도 3은, 적어도 일부 실시예에 따른, 인스턴스 호스트 플랫폼의 컴포넌트의 예시도;
도 4는, 적어도 일부 실시예에 따른, 클라이언트와, 제어 서버와, 인스턴스 호스트 플랫폼 간 상호작용의 예시도;
도 5는, 적어도 일부 실시예에 따른, 제어 서버에서 작업 흐름 관리기 노드로부터 시작하는 커맨드 흐름의 일례도;
도 6은, 적어도 일부 실시예에 따른, 인스턴스 호스트 플랫폼의 등록과 연관된 작업의 예시도;
도 7은, 적어도 일부 실시예에 따른, 자원 인스턴스를 론칭하는 것과 연관된 작업의 예시도;
도 8은, 적어도 일부 실시예에 따른, 제어 서버로부터 인스턴스 호스트에 발행된 커맨드 요청의 엘리먼트의 예시도;
도 9는, 적어도 일부 실시예에 따른, 인스턴스 호스트의 원격 구성을 수행하도록 동작가능한 제어 서버의 작업의 태양을 예시하는 순서도;
도 10은, 적어도 일부 실시예에 따른, 제어 서버에서 원격 이벤트 통지와 관련된 작업의 태양을 예시하는 순서도;
도 11은, 적어도 일부 실시예에 따른, 제어 서버 풀 사이즈(control server pool size)를 결정하는 것과 관련된 작업의 태양을 예시하는 순서도;
도 12는, 적어도 일부 실시예에 따른, 제3자 플랫폼의 원격 구성을 관리하도록 구성된 제어 서버의 작업의 태양을 예시하는 순서도;
도 13은, 적어도 일부 실시예에 따른, 제3자에 의해 그리고 제공자 네트워크에 의해 지원되는 컴퓨팅 자원 인스턴스 정의의 예시도;
도 14는, 적어도 일부 실시예에 따른, 제3자 플랫폼에 대한 플랫폼 승인 요청에 응답하여 제공자 네트워크의 제어 서버에 의해 수행되는 작업의 태양을 예시하는 순서도;
도 15는, 제공자 네트워크의 제어 서버 컴포넌트에 의해 제어되는 제3자 플랫폼 상에 실체화된 인스턴스를 포함하여, 클라이언트가 복수의 제공자로부터 자원 인스턴스를 선택 가능하게 하도록 구현될 수 있는 프로그램식 사용자 인터페이스의 일례도; 및
도 16은 적어도 일부 실시예에서 사용될 수 있는 일례의 컴퓨팅 디바이스를 예시하는 블록 선도.
여기에서는 수개의 실시예 및 예시적 도면에 대하여 예로서 실시예가 설명되고 있기는 하지만, 당업자는 실시예가 설명된 실시예 또는 도면으로 한정되는 것은 아님을 인식할 것이다. 거기에서의 도면 및 상세한 설명은 개시된 특정 형태로 실시예를 한정하려는 의도가 아니라, 반대로, 본 발명은 첨부 청구범위에 의해 정의되는 바와 같은 취지 및 범위 내에 드는 모든 수정, 균등물 및 대안을 망라하는 것임을 이해하여야 한다. 여기에서 사용되는 제목은 단지 편성 목적일 뿐이고 청구범위 또는 설명의 범위를 제한하도록 사용됨을 의미하지는 않는다. 본 출원의 곳곳에서 사용되는 바와 같이, 단어 "할 수 있다"는 의무적 의미(즉, 필수를 의미)보다는 허용적 의미(즉, 잠재성을 가짐을 의미)로 사용된다. 유사하게, 단어 "포함한다" 및 그 활용형은 포함하지만 국한되지는 않음을 의미한다.

낮은 오버헤드 자원 인스턴스 호스트 구성을 위한 방법 및 장치의 다양한 실시예가 설명된다. 인터넷 및/또는 다른 네트워크를 통하여 액세스가능한 (다양한 유형의 클라우드-기반 컴퓨팅 또는 저장과 같은) 하나 이상의 멀티-테넌트 서비스를 분산된 클라이언트 세트에 제공하도록 공중 부문 조직 또는 회사와 같은 엔티티에 의해 수립된 네트워크가 본 문서에서는 제공자 네트워크라고 칭해질 수 있다. 용어 "멀티-테넌트(multi-tenant)"는 여기에서는, 서비스 기능성의 부분들을 소정 기저 자원 세트를 사용하여 제공받고 있는 하나의 클라이언트가 그 자원 세트가 다른 클라이언트에게도 사용되고 있음을 알고 있지 않을 수 있도록, 여러 다른 클라이언트 엔티티에게 각각의 커스터마이징가능한, 격리된 서비스 뷰가 제공되는 그러한 방식으로 애플리케이션 및/또는 데이터 가상화를 구현하도록 설계되는 서비스를 지칭하는데 사용될 수 있다. 제공자 네트워크는 일부 실시예에서는, 멀티-테넌트 서비스에 부가해서든 그 대신에든, (사설 클라우드 구현에 대해서와 같은) 단일-테넌트 서비스를 지원할 수 있다. 그러한 제공자 네트워크는, 제공자에 의해 제공되는 기반구조 및 서비스를 구현, 구성 및 분산하는데 필요로 되는, 물리적 및/또는 가상화된 컴퓨터 서버, 저장 디바이스, 네트워킹 장비 등의 집합과 같은, 다양한 자원 풀(resource pool)을 호스팅하는 수많은 데이터 센터를 포함할 수 있다. 제공자 네트워크의 자원의 부분집합은 일부 실시예에서는, 가상 또는 물리적 컴퓨팅 인스턴스, 저장 인스턴스, 또는 네트워크 자원 인스턴스와 같은, 소위 "인스턴스"라는 유닛으로 클라이언트에 의해 예약(및 그에게 할당)을 위해 제공될 수 있다. 가상 컴퓨팅 인스턴스는, 예를 들어, (CPU의 유형 및 수, 주 메모리 사이즈, 저장 디바이스 수 및 사이즈 등을 나타냄으로써 특정될 수 있는) 특정된 컴퓨팅 능력 및 특정된 소프트웨어 스택(예를 들어, 순차로 하이퍼바이저에 더하여 실행될 수 있는, 특정 버전의 운영 체제)을 갖는 하나 이상의 서버를 포함할 수 있다. 가상 컴퓨팅 인스턴스, 저장 자원 인스턴스 또는 네트워크 자원 인스턴스를 포함하는 다양한 종류의 자원 인스턴스는 여기에서는 "인스턴스 호스트 플랫폼" 또는 "인스턴스 호스트"라고 칭해지는 시스템 상에서 실체화될 수 있다. 일부 실시예에 있어서, 특정 유형의 N개의 다른 가상 컴퓨팅 인스턴스를 실체화할 수 있는 인스턴스 호스트 플랫폼은, 예를 들어, 전형적으로 하드웨어 서버의 컴퓨팅 능력의 작은 단편을 이용하는 운영 체제 소프트웨어 및/또는 가상화 소프트웨어와 같은, 초기에 설치된 비교적 저-레벨 소프트웨어 컴포넌트의 선택된 세트를 갖는 하드웨어 서버를 포함할 수 있다. 더 많은 가상 컴퓨팅 인스턴스가 론칭됨에 따라, 예를 들어, 여러 다른 가상 컴퓨팅 인스턴스 상에서 실행되는 클라이언트 애플리케이션을 위해 서버의 컴퓨팅 능력의 더 큰 부분이 사용되게 될 수 있다. 여러 다른 유형의 컴퓨팅 디바이스는, 범용 또는 특수용 컴퓨터 서버, 저장 디바이스, 네트워크 디바이스 등을 포함하여, 여러 다른 실시예에서 제공자 네트워크의 자원을 구현하도록 조합으로 또는 단독으로 사용될 수 있다. 아래에 설명되는 바와 같이, 제공자 네트워크 자원의 부분집합은 일부 실시예에서는 (예를 들어, 클라이언트 요청에 응답하여 인스턴스 호스트 상에서 자원 인스턴스를 론칭, 모니터링 및 종료하기 위한) 제어 및 구성 목적에 전용될 수 있다. 그러한 전용 제어 자원은 여기에서는 "제어 플레인 자원", "제어 플레인 서버" 또는 "제어 서버"라고 칭해질 수 있다. 적어도 일부 실시예에 있어서, 제공자 네트워크 내 인스턴스 호스트 상에서 자원 인스턴스를 구성하는데 사용되는 것에 부가하여, 소정 제공자 네트워크의 적어도 일부의 제어 서버는 또한, 아래에 더 상세히 설명되는 바와 같이, 제공자 네트워크 외부, 예를 들어, 제3자 데이터 센터 또는 시설 내 원격 플랫폼에서, 또는 접속 거점(point-of-presence) 위치 또는 유사한 시설에서 호스팅되는 인스턴스를 원격으로 구성할 수 있다.

일 실시예에 의하면, 인스턴스를 관리하기 위한 제어 소프트웨어는 인스턴스 호스트 상에 부과되는 집행 오버헤드를 최소화하는 그러한 방식으로 구현될 수 있다. 구성-관련 프로세싱 중 다량은, 고-레벨 결정 및 메타데이터 조작이 제어 서버에서 구현될 수 있는 한편, 단지 단순한 저-레벨(및 전형적으로는 멱등 및 무상태) 구성-관련 커맨드만이 인스턴스 호스트 자체에서 실행되어야 할 수 있도록, 그러한 실시예에서는 인스턴스 호스트로부터 분담될 수 있다. 그러한 실시예에 있어서 인스턴스 상태 및 인스턴스 유형 정의에 대한 상세는 인스턴스 호스트에서 이해되도록 요구되지 않을 수 있다. 예를 들어, 하나의 그러한 실시예에 있어서, 계층화된 제어 소프트웨어 아키텍처는 제어 서버에서 채용될 수 있으며, 거기에서는 인스턴스 상태 관리기가 작업 흐름 관리기 컴포넌트를 인보크함으로써 클라이언트의 인스턴스 구성 요청에 응답한다. 작업 흐름 관리기는 (클라이언트의 인스턴스 구성 요청에 응답하여 인스턴스 상태 관리기에 의해 도달되는) 상위-레벨 구성 결정을, 제어 소프트웨어의 구성 정의기 컴포넌트에 의해 제공되는 인스턴스 구성 정의의 맥락에서, 그 구성 정의에 특정한 하나 이상의 하위-레벨 작업 흐름 작업으로 번역할 수 있다. 순차로 작업 흐름 관리기는 작업 흐름 작업을 제어 서버에서의 제어 소프트웨어의 커맨드 통신기 컴포넌트에 송신할 수 있다. 커맨드 통신기는, 소정 작업 흐름 작업에 응답하여, 네트워크를 통해 특정 인스턴스 호스트에, 커맨드 프로토콜에 따라, (운영 체제 커맨드 또는 가상화 소프트웨어 커맨드와 같은) 하나 이상의 저-레벨 커맨드를 보안 제출할 수 있다.

인스턴스 호스트에서, (단순 웹 서버와 같은) 커맨드 수신기는 원격 커맨드 실행기(remote command executor)(RCE)를 실체화함으로써 통신기로부터의 소정 커맨드에 응답할 수 있다. 요구에 따라 커맨드 수신기에 의해 나오는 단일 실행 스레드(single thread of execution)(또는 소프트웨어 프로세스)를 포함할 수 있는 RCE는 적어도 일부 실시예에서는, 전형적으로는 인스턴스 호스트 상의 가상화 소프트웨어 컴포넌트에 또는 인스턴스 호스트에서의 운영 체제 컴포넌트에 보내지는, 하나 이상의 작업을 발행하기에 충분히 길게 활성으로 남아있을 뿐일 수 있다. RCE는 그러한 실시예에서는 작업이 개시된 후에 퇴출 또는 종료할 수 있다. 커맨드 수신기는 RCE의 작업에 의해 발생된 반환 코드, 표준 출력 또는 오류 출력을 커맨드 통신기에 제공할 수 있다. 이들 결과는 요청된 커맨드의 성공 또는 실패를 결정하도록 제어 서버에서 해석될 수 있고, 클라이언트의 인스턴스 구성 요청에 대한 응답은 그에 따라 일부 실시예에서는 포뮬레이팅될 수 있다. 그리하여, 인스턴스 호스트에서의 인스턴스 구성 오버헤드가 그러한 실시예에서는 RCE의 실체화 및 RCE에 의해 요청된 작업으로 크게 한정되고, 그로써 클라이언트-요청된 자원 인스턴스 자체의 사용을 위해 방대한 대다수의 인스턴스 호스트 자원을 보유할 수 있다. 일부 구현에 있어서, 제어 서버 소프트웨어의 여러 다른 계층에서의 구성 책임의 캡슐화는 수백 또는 수천의 인스턴스 호스트가 단일 제어 서버 또는 수개의 제어 서버로부터 원격으로 구성될 수 있게 하기에 충분히 효율적일 수 있다.

적어도 일부 실시예에 있어서, RCE를 실체화하는 것은, 예를 들어, 웹 서버에 의해 공통 게이트웨이 인터페이스(CGI)에 따라 적어도 하나의 실행 스레드를 실체화하는 것을 포함할 수 있다. HTTPS(하이퍼텍스트 전송 프로토콜, HTTP의 보안 버전)와 같은 효율적인 주지의 프로토콜이 일부 구현에서는 인스턴스 호스트에 커맨드 송신 및/또는 인스턴스 호스트로부터 결과 수신을 위해 사용될 수 있다. 커맨드 자체는 일부 실시예에서는 JSON(JavaScript Object Notation) 또는 XML(Extended Markup Language)의 소정 변종과 같은 산업-표준 포맷 또는 표기법으로 포매팅될 수 있다. 다른 실시예에서는, 사설 또는 전유 프로토콜 및/또는 포맷이 사용될 수 있다. 사용되는 커맨드 프로토콜은 복수의 커맨드 유형을 지원할 수 있으며, 그 적어도 하나의 부분집합은 멱등이도록 설계된다 - 예를 들어, 소정 파라미터 세트를 갖는 특정 멱등 커맨드 "cmd1"가 한 번보다 많이 발행되면, 그 커맨드의 두 번째 발행 및 어느 추후의 발행은 부정적 효과를 갖지 않을 수 있다.

일부 실시예에 있어서, 제공자 네트워크는 복수의 지리적 영역으로 조직될 수 있고, 각각의 영역은, 여기에서는 "가용성 존"이라 칭해질 수 있는, 하나 이상의 가용성 컨테이너를 포함할 수 있다. 순차로 가용성 컨테이너는, 소정 가용성 컨테이너 내 자원이 다른 가용성 컨테이너 내 실패로부터 격리되는 그러한 방식으로 엔지니어링된, 하나 이상의 구별되는 위치 또는 데이터 센터를 포함할 수 있다. 즉, 하나의 가용성 컨테이너 내 실패는 어느 다른 가용성 컨테이너 내 실패의 결과를 초래할 것으로 예상되지 않을 수 있다; 그리하여, 자원 인스턴스 또는 제어 서버의 가용성 프로파일은 다른 가용성 컨테이너 내 자원 인스턴스 또는 제어 서버의 가용성 프로파일과는 독립적인 것으로 의도된다. 클라이언트는 각각의 가용성 컨테이너 내 다수의 애플리케이션 인스턴스를 론칭함으로써 단일 위치에서의 실패로부터 그들 애플리케이션을 보호할 수 있을 수 있다. 동시에, 일부 구현에서는 저렴하고 낮은 레이턴시 네트워크 접속성이 동일한 지리적 영역 내에 상주하는 자원 인스턴스 간에 제공될 수 있다(그리고 동일한 가용성 컨테이너의 자원 간 네트워크 송신은 훨씬 더 빠를 수 있다). 일부 클라이언트는 그들 애플리케이션의 다양한 컴포넌트가 실행되는 바로 그곳의 소망 제어도를 유지하기 위해, 예를 들어, 영역 레벨에서든, 가용성 컨테이너 레벨에서든, 데이터 센터 레벨에서든 그들 자원이 예약 및/또는 실체화되는 위치를 특정하기를 바랄 수 있다. 다른 클라이언트는, 자원이, 예를 들어, 성능, 높은 가용성, 지원되는 소프트웨어 레벨 등에 대한 클라이언트 요건을 충족하는 한, 그들 자원이 예약 또는 실체화되는 바로 그 위치에는 관심이 더 적을 수 있다. 하나의 가용성 컨테이너(또는 데이터 센터)에 위치하는 제어 서버는 일부 실시예에서는 다른 가용성 컨테이너(또는 다른 데이터 센터) 내 인스턴스 호스트에서의 자원 인스턴스를 원격으로 구성할 수 있을 수 있다 - 즉, 특정 가용성 컨테이너 또는 데이터 센터는 로컬 자원 인스턴스를 관리할 로컬 제어 서버를 가질 필요가 없을 수 있다.

적어도 일부 실시예에 있어서, 제어 서버는 제어 서버로부터 관리되고 있는 자원 인스턴스에서 (다양한 서브컴포넌트에서의 오류, 또는 예기치않은 셧다운과 같은) 특정 유형의 이벤트가 일어날 때 통지를 수신하도록 구성될 수 있다. 하나의 그러한 실시예에 있어서, 제어 서버는 인스턴스 호스트 플랫폼에서 사용 중인(또는 사용 중인 운영 체제에 의해) 가상화 소프트웨어(예를 들어, 하이퍼바이저)가 제공되는 기존 이벤트 모니터를 이용할 수 있다. 제어 서버를 대신하여 인스턴스 호스트에서 실체화된, 경량의 이벤트 디스패처가 일 구현에서는 이벤트 모니터에 가입할 수 있다. 이벤트 모니터가 이벤트 디스패처에 이벤트가 일어났음을 알려주고, 이벤트 디스패처가 그 이벤트에 대해 제어 서버에의 통지가 적합하다고 결정할 때, 이벤트 디스패처는 대응하는 통지를 제어 서버에(예를 들어, 커맨드 통신기에 또는 작업 흐름 관리기에) 송신할 수 있다. 이벤트의 표시가 제어 소프트웨어 스택 위로, 예를 들어, 커맨드 통신기로부터 작업 흐름 관리기로 그리고 계속 인스턴스 상태 관리기로, 넘겨질 수 있으며, 그러면, 이벤트 유형에 기반하여, 필요에 따라 인스턴스 상태 메타데이터를 업데이트할 수 있다. 일부 실시예에 있어서, 인스턴스 상태 관리기는 이벤트가 예기치않은 셧다운 또는 다른 실패였으면 복구 작업을 개시할 수 있다. 복구 작업은 일부 실시예에서는 다른 구성 작업과 유사한 흐름을 따를 수 있다 - 예를 들어, 그것들은 인스턴스 상태 관리기에 의해 개시되고, 작업 흐름 관리기 및 커맨드 통신기를 통하여 연속적으로 하위-레벨 커맨드로 번역되고, RCE를 통하여 실행을 위해 인스턴스 호스트에서 커맨드 수신기에 송신될 수 있다.

계층화된 제어 소프트웨어 아키텍처에 대한 설계 목표 중 하나는 특정 유형의 대규모 실패 이벤트로부터의 복구가 허용가능한 타임프레임 내에서 성취될 수 있음을 보장하는 것일 수 있다. 예를 들어, 데이터 센터 및 가용성 존이 데이터-센터-범위 또는 가용성-존-범위 실패를 감축하도록 중대한 컴포넌트에서 다양한 리던던시 레벨로 구현될 수 있더라도, 그러한 대규모 실패를 100% 보증으로 방지하는 것은 매우 힘들 수 있다. 제공자 네트워크의 클라이언트의 다수가 임무에 필수적인 기능에 대해 그 자원 인스턴스에 의존할 수 있으므로, 그러한 드문 실패 이벤트로부터의 합리적으로 신속한 복구가 소망될 수 있다. 따라서, 적어도 일부 실시예에서는, 제어 서버에 전용인 자원이 대규모 실패에 대한 목표 복구 시간에 기반하여 결정될 수 있다. 대규모 실패의 경우에 인스턴스 복구 구성 작업이 요구될 수 있는 레이트가 추정될 수 있다. 예를 들어, 관리될 실패의 사이즈의 표현(예를 들어, 비상 계획이 세워져야 하는 동시적 또는 준-동시적 실패의 수)은 물론 여러 다른 데이터 센터로의 그들 인스턴스의 잠재적 매핑, 인스턴스를 완전 재-실체화하도록 수행될 필요가 있을 복구 관련 구성 작업의 시퀀스, 및 특정 레벨의 컴퓨팅 및 네트워크 능력을 갖는 복구 서버가 단위 시간당 편성할 수 있을 수 있는 그러한 작업의 수도 포함하는 파라미터화된 모델이 발생될 수 있다. 복구 시간 목표를 충족하는데 요구되는 복구 작업 레이트를 포함하는, 모델의 다양한 파라미터를 사용하여, 특정 자격 레벨의 제어 서버의 수가 결정될 수 있고, 적합한 유형의 제어 서버의 풀이 확립될 수 있다. 일부 경우에 있어서, 대규모 실패 이벤트에 응답하는데 필요로 되는 제어 서버의 수는 정규 작업 조건에 요구되는 제어 서버의 수를 초과할 수 있고, 그 경우 제공자 네트워크 운용자는, 배치될 제어 서버의 수를 결정하기 전에, 가외 제어 서버를 유지하는 비용 대, 대규모 실패를 취급하기에 충분한 제어 서버를 갖지 않는 결과를 저울질할 수 있다.

적어도 일부 실시예에 있어서, 작업 흐름 관리기 및 커맨드 통신기와 같은, 제어 서버의 컴포넌트 중 수개 또는 전부는 사이즈가 필요에 따라 동적으로 증가될 수 있는 클러스터의 노드로서 구현될 수 있다. 예를 들어, 소정 시점에 실체화된 W개의 작업 흐름 관리기 노드 및 C개의 커맨드 통신기 노드가 있을 수 있고, 각각의 컴포넌트에 대한 노드의 수는 소망에 따라 증가되거나 감소될 수 있다. 소정 하드웨어 디바이스가 일부 구현에서는 소정 유형의 제어 서버 컴포넌트의 하나 이상의 노드에 사용될 수 있다 - 예를 들어, W개의 작업 흐름 관리기 노드 및 C개의 커맨드 통신기 노드를 호스팅하도록 S개의 제어 서버를 할당하는 것이 가능할 수 있으며, 여기서 S <= (W + C)이다.

위에서 언급된 바와 같이, 소정 인스턴스 호스트 플랫폼은 일부 실시예에서는 다수의 자원 인스턴스를 지원할 수 있을 수 있다. 일부 그러한 실시예에서는 소정 인스턴스 호스트 상의 자원 인스턴스와 그들을 관리하는 제어 서버 간 융통성 있는 매핑이 구현될 수 있다 - 예를 들어, 호스트(H1) 상의 하나의 자원 인스턴스(RI-X)는 제어 서버(CS1)에 의해 관리될 수 있는 한편, H1 상의 다른 자원 인스턴스(RI-Y)는 다른 제어 서버(CS2)에 의해 관리될 수 있다. 적어도 일부 실시예에 있어서, 병행 제어 메커니즘은 상충하는 작업(예를 들어, 동일한 이름으로 또는 상충하는 이름으로 파일 시스템과 같은 소프트웨어 저장 디바이스를 생성하라는 2개의 다른 커맨드)이 시도되는 것을 방지하도록 구현될 수 있다. 예를 들어, 소정 인스턴스 호스트 플랫폼 상의 병행 구성 작업의 수는 일 구현에서는 로크를 사용하여 제한될 수 있다. 로크 관리기가 일부 실시예에서는 구현될 수 있으며, 그로부터 배타적 로크(공유된 로크를 유지하는 동안 허용되는 인스턴스 호스트 작업의 유형 및/또는 공유자의 수에 대한 제한을 갖는 공유된 로크)가 소정 인스턴스 호스트 상의 구성 작업을 수행하기 이전에 획득되어야 한다.

적어도 일부 실시예에 있어서는, 위에서 설명된 자원 인스턴스 구성에 사용되는 모듈식 접근법이 또한 메트릭 수집 또는 로그 레코드 수집과 같은 다른 유형의 작업에 사용될 수 있다. 예를 들어, 인스턴스 호스트로부터 제어 서버에 (CPU 이용, 메모리 사용 또는 네트워크 사용 측정치와 같은) 성능 정보를 푸싱하는 대신에, 제어 서버 메트릭 수집기 컴포넌트가 위에서 설명된 커맨드 통신기를 사용하여 인스턴스 호스트에 "메트릭-입수" 커맨드를 발행할 수 있는 풀 모델이 구현될 수 있다. RCE 또는 유사한 단명 스레드 또는 프로세스는 인스턴스 호스트에서 하이퍼바이저 또는 운영 체제 툴을 사용하여 정보를 수집하도록 실체화될 수 있고, 결과는 메트릭 수집기에 다시 보내질 수 있다.

클라이언트가 인스턴스 론칭 요청을 제어 서버에 발행할 때, 요청된 인스턴스에 사용되는 특정 인스턴스 호스트는 여러 다른 실시예에 있어서 수개의 기준 중 어느 것에라도 기반하여 선택될 수 있다. 일부 경우에 있어서, 인스턴스 호스트는 클라이언트의 식별 정보에 적어도 부분적으로 기반하여 선택될 수 있다 - 예를 들어, 클라이언트의 인터넷 프로토콜 주소 또는 물리적 주소는 클라이언트의 구내에 지리적으로 가까운 데이터 센터를 선택하도록 사용될 수 있다. 클라이언트가 일부 위치에서만 이용가능하거나, 또는 데이터 센터 간 공급 또는 수요 변화에 기인하여 다른 것들보다 소정 데이터 센터에서 더 쉽게 이용가능한 특정 유형의 자원 인스턴스를 요청하면, 인스턴스 호스트는 요청된 자원의 가용성에 기반하여 선택될 수 있다. 가격책정 정책(예를 들어, 클라이언트가 특정 세트의 인스턴스 호스트를 사용하여 가장 잘 지원될 수 있는 특정 가격 레벨에 대한 선호를 표현하였는지)은 물론, 제공자 네트워크 내의 현재 성능 조건 및 동향도 일부 실시예에서는 특정 인스턴스 호스트를 선택하는데 사용될 수 있다.

일부 실시예에 있어서, 제공자 네트워크의 제어 소프트웨어 아키텍처는, 예를 들어, 제공자 네트워크 외부의 데이터 센터 또는 다른 시설에서, 또는 제공자 네트워크와 다른 네트워크 간 액세스 포인트에서, 원격 위치에서의 장비를 사용하여 자원 인스턴스의 실체화를 지원할 수 있다. 예를 들어, 제3자 제공자는 제공자 네트워크의 제어 서버를 사용하여 관리되게 되는 자원 인스턴스에 대해 하드웨어를 배치함으로써 데이터 센터에서 충분히 사용되지 않는 하드웨어를 이용하기를 바랄 수 있다. 다른 일례에 있어서, 제공자 네트워크와 연관된 하나 이상의 인터넷 접속 거점(POP) 위치에서의 호스트는 일부 실시예에서는 제어 서버를 사용하여 원격 인스턴스에 이용될 수 있다. 일부 그러한 POP 위치에 있어서, 호스트 중 적어도 일부는 제공자 네트워크의 (컨텐트 배포와 같은) 서비스를 지원하도록 구성될 수 있고, 그러한 호스트는 일부 경우에서는 제공자 네트워크 내 자원 인스턴스를 실체화하는데 사용되는 인스턴스 호스트의 대부분에 전형적으로 설치되는 소프트웨어 스택의 골자 버전을 사용할 수 있다. 그러한 골자 호스트는 제어 서버에 의해 자원 인스턴스를 실체화하는데 사용될 수 있다. 용어 "원격 플랫폼"은 여기에서는 제3자에 의해 전적으로 소유/관리되고 제공자 네트워크 밖에 위치하는 플랫폼, 또는 제공자 네트워크와 원격통신 제공자와 같은 다른 서비스 제공자 간 경계에 있는 POP 또는 유사한 엔티티에 위치하는 플랫폼을 지칭하는데 사용될 수 있다. 유사하게, 용어 "원격 위치"는 그러한 원격 플랫폼이 편입되어 있는 시설을 지칭하는데 사용될 수 있다. 소정 제어 서버는 일부 실시예에서는 제공자 네트워크의 자신의 인스턴스 호스트와 더불어 또는 그 대신에, 제3자 플랫폼도 관리할 수 있을 수 있다. 제공자 네트워크 운용자는, 그것이 클라이언트가 액세스가능한 자원의 전반적 풀을 증가시킬 수 있고, 또한 더 나은 지리적 분산, 강화된 시스템-범위 위험 관리, 및 수입 증가의 결과에 이를 수 있으므로, 그러한 시나리오를 기꺼이 지원할 수 있다. 하나의 그러한 실시예에 있어서, 제3자 벤더(또는 POP 위치 운용자)는, 제공자 네트워크의 자신의 인스턴스 호스트가 사용되는 방식과 유사한 방식으로 가상화된 자원을 호스팅하도록 사용될 수 있는, 원격 시설에 위치하는 후보 플랫폼을 나타내는 플랫폼 승인 요청을 (예를 들어, 제어 서버 컴포넌트에 의해 지원되는 프로그램식 인터페이스를 통하여) 제출할 수 있다. 응답하여, 플랫폼 자격을 검증할 책임이 있는 제어 서버 컴포넌트는 후보 플랫폼에 대해 하나 이상의 테스트를 수행할 수 있다. 여기에서는 "자격 결정 작업"이라고 칭해질 수 있는 그러한 테스트는, 설치된 소프트웨어 스택 체크, 성능 테스트, 원격 커맨드 실행기(RCE) 메커니즘이 제3자 플랫폼 상에서 성공적으로 사용될 수 있는지 검증하는 체크 등을 포함하는, 다양한 다른 컴포넌트를 포함할 수 있다. 특정 후보 플랫폼이 테스트를 통과하면, 그것은 자원 인스턴스가 제공자 네트워크의 제어 서버에 의해 구성될 수 있는 "승인된" 플랫폼으로서 지정될 수 있다. (일부 실시예에서는 유사한 자격 테스트가 제공자 네트워크의 자신의 하드웨어 플랫폼에 대해, 인스턴스에 대한 그들 사용 이전에, 수행될 수 있다).

후보 원격(예를 들어, 제3자 또는 POP) 플랫폼이 승인된 후에, 그것은 이용가능한 인스턴스 호스트의 풀에 포함될 수 있으며, 그로부터 그것은 클라이언트의 인스턴스 구성 요청에 응답하도록 선택될 수 있다. 유사한 계층화된 제어 소프트웨어 접근법은 제공자 네트워크의 자신의 인스턴스 호스트에 대해 사용되는 바와 같이 승인된 인스턴스 호스트 플랫폼을 구성하도록 사용될 수 있다 - 예를 들어, 제어 서버 엔드에서의 인스턴스 상태 관리기, 작업 흐름 관리기 및 커맨드 통신기는 제3자 플랫폼 상의 로컬 구성 작업을 수행하기 위해 원격 커맨드 실행기(RCE)를 인보크하도록 협력할 수 있다. 제어 서버와 제공자 네트워크의 내부 인스턴스 호스트 간 통신의 경우에서와 같이, 적어도 일부 구현에서는 보안 네트워킹 프로토콜이 사용될 수 있다. 일부 구현에서는 터널링 프로토콜이 커맨드 통신기에 의해 사용될 수 있거나, 또는 프록시가 제어 서버와 인스턴스 호스트 플랫폼 간 통신을 중계하도록 사용될 수 있다. 적어도 일부 실시예에 있어서, 터널링 또는 다른 유사한 기술은 제어 서버가 전형적으로는 방화벽과 같은 네트워크 보안 장벽에 의해 외부 트래픽으로부터 보호되는 제3자 플랫폼과 통신 가능하게 하도록 사용될 수 있다.

적어도 일부 실시예에 있어서, 제공자 네트워크는 그 인스턴스 호스트를 사용하여 자원 인스턴스 유형 세트를 지원할 수 있다 - "소형", "중형" 및 "대형" 인스턴스는, 각각의 유형에 의해 지원되는 자격 및 특징의 각각의 정의로, 가상화된 컴퓨팅 자원에 대해 지원될 수 있다. 제3자 플랫폼은 또한 일부 경우에서는 이들 동일 유형의 인스턴스를 지원할 수 있고, 그로써 제공자 네트워크의 기반구조 내로 제3자 플랫폼의 상당한 무결절 통합을 가능하게 한다. 일부 실시예에 있어서, 제3자는 그 자신의 인스턴스 유형을 정의하도록 허용될 수 있다 - 예를 들어, 기저 하드웨어 또는 소프트웨어가 제공자 네트워크의 정의된 인스턴스 유형과 완전히 호환가능하지는 않기 때문이거나, 제3자가 제공자 네트워크에 의해 제공된 인스턴스 유형과 그들 제공물을 차별화하기를 바라기 때문이거나, 또는 어떠한 다른 이유 때문이다. 제공자 네트워크는 클라이언트가 그러한 실시예에서 획득할 수 있는 모든 여러 다른 인스턴스 유형을 나타내는 클라이언트-대면 인터페이스(예를 들어, 웹 사이트 또는 애플리케이션 프로그래밍 인터페이스(API))를 구현할 수 있다 - 예를 들어, 인터페이스는 제공자 네트워크의 인스턴스 유형은 물론, 제공자 네트워크의 제어 서버를 사용하여 다양한 제3자 파트너에 의해 지원되는 부가적 인스턴스 유형도 나타낼 수 있다. 일부 실시예에 있어서, 플랫폼 승인 요청 또는 제3자로부터 제공자 네트워크로의 소정 부가적 통신은 제3자가 지원하기를 바라는 인스턴스 유형의 표시를 포함할 수 있다. 일 실시예에 있어서, 제3자 제공자는 지원되는 인스턴스 유형 정의에 따라 후보 플랫폼의 자격을 체크하도록 테스트 제안(또는 실제 테스트)을 제공할 수 있다.

제공자 네트워크 밖의 다양한 데이터 센터에 위치하는 플랫폼에 부응할 수 있을 수 있는, 위에서 설명된 융통성 있는 제어 플레인 아키텍처는 또한, 일부 실시예에서는, 클라이언트가 그들 자신의 충분히 이용되지 않는 하드웨어 플랫폼을 배치하거나, 잘-이용되는 클라이언트-측 플랫폼에 대해서도 제어 플레인 아키텍처를 이용할 기회를 제공할 수 있다. 예를 들어, 일 실시예에 있어서는, 마치 제3자가 인스턴스 호스팅에 대해 그들 플랫폼이 승인되게 할 수 있는 것처럼, 제공자 네트워크의 클라이언트는 클라이언트의 네트워크 또는 데이터 센터 내에 상주하는 플랫폼이 승인되게 할 수 있다. 클라이언트의 플랫폼이 인스턴스 배치에 대해 승인되고 나면, 제공자 네트워크 내 제어 서버는 그 플랫폼 상에 인스턴스를 구성하도록 사용될 수 있다.

예시적 시스템 환경

도 1은, 적어도 일부 실시예에 따른, 일례의 시스템 환경을 예시하고 있다. 도시된 바와 같이, 시스템은 (풀(120A, 120B, 120C)과 같은) 여러 제어 서버 풀(120) 및 (풀(110A, 110B, 110C)과 같은) 인스턴스 호스트 풀(110)을 포함하는 제공자 네트워크(102)를 포함할 수 있다. 제어 서버 풀(120)은 (클라이언트(150A 또는 150B)와 같은) 클라이언트(150)로부터 제어 서버에 의해 수신된 인스턴스 구성 요청(170)에 응답하여, 예를 들어, 인스턴스 풀(110)의 인스턴스 호스트에 제출된 커맨드를 통하여, 원격으로 인스턴스 호스트 상의 구성 작업을 수행하도록 구성된 복수의 하드웨어 및/또는 소프트웨어 제어 서버를 포함할 수 있다. 어느 유형의 자원 인스턴스가 소정 인스턴스 호스트 상에서 구현되어야 하는지, 인스턴스 상태 정보, 및 인스턴스를 실체화하는데 사용될 구성 정의/레이아웃의 결정과 관련된 프로세싱과 같은 대다수의 구성-관련 프로세싱은, 예를 들어, 도 2에 관하여 아래에 더 상세히 설명되는 다양한 컴포넌트를 사용하여 제어 서버 상에서 수행될 수 있다. 풀(120)의 제어 서버는 풀(110)의 인스턴스 호스트에서의 실행을 위해 비교적 저-레벨(예를 들어, 하이퍼바이저-레벨 또는 운영 체제 레벨 커맨드)의 시퀀스를 송신하며, 거기서 전형적으로는 단명 원격 커맨드 실행기(RCE)가 요청된 커맨드 또는 커맨드 시퀀스를 실행하고, 반환 값을 제공하고, 그 후 퇴출 또는 종료하도록 실체화될 수 있다. 일부 실시예에 있어서, 커맨드는, 커맨드 요청이 어떤 일로 손실 또는 무시되든지, 또는 반환 값이 손실 또는 무시되든지 하면, 전형적으로는 커맨드가 부정적 결과 없이 재발행될 수 있도록, 적어도 일부 멱등 작업을 지원하는 커맨드 프로토콜에 따라 포매팅될 수 있다.

각각의 인스턴스 호스트 풀(110A)은 묘사된 실시예에서는, 가상화된 컴퓨팅 서버, 가상화된 저장 자원 및/또는 가상화된 네트워크 자원과 같은, 다양한 유형의 하나 이상의 자원 인스턴스에 각각 부응할 수 있는 여러 인스턴스 호스트 플랫폼을 포함할 수 있다. 소정 풀 내에 포함된 여러 인스턴스 호스트는 기반구조 제약(예를 들어, 제공자 네트워크의 데이터 센터에서의 공간, 대역폭, 또는 전력 한계), 또는 다양한 유형의 자원 인스턴스에 대한 수요와 같은 다양한 인자에 기반하여 결정될 수 있다. 여러 다른 인스턴스 유형(예를 들어, "대형" 대 "소형" 가상 컴퓨팅 인스턴스)이 지원되고, 그리고/또는 (장기간 예약 대 요구에 따라 대 "현물" 가격책정과 같이) 여러 다른 가격책정 정책이 지원되는 일부 실시예에 있어서, 일부 인스턴스 호스트 풀은 특정 인스턴스 유형의 인스턴스, 또는 특정 가격책정 정책에 따라 가격책정된 인스턴스를 제공하는데 전용일 수 있다. 특정 클라이언트(150)의 인스턴스가 론칭되게 되는 특정 인스턴스 호스트는 인근성(예를 들어, 클라이언트의 구내 또는 네트워크에 대한, 또는 클라이언트에 의해 사용되고 있는 다른 인스턴스 호스트에 대한 물리적 근접도), 클라이언트에 의해 요청된 인스턴스 유형, 클라이언트에 의해 요청된 가격책정 정책, 또는 제공자 네트워크 내 현재 또는 예측된 자원 사용 동향(예를 들어, 최근 시간 기간에 걸쳐 더 낮은 레벨의 CPU 또는 네트워크 이용을 가졌던 인스턴스 호스트는 매우 바빴던 인스턴스 호스트보다 선호될 수 있음)과 같은 다양한 인자에 기반하여 선택될 수 있다.

도시된 바와 같이, 제공자 네트워크의 인스턴스 호스트 풀(110) 및 제어 서버 풀(120)은 묘사된 실시예에서는 다양한 가용성 컨테이너(105) 간에 분산될 수 있다 - 예를 들어, 가용성 컨테이너(105A)는 인스턴스 호스트 풀(110A) 및 제어 서버 풀(120A)을 포함하고, 가용성 컨테이너(105B)는 인스턴스 호스트 풀(110B) 및 제어 서버 풀(120B)을 포함하고, 가용성 컨테이너(105C)는 인스턴스 호스트 풀(110C)을 포함하는 한편, 가용성 컨테이너(105D)는 제어 서버 풀(120C)을 포함한다. 각각의 가용성 컨테이너(105)는, 하나의 가용성 컨테이너(105)에서 경험되는 (전력 정전과 같은) 실패가 다른 가용성 컨테이너 내의 실패와 상관될 것으로 예상되지 않을 수 있도록, 다른 컨테이너의 프로파일과는 독립적인 실패 프로파일 또는 가용성 프로파일을 갖도록 엔지니어링될 수 있다. (160A, 160B, 160C)와 같은 양날 화살표(160)는 묘사된 실시예에서는 (풀(120)에서의 제어 서버로부터 보내진) 구성 커맨드 및 (풀(110)에서의 인스턴스 호스트로부터 보내진) 구성 커맨드 결과와 관련된 상호작용을 나타낸다. 화살표(160C)에 의해 도시된 바와 같이, ((105B)와 같은) 소정 가용성 컨테이너 내 제어 서버는 그들 자신의 가용성 컨테이너 내뿐만 아니라, ((105C)와 같은) 다른 가용성 컨테이너 내 인스턴스 호스트의 구성도 관리할 수 있다. 다양한 실시예에 있어서, 일부 가용성 컨테이너(예를 들어, (105A) 및 (105B))는 인스턴스 호스트 풀과 더불어 제어 서버 풀도 포함할 수 있고, 다른 것(예를 들어, (105D))은 인스턴스 호스트 풀을 포함하지 않을 수 있고, 일부(예를 들어, (105C))는 제어 서버 풀을 포함하지 않을 수 있다. 소정 클라이언트는 일부 실시예에 있어서 인스턴스 구성 요청을 다양한 제어 서버에 제출할 수 있다 - 예를 들어, 클라이언트(150B)는 풀(120C)뿐만 아니라 풀(120B)의 제어 서버에도 요청(170B)을 제출할 수 있다. 소정 인스턴스 호스트 풀(110)은 묘사된 실시예에서는, 풀(120B, 120C)의 제어 서버에 의해 관리되는 인스턴스 호스트 풀(110C)의 경우에서와 같이, 하나 이상의 제어 서버 풀로부터 관리될 수 있다.

도 1은 또한 제공자 네트워크(102) 외부의 제3자 플랫폼의 구성에 대한 지원을 예시하고 있다. 묘사된 실시예에 있어서, 제공자 네트워크의 풀(120A)에서의 제어 서버는 제3자 네트워크(125A)의 승인된 인스턴스 호스트 후보 플랫폼(135A)의 자원 인스턴스의 구성을 원격 제어할 수 있는 한편, 풀(120B 또는 120C)에서의 제어 서버는 제3자 네트워크(125B)의 승인된 인스턴스 호스트 후보 플랫폼(135B)에서의 인스턴스를 구성할 수 있을 수 있다. 소정 제어 서버는 묘사된 실시예에서는 제공자 네트워크의 자신의 인스턴스 호스트뿐만 아니라 제3자 플랫폼도 관리할 수 있을 수 있다. 네트워크(125A 또는 125B)의 운용자와 같은 제3자 제공자는, 일부 실시예에서는, 그들이 인스턴스 호스팅에 대해 승인되게 하기를 바라는 후보 플랫폼을 나타내는 플랫폼 승인 요청을 제공자 네트워크(102) 내의 제어 서버 컴포넌트에 제출할 수 있다. 자격 결정 테스트는, 예를 들어, 후보 플랫폼이 인스턴스를 구성하는데 필요로 되는 RCE 기능성을 지원할 수 있는지, 플랫폼이 소망의 성능, 가용성, 신뢰도 레벨을 지원할 수 있는지, 그리고/또는 플랫폼이 소망의 소프트웨어 스택을 지원할 수 있는지 결정하도록 제어 서버로부터 후보 플랫폼에서 개시될 수 있다. 플랫폼이 승인되고 나면, 그것은 인스턴스 호스트 풀 내에(예를 들어, 특별 제3자 인스턴스 호스트 풀 내에 또는 제공자 네트워크 내에 이미 수립된 인스턴스 호스트 풀 중 하나 내에) 포함되고, 제공자 네트워크의 어느 다른 인스턴스 호스트와 유사한 방식으로 다뤄질 수 있다. 일부 실시예에 있어서, 제3자 네트워크 운용자는 제공자 네트워크에 의해 본디 지원되는 인스턴스 유형과는 다른 그들 자신의 인스턴스 유형을 정의할 수 있을 수 있고; 다른 실시예에 있어서, 제3자 제공자는 제공자 네트워크가 지원하는 동일한 유형의 인스턴스를 지원하도록 요구될 수 있다. 앞서 언급된 바와 같이, 예를 들어, 제공자 네트워크의 전형적 내부 인스턴스 호스트 소프트웨어 스택의 골자 버전을 갖는 접속 거점 위치(도 1에는 도시되지 않음)의 플랫폼은 일부 실시예에서는 후보 플랫폼(135)이 사용되는 방식과 유사한 방식으로 자원 인스턴스를 호스팅하도록 사용될 수 있다.

구성-관련 작업의 다량이 인스턴스 호스트에서라기보다는 전용 제어 서버에서 실행되는 컴포넌트에 의해 행해지는 모듈식 제어 아키텍처를 구현하는 결과로서, 묘사된 실시예에서는 구성-관련 오버헤드가 인스턴스 호스트 자체에서 최소화될 수 있다. 예를 들어, 제어 서버로부터 HTTPS를 통하여 저-레벨 커맨드를 수신하고 전형적으로는 단명 CGI 프로세스를 실체화하여 커맨드, 또는 인스턴스 호스트에서 특정 유형의 드문 이벤트가 일어날 때 제어 서버에 통지할 수 있는 이벤트 리스너(event listener)를 실행하도록 구성된 최소한의 웹 서버와 같이, 인스턴스 호스트에서의 인스턴스 구성을 지원하는데 경량의, 무상태 컴포넌트만이 요구될 뿐일 수 있다. 각각의 제어 서버는 일부 실시예에서는 다수의 인스턴스 호스트에 대한 작업을 수행할 수 있을 수 있다. 소정 풀(120) 내에 확립되는 전용 제어 서버의 수는, 여러 다른 실시예에 있어서, 대규모 정전에 응답하기 위해 복구 구성 작업이 수행되어야 할 수 있는 레이트와 같은, 다양한 인자에 기반하여 선택될 수 있다. 클라이언트 인스턴스 구성 요청(및 요청에 대한 응답)은 도 1에서 화살표(170)에 의해 나타나 있다(예를 들어, 클라이언트(150A)와 풀(120A) 간 화살표(170A), 클라이언트(150B)와 풀(120B) 간 (170B), 또는 클라이언트(150B)와 풀(120C) 간 (170C)). 각종 기술 중 어느 것이라도 소정 클라이언트 요청에 응답하게 되는 풀(120)의 특정 제어 서버 또는 서버들을 선택하는데 사용될 수 있다 - 예를 들어, 제어 서버는 부하 균형 메커니즘을 사용하여, 또는 클라이언트 친화도(예를 들어, 동일한 클라이언트 IP 주소로부터의 요청은 동일한 제어 서버에 의해 다루어질 수 있음), 또는 랜덤으로 선택될 수 있다. 다양한 제어 서버의 컴포넌트의 기능성, 및 클라이언트와, 제어 서버와, 인스턴스 호스트 플랫폼 간 상호작용에 관한 부가적 상세가 아래에 제공된다.

제어 서버 및 인스턴스 호스트 컴포넌트

도 2는, 적어도 일부 실시예에 따른, 인스턴스 호스트 플랫폼의 원격 구성을 위해 구성된 제어 서버의 컴포넌트의 예를 도시하고 있다. 예시된 컴포넌트와, 컴포넌트가 구현되는 하드웨어/소프트웨어 서버 간 매핑은 시간에 걸쳐 그리고 여러 다른 실시예에서 달라질 수 있다. 예를 들어, 일부 구현에 있어서는, 예시된 컴포넌트의 각각을 단일 컴퓨팅 디바이스 상에 실체화하는 것이 가능할 수 있는 한편, 다른 실시예에 있어서는, 하나 이상의 컴퓨팅 디바이스가 특정 컴포넌트의 노드 또는 인스턴스에 사용될 수 있다(예를 들어, 다수의 작업 흐름 관리기 노드가 실체화될 수 있으며, 하나 이상의 작업 흐름 관리기 노드가 소정 컴퓨팅 디바이스에 편입된다).

클라이언트 및 제3자 상호작용 관리기 컴포넌트(235)는 묘사된 실시예에서는, 인스턴스 론칭 또는 구성 요청, 또는 제3자 또는 클라이언트-소유 플랫폼에 대한 승인 요청과 같은, 인커밍 클라이언트 요청(201) 및/또는 제3자 요청(202)을 수신할 책임이 있을 수 있다. 일부 실시예에 있어서, (웹 페이지, 웹 사이트, API, 그래픽 사용자 인터페이스 또는 커맨드-라인 툴과 같은) 하나 이상의 프로그램식 인터페이스는 클라이언트 상호작용 및/또는 제3자 상호작용을 지원하도록 구현될 수 있다. 인스턴스 상태 관리기(210)는 묘사된 실시예에서는, 정전 또는 예상치 못한 인스턴스 셧다운에 응답하도록 그리고/또는 새로운 인스턴스 호스트를 등록하도록, 클라이언트 또는 제3자 요청에 응답하여 구성 작업을 편성할 책임이 있을 수 있다. 예를 들어, 클라이언트로부터의 인스턴스 론칭 요청에 응답하여, 인스턴스 상태 및 복구 관리기(210)는 어느 인스턴스 호스트가 론칭에 사용되게 되는지 정확히 (용량 관리기(205)의 도움으로) 식별할 수 있고, 그 후, 선택된 인스턴스 호스트에서의 궁극적 실행을 위해 하위-레벨 커맨드로 번역될 론칭 커맨드를 작업 흐름 관리기(225)에 발행할 수 있다.

용량 관리기(205)는 묘사된 실시예에서는 인스턴스 호스트 풀(110)이 예상된 수요에 대해 충분한 사이즈로 됨을 보장하도록, 그리고/또는 필요하다면 풀 간 자원을 이동시키도록 구성될 수 있다. 자격 테스터(215)는 제3자 후보 플랫폼을 승인하는 그리고/또는 제공자 네트워크 내 인스턴스 호스트가 충분히 프로비저닝되는지 검증하는 결정을 돕기 위한 (성능 테스트, 소프트웨어 스택 확인 등과 같은) 테스트를 실행하도록 구성될 수 있다. 계량/과금 관리기(230)는, 예를 들어 네트워크 요청 계수, 측정된 트래픽, I/O 계수, CPU 이용 등과 같은 메트릭에 기반하여, 소정 클라이언트가, 그 클라이언트에 대해 시행되고 있는 특정 가격책정 플랜에 따라, 과금 기간에 걸쳐 특정 자원 인스턴스를 사용한 것에 대해 얼마나 많이 청구받게 되는지 결정하도록 구성될 수 있다.

구성 정의기(220)는 묘사된 실시예에서는, 론칭될 특정 인스턴스 유형에 대해, 특정 인스턴스 호스트에서 구현될 특정 구성 레이아웃(예를 들어, 수립될 소프트웨어 디바이스 및 다양한 파일 시스템의 이름, 다양한 튜닝가능한 설정에 대한 파라미터 값 등)의 상세를 발생시킬 책임이 있을 수 있다. 작업 흐름 관리기(225)는 인스턴스 상태 관리기(210)에 의해 발행된 고-레벨 커맨드, 및 구성 정의기(220)로부터의 구성 레이아웃 상세를 수신하고, 커맨드를 하나 이상의 하위-레벨 커맨드를 포함하는 작업 흐름으로 번역할 책임이 있을 수 있다. 그 후 작업 흐름 관리기(225)는, RCE를 통한 실행을 위해 (예를 들어, HTTPS를 통하여) 대응하는 커맨드 시퀀스(281)(예를 들어, JSON 또는 XML로 포매팅됨)를 선택된 인스턴스 호스트에 송신할 수 있는, 커맨드 통신기(240)에 작업 흐름 커맨드를 이관할 수 있다. 일부 실시예에 있어서, 로킹 서비스(275)는 인스턴스 호스트 구성이 상충하거나 중첩하는 수정 요청에 기인하여 변질되게 되지 않음을 보장하도록 작업 흐름 관리기(225)에 의해(또는 도 2에 예시된 다른 컴포넌트에 의해) 사용될 수 있다 - 예를 들어, 인스턴스 호스트 상의 배타적 로크가 특정 유형의 구성 변경이 허용되기 전에 요구될 수 있다. 로킹 서비스(275)는 일부 실시예에서는 제어 서버의 컴포넌트가 아닐 수 있다, 예를 들어, 제공자 네트워크에서 다른 목적에 사용되는 기존 로킹 서비스가 사용될 수 있다. 제어 서버는 또한 일부 실시예에서는 인스턴스 호스트에서 (자원 인스턴스에 영향을 미칠 수 있는 예상치 못한 셧다운, 하드웨어 또는 소프트웨어 오류 또는 실패와 같은) 특정 유형의 이벤트가 일어날 때 통지를 수신하도록 구성된 이벤트 리스너(245)를 포함할 수 있다. 이벤트 리스너(245)는 일부 실시예에서는 이벤트에 대한 정보를 인스턴스 상태 관리기에 송신할 수 있으며, 그러면 그것들을 적합하게 해석하여, 예를 들어, 인스턴스 상태 정보가 업데이트될 필요가 있는지 결정할 수 있다. 적어도 일부 실시예에 있어서, 커맨드 통신기(240)는 또한, 예를 들어, 계량 관리기(230)를 대신하여 인스턴스 호스트로부터 성능 또는 다른 메트릭을 수집하도록 인스턴스 호스트에 저레벨 커맨드를 제출할 수 있다; 그러한 실시예에 있어서, 커맨드 통신기에 의해 발행된 커맨드 세트는 구성 변경을 구현할 수정 커맨드뿐만 아니라 메트릭 수집을 위한 비-수정 커맨드도 포함할 수 있다.

그 이름에 의해 나타나 있는 바와 같이, 인스턴스 상태 관리기(210)는 다양한 자원 인스턴스의 상태를 알고 있을 수 있는 한편, 작업 흐름 관리기(225), 커맨드 통신기(240) 및/또는 이벤트 리스너(245)와 같은 하위-레벨 컴포넌트는, 적어도 인스턴스 상태에 대한 지식 또는 그에 대한 상세가 묘사된 실시예에서는 그들 기능을 수행하도록 그러한 하위-레벨 컴포넌트에 의해 필요로 되지 않을 수 있다는 의미에서, 무상태일 수 있음을 유념한다. 인스턴스 상태에 대한 정보를 한정된 컴포넌트 세트로 제한함으로써, 작업 흐름 관리기 및 커맨드 통신기와 같은 무상태 컴포넌트의 구현이 그러한 실시예에서 실질적으로 단순화될 수 있다. 또한 도 2의 이중 화살표는 예시된 다양한 제어 서버 컴포넌트 간에 일어날 수 있는 상호작용의 유형 중 일부의 예를 나타내고 있기는 하지만, 상호작용의 부가적 유형이 또한 적어도 일부 실시예에서는 컴포넌트 간에 지원될 수 있음을 유념한다 - 예를 들어, 컴포넌트 중 어느 하나는 일부 실시예에서는 어느 다른 컴포넌트와 통신할 수 있을 수 있다.

도 3은, 적어도 일부 실시예에 따른, (제공자 네트워크 운용자에 의해 소유된 플랫폼은 물론 제3자 플랫폼도 포함할 수 있는) 인스턴스 호스트 플랫폼의 컴포넌트의 예를 도시하고 있다. 도시된 바와 같이, 인스턴스 호스트 플랫폼은 제어 서버의 커맨드 통신기(240)에 의해 발생된 커맨드 시퀀스를 수신하도록 구성된, 웹 서버와 같은, 커맨드 수신기 컴포넌트(305)를 포함할 수 있다. 인스턴스 호스트는 또한 호스트의 베어 하드웨어에 더하여 가상화 기능성을 제공하는 하이퍼바이저(317)를 포함할 수 있다. 하이퍼바이저(317)는 묘사된 실시예에서는 인스턴스 호스트 플랫폼의 자원을 복수의 도메인으로 조직할 수 있으며, (소위 도메인 제로라고 할 수 있는) 하나의 도메인은 집행에 사용되고 다른 도메인은 자원 인스턴스에 사용된다. 운영 체제(315)의 인스턴스는 도메인 제로 내에 수립될 수 있다. 각각의 수신된 커맨드에 또는 커맨드 시퀀스에 응답하여, 커맨드 수신기(305)는, (330A) 또는 (330B)와 같은, 원격 커맨드 실행기(RCE)(330)를 실체화할 수 있다. 그 후 RCE(330)는 작업, 예를 들어, 하이퍼바이저(317)에 또는 도메인-제로 운영 체제(315)에 보내지는 작업에 대한 요청을 발행할 수 있다. 일부 실시예에 있어서, RCE(330)는 도메인-제로 운영 체제(315) 또는 하이퍼바이저(317)의 컴포넌트로서 구현되거나 생각될 수 있다. 그 작업 요청(들)을 발행하고 (예를 들어, 반환 코드, 오류 출력 또는 표준 출력을 포함하는) 결과를 수신한 후에, 소정 RCE는 도시된 실시예에서는 종료 또는 퇴출할 수 있다. RCE는 일부 구현에서는 저절로 퇴출 또는 종료할 수 있는 한편, 다른 구현에 있어서 RCE는 (예를 들어, "킬" 신호 또는 어떤 다른 메커니즘을 사용하여) 커맨드 수신기(305)에 의해 종료될 수 있다. 다른 실시예에 있어서, RCE는 그저 소정 작업을 개시하는데 필요로 되는 것보다 더 긴 시간 기간 동안 여전히 존재하고 있을 수 있다 - 예를 들어, RCE의 풀이 유지되고 있을 수 있다. 적어도 하나의 구현에 있어서, 각각의 RCE는 실행의 CGI 프로세스 또는 스레드를 표현할 수 있다. 일부 실시예에 있어서, RCE는 장기-실행 작업을 시작하고 퇴출할 수 있고, (RCE가 퇴출한 후에 계속될 수 있는) 장기-실행 작업의 결과는 커맨드 수신기에 의해 비동기식으로 획득될 수 있다.

RCE에 의해 개시된 작업은 (작업이 성공하면) 궁극적으로는 작업 흐름 관리기(225)로부터의 구성 커맨드의 구현의 결과를 초래하여, 예를 들어 컴퓨팅 자원(350A 또는 350B), 저장 자원(360A 또는 360B) 또는 네트워크 자원(370A 또는 370B)과 같은 다양한 가상화된 자원 인스턴스(345)의 실체화(또는 그 구성 수정)의 결과를 초래할 수 있다. RCE 및 커맨드 수신기는 또한 묘사된 실시예에 있어서, 그들이 소정 시간에 특정 인스턴스가 어떤 상태에 있는지 모를 수 있다는 의미에서, 인스턴스 상태에 관하여 무상태일 수 있다. 인스턴스 호스트가 하이퍼바이저에 의해 도메인으로 조직되는 일부 실시예에 있어서, 각각의 가상 자원 인스턴스는 각각의 도메인에 대응할 수 있다. 인스턴스 호스트는 또한 묘사된 실시예에서는 이벤트 디스패처(310)를 포함할 수 있다. 이벤트 디스패처는 하나 이상의 이벤트 모니터(예를 들어, 도메인-제로 운영 체제(315) 또는 하이퍼바이저(317) 내에 구현되는 모니터)에 가입할 수 있다. 이벤트 모니터(들)는 특정 유형의 이벤트가 인스턴스 호스트에서 일어나면 그리고 그때 이벤트 디스패처에 통지할 수 있고, 이벤트 디스패처는 다양한 실시예에 있어서, 커맨드 수신기를 통하여든 또는 직접이든, 이벤트에 대해 제어 서버에서의 이벤트 리스너(245)에 통지할 수 있다.

예시적 요청/응답 흐름

도 4는, 적어도 일부 실시예에 따른, 클라이언트와, 제어 서버와, 인스턴스 호스트 플랫폼 간 상호작용의 예를 도시하고 있다. 도시된 바와 같이, 클라이언트(150)는 묘사된 실시예에서는 인스턴스를 론칭 또는 종료하라는 요청과 같은 인스턴스 구성 요청(440)을 제어 서버(410)에 제출할 수 있다. 클라이언트 요청은 일부 실시예에서는 제어 서버(410)의 상호작용 관리기 컴포넌트(235)에 의해 구현된 API 또는 웹 페이지와 같은 프로그램식 인터페이스를 통하여 송신될 수 있다. (인스턴스 상태 관리기(210), 작업 흐름 관리기(225) 및/또는 커맨드 통신기(240)와 같은) 제어 서버 계층의 여러 컴포넌트는 인스턴스 구성 요청을 인스턴스 호스트 플랫폼(301)에 송신되는 저-레벨 커맨드 시퀀스(450)로 번역하도록 협력할 수 있다.

저-레벨 커맨드는 묘사된 실시예에서는 인스턴스 호스트 플랫폼(301)에서 RCE 작업으로 번역될 수 있다. 도시된 바와 같이, 예를 들어, RCE는 새로운 프로세스 또는 스레드를 낳음으로써 실체화될 수 있고(도 4의 구성요소(461)), RCE는 하나 이상의 작업을 발행 또는 수행할 수 있고(구성요소(462)), 그 후 퇴출 또는 종료할 수 있다(구성요소(463)). 커맨드의 결과(470)는 제어 서버(410)에 다시 보내질 수 있다. 결과(470)에 기반하여, 인스턴스 구성 응답(480)은 요청 클라이언트(150)에 다시 보내질 수 있다. 커맨드 시퀀스(450) 및/또는 결과(470)는, 다양한 실시예에 있어서, HTTPS와 같은 어떠한 적합한 보안 네트워킹 프로토콜이라도 사용하여 송신될 수 있다. 커맨드 및 결과는 일부 실시예에서는 JSON 또는 XML의 변종에 따라 포매팅될 수 있다. 사용되는 커맨드 프로토콜은 다양한 실시예에서는 적어도 일부 멱등 작업을 지원할 수 있다. 일부 실시예에 있어서, 커맨드 프로토콜은 성능 메트릭 수집, 로그 레코드 수집 등을 포함하는 다양한 다른 커맨드 유형 및 기능을 지원할 수 있다 - 예를 들어, 인스턴스 호스트 플랫폼(301)에서 하나 이상의 자원 인스턴스를 소유하는 클라이언트에 대한 과금량을 결정하기 위해, 클라이언트가 얼마나 많은 다양한 종류의 작업을 인스턴스에 발행하였는지, 또는 클라이언트가 얼마나 많은 네트워크 트래픽을 인스턴스 호스트 플랫폼에서 발생시켰는지 결정하도록 제어 서버(410)에 의해 저-레벨 커맨드가 발행될 수 있다. 일부 구현에서는, RCE 이외의 메커니즘이 메트릭 또는 로그 레코드 수집과 같은 특정 유형의 제어 서버-요청된 작업에 사용될 수 있는 한편, 다른 구현에서는 RCE가 구성 수정에도 그리고 메트릭/로그 수집에도 사용될 수 있다.

도 5는, 적어도 일부 실시예에 따른, 제어 서버에서 작업 흐름 관리기 노드로부터 시작하는 커맨드 흐름의 일례를 도시하고 있다. 도시된 예는 인스턴스 호스트에서 소프트웨어 RAID(redundant array of independent disks) 디바이스의 생성을 다루며, 새로운 가상 컴퓨팅 인스턴스를 수립하는데 요구되는 구성의 일부를 표현할 수 있다. 그 예는 여기에서는, 구체적 예를 사용하여, 인스턴스 호스트 및 제어 서버의 여러 다른 컴포넌트가 일 실시예에 있어서 작업할 수 있는 커맨드 상세의 레벨을 예시하도록 제공된다; 다양한 실시예에 있어서, RAID 디바이스와 무관한 많은 다른 유형의 구성 작업이 유사한 입도의 커맨드를 사용하여 구현될 수 있다. 경과된 시간은 도 5의 상부로부터 저부로 증가한다.

묘사된 실시예에 있어서 작업 흐름 관리기(225)는, 예를 들어, 새로운 컴퓨팅 인스턴스에 대한 클라이언트의 요청에 응답하여 인스턴스 상태 관리기(210)로부터 컴퓨팅 인스턴스에 대한 루트 파일 시스템을 수립하라는 고-레벨 요청을 수신할 수 있다(도 5의 구성요소(502)). 작업 흐름 관리기(225)는, (예를 들어, "md2", "sda3" 등과 같은 소프트웨어 디바이스 이름에 대한) 특정된 파라미터 값을 갖는 RAID1 디바이스의 생성을 요청하는, 블록 디바이스 서브시스템에 보내지는 커맨드 "block.raid1.create"를 커맨드 컨트롤러(240)에 제출할 수 있다(구성요소(507)). 작업 흐름 관리기(225)는 생성될 새로운 인스턴스에 대해 구성 정의기(220)로부터 획득된 구성 정의 또는 레이아웃에 적어도 부분적으로 기반하여 파라미터 값을 결정하였을 수 있다.

"block.raid1.create" 커맨드에 응답하여, 커맨드 통신기(240)는 "RCE.exec" 커맨드를 인스턴스 호스트의 커맨드 수신기(305)에 제출할 수 있다(구성요소(512)). 순차로 커맨드 수신기(305)는 요청된 작업, 이 경우에서는 도메인-제로 운영 체제 계층에서의 "mdadm"(다수 디바이스 집행) 커맨드의 인보크를 실행하는 RCE 프로세스 또는 스레드를 실체화할 수 있다(구성요소(515)). RCE 프로세스 또는 스레드는 인보크로부터 반환 값 또는 퇴출 코드(구성요소(518)에서 "$?" 값)을, 인보크된 작업으로부터 표준 출력(구성요소(518)에서 "$1" 값)을, 그리고 인보크된 작업으로부터 표준 오류(구성요소(518)에서 "$2" 값)를 획득할 수 있다. 이들 결과는 커맨드 수신기에 의해 커맨드 통신기(240)에 다시 송신될 수 있다(구성요소(521)). 순차로 커맨드 컨트롤러(240)는 결과를 그것이 수신하였던 "block.raid1.create" 커맨드에 대한 반환 값(예를 들어, 이 예에서는 성공을 나타내는 "참")으로 번역하고, 반환 값을 다시 작업 흐름 관리기(225)에까지 송신할 수 있다(구성요소(524)). 유사하게 작업 흐름 관리기(225)는 그것이 수신하였던 "setup-instance-root-fs" 커맨드에 대한 반환 값을 결정하고, 이러한 반환 값(이 예에서는 역시 "참")을 인스턴스 상태 관리기에 제공할 수 있다(구성요소(527)). 상호작용이 도 5에 예시되어 있는 다양한 컴포넌트는 인스턴스 상태 관리기에 의해 유지되고 있는 인스턴스 상태 정보를 알고 있지 않을 수 있음을 유념한다; 대신에, 묘사된 계층의 각각은 단순히 필요에 따라 하위 레벨 작업을 수행할 수 있고, 그 누적된 결과는 (예를 들어, 인스턴스의 론칭, 재구성 또는 종료로의) 인스턴스 상태에서의 변경에 기여할 수 있다.

일부 실시예에 있어서, 새로운 인스턴스 호스트 플랫폼이 제공자 네트워크의 데이터 센터에 부가될 때, 궁극적으로는 호스트 상에 배치되게 되는 자원 인스턴스의 특정 유형 및 수에 관한 결정이 이루어져야 할 수 있다. 그러한 실시예에 있어서 새로운 인스턴스 호스트는 인스턴스를 호스팅하도록 "등록"한다고 할 수 있고, 등록의 결과는 하나 이상의 인스턴스 유형의 "인스턴스 슬롯"(호스트 상에 론칭될 수 있는 잠재적 인스턴스의 논리적 표현)의 수의 결정을 포함할 수 있다. 도 6은, 적어도 일부 실시예에 따른, 인스턴스 호스트 플랫폼의 등록과 연관된 작업의 예를 도시하고 있다. 도 5의 경우에서와 같이, 경과된 시간은 도 6의 상부로부터 저부로 증가한다. 구성요소(602)에 도시된 바와 같이, 인스턴스 호스트는 인스턴스 상태 관리기(210)에 등록 요청을 송신할 수 있다(또는 등록 요청은 인스턴스 호스트를 대신하여 송신될 수 있다). 일부 실시예에 있어서, 인스턴스 상태 관리기와는 별개의 등록 관리기는 등록 프로세스를 편성하도록 사용될 수 있다. 인스턴스 상태 관리기(210)는 구성요소(607)에 의해 나타낸 바와 같이, 등록 요청에 응답하여, 인스턴스 슬롯 수립 요청을 용량 관리기(205)에 송신할 수 있다. 인스턴스 슬롯 수립 요청은 질문 "얼마나 많은 인스턴스 슬롯, 및 그 어떤 인스턴스 유형(들)을 인스턴스 호스트(X)가 지원하여야 하는가"에 대답하라는 요청의 등가를 표현할 수 있다. 용량 관리기(205)는 구성요소(612)에 나타낸 바와 같이, 적어도 부분적으로, 하드웨어 자격 요청을 구성 정의기(220)에 제출함으로써 인스턴스 슬롯 수립 요청에 응답할 수 있다. 적어도 일부 실시예에 있어서, 인스턴스 호스트로서 제공자 네트워크에 의해 취득되었던 컴퓨팅 디바이스의 하드웨어 자격에 대한 정보는 인벤토리 데이터베이스에서 이용가능할 수 있다. 일부 구현에 있어서, 하나 이상의 선호되는 벤더로부터의 랙-기반 서버와 같은 하드웨어 디바이스의 몇몇 "표준" 유형은 제공자 네트워크 내 인스턴스 호스트에 사용될 수 있고, 그래서 등록시에 성능 테스트에 대한 필요성은 없을 수 있다 - 즉, 인벤토리는 인스턴스 호스트의 자격을 결정하기에 충분한 정보를 포함하고 있을 수 있다. 구성 정의기는 인스턴스 호스트의 하드웨어 상세(구성요소(618))를 검색하도록 인벤토리 룩업(구성요소(615))을 수행할 수 있다.

하드웨어 상세에 기반하여, 구성 정의기는 인스턴스 호스트에 대한 실현가능한 인스턴스 구성 세트(구성요소(621))를 포뮬레이팅할 수 있다 - 예를 들어, 구성 정의기는, 제공자 네트워크에서 사용되고 있는 "대형", "중형" 및 "소형" 인스턴스 유형의 정의에 기반하여, 인스턴스 호스트가 M개의 "대형" 컴퓨팅 인스턴스, N개의 "중형" 컴퓨팅 인스턴스 또는 "P"개의 소형 컴퓨팅 인스턴스를 호스팅할 수 있을 수 있다고 결정할 수 있다. 실현가능한 구성의 목록은 용량 관리기(205)에 제공될 수 있다. 그 후 용량 관리기는, 다양한 유형의 인스턴스에 대한 현재 및 예측된 공급 및 수요와 같은 다양한 인자에 기반하여, 인스턴스 호스트에 대한 실현가능한 구성 중 하나를 선택할 수 있다. 일부 실시예에 있어서, 용량 관리기(205)는 또한 새로운 인스턴스 호스트가 놓여 있는 데이터 센터 또는 가용성 컨테이너에서의 현재 자원 이용 레벨 및/또는 가격책정 정책을 고려할 수 있다. 그 후 용량 관리기(205)는 선택된 인스턴스 슬롯 정의(예를 들어, "N개의 대형 인스턴스 슬롯")를 인스턴스 상태 관리기에 송신할 수 있으며(구성요소(624)), 그러면 슬롯 정의를 메타데이터 데이터베이스 내에 저장할 수 있다. 일부 실시예에 있어서, 인스턴스 상태 관리기(210)는 등록 확인응답(구성요소(627))을 인스턴스 호스트에 제공할 수 있으며, 그것이 인스턴스 구성에 대해 준비되어 있음을 인스턴스 호스트에 나타낼 수 있다(구성요소(631)). 다른 실시예에 있어서, 특정 인스턴스 호스트가 이용되게 되는 인스턴스의 수 및 유형을 결정하는 프로세스는 도 6에 도시된 것과는 다를 수 있다.

도 7은, 적어도 일부 실시예에 따른, 자원 인스턴스를 론칭하는 것과 연관된 작업의 예를 도시하고 있다. 경과된 시간은 도 7의 상부로부터 저부로 증가한다. 묘사된 실시예에 있어서, 인스턴스 상태 관리기(210)는 ("소형", "중형" 또는 "대형" 컴퓨팅 인스턴스와 같은) 특정된 인스턴스 유형의 자원 인스턴스를 론칭하라는 요청을 클라이언트(150)로부터 수신할 수 있다. 인스턴스 상태 관리기(210)는 요구되는 인스턴스 유형을 나타내는 (도 7의 구성요소(702)에 도시된 바와 같은) 요청을 용량 관리기(205)에 보낼 수 있다. 용량 관리기(205)는, 인스턴스 호스트 풀(110)의 데이터베이스에 적어도 부분적으로 기반하여, 론칭될 인스턴스에 사용될 특정 IP 주소 및 특정 인스턴스 호스트(301)를 결정하고, 적어도 IP 주소를 인스턴스 상태 관리기에 제공할 수 있다(구성요소(707)). 그 후 인스턴스 상태 관리기(210)는, 인스턴스 유형 및 IP 주소를 나타내는, 특정 구성 파라미터 및 레이아웃 정보에 대한 요청을 구성 정의기에 제출할 수 있다(구성요소(711)). 도시된 실시예에 있어서, 구성 정의기는, 인스턴스 호스트에서의 특정 슬롯 수를 포함하는, 요청된 구성 파라미터를 다시 인스턴스 상태 관리기에 제공할 수 있다(구성요소(714)). 그 후 인스턴스 상태 관리기는, 인스턴스 유형, IP 주소 및 슬롯 수를 나타내는, 론칭 커맨드를 작업 흐름 관리기(225)에 발행할 수 있다(구성요소(721)). 작업 흐름 관리기(225)는 커맨드 통신기(240)로의 커맨드 시퀀스(구성요소(721))를 개시할 수 있으며, 그러면 순차로 하나 이상의 RCE를 사용한 실행을 위해 커맨드 시퀀스를 인스턴스 호스트에 제출할 수 있다(구성요소(724)).

HTTPS 커맨드 요청 및 응답

적어도 일부 실시예에 있어서, 앞서 언급된 바와 같이, 제어 서버와 인스턴스 호스트 간 통신은 HTTPS와 같은 보안 프로토콜을 사용하여 구현될 수 있다. 도 8은, 적어도 일부 실시예에 따른, 제어 서버로부터 인스턴스 호스트에 발행된 커맨드 요청의 엘리먼트의 예를 도시하고 있다. 사용되는 HTTPS 요청 및 응답은 복수의 헤더 및 바디 엘리먼트를 포함할 수 있고, 그 중 몇몇 예만이 도 8에 제공되어 있다. 구성요소(802)에서 도시된 바와 같이, 제어 서버의 커맨드 통신기로부터 인스턴스 호스트의 커맨드 수신기에 보내진 커맨드에 사용된 요청 헤더는, 요청 바디의 무결성이 인스턴스 호스트에서 검증될 수 있도록, 요청의 바디로부터 결정된 다이제스트 또는 해시 값(820)을 포함할 수 있다. 요청 헤더는 "CHANGE-ID", "UUID" 및 "subsystemID"를 포함하는 자원 이름을 갖는, 구성요소(821)에 도시된 바와 같은, HTTP "PUT" 동사 또는 요청 방법을 특정할 수 있다. CHANGE-ID는 커맨드가 발행되는 결과에 이르는 특정 클라이언트 요청을 표현할 수 있다; 소정 클라이언트 요청에 대응하는 CHANGE-ID는 일부 실시예에서는 예를 들어 클라이언트 상호작용 관리기(235)에 의해 할당될 수 있고, 도 4, 도 5 또는 도 7에 도시된 것들과 같이 제어 서버의 여러 다른 컴포넌트 간 커맨드 및 응답 흐름에서 파라미터로서 건네질 수 있다. 묘사된 실시예에 있어서, 범용 고유 식별자 또는 UUID는 특정 커맨드 요청에 대해 발생될 수 있다, 예를 들어, 커맨드 통신기(240)는 그것이 인스턴스 호스트에 보내는 각각의 커맨드 요청에 대한 구별되는 UUID를 발생시킬 수 있다. 묘사된 실시예에 있어서, 서브시스템 식별자는 요청된 작업을 수행하도록 사용되게 되는 도메인-제로 운영 체제 또는 하이퍼바이저 계층에서의 특정 서브시스템을 나타낼 수 있다. 적어도 일부 실시예에 있어서, 로그 레코드는 커맨드 요청이 보내지거나 수신될 때, 또는 대응하는 작업이 인스턴스 호스트에서 실행될 때 발생될 수 있고, 로그 레코드는 CHANGE-ID, UUID 및 subsystemID 중 일부 또는 전부를 포함하여, 더 용이한 디버깅 또는 상관 분석에 대해 가능하게 할 수 있다.

HTTPS 요청의 바디(806)는, 도 8의 묘사된 예에서는 JSON-같은 구문을 사용하여 특정된, 정의된 커맨드 프로토콜에 따라 커맨드 시퀀스를 포함할 수 있다. 일부 실시예에 있어서, 커맨드 프로토콜은 요청 바디(806) 내의 파일 컨텐트의 특정을 가능하게 할 수 있으며, 여기서 파일 컨텐트는 커맨드 중 일부 또는 전부의 파라미터로서 역할할 수 있다. 예를 들어, 도 8에 있어서는, 라벨 @FILE1 및 @FILE2를 갖는 2개의 파일의 컨텐트(예를 들어, URL-인코딩된 16진 형태)가 요청 바디 내에 포함될 수 있다. 도시된 바와 같이, 키워드 "커맨드"는 요청 내에 포함된 커맨드 시퀀스를 나타낼 수 있다. 3개의 커맨드 - "cmd1", "cmd2" 및 "cmd3"가 시퀀스 내에 나타나 있다. "cmd1"은 2개의 파일 파라미터 FILE1 및 FILE2를 가지며, 그 각각의 컨텐트는 @FILE1 및 @FILE2로 나타나 있다. "cmd2"는 어떠한 파일 파라미터도 갖지 않는 한편, "cmd3"는 단일 파일 파라미터 FILE2를 갖는다. 사용 중인 커맨드 프로토콜에 따라, "cmd1"에 대응하는 작업이 RCE를 통하여 인스턴스 호스트에서 실행될 때, @FILE1 및 @FILE2의 컨텐트는 묘사된 실시예에서는 작업에 대한 파라미터로서 제공될 것이다. 유사하게, RCE가 "cmd3"에 대응하는 작업을 수행할 때, @FILE2의 컨텐트가 파라미터로서 제공될 것이다. 묘사된 실시예에 있어서 도 8에 도시된 방식으로 요청 바디 내 파일의 특정은 편의 기능을 표현할 수 있고; 다른 실시예에서는 파일 컨텐트를 포함하고 있는 별개의 메시지와 같이 다른 접근법이 사용될 수 있다. 일부 실시예에 있어서, 커맨드 프로토콜은 커맨드가 그들이 요청 바디 내에 나타나는 순서로 인스턴스 호스트에서 실행되어야 한다고 요구할 수 있다; 다른 실시예에 있어서, 그러한 순서정렬은 요구되지 않을 수 있다. 일 구현에 있어서는, 단일 요청 내 송신될 수 있는 커맨드 수에 대한 최대 한계가 부과될 수 있다. 다른 구현에 있어서는, 커맨드의 수에 대한 어떠한 한계도 부과되지 않을 수 있다. 요청 헤더의 UUID는 일부 실시예에서는, 도 8에 도시된 바와 같이, 바디 내 포함될 수 있다. 다른 실시예에서는, XML과 같이, 도 8에 도시된 JSON-같은 포맷과는 다른 포맷이 커맨드 시퀀스를 나타내도록 사용될 수 있다.

일부 실시예에 있어서, 커맨드 요청에 대한 대답은 시퀀스의 커맨드의 각각에 대해 별개의 구절 또는 엘리먼트를 포함할 수 있다. 일 실시예에 대해 요청 바디(806)의 커맨드 시퀀스 내 제1 커맨드에 대한 응답 구절("cmd1 -F FILE1 FILE2")이 응답 바디(810) 내에 나타나 있다. "command-number" 값(묘사된 예에서는 "1")은 구절이 시퀀스의 제1 커맨드에 대한 것임을 나타낸다. 제1 커맨드의 실행에 의해 산출된 표준 출력은 "stdout" 필드 내에 나타낸다. 표준 오류 출력은 "stderr" 필드 내 나타낸다. 커맨드의 퇴출-코드(예를 들어, 사용되는 운영 체제 또는 하이퍼바이저 컴포넌트에 의해 반환된 값)는 "exit-code" 필드 내에 나타낸다. 부가적으로, 응답 구절은 벽-시계 시간(인스턴스 호스트 상에서 커맨드를 완료하는데 걸린 경과된 시간)은 물론, 마이크로초 또는 밀리초와 같은 단위로 표현되는, 인스턴스 호스트에서 커맨드에 대해 걸린 자원 사용을 나타내는 시스템 및 사용자 CPU 시간에 대한 메트릭도 포함하고 있다. 다양한 실시예에 있어서는, 도 8에 도시된 것들 이외의 포맷이 커맨드에 그리고/또는 커맨드 응답에 사용될 수 있다.

인스턴스 호스트의 원격 구성을 위한 방법

도 9는, 적어도 일부 실시예에 따른, 인스턴스 호스트의 원격 구성을 수행하도록 동작가능한 제어 서버의 작업의 태양을 예시하는 순서도이다. 구성요소(901, 902)에 도시된 바와 같이, 컴퓨팅 디바이스 세트가 제공자 네트워크의 인스턴스 호스트로서 역할하도록 지정될 수 있고, 제어 서버 세트가 인스턴스 호스트의 원격 구성을 관리하도록 지정될 수 있다. 여러 다른 실시예에 있어서, 다양한 유형의 멀티-테넌트, 네트워크 액세스가능한 서비스는, 가상화된 컴퓨팅 서비스, 저장 서비스 또는 네트워킹-관련 서비스와 같은 기반구조-관련 서비스는 물론, 관계형 또는 비-관계형 데이터베이스, 컨텐트 관리 서비스 등과 같은 상위-레벨 멀티-테넌트 애플리케이션도 포함하여, 인스턴스 호스트 상에서 구현되는 (그리고 제어 서버의 도움으로 구성되는) 자원 인스턴스를 사용하여 제공될 수 있다.

새로운 가상화된 컴퓨팅 서버를 론칭하라는 또는 현존 가상화된 서버를 종료하라는 요청과 같은, 멀티-테넌트 서비스 중 하나 이상에 보내지는 인스턴스 구성 요청은 묘사된 실시예에서는, 예를 들어, 클라이언트 상호작용 관리기(235)와 같은 프론트-엔드 제어 서버 컴포넌트에서 또는 프론트-엔드 부하 밸런서에서 수신될 수 있다(구성요소(907)). 제어 서버 컴포넌트의 구현(예를 들어, 제어 서버 기능성의 컴포넌트가 다수 제어 서버에 걸쳐 분산되는지, 멀티-노드 클러스터로서 구현되는지, 단일 모놀리식 제어 서버 내에 전부 편입되는지) 및 구성 요청의 본성에 의존하여, 어느 특정 제어 서버가 클라이언트의 요청에 응답하여 인보크되게 되는지에 관한 그리고 어느 특정 인스턴스 호스트(들)가 인보크되게 되는지에 관한 선택이 이루어져야 할 수 있다. 묘사된 실시예에 있어서, 예를 들어, 클라이언트가 새로운 컴퓨팅 인스턴스를 활성화 또는 론칭하기를 바라면, 특정 인스턴스 호스트는, 클라이언트의 요청이 수신된 소스 가까이의 데이터 센터 또는 가용성 컨테이너에서의 다양한 인스턴스 호스트의 이용 레벨, 클라이언트가 서명 등록한 가격책정 모델, 클라이언트에 사용되고 있는 다른 인스턴스 호스트에 대한 이용가능한 인스턴스 호스트의 인근성과 같은 인자에 기반하여, 또는 클라이언트가 나타낸 명시적 위치 선호에 기반하여 선택될 수 있다(구성요소(910)). 유사하게, 제어 서버(들)는 여러 다른 실시예에 있어서 인근성(예를 들어, 클라이언트에 대해서든 또는 선택된 인스턴스 호스트에 대해서든 근접도) 또는 구성요소(902)에서 결정된 세트의 다양한 제어 서버의 이용 레벨과 같은 다양한 인자에 기반하여 클라이언트의 요청에 대해 선택될 수 있다(구성요소(910)).

묘사된 실시예에 있어서, 인스턴스 상태 관리기(210), 작업 흐름 관리기(225), 구성 정의기(220) 및 커맨드 통신기(240)와 같은 여러 다른 제어 서버 컴포넌트는 클라이언트의 요청에 응답하도록 협력할 수 있다. 일부 실시예에 있어서, 예를 들어, 선택된 인스턴스 호스트의 구성 상태 또는 메타데이터의 상충하는 뮤테이션을 방지하기 위해, 선택사항으로서 로크가 제어 서버 컴포넌트 중 하나에 의해 선택된 인스턴스 호스트 상에서 취득될 수 있거나(구성요소(913)), 또는 어떤 다른 병행 제어 메커니즘이 사용될 수 있다. 여러 다른 로킹 입도가 여러 다른 실시예에서 그리고 여러 다른 유형의 구성 변경에 대해 채용될 수 있다 - 예를 들어, 일부 실시예에서는 소정 인스턴스 호스트와 연관된 메타데이터의 부분집합만이 로킹될 수 있는 한편, 다른 실시예에서는 인스턴스 호스트의 그룹에 대한 메타데이터가 유닛으로서 로킹될 수 있다. 구성 요청으로부터 유도된 커맨드 시퀀스는 궁극적으로는 선택된 제어 서버 컴포넌트로부터 선택된 인스턴스 호스트에 송신될 수 있다(구성요소(914)). 일부 실시예에 있어서, HTTPS 및 JSON 또는 XML과 같은 표준 프로토콜 또는 포맷이 커맨드 시퀀스에 사용될 수 있다.

선택된 인스턴스 호스트에서, 하나 이상의 저-레벨, 무상태, 경량의 원격 커맨드 실행기(RCE)는 묘사된 실시예에서는 커맨드 시퀀스 내에 나타난 작업을 구현하도록, 예를 들어, CGI 프로세스 또는 스레드의 형태로, 실체화될 수 있다(구성요소(916)). 구현에 의존하여, 별개의 RCE 스레드/프로세스 중 어느 것이 시퀀스 내의 각각의 커맨드에 대해 구현될 수 있거나, 단일 RCE가 수개의 커맨드를 구현할 책임이 있을 수 있다. RCE는 적어도 일부 실시예에서는 작업을 발행 또는 개시한 후에 퇴출 또는 종료할 수 있다. RCE 작업의 결과(예를 들어, 운영-체제 또는 하이퍼바이저-레벨 커맨드의 반환 값 또는 퇴출 코드, 표준 출력 및/또는 표준 오류)는 묘사된 실시예에서는 커맨드 요청에 대해 발행한 제어 서버 컴포넌트에 다시 제공될 수 있다(구성요소(919)). 일부 구현에 있어서, RCE는 저절로 퇴출할 수 있는 한편, 다른 구현에 있어서 RCE는 그들 결과가 수신된 후에 (예를 들어, "킬" 신호를 보냄으로써) 명시적으로 종료될 수 있다. 적어도 일부 실시예에 있어서는, 수집된 RCE 결과에 기반하여, 클라이언트의 구성 요청의 상위-레벨 결과(예를 들어, 성공 결과 또는 실패 결과)가 결정될 수 있다(구성요소(921)). 구성요소(913)에 대응하여 작업에서의 상충하는 구성 변경을 방지하도록 로크가 취득되었으면, 그것이 해제될 수 있다. 일부 실시예에 있어서, 결과의 표시 또는 통지는 요청 클라이언트에 제공될 수 있다.

앞서 언급된 바와 같이, 일부 실시예에 있어서, 제어 서버 컴포넌트는 특정 유형의 이벤트(예를 들어, 예상치 못한 프로세스 또는 컴포넌트 실패/셧다운과 같이, 제어 서버 커맨드에 대해 비동기식으로 일어나는 이벤트)가 인스턴스 호스트에서 일어날 때 인스턴스 호스트로부터 통지를 수신하도록 구성될 수 있다. 도 10은, 적어도 일부 실시예에 따른, 제어 서버에서 원격 이벤트 통지와 관련된 작업의 태양을 예시하는 순서도이다. 구성요소(1001)에 도시된 바와 같이, 특정 제어 서버 또는 서버들은 소정 인스턴스 호스트에서의 다양한 비동기식 이벤트를 추적하도록 선택될 수 있다. 일부 실시예에 있어서는, 소정 인스턴스 호스트에 커맨드 시퀀스를 제출할 책임이 있는 동일 제어 서버가 사용될 수 있는 한편, 다른 실시예에서는 다른 제어 서버가 이벤트 통지를 위해 선택될 수 있다. 이벤트 리스너(245)는 선택된 제어 서버 상에 실체화될 수 있다(구성요소(1004)). 이벤트 리스너(245)는, 인스턴스 호스트로부터 이벤트 통지를 수신하도록, 소정 인스턴스 호스트에서의 이벤트 디스패처(310)에 가입 또는 등록할 수 있다. 일부 실시예에 있어서, 이벤트 디스패처는, 예를 들어, 인스턴스 호스트 상에 설치되는 가상화 소프트웨어 계층 이벤트 모니터(또는 운영 체제 계층 이벤트 모니터)로부터, 관심 있는 이벤트가 인스턴스 호스트에서 일어날 때 표시를 획득하도록 구성될 수 있다. 제어 서버에서의 이벤트 리스너로의 통지는 일부 실시예에서는 HTTPS와 같은 보안 네트워킹 프로토콜을 사용하여 제공될 수 있고, 그러한 실시예에서는 이벤트 통지를 위해 지정된 특정 포트가 선택될 수 있다.

예상치 못한 셧다운 또는 실패와 같은 이벤트가 일어날 때, 이벤트 디스패처(310)는 묘사된 실시예에서는 적합한 포맷 및 프로토콜을 사용하여 통지를 이벤트 리스너(245)에 송신할 수 있다. 이벤트 리스너가 통지를 수신(구성요소(1007))한 후에, 예를 들어 이벤트의 본성에 의존하여, 인스턴스 상태 관리기(210) 또는 복구 관리기와 같은 하나 이상의 다른 제어 서버 컴포넌트에 통지될 수 있다(구성요소(1010)). 이벤트에 의해 영향을 받은 자원 인스턴스(들)에 대한 상태 정보는, 예를 들어, 상태 관리기(210)에 의해 영향을 받은 인스턴스 상에 유지되고 있는 상태 메타데이터 내에서 수정될 수 있다(구성요소(1013)). 묘사된 실시예에 있어서, 이벤트 리스너(245) 자체는 인스턴스 상태를 모르고 있을 수 있고, 단순히 하나 이상의 인스턴스 호스트(들)로부터 이벤트 통지를 수신하고 이벤트 통지를 적합한 상위-레벨 제어 서버 컴포넌트 상으로 건네줄 책임이 있을 수 있다. 도 10에 도시된 실시예에 있어서, 제어 서버 설계의 모듈식 본성은 상위-레벨 상태 관리 결정과 이벤트 통지 수신(이벤트 리스너의 책임)을 격리시킬 수 있다. 적어도 일부 실시예에 있어서, 영향을 받는 인스턴스 호스트 상의 복구 작업은 특정 유형의 이벤트에 대해 제어 서버의 별개의 복구 관리기 컴포넌트 또는 인스턴스 상태 관리기(210)에 의해 개시될 수 있다. 일 실시예에 있어서, 이벤트가 일어난 영향을 받는 인스턴스 호스트 상에 자원 인스턴스를 소유하는 클라이언트에 통지될 수 있다.

일부 실시예에 있어서는, 제어 서버의 하나 이상의 풀(120) 및/또는 인스턴스 호스트에서의 (실패 이벤트 후에 인스턴스 상태를 복원하는데 요구될 수 있는 복구 작업을 포함하는) 자원 인스턴스의 원격 관리에 전용인 다른 자원이 수립될 수 있다. 그러한 풀에 포함된 제어 서버의 수는, 예를 들어, 현재 작업 조건에 기반하여 여러 다른 구현에서 달라질 수 있고, 여러 인자에 기반하여 결정될 수 있다. 도 11은, 적어도 일부 실시예에 따른, 제어 서버 풀 사이즈를 결정하는 것과 관련된 작업의 태양을 예시하는 순서도이다. 제어 서버 풀 사이즈는 도 11에 묘사된 실시예에서는 (다수의 자원 인스턴스에 영향을 미치는, 데이터 센터 레벨 또는 가용성 컨테이너 레벨에서의 정전과 같은) 대규모 실패 이벤트와 연관된 복구 요건에 적어도 부분적으로 기반하여 결정될 수 있다. 구성요소(1101)에 도시된 바와 같이, 정전의 빈도, 영향을 받는 실행 중인 자원 인스턴스의 수의 범위, 다양한 복구 작업이 얼마나 오래 걸리는지, 복구 시간의 함수로서의 고객 피드백 등과 같은 메트릭이 대규모 정전시 채집될 수 있다. 그러한 메트릭에 기반하여, 계획되어야 하는 정전 이벤트의 규모에 대한 특정 목표점, 및 인스턴스에 대한 목표 복구 시간이 개발될 수 있다.

구성요소(1104)에 나타낸 바와 같이, (방정식에 기반하는 분석 모델 또는 시뮬레이션 모델과 같은) 모델은 목표로 된 사이즈의 대규모 정전의 발생 이벤트에서 필요로 될 수 있는 다양한 유형의 복구 작업의 레이트를 결정하도록 발생될 수 있다. 그러한 복구 작업은 예를 들어 파일 시스템을 체크 및 리빌드하는 것, 가상 기계 이미지 또는 인스턴스 스냅샷을 레포지토리로부터 인스턴스 호스트에 복사하는 것, 및 제어 소프트웨어 스택의 다양한 레벨에서의 유사한 작업을 포함할 수 있다. 일 구현에 있어서, 예를 들어, 모델은 X분 내 100,000 가상 컴퓨팅 인스턴스의 실패에 대한 인스턴스 복구를 완료하기 위해, 유형 R1의 복구 작업의 요구되는 레이트는 분당 50,000이고, 유형 R2의 복구 작업의 요구되는 레이트는 분당 10,000임을 나타낼 수 있다. 일부 실시예에 있어서, 테스트는 제어 서버의 다양한 사이즈에 의해 다양한 유형의 복구 작업이 완료될 수 있는 레이트를 결정하도록 실행될 수 있다(구성요소(1107)). 모델 및 테스트 결과를 사용하여 그러한 작업을 수행할 여러 다른 유형의 제어 서버의 용량 및 다양한 유형의 복구 작업의 요구되는 레이트를 그렇게 추정하였으면, 제어 서버 풀(들)에 대해 의뢰받을 하나 이상의 용량 레벨의 제어 서버의 수가 결정될 수 있다(구성요소(1111)). 일부 실시예에 있어서, 모델은 복구 작업 시간을 최적화하도록 여러 다른 가용성 컨테이너 내에서의 또는 다양한 데이터 센터에서의 제어 서버의 배치와 같이 더 상세한 추천에 사용될 수 있다. 일부 실시예에서는 (예를 들어, 정전의 부재시) 표준 작업 조건에 필요로 될 수 있는 제어 서버의 수를 결정하도록 유사한 모델이 또한 사용될 수 있다. 그러한 일 실시예에 있어서, 정규 작업 조건 하에 특정 용량 레벨의 요구되는 제어 서버의 수가 N1이라고 추정되고, 목표로 된 사이즈의 대규모 실패 하에 용량 레벨의 요구되는 제어 서버의 수가 N2라고 추정되면, 제공자 네트워크의 운용자는, 양 유형의 작업 조건이 성공적으로 관리될 수 있도록, N1과 N2 중 더 큰 것으로 설정된 풀 사이즈를 선택할 수 있다.

제3자 자원 인스턴스

적어도 일부 실시예에 있어서, 제공자 네트워크의 제어 서버(또는 일괄하여 분산된 제어 서버 집합)는, 일부 실시예에 대하여는 도 1에 예시된 바와 같이, 제공자 네트워크 외부의 제3자 플랫폼의 원격 구성을 관리할 수 있을 수 있다. 도 12는, 일부 실시예에 따른, 그러한 제어 서버의 작업의 태양을 예시하는 순서도이다. 도 12의 구성요소(1201)에 도시된 바와 같이, 멀티-테넌트 네트워크-액세스가능한 서비스에 보내지는 인스턴스 구성 요청은 제공자 네트워크 내부의 인스턴스 호스트뿐만 아니라 제3자 인스턴스 호스트 플랫폼도 둘 다 관리할 수 있는 제어 서버에서 수신될 수 있다. 요청의 본성에 의존하여, 제어 서버는 요청에 대응하는 구성 작업이 수행되어야 하는 특정 인스턴스 호스트 플랫폼을 결정할 수 있다(구성요소(1204)). (구성요소(1207)에서 검출된 바와 같이) 선택된 플랫폼이 제3자 플랫폼이면, 제어 서버 컴포넌트는 저-레벨 커맨드 시퀀스를 제3자 플랫폼에 발행하고(구성요소(1210)), 예를 들어, 작업 흐름 관리기 및 커맨드 통신기의 기능성에 관하여 앞서 설명된 것들과 유사한 기술을 사용하여 결과를 수집할 수 있다. (또한 구성요소(1207)에서 검출된 바와 같이) 선택된 플랫폼이 제공자 네트워크 플랫폼이면, 저-레벨 커맨드가 제공자 네트워크 플랫폼에 발행될 수 있고(구성요소(1213)) 결과가 수집될 수 있다. 어느 경우에서든, 하나 이상의 제어 서버 컴포넌트(들)는 인스턴스 구성 요청의 상위-레벨 결과를 결정하기 위해 저-레벨 커맨드 시퀀스의 수집된 결과를 분석할 수 있고, 적어도 일부 실시예에서는 그리고 특정 유형의 요청에 대해서는, 요청을 제출한 클라이언트에 응답이 제공될 수 있다(구성요소(1216)). 앞서 언급된 바와 같이, 도 12에서의 제3자 플랫폼에 관하여 예시된 기능성의 유형은 또한 또는 대신에 적어도 일부 실시예에서는 접속 거점 위치에서의 플랫폼 및 유사한 원격 플랫폼에 관하여 지원될 수 있다.

일부 실시예에 있어서, 제공자 네트워크(102)는 자원 용량 유닛의 그룹을 표현하는 하나 이상의 디폴트 "인스턴스 패밀리"를 지원할 수 있다. 일부 인스턴스 패밀리는 일반적 사용을 위해, 즉, 공통으로-사용되는 애플리케이션을 실행시키는 클라이언트를 위해 의도될 수 있고; 다른 인스턴스 패밀리는, 고-메모리 애플리케이션, 고-CPU 애플리케이션, 클러스터링된 애플리케이션, 병렬 애플리케이션 등을 위해서와 같이, 전문적 사용을 위해 지원될 수 있다. 제3자(예를 들어, 제공자 네트워크 운용자 이외의 엔티티)가 제공자 네트워크의 제어 서버로부터의 원격 인스턴스 구성을 위해 그들 인스턴스 호스트를 등록하도록 허용되는 일부 실시예에 있어서, 제3자 중 적어도 일부는 그들 자신의 디폴트 인스턴스 패밀리를 정의할 수 있다. 적어도 하나의 실시예에 있어서, 클라이언트는, 아래에 더 상세히 설명되는 바와 같이, 제공자 네트워크 및/또는 제3자에 의해 정의된 디폴트 인스턴스 유형으로부터의 변형을 특정할 수 있다. 도 13은, 적어도 일부 실시예에 따른, 제3자에 의해 그리고 제공자 네트워크에 의해 지원될 수 있는 각각의 컴퓨팅 자원 인스턴스 정의의 예를 도시하고 있다. 제공자 네트워크(102)에 속하는 인스턴스 호스트를 사용하여 지원될 수 있는 "표준" 인스턴스 패밀리(1302)의 일례가, 제3자의 인스턴스 호스트에 대해 제3자에 의해 정의된 다른 일례의 인스턴스 패밀리(1340)와 함께, 도시되어 있다. 컴퓨팅 자원 인스턴스 유형은, 컴퓨팅 용량, 메모리 용량, 저장 용량, 네트워킹 용량, 운영 체제 버전 또는 주소 사이즈(예를 들어, 32-비트 대 64-비트 주소) 등과 같이, 다양한 특성에서 서로 다를 수 있다. 도 13에 있어서, 인스턴스 유형은 다른 컴퓨팅 용량(소위 "C"라는 단위로 표현됨), 메모리 용량(소위 "M"이라는 단위로 표현됨), 및 저장 용량(소위 "S"라는 단위로 표현됨)을 갖는 것으로 도시되어 있고; 인스턴스 유형 간 다른 차이는 명확성을 위해 도시되어 있지 않다. 일부 실시예에서는, 제공자 네트워크 내에든, 또는 소정 제3자 네트워크 내에든 하나보다 많은 인스턴스 패밀리가 정의될 수 있다 - 예를 들어, 특별 "고-메모리" 인스턴스 패밀리가 메모리 집약적 애플리케이션에 대해 지원될 수 있다. 일 실시예에 있어서, 소정 제공자 네트워크 또는 소정 제3자는 단 하나의 종류의 인스턴스만을 정의 또는 지원할 수 있다.

일부 실시예에 있어서, 여러 다른 인스턴스 유형의 소정 인스턴스 패밀리는 여러 다른 하드웨어 서버 유형의 소형 세트를 사용하여 구현될 수 있다(예를 들어, 단일 서버 유형도 일부 경우에서는 소정 패밀리의 모든 인스턴스 유형에 대해 충분할 수 있다). 예를 들어, 도시된 실시예에 있어서, 표준 인스턴스 패밀리(1302)의 다양한 인스턴스 유형(소형, 중형, 대형 및 초대형)은 32 프로세싱 코어, 64 기가바이트의 이용가능한 주 메모리 및 1600 기가바이트의 이용가능한 디스크 저장소를 갖는 단일 서버 유형 "S1"을 사용하여 제공자 네트워크(102) 내에 구현가능할 수 있다. 표준 인스턴스 패밀리(1302)의 4개의 인스턴스 유형의 상대적 컴퓨팅 용량은 1:2:4:8의 비로 있다. 초대형 인스턴스(1316)가 S1 서버의 32 코어 전부를 사용하도록 허용되면, 대형 인스턴스(1314)는 16 코어까지 사용하도록 허용될 수 있고, 중형 인스턴스(1312)는 8 코어까지 사용할 수 있고, 소형 인스턴스(1210)는 4 코어까지 사용할 수 있다. 유사하게, 초대형 인스턴스(1316)가 주 메모리의 64 기가바이트 전부를 사용하도록 허용되면, 인스턴스 유형 대형, 중형 및 소형에 의해 사용가능한 최대 메모리는 각각 32 기가바이트, 16 기가바이트 및 8 기가바이트로 설정될 수 있다. 여러 다른 인스턴스 유형에 대한 저장 용량 한계는 동일한 비로 설정될 수 있다: 초대형 인스턴스에 대해서는 1600 기가바이트 전부, 대형 인스턴스에 대해서는 800 기가바이트, 중형 인스턴스에 대해서는 400 기가바이트 및 소형 인스턴스에 대해서는 200 기가바이트.

일부 실시예에 있어서, 프로세서 코어 사용, 메모리 사용, 저장소 사용에 대한 제한과 더불어, 네트워킹 한계 등과 같은 다른 제한도 여러 다른 인스턴스 유형을 구현하도록 사용된 하이퍼바이저 또는 다른 저-레벨 소프트웨어의 설정 또는 파라미터를 사용하여 제어될 수 있다. 그리하여, 적어도 일부 실시예에서는, 앞서 설명된 제어 서버 컴포넌트의 도움으로 소정 S1 서버 상의 가상화 설정을 변경함으로써, 8개의 소형 인스턴스, 4개의 중형 인스턴스, 2개의 대형 인스턴스, 하나의 초대형 인스턴스, 또는 소형과, 중형과, 대형 인스턴스의 다양한 조합(예를 들어, 하나의 대형 인스턴스와, 하나의 중형 인스턴스와 2개의 소형 인스턴스)을 수립하는 것이 가능할 수 있다. 표준 패밀리 내 각각의 더 큰 인스턴스 유형의 용량이 잠재적으로는 정수의 더 작은 인스턴스를 형성하도록 분배될 수 있다는 사실은 제어 서버 컴포넌트로부터 인스턴스 호스트의 융통성 있는 구성에 유용할 수 있다. 단일 서버 유형(S1)이 위에서 언급되고 있기는 하지만, 일부 실시예에서는 소정 인스턴스 패밀리의 다양한 용량 레벨이 수개의 다른 서버 유형을 사용하여 구현될 수 있고, 인스턴스 패밀리의 여러 다른 용량 레벨에 사용되는 코어 또는 다른 자원의 수가 서로의 정수배이어야 한다는 요건은 없다.

일부 실시예에 있어서, 제3자 플랫폼의 원격 구성에 대해 제공자 네트워크의 제어 서버 기능성을 이용하기를 바라는 제3자는 제공자 네트워크의 인스턴스 호스트에 사용되는 그들 인스턴스 호스트 플랫폼에 대한 동일한 하드웨어 플랫폼 또는 벤더를 사용하도록 요구될 수 있다. 그렇지만, 적어도 일부 실시예에 있어서 적어도 일부의 제3자 운용자는 그들의 후보 인스턴스 호스트 플랫폼에 대해 여러 다른 유형의 하드웨어를 사용할 수 있고, 결과로서, 그들 인스턴스 유형은 그러한 실시예에서는 제공자 네트워크 본디의 인스턴스 유형과는 다양한 유형의 용량(예를 들어, 컴퓨팅, 메모리 또는 저장 용량)에서 다를 수 있다. 도 13의 예에 있어서, 제3자 인스턴스 패밀리(1340)는 "베이스라인" 인스턴스 유형 및 "빅" 인스턴스 유형을 포함한다. 적어도 일부 실시예에 있어서, 소정 제3자에 의해 정의된 여러 다른 유형의 인스턴스에 대한 용량 비는, 예를 들어, 제공자 네트워크 운용자와 제3자 간 비즈니스 협약의 일부분으로서 제공자 네트워크 운용자에 제공될 수 있다. 예를 들어, 도 13에 있어서, "베이스라인"과 "빅" 제3자 인스턴스 유형의 컴퓨팅 용량 간 비는 x:y로서 도시되어 있고, 제3자 인스턴스 유형의 메모리 용량 간 비는 p:q로서 도시되어 있고, 저장 용량 간 비는 f:g로서 도시되어 있다.

제공자 네트워크가, 예를 들어, 공유된 인스턴스 예약 인터페이스 및/또는 공유된 구성 API를 제공함으로써 제3자 인스턴스 패밀리(1340)를 지원하는 클라이언트-대면 인터페이스를 구현하는 실시예에 있어서, 클라이언트에게는 제공자 네트워크 자체의 인스턴스와 제3자 인스턴스의 상대적 용량에 관하여 알려줄 필요가 있을 수 있다. 묘사된 실시예에 있어서, 예를 들어, 제공자 네트워크의 제어 서버의 자격 테스터 컴포넌트(215)는 "표준" 인스턴스 패밀리(1302)의 인스턴스 유형 대비 다양한 제3자 인스턴스 유형의 용량을 결정할 책임이 있을 수 있다. 자격 테스터는, 예를 들어, "베이스라인" 또는 "빅" 인스턴스가 론칭된 특정 제3자 인스턴스 호스트 플랫폼에 테스트(1390) 세트를 송신하고, 테스트의 결과(1392)를 사용하여 제3자 인스턴스 유형 대 제공자 네트워크의 표준 인스턴스 유형의 용량 비를 결정함과 더불어, 제3자 인스턴스 유형의 용량의 비(예를 들어, x:y, p:q, f:g)가 올바른지 검증할 수 있다. 부가적으로, 자격 테스터(215)는 또한 일부 실시예에서는 제3자가 제공자 네트워크의 제어 서버 컴포넌트로부터 원격으로 제어될 인스턴스 호스트의 그 플리트에 부가하기를 바라는 새로운 인스턴스 호스트 후보 플랫폼을 유효성 검증할 책임이 있을 수 있다. 일부 실시예에 있어서, 성능 및 용량 테스트에 부가하여, 예를 들어 소망의 소프트웨어가 설치되었음, 적합한 종류의 RCE가 구성 작업을 구현하는데 필요로 될 때 제어 서버에 의해 성공적으로 인보크될 수 있음 등을 보장할 테스트를 포함하는 다른 유형의 테스트가 또한 제3자 플랫폼 상에 자격 테스터에 의해 수행될 수 있다.

제공자 네트워크 및/또는 제3자 네트워크가 디폴트 지원된 인스턴스 유형 세트를 정의하는 적어도 일부 실시예에 있어서, 클라이언트에 의해 획득될 수 있는 자원 인스턴스의 속성에 관한 추가적 융통성은 클라이언트가 지원된 인스턴스 유형의 속성으로부터의 변형을 나타낼 수 있게 함으로써 지원될 수 있다. 예를 들어, 디폴트 가상화된 인스턴스 유형 세트가 일 실시예에서는 지원될 수 있고, 여기서 각각의 인스턴스 유형은 연관된 속성 또는 자격 세트를 갖는다. 하나의 특정 디폴트 인스턴스 유형(DIT1)은 CPU 성능 속성(CP), 디스크 저장 속성(DP), 네트워크 스루풋 속성(NP), 네트워크 레이턴시 속성(NLP) 및 설치된 소프트웨어 속성(SP)에 의해 특징지어질 수 있다. 클라이언트는, 예를 들어 인스턴스 구성 요청에서, 그들은 속성이 일반적으로는 DIT1에 대해 정의된 속성과 유사하지만, 다른 네트워크 레이턴시 속성(NLP2) 또는 다른 설치된 소프트웨어(SP2) 세트를 갖거나, 어떤 다른 속성 변형을 갖는 자원 인스턴스를 론칭하기를 바란다고 나타낼 수 있다. 제어 서버 컴포넌트가 요청된 속성 변형이 지원될 수 있다고 결정하면, (예를 들어, 속성 변형을 구현할 커맨드를 포함하여) 클라이언트의 요청에 따라 자원 인스턴스를 구성할 커맨드 세트가 위에서 설명된 종류의 기술을 사용하여 발행될 수 있다. 여기에서 설명되는 제어 서버 컴포넌트의 디커플링은 인스턴스 구성에 대한 더 하드-와이어드 접근법이 사용되는 환경에서보다 그러한 변형이 훨씬 더 용이하게 취급 가능하게 할 수 있다.

일부 실시예에 있어서, 도 4에 도시된 종류의 제어 서버 아키텍처에 의해 허용되는 융통성은 속성이 제공자 네트워크에 의해 그리고/또는 제3자 제공자에 의해 지원되는 디폴트 인스턴스 유형과는 실질적으로 다를 수 있는 그들 자신의 인스턴스 유형을 클라이언트가 정의 가능하게 할 수 있다. 그러한 실시예에 있어서, 클라이언트(C1)는, 예를 들어, 프로그램식 인터페이스를 통하여 그리고/또는 제공자 네트워크에 의해 정의된 인스턴스 정의 언어 또는 프로토콜을 사용하여, 다양한 성능 및 다른 자격을 상술하는 그들 선호되는 인스턴스 유형의 정의를 제출할 수 있다. (자격 테스터(215)와 같은) 다양한 제어 서버 컴포넌트는 (제공자 네트워크 내부의 플랫폼이든, 제3자 플랫폼이든, 둘 다이든) 인스턴스 호스트 플랫폼 중, 있다면, 어느 것이 클라이언트-정의된 인스턴스 유형을 지원할 수 있는지 결정할 수 있고, 그들 인스턴스 호스트 플랫폼은 그 클라이언트의 인스턴스 구성 요청에 대해 사용될 수 있다. 일부 실시예에 있어서는, 클라이언트가 소망에 따라 그들 인스턴스 중 어느 것에 대해서라도 커스터마이징된 속성 또는 특성을 정의할 수 있는 완전 동적 인스턴스 정의가 지원될 수 있다.

도 14는, 적어도 일부 실시예에 따른, 네트워크-액세스가능한 서비스를 제공하도록 제3자 네트워크의 자원 인스턴스를 구성하기 위하여 제공자 네트워크의 제어 서버에 의해 수행되는 작업의 태양을 예시하는 순서도이다. 도 14의 구성요소(1401)에 도시된 바와 같이, 제3자 플랫폼 승인 요청은, 상호작용 관리기(235)와 같은, 제어 서버 프론트-엔드 컴포넌트에 의해 (API 또는 웹 페이지와 같은) 프로그램식 인터페이스를 통하여 수신될 수 있다. 승인 요청은, 플랫폼의 네트워크 주소 또는 좌표, 네트워크 주소를 사용하여 관리책임자로서 플랫폼에 로그인하는데 사용가능한 크리덴셜, 하나 이상의 멀티-테넌트 서비스를 제공하도록 플랫폼 상에서 지원될 인스턴스 종류에 대한 인스턴스 유형 정보, 및/또는 플랫폼이 그것이 지원한다고 주장하는 자원 인스턴스를 지원할 수 있는지 유효성 검증하도록 실행될 수 있는 테스트 유형을 나타내는 테스트 정보와 같이, 승인이 소망되는 후보 플랫폼에 대한 다양한 유형의 정보를 포함할 수 있다. (적어도 일부 실시예에 있어서, 단일 승인 요청은 다수의 후보 플랫폼을 나타낼 수 있고, 그 경우 단일 플랫폼에 대해 여기에서 설명되는 테스트 및 다른 작업의 유형은 나타난 후보 플랫폼의 각각에 대해 반복될 수 있다). 승인 요청에 응답하여, 자격 테스터(215)와 같은 제어 서버 컴포넌트는, 설치된 소프트웨어 스택 검증, 성능 테스트, 신뢰도 테스트, RCE가 원격 커맨드를 통하여 론칭될 수 있는지(예를 들어, 후보 플랫폼 상의 웹 서버 또는 다른 커맨드 수신기가 CGI-기반 프로세스 또는 스레드를 론칭하도록 구성될 수 있는지를 포함함) 검증하는 체크 등과 같은, 후보 플랫폼 상의 하나 이상의 자격 결정 작업을 개시할 수 있다(구성요소(1404)). 후보 플랫폼 상에서 지원될 인스턴스 유형이 표시되는 실시예에 있어서, 자격 테스터(215)는 표시된 인스턴스 유형, 또는 인스턴스 유형의 표시된 인스턴스 수가 후보 플랫폼 상에 실체화될 수 있는지 검증할 수 있다. 지원될 인스턴스 유형에 대한 테스트 정의, 또는 그러한 테스트 정의로의 포인터는 일부 실시예에서는 승인 요청 내에 포함될 수 있다. 다양한 실시예에 있어서, 지원될 인스턴스 유형은 제공자 네트워크에 의해 정의되거나, 제3자에 의해 정의되거나, 제3자 및 제공자 네트워크 둘 다에 의해 정의된 인스턴스 유형 또는 패밀리를 포함할 수 있다.

(구성요소(1407)에서 결정되는 바와 같이) 결과가 후보 플랫폼 자격이 허용될 수 있다고 나타내면, 플랫폼은, 예를 들어, 자원 인스턴스 구성이 제공자 네트워크의 제어 서버를 사용하여 원격으로 수행되게 되는 플랫폼의 풀 내 포함을 위해 승인된 것으로 지정될 수 있다(구성요소(1413)). (적합한 바이너리 또는 라이브러리를 사용하여 CGI 프로세스를 론칭하는데 필요로 되는 웹 서버 구성 변경과 같이) 플랫폼 상의 어떠한 부가적 구성 변경이라도 원격 커맨드를 지원하는데 요구되면, 묘사된 실시예에 있어서 그러한 변경은, 예를 들어, 승인 요청에 제공된 관리책임자 크리덴셜을 사용하여 이루어질 수 있다. 후보 플랫폼의 자격이 허용될 수 있지 않다고 알게 되면, 승인 요청은 거절될 수 있다(구성요소(1410)).

후속하여 클라이언트의 인스턴스 구성 요청이 (예를 들어, 상호작용 관리기(235)를 통하여) 제어 서버에서 수신될 때, 제어 서버 컴포넌트(예를 들어, 인스턴스 상태 관리기(210))는, 도 12에 관하여 위에서 또한 설명된 바와 같이, 제공자 네트워크의 인스턴스 호스트가 요청에 응답하도록 사용되게 되는지, 또는 승인된 제3자 플랫폼이 사용되게 되는지에 관한 결정을 할 수 있다. 적어도 일부 실시예에 있어서, 클라이언트는, 도 15를 참조하여 아래에 설명되는 바와 같이, 그들 인스턴스가 론칭되게 되는 플랫폼의 소스(예를 들어, 제공자 네트워크 또는 특정 제3자 네트워크)에 관한 그들 선호를 나타내는 것이 가능하게 될 수 있다. 다른 실시예에 있어서, 인스턴스 상태 관리기는, 클라이언트의 네트워크에 대한 제3자 플랫폼의 근접도, 또는 다른 인스턴스 호스트의 것 대비 제3자 플랫폼의 현재 또는 예측된 이용 레벨과 같은 다양한 인자 중 어느 것에 기반하여, 클라이언트가 제3자 제공자에 대한 선호를 명시적으로 나타내지는 않더라도 승인된 제3자 인스턴스 호스트를 선택하도록 결정할 수 있다. 따라서 클라이언트에 의해 요청된 구성을 수행하도록 특정 승인된 제3자 플랫폼을 사용한다는 결정이 이루어질 수 있다(구성요소(1416)).

제어 서버 컴포넌트가 다수의 서버에 걸쳐 분산되는 적어도 일부 실시예에서는, 선택된 제3자 인스턴스 호스트 플랫폼의 원격 구성에 사용될 하위-레벨 제어 서버 컴포넌트(예를 들어, 작업 흐름 관리기, 커맨드 통신기 및 이벤트 리스너)가 있는 특정 제어 서버가 선택될 수 있다(구성요소(1419)). 커맨드 시퀀스는, 도 4, 도 5, 도 7, 도 8 및 도 9의 맥락에서 앞서 설명된 바와 같이, 커맨드 시퀀스가 제공자 네트워크 자체의 인스턴스 호스트에 보내지는 방식과 유사한 방식으로, 적합한 제어 서버로부터 하나 이상의 RCE를 통한 구현을 위해 선택된 승인된 제3자 인스턴스 호스트에 보내질 수 있다(구성요소(1422)). 예를 들어, HTTPS 프로토콜이 커맨드 시퀀스에 사용될 수 있고, 여러 다른 실시예에 있어서 커맨드 자체는 JSON, XML, 또는 JSON 또는 XML의 변종에 따라 포매팅될 수 있다. 일 실시예에 있어서, 제3자 인스턴스 호스트 플랫폼 상의 구성 변경을 위한 병행 제어는, 예를 들어, 제공자 네트워크의 로크 관리기, 제3자 운용자에 의해 구현된 로크 관리기, 또는 제공자 네트워크와 제3자의 로크 관리기의 조합을 사용하여 구현될 수 있다. 그러한 일 실시예에 있어서는, 제3자 플랫폼에 커맨드 시퀀스를 발행하기 이전에, 제공자 네트워크의 인스턴스 호스트를 로킹하기 위한 위에서 설명된 것과 유사한 방식으로, 하나 이상의 로크가 적합한 로크 관리기(들)로부터 획득될 수 있고, 로크(들)는 작업이 개시 또는 완료된 후에 해제될 수 있다. 제3자 플랫폼에서, 웹 서버와 같은 커맨드 수신기는 일부 실시예에서는 요청된 작업 또는 작업들을 수행하도록 필요에 따라 (예를 들어, CGI를 사용하여) RCE를 실체화할 수 있고, RCE는 작업이 개시된 후에 종료 또는 퇴출할 수 있다. 퇴출 코드 또는 반환 코드, 표준 출력 및/또는 표준 오류와 같은, RCE 작업의 결과는 다시 제어 서버에 제공될 수 있고, 클라이언트의 요청에 대한 응답은 수집된 RCE 결과에 기반하여 제공될 수 있다(구성요소(1425)). 그리하여, 제3자 제공자는 제공자 네트워크 운용자에 의해 구축된 현존 인스턴스 구성 제어 기반구조를 이용할 수 있는 한편, 계속하여 그들 제3자 데이터 센터의 기반구조를 소유 및 관리할 수 있다. 많은 경우에 있어서, 제3자가 그들 초과한 또는 충분히 사용되지 않는 하드웨어 플랫폼을 유료화하고 그 이용을 극적으로 증가시키는 것이 가능하게 될 수 있다. 일부 실시예에 있어서, 앞서 언급된 바와 같이, 클라이언트 네트워크는 또한 충분히 이용되지 않는 하드웨어 플랫폼을 포함할 수 있고, 제공자 네트워크의 클라이언트는 또한 그러한 플랫폼을 더 잘 이용하도록 제공자 네트워크의 제어 서버를 사용하는 것이 가능하게 될 수 있다. 그러한 실시예에 있어서, 예를 들어, 클라이언트는 제공자 네트워크 장비 상에서 실행 중인 도 2의 제어 서버 컴포넌트의 도움으로 클라이언트의 자신의 하드웨어 플랫폼 상에 자원 인스턴스를 론칭할 수 있을 수 있다. 유사하게, 적어도 하나의 실시예에 있어서, 접속 거점(POP) 위치를 운용 또는 관리하는 엔티티는 자원 인스턴스 호스팅을 위해 호스트를 구성하도록 제공자 네트워크의 제어 서버를 사용할 수 있다.

적어도 하나의 실시예에 있어서, 위에서 설명된 종류의 자격 테스트는 시간에 걸쳐 제3자 플랫폼에 대해 반복되어, 예를 들어, 그러한 플랫폼의 승인을 주기적으로 늘릴 수 있다. 그러한 일 실시예에 있어서, 승인을 갱신하도록 하나 이상의 제3자 플랫폼 상에 재-실행될 자격 테스트 반복의 스케줄이 결정될 수 있다. 그 후 자격 테스트의 반복은 스케줄에 따라 개시될 수 있고, 승인이 갱신되어야 하는지에 관한 결정은 반복의 결과에 적어도 부분적으로 기반할 수 있다.

앞서 언급된 바와 같이, 일부 실시예에 있어서 클라이언트에게는 클라이언트의 자원 인스턴스에 사용되게 되는 인스턴스 호스트의 제공자에 대한 그들 선호를 프로그램식으로 나타낼 기회가 제공될 수 있다. 도 15는, 제공자 네트워크의 제어 서버 컴포넌트에 의해 제어되는 제3자 플랫폼 상에 실체화된 인스턴스를 포함하여, 클라이언트가 복수의 제공자로부터 자원 인스턴스를 선택 가능하게 하도록 구현될 수 있는 프로그램식 사용자 인터페이스의 일례를 도시하고 있다. 묘사된 실시예에 있어서, 예시된 사용자 인터페이스는 메시지 구역(1503) 및 수개의 양식 필드를 갖는 웹 페이지(1500)를 포함한다. 메시지 구역(1503)에 나타낸 바와 같이, 클라이언트는 웹 페이지(1500)를 사용하여 그들 인스턴스 요구에 관한 소정 예비적 선호를 제공하도록 요청받고, 양식 필드의 제출은 클라이언트가 소망 인스턴스에 대해 하나 이상 선택할 수 있는 특정 인스턴스 호스트 옵션 양식의 목록의 결과를 초래할 것이다.

필드(1507)를 사용하여, 클라이언트는, 예를 들어, 컴퓨팅 자원이 디폴트 자원 유형인 드롭-다운 선택 목록을 통하여 그들이 취득하기를 바라는 자원(들) 유형(예를 들어, 컴퓨팅 대 저장 대 네트워크)을 나타낼 수 있다. 필드(1509)는 선호되는 자원 벤더를 특정하도록 사용될 수 있다; 클라이언트가 특정 벤더를 특정하지 않기를 바라면, "이용가능한 최저가" 벤더라는 디폴트 선택이 사용될 수 있다. 필드(1511)를 사용하여, 클라이언트는 선호되는 가용성 컨테이너를 나타내거나 또는 지리적으로 가장 가까운 가용성 컨테이너라는 디폴트 옵션이 선택되게 둔다. 필드(1512)는 클라이언트가 이용가능한 다양한 인스턴스 유형 중으로부터 선택 가능하게 하는데, 그 중 일부는 제공자 네트워크에 의해 그 자신의 인스턴스 호스트를 사용하여 구현될 수 있는 한편, 다른 것들은 제3자에 의해 소유된 인스턴스 호스트를 사용하여 구현될 수 있다. 클라이언트는 각각의 패밀리의 인스턴스 유형, 이용가능한 가격책정 정책 및/또는 부가적 정보에 대한 더 많은 상세를 알아내도록 구성요소(1512) 내에 포함된 다양한 링크를 클릭할 수 있다. 묘사된 실시예에 있어서, 클라이언트는 양식 필드(1513)를 사용하여 필요로 되는 자원 인스턴스의 수를, 그리고 구성요소(1515)를 사용하여 인스턴스가 필요로 되는 지속시간을 특정할 수 있다. 클라이언트의 선호는 "제출!" 버튼(1519)을 사용하여 제출될 수 있다.

도 15에 도시되어 있는 것과 다른 실시예에 있어서 여러 다른 선호 정보가 클라이언트로부터 요청될 수 있음과, 일부 실시예에 있어서 웹 페이지 이외의 프로그램식 인터페이스(예를 들어, API, 커맨드-라인 툴 또는 그래픽 사용자 인터페이스)가 클라이언트의 선호를 획득하도록 사용될 수 있음을 유념한다. 또한, 일부 실시예에 있어서, 도 9, 도 10, 도 11, 도 12 및 도 14의 것들과 같은, 위에서 설명된 순서도에 예시된 작업 중 일부는 도면에 도시된 것과는 다른 순서로 수행될 수 있음과, 다른 실시예에 있어서, 작업 중 일부는 순차적으로 대신에 병렬로 수행될 수 있음을 유념한다. 다양한 실시예에 있어서, 순서도에 도시된 작업 중 일부는 생략될 수 있다.

사용례

효율적, 모듈식 자원 인스턴스 원격 구성 제어의, 위에서 설명된 기술은 다수의 플랫폼이 가상화된 자원을 호스팅하도록 사용되게 되는 다양한 유형의 환경에서 유익할 수 있다. 그것들은 클라이언트에 제공 시 다양한 멀티-테넌트 서비스를 지원하도록 요구되는 온-플랫폼 구성 소프트웨어를 사용하는 대안의 접근법이 상당한 오버헤드를 부과할 수 있는 환경에서 특히 유용할 수 있다. 그러한 온-플랫폼 구성 소프트웨어는 이상적으로는 고객-요청된, 수입-발생시키는 자원 인스턴스에 전용이어야 하는 컴퓨팅 사이클, 메모리 및/또는 저장소의 비율을 대신 감축시킬 수 있다.

예시적 실시예

본 개시의 실시예는 이하의 조항을 고려하여 설명될 수 있다:

1. 방법으로서,

클라이언트로부터의 인스턴스 구성 요청에 응답하여,

인스턴스 구성을 위해 특정 커맨드 프로토콜에 따라 포매팅된 하나 이상의 커맨드의 시퀀스를, 자원 인스턴스의 원격 구성을 관리하도록 지정된 하나 이상의 제어 서버 중 선택된 제어 서버로부터, 수신하는 단계로서, 네트워크-액세스가능한 서비스의 자원 인스턴스를 구현하도록 지정된 복수의 인스턴스 호스트 중 선택된 인스턴스 호스트에서 수행되는 상기 수신하는 단계;

원격 커맨드 실행기를, 하나 이상의 커맨드의 시퀀스를 수신하는 것에 응답하여 선택된 인스턴스 호스트에서, 실체화하는 단계;

하나 이상의 커맨드의 시퀀스에 대응하는 하나 이상의 구성 작업을, 선택된 인스턴스 호스트에서의 원격 커맨드 실행기에 의해, 개시하는 단계;

하나 이상의 구성 작업의 결과를 선택된 제어 서버에 제공하는 단계;

원격 커맨드 실행기를 종료하는 단계; 및

클라이언트에, 결과에 적어도 부분적으로 기반하여, 인스턴스 구성 요청에 대한 응답을 제공하는 단계를 포함한다.

2. 제1항의 방법으로서,

선택된 인스턴스 호스트 상에서, 웹 서버에 의해 하나 이상의 커맨드의 시퀀스를, 보안 네트워킹 프로토콜을 통하여, 수신하는 단계를 더 포함하되,

상기 원격 커맨드 실행기를 실체화하는 단계는 공통 게이트웨이 인터페이스(CGI) 표준에 따라 웹 서버에 의해 적어도 하나의 실행 스레드를 실체화하는 단계를 포함한다.

3. 제1항의 방법으로서,

선택된 인스턴스 호스트에서 구현된 이벤트 모니터에, 선택된 인스턴스 호스트에서의 이벤트 디스패처에 의해, 가입하는 단계;

선택된 인스턴스 호스트에서 구현된 자원 인스턴스에서의 이벤트의 통지를, 보안 네트워킹 프로토콜을 통하여 이벤트 디스패처로부터, 제어 서버의 세트 중 특정 제어 서버에, 송신하는 단계를 더 포함하되, 상기 통지는 자원 인스턴스의 상태 정보를 업데이트하도록 사용가능하다.

4. 제1항의 방법으로서,

복수의 인스턴스 호스트에서 구현된 자원 인스턴스를, 특정 유형의 실패의 이벤트시, 복구하도록 인스턴스 복구 구성 작업이 수행되게 되는 레이트를 추정하는 단계; 및

추정된 레이트에 적어도 부분적으로 기반하여 하나 이상의 제어 서버에 포함될 제어 서버의 수를 결정하는 단계를 더 포함한다.

5. 제1항의 방법으로서, 선택된 인스턴스 호스트는 제공자 네트워크의 제1 가용성 컨테이너의 제1 데이터 센터 내에 위치하고, 선택된 제어 서버는 제공자 네트워크의 제2 가용성 컨테이너 내의 다른 데이터 센터 내에 위치하며, 제1 가용성 컨테이너는 제2 가용성 컨테이너와는 다른 가용성 프로파일을 갖는다.

6. 시스템으로서,

네트워크-액세스가능한 서비스의 자원 인스턴스를 구현하도록 구성가능한 복수의 인스턴스 호스트; 및

복수의 인스턴스 호스트에서의 자원 인스턴스의 구성을 관리하도록 구성된 하나 이상의 제어 서버를 포함하되,

하나 이상의 제어 서버 중 선택된 제어 서버는, 클라이언트로부터의 인스턴스 구성 요청에 응답하여, 복수의 인스턴스 호스트 중 선택된 인스턴스 호스트에 하나 이상의 커맨드의 시퀀스를 송신하도록 구성되고,

선택된 인스턴스 호스트는, 하나 이상의 커맨드의 시퀀스를 수신하는 것에 응답하여, 원격 커맨드 실행기를 실체화하도록 구성되며,

원격 커맨드 실행기는 하나 이상의 커맨드의 시퀀스에 대응하는 하나 이상의 구성 작업을 개시하도록 구성되고, 그리고

선택된 제어 서버는 클라이언트에, 하나 이상의 구성 작업의 결과에 적어도 부분적으로 기반하여, 인스턴스 구성 요청에 대한 응답을 제공하도록 구성된다.

7. 제6항의 시스템으로서, 선택된 인스턴스 호스트는,

웹 서버에서 하나 이상의 커맨드의 시퀀스를 수신하도록 더 구성되되,

웹 서버는 공통 게이트웨이 인터페이스(CGI) 표준에 따라 원격 커맨드 실행기를 실체화하도록 구성된다.

8. 제6항의 시스템으로서, 선택된 인스턴스 호스트는,

선택된 인스턴스 호스트에서 구현된 이벤트 모니터에 가입하고; 그리고

선택된 인스턴스 호스트에서의 이벤트 모니터에 의해 표시된 이벤트의 발생의 통지를, 하나 이상의 제어 서버 중 특정 제어 서버에, 보안 네트워킹 프로토콜을 통하여, 송신하도록 구성된 이벤트 디스패처를 포함한다.

9. 제8항의 시스템으로서, 특정 제어 서버는,

자원 인스턴스에 대한 상태 정보를, 통지에 적어도 부분적으로 기반하여, 업데이트하도록 더 구성된다.

10. 제6항의 시스템으로서, 하나 이상의 제어 서버는 제어 서버 풀의 복수의 제어 서버를 포함하되, 제어 서버 풀의 사이즈는, 복수의 인스턴스 호스트에서 구현된 자원 인스턴스를, 특정 유형의 실패의 이벤트 시, 복구하도록 인스턴스 복구 구성 작업이 수행되게 되는 추정된 레이트에 적어도 부분적으로 기반하여 결정된다.

11. 제6항의 시스템으로서, 선택된 인스턴스 호스트는 제공자 네트워크의 제1 가용성 컨테이너의 제1 데이터 센터 내에 위치하고, 선택된 제어 서버는 제공자 네트워크의 제2 가용성 컨테이너 내의 다른 데이터 센터 내에 위치하며, 제1 가용성 컨테이너는 제2 가용성 컨테이너와는 다른 가용성 프로파일을 갖는다.

12. 제6항의 시스템으로서, 하나 이상의 커맨드의 시퀀스를 송신하기 이전에, 선택된 제어 서버는 선택된 인스턴스 호스트 상의 로크를 획득하도록 구성된다.

13. 제6항의 시스템으로서, 하나 이상의 커맨드의 시퀀스는 복수의 커맨드 유형을 지원하는 커맨드 프로토콜에 따라 송신되고, 복수의 커맨드 유형 중 적어도 부분집합의 커맨드 유형은 멱등 커맨드를 포함한다.

14. 제13항의 시스템으로서, 하나 이상의 제어 서버 중 특정 제어 서버는,

복수의 커맨드 유형 중 특정 커맨드 유형을 사용하여 선택된 인스턴스 호스트로부터 하나 이상의 성능 메트릭을 수집하도록 더 구성된다.

15. 제6항의 시스템으로서, 선택된 인스턴스 호스트는, (a) 클라이언트의 식별 정보, (b) 인스턴스 구성 요청 내에 표시된 자원 인스턴스 유형, (c) 복수의 인스턴스 호스트와 연관된 하나 이상의 성능 메트릭, 또는 (d) 하나 이상의 가격책정 정책 중 하나 이상에 적어도 부분적으로 기반하여 복수의 인스턴스 호스트로부터 선택된다.

16. 제6항의 시스템으로서, 하나 이상의 커맨드의 시퀀스는 하이퍼텍스트 전송 프로토콜의 변종을 통하여 송신된다.

17. 제6항의 시스템으로서, 하나 이상의 커맨드의 시퀀스는 제이슨(JSON) 포맷의 변종에 따라 송신된다.

18. 제6항의 시스템으로서, 인스턴스 구성 요청은 구성될 자원 인스턴스 유형을 나타내고, 자원 인스턴스 유형은, (a) 컴퓨팅 자원 인스턴스, (b) 저장 자원 인스턴스, 또는 (c) 네트워킹 자원 인스턴스 중 적어도 하나를 포함한다.

19. 하나 이상의 프로세서 상에서 실행될 때 하나 이상의 네트워크-액세스가능한 서비스의 자원 인스턴스를 호스팅하도록 구성가능한 복수의 인스턴스 호스트를 포함하는 제공자 네트워크의 제어 서버를 구현하는 프로그램 명령어를 저장하는 비-일시적 컴퓨터-액세스가능한 저장 매체로서, 제어 서버는,

클라이언트로부터의 인스턴스 구성 요청으로서 하나 이상의 네트워크-액세스가능한 서비스 중 특정 서비스에 보내지는 인스턴스 구성 요청에 응답하여,

하나 이상의 커맨드를, 복수의 인스턴스 호스트 중 선택된 인스턴스 호스트에, 송신하고;

하나 이상의 커맨드에 응답하여 선택된 인스턴스 호스트에서 실체화된 원격 커맨드 실행기에 의해 선택된 인스턴스 호스트에서 개시된 하나 이상의 구성 작업의 결과를, 선택된 인스턴스 호스트로부터, 수신하고;

클라이언트에, 하나 이상의 구성 작업의 결과에 적어도 부분적으로 기반하여, 인스턴스 구성 요청에 대한 응답을 제공하도록 구성된다.

20. 제19항의 비-일시적 컴퓨터-액세스가능한 저장 매체로서, 제어 서버는, (a) 송신될 하나 이상의 커맨드를 결정하도록 구성된 작업 흐름 관리기, (b) 선택된 인스턴스 호스트에 하나 이상의 커맨드를 송신하도록 구성된 통신 모듈, 및 (c) 선택된 인스턴스 호스트로부터 비동기식 이벤트 통지를 수신하도록 구성된 이벤트 리스너 중 하나 이상을 포함한다.

21. 제19항의 비-일시적 컴퓨터-액세스가능한 저장 매체로서, 하나 이상의 커맨드를 송신하기 이전에, 제어 서버는 선택된 인스턴스 호스트 상의 로크를 획득하도록 구성된다.

22. 제19항의 비-일시적 컴퓨터-액세스가능한 저장 매체로서, 하나 이상의 커맨드는 복수의 커맨드 유형을 지원하는 커맨드 프로토콜에 따라 송신되고, 복수의 커맨드 유형 중 적어도 부분집합의 커맨드 유형은 멱등 커맨드를 포함한다.

23. 제22항의 비-일시적 컴퓨터-액세스가능한 저장 매체로서, 제어 서버는,

복수의 커맨드 유형 중 특정 커맨드 유형을 사용하여 선택된 인스턴스 호스트로부터 하나 이상의 성능 메트릭을 수집하도록 더 구성된다.

24. 제19항의 비-일시적 컴퓨터-액세스가능한 저장 매체로서, 하나 이상의 커맨드는 하이퍼텍스트 전송 프로토콜의 변종을 통하여 송신된다.

25. 제19항의 비-일시적 컴퓨터-액세스가능한 저장 매체로서, 특정 네트워크-액세스가능한 서비스는 자원 인스턴스 유형의 세트를 정의하고, 인스턴스 구성 요청은 (a) 세트 중 특정 자원 인스턴스 유형 및 (b) 특정 자원 인스턴스 유형의 디폴트 속성에 대한 요청된 변형의 표시를 포함하고, 하나 이상의 커맨드 중 적어도 하나의 커맨드는 요청된 변형을 구현하도록 겨냥된다.

26. 제19항의 비-일시적 컴퓨터-액세스가능한 저장 매체로서, 요청된 변형은, (a) 성능 자격, 또는 (b) 설치된 소프트웨어 컴포넌트 중 적어도 하나의 표시를 포함한다.

27. 비-일시적 컴퓨터-액세스가능한 저장 매체로서, 하나 이상의 프로세서 상에서 실행될 때,

제공자 네트워크의 제어 서버로서 하나 이상의 네트워크-액세스가능한 서비스를 제공하기 위해 자원 인스턴스의 원격 구성을 관리하도록 구성되는 제어 서버로부터 인스턴스 구성 커맨드를 수신하고;

원격 커맨드 실행기로서 커맨드에 따라 하나 이상의 구성 작업을 개시하도록 구성되는 원격 커맨드 실행기를 인스턴스 구성 커맨드에 응답하여 실체화하고; 그리고

하나 이상의 구성 작업의 결과를 선택된 제어 서버에 제공하는 프로그램 명령어를 저장한다.

28. 제27항의 비-일시적 컴퓨터-액세스가능한 저장 매체로서, 하나 이상의 프로세서 상에서 실행될 때 명령어는,

웹 서버에서 인스턴스 구성 커맨드를 수신하되, 원격 커맨드 실행기는 공통 게이트웨이 인터페이스(CGI) 표준에 따라 실체화된 적어도 하나의 실행가능한 프로세스를 포함하고, 적어도 하나의 실행가능한 프로세스는 하나 이상의 구성 작업의 개시 후에 종료하도록 구성된다.

29. 제27항의 비-일시적 컴퓨터-액세스가능한 저장 매체로서, 하나 이상의 프로세서 상에서 실행될 때 명령어는,

적어도 부분적으로 (a) 로컬 하이퍼바이저 컴포넌트 또는 (b) 로컬 운영 체제 컴포넌트 중 적어도 하나에 의해 구현된 이벤트 모니터에 가입하고; 그리고

이벤트 모니터에 의해 모니터링된 이벤트의 통지를, 제어 서버에, 송신하도록 동작가능한 이벤트 디스패처를 구현한다.

30. 방법으로서,

가상화된 자원을 호스팅하기 위한 하나 이상의 후보 플랫폼의 표시를 포함하는 플랫폼 승인 요청을, 네트워크-액세스가능한 서비스의 자원의 원격 구성을 지원하는 제공자 네트워크에서, 수신하는 단계;

하나 이상의 후보 플랫폼 중 특정 후보 플랫폼 상에 자격 결정 작업을, 플랫폼 승인 요청에 응답하여, 수행하는 단계;

적어도 부분적으로 제공자 네트워크의 하나 이상의 제어 서버를 통하여 구성되게 되는 가상화된 자원을 호스팅하도록 사용될 승인된 플랫폼으로서 후보 플랫폼을, 자격 결정 작업의 결과에 적어도 부분적으로 기반하여, 지정하는 단계;

클라이언트로부터의 자원 요청에 응답하여, 승인된 플랫폼에서 특정 가상화된 자원을 실체화할 하나 이상의 구성 커맨드를, 하나 이상의 제어 서버 중 특정 제어 서버로부터, 발행하는 단계; 및

하나 이상의 구성 커맨드에 응답하여 승인된 플랫폼에서 실체화된 원격 커맨드 실행기에 의해 개시된 작업의 결과에 적어도 부분적으로 기반하여 자원 요청에 대한 대답을, 클라이언트에, 제공하는 단계를 포함하되, 원격 커맨드 실행기는 작업을 개시한 후에 종료한다.

31. 제30항의 방법으로서, 자격 결정 작업은 후보 플랫폼이 원격 커맨드 실행기를 실체화하도록 구성가능한지 체크하는 것을 포함한다.

32. 제30항의 방법으로서, 자격 결정 작업은 후보 플랫폼이 공통 게이트웨이 인터페이스(CGI)에 따라 원격 커맨드 실행기를 실체화하도록 구성가능한 웹 서버를 포함하는지 체크하는 것을 포함한다.

33. 제30항의 방법으로서, 제공자 네트워크에 의해 구현된 네트워크-액세스가능한 서비스는 지원되는 가상화된 자원 인스턴스 유형의 세트를 정의하고,

지원되는 가상화된 자원 인스턴스 유형의 세트 중 특정 가상화된 자원 인스턴스 유형의, 플랫폼 승인 요청 내, 표시를 수신하는 단계를 더 포함하되, 특정 후보 플랫폼은 특정 가상화된 자원 인스턴스 유형을 지원하도록 겨냥되고, 자격 결정 작업은 특정 가상화된 자원 인스턴스 유형이 특정 후보 플랫폼 상에서 구현될 수 있는지 체크하는 테스트를 포함한다.

34. 제30항의 방법으로서, 제공자 네트워크에 의해 구현된 네트워크-액세스가능한 서비스는 지원되는 가상화된 자원 인스턴스 유형의 세트를 정의하고,

지원되는 가상화된 자원 인스턴스 유형의 세트의 구성원이 아닌 다른 가상화된 자원 인스턴스 유형의, 플랫폼 승인 요청 내, 표시를 수신하는 단계를 더 포함하되, 특정 후보 플랫폼은 다른 가상화된 자원 인스턴스 유형을 지원하도록 겨냥된다.

35. 제30항의 방법으로서, 플랫폼 승인 요청은 적어도 부분적으로 제3자 상호작용을 위해 구현된 프로그램식 인터페이스를 통하여 수신되고, 하나 이상의 후보 플랫폼은 제공자 네트워크 외부의 시설에 상주한다.

36. 제30항의 방법으로서, 하나 이상의 후보 플랫폼은 접속 거점(POP) 시설에 상주한다.

37. 시스템으로서,

가상화된 자원을 호스팅하기 위한 하나 이상의 후보 플랫폼의 표시를 포함하는 플랫폼 승인 요청을, 복수의 네트워크-액세스가능한 서비스를 구현하는 제공자 네트워크에서, 수신하고;

하나 이상의 후보 플랫폼 중 특정 후보 플랫폼 상에 자격 결정 작업을, 플랫폼 승인 요청에 응답하여, 개시하며;

적어도 부분적으로 제공자 네트워크의 하나 이상의 제어 서버를 통하여 구성되게 되는 가상화된 자원을 호스팅하도록 사용될 승인된 플랫폼으로서 특정 후보 플랫폼을, 자격 결정 작업의 결과에 적어도 부분적으로 기반하여, 지정하고; 그리고

클라이언트로부터의 자원 요청에 응답하여, 승인된 플랫폼에서 실체화된 원격 커맨드 실행기를 사용하여 승인된 플랫폼에서 특정 가상화된 자원을 구성할 하나 이상의 구성 커맨드를, 하나 이상의 제어 서버 중 특정 제어 서버로부터, 발행하도록 구성된 하나 이상의 컴퓨팅 디바이스를 포함한다.

38. 제37항의 시스템으로서, 특정 제어 서버는,

원격 커맨드 실행기에 의해 개시된 작업의 결과에 적어도 부분적으로 기반하여 자원 요청에 대한 대답을, 클라이언트에, 제공하도록 더 동작가능하되, 원격 커맨드 실행기는 작업을 개시한 후에 종료하도록 구성된다.

39. 제37항의 시스템으로서, 자격 결정 작업은 후보 플랫폼이 원격 커맨드 실행기를 실체화하도록 구성가능한지 체크하는 것을 포함한다.

40. 제37항의 시스템으로서, 자격 결정 작업은 후보 플랫폼이 공통 게이트웨이 인터페이스(CGI)에 따라 원격 커맨드 실행기를 실체화하도록 구성가능한 웹 서버를 포함하는지 체크하는 것을 포함한다.

41. 제37항의 시스템으로서, 플랫폼 승인 요청은 특정 가상화된 자원 인스턴스 유형의 표시를 포함하고, 특정 후보 플랫폼은 특정 가상화된 자원 인스턴스 유형을 지원하도록 겨냥된다.

42. 제41항의 시스템으로서, 자격 결정 작업은 특정 가상화된 자원 인스턴스 유형이 특정 후보 플랫폼 상에서 구현될 수 있는지 체크하는 테스트를 포함한다.

43. 제37항의 시스템으로서, 제공자 네트워크는 지원되는 가상화된 자원 인스턴스 유형의 세트를 정의하고, 특정 가상화된 자원 인스턴스 유형은 지원되는 가상화된 자원 인스턴스 유형의 세트에 속한다.

44. 제37항의 시스템으로서, 제공자 네트워크는 지원되는 가상화된 자원 인스턴스 유형의 세트를 정의하고, 특정 가상화된 자원 인스턴스 유형은 지원되는 가상화된 자원 인스턴스 유형의 세트에 속하지 않고, 플랫폼 승인 요청은 특정 후보 플랫폼이 특정 가상화된 자원 인스턴스 유형을 구현할 수 있는지 검증하도록 사용될 하나 이상의 테스트의 표시를 포함한다.

45. 제37항의 시스템으로서, 하나 이상의 제어 서버는 적어도 디폴트 가상화된 자원 인스턴스 유형의 세트에 대한 승인된 플랫폼으로서 특정 후보 플랫폼을 지정하도록 구성되고, 클라이언트로부터의 자원 요청은 세트에 포함되지 않는 인스턴스 유형의 특정 가상화된 자원 인스턴스의 표시를 포함하고, 하나 이상의 구성 커맨드는 특정 가상화된 자원 인스턴스를 구성하도록 발행된다.

46. 제45항의 시스템으로서, 특정 가상화된 자원 인스턴스의 특정 속성은 디폴트 가상화된 자원 인스턴스 유형의 각각의 대응하는 속성과는 다르고, 특정 속성은 (a) 성능 속성, (b) 저장 용량 속성, 또는 (c) 지원되는 소프트웨어 특징 속성 중 적어도 하나를 포함한다.

47. 제37항의 시스템으로서, 하나 이상의 구성 커맨드는 하이퍼텍스트 전송 프로토콜의 변종을 통하여 송신된다.

48. 제37항의 시스템으로서, 하나 이상의 구성 커맨드는 제이슨(JSON) 포맷의 변종에 따라 송신된다.

49. 제37항의 시스템으로서, 하나 이상의 컴퓨팅 디바이스는,

(a) 제공자 네트워크 및 (b) 승인된 플랫폼의 소유자를 포함하는 이용가능한 소스의 세트 중으로부터, 클라이언트가 특정 자원에 대한 플랫폼 소스를 선택하는 것을 가능하게 하는 프로그램식 인터페이스를 구현하도록 더 동작한다.

50. 제37항의 시스템으로서, 플랫폼 승인 요청은 클라이언트로부터 수신되고, 하나 이상의 후보 플랫폼은 클라이언트의 클라이언트 네트워크에 상주한다.

51. 하나 이상의 프로세서 상에서 실행될 때 제공자 네트워크의 제어 서버를 구현하는 프로그램 명령어를 저장하는 비-일시적 컴퓨터-액세스가능한 저장 매체로서, 제어 서버는,

구성이 제공자 네트워크 내로부터 관리되는 자원 인스턴스를 적어도 부분적으로 사용하여 구현된 네트워크-액세스가능한 서비스에 보내지는, 클라이언트로부터의 인스턴스 구성 요청의 수신 후에,

인스턴스 구성 요청에 대응하는 하나 이상의 구성 작업이 제공자 네트워크 외부의 원격 플랫폼에서 수행되게 되는지 결정하고;

하나 이상의 구성 작업이 제공자 네트워크 외부의 원격 플랫폼에서 수행되게 된다고 결정하는 것에 응답하여,

제공자 네트워크 외부의 선택된 원격 플랫폼에 하나 이상의 커맨드를 발행하고; 그리고

하나 이상의 커맨드의 결과를, 선택된 원격 플랫폼으로부터, 수신하며;

하나 이상의 구성 작업이 제공자 네트워크 외부의 원격 플랫폼에서 수행되지 않게 된다고 결정하는 것에 응답하여,

제공자 네트워크 내의 선택된 인스턴스 호스트에 하나 이상의 커맨드를 발행하고;

하나 이상의 커맨드의 결과를, 선택된 인스턴스 호스트로부터, 수신하고; 그리고

클라이언트에, 하나 이상의 커맨드의 결과에 적어도 부분적으로 기반하여, 인스턴스 구성 요청에 대한 응답을 제공하도록 구성된다.

52. 제51항의 비-일시적 컴퓨터-액세스가능한 저장 매체로서, 하나 이상의 구성 작업이 제공자 네트워크 외부의 원격 플랫폼에서 수행되게 된다고 결정하는 것에 응답하여, 제어 서버는,

제공자 네트워크 외부의 선택된 원격 플랫폼에서의 커맨드 수신기에 하나 이상의 커맨드를 발행하도록 구성되되, 커맨드 수신기는 하나 이상의 커맨드 중 특정 커맨드에 응답하여 선택된 제3자 플랫폼에서 원격 커맨드 실행기를 실체화하도록 구성되고, 원격 커맨드 실행기는 특정 커맨드에 대응하는 특정 작업을 개시하고, 특정 작업의 결과를 커맨드 수신기에 제공하고, 그리고 퇴출하도록 구성된다.

53. 제51항의 비-일시적 컴퓨터-액세스가능한 저장 매체로서, 선택된 원격 플랫폼에 하나 이상의 커맨드를 발행하기 이전에, 제어 서버는 제공자 네트워크 내에 구현된 로크 관리기를 사용하여 선택된 원격 플랫폼 상의 로크를 획득하도록 구성된다.

54. 비-일시적 컴퓨터-액세스가능한 저장 매체로서, 하나 이상의 프로세서 상에서 실행될 때,

하나 이상의 가상화된 자원을 호스팅할 후보라고 생각되는 제3자 플랫폼을 나타내는 플랫폼 승인 요청을 수신하고;

특정 커맨드 프로토콜을 지원하도록 구성된 원격 커맨드 실행기가 제3자 플랫폼 상에 구현될 수 있는지 체크하는 적어도 하나의 테스트를 포함하는, 제3자 플랫폼 상에 실행될 하나 이상의 자격 테스트를 식별하며;

제3자 플랫폼 상에 하나 이상의 자격 테스트의 실행을 개시하고; 그리고

하나 이상의 자격 테스트의 결과에 적어도 부분적으로 기반하여 제3자 플랫폼을 승인할지 결정하는 프로그램 명령어를 저장한다.

55. 제54항의 비-일시적 컴퓨터-액세스가능한 저장 매체로서, 하나 이상의 자격 테스트는 제공자 네트워크의 네트워크-액세스가능한 서비스에서 지원되는 특정 인스턴스 유형에 대해 정의된 성능 레벨에 따라 제3자 플랫폼의 성능 자격을 체크하는 특정 성능 테스트를 포함한다.

56. 제54항의 비-일시적 컴퓨터-액세스가능한 저장 매체로서, 하나 이상의 자격 테스트는, 승인 요청의 개시자에 의해 정의된 특정 인스턴스 유형에 대해, 승인 요청 내에 표시된 성능 레벨에 따라 제3자 플랫폼의 성능 자격을 체크하는 특정 성능 테스트를 포함한다.

57. 제54항의 비-일시적 컴퓨터-액세스가능한 저장 매체로서, 하나 이상의 프로세서 상에서 실행될 때 명령어는,

제3자 플랫폼의 승인을 갱신하도록 제3자 플랫폼 상에 재-실행될 자격 테스트 반복의 스케줄을 결정하고;

스케줄에 따라 자격 테스트의 반복을 개시하며; 그리고

반복의 결과에 적어도 부분적으로 기반하여 승인이 갱신되어야 하는지 결정한다.

예시적 컴퓨터 시스템

적어도 일부 실시예에 있어서, 인스턴스 호스트 및/또는 다양한 제어 서버 컴포넌트의 기능성을 구현할 기술을 포함하는, 여기에서 설명되는 기술 중 하나 이상 중 일부 또는 전부를 구현하는 서버는 하나 이상의 컴퓨터-액세스가능한 매체를 포함하거나 그에 액세스하도록 구성되는 범용 컴퓨터 시스템을 포함할 수 있다. 도 16은 그러한 범용 컴퓨팅 디바이스(3000)를 예시하고 있다. 도시된 실시예에 있어서, 컴퓨팅 디바이스(3000)는 입/출력(I/O) 인터페이스(3030)를 통하여 시스템 메모리(3020)에 결합된 하나 이상의 프로세서(3010)를 포함한다. 컴퓨팅 디바이스(3000)는 I/O 인터페이스(3030)에 결합된 네트워크 인터페이스(3040)를 더 포함한다.

다양한 실시예에 있어서, 컴퓨팅 디바이스(3000)는 하나의 프로세서(3010)를 포함하는 유니프로세서, 또는 수개의 프로세서(3010)(예를 들어, 2개, 4개, 8개 또는 다른 적합한 수)를 포함하는 멀티프로세서 시스템일 수 있다. 프로세서(3010)는 명령어를 실행할 수 있는 어떠한 적합한 프로세서라도 될 수 있다. 예를 들어, 다양한 실시예에 있어서, 프로세서(3010)는, x86, PowerPC, SPARC, or MIPS ISA, 또는 어느 다른 적합한 ISA와 같은 각종 명령어 세트 아키텍처(ISA) 중 어느 것을 구현하는 범용 또는 내장 프로세서일 수 있다. 멀티프로세서 시스템에 있어서, 프로세서(3010)의 각각은, 반드시는 아니지만, 공통으로 동일 ISA를 구현할 수 있다.

시스템 메모리(3020)는 프로세서(들)(3010)가 액세스가능한 데이터 및 명령어를 저장하도록 구성될 수 있다. 다양한 실시예에 있어서, 시스템 메모리(3020)는, 정적 램(SRAM), 동기식 동적 RAM(SDRAM), 비휘발성/플래시-유형 메모리, 또는 어느 다른 유형의 메모리와 같은, 어떠한 적합한 메모리 기술이라도 사용하여 구현될 수 있다. 도시된 실시예에 있어서, 위에서 설명된 그들 방법, 기술 및 데이터와 같은, 하나 이상의 소망 기능을 구현하는 프로그램 명령어 및 데이터는 코드(3025) 및 데이터(3026)로서 시스템 메모리(3020)에 저장되는 것으로 도시되어 있다.

일 실시예에 있어서, I/O 인터페이스(3030)는 프로세서(3010)와, 시스템 메모리(3020)와, 네트워크 인터페이스(3040) 또는 다른 주변 인터페이스를 포함하는, 디바이스 내 어느 주변 디바이스 간 I/O 트래픽을 조정하도록 구성될 수 있다. 일부 실시예에 있어서, I/O 인터페이스(3030)는 어떠한 필요한 프로토콜, 타이밍, 또는 하나의 컴포넌트(예를 들어, 시스템 메모리(3020))로부터의 데이터 신호를 다른 컴포넌트(예를 들어, 프로세서(3010))에 의한 사용에 적합한 포맷으로 변환하는 다른 데이터 변환이라도 수행할 수 있다. 일부 실시예에 있어서, I/O 인터페이스(3030)는, 예를 들어, 주변 컴포넌트 상호접속(PCI) 버스 표준 또는 범용 직렬 버스(USB) 표준의 변종과 같이 다양한 유형의 주변 버스를 통해 배속된 디바이스에 대한 지원을 포함할 수 있다. 일부 실시예에 있어서, I/O 인터페이스(3030)의 기능은, 예를 들어, 노스 브릿지 및 사우스 브릿지와 같은 2개 이상의 별개 컴포넌트로 나뉠 수 있다. 또한, 일부 실시예에 있어서, 시스템 메모리(3020)로의 인터페이스와 같은, I/O 인터페이스(3030)의 기능성 중 일부 또는 전부는 프로세서(3010)에 직접 편입될 수 있다.

네트워크 인터페이스(3040)는 컴퓨팅 디바이스(3000)와, 예를 들어, 도 1 내지 도 15에 예시된 바와 같은 다른 컴퓨터 시스템 또는 디바이스와 같이 네트워크 또는 네트워크들(3050)에 배속된 다른 디바이스(3060) 간 데이터가 교환될 수 있게 하도록 구성될 수 있다. 다양한 실시예에 있어서, 네트워크 인터페이스(3040)는, 예를 들어, 이더넷 네트워크 유형과 같이 어떠한 적합한 유선 또는 무선 일반 데이터 네트워크라도 통하여 통신을 지원할 수 있다. 부가적으로, 네트워크 인터페이스(3040)는 아날로그 음성 네트워크 또는 디지털 광섬유 통신 네트워크와 같은 원격통신/전화 네트워크를 통하여, 광섬유 채널 SAN과 같은 스토리지 에어리어 네트워크를 통하여, 또는 어떠한 다른 적합한 유형의 네트워크 및/또는 프로토콜이라도 통하여 통신을 지원할 수 있다.

일부 실시예에 있어서, 시스템 메모리(3020)는 대응하는 방법 및 장치의 실시예를 구현하도록 도 1 내지 도 15에 대해 위에서 설명된 바와 같은 프로그램 명령어 및 데이터를 저장하도록 구성된 컴퓨터-액세스가능한 매체의 일 실시예일 수 있다. 그렇지만, 다른 실시예에 있어서, 프로그램 명령어 및/또는 데이터는 여러 다른 유형의 컴퓨터-액세스가능한 매체 상에서 수신, 송신 또는 저장될 수 있다. 일반적으로 말하면, 컴퓨터-액세스가능한 매체는 자기 또는 광학 매체, 예를 들어, I/O 인터페이스(3030)를 통하여 컴퓨팅 디바이스(3000)에 결합된 디스크 또는 DVD/CD와 같은 메모리 매체 또는 비-일시적 저장 매체를 포함할 수 있다. 비-일시적 컴퓨터-액세스가능한 저장 매체는 또한 시스템 메모리(3020) 또는 다른 유형의 메모리로서 컴퓨팅 디바이스(3000)의 일부 실시예에 포함될 수 있는 RAM(예를 들어, SDRAM, DDR SDRAM, RDRAM, SRAM 등), ROM 등과 같은 어떠한 휘발성 또는 비-휘발성 매체라도 포함할 수 있다. 더욱, 컴퓨터-액세스가능한 매체는 네트워크 인터페이스(3040)를 통하여 구현될 수 있는 바와 같은 네트워크 및/또는 무선 링크와 같은 통신 매체를 통하여 전해지는 전기, 전자기 또는 디지털 신호와 같은 신호 또는 전송 매체를 포함할 수 있다. 도 15에 예시된 것과 같은 다수의 컴퓨팅 디바이스 중 일부 또는 전부는 다양한 실시예에 있어서 설명된 기능성을 구현하도록 사용될 수 있다; 예를 들어, 다양한 다른 디바이스 및 서버 상에서 실행되는 소프트웨어 컴포넌트는 기능성을 제공하도록 협업할 수 있다. 일부 실시예에 있어서, 설명된 기능성 중 일부는, 범용 컴퓨터 시스템을 사용하여 구현되는 대신에 또는 그에 부가하여, 특수용 컴퓨터 시스템, 네트워크 디바이스, 또는 저장 디바이스를 사용하여 구현될 수 있다. 용어 "컴퓨팅 디바이스"는, 여기에서 사용될 때, 적어도 모든 이들 유형의 디바이스를 지칭하고, 이들 유형의 디바이스로 한정되지는 않는다.

결론

다양한 실시예는 컴퓨터-액세스가능한 매체 상에 상기 설명에 따라 구현된 명령어 및/또는 데이터를 수신, 송신 또는 저장하는 것을 더 포함할 수 있다. 일반적으로 말하면, 컴퓨터-액세스가능한 매체는 자기 또는 광학 매체, 예를 들어, 디스크 또는 DVD/CD-ROM, RAM(예를 들어, SDRAM, DDR, RDRAM, SRAM 등)과 같은 휘발성 또는 비-휘발성 매체, ROM 등과 같은 메모리 매체 또는 저장 매체는 물론, 네트워크 및/또는 무선 링크와 같은 통신 매체를 통하여 전해지는 전기, 전자기 또는 디지털 신호와 같은 신호 또는 전송 매체도 포함할 수 있다.

여기에서 설명되고 도면에서 예시된 바와 같은 다양한 방법은 방법의 대표적 실시예를 표현한다. 방법은 소프트웨어, 하드웨어, 또는 그 조합으로 구현될 수 있다. 방법의 순서는 변경될 수 있고, 다양한 구성요소가 부가, 순서변경, 조합, 생략, 수정 등이 될 수 있다.

본 개시가 유익한 당업자에게 자명하게 되는 바와 같이 다양한 수정 및 변경이 이루어질 수 있다. 모든 그러한 수정 및 변경을 포괄하려는 의도이고, 그에 따라, 위 설명은 제한적 의미라기보다는 예시로 간주하고자 하는 의도이다.

Claims (15)

1. 네트워크-액세스가능한 서비스의 자원 인스턴스를 위한 인스턴스 호스트를 구성하기 위한 시스템으로서,
   네트워크-액세스가능한 서비스의 상기 자원 인스턴스를 구현하도록 구성가능한 복수의 인스턴스 호스트; 및
   상기 복수의 인스턴스 호스트에서의 상기 자원 인스턴스의 구성을 관리하도록 구성된 하나 이상의 제어 서버를 포함하되,
   상기 하나 이상의 제어 서버 중 선택된 제어 서버는, 클라이언트로부터의 인스턴스 구성 요청에 응답하여, 상기 복수의 인스턴스 호스트 중 선택된 인스턴스 호스트에 하나 이상의 커맨드의 시퀀스를 송신하도록 구성되고,
   상기 선택된 인스턴스 호스트는, 상기 하나 이상의 커맨드의 시퀀스를 수신하는 것에 응답하여, 원격 커맨드 실행기를 실체화하도록 구성되며,
   상기 원격 커맨드 실행기는 상기 하나 이상의 커맨드의 시퀀스에 대응하는 하나 이상의 구성 작업을 개시하도록 구성되고, 그리고
   상기 선택된 제어 서버는 상기 클라이언트에, 상기 하나 이상의 구성 작업의 결과에 기반하여, 상기 인스턴스 구성 요청에 대한 응답을 제공하도록 구성되는 시스템.
2. 제1항에 있어서, 상기 선택된 인스턴스 호스트는,
   웹 서버에서 상기 하나 이상의 커맨드의 시퀀스를 수신하도록 더 구성되되,
   상기 웹 서버는 공통 게이트웨이 인터페이스(CGI) 표준에 따라 상기 원격 커맨드 실행기를 실체화하도록 구성되는 시스템.
3. 제1항에 있어서, 상기 선택된 인스턴스 호스트는,
   상기 선택된 인스턴스 호스트에서 구현된 이벤트 모니터에 가입하고; 그리고
   상기 선택된 인스턴스 호스트에서의 상기 이벤트 모니터에 의해 표시된 이벤트의 발생의 통지를, 상기 하나 이상의 제어 서버 중 특정 제어 서버에, 보안 네트워킹 프로토콜을 통하여, 송신하도록 구성된 이벤트 디스패처를 포함하는 시스템.
4. 제3항에 있어서, 상기 특정 제어 서버는,
   자원 인스턴스에 대한 상태 정보를, 상기 통지에 기반하여, 업데이트하도록 더 구성되는 시스템.
5. 제1항에 있어서, 상기 하나 이상의 제어 서버는 제어 서버 풀(control server pool)의 복수의 제어 서버를 포함하되, 상기 제어 서버 풀의 사이즈는, 상기 복수의 인스턴스 호스트에서 구현된 자원 인스턴스를, 특정 유형의 실패의 이벤트 시, 복구하도록 인스턴스 복구 구성 작업이 수행되게 되는 추정된 레이트에 기반하여 결정되는 시스템.
6. 제1항에 있어서, 상기 선택된 인스턴스 호스트는 제공자 네트워크의 제1 가용성 컨테이너의 제1 데이터 센터 내에 위치하고, 상기 선택된 제어 서버는 상기 제공자 네트워크의 제2 가용성 컨테이너 내의 다른 데이터 센터 내에 위치하되, 상기 제1 가용성 컨테이너는 상기 제2 가용성 컨테이너와는 다른 가용성 프로파일을 갖는 시스템.
7. 제1항에 있어서, 상기 하나 이상의 커맨드의 시퀀스를 송신하기 이전에, 상기 선택된 제어 서버는 상기 선택된 인스턴스 호스트 상의 로크를 획득하도록 구성되는 시스템.
8. 제1항에 있어서, 상기 하나 이상의 커맨드의 시퀀스는 복수의 커맨드 유형을 지원하는 커맨드 프로토콜에 따라 송신되되, 상기 복수의 커맨드 유형 중 적어도 부분집합의 커맨드 유형은 멱등 커맨드를 포함하는 시스템.
9. 제8항에 있어서, 상기 하나 이상의 제어 서버 중 특정 제어 서버는,
   상기 복수의 커맨드 유형 중 특정 커맨드 유형을 사용하여 상기 선택된 인스턴스 호스트로부터 하나 이상의 성능 메트릭을 수집하도록 더 구성되는 시스템.
10. 제6항에 있어서, 상기 선택된 인스턴스 호스트는, (a) 상기 클라이언트의 식별 정보, (b) 상기 인스턴스 구성 요청 내에 표시된 자원 인스턴스 유형, (c) 상기 복수의 인스턴스 호스트와 연관된 하나 이상의 성능 메트릭, 또는 (d) 하나 이상의 가격책정 정책 중 하나 이상에 기반하여 상기 복수의 인스턴스 호스트로부터 선택되는 시스템.
11. 네트워크-액세스가능한 서비스의 자원 인스턴스를 위한 인스턴스 호스트를 구성하기 위한 방법으로서,
    클라이언트로부터의 인스턴스 구성 요청으로서 하나 이상의 네트워크-액세스가능한 서비스 중 특정 서비스에 보내지는 상기 인스턴스 구성 요청에 응답하여,
    하나 이상의 커맨드를, 복수의 인스턴스 호스트 중 선택된 인스턴스 호스트에 제어 서버에 의해, 송신하는 단계;
    상기 하나 이상의 커맨드에 응답하여 상기 선택된 인스턴스 호스트에서 실체화된 원격 커맨드 실행기에 의해 상기 선택된 인스턴스 호스트에서 개시된 하나 이상의 구성 작업의 결과를, 상기 선택된 인스턴스 호스트로부터, 수신하는 단계;
    상기 클라이언트에, 상기 하나 이상의 구성 작업의 결과에 기반하여, 상기 인스턴스 구성 요청에 대한 응답을 제공하는 단계를 포함하는 방법.
12. 제11항에 있어서, 상기 제어 서버는, (a) 송신될 상기 하나 이상의 커맨드를 결정하도록 구성된 작업 흐름 관리기, (b) 상기 선택된 인스턴스 호스트에 상기 하나 이상의 커맨드를 송신하도록 구성된 통신 모듈, 및 (c) 상기 선택된 인스턴스 호스트로부터 비동기식 이벤트 통지를 수신하도록 구성된 이벤트 리스너(event listener) 중 하나 이상을 포함하는 방법.
13. 제11항에 있어서, 상기 하나 이상의 커맨드를 송신하기 이전에, 상기 제어 서버는 상기 선택된 인스턴스 호스트 상의 로크를 획득하도록 구성되는 방법.
14. 제11항에 있어서,
    상기 하나 이상의 커맨드의 복수의 커맨드 유형 중 특정 커맨드 유형을 사용하여 상기 선택된 인스턴스 호스트로부터 하나 이상의 성능 메트릭을 수집하는 단계를 더 포함하는 방법.
15. 제11항에 있어서, 상기 하나 이상의 커맨드는 하이퍼텍스트 전송 프로토콜의 변종을 통하여 송신되는 방법.

Images