KR101959601B1 - 관리 시스템 및 관리 시스템을 제어하기 위한 방법 - Google Patents

관리 시스템 및 관리 시스템을 제어하기 위한 방법 Download PDF

Info

Publication number
KR101959601B1
KR101959601B1 KR1020150173725A KR20150173725A KR101959601B1 KR 101959601 B1 KR101959601 B1 KR 101959601B1 KR 1020150173725 A KR1020150173725 A KR 1020150173725A KR 20150173725 A KR20150173725 A KR 20150173725A KR 101959601 B1 KR101959601 B1 KR 101959601B1
Authority
KR
South Korea
Prior art keywords
processing system
processing
amount
adjustment
request
Prior art date
Application number
KR1020150173725A
Other languages
English (en)
Other versions
KR20160073306A (ko
Inventor
가즈노리 가토
Original Assignee
캐논 가부시끼가이샤
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 캐논 가부시끼가이샤 filed Critical 캐논 가부시끼가이샤
Publication of KR20160073306A publication Critical patent/KR20160073306A/ko
Application granted granted Critical
Publication of KR101959601B1 publication Critical patent/KR101959601B1/ko

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/60—Software deployment
    • G06F8/65—Updates
    • G06F8/656—Updates while running
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5061—Partitioning or combining of resources
    • G06F9/5077—Logical partitioning of resources; Management or configuration of virtualized resources
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2209/00—Indexing scheme relating to G06F9/00
    • G06F2209/50—Indexing scheme relating to G06F9/50
    • G06F2209/5022—Workload threshold

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Security & Cryptography (AREA)
  • Debugging And Monitoring (AREA)
  • Computer And Data Communications (AREA)
  • Business, Economics & Management (AREA)
  • Tourism & Hospitality (AREA)
  • Health & Medical Sciences (AREA)
  • Economics (AREA)
  • General Health & Medical Sciences (AREA)
  • Human Resources & Organizations (AREA)
  • Marketing (AREA)
  • Primary Health Care (AREA)
  • Strategic Management (AREA)
  • General Business, Economics & Management (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

관리 시스템에서, 취득 유닛이 미리정해진 네트워크 시스템으로부터 전송되는 요청을 처리하는 처리 시스템을 전환하기 위한 지시에 따라 제1 처리 시스템에 대해 사용되는 리소스의 양의 조정과 관련된 정보를 취득한다. 조정 지시 유닛은 이러한 취득된 정보를 기초로 제2 처리 시스템 내에서의 리소스의 양을 조정하기 위한 조정 지시로서 제2 처리 시스템 내의 상기 가상 머신의 수를 증가시키기 위한 지시를 내린다. 이후, 상기 미리정해진 네트워크 시스템으로부터 전송된 상기 요청을 처리하는 상기 처리 시스템은 이 조정 지시에 따라 전환된다.

Description

관리 시스템 및 관리 시스템을 제어하기 위한 방법{MANAGEMENT SYSTEM AND METHOD FOR CONTROLLING MANAGEMENT SYSTEM}
본 발명은 처리 시스템이 전환될 때 처리 시스템 내에 포함된 리소스의 리소스 양을 조정하기 위한 기술에 관한 것이다.
최근에는, 사용자가 인터넷 상에 존재하는 서버에서 구동하는 다양한 종류의 애플리케이션을 사용할 수 있게 하는 클라우드 서비스가 제공되고 있다. Infrastructure as a Service(IaaS) 및 Platform as a Service(PaaS)와 같은 클라우드 서비스에서, 클라우드 서비스 벤더는 네트워크를 통해 시스템 관리자에게 스토리지 및 가상 머신과 같은 리소스를 제공한다. 가상 머신은 가상화 기술을 이용하여 물리적 구성과 무관하게 논리적 단위(logical unit)에 의해 서버를 분할함으로써 확립되고 독립적인 운영 시스템을 갖는 상태에서 각각의 논리 컴퓨터가 작동하는 방식으로 구성되는 논리 컴퓨터이다. 시스템 관리자는 클라우드 서비스 벤더에 의해 제공되는 스토리지 및 가상 머신과 같은 리소스를 이용하여 개별 서비스를 제공하기 위한 시스템을 구축할 수 있다.
클라우드 서비스를 이용하여 구축된 시스템은 수신된 요청의 양에 기초한 리소스 양 및 시스템 관리자에 의해 임의로 이루어진 설정에 따른 그러한 요청을 처리하기 위한 로드를 자동으로 조정할 수 있다. 예컨대, 일본 미심사 특허 출원 공개(PCT 출원의 번역문) 제2013-543171호는 프로그램을 실행하는데 필요한 리소스를 자동적으로 할당하고, 프로그램의 실행이 시작된 후 할당된 리소스를 변경하는 오토-스케일링 기능을 개시하고 있다.
리소스 양을 조정하기 위한 이러한 처리는 클라우드 서비스에서 준비되는 리소스 매니저에 의해 수행된다. 요청의 양은 단위 시간 당 로드 밸런서에 의해 수신된 요청의 수를 의미한다. 처리를 위한 로드는 가상 머신 내에서의 처리를 위해 부가되는 로드를 의미하며, 가상 머신의 중앙 처리 유닛(CPU) 사용률 및 메모리 사용률, 응답이 반환되는데 소요되는 시간 등을 지칭한다. 예컨대, 리소스 양의 조정은 가상 머신의 수를 증가시키는 스케일링-아웃, 가상 머신에 대한 하드웨어 리소스의 할당을 증가시키는 스케일링-업을 포함한다. 또한, 리소스 양의 조정은 가상 머신의 수를 감소시키는 스케일링-인 및 가상 머신에 대한 하드웨어 리소스의 할당을 감소시키는 스케일링-다운도 포함한다. 하드웨어 리소스는 CPU, 메모리, 스토리지 등이다. 또한, 로드 밸런서는 수신된 요청의 양을 기초로 스케일링-아웃 등을 자동적으로 수행할 수도 있다.
또한, 최근에는 블루-그린 디플로이먼트(Blue-Green deployment)라 불리는 기술이 예컨대, 상술된 클라우드 서비스를 사용하여 구축된 시스템의 버전 업그레이드 시에 종종 사용되고 있다. 시스템의 버전 업그레이드는 예컨대, 시스템 내의 가상 머신 상에서 실행되는 애플리케이션의 버전 업그레이드를 포함한다. 버전 업그레이드 후 시스템에는 시스템이 제공할 수 있는 추가적인 기능이 설치되고 및/또는 시스템이 관리하는 데이터의 유형 및/또는 포맷이 변경된다.
이제 블루-그린 디플로이먼트가 설명될 것이다.
우선, 현재 외부 네트워크로부터의 요청 수신 및 이러한 요청의 처리를 담당하는 운영 환경인 처리 시스템이 클라우드 서비스에서 작동하고 있다. 처리 시스템은 상기 요청을 처리하도록 구성된 하나 이상의 가상 머신 및 가상 머신으로 상기 요청을 분배하도록 구성된 로드 분배 디바이스로 기능하는 로드 밸런서를 적어도 포함한다. 따라서, 이 처리 시스템의 버전을 업그레이드하길 원할 때, 현재 버전의 처리 시스템과 상이한 버전 업그레이드 후의 처리 시스템이 클라우드 서비스 내에 추가로 구축된다. 이후, 버전을 업그레이드 시키고 싶은 시기가 도래하면, 예컨대 외부 네트워크로부터 요청의 전송 대상을 나타내는 접속처의 설정이 클라우드 서비스 내에서 변경되고, 이로 인해 운영 환경의 역할을 하는 처리 시스템이 전환된다. 이때, 운영 환경은 버전 업그레이드 후의 처리 시스템으로 전환된다. 시스템의 버전 업그레이드는 이러한 전환에 의해 실현된다.
현재 버전의 상술된 시스템이 작동하고 있는 상태인 처리 시스템, 즉 상기 전환 전의 처리 시스템은 소위 블루 환경(Blue environment)으로 불린다. 한편, 버전 업그레이드 후 상술된 시스템이 구축된 상태의 처리 시스템, 즉 상기 전환 후의 처리 시스템은 소위 그린 환경(Green environment)으로 불린다. 이하에서, 블루 환경 및 그린 환경은 제1 처리 시스템 및 제2 처리 시스템으로 각각 언급될 수 있다.
블루-그린 디플로이먼트에 의한 처리 시스템의 전환은 시스템의 상술된 버전 업그레이드 이외의 상황에서도 사용될 수 있다. 예컨대, 이러한 전환은 요청을 처리하는 환경이 실패 또는 버그가 발생한 처리 시스템(이 경우, 제1 처리 시스템)으로부터 다른 정상 작동하는 처리 시스템(이 경우, 제2 처리 시스템)으로 전환될 때 사용될 수 있다.
상술된 시스템과 같은 시스템이 예컨대, 하루에 수 차례 업그레이드되도록 예정될 수 있다. 그러한 시스템에 대해서는, 버전 업그레이드를 위한 다음 타이밍이 곧 다가오기 때문에, 요청의 양의 추이 등을 고려하여 처리 시스템의 상술된 전환을 수행하는 것이 곤란하다.
또한, 시스템 운용 상 새로운 버전의 시스템이 릴리스 될 날짜를 크게 연기하는 것도 불가능할 수 있다. 따라서, 다수의 요청이 외부 네트워크로부터 수신되고 처리를 위한 매우 큰 로드가 제1 처리 시스템 상에 부가될 때에도, 이러한 요청을 처리하는 처리 시스템을 전환하기 위한 처리가 버전 업그레이드 등을 위해 수행되어야만 할 수 있다.
제1 처리 시스템 상에 부가되는 요청과 관련된 처리를 위한 로드가 클 때, 상술된 리소스 매니저는 다수의 리소스가 제1 처리 시스템 내에서 요청을 처리하는 로드 밸런서 등에 제공되도록 조정 처리를 수행한다. 한편, 리소스를 조정하기 위한 처리는 버전 업그레이드를 위한 전환을 기대하고 미리 준비되는 제2 처리 시스템 내의 리소스 매니저에 의해 수행되지 않는데, 이는 제2 처리 시스템이 외부 네트워크로부터 아직 요청을 수신하지 않으며 수신된 요청을 처리하지 않기 때문이다.
또한, 미리 준비된 제2 처리 시스템은 시스템 관리자가 시스템을 관리하는 비용을 절약하려는 것을 고려하는 경우 상대적으로 작은 리소스 양을 포함할 수 있다. 이러한 상황 하에서 상술된 전환 처리를 수행하는 것은 동시에 다수의 요청을 수신하는 제2 처리 시스템을 초래한다. 따라서, 그로부터의 가능한 결과는, 리소스 매니저가 제시간에 리소스를 조정하는 처리를 수행할 수 없는 경우 제2 처리 시스템이 요청을 처리하는 것이 늦어지는 것이다.
본 발명은 제1 처리 시스템으로부터 제2 처리 시스템으로 처리 시스템을 전환하기 위한 처리의 시기에 제2 처리 시스템이 요청을 처리하는 것이 늦어지는 것을 방지할 수 있는 관리 시스템 및 이 관리 시스템을 제어하는 방법에 관한 것이다.
본 발명의 일 양태에 따르면, 적어도, 요청을 처리하도록 각각 구성된 하나 이상의 가상 머신과, 상기 가상 머신(들)에 상기 요청을 분배하도록 구성된 로드 분배 디바이스를 각각 포함하는 복수의 처리 시스템을 포함하는 관리 시스템은, 미리정해진 네트워크 시스템으로부터 전송되는 요청을 처리하는 처리 시스템을 상기 복수의 처리 시스템에 포함된 제1 처리 시스템으로부터 제2 처리 시스템으로 전환하기 위한 지시에 따라, 제1 처리 시스템에 대해 사용되는 리소스의 양의 조정과 관련된 정보를 취득하도록 구성된 취득 유닛과, 상기 취득 유닛에 의해 취득된 상기 정보를 기초로 제2 처리 시스템 내에서의 리소스의 양을 조정하기 위한 조정 지시로서 제2 처리 시스템 내의 가상 머신의 수를 증가시키기 위한 지시를 내리도록 구성된 조정 지시 유닛을 포함하고, 상기 미리정해진 네트워크 시스템으로부터 전송된 상기 요청을 처리하는 상기 처리 시스템은 상기 조정 지시 유닛에 의해 내려진 조정 지시에 따라 제1 처리 시스템으로부터 제2 처리 시스템으로 전환된다.
본 발명의 다른 특징은 첨부된 도면을 참조하여 예시적인 실시예의 후속하는 설명으로부터 명확해질 것이다.
도 1은 본 발명의 예시적 실시예에 따른 시스템 구성의 개략을 도시한다.
도 2는 정보 처리 장치의 하드웨어 구성의 일 예를 도시한다.
도 3a 및 도 3b는 관리 시스템의 구성의 일 예를 각각 도시한다.
도 4는 리소스 매니저의 구성의 일 예를 도시한다.
도 5는 리소스 정보 관리 테이블을 도시한다.
도 6은 모니터링 상태 관리 테이블을 도시한다.
도 7은 오토-스케일링 상태 관리 테이블을 도시한다.
도 8은 스택 정보 관리 테이블을 도시한다.
도 9a, 도 9b, 도 9c 및 도 9d는 스택 템플릿의 일 예를 도시한다.
도 10은 운영 환경을 전환하기 위한 처리의 흐름을 도시하는 흐름도이다.
도 11a, 도 11b 및 도 11c 각각은 그린 환경에서 리소스 양을 조정하기 위한 처리의 흐름을 도시하는 흐름도이다.
도 12는 스택 템플릿의 일 예를 도시한다.
도 13은 이행 방법 테이블을 도시한다.
후속하는 설명에서, 본 발명을 구현하기 위한 예시적 실시예가 도면을 참조하여 설명될 것이다.
본 발명의 예시적 실시예는 예로서, 클라우드 서비스를 이용하여 구축된 네트워크 시스템으로서, 복수의 고객 및 각 고객에 의해 소유되는 네트워크 디바이스를 네트워크를 통해 원격 위치로부터 관리하는 관리 시스템을 기초로 설명될 것이다. 관리 시스템은 고객 각각에 대해 도입된 고객 네트워크 환경 내에 존재하는 네트워크 디바이스로부터 로그 정보 및 장해 정보와 같은 디바이스 정보 및 동작 정보를 수집하고 이들을 분석하여, 다양한 디바이스 관리 서비스를 제공한다. 더욱 구체적으로, 관리 시스템은 장해 시 네트워크 디바이스를 수리하는데 필요한 서비스 및 네트워크 디바이스의 동작 상태를 보고하는 서비스를 제공한다. 관리 시스템은 상기 서비스들을 제공하기 위해 예컨대, 관리 대상으로 취급될 네트워크 디바이스를 신규 등록하고, 리포트를 생성하고, 네트워크 디바이스의 로그 정보를 등록하는 등의 요청을 수신하도록 구성된다.
또한, 고객 디바이스의 관리 등이 고객으로부터 위탁된 고객 관리자가 존재할 수도 있다. 이 경우, 고객 관리자는 각 고객에 의해 소유되는 디바이스를 관리하고 관리 시스템을 사용하여 해당 고객에게 다양한 서비스를 제공한다. 관리 시스템의 사용자는 고객 관리자 및 고객을 포함한다.
도 1은 전체 시스템의 구성의 개략을 도시한다. 네트워크 디바이스 및 고객 정보를 관리하는 관리 시스템(100)과, 각각의 내부에 설치된 네트워크 디바이스를 포함하는 복수의 고객 환경(130)이 인터넷을 통해 서로 접속된다. 또한, 관리 시스템(100)을 관리하는데 이용되는 시스템 관리자를 위한 컴퓨터(110) 및 네트워크 디바이스의 판매 회사의 담당자(고객 관리자)를 위한 컴퓨터(120)도 네트워크를 통해 관리 시스템(100)에 접속된다.
관리 시스템(100)은 IaaS 및 PaaS와 같은 클라우드 서비스에 의해 제공되는 리소스 및 플랫폼을 이용하여 구축된 시스템으로, 네트워크 디바이스 및 네트워크 디바이스를 소유한 고객을 관리하기 위한 서비스를 제공한다. 리소스로서, 클라우드 서비스는 예컨대, 인터넷 내의 데이터 센터에 존재하는 서버 컴퓨터 상에서 구동하는 복수의 가상 머신, 스토리지 등을 제공한다. 각각의 가상 머신은 가상화 기술을 이용하여 물리적 구성과 무관하게 논리 단위에 의해 서버를 분할하여 도입되는 논리 컴퓨터로서, 상기 독립적 운영 시스템을 갖는 상태에서 각각의 논리 컴퓨터가 동작하도록 구성된다. 복수의 가상 머신 상에서의 다양한 애플리케이션 프로그램의 실행은 관리 시스템(100)으로서 다양한 관리 서비스를 구현한다. 서비스 콘텐츠의 구체적인 예는, 고객 환경 내에 설치된 네트워크 디바이스 정보를 수집할 때 해당 고객에 관한 정보와 관련하여 고객 환경(130) 내에 설치된 네트워크 디바이스의 디바이스 정보를 관리하는 서비스를 포함한다. 다른 예는 고객 환경(130) 내에 설치된 네트워크 디바이스의 장해 정보 및 로그 정보와 같은 동작 정보를 수집하고, 수집된 동작 정보를 분석함으로써 판매 회사의 담당자 및 고객에게 보고하는 서비스이다. 또 다른 예는 전자 우편 등을 통해 장애 시 네트워크 디바이스를 수리하는데 필요한 정보를 판매 회사의 담당자에게 통지하는 서비스이다. 네트워크 디바이스의 예는 프린터 및 네트워크 카메라와 같은 화상 처리 장치를 포함한다. 프린터의 종류는 잉크를 사용하여 데이터를 인쇄하는 잉크젯 프린터 및 토너 등을 이용하는 전자 사진식 프린터를 포함한다. 관리 시스템(100)은 인쇄 방법 각각에 대한 특정한 동작 정보(예컨대, 토너 사용량 및 잉크 사용량)를 수집할 수도 있으며, 상이한 관리 서비스를 제공할 수 있다.
컴퓨터(110)는 시스템 관리자에 의해 이용되는 컴퓨터이며, 설치된 웹 브라우저 등을 이용하여 관리 시스템(100)에 의해 제공되는 관리자를 위한 관리 스크린을 디스플레이 할 수 있다. 시스템 관리자는 예컨대, 컴퓨터(110) 상에 디스플레이되는 관리 스크린을 통해 관리 시스템(100)에 대한 다양한 종류의 설정을 구성하기 위한 요청을 전송하기 위한 지시를 내릴 수 있다. 예컨대, 시스템 관리자는 상술된 블루-그린 디플로이먼트를 위해 그린 환경을 생성하기 위한 요청 및 블루 환경으로부터 그린 환경으로 요청 처리 시스템을 전환하기 위한 요청을 전송하기 위한 지시를 내릴 수 있다. 처리 시스템은 요청을 처리하도록 구성된 하나 이상의 가상 머신과 가상 머신(들)에 대해 요청을 분배하도록 구성된 로드 분배 디바이스로서 기능하는 로드 밸런서를 적어도 포함한다.
컴퓨터(120)는 네트워크 디바이스의 판매 회사의 담당자에 의해 이용되는 컴퓨터로서, 웹 브라우저 등을 이용하여 관리 시스템(100)에 의해 제공되는 담당자용 스크린을 디스플레이 할 수 있다. 관리 시스템(100)에 의해 제공되는 담당자용 스크린의 예는, 담당자가 고객 환경(130) 내에 설치된 네트워크 디바이스의 장해 정보 및 로그 정보와 같은 동작 정보를 확인할 수 있게 하는 스크린을 포함한다. 또한, 컴퓨터(120)는 담당자용 스크린과 같은 고객 환경(130) 내에 설치된 네트워크 디바이스를 모니터링하는 설정을 구성하기 위한 스크린을 디스플레이할 수 있다.
고객 환경(130)은 관리 시스템(100)에 의해 관리되는 각 고객을 위한 네트워크에 존재하는 네트워크 환경을 나타낸다. 고객 환경(130)에서, 고객에 의해 소유되는 하나 이상의 네트워크 디바이스 및 관리 시스템(100)과 상기 네트워크 디바이스 사이의 통신을 중계하는 중계 장치는 근거리 네트워크(LAN)를 통해 서로 접속된다. 중계 장치는 네트워크 내에서 네트워크 디바이스를 검색하는 기능을 가지며, 임의의 네트워크 디바이스를 찾은 경우 그 네트워크 디바이스의 디바이스 정보를 관리 시스템(100)에 통지하기 위한 요청을 생성 및 전송하는 기능을 갖는다. 또한, 이 중계 장치는 네트워크 디바이스로부터 수집된 동작 정보를 관리 시스템(100)에 통지하기 위한 요청을 생성하고, 생성된 요청을 전송하는 기능을 갖는다. 본 시스템은 복수의 컴퓨터(120) 및 복수의 고객 환경(130)을 포함할 수 있다.
도 2는 정보 처리 장치의 하드웨어 구성의 일 예를 도시한다. 본 예시적 실시예에 따른 정보 처리 장치는 관리 시스템(100), 컴퓨터(110), 컴퓨터(120), 고객 환경(130) 각각에 존재하는 중계 장치의 역할을 하는 컴퓨터 등을 구현하기 위한 데이터 센터 내에 존재하는 서버 컴퓨터에 대응한다.
정보 처리 장치는 판독 전용 메모리(ROM)(253) 내에 저장된 프로그램을 실행하는 CPU(251)를 포함하고, 내부 버스(256)를 통해 각 디바이스를 총괄적으로 제어한다. 랜덤 액세스 메모리(RAM)(252), ROM(253), 스토리지 디바이스(254), 네트워크 인터페이스(I/F)(255) 및 입력/출력 I/F(257)가 내부 버스(256)에 접속된다. 또한, 입력/출력 I/F(257)는 예컨대, PS/2 도는 유니버설 시리얼 버스(USB I/F) 및 아날로그 또는 디지털 I/F를 포함한다. 입력/출력 I/F(257)는 도시되지 않은 키보드, 마우스, 음극 선관(CRT) 또는 액정 디스플레이 등이 정보 처리 장치에 접속될 수 있게 한다. 정보 처리 장치는 네트워크 I/F(255)를 이용하여 LAN, 인터넷 환경 또는 인터넷을 통해 통신을 수행한다. 이 통신은 정보 처리 장치가 네트워크 디바이스 및 다른 정보 처리 장치와 통신할 수 있게 한다. CPU(251)는 RAM(252) 및 ROM(253)과 함께 프로그램을 실행하기 위한 처리를 수행한다. 또한, CPU(251)는 가상화 기술을 구현하기 위한 프로그램을 실행할 수도 있다. 또한, CPU(251)는 스토리지 디바이스(254)와 같은 기록 매체 내에 데이터를 기록하기 위한 처리를 수행한다. 스토리지 디바이스(254)는 외부 스토리지 디바이스로 기능한다. 다양한 종류의 정보를 저장하는 것 이외에도, 스토리지 디바이스(254)는 다양한 종류의 시스템 정보 및 처리 정보를 RAM(252) 대신에 저장할 수도 있다.
도 3a 및 도 3b는 관리 시스템(100)의 구성의 일 예를 각각 도시한다. 관리 시스템(100)은 컴퓨터(110)를 조작하는 시스템 관리자에 의해 구축 및 관리되고, 서비스를 제공하기 위해 고객 관리자에 의해 조작되는 컴퓨터(120) 및 고객 환경(130) 내의 네트워크 디바이스 및 중계 장치로부터 전송된 요청을 처리한다.
도 3a는 그린 환경(350)이 생성되기 전 관리 시스템(100)을 도시한다. 도 3a에서, 관리 시스템(100)은 시스템 매니저(300), 도메인 네임 시스템(DNS)(301), 데이터베이스(302), 리소스 매니저(303) 및 블루 환경(330)을 포함한다. 한편, 도 3b는 그린 환경(350)이 생성된 후 관리 시스템(100)을 도시한다. 도 3b에 도시된 관리 시스템(100)의 구성은 그린 환경(350)이 그에 부가된 도 3a에 도시된 관리 시스템(100)의 구성이다. 그린 환경(350)은 동작 확인 및 시험이 수행된 후 운영 환경이 되도록 블루 환경(330)을 대체한다. 운영 환경을 전환하기 위한 처리가 도 10을 참조하여 후술될 것이다.
인터넷 프로토콜(IP) 어드레스와 같은 어드레스 정보 및 가상 머신 및 로드 밸런서 각각의 호스트 네임이 DNS(301)에 등록된다. 시스템 관리자를 위한 컴퓨터(110), 고객 관리자를 위한 컴퓨터(120) 및 고객 환경(130) 내의 컴퓨터 및 네트워크 디바이스는 인터넷과 같은 네트워크를 통해 DNS(301)와 통신한다. 이러한 컴퓨터 및 네트워크 디바이스는 요청에 대한 접속처로 설정되는 처리 시스템 내에의 로드 밸런서의 호스트 네임에 대응하는 어드레스 정보를 DNS(301)에 대해 문의하고, DNS(301)로부터 반환된 어드레스 정보에 요청을 전송한다. 수신된 문의에 응답하여, DNS(301)는 DNS 네임과 관련된 DNS 레코드를 이용하여, 요청에 대한 접속처로 설정되는 처리 시스템 내의 로드 밸런서를 나타내는 어드레스 정보 또는 호스트 네임을 반환한다. 관리 시스템(100) 내에 포함된 가상 머신 각각은 고유 IP 어드레스와 같은 어드레스 정보를 갖는다. 따라서, 이 로드 밸런서의 어드레스 정보는 로드 밸런서의 역할을 하는 가상 머신의 어드레스 정보를 기초로 식별될 수 있다.
데이터베이스(302)는 본 관리 시스템(100)을 구현하기 위한 프로그램, 서비스를 제공하기 위한 다양한 종류의 데이터, 이하에서 설명될 도 5 내지 도 8 및 도 13에 도시된 각각의 테이블 등을 저장한다.
시스템 매니저(300)는 예컨대, 시스템 관리자를 위한 컴퓨터(110)로부터 관리 시스템(100) 내의 처리 시스템의 설정에 관한 요청을 수신한다. 시스템 매니저(300)는 시스템 관리자로부터의 요청을 기초로 리소스 매니저(303)에게 지시를 내린다. 예컨대, 시스템 매니저(300)는 처리 시스템을 형성하는 리소스 및 이 리소스를 이용하여 처리 시스템을 생성하는 지시 및 리소스 양을 조정하기 위한 조정 지시를 내린다.
리소스 매니저(303)는 처리 시스템을 형성하는 리소스를 생성 또는 삭제하고, 시스템 매니저(300)로부터의 지시를 기초로 관리 시스템(100) 내의 리소스 양을 조정하기 위한 처리를 수행한다. 리소스 양의 조정은 예컨대, 가상 머신의 수를 증가시키는 스케일링-아웃 및 가상 머신에 대한 하드웨어 리소스의 할당을 증가시키는 스케일링-업을 포함한다. 또한, 리소스 양의 조정은 가상 머신의 수를 감소시키는 스케일링-인 및 가상 머신에 대한 하드웨어 리소스의 할당을 감소시키는 스케일링-다운도 포함한다. 하드웨어 리소스는 CPU(코어의 수), 메모리(크기), 스토리지(크기) 등이다.
리소스 매니저(303)는 또한 블루 환경(330)으로 전송된 요청의 양을 모니터링함으로써 리소스 양을 자동으로 조정할 수 있다. 요청의 양은 단위 시간 당 블루 환경(330) 내에서 로드 밸런서(331)에 의해 수신되는 요청의 수를 의미한다. 또한, 리소스 매니저(303)는 블루 환경(330) 상에 부가된 처리 로드를 모니터링함으로써 리소스 양을 자동으로 조정하도록 구성될 수 있다. 처리 로드는 가상 머신 내에서 처리를 위해 소비된 로드를 의미하며, 가상 머신의 CPU 사용률 및 메모리 사용률, 응답을 반환하는데 걸리는 시간 등을 지칭한다. 용어 "오토-스케일링"은 모니터링된 요청의 양 또는 모니터링된 처리 로드가 사전에 설정된 조건을 충족할 때 리소스 매니저(303)에 의해 수행되는 리소스 양의 조정을 지칭하는데 사용된다.
또한, 리소스 매니저(303)는 예컨대, 시스템 매니저(300)로부터의 지시에 따라 DNS(301)에 등록된 DNS 레코드를 재기입함으로써 운영 환경을 전환한다. 운영 환경을 전환하기 위한 방법이 도 4에 도시된 전환 유닛(405)을 설명하는 문단에서 상세하게 설명될 것이다.
블루 환경(330)은 현재 버전의 애플리케이션이 동작하는 처리 시스템이며, 로드 밸런서(331), 가상 머신(332, 334) 및 큐(333)를 포함한다. 그린 환경(350) 내에서 동작하는 애플리케이션은 블루 환경(330) 내에서 동작하는 애플리케이션에 비해 적어도 하나의 기능이 추가 또는 확장된 업그레이드 버전의 애플리케이션이다. 그린 환경(350)은 로드 밸런서(351), 가상 머신(352, 354) 및 큐(353)를 포함하는 처리 시스템이다. 블루 환경(330) 및 그린 환경(350)의 각각은 예컨대, 복수의 로드 밸런서(331 또는 351), 복수의 가상 머신(332, 334) 또는 (352, 354)를 포함할 수 있다.
블루 환경에서(330), 로드 밸런서(331)는 가상 머신(332)에 대해 수신된 요청을 분배하는 로드 분배 디바이스이다. 가상 머신(332)은 블루 환경(330) 및 요청을 수신 및 처리하는 웹 서버 등의 요청 처리 시스템이다. 큐(333)는 가상 머신(332)에 의해 처리된 요청에 대응하는 메시지를 관리하기 위한 큐이다. 가상 머신(334)은 블루 환경(330) 내의 배치 처리 시스템 및 큐(333) 내에서 큐처리된(queued) 메시지를 처리하는(큐처리된 메시지 상의 배치 처리를 수행하는) 배치 서버 등이다. 가상 머신(332)에 의한 요청 처리 및 가상 머신(334)에 의한 배치 처리는 비동기식으로 수행된다.
그린 환경(350)에서, 로드 밸런서(351)는 가상 머신(들)(352)에 대해 수신된 요청을 분배하는 로드 분배 디바이스이다. 가상 머신(352)은 그린 환경(350), 및 요청을 수신 및 처리하는 웹 서버 등의 요청 처리 시스템이다. 큐(353)는 가상 머신(352)에 의해 처리되는 요청에 대응하는 메시지를 관리하기 위한 큐이다. 가상 머신(354)은 그린 환경(350) 내의 배치 처리 시스템 및 큐(353) 내의 큐처리된 메시지를 처리하는(큐처리된 메시지 상의 배치 처리를 수행하는) 배치 서버 등이다. 가상 머신(352)에 의한 요청 처리 및 가상 머신(354)에 의한 배치 처리는 비동기식으로 수행된다.
관리 시스템(100)은 또한 복수의 그린 환경(350)을 포함할 수 있다. 운영 환경을 변환할 때, 시스템 관리자는 복수의 준비된 그린 환경(350) 중 하나를 선택할 수도 있다.
도 4는 본 예시적 실시예에 따른 리소스 매니저(303)의 구성의 일 예를 도시한다. 리소스 매니저(303)는 리소스 생성 유닛(401), 리소스 모니터링 유닛(402), 오토-스케일링 관리 유닛(403), 스택 수용 유닛(404) 및 전환 유닛(405)을 포함한다.
리소스 생성 유닛(401)은 시스템 관리자로부터 관리 시스템(100)의 리소스에 내려진 요청을 수신하고, 상기 요청을 기초로 가상 머신(332, 334, 352, 354) 및 서버 구성 요소를 생성한다. 시스템 관리자는 가상 머신(332, 334, 352, 354)을 생성하고 이들을 사용 가능하게 만들도록 리소스 생성 유닛(401)에 요청할 수 있다. 리소스 생성 유닛(401)은 다양한 종류의 방법에 의해 시스템 관리자로부터 요청을 수신한다. 예컨대, 리소스 생성 유닛(401)은 관리 시스템(100)에 의해 제공되는 그래픽 사용자 인터페이스(GUI), 애플리케이션 프로그래밍 인터페이스(API) 등을 사용하여 시스템 관리자로부터 요청을 수신하도록 구성될 수 있다. 시스템 관리자로부터의 요청은 가상 머신(332, 334, 352, 354)의 수, 유형 등을 포함한다.
가상 머신(332, 334, 352, 354) 각각은 시스템 관리자에 의해 선택될 수 있는 운영 시스템(OS), 애플리케이션 서버, 시스템 및 애플리케이션 구성 등을 포함할 수 있다. 서버 구성 요소는 로드 밸런서(331, 351), 큐(333, 353) 등을 포함하지만, 이에 제한되지는 않는다. 관리 시스템(100)이 시스템 관리자로부터의 요청을 만족시키는 가상 머신(332, 334, 352, 354)을 생성한 후에, 시스템 관리자는 가상 머신(332, 334, 352, 354)의 설정을 변경할 수 있다. 예컨대, 시스템 관리자는 가상 머신(332, 334, 352, 354) 각각에 관련된 네트워크 대역폭 또는 스토리지 디바이스의 양 또는 유형을 변경할 수 있다.
리소스 모니터링 유닛(402)은 서버 구성 요소 및 가상 머신(332, 334, 352, 354)의 상태, 용량 등을 모니터링한다. 예컨대, 리소스 모니터링 유닛(402)은 모니터링 되는 항목으로서, 로드 밸런서(331, 351) 각각에 대한 단위 시간당 요청의 수, 가상 머신(332, 334, 352, 354) 각각에 대한 CPU 사용률 및/또는 메모리 사용률 등 그리고 큐(333, 353) 각각에 대해 처리되지 않은 메시지의 수 및/또는 기타 사항을 모니터링한다. 리소스 모니터링 유닛(402)은 블루 환경(330) 및 그린 환경(350)에 접속되고, 상술된 모니터링 항목에 대한 정보를 취득한다. 이때, 리소스 모니터링 유닛(402)은 관리 시스템(100) 내의 네트워크(도시 생략)를 거쳐 블루 환경(330) 및 그린 환경(350)에 접속된다.
모니터링된 항목이 모니터링의 결과로서 (이하에서 설명될 도 9b에 도시된 스택 템플릿 내에 규정된) 시스템 관리자에 의해 미리정해진 조건을 만족하는 경우, 리소스 모니터링 유닛(402)은 알람 이벤트를 발생한다. 오토-스케일링 관리 유닛(403)은 상기 알람 이벤트를 수신하고, 이 알람 이벤트에 응답하여 가상 머신(들), 서버 구성 요소(들)을 생성한다.
오토-스케일링 관리 유닛(403)은 서버 구성 요소 및 가상 머신(332, 334, 352, 354)의 오토-스케일링을 관리한다. 오토-스케일링 관리 유닛(403)은, 오토-스케일링의 대상으로 취급되는 가상 머신(332, 334, 352, 354) 및 서버 구성 요소를 그룹 단위로 관리한다. 이 그룹은 본원에서 오토-스케일링 그룹으로 지칭될 것이다. 예컨대, 오토-스케일링 관리 유닛(403)은 복수의 존재하는 가상 머신(332)을 하나의 오토-스케일링 그룹으로 관리한다.
오토-스케일링 관리 유닛(403)은 오토-스케일링 그룹에 속하는 가상 머신(332, 334, 352, 354)을 로드 밸런서(331, 351)에 각각 접속시키고, 오토-스케일링 그룹은 로드 밸런서(331, 351)와 각각 관련 지어진다. 로드 밸런서(331, 351)는 외부로부터 수신된 요청을 가상 머신(332, 352)에 대해 전송 및 분배하고, 가상 머신(332, 352)은 수신된 요청을 처리한다.
오토-스케일링 관리 유닛(403)은 오토-스케일링 그룹에 속한 그리고 작동 중인 서버 구성 요소 또는 가상 머신의 수가 요구되는 디바이스의 수로 설정된 디바이스의 수와 일치하도록 오토-스케일링을 제어한다. 요구되는 디바이스의 수는 시스템 관리자로부터의 요청을 기초로 결정된다. 요구되는 디바이스의 수는 클라우드 서비스의 벤더에 의해 미리 설정될 수 있다.
동작 디바이스의 수가 요구되는 디바이스의 수보다 작은 경우, 오토-스케일링 관리 유닛(403)은 가상 머신(들)을 생성하도록 리소스 생성 유닛(401)에 요청하고, 대응하는 오토-스케일링 그룹에 생성된 가상 머신(들) 등을 추가한다. 오토-스케일링 그룹이 로드 밸런서(331 또는 351)과 관련되는 경우, 오토-스케일링 관리 유닛(403)은 추가된 가상 머신(들)을 대응하는 로드 밸런서(331 또는 351)에 접속시킨다.
한편, 동작 디바이스의 수가 요구되는 디바이스의 수보다 클 경우, 오토-스케일링 관리 유닛(403)은 오토-스케일링 그룹으로부터 가상 머신(들)을 삭제하고, 상기 가상 머신(들)을 중지시키도록 리소스 생성 유닛(401)에 요청한다. 오토-스케일링 그룹이 로드 밸런서(331 또는 351)과 관련되는 경우, 오토-스케일링 관리 유닛(403)은 오토-스케일링 관리 유닛(403)이 삭제하려고 시도하는 가상 머신(들)과 대응하는 로드 밸런서(331 또는 351) 사이의 접속 종료를 요청한다. 로드 밸런서(331 또는 351)는 오토-스케일링 관리 유닛(403)이 삭제를 시도하는 가상 머신(들)로의 요청 전송을 중지하고, 현재 처리되는 요청이 클리어된 후에 로드 밸런서(331 또는 351)과 이 가상 머신(들) 사이의 접속을 종료한다. 오토-스케일링 관리 유닛(403)은 가상 머신(332 또는 352)이 로드 밸런서(331 또는 351)로부터 접속 해제된 후에 가상 머신(332 또는 352)을 중지하도록 리소스 생성 유닛(401)에 요청한다.
또한, 용어 "오토-스케일링 폴리시"는 본원에서 리소스 모니터링 유닛(402)이 알람 이벤트를 발생시킬 때 오토-스케일링 그룹 내의 요구되는 디바이스의 수를 설정하기 위한 처리를 의미하기 위해 사용될 것이다. 시스템 관리자는 예컨대, 요구되는 디바이스의 수를 하나씩 증가시키거나, 요구되는 디바이스의 수를 하나씩 감소시키거나 또는 요구되는 디바이스의 수를 20으로 설정하기 위해 요구되는 디바이스의 수를 지정한다. 리소스 모니터링 유닛(402)은 시스템 관리자로부터의 요청에 따라 리소스 양의 조정에 기여한다. 또한, 오토-스케일링 관리 유닛(403)은 오토-스케일링 상태에 관한 정보를 관리한다. 오토-스케일링 상태에 관한 정보는 가상 머신의 수, 가상 머신의 상세, 최후에 실행된 오토-스케일링의 조작을 포함한다.
스택 수용 유닛(404)은 컴퓨터(110)에 의해 API 등을 사용하여 시스템 관리자로부터의 가상 머신(들), 서버 구성 요소(들) 등을 생성 또는 삭제하라는 요청을 수신한다. 이때, 스택 수용 유닛(404)은 스택 템플릿을 수신하고, 스택 템플릿 내에 기입된 서버 구성 요소(들) 및 가상 머신(들)을 생성하도록 리소스 생성 유닛(401)에 요청한다. 스택 템플릿은, 시스템 관리자로부터의 요청이 가상 머신(들) 및 서버 구성 요소(들)의 생성에 대해 기입되는 템플릿이다. 스택 템플릿은 도 9a 내지 도 9c를 참조하여 이하에서 설명될 것이다. 스택은 동일한 스택 템플릿을 기초로 생성된 서버 구성 요소 및 가상 머신의 수집체를 지칭한다. 본 예에서, 블루 환경(330)에서의 가상 머신(들) 및 서버 구성 요소(들)의 각각의 생성 및 그린 환경에서의 가상 머신 및 서버 구성 요소(들)의 생성은 하나의 스택 템플릿에 기입된다.
스택 수용 유닛(404)은 상술된 바와 같이 구성된 스택 템플릿을 수신하고, 가상 머신(들) 및 서버 구성 요소(들)를 생성할 것을 리소스 생성 유닛(401)에 요청한다. 또한, 스택 수용 유닛(404)은 리소스 모니터링 유닛(402)에 모니터링 조건을 추가하고, 오토-스케일링 관리 유닛(403)과 함께 오토-스케일링에 관한 정보를 등록한다. 이때의 처리는 도 3b에 도시된 그린 환경(350)의 생성을 초래한다.
환경을 전환하라는 지시가 시스템 관리자로부터 내려지면, 전환 유닛(405)은 블루 환경(330) 및 그린 환경(350)의 지정된 스택 식별자(IDs)(801)를 수신하고, 블루 환경(330) 내에서의 리소스 양의 조정과 관련된 정보를 취득한 후, 그린 환경(350)에서 취득된 정보를 반영한다. 그린 환경(350)에서의 리소스를 조정하기 위한 처리가 완료된 후에, 전환 유닛(405)은 DNS(301)의 설정을 변경하여, 운영 환경을 블루 환경(330)에서 그린 환경(350)으로 전환한다.
전환 유닛(405)은 블루 환경(330)으로부터 그린 환경(350)으로 운영 환경을 전환한다. 운영 환경의 전환은 예컨대, 블루 환경(330)을 나타내는 레코드로부터 그린 환경(350)을 나타내는 레코드로 DNS(301) 내의 레코드를 변경하여 구현된다. 예컨대, 서버의 호스트 네임이 www.a-service.com인 경우, 후속하는 레코드: www.a-service.com CNAME lb-R01.cloudservice.com은 블루 환경(330)이 운영 환경으로 역할을 하고 있는 상태에서 등록된다. 이 레코드에서, lb-R01.cloudservice.com은 블루 환경(330)에서의 로드 밸런서(331)의 호스트 네임이다. 로드 밸런서(331)의 이 호스트 네임은 운영 환경이 전환될 때, 그린 환경(350)에서의 로드 밸런스(351)의 호스트 네임인 lb-R02.cloudservice.com으로 재기입된다. DNS(301) 내의 레코드는 다음의 기록: www.a-service.com CNAME lb-R02.cloudservice.com으로 변경된다. 이러한 방식으로 DNS(301) 내의 기록을 변경하는 것은 전환 유닛(405)이 관리 시스템(100) 외부로부터 접속된 컴퓨터(120) 등으로부터의 액세스를 위한 인터넷 웹주소(Uniform Resource Locator)(URL)을 변경하지 않고 블루 환경(330)으로부터 그린 환경(350)으로 접속처인 서비스를 전환할 수 있게 한다.
또한, 리소스 매니저(303)는 시스템 매니저(300)로부터의 지시에 따라 DNS(301) 내에 등록된 DNS 레코드를 재기입한다. DNS 레코드를 재기입하는 것은 고객 매니저를 위한 컴퓨터(120), 고객 환경(130) 내의 컴퓨터 및 네트워크 디바이스와 같은 미리정해진 네트워크로부터의 요청에 대한 접속처의 변경을 유발하여, 운영 환경이 전환될 수 있게 한다.
요청에 대한 접속처를 변경하는 방법의 예는 상술된 방법 이외에, 액세스 포인트로서 로드 밸런서 또는 리버스 프록시를 준비하는 방법 및 시스템에 액세스하기 위한 URL을 재기입하는 방법을 포함한다.
도 5는 본 예시적 실시예에 따른 리소스 정보 관리 테이블을 도시한다. 테이블의 우측 단부에 배치된 수는 레코드 수를 나타내며, 이는 도 6 내지 도 8 및 도 13에 도시된 각각의 테이블에서도 마찬가지다. 리소스 정보 관리 테이블의 항목은 리소스 ID(501), 유형(502) 및 태그(503)를 포함한다. 리소스 생성 유닛(401)은 예컨대, 레코드(511 내지 523)에 의해 지시되는 바와 같이 리소스 정보를 관리한다. 리소스는 클라우드 서비스에 의해 제공되는 리소스를 의미하며, 가상 머신(332, 334, 352, 354) 및 서버 구성 요소를 포함한다.
리소스 ID(501)는 리소스 생성 유닛(401)에 의해 생성된 리소스를 식별하기 위한 식별자이다. 유형(502)은 리소스 생성 유닛(401)에 의해 생성된 리소스의 유형을 나타낸다. 리소스의 유형의 예는 가상 머신, 로드 밸런서 및 큐를 포함한다. 태그(503)는 리소스에 추가되는 정보 및 한 쌍의 키 및 값이다. "Role" 속성은 처리 시스템 내의 가상 머신(들) 또는 서버 구성 요소(들)의 역할을 나타내고, "Web" 및 "Batch"와 같은 값이 그에 대한 설정된다. 또한, "Version" 속성은 관리 시스템(100)을 식별하는데 사용되는 키이며, 예컨대 리소스가 존재하는 환경이 블루 환경(330)인지 또는 그린 환경(350)인지를 제안하는 버전을 나타낸다. 이러한 항목은 운영 환경이 변환될 때 참조되는데, 이는 이하에서 설명될 것이다.
도 6은 본 예시적 실시예에 다른 모니터링 상태 관리 테이블을 도시한다. 리소스 모니터링 유닛(402)은 예컨대, 레코드(611 내지 618)에 의해 나타내지는 바와 같이 리소스를 모니터링하는 상태에 관한 정보를 관리한다. 모니터링 상태 관리 테이블의 항목은 모니터링 조건명(601), 모니터링된 리소스(602), 모니터링된 항목(603), 사전에 측정된 값(604) 및 연속 횟수(605)를 포함한다.
모니터링 조건명(601)은 모니터링 조건을 식별하기 위한 네임이다. 이하에서 설명될 스택 수용 유닛(404)에 의해 생성된 모니터링 조건의 경우, 스택 ID(801)가 모니터링 조건명(601)을 나타내는 문자열의 선두에 추가된다. 모니터링된 리소스(602)는 리소스 모니터링 유닛(402)이 모니터링하는 모니터링된 리소스를 나타내는 정보이다. 모니터링된 항목(603)은 리소스 모니터링 유닛(402)이 모니터링하는 모니터링된 항목을 나타내는 정보이다. 예컨대, 레코드(611)에서, 모니터링된 항목(603)은 리소스 모니터링 유닛(402)이 "R04"에 의해 식별되는 큐(333 또는 353) 내에 저장된 메시지의 수를 모니터링하는 것을 나타낸다. 이전에 측정된 값(604)은 이 레코드 내에서 표시되는 모니터링된 항목(603)에 대해 이전 측정의 시간에 리소스 모니터링 유닛(402)에 의해 취득된 값이다. 연속 횟수(605)는 동일한 모니터링 조건이 연속해서 만족하는 횟수이다. 예컨대, 연속 횟수(605)는, 동일한 모니터링 조건이 300초의 간격으로 연속해서 2회 만족된 경우 관리 시스템(100)이 시스템 관리자에게 통지하도록 설정되는 때와 같은 경우에 사용된다.
도 7은 본 예시적 실시예에 따른 오토-스케일링 상태 관리 테이블을 도시한다. 오토-스케일링 관리 유닛(403)은 예컨대, 레코드(711 내지 718)에 의해 지시되는 바와 같이, 서버 구성 요소 또는 오토-스케일링 그룹의 오토 스케일링에 관한 정보를 관리한다. 오토-스케일링 상태 관리 테이블의 항목은 오토-스케일링 관리 ID(701), 유형(702), 요구되는 디바이스의 수(703), 동작 디바이스의 수(704), 상세(705), 최후에 실행된 조작(706) 및 태그(707)을 포함한다.
오토-스케일링 관리 ID(701)는 오토-스케일링 상태와 관련하여 관리되어야 하는 서버 구성 요소의 리소스 ID 또는 오토-스케일링 그룹의 ID이다. 스택 수용 유닛(404)에 의해 생성된 오토-스케일링 그룹의 경우, 스택 ID(801)는 오토-스케일링 관리 ID를 나타내는 문자열의 선두에 추가된다. 유형(702)은 오토-스케일링 관리 ID(701)로 측정되는 오토-스케일링 관리의 대상인 리소스의 유형을 저장한다. 리소스 유형의 예는 오토-스케일링 그룹, 로드 밸런서 및 큐를 포함한다.
요구되는 디바이스의 수(703)는 오토-스케일링 그룹 내에서 필요하게 되는 것으로 규정되는 가상 머신의 수이다. 동작 디바이스의 수(704)는 오토-스케일링 그룹과 관련되고 작동 중인 가상 머신의 수이다. 오토-스케일링 관리 유닛(403)은 동작 디바이스의 수(704)가 요구되는 디바이스의 수(703)와 일치하도록 동작 디바이스의 수(704)를 제어한다. 상세(705)는 가상 머신의 처리 용량을 나타낸다.
최후에 실행된 조작(706)은 오토-스케일링 그룹, 서버 구성 요소 등에서 오토-스케일링 관리 유닛(403)에 의해 마지막으로 수행된 조작으로서 보유되는 제어 명령이다. 태그(707)는 오토-스케일링 관리 ID(701)로 지정되는 서버 구성 요소 또는 오토-스케일링 그룹에 추가되는 태그이다. "Role" 속성 및 "Version" 속성은 각각 태그(503)의 설명에서 기술된 "Role" 속성 및 "Version" 속성과 유사하다.
예컨대, 로드 밸런서 및 큐와 같은 서버 구성 요소 등은 클라우드 서비스 벤더에 의해 미리 설정될 수 있으며, 매니지드 서비스(managed service)로서 시스템 관리자에게 제공될 수 있다. 이러한 경우, 관리 시스템(100)은 시스템 관리자에게 상기 설정 및 오토-스케일링의 상태를 개시하는 것을 자제할 수 있다. 또한, 관리 시스템(100)은 시스템 관리자가 오토-스케일링 기능에 관한 설정을 구성하지 않고, 관리 시스템(100)이 오토-스케일링을 자동으로 설정 및 관리하는 방식으로 구성될 수 있다.
도8은 본 예시적 실시예에 따른 스택 정보 관리 테이블을 도시한다. 스택을 생성하라는 요청을 수신하면, 스택 수용 유닛(404)은 스택을 식별하기 위한 스택 ID(801)를 생성하고, 생성된 가상 머신, 생성된 서버 구성 요소 및 다른 설정 정보와 관련된 스택 ID(801)를 관리한다. 스택 수용 유닛(404)은 예컨대, 레코드(811 내지 823)에 의해 지시되는 바와 같이 스택 ID(801)와 관련된 스택 템플릿을 보유한다. 스택 정보 관리 테이블의 항목은 스택 ID(801) 및 리소스 ID(802)를 포함한다.
스택 ID(801)는 스택 수용 유닛(404)에 의해 발행되는 스택의 식별자이다. 리소스 ID(802)는 스택과 관련하여 생성된 서버 구성 요소 또는 가상 머신(332, 334, 352, 또는 354)의 리소스의 식별자이다. 시스템 관리자가 스택의 삭제를 지정한 경우, 스택 수용 유닛(404)은 스택 정보 관리 테이블을 참조하고 스택과 관련된 리소스의 삭제를 요청한다. 또한, 스택 수용 유닛(404)은 도 5 내지 도 7에 도시된 각각의 테이블에서 오토-스케일링 관리 유닛(403) 및 리소스 모니터링 유닛(402)에 의해 등록된 다양한 종류의 설정 정보의 삭제를 요청한다.
시스템 관리자는 복수의 스택을 조합하는 상태에서 처리 시스템을 구축할 수 있다. 예컨대, 시스템 관리자는 시스템의 버전을 업그레이드할 때 교체되지 않을 데이터베이스 서버 등을 포함하는 스택과, 버전을 업그레이드할 때 교체될 웹 서버 등을 포함하는 스택을 조합할 수 있다.
도 9a, 도 9b, 도 9c 및 도 9d는 본 예시적 실시예에 따른 스택 템플릿을 도시한다. 스택 수용 유닛(404)은 예컨대, 시스템 관리자에 의해 조작되는 컴퓨터(110)로부터 스택 템플릿을 수신한다. 좌측 단부에 배치된 수는 라인 수를 나타내며, 동일한 사항이 도 12에 도시된 스택 템플릿에도 적용된다. 도 9a는 스택 템플릿 내의 2번째으로부터 53번째 라인을 도시한다. 도 9b는 스택 템플릿 내에서 54번째 라인으로부터 97번째 라인을 도시한다. 도 9c는 스택 템플릿 내에서 98번째 라인으로부터 140번째 라인을 도시한다. 도 9d는 스택 템플릿 내에서 141번째 라인으로부터 185번째 라인을 도시한다. 후속하는 설명에서, 스택 템플릿은 본 예시적 실시예와 관련된 부분을 발췌하여 설명될 것이다. 오토-스케일링 기능의 설정, 스택으로서 생성되는 서버 구성 요소 및 가상 머신 등은 2번째 라인으로부터 185번째 라인에 지정된다.
명칭이 WebLB인 로드 밸런서의 생성이 지정되고, "Role" 속성 및 "Version" 속성의 값은 각각 도 9a에 도시된 3번째 라인으로부터 25번째 라인에서 태그로서 "Web" 및 "100"으로 지정된다. 스택 수용 유닛(404)은 로드 밸런서를 생성할 것을 리소스 생성 유닛(401)에 요청한다. 생성된 로드 밸런서에 관한 정보는 리소스 정보 관리 테이블(도 5)에 등록되고, 스택 ID(801)와 리소스 ID(802) 사이의 관계는 스택 정보 관리 테이블(도 8)에 등록된다. 명칭이 WebAutoScalingGroup인 오토-스케일링 그룹은 26번째 라인으로부터 46번째 라인에 설정된다. 접속 대상은 로드 밸런서: WebLB가 되도록 지정되고, 가상 머신의 최소수(MinSize) 및 최대수(MaxSize)는 각각 2와 10으로 지정된다. 초기에 요구되는 디바이스의 수(DesiredCapacity)는 2로 지정되고, 가상 머신의 기동 설정(LaunchConfigurationName)은 "WebLaunchConfig"로 지정된다. "Role" 속성 및 "Version" 속성은 각각 태그로서 "Web" 및 "100"으로 지정된다.
WebAutoScalingGroup 내에서 지정된 명칭이 "WebLaunchConfig"인 가상 머신의 기동은 47번째 라인으로부터 53번째 라인에 설정된다. OS 화상(ImageID)로서 "imageWeb100"의 사용이 지정되고, CPU, 메모리 등의 상세를 지정하는 인스턴트 유형(instance type)(InstanceType)으로서 "Large"가 지정된다.
스택 템플릿의 이러한 예에서, 스택 수용 유닛(404)은 오토-스케일링 그룹(S01_WebAutoScalingGroup)을 오토-스케일링 관리 유닛(403)에 등록하고, 요구되는 디바이스의 수를 2로 설정한다(문자열의 선두에 스택 ID(801)를 추가한다). 요구되는 디바이스의 수가 2로 설정되었지만 동작하는 디바이스의 수가 0이기 때문에, 오토-스케일링 관리 유닛(403)은 동작하는 디바이스의 수가 요구되는 디바이스의 수에 도달할 때까지 오토-스케일링 그룹에 생성된 가상 머신을 추가하도록 WebLaunchConfig를 기초로 가상 머신(332 또는 352)를 생성한다.
명칭이 WebAutoScalingGroup인 오토-스케일링 그룹과 관련된 오토-스케일링 폴리시는 54번째 라인으로부터 71번째 라인에 지정된다. WebScaleUpPolicy는 요구되는 디바이스의 수를 하나씩 증가시키는 조작("ScalingAdjustment" : "1")이 실행되도록 지정된다. 또한, WebScaleDownPolicy는 요구되는 디바이스의 수를 하나씩 감소시키는 조작("ScalingAdjustment" : "-1")이 실행되도록 지정된다. WebScaleUpPolicy는 스택 수용 유닛(404)이 스택 템플릿을 기초로 구성하는 가상 서버 그룹의 설정을 위한 지시이다.
명칭이 WebAutoScalingGroup인 오토-스케일링 그룹과 관련된 모니터링 및 통지 조건은 도 9b에 도시된 72번째 라인으로부터 97번째 라인에 설정된다.
WebCPUAlarmHigh에서, CPU 사용률("CPUUtilization")의 평균이 "WebAutoScalingGroup"에 대해 모니터링 되는 항목(MetricName)으로서 모니터링되도록 지정된다. 따라서, CPU 사용률의 평균이 300초 간격으로 2회 역치 값인 90%를 초과하는 경우 리소스의 조정이 AlarmAction에 지정된 명칭이 "WebScaleUpPolicy"인 오토-스케일링 폴리시를 참조하여 수행되도록 지정된다.
스택 템플릿의 이 예에서, 스택 수용 유닛(404)은 리소스 모니터링 유닛(402) 내에 모니터링 조건(S01_ WebCPUAlarmHigh) 등을 등록한다.
생성되어야 하는 큐가 도 9c에서 98번째 라인으로부터 113번째 라인에 지정된다. 이 예에서, 명칭이 "BatchQueue"인 큐의 생성이 지정된다. "Role" 속성 및 "Version" 속성의 값은 각각 태그로서 "Batch" 및 "100"으로 지정된다.
스택 템플릿의 이 예에서, 스택 수용 유닛(404)은 큐를 생성할 것을 리소스 생성 유닛(401)에 요청한다. 생성된 큐에 관한 정보는 리소스 정보 관리 테이블(도 5)에 등록되고, 스택 ID(801)와 리소스 ID(802) 사이의 관계는 스택 정보 관리 테이블(도 8)에 저장된다.
명칭이 BatchAutoScalingGroup인 오토-스케일링 그룹이 지정되고, 가상 머신의 최소수(MinSize) 및 최대수(MaxSize)가 각각 1과 10으로 도 9c의 114번째 라인으로부터 133번째 라인에 지정된다. 초기에 요구되는 디바이스의 수(DesiredCapacity)는 1로 지정되고, 가상 머신의 기동 설정(LaunchConfigurationName)은 "BatchLaunchConfig"로 지정된다. "Role" 속성 및 "Version" 속성은 각각 태그로서 "Batch" 및 "100"으로 지정된다. BatchLaunchConfig는 수신된 요청에 대응하는 큐 내에 축적된 처리를 연속적으로 수행하는 배치 처리 시스템의 설정을 위한 지시이다.
BatchAutoScalingGroup 내에 지정된 명칭이 "BatchLaunchConfig"인 가상 머신의 기동은 도 9c의 134번째 라인으로부터 140번째 라인에 설정된다.
명칭이 BatchAutoScalingGroup인 오토-스케일링 그룹에 관련된 오토-스케일링 폴리시가 도 9d에 도시된 141번째 라인으로부터 158번째 라인에 지정된다. BatchScaleUpPolicy는 요구되는 디바이스의 수를 하나씩 증가시키는 조작("ScalingAdjustment" : "1")이 실행되도록 지정된다. 또한, BatchScaleDownPolicy는 요구되는 디바이스(들)(703)의 수를 하나씩 감소시키는 조작("ScalingAdjustment" : "-1")이 실행되도록 지정된다.
명칭이 BatchAutoScalingGroup인 오토-스케일링 그룹과 관련된 모니터링 및 통지는 159번째 라인으로부터 184번째 라인에 지정된다. BatchOueueAlarmHigh에서, 메시지의 수("NumberOfMessages")의 평균은 "BatchQueue"에 대해 모니터링 항목(MetricName)으로서 모니터링되도록 설정된다. 따라서, AlarmAction에서 지정된 명칭이 "BatchScaleUpPolicy"인 오토-스케일링 폴리시는, 메시지의 수의 평균이 300초 간격으로 2회 역치값인 100을 초과하는 경우 수행되도록 설정된다.
도 10은 본 예시적 실시예에 따라 운영 환경을 전환하기 위한 처리의 흐름을 도시하는 흐름도이다. 리소스 매니저(303)는 운영 환경을 전환하기 위한 처리를 수행한다.
단계 S1001에서, 리소스 매니저(303)는 시스템 매니저(300)로부터의 지시에 응답하여 그린 환경(350)에서의 리소스 양을 조정하기 위한 처리를 시작한다. 단계 S1002에서, 리소스 매니저(303)는 전환 대상인 블루 환경(330) 및 그린 환경(350)를 지정하는 입력을 시스템 관리자로부터 수신한다. 시스템 관리자는 컴퓨터(110)를 조작하여 전환 대상인 블루 환경(330) 및 그린 환경(350)을 지정하고, 전환 유닛(405)은 블루 환경(330) 및 그린 환경(350)을 지정하는 이러한 입력을 포함하는 요청을 수신한다.
블루 환경(330) 및 그린 환경(350)을 지정하기 위한 방법으로서, 시스템 관리자는 블루 환경(330) 또는 그린 환경(350)의 각각의 스택 ID(801)를 지정할 수 있거나, 또는 그 태그의 키(Key) 및 값(Value)으로 블루 환경(330) 및 그린 환경(350)을 특정할 수 있다. 키는 태그의 속성이고, 값은 상기 속성의 값이다. 시스템 관리자가 스택 ID(801)과 함께 블루 환경(330) 및 그린 환경(350)을 지정한 경우, 시스템 관리자는 예컨대, 블루 환경(330) 및 그린 환경(350)의 스택 ID(801)로서 각각 S01 및 S02를 지정함으로써 블루 환경(330) 및 그린 환경(350)을 지정한다. 시스템 관리자는 복수의 스택을 한번에 지정할 수 있다. 시스템 관리자가 태그를 지정하는 경우, 시스템 관리자는 "Version"을 나타내는 키를 이용하여 태그를 식별하고, 예컨대, 블루 환경(330) 및 그린 환경(350) 각각에 대해 "100" 및 "101"을 지정함으로써 블루 환경(330) 및 그린 환경(350)을 지정한다.
이하에서, 본 흐름도는 예로서, 블루 환경(330)의 키 및 그린 환경(350)의 키에 대해 "100" 및 "101"이 각각 설정된 것으로 상정하여 설명될 것이다. 또한, 이 경우, 오토-스케일링 그룹, 가상 머신 및 서버 구성 요소가 속하는 스택의 ID가 오토-스케일링 관리 ID(701), 스택 ID(801) 등을 나타내는 문자열의 헤드로부터 취득될 수 있다.
단계 S1003에서, 전환 유닛(405)은 오토-스케일링 관리 유닛(403)으로부터 지정된 블루 환경(330) 및 그린 환경(350) 내의 오토-스케일링 상태에 관한 정보를 취득한다. 그린 환경(350)에 대한 정보로서, "Version" 속성은 "101"로 지시된다. 이때, 전환 유닛(405)은 오토-스케일링 상태 관리 테이블(도 7)로부터 태그(707)(레코드(715 내지 718)) 내에서 ("Version" : "101")을 포함하는 리소스 양의 조정에 관한 정보를 취득한다. 전환 유닛(405)은 지정된 블루 환경(330)에 대한 정보만을 취득할 수 있다. 또한, 블루 환경(330) 및 그린 환경(350)에 관한 정보는 관리 시스템(100) 내의 데이터베이스(302)에 저장될 수 있거나 또는 관리 시스템(100) 외부에 준비된 스토리지 디바이스에 저장될 수 있다.
후속하여, 리소스 매니저(303)는 그린 환경(350) 내의 서버 구성 요소 및 오토-스케일링 그룹 각각에 대해 단계 S1004 내지 단계 S1007의 처리를 반복한다. 단계 S1007에서, 처리는 오토-스케일링 그룹 및 서버 구성 요소 모두에서의 처리가 완료될 때 루프를 빠져나간다.
단계 S1005에서, 전환 유닛(405)은 오토-스케일링 폴리시를 기초로 자동 조정 기능을 무효화한다. 무효화되는 자동 조정 기능은 스케일링-인 또는 스케일링-다운을 규정하는 오토-스케일링 폴리시를 기초로 하는 자동 조정 기능만일 수 있다. 스케일링-인의 대상으로서 취득되는 오토-스케일링 폴리시는 오토-스케일링의 설정에서 추가 또는 삭제되는 가상 머신의 수(ScalingAdjustment)로서 음의 값을 지정하는 오토-스케일링 폴리시이다. 자동 조정 기능을 무효화하는 타이밍은 단계 S1005에 제한되지 않으며, 그린 환경(350)의 생성으로부터 그린 환경(350)에서의 리소스 양을 조정하기 위한 처리의 시작까지의 기간 동안의 임의 타이밍일 수 있다.
운영 환경이 블루 환경(330)에서 그린 환경(350)으로 전환되면, 그린 환경(350) 내의 가상 머신의 수가 증가되어야 하거나 및/또는 그린 환경(350) 내의 서버 구성 요소(들)이 약간의 로드만이 그린 환경(350)에 부여되는 상태에서 스케일 업되어야 한다. 스케일링-인을 규정하는 오토-스케일링 폴리시를 무효화하는 것은 그린 환경(350)에서 리소스가 증가된 후에 스케일링-인을 호출하는 알람이 생성되는 것을 방지하며, 따라서 그린 환경(350) 내의 가상 머신의 수가 감소되는 것을 방지하고 및/또는 그린 환경(350) 내의 서버 구성 요소(들)이 스케일 다운되는 것을 방지한다. 또한, 전환 유닛(405)은 오토-스케일링 폴리시가 오토-스케일링 그룹에 적용될 때 미리정해진 특정 기간 동안 무효화되도록 오토-스케일링 그룹에 대한 오토-스케일링 폴리시의 적용을 설정하도록 구성될 수도 있다.
후속하여, 단계 S1006에서, 리소스 생성 유닛(401)은 그린 환경(350) 내의 리소스 양을 조정하기 위한 처리를 수행한다. 그린 환경(350) 내의 리소스 양을 조정하기 위한 처리는 도 11a를 참조하여 후술될 것이다.
이러한 처리가 단계 S1007에서 모든 오토-스케일링 그룹 및 서버 구성 요소에 대해 완료된 경우, 처리는 단계 S1008로 진행한다.
단계 S1008에서, 전환 유닛(405)은 블루 환경(330)으로부터 그린 환경(350)으로 운영 환경을 전환하기 위한 처리를 수행한다. 전환 유닛(405)은 전환 유닛(405)을 설명하는 단락에서 상술된 방법에 의해 운영 환경을 전환한다. 특히, 운영 환경을 전환하기 위한 처리는 예컨대, 블루 환경(330)을 나타내는 레코드로부터 그린 환경(350)을 나타내는 레코드로 DNS(301) 내의 레코드를 변경하는 처리를 의미한다. 이 처리로 인해, 외부 네트워크로부터 전송된 요청을 수신 및 처리하는 운영 환경의 전환이 이루어진다. 또한, 운영 환경을 전환한 후에, 전환 유닛(405)은 단계 S1005에서 무효화된 자동 조정 기능을 활성화한다(enables).
도 11a는 본 예시적 실시예에 따른 그린 환경(350) 내에서의 리소스 양을 조정하기 위한 처리의 흐름을 도시하는 흐름도이며, "요구되는 디바이스의 수의 적용'을 기초로 하는 이행 방법을 이용하여 그린 환경(350) 내의 리소스 양을 조정하기 위한 처리의 흐름을 도시한다. 그린 환경(350) 내의 리소스 양을 조정하기 위한 처리는 그린 환경(350) 내의 서버 구성 요소 및 오토-스케일링 그룹 각각에 대해 수행된다.
"요구되는 디바이스의 수의 적용"은 블루 환경(330)에서 요구되는 가상 머신의 수를 그린 환경(350)에 적용하는 이행 방법을 의미한다. 단계 S1101 내지 단계 S1104에서, 리소스 매니저(303)는 "요구되는 디바이스의 수의 적용"을 기초로 하는 이행 방법에 의해 그린 환경(350) 내의 리소스 양을 조정하기 위한 처리를 수행한다. 상기 "요구되는 디바이스의 수의 적용"은 예컨대, 복수의 가상 머신을 포함하는 오토-스케일링 그룹에 대한 적용의 경우에 적합하다.
단계 S1102에서, 전환 유닛(405)은 "Role" 속성의 값이 반복 대상인 오토-스케일링 그룹, 서버 구성 요소 등에 설정된 값과 동일한 블루 환경(330)에서 서버 구성 요소 또는 오토-스케일링 그룹의 요구되는 디바이스의 수(703)를 취득한다.
전환 유닛(405)은 오토-스케일링 관리 유닛(403)으로부터, 블루 환경(330)을 나타내는 태그("Version" 속성이 "100")가 태그(707) 내에 포함되고 "Role" 속성의 값이 동일한 오토-스케일링 그룹 또는 서버 구성 요소를 검색한다. 예컨대, 오토-스케일링 그룹(S02_WebAutoScalingGroup)의 경우에, "Role" 속성의 값은 "Web"이다. 따라서, 전환 유닛(405)은, ("Role" : "Web") 및 ("Version" : "100")이 태그(707) 내에 포함되고 동일한 유형이 유형(702)에 지정되는 행(711)에서 S01_WebAutoScalingGroup을 선택한다. 전환 유닛(405)은 S01_WebAutoScalingGroup의 요구되는 디바이스의 수(703)의 값인 "5"를 취득한다.
후속하여, 단계 S1103에서, 리소스 생성 유닛(401)은 그린 환경(350) 내의 서버 구성 요소 또는 오토-스케일링 그룹에 대해 리소스 양을 조정한다. 예컨대, "5"는 오토-스케일링 그룹(S02_WebAutoScalingGroup)(레코드(715))의 요구되는 디바이스의 수(703)로 설정된다. 더욱 구체적으로는, 그린 환경(350) 내의 오토-스케일링 그룹 또는 서버 구성 요소의 요구되는 디바이스의 수(703)는 단계 S1102에서 취득된, 블루 환경(330) 내의 오토-스케일링 그룹 또는 서버 구성 요소의 요구되는 디바이스의 수를 기초로 설정된다. 오토-스케일링 관리 유닛(403)은, 오토-스케일링 그룹(S02_WebAutoScalingGroup)의 동작하는 디바이스의 수(= 2)가 요구되는 디바이스의 수(= 5)와 일치하지 않는다는 것을 검출한다. 따라서, 오토-스케일링 관리 유닛(403)은, 오토-스케일링 그룹이 속한 스택(S02) 내의 WebAutoScalingGroup에 대한 가상 머신(352)의 기동 설정(WebLaunchConfig)에 따라 생성된 가상 머신(352)을 오토-스케일링 그룹에 추가한다. 블루 환경(330)에서 요구되는 디바이스의 수(703)가 그린 환경(350)에 적용됨으로써, 동작하는 디바이스의 수(704)가 최종적으로 "5"에 도달한다.
블루 환경(330)에서 요구되는 디바이스의 수(703)는, 그것이 정확하게 블루 환경(330)에서 요구되는 디바이스의 수(703)인 것으로서 그린 환경(350)에 적용될 필요는 없다. 예컨대, 그린 환경(350)에서 요구되는 디바이스의 수(703)는 그린 환경(350) 내의 가상 머신의 상세(705)를 나타내는 정보 및 블루 환경(330) 에서 요구되는 디바이스의 수(703)를 기초로 설정될 수 있다.
동작에 착수한 가상 머신의 수는 현재 운영 환경의 역할을 하는 블루 환경(330)이 약간의 여유를 포함하는 넉넉한 처리 용량을 갖게 하기 위해, 블루 환경(330)에 부가된 로드를 처리하기 위해 요구되는 디바이스의 수보다 클 수 있다. 이 경우, 전환 유닛(405)은 이를 고려하여 그린 환경(350) 내의 요구되는 디바이스의 수(703)를 설정할 수 있다.
시스템 매니저(300)는, 운영 환경이 전환되기 전 미리정해진 기간 동안 블루 환경(330)에 의해 수신된 요청의 양을 기초로 운영 환경이 전환될 때의 요청의 양을 예측할 수 있다. 예컨대, 시스템 매니저(300)는 단위 시간 당 요청의 수를 나타내는 그래프를 이용하여, 블루 환경(330)에서의 리소스 양의 조정에 관한 정보를 취득할 때 요청 양의 증가 또는 감소를 나타내는 기울기를 산출한다. 시스템 매니저(300)는 블루 환경(330) 내의 요구되는 디바이스의 수 외에도 요청 수의 증가 또는 감소를 추가로 고려하여 그린 환경(350) 내의 요구되는 디바이스의 수를 결정할 수 있다. 동일한 사항이 후술되는 적용 예에 적용된다.
단계 S1104에서, 처리는 도 10의 흐름도로 복귀되고 다음 단계로 진행한다.
본 예시적 실시예에서, 운영 환경이 제1 처리 시스템으로부터 제2 처리 시스템으로 전환되기 전에, 운영 환경이 전환되는 처리 시스템인 제2 처리 시스템 내의 가상 머신의 수는 제1 처리 시스템 내의 가상 머신의 수와 일치하도록 조정된다. 본 예시적 실시예는 운영 환경이 전환될 때 제2 처리 시스템이 요청 처리를 늦게 처리하는 것을 방지할 수 있다.
제2 예시적 실시예는 제1 예시적 실시예와 기본적으로 유사하며, 따라서 이 실시예들 간의 차이점만이 설명될 것이다. 단계 S1006에서의 그린 환경(350) 내의 리소스 양을 조정하기 위한 처리에 있어서, "요구되는 디바이스의 수의 적용"을 기초로 하는 이행 방법이 제1 예시적 실시예에서 사용되었지만, 본 예시적 실시예에서는 "로드 상태의 적용"을 기초로 하는 이행 방법이 사용된다. 본 예시적 실시예에서, 모니터링된 요청의 양 또는 모니터링된 처리 로드를 나타내는 정보가 그린 환경(350)에서의 리소스 양을 조정하기 위한 처리에 사용된다.
도 11b는 본 예시적 실시예에 따른 그린 환경(350) 내의 처리의 흐름을 도시하는 흐름도로서, "로드 상태의 적용"을 기초로 하는 이행 방법에 의해 그린 환경(350) 내의 리소스 양을 조정하기 위한 처리의 흐름의 일 예를 도시한다. 그린 환경(350) 내의 리소스 양을 조정하기 위한 처리는 그린 환경(350) 내의 오토-스케일링 그룹 및 서버 구성 요소의 각각에 대해 수행된다.
"로드 상태의 적용"은 블루 환경(330) 내의 로드 상태를 나타내는 정보를 그린 환경(350)에 적용하는 이행 방법을 의미한다. 단계 S1111 내지 단계 S1115에서, 리소스 매니저(303)는 "로드 상태의 적용"을 기초로 하는 이행 방법에 의해 그린 환경(350)에서의 리소스 양을 조정하기 위한 처리를 수행한다. "로드 상태의 적용"은 서버 구성 및/또는 가상 머신의 상세 등과 관련하여 블루 환경(330)과 그린 환경(350) 사이에 차이가 존재하는 경우와 같이 블루 환경(330) 내의 요구되는 디바이스의 수(703)를 그 자체로 적용하는 방법을 이용하는 것이 적절하지 않은 경우에 적합하다. "로드 상태의 적용"은 또한 요구되는 디바이스의 수(703)를 나타내는 정보가 취득될 수 없다 경우 이용될 수 있다.
단계 S1112에서, 전환 유닛(405)은 블루 환경(330) 내의 오토-스케일링 그룹 또는 서버 구성 요소의 로드 상태를 나타내는 정보를 취득한다.
예컨대, 오토-스케일링 그룹(S02_WebAutoScalingGroup)의 경우에, 그와 관련된 오토-스케일링 폴리시는 WebScaleUpPolicy 및 WebScaleDownPolicy이다. 또한, 그와 관련된 모니터링 조건은 WebCPUAlarmHigh 및 WebCPUAlarmLow이며, 전환 유닛(405)은 이러한 2개의 모니터링 조건을 검색한다. R14에 의해 식별되는 큐(353)의 경우에, 2개의 모니터링 조건(S02_BatchQueueAlarmHigh 및 S02_BatchQueueAlarmLow)이 그와 관련된다. 전환 유닛(405)은, "Role" 속성의 값이 상기 모니터링 조건들 하에서 모니터링되는 리소스(602)로서 지정된 리소스와 동일한 블루 환경(330)의 서버 구성 요소 또는 오토-스케일링 그룹의 오토-스케일링 상태에 관한 정보를 취득한다.
예컨대, R14에 의해 식별되는 큐(353)의 경우에, "Role" 속성의 값은 리소스 정보 관리 테이블(도 5) 내의 레코드(522)를 참조하여 R14의 태그 정보로부터 "Batch"인 것으로 인식될 수 있다. 전환 유닛(405)은 행(514) 내에 배치되는 R04가 "Role" 속성의 값이 "Batch"인 블루 환경(330) 내의 큐(333)이라는 것을 발견하고 R04의 로드 상태(NumberOfMessages)를 취득한다.
후속하여, 단계 S1113에서, 전환 유닛(405)은 그린 환경(350) 내의 리소스 양이, 단계 S1112에서 취득된 처리 로드 및 요청의 양과 같은 블루 환경(330) 내의 로드 상태를 나타내는 정보를 기초로 조정되어야 하는지를 결정한다.
예컨대, R14에 의해 식별되는 큐(353)의 경우에, 전환 유닛(405)은 조건(S02_BatchQueueAlarmHigh 또는 S02_BatchQueueAlarmLow)이 R04에 의해 식별되는 큐(333)의 로드 상태를 기초로 만족되는지를 판정한다. 관리 시스템(100)이 지정된 간격으로 복수회 로드 상태를 측정하도록 설정된 경우, 전환 유닛(405)은 복수회 로드 상태를 측정하도록 구성될 수 있거나 또는 로드 상태를 한번 측정으로 대체하도록 구성될 수도 있다. 운영 환경이 전환될 때에만 참조되는 오토-스케일링 폴리시가 준비될 수 있다.
그린 환경(350) 내의 리소스 양이 조정되어야 한다고 전환 유닛(405)이 판정하는 경우(단계 S1113에서 "예"), 처리는 단계 S1114로 진행한다. 이후, 리소스 생성 유닛(401)은 그린 환경(350) 내의 리소스 양을 조정한다. 한편, 그린 환경(350) 내의 리소스 양이 조정될 필요가 없다고 전환 유닛(405)이 판정한 경우(단계 S1113에서 "아니오"), 처리는 단계 S1115로 진행한다.
단계 S1115에서, 처리는 도 10의 흐름도로 복귀한 후, 다음 단계로 진행한다.
그린 환경(350)이 약간의 여유가 블루 환경(330)의 처리 용량에 추가되는 넉넉한 처리 용량을 갖는 방식으로, 리소스 매니저(303)는 그린 환경(350) 내의 요구되는 디바이스의 수(703) 및/또는 상세(705)를 설정할 수 있다.
오토-스케일링 그룹의 경우에, 리소스 매니저(303)는 로드 상태가 단계 S1113에서 상한에 도달한 것과 관련된 모니터링 조건과 관련되는 오토-스케일링 폴리시를 기초로 요구되는 디바이스의 수(703) 등을 설정한다. 이때, 리소스 매니저(303)는 블루 환경(330) 내에서 로드 밸런서(331)에 의해 수신된 요청의 양과 그린 환경(350) 내에서 처리될 수 있는 요청의 양이 서로 일치하는 방식으로 요구되는 디바이스의 수(703)를 설정한다. 시스템 관리자는 예컨대, 큐와 같은 매니지드 서비스로서 제공되는 서버 구성 요소로 인해 오토-스케일링의 설정을 지정할 수 없을 수 있다. 이 경우, 리소스 매니저(303)는 요구되는 디바이스의 수 및/또는 상세를 산출하여, 이들을 오토-스케일링 관리 유닛(403) 내에서 관리되는 설정을 기초로 서버 구성 요소에 적용한다. 시스템 매니저(300)는 운영 환경이 전환되기 전 미리정해진 기간 동안 블루 환경(330)에 의해 수신된 요청의 양을 기초로 운영 환경이 교체될 대의 요청의 양을 예측할 수 있다. 시스템 매니저(300)는 블루 환경(330)에서 로드 밸런서(331)에 의해 수신된 요청의 양 이외에, 요청 양의 증가 또는 감소를 추가로 고려하여 그린 환경(350)에 의해 처리될 수 있는 것으로 예측되는 요청의 양을 결정할 수 있다. 동일한 사항이 후술될 적용예에도 적용된다.
본 예시적 실시예에서, 운영 환경이 제1 처리 시스템으로부터 제2 처리 시스템으로 전환되기 전에, 제2 처리 시스템 내의 리소스 양은 제1 처리 시스템 내의 로드 상태를 나타내는 정보를 이용하여 증가된다. 제2 처리 시스템이 운영 환경으로서 작용할 때 수행될 수 있도록 설정되는 오토-스케일링에 의한 리소스 양을 조정하는 처리는 제2 처리 시스템 내의 리소스 양을 증가시키기 위한 방법으로서 수행될 수 있다. 대안적으로는, 다른 방법으로서, 운영 환경을 전환하기 위한 처리를 실행할 때 수행되도록 리소스 양을 조정하기 위한 처리가 미리 설정될 수 있으며, 그리고 그 리소스 양을 조정하기 위한 처리가 수행될 수 있다. 본 예시적 실시예는 서버 구성 및/또는 가상 머신의 상세 등과 관련하여 제1 처리 시스템과 제2 처리 시스템 사이에 차이가 존재하는 경우에도, 운영 환경을 전환할 때 제2 처리 시스템이 요청의 처리를 늦게 실행하는 것을 방지할 수 있다.
제3 예시적 실시예는 제1 예시적 실시예와 기본적으로 유사하며, 따라서 이 예시적 실시예들 사이의 차이점만이 설명될 것이다. 단계 S1006에서 수행되는 그린 환경(350) 내의 리소스 양을 조정하는 처리에 있어서, "최후에 실행된 조작의 적용"을 기초로 하는 이행 방법이 본 예시적 실시예에서 이용되는 반면에, 제1 예시적 실시예에서는 "요구되는 디바이스의 수의 적용"을 기초로 하는 이행 방법이 이용되고, 제2 예시적 실시예에서는 "로드 상태의 적용"을 기초로 하는 이행 방법이 이용된다. 본 예시적 실시예에서, 블루 환경(330)에서 최후에 실행된 리소스 양을 조정하기 위한 처리는 또한 블루 환경(330)에서의 리소스 양의 조정과 관련한 정보를 취득할 때 그린 환경(350)에서 수행된다.
도 11c는 본 예시적 실시예에 따른 그린 환경(350) 내의 처리의 흐름을 도시하는 흐름도로서, "최후에 실행된 조작의 적용"을 기초로 하는 이행 방법에 의해 그린 환경(350) 내의 리소스 양을 조정하기 위한 처리의 흐름의 일 예를 도시한다. 그린 환경(350)에서의 리소스 양을 조정하기 위한 처리는 그린 환경(350)에서의 오토-스케일링 그룹 및 서버 구성 요소 각각에 대해 수행된다.
"최후에 실행된 조작의 적용"은 그린 환경(350) 내에서 그에 대응하는 서버 구성 요소 등에, 블루 환경(330) 내의 서버 구성 요소 등에서 최후에 실행된 조작으로서 보유되는 제어 명령을 수행함으로써 블루 환경(330) 내에서 최후에 실행된 조작을 적용하는 이행 방법을 의미한다. 단계 S1121 내지 단계 S1124에서, 리소스 매니저(303)는 "최후에 실행된 조작의 적용"을 기초로 하는 이행 방법에 의해 그린 환경(350) 내에서의 리소스 양을 조정하기 위한 처리를 수행한다. "최후에 실행된 조작의 적용"은 예컨대, 요구되는 디바이스의 수를 나타내는 정보와 로드 상태를 나타내는 정보가 취득될 수 없는 경우에도 이용될 수 있다.
단계 S1122에서, 전환 유닛(405)은 "Role" 속성이 동일한 블루 환경(330)에서의 서버 구성 요소에 대해 최후에 실행된 동작(706)을 취득한다. 단계 S1122에서의 취득 시, 최후에 실행된 조작(706)은 블루 환경(330) 내의 서버 구성 요소 상에서 최후에 실행된 리소스 양을 조정하기 위한 처리이다. 전환 유닛(405)은 "Role" 속성의 값이 반복 대상인 오토-스케일링, 서버 구성 요소 등에 대해 설정된 값과 동일한 블루 환경(330)에서의 서버 구성 요소 또는 오토-스케일링 그룹의 최후에 실행된 조작(706)을 취득한다. 전환 유닛(405)은 블루 환경(330)을 나타내는 태그("Version" 속성이 "100")가 태그(707) 내에 포함되고 "Role" 속성의 값이 동일한 오토-스케일링 그룹 또는 서버 구성 요소를 검색한다.
예컨대, R11에 의해 식별되는 로드 밸런서(351)의 경우에, "Role" 속성의 값이 "Web"이기 때문에, 전환 유닛(405)은, ("Role" : "Web") 및 ("Version" : "100")이 태그(707) 내에 포함되고 동일 유형이 유형(702) 내에서 지정되는 행(712) 내에서 R01에 의해 식별되는 로드 밸런서(331)를 선택한다. 이후에, 전환 유닛(405)은 R01의 최후에 실행된 조작(706)의 값인 ("Change Type = Medium")을 취득한다.
후속하여, 단계 S1123에서, 오토-스케일링 관리 유닛(403)은 그린 환경(350)에서의 오토-스케일링 그룹, 서버 구성 요소 등에 대한 오토-스케일링 기능의 동일한 설정의 조작을 수행한다.
예컨대, 오토-스케일링 관리 유닛(403)은 R11에 의해 식별되는 로드 밸런서(351) 상에, 단계 S1122에서 취득된 정보인 최후에 실행된 조작(706)("Change Type = Medium")을 수행한다. 이 조작에 응답하여, R11에 의해 식별된 로드 밸런서(351)는 그 내부에 포함된 가상 머신의 수를 증가시키는 것과 같은 오토-스케일링을 수행한다.
단계 S1124에서, 처리는 도 10의 흐름도로 복귀한 후에 다음 단계로 진행한다.
시스템 매니저(300)는 운영 환경이 전환되기 전 미리정해진 기간 동안 블루 환경(330)에 의해 수신되는 요청의 양을 기초로, 운영 환경이 교체될 때의 요청의 양을 예측할 수 있다. 시스템 매니저(300)는 블루 환경(330)에서의 최후에 실행된 리소스 양을 조정하기 위한 처리 이외에, 요청 양의 증가 또는 감소를 추가로 고려하여 그린 환경(350)에서의 리소스 양을 조정하기 위한 처리를 수행할 수 있다. 동일한 사항이 후술되는 적용예에 적용될 수 있다.
본 예시적 실시예에서, 제1 처리 시스템에서 최후에 실행된 리소스 양을 조정하기 위한 처리와 동일한 조작이 운영 환경을 전환하라는 지시에 따라 제2 처리 시스템에서 수행된다. 본 예시적 실시예는, 가상 머신의 수를 나타내는 정보와 로드 상태를 나타내는 정보가 취득될 수 없을 때에도, 제2 처리 시스템이 운영 환경을 전환할 때 요청을 늦게 처리하는 것을 방지할 수 있다.
<적용예 1>
단계 S1006에서의 그린 환경(350) 내의 리소스 양을 조정하기 위한 처리에 있어서, 전환 유닛(405)은 제1 예시적 실시예 내지 제3 예시적 실시예에 따른 이행 방법 중 어느 이행 방법이 이용되어야 하는지를 지정하는 스택 템플릿 내에 규정된 임의의 설정에 따라 전환을 제어할 수 있다. 이 설정은 처리 시스템 내에서 모든 오토-스케일링 그룹 및 서버 구성 요소 사이에 공유될 수 있다. 본 예시적 실시예는 상기 이행 방법이 오토-스케일링 그룹 및 서버 구성 요소 각각에 대해 설정되는 것을 상정하여 설명될 것이다.
도 12는 본 예시적 실시예에 따른 스택 템플릿의 일 예를 도시하며, 이행 방법은 본원에 기재된다. 운영 환경이 블루 환경(330)과 그린 환경(350) 사이에서 전환될 때의 오토-스케일링 상태에 관한 정보를 반영하는 동작의 설정은 186번째 라인으로부터 199번째 라인에 지정된다.
운영 환경이 전환될 때 그린 환경(350) 내의 리소스 양을 조정하기 위한 처리 시점에서 이행 방법에 관한 설정은 186번째 라인으로부터 199번째 라인에 지정된다. 예컨대, 이 설정은 전환 유닛(405)이 운영 환경을 전환하라는 지시를 수신할 때 참조된다.
상기 설정의 예로서, "Web"이 "Role"을 나타내는 키를 갖는 속성의 값으로 지정되는 오토-스케일링 그룹에 대한 동작이 187번째 라인으로부터 193번째 라인에 설정된다. "요구되는 디바이스의 수의 적용"("CopyDesiredCapacity")이 이행 방법(MigrateMethod)으로 지정된다.
전환 유닛(405)은 그린 환경(350) 내에서의 리소스 양을 조정하기 위한 처리를 위해 참조되는 블루 환경(330)에 대한 정보를 선택하여, 이행 방법을 설정한다. 우선, 전환 유닛(405)은 반복 대상인 오토-스케일링 그룹 또는 서버 구성 요소에 대해 그린 환경(350)을 위한 스택 템플릿 내에 지정된 이행 방법과 합치하는 오토-스케일링 그룹 또는 서버 구성 요소를 검색한다. 전환 유닛(405)은 스택 수용 유닛(404)으로부터 그린 환경(350)을 위한 스택 템플릿을 취득한다.
오토-스케일링 정보(715) 내의 오토-스케일링 그룹 "S02_WebAutoScalingGroup"은 그 값이 "Web"으로 설정되는 "Role"속성을 가지며, 스택 템플릿 내의 187번째 라인으로부터 193번째 라인에 지정된 제1 이행 설정과 합치한다. 따라서, 이 이행 방법은 "요구되는 디바이스의 수의 적용"이다. 전환 유닛(405)은 스택 템플릿을 참조하지 않고 미리정해진 이행 방법을 채용하도록 구성될 수 있다.
상기 설정의 다른 예로서, "Batch"가 "Role"을 나타내는 키를 갖는 속성의 값으로 지정되는 오토-스케일링 그룹에 대한 동작이 194번째 라인으로부터 198번째 라인에 지정된다. 그 이행 방법(MigrateMethod)으로는 "설정 없음"("없음")이 지정된다.
리소스 매니저(303)는 블루 환경(330)에서의 가상 머신(332)의 요구되는 디바이스의 수(703)를 그린 환경(350)에서의 가상 머신(352)에 적용하지만, 블루 환경(330)에서의 가상 머신(334)의 요구되는 디바이스의 수(703)를 그린 환경(350)에서의 가상 머신(354)에 적용하지는 않는다. 가상 머신(332)은 웹 서버 등이며, 미리정해진 네트워크 시스템으로부터의 많은 수의 요청을 처리하여, 그린 환경(350) 내의 가상 머신(352)은 환경이 전환되기 전에 요구되는 디바이스의 수(703)만큼 준비되어야 한다. 하지만, 가상 머신(334)은 배치 서버 등이며 큐처리된 메시지를 수신한 후에 처리하여, 가상 머신(354)의 수는 단지 그린 환경(350) 내의 오토-스케일링 기능에 의해 증가되어야 한다. 이는 미리정해진 네트워크 시스템으로부터의 요청 수와의 동기화에 있어서 큐처리된 메시지의 수가 증가하지 않기 때문이다. 따라서, 그린 환경(350) 내에서의 가상 머신(354)의 수는 운영 환경이 전환되기 전에 증가될 필요가 없다.
194번째 라인 내지 198번째 라인에 지정된 설정은, 처리 시스템이 전환될 때 시스템 관리자가 배치 서버의 서버 요금을 절약할 수 있게 한다.
오토-스케일링 그룹 또는 서버 구성 요소가 스택 템플릿 내에 지정된 이행 방법과 합치하지 않는 경우, 전환 유닛(405)은 도 13을 참조하여 서버 구성 요소 및 가상 머신과 같은 각각의 유형에 대해 지정된 이행 방법을 설정한다.
도 13은 본 예시적 실시예에 다른 서버 구성 요소의 유형에 의해 지정되는 이행 방법을 나타내는 테이블의 일 예를 도시한다. 전환 유닛(405)은 이행 방법에 관한 정보, 예컨대 레코드(1311, 1312)에 의해 지시되는 정보를 관리한다. 유형(1301)은 가상 머신 및 서버 구성 요소와 같은 유형을 나타내며, 이행 방법(1302)은 유형별로 지정된 이행 방법을 나타낸다. 예컨대, 리소스 ID(501)로서 R11에 의해 식별되는 로드 밸런서(351)를 위한 이행 방법을 결정할 때, 전환 유닛(405)은 도 13에 도시된 행(1311)을 참조하고, 이행 방법으로 "최후에 실행된 조작의 적용"을 이용할 것을 결정한다. 한편, R14에 의해 식별되는 큐(353)의 경우에, 전환 유닛(405)은 행(1312)을 참조하고, 이행 방법으로 "로드 상태의 적용"을 이용하도록 결정한다. 이행 방법이 결정될 수 없는 경우, 전환 유닛(405)은 이행 방법을 "없음"으로 설정한다.
본 예시적 실시예는 이상 방법이 처리 시스템 내에 포함된 리소스의 각 그룹에 대해 설정되는 것을 가능하게 하며, 리소스 양을 조정하기 위한 처리가 운영 환경이 전환될 때 각 그룹에 대해 설정되는 이행 방법에 따라 수행될 수 있게 한다.
<적용예 2>
도 10 및 도 11a 내지 도 11c의 흐름도에 도시된 처리의 일부가 리소스 매니저(303) 대신에 시스템 매니저(300)에 의해 수행될 수 있다.
도 10에 도시된 단계 S1008에서, 운영 환경은 그린 환경(350) 내의 리소스 양이 실제로 조정된 후에 블루 환경(330)으로부터 그린 환경(350)으로 전환된다. 리소스 양이 실제로 조정될 때까지, 시스템 매니저(300)는 리소스 매니저(303)의 리소스 생성 유닛(401)에 리소스 양을 조정하기 위한 지시를 내린다. 따라서, 예컨대, 시스템 매니저(300)는 동작하는 디바이스의 수(704)가 도 7에 도시된 요구되는 디바이스의 수(703)와 일치한다는 것을 확인한 후에 운영 환경을 전환하라는 지시를 내린다.
또한, 그린 환경(350) 내의 리소스 양이 전환 지시가 내려진 후에 조정되는 시기는 운영 환경이 실제로 전환된 직후일 수 있다. 하지만, 그린 환경(350) 내의 리소스의 양은 오토-스케일링에 의해 제 시간에 조정되어야 한다.
다른 실시예
또한, 본 발명의 실시예(들)는 상술된 실시예 중 하나 이상의 기능을 수행하기 위해 (더욱 완전하게는 '비-일시적 컴퓨터-판독 가능 기억 매체'로 지칭될 수 있는) 기억 매체 상에 기록된 컴퓨터 실행 가능 지시(예컨대, 하나 이상의 프로그램)를 독출 및 실행하고 상술된 실시예(들) 중 하나 이상의 기능을 수행하기 위한 하나 이상의 회로(예컨대, 주문형 반도체(application specific integrated circuit(ASIC))를 포함하는 시스템 또는 장치의 컴퓨터에 의해, 그리고 예컨대 상술된 실시예(들) 중 하나 이상의 기능을 수행하기 위해 저장 매체로부터 컴퓨터 실행 가능한 지시를 독출 및 실행하고 및/또는 상술된 실시예(들) 중 하나 이상의 기능을 수행하도록 하나 이상의 회로를 제어함으로써 상기 시스템 또는 장치의 컴퓨터에 의해 수행되는 방법에 의해 구현될 수 있다. 컴퓨터는 하나 이상의 프로세서(예컨대, 중앙 처리 유닛(CPU), 마이크로 처리 유닛(MPU))를 포함할 수 있으며, 컴퓨터 실행 가능 지시를 독출 및 실행하기 위해 개별 컴퓨터 또는 개별 프로세서의 네트워크를 포함할 수 있다. 컴퓨터 실행 가능 지시는 예컨대, 네트워크 또는 저장 매체로부터 컴퓨터로 제공될 수 있다. 저장 매체는 예컨대, 하드 디스크, 랜덤 액세스 메모리(RAM), 판독 전용 메모리(ROM), 분산형 컴퓨팅 시스템의 스토리지, 광학 디스크(예컨대, 콤팩트 디스크(CD), 디지털 다목적 디스크(DVD) 또는 블루레이 디스크(BD)™), 플래시 메모리 디바이스, 메모리 카드 등 중 하나 이상을 포함할 수 있다.
(기타의 실시예)
본 발명은, 상기의 실시예의 1개 이상의 기능을 실현하는 프로그램을 네트워크 또는 기억 매체를 개입하여 시스템 또는 디바이스에 공급하고, 그 시스템 또는 디바이스의 컴퓨터에 있어서 1개 이상의 프로세서가 프로그램을 판독하여 실행하는 처리에서도 실현 가능하다.
또한, 1개 이상의 기능을 실현하는 회로(예를 들어,ASIC)에 의해서도 실행 가능하다.
본 발명이 예시적 실시예를 참조하여 설명되었지만, 본 발명은 기술된 예시적 실시예에 제한되지 않는다는 것이 이해되어야 한다. 후속하는 청구항의 범주는 그러한 변경 및 등가의 구조 및 기능 모두를 포함하도록 가장 광의의 해석에 따라야 한다.

Claims (20)

  1. 적어도, 요청을 처리하도록 각각 구성된 하나 이상의 가상 머신과, 상기 가상 머신(들)에 상기 요청을 분배하도록 구성된 로드 분배 디바이스를 각각 포함하는 복수의 처리 시스템을 포함하는 관리 시스템이며,
    미리정해진 네트워크 시스템으로부터 전송되는 상기 요청을 처리하는 처리 시스템을 상기 복수의 처리 시스템에 포함된 제1 처리 시스템으로부터 제2 처리 시스템으로 전환하기 위한 지시에 따라, 제1 처리 시스템에 대해 사용되는 리소스의 양의 조정과 관련된 정보를 취득하도록 구성된 취득 유닛과,
    상기 취득 유닛에 의해 취득된 상기 정보를 기초로 상기 제2 처리 시스템 내에서의 리소스의 양을 조정하기 위한 조정 지시로서 상기 제2 처리 시스템 내의 상기 가상 머신의 수를 증가시키기 위한 지시를 내리도록 구성된 조정 지시 유닛을 포함하고,
    상기 미리정해진 네트워크 시스템으로부터 전송된 상기 요청을 처리하는 상기 처리 시스템은 상기 조정 지시 유닛에 의해 내려진 조정 지시에 따라 상기 제1 처리 시스템으로부터 상기 제2 처리 시스템으로 전환되는, 관리 시스템.
  2. 제1항에 있어서,
    상기 제1 처리 시스템 및 상기 제2 처리 시스템은, 상기 요청을 처리하기 위한 상기 로드 분배 디바이스로부터의 요청을 수신하도록 구성된 하나 이상의 가상 머신을 포함하는 요청 처리 시스템과, 상기 요청 처리 시스템에 의해 처리되는 상기 요청에 대응하는 메시지를 처리하도록 구성된 하나 이상의 가상 머신을 포함하는 배치 처리 시스템을 각각 포함하고,
    상기 조정 지시 유닛은, 상기 취득 유닛에 의해 취득된 상기 정보를 기초로, 상기 제2 처리 시스템 내의 상기 배치 처리 시스템에 대해서가 아니라, 상기 제2 처리 시스템 내의 상기 요청 처리 시스템에 대해 조정 지시를 내리는, 관리 시스템.
  3. 제1항에 있어서,
    상기 조정 지시 유닛은, 상기 취득 유닛에 의해 취득된 상기 정보를 기초로 상기 제2 처리 시스템 내의 리소스의 양을 조정하기 위한 조정 지시로서 상기 제2 처리 시스템 내의 가상 머신(들)에 대한 하드웨어 리소스의 할당을 증가시키기 위한 지시를 추가로 내리는, 관리 시스템.
  4. 제1항에 있어서,
    상기 제1 처리 시스템 및 상기 제2 처리 시스템 각각에 의해 사용되는 리소스는 하나 이상의 서버 컴퓨터에 의해 제공되는, 관리 시스템.
  5. 제1항에 있어서,
    상기 미리정해진 네트워크 시스템으로부터 전송된 상기 요청을 처리하는 상기 처리 시스템이 상기 제1 처리 시스템으로부터 상기 제2 처리 시스템으로 전환된 후에, 수신된 요청의 양에 따라 상기 제2 처리 시스템 내의 리소스의 양을 감소시키기 위한 조정을 자동적으로 수행하는 조정 기능이 활성화되는, 관리 시스템.
  6. 제1항에 있어서,
    상기 취득 유닛에 의해 취득된 상기 정보는, 상기 제1 처리 시스템 내의 가상 머신의 수, 상기 제1 처리 시스템에 의해 수신된 요청의 양, 상기 제1 처리 시스템 내에서 최후에 실행된 조정을 나타내는 정보 중 하나 이상인, 관리 시스템.
  7. 제6항에 있어서,
    상기 처리 시스템은, 하나 이상의 가상 머신 및 하나 이상의 로드 분배 디바이스 중 하나 이상을 각각 포함하는 복수의 그룹으로 분할되어 관리되고,
    상기 관리 시스템은, 상기 제2 처리 시스템에 의해 사용되는 리소스의 그룹의 각각에 대해, 상기 제1 처리 시스템 내의 가상 머신의 수, 상기 제1 처리 시스템에 의해 수신된 상기 요청의 양 및 상기 제1 처리 시스템 내에서 최후에 실행된 조정을 나타내는 정보 중 어느 하나를, 상기 조정 지시 유닛에 의해 내려진 지시에 대해 사용되는 상기 제1 처리 시스템에 대한 정보로서 설정하도록 구성된 설정 유닛을 더 포함하고,
    상기 취득 유닛은, 상기 설정 유닛에 의해 구성된 설정에 따라, 상기 제1 처리 시스템 내의 가상 머신의 수, 상기 제1 처리 시스템에 의해 수신된 요청의 양, 상기 제1 처리 시스템 내에서 최후에 실행된 조정을 나타내는 정보 중 하나 이상을 취득하고,
    상기 조정 지시 유닛은, 상기 제2 처리 시스템에 의해 사용되는 리소스의 그룹의 각각에 대해, 상기 취득 유닛에 의해 취득된 정보를 기초로 상기 제2 처리 시스템 내에서의 리소스의 양을 조정하기 위한 조정 지시를 내리는, 관리 시스템.
  8. 제1항에 있어서,
    상기 제1 처리 시스템에 의해 수신된 상기 요청의 양 또는 상기 제1 처리 시스템 상에 부여된 요청 처리를 위한 로드를 나타내는 정보가 상기 취득 유닛에 의해 취득되는 경우, 상기 조정 지시 유닛은 취득된 상기 정보를 기초로 상기 제2 처리 시스템 내에서의 리소스의 양을 조정하기 위한 조정 지시를 내리는, 관리 시스템.
  9. 제1항에 있어서,
    상기 제1 처리 시스템에서 최후에 실행된 조정을 나타내는 정보가 상기 취득 유닛에 의해 취득되는 경우, 상기 조정 지시 유닛은 상기 제2 처리 시스템 내에서의 리소스의 양을 조정하기 위한 조정 지시로서 상기 취득 유닛에 의해 취득된 상기 정보에 의해 나타내지는 조정을 상기 제2 처리 시스템 내에서 수행하기 위한 지시를 내리는, 관리 시스템.
  10. 제1항에 있어서,
    상기 제1 처리 시스템 내의 가상 머신(들) 상에서 동작하는 애플리케이션의 버전 및 상기 제2 처리 시스템 내의 가상 머신(들) 상에서 동작하는 애플리케이션의 버전이 서로 상이한, 관리 시스템.
  11. 적어도, 요청을 처리하도록 각각 구성된 하나 이상의 가상 머신과, 상기 가상 머신(들)에 상기 요청을 분배하도록 구성된 로드 분배 디바이스를 각각 포함하는 복수의 처리 시스템을 포함하는 관리 시스템을 제어하기 위한 제어 방법이며,
    미리정해진 네트워크 시스템으로부터 전송되는 상기 요청을 처리하는 처리 시스템을 상기 복수의 처리 시스템에 포함된 제1 처리 시스템으로부터 제2 처리 시스템으로 전환하기 위한 지시에 따라, 제1 처리 시스템에 대해 사용되는 리소스의 양의 조정과 관련된 정보를 취득하는 단계와,
    상기 취득하는 단계에서 취득된 상기 정보를 기초로 상기 제2 처리 시스템 내에서의 리소스의 양을 조정하기 위한 조정 지시로서 상기 제2 처리 시스템 내의 상기 가상 머신의 수를 증가시키기 위한 지시를 내리는 단계를 포함하고,
    상기 미리정해진 네트워크 시스템으로부터 전송된 상기 요청을 처리하는 상기 처리 시스템은 상기 지시를 내리는 단계에서 내려진 조정 지시에 따라 상기 제1 처리 시스템으로부터 상기 제2 처리 시스템으로 전환되는, 제어 방법.
  12. 제11항에 있어서,
    상기 제1 처리 시스템 및 상기 제2 처리 시스템은, 상기 요청을 처리하기 위한 상기 로드 분배 디바이스로부터의 요청을 수신하도록 구성된 하나 이상의 가상 머신을 포함하는 요청 처리 시스템과, 상기 요청 처리 시스템에 의해 처리되는 상기 요청에 대응하는 메시지를 처리하도록 구성된 하나 이상의 가상 머신을 포함하는 배치 처리 시스템을 각각 포함하고,
    상기 조정 지시는, 상기 취득하는 단계에서 취득된 상기 정보를 기초로, 상기 제2 처리 시스템 내의 상기 배치 처리 시스템에 대해서가 아니라, 상기 제2 처리 시스템 내의 상기 요청 처리 시스템에 대해 내려지는, 제어 방법.
  13. 제11항에 있어서,
    상기 제2 처리 시스템 내의 가상 머신(들)에 대한 하드웨어 리소스의 할당을 증가시키기 위한 지시가, 상기 취득하는 단계에서 취득된 상기 정보를 기초로 상기 제2 처리 시스템 내의 리소스의 양을 조정하기 위한 조정 지시로서 추가로 내려지는, 제어 방법.
  14. 제11항에 있어서,
    상기 제1 처리 시스템 및 상기 제2 처리 시스템 각각에 의해 사용되는 리소스는 하나 이상의 서버 컴퓨터에 의해 제공되는, 제어 방법.
  15. 제11항에 있어서,
    상기 미리정해진 네트워크 시스템으로부터 전송된 상기 요청을 처리하는 상기 처리 시스템이 상기 제1 처리 시스템으로부터 상기 제2 처리 시스템으로 전환된 후에, 수신된 요청의 양에 따라 상기 제2 처리 시스템 내의 리소스의 양을 감소시키기 위한 조정을 자동적으로 수행하는 조정 기능이 활성화되는, 제어 방법.
  16. 제11항에 있어서,
    상기 취득하는 단계에서 취득된 상기 정보는, 상기 제1 처리 시스템 내의 가상 머신의 수, 상기 제1 처리 시스템에 의해 수신된 요청의 양, 상기 제1 처리 시스템 내에서 최후에 실행된 조정을 나타내는 정보 중 하나 이상인, 제어 방법.
  17. 제16항에 있어서,
    상기 처리 시스템은, 하나 이상의 가상 머신 및 하나 이상의 로드 분배 디바이스 중 하나 이상을 각각 포함하는 복수의 그룹으로 분할되어 관리되고,
    상기 제어 방법은, 상기 제2 처리 시스템에 의해 사용되는 리소스의 그룹의 각각에 대해, 상기 제1 처리 시스템 내의 가상 머신의 수, 상기 제1 처리 시스템에 의해 수신된 상기 요청의 양 및 상기 제1 처리 시스템 내에서 최후에 실행된 조정을 나타내는 정보 중 어느 하나를, 상기 지시를 내리는 단계에서 내려진 지시에 대해 사용되는 상기 제1 처리 시스템에 대한 정보로서 설정하는 단계를 더 포함하고,
    상기 제1 처리 시스템 내의 가상 머신의 수, 상기 제1 처리 시스템에 의해 수신된 요청의 양, 상기 제1 처리 시스템 내에서 최후에 실행된 조정을 나타내는 정보 중 하나 이상이 상기 설정하는 단계에서 구성된 설정에 따라 상기 취득하는 단계에서 취득되고,
    상기 지시를 내리는 단계에서, 상기 제2 처리 시스템에 의해 사용되는 리소스의 그룹의 각각에 대해, 상기 취득하는 단계에서 취득된 정보를 기초로 상기 제2 처리 시스템 내에서의 리소스의 양을 조정하기 위한 조정 지시가 내려지는, 제어 방법.
  18. 제11항에 있어서,
    상기 제1 처리 시스템에 의해 수신된 상기 요청의 양 또는 상기 제1 처리 시스템 상에 부여된 요청 처리를 위한 로드를 나타내는 정보가 상기 취득하는 단계에서 취득되는 경우, 상기 지시를 내리는 단계에서 상기 제2 처리 시스템 내에서의 리소스의 양을 조정하기 위한 조정 지시가 취득된 상기 정보를 기초로 내려지는, 제어 방법.
  19. 제11항에 있어서,
    상기 제1 처리 시스템에서 최후에 실행된 조정을 나타내는 정보가 상기 취득하는 단계에서 취득되는 경우, 상기 지시를 내리는 단계에서, 상기 제2 처리 시스템 내에서의 리소스의 양을 조정하기 위한 조정 지시로서 상기 취득하는 단계에서 취득된 상기 정보에 의해 나타내지는 조정을 상기 제2 처리 시스템 내에서 수행하기 위한 지시가 내려지는, 제어 방법.
  20. 제11항에 있어서,
    상기 제1 처리 시스템 내의 가상 머신(들) 상에서 동작하는 애플리케이션의 버전 및 상기 제2 처리 시스템 내의 가상 머신(들) 상에서 동작하는 애플리케이션의 버전이 서로 상이한, 제어 방법.
KR1020150173725A 2014-12-16 2015-12-08 관리 시스템 및 관리 시스템을 제어하기 위한 방법 KR101959601B1 (ko)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
JPJP-P-2014-254602 2014-12-16
JP2014254602 2014-12-16
JPJP-P-2015-187460 2015-09-24
JP2015187460A JP6548540B2 (ja) 2014-12-16 2015-09-24 管理システムおよび管理システムの制御方法

Publications (2)

Publication Number Publication Date
KR20160073306A KR20160073306A (ko) 2016-06-24
KR101959601B1 true KR101959601B1 (ko) 2019-03-18

Family

ID=56141990

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020150173725A KR101959601B1 (ko) 2014-12-16 2015-12-08 관리 시스템 및 관리 시스템을 제어하기 위한 방법

Country Status (3)

Country Link
JP (1) JP6548540B2 (ko)
KR (1) KR101959601B1 (ko)
CN (1) CN105700908B (ko)

Families Citing this family (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106412075A (zh) * 2016-10-14 2017-02-15 郑州云海信息技术有限公司 一种基于云计算的资源配置方法及装置
JP6783638B2 (ja) * 2016-11-29 2020-11-11 キヤノン株式会社 管理システム、および制御方法
CN108282507B (zh) * 2017-01-06 2021-02-02 阿里巴巴集团控股有限公司 在CaaS环境中进行应用发布的方法、装置以及电子设备
JP6943125B2 (ja) * 2017-10-04 2021-09-29 トヨタ自動車株式会社 情報処理装置、情報処理方法及びプログラム
KR102090561B1 (ko) * 2018-05-24 2020-03-18 주식회사 티맥스소프트 클라우드 환경에서 웹 서버와 was를 오토 스케일하는 방법 및 이를 사용한 was 관리자 서버
JP7102950B2 (ja) * 2018-05-30 2022-07-20 富士通株式会社 情報処理システム、情報処理システムの制御方法及び管理装置の制御プログラム
KR102106223B1 (ko) * 2018-10-16 2020-05-28 부산대학교 산학협력단 오픈스택 기반의 클라우드 오케스트레이션 방법 및 장치
JP7353836B2 (ja) 2019-07-16 2023-10-02 キヤノン株式会社 情報処理装置、方法およびプログラム
CN110471683B (zh) * 2019-08-06 2023-11-24 上海浦东发展银行股份有限公司信用卡中心 一种基于智能dns的容器云应用蓝绿发布方法
KR102537906B1 (ko) * 2022-01-07 2023-05-30 주식회사 저스트큐 위탁 판매를 위한 관리 서버의 오토 스케일링 방법

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP5717164B2 (ja) * 2009-10-07 2015-05-13 日本電気株式会社 コンピュータシステム、及びコンピュータシステムのメンテナンス方法
JP5342615B2 (ja) * 2011-08-15 2013-11-13 株式会社日立システムズ 仮想サーバ制御システム及びプログラム
KR101287448B1 (ko) * 2011-10-27 2013-07-18 삼성에스디에스 주식회사 퍼지 제어 기반 가상 머신 스케일링 시스템 및 방법
CN103136030A (zh) * 2011-11-24 2013-06-05 鸿富锦精密工业（深圳）有限公司 虚拟机管理系统及方法
US9372735B2 (en) * 2012-01-09 2016-06-21 Microsoft Technology Licensing, Llc Auto-scaling of pool of virtual machines based on auto-scaling rules of user associated with the pool
TWI456944B (zh) * 2012-05-02 2014-10-11 Quanta Comp Inc 管理方法及其系統
KR20140142745A (ko) * 2012-07-20 2014-12-12 휴렛-팩커드 디벨롭먼트 컴퍼니, 엘.피. 네트워크 리소스의 정책 기반 스케일링
CN103577122B (zh) * 2013-11-06 2016-08-17 杭州华为数字技术有限公司 分布式应用系统在平台间迁移的实现方法及装置
JP2016218530A (ja) * 2015-05-14 2016-12-22 キヤノン株式会社 リクエスト振り分けシステム、管理システム、およびその制御方法

Also Published As

Publication number Publication date
CN105700908B (zh) 2019-04-12
JP6548540B2 (ja) 2019-07-24
JP2016115333A (ja) 2016-06-23
KR20160073306A (ko) 2016-06-24
CN105700908A (zh) 2016-06-22

Similar Documents

Publication Publication Date Title
KR101959601B1 (ko) 관리 시스템 및 관리 시스템을 제어하기 위한 방법
US10013271B2 (en) Management system and method for controlling management system
JP6450835B2 (ja) エネルギーセービング制御方法、管理サーバ及びネットワークデバイス
JP6514241B2 (ja) ソフトウェア定義ネットワークにおけるサービスオーケストレーション方法及び装置、記憶媒体
US8412810B1 (en) Provisioning and managing a cluster deployed on a cloud
US10146636B1 (en) Disaster recovery rehearsals
US11093296B2 (en) System, virtualization control apparatus, method for controlling a virtualization control apparatus, and program
WO2020135799A1 (zh) Vnf服务实例化方法及装置
EP3588852B1 (en) Method, apparatus and system for managing network slice instance
CN103294765A (zh) 用于供应和转换虚拟设备的基于策略的方法的方法和系统
US11966768B2 (en) Apparatus and method for multi-cloud service platform
US10389653B2 (en) Request distribution system, management system, and method for controlling the same
JP6582445B2 (ja) シンクライアントシステム、接続管理装置、仮想マシン稼働装置、方法、および、プログラム
JP2016103144A (ja) 仮想マシン配備方法、仮想マシン配備プログラム及び仮想マシン配備システム
JP5352367B2 (ja) 仮想マシン起動端末および仮想マシン起動プログラム
CN113382077B (zh) 微服务调度方法、装置、计算机设备和存储介质
US10754368B1 (en) Method and system for load balancing backup resources
JP2017010227A (ja) ウェブサーバ、管理システム、およびその制御方法
US8433877B2 (en) Storage scalability management
JP2016177324A (ja) 情報処理装置、情報処理システム、情報処理方法、及びプログラム
US20160328242A1 (en) Predictive writing of bootable images to storage nodes in a cloud computing environment
CN107547622B (zh) 一种资源调整方法及装置
US10942779B1 (en) Method and system for compliance map engine
JP6568232B2 (ja) 計算機システム、及び、装置の管理方法
WO2013095083A1 (en) A method and system of extending computing grid resources

Legal Events

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