HTTP Compression (III) : IIS Support

HTTP 압축을 사용하는 방법은 여러가지가 있다. 손쉬운 방법은 HTTP 압축을 수행하는 소프트웨어 혹은 하드웨어(!)를 구입하는 것이다. XCompress 제품과 같은 소프트웨어는 IIS의 ISAPI 필터를 통해 HTTP를 압축해 준다. 이 회사의 제품 중에는 NIC 하드웨어 수준에서 HTTP 압축을 지원하는 경우도 있다. 비용에 부담이 간다면(공짜를 좋아한다면) 공개 소프트웨어로서 ISAPI 필터 모듈을 사용할 수도 있다. FlatCompression 이란 ISAPI 필터는 소스가 공개된 HTTP 압축 모듈이다. 비록 상용 제품처럼 기능이 풍부하지 않지만 사용하는데 무리가 없다고 한다. (필자는 사용해 본적이 없다)

IIS 5.0

HTTP 압축을 위한 소프트웨어를 멀리서 찾을 필요는 없다. 바로 IIS가 HTTP 압축 기능을 이미 제공하기 때문이다(웬만하면 다 지원된다... 독립 소프트웨어 개발사(자)는 뭐 먹구 살으라구... 드러버서... -_-). HTTP 압축은 Windows 2000에 포함된 IIS 5.0부터 제공되는 기능이다. IIS 5.0에 포함된 HTTP 압축은 여러가지 문제를 가지고 있었다고 한다. 구글에서 IIS gzip compression 이란 키워드로 검색해 보면 IIS 5.0의 HTTP 압축을 성토하는 여러 글들을 찾아볼 수 있다. 특히 XCompress 제품 정보에서 IIS 5.0의 문제점을 상세히 지적하고 있다. (필자가 보기에는 자사 제품을 홍보하기 위한 내용으로 보이며, 현재에는 IE의 버전업과 서비스팩을 통해 극복한 것으로 보인다. Windows 2000으로 서비스를 하는 독자가 있다면 IIS 압축 함 테스트 해보고 결과 알려주면 대단히 댕큐하겠다... 알리도~~~)

IIS 5.0의 압축 버그가 해결되었건 그렇지 않았건 중요한 결점은 IIS 5.0에서 제공하는 HTTP 압축의 핵심적인 문제점은 HTTP 압축의 적용 여부가 서버 단위로 결정된다는 것이다. 즉, 한 웹 서버가 2개 이상의 웹 사이트를 호스팅하는 상황에서 선택적으로 한 사이트에서만 HTTP 압축을 사용하도록 세팅할 수 없다는 것이다. 한대의 웹 서버에서 여러 웹 사이트를 호스팅하는 경우에는 치명적이라 할 수 있게따. 뭐 모든 사이트에서 HTTP 압축을 적용하게따면 문제가 없겠지만... 쩝...

IIS 5.0의 HTTP 압축 설정은 IIS 6.0과 비슷하므로 구체적인 설정방법은 여기서 다루지 않겠다. (사실 필자도 IIS 5.0에서 압축을 설정해 본적이 없다... -_-)

IIS 6.0

IIS 5.0의 압축을 성토하는 글들을 살펴보면 공히 IIS 6.0에서 HTTP 압축이 매우 잘 작동한다는 내용이 포함되어 있다. IIS 6.0의 HTTP 압축 기능은 이전 버전에 비해 안정적으로 작동하며 IIS 5.0에서 제공하지 않는 폴더 혹은 파일별로 압축을 지원한다. IIS 6.0의 HTTP 압축을 사용하기 위한 방법을 이제부터 살펴보자. 여기 내용은 Microsoft TechNet의 IIS Operation Guide 내용과 인터넷 상의 여러 블로그, 자료를 킁킁거리며 돌아다닌 내용 및 필자가 직접 테스트하고 권장하는 방법의 짬뽕이 되겠다. (빡셨다... -_-)

IIS 6.0은 HTTP 압축 기능을 ISAPI 필터 형태로 제공한다. 이 ISAPI 필터는 C:\Windows\System32\Inetsrv 폴더에 gzip.dll 이란 이름으로 존재한다. 인터넷 상의 IIS 6.0 압축에 대한 글들을 검색해 보면 이 DLL에 대해 "웹 서비스 확장"에서 ISAPI를 허용해야 한다는 글들이 있지만 필자가 확인해 본 결과 이러한 설정은 필요하지 않았다. HTTP 압축 설정은 IIS 관리자를 통해 손쉬운 설정을 수행하거나, adsutil.vbs 스크립트를 사용하거나, 메타베이스를 직접 수정하는 등의 방법을 사용할 수 있다. 먼저 IIS 관리자를 사용하는 방법부터 살펴보자.

