KR20040075048A

KR20040075048A - 웹 팜 트래픽 제어 방법 및 장치

Info

Publication number: KR20040075048A
Application number: KR10-2004-7010400A
Authority: KR
Inventors: 울프조엘; 유필립
Original assignee: 인터내셔널 비지네스 머신즈 코포레이션
Priority date: 2002-01-24
Filing date: 2003-01-17
Publication date: 2004-08-26
Also published as: DE60301202D1; EP1472846A1; CN100556024C; US20030140143A1; US7356592B2; CA2471594C; ATE301364T1; EP1472846B1; CA2471594A1; DE60301202T2; TWI238621B; JP2005516293A; JP3989443B2; TW200302644A; WO2003063447A1; CN1706165A; KR100754296B1

Abstract

복수의 웹 사이트 및 서버를 갖는 웹 팜을 제어하는 방법이 개시되어 있으며, 이 방법은 상기 웹 사이트들로부터 수신된 고객 요청들을 복수의 부류로 분류하는 단계로서 상기 부류는 공유가능 고객 요청과 비공유가능 고객 요청을 포함하는 것인 분류 단계, 상기 서버들 중 어느 것이라도 서로 다른 상기 웹 사이트들로부터 수신된 공유가능 고객 요청들을 처리할 수 있도록 상기 공유가능 고객 요청들을 라우팅하는 단계, 및 특정의 상기 웹 사이트들로부터의 상기 비공유가능 고객 요청들을 상기 특정의 웹 사이트들이 할당되어 있는 특정의 서버들로만 라우팅하는 단계를 포함한다.

Description

웹 팜 트래픽 제어 방법 및 장치{METHOD AND APPARATUS FOR WEB FARM TRAFFIC CONTROL}

웹 팜 또는 콤플렉스(complex)는 이제 아주 대중화되어가고 있다. 웹 팜을 뒷받침하는 주된 발상은 다수의 서로 다른 웹 사이트들이 풀링된 자원(pooled resource)을 공유한다는 개념이다. 구체적으로 설명하면, 웹 팜은 일반적으로 부하 제어를 수행하고 고객 요청들을 분산시키기 위해 공통의 프런트-엔드 디스패처(front-end dispatcher)를 공유한다. 웹 팜은 또한 다수의 웹 서버들을 공유하고, 또 웹 팜은 요청 결과들을 고객들에게 반환하기 위해 백-엔드 대역폭(back-end bandwidth)을 공유한다. 하드웨어 및 소프트웨어는 일반적으로 단일 서비스 제공자 또는 콘텐츠 호스트(content host)에 의해 소유, 운영 및 유지된다. 이러한 서비스를 현재 제공하고 있거나 제공할 계획을 하고 있는 회사들의 예로는 AT&T, Exodus, Intel, IBM, Qwest, Verio, 및 Worldcom이 있다.

웹 팜의 주된 성능 문제는 그 시스템 상에서 달성되는 평균 응답 시간을 최소화하기 위해 부하를 서버들 상에 효과적으로 분산시키는 것이다. 서버들의 무리한 이용(overutilization)은 고객 요청의 과도한 지연을 야기시킬 수 있다. 반면에, 서버들의 저조한 이용(underutilization)은 낭비적이다. 평균 응답 시간을 최소화시키는 것은 웹 팜이 달성할 수 있는 처리 용량(throughput)을 극대화하는 이중 효과를 가지게 된다. 이것은 프런트-엔드 디스패처에서의 부하 제어 절차가 더욱 허용적(permissive)으로 되어 요청들의 거절이 더 적어질 수 있음을 의미한다.

웹 팜의 주된 동기 중 하나는 풀링된 자원으로 인해 생기는 효율성이다. 각각의 웹 사이트가 하나 이상의 서버들로 된 세트에 할당된다. 그렇지만, 종래 기술에서는 웹 사이트 할당이 서버들 간에 분할되어 있는 것으로 가정하고 있다. 즉, 어떤 서버도 2개 이상의 웹 사이트로부터의 트래픽을 처리하지 않는다.

다수의 서버를 포함하는 세트를 구축하는 것을 뒷받침하는 이론적 근거는 실현 가능성(feasibility)이다. 여러가지 사이트들 사이의 고객 요청의 분포는 일반적으로 아주 불균일하게 된다. 어떤 사이트들은 다른 사이트들보다 엄청나게 더 인기가 있을 수 있으며, 인기있는 웹 사이트(hot website)의 인기는 일반적으로 그 사이트를 단일 서버에 할당하게 되면 그 서버가 과부하에 걸릴 정도로 대단하다. 따라서, 타당한 성능을 달성하기 위해서는, 어떤 웹 사이트들을 다수의 서버들에 할당하는 것이 필요하게 된다.

분할된 경우에 대한 부하 분산 알고리즘을 구현하는 것이 공지되어 있지만, 이러한 서버의 분할은 유연성의 저하, 따라서 분산의 최적성이 저하된 웹 사이트 부하 분산(less optimally balanced website load balancing)을 가져오게 된다.

본 발명은 웹 팜(web farm)에서의 부하 분산(balancing of load)에 관한 것이다.

도 1은 네트워크 디스패처 및 다수의 서버를 포함하는 웹 팜을 나타낸 도면.

도 2는 고울 프로시저(Goal procedure)의 일부인 더미 노드(dummy node)로부터 위닝 노드(winning node)로의 경로를 나타낸 도면.

도 3은 고울 프로시저의 플로우차트를 나타낸 도면.

도 3b는 고울 프로시저의 초기화 단계의 플로우차트를 나타낸 도면.

도 3c는 고울 프로시저의 경로 북키핑(path bookkeeping) 단계의 플로우차트를 나타낸 도면.

도 3d는 고울 프로시저의 그래프 북키핑(graph bookkeeping) 단계의 플로우차트를 나타낸 도면.

도 4는 다이나믹 프로시저의 플로우차트를 나타낸 도면.

도 5는 다이나믹 프로시저를 설명하는 일례에서의 웹 사이트 심볼들의 용어 모음을 나타낸 도면.

도 6은 동일한 일례에서 다이나믹 프로시저의 방향 그래프(directed graph)를 나타낸 도면.

도 7은 동일한 일례에서 스태틱 프로시저의 무방향 그래프(undirected graph)를 나타낸 도면.

도 8은 스태틱 프로시저에서 이웃 도피 발견적 학습법(neighborhood escape heuristic)을 나타낸 도면.

도 9는 스태틱 프로시저의 플로우차트를 나타낸 도면.

복수의 웹 사이트 및 서버를 갖는 웹 팜을 제어하는 방법이 개시되어 있으며, 이 방법은, 상기 웹 사이트들로부터 수신된 고객 요청들을 복수의 부류(category)로 분류(categorize)하는 단계로서 상기 부류는 공유가능 고객 요청(sharable customer request)과 비공유가능 고객 요청(unsharable customer request)을 포함하는 것인 분류 단계, 상기 서버들 중 어느 것이라도 서로 다른 상기 웹 사이트들로부터 수신된 공유가능 고객 요청들을 처리할 수 있도록 상기 공유가능 고객 요청들을 라우팅하는 단계, 및 특정의 상기 웹 사이트들로부터의 상기 비공유가능 고객 요청들을 상기 특정의 웹 사이트들이 할당되어 있는 특정의 서버들로만 라우팅하는 단계를 포함한다.

본 방법의 또하나의 측면은 고울 프로시저(Goal procedure)를 더 포함하며, 상기 고울 프로시저는, 상기 웹 사이트들의 상기 서버들로의 상기 할당과 현재의 고객 요청 부하가 주어진 경우, 상기 고객 요청 각각에 대해 임의의 주어진 순간에 평균 고객 응답 시간을 최소화하기 위해 상기 각각의 고객 요청이 할당될 상기 서버들 중에서 최적의 서버를 결정하는 단계를 포함한다.

본 방법의 또다른 측면에서, 상기 고울 프로시저는, 이하의 제약 조건,,,인 경우,, 및인 경우에 따라 함수를 최소화시킴으로써 실시되며, 여기서, M은 웹 사이트의 개수이고, N은 서버의 개수이며, R_j는 서버 j에서의 고객 도달율(customer arrival rate)의 함수인 예상 응답 시간(expected response time)이고, x_i,j는 서버 j에 의해 처리될 수 있는 웹 사이트 i에 대한 공유가능 요청들의 가상적 개수(hypothetical number)를 나타내는 결정 변수(decision variable)이며, y_i,j는 서버 j에 의해 처리될 수 있는 웹 사이트 i에 대한 비공유가능 요청들의 가상적 개수를 나타내는 결정 변수이고, L_j는 서버 j에 대한 최대 허용가능 부하(maximum acceptable load)이며, c_i는 웹 사이트 i로부터의 공유가능 고객 요청들의 현재의 개수이고, d_i는 웹 사이트 i로부터의 비공유가능 요청들의 현재의 개수이며, a_i,j는 웹 사이트 i로부터의 공유가능 요청들이 서버 j로 라우팅될 수 있는지를 나타내는 인덱스이고, b_i,j는 웹 사이트 i로부터의 비공유가능 요청들이 서버 j로 라우팅될 수 있는지를 나타내는 인덱스이다.

본 방법의 또다른 측면은 방향 그래프(directed graph)를 생성 및 유지하는 단계로서, 상기 방향 그래프는 더미 노드(dummy node)와 복수의 서버 노드를 포함하고, 각각의 상기 서버 노드는 상기 서버들 중 하나에 대응하는 것인 방향 그래프 생성 및 유지 단계, 식이 최소가 되는 상기 서버 노드들 중 하나를 위닝 노드(winning node)로서 지명하는 단계, 및 상기 더미 노드로부터 상기 위닝 노드로의 최단 방향 경로(shortest directedpath)를 선택하는 단계를 포함한다.

본 방법의 또다른 측면은 스태틱 프로시저(Static procedure)를 포함하고, 상기 스태틱 프로시저는 특정의 상기 웹 사이트들을 특정의 상기 서버들에 할당하는 단계를 포함한다.

본 방법의 또다른 측면에서, 상기 스태틱 프로시저는 각각의 상기 웹 사이트로부터의 공유가능 및 비공유가능 고객 요청들의 예측 수요(forecasted demand)에 기초하여 상기 웹 사이트들을 특정의 서버들에 할당한다.

본 방법의 또다른 측면은 다이나믹 프로시저(Dynamic procedure)를 포함하며, 상기 다이나믹 프로시저는, 그 다음 고객 요청을 검사하는 단계, 어느 서버가 상기 그 다음 고객 요청을 현재 처리하기 위한 최적 서버인지를 결정하기 위해 상기 고울 프로시저를 호출하는 단계, 및 상기 그 다음 고객 요청을 상기 최적 서버로 디스패치하는 단계를 포함한다.

본 방법의 또다른 측면은 상기 고객 요청들을 큐 안으로 수신하는 단계를 포함하며, 상기 다이나믹 프로시저는, 상기 큐 내의 상기 고객 요청들을 모니터링하는 단계, 상기 서버들에 의해 현재 처리되고 있는 고객 요청들을 모니터링하는 단계,을 설정함으로써 각각의 j번째 서버에 대해 함수를 정의하는 단계,을 설정함으로써 각각의 j번째 서버에 대해 개정된 허용가능 부하 한계(revised acceptable load limit)를 정의하는 단계, 및 상기함수 및 개정된 허용가능 부하 한계를 이용하여 이하의 제약 조건,,,인 경우,, 및인 경우의 제약 조건에 따라 함수를 최소화하기 위해 상기 고울 프로시저를 호출하는 단계를 포함하며, 여기서는 서버 j에 의해 처리될 수 있는 웹 사이트 i에 대한 큐 내의 공유가능 요청들의 가상적 개수를 나타내는 결정 변수이고,는 서버 j에 의해 처리될 수 있는 웹 사이트 i에 대한 비공유가능 요청들의 가상적 개수를 나타내는 결정 변수이며,는 웹 사이트 i로부터의 큐 내의 공유가능 고객 요청들의 현재의 개수이고,는 웹 사이트 i로부터의 큐 내의 비공유가능 요청들의 현재의 개수이며,는 서버들 중 하나에서 현재 처리되고 있는 웹 사이트 i로부터의 공유가능 고객 요청들의 현재의 개수이고,는 서버들 중 하나에서 현재 처리되고 있는 웹 사이트 i로부터의 비공유가능 요청들의 현재의 개수이다.

