IT_Server/etc.(related Server)

[펌] DNS라우팅을 이용한 부하분산

JJun ™ 2013. 4. 5. 16:29

 

 


 출처: http://www.javaservice.net/~java/bbs/read.cgi?b=consult&c=r_p&n=955677171


 

 

 

DNS는 Berkerly에서 만든 BIND라는 DNS를 통상 많이 사용합니다.
(BIND의 설치법은 "Linux/Unix"게시판에 있습니다.)


BIND의 zone 파일에 다음처럼 하나의 머신 도메인 명에

하나이상의 IP Address를 매핑시켜 보겠습니다.
-----------------------------------------
........
a.javaservice.net  IN A 210.220.251.96
                   IN A 210.220.251.95
                   IN A 210.220.251.94
........
-----------------------------------------
이제 어떻게 a.javaservice.net 이란 도메인에 대해 IP Address가 매핑된지

확인해볼까요.

javaservice:/var/named# nslookup a.javaservice.net
Server:  elim.net
Address:  203.239.130.1
Non-authoritative answer:
Name:    a.javaservice.net
Addresses:  210.220.251.94, 210.220.251.96, 210.220.251.95

94, 95, 96 이렇게 서로다른 IP어드레스가 같이 나옵니다.
이와 같이 하나의 도메인에 서로다른 IP가 매핑되어 있을 경우, BIND DNS 서버는
round-robin 방식으로 요청이 들어올 때 마다 돌아가며 IP 어드레스를 넘겨줍니다.

javaservice:/var/named# ping a.javaservice.net
PING a.javaservice.net (210.220.251.96) : 56(84) bytes of data.
64 bytes from 210.220.251.96: icmp_seq=0 ttl=255 time=0.1 ms
64 bytes from 210.220.251.96: icmp_seq=1 ttl=255 time=0.0 ms
--- a.javaservice.net ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 0.0/0.0/0.1 ms

javaservice:/var/named# ping a.javaservice.net
PING a.javaservice.net (210.220.251.95)  : 56(84) bytes of data.
64 bytes from 210.220.251.95: icmp_seq=0 ttl=255 time=0.4 ms
64 bytes from 210.220.251.95: icmp_seq=1 ttl=255 time=0.4 ms
--- a.javaservice.net ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max = 0.4/0.4/0.4 ms

javaservice:/var/named# ping a.javaservice.net
PING a.javaservice.net (210.220.251.94) : 56(84) bytes of data.
64 bytes from 210.220.251.94: icmp_seq=0 ttl=255 time=0.4 ms
64 bytes from 210.220.251.94: icmp_seq=1 ttl=255 time=0.4 ms
--- a.javaservice.net ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max = 0.4/0.4/0.4 ms
javaservice:/var/named#

지금 직접 자신의 PC에서 "ping a.javaservice.net" 을 여러번 수행해 보세요.
IP가 바뀌는 걸 확인할 수 있습니다.

이제 URL을 http://a.javaservice.net 을 브라우져를 죽였다 살리는 방법으로

여러번 호출해 보세요..."자바서비스넷", "다모타홈페이지", "넥스웹" 중

하나의 웹페이지가 뜰 겁니다.

문제는 IE든 Netscape든, 일단 한번 a.javaservice.net 이란 도메인에 IP가 한번
요청되면, 내부적으로 그 IP어드레스를 cache로 기억을 하고 있게 됩니다. 또다시
DNS서버에게 요청을 하지 않습니다. 결국, 같은 브라우져에서 일단 IP가 결정나면,
계속 같은 머신에게만 요청이 들어간다는 소리가 되지요...(이건 브라우져의 특성이죠)

지금은 제가 머신이 여러대가 없는 관계로, 같은 N/W망에 있는

"다모타", "넥스웹"이 연결이 되지만, 이 세대의 머신이 완전히 어플리케이션적으로

동일한 내용을 갖도록해 놓으면, 수많은 사람이 들이 http://a.javaservice.net 으로 들어 올 때,

서로 다른 세대의 머신으로 서비스를 하는 효과를 낼 수가 있다는 것이지요.
1000명이 들어올 경우, 이중 33%는 96번머신에, 33%는 95번머신에, 나머지 33%는
94번 머신에 접속해서 사용하고 있는 효과가 나겠죠.

물론 이것만 가지고도, 머신 여러대를 이용해 Load balance(부하분산)의 효과를
거둘수 있습니다.  그러나 엄격히 말하면 이건 Load balance가 아닙니다.

 

96번 머신에 접속된 333 명이 다른 사용자들보다 엄청나게 많은 작업을 할 수 있고,

대신 다른 머신은 텅텅 놀고 있을 수 있다는 거지요.

그러나 주의해야 할 제약 사항이 있습니다. 일반 html만 존재하는 컨텐트성의 자료나
Cookie를 이용하는 CGI는 문제가 없습니다. 하지만, 서블렛 엔진의 경우, session을
이용하는데, 중간에 머신의  IP가 변경된다면 session이 없는 머신과의 연결시
새로운 session이 열린다는 것입니다. 물론 하나의 브라우저에서 일단 한번 요청이
되면,계속 간은 IP로만 연결이 되기는 하지만 이것은 보장받을 수 있는 것인 아닙니다.
특히, 여러번의 호출로 단일의  트렌젝션이 이루어질 경우 문제가 심각해지겠죠.

결국, mission-critial한 어플리케이션을 사용할 경우는 단순히 이와 같은 DNS 라우팅을
이용하는 것은 위험하다는 소립니다.

Load-balance와 clustering에 관련한 부분은 (웹) 어플리케이션의 경우 대부분 제공되는
기능중 하나입니다. 내부적으로 어떠한 방식을 취하고 있는 지는 해당 어플리케이션
서버마다 다릅니다. BEA WebLogic, IBM WebSphere, SilverStream 등등 각각 고유한
방식으로 서로다른 머신을 이용해 머신별 혹은 어플리케이션별로 Load balance 기능을
구현하고 있습니다.

따라서 제품이 뭐냐에 따라 해당 문서를 참조하셔야 합니다.


------------------------------------------------------- 
  본 문서는 자유롭게 배포/복사 할 수 있으나 반드시
  이 문서의 저자에 대한 언급을 삭제하시면 안됩니다
================================================
  자바서비스넷 이원영
  E-mail: javaservice@hanmail.net
  PCS:019-310-7324
================================================