사이트 구축할때 성능설계 어떤식으로 하시나요?

들어가기전에

안녕하세요.

오늘 여러분들에게 조금 생소할 수 있는 이야기를 해보려고 합니다. 여러분들은 웹사이트를 제작하기 앞서 성능추이 분석을 해보신적이 있으신지요? “아, 내 사이트는 동접 요청수가 이정도를 원하기 때문에 이런저런 성능의 스펙을 준비해야하고 이런저런 튜닝이 필요하다.” 등의 대략적인 분석을 통해 웹사이트 제작이 들어가거나 제작 후 튜닝에 들어갈 거라고 생각이 듭니다.

저는 이 글에서 성능추이 분석을 서버내적인 성능 스팩이 아닌 서버외의 환경을 기준으로 해보려고 합니다. 제가 네트워크가 본업이고 일본으로 넘어오고나서부터는 줄곳 설계를 해왔기 때문에 이런 경험을 살려 여러분들에게 도움이 될 만한 재미난 글을 적어볼끼 합니다. 글 중간 중간 안드로메다로 떠날 수 있음을 유의하시고 TCP/IP에 대한 지식이 전무하다면 이야기의 큰 맥만 짚어가면서 이해하시기 바랍니다.

xetown.com의 추이 분석

장엄한 설명을 하기전에 우선 xetown.com이 제가 하는 추이분석을 통해 어떤 결과를 보였는지 그래프를 봐주세요. 결과는 초당 약 240회의 웹페이지 요청이 되면 서버가 1Gbps의 인터페이스를 가지고 있다는 가정하에 네트워크의 Bottleneck(병목현상)이 발생하기 시작하게 되며 400회 정도의 요청만으로도 네트워크를 불통으로 만들 수 있게 됩니다.

어떠한 근거로 이런 통계가 나왔는가?

근거란 “대략 얼마” 라는 어림잡은 수치가 아니라 실제 이론으로 하여금 납득이 가능해야겠죠. 저는 제가 평소 대역폭에 준하는 네트워크를 설계할때 그 값이 기준치에 타당한지 이론에 근거하여 시뮬레이션을 합니다. 제가 회사서 사용하고 있는 계산식을 이번 추이용으로 조금 수정한 결과를 첨부합니다.

전송량과 지연을 기반으로 리얼에 근접한 계산을 하기위해 위와 같은 엑셀을 만들어 사용중입니다.
(이번 내용과 무관한 내용이 조금 섞여 있습니다. 회색처리 부분은 무시 해주세요.)

위 내용을 보는 방법을 간단히 말씀드리면 항목의 3은 xetown.com에서 전송되어온 기본 용량입니다. 1회 요청에 500kb를 내려받았습니다.(CDN, google 제외) 이 값을 기준으로 하여 서버환경이 1Gbps일때 동시에 몇회 요청이 있을때 Bottleneck이 발생하는지를 계산하는 방식입니다. 항목 18과 19가 결과이며 1G 인터페이스의 MAX인 125MB/s(1Gbps)를 정의하고 있습니다.

여러분은 TCP/IP 이론에서 대역폭 계산식을 배우게 되는데 어떻게 나와있나요? 아래와 같은 수식을 볼 수 있을 겁니다. 하지만 이것이 실제 전송된 값이라는 근거치에는 약간 부족합니다. 올바른 계산을 위해서, 또 사전지식으로써 패킷의 실체와 TCP Window size의 정의를 알아둘 필요가 있습니다.

bps = TCP Window size(KB) * 8 / RTT(s)

패킷

어럽지 않게 간단히 설명합니다. 패킷은 크게 3가지 종류로 보시면 됩니다. 첫번째로, 익히 알고 있을 패킷의 헤더인데 Data라는게 MTU라고 세션을 맺기 전에 행하는 3way handshake를 통해 서로간에 주고 받을 수 있는 패킷의 단위를 약속합니다. 이 값의 최대치는 1460이고 IP헤더를 합하여 1500이 네트워크를 통해 전달 되는 MTU값이 됩니다. 그리고 Pad라고 있는곳은 최소값을 보정해주는 건데 1460의 공간안에 아무런 값이 없다면 최소값 46byte이 Pad값으로 붙여집니다. 데이터가 1b가 있다면 pad는 45가 됩니다. 이유는 에러체크(CRC)나 그런 용도 때문에 그런겁니다.