복수의 웹 사이트와 서버를 갖는 웹 팜을 제어하기 위한 방법 단계들을 수행하기 위해 기계에 의해 실행가능한 명령어들의 프로그램을 유형으로 구현하는 기계에 의해 판독가능한 프로그램 저장 장치가 개시되어 있으며, 상기 방법 단계들은상기 웹 사이트들로부터 수신된 고객 요청들을 복수의 부류로 분류하는 단계로서 상기 부류는 공유가능 고객 요청과 비공유가능 고객 요청을 포함하는 것인 분류 단계, 상기 서버들 중 어느 것이라도 서로 다른 상기 웹 사이트들로부터 수신된 공유가능 고객 요청들을 처리할 수 있도록 상기 공유가능 고객 요청들을 라우팅하는 단계, 및 특정의 상기 웹 사이트들로부터의 상기 비공유가능 고객 요청들을 상기 특정의 웹 사이트들이 할당되어 있는 특정의 서버들로만 라우팅하는 단계를 포함한다.

본 장치의 또하나의 측면은 고울 프로시저를 포함하며, 상기 고울 프로시저는, 상기 웹 사이트들의 상기 서버들로의 상기 할당과 현재의 고객 요청 부하가 주어진 경우, 상기 고객 요청 각각에 대해 임의의 주어진 순간에 평균 고객 응답 시간을 최소화하기 위해 상기 각각의 고객 요청이 할당될 상기 서버들 중에서 최적의 서버를 결정하는 단계를 포함한다.

본 장치의 또다른 측면에서, 상기 고울 프로시저는, 이하의 식,,인 경우,,인 경우의 제약 조건에 따라 함수를 최소화시킴으로써 실시되며, 여기서, M은 웹 사이트의개수이고, N은 서버의 개수이며, R_j는 서버 j에서의 고객 도달율의 함수인 예상 응답 시간이고, x_i,j는 서버 j에 의해 처리될 수 있는 웹 사이트 i에 대한 공유가능 요청들의 가상적 개수를 나타내는 결정 변수이며, y_i,j는 서버 j에 의해 처리될 수 있는 웹 사이트 i에 대한 비공유가능 요청들의 가상적 개수를 나타내는 결정 변수이고, L_j는 서버 j에 대한 최대 허용가능 부하이며, c_i는 웹 사이트 i로부터의 공유가능 고객 요청들의 현재의 개수이고, d_i는 웹 사이트 i로부터의 비공유가능 요청들의 현재의 개수이며, a_i,j는 웹 사이트 i로부터의 공유가능 요청들이 서버 j로 라우팅될 수 있는지를 나타내는 인덱스이고, b_i,j는 웹 사이트 i로부터의 비공유가능 요청들이 서버 j로 라우팅될 수 있는지를 나타내는 인덱스이다.

본 장치의 또다른 측면은, 방향 그래프를 생성 및 유지하는 단계로서 상기 방향 그래프는 더미 노드와 복수의 서버 노드를 포함하고 상기 각각의 서버 노드는 상기 서버들 중 하나에 대응하는 것인 방향 그래프 생성 및 유지 단계, 식이 최소가 되는 상기 서버 노드들 중 하나를 위닝 노드로서 지명하는 단계, 및 상기 더미 노드로부터 상기 위닝 노드로의 최단 방향 경로를 선택하는 단계를 포함한다.

본 장치의 또다른 측면은 스태틱 프로시저를 포함하고, 상기 스태틱 프로시저는 특정의 상기 웹 사이트들을 특정의 상기 서버들에 할당하는 단계를 포함한다.

본 장치의 또다른 측면에서, 상기 스태틱 프로시저는 각각의 상기 웹 사이트로부터의 공유가능 및 비공유가능 고객 요청들의 예측 수요(forecasted demand)에 기초하여 상기 웹 사이트들을 특정의 서버들에 할당한다.

본 장치의 또다른 측면은 다이나믹 프로시저를 포함하며, 상기 다이나믹 프로시저는, 그 다음 고객 요청을 검사하는 단계, 어느 서버가 상기 그 다음 고객 요청을 현재 처리하기 위한 최적 서버인지를 결정하기 위해 상기 고울 프로시저를 호출하는 단계, 및 상기 그 다음 고객 요청을 상기 최적 서버로 디스패치하는 단계를 포함한다.

본 장치의 또다른 측면은 상기 고객 요청들을 큐 안으로 수신하는 단계를 포함하며, 상기 다이나믹 프로시저는, 상기 큐 내의 상기 고객 요청들을 모니터링하는 단계, 상기 서버들에 의해 현재 처리되고 있는 고객 요청들을 모니터링하는 단계,을 설정함으로써 각각의 j번째 서버에 대해 함수를 정의하는 단계,을 설정함으로써 각각의 j번째 서버에 대해 개정된 허용가능 부하 한계를 정의하는 단계, 및 상기함수 및 개정된 허용가능 부하 한계를 이용하여 이하의 식,,,인 경우,, 및인 경우의 제약 조건에 따라 함수를 최소화하기 위해 상기 고울 프로시저를 호출하는 단계를 더 포함하며, 여기서,는 서버 j에 의해 처리될 수 있는 웹 사이트 i에 대한 큐 내의 공유가능 요청들의 가상적 개수를 나타내는 결정 변수이고,는 서버 j에 의해 처리될 수 있는 웹 사이트 i에 대한 비공유가능 요청들의 가상적 개수를 나타내는 결정 변수이며,는 웹 사이트 i로부터의 큐 내의 공유가능 고객 요청들의 현재의 개수이고,는 웹 사이트 i로부터의 큐 내의 비공유가능 요청들의 현재의 개수이며,는 서버들 중 하나에서 현재 처리되고 있는 웹 사이트 i로부터의 공유가능 고객 요청들의 현재의 개수이고,는 서버들 중 하나에서 현재 처리되고 있는 웹 사이트 i로부터의 비공유가능 요청들의 현재의 개수이다.

웹 팜에 대해 개시되어 있으며, 이 웹 팜은 고객들로부터 고객 요청들을 수신하는 수단, 상기 고객 요청들을 처리하여 응답들을 생성하는 수단, 상기 응답들을 상기 고객들에게 전송하는 수단, 상기 고객 요청들을 공유가능 고객 요청들과 비공유가능 고객 요청들로 분류하는 수단, 및 네트워크 디스패처를 포함하며, 상기 네트워크 디스패처는 고울 프로시저, 스태틱 프로시저, 및 다이나믹 프로시저를 실행하는 수단을 포함하고, 상기 고울 프로시저는, 상기 웹 사이트들의 상기 서버들로의 상기 할당과 현재의 고객 요청 부하가 주어진 경우, 상기 고객 요청 각각에 대해 임의의 주어진 순간에 평균 고객 응답 시간을 최소화하기 위해 상기 각각의 고객 요청이 할당될 상기 서버들 중에서 최적의 서버를 결정하는 단계를 포함하며, 상기 공유가능 고객 요청들은 임의의 상기 서버로 할당될 수 있고, 상기 비공유가능 고객 요청들은 상기 비공유가능 고객 요청들이 어느 웹 사이트에서 발신되었는지에 따라 특정의 서버들에 할당될 수 있을 뿐이며, 상기 스태틱 프로시저는 특정의 상기 웹 사이트들을 특정의 상기 서버들에 할당하는 단계를 포함하고, 상기 다이나믹 프로시저는, 그 다음 고객 요청을 검사하는 단계, 어느 서버가 상기 그 다음 고객 요청을 현재 처리하기 위한 최적 서버인지를 결정하기 위해 상기 고울 프로시저를 호출하는 단계, 및 상기 그 다음 고객 요청을 상기 최적 서버로 디스패치하는 단계를 포함한다.

본 발명은 다수의 사이트들의 서버 할당들 사이에 중첩을 허용함으로써 웹 팜에서 부하를 분산시키는 문제의 해결을 제공하며 또 실제적인 방식으로 다양한 사이트들의 소유자들의 구미에 맞는 해결을 제공한다. 본 발명의 개시 내용은 1999년 8월 16일자로 출원되고 공동 양도된 동시 계류 중인 것으로서 발명의 명칭이 "METHOD AND APPARATUS FOR LOAD BALANCING OF WEB CLUSTER FARMS"(웹 클러스터 팜의 부하 분산 방법 및 장치)인 미국 특허 출원 제09/374,539호[대리인 문서 번호 12793(YO999-307)](현재 미국 특허 제6,374,297호)에 개시된 부하 분산 시스템 대신에 사용될 수 있다.

웹 사이트 세트(website set)를 중첩시키는 것의 이론적 배경은 유연성(flexibility)이다. 웹 팜은 많은 서로 다른 사이트들로부터의 고객 요청들을 동시에 처리할 수 있어야만 하며, 이러한 고객 요구는 일반적으로 폭주성이 있다(bursty). 이러한 폭주성(burstiness)은 웹 사이트 인기 및 고객 믹스(customer mix)의 변동으로 인해 주간 단위로, 일간 단위로, 및 시간 단위로 나타날 수 있다. 이러한 증거로 볼 때 폭주성이 분 단위 및 심지어 초단위 등의 훨씬 더 작은 원자 시간 단위(atomic time unit)로도 일어남을 시사한다. 여기서의 요점은 평균 웹 사이트 접속율(average website access rate)이 고객 행동의 변덕스런 성향을 충분히 사로잡지 못한다는 것이다. 한 웹 사이트의 트래픽은 극적으로 늘었다 줄었다 할 수 있고, 한 웹 사이트는 또다른 웹 사이트가 덜 북적거릴 때 북적거릴 수 있다. 바라는 것은 몇개의 사이트를 관리하는 서버가 이러한 동적인 트래픽에 반응하기 위해 이들 사이트 간의 부하 분산에 변화를 주도록 할 수 있게 하는 것이다. 분할 설계(partitioned design)에서는 이러한 반응 능력(reactive capability)이 가능하지 않음에 유의한다.

본 발명은 서버 자원을 효과적으로 풀링하고 이들 서버 상에 부하를 분산시키기 위해 프런트-엔드 디스패처(front-end dispatcher)에 지능적 방법을 사용한다. 본 발명은 각 웹 사이트가 하나 이상의 서버로 된 세트에 할당되고 또한 이들 세트가 중첩될 수 있는 것으로 생각하기에 충분할 정도로 일반화가능하다. 이것은 필요한 경우 주어진 서버가 다수의 사이트들로부터의 고객 요청들을 처리할 수 있음을 의미한다. 덜 바람직한 대안은 각 서버가 정확히 하나의 웹 사이트로부터의요청들을 처리하도록 여러 사이트들 간에 서버를 분할하는 것이다. 본 발명은 이러한 덜 양호한 특수한 경우에 역시 동작을 하지만 덜 효과적이다.

