이번 주제는 ‘애플리케이션 스위치 제대로 알기’다. 잘 알고 있는 것 같으면서도 막상 잘 모르는 것이 L4~7 스위치로 통용되는 애플리케이션 스위치다. 이번 기고는 애플리케이션 스위치에 대한 진실과 오해를 짚고 넘어가야 될 필요성이 있어서 마련됐다. 지난호 애플리케이션 스위치의 전신인 로드 밸런서 탄생 이야기에 이어 그간 궁금했던 벤더별 애플리케이션 스위치에 대해 상세히 살펴보자.<편집자>

 

 

최성열 시스코 APAC ANS CSE
sungchoi@cisco.com

첫 번째 이야기가 조금 식상하고, 다 알고 있는 이야기라고요. 그렇다면, 이제 본격적인 애플리케이션 스위치로 넘어가 두 번째 이야기는 어떤 애플리케이션 스위치들이 있는지 살펴보도록 하겠습니다.

아마 현장에 계신 분들은 알테온, 시스코, F5, 파운드리(브로케이드로 인수), 라드웨어(지난해 초 알테온 인수), 시트릭스(넷스케일러 인수) 등의 외국 기업과 국내 업체로 선전하고 있는 파이오링크, 펌킨네트웍스 등을 꼽을 겁니다. 그리고 최근에 파운드리 출신의 핵심기술자들이 나와서 설립한 A10을 들 수 있습니다. 아마 이쪽 일을 안 하시는 분들은 이들 중 유명한 몇 개 업체만 들어보셨을 겁니다.

이 외에도 스위치 회사인 익스트림이 써밋(Summit) 시리즈 뒤에 i를 붙인 모데로 로드 밸런싱 기능을 지원한 적이 있습니다. 또 간혹 코요테포인트, 어레이네트웍스라는 외국 회사도 들어 볼 수 있고, 미리텍이라는 국내 기업도 있습니다. 물론 그 이외에 다른 업체들도 많이 있습니다. 흔히 이야기하는 로드 밸런서(Load Balancer) 전문이라고 하면 앞서 언급한 회사들이 대표적이라고 보면 됩니다.

현재는 스위치 형태의 로드 밸런서가 대다수로, 일반적으로 로드 밸런서는 ‘소프트웨어 기반, 서버 기반, 스위치 기반’의 3가지 형태로 나눌 수 있습니다. 어떤 자료에는 ‘DNS 기반, 소프트웨어 기반, 하드웨어 기반’이라고 분류하는 경우도 있습니다. 하지만 이러한 분류는 이해를 돕고자 하는 것이지 ‘어떤 방식이 좋다’라는 식으로 접근하면 안 됩니다.

우리가 흔히 L4~7 스위치라고 많이 하는데, 이건 국내에 처음 로드 밸런서를 유행시킨 알테온과 파운드리가 기본적으로 스위치 형태의 모양을 가지고 있었기 때문입니다. 하지만 오랜 동안 수많은 검색을 통해 알아낸 건 ‘F5’가 아무래도 최초에 가까운 회사고, 이 회사 제품들은 오랫동안 서버 기반이었습니다. 그리고 시스코의 첫 번째 로드 밸런서라는 로컬 디렉터(LocalDirector)도 서버 타입이었습니다.

따라서 정확히 말하자면 ‘로드 밸런서’라고 부르는 게 맞을 것 같습니다. 외국에서는 이러한 용어가 익숙하지만 국내에서는 L4 또는 L7 스위치라는 스위치 형태를 강조하기 때문에 세계 시장 점유율 1위인 F5도 과거 포트가 2~4개 있는 BIG-IP라는 제품으로는 국내 사업을 접을 수밖에 없을 만큼 어려움을 겪었습니다. 그러나 지금은 F5의 모든 제품들이 스위치 형태를 띠고 있어 스위치 기반으로 불리고, 몇 년 전 국내 지사를 다시 설립하고 적극적인 영업에 나서고 있습니다.
 
