KR100255498B1

KR100255498B1 - 동적 페이지 링크 리타겟팅 방법

Info

Publication number: KR100255498B1
Application number: KR1019970057346A
Authority: KR
Inventors: 메이휴데이비드이반
Original assignee: 포만 제프리 엘; 인터내셔널 비지네스 머신즈 코포레이션
Priority date: 1997-02-19
Filing date: 1997-10-31
Publication date: 2000-05-01
Also published as: JPH10240701A; KR19980070068A; JP3014358B2; TW445417B; US5933606A

Abstract

본 발명은, 프로세스 또는 코드에 대한 변경만이 웹 서버상에 내재하고, 자원의 이용가능성을 축소시키지 않도록 하면서, 컴퓨터 네트워크, 바람직하게는 웹 페이지 및 웹 서버를 이용하는 인터넷 환경에서 복수의 복제된 서버 사이에서 작업부하를 분산시키는 방법에 관한 것이다.

Description

동적 페이지 링크 리타겟팅 방법

월드 와이드 웹(World Wide Web)은 비지니스를 수행하고, 정보를 검색하기 위한 선택의 방법이 되고 있으며, 또한 다른 사람과 교제하는 생존력 있는 수단이 되고 있다. 월드 와이드 웹의 대중성으로 인해 웹을 지원하고 유지하는 시스템에서 예기치 않은 수요가 발생하고, 따라서, 웹의 성능이 여러번에 걸쳐 영향을 받는다. 더욱 더 많은 사람들이 동일한 웹 사이트에 억세스하고 동일한 링크를 통과하기 위해 시도함에 따라, 링크 및 웹 사이트는 적체되게 된다. 이러한 적체(congestion)는 사용자에 대한 응답시간의 증가를 유발한다. 이러한 응답시간의 증가는 사용자에 대한 비용도 증가시키고 사용자를 좌절하게 한다. 웹 사이트가 너무 적체되게 되면, 사용자는 보다 양호한 성능을 가진 대안의 웹 사이트를 찾기 시작하게 된다. 이것은 어떤 경우에, 그 사이트에 억세스하는 사용자의 수에 근거하여 수익을 받는 웹 사이트의 소유자에게는 극히 바람직스럽지 못하다.

웹 사이트의 창작자(creators)는 웹 사이트의 복수의 사례(instances)를 작성하고, 사용자로 하여금 이들 복수의 사례에 연결하도록 하므로써 이러한 문제를 해결하기 위해 시도해왔다. 이것은 양호한 해결방안처럼 들리지만, 문제가 없는 것이 아니다. 웹 사이트는 그 명칭에 의해 억세스되어야 하기 때문에, 사이트의 사용자는 상이한 사용자에게 상이한 명칭을 분산(distribute)시켜야 하고, 사용자로 하여금 동일한 정보의 상이한 사례를 억세스하도록 해야한다. 이것은 도1에 도시되어 있다. 상이한 명칭을 관리하는 것은, 사이트의 소유자가 주어진 시간에 누가 그 사이트를 억세스할 가능성이 있는지 판단해야 하고, 그것을 복수의 정보 사례에 걸쳐 공평하게 분산시켜야 하기 때문에 매우 복잡해진다. 사이트 소유자는 정보를 지원하는 복수의 서버 각각에 대한 부하가 비교적 공평하게 유지되도록 명칭을 분산시키거나, 오직 하나의 서버만이 존재했던 경우와 동일한 문제와 마주치게 될 위험성을 분산시켜야 한다. 또한, 상이한 웹 사이트의 명칭을 상이한 사용자에게 분산시키는 방법은, 대안의 사이트 중 하나가 다운되는 경우에 몇몇 사용자가 정보를 억세스할 수 없게 되는 결과를 초래하게 된다. 사용자는 위치를 찾을 수 있는 하나의 명칭만을 알기 때문에, 이들 사용자는 그 서버가 다운된 서버인 경우에, 비록 동일한 정보를 억세스할 수 있는 다른 서버가 활성 상태를 유지한다 할지라도 억세스를 실패하게 된다. 만일 사용자가 그 정보에 대한 복수의 위치를 발견하는 경우에는 추가적인 혼란이 초래된다. 사용자는 어떤 정보가 "최근(current)"의 것인지에 관해 혼동될 수도 있다.