Compression Setting using IIS Manager

IIS 관리자를 수행하고 웹 사이트 폴더(기본 웹 사이트가 아님에 유의하라)를 오른쪽 클릭하여 등록정보를 연다. 웹 사이트 등록정보가 나타나면 서비스 탭을 선택한다. 화면1 과 같은 대화상자가 나타날 것이다. 하단의 HTTP 압축 설정을 이용하면 된다.

화면1. HTTP 압축 설정 (IIS 관리자 이용)

응용 프로그램 파일 압축은 ASP, ASP.NET, ISAPI 확장(Extension), CGI(exe) 등 정적인 파일이 아닌 컨텐츠가 동적으로 생성될 때 압축을 사용할 것인가를 설정한다. 반면 정적 파일 압축은 .htm, .html, .txt 등과 같이 런타임에 변하지 않는 정적 컨텐츠를 압축할 것인가를 결정한다.

동적 컨텐츠 압축은 매 스크립트(ASP, ASP.NET 등)가 수행될 때마다 컨텐츠가 달라질 수 있으므로 IIS는 매번 컨텐츠를 압축한다. 반면 정적 컨텐츠 압축은 컨텐츠가 매번 변하지 않으므로 컨텐츠를 압축하여 별도의 디렉토리에 저장해 둔다. 그리고 나중에 동일 컨텐츠가 요청되면 이미 압축되어 있는 파일을 반환한다. 매번 압축을 수행하지 않으므로 보다 나은 성능을 기대할 수 있다. 물론, 원본 컨텐츠가 변경되면 IIS는 변경된 컨텐츠를 감지하고 다시 압축을 수행할 것이다. 여기서 한가지 알아두아야 할 사항은 정적 컨텐츠를 최초로 요청했을 때 IIS는 곧바로 압축을 수행하지 않고 압축 큐에 컨텐츠를 집어 넣는다. 그리고 최초의 요청에 대해서는 압축되지 않은 컨텐츠를 내보낸다. 압축 테스트를 할 때 한번도 압축되지 않은 정적 컨텐츠를 요청하면 압축되지 않은 결과가 나오고 두번째 이후의 요청은 압축된 컨텐츠를 내보내므로 '어? 압축 안되네' 라고 생각하지 말기 바란다. 이렇게 함으로써 IIS는 보다 효율적인 압축을 수행할 수 있는 것이다.

정적 컨텐츠가 압축되어 캐시되는 디렉토리는 화면 1에서 보는 바와 같이 설정이 가능하다. 기본 값은 C:\Windows\IIS Temporary Compress Files 라는 폴더이다. 이 폴더를 변경하고자 한다면, NTFS로 포맷된 로컬 디스크(네트워크 드라이브는 사용할 수 없다)의 폴더를 지정해야 하며 이 폴더는 IIS_WPG 그룹이 모든 권한을 가지고 있어야 한다. 또한 이 디렉토리의 크기 역시 화면 1과 같이 제한할 수 있다.

압축 설정이 효과를 내기 위해서는 w3wp.exe 작업 프로세스가 재시작 되어야 한다. 반드시 작업 프로세스가 재시작되어 HTTP  압축에 관련된 설정을 다시 읽도록 해야만 압축이 효과를 나타내므로 IIS를 아예 재시작하던가, 리부팅(컥 !!)을 하던가, 아니면 어플리케이션 풀에서 원하는 w3wp.exe 만 살짝 재시작하던가 방법은 알아서 선택하길...

IIS 관리자를 통한 설정은 간단하지만 다양한 설정을 수행할 수 없다. 예를 들어 정적 컨텐츠는 확장자가 .htm, .html, .txt 로 설정되어 있는데 이 설정에 .css 나 .js 등을 추가할 수 없다. 또, 동적 컨텐츠는 확장자가 .asp, .dll, .exe로 설정되어 있는데 .aspx를 추가하는 UI를 가지고 있지 않다. 결정적으로 IIS 관리자의 HTTP 압축 설정은 모든 사이트, 모든 가상 디렉토리에 적용되어 버린다. IIS 관리자를 통한 설정은 소위 전역 설정(global setting)으로 IIS의 모든 사이트, 디렉토리, 컨텐츠에 적용됨에 유의하도록 하자.