소프트웨어 기반 로드 밸런서
소프트웨어 기반은 말 그대로 전용장비가 있는것이 아니고, 해당 소프트웨어를 범용서버에 설치하는 타입입니다.

<그림 1>을 보면 스케줄러(Scheduler)라고 하는 것이 우리가 알고 있는 로드 밸런서입니다. 이 스케줄러가 VIP(Virtual IP)를 가지게 됩니다.(DNS에 등록돼 있겠죠) 그리고 사용자 접속이 올 경우 콘텐츠 서버라고 하는 실제 서버로 전달하게 됩니다. 백업 스케줄러라는 것은 액티브-스탠바이(Active-Standby)처럼 액티브 스케줄러가 다운될 경우 서비스를 계속하기 위해서 존재합니다. 또 <그림 1>을 보면 서버들이 모두 비슷하게 생겼는데 일반적인 플랫폼에 올라가게 됩니다. 그래서 모든 성능은 스케줄러가 올라가는 서버의 성능에 따라 차이가 납니다. 레조네이트의 자료를 보니 다음과 같네요.

■ 플랫폼: 썬 SPARC CPU 라인, 인텔 CPU 패밀리, AMD CPU 패밀리, IBM 파워PC
■ 운영체제(OS): 썬 솔라리스, MS 윈도우 서버, 리눅스, AIX

여기서 중요한 건 콘텐츠 서버입니다. 서버는 어떤 종류든 상관이 없고, 로드 밸런싱을 하는 것만 앞서 언급한 기준을 따릅니다. 서비스를 하는 서버는 일반적인 L4처럼 OS나 소프트웨어를 특별히 따지지 않습니다.
스톤소프트(www.stonesoft.com)라는 회사도 있었는데, 요즘은 방화벽, IPS, VPN 등 보안 솔루션에 집중하는 것 같네요. 또한 리눅스의 LVS(www.linuxvirtualserver.org/software/index.html)나 MS의 클러스터링(msdn.microsoft.com/en-us/library/ms978730.aspx)도 여기에 포함된다고 할 수 있습니다. 이 외에도 인터넷 검색을 하면 좀 더 많이 있습니다. 인터넷 검색 시에는 구글에서 ‘software based load balancer’라고 하면 됩니다.

대부분의 소프트웨어 기반 제품들은 하드웨어를 가리지 않아 가격에서 자유로울 수 있는 반면 아무래도 소프트웨어 기반은 전용 장비에 올라간 서버/스위치 기반보다는 하드웨어를 자유롭게 선택하더라도 성능에서 제약사항이 많을 수 있으며, OS 문제도 감당해야 할 부분입니다. 그리고 대부분의 소프트웨어 기반 제품들은 서버 로드 밸런싱 기능을 가지고 있지 방화벽 로드 밸런싱 같은 네트워크 입장에서 복잡한 구성에는 고려되지 않습니다.
 
서버 기반 로드 밸런서
서버 기반은 보통 로드 밸런서를 하드웨어 타입으로 판매를 하고, 성능별로 A, B, C 시리즈 형태로 구분됩니다. 가장 큰 특징 중 하나는 바로 포트 수가 클라이언트 사이드 1개, 서버 사이드 1개, 이렇게 해서 2개에서 이중화를 위한 포트까지 4개를 제공하는 경우가 많습니다. 다시 말하면 내부 서버를 연결하려면 L2 스위치를 둬야 하는 구조라고 볼 수 있습니다.

성능별로 장비 시리즈가 3개라면, 아마 이렇게 나눌 수 있겠네요. 100M 포트를 가지면서 성능이 100M 미만, 1G 포트를 가지면서 성능이 1G 미만, 10G 포트를 가지면서 성능이 몇G 정도. 어떤 것들이 있었는지 한번 볼까요. 설명을 아무리 해도 한번 보는 게 제일 낫겠죠. 잘 보면 1U, 2U 서버처럼 생겼는데, 벤더의 디자인을 가지고 있습니다. 그리고 흔히 알고 있는 스위치처럼 포트 수가 8, 12, 24, 48개 이렇게 있는 것이 아니고, 2~4개로 돼 있는 게 특징입니다.