다른 사람들은 웹 스프레이어(sprayers)를 이용하여 웹 사이트 부하 균형유지(load balancing) 문제를 해결하기 위해 시도 하였다. 웹 스프레이어는 복수의 다른 서버에 접속된 중간 서버이다. 스프레이어가 접속된 복수의 서버 각각은 복사된 동일한 정보를 포함한다. 복수의 서버상의 정보를 억세스하기 위해 시도하는 사람은 모두 스프레이어를 통해 정보를 억세스해야 한다. 스프레이어는 정보에 대한 요구를 수신하고, 복수의 서버중 어느 서버가 다음 요구를 전송할 것인지 판단하고, 그 요구를 적절한 제2의 서버로 전송한다. 이것은 또한, 복수의 데이터 서버 사이에서 작업을 분산시키기 위한 단순한 라운드-로빈(round-robin) 서빙 방법으로서 구현될 수 있다. 이러한 방법은, 비록 일반적으로는 성능을 개선하기 위해 유용하지만, 상당한 결점을 갖고 있는데, 그 이유는 스프레이어가 다운되거나 오동작하는 경우에, 그 정보에 대한 억세스가 실패하기 때문이다. 다른 제2의 서버는 스프레이어 없이는 억세스될 수 없다. 또한, 현재의 스프레이어의 구현에는 제2의 서버가 얼마나 비지(busy)한 상태에 있는지 판단하기 위한 수단이 없다. 불과 수초가 걸리는 단일의 서버 요구를 하는 사람이 한 시간이 걸리는 요구를 하는 사람과 동일하게 간주된다. 이것은 비록 단일 서버를 구비한 경우 보다는 확실히 뚜렷한 성능 개선이지만, 제2의 서버의 작업부하의 약간의 불균형을 유발할 수 있다.

본 발명의 목적은 추가적인 하드웨어를 필요로 하지 않고 대중적인 웹 사이트를 억세스하는 동안 지연을 감소시키는 수단을 제공하는 것이다.

본 발명의 다른 목적은, 웹 사이트의 높은 이용가능성을 제공하는 것과 관련된 비용 - 여기서, 비용은 하드웨어 비용, 관리 비용, 구성(configuration) 비용, 및 유지보수 비용을 포함함 - 을 최소화하는 것이다.

본 발명의 제3의 목적은, 동일한 해결방안이 모든 크기의 웹 사이트에 사용될 수 있도록 매우 확장가능한 해결방안을 제공하는 것이다.

본 발명의 또 다른 목적은 추가적인 하드웨어나 웹 브라우저에 대한 변경을 필요로 하지 않고 전술한 장점을 제공하는 것이다.

상기 및 다른 목적은 본 발명에 의해 충족된다.

본 발명은 동일한 정보를 포함하는 복수의 서버에 걸쳐 부하 균형유지를 용이하게 하기 위해 웹 페이지내에 포함된 하이퍼텍스트 전송 프로토콜(http) 링크의 이용을 수반한다. 동적 페이지 링크 리타겟팅(dynamic page link retargeting) (DPLR) 으로 불리는 본 발명은 부하 균형유지를 위한 특수 목적 전위(front end) 프로세서에 의존하는 것이 아니라 부하 균형유지를 위해 웹 페이지내의 링크를 이용한다. DPLR은 기존의 하드웨어의 특수한 편성 또는 특수 하드웨어의 필요성을 없애고, 일련의 웹 서버가 독립적으로 동작할 수 있도록 한다. 이것은 개별적인 웹 서버의 고장을 떠나 보다 높은 이용가능성을 제공한다. 또한, 이 해결방안은 문제에 대한 다른 공지된 해결방안 보다 저렴한 비용이 든다. DPLR은 특수한 구성을 필요로 하지 않으며, 웹 서버를 통한 부하 균형유지에 대한 웹 스프레이어 해결방안 보다 더욱 용이하게 확장가능(scalable)하다.