그렇지만, 웹 팜의 경우에 세트를 중첩시키는 것은 문제가 없지 않다. 적합한 성능을 갖는 서버가 적당한 수의 웹 사이트에 대응하는 것이 기술적인 관점에서 볼 때 합당하지만, 정략적인 관점에서 보면 그다지 합당하지 않을 수 있다. 예를 들어, 서버가 우연히 사이트들 사이에 논리적으로 분할되어 있다고 할지라도, 전자 상거래 상인은 트랜잭션 요청들을 처리하는 서버들을 다른 상인들과 공유하는 것을 거부할지도 모른다. 상인의 거부는 일반적으로 프라이버시 이유에 근거하게 된다. 다행스럽게도, 이러한 상인은 브라우징 요청(browse request)을 위해 서버들을 공유하는 것에 대해서는 거의 언제나 덜 민감하다. 부하 분산 절차가 실제적이고 따라서 구현가능하도록 하기 위해서는, 이러한 문제에 효과적으로 대처해야만 한다. 이것은 각 웹 사이트의 부하를 필요한 경우 2개의 부류, 즉 공유가 가능하지 않은 부류와 공유가 가능한 부류로 분할함으로써 달성될 수 있다. 이것은 (브라우저에 의해 개시된) 공개적 요청들(public requests)이 다른 사이트들로부터의 공유 가능 요청들(sharable requests)과 서버를 공유할 수 있는 것으로 가정한다. 공개적 요청들은 또한 동일한 웹 사이트로부터의 (트랜잭션에 의해 개시된) 개인적 요청들과 서버를 공유할 수 있다. 이러한 중요한 개량이 할당의 중첩이라는 정략적으로 변덕스런 문제에도 불구하고 잘 수행하기 위해 요구되는 유연성을 본 발명에 제공한다.

비록 본 명세서에서 본 발명이 2가지 레벨의 고객 트래픽의 관점에서 기술되어 있지만, 당업자라면 본 발명이 변동하는 웹 사이트 대 서버 제약 조건을 갖는 트래픽 레벨들의 계층 구조로 일반화가능한 것임을 잘 알 것이다.

비록 공개적 및 개인적 부류가 각각 브라우징 요청 및 트랜잭션 요청에 의해 개시되지만, 이들 용어는 실제로 공유 가능 여부(ability or inability to share)에 의해 정의된다는 것에 유의한다. 예를 들어 논리적 분할 개념을 받아들이고 있는 전자 상거래 사이트의 경우, 트랜잭션 요청은 공개적 트래픽(public traffic)의 일부로서 간주되고, 그 결과 개인적 트래픽(private traffic)은 전혀 없게 된다. 다른 극단의 경우, 브라우저에 대해조차도 서버들의 어떤 공유도 허용하지 않는 전자 상거래 사이트는 개인적 트래픽의 일부로서 간주되는 브라우징 요청들을 가지게 되며, 공개적 트래픽은 전혀 없다. 물론, 브라우징 및 트랜잭션이라는 용어들이 어쨋든 문자 그대로의 의미를 갖지 않는 비상거래 사이트(non-commercial site)도 있을 수 있다. 그럼에도 불구하고, 간단함을 위해, 트래픽은 공유가능성(sharability)에 따라 공개적 또는 개인적 부류 중 어느 하나로 분류되어진다.

본 발명은 웹 팜 부하를 아주 효과적으로 분산시키기 위해 웹 사이트 할당을 중첩시키는 것의 가능성을 이용한다. 문제는 자연스럽게 2가지 하위 문제들로 분리되며, 각각에 대한 해결은 적절한 목표를 설정하기 위해 동일한 기본적인 최적화 방법을 이용한다. 따라서, 고울 프로시저(Goal procedure), 스태틱 프로시저(Static procedure), 및 다이나믹 프로시저(Dynamic procedure)라고 불리우는 본 발명의 3가지 주요 컴포넌트가 있다.

고울 프로시저는 주된 공통 프로시저이다. 고울 프로시저는 사이트의 서버로의 할당 및 현재의 고객 요청 부하가 주어지면 임의의 주어진 순간에 평균 고객 응답 시간을 최소화시키도록 설계된 최적화 기술을 사용한다. 이 기술은 Tantawi 등의Optimal allocation of multiple class resources in computer systems(컴퓨터 시스템에서의 다중 클래스 자원의 최적 할당), ACM Sigmetrics Conference(1998년 5월)의 제253면 내지 제260면에 기재된 소위 이산 클래스 제약 분리가능 볼록 자원 할당 문제(discrete class constrained separable convex resource allocation problem)를 해결하는 데 사용된 것의 약간 특수한 경우이다. 따라서, 이 방법은 최적의 부하 분산 목표를 결정하게 된다. 구체적으로 설명하면, 그 출력은 각각의 해당 서버에 의해 처리될 각 웹 사이트에 대한 공개적 및 개인적 부류 둘다의 고객 요청들의 최적의 개수, 따라서 합산에 의해 서버당 모든 고객 요청들의 최적의 개수이다. 이 문제는 비교적 빈번하게 해결될 필요가 있다. 다행스럽게도, 이 해결 기술은 고속이다(또 증가 속성이 있다)(incremental in nature). 이 기술은 이기종 서버를 처리할 수 있으며, 어떤 오래된 저속의 서버가 시간의 경과에 따라 불가피하게 새로운 고속의 서버로 교체되어야 할 것이기 때문에 중요하다. 고울 프로시저는 이하의 다이나믹 프로시저와 스태틱 프로시저 컴포넌트의 필수적인 부분이다.

스태틱 프로시저는 공개적 및 개인적 요청의 요구 사항을 존중하면서 양호한, 거의 최적이기를 바라는, 사이트의 서버로의 할당을 생성한다. 이것이 보다 양호하게 행해질수록 고울 프로시저에서의 평균 응답 시간이 더 좋아질 수 있다.스태틱 프로시저 컴포넌트는 그 자신이 진행함에 따라 고울 프로시저를 반복적으로 호출한다. 이 기술은 초기 모드(initial mode) 또는 증가 모드(incremental mode) 중 어느 하나로 실행될 수 있다. 초기 모드는 새로운 웹 팜을 구성할 때 적절하다. 증가 모드는 할당 변경의 회수를 제한하는 제약 조건을 허용하며, 따라서 고품질의 웹 사이트 대 서버 할당을 유지하는 데 실용적이다. R. Garfinkel 등의Integer Programming(정수 프로그래밍), John Wiley and Sons, New York, NY (1972)에 기재되어 있는 것과 같은 이웃 도피 발견적 학습법(neighborhood escape heuristic)이 이용된다. 증가 모드는 주기적으로, 아마도 주당 1회 정도로 실행되도록 되어 있다. 웹 사이트 대 서버 할당을 재구성하는 것이 분명히 사소한 작업은 아니다. 정확한 회수는 웹 사이트 수요 예측의 변동성(volatility) 및 새로운 할당을 행하는 비용에 의존하고 있다.

다이나믹 프로시저는 스태틱 프로시저 컴포넌트의 출력 및 변동하는 웹 사이트 고객 수요에 기초하여 네트워크 디스패처에서 실시간 웹 서버 라우팅을 수행한다. 다이나믹 프로시저는 이러한 이상적이라고 생각되는 라우팅을 계산하기 위해 고울 프로시저에 기초하여 제한된 하위 문제(restricted subproblem)를 해결한다. 다이나믹 프로시저는 이전에 디스패치된 요청들의 할당을 이전하지 않으며, 이는 성능을 추가로 향상시킬 수 있지만 엄청나게 많은 오버헤드에 봉착하게 된다.

도 1을 참조하면, 3개의 사이트(12)와 9개의 서버(13)를 갖는 가상적 웹 팜(10)의 일례가 도시되어 있다. 네트워크 디스패처(network dispatcher)(14)는 3개의 사이트(12)에 대한 고객 요청을 해당 서버로 라우팅한다. 제1 웹사이트(12a)는 2개의 서버(1, 2)를 포함하고, 5개의 서버(2 내지 6)를 갖는 제2 웹 사이트(12b)와 중첩되어 있으며, 이 제2 웹 사이트(12b)는 이어서 4개의 서버(6 내지 9)를 갖는 제3 웹 사이트(12c)와 중첩되어 있다. 고객 요청의 결과는 다시 고객들에게 파이핑(pipe)되고, 그 고객은 이어서 부가의 요청을 할 수 있다.

도 1의 예시적인 일례를 참조하여, 본 발명의 3가지 주요 컴포넌트에 대해 상세히 설명하는 것이 유용할 것이다.

고울 프로시저(고울) 컴포넌트

먼저 일부 표기법을 정의하면 유용할 것이다. M은 편의상 항상 i로 인덱싱되는 웹 사이트의 개수를 나타내는 것으로 한다. N은 j로 인덱싱되는 서버의 개수를 나타내는 것으로 한다. {0,1} MxN 행렬 A=(a_i,j)가 웹 사이트 i에 대한 공개적 요청을 서버 j에 할당하는 것에 대한 가능성(potential)을 나타내는 것으로 한다. 환언하면, 웹 사이트 i에 대한 공유가능 요청(sharable request)이 서버 j에 의해 처리될 수 있는 경우 a_i,j= 1이고, 그렇지 않은 경우 a_i,j= 0이다. 이와 유사하게, {0,1} MxN 행렬 B=(b_i,j)가 웹 사이트 i에 대한 개인적 요청을 서버 j에 할당하는 것에 대한 가능성(potential)을 나타내는 것으로 한다. 환언하면, 웹 사이트 i에 대한 비공유가능 요청(non-sharable request)이 서버 j에 의해 처리될 수 있는 경우 b_i,j= 1이고, 그렇지 않은 경우 b_i,j= 0이다. 우리는 실제로 웹 사이트 i에 대한 개인적 요청을 처리하는 서버 j가 그 웹 사이트에 대한 공개적 요청도 처리할수 있는 것으로 가정할 것이다. 따라서, b_i,j= 1인 경우 a_i,j= 1이다.

예상 응답 시간을 고객 도달율(customer arrival rate)의 함수로서 측정하는 함수 R_j는 각각의 서버 j와 관련되어 있다. 이 함수는 서비스 시간 분포(service time distribution)에 의존하며, 이 서비스 시간 분포는 이어서 프로세서의 속도에 의존한다. 함수 R_j는 일반적으로 증가 함수이면서 볼록 함수이다. 여기에 인용함으로써 그 전체 내용이 본 명세서에 포함되는 Lavenberg의Computer Performance Modeling Handbook(컴퓨터 성능 모델링 핸드북), Academic Press, New York, NY (1983)에 기재되어 있는 도달율 패턴 및 서비스 시간 분포에 관한 어떤 간단화 가정들하에서 R_j를 계산 또는 추정하는 고전적인 큐잉 기술이 있지만, 일반적으로 그 함수는 시뮬레이션 실험 또는 모니터링을 통해 계산될 필요가 있을 수 있다.

이 함수에 기초하여 볼 때, 이 임계값을 초과하면 R_j의 값이 너무 커지게 될 것이라는 의미에서 서버 j에 대한 최대 허용 부하 L_j가 있을 것으로 가정할 수 있다. 우리가 L_j= ∞로 설정하면, 이러한 최대 부하 제약 조건은 물론 완화될 것이다. 주어진 순간에 웹 사이트 i에 대해 c_i개의 공개적 요청 및 d_i개의 개인적 요청이 진행 중에 있는 것으로 가정한다. 추가적으로 이것들을 서버 j 상의 웹 사이트 i에 대한 c_i,j개의 공개적 요청 및 d_i,j개의 개인적 요청으로 분해한다. 따라서,이고, a_i,j= 0일 때는 항상 c_i,j= 0이다(웹 사이트가 할당되지 않은 서버로부터 그 웹 사이트에 대한 공개적 요청을 처리할 수는 없다). 이와 마찬가지로, b_i,j= 0일 때는 항상 d_i,j= 0이다. 우리는가 진행 중인 공개적 요청의 총 개수를 나타내는 것으로 하고, 이와 마찬가지로가 진행 중인 개인적 요청의 총 개수를 나타내는 것으로 한다.

서버 부하는 현재의 부하 및 웹 사이트 대 서버 할당이 주어진 경우 이하의 수학식 1로 표현된 목적 함수가 이하의 수학식 2 내지 수학식 6의 제약 조건들에 따라 최소화될 때 최적으로 분산된 것으로 간주될 수 있다.

인 경우