그렇다면 OS는 어떨까요. 보통 이런 제품들의 특징은 리눅스, FreeBSD 등과 같은 범용의 무료 OS를 하드웨어에 맞게 최적화해서 사용했었습니다. 왜 과거형을 이냐구요. <그림 2>에 소개된 모델들은 현재는 모두 판매되지 않기 때문이죠. 그렇다고 OS가 특별히 바뀐 게 아니라 외부 형태가 스위치를 내부적으로 연결한 구조로 바뀌었습니다. 그건 아래서 다시 이야기하도록 하죠. 암튼 로드 밸런싱을 해야 할 서버들이 여러 대(2대를 쓰는 곳도 있지만)기 때문에 ‘클라이언트-로드밸런서-서버’ 이런 구조에서 반드시 L2 스위치가 필요합니다.

과거에는 사용할 서버만큼 포트 수를 제공하는 스위치를 구하기 쉽지 않았는데, 고객들은 당연히 포트 수가 많은 스위치가 최고로 생각했습니다. 심지어 로드 밸런싱이 돼야 할 서버가 로드 밸런서에 직접 연결돼야 한다고 생각하는 고객들도 있었죠. 이러면 숨이 턱턱 막혀 왔습니다. 그러나 직접 연결되지 않고 L2 스위치를 거쳐서, 때로는 라우팅 구간에 있어서 다른 네트워크에 존재해도 가능합니다. 포트가 몇 개 더 있으면 좋겠지만 그게 앞서 언급한 이유에서라니. 그렇게 고객은 업체의 농간에 놀아난 게 아닐까 생각됩니다.

하지만 지금도 업체간 경쟁을 할 때 뭘 가지고 하는지 아시나요. 여전히 포트 수 몇 개 이상, 이러고 있습니다. 어떤 한 업체가 먼저 우위를 차지하면 그냥 그걸로 밀고 나갑니다. 부디 이런 걸 안 했으면 좋겠습니다.(물론 저도 예전엔 그랬는데, 그건 정말 중요한 게 아니었습니다. 이제라도 이런 식으로 제품 경쟁을 하면 안 됩니다.)

결국 포트 수는 가격이 돼 버렸습니다. 그러나 포트 수만이 아니라 이것저것 검토할 게 많은데, 정작 중요한 걸 보지 못하게 됩니다. 포트가 필요하면 저가의 L2 스위치를 구매하면 됩니다. 포트 수 때문에 가격을 높이는 건 아닙니다.

초기의 서버 기반은 상당부분 서버에 올라간 OS 커널이 중요했던 것 같습니다. CPU는 우리가 알고 있는 랙형 서버가 쓰듯이 인텔 x86 CPU를 쓰는 구조가 대부분이었습니다. 여기서 중요한 건 다음에서 설명할 스위치 기반은 인텔 x86을 쓰는 제품과 NP(Network Processor)라고 불리는 다른 CPU(인텔 IXP, 캐비움 옥테온, 브로드컴 등)를 쓴다는 겁니다. 어떤 프로세서를 쓰느냐가 중요한 문제지만 로드 밸런서의 경우는 라우터/스위치와 달리 보다 복잡한 동작을 하기 때문에 그것을 얼마나 제대로 구현했는가 또한 중요합니다. 또 프로세서의 종류에 따라 기능, 성능, 확장의 문제를 안고 있는 경우도 있습니다.

스위치 기반 로드 밸런서
보통 스위치 기반의 애플리케이션 스위치들은 외형만으로는 L4인지, L2/3 스위치인지 구분이 어렵습니다. 그나마 구분할 수 있는 방법은 크게 두 가지인 것 같습니다. 저처럼 경험이 있어서 브랜드와 모델명을 보고 알거나 디자인을 잘 살펴보면 L2/3 스위치에 비해 신경을 보다 더 쓴 티가 난다는 사실을 알 수 있습니다.(L2/3 보다 훨씬 비싸기 때문에 똑같이 보이면 안 되니까. 비싸게 산 옷이 싼 티가 난다면 누가 사겠습니까.)

