System Compleat.

Application Delivery Switch

Techs
정윤진 ( yjjeong@rsupport.co.kr )

최근 외산 스위치 시장의 트렌드를 보면 ( 물론 나는 유행에 무감각 하기 때문에 트렌드가 아닐 수도 있다. )  소위 어플리케이션 가속 스위치라는 것들이 잘 나가고 있다.  이런 스위치들은
기능이 좋은 스위치라 하기도 뭣하고, 포트가 많은 서버라기도 애매한 부분이 적지 않다.

이런 애매모호한 스위치들의 동작 형태를 보자면 몇가지가 있는데, 내가 살펴본 바로는 다음과 같다.

    -  기본적인 Layer 4 스위치 기능
    -  Reverse Proxy
    -  SSL 가속
    -  Compress  ( 주로 gzip )
    -  Memory Cache ( Contents Caching )
    -  Application Accelerator  ( 이건 벤더마다 다르고 룰도 복잡해서 아직 잘 모르겠다 )
    -  OS 는 BSD 나 Linux 계열을 주로 사용,  Traffic 처리용 ASIC 이 별도로 존재
   

이런 L7 계열의 스위치 중에 거의 대장급에 속하는 F5 의 Big-IP 제품군을 들여다 보면
( 잘나가니까 대장 ) 아~ 이게 이런거구나 하는 느낌이 팍 오실거다.

F5가 왜 잘나갈까 하고 나름 고민해 봤는데, 역시 iRule 을 사용한 각종 Customizing 이 관건이 아닐까 한다.  이 L7 이라는 놈을 잘 사용하면  별의 별짓을 다 할 수 있다.  쉽게 상상할 수 있는 스위치에 iptables 의 적용이라던가, DDoS 방어를 위한 패킷 제어 ( 물론 엣지레벨이지만 )
쿠키를 사용한 로드벨런싱 처리 등 갖가지 방법이 다 있지만, 이런 iRule 이나 iControl 에 대한 것은  http://devcentral.f5.com 을 참조 하시도록 하고.

문제는, 소위 말하는 L7 레벨의 뭔가를 하는 것들을 까보면, 가장 메리트가 있는 것은 Reverse Proxy 나 OpenSSL ASIC을 사용한 가속, 서버 부하 없이 .css 나  .js, .html 등과 같은 size 에 민감한 파일들의 압축 처리 정도가 아닐까 한다.

뭐 10M 가 회선 서비스 받으면서 이런거 고민 안해도 서비스는 잘 돌아가겠지만, 문제는 100M, 1G, 10G, 40G 등 회선 속도가 커지면서 생길 수 있는 내부의 모든 복잡한 구조의 웹서버들의
어떠한 수정도 없이, 최전선의 스위치에서 압축적용 해버림으로서 굉장한 트래픽의 절감 효과를 기대 할 수 있다는 것이다.  ( 그렇다고 이미지까지 압축 시도 하면.. ;; ) 

또한, Ram Cache 의 기능을 사용해 보면, 별도의 이미지 서버를 위한 서버 Farm 을 구축할 필요가 없을 정도로 잘 동작한다.  물론 메모리의 소비 비용이 있지만, 자주 사용 되는 이미지들의 전체 크기가 2G 를 넘지 않는다면 충분히 매력적이다.

SSL 가속의 경우에는, 스위치 자체에 인증서를 박아 버림으로서 모든 고민이 끝난다.

이러한 여러가지를 적용했을때의 효과는, 첫째로 트래픽의 절감, 둘째로 서버의 부하 감소의
두가지 효과가 크다.  실제 Reverse Proxing 을 사용하고 Connection profile 을 One connect 를 사용하면,  서버 앞단에서 일종의 Connection Manager 처럼 동작하며, 실제 서버와의 연결은 지정된 몇개의 EST 커넥션을 통해 처리하기 때문에 서버레벨에서의 TCP 3way handshake 를 위한 오버헤드가 전혀 없다.  더불어 만약 아파치를 사용 중이라면 ( mpm type 이 prefork 던 worker 이건 무엇이건 간에 ) 새로운 클라이언트를 위한 mutex 처리 및 기타 등등의 오버헤드가 싹 사라지기 때문에 아주 매력적인 것이다.

