KR100944156B1 - 웹 서버 부하 분산 시스템 및 방법 - Google Patents

웹 서버 부하 분산 시스템 및 방법 Download PDF

Info

Publication number
KR100944156B1
KR100944156B1 KR1020080102892A KR20080102892A KR100944156B1 KR 100944156 B1 KR100944156 B1 KR 100944156B1 KR 1020080102892 A KR1020080102892 A KR 1020080102892A KR 20080102892 A KR20080102892 A KR 20080102892A KR 100944156 B1 KR100944156 B1 KR 100944156B1
Authority
KR
South Korea
Prior art keywords
dns
server
address
client
host name
Prior art date
Application number
KR1020080102892A
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 삼성에스디에스 주식회사
Priority to KR1020080102892A priority Critical patent/KR100944156B1/ko
Application granted granted Critical
Publication of KR100944156B1 publication Critical patent/KR100944156B1/ko

Links

Images

Classifications

    • 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/1036—Load balancing of requests to servers for services different from user content provisioning, e.g. load balancing across domain name servers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/45—Network directories; Name-to-address mapping
    • H04L61/4505—Network directories; Name-to-address mapping using standardised directories; using standardised directory access protocols
    • H04L61/4511—Network directories; Name-to-address mapping using standardised directories; using standardised directory access protocols using domain name system [DNS]

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

본 발명은 웹 서버 부하 분산 시스템 및 방법에 관한 것으로서, DNS 클라이언트가 소정 호스트 네임의 IP 주소를 요청하여, 로컬 DNS 서버가 DNS 질의를 행하는 경우, 호스트 네임의 관장 DNS 서버가 리디렉션 서버의 IP 주소를 전달한다. 그리고, DNS 클라이언트가 리디렉션 서버의 IP 주소를 통해 리디렉션 서버로 접속하였을 때, 리디렉션 서버는 호스트 네임에 DNS 클라이언트의 IP 주소를 부가하여 리디렉션 응답을 하며, 로컬 DNS 서버가 DNS 클라이언트의 IP 주소가 부가된 호스트 네임의 IP 주소에 대한 DNS 재질의를 수행하는 경우, 호스트 네임의 관장 DNS 서버가 호스트 네임에 부가된 DNS 클라이언트의 IP 주소를 이용하여, DNS 클라이언트에서 가장 가까운 캐시 서버의 IP 주소를 전송하는 웹 서버 부하 분산 시스템 및 방법이 개시된다.
GSLB, DNS, 서버 부하 분산, 클라이언트, 리디렉션

Description