다음 <그림 4>를 보시죠. L2/3 스위치 같죠. 정말 이쪽(상위계층 스위치) 일을 안 하시는 분들은 이게 뭐야 할 겁니다. 일단 모양을 봐서 알겠지만 스위치처럼 생긴 것들이 많습니다. 그래도 L2/3 스위치와 차이나는 외형적인 특징은 포트 수가 그렇게 많지 않다는 겁니다.

●● 1~2U에서 섀시형 까지
제품들을 자세히 보면 보통은 1~2U 정도의 크기들이 많습니다. 일부 벤더들은 백본 형태의 섀시형 스위치(시스코, 브로케이드) 모양을 가지고 있는 경우도 있습니다. F5도 완전 섀시라기보다는 블레이드 섀시 형태로 탑재되는 비프리온(Viprion)을 출시했습니다. 아무래도 전통적인 섀시 형태보다는 포트 수의 자유로움(원하는 라인카드 마음대로 선택 할 수 있는)에서 차이가 나겠지요.

시스코나 브로케이드 이외에도 지금은 어바이어에 인수됐지만 노텔이 알테온을 인수한 이후 패스포트라는 백본 스위치에 탑재되는 WSM(Web Switching Module) 모듈을 개발해 시스코의 CSM(Content Switch Module), ACE(Application Control Engine)처럼 꽂는 형태를 가졌었습니다. 그러나 품질 문제로 인해 현재는 사용되지 않는다고 보면 됩니다.

우리나라에서 정말 강세를 보였던 알테온이 예전에 700 시리즈라는 섀시 형태를 만들었지만 고생을 많이 했습니다. 알테온의 아성(거의 베스트셀러 수준)은 AD3, 184 시리즈를 거쳐 <그림 4>에 있는 AAS 시리즈로 이어진 것이라고 보는 게 정확할 겁니다.

그럼 섀시 형태의 제품인 시스코와 브로케이드의 차이는 뭘까요. 시스코는 베스트셀러인 C6500 스위치와 7600 라우터에 추가적으로 CSM을 꽂는 형태로 지원을 했고, 현재는 ACE라는 모듈이 추가된 형태입니다. 브로케이드는 서버아이언(ServerIron)이라는 제품으로 섀시 형태지만 L4~7 기반으로 만든 제품입니다.

그러면 L2/3 스위치와 디자인하고 가격만 차이가 나냐구요. L4~7이 장난도 아닌데 그렇게 만들지는 않지요. 그냥 하나의 칩에서 다하면 되지 뭘 그리 복잡하게 하냐고 생각할 수도 있겠지만 보통 로드 밸런서는 L2/3 하드웨어 형태의 칩을 직접 제공하는 방식이 아니라는 점을 먼저 알아야 합니다. 즉, L2/3 처리를 하는 칩에 별도의 L4~7을 처리하는 CPU를 쓰는 형태를 많이 사용한다는 거죠. 그림으로 그리면 <그림 5>처럼 됩니다.

물론 모두 다 이런 구조는 아닙니다. 그러나 대부분의 장비들은 매니지먼트와 실제 로드 밸런싱 패킷을 처리하는 부분을 분리하고 있습니다. 그렇지 않은 경우도 있기 때문에 그냥 참고만 하세요.

●● L2/3 칩
모든 L4~7 스위치 전문회사들이 L2/7 스위치 전문회사는 아니기 때문에 보통은 기가 포트 몇 개, 10G 몇 개를 구현하기 위해서는 전문회사 제품을 사용하는 게 보다 효율적입니다. 현재 브로드컴(www.broadcom.com/products/ Enterprise-Networking)의 칩을 많이 사용하는데 웹사이트에 가보면 다양한 종류의 칩들이 나와 있습니다.

이런 칩들을 이용해 기본적인 스위칭에 필요한 칩을 자신들의 모델에 맞게끔 설계하게 됩니다. 이왕 만들 거면 특정 포트(예를 들면 10G 포트 몇 개)가 더 많으면 좋겠다고 생각할 수도 있는데, 10G 포트를 L4~7쪽 엔진과도 써야 하기 때문에 외부에 보이는 포트는 제약이 있을 수 있습니다. 여튼 해당 스위치 칩을 써서 내부에 필요한 용도로 몇 개, 그리고 외부로 몇 개 이런 식으로 만듭니다.

