|
이번 기고의 주제는 ‘애플리케이션 스위치 제대로 알기’다. 잘 알고 있는 것 같으면서도 막상 잘 모르는 것이 L4~7 스위치로 통용되는 애플리케이션 스위치다. 이번 기고는 애플리케이션 스위치에 대한 진실과 오해를 짚고 넘어가야 될 필요성이 있어서 마련됐다. 이어에는 잘 모르고 있는 애플리케이션의 성능지표에 관한 첫 번째 이야기다. <편집자>
최성열
시스코 APAC ANS CSE
sungchoi@cisco.com
2회에 걸쳐 애플리케이션 스위치의 선택 조건인 ‘성능지표’에 대해 알아볼까 합니다. 예전에 고객사를 방문했을 때 고객이 대뜸 궁금한 게 있으니 ▲하드웨어 구조 ▲소프트웨어 구조 ▲로드밸런싱 방법 ▲헬쓰체크 방법 ▲성능(용량) 판단 등을 설명해달라고 하더군요. 그래서 준비한 프리젠테이션은 못하고 부랴부랴 이것저것 자료와 칠판을 이용해 설명을 드렸는데, 역시나 잘 이해를 못 하시더군요.
2회에 걸쳐 애플리케이션 스위치의 선택 조건인 ‘성능지표’에 대해 알아볼까 합니다. 예전에 고객사를 방문했을 때 고객이 대뜸 궁금한 게 있으니 ▲하드웨어 구조 ▲소프트웨어 구조 ▲로드밸런싱 방법 ▲헬쓰체크 방법 ▲성능(용량) 판단 등을 설명해달라고 하더군요. 그래서 준비한 프리젠테이션은 못하고 부랴부랴 이것저것 자료와 칠판을 이용해 설명을 드렸는데, 역시나 잘 이해를 못 하시더군요.
알고 싶다고 해도, 쉽게 설명을 한다고 해도 쉬운 게 아니죠. ‘애플리케이션 스위치 성능’은 IT 경험이 많다고 쉽게 알 수 있는 내용은 아니라고 생각합니다. 성능은 여러분들이 잘 알아야 하는 수치입니다. 무조건 높은 게 좋은 게 아니라 ‘적절한’ 제품을 선택할 수 있는 정도는 알아야 합니다. 이런 이야기 많이 들어봤을 겁니다.
A사: 우리는 쓰루풋이 10Gbps입니다. 업계 최고죠.
B사: 우리는 L4 CPS(Connection Per Second)가 40만 CPS입니다. 당근 따라올 데가 없죠.
C사: 우리는 L7 TPS(Transaction Per Second)가 20만 TPS입니다. 업계 짱이죠.
D사: 우리는 동시 커넥션(Max Concurrent Connection)이 500만입니다. 이건 업계 최고죠.
대개 일반적인 L4~7 관련 성능을 이야기할 때 가장 기본적으로 따지는 숫자는 4가지 정도입니다. 물론 더 많은 부분을 봐야겠지만 앞서 예를 든 4가지는 정확히 알아둬야 합니다.
처리량(Throughput)
흔히 이야기 하는 처리량은 ‘트래픽’의 처리량을 말합니다. 애플리케이션 스위치는 <그림 1>에서 보는 것처럼 클라이언트와 서버 사이에서 일을 합니다. 그래서 클라이언트/서버 사이의 트래픽을 얼마나 처리 하느냐를 기준으로 하게 됩니다. 인/아웃으로 그려 놓은 건 애플리케이션 스위치를 기준으로 클라이언트가 서버로 보내는 트래픽과 서버에서 클라이언트로 응답하는 트래픽이 존재하기 때문이고, 이게 실제로 기준이 돼야 합니다.
| |
 |
