로드 밸런싱

로드밸런싱은 설계를 진행하면서 항상 직면하는 중요 요소 중 하나이다.

이번 프로젝트도 특성상 안들어갈리가 없다.

LBS(Load Balancing Service)를 구현하는 방식 가장 쉽고 일반적인 방식이 하드웨어적인 구현이다.

L4나 L7와 같은 장비를 서비스 앞단에 두고 VIP를 설정하여 내부 서버들에게 로드밸런싱 정책과 각 서버별 가중치(weight)값을 지정하는 형식으로 보통 설정하면 끝이다. 여기에 L7은 High 레이어 특성상 추가적으로 소프트웨어적인 제어가 가능하다. 

이정도면 일반적으로 쓰는데 지장이 없으나 이런 장비들은 대부분 고가이다.

요즘 많이 쓰는 cloud 기반의 서비스들도 부가 서비스 형태로 지원하긴 하나 서비스 이용료가 비싼 편이며,

현 프로젝트가 사용중인 cloud 서비스는 L4에서도 아주 제한적인 형태로만 제공하여 http와 https를 동시에 지원하지 못하며 public IP로만 설정이 가능한 상황이다.

여기에 기본적으로 동시 처리할 수 있는 세션수( 메모리와 CPU에 따라 가변적 )가 정해져 있는데 예전에 썼었던 Alteon 장비의 경우 동시 처리 세션이 20만 정도 되었었다. 이정도면 일반적인 서비스는 거의 무리가 없었으나, 가끔씩 트래픽이 폭주하거나 하면 장비가 비정상적인 상황을 맞이할때도 있는 경우가 종종 있었다.

이런 하드웨어 장비를 제외하면 선택지는 당연히 소프트웨어 적인 구성이다.

일반적으로 많이 쓰는 방식이 LVS( Linux Virtual Server )를 통한 LBS의 구축이다.

직접 설치해본적은 없으나, 생각보다 쉽게 설치가 가능하다.
( 관련하여 워낙 많은 자료들이 있어 굳이 열거하지 않음. 싫은 귀찮음.. -_-;; )

ipvsadm을 통한 VIP를 설정하여 가상으로 아이피를 할당후 로드밸런싱 설정을 할 수 있으며 상용 L4에 준하는 기능 설정이 가능하다.

L7정도의 제어가 필요하다면 haproxy를 활용하면 된다. 자세한것은 여기를 참조 ( http://blog.daum.net/sssssssim/3 )

어찌되었던 이 경우에도 GLSB와 같은 시스템이 있어야 어느 정도 완벽한 설정이 가능하다는 것은 한계.

다만, Active - Standby 형태로라도 구성이 가능한것은 장애 상황에 대비한 나름대로 괜찮은 선택인것 같다.

LVS로 Active - Standby 형태로 서버를 구성( 참조 링크 )하고, 여기에 접속해야할 서버를 구성해준다.

이후 LVS에 포함될 서버리스트를 구성하면 LBS가 적용된 시스템을 구축할 수 있다.

참고 : LBS 등은 세션관리가 중요하기 때문에 세션의 timeout이 정해져 있다. 이런 설정들을 통해서 ssh 터미널을 사용하거나, tcp 커넥션등을 사용하게 되면 설정에 따라 다르지만 짧게는 30초만에 접속이 끊어진다.