|
이번 기고의 주제는 ‘애플리케이션 스위치 제대로 알기’다. 잘 알고 있는 것 같으면서도 막상 잘 모르는 것이 L4~7 스위치로 통용되는 애플리케이션 스위치다. 이번 기고는 애플리케이션 스위치에 대한 진실과 오해를 짚고 넘어가야 될 필요성이 있어서 마련됐다. 이번호에서는 잘 모르고 있는 애플리케이션의 성능지표에 관한 두 번째 이야기를 풀어본다. <편집자>
최성열
시스코 APAC ANS CSE
sungchoi@cisco.com
애플리케이션 스위치의 성능지표 1탄인 ‘처리량(Throughput)’, ‘CPS(Connection Per Second)’에 이어 이번호에서는 성능지표 2탄으로 ‘L7 TPS (Transactions per second)’와 ‘동시 연결 수(Concurrent Connections)’라는 것에 대해 알아보겠습니다.
애플리케이션 스위치의 성능지표 1탄인 ‘처리량(Throughput)’, ‘CPS(Connection Per Second)’에 이어 이번호에서는 성능지표 2탄으로 ‘L7 TPS (Transactions per second)’와 ‘동시 연결 수(Concurrent Connections)’라는 것에 대해 알아보겠습니다.
L7 TPS
요즘 나오는 로드밸런서들은 기본적으로 L7 기반의 동작을 지원하기기 때문에 당장 사용하지 않더라도 보통 L7 성능을 측정하고자 하는 경우가 많이 있습니다. 이때 대부분 트랜잭션(Transaction)이라는 용어를 사용합니다. RPS(Requests Per Second)라고도 하는 업체도 있기도 한데, 아무래도 범용적인 용어가 L7 TPS가 아닐까 합니다. 지난호에 이야기했던 L4 CPS와 L7 TPS의 가장 큰 차이를 생각해 보겠습니다. 계측기와 애플리케이션 스위치 장비의 두 가지 측면에서 봐야 합니다.
우선 계측기의 종류에 따라서 L7 콘텐츠를 포함하느냐 안 하느냐의 차이가 있습니다. 지난호에서 말씀드린 것처럼 아발렌체(Avalanche)라는 장비는 기본적으로 L4 CPS를 할 때도 GET을 포함한 테스트를 기본으로 하기 있기 때문에 L4, 즉 TCP 세션에 대한 처리를 할 때도 GET과 데이터가 포함돼 있습니다. 익시아(IXIA)나 브레이킹포인트(BreakingPoint) 등 다른 계측기들은 그렇지 않은 것으로 기억(?)합니다.
그런데 중요한 건 이 동작 자체가 하나의 세션에 패킷 수가 많기는 하지만 실제 로드밸런싱 장비 입장에서는 크게 영향을 주지 않는다는 사실입니다. 왜냐하면 L4로 동작할 때는 처음 세션을 받고, 로드밸런싱을 할 서버를 결정하는 게 가장 큰 부하고, 추가 패킷들은 세션 테이블을 보고 전달하기 때문에 부하가 상대적으로 적습니다.
| |
 |