웹 서버 부하 분산 시스템 및 방법{ Web Server Load Balancing System and Method }
본 발명은 웹 서버 부하 분산 시스템 및 방법에 관한 것으로, 보다 상세하게는 HTTP 리디렉션 응답을 통해 DNS 클라이언트의 IP 주소를 호스트 네임의 관장(Authoritative) DNS 서버에 전달하여, DNS 클라이언트에서 가장 가까운 곳에 위치하는 캐시 서버로의 접속을 유도하는 웹 서버 부하 분산 시스템 및 방법에 관한 것이다.
CDN(Content Delivery Network)은 네트워크 트래픽(Network Traffic)의 체증 원인이 되는 미들 마일(인터넷 망)의 문제와 캐싱 전략의 한계를 극복하기 위해 등장한 새로운 개념의 콘텐츠 전송 기술이다.
CDN의 목적은 인터넷 서비스의 질을 향상시키기 위해 다수의 서버를 네트워크 가장 자리에 분산시키고, 콘텐츠를 분산된 서버에 복제하여 클라이언트 가까이에 있는 복제 서버로 하여금 콘텐츠 요청에 응답하게 함으로서, 클라이언트에게 빠른 서비스를 제공하는 것이다.
CDN은 캐싱 기술을 한 단계 진보시킨 것으로, 캐싱은 일반적을 로컬 기반으로 사용하도록 설계되어 클라이언트들이 빈번히 요청하는 콘텐츠를 저장하는데 반해, CDN은 네트워크 전반에 분산되어 있는 복제 서버들을 관리하며 정책적으로 선택된 콘텐츠를 저장한다.
이러한 CDN을 구현하기 위해 사용되는 일반적인 방식이 DNS(Domain Name Service) 기반의 글로벌 서버 부하 분산 기법(Global Server Load Balancing : GSLB)이다.
여기서, DNS 기반의 GSLB란 클라이언트로부터 특정 호스트 이름에 대한 IP 주소를 요청하는 질의가 있는 경우, DNS 서버가 클라이언트의 위치에 따라 네트워크 상에서 클라이언트로부터 가장 가까운 서버의 IP 주소를 알려주어, 클라이언트로 하여금 상기 호스트 이름을 가진 다수의 서버 중 가장 빠른 서비스를 제공할 수 있는 서버에 접속하도록 유도해주는 기술을 말한다.
도 1은 일반적인 DNS 동작 과정을 나타낸 도면이다.
도 1을 참조하면, 먼저 DNS 클라이언트(10)가 로컬 DNS 서버(20)에게 특정 호스트 이름(예를 들어, www.example.com)에 대한 IP 주소를 묻는 순환 질의(Recursive Query)를 보낸다(①). 상기 로컬 DNS 서버(20)는 상기 DNS 클라이언트(10)에 설정된 DNS 서버를 말한다.
여기서, 순환 질의(Recursive Query)는 DNS의 동작 모드 중 하나로서, 상기 로컬 DNS 서버(20)는 상기 순환 질의에 대해서 다른 DNS 서버를 참조하라는 응답을 해서는 안되며, 상기 순환 질의에 대해 끝까지 정보를 찾아서 응답을 해주어야 하고, 존재하지 않는 정보에 대해서는 에러 메시지를 전달한다.
이때, 상기 로컬 DNS 서버(20)는 자신의 영역(Zone) 파일 즉, 특정 도메인에 속하는 호스트 이름과 그에 해당하는 IP 주소가 저장된 파일을 검색하여 상기 DNS 클라이언트(10)가 요청하는 www.example.com 도메인에 대한 영역 파일이 있는지를 확인한다.
다음으로, 상기 로컬 DNS 서버(20)는 루트 DNS 서버(30)에게 www.example.com의 IP 주소를 묻는 반복 질의(Iterative Query)를 보낸다(②).
즉, 상기 확인 결과, 상기 로컬 DNS 서버(20)는 자신의 영역 파일에 www.example.com 도메인에 대한 영역 파일이 없음을 알게 되며, 따라서 example.com 도메인 또는 com 도메인의 관장(Authoritative) DNS서버의 IP 주소를 알기 위해, 루트 DNS 서버(30)로 www.example.com의 IP 주소를 묻는 반복 질의를 보내게 된다.
여기서, 반복 질의(Iterative Query)는 DNS의 또 다른 동작 모드로서, DNS 서버는 상기 반복 질의에 대해 자신에게 해당하는 정보가 없는 경우, 해당 정보를 관장하는 또 다른 DNS 서버의 정보를 알려준다.
상기 루트 DNS 서버(30)는 루트 도메인에 대한 관장 서버이며, 탑 레벨(Top-Level) 도메인(예를 들면, biz, com, net, org, info, pro 등)에 대한 관장 DNS 서버의 정보를 가지고 있다.
따라서, 상기 루트 DNS 서버(30)는 www.example.com의 탑 레벨 도메인인 com 의 관장 DNS 서버(40)의 IP 주소를 상기 로컬 DNS 서버(20)로 전송한다(③).
이어서, 상기 로컬 DNS 서버(20)는 www.example.com의 IP 주소를 묻는 반복 질의를 탑 레벨의 도메인인 com의 관장 DNS 서버(40)로 보낸다(④).
상기 com의 관장 DNS 서버(40)는 com 도메인의 하위 레벨 도메인(예를 들면, example.com, samsung.com 등)에 대한 관장 DNS 서버의 IP 주소를 가지고 있다. 따라서, example.com의 관장 DNS 서버(50)의 IP 주소를 상기 로컬 DNS 서버(20)로 전송한다(⑤).
연이어, 상기 로컬 DNS 서버(20)는 www.example.com의 IP 주소를 묻는 반복 질의를 상기 example.com의 관장 DNS 서버(50)로 보낸다(⑥).
그러면, 상기 example.com의 관장 DNS 서버(50)는 www.example.com의 IP 주소를 상기 로컬 DNS 서버(20)로 전송한다(⑦).
그 후, 상기 로컬 DNS 서버(20)는 상기 www.example.com의 IP 주소를 DNS 클라이언트(10)로 전달한다(⑧).
한편, DNS 기반의 GSLB는 네트워크상의 여러 곳에 www.example.com 서버에 대한 다수의 캐시 서버를 두고, DNS 클라이언트의 위치에서 가장 가까운 캐시 서버의 IP 주소를 알려주는 기술이다.
즉, 상기 DNS 동작 과정 중 ⑦에서, example.com의 관장 DNS 서버(50)는 www.example.com의 IP 주소를 알려줄 때, 상기 DNS 클라이언트(10)의 IP 주소를 고려하여, 상기 DNS 클라이언트(10)에서 가장 가까운 곳에 위치한 캐시 서버의 IP 주 소를 알려주게 된다.
이렇게 함으로써, 원본 www.example.com 서버에 대한 부하 분산이 이루어지며, 동시에 사용자는 자신으로부터 가까운 곳에 위치한 서버에 접속하게 됨으로써, 빠른 서비스를 제공받을 수 있게 된다.
그러나, 종래의 DNS 기반의 GSLB는 DNS 클라이언트(즉, 사용자 컴퓨터)의 위치를 정확히 파악할 수 없다는 단점이 있다.
즉, 도 1을 참조하면, DNS 동작 과정에서 example.com의 관장 DNS 서버(50)에게 IP 주소를 묻는 주체는 DNS 클라이언트(10)가 아니라 상기 DNS 클라이언트(10)에 설정된 로컬 DNS 서버(20)이다.
따라서, DNS 클라이언트(10)의 위치와 상기 DNS 클라이언트(10)에 설정된 로컬 DNS 서버(20)의 위치가 멀리 떨어져 있는 경우에는 DNS 클라이언트(10)에 인접한 서버로의 접속을 보장할 수 없게 된다.
예를 들어, 한국의 사용자가 노트북의 로컬 DNS 서버를 한국 통신 DNS 서버로 설정한 후에 미국으로 출장을 가는 경우를 생각해보면, example.com의 관장 DNS 서버(50)는 상기 노트북(위치 : 미국)으로부터 DNS 질의를 받는 것이 아니라, 한국 통신 DNS 서버(위치 : 한국)로부터 DNS 질의를 받게 되므로, 한국 통신 DNS 서버에서 가장 가까운 서버의 IP 주소를 알려주게 된다.
이는 example.com의 관장 DNS 서버(50)가 DNS 클라이언트(10)의 정확한 위치를 파악할 수 없기 때문에 나타나는 현상이므로, 상기 example.com의 관장 DNS 서버(50)에게 DNS 클라이언트(10)의 정확한 위치를 알릴 수 있는 방안이 요구된다.
본 발명의 목적은 사용자 컴퓨터가 소정 호스트 네임의 IP 주소를 요청할 때, 사용자 컴퓨터의 위치에서 가장 가까운 곳의 캐시 서버의 IP 주소를 전달하는 웹 서버 부하 분산 시스템 및 방법을 제공하는 데 있다.
본 발명의 다른 목적은 DNS 기반의 GSLB의 동작 방식 및 DNS 프로토콜의 변경없이 사용자 컴퓨터의 IP 주소를 호스트 네임을 관장하는 호스트 네임의 관장(Authoritative) DNS 서버에 전달하는 웹 서버 부하 분산 시스템 및 방법을 제공하는 데 있다.
상기 문제점을 해결하기 위한 본 발명의 웹 서버 부하 분산 시스템의 바람직한 실시예는, 소정 호스트 네임의 IP 주소를 요청하는 DNS 클라이언트와, 상기 DNS 클라이언트에 설정되며, 상기 DNS 클라이언트의 요청에 대해 상위 DNS 서버들에게 상기 호스트 네임의 IP 주소에 대한 DNS 질의(Query)를 수행하는 로컬 DNS 서버와, 상기 호스트 네임의 도메인을 관장하며, 상기 DNS 질의에 대해 리디렉션(Redirection) 서버의 IP 주소를 전송하는 호스트 네임 관장(Authoritative) DNS 서버와, 상기 DNS 클라이언트가 접속해오는 경우, 상기 DNS 클라이언트의 IP 주소를 상기 호스트 네임에 부가하여 리디렉션 응답하는 리디렉션(Redirection) 서버를 포함하여 이루어진다.
여기서, 상기 DNS 클라이언트는 상기 DNS 클라이언트의 IP 주소가 부가된 호스트 네임의 IP 주소에 대한 재요청을 하고, 상기 로컬 DNS 서버는 상기 DNS 클라이언트의 재요청에 대해, 상위 DNS 서버들에게 상기 DNS 클라이언트의 IP 주소가 부가된 호스트 네임의 IP 주소에 대한 DNS 재질의를 수행하는 것을 특징으로 한다.
또한, 상기 호스트 네임 관장 DNS 서버는, 상기 로컬 DNS 서버의 DNS 재질의에 대해, 상기 호스트 네임에 부가된 DNS 클라이언트의 IP 주소를 이용하여, 상기 DNS 클라이언트에서 가장 가까운 캐시 서버의 IP 주소를 전송하는 것을 특징으로 한다.
한편, 본 발명의 웹 서버 부하 분산 방법의 바람직한 실시예는, (A) DNS 클라이언트가 소정 호스트 네임의 IP 주소를 요청하는 단계와, (B) 상기 DNS 클라이언트에 설정된 로컬 DNS 서버가 상기 DNS 클라이언트의 요청에 대해 상위 DNS 서버들에게 상기 호스트 네임의 IP 주소에 대한 DNS 질의(Query)를 수행하는 단계와, (C) 상기 호스트 네임의 도메인을 관장하는 호스트 네임 관장(Authoritative) DNS 서버가 상기 DNS 질의에 대해 리디렉션(Redirection) 서버의 IP 주소를 전송하는 단계와, (D) 상기 DNS 클라이언트가 접속해오는 경우, 상기 리디렉션(Redirection) 서버가 상기 DNS 클라이언트의 IP 주소를 상기 호스트 네임에 부가하여 리디렉션 응답하는 단계를 포함하여 이루어진다.
여기서, 상기 (D) 단계 이후에, (E) 상기 DNS 클라이언트가 상기 로컬 DNS 서버로 상기 DNS 클라이언트의 IP 주소가 부가된 호스트 네임의 IP 주소에 대한 재요청을 하는 단계와, (F) 상기 로컬 DNS 서버가 상기 DNS 클라이언트의 재요청에 대해, 상위 DNS 서버들에게 상기 DNS 클라이언트의 IP 주소가 부가된 호스트 네임의 IP 주소에 대한 DNS 재질의를 수행하는 단계를 더 포함하여 이루어지는 것을 특징으로 한다.
또한, 상기 (F) 단계에서, 상기 호스트 네임 관장 DNS 서버는, 상기 로컬 DNS 서버의 DNS 재질의에 대해, 상기 호스트 네임에 부가된 DNS 클라이언트의 IP 주소를 이용하여, 상기 DNS 클라이언트에서 가장 가까운 캐시 서버의 IP 주소를 전송하는 것을 특징으로 한다.
본 발명의 실시예에 의하면, HTTP 리디렉션 응답을 이용함으로써, DNS 기반의 GSLB 동작 방식 및 DNS 프로토콜의 변경없이 DNS 클라이언트의 정확한 주소를 호스트 네임의 관장(Authoritative) DNS 서버에게 알려줄 수 있으며, 그로 인해 DNS 클라이언트의 실제 위치에서 가장 가까운 캐시 서버로의 접속을 유도할 수 있게 된다.
이하, 도 2 및 도 3을 참조하여 본 발명의 웹 서버 부하 분산 시스템 및 방법의 구체적인 실시형태를 설명하기로 한다. 그러나 이는 예시에 불과하며 본 발명은 이에 제한되지 않는다.
본 발명을 설명함에 있어서, 본 발명과 관련된 공지기술에 대한 구체적인 설 명이 본 발명의 요지를 불필요하게 흐릴 수 있다고 판단되는 경우에는 그 상세한 설명을 생략하기로 한다. 그리고, 후술되는 용어들은 본 발명에서의 기능을 고려하여 정의된 용어들로서 이는 사용자, 운용자의 의도 또는 관례 등에 따라 달라질 수 있다. 그러므로 그 정의는 본 명세서 전반에 걸친 내용을 토대로 내려져야 할 것이다.
우선, DNS 클라이언트(사용자 컴퓨터)가 접속하고자하는 소정 호스트 네임의 관장(Authoritative) DNS 서버로 DNS 클라이언트의 IP 주소를 전달할 수 있는 방안으로는 다음의 방법을 생각해볼 수 있다.
1) DNS 클라이언트에 설정된 로컬 DNS 서버에서 인코딩하는 방법
- DNS 클라이언트에 설정된 로컬 DNS 서버가 DNS 클라이언트로부터 www.example.com에 대한 질의를 받으면, 이를 상위 DNS 서버로 전달할 때, DNS 클라이언트 IP 주소.www.example.com으로 바꾸어서 묻는 방법이다.
예를 들면, DNS 클라이언트 IP 주소가 1.2.3.4라고 하면, 로컬 DNS 서버에서 1-2-3-4.www.example.com으로 바꾸어서 상위 DNS 서버로 전달하는 방법이다.
2) DNS 질의 포맷에 DNS 클라이언트의 IP 주소를 포함하는 방법
- DNS 클라이언트에 설정된 로컬 DNS 서버가 상위 DNS 서버로 질의할 때, DNS 질의 자체에 DNS 클라이언트의 IP 주소를 포함할 수 있는 필드를 추가하는 방법이다.
3) 사용자가 직접 URL을 쓰는 방법
- 사용자가 직접 www.example.com 대신 1-2-3-4.www.example.com이라고 URL을 쓰는 방법이다.
여기서, 상기 1) 및 2)의 방법은 기술적으로는 가능하지만 실제 현장에 적용하기가 거의 불가능하다는 단점이 있다.
즉, DNS 클라이언트에 설정된 로컬 DNS 서버는 특정 ISP(Internet Service Provider)에 속한 서버들이며, GSLB를 구현하는 주체가 상기 ISP DNS 서버에 대한 소유권이 없으므로, ISP DNS 서버가 DNS 클라이언트의 IP 주소를 인코딩하거나, DNS 질의 포맷에 DNS 클라이언트의 IP 주소를 추가하는 방법을 사용할 수 있는 방안이 없다.
즉, 실제 GSLB를 적용하는데 있어서 제어 가능한 범위는 웹 서버(www.example.com)와 example.com의 관장 DNS 서버뿐이며, 그 이외의 DNS 서버는 특정 ISP에 속한 서버이어서 GSLB를 구현하는 주체가 제어할 수 없게 된다.
상기 1) 및 2)의 방법을 적용하려면, 모든 ISP DNS 서버의 동작 방식이 변경되어야 하며, 특히 2)의 방법의 경우, 기존의 DNS 질의 포맷 자체에 변경을 가해야 하므로, DNS 프로토콜을 변경해야 하는 문제점이 있다.
상기 3)의 방법은 사용자가 자신이 사용하는 컴퓨터의 IP 주소를 찾아서 이를 직접 URL로 기입하여야 하는바, 컴퓨터를 다루는데 미숙한 사람에게는 여간 불편한 일이 아닐 수 없다.
따라서, 기존의 DNS 기반의 GSLB의 동작 방식 및 DNS 프로토콜을 변경하지 않고, 사용자에게 불편을 주지 않는 한도에서 DNS 클라이언트의 IP 주소를 호스트 네임의 관장(Authoritative) DNS 서버로 전달할 수 있는 방안이 필요하다.
이를 위해, 본 발명에서는 www.example.com의 IP 주소를 묻는 질의에 대해 리디렉션 서버(Redirection Server)의 IP 주소를 알려주고, DNS 클라이언트에서 상기 리디렉션 서버로 접속해오면, 상기 리디렉션 서버는 DNS 클라이언트의 IP 주소를 알 수 있으므로, 1-2-3-4.www.example.com 형태의 URL로 리디렉션해줌으로써, DNS 클라이언트의 실제 위치에서 가장 가까운 서버의 IP 주소를 알려준다.
도 2는 본 발명의 웹 서버 부하 분산 시스템을 나타낸 도면이다. 여기서, 본 발명의 동작 과정을 번호로 나타내었으며, 이에 대한 자세한 설명은 후술하기로 한다.
도 2를 참조하면, 본 발명의 웹 서버 부하 분산 시스템(100)은 DNS 클라이언트(110), 로컬 DNS 서버(120), 루트 DNS 서버(130), 탑 레벨 DNS 서버(140), 호스트 네임의 관장(Authoritative) DNS 서버(150), 리디렉션(Redirection) 서버(160), 캐시 서버(170)를 포함하여 이루어진다.
이와 같이 구성된 웹 서버 부하 분산 시스템(100)에서, 상기 DNS 클라이언트(110)는 특정 호스트 네임에 대한 IP 주소를 묻는 순환 질의(Recursive Query)를 상기 로컬 DNS 서버(120)로 보낸다.
상기 로컬 DNS 서버(120)는 상기 DNS 클라이언트(110)에 설정된 DNS 서버이며, 상기 순환 질의에 대해 상위 DNS 서버들에게 반복 질의(Iterative Query)를 보낸다.
상기 루트 DNS 서버(130)는 루트 도메인에 대한 관장(Authoritative) DNS 서버이며, 탑 레벨 도메인(예를 들면, biz, com, net, org, info, pro 등)에 대한 관장 DNS 서버의 정보를 가진다.
따라서, 상기 루트 DNS 서버(130)는 상기 로컬 DNS 서버(120)의 반복 질의에 대해 탑 레벨 도메인의 관장 DNS 서버의 IP 주소를 전송해준다.
상기 탑 레벨 DNS 서버(140)는 하위 레벨 도메인에 대한 관장 DNS 서버의 정보를 가지며, 상기 로컬 DNS 서버(120)의 반복 질의에 대해 하위 레벨 도메인의 관장 DNS 서버의 IP 주소를 전송해준다.
상기 호스트 네임의 관장(Authoritative) DNS 서버(150)는 상기 로컬 DNS 서버(120)의 반복 질의에 대해 리디렉션 서버(160)의 IP 주소를 전송한다.
또한, 상기 호스트 네임의 관장 DNS 서버(150)는 상기 로컬 DNS 서버(120)의 반복 질의에 대해 상기 DNS 클라이언트(110)의 위치에서 가장 가까운 곳의 캐시 서버(170)의 IP 주소를 전송한다.
상기 리디렉션(Redirection) 서버(160)는 상기 DNS 클라이언트(110)가 접속해오는 경우, 상기 DNS 클라이언트(110)가 요청하는 호스트 네임에 상기 DNS 클라이언트(110)의 IP 주소를 부가하여 리디렉션 응답을 한다.
상기 캐시 서버(170)는 상기 DNS 클라이언트(110)가 접속하는 경우, 상기 DNS 클라이언트(110)가 원하는 콘텐츠를 전송해준다. 여기서, 상기 캐시 서버(170)는 상기 DNS 클라이언트(110)의 위치에서 가장 가까운 곳에 위치한 캐시 서버이다.
본 발명에 의하면, DNS 질의의 전달 과정에 관여하지 않는 HTTP 리디렉션 응 답을 사용함으로써, DNS 기반의 GSLB 동작 방식 및 DNS 프로토콜의 변경없이 DNS 클라이언트의 정확한 주소를 호스트 네임의 관장(Authoritative) DNS 서버에게 알려줄 수 있다.
도 3은 본 발명의 웹 서버 부하 분산 방법의 실시예를 나타낸 도면이다. 여기서는 DNS 클라이언트가 www.example.com이라는 호스트 네임에 대한 IP 주소를 요청하는 경우를 일 예로 살펴보기로 한다.
도 3을 참조하면, 먼저, DNS 클라이언트(110)가 로컬 DNS 서버(120)에게 www.example.com에 대한 IP 주소를 묻는 순환 질의(Recursive Query)를 보낸다(S 100).
다음으로, 상기 로컬 DNS 서버(120)는 루트 DNS 서버(130)에게 www.example.com의 IP 주소를 묻는 반복 질의(Iterative Query)를 보낸다(S 101).
이어서, 상기 루트 DNS 서버(130)는 www.example.com의 탑 레벨 도메인인 com의 DNS 서버(140)의 IP 주소를 상기 로컬 DNS 서버(120)로 전송한다(S 102).
연이어, 상기 로컬 DNS 서버(120)는 www.example.com의 IP 주소를 묻는 반복 질의를 탑 레벨의 도메인인 com의 DNS 서버(140)로 보낸다(S 103).
그 후, 상기 com의 DNS 서버(140)는 example.com의 관장 DNS 서버(150)의 IP 주소를 상기 로컬 DNS 서버(120)로 전송한다(S 104).
다음으로, 상기 로컬 DNS 서버(120)는 www.example.com의 IP 주소를 묻는 반복 질의를 상기 example.com의 관장 DNS 서버(150)로 보낸다(S 105). 여기까지의 동작 과정은 종래의 DNS 기반의 GSLB와 동일하다.
이어서, 상기 example.com의 관장 DNS 서버(150)는 리디렉션 서버(160)의 IP 주소를 상기 로컬 DNS 서버(120)로 전송한다(S 106).
연이어, 상기 로컬 DNS 서버(120)는 상기 리디렉션 서버(160)의 IP 주소를 상기 DNS 클라이언트(110)로 전송하며(S 107), 상기 DNS 클라이언트(110)는 상기 리디렉션 서버(160)로 접속한다(S 108).
그 후, 상기 리디렉션 서버(160)는 HTTP 리디렉션 응답을 이용하여 [DNS 클라이언트의 IP 주소].www.example.com으로 리디렉션한다(S 109).
이때, DNS 클라이언트(110)가 직접 접속을 하게 되므로, 상기 리디렉션 서버(160)는 상기 DNS 클라이언트(110)의 IP 주소를 알 수 있다.
예를 들어, 상기 리디렉션 서버(160)는 상기 DNS 클라이언트(110)의 IP 주소가 1.2.3.4라고 하면, 1-2-3-4.www.example.com으로 리디렉션한다.
다음으로, 상기 리디렉션 응답을 받은 DNS 클라이언트(110)는 상기 로컬 DNS 서버(120)에게 1-2-3-4.www.example.com의 IP 주소를 묻는 순환 질의를 보내고(S 110), 상기 로컬 DNS 서버(120)는 다시 반복 질의를 통해 1-2-3-4.www.example.com의 IP 주소를 얻는 과정을 수행한다(S 111→S 112→S 113→S 114→S 115).
여기서, 상기 example.com의 관장 DNS 서버(150)는 상기 로컬 DNS 서버(120)로부터 1-2-3-4.www.example.com의 IP 주소를 알려달라는 요청을 받게 되며, 이때 DNS 클라이언트(110)의 위치를 고려하여 상기 DNS 클라이언트(110)의 위치로부터 가장 가까운 캐시 서버(170)의 IP 주소를 알려준다(S 116).
즉, 상기 example.com의 관장 DNS 서버(150)는 호스트 네임인 1-2-3-4.www.example.com로부터 IP 주소가 1.2.3.4인 DNS 클라이언트가 www.example.com의 IP 주소를 요청하고 있다는 것을 알 수 있으며, 이때 상기 DNS 클라이언트(110)의 위치로부터 가장 가까운 캐시 서버(170)의 IP 주소를 알려준다.
이어서, 상기 로컬 DNS 서버(120)는 상기 DNS 클라이언트(110)의 위치로부터 가장 가까운 캐시 서버(170)의 IP 주소를 상기 DNS 클라이언트(110)로 전달해주고(S 117), 상기 DNS 클라이언트(110)는 상기 캐시 서버(170)에 접속하며(S 118), 상기 캐시 서버(170)는 상기 DNS 클라이언트(110)가 요청하는 콘텐츠를 전송해준다(S 119).
본 발명에 의하면, HTTP 리디렉션 응답을 이용함으로써, DNS 기반의 GSLB 동작 방식 및 DNS 프로토콜의 변경없이 DNS 클라이언트의 정확한 주소를 호스트 네임의 관장(Authoritative) DNS 서버에게 알려줄 수 있으며, 그로 인해 DNS 클라이언트의 실제 위치에서 가장 가까운 캐시 서버로의 접속을 유도할 수 있게 된다.
이상에서 대표적인 실시예를 통하여 본 발명에 대하여 상세하게 설명하였으나, 본 발명이 속하는 기술분야에서 통상의 지식을 가진 자는 상술한 실시예에 대하여 본 발명의 범주에서 벗어나지 않는 한도 내에서 다양한 변형이 가능함을 이해할 것이다.
그러므로 본 발명의 권리범위는 설명된 실시예에 국한되어 정해져서는 안 되며, 후술하는 특허청구범위뿐만 아니라 이 특허청구범위와 균등한 것들에 의해 정 해져야 한다.
도 1은 일반적인 DNS 동작 과정을 나타낸 도면.
도 2는 본 발명의 웹 서버 부하 분산 시스템 및 방법을 나타낸 도면.
* 도면의 주요 부분에 대한 부호의 설명 *
110 : DNS 클라이언트 120 : 로컬 DNS 서버
130 : 루트 DNS 서버 140 : 탑 레벨의 DNS 서버
150 : 호스트 네임의 관장 DNS 서버 160 : 리디렉션 서버
170 : DNS 클라이언트에서 가장 가까운 곳에 위치한 캐시 서버