프레임 길이 외에있는 preamble, SFD, IFG는 네트워크 장비내에서 처리하는 정보입니다. 실제 장비가 Qos를 사용중이라면 패킷하나하나에 마킹을 하고 우선순위를 정해 패킷을 제어하게 됩니다. (이 패킷은 해로운 패킷이다.)

두번째의 경우는 VLAN태그라고 VTP를 위한 목적으로 사용되는 값으로 조금 더 패킷에 값이 붙습니다. 하지만 이 경우는 큰 건물에 회사사원이 층간, 부서간 서로 통신 여부를 관리하기 위하는 목적이라서 웹사이트 서버 구성에서는 거의 사용하지 않습니다.

마지막으로 점보 프레임이란건데 1개의 패킷에 최대 9K까지 실어보낼 수 있어 통신속도를 높일 수 있습니다. 단, 소스와 목적지의 통신 구간안의 모든 기기가 점보 프레임을 지원해야하는 조건이 있기 때문에 L3 layer 환경에서는 사용할 수 없습니다. 중간에 점보를 사용안하는 기기가 있다면 해당 패킷을 플래그먼트시키거나 패킷 자체를 버리게 되어 통신 불능에 빠지게 됩니다.

그림 밑에 PPS라고 적혀 있는게 있는데요. Packet per Second라고 초당 전송 패킷 수 입니다. 이것은 byte량이 아니라 패킷 자체를 하나의 단위로 봅니다. NW기기는 Backplane이라고 성능스펙이 있는데 기기 내부에서 초당 얼마나 많은 PPS의 처리가 가능한지를 기준으로 삼고 있습니다. 그렇기 때문에 대역폭이 적더라도 PPS 수가 많아지면 통신이 느려지거나 나빠지는 원인이 됩니다. 1Gbps 인터페이스가 패킷의 최소 단위인 672bit를 기준으로 처리 가능한 최대 패킷수는 송수신 관계없이 총합 1.5Mpps입니다. 1460의 꽉찬 패킷으로 1Gbyte를 전송하게 되면 이 값은 오히려 떨어지게 되어 좋은 전송 효율을 보기에 됩니다.

Bps가 얼마냐보다 이 값이 얼마나 높아지는가에 따라서 성능에 영향을 받습니다. 일반적인 Cisco 3750정도의 기계는 내부 스펙이 30Mpps정도쯤 합니다. 이곳에 ASIC칩이 있는 10G 모듈을 달면 좀 더 높은 PPS를 가지게 됩니다.

이번에 성능 추이는 패킷 하나당 실어나를 수 있는 사이즈가 1460byte인 상태에서 언제 1Gbps와 1.5Mpps에 도달하느냐를 기준으로 삼았습니다.

TCP Window size

64K가 TCP Window size 최소단위라고 하던데 그렇게만 알고 있으실텐데 말이죠. TCP Window size는 TCP/IP가 고신뢰성의 프로토콜로 존재하게끔하는 아주 중요한 값인데요. 요즘 현대에 들어서는 장비들의 고스펙과 통신 대역폭의 증가로 이제는 오히려 속도에 방해만 주는 원인으로 지목되고 있습니다. ㅠㅠ 이제는 현대의 OS나 프로그램은 기본 기준을 맞춰서 데이터를 잘라보내지 않고 전송 상황에 따라 TCP Window size를 가변해서 처리하게 됩니다.

이런 상황에서 위 성능을 추이하기 위한 TCP/IP의 대역폭 계산식에 어떤 값을 넣어야 올바른가에 대한 기준 자체가 모호해지기 때문에 보다 객관적인 성능 추이를 관찰하기 어려워지게 되었는데요. 저는 위의 도표 MSS 정수배의 62,240byte를 기준으로 선정 하였습니다. MSS를 기준으로 보다 높은 TCP Windows size는 Window Scaling되기 때문에, 그리고 이번 목적은 RTT를 통해 대역폭을 찾는게 아니기 때문에 62,240이 타당하다고 생각합니다.

시뮬레이트 해보기