|
|
<그림 1> 애플리케이션 스위치 위치
|
일단 단위는 보통 Gbps로 따지게 됩니다. 왜냐하면, 실시간으로 지나가는 트래픽 기준이거든요. 그러면 10Gbps의 트래픽을 처리하는 장비라면? 인/아웃 합이 초당 10Gbps의 트래픽을 처리한다고 보면 됩니다.
보통 애플리케이션 스위치의 처리량은 L2/3 스위치와 달리 64바이트를 기준으로 하지 않고 일반적인 트래픽 처리(계측기를 이용해)를 기준으로 합니다. 64바이트로만 측정한다면 10Gbps를 처리하는 장비도 실제로는 몇 Gbps가 안 나올 수 있습니다.
L4~7 엔진은 단순 트래픽 처리뿐만 아니라 뒤에서 설명할 초당 세션 수 등과 연관이 있기 때문에 256바이트 또는 512바이트 정도는 돼야 벤더에서 이야기하는 트래픽이 나오게 됩니다. 물론 내부 설정에 의해 로드밸런싱을 하지 않고 L3 스위칭만 하게 한다면 하드웨어(L2/3)에서 처리하는 것처럼 와이어스피드를 볼 수도 있지만 적절한 방법은 아닙니다. L2/3는 패킷 수와 연관이 있지만 애플리케이션 스위치는 어찌됐던 세션 수와 연관이 있기 때문입니다.
일반적인 L4 로드밸런싱을 할 때 애플리케이션 스위치는 모든 플로우(Flow)에 관여하게 됩니다. 클라이언트에서 서버로, 서버에서 클라이언트로 응답되는 모든 패킷이 처리량 산정에 사용됩니다. 그런데 패킷 사이즈라 함은 SYN 같은 패킷들은 64바이트 안에 모두 끝나지만 실제 웹서버와 유사한 환경의 계측기 테스트를 해야 하기 때문에 서버에서 응답되는 사이즈를 하나씩 조절하게 됩니다.
처음에는 64바이트부터 시작해서 128, 256, 512, 1024, 5K, 11K, 22K 등으로 올리게 됩니다. 그러면 64나 128에서는 벤더에서 이야기하는 숫자는 보지 못하고 그 이상(경험상으로는 512 이상 정도는 돼야)에서 볼 수 있습니다. 클라이언트의 요청을 조절하는 경우도 있지만 대부분은 서버의 응답 사이즈를 조절해 전체적인 처리량을 측정하게 됩니다.
그러면 앞에서 이야기했던 인보다는 아웃이 몇 배가 커지게 되죠. 단순하게 인/아웃을 64-64, 128-128 이렇게 하는 건 무의미한 테스트로 봐야 합니다. 초당 세션 처리량이 적은 장비들도 패킷 사이즈를 크게 하면 당연히 많은 양의 패킷을 처리하는 것으로 볼 수 있을 겁니다. 단 이런 장비는 처리량은 통과하더라도 CPS 같은 것에서 성능이 안 된다는 것을 발견할 수 있겠죠.
| |
 |
|
|
<그림 2> 한 클라이언트가 세션 하나를 맺고, 데이터 하나를 가져오는 동작
|
마토: 처리량만 기준으로 본다면 어떤 장비가 좋다는 건지 설명 좀 해주셔요.
달: 좋다기보다는 벤더에서 이야기하는 처리량(4Gbps, 6Gbps, 8Gbps, 10Gbps) 같은 숫자는 장비를 도입하는 입장에서 충분히 이해를 해야 한다는 거지. 벤더 입장에서는 흔히 스펙을 우려해 다른 처리량과 무관하게 패킷량을 크게 측정해 처리량을 높일 수도 있다는 거지.
마토: 아~
달: ㅎㅎ 이해가 잘 안가지? 성능 측정을 할 때, 애플리케이션 스위치는 계측기를 통해서 로드밸런싱 설정을 해 놓고 하거든. 예를 들면 클라이언트는 300개 IP에, 서버는 10개를 로드밸런싱하는 조건으로 설정해 놓았다고 생각해 보자. 앞에 <그림 2>를 보면 한 클라이언트가 세션 하나를 맺고 데이터 하나를 가져오는 동작이 거든. 이게 뒤에 설명할 CPS라는 건데. 그냥 서버에서 응답하는 사이즈만 크게 하면 이런 세션을 적게 처리하고도 많은 양의 트래픽을 처리하는 것처럼 할 수 있다는 거지.
마토: 아하. 그렇군. 그럼 어떻게 그걸 증명해야하지.
달: 장비를 도입할 때 하나의 숫자만 보고 제품을 선택하면 안 되는 거야. 앞에서 언급한 처리량, CPS, TPS를 다 따져봐서 이런 것들이 잘 조합돼 있는지를 봐야지.
마토: 다시 어려워지려고 하는데. ㅠ.ㅠ
달: 최소한 장비를 판단한다면, 이런 것들을 잘 따져야지. 그렇지 않을 거라면 성능 이야기를 하면서 장비를 사면 안 되는 거지.
마토: 그건 그런데, 고객을 만나서도 그렇게 이야기 해?
달: 헉, 아니. 고객 만나면 이렇게까지 심하게 하진 않지. 근데 꼭 이해하라고 이야기를 하지. 근데 잘 안 듣지. 심하게는 이런 경우도 있어. 10G 포트만 있으면 장비가 10G를 처리하는 것으로 인식하거든. 그건 그냥 10G 인터페이스 일뿐인데.
| |
 |