|
|
<그림 1> 로드밸런서의 L7 세션 동작
|
애플리케이션 스위치가 L7으로 동작할 경우 L4 상위레벨의 헤더 또는 데이터를 보고 동작을 하기 때문에 부하가 많을 수밖에 없습니다. 더구나 <그림 1>을 보면 L7으로 동작할 때 상당한 차이를 보입니다. L7으로 동작할 때 가장 큰 차이가 ‘GET’과 같은 L7 요청이 있을 때 서버로 세션을 연다는 점입니다. 그래서 세션을 열고 닫고 하는 문제가 L4로 동작할 때와는 달리 로드밸런서가 클라이언트와 직접 세션 셋업을 하고, 서버와는 또다시 별도로 하게 됩니다.
L4 동작일 때는 SYN이 오면 어떤 서버로 갈지 바로 결정돼서 전달됐지만 지금은 그렇지 않죠? 어떻게 보면 약간 느리게 연결되지요? 그래서 업계에서는 딜레이드 바인딩(Delayed Binding)이라고 합니다. L7의 이러한 동작에서 콘텐츠 로드밸런싱은 물론 TCP 리유즈(Reuse)라고 하는 커넥션(Connection) 관리로 서버의 부하를 줄이고, DDoS에 SYN 쿠키 기능을 이용하기도 합니다. 그리고 자신이 세션을 100% 가로채고 있기 때문에 콘텐츠(<그림 1>)에서 4번째 패킷인 GET)를 확인하고 밸런싱 될 서버를 결정하기도 하고, 필요하면 WAF(Web Application Firewall)로 정책에 의한 차단이나 조작도 가능하게 됩니다. 그만큼 기존 L4 동작보다는 많은 리소스를 써야 원하는 일을 수행할 수 있습니다.
아발란체에서 제공하는 기본적인 메뉴(왼쪽)를 보면 많이 사용하는 것이 HTTP_1.1_SEC을 이용한 설정인데, GET 리퀘스트가 기본적으로 2개가 있습니다. 이 동작은 <그림 1>처럼 하나의 TCP 세션에 1개의 GET이 아니라 2개의 GET을 기본값으로 하고 있습니다. 400,000TPS라고 하면 실제로는 TCP 세션은 절반인 200,000가 열리는 것이고 여기에 2개의 GET이 추가되게 됩니다.
만약 장비가 L7으로 동작할 때 TCP 세션에 약한 장비라면 하나의 TCP 세션에 여러 개의 GET을 추가하면 세션 셋업에 대한 부담을 줄이면서 L7 동작에 집중할 수도 있습니다.(숫자 속임도 가능하죠.) L7 TPS는 L7 동작에 대한 부하를 측정하는 것이지만 너무 많은 GET을 추가하는 것은 적당한 방법은 아니라 생각합니다.
| |
 |
|
|
<그림 2> 아발란체의 L7 TPS 설정화면
|
로드밸런싱 장비 설정
그렇다면 로드밸런싱 장비를 어떻게 설정될까요. 여기서 중요한 건 계측기만 GET과 같은 리퀘스트가 포함돼 있고, 로드밸런싱 장비는 L4로 동작하면 장비의 성능은 아주 잘 나오게 된다는 점입니다.(이것도 꼼수죠.) 왜냐하면 로드밸런싱 장비의 설정에 따라 그런 GET 리퀘스트 참조 없이 이후 리퀘스트들을 그냥 따라오는 패킷들로 따져서 커넥션 테이블을 보고 던져주기만 하기 때문이죠.
따라서 성능 측정을 한다면 장비의 상태들을 잘 참조해서 설정과 동작이 되는지 장비 입장에서 볼 필요가 있습니다. 장비의 설정을 한번 볼까요. 제가 담당하고 있는 장비가 시스코 ACE(Application Control Engine)이니 그 장비의 예를 보도록 하겠습니다.
serverfarm host imagefarm ---> 이미지를 다루는 서버 3, 4번을 두고
rserver lnx3
inservice
rserver lnx4
inservice
serverfarm host webfarm ---> 일반적인 콘텐츠를 다루는 웹 서버 1, 2
rserver lnx1
inservice
rserver lnx2
inservice
class-map type http loadbalance match-all images
2 match http url /images/.* ---> 여기가 중요한 설정. URL 중에서 이미지(/images/.*)로 된 것들만 선택
class-map match-all slb-vip
2 match virtual-address 172.16.1.101 eq tcp http
policy-map type loadbalance http first-match slb
class images
serverfarm imagefarm ---> 여기 있는 이 서버팜으로 보내는 거죠.
class class-default
serverfarm web ---> 그리고 그렇지 않은 것들은 여기로.
policy-map multi-match client-vips
class slb-vip
loadbalance vip inservice
loadbalance policy slb
그래서 실제 동작 결과는
ACE-1/routed(config-if)# do show service-policy client-vips detail
---------------------------------------------------------------
service-policy: client-vips
class: slb-vip
VIP Address: Protocol: Port:
172.16.1.101 tcp eq 80
VIP State: INSERVICE
curr conns : 0 , hit count : 10
L7 Loadbalance policy : slb-logic
class/match : images
LB action :
primary serverfarm: imagefarm
state: UP
hit count : 9
class/match : class-default
LB action :
primary serverfarm: webfarm
state: UP
hit count : 1
이렇게 각각의 서버 팜으로 밸런싱이 되게 됩니다. 계측기에는 요청하는 리퀘스트에 당연히 ‘http://172. 16.1.101/images/abc.gif’와 같은 리퀘스트가 포함돼 있어야 이러한 결과처럼 각각의 서버팜들로 분산이 되겠죠.
동시 연결 수
일반적으로 애플리케이션 스위치 성능을 나타낼 때 4가지(처리량, L4 CPS, L7 TPS, 동시 연결 수)가 있다고 했습니다. 동시 연결 수는 다른 성능보다 메모리 의존적인 부분이 있고, 오해의 소지가 있기 때문에 조금 더 신중하게 접근 할 필요가 있습니다. 애플리케이션 스위치의 동시 연결 수는 로드밸런싱을 기준으로 클라이언트/서버의 세션 수로 합니다. 물론 벤더마다 기준 차이는 조금씩 다릅니다. 이 부분에서 혼동이 있을 수도 있으니 잘 기억해 두셨으면 합니다.
| |
 |