Compression Setting using Metabase

IIS의 모든 설정은 메타베이스에 기록된다. IIS 관리자 역시 이 메타베이스를 수정하는 프론트 엔드 UI 일 뿐이다. IIS 메타 베이스를 수정하는 손쉬운 방법 중 한가지가 c:\inetpub\adminscript\ 폴더에 존재하는 adsutil.vbs 스크립트이다. 이 스크립트를 통해 IIS의 HTTP 압축 설정을 수행하거나 메타베이스를 직접 수정할 수도 있다. (IIS 5.0에서는 IIS 관리자에 설정 UI가 존재하지 않으므로 죽으나 사나 스크립트 써야 한다)

IIS의 HTTP 압축에 관련된 설정은 메타베이스의 /LM/W3SVC/Filters/Compression 노드와 의 자식 노드들에 의해 결정된다. 특히 Parameters 항목에는 전역 HTTP 압축 설정이 포함된다. 즉, IIS 관리자에서 수행했던 설정이 모두 이 Parameters 항목을 수정하는 것이라는 것이다. 말로만 하면 잘 이해가 안되니 캡처 서비스 들어간다... IIS Resoure Kit (공짜다... MS에서 찾아서 다운로드하고 설치해라... 무쟈게 좋은 유틸들 많다...)에 포함된 Metabase Explorer로 화면 2와 같이 HTTP 압축에 관련된 설정을 찾아 볼 수 있다.

화면2. HTTP 압축에 관련된 설정을 보여주는 Metabase Explorer 스냅샷

여기서 HcDoStaticCompression 속성이 정적 컨텐츠에 대한 압축 여부를 결정하는 전역 설정값이며, HcDoDynamicCompression 속성이 동적 컨텐츠에 대한 압축 여부를 결정하는 전역 설정값이다. HcCompressionDirectory 니 HcDoDiskSpaceLimiting 이니 하는 속성은 설명하지 않아도 감이 팍팍 올 것이며, 나머지 속성은 MSDN을 찾아 보기 바란다.

gzip 항목과 deflate 항목도 클릭해서 살펴보면 각 압축 알고리즘 마다 압축 여부를 결정하는 속성이 있다. 이런 속성보다 중요한 것은 압축을 수행할 정적 컨텐츠와 동적 컨텐츠의 확장자를 결정하는 속성이 있다는 점이다. HcFileExtensions 속성이 압축할 정적 컨텐츠의 확장자를 설정하는 속성이며, HcScriptFileExtensions 속성이 압축할 동적 컨텐츠의 확장자를 설정하는 속성이다. 이 속성의 기본 값들에 추가적인 확장자들을 등록함으로써 .css, .js, .aspx 등의 컨텐츠를 압축할 수 있다. .Aspx 와 같은 확장자는 HcScriptFileExtensions에 추가되어야 함은 당연 빤쭈다.

어떤 메타베이스 속성을 수정해야 할지 알았다면 직접 수정해 보자. IIS Metabase Explorer가 설치되어 있다면 이것을 이용하여 직접 수정해도 된다. 만약 그렇지 않다면 C:\inetpub\adminscript 폴더에 존재하는 adsutil.vbs 스크립트를 사용하자. 이 스크립트는 cscript.exe와만 작동하므로 명령창(cmd.exe)을 열고 명령을 입력해야 한다.

정적 컨텐츠 압축을 전역적으로 활성화 시키고자 한다면 다음과 같이 스크립트를 수행한다.

gzip으로 압축할 정적 컨텐츠를 가진 파일 확장자를 .htm, .html, .txt, .doc 으로 등록하고자 한다면 다음과 같이 스트립트를 수행한다.

Metabase Explorer도 아니고 adsutil.vbs 스크립트도 아닌 마지막 방법은 메타베이스 XML 파일을 직접 수정하는 것이다. IIS를 정지시키고 c:\windows\system32\inetsrv\ 폴더의 Metabase.xml 파일을 텍스트 에디터로 연다(먼저 백업을 해두는 것이 정신 건강에 이로울 것이다). 그리고 수정하고자 하는 항목을 찾아 수정한다. 그리고 나서 다시 IIS를 시작하면 된다. 별로 권하고 싶은 방법이 아니다.

Compression Settings by Directory basis