도1은 웹 환경에서 작용하는 스프레이어를 도시한 도면.

도2는 명칭에 의해 각각 억세스되는 복수의 대리 웹 서버를 도시한 도면.

도3은 지명된 웹 서버 및 3개의 대리 서버를 이용하는 본 발명을 도시한 도면.

도4는 본 발명의 흐름도.

도5a는 리타겟팅의 라운드 로빈 방법의 흐름도.

도5b는 서버 리타겟팅의 최소 비지상태 방법의 흐름도.

도6a는 본 발명을 구현하기 이전의 웹 페이지의 그래프도.

도6b는 본 발명을 구현한 이후의 웹 페이지의 그래프도.

도6c는 본 발명의 서버 대용이 이루어진 후의 웹 페이지의 그래프도.

*도면의 주요 부분에 대한 부호의 설명

101,103,105,107:데이터 서버

109:웹 스프레이어

113,115,117,119:통신 링크

적시에 수신되는 다수의 요구를 충족시키는데 있어서의 웹 서버의 무능력 문제에 대한 가장 최근의 해결방안중 하나는 웹 스프레이어 이다. 도1은 웹 스프레이어를 도시하고 있다. 웹 스프레이어 환경에서, 사용자는 웹 스프레이어(109)를 어드레스하므로써 원하는 정보를 억세스한다. 본 실시예에서, 사용자는 http:\\w3.externaladdr.com\xxxxx.xxxxx 를 참조(reference) 하므로써 정보를 어드레스하게 되는데, 여기서, 'xxxxx.xxxxx' 는 요구가 이루어진 특정 정보이다. 일단 웹 스프레이어(109)가 정보를 수신하면, 이 스프레이어는 부착된 데이터 서버중 한 서버로 정보에 대한 요구를 전송한다. 수신된 제1 요구는 요구된 어드레스를 http:\\w3.locationone.com\xxxx.xxxx 로 변환하므로써 제1 링크(113)를 통해 제1 데이터 서버(101)로 전송되고, 정보에 대한 제2 요구는 요구된 어드레스를 http:\\w3.locationtwo.com\xxxx.xxxx 로 변환하므로써 제2 링크(115)를 통해 제2 데이터 서버(103)로 전송되고, 정보에 대한 제3 요구는 요구된 어드레스를 http:\\w3.locationthree.com\xxxx.xxxx 로 변환하므로써 제3 링크(117)를 통해 제3 데이터 서버(105)로 전송되고, 정보에 대한 제4 요구는 요구된 어드레스를 http:\\w3.locationfour.com\xxxx.xxxx 로 변환하므로써 제4 링크(119)를 통해 제4 데이터 서버(107)로 전송된다. 데이터에 대한 다른 요구가 수신되면, 프로세스는 라운드 로빈 방식으로 제1 데이터 서버와 함께 다시 시작된다. 이러한 방법은 사용자가 복수의 대리(alternate) 데이터 위치를 알 필요 없이 사용자에 의해 인지되는 보다 양호한 응답 시간을 갖고 보다 많은 요구가 처리될 수 있도록 하지만, 뚜렷한 결점도 갖고 있다. 첫째로, 몇몇 스프레이어는 사용자에게 요구를 충족시키는 어떠한 부하도 처리하지 않게 되는 특수한 하드웨어를 필요로 하고, 다른 스프레이어는 웹 페이지를 처리하게 되지만 그 서버의 성능에 영향을 줄 가능성을 갖고 있다. 이들 두가지 형태의 스프레이어는 모두 스프레이어를 적절하게 구성하기 위한 특수한 지식과 스프레이어 기능을 구현하기 위한 특수한 소프트웨어를 필요로 한다. 두 번째로, 만일 사용자가 할당된 데이터 서버가 고장나거나, 데이터 서버와 스프레이어 사이의 링크가 고장나는 경우에, 스프레이어로 요구를 재발생하는 것 이외에는 사용자가 계속 진행할 아무런 방법이 없다. 또한, 라운드 로빈 방식의 요구 분산 방법은 사용자가 데이터 서버에 억세스하게 되는 시간의 길이를 고려하지 않으며, 따라서, 부하의 분산에서 불균형을 초래할 수 있다. 마지막으로, 웹 스프레이어가 다운되는 경우에, 이러한 해결방안에 의해서는 어떠한 서버도 억세스될 수 없다.