Claims (7)

  1. 소정 호스트 네임의 IP 주소를 요청하는 DNS 클라이언트;
    상기 DNS 클라이언트에 설정되며, 상기 DNS 클라이언트의 요청에 대해 상위 DNS 서버들에게 상기 호스트 네임의 IP 주소에 대한 DNS 질의(Query)를 수행하는 로컬 DNS 서버;
    상기 호스트 네임의 도메인을 관장하며, 상기 DNS 질의에 대해 리디렉션(Redirection) 서버의 IP 주소를 전송하는 호스트 네임 관장(Authoritative) DNS 서버; 및
    상기 DNS 클라이언트가 접속해오는 경우, 상기 DNS 클라이언트의 IP 주소를 상기 호스트 네임에 부가하여 리디렉션 응답하는 리디렉션(Redirection) 서버를 포함하여 이루어지는 웹 서버 부하 분산 시스템.
  2. 제1항에 있어서,
    상기 리디렉션 서버는,
    상기 호스트 네임의 전단부에 상기 DNS 클라이언트의 IP 주소를 인코딩하여 부가하는 것을 특징으로 하는 웹 서버 부하 분산 시스템.
  3. 제1항에 있어서,
    상기 DNS 클라이언트는 상기 DNS 클라이언트의 IP 주소가 부가된 호스트 네임의 IP 주소에 대한 재요청을 하고,
    상기 로컬 DNS 서버는 상기 DNS 클라이언트의 재요청에 대해, 상위 DNS 서버들에게 상기 DNS 클라이언트의 IP 주소가 부가된 호스트 네임의 IP 주소에 대한 DNS 재질의를 수행하는 것을 특징으로 하는 웹 서버 부하 분산 시스템.
  4. 제3항에 있어서,
    상기 호스트 네임 관장 DNS 서버는,
    상기 로컬 DNS 서버의 DNS 재질의에 대해, 상기 호스트 네임에 부가된 DNS 클라이언트의 IP 주소를 이용하여, 상기 DNS 클라이언트에서 가장 가까운 캐시 서버의 IP 주소를 전송하는 것을 특징으로 하는 웹 서버 부하 분산 시스템.
  5. (A) DNS 클라이언트가 소정 호스트 네임의 IP 주소를 요청하는 단계;
    (B) 상기 DNS 클라이언트에 설정된 로컬 DNS 서버가 상기 DNS 클라이언트의 요청에 대해 상위 DNS 서버들에게 상기 호스트 네임의 IP 주소에 대한 DNS 질의(Query)를 수행하는 단계;
    (C) 상기 호스트 네임의 도메인을 관장하는 호스트 네임 관 장(Authoritative) DNS 서버가 상기 DNS 질의에 대해 리디렉션(Redirection) 서버의 IP 주소를 전송하는 단계; 및
    (D) 상기 DNS 클라이언트가 접속해오는 경우, 상기 리디렉션(Redirection) 서버가 상기 DNS 클라이언트의 IP 주소를 상기 호스트 네임에 부가하여 리디렉션 응답하는 단계를 포함하여 이루어지는 웹 서버 부하 분산 방법.
  6. 제5항에 있어서,
    상기 (D) 단계 이후에,
    (E) 상기 DNS 클라이언트가 상기 로컬 DNS 서버로 상기 DNS 클라이언트의 IP 주소가 부가된 호스트 네임의 IP 주소에 대한 재요청을 하는 단계; 및
    (F) 상기 로컬 DNS 서버가 상기 DNS 클라이언트의 재요청에 대해, 상위 DNS 서버들에게 상기 DNS 클라이언트의 IP 주소가 부가된 호스트 네임의 IP 주소에 대한 DNS 재질의를 수행하는 단계를 더 포함하여 이루어지는 웹 서버 부하 분산 방법.
  7. 제6항에 있어서,
    상기 (F) 단계에서,
    상기 호스트 네임 관장 DNS 서버는, 상기 로컬 DNS 서버의 DNS 재질의에 대 해, 상기 호스트 네임에 부가된 DNS 클라이언트의 IP 주소를 이용하여, 상기 DNS 클라이언트에서 가장 가까운 캐시 서버의 IP 주소를 전송하는 것을 특징으로 하는 웹 서버 부하 분산 방법.
