티스토리 뷰

개발 노트/Network

L4 / L7 스위치와 로드밸런싱

오리지날초이 2013. 8. 29. 15:03


L4 스위치 

- vip 지정을 통한 Load Balance 및 Fail Over

- real ip 를 묶은 vip 로 향하는 트래픽은 RR 방식으로 로드밸런싱 된다.


L3 스위치

- src ip, dst ip 을 static routing 방식으로 밸런싱할수 있다.


Q) 라운드로빈 방식으로 밸런싱할때 패킷 구분은?

- 최소한의 패킷 단위로 밸런싱하는게 아니라, 세션기반으로 밸런싱 할 것이다.


Q) 미러링 받은 트래픽이라면?

- 미러링 트래픽의 경우 src 에서 보낸 packet 의 세션 구분은 해줄테고,

  dst 에서 보낸 응답용 packet 까지도 세션 구분되어 밸런싱 해줄 것이다.


위의 두가지는 기회가 될때 엔지니어에게 확인해보자


본문의 그림은 대부분 깨져있다. 그림을 보고 싶다면 아래 첨부 pdf 를 읽어보라



L4_L7 스위치의 개요.pdf


L4_L7 로드밸런싱의 해부.pdf






원본출처 : http://www.datanet.co.kr/news/articleList.html?page=11&total=270&sc_section_code=&sc_sub_section_code=S2N15&sc_serial_code=&sc_area=&sc_level=&sc_article_type=&sc_view_level=&sc_sdate=&sc_edate=&sc_serial_number=&sc_word=&sc_word2=&sc_andor=&sc_order_by=&view_type=



L4/L7 스위치①] L4/L7 스위치의 개요
 
로드밸런싱의 ‘꽃’, L4/L7 스위치 관심 집중
스위칭ㆍ패킷 필터링ㆍ미러링ㆍ보안 기능 결합 … 
초당 연결수ㆍ동시 연결수ㆍ처리용량이 성능 잣대 


L4/L7의 등장 배경

최근 다양한 기능과 성능을 보유한 이더넷 스위치들이 등장하고 있다. 이더넷 스위치의 발전 과정을 다양한 측면에서 바라볼 수 있으며 <그림 1>과 같이 대역폭(Bandwidth), 기능(Function), 지능(Intelligence)을 큰 축으로 발전하고 있다. 



<표1> OSI 주요 계층에 쓰이는 프로토콜
OSI 참고모델의
주요 계층
널리 쓰이는 프로토콜
레이어 2이더넷Ⅱ, IEEE802.3/802.2 SNAP, 네트웨어, 802.3 Raw
레이어 3IP, ARP, IPX, Non IP/IPX, IPv6
레이어 4TCP, UDP, ICMP
레이어5~7HTTP, SNMP, 텔넷, FTP, RTSP


대역폭 측면에서 이더넷 스위치는 초기의 CSMA-CD(10Mbps)방식에서 패스트 이더넷, 기가비트 이더넷, 10기가비트 이더넷으로 확장되고 있다. 한편 기능적 측면에서는 랜 안에서 네트워킹 유닛(호스트) 간에 물리적인 연결을 목적으로 했던 이더넷 L2 스위치는 지역망이 복잡해지고, 단일 랜 환경이 맨 영역으로 확대됨에 따라, 가상랜 QoS를 특징으로 하는 L3 스위치가 기업시장을 중심으로 광범위하게 사용되고 있다. 이더넷 스위치를 지능적인 측면에서 크게 OSI 참조 모델에 의한 7계층의 정의에 따라서, L2/L3/L4/L7 스위치로 구분이 가능하다.


레이어 4 스위치ㆍ로드밸런서의 차이

레이어 2 스위치는 OSI 참조 모델의 레이어 2 범주(이더넷 프로토콜 상에서 소스 MAC, 목적지 MAC)에서 패킷의 경로를 제어하고, 레이어 3 스위치는 OSI 참조 모델의 레이어 3 범주(TCP/IP 프로토콜 상에서는 소스 IP, 목적지 IP)에서 패킷의 경로를 제어한다.

레이어 4 스위치는 기존의 이더넷 레이어 2 스위치와 다른 차원이 스위치다. 레이어 4 스위치는 레이어 4 범주의 패킷을 분류하고 경로를 제어하는 것에서는 레이어 2 스위치 혹은 레이어 3 스위치와 동일하지만, 레이어 4 스위치의 독특한 기능은 레이어 4에서 발생하는 세션을 관리하고, 세션 관리를 위한 패킷도 조작한다는 것이다.

레이어 4 스위치의 기능은 벤더마다 조금씩 차이가 있을 수 있으나, 핵심 기능은 로드밸런싱 기능이다. 로드밸런싱 기능을 제공하는 제품군을 일반적으로 ‘로드밸런서’라고 부른다. 이런 차원에서 레이어 4 스위치는 로드밸런서의 한 제품 형태라고 할 수 있다. 로드밸런서의 제품들은 크게 서버 기반, 스위치 기반, 소프트웨어 기반의 제품으로 나눌 수 있다.

서버 기반 로드밸런서는 이더넷 카드를 여러 개 장착한 일반 서버형태로 구성되어 있다. 주된 기능은 범용 CPU상에서 포워딩 엔진으로 동작한다. 시중에는 F5 네트웍스의 BIG-IP, 코요테 포인트 이퀄라이저, 시스코의 로컬디렉터, 넷스케일러의 제품들이 있고 리눅스 오픈 프로젝트의 리눅스 버추얼 서버 프로젝트가 여기에 속한다.

소프트웨어 기반의 제품은 소위 클러스터링 소프트웨어로 분류할 수 있다. 별도의 각각의 서버에 클러스터링 모듈을 탑재해 트래픽을 분산하며, 다양한 트래픽 관리기능을 갖추는 것이 특징이다. 서버의 종류나 운영체제에 의존적인 면이 단점이다. 마이크로소프트 2000 서버의 클러스터링 서비스, 리소네이트(Resonate)의 제품들이 이에 속한다.

이에 반해 스위치 기반의 로드밸런서는 일반 L2/L3 스위치의 기능과 형태에 추가적으로 로드밸런싱이 더해진 형태이다. 이러한 형태의 스위치는 레이어 4의 기능을 전용으로 수행하기 위해 L2/L3 칩을 내장하면서 동시에 로드밸런싱을 고속으로 수행하기 위한 전용 엔진을 탑재하고 있으며, 전문적으로 로드밸런싱을 위한 ASIC을 장착하기도 한다. 시스코의 컨텐츠 서비스 스위치, 노텔의 알테온 웹 스위치, 파이오링크의 핑크박스 시리즈, 파운드리의 서버아이언 제품이 여기에 속한다.

역사적으로 L4 스위치의 모티브는 서버기반의 로드밸런서였다고 할 수 있으며, L4 스위치는 로드밸런싱 기능 이외에도 L2/L3 스위칭 기능 및 패킷 필터링, 미러링, 보안 등 다양한 기능들이 추가되고 있다.


L4/L7 스위치의 주요 기능