도2는 웹 서버로 향하는 정보에 대한 요구의 볼륨을 충족시키는 문제에 대한 덜 바람직한 다른 대안을 도시하고 있다. 도2에는 복제된 정보를 포함하는 4개의 대리 서버를 가진 통신 링크(210)가 도시되어 있다. 사용자가 원하는 정보에 대한 루트를 요구할 때, 이들 사용자에게 상이한 어드레스가 알려진다. 정보에 대한 억세스를 요구하는 사용자중 일부는 어드레스 http:\\w3.extern1.com\xxx.xxx 의 제1 데이터 서버(201)에 그 정보가 있는 것으로 알게되고, 정보에 대한 억세스를 요구하는 사용자중 일부는 어드레스 http:\\w3.extern2.com\xxx.xxx 의 제2 데이터 서버(203)에 그 정보가 있는 것으로 알게되고, 정보에 대한 억세스를 요구하는 사용자중 일부는 어드레스 http:\\w3.extern3.com\xxx.xxx 의 제3 데이터 서버(205)에 그 정보가 있는 것으로 알게되고, 정보에 대한 억세스를 요구하는 사용자중 잔여 사용자는 어드레스 http:\\w3.extern4.com\xxx.xxx 의 제4 데이터 서버(207)에 그 정보가 있는 것으로 알게 된다. 이와 같은 접근방법은 구현이 비교적 간단하고 하드웨어 변경이나 구성을 필요로하지 않지만, 상당한 결점도 갖고 있다. 이러한 해결방안은 부하 균형유지를 제공하지 않는다. 이것은 원하는 데이터가 균일한 방식으로 배치되는 위치에 관해서는 정보를 분산시킬 수도 있지만, 데이터에 대한 실제적인 억세스 또는 억세스 시도를 분산시키기 위해 하는 것은 아무것도 없다. 또한, 하나 또는 그 이상의 데이터 서버가 고장나는 경우에, 한 데이터 서버가 다른 데이터 서버를 백업(back-up)하도록 허용되지 않는다. 예를 들어, 만일 사용자는 그들이 원하는 정보가 http:\\w3.extern2.com\xxx.xxx에 존재하는 것으로 알고 있고, 데이터 서버 w3.extern2.com가 고장난 경우에, 사용자는 그 정보를 다른 장소에서 찾을 수 있다는 것을 알지 못하게 되며, 이러한 해결방안은 자동적인 재루팅 메카니즘을 제공하지 않는다. 또한, 한 사용자는 정보가 http:\\w3.extern1.com\xxx.xxx 으로부터 오는 것으로 알고 있고, 다른 사용자는 정보가 http:\\w3.extern4.com\xxx.xxx 로부터 오는 것으로 알고 있는 경우에, 정보를 공유하길 시도하는 사용자는 극히 혼동될 수 있다. 가장 최신의 정보가 위치하는 장소에 관한 관심 등이 존재할 수 있다.