여기서, x_i,j는 서버 j에 의해 처리될지도 모르는 웹 사이트 i에 대한 공개적 요청의 가상적 개수를 나타내는 결정 변수(decision variable)이다. 이와 유사하게, y_i,j는 서버 j에 의해 처리될지도 모르는 웹 사이트 i에 대한 개인적 요청의 가상적 개수를 나타내는 결정 변수(decision variable)이다. 목적 함수는 여러가지 서버에서의 예상 응답 시간의 합을 측정하며, 이는 배수 상수(multiplicative constant)만큼 평균 응답 시간과 다르다. 이 상수는 최적화 문제의 관점에 볼 때 관련이 없는 것이다. 수학식 2의 제약 조건은 서버 i에 대한 허용가능 부하를 제한한다. 수학식 3의 제약 조건은 웹 사이트 i 공개적 요청의 총 개수가 진행 중인 이러한 요청의 실제 개수와 같도록 보장해준다. 수학식 4의 제약 조건은 웹 사이트 대 서버 할당이 공개적 요청에 대해 존중되도록 해준다. 수학식 5 및 수학식 6의 제약 조건은 개인적 요청에 대한 대응하는 요구 사항이다. 최적 해(optimal solution)에서이고이면,가 서버에 대한 원하는 부하를 표현함에 유의한다. 우리의 궁극적인 목표는 최적의 부하와 실제 부하가 각 서버 j에 대해 항상 서로에 가깝도록 보장해주는 것이다.

상기한 최적화 문제는 소위 이산 클래스 제약 분리가능 볼록 자원 할당 문제의 특수한 경우이다. 이 클래스들은 여러가지 사이트에 대한 공개적 및 개인적 요청에 대응한다. 문제는 수학식 2의 제약 조건으로 인해 이산적이고, 수학식 3 및 수학식 5의 제약 조건으로 인해 자원 할당 문제이며, 수학식 4 및 수학식 6의 제약 조건으로 인해 클래스 제약이다. 분리가능성(separability)이라는 용어는 목적 함수의 성질을 말하는 것으로서, 볼록성(convexity)이라는 용어는 그 자체로 명확하다. Tantawi 등에 의해 개시된 바와 같이, 이산 클래스 제약 자원 할당 문제는 그래프-이론적 최적화 프로시저(graph-theoretic optimization procedure)를 사용하여 정확하고 효율적으로 해결될 수 있다.

도 3을 참조하면, 고울 프로시저의 양호한 실시예의 플로우차트가 도시되어 있다. 실현가능 해(feasible solution)가 존재하는 것으로 가정하면, 프로시저는 C + D개의 단계를 이루어 진행된다. 도 2에서의 같은 방향 그래프가 생성되고, 프로시저의 전 과정에 걸쳐 유지된다. 그래프의 노드들은 서버 1, ..., N와, 그에 덧붙여 "노드 0"라고 표시된 더미 노드다. 각각의 i에 대해 a_i,0= 1이고 b_i,0= 1이며, L₀= 0인 것으로 설정한다. 우리는 부분 실현 가능 해(partial feasible solution) 을 생성하여 수정한다. 처음에, 도 3의 단계 100 및 단계 105에서, 이 부분 실현 가능 해는 각각의 i에 대해이고 모든에 대해를 갖도록 설정되며, 따라서 모든 자원은 더미 노드에 존재한다. 방향 그래프는 단계 110에서 초기화되고, 어떤 단계에서든지 이하의 수학식 7, 수학식 8, 및 수학식 9의 조건을 만족시키는 적어도 하나의 웹 사이트가 i₁이 있는 경우 또는 다른 대안에서 이하의 수학식 10, 수학식 11, 및 수학식 9의 조건을 만족시키는 적어도 하나의 웹 사이트 i₁이 있는 경우 노드에서 노드로의 방향 연결선(directed arc)을 갖는다.

수학식 7의 조건은 노드 j₁과 j₂가 웹 사이트 i₁에 대한 공개적 요청을 처리할 수 있음을 나타낸다. 수학식 8의 조건은 웹 사이트 i₁에 대한 공개적 요청이 노드 j₁에 할당되었음을 나타낸다. 수학식 9의 조건은 이 요청이 노드 j₂에 대한 부하 한계를 초과하지 않고 그 노드 j₂로 이전될 수 있음을 나타낸다. 수학식 10, 수학식 11, 및 수학식 9의 조건은 개인적 요청에 대한 대응하는 요구 사항이다. 노드 0으로부터 방향 연결선이 있을 수 있지만 노드 0로의 방향 연결선은 없음에 유의한다. 따라서, 수신 노드는 항상 실제 서버이며 더미 노드가 아니다.

본 방법의 일반적인 단계는 0으로부터 j로 방향 경로(directed path)가 있는 모든 노드들중에서 수학식 12로 나타낸 제1 차분이 최소가 되는 위닝 노드를 찾아낸다.

이 소위 제1 차분은 연속 함수에 대한 도함수의 이산 아날로그(discrete analog)이다. 이 제1 차분은 R_j의 볼록성(convexity)으로 인해 각각의 i에 대해 비감소적(non-decreasing)이다. 이러한 노드가 존재하지 않는 경우, 프로시저는 실현 불가능 해(infeasible solution)로 종료한다. 그렇지 않은 경우, 0에서 위닝 노드로의 최단 방향 경로가 선택된다. 이 경로 내의 각각의 방향 연결선 (j₁, j₂)에 있어서, 해당 웹 사이트 i₁에 대해 (공개적 요청에 대한 감소 및 증가 또는 개인적 요청에 대한 감소 및 증가 중 어느 하나에 의해)의 값은 1 씩 감소하고,의 값은 1씩 증가한다. 모든 방향 연결선에 대해 이 단계를 수행하면 한 단위의 부하를 더미 노드로부터 제거하고 한 단위의 부하를 위닝 노드에 부가하는 효과가 있다. 중간 노드의 부하에 대해서는 순 효과(net effect)가 없다. 따라서, 더미 노드는 자원의 스테이징 영역(staging area)으로서 기능하며, 그 자원들 중 하나는 각 단계에서 서버 노드들로 릴리스(release)된다. 이어서, 북키핑(bookkeeping)이 방향 그래프에 대해 수행되며, 이는 일부 방향 연결선들을 수정할 수 있으며 어쩌면 일부 노드들을 분리시킬 수 있고, 그 단계는 반복된다. (C + D)개의 단계 후에, 프로시저는 최초의 이산 클래스 제약 자원 할당 문제의 최적 해로 종료한다. 방향 그래프 내의 연결선들에 대한 조건으로 인해 실현 가능성이 보장된다.

보다 상세하게는 도 3을 참조하면, 고울 프로시저의 양호한 실시예가 단계100에서 모든 사이트 i와 서버 j에 대해 변수 x_i,j및 y_i,j를 0으로 설정하는 것으로 시작한다. 이 프로시저는 그 자신이 진행함에 따라 이들 변수를 증가 및 감소시킨다. 단계 105에서, 더미 노드는 노드 0으로 초기화된다. 모든 자원들이 처음에 그곳에 놓여 있으며, 따라서 우리는 x_i,0= c_i및 y_i,0= d_i로 설정한다. 단계 110에서, N+1개의 노드들을 연결시키는 방향 그래프는 이하에서 도 3b를 참조하여 보다 상세히 기술하는 바와 같이 수학식 7 내지 수학식 11의 방정식에 따라 초기화된다. 이것으로부터 a_i,j= 1 또는 b_i,j= 1인 적어도 하나의 웹 사이트 i가 있도록 더미 노드 0으로부터 노드 j로의 방향 연결선이 있을 것으로 결정할 수 있다. 이 그래프는 프로시저가 진행함에 따라 수정될 것이다. 단계 115에서, k = 1로 설정한다. 이 변수는 자원이 할당될 때 자원의 단위를 카운트한다. 단계 120에서, m을 무한대(∞)로 초기화하고 j를 1로 초기화한다. 단계 125에서 0에서 노드 j로 방향 경로가 있는지를 결정한다. 있는 경우, 단계 130에서 이 서버 j에 대한 수학식 12의 방정식을 계산하고 그것을 m과 비교한다. m보다 작은 경우, 단계 135에서 j* = j로 설정하고 m을 수학식 12의 방정식의 값으로 설정한다. 이것이 현재 가장 작은 m의 값이다. 이어서, 단계 140으로 진행한다. 또한 단계 125에서 경로가 없는 경우 또는 단계 130에서 수학식 12의 방정식이 m 이상인 것으로 평가되는 경우 단계 140으로 진행한다. 단계 140에서 j를 증가시킨다. 단계 145에서 j가 N 이하인지를 검사한다. N이하인 경우, 단계 125로 되돌아간다. 그렇지 않은 경우, 단계 150으로 가서 m을 무한대와 비교한다. m이 무한대보다 작지 않은 경우, 더미 노드에서 임의의 노드로의 경로가 없으며, 따라서 그 문제에 대한 실현 가능 해가 없다. 따라서, 프로시저는 단계 155에서 종료된다. 그렇지 않은 경우, 단계 160으로 진행하여 최단의 이러한 경로를 찾아낸다. 단계 165에서 이 경로에 대해 북키핑(bookkeeping)을 수행하고, x_i,j및 y_i,j의 해당 값을 증가 및 감소시킨다. 그렇게 함에 있어서, 도 3c를 참조하여 이하에 보다 상세히 기술하는 바와 같이 한 단위의 자원이 더미 노드로부터 제거되고 한 단위의 자원이 서버 j*에 부가된다. 이어서, 단계 170에서 방향 그래프에 대해 북키핑을 수행하여, 또다시 수학식 7 내지 수학식 11의 방정식이 만족되도록 한다. 이 프로세스에서 일부 방향 연결선들은 부가될 수 있고 일부는 제거될 수 있으며, 이에 대해서는 이하에서 도 3d를 참조하여 보다 상세히 기술한다. 단계 175에서, k를 증가시킨다. 단계 180에서 k가 C + D 이하인지를 알아보기 위해 k를 검사한다. 이하가 아닌 경우, 프로시저는 단계 185에서 최종 해 x_i,j와 y_i,j로 종료하고, 그렇지 않은 경우 단계 120으로 되돌아가서 프로시저를 계속한다.

도 2를 참조하면, 클래스 제약 자원 할당 프로시저의 방향 그래프가 도시되어 있다. 그 그래프의 모든 노드 및 방향 연결선이 동 도면에 도시되어 있는 것은 아님에 유의한다. 부하는 더미 "노드 0"(20)로부터 제1 차분이 최소가 되는 노드 0에 연결되어 있는 노드인 위닝(서버) 노드(25)로 이전된다. 도시된 방향 경로는 최단 방향 경로인 것으로 의도된 것이다. 방향 연결선에는 1 내지 5의 번호가 부기되어 있다. 동 도면에서, 어떤 웹 사이트에 대한 하나의 새로운 (공개적 또는개인적) 요청이 방향 연결선 1을 통해 할당되지만, 그 요청이 할당되는 제1 (서버) 노드(21)는 그의 동작 레벨(level of activity)을 변경하지 않는다. 사실, 처음 4개의 서버 노드(21 내지 24)는 서로 다른 동작 레벨을 갖지 않는다. 5번째 위닝 서버 노드(25)는 더미 노드(20)의 대가로 한 단위의 동작의 이득(a gain of one unit of activity)을 경험한다.

도 3b를 참조하면, 도 3의 단계 100에 대응하는 초기화 프로시저의 플로우차트가 도시되어 있다. 단계 400에서, j = 1로 초기화하고 이어서 단계 405에서 L_j가 0보다 큰지 여부를 알아보기 위한 검사를 한다. 0보다 큰 경우, 단계 410에서 i를 1로 초기화하고, 단계 415에서 a_j가 0보다 큰지를 알아보기 위한 검사를 한다. 0보다 큰 경우, 단계 420에서 x_io가 0보다 큰지를 알아보기 위한 검사를 한다. 0보다 큰 경우, 단계 425에서 더미 노드 0로부터 j로의 방향 연결선을 생성하고 단계 430으로 진행한다. 단계 415 또는 단계 420 중 하나가 실패하면, 단계 435로 진행하여, b_j가 0보다 큰지를 알아보기 위한 검사를 한다. 0보다 큰 경우, 단계 440에서 y_i0가 0보다 큰지를 알아보기 위한 검사를 한다. 0보다 큰 경우, 이전과 마찬가지로 단계 425로 진행한다. 단계 435 또는 단계 440 중 하나가 실패하면, 제어는 단계 430으로 진행하여, j가 증가된다. 단계 445에서, j가 N보다 작거나 같은지를 알아보기 위한 검사를 한다. 작거나 같지 않으면, 제어는 단계 405로 되돌아가고, 작거나 같으면 단계 450에서 종료한다.