지금까지의 설정은 HTTP 압축에 대한 전역 설정이였다. IIS 6.0은 폴더별로 HTTP 압축 여부를 수행할 수 있다. IIS 6.0에 새로이 추가된 DoStaticCompression 속성과 DoDynamicCompression 속성은 IIS의 각 디렉토리/파일 마다 설정될 수 있는 속성으로서 해당 디렉토리내의 파일의 압축 여부를 결정한다. 그리고 이 속성의 값은 전역 압축 속성 값을 오버라이드 한다. 즉 전역 속성에서 압축이 활성화 되어 있더라도 해당 폴더의 압축 속성이 해제되어 있다면 압축이 수행되지 않는다. 반대로 전역 압축 속성이 해제(디폴트 값)되어 있더라도 해당 폴더의 압축 속성이 활성화 되어 있다면 해당 폴더의 내용은 압축된다.

아쉽게도 이 두 속성 값을 변경하는 관리 화면(UI 화면)은 존재하지 않는다. 이 값을 수정하기 위해서는 adsutil.vbs를 사용하거나 Metabase Explorer를 이용하여 직접 값을 추가/수정해 주어야 한다. Metabase Explorer를 이용하는 방법은 약간 복잡하다. Metabase Explorer는 기존에 생성된 속성 값을 보거나 수정하기에는 좋지만 새로운 속성을 추가하기엔 영 불편한 도구이기 때문이다. 따라서 adsutil.vbs를 사용하는 것이 가장 편리하다. 예를 들어 "디폴트 웹 사이트"의 /test2 디렉토리의 파일들에 대해 정적 컨텐츠 압축을 수행하려면 다음과 같은 스크립트 명령을 쓰면 된다.

위 명령을 수행할 때 w3svc/1/root/test2 를 찾을 수 없다는 오류 메시지가 나올 수도 있는데 이는 test2 디렉토리가 가상 디렉토리가 아닌 실제 파일 시스템의 디렉토리이고 IIS 메타베이스에 어떠한 설정도 없을 때, 메타 베이스 상에 w3svc/1/root/test2 노드가 존재하지 않기 때문에 발생한다. 이 경우 다음 스크립트로 메타베이스 항목을 "생성" 한 후에 압축 설정을 수행하면 된다.

DoStaticCompression과 DoDynamicCompression 속성은 전역 설정이 아니기 때문에 작업 프로세스(w3wp.exe)나 IIS를 재시작할 필요가 없다.

디렉토리별 압축 설정은 대략 귀찮다. 손쉽게 압축 설정을 수행하기 어려운데... 필자 시간나면 요거 관련된 유틸 함 작성해 볼라구 한다. 기대는 하지마라... 필자 워낙 게으르고 귀차니즘에 쩔어 살기 땀시... 지금 이렇게 블로그에 글 쓰는 것도 울 마누라는 무쟈게 신기해 한다는... -_-

Test

IIS의 압축 설정을 하고 나면 실제로 압축이 작동하는가 테스트 해봐야 할 것이다. 먼저 테스트 해봐야 할 항목은 압축 설정 이후 웹 사이트가 제대로 작동하는가 웹 브라우저를 통해 살펴봐야 할 것이다. 웹 사이트에 문제가 없다면 실제로 압축이 수행되는가를 살펴보도록 하자. Fiddler를를 사용하면 이 역시 간단히 알아볼 수 있다. Fiddler를 통해 압축 여부를 판단하는 것은 지난 포스트에서 살펴 보았으므로 스킵~

정적 컨텐츠 압축에 대한 테스트는 주의를 기울여야 한다. 앞서 언급했듯이 최초의 정적 컨텐츠(.htm 같은) 요청은 일반적으로 압축이 되지 않는다. IIS는 압축 큐에 컨텐츠를 집어 넣고 압축 되지 않은 컨텐츠를 반환한다. 압축 큐에 의해 컨텐츠가 압축되면 압축된 결과가 c:\windows\IIS Temporary Compress Files 폴더에 생성되므로 이 폴더에 해당 파일이 있는가 확인하는 것도 압축 수행 여부를 판단하는 좋은 방법 중 하나이다. 일단 이 폴더에 정적 컨텐츠가 존재하면 IIS는 이 폴더의 파일을 반환한다. 이 파일은 이미 압축되어 있으므로 압축이 효과를 나타내는 것이다.

동적 컨텐츠는 매번 클라이언트 요청마다 압축이 수행된다. 따라서 압축이 수행중인가를 손쉽게 판단할 수 있다.

Disadvantage