도3은 웹상의 정보가 동일한 웹 서버 및 상이한 웹 서버내에 포함된 다른 정보에 대한 다수의 포인터(또는 링크)를 포함할 수도 있다는 사실을 이용하는 본 발명의 네트워크를 도시하고 있다. 본 발명은 동일한 웹 서버내의 정보에 대한 억세스에 관한 것이다. 도면으로부터 명백한 바와 같이, 본 발명은 특수한 하드웨어나 또는 추가적인 하드웨어를 필요로하지 않는다. 사용자는 통신 링크(310)을 통해 http:\\w3.extern1.com\xxx.xxx (301)에 억세스하므로써 원하는 정보를 억세스한다. 이것은 정보에 대한 단일 인터페이스를 허용한다. 정보 억세스가 충족되면, 데이터 서버는 그것이 '비지상태(busy)' 인지 알기 위해 검사한다. 비지상태는 시스템 운영자에 의해 그 시스템에 대한 적절한 이용 레벨이 되도록 정의될 수 있다. 만일 원래의 데이터 서버가 비지상태 이면, 사용자에게 전송된 정보내의 소정의 페이지 레퍼런스에서 초기의 데이터 서버 대신에 대리 서버로 대체하기 위해 대리 서버 위치의 내부 링크 리스트가 사용된다. 이것은 사용자에 대한 단일 인터페이스 포인트를 유지하면서 사용자에 의한 미래의 억세스가 대리 데이터 서버중 하나로 이루어 지도록 한다. 이러한 예를 이용하여, 사용자 w3.extern1.com\xxx.yyy, w3.extern1.com\xxx.zzz, 및 w3.extern1.com\qqq.xxx 에 대한 레퍼런스를 갖고 있는 웹 페이지 http:\\w3.extern1.com\xxx.xxx 를 억세스할 수 있다. 이 페이지가 요구자(requester)로 전송되고 'extern1'(301) 데이터 서버가 비지상태 이면, 사용자는 다른 정보를 위해 http:\\w3.extern2.com\xxx.yyy, http:\\w3.extern2.com\xxx.zzz, 및 http:\\w3.extern2.com\qqq.xxx 에 대한 링크를 가진 웹 페이지 http:\\w3.extern1.com\xxx.xxx 를 수신할 수도 있다. 그러므로, 사용자가 그 내부 링크중 어느 것을 따라가면, 'extern2' 서버(303)를 억세스하게 된다. 'extern3' 서버(305) 또는 'extern4' 서버(307)를 억세스하기 위해서도 비슷한 시나리오가 수반된다.

본 발명의 양호한 실시예는 웹 페이지에 대하여 프리프로세서(preprocessor) (또는 사전처리)를 실행하므로써 구현된다. 웹 서버상에 내재하는 이 프리프로세서는, 웹 페이지내에 포함된 링크 수의 카운트를 표시하기 위해 각각의 웹 페이지의 시작부분에 헤더를 부가하고, 선택된 페이지내에 포함된 웹 페이지에 대한 각각의 링크의 위치 또는 오프셋을 표시하기 위한 값을 부가한다. 이것을 실현하는 가장 용이하고 가장 직접적인 방법은, 예를 들어, 50개의 대리 서버가 존재하는 경우에 이들 서버에 'abcd.xyz01.aaa'로부터 'abcd.xyz50.aaa' 까지 명명하는 것과 같이 서버가 순차적으로 명명되도록 하는 규약을 채택하는 것이다. 만일 이러한 규약이 채택되면, 프리프로세서에 의해 부가된 헤더의 포인터는 서버 명칭의 대치가능한(replaceable) 숫자 부분에 대한 오프셋을 포함한다. 본 발명의 구현이 속행되고 최초의 서버가 비지상태라는 판단이 이루어지면, 이 프로세스는 대리 서버의 링크된 리스트를 통해 인덱스하고, 단지 2개의 숫자만이 대치된다. 이것은 또한, 링크된 리스트의 필드가 전체 서버 명칭이 아닌 2개의 대치가능한 숫자만을 포함하도록 허용하기 때문에 링크된 리스트를 간략하게 한다.

도6a는 프리프로세서를 통해 진행되기 전의 웹 페이지를 도시하는 그래프도 이다. 웹 페이지(601)의 시작부분에 대한 포인터(603)가 존재한다. 웹 페이지내에는 추가적인 웹 페이지에 대한 링크(605,607,609)가 있다. 본 실시예에서, 모든 링크는 동일한 서버로 향하고 있지만, 이것은 반드시 그런 경우가 되는 것은 아니다. 복수의 서버로 향하는 링크가 존재할 수도 있다.

도6b는 본 발명에서와 같이 재처리된 이후의 도6a와 동일한 페이지의 그래프도 이다. 이제, 웹 페이지(610)는 헤더(611)를 포함한다. 본 실시예에서 헤더(611)는 처리된 웹 페이지내의 링크 수의 카운트(613)와, 처리된 페이지내의 페이지 링크의 오프셋(615,617,619) 각각에 대한 레퍼런스를 포함한다. 데이터의 시작부분에 대한 포인터(620)와 다른 웹 페이지에 대한 링크(621,623,625)는 변하지 않은 상태로 유지된다.