또하나는, http 헤더를 조작하는데 있다.  이 http 헤더를 조작함으로서 얻어질 수 있는 잇점은
더 말할 나위도 없지만, 각 contents type 에 따른 client cache expire 의 지정이라던가
문제 발생시 특정 uri 에 대한 redirection 처리 등은 서버에 대한 고민없이 바로 적용가능 하겠다.

추가기능으로 Active - Active 를 사용 할 수 있다는 것도 장점이다.  국내 환경이나, 대부분의 경우 안정성을 위하여 Active - Standby 구조를 적용하는것이 많지만, 국내의 경우 IDC 에서
받는 회선이 보통 IDC 의 L3를 거쳐 L2 레벨 아니면 L3 레벨 정도로 국한 되기 때문에  실제 그런 구조를 도입하려면 IDC의 담당자와 머리짜야 하지만, 일본이나 미국의 경우 BGP 레벨로 서비스를 해 주는 경우가 많기 때문에,  필요한 경우 Active - Active Routing 옵션을 구매해서
IDC 와 우리 라우터 2대간 BGP 로 구성하고, 이 아래에 Big-IP 를 물려주면 가능하리라 생각 된다.


와 죽이네 당장 사야겠네 하며 장점만 있냐 라고 물으신다면 대답은 No 이다.  이러한 무수한 좋은 장점도 있지만, 일단 가격이 비싸다.
물론 Cisco 에 비할 바 아니지만, 6000급의 모델을 가져가려면 대당  한화로 4천만원은 우습다.
거기에 위에 설명한 모든 기능을 옵션으로 붙이자면,  옵션당 천만원씩은 더 내도 된다.

둘째로, 잘 알려지진 않았지만  일부 iRule 에 대한 Bug다.  Recommand 된 iRule 이나
devecentral 등에서 검증 받지 못한 iRule 및 iControl 등을 Customize 하게 되면, 예기치 못한 장애에 휘말릴 수 있다.

돈있고 장비 빠방한 회사에 근무한다면 뭐 좋지만,  돈없고 맨날 사람 고생하는 회사라면
nginx + 적당한 load balancer 정도를 생각 해 볼 수 있다.  핵심기능은 모두 구현해 주기 때문에,  돈이 아쉽거나, 또는 너무너무 많은 종류의 서버들이 너무너무 많아서  이런 기능을 많이 구현해야 하는데, 장비값이 너무 비싸서 고민이라면 제일 좋은 선택인 것이다.

이런 L7 을 수십대 두어야 하는 경우 nginx 로 대체하고  여기에 인건비 쓰는게 남는거다.
물론, 장애를 대비한 구조는 미리 설계를 해 두어야 한다.


웹 가속에 대한 방법이나 종류는 너무 많다.  조금만 구글링을 해 보면, 정보는 도처에 널려있고 비교적 베타 테스트가 많은 시스템 관련 직종 사람들의 경우, 조금만 시간을 투자하면 어떤 구성이 합리적인지 잘 알수 있으며, 예상 가능한 장애 리스트도 뽑아 볼 수 있겠다.

물론 Nginx 를 사용하면 SSL 가속이 아쉽지만,  이런 SSL 가속이 들러붙은 NIC 도 존재하니
꼭 필요하다면 한대 정도 사서 테스트 해 보는것도 좋은 방법이겠다.


어떻게 시스템을 구성하던 자유겠지만, 잘못된 구성으로 인한 책임은 고스란히 본인 몫이 된다.
상용과 오픈소스 솔루션에 대한 선택은, 결국 장비값이냐 인건비냐 의 싸움이므로  우리같은
3D 직종 사람들은 경영자에게 두가지 방법이 있다 제안만 하면 되지 않겠는가.


다음에는, SSL Accelerator 에 대해 테스트 해 봐야 겠다.
못참고 궁금하신 분들을 위해, 링크는 먼저 걸어 둘까나. 이런게 있다 라는 것정도?

http://www.cavium.com/pdfFiles/OCTEON_Plus_XL%20NIC%20PB_v1.pdf
이 제품이 검증된 제품이 아니라는걸 굳이 말해야 할 필요가 있는지 모르겠지만 -