KR20210023693A - 스파이크 검출 및 부하 분산 자원 관리 시스템 및 그 방법 - Google Patents

스파이크 검출 및 부하 분산 자원 관리 시스템 및 그 방법 Download PDF

Info

Publication number
KR20210023693A
KR20210023693A KR1020200095498A KR20200095498A KR20210023693A KR 20210023693 A KR20210023693 A KR 20210023693A KR 1020200095498 A KR1020200095498 A KR 1020200095498A KR 20200095498 A KR20200095498 A KR 20200095498A KR 20210023693 A KR20210023693 A KR 20210023693A
Authority
KR
South Korea
Prior art keywords
load balancing
load
processors
resource
queue
Prior art date
Application number
KR1020200095498A
Other languages
English (en)
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 KR20210023693A publication Critical patent/KR20210023693A/ko

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • H04L43/0805—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters by checking availability
    • H04L43/0817—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters by checking availability by checking functioning
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
    • 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/5083—Techniques for rebalancing the load in a distributed system
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • 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/5072—Grid computing
    • 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
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/12—Avoiding congestion; Recovering from congestion
    • H04L47/125—Avoiding congestion; Recovering from congestion by balancing the load, e.g. traffic engineering
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/30—Flow control; Congestion control in combination with information about buffer occupancy at either end or at transit nodes
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/50—Queue scheduling
    • H04L47/62—Queue scheduling characterised by scheduling criteria
    • H04L47/625—Queue scheduling characterised by scheduling criteria for service slots or service orders
    • H04L47/6255—Queue scheduling characterised by scheduling criteria for service slots or service orders queue load conditions, e.g. longest queue first
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L49/00—Packet switching elements
    • H04L49/90—Buffering arrangements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L49/00—Packet switching elements
    • H04L49/90—Buffering arrangements
    • H04L49/9047—Buffering arrangements including multiple buffers, e.g. buffer pools
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
    • H04L67/1004—Server selection for load balancing
    • H04L67/1008—Server selection for load balancing based on parameters of servers, e.g. available memory or workload
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
    • H04L67/1004—Server selection for load balancing
    • H04L67/101—Server selection for load balancing based on network conditions
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/60—Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G06F2009/4557—Distribution of virtual machine instances; Migration and load balancing

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Environmental & Geological Engineering (AREA)
  • Computer Hardware Design (AREA)
  • Mathematical Physics (AREA)
  • Debugging And Monitoring (AREA)

Abstract

본 발명의 하나 또는 그 이상의 실시 예에 따른 부하 분산 시스템은, 중앙 집중 큐; 상기 중앙 집중 큐에 연결된 자원 노드들의 풀; 하나 또는 그 이상의 프로세서; 및 상기 하나 또는 그 이상의 프로세서에 연결되고, 명령어들을 저장하는 메모리를 포함하되; 상기 명령어들은, 상기 하나 또는 그 이상의 프로세서에 의해 실행되는 경우, 상기 하나 또는 그 이상의 프로세서로 하여금: 상기 중앙 집중 큐의 큐 상태를 모니터링하여 버스티 트래픽 구간을 식별하도록 하고; 상기 버스티 트래픽 구간과 관련된 부하에 대한 인덱스 값을 계산하도록 하고; 상기 인덱스 값에 기반하여 부하 분산 전략을 선택하도록 하고; 상기 부하 분산 전략에 기반하여 상기 자원 노드들의 상기 풀로 상기 부하를 분배하도록 하고; 상기 부하 분산 전략에 응답하여 상기 자원 노드들의 상기 풀의 상태를 관찰하도록 하고 상기 관찰된 상태에 기반하여 보상을 계산하도록 하고; 그리고 상기 보상에 기반하여 상기 부하 분산 전략을 조절하도록 한다.

Description