IIS의 압축 기능은 무료로 사용할 수 있는 훌륭한 기능임에 틀림없다. 하지만 단점이 전혀 없는 것은 아니다. 첫째로 컨텐츠를 압축 할 것인가 말것인가를 파일 확장자(extension)에 의해서 결정하기 때문에 asp 혹은 aspx가 HTML이 아닌 JPEG 등 이미 압축된 컨텐츠를 반환하는 경우 불필요한 압축을 수행할 수도 있다. 또한 asp/aspx 등 스크립트가 PDF를 반환한다면 브라우저는 오류를 일으키며 PDF 를 브라우저에 보여주지 않는다. 그 이유는 IE가 HTML, CSS 등의 웹 컨텐츠나 MS-Word, MS-Powerpoint 등 오피스 문서 등은 압축 해제를 잘 수행한다. 하지만 PDF는 무슨 이유인지 제대로 압축을 해제하지 못한다는 것이다.

이 처럼 IIS가 압축을 파일의 확장자에 의해 수행하므로 하나의 확장자(asp, aspx 등)가 여러 컨텐트 타입을 반환하는 경우 문제의 소지가 있다는 것이다. 앞서 무료/상용 소프트웨어로 언급한 ISAPI 필터들은 모두 파일 확장자에 의해 압축하는 것이 아닌 HTTP 헤더에서 Content-Type에 의해 압축 여부를 결정하기 때문에 이런 문제가 발생하지 않는다고 한다.

IIS 압축의 또 하나의 단점은 디렉토리, 파일별 압축 설정이 너무 귀찮다는 것이다. IIS 관리자가 디렉토리/파일별 압축 설정에 대한 UI를 제공하지 않기 때문에 귀찮은 메타베이스 수정 작업을 동반하며, 설정할 디렉토리가 상당히 많은 경우 대략 즐스러운 사건이 발생한다. 그나마 위안이 되는 것은 상위 디렉토리의 압축 설정이 하위 디렉토리까지 파생된다는 것 정도 일까?

Recommendation

IIS 압축에 대해 필자의 조언은 이렇다(필자의 의견이므로 걍 씹어도 된다. 절대 MS의 권고 사항이 아니당...). 가급적이면 IIS 압축 기능을 최대한 활용한다. 특히 정적 컨텐츠 압축은 매번 압축을 수행하는 것이 아니라 한번 압축된 파일을 만들어 놓고 이것을 재사용하므로 효율이 매우 좋다. 동적 컨텐츠의 경우도 앞서 단점에서 언급한 사항이 아니라면 디렉토리/파일별 압축 설정을 통해 대부분의 문제를 우회할 수 있다.

파일 확장자가 아닌 Content-Type별로 압축 수행 여부를 판단해야 한다면, 상용 압축 소프트웨어를 구입하던가 아니면 압축 모듈을 직접 개발해야 한다. 압축 모듈은 IIS이건 상용 소프트웨어 이건 ISAPI 필터를 통해 수행되므로 압축 모듈을 만든다는 것은 ISAPI 필터를 개발하는 것이다. 그런데... 이 ISAPI 필터의 개발이 쉽지 않다는 것이다(필자도 ISAPI 필터는 한번도 작성해 본적이 없다. ISAPI 확장은 몇번 작성해 보았지만...). 만약 웹 어플리케이션이 닷넷 기반이라면 압축을 수행하는 필터의 개발은 그다지 어렵지 않다. ISAPI 필터에 해당하는 닷넷 HTTP 모듈(HTTP Module)을 작성하면 되기 때문이다.

Epilog

HTTP 압축을 적용할 것인가 말 것인가는 순전히 독자 맘이다. 국내 사이트는 대부분 HTTP 압축을 적용하지 않고 있는데 나름대로의 이유가 있을 것이라 믿는다. HTTP 캐시와 맞물려 압축이 곤란하다든가, 웹 서버의 CPU 점유율이 높은 편이라 압축하기 곤란하다든가... 등등... 하지만 HTTP 압축이 뭔지도 모르거나 알고 있더라도 대략 귀찮기 때문에 HTTP 압축을 고려하지 않는다면 대략... 우워~~~

HTTP 압축을 실제로 구현하는 부분까지 커버하여 글을 작성하려 했건만 여의치 않았다(시간이 된다면 HTTP 압축에 대해 추가적으로 글을 더 작성해 보려고 한다). 미흡한 기획 포스트를 읽어준 독자 여러분... 감사할 따름이다.... 댕~큐~