|
|
<그림 3> 시스코 ACE 세션 테이블
|
시스코 ACE의 세션 테이블을 먼저 보도록 보죠. <그림 3>은 서버 로드밸런싱(SLB) 환경에서 209.165.201.11이라는 클라이언트가 172.16.11.190이라는 VIP의 80포트로 세션을 열었고, 다시 192.168.1.11이라는 서버의 80포트로 로드밸런싱이 된 세션입니다. 아시겠지만 SLB는 VIP로 접속을 하고, 다시 실제 서버로 밸런싱이 되기 때문에 흔히 목적지주소변환(NAT)이 일어나게 됩니다. 관리 테이블이 일반적인 라우팅 캐시나 L2에서의 테이블 보다는 더 많은 정보를 담고 있습니다. 그림에서는 빠졌지만 세션생성 시간, 사용하지 않는 시간들도 관리를 합니다.
어떤 장비는 이걸 한 줄로 표시하기도 하고, 두 줄로 표시하기도 합니다. 이는 장비를 만드는 사람들의 특성이니까 크게 신경을 쓰지 않아도 됩니다. 만약에 VIP의 포트가 80인데, 서버의 포트가 8080, 8081과 같은 다른 포트라면 192.168.1.11:xx의 뒷부분이 다른 포트로 표시됩니다. 그러니 세션 테이블만 잘 이해하면 다른 부분들까지도 연관해서 알 수 있습니다. 그리고 맨 앞에 커넥션 ID 등은 보통 내부적으로 관리하고, ‘ESTAB(Established)’라는 세션의 상태(Status)도 관리해서 이 세션의 상태를 제대로 관리해야 합니다.
세션 테이블은 왜 필요한가?
일반적인 웹 서버라면 TCP로 동작하고, SYN 패킷이 왔을 때 어떤 서버로 밸런싱을 해야 할지를 선택하게 됩니다. 이렇게 서버가 결정되고 나면 이후에 세션들, SYN+ACK 응답, 그리고 ACE, GET, 데이터 전송 등 따라오는 패킷들이 계속 있겠죠. 이런 모든 것들이 계속 NAT가 돼야 하고, 같은 서버로 전달돼야 하고, 어떤 VLAN에서 왔는지도 알아야 합니다. 그래서 계속적으로 참조해야 할 필요가 있기 때문에 세션 테이블을 만들어 놓고, 참조를 해서 관련 동작들을 하게 됩니다.
L2 스위치에 MAC 러닝 테이블이 있으면 브로드캐스트 안 해도 되고, L3에서 라우팅 캐시 테이블이 있으면 다시 라우팅 테이블 검색 안 하고 캐시 테이블을 보고 전달하는 장점이 있죠. 그것처럼 메모리에 기록된 정보를 먼저 검색해서 처리하고 그렇지 않으면 라우팅 테이블 다시 찾는 부하를 가지게 되는 것과 비슷합니다. 그래서 애플리케이션 스위치는 아무래도 서버 선택, NAT 등 다양한 부분을 더 참조하고 동작해야 하기 때문에 이 테이블로 얻는 이득이 아주 크게 됩니다. 만약에 이런 테이블이 없으면 앞서 이야기했던 L4 CPS처럼 매번 서버 선택에 대한 부담과 NAT는 어떻게 해줘야 하는지 CPU가 더 바빠질 테니 아주 중요한 요소입니다.
세션 테이블은 언제 사라지나?
FIN, 리셋과 같이 클라이언트/서버에서 정상적인 종료를 하게 되면 애플리케이션 스위치는 세션을 바로 지워버립니다. 그런데 만약 세션 종료가 없거나 잘못된 종료가 있을 경우에는 장비의 기본 시간 동안 가지고 있습니다. 이 건 모든 TCP/IP 장비(방화벽, PC, 서버)들이 가지고 있습니다. 일반적으로 세션 종료가 없으면 1시간을 가지게 되는데, ‘잘 끊어지겠지’라고 생각하겠지만 그렇지 않은 경우가 많습니다. 그래서 터무니없이 세션에 대한 모니터링도 필요합니다.
최근에 어떤 고객사에서 보니 클라이언트/서버 사이에 세션 끊는 부분이 정상적이지 않아 세션이 많이 남아있는데, 보통 이 경우를 반쯤 닫힘(Half Closed)이라고 하는데 이 경우는 일반적인 타임아웃과는 달라 추가적으로 적용을 해 준 적이 있습니다. 일반적으로는 초단위로 보통 설정을 합니다. 대부분의 기본값들은 1시간이고, 범위는 0~4,294,967,295와 같은 형태로 돼 있습니다.
parameter-map type connection Timeout_parameter
set timeout inactivity 300
set tcp timeout half-closed 10
set tcp timeout embryonic 10
요즘은 웜 같은 불필요한 세션이 많으므로 세션 관리에도 신경을 써야 합니다. 그렇지 않으면 장비의 최대 동시 연결 수를 넘는 경우가 생길 수 있습니다.(사실 요즘 장비들은 지원하는 숫자가 큰 편이라 큰 문제는 없겠지만) 예전에 웜이 처음 나오고, 장비들이 1M 미만을 지원할 때는 실제로 세션들이 꽉 차서 서비스가 안 되는 걸 몇 번 경험한 적 있습니다.
마토: 이렇게 세션들이 꽉 차면 무슨 일이 생기는데?
달: 오호 좋은 질문. 애플리케이션 스위치는 항상 세션을 만들어야 하는데, 이게 제대로 안 만들어지면 로드밸런싱을 하는 순간 세션을 만들어야 하는데 그렇지 못하니까 새로운 접속들은 연결이 안 되는 거지.
마토: 우와 그럼 아주 심각한 문제네?
달: 그렇지. 하지만 정상적인 서비스 상황에서는 그런 일 없고, 운영자들이 지속적으로 모니터링할 필요가 있고, 어디에서 문제가 생기는지를 찾고, 원인을 해결하려고 하는 방법을 찾는 것도 필요해.
마토: 너무 막연한 거 아니야? 전문가가 정확한 솔루션을 제공해야지.
달: ㅎㅎ 그런가? 예를 들면 외부에서의 문제라면 DDoS 같은 보안장비의 힘을 빌린다거나 애플리케이션 스위치의 DDoS 기능을 활용할 수도 있어. 내부에서의 웜 관련 세션이라면 출발지 IP가 서버 IP가 아닌 것들을 차단하는 설정을(ACL) 한다거나 보안패치 등을 제대로 하는 것도 중요하지. 그리고 앞서 말한 타임아웃 조절값 등으로 불필요한 세션들이 남아있는 걸 조절하는 것도 필요할 거고. 아니면 서버들에 대한 최대 연결 수 제한 등으로 과도한 접속으로 인한 서비스 중단 현상을 막는 것도 해볼 수 있겠다.
마토: 너무 어렵다. 할 일이 많네. ㅠ.ㅠ
달: 아무래도 보안문제와 연결되는 게 많은데, 국제보안전문가자격증(CISSP)을 가진 사람 입장에서 보면. ㅋㅋ 보안은 어떤 한 솔루션으로 모두 해결되는 게 아니라는 점을 꼭 기억했으면 좋겠어. ^^;;
| |
 |