KR1020080102892A 2008-10-21 2008-10-21 웹 서버 부하 분산 시스템 및 방법 KR100944156B1 (ko)

Priority Applications (1)

Application Number Priority Date Filing Date Title
KR1020080102892A KR100944156B1 (ko) 2008-10-21 2008-10-21 웹 서버 부하 분산 시스템 및 방법

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
KR1020080102892A KR100944156B1 (ko) 2008-10-21 2008-10-21 웹 서버 부하 분산 시스템 및 방법

Publications (1)

Publication Number Publication Date
KR100944156B1 true KR100944156B1 (ko) 2010-02-24

Family

ID=42083763

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020080102892A KR100944156B1 (ko) 2008-10-21 2008-10-21 웹 서버 부하 분산 시스템 및 방법

Country Status (1)

Country Link
KR (1) KR100944156B1 (ko)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2011019110A1 (ko) * 2009-08-12 2011-02-17 삼성에스디에스 주식회사 콘텐츠 제공 시스템 및 방법
KR20150049821A (ko) * 2013-10-31 2015-05-08 삼성에스디에스 주식회사 서버 및 이를 이용한 부하 분산 방법

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20000064071A (ko) * 1999-12-23 2000-11-06 이재혁 웹 콘텐츠 전송 시스템 및 그 전송 제어 방법
US20020007413A1 (en) 2000-03-16 2002-01-17 Garcia-Luna-Aceves Jj System and method for using a mapping between client addresses and addresses of caches to support content delivery

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20000064071A (ko) * 1999-12-23 2000-11-06 이재혁 웹 콘텐츠 전송 시스템 및 그 전송 제어 방법
US20020007413A1 (en) 2000-03-16 2002-01-17 Garcia-Luna-Aceves Jj System and method for using a mapping between client addresses and addresses of caches to support content delivery

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2011019110A1 (ko) * 2009-08-12 2011-02-17 삼성에스디에스 주식회사 콘텐츠 제공 시스템 및 방법
KR101135087B1 (ko) 2009-08-12 2012-04-16 삼성에스디에스 주식회사 콘텐츠 제공 시스템 및 방법
KR20150049821A (ko) * 2013-10-31 2015-05-08 삼성에스디에스 주식회사 서버 및 이를 이용한 부하 분산 방법
KR102043031B1 (ko) 2013-10-31 2019-11-11 삼성에스디에스 주식회사 서버 및 이를 이용한 부하 분산 방법