도4는 또한, 흐름도를 이용하여 본 발명의 개념을 설명하고 있다. 본 발명을 구현하는 웹 사이트가 설정되면, 먼저 이용가능한 복수의 대리 사이트가 있는지 판단하기 위한 검사가 이루어진다(401). 만일 이용가능한 복수의 대리 사이트가 존재하지 않으면, 정보는 종래 기술에서와 같이 처리된다(403). 만일 이용가능한 복수의 대리 사이트가 존재하면, 대리 서버에 관한 내부의 링크된 리스트가 작성된다(405). 이 내부의 링크된 리스트는 최초의 데이터 서버상에 저장된다. 다음에는, 최초의 데이터 서버상에 위치된 웹 페이지에 대한 요구가 수신되었는지 판단하기 위한 검사가 이루어진다(407). 만일 요구가 수신되지 않았으면, 서버는 요구를 대기한다(409). 만일 최초의 데이터 서버상에 위치된 웹 페이지에 대한 요구가 수신되었으면, 최초의 데이터 서버가 '비지상태'인지 판단하기 위한 검사가 이루어진다(411). 만일 최초의 데이터 서버가 비지상태가 아니면, 그 요구는 최초의 데이터 서버상에서 전부 처리된다(413). 만일 최초의 데이터 서버가 비지상태 이면, 최초의 데이터 서버에 대한 레퍼런스를 대리 데이터 서버중 하나로 대체하기 위해 대리 서버의 내부의 링크된 리스트가 사용된다(415). 이것은 사용자에게 반송된 페이지내의 최초의 데이터 서버에 대한 모든 내부 링크 또는 레퍼런스가 사용자 인터페이스에 영향을 주지 않고 실제적으로 최초의 데이터 서버의 작업을 분담하는 대리 데이터 서버의 어드레스로 대치되도록 한다.

본 발명의 양호한 실시예에서, 브라우저는 웹 페이지의 헤더를 처리하고, 마주치게 되는 (페이지 링크의 오프셋의 리스트에 의해 표시되는 바와 같은) 최초의 데이터 서버에 대한 각각의 레퍼런스를 위해, 최초의 데이터 서버는 대리 데이터 서버로 대치되게 된다.

도5a 및 도5b는 링크를 대용할 때 어떤 대리 서버를 사용할 것인지 판단하는 대안의 수단을 도시하는 흐름도이다. 이 시점에서 2개의 바람직한 대안이 존재하지만, 본 발명은 대리 서버를 통해 순환하는 어떠한 방법과도 함께 이용될 수 있다. 여기서 제안된 '라운드 로빈' 방식 및 '최소 비지상태' 방식의 대안은 본 발명을 제한하는 것을 의미하는 것은 아니다.

도5a는 서버 리타겟팅(retargeting)의 라운드 로빈 방법을 도시하고 있다. 도5a에서, 먼저 '리타겟트된 서버' 에 대한 포인터가 제1 대리 서버로 설정된다(501). 다음에, 리타겟팅이 지시되었는지 판단하기 위한 검사가 이루어진다(503). 만일 리타겟팅이 지시되지 않았으면, 시스템은 리타겟팅 명령을 대기한다(505). 만일 리타겟팅이 지시되었으면, 요구된 웹 페이지내의 링크는 최초의 데이터 서버로부터 '리타겟트된 서버' 포인터에 의해 지시된 데이터 서버로 변경된다(507). 다음에는, 현재의 '리타겟트된 서버'가 체인(chain)내의 마지막 서버를 지시하는지 판단하기 위한 검사가 이루어진다(509). 만일 '리타겟트된 서버'가 체인내의 마지막 서버를 지시하면, '리타겟트된 서버' 포인터가 제1 대리 서버로 설정된다(511). 만일 '리타겟트된 서버'가 체인내의 마지막 서버를 지시하지 않으면, '리타겟트된 서버' 포인터는 그 다음 이용가능한 대리 서버를 지시하도록 증가된다(513).

