로드밸런싱 방법의 종류 그리고 공간적 특징…

동시 접속자가 많은 사이트에서 IP 추적으로 알수 있는것은 로드 밸런서 IP 주소다.

동시 접속자가 많은 사이트의 경우는 서버 한대로 모든일을 처리 하지 못하므로 인하여 로드밸런서라는 부하를 분산하는 서버를 운영 한다.  로드밸런서라고 한다.. 보통 L4 스위치나  L7 스위치라 부르기도 하는데 ,  이는 네트워크 레이어에서 어떻게 트래픽을  분산하여 보내느냐에 따라서 부르기도 한다. 
– 요즘 클라우드 서비스가 대중화 되면서  L7에 의한 어플리케이션 스위치도 부하 분산에 사용된다.- 

이때 실제 알수 있는  IP는 겉으로 드러난 로드 밸런서의 아이피이고 내부에 어던 서버가 리얼 서버인지 알기는 쉽지 않다. 아래의 그림처럼 virtual ip address 와 리얼서버의 ip가 다른 경우.. 만일 서버가 같은 공간에 있지 않고 다른 공간에 있다면  로드 밸런서만 변경해서 다시 서비스를 가동 할수 있으므로 ,  그 서버의 운영을 중단 시키기는 쉽지 않기 때문이다. 

특히 클라우드 서비스를 이용하는 경우라면  대부분  L7  로드 밸런싱이라 같은 공간하에 있지도 않을 뿐더러
로드 밸런서의 사용자와 리얼서버의 사용자가 다른 경우라면 실제로 리얼 서버가 어디에 있는지 추적은 쉽지 않다. 

클라우드 서비스가 보편화 된 세상에서 부하분산 버츄얼 서버와 리얼서버가  위치가 다르기 때문에 실제 그  사이트 운영을  막는다는 것은,  실제로 들어나는 서버와 운영 되는 서버가 다르기 때문에 쉽지 않을 걸로 보인다. 

로드밸런서별 의 특성과  로드 밸런싱의  공간적 범주

리눅스 엔지니어의 기초 과정에  LVS (Linux Virtual Server) 과정이 들어 가는 걸로 알고 있다.  
대부분  그냥 수박 겉핧기 식으로 배우기 때문에 , 부하가 어떤게 많은가 적은가 . 이런 정도만 이야기하고 끝나는 걸로 알고 있다. 

로드 밸런싱  L4 네트워크 레이어에서 밸런싱 하는  NAT,  DIRECT ROUTING , IP TUNNELING , 그리고 어플리케이션 레벨의 – 쉽게 이야기 해서 프록시 서버를 이용해서 부하를 분산하는 L7이 있다.
여기서는 로드 밸런싱의 공간적인 특성에 대해서 다뤄 보도록 한다.

 NAT
기술적인 도큐먼트는 아래를 참고하기 바란다. http://www.linuxvirtualserver.org/VS-NAT.html

패킷 포워딩을+ 로드 밸런싱이라 이해하면 된다.
NAT 방식은  접속을 시도하는 클라이언트의   tcp/ip 패킷 헤더를 수정하여 리얼서버로 고르게 분산하여 패킷을 포워딩 한 뒤 , 리얼 서버에서 로드 밸런서로 돌아 오는 패킷을  다시 수정하여 접속을 이뢰한 클라이언트로 트래픽을  다시 되돌려 주는 경우의 부하 분산이다.
보통 레이어 2 네트워크에서 사용하여  Vlan  범주 이내에서 사용이 하나,  ip의 패킷헤드를 수정하여 부하를 분산하므로  GNAT(Gloval NAT)이라 하여  vlan 밖 아니 데이터 센터 밖으로 패킷을 전송할수도 있다. 

일반적으로 리얼서버에 어떠한 세팅을 하지 않고도 이용이 가능 하다는 점  가장 많이 사용하는 로드 밸런싱 방식이다.

실제 우리회사에서 직접 만들어  서비스하는 로드 밸런서의 경우  대부분 고객이  NAT방식으로 서비스를  이용하고 있고
대부분의 밴더사들이 판매하는  L4 스위치 여러가지 부하 분산 방식을 사용하나 DEFAULT는  NAT방식으로 서비스 한다.

또한  GNAT의 경우 데이타 센터 이전 작업시나  ddos 긴급 대피 서비스에서 가산 데이터 센터에서 분당 데이터센터로 패킷을 포워딩 하는 방식으로
리얼 서버의 공간적 이전 없이 네임서버에서 로드밸런서의  주소를 바꿔 주는 것 만으로 부하 분산이 가능 해진다.  