|
|
<그림 3> 아발란체로 측정한 실제 트래픽 결과
|
<그림 3>은 실제 사이트에서 아발란체(Avalanche)라는 계측기로 측정한 결과입니다. 장비의 아웃을 보면 4.3Gbps인데 인은 100Mbps가 넘습니다. 처리량도 그렇고, 그 값이 손실없이 안정적으로 동작하느냐 여부도 중요한 요소가 될 수 있을 것 같습니다.
양방향(Bi-direction)과 단방향(Uni-direction)
벤더에서 장비의 스펙을 내놓을 때 대개 애매하게 내놓습니다. 처리량을 그냥 10Gbps라고 씁니다. 그러면 고객은 혼동하죠. 도대체 이 기준이 뭘까? 일반적으로는 글자 그대로 ‘10Gbps’를 처리할 수 있는 장비라고 생각합니다.
하지만 여기서 명확히 해야 할 것은 인도 10Gbps, 아웃도 10Gbps 인지를 생각해 봐야 합니다. 지난호에서 설명한 L4~7 엔진 기억하시죠. 여기에 문제가 있는 겁니다. 로드 밸런서는 로드밸런싱되는 트래픽이 보통 엔진을 통과하는데, 이걸 경유하는 만큼 이 내부의 엔진에서 양방향 10Gbps라면 초당 20Gbps를 처리하게 되는 겁니다. 인/아웃을 합쳐서 실제 엔진에서의 처리되는 처리량이 됩니다.
단방향 10Gbps라면 어찌됐던 단방향 10Gbps를 최대로 처리하는 것이고, 이 장비는 단방향 10Gbps 또는 양방향으로는 5Gbps를 처리하게 돼 인/아웃을 합치면 10Gbps를 처리하게 됩니다. 그러나 실제 현장에서는 이 용어의 잘못된 사용으로 인해 장비의 성능을 2배 가까이 오해하는 경우가 많습니다.
일반적인 웹서비스를 하는 곳은 클라이언트에서 서버로 전달되는 인과 아웃의 차이는 수 십배입니다. 웹서비스를 생각해 보면 클라이언트는 대부분의 서버에게 콘텐츠 요청(In)을 하게 되고, 서버는 다수의 페이지를 클라이언트로 응답(Out)하게 됩니다.
흔히 평균 요청이 64바이트 또는 이보다 조금 많다면 서버에서 응답되는 패킷의 일반적인 사이즈는 1000바이트 근처가 됩니다. 이것만 따져도 15.6배가 되네요. 그래서 성능을 산정할 때는 기본적으로 서버에서 응답하는 전체적인 트래픽을 기준으로 해야 합니다. 다시 말하면 인/아웃을 고려하되 적어도 단방향 트래픽 처리량이 서버에서 응답될 아웃보다는 커야합니다.
CPS(Connection Per Second)
CPS는 가장 대표적인 성능 기준으로, L4는 보통 CPS라는 용어를 사용합니다. L7은 TPS(Transactions Per Second) 또는 RPS(Request Per Second)를 쓰기도 합니다. 쉽게 풀면 ‘초당 커넥션 처리 숫자’로 이야기할 수 있는데, 초당 얼마나 많은 커넥션을 동시에 처리하느냐를 의미합니다. 일반적으로 클라이언트가 VIP로 접속하고, 이를 특정 서버로 분산한 후 다시 세션을 끊는 과정을 하나의 CPS로 보니다. 만일 어떤 벤더가 우리는 20만 CPS를 지원한다고 했다면, 이는 초당 20만개의 커넥션을 동시에 받아들여서 로드 밸런싱을 한다는 걸 의미합니다.
예전에는 하나의 커넥션이라고 하면 <그림 4>처럼 커넥션 하나가 만들어지고, 닫히는 순간까지를 이야기합니다. 보통 우리가 TCP 통신을 이야기할 때 세션 TCP 3웨이-핸드쉐이크라고 이야기하는데, 기본적으로 열 때는 3개, 닫힐 때는 3개 또는 4개의 세션을 사용합니다. 계측기마다 기준이 조금씩 다르지만 일반적으로 비슷하다고 보면 됩니다. 보통 닫힐 때 4웨이-앤드쉐이크라고 하니 7개라고 하고, 20만 CPS라고 하면, 초당 20만 개가 열리고 닫히기 때문에 20만×7이 돼 140만 패킷이 왔다갔다하는 거네요(데이터 통신은 제외하고).
| |
 |