다시 이론치로 돌아왔습니다. 조건 1은 TCP Window size가 MSS 정수배일것. 그리고 4,5,6을 통해 실제 패킷의 전송될 최종 용량을 계산하고 어느 시점에서 네트워크에 Bottleneck이 생기는지를 계산했습니다. 참고로 Bottleneck이라고 해서 손실을 의미하는건 아닙니다. 병목을 주는쪽이 서버에서 보내는 데이터라서 NW기기들은 부하를 감지하면 Path MTU Discovery라는 code가 포함된 패킷을 서버로 보내게 되는데 이 패킷을 서버가 받게 되면 보내는 동작을 멈추게 됩니다.(PMTUD가 활성화가 안되어있다면 무시하고 보내게 됩니다.)

아, 그리고 요청되는 패킷 정보라는게 유저가 서버에 보내는 Get HTTP 1/1 요청 정보인데 이게 대략 300~500byte 정도라서 추정치로 넣었습니다.(추정입니다.-_-)

결과로 보자면 초당 메인페이지를 240번 요청하여 계속 유지하게 되면 접속에 문제가 나타나며 이보다 많은 요청이 들어오면 통신이 어려워지게 됩니다.

SOLUTION

어디까지나 xetown.com의 서버가 1Gbps 싱글 인터페이스일거라는 가정의 계산이었지만 내 생각에 아래의 조정을 한다면 보다 더 많은 요청을 수용 가능할거라고 생각합니다.

1. CDN 활용
Font Awesome나 jquery 라이브러리를 전부 내부에서 읽고 있네요. 여러곳에 중복되는 소스라면 CDN을 적극 활용해야합니다. 지금은 500kb이지만 라이브러리를 타 사이트로 돌리게 된다면 적은 트래픽으로 요청이 이뤄지지 않을까 생각합니다.

2. 그림파일 압축
많은 그림파일을 보내오고 있네요. 캐시하기 때문에 2회째부터는 읽지 않겠지만 성능개선은 최초 접속에 최소 트래픽으로 대응해야하는게 목적이기 때문에 메인페이지에 많은 그림 노출은 되도록 피하거나 이미지 압축(http://www.imgopt.com/)을 하거나, 아니면 아마존 S3같은 가상서버에 올려놓고 트래픽을 분산하는게 좋아보입니다.

3. js, css파일의 압축(merge)
압축의 중요성. include jquery.load @Import이런게 아니라 하나의 파일에 소스를 담아두는것이 포인트입니다. 용량 압축도 중요하지만 불러오는 파일은 줄여야 하는게 통신 환경에 도움이 됩니다. 위에 패킷과 pps 부분에서도 설명했지만 MTU 사이즈보다 적은 값을 가지는 파일들은 불필요한 pad를 생성하기 때문에 좋지 못하며 하나의 패킷에 많은 양을 담아서 보내는게 PPS를 줄이는 지름길입니다.

4. 서버 이중화
당연한 이야기지만 이런것 때문에 서버를 이중화하는 거죠. 1Gbps로는 서버의 성능고갈 이전에 다른곳에서 문제가 생기기 때문에 되도록이면 웹서버 이중화+DB서버 구성이 좋고 서버가 싱글이면 인터페이스 2개를 Teaming 하여 대역폭을 늘리시는게 효과적입니다.

여담

공홈에 XE성능 100배 올리는 패치로 게시글이 있습니다. 아파치의 성능 테스트 기능인가요? 아래의 성능으로 Time Per request의 효과를 얻었다고 적어놓은거 같은데 보시면 Transfer rate가 261MB/s입니다. 이미 이 서버의 웹페이지는 외부에서는 볼 수 없게 되는거죠. 이런게 서버 성능만 가지고 추이를 판단할 수 없는 경우죠.(반대로 생각해보면 10000요청에 저정도 전송량이라는것은 웹페이지가 잘 최적화 되어있다는게 되는거겠죠. 아니면 기본페이지이거나...)

$ ab -n 10000 -c 100 http://localhost/
Requests per second:    12813.79 [#/sec] (mean)
Time per request:       7.804 [ms] (mean)
Time per request:       0.078 [ms] (mean, across all concurrent requests)
Transfer rate:          261932.47 [Kbytes/sec] received

xetown도 제가 추정하고 있는게 맞는 수치인지 아래를 통해 객관적으로 판단해보면 좋을 것 같습니다.

$ ab -n 240 -c 240 http://localhost/

다른 곳

일본어로 만든 자료를 역 번역하는건 너무나 어려워... =ㅁ=

TCPsimulate.xlsx