도 3c를 참조하면, 도 3의 단계 165의 경로 북키핑 프로시저(path bookeeping procedure)의 플로우차트가 도시되어 있다. 이 플로우차트에서, 최단 경로가 k개의 방향 연결선을 가지며 j₀= 0에서 j₁, j₂, ..., j_k= j까지의 라벨이 붙여져 있다. 단계 500에서, j = 0으로 초기화하고, 단계 505에서 i = 1로 초기화한다. 단계 510에서 a_ij= a_i(j+1) = 1인지를 알아보기 위한 검사를 한다. 그러한 경우, 단계 515에서 x_ij가 0보다 큰지를 검사한다. 그러한 경우, 단계 520에서 x_ij를 감소시키고 x_i(j+1)을 증가시킨다. 단계 510 또는 단계 515 중 하나에서의 검사가 실패하면, 단계 525로 진행하여, 이와 유사하게 b_ij= b_i(j+1) = 1인지를 알아보기 위한 검사를 한다. 그러한 경우, 단계 530에서 y_ij가 0보다 큰지를 검사한다. 0보다 큰 경우, 단계 535에서 y_ij를 감소시키고 y_i(j+1)을 증가시킨다. 단계 525 또는 단계 530 중 어느 하나가 실패하면, 단계 540으로 진행하여 i를 증가시키고 단계 510으로 되돌아간다(하나의 서버 i가 제약 조건들로 인해 종국적으로 이 검사를 통과할 것임은 알고 있는 바이다). 이제 단계 520 또는 단계 535 후에, 단계 545로 진행하여 j를 증가시킨다. 단계 550에서 j가 k보다 작은지를 알아보기 위한 검사를 한다. 작은 경우, 단계 505로 되돌아한다. 작지 않은 경우, 프로시저는 단계 555에서 종료한다.

도 3d를 참조하면, 도 3의 단계 170의 그래프 북키핑 프로시저의 플로우차트가 도시되어 있다. 단계 600에서 시작하여, j₁을 1로 초기화한다. 단계 605에서,j₂를 1로 초기화한다. 단계 610에서 L_j2에 관한 수학식 9의 조건이 참인지를 알아보기 위한 검사를 한다. 참이 아닌 경우, 프로시저는 단계 612에서 종료하고, 참인 경우 단계 615에서 i = 1로 초기화하고 이어서 단계 620에서 a_ij1= a_ij2= 1인지를 알아보기 위한 검사를 한다. 그러한 경우, 단계 625에서 x_ij1이 0보다 큰지를 알아보기 위한 검사를 한다. 0보다 큰 경우, 단계 630에서 노드 j₁으로부터 노드 j₂로의 방향 연결선을 생성하고, 단계 635로 진행하여 j₂를 증가시킨다. 단계 620 또는 단계 625 중 어느 하나가 실패하면, 단계 640으로 진행하여 b_ij1= b_ij2= 1인지를 알아보기 위한 검사를 한다. 그러한 경우, 단계 645에서 y_ij2가 0보다 큰지를 알아보기 위한 검사를 한다. 0보다 큰 경우, 이전과 같이 단계 630으로 진행한다. 단계 640 또는 단계 645 중 어느 하나가 실패하면, 단계 635로 진행한다. 단계 650에서, j₂가 N보다 작거나 같은지를 알아보기 위한 검사를 한다. 작거나 같은 경우, 단계 655에서 j₁을 증가시키고 단계 660으로 진행하여 j₁이 N보다 작거나 같은지를 알아보기 위한 검사를 한다. 작거나 같지 않은 경우, 단계 665에서 종료한다. 단계 650에서의 검사가 실패하면, 단계 670으로 진행하여 j₁= j₂인지를 검사한다. j₁= j₂인 경우, 단계 635로 복귀하고, 그렇지 않은 경우 단계 610으로 복귀한다. 단계 660에서의 검사가 실패하면, 단계 675로 진행하여, 마찬가지로 j₁= j₂인지를 검사한다. j₁= j₂인 경우, 단계 655로 복귀하고, 그렇지 않은 경우 단계 605로 복귀한다.

다이나믹 프로시저(다이나믹)

도 4를 참조하면, 이제부터 부하 분산 프로시저의 다이나믹 프로시저 컴포넌트에 대해 설명한다. 이 기술은 (스태틱 프로시저 컴포넌트) 사이트의 서버로의 할당을 이미 알고 있는 것으로 가정한다. 이것은 행렬 A 및 B을 결정하는 것에 대응한다. 이 기술은 이어서 네트워크 디스패처에서의 새로운 고객 요청의 도달 뿐만 아니라 서버에서의 정확한 또는 대략적인 부하를 모니터링한다. 다이나믹 프로시저 컴포넌트의 임무는 이들 큐잉된 요청들에 대해 네트워크 디스패처에서 라우팅 결정을 행하여 그 요청들을 해당 서버에 할당하는 것이다. 그렇게 함에 있어서, 다이나믹 프로시저 컴포넌트는 고울 프로시저에 의해 규정된 최적의 평균 응답 시간 및 서버 부하 레벨을 가능한 정도까지 달성하려고 노력한다. 실제로, 다이나믹 프로시저 컴포넌트는 그의 결정을 행하기 위해 네트워크 디스패처에 큐잉되어 있는 트래픽에 대해 고울 프로시저를 호출한다. 라우팅 결정은 정확한 또는 확률론적 정책을 통해 구현될 수 있다. 요청들이 일단 스태틱 프로시저 컴포넌트에 의해 서버들에 할당되면, 그 요청들은 그 서버들에서 충족되어진다. 다시 말하면, 양호한 실시예에서, 네트워크 디스패처의 결정은 최종적인 것으로 간주되며, 서버에서의 요청들 그 자체는 부하에 기초하여 리디렉션될 수 없다.

어떤 메타 표기법(meta notation)을 정의하면 유용할 것이다. 임의의 주어진 시간에, 일부 부하는 네트워크 디스패처에 큐잉되고 일부는 이미 서버들로 디스패치되어 있을 것이다. 우리는 전체 부하 뿐만 아니라 이들 2가지 유형의 부하도 구별하고자 한다. 우리는 디스패처에서의 부하에 관한 변수를 가리킬 때는단일 도트(single dot)를 사용하고, 서버에서의 부하에 관한 변수를 가리킬 때는이중 도트(double dot)를 사용할 것이다. 도트가 사용되지 않은 경우, 그 변수는 디스패처 및 서버의 합성 부하(combined dispatcher and server load)를 가리키는 것이다.

본 방법은 서버 j 상의 웹 사이트 i에 대한 디스패치된 공개적 요청의 현재의 개수와 디스패치된 개인적 요청의 개수를 모니터링한다. 다이나믹 프로시저 컴포넌트는 서버 상에서의 요청의 완료에 직접 반응하지 않지만,와의 값을 적절히 감소시킨다. 이 데이터가 즉시 이용할 수 없는 경우, 그것은 추정될 수 있다. 그 동안, 새로운 요청들이 도달하고 네트워크 디스패처에 큐잉된다.는 다이나믹 프로시저 컴포넌트의 마지막 실행 이후의 웹 사이트 i에 대한 새로운 공개적 요청의 개수를 나타내는 것으로 한다. 이와 마찬가지로,는 다이나믹 프로시저 컴포넌트의 마지막 실행 이후의 웹 사이트 i에 대한 새로운 개인적 요청의 개수를 나타내는 것으로 한다. 이를 전부 합하여,와는 각각 디스패처에 큐잉된 공개적 요청들과 개인적 요청들의 총 개수를 나타내는 것으로 한다.

다이나믹 프로시저 컴포넌트는 일정한 시간 구간 후에, 또는 큐 내의 항목들의 개수가 어떤 고정된 배치 크기 임계값(fixed batch size threshold)에 도달한 후에, 또는 아마도 양쪽 기준의 어떤 조합에 의해, 웨이크업(wake up)되어 실행되도록 설계될 수 있다.

고울 프로시저를 네트워크 디스패처에 큐잉되어 있는 요청들에 적용하는 반면 이미 디스패치된 요청들은 내버려 둔다. 이를 위해, 약간의 북키핑이 요구될 것이다. 구체적으로 설명하면, 이하의 수학식 13을 설정함으로써 각각의 서버 j에 대해 새로운 볼록 증가 함수(convex increasing function)를 정의한다.

이 함수는 서버에서의 비섭동성 부하(unperturbable load)의 양을 고려하기 위해 원래의 함수를 단순히 이동시킨다. 같은 이유로, 각각의 서버 j에 대해 이하의 수학식 14를 설정함으로써 개정된 허용가능 부하 한계를 정의한다.

이들 공식에서,개의 큐잉된 요청들을 디스패치하는 최적의 방법은 이하의 제한된 고울 프로시저 컴포넌트 문제를 해결함으로써 결정된다.

즉, 수학식 16 내지 수학식 20의 제약 조건에 따라 수학식 15를 최소화시키는 문제로서 도 4의 단계 200에 대응한다.

인 경우

최적 해에서도, 서버 j 상에서의 총 부하는 전반적으로 차선적이다. 그렇지만, 이미 할당된 부하가 서버들 사이에서 이전될 수없다는 부가의 제약 조건에 따라 최적이다.

게다가, 어떤 웹 사이트 i₁에 대해또는중 어느 하나가 되도록 새로운 요청이 네트워크 디스패처에 도달할 때마다 이 기술이 웨이크업하는 특수한 경우에, 그 프로시저는 정말로욕심이 많은 것이다(greedy). 다시 말하면, 웹 사이트 i₁에 대한 새로운 공개적 요청이 할당되도록인 경우, 이하의 수학식 21의 제1 차분이 최소가 되는,와를 만족시키는 그 서버 j가 선택된다.

웹 사이트 i₁에 대한 새로운 개인적 요청이 부가되도록인 경우, 수학식 21에 의해 주어지는 제1 차분이 최소가 되는,와 부하 한계 제약 조건을 만족시키는 그 서버 j가 선택된다.

다이나믹 프로시저는 도 5 및 도 6에 도시된 일례에 의해 설명될 수 있다. 8개의 사이트를 호스팅하는 15 서버 구성을 생각해보자. 공개적 웹 사이트 트래픽을 처리하기 위해 할당된 5개의 서버가 있다. 이들 서버를클러스터서버(cluster server)라고 부를 것인데, 왜냐하면 각각의 이러한 서버가 다수의 사이트로부터의 트래픽을 처리하는 기능을 가지고 있기 때문이다. 또한, 개인적인 웹 사이트 트래픽을 처리하기 위해 할당된 10개의 서버가 있다. 따라서, 이들 서버는분할서버(partition server)라고 부를 것이다. 각각의 이러한 서버는 공개적 및 개인적 트래픽 둘다를 처리할 수 있지만, 단지 하나의 웹 사이트로부터의 것만을 처리한다. 이 일례에 대한 웹 사이트 심볼 용어 모음인 도 5를 생각해보자. 각각의 심볼은 웹 사이트에 고유한 형상을 갖는다. 예를 들어,circularlogic.com은 원으로 표현되어 있다. 회색 심볼은 공개적 트래픽을 나타내고, 검정색 심볼은 개인적 트래픽을 나타낸다. 관련 클러스터 및 분할 서버 카디날리티(cardinality)도 나타내어져 있다. 이들은 각각 할당 행렬 A와 B의 행 합산와이다. 예를 들어,circularlogic.com은 3개의 클러스터 서버와 2개의 분할 서버를 할당받는다.

