글로벌 로드밸런싱을 구현하는 기술은 여러 가지가 있다. 그 중에서 현재 가장 많이 이용되는 것은 네임서버에 대상 서버를 복수로 등록하는 방법과 ISP가 운영하는 네임서버의 정보를 이용하는 방법, HTTP 프로토콜의 리다이렉션을 이용하는 방법 등이다.
DNS 레코드 추가를 통한 서버 분산
글로벌 로드밸런싱을 구현하는 가장 간단한 방법은 DNS를 이용하는 것이다. 가장 쉽게 서버의 부하를 분산시켜주는 이 방법은 DNS 레코드에 서비스 가능한 모든 서버를 등록하면 된다.
예를 들어, abc.co.kr의 도메인을 관리하는 네임서버에 (화면 1)과 같이 등록하는 것만으로 기초적인 로드밸런싱을 구현할 수 있다. 이렇게 도메인 www.abc.co.kr에 대한 서버를 모두 등록해 놓으면, 네임서버는 사용자의 요청에 따라 교대로 해당 IP 주소를 리턴한다. (네임서버에 관해서는 시중에 관련 서적이 많이 나와있고, 인터넷에서 쉽게 관련 정보를 찾아볼 수 있기 때문에 여기서는 네임서버의 기본적인 내용에 대해서는 다루지 않겠다.)
@INSOAns.abc.co.kr.root.abc.co.kr. (2002100804;serial number
7200;refresh timer
600;retry time604800 ;expire timer - 1week300 ;minimum timer
)
; zone NS records
@INNSns.abc.co.kr.
INNSns2.abc.co.kr.
; zone records
@INA100.100.100.1
INMXI0 mail
mailINA100.100.100.2
www INA100.100.100.3
INA 100.100.100.4
INA200.200.200.3
INA300.300.300.4
INA300.300.300.3
물론 해당 서버의 성능을 고려해 같은 IP를 여러 번 넣어 줄 수도 있다. 그러면 그 비율대로 네임서버가 해당 IP 주소를 리턴해준다.
(화면 2)는 실제 www.yahoo.com의 IP 주소를 조회한 경우이다. 조회할 때마다 66.218.71.80, 66.218.71.81, 66.218.71.83, 66.218.71.84, 66.218.71.86, 66.218.71.87, 66.218.71.89의 7개 주소가 순서가 조금씩 바뀌면서 나오는 것을 볼 수 있다.
(화면 2) nslookup으로 www.yahoo.com을 조회한 경우
실제 브라우저를 통해 www.yahoo.com에 접속하는 경우에 브라우저는 네임서버로 질의한 후, 받은 IP 주소 중에서 맨 처음의 주소를 이용해 해당 서버로 접속하게 되므로 접속자를 7개의 서버에 골고루 분산시킬 수 있다.
그러나 이 방법은 구현이 쉬운 만큼 몇 가지 단점이 존재한다. 네임서버는 등록된 실제 서버가 어떤 서비스를 하는지에 대한 체크를 하지 않고, 더 나아가 서버가 다운됐는지조차 알지 못한 채 단순히 등록된 IP 주소를 반환하는 역할만 한다. 따라서 실제 등록된 서버 중 1대가 다운돼 서비스할 수 없게 돼도, 네임서버는 서버가 다운됐다는 사실을 인지하지 못한 채 그냥 해당 IP를 리턴한다.
이런 서비스를 제대로 수행하지 못하는 서버의 IP 주소를 넘겨받은 브라우저는 “서버를 찾을 수 없습니다”라는 메시지를 뿌릴 것이다. 역시 네임서버에 가상 IP 주소를 등록하고, 서버 팜의 앞단에 가상 IP 주소를 가진 4계층 스위치 등을 설치해 하나의 서버 팜에서 서버의 부하 등을 고려한 로드밸런싱을 추가적으로 한다면 피해갈 수도 있다.
또 한가지 단점은 서버에 대한 로드밸런싱이 정확하지 않다는 것이다. 실제로 사용자가 abc.co.kr의 도메인을 관장하는 네임서버로 직접 질의를 하기보다는 ISP가 운영하는 캐싱 네임서버에 질의하고, 캐싱 네임서버가 abc.co.kr의 도메인을 관장하는 네임서버로 질의하는데, 캐싱 주기에 따라 순서대로 해당 IP 주소를 캐싱한다. 그러므로 여러 사용자가 캐싱 주기 내에 네임서버로 질의하면, 실제 의도와는 다르게 동일한 IP 주소를 받게 되며, 네임서버가 리턴하는 주소가 정확히 1/n로 나뉘지 않게 된다.
일반적으로 이런 점을 피하기 위해 네임서버에서 캐싱 주기를 짧게 한다. 그러나 주기가 너무 짧으면 네임서버에 대한 질의가 많아져 부하문제가 발생하므로, 혹시나 있을 네임서버의 장애에도 대처해야 한다.
또한 서버의 부하 정도를 감안하지 않고, 순서대로 서버의 IP 주소를 리턴하기 때문에 부하가 있는 서버에 사용자가 몰릴 경우도 있을 수 있다.
ISP의 로컬 DNS 이용
그 다음으로 가능한 방법이 ISP가 운영하는 로컬 DNS를 이용하는 방법이다. (그림 1)은 사용자가 특정 홈페이지를 보기까지 일어나는 일련의 과정을 설명한 것이다.
이 방법은 실제로 서버에 접속하는 사용자가 어떤 방법으로 접속하느냐에 따라 서버를 할당할 수 있게 해준다. (그림 1)과 같이 사용자는 사용자가 속한 ISP의 캐싱 네임서버로부터 IP 주소를 리턴받는데, ISP의 캐싱 네임서버가 질의하는 권한 위임된 A-DNS는 캐싱 네임서버의 주소를 인식해, ISP에 근접한 서버 중 부하가 적은 서버를 판단해 IP 주소를 반환한다. 이로써 사용자는 가장 근접한 곳으로부터 서비스를 받을 수 있다.
이 방법은 처음에 설명한 DNS에 서버의 주소를 모두 등록하는 방법보다는 좀 더 지능적으로 사용자와 서버 사이의 병목을 줄일 수 있다. 많은 사용자를 보유한 ISP가 운영하는 IDC에 서버를 고루 배치해 서비스한다면, 많은 사용자에게 만족을 줄 수 있을 것이다.
최근 1000만 명을 넘어선 초고속 인터넷 서비스 사용자는 DHCP를 이용해 사용자의 IP와 네임서버 정보를 자동으로 할당받기 때문에, 사용자가 이용하는 캐싱 네임서버와 사용자는 동일 ISP에 속하게 된다. 이 ISP내에 서비스할 수 있는 서버가 존재하면, 실제로 사용자와 서비스 서버는 동일 ISP 내에 있기 때문에 미들마일 구간의 병목은 피할 수 있다.
일부 수동으로 네임서버를 설정할 수 있는 전용회선 사용자의 경우, 이용의 편의성 등 여러 가지 이유로 자신이 속한 ISP와는 다른 ISP에서 운영하는 네임서버를 잡는 경우가 종종 있어 사용자의 위치를 판단하는데 오류가 발생할 수도 있다. 하지만 이런 사용자는 극히 드물기 때문에 서버를 여러 ISP에 분산 배치해 서비스를 하는 경우에 보다 효율적이라 볼 수 있다.
HTTP 리다이렉션 이용 방식
(그림 1)에서 나타난 네임서버는 일반적으로 운영되는 서버들이며, 권한 위임된 네임서버가 추가적으로 들어가 있다. 권한 위임된 네임서버는 기본적으로 네임서버의 기능을 하면서 부가적으로 서버의 상태를 체크하고 있다가, 질의에 서버의 상태를 고려해 IP 주소를 리턴하는 역할을 한다. 또한 이 방법은 관련 솔루션이 시중에 많이 나와 있어 소스가 공개된 네임서버에 서버의 상태를 체크하는 부분만 추가 개발한다면 쉽게 운영할 수 있다.
또 다른 방법으로는 HTTP 리다이렉션 방식이 있다. 이름에서도 나타나듯이 http 프로토콜의 리다이렉션 방식을 이용하는 것으로, 기본적으로 http 방식에서만 이용할 수 있는데, 웹 서비스 뿐 아니라 다른 서비스에서도 응용할 부분이 많을 것으로 보인다. HTTP가 아닌 다른 서비스에 대해서는 뒤에서 다시 자세한 설명을 하겠다.
HTTP 리다이렉션은 HTTP 프로토콜의 기본 기능으로, 실제로 여러 웹 사이트에서 부분적으로 많이 이용되고 있다. 쉬운 예로 어떤 사이트에서 링크 주소를 클릭했는데, 브라우저의 주소 창에 바뀌어 나타난 주소가 링크 주소가 아니거나, 어떤 페이지에서 홈페이지 주소가 새롭게 변경됐다는 말과 함께 “5초 후에 자동으로 해당 사이트로 이동합니다”라는 메시지가 뜨고 실제 해당 사이트로 이동하는 것은 바로 이런 HTTP 리다이렉션을 이용한 예이다.
실제로 많은 사이트들은 HTTP 리다이렉션 기술을 글로벌 로드밸런싱용으로 적용하기보다는, 다른 목적을 위해 페이지를 강제 변경시킬 때 이용하는 것이 현실이다. 만일 이 기술을 글로벌 로드밸런싱하기 위해 모든 페이지의 모든 구성요소에 적용한다면, 어떤 일이 벌어질까.
실제 웹 서버에서 처리해야 하는 사용자의 요구와 동일한 수만큼 HTTP 리다이렉션을 수행해야 할 것이다. 실제로 HTTP 리다이렉션을 하는 데는 많은 부하와 처리 시간이 필요하지는 않다. 하지만 많은 수의 요구를 처리하기 위해 추가로 준비해야 하는 서버가 필요하고, 웹 컨텐츠와 같은 작은 크기의 데이터를 전송하는데 있어 HTTP 리다이렉션을 처리하는데 추가로 소요되는 시간까지 고려한다면 실익이 그리 크지 않을 것이다.
현재 나와있는 HTTP 리다이렉션 솔루션은 웹 서버에 적용되기보다는, 위에서 말한 다른 서비스와 관련된 것들이 대부분이다. 그렇다면 다른 서비스에는 무엇이 있을까.
먼저 웹 서비스에 응용하기 쉽지 않은 이유로 추가적인 서버를 필요로 하는 많은 요청 수와 추가적인 처리 시간을 들었다. 이런 것들을 피하도록 해주는 HTTP 리다이렉션을 필요로 하는 서비스로는 스트리밍 서비스가 가장 적합할 것이다.
스트리밍 서비스는 중간 단계에 HTTP 프로토콜을 이용한다. 웹 서비스만큼 서비스 요청이 많지 않은 스트리밍 서비스는 하나의 요청에 대해 서비스 시간이 길어서 HTTP 리다이렉션을 처리하는데 걸리는 시간이 상대적으로 무시해도 될 만큼 적다.
(그림 3)는 마이크로소프트의 윈도우 미디어 서비스를 제공하는데 글로벌 로드밸런싱을 적용한 예이다.
마이크로소프트 윈도우 미디어 서비스의 경우, 동영상 파일이 보통 mms 프로토콜을 이용하고, 확장자가 asf인 파일을 이용한다. 스트리밍 서비스를 하는데 있어 링크 주소를 mms://10.0.0.1/movie.asf라고 직접 이용하기도 하지만, 많은 경우 불법접속 차단이나 다양한 부가정보를 담기 위해 asx라고 불리는 메타 파일을 경유한다. 메타 파일을 이용하는 경우, http 프로토콜을 이용할 수가 있는데 이때 HTTP 리다이렉션의 적용이 가능하다.
사용자가 영화를 보기 위해 웹 페이지에서 http://asx.abc.co.kr /movie.asx의 링크 주소를 클릭하면, 일반적인 웹 접속과 마찬가지로 네임서버에서 asx.abc.co.kr의 주소를 받은 뒤 asx.abc.co.kr 서버에 서비스를 요청한다. 이때 asx.abc.co.kr 주소를 가진 ASX 생성기 서버는 실시간으로 요청받은 asx 파일을 생성한다.
ASX 생성기 서버가 생성하는 정보로는 제목, 저작권자, 저작자 등 플레이어에 표현될 수 있는 영화에 대한 정보와 실제 영화파일이 위치한 정보들이 있다. 보통 영화에 대한 정보는 생략돼도 서비스하는데 지장이 없지만, 영화 파일의 위치 정보는 필수적이다. 이런 정보를 실시간으로 생성하기 위해서는 영화에 대한 정보를 파일별로 외부에서 가져와야 하고, 또한 영화파일에 대한 위치 정보도 실시간으로 조회해 생성된다.
ASX 생성기 서버는 실제로 웹 서버이기 때문에 서비스를 요청한 사용자의 Referer를 이용해 IP 주소를 알아낼 수 있다. 또한 스트리밍 서비스를 하는 서버의 상태를 실시간으로 체크하고 있다가 서비스 요청이 들어오면 사용자의 IP 주소를 참고해 서비스 가능한 근접 서버 중에서 서버의 부하가 없는 서버의 주소를 이용해 asx 파일을 만들어 제공한다.
그러나 HTTP 리다이렉션을 이용해 스트리밍 서비스를 하는데 단점이 있다. 여러 음악 파일을 연이어 듣거나 영화를 시청하기 전에 광고 등 여러 개의 파일을 한번에 묶어서 스트리밍할 수 있는 기능을 할 때는 asx 파일에 여러 개의 파일 위치정보를 넣어주는데, 파일에 대한 부가정보는 한 번밖에 넣어줄 수 없기 때문에 각 음악이나 영화 파일에 대해서 부가정보를 나타낼 수가 없다. 이런 점은 마이크로소프트에서 제공하는 메타 파일의 포맷에 기인하는 것으로, 현재로서는 대안이 없다.
서버 할당의 근거가 서버의 부하 정도와 함께 로컬 DNS를 이용한 방식에서는 기준이 ISP에서 운영하는 로컬 네임서버인데 반해, HTTP 리다이렉션 방식은 사용자의 IP 주소가 된다. 사용자의 IP 주소를 근거로 사용자를 적절한 서버로 유도할 수 있게 된다. 따라서 사용자의 IP를 기반으로 다양한 부가 서비스를 제공할 수 있다.
정확한 글로벌 로드밸런싱을 위해서는 사용자의 IP 주소를 기반으로 서버를 할당하는 방법이 제일 좋다. 하지만 실제 HTTP 리다이렉션은 웹 서버 기반으로 부가적인 기능을 하는 것이다.
따라서 사용자의 IP 주소를 획득하는 방법은 웹 서버에서 인지할 수 있는 Referer 정보다. 하지만 실제 사용자에게 할당되는 IP 주소는 일부 ISP들이 운영하는 내부 네트워크에서는 공인 IP 주소가 아닌 사설 IP 주소를 이용하는 경우가 종종 있어, 100% 사용자의 IP 주소만으로 사용자를 구분하기는 어려움이 있다. 또한 HTTP 프로토콜의 리다이렉션 방식을 이용하기 때문에 HTTP 프로토콜을 이용하지 않는 다른 서비스에 적용하기 어려운 점이 있다. @