참, L2/3 칩을 쓰더라도 이 부분에서 모든 동작이 이뤄지는 것은 아닙니다. 흔히 로드 밸런서가 L3 라우팅을 풀 와이어로 지원하지 못하는 경우는 로드 밸런싱 설정이 있는 트래픽들이 항상 위에 있는 엔진을 거쳐야 하기 때문으로, 하드웨어 측면에서 와이어로 지원한다는 건 어폐가 있을 수 있습니다. 물론 L4지만 L3 동작만 한다면 하드웨어 기반의 L3 칩에서 다 할 수도 있겠죠. 벤더들 마다 차이는 있을 수 있답니다.

●● 매니지먼트
예전에는 많은 장비들이(아직도 있을 수 있고) 로드 밸런싱을 하는 패킷과 장비 관리(설정, 모니터링, 로그, HA)나 서버 상태를 체크하는 헬스 체크(Health Check) 등을 하나의 CPU에서 처리했습니다. 그러나 고속의 처리를 요하는 경우와 이런 패킷들로 인해 장비 관리가 흔들리거나 장비 관리의 부하 및 문제로 패킷 처리에 영향을 미쳐 현재는 분리된 구조가 많습니다. 실제로 필드에서 보니 이런 제품들이 많이 쓰이고 있더군요.
 
●● L4/7 엔진
L4/7 엔진은 별도의 OS를 가진 모듈이라고 생각하면 맞습니다. 외부에서 봐서는 하나의 OS지만 동작 자체가 다르기 때문에 별도로 진행된다고 보면 됩니다. 그래서 보통 CPU+메모리와 같은 형태로 돼 있고, 여기에 사용하는 CPU는 매니지먼트와 같이 인텔 x86부터 다양한 네트워크 프로세서를 사용합니다.

어떤 방식이 더 좋은지 질문을 하지만 저는 이건 중요하지 않다고 생각합니다. 치명적인 버그를 가지고 있는 게 아니라면 벤더의 제품 특성에 맞게 안정적으로 개발하는 게 더 중요합니다.(개발자들한테 이런 이야기하면 혼납니다. 왜냐면 장비 안의 칩들이 어떤 특성을 가지고 있는지 잘 모르기 때문이죠. 하지만 고객 입장에서는 내부에 사용된 어떤 것이 중요한 게 아니라 실제 그 장비가 고객이 원하거나 스펙에 나와 있는 성능을 최대한 발휘할 수 있느냐가 중요하다고 봅니다.)

L4/7 엔진에서는 로드 밸런싱을 합니다. 그리고 매니지먼트나 L2/3 칩과 긴밀하게 동작해 서버 상태나 세션 정보, MAC 러닝(MAC learning), ARP 정보들도 관리해 완벽한 동작을 하게 합니다. 보통 장비의 성능은 여기서 판가름 난다고 보면 됩니다.
 
●● 추가카드(SSL, 가속, 보안)
벤더별로 장비의 스펙을 잘 보면 하드웨어 구현이라는 경우가 있는데, 일반적으로 L4~7 관련 동작은 상당히 많은 변화를 요구하기 때문에 순수 ASIC만으로 모든 걸 구현하기는 어렵습니다. 크게 변하지 않을 정보만 하드웨어적으로 구현하는 경우도 있겠지만 보통의 하드웨어적 구현이라고 하면 SSL 가속, 웹 가속, 인스펙션(Inspection) 칩 등의 전문회사 장비를 사용합니다.

아시겠지만 이 또한 어려운 동작이라 이걸 자체 개발하는 건 비효율적입니다. 따라서 이미 구현이 완료된 검증된 카드 형태를 써서 연결하는 형태를 많이 취합니다. SSL 카드가 몇 TPS를 쓴다고 한다면, 이건 벤더의 특정 기술 때문보다는 채택한 카드가 그만큼 지원하기 때문입니다. 가끔은 벤더들이 똑같은 카드를 쓰는 경우도 있답니다. 어, 잠깐만요. 마토가 궁금한 게 있다고 하네요.
 