|
|
<그림 4> 일반적인 커넥션 과정
|
그런데 여기서는 단순 패킷이 문제가 아니라 로드밸런싱 장비들은 VIP로 온 걸 서버로 보내면서 서버의 IP로 바꾸게 되는 동작을 하고, 되돌아 갈 때는 다시 거꾸로 서버의 IP인 소스 IP를 VIP로 바꿔서 보내야 합니다. 다시 말하면 VIP로 와서, 서버로 갈 때는 목적지 NAT가, 서버에서 응답돼 클라이언트로 갈 때는 소스 NAT가 됩니다. 처음에 VIP로 오면 어떤 서버로 갈 지와 매번 패킷에 대해서는 세션 테이블을 확인해야 이러한 동작이 가능하기 때문에 굉장히 많은 부하가 있습니다.
그래서 계측기를 이용해 테스트를 해보면, CPS를 쭈~욱 올려가면서 테스트를 하면 장비의 CPU도 같이 쭈~욱 올라가는 걸 볼 수 있습니다. 로드밸런싱 동작 중에 CPU와 메모리 부하가 많을 때라고 보면 될 것 같습니다. 생각해 보세요. 얼마나 많은 숫자인지. 예전에는 로드배런싱 장비들이 10만 CPS만 돼도 꽤 높은 장비였는데, 요즘은 워낙 성능이 좋다 보니 최고사양 장비들은 몇 십만 CPS는 기본입니다.
성능 측정은 각각의 성능 측정에 맞는 설정을 하게 되는데, 다음 <그림 5>는 아발란체라는 장비의 샘플 컨피그(Sample Config) 중에서 HTTP를 이용한 CPS 성능 측정 화면으로, 테스트 방식을 이해하는데 도움이 될 것 같아 캡쳐해 봤습니다. 왼쪽 메뉴를 보면 여러 종류의 프로토콜과 성능 측정 방법이 있으니 사용자는 자신의 테스트 상황에 맞게 설정하면 됩니다.
| |
 |
|
|
<그림 5> HTTP 이용한 L4 CPS 테스트 화면
|
<그림 5>는 HTTP를 이용한 L4 CPS 테스트로, 30만 CPS 측정을 기준으로 설정을 했습니다. 파란색으로 돼 있는 부분이 실제로 장비가 시간이 지나면서 쏘는 양입니다. 장비에 따라서 대기시간을 가진 다음에 패킷이 후루룩 최고치까지 가는 경우가 있지만 대부분 초기에 대기시간(여기서는 30초)을 둬 시작을 누르더라도 바로 시작하지 않습니다. 흔히 ARP 업데이트 등을 고려해서 그렇기 때문에 이 시간 단축은 권고하지 않는 편입니다.
30초 이후에는 점차적으로 증가시켜 일정시간이 되면 목표치인 30만을 만들어 냅니다. 안정적인 장비라면 이때에도 CPU도 어느 정도 안정적이여야 하고(물론 높겠지만), 만일 패킷 빠짐, 튐 현상, 관리모듈 불안 등이 있다면 조금 고민해 봐야 합니다.
그리고 마지막으로는 테스트를 종료하기 전에 모든 세션을 정리하기 위해 일정시간을 둡니다. 그래프가 떨어졌더라도 해당 시간이 다 되기 전까지는 테스트가 끝난 게 아니니 기다려야 합니다. 계측기는 사람이 아니기 때문에 뭔가 하나라도 잘못되면 바로 에러 값을 증가시켜 당황하게 만든다는 걸 기억하세요. 아주 냉정합니다.
| |
 |
|
|
<그림 6> 실제 장비 테스트 화면
|
이제 실제 장비를 테스트한 결과를 <그림 6>을 통해 볼까요(이번에는 다른 계측기 테스트 결과입니다). 안정된 장비라면 스펙 숫자에서 전반적으로 안정된 그래프와 지연이 없어야 합니다. 물론 하나도 없을 수는 없지만, 눈에 띄는 지연은 장비의 안정성에 의문을 가져야 합니다. 이 그래프에서 알 수 있는 건 바로 30만을 향해서 치달았고, 60초 정도를 안정적으로 유지하고, 다시 15초 정도 정리하는(?) 시간을 가졌다는 겁니다. 그렇지 않은 장비는? 각자의 상상에 맞기겠습니다. 다음호에서는 L7 성능과 동시 연결 수에 대한 이야기를 해보겠습니다. |
webmaster@datanet.co.kr
KT, ‘28GHz 기업전용 5G 네트워크’ 개발 성공