단점은 NAT – DENAT 과정이 필수로 필요하여 부하가 높다는 점 – tcp/ip  접속 세션을 로드 밸런서가 계속 물고 있어야 하고, 리얼서버에서 응답한 트래픽이 로드밸런서로 다시 몰려 들어 온뒤  DENAT 과정으로  IP 재 변환과정 이후 클라이언트로 돌려 보내야 하는 점으로 인하여,  로드 밸런서에  부하가 가중되는 점 (요즘은 서버가 좋아서 아웃바운드 1기가 정도는 끄덕 없다.).  데이타 센터를 넘나 들어 부하를 분산 할 경우 트래픽 비용이 이중으로 발생한 다는 점이다. 

 

Direct Routing
기술문서는 여기를 보라.  

http://www.linuxvirtualserver.org/VS-DRouting.html

NAT은 들어 오는  패킷  헤더를  수정하여 리얼 서버로 포워딩 하여 부하를 분산하는 방법이라면. 
Direct Routing은 VLAN 내에서만- 다시말해 MAC ADDRESS 의 브로드 캐스팅이 되는 공간적인 한계를 가진 부하 분산 방법이다. 
간단하게 말하면 VLAN 내에서 mac – IP 이용한  IP SPOOFING  방식을 이용한 부하 분산 방법이다.

VLAN 내에서 서버간 통신은 MAC – IP 매칭을 통해서 통신을 한다. 이를 이용해  로드 밸런서 들어오는 패킷에 대해서 DESTINATION 주소와 MAC을 임으로 지정하여  부하를 분산하고,  부하를 분산 받는 리얼서버에서는 그 응답을 받아서 일을 처리하고  클라이언트로  응답 패킷을 보낼때 서버는 클라이언트가 접속을 하고자 했던 로드밸런서 IP 로 속여서 (자신의 IP를 SPOOFING하여) 센션이 연결되고 통신이 이루어 지는 방식이다.
 

MAC ADDREESS가 브로드 캐스팅 되어야 하는 VLAN이라는 공간적인 한계가 있다.  한마디로  L3 스위치 이내의 공간을 넘어설수 없는 부하 분산이다. 
또한 서버 쪽에 IP SPOOFING할수 있는 모듈을 설치해야만 사용할수 있다. 리눅스 윈도우즈 서버 모두 기러한 모듈을 지원한다. 

이 로드밸런서는 NAT방식의 문제점인  접속 세션을 계속  연결한뒤  NAT- DENAT 과정이 필요 없으므로 부하가 거의 없다는 점과,  IN BOUND와 OUT BOUND가 분리 할수 있기 때문에 로드밸런서의 네트워크  성능 과 퍼포먼스의 한계를 뛰어 넘어  L3 스위치의 네트워크 퍼포먼스까지 트래픽 분산이 가능 하다.
다시말해 로드 밸런서는 1기가급이라면 스위치의 아웃바운드가  10기가 스위치라면  10기가의 트래픽 전송이 가능 하다.  
수십 수백대의 접속이 폭주하는 서비스,  CDN 이나 동영상등의 서비스에 대부분 다이렉트 라우팅을 사용한다.의

IP TUNNELING
IP TUNNELING 문서는 여기 http://www.linuxvirtualserver.org/VS-IPTunneling.html
아이피 터널링은  로드밸런서와 가상 서버간에  가상의 터널- VPN 컨셉과 유사하다- 을 만들어 그 터널을 통해  클라이언트의  세션과  패킷을  리얼서버로 전달하고,  
그 서버에서  클라이언트로 응답하는 내용이  로드밸런서로 돌아 오지 않고 바로 클라이언트로 전송 되는 방식이다.  한마디로  리얼서버가 클라이언트에 패킷을 보낼때 로드 밸런서라고 SPOOF 라고 하여 패킷을 전송 하는 방식이다. 

따라서  DIRECT ROUTING의 단점인  VLAN  밖으로의 패킷 전달이 가능 하다는 점이 장점이다.  심지어 다른 국가간  .  미국 에서 한국으로 미국에서 일본에 있는  데이타 센터로도 로드 밸런싱이 가능하며,   NAT 방식의 문제인 전송된 패킷이 DENAT을 위해 트래픽이 로드 밸런서로 회귀하여  로드밸런서의  부하를 가중 시키고,  데이타 센터를 회귀함으로 인해 발생하는  트래픽의 이중 과금이 발생하지 않는 장점이 있다.