스파이크 검출 및 부하 분산 자원 관리 시스템 및 그 방법{SYSTEMS AND METHODS FOR SPIKE DETECTION AND LOAD BALANCING RESOURCE MANAGEMENT}
본 발명은 작업 부하 트래픽 분포에 관한 것이다. 좀 더 상세하게는, 스파이크 검출 및 부하 분산(균형, balancing) 시스템 및 그 방법에 관한 것이다.
일반적으로, 클라우드 데이터 센터(cloud data center)들을 대상으로 한 트래픽(또는 부하)의 양은 사용자 요청에 기반하여 변동한다. 이 트래픽은 버스티(bursty)(예를 들어, 요청에 갑작스러운 피크 발생)할 수 있고, 고도의 자원 재분배를 요청할 수 있다. 종종, 그러나, 불확실한 작업 부하 트래픽의 본질은 많은 요청들로 하여금 즉석에서 재분배되는 것을 요구할 수 있는데, 이는 성능 저하를 초래한다. 예를 들어, 클라우드 데이터 센터에 도착하는 트래픽은 스케줄링 지연(scheduling delay)에 비례할 수 있는데, 가변성이 높을수록 스케줄링 지연은 길어진다. 따라서, 만일 자원들이 커밋(commit)되는 경우, 스케줄을 바꾸는 것은 불만스러운 서비스 수준 협약(Service-Level Agreements; SLA)을 초래할 수 있다.
이러한 문제들은 요청들을 처리(또는 실행)하기 위하여 여러 개의 서버 노드들(예를 들어, 도커 컨테이너(docker container), 가상 머신, 기타 등등)을 임대 또는 소유하는 사용자들에 대하여 악화될 수 있다. 예를 들어, 이러한 서버 노드들은 일반적으로 클라우드 컴퓨팅 벤더(vendor)에 의해 호스트되고, 종종 다른 사용자들의 서비스 노드들을 호스트하는 물리적 서버들 상에 위치할 수 있다. 나아가, 이러한 물리적 서버들은 종종 여러 명의 사용자들에게 과도하게 판매(oversold)되고, 이에 따라 여러 명의 사용자들이 과도하게 약속(overpromise)된 자원을 공유하게 된다. 결과적으로, 작업 부하 스파이크(예를 들어, 많은 양의 작업들 또는 요청들을 전송하는)를 지니는 사용자는 공유된 자원 상의 해당 사용자에 대해 문제를 초래할 수 있을 뿐만 아니라, 물리적 호스트 서버를 느리게 하여 다른 사용자들에게 영향을 미칠 수 있다.
따라서, 스파이크 검출 및 지능적 부하 분산 시스템 및 방법이 요구된다.
본 배경 기술에 개시된 상기 정보는 본 발명의 배경 기술의 이해 증진을 위한 것이며, 따라서, 종래 기술을 구성하지 않는 정보를 포함할 수 있다.
본 발명의 목적은, 스파이크 검출 및 부하 분산 시스템 및 그 방법을 제공하는 데 있다.
본 발명의 하나 또는 그 이상의 실시 예에 따른 부하 분산 시스템은, 중앙 집중 큐; 상기 중앙 집중 큐에 연결된 자원 노드들의 풀; 하나 또는 그 이상의 프로세서; 및 상기 하나 또는 그 이상의 프로세서에 연결되고, 명령어들을 저장하는 메모리를 포함하되; 상기 명령어들은, 상기 하나 또는 그 이상의 프로세서에 의해 실행되는 경우, 상기 하나 또는 그 이상의 프로세서로 하여금: 상기 중앙 집중 큐의 큐 상태를 모니터링하여 버스티 트래픽 구간을 식별하도록 하고; 상기 버스티 트래픽 구간과 관련된 부하에 대한 인덱스 값을 계산하도록 하고; 상기 인덱스 값에 기반하여 부하 분산 전략을 선택하도록 하고; 상기 부하 분산 전략에 기반하여 상기 자원 노드들의 상기 풀로 상기 부하를 분배하도록 하고; 상기 부하 분산 전략에 응답하여 상기 자원 노드들의 상기 풀의 상태를 관찰하도록 하고 상기 관찰된 상태에 기반하여 보상을 계산하도록 하고; 그리고 상기 보상에 기반하여 상기 부하 분산 전략을 조절하도록 한다.
하나 또는 그 이상의 실시 예들에서, 상기 인덱스 값은 기틴스 인덱스 값에 대응한다.
하나 또는 그 이상의 실시 예들에서, 상기 인덱스 값을 계산하기 위하여 상기 명령어들은, 상기 하나 또는 그 이상의 프로세서로 하여금: 상기 버스티 트래픽 구간과 관련된 상기 부하에 대해 복수의 기틴스 인덱스 값들을 더 계산하도록 하고; 그리고 상기 복수의 기틴스 인덱스 값들 중 가장 큰 값을 새로운 스파이크 값으로서 더 출력하도록 한다.
하나 또는 그 이상의 실시 예들에서, 상기 자원 노드들의 상기 풀로 상기 부하를 분산시키기 위하여 상기 명령어들은, 상기 하나 또는 그 이상의 프로세서로 하여금: 새로운 계산 환경을 생성하기 위하여 상기 새로운 스파이크 값에 기반하여 상기 자원 노드들의 상기 풀에 대한 자원 요청 사항을 더 조절하도록 하고; 그리고 상기 새로운 계산 환경에 대한 상기 부하와 관련된 작업 요청 분배 스케줄을 더 생성하도록 한다.
하나 또는 그 이상의 실시 예들에서, 상기 부하 분산 전략을 선택하기 위하여 상기 명령어들은, 상기 하나 또는 그 이상의 프로세서로 하여금: 상기 자원 노드들의 상기 풀 내의 각 자원에 대하여 증분 부하 관리 값을 더 계산하도록 하고; 그리고 상기 자원 노드들의 상기 풀 내의 각 자원에 대하여 기초 자원 파라미터를 더 계산하도록 한다.
하나 또는 그 이상의 실시 예들에서, 상기 부하 분산 전략은 상기 기초 자원 파라미터 중 가장 큰 파라미터를 지니는 상기 자원에 기반하여 선택된다.
하나 또는 그 이상의 실시 예들에서, 상기 보상을 계산하기 위하여 상기 명령어들은, 상기 하나 또는 그 이상의 프로세서로 하여금: 상기 인덱스 값, 입력 상태, 상기 선택된 부하 분산 전략, 및 보상 함수에 기반하여 Q-함수를 더 계산하도록 한다.
하나 또는 그 이상의 실시 예들에서, 상기 Q-함수는: 수식
Figure pat00001
에 따라 계산되고, 상기 수식에서: s 및 s'는 기틴스 인덱스 값들의 과거 상태 및 현재 상태에 각각 대응하고; a는 서로 다른 부하 값들에 대응하고; 그리고 r은 즉시 보상 파라미터에 대응한다.
하나 또는 그 이상의 실시 예들에서, 상기 명령어들은 상기 하나 또는 그 이상의 프로세서로 하여금: 상기 Q-함수 계산에 지수가중이동평균을 적용한다.
하나 또는 그 이상의 실시 예들에서, 상기 부하는 포아송 트래픽 분포에 대응한다.
본 발명의 하나 또는 그 이상의 실시 예에 따른 부하 분산 방법은, 하나 또는 그 이상의 프로세서에 의해, 버스티 트래픽 구간을 식별하기 위하여 중앙 집중 큐의 큐 상태를 모니터링하는 단계; 상기 하나 또는 그 이상의 프로세서에 의해, 상기 버스티 트래픽 구간에 관련된 부하에 대한 인덱스 값을 계산하는 단계; 상기 하나 또는 그 이상의 프로세서에 의해, 상기 인덱스 값에 기반하여 부하 분산 전략을 선택하는 단계; 상기 하나 또는 그 이상의 프로세서에 의해, 상기 부하 분산 전략에 기반하여 자원 노드들의 풀로 상기 부하를 분배하는 단계; 상기 하나 또는 그 이상의 프로세서에 의해, 상기 부하 분산 전략에 응답하여 상기 지원 노드들의 풀의 상태를 관찰하는 단계; 상기 하나 또는 그 이상의 프로세서에 의해, 상기 관찰된 상태에 기반하여 보상을 계산하는 단계; 및 상기 하나 또는 그 이상의 프로세서에 의해, 상기 보상에 기반하여 상기 부하 분산 전략을 조절하는 단계를 포함한다.
하나 또는 그 이상의 실시 예들에서, 상기 인덱스 값은 기틴스 인덱스 값에 대응한다.
하나 또는 그 이상의 실시 예들에서, 상기 인덱스 값을 계산하는 단계는: 상기 하나 또는 그 이상의 프로세서에 의해, 상기 버스티 트래픽 구간과 관련된 상기 부하에 대해 복수의 기틴스 인덱스 값들을 계산하는 단계; 그리고 상기 하나 또는 그 이상의 프로세서에 의해, 상기 복수의 기틴스 인덱스 값들 중 가장 큰 값을 새로운 스파이크 값으로서 출력하는 단계를 포함한다.
하나 또는 그 이상의 실시 예들에서, 상기 자원 노드들의 상기 풀로 상기 부하를 분배하는 단계는: 상기 하나 또는 그 이상의 프로세서에 의해, 새로운 계산 환경을 생성하기 위하여 상기 새로운 스파이크 값에 기반하여 상기 자원 노드들의 상기 풀에 대한 자원 요청 사항을 조절하는 단계; 그리고 상기 하나 또는 그 이상의 프로세서에 의해, 새로운 계산 환경에 대한 상기 부하와 관련된 작업 요청 분배 스케줄을 더 생성하는 단계를 포함한다.
하나 또는 그 이상의 실시 예들에서, 상기 부하 분산 전략을 선택하는 단계는: 상기 하나 또는 그 이상의 프로세서에 의해, 상기 자원 노드들의 상기 풀 내의 각 자원에 대하여 증분 부하 관리 값을 계산하는 단계; 그리고 상기 하나 또는 그 이상의 프로세서에 의해, 상기 자원 노드들의 상기 풀 내의 각 자원에 대하여 기초 자원 파라미터를 계산하는 단계를 포함한다.
하나 또는 그 이상의 실시 예들에서, 상기 부하 분산 전략은 상기 기초 자원 파라미터 중 가장 큰 파라미터를 지니는 상기 자원에 기반하여 선택된다.
하나 또는 그 이상의 실시 예들에서, 상기 보상을 계산하는 단계는: 상기 하나 또는 그 이상의 프로세서에 의해, 상기 인덱스 값, 입력 상태, 상기 선택된 부하 분산 전략, 및 보상 함수에 기반하여 Q-함수를 계산하는 단계를 포함한다.
하나 또는 그 이상의 실시 예들에서, 상기 Q-함수는: 수식
Figure pat00002
에 따라 계산되고, 상기 수식에서: s 및 s'는 기틴스 인덱스 값들의 과거 상태 및 현재 상태에 각각 대응하고; a는 서로 다른 부하 값들에 대응하고; 그리고 r은 즉시 보상 파라미터에 대응한다.
하나 또는 그 이상의 실시 예들에서, 상기 Q-함수 계산에 지수가중이동평균을 적용하는 단계를 더 포함한다.
하나 또는 그 이상의 실시 예들에서, 상기 부하는 포아송 트래픽 분포에 대응한다.
본 발명에 의하면, 스파이크 검출 및 부하 분산 시스템 및 그 방법이 제공된다.
본 발명의 상기 및 다른 측면들 및 특징들은 첨부된 도면들을 참조하여 이루어진 다음의 실시 예들에 대한 상세한 설명으로부터 통상의 기술자에게 보다 쉽게 명백해질 것이다.
도 1은 본 발명의 실시 예에 따른, 클라우드 환경 상의 부하 분산 시스템을 나타낸다.
도 2는 본 발명의 실시 예에 따른, 중앙 집중 큐로부터 작업들을 디스패치하기 위한 예시적인 장치를 나타낸다.
도 3은 본 발명의 실시 예에 따른, 작업 요청의 데이터 구조 망 구성방식(topology)을 나타낸다.
도 4는 본 발명의 실시 예에 따른, 부하 분산을 위한 제 1 모드 하에서 동작하는 부하 분산 시스템의 블록도이다.
도 5a는 본 발명의 실시 예에 따른, 제 1 모드 하에서 적절한 부하 분산 전략을 선택하는 방법을 나타내는 흐름도이다.
도 5b는 본 발명의 실시 예에 따른, 도 5a의 방법을 구현하기 위한 대응하는 의사코드(pseudocode)를 나타낸다.
도 6은 본 발명의 실시 예에 따른, SCV-ACF 기반 스파이크 검출 방법의 그래프를 나타낸다.
도 7a는 본 발명의 실시 예에 따른, 스파이크 검출기에 의해 결정된 각 스파이크 레벨에 대하여 대응하는 부하 분산 전략을 나타내는 블록도이다.
도 7b는 본 발명의 실시 예에 따른, 도 7a의 다양한 부하 분산 전략들을 구현하기 위한 대응하는 의사코드를 나타낸다.
도 8은 본 발명의 실시 예에 따른, 부하 분산을 위한 제 2 모드 하에서 동작하는 부하 분산 시스템의 블록도이다.
도 9는 본 발명의 실시 예에 따른, 부하 분산 시스템의 시스템도이다.
도 10a는 본 발명의 실시 예에 따른, 스파이크 검출 방법을 나타내는 흐름도이다.
도 10b는 본 발명의 실시 예에 따른, 도 10a의 스파이크 검출 방법을 구현하기 위한 대응하는 의사코드를 나타낸다.
도 11a 내지 도 11c는 본 발명의 실시 예에 따른, 들어오는 트래픽 분석을 위한 인덱스 정책 필터의 예시들을 나타낸다.
도 12는 본 발명의 실시 예에 따른, 버스트 값을 생성하기 위한 예시적인 방법을 나타내는 흐름도이다.
도 13a는 본 발명의 실시 예에 따른, 머신 러닝 과정의 예시적인 방법을 나타내는 흐름도이다.
도 13b는 본 발명의 실시 예에 따른, 도 13a의 과정을 구현하기 위한 대응하는 의사코드를 나타낸다.
도 14는 본 발명의 실시 예에 따른, 한계 계산기를 나타내는 흐름도이다.
도 15a는 본 발명의 실시 예에 따른, 인덱스 정책 필터, 한계 계산기, 구성 로직, 및 자원 풀 스케줄러 사이의 파라미터 전송을 나타낸 것이다.
도 15b는 본 발명의 실시 예에 따른, 부하 분산 에이전트의 결과적인 신뢰 한계 레벨을 나타낸다.
도 16은 본 발명의 실시 예에 따른, 모드 선택기의 블록도이다.
도 17은 본 발명의 실시 예에 따른, 제 1 모드와 제 2 모드 사이에서 자동으로 선택하는 방법을 나타내는 흐름도이다.
이하에서는, 명세서 전반에 걸쳐 동일한 참조 번호들은 동일한 구성을 나타내는 첨부되는 도면들을 참조하여 본 발명의 예시적인 실시 예가 자세히 설명될 것이다. 하지만, 본 발명은 다양한 다른 형태로 실시 될 수 있으며, 여기에 설명된 내용에 국한되어서 해석되어서는 안 된다. 오히려, 이러한 실시 예들은 이 개시가 철저하고 완전하게 되기 위한 예로서 제공되며, 통상의 기술자에게 본 발명의 특징 및 기능을 완전하게 전달할 것이다. 따라서, 본 발명의 기술 분야에서 통상의 지식을 가진 자가 본 발명의 특징 및 기능을 완벽하게 이해하기 위해 필요하지 않은 프로세스, 요소들, 및 기술들은 설명되지 않을 수 있다. 특별히 언급하지 않는 한, 유사한 참조 번호들은 첨부된 도면들 및 쓰여진 설명에서 유사한 구성요소들을 나타내고, 따라서 그것에 대한 설명은 반복되지 않을 것이다.
본 발명에 따른 실시 예들의 하나 또는 그 이상의 측면들 또는 특징들은 작업 부하 트래픽 스파이크들을 검출(스파이크 검출이라고도 불리는)하고 서버 노드들에 걸쳐 지능적 부하 분산(균형, balancing)을 수행하기 위한 엔드-투-엔드(단-대-단, end-to-end) 솔루션에 관한 것이다. 몇몇 실시 예들에서, 부하 분산 시스템은 작업 부하 트래픽 스파이크들을 검출하고, 하나 또는 그 이상의 자원을 선택하여 클라이언트에 대해 새로운 작업들을 할당하기 위하여 제공된다. 몇몇 실시 예들에서, 부하 분산 시스템은 다른 사용자들의 행동이 공유 호스팅 물리적 서버들에 미치는 영향에 대해서 알 수 있다(예를 들어, 자신의 서버 노드들의 서비스 속도의 주기적인 모니터링(monitoring)을 통하여). 몇몇 실시 예들에서, 부하 분산 시스템은 두 가지 모드 하에서 선택적으로 동작할 수 있다: (1) 휴리스틱(heuristic) 모드일 수 있는 제 1 모드; 및 (2) 머신 러닝(machine learning) 모드, 예를 들어, 강화 학습 기반(Reinforcement Learning-Based) 모드와 같이, 일 수 있는 제 2 모드.
간략한 개요 상에서, 제 1 모드(예를 들어, 휴리스틱 모드)는 균일 분포를 지니는 들어오는 작업 부하들을 처리하는 상대적으로 가벼운 접근이다. 제 1 모드 하에서, 스파이크들은 제곱 변동계수-자기상관계수 기반 함수(squared-coefficient of variation-autocorrelation-based function; SCV-ACF) 방법을 이용하여 검출될 수 있는데, 이는 확률적 프로세스의 분산(dispersion)에 기반한 것이다. 그 후 작업 요청들은, 높은, 중간, 및 낮은 스파이크 정도(또는 스파이크 범위)들에 응답하여, 각각 라운드 로빈(Round Robin) 부하 분산 전략, JSQ(Join Shortest Queue) 부하 분산 전략, 및 최소 변동계수(minimum Coefficient of Variation; minCV) 부하 분산 전략을 이용하여 할당될 수 있다.
제 2 모드(예를 들어, 학습 모드)는 특정된 작업 완료 시간 내에 스파이크 값(또는 스파이크 레벨)을 예측하기 위하여 인덱스(예를 들어, 기틴스 인덱스(Gittins index; GI)를 사용하는 강화 학습 기반 접근(예를 들어, Q-학습)에 기반한 머신 러닝 모드이다. 제 2 모드 하에서, 부하 분산 시스템은, 제 1 모드에서 스파이크 범위들이 미리 결정된(또는 미리 설정된) 카테고리들로 나누어지는 것과 비교하여, 넓은 범위의 스파이크 값들(또는 스파이크 레벨들)에 응답하여 활성화될 수 있다. 몇몇 실시 예들에서, 제 2 모드 하에서, 부하 분산 시스템은 시간에 걸쳐 변하는 작업 부하 조건들에 기반하여 부하 분산 전략들을 조절할 수 있고, 기한이 만료된 중요한 또는 시간에 민감한(time-sensitive) 작업들을 지원하도록 활성화될 수 있고, 그리고 버스티(bursty) 트래픽 구간들(예를 들어, 높은 트래픽 스파이크 구간들)에 응답하여 동적 자원 할당(예를 들어, 자원을 추가하거나 제거하는 것)을 지원할 수 있다.
다양한 실시 예들에서, 부하 분산 시스템은 모드들의 다양하게 요구되는 측면들 및 특징들에 기반하여 제 1 모드 또는 제 2 모드 중 임의의 하나의 모드 하에서 동작하도록 구성될 수 있다. 몇몇 실시 예들에서, 부하 분산 시스템은 자원 노드 풀(resource node pool)의 작업 부하 조건들에 기반하여 요구되는 또는 필요한 모드들 중에서 자동으로 선택하는 모드 선택기(mode selector)를 포함할 수 있다.
버스티한 요청들(예를 들어, 트래픽 스파이크들)을 검출하고 처리하는 것은 많은 분야에서 직면하고 있는 복잡한 문제이다. 어려움은 변화하는 로컬 및 글로벌 환경들 내의 스파이크들을 분석하는 데 있다. 넓게 분포한 클라우드 컴퓨팅 시장은 이 문제가 흔한 분야이다. 따라서, 다양한 실시 예들이 부하 분산 시스템이 컴퓨터(또는 서버) 노드들에 작업 요청들을 할당하는 클라우드 환경과 관련하여 본 명세서에 개시되어 있지만, 본 발명은 이에 한정되지 않고, 그리고 동일하거나 또는 동등한 기능들 및 구조들은, 본 발명의 사상 및 범위 내에 포함되도록 의도되는, 다른 실시 예들 및 다른 환경 상에서(예를 들어, 계산 작업들이 작업자 노드들에 할당되는 분배(distributed) 프로세싱 환경, 입출력 요청들이 디스크 자원들에 할당되는 디스크 입출력 프로세싱, 또는 기타 등등) 이루어질 것이라고 이해된다.
도 1은 본 발명의 실시 예에 따른, 클라우드 환경(102) 상의 부하 분산 시스템을 나타낸다. 도 1에 나타난 바와 같이, 클라우드 환경(102)는, 고객 장치들(또는 클라이언트 장치들)(104)로부터 요청들(또는 작업들)(106)을 처리하기 위하여, 하나 또는 그 이상의 고객 장치들(104)과 통신 가능하게 연결될 수 있다. 몇몇 실시 예들에서, 클라우드 환경(102)은 다양한 부하 분산 전략들에 따라 자원 노드 풀(110)으로 작업 요청들을 분배하기 위하여, 자원 노드 풀(110)과 연결된 부하 분산 시스템(108)을 포함할 수 있다. 몇몇 실시 예들에서, 자원 노드 풀(110)은 복수의 자원 노드들(예를 들어, 서버 노드들)을 포함할 수 있고, 이는 복수의 가상 머신(virtual machine; VM)들 및 대응하는 컨테이너들(예를 들어, 데이터 컨테이너들)로서 예시적으로 도 1에 나타나 있다. 그러나, 본 발명은 이에 한정되지 않으며, 다른 실시 예들에서, 자원 노드 풀(110)은 복수의 작업자 노드(worker node)들, 복수의 디스크 드라이브들(예를 들어, 저장 자원), 및/또는 복수의 프로세서들(예를 들어, 계산 자원)을 포함할 수 있다.
클라우드 환경에서, 요청들을 처리하기 위한 효율적인 자원들의 할당은 클라이언트들 쪽에서 시작한다. 클라이언트 애플리케이션들은 자원들을 다르게 요구하여, 특정 클라이언트 애플리케이션의 요구량이 높은 경우, 계산 자원들은 해당 클라이언트 애플리케이션으로 재할당되어야 한다. 예를 들어, 서로 다른 실행 요구량을 지니는 애플리케이션들(직렬화된 로드 가능 라이브러리(serialized loadable library) 또는 병렬 프로세스와 같은)은 종종 자원 재할당을 요구한다. 이 요청들은, 종종 짧은 주기로 들어오는데, 도착 속도가 빠른 스파이크들에 대한 책임이 있다. 그러나, 버스티한 작업 부하를 바꾸는 것은 서비스의 질(quality of service; QoS)를 저하시킬 수 있고, 서비스 제공자의 이익에 영향을 미칠 수 있다. 따라서, 작업 부하의 작업 도착 및 완료 속도는 요청들을 삭제하는 일 없이 최적으로 고려되어야 할 필요가 있다.
몇몇 실시 예들에서, 부하 분산 시스템(108)은 부하 분산 에이전트(112), 자원 풀 스케줄러(114), 및 구성 로직(Composition Logic)(116)을 포함할 수 있다. 아래에서 더 자세히 다루어지는 바와 같이, 다양한 실시 예들에서, 부하 분산 에이전트(112)는 스파이크(spikey) 도착 주기에 응답하여 자원 노드들로 부하(예를 들어, 작업 요청들)를 분배할 수 있다. 몇몇 실시 예들에서, 부하 분산 시스템(108)은 변화하는 작업 부하 조건들에 응답하여, 부하를 분산시키는 데 필요한 또는 요구되는 대로 제 1 모드 또는 제 2 모드 하에서 동작할 수 있다.
도 2는 본 발명의 실시 예에 따른, 중앙 집중 큐(centralized queue; CQ)(202)로부터 작업들을 디스패치(dispatch)하기 위한 예시적인 장치(200)를 나타낸다. 도 2를 참조하면, 장치(200)는 중앙 집중 큐(202), 디스패처(dispatcher)(204), 및 복수의 서버 노드들(206a, 206b, 206c, 및 206d)을 포함한다. 몇몇 실시 예들에서, 서버 노드들 각각(206a, 206b, 206c, 및 206d)은 대응하는 큐(208a, 208b, 208c, 및 208d)를 갖는다. 몇몇 실시 예들에서, 클라우드 제공자 시스템(예를 들어, 도 1의 클라우드 환경(102))은 요청의 여행 경로에 기반하여 중앙 집중 큐(202)에 사용자 작업 요청들을 큐잉(queue)한다. 영역에 의하여 결정될 수 있는 요청의 여행 경로는, “물리적 세계(physical-world)” 지정학적 위치에 기반하거나(예를 들어, 중앙 집중 큐가 뉴욕에 위치하는 경우, 시카고에 위치하는 작업자 노드는, 일본 도쿄에 위치하는 같은 스펙의 작업자 노드에 비하여 좋은 선택일 수 있다) 또는 네트워크 망 구성방식(network-topology)에 기반한 위치에 기반할 수 있다(예를 들어, 가까운 곳에 위치하는 노드의 접근 속도는 먼 곳에 위치하는 노드의 접근 속도보다 느릴 수 있다). 몇몇 실시 예들에서, 디스패처(204)(예를 들어, 부하 분산 시스템)은 영역 상의 대응하는 큐들(208a, 208b, 208c, 및 208d)에 걸쳐 부하(예를 들어, 사용자 작업 요청들)를 분산시키기(균형을 맞추기) 위하여, 중앙 집중 큐(202)와 연결될 수 있다.
예를 들어, 몇몇 실시 예들에서, 장치(200)로 향하거나 또는 할당된(예를 들어, 영역에 기반하여) 모든 요청들(예를 들어, 작업들)은 중앙 집중 큐(202)에 큐잉될 수 있다. 디스패처(204)는 그 후 큐잉된 요청들을 큐 전략에 따라 서버 노드들(206a, 206b, 206c, 및 206d)의 큐들(208a, 208b, 208c, 및 208d) 중 대응하는 것들로 분배한다. 큐들(208a, 208b, 208c, 및 208d)의 각각은 특징적인 도착 속도 및 서비스 속도를 지니지만, 큐들(208a, 208b, 208c, 및 208d)의 서비스 속도들은 주어진 시간(예를 들어, 런타임(runtime))에서 서로 같도록 보장되지 않을 수 있다.
몇몇 실시 예들에서, 디스패처(204)의 목적은 선택된 영역(예를 들어, 지정학적 위치) 상의 모든 큐들(208a, 208b, 208c, 및 208d)에 걸쳐 부하를 분산하는 것일 수 있다. 예를 들어, 단순화된 균질 시나리오 상에서, 요청들이 동일한 또는 실질적으로 동일한 양의 작업 부하를 지니는(예를 들어, 동일한 메이크스팬(makespan, 작업 완료 시간, 총 소요시간)을 소비하는) 경우, 디스패처(204)는 큐잉된 작업들의 개수에 기반하여 단순히 큐들을 분산시킬 수 있다. 그러나, 요청들은 대체로 균일하지 않고, 실제 상황들에서 복수의 애플리케이션들 또는 심지어 단 하나의 애플리케이션으로부터의 요청들(예를 들어, 작업들)은 유의미한 차이(예를 들어, 서로 다른 작업 부하들)를 지닐 수 있다.
더욱이, 처음에 서버(예를 들어, 서버 노드)에 적합하다고 간주된 요청(예를 들어, 작업)이 나중에, 예를 들어, 자원들이 갑자기 바뀌거나 재할당되는 경우에, 응답 불가 또는 “막힌(stuck)” 상태가 되는 것도 가능하다. 이 경우, 몇몇 실시 예들에서, 요청들(예를 들어, 작업들)은 일시적 큐로 돌아갈 수 있고, 그렇게 하여 요청(또는 작업)은 다른 서버들(예를 들어, 다른 서버 노드들)에 의하여 픽업(또는 분배)될 수 있다. 몇몇 실시 예들에서, 극적인 경우, 이러한 응답 불가 또는 “막힌” 요청들은 최종적으로 삭제되기 이전에 중앙 집중 큐(202)로 돌아갈 수 있다. 몇몇 실시 예들에서, 아래에서 더 설명되는 바와 같이, 이러한 요청들의 본질은 적절한 행동을 취하기 위하여 학습될 수 있다(예를 들어, 학습 모드를 통하여).
도 3은 본 발명의 실시 예에 따른, 작업 요청의 데이터 구조 망 구성방식(topology)을 나타낸다. 도 3에 나타난 파라미터들 각각은 아래의 표 1에서 더 자세히 설명된다.
파라미터 참조번호 설명
job_pkt_struct 302 키 및 값 객체로 구성되는 요청 인스턴스화된 구조
key_ptr 304 키에 대한 포인터
value_struct 306 작업 객체의 인스턴스화된 값 구조체
value_ptr 308 동작이 수행될 파일/데이터와 같은, 작업 객체에 대한 포인터
value_size 310 작업 객체의 크기
type 312 작업 서비스의 내용 유형
operation 314 Get, put, delete 등과 같은 요청 동작들
timestamp 316 작업 시간 민감도를 알아내기 위한, 중앙 집중 큐 입력(entry) 시간과 같은 타임스탬프
몇몇 실시 예들에서, 표 1에 나타난 파라미터들 중에서, value_size(310) 파라미터(예를 들어, 데이터 크기) 및 operation(314) 파라미터(예를 들어, 읽기, 쓰기, 삭제, 기타 등등)는 표 1에 나타난 다른 파라미터들에 비하여 지연 시간(latency)의 관점에서 성능에 더 많은 영향을 미칠 수 있다. 예를 들어, 4KB 입출력 읽기를 지니는 제 1 요청 및 10MB 입출력 쓰기를 지니는 제 2 요청은 서로 다른 메이크스팬(예를 들어, 작업 완료 시간)을 가질 것이고, 따라서, 부하 분산기(예를 들어, 디스패처)는 제 1 및 제 2 요청들을 동등하게 다루지 말아야 한다. 따라서, 몇몇 실시 예들에서, 요청들(예를 들어, 작업들)은 그것들의 특징에 기반하여 그리고 요청과 관련된 실제 또는 추정된 작업 부하(예를 들어, 메이크스팬)를 결정함으로써 분류(차별화)될 수 있다.
도 4는 본 발명의 실시 예에 따른, 부하 분산을 위한 제 1 모드(예를 들어, 휴리스틱 모드) 하에서 동작하는 부하 분산 시스템의 블록도이다. 아래에서 더 자세히 설명되는 바와 같이, 제 1 모드는 다양한 스파이크 범위들(또는 정도들)에 기반하여 작업 부하들(예를 들어, 작업들 또는 요청들)을 통계적으로 분배하는, 비교적 가벼운 휴리스틱 접근이다. 예를 들어, 제 1 모드에서, 작업 부하들(예를 들어, 작업들 또는 요청들)은 높은 스파이크 범위(또는 정도)에 응답하여 라운드 로빈 부하 분산 전략, 중간 스파이크 범위에 응답하여 JSQ 부하 분산 전략, 및/또는 낮은 스파이크 범위에 응답하여 minCV 부하 분산 전략을 이용하여 자원들로 분배될 수 있다. 몇몇 실시 예들에서, 작업 부하 스파이크들(및 대응하는 스파이크 범위들)은 SCV-ACF 방법에 기반하여 검출될 수 있고, 이는, 예를 들어, 확률적 프로세스의 분산에 기반한다.
도 4를 참조하면, 몇몇 실시 예들에서, 부하 분산 시스템(400)은 부하 모니터(402), 스파이크 검출기(404), 및 부하 분산기(406)를 포함한다. 부하 모니터(402)는 자원 풀(예를 들어, 노드 풀, 서버 풀, 기타 등등)을 모니터링할 수 있고, 자원 풀의 내용들(예를 들어, 노드들 각각에 대응하는 큐들)에 관련된 정보를 제공할 수 있다. 예를 들어, 몇몇 실시 예들에서, 부하 모니터(402)는 영역 내의 현재 큐에 대한 부하 상태 정보(예를 들어, 큐들의 개수, 작업 요청들의 개수, 각 요청들의 작업 부하 양, 및/또는 기타 등등)를 수집할 수 있다. 이 부하 상태 정보는, 스파이크 레벨을 계산하기 위하여 단지 큐잉된 작업들의 개수를 이용하는 것 대신, 수반되는 실제 작업 부하의 정도(또는 척도)를 계산하기 위하여 스파이크 검출기(404)에 의하여 사용될 수 있다. 예를 들어, 몇몇 실시 예들에서, 스파이크 검출기(404)는 대응하는 자원 노드들의 큐들에 대한 사용자의 중앙 집중 큐에 대하여, 현재 들어오는 작업들(예를 들어, 요청들)의 스파이크 레벨을 검출(예를 들어, 측정 또는 계산)할 수 있다. 몇몇 실시 예들에서, 스파이크 검출기(404)는 현재 들어오는 작업들과 관련된 구간(예를 들어, 시간 윈도우)를 강한 스파이크(strong spiky; SS) 구간, 중간 스파이크(middle spiky; MS) 구간, 또는 약한 스파이크(weak spiky; WS) 구간과 같이 레이블링(label)할 수 있다.
몇몇 실시 예들에서, 부하 분산기(406)는, 작업 부하들(예를 들어, 작업들 또는 요청들)을 분배하는 데 사용할 적절한 부하 분산 전략을 결정하기 위하여, 스파이크 검출기(404)에 의해 제공된 레이블을 사용할 수 있다. 몇몇 실시 예들에서, 부하 상태 정보 및 레이블에 기반하여, 부하 분산기(406)는 부하를 분산시키고 시스템 활용성을 개선하기 위하여 자원 노드들의 큐들 사이의 작업들(또는 요청들)을 분배할 수 있다. 예를 들어, 몇몇 실시 예들에서, 낮은 정도(또는 범위)의 버스티 작업 도착들(예를 들어, 약한 스파이크 구간) 동안에, 부하 분산기(406)는 minCV 부하 분산 전략에 기반하여 더 정확한 결정들을 내릴 수 있는 시간을 더 많이 가질 수 있다. 중간 정도(또는 범위)의 작업 도착들(예를 들어, 중간 스파이크 구간) 동안에, 부하 분산기(406)는 큐들의 작업 부하 상태에 대응하는 정보를 이용하는 JSQ 부하 분산 전략을 사용할 수 있다. 높은 정도(또는 범위)의 들어오는 트래픽(예를 들어, 높은 스파이크 구간) 동안에, 상태 정보는 지연될 수 있고, 따라서 부하 분산기(406)는 라운드 로빈 부하 분산 전략을 사용할 수 있다.
더 상세하게는, 도 5a는 본 발명의 실시 예에 따른, 제 1 모드 하에서 적절한 부하 분산 전략을 선택하는 방법을 나타내는 흐름도이고, 도 5b는 본 발명의 실시 예에 따른, 도 5a의 방법을 구현하기 위한 대응하는 의사코드(pseudocode)를 나타낸다.
도 5a 내지 도 5b를 참조하면, 블록(502)에서 할당된 작업 요청이 수신되는 경우(예를 들어, 클라우드 제공자로부터), 요청은 중앙 집중 큐(예를 들어, 도 2의 202)에 큐잉될 수 있다. 블록(504)에서, 시스템은 노드 풀이 여러 개의 큐들을 지니고 있는지 여부를 검사한다(예를 들어, 도 5b의 7번째 줄). 그렇지 않은 경우(예를 들어, 아니오), 오직 하나의 큐만 존재하므로 모든 작업 요청들은 블록(506)에서 하나의 큐로 분배된다. 한편, 노드 풀이 블록(504)에서 여러 개의 큐를 지니는 경우(예를 들어, 예), 시스템은 블록(508)에서 현재 시간이 새로운 전략 업데이트 윈도우에 대응하는지 여부를 결정한다(예를 들어, 도 5b의 10번째 줄). 예를 들어, 표 2는 두 개의 에폭(epoch) 윈도우들 및 제 1 모드에서 사용되는 그것들의 기능을 나타낸다.
에폭 윈도우 명칭 설명
전략 업데이트 윈도우(W_SU) 전략 업데이트 및 작업 부하 스파이크 레벨 검출 수행을 위하여 미리 설정된 빈도
큐 상태 업데이트 윈도우(W_QSU) 보고에서의 큐 상태 업데이트를 위한 현재 빈도
현재 시간이 블록(508)의 전략 업데이트 윈도우에 대응하지 않는 경우(예를 들어, 아니오), 부하 분산기(406)는 블록(510)에서 현재 에폭(epoch)의 부하 분산 전략을 변화시키지 않을 수 있다. 다시 말해서, 부하 분산 전략이 결정된 경우, 시스템은 블록(510)에서 해당 전략을 잠글 것이고, 부하 모니터(402)가 현재 부하 분산 전략을 디스패치하는 것을 돕기 위하여(필요하거나 요구되는 경우) 호출될 것이다. 이러한 “지연(lazy)” 전략 업데이트 빈도는 지속적으로 부하 분산 전략을 업데이트하는 것과 관련된 업데이트 비용을 줄일 수 있다.
한편, 현재 시간이 블록(508)의 전략 업데이트 윈도우에 대응하는 경우(예를 들어, 예), 스파이크 검출기(404)는 호출되어 중앙 집중 큐의 현재 트래픽의 스파이크 정도(또는 레벨)을 검출하고, 부하 분산기(406)로 스파이크 정도 결과를 전송할 것이다. 부하 분산기(406)는 스파이크 정도 결과들에 따라 전략들 사이에서 스위치할 수 있다(예를 들어, 도 5B의 10번째-18번째 줄). 예를 들어, 부하 분산기(406)가 블록(512)에서 스파이크 정도가 높은 스파이크 범위 내에 있다고 결정하는 경우, 블록(514)에서 라운드 로빈 부하 분산 전략이 활성화될 수 있다. 부하 분산기(406)가 블록(516)에서 스파이크 정도가 중간 스파이크 범위 내에 있다고 결정하는 경우, 블록(518)에서 JSQ 부하 분산 전략이 활성화될 수 있다. 부하 분산기(406)가 블록(520)에서 스파이크 정도가 약한 스파이크 범위 내에 있다고 결정하는 경우, 블록(522)에서 minCV 부하 분산 전략이 활성화될 수 있다. 부하 분산 전략이 결정된 이후, 시스템은 상술한 바와 같이 블록(510)에서 전략을 잠글 수 있다.
부하 모니터(402), 스파이크 검출기(404), 및 부하 분산기(406) 각각은 본 명세서에 사용되는 몇몇 기호들과 그들에 대응하는 설명들을 요약하는 표 3을 참조하여 더 자세히 설명될 것이다.
기호 설명
Figure pat00003
 큐 q에서 요청 i의 실제 작업 부하의 양. 작업의 전체 메이크스팬.
Figure pat00004
 요청 i의 작업 크기.
Figure pat00005
 요청 i의 연산 유형. 예를 들어, get, put, delete, 등.
Figure pat00006
 요청 i의 연산 유형에 대한 큐 q의 서비스 속도.
Figure pat00007
 큐 q에 큐잉된 모든 요청들의 전체 실제 작업 부하의 양.
Figure pat00008
 큐 q에 큐잉된 작업 요청들의 집합.
Figure pat00009
,
Figure pat00010
 각 클라우드 큐 영역/포트에서 큐 q 및 중앙 집중 큐 c. c는 중앙 집중 큐이고, 사용자 애플리케이션 레이어 큐들이 아니다.
Figure pat00011
.　
Figure pat00012
 큐 q 및 중앙 집중 큐 c에 큐잉된 요청들의 개수
Figure pat00013
 각각 큐 q 및 중앙 집중 큐 c의 미리 설정된 최대 크기.
Figure pat00014
 큐 k로 새로운 작업 요청 i가 할당된 경우, 큐 q에 큐잉된 모든 요청들의 전체 실제 작업 부하의 양. 큐 k는 큐 q와 같거나 또는 같지 않을 수 있으므로, 이것은 조각마다 정의된(piecewise) 함수이다.
Figure pat00015
 큐 k에 새로운 요청 i가 할당된 경우, 큐의 집합 Q의 모든 큐들에 큐잉된 모든 요청들의 전체 실제 작업 부하의 양의 평균.
Figure pat00016
 현재 클라우드 큐 영역의 큐들의 집합.
Figure pat00017
 클라우드 큐 영역의 큐들의 개수.
Figure pat00018
 영역의 각 큐의 전체 작업 부하의 양의 변동계수(coefficient of variation; CV). 이 값은 균형의 정도를 반영, 예를 들어, 변동계수 값이 클수록, 큐들에 걸쳐 더 많은 불균형이 존재한다.
Figure pat00019
 제곱 변동계수.
Figure pat00020
 스파이크 레벨, 또는 분산 인덱스. 이 값이 클수록, 스파이크 레벨이 높다.
Figure pat00021
,　
Figure pat00022
 식 3-3에 나타난 바와 같은 자기상관계수 함수에 대하여 반복하는 지연(lag) 값 및 미리 설정된 최대 지연 값(보통 아주 큰 값 또는 심지어 무한대)
Figure pat00023
 중앙 집중 큐에 큐잉된 작업 개수의 분산. 도착 분포는 광의의 정상 확률 프로세스를 따른다고 가정하며, 이는 시간에 무관한 프로세스라는 것을 뜻한다.
Figure pat00024
 자기상관계수 가중치 결과들을 조절하는 놉(knob). 보통, 2 또는 3으로 설정한다.
Figure pat00025
 각각 시간 t와　t+θ에서의 중앙 집중 큐에 큐잉된 작업 개수.
Figure pat00026
 각각 시간 t와　t+θ에서의 중앙 집중 큐에 큐잉된 작업 개수의 평균값.
상술한 바와 같이, 특정 작업의 작업 부하(예를 들어, 메이크스팬)은 다른 작업의 작업 부하와 서로 다를 수 있기 때문에, 보류 중인 작업들(또는 요청들)의 개수만을 고려하는 것은 충분하지 않을 수 있다. 따라서, 몇몇 실시 예들에서, 부하 모니터(402)는 작업들의 실제(또는 추정된) 작업 부하(예를 들어, 메이크스팬)에 기반하여 작업들을 변환함으로써, 작업들의 특징에 기반하여 작업들(예를 들어, 요청들)을 분류할 수 있다. 예를 들어, 몇몇 실시 예들에서, 부하 모니터(402)는 식 1에 나타난 바와 같이, 작업 요청의 크기를 요청의 연산 유형에 대한 큐 q의 서비스 속도로 나누어서 단일 작업(또는 요청)의 작업 부하의 양을 결정(예를 들어, 계산 또는 추정)할 수 있다.
Figure pat00027
비 제한적인 예를 들어, 1024KB 크기의 쓰기 입출력 작업 그리고 해당 큐의 쓰기 속도가 1024MB/sec인 경우를 고려하면, 작업 부하의 양(예를 들어, 실제 또는 추정된)은 약 0.001초이다. 따라서, 부하 모니터(402)는 식 1을 이용하여 작업의 작업 부하의 양을 계산하기 위하여, 작업의 크기 및 유형에 대한 정보뿐만 아니라, 해당 유형의 작업에 대한 각 큐의 서비스 속도에 대한 정보를 식별할 수 있다. 비록 동일한 클라우드 영역의 모든 큐들이 동일한 유형의 연산에 대하여 동일한 서비스 속도를 지닌다고 하더라도, 식 1은 동일한 유형의 연산에 대하여 균일하지 않은 서비스 속도를 지니는, 동일한 클라우드 영역의 큐들도 지원한다(예를 들어, 식 1의 분모 μ<vi,q>에 의하여 반영되는 바와 같이).
식 1에 기반하여, 큐 q의 모든 큐잉된 작업 요청들의 전체 작업 부하의 양은 식 2에 나타난 바와 같이 큐 q의 요청들의 모든 작업 부하의 양들을 더함으로써 더 계산될 수 있다.
Figure pat00028
그러나, 큐 작업 부하 상태를 자주 수집하고 계산하는 것은 비용이 많이 들 수 있다. 따라서, 몇몇 실시 예들에서, 에폭 윈도우(예를 들어, queueStatusUpdateWindow)는, 표 2에서 상술한 바와 같이, 주기적 “재보정(recalibrate)” 큐 상태를 설정하기 위하여 제공될 수 있다. 이로 인하여 오버헤드(overhead)가 감소할 수 있으나, 이는 분산된(degregated) 디스패칭 솔루션들을 초래할 수 있는 정보 지연을 발생시킬 수도 있다. 예를 들어, 높은 트래픽 시간(예를 들어, 높은 작업 요청 스파이크 시간) 동안, 이 지연은 지난 에폭에서 가장 유휴 상태였던 큐로 모든 작업들을 할당하는 것을 초래할 수 있는 반면, 다른 큐들은 큐잉된 작업들을 마치고 나면 유휴 상태가 된다. 이 불균형은 시스템 자원들을 낭비할 수 있을 뿐만 아니라, 백로그(backlog)들을 초래할 수 있다. 따라서, 몇몇 실시 예들에서, 스파이크 검출기(404)는 스파이크 레벨을 검출할 수 있고, 서로 다른 스파이크 레벨들에 대하여 서로 다른 부하 분산 전략들이 활성화될 수 있다.
예를 들어, 몇몇 실시 예들에서, 시스템이 스파이크 주기의 시작과 끝을 예측하는(또는 식별하는) 동안, 작업 요청 스파이크들을 단일 점수(예를 들어, 레벨 또는 정도 값)로 정성적으로 캡처할 수 있도록 시스템을 활성화하기 위하여, 스파이크 검출기(404)는 SCV-ACF에 기반한 스파이크 검출 방법을 활용할 수 있다. 예를 들어, 식 3에 나타난 바와 같이, 스파이크들의 레벨은 확률적 프로세스의 분산의 인덱스(
Figure pat00029
)로서 정의될 수 있다.
Figure pat00030
따라서, 몇몇 실시 예들에서, 스파이크 레벨은 자기상관계수 기반의 함수(ACF)의 제곱 변동계수(SCV)에 대응할 수 있다. 몇몇 실시 예들에서, 제곱 변동계수와 자기상관계수가 동시에 존재하는 것은 서로 다른 스파이크 정도를 지닌 작업의 작업 부하를 분류하기에 충분할 수 있다. 식 3에서, α는 자기상관계수의 가중치를 조절하기 위하여 미리 설정된 놉(예를 들어, 2 또는 3)을 의미하고, θ는 시간 t와 t+θ 사이의 지연 시간을 의미하며, σ는 중앙 집중 큐에 큐잉된 작업 개수의 분산을 의미한다. 몇몇 실시 예들에서, 식 2는 도착 분포가 광의의 정상 확률(stationary) 프로세스를 따른다고 가정하며, 이는 시간에 무관한 프로세스임을 의미한다. 결과적으로, 상관계수는 오직 한 쌍의 값들 사이의 시간-거리(또는 시간-구간)에 의존하고, 그들의 시간에서의 위치에 의존하는 것이 아니기 때문에, 자기상관계수는 오로지 지연 시간(θ)에만 의존한다.
도 6은 본 발명의 실시 예에 따른, SCV-ACF 기반 스파이크 검출 방법의 그래프를 나타낸다. 도 6의 그래프에서, 강한 스파이크는 참조 기호 SS로 표시되고, 중간 스파이크는 참조 기호 MS로 표시되고, 약한 스파이크는 참조 기호 WS로 표시된다. 도 6에 나타난 바와 같이, 대응하는 범위 내의 입출력 스트림 개수들은 스파이크 레벨이 어떻게 분류되어 있는지 결정할 수 있다. 예를 들어, 입출력 스트림 개수가 제 1 범위(예를 들어, 약한 스파이크 범위)에 존재하는 경우, 스파이크 레벨은 약한 스파이크(WS)로 분류될 수 있다. 입출력 스트림 개수가 제 2 범위(예를 들어, 중간 스파이크 범위)에 존재하는 경우, 스파이크 레벨은 중간 스파이크(MS)로 분류될 수 있다. 입출력 스트림 개수가 제 3 범위(예를 들어, 강한 스파이크 범위)에 존재하는 경우, 스파이크 레벨은 강한 스파이크(SS)로 분류될 수 있다. 따라서, 몇몇 실시 예들에서, 스파이크 검출기(404)는 스파이크 레벨 유형들의 범위들(예를 들어, 미리 설정된 범위들)에 기반하여 도 6에 나타난 현재 에폭의 각 작업 요청을 세 개의 스파이크 레벨들 중 하나로 분류할 수 있다.
도 7a는 본 발명의 실시 예에 따른, 스파이크 검출기(404)에 의해 결정된 각 스파이크 레벨에 대하여 대응하는 부하 분산 전략을 나타내는 블록도이고, 도 7b는 본 발명의 실시 예에 따른, 도 7a의 다양한 부하 분산 전략들을 구현하기 위한 대응하는 의사코드를 나타낸다.
상술한 바와 같이, 작업 부하 불균형은 자원 활용률 부족 및/또는 시스템 성능 저하를 초래할 수 있다. 부하 분산 도중 하나의 도전은 어떤 큐 상태 정보가 믿을 만한지 결정하는 것이다. 예를 들어, 지속적으로 큐 상태 정보(예를 들어, 작업 크기, 작업 유형, 큐의 서비스 속도, 및/또는 기타 등등)를 수집하는 것은 큰 오버헤드를 요구할 수 있는데 반하여, 오래된 상태 정보는 오래되었을 수 있다. 따라서, 몇몇 실시 예들에서, 시스템은 큐 상태 정보의 서로 다른 신뢰 레벨들에 기반하여 서로 다른 부하 분산 전략들 사이에서 스위치할 수 있도록 스파이크 레벨을 검출할 수 있다. 예를 들어, 높은 요구 트래픽 구간들(예를 들어, 높은 스파이크 레벨) 동안 수집된 큐 상태 정보는 낮은 트래픽 구간들(예를 들어, 약한 스파이크 레벨) 동안 수집된 큐 상태 정보에 비하여 일반적으로 덜 믿을 만 하다.
따라서, 도 7a에 나타난 바와 같이, 몇몇 실시 예들에서, 높은 트래픽 구간들(예를 들어, 높은 스파이크 레벨)(702) 동안, 부하 분산기(406)는 라운드 로빈 부하 분산 전략(704)을 선택할 수 있다. 중간 트래픽 구간들(예를 들어, 중간 스파이크 레벨)(706) 동안, 부하 분산기(406)는 JSQ 부하 분산 전략(708)을 선택할 수 있다. 낮은 트래픽 구간들(예를 들어, 약한 스파이크 레벨)(710) 동안, 부하 분산기(406)는 minCV 부하 분산 전략(712)을 선택할 수 있다. 이러한 전략들 각각에 대해서는 아래에서 더 상세하게 설명될 것이다.
높은 트래픽 구간들(예를 들어, 부하 모니터(402)에 의하여 많은 개수의 요청들이 검출된)의 경우, 부하 분산기(406)는 라운드 로빈 부하 분산 전략을 활성화할 수 있는데, 이는 큐 상태 정보 또는 복잡한 부하 분산 계산들이 필요하지 않기 때문에 낮은 오버헤드를 갖거나 또는 오버헤드를 갖지 않는다. 예를 들어, 이러한 높은 트래픽 구간들 동안에는, 각 큐의 작업 부하의 양을 결정하는 데 비용이 많이 들 수 있고, 큐 상태 정보는 높은 트래픽으로부터의 지연들로 인하여 종종 오래될 수 있다. 이러한 지연들은, 예를 들어, 이전의 가장 낮은 작업 부하를 갖는 큐에 모든 작업 요청들을 전송함으로써 시스템을 오작동시킬 수 있는데, 이는 그 큐의 포화로 인하여 불균형을 초래할 수 있다. 다시 말해서, 큐 상태 정보가 신뢰될 수 없고, 많은 양의 높은 트래픽에 대하여 복잡한 계산들을 수행할 시간이 없기 때문에, 높은 트래픽 구간들 동안 라운드 로빈 부하 분산 전략이 활성화될 수 있다.
예를 들어, 몇몇 실시 예들에서, 식 4에 나타난 바와 같이, 시스템은 이전 큐의 개수 k를 유지할 수 있고, 각 새로운 작업 요청에 대하여 1을 더할 수 있다. 큐의 개수 k가 한계 값을 초과하는 경우, 식 4에 나타난 바와 같이, 다시 0으로 되돌아간다(예를 들어, 큐의 개수가 0부터 Nq-1까지이므로).
Figure pat00031
식 4에 나타난 바와 같이, 좌변의 k는 새로운 작업 요청을 할당하기 위한 k의 다음 라운드 선택을 나타내고, 이 k 값은 그 이전 값(k+1)에 기반한다. 라운드 로빈 부하 분산 전략이 새로운 작업 요청의 특징에 독립적이기 때문에, 식 5에 나타난 바와 같이, 선택된 큐(모든 다른 큐들도 마찬가지로)가 가득 차지 않았는지 확인해야 한다는 제약이 있다.
Figure pat00032
중간 트래픽 구간들의 경우, 부하 분산기(406)는 JSQ 부하 분산 전략을 활성화할 수 있고, 이는 다른 큐들이 유휴 상태인 동안 임의의 하나의 큐가 보류 중인 여러 작업들을 지니고 있을 확률을 감소시키면서 큐들에 걸쳐 부하를 분산하는 것을 목표로 한다. 중간 트래픽 구간들 동안, 큐 상태 정보 및 실제 큐 상태의 지연은 높은 스파이크 레벨 에폭들의 지연보다 작기 때문에, 지연된 큐 상태 정보는 높은 스파이크 상황들에 비하여 더 믿을 만 할 수 있다. 따라서, 중간 트래픽 구간들 동안, 부하 분산기(406)는 더 자세한 큐 상태 정보를 수신하고 활용할 수 있는 시간이 더 있을 수 있다.
다양한 실시 예들에서, JSQ 부하 분산 전략은 큐잉된 작업들의 개수 및/또는 실제(또는 추정된) 작업 부하의 양에 기반하여 구현될 수 있다. 예를 들어, 몇몇 실시 예들에서, JSQ 부하 분산 전략은 단순히 작업 부하의 양을 나타내는 큐잉된 작업들의 개수를 이용할 수 있다. 이 구현 방법은 전체 시스템 활용률이 매우 높은 경우들에 유리할 수 있는데, 각 큐의 실제(또는 추정된) 작업 부하의 양들을 이용하는 것에 비하여 빠르기 때문이다. 따라서, 몇몇 실시 예들에서, 부하 분산기(406)는 식 6에 나타난 바와 같이, 큐잉된 요청의 개수가 가장 적은 큐로 들어오는 작업 요청을 할당하기 위하여 JSQ 부하 분산 전략을 활성화할 수 있다.
Figure pat00033
몇몇 실시 예들에서, 큐들의 집합 Q에 대하여, 식 6은 식 7에 나타난 바와 같이 작성될 수 있다.
Figure pat00034
큐잉된 작업들의 개수를 이용하는 것이 각 큐의 실제(또는 추정된) 작업 부하의 양들을 이용하는 것보다 빠를 수 있는 반면에, 큐잉된 작업들의 개수는 작업들 사이의 부하 차이들을 고려하지 않기 때문에 트레이드오프는 정확성일 수 있다. 따라서, 몇몇 실시 예들에서, 실제(또는 추정된) 작업 부하의 양을 더 정확하게 반영하기 위하여, 부하 분산기(406)는 JSQ 부하 분산 전략을 활성화하여, 새로운 작업 요청의 (변환된) 작업 부하의 양을 더함으로써 각 큐의 실제(또는 추정된) 작업 부하의 양을 더 계산할 수 있다. 예를 들어, 몇몇 실시 예들에서, 부하 분산기(406)는 먼저, 큐 k로 새로운 작업 요청 i가 할당된 경우, 큐 q에 존재하는 모든 작업 요청들의 전체 실제 작업 부하의 양을 정의할 수 있다. 주어진 k에 대하여, 큐 q의 전체 작업 부하의 양은 식 8을 이용하여 계산될 수 있다.
Figure pat00035
식 8에 나타난 바와 같이, k는 q와 같을 수도 있고 또는 같지 않을 수도 있으므로, 식 8은 조각마다 정의된 함수이다. 따라서, 식 9에 나타난 바와 같이, 최적화 프레임워크는 부하가 가장 낮은 큐 k(큐가 가득 차지 않은 경우, 새롭게 추가된 작업을 포함하여)를 찾는 것이 될 수 있다. 따라서, 부하 분산기(406)는 식 9를 이용하여, 큐잉된 요청들의 실제(또는 추정된) 양이 가장 적은 큐로 들어오는 요청을 할당할 수 있다.
Figure pat00036
몇몇 실시 예들에서, 주어진 큐들의 집합 Q와 새로운 작업 요청 i에 대하여, 식 9는 식 10에 나타난 바와 같이 작성될 수 있다.
Figure pat00037
낮은(또는 약한) 트래픽 구간들의 경우, 부하 분산기(406)가 실제(또는 추정된) 작업 부하의 양 및 더 정확한 균형 정도(분산된 정도) 측정을 둘 다 고려하는 완전한 최적화를 수행할 시간을 더 가질 수 있기 때문에, 부하 분산기(406)는 minCV 부하 분산 전략을 활성화할 수 있다. 몇몇 실시 예들에서, 실제(또는 추정된) 작업 부하의 양은 예를 들어, 상술한 식 1 및 식 2를 이용하여 계산될 수 있다. 균형 정도 측정은 표준편차(예를 들어, 분산(variance)의 제곱근)를 이용하여 계산될 수 있으나, 평균과 동일한 단위들(예를 들어, 입력들의 절대값)을 요구한다. 따라서, 몇몇 실시 예들에서, 부하 분산기(406)는, 평균에 대한 표준편차의 비에 해당하는, 상대적 표준편차(Relative Standard Deviation; RSD)라고도 알려진 변동계수(CV)를 이용하여, 큐 작업 부하 분포의 분산(dispersion)을 계산할 수 있다. 예를 들어, 몇몇 실시 예들에서, 임의의 주어진 k(작업 요청이 할당될 선택된 큐에 대응하는)에 대하여, 부하 분산기(406)는 식 11을 이용하여 큐 집합 Q의 모든 큐들에 큐잉된 모든 요청들의 전체 실제 작업 부하의 양의 평균을 계산할 수 있다.
Figure pat00038
부하 분산기(406)는 그 다음, 식 12에 나타난 바와 같이 표준편차를 식 11에서 계산된 평균으로 나눔으로써 변동계수(식 12에서 Ω으로 표시됨)를 계산할 수 있다.
Figure pat00039
식 12에 나타난 바와 같이, 새로운 요청 i를 수락하기 위하여 주어진 선택된 큐 k에 대하여, 새로운 요청이 k에 추가된 이후 큐 집합 Q의 모든 큐들의 균형 정도는 Ω<Q,k,i>이다. 이 경우, 더 작은 변동계수 값(Ω)은 클라우드 영역/포트에서의 더 나은 부하 분산(균형) 결과를 나타낸다. 따라서, 몇몇 실시 예들에서, 부하 분산기(406)는, 불균형 정도를 최소화 또는 감소시키는 것을 목적으로 하는 식 13을 이용하여, minCV 부하 분산 전략을 구현할 수 있다.
Figure pat00040
식 13에 나타난 바와 같이, 최적화 프레임워크 minCV는 세 가지 제약(예를 들어, 식 13의 s.t.) 하에서 목적 함수(objective function)를 최소화 또는 감소시킬 수 있도록 제공된다. 첫 번째 제약은 q(반복되는 큐) 및 k(새로운 작업을 할당할 큐)가 영역 상의 모든 사용 가능한 큐들의 집합에 포함되는지 여부를 확인한다. 두 번째 및 세 번째 제약들은 큐들이, 작업 요청 개수들의 단위로 미리 설정된 큐 용량(예를 들어, |q|max 및 |k|max)을 초과하여 큐잉하지 않도록 해야 한다는 것을 확인한다. 이 최적화된 프레임워크는 minCV라고 불리는데, 식 14에 나타난 바와 같이, 변동계수의 최소값을 얻기 위하여 k를 식별함으로써 큐의 실제 작업 부하 양들의 변동계수를 최소화하는 것을 목적으로 하기 때문이다.
Figure pat00041
도 8은 본 발명의 실시 예에 따른, 부하 분산을 위한 제 2 모드 하에서 동작하는 부하 분산 시스템(800)의 블록도이다. 도 9는 본 발명의 실시 예에 따른, 부하 분산 시스템(800)의 시스템도이다. 아래에 더 자세히 설명되는 바와 같이, 제 2 모드는 인덱스(예를 들어, 기틴스 인덱스)를 이용하여 특정 작업 완료 시간 내 스파이크 값들을 예측하는, 머신 러닝(예를 들어, 강화 학습) 기반 방법이다. 몇몇 실시 예들에서, 제 2 모드 하에서 동작하는 경우, 시스템은 설정(구성)된(예를 들어, 미리 설정된) 범위들(예를 들어, 약한 스파이크 범위, 중간 스파이크 범위, 및 강한 스파이크 범위)에 기반하여 분류되는 제 1 모드에서의 스파이크 레벨들 대신, 스파이크 값들의 스펙트럼에 응답하여 활성화될 수 있다. 나아가, 몇몇 실시 예들에서, 제 2 모드 하에서 동작하는 경우, 시스템은 미리 설정된 제 1 모드에서의 부하 분산 전략들(예를 들어, 라운드 로빈, JSQ, 및 minCV)에 제한되는 대신, 시간에 걸쳐 변화하는 작업 부하 조건들에 따라 부하 분산 전략들을 동적으로 조절할 수 있도록 활성화될 수 있다. 몇몇 실시 예들에서, 제 2 모드 하에서 동작하는 시스템은 만료 기한을 갖는 작업 요청들(예를 들어, 이하에서 또한 시간에 민감한 작업 요청들이라고 불리는)을 지원할 수 있도록 활성화될 수 있고, 및/또는 버스티 트래픽 구간들에 응답하여 자원들을 동적으로 추가 또는 제거할 수 있다.
도 8 내지 도 9를 참조하면, 몇몇 실시 예들에서, 시스템(800)은 오케스트레이터(orchestrator, 802), 트래픽 모니터(804), 인덱스 정책 필터(index policy filter)(806), 부하 에이전트(또는 부하 분산 에이전트)(812), 한계 계산기(bound calculator)(808), 구성 로직(810), 및 자원 풀(또는 가상 머신 풀) 스케줄러(814)를 포함할 수 있다. 몇몇 실시 예들에서, 트래픽 모니터(804)는 중앙 집중 큐(예를 들어, 도 2의 202)를 모니터링할 수 있고, 중앙 집중 큐의 상태 정보를 송신할 수 있다. 몇몇 실시 예들에서, 인덱스 정책 필터(806)는 타임 윈도우 결정들을 포함한 시간이 중요한(time-critical) 정보를 관리할 수 있다. 몇몇 실시 예들에서, 부하 분산 에이전트(812)는 머신 러닝 방법들(예를 들어, 강화 학습(Q-학습))에 기반하여 다양한 부하 분산 전략들을 활성화할 수 있다. 예를 들어, 몇몇 실시 예들에서, 도 9에 나타난 바와 같이, 부하 분산 에이전트(812)는 선택된 부하 분산 전략에 따라 자원 노드들의 풀로 부하를 분배할 수 있고(예를 들어, 행동), 부하 분산 전략에 응답하여 자원 노드들의 풀의 상태를 관찰할 수 있고(예를 들어, 상태 관찰), 관찰된 상태에 기반하여 보상을 계산할 수 있고(예를 들어, 보상), 그리고 보상에 기반하여 부하 분산 전략을 조절할 수 있다. 몇몇 실시 예들에서, 한계 계산기(808)는 작업 요구량을 만족하기 위한 부하 분산 에이전트(812)의 신뢰도를 통신할 수 있다. 몇몇 실시 예들에서, 구성 로직(810)은 자원들을 추가 또는 제거할 수 있도록(예를 들어, 자원 풀로부터) 부하 분산 에이전트(812)를 활성화시킬 수 있다. 몇몇 실시 예들에서, 자원 풀 스케줄러(814)는 적절한 큐로 스케줄될 작업 요청들을 준비할 수 있다.
간략한 개요 상에서, 시스템(800)은 두 개의 주요 단계들로서 검출 단계(detection phase) 및 보급 단계(dissemination phase)로 나누어질 수 있다. 몇몇 실시 예들에서, 트래픽 모니터(804) 및 인덱스 정책 필터(806)는 검출 단계(예를 들어, 스파이크 검출 및 시간이 중요한 작업 요청 기능들)에 주로 수반되고, 부하 분산 에이전트(812), 한계 계산기(808), 구성 로직(810), 및 자원 풀 스케줄러(814)는 보급 단계(예를 들어, 부하 분산 및 동적 자원 조절)에 주로 수반된다. 몇몇 실시 예들에서, 한계 계산기(808)는 부하 분산 행동을 위한 검출 정보를 처리하는 학습 “글루(glue)”로 간주될 수 있다.
몇몇 실시 예들에서, 검출 단계 동안, 오케스트레이터(802)는 작업 요청 도착들에 대하여 로컬 트래픽 모니터(804)로부터 입력을 수신한다. 작업 요청 도착들은 버스트의 각 윈도우가 타임 스탬프(time stamped)되는 인덱스 정책 필터(806)를 통하여 통과된다. 예를 들어, 기틴스 인덱스가 0.7인 것은 70%의 작업 요청들은 시간 간격의 절반 내에 도착하고, 나머지 30%의 작업 요청들은 시간 간격의 나머지 절반 내에 도착한다는 것을 의미한다. 몇몇 실시 예들에서, 이 도착 과정 동안 두 종류의 행동들이 취해질 수 있다. 취해질 수 있는 첫 번째 행동은 트래픽을 선점하기 위한 전체 최적 전략이고, 두 번째 행동은 기틴스 인덱스의 계산이다. 몇몇 실시 예들에서, 계산 자원들을 할당하기 위한 최적의 전략은 시간에 걸쳐 트래픽 구성이 시간에 따라 어떻게 증가하는지에 기반하여 계산될 수 있다.
예를 들어, 초기 구성은 두 개의 시간 구간으로 나누어진 윈도우로 시작할 수 있고, 기틴스 인덱스 계산에 따라 시간 축의 각 절반에서 다수의 요청들에 대한 자원들이 점진적으로 생성될 수 있다. 출력은 한계 계산기(808)로 전송될 수 있고, 그 곳에서 예측된 스파이크 요구에 기반하여 증분 부하 값(incremental load value)이 계산될 수 있다. 계산된 증분 부하 값은 그 후 다음 단계(예를 들어, 보급 단계)에서, 예를 들어, 자원들을 재할당하는 데 이용될 수 있다.
보급 단계 동안, 오케스트레이터(802)는 초기 할당의 변화에 사용되는 자원 증분(I)을 측정할 수 있고, 원하는 자원 요구의 재계산(re-computation)을 수행할 수 있다. 이것은 구성 로직(810)의 입력으로서 주어질 수 있다. 따라서, 보급 단계는 클라우드의 자원 프로비저닝(provisioning)에 필수적인 역할을 하는 인프라 구조와 협력하여 작동할 수 있다. 예를 들어, 구성 로직(810)은 서비스 수준 협약(SLA) 또는 서비스의 질(QoS)의 서비스 요구들을 맞추는(tailoring) 요청된 자원 가상 머신의 체이닝(chaining, 연쇄적 처리)을 수행할 수 있다.
몇몇 실시 예에 따르면, 기틴스 인덱스에 기반한 스파이크 지시 파라미터는 아주 적은 수의 파라미터들을 가지고도 특정된 작업 완료 시간 내의 스파이크 값을 예측할 수 있도록 시스템(800)을 활성화할 수 있다. 이것은 시스템(800)을 활성화하여 작동자의 이익을 최대화하는 동시에 부하를 분산시킬 수 있도록 한다. 예를 들어, 버스티한 정도(burstiness)는 단일 파라미터에 기반하여 설명될 수 있고, 이 파라미터는 트래픽 행동을 학습하는 것을 허용할 수 있고 그리고 작동자에게 즉시(on the fly) 피드백을 제공할 수 있다. 더 상세하게는, 몇몇 실시 예들에서, 모델 피팅(model fitting) 및 트레이스 생성(trace generation)은 효율적인데, 데이터의 크기에 따라 선형적으로 스케일링되기 때문이다. 몇몇 실시 예에 따르면, 시스템(800)은 머신 러닝 전략으로서 강화 학습을 활용하는데, 강화 학습은 “빨리 실패하면 빨리 배우는(fail-fast-learn-fast)” 접근법이기 때문이다.
예를 들어, 몇몇 실시 예들에서, 엔트로피(entropy)는 이산 확률함수 P의 균일성으로서 정의될 수 있다. 확률 pi를 가지는 사건 P에 대한 엔트로피 값 E(P)는 식 15에서 정의된다.
Figure pat00042
식 15의 변수들은 표 4에서 정의된다.
기호 설명
Figure pat00043
 사건 P의 엔트로피
Figure pat00044
 사건 P의 확률
Figure pat00045
 엔트로피 계산
식 15에 나타난 바와 같이, 모든 확률 값들이 같을 때(또는 동일할 때), 엔트로피는 최대값에 도달한다. 한편, 하나의 사건이 지배하는 경우, 엔트로피는 0에 접근한다. 따라서, 몇몇 실시 예들에서, 엔트로피는 버스티한 정도(burstiness)를 나타내고, 버스티한 정도의 전역 값 그 자체는 허스트(Hurst) 파라미터에 의하여 판단된다. 실제로 그것은 자기 유사성(self-similarity)의 개념이지만, 자기 유사 프로세스들이 항상 버스티한 시퀀스를 생성하는 것은 아니다. 또한, 허스트 파라미터는 대규모 시간 단위의 사용량과 관련이 있다. 따라서, 몇몇 실시 예들에서, 영감(inspiration)은 기틴스 인덱스(Gittins index; GI)라고 불리는 통계적 인덱스로부터 도출된다.
전형적으로, 기틴스 인덱스는 하나의 시간 간격 내의 요청들의 경계를 정하는 파라미터로서 사용된다. 예를 들어, 기틴스 인덱스가 0.7인 것은 70%의 작업 요청들은 시간 간격의 절반 내에 도착하고, 나머지 30%의 작업 요청들은 시간 간격의 나머지 절반 내에 도착한다는 것을 의미한다. 이러한 도착 프로세스 동안, 두 종류의 행동들이 취해질 수 있는데, 하나의 행동은 선점된(pre-empting) 트래픽에 대한 전체 최적의 전략이고, 다른 하나의 행동은 기틴스 인덱스의 계산이다. 몇몇 실시 예들에서, 계산 자원들을 할당하는 최적의 전략은 트래픽 구성이 시간에 걸쳐 어떻게 증가하는지에 기반하여 결정될 수 있다. 예를 들어, 초기 구성은 2-시간 분할(two-time division)로 시작하고, 기틴스 인덱스 계산에 따라 시간 축의 각 절반에서 생성되는 요청들의 개수에 걸쳐 점진적으로 반복된다. 몇몇 실시 예들에서, 얼마나 빠르게 기틴스 인덱스가 계산될 수 있는지는 의도한 바가 아니지만, 대신에, 트래픽 특성들을 학습하기 위한 입력으로서의 인덱스를 사용함으로써 얻어지는 통찰력이다. 예를 들어, 몇몇 실시 예들에서, 기틴스 인덱스의 값이 1에 접근함에 따라, 균일 트래픽 인덱스 값들은 전형적으로 약 0.5이기 때문에 높은 트래픽 불규칙성이 가정될 수 있다.
몇몇 실시 예들에서, 제 2 모드(예를 들어, 학습 모드)는 임의의 분포를 제공하는 데 사용될 수 있다(예를 들어, 균일 분포를 제공하기 위한 제 1 모드와는 다르게). 예를 들어, 몇몇 실시 예들에서, 제 2 모드는 특별한 경우의 시나리오로서 균일 분포를 포함할 수 있다. 몇몇 실시 예들에서, 제 2 모드 하의 대부분의 시나리오들에서 고려되는 트래픽은 항상 자기 유사(self-similar)하지는 않은 포아송(Poisson) 트래픽으로서 설명될 수 있다. 예를 들어, 멀티미디어부터 게임 애플리케이션, 웹 애플리케이션에 달하는 범위의 서로 다른 사용자 요청들은, 이러한 환경들에서 서비스의 질(QoS)를 관리할 과감한 필요성을 보여주었다. 전형적으로, 네트워크 상의 부하가 일반적인 부하 척도를 초과할 경우, 이러한 변화를 관리할 필요가 있다. 따라서, 이러한 분포들은 임의적이고 인덱싱 가능한(indexable) 보호 아래로 가져와질 필요가 있다. 다시 말해서, 제 2 모드의 인덱싱 가능성(indexability)은 비-머신 러닝(non-machine learning) 문제를 머신 러닝 문제로 변환하는 것을 활성화할 수 있다. 몇몇 실시 예들에서, 함수는 전체 트래픽 인덱싱을 쉽게 만드는, 단조 증가 함수이다. 나아가, 몇몇 실시 예들에서, 도착 분포는 트래픽 도착에 대한 전사 함수(onto function)로 맵핑(mapped)될 수 있다.
몇몇 실시 예들에서, 기틴스 인덱스는 작업 선점을 가능하게 하는데, 즉, 선착순(first come first serve; FCFS) 작업 완료 대신, 시간이 중요한 작업들이 먼저 처리될 수 있다. 예를 들어, 큐잉된 모든 작업들이 두 유형들, 즉, 최대 효율(best effort) 트래픽 및 시간 민감(time sensitive) 트래픽으로 나누어지는 시나리오를 생각해 보자. 몇몇 실시 예들에서, 기틴스 인덱스에 기반한 새로운 도착 시간 및 스케줄은 큐에 정체되어 있거나 누구의 자원 점유인지 알려지지 않은 트래픽을 정체시키기 위하여 계산된다.
더 상세하게는, 도 10a는 본 발명의 실시 예에 따른, 스파이크 검출 방법을 나타내는 흐름도이고, 도 10b는 본 발명의 실시 예에 따른, 도 10a의 스파이크 검출 방법을 구현하기 위한 대응하는 의사코드를 나타낸다. 도 8, 도 9, 도 10a, 및 도 10b를 참조하면, 몇몇 실시 예들에서, 제어의 흐름은 검출로부터 시작한다. 검출이 발생한 경우, 인덱스(예를 들어, 기틴스 인덱스)는 트래픽이 시간이 중요한 트래픽 및 최대 효율 트래픽으로 나누어질 수 있도록 한다. 마찬가지로, 인덱스는 얼마나 버스티한지 및 허스트 파라미터로부터 정의된 버스트의 정도에 기반하여 트래픽을 특성화할 수 있다. 몇몇 실시 예들에서, 버스트 요청을 만족시키기 위해, 이러한 시나리오들에서 더 많은 자원 요구사항들이 요구될 수 있는데, 이는 새로운 가상 계산 환경(virtual compute environment)을 구성함으로써 만족된다. 몇몇 실시 예들에서, 부하 분산기는 한계 계산 파라미터들(예를 들어, 한계 계산기(808)에 의하여 계산되는 바와 같이) 및 새로운 부하 증분 값(예를 들어, 버스트의 정도에 기반하여)을 포함한다. 몇몇 실시 예들에서, 작업들의 시간이 중요한 본질은 인덱스 정책 필터(806) 및 트래픽 모니터(804) 둘 다에 의하여 모니터링될 수 있다.
예를 들어, 몇몇 실시 예들에서, 작업 요청들이 큐잉됨에 따라(예를 들어, 도 2의 중앙 집중 큐(202)에), 트래픽 모니터(804)는 스파이크 검출을 위하여 큐를 모니터링한다. 몇몇 실시 예들에서, 트래픽 모니터(804)는 트래픽을 분리하기 위하여 기틴스 인덱스 메트릭(metric)을 계산할 수 있다. 예를 들어, 표 5는, 몇몇 실시 예들에 따라, 스파이크 검출에 사용되는 알고리즘들의 일부 기호들 및 관련된 설명들을 정의한다.
기호 설명
Figure pat00046
,
Figure pat00047
 상태 α, 중단 집합(stopping set) S(α), 계속 집합(continuing set) C(αk)
Figure pat00048
,
Figure pat00049
 'α'에 대한 기틴스 인덱스 값, 전역적으로 초기화된 기틴스 인덱스 값
Figure pat00050
,
Figure pat00051
 중단 집합 S(α)를 완전히 트래버스(traverse)하는 데 소요되는 시간T(S(α)), t>0: Xt∈S(α), 디스카운트(discount) 파라미터
Figure pat00052
,　
Figure pat00053
 상태 공간(Xt)에 대한 보상T(S(α)), t>0: Xt∈S(α), 단위 행렬
Figure pat00054
 마르코비안(Markovian) 업데이트 함수
Figure pat00055
 기틴스 인덱스(GI) 계산식
Figure pat00056
 사전 지식에 기반한 보상의 기대값
Figure pat00057
 베이지안(Bayesian) 기대값의 최대값
도 10a 내지 도 10b를 참조하면, 시간 t=t1에서, 네트워크는 첫 번째 스파이크를 수신한다. 여기서 내려져야 할 결정(예를 들어, 도 10a의 흐름도의 최종 결정)은 성공적인 스파이크 검출로 불릴 수 있다. 따라서, 도 10a의 흐름도에 의하여 결정되는 다른 임의의 값들은 실패로 간주될 수 있다. 예를 들어, 도 10a의 흐름도에 의하여 내려지는 결정은 성공들과 실패들의 베르누이(Bernoulli) 결정을 따를 수 있다. 몇몇 실시 예들에서, 이 문제는 서비스 속도에 기반하여 지수적으로 진화할 수 있기 때문에, 이 문제는 NP-완전(NP(Non Polynomial)-complete)으로 증명될 수 있다(또는 다시 말해서, 서비스 속도의 증가가 다항식이 아닌 계산 시간의 증가를 초래할 수 있다). 따라서, 몇몇 실시 예들에서, 스칼라는 정지 시간(stopping time)(T)에 기반하여 모델링될 수 있고, 이는 검출 단계가 보급 단계로 전이하는 시간을 의미한다.
예를 들어, 블록(1005)에서, 트래픽 모니터(804)는 초기화할 수 있다. 초기화 과정 동안, 트래픽 모니터(804)는 식 16을 이용하여 최대 기틴스 인덱스(GI)인 ζ를 결정할 수 있다. 상태 α에 대한 중단 단계(stopping phase)는 S(α)로 정의되며, α1이 최대 기틴스 인덱스를 갖는 경우 ζ=S(α1)이다.
Figure pat00058
블록(1010)의 상태 α1에 대한 중단 단계 S 동안, 블록들(1015, 1020, 및 1025)은 α1 상태에 대하여 반복되고, 그런 경우 C(αk)=α1…αk-1 가 다음 k번째로 큰 기틴스 인덱스를 나타낸다면 이는 식 17에 의하여 표현될 수 있다.
Figure pat00059
식 17에서, Pa,b는
Figure pat00060
행렬을 이용한 보상 함수를 나타낸다. 나아가, I가
Figure pat00061
단위 행렬인 경우, 두 개의 보조 식(식 18 및 19)을 먼저 이용하여 기틴스 인덱스(GI)의 값을 계산할 수 있다.
Figure pat00062
Figure pat00063
식 18 및 식 19에 기반하여, 기틴스 인덱스의 값(GI)은 식 20으로부터 계산될 수 있다.
Figure pat00064
기틴스 인덱스(GI)의 값이 계산되고(예를 들어, 블록(1015)에서), 정렬되고(예를 들어, 블록(1020)에서), 그리고 k번째로 큰 값으로 결정된(예를 들어, 블록(1025)에서) 이후, 기틴스 인덱스 값(예를 들어, k번째로 큰 기틴스 인덱스 값)은 기틴스 값의 임계 값(예를 들어, 이 예시에서는 0.5)과 비교되어 시간 T에 대한 최고 완성 속도(best completion rate)를 결정하며, 이는 중단 시간에 해당한다. 이 경우, 기틴스 인덱스(GI)가 기틴스 인덱스 임계 값보다 큰 경우, 블록(1035)에서 부하 분산 에이전트(812)를 호출하기 위하여 버스트 플래그는 켜짐(on)으로 설정된다.
도 11a 내지 도 11c는 본 발명의 실시 예에 따른, 들어오는 트래픽 분석을 위한 인덱스 정책 필터의 예시들을 나타낸다. 도 11a 내지 도 11c에 들어오는 트래픽의 비-제한적 예시 파형이 나타나 있지만, 본 발명은 도 11a 내지 도 11c에 나타난 예시들에 제한되지 않으며, 들어오는 트래픽의 실제 파형들은 여기에 나타난 것과 다를 수 있다. 몇몇 실시 예들에서, 모니터링 단계 이후, 인덱스 정책 필터(806)는 들어오는 트래픽의 적절한 스파이크 값(예를 들어, 버스트 값)을 결정하기 위하여 들어오는 트래픽을 인덱싱 가능성에 기반하여 마킹(mark)할 수 있다. 예를 들어, 몇몇 실시 예들에서, 인덱스 정책 필터(806)는 기틴스 인덱스 값들을 이용하여 버스트에 대한 다양한 분포들을 가진 들어오는 트래픽을 분석한다. 기틴스 인덱스는 버스트로 간주되는 최대값을 나타내는 선형 스케일을 제공한다.
예를 들어, 몇몇 실시 예들에서, 인덱스 정책 필터(806)는 기틴스 인덱스(GI) 분석기(1105)를 포함할 수 있다. 몇몇 실시 예들에서, 기틴스 인덱스 분석기(1105)는 윈도우의 스텝들 상의 도착 그룹들에 대한 기틴스 인덱스를 계산하고, 윈도우에 대한 스파이크 값에 대응하는 대표값(예를 들어, 버스트 값)을 출력할 수 있다. 예를 들어, 도 11에 나타난 바와 같이, 기틴스 인덱스 분석기(1105)는 무작위로 변화하는 스파이크 값들(예를 들어, 기틴스 인덱스 값들)을 생성하기 위하여 들어오는 트래픽을 분석할 수 있다. 도 11a에 나타난 바와 같이, 최고 버스트(예를 들어, 최고 버스트 값)를 지닌 트래픽 도착의 선형적 증가는 분리될 수 있다. 도 11b에 나타난 바와 같이, 선형적으로 증가하는 버스트 값들은 기틴스 인덱스 분석기(1105)로 하여금 최고값(예를 들어, 최고 버스트 값)을 새로운 스파이크 값으로서 출력할 수 있도록 할 수 있다. 도 11c에 나타난 바와 같이, 무작위의 값들을 포함하는 서로 다른 집합의 증가하는 버스트 값들은 기틴스 인덱스 분석기(1105)로 하여금 최고값(예를 들어, 최고 버스트 값)을 새로운 스파이크 값으로서 출력할 수 있도록 한다.
도 12는 본 발명의 실시 예에 따른, 버스트 값을 생성하기 위한 예시적인 방법을 나타내는 흐름도이다. 도 12를 참조하면, 들어오는 트래픽은 블록(1205)에서 인덱스 정책 필터(806)에 의하여 수신된다. 들어오는 트래픽은 블록(1210)에서 인덱스 정책 필터(806)에 의하여 검사된다. 예를 들어, 몇몇 실시 예들에서, 인덱스 정책 필터(806)는 도착 그룹들을 복수의 윈도우 스텝들로 분리할 수 있다. 분석 윈도우 상의 스텝들 각각의 기틴스 인덱스 값들은 블록(1215)에서 계산될 수 있다. 예를 들어, 인덱스 정책 필터(806)는 분석 윈도우 상의 스텝들 각각에 대하여 기틴스 인덱스를 계산할 수 있다. 최대 대표값은 블록(1220)에서 기록될 수 있다. 예를 들어, 인덱스 정책 필터(806)는 분석 윈도우 상의 스텝들 중에서 최대 기틴스 인덱스 값을 식별할 수 있고 기록할 수 있다. 선형 인덱스 측정은 블록(1225)에서 이루어진다. 예를 들어, 기록된 기틴스 인덱스 값은 버스트에 대하여 고려되어야 할 최대값을 나타내기 위한 선형 스케일을 제공한다.
몇몇 실시 예들에서, 검출 단계가 완료된 이후, 새로운 스파이크 값들은 새로운 부하 요구들을 생산하는 데 사용된다. 예를 들어, 몇몇 실시 예들에서, 한계 계산기(808)는 풀링(pooled)될 예정인 요구되는 자원(예를 들어, 자원 풀로부터)을 결정하기 위하여 한계를 계산할 수 있다. 몇몇 실시 예들에서, 한계 계산이 결정된 이후, 모든 앞으로의 스파이크 변형들은 훈련되고 부하 요구는 만족될 수 있다. 한계 계산기(808)는 도 14 내지 도 15b를 참조하여 더 상세히 설명될 것이다.
이후에서는, 트래픽 조건들에 응답하여 자원들을 할당하기 위한 부하 분산 에이전트(812)의 측면들과 특징들이 더 자세히 설명될 것이다. 몇몇 실시 예들에서, 부하 분산 에이전트(812)는 입력 부하를 만족시키기 위하여 선택된 노드들(예를 들어, 가상 머신들, 컨테이너들, 및/또는 기타 등등) 상에서 결정들을 내리기 위하여 필요한 파라미터들을 처리할 수 있다. 표 6은 몇몇 실시 예들에 따라, 한계 계산기(808) 및 부하 분산 에이전트(812)에 의하여 사용되는 알고리즘들의 일부 기호들 및 관련된 설명들을 정의한다.
기호 설명
Figure pat00065
 계산된 부하 증분 한계, 할당, 부하 값들
Figure pat00066
 기초 자원 파라미터(base resource parameter), 업데이트된 기초 자원 파라미터
Figure pat00067
 Q-학습 전략
Figure pat00068
 노드에 작업을 할당하는 것에 기반하는 보상의 정의
Figure pat00069
 노드에 작업을 할당하는 것에 기반하는 보상의 정의
Figure pat00070
 기틴스 인덱스 측정 입력 상태, 부하 분산 행동 a, 디스카운트 파라미터, 및 현재와 다음 상태들을 지니는 로컬 최대 Q 값에 대한 Q 함수
Figure pat00071
 모델링 파라미터
몇몇 실시 예들에서, 변동성의 정도가 매우 높기 때문에, 피크(peak) 검출 이전의 부하들 j로 할당되기로 되어 있는 기초 자원 파라미터(base resource parameter) Bj가 결정될 수 있다. 예를 들어, 버스트가 시작한 시점으로부터 중단 시간에 이르기까지, 전체 N개의 할당들이, 할당을 위하여 만들어진 증분 업데이트를 의미하는 nj와 함께 제공될 수 있다. 이것은 식 21에 정의된 바와 같이, 추정된 증분 부하 관리 값(estimated incremental load managing value) I'에 의하여 주어진다.
Figure pat00072
예를 들어, 부하 분산 에이전트(812)가 초기(예를 들어, 처음으로)에 호출되는 경우, 초기에 예상된 Bj에 부하 관리 값 I'를 더한 값이 계산되어, 새롭게 업데이트된 값은 Bj=Bj+I'와 같이 정의된다. 이 계산은 모든 자원 이용 가능성을 분석하고 최고 이득을 갖는 구성을 선호하는 것에 의하여 수행된다. 이는 자원 할당의 신뢰 한계라고 불리는데, 모든 시간에 대하여 학습 과정은 높은 신뢰 한계를 갖는 행동들을 선호한다. 몇몇 실시 예에 따르면, 학습 과정은 Q-학습으로도 알려져 있는 강화 학습 전략을 포함할 수 있다. 즉, 몇몇 실시 예에서, 에이전트(예를 들어, 부하 분산 에이전트(812))가 환경(예를 들어, 클라우드 환경)으로부터 얻을 수 있는 평균 보상의 한계가 정해진다. 예를 들어, 몇몇 실시 예들에서, 부하 분산 에이전트(812)는 지수가중이동평균(exponentially weighted moving average; EWMA)을 이용하여 기대값을 추정할 수 있다. 예를 들어, 몇몇 실시 예들에서, 부하 분산 에이전트(812)는 식 22에 나타난 바와 같이 상태-행동 사이클을 걸쳐 반복할 수 있는데, S, S'는 각각 기틴스 인덱스 측정의 과거 및 현재 상태들을 나타내고, a는 서로 다른 부하 값들을 나타내며, r은 즉시 보상(immediate reward) 파라미터를 정의한다.
Figure pat00073
지수가중이동평균을 이용하면, 식 22는 식 23에 나타난 바와 같이 재작성될 수 있다.
Figure pat00074
도 13a는 본 발명의 실시 예에 따른, 머신 러닝 과정의 예시적인 방법을 나타내는 흐름도이고, 도 13b는 본 발명의 실시 예에 따른, 도 13a의 과정을 구현하기 위한 대응하는 의사코드를 나타낸다.
몇몇 실시 예들에서, 새로운 시간 스텝은 블록(1305)에서 머신 러닝 과정을 유발한다. 새로운 시간 스텝에 대하여, 기틴스 인덱스 값의 변화는 블록(1310)에서 결정된다. 블록(1310)에서 기틴스 인덱스 값의 변화가 없는 경우(예를 들어, 아니오), 과정은 블록(1305)에서 새로운 시간 스텝을 모니터링하기 위하여 계속된다. 한편, 블록(1310)에서 기틴스 인덱스 값의 변화가 있는 경우, 블록(1315)의 각 자원 nj에 대하여, 부하 관리 값 I'이 블록(1320)에서 결정되고, 기초 자원 파라미터 Bj가 블록(1325)에서 결정되고, 그리고 자원들 nj 각각에 대한 신뢰 한계들이 블록(1330)에서 계산된다. 부하 분산 에이전트(812)는 블록(1335)에서 행동을 취한다. 예를 들어, 몇몇 실시 예들에서, 부하 분산 에이전트(812)는 가장 높은 신뢰 한계를 지닌 행동을 선택한다. 마지막으로, 선택되는 취해진 행동으로부터 학습된 임의의 Q-학습 업데이트들은 블록(1340)에서 적용된다.
예를 들어, 몇몇 실시 예들에서, 부하 분산 에이전트(812)의 목적은 제공자의 이득을 최대화하는 것일 수 있다. 변화하는 클라우드 환경 조건들을 추정하기 어렵기 때문에, 학습 과정을 통하여 자원 할당을 유도하는 것이 중요할 수 있는데, 이는 단일 버스트 간격은 성공적인 올-인-원(all-in-one) 훈련의 한계를 정하지 않기 때문이다. 따라서, 몇몇 실시 예들에서, Q-학습 전략은 식 24에 나타난 바와 같이 사용된다.
Figure pat00075
ri c는 식 25에 의하여 정의된다.
Figure pat00076
이산 변수 pi e는 식 26에 의하여 정의된다.
Figure pat00077
상기 식 24 내지 식 26에서, 변수 e는 변화하는 버스트 값들(GI)과 정렬되는 임의의 사건으로서 정의된다.
자원 풀(예를 들어, 노드 풀 또는 가상 머신 풀) 상에 부하 분산 에이전트(812)의 행동을 직접적으로 실행하기 위하여, 제어는 구성 로직(810) 및 자원 풀 스케줄러(814)로 넘어간다. 몇몇 실시 예들에서, 구성 로직(810)은 자원들을 추가하고 제거하는 로직을 포함하는데, 자원들을 구성하는 것은 동적 가상 환경의 중요한 부분일 수 있기 때문이다. 따라서, 몇몇 실시 예들에서, 구성 로직(810)은 스파이크 값(또는 버스트 값) 계산에 기반하여 자원 요구량을 조절할 수 있다. 초기 검출이 도착한 이후, 전체 요구량은 어떤 자원(예를 들어, 가상 머신)이 자원 풀(예를 들어, 가상 머신 풀)로부터 선택되는지에 기반하여 계산될 수 있다. 몇몇 실시 예들에서, 구성 로직(810)은 자원들(예를 들어, 가상 머신들)을 초기 가상 네트워크와 재구성하여, 새로운 가상 계산 환경을 생산한다.
몇몇 실시 예들에서, 자원 풀 스케줄러(814)는 적절한 큐들로 작업들의 테이블을 할당할 수 있고, 디스패치를 수행할 수 있다. 디스패처로서, 자원 풀 스케줄러(814)는 새로운 가상 계산 환경 스케줄의 일부를 인덱스 정책 필터(806)로 전송하여 학습과 탐색의 피드백 루프를 완성한다. 몇몇 실시 예들에서, 새로운 스케줄이 준비되고 나면, 이전 것들과 유사한 기틴스 인덱스 값을 지닌 모든 새로운 도착들은 자기 만족(self-satisfied)한 상태를 유지할 수 있다.
몇몇 실시 예들에서, 부하 분산 에이전트(812)가 가능한 행동들을 탐색하는 동안, 이전의 비슷한 상황들에서 경험한 이득이 되지 않는 행동들을 피한다. 다시 말해서, 몇몇 실시 예들에서, 부하 분산 에이전트(812)는 한계 계산기(808)에 의하여 계산된 신뢰 한계들에 기반하여 낙관적이라고 여기는 행동들을 강조한다. 예를 들어, 몇몇 실시 예들에서, 한계 계산기(808)은 부하 분산 에이전트(812)가 요청들이 만족되었는지를 얼마나 잘 고려하는지를 나타내는 신뢰 한계를 평가한다. 몇몇 실시 예들에서, 한계 계산기(808)은 인덱스 정책 필터(806)의 출력을 부하 파라미터들을 계산하는 것을 위한, 예를 들어, 증분 부하 값 I'을 계산하기 위한 스파이크 요구의 기저(basis)로서 취한다.
예를 들어, 도 14는 본 발명의 실시 예에 따른, 한계 계산기(808)를 나타내는 흐름도이다. 도 14를 참조하면, 몇몇 실시 예들에서, Bj와 I' 파라미터들은 nj 파라미터를 계산하기 위하여 얻어질 수 있고, 부하 분산 에이전트(812)의 Q-학습 과정에 영향을 미친다. 예를 들어, 블록(1405)에서 새로운 시간 스텝에 대하여, 증분 부하 관리 값 I'를 계산하기 위하여 사용된 파라미터들(예를 들어, Bj 및 N)은 블록(1410)에서 얻어진다. 업데이트된 nj 파라미터는 블록(1415)에서 기틴스 인덱스 값에 따라 얻어진다. 증분 부하 관리 값 I'은 블록(1420)에서 업데이트되고, Bj 업데이트는 블록(1425)에서 통신된다. 그 다음, 신뢰 한계는 블록(1430)에서 업데이트된다.
도 15a는 본 발명의 실시 예에 따른, 인덱스 정책 필터(806), 한계 계산기(808), 구성 로직(810), 및 자원 풀 스케줄러(814) 사이의 파라미터 전송을 나타낸 것이다. 도 15b는 본 발명의 실시 예에 따른, 부하 분산 에이전트(812)의 결과적인 신뢰 한계 레벨을 나타낸다.
도 16은 본 발명의 실시 예에 따른, 모드 선택기의 블록도이다. 도 17은 본 발명의 실시 예에 따른, 제 1 모드와 제 2 모드 사이에서 자동으로 선택하는 방법을 나타내는 흐름도이다. 다양한 실시 예들에서, 상술한 바와 같이, 부하 분산 시스템은 제 1 모드(예를 들어, 휴리스틱 모드) 또는 제 2 모드(예를 들어, 학습 모드) 하에서 동작할 수 있도록 제공된다. 예를 들어, 몇몇 실시 예들에서, 부하 분산 시스템은 위에서 설명한 모드들 각각의 원하는 측면들과 특징들에 기반하여 제 1 모드 또는 제 2 모드 하에서 동작하도록 구성될 수 있다. 다른 실시 예들에서, 시스템은 제1 또는 제 2 모드들 중 임의의 모드를 자동적으로 선택할 수 있고, 시스템은 필요로 하는 또는 요구되는 제1 및 제 2 모드들 각각 하에서 선택적으로 동작한다. 예를 들어, 몇몇 실시 예들에서, 부하 분산 시스템은 필요로 하는 또는 요구되는 제 1 모드(1605) 또는 제 2 모드(1610) 중 임의의 모드를 자동적으로 선택하기 위하여 모드 선택기(1600)를 포함할 수 있다.
몇몇 실시 예들에서, 모드 선택기(1600)은 제 1 및 제 2 모드들 사이에서 선택할 수 있도록 카운터(1602)를 포함할 수 있다. 몇몇 실시 예들에서, 카운터(1602)는 오버플로우(overflow) 또는 언더플로우(underflow)가 허용되지 않는 2-비트 카운터일 수 있으나, 본 발명은 이에 한정되지 않는다. 몇몇 실시 예들에서, 모드 선택기(1600)은 카운터(1602)를 사용하여 시스템이 모드들 사이에서 너무 자주 전환하지 않도록 다소의 저항을 제공한다. 예를 들어, 지속적인 문맥 교환(context switching)은 부하 분산 에이전트(812)의 학습 개발에 부정적인 영향을 미칠 수 있다. 따라서, 몇몇 실시 예들에서, 모드 선택기(1600)는, 일정 시간 동안 높은 성능을 입증함으로써 부하 분산 에이전트(812)가 충분히 훈련된 후 모드 전환이 수행될 수 있도록, 카운터(1602)를 이용할 수 있다.
간략한 개요 상에서, 몇몇 실시 예들에서, 모드 선택기(1600)는 카운터(1602)를 이용하여 제 1 모드(예를 들어, 휴리스틱 모드)(1605) 또는 제 2 모드(예를 들어, 학습 모드)(1610)에서 동작할지를 결정한다. 예를 들어, 몇몇 실시 예들에서, 높은 카운터 값(예를 들어, 중간 카운터 값보다 높은)은 제 2 모드(예를 들어, 학습 모드)(1610)에서 더 높은 신뢰 레벨을 나타낼 수 있고(예를 들어, 부하 분산 에이전트(812)가 충분히 훈련되었음을 나타나며), 낮은 카운터 값(예를 들어, 중간 카운터 값보다 낮은)은 제 1 모드(예를 들어, 휴리스틱 모드)(1605)에서 더 높은 신뢰 레벨을 나타낼 수 있다. 몇몇 실시 예들에서, 그러나, 모드 선택은 트래픽이 유니폼(균일한) 분포와 유사할 때, 즉, 기틴스 인덱스 값이 대응하는 임계 범위(예를 들어, 0.5와 같은 미리 설정된 중간 범위) 내에 존재할 때 고려될 수 있다. 몇몇 실시 예들에서, 두 모드들이 버스트 시나리오에 동의하는 경우, 모드 선택기(1600)는 제 1 모드(1605)를 선택하는데, 이는 제 2 모드(1610)에 비하여 더 가벼울 수 있다. 한편, 몇몇 실시 예들에서, 모드들이 버스트 시나리오에 동의하지 않는 경우, 카운터 값은 모드들 사이에서 선택하는 데 이용될 수 있다.
더 상세하게는, 도 17을 참조하면, 모드 선택기(1600)는 블록(1702)에서 카운터(1602)를 초기화시킨다. 예를 들어, 모드 선택기(1600)는 블록(1702)에서 카운터(1602)를 초기 카운터 값(예를 들어, 0)으로 설정할 수 있다. 기틴스 인덱스 값은 블록(1704)에서 회수될 수 있다. 몇몇 실시 예들에서, 모드 선택기(1600)는 블록(1706)에서, 기틴스 인덱스 값이 임계 범위 내에 있는지 결정하기 위하여 기틴스 인덱스 값을 임계 범위(예를 들어, 0.5와 같은 미리 설정된 중간 범위)와 비교할 수 있다. 블록(1706)에서 기틴스 인덱스 값이 임계 범위 내에 있지 않은 경우(예를 들어, 아니오), 모드 선택기(1600)는 블록(1708)에서 제 2 모드(예를 들어, 학습 모드)를 선택할 수 있다. 한편, 블록(1706)에서 기틴스 인덱스 값이 임계 범위 내에 있는 경우(예를 들어, 예), 모드 선택기(1600)는 블록(1710)에서 제곱 변동계수(SCV) 값을 회수할 수 있다.
블록(1712)에서, 모드 선택기(1600)는 제 1 및 제 2 모드가 버스트 시나리오에 동의하는지 결정할 수 있다. 제 1 및 제 2 모드들 모두가 블록(1712)에서 버스트 시나리오에 동의하는 경우(예를 들어, 예), 모드 선택기(1600)는 블록(1714)에서 제 1 모드(예를 들어, 휴리스틱 모드)를 선택할 수 있다. 한편, 제 1 및 제 2 모드들이 블록(1712)에서 버스트 시나리오에 동의하지 않는 경우(예를 들어, 아니오), 카운터(1602)의 카운터 값은 카운터 임계 수치(예를 들어, 이 예에서는 중간 지점 카운터 값 2)와 비교되어 카운터 값이 카운터 임계 수치보다 작은지를 결정한다. 블록(1716)에서 카운터 값이 카운터 임계 수치보다 작은 경우(예를 들어, 예), 블록(1718)에서 제 1 모드가 선택된다. 모드 선택기(1600)는 그 후 제 1 모드 하에서, 블록(1720)에서 실패율이 개선되는지(또는 유지되는지) 결정한다. 블록(1720)에서 실패율이 개선되지(또는 유지되지) 않으면(예를 들어, 아니오), 카운터(1602)는 블록(1722)에서 증가된다(예를 들어, 2-비트 카운터인 이 예에서 이미 최대값인 3에 도달하지 않은 경우). 블록(1720)에서 실패율이 개선되는 경우, 카운터(1602)는 블록(1728)에서 감소된다(예를 들어, 이 예에서 이미 최소값인 0에 도달하지 않은 경우).
한편, 블록(1716)에서 카운터 값이 카운터 임계 수치보다 큰 경우(예를 들어, 아니오), 모드 선택기(1600)는 블록(1724)에서 제 2 모드를 선택할 수 있다. 모드 선택기(1600)는 그 후 제 2 모드 하에서, 블록(1726)에서 실패율이 개선되는지(또는 유지되는지) 결정한다. 블록(1726)에서 실패율이 개선되지(또는 유지되지)않으면(예를 들어, 아니오), 카운터(1602)는 블록(1728)에서 감소된다(이 예에서 이미 최소값인 0에 도달하지 않은 경우). 한편, 블록(1726)에서 실패율이 개선되는 경우, 카운터(1602)는 블록(1722)에서 증가된다(예를 들어, 2-비트 카운터인 이 예에서 이미 최대값인 3에 도달하지 않은 경우).
본 명세서에 개시된 동작들의 일부 또는 전부는 하나 또는 그 이상의 프로세싱 회로에 의하여 수행될 수 있다. “프로세싱 회로”라는 용어는 본 명세서에서 데이터 또는 디지털 신호들을 처리하는 데 사용되는 하드웨어, 펌웨어, 및 소프트웨어의 임의의 결합을 의미하는 것으로 사용된다. 프로세싱 회로 하드웨어는, 예를 들어, ASIC(application specific integrated circuit), 범용 또는 특수 목적의 중앙 처리 장치(CPU), 디지털 신호 프로세서(DSP), 그래픽 처리 장치(GPU), 및 FPGA(field programmable gate array)와 같은 프로그래밍 가능한 로직 장치들을 포함할 수 있다. 프로세싱 회로에서, 본 명세서에서 사용되는 바와 같이, 각 기능은 해당 기능을 수행하기 위하여 구성된, 즉, 하드-와이어(hard-wired)된, 하드웨어 또는 비-일시적 저장 매체에 저장되는 명령어들을 실행하도록 구성되는, CPU와 같은, 더 범용의 하드웨어에 의하여 수행된다. 프로세싱 회로는 단일 PCB(printed circuit board) 상에 제조되거나, 여러 개의 서로 연결된 PCB들 상에 분산될 수 있다. 프로세싱 회로는 다른 프로세싱 회로를 포함할 수 있다; 예를 들어, 프로세싱 회로는, PCB에 서로 연결된 FPGA와 CPU와 같이, 두 개의 프로세싱 회로들을 포함할 수 있다.
비록 여기에서 제 1, 제 2, 제 3 등의 용어들은 다양한 요소들, 성분들, 영역들, 층들, 및/또는 섹션들을 설명하기 위해 사용되지만, 이러한 요소들, 성분들, 영역들, 층들, 및/또는 섹션들은 이러한 용어들로 인해 제한되지 않는 것으로 이해될 것이다. 이러한 용어들은 다른 요소, 성분, 영역, 층, 또는 섹션으로부터 하나의 요소, 구성, 영역, 층 또는 섹션을 구별하기 위해 사용된다. 따라서, 후술하는 제 1 구성 요소, 성분, 영역, 층, 또는 섹션은 본 발명의 사상 및 범위를 벗어나지 않고, 제 2 구성 요소, 성분, 영역, 층, 또는 섹션을 지칭 할 수 있다.
하나의 요소 또는 도면에서 도시된 다른 구성 요소(들) 또는 특징(들)과의 특징적인 관계를 설명하기 위한 설명을 용이하게 하기 위해 “아래의”, “아래”, “낮은”, “특정 부분 아래”, “위에”, “상부”와 같은 공간적이고 상대적인 용어들이 여기에서 사용될 수 있다. 공간적이고 상대적인 용어들은 도면에서 묘사된 방향에 더해 사용 또는 동작에서 장치의 다른 방향들을 포함하도록 의도된 것이 이해될 것이다. 예를 들면, 만약 도면의 장치가 뒤집어지면, 다른 구성 요소들 또는 특징들의 “아래” 또는 “아래의” 또는 “특정 부분 아래”로 설명된 구성요소들은 다른 구성 요소들 또는 특징들의 “위로” 맞춰지게 된다. 따라서, “아래의” 또는 “특정 부분 아래”의 예시적인 용어들은 위 또는 아래 방향 모두를 포함할 수 있다. 장치는 다르게 맞춰질 수 있으며(예를 들면, 90도 도는 다른 방향으로 회전됨) 그리고 공간적으로 상대적인 기술어들은 그에 따라 해석되어야 한다. 또한, 요소 또는 층이 두 개의 요소들 또는 층들 사이로 언급되는 때, 그것은 단지 요소 또는 층이 두 요소들 또는 층들 사이에 있을 수 있거나, 또는 하나 또는 그 이상의 사이의 요소들 또는 층들이 또한 존재할 수 있다.
본 명세서에서 사용된 용어들은 단지 특정한 실시 예들을 설명하기 위한 것이고, 본 발명을 제한하려는 것으로 의도되지 않았다. 본 명세서에서 사용된 바와 같이, “대체로”, “약” 용어 그리고 이와 유사한 용어들은 근사치의 용어들로서 사용되고, 정도의 용어들로서 사용되지 않고. 통상의 기술자에 의해 식별되는 측정된 또는 계산된 값들의 고유한 변동을 고려하기 위한 것이다.
본 명세서에서 사용된 바와 같이, 문맥상 명백하게 다르게 뜻하지 않는 한, 단수 형태 “하나”는 복수의 형태도 포함하는 것으로 의도된다. “포함하는”, 그리고 “포함하고 있는” 용어들이 본 명세서에서 사용될 때, 이러한 용어들은 정해진 특징들, 정수들, 단계들, 동작들, 요소들, 및/또는 성분들의 존재를 명시하나, 하나 또는 그 이상의 다른 특징들, 정수들, 단계들, 동작들, 요소들, 성분들, 및/또는 그것들의 그룹들의 추가 또는 존재를 불가능하게 하지 않는다. 본 명세서에서 사용된 바와 같이, “및/또는” 용어는 하나 또는 그 이상의 열거된 항목들과 연관된 임의의 그리고 모든 조합들을 포함한다. “적어도 하나”와 같은 표현들은 요소들 전체 리스트를 수정하고 그리고 리스트의 개별 요소들을 수정하지 않는다. 또한, 본 발명의 실시 예들을 기술할 때 "할 수 있다"의 사용은 "본 발명의 하나 이상의 실시 예들"을 의미한다. 또한, "예시" 용어는 예 또는 그림을 의미한다. 본 명세서에서 사용된 바와 같이, “사용”, “사용되는”, 그리고 “사용된” 용어들은 “이용”, “이용되는”, 그리고 “이용된” 용어들의 동의어로 각각 간주될 수 있다.
요소, 층, 영역, 또는 성분이 다른 요소, 층, 영역 또는 성분 “에”, “에 연결된”, “에 결합된” 것으로 언급되는 때, 그것은 다른 요소, 층, 영역, 또는 성분 “에 직접적으로”, “에 직접적으로 연결된”, “에 직접적으로 결합된”일 수 있거나, 하나 또는 그 이상의 사이의 요소들, 층들, 영역들, 또는 성분들이 존재할 수 있다. 또한, 요소 또는 층이 두 개의 요소들 또는 층들 사이로 언급되는 때, 그것은 단지 요소 또는 층이 두 요소들 또는 층들 사이에 있을 수 있거나, 또는 하나 또는 그 이상의 사이의 요소들 또는 층들이 또한 존재할 수 있다.
본 명세서에 언급된 임의의 수치 범위는, 언급된 범위 내에 포함되며 동일한 수치 정밀도를 지니는 모든 하위 범위를 포함하는 것으로 의도된다. 예를 들어, “1.0 내지 10.0”이라는 범위는 언급된 최소값 1.0 및 언급된 최대값 10.0 사이(및 포함하는), 즉, 1.0 이상의 최소값 및 10.0 이하의 최대값을 갖는, 예를 들어, 2.4 내지 7.6과 같은 범위를 포함하는 것으로 의도된다. 본 명세서에 언급된 임의의 최대 수치 제한은 그 안에 포함된 모든 더 낮은 수치 제한을 포함하는 것으로 의도되며, 본 명세서에 언급된 임의의 최소 수치 제한은 그 안에 포함된 모든 더 높은 수치 제한을 포함하는 것으로 의도된다.
비록 스파이크 검출 및 지능적 부하 분산 시스템 및 방법의 예시적인 실시 예들이 본 명세서에 구체적으로 설명되고 도시되어 있으나, 통상의 기술자들에게는 많은 수정들 및 변화들이 명백할 것이다. 따라서, 본 명세서에 개시된 원리에 따른 스파이크 검출 및 지능적 부하 분산 시스템 및 방법은, 본 명세서에서 구체적으로 설명된 것과 다르게 구현될 수 있는 것으로 이해될 것이다. 본 발명은 또한 다음의 청구 범위 및 그 균등 범위에서 정의된다.

Claims (10)

  1. 중앙 집중 큐(queue);
    상기 중앙 집중 큐에 연결된 자원 노드들의 풀(pool);
    하나 또는 그 이상의 프로세서; 및
    상기 하나 또는 그 이상의 프로세서에 연결되고, 명령어들을 저장하는 메모리를 포함하되;
    상기 명령어들은, 상기 하나 또는 그 이상의 프로세서에 의해 실행되는 경우, 상기 하나 또는 그 이상의 프로세서로 하여금:
    상기 중앙 집중 큐의 큐 상태를 모니터링하여 버스티 트래픽(bursty traffic) 구간을 식별하도록 하고;
    상기 버스티 트래픽 구간과 관련된 부하에 대한 인덱스 값을 계산하도록 하고;
    상기 인덱스 값에 기반하여 부하 분산 전략을 선택하도록 하고;
    상기 부하 분산 전략에 기반하여 상기 자원 노드들의 상기 풀로 상기 부하를 분배하도록 하고;
    상기 부하 분산 전략에 응답하여 상기 자원 노드들의 상기 풀의 상태를 관찰하도록 하고;
    상기 관찰된 상태에 기반하여 보상을 계산하도록 하고; 그리고
    상기 보상에 기반하여 상기 부하 분산 전략을 조절하도록 하는 부하 분산 시스템
  2. 제 1 항에 있어서,
    상기 인덱스 값은 기틴스 인덱스(Gittins Index; GI) 값에 대응하는 부하 분산 시스템.
  3. 제 1 항에 있어서,
    상기 부하 분산 전략을 선택하기 위하여 상기 명령어들은, 상기 하나 또는 그 이상의 프로세서로 하여금:
    상기 자원 노드들의 상기 풀 내의 각 자원에 대하여 증분 부하 관리 값을 더 계산하도록 하고; 그리고
    상기 자원 노드들의 상기 풀 내의 각 자원에 대하여 기초 자원 파라미터를 더 계산하도록 하는 부하 분산 시스템.
  4. 제 1 항에 있어서,
    상기 보상을 계산하기 위하여 상기 명령어들은, 상기 하나 또는 그 이상의 프로세서로 하여금:
    상기 인덱스 값, 입력 상태, 상기 선택된 부하 분산 전략, 및 보상 함수에 기반하여 Q-함수를 더 계산하도록 하는 부하 분산 시스템.
  5. 제 4 항에 있어서,
    상기 Q-함수는:
    수식
    Figure pat00078
    에 따라 계산되고,
    상기 수식에서:
    s 및 s'는 기틴스 인덱스 값들의 과거 상태 및 현재 상태에 각각 대응하고;
    a는 서로 다른 부하 값들에 대응하고; 그리고
    r은 즉시 보상 파라미터에 대응하는 부하 분산 시스템.
  6. 하나 또는 그 이상의 프로세서에 의해, 버스티 트래픽 구간을 식별하기 위하여 중앙 집중 큐의 큐 상태를 모니터링하는 단계;
    상기 하나 또는 그 이상의 프로세서에 의해, 상기 버스티 트래픽 구간에 관련된 부하에 대한 인덱스 값을 계산하는 단계;
    상기 하나 또는 그 이상의 프로세서에 의해, 상기 인덱스 값에 기반하여 부하 분산 전략을 선택하는 단계;
    상기 하나 또는 그 이상의 프로세서에 의해, 상기 부하 분산 전략에 기반하여 자원 노드들의 풀로 상기 부하를 분배하는 단계;
    상기 하나 또는 그 이상의 프로세서에 의해, 상기 부하 분산 전략에 응답하여 상기 지원 노드들의 상기 풀의 상태를 관찰하는 단계;
    상기 하나 또는 그 이상의 프로세서에 의해, 상기 관찰된 상태에 기반하여 보상을 계산하는 단계; 및
    상기 하나 또는 그 이상의 프로세서에 의해, 상기 보상에 기반하여 상기 부하 분산 전략을 조절하는 단계를 포함하는 부하 분산 방법.
  7. 제 6 항에 있어서,
    상기 인덱스 값은 기틴스 인덱스 값에 대응하는 부하 분산 방법.
  8. 제 6 항에 있어서,
    상기 부하 분산 전략을 선택하는 단계는:
    상기 하나 또는 그 이상의 프로세서에 의해, 상기 자원 노드들의 상기 풀 내의 각 자원에 대하여 증분 부하 관리 값을 계산하는 단계; 그리고
    상기 하나 또는 그 이상의 프로세서에 의해, 상기 자원 노드들의 상기 풀 내의 각 자원에 대하여 기초 자원 파라미터를 계산하는 단계를 포함하는 부하 분산 방법.
  9. 제 6 항에 있어서,
    상기 보상을 계산하는 단계는:
    상기 하나 또는 그 이상의 프로세서에 의해, 상기 인덱스 값, 입력 상태, 상기 선택된 부하 분산 전략, 및 보상 함수에 기반하여 Q-함수를 계산하는 단계를 포함하는 부하 분산 방법.
  10. 제 9 항에 있어서,
    상기 Q-함수는:
    수식
    Figure pat00079
    에 따라 계산되고,
    상기 수식에서:
    s 및 s'는 기틴스 인덱스 값들의 과거 상태 및 현재 상태에 각각 대응하고;
    a는 서로 다른 부하 값들에 대응하고; 그리고
    r은 즉시 보상 파라미터에 대응하는 부하 분산 방법.
KR1020200095498A 2019-08-23 2020-07-30 스파이크 검출 및 부하 분산 자원 관리 시스템 및 그 방법 KR20210023693A (ko)

Applications Claiming Priority (6)

Application Number Priority Date Filing Date Title
US201962890864P 2019-08-23 2019-08-23
US62/890,864 2019-08-23
US201962913536P 2019-10-10 2019-10-10
US62/913,536 2019-10-10
US16/706,161 US11240294B2 (en) 2019-08-23 2019-12-06 Systems and methods for spike detection and load balancing resource management
US16/706,161 2019-12-06

Publications (1)

Publication Number Publication Date
KR20210023693A true KR20210023693A (ko) 2021-03-04

Family

ID=74645525

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020200095498A KR20210023693A (ko) 2019-08-23 2020-07-30 스파이크 검출 및 부하 분산 자원 관리 시스템 및 그 방법

Country Status (2)

Country Link
US (1) US11240294B2 (ko)
KR (1) KR20210023693A (ko)

Families Citing this family (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107770242B (zh) * 2017-08-25 2018-07-17 贵州白山云科技有限公司 一种实现智能流量调度的方法及装置
EP4239484A3 (en) 2018-10-26 2024-01-03 VMware, Inc. Collecting samples hierarchically in a datacenter
US11290358B2 (en) 2019-05-30 2022-03-29 Vmware, Inc. Partitioning health monitoring in a global server load balancing system
US11182269B2 (en) * 2019-10-01 2021-11-23 International Business Machines Corporation Proactive change verification
CN113162790B (zh) * 2020-01-22 2023-10-03 华为技术有限公司 调整服务等级的方法、装置、设备及存储介质
US11811861B2 (en) * 2021-05-17 2023-11-07 Vmware, Inc. Dynamically updating load balancing criteria
CN113392511B (zh) * 2021-05-28 2022-11-22 广西电网有限责任公司电力科学研究院 基于频谱包络符号熵的有载分接开关机械状态监测方法
US11799824B2 (en) 2021-06-14 2023-10-24 Vmware, Inc. Method and apparatus for enhanced client persistence in multi-site GSLB deployments
CN113791909B (zh) * 2021-09-18 2023-10-03 深圳市华智世纪科技有限公司 服务器容量调整方法、装置、计算机设备及存储介质
US11900182B2 (en) * 2021-10-06 2024-02-13 Imperva, Inc. Waiting room with zero latency
US11973694B1 (en) * 2023-03-30 2024-04-30 Mellanox Technologies, Ltd. Ad-hoc allocation of in-network compute-resources
CN116471273B (zh) * 2023-04-18 2023-10-20 广州智臣信息科技有限公司 一种跨网数据交换系统的负载均衡实现方法

Family Cites Families (64)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5592672A (en) * 1993-11-02 1997-01-07 Bell Communications Research, Inc. System for load balancing between message processors by routing all queued messages to a particular processor selected by a deterministic rule
JP2959539B2 (ja) 1997-10-01 1999-10-06 日本電気株式会社 バッファ制御方法および装置
JP2001109638A (ja) * 1999-10-06 2001-04-20 Nec Corp 推定伸長率に基づくトランザクション負荷分散方法及び方式並びにコンピュータ可読記録媒体
GB2359444B (en) 2000-02-15 2003-07-09 3Com Corp Network switch including restriction of source address look-ups based on receive queue length
US20020124104A1 (en) * 2001-03-01 2002-09-05 Yigal Rappaport Network element and a method for preventing a disorder of a sequence of data packets traversing the network
US20030067874A1 (en) 2001-10-10 2003-04-10 See Michael B. Central policy based traffic management
US7782776B2 (en) 2002-03-15 2010-08-24 Broadcom Corporation Shared weighted fair queuing (WFQ) shaper
US7289498B2 (en) * 2002-06-04 2007-10-30 Lucent Technologies Inc. Classifying and distributing traffic at a network node
US7430211B2 (en) 2002-10-18 2008-09-30 Broadcom Corporation System and method for receive queue provisioning
US8145731B2 (en) * 2003-12-17 2012-03-27 Hewlett-Packard Development Company, L.P. System and method for determining how many servers of at least one server configuration to be included at a service provider's site for supporting an expected workload
US7836181B2 (en) * 2004-09-21 2010-11-16 Alcatel-Lucent Usa Inc. Fairness and load balancing in wireless LANs using association control
DE102004061339A1 (de) * 2004-12-20 2006-06-29 Infineon Technologies Ag Scheduling-Verfahren, insbesondere Kontex-Scheduling-Verfahren, und Einrichtung zur Verwendung bei einem Scheduling-Verfahren
US7448044B1 (en) 2005-02-02 2008-11-04 Sun Microsystems, Inc. Systems and methods for efficient queue pair number re-use
US7941805B2 (en) * 2006-08-15 2011-05-10 International Business Machines Corporation Affinity dispatching load balancer with precise CPU consumption data
CN101971590A (zh) 2006-12-20 2011-02-09 汤姆森许可贸易公司 通过管理tcp ack来提高lan中的吞吐量
US8160085B2 (en) 2007-12-21 2012-04-17 Juniper Networks, Inc. System and method for dynamically allocating buffers based on priority levels
US9237034B2 (en) 2008-10-21 2016-01-12 Iii Holdings 1, Llc Methods and systems for providing network access redundancy
US20100157964A1 (en) 2008-12-18 2010-06-24 Pantech & Curitel Communications, Inc. Server to guide reconnection in mobile internet, method for guiding server reconnection, and server reconnection method
US8346999B2 (en) 2009-12-15 2013-01-01 Intel Corporation Dynamic receive queue balancing with high and low thresholds
US8446824B2 (en) 2009-12-17 2013-05-21 Intel Corporation NUMA-aware scaling for network devices
EP2531987A4 (en) 2010-02-01 2015-05-13 Miovision Technologies Inc SYSTEM AND METHOD FOR MODELING AND OPTIMIZING THE PERFORMANCE OF TRANSPORT NETWORKS
US8413143B2 (en) 2010-04-12 2013-04-02 International Business Machines Corporation Dynamic network adapter queue pair allocation
US8589941B2 (en) 2010-04-23 2013-11-19 International Business Machines Corporation Resource affinity via dynamic reconfiguration for multi-queue network adapters
US8996756B2 (en) 2010-09-17 2015-03-31 Oracle International Corporation Using process location to bind IO resources on NUMA architectures
US8522250B2 (en) 2010-09-29 2013-08-27 International Business Machines Corporation Managing access to a shared resource in a data processing system
US9021138B2 (en) 2011-08-26 2015-04-28 Microsoft Technology Licensing, Llc Performance of multi-processor computer systems
US9152448B2 (en) 2012-05-11 2015-10-06 Vmware, Inc. Performance of load balancing modules with migration awareness
JP2015530766A (ja) 2012-09-28 2015-10-15 日本電気株式会社 通信システム、制御装置、端末、端末制御方法及びプログラム
US20140274011A1 (en) 2013-03-14 2014-09-18 Qualcomm Incorporated Method and apparatus for controlling operation of a user equipment based on physical layer parameters
US10069903B2 (en) 2013-04-16 2018-09-04 Amazon Technologies, Inc. Distributed load balancer
US20140325524A1 (en) 2013-04-25 2014-10-30 Hewlett-Packard Development Company, L.P. Multilevel load balancing
US9298648B2 (en) 2013-05-08 2016-03-29 Avago Technologies General Ip (Singapore) Pte Ltd Method and system for I/O flow management using RAID controller with DMA capabilitiy to directly send data to PCI-E devices connected to PCI-E switch
US9785356B2 (en) 2013-06-26 2017-10-10 Cnex Labs, Inc. NVM express controller for remote access of memory and I/O over ethernet-type networks
US9843540B2 (en) 2013-08-26 2017-12-12 Vmware, Inc. Traffic and load aware dynamic queue management
US20150120224A1 (en) 2013-10-29 2015-04-30 C3 Energy, Inc. Systems and methods for processing data relating to energy usage
EP2869514A1 (en) 2013-10-30 2015-05-06 Alcatel Lucent Method and system for queue management in a packet-switched network
JP6299169B2 (ja) 2013-11-14 2018-03-28 富士通株式会社 ストレージ装置、ストレージ装置の制御方法、及びストレージ装置の制御プログラム
WO2016026131A1 (zh) 2014-08-22 2016-02-25 上海交通大学 一种基于 numa 高性能网络缓存资源亲和度的虚拟处理器的调度方法
US9703742B2 (en) 2014-09-26 2017-07-11 Intel Corporation Unified device interface for a multi-bus system
US9495192B2 (en) 2014-09-30 2016-11-15 Vmware, Inc. NUMA I/O aware network queue assignments
US9876698B2 (en) 2015-04-09 2018-01-23 International Business Machines Corporation Interconnect congestion control in a storage grid
CA3128629A1 (en) 2015-06-05 2016-07-28 C3.Ai, Inc. Systems and methods for data processing and enterprise ai applications
KR102403489B1 (ko) 2015-07-10 2022-05-27 삼성전자주식회사 비휘발성 메모리 익스프레스 컨트롤러에 의한 입출력 큐 관리 방법
US9946484B2 (en) 2015-07-31 2018-04-17 Netapp, Inc. Dynamic routing of input/output requests in array systems
US10241674B2 (en) 2015-12-11 2019-03-26 Vmware, Inc. Workload aware NUMA scheduling
US10795608B2 (en) 2016-02-19 2020-10-06 Hitachi, Ltd. Computer, communication driver, and communication control method
US10142231B2 (en) 2016-03-31 2018-11-27 Intel Corporation Technologies for network I/O access
US10394679B2 (en) 2016-04-29 2019-08-27 Nicira, Inc. Locality-aware scheduling for NIC teaming
US11016940B2 (en) 2016-06-02 2021-05-25 International Business Machines Corporation Techniques for improving deduplication efficiency in a storage system with multiple storage nodes
US10089144B1 (en) * 2016-06-17 2018-10-02 Nutanix, Inc. Scheduling computing jobs over forecasted demands for computing resources
CN106254272B (zh) 2016-09-05 2019-08-02 盛科网络（苏州）有限公司 基于硬件实现的弹性的加权公平调度方法及调度系统
US10509569B2 (en) 2017-03-24 2019-12-17 Western Digital Technologies, Inc. System and method for adaptive command fetch aggregation
US10244048B2 (en) * 2017-04-28 2019-03-26 International Business Machines Corporation Sender system status-aware load balancing
US10310996B2 (en) 2017-05-31 2019-06-04 International Business Machines Corporation Hardware queue manager with water marking
US11102294B2 (en) 2017-06-09 2021-08-24 Samsung Electronics Co., Ltd. System and method for supporting energy and time efficient content distribution and delivery
US10698900B2 (en) 2017-09-25 2020-06-30 Splunk Inc. Generating a distributed execution model with untrusted commands
US20190196969A1 (en) 2017-12-22 2019-06-27 Samsung Electronics Co., Ltd. Method and apparatus for adaptive cache load balancing for ssd-based cloud computing storage system
US10637917B2 (en) * 2018-04-30 2020-04-28 EMC IP Holding Company LLC Host device load balancing using port load reported by storage system
US10599548B2 (en) 2018-06-28 2020-03-24 Intel Corporation Cache monitoring
US11681565B2 (en) 2018-09-13 2023-06-20 Intel Corporation Technologies for hierarchical clustering of hardware resources in network function virtualization deployments
US20190042331A1 (en) 2018-09-14 2019-02-07 Intel Corporation Power aware load balancing using a hardware queue manager
US10671302B1 (en) 2018-10-26 2020-06-02 Pure Storage, Inc. Applying a rate limit across a plurality of storage systems
US10855596B2 (en) * 2018-11-20 2020-12-01 Microsoft Technology Licensing, Llc Load balancing among multiple endpoint computing systems of a domain
US11467873B2 (en) 2019-07-29 2022-10-11 Intel Corporation Technologies for RDMA queue pair QOS management

Also Published As

Publication number Publication date
US20210058453A1 (en) 2021-02-25
US11240294B2 (en) 2022-02-01

Similar Documents

Publication Publication Date Title
KR20210023693A (ko) 스파이크 검출 및 부하 분산 자원 관리 시스템 및 그 방법
Yu et al. Stochastic load balancing for virtual resource management in datacenters
US11206193B2 (en) Method and system for provisioning resources in cloud computing
Khorsand et al. A self‐learning fuzzy approach for proactive resource provisioning in cloud environment
US8640132B2 (en) Jobstream planner considering network contention and resource availability
TWI382318B (zh) 協調的服務效能以及應用程式置放管理
US7127716B2 (en) Method of load balancing a distributed workflow management system
US7441028B1 (en) Method of defining a required information system capacity as a function of a user&#39;s quality of service objectives
US8024737B2 (en) Method and a system that enables the calculation of resource requirements for a composite application
US20060294238A1 (en) Policy-based hierarchical management of shared resources in a grid environment
CN102724103B (zh) 代理服务器、分层次网络系统及分布式工作负载管理方法
JP2008519322A (ja) 電気通信サービスおよび／またはネットワーク管理用のプラットフォームにおけるリソースの管理方法、対応プラットフォーム、およびそのコンピュータ・プログラム生成物
He et al. Allocating non-real-time and soft real-time jobs in multiclusters
US20140196054A1 (en) Ensuring performance of a computing system
US8732307B1 (en) Predictive control for resource entitlement
Vu et al. Predictive hybrid autoscaling for containerized applications
Hu et al. Job scheduling without prior information in big data processing systems
Farahabady et al. A qos-aware controller for apache storm
Lu et al. InSTechAH: Cost-effectively autoscaling smart computing hadoop cluster in private cloud
JP5670290B2 (ja) 通信サービスのためのプロセスの実行のためのリソースを管理する方法、システム及びコンピュータ・プログラム
Yousaf et al. RAVA—Resource aware VNF agnostic NFV orchestration method for virtualized networks
Stein Adaptive event dispatching in serverless computing infrastructures
Tairin et al. Embracing Uncertainty for Equity in Resource Allocation in ML Training
Shi et al. Developing an optimized application hosting framework in clouds
US20070016824A1 (en) Methods and apparatus for global systems management