이들 모두가 도 6에 보다 상세히 나타내어져 있다. 내부 루프(inner loop)는 5개의 클러스터 서버(C1 내지 C5)를 포함하고, 외부 루프(outer loop)는 10개의 분할 서버(P1 내지 P10)를 포함한다. 예를 들어,circularlogic.com은 클러스터 서버 C1, C2, 및 C5에 할당되어 있음에 유의한다. 서버 C1 상에서는, 이 웹 사이트에 대한 공개적 트래픽이hexnut.com및eggcentric.com에 대한 공개적 트래픽과 그 서버를 공유해야만 한다. 이와 마찬가지로,circularlogic.com은 분할 서버 P1 및 P2에 할당된다. 이들 2개의 서버 각각은 공개적 및 개인적 트래픽 둘다를 처리하지만 단지 이 웹 사이트에 대한 것만을 처리한다.

실제로, 도 6은 더 많은 정보를 전달한다. 도 6은 고울 프로시저에 의해 사용되는 종류의 약간 수정된 방향 그래프를 나타내고 있다. 클래스 제약 자원 할당 문제의 해결에서 특정의 순간에서의 더미 노드로부터 서버 노드까지의 최단 경로를 나타낸 도 2를 다시 참조하자. 이와 반대로, 도 6은 한가지 예외를 두고서 이러한 순간에서의 모든 방향 연결선 및 노드를 나타내고 있는 방향 그래프 H를 도시하고 있다. (이 예외는 더미 노드와 그로부터 나오는 방향 연결선이 제거되어 있다는 것이다)

따라서, H는 다음과 같이 정의된다. 즉, 노드는 서버에 대응하는 것으로 정의된다. 개별적인 서버 노드의 각각의 쌍 j₁과 j₂에 대해, 수학식 7 내지 수학식 9의 조건 또는 수학식 10, 수학식 11 및 수학식 9의 조건을 만족시키는 적어도 하나의 웹 사이트 i₁이 존재하기만 하면 j₁으로부터 j₂로의 방향 연결선이 있다.

도 6에서, 모든 방향 연결선이 양쪽 방향으로 나타나는 것은 아닌데, 왜냐하면 그 방향 연결선들이 관련 제약 조건들 모두를 만족시킬 수 없을 수 있기 때문이다. 예를 들어, P3로부터 P4로 방향 연결선이 없는데, 이는 공개적(수학식 8의 조건)이든 개인적(수학식 11의 조건)이든 간에 P3에 부하가 없기 때문에 자명하다. C3로부터 P7로 방향 연결선이 없는데, 이는 P7이 최대 용량(full capacity)으로 동작하고 있기 때문에 자명하다(수학식 9의 조건). C1과 P3 사이에는 어떤 방향으로도 연결선이 없는데, 이는 P3 상에 공개적 부하가 없기 때문에(수학식 8의 조건) 또한 C1이 최대 용량으로 동작하고 있기 때문에 자명하다. P1과 C4 사이에 어떤 방향으로도 연결선이 없는데, 이는 수학식 7의 조건이나 수학식 10의 조건 어느 것도 만족되지 않기 때문이다.

다시 말하면, 방향 연결선의 존재는 서버 상의 부하를 감소시키고, 또하나의 서버 상의 부하를 그 부하 용량(load capacity)을 초과하지 않고 증가시키며, 또한 다른 서버들 상의 부하들을 변함없이 그대로 둘 가능성을 나타낸다. 더미 노드로부터 서버 노드들 중 하나로의 방향 경로는 스테이징 노드(staging node)로부터 그 서버 노드로의 한 단위의 부하의 이전을 가능하게 해주며, 모든 다른 서버 노드들은 변함없이 그대로 둔다. 이 이전 이후에, 그래프 H는 수학식 8, 수학식 9 및 수학식 11의 제약 조건의 현재의 상태를 존중하기 위해 북키핑 기술을 통해 수정될 수 있다. (수학식 7 및 수학식 10의 제약 조건의 상태는 그대로 있음)

도 6에서 3가지 서로 다른 유형의 방향 연결선을 볼 수 있다. 하나의 분할 서버로부터 또하나의 분할 서버로의 공개적 또는 개인적 부하 중 하나의 잠재적 이전을 나타내는 한 유형은 P1과 P2 사이에서 볼 수 있다. 분할 서버로부터 클러스터 서버로 또는 그 반대로 공개적 부하 사이의 잠재적 이전을 나타내는 제2 유형은 P1과 C1 사이에서 볼 수 있다. 한 클러스터 서버로부터 또하나의 클러스터 서버로의 공개적 부하 사이의 잠재적 이전을 나타내는 제3 유형은 C1과 C2 사이에서 볼 수 있다.

그래프 H가 가능한 한 많은 방향 연결선을 갖는다는 측면에서 더욱조밀(tight)해질수록, 고울 프로시저가 더 낮은 응답 시간을 가져오는 양호한 품질 결과를 달성할 가능성이 더 많아지게 된다. 이것은 다음에 설명할 스태틱 프로시저 컴포넌트의 목표이다.

다이나믹 프로시저에 대한 구체적인 실시예는 도 4의 플로우차트에 도시되어 있다. 제어 흐름은 단계 200에서 시작하여, 각각의 웹 사이트 i와 서버 j에 대해 최적의 목표와를 해결하기 위해 고울 프로시저를 사용한다. 단계 205에서, k = 1로 설정한다. 단계 210에서 각각의 웹 사이트 i와 서버 j에 대해와를 0으로 초기화한다. 이들 변수는 목표에 대한 디스패처의 진행을 카운트하게 된다. 단계 215에서 어느 웹 사이트가 큐 내의 요청 k에 대응하는지를 결정한다. 단계 220은 그 요청이 공개적인 것인지 개인적인 것인지를 결정한다. 이들 2가지 가능성 각각에 대한 거의 유사한 흐름이 있게 되며, 여기서는 공개적인 대안에 초점을 맞추기로 한다. 이것은 j = 1로 설정하고 M은 -∞로 설정하는 단계 225에서 시작한다. 다음과 같이 목표와 달성된 값 사이의 차분이 최대인 서버를 찾아내도록 노력한다. 단계 230에서 M이보다 작은지를 검사한다. 작은 경우, 단계 235에서 j* = j로 설정하고, M =로 설정하고, 이어서 단계 240으로 진행한다. 또한, 단계 230에서의 검사가 실패한 경우도 단계 240으로 분기한다. 단계 240에서, j를 증가시킨다. 단계 245에서, j가 N보다 작거나 같은지를 검사한다. 작거나 같은 경우, 단계 230으로 복귀한다. 그렇지 않은 경우, 단계 250에서 위닝 서버 j*를 갖게 되고,를 증가시키며 요청 k를 서버 j*로 디스패치한다. 이어서, 단계 255로 진행하여 k를 증가시킨다. 단계 260에서 k가보다 작거나 같은지를 검사한다. 작거나 같은 경우, 단계 210으로 되돌아가서 그 다음 요청을 디스패치한다. 그렇지 않은 경우, 종료하고 요청의 큐를 비운다. 단계 220에서 요청이 개인적인 요청인 것으로 결정하는 경우, 단계 270 내지 단계 295로 진행한다. 이들 단계는 정확하게 말하면 공개적 요청이 아닌 개인적 요청을 처리한다는 점을 제외하고는 단계 225 내지 단계 250과 유사하다. 궁극적으로 제어 흐름은 다시 단계 220으로 복귀한다.

스태틱 프로시저 컴포넌트

도 7 내지 도 9를 참조하여, 이제부터 사이트를 서버에 할당하는 스태틱 프로시저 컴포넌트에 대해 설명한다. 목표는 고울 프로시저, 따라서 다이나믹 프로시저 컴포넌트의 달성가능한 성능을 최적화하는 것이다. 스태틱 프로시저 컴포넌트로의 주요 입력은 허용가능한 웹 사이트 대 서버 할당에 대한 임의의 제약 조건 뿐만 아니라 각각의 웹 사이트에 대한 공개적 및 개인적 요청의 평균 수요의 예측이 된다. 스태틱 프로시저 컴포넌트의 출력은 단지 2개의 {0,1} 할당 행렬와가 된다.

또한, 웹 사이트 대 서버 할당에 관한 제약 조건은 이미 알고 있는 것으로 가정한다. 이들 제약 조건은 서버 그 자체의 물리적 용량, 타당할 정도로 높은 캐시 히트율(cache hit rate)을 달성하는 목표, 서버 상의 운영 체제, 어떤 사이트들이 협상했을지도 모를 고정 서버 할당 등에 관한 것일 수 있다. 이러한 제약 조건은 아주 복잡하거나 아주 기초적인 것일 수 있다. 예를 들어, 캐시 제약 조건은 아마도 분석적 히트율 모델, 웹 사이트 데이터의 지역성(locality), 및 캐시 크기에 기초할 때 비교적 복잡할 수 있다. 캐시 제약 조건은 비교적 적은 수의 사이트들이 각 서버에 할당되도록 하는 효과를 가지게 된다. 반면에, 운영 체제 제약 조건은 단순히 어느 사이트가 어떤 서버에 비적절한 것인지의 리스트일 수 있다. 요점은 스태틱 프로시저 컴포넌트는 발견적 학습 속성(heuristic in nature)이 있으며, 할당에 있어서의 어떤 변경도 고려하기 전에 제약 조건들을 검사하는 것만으로 그 제약 조건들을 처리할 수 있다.

스태틱 프로시저 컴포넌트는 2가지 가능한 모드를 갖는다. 초기 모드(initial mode)(도 9)는 아무런 사이트도 아직 서버에 할당되지 않은 것인 무(無)에서 새로운 시스템을 구성하는 데 사용된다. 그 다음에, 증가 모드(incremental mode)는 개정된 웹 사이트 수요 예측에 기초하여 기존의 웹 사이트 대 서버 할당을 조정하기 위해 주기적으로 사용된다. 이들 조정의 구현이 실용적이 되도록 하기 위해, 허용된 웹 사이트 대 서버 할당 변경의 허용 횟수를 제한하는 제약 조건을 고려한다. 2가지 모드 둘다 기본적으로 동일한 방법론을 사용함을 알 수 있다. 초기 모드에서 응답 시간 함수에 대해 분석적 모델을 사용해야만 할지로 모르는 반면, 증가 모드에서는 그 대신에 보다 정확한 측정 응답 시간을 사용할 수 있다. 이들은 아마도 캐싱 및 다른 실제 세상의 현상의 효과를 잘 포착할 것이다.

증가 스태틱 프로시저 컴포넌트(incremental the Static procedure component)는 너무 빈번히 실행되어서는 안되는데, 그 이유는 할당 변경을 행함에 있어 명백한 비용이 있기 때문이다. 주당 1회 정도가 아마도 적당할 것이다. 정확한 회수는 갱신된 웹 사이트 예측이 주어진 경우 성능 향상의 가능성와 비교한이 비용의 상대적 트레이드오프에 달려 있다. 아마도 스태틱 프로시저의 실행은 어떤 종류의 부하 불균형 조건(load imbalance condition)의 검출에 의해 트리거될 수 있다.

2가지 모드 둘다에서의 주된 목표는 다음과 같이 정의되는 무방향 그래프 G의 높은 연결성(high connectivity)을 달성하는 것이다. 즉 노드는 서버에 대응하는 것으로 정의된다. 개별적인 노드의 각 쌍 j₁과 j₂에 대해,인 적어도 하나의 웹 사이트 i₁또는 인 적어도 하나의 웹 사이트 i₁이 존재하기만 하면 j₁과 j₂사이에 연결선이 있다. 이들 조건은 방향 그래프 H에 대한 정의에서의 수학식 7 및 수학식 10의 조건과 닮았다. 수학식 8, 수학식 9 및 수학식 11의 조건이 일반적으로 임의의 잘 균형을 이룬 웹 팜에서 만족될 것이기 때문에, 개념은 G가 H에 대한 효과적인 대용으로서 기능한다는 것이다. 또한, 수학식 7 및 수학식 10의 조건이 기본적으로 정적(static)인 반면, 수학식 8, 수학식 9 및 수학식 11의 조건은 본질적으로 동적(dynamic)이라는 것에 유의한다. 즉, 그것이 G가 스태틱 프로시저 컴포넌트에 더 적절한 이유이다.

