IIS 7.0
IIS 7.0의 가장 중요한 10가지 성능 향상
Mike Volodarsky
한 눈에 보기:
- 사용자 응용 프로그램의 공간 최소화
- 대역폭 비용 감소
- 향상된 캐싱 기능 사용
목차
간결한 웹 서버
간결한 OS를 기반으로 활용
특화된 응용 프로그램 포톨로지
응용 프로그램 지원 개선
응용 프로그램 밀도 향상
압축을 통한 대역폭 감소
미디어 비트 전송률 제한
출력 캐싱
ISAPI 코드를 IIS 7.0 모듈로 변환
서버 확장성
결론
IIS 7.0을 도입하려는 회사의 관계자와 이야기할 때 빠지지 않는 질문 중 하나는 IIS 7.0을 도입하면 서버나 응용 프로그램의 성능이 개선될 것인지에 대한 것입니다. 보통은 이 질문에
예라고 답하지만 응용 프로그램을 처음 IIS 7.0으로 마이그레이션하고 성능 향상이 보이지 않는다고 해도 놀라지는 마십시오.
이러한 현상을 이해하려면 최신 릴리스의 특성을 이해할 필요가 있습니다. IIS 6.0은 강력한 보안, 높은 안정성 및 성능 향상이라는 세 가지 목표를 위한 엔지니어링 릴리스였습니다. 반면에 IIS 7.0은 플랫폼 릴리스이며 이전 버전의 고품질 기본 웹 서버 코어를 핵심적인 최신 배포 및 관리 시나리오 지원을 갖춘 모듈 방식의 확장성 높은 플랫폼으로 전환하는 목적을 가지고 있습니다.
아키텍처에 대한 여러 가지 변경과 새로운 기능이 실제로는 웹 서버의 성능에 좋지 않은 영향을 줄 수 있습니다. 예를 들어 최적화된 웹 서버 코드 경로가 핵심적인 변경 사항 중 하나에 의해 독립 실행형 모듈로 분리되어 웹 서버에서 특별한 대우를 받지 못하게 될 수 있습니다. 그러나 성능 향상을 위한 IIS 팀의 노고 덕분에 IIS 7.0은 이전 버전과 비교했을 때 여러 부분에서 동등하며 특정 영역에서는 오히려 앞서는 성능을 보여 줍니다. 웹 서버 코어와 통합 파이프라인 개발에 참여했던 필자의 개인적인 관점에서 볼 때 이것이 가능했던 것은 디자인 면에서 많은 독창성과 제품 구현의 노력이 있었기 때문입니다.
IIS 7.0이 이전 IIS 릴리스에 비해 상당한 성능 향상을 제공하고 서버 팜에서 성능 관련 비용을 줄일 수 있는 잠재력이 훨씬 높다는 점은 분명합니다.
단순히 IIS 7.0으로 마이그레이션하여 반드시 이러한 혜택을 볼 수 있는 것은 아니지만 일부 환경에서는 곧바로 혜택을 볼 수 있습니다. Microsoft.com에서는 10%의 CPU 효율 향상을 경험했습니다. 완전한 분석 자료는 Microsoft.com 팀 블로그(go.microsoft.com/fwlink/?LinkId=122497)에서 볼 수 있습니다. 이 밖에도 SSL(Secure Sockets Layer), Windows® 인증(이 둘은 이제 커널에서 수행됨), 그리고 다중 코어 및 다중 프로세서 시스템에서 개선된 수직 확장성을 포함하여 특정 영역에서 분명한 개선이 있습니다.
그러나 IIS 7.0의 진가는 기존 기능에 대한 성능 향상보다는 적극적인 활용이 필요한 새로운 기능을 통해서 확인할 수 있습니다. 이러한 기능은 플랫폼의 유연성과 확장성 특성과 새로운 성능 기능에 기반을 두는 경우가 많습니다. 이 기사에서는 IIS 7.0으로 전환하여 성능 향상을 거둘 수 있는 가장 중요한 10가지 부분을 살펴보겠습니다.
간결한 웹 서버
간결한 IIS 7.0 서버를 배포하는 능력은 서버의 모듈식 아키텍처 덕분에 가능해졌습니다. 실질적으로 모든 웹 서버 기능은 모듈식 구성 요소로 구현되었으므로 별도로 추가하거나 제거할 수 있습니다. 따라서 응용 프로그램의 작업에 필요하지 않은 모든 서버 기능을 제거하여 공격 가능 영역과 작업 공간을 크게 줄이고 성능을 향상시키는 것과 같은 많은 혜택을 얻을 수 있습니다.
전체 IIS 7.0 웹 서버 기능에는 통합 파이프라인에 서비스를 제공하는 네이티브 IIS 모듈과 ASP.NET 모듈을 포함하여 44개의 모듈이 포함되어 있습니다. 이러한 모듈은 인증(Windows 인증 및 다이제스트 인증 모듈), 응용 프로그램 프레임워크 지원(FastCGI 모듈), 응용 프로그램 서비스(세션 상태 모듈), 보안(요청 필터링 모듈) 및 성능(출력 캐시 모듈)과 같은 서비스를 제공합니다. 놀랍게도 정적 콘텐츠만 제공하면 되는 최소한의 웹 서버는 단 두 개의 모듈로도 작동이 가능합니다!
불필요한 모듈로 인한 오버헤드는 가령 요청 로깅이나 실패한 요청 추적 모듈의 경우에는 상당히 높은 수준까지 발생할 수 있습니다. 환경에서 필요 없는 이러한 모듈을 제거하면 전체 처리량을 높이고 서버 워크로드에 대한 TTFB(첫 번째 바이트까지의 시간) 및 TTLB(마지막 바이트까지의 시간)를 낮추어 응답 성능을 개선할 수 있습니다.
그림 1에는 HTML 파일(정적 워크로드) 및 hello world ASP.NET 페이지(ASP.NET 워크로드)를 전체 기능 집합, 해당 워크로드를 위한 기본 기능 집합 및 워크로드에 필요한 최소 기능 집합 구성에서 제공하는 간단한 처리량 테스트의 결과가 나와 있습니다. 전체 구성에서도 대부분의 불필요한 기능은 이미 해제되어 있지만 최소 구성에서 이를 완전하게 제거하면 정적 워크로드와 ASP.NET 워크로드 모두에서 상당한 처리량 상승을 경험할 수 있습니다.
그림 1 동시 클라이언트가 100개일 때 세 가지 다른 구성에서 정적 워크로드와 ASP.NET 워크로드의 처리량 비교 (더 크게 보려면 이미지를 클릭하십시오.)
또한 메모리 용량과 사이트 밀도가 향상된 것을 볼 수 있으며 이러한 효과는 공유 호스팅 환경이나 많은 수의 작업자 프로세스가 사용 중인 경우에 더욱 높아집니다. 일반적으로 성능 개선은 각 프로세스에 적은 수의 DLL을 로드하고 모듈 초기화와 요청 처리 중에 발생하는 메모리 할당을 취소화함으로써 얻어집니다. 그림 2에는 동일한 처리량 테스트에서의 메모리 사용량(IIS 작업자 프로세스의 개인 바이트)이 나와 있습니다. 이 예에서는 ASP.NET appdomain 오버헤드가 모듈을 제거하여 얻는 기본 향상보다 비교적 높기 때문에 성능 향상이 두드러지게 나타나지 않고 있지만 향상되는 양상은 예상대로입니다.
그림 2 동시 클라이언트가 100개일 때 세 가지 다른 구성에서 정적 워크로드와 ASP.NET 워크로드의 메모리 사용량(개인 바이트) (더 크게 보려면 이미지를 클릭하십시오.)
IIS 7.0은 응용 프로그램 수준에서 사용할 모듈에 대한 추가 제어를 제공하며 모듈 전제 조건을 통해 워크로드를 바탕으로 모듈 사용량에 대한 제어도 제공합니다. 이렇게 하려면 추가적인 고급 구성을 수행해야 하지만 다중 사이트 환경이나 여러 고유 워크로드를 지원하는 응용 프로그램에 추가적인 장점을 제공할 수 있습니다.
한 가지 주의할 것은 필요한 기능을 결정하기가 까다로울 수 있다는 것입니다. 응용 프로그램 프레임워크를 지원하기 위한 최소한의 기능뿐 아니라 응용 프로그램이 간접적으로 사용하는 추가 기능도 고려해야 합니다. 예를 들어 여러분의 응용 프로그램이 특정한 인증 방법을 사용하거나 다양한 IIS 기능에서 제공되는 권한 부여 체계에 의존하는 경우가 있을 수 있습니다. 이러한 경우 해당 모듈을 제거하면 응용 프로그램의 보안에 나쁜 영향을 줄 수 있습니다. 비슷하게 여러분의 응용 프로그램이 기능이나 성능 효과를 위해 다른 모듈을 사용하는 경우가 있으며 이때 이러한 모듈을 제거하면 작동에 문제가 생기거나 성능 저하가 발생합니다.
간결한 OS를 기반으로 활용
Windows Server® 2008에서는 웹 서버의 노출 영역을 더욱 줄일 수 있는 OS 수준 구성 요소화를 제공합니다. Server Core는 최소한의 핵심 OS 하위 시스템 집합이 포함되어 있는 Windows Server 2008 운영 체제의 최소 설치 옵션입니다. Server Core는 간결한 IIS 7.0 웹 서버를 위한 이상적인 환경입니다.
그러나 Server Core를 평가할 때는 응용 프로그램에 영향을 줄 수 있는 몇 가지 제약 사항에 주의해야 합니다. Server Core는 Microsoft® .NET Framework를 지원하지 않으므로 ASP.NET, IIS용 .NET 확장성 및 IIS 관리자를 사용할 수 없습니다. 또한 MMC(Microsoft Management Console)가 없기 때문에 명령줄 도구를 사용하여 로컬 관리 작업을 수행해야 합니다. IIS 구성 요소화를 이미 올바르게 활용하고 있다면 성능의 관점에서는 Server Core 또는 전체 Windows Server 구현 중 어디에서 여러분의 응용 프로그램 워크로드를 실행하더라도 메모리 공간이나 처리량 면에서는 차이가 없을 것입니다. 이것은 작업이 IIS에서 실행되며 응용 프로그램 자체는 두 플랫폼에서 동일하기 때문입니다. 그러나 서버의 전체 공간에 있어서는 디스크 공간이나 메모리 사용량에 있어 차이가 있습니다.
그림 3에는 정적 워크로드 테스트를 전체 Windows Server 2008 구성과 Server Core에서 수행한 경우 공간의 차이가 나와 있습니다. IIS 공간은 두 경우에 거의 동일하지만 Server Core의 전반적인 OS 공간 사용이 적기 때문에 훨씬 적은 양의 메모리로 워크로드를 지원할 수 있습니다. 사용 공간이 적다는 것은 응용 프로그램 워크로드를 덜 강력한 하드웨어에 배포하고 운영 체제 환경이 아니라 응용 프로그램의 요구를 처리하는 데 집중할 수 있다는 것을 의미합니다. 물론 같은 이유로 가상화된 환경에서도 Server Core는 훌륭한 옵션입니다.
그림 3 정적 워크로드 테스트를 수행한 후의 전체 Windows Server 2008과 Server Core 메모리 공간 비교 (더 크게 보려면 이미지를 클릭하십시오.)
특화된 응용 프로그램 포톨로지
응용 프로그램 워크로드를 최적화할 때는 워크로드를 고유한 부분으로 분리할 수 있습니다. 예를 들어 동일한 웹 서버 30대로 구성된 팜에서 실행하던 응용 프로그램을 웹 서버 10대, 응용 프로그램 서버 5대, 그리고 캐싱 및 압축을 수행하는 프록시 서버 3대로 구성된 팜에서 실행할 수 있습니다.
이러한 특화가 효과를 발휘하는 몇 가지 이유가 있습니다. 첫째, 응용 프로그램 워크로드의 성능은 메모리와 같이 응용 프로그램의 여러 부분에서 경합을 벌이는 다양한 공유 리소스의 영향을 받는 경우가 많습니다. 리소스에 대한 이러한 경쟁은 각 서버가 다른 리소스를 완벽하게 사용하는 데 방해가 되는 병목 현상의 원인입니다. 응용 프로그램의 부분을 분리하면 기존에 경합을 벌여야 했던 리소스에 쉽게 액세스할 수 있게 되어 동일한 하드웨어 리소스에서도 높은 효율을 거둘 수 있습니다.
둘째, 특화를 통해서 응용 프로그램의 캐시 효율이 향상되어 성능도 개선될 수 있습니다. 이러한 캐시에는 가상 메모리 TLB(Translation Lookaside Buffer), 파일 시스템 캐시, 다른 운영 체제 및 응용 프로그램 캐시가 있습니다. CPU에서도 효율 향상 효과를 얻을 수 있습니다. 응용 프로그램의 특정 부분에 집중함으로써 병렬 작업의 수를 줄이고 CPU가 수행해야 하는 컨텍스트 전환 횟수를 줄임으로써 작업 성능을 극대화할 수 있습니다.
셋째, 특화를 통해 워크로드별 최적화를 수행하여 응용 프로그램의 각 부분이 더 효율적으로 작동하도록 만들 수 있습니다. 전체 응용 프로그램이 같은 서버에서 지원되는 경우에는 응용 프로그램의 다른 부분에 대한 요구가 충돌하여 이러한 최적화 중 많은 항목이 불가능합니다.
이 현상이 발생하는 일반적인 장소 중 하나로 동시성에 상당히 큰 영향을 주며 여러 응용 프로그램에서 메모리 사용, 대기 시간 및 처리량에 간접적인 영향을 주는 IIS와 ASP.NET 스레딩 구성이 있습니다. IIS 정적 파일 워크로드는 상당히 비동기적이며 높은 동시 요청 한계가 필요하지만 사용 가능한 스레드 수가 상당히 적어도 작동합니다. 반면에 ASP.NET 기능 중에는 동기적이고 오랫동안 차단하며 스레드가 많이 필요한 기능이 많으며 일부는 메모리에 대한 영향을 줄이기 위해 낮은 동시성 제한을 필요로 합니다. 정적 워크로드를 분리하고 요청 처리 파이프라인 부분을 별도의 프로세스나 서버로 분리하면 각 개별 워크로드의 동시성을 최적화할 수 있습니다.
마지막으로 특화를 통해 응용 프로그램이 서로 연관이 없는 별도의 워크로드나 응용 프로그램 부분을 수직적으로 확장할 수 있게 되어 전반적인 확장성이 향상됩니다. 이를 통해 전체 응용 프로그램에 동일한 템플릿을 적용할 필요 없이 응용 프로그램 토폴로지에서 가장 필요한 곳에 증가한 용량과 중복성을 제공할 수 있게 됩니다. 이 모델에서 특화된 리소스는 실제 서버이거나 가상 서버 또는 심지어 같은 시스템의 응용 프로그램 풀이 될 수 있습니다.
여러분의 응용 프로그램 토폴로지에 특화를 적용함으로써 얻을 수 있는 잠재적인 혜택을 평가할 때는 먼저 응용 프로그램에서 프로세싱 또는 리소스를 많이 사용하는 병목 현상을 찾는 것으로 시작하십시오. 이러한 영역을 격리하면 상당한 최적화 잠재성이 제공되고 가장 높은 수준의 수평 확장성을 요구하므로 가장 먼저 특화 후보로 고려해야 합니다. 그런 다음 이러한 영역을 격리하면 응용 프로그램의 나머지 부분이 리소스를 더 효과적으로 활용할 수 있는지 평가합니다. 마지막으로 격리된 응용 프로그램 구성 요소를 연결하는 데 필요한 연결 메커니즘의 오버헤드를 평가해야 합니다.
응용 프로그램 지원 개선
IIS 7.0에는 여러 공개 소스 응용 프로그램 프레임워크에서 지원되는 공개 프로토콜인 FastCGI를 통해 확장된 응용 프로그램 프레임워크 지원이 제공됩니다. 이러한 지원이 없었다면 IIS와의 안정적이고 성능이 뛰어난 네이티브 통합이 불가능했을 것입니다. 오랫동안 IIS에서 지원된 CGI(Common Gateway Interface) 프로토콜과는 달리 FastCGI는 Windows 플랫폼에서 훨씬 개선된 성능을 제공합니다. 이것은 주로 심한 요청별 프로세스 생성 오버헤드를 없애서 클라이언트가 지속적으로 유지되는 연결을 활용할 수 있도록 하는 FastCGI 재사용 가능 프로세스 아키텍처 덕분입니다.
IIS에서 CGI나 다른 메커니즘을 사용하여 응용 프로그램 프레임워크를 지원하는 경우에는 이를 FastCGI 프로토콜로 변환하여 성능(경우에 따라서는 안정성까지)을 개선할 수 있습니다.
이 지원을 활용하는 첫 번째 응용 프로그램 프레임워크는 PHP입니다. 실제로 IIS 팀에서는 IIS FastCGI에서 PHP가 잘 작동하고 Windows에서 PHP 프레임워크의 성능을 개선할 수 있도록 Zend Technologies와 직접 협력하여 작업을 진행했습니다. 프로젝트에 대한 자세한 내용은 필자의 블로그(go.microsoft.com/fwlink/?LinkId=122509)를 참조하십시오. IIS에서 실행되는 ASP 또는 ASP.NET 응용 프로그램, PHP 또는 다른 기술을 사용하는 FastCGI 호환 응용 프로그램 프레임워크를 포함하여 웹 서버 기술을 혼합해서 사용하고 있다면 이러한 응용 프로그램을 IIS 7.0 플랫폼에서 통합할 수 있습니다.
PHP 및 다른 응용 프로그램 프레임워크를 IIS 7.0 및 FastCGI로 전환하면 ASP.NET 통합 파이프라인을 포함하는 다양한 IIS 7.0 기능을 활용할 수 있습니다. 이렇게 하면 응용 프로그램 프레임워크를 ASP.NET으로 변환하지 않고도 ASP.NET 서비스를 활용하여 향상시킬 수 있는 매우 편리한 옵션이 제공됩니다. 또한 다른 프레임워크를 사용하는 응용 프로그램이 공동 작업하는 기반이 마련됩니다. 이 방법을 사용하여 코드를 전혀 변경하지 않고도 기존 응용 프로그램의 기능과 성능을 향상시키는 방법에 대한 예는 msdn.microsoft.com/magazine/cc135973.aspx에서 필자의 MSDN 기사 "통합된 ASP.NET 파이프라인을 활용한 응용 프로그램 향상"을 참조하십시오.
응용 프로그램 밀도 향상
IIS 7.0에는 단일 서버에서 호스트되는 응용 프로그램의 밀도를 높이기 위한 향상된 기능이 많이 포함되어 있습니다. 이러한 향상된 기능은 공유 호스팅의 품질을 개선하기 위해 IIS 7.0에서 제공하는 개선된 사이트 프로비전 및 응용 프로그램 격리를 포함하는 다양한 기능의 일부입니다.
성능 측면에서 이러한 향상은 IIS 7.0 서버에서 프로비전할 수 있는 응용 프로그램의 수를 늘리는 것과 동시에 활성화할 수 있는 응용 프로그램의 수를 늘리는 두 가지 측면에서 집중적으로 이루어졌습니다.
IIS 7.0은 이전 버전에 비해 각 서버에서 더 많은 수의 응용 프로그램을 프로비전할 수 있습니다. 내부 테스트에 의하면 단일 서버에서 최대 100,000개의 사이트를 프로비전할 수 있었습니다. 이러한 결과는 더 많은 수의 사이트와 응용 프로그램을 만들고 구성하는 능력을 통해 가능해졌습니다.
한 가지 주의할 것은 고속 프로비전을 수행하려면 새로운 구성 API로 전환해야 한다는 것입니다. 기존 구성 API로는 이를 달성할 수 없습니다. 또한 모든 IIS 구성 API가 동일한 성능 특성을 제공하는 것은 아니므로 높은 성능을 보장하기 위해서는 신중하게 선택해야 합니다. 확신이 없는 경우에는 Microsoft.Web.Administration 네임스페이스, AppCmd.exe 명령줄 도구, 그리고 스크립트, .NET 또는 C++ 코드에서 액세스하는 IIS COM 구성 개체를 포함하여 새로운 IIS 구성 개체를 직접 활용하는 구성 옵션을 선택하십시오.
요청을 처리하기 위해 영구적 응용 프로그램 및 작업자 프로세스를 사용하는 IIS 아키텍처에서 프로비전할 수 있는 사이트의 수와 활성화할 수 있는 사이트의 수 사이에는 매우 중요한 차이가 있습니다. 이 모델에서 활성 응용 프로그램은 서버에서 더 많은 리소스를 소비하지만 캐싱을 사용하고 초기화 비용이 제거되어 더 나은 지속 성능을 제공합니다.
권장되는 응용 프로그램 격리 모델을 사용하는 경우 각 활성 응용 프로그램에 특정한 양의 메모리와 별도의 작업자 프로세스가 필요하므로 활성 응용 프로그램의 수는 응용 프로그램 메모리 공간에 크게 좌우됩니다. 따라서 정적 콘텐츠만 제공하는 단일 응용 프로그램은 작업자 프로세스에 3MB만 필요할 수 있으며 심지어 다른 정적 콘텐츠 응용 프로그램과 같은 작업자 프로세스를 공유하는 것도 가능하지만 일부 동적 응용 프로그램에서는 사용량이 낮은 경우에도 100MB 이상의 RAM이 필요할 수 있습니다. 따라서 최대 가능 밀도를 정의할 때 IIS 작업자 프로세스 자체의 메모리 오버헤드는 응용 프로그램의 공간과 비교하면 중요성이 떨어집니다.
일반적인 공유 호스팅 시나리오에는 요청의 80%가 사이트 중 20%에 집중되는 80/20 분포라는 현상이 자주 나타납니다. 이에 따라 동시에 활성화할 수 있는 사이트의 비율이 낮아집니다. IIS 7.0에서는 활성 사이트의 수를 늘리기 위해 비활성 응용 프로그램에서 메모리를 회수하여 더 많은 활성 응용 프로그램을 호스트할 수 있도록 하는 활성 수명 관리라는 기능을 제공합니다.
IIS 7.0에는 서버에서 사용 가능한 메모리를 바탕으로 작업자 프로세스의 유휴 시간 제한을 사전에 조정하는 동적 유휴라는 새로운 알고리즘이 도입되었습니다. 사용 가능한 메모리가 줄어들면 유휴 응용 프로그램을 더 빠르게 제거하여 더 많은 활성 응용 프로그램을 호스트할 수 있습니다. 그리고 메모리가 충분한 경우에는 시간 제한을 길게 유지하여 더 나은 성능을 제공하고 응용 프로그램 상태를 유지할 수 있습니다. 동적 유휴를 사용하면 더 많은 응용 프로그램을 활성 상태로 유지할 수 있는 것은 물론 스래싱(Thrashing)으로 인한 심각한 성능 저하의 원인인 메모리 부족 현상을 방지하는 데 도움이 됩니다.
활성 응용 프로그램을 더 많이 호스팅하려면 OS에서 4GB보다 많은 메모리를 주소 지정할 수 있는 64비트 운영 체제를 활용해야 합니다. 64비트 운영 체제에서도 IIS 작업자 프로세스를 32비트 모드(SysWoW64)로 실행하여 메모리를 더 적게 소비하면서도 OS는 32비트 환경보다 더 많은 메모리 공간을 주소 지정할 수 있습니다.
압축을 통한 대역폭 감소
인터넷 연결 데이터 센터를 운영하는 데 필요한 비용 중 대역폭 비용이 가장 높다는 사실은 놀라운 일이 아닙니다. 또한 요청된 콘텐츠를 제공하는 데 필요한 대역폭은 응용 프로그램의 응답성에 중요한 핵심 요소입니다.
응용 프로그램 응답을 제공하는 데 필요한 대역폭을 줄이는 가장 효과적인 방법 중 하나는 HTTP 압축을 사용하는 것입니다. 이렇게 하면 응답의 크기를 상당히 줄일 수 있으며 HTML과 같이 압축이 용이한 텍스트 콘텐츠에 적용하는 경우에는 1/10 수준까지 압축할 수 있습니다. 게다가 거의 모든 브라우저에서 압축을 지원하며 데스크톱 하드웨어에서 압축 해제를 수행하기 위한 비용은 데이터를 적게 전송하여 얻는 대기 시간 감소와 비교하면 사소한 수준입니다. 또한 압축은 HTTP 1.1 프로토콜에 정의된 콘텐츠-인코딩 협상에 기반을 두므로 압축을 지원하지 않는 클라이언트에서도 안전하게 이 기능을 사용할 수 있습니다. 이러한 클라이언트는 단순히 콘텐츠의 압축되지 않은 버전을 수신합니다.
IIS 7.0은 이전 버전에 도입된 정적 압축과 동적 압축의 두 가지 압축 기능을 제공합니다. 정적 압축은 정적 콘텐츠를 미리 압축하여 디스크에 저장하므로 향후 요청에 압축 오버헤드 없이 압축된 콘텐츠를 제공할 수 있습니다. 동적 압축은 실시간으로 응답을 압축하므로 응용 프로그램에서 생성된 응답을 압축할 수 있습니다. ASP, ASP.NET 또는 PHP를 포함하여 IIS 7.0의 모든 응용 프로그램 프레임워크는 동적 압축을 활용할 수 있습니다.
일반적인 통념과는 달리 동적 압축이 CPU 오버헤드를 심각하게 유발하지는 않습니다. 실제로 사용량이 많은 서버에서 동적 압축에 사용되는 전체 CPU 사용률은 5% 미만입니다. 동적 압축은 모든 응용 프로그램 워크로드에서 최대한의 대역폭을 저장할 수 있도록 비교적 자유롭게 배포할 수 있습니다.
압축 강도를 구성하면 원하는 압축 수준과 CPU 오버헤드 비율을 조정하여 압축 오버헤드를 최적화할 수 있습니다. 여기에서 그치지 않고 응용 프로그램이 압축된 콘텐츠를 캐싱할 수 있도록 구성하면 이미 압축된 콘텐츠에 대해서는 다시 압축하는 오버헤드를 방지할 수 있습니다. ASP.NET과 IIS 출력 캐시는 기능을 지원하는 클라이언트를 위해 압축된 콘텐츠를 캐시하는 것은 물론 압축되지 않은 콘텐츠가 필요한 클라이언트의 요청을 처리할 수 있는 선택적인 기능을 포함하도록 업그레이드되었습니다.
미디어 비트 전송률 제한
미디어 콘텐츠를 제공하는 사이트의 수가 증가함에 따라 많은 기업의 대역폭 비용 또한 빠른 속도로 증가하고 있습니다. 문제는 클라이언트로 전송된 미디어 콘텐츠의 많은 부분이 아예 사용되지 않기 때문에 대역폭 낭비가 심각하다는 사실입니다. 왜 이러한 문제가 발생할까요?
브라우징하면서 최근에 온라인 비디오를 보았던 기억을 떠올려 보십시오. 이러한 비디오를 끝까지 보셨습니까? 비디오 사이트를 브라우징하는 동안 비디오의 특정 부분만 감상하고 다른 비디오를 보거나 페이지를 떠나는 경우가 일반적입니다. 그러나 비디오를 제공하는 데 점진적 다운로드를 사용하는 웹 서버는 이러한 몇 초간의 재생 시간에 필요한 것보다 훨씬 많은 양의 데이터를 전송합니다. 이러한 데이터 대부분은 아예 사용되지 않습니다.
비디오를 5초 동안 감상하기 위해 이 5초 동안 30초 분량의 비디오 데이터를 전송(버퍼링)한다면 대역폭의 80% 이상을 낭비하는 것입니다.
필자는 1년 전에 IIS 7.0 베타 릴리스를 도입하는 고객의 환경에서 이 문제가 발생하지 않도록 비디오 비트 전송률을 자동으로 감지하여 이와 거의 비슷한 속도로 클라이언트에 비디오를 전송하는 대역폭 제한 모듈을 개발했습니다. IIS 미디어 팀에서는 비트 전송률 제한 모듈(그림 4 참조)이라고 하는 이 모듈을 선택하고 iis.net 다운로드 센터에서 제공하고 있습니다(iis.net/downloads/?tabid=34&g=6&i=1640). 자세한 내용은 Scott Guthrie의 블로그(go.microsoft.com/fwlink/?LinkId=122514)를 참조하십시오.
그림 4 비트 전송률 제한을 통해 대역폭 사용 최소화 (더 크게 보려면 이미지를 클릭하십시오.)
비트 전송률 제한 모듈은 가장 많이 사용되는 비디오 유형의 인코딩 속도를 자동으로 감지합니다. 빠른 시작을 위해 초기 버퍼링 대기 시간을 없애도록 클라이언트에 미리 전송할 데이터의 양과 인코딩 속도에 대한 콘텐츠 전송 비율도 제어할 수 있습니다. 최대 대역폭 및 동시 연결과 같은 다른 여러 옵션을 구성할 수 있으며 모듈을 프로그래밍 방식으로 제어할 수도 있습니다.
출력 캐싱
일반적으로 캐싱은 반복적인 작업을 수행하는 응용 프로그램의 성능을 개선하는 최선의 방법입니다. 응용 프로그램별 성능 개선에는 상당히 많은 노력과 응용 프로그램의 프로세싱 오버헤드에 대한 세밀한 조사가 필요하지만 캐싱은 동일한 콘텐츠에 대한 반복된 요청에 따르는 오버헤드를 제거하는 방법입니다.
IIS 7.0 이전에는 IIS 커널 캐시와 ASP.NET 캐시 형식으로 IIS와 ASP.NET이 각각 캐시 기능을 제공했습니다. IIS 커널 캐시는 최고의 성능을 제공했지만 주로 정적 콘텐츠로 사용이 제한되었습니다. ASP.NET 출력 캐시는 동적 콘텐츠를 캐싱하기 위한 훨씬 완전한 솔루션이었지만 성능과 메모리 관리 효율이 떨어졌습니다. IIS 7.0의 새로운 출력 캐시는 IIS 커널 캐시와 ASP.NET 출력 캐시의 부족한 점을 보완했습니다.
IIS 7.0 출력 캐시는 ASP, ASP.NET, PHP 및 다른 IIS 7.0 호환 응용 프로그램 프레임워크를 포함하여 모든 응용 프로그램에서 동적 콘텐츠를 캐싱할 수 있습니다. 이 새로운 기능은 콘텐츠 가변성과 만료를 지원할 수 있으므로 IIS 커널 캐시에서는 캐시할 수 없었던 콘텐츠까지 캐싱을 구현합니다. 또한 제한을 충족하지 않는 콘텐츠에도 커널 캐시를 사용할 수 있습니다.
또한 IIS 7.0 출력 캐시는 ASP.NET 출력 캐시에서만 제공되는 고급 캐싱 기능(예: 캐시 종속성 또는 무효화)이 요구되지 않은 ASP.NET 콘텐츠를 위해 보다 높은 성능을 제공하는 ASP.NET 출력 캐시의 대안으로도 사용할 수 있습니다.
출력 캐시에 있어 과제는 일반적으로 효과적인 응답 캐싱을 가능하게 하면서도 요구되는 캐시 정확성 및 유효성을 유지하도록 올바른 콘텐츠 만료, 무효화 및 가변성 정책을 정의하는 것입니다. 대부분의 경우에는 간단히 올바른 캐싱 규칙을 구성하는 것으로 충분하지만 일부 경우에는 런타임 정보를 바탕으로 복잡한 정책이 필요합니다. 이를 처리하기 위해 IIS 7.0 출력 캐시는 필요한 캐싱 동작을 보장하기 위한 프로그래밍 API를 제공합니다. 이를 통해 이전에는 캐싱의 혜택을 볼 수 없었던 콘텐츠에 대해서도 캐싱 성능 향상을 경험할 수 있습니다. 또한 ASP.NET 통합 파이프라인을 통해 비 ASP.NET 콘텐츠에서도 ASP.NET 출력 캐시를 사용할 수 있습니다.
동적 콘텐츠를 위한 출력 캐시를 배포하기는 까다로우며 IIS 7.0 플랫폼의 다양한 캐싱 기능의 효율성과 유연성을 활용하는 다중 계층 전략이 필요합니다. 이를 위한 단계에는 응답에 영향을 주는 여러 매개 변수를 기술하고, 캐시의 유효성을 유지하기 위한 만료와 무효화 전략을 정의하며, 어떤 캐시가 필요한 의미 체계를 지원하는지 확인하는 등이 포함됩니다.
그러나 이러한 복잡성에 대한 대가는 충분합니다. IIS 7.0 출력 캐시를 구현하면 응용 프로그램의 전체 처리량을 최대 몇 배까지 향상시킬 수 있으며 데이터베이스와 비즈니스 계층 구성 요소에서의 부하도 이에 상응하는 수준으로 줄일 수 있습니다.
ISAPI 코드를 IIS 7.0 모듈로 변환
IIS 7.0에는 모든 IIS 7.0 모듈이 기반을 두는 새로운 서버 API가 도입되었습니다. 이 API는 IIS 이전 버전에 사용되던 기존 ISAPI 필터와 ISAPI 확장 API를 대체합니다. 이전 버전을 지원할 필요가 없는 새로운 모듈의 경우 새로운 API가 사용하기 쉽고 더 안정적인 서버 쪽 코드를 작성할 수 있도록 지원하는 것은 물론 더 강력합니다.
그러나 기존 ISAPI 필터와 확장에 대한 지원이 필요한 경우 IIS 7.0은 선택적인 IIS 7.0 모듈을 통해 구현되는 호환성 계층을 사용할 수 있는 옵션을 제공합니다. 이 옵션을 사용하면 기존 ISAPI 구성 요소를 다시 작성하지 않고도 IIS 7.0에서 사용할 수 있습니다.
기존 ISAPI 기반을 활용하면 IIS 7.0 마이그레이션에 대한 장벽을 낮출 수 있지만 레거시 ISAPI 코드를 새로운 IIS 7.0 API로 이식하는 것을 신중하게 고려해야 합니다. 코드를 이식하면 ISAPI 호환성 계층에 의한 오버헤드가 제거되고 ISAPI 구성 요소에서는 제공되지 않는 성능상의 장점을 활용할 수 있습니다. ISAPI 구성 요소에서 수행되는 작업에 따라서는 상당히 높은 수준까지 성능상의 장점을 누릴 수 있습니다. 예를 들어 IIS 7.0 모듈 API는 구성 요소 내부 작업의 속도를 크게 높일 수 있는 사이트, 응용 프로그램 및 URL과 연관된 임의의 데이터와 구성 메타데이터 캐싱을 위한 기본 제공 지원을 제공합니다.
또한 IIS 모듈 API는 모듈이 요청 엔터티 데이터 수신이나 응답 전송과 같이 오랫동안 실행되는 작업을 비동기적으로 수행할 수 있도록 허용합니다. 이러한 작업을 비동기적으로 수행할 수 있도록 허용하면 기존에는 요청 스레드의 수에 대한 제한 때문에 수십 개나 수백 개로 제한되었던 동시 클라이언트의 수를 수만 개까지 크게 확장할 수 있습니다. 비동기 프로세싱은 또한 메모리 사용량을 줄이고 CPU 사용률을 크게 개선하여 응용 프로그램에서 다른 요청과 작업을 처리하는 데 따르는 영향을 없애 줍니다.
성능에 영향을 주는 특정한 패턴을 기반으로 네이티브 API는 개발자에게 요청 처리 작업에 대한 높은 수준의 유연성을 제공합니다. 이를 통해 서버 구성 요소의 디자인을 개선하고 결과적으로 효율성을 크게 높일 수 있습니다. 예를 들어 이전에는 와일드카드 ISAPI 확장과 자식 요청 실행이 필요했던 특정 필터링 작업을 이제는 원래 요청 중에 한 모듈에서 실행하고 응답을 위해 IIS 커널 캐싱을 설정할 수도 있습니다.
이를 위해서는 마이그레이션의 장점을 극대화할 수 있는 최적의 디자인을 결정하기 위한 약간의 프로토타입 작성과 실험이 필요합니다. ISAPI와 IIS 7.0 모듈 API 간의 근본적인 아키텍처 차이 때문에 직접적인 이식 경로가 항상 올바른 방법은 아닙니다. 다행스러운 것은 IIS 7.0 모듈 API는 ISAPI보다 사용하기 쉽게 때문에 마이그레이션이 다소 수월하다는 것입니다.
서버 확장성
IIS 7.0은 완벽한 확장성을 제공합니다. 확장을 위해서는 서버 작업에 대한 상당한 수준의 사전 지식이 필요하지만 응용 프로그램별 성능 향상에 대한 막대한 가능성을 열어 줍니다. 서버 아키텍처와 요청 처리에 대한 어느 정도 지식을 갖추면 이 확장성을 활용하여 여러분의 응용 프로그램, 워크로드 및 하드웨어 요구 사항에 맞춘 사용자 지정 성능 솔루션을 설계할 수 있습니다.
이러한 솔루션을 기본 제공 IIS 7.0 기능을 사용자 지정 구현으로 대체함으로써 사용할 수 있습니다. IIS 7.0 기능은 많은 최적화와 성능 테스트를 거쳤지만 모든 사용 예에 맞게 최적화된 것은 아닙니다. 따라서 여러분의 특정 워크로드에 맞는 최적화를 작성하여 특정 모듈의 성능을 개선할 수 있습니다. 예를 들어 파일 시스템 API를 사용하여 파일을 열거하지 않고 디렉터리 목록을 메모리에 캐시하도록 디렉터리 목록 모듈을 다시 구현할 수 있습니다.
또한 확장성을 활용하여 성능 관련 기능을 새로 작성할 수 있습니다. 이러한 기능의 기본 제공 예로는 출력 캐시, 압축 모듈 및 기타 다른 내부 캐시가 포함됩니다.
사용자 지정 성능 관련 기능이 필요한지 확인하려면 사용자 응용 프로그램과 해당 워크로드의 성능 특성을 이해해야 하며 해결해야 하는 병목 현상에 대해서도 알아야 합니다. IIS 7.0에서는 필요한 기능의 요구 사항과 가능한 디자인을 명확하게 확인하기 위한 성능 분석을 수행하는 진단 지원을 풍부하게 제공합니다.
결론
IIS 7.0 릴리스는 기능 릴리스에 가깝지만 모듈식 아키텍처, 구성 기능 및 새로운 성능 기능 덕분에 높은 수준의 성능 향상을 제공합니다. 기업에서는 서버 통합, 대역폭 비용 절감은 물론 향상된 사용자 환경 제공이라는 이러한 향상된 기능을 통해 상당한 절감 효과를 거둘 수 있습니다.
이러한 많은 향상된 기능을 올바르게 활용하려면 현재 응용 프로그램 플랫폼에 대한 철저한 분석과 IIS 7.0 아키텍처에 대한 충분한 이해가 필요한 경우가 많습니다. IIS 7.0 아키텍처에 대한 자세한 내용과 이 기사에서 언급한 기능에 대해 알아보려면 iis.net을 방문해 보십시오. 필자는 블로그(mvolo.com)에서 IIS 7.0을 적극적으로 활용하여 응용 프로그램 성능을 개선하고 운영 비용을 절감하는 기술을 다루고 있습니다.
Mike Volodarsky는 이전에 Microsoft IIS 팀에서 프로그램 관리자로 일했으며 지난 5년 동안 ASP.NET 2.0과 IIS 7.0 핵심 기능의 설계와 개발을 주도했습니다. 현재 그는 IIS 7.0과 Windows Server 2008을 사용하는 고성능 웹 팜을 위한 고급 웹 서버 기술을 개발하고 있습니다. Mike는 IIS 7.0 Resource Kit의 저자로서 집필을 이끌고 있으며 MSDN Magazine과 그의 IIS 7.0 블로그(mvolo.com)에서 활발하게 글을 쓰고 있습니다.