도5b는 서버 리타겟팅의 최소-비지상태(least-busy) 방법을 도시한다. 도5b에서는 먼저, 최소 비지상태의 대리 서버를 판단하기 위해 각각의 대리 서버에 관한 질의가 이루어진다(525). 다음에, '리타겟트된 서버' 포인터가 최소 비지상태 대리 서버를 지시하도록 설정된다(527). 다음에는, 리타겟팅 지시가 수신되었는지 판단하기 위한 검사가 이루어진다(529). 만일 리타겟팅 지시가 수신되지 않았으면, 시스템은 리타겟팅 지시를 대기한다(531). 만일 리타겟팅 지시가 수신되었으면, 사용자에게 반송된 웹 페이지내의 내부 링크가 '리타겟트된 서버'상에 위치된 웹 페이지를 지시하도록 변경된다(533). 다음에는, 가장 최근의 정보를 이용하여 최소 비지상태 대리 서버가 다시 계산되고(535), '리타겟트된 서버' 포인터는 현재 최소 비지상태의 서버로 재설정된다(537).

전술한 양호한 실시예에 대한 대안은 내부의 링크된 리스트가 각각의 서버상에 저장될 수 있도록 허용한다. 이것은 2차적인 데이터 서버가 너무 비지상태인 경우에 이들 서버가 요구의 방향을 수정하도록 허용한다.

본 발명은 하나 또는 그 이상의 대리 서버의 명칭이 모두 동일한 크기로 되어 있는 것으로 가정한다. 이러한 가정은 웹 페이지의 텍스트내의 문자 스트링(character strings)의 대치를 단순화시킨다. 만일 대리 서버의 명칭이 최초의 웹 서버와 다른 크기로 되어 있다면, 텍스트내의 정보는 패드(padded)되어야 한다.

도6c는 서버 xxx.xx1.xxx 가 비지상태 이고, 정보가 서버 xxx.xx2.xxx 로 방향 수정해야 되는지에 관한 판단이 이루어진 후의 도6b의 웹 페이지를 도시하고 있다. 이 특정 실시예에서는, 최초의 서버와 각각의 대리 서버 사이에서 서버 명칭중 하나의 숫자만이 상이하다는 규약이 채택되었기 때문에, 헤더에서 표현되는 숫자(615,617,619)는 서버 명칭의 대치가능한 숫자를 직접 지시할 수 있다. 대안으로, 만일 이러한 규약이 채택되지 않았으면, 이들 숫자는 http 어드레스의 시작부분을 지시할 수도 있으며, 전체 명칭이 대치되거나, 또는 인터페이스가 대치가능한 숫자로 카운트되도록 기록될 수도 있다.

본 발명의 양호한 실시예는 어떠한 방식으로든지 본 발명의 적응성을 제한하는 것을 의미하는 것은 아니다. 본 발명은 전송된 페이지가 다른 서버상의 복수의 사례를 구비한 다른 페이지를 참조하는 어떤 형태의 전송가능한 페이지 처리에도 적용될 수 있다.

본 발명의 개선은 웹 서버중 하나가 다운되는 경우에 피드백 메카니즘을 허용한다. 많은 공지된 피드백 메카니즘이 모두 사용될 수 있다. 웹 서버가 다운되면, 고장난 서버의 명칭 또는 포인터가 대리 서버의 링크된 리스트로부터 제거되고, 따라서 사용자가 고장난 서버로 루트되지 않도록 보장한다. 또한, 서버의 명칭이 이용가능하게 될 때 링크된 리스트에 포함되도록 하는데 있어서도 동일한 기술이 사용될 수 있다.

전술한 바와 같은 본 발명에 따르면, 기존의 하드웨어의 특수한 편성 또는 특수 하드웨어의 필요성을 없애고, 일련의 웹 서버가 독립적으로 동작할 수 있도록 하면서, 종래의 해결방안 보다 저렴한 비용으로, 웹 서버를 통한 부하 균형유지를 가능하게 한다는 효과가 있다.