도 7은 전술한 일례에 대한 그래프 G를 도시한 것이다. 도 6에 도시한 방향 그래프 H와의 유사성에 유의한다. 그렇지만, 도 7에서는 서버 C1과 P3 사이에 연결선이 있지만, 도 6은 어느 방향으로도 대응하는 방향 연결선을 가지고 있지 않다. 서버 P4로부터 P3로의 방향 연결선 등의 도 6에 있는 몇개의 다른 방향 연결선은 반대 방향의 방향 연결선에 의해 짝을 이루지 않는다. 도 7에서 2개의 클러스터 서버 사이의 연결선들이 실선으로 도시되어 있고, 2개의 분할 서버 사이의 연결선은 점선으로 도시되어 있으며, 클러스터 서버와 분할 서버 사이의 연결선은 파선으로 도시되어 있음에 유의한다.

우리가 최적화하려고 하는 목적 함수는 본 발명에서 블랙 박스로 취급하고 있는 고울 프로시저 컴포넌트 자체의 목적 함수이다. 여기에서의 이론적 근거는 평균 응답 시간인 것이 효과적인 이 척도는 나머지 2개의 그래프 이론적인 대용 중 어느 하나보다 명확하게 더 직접적으로 적절하고 그다지 계산 비용이 더 많이 드는 것은 아니라는 것이다.

사용되는 메타 표기법에서는 틸드(~)가 스태틱 프로시저 문제 공식을 말한다.

다음과 같이 사이트의 서버로의 (어떤 의미에서 양호한) 할당의 공간을 기술하는 새로운 행렬를 착상하는 것으로 시작한다. 즉,는 다시 MxN 크기의 {0,1} 행렬이 된다. 각각의 웹 사이트에 대해 공개적 및 개인적 트래픽 둘다가 존재하는 일반적인 조건 하에서, 이하의 수학식 22 및 수학식 23의 방식으로에서와으로의 변환을 행한다.

이것은 행 합산인 임의의 서버 j가 하나의 웹 사이트에 대한 공개적 및 개인적 트래픽 둘다를 갖는 분할 서버이고 다른 모든 서버가 다수의 공개적 웹 사이트 트래픽을 갖는 서버라는 묵시적인 가정을 하고 있다. 할당 행렬 A 및 B의 모든 가능한 쌍이 어떤 행렬으로부터 전이되는 것으로 간주될 수 있는 것은 아니라는 것에 유의한다. 그렇지만, 그렇게 간주될 수 없는 것들은 덜 바람직한 것이다. 스태틱 프로시저 컴포넌트는 그들을 선택하지 않는다.

특수한 경우를 다루기 위해 사소한 조정을 해야만 한다. 웹 사이트 i에 대해 개인적 트래픽만이 존재하는 경우,일 때는 항상에 대해일 것이 요구된다. 이것은 j를 웹 사이트 i에 대한 분할 서버로 만든다.및으로 설정한다. 웹 사이트 i에 대해 공개적 트래픽만이 존재하는 경우, 그 웹 사이트에 할당된 임의의 서버 j는이라고 할지라도 공식적으로 공개적인 것으로 간주될 수 있다. 따라서,와로 설정한다.

또한, 각각의 서버 j 상의 부하가 그의 부하 한계 L_j를 초과하는 경우들을 처리하기 위해 그 서버에 대한 응답 시간 함수 R_j를 수정할 필요가 있다. 적어도 우리의 스태틱 프로시저 컴포넌트 절차들의 초기 단계들에서 이러한 실현 불가능성이 일어나는 것도 무리가 아니며, 대량의 목적 함수 비용으로 실현 가능성을 강요함으로써 이들을 처리할 필요가 있다. 따라서, 아주 큰 수 Q를 생각하고에 대해인 것으로 하지만,,, 이하 마찬가지이다. 일반적인 재귀는 k > 0에 대해 수학식 24를 정의한다.

가 볼록이고 증가하는 것임에 유의한다. 또한 최대 허용가능 부하를인 것으로 재정의한다.

와를 각각 웹 사이트 i에 대해 예측된 공개적 및 개인적 부하를 말하는 것으로 하자. 여기서의 설명은 각 웹 사이트에 대해 공개적 및 개인적 트래픽 둘다가 존재하는 경우에 기초하고 있지만, 이것이 그 경우가 아닌 때에는 신속히 적절한 수정을 결정할 수 있다.

일반성의 상실없이 사이트들이 예측된 총 부하가 증가하는 관점에서 재인덱싱되어 있는 것으로 가정하자. 또한 서버들이 성능이 증가하는 관점에서 재인덱싱되어 있는 것으로 가정하자. 이것은 예를 들어 그들의 원래의 최대 허용가능 부하 L_j에 의해 결정될 수 있다.

초기 할당 방법의 제1 단계는 가능한 범위까지 사이트들을 서버들에 순차적으로 매칭시키는 것이다. 어떤 사이트들을 어떤 서버로부터 제한하는 실현 가능성 제약 조건이 있을 수 있으며, 이들 제약 조건을 존중되어야만 한다. 따라서, 도 9의 단계 305 내지 단계 355에 도시한 바와 같이 웹 사이트 i = 1로부터 M까지 루프를 돌면서, 단계 325에서(단, j는 실현가능하지만 현재 할당되지 않은 서버의 최저 인덱스임)로 설정하고, 초기화에서 다른 모든 j에 대해= 0으로 설정한다. 모든 사이트들에 대해 가능한 실현가능 할당들이 없을 것임이 가능하지만 아마도 그럴 가능성은 거의 없다. 이것은 제약 조건들로 인해 일어날 수 있으며, 또 그것은 M>N이기 때문에 일어날지도 모른다. 이 경우, 초기 할당 기술은 실패한다. 그렇지 않은 경우, 이 시점에서 M개의 분할 서버가 있으며, 나머지 N-M개의 서버는 아이들 상태(idle)이다.

이러한 초기 해(initial solution)를 얻기 위해 수학식 25와 같은 것인 목적 함수를 계산한다.

이제 초기 해는 소위 이웃 도피 발견적 학습법의 구현에 의해 수정되어진다. 이 발견적 학습법은 사이트의 서버로의 2개의 가능한 할당 사이의 거리를 측정하기 위해 메트릭 Δ를 이용하며, 이에 대해서는 곧 설명할 것이다. 이웃 도피 발견적 학습법인 Briey는 비교적 낮은 계산 비용을 달성하면서 로컬 최소값들(localminima)에 트랩되는 것을 회피하려고 시도하는 반복적 개선 프로시저이다. 상기한 것과 같은 기존의 초기 가능해에 덧붙여 가능해의 검색 공간에 대한 그 순간의 미리 정의된 메트릭 Δ을 가정하면, 이 기술은 단계들을 이루어 진행한다. 각각의 단계의 시작에서, 그 단계 동안 수정될 수 있는 소위 현재 해(current solution)가 있다. 첫번째 단계의 시작에서, 현재 해는 초기 해이다. 각각의 단계는 계속하여 현재 해에 관한 거리 1, 2 및 기타 등등의 이웃들을 검색한다. (현재 해에 관한 거리 k의 이웃은 현재 해로부터의 거리가 k보다 작거나 같은 모든 실현가능 할당의 세트이다. 현재 해를 중심으로 거리 k의 링(ring)은 현재 해로부터의 거리가 k와 같은 모든 실현가능 할당의 세트이며, 이는 거리 k의 이웃 - 거리 k-1의 이웃이다.) 목적 함수 개선이 현재 해에 관한 거리 1의 이웃에서 발견될 수 있는 경우, 발견적 학습법은 최상의 이러한 개선을 선택하고, 그것에 현재 해로서 재라벨링하며, 그 다음 단계를 시작함으로써 그 프로세스를 반복한다. 거리 1의 이웃 내에서 어떤 개선도 발견되지 않은 경우, 발견적 학습법은 그 대신에 거리 2의 링을 고려한다. 다시 말하면, 2가지 가능성이 있다. 즉, 여기에서 개선이 있는 경우, 최상의 이러한 개선이 현재 해로서 선택되고, 그 프로시저는 그 다음 단계를를 시작한다. 그렇지 않은 경우, 프로시저는 거리 3의 링을 고려하고 이하 마찬가지로 하여 고정 거리 한계, 말하자면 K까지 계속한다. K번째 링 내에서 목적 함수 개선에 도달하지 않은 경우, 프로세스는 현재 해와 같은 최종 해로 종료한다. 여러가지 링의 검사는 도 9의 단계 360, 단계 380, 및 단계 385에서 행해진다. 개선은 단계 370에서 검사된다.

도 8은 이 프로세스를 나타낸 것이다. 초기 단계의 시작에서의 현재 해는 제1 이웃 세트의 중심(400), 즉 거리 1(distance 1)에 있다. 발견적 학습법은 개선이 발견될 때까지 제1 이웃 및 그 다음 링을 순차적으로 검색한다. 동 도면에서, 개선이 일어나는 것은 K번째 링, 거리 K에서 뿐이다. 그 다음에, 발견적 학습법은 새로운 중심(410)으로 나타낸 바와 같이 현재 해를 그 검색에서 발견된 최상의 개선으로 재설정하고, 제2 단계를 시작한다. 동 도면은 그 해에 관한 이웃들을 나타낸 것이다. 이제 개선은 제3 링에서 발견된다. 이제, 제3 스테이지가 시작되지만, 도면에는 이를 도시하지 않았다. K번째 링이 제1 단계에서 개선을 보이지 않은 경우, 초기 해는 최종 해가 된다.

이제 거리 메트릭 Δ을 정의한다.와가 2개의 이러한 할당인 것으로 하고, 이하의 수학식 26을 정의한다.

여기서의 의도는 단순하다. 즉, 예를 들어, 하나의 웹 사이트를 서버들 중 하나에 추가하거나 그로부터 제거함으로써 할당을 새로운 할당으로 수정하는 경우,가 얻어진다. 웹 사이트의 이전의 서버로부터 (이전에 할당된 그 웹 사이트를 갖지 않았던) 새로운 서버로의 이동은 도 8에서 거리 2를 갖는다. 웹 사이트를 서버로부터 제거하고 동시에 다른 웹 사이트를 그 서버에 추가하는 것도 거리 2를 갖는다. 서로 다른 서버 상의 서로 다른 웹 사이트의 스왑(swap)은 거리 4를 가지며, 이하 마찬가지이다.

주어진 해및 그의 전이된 할당 행렬와의 경우, 개선에 대한 검사는 수학식 28 내지 수학식 31의 제약 조건에 따라 수학식 27을 최소화하는 고울 프로시저 컴포넌트 문제를 해결하는 것을 포함한다.

인 경우

물론,를 포함하는 제약 조건은 무의미하다. 그렇지만, 한계 L_j를초과하는 부하의 비용이 주어지면, 이웃 도피 발견적 학습법에서의 아주 적은 단계들 후에 각 서버 j에 대해 그 해가 수학식 32를 만족하는 것을 예상한다.

따라서, 모든 관점으로부터 볼 때 실현가능한 할당들이 신속히 달성될 수 있어야만 한다. 실제로는, 프로시저의 처음 몇개의 단계들이 일반적으로 하이 볼륨 사이트들을 현재 미사용인 서버들에 할당하게 되고, 이어서 본 기술은 분할 서버를 클러스터 서버로 변환하기 시작하며 일반적으로 더 높은 성능의 서버의 상태를 먼저 변경한다.

증가 프로시저는 예측 변동 등이 있을 경우 양호한 웹 사이트 대 서버 할당을 유지하기 위해 주기적으로, 아마도 주당 1회 실행되어진다. 다행스럽게도, 증가 프로시저는 거의 동일한 방법론을 사용한다.