단  이 방식의 문제점은 서버가 WINDOW 운영 체제인 경우는 지원 하지 않는 다는 점과,    데이타 센터간 국가간 다른 데이타 센터를  넘어서 로드 밸런싱을 할 경우 , 대부분 통신 사업자들이 타 회사 IP에  망관리상 배타적이기 때문에 .  망관리 혹은 데이타 센터 차원에서  보안 정책과  트래픽 관리 정책상  로드 밸런서의 IP가 자신들의  IP가 아닌 경우  패킷이 DROP 되는 경우가 대부분이다.  쉽게 말해   KT 목동 아이디씨 에  로드 밸런서가 있다면,  KT 목동 아이디씨나 분당아이디씨 영동 아이디씨로  아이피 터널링 방식으로 로드 밸런싱이 가능하나,  우리 아이디씨나 엘지 아이디씨로는 아이피 터널링이 불가능 하다.

그러나 그렇지 않은 망도 있다. 회선의 성격이 IX(EXCHANGE)인 경우  타사의  네트워크가 접속을 해서 트래픽을 나누어야 하는  사업모델이라  타사의 IP로도 로드 밸런싱이 가능 하다.  다시 말해 중국이나 일본에  로드 밸런서가 있거나 하고 리얼서버가 한국에 있는  한국 IX망을 이용하고 있다면 .. 그 IX 망을 이용해서는 IP tunneling 방식의  로드 밸런싱이 가능 하다는 점이다. 

이 방식이 클라우드 서비스에서 L7스위치가 다른 방식에 비해 퍼포먼스가 상대적으로 떨어 지는 경우, 상대적으로  L7에 비하여 부하에 강하여 데이타 센터 내에서 이 방식으로 부하 분산을 많이 이용 하고 있고, DDOS 공격이 심하던때,  공격 받던 리얼 서버를 감추고자 게임 서비스 들이나 성인물 서비스 들이 이 방법을 이용한 사례가 있다.

L7 APPLICATION BALANCER – PROXY 를 이용한 로드 밸런싱 

PROXY 서버를 이용하여 밸런싱  하는 방법이다.  
NAT 방식과 비슷해 보이나 패킷을 포워딩 하고 리플라이를 받아서 클라이언트에 다시 재 전송 해주는 방식이라면,   L7 은 프록시로 동작 하면서  밸런서가 서버에게는 클라이언트처럼 보이도록 작동하고,  클라이언트에는 서버처럼 대신하여 동작 하는 걸로 보이는 , 어플리케이션 영역에서의 동작을 한다.  따라서 NAT 방식은  DESTINATION 프로그램의 PORT와 상관 없이 무조건 적인 동작이 가능 하나- 포트 별로 별도의 밸런싱도 가능 하다- ,  L7은 특정 포트에  프록시 서버가 데몬 형태로 떠 있다가  그 포트로 들어오는 트래픽에 대해서 마치 서버 인것처럼 동작하여 트래픽을 받은뒤  서버에는 마치 클라이언트인 것처럼 동작을 하게 된다.

L7 프록시는  다양한 목적으로 쓰인다.

 가장 많이 쓰이는 곳은 웹 방화벽 룰셋과 같이 동작하는 하드웨어 웹방화벽이 그러하며,  또한  클라우드 서비스에서 로드 밸런서로 가장 많이 쓰이게 된다. 일반적으로 HAPROXY라는 오픈 소스가 L7 로드 밸런서로 가장 많이 사용 된다.

클라우드 서비스에서 L7 PROXY를 사용하는 이유는 현재까지  네트워크 가상화가 현재도 테스트 단계 수준인 경우가 많아,  클아우드 서버같이  아이피가 여러  VLAN을 넘어 서는 로드 밸런싱이 비일 비재 한 경우에  GNAT  IPTUNNELING 과 L7 PROXY 를 사용하여야 하는데  ,  GNAT 방식으로  밸런싱을 할경우 VLAN을 넘어가는 경우 접속자의 접속 아이피 정보를  서버로 전달하는 것이 불가능 한 문제,  IP TUNNELING은  윈도우즈 운영체제를 사용 할수 없는점 , 리얼 하드웨어의 퍼포먼스 가 필요한점 으로 인해 ,   
L7 PROXY가  어플리케이션 방식의 경우 패킷에 접속자의 정보를 넣어서 보낼수 있다는 점이 장점인 관계로,  NAT 방식에 비해서 퍼포먼스가 많이 떨어지지만,  클라우드 서비스에서 부하 분산에는 대부분 이 방법이사용 한다.

그러나 부하가 많아 지면 버벅 거리는 점이 가장 큰 단점이다.
실제 균일하고 안정적인  로드 밸런싱을 하려면,  결국 자체 서버를 구축하고 하드웨어 밸런서에 의한 NAT이나 DIRECT ROUTING  하는 것 이외에는 답이 없다.