Claims

2개 또는 그 이상의 서버를 포함하고, 적어도 하나의 부착된 원격 사용자가 있고, 하나 이상의 서버에 정보가 복사되어 있는 컴퓨터 네트워크에 있어서,

상기 2개 또는 그 이상의 서버내에서, 상기 서버중 한 서버로부터 원격 워크스테이션의 사용자로 전송될 정보의 페이지 - 여기서, 상기 정보의 페이지는 동일한 서버내의 정보 페이지들에 대한 추가적인 레퍼런스를 구비함 - 를 처리하기 위한 수단;

정보를 요구받은 서버가 비지상태 인지 검출하기 위한 수단;

처리된 페이지내의 비지상태의 서버에 대한 레퍼런스를 대리 서버로 대치하기 위한 수단; 및

상기 대리 서버로부터 후속 페이지들을 검색하기 위한 수단

을 포함해서 이루어진 컴퓨터 네트워크.
제1항에 있어서,

상기 페이지는 월드 와이드 웹 페이지이고, 상기 2개 또는 그 이상의 서버는 웹 서버이고, 상기 페이지들은 웹 페이지들인 컴퓨터 네트워크.
제1항에 있어서,

상기 처리 수단은 상기 정보 페이지의 시작부분에 헤더를 부가하도록 되어 있는 컴퓨터 네트워크.
제3항에 있어서,

상기 헤더는,

전송되는 페이지내의 동일한 서버내에서 정보 페이지들에 대한 다수의 레퍼런스를 포함하는 카운터 필드; 및

페이지들에 대한 레퍼런스의 각각에 대한 인덱스 필드 - 여기서, 상기 인덱스 필드는 대리 서버로 대치될 비지상태의 서버를 지시함 - 를 포함하는 컴퓨터 네트워크.
제1항에 있어서,

상기 대리 서버는 링크된 리스트에 배치되어 있는 컴퓨터 네트워크.
복사된 동일한 정보를 가진 2개 또는 그 이상의 서버 - 여기서, 각각의 서버는 복수의 정보 페이지들을 포함하고, 상기 정보 페이지들의 일부는 상기 동일한 서버상의 다른 정보 페이지들에 대한 레퍼런스를 포함함 - 에 걸쳐 작업부하를 균형유지하는 방법에 있어서,

상기 서버상에 내재하는 상기 정보 페이지들 각각을 사전처리(preprocessing) - 여기서, 상기 사전처리는 상기 정보 페이지들 각각에 헤더를 부가하는 것을 포함함 - 하는 단계;

상기 2개 또는 그 이상의 서버에 대한 레퍼런스를 포함하는 데이터 구조를 작성하는 단계;

원격 워크스테이션으로부터 상기 서버상에 내재하는 상기 정보 페이지들중 하나에 대한 요구를 수신하는 단계;

상기 요구된 정보 페이지가 내재하는 상기 서버가 비지상태 인지 판단하는 단계;

만일 상기 정보 페이지가 내재하는 상기 서버가 비지상태 이면, 상기 데이터 구조로부터 대리 서버를 선택하는 단계; 및

상기 페이지의 헤더에 의해 지시된 레퍼런스를 대치하므로써 상기 억세스된 서버에 대한 레퍼런스를 상기 대리 서버에 대한 레퍼런스로 대치하는 단계

를 포함해서 이루어진 작업부하 균형유지 방법.
제6항에 있어서,

상기 데이터 구조는 링크된 리스트인 작업부하 균형유지 방법.
제6항에 있어서,

상기 페이지는 월드 와이드 웹 페이지이고, 상기 서버는 웹 서버인 작업부하 균형유지 방법.
제6항에 있어서,

상기 헤더는,

전송되는 상기 정보 페이지내에서 정보 페이지들에 대한 다수의 레퍼런스를 포함하는 카운터 필드; 및

전송되는 상기 정보 페이지들내에 포함된 추가적인 정보 페이지들에 대한 각각의 레퍼런스를 위한 인덱스 필드를 포함하는 작업부하 균형유지 방법.