2009년 1월호로 월간 마이크로소프트웨어에 기고한 기사입니다.
기존의 웹 사이트 성능 튜닝 강좌와 중복되는 내용도 있습니다.
PDF & XPS문서: 
웹사이트 오해와 진실.zip
두말하면 잔소리겠지만 웹 사이트의 성능을 높이는 일은 굉장히 중요하다. 사용자가 해당 서비스를 판단하는 가장 중요한 잣대도 바로 사이트의 성능이다. 하지만 우리는 웹 사이트 성능에 대한 많은 오해를 가지고 있다. 때문에 이번 강좌에서는 그 오해와 그 뒤에 숨이었던 진실은 무엇인지 살펴볼 것이고, 웹 사이트 튜닝을 위한 몇 가지 지침 또한 소개하도록 하겠다.
사이트는 왜 느려지는 걸까?
가끔 필자에게 닷넷 프로젝트 성능 튜닝에 대한 요청이 들어오곤 한다. 그 요청 내용의 대부분은 DB는 이상이 없고 프로그램 로직도 크게 문제가 없는 것 같은데 왜 프로그램이 느린지 모르겠다는 것이다. 즉, 이 말은 어디에서 어떤 시간들이 소요되고 있는지 진단하지 못하고 있다는 것이다. 이 문제를 해결하기 위해서는 과연 어떠한 요소들이 사이트의 성능을 결정하는지 알아야 한다. 웹 사이트에서 성능을 결정하는 요소는 다음 그림처럼 3가지 요소로 구분할 수 있다.
[그림1] 웹 사이트의 성능을 결정하는 3가지 요소
사이트의 성능을 진단해 보고자 한다면 이 그림에서처럼 서버, 네트워크, 브라우저 동작을 진단해야 한다. 하지만 대부분 웹사이트의 성능을 튜닝이다라고 한다면 주로 서버 단의 작업에 집중해서 작업을 하는 것이 일반적일 것이다. 예를 들자면,
| ''어, 이거 사이트 느리네, DB튜닝 좀 부탁해볼까?" "우리 미들웨어에 COM+를 적용하면 좀 빨라 지려나?" “클래스 설계가 잘못되어서 느린 것이 아닐까?” |
하지만 회사의 업무를 위한 백오피스를 위한 웹 사이트가 아니라면 즉, 아주 많은 양의 데이터를 다루는 사이트가 아니라면 서버 단의 동작은 일반적으로 웹사이트 성능에 큰 영향을 주지 않는다. 또한 초보 프로그래머가 짠 조금 좋지 않은 프로그램 로직이라고 하더라도 그것이 성능에 큰 영향을 주지는 않는다. 이 내용은 바로 다음 절에서 자세히 설명하도록 하겠다.
서버 단보다도 일반적으로 브라우저의 동작(UI단)과 네트워크에서 더 많은 영향을 주게 된다. 네트워크의 경우 사용자와 서버가 지리적으로 먼 곳에 위치해 있다면 수많은 라우터를 거치면서 네트워크의 통신속도는 느려지게 된다. 그래서 도입하는 기술이 바로 CDN(Contents Delivery Network) 이라는 서비스이다. 하지만, 한국에서만 서비스를 적용한다면 거리 때문에는 크게 성능에 문제가 생기지 않을 것이다. 단, 동영상과 같은 큰 파일을 서비스할 때는 다르지만 아무튼 우리나라는 땅도 좁고 초고속 인터넷 망이 설치되어 있는 인터넷 강국(단, 인터넷 강국일 뿐이고..)이기 때문에 크게 거리에 대해서 걱정할 필요는 없다. 전세계적으로 서비스 하는 다국어 버전의 사이트라면 CDN이나 네트워크 문제에 신경을 써야 할 것이다. 하지만 이런 네트워크의 속도들은 개발자가 어떻게 조율할 수 있는 영역이 아니기 때문에 성능과 관련된 내용은 다루지 않을 것이다.
웹사이트 성능의 오해와 진실
그럼 여기서 개발자가 성능을 진단해야 할 부분은 크게 두 가지로 볼 수 있다. 바로 서버 단(Backend)과 브라우저의 동작(Frontend)이다. 쉽게 말하자면 서버 단은 프로그래밍 언어가 HTML을 만들어 내기까지의 동작이 해당되는 것이고 그 이후에 일어나는 브라우저의 동작은 UI단이 되는 것이다. 백오피스 시스템의 경우 서버 단의 동작에 좀 더 무게를 두게 될 것이고 일반 서비스 사이트의 경우 UI(브라우저)단의 동작에 무게를 두게 될 것이다. 이번에 성능 튜닝은 백오피스 시스템에서 사용되는 사이트가 아닌 일반 서비스 사이트의 성능을 살펴볼 것이다.
앞에서 서버 단의 경우 성능의 비중이 높지 않다고 언급했었다. 그럼 야후에서 성능튜너로 일하고 있는 스티브 사우더스의 조사 결과를 살펴보도록 하자. 스티브 사우더스는 야후 사이트를 처음 방문했을 때 서버와 UI단의 비율을 조사해 보았다.
[그림2] 야후사이트를 방문했을 때
HTML을 생성해서 내려주는 부분이 서버단이 되고 그 뒤에 브라우저의 추가적인 요청에 의해서 일어나는 작업들이 바로 UI단이 된다. 그랬을 때의 비율은 5:95로 나타나지는 것을 볼 수 있었다.
[그림3] 야후 사이트의 성능 비교
그럼 재 방문했을 때의 비율은 어떻게 될까? 처음 방문했기 때문에 느려지는 것은 아닐까? 재방문 하게 될 경우 인터넷 임시폴더에 저장되어 있는 파일들을 이용하기 때문에 빨라지지 않을까? 그것도 염두하고 테스트 했지만 다음과 같은 결과가 나오게 되었다.
[그림4] 재방문 했을 때의 야후 사이트의 성능 비교
재 방문을 해도 야후는 UI단에서 88%의 성능을 차지하고 있는 것이다. 그럼 야후만 그런 것 아닐까? 다른 사이트들은 괜찮지 않을까? 이러한 의문이 있을 것 같아서 스티브 사우더스는 미국 상위 10개의 사이트들의 성능 비율을 조사하였다. 다음 그림을 살펴보자.
[그림5] 미국 상위 10개 사이트의 성능비율
보는 것과 같이 처음 방문시 대부분 80~90%의 성능을 차지하고 있는 것을 볼 수 있다. 그리고 캐시를 이용한다고 하더라도 마찬가지로 80~90%의 비율을 보이는 것을 볼 수 있다. 구글의 경우 재 방문시의 비율이 비교적 적은 것을 볼 수 있는데 이것은 구글이 그만큼 컨텐츠를 조금 내려주려고 노력하였고 그 컨텐츠가 굉장히 적기 때문이다. (구글에 대한 자세한 내용을 알고 싶다면 필자의 블로그 blog.hoons.kr의 “구글 웹사이트의 고성능의 비결”이라는 포스트를 참고하길 바란다.)
이만큼 일반 사이트에서는 UI단의 비중이 그만큼 크다는 것이다. 우리는 일반적으로 사이트를 튜닝하기 위해서 DB를 새로 구성하거나 서버의 아키텍처를 새롭게 짜거나 할 것이다. 하지만 이러한 튜닝은 굉장히 많은 비용과 시간을 필요로 한다. 그리고 중요한 것은 10% 밖에 안 되는 서버 단의 성능을 50%나 올린다 하더라도 실제로는 5%밖에 튜닝되지 않은 것이기 때문에 체감적으로 느낄 수 있는 속도는 얼마 안 된다는 것이다. 반면에 여기서 설명할 UI단의 성능을 굉장히 쉽게 튜닝 할 수 있을 뿐만 아니라 웹 사이트의 성능을 올릴 수 있는 가능성도 굉장히 크다는 것이다.
성능진단 도구
그렇다면 성능은 어떻게 진단해야 할까? 먼저 어떤 웹 사이트의 성능을 튜닝한다고 한다면 서버단, UI단, 네트워크단 이 3가지 요소 중에 어떤 부분에 문제가 있는지 진단해야 한다. 이 진단을 위해서 우리는 브라우저 통신 패킷을 보여주는 툴을 설치해야 한다. 그럼 어떤 툴을 이용해야 할까? 여러 도구가 있지만 필자가 추천하는 툴은 브라우저 진단 도구인 IE Watch(http://www.iewatch.com/)라는 툴을 추천한다. 이 툴은 30일 평가 판으로 다운받아 30일 동안은 자유롭게 사용할 수 있다. 그리고 이 툴은 HTTP 프로토콜이 어떻게 요청되고 응답되고 있는지 보여줍니다. 유사한 툴로는 피들러와 HTTP핸들러와 같은 툴들이 존재한다. 하지만 이 툴은 HTTP 요청에 대한 시간들을 그래프로 보여주기 때문에 유료지만 추천하는 것이다.
그럼 이 툴을 가지고 어떻게 사이트의 성능을 진단해야 할까? 먼저 HOONS닷넷을 진단한다고 가정해 보겠다. 다음 화면은 HOONS닷넷 사이트를 IEWatch로 분석해 본 결과를 보여주고 있다.
[화면1] HOONS닷넷의 분석
브라우저는 먼저 HTML 문서를 TCP를 이용하여 호출하여 받게 된다. 그리고 HTML안에 포함된 여러 요소들을 다운 받게 된다. 여기서 그 HTML이 바로 서버 단의 동작시간이고 그 다음 브라우저에 포함된 구성요소들을 다운 받는 시간들이 바로 UI 단의 동작시간인 것이다. 이 시간만 보면 어디에서 문제가 생기는 것인지 쉽게 알 수 있을 것이다. HOONS닷넷 사이트의 경우 서버 단 동작시간은 전체속도에서 35%초 소요되는 것을 볼 수 있다. HOONS닷넷의 경우는 이미지나 스크립트와 같은 기타 구성요소들을 많이 사용하고 있지 않기 때문에 30% 정도 밖에 되지 않는 것이다. S.I의 경우 서버 단의 비중이 조금 더 높을 것이고 서비스 업체의 경우 이 비중이 더 높을 것입니다. 그럼 실제로 많은 사용자들을 서비스하고 있는 국내의 게임 포털 사이트를 살펴보도록 하자. 다음 화면은 어떤 포털사이트의 속도를 캡쳐한 화면이다.
[화면2] 국내 게임 포털 사이트의 분석
이 게임 사이트의 경우 서버 단의 실행 속도가 전체의 약 10%밖에 되지 않고 UI단의 동작 시간은 90%나 차지하고 있는 것을 볼 수 있다. 이 툴을 이용한다면 그래프로 시간들을 그려 주기 때문에 보다 직관적으로 확인할 수 있을 것이다.
야후의 Yslow
야후 성능팀의 매니저 스티브 사우더스는 성능을 최적화 시키기 위한 14가지 팁을 제공하고 있다. 그 팁은 다음과 같다.
| 규칙1 ? HTTP 요청을 줄여라 규칙2 ? 컨텐츠 전송 네트워크를 이용하라 규칙3 ? 헤더에 만료기한을 추가하라 규칙4 ? Gzip 컴포넌트를 이용해라 규칙5 ? 스타일시트를 위에 넣어라 규칙6 ? 스크립트를 아래에 넣어라 규칙7 ? CSS Expression을 피해라 규칙8 ? 자바스크립트와 CSS를 외부파일에 넣어라 규칙9 ? DNS 조회를 줄여라 규칙10 ? 자바스크립트를 최소화하라 규칙11 ? 리다이렉트를 피해라 규칙12 ? 중복되는 스크립트를 제거하라 규칙13 ? ETag를 설정하라 규칙14 ? 캐시를 지원하는 Ajax 만들기 |
[14가지 규칙]
이 14가지의 팁을 이용해서 튜닝 한다면 UI단의 성능을 50% 이상은 충분히 올릴 수 있을 것이다. 그리고 야후에서는 Yslow라는 도구를 제공해주고 있다. 이 도구는 위와 같은 14가지 규칙들을 얼만큼 지키고 있는지 확인해볼 수 있다. 그리고 규칙 각각 등급을 표시하고 어떤 컨텐츠가 잘못되었는지도 보여주게 된다. 즉, 이 툴만 있다면 어느 정도 성능 튜닝이 가능하다는 것이다. 다음 화면은 HOONS닷넷을 YSlow로 돌려면 화면이다.
[화면3] Yslow를 이용한 등급측정
필자의 사이트는 전체 등급은 F를 받았고 점수는 45를 받았다. 굉장히 낮은 점수다. 학교에 다니면서도 받기 힘든F를 여기서 받아 버린 것이다.(ㅠㅠ) 하지만 국내의 상위 사이트들도 등급을 측정해 보면서 필자는 다시 안도의 한숨을 쉬게 되었다. 다음 그림은 국내 상위 사이트의 등급을 보여주고 있다.
[그림6] 국내 사이트의 YSlow 측정 (2008/04기준)
물론 필자가 테스트하는 환경에 있어서 응답시간에는 많은 변수가 있을 것이다. 그 밖에 페이지의 무게와 등급을 살펴보도록 하자. 보면 외국사이트의 경우 상당히 높은 등급이 매겨지는 것을 볼 수 있지만 국내의 사이트들은 대부분 낮은 등급이 매겨지는 것을 볼 수 있을 것이다. 이 등급이 낮다는 것은 그만큼 사이트 성능을 올릴 수 있는 가능성이 많다는 것이기 때문에 긍정적으로 받아드려야 한다.
그렇다면 YSlow의 등급과 실제로 사이트의 성능과 비례한 것인지 궁금할 수 있을 것이다. 다음 그래프는 YSlow와 페이지의 관계를 보여주고 있다.
[그림8] 페이지 무게, 응답시간, YSlow등급의 관계
이 그래프에서 볼 수 있듯이 YSlow등급과 페이지의 무게와 그리고 응답시간은 거의 비례하고 있는 것 볼 수 있다. 즉, 이 말은 YSlow 툴에 최적화 시킨다면 그만큼 응답시간은 줄일 수 있고 페이지를 가볍게 만들 수 있다는 것이다.
브라우저의 동작
UI단의 성능을 튜닝하기 위해서는 기본적인 브라우저 동작의 개념을 명확하게 가지고 있어야 한다. 특정 웹 사이트를 처음 방문할 경우 HTML뿐만 아니라 이미지, 스타일시트, 스크립트 등 모든 구성요소들을 자신의 PC로 다운 받게 된다. 다음 그림은 어떤 게임 포털 사이트를 처음 방문했을 때 순차적으로 다운되는 모습을 보여주고 있다.
[사이트를 처음 방문할 경우의 동작구조]
이 사이트는 총 157번의 HTTP 요청을 만들고 있고 페이지 전체 크기는 약 1.1메가 정도 되는 것을 볼 수 있다. 그리고 가운데 상태코드(Status)를 보면 처음 302를 빼고 모두 200을 반환하고 있는 것을 볼 수 있을 것이다. 동작 순서를 요약하자면, 브라우저는 처음에 HTML을 다운 받는다. 위의 분석 결과를 보면 HTML을 다운 받는 시간은 약 0.234초가 소비된 것을 볼 수 있다. 앞에서 설명했듯이 이 시간은 바로 서버 단의 동작으로 봐도 무방하다. (실제로 전달되는 시간을 빼야 하겠지만..) 그 뒤에 브라우저는 HTML을 분석하여 문서 위에서부터 차례대로 구성요소(플래쉬, 스크립트, 이미지등)들을 다운로드 하게 된다. 그렇게 모든 구성요소를 다운 받는 시간은 약 2.3초가 걸리게 된 것이다. 그리고 다운로드 된 구성요소들은 인터넷 임시파일 폴더에 저장한다. 여기서 중요한 것은 브라우저는 다운로드를 진행하면서 로딩되는 과정을 눈으로 볼 수 있게 지원하고 있다는 것이다. 즉, 다운받는 즉시 브라우저에 표현해 주고 있다는 것이다.(너무 당연한 거인가) 만약 그렇지 않으면 우리는 사이트가 굉장히 느리다고 생각할 것이다. 하지만 이런 로딩 화면을 지원하지 않게 될 경우가 있다. 이 내용은 다음 번 팁에서 다루게 될 것이다.
그럼 이 페이지를 다시 한번 호출해 보면 어떻게 될까? 사이트를 2번째 방문하게 될 경우 처음 다운 받았던 여러 구성요소들은 이미 인터넷임시 폴더에 저장되어 있는 상태가 된다. 그럴 경우 브라우저는 어떻게 동작되는지 살펴보도록 하자.
[화면5] 두 번 방문 했을 때의 상태
두 번째 방문할 경우 전체 응답시간이 1.5초로 줄어든 것을 볼 수 있다. 여기서 페이지 사이즈는 전달된 양과는 무관한 전체 구성요소의 합계를 나타내고 있습니다. 때문에 필자는 IBM 패킷 탐지기로 전체적으로 얼마나 다운받게 되는지 관찰해 보았다. 관찰해 본 결과 전체 사이즈는 0.16M 정도 되는 것을 확인할 수 있었다. 왜냐하면 이전에 이미 다운 받아 놓은 구성요소들이 인터넷 임시파일 폴더에 저장되어 있기 때문에 변경되지 않았다면 다시 다운로드 되지 않기 때문이다. 그런데 왜 요청 수는 155로 줄지 않을 것일지 의문이 들 수 있을 것이다. 그 이유는 브라우저는 구성요소가 디스크에 존재할 경우 이 요소가 변경이 되었는지 확인하는 요청을 보내게 되는 것이다. 전문적인 용어로 조건부 Get요청(Conditional Get Request) 이라고 한다.서버에게 수정되었는지 물어보고 만약 수정되지 않았다면 304 응답을 보내게 되고 수정되었다면 그 파일을 다시 보내주게 됩니다. 그렇기 때문에 HTTP요청은 반드시 일어나게 되는 것이다. 위의 화면을 보면 페이지의 구성요소들의 상태코드들이 304라는 응답을 받는 것을 볼 수 있을 것이다.
브라우저는 요청?응답(Request-Response) 방식으로 각각 서버에 요청하고 그 응답들을 받아 처리하게 된다. 브라우저는 다음과 같은 요청을 보내게 되고, 이 사이트에서는 아래와 같은 요청들이 155번 일어났다고 보면 된다. 다음 요청은 이 사이트의 로고가 수정되었는지 물어보는 요청이다.
브라우저->서버
| GET /logo_nx.gif HTTP/1.1 Accept: */* Accept-Language: ko UA-CPU: x86 Accept-Encoding: gzip, deflate If-Modified-Since: Fri, 25 Jan 2008 08:39:11 GMT If-None-Match: "5f655c22d5fc81:6f" User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; .. Host: s.nx.com Connection: Keep-Alive 응답(Reponse) |
서버->브라우저
| HTTP/1.1 304 Not Modified Date: Mon, 03 Mar 2008 12:12:44 GMT Etag: "5f655c22d5fc81:6f" |
YSlow에서 언급한 14개의 규칙만 알고 있다면 이 요청-응답의 헤더들만 보아도 어떤 부분을 튜닝 해야 할지 대충 구상이 잡힐 것이다. 튜닝을 위해서는 이 응답과 요청의 헤더들의 뜻을 이해하고 있어야 한다. W3G 홈페이지(영문)를 방문해서 HTTP에 대한 스펙을 찾아보면 이 속성들에 대한 스펙을 정의하고 있는 것을 볼 수 있을 것이다.
그럼 서버에서는 이 이미지가 최신 버전인지 어떻게 확인 해야할까? 이것은 HTTP 버전과 IIS의 설정에 따라 다르다. HTTP 버전은 1.0과 1.1이 존재하지만 대부분의 브라우저들은 1.1을 사용하고 있다. HTTP 1.1을 이용할 경우 서버는 Etag라는 것을 브라우저에게 발행하게 된다. Etag는 파일의 정보와 IIS 서버의 정보를 요약하여 만들어지는 파일의 고유한 아이디와 같은 값이라고 보면 된다. HTTP1.1을 이용할 경우 IIS의 서버에서 별다른 작업이 없을 경우 Etag값을 이용해서 파일이 서버의 내용과 일치하는지 확인하게 된다. 위의 요청(Request)을 보면 If-None-Mach를 보내게 되는 것을 볼 수 있다. (If-None-Match: "5f655c22d5fc81:6f") 그리고 만약 HTTP1.0을 이용하고 있을 경우 최근 수정 일을 통하여 파일을 비교하게 되는 것이다.( If-Modified-Since: Fri, 25 Jan 2008 08:39:11 GMT) 여기서 이 포털 사이트는 Etag를 사용하고 있는 것을 볼 수 있는데 ETag는 성능을 떨어뜨리는 문제를 가지고 있다.
그렇다면 이 사이트의 성능을 올릴 수 있는 몇 가지 방법들을 간략하게 요약해 보겠다. 먼저 캐시의 만료기한을 지정하여 파일이 수정되었는지에 대한 확인 요청을 만들지 않게 할 수 있다. 그리고 여러 가지 귀찮은(?) 방법들을 적용해서 HTTP 요청을 최소화한다면 20% 이상의 성능을 올릴 수 있을 것이다. 그리고 텍스트 파일들은 압축을 적용할 수 있지만 이 사이트에서는 적용하지 않고 있었다. 또한 굉장히 많은 스크립트들을 사용하고 있지만 최소화 하지 않고 사용하고 있다. 그리고 스크립트를 배치시킨 위치 또한 좋지 않았다. 마지막으로 동시 다운로드를 이용하여 보다 빠르게 다운 받게 할 수도 있다. 이 밖에도 간단하게 성능을 튜닝 할 수 있는 내용들이 더 있을 것이다. 이 내용들은 다음 회차에서 천천히 살펴볼 것이다.
성능을 높여야 하는 이유
당연하고도 뜬금없는 제목이 놓여져 있다. 성능을 왜 높여야 하냐는 것이다. 웹 사이트의 성능을 왜 높여야 하는지 한번 물어보도록 하겠다.
“아니 그거야 당연한 거지 사이트 속도가 높아야 사용자가 편하게 이용할 수 있을 것이고 그만큼 많이 올 수 있다는 거잖아. 사용자가 많으면 우리회사의 매출이 높아지는 거 아냐?”
“딩동댕!” 정답이다. 그럼 얼만큼의 사용자가 늘어나고 얼만큼의 매출이 증가하게 될 것인지 궁금해 할 것이다. 미국에서 구글과 아마존을 대상으로 다음과 같은 조사 결과를 발표하였다. 이 자료는 http://home.blarg.net/~glinden/StanfordDataMining.2006-11-29.ppt 에서 제공한 자료로 더자세한 정보는 이 링크를 확인해보길 바란다. 조사 결과는 다음과 같다.
[그림7] 야후와 아마존의 성능
구글에서 0.5초만 느려졌을 뿐인데 트래픽이 1/5이나 줄게 되었다. 실로 엄청난 통계이다. 더욱이 놀라운 것은 아마존의 결과이다. 아마존의 경우 단 0.1초만 느려졌을 뿐인데 판매율이 1%나 줄어든 것이다. (난 0.1초만 느려졌을 뿐이고…) 그렇다면 20%의 트래픽과 1%의 판매율은 어떤 수치일지 살펴보도록 하자.
| 구글: 매월/ 2700만 명의 사용자 감소 아마존: 분기/ 약 500억 원의 매출손해 |
백분율을 수치화 시켜본 결과 이러한 어마어마한 통계가 나오는 것을 볼 수 있다. 이만큼 웹 사이트의 성능은 굉장히 중요한 요소 중에 하나이다.
정리
이번 시간에는 웹 사이트의 성능의 오해와 진실에 대한 내용을 살펴보았다. 중요한 핵심은 웹 사이트 응답시간의 80~90%는 UI단의 동작에서 소비된다는 것이고 이 말뜻은 성능을 올릴 수 있는 가능성이 더 크다라는 것이고 그만큼 더 간단하다는 것이다. 이 튜닝을 위해서 14가지의 규칙들을 제공해주고 있는데 이 내용은 다음 시간에 왜 이렇게 해야 되는지에 대한 이유와 함께 살펴보도록 하겠다.
Tools Download
IEWatch: http://www.iewatch.com/
IBM Page Detailer: http://alphaworks.ibm.com/tech/pagedetailer
YSlow & Firebug: http://developer.yahoo.com/yslow/
Reference
웹 사이트 최적화 기법(ITC출판사)
http://developer.yahoo.com/performance/rules.html
Steve Souders(souders@yahoo-inc.com)의 High Performance Web Sites PPT