마토: 오빠? 글은 잘 쓰셨는데, 그럼 어떤 게 좋다는 거예요? 소프트웨어, 서버, 스위치 타입?
달: 헉. 그렇게 물으면 글을 잘 쓴 게 아니라 못 쓴 거지. 내 이야기는 그런 타입들이 있다는 거고, 각각의 특성이 있다는 건데.
마토: 그래요?
달: 그렇지. 그런데 현재 제품들의 특성을 고객들이 잘못 이해하고 있는 게 있어. 예를 들면 현재 제품들은 성능이 높은 제품일수록 10G 포트 수 같은 것들이 고정돼 있어 적정한 수준의 성능이 필요한데 그걸 위해서 반드시 최상위 제품을 사야만 하거든. 어떻게 보면 고객한테는 선택권이 없이 무조건 최상위 제품을 살 수밖에 없기 때문에 비용 부담이 크지. 나도 제품을 파는 입장에 있는 엔지니어지만 이건 아니다 싶어. 10G 포트가 있는데, 10Gbps 성능과는 무관한데, 거기에 혹 하는 분들도 있고. 다른 중요한 성능(L4 CPS, L7 TPS, 쓰루풋, 최대 동시접속 등)에 대해서는 관심이 없는 경우도 많아.
마토: 음. 그렇군요.
달: 그리고 또 한 가지는 고객들이 최고만 고집해. 언제 쓸지도 모르는 최고 성능, 최고 포트를 선호하니까 그렇게 된 것도 있지. 전에 일본 고객을 지원한 적이 있는데, 그쪽은 조금 답답해 보이지만 100M, 1G, 10G 이런 거에 대해 굉장히 꼼꼼하게 산정하고 테스트하고 구매를 하더라고. 적정한 걸 산다는 거지. 그러나 국내에서는 5년 뒤에 10G 포트가 필요한데 먼저 산다는 거지. 그리고 5년 뒤에는 장비를 또 새로 구매하고.
마토: 그럼 정리하면, 무조건 스펙이 좋은 것만 사지 말고, 적절하고 필요한 장비를 사라는 거지?
달: 그렇지. 가끔 고객 구매 사양에 특정 벤더를 지칭하는 내용이 적혀 나오는 데, 어떤 포트 몇 개 이상이라는 식으로. 이건 정말 아니라고 봐.
마토: 그럼 포트 수가 필요한 건 어떻게 해결해? 서버도 많은데.
달: 앞서 말했지만 L2를 쓰면 되지. 그게 훨씬 더 저렴할 걸. 절대 나쁜 게 아니야.
 
참 소프트웨어 제품은 IDC나 프로스트&설리번 같은 시장조사기관에는 포함되지 않습니다. 장비로 된 것들만 포함됩니다. L4 스위치의 오해 중 하나는 백플레인이라고 하는 L2 스위칭 용량으로 제품을 선택하는 경우입니다. 로드 밸런서 대부분은 위에서 내려온 트래픽을 아래 서버들로 전달하는 역할을 하기 때문에 스위칭 용량은 정말 의미가 없습니다. 12G, 128G, 이런 거 다 소용없습니다.

다만 장비와 장비간에 다량으로 스위칭 통신이 이뤄져야 한다면 필요하겠죠. 섀시 형태의 경우 필요할 것 같네요. 하지만 대부분은 아닙니다. 현재 나온 제품이면 충분합니다. 그러니 너무 현혹되지 마세요. 거의 대부분이 사용된 L2/3 칩의 성능을 말하는 거니까 중요한 게 아닙니다. 대부분의 트래픽이 L4~7 엔진을 통과해야하니 의미 없는 숫자에 불과하죠. 여기서 2편 마무리합니다. 3편부터는 정말 이슈가 많이 되는 성능 지표에 대해 알아보겠습니다.