Similar Documents

Publication Publication Date Title
US11115500B2 (en) Request routing utilizing client location information
US20220174010A1 (en) Updating routing information based on client location
US9800539B2 (en) Request routing management based on network components
US9160703B2 (en) Request routing management based on network components
AU2011307319B2 (en) Request routing in a networked environment
JP6146950B2 (ja) ネットワークコンピューティングコンポーネントを使用してルーティングをリクエストする方法およびシステム
JP5150769B2 (ja) 要求ルーティングおよびクライアントロケーション情報を利用したルーティング情報の更新
US8527635B2 (en) Contents delivery system and method, web server and contents provider DNS server thereof
EP2266064B1 (en) Request routing
US20150134848A1 (en) Alias resource record sets
US11463401B2 (en) Systems and methods for processing requests for content of a content distribution network
KR101135087B1 (ko) 콘텐츠 제공 시스템 및 방법
KR100944156B1 (ko) 웹 서버 부하 분산 시스템 및 방법
KR101039370B1 (ko) 도메인 위임에 의한 ｇｓｌｂ 서버 및 이를 이용한 ｃｄｎ 서비스 시스템 및 방법
KR101109524B1 (ko) 복수의 ｃｄｎ 사업자를 통한 컨텐츠 분배시스템 및 방법, 그 컨텐츠 제공자 네임서버

Legal Events

Date Code Title Description
A201 Request for examination
E701 Decision to grant or registration of patent right
N231 Notification of change of applicant
GRNT Written decision to grant
FPAY Annual fee payment

Payment date: 20130108

Year of fee payment: 4

FPAY Annual fee payment

Payment date: 20140103

Year of fee payment: 5

FPAY Annual fee payment

Payment date: 20141231

Year of fee payment: 6

FPAY Annual fee payment

Payment date: 20151228

Year of fee payment: 7

FPAY Annual fee payment

Payment date: 20170102

Year of fee payment: 8

FPAY Annual fee payment

Payment date: 20171213

Year of fee payment: 9

FPAY Annual fee payment

Payment date: 20190102

Year of fee payment: 10

FPAY Annual fee payment

Payment date: 20200121

Year of fee payment: 11