회사에서 웹서버를 한대 운영하고 있다고 가정하자. 동시접속자들의 계속적인 증가로 인한 서버의 응답력의 저하로 서버의 업그레이드를 고려하고 있다. 서버의 업그레이드만이 최선의 방법일까? CPU가 너무 느려서 사용자들의 요청을 제대로 처리할 수 없다거나 메모리의 부족으로 혹은 하드디스크의 느린 속도로 인해서 고민중이라면 서버의 업그레이드가 고민의 일부분은 해소할 수 있겠지만, 한대의 서버로만 완전한 해결책을 제시하기는 한계가 있기 마련이다.
다른 방법은 무엇일까? 당연히 서버를 중복해서 배치하는 것을 고려할 수 있다. 한대보다는 두대가 있어서 사용자들의 요청을 처리한다면 서버의 분산을 통해서 서버의 응답력은 분명히 향상을 가져올 수 있을 것이기 때문이다.
당신은 결국 웹서버 한대를 더 설치하기로 결정했다. 2대의 웹서버. 이들을 어떻게 구성하여야 최선의 선택이 될까? 이제 새로운 고민이 시작된다. 지금 현재 당신이 웹서버를 한대 더 추가하고자 하는데 정확한 필요성을 먼저 판단해 보라. 웹서버의 성능을 높여주기 위함인지, 아니면 한대의 서버가 다운되었을때 또 다른 웹서버를 통해서 계속 서비스를 할 수 있도록 하기 위함인지..
몇가지 방법이 있다. 막연하게 생각할 수 있는 한가지는 요즘 주변에서 심심찮게 들리는 "클러스터"를 생각할 지도 모르겠다. 클러스터는 훌륭한 솔루션인 것임에는 틀림없다. 하지만 좋은 솔루션인 만큼 요구조건도 상대적으로 까다로운 편인데, 몇가지 살펴본다면 Windows 2000에서 제공하는 클러스터로 구현하기 위해서는 OS가 Windows 2000 Advanced Server이상이어야 한다는 것이고, 물리적인 환경으로 보자면 같은 네트워크에 위치해 있어야 한다는 점 등의 제약사항을 들 수 있겠다. 또 다른 솔루션을 찾아보면 "로드밸런싱" 디바이스들을 들 수가 있겠지만 무엇보다 만만치 않은 비용이 들어가야 한다.
간단하게 구현할 수 있는 방법은 없을까? 그러한 관리자라면 DNS에서 한가지 방법을 찾을 수 있다. DNS로써 구현하는 방법은 완전한 솔루션은 아니지만 가장 손쉽고 경제적으로 클라이언트의 웹서버로의 요청을 분산시킬수 있는 방법을 제공한다.
DNS가 어떻게? 개념은 너무 단순하다. 웹서버가 아무리 잘 셋팅되어 있어도 DNS가 웹서버의 위치(IP Address)를 가르쳐 주지 않으면 클라이언트들은 웹서버에 접근할 수 없다. 웹서버가 두대라면? DNS가 클라이언트의 웹서버의 IP를 요청하는 쿼리를 받을때마다 2대의 웹서버를 번갈아가면서 가르쳐줄 수 있다면 당연히 클라이언트의 요청은 분산이 되지 않을까?
이러한 기능을 DNS의 라운드로빈(Round robin)기능이라고 하고 Windows 2000의 DNS서버는 기본적으로 라운드 로빈이 활성화되어 있다. 관리자는 적절하게 관리영역에 호스트레코드만 생성하여 주면 된다.
아래의 예제를 통해서 접근해 본다. <그림1>에서는 mscs.co.kr이라는 도메인에 www 레코드가 2개 생성되어 있고 각각 192.168.0.2와 192.168.0.3 이라는 IP Address가 설정되어 있음을 보여준다.
< 그림1. DNS호스트 레코드 생성 >
두대의 웹서버를 <그림1>과 같이 DNS레코드를 구성한다. 반드시 A레코드를 사용해야 한다. CNAME은 동일한 이름의 레코드를 여러개 구성할 수 없다.
이제 구성은 끝났다.
에게?? 벌써?? 위에서 얘기한바 있다. 가장 간단하게 구성할 수 있는 방법이라고. 기본적으로 Windows 2000의 DNS는 라운드 로빈이 활성화 되어 있다. 이제 이 DNS서버는 외부의 다른 DNS서버로부터 www.mscs.co.kr 레코드에 대한 요청을 받으면 192.168.0.2와 192.168.0.3 레코드를 동시에 응답하게 된다. 하지만 이 응답이 순서가 있어서 첫번째 DNS쿼리가 오면 192.168.0.2 192.168.0.3의 순서로 응답하고 두번째 DNS쿼리가 오면 이번에는 192.168.0.3 192.168.0.2의 순서로 응답해 준다. 결국 사용자들의 웹서버에 대한 요청은 2대의 서버로 분산되는 효과를 가지게 되는 것이다.
DNS서버의 등록정보를 살펴서 라운드 로빈 구성을 살펴보자.
<그림2. DNS서버 등록정보>
DNS관리콘솔의 왼쪽패널에서 DNS서버 이름을 마우스 오른쪽 클릭하여 '등록정보'를 연다.
< 그림3. DNS서버 등록정보 - 고급옵션>
등록정보의 고급옵션을 살펴보니 여러가지 옵션이 보이는데 '라운드 로빈 사용'이 체크되어 있는 것을 확인할 수 있다.
이러한 DNS라운드 로빈을 이용하여 사용자들의 웹서버로의 요청을 분산시키는 작업은 얼마든지 가능하지만 간단한 구현만큼 한가지 맹점을 가지고 있다.
당신이 관리하는 두대의 웹서버중에서 한대의 웹서버가 문제가 생겨서 다운되었다고 가정을 해 보자. 당연히 당신은 DNS서버의 레코드중에서 문제가 생긴 웹서버의 레코드를 삭제할 것이다. 그러고 나면 당신의 웹서버에 연결하고자 하는 사용자들중 일부는 웹서버를 찾지 못한다는 에러를 만나게 될 수 있다. 원인을 살펴보니 사용자들이 여전히 문제가 생겨서 DNS에서 제거한 레코드에 해당하는 웹서버를 찾아가고 있다는 것을 발견하게 되었다. 당연히 사용자들의 요청은 웹서버로 전달될 수가 없다.
무엇이 문제인가?
DNS서버는 기본적으로 '캐쉬'를 가지는데 한번 DNS서버간의 쿼리를 통해서 원하는 레코드의 정보를 얻으면 이것을 캐쉬에 저장하고 캐쉬의 TTL이 만료되기 전에는 다른 DNS서버로 새로운 쿼리를 던지지 않는다는데서 문제가 생기는 것이다.
예를 들어서 외부의 한 사용자가 천리안의 DNS를 사용하고 있다고 가정해 보겠다. 그 사용자는 웹브라우저를 실행시키고 http://www.mscs.co.kr 이라는 사이트에 접근을 시도했다. 당연히 천리안의 DNS에게 www.mscs.co.kr의 IP Address를 요청했을 것이고 천리안의 DNS서버는 mscs.co.kr의 DNS서버에게 www레코드를 요청하게 된다. mscs.co.kr의 DNS는 192.168.0.2와 192.168.0.3 이라는 2개의 레코드를 응답하게 되고 천리안의 DNS서버는 그 정보를 캐쉬에 저장한 다음 사용자에게 응답해 주게 된다. 그렇게 해서 사용자와 웹서버와의 통신은 잘 이루어지게 되는데...
mscs.co.kr의 웹서버중 192.168.0.2 IP Address를 가진 웹서버가 다운이 되었고 mscs.co.kr 관리자는 DNS서버의 192.168.0.2 레코드를 제거하게 된다.
하지만 천리안의 DNS를 사용하는 외부의 사용자가 다시 http://www.mscs.co.kr 에 접근을 시도하게 되면 천리안의 DNS서버는 사용자가 원하는 정보를 자신의 캐쉬에서 찾아서 응답하게 되고 결국 사용자는 현재 다운이 되어 네트워크에서 사라진 192.168.0.2 웹서버에 연결을 시도한다. 웹서버를 찾을 수 없다는 에러메시지를 받게 된다.
이러한 경우는 DNS의 성능을 위해서 제공되는 '캐쉬'가 거꾸로 좋지 않은 영향을 주는 결과를 낳고 말았다. www 레코드의 TTL값을 조정하여 캐쉬로 인한 문제를 최소화해 보자.
DNS서버에서 mscs.co.kr 영역의 SOA레코드를 편집하여 전체적인 TTL을 조정할 수도 있지만 예제에서는 특별히 www 레코드의 TTL만을 바꿔보도록 한다.
< 그림4. DNS관리콘솔 - 고급옵션>
DNS관리콘솔에서 보기-고급을 선택한다. 캐쉬된 레코드나 레코드별 TTL관리 등 추가작업을 할 수가 있게 된다.
< 그림5. www 레코드 TTL조정>
www레코드의 등록정보를 열고 TTL값을 기본값인 1시간을 지우고 0시간으로 바꿨다. 이제 이 DNS서버로부터 www 레코드를 얻은 상대방 DNS서버에서는 www.mscs.co.kr 레코드의 TTL이 0이므로 캐쉬를 하지 않고 항상 필요할 때마다 새롭게 DNS서버에 쿼리하게 될 것이다.
거듭 이야기하지만 DNS를 이용한 방법으로는 당신이 원하는 완벽한 솔루션이 될 수는 없다. TTL을 바꿔서 문제를 최소화시켜도 상대방 DNS서버에서 임의로 캐쉬값을 조절하는 경우도 있고 이 문제로 몇몇 ISP의 DNS같은 경우 24시간 길게는 며칠씩 캐쉬에 정보를 가지는 경우가 있어서 당신의 회사에서 DNS서버의 레코드를 변경했어도 그것이 전체 인터넷의 DNS서버까지 완전하게 반영되기까지는 수일이 걸리는 경우도 허다하기 때문이다.
그러한 문제로 인한 피해가 회사의 손실로 영향을 미칠수 있는 경우라면 당연히 NLBS를 구현하는 것이 올바른 선택일 것이다.