물론 초기 해는 마지막 스태틱 프로시저 컴포넌트 실행으로부터의 현재 해이고, 그 초기 해는 본 발명의 이웃 도피 기술을 통해 수정된다. 유일한 비결은 본 발명에서 초기 해와 현재 해 사이의 거리가 어떤 사용자 정의된 임계값 T를 초과하는 경우에 중단하는 것인 부가의 중단 기준을 사용한다는 것이다. 이렇게 하는 이유는 할당 변경이 구현하기에 실제로 비용이 많이 들고 또 스태틱 프로시저 컴포넌트 실행의 연속한 인스턴스 사이에 무턱대로 서로 다른 해를 허용하고 싶지 않기 때문이다.

도 9를 참조하면, 스태틱 프로시저의 상세한 실시예가 도시되어 있다. 단계 300에서 시작하여, 웹 사이트 i를 1로 초기화한다. 단계 305에서, 서버 j를 1로 초기화한다. 단계 310에서, 서버 j가 웹 사이트 i에 대해 실현가능한지를 결정한다. 실현가능한 경우, 단계 320으로 진행하여 서버 j가 현재 미할당되어 있는지를 결정한다. 그 서버가 현재 미할당되어 있는 경우, 단계 325에서 그 서버를 할당하고, 단계 330에서 웹 사이트 i를 증가시킨다. 단계 335에서 i가 사이트의 총 개수 M보다 작거나 같은지를 결정한다. 작거나 같은 경우, 단계 305로 복귀한다. 단계 310 또는 단계 320에서의 검사가 실패하였으면, 단계 340으로 진행하여 서버 j를 증가시킨다. 단계 345에서, j가 서버의 총 개수 N보다 작거나 같은지를 결정한다. 작거나 같은 경우, 단계 310으로 복귀한다. 그렇지 않은 경우, 단계 350에서 비실현가능한 해로 종료한다. 이제 단계 335에서 사이트들이 소진된 경우로 복귀하여, 단계 355로 진행하여 프로시저의 이웃 도피 컴포넌트(neighborhood escape component)를 시작한다. 수학식 25에 의해 주어진 해의 값 R을 구한다. 단계 360에서, k = 1로 설정한다. 단계 365에서, 가능한 최상의 해 R_k를 구하기 위해 k번째 링을 검색한다. 단계 370에서, 최상의 현재 해 R에 비교되는 R_k를 구한다. 새로운 값이 더 좋은 경우, 단계 375에서 이것을 최상의 해로 삼으며, 단계 360으로 복귀한다. 새로운 해가 더 좋은 것이 아닌 경우, 단계 380에서 k를 증가시킨다. 단계 385에서 모든 링 k가 소진되었는지를 결정한다. 소진되지 않은 경우, 단계 365로 복귀한다. 그렇지 않은 경우, 단계 390에서 최종 할당 해로 종료한다.

본원 발명은 웹 팜 및 웹 팜에서 부하를 분산하기 위한 방법에 적용된다.

Claims

복수의 웹 사이트 및 서버를 갖는 웹 팜을 제어하는 방법으로서,

상기 웹 사이트들에 의해 수신된 고객 요청들을 복수의 부류로 분류하는 단계로서 상기 부류는 공유가능 고객 요청과 비공유가능 고객 요청을 포함하는 것인 분류 단계,

상기 서버들 중 어느 것이라도 상기 웹 사이트들 중의 서로 다른 웹 사이트들로부터 수신된 공유가능 고객 요청들을 처리할 수 있도록 상기 공유가능 고객 요청들을 라우팅하는 단계, 및

상기 웹 사이트들 중의 특정의 웹 사이트들로부터의 상기 비공유가능 고객 요청들을 상기 특정의 웹 사이트들이 할당되어 있는 특정의 서버들로만 라우팅하는 단계를 포함하는 웹 팜 제어 방법.
제1항에 있어서, 고울 프로시저를 더 포함하며,

상기 고울 프로시저는, 상기 웹 사이트들의 상기 서버들로의 상기 할당과 현재의 고객 요청 부하가 주어진 경우, 상기 고객 요청 각각에 대해 임의의 주어진 순간에 평균 고객 응답 시간을 최소화하기 위해 상기 각각의 고객 요청이 할당될 상기 서버들 중에서 최적의 서버를 결정하는 단계를 포함하는 것인 웹 팜 제어 방법.
제2항에 있어서, 상기 고울 프로시저는,

이하의 식 (1) 내지 식 (5),

(1)

(2)

인 경우(3)

(4)

인 경우(5)

의 제약 조건에 따라 이하의 식 (6),

(6)

의 함수를 최소화시킴으로써 실시되며,

여기서, M은 웹 사이트의 개수이고, N은 서버의 개수이며, R_j는 서버 j에서의 고객 도달율의 함수인 예상 응답 시간이고, x_i,j는 서버 j에 의해 처리될 수 있는 웹 사이트 i에 대한 공유가능 요청들의 가상적 개수를 나타내는 결정 변수이며, y_i,j는 서버 j에 의해 처리될 수 있는 웹 사이트 i에 대한 비공유가능 요청들의 가상적 개수를 나타내는 결정 변수이고, L_j는 서버 j에 대한 최대 허용가능 부하이며,c_i는 웹 사이트 i로부터의 공유가능 고객 요청들의 현재의 개수이고, d_i는 웹 사이트 i로부터의 비공유가능 요청들의 현재의 개수이며, a_i,j는 웹 사이트 i로부터의 공유가능 요청들이 서버 j로 라우팅될 수 있는지를 나타내는 인덱스이고, b_i,j는 웹 사이트 i로부터의 비공유가능 요청들이 서버 j로 라우팅될 수 있는지를 나타내는 인덱스인 것인 웹 팜 제어 방법.
제3항에 있어서, 방향 그래프를 생성 및 유지하는 단계로서, 상기 방향 그래프는 더미 노드와 복수의 서버 노드를 포함하고, 상기 각각의 서버 노드는 상기 서버들 중 하나에 대응하는 것인 방향 그래프 생성 및 유지 단계,

이하의 식 (7),

(7)

이 최소가 되는 상기 서버 노드들 중 하나를 위닝 노드로서 지명하는 단계, 및

상기 더미 노드로부터 상기 위닝 노드로의 최단 방향 경로를 선택하는 단계를 더 포함하는 웹 팜 제어 방법.
제1항 내지 제4항 중 어느 한 항에 있어서, 스태틱 프로시저를 더 포함하고,

상기 스태틱 프로시저는 비공유가능 고객 요청들을 처리하기 위해 상기 웹사이트들 중 특정의 웹 사이트들을 특정의 상기 서버들에 할당하는 단계를 포함하는 것인 웹 팜 제어 방법.
제5항에 있어서, 상기 스태틱 프로시저는 각각의 상기 웹 사이트로부터의 공유가능 및 비공유가능 고객 요청들의 예측 수요(forecasted demand)에 기초하여 상기 웹 사이트들을 특정의 서버들에 할당하는 것인 웹 팜 제어 방법.
제2항 내지 제4항 중 어느 한 항에 있어서, 다이나믹 프로시저를 더 포함하며,

상기 다이나믹 프로시저는,

그 다음 고객 요청을 검사하는 단계,

어느 서버가 상기 그 다음 고객 요청을 현재 처리하기 위한 최적 서버인지를 결정하기 위해 상기 고울 프로시저를 호출하는 단계, 및

상기 그 다음 고객 요청을 상기 최적 서버로 디스패치하는 단계를 포함하는 것인 웹 팜 제어 방법.
제7항에 있어서, 상기 고객 요청들을 큐 안으로 수신하는 단계를 더 포함하며,

상기 다이나믹 프로시저는,

상기 큐 내의 상기 고객 요청들을 모니터링하는 단계,

상기 서버들에 의해 현재 처리되고 있는 고객 요청들을 모니터링하는 단계,

이하의 식 (8),

(8)

을 설정함으로써 각각의 j번째 서버에 대해 함수를 정의하는 단계,

이하의 식 (9),

(9)

을 설정함으로써 각각의 j번째 서버에 대해 개정된 허용가능 부하 한계를 정의하는 단계, 및

상기함수 및 개정된 허용가능 부하 한계를 이용하여

이하의 식 (10) 내지 식 (14),

(10)

(11)

인 경우(12)

(13)

인 경우(14)

의 제약 조건에 따라 이하의 식 (15),

(15)

의 함수를 최소화하기 위해 상기 고울 프로시저를 호출하는 단계를 더 포함하며,

여기서,는 서버 j에 의해 처리될 수 있는 웹 사이트 i에 대한 큐 내의 공유가능 요청들의 가상적 개수를 나타내는 결정 변수이고,는 서버 j에 의해 처리될 수 있는 웹 사이트 i에 대한 비공유가능 요청들의 가상적 개수를 나타내는 결정 변수이며,는 웹 사이트 i로부터의 큐 내의 공유가능 고객 요청들의 현재의 개수이고,는 웹 사이트 i로부터의 큐 내의 비공유가능 요청들의 현재의 개수이며,는 서버들 중 하나에서 현재 처리되고 있는 웹 사이트 i로부터의 공유가능 고객 요청들의 현재의 개수이고,는 서버들 중 하나에서 현재 처리되고 있는 웹 사이트 i로부터의 비공유가능 요청들의 현재의 개수인 것인 웹 팜 제어 방법.
제1항 내지 제8항 중 어느 한 항에 기재된 방법을 수행하기 위해 컴퓨터에 의해 실행가능한 명령어들을 포함하는 컴퓨터 프로그램.
복수의 웹 사이트 및 서버를 갖는 웹 팜으로서,

고객들로부터 고객 요청들을 수신하는 수단,

상기 고객 요청들을 처리하여 응답들을 생성하는 수단,

상기 응답들을 상기 고객들에게 전송하는 수단,

상기 고객 요청들을 공유가능 고객 요청들과 비공유가능 고객 요청들로 분류하는 수단,

상기 서버들 중 어느 것이라도 상기 웹 사이트들 중 서로 다른 웹 사이트들로부터 수신된 공유가능 고객 요청들을 처리할 수 있도록 상기 공유가능 고객 요청들을 라우팅하는 수단, 및

상기 웹 사이트들 중 특정의 웹 사이트들로부터의 상기 비공유가능 고객 요청들을 상기 특정의 웹 사이트들이 할당되어 있는 특정의 서버들로만 라우팅하는 수단을 포함하는 웹 팜.
제10항에 있어서, 네트워크 디스패처를 더 포함하며,

상기 네트워크 디스패처는 고울 프로시저, 스태틱 프로시저, 및 다이나믹 프로시저를 실행하는 수단을 포함하고,

상기 고울 프로시저는, 상기 웹 사이트들의 상기 서버들로의 상기 할당과 현재의 고객 요청 부하가 주어진 경우, 상기 고객 요청 각각에 대해 임의의 주어진 순간에 평균 고객 응답 시간을 최소화하기 위해 상기 각각의 고객 요청이 할당될 상기 서버들 중에서 최적의 서버를 결정하는 단계를 포함하며,

상기 공유가능 고객 요청들은 임의의 상기 서버로 할당될 수 있고,

상기 비공유가능 고객 요청들은 상기 비공유가능 고객 요청들이 어느 웹 사이트에서 발신되었는지에 따라 특정의 서버들에 할당될 수 있을 뿐이며,

상기 스태틱 프로시저는 특정의 상기 웹 사이트들을 특정의 상기 서버들에 할당하는 단계를 포함하고,

상기 다이나믹 프로시저는,

그 다음 고객 요청을 검사하는 단계,

어느 서버가 상기 그 다음 고객 요청을 현재 처리하기 위한 최적 서버인지를 결정하기 위해 상기 고울 프로시저를 호출하는 단계, 및

상기 그 다음 고객 요청을 상기 최적 서버로 디스패치하는 단계를 포함하는 것인 웹 팜.