L4/L7 스위치의 주요 기능은 크게 다음과 같다.

  • 서버 로드밸런싱(SLB) 기능
  • 캐시 리다이렉션(CR) 기능
  • 방화벽/VPN 로드밸런싱(FWLB) 기능
  • 패킷 미러링/필터링 기능
    보안 기능

    이러한 기능들을 통해 L4 스위치는 인터넷 서버의 성능 확장, 서비스의 속도 개선, 인터넷 서비스의 안정성 향상, 인터넷 트래픽을 효율적으로 관리해야 하는 경우에 적용될 수 있다.

    SLB기능은 인터넷의 서버(웹서버, 파일 서버, 메일 서버 등)의 부하분산 기능을 말한다. 여러 대의 서버를 마치 하나의 서버(서버 팜)처럼 동작하게 함으로써, 인터넷 서버의 성능 및 안정성을 향상시킬 수 있다. SLB에 대한 기능은 다음 호에 자세히 다룬다.

    L4 스위치의 CR기능은 인터넷으로 급속한 확산으로 많이 사용되고 있는 캐싱 서버를 좀더 효율적으로 사용할 수 있게 하는 것이다. 캐시는 인터넷의 서버와 클라이언트 단에서 속도 향상과 왠 구간의 트래픽 감소을 위해 서버의 데이터를 일시적으로 저장하는 장치이다. 과거에 캐싱서버는 클라이언트 측면에서 프락시 형태로 동작했지만, L4 스위치를 사용해 ‘투명한’ 캐싱 서비스를 제공할 수 있다. 여기서 투명하다는 의미는 클라이언트단에서 웹브라우저에 아무런 설정 없이 캐싱 서비스를 제공받을 수 있다는 의미이다.

    L4 스위치의 FWLB기능은 방화벽이나 가상사설망(VPN) 게이트웨이 장비의 성능향상과 안정성향상을 위한 기능이다. VPN게이트웨이는 방화벽과 다른 장비로 분류되지만, 패킷의 흐름이 유사한 관계로 L4 스위치에서 FWLB기능으로 분류된다. 기존까지 VPN게이트웨이 장비를 로드밸런싱하는 경우는 VPN게이트웨이의 특성에 의해 기술적인 문제가 많았으나, 시장의 요구와 기술적인 문제의 해결로 인하여 점차로 보편화되고 있는 추세이다. VPN 장비의 로드밸런싱 기능을 위해서는 특별한 패킷 처리가 필요하다.


    L4/L7 스위치의 성능 지표

    L4/L7 스위치는 L2/L3 스위치로서 모두 동작할 수 있는 기능이 있지만, L4/L7 스위치의 가장 중요한 특징은 로드밸런싱 기능이라고 할 수 있다. 로드밸런싱 기능은 L2/L3 기능과 달리 국제 표준에 의해 정해진 기능이나 성능 지표가 없다.

    1. 초당 연결수(Connections per second)

    순수한 로드밸런싱의 성능을 나타낼 때, 시간당 얼마만큼의 TCP 트래픽(예, HTTP)을 처리할 수 있느냐가 중요한 지표이다. 하나의 TCP 연결은 클라이언트와 서버간의 쓰리-웨이 핸드쉐이크(three-way handshake) 동작(하나의 SYN과 두개의 ACK 패킷)으로 정의된다. 따라서 이 성능 지표는 제품에 따라 ‘초당 트랜잭션(transactions per second)’ 혹은 ‘초당 세션(sessions per second)’으로 불리기도 한다. 하나의 TCP 세션을 열고(opening) 닫는(closing) 작업은 L4 레벨의 기본 세션관리의 가장 핵심적인 동작이고, L4의 포워딩 엔진 부분에 가장 많은 작업량을 요구하는 작업이므로, 이 지표는 L4의 네트워크 프로세서 디바이스나 커널의 성능에 따라 좌우된다.

    시장에 출시된 제품들은 TCP 세션을 시간당 얼마나 성립(opening)할 수 있는지를 제시하고 있다. 따라서, 만약 세션을 닫는 동작까지를 고려할 경우 초당 연결 수를 계산하면 세션이 성립되는 경우의 초당 연결 수의 약 2분의 1이 나온다고 보면 된다.

    한편, 모든 로드밸런싱에서 초당 연결 수가 의미 있는 수치는 아니다. 예를 들어 SLB에서 UDP 패킷에 대해 초당 연결 수는 무의미한 값이다. UDP 패킷은 쓰리-웨이 핸드쉐이크 방식이 아니라, 커넥션리스(connection-less) 프로토콜이므로 단일 UDP패킷에 대하여 연결(connection)이 바로 성립된다. 따라서, UDP 프로토콜에 대한 로드밸런싱을 구축하는 경우에 초당 연결 수는 의미가 없다고 할 수 있다. 한편, FWLB에서는 초당 연결수 보다도 다음에 설명할 처리용량(throughput)이 더 중요한 성능 지표라고 할 수 있다.

    2. 동시 연결수(Concurrent connections)

    동시 연결수는 얼마나 많이 성립된 TCP 세션을 유지할 수 있는지에 대한 수치이다. 일반적으로, 하나의 TCP 세션이 열렸을 때, 바로 즉시 세션이 닫히는 것이 아니라, 사용자의 그 TCP 세션을 사용하고자 하는 시간동안 계속 세션을 유지를 하여야 한다. 특히, HTTP v1.1 프로토콜에서는 HTTP v1.0에 비해 TCP 세션하나를 지속적으로 사용하므로, 로드밸런서 장비는 성립된 TCP 세션을 되도록 오래 지속할 필요가 있다.

    동시 연결수는 L4 스위치의 네트워크 프로세스나 커널에 부착된 메모리의 양에 의존적이다. 시중에 출시된 L4 스위치가 제공하는 동시 연결수는 수천개에서 무제한(unlimitted)까지다. 특히, 무제한까지 지원한다는 의미는 이론적으로 메모리를 사용하지 않는 스테이트레스(state-less) 로드밸런싱 알고리즘(예, 해싱)을 적용할 경우이며, 현실적인 의미에서는 기타 네트워크 장벽(barrier)에 의해 동시 연결수는 제한될 수밖에 없다.

    한편, UDP 패킷에 대해 오해가 될 수 있는 점이 있다. UDP 패킷은 커넥션리스 프로토콜이므로 UDP 패킷을 로드밸런싱하는 경우에 동시 연결수와 연관이 없다라고 생각할 수 있으나 이는 잘못된 견해이다. UDP 패킷에 대한 세션 성립을 L4 스위치가 수행하지는 않지만, 상태를 기억해야 하는 로드밸런싱 알고리즘(예: 라운드 로빈, 리스트(least) 커넥션)을 사용하는 경우 각 UDP 패킷과 실제 서버의 연결정보를 기억해야 하므로 최대 연결 수는 TCP에서와 같이 중요한 지표라고 할 수 있다.


    3. 처리 용량(Throughput)

    시중에 출시된 많은 L4 스위치에서 ‘우리 제품의 스위칭 용량이 몇 Gbps, 혹은 수십 Gbps다’ 라는 사양을 제시한다. 이러한 사양은 고객이나 사용자에게 로드밸런싱(L4 레벨의 패킷 처리)을 수 기가 혹은 수십 기가에서 처리할 수 있다는 오해를 불러일으키기 쉽다. 스위칭 용량이 수 Gbps, 혹은 수십 Gbps라는 의미는 L4 스위치 내의 포트간에 패킷을 처리하는 L2 레벨의 패킷 처리 용량, 더 엄밀하게는 내부의 스위치 패브릭의 용량이 그렇다는 의미이지 L4 레벨의 모든 동작이 그 용량으로 처리된다는 것은 아니다. 정확한 L4의 용량은 이와는 별도로 제시되어야 함이 옳다. 일반적으로 L4 스위칭에 대한 처리 용량은 다양한 구성 및 경우에 따라서 다른 값을 나타낼 수 있으므로, 하나의 수치로 표현될 수 없다.

    다른 한편으로, 처리 용량은 각 스위치 장비가 지원하는 업링크(Uplink) 포트의 인터페이스 규격(패스트 이더넷, 기가비트 이더넷)에 제한된다고 할 수 있다. 예를 들어, 수 Gbps의 L2 스위칭 처리용량을 가지는 L4 스위치라고 하더라도, 업링크에 따라서, 최대 100Mbps, 1Gbps에 제한될 수밖에 없다. 이러한 제한점을 극복하기 위해서 업링크를 여러 개 트렁크해 사용하는 것이 제시 될 수 있으나, 일반적인 L2 레벨의 트렁킹(trunking)은 간단한 해싱함수에 의해 패킷을 분산시키므로 두개 이상의 업링크 포트를 효율적으로 사용할 수 없는 단점이 있다. 이러한 업링크 포트에 대한 성능의 제한을 극복하기 위해서 SLB의 구성에서는 DSR(Direct Server Return) 기술을 사용할 수 있는데, 이는 다음 호에서 자세히 설명하기로 한다.

    처리 용량을 나타내는 단위는 두 가지 형태로 생각할 수 있다. 하나는 bps(bit per second)이고, 또 하나는 pps(packet per second)이다. 여기서 패킷이란 이더넷 패킷을 대부분 지칭하고, 이더넷 패킷은 최소 40바이트에서 최대 사이즈는 1,500바이트가 일반적이다. 하나의 패킷은 바이트의 단위로 표현되고, 1바이트=8비트이므로, 아래의 수식으로 둘 사이의 관계를 표시할 수 있다.

    bps = (pps) x (패킷 사이즈) x (8)
    따라서, 처리용량을 pps로 제시할 경우는 패킷의 사이즈를 함께 제시하여야 정확한 bps의 처리용량을 계산할 수 있다. 반대로, bps로 처리용량을 제시할 경우는 처리에 사용되는 패킷의 길이를 제시해야 한다.

    예를 들어, 처리용량이 10,000pps라고 하면 10,000pps=10K×1.5Kbytes(MTU)×8bps=120 Mbps 이므로 최대로 처리할 수 있는 120bps의 이론값을 갖는다. 하지만, 실제 pps의 기준이 모호하므로 만약, 실제 환경에서 많이 전송되는 패킷 사이즈, 약 64바이트 패킷을 기준으로 한다면 10,000pps=10K×64바이트× 8bps=4.9Mbps이다. 이는 앞서 제시한 이론적인 최대치인 120Mbps와 큰 차이가 있다. 100Mbps 패스트 이더넷 인터페이스와 1Gbps 기가비트 이더넷 인터페이스를 100% 활용하는 경우에 각 패킷 사이즈에 따라, pps를 계산하면 <표 2>와 같다.

    <표2> 패킷 사이즈에 따른 PPS 계산
     64바이트128바이트512바이트1024바이트1500B바이트
    100Mbps204.8K102.4K25.6K12.8K8.7K
    1Gbps2048K1024K256K128K87.3K


    4. 임계치(Threshold)

    좀 더 현실적으로 어떠한 L4 스위치도 처리해야 하는 트래픽이 많아지거나 고급의 기능을 수행할 경우에는 처리속도가 급격히 떨어지는 현상이 발생할 수 있다. 만약, 어떤 L4 스위치가 L4 스위칭을 처리할 경우에는 아무런 지연현상(Latency) 없이 90Mbps로 패킷을 처리할 수 있지만, URL-파싱(parsing)이나 쿠키 기반 퍼시스턴스(cookie-based persistence)를 적용했을 경우 45Mbps 정도만을 처리할 수 있을 것이다. 이것은 위의 기능을 수행하기 위해 L5~L7 레이어 레벨에서 패킷을 더 조사하고, 조작하여야 하기 때문이다. 이러한 현상을 임계현상이라고 정의하고, 임계현상이 발생하는 처리용량을 임계치라고 한다. 예를 들면, HTTP의 리퀘스트에 대한 로드밸런싱을 어느 정도까지는 무난히 처리하다가, 어느 임계치를 넘으면 처리 속도가 현저히 떨어질 수 있다. 이러한 특성은 서버기반의 로드밸런서와 ASIC을 기반으로 하는 로드밸런서 모두에서 나타날 수 있다. 특별히, 서버기반의 로드밸런서에서는 L4의 처리를 중앙 CPU에서 처리하는 부분이 많으므로 선형적으로(linearly) 성능의 저하가 발생하는 경우가 많다. 반면에 분산처리 구조의 ASIC이나 전용 하드웨어 구조를 가진 L4 스위치는 처리용량이 큰 장점이 있으나 임계현상이 두드러지게 나타날 수 있다.

    최근에는 이러한 임계현상의 극복을 위해서 L4 기능뿐 아니라, L5~L7 기능을 성능저하나 지연현상(Latency) 없이 처리하기 위한 네트워크 프로세서 혹은 ASIC 개발에 주력하고 있다. 이러한 네트워크 프로세서 칩 개발 동향 및 L4/L7 스위치 구조에 대해서는 다음 호에서 자세히 설명한다. (
    http://www.datanet.co.kr/)
     
     

    [L4/L7 스위치②] L4/L7 스위치의 로드밸런싱 해부
     
     
    SLB 구성 방식

    서버 로드밸런싱 기능은 여러 대의 서버를 마치 하나의 서버처럼 동작시킴으로써 성능을 쉽게 확장하게 하고, 서버의 장애 발생시에도 타 서버로 운영이 가능하게 함으로써 신뢰성을 향상시키는 방법이다. 여러 대의 서버들을 리얼 서버(real server)라고 부르고, 리얼 서버의 집합을 클러스터(cluster) 혹은 가상 서버(virtual server)라고 부른다. 서버 로드밸런싱의 예는 <그림 1>과 같다.



    <그림 1>의 구성에서는 웹 서비스(HTTP, TCP 포트=80)와 이메일 서비스(S-MTP, TCP 포트=25)의 두 가지 종류에 대해 서버 로드밸런싱을 제공한다. SLB 구성방법은 설치 관점에 따라 여러 가지로 분류할 수 있다. 우선 네트워크 설정을 기준으로 브리지(bridge mode)방식과 라우팅(routing mode) 방식으로 나눌 수 있고 물리적인 포트 연결 차원에서 외팔 (one-armed) 방식과 양팔(two-armed ) 방식이 있다.

    브리지 방식은 가상 서버와 리얼 서버의 네트워크 대역이 동일한 경우를 말하며, 라우팅 방식은 두 네트워크 대역이 다른 경우를 의미한다. 예를 들어 <그림 1>에서 가상 서버의 IP(VIP)는 192.168.10.1/24 이고, 각각의 리얼서버는 동일한 192.168.10.x/24 (x=2,3,4)이다. 따라서 <그림 1>은 브리지 방식의 SLB이다.

    브리지 방식인 경우에는 외부의 고객이나 관리자가 가상 서버 및 리얼 서버로 직접적인 접속이 가능하다. 또한, 리얼 서버에서도 인터넷과 같은 외부망으로 접속이 가능하다. 브리지 방식은 관리의 편리성이 높인 반면에, 외부 보안에 취약하다는 것이 단점이다.

    <표1> SLB 분류
    기준
    세부 방식
    네트워크 설정
    브리지(bridge mode) 방식
    라우팅(routing mode) 방식
    포트 연결
    외팔(one-armed) 방식
    양팔(two-armed) 방식


    라우팅 방식에서는 가상 서버와 리얼 서버의 네트워크 대역이 다르다. 따라서, L4/L7 스위치는 양변의 네트워크 대역에 대한 게이트웨이 역할을 수행한다. 라우팅 방식에서는 리얼 서버들의 기본 게이트웨이 주소는 L4/L7 스위치 자신이 된다. 이러한 구성에서는 리얼 서버로 직접적인 접속을 막기 위해 사설 IP 대역을 많이 사용하고 있다. 외부에서 접속하기 위해서는 각 리얼 서버에 NAT를 수행한다. 라우팅 방식은 관리의 편리성이 낮은 반면에, 외부 보안에 강하다는 장점이 있다.



    포트연결을 기준으로 하는 분류에서 외팔 방식이란 SLB를 위해 L4에 연결되는 포트 구성이 한 개의 포트를 사용하는 경우를 말한다. <그림 1>에서는 두개의 포트를 사용하므로 양팔 방식으로 분류된다. 반면, <그림 2>는 외팔방식의 구성으로서 1개의 포트를 사용해 SLB를 수행한다. 일반적으로 외팔 방식과 양팔 방식의 데이터의 흐름은 차이가 없으며 몇 개의 포트를 사용하느냐가 관건이다. 한 개의 포트를 사용하더라도 내부적으로 가상적인 두개의 포트를 사용하는 것과 동일하다.

    DSR(Direct Server Return)

    DSR은 SLB의 변형적인 구성이다. 앞에서 설명한 SLB는 가상 서버의 IP(VIP)로 요청되는 패킷이 NAT 방식에 의해 리얼 서버의 IP로 변환되고, 응답 패킷은 반대로 리얼서버의 IP가 L4 스위치에 의해 VIP로 변환된다. 하지만, DSR에서는 이러한 NAT 방식을 취하지 않고, L3 레벨의 패킷 조작 없이 리얼 서버들로 패킷이 분산된다. 사전에 각각의 리얼 서버는 VIP의 인터페이스를 받을 수 있도록 설정되어 있어야 하며, 각각의 리얼 서버는 L4를 거치지 않고 직접(directly) 사용자에서 응답 패킷을 전달한다.

    DSR을 구성하기 위해서는 라우터 방식보다는 브리지 방식이 이치에 맞으며, 양팔 방식 보다는 외팔 방식이 더 단순하고 효과적이다. 특히, 양팔 방식인 경우에는 모든 패킷들이 L4 스위치를 통해 전달되는 오버헤드가 존재한다. 반면에 외팔 방식은 L2스위치를 거쳐 직접 외부망으로 전달되므로 L4의 부하를 줄일 수 있는 장점이 있다. 특히, 대규모 웹사이트에서 업링크의 트래픽이 많을 경우에 매우 유용하다고 할 수 있다.


    글로벌SLB(GSLB) 

    GSLB는 신뢰성과 인터넷 서비스 속도를 더 향상시키기 위해서, 네트워크 공간과 지역적 공간 모두에서 리얼 서버를 분산 배치해 이를 로드밸런싱 하는 기능을 말한다. 앞에서의 SLB는 엄밀한 의미에서 로컬 SLB라고 할 수 있다. 즉 단일 대역내에 있는 서버들에 대한 부하 분산만을 담당했기 때문이다. GSLB의 예는 <그림 3>과 같다. www.a.com이라는 사이트를 전세계 사용자가 접속하는 경우에 각 지역(아시아, 유럽, 미국)마다 로컬 SLB를 구축한다. 각 지역의 사용자가 서비스 요청을 했을 때, 지역적으로 가까이 있거나 응답속도가 빠른 쪽으로 서비스 요청을 분산시킨다.




    GSLB는 특정 도메인(예, www.a.com)으로 들어온 요청을 분산시키는 것이 주된 기능이고, DNS를 변형해 구성한다. DNS 기능은 기본적으로 도메인 네임에 대한 쿼리 요청에 대해 응답을 주기 때문에, 그 응답을 변형해 서비스 요청을 지역적으로 분산되어 있는 서버들로 전달할 수 있다.

    좀더 구체적으로, GSLB를 구현하는 방법은 GSLB장비 자체가 정식 DNS(Authoritative DNS)로 동작하는 방법과 DNS 프록시(proxy)로 동작하는 방법이 있다. 정식 DNS는 www.a.com에 대한 도메인 네임 쿼리 요청에 대해, 자체적인 로드밸런싱 알고리즘에 의해 가장 적합한 사이트(서울, 런던, 뉴욕)를 선택해 쿼리에 응답한다.

    DNS 프록시 방식은 내부에 리얼 정식 DNS 서버를 배치한 후, 외부에는 GSLB 장비 자신이 DNS 서버로 등록해 외부의 도메인 네임 쿼리 요청에 대하여 대리인 역할을 해주면서, 쿼리 응답 패킷을 가로채서 가장 적합한 사이트로 조작하는 방식이다. GSLB는 다국적 기업의 웹사이트나, 전세계를 대상으로 하는 e-커머스 사이트에 적합한 기술이라고 할 수 있으나, 국내에서도 천재지변으로 인한 백업 사이트 구축, 대단위 데이터 전송이 필요한 e-커머스에 필요한 기능이다. GSLB의 구축과 사이트 관리는 로컬 SLB에 비하여 복잡하고 어려운 것이 사실이다. 하지만, 신뢰성이 반드시 필요한 사이트와 전송 데이터의 양이 많은 인터넷 사이트가 확산됨에 따라서, CDN(Contents Delivery Networks)과 더불어 점차로 범용화되고 있다.

    캐시 리다이렉션(Cache Redirection)

    캐싱 리다이렉션 기능은 내부 망에서 외부 인터넷으로 향하는 웹(WWW) 트래픽을 가로채 캐싱 서버에게 전달하는 기능을 말한다. 내부의 호스트 컴퓨터는 캐싱 서버를 프락시로 등록할 필요가 없이 투명한(trapsparent) 방식으로 캐싱 서비스를 할 수 있다. 또한, 캐싱 리다이렉션을 통하여 웹 트래픽(TCP=80포트)만을 처리하기 때문에 캐싱 서버에서 불필요한 패킷 처리를 막아줘 응답속도를 빠르게 해 줄 수 있다.




    투명 캐싱 서버의 동작은 다음과 같다. 사용자의 웹 트래픽(URL 페이지) 요구는 L4 스위치에 의해 우선적으로 캐싱 서버에 보내진다. 해당 트래픽의 URL이 캐싱 서버에 저장되어 있으면(hit), 캐싱 서버가 즉시 응답해준다. 만약 캐싱 서버에 저장된 내용이 아니라면(missed) 캐싱 서버가 프락시로 동작해 해당 URL에서 페이지를 요청해 다시 사용자에게 전달하고, 캐싱 서버 자체에 저장한다.

    경우에 따라 RTSP(Real Time Sstreaming Protocol : TCP, UDP=554), NNTP(Net News Transfer Pr-otocol : TCP=119) 트래픽에 대해 그룹을 등록해 서비스 할 수 있다. 인터넷 트래픽 뿐 아니라 임의의 응용프로그램에 대해 포트 설정을 통해 리다이렉션 서비스를 구현할 수 있다.

    L4 스위치는 패킷 재전송(Packet Redirection) 기술에 기반하고 있다. 이 패킷 재전송 기술을 이용해 투명한 캐싱 서버 동작이 가능하며 또한, 로드밸런싱 기능을 통해 캐싱 서버들의 집합(서버군)을 관리하는 것이 가능하다. 이런 방법으로 하나의 L4 스위치에 캐싱 서버를 여러 대로 확장 할 수 있다.


    방화벽 부하 분산(FWLB)

    인터넷의 보안을 생각할 때 방화벽은 필수 사항이다. 그러나, 방화벽 한 대로 서비스를 제공할 경우, 단일오류지점(single point of failure)이 발생할 수 있다. 또한, 애플리케이션 수준의 프락시를 이용해 높은 보안 수준을 제공하기 위해서 많은 부하가 방화벽에 걸리게 되어 응답시간의 지연을 초래한다. 이러한 문제점들은 최근의 전자상거래 환경에서는 사업을 수행하는데 치명적인 걸림돌이 될 수 있다. FWLB의 목적은 크게 다음의 3가지로 요약할 수 있다.

    ■ 하나 이상의 방화벽을 추가해 가용성 및 성능을 향상시킨다.
    ■ 동적인 로드분산을 통해 응답속도를 향상시킨다.
    ■ 시스템 변경 없이 방화벽 확장 및 관리가 쉽도록 한다.


    FWLB를 구성하기 위해, 공인망(Public network)과 사설망(Private network) 사이에 2대의 L4 스위치(상위 L4 스위치, 하위 L4 스위치)를 배치한다. 상위 L4 스위치는 외부망에서 내부망으로 들어오는 패킷에 대한 부하 분산을 담당하며, 하위 L4 스위치는 내부망에서 외부망으로 나가는 패킷에 대한 부하 분산을 담당한다.

    FWLB의 중요한 특징 중 하나는 동일한 세션에 속하는 패킷들은 모두 동일한 방화벽으로 전송되어야 한다는 점이다. 각 방화벽은 세션의 상태정보를 통해 패킷 필터링을 수행하기 때문에, 현재 상태에 맞지않은 패킷이 들어올 경우 부적합한 패킷(illegal packet)으로 간주해 삭제하게 된다. 즉, L4 스위치에 의해 들어오고 나가는 패킷이 서로 다른 방화벽으로 전송되면 세션을 유지할 수 없게 된다. 따라서, 상위 L4 스위치와 하위 L4 스위치는 입출력되는 패킷의 경로를 기억해 경로를 지속적으로 유지할 수 있도록 한다.




    또한 DMZ 구간이 있는 경우에도 경로를 지속적으로 유지하기 위해여 DMZ 구간에 별도의 L4 스위치가 배치된다. <그림 5>는 위에서 설명한 일반적인 FWLB 구성이다.


    VPN 부하 분산(VPNLB)

    VPN 게이트웨이는 네트워크상의 배치와 패킷 흐름이 방화벽과 유사한 점이 많지만, 부하분산 입장에서는 매우 다른점이 존재한다. VPN 게이트웨이는 일반적으로 서버/클라이언트 개념으로 본점-본점간 혹은 본점-지점간의 배치되는데, 특히 본점-지점간의 구성이 일반적이다. 본점-지점 구성에서 본점으로의 터널링 접속은 지점단의 VPN 게이트웨이에서 접속하는 방법과 원격 엑세스 사용자(remote access users)에서 접속하는 방법이 있다. 어떤 경우이든, 본점에 접속하기 위해 사용하는 터널링 프로토콜은 IPSec, L2TP, PP2P 등이 있다. <그림 6>은 본점에 VPN 게이트웨이들에 대해 VPNLB를 구성한 예이다.



    해싱 알고리즘의 제한점

    방화벽은 패킷이 지나가는 경로에 배치돼 브리지 모드에서는 아무런 패킷의 조작 없이 그대로 전달한다. 반면, NAT를 수행하는 방화벽인 경우에 출발지 IP를 바꾸는 조작을 한다. 따라서, FWLB를 구성하는 경우에 목적지 IP에 대한 해싱(hashing)을 사용할 수 있으므로, 해싱 알고리즘이 많이 사용된다.

    VPNLB에서 해싱 알로리즘을 사용하는 것이 이론적으로 불가능하다. 왜냐하면, VPN 게이트웨이는 터널링 전과 터널링 후에 출발지 IP와 목적지 IP 모두 변경된다. 따라서, 상부 L4 스위치에서 암호화 패킷을 로드밸런싱 할 경우와 하부 L4 스위치에서 복호화 패킷을 로드밸런싱할 경우 일반적인 해싱 알고리즘을 사용할 수 없게 된다. 따라서, 이 경우에는 라우드 로빈(round-robin), 리스트 커넥션(least-connection), 웨이티드 알고리즘(weighted algorithm)을 써야 한다.

    본점-지점간 양방향 접속

    VPNLB에서는 일반적으로 지점에서 본점으로 터널링 접속을 시도한다. 하지만, 본점에서 지점으로 통신을 시도하는 응용(NMS, 지점관리)도 점차 증가하는 추세이다. 본점에서 지점으로 통신을 시도하는 경우에는 하단의 L4 스위치는 상부에 위치한 VPN 게이트웨이 VPN1, VPN2중 어느 게이트웨이와 해당 지점과 터널링이 맺어져 있는지 알아야 한다. 즉, 본점-지점간 양방향 접속이 가능하기 위해서는 L4 스위치와 VPN 게이트웨이 간에 터널링 정보를 공유해야 한다.


    네트워크 로드밸런싱(NLB)

    L4 스위치의 네트워크 부하 분산기능(NLB)은 다수의 인터넷 접속 라인을 사용해 네트워크의 속도와 안정성을 개선하기 위한 기능이다. NLB 기능은 기존에 L4 스위치에서 제공하는 기능은 아니었으나, 사용자의 요구에 의하여 점차로 확산되는 추세다. 제품으로는 파이오링크의 ‘파이오링크1508-NLB’, F5 네트웍스의 ‘링크 컨트롤러’, 라드웨어의 ‘링크프루프’, 팻파이프의 ‘팻파이프 엑스트림’ 등이 있다.

    하나의 ISP(Internet Service Provider)의 인터넷 접속라인을 사용할 경우, 실제 기업이나 학교의 인터넷 접속 환경에서는 아래와 같은 문제점들이 발생한다.

  • 네트워크의 속도가 느려 업무에 지장이 많다.
  • 네트워크의 다운으로 인한 인터넷 사용의 곤란 발생한다.
  • 네트워크 속도 업그레이드에 대한 경제적 부담이 가중한다.


  • <그림 7>은 내부망에서 인터넷을 사용하기 위해 ISP 1의 전용선 A, ISP 2의 전용선 B 및 케이블 라인, ISP 3의 ADSL 라인을 사용한 경우이다. 불필요한 트래픽으로 업무상 중요한 인터넷 사용에 지장이 발생한다.

    NLB는 L4 스위치를 이용해 여러 개 ISP들의 전용선들과 ADSL, 케이블모뎀 등의 초고속인터넷 회선을 결합시켜 단일한 전용선처럼 사용하게 한다. 또한 인터넷 트래픽을 효율적으로 관리하여 불필요한 특정 회선에 대한 트래픽 집중현상을 완화해, 트래픽 처리 효율을 최적화한다. NLB를 이용한 네트워크 구성은 <그림 7>과 같다.

    내부망의 IP 대역은 전용선 A의 IP대역과 전용선 B의 IP 대역을 동시에 사용하거나, 사설 IP대역을 설정해 PAT(Port Address Translation) 구성을 설정, 사용할 수 있다. 특히, 케이블 인터넷 라인이나 ADSL/VDSL 라인에서 할당된 IP가 적은 경우에 내부망이 PAT를 사용해 IP를 공유하도록 처리한다. 

    NLB에서 사용되는 부하 분산 방식에는 기존의 라운드 로빈, 해싱, 리스트 커넥션, 최대 응답 시간, 최대 대역폭 방식을 사용할 수 있다.

    <그림 8>은 E1 라인 하나만을 사용하는 회사에서 8Mbps ADSL 3개의 라인을 추가해 NLB 구성을 했을 때 대역폭의 증가율을 보여주고 있다.




    또한, NLB의 장점은 인터넷 회선의 고장율을 획기적으로 개선할 수 있다는 것이다. <그림 8>의 예에서 E1 라인과 서로 다른 ISP의 ADSL 라인 3개를 동시에 사용하는 경우에 ‘전용선은 한달에 한번 고장발생 확률, ADSL 초고속인터넷은 10일에 한번 고장한다’는 가정에서 고장율은 <표 2>와 같다고 할 수 있다. (www.dataNet.co.kr)

    <표2> NLB를 이용한 회선 고장율의 개선
    구분
    고장율
    비고
    NLB 적용 전(E1만 사용)
    1/30
    한달에 한번 고장발생
    NLB 적용 후(E1+1×ADSL)
    1/300
    1년에 한번 고장발생
    NLB 적용 후(E1+3×ADSL)
    1/30000
    82년에 한번 고장발생
     
     


     
    [L4/L7 스위치③] L4/L7 스위치의 미래
     
    지난 2회에 걸친 연재에서 L4 스위치의 등장배경, 개념 및 서버 로드밸런싱, 파이어월/VPN 로드밸런싱, 네트워크 로드밸런싱, 캐싱 서버 리다이렉션, 필터링 기능에 대해 알아봤다. 이번 호에는 L4 스위치를 넘어서 L7 스위치의 개념, 동작원리, 활용 방법 등을 살펴본다. 편집자


    L7 스위치 소개

    이제 IT 업종에 종사하는 사람들 중에서 스위치를 모른다고 하는 사람은 거의 없을 것이다. 스위치의 포트에 UTP 케이블을 연결해 LED에 불이 들어오고, 인터넷이 잘 연결되면 ‘아! 스위치가 잘 동작하는 구나’라고 생각하면 그만일 정도로 간편해졌기 때문이다.

    단순한 더미 이더넷 스위치나 언매니지드(Unmanaged) 기반의 100베이스-TX 스위칭 허브를 사용하는 독자라면 스위치가 아주 단순한 기능을 수행하는 장비라고 생각할 수 있다. 하지만, 좀더 IT계에서 네트워크 관리를 해본 사람이라면 자신이 사용하는 고급기능의 스위치에 대해 완벽히 알고 있다고 장담할 사람이 얼마나 될까? 매니지드(Managed) 기반의 L2 스위치만을 말하는 것은 아니다. 근래 들어 필수 불가결하게 업계에서 사용되는 L3/L4 스위치에 대해 그 다양한 기능과 사양(specification)을 온전히 이해하고 설정해 사용하는 사람은 흔치 않을 것이다.

    L7 스위치로는 탑레이어 ‘앱스위치’, 라드웨어의 ‘웹서버디렉터’, 노텔의 ‘에이스디렉터’, 파운드리의 ‘서버아이언’, F5의 ‘BIG/IP HA+컨트롤러’ 등이 나와 있다. 국내 L4/L7 스위치 관련 제품에는 파이오링크의 ‘핑크박스1000/2000’ 시리즈가 있다. 이와 같은 L7 스위치는 기능 및 목적 시장이 천차만별이다. 이미 다양한 자료를 통해 알려졌듯이 L7 스위치는 컨텐츠를 인지해 스위칭하는 장비이다. L7 스위치는 미션크리티컬한 응용프로그램들(포인트캐스트[Pointcast], ERP 애플리케이션, FTP, NFS, VoIP 관련, 화상회의)의 관리 및 제어에 필요한 솔루션이다. 하지만, L7 스위치에 대해 좀 더 정확한 의미를 이해하는 것이 L7 스위치 제품을 선택하고 사용하는데 도움이 될 것이다.


    L7 스위치의 개념

    L7 스위치란 위에서 언급했듯이 컨텐츠를 인지해 원하는 포트로 전달하는 스위치를 말한다. 하지만 ‘컨텐츠’와 ‘인지’ 라는 말은 매우 광범위하고 애매모호한 기술용어이며 이 두 단어가 L7 스위치의 모든 기능을 내포한다고 보기는 어렵다. 혹자는 L4 스위치와 구별해 OSI 7 참조모델을 참고하면서 L5~L7의 패킷 데이터 영역을 분석해 스위칭하는 장비라고 설명하기도 한다. 이러한 설명은 매우 효율적이고, 적당한 설명이라고 생각한다. 필자의 경험으로 L7 스위치를 한 문장으로 표현하는 것은 어렵다. 하지만 현재 상용되는 L7 스위치가 가져야 하는 기본 기능은 아래와 같다.

    - TCP/UDP 헤더 및 데이터의 일부를 분석하고 분류한다.
    - HTTP URL 기반의 패킷 스위칭 기능을 수행한다. 
    - 세션별, 유저별, 혹은 응용별 QoS 정책을 지정할 수 있다.
    - 응용프로그램 레벨의 로직 구성이 가능하다.

    L7 스위치는 L3/L4 스위치의 기능을 대부분 포용하며, 최상 레벨의 스위칭 기능을 제공하는 것은 사실이지만, L7 스위치에 대해 몇 가지 오해의 소지는 존재한다. 아래 몇 가지 오해의 유형을 적는다.

    - L7 스위치는 레이어 7 계층을 위한 스위치다.
    - L7 스위치란 URL 기반 스위치다.
    - L7 스위치는 모든 TCP/UDP 포트(0-65535)에 대한 인지가 가능하다.

    L7 스위치는 L7 계층만을 다루는 것은 아니다. 스위치로서 동작하기 위해 기본적인 L2, L3 스위치 기능을 포함하고, 부분적으로 L4 스위치 기능을 지원한다. 엄밀히 말하면 현재 상용화된 L7 스위치는 레이어 5의 세션 계층 스위칭 역할에 충실하다고 말할 수 있고, 모든 애플리케이션들의 세션을 분류할 수 있는 것은 아니다.

    한편, 현재 L7 스위치 장비는 웹 트래픽에 대한 패킷 구별 및 제어가 많은 부분을 차지하는 것이 사실이지만, L7 스위치 장비가 URL 만을 다루는 것 만은 아니다. 많은 응용 프로그램들은 멀티미디어 및 미션크리티컬한 데이터 전송을 위해 데이터를 가공하므로, 이러한 데이터에 대한 처리가 L7 스위치에 필요하다.

    또한, L7 스위치가 모든 TCP/UDP에 기반한 응용프로그램을 분류하고 제어할 수 있는 것은 아니다. 일반적으로 널리 알려진 포트인 FTP, NFS, H.323, RTP 등에서 세션 처리가 가능하지만, 순간적으로 사용하는 임시 포트들을 분석하는 것은 매우 제한적이다. 또한, L7 스위치에서 QoS 기능을 지원하지만, 전문 QoS 장비들(시타라 네트웍스의 ‘QoS웍스’, 패킷티어의 ‘패킷쉐이퍼’, 넷리얼리티의 ‘와이즈왠’)에서 제공하는 트래픽 쉐이핑(shaping), 레이트 컨트롤(rate control) 등과 동일시 해서는 안 된다. 물론, 차후에 L7 스위치는 QoS 기능을 기본으로 제공하게 될 것이다.


    L7 스위치의 동작원리

    L7 스위치의 동작은 개념적으로 매우 단순할 수도 있다. 하지만, 그 내부의 패킷에 대한 분류 및 제어는 매우 난해하며 정교한 기술이라고 할 수 있다. 따라서, 세계적으로도 L7 스위치는 이미 성숙된 기술이 아니라, 지속적으로 개선되어지고 있는 기술이라고 할 수 있다.

    L4 스위치에서는 L4 계층의 세션 단위(TCP 또는 UDP)로 부하분산을 수행한다. 단방향 프로토콜인 UDP를 제외하고, L4 계층의 가장 핵심적이며 광범위하게 쓰이는 프로토콜은 TCP이므로, L4 계층의 세션은 TCP 세션이라고 할 수 있다. 이러한 TCP 세션을 로드밸런싱하기 위해서는 처음 TCP 패킷을 받은 시점 즉, TCP SYN 패킷을 받은 시점에 즉시 리얼서버에 그 패킷을 할당하면 된다. TCP 세션이 성립되는 시점은 TCP SYN를 리얼 서버에서 받는 시점이 된다. 일단, 하나의 TCP 세션이 리얼서버에 할당되면 그 뒤의 모든 패킷들은 동일서버로 포워딩된다. 이러한 동작을 TCP 패킷의 흐름으로 표현하면 <그림 1>과 같다.



    <그림1> L4 스위치의 TCP 세션 관리


    <그림 1>과 같이 TCP SYN이 초기 시퀸스 번호(sequence number) 100으로 접속을 시도하면, L4 스위치는 서버1, 서버2 가운데 서버1 쪽으로 세션을 할당한다. 서버1은 TCP SYN의 응답으로 TCP SYN ACK를 전달한다. 이 패킷은 서버1에서 시작하는 시퀀스 번호 200과 확인 번호(ACK number) 101을 갖는다. 그 다음으로 클라이언트 측에서 ACK를 보냄으로써 클라이어트단과 서버1단 사이에 하나의 TCP 세션이 형성된다. 그 다음으로 클라이언트 단에서는 특정 응용(application)에 대한 요청정보(request data)를 보내고 받음으로써 응용계층에서의 데이터 전송이 가능하게 된다. 이러한 특정 응용의 요청으로는 HTTP, FTP, 텔넷, 이메일 정보 등이 될 수 있다.

    L7 스위칭 기능은 이러한 특정 응용데이터에 따라 패킷의 경로와 서버의 할당을 결정하는 기능이라고 할 수 있다. 즉, TCP SYN 패킷을 검사해 바로 서버로 할당하기 보다는 요청정보를 검사해 서버로 할당하도록 해야 한다. 이러한 컨텐츠 기반의 스위칭을 수행하기 위해서는 클라이언트와 서버단 사이에 TCP 세션을 형성을 잠시 보류할 필요가 있다.

    L7 스위칭을 담당하는 장비는 클라이언트와의 TCP 세션을 잠시 보류시킨 상태에서 특정 요청정보가 전송되어 왔을 때, 이를 기반으로 서버쪽과 TCP 세션을 중계하는 역할을 담당해야 한다. 이러한 기능을 딜레이드 바인딩(delayed binding) 기능, TCP 스플리싱(splicing) 기능 혹은 TCP 터미네이션(termination) 기능이라고 부른다. 딜레이드 바인딩 동작을 TCP 패킷의 흐름으로 표현하면 <그림 2>와 같다.



    <그림2> L7 스위치의 TCP 세션 관리


    <그림 2>에서 클라이언트의 TCP SYN에 대한 요청은 L7 스위치가 담당해 L7 스위치가 TCP 세션을 형성한다. 클라이언트는 요청 데이터를 보냈을 때, L7 스위치는 요청 데이터 정보를 참조해 리얼서버로 할당한다. L7 스위치는 할당된 리얼서버와 또 다른 TCP 세션을 형성하고 데이터를 중계한다. L7 스위치는 L4 스위치와 달리 L4 계층의 IP와 전송 포트를 변경하거나 치환할 뿐만 아니라, 클라이언트와 서버사이에 투명하게 시퀀스 번호를 맞춰 주어야 한다. 


    L7 스위치의 활용

    L7 스위칭의 기능은 컨텐츠 기반의 로드밸런싱과 세션처리를 통해 기존의 L4에서 제공하기 힘들었던 기능들을 수행할 수 있다. 예를 들어 <그림 3>을 살펴보자.



    <그림3> 메가프락시 문제


    <그림 3>을 살펴보면 아래의 사설망(192.168.1.0/24)에 있는 클라이언트들이 방화벽 혹은 NAT 장비를 통해 특정 웹사이트(www.a.com)에 접속을 시도하고 있다. 사설망의 클라이언트들은 인터넷을 사용하기 위해 NAT 장비에서 공인 IP(210.1.4.10)로 치환되어 인터넷상으로 전송된다. www.a.com의 웹사이트는 앞단에 L4 스위치가 있어 3대의 웹 서버가 서버 팜을 형성하고 있고, 로드밸런싱되고 있다고 가정하자. L4 스위치에서는 클라이언트 A,B,C에서 접속한 사용자에 대해는 서로 다른 서버들로 로드밸런싱을 하고 싶지만, L4 스위치는 클라이언트 A,B,C를 구별할 수 없고, 동일한 IP에서 접속을 시도하기 때문에 하나의 리얼 서버(서버1)로 TCP 세션을 유지하게 된다. 이러한 경우 서버1 쪽으로 트래픽이 많이 집중되어 부하분산의 효과가 감소하게 된다. 이것은 한 예에 불과하고, 실제로 다수의 인터넷 사용자들(초고속 인터넷 사용자들)이 프락시 서버를 통해 인터넷에 접속하는 경우 메가프락시(megaproxy) 문제 혹은 AOL 문제라고 부르는 현상에 의해 실질적인 로드밸런싱을 불가능하게 만들고 있다.


    ■ 쿠키 기반 연결지속성(cookie-based persistency)

    위와 같이 프락시를 통해 웹 서버에 접속을 시도하는 클라이언트나 무선 혹은 모바일 인터넷을 사용해 웹 서버에 접속을 시도하는 클라이언트들은 실제적은 자신의 IP가 NAT(network address translation) 되거나, 유동적으로 바뀔 수 있다. 이렇게 클라이언트의 IP 혹은 전송포트가 바뀌더라도 클라이언트와 웹 서버간에 세션 연결을 지속하는 방법에 HTTP의 쿠키(cookie) 정보를 이용할 수 있다.

    쿠키란 웹 서버에 의해 클라이언트를 제어하기 위해 HTTP 헤더에 덧붙여지는 오브젝트인데, 클라이언트가 데이터를 요청하였을 때, 웹 서버가 응답 정보 안에 해당 클라이언트에 고유한 쿠키값을 지정하게 된다. 예를 들어, 인터넷 상거래에서 ‘장바구니(shopping cart)’ 등이 각 사용자의 상거래정보 유지를 쿠키를 이용해 해결하고 있다.

    위의 메가프락시 문제에 대해 L7 스위칭을 사용하게 되면 좀더 정교한 클라이언트별 로드밸런싱을 수행할 수 있다. 즉, 쿠키를 이용하면 같은 IP를 가진 클라이언트에 대해 HTTP 헤더에 서로 다른 쿠키값(예; user=1, user=2)을 할당함으로써 서로 다른 서버로 로드밸런싱 하더라도 <그림 4>와 같이 세션의 연결지속성을 유지할 수 있다.



    <그림4> 쿠키 기반의 L7 스위칭 기법


    ■ 분리(URL partitioning) 기능

    L7 스위치를 도입함으로써 URL 기반으로 웹 서버를 분리해 웹 서비스가 가능하게 된다. <그림 5>는 특정 URL에 대해 특정 웹 서버가 처리할 수 있도록 L7 스위치를 사용하는 경우이다.


    <그림5> L7 스위치를 이용한 URL 스위칭


    <그림 5>의 default.asp와 같이 동적으로 변경되는 페이지는 서버1 웹 서버에 저장하고, image.jpg와 같은 정적인 html 텍스트나 이미지 등은 서버2에 저장해 웹 서버관리를 효율적으로 할 수 있다. 이렇게 서로 특성이 다른 웹 페이지를 별도로 관리하고 웹 서버에 특성을 조절함으로써 최대의 성능을 낼 수 있다. 이러한 기능은 특히 캐싱 서버의 리다이렉션이나 IDS서버의 로드밸런싱을 수행할 경우에 매우 효과적으로 웹 서버의 성능을 극대화 하는 방법을 제공한다.

    ■ 보안기능

    L7 스위치는 강력한 패킷 처리 능력과 인지능력을 통해 아래와 같은 보안기능을 제공할 수 있다.

    - 컨텐츠 기반 패킷 필터링
    - 안티바이러스 
    - 응용 레벨의 미러링

    컨텐츠 기반 패킷 필터링 기능은 최근 관심을 갖는 안티바이러스 기능을 위한 근간이 된다. 최근 들어 기승을 부리고 있는 님다, 코드레드, 새드마인드 IIS 등은 기존의 웜 바이러스가 전자 우편에 의해 확산되는 것에 반해 브라우저, 랜, 웹 서버 등을 통해 무차별적으로 전파되는 특성을 가지고 있어 네트워크와 서버의 성능에 심각한 문제를 발생시키고 있다. 각각의 바이러스는 독특한 패턴을 가지게 되는데, L7 스위치에서는 그 패턴 매칭을 통해 패킷을 분류하고 제어하게 된다.

    예를 들어 님다 바이러스는 ‘readme.exe’, ‘쪱.eml’, ‘root.exe’, ‘.ida?’, ‘cmd.exe’ 등 패턴들을 포함한다. L7 스위치에는 사전에 위와 같은 패턴을 미리 검사하게 하고, 패턴이 매칭되었을 경우 해당 패킷을 드롭(drop)하는 방법을 채용한다.

    하지만, L7 스위치의 안티바이러스 기능은 널리 알려진 웹 바이러스를 차단하는데 효과적일 수 있으나, 새롭게 등장하는 웹 바이러스에는 사전에 차단할 수 없다. 또한 이미 알려진 웹 바이러스라고 하더라도, 관리자가 패턴에 대해 미리 정책을 설정해야 하는 단점이 있다.

    결국, 안티바이러스 본연의 기능은 방화벽에서 지원하고, 지속적인 안티바이러스 정책을 업그레이드하는 것이 올바른 보안정책이라고 할 수 있다.

    애플리케이션별 미러링 기능은 IDS 서버를 통한 보안기능에 효율성과 보안성을 더 증대시킬 수 있다. IDS서버는 모든 패킷에 대한 추적을 수행하므로 서버기반에 CPU-인텐시브한 작업을 수행하므로, 일시에 패킷이 폭주할 경우 바이러스 및 DoS 공격에 대한 감지 능력을 상실 할 수 있다. 이때, L7 스위치의 애플리케이션별 미러링 기능을 통해 애플리케이션별로 IDS 서버를 부하 분산시켜 각 IDS에서 애플리케이션 별로 각종 바이러스 및 공격에 대한 추적 및 검색 기능을 더 강화 할 수 있다.


    L7 스위치의 중요 이슈

    ■ 구조적 측면

    L7 스위치는 기존의 L3/L4 스위치보다 성능이 우수하다라고 생각하는 경향이 있다. 일면 사실이기도 하지만, L7 스위치의 구조에 따라, 성능은 많은 차이를 나타낼 수 있다. 특히 L7 스위치는 CPU-인텐시브한 작업이 많기 때문에 처리 패턴과 정책에 따라 동일 스위치에서도 성능이 다를 수 있다. 이러한 문제는 일반 방화벽의 성능과 유사한 원리라고 할 수 있다.

    초기에 등장한 L7 스위치의 기능은 중앙 CPU에서 처리하는 구조였다. L4 스위치 업체들은 초기 L7 스위치에서 기존 하드웨어의 변경을 최소화해 L7기능을 부여했다 이러한 시스템에서 L7은 초라한 기능에 불과하였으나, 최근 새롭게 등장하는 L7 스위치 업체들은 장비를 ASIC화거나 포트마다 독립적인 CPU를 통해 L7 스위치 패킷 분류 및 포워딩을 수행하는 엔진을 탑재한다. ASIC화와 독립 CPU를 통해 L7 스위칭을 라인 스피드로 처리할 수 있게된 것이다.

    하지만, ASIC를 통해 얻은 이점도 있는 반면 포기하는 것도 있다. 일반적으로 L7 스위치를 ASIC화 하였을 때, L7 스위치 자체 기능 및 여타 기능에 유연성과 성능의 제약이 뒤따르기 마련이다. 메모리 부족과 페이로드에서 길이의 제한, 새롭게 등장하는 응용프로그램에 대한 지원 등이 걸림돌이 될 수 있다. 또한, 펌웨어의 업그레이드에도 제약이 될 수 있으므로, L7 스위치의 선택에 주의가 요구된다.

    근래에 네트워크 프로세서 칩 업체에서 패킷에 대한 L4/L7 분류화(classification)를 제공하는 칩을 판매하고 있으나, 아직 범용 네트워크 프로세서의 사용은 접근이 쉽지 않고, 투자비용도 적지 않은 편이다. 그렇기 때문에 네트워크 프로세서를 사용한 L7 스위치는 검증에 시간이 걸릴 것으로 보인다.

    또 한가지 네트워크 프로세서가 제어에 필요한 MAC 변환이나 NAT는 지원할 수 있지만, 컨텐츠 레벨의 파싱(parsing)이나 URL 탐색(search), 딜레이드 바인딩, TCP 터미네이션과 같은 CPU-인텐시브한 기능들을 온전히 구현하기 위해서 네트워크 프로세서가 능사가 아니라는 점을 명심해야 한다.

    ■ 기능적 측면

    <그림 6>을 통해 L7 스위치 또 다른 적용 가능성을 생각해 보자.



    <그림6> H.323 화상회의를 위한 프로토콜 분석


    <그림 6>은 H.323 프로토콜을 이용해 화상회의를 하는 예를 보여주고 있다. H.323은 2개의 TCP 세션 연결을 하는데, 하나는 콜 셋업(Q.931)이고 다른 하나는 콜 컨피그레이션(H.245)이다. 이어서, 적어도 8개의 UDP 스트림을 오디오/비디오 전송을 위해서 사용한다. 이러한 일련의 과정이 하나의 응용프로그램 수준에서 분류되기 위해서는 개별적인 프로토콜의 L7 스위칭 분류 뿐만이 아니라, 개별 프로토콜의 흐름을 기억하고 분류하는 흐름 분류(flow classification)가 필요할 것이다.


    L7 스위칭 기술의 파급 효과

    L7 스위치의 응용분야는 앞에서 언급했듯이, L4 스위치에서 진화된 기능으로서 SLB, CSLB, FWLB에 관리의 효율성 및 더욱 정교한 부하 분산등에 응용될 수 있다. 하지만, 이는 L7 스위치의 일부기능에 불과하다. L7 스위치는 사용자별/응용프로그램별 트래픽 관리, 보안을 위한 패킷 처리, 그리고, 과금 및 모니터링 분야에서 핵심장비로 자리 잡을 것이다. 하지만, 현재 상용화된 L7 스위치는 아직 못다 이룬 이러한 목표를 위해 전진하고 있다.

    L7 스위칭 기능은 단순히 L4/L7 스위치 장비에만 적용 가능한 기술이 아니고, 유사 제품 및 분야로 파급될 수 있는 기술이라고 할 수 있다. L7 스위칭 기술은 기가급 방화벽, 침입탐지시스템(IDS), 가상사설망(VPN) 장비, 그리고, 고급 캐싱 서버, 웹 서버, QoS 장비, CDN(Content Delivery Network) 장비, 트래픽 관리 장비 등을 망라하는 인터넷 액세스단 장비의 고성능화에 필수적이고 핵심적인 기술을 내포하고 있기 때문이다. 특히, 10기가비트 이더넷이 점차로 가시화되면서 스토리지 분야에서도 TCP 기반의 iSCSI를 채용하려는 움직임이 활발히 진행중이다.

    이러한 움직임은 매우 의미 있는 현상으로, 향후 IP 기반 스토리지 시장의 형성과 함께 TCP 세션을 실시간 고성능으로 처리할 수 있는 플랫폼에 대한 연구가 필요하다는 것을 시사한다. 그리고, 보안분야에서도 점점 더 지능화된 바이러스나 웸 메일을 기가급으로 처리하기 위한 기술, 사용자에게 직관적이며 라인스피드 성능을 제공하기 위한 안정된 QoS 기술, 캐싱 기술 등이 L7 스위칭 기술과 매우 밀접히 연관되어 있다.

  •  


    728x90
    반응형

    '개발 노트 > Network' 카테고리의 다른 글

    splitcap  (0) 2014.02.03
    editcap  (0) 2014.02.03
    네트워크 케이블 종류  (0) 2013.08.30
    시스템 모니터링을 위한 SNMP 설정하기  (1) 2013.07.23
    TCPDUMP 사용하기  (1) 2013.07.11
    공지사항
    최근에 올라온 글
    최근에 달린 댓글
    Total
    Today
    Yesterday
    «   2024/04   »
    1 2 3 4 5 6
    7 8 9 10 11 12 13
    14 15 16 17 18 19 20
    21 22 23 24 25 26 27
    28 29 30
    글 보관함