|
|
<그림 4> 시스코 ACE 어드민 화면(동시 연결수: 최대 4M 지원)
|
<그림 4>를 참고해서 장비를 한번 볼까요. 이 장비는 최대 4M를 동시 연결 수로 지원하는데 클라이언트 → VIP, 그리고 밸런싱이 돼 서버로 가는 세션을 관리하기 때문에 3M의 계측기로 테스트할 때 6,000,000으로 보이는 거고, 우리는 3M라고 보면 됩니다. 어떤 벤더에서는 이를 숫자 그대로 6M로 읽어 경쟁사들과 차별화를 두는 경우가 있는데 앞서 언급한 것처럼 평가자가 기준을 가지고 있어야 제대로 된 평가를 할 수 있습니다.
| |
 |
|
|
<그림 5> 아발란체 계측기 설정화면(오픈 커넥션: 3,000,000)
|
<그림 5>의 아발렌체 계측기에서 숫자를 보면 오픈 커넥션이 3,000,000으로 보입니다. 이 상황은 현재 애플리케이션 스위치에 3,000,000개의 연결이 돼 있고, 관련된 세션이 들어오면 그 테이블을 보고 기존에 밸런싱됐던 서버들로 바로 보내주면 됩니다. 그런데 문제는 이 테스트에서 한 가지 빠진 게 있습니다. 계측기 설정에 따라 그냥 세션을 닫지 않고 열기만 하는 방법이 있습니다. 이 경우는 초당 몇 만개씩 열기만 하기 때문에 애플리케이션 스위치 입장에서는 그냥 세션만 열면 됩니다. 그래서 다시 닫지 않으면 실제로 장비에 가는 부하는 많지가 않습니다.
실제 환경에서는 세션이 많으면서 열리고 닫히고 하기 때문에 제대로 측정을 한다면 3,000,000개를 유지하기 위해서 세션을 계속 열고 닫고, 데이터도 주고받고 하는 설정이 필요합니다. 그래야 제대로 된 테스트죠. 그리고 지연도 체크를 해야 하고, 메모리에서 수 백만 개의 테이블에서 딱 맞는 세션을 찾아내는(look up) 것은 쉽지 않은 일입니다. 어쩌면 장비의 지연 요소가 될 수도 있습니다.
여러분들에게 적절한 세션 수는? 애플리케이션의 특성을 생각하시면 됩니다. 일반적으로는 한 유저가 10개의 세션을 연다고 치고, 접속이 많은 시간대(Peak Time)에 약 1만 명이 붙어있다면 동시 세션은? 10,000명×10세션=100,000 동시 세션이 되는 거죠.
그런데 이 세션들이 얼마나 붙어있을 것 같으세요. 잘 측정해 보면 대부분 10초 미만이 될 겁니다. 그러니 100,000 세션이라는 숫자가 적은 숫자가 아닐 수 있습니다. 그렇다면 어떤 장비를 선택해야 할까요? 환절기 감기 조심하시고, 다음호에는 L4와 L7의 차이에 대한 논란을 파헤쳐 보도록 하겠습니다. |
webmaster@datanet.co.kr
KT, ‘28GHz 기업전용 5G 네트워크